The Use Case description given by Sun holds the section
I do not know the meaning.
Does that section describes when the Use Case is used? So in case of 'Change Itinerary' is that called when the customer has confirms an itinerary and then wants to change its 'confirmed' itineray. After changing, the Use Case 'Change Itinerary' went for 'Paying Itinerary'?
Use Case Weights are determined in basically the same manner, with simple, average, complex weights (you determine the weights, but generally it's from the number of transactions/scenarios in the Use Case.
These are actually unadjusted weights, since you also need to compute based on where in the project cycle they need to be implemented (for example, will they be dealt with in dev, test, security, etc). But you get the picture.
Again, you didn't include the actual text from Sun's book so I'm not sure this is what they're talking about, but that's what a Use Case Point is.
Joined: Jul 22, 2004
Thanks for your explanation.
I did not write some text of the exam since it might be forbidden and I do not want to do forbidden stuff.
In my opinion the 'Use Point' in the exam Use Case description has a different meaning as you explained. I guess that the section describes more or less when the Use Case is called or so.
I think what Sun really meant was "Extension Points" rather than "Use Case Points". There are books than can explain extension points better than I can but really it is the business logic or conditions that derives whether or not an "extended" use case is initiated.
What Sun may have intended is to create their own meaning that incorporates both inclusions and extensions. But I'm about 99% sure that is not within the UML 1.5 or UML 2.0 specifications. However, as this is referred to within a "Use Case Specification" and that a specification is not within the domains of UML, they can create whatever they like.
I attended a Sun Microsystems Education OOA&D course a number of years ago that was very good - one of the best courses I've been on. Looking at my notes, which includes Use Case Forms/Specifications, the course literature uses the correct terminology as "Extension and Inclusion Points".
Whether it was intentional or that the course providers should attend one of their own courses is questionable. However, I suppose it does reflect the true nature of Use Cases and the unfortunate diversity of understanding that the industry is faced with. Unlike other aspects of UML, Use Cases are probably the least defined and the most likely to be interpreted differently by five people in the same room.
Ian Roberts<br />Application Architect<br />SCJP, SCJD, SCEA, OCUP Fundamental