chapter 4 design

7/31/2019 Chapter 4 Design

1/39

Software Design


2/39

Introduction to software design process and

principles

The goal of the design process is to produce amodel or representation of the system, which can be

used later to build a system. The produced model iscalled the design of the system.


3/39

The design of a system is essentially a blue print ora plan for a solution for the system.

The design process for software system often hastwo levels.

At the first level the focus is on deciding whichmodules are needed for the system, thespecification of these modules and how the modulesshould be interconnected.


4/39

Once high-level design is done, you have

a graphical representation of the structure ofyour software system

a document that defines high-level details ofeach module in your system, including

a modules interface (including input and

output data types)


5/39

notes on possible algorithms or datastructures the module can use to meet itsresponsibilities

a list of any non-functional requirements thatmight impact the module


6/39

Detailed Design

After high-level design, a designers focus

shifts to low-level design

Each modules responsibilities should be

specified as precisely as possible

Constraints on the use of its interface shouldbe specified


7/39

pre and post conditions can be identified

module-wide invariants can be specified

internal data structures and algorithms canbesuggested


8/39

Design Principles

A design should clearly be verifiable, complete andtraceable .

The design of the system is one of the mostimportant factors affecting maintainability of thesystem.

Simplicity is perhaps the most important qualitycriteria for software systems.


9/39

1.Problem partitioning

For software design, the goal is to divide the probleminto manageably small pieces that can be solvedseparately.

2. Abstraction: An abstraction of component describes theexternal behavior of that component without botheringwith the internal details that produce the behavior.


10/39

3.Modularity:

A system is considered modular if it consists ofdiscreet components so that each component can beimplemented separately. And change to one componentis minimal impact on other component.

For modularity , each module needs to support a welldefined abstraction and have clear interface throughwhich it can be interact with other modules.

Modularity is where abstraction and partitioning cometogether.


11/39

The Design Process

The system should be described at severaldifferent levels of abstraction.

Design takes place in overlapping stages.It is artificial to separate it into distinct phases

but some separation is usually necessary.


12/39

Phases in the Design Process

Architecturaldesign

Abstractspecificatio

n

Interfacedesign

Componentdesign

Datastructuredesign

Algorithmdesign

System

architecture

Sof tware

specification

Interface

specification

Component

specification

Data

structurespecification

Algorithm

specification

Requirementsspecification

Design activities

Design products


13/39

Design Phases

Architectural design: Identify sub-systems. Abstract specification:Specify sub-systems. Interface design:Describe sub-system

interfaces.

Component design:Decompose sub-systemsinto components.

Data structure design: Design data structures tohold problem data.

Algorithm design: Design algorithms for

problem functions.


14/39

Design

Computer systems are not monolithic: they areusually composed of multiple, interacting modules.

Modularity has long been seen as a key to cheap,

high quality software.

The goal of system design is to decode:

What the modules are;

What the modules should be;

How the modules interact with one-another


15/39

Stages of Design

Problem understanding Look at the problem from different angles to discover the

design requirements.

Identify one or more solutions Evaluate possible solutions and choose the most appropriate

depending on the designer's experience and availableresources.

Describe solution abstractions Use graphical, formal or other descriptive notations to

describe the components of the design.

Repeat process for each identified abstractionuntil the design is expressed in primitive terms.


16/39

Characteristics of Good Design

Component independence

High cohesion

Low coupling


17/39

Coupling and Cohesion


18/39

Coupling Coupling is a property of a collection of

modules.

Coupling is the measure of strength ofinterdependence between modules in a system.

Interdependence occurs because of some dataor control that is passed between two modules.

Highly coupled system has stronginterconnections with program units

interdependent on each other.


19/39

Coupling: Degree of dependence among

components

No dependencies Loosely coupled-some dependencies

Highly coupled-many dependencies

High coupling makes modifyingparts of the system difficult, e.g.,modifying a component affects allthe components to which thecomponent is connected.


20/39

We aim to minimise coupling - to makemodules as independent as possible

Low coupling can be achieve by:

eliminating unnecessary relationships

reducing the number of necessary relationships

easing the tightness of necessary relationships


21/39

Range of Coupling

High Coupling

Loose

Low

Content

Common

Control

Stamp

Data

Uncoupled


22/39

Content coupling

Definition: One component referencescontents of another

Example:

Component directly modifies anothers data


23/39

Common Coupling

Definition: Two components share data Global data structures

Common blocks

Usually a poor design choice because Reduces readability

Difficult to determine all the components thataffect a data element (reduces maintainability)

Difficult to reuse components


24/39

Control Coupling

Definition: Component passes controlparameters to coupled components.

May be either good or bad, depending on

situation. Bad when component must be aware of internal

structure and logic of another module

Good if parameters allow factoring and reuse offunctionality


25/39

Stamp Coupling

Definition: Component passes a data structure toanother component that does not have access tothe entire structure.

Requires second component to know how tomanipulate the data structure (e.g., needs to knowabout implementation)


26/39

Data Coupling

Definition: Two components are datacoupled if there are homogeneous dataitems.

Every argument is simple argument ordata structure in which all elements areused

Good, if it can be achieved. Easy to write contracts for this and modify

component independently.


27/39

Key Idea in Object-Oriented

Programming Object-oriented designs tend to have low

coupling.


28/39

Cohesion

Definition: The degree to which all elementsof a component are directed towards a singletask and all elements directed towards that

task are contained in a single component. Internal glue with which component is

constructed

All elements of component are directed

toward and essential for performing the sametask

High is good


29/39

Cohesion

Cohesion is a property or characteristic of anindividual module. Cohesion is the measure ofintra-modular strength.

Cohesion of module is a measure of thestrength of the association of elements withina module.

A cohesive module performs a single taskwithin a software procedure.


30/39

Range of Cohesion

High Cohesion

Low

Functional

Sequential

Communicational

Procedural

Temporal

Logical

Coincidental


31/39

Examples of Cohesion-1

Function A

FunctionB

Function

D

FunctionC

Function

E

CoincidentalParts unrelated

Function A

Function A

Function A

logic

LogicalSimilar functions

Time t0

Time t0 + X

Time t0 + 2X

TemporalRelated by time

Function A

Function B

Function C

ProceduralRelated by order of functions


32/39

Examples of Cohesion-2

Function A part 1

Function A part 2

Function A part 3

FunctionalSequential with complete, related functions

Function A

Function B

Function C

CommunicationalAccess same data

Function A

Function B

Function C

SequentialOutput of one is input to another


33/39

Coincidental Cohesion

Definition: Parts of the component are onlyrelated by their location in source code

Elements needed to achieve some

functionality are scattered throughout thesystem.

Accidental

Worst form


34/39

Logical Cohesion

Definition: Elements of component arerelated logically and not functionally.

Several logically related elements are in thesame component and one of the elements isselected by the client component.


35/39

Temporal Cohesion

Definition: Elements of a component arerelated by timing.

Difficult to change because you may have tolook at numerous components when achange in a data structure is made.


36/39

Procedural Cohesion

Definition: Elements of a component arerelated only to ensure a particular order ofexecution.

Actions are still weakly connected andunlikely to be reusable


37/39

Communicational Cohesion

Definition: Module performs a series ofactions related by a sequence of steps to befollowed by the product and all actions are

performed on the same data


38/39

Sequential Cohesion

The output of one component is the input toanother.

Occurs naturally in functional programming

languages

Good situation


39/39

Functional Cohesion

Definition: Every essential element to a singlecomputation is contained in the component.

Every element in the component is essential

to the computation.

Ideal situation.

chapter 4 design

Documents