Software Enggineering Design :

8/14/2019 Software Enggineering Design :

1/30

By Neha Patel

Software Design


2/30

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 clients 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


3/30

By Neha Patel

Some of the desirable properties for the s/w system design are:

>> Verifiability >> Efficiency>> Completeness >> Traceability

>> Consistency >>

Simplicity/Understandability


4/30

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 thecost of solving all the pieces..

The pieces cannot be entirely independent, as they togetherform the system..


5/30

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


6/30

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


7/30

By Neha Patel

When the components donot exists, their abstract specificationcan be specified.

The goal of the system design is to specify the modules in asystem 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


8/30

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


9/30

By Neha Patel

Top Down & Bottom UpStrategies 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


10/30

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.


11/30

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


12/30

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


13/30

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 understandthe modules individually..


14/30

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 beused for comm; indirect and obscure use should be avoided (eg. using

shared variables)


15/30

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


16/30

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


17/30

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


18/30

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.


19/30

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 elementsare grouped in modules

No guidelines on how to combine the elements in modules.


20/30

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


21/30

By Neha Patel

Design Specification Structure Charts-

Can be used to represent a function oriented design (functionalabstraction)

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


22/30

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

Asuperordinate of B ; Bsubordinate 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.


23/30

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

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.


24/30

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 thismodule

Composite module

A module which can perform functions of more than one typeof modules can be represented using composite module


25/30

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.


26/30

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


27/30

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 aparticular choice should also be specified..

All the major decision taken during designing should also be

specified..


28/30

By Neha Patel


29/30

By Neha Patel


30/30

By Neha Patel

Software Enggineering Design :

Documents

Transcript of Software Enggineering Design :