“Systems Analysis and Design, I”

LECTURE 7:
The Object-Oriented Approach to
Requirements

1
Lecture Outline
 Unified Modeling Language (UML)
 Object-Oriented Requirements (OOR)
 System Activities
 Use Case Diagram
 Activity Diagram
 System Sequence Diagram
 State Machine Diagram
 Integrating Object-Oriented Models

2
The Domain Model Class Diagram

 Unified Modeling Language (UML) diagram

 de facto standard for models used with
object-oriented system development
 Domain model class diagram is a model to
show classes of objects
Models things in the users’ work domain
Used to define requirements for OO (very similar
to entities in ERD)
Class is the type or classification to which all
similar objects belong (e.g. guitar and violin
objects both belong to class “stringed
instruments”) 3
UML Class Symbol
 The class symbol is a rectangle
 The top section of the rectangle is the
name of the class
 The middle section is the attributes of the
class
 The bottom section lists the methods of
the class (methods define the behavior of
objects of the class). Methods are not
always shown as far as they are standard.

4
UML Class Symbol

5
 Class Diagram
 Classes, associations among classes and
attributes of classes are modeled using a class
diagram
 The class diagram shows some of the behaviors
of objects of the class, called method
 Methods of a class are the behaviors all objects
in the class are capable to do.
 A behavior is an action that the object processes
itself, when asked to do so by sending it a
message from another object
 Since each object contains values for attributes
and methods for operating on those attributes
(plus other behaviors), an object is said to be
encapsulated (i.e., a self-contained and
protected unit) 6
Simple Domain Model Class
Diagram

7
Simple Domain Model Class
Diagram (continued)
 No methods shown in domain model
 Domain classes are not software
classes
 Very similar to ERD
 UML and domain model can be used in
place of ERD in traditional approach

8
Multiplicity of Associations

9
University Course Enrollment
Domain Model Class Diagram

10
Refined Model with Association
Class and Grade Attribute

11
More Complex Class Concepts

 Generalization/specialization
hierarchies
 Inheritance
 Aggregation

12
Generalization/Specialization
 Generalization means grouping similar types of
things (e.g., motor vehicles group cars, trucks and
tanks. They share certain general features (e.g.,
wheels, engine, etc.), so motor vehicle is a more
general class)
 Specializations are judgments that categorize
different types of things (e.g., sports car is a
special type of car)
 A generalization/specialization hierarchy is
used to structure (or rank) things from the more
general down to the more special
 Each class has a more general class above it – a
superclass
 A class may have a more specialized class below –
a subclass
13
A Generalization/Specialization
Class Hierarchy for Motor Vehicles

14
A Generalization/Specialization
Class Hierarchy for RMO Orders

15
 Inheritance
 Inheritance is a concept that allows subclasses
to share characteristics of their superclasses
• E.g. a sports car has everything a car has (e.g., 4
wheels and an engine, which it inherits from the
class car which is above it)
• The sports car then specializes
–E.g., has a sports option, racing wheels, etc.
• In the object-oriented approach, inheritance is a
key concept that is possible because of
generalization/specialization hierarchies (these
hierarchies are often called inheritance
hierarchies)
16
Whole-Part Hierarchies

 Whole-part hierarchies – relationships

that structure classes by components
 Aggregation – whole-part relationships
between and object and its removable parts
Parts can exist separately
Like car and its tires
 Composition – whole-part relationships
between and object and its non-removable
parts.
Parts cannot exist separately
Like Hand is composed of fingers and thumb
17
Whole-Part Aggregation
Relationships

18
Class Diagram Example: Bank
Account
• Bank account system includes a generalization/specialization
hierarchy:
– Account is the superclass
– SavingsAccount and CheckingAccount are subclasses of
Account
– A triangle on the line connecting classes indicates
inheritance (the subclasses inherit attributes and behaviors from
the superclass Account like having an account number)
• But Savings and Checking accounts are also specialized
• A SavingsAccount “knows” how to calculate interest but a
checking account doesn’t (so they have different methods and
attributes, although they share things they inherit from class
Account)

