Design

19
Design Engineering 1

Transcript of Design

Page 1: Design

Design Engineering

1

Page 2: Design

Fundamental Concepts

2

abstraction—data, procedure, control architecture—the overall structure of the software modularity—compartmentalization of data and function Functional independence—single-minded function and low coupling hiding—controlled interfaces refinement—elaboration of detail for all abstractions Refactoring—a reorganization technique that simplifies the design

Page 3: Design

Data Abstraction

3

Abstraction is the intellectual tool that allows us to deal with concepts apart from particular instances of those concepts. During requirements definition an design, abstraction permits separation of the conceptual aspects of a system from the implementation details

Page 4: Design

Procedural Abstraction

4

openopen

implemented with a "knowledge" of the object that is associated with enter

details of enter details of enter algorithmalgorithm

Page 5: Design

Three widely used abstraction mechanism in s/w design are

functional abstractiondata abstractioncontrol abstraction.

5

Page 6: Design

Functional Abstraction

Functional Abstraction It involves the use of parameterized subprograms. The

ability to parameterize a subprogram and to bind different parameter values on different invocations of the subprogram is a powerful abstraction mechanism.

Data AbstractionIt involves specifying a data type or a data object by specifying legal operations on objects. Representation and manipulation details are suppressed.

 

6

Page 7: Design

Control Abstraction It is the third commonly used abstraction mechanism

in software design. Control abstraction is used to state a desired effect without stating the exact mechanism of control. IF statements and WHILE statements in modern programming languages are abstractions of machine code implementations that involve conditional jump instructions. A statement of the form

“for all I in S sort files I”leaves unspecified the sorting techniques, the nature of S,

the nature of the files, and how “for all I in S” is to be handled

7

Page 8: Design

Architecture

8

““The overall structure of the software and the The overall structure of the software and the ways in which that structure provides ways in which that structure provides conceptual integrity for a system.” [SHA95a]conceptual integrity for a system.” [SHA95a]

Structural properties.Structural properties. This aspect of the architectural design This aspect of the architectural design representation defines the components of a system (e.g., modules, representation defines the components of a system (e.g., modules, objects, filters) and the manner in which those components are objects, filters) and the manner in which those components are packaged and interact with one another. For example, objects are packaged and interact with one another. For example, objects are packaged to encapsulate both data and the processing that packaged to encapsulate both data and the processing that manipulates the data and interact via the invocation of methods manipulates the data and interact via the invocation of methods

Extra-functional properties.Extra-functional properties. achieves requirements for performance, achieves requirements for performance, capacity, reliability, security, adaptability, and other system capacity, reliability, security, adaptability, and other system characteristics.characteristics.

Families of related systems.Families of related systems. The architectural design should draw The architectural design should draw upon repeatable patterns that are commonly encountered in the upon repeatable patterns that are commonly encountered in the design of families of similar systems. In essence, the design should design of families of similar systems. In essence, the design should

have the ability to reuse architectural building blocks.have the ability to reuse architectural building blocks.

Page 9: Design

Modular Design

9

easier to build, easier to change, easier to fix ...

Modularity is the way of defining the system as a collection of well defined, manageable units with well defined interfaces among the units. Desirable properties of a modular system include:•Each module is a well defined subsystem that is potentially useful in other applications•Each module has a single, well defined purpose.•Modules can be separately compiled and stored in a library•Modules can use other modules.•Modules should be easier to use than to build•Modules should be simpler from the outside than from the inside.

Page 10: Design

Modularity: Trade-offs

10

What is the "right" number of modules What is the "right" number of modules for a specific software design?for a specific software design?

optimal numberoptimal number of modulesof modules

cost ofcost of softwaresoftware

number of modulesnumber of modules

modulemoduleintegrationintegration

costcost

module development cost module development cost

Page 11: Design

Functional Independence

11

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.

abstractionabstraction

architecturearchitecture

modularitymodularity

functional functional independenceindependence

hidinghiding

refinementrefinement

refactoringrefactoring

Page 12: Design

CouplingCoupling is the measure of the degree of

interdependence between modules. Two modules with high coupling are strongly interconnected and thus, dependent on each other.

12

•Content/Pathological Coupling : (worst) When a module uses/alters data in another •Control Coupling : 2 modules communicating with a control flag (first tells second what to do via flag) •Common/Global-data Coupling : 2 modules communicating via global data •Stamp/Data-structure Coupling : Communicating via a data structure passed as a parameter. The data structure holds more information than the recipient needs. •Data Coupling : (best) Communicating via parameter passing. The parameters passed are only those that the recipient needs.

Page 13: Design

CohesionCoincidental Cohesion : (Worst) Module elements are

unrelated Logical Cohesion : Elements perform similar activities as selected from outside module, i.e. by a flag that selects operation to perform

Logical cohesionTemporal Cohesion : operations related only by general

time performed (i.e. initialization() or FatalErrorShutdown?()) Procedural Cohesion : Elements involved in different but sequential activities, each on different data

13

Page 14: Design

CohesionSequential Cohesion : operations on same data in

significant order; output from one function is input to next (pipeline)

Informational Cohesion: a module performs a number of actions, each with its own entry point, with independent code for each action, all performed on the same data structure. Essentially an implementation of an

Functional Cohesion : all elements contribute to a single, well-defined task, i.e. a function that performs exactly one operation

14

Page 15: Design

Communicational Cohesion : unrelated operations except need same data or input

15

Page 16: Design

Information Hiding

16

modulemodulecontrolledcontrolledinterfaceinterface

"secret""secret"

• • algorithmalgorithm

• • data structuredata structure

• • details of external interfacedetails of external interface

• • resource allocation policyresource allocation policy

clientsclients

a specific design decisiona specific design decision

abstractionabstraction

architecturearchitecture

modularitymodularity

functional functional independenceindependence

hiding hiding

refinementrefinement

refactoringrefactoring

Page 17: Design

Why Information Hiding?

17

reduces the likelihood of “side effects”

limits the global impact of local design decisions

emphasizes communication through controlled interfaces

discourages the use of global dataleads to encapsulation—an attribute

of high quality designresults in higher quality software

Page 18: Design

Stepwise Refinement

18

open

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

abstractionabstraction

architecturearchitecture

modularitymodularity

functional functional independenceindependence

hiding hiding

refinementrefinement

refactoringrefactoring

Page 19: Design

Refactoring

19

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 redundancyunused design elements inefficient or unnecessary algorithmspoorly constructed or inappropriate data structuresor any other design failure that can be corrected to yield

a better design.

abstractionabstraction

architecturearchitecture

modularitymodularity

functional functional independenceindependence

hiding hiding

refinementrefinement

refactoringrefactoring