Professional Documents
Culture Documents
Uke37 05 UseCases
Uke37 05 UseCases
Use Cases Were Introduced by Ivar Jacobson in the Beginnig of the 1990s.
A use case is a specific way of using the system by performing some part of the functionality. Each use case constitutes a complete course of events initiated by an actor, and it specifies the interaction that takes place between an actor and the system... The collected use cases specify all the existing ways of using the system.
Use Cases, slide no. 2
Often a Use Case Is Followed by a More Detailed Description of How the Functionality of the Use Case Is Accomplished Precondition Main or exceptional flows of events expressed as a:
written list of actions or as an activity diagram
student brows the course register page student inserts the card in the card reader
Postcondition
Use Cases, slide no. 8
Graphical Notation
An actor is a user role, a kind of stereotype. The actor is symbolized with a stick man figure with the name of the actor below the figure. A use case is shown as an ellipse, with a name inside identifying the use case. When an actor is involved in a use case, a line is drawn from the actor to the use case. We say that the actor communicates with the use case. Who is initiating the communication can be indicated by an arrowhead.
The Actor
[2] The total set of actors within a use case model reflects everything that needs to exchange information with the system.
System Boundary
System Boundary
It is possible to define the boundary of the system.
This is particular useful if you have a complex system and split it up into sub system. Specifying the boundaries of each subsystem can make the separation between the subsystem clear.
Use Cases, slide no. 15
Use of these features will typically make a use case diagram more complex to read, so they should be used with caution.
There is not full agreement on how to use these features, e.g. UML 1.1 and UML 1.3 differs on these matters.
Use Cases, slide no. 17
Stereotypes in UML
Extends and includes is represented with dependency arrow. The dependency arrow is already used, because of this extends and include must be stereotypes. In UML stereotype names are included in << and >>.
The following definition can be found in UML Notation Guide from Rational Software: A stereotype is, in effect, a new class of modeling element that is introduced at modeling time. It represents a subclass of an existing modeling element with the same form (attributes and relationships) but with a different intent.
base The include relationship indicates that the base use case incorporates the behavior of the other use case. The base use case is dependent of the included use case but not the opposite way. Functionality shared between two use cases can in this way be extracted out and described in a separate use case.
Use Cases, slide no. 19
Refinement of:
register as student
Use Case register as student: This use case is started by the student (which at this point is not a student), which request to be registered as a student. A person from the administration updates the student register.
register as student
include
student
adm
More On Include
Include is used to define functionality that is common to several use cases, a modularization technique. If we see that a component can be used, we can model this by a separate use case describing the component. A scenario that is an instance of the base use case will typically contain a sub scenario from the included one. Use Cases, slide no. 22
If a use case incorporates two ore more clearly different scenarios - some condition dictates which - this can be modeled by an extend relation. So the extend relationship can be used to model behavior that the user sees as optional or as an exception on normal behavior. The base use case can incorporate the extended behavior under certain conditions otherwise stand alone.
base You should specify: The condition under which the extended use applies At which point the condition is tested and the behavior may diverge; This point is called the extension point.
Track order
include
Validate user
Check password
parent
child
The generalization relationship indicates that the child will inherits the behavior and meaning from the parent use case. The child can alter or/and extend the behavior of the parent, but it should be possible to substitute the child for the parent every place the parent is used.
Use Cases, slide no. 26
Student
Use Cases, slide no. 30
extend
Stimuli
Buyer extend
Buyer returns goods
Use Cases, slide no. 31
Use Case: 5 Buy Goods Each step take the form A does X, where A is ---------------------------------------an actor and X is an action. If a use case is MAIN SUCCESS SCENARIO included you will find a step that has the form 1. Buyer calls in with a purchase request. include U, where U is another use case. 2. Company captures buyers name, Extension 3a is execute instead of 3 if condition: address, requested goods, etc. Company is out of one of the ordered items is 3. Company gives buyer information on fulfilled! goods, prices, delivery dates, etc. Company is out of one of the items 4. Buyer signs for order. 5. Company creates order, ships order to buyer. extend 6. Company ships invoice to buyer. Buyer pays directly 7. Buyers pays invoice. Buy Goods with credit card extend ---------------------EXTENSIONS Buyer 3a. Company is out of one of the ordered items: extend 3a1. Renegotiate order. Buyer returns goods 4a. Buyer pays directly with credit card: 4a1. Take payment by credit card (use case 44) 7a. Buyer returns goods: 7a. Handle returned goods (use case 105)
Use Cases, slide no. 32
[1] The last step in a extension can take one of the following forms:
Fail - use case is terminated and goal is not achived Stop - use case is terminated and goal is achived Resume N - execution should continue at step N in main success scenario. If the last step is not one of the above, continue at main scenario.
Use Cases, slide no. 33
extend
References
[1] Alistair Cockburn : http://members.aol.com/acockburn/ 2001, Feb. [2] Doug Rosenberg and Kendall Scott: Use Case Driven Object Modeling with UML: A Practical Approach Addison-Wesley - Ivar Jacobson: Object-Oriented Software Engineering: A Use Case Driven Approach. Addison-Wesley, 1994 - Martin Fowler with Kendall Scott: UML Distilled. Addison-Wesley, 1997 - Grady Booch, James Rumbaugh, Ivar Jacobson: The Unified Modeling Language User Guide.Addison-Wesley, 1999 - Terry Quatrani: Visual Modeling with Rational Rose and UML. Addison-Wesley, 1998 - Daniel Tkach, Walter Fang and Andrew So: Visual Modeling Technique, 1996 - Alistair Cockburns Web: http://members.aol.com/acockburn - Rational software: http://www.rational.com/uml/documentation.html
Use Cases, slide no. 36