Slide2Use Case Diagrams •Use case diagrams used for to specify: •(external) requirements, required usages of a system under design or analysis (subject) - to capture what the system is supposed to do; •the functionality offered by a subject – what the system can do; •requirements the specified subject poses on its environment - by defining how environment should interact with the subject so that it will be able to perform its services. •Diagrams consist of: • Actors • Use case • System • Packages
Slide3Actors •An Actor is any entity that performs a role in one given system. This could be a person, organization or an external system. •Give meaningful business relevant names for actors – For example if your use case interacts with an outside organization its much better to name it with the function rather than the organization name. (Eg: Airline Company is better than PanAir) •Primary actors should be to the left side of the diagram – This enables you to quickly highlight the important roles in the system.
Slide4•Actors model roles (not positions) – In a hotel both the front office executive and shift manager can make reservations. So something like “Reservation Agent” should be used for actor name to highlight the role. •External systems are actors – If your use case is send email and if interacts with the email management software then the software is an actor to that particular use case. •Actors don’t interact with other actors – In case actors interact within a system you need to create a new use case diagram with the system in the previous diagram represented as an actor. •Place inheriting actors below the parent actor – This is to make it more readable and to quickly highlight the use cases specific for that actor.
Slide5Use Case •represents a function or an action within the system. Its drawn as an oval and named with the function. •Names begin with a verb – An use case models an action so the name should begin with a verb. •Make the name descriptive – This is to give more information for others who are looking at the diagram. For example “Print Invoice” is better than “Print”. •Highlight the logical order – For example if you’re analyzing a bank customer typical use cases include open account, deposit and withdraw. Showing them in the logical order makes more sense.
Slide6•Place included use cases to the right of the invoking use case – This is done to improve readability and add clarity. •Place inheriting use case below parent use case – Again this is done to improve the readability of the diagram.
Slide7System and Packages •System defines the scope of the use case and drawn as a rectangle. This an optional element but useful when your visualizing large systems. •Packages are Optional element that is extremely useful in complex diagrams. Packages are used to group together use cases.
Slide8System and Packages •Use them sparingly and only when necessary •Give meaningful and descriptive names to these objects
Slide9Relationships •Association between an actor and a use case •Generalization of an actor •Extend relationship between two use cases •Include relationship between two use cases •Generalization of a use case
Slide10Relationships •Arrow points to the base use case when using <> •<> can have optional extension conditions •Arrow points to the included use case when using <> •Both <> and <> are shown as dashed arrows. •Actor and use case relationship doesn’t show arrows.