CS615 – Software Engineering I

Lecture 4

Analysis Modeling (Chapter 8)

Requirements Analysis

 

 

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

Partitioning

 

 

Software Requirements Views

Software Prototyping

 

 

 

Prototyping Methods and Tools

Specification Principles

Specification Representation

Specification Review

 

Analysis Model

Structured Analysis (DeMarco)

Analysis Model Objectives

 


 

Analysis Model Elements

Analysis Modeling: Where to Begin?

Data Modeling (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

 

Scenario-Based Modeling

Use-Cases

Use-Case Diagram

 

Activity Diagram

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

 


 


Swimlane Diagrams

Allows the modeler to:

 

Flow-Oriented Modeling

Functional Modeling and Information Flow (DFD)

Data Flow Diagrams (DFDs)

 

 

 

 

 

 

The relationship between data and control models

 

 

 

Class-Based Modeling

 

Analysis Classes

 

Selecting Classes—Criteria

 

Class Diagram

 

CRC Modeling

 

CRC Cards

 

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

 

Reviewing the CRC Model

 

Associations and Dependencies

 

Multiciplicity

 

Dependencies

 

Analysis Packages

 

 

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

 

 

Sequence Diagram

 

 

 

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 Engineering (Chapter 9)

Translating the analysis model into a software design

 
 

Design Specification Models

The Design Process

1.    A design should exhibit an architectural structure that it:


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

2.    A design should be modular; that is, the software should be logically partitioned into elements that perform specific functions and subfunctions.

3.    A design should contain distinct representations of data, architecture, interfaces, and components (modules).

4.    A design should lead to data structures that are appropriate for the objects to be implemented and are drawn from recognizable data patterns.

5.    A design should lead to components that exhibit independent functional characteristics.

6.    A design should lead to interfaces that reduce the complexity of connections between modules and with the external environment.

7.    A design should be derived using a repeatable method that is driven by information obtained during software requirements analysis.

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: