SE 616 – Introduction to Software Engineering

Lecture 4

Analysis Modeling (Chapter 8)

Requirements Analysis


Description: ch10fg6


Software Requirements Analysis Phases

Software Requirements Elicitation

Process Initiation

Facilitated Action Specification Techniques (FAST)

Quality Function Deployment (QFD)

Analysis Principles

Operational principles:

Guiding principles:

Information Domain


Information Flow

How data and control change as each moves through a system

Description: ch10fg7



Description: ch10fg8


Description: ch10fg9

Software Requirements Views

Software Prototyping


Description: ch10fg10 


Prototyping Methods and Tools

Specification Principles

Specification Representation

Specification Review


Analysis Model

Structured Analysis (DeMarco)

Analysis Model Objectives


Description: Image1

Analysis Model Elements

Analysis Modeling: Where to Begin?

Data Modeling (ERD)


Description: Image2


Description: Image3


Description: Image4

Cardinality and Modality (ERD)


Description: Image5


Entity/Relationship Diagrams

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

Description: Image6

Expanded ERD
Description: Image7


ERD representation of data object type hierarchies

Description: Image8


Associative data object - represents the associativity between objects
Description: Image9

Creating Entity Relationship Diagrams


Scenario-Based Modeling


Use-Case Diagram

Description: usecasediag


Activity Diagram

Supplements the use-case by providing a diagrammatic representation of procedural flow


Description: actdia

Swimlane Diagrams

Allows the modeler to:

Description: swimlane


Flow-Oriented Modeling

Functional Modeling and Information Flow (DFD)

Data Flow Diagrams (DFDs)


Description: Image10



Description: Image11



Description: Image12


The relationship between data and control models

Description: Image13


Description: Image14



Class-Based Modeling


Analysis Classes


Selecting Classes—Criteria


Class Diagram

Description: classdiag


CRC Modeling


CRC Cards

Description: crccard


Class Types

controller classes can be designed to manage


Class Responsibilities

·         System intelligence should be distributed across classes to best address the needs of the problem

·         Each responsibility should be stated as generally as possible

·         Information and the behavior related to it should reside within the same class

·         Information about one thing should be localized with a single class, not distributed across multiple classes.

·         Responsibilities should be shared among related classes, when appropriate.


Class Colaborations


Composite Aggregate Class

Description: aggclass


Reviewing the CRC Model


Associations and Dependencies



Description: multiplicity



Description: dependencies


Analysis Packages

Description: analpkg



Behavioral Modeling

·         The behavioral model indicates how software will respond to external events or stimuli.

·         Evaluate all use-cases to fully understand the sequence of interaction 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.

·         Build a state diagram for the system.

·         Review the behavioral model to verify accuracy and consistency.


State Representations 



State Diagram for the ControlPanel Class

Description: statediag



Sequence Diagram


Description: sequencediag



Level 1 CFD for photocopier software


Description: Image15

State transition diagram for photocopier software
Description: Image16


Description: Image26

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


Data Construct




is composed of





[ | ]




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.

 Description: Image17


Design Engineering (Chapter 9)

Translating the analysis model into a software design

Description: Image18 

Design Specification Models

The Design Process

(1) has been created using recognizable design patterns
(2) is composed of components that exhibit good design characteristics
(3) can be implemented in an evolutionary fashion, thereby facilitating implementation and testing.

Design Principles

Software Design Concepts

Modularity and software cost

Description: Image19

Typical Hierarchical Control Structure

Description: Image20

  Description: Image21

Effective Modular Design

Functional Independence


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


module that performs one distinctprocedural task. 


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


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."


Description: Image23

Design Documentation

Software Design Specification from: