Software Engineering: A Practitioner’s Approach

Chapter 8
Analysis Modeling

SWE course 2005 1
 Analysis Modeling
 The products of analysis must be highly maintainable.
 Problems of size must be dealt with through 
partitioning.
 Graphics must be used
 We have to differentiate between logical and physical 
considerations.
 Analysis modeling uses a combination of text and 
diagrammatic forms.
 The purpose of analysis modeling is to validate the 
software requirements.
SWE course 2005 2
 Analysis Modeling
 A few of the diagrammatic formats we will look at are:
 scenario­based modeling – represents the system from the user’s 
point of view.
 Flow­oriented modeling – provides an indication of how data 
objects are transformed by processing functions.
 Class­based modeling – defines objects, attributes and 
relationships
 Behavioral modeling depicts the states of the system and its 
classes and the impact of events on these states.

SWE course 2005 3
 Requirements Analysis
 Requirements analysis 
 specifies software’s operational characteristics
 indicates software's interface with other system elements 
 establishes constraints that software must meet
 Requirements analysis allows the software engineer (called an 
analyst or modeler in this role) to:
 elaborate on basic requirements established during earlier requirement 
engineering tasks
 build models that depict user scenarios, functional activities, problem 
classes and their relationships, system and class behavior, and the flow 
of data as it is transformed. 
 The analysis model and requirements specification provide a means 
for assessing quality once the SW is built.

SWE course 2005 4
The analysis model is a bridge between the 
system description and the design model

system
description

analysis
model

design
model

SWE course 2005 5
 Analysis Model Objectives
 to describe what the customer requires
 to establish a basis for the creation of a software design
 to define a set of requirements that can be validated once 
the SW is built

SWE course 2005 6
 Analysis Rules of Thumb
 The model should focus on requirements that are visible within the 
problem or business domain. The level of abstraction should be 
relatively high. 
 Each element of the analysis model should add to an overall 
understanding of software requirements and provide insight into 
the information domain, function and behavior of the system.
 Delay consideration of infrastructure and other non­functional 
models until design. 
 Minimize coupling throughout the system. 
 Be certain that the analysis model provides value to all 
stakeholders. 
 Keep the model as simple as it can be. 

SWE course 2005 7
 Domain Analysis
Software domain analysis is the identification, analysis, 
and specification of common requirements from a 
specific application domain, typically for reuse on 
multiple projects within that application domain . . . 
[Object­oriented domain analysis is] the identification, 
analysis, and specification of common, reusable 
capabilities within a specific application domain, in 
terms of common objects, classes, subassemblies, and 
frameworks . . .
Donald Firesmith

SWE course 2005 8
 Domain Analysis
 Define the domain to be investigated.
 Collect a representative sample of applications in 
the domain.
 Analyze each application in the sample.
 Develop an analysis model for the objects. 

SWE course 2005 9
 Analysis Modeling Approaches
 View 1:  structured analysis 
 considers data and the processes that transform the data as 
separate entities.
 View 2: object­oriented analysis 
 focuses on the definition of classes and how they collaborate to 
effect customer requirements.

SWE course 2005 10
 Data Modeling
 Analysis modeling usually begins with data 
modeling.
 defines data objects independently of processing
 focuses attention on the data domain
 creates a model at the customer’s level of abstraction
 indicates how data objects relate to one another

SWE course 2005 11
 What is a Data Object?
