CS615 – Software Engineering I
Lecture 4

Analysis Modeling (Chapter 12)

Analysis Model

Structured Analysis (DeMarco)

Analysis Model Objectives


 

Analysis Model Elements

Analysis Modeling: Where to Begin?

Data Modeling Elements (ERD)


 


 

Cardinality and Modality (ERD)

Entity/Relationship Diagrams

A simple ERD and data object table (Note: In this ERD the relationship builds is indicated by a diamond)

Expanded ERD

ERD representation of data object type hierarchies

Associative data object - represents the associativity between objects

 

Creating Entity Relationship Diagrams

Functional Modeling and Information Flow (DFD)

Data Flow Diagrams (DFDs)


 
  The relationship between data and control models

Behavioral Modeling (STD)

Example
Level 1 CFD for photocopier software

State transition diagram for photocopier software


 

Data Dictionary Contents

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 [even] intermediate calculations Notation
Data Construct Notation Meaning
  is composed of
Sequence + and
Selection  [ | ] either-or
Repetition {}n n repetitions of
  ( )  optional data
  * ... *  delimits comments

Notation enables representation of composite data in one of the three fundamental ways that it can be constructed:

  1. As a sequence of data items.
  2. As a selection from among a set of data items.
  3. As a repeated grouping of data items. Each data item entry that is represented as part of a sequence, selection, or repetition may itself be another composite data item that needs further refinement within the dictionary.

 
 

Design Concepts and Principles (Chapter 12)

Translating the analysis model into a software design

 
 

Design Specification Models

The Design Process

Design Principles

Software Design Concepts

Modularity and software cost
Typical Hierarchical Control Structure

 
 

Effective Modular Design

Functional Independence
low coincidental cohesion  module that performs tasks that are related logically
temporal cohesion  module contains tasks that are related by the fact that all must be executed with the same spanof time
procedural cohesion  processing elements of a module are related and must be executed in a specific order
communicational cohesion  all processingelements concentrate on one area of a data structure
high module that performs one distinctprocedural task. 
low  data coupling simple data are passed- a one-to-one correspondence of items exists
stamp coupling a portion of a datastructure (rather than simple arguments) is passed via a module interface
control coupling  where a "control flag" is passed between modules
external coupling  modules are tied toan environment external to software
common coupling when a number of modulesreference a global data area
high content coupling when one modulemakes use of data or control information maintained within the boundaryof another module

Design Heuristics for effective Modularity

Program structure can be manipulated according to the following set of heuristics:
  1. Evaluate the "first iteration" of the program structure to reduce coupling and improve cohesion
  2. Attempt to minimize structures with high fan-out; strive for fan-in as depth increases
  3. Keep the scope of effect of a module within the scope of control of that module
  4. Evaluate module interfaces to reduce complexity and redundancy and improve consistency
  5. Define modules whose function is predictable, but avoid modules that are overly restrictive
  6. Strive for "controlled entry" modules by avoiding "pathological connections."

 

Design Documentation

Software Design Specification from: