Design1

50
Guide: Er. Deepinder Kaur Presented By: Sonali Nikhil Pallavi

Transcript of Design1

Page 1: Design1

Guide: Er. Deepinder Kaur Presented By: Sonali Nikhil Pallavi

Page 2: Design1
Page 3: Design1

Computer software, or just software, is a collection of computer programs and related data that provides the instructions for telling a computer what to do and how to do it.

Software is a set of programs, procedures, algorithms and its documentation concerned with the operation of a data processing system.

Page 4: Design1

System Development Life Cycle

Page 5: Design1

We are going to

study about the

design phase.

Page 6: Design1

Design process takes inputs of software

specifications and is dedicated to plan for

implementation of the software.

The focus of this process is to cover the gap

between understanding the specification and

implementing them in the software

These design elements are intended to

describe the software in sufficient detail.

Design elements describe the desired

software features in detail

Page 7: Design1

Design Phase

Structured

Analysis Structured

design

Page 8: Design1

Structured Analysis (SA) in

software engineering and its

allied technique, Structured

Design (SD), are methods for

analyzing and converting

business requirements into

specifications and ultimately,

computer programs, hardware

configurations and related

manual procedures.

Structured analysis

Page 9: Design1

Analysis model

Scenario based

Flow oriented based

Class based

Behavioral

Page 10: Design1

To describe customer

requirement

To establish basis of

design

Page 11: Design1

A data flow diagram (DFD) is a graphical representation of the "flow" of data through an information system, modeling its process aspects.

A DFD shows what kinds of information will be input to and output from the system, where the data will come from and go to, and where the data will be stored.

Page 12: Design1

Synchronous

operations

Asynchronous

operations

If data is going from 1

bubble to another

If data goes to a

data store then to

other bubble

Page 13: Design1

Level 0 P

0

Level 1 P1

0.1

Level 2 P11

0.1.1

P12

0.1.2

Balancing

DFD’s

Page 14: Design1

Also known as “high – level design”

Software architecture is made with the help of structured charts

Page 15: Design1

Characteristics of Software Design

Correctness

Understandability

Efficiency

Maintainability

Page 16: Design1

Identify nature of

requirement.

Analysis & build

modal

Validate solution

Refine design solution

Implement design

solution

Requirement

specification

Functional

specification

system

Mismatch b/w

modal & design

are removed

Design blueprint

Software

architecture

Process Outcome

Page 17: Design1

Concepts

of design modularity

abstraction

cohesion

coupling

Problem

partitioning

& hierarchy

Page 18: Design1

Modularity

Concept of keeping

separate the various

unrevealed aspects

of a system so that

each aspect can be

studied in isolation.

A

B C

Page 19: Design1

It helps in system debugging.

In system repairs.

In system building.

Page 20: Design1

Condition must for

modularity!!

Each module needs

to support a well-

defined abstraction &

have a clear interface

through which it can

interact with other

modules.

Page 21: Design1

Decomposition

Is creating lower level elements from higher lever key element

on the basis of functions & features.

Result of this is called MODULES.

Page 22: Design1

Abstraction of a component describes the

external behaviour of that component without

bothering with the internal details that produce

the behaviour

It is essential for problem partitioning.

Page 23: Design1

Functional

abstraction Data

abstraction

Page 24: Design1

1.

• Is the basis of partitioning in the functional oriented

approach

2.

• when problem is being partitioned ,the complete

transformation function for the system is partitioned into

smaller functions

3.

• The decomposition of the system is in terms of functional

modules

Page 25: Design1

It supports certain operations required

from a data object, depending on the

object & environment in which it is used.

Only such operations are visible &

internals are hidden.

It forms the basis of object oriented

design.

Page 26: Design1

Rule of “Divide & Conquer”.

Goal is to divide the problem into manageable small pieces that can be solved

separately

The cost of solving the entire problem is more than the sum of the cost of

solving all the pieces

Different pieces have to cooperate & communicate to solve larger problem

The design produced by using problem partitioning can be represented as a

hierarchy of components

Page 27: Design1

Hierarchical structure makes it much easier to comprehend larger problems

All design methodologies aim to produce a design that employs hierarchical

structures

Page 28: Design1

Fan-in refers to no. of units that use

a particular software unit.

Fan-out refers to no. of units used by

particular software unit

Page 29: Design1

A

B

D E

C

F

Super-ordinate

of B & C

Sub-ordinate of A

& super-ordinate of

D , E & F

Sub-ordinate of B

& C

Fan-in for B

is 1 & fan-

out is 2

Page 30: Design1

Two modules are considered independent if one can

function completely without the presence of other.

The more connections between the modules ,the more they

are dependent.

Hence, fewer & simpler the connections between modules

the easier is to understand them.

Page 31: Design1

Coupling is the strength of

interconnections between

modules.

Highly – coupled modules

are joined by strong

interconnections.

While loosely-coupled

modules have weak

connections.

Independent modules have

no interconnections.

A B

C D

Highly

coupled

A B

C D

Loosely

A B Uncoupled

Page 32: Design1

Coupling increases the complexity.

To minimize coupling , the no. of interfaces per module.

Interface is used to pass information to & from modules.

Page 33: Design1

Reference made from 1 module to another

Amount of data passed from 1 module to another

Amount of control passed from 1 module to another

Page 34: Design1

It represents how tightly bound the internal elements

of the module are to 1 another.

It gives an idea whether the different elements of a

module belong together in the same module.

Greater the cohesion of each module in the system ,

lower the coupling between modules is.

Page 35: Design1

Co-incidental

logical

temporal

procedural

communicational

sequential

functional

Page 36: Design1
Page 37: Design1

Component level design

Interface design

Architectural design

Data/class design

Page 38: Design1

Known as structural decomposition: actually a

conversion of Data flow Diagram to Structured

chart

Page 39: Design1

Selection: determined by “diamond”. This means condition will

checked & depending on these modules will be executed.

Process

Process Process

Page 40: Design1

Using “semi-circular arrow we represent this.

This arrow includes a link to a module implying

that module is executed multiple times

A

B C D

Page 41: Design1

Module A

Invocation

arrow

Parameters

Page 42: Design1

Input module: obtain info. From subordinate &

passes to super-ordinate

Input module

Page 43: Design1

Output module : takes info. From their

super-ordinate & pass to sub-ordinate.

Output module

Page 44: Design1

Transform module : that

transform data into other form.

Transform module

Page 45: Design1

Co-ordinate module: manages info. To & from other

sub-ordinates.

Co-ordinate module

A B

Page 46: Design1

Composite module: perform function of more than 1

module.

Composite module

B C

Page 47: Design1

Transformation of DFD to structured

design.

Identify system

processing

transform

Identify input

transform

Identify output

transform

Page 48: Design1

Main

readnums Sort Add_n

switch

A,n

A,n a

X,y X,y

A,n

sum

Page 49: Design1

Any questions

Page 50: Design1

Thankyou you

Made By :

Sonali Narang

B.Ca