Top Banner
Software Design
30
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1: Software Design

Software Design

Page 2: Software Design

SW Design

Software design is an iterative process

through which requirements are translated

into a “blueprint” for constructing the

software.

Initially, the blueprint depicts a holistic view of

software.

Page 3: Software Design

Process of Design Engineering

During the design process the software specifications are transformed into design models

Models describe the details of the data structures, system architecture, interface, and components.

Each design product is reviewed for quality before moving to the next phase of software development.

At the end of the design process a design modeland specification document is produced.

This document is composed of the design models that describe the data, architecture, interfaces and components.

Page 4: Software Design

Entity-

Relationship

Diagram

Data Flow

Diagram

State-Transition

Diagram

Data Dictionary

Process Specification (PSPEC)

Control Specification (CSPEC)

Data Object Description

THE ANALYSIS MODEL

proceduraldesign

interfacedesign

architecturaldesign

datadesign

THE DESIGN MODEL

Page 5: Software Design

Design Specification Models

Data design – created by transforming the analysis information model (data dictionary and ERD) into data structures required to implement the software. Part of the data design may occur in conjunction with the design of software architecture. More detailed data design occurs as each software component is designed.

Architectural design - defines the relationships among the major structural elements of the software, the “design patterns” than can be used to achieve the requirements that have been defined for the system, and the constraints that affect the way in which the architectural patterns can be applied. It is derived from the system specification, the analysis model, and the subsystem interactions defined in the analysis model (DFD).

Page 6: Software Design

Design Specification Models

Interface design - describes how the software elements communicate with each other, with other systems, and with human users; the data flow and control flow diagrams provide much of the necessary information required.

Procedural / Component-level design - created by transforming the structural elements defined by the software architecture into procedural descriptions of software components using information obtained from the process specification (PSPEC), control specification (CSPEC), and state transition diagram (STD).

Page 10: Software Design

Patterns

a pattern is “a common solution to a common problem in a given context.” While architectural styles can be viewed as patterns describing the high-level organization of software (their macroarchitecture), other design patterns can be used to describe details at a lower, more local level (their microarchitecture).

Creational patterns (example: builder, factory, prototype, and singleton)

Structural patterns (example: adapter, bridge, composite, decorator, façade, flyweight, and proxy)

Behavioral patterns (example: command, interpreter, iterator, mediator, memento, observer, state, strategy, template, visitor)

Page 11: Software Design

Design Pattern

Design Pattern enables a designer to

determine whether the pattern :

is applicable to the current work

can be reused

can serve as a guide for developing a similar, but

functionally or structurally different pattern.

Page 12: Software Design

Modular Design

Easier to change

Easier to build

Easier to maintain

Page 13: Software Design

Sizing Modules: Two Views

MODULE

What's inside??

How big is it??

Page 14: Software Design

Information Hiding

Principle of information hiding says that a good split

of modules is when modules communicate with one

another with only the information necessary to

achieve the s/w function.

So information hiding enforces access constraints to

both

procedural detail with a module, and

local data structure used by that module.

Data hiding is a CRITERION for modular design.

How to know what modules to create.

Page 15: Software Design

Information Hiding

modulecontrolledinterface

"secret"

• algorithm

• data structure

• details of external interface

• resource allocation policy

clients

a specific design decision

Page 17: Software Design

17

Functional Independence

COHESION - the degree to which a module performs one and only one function. COUPLING - the degree to which a module is "connected" to other modules in the system.

Page 18: Software Design

Cohesion

Internal glue with which component is constructed

All elements of component are directed toward and

essential for performing the same task

Page 19: Software Design

Range of Cohesion

High Cohesion

Low

Functional

Sequential

Communicational

Procedural

Temporal

Logical

Coincidental

Page 20: Software Design

Examples of Cohesion-1

Function A

Function

BFunction

D

Function

CFunction

E

Coincidental

Parts unrelated

Function A

Function A’

Function A’’

logic

Logical

Similar functions

Time t0

Time t0 + X

Time t0 + 2X

Temporal

Related by time

Function A

Function B

Function C

Procedural

Related by order of functions

Page 21: Software Design

Examples of Cohesion-2

Function A part 1

Function A part 2

Function A part 3

Functional

Sequential with complete, related functions

Function A

Function B

Function C

Communicational

Access same data

Function A

Function B

Function C

Sequential

Output of one is input to another

Page 22: Software Design

Coupling

Degree of dependence among components.

No dependencies Loosely coupled-some dependencies

Highly couples-many dependencies

Page 23: Software Design

Ways components can be dependent References made from one to another

Component A invokes B

A depends on B for completion of its function or process

Amount of data passed from one to another

Component A passes to B: a parameter, contents of an array, block of

data

Amount of control one has over the other

Component passes a control flag to B

Value of flag tells B the state of some resource or subsystem, process

to invoke, or whether to invoke a process

Degree of complexity in the interface between components

Components C and D exchange values before D can complete

execution

Page 24: Software Design

Range of Coupling

High Coupling

Loose

Low

Content

Common

External

Control

Stamp

Data

Uncoupled

Page 25: Software Design

Content Coupling : (worst) When a moduleuses/alters data in another module

Common Coupling : 2 modules communicatingvia global data

External Coupling :Modules are tied to anenvironment external to the software

Control Coupling : 2 modules communicatingwith a control flag

Page 26: Software Design

Stamp Coupling : Communicating via adata structure passed as a parameter. Thedata structure holds more information thanthe recipient needs.

Data Coupling : (best) Communicatingvia parameter passing. The parameterspassed are only those that the recipientneeds.

No data coupling : independent modules.

Page 27: Software Design

Summary

The measure of strength

of the association of

elements within a module

The measure of

interdependence of one

module to another

It is the degree to which

the responsibility of a

single component form a

meaningful unit

It describes the

relationship between

software components

It is a property or

characteristic of an

individual module

It is a property of a

collection of modules

COHESION COUPLING

Page 28: Software Design

Refinement

Refinement is a process of elaboration

It is a top-down design strategy

A program is developed by successfully refining levels of procedural

details

Page 29: Software Design

Stepwise Refinement

Open Door

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

Page 30: Software Design

Refactoring

Fowler [FOW99] defines refactoring in the following manner: "Refactoring is the process of changing a software system in

such a way that it does not alter the external behavior of the code [design] yet improves its internal structure.”

When software is refactored, the existing design is examined for redundancy

unused design elements

inefficient or unnecessary algorithms

poorly constructed or inappropriate data structures

or any other design failure that can be corrected to yield a better design.