Chapter 8

Analysis Modeling
- Requirements analysis
- Flow-oriented modeling
- Scenario-based modeling
- Class-based modeling
- Behavioral modeling

(Source: Pressman, R. Software Engineering: A Practitioner’s Approach. McGraw-Hill, 2005)

 Goals of Analysis Modeling
• Provides the first technical representation of a system
• Is easy to understand and maintain
• Deals with the problem of size by partitioning the system
• Uses graphics whenever possible
• Differentiates between essential information versus implementation
information
• Helps in the tracking and evaluation of interfaces
• Provides tools other than narrative text to describe software logic and
policy

2
 A Set of Models
• The requirements modeling action results in one or more of the following types
of models:
• Scenario-based models of requirements from the point of view of various
system “actors”

• Data models that depict the information domain for the problem

• Class-oriented models that represent object-oriented classes (attributes and

operations) and the manner in which classes collaborate to achieve system
requirements
• Flow-oriented models that represent the functional elements of the system
and how they transform data as it moves through the system

• Behavioral models that depict how the software behaves as a consequence of

3
external “events”
A BRIDGE

system
description

analysis
model

design
model

4
Requirements Analysis Purpose

• Specifies the software's operational characteristics

• Indicates the software's interfaces with other system elements

• Establishes constraints that the software must meet

• Provides the software designer with a representation of information,

function, and behavior

• Provides the developer and customer with the means to assess quality
once the software is built

5
 Overall Objectives

• Three primary 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 software is

built

6
 Analysis Rules of Thumb
• The analysis 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 following
– Information domain, function, and behavior of the system
• The model should delay the consideration of infrastructure and other non-
functional models until the design phase
– First complete the analysis of the problem domain
• The model should minimize coupling throughout the system
– Reduce the level of interconnectedness among functions and classes
• The model should provide value to all stakeholders
• The model should be kept as simple as can be

7
 Domain Analysis
• Definition
– The identification, analysis, and specification of common, reusable capabilities
within a specific application domain
– Do this in terms of common objects, classes, subassemblies, and frameworks
• Sources of domain knowledge
– Technical literature
– Existing applications
– Customer surveys and expert advice
– Current/future requirements
• Outcome of domain analysis
– Class taxonomies
– Reuse standards
– Functional and behavioral models
– Domain languages

8
 Analysis Modeling Approaches
• Structured analysis
– Considers data and the processes that transform the data as separate
entities
– Data is modeled in terms of only attributes and relationships (but no
operations)
– Processes are modeled to show the 1) input data, 2) the transformation
that occurs on that data, and 3) the resulting output data
• Object-oriented analysis
– Focuses on the definition of classes and the manner in which they
collaborate with one another to fulfill customer requirements

9
Elements of the Analysis Model
Object-oriented Analysis Structured Analysis

Scenario-based Flow-oriented
modeling modeling
Use case text Data structure diagrams
Use case diagrams Data flow diagrams
Activity diagrams Control-flow diagrams
Swim lane diagrams Processing narratives

Class-based Behavioral
modeling modeling
Class diagrams
State diagrams
Analysis packages
Sequence diagrams
CRC models
Collaboration diagrams
10
Flow-oriented Modeling
 Data Modeling
• Identify the following items
– Data objects (Entities)
– Data attributes
– Relationships
– Cardinality (number of occurrences)

12
 DATA MODELING CONCEPTS

Data Objects
A data object is a representation of composite information that must be understood
by software.
can be an external, a thing ,an occurrence or event, a role ,an organizational unit, a
place ,or a structure .

Data Attributes
Data attributes define the properties of a data object and take on one of three different
characteristics. They can be used to
(1) name an instance of the data object,
(2) describe the instance, or
(3) make reference to another instance in another table.

Relationships
Data objects are connected to one another in different ways.

13
Data Flow and Control Flow

• Data Flow Diagram

– Depicts how input is transformed into output as data objects
move through a system
• Process Specification
– Describes data flow processing at the lowest level of
refinement in the data flow diagrams
• Control Flow Diagram
– Illustrates how events affect the behavior of a system through
the use of state diagrams

14
Diagram Layering and Process
Refinement

