• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

use-case with no user interaction?

 
Ranch Hand
Posts: 1419
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ]
 
Ranch Hand
Posts: 86
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ]
 
Ranch Hand
Posts: 317
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 86
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Ranch Hand
Posts: 46
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 1419
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 86
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 317
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 46
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.





 
reply
    Bookmark Topic Watch Topic
  • New Topic