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 - Javier

Pages: 1 ... 3 4 [5]
Uml Process / UML Certification from OMG!
« on: August 08, 2003, 11:51:11 am »
It came to my attention that the Object Management Group, the sheperd of UML, is offering a certification in UML.  Exams are normally $200 USD but for a limited time you can get them for $80 USD.

The exams test your knowledge of UML in several different areas, and there are 3 levels that you can be certified in.

Check the information at:

Uml Process / Re: Dependency between UseCases
« on: August 07, 2003, 12:07:28 pm »

I do not believe that they are necessarily related, since a guest can check in without a reservation.

Therefore, a reservation *is not* a pre-condition to check-in.

I see three ways that this can be modeled:

1. Let  Check In With Reservation <<refine>> Check-In.  This new use case would have a <<refine>> association

Check In <---------------- Check In With Reservation

The refinement then must have a reservation as a precondition.

Your use case text would then look similar to the check in use case, except that the first steps would be to retrieve the reservation information.

2. Let Check In With Reservation <<include>> Check-In.

The use case would also have a reservation as a precondition.

Check In <---------------- Check In With Reservation

The semantics for include and refine are different, but in this case you could consider that it is valid to <<include>> the other use case.  Your text would then look something like this--depending on your use case template):

1. The clerk asks for guest information
2. The clerk retrieves the reservation.
3. The Check-In use case executes

3. Model it as a scenario:  The general steps of the use case are the same.  You should pick the most common scenario as the abstraction for your main use case, and then the other as a given scenario.



Uml Process / Re: Use Case Diagram question
« on: July 30, 2003, 03:55:50 pm »

Almost there.  Invert the generalization between User and Admin.  You can see that most of the use cases will be performed by User but only a few will be performed specifically by Admin.  Admin should "derive" from User.


I like the packages.  You can see that they add clarity.  As of the rest, it looks correct to me.  Some people may more demanding, but your model conveys what you mentioned in your original posting.



Uml Process / Re: Use Case Diagram question
« on: July 30, 2003, 09:54:54 am »

1. A generic recommendation is to create packages for semantically-related use cases.  For example, session-related use cases (Log In, Log Out) User Maintenance (add/delete/modify/lock account/modify password).  This way it'll be eaiser to read the diagram.

2. Another recommendation is to use verb-noun approach for the use case names.  This would change Login to Log In, Logout to Log Out and Load UserData to Load User Data, Modify UserPassword to Modify User Password, etc.--actually, login and logout, logon and logoff, are nouns, but people mistakenly uses them as verbs ;-)

3. Administrator IS-A User, therefore, it should be a generalization of user, not backwards.  This stems from the fact that most users are not administrators, while all administrators are users.  This would also eliminate the Normal User actor.

4. Given the recommendation above, Delete User could have an extension point when the user is Admin, not when it is not.

5. I do not see how the Login use case includes Save UserData

6. I do not see the reason for existence for Modify UserPassword and Modify UserName.  It seems to me they do not contribute to the model and should be part of Modify User.



Uml Process / Re: c# design model
« on: July 29, 2003, 03:42:31 pm »

Contrary to your statement, Rational Rose XDE supports C#...if you're willing to pay.  You can use EA to generate C# programs--or C++, or...

I'd advise you to download the Zicom Mentor tutorial so that you learn the capabilities of EA.  After that, every modeling tool that can generate code from a model and reverse engineer code into a model is really a try-as-you-go approach: try writing a couple of classes and then generate the code with EA, than go backwards, etc. ;-)



Uml Process / Re: Dependency stereotypes
« on: July 25, 2003, 10:25:16 am »

If A is heavily dependent on class B, then it probably deserves a regular association (solid line).  Let me explain:

All dependencies can be traced to this:

                    <<stereotype here>>
CLASS A-----------------------------------> CLASS B

Bidirectional dependencies can be represented like this:

CLASS A <----------------------------------- CLASS B

Dependencies that are so common deserve their own icon (or line), e.g., aggregation, composition, etc.

Therefore, if A is heavily dependent on B, it should probably look like this:

CLASS A ____________________> CLASS B

and if B is not so heavily dependent on C then it should look like this:

CLASS B----------------------------------> CLASS C

This is usually true, for example, when in class B a method takes an argument of type C or something that can be converted to C, or when within a method in B you use a C.

If you receive an argument in a method in B that can be converted to a C, there is a special stereotype, <<become>>, that indicates that the argument can become a given type.  Usually you would have to cast the argument it to given type.  In C++ you would use a dynamic_cast, in C# a (MyType) cast, in VB a (IMyInterface) cast, etc.  The association can be represented with:

CLASS B -----------------------------------> CLASS C

C++ design also distinguishes heavy and lightweight dependencies by calling them "uses in the interface" and "uses in the implementation" (John Lakos), which roughly correspond to the description you gave.

Hope this helps--given the late response :-)


Uml Process / Re: Organising Packages
« on: July 25, 2003, 09:58:10 am »

Either I can't find the constraint you have or I don't understand your post correctly:  You're able to create any type of element in the package of your choosing (right-click...New element type)

I follow the approach you describe too.  Although the 4+1 view is a nice starting point, one is not constrained to use it.  I also group functionality by package and mix all the related elements in that package--use cases, classes, etc.

For example, when we have a design that will yield two components: the functional component and its configuration, I create two packages under Logical View; one for the component functionality and another one for its configuration.  Then I distribute the appropriate use cases to each package, create the class diagrams, create the sequence diagrams to the use cases, etc.

Hope it helps,


Pages: 1 ... 3 4 [5]