Chapter 8
Analysis Modeling
Moonzoo Kim
CS Division of EECS Dept.
KAIST
moonzoo@cs.kaist.ac.kr
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
