Chapter 8

Analysis Modeling
Moonzoo Kim
CS Division of EECS Dept.
KAIST
[email protected]
http://pswlab.kaist.ac.kr/courses/cs550-07

CS550 Intro. to SE
Spring 2007 1
 Roadmap of SEPA covered in CS550
„ March : Ch 1 – Ch 5 „ April: Ch 7- Ch 9 „ May : Ch 10 – Ch 14
„ 1. Intro to SE „ 7. Requirement „ 10. Creating an
Engineering Architectural Design
„ 2. A Generic View „ Req. eng tasks
of Process „ Req. elicitation „ 11. Modeling
„ 3. Process Models „ Developing use- Component-Level
cases Design
„ 4. An Agile View „ Building the
of Process analysis model „ 12. Performing UI
„ 8. Building the Design
„ 5. SE Practice
Analysis Model „ 13. Testing
„ 6. System „ 9. Design Strategies
Engineering Engineering
„ 14. Testing Tactics
SafeHome Project
SafeHome Project
- Class diagram
- Use-case diagram
- CRC cards
- Use-cases
CS550 Intro. to SE - Sequence diagram
Spring 2007 - Activity diagram 2
- State diagram
Overview of Ch 8. Building the Analysis Model

„ April 10: ch 8.1- ch 8.5

„ 8.1 Requirement Analysis
„ 8.2 Analysis Modeling Approaches
„ 8.3 Data Modeling Concepts
„ 8.4 Object-Oriented Analysis
„ 8.5 Scenario-based modeling

„ April 12: ch 8.6- ch 8.8

„ 8.6 Flow-oriented modeling
„ 8.7 Class-based modeling
„ 8.8 Creating a behavioral model

CS550 Intro. to SE
Spring 2007 3
 Requirements Analysis
„ At a technical level, SE begins with a building
an analysis model of a target system
„ Requirements analysis
„ specifies software’s operational characteristics
„ indicates software's interface with other system
elements
„ establishes constraints that software must meet
„ Objectives
1. To describe what the customer requires
2. Establish a basis for the creation of a SW design
3. To define a set of requirements that can be validated
once the software is built
CS550 Intro. to SE
Spring 2007 4
 Requirements Analysis
„ Requirements analysis allows the software engineer
to:
„ elaborate on basic requirements established during earlier
requirement engineering tasks
„ see Ch 7. “Requirements Engineering”
„ build models that depict
„ user scenarios
„ functional activities
„ problem classes and their relationships
„ system and class behavior
„ the flow of data as it is transformed.

CS550 Intro. to SE
Spring 2007 5
 A Bridge

system
description

analysis
model

design
model

CS550 Intro. to SE
Spring 2007 6
 Rules of Thumb
1. The model should focus on requirements that are visible within the
problem or business domain.
„ The level of abstraction should be relatively high.
2. Each element of the analysis model should
„ add to an overall understanding of software requirements
„ provide insight into the
„ information domain
„ function of the system
„ behavior of the system
3. Delay consideration of infrastructure and other non-functional models
until design.
4. Minimize coupling throughout the system.
5. Be certain that the analysis model provides value to all stakeholders.
6. Keep the model as simple as it can be.
CS550 Intro. to SE
Spring 2007 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
„ 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.
CS550 Intro. to SE
Spring 2007 8
 Data Modeling
„ Analysis modeling often „ Typical data objects
begins with data modeling „ External entities
„ Examines data objects „ printer, user, sensor
independently of „ Things
processing „ reports, displays, signals
„ Focuses attention on the „ Occurrences or events
data domain „ interrupt, alarm
„ Indicates how data objects „ Roles
relate to one another „ manager, engineer, salesperson
„ Relationship among data „ Organizational units
objects can be expressed in „ division, team
UML very well „ Places
„ manufacturing floor
„ Structures
CS550 Intro. to SE
Spring 2007 „ employee record 9
 Object-Oriented 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

CS550 Intro. to SE
Spring 2007 10
 Classes
occurrences roles
• Object-oriented thinking organizational units
things
begins with the definition of places
a class, often defined as: external entities
structures
– template
– generalized description class name
– “blueprint” ... describing a attributes:
collection of similar items
• A superclass establishes a
hierarchy of classes
operations:
• Once a class of items is
defined, a specific instance
of the class can be identified

CS550 Intro. to SE
Spring 2007 11
 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.

CS550 Intro. to SE
Spring 2007 12
 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”

CS550 Intro. to SE
Spring 2007 13
 Class Hierarchy
Furniture (superclass)

Table Chair Desk Bed

subclasses of the

instances of Chair

CS550 Intro. to SE
Spring 2007 14
 How to Define All Classes
1. Basic user requirements must be communicated
between the customer and the SW engineer
2. Classes must be identified
„ Attributes and methods are to be defined
3. A class hierarchy is defined
4. Object-to-object relationships should be represented
5. Object behavior must be modeled
6. Tasks 1 through 5 are repeated until the model is
complete

CS550 Intro. to SE
Spring 2007 15
 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
(1) What should we write about?
(2) How much should we write about it?
(3) How detailed should we make our description?
(4) How should we organize the description?

CS550 Intro. to SE
Spring 2007 16
 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
„ Developing a use case
„ What are the main tasks or functions that are performed by the
actor?
„ What system information will the actor acquire, produce or
change?
„ What information does the actor desire from the system?
CS550 Intro. to SE
Spring 2007 17
 Use-Case Diagram
Saf eHome

Access camera
surveillance via t he cameras
Int ernet

Conf igure Saf eHome

syst em paramet ers

homeowner

Set alarm

CS550 Intro. to SE
Spring 2007 18
 Activity Diagram
ent er password
and user ID

„ Supplements the use-

valid passwor ds/ ID invalid passwor ds/ ID

case by providing a
diagrammatic ot her f unct ions
m ay also be
select major f unct ion prompt f or reent ry

representation of
select ed
input t r ies r em ain
select surveillance
no input
t r ies r em ain

procedural flow
(Fig 8.7 of 224 pg) t hum bnail views select a specif ic cam er a

select specif ic
select camera icon
camera - t humbnails

view camera out put

in labelled window

prompt f or
anot her view

CS550 Intro. to SE exit t his f unct ion

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

„ Allows the modeler to ent er pas s word

and us er ID

represent the flow of

activities described by s elec t m ajor f unc t ion
valid p asswo r d s/ ID
in valid
p asswo r d s/ ID

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

„ This diagram indicates s elec t s urv eillanc e

n o in p u t
in p u t t r ies
r em ain

which actor or analysis

t r ies r em ain

class has responsibility t h u m b n ail views select a sp ecif ic cam er a

for the action described s elec t s pec if ic

c am era - t hum bnails
s elec t c am era ic on

by an activity rectangle generat e v ideo

out put

(Fig 8.8 of 225 pg) v iew c am era out put

in labelled window
prom pt f or
anot her v iew

exit t h is
f u n ct io n

see
an o t h er
cam er a
CS550 Intro. to SE
Spring 2007 20
 HW #3. Due April 17
8.2 Is it possible to develop an effective analysis model without
developing all four elements shown in Fig.8.3? Explain

8.3 Is it possible to begin coding immediately after an analysis model

has been created? Explain your answer and then argue the
counterpoint (e.g. negative effects)

8.5 An analysis rule of thumb is that the model “should focus on

requirements that are visible within the problem or business
domain.” What types of requirements are not visible in these
domains? Provide a few examples.

8.19 Write a template-based use-case for the SafeHome home

management system (“SafeHome home management function”)
described informally in the sidebar following Sect 8.7.4. Also draw a
swimlane activity diagram (use a template at Sect.7.5)
CS550 Intro. to SE
Spring 2007 21