Lecture 7 – Chapter 7

The Object-Oriented Approach to

Requirements

1
 Object-Oriented Analysis

• Object-oriented viewpoint
– Consists of objects that work together, or collaborate to
carry out functions
• Unified Modeling Language (UML)
– In 1997 presented to the Object Management Group
(OMG) as a standard modeling technique
– Based on work by Booch, Rumbaugh and Jacobson
– UML has become a standard

2
 Object-Oriented Requirements
• Types of OO diagrams
– Class diagram
– The use case diagram
• Shows “uses” of the new system
– The collaborative diagram
• Shows how objects “collaborate”
– The sequence diagram
• Shows sequencing of messaging
– The statechart diagram
• Describes the states and behaviour of objects

OO Requirements = Event Table + Class Diagram + Use Case Diagrams

+ Interaction Diagrams (collaboration and/or sequence diagrams) +
Statechart Diagram 3
 Review – Differences between traditional
structured and the OO approach
• SDLC for both has same phases
• Both approaches begin with the event table
– Require identification of “events”
• Both require identification of “things”
• Main difference
– The diagrams or models used are quite different

4
5
 The Class Diagram
• There are two kinds of descriptions of systems
– Structural information (components of the system)
– Behavioral information (logic performed by components)
• Class diagram provides definition of structural
components of the system
• The other OO diagrams (e.g. use case, sequence,
collaboration) focus on activities the system performs
• NOTE – with OO Analysis the class diagrams to describe
system requirements can map very closely to the structure
(i.e. classes) in the OO computer program that will be
eventually created
6
 Generalization/Specialization Hierarchies
• Hierarchies that structure or rank classes from the
more general superclass to the more specialized
subclasses (sometimes called inheritance hierarchies)
• Generalizations
• group similar types of things like all cars share certain
features (e.g. all cars have wheels, engine etc.)
• Specializations
• are judgments that categorize different types of things
(e.g. sports car is a special type of car)
• A generalization/specialization hierarchy structures
things from the 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 7
8
9
 Inheritance
•Inheritance: 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.

10
 Aggregation (Whole-Part Hierarchies)

•Can also structure things by defining them in terms

of parts
•Aggregation: A relationship between and object
and its parts
•E.g. aggregation in the context of a computer
system, a computer system is made up of:
- processor, main memory, keyboard, disk storage, monitor

11
12
Example of Class Diagram Notation

13
Another Example of Class Diagram Notation

14
 The Use Cases and Actors

• Use Case – a single use or function performed by

the system for those who use the system
– Describes the activity the system carries out in response
to an event
– E.g. examples of use cases for word processing
• “write a letter”, “print a letter”
– Two related concepts
• A person is involved, the person uses the system
• Actor: a role played by a user of the system (a stick figure)
– E.g. For RMO, use case “Create new order” might
involve a sales representative talking to the customer
on the phone
15
16
 Scenarios

• There may be a whole series of individual steps to

accomplish a use case
• Scenario
– A particular sequence of activities within a case
– NOTE - one use case may have several different
scenarios
• In the RMO example, for the use case “Create new
order” there are at least two scenarios
– “Customer creates telephone order”
– “Customer creates web order”
• Describe individual steps with a narrative called a
flow of activities 17
18
 The Use Case Diagram

• A graphical model that summarizes the

information about the actors and use cases
• The use cases derive from the events in the event
table
• Can think of it as a functional description of the
system
– Identifies functions to be supported by the system
• Fig. 7-4 (next slide) shows a use case with a
second actor and additional use cases
– Order-entry subsystem
• The boundary line is the automation boundary
19
20
 Use Case (continued)

• Fig. 7-5 (next slide) shows the 14 use cases for

external events (triggered by external actors) for
RMO example – order entry subsystem
• Note that internally triggered events are often not
represented by use case diagrams

21
22
 Use Case (continued)

• Another approach
– Draw all the use cases that involve a specific actor
– See Fig. 7-6 (next slide)
– Shows all the use cases for the customer actor
– Useful in this example for showing all the activities
that are accessible through the Internet

23
24
 Use Case (continued)
