Use Case Diagrams. CSIS3600 Fall 2002. *Why do we model?. Provide structure for problem solving Experiment to explore multiple solutions Furnish abstractions to manage complexity Reduce time-to-market for business problem solutions Decrease development costs Manage the risk of mistakes.
Tijuana “shantytown”: http://www.macalester.edu/~jschatz/residential.html
the artifacts of software systems
UML notation is useful for graphically depicting object oriented analysis and design models.
http://www.omg.org/technology/documents/modeling_spec_catalog.htm(it’s 808 pages long!)
Current version is v1.4
The techniques drawn from the UML model for OOAD include:
A Use Case is a behaviorally related sequence of steps (a scenario), both automated and manual for the purpose of completing a single business task.
Fig. 3-53, UML Notation Guide
to be described in detail.
Actors are different from users.
A user is anyone who uses the system.
An actor is a role a user plays.
An actor is a type or class of users - user is a specific instance of an actor
(If the same user plays two roles, he would be represented as an instance in each class of actor, i.e. John Patton is both an instructor and advisor. He would be represented as an instance in both the actor called Instructor and the actor called Advisor.)
Events triggered by time are called temporal events.
The backup of system data is automatically initiated to occur every night at 2:30 am. No one has to request the backup. It is a temporal event. The actor for this temporal event is the system itself.
One place to start is to look at context model diagrams of the system.
To identify use cases, Jacobson recommends asking:
A use case may also have alternate courses of actions
Fig. 3-54, UML Notation Guide
Diagram from Popkin Software: http://www.popkin.com/images/usecase.gif
Use cases in opposite order – Notice the direction of the arrow
Lilly, S. Use Case Pitfalls: Top 10 Problems from Real Projects Using Use Cases. Proceedings of TOOLS, USA 99, IEEE, 1999.