Transcript Document
Lecture 6
Requirement analysis
Functional Modeling
Object Modeling
Dynamical Modeling
Non-functional requirements
Slides adopted from the book and lecture
material for the “Object oriented software
engineering” by Bruegge & Dutroit
SW Development Process
Requirement analysis
System Analysis
Describes how the system is realized.
Implementation
Identifies the structure of the system.
Design
Describes what the system is supposed to do.
Implements the system and performs unit testing
Testing
Verifies system
Requirement Analysis: Overview
Three types of modeling
Functional modeling
Object modeling
Dynamic modeling
Functional Modeling: What are the
transformations?
Create scenarios and use case diagrams
Talk to client, observe, get historical records, do
thought experiments
Requirement Analysis: Overview
Object Modeling: What is the structure of the system?
Create class diagrams
Identify objects. What are the associations between them?
What is their multiplicity?
What are the attributes of the objects?
What operations are defined on the objects?
Dynamic Modeling: What is its control structure?
Create sequence diagrams
Identify senders and receivers
Show sequence of events exchanged between objects.
Identify event dependencies and event concurrency.
Create state diagrams
Only for the dynamically interesting objects.
How to do Analysis
Analyze the problem statement
Identify functional requirements
Identify non-functional requirements
Identify constraints (pseudo requirements)
Build the functional model:
Develop use cases to illustrate functionality requirements
Build the dynamic model:
Develop sequence diagrams to illustrate the interaction
between objects
Develop state diagrams for objects with interesting behavior
Build the object model:
Develop class diagrams showing the structure of the system
Problem Statement:
Direction Control for a Toy Car
Power is turned on
Car moves forward and car
headlight shines
Power is turned off
Car stops and headlight goes
out.
Power is turned on
Headlight shines
Power is turned off
Headlight goes out.
Power is turned on
Car runs backward with its
headlight shining.
Power is turned off
Car stops and
headlight goes out.
Power is turned on
Headlight shines
Power is turned off
Headlight goes out.
Power is turned on
Car runs forward
with its headlight
shining.
Find the Functional Model:
Do Use Case Modeling
Use case 1: System Initialization
Entry condition: Power is off, car is not moving
Flow of events:
Driver turns power on
Exit condition: Car moves forward, headlight is on
Use case 2: Turn headlight off
Entry condition: Car moves forward with headlights on
Flow of events:
Driver turns power off, car stops and headlight goes
out.
Driver turns power on, headlight shines and car does
not move.
Driver turns power off, headlight goes out
Exit condition: Car does not move, headlight is out
Use Cases continued
Use case 3: Move car backward
Entry condition: Car is stationary, headlights off
Flow of events:
Driver turns power on
Exit condition: Car moves backward, headlight on
Use case 4: Stop backward moving car
Entry condition: Car moves backward, headlights on
Flow of events:
Driver turns power off, car stops, headlight goes out.
Power is turned on, headlight shines and car does not
move.
Power is turned off, headlight goes out.
Exit condition: Car does not move, headlight is out.
Use cases continued
Use case 5: Move car forward
Entry condition: Car does not move, headlight is
out
Flow of events
Driver turns power on
Exit condition:
Car runs forward with its headlight shining.
Use Case Pruning
Do we need use case 5?
Use case 1: System Initialization
Entry condition: Power is off, car is not moving
Flow of events:
Driver turns power on
Exit condition: Car moves forward, headlight is on
Use case 5: Move car forward
Entry condition: Car does not move, headlight is out
Flow of events
Driver turns power on
Exit condition:
Car runs forward with its headlight shining.
Find the Dynamic Model:
Create sequence diagram
Name: Drive Car
Sequence of events:
Billy turns power on
Headlight goes on
Wheels starts moving forward
Wheels keeps moving forward
Billy turns power off
Headlight goes off
Wheels stops moving
...
Sequence Diagram for Drive
Car Scenario
:Headlight
:Wheel
Billy:Driver
Power(on)
Power(off)
Power(on)
Power(on)
Power(off)
Power(on)
Toy Car: Dynamic Model
State-Chart Diagram
Wheel
Headlight
Off
power
off
Forward
power
off
power
on
power
on
Stationary
Stationary
On
power
on
power
off
Backward
Toy Car: Object Model
Car
Power
Headlight
Wheel
Status: (On, Off)
Status: (On, Off)
TurnOn()
TurnOff()
Switch_On()
Switch_Off()
Motion:( Forward
Backward,
Stationary)
Start_Moving()
Stop_Moving()
For which system is a particular
model most relevant?
Object model: The system has non-trivial data
structures.
Dynamic model: The model has many different
types of events: Input, output, exceptions, errors,
etc.
Functional model: The model performs
complicated transformations such as difficult
computations consisting of many steps.
For which system is a particular
model most relevant?
Examples:
Compiler: Functional model most important. Dynamic
model is trivial because there is only one type input and
only a few outputs.
Database systems: Object model most important.
Functional model is trivial, because their purpose is
usually only to store, organize and retrieve data.
Spreadsheet program: Functional model most
important. Object model is trivial, because the
spreadsheet values are trivial and cannot be structured
further. The only interesting object is the cell.
Why Scenarios and Use Cases?
Comprehensible by the user
Use cases model a system from the users’ point of view
(functional requirements)
Define every possible event flow through the system
Description of interaction between objects
Use cases can form basis for whole development
process
User manual
System design and object design
Implementation
Test specification
Client acceptance test
Identifying Use Cases
Engage in a dialog, use an evolutionary,
incremental approach
You help the client to formulate the
requirements
The client helps you to understand the
requirements
The requirements evolve while the use
cases are being developed
How to Specify a Use Case
Name of Use Case
Actors
Precondition
Free form, informal natural language
Exceptions
Use a phrase such as “This use case starts when…”
Flow of Events
Description of actors involved in use case
Describe what happens if things go wrong
Special Requirements
List nonfunctional requirements and constraints
From Use Cases to
Requirement Analysis Model
Both focus on the requirements from the user
point of view.
Use cases use natural language (derived from
problem statement)
Written scenarios
Requirements analysis model uses formal or
semi-formal notation (UML)
System sequence diagrams
Domain model
Identify Conceptual Classes
Candidate classes are possible class names
that are being considered as candidates for
inclusion in the system.
Techniques:
noun phrase identification from use case
model or documentation
Brainstorming
CRC cards
Design patterns
Noun Phrase Identification
Read and understand the use case scenarios.
Look for noun phrases, mark the nouns
Divide into three categories
Definite object
Possible object
Nonsense object
Discuss “possible objects” and assign them to either
of the two other categories
Example
Computer system for library:
Books and Journals: The library contains books and
journals. There can be multiple copies a particular book.
Books can be borrowed by a library user for a period of
six weeks.
Loans: The system needs to keep track of which books
are on loan and when they are due.
Possible candidates for conceptual classes: library,
system, book, journal, copy, user, period, week, loan
Nonsense objects: week, system
Possible objects: library, period
Definite objects: book, journal, copy, loan, user
Definition: Object Modeling
Main goal: Find the important abstractions
Steps during object modeling
1. Class identification
Based on the fundamental assumption that we can
find abstractions
2. Find the attributes
3. Find the methods
4. Find the associations between classes
Order of steps
Goal: get the desired abstractions
Order of steps secondary, only a heuristic
Iteration is important
Class Identification
Identify the boundaries of the system
Identify the important entities in the system
Class identification is crucial to objectoriented modeling
Basic assumption:
1. We can find the classes for a new software
system (Forward Engineering)
2. We can identify the classes in an existing
system (Reverse Engineering)
Class Identification
Objects are not just found by taking a picture
of a scene or domain
The application domain has to be analyzed.
Depending on the purpose of the system
different objects might be found
How can we identify the purpose of a system?
Scenarios and use cases
Another important problem: Define system
boundary.
What object is inside, what object is outside?
Pieces of an Object Model
Classes
Associations (Relations)
Attributes
Part of- Hierarchy (Aggregation)
Kind of-Hierarchy (Generalization)
Detection of attributes
Is something an attribute or a class (e.g. money)
Methods
Detection of methods
Generic methods: General world knowledge, design
patterns
Domain Methods: Dynamic model, Functional model
Object vs Class
Object (instance): Exactly one thing
The lecture on Wednesday 19/9 from 8-10 on Analysis
A class describes a group of objects with similar properties
Sale, Customer, Item, Lecture…
Object diagram: A graphic notation for modeling objects,
classes and their relationships ("associations"):
Class diagram: Template for describing many instances of
data. Useful for taxonomies, patters, schemata...
Instance diagram: A particular set of objects relating to
each other. Useful for discussing scenarios, test cases and
examples
Class and Instance Diagrams
Inspector
joe:
Inspector
mary:
Inspector
Class Diagram
anonymous:
Inspector
Instance Diagram
Attributes and Values
Inspector
name:string
age: integer
joe:Inspector
mary: Inspector
name = “Joe”
age = 24
name = “Mary”
age = 18
Links and Associations
Links and associations establish relationships among
objects and classes.
Link:
A connection between two object instances. A link
is like a tuple.
A link is an instance of an association
Association:
Basically a bidirectional mapping.
One-to-one, many-to-one, one-to-many,
An association describes a set of links like a class
describes a set of objects.
1-to-1 and 1-to-N Associations
Country
has-capital
name
City
name
1-1 association
Order
date
contains
1-N association
Item
* price
productID
Object Instance Diagram
Example for 1-to-N
:Item
:Order
:Item
Price:5,50
ItemID : 23
Price:9,90
ItemID : 105
:Item
Price:105,00
ItemID : 98
Many-to-Many Associations
Customer
*
places
*
Order
Aggregation
Models "part of" hierarchy
Useful for modeling the breakdown of a product
into its component parts
UML notation: Like an association but with a
small diamond indicating the assembly end of
the relationship.
Aggregation
Automobile
serial number
year
manufacturer
model
color
weight
drive
purchase
Engine
horsepower
volume
on
off
3,4,5
Wheel
diameter
number of bolts
*
Brakelight
on
off
2,4
Door
open
close
Battery
amps
volts
charge
discharge
Inheritance
Models "kind of" hierarchy
Powerful notation for sharing similarities among classes
while preserving their differences
UML Notation: An arrow with a triangle
Cell
BloodCell
Red
White
MuscleCell
Smooth
Striate
NerveCell
Cortical
Pyramidal
Aggregation vs Inheritance
Both associations describe trees (hierarchies)
Aggregation tree describes “a-part-of
“relationships (also called and-relationship)
Inheritance tree describes "kind-of"
relationships (also called or-relationship)
Aggregation relates instances (involves two or
more different objects)
Inheritance relates classes (a way to structure
the description of a single object)
Other Associations
Uses:
An object uses another object : Player moves Token
Contains:
Sometimes called “spatial aggregation”
... contains ...
Example: an order contains items
Parent/child relationship:
... is father of ...
... is mother of ...
Seniority:
... is older than ...
... is more experienced than ...
Requirement Analysis
Challenging activity
Requires collaboration of people with different
backgrounds
User with application domain knowledge
Developer with implementation domain knowledge
Bridging the gap between user and developer:
Scenarios: Example of the use of the system in terms
of a series of interactions with between the user and
the system
Use cases: Abstraction that describes a class of
scenarios
System Model
Scenarios
- As-is scenarios, visionary scenarios
Use case model
- Actors and use cases
Object model
- Data dictionary
- Class diagrams (classes, associations, attributes
and behaviors)
Dynamic model
- State diagrams for classes with significant dynamic
behavior
- Sequence diagrams for collaborating objects
(protocol)
System Identification
Development of a system is not just done by
taking a snapshot of a scene (domain)
Definition of the system boundary
What is inside, what is outside?
How can we identify the purpose of a system?
Requirement Process:
Requirements Elicitation: Definition of the system in
terms understood by the customer (use cases)
Analysis: Technical specification of the system in terms
understood by the developer (sequence diagrams, class
diagrams)
Why different kinds of models?
Use case model (user oriented view of the domain)
Domain model (analysis model, analyst oriented view of
the domain)
Design model (view of software concepts in the domain)
Each type of model describes the same system but from a
different perspective and at a different level of abstraction.
They provide different kinds of information (e.g. dynamic,
static view of the system, or functionality oriented vs.
solution oriented)
Types of Requirements
Functional requirements: Describe the interactions
between the system and its environment independent from
implementation
The system must record sales.
Nonfunctional requirements: User visible aspects of
the system not directly related to functional behavior.
The response time must be less than 5 second
The display should be readable from 1 meter.
Constraints (“Pseudo requirements”): Imposed by the
client or the environment in which the system will operate
The implementation language must be JAVA.
Nonfunctional Requirements
Usability
Reliability
Performance
Supportability
Implementation
Interface
Operations
Nonfunctional Requirements
Usability: User interface and human factors
What type of user will be using the system?
Will more than one type of user be using the system?
What sort of training will be required for each type of
user?
Is it particularly important that the system be easy to
learn?
Is it particularly important that users be protected
from making errors?
What sort of input/output devices for the human
interface are available, and what are their
characteristics?
Nonfunctional Requirements
Usability : Documentation
What kind of documentation is required?
What audience is to be addressed by each
document?
Implemenation: Hardware considerations
What hardware is the proposed system to be used
on?
What are the characteristics of the target
hardware, including memory size and auxiliary
storage space?
Nonfunctional Requirements
Performance characteristics
Are there any speed, throughput, or response time
constraints on the system?
Are there size or capacity constraints on the data
to be processed by the system?
Reliability: Error handling and extreme
conditions
How should the system respond to input errors?
How should the system respond to extreme
conditions?
Nonfunctional Requirements
Interface
Is input coming from systems outside the
proposed system?
Is output going to systems outside the proposed
system?
Are there restrictions on the format or medium
that must be used for input or output?
Supportability : System Modifications
What parts of the system are likely candidates for
later modification?
Nonfunctional Requirements
Reliability : Quality issues
What are the requirements for reliability?
Must the system trap faults?
Is there a maximum acceptable time for
restarting the system after a failure?
What is the acceptable system downtime per
24-hour period?
Is it important that the system be portable
(able to move to different hardware or
operating system environments)?
What sorts of modifications are expected?
Nonfunctional Requirements
Physical Environment
Where will the target equipment operate?
Will the target equipment be in one or
several locations?
Will the environmental conditions in any
way be out of the ordinary (for example,
unusual temperatures, vibrations, magnetic
fields, ...)?
Nonfunctional Requirements
Reliability : Security Issues
Must access to any data or the system itself be
controlled?
Is physical security an issue?
Operation : Resources and Management Issues
How often will the system be backed up?
Who will be responsible for the back up?
Who is responsible for system installation?
Who will be responsible for system maintenance?
Pseudo Requirements
Pseudo requirement:
Any client restriction on the solution domain
Examples:
The target platform must be a SUN/SPARC
The implementation language must be JAVA
The documentation standard X must be used
A data-glove must be used
ActiveX must be used
The system must interface to a barcode reader
Prioritizing requirements
High priority (“Core requirements”)
Must be addressed during analysis, design, and
implementation.
A high-priority feature must be demonstrated successfully
during client acceptance.
Medium priority (“Optional requirements”)
Must be addressed during analysis and design.
Usually implemented and demonstrated in the second
iteration of the system development.
Low priority (“Fancy requirements”)
Must be addressed during analysis (“very visionary
scenarios”).
Illustrates how the system is going to be used in the
future if not yet available technology enablers are
Requirements Validation
Requirements validation criteria:
Correctness:
The requirements represent the client’s view.
Completeness:
All possible scenarios through the system are
described, including exceptional behavior by
the user or the system
Consistency:
There are functional or nonfunctional
requirements that contradict each other
Requirements Validation
Clarity:
There are no ambiguities in the
requirements.
Realism:
Requirements can be implemented and delivered
Traceability:
Each system function can be traced to a
corresponding set of functional requirements