unit 5-design engineering

8/11/2019 Unit 5-Design Engineering

1/40

Unit 5Design Engineering

-Edited by

Shubha Puthran


2/40

Introduction Design engineering encompasses the set of

principles, concepts and practices that leads to thedevelopment of a high-quality system or product.

Design creates representation/model of the s/w ,but unlike analysis (that focuses on describing

required data, function and behavior), the designmodel provides detail about s/w data structures,architecture interfaces and components that arenecessary to implement the system.

The goal of design engineering is to produce amodel or representation that exhibits firmness,commodity and delight.


3/40

Design within the context of SE

S/w design sits at the kernel of s/w

engineering

Each of the elements of the analysis model

provides information that is necessary to

create the four design models required fora complete specification of design.


4/40

Analysis Model -> Design Model

Analysis Model

use-cases - text

use-case diagramsactivity diagrams

swim lane diagrams

data flow diagrams

control-flow diagramsprocessing narratives

f low- ori ent ed

ele ment s

behav ior a lele ment s

cl ass- based

ele ment s

scenar io- based

ele ment s

class diagramsanalysis packages

CRC models

collaboration diagrams

state diagrams

sequence diagramsDa t a/ Class De sign

Archi t ec t ura l Des ign

In t e r f a c e De s ig n

Com pone nt -

L e v e l De s ig n

Design Model


5/40


The data/class design transforms analysis-class models

into design class realizations and the requisite datastructures required to implement the s/w. Basis: CRC index cards and all other data information

(attributes)

The architectural design defines the relationshipbetween major structural elements of the s/w, thearchitectural styles and design patterns that can beused to achieve the requirements defined for thesystem, and the constraints that affect the way in which

architecture can be implemented. Basis: system specification, the analysis model and the

interaction of subsystems


6/40


The interface design describes how the s/wcommunicates with systems that interoperatewith it, and with humans who use it. Aninterface implies a flow of information and aspecific type of behavior.

Basis: usage scenarios and behavioral models

The component-level design transformsstructural elements of the s/w architecture

into a procedural description of s/wcomponents. Class-based models, flow-models and behavioral

models serve as the basis for component design.


7/40

Design Process and Quality

S/w design is an iterative process through which

requirements are translated into a blueprint forconstructing the s/w.

Three characteristics that serves as a guide for theevaluation of a good design: the design must implement all of the explicit requirements

contained in the analysis model, and it must accommodateall of the implicit requirements desired by the customer.

the design must be a readable, understandable guide forthose who generate code and for those who test andsubsequently support the software.

the design should provide a complete picture of thesoftware, addressing the data, functional, and behavioraldomains from an implementation perspective.


8/40

Quality Guidelines

A design should exhibit an architecture that (1) has

been created using recognizable architectural stylesor patterns, (2) is composed of components thatexhibit good design characteristics and (3) can beimplemented in an evolutionary fashion.

A design should be modular; that is, the softwareshould be logically partitioned into elements orsubsystems.

A design should contain distinct representations ofdata, architecture, interfaces, and components.


9/40

Quality Guidelines A design should lead to data structures that are appropriate for the

classes to be implemented and are drawn from recognizable datapatterns.

A design should lead to components that exhibit independentfunctional characteristics.

A design should lead to interfaces that reduce the complexity ofconnections between components and with the externalenvironment.

A design should be derived using a repeatable method that is drivenby information obtained during software requirements analysis.

A design should be represented using a notation that effectivelycommunicates its meaning.


10/40

Quality attributes

FURPS quality attributes:

Functionality: it is assessed by evaluating the feature set andcapabilities of the program, the generality of the functionsthat are delivered and the security of the overall system.

Usability: it is assessed by considering human factors, overallaesthetics, consistency and documentation

Reliability: it is evaluated ,by measuring the frequency and

severity of failure, the accuracy of output results, the mean-time-to-failure (MTTF), the ability to recover from failure andthe predictability of the program.


11/40

Quality attributes Performance: it is measured by processing

speed, response time, resource consumption,throughput and efficiency.

Supportability: it combines the ability toextend the program, adaptability andserviceability, in addition, testability,compatibility, configurability, the ease with

which a system can be installed and the easewith which problems can be localized.


12/40


13/40

Design Concepts

Abstractiondata, procedure, control

Architecturethe overall structure of the software

Patternsconveys the essence of a proven design solution

Modularitycompartmentalization of data and function

Information hidingcontrolled interfaces

Functional independencesingle-minded function and low

coupling

Refinementelaboration of detail for all abstractions

Refactoringa reorganization technique that simplifies thedesign

Design classes


14/40

Abstraction

When we consider a modular solution to any problem, many

levels of abstraction can be posed. Data abstractions and Procedural abstractions

A procedural abstraction refers to a sequence of instructions

that have a specific and limited function

Example: Openfor a door : open implies a sequence ofsteps (walk to the door, reach out and grasp knob, turn

knob and pull door)

A data abstraction is a named collection of data that describesa data object.

Example: data abstraction for door includes attributes that

describe the door.


15/40

Data Abstraction

door

implemented as a data structure

manufacturermodel numbertypeswing direction

insertslightstypenumber

weightopening mechanism


16/40

Procedural Abstraction

open

implemented with a "knowledge" of the

object that is associated with enter

details of enteralgorithm


17/40

ArchitectureThe overall structure of the software and the ways in

which that structure provides conceptual integrity for a

system.

Structural Models: represent architecture as an organized

collection of program components.

Framework Models: increase the level of design

abstraction by attempting to identify repeatable

architectural design frameworks.

Dynamic Models: address the behavioral aspects of the

program architecture.

Process Models: focus on the design of the business or

technical process that the system must accommodate.

Functional Models: can be used to represent the

functional hierarchy of a system.


18/40

Patterns

A design pattern describes a design structurethat solves a particular design problem within a

specific context.

It helps to determine: Whether the pattern is applicable to the current

work

Whether the pattern can be reused

Whether the pattern can serve as a guide for

developing a similar, but functionally or structurally

different pattern.


19/40

Modularity

S/w is divided into separately named and

addressable components, called modules, that areintegrated to satisfy problem requirements.

Consider two problems p1 and p2. If the perceived

complexity of p1 is greater than the perceived

complexity of p2, it follows that the effort required to

solve p1 is greater then the effort required to solve

p2.

It also follows that the perceived complexity of 2problems when they are combined is often greater

than the sum of the perceived complexity when each

is taken separately.


20/40


21/40

Modularity: Trade-offsWhat is the "right" number of modules

for a specific software design?

optimal number

of modules

cost of

software

number of modules

moduleintegration

cost

module development cost


22/40

Information Hiding

module

controlledinterface

"secret"

algorithm

data structure

details of external interface

resource allocation policy

clients

a specific design decision


23/40

Information Hiding Modules should be specified and designed so that

information contained within a module is inaccessibleto other modules that have no need for suchinformation.

Benefits:

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 attribute of high quality design

results in higher quality software


24/40


25/40

Functional Independence

Coupling: is an indication of the relative

independence among modules.

It depends on the interface complexity

between modules, the point at which entry or

reference is made to a module, and what data

pass across the interface.

We strive for lowest possible coupling


26/40


27/40

Stepwise Refinement

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


28/40

Refactoring

"Refactoring is the process of changing a software

system in such a way that it does not alter theexternal behavior of the code [design] yet improvesits internal structure.

When software is refactored, the existingdesign 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.


29/40

Design Classes Analysis classes are refined during design to become

design classes that (i) refine the analysis classes by

providing design detail that will enable the classes tobe implemented and (ii) create a new set of designclasses that implement a s/w infrastructure tosupport the business solution.

There are 5 types:

User interface classes: define all abstractions that arenecessary for human computer interaction.

Business domain classes: the classes identify theattributes and services that are required to implement

some element of the business domain. Process classes: implement lower-level business

abstractions required to fully manage the businessdomain classes.

Persistent classes: represent data stores that will

persist beyond the execution of the s/w.


30/40

Design Classes System Classes: implement s/w management and control

functions that enable the system to operate and

communicate within its computing environment and withthe outside world.

Four characteristics of a well-formed design class:

Complete and Sufficient: a design class should be the

complete encapsulation of all attributes and methods that canreasonably be expected to exist for the class. Sufficiencyensures that the design class contains only those methods thatare sufficient to achieve the intent of the class.

Primitiveness: methods associated with a design class should

