Unit-III Software Design222

(1)

UNIT-III

(2)

SOFTWARE DESIGN

• The objective of Software Design phase is to take

the SRS document as input and produce the output mentioned below

– Different modules required to implement the solution – Control relationships among the different modules. – Interface among different modules.

– Data structures of the individual modules.

– Algorithms required to implementing the individual

(3)

• Software design is a process to transform user

(4)

 For assessing user requirements, an SRS

(Software Requirement Specification) document is created whereas for coding and implementation, there is a need of more specific and detailed requirements in software terms.

 The output of this process can directly be used

(5)

• Software design is the first step in SDLC

(Software Design Life Cycle), which moves the concentration from problem domain to solution domain.

• Software design model consists of 4 designs:

– Data/class Design – Architectural Design – Interface Design

(6)

(7)

(8)

SOFTWARE DESIGN PROCESS AND

DESIGN QUALITY

 Software(s/w) design is an iterative process

(9)

GOAL OF DESIGN PROCESS

• The design must implement all of the explicit

requirements contained in the analysis model,

and it must accommodate all of the implicit

requirements desired by the customer.

• The design must be a readable, understandable

guide for those who generate code and for those who test and subsequently support the software.

• The design should provide a complete picture of

(10)

DESIGN GUIDELINES

1. A design should exhibit an architecture that

(1) Has been created using recognizable architectural styles or patterns,

(2) Is composed of components that exhibit good design characteristics.

(11)

2. A design should be modular; that is, the software should be logically partitioned into elements or subsystems!

3. A design should contain distinct

representations of data, architecture, interfaces,

(12)

4. A design should lead to data structures that

are appropriate for the classes to be implemented

and are drawn from recognizable data patterns.

5. A design should lead to components that

exhibit independent functional

(13)

6. A design should lead to interfaces that

reduce the complexity of connections between

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

8. A design should be represented using a notation that effectively communicates its

(14)

SOFTWARE DESIGN CONCEPTS

(15)

(16)

ABSTRACTION

 Abstraction refers to a powerful design tool,

which allows software designers to consider components at an abstract level, while neglecting the implementation details of the components.

 IEEE defines abstraction as 'a view of a problem

(17)

• Each step in the software process is accomplished

through various levels of abstraction.

– At the highest level, an outline of the solution to the problem

is presented.

– whereas at the lower levels, the solution to the problem is

(18)

• There are three commonly used abstraction

mechanisms in software design, namely,

– functional abstraction, – data abstraction and – control abstraction.

(19)

I. PROCEDURAL OR FUNCTIONAL

ABSTRACTION:

• These are the sequence of instructions that have

a specific and limited function. Ex. Open a door

• Open implies long sequence of activities (e.g.

(20)

II. DATA ABSTRACTION:

• This involves specifying data that describes a

data object.

Ex. Open a door. – Door is a data object.

• Data abstraction for door would encompass a set

(21)

III. CONTROL ABSTRACTION:

• It states the desired effect, without stating the

exact mechanism of control.

– For example, if and while statements in programming

(22)

MODULARITY

 Software is divided into separately named and

addressable components which are called modules.

 Those are integrated to satisfy problem

requirements.

 Modularity is a single attribute of software that

(23)

• Monolithic software i.e. a large program

(24)

(25)

 It is easier to solve a complex problem when you

break it into manageable PCs (Modules).

 When we divide software in to modules then

development effort also decreased.

 From above graph we can show that as the number of

(26)

1) MODULAR

DECOMPOSABILITY

 It provides a systematic approach for

(27)

2) MODULAR COMPOS ABILITY

• Modular compos ability means if a design method

(28)

3) MODULAR

UNDERSTANDABILITY

• If a module can be understood as a standalone

(29)

4) MODULAR CONTINUITY

 If small changes to the system requirements

(30)

5) MODULAR PROTECTION

• If any unexpected condition occurs within a

(31)

SOFTWARE ARCHITECTURE

• “The software architecture of a program or computing system is

the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them.

• Architecture focuses on how the major elements and components

within an application are used by, or interact with, other major elements and components within the application.

• The selection of data structures and algorithms or the

implementation details of individual components are design concerns.

• There is a difference between the terms architecture and design.

(32)

• For example, consider the client-server

(33)

EFFECTIVE MODULAR DESIGN

• Effective modular design consists of three things:

– Functional Independence – Cohesion

(34)

FUNCTIONAL INDEPENDENCE

 Functional independence is achieved by

(35)

 In other words - each module addresses a specific

sub-function of requirements .

 Independence is important because –

 Easier to develop

 Easier to Test and maintain

 Error propagation is reduced

 Reusable module.

 To summarize, functional independence is a key ‘to

(36)

Functional independence is evaluated using two criteria:

Cohesion

– Cohesion is a measure of the relative functional strength of

a module.

Coupling

– Coupling is a measure of the relative interdependence

(37)

(38)

COHESION

• Cohesion is the measure of strength of the

association of elements within a module.

• A cohesive module performs a single task within

(39)

(40)

• FUNCTIONAL COHESION:

• In this, the elements within the modules

(41)

SEQUENTIAL COHESION:

• In this, the elements within the modules are

(42)

COMMUNICATIONAL COHESION:

• In this, the elements within the modules perform

(43)

PROCEDURAL COHESION:

• In this, the elements within the modules are

(44)

TEMPORAL COHESION:

• In this, the elements within the modules contain

(45)

LOGICAL COHESION

:

(46)

COINCIDENTAL COHESION:

(47)

COUPLING

• In software engineering, coupling is the degree

of interdependence between software modules;

• A measure of how closely connected two routines

or modules are the strength of the relationships between modules.

