Software Engineering 1 Unit III: Design Methods and Models (08 Hrs) The Design Process, Concepts of design, Design Quality, Design Principles, Object-Oriented

Software Engineering 1

Unit III: Design Methods and Models (08 Hrs)

The Design Process, Concepts of design, Design Quality, Design Principles,Object-Oriented Design Concepts, Design Classes, The Design Model and elements;

Software Architecture, Importance, Architectural Styles, ArchitecturalDesign, Assessing Alternative Architectural Designs using Architectural Styles inDesigns;

Component Design, Class-Based Components, Conducting Component Level Design, Component Level Design for WebApps;

User Interface Design, The Golden Rules , User Interface Analysis and Design, Interface Analysis, Interface Design Steps, WebApp Interface Design, Design Evaluation;

Design Document, Modifiability: SAAM Method, ATAM Method, The HASARD Method.


Part I. Design Part I. Design ProcessProcess

.


Design ProcessDesign ProcessAnalysis Model -> Design ModelAnalysis Model -> Design Model

Analysis Model

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

data flow diagrams control-flow diagrams processing narratives

f low-oriented elements

behavioralelements

class-basedelements

scenario-basedelements

class diagrams analysis packages CRC models collaboration diagrams

state diagrams sequence diagrams

Data/ Class Design

Architectural Design

Interface Design

Component- Level Design

Design Model


Fundamental Fundamental ConceptsConcepts

abstractionabstraction—data, procedure, control—data, procedure, control architecturearchitecture—the overall structure of the software—the overall structure of the software patternspatterns—”conveys the essence” of a proven design solution—”conveys the essence” of a proven design solution modularitymodularity—compartmentalization of data and function—compartmentalization of data and function hidinghiding—controlled interfaces—controlled interfaces Functional independenceFunctional independence—single-minded function and low —single-minded function and low

couplingcoupling refinementrefinement—elaboration of detail for all abstractions—elaboration of detail for all abstractions RefactoringRefactoring—a reorganization technique that simplifies the —a reorganization technique that simplifies the

designdesign


Data Data AbstractionAbstraction

doordoor

implemented as a data structure

manufacturermanufacturermodel numbermodel numbertypetypeswing directionswing directioninsertsinsertslightslights typetype numbernumberweightweightopening mechanismopening mechanism


Procedural Procedural AbstractionAbstraction

openopen

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

details of enter details of enter algorithmalgorithm


ArchitectureArchitecture““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.” conceptual integrity for a system.”

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. The architectural design description The architectural design description should address how the design architecture achieves requirements should address how the design architecture achieves requirements for performance, capacity, reliability, security, adaptability, and for performance, capacity, reliability, security, adaptability, and other system characteristics.other system 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.


PatternsPatternsDesign Pattern TemplateDesign Pattern TemplatePattern namePattern name—describes the essence of the pattern in a short but —describes the essence of the pattern in a short but expressive name expressive name

IntentIntent—describes the pattern and what it does—describes the pattern and what it does

Also-known-asAlso-known-as—lists any synonyms for the pattern—lists any synonyms for the pattern

MotivationMotivation—provides an example of the problem —provides an example of the problem

ApplicabilityApplicability—notes specific design situations in which the pattern is —notes specific design situations in which the pattern is applicableapplicable

StructureStructure—describes the classes that are required to implement the —describes the classes that are required to implement the patternpattern

ParticipantsParticipants—describes the responsibilities of the classes that are —describes the responsibilities of the classes that are required to implement the patternrequired to implement the pattern

CollaborationsCollaborations—describes how the participants collaborate to carry out —describes how the participants collaborate to carry out their responsibilitiestheir responsibilities

ConsequencesConsequences—describes the “design forces” that affect the pattern and —describes the “design forces” that affect the pattern and the potential trade-offs that must be considered when the pattern is the potential trade-offs that must be considered when the pattern is implementedimplemented

Related patternsRelated patterns—cross-references related design patterns—cross-references related design patterns


Modular Modular DesignDesign


Modularity: Trade-Modularity: Trade-offsoffsWhat 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


Information HidingInformation Hiding

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


Why Information Why Information Hiding?Hiding?

reduces the likelihood of “side reduces the likelihood of “side effects”effects”

limits the global impact of local limits the global impact of local design decisionsdesign decisions

emphasizes communication through emphasizes communication through controlled interfacescontrolled interfaces

discourages the use of global datadiscourages the use of global data leads to encapsulation—an attribute leads to encapsulation—an attribute

of high quality designof high quality design results in higher quality softwareresults in higher quality software


Stepwise Stepwise RefinementRefinementopen

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


Functional Functional IndependenceIndependence

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.


Sizing Modules: Two Sizing Modules: Two ViewsViews

MODULE

What's inside??

How big is it??


RefactoringRefactoring "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.


Design and QualityDesign and Quality

the design must implement all of the explicit the design must implement all of the explicit requirementsrequirements contained in the analysis model, and contained in the analysis model, and it must accommodate all of the implicit it must accommodate all of the implicit requirements desired by the customer.requirements desired by the customer.

the design must be a readable, understandable the design must be a readable, understandable guideguide for those who generate code and for those for those who generate code and for those who test and subsequently support the software.who test and subsequently support the software.

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


Quality GuidelinesQuality Guidelines A design should exhibit an architectureA design should exhibit an architecture that (1) has been created using that (1) has been created using

recognizable architectural styles or patterns, (2) is composed of components recognizable architectural styles or patterns, (2) is composed of components that exhibit good design characteristics and (3) can be implemented in an that exhibit good design characteristics and (3) can be implemented in an evolutionary fashionevolutionary fashion

A design should be modularA design should be modular; that is, the software should be logically ; that is, the software should be logically partitioned into elements or subsystemspartitioned into elements or subsystems

A design should contain distinct representationsA design should contain distinct representations of data, architecture, of data, architecture, interfaces, and components.interfaces, and components.

A design should lead to data structures that are appropriateA design should lead to data structures that are appropriate for the classes to for the classes to be implemented and are drawn from recognizable data patterns.be implemented and are drawn from recognizable data patterns.

