ANALYSIS MODELING

Analysis bridges the gap between system level requirement engineering and software design Term originally coined by Douglas Ross and popularized by DeMarco If you don’t analyze problem, its highly likely that you will build a highly elegant software that solves the wrong problem

System Models

Analysis MODELS Functional Models Behavioral Models: Software transforms information To accomplish this, it must perform at least three generic functions Input Processing Output Behavioral Models: Most softwares responds to events from outside world This response characteristic forms the basis of the behavioral model

Analysis Models Process Specification Data object description State-transition Diagram Data object description Process Specification Entity Relationship diagram Data flow diagram Data Dictionary Control Specification

Data Flow Diagram (DFD) – It serves two purposes: Data Dictionary – A repository that contains description of all data objects consumed or produced by the software Entity Relationship Diagram (ERD) – depicts relationship between data objects Data Flow Diagram (DFD) – It serves two purposes: Provide an indication of how data is transformed To depict the functions that transform the data flow State Transition Diagram (STD) – It indicates how the system behaves as a consequence of external events

Product Specification: description of each function presented in DFD is contained in process specification (PSPEC) Control Specification: Additional information about control aspects of software are contained in control specification

DATA MODEL

Data Model An analysis method that models data objects and their relationships Data modeling is a process by which The data requirements within a given scope are grouped into objects called entities Relationships between those entities are documented A graphical representation called an entity-relationship diagram is produced.

Entity A data entity is anything real or abstract about which we want to store data. Entity types fall into five classes: roles, events, locations, tangible things or concepts. e.g. employee, payment, campus, book. Specific examples of an entity are called instances.

Concepts Data Objects Attributes Relationships Cardinality and Modality

Data Modeling Data objects – Any composite information that must be understood by the software External entity Thing Occurrence Role Organizational unit Place Structure

ENTITY TYPES Strong Entity Weak Entity Associative Entity Exist independently of other entity types Weak Entity Whose existence depends on some other entity type The entity type on which the weak entity type depends is known as “identifying owner” Associative Entity described in “relationships”

Define the properties of a data object They can be used to Attributes Define the properties of a data object They can be used to Name an instance of the data object Describe the instance Make reference to another instance in another table

identifier An attribute or combination of attributes that uniquely identifies individual instances of an entity type Has properties of Unique Not null Cannot change

Attribute Types Simple Attribute Composite attribute Cannot be broken down e.g. vehicle_color Composite attribute Some attributes can be broken down into meaningful component parts E.g. Address

Attribute Types Single valued attribute Multivalued attributes An attribute that take on more than one value for a given entity instance (e.g. skill) Stored attribute Derived attribute Whose value can be calculated from other information

Relationships It depicts the association between one or more data objects e.g: A bookstore displays books Associative Entities: presence of one or more attributes on a relationship Weak entities are identified through an “identifying relationship” with their owner entity

Basic Symbols Associative Entity Strong Entity Weak Entity Attribute Relationship Multivalued Attribute Derived Attribute Identifying Relationship

Cardinality Cardinality defines It is the specification of the number of occurrences of one object that can be related to the number of occurrences of another object  One-to-one One-to-many Many-to-many

Modality Defines the need for the relationship to occur Modality = 0 Optional Modality = 1 Mandatory

Entity Relationship Diagram(ERD)–Notation One common form: (0, m) object relationship object 1 2 (1, 1) attribute Another common form: object relationship object 1 2 (0, m) (1, 1)

Example: ERD places Member Order setup_for Product

The ERD: An Example request for service Customer places (1,1) (1,m) standard task table (1,n) work order generates (1,1) (1,1) (1,1) work tasks (1,w) selected from consists of (1,w) (1,i) materials lists

Functional Modeling Every computer-based system is an information transform .... computer based system input output

Data Flow Diagram Data flow diagramming shows business processes and the data that flows between them Data flow diagrams illustrate how data is processed by a system in terms of inputs and outputs. The Data Flow Diagram shows the flow of data or information.

Four Basic Elements A dataflow diagram consists of External Entities Processes Data Flow Data Stores

DFD Elements

DFD Shapes from Visio

External Entities Represent people or organizations outside of the system being studied Shows the initial source and final recipient of data and information Should be named with a noun, describing that entity

External Entities External entities may be A person, such as CUSTOMER or STUDENT A company or organization, such as BANK or SUPPLIER Another department within the company, such as ORDER FULFILLMENT Another system or subsystem, such as the INVENTORY CONTROL SYSTEM

Processes Represent either: A whole system A subsystem Work being done, an activity Names should be in the form verb-adjective-noun

Data Stores Name with a noun, describing the data Data stores are usually given a unique reference number, such as D1, D2, D3 Include any data stored, such as: A computer file or database A transaction file A set of tables A manual file of records sensor # sensor #, type, location, age look-up sensor data report required type, location, age sensor number sensor data