be focused on accomplishing one service for the class. High Cohesion: a cohesive design class has a small, focused set

of responsibilities.

Low Coupling: within the design model, it is necessary fordesign classes to collaborate with one another, but this

collaboration should be kept to an acceptable minimum.


31/40


32/40

The Design Model

process dimension

architecture

elements

interface

elements

component -level

element s

deployment -level

elements

low

high

class diagrams

analysis packages

CRC models


use-cases - text

use-case diagrams

activity diagrams

swi m lane diagrams

collaboration diagrams data flow diagrams

control-flow diagrams

processing narratives

data flow diagrams

control-flow diagrams

processing narratives

state diagrams

sequence diagrams

state diagrams

sequence diagrams

design class realizations

subsystems


design class realizat ions

subsystems


refinements to:

deployment diagrams

class diagrams

analysis packages

CRC models


component diagrams

design classes

activity diagrams

sequence diagrams

refinements to:

component diagrams

design classes

activity diagrams

sequence diagrams

design class r ealizations

subsystems


component diagrams

design classes

activity diagrams

sequence diagrams

analysis model

design mode l

Requirement s:

constraints

interoperabilit y

t argets and

configuration

technical interface

design

Navigation design

GUI desi gn

Th D i M d l


33/40

The Design Model

Data Design Elements:

it creates a model of data that is represented at a high level

of abstraction. This data model is refined into more implementation-

specific representations that can be processed by computersystem.

The design of data structures and the associated algorithms

required to manipulate them is essential to the creation ofhigh-quality s/w.

The translation of data model into a database and thecollection of database reorganized into a data warehousewhich enables data mining or knowledge discovery.

Architecture Design Elements: it gives an overall view of the s/w.

it is derived from 3 sources:

(1) information about the application domain for the s/w tobe built (2) specific analysis elements such as DFDs

(3) the availability of architectural patterns and styles.


34/40


35/40

Interface Elements

Cont rolPanel

LCDdisplay

LEDindicatorskeyPadCharacteristics

speaker

wirelessInterface

readKeyStroke()

decodeKey()

displayStatus()

lightLEDs()

sendControlMsg()

Figure 9.6 UML interface represent at ion forCont ro lPane l

KeyPad

readKeystroke()

decodeKey()

WirelessPDA

KeyPad

MobilePhone


36/40

The Design Model Component-level Design Elements:

It describes the internal details of each s/w component.

It defines data structures for all data objects and algorithmicdetail for all processing that occurs within a component andan interface that allows access to all component operations.

SensorManagementSensor


37/40

The Design Model Deployment-level Design

Elements:

It indicate how s/w functionality

and subsystems will be allocated

within the physical computing

environment that will support the

s/w.

Figure 9 .8 UML deploym ent diagram for SafeHome

Personal comput er

Security

homeManagement

Surveillance

communication

Cont rol Panel CPI serve r

Security homeownerAccess

externalAccess


38/40

Pattern-based s/w design

The best designers in any field have an uncanny(weird) ability to

see patterns that characterize a problem and correspondingpatterns that can be combined to create a solution

A description of a design pattern may also consider a set of

design forces.

Design forces describe non-functionalrequirements (e.g., ease of maintainability,

portability) associated with the software for which

the pattern is to be applied.

The pattern characteristics (classes, responsibilities, andcollaborations) indicate the attributes of the design that may be

adjusted to enable the pattern to accommodate a variety of

problems.


39/40

Pattern-based s/w design Using Patterns in Design: The following are the types of

design patterns Architectural Patterns: they define the overall structure of

the s/w, indicate the relationships among subsystems ands/w components and define the rules for specifyingrelationships among the elements of the architecture.

Design Patterns: they address a specific element of thedesign such as an aggregation of components to solve somedesign problem, relationship among components or themechanisms for effecting component-to-componentcommunication.

Idioms(coding patterns): like algorithmic element of acomponent, a specific interface or a mechanism forcommunication among components.


40/40

Frameworks

A framework is not an architectural pattern,

but rather a skeleton with a collection of plugpoints (also called hooks and slots) thatenable it to be adapted to a specific problemdomain.

Design patterns are more abstract thanframeworks.

Design patterns are smaller architectural elementsthan frameworks

Design patterns are less specialized thanframeworks

unit 5-design engineering

Documents