Lecture No.

Analysis Modeling
- Requirements analysis
- Flow-oriented modeling
- Scenario-based modeling
- Class-based modeling
- Behavioral modeling
Requirements Analysis
• Requirement analysis allows the software engineer elaborate on basic
requirements established during earlier requirement engineering task
and build models based on user scenarios, functional activities, system
and class behaviour, flow of data etc

• It provides the SW designer with representation of information,

function, and behaviour that can be translated to architectural, interface
and component – level design.

• Provides the developer and customer with the means to assess quality
once the software is built
 Analysis Modeling Principles
 Analysis methods are related by a set of operational principles:
1. The information domain of a problem must be represented and
understood.
2. The functions that are software performs must be defined.
3. The behavior of the software must be represented.
4. The models that depict information, function and behavior must
be partitioned in a manner that uncovers detail in a layered
fashion.
5. The analysis task should move from essential information toward
implementation detail.
 Analysis Modeling Principles
1. Information domain encompasses that the data flow into
the system, out of the system and data stored.
2. Functions provide direct benefit to end-users and also
provide internal support for those features that are user
visible.
3. Behavior driven by its interaction with the external
environment.
E.g. Input provided by end-users, control data provided by
an external system, or monitoring data.
Analysis Modeling Principles
4. Key strategy of analysis model, divide complex problem into sub-problem
until each sub-problem is relatively easy to understood. This concept is
called partitioning.
5. The “essence” of the problem is described without any consideration of how
a solution will be implemented.
E.g. Video game requires that player “instruct”

Implementation detail (design model) indicates how the essence will be

implemented
E.g. Keyboard command might be typed or a joystick used.
 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

All elements of an analysis model are directly traceable to parts of the

design model, and some parts overlap
Analysis Model - A Bridge
Goals of Analysis Modeling

• To provide a description of the required informational, functional,

and behavioural domains for a computer based system

• This model changes dynamically as the SW Engineer learn more

about the system, and stakeholders

• Provides the first technical representation of a system

• Analysis model is a snapshot of requirements at any given time.

A Set of Models
Scenario-based modeling – represents the system from the user's point
of view

Class-based modeling – defines objects, attributes, and relationships

Behavioral modeling – depicts the states of the classes and the impact of
events on these states

Flow-oriented modeling – provides an indication of how data objects are

transformed by a set of processing functions

3
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
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
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 …
 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
13
 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
Example Activity Diagram
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
 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)
 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
 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
Example Class Box

Class Name Component

componentID
telephoneNumber
Attributes componentStatus
delayTime
masterPassword
numberOfTries
program()
display()
Operations reset()
query()
modify()
call()
 Example Class Diagram
Accountant Auditor Record
Keeper

Input Production Transaction

Verifier Manager Processor

Report Account List

Error Log Input Handler Account
Generator

1..n

Local File Remote File Accounts Accounts

Handler Handler Receivable Payable

24
Behavioral Modeling
Behavioral Modeling
• The behavioural model indicates how software will respond to external events
• Identify events found within the use cases and implied by the attributes in the
class diagrams
• Build a state diagram for each class, and if useful, for the whole software
system
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
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
• The active state of an object indicates the current overall status of the object
as is goes through transformation or processing
– A state name represents one of the possible active states of an object
• The passive state of an object is the current value of all of an object's
attributes
28
State Diagram for the Control Panel Class of SafeHome Security System
Flow-oriented Modeling
 Data Modeling
• Identify the following items
– Data objects (Entities)
– Data attributes
– Relationships
– Cardinality (number of occurrences)

31
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

32
Diagram Layering and
Process Refinement

Context-level diagram

Level 1 diagram

33
Process Specification
 What is a Data Flow Diagram?
• A data flow diagram (DFD) is a graphical
tool that allows system analysts (and
system users) to depict the flow of data in
an information system.
• The DFD is one of the methods that
system analysts use to collect information
necessary to determine information system
requirements.
 What is a Data Flow Diagram?
• A Data Flow Diagram is intended to serve
as a communication tool among
– systems analysts
– end users
– data base designers
– system programmers
– other members of the project team
 DFD Symbols and Definitions
• Process - performs some action on data, such
Process as creates, modifies, stores, delete, etc. Can be
manual or supported by computer

• Data store - information that is kept and

Data store accessed. May be in paper file folder or a
database.

• External entity - is the origin or destination of

External
data. Entities are external to the system
Entity
• Data flow - the flow of data into or out of a
Data flow process, datastore or entity
Rules for Drawing DFD’s

A minimum of one data flow in and one data flow

out of a process

A datastore must be connected to a process

(either in, out, or both)

An external entity must be connected to a

process (either in, out, or both)

A single data flow must only flow one way