A design should lead to components that exhibit independent functional A design should lead to components that exhibit independent functional characteristicscharacteristics..

A design should lead to interfaces that reduce the complexityA design should lead to interfaces that reduce the complexity of connections of connections between components and with the external environment.between components and with the external environment.

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

A design should be represented using a notation that effectively communicates A design should be represented using a notation that effectively communicates its meaningits meaning..


Design Design PrinciplesPrinciples The design process should not suffer from ‘tunnel vision.’ The design process should not suffer from ‘tunnel vision.’

The design should be traceable to the analysis model. The design should be traceable to the analysis model. The design should not reinvent the wheel. The design should not reinvent the wheel. The design should “minimize the intellectual distance” between The design should “minimize the intellectual distance” between

the software and the problem as it exists in the real world. the software and the problem as it exists in the real world. The design should exhibit uniformity and integration. The design should exhibit uniformity and integration. The design should be structured to accommodate change. The design should be structured to accommodate change. The design should be structured to degrade gently, even when The design should be structured to degrade gently, even when

aberrant data, events, or operating conditions are encountered. aberrant data, events, or operating conditions are encountered. Design is not coding, coding is not design. Design is not coding, coding is not design. The design should be assessed for quality as it is being created, The design should be assessed for quality as it is being created,

not after the fact. not after the fact. The design should be reviewed to minimize conceptual The design should be reviewed to minimize conceptual

(semantic) errors.(semantic) errors.


OO Design ConceptsOO Design Concepts Design classesDesign classes

Entity classesEntity classes Boundary classesBoundary classes Controller classesController classes

InheritanceInheritance—all responsibilities of a superclass is —all responsibilities of a superclass is immediately inherited by all subclassesimmediately inherited by all subclasses

MessagesMessages—stimulate some behavior to occur in the —stimulate some behavior to occur in the receiving objectreceiving object

PolymorphismPolymorphism—a characteristic that greatly reduces —a characteristic that greatly reduces the effort required to extend the designthe effort required to extend the design


Design ClassesDesign Classes Analysis classes are refined during design to become Analysis classes are refined during design to become

entity classesentity classes Boundary classesBoundary classes are developed during design to create are developed during design to create

the interface (e.g., interactive screen or printed reports) the interface (e.g., interactive screen or printed reports) that the user sees and interacts with as the software is that the user sees and interacts with as the software is used. used.

Boundary classes are designed with the responsibility of Boundary classes are designed with the responsibility of managing the way entity objects are represented to users. managing the way entity objects are represented to users.

Controller classeController classess are designed to manage are designed to manage the creation or update of entity objects; the creation or update of entity objects; the instantiation of boundary objects as they obtain the instantiation of boundary objects as they obtain

information from entity objects; information from entity objects; complex communication between sets of objects; complex communication between sets of objects; validation of data communicated between objects or between validation of data communicated between objects or between

the user and the application.the user and the application.


InheritanceInheritance

Design options:Design options: The class can be designed and built from scratch. That is, The class can be designed and built from scratch. That is,

inheritance is not used.inheritance is not used. The class hierarchy can be searched to determine if a The class hierarchy can be searched to determine if a

class higher in the hierarchy (a superclass)contains most class higher in the hierarchy (a superclass)contains most of the required attributes and operations. The new class of the required attributes and operations. The new class inherits from the superclass and additions may then be inherits from the superclass and additions may then be added, as required.added, as required.

The class hierarchy can be restructured so that the The class hierarchy can be restructured so that the required attributes and operations can be inherited by required attributes and operations can be inherited by the new class.the new class.

Characteristics of an existing class can be overridden and Characteristics of an existing class can be overridden and different versions of attributes or operations are different versions of attributes or operations are implemented for the new class.implemented for the new class.


MessageMessagess

:SenderObject

:ReceiverObject

message (<parameters>)


PolymorphismPolymorphism

case of graphtype:case of graphtype:

if graphtype = linegraph then DrawLineGraph (data);if graphtype = linegraph then DrawLineGraph (data);

if graphtype = piechart then DrawPieChart (data);if graphtype = piechart then DrawPieChart (data);

if graphtype = histogram then DrawHisto (data);if graphtype = histogram then DrawHisto (data);

if graphtype = kiviat then DrawKiviat (data);if graphtype = kiviat then DrawKiviat (data);

end case;end case;

All of the graphs become subclasses of a general class All of the graphs become subclasses of a general class called graph. Using a concept called overloading [TAY90], called graph. Using a concept called overloading [TAY90], each subclass defines an operation called each subclass defines an operation called drawdraw. An object . An object can send a can send a drawdraw message to any one of the objects message to any one of the objects instantiated from any one of the subclasses. The object instantiated from any one of the subclasses. The object receiving the message will invoke its own receiving the message will invoke its own drawdraw operation operation to create the appropriate graph. to create the appropriate graph.

graphtype drawgraphtype draw

ConventionalConventional approach …approach …


The Design ModelThe Design Model

process dimension

architecture elements

interface elements

component-level elements

deployment-level elements

low

high


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



design class realizations subsystems collaboration diagrams


refinements to:

deployment 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


Design Model ElementsDesign Model Elements Data elementsData elements

Data model --> data structuresData model --> data structures Data model --> database architectureData model --> database architecture

Architectural elementsArchitectural elements Application domainApplication domain Analysis classes, their relationships, collaborations and behaviors Analysis classes, their relationships, collaborations and behaviors

are transformed into design realizationsare transformed into design realizations Patterns and “styles” Patterns and “styles”

Interface elementsInterface elements the user interface (UI) the user interface (UI) external interfaces to other systems, devices, networks or other external interfaces to other systems, devices, networks or other

producers or consumers of informationproducers or consumers of information internal interfaces between various design componentsinternal interfaces between various design components.

Component elementsComponent elements Deployment elementsDeployment elements


Interface ElementsInterface 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


Component ElementsComponent Elements

SensorManagementSensor


Deployment ElementsDeployment Elements

