Analysis Modelling
The requirements model as a bridge between
the system description and the design model
Analysis Rules of Thumb
The model should focus on requirements that are visible
within the problem or business domain.
Each element of the requirements 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
nonfunctional models until design.
Minimize coupling throughout the system.
Be certain that the requirements model provides value
to all stakeholders.
Keep the model as simple as it can be.
Analysis Model
Elements of the analysis model
Scenario-Based Modeling
Use-case Diagram
Use-case diagram for surveillance function
Alternative Actions
Can the actor take some other action at this
point?
Is it possible that the actor will encounter
some error condition at this point?
Is it possible that the actor will encounter
behavior invoked by some event outside the
actor’s control?
Activity diagram for
Access camera
surveillance—display
camera views function
Swimlane
diagram
Flow-Oriented Modeling
The DFD takes an input-process-output view of a system.
Data objects are represented by labeled arrows, and
transformations are represented by circles (also called
bubbles).
The DFD is presented in a hierarchical fashion. That is, the
first data flow model (sometimes called a level 0 DFD or
context diagram) represents the system as a whole.
Subsequent data flow diagrams refine the context
diagram, providing increasing detail with each subsequent
level.
Guidelines
Depict the system as single bubble in level 0.
Carefully note primary input and output.
Refine by isolating candidate processes and their
associated data objects and data stores.
Label all arrows and bubbles with meaningful names.
Maintain information conformity between levels.
Refine one bubble at a time.
Data Flow Diagram
Context-level DFD for SafeHome security function
Grammatical Parse
The SafeHome security function enables the homeowner to configure the security
system when it is installed, monitors all sensors connected to the security system, and
interacts with the homeowner through the Internet, a PC, or a control panel.
During installation, the SafeHome PC is used to program and configure the system.
Each sensor is assigned a number and type, a master password is programmed for
arming and disarming the system, and telephone number(s) are input for dialing when a
sensor event occurs.
When a sensor event is recognized, the software invokes an audible alarm attached to
the system. After a delay time that is specified by the homeowner during system
configuration activities, the software dials a telephone number of a monitoring service,
provides information about the location, reporting the nature of the event that has been
detected. The telephone number will be redialed every 20 seconds until a telephone
connection is obtained.
The homeowner receives security information via a control panel, the PC, or a browser,
collectively called an interface. The interface displays prompting messages and system
status information on the control panel, the PC, or the browser window. Homeowner
interaction takes the following form…
Referring to the grammatical parse, verbs are SafeHome
processes and can be represented as bubbles in a subsequent
DFD. Nouns are either external entities (boxes), data or
control objects (arrows), or data stores (double lines).
nouns and verbs can be associated with one another (e.g.,
each sensor is assigned a number and type; therefore
number and type are attributes of the data object
sensor).
by performing a grammatical parse on the processing
narrative for a bubble at any DFD level, you can generate
much useful information about how to proceed with the
refinement to the next level.
Level 2 DFD that refines the monitor sensors process
Control Flow Diagram
State diagram for SafeHome security function
Class-Based Modeling
Identifying Analysis
Classes
External entities that produce or consume
information
Things that are part of the information domain
Occurrences or events
Roles played by people who interact with the
system
Organizational units
Places that establish context
Structures that define a class of objects
Class Selection Criteria
1. Retained information
2. Needed services
3. Multiple attributes
4. Common attributes
5. Common operations
6. Essential requirements
Identifying Classes
Potential class Classification Accept / Reject
homeowner role; external entity reject: 1, 2 fail
sensor external entity accept
control panel external entity accept
installation occurrence reject
(security) system thing accept
number, type not objects, attributes reject: 3 fails
master password thing reject: 3 fails
telephone number thing reject: 3 fails
sensor event occurrence accept
audible alarm external entity reject: 1 fails
monitoring service organizational unit; ee reject: 1, 2 fail
Class Diagram
Class diagram for the system class
Class Diagram
Class diagram for FloorPlan
CRC Modeling
A CRC model index card for FloorPlan class
Class Responsibilities
Distribute system intelligence across classes.
State each responsibility as generally as possible.
Put information and the behavior related to it in the
same class.
Localize information about one thing rather than
distributing it across multiple classes.
Share responsibilities among related classes, when
appropriate.
Class Collaborations
Relationships between classes:
is-part-of — used when classes are part of an
aggregate class.
has-knowledge-of — used when one class must
acquire information from another class.
depends-on — used in all other cases.
Class Diagrams
Top: Multiplicity
Bottom: Dependencies
Behavioral Modeling
Identifying Events
A use-case is examined for points of information
exchange.
The homeowner uses the keypad to key in a four-digit
password. The password is compared with the valid
password stored in the system. If the password in
incorrect, the control panel will beep once and reset itself
for additional input. If the password is correct, the control
panel awaits further action.
State Diagram
State diagram for the ControlPanel class
Sequence Diagram
Sequence diagram (partial) for the SafeHome security function
