BITS Pilani

BITS Pilani
Hyderabad Campus

Dr.Aruna Malapati Asst Professor Department of CSIS

BITS Pilani
Hyderabad Campus

Object Oriented Design USE CASE and class diagram

Todays Agenda
Use Cases The Benefits of Use Cases Strengths and Weaknesses Use case symbols & Use case diagrams Class diagrams

CS/IS F213 First Semester 2012-13

BITS Pilani, Hyderabad Campus

Use Cases
Support requirements engineering activities and the requirement process. Capture what a system is supposed to do, i.e., systems functional requirements. Describe sequences of actions a system performs that yield an observable result of value to a particular actor. Model actions of the system at its external interface. Capture how the system coordinates human actions.
CS/IS F213 First Semester 2012-13 BITS Pilani, Hyderabad Campus

The Benefits of Use Cases

Relatively easy to write and easy to read Comprehensible by users Engage the users in the requirements process Force developers to think through the design of a system from a user viewpoint Identify a context for the requirements of the system Critical tool in the design, implementation, analysis and testing process Rapid change allows exploratory approach Serve as inputs to the user documentation

CS/IS F213 First Semester 2012-13

BITS Pilani, Hyderabad Campus

Use Cases: Strengths and Weaknesses

Strengths Capture different actors views of the system Capture some structures in requirements Are comprehensible by nave users Weaknesses Lack of non-functional requirements Lack of what the system shall not do

CS/IS F213 First Semester 2012-13

BITS Pilani, Hyderabad Campus

Use Cases at a Glance

CS/IS F213 First Semester 2012-13

BITS Pilani, Hyderabad Campus

Use Case
A Use Case is an interaction between the system and a person or another system to achieve a result. A required bit of functionality. It yields an observable result of value to an actor (and hence a developer).

Typically named with a verb than a noun

Do something to something

View Timetable
CS/IS F213 First Semester 2012-13 BITS Pilani, Hyderabad Campus

Actors
A coherent set of roles that users of Use Cases play when interacting with Use Cases Roles not users or people User may have more than one role

Smith

Lecturer

CS/IS F213 First Semester 2012-13

BITS Pilani, Hyderabad Campus

Actors

CS/IS F213 First Semester 2012-13

BITS Pilani, Hyderabad Campus

Relationships
A semantic connection among elements Used to show:
A function required by an actor Relationships between actors

Relationships between use cases

Some people also use external relationships

Relationships between things that do not directly interact with the system Out of scope?

CS/IS F213 First Semester 2012-13

BITS Pilani, Hyderabad Campus

Use Case Diagram

A diagram that shows a set of Use Cases and Actors and their relationships Use Case diagrams address a user-centric view of a system Show a required bit of functionality

Person

View Timetable

CS/IS F213 First Semester 2012-13

BITS Pilani, Hyderabad Campus

Scenario / System Boundary

Scenario

A single path through a Use Case

Use case is usually a collection of scenarios Included as part of use case description

System Boundary
A high level indication of the domain Limit to investigation
System Part of system in focus

CS/IS F213 First Semester 2012-13

BITS Pilani, Hyderabad Campus

Exercise 1 Use Case Diagram

Draw a use case diagram for the space invader game below:
Move Left Move Right Fire Laser Player View High Scores

Play Game

CS/IS F213 First Semester 2012-13

BITS Pilani, Hyderabad Campus

Solution

Move Left Move Right Fire Laser Player View High Scores

Play Game

CS/IS F213 First Semester 2012-13

BITS Pilani, Hyderabad Campus

Relationships in use cases

Between actor and use case
Actor uses

Generalisation of actors
Types of users

Use case stereotypes

<<extend>>

Optional
<<include>>

Mandatory Stereotype is a UML extension mechanism to indicate a type of behaviour

CS/IS F213 First Semester 2012-13 BITS Pilani, Hyderabad Campus

Generalization of Actors
CMS

CS/IS F213 First Semester 2012-13

BITS Pilani, Hyderabad Campus

Use case of ATM machine

CS/IS F213 First Semester 2012-13

BITS Pilani, Hyderabad Campus