Figure 9.8 UML deployment diagram for SafeHome

Personal computer

Security

homeManagement

Surveillance

communication

Control Panel CPI server

Security homeownerAccess

externalAccess


Part II. Software Part II. Software Architecture Architecture

.


Why Architecture?Why Architecture?The architecture is not the operational software. The architecture is not the operational software. Rather, it is a representation that enables a Rather, it is a representation that enables a software engineer to: software engineer to:

(1) analyze the effectiveness of the design in (1) analyze the effectiveness of the design in meeting its stated requirements, meeting its stated requirements,

(2) consider architectural alternatives at a stage (2) consider architectural alternatives at a stage when making design changes is still relatively easy, when making design changes is still relatively easy, and and

(3) reduce the risks associated with the (3) reduce the risks associated with the construction of the software.construction of the software.


Why is Architecture Why is Architecture Important?Important?

Representations of software architecture are an enablerRepresentations of software architecture are an enabler for communication between all parties (stakeholders) for communication between all parties (stakeholders) interested in the development of a computer-based system.interested in the development of a computer-based system.

The architecture highlights early design decisionsThe architecture highlights early design decisions that will that will have a profound impact on all software engineering work have a profound impact on all software engineering work that follows and, as important, on the ultimate success of that follows and, as important, on the ultimate success of the system as an operational entity.the system as an operational entity.

Architecture “constitutes a relatively small, intellectually Architecture “constitutes a relatively small, intellectually graspable modelgraspable model of how the system is structured and how of how the system is structured and how its components work together” .its components work together” .


Architectural StylesArchitectural Styles

Data-centered architecturesData-centered architectures Data flow architecturesData flow architectures Call and return architecturesCall and return architectures Object-oriented architecturesObject-oriented architectures Layered architecturesLayered architectures

Each style describes a system category that encompasses: (1) a Each style describes a system category that encompasses: (1) a set of componentsset of components (e.g., a database, computational modules) (e.g., a database, computational modules) that perform a function required by a system, (2) a that perform a function required by a system, (2) a set of set of connectorsconnectors that enable “communication, coordination and that enable “communication, coordination and cooperation” among components, (3) cooperation” among components, (3) constraintsconstraints that define that define how components can be integrated to form the system, and (4) how components can be integrated to form the system, and (4) semantic modelssemantic models that enable a designer to understand the that enable a designer to understand the overall properties of a system by analyzing the known overall properties of a system by analyzing the known properties of its constituent parts. properties of its constituent parts.


Data-Centered ArchitectureData-Centered Architecture


Data Flow ArchitectureData Flow Architecture


Call and Return ArchitectureCall and Return Architecture


Layered ArchitectureLayered Architecture


Architectural PatternsArchitectural Patterns ConcurrencyConcurrency—applications must handle multiple tasks in a —applications must handle multiple tasks in a

manner that simulates parallelism manner that simulates parallelism operating system process managementoperating system process management patternpattern task schedulertask scheduler pattern pattern

PersistencePersistence—Data persists if it survives past the execution of —Data persists if it survives past the execution of the process that created it. Two patterns are common: the process that created it. Two patterns are common:

a a database management systemdatabase management system pattern that applies the storage and pattern that applies the storage and retrieval capability of a DBMS to the application architectureretrieval capability of a DBMS to the application architecture

an an application levelapplication level persistencepersistence pattern that builds persistence pattern that builds persistence features into the application architecturefeatures into the application architecture

DistributionDistribution— the manner in which systems or components — the manner in which systems or components within systems communicate with one another in a distributed within systems communicate with one another in a distributed environmentenvironment

AA brokerbroker acts as a ‘middle-man’ between the client component and a acts as a ‘middle-man’ between the client component and a server component.server component.


Architectural DesignArchitectural Design

The software must be placed into contextThe software must be placed into context the design should define the external entities (other the design should define the external entities (other

systems, devices, people) that the software interacts systems, devices, people) that the software interacts with and the nature of the interactionwith and the nature of the interaction

A set of architectural archetypes should be A set of architectural archetypes should be identifiedidentified AnAn archetypearchetype is an abstraction (similar to a class) that is an abstraction (similar to a class) that

represents one element of system behaviorrepresents one element of system behavior The designer specifies the structure of the The designer specifies the structure of the

system by defining and refining software system by defining and refining software components that implement each archetypecomponents that implement each archetype


Architectural ContextArchitectural Context

target system: Security Function

uses

uses peershomeowner

Safehome Product

Internet-based system

surveillance function

sensors

control panel

sensors

uses


ArchetypesArchetypes

Figure 10.7 UML relationships for SafeHome security function archetypes (adapted from [BOS00])

Controller

Node

communicates with

Detector Indicator


Component StructureComponent StructureSafeHome Executive

External Communication Management

GUI Internet Interface

Function selection

Security Surveillance Home management

Control panel

processing

detector management

alarm processing


Refined Component Refined Component StructureStructure

sensorsensorsensorsensor

sensorsensorsensor

sensor

External Communication Management

GUI Internet Interface

Security

Control

panelprocessing

detector

managementalarm

processing

Keypad processing

CP display functions

scheduler

sensorsensorsensorsensor

phone communication

alarm

SafeHome Executive


Analyzing Architectural Analyzing Architectural DesignDesign

1. Collect scenarios. 1. Collect scenarios. 2. Elicit requirements, constraints, and environment 2. Elicit requirements, constraints, and environment description. description. 3. Describe the architectural styles/patterns that have 3. Describe the architectural styles/patterns that have been chosen to address the scenarios and requirements:been chosen to address the scenarios and requirements:

• • module viewmodule view• • process viewprocess view• • data flow viewdata flow view

4. Evaluate quality attributes by considered each 4. Evaluate quality attributes by considered each attribute in isolation. attribute in isolation. 5. Identify the sensitivity of quality attributes to various 5. Identify the sensitivity of quality attributes to various architectural attributes for a specific architectural style. architectural attributes for a specific architectural style. 6. Critique candidate architectures (developed in step 3) 6. Critique candidate architectures (developed in step 3) using the sensitivity analysis conducted in step 5.using the sensitivity analysis conducted in step 5.


