Use Case Modeling

What is use case modeling? Core concepts Diagram tour When to model use cases Modeling tips Example: Online HR System

Use Case modelling use case model: Gives the view of a system that emphasizes the behavior as it appears to outside users. –A use case model partitions system functionality into transactions (‘use cases’) that are meaningful to users (‘actors’) –.–.

Use case diagram They simply illustrate the main functionality of the SUD and the actors that interact with it. The diagram includes Actors which are people or things that derive value from the system and use cases that represent the functionality of the system. Actors and use cases are separated by the system boundary and connected by lines representing associations. Creating a use case diagram is a four step process where by the analyst draws the system boundary, adds the use cases to the diagram,identifies the actors and then finally adds appropriate associations to connect use cases and actors.

Use Case Modeling: Core Elements

Use Case Modeling: Core Relationships >

Use Case Modeling: Core Relationships (cont’d) >

Shows use cases, actor and their relationships Use case internals can be specified by text and/or interaction diagrams Kinds –use case diagram –use case description Use Case Diagram Tour

Fig. 3-44, UML Notation Guide Use Case Diagram

Fig. 3-45, UML Notation Guide Use Case Relationships additional requests : Order Product Supply Arrange «include» Request Catalog «extend» Extension points Payment Customer Data after creation of the order Place Order 1* the salesperson asks for the catalog

Fig. 3-46, UML Notation Guide Actor Relationships

System behavior The behavior of the system under development is documented in a use case model. The use case model illustrates the system’s intended functions [Use cases] its surroundings [actors] and the relationships between the use cases and actors (use case diagram). The most import role of the use case model is communication It provides a vehicle used by the customers or end users and the developers to discuss the system’s functionality and behavior

Actors Actors are not part of the system –They represent anyone or anything that must interact with the system. –Actors are the users of the system An actor may; –Only input information to the system –Only receive information from the system –Input and receive information to and from the system.

How to identify actors Typically the actors are found in the problem statement and by conversations with the customers and domain experts. The following question may help you identify the actors of the system. –Who is interested in a certain requirement? –Where in the organisation is the system used? –Who will be benefit from the use of the system? –Who will supply the system with this information, use this information, and remove this information

How to identify actors Who will support and maintains the system? Does the system use an external resource? Does one person play several diffferent rolles? Do several people play the same role? Does the system interact with a legacy system?

How do you represent? In UML an actor is represented as a stickman

Actors In the ESU course registration system Students want to register for courses Professors want to select courses to teach The registrar must maintain all the information about courses, professors and students. The billing system must receive billing information from the system. Based on the answers to the questions posed the following actors have been identified: –Student, Professor, registrar, and the Billing system.

Actor documentation A brief description for each actor should be added to the model. The description should identify the role of the actor plays while interacting with the system.

Actor documentation-example Student: A person who is registered to take classes at the university Professor- A person who is certified to teach classes at the university Registrar- the person who is responsible for the maintenance of the course registration system. Billing system-the external system responsible for the student billing.

Use Cases Use cases model a dialogue between an actor and the system. A use case is a task which an actor needs to perform with the help of the system. They represent the functionality provided by the system that is –What capabilities will be provided to an actor by the system. –The collection of use cases for a system constitute all the defined ways.

Use case definition A sequence of transactions performed by a system that yields a measurable result of values for a particular actor. The following questions may use to help identify the use cases for a system. –What are the tasks of each actor? –Will any actor create, store change, remove or read this information? –What use cases will create, store change, remove or read this information? –Will any actor need to inform the system about sudden external changes.

Use case definition –Does any actor need to be informed about certain occurrences in the system –What use cases will support and maintain the system? –Can all functional requirements be performed by the use cases?

Use case representation In UML a use case is represented as an oval as shown below.

Use cases in the ESU course registration system The following needs must addressed by the system: –The student actor needs to use the system to register for courses. –After the course selection process is completed, the billing system must be supplied with billing information. –The professor actor needs to use the system to select the courses to teach for a semester and must be able to receive a course roster from the system –The registrar is responsible for the generation of the course catalog for a semester and for the maintenance of all the information about the curriculum, the students, and the professors needed by the system

