Use Case Modeling SJTU

Unified Modeling Language (UML) l Standardized notation for object-oriented development l Needs to be used with an analysis and design method Notation provides more support for analysis than design l Intended for all types of OO software development

UML Diagrams l Use case diagram l Class diagram l Object diagram Instance version of class diagram l Collaboration diagram l Sequence diagram l Statechart diagram l Activity diagram l Component diagram l Deployment diagram

Use Case l Scenario showing sequence of actions between one or more actors and system l Captures functional requirements of a system l Actor (user of the system) initiates a use case l Communication associations connect actors with use cases l Defines system behavior without revealing internal structure

UML Notation for Use Case Generalization Communication association System

Actors (1 of 2) l Model external entities that interact directly with system Human user Role played in the application domain A user type, not an individual user External input/output device ) For example, a sensor External timer External system

Actors (2 of 2) l Primary actor Initiates a use case Takes proactive role and initiates actions in the system l Secondary actor Receives outputs and provides inputs l May use I/O devices or external system to physically interact with system l At least one actor must gain value from the use case

Actor Inheritance l Inheritance (generalization) may be applied to actors l Actors B and C inherit the behavior of Actor A

Examples of Actors l Prospective student l Student l Admissions clerk l Instructor l Registrar l Subject matter expert l Cashier l Courseware developer l Credit card bureau l Alumnus l Proctor

Use Case Levels of Detail l Can be viewed at various levels of detail Use case (requirements) model Functional requirements defined in terms of actors and use cases Shows interaction between actor and black box system Analysis model Use case refined to describe objects that participate in use cases and their interactions Develop collaboration diagrams or sequence diagrams Design model Use cases further refined Use cases form basis of integration & system test cases

Use Case Model l Defines system functional requirements in terms of Actors and use cases Each use case defined in terms of sequence of interactions between Actor and System Narrative description Simple use cases may involve only one interaction More complicated use cases may involve several interactions l Example

Steps in Use Case Development l Identify the actors l For each actor, identify the major actions actor needs to perform l For each action, develop a use case using UML notation l Document each use case Describe the sequence of interactions for each use case using template on next slide Use word processor to capture use case description l Identify and implement use case relationships Include Extend Generalization

Use Case Template (1 of 2) l Use case name Unique identifier for use case l Summary 1-2 sentence description l Dependency Includes, extends, or generalization relationships l Actors Primary actor who initiates use case Secondary actors l Preconditions Conditions that must be true at start of use case (system state)

Use Case Template (2 of 2) l Description Main sequence of interactions (an event trace) Input from actor followed by response of the system System treated as black box Deals with what system does in response to actor’s input, not how system does it l Alternatives Narrative description of alternative branches from main sequence Identify possible error conditions l Post-condition Condition that is always true at end of use case if main sequence has been followed l Outstanding questions Documented questions for discussion with users

Example of Use Case (1 of 4)

Example of Use Case (2 of 4) Use Case Name: Withdraw Funds Summary: Customer withdraws a specific amount of funds from a valid bank account. Dependency: None Actor: ATM Customer Precondition: ATM is idle, displaying a Welcome message. Description: 1. Customer inserts the ATM Card into the Card Reader. 2. If the system recognizes the card, it reads the card number. 3. System prompts customer for PIN number. 4. Customer enters PIN. 5. System checks the expiration date and whether the card is lost or stolen. 6. If card is valid, the system then checks whether the user-entered PIN matches the card PIN maintained by the system. 7. If PIN numbers match, the system checks what accounts are accessible with the ATM Card.

Example of Use Case (3 of 4) 8..System displays customer accounts and prompts customer for transaction type: Withdrawal, Query, or Transfer. 9. Customer selects Withdrawal, enters the amount, and selects the account number. 10.System checks whether customer has enough funds in the account and whether daily limit has been exceeded. 11.If all checks are successful, system authorizes dispensing of cash. 12.System dispenses the cash amount. 13.System prints a receipt showing transaction number, transaction type, amount withdrawn, and account balance. 14.System ejects card. 15.System displays Welcome message. Copyright 2000 H. Gomaa

Example of Use Case (4 of 4) Alternatives:  If the system does not recognize the card, the card is ejected.  If the system determines that the card date has expired, the card is confiscated.  If the system determines that the card has been reported lost or stolen, the card is confiscated.  If the customer entered PIN does not match the PIN number for this card, then the system re-prompts for the PIN.  If the customer enters the incorrect PIN three times, then the system confiscates the card.  If the system determines that the account number is invalid, then it displays an error message and ejects the card.  If the system determines that there are insufficient funds in the customer’s account, then it displays an apology and ejects the card.  If the system determines that the maximum allowable daily withdrawal amount has been exceeded, then it displays an apology and ejects the card.  If the ATM is out of funds, then the system displays an apology, ejects the card, and shuts down the ATM.  If the customer enters Cancel, the system cancels the transaction and ejects the card. l Postcondition: Customer funds have been withdrawn. l Outstanding questions: none