An Architectural Design An Architectural Design MethodMethod

"four bedrooms, three baths,lots of glass ..."

customer requirements

architectural design


Deriving Program Deriving Program ArchitectureArchitecture

ProgramProgramArchitectureArchitecture


Partitioning the Partitioning the ArchitectureArchitecture

““horizontal” and “vertical” horizontal” and “vertical” partitioning are requiredpartitioning are required


Horizontal PartitioningHorizontal Partitioning

define separate branches of the module define separate branches of the module hierarchy for each major functionhierarchy for each major function

use control modules to coordinate use control modules to coordinate communication between functionscommunication between functions

function 1function 1 function 3function 3

function 2function 2


Vertical Partitioning: FactoringVertical Partitioning: Factoring

design so that decision making and work design so that decision making and work are stratifiedare stratified

decision making modules should reside at decision making modules should reside at the top of the architecturethe top of the architecture

workersworkers

decision-makersdecision-makers


Why Partitioned Why Partitioned Architecture?Architecture?

results in software that is easier to testresults in software that is easier to test leads to software that is easier to maintainleads to software that is easier to maintain results in propagation of fewer side effectsresults in propagation of fewer side effects results in software that is easier to extendresults in software that is easier to extend


Part III: Component DesignPart III: Component Design

52

What is Component Level What is Component Level Design?Design?

A complete set of software components is A complete set of software components is defined during architectural designdefined during architectural design

But the internal data structures and But the internal data structures and processing details of each component are processing details of each component are not represented at a level of abstraction not represented at a level of abstraction that is close to codethat is close to code

Component-level design defines the data Component-level design defines the data structures, algorithms, interface structures, algorithms, interface characteristics, and communication characteristics, and communication mechanisms allocated to each componentmechanisms allocated to each component

Software Engineering

53

Component ViewsComponent Views

OO ViewOO View – A component is a set of – A component is a set of collaborating classes.collaborating classes.

Conventional ViewConventional View – A component is a – A component is a functional element of a program that functional element of a program that incorporates processing logic, the internal incorporates processing logic, the internal data structures required to implement the data structures required to implement the processing logic, and an interface that processing logic, and an interface that enables the component to be invoked and enables the component to be invoked and data to be passed to it.data to be passed to it.


54

Class ElaborationClass Elaboration


55

Design PrinciplesDesign Principles

Design by ContractDesign by Contract Open-Closed PrincipleOpen-Closed Principle Subtype SubstitutionSubtype Substitution Depend on AbstractionsDepend on Abstractions Interface SegregationInterface Segregation


56

Design by ContractDesign by Contract

The relationship between a class and its clients The relationship between a class and its clients can be viewed as a formal agreement, expressing can be viewed as a formal agreement, expressing each party’s rights and obligations.each party’s rights and obligations.

Consider the following list operation:Consider the following list operation:

publicpublic Item remove( Item remove(intint index) index) requiresrequires the specified index is in range ( 0 the specified index is in range ( 0 index < index <

size( ) )size( ) ) ensuresensures the element at the specified position in this list the element at the specified position in this list

is removed, subsequent elements are shifted to the left is removed, subsequent elements are shifted to the left ( 1 is subtracted from their indices ), and the element ( 1 is subtracted from their indices ), and the element that was removed is returnedthat was removed is returned


57

Open-Closed PrincipleOpen-Closed Principle

A module should be open for extension but A module should be open for extension but closed for modification.closed for modification.


58

SubstitutabilitySubstitutability

Subclasses should be substitutable for base Subclasses should be substitutable for base classesclasses


59

Dependency InversionDependency Inversion

Depend on Depend on abstractions. abstractions. Do not Do not depend on depend on concretions.concretions.


60

Interface SegregationInterface Segregation

Many client-specific interfaces are better than Many client-specific interfaces are better than one general purpose interface.one general purpose interface.


61

CohesionCohesion

The The “single-mindedness”“single-mindedness” of a module of a module cohesion implies that a single component cohesion implies that a single component

or class encapsulates only attributes and or class encapsulates only attributes and operations that are closely related to one operations that are closely related to one another and to the class or component another and to the class or component itself.itself.

Examples of cohesionExamples of cohesion FunctionalFunctional LayerLayer CommunicationalCommunicational


62

Functional CohesionFunctional Cohesion

Typically applies to operations. Occurs when a Typically applies to operations. Occurs when a module performs one and only one computation module performs one and only one computation and then returns a result.and then returns a result.


63

Layer CohesionLayer Cohesion

Applies to packages, Applies to packages, components, and components, and classes. Occurs when classes. Occurs when a higher layer can a higher layer can access a lower layer, access a lower layer, but lower layers do but lower layers do not access higher not access higher layers.layers.


64

Communicational CohesionCommunicational Cohesion

All operations that access the same data All operations that access the same data are defined within one class.are defined within one class.

In general, such classes focus solely on In general, such classes focus solely on the data in question, accessing and the data in question, accessing and storing it.storing it.

ExampleExample: A StudentRecord class that : A StudentRecord class that adds, removes, updates, and accesses adds, removes, updates, and accesses various fields of a student record for various fields of a student record for client components.client components.


65

CouplingCoupling

A qualitative measure of the degree to which classes A qualitative measure of the degree to which classes or components are connected to each other.or components are connected to each other.

AvoidAvoid Content couplingContent coupling

Use cautionUse caution Common couplingCommon coupling

Be awareBe aware Routine call couplingRoutine call coupling Type use couplingType use coupling Inclusion or import couplingInclusion or import coupling


66

Content CouplingContent Coupling

Occurs when one Occurs when one component component “surreptitiously modifies “surreptitiously modifies data that is internal to data that is internal to another component”another component”

Violates information Violates information hidinghiding

What’s wrong here? What’s wrong here?

