Cloud Computing:

Requirements Analysis
and the Unified Process

Dr. Engr. Sami ur Rahman

 Overview

 What is UML?
 A brief history of UML and its origins.
 Understanding the basics of UML.
 UML diagrams
 UML Modeling tools

Stratford University | School of Computer Science & Information Technology | Dr. Engr. Sami ur Rahman 2
 What is UML?
UML: Unified Modeling Language
 An industry-standard graphical language for
specifying, visualizing, constructing, and
documenting the artifacts of software systems,
as well as for business modeling.

 The UML uses mostly graphical notations to

express the OO analysis and design of software
projects.

 Simplifies the complex process of software

design

Stratford University | School of Computer Science & Information Technology | Dr. Engr. Sami ur Rahman 3
 Why UML for Modeling?

 A diagram/picture = thousands words

 Uses graphical notation to communicate more clearly
than natural language (imprecise) and code(too
detailed).
 Makes it easier for programmers and software
architects to communicate.
 Helps acquire an overall view of a system.
 UML is not dependent on any one language or
technology.
 UML moves us from fragmentation to standardization.

Stratford University | School of Computer Science & Information Technology | Dr. Engr. Sami ur Rahman 4
 History

Time
Year Version
2003: UML 2.0
2001: UML 1.4
1999: UML 1.3
1997: UML 1.0, 1.1
1996: UML 0.9 & 0.91
1995: Unified Method 0.8

Booch ‘93 OMT - 2

Other methods

Booch ‘91
OMT - 1

Stratford University | School of Computer Science & Information Technology | Dr. Engr. Sami ur Rahman 5
 Types of UML Diagrams

Use Case Diagram: capture requirements. Clarify exactly

what the system is supposed to do
Displays the relationship among actors and use cases.
Different from traditional flow chart.

Class Diagram: static relationships between classes.

Describe the types of objects in the system and various kinds
of static relationship that exist among them.

Sequence Diagram:
Displays the time sequence of the objects participating in the
interaction.

Stratford University | School of Computer Science & Information Technology | Dr. Engr. Sami ur Rahman 6
 Types of UML Diagrams (Cont.)

Collaboration Diagram
Displays an interaction organized around the objects
and their links to one another.
State Diagram
Displays the sequences of states that an object of an
interaction goes through during its life in response to
received stimuli, together with its responses and
actions.

Component Diagram
Illustrate the organizations and dependencies of the
physical components in a system. A higher level than
class diagrams.
Stratford University | School of Computer Science & Information Technology | Dr. Engr. Sami ur Rahman 7
 Use Case Diagrams

Boundary Use Case

Actor
Library System

Borrow
Employee
Client

Order Title

Fine Remittance

Supervisor

• A generalized description of how a system will be used.

• Provides an overview of the intended functionality of the system
Stratford University | School of Computer Science & Information Technology | Dr. Engr. Sami ur Rahman 8
 Use Case Diagram(core components)

Actors: A role that a user plays with respect to the

system,including human users and other systems.
e.g.,inanimate physical objects (e.g. robot); an external
system that needs some information from the current
system.

Use case: A set of scenarios that describing an interaction

between a user and a system.

Stratford University | School of Computer Science & Information Technology | Dr. Engr. Sami ur Rahman 9
 Use Case Diagram (core components)

 A use case is a single unit of meaningful work. E.g. login,

register, place an order, etc.
 Each Use Case has a description which describes the
functionality that will be built in the proposed system.
E.g. for use case “order title” , a brief description: This
use case receives orders from employee or supervisor, then
return the ordered title.
System boundary: a rectangle diagram representing the
boundary between the actors and the system.

Stratford University | School of Computer Science & Information Technology | Dr. Engr. Sami ur Rahman 10
 Use Case Diagram(core relationship)

Association: communication between an actor and a

use case; represented by a solid line.

Generalization: relationship between one general use

case and one specific use case.
Represented by a line with a triangular arrow head
toward the parent use case, the more general modeling
element.

employee
waitress

Stratford University | School of Computer Science & Information Technology | Dr. Engr. Sami ur Rahman 11
 Use Case Diagram(core relationship)

Include: a dotted line labeled <<include>> beginning at

