What is the meaning of 'Use Points'?
Lucy Hummel
Ranch Hand
Posts: 71
posted 12 years ago
Hi folks,
The Use Case description given by Sun holds the section
Use Points
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'?
Looking forward to your opinions.
Lucy
The Use Case description given by Sun holds the section
Use Points
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'?
Looking forward to your opinions.
Lucy
jono
Greenhorn
Posts: 25
vu lee
Ranch Hand
Posts: 208
Robert Paris
Ranch Hand
Posts: 585
posted 12 years ago
While I have never read the text you are talking about, my guess is they are talking about Use Case Points.
Use Case Points are basically a way of guessing how large a project's goin to be and how much time/effort it will require. In a quick and dirty...
UCP (Use Case Points) = AW (Actor Weights) + UCW (Use Case Weights)
The Actor weights are determined by first getting the total number of actors, and then giving them a "weight" based on complexity:
* Simple (GUI) = 1
* Average (interactive interface) = 2
* Complex (API-level) = 3
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.
Use Case Points are basically a way of guessing how large a project's goin to be and how much time/effort it will require. In a quick and dirty...
UCP (Use Case Points) = AW (Actor Weights) + UCW (Use Case Weights)
The Actor weights are determined by first getting the total number of actors, and then giving them a "weight" based on complexity:
* Simple (GUI) = 1
* Average (interactive interface) = 2
* Complex (API-level) = 3
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.
Lucy Hummel
Ranch Hand
Posts: 71
posted 12 years ago
Hi Robert,
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.
Lucy
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.
Lucy
Jeremy Hsu
Ranch Hand
Posts: 79
Lucy Hummel
Ranch Hand
Posts: 232
posted 12 years ago
Hi Jeremy,
That sounds good. IMO that is what Sun means with it.
Thanks
Lucy
Originally posted by Jeremy Hsu:
the Use Points that Sun uses is exactly the same as the UML use case Include notation. Use cases include other use cases
Hi Jeremy,
That sounds good. IMO that is what Sun means with it.
Thanks
Lucy
----------------------------------<br />| SCJP, SCWCD, SCBCD, SCEA, SCJD |<br />----------------------------------
I Roberts
Ranch Hand
Posts: 66
posted 12 years ago
Hi,
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.
Regards,
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.
Regards,
Ian Roberts<br />Application Architect<br />SCJP, SCJD, SCEA, OCUP Fundamental
Lucy Hummel
Ranch Hand
Posts: 232
posted 12 years ago
IMO you did not follow that naming policy.
May I ask you to update your profile
Lucy
Originally posted by jono:
Lucy,
I never figured that out. And I didn't worry about it either. I took the information contained therein and incorporated it where possible but I didn't try and figure it out.
IMO you did not follow that naming policy.
May I ask you to update your profile
Lucy
----------------------------------<br />| SCJP, SCWCD, SCBCD, SCEA, SCJD |<br />----------------------------------
