cs212: object oriented analysis and design lecture 32: use case and class diagrams

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

Upload: francis-marsh

Post on 18-Jan-2016

222 views

Category:

Documents


0 download

TRANSCRIPT

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

CS212: Object Oriented Analysis and DesignLecture 32: Use case and Class

diagrams

Page 2: 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

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

Outline of Lecture 32

• UML

• Use case diagram

• Class diagram

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

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

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

Use case diagram

• What is being described? (The system.)

• Who interacts with the system? (The actors.)

• What can the actors do? (The use cases.)

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

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.

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

System

• The set of all use cases together describes the functionality that a software system provides

• The set of all use cases together describes the functionality that a software system provides

Query student

data

Issue certificate

Announce Exam

Student Administrationsystem

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

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

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

Example

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

Type of Actors

• Human/non-human

• Active/passive

• Primary/ Secondary

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

Example

Active vs. Passive Active vs. Active

Primary vs. Secondary Primary vs. Secondary

Human

Non-Human

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

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.

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

Association: Example

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

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

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

Relationships between Actors

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

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

A word of caution

Generalization: actors that are specialized versions of other actors

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

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

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

Example

Base use case

Included use case

Extendinguse case

Base use case

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

Condition

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

Example

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

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 ?

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

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

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

Use case description

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

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.

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

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

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

Use case: Money withdrawal

Actor Actions System Actions1. 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 amount 6. 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

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

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

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

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

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

ATM Cash withdrawal

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

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

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

Essential features

• Class

• Attributes

• Operations

• Relationships• Associations• Generalization• Realization

• Dependency

• Constraint Rules and Notes

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

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

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

Example

Class Name

Attributes

Operations

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

Thank youNext Lecture: UML Diagrams