Analysis Model

Overview
analysis model is the first technical representation of a system. Analysis modeling uses a combination of text and diagrams to represent software requirements (data, function, and behavior) in an understandable way. Building analysis models helps make it easier to uncover requirement inconsistencies and omissions. Two types of analysis modeling are commonly used: structured analysis object-oriented analysis object Data modeling uses entity-relationship diagrams to define data entityobjects, attributes, and relationships. Functional modeling uses data flow diagrams to show how data are transformed inside the system. Behavioral modeling uses state transition diagrams to show the impact of events. Analysis work products must be reviewed for completeness, correctness, and consistency.
The

Analysis Modeling Approaches



Structural analysis:


The data: The model defines their attributes and data: relationships. relationships. The processes that transform the data: The model shows how they transform the data objects as they flow through the system. Focus: Classes and their inter-relationships interUML is predominantly object-oriented object-

ObjectObject-oriented analysis:
 

Structured Analysis (DeMarco)

Analysis products must be highly maintainable, especially the software requirements specification. Problems of size must be dealt with using an effective method of partitioning. Graphics should be used whenever possible. Differentiate between the logical (essential) and physical (implementation) considerations. Find something to help with requirements partitioning and document the partitioning before specification. Devise a way to track and evaluate user interfaces. Devise tools that describe logic and policy better than narrative text.

Analysis Model Objectives

Describe what the customer requires.

Establish a basis for the creation of a software design. Devise a set of requirements that can be validated once the software is built.

Elements of the Analysis Model

Scenario-based elements Flow-oriented elements Use-case diagrams Use cases - text Activity Diagrams Swim lane diagrams Analysis Model Class-based elements Class diagrams Analysis Packages CRC Models Collaboration Diagrams Behavioral elements State diagrams Sequence diagrams Data-flow diagrams Control flow diagrams Processing narratives

Analysis Model Elements

Data dictionary - contains the descriptions of all data objects consumed or produced by the software Entity relationship diagram (ERD) - depicts relationships between data objects Data flow diagram (DFD) - provides an indication of how data are transformed as they move through the system; also depicts functions that transform the data flow (a function is represented in a DFD using a process specification or PSPEC) State transition diagram (STD) - indicates how the system behaves as a consequence of external events, states are used to represent behavior modes. Arcs are labeled with the events triggering the transitions from one state to another (control information is contained in control specification or CSPEC)

Data Modeling


 

examines data objects independently of processing focuses attention on the data domain creates a model at the customers level of abstraction indicates how data objects relate to one another

Data Modeling Elements

Data object - any person, organization, device, or software product that produces or consumes information Attributes - name a data object instance, describe its characteristics, or make reference to another data object Relationships - indicate the manner in which data objects are connected to one another

What is a Data Object?

