Analysis Modeling

Analysis Modeling
At a technical level, software engineering begins with a series of modeling tasks that lead to a complete specification of requirements and a comprehensive design representation for the software to be built. The analysis model actually a set of models , is the first technical representation of a system. Structured analysis and Object oriented analysis is generally used to defined software projects.

Structured Analysis
Structured analysis is a model building activity. For operational analysis we crate models that depicts information (data and control) content and flow ,we partitioned system functionality and behaviorally and we depict the essence of what must be built.

Elements of data modeling

The analysis modeling must achieve three goals
1) To describes what the customer requires. 2) To establish a basis for the creation of a software design 3) To define a set of requirement that can be validated once the software is built.

Entity Relationship Diagram

Data Flow Diagram

Data Dictionary

State Transition Diagram Control Specification

The Structure of the Analysis Model

Analysis Modeling domain

Data Modeling Functional Modeling Behavioral Modeling

Data Modeling
Data modeling give the answer of the following functions
What are the primary data objects to be processes by the system. What is the composition of each data object and what attributes describes the objects. Where do the objects currently reside ? What is the relationship between the objects and processes that transform them?

Data model consists of three interrelated pieces of information

Data Objects
Data object: it is the representation of any composite information. Composite means it has number of different properties.
Data object can be an external entity(anything that produces or consume information) a thing(salesperson) An organizational unit(purchase department) A place(warehouse) a structure(a file)

Data objects
Data can be defined in terms of a set of attributes. Data object description used to incorporates the data object and all of its attributes. Data objects are related to each other. A data object encapsulate data only, there is no reference within a data object operations that act on the data.

Attributes
Attributes define the properties of data objects and have following characteristics They can be used
Name an instance of the data object Describes the instance Make reference to another instance of the data object

One or more attributes defines as a key.

Relationship
Data objects are connected to one another in a variety of different ways. With this relationship we can define a set of object-relationship pairs that define that relevant relationship. It is important that object relation pairs are bidirectional.

Cardinality and modality

The data model must be capable of representing the number of occurrences of objects in a given relationship. Cardinality is the specification of representing the number occurrences of one object can be related to the number of occurrences of another object. Cardinality usually expressed as simply one or many. by this objects can be related as
One to one(1:1) One to many(1:N) Many to many(M:N)

Modality
The modality of a relationship is zero if there is no explicit need for the relationship to occur or the relationship is optional. The modality is 1 if an occurrence of relationship is mandatory.

Cardinality and Modality

Cardinality: Single user awaits repair action
Customer

Cardinality: There may be many repair action(s)

Repair action

Is provided with

Modality: Mandatory Implies that in order to have a repair action(s),we must have a customer.

Modality: Optional Implies that there may be a situation in which a repair action is not necessary.

Entity Relationship Diagram

The object-relationship can be represented graphically using Entity-Relationship Diagram(ERD). A set of components are indentified for the ERD: data objects, attributes, relationship and various type indicators. The primary purpose of the ERD if to represent data objects and their relationship.

Example: ERD
Licenses Dealership Stocks

Manufacturer

Build

Car

Transports

Contracts

Shipper

Object type hierarchy

Car

European

Domestic

Asian

Swedish

German

French

Italian

Japanese

Korean

Associate data Objects

Electronics Drive train

Engine

chasis

interior

Car

Functional Modeling
Information is transformed as it flow through a computer based system. Information flow models are used to show the flow of the information of the system . Overall function of the system is represented as a single information transform noted as bubble. One or more inputs shown as labeled arrows , external entities represented as a box. Output information also shown as boxes .

DFD: Data Flow Diagram

DFD is a graphical technique that depict information flow and the transforms that are applied as data moves from input to output. DFD also called bubble chart. DFD can be used to represent a system or software at any level of abstraction. DFD may be partitioned into levels that represent increasing information flow and functional details.

Data Flow Diagram

A level 0 DFD, also called functional system model or a context model. It represents the entire software element as a single bubble with input and output data indicated y incoming and outgoing arrows , respectively. Additional processes and information flow paths are represented as the level 0 DFD is partitioned to reveal more detail.

External entity

A producer or consumer of information that resides outside the bounds of the system to be modeled. A transformer of information (a function ) that resides within the bounds of the system to be modeled
A data object; the arrowed indicated the direction of data flow

Process

Data object Data store

A repository of data that is to be stored for use by one or more processes; may be as simple as a buffer or queue or as simple or as sophisticated as relational database.

Notations for DFD

Simple guidelines for the DFD