19
Class Diagram Example: Bank
Account
• The Customer class and the Account class are associated
– Each customer can have zero or more accounts (the
diagram shows the minimum and maximum cardinality on the
line connecting the classes, and the asterisk means “many”
– Each account is owned by one and only one customer
• The SavingsAccount and CheckingAccount classes inherit
the association with the Customer class
• The Account class is an abstract class (i.e., the class that
cannot be instantiated, existing only to allow subclasses to
inherit its attributes, methods and associations) – shown in italics
• SavingsAccount, CheckingAccount and Customer are
examples of class are concrete classes that can be
instantiated (i.e., objects can be created)

20
A bank account system class
diagram

21
Association Class

• If the association itself has attributes

and/or methods, it can be represented by
an association class (represents many-
to-many relationships)
• Multiplicity of the association between
CourseSection and Student is many-to-
many. A dashed line connects the
association line to the association class
named CourseEnrollment that has the
grade attributes
22
University course enrollment class
diagram with an association class

23
The RMO Domain Class Diagram

• A generalization/specialization hierarchy
is included to show three types of orders –
web order, telephone order and mail
order, which share the attributer listed for
Order class, but each special type of order
has some additional attributes
• This diagrams shows no methods
• The initial class diagram developed during
the systems analysis phase includes no
methods. As behaviors of objects are
further developed (during analysis and
design) methods are added
24
RMO
Domain
Model
Class
Diagram

25
TA vs. OOA: Requirements modeling
• The requirements models are quite different depending
on approach used by the team: traditional or object-
oriented (the two key concepts – events and things)
• Traditional approach: based on the event table creates
a set of data flow diagrams (DFDs); the entity-relationship
diagram (ERD) defines the data storage requirements that
are included in the DFDs, views a system as a collection of
processes. When the process executes it interacts with
data. So, emphasizes processes, data, input/outputs
• Object Oriented approach: based on the event table
creates class diagrams, views a system as a collection of
interacting objects with their own behaviour (methods).
There are NO conventional processes and data files, just
interacting objects
26
Unified Modeling Language (UML)

• OOA considers an IS as a set of objects that work together to carry out

the function. OO analysis involves two steps:
(1) Definition the set of objects that will make up the system and
describing the interactions or communications among the various
objects (these interactions take the form of messages between
objects)
(2) Describing the internal processes that go on within each object to
respond to messages from other objects, and to initiate messages
to other objects
• UML is a notation used in OO modeling
• A preliminary version of UML was presented in 1995
• In 1997 UML was presented to the Object Management Group
(OMG) as a standard modeling technique
• OMG (est. 1989) is a consortium of software vendors, developers and
organization with the goal to provide a common architectural
framework for OO applications – www.omg.org
27
Object-Oriented Requirements
(OOR)
 Object-oriented system requirements are specified
and documented through process of building
models

 Modeling process starts with identification of use

cases and problem domain classes (things in
users’ work environment)

 Business events trigger elementary business

processes (EBP) that new system must address
as use cases

 Use cases define functional requirements 28

OOR - Models

OO models (or diagrams) to define system

requirements are called use case models:
• Use case diagram shows the various user roles and how they will
use the system. It is an extension of the event table. It is a convenient
way to document the function that the system must support.
• Sequence diagram shows inputs and outputs and sequence of
messages between an external actor and the system objects during a
use case or scenario.
• The flow of information between the objects is in form of messages
OO models (or diagrams) to define classes of objects
and their states are called domain models :
• Domain class diagram (see lecture 5) – identifies and classifies the
objects that will make up the new system along with their properties (or
attributes)
• State machine diagram describes the states and behavior of each
object: life of an object in state and transitions 29
The System Activities—
A Use Case/Scenario View
 Use case model used to identify and define all
elementary business processes that system must
support
 Use cases are identified at two levels:
Overview level (event table and use case diagram of all the
use cases)
Detailed level (for each use case – use case description,
activity diagram, sequence diagram)
 Use case – an activity a system carried out, usually in
response to a user request
 Actor (person, other system, or device that receive services
from the system and who actually interact with the
system)
Role played by user
30
Outside automation boundary
Techniques for Identifying Use
Cases (Review from Chapter 5)
 Identify user goals
Each goal at the elementary business process (EBP) level
is a use case

EBP – task performed by one user in one place and in

response to business event that adds measurable
business value, and leaves system and data in consistent
state

 Event decomposition technique (event table)

 CRUD analysis technique (create, read/report,
update, delete) to ensure coverage
31
 Use Case Diagram
 Graphical UML diagram that summarizes information about
actors and use cases

 Simple diagram shows overview of functional

requirements

 Symbols: use case is symbolized by an oval with the name of

the use case inside; stick figure represents an actor (i.e., a
role)

 Two approaches to use case diagrams

By subsystem

By actor
32
Simple Use Case with an Actor

33
Use Case Diagram with
Automation Boundary and
Alternate Actor Notation

34
All Use Cases Involving Customer
as Actor

Direct access
to the system

35
A use case diagram
of the CSS for RMO
organizes by
subsystems

36
Use Cases of RMO Order Entry
Subsystem

A packaged notation is used: a tabbed rectangle that groups similar

component together 37
<<Includes>> Relationship

 Documents situation in which one use case

requires the services of a common subroutine

 Another use case is developed for this common

subroutine

 A common use case can be reused by multiple use

cases

 E.g., two use cases “Create new order” and

“Update order” may need to validate the customer
account. A common use case may be defined to
carry out this function 38
Example of Order-Entry
Subsystem with <<Includes>>
Use Cases

39
Use Case Diagram vs. Structured
Techniques
• Objective of the use case diagram is to provide an overview of the
system (including actors and the functions they perform)
– A use case diagram is like a context diagram in the sense of
defining the scope of the system
– However, individual use cases appear more like a DFD fragment in
that they identify an individual function that the system must support
• Difference with structured techniques
– The use case diagram begins by defining the automation
boundary while in DFD this boundary is often not defined until the
entire process has been detailed
– In a DFD an external agent is always the original source or
destination of the information and may not necessarily be the one
interacting with the system;
– In a use case diagram, an actor is the one who actually
interacts with the system whether or not that actor is the original 40
source of information
Use Case Diagram vs. Structured
Techniques (cont’d)
Example: in the RMO case, a customer may call an RMO clerk
and make an order.
The DFD would identify the external entity as the customer; the
clerk’s activity would be embedded in a process “Enter customer
order”.
In the use case diagram, the clerk would be identified as the
actor who uses the system to enter or create a customer order
The use case diagram does not indicate data flows, i.e.
information flowing into and out of the system is not shown (this
is done with the next level of modeling – the sequence diagrams)
Important to identify every possible role that will use the
system.

41
Developing a Use Case Diagram
Two main approaches to developing a use case diagram:
First approach: start with an event table and analyze each event to
determine:
• How the system is used to support the event
• The actors who initiate the event
• Other use cases that will need to be invoked
• Generally, each event will become a use case
Second approach: identifying all the actors who use the system and the
EBPs with the user goal technique
 Actors must actually contact the system
 Assume perfect technology condition (no technical activities!)
 Actors – are roles played by users (e.g., order clerk, manager)
 Identify goal for each actor (e.g., “accept a return”)

Finalize with a CRUD analysis to ensure completeness (every class has

sufficient use cases to support its all methods) – a cross-check!

42
Scenarios

• A use case only shows that an actor interacts with the system to carry
out a business activity
• There may be a whole series of individual steps to accomplish the use
case (these steps are described with a narrative called a flow of
activities) - steps within a use case
• A use case may have several alternative internal activities. In the RMO
example, for the use case “Create new order” there are at least two
sequences when:
– A customer creates telephone order through clerk (a clerk
interacts with the system), or
– A customer creates web order (a customer interacts with the
system)
• A particular sequence of activities within a use case is called
scenario. It represents a unique path through the use case
E.g., two possible scenarios for the RMO use case “Create new order”:
in the first instance, the second actor “Order clerk” is involved who is
actually interfacing with the system
43
Two scenarios for RMO
“Create new order”

44
Activity Diagrams
 Used to document workflow of business process
activities for each use case or scenario

 Standard UML 2.0 diagram as seen in Chapter 4

 Can support any level of use case description; a

supplement to use case descriptions

 Helpful in developing system sequence

diagrams

45
Activity
Diagram—
Telephone
Order
Scenario

46
Activity
Diagram—
Web Order
Scenario

47
Identifying Inputs and Outputs—
The System Sequence Diagram
 Interaction diagram – a communication diagram or a
sequence diagram
 System sequence diagram (SSD) is type of UML 2.0
interaction diagram
 Used to model input and output messaging requirements
for a use case or scenario
 Shows sequence of interactions as messages to/from actors
and internal objects during flow of activities
 Emphasis: how the actor interacts with the system by
entering input data and receiving output data
 Object notation instead of class notation is used to show
that message is sent to an individual object, not the class
 System is shown as one object: a “black box”
48
Object and class names in SSD

49
SSD Notation

 Lifeline or object lifeline is a vertical dashed line

under object or actor to show the sequence of
messages over time: from top to bottom
 Message is labelled on arrows to show messages
sent to or received by actor or system, including
input data: request operation in the destination
object
 Actor is role interacting with the system with
messages
 Object is the component that interacts with
actors and other objects

50
System Sequence Diagram (SSD)
Notation

51
SSD Notation

Activation line 52
SSD Lifelines

 Vertical line under object or actor

Shows passage of time
 If vertical line dashed
Creation and destruction of thing is not
important for scenario
 Long narrow rectangles
Activation lifelines emphasize that object
is active only during part of scenario

53
SSD Messages

 Internal events identified by the flow of objects in a

scenario
 Requests from one actor or object to another to do
some action
 Invoke a particular method
 Input message – solid line
 Return message – dashed line
 Complete syntax:

* [true/false condition] return-value := message-name

(parameter list) 54
SSD for the RMO Look up item
availability

55
Repeating
Message

56
Developing a System Sequence
Diagram

 Begin with detailed description of use case

from fully developed form or activity
diagram
 Identify input messages
 Describe message from external actor to
system using message notation
 Identify and add any special conditions on
input message, including iteration and
true/false conditions
 Identify and add output return messages 57
Activity Diagram of the Telephone
Order Scenario

58
Resulting SSD for the Telephone
Order Scenario

59
SSD of the
Web Order
Scenario for
the Create
New Order
Use case

60
The relationship of use case
diagram, class diagram and
sequence diagrams

SSD includes objects from the class diagram and actors from the use
case diagram 61
Developing a System Sequence
Diagram: Steps

1. Identify all the objects and actors that are involved in the
scenario (they are only actors have been identified in the use
case diagram and objects from the classes that are identified
in the class diagram)
2. Based on the flow of activities, identify each message that
will be required to carry out the scenario along with both
source object (or actor) for the message and the destination
object (or actor)
3. Determine whether each message is always sent or sent only
under certain conditions
4. Sequence the messages correctly and attach them to the
appropriate lifelines of actors and objects
5. Add the formal syntax on the messages for conditions,
message names and passed parameters
6. Add response messages and communications 62
A complete
SSD for
the RMO
use case
Create new
order

63
Just for Fun!

http://www.visualjokes.com
64
Identifying Object Behaviour—
The State Machine Diagram (SMD)
 SSDs give external view of object behaviour – messages
passed around but do not show, what an object does when it
gets a message
 There is a need to specify internal logic for each object,
i.e., a description of the actions that the objects perform
themselves
 State machine diagram is UML a 2.0 diagram that models
object internal behaviour, states and transitions
Complex problem domain classes can be modeled

 Each object is an instance of a class, and comes into

existence in some manner
 During its existence it is “in” certain states and makes
transitions from state to state
 These states and the changes an object makes from state to
state are shown in SMD (two main symbols: state and
transitions) 65
Identifying Object Behaviour—
The State Machine Diagram
 State of an object
 A condition that occurs during its life when it satisfies some
criterion, performs some action, or waits for an event
 Each state has unique name (e.g., “on”, “working”, “loading
equipment”, etc.) and is a semipermanent condition or status
(because external events can interrupt them)
 Action is an activity performed by an object in a particular state
 A state is represented by a rectangle with rounded corners (with
the name of the state inside)
 Any actions that must be performed during the period of the state
are placed below the state name in the rectangle
 Transition - movement of an object from one state to
another state
 Considered to be short in duration and cannot be interrupted
 Once started, a transition runs to completion by taking the
object to the new state (called destination state) 66
Simple SMD for a Printer

67
State Machine Terminology

 Pseudostate – the starting point of a state machine,

indicated by a black dot
 Origin state – the original state of an object from
which the transition occurs
 Destination state – the state to which an object
moves after the completion of a transition
 Message event – the trigger for a transition, which
causes the object to leave the origin state
 Guard condition – a true/false test to see whether a
transition can fire
 Action expression – a description of the activities
performed as part of a transition
68
Composite States and
Concurrency—States within a
State

69
Concurrent Paths for Printer in
the On State

70
Relationships among OO models 71
State Machine Diagram and SSD

•Each column is labelled with the name of a class (the columns

identify all of the classes in the system); each row is for one sequence
diagram; the Xs in the cells show which classes are involved in which
sequence diagram).
• An SMD for a class is based on the entire column for that class
• Every cell with X provides information about the messages to and
from the class
72
Rules for Developing State
Machine Diagram
 Review domain class diagram, select important
ones, and list all state and exit conditions
 Begin building state machine diagram fragments
for each class
 Sequence fragments in correct order and review
for independent and concurrent paths
 Expand each transition with message event,
guard-condition, and action-expression
 Review and test each state machine diagram

73
States and Exit Transitions for
OrderItem

74
Partial State Machine for
OrderItem

75
Final State Machine for OrderItem

76
Order Domain Class for RMO—
States and Exit Transitions

77
First-Cut State Machine Diagram
for Order

78
Second-Cut State Machine
Diagram for Order

79
Integrating Object-Oriented
Models
 Complete use case diagram is needed to
understand total scope of new system
 Domain model class diagrams should also be as
complete as possible for entire system
 With iterative approach, construct use case
descriptions, activity diagrams, and system
sequence diagrams for use cases in iteration
 Development of a new diagram often helps refine
and correct previous diagrams

80
Relationships Between OO
Requirements Models

81
 Readings

Today’s lecture: Chapter 7 – “The Object-

Oriented Approach to Requirements”

!!
u!
yo
nk

For next lecture: Chapter 8 – “Evaluating

a
Th

Alternatives for Requirements,

Environments, and Implementation”

82