Context-level diagram

Level 1 diagram

15
Process Specification
Scenario-based Modeling
 Writing Use Cases
• It is effective to use the first person “I” to describe how the actor
interacts with the software
• Format of the text part of a use case

Use-case title:

Actor:

Description: I …

(See examples in Pressman textbook on pp. 188-189) 17

 Example Use Case Diagram

Make automated menu

selections Expert Menu
System

Order food and drink

Cook
Notify customer that
food and drink are ready
Customer

Pay for food and drink Payment

System
18
 Activity Diagrams

• Supplements the use case by providing a graphical representation of

the flow of interaction within a specific scenario

• Uses flowchart-like symbols

– Rounded rectangle - represent a specific system function/action

– Arrow - represents the flow of control from one function/action to another

– Diamond - represents a branching decision

– Solid bar – represents the fork and join of parallel activities

19
 ent er passw or d
and user ID

valid passwor ds/ ID invalid passwor ds/ ID

selec t major f unc t ion pr ompt f or r eent r y

ot her f unct ions
m ay also be
select ed
input t r ies r em ain
selec t sur v eillanc e
no input
t r ies r em ain

t hum bnail views select a specif ic cam er a

selec t spec if ic
selec t c amer a ic on
c amer a - t humbnails

v iew c amer a out put

in labelled w indow

pr ompt f or
anot her v iew

exit t his f unct ion

20
see anot her cam er a
 Swimlane Diagrams
homeowner c a m e ra i n t e rf a c e

Allows the
ent er pas s w ord
modeler to and us er ID

represent the
flow of activities valid p asswo r d s/ ID
in valid

described by the s elec t m ajor f unc t ion

p asswo r d s/ ID

use-case and at o t h er f u n ct io n s
m ay also b e
prom pt f or reent ry

the same time select ed

in p u t t r ies

indicate which s elec t s urv eillanc e

n o in p u t
r em ain

actor (if there are t r ies r em ain

multiple actors t h u m b n ail views select a sp ecif ic cam er a

involved in a
specific use- s elec t s pec if ic
c am era - t hum bnails
s elec t c am era ic on

case) or analysis
class has generat e v ideo
responsibility for out put

the action v iew c am era out put

in labelled w indow
prom pt f or
anot her v iew

described by an exit t h is

activity rectangle f u n ct io n

see
an o t h er
cam er a

21
Class-based Modeling
 Identifying Analysis Classes
1) Perform a grammatical parse of the problem statement or use cases
2) Classes are determined by underlining each noun or noun clause
3) A class required to implement a solution is part of the solution space
4) A class necessary only to describe a solution is part of the problem space
5) A class should NOT have an imperative procedural name (i.e., a verb)
6) List the potential class names in a table and "classify" each class according
to some taxonomy and class selection characteristics
7) A potential class should satisfy nearly all (or all) of the selection
characteristics to be considered a legitimate problem domain class
Potential classes General Selection
classification Characteristics

23
(More on next slide)
 Identifying Analysis Classes
(continued)
• General classifications for a potential class
– External entity (e.g., another system, a device, a person)
– Thing (e.g., report, screen display)
– Occurrence or event (e.g., movement, completion)
– Role (e.g., manager, engineer, salesperson)
– Organizational unit (e.g., division, group, team)
– Place (e.g., manufacturing floor, loading dock)
– Structure (e.g., sensor, vehicle, computer)

(More on next slide) 24

 Identifying Analysis Classes
(continued)
• Six class selection characteristics
1) Retained information
– Information must be remembered about the system over time
2) Needed services
– Set of operations that can change the attributes of a class
3) Multiple attributes
– Whereas, a single attribute may denote an atomic variable rather than a class
4) Common attributes
– A set of attributes apply to all instances of a class
5) Common operations
– A set of operations apply to all instances of a class
6) Essential requirements
– Entities that produce or consume information

25
 Defining Attributes of a Class
• Attributes of a class are those nouns from the grammatical parse that
reasonably belong to a class
• Attributes hold the values that describe the current properties or state of a
class
• An attribute may also appear initially as a potential class that is later
rejected because of the class selection criteria

• Usually an item is not an attribute if more than one of them is to be