public class StudentRecord {

private String name; private int[ ] quizScores;

public String getName() { return name; } public int getQuizScore(int n) { return quizScores[n]; } public int[ ] getAllQuizScores() { return quizScores; }

….

public class StudentRecord {

private String name; private int[ ] quizScores;

public String getName() { return name; } public int getQuizScore(int n) { return quizScores[n]; } public int[ ] getAllQuizScores() { return quizScores; }

….


67

Common CouplingCommon Coupling

Occurs when a number of components all make Occurs when a number of components all make use of a global variable.use of a global variable.


68

Routine CouplingRoutine Coupling

Certain types of coupling occur routinely in Certain types of coupling occur routinely in object-oriented programming.object-oriented programming.


69

Conducting Component-Level Conducting Component-Level DesignDesign

1.1. Identify design classes in problem domainIdentify design classes in problem domain

2.2. Identify infrastructure design classesIdentify infrastructure design classes

3.3. Elaborate design classesElaborate design classes

4.4. Describe persistent data sourcesDescribe persistent data sources

5.5. Elaborate behavioral representationsElaborate behavioral representations

6.6. Elaborate deployment diagramsElaborate deployment diagrams

7.7. Refactor design and consider alternativesRefactor design and consider alternatives


70

Steps 1 & 2 Steps 1 & 2 –– Identify Classes Identify Classes

1.1. Most classes from the Most classes from the problem domainproblem domain are are analysis classes created as part of the analysis analysis classes created as part of the analysis modelmodel

2.2. TheThe infrastructure infrastructure design classes are design classes are introduced as components during architectural introduced as components during architectural designdesign


71

Step 3 Step 3 –– Class Elaboration Class Elaboration

a)a) Specify message details when classes or Specify message details when classes or components collaboratecomponents collaborate

b)b) Identify appropriate interfaces for each Identify appropriate interfaces for each componentcomponent

c)c) Elaborate attributes and define data structures Elaborate attributes and define data structures required to implement themrequired to implement them

d)d) Describe processing flow within each operation Describe processing flow within each operation in detailin detail


72

3a. Collaboration Details3a. Collaboration Details

Messages can be elaborated by expanding their Messages can be elaborated by expanding their syntax in the following manner:syntax in the following manner: [guard condition] sequence expression (return value) :=[guard condition] sequence expression (return value) :=

message name (argument list)message name (argument list)


73

3b. Appropriate Interfaces3b. Appropriate Interfaces

Pressman argues that the PrintJob interface Pressman argues that the PrintJob interface “initiateJob” in slide 5 does not exhibit sufficient “initiateJob” in slide 5 does not exhibit sufficient cohesion because it performs three different cohesion because it performs three different subfunctions. He suggests this refactoring. subfunctions. He suggests this refactoring.


74

3c. Elaborate Attributes3c. Elaborate Attributes

Analysis classes will typically only list names of Analysis classes will typically only list names of general attributes (ex. paperType).general attributes (ex. paperType).

List all attributes during component design.List all attributes during component design. UML syntax:UML syntax:

name : type-expression = initial-value { property string }name : type-expression = initial-value { property string } For example, paperType can be broken into For example, paperType can be broken into

weight, size, and color. The weight attribute weight, size, and color. The weight attribute would be:would be: paperType-weight: string =paperType-weight: string =

““A” { contains 1 of 4 values – A, B, C, or D }A” { contains 1 of 4 values – A, B, C, or D }


75

3d. Describe Processing Flow3d. Describe Processing Flow

Activity diagram Activity diagram for for computePaperCostcomputePaperCost( )( )


76

Step 4 Step 4 –– Persistent Data Persistent Data

Describe persistent Describe persistent data sources data sources (databases and (databases and files) and identify files) and identify the classes the classes required to required to manage them.manage them.


77

Step 5 Step 5 –– Elaborate Behavior Elaborate Behavior

It is sometimes It is sometimes necessary to model necessary to model the behavior of a the behavior of a design class.design class.

Transitions from Transitions from state to state have state to state have the form:the form: Event-name Event-name

(parameter-list) (parameter-list) [guard-condition] / [guard-condition] / action expressionaction expression


78

Step 6 Step 6 –– Elab. Deployment Elab. Deployment

Deployment diagrams are elaborated to Deployment diagrams are elaborated to represent the location of key packages or represent the location of key packages or components.components.


79

Step 7 Step 7 –– Redesign/Reconsider Redesign/Reconsider The first component-level model you The first component-level model you

create will not be as complete, consistent, create will not be as complete, consistent, or accurate as the nor accurate as the nthth iteration you apply iteration you apply to the model.to the model.

The best designers will consider many The best designers will consider many alternative design solutions before alternative design solutions before settling on the final design model.settling on the final design model.



Component Design for Component Design for WebAppsWebApps WebApp component is WebApp component is

(1) a well-defined cohesive function that manipulates (1) a well-defined cohesive function that manipulates content or provides computational or data processing content or provides computational or data processing for an end-user, or for an end-user, or

(2) a cohesive package of content and functionality that (2) a cohesive package of content and functionality that provides end-user with some required capability. provides end-user with some required capability.

Therefore, component-level design for WebApps Therefore, component-level design for WebApps often incorporates elements of content design often incorporates elements of content design and functional design.and functional design.


Content Design for Content Design for WebAppsWebApps focuses on content objects and the manner in which they focuses on content objects and the manner in which they

may be packaged for presentation to a WebApp end-usermay be packaged for presentation to a WebApp end-user consider a Web-based video surveillance capability within consider a Web-based video surveillance capability within

SafeHomeAssured.comSafeHomeAssured.com potential content components can be defined for the video potential content components can be defined for the video

surveillance capability: surveillance capability: (1) the content objects that represent the space layout (the floor (1) the content objects that represent the space layout (the floor

plan) with additional icons representing the location of sensors plan) with additional icons representing the location of sensors and video cameras; and video cameras;

(2) the collection of thumbnail video captures (each an separate (2) the collection of thumbnail video captures (each an separate data object), and data object), and

(3) the streaming video window for a specific camera. (3) the streaming video window for a specific camera. Each of these components can be separately named and Each of these components can be separately named and