The level 0 data flow diagram should depict the software /system, as single bubble. Primary input and output should be carefully noted Refinement should begin be isolating candidate processes, data objects and stores to be represented at the next level All arrow and bubbles should be labeled with meaningful names Information flow continuity must be maintained from level to level. One bubble at a time should be refined.

Control Panel

User commands and data

Display information

Control Panel Display

Alarm Type SafeHome Software Sensor status

Alarm

sensor

Telephone number tones

Telephone line

Processing Specification
DFD notation can be used to for processing specification. A processing specification (PSPEC) can be used to specify the processing detains implied by a bubble within a DFD. The processing specification describes the input to a function ,the algorithm that is applied to the input and the output that is produced. PSPEC also indicates restrictions and limitations imposed on the process (function), performance characteristics that are relevant to the process, design constraints that may influence the process implementation.

DFD extension for Real Time System

A real time system must interact with the real world in a time frame dictated by the real world. There are 2 extension for the Real Time System
Ward and Mellor Hatley and Pirbhai

These extension enable a analyst to represent control flow and control processing as well as data flow and processing.

Ward and Mellor Extension

Requirements of real time system
Information flow that is gathered or produced on a time-continuous basis Control information passes through out the system and control processing associated Multiple instances of the same transformation, which are sometime encountered in multitasking situation System states and the mechanism that causes transition between states.

Following are the notation used for RTS

Quasicontinuous data flow

control process

A data object that is input or output from a process on a continuous basis

A transformer of control or events; accepts control and input and produces control as output
Control item or events; takes on a Boolean or discrete value; the arrowhead indicates the direction of data flow A repository of control items that are to be stored for use by one or more processes Multiple equivalent instances of the same process; used when multiple processes are created in multitasking system

Control Item
Control Store

Process

Monitored temperature
Input continuously output continuously Corrected Value

Monitor and adjust temperature Level

Temperature SetPoint

Time Continuous data flow

Status of each fixture Movement alarm Parts status buffer Robot initiation control

Bit string

Start /stop flag Monitor fixture & operator interface

Process activate Operator setting Position command Process robot command

Operator commands

Robot movement records Robot command file

Hatley and pirbhai Extensions

A control item or event; takes on a boolean or discrete value; the arrowed indicates the direction of data flow The vertical bar is references to a control specifications(CSPEC) that describes the behavior of a system and defines how processes are activated as a consequences of events

Hatley and Pirbhai Extension

Extension suggest that dashed and solid notation be represented separately . Therefore , a control flow diagram is defined. The CFD contains the same processes as a DFD control flow rather than data flow. Instead of representing control processes directly , a notational reference to a control specification (CSPEC) is used. With the notation of DFD and extension and PSPEC and CSPEC hateky and pirbhai create a model of real time system.

Data Input

Process model
DFD

Data output

PSPEC
Process Activators Data Conditions

Control Model
CFD

Control output

CSPEC Control Input

Relationship between data and control model

Control Flow Diagram

Control flow diagrams are used to class of application which are driven by events rather than data. The hately and pribhai notations are used for the control flow diagram. The CFD contains some of the process as DFD, but shows control flow rather than data flow. Instead of representing control processes directly within the flow model, a notational reference to a control specification.

Creation of CFD
For CFD a data flow model is stripped of all data flow arrows. Events and control items are than added to diagram and a window into the control specification is shown.

Control Panel

User Command and data

Level 1 DFD for SafeHome

Configure request Configuration data Configuration information a/d message Configurati on data Control Display panel Information Display Sensor Information Alarm type Telephone number tone

Start /Stop
Password

Process passwo rd

Valid id msg. Configuration data Monit or sensor

Alarm

Sensor Status Sensor Telephone Line

Control Panel Config ure system Start /stop switch Activa te /deact ivate Process passwo rd Blink flag

Level 1 CFD for SafeHome

Display action status (complete, in progress

Interact with user

Display messag e and status Monit or sensor Alarm status

Control panel Display Timeout

Sensor Event Sensor

Alarm Signal

Alarm

Telephone Line

The control Specification

The control specification represents the behavior of the system in two different ways. 1) State Transition Diagram: Sequential specification of behavior 2) Process activation table: a combinatorial specification of behavior

Start/stop switch Invoke monitor and control system

State Transition Diagram

Reading user input

Sensor event Invoke Monitor and control system Monitoring system status Sensor event Invoke display Massage and status Sensor event Invoke display message and status

Time out Invoke interact with user

Acting on a sensor event

Sensor event Invoke monitor and control system Displaying user feedback

Blink flag Invoke display Message and status

Display action status Invoke interact with user