Case study
System has to run on an automated teller machine. User must be able to deposit checks into the account. User must be able to draw money from the account. User should be able to query the balance of his/her account. The user should get a receipt for a transaction on request. The transaction type (withdrawal or deposit), the transaction date, the account number, the amount, and the new balance should be visible on the receipt. After each transaction the new balance should be displayed to the user.

CS/IS F213 First Semester 2012-13

BITS Pilani, Hyderabad Campus

Common errors
connection between actors and use cases have no direction Connections between use cases are dotted ( ) and should be labeled <<extend>> or <<include>> <<extend>>: arrow points from use case describing the alternative event flow to the standard case <<include>>: arrow points from calling use case to use case that describes actions to include

CS/IS F213 First Semester 2012-13

BITS Pilani, Hyderabad Campus

Use Case description

Use case: withdraw Precondition: User has selected withdraw option Main flow: Include (Verify user) Prompt user for amount to withdraw Check available funds of user Check available money of ATM Remove amount from account Give money (print receipt) Print current balance Exceptional flow If not sufficient funds or money available, prompt user for lower amount
CS/IS F213 First Semester 2012-13 BITS Pilani, Hyderabad Campus

Use Case description

Use case: deposit Precondition: User has selected deposit option Main flow: Include (Verify user) Prompt user for amount of deposit Open slot Get check (print receipt) Print (balance + deposited amount)

CS/IS F213 First Semester 2012-13

BITS Pilani, Hyderabad Campus

Use Case description

Use case: check balance Precondition: User has selected balance option Main flow: Include (Verify user) Print balance

CS/IS F213 First Semester 2012-13

BITS Pilani, Hyderabad Campus

Acceptable solution
<<extend>> (print receipt)

withdraw
check balance

withdraw with receipt

User

deposit

<<extend>> (print receipt)

deposit with receipt

CS/IS F213 First Semester 2012-13

BITS Pilani, Hyderabad Campus

Good solution
<<extend>> (print receipt)
<<include>> check balance <<include>> Verify user

withdraw

withdraw with receipt

User

<<include>> deposit <<extend>> (print receipt) deposit with receipt

CS/IS F213 First Semester 2012-13

BITS Pilani, Hyderabad Campus

Class Diagrams
Class Diagrams are a standard visual representation to the following aspects: Classes and Interfaces

Fields
Methods Sub-type and sub-class relations (Inheritance) Abstract and concrete methods and classes
CS/IS F213 First Semester 2012-13 BITS Pilani, Hyderabad Campus

Class Diagrams
Classes are marked with a boxed text. A class box may have up to three compartments: 1 The class name 2 Fields 3 Methods

CS/IS F213 First Semester 2012-13

BITS Pilani, Hyderabad Campus

Visibility
A set of prefixes for attributes and methods
+ public visible to any class
# protected visible to any subclass

private visible only to class itself

~ package visible to any class within enclosing package

Visibility is a class feature. It is found only in class diagrams.

CS/IS F213 First Semester 2012-13

BITS Pilani, Hyderabad Campus

Constraint
Now, suppose ALL our 2D points must have an (x,y) coordinate such that both x and y are between 0 and 10 This is a constraint.

CS/IS F213 First Semester 2012-13

BITS Pilani, Hyderabad Campus

Static Members
Static members of a class (either attributes or methods) exist at the class level. They can be used without instantiated an object. In UML, these are underlined.

CS/IS F213 First Semester 2012-13

BITS Pilani, Hyderabad Campus

Inheritance
The relation B inherits from A is marked with a largeheaded triangular arrow, possibly to several sub-classes.

CS/IS F213 First Semester 2012-13

BITS Pilani, Hyderabad Campus

Abstract and Concrete Classes

Abstract classes (or interfaces) and abstract methods are marked italized, or with a star. Concrete classes and methods are marked regularly, or with a plus The relation B implements A is marked like inheritance, but dashed CS/IS F213 First Semester 2012-13

BITS Pilani, Hyderabad Campus

Summary
Use Cases in UML capture (to a certain extent) system requirements and support requirements engineering activities and processes Use Case notations and examples Describing use cases

Developing use cases

CS/IS F213 First Semester 2012-13

BITS Pilani, Hyderabad Campus