Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - jaimeglz

Pages: 1 ... 3 4 [5] 6 7 ... 11
General Board / Re: A newbie Questions
« on: December 19, 2002, 07:01:14 pm »
Hi again,

You do'nt need to worry about how to move this thread to the UML Process forum: Sparkx will read this thread.

(Geoff: Can this thread be moved to the other forum? Thnks in advance.)

On my other concern, my point is that there is so much overlap between robustness and sequence diagrams that I would not do both for a single use case.

Here's a link to a discussion that took place in this forum on robustness diagrams some months ago, and which I hope can be of help:

Keep us posted as you go along in your roadmap.


General Board / Re: A newbie Questions
« on: December 19, 2002, 10:39:12 am »
Hi kalmen,

The roadmap you suggest sounds pretty good for a small-to-medium project (say, a couple of weeks to two months for analysis and design), but I want make a couple of comments:

1. Why do robustness AND sequence diagrams?

I know there are forum participants who use robustness diagrams, and they could give us their comments on this; but IMHO robustness diagrams are great whenever you have a use case that has a limited amount of interacting elements (and you are not going to clutter your use case figure). In these cases, there is no need for a sequence diagram.

Likewise, if you have a good ammount of interacting elements, I'd recommend to use a sequence diagram directly. Why do an incomplete and redundant robustness diagram in these other cases?

If you have a very limited ammount of time, and situation allows, stick to either robustness OR sequence diagrams. This will make your project a lot easier.

2. Would you agree to move this thread to the (neighboring) UML process forum, where these sort of issues are discussed?

I hope this helps.

Jaime Gonzalez

General Board / Re: Use case enough ??
« on: December 17, 2002, 08:28:12 am »