Object —something that is described by a set
of attributes (data items) and that will be 
manipulated within the software (system)
each  instance of an object (e.g., a book) 
can be identified uniquely (e.g., ISBN #) 
each plays a necessary role in the system
i.e., the system could not function without 
access to instances of the object
each is described by attributes that are 
themselves data items

SWE course 2005 12
 Typical Data Objects
external entities  (printer, user, sensor)
things  (e.g, reports, displays, signals) 
occurrences or events  (e.g., interrupt, alarm)
roles  (e.g., manager, engineer, salesperson)
organizational units  (e.g., division, team)
places  (e.g., manufacturing floor) 
structures  (e.g., employee record)

SWE course 2005 13
 Data Objects and Attributes
A data object contains a set of attributes that act as an 
•A data object contains a set of attributes that act as an 
aspect, quality, characteristic, or descriptor of the object.
Attributes name a data object, describe its characteristics, 
•Attributes name a data object, describe its characteristics, 
and can make reference to another object.
A data object (composite item) and an OO Class are not the 
•A data object (composite item) and an OO Class are not the 
same.
object: automobile
attributes:
make
model
body type
price

SWE course 2005 14
 Relationships
 Indicate the manner in which data objects are connected 
to one another.

SWE course 2005 15
Data modeling with ENTITY RELATIONSHIP (ER) diagrams

 Part of the process of understanding a problem is deciding what the important

participants in the situation being modeled are and what are their relationships.
 This process is called data modeling. One high-level approach to data modeling is
called Entity-Relationship modeling (ER modeling), developed by Chen in the 1970's.
 The participants in a model are called entities and correspond to nouns in the verbal
description of the problem. For example, a university can be described in terms of
courses, buildings, departments, etc.
 The relationships are often expressed as verbs and relate two or more entities. For
example, students take courses.
 Entities often have properties that are called attributes. Attributes are the computer
representation of the abstract entities. For example, a class has a name, a number, and a
maximum enrollment.

SWE course 2005 16
 ENTITIES (Objects) AND ATTRIBUTES

•Entities represent a class of similar things. The differences among the instances
of a class are denoted by the values of the entity's attributes.
•Entities belong to the problem being modeled. They never exist inside the
computer. The values of the attributes are stored in the machine.
•Entities are denoted by rectangles in Entity - Relationship ( ER ) diagrams. They
contain a unique textual label indicating the name of the class.
•Attributes are denoted by circles. The textual label contained in the circle will
ultimately become the name of a database field.
•Attributes are connected to their associated entities by unlabeled and
undirected arcs.
SWE course 2005 17
 RELATIONSHIPS

Relationship —indicates “connectedness”; a "fact" that must be

"remembered“ by the system and cannot or is not computed or derived
mechanically
- Entities bear relationships to each other. Otherwise they would not be part of the
same problem description.

- Relationships are denoted by diamonds. The diamonds are connected to the

associated entities by undirected arcs. There are at least two arcs incident on each
diamond.

- The diamonds are labeled with verbs. These verbs are different from the verbs
and verb phrases labeling process nodes in data flow diagrams.
- In a DFD, the label on a process node indicates an active function to be
performed by some computing process.

- The labels for ER relationships are more non-committal. They indicate that two
entity classes are somehow related, not that one is necessarily produced from the
other.
•The arcs may be labeled. A label indicates the type of relationship between two 18
SWE course 2005
 RELATIONSHIPS - 2
-Cardinality: How many of each object in a relationship. Cardinality is shown as a
mark on the relationship line next to each box:

+ A 1:1 relationship indicates that each instance of one

entity corresponds to one and only one instance of
the second. Likewise, each instance of the second
corresponds to one and only one instance of the first.
For example, each wife has exactly one husband and
vice versa.

+ A 1:M relationship indicates that a single instance of

one entity corresponds to multiple instances of the
other. For example, many family members may live in
the same house.

+ An M:M relationship indicates that multiple instances

of one entity corresponds to multiple instances of the
other. For example, a person eats many different kinds
SWE course 2005 19
 RELATIONSHIPS - 3
 Modality: Is there always at least one A for each B, or is A
optional?
Modality one: value is required
Modality zero: value is optional
This applies to each argument of relationship
 So: 16 different categories of relationships; each argument may
be:
Cardinality Modality Description
one one exactly one
one zero at most one
many one at least one
many
SWE course 2005
zero any number 20
 Constructing an ERD
 To construct an ER Diagram:
1. List “things" application addresses; these are candidate data
objects
2. Find connections among data objects; these are candidate
relationships
3. Determine relationship cardinality and modality
4. Define attributes of each data object
5. Draw an ER Diagram
6. Iterate until data model is stable

SWE course 2005 21
 ERD Notation

One common form:

(0, m)
object1 relationship object 2
(1, 1)

attribute
Another common form:

object1 relationship
object 2
(0, m) (1, 1)

SWE course 2005 22
 Entity relationship Diagrams
One common form:
(0, m)
object1 relationship object 2
(1, 1)

attribute
Another common form:

object1 relationship
object 2
(0, m) (1, 1)

SWE course 2005 23
 Building an ERD

 Level 1—model all data objects (entities) and their 
“connections” to one another
 Level 2—model all entities and relationships
 Level 3—model all entities, relationships, and the 
attributes that provide further depth

SWE course 2005 24
 Example

NAME

AGE
STUDENT SEX

ENROLLED_IN

SUBJECT
CLASS COURSE_ID

MAX_ENROLLMENT

SWE course 2005 25
 Non binary relations

Data Duration

Director
HeadOf
Department

Participate
Assigned

Project

Employee

SWE course 2005 26
 EXAMPLE ER DIAGRAM

Employee Rank
#
Title Hours

Teacher
Extra
Curricular
Teaches Activities
M
M
Students M Participate
In

GPA Student Class

ID
SWE course 2005
 EXAMPLE ER DIAGRAM

branch
customer accoun
t

cid name balanc bname bcit

ano
e y
ccity

SWE course 2005 28
 DATAFLOW diagram: function modeling
 Analysis technique based on data transformers (verbs)
 Lower level (detail) diagrams may refine high level transformers
 Summarizes the flow of data between modules of a system and external elements
(people, databases, network, etc.). A DFD does not specify in what order or in what
situations such data flows occur.
 DFD considers both data and processing. It's modeling can be described in a number
of ways:
 What functions must the system perform? What are the interactions between the
functions?
 What transformations must the system carry out? What inputs are transformed
into what outputs?
 What kind of work does the system do? Where does it get the information to do
its work? Where does it deliver the results of its work?

SWE course 2005 29
 Data flow Diagram components
 Data flow diagrams consist of processes, data stores, flows, and information
sources:
 Processes (transformations): are represented by labeled circles (bubbles). They
represent the various individual functions that the system carries out.
 Flows: Information and/or data flow is represented by a labeled arrow. they
represent the information that the processes require as input and/or the information
generate as output.
 Data stores: files and depositories are represented by open boxes. The stores will
typically exist as files or databases.
 Information sources and sinks are represented by boxes

SWE course 2005 30
 The Flow Model
Every computer-based system is an
information transform ....

computer
input based output
system

SWE course 2005 31
 Flow Modeling Notation

external entity

process

data flow

data store

SWE course 2005 32
 External Entity

A producer or consumer of data

Examples: a person, a device, a sensor

Another example: computer-based
system
Data must always originate somewhere
and must always be sent to something

SWE course 2005 33
 Process

A data transformer (changes input

to output)

Examples: compute taxes, determine area,

format report, display graph
Data must always be processed in some
way to achieve system function

SWE course 2005 34
 Data Flow

Data flows through a system, begins

as input and is transformed into output.
base
compute
area
triangle
height area

SWE course 2005 35
 Data Stores

Data is often stored for later use.

sensor #
sensor #, type,
look-up location, age
sensor
report required data
type,
sensor number location, age

sensor data

SWE course 2005 36
 Data Flow Diagramming:
Guidelines

 all icons must be labeled with meaningful names

 the DFD evolves through a number of levels of detail
 always begin with a context level diagram (also called level 0)
 always show external entities at level 0
 always label data flow arrows
 do not represent procedural logic

SWE course 2005 37
 Constructing a DFD—I

 review ERD to isolate data objects and grammatical parse to

determine “operations”
 determine external entities (producers and consumers of data)
 create a level 0 DFD

SWE course 2005 38
 Level 0 DFD Example

processing
user request requested
digital video
video signal
monitor
processor
video
source NTSC
video signal

SWE course 2005 39
 Constructing a DFD—II

 write a narrative describing the transform

 parse to determine next level transforms
 “balance” the flow to maintain data flow continuity
 develop a level 1 DFD
 use a 1:5 (approx.) expansion ratio

SWE course 2005 40
 Construction of DFD
 DFDs show system at varying levels of abstraction

 The top level data flow diagram is called the context diagram

 It contains exactly one process node denoting the overall function of the system

 DFDs do not show sequence, conditions, loops

 Each bubble should be accompanied by a processing specification (PSPEC), explaining

inputs, outputs, algorithm, etc.

SWE course 2005 41
 A construction “method” (1)

1. Start from the “context” diagram

Input 1 Output
1

Input information Output

2 2
... system ...
Input n
Output
m

SWE course 2005 42
 A construction “method” (2)
2. Proceed by refinements until you
reach “elementary” functions
(preserve balancing) I A
O

A3
H
J
I A1 A4
A6
K P Q
A2 M S
A5
N
R A7 O

K K2 B2
M
B1
K3
K1
N
B4
T B3
Ag K4

SWE course 2005 43
 DFD Example

Spooled Mail
Incoming Mail Messages Read Displayed
Mail Receive Messages
Incoming Mail &
Mail Spool Process
Mail
Filed
Mail

Mail File

SWE course 2005 44
 REFINING DATA FLOW DIAGRAMS

 One important part of system modeling is separating important concepts

from details
 Data flow modeling supports this by refine DFDs to produce detailed DFD
or many manageable modular DFDs
 A process node in a high level diagram can be expanded to a full diagram at
a lower level
 Lines coming into and leaving the process node must be present in the low
level diagram
 This consistency rule can be checked automatically by the CASE tool

SWE course 2005 45
 EXAMPLE : REFINED DIAGRAM

Displayed
Message Delete
Message

Mail Read Read Message

Messages Message

File
Message

Filed
Reply Mail
to
Message

Reply

SWE course 2005 46
 A library example
Book Book request
Shelves by t he user
T it le and aut hor
of request ed book; name
of t he user
Aut hor

Book Book
List of Aut hors
Get a book recept ion

T it le
Book t it le;
user name
List of t it les

T it le List of books borrowed

Search by
t opics
List of t opics
T opic
List of t it les
T opic referring t o t he t opic
Display of
t he list of t it les
T opic request
by t he user

SWE course 2005 47
 Refinement of
“Get a book”
Book

Shelves
Author Get Book
the book
List of Authors
Book
<shelf#, book#> reception
Find
Title book
position
List of titles List of books borrowed

Title and author

of requested book; Book title;
name of the user user name
Book request
by the user

SWE course 2005 48
 Patient monitoring systems
The purpose is to monitor the patients’ vital factors--blood,
pressure, temperature, …--reading them at specified frequencies
from analog devices and storing readings in a DB. If readings fall
outside the range specified for patient or device fails an alarm
must be sent to a nurse. The system also provides reports.
Nurse

Report
Request
Report
Clinical Patient
Patient Data Nurse
Monitoring
Alarm
Recent data

Data for report Persistent data

SWE course 2005 49
 A refinement
Patient archive
Report Nurse
Recent Request
Data Data for
Report
Generate
Update Report
archive
Report
Formatted data
Central Nurse
Monitoring Alarm

Limits Patient data

Local Clinical
Limits for patient Monitoring Data Patient

SWE course 2005 50
 More refinement
Pressure Patient
data
Limits
Temperature decode
Check
limit
violations Pulse
Pressure, pulse…
Result
Format
Date clock
data produce
Time
message
Formatted data alarm

SWE course 2005 51
 An evaluation of DFDs (1)
 Easy to read, but …
 Informal semantics
 How to define leaf functions?
 Inherent ambiguities

A
E
• Outputs from A, B, C are
B D
all needed?
F • Outputs for E and F are
C produced at the same time

SWE course 2005 52
 An evaluation of DFDs (2)
 Control information is absent

A B

Possible interpretations:
(a) A produces datum, waits until B consumes it
(b) B can read the datum many times without
consuming it
(c) a pipe is inserted between A and B

SWE course 2005 53
 Order processing DFD

Checked and
Completed Signed Signed Send to signed order
order form order form order form supplier + order
Or der
notification
details + Complete Valida te Record
blank order form order order
order form Adjust
Order available
Signed budget
details order form
Order
amount
+ account
details
Orders Budget
file file

SWE course 2005 54
 Equipment procurement DFD
Delivery
note
Equipment Checked Delivery
Specify spec. spec. Accept note Check
Validate Get cost
equipment delivery of delivered
specification estimates
requir ed equipment items

Supplier Spec. +
Equipment list supplier + Order Installation
spec. estimate notification instructions

Place
Supplier Find Choose equipment Install
database suppliers supplier equipment
order
Order
details + Installation
Blank order acceptance
form

Accept
Checked and
delivered
signed or der form
equipment

Equipment
details

Equipment
database

SWE course 2005 55
SWE course 2005 56
 OO Analysis
 The intent is to define all classes and the relationships 
and behavior accosiated with them. 
 Key tasks:
 basic user requirements must be known.
 classes must be identified (attributes and methods)
 class hierarchy defined
 object­to­object relationships represented.
 object behavior must be modeled

SWE course 2005 57
 Object­Oriented Concepts
 The following key concepts must be
understood to apply class-based elements of
the analysis model
 Key concepts:
 Classes and objects

 Attributes and operations

 Encapsulation and instantiation

 Inheritance

SWE course 2005 58
 Classes
• object-oriented thinking begins with the definition of a
class, often defined as:
– template
– generalized description
– “blueprint” ... describing a collection of similar
items
• a metaclass (also called a superclass) establishes a
hierarchy of classes
• once a class of items is defined, a specific instance of
the class can be identified
SWE course 2005 59
 Building a Class
class name

attributes:

operations

attributes:
operations:

SWE course 2005 60
 What is a Class?
occurrences roles
things organizational units
places
external entities
structures

class name

attributes:

operations:

SWE course 2005 61
Encapsulation/Hiding
The object encapsulates
both data and the logical
procedures required to method  method 
# 1 # 2
manipulate the data
data
method 
method  # 3
# 6

method  method 
# 5 # 4

Achieves “information hiding”

SWE course 2005 62
 Class  :browsersAccessing
Hierarchy
PieceOfFurniture (superclass)

Table Chair Desk ”Chable"

subclasses of the

instances of Chair

SWE course 2005 63
 Methods
(a.k.a. Operations,
Services)
An executable procedure that is encapsulated
in a class and is designed to operate on one or
more data attributes that are defined as part
of the class.
A method is invoked
via message passing.

SWE course 2005 64
 Scenario­Based Modeling
 Use­cases are simply an aid to defining what exists 
outside the system (actors) and what should be 
performed by the system (use­cases).    Ivar Jacobson

2. What should we write about?
3. How much should we write about it?
4. How detailed should we make our description? 
5. How should we organize the description? 

SWE course 2005 65
 Use­Cases
 A scenario that describes a “thread of usage” for a
system
 Actors represent roles people or devices play as the
system functions
 Users can play a number of different roles for a given
scenario

SWE course 2005 66
 Developing a Use­Case
 What are the main tasks or functions that are
performed by the actor?
 What system information will the the actor acquire,
produce or change?
 Will the actor have to inform the system about
changes in the external environment?
 What information does the actor desire from the
system?
 Does the actor wish to be informed about unexpected
changes?

SWE course 2005 67
 Use­Case Diagram
SafeHome

Access camera
surveillance via the cameras
Internet

Configure SafeHome
system parameters

homeowner

Set alarm

SWE course 2005 68
 Activity Diagram enter password
and user ID

Supplements the use-case by

providing a diagrammatic
valid passwords/ ID invalid passwords/ ID

representation of procedural ot her f unct ions

select major function prompt for reentry

flow
may also be
select ed
input t r ies remain
select surveillance
no input
t ries remain

t humbnail views select a specif ic camera

select specific
select camera icon
camera - thumbnails

view camera output

in labelled window

prompt for
another view

exit t his f unct ion see anot her camera

SWE course 2005 69
Swimlane Diagrams
h o m e o wn e r c a m e ra i n t e rf a c e

enter password
and user ID

Allows the modeler to

represent the flow of select major function
valid p asswo rd s/ ID
in valid
p asswo rd s/ ID

activities described by the o t h er f u nctio n s

may also b e
select ed
prompt for reentry

use-case and at the same select surveillance

n o in p u t
in p u t t ries
remain

time indicate which actor tries remain

(if there are multiple th u mb n ail views select a sp ecif ic camera

actors involved in a select specific

camera - thumbnails
select camera icon

specific use-case) or generate video

analysis class has view camera output

output

prompt for

responsibility for the in labelled window another view

exit t h is

action described by an
f u nctio n

see
an o t h er
camera

activity rectangle
SWE course 2005 70
 Flow Modeling Notes
 each bubble is refined until it does just one thing
 the expansion ratio decreases as the number of levels 
increase
 most systems require between 3 and 7 levels for an 
adequate flow model
 a single data flow item (arrow) may be expanded as 
levels increase (data dictionary provides information)
 The Process Specification (PSPEC) describes all flow 
model processes that appear at the final level of 
refinement.
 It is a “mini” spec for each transform at the lowest refined 
level of a DFD

SWE course 2005 71
 Process Specification (PSPEC)
bubble

PSPEC
narrative
pseudocode (PDL)
equations
tables
diagrams and/or charts

SWE course 2005 72
 DFDs map into the design model.

analysis model
Maps into
design model

SWE course 2005 73
 Control Flow Diagrams
 Many applications are event driven rather than data driven.
 Produce control information rather than reports or displays.
 This app type requires control flow modeling in addition to data flow
modeling.
 CFD: Represents “events” and the processes that manage events
 An “event” is a Boolean condition that can be determined by:
 listing all sensors that are "read" by the software.

 listing all interrupt conditions.

 listing all "switches" that are actuated by an operator.
 listing all data conditions.
 recalling the noun/verb parse that was applied to the processing
narrative, review all "control items" as possible CSPEC inputs/outputs.
SWE course 2005 74
 The Control Model
ol flow diagram is "superimposed" on the DFD
ows events that control the processes noted in
the DFD
flows—events and control items—are noted by
dashed arrows
bar implies an input to or output from a control
c (CSPEC) — a separate specification that
describes how control is handled
d arrow entering a vertical bar is an input to the
CSPEC
shed arrow leaving a process implies a data
condition
ed arrow entering a process implies a control
input read directly by the process
flows do not physically activate/deactivate the
processes—this is done via the CSPEC
SWE course 2005 75
 Control Flow 
Diagram

SWE course 2005 76
 Control Specification (CSPEC)
The CSPEC can be:
state diagram 
(sequential spec)

state transition table
combinatorial spec
decision tables 

activation tables

SWE course 2005 77
 Guidelines for Building a CSPEC
list all sensors that are "read" by the software
list all interrupt conditions
list all "switches" that are actuated by the operator
list all data conditions
recalling the noun-verb parse that was applied to the
software statement of scope, review all "control items"
as possible CSPEC inputs/outputs
describe the behavior of a system by identifying its
states; identify how each state is reach and defines
the transitions between states
focus on possible omissions ... a very common error in
specifying control, e.g., ask: "Is there any other way I
can get to this state or exit from it?"
SWE course 2005 78
 State Transition Diagrams
 State Transition Diagrams (STD) represent the behavior of the
system
 put state transition and action (events that cause the system to
change state) information together in one diagram
 They also indicate what actions are taken as a consequence of a
particular event.
 A state transition diagram (STD) shows how one module in a
system behaves for all possible inputs. An STD is particularly
important for modules that change state or mode several times,
depending on what's happened. A module may be in password-
reading state, or time-scheduling state, or whatever.

SWE course 2005 79
 The States of a System
 state—a set of observable circum-stances that characterizes the
behavior of a system at a given time
 state transition—the movement from one state to another
 event—an occurrence that causes the system to exhibit some
predictable form of behavior
 action—process that occurs as a consequence of making a
transition

SWE course 2005 80
 Behavioral Modeling

 make a list of the different states of a system (How does

the system behave?)
 indicate how the system makes a transition from one state
to another (How does the system change state?)
 indicate event

 indicate action

 draw a state transition diagram

SWE course 2005 81
 Nodes and Links
 Nodes
 Nodes represent the states of one module of the system. Sometimes, this
state will be equivalent to an interface screen or web page. If so, the node
should be labeled with the name of the screen or page, e.g., "the password
screen." Other times, the state is more abstract and determined by the
values of some internal variables. In such cases, where labels would be
cryptic, the nodes may be left unlabelled.
 A common mistake is to put an action or event label on a node, e.g., "read
password." A state is not an action, not a program, not a step, not a
message, not an event. Nothing happens in a state. Things only happen in
the transitions between states.
 Links
 Links represent the transitions between states. Therefore, links are always
directed, i.e., they're arrows from one state to another, not just lines, and
labeled with inputs, actions or events, never data messages
 It is never acceptable to leave links unlabelled. Unlabelled links make no
sense in an STD.
SWE course 2005 82
 State Transition Diagram Notation

state

event causing transition

action that occurs

new state

SWE course 2005 83
 State transitions for an order

get next item[ not all Item received[ some

items checked ] items not in stock ]

[ All items checked && some

/ get first item Checking items not in stock ]
Waiting
do: check item

[ All items checked && Item received[ all items

all items available ] available ]

Dispatching Delivered
Delivered
do: initiate delivery

SWE course 2005 84
 EXAMPLE : STATE TRANSITION
DIAGRAM GARAGE DOOR OPENER
Door Closed
Motor off
button pressed/
start motor door closed detected/
stop motor
/ Door Partially Closed
start motor
Motor Running Motor off
Up button pressed/
stop motor
button pressed/
Door Partially Open stop motor
Motor off
Motor Running
button pressed/
door open detected/ start motor Down
stop motor
button pressed/
start motor
Door Open
Motor off
SWE course 2005 85
 State transition diagram for safehome

SWE course 2005 86
 Microwave oven state machine
Full
power on

Full Timer
power Timer
Timeout
Full
power Set Timed Cooking
Idle
time operation complete
Half
power
Half Door
power Timer closed Start
Door
open Door
Half Operation open
Idle
power on Door enabled
closed

Operation
disabled

SWE course 2005 87
 Class­Based Modeling
 Identify analysis classes by examining the 
problem statement
 Use a “grammatical parse” to isolate potential 
classes
 Identify the attributes of each class
 Identify operations that manipulate the attributes

SWE course 2005 88
 Analysis Classes
 External entities (e.g., other systems, devices, people) that produce or
consume information to be used by a computer-based system.
 Things (e.g, reports, displays, letters, signals) that are part of the
information domain for the problem.
 Occurrences or events (e.g., a property transfer or the completion of a
series of robot movements) that occur within the context of system
operation.
 Roles (e.g., manager, engineer, salesperson) played by people who
interact with the system.
 Organizational units (e.g., division, group, team) that are relevant to an
application.
 Places (e.g., manufacturing floor or loading dock) that establish the
context of the problem and the overall function of the system.
 Structures (e.g., sensors, four-wheeled vehicles, or computers) that define
a class of objects or related classes of objects.
SWE course 2005 89
 Criteria for selecting classes
 pg 203
 A class selected to be included in the requirement model 
should satisfy almost all of these characteristics.
 retained information
 needed services
 multiple attributes
 common attributes
 common operations
 essential requirements 

SWE course 2005 90
 attributes: the set of data objects that fully define the 
class within the context of the problem.
 operations define the behavior of an object and fall into 3 
broad categories.
 operations that manipulate data in some way
 operations that perform a computation
 operations that inquire about the state of an object
 operations that monitor an object for the occurrence of a 
controlling event.

SWE course 2005 91
 Class Diagram
Class name
System
systemID
verificationPhoneNumber attributes
systemStatus
delayTime
telephoneNumber
masterPassword
temporaryPassword
numberTries

program()
display() operations
reset()
query()
modify()
call()

SWE course 2005 92
 Class Diagram
FloorPlan

type
name
outsideDimensions

determineType ()
positionFloorplan
scale( )
change color( )

is placed within

is part of

Camera Wall

type type
ID wallDimensions
location
fieldV iew
panA ngle
ZoomSetting
determineType ()
computeDimensions ( )
determineType ()
translateLocation ()
displayID()
displayV iew()
displayZoom()
is used to build is used to build

is used to build

WallSegment Window Door

type type type

startCoordinates startCoordinates startCoordinates
stopCoordinates stopCoordinates stopCoordinates
nextWallSement nextWindow nextDoor

determineType ( ) determineType ( ) determineType ()

draw( ) draw( ) draw()

SWE course 2005 93
 Class­Responsibility­Collaborator 
(CRC) Modeling
 Analysis classes have “responsibilities”
 Responsibilities are the attributes and operations
encapsulated by the class
 Analysis classes collaborate with one another
 Collaborators are those classes that are required to provide
a class with the information needed to complete a
responsibility.
 In general, a collaboration implies either a request for
information or a request for some action.

SWE course 2005 94
 CRC Modeling
Class:
Class:
Description:
Class:
Description:
Class:FloorPlan
Description:
Responsibility:
Description: Collaborator:
Responsibility: Collaborator:
Responsibility: Collaborator:
Responsibility: Collaborator:
defines floor plan name/type
manages floor plan positioning
scales floor plan for display
scales floor plan for display
incorporates walls, doors and windows Wall
shows position of video cameras Camera

SWE course 2005 95
 Class Types
 Entity classes, also called model or business classes, are extracted directly from the statement
of the problem (e.g., FloorPlan and Sensor).
 represent things that are to be storing in a database and persist throughout the duration of
the application unless specifically deleted.
 Boundary classes are used to create the interface (e.g., interactive screen or printed reports)
that the user sees and interacts with as the software is used.
 designed with the responsibility of managing the way entity objects are represented to
users.
 Controller classes manage a “unit of work” from start to finish. That is, controller classes
can be designed to manage
 the creation or update of entity objects;

 the instantiation of boundary objects as they obtain information from entity objects;

 complex communication between sets of objects;

 validation of data communicated between objects or between the user and the
application.
SWE course 2005 96
 Responsibilities
Guidelines for allocating responsibilities to 
classes
 System intelligence should be distributed across classes 
to best address the needs of the problem
 Each responsibility should be stated as generally as 
possible
 Information and the behavior related to it should reside 
within the same class
 Information about one thing should be localized with a 
single class, not distributed across multiple classes. 
 Responsibilities should be shared among related classes, 
when appropriate. 

SWE course 2005 97
 Collaborations
 Classes fulfill their responsibilities in one of two ways:
  A class can use its own operations to manipulate its own attributes, 
thereby fulfilling a particular responsibility, or 
  a class can collaborate with other classes.
 Collaborations identify relationships between classes
 Collaborations are identified by determining whether a class can 
fulfill each responsibility itself
 if it can not then a collaboration is required.
 three different generic relationships between classes [WIR90]: 
  the is­part­of relationship
 aggregation
  the has­knowledge­of relationship
 one class must acquire information from another class.
  the depends­upon relationship
 implies that 2 classes have a dependency that is not achieved by 
has_knowledge­of or is­part­of.

SWE course 2005 98
 Composite Aggregate Class
Player

PlayerHead PlayerBody PlayerArms PlayerLegs

SWE course 2005 99
 Reviewing Model with CRC cards
 All participants in the review (of the CRC model) are given a subset of the CRC model
index cards.
 Cards that collaborate should be separated (i.e., no reviewer should have two cards
that collaborate).
 All use-case scenarios (and corresponding use-case diagrams) should be organized into
categories.
 The review leader reads the use-case deliberately.
 As the review leader comes to a named object, she passes a token to the person
holding the corresponding class index card.
 When the token is passed, the holder of the class card is asked to describe the
responsibilities noted on the card.
 The group determines whether one (or more) of the responsibilities satisfies the use-
case requirement.
 If the responsibilities and collaborations noted on the index cards cannot accommodate
the use-case, modifications are made to the cards.
 This may include the definition of new classes (and corresponding CRC index
cards) or the specification of new or revised responsibilities or collaborations on
existing cards.
SWE course 2005 100
 Associations and Dependencies
 Two analysis classes are often related to one another in some
fashion
 In UML these relationships are called associations

 an association defines a relationship betweeen classes.

 Associations can be refined by indicating multiplicity (the

term cardinality is used in data modeling
 In many instances, a client-server relationship exists between
two analysis classes.
 In such cases, a client-class depends on the server-class in
some way and a dependency relationship is established
(<<stereotype>>)
SWE course 2005 101
 Multiplicity
Wall

1 1 1

is used to build is used to build

1..* 0..* is used to build 0..*

WallSegment Window Door

SWE course 2005 102
 Dependencies

DisplayWindow Camera

<<access>>

{password}

SWE course 2005 103
 Analysis Packages
 Various elements of the analysis model (e.g., use­cases, analysis 
classes) are categorized in a manner that packages them as a 
grouping which is called an analysis package.
 The plus sign preceding the analysis class name in each package 
indicates that the classes have public visibility and are therefore 
accessible from other packages.
 Other symbols can precede an element within a package. 
 A minus sign indicates that an element is hidden from all other 
packages 
 a # symbol indicates that an element is accessible only to packages 
contained within a given package.

SWE course 2005 104