software engineering 1 unit iii: design methods and models (08 hrs) the design process, concepts of...
TRANSCRIPT
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.
Software Engineering 3
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
Software Engineering 4
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
Software Engineering 5
Data Data AbstractionAbstraction
doordoor
implemented as a data structure
manufacturermanufacturermodel numbermodel numbertypetypeswing directionswing directioninsertsinsertslightslights typetype numbernumberweightweightopening mechanismopening mechanism
Software Engineering 6
Procedural Procedural AbstractionAbstraction
openopen
implemented with a "knowledge" of the object that is associated with enter
details of enter details of enter algorithmalgorithm
Software Engineering 7
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.
Software Engineering 8
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
Software Engineering 10
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
Software Engineering 11
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
Software Engineering 12
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
Software Engineering 13
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
Software Engineering 14
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.
Software Engineering 15
Sizing Modules: Two Sizing Modules: Two ViewsViews
MODULE
What's inside??
How big is it??
Software Engineering 16
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.
Software Engineering 17
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.
Software Engineering 18
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..
Software Engineering 19
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.
Software Engineering 20
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
Software Engineering 21
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.
Software Engineering 22
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.
Software Engineering 24
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 …
Software Engineering 25
The Design ModelThe Design Model
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
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:
component diagrams design classes activity diagrams sequence diagrams
design class realizations subsystems collaboration diagrams
component diagrams design classes activity diagrams sequence diagrams
analysis model
design model
Requirements: constraints interoperability targets and configuration
technical interface design Navigation design GUI design
Software Engineering 26
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
Software Engineering 27
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
Software Engineering 29
Deployment ElementsDeployment Elements
Figure 9.8 UML deployment diagram for SafeHome
Personal computer
Security
homeManagement
Surveillance
communication
Control Panel CPI server
Security homeownerAccess
externalAccess
Software Engineering 31
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.
Software Engineering 32
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” .
Software Engineering 33
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.
Software Engineering 38
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.
Software Engineering 39
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
Software Engineering 40
Architectural ContextArchitectural Context
target system: Security Function
uses
uses peershomeowner
Safehome Product
Internet-based system
surveillance function
sensors
control panel
sensors
uses
Software Engineering 41
ArchetypesArchetypes
Figure 10.7 UML relationships for SafeHome security function archetypes (adapted from [BOS00])
Controller
Node
communicates with
Detector Indicator
Software Engineering 42
Component StructureComponent StructureSafeHome Executive
External Communication Management
GUI Internet Interface
Function selection
Security Surveillance Home management
Control panel
processing
detector management
alarm processing
Software Engineering 43
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
Software Engineering 44
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.
Software Engineering 45
An Architectural Design An Architectural Design MethodMethod
"four bedrooms, three baths,lots of glass ..."
customer requirements
architectural design
Software Engineering 46
Deriving Program Deriving Program ArchitectureArchitecture
ProgramProgramArchitectureArchitecture
Software Engineering 47
Partitioning the Partitioning the ArchitectureArchitecture
““horizontal” and “vertical” horizontal” and “vertical” partitioning are requiredpartitioning are required
Software Engineering 48
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
Software Engineering 49
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
Software Engineering 50
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
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.
Software Engineering
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
Software Engineering
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
Software Engineering
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.
Software Engineering
58
SubstitutabilitySubstitutability
Subclasses should be substitutable for base Subclasses should be substitutable for base classesclasses
Software Engineering
59
Dependency InversionDependency Inversion
Depend on Depend on abstractions. abstractions. Do not Do not depend on depend on concretions.concretions.
Software Engineering
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.
Software Engineering
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
Software Engineering
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.
Software Engineering
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.
Software Engineering
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.
Software Engineering
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
Software Engineering
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; }
….
Software Engineering
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.
Software Engineering
68
Routine CouplingRoutine Coupling
Certain types of coupling occur routinely in Certain types of coupling occur routinely in object-oriented programming.object-oriented programming.
Software Engineering
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
Software Engineering
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
Software Engineering
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
Software Engineering
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)
Software Engineering
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.
Software Engineering
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 }
Software Engineering
75
3d. Describe Processing Flow3d. Describe Processing Flow
Activity diagram Activity diagram for for computePaperCostcomputePaperCost( )( )
Software Engineering
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.
Software Engineering
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
Software Engineering
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.
Software Engineering
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.
Software Engineering
Software Engineering 80
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.
Software Engineering 81
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.
Software Engineering 82
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.
Software Engineering 84
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
Software Engineering 85
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
Software Engineering 86
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.
Software Engineering 87
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.
Software Engineering 88
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.
Software Engineering 89
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
Software Engineering 91
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.
Software Engineering 92
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?
Software Engineering 93
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.
Software Engineering 94
WebE Design PyramidWebE Design Pyramid
Interface design
Aesthetic design
Content design
Navigation design
Architecture design
Component design
user
technology
Software Engineering 95
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.
Software Engineering 96
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.
Software Engineering 97
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.
Software Engineering 98
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.”
Software Engineering 99
Design IssuesDesign Issues
Response timeResponse time Help facilitiesHelp facilities Error handlingError handling Menu and command labelingMenu and command labeling Application accessibilityApplication accessibility InternationalizationInternationalization
Software Engineering 100
Design Evaluation Design Evaluation CycleCycle
preliminarydesign
buildprototype #1
interface
evaluationis studied by
designer
designmodifications
are made
buildprototype # n
interface
userevaluate'sinterface
Interface designis complete
Software Engineering 101
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.
103Software Engineering
3. Prioritize the Design3. Prioritize the Design
104Software Engineering
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)
105Software Engineering
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
106Software Engineering
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.
107Software Engineering
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
108Software Engineering
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.
109Software Engineering
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.
110Software Engineering
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.
111Software Engineering
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”
112Software Engineering
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
113Software Engineering
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
114Software Engineering
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…
115Software Engineering
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.
116Software Engineering
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.
117Software Engineering