Design Concepts

Design
ItistheKernelofSE MitchKapor,thecreatorofLotus123,presented asoftwaredesignmanifestoinDr.DobbsJournal. Hesaid: Goodsoftwaredesignshouldexhibit: Firmness:Aprogramshouldnothaveanybugs thatinhibititsfunction. Commodity:Aprogramshouldbesuitablefor thepurposesforwhichitwasintended. Delight:Theexperienceofusingtheprogram shouldbepleasurableone. 2

Translating the Analysis model into a software design

Data Object Description EntityRelationship Diagram

Process Specification (PSPEC) Data Flow Diagram

procedural design

Data Dictionary

interface design architectural design data design

State-Transition Diagram

Control Specification (CSPEC)

THE ANALYSIS MODEL

THE DESIGN MODEL

Analysis Model -> Design Model

sc enario- based elements

use-cases - text use-case diagrams activity diagrams swim lane diagrams

f low- oriented elements

data flow diagrams control-flow diagrams processing narratives

Component L evel Design

Analysis Model

Int erfac e Design

c lass- based elements

class diagrams analysis packages CRC models collaboration diagrams

behavioral elements
state diagrams sequence diagrams

Arc hit ec t ural Design

Dat a/ Class Design

Design Model

Data Design transforms the information domain model created during analysis into the data structures Data objects and their relationships of ER diagram and data content of data dictionary forms the basis Architectural design defines the relationship between major structural elements of the software It is a framework of a computer based system Interface design describes how the software communicates DFD & CFD Component level design converts the structural elements of the software architecture into procedural description Information obtained from PSPEC, CSPEC & STD 5

the design must implement all of the explicit requirements contained in the analysis model, and it must accommodate all of the implicit requirements desired by the customer. the design must be a readable, understandable guide for those who generate code and for those who test and subsequently support the software. the design should provide a complete picture of the software, addressing the data, functional, and behavioral domains from an implementation perspective. 6

Design and Quality

Quality Guidelines A design should exhibit an architecture that (1) has been

created using recognizable architectural styles or patterns, (2) is composed of components that exhibit good design characteristics and (3) can be implemented in an evolutionary fashion
For smaller systems, design can sometimes be developed linearly.

A design should be modular; that is, the software should be logically partitioned into elements or subsystems A design should contain distinct representations of data, architecture, interfaces, and components. A design should lead to data structures that are appropriate for the classes to be implemented and are drawn from recognizable data patterns. A design should lead to components that exhibit independent functional characteristics. A design should lead to interfaces that reduce the complexity of connections between components and with the external environment. A design should be derived using a repeatable method that is driven by information obtained during software requirements analysis. A design should be represented using a notation that effectively communicates its meaning.

Design Principles
The design process should not suffer from tunnel vision. The design should be traceable to the analysis model. The design should not reinvent the wheel. The design should minimize the intellectual distance [DAV95] between the software and the problem as it exists in the real world. The design should exhibit uniformity and integration. The design should be structured to accommodate change. The design should be structured to degrade gently, even when aberrant data, events, or operating conditions are encountered. Design is not coding, coding is not design. The design should be assessed for quality as it is being created, not after the fact. The design should be reviewed to minimize conceptual (semantic) errors.
From Davis [DAV95]

Design Principles

Design Principles

10

Design Principles

11

Design Principles

12

Design Concepts

13

Fundamental Concepts
Abstractiondata, procedure, control Architecturethe overall structure of the software Patternsconveys the essence of a proven design solution Separation of concernsany complex problem can be more easily handled if it is subdivided into pieces Modularitycompartmentalization of data and function Hidingcontrolled interfaces Functional independencesingle-minded function and low coupling Refinementelaboration of detail for all abstractions Aspectsa mechanism for understanding how global requirements affect design Refactoringa reorganization technique that simplifies the design Design Classesprovide design detail that will enable analysis classes to be implemented

14

Abstraction

15

Procedural Abstraction
open
details of enter algorithm

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

16

17

Data Abstraction
door
manufacturer model number type swing direction inserts lights type number weight opening mechanism

implemented as a data structure

18

Stepwise Refinement

19

Stepwise Refinement
open

walk to door; reach for knob; open door; walk through; close door. repeat until door opens turn knob clockwise; if knob doesn't turn, then take key out; find correct key; insert in lock; endif pull/push door move out of way; end repeat

20

Modularity
"modularityisthesingleattributeof softwarethatallowsaprogramtobe intellectuallymanageable"[Mye78]. Monolithicsoftware(i.e.,alargeprogram composedofasinglemodule)cannotbe easilygraspedbyasoftwareengineer.
Thenumberofcontrolpaths,spanofreference, numberofvariables,andoverallcomplexity wouldmakeunderstandingclosetoimpossible.

Inalmostallinstances,youshouldbreak thedesignintomanymodules,hopingto 21 makeunderstandingeasierandasa

22

23

Modularity: Trade-offs
cost of software

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

module development cost

module integration cost

optimal number of modules

number of modules

24

Architecture
Theoverallstructureofthesoftwareandthewaysin whichthatstructureprovidesconceptualintegrityfora system.[SHA95a]
Structuralproperties.Thisaspectofthearchitecturaldesign representationdefinesthecomponentsofasystem(e.g.,modules, objects,filters)andthemannerinwhichthosecomponentsarepackaged andinteractwithoneanother.Forexample,objectsarepackagedto encapsulatebothdataandtheprocessingthatmanipulatesthedataand interactviatheinvocationofmethods Extrafunctionalproperties.Thearchitecturaldesigndescriptionshould addresshowthedesignarchitectureachievesrequirementsfor performance,capacity,reliability,security,adaptability,andother systemcharacteristics. Familiesofrelatedsystems.Thearchitecturaldesignshoulddrawupon repeatablepatternsthatarecommonlyencounteredinthedesignof familiesofsimilarsystems.Inessence,thedesignshouldhavetheability toreusearchitecturalbuildingblocks.

25

Control Hierarchy
It is also called as program structure, represents the organization of the components

26

Fan In indicates how many modules directly control the given module Fan- Out is a measure of the number of modules that are directly controlled by another module. A module that controls another module- Super ordinate A module controlled by another module is called subordinate
27

Structural Partitioning
Program structure can be partitioned both horizontally and vertically. Horizontal partitioning defines separate branches of the modular hierarchy for each program function. Partitioning the architecture horizontally provides a number of distinct benefits Easy to test Easy to Maintain Propagation of fewer side effects Easy to extend Disadvantage Complicate the overall control of program flow 28

29

Vertical partitioning
Factoring , the control and work should be top-down in the program structure. Top level modules - control functions. Modules in the low level should be the workers, performing all input, computation and output tasks. Propagation of side effects
30

Data Structure
Data structure is a representation of the logical relationship among individual elements of data. Data structure dictates the organization, methods of access, degree of associativity, and processing alternatives for information
31

Software Procedure
Program structure defines control hierarchy without regard to the sequence of processing and decisions. Software procedure focuses on the processing details of each module individually. Procedure must provide a precise specification of processing, including sequence of events, exact decision points, repetitive operations, and even data organization and structure.

32

Procedure is layered

33

Information Hiding
module
controlled interface algorithm data structure details of external interface resource allocation policy

clients

"secret"

a specific design decision

34

Why Information Hiding?

reduces the likelihood of side effects limits the global impact of local design decisions emphasizes communication through controlled interfaces discourages the use of global data leads to encapsulationan 35 attribute of high quality design

Sizing Modules: Two Views

W hat's inside??

How big is it??

MODULE

36

Functional Independence
Functionalindependenceisachievedby developingmoduleswith"singleminded" functionandan"aversion"toexcessive interactionwithothermodules. Cohesionisanindicationoftherelative functionalstrengthofamodule.

Couplingisanindicationoftherelative interdependenceamongmodules.

Acohesivemoduleperformsasingletask, requiringlittleinteractionwithother componentsinotherpartsofaprogram.Stated simply,acohesivemoduleshould(ideally)do justonething. 37 Couplingdependsontheinterfacecomplexity

Design Model Elements

Data elements
Data model --> data structures Data model --> database architecture

Architectural elements
Application domain Analysis classes, their relationships, collaborations and behaviors are transformed into design realizations Patterns and styles (Chapters 9 and 12)

Interface elements
the user interface (UI) external interfaces to other systems, devices, networks or other producers or consumers of information internal interfaces between various design components.

Component elements Deployment elements

38