• <<Includes>> Relationships
– It may be necessary for one use case to use the services
of another case
• E.g. the use case called “Create new order” may need to
validate the customer account (with an additional use case
called “Validate customer account”
• This relationship is:
– Create new order <<includes>> Validate customer account
• Sometimes this is referred to as the <<uses>> relationship
• Some use cases have external actors and other use cases
reference a use case

25
26
 Example of Use Cases For Development of
Point-of-Sale Terminal Software
STEP 1: Identify Actors and Use Cases

Actors Use Cases

Cashier
Customer Buy Items
Refund Items
Manager Start Up
System Administrator Add New Users

27
 STEP 2:Draw a Use Case Diagram

Buy Items

Customer
Cashier
Refund
Items

Start Up

Manager
Add New
Users
System 28
Administrator ETC.
 The Use Case Diagram Compared to
Structured Techniques
• Objective of the use case diagram
– To provide an overview of the system (including actors
and the functions they perform)
– A use case diagram in this sense is like a context diagram
– However, more like DFD fragments in that they identify
an individual function
• Difference with structured techniques
– The use case diagram begins by defining the automation
boundary – in DFD this boundary is often not defined
– The use case diagram does not indicate data flow (this is
done with other types of OO diagrams)
29
 Development of a Use Case Diagram

• 2 ways of developing a use case diagram

– Start with an event table and analyze each event to
determine:
• How the system is 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
– OR, start by identifying all the actors who use the system
• Build a list of actors based on the event table by looking at the
Trigger and Source columns
• Instead of listing as e.g. Bob or Mary, may want to identify the
specific roles that people play (e.g. clerk, doctor etc.)
• Once the actors and use cases are identified next step
is to develop a flow of activities as the starting for
identifying the various scenarios 30
  Finalize with a CRUD analysis to ensure completeness

RMO Activity-Data Matrix (CRUD)

Figure 6-34
Systems Analysis and Design in a Changing World, 5th Edition 31
 Activity Diagrams
• Used to document workflow of business
process activities for each use case or scenario

• Standard UML 2.0 diagram

• Can support any level of use case description; a

supplement to use case descriptions

• Helpful in developing system sequence

diagrams
32
 Activity
Diagram—
Telephone
Order
Scenario

Figure 7-8
Systems Analysis and Design in a Changing World, 5th Edition 33
 Activity
Diagram—
Web Order
Scenario

Figure 7-9
Systems Analysis and Design in a Changing World, 5th Edition 34
 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
during flow of activities
• System is shown as one object: a “black box”
Systems Analysis and Design in a Changing World, 5th Edition 35
 SSD Notation
• Lifeline or object lifeline is a vertical line under
object or actor to show passage of time for
object
• Message is labeled on arrows to show messages
sent to or received by actor or system
• Actor is role interacting with the system with
messages
• Object is the component that interacts with
actors and other objects

Systems Analysis and Design in a Changing World, 5th Edition 36

 System Sequence Diagram (SSD)
Notation

Figure 7-10
Systems Analysis and Design in a Changing World, 5th Edition 37
 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

Systems Analysis and Design in a Changing World, 5th Edition 38

 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

Systems Analysis and Design in a Changing World, 5th Edition 39

 Repeating
Message

Figure 7-11
Systems Analysis and Design in a Changing World, 5th Edition 40
 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
Systems Analysis and Design in a Changing World, 5th Edition 41
 Activity Diagram of the
Telephone Order Scenario

Figure 7-12
Systems Analysis and Design in a Changing World, 5th Edition 42
 Resulting SSD for the Telephone
Order Scenario

Figure 7-13
Systems Analysis and Design in a Changing World, 5th Edition 43
 SSD of the
Web Order
Scenario for
the Create
New Order
Use case

Figure 7-14
Systems Analysis and Design in a Changing World, 5th Edition 44
 Identifying Object Behavior—
The State Machine Diagram
• State machine diagram is UML 2.0 diagram
that models object states and transitions
– Complex problem domain classes can be modeled
• 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 and is a semipermanent condition or
status
• Transition
– The movement of an object from one state to another state
Systems Analysis and Design in a Changing World, 5th Edition 45
 Simple State Machine Diagram for
a Printer

Figure 7-15
Systems Analysis and Design in a Changing World, 5th Edition 46
 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

Systems Analysis and Design in a Changing World, 5th Edition 47

 Composite States and
Concurrency—States within a
State

Figure 7-16
Systems Analysis and Design in a Changing World, 5th Edition 48
 Concurrent Paths for Printer in the
On State

Figure 7-17
Systems Analysis and Design in a Changing World, 5th Edition 49
 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
Systems Analysis and Design in a Changing World, 5th Edition 50
 Order Domain Class for RMO—
States and Exit Transitions

Figure 7-21
Systems Analysis and Design in a Changing World, 5th Edition 51
 First-Cut State Machine Diagram
for Order

Figure 7-22
Systems Analysis and Design in a Changing World, 5th Edition 52
 Second-Cut State Machine Diagram
for Order

Figure 7-23
Systems Analysis and Design in a Changing World, 5th Edition 53
 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, only 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
Systems Analysis and Design in a Changing World, 5th Edition 54
 Relationships Between OO
Requirements Models

Figure 7-24
Systems Analysis and Design in a Changing World, 5th Edition 55
 Summary
• Object-oriented approach has complete set of
diagrams that define system requirements
• Requirements specified using following models
– Domain model class diagram (Chapter 5)
– Use case diagrams (Chapters 7)
– Use case detailed models, either descriptive formats
or activity diagrams (Chapter 5 & 7)
– System sequence diagrams (Chapter 7)
– State machine diagrams (Chapter 7)

Systems Analysis and Design in a Changing World, 5th Edition

56