Object something that is described by a set of attributes (data items) and that will be manipulated within the software (system) each instance of an object (e.g., a book) can be identified uniquely (e.g., ISBN #) each plays a necessary role in the system i.e., the system could not function without access to instances of the object each is described by attributes that are themselves data items
What are some typical data objects?

Typical Data Objects

external entities (printer, user, sensor) things (e.g, reports, displays, signals) occurrences or events (e.g., interrupt, alarm) roles (e.g., manager, engineer, salesperson) organizational units (e.g., division, team) places (e.g., manufacturing floor) structures (e.g., employee record)

A data object contains a set of attributes that act as an aspect, quality, characteristic, or descriptor of the object object: automobile attributes: make model body type price options code

Data Objects and Attributes

How do data objects differ from OO classes or do they?

Attributes

What is a Relationship?
relationship indicates connectedness; a "fact" that must be "remembered" by the system and cannot or is not computed or derived mechanically

 

several instances of a relationship can exist objects can be related in many different ways

    

A bookstore orders books. A bookstore displays books. A bookstore stocks books. A bookstore sells books. A bookstore returns books

Cardinality and Modality

Cardinality - in data modeling, cardinality specifies how the number of occurrences of one object are related to the number of occurrences of another object (1:1, 1:N, M:N) Modality - zero (0) for an optional object relationship and one (1) for a mandatory relationship

ERD model:


 

- ERD is a very useful method for data modeling. - It focuses on data, representing a data network in the system. - It represents: data objects, object attributes, and relationships between objects

ERD Notation
One common form: object1
(0, m)
relationship

(1, 1)

object 2
attribute

Another common form: object1

(0, m) relationship (1, 1)

object 2

See http://www.smartdraw.com/tutorials/software/erd/tutorial_01.htm for a tutorial on how to draw entity relationship diagrams.

The ERD: An Example

Customer (1,1)
places

(1,m)

request for service (1,1)

standard task table (1,1)

selected from

generates

(1,n)

work order (1,1)

(1,1) work (1,w) tasks materials (1,w)

consists of

(1,i)

lists

Data Flow Diagrams



DFDs - graphic representation of the flow of data through a system; can be physical DFDs or logical DFDs

Flow Modeling Notation

external entity

process

data flow data store

External Entity
A producer or consumer of data Examples: a person, a device, a sensor Another example: computer-based computersystem Data must always originate somewhere and must always be sent to something

Process
A data transformer (changes input to output) Examples: compute taxes, determine area, format report, display graph Data must always be processed in some way to achieve system function

Data Flow
Data flows through a system, beginning as input and be transformed into output.
base compute triangle area area

height

Data Stores
Data is often stored for later use.
sensor # sensor #, type, location, age

report required

looklook-up sensor data

sensor number

type, location, age

sensor data

Data Flow Diagramming: Guidelines

 

  

all icons must be labeled with meaningful names the DFD evolves through a number of levels of detail always begin with a context level diagram (also called level 0) always show external entities at level 0 always label data flow arrows do not represent procedural logic

State transition diagrams represent the system states and events that trigger state transitions  STD's indicate actions (e.g., process activation) taken as a consequence of a particular event  A state is any observable mode of behavior  It shows how system moves from state to state  Hatley and Pirbhai control flow diagrams (CFD) and UML sequence diagrams can also be used for behavioral modeling  Behavior modeling is also referred to as State modeling, State machines and State transition matrix.


Behavioral Modeling (STD)

Behavioral Modeling


The behavioral model indicates how software will respond to external events or stimuli. To create the model, the analyst must perform the following steps:


  

Evaluate all use-cases to fully understand the sequence of useinteraction within the system. Identify events that drive the interaction sequence and understand how these events relate to specific objects. Create a sequence for each use-case. useBuild a state diagram for the system. Review the behavioral model to verify accuracy and consistency.

State Representations


In the context of behavioral modeling, two different characterizations of states must be considered:
 

the state of each class as the system performs its function and the state of the system as observed from the outside as the system performs its function

The state of a class takes on both passive and active characteristics [CHA93].


A passive state is simply the current status of all of an objects attributes. The active state of an object indicates the current status of the object as it undergoes a continuing transformation or processing.

The States of a System



state statea set of observable circum-stances that circumcharacterizes the behavior of a system at a given time state transitionthe movement from one state to transition another event eventan occurrence that causes the system to exhibit some predictable form of behavior action actionprocess that occurs as a consequence of making a transition

Level 1 CFD for Photocopier Software

STD for Photocopier Software

The Mechanics of SA

Creating Entity Relationship Diagrams



  

  

Use ERDs to specify - the data objects (input, internal, and output data objects), - the attributes inside data objects - the relationships between them - their cardinality and modality Customer asked to list "things" that application addresses, these things evolve into input objects, output objects, and external entities Analyst and customer define connections between the objects One or more object-relationship pairs is created for each connection objectThe cardinality and modality are determined for an object-relationship objectpair Attributes of each entity are defined The entity diagram is reviewed and refined Steps are repeated until data modeling is complete

Establishing Connections

Object/Relationship Pairs

Developing relationships and cardinality /Modality

Attributes of the object



Sensor Object Sensor type Internal Identification Number Zone Location Alarm Level

Creating Data Flow Diagram



 

   

level 0 data flow diagram should depict the system as a single bubble Primary input and output should be carefully noted Refinement should begin by consolidating candidate processes, data objects, and data stores to be represented at the next level Label all arrows & bubbles with meaningful names Information flow must be maintained from one level to level Refine one bubble at a time Write a PSPEC (a "mini-spec" written using English or "minianother natural language or a program design language) for each bubble in the final DFD

Context level DFD for safe home

Level 1 DFD for safe home

Level 2 DFD for safe home

Creating Control Flow Diagrams



Begin by stripping all the data flow arrows form the DFD Events (solid arrows) and control items (dashed arrows) are added to the diagram Add a window to the CSPEC (contains an STD that is a sequential specification of the behavior) for each bubble in the final CFD

Guidelines for selecting the candidate events

Level 1 CFD for safe home

Control Specification (CSPEC)

The CSPEC can be: state diagram (sequential spec) state transition table decision tables activation tables combinatorial spec

STD for Safe Home

Process Activation table for safe home

Process Specification


 

It used to describe all flow model processes that appear at the final level of refinement It is a mini spec in SRS Guide for the design of the software component that will implement the process

Process Specification (PSPEC)

bubble

PSPEC narrative pseudocode (PDL) PDL) equations tables diagrams and/or charts

Data Dictionary


It is proposed as quasi formal grammar for describing the content of objects defined during SA. The data dictionary is an organized listing of all data elements that are pertinent to the system, with precise, rigorous definitions so that both user and system analyst will have a common understanding of inputs, outputs, components of stores and intermediate calculations

Data Dictionary Contents

  

 

Name - primary name for each data or control item, data store, or external entity Alias - alternate names for each data object Where-used/howWhere-used/how-used - a listing of processes that use the data or control item and how it is used (e.g. input to process, output from process, as a store, as an external entity) Content description - notation for representing content Supplementary information - other data type information, preset values, restrictions, limitations, etc Checks for the consistency and helps to reduce errors.

   

Where is the data object used ? What else will have to change if we modify it What will the overall impact of the change be Notation used in content description

  

The notation enables a software engineer to represent composite data in one of the 3 fundamentals ways that it can be constructed: As a sequence of data items As a selection from among a set of data items As a repeated grouping of data items

Example

Advantages & Disadvantages

Advantages  Improves consistency  Reduce errors  Defines Information items unambiguously Disadvantages  For large computer based systems, the data dictionary grows rapidly in size and complexity.  Difficult to maintain it manually