manipulated as a package.manipulated as a package.


Functional Design for Functional Design for WebAppsWebApps

Modern Web applications deliver increasingly Modern Web applications deliver increasingly sophisticated processing functions that: sophisticated processing functions that: (1) perform localized processing to generate content and (1) perform localized processing to generate content and

navigation capability in a dynamic fashion; navigation capability in a dynamic fashion; (2) provide computation or data processing capability that is (2) provide computation or data processing capability that is

appropriate for the WebApp’s business domain; appropriate for the WebApp’s business domain; (3) provide sophisticated database query and access, or (3) provide sophisticated database query and access, or (4) establish data interfaces with external corporate systems. (4) establish data interfaces with external corporate systems.

To achieve these (and many other) capabilities, you will To achieve these (and many other) capabilities, you will design and construct WebApp functional components that design and construct WebApp functional components that are identical in form to software components for are identical in form to software components for conventional software. conventional software.


Part IV. User Interface Part IV. User Interface DesignDesign


Interface DesignInterface Design

Easy to use?Easy to use?

Easy to understand?Easy to understand?

Easy to learn?Easy to learn?

Typical Design ErrorsTypical Design Errors

lack of consistencylack of consistencytoo much memorizationtoo much memorizationno guidance / helpno guidance / helpno context sensitivityno context sensitivitypoor responsepoor responseunfriendlyunfriendly


Golden RulesGolden Rules

Place the user in controlPlace the user in control Reduce the user’s memory loadReduce the user’s memory load Make the interface consistentMake the interface consistent


Place the User in ControlPlace the User in ControlDefine interaction modes in a way that does not force Define interaction modes in a way that does not force a user into unnecessary or undesired actions. a user into unnecessary or undesired actions.

Provide for flexible interaction. Provide for flexible interaction.

Allow user interaction to be interruptible and Allow user interaction to be interruptible and undoable. undoable.

Streamline interaction as skill levels advance and Streamline interaction as skill levels advance and allow the interaction to be customized. allow the interaction to be customized.

Hide technical internals from the casual user. Hide technical internals from the casual user.

Design for direct interaction with objects that appear Design for direct interaction with objects that appear on the screen.on the screen.


Reduce the User’s Memory LoadReduce the User’s Memory Load

Reduce demand on short-term memory. Reduce demand on short-term memory.

Establish meaningful defaults. Establish meaningful defaults.

Define shortcuts that are intuitive. Define shortcuts that are intuitive.

The visual layout of the interface should be based on The visual layout of the interface should be based on a real world metaphor. a real world metaphor.

Disclose information in a progressive fashion.Disclose information in a progressive fashion.


Make the Interface Make the Interface ConsistentConsistent

Allow the user to put the current task into a Allow the user to put the current task into a meaningful context. meaningful context.

Maintain consistency across a family of Maintain consistency across a family of applications. applications.

If past interactive models have created user If past interactive models have created user expectations, do not make changes unless there is expectations, do not make changes unless there is a compelling reason to do so. a compelling reason to do so.


User Interface Design ModelsUser Interface Design Models

User modelUser model — a profile of all end users of — a profile of all end users of the systemthe system

Design modelDesign model — a design realization of the — a design realization of the user modeluser model

Mental model (system perception)Mental model (system perception) — the — the user’s mental image of what the interface isuser’s mental image of what the interface is

Implementation modelImplementation model — the interface — the interface “look and feel” coupled with supporting “look and feel” coupled with supporting information that describe interface syntax information that describe interface syntax and semanticsand semantics


User Interface Design ProcessUser Interface Design Process


Interface AnalysisInterface Analysis

Interface analysis means understanding Interface analysis means understanding (1) the people (end-users) who will interact (1) the people (end-users) who will interact

with the system through the interface;with the system through the interface; (2) the tasks that end-users must perform to (2) the tasks that end-users must perform to

do their work, do their work, (3) the content that is presented as part of the (3) the content that is presented as part of the

interfaceinterface (4) the environment in which these tasks will (4) the environment in which these tasks will

be conductedbe conducted.


Analysis of Display ContentAnalysis of Display Content Are different types of data assigned to consistent geographic Are different types of data assigned to consistent geographic

locations on the screen (e.g., photos always appear in the upper locations on the screen (e.g., photos always appear in the upper right hand corner)?right hand corner)?

Can the user customize the screen location for content?Can the user customize the screen location for content? Is proper on-screen identification assigned to all content? Is proper on-screen identification assigned to all content? If a large report is to be presented, how should it be partitioned If a large report is to be presented, how should it be partitioned

for ease of understanding?for ease of understanding? Will mechanisms be available for moving directly to summary Will mechanisms be available for moving directly to summary

information for large collections of data.information for large collections of data. Will graphical output be scaled to fit within the bounds of the Will graphical output be scaled to fit within the bounds of the

display device that is used?display device that is used? How will color to be used to enhance understanding?How will color to be used to enhance understanding? How will error messages and warning be presented to the user?How will error messages and warning be presented to the user?


Interface Design StepsInterface Design Steps

Using information developed during interface Using information developed during interface analysis, analysis, define interface objects and actions define interface objects and actions (operations).(operations).

Define events (user actions)Define events (user actions) that will cause the state that will cause the state of the user interface to change. Model this behavior.of the user interface to change. Model this behavior.

Describe each interface stateDescribe each interface state as it will actually look as it will actually look to the end-user.to the end-user.

Indicate how the user interprets the state of the Indicate how the user interprets the state of the systemsystem from information provided through the from information provided through the interface.interface.


WebE Design PyramidWebE Design Pyramid

Interface design

Aesthetic design

Content design

Navigation design

Architecture design

Component design

user

technology


WebApp Interface DesignWebApp Interface Design

Where am I?Where am I? The interface should The interface should provide an indication of the WebApp that has been accessed provide an indication of the WebApp that has been accessed inform the user of her location in the content hierarchy.inform the user of her location in the content hierarchy.

What can I do now?What can I do now? The interface should always help the user The interface should always help the user understand his current optionsunderstand his current options

