Software engg. pressman_ch-9

Chapter 9Design Engineering


1

Software Engineering: A Practitioner’s Approach, 6th editionby Roger S. Pressman



2

Software Engineering: A Practitioner’s Approach, 6th editionby Roger S. Pressman

Translating Analysis Model into Design Model

3

Translating Analysis Model into Design ModelData / Class design: transforms analysis-class models into design class realizations and the requisite data structures required to implement the software.Architectural Design: defines the relationship between major structural elements of the software, the architectural styles and design patterns that can be used to achieve the requirements defined for the system and the constraints that affect the way in which architectural can be implemented.

Data / Class design: transforms analysis-class models into design class realizations and the requisite data structures required to implement the software.Architectural Design: defines the relationship between major structural elements of the software, the architectural styles and design patterns that can be used to achieve the requirements defined for the system and the constraints that affect the way in which architectural can be implemented.

4

Translating Analysis Model into Design Model

Interface Design: describes how the software communicates with systems that interoperated with it, and with humans who use it.

Component level Design: transforms structural elements of the software architecture into procedural description of software components.

Interface Design: describes how the software communicates with systems that interoperated with it, and with humans who use it.

Component level Design: transforms structural elements of the software architecture into procedural description of software components.

5

Design Process and Design QualityCharacteristics that serve as a guide for the evaluation of a good design.

1. 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 customers.

2. The design must be readable, understandable guide for those who generate code and for those who test and subsequently support the software.

3. The design should provide a complete picture of the software, addressing the data, functional, and behavioral domains from an implementation perspective.

Characteristics that serve as a guide for the evaluation of a good design.

1. 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 customers.

2. The design must be readable, understandable guide for those who generate code and for those who test and subsequently support the software.

3. The design should provide a complete picture of the software, addressing the data, functional, and behavioral domains from an implementation perspective.

A design should exhibit an architecture that is : created using recognizable architectural styles or patterns composed of components that exhibits good design characteristics can be implemented in an evolutionary fashion , thereby facilitating implementation and testing.A design should be modular.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 pattern.

A design should exhibit an architecture that is : created using recognizable architectural styles or patterns composed of components that exhibits good design characteristics can be implemented in an evolutionary fashion , thereby facilitating implementation and testing.A design should be modular.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 pattern.

6

Characteristics of a good design

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.

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.

7

Characteristics of a good design

FURPS quality attributes represent a target for all software design.Functionality: assessed by evaluating the feature set and capabilities of the program, functions that are delivered, and the security of the overall system.Usability: assessed by considering human factors, overall aesthics, consistency and documentation.Reliability: 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, and the predictability of the program.

FURPS quality attributes represent a target for all software design.Functionality: assessed by evaluating the feature set and capabilities of the program, functions that are delivered, and the security of the overall system.Usability: assessed by considering human factors, overall aesthics, consistency and documentation.Reliability: 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, and the predictability of the program. 8

Quality Attributes

Performance: measured by processing speed, response time, resource consumption, throughput, and efficiency.

Supportability: combines the ability to extend the program (extensibility), adaptability, serviceability--- these three attributes represent a more common term, maintainability. In addition testability, compatibility, configurability, ease with which a system can be installed, and the ease with which problems can be localized.

Performance: measured by processing speed, response time, resource consumption, throughput, and efficiency.

Supportability: combines the ability to extend the program (extensibility), adaptability, serviceability--- these three attributes represent a more common term, maintainability. In addition testability, compatibility, configurability, ease with which a system can be installed, and the ease with which problems can be localized.

9

Quality Attributes contd…

abstraction — data, procedure, controlarchitecture — the overall structure of the softwarepatterns — “conveys the essence” of a proven design solutionmodularity — compartmentalization of data and functioninformation hiding — controlled interfacesfunctional independence — high cohesion and low couplingrefinement — elaboration of detail for all abstractionsrefactoring — improve design without effecting behavior

abstraction — data, procedure, controlarchitecture — the overall structure of the softwarepatterns — “conveys the essence” of a proven design solutionmodularity — compartmentalization of data and functioninformation hiding — controlled interfacesfunctional independence — high cohesion and low couplingrefinement — elaboration of detail for all abstractionsrefactoring — improve design without effecting behavior

10

Design Concepts

Abstraction: when we consider a modular solution to any problem, many levels of abstraction can be posed.(i) highest level – stated in broad terms(ii) lowest level – more detailed description is provided.As we move through different levels of abstraction, we work to create procedural and data abstractions.1) Procedural abstraction refers to a sequence of instructions that have a specific and limited function.2) Data abstraction is a named collection of data that describes a data object.

Abstraction: when we consider a modular solution to any problem, many levels of abstraction can be posed.(i) highest level – stated in broad terms(ii) lowest level – more detailed description is provided.As we move through different levels of abstraction, we work to create procedural and data abstractions.1) Procedural abstraction refers to a sequence of instructions that have a specific and limited function.2) Data abstraction is a named collection of data that describes a data object. 11

Design Concepts cont…....

12

Data Abstraction

door

ManufacturerModel noTypeWeightSwing directionOpening mechanism

Implemented as a data structure

13

Procedural Abstraction

open

Details of enter algorithm

Implemented with a “knowledge” of the object that is associated with enter

Architecture is the overall structure or organization of Architecture is the overall structure or organization of program components(modules), the manner in which these program components(modules), the manner in which these components interact, and the structure of data that are used by components interact, and the structure of data that are used by the components. the components.

A design pattern describes a design structure that solves a A design pattern describes a design structure that solves a particular design problem within a specific context and amid particular design problem within a specific context and amid “forces” that may have an impact on the manner in which the “forces” that may have an impact on the manner in which the pattern is applied and used.pattern is applied and used.

Architecture is the overall structure or organization of Architecture is the overall structure or organization of program components(modules), the manner in which these program components(modules), the manner in which these components interact, and the structure of data that are used by components interact, and the structure of data that are used by the components. the components.

A design pattern describes a design structure that solves a A design pattern describes a design structure that solves a particular design problem within a specific context and amid particular design problem within a specific context and amid “forces” that may have an impact on the manner in which the “forces” that may have an impact on the manner in which the pattern is applied and used.pattern is applied and used.

14

Architecture & Patterns

Software is divided into separately named components, called Software is divided into separately named components, called modules, that are integrated to satisfy problem requirements. modules, that are integrated to satisfy problem requirements.

When we sub divide software, the effort required to develop it When we sub divide software, the effort required to develop it will become small. However, as the number of modules grows, will become small. However, as the number of modules grows, the effort (cost) associated with integrating the modules also the effort (cost) associated with integrating the modules also grows.grows.

Why modularize a design ?Why modularize a design ? -development can be more easily planned, -development can be more easily planned, -software increments can be defined and delivered, -software increments can be defined and delivered, -changes can be more easily accommodated, -changes can be more easily accommodated, testing and debugging can be conducted more efficiently testing and debugging can be conducted more efficiently -long term maintenance can be conducted without serious side -long term maintenance can be conducted without serious side effects.effects.

Software is divided into separately named components, called Software is divided into separately named components, called modules, that are integrated to satisfy problem requirements. modules, that are integrated to satisfy problem requirements.

When we sub divide software, the effort required to develop it When we sub divide software, the effort required to develop it will become small. However, as the number of modules grows, will become small. However, as the number of modules grows, the effort (cost) associated with integrating the modules also the effort (cost) associated with integrating the modules also grows.grows.

Why modularize a design ?Why modularize a design ? -development can be more easily planned, -development can be more easily planned, -software increments can be defined and delivered, -software increments can be defined and delivered, -changes can be more easily accommodated, -changes can be more easily accommodated, testing and debugging can be conducted more efficiently testing and debugging can be conducted more efficiently -long term maintenance can be conducted without serious side -long term maintenance can be conducted without serious side effects.effects.

15

Modularity

16

Modular Design easier to build, easier to change, easier to fix ...easier to build, easier to change, easier to fix ...

Modularity: Trade-offsModularity: Trade-offs

17

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

The principle of information hiding suggests that modules be characterized by design decisions that (each) hides from all others. In other words, modules should be specified and designed so that information (algorithm and data) contained within a module is inaccessible to other modules that have no need for such information.

In short abstraction helps to define the procedural entities that make up the software. Hiding defines and enforces access constraints to both procedural detail within a module and any local data structure used by the module.

The principle of information hiding suggests that modules be characterized by design decisions that (each) hides from all others. In other words, modules should be specified and designed so that information (algorithm and data) contained within a module is inaccessible to other modules that have no need for such information.

In short abstraction helps to define the procedural entities that make up the software. Hiding defines and enforces access constraints to both procedural detail within a module and any local data structure used by the module.

18

Information Hiding

Functional independence is achieved by developing modules with single-minded function and with a dislike to excessive interaction with other modules.

In another way we can say that we want to design software so that each module addresses a specific sub function of requirements and has a simple interface when viewed from other parts of the program structure.

Functional independence is achieved by developing modules with single-minded function and with a dislike to excessive interaction with other modules.

In another way we can say that we want to design software so that each module addresses a specific sub function of requirements and has a simple interface when viewed from other parts of the program structure.

19

Functional Independence

Independence is assessed using two qualitative criteria: cohesion and coupling.Cohesion is a natural extension of the information hiding concept, wherein cohesive module performs a single task, requiring little interaction with other components in other parts of the program.Coupling is an indication of interconnection among modules in a software structure.Coupling depends on the interface complexity between modules, the point at which entry or reference is made of a module, and what data pass across the interface.

In software design, we strive for lowest possible coupling.

Independence is assessed using two qualitative criteria: cohesion and coupling.Cohesion is a natural extension of the information hiding concept, wherein cohesive module performs a single task, requiring little interaction with other components in other parts of the program.Coupling is an indication of interconnection among modules in a software structure.Coupling depends on the interface complexity between modules, the point at which entry or reference is made of a module, and what data pass across the interface.

In software design, we strive for lowest possible coupling.20

Functional Independence contd…

Functional IndependenceFunctional Independence

21

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.

Refinement is actually a process of elaboration. Refinement is actually a process of elaboration.

Statement describes function or information conceptually but Statement describes function or information conceptually but provides no information about the internal workings of the provides no information about the internal workings of the function or the internal structure of the data.function or the internal structure of the data.

Refinement causes the designer to elaborate on the original Refinement causes the designer to elaborate on the original statement, providing more and more detail as each successive statement, providing more and more detail as each successive refinement (elaboration) occurs.refinement (elaboration) occurs.

Abstraction and refinement are complementary concepts. Abstraction and refinement are complementary concepts. Abstraction enables a designer to specify procedure and data Abstraction enables a designer to specify procedure and data and yet suppress low-level details. Refinement helps the and yet suppress low-level details. Refinement helps the designer to reveal low-level details as design progresses.designer to reveal low-level details as design progresses.

Refinement is actually a process of elaboration. Refinement is actually a process of elaboration.

Statement describes function or information conceptually but Statement describes function or information conceptually but provides no information about the internal workings of the provides no information about the internal workings of the function or the internal structure of the data.function or the internal structure of the data.

Refinement causes the designer to elaborate on the original Refinement causes the designer to elaborate on the original statement, providing more and more detail as each successive statement, providing more and more detail as each successive refinement (elaboration) occurs.refinement (elaboration) occurs.

Abstraction and refinement are complementary concepts. Abstraction and refinement are complementary concepts. Abstraction enables a designer to specify procedure and data Abstraction enables a designer to specify procedure and data and yet suppress low-level details. Refinement helps the and yet suppress low-level details. Refinement helps the designer to reveal low-level details as design progresses.designer to reveal low-level details as design progresses. 22

Refinement

Stepwise RefinementStepwise Refinement

23

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

Refactoring is the process of changing a software system in Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the such a way that it does not alter the external behavior of the code (design) yet improves its internal structure.code (design) yet improves its internal structure.

When software is refactored, the existing design is examined When software is refactored, the existing design is examined for redundancy, unused design elements, inefficient or for redundancy, unused design elements, inefficient or unnecessary algorithms, poorly constructed or in appropriate unnecessary algorithms, poorly constructed or in appropriate data structure, or any other design failure that can be corrected data structure, or any other design failure that can be corrected to yield a better design.to yield a better design.

Refactoring is the process of changing a software system in Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the such a way that it does not alter the external behavior of the code (design) yet improves its internal structure.code (design) yet improves its internal structure.

When software is refactored, the existing design is examined When software is refactored, the existing design is examined for redundancy, unused design elements, inefficient or for redundancy, unused design elements, inefficient or unnecessary algorithms, poorly constructed or in appropriate unnecessary algorithms, poorly constructed or in appropriate data structure, or any other design failure that can be corrected data structure, or any other design failure that can be corrected to yield a better design.to yield a better design.

24

Refactoring

Five different types of design classes, each representing a Five different types of design classes, each representing a different layer of the design architecture are suggested.different layer of the design architecture are suggested.

User interface classes – define abstractions necessary for define abstractions necessary for Human Computer Interface.Human Computer Interface.Business domain classesBusiness domain classes – refinements of analysis classes. – refinements of analysis classes.Process classesProcess classes – lower-level business abstractions that – lower-level business abstractions that manage business domain classes.manage business domain classes.Persistent classesPersistent classes – data stores (databases) that persist beyond – data stores (databases) that persist beyond execution of the software.execution of the software.System classesSystem classes – management and control functions that – management and control functions that enable the system to operate and communicate within its enable the system to operate and communicate within its computing environment and with the outside world.computing environment and with the outside world.

Five different types of design classes, each representing a Five different types of design classes, each representing a different layer of the design architecture are suggested.different layer of the design architecture are suggested.