Data Flow Shows the data about a person, place, or thing that moves through the system Names should be a noun that describes the data moving through the system Arrowhead indicates the flow direction Use double headed-arrows only when a process is reading data and updating the data on the same table or file compute triangle area base area height

Developing Data Flow Diagrams Use the following guidelines: Create the context level diagram, including all external entities and the major data flow to or from them Create Diagram 1 by analyzing the major activities within the context process Include the external entities and major data stores Create a child diagram for each complex process on Diagram 1

Creating Data Flow Diagrams Detailed data flow diagrams may be developed by Making a list of business activities Analyzing what happens to an input data flow from an external entity Analyzing what is necessary to create an output data flow to an external entity Examining the data flow to or from a data store Analyzing a well-defined process for data requirements and the nature of the information produced Unclear areas of a data flow diagram should be noted and investigated

Data Flow Diagram Levels Data flow diagrams are built in layers The top level is the Context level Each process may explode to a lower level The lower level diagram number is the same as the parent process number Processes that do not create a child diagram are called primitive

Context Level Data Flow Diagram The level 0 DFD should depict the software/system as a single bubble Contains only one process, representing the entire system The process is given the number zero All external entities are shown on the context diagram as well as major data flow to and from them The diagram does not contain any data stores

Several Common Modeling Rules All processes must have at least one data flow in and one data flow out. All processes should modify the incoming data, producing new forms of outgoing data. Each data store must be involved with at least one data flow Each external entity must be involved with at least one data flow A data flow must be attached to at least one process.

Key Definitions Decomposition is the process of modeling the system and its components in increasing levels of detail Balancing involves ensuring that information presented at one level of a DFD is accurately represented in the next level DFD.

A data flow diagram

Context Level DFD

Level 1 DFD

Behavioral Model events behavior Outside world Application

Behavioral Modeling make a list of the different states of a system (How does the system behave?) indicate how the system makes a transition from one state to another (How does the system change state?) indicate event indicate action draw a state transition diagram

State Transition Diagram (STD) It highlights the time-dependent behavior of a system. It shows ‘what’ happens ‘when’ Major components States Transitions between states Useful for describing behavior of real-time systems, interactive systems

The States of a System State — a set of observable circum-stances that characterizes the behavior of a system at a given time State Transition — the movement from one state to another Event — an occurrence that causes the system to exhibit some predictable form of behavior Action — process that occurs as a consequence of making a transition

Example: State Transition Diagram RButton-down / display PopUp Menu Idle Menu visible RButton-up / erase PopUp Menu Cursor-moved / highlight Menu item

State Transition Diagram Notation event causing transition action that occurs new state

Example

The Control Specification (CSPEC) Describes the behavior of a system by identifying its states; identify how each state is reached and define the transition between states focuses on possible omissions ... a very common error in specifying control, e.g., ask: "Is there any other way I can get to this state or exit from it?" The CSPEC contains A State Transition Diagram A Process Activation Table

The Process Specification (PSPEC) It is used to describe all the flow model processes that appear at the final level of refinement PSPEC narrative pseudocode (PDL) equations tables diagrams and/or charts bubble

Creating Mini-Specs Software Specification

The Data Dictionary (DD) The data dictionary is an organized listing of all data elements that are relevant to the system with precise rigorous definitions so that both the user and the system analyst will have a common understanding of inputs, outputs, components of stores and [even] intermediate calculations

Information contained in DD Name: the primary name of the composite data item Aliases: other names for the data item Where used: data transforms (processes) that use the composite data item How used: the role of the data item (input, output, temporary storage, etc.) Content Description: a notation for representing content (presented on next slide) Supplementary information: specific information about data types

Data Construct Notation Meaning = Is composed of Sequence + And Selection [|] Either-or Repetition {}n n repetitions of () Optional data *…* Delimits comments

Name: Telephone number Aliases: none Where used/how used: assess against set-up (output) dial phone (input) Description: telephone number = [local number | long distance number] local number = prefix + access number long distance number = 1 + area code + local number area code = [800 | 888 | 561] prefix = *a three digit number that never starts with 0 or 1* access number = *any four number string *

The Data Dictionary The data dictionary is an organized listing of all data elements pertinent to the system with precise rigorous definitions so that both user and SA will have common understanding of all data elements. It describes: meaning and composition of data flows, data stores relevant values and units of elementary data elements details of relationships between stores that are highlighted in a ERD

Data Dictionary Notation Example: customer-name = title + first-name + (middle-name) + last-name title = [Mr. | Miss | Ms. | Mrs.| Dr. | Prof. ] first-name = {legal-character} order = customer-name + shipping-addr + {item}

Credits: Chapter 8 : Software Engineering - A practitioner’ s Approach by Roger S. Pressman (6th Edition) Chapter 3: A Modern Database Management by Fred R. mcFadden, Jeffrey A. Hoffer, Mary B. Prescott (5th Edition) Lecture Slides, Dr. Fakhar Lodhi VU CS504