what functions are available?what functions are available? what links are live?what links are live? what content is relevant?what content is relevant?

Where have I been, where am I going?Where have I been, where am I going? The interface must The interface must facilitate navigation. facilitate navigation.

Provide a “map” (implemented in a way that is easy to understand) of Provide a “map” (implemented in a way that is easy to understand) of where the user has been and what paths may be taken to move where the user has been and what paths may be taken to move elsewhere within the WebApp.elsewhere within the WebApp.


Interface Design Principles-IInterface Design Principles-I

AnticipationAnticipation—A WebApp should be designed so that it anticipates —A WebApp should be designed so that it anticipates the use’s next move. the use’s next move.

CommunicationCommunication—The interface should communicate the status of —The interface should communicate the status of any activity initiated by the userany activity initiated by the user

ConsistencyConsistency—The use of navigation controls, menus, icons, and —The use of navigation controls, menus, icons, and aesthetics (e.g., color, shape, layout)aesthetics (e.g., color, shape, layout)

Controlled autonomyControlled autonomy—The interface should facilitate user —The interface should facilitate user movement throughout the WebApp, but it should do so in a movement throughout the WebApp, but it should do so in a manner that enforces navigation conventions that have been manner that enforces navigation conventions that have been established for the application.established for the application.

EfficiencyEfficiency—The design of the WebApp and its interface should —The design of the WebApp and its interface should optimize the user’s work efficiency, not the efficiency of the Web optimize the user’s work efficiency, not the efficiency of the Web engineer who designs and builds it or the client-server engineer who designs and builds it or the client-server environment that executes it.environment that executes it.


Interface Design Principles-IIInterface Design Principles-II

FocusFocus—The WebApp interface (and the content it presents) should stay —The WebApp interface (and the content it presents) should stay focused on the user task(s) at hand. focused on the user task(s) at hand.

Fitt’s LawFitt’s Law—“The time to acquire a target is a function of the distance to —“The time to acquire a target is a function of the distance to and size of the target.”and size of the target.”

Human interface objectsHuman interface objects—A vast library of reusable human interface —A vast library of reusable human interface objects has been developed for WebApps.objects has been developed for WebApps.

Latency reductionLatency reduction—The WebApp should use multi-tasking in a way that —The WebApp should use multi-tasking in a way that lets the user proceed with work as if the operation has been completed. lets the user proceed with work as if the operation has been completed.

LearnabilityLearnability— A WebApp interface should be designed to minimize — A WebApp interface should be designed to minimize learning time, and once learned, to minimize relearning required when learning time, and once learned, to minimize relearning required when the WebApp is revisited. the WebApp is revisited.


Interface Design Principles-Interface Design Principles-IIIIII Maintain work product integrityMaintain work product integrity—A work product (e.g., a form completed —A work product (e.g., a form completed

by the user, a user specified list) must be automatically saved so that it by the user, a user specified list) must be automatically saved so that it will not be lost if an error occurs.will not be lost if an error occurs.

ReadabilityReadability—All information presented through the interface should be —All information presented through the interface should be readable by young and old.readable by young and old.

Track stateTrack state—When appropriate, the state of the user interaction should be —When appropriate, the state of the user interaction should be tracked and stored so that a user can logoff and return later to pick up tracked and stored so that a user can logoff and return later to pick up where she left off.where she left off.

Visible navigationVisible navigation—A well-designed WebApp interface provides “the —A well-designed WebApp interface provides “the illusion that users are in the same place, with the work brought to them.”illusion that users are in the same place, with the work brought to them.”


Design IssuesDesign Issues

Response timeResponse time Help facilitiesHelp facilities Error handlingError handling Menu and command labelingMenu and command labeling Application accessibilityApplication accessibility InternationalizationInternationalization


Design Evaluation Design Evaluation CycleCycle

preliminarydesign

buildprototype #1

interface

evaluationis studied by

designer

designmodifications

are made

buildprototype # n

interface

userevaluate'sinterface

Interface designis complete


Part V. Design Document and Part V. Design Document and EvaluationEvaluation

Goals of Good DocsGoals of Good Docs

Capture design consensusPrimary vision conduit between departmentsAid in schedulingOffer focusGive visibility to future dependencies and design conflicts

102Software Engineering

Why is good design documentation Why is good design documentation so rare?so rare?

Design docs for most system deal with Design docs for most system deal with complex, interconnected systems.complex, interconnected systems.

Designers tend to overdesign.Designers tend to overdesign. Systems take less time to design than to build.Systems take less time to design than to build. ““Big Book of Stupid”Big Book of Stupid”

Most design docs don’t embrace iteration.Most design docs don’t embrace iteration. Most docs are rarely kept up to date as the Most docs are rarely kept up to date as the

project progresses.project progresses.


3. Prioritize the Design3. Prioritize the Design


4. Illustrate4. Illustrate

5. Don’t tell others How5. Don’t tell others Howto do their jobsto do their jobs

6. Use user stories6. Use user stories

7. Separate Code from Content7. Separate Code from Content

8. Invest in a good Format8. Invest in a good Format

9. Use Clear Terminology9. Use Clear Terminology

10. Kill Redundancy10. Kill Redundancy

11. No Weak language11. No Weak language

12. Capture your Reasoning12. Capture your Reasoning

What’s ArchitectureWhat’s Architecture

“the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution”. (IEEE 1471)


Software ArchitectureSoftware Architecture

Architecture is importantArchitecture is important it should be analyzedit should be analyzed

Architecture can be prescribedArchitecture can be prescribed decisions should be analyzeddecisions should be analyzed

Architecture is central for communicating Architecture is central for communicating it should be documentedit should be documented

Architecture is expensive to changeArchitecture is expensive to change it is cheaper to analyze earlyit is cheaper to analyze early

Architecture affects the entire projectArchitecture affects the entire project many stakeholders should be involvedmany stakeholders should be involved

Requirements can be understood earlyRequirements can be understood early architecture should be designed to meet themarchitecture should be designed to meet them


Why Evaluate an Architecture? Why Evaluate an Architecture?

The cost to fix an error found during The cost to fix an error found during requirements or early design phases is requirements or early design phases is orders of magnitudes less to correct than orders of magnitudes less to correct than error found in testing.error found in testing.

Architecture determines the structure of Architecture determines the structure of the project: schedules and budgets, the project: schedules and budgets, performance goals, team structure, performance goals, team structure, documentation organization, and testing documentation organization, and testing and maintenance activities.and maintenance activities.


How to validate a software How to validate a software architecture?architecture?

A suite of three methods, all developed at the A suite of three methods, all developed at the Software Engineering Institute.Software Engineering Institute. ATAM: Architecture Tradeoff Analysis Method ATAM: Architecture Tradeoff Analysis Method SAAM: Software Architecture Analysis Method SAAM: Software Architecture Analysis Method ARID: Active Reviews for Intermediate Designs ARID: Active Reviews for Intermediate Designs


Software Architecture Analysis Software Architecture Analysis Method (SAAM)Method (SAAM)

aims to predict the quality of a system aims to predict the quality of a system before it has been developed.before it has been developed.

the quality of the architecture is validated the quality of the architecture is validated by analyzing the impact of predefined by analyzing the impact of predefined scenarios on architectural components.scenarios on architectural components.

addresses concerns at the architecture addresses concerns at the architecture design level which inherently crosscut design level which inherently crosscut multiple architectural components.multiple architectural components.


Active Reviews for Active Reviews for Intermediate Designs (ARID)Intermediate Designs (ARID)

method for reviewing preliminary software method for reviewing preliminary software designs (such as for a component or a designs (such as for a component or a subsystem) for suitability in its intended usage subsystem) for suitability in its intended usage context and environment. context and environment.

result in a high-fidelity design review coupled result in a high-fidelity design review coupled with high-quality familiarization with the design.with high-quality familiarization with the design.


ATAM - VocabularyATAM - Vocabulary

ScenarioScenario – A scenario is a short statement describing – A scenario is a short statement describing an interaction of one of the stakeholders with the an interaction of one of the stakeholders with the system system

StakeholderStakeholder – An individual, team, or organization (or – An individual, team, or organization (or classes thereof) with interests in, or concerns relative classes thereof) with interests in, or concerns relative to, a systemto, a system

Architectural viewArchitectural view – A representation of a whole system – A representation of a whole system from the perspective of a related set of concerns from the perspective of a related set of concerns

Functional requirementsFunctional requirements - specify what software has to - specify what software has to do. do.

Non-functional requirementsNon-functional requirements specify how well it should specify how well it should be done.be done.


What’s ATAMWhat’s ATAM

Purpose: To assess the consequences of Purpose: To assess the consequences of architectural decisions in light of quality architectural decisions in light of quality attribute* requirements.attribute* requirements.

Primarily a risk identification mechanismPrimarily a risk identification mechanism Not a predictor of quality achievementNot a predictor of quality achievement

*Quality attribute = “ilities”*Quality attribute = “ilities”


System Quality AttributeSystem Quality Attribute

PerformancePerformance AvailabilityAvailability UsabilityUsability SecuritySecurity

MaintainabilityMaintainability

PortabilityPortability

ReusabilityReusability

TestabilityTestability

End User’s view

Developer’s view

Time To MarketTime To MarketCost and BenefitsCost and BenefitsProjected life timeProjected life timeTargeted MarketTargeted MarketIntegration with Integration with Legacy SystemLegacy SystemRoll back Roll back ScheduleSchedule

BusinessCommunityview


ATAM – Cost/BenefitATAM – Cost/Benefit

CostCost 1 – 2 weeks of time for 8 – 10 highly paid people, 2 days for 1 – 2 weeks of time for 8 – 10 highly paid people, 2 days for

another 10-12 people (for full formal process!)another 10-12 people (for full formal process!) Delays project startDelays project start Forces development of architecture up frontForces development of architecture up front

BenefitBenefit Financial – saves moneyFinancial – saves money Forces preparation / documentation / understandingForces preparation / documentation / understanding Captures rationaleCaptures rationale Catch architectural errors before builtCatch architectural errors before built Make sure architecture meets scenariosMake sure architecture meets scenarios More general, flexible architectureMore general, flexible architecture Reduces riskReduces risk


ATAM StepsATAM Steps Phase 1 – evaluators and decision makers Phase 1 – evaluators and decision makers

Present Present ATAMATAM Business driversBusiness drivers ArchitectureArchitecture

Identify architectural approachesIdentify architectural approaches Generate quality attribute utility treeGenerate quality attribute utility tree Analyze architectural approachesAnalyze architectural approaches

Phase 2 – add stakeholders Phase 2 – add stakeholders Brainstorm and prioritize scenariosBrainstorm and prioritize scenarios Analyze architectural approachesAnalyze architectural approaches Present resultsPresent results

Phase 3Phase 3 Analyze cost / benefit of ATAMAnalyze cost / benefit of ATAM

Repeat the last steps of phase 1 In a broader forum…


HASARD MethodHASARD Method HASARD – Hazard Analysis of Software ARchitectural Designs

This method is based on a kind of system analysis techniques, which is widely used in analyzing safety related systems in various industry sectors.

This method is intended to find out how well a software architectural design meets quality requirements specified in the form of scenarios.

A common weakness of the previous methods is that they have limited power to discover unknown problems that are not elicited and explicitly specified by quality requirements. HASARD method helps to overcome this problem.


HASARD StepsHASARD StepsWhat – if checklistWhat – if checklist A review team is selected;

The review team methodically examines the process from elicitation of requirements to delivery of products, at each step the group collectively generates the list of what – if questions regarding the safety and quality of design;

Answers are developed for each question. The review team then works to achieve a consensus on each question and answer. From these answers, a listing of recommendations, along with the list of questions and answers, become the key elements of the report;

The same list is to be taken care by design team during design process.


Documents

Software Engineering 1 Unit III: Design Methods and Models (08 Hrs) The Design Process, Concepts of design, Design Quality, Design Principles, Object-Oriented