This week's book giveaway is in the Mac OS forum.
We're giving away four copies of a choice of "Take Control of Upgrading to Yosemite" or "Take Control of Automating Your Mac" and have Joe Kissell on-line!
See this thread for details.
The moose likes Architect Certification (SCEA/OCMJEA) and the fly likes use-case with no user interaction? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


JavaRanch » Java Forums » Certification » Architect Certification (SCEA/OCMJEA)
Bookmark "use-case with no user interaction?" Watch "use-case with no user interaction?" New topic
Author

use-case with no user interaction?

Frank Silbermann
Ranch Hand

Joined: Jun 06, 2002
Posts: 1387
Does it make any sense to have a use-case (or use-case extension) that involves no additional user interaction?

The Price Intinerary "use-case" is included by both Prepare Itinerary and Change Itinerary, but this seems to me more like a system subroutine than a snippet of use-case.

What additional user interaction, if any, occurs during Price Itinerary?
[ August 02, 2004: Message edited by: Frank Silbermann ]
Tomi Tuomainen
Ranch Hand

Joined: Jun 13, 2004
Posts: 86
The pricing model may be very simple at the moment, but the analyst may have thought that this is very important part of the system that could be very complicated in the future: so pricing should be separated as it's own use case.

This way the other use cases can include the pricing use case, so there's no need to duplicate the logic in use case stories. And perhaps it also makes use case diagram clearer.

Even if there wouldn't be any user interaction in the use case story (read and believe it :roll: ) this may change if more complicated pricing model will take place.

Tomi
[ August 02, 2004: Message edited by: Tomi Tuomainen ]
Parag Doshi
Ranch Hand

Joined: Jun 29, 2004
Posts: 317
Originally posted by Tomi Tuomainen:
The pricing model may be very simple at the moment, but the analyst may have thought that this is very important part of the system that could be very complicated in the future: so pricing should be separated as it's own use case.

This way the other use cases can include the pricing use case, so there's no need to duplicate the logic in use case stories. And perhaps it also makes use case diagram clearer.

Even if there wouldn't be any user interaction in the use case story (read and believe it :roll: ) this may change if more complicated pricing model will take place.

Tomi

[ August 02, 2004: Message edited by: Tomi Tuomainen ]



If the pricing model might get complicated, the core classes might need to factor in that change. For example, Segments and Flights would need to be made more sensitive in their relationships with other dependent segments/flights etc. They wouldnt be able to live in isolation like they do now.. am wondering how much should we factor in, in anticipation of a complex pricing model? how far do we think while designing our classes and their relations with other neighboring classes.

any thoughts?

parag
Tomi Tuomainen
Ranch Hand

Joined: Jun 13, 2004
Posts: 86
Parag,

For the sake of maintenability we should make a class diagram that supports a decent booking system. But we probably shouldn't model too much stuff that is not in the requirements. So it's a choice between maintenability and following poor requirements analysis .

I think it's best to follow the requirements with some exceptions that can be defended by maintenability, flexibility, extensibility, reusability etc.

Tomi
Ian Roberts
Ranch Hand

Joined: Aug 20, 2003
Posts: 46
I'm not sure what the issue is here because (to me) the business analyst was simply identifying a common piece of functionality that is used by two use cases. The Price Itinerary use case has an includes stereotype that concludes that it is a piece of functionality that has been identified as a potential reusable component and separated as such. The business analyst may have had further discussions that concluded that the Price Itinerary was to be used for other pricing mechanisms become a service-orientated component; allowing it to be reused not only by this system but potentially a number of other systems.

Although the content of the use case is quite basic, it is still common functionality that you would certainly not want to duplicate in several components - not if you value reusability.

Regards,

Ian R.
Frank Silbermann
Ranch Hand

Joined: Jun 06, 2002
Posts: 1387
Originally posted by Ian Roberts:
I'm not sure what the issue is here because (to me) the business analyst was simply identifying a common piece of functionality that is used by two use cases. The Price Itinerary use case has an includes stereotype that concludes that it is a piece of functionality that has been identified as a potential reusable component and separated as such.


Perhaps, but he's mixing requirements with design.

On the one hand, it is relevant for him to point out that the business rules for initial pricing are the same as those for re-pricing, and it's not immediately clear to me where else he would record this.

On the other hand, I cannot recall ever seeing a use case realization that did not include a user!!! Has any of you seen one?
Tomi Tuomainen
Ranch Hand

Joined: Jun 13, 2004
Posts: 86
UML spec:

A use case is a kind of classifier representing a coherent unit of functionality provided by a system, a subsystem, or a class as manifested by sequences of messages exchanged among the system (subsystem, class) and one or more outside interactors (called actors) together with actions performed by the system (subsystem, class)."


So there should be at least one actor.

Tomi
Parag Doshi
Ranch Hand

Joined: Jun 29, 2004
Posts: 317
Something I read on this website :
http://www.ajug.org/info/tech/uml/uml.html


The uses relationship occurs when you have common behavior that exists in multiple use cases that can be factored out into a separate use case (e.g., login use case). Note that actors have relationships to use cases that are being extended whereas there is often no actor associated with a common use case.



Parag
Ian Roberts
Ranch Hand

Joined: Aug 20, 2003
Posts: 46
Originally posted by Frank Silbermann:


Perhaps, but he's mixing requirements with design.

On the one hand, it is relevant for him to point out that the business rules for initial pricing are the same as those for re-pricing, and it's not immediately clear to me where else he would record this.

On the other hand, I cannot recall ever seeing a use case realization that did not include a user!!! Has any of you seen one?


That is not the purpose of the extends or includes relationship. The Business Analyst is simply identifying a reusable piece of functionality that should not be duplicated. How the designer (if he selects to) actually implements that requirement is design.

Quote from The UML User Guide, which I have not had to quote from for about 6 years(!):

"You can also organize use cases by specifying generalization, include, and extend relationships among them. You apply these relationships in order to factor common behavior (by pulling such behavior from other use cases that it includes) and in order to factor (by pushing behavior into other use cases that extends it).

...

You can use an include relationship to avoid describing the same flow of events several times, by putting common behavior in a use case of its own (the use case that is included by a BASE USE CASE)..."

There are some very good books on the market regarding UML (specifically OOAD and Use Case creation) and how to interpret it. I wouldn't simply use the UML specification because that can easily be misunderstood. As I have said before, there is nothing with including or extending a use case from another (BASE) use case without the relationship of an actor. The Sun Use Case diagram may not be content correct (?) but it does use the UML specification correctly.

The UML User Guide (OMG Press) has some Use Case diagrams that should help anyone who is not too sure on Use Cases but there are some even better books on the market.





 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: use-case with no user interaction?