Use cases Based on the needs identified, the following use cases have been identified. –Register for courses –Select courses to teach –Request course roster –Maintain professor information –Maintain student information –Create course catalog

System Boundary This can be useful when modelling a complex system which is split into different subsystems. You may have one use case diagram for each subsystem.

When to model use cases Model user requirements with use cases. Model test scenarios with use cases. If you are using a use-case driven method –start with use cases and derive your structural and behavioral models from it. If you are not using a use-case driven method –make sure that your use cases are consistent with your structural and behavioral models.

Use case relationships An association may exist between an actor and a use case. This type of association is referred to as a communicate association since it represents communication between an actor and a use case. May be in both directions (Actor to use case and use case to actor. The navigation direction represents who initiates the communication. An association is represented as a line connecting the related elements.

Main ESU use case diagram

Types of relationships Extend Include Note: Multiple use case may share pieces of the same functionality. –This functionality is placed in a separate use case rather than documenting it in every use case that needs it.

The Include relationship Include relationships are created between the new use case and any other use case that uses its functionality. E.g each use case in the ESU course registration system starts with the verification of the user. This functionality can be captured in a user verification use case, which is then used by other use cases as needed.

The extend relationship Used to show –optional behavior –Behavior that is run only under certain conditions such as triggering an alarm –Several different flows that may be run based on actor selection E.g A use case that monitors the flow of packages on a conveyor belt can be extended by a trigger Alarm use case if the packages jam

Example >

Stereotype Provides the capability of extending the basic modelling elements to create new elements. Stereotype elements are included within guillemets( >) and placed along the relationship line. Stereotypes are used to create the needed use case relationships. The stereotype > may be added to an association to show that the association is a communicate association. –This is optional since an association is the type of relationship allowed between an actor and a use case. –Include and extend relationships must use stereotypes since they are both represented by a dependence relationship.

Use case relationships > External use case The included use case A base use case Another base use case

Use Case Modeling Tips Make sure that each use case describes a significant chunk of system usage that is understandable by both domain experts and programmers When defining use cases in text, use nouns and verbs accurately and consistently to help derive objects and messages for interaction diagrams Factor out common usages that are required by multiple use cases –If the usage is required use > –If the base use case is complete and the usage may be optional, consider use > A use case diagram should –contain only use cases at the same level of abstraction –include only actors who are required Large numbers of use cases should be organized into packages

Example: Online HR System

Online HR System: Use Case Relationships

Use Case Name Primary Actor Stakeholders and Interests: Preconditions Main Success Scenario (or Basic Flow) Extensions (or Alternative Flows) Special Requirements Technology and Data Variations List FULLY DRESSED USECASE MODEL

Online HR System: Update Benefits Use Case n Actors : employee, employee account db, healthcare plan system, insurance plan system n Preconditions:  Employee has logged on to the system and selected ‘update benefits’ option n Basic course  System retrieves employee account from employee account db  System asks employee to select medical plan type; include Update Medical Plan.  System asks employee to select dental plan type; include Update Dental Plan.  … n Alternative courses  If health plan is not available in the employee’s area the employee is informed and asked to select another plan...

Use Case Description: Change Flight n Actors: traveler, client account db, airline reservation system n Preconditions:  Traveler has logged on to the system and selected ‘change flight itinerary’ option n Basic course  System retrieves traveler’s account and flight itinerary from client account database  System asks traveler to select itinerary segment she wants to change; traveler selects itinerary segment.  System asks traveler for new departure and destination information; traveler provides information.  If flights are available then  …  System displays transaction summary. n Alternative courses  If no flights are available then … Note:Use case detail should be written in a third person, active- voice English.

Explaining the sections Explaining the sections: –Preface Elements: Only place elements at the start which are important to read before the main success scenario. –Primary Actor: principal actor that calls upon system services to fulfil a goal. –Stakeholders and interests list is very important. It creates the basis upon which the system requirements are identified. This is because the system under development operates a contract between the stakeholders, with the use cases detailing the behavioural parts of that contract. The use cases as a contract for behaviour, captures all and only the behaviours related to satisfying the stakeholders’ interests. –The question of our interest is what should be included in the use case?

Explaining the Sections –The use case should include anything that satisfies all the stakeholders’ interests. –By starting with the stakeholders and their interests before writing the remainder of the use case, we have a method to remind us what the more detailed responsibilities of the system should be. For example is it possible to identify the responsibility for sales person commission handling if you did not list the salesperson as a stakeholder and specified his or her interests? –The stakeholder interest viewpoint provides a thorough and methodical procedure for discovering and recording all the required behaviours. Preconditions and Success Guarantee (Post conditions) –Pre Conditions:state what must always be true before beginning a scenario in the use case. Preconditions are not tested within the use case; rather, they are conditions that are assumed to be true.

Explaining the sections –A precondition implies a scenario of another use case that has successfully completed, such as logging in or in more general “cashier has been identified and authenticated”. –Note that there are many other conditions that have to be true but not all them need to be mentioned. We only mention those with high practical value. There is not practical value involved in stating that the system power must be on. –We only state the noteworthy assumptions that the use case writer thinks readers should be alerted to. Success Guarantee (or Post conditions) –State what must be true on successful completion of the use case. –Either consider the main success scenario or some alternate path. –The guarantee should meet the needs of all the stakeholders.

Explaining the sections Main success scenario and steps (or Basic Flow) –It is called the happy path scenario. –It describes the typical success path that satisfies the interests of the stakeholders. –It is advisable to defer all conditional and branching statements to the extensions section –Step one of the success scenario indicates the trigger event that starts the scenario. –It is a common idiom to always capitalize the actors’ names for ease of identification. –Note also the style used for steps that have to be repeated.

Explaining the sections Extensions (or Alternative Flows) –These are equally important. –Indicate all the other branches or scenarios or both success and failure. –These are more complex and longer than the success scenario section. –These are also called alternative flows. –The combination of the happy path and the extension flows should satisfy nearly all the interests of the stakeholders. We state nearly because some interests may best be captured as non functional requirements expressed in the supplementary specification rather than the use cases. –Extension scenarios are branches from the main success scenario, and so can be notated with respect to it –Example at step 3 of the main success scenario there may be an invalid item identifier, either because it was incorrectly entered or unknown to the system. Its extension is labeled 3a. It first indicates the condition and then the response.

Explaining the sections –At the end of the extension handling, by default the scenario merges back with the main success scenario, unless the extension indicates otherwise such as by halting the system. –If an extension appears too complex, we try to define it as a separate use case. Special Requirements –If a non functional requirement, quality attribute or constraint relates specifically to a use case, record it with the use case. These include qualities such as performance, reliability and usability and design constraints (I/O devices) that have been mandated or considered likely. –Many analysts find it useful to ultimately consolidate all non functional requirements in supplementary specification, for content management, comprehension and readability, because these requirements have to be considered as a whole during architectural analysis.

Explaining the sections Technology and Data variation List –Often there are technical variations in how something must be done, but not what, and it is noteworthy to record this in the use case. –Example is a technical constraint imposed by stakeholders regarding input or output technologies. E.g. a stake holder may suggest the POS must support Credit Account Input using a card reader and the key board. –These are early design decisions or constraints. It is skilful to avoid premature design decisions but sometimes they are obvious or unavoidable especially concerning I/O technologies. –This list is also available for us to understand the data variations, so it is a place we record anything to do with data variation schemes such as UPCs or, encoded in bar code system –This section should not contain multiple steps to express varying behaviour for different cases. If that is necessary include it in the extension section.

UML is effective for modeling large, complex software systems It is simple to learn for most developers, but provides advanced features for expert analysts, designers and architects It can specify systems in an implementation-independent manner 10-20% of the constructs are used 80-90% of the time Structural modeling specifies a skeleton that can be refined and extended with additional structure and behavior Use case modeling specifies the functional requirements of system in an object-oriented manner Ideas to Take Away