Design Concepts & Principles

Indu SharmaHOD(CSE)

CPTC,Rajsamand

Introduction The purpose of the design phase is to plan a

solution of the problem specified by the requirements documents.

It is a blueprint for the solution of a problem This phase is the first of three technical

activities-design, code generation, and test-that are required to build and verify the software.

The design of the system is perhaps the most critical factor affecting quality of the software, it has a major impact on the later phases, particularly testing and maintenance.

Introduction The design process for software systems

often has two levels.• Top-level design• Detailed design

At the first level the focus is on deciding which modules are needed for the system, the specifications of these modules, and how the modules should be interconnected.

In the second level, the internal design of the modules, or how the specifications of the module can be satisfied, is decided.

Fundamental Differences between Design and Analysis1. The problem analysis, we construct a

model of the problem domain, while in design we construct a model for the solution domain.

2. In design, the system depends on the model, while in problem analysis the model depends on the system.

3. The basic aim of the modeling in problem analysis is to understand, while the basic aim of modeling in design is to optimize (in our case, simplicity and performance).

Implement all explicit and implicit requirements

Be a readable and understandable guide for developers and customers

Provide a complete picture of software

A Good Design

Design Principles A good designer should consider

alternative approaches.• Each alternative should be judged with

respect to stated requirements.• Each alternative should be judged with

respect to resources required for the solution and resources available to do the job.

• Each alternative should be judged with respect to the design concepts (eg. Modularity, information hiding etc.)

A good design is traceable to the Analysis Model and to Software Requirements.

Design Principles A good designer will not “re-invent the

wheel”• If a good design exists and can be reused from

some other source, then do not re-design the solution. Time and money are always in short supply. A good software engineer will always look for a ready-made solution before developing a new one.

A good design should minimize “intellectual distance” between the software and the real world problem it is designed to solve.

• This is one of the most important benefits of the object-oriented approach to design.

Design Principles The design should exhibit uniformity and

integration.• It should appear as if “one person”

developed the entire system. There should be a well-defined set of coherent principles and rationale that guide design decisions throughout the system development. The description of the system uniformly should follow certain defined standards for style, format, and organization everywhere they could apply.

• Interfaces between components should be documented completely and clearly using a consistent style and presentation format.

Design Principles The design should be structured to

accommodate change.• Again, the object-oriented approach tends to

yield designs that satisfy this principle. Design should be structured to degrade

gently.• It should terminate gracefully and not bomb

suddenly. Design and coding are not

interchangeable.

Design Principles Design should have quality assessment

during creation, not afterwards• This is to reduce development time

A design should be reviewed to minimize conceptual (semantic) errors.

• Focus on omissions, ambiguity, and inconsistency before worrying about the syntax of the design model.

Relation of Analysis to Design

The Design Model Data Design

Transforms information domain model into data structures required to implement software

Architectural Design

Defines relationship among the major structural elements of a program

Procedural Design

Interface Design

Architectural Design

Data Design

The Design Model

Which is mapped from the Analysis model

The Design Model Interface Design

Describes how the software communicates with itself, to systems that interact with it and with humans.

Procedural Design Transforms structural

elements of the architecture into a procedural description of software construction

Procedural Design

Interface Design

Architectural Design

Data Design

The Design Model

Which is mapped from the Analysis model

Fundamental Concepts

Abstraction — data, procedure, control Refinement — elaboration of detail for

abstractions Modularity — compartmentalize data and function Architecture — overall structure of the software Partitioning — partition the program structure Data structure — the logical relationship of data Procedure — the algorithms that achieve function Hiding — controlled interfaces Function independences — cohesion, coupling

Abstraction Each step in the software process is

a refinement in the level of abstraction of the software solution.

Data Abstraction A data abstraction is a named

collection of data object. Eg. Classes and interfaces in JAVA.

Data Abstractiondoor

implemented as a data structure

manufacturermodel numbertypeswing directionweight

opening mechanism

AbstractionProcedural Abstraction:

A procedural abstraction is a named sequence of instructions that has a specific and limited function.

This allows the designer to reason in terms of inputs and results of the named computation without having to think about the details of how the computation will be accomplished or implemented.

Procedural Abstractionopen

details of enter algorithm

Walk to the door, reach out and grasp knob, turn know and pull the door, step away from moving door etc.

Abstraction Control Mechanism

Third form of abstraction used in software design.

It implies a control mechanism without specifying internal details.

Eg. Semaphore in OS, Concurrency control in databases etc.

Refinement Stepwise refinement is a top down strategy. Refinement is a process of elaboration. We begin

with a statement of function that is defined at a high level of abstraction. Refinement causes the designer to elaborate on the original statement, providing more and more detail as each successive refinement occurs.

Abstraction and refinement are complementary concepts. Abstraction enables a designer to specify procedure and data yet suppress low-level details. Refinement helps the designer to reveal low-level details as designer progresses. Both concepts aid the designer in creating a complete design model as the design evolves.

Refinement

open

walk to door;reach for knob;

open door;

walk through;close door.

repeat until door opensturn knob clockwise;if knob doesn't turn, then take key out; find correct key; insert in lock;endifpull/push doormove out of way;end repeat

Modularity Software is divided into separately named

and addressable components, often called modules, that are integrated to satisfy problem requirements.

Monolithic software (i.e. a large program composed of a single module) can’t be easily grasped by a reader. The number of control paths, span of references, number of variables and overall complexity would make understanding close to impossible.

Modularity Let C(x) ->perceived complexity of

a problem x.E(x) -> Effort (in time) required to solve a problem x.p1 and p2 are two problems

If C(p1) > C(p2) ---(i-a)it follows that

E(p1) > E(p2) ---(i-b)

Modularity Another interesting characteristics that has

been uncovered through experimentation in human problem solving. That is,C(p1+p2) > C(p1) + C(p2) ---(ii)Now from Equation (i-b)E(p1+p2) > E(p1) + E(p2) ---(iii)

This leads to a divide and conquer strategy-it is easier to solve a complex problem when you break it into manageable pieces.

Modularity: Trade-offs

What is the "right" number of modules What is the "right" number of modules for a specific software design?for a specific software design?

optimal numberoptimal number of modulesof modules

cost ofcost of softwaresoftware

number of modulesnumber of modules

modulemoduleintegrationintegration

costcost

module development cost module development cost

Modularity Under-modularity and over-modularity

should be avoided. Another important question arises when

modularity is considered. How do we define an appropriate module of a

given size? The answer lies in the method(s) used to

define modules within a system. Meyer defines five criteria that enables us

to evaluate a design method with respect to its ability to define an effective modular system.

Modularity Objectives of modularity in a design method Modular Decomposability

Provide a systematic mechanism to decompose a problem into sub problems.

Modular Composability Enable reuse of existing components

Modular Understandability Can the module be understood as a stand

alone unit (without reference to other modules)? Then it is easier to understand and change.

Modularity Modular Continuity

If small changes to the system requirements result in changes to individual modules, rather than system-wide changes, the impact of the side effects is reduced .

Modular Protection If there is an error in the module, then

those errors are localized and not spread to other modules

Architecture ““The The overall structureoverall structure of the software and of the software and

the ways in which that structure provides the ways in which that structure provides conceptual integrity for a system.” conceptual integrity for a system.”

In simplest form, architecture is the In simplest form, architecture is the hierarchical structure of program hierarchical structure of program components (modules), the manner in components (modules), the manner in which these components interact and the which these components interact and the structure of data that are used by the structure of data that are used by the components.components.

Architecture

superordinate

subordinate

Structural Partitioning If the architectural style of a system is

hierarchical, the program structure can be partitioned both horizontally and vertically.

Horizontally Partitioning defines separate branches of the modular hierarchy for each major program function.

For eg. The simplest approach to horizontal partitioning defines three partitions – input, data transformation, and output.

Structure Partitioning Benefits: Horizontal Partitioning

Easier to test Easier to maintain Propagation of fewer side effects Easier to add new features

F1 (Ex: Input) F2 (Process) F3(Output)

Structure Partitioning Vertical partitioning, often called factoring,

suggests that control (decision making) and work should be distributed top-down in the program structure.

Top-level modules should perform control functions and do little actual processing work. Modules that reside low in the structure should be the worker, performing all input, computation, and output tasks.

Structure Partitioning

Benefits: Vertical Partitioning Less susceptible to side effects Also very maintainable

Fan-out (span of control): Fan-out is a measure of the number of

modules that are controlled by another module.

objective: ”boss” modules should control a reasonable number of workers;

guideline: number of modules controlled by a “boss” < 7

(3)

Fan-in Fan-in indicates how many modules directly

control a given module. objective: maximize fan-in, create generalized

modules guideline: modules must have strong or moderate

cohesion(4)

Data Structure It refers to the representation of the

logical relationship among individual elements of data.

Eg. Scalar items: integer Vector: array Space: structure Linked lists Trees Stacks etc.

Software Procedure Software Procedure focuses on the

processing details of each module individually.