Extend Relationship l Use case A is an extension of use case B Can model alternative paths of a “base” use case l Can model conditional part of base use case, which is executed under certain circumstances l Base use case does not depend on extension use case and can function independently of it l Maximizes extensibility of use cases

Include Relationship l Use case A includes use case B l Abstract use case capturing common pattern in several use cases l Concrete use cases include abstract use case l Abstract use case can not be executed on its own l Maximizes reuse of use cases

Example of Abstract Use Case (1 of 2) Use Case Name: Validate PIN Summary: System validates customer PIN. Dependency: included by Withdraw Funds, Query Account, and Transfer Funds Actor: ATM Customer Precondition: ATM is idle, displaying a Welcome message. Description: 1.Customer inserts the ATM Card into the Card Reader. 2.If the system recognizes the card, it reads the card number. 3.System prompts customer for PIN number. 4.Customer enters PIN. 5.System checks the expiration date and whether the card is lost or stolen. 6.If card is valid, the system then checks whether the user-entered PIN matches the card PIN maintained by the system.

Example of Abstract Use Case (2 of 2) 7.If PIN numbers match, the system checks what accounts are accessible with the ATM Card. 8.System displays customer accounts and prompts customer for transaction type: Withdrawal, Query, or Transfer. Alternatives:.If the system does not recognize the card, the card is ejected..If the system determines that the card date has expired, the card is confiscated..If the system determines that the card has been reported lost or stolen, the card is confiscated..If the customer-entered PIN does not match the PIN number for this card, the system re- prompts for the PIN..If the customer enters the incorrect PIN three times, the system confiscates the card..If the customer enters Cancel, the system cancels the transaction and ejects the card. Postcondition: Customer PIN has been validated. Outstanding questions: none

Example of Concrete Use Case (1 of 2) Use Case Name: Withdraw Funds Summary: Customer withdraws a specific amount of funds from a valid bank account. Dependency: Include Validate PIN abstract use case. Actor: ATM Customer Precondition: ATM is idle, displaying a Welcome message. Description: 1.Include Validate PIN abstract use case. 2.Customer selects Withdrawal, enters the amount, and selects the account number. 3.System checks whether customer has enough funds in the account and whether the daily limit will not be exceeded. 4.If all checks are successful, system authorizes dispensing of cash. 5.System dispenses the cash amount. 6.System prints a receipt showing transaction number, transaction type, amount withdrawn, and account balance. 7.System ejects card. 8.System displays Welcome message.

Example of Concrete Use Case (2 of 2) Alternatives: If the system determines that the account number is invalid, it displays an error message and ejects the card. If the system determines that there are insufficient funds in the customer’s account, it displays an apology and ejects the card. If the system determines that the maximum allowable daily withdrawal amount has been exceeded, it displays an apology and ejects the card. If the ATM is out of funds, the system displays an apology, ejects the card, and shuts down the ATM. Postcondition: Customer funds have been withdrawn. Outstanding questions: none

Generalization Relationship l Use case A (parent) is a generalization of use cases B and C (child use cases) l Use cases B and C are specializations of use case A B and C represent more specific forms of A l Child inherits attributes, operations, and relationships of parent

Use Case Package l Encompasses a related group of use cases l Address major subsets of system functionality l Use Case Package Structuring Group use cases into packages based on Major subset of system functionality Related use cases started by the same actor

Use Case Guidelines l Placing IF..THEN..ELSE statements into use case description is not recommended Looks too much like pseudocode l Small abstract use cases corresponding to individual functions should not be considered Results in a functional decomposition with fragmented use cases in which abstract use cases do not describe a sequence of events l List all actors and dependencies l First line of description must identify actor and actor input that initiates use case l Ensure that at least one actor gains value from use case l Maintain consistency between use cases l Follow notation

Context Diagram l Depicts the boundary between the system and the external environment Identifies all external entities (actors) that interact with system Can be implemented using UML or other notations

References l Hassan Gomaa, Lecture Notes on Software Requirements and Prototyping, George Mason University, Fall 2000 l Hassan Gomaa, Designing Concurrent, Distributed, and Real-Time Applications With UML, Addison Wesley, 2000