associated with a class

26
 Defining Operations of a Class
• Operations define the behavior of an object
• Four categories of operations
– Operations that manipulate data in some way to change the state of an object
(e.g., add, delete, modify)
– 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
• An operation has knowledge about the state of a class and the nature of its
associations
• The action performed by an operation is based on the current values of the
attributes of a class
• Using a grammatical parse again, circle the verbs; then select the verbs
that relate to the problem domain classes that were previously identified

27
 Example Class Box
Class Name Component

+ componentID
- telephoneNumber
Attributes - componentStatus
- delayTime
- masterPassword
- numberOfTries
+ program()
+ display()
Operations + reset()
+ query()
- modify()
+ call()
28
 Association, Generalization and
Dependency (Ref: Fowler)
• Association
– Represented by a solid line between two classes directed from the source
class to the target class
– Used for representing (i.e., pointing to) object types for attributes
– May also be a part-of relationship (i.e., aggregation), which is represented by
a diamond-arrow
• Generalization
– Portrays inheritance between a super class and a subclass
– Is represented by a line with a triangle at the target end
• Dependency
– A dependency exists between two elements if changes to the definition of one
element (i.e., the source or supplier) may cause changes to the other element
(i.e., the client)
– Examples
• One class calls a method of another class
• One class utilizes another class as a parameter of a method
29
 Example Class Diagram
Accountant Auditor Record
Keeper

Input Production Transaction

Verifier Manager Processor

Report
Error Log Input Handler Account Account List
Generator

1..n

Local File Remote File Accounts Accounts

Handler Handler Receivable Payable

30
Behavioral Modeling
 Creating a Behavioral Model

1) Identify events found within the use cases and implied by the
attributes in the class diagrams
2) Build a state diagram for each class, and if useful, for the whole
software system

32
 Identifying Events in Use Cases
• An event occurs whenever an actor and the system exchange
information
• An event is NOT the information that is exchanged, but rather the fact
that information has been exchanged
• Some events have an explicit impact on the flow of control, while
others do not
– An example is the reading of a data item from the user versus comparing
the data item to some possible value

33
 Building a State Diagram
• A state is represented by a rounded rectangle

• A transition (i.e., event) is represented by a labeled arrow leading from

one state to another
– Syntax: trigger-signature [guard]/activity

34
 Example State Diagram
pop / set n to 0; return error push [n – 2 < max]

push [n = 0]
Empty Partially pop [n > 1]
Stack Filled Stack
pop [n = 1]

pop [n = max] push [n - 1 = max]

Full Stack

push / set n to max; return error

35
 CRC Models
• Class-responsibility-collaborator (CRC) modeling provides
a simple means for identifying and organizing the classes
that are relevant to system or product requirements.
Ambler describes CRC modeling in the following way:

– A CRC model is really a collection of standard index

cards that represent classes. The cards are divided into
three sections. Along the top of the card you write the
name of the class. In the body of the card you list the
class responsibilities on the left and the collaborators
on the right.

36
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

37
 Class Types
• Entity classes, also called model or business classes, are
extracted directly from the statement of the problem (e.g.,
Sensor).
• 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.

• 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.
38
 Responsibilities
• 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.

39
 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
• three different generic relationships between classes:

– the is-part-of relationship

– the has-knowledge-of relationship
– the depends-upon relationship

40
 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

• 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 and a # symbol indicates that an element is
accessible only to packages contained within a given package.

41
 package name

Environment
+Tree
+Landscape
+Road
+Wall
+Bridge
+Building RulesOf TheGame
+VisualEffect
+Scene +RulesOfMovement
+ConstraintsOnAction

Charact ers

+Player
+Protagonist
+Antagonist
+SupportingRole

42
 Summary:
Elements of the Analysis Model
Object-oriented Analysis Structured Analysis

Scenario-based Flow-oriented
modeling modeling
Use case text
Data flow diagrams
Use case diagrams
Control-flow diagrams
Activity diagrams
Processing narratives
Swim lane diagrams

Class-based Behavioral
modeling modeling
Class diagrams
State diagrams
Analysis packages
Sequence diagrams
CRC models
Collaboration diagrams
43