It must provide a precise specification of processing, including sequence of events, exact decision points, repetitive operations, and even data organization.

There is a relationship between structure and procedure.

Software Procedure

Information Hiding The concept of modularity leads to a

fundamental question : How do we decompose a software solution to

obtain the best set of modules? The principle of information hiding

suggests that the modules should be specified and designed so that information (procedure and data) contained within a module is inaccessible to other modules that have no need for such information.

Information Hiding

modulemodulecontrolledcontrolledinterfaceinterface

"secret""secret"clientsclients

a specific design decisiona specific design decision

Hiding Hiding — controlled interfaces— controlled interfaces

Why Information Hiding? Leads to encapsulation — an

attribute of high quality design Reduces the likelihood of “side

effects”. Easy modifications during testing

and software maintenance. Emphasizes communication through

controlled interfaces Discourages the use of global data Results in higher quality software

Functional Independence The concept of functional independence is a

direct result of modularity, and the concepts of abstraction and information hiding.

Each module addresses a specific subfunction of requirements.

Independent modules are: Easier to maintain Easier to test Error propagation is reduced Reusable modules are possible Encourage parallel development

Functional Independence Functional independence is the key

to good design, and design is the key to software quality.

Independence is measured using two qualitative criteria: Cohesion and Coupling.

Coupling Coupling is a measure of the relative

interdependence among modules. Two modules with high coupling are strongly

interconnected and thus, dependent on each other. Two modules with low coupling are not dependent on one another.

Coupling depends on the interface complexity between modules, the point at which entry or reference is made to a module, and what data pass across the interface.

In software design, we strive for lowest possible coupling.

Coupling: Degree of dependence among components

No dependencies Loosely coupled-some dependencies

Highly coupled-many dependencies

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

Range of CouplingHigh Coupling

Loose

Low

Content

Common

External

Control

Stamp

Data

Uncoupled

Data coupling Modules communicate

by parameters Each parameter is an

elementary piece of data Each parameter is

necessary to the communication

Nothing extra is needed

ProcessResults

CalculateGrade

mark grade

Data coupling No Tramp Data. Too many parameters - makes the

interface difficult to understand and possible error to occur.

Stamp coupling A composite data

(complete data structure) is passed between modules

Internal structure contains data not used

Stamp Typically involves tramp data.

ProcessResults

UpdateGrade

record updated record

Control coupling Communication by a

passing of control information. Eg. flags

A module controls the logic of another module through the parameter

Controlling module needs to know how the other module works - not flexible!

Checkrecord

Displayerror

Error code

External Coupling When modules are tied to an

environment external to software. For eg. I/O couples module to

specific devices, format, and communication protocols.

Common Coupling Shared data between modules. Global data Making a change to the common

data means tracing back to all the modules which access that data to evaluate the effect of change.

Common Coupling

Common Coupling

Content coupling A module refers to the

inside of another module Branch into another module Control is passed from one

module to the middle of another.

Refers to data within another module.

Content Coupling

Content Coupling

Cohesion A cohesive module performs a single task

within a software procedure, requiring a little interaction with procedures being performed in other parts of a program.

The degree to which a module performs one and only one function.

We aim for strongly cohesive modules Strong cohesion will reduce relations

between modules - minimize coupling

Range of CohesionHigh Cohesion (Best)

Low (Worst)

Functional

Sequential

Communicational

Procedural

Temporal

Logical

Coincidental

Functional Cohesion Strongest cohesion All elements contribute to the execution of

one and only one problem-related task Focussed - strong, single-minded purpose No elements doing unrelated activities Examples of functional cohesive modules:

Compute cosine of angle Read transaction record Assign seat to airline passenger

Functional Cohesion

Function A part 1

Function A part 2

Function A part 3

FunctionalSequential with complete, related functions

Sequential Cohesion The output of one component is

the input to another.Function A

Function B

Function C

SequentialOutput of one is input to another

Example of Sequential Cohesionmodule format and cross-validate

record use raw record format raw record cross-validate fields in raw record return formatted cross-validated

recordend module

Communicational Cohesion The activities are related to each

other by the data that the modules uses.

Each instruction acts on the same input or output data.

Function A

Function B

Function C

CommunicationalAccess same data

Example of Communicational Cohesion

module determine customer details use customer account no find customer name find customer loan balance return customer name, loan balanceend module

Procedural cohesion Elements are related only by sequence,

otherwise the activities are unrelated. In other words, the procedural cohesion

occurs in modules whose instructions although accomplish different tasks yet have been combined because there is specific order in which the task are to be completed.

Similar to sequential cohesion, except for the fact that elements are unrelated