Thnks for the suggestion: I will take a look at Six Sigma (and I've already bookmarked their web page).

I picked up the idea of the user, structure and behavior views (or development tracks) from a schematic diagram that had been produced by Monique Bona´, from Belgium, for the Unisys TeamDesign process in 1995. I was an instructor for the TeamDesign roll-out effort back then, and met Monique at a Design Scholl held at the Unisys Training Center for Europe at Milton Keynes (and got to admit some of my pupils, including her, knew more than I).

When I saw the poster with the three views, I thought it was really a neat idea: the user interface track leads to the user interface set of deliverables; the behaviour track leads to object behaviour, strored procedures, programs...;  the structure track leads to the data base...

Yourdon had originally defined the information, function and time views, but they didn't even come close to the clarity achieved by this newer, object-oriented, way of seeing things. And Martin and Odell had also stressed the idea of views, but their way of explaning it was a bit complicated.

Later, during an actual project, I added the technical architecture track out of sheer necessity.

Well, I just wanted to give due credit on where I got this idea, so I'll better not keep this too long.


General Board / Re: Use case enough ??
« on: December 16, 2002, 03:47:42 pm »
Hi ac, Steve, Fred... all,

Another two bits on the topic of use cases and requirements:

One way of viewing a software project (excluding the project management perspective) is to see it from four different points of view:

1. The user's view: This view emphasizes that what the user really sees are the interfaces with the system, such as windows, dialogs, screens...

2. The behaviour view: What behaviour should the system have? For instance, what should the system do in response to certain events.

3. The structural view: What structural elements does the system need to store and handle the necessary objects for the required behavior?

4. The technical architecture view: What platform, OS, communications, database management system... are needed or are the optimal for all of the above?

Each one of these four development tracks has its own set of requirements. So, lets ask the question: Do use cases satisfy all types or requirements? And the answer is "almost, but not quite...". For instance, there could be a formal requirement to reuse as much as possible the existing technical infrastructure of a company; so, if you are using only a use case model, you will need to produce a separate document for this sort of requirements.

On the other hand, does UML have all the necessary artifacts to handle the four development tracks? And the answer is a confident "yes", or it does so to a very high degree.

For instance, we can create a deployment diagram that depicts the existing technical infrastructure, and specify that we need to stick as much as possible to this architecture.

Or take another example: UML also has class diagrams where we can document and specify static business rules (such as what should be the relationship between a budget item and an expense). Can you model these static rules in use cases? Probably... but you will have to really stretch your model and your documentation.

In conclusion: use cases are very good to drive the modeling effort, and are considered best practice for discovering requirements; but they are not a cure-it-all.

Jaime Gonzalez

General Board / Re: Forum keeps loging me off
« on: December 07, 2002, 06:52:49 pm »
Problem solved: I just have to check "Allways keep logged in" during sign on.

General Board / Re: Use Case with Stereotype
« on: November 28, 2002, 03:42:10 pm »
What version and build are you using?

I created an <<external>> stereotype for classifiers using version 3.11, build 504 (Reference -> Stereotypes    Stereotype: external, Applies to: classifier) and I can see it in the Stereotype dropdown edit in the use case's dialog.

Of course, it does not show up as <<external>> in the diagram representation of the use case; but very possibly you can give it a visual cue by using the metafile procedure. (I did not try the metafile.)


General Board / Re: Use Case with Stereotype
« on: November 25, 2002, 08:38:19 pm »
Hi Jumbik,

True, in References -> Stereotypes  there is no option for use cases in "Applies to"; true, also, that UML allows for stereotyping of any classifier and any association. But use cases are classifiers (for those not familiar with the concept, these are, basically, UML elements that have both attributes and behaviour), and there is an option for "Applies to" "classifier" in References -> Stereotypes, and you can create the <<external>> stereotype for your use cases there.

After you create this stereotype for classifiers, it will be available in your use case dialogs.

To automatically give these use cases a clear visual cue, just follow the instructions on metafiles in help.

Hope this works for you, and good luck!

Jaime Gonzalez

General Board / Re: All requirements in EA - doable? Advisable?
« on: November 29, 2002, 08:09:59 pm »
Hi Phil,

As part of our high-level methodological discussion, I would like to clarify a bit what PUP means down here. A very wise street-philosopher discovered that, nothwithstanding their political preferences, Mexicans are divided into two political parties: the PUP, Universal Party of P....s (pretty strong word, which net-etiquette prevents me from printing here, but basically meaning dumb, error-prone person); and the PyP, the party of Presumptous and P...s (that is, the party of those that do not have the humility of recognizing themselves as error prone, but who are so anyway).

(Apologies to those not interested in vulgar humour.)

Great presentation! Thanks for sharing it, Phil.


General Board / Re: All requirements in EA - doable? Advisable?
« on: November 28, 2002, 04:50:02 pm »
Hi Frank,

I hope we can have a more fruitful exchange on this topic, but here are some preliminary comments on requirements in EA.

For most projects, I create a "Project definition and requirements" package as the first package in my EA projects. I'm currently experimenting on having this requirements package as part of a more general "Subject matter area analysis" package, together with the area's org chart package, the processes package and the domain structural model; but this not essential, and is only a matter of how you organize your project tree.

In this project definition and requirements package I create a diagram with the relationships between requirements and goals. I got the idea from Eriksson and Perker's "Business Modeling with UML" (see "Goals", under chapter 3: "Modeling the Business Architecture"), though I add requiriments in addition to these author's quantitative and qualitative goal diagrams.

Why is this useful? 1. Because I get a visual diagram with a model of project goals and requierements; 2. EA can generate a pretty nice RTF from this package. The RTF contains a description of each goal and each general requirement, the org-chart, the process diagram and the domain structural model (formerly called "Logical business model", and that contains the "real world" objects you first discover in the subject area; sort of a pre-structural-class model). You can add, also, a preliminary technical architecture package, which will also be part the RTF (or, if you preffer, of the HTML) doc.

In the diagram, all major requirements and goals are associated with the project's ácentral goal; for instance: "Design, develop, test and put into production a system for capturing, storing, concentrating and analyzing individual and community data, in order to support decision making by municipal and state authorities". The general requirement to put this systems into production "depends on" adequate testing, which "depends on" building the system, which "depends on" design... and so forth. It is simpler to display these relationships visually that to explain them in the text.

The RTF I generate with these packages (including diagrams) is the heart of the project's scope document, which is the most important specification you need the customer to agree on --in order to mitigate scope creep-- before you embark on further analysis (for instance, before you embark on the use case model) or design. It is also an extremely useful document to reference in a formal contract.

If I model and base-line goals and requirements this way in EA, then I do not need to write and maintain a separate scope document; instead, I have a single place where I introduce new general requirements and goals, objects in the org chart, etc. In other words, I can control project scope (largest single source of project headaches) in a the same project file where analysis and design are contained.

I guess we can add this scope document deliverable to the PUP (Phil's Unified Process, which I propose to be built by EA forum members as our alternative to the proprietary Rational Unified Process; and, believe me, people here in Mexico will get a kick out our process being called PUP).

Jaime Gonzalez

General Board / Re: How to share a class
« on: December 05, 2002, 08:20:13 pm »

General Board / Re: How do I best organize these Use Cases ?
« on: December 05, 2002, 08:12:03 pm »
Hi Alco,

All three solutions in your last posting are consisteng with UML rules, so you can choose a solution depending on other considerations; for instance:

Just how finely grained do you want your use case diagrams to be? If my model is grained to the point where I have a use case for each non-trivial dialog, then the creation of a new use case that <<extends>> the general customer info edit use case is appropriate.

How cluttered is you diagram? This is related to the previous question, and if the answer is "its getting more and more cluttered", what I would recommend is to create a subbordinate diagram, with the use cases pertaining to customer info editing.

For navigation from the general diagram into the more detailed use case diagrams, check other items in this forum on how to link one diagram to another.

Keep us posted if this does not answer your question.

Jaime Gonzalez

General Board / Re: Can classes default to other language?
« on: November 07, 2002, 06:10:49 pm »
Hi Jason,

As I'm sure you are aware, it is easy to add a new language and new data types for that language; but I haven't been able to set this new language as default, either: the only languages I can have as default are the ones that have icons in the View --> Options tree.

While Sparx fixes this (or answers, and thus brings us out of our ignorance), I suggest a quick and dirty solution: take the existing language that resembles SQLWindows (that used to be Gupta, am I wrong?) the most, modify its data types as needed, and set it as the default language.

This is not the most elegant solution, but I hope it helps!


General Board / Re: Is there a means to control errors in the mode
« on: December 02, 2002, 09:02:22 am »
Hi Phil,

The UML metamodel is quite specific on the concept of "namespace": two elements of the same type cannot have the same name in the same namespace. The "namespace" metaclass is, as a matter of fact, one of the central components of the metamodel's "backbone".

In our case (working with EA), the namespace is the "root" package in our project tree. (I'm probably wrong in calling it "root", because in EA you can have several namespaces in the same project.)

Of course, you are right in considering the full path as the element's name.


General Board / Re: Is there a means to control errors in the mode
« on: November 29, 2002, 08:38:55 pm »
Hi Thomas,

I suggest you search the forum for "relationship matrix". We had quite a good discussion on this some months ago (July? August...?) But in case you have trouble searching for the appropriate thread, the main idea is to use the matrix (Project -> Relationship Matrix) to check the integrity of your model.

A repetition of classes (or, in general, objects) with the same name will be very visible in your matrix.

Hope this helps.

Jaime Gonzalez

General Board / Re: Table Class
« on: November 28, 2002, 05:06:38 pm »
Hi Olaf,

According to SQL standards, adding a PK contraint to a table should automatically create an index for the chosen column or columns. An index is a behavioural feature, which plays the same role as an operation; for instance, when you invoke the index (which happens automatically when you search for a primary key datum), you fire-off a sequence of events, which is part the behavioural aspect of your table.

In UML, behavioural features of classifiers (such as tables) are grouped into the operations dept., and this is why SQL constraints, such as PKs, appear in the operations section of the classes' box.

Hope I have helped to clarify the issue.

Jaime Gonzalez

Pages: 1 ... 3 4 [5] 6 7 ... 11