You are on page 1of 30

Software Design

By Neha Patel
 The goal of the design process is to produce a model or
representation of a system, which can be used for developing the
system..

 The design of the system is produced keeping in mind the
constraints and limitations imposed by the client’s need..

 The input to the design phase are validated spec/reqmts; O/P is the
architectural or system design.

 This phase consists of 2 stages: System design & Detailed design

By Neha Patel
 Some of the desirable properties for the s/w system design are:
>> Verifiability >> Efficiency
>> Completeness >> Traceability
>> Consistency >>
Simplicity/Understandability

By Neha Patel
Problem Partitioning
 Smaller problems do not require partitioning..

 For larger problems, divide and conquer strategy is used..

 Divide the problem into manageable smaller pieces which can
be solved easily and separately..

 Cost of solving the entire problem is more than the sum of the
cost of solving all the pieces..

 The pieces cannot be entirely independent, as they together
form the system..

By Neha Patel
 Co-operation and communication is reqd between different pieces; this
adds complexity.

 When the cost of partitioning + complexity becomes higher than the
saving achieved by partitioning; further breakdown is not reqd (stop
partitioning)..

 Simplicity and understandability can be achieved by partitioning..

 It also helps in maintenance and design verification..

 Partitioning may also lead to hierarchical designs..

By Neha Patel
Abstraction
 An abstraction of a component describes the external behavior of that
component, without bothering the internal details…

 Component can be considered at an abstract level..

 Abstraction is important for problem partitioning, PP is actually
understanding the system components..

 To concentrate on one component, abstraction of other components is used..

 In order to understand behavior the system, the abstraction of the subsystem
or components can be identified…

By Neha Patel
 When the components donot exists, their abstract specification
can be specified.

 The goal of the system design is to specify the modules in a
system and their abstractions..

 Later in the detailed design phase, designer can concentrate on
each module..

 The abstract specification of each module should be satisfied,
in the detailed design and the implementation phase..

 2 abstraction mechanisms:
 Functional abstraction

 Data abstraction

By Neha Patel
 Functional abstraction
 Module is specified by the functions it performs..
 The system can be decomposed into functional modules..

 Data abstraction
 Data is treated as objects, with predefined operations on them..
 Theses are the only operations that can be performed on them..
 The internal details are hidden, the operations are visible..
 The system is decomposed in w.r.t. the objects, the system contains..

By Neha Patel
Top Down & Bottom Up
Strategies
 Any system consists of components, it is a hierarchy of
components

 The highest level component corresponds to the total system..

 For designing hierarchy, 2 approaches are possible:
 Top-down approach

 Bottom-up approach

By Neha Patel
 Top-Down Approach:
 It starts from the highest level component proceeding

through the lower levels.

 Identify the major component, decompose into lower level
components, keep iterating until desired level of detail is
obtained..

 It results in stepwise refinement

 It starts with an abstract design, in each step the design is
refined, until a level where no refinement is needed..

 It is suitable if the spec. are clearly known….

By Neha Patel
 Bottom-Up Approach
 It starts with the lower level component and proceeds

progressively through higher levels..

 The most basic or primitive components are designed, later
proceed to the higher level components which use them..

 It has layers of abstraction.

 Operations that provide a layer of abstraction are implm, this
layer can later be used to implement higher level component..

 System is to be built from existing sys, bottom-up approach is
suitable..

By Neha Patel
Module Level Concepts
 Module is a logically separable part of a program.

 Modularity is a desirable property of a system..

 Certain criteria should be satisfied so as to make the modules
modifiable and solvable..

 2 modularization criteria are:
 Cohesion

 Coupling

By Neha Patel
Coupling:
 Coupling between modules is the strength of interconn between
modules OR a measure of interdependence among modules..

 Any two modules cannot be completely independent; they need
to interact with each other..

 If they are independent; easy to modify and are solvable..

 More the conn., more is the dependencies..

 The fewer and simpler the conn, the easier it is to understand
the modules individually..

By Neha Patel
 Highly coupled modules -- STRONG interconns
 Loosely coupled modules -- WEAK interconns
 Independent modules – NO interconns

 Modules are decided during system design; coupling is also decided; it
cannot be modified during implm.

 Coupling is affected by complexity and obscurity..

 Coupling can be minimized by reducing the number of interfaces and
minimizing the complexity of the modules..

 There should be a defined entry interface of a module which should be
used for comm; indirect and obscure use should be avoided (eg. using
shared variables)

By Neha Patel
 More the complexity of the interface higher is the degree of
coupling..

 Hence the interface should be simple and small….

 The type of information flow also affects coupling; 2 types of
information flow along the intf: data & control

 Control flow: passing or receiving ctrl info on the basis of which
the module will behave; it is difficult to understand the
abstraction of the module….

 Data flow: passing or receiving data info; data comm provides
lowest degree of coupling..

By Neha Patel
Cohesion
 It represents how tightly the internal elements of the modules are
bounded.

 The relation between the elements of the same module should be
strengthen, and with other modules should be reduced
(i.e.coupling)

 Cohesion is an intra modular concept..

 GREATER the cohesion of each modules, LOWER will be the
coupling between the modules…

By Neha Patel
 Several levels of cohesion:
 Coincidental

 Logical

 Temporal

 Procedural

 Communicational

 Sequential

 Functional

 Coincidental is the lowest level and functional is the highest level
of cohesion

 Lower levels should be avoided and higher level should be
achieved..

By Neha Patel
 Coincidental
 If an existing system is modularized by simply breaking the
program into pieces and making them modules..
 There is no meaningful relationship between the elements..
 Modifications is difficult due to strong interconnections.

 Logical
 If there is a logical relationship among the elements of the
modules.
 Logically cohesive modules should be avoided; they might
result in hybrid info flow between modules..

 Temporal
 The functions are related in time and are executed together.
 Activities like init, clean up etc are temporally bounded.
 The code usually simpler as compared to the logical level.

By Neha Patel
 Procedural
 Elements belong to a common procedural unit.
 It occurs if module structure is in the form of a flowchart
 Eg. Loop and decision stmts together may form a module

 Communicational
 Elements are related by a reference to the same i/p and o/p data.
 Elements that operate on the same i/p or o/p data can be put together.

 Sequential
 The o/p of one module forms the i/p of the other and these elements
are grouped in modules
 No guidelines on how to combine the elements in modules.

By Neha Patel
 Functional
 It is the strongest cohesion

 All elements are related to performing a simple function

 Elements accomplishing a single goal

 Eg. Sorting or mathematical function

By Neha Patel
Design Specification
 Structure Charts-
 Can be used to represent a function oriented design (functional

abstraction)

 The design can be represented graphically using structure charts..

 The struc of the program shows modules of that program & the
interconns between them…

 The basic focus is on representing the hierarchy of modules..

By Neha Patel
 In a structure chart a module is represented by a box with
the module name written in it..

 An arrow from A to B  A invokes B..

 A  superordinate of B ; B  subordinate of A..

 The parameters can be represented by small arrow along
with the direction of flow of i/p and o/p parameters.

 Iteration can be represented by a looping arrow around the
arrows joining the subordinates.

By Neha Patel
 Decisions can also be represented; if the invocation of a
particular module depends upon the decision in the
superordinate it can be represented by a small diamond…

 Modules can be categorized
 Input module

 Info is obtained from the subordinates & passed on to the
superordinate.
 It takes data from the sources & prepares it processing.

 Output module
 Info is taken from the superordinate & passed on to the
subordinate..
 It takes the output that is produced.

By Neha Patel
 Transform module
 It is related with transforming data into other form..
 It can be used to represent computational modules..

 Coordinate module
 The modules whose concern is to manage flow of data to and
from different subordinates can be represented thru this
module

 Composite module
 A module which can perform functions of more than one type
of modules can be represented using composite module…

By Neha Patel
 It is useful for creating the design

 It shows the modules their call hierarchy, the interfaces between them
& the info passed between them..

 It does not specify scope, structure of data or spec of each module..

 Hence it is not used to convey design to the implementer.

 For a given set of reqmts programs with different structures can be
obtained..

 The obj of the design phase is to fix the struc during design.

By Neha Patel
 In order to communicate the design to other programmers or using
it for future ref, the design needs to be formally specified.

 The design spec should be formalized in the design doc. which
can be used for further activities.

 The design spec should contain:
 Problem Spec

 The reqmts are translated into a specification of a problem which
is suited for design purpose.

 Major data struc.
 A formal definition of the data structures identified should be
specified..

By Neha Patel
 Modules & their struc.
 The design doc should specify the interface of the module (the
data items, type of module), the abstract behavior (the working
of that module), all the module using the particular module..
 This info can be used for maintaining & understandability..

 Design decisions
 The choices that were available & the reasons for making a
particular choice should also be specified..
 All the major decision taken during designing should also be
specified..

By Neha Patel
By Neha Patel
By Neha Patel
By Neha Patel