UML Lecture# 2 Use Case Diagrams

A Use Case diagram models the functionality of the system as perceived by outside users, called actors. • Use case diagrams – Highlight the functional requirements of the system i.e. what the system should do – Since it records “what the system should do”, thus it become the basis for performing tests that verify whether the system doing what the user expects – Pthe ability to trace functional requirements into classes and operations • Audience of Use Case diagram – Clients can see the use case diagram to confirm whether the system will do what they expect – Quality Assurance Team may refer to use case diagrams while verifying whether system meets the expectations of clients – Architects may use the diagram to see what functionality should be made available to various users Components of a use-case diagram • Use-cases – Represents a complete functionality as perceived by an actor – It encapsulates a description of a set of sequence of actions, including variants that the system performs to yield an observable value to an actor. The sequence and variants are documented in a use case specification • Actor – representing a role that someone might play, rather than a particular individual – external entity that has interest in interacting with the system – Someone who gives input or receive any output from the system • Interaction – a communication relation between an actor and a use case Drawing a use case diagram • The first step is to identify the actors • Then we should identify the activities that are initiated by actor or the activities whose output is received by an actor. • It should be seen whether any sub activities are performed or whether some actions are performed in special situations Use Case Relationships A use case is usually associated with an actor. This association is known as communications associations The navigation direction of an association represents who is initiating the communication Relationships also exist between use cases Generalization relationship: Sometimes certain use case is a specialized version of another use case. For example, Conduncting a Test is a general situation whereas a Conducting a Mid-Term is a special situation that has all the processes/steps of Test as well as some additional steps/ Include – Base use case explicitly incorporates the behavior of another use case – It enables us to avoid describing the same flow of events several time by putting the common behavior in a use case of its own • Extend – An extend relationship between use cases means that behavior of another use case is conditionally incorporated in the base use case – Use an extend relationship to model the part of a use case the user may see as optional system behavior