User interface classes – define abstractions necessary for define abstractions necessary for Human Computer Interface.Human Computer Interface.Business domain classesBusiness domain classes – refinements of analysis classes. – refinements of analysis classes.Process classesProcess classes – lower-level business abstractions that – lower-level business abstractions that manage business domain classes.manage business domain classes.Persistent classesPersistent classes – data stores (databases) that persist beyond – data stores (databases) that persist beyond execution of the software.execution of the software.System classesSystem classes – management and control functions that – management and control functions that enable the system to operate and communicate within its enable the system to operate and communicate within its computing environment and with the outside world.computing environment and with the outside world.

25

Design Classes

Following are the four characteristics of a well-formed design Following are the four characteristics of a well-formed design class: class:

1. 1. Complete and Sufficient: Complete and Sufficient: class should be complete and class should be complete and sufficient that is encapsulation of reasonable attributes and sufficient that is encapsulation of reasonable attributes and methods.methods.2. 2. Primitiveness:Primitiveness: each method should be focused on one thing. each method should be focused on one thing.3. 3. High cohesion High cohesion – class should be focused on one kind of thing. – class should be focused on one kind of thing.

4. 4. Low coupling Low coupling – should have only limited knowledge of – should have only limited knowledge of classes in other subsystems.classes in other subsystems.

Following are the four characteristics of a well-formed design Following are the four characteristics of a well-formed design class: class:

1. 1. Complete and Sufficient: Complete and Sufficient: class should be complete and class should be complete and sufficient that is encapsulation of reasonable attributes and sufficient that is encapsulation of reasonable attributes and methods.methods.2. 2. Primitiveness:Primitiveness: each method should be focused on one thing. each method should be focused on one thing.3. 3. High cohesion High cohesion – class should be focused on one kind of thing. – class should be focused on one kind of thing.

4. 4. Low coupling Low coupling – should have only limited knowledge of – should have only limited knowledge of classes in other subsystems.classes in other subsystems.

26

Guide lines for well-formed design class:

The Design ModelThe Design Model

27

process dimension

architecture elements

interface elements

component-level elements

deployment-level elements

low

high

class diagrams analysis packages CRC models collaboration diagrams

use-cases - text use-case diagrams activity diagrams swim 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 collaboration diagrams


refinements to:

deployment diagrams

class diagrams analysis packages CRC models collaboration diagrams

component diagrams design classes activity diagrams sequence diagrams

refinements to:




analysis model

design model

Requirements: constraints interoperability targets and configuration

technical interface design Navigation design GUI design

Data elements Architectural level Architectural level databases and files databases and files Component level Component level data structures & data structures & algorithmsalgorithmsArchitectural elements An architectural model is derived from: An architectural model is derived from: Application domain Application domain Analysis model Analysis model Available styles and patterns Available styles and patternsInterface elementsThere are three parts to the interface design element:There are three parts to the interface design element: The user interface (UI) The user interface (UI) Interfaces to external systems Interfaces to external systems Interfaces to components within the application Interfaces to components within the applicationComponent elementsDeployment elements

Data elements Architectural level Architectural level databases and files databases and files Component level Component level data structures & data structures & algorithmsalgorithmsArchitectural elements An architectural model is derived from: An architectural model is derived from: Application domain Application domain Analysis model Analysis model Available styles and patterns Available styles and patternsInterface elementsThere are three parts to the interface design element:There are three parts to the interface design element: The user interface (UI) The user interface (UI) Interfaces to external systems Interfaces to external systems Interfaces to components within the application Interfaces to components within the applicationComponent elementsDeployment elements

28

Design Model Elements

29

Design Model Elements

ControlPanel

LCDdisplay LEDindicators keyPadCharacteristics speaker wirelessInterface

readKeyStroke() decodeKey() displayStatus() lightLEDs() sendControlMsg()

Figure 9.6 UML interface representation for ControlPanel

KeyPad

readKeystroke() decodeKey()

<<interface>>

WirelessPDA

KeyPad

MobilePhone

Interface ElementsInterface Elements

30

ControlPanel

LCDdisplay LEDindicators keyPadCharacteristics speaker wirelessInterface

readKeyStroke() decodeKey() displayStatus() lightLEDs() sendControlMsg()

Figure 9.6 UML interface representation for ControlPanel

KeyPad

readKeystroke() decodeKey()

<<interface>>

WirelessPDA

KeyPad

MobilePhone

Component ElementsComponent Elements

31

SensorManagementSensor

Deployment DiagramDeployment Diagram

32

Technology

Software engg. pressman_ch-9