Procedural Cohesion

Function A

Function B

Function C

ProceduralRelated by order of functions

Temporal cohesion Elements are involved in activities that are

related in time. The elements are grouped together

because they occur at about the same point in time.

Modules that perform activities like “initialization”, “clean up”, and “termination” are usually temporarily bound.

Temporal Cohesion

Time t0

Time t0 + X

Time t0 + 2X

TemporalRelated by time

Example of Temporal Cohesion

module initialise set counter to 0 open student file clear error message variable initialise arrayend module

Logical cohesion A module has logical cohesion if

there is some logical relationship between the elements of a module, and the elements perform functions that fill in the same logical class.

Usually have control coupling, since one of the activities will be selected

Example of Logical Cohesion

module display record use record-type, record if record-type is student then display student record else if record-type is staff then display staff recordend module

Logical Cohesion

Function A

Function A’

Function A’’

logic

LogicalSimilar functions

Coincidental cohesion Elements contribute to activities with no

meaningful relationship to one another Similar to logical cohesion, except the

activities may not even be the same type Mixture of activities. Difficult to understand and maintain, with

strong possibilities of causing ‘side effects’ every time the module is modified

Example of Coincidental Cohesion

module miscellaneous functions use customer record display customer record calculate total sales read transaction record return transaction recordend module

Function AFunction

BFunction

D

FunctionC

Function E

CoincidentalParts unrelated

Examples of CohesionFunction A

FunctionB

FunctionD

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

Examples of Cohesion

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

Determining Module Cohesion

Doing onefunction

only?

Activitiessame category?

Sequenceimportant?

Modulerelated

by?

Sequenceimportant?

Functional

Sequential

Communicational

Procedural Temporal

Logical

Coincidental

Yes

No

Data None

Control Flow

Yes

Yes

Yes

No

No

No

Design Heuristics for Effective Modularity Once program structure has been

developed, effective modularity can be achieved by manipulating the program structure according to the following set of rules:

1. Evaluate the “first iteration” of the program structure to reduce coupling and improve cohesion.

Design Heuristics Modules may be exploded or imploded

with an eye toward improving module independence.

2. Attempt to minimize structures with high fan-out; strive for fan-in as depth increases.

More reasonable distribution of control. A number of layers of control and highly

utilitarian modules at lower details.

Program Structure

Design Heuristics3. Keep scope of effect of a module

within the scope of control of that module.

The scope of control of module e is all modules that are subordinate and ultimately subordinate to module e.

If module e makes a decision that affects module r, we have a violation of this heuristic.

Design Heuristics4. Evaluate module interfaces to

reduce complexity and redundancy and improve consistency.

Module interfaces should be simple and should be consistent with the function of a module.

Interface inconsistency is an indication of low cohesion.

Design Heuristics5. Define modules whose function is

predictable, but avoid modules that are overly (excessively) restrictive.

A module is predictable when it can be treated as black box.

A module that arbitrarily restricts the size of a local data structure, options within control flow, or modes of external interface will invariably require maintenance to remove such restrictions.

Design Heuristics6. Strive for “controlled entry”

modules by avoiding “pathological connections.”

Warns against content coupling. Module interfaces are controlled. Pathological connection refers to

branches or references into middle of a module.

Software Design Methodologies The aim of design methodologies is to

provide guidelines to aid the designer during the design process.

A good design methodology is to organize the program in such a way that are easy to develop and later, to change.

The major software design methodologies are: Structured Design Methodology Object Oriented Design Methodology Real Time System Design Methodology

Structured Design Methodology (SDM) In SDM, the software is viewed as

transformation function that transforms the given inputs into the desired outputs.

The central objective is to properly designed this transformation function.

Due to this view of software, the SDM is primarily function oriented.

It is also called function oriented design methodology.

The concept of Program Structure, functional abstraction and functional decomposition lies at the heart of the structural design.

Structured Design Methodology (SDM) Design Notations

For a SDM, the design can be represented graphically or mathematically by the following:

DFDs Data Dictionaries Structure Charts Algorithms/Pseudcode etc.

Object Oriented Design Methodology Object oriented methodology reflects a natural view of the

world. OO Concepts:

Classes and Objects Data Abstraction & Encapsulation Polymorphism Inheritance Information Hiding

In and OO system, the basic module is a class. During design, the goal is to identify the modules that the

system should have, and their interfaces and relationships. In OOD, we are therefore identifying the classes that should exist in the software and the relationships between these classes.

UML(Unified Modeling Language): UML is a graphical notation for expressing object oriented designs