base use case and ending with an arrows pointing to the
include use case. An “Include” relationship is used to indicate
that a particular Use Case must include another use case to
perform its function.
<<include>>

<<uses>>
or in MS Visio

A Use Case may be included by one or more Use Cases, so it

reduces duplication of functionality.
Example: the <list orders> Use Case may be included
every time when the <modify order> Use Case is run.

Stratford University | School of Computer Science & Information Technology | Dr. Engr. Sami ur Rahman 12
 Use Case Diagram (core relationship)

 Extend: a dotted line labeled <<extend>> with an arrow toward

the base case. The extending use case may add behavior to the
base use case. The base class declares “extension points”.
<<extend>>

Used when exceptional circumstances are encountered. For

example, the <get approval> Use Case may optionally extend the
regular <modify order> Use Case.

Note: other expressions. For example, in MS Visio

<<uses>> <<extends>>

Stratford University | School of Computer Science & Information Technology | Dr. Engr. Sami ur Rahman 13
 Use Case Diagrams(cont.)

(TogetherSoft, Inc)

Stratford University | School of Computer Science & Information Technology | Dr. Engr. Sami ur Rahman 14
 Use Case Diagrams(cont.)

• Pay Bill is a parent use case and Bill Insurance is the

child use case. (generalization)

• Both Make Appointment and Request Medication

include Check Patient Record as a subtask.(include)

• The extension point is written inside the base case

Pay bill; the extending class Defer payment adds the
behavior of this extension point. (extend)

Stratford University | School of Computer Science & Information Technology | Dr. Engr. Sami ur Rahman 15
 Class Diagram
 Each class is represented by a rectangle subdivided into
three compartments
 Name
 Attributes
 Operations
 Modifiers are used to indicate visibility of attributes and
operations.
 ‘+’ is used to denote Public visibility (everyone)
 ‘#’ is used to denote Protected visibility (friends and
derived)
 ‘-’ is used to denote Private visibility (no one)
 By default, attributes are hidden and operations are visible.
 The last two compartments may be omitted to simplify the
class diagrams

Stratford University | School of Computer Science & Information Technology | Dr. Engr. Sami ur Rahman 16
 An example of Class

Name
Account_Name
- Custom_Name
Attributes
- Balance
+AddFunds( ) Operations
+WithDraw( )
+Transfer( )

Stratford University | School of Computer Science & Information Technology | Dr. Engr. Sami ur Rahman 17
 C++ Class Example

class Checking {
private:
char Customer_name[20];
float Balance;
public:
AddFunds(float);
WithDraw(float);
Transfer(float);
set_name(string);
get_name();
set_balance(float);
get_balance();
};
Stratford University | School of Computer Science & Information Technology | Dr. Engr. Sami ur Rahman 18
 Notation of Class Diagram: association

Associations represent relationships between instances

of classes .
An association is a link connecting two classes.
 Bi-directional association
Associations are assumed to be bi-directional
e.g. Flight and plane
notation:

 Uni-directional association
e.g. Order and item
notation:

Stratford University | School of Computer Science & Information Technology | Dr. Engr. Sami ur Rahman 19
 Association: Multiplicity and Roles

student
1 *

University Person

0..1 *
employer teacher
Multiplicity
Symbol Meaning Role
Role
1 One and only one “A given university groups many
0..1 Zero or one people; some act as students, others
M..N From M to N (natural as teachers. A given student
language) belongs to a single university; a
* From zero to any positive given teacher may or may not be
integer working for the university at a
0..* From zero to any positive
particular time.”
integer
1..* From one to any positive
integer
Stratford University | School of Computer Science & Information Technology | Dr. Engr. Sami ur Rahman 20
 Notation of Class Diagram: Generalization

Supertype Example: Customer

Regular Loyalty
Customer Customer

Subtype1 Subtype2
or: Customer
Generalization expresses a
relationship among related
classes. It is a class that
includes its subclasses.
Regular Loyalty
Customer Customer
Stratford University | School of Computer Science & Information Technology | Dr. Engr. Sami ur Rahman 21
 Notation of Class Diagram: Composition
COMPOSITION Composition: expresses a relationship among instances
Whole Class of related classes. It is a specific kind of Whole-Part
Class W relationship.

It expresses a relationship where an instance of the

Whole-class has the responsibility to create and initialize
instances of each Part-class.

Class P1 Class P2 It may also be used to express a relationship where instances

of the Part-classes have privileged access or visibility to
certain attributes and/or behaviors defined by the
Part Classes Whole-class.

Composition should also be used to express relationship where

Example instances of the Whole-class have exclusive access to and
control of instances of the Part-classes.
Automobile
Composition should be used to express a relationship where
the behavior of Part instances is undefined without being
related to an instance of the Whole. And, conversely, the
behavior of the Whole is ill-defined or incomplete if one or
more of the Part instances are undefined.
Engine Transmission

[From Dr.David A. Workman]

Stratford University | School of Computer Science & Information Technology | Dr. Engr. Sami ur Rahman 22
 Notation of Class Diagram: Aggregation
Container Class
Class C Aggregation: expresses a relationship among instances
of related classes. It is a specific kind of Container-
AGGREGATION Containee relationship.

It expresses a relationship where an instance of the

Container-class has the responsibility to hold and
Class E1 Class E2 maintain instances of each Containee-class that have
been created
outside the auspices of the Container-class.
Containee Classes
Aggregation should be used to express a more informal
relationship than composition expresses. That is, it is an
appropriate relationship where the Container and its
Containees can be manipulated independently.
Example
Bag
Aggregation is appropriate when Container and
Containees have no special access privileges to each
other.

Apples Milk

[From Dr.David A. Workman]

Stratford University | School of Computer Science & Information Technology | Dr. Engr. Sami ur Rahman 23
 Aggregation vs. Composition
Composition is really a strong form of aggregation
• components have only one owner
• components cannot exist independent of their owner;
both have coincident lifetimes
• components live or die with their owner
e.g. (1)Each car has an engine that can not be shared
with other cars.
(2) If the polygon is destroyed, so are the points.

Aggregations may form "part of" the aggregate, but may not be
essential to it. They may also exist independent of the aggregate.
Less rigorous than a composition.
e.g. (1)Apples may exist independent of the bag.
(2)An order is made up of several products, but the
products are still there even if an order is
cancelled.

Stratford University | School of Computer Science & Information Technology | Dr. Engr. Sami ur Rahman 24
 Class Diagram example
Name Order class
-dateReceived
Multiplicity: mandatory
Attributes -isPrepaid Customer
-number :String
-price : Money
* 1 -name
-address
+dispatch() Association +creditRating() : String()
Operations +close()

1
{if Order.customer.creditRating is Generalization
"poor", then Order.isPrepaid must
be true }

Corporate Customer Personal Customer

-contactName -creditCard#
Constraint -creditRating
-creditLimit
Multiplicity: (inside braces{}}
+remind()
+billForMonth(Integer)
Many value
Multiplicity: *
optional 0..1
Employee
*
OrderLine
-quantity: Integer 1
-price: Money * Product
-isSatisfied: Boolean

[from UML Distilled Third Edition]

Stratford University | School of Computer Science & Information Technology | Dr. Engr. Sami ur Rahman 25
 Sequence Diagram: Object interaction

A B

Self-Call: A message that an Synchronous

Object sends to itself.
Asynchronous
Condition: indicates when a
message is sent. The message is Transmission
delayed
sent only if the condition is true.

[condition] remove()
Condition
*[for each] remove()
Iteration
Self-Call

Stratford University | School of Computer Science & Information Technology | Dr. Engr. Sami ur Rahman 26
 Sequence Diagrams – Object Life Spans
 Lifelines
The dotted line that extends down the
vertical axis from the base of each
object.
A
 Messages
Labeled as arrows, with the arrowhead
indicating the direction of the call. Create
B
 Activation bar
The long, thin boxes on the lifelines are
method-invocation boxes indicting that
indicate processing is being performed
by the target object/class to fulfill a
message.
Activation bar
 Rectangle also denotes when object is X
deactivated. Return
Deletion
 Deletion Lifeline
 Placing an ‘X’ on lifeline
 Object’s life ends at that point

Stratford University | School of Computer Science & Information Technology | Dr. Engr. Sami ur Rahman 27
 Sequence Diagram
Us er Message Catalog Res ervations

1: look up ()

2: title data ()

3: [not available] res erve title ()

4 : title returned ()

5: hold title ()

5 : title available ()

6 : borrow title ()

6 : rem ove res ervation ()

• Sequence diagrams demonstrate the behavior of objects in a use case

by describing the objects and the messages they pass.
• The horizontal dimension shows the objects participating in the interaction.
• The vertical arrangement of messages indicates their order.
• The labels may contain the seq. # to indicate concurrency.
Stratford University | School of Computer Science & Information Technology | Dr. Engr. Sami ur Rahman 28
 Interaction Diagrams: Collaboration
diagrams

 Shows the relationship between objects and the order of

messages passed between them.

 The objects are listed as rectangles and arrows indicate the

messages being passed.

 The numbers next to the messages are called sequence

numbers. They show the sequence of the messages as they are
passed between the objects.

 Convey the same information as sequence diagrams, but focus

on object roles instead of the time sequence.

Stratford University | School of Computer Science & Information Technology | Dr. Engr. Sami ur Rahman 29
 Interaction Diagrams: Collaboration
diagrams (cont.)

start

6: remove reservation

3 : [not available] reserve title

User Reservations

6 : borrow title 5: title available

1: look up
2: title data

4 : title returned
Catalog

5 : hold title

Stratford University | School of Computer Science & Information Technology | Dr. Engr. Sami ur Rahman 30
 CRC Card

• A collection of standard index cards, each of which is

divided into three sections; can be printed or hand-
written.

• Benefits: It is easy to describe how classes work by

moving cards around; allows to quickly consider
alternatives.
Class Collaborators
Reservations • Catalog
• User session

Responsibility
• Keep list of reserved titles
• Handle reservation

Stratford University | School of Computer Science & Information Technology | Dr. Engr. Sami ur Rahman 31
 How to create CRC cards?

 Find classes
Look for main classes first, then find relevant classes.

 Find responsibilities
Know what a class does; what information you wish to maintain about
it.

 Define collaborators
A class often needs to collaborate with other classes to get the job
done. Collaboration diagram is an example to show class relationship.

 Move cards around

Cards that collaborate with one another should be placed close
together, whereas cards that don’t collaborate should be placed far
apart.

Stratford University | School of Computer Science & Information Technology | Dr. Engr. Sami ur Rahman 32
 State Diagrams
(Billing Example)

State Diagrams show the sequences of states

an object goes through during its life cycle
in response to stimuli, together with its
responses and actions; an abstraction of all
possible behaviors.

Start End
Unpaid Paid
Invoice created payin Invoice destroying
g

Stratford University | School of Computer Science & Information Technology | Dr. Engr. Sami ur Rahman 33
 Basic rules for State Diagrams
 Draw only one object's chart at a time.

 A state is drawn as a box with rounded corners.

 From each state draw an arrow to another state if

the object can change from one to the other in
one step.

 Label the arrow with the event that causes it.

 Show the initial state by drawing an arrow from a

black filled circle to the initial state.

 Show the end state by drawing an arrow to a

circle with a filled circle inside it.
Stratford University | School of Computer Science & Information Technology | Dr. Engr. Sami ur Rahman 34
 State Diagrams
(Traffic light example)

Traffic Light Start

State
Transition Red

Yellow

Green

Event

Stratford University | School of Computer Science & Information Technology | Dr. Engr. Sami ur Rahman 35
 Component Diagram

 Illustrate the organizations and dependencies of the

physical components in a system.
 Has a higher level of abstraction than a Class diagram -
usually implemented by one or more classes.
Symbols and Notations

Components
a large rectangle with two smaller rectangles on the side.

Stratford University | School of Computer Science & Information Technology | Dr. Engr. Sami ur Rahman 36
 Component Diagram (cont.)

Interface
An interface describes a group of operations used or
created by components. It represents a declaration of
a set of coherent public features and obligations,
similar to a contract.

Dependencies

dashed arrows.

Stratford University | School of Computer Science & Information Technology | Dr. Engr. Sami ur Rahman 37
 Component Diagram (cont.)

order

customer

account

Order provides a component interface, which is a collection of one

or more methods with or without attributes.

Account and customer components are dependent upon the

interface of the order.
Stratford University | School of Computer Science & Information Technology | Dr. Engr. Sami ur Rahman 38
 UML Modeling Tools
 Rational Rose (www.rational.com) by IBM
 UML Studio 7.1 ( http://www.pragsoft.com/) by Pragsoft
Corporation
Capable of handling very large models (tens of
thousands of classes). Educational License US$ 125.00;
Freeware version.
 Microsoft Visio
 Dia: open source, much like visio.
(http://www.gnome.org/projects/dia/)
 ArgoUML (Open Source; written in java ) (
http://www.apple.com/downloads/macosx/development_to
ols/argouml.html
)
 Others (
http://www.objectsbydesign.com/tools/umltools_byCompa
ny.html
)

Stratford University | School of Computer Science & Information Technology | Dr. Engr. Sami ur Rahman 39
 Microsoft Visio

Stratford University | School of Computer Science & Information Technology | Dr. Engr. Sami ur Rahman 40
 UML studio 7.1

Stratford University | School of Computer Science & Information Technology | Dr. Engr. Sami ur Rahman 41
 Poor Design, need more heuristics!

(Radu Marinescu[5])
Stratford University | School of Computer Science & Information Technology | Dr. Engr. Sami ur Rahman 42
 A cleaner design

(Radu Marinescu[5])
Stratford University | School of Computer Science & Information Technology | Dr. Engr. Sami ur Rahman 43
 Reference

1. UML Distilled: A Brief Guide to the Standard Object Modeling Language

Martin Fowler, Kendall Scott

2. Practical UML --- A Hands-On Introduction for Developers

http://www.togethersoft.com/services/practical_guides/umlonlinecourse/

3. OO Concepts in UML. Dr. David A. Workman, School of EE and CS.

UCF.

4. Software Engineering Principles and Practice. Second Edition;

Hans van Vliet.

5. http://labs.cs.utt.ro/labs/acs/html/lectures/4/lecture4.pdf

Stratford University | School of Computer Science & Information Technology | Dr. Engr. Sami ur Rahman 44
Introduction to UML[1]

 UML is NOT a methodology

 UML is NOT a process
 UML is NOT proprietary (Now under the OMG)
 UML is strictly Notations

CS 406 Fall 2001 Requirements 45

Analysis
Stratford University | School of Computer Science & Information Technology | Dr. Engr. Sami ur Rahman 45
 Introduction to UML[2]

 Goals of UML notation

 Simple : requires only a few concepts and symbols
 Expressive : applicable to a wide spectrum of systems and
life cycle methods
 Useful : focuses only upon those necessary elements to
software engineering
 Consistent : the same concept and symbol should be applied
in the same fashion throughout

CS 406 Fall 2001 Requirements 46

Analysis
Stratford University | School of Computer Science & Information Technology | Dr. Engr. Sami ur Rahman 46
 Introduction to UML[3]

 Goals of UML notation:

 Printable
 Extensible : users and tool builders should have some
freedom to extend the notation
 UML has different parts
 Views - shows different aspects of the system that are
modeled, links the modeling language to the method/process
chosen for development
 Diagrams - graphs that describe the contents in a view
 Model elements - concepts used in a diagram

CS 406 Fall 2001 Requirements 47

Analysis
Stratford University | School of Computer Science & Information Technology | Dr. Engr. Sami ur Rahman 47
 Introduction to UML[4]

Component Logical
View View
Use
Case
View
Concurrenc
Deployment
y
View
View

9/3/01 CS 406 Fall 2001 Requirements A 48

nalysis 48
Stratford University | School of Computer Science & Information Technology | Dr. Engr. Sami ur Rahman
 Introduction to UML[5]

 Use-case view : A view showing the functionality of the

system as perceived by the external actors
 Logical view: A view showing how the functionality is
designed inside the system, in terms of the static
structure and dynamic behavior
 Component view: A view showing the organization of
the code components

CS 406 Fall 2001 Requirements 49

Analysis
Stratford University | School of Computer Science & Information Technology | Dr. Engr. Sami ur Rahman 49
 Introduction to UML[6]

 Concurrency view: A view showing the concurrency of

the system
 Deployment view: A view showing the deployment of
the system in terms of the physical architecture

CS 406 Fall 2001 Requirements 50

Analysis
Stratford University | School of Computer Science & Information Technology | Dr. Engr. Sami ur Rahman 50
Introduction to UML[9]

 Model elements
 Class
 Object
 State
 Use case
 Interface
 Association
 Link
 Package ….

CS 406 Fall 2001 Requirements 51

Analysis
Stratford University | School of Computer Science & Information Technology | Dr. Engr. Sami ur Rahman 51
 Introduction to UML[10]

 Use Case diagram: External interaction with actors

 Class/Object Diagram : captures static structural
aspects, objects and relationships
 State Diagram: Dynamic state behavior
 Sequence diagram: models object interaction over
time
 Collaboration diagram: models component interaction
and structural dependencies

CS 406 Fall 2001 Requirements 52

Analysis
Stratford University | School of Computer Science & Information Technology | Dr. Engr. Sami ur Rahman 52
 Introduction to UML[11]

 Activity diagram : models object activities

 Deployment diagram : models physical architecture
 Component diagram : models software architecture

CS 406 Fall 2001 Requirements 53

Analysis
Stratford University | School of Computer Science & Information Technology | Dr. Engr. Sami ur Rahman 53
 Case study - Point of Sale

 POS terminal should support the following

 record sales
 handle payments
 many architectural layers
 presentation
 application logic (problem domain, service support)
 persistence
 Emphasis - problem domain application
objects

9/3/01 CS 406 Fall 2001 Requirements A 54

nalysis 54
Stratford University | School of Computer Science & Information Technology | Dr. Engr. Sami ur Rahman
 Thank You !!!

Stratford University | School of Computer Science & Information Technology | Dr. Engr. Sami ur Rahman 55
Introduction to UML[1]

 UML is NOT a methodology

 UML is NOT a process
 UML is NOT proprietary (Now under the OMG)
 UML is strictly Notations

CS 406 Fall 2001 Requirements 56

Analysis
Stratford University | School of Computer Science & Information Technology | Dr. Engr. Sami ur Rahman 56
 Introduction to UML[2]

 Goals of UML notation

 Simple : requires only a few concepts and symbols
 Expressive : applicable to a wide spectrum of systems and
life cycle methods
 Useful : focuses only upon those necessary elements to
software engineering
 Consistent : the same concept and symbol should be applied
in the same fashion throughout

CS 406 Fall 2001 Requirements 57

Analysis
Stratford University | School of Computer Science & Information Technology | Dr. Engr. Sami ur Rahman 57
 Introduction to UML[3]

 Goals of UML notation:

 Printable
 Extensible : users and tool builders should have some
freedom to extend the notation
 UML has different parts
 Views - shows different aspects of the system that are
modeled, links the modeling language to the method/process
chosen for development
 Diagrams - graphs that describe the contents in a view
 Model elements - concepts used in a diagram

CS 406 Fall 2001 Requirements 58

Analysis
Stratford University | School of Computer Science & Information Technology | Dr. Engr. Sami ur Rahman 58
 Introduction to UML[4]

Component Logical
View View
Use
Case
View
Concurrenc
Deployment
y
View
View

9/3/01 CS 406 Fall 2001 Requirements A 59

nalysis 59
Stratford University | School of Computer Science & Information Technology | Dr. Engr. Sami ur Rahman
 Introduction to UML[5]

 Use-case view : A view showing the functionality of the

system as perceived by the external actors
 Logical view: A view showing how the functionality is
designed inside the system, in terms of the static
structure and dynamic behavior
 Component view: A view showing the organization of
the code components

CS 406 Fall 2001 Requirements 60

Analysis
Stratford University | School of Computer Science & Information Technology | Dr. Engr. Sami ur Rahman 60
 Introduction to UML[6]

 Concurrency view: A view showing the concurrency of

the system
 Deployment view: A view showing the deployment of
the system in terms of the physical architecture

CS 406 Fall 2001 Requirements 61

Analysis
Stratford University | School of Computer Science & Information Technology | Dr. Engr. Sami ur Rahman 61
Introduction to UML[9]

 Model elements
 Class
 Object
 State
 Use case
 Interface
 Association
 Link
 Package ….

CS 406 Fall 2001 Requirements 62

Analysis
Stratford University | School of Computer Science & Information Technology | Dr. Engr. Sami ur Rahman 62
 Introduction to UML[10]

 Use Case diagram: External interaction with actors

 Class/Object Diagram : captures static structural
aspects, objects and relationships
 State Diagram: Dynamic state behavior
 Sequence diagram: models object interaction over
time
 Collaboration diagram: models component interaction
and structural dependencies

CS 406 Fall 2001 Requirements 63

Analysis
Stratford University | School of Computer Science & Information Technology | Dr. Engr. Sami ur Rahman 63
 Introduction to UML[11]

 Activity diagram : models object activities

 Deployment diagram : models physical architecture
 Component diagram : models software architecture

CS 406 Fall 2001 Requirements 64

Analysis
Stratford University | School of Computer Science & Information Technology | Dr. Engr. Sami ur Rahman 64
 Case study - Point of Sale

 POS terminal should support the following

 record sales
 handle payments
 many architectural layers
 presentation
 application logic (problem domain, service support)
 persistence
 Emphasis - problem domain application
objects

9/3/01 CS 406 Fall 2001 Requirements A 65

nalysis 65
Stratford University | School of Computer Science & Information Technology | Dr. Engr. Sami ur Rahman
 Understanding requirements

Ref# Function Category

R1.1 Record the current Evident

sale
R1.2 Calculate current Evident
sale total
R1.3 Reduce inventory Hidden

9/3/01 CS 406 Fall 2001 Requirements A 66

nalysis 66
Stratford University | School of Computer Science & Information Technology | Dr. Engr. Sami ur Rahman
 Use cases [1]

 Excellent technique for improving the

understanding of requirements
 Narrative in nature
 Use cases are dependent on having some
understanding of the requirements (expressed in
functional specifications document).

9/3/01 CS 406 Fall 2001 Requirements A 67

nalysis 67
Stratford University | School of Computer Science & Information Technology | Dr. Engr. Sami ur Rahman
 Use Cases [2]

 Use case - narration of the sequence of

events of an actor using a system
 UML icon for use case

9/3/01 CS 406 Fall 2001 Requirements A 68

nalysis 68
Stratford University | School of Computer Science & Information Technology | Dr. Engr. Sami ur Rahman
 Actors [1]

 Actor - an entity external to the system

that in some way participates in the
use case
 An actor typically stimulates the
system with input events or receives
outputs from the system or does both.
 UML notation for actor:

C ustom er

9/3/01 CS 406 Fall 2001 Requirements A 69

nalysis 69
Stratford University | School of Computer Science & Information Technology | Dr. Engr. Sami ur Rahman
 Actors [2]

 Primary Actor - an entity external to the

system that uses system services in a
direct manner.
 Supporting Actor- an actor that provides
services to the system being built.
 Hardware, software applications, individual
processes, can all be actors.

9/3/01 CS 406 Fall 2001 Requirements A 70

nalysis 70
Stratford University | School of Computer Science & Information Technology | Dr. Engr. Sami ur Rahman
Identification of Use Cases

 Method 1 - Actor based

 Identify the actors related to the system
 Identify the processes these actors initiate or participate in
 Method 2 - Event based
 Identify the external events that a system must respond to
 Relate the events to actors and use cases
 Method 3 – Goal based
 [Actors have goals.]
 Find user goals. [Prepare actor-goal list.]
 Define a use case for each goal.

CS 406 Fall 2001 Requirements 71

Analysis
Stratford University | School of Computer Science & Information Technology | Dr. Engr. Sami ur Rahman 71
 Identification of Use Cases[2]

 To identify use cases, focus on elementary

business processes (EBP).
 An EBP is a task performed by one person in one
place at one time, in response to a business event.
This task adds measurable business value and
leaves data in a consistent state..

9/3/01 CS 406 Fall 2001 Requirements A 72

nalysis 72
Stratford University | School of Computer Science & Information Technology | Dr. Engr. Sami ur Rahman
 Point of Sale - Actors

 Actors:
 Cashier
 Customer
 Supervisor
 Choosing actors:
 Identify system boundary
 Identify entities, human or otherwise, that will interact
with the system, from outside the boundary.
 Example: A temperature sensing device is an actor for
a temperature monitoring application.

9/3/01 CS 406 Fall 2001 Requirements A 73

nalysis 73
Stratford University | School of Computer Science & Information Technology | Dr. Engr. Sami ur Rahman
 Point of Sale - Use Cases

 Cashier
 Log In
 Cash out
 Customer
 Buy items
 Return items

9/3/01 CS 406 Fall 2001 Requirements A 74

nalysis 74
Stratford University | School of Computer Science & Information Technology | Dr. Engr. Sami ur Rahman
 Common mistake

 Common error -
representing individual
steps as use cases
 Example: printing a receipt
(Why?)

9/3/01 CS 406 Fall 2001 Requirements A 75

nalysis 75
Stratford University | School of Computer Science & Information Technology | Dr. Engr. Sami ur Rahman
 High level vs. Low Level Use
cases[1]

 Consider the following use cases:

 Log out
 Handle payment
 Negotiate contract with a supplier
 These use cases are at different levels. Are they
all valid? To check, use the EBP definition.
 Log out: a secondary goal; it is necessary to do
something but not useful in itself.
 Handle payment: A necessary EBP. Hence a
primary goal.

9/3/01 CS 406 Fall 2001 Requirements A 76

nalysis 76
Stratford University | School of Computer Science & Information Technology | Dr. Engr. Sami ur Rahman
 High level vs. Low Level Use cases
[2]

 Log out: a secondary goal; it is necessary to do

something but not useful in itself.
 Handle payment: A necessary EBP. Hence a
primary goal.
 Negotiate contract: Most likely this is too high a
level. It is composed of several EBPs and hence
must be broken down.

9/3/01 CS 406 Fall 2001 Requirements A 77

nalysis 77
Stratford University | School of Computer Science & Information Technology | Dr. Engr. Sami ur Rahman
Use Case Diagram - Example

Process sale

Payment
Authorization
Cashier Handle returns
service

Process rental <<actor>>

Tax calculator

Manage
System administrator <<actor>>
security
Accounting
Manage users
system

Use Case Diagram: illustrates a set of use cases for a system.

9/3/01 CS 406 Fall 2001 Requirements A 78
nalysis 78
Stratford University | School of Computer Science & Information Technology | Dr. Engr. Sami ur Rahman
More on Use Cases

 Try to describe use cases independent of

implementation
 Be as narrative as possible
 State success scenarios (how do you measure the
success of an use case)
 A use case can have many scenarios (threads of
execution)
 Agree on a “format style” for use case description
 Name a use case starting with a verb in order to
emphasize that it is a process (Buy Items, Enter an
order, Reduce inventory)
CS 406 Fall 2001 Requirements 79
Analysis
Stratford University | School of Computer Science & Information Technology | Dr. Engr. Sami ur Rahman 79
More on Use Cases

 Document exception handling or branching

 when a “Buy Item” fails, what is expected of the system
 when a “credit card” approval fails, what is expected of the
system

CS 406 Fall 2001 Requirements 80

Analysis
Stratford University | School of Computer Science & Information Technology | Dr. Engr. Sami ur Rahman 80
A sample Use Case

Use case: Buy Items

Actors: Customer, Cashier
Type: Primary, Essential
Description: A customer arrives at a checkout with
items to purchase. The cashier records
the purchase items and collects payment.

9/3/01 CS 406 Fall 2001 Requirements A 81

nalysis 81
Stratford University | School of Computer Science & Information Technology | Dr. Engr. Sami ur Rahman
Ranking Use Cases

 Use some ordering that is customary to your

environment
 Example: High, Medium, Low
 Example: Must have, Essential, Nice to have

 Useful while deciding what goes into an increment

 Point of sale example:

 Buy Items - High
 Refund Items - Medium (Why?)
 Shut Down POS terminal - Low
CS 406 Fall 2001 Requirements 82
Analysis
Stratford University | School of Computer Science & Information Technology | Dr. Engr. Sami ur Rahman 82