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

Modeling

Information Flow

How data and control change as each moves through a system

Description: ch10fg7

Partitioning

 

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-Cases

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

 

Multiciplicity

Description: multiplicity

 

Dependencies

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

 

 

Example
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

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.

 
 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

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

 

Description: Image23

Design Documentation

Software Design Specification from: