CS212: Object Oriented Analysis and Design Lecture 32: Use case and Class diagrams

Recap of Lecture 31 Introduction to modelling UML Evolution Different views of a system Different modelling diagrams

Outline of Lecture 32 UML Use case diagram Class diagram

Use Case Diagram It allows to describe the possible usage scenarios (use cases) that a system is developed for It expresses what a system should do However, does not address any realization details such as data structures, algorithms, etc. Use cases represent the customer’s requirements of the system

Use case diagram What is being described? (The system.) Who interacts with the system? (The actors.) What can the actors do? (The use cases.)

Use Cases A use case describes functionality expected from the system to be developed a use case is triggered either by invocation of an actor or by a trigger event, in short, a trigger A use case is usually represented as an ellipse.

System The set of all use cases together describes the functionality that a software system provides Query student data Issue certificate Announce Exam Student Administration system

Actors It is essential to document who actually works and interacts with the system Actors always interact with the system in the context of their use cases Actors are represented by stick figures

Example

Type of Actors Human/non-human Active/passive Primary/ Secondary

Example Active vs. Passive Active vs. Active Primary vs. Secondary Human Non-Human

Associations An actor is connected with the use cases via associations It express that the actor communicates with the system and uses a certain functionality An association is always binary Multiplicities may be specified for the association ends.

Association: Example

Role Actors do not represent a specific user They represent roles that users adopt Specific users can adopt and set aside multiple roles simultaneously Example: Student vs. TA

Relationships between Actors Actors often have common properties and some use cases can be used by various actors

A word of caution Generalization: actors that are specialized versions of other actors

Relationships between Use Cases «include» relationships use cases that are included as parts of other use cases. Enable to factor common behavior. «extend» relationships use cases that extend the behavior of other core use cases. Enable to factor variants. generalizations of use cases use cases that are specialized versions of other use cases

Example Base use case Included use case Extending use case Base use case

Condition

Example

How to identify actor and use case? Analysis of requirements documents Analysis of the expectations of future users What are tasks of each actor ? Will any actor create, store, change, remove, or read information in the system ? What use cases will create, store, change, remove, or read this information ? Will any actor need to inform the system about sudden, external changes ? Does any actor need to be informed about certain occurrences in the system ? Can all functional requirements be performed by the use cases ?

Pitfalls Error 1: Modeling processes Error 2: Setting system boundaries incorrectly Error 3: Mixing abstraction levels Error 4: Functional decomposition Error 5: Incorrect associations Error 6: Modeling redundant use cases

Use case description

An example Use Case: Withdraw Money Purpose: To withdraw some cash from user’s bank account Overview: The use case starts when the customer inserts his credit card into the system. The system requests the user PIN. The system validates the PIN. If the validation succeeded, the customer can choose the withdraw operation else alternative 1 – validation failure is executed. The customer enters the amount of cash to withdraw. The system checks the amount of cash in the user account, its credit limit. If the withdraw amount in the range between the current amount + credit limit the system dispense the cash and prints a withdraw receipt, else alternative 2 – amount exceeded is executed.

Use case: Money withdrawal Actors: Customer Pre Condition: The ATM must be in a state ready to accept transactions The ATM must have at least some cash on hand that it can dispense The ATM must have enough paper to print a receipt for at least one transaction Post Condition: The current amount of cash in the user account is the amount before the withdraw minus the withdraw amount A receipt was printed on the withdraw amount The withdraw transaction was audit in the System log file

Use case: Money withdrawal Actor ActionsSystem Actions 1. Begins when a Customer arrives at ATM 2. Customer inserts a Credit card into ATM 3. System verifies the customer ID and status 5. Customer chooses “Withdraw” operation 4. System asks for an operation type 7. Customer enters the cash amount6. System asks for the withdraw amount 8. System checks if withdraw amount is legal 9. System dispenses the cash 10. System deduces the withdraw amount from account 11. System prints a receipt 13. Customer takes the cash and the receipt 12. System ejects the cash card

Use case: Money withdrawal Alternative flow of events: Step 3: Customer authorization failed. Display an error message, cancel the transaction and eject the card. Step 8: Customer has insufficient funds in its account. Display an error message, and go to step 6. Step 8: Customer exceeds its legal amount. Display an error message, and go to step 6. Exceptional flow of events: Power failure in the process of the transaction before step 9, cancel the transaction and eject the card

Use case: Money withdrawal Alternative flow of events: Step 3: Customer authorization failed. Display an error message, cancel the transaction and eject the card. Step 8: Customer has insufficient funds in its account. Display an error message, and go to step 6. Step 8: Customer exceeds its legal amount. Display an error message, and go to step 6. Exceptional flow of events: Power failure in the process of the transaction before step 9, cancel the transaction and eject the card

ATM Cash withdrawal

Class Diagram Use the class diagram to model the static structure of a system Describes the elements of the system and the relationships between them Class diagram allows to create a conceptual view of the system and to define the vocabulary to be used

Essential features Class Attributes Operations Relationships Associations Generalization Realization Dependency Constraint Rules and Notes

Class Describes a set of objects having similar: Attributes (status) Operations (behavior) Relationships with other classes Attributes and operations may have their visibility marked: "+" for public "#" for protected "−" for private "~" for package

Example Class Name Attributes Operations

Thank you Next Lecture: UML Diagrams