• Coupling can be

– "low" (also "loose" and "weak") or – "high" (also "tight" and "strong").

• Some types of coupling, in order of highest to

(48)

(49)

CONTENT COUPLING AND

COMMON COUPLING

Content coupling

 Two modules are content coupled if one module changes a statement in another module.

 In the below figure, Modules B and Module D are content coupled.

Common coupling

• Two modules are common

coupled if they both share the same global data area.

• In Figure, Modules C and

(50)

CONTROL COUPLING

• Two modules are control

coupled if they communicate (passes a piece of information intended to control the internal logic) using at least one ‘control flag’.

• The control flag is a variable

that controls decisions in subordinate or superior modules.

• In below figure , when

(51)

STAMP COUPLING, DATA COUPLING AND NO DIRECT COUPLING

Stamp Coupling

• Two modules are stamp coupled if

they communicate through a passed data structure that contains more information than necessary for them to perform their functions.

• In below figure, data structure is

passed between modules 1 and 4.

• Therefore, Module 1 and Module 4

are stamp coupled.

Data coupling:

• Two modules are data coupled if they

communicate by passing parameters.

• In below figure, Module 1 and

Module 3 are data coupled.

No direct coupling:

• Two modules are no direct coupled

when they are independent of each other.

• In below figure, Module 1 and Module

(52)

ARCHITECTURAL DESIGN

• Requirements of the software should be

transformed into an architecture that

describes the software's top-level structure and identifies its components.

• This is accomplished through architectural

(53)

 IEEE defines architectural design as 'the process

(54)

AN ARCHITECTURAL DESIGN PERFORMS THE FOLLOWING FUNCTIONS.

1. It defines an abstraction level at which the designers can specify the functional and performance behavior of the system.

2. It develops and documents top-level design for the

external and internal interfaces.

3. It develops preliminary versions of user documentation.

4. It defines and document preliminary test

(55)

ARCHITECTURAL DESIGN

OUTPUT

• The architectural design process results in

an Architectural Design Document (ADD).

This document consists of a number of graphical representations that comprises software models along with associated descriptive text.

• The software models include

– static model,

– interface model,

– relationship model, and – dynamic process model.

(56)

 Architectural design document gives the

(57)

COMPONENT-LEVEL DESIGN OR PROCEDURAL DESIGN

 As soon as first iteration of architectural design

is complete, component-level design also called

procedural design takes place.

 Component-level design is created by

transforming the structural elements defined by the software architecture into procedural descriptions of software components.

 These components are derived from the analysis

(58)

 Component also known as module, resides within the

software architecture and serves one of the three roles listed below:

 A control component, which coordinates the invocation (request) of all other components present in the problem domain.

 A problem domain component, which implements a complete or partial function as required by the user.

 An infrastructure component supports

(59)

DATA FLOW-ORIENTED DESIGN

• A Data Flow Diagram (DFD) is traditional visual

representation of the information flows within a system.

• A neat and clear DFD can represent a good

amount of the system requirements graphically.

• It can be manual, automated, or combination of

(60)

• It shows how information enters and leaves the

system, what changes the information and where information is stored.

• The purpose of a DFD is to show the scope and

(61)

DFD SHOULD NOT BE CONFUSED

WITH A FLOWCHART.

 A DFD represents the flow of data whereas

flowchart depicts the flow of control.

 Also, a DFD does not represent the information

about the procedure to be used for accomplishing the task.

 DFD helps a software designer to describe the

(62)

• DFDs only involve four symbols. They are: – Process

– Data Object – Data Store

(63)

(64)

Process

• A process is a business activity or function where

the manipulation and transformation of data takes place.

(65)

EXTERNAL AGENT

• External systems which are outside the boundary

of this system, these are represented using the squares

E x t e r n a l

(66)

DATA STORE

• A data store represents the storage of persistent

data required and/or produced by the process.

• Here are some examples of data stores:

– membership forms, – database table, etc.

• Where data is being stored for later retrieval. • Provides input to the process

• Outputs of the processes may be going into these

data stores.

(67)

DATA FLOW

• A data flow represents the flow of information,

(68)

(69)

(70)

Description:

 First we shall discuss ‘withdraw funds from an account’ process. In

this process, information about the accounts and account transactions is retrieved (from the data stores) and bank releases the funds. After this, it sends this information to ‘reconcile account balance’ process which prepares a monthly account statement. In this statement, information regarding bank accounts and account transactions are described.

 Next is the ‘pay a bill’ process through which a creditor pays his dues

and the corresponding accounts are updated against the cash transaction. A receipt is issued back to the creditor.

 The fourth process is ‘deposits funds in an account’ in which an

(71)

(72)

ARCHITECTURAL DESIGN

REPRESENTATION

(73)

 Structural model:

(74)

• Dynamic model: Specifies the behavioral aspect

of the software architecture and indicates how the structure or system configuration changes as the function changes due to change in the

external environment

• Process model: Focuses on the design of the

(75)

• Functional model: Represents the functional

hierarchy of a system.

• Framework model: Attempts to identify

repeatable architectural design patterns encountered in similar types of application.

• This leads to an increase in the level of

(76)

 The modular design of the software should exhibit the

(77)

PROVIDE SIMPLE INTERFACE

• Simple interfaces reduce the number of

interactions that must be considered when verifying that a system performs its intended (proposed) function.

• Simple interfaces also make it easier to reuse

components in different circumstances.

(78)

ENSURE INFORMATION HIDING:

• The benefits of modularity automatically do not

follow the act of subdividing a program.

• Each module should encapsulate information

that is not available to the rest of a program.

• This reduces the cost of subsequent design