View
10
Download
0
Category
Preview:
Citation preview
Software Engineering: A Practitioner’s Approach, 6/eSoftware Engineering: A Practitioner’s Approach, 6/e
Chapter 10Chapter 10Architectural DesignArchitectural Design
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 1
copyright © 1996, 2001, 2005
R.S. Pressman & Associates, Inc.
For University Use OnlyMay be reproduced ONLY for student use at the university level
when used in conjunction with Software Engineering: A Practitioner's Approach.Any other reproduction or use is expressly prohibited.
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,
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 2
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 when making design changes is still relatively easy, and easy, 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 for communication between all parties (stakeholders) interested in the communication between all parties (stakeholders) interested in the development of a computerdevelopment of a computer--based system.based system.
�� The architecture highlights early design decisionsThe architecture highlights early design decisions that will have a that will have a
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 3
The architecture highlights early design decisionsThe architecture highlights early design decisions that will have a that will have a profound impact on all software engineering work that follows and, profound impact on all software engineering work that follows and, as important, on the ultimate success of the system as an as important, on the ultimate success of the system as an operational entity.operational entity.
�� Architecture “constitutes a relatively small, intellectually graspable Architecture “constitutes a relatively small, intellectually graspable modelmodel of how the system is structured and how its components work of how the system is structured and how its components work together” [BAS03].together” [BAS03].
Data DesignData Design
�� At the architectural level …At the architectural level …
�� Design of one or more databases to support the Design of one or more databases to support the application architectureapplication architecture
�� Design of methods for ‘Design of methods for ‘miningmining’ the content of multiple ’ the content of multiple
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 4
�� Design of methods for ‘Design of methods for ‘miningmining’ the content of multiple ’ the content of multiple databasesdatabases
�� navigate through existing databases in an attempt to navigate through existing databases in an attempt to
extract appropriate businessextract appropriate business--level informationlevel information
�� Design of a Design of a data warehousedata warehouse——a large, independent a large, independent
database that has access to the data that are stored in database that has access to the data that are stored in
databases that serve the set of applications required by databases that serve the set of applications required by
a businessa business
Data DesignData Design
�� At the component level …At the component level …
�� refine data objects and develop a set of data refine data objects and develop a set of data abstractionsabstractions
�� implement data object attributes as one or more implement data object attributes as one or more
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 5
data structuresdata structures
�� review data structures to ensure that appropriate review data structures to ensure that appropriate relationships have been establishedrelationships have been established
�� simplify data structures as requiredsimplify data structures as required
Data DesignData Design——Component LevelComponent Level1. The systematic analysis principles applied to function and 1. The systematic analysis principles applied to function and
behavior should also be applied to data. behavior should also be applied to data. 2. All data structures and the operations to be performed on each 2. All data structures and the operations to be performed on each
should be identified. should be identified.
3. A data dictionary should be established and used to define both 3. A data dictionary should be established and used to define both data and program design. data and program design.
4. Low level data design decisions should be deferred until late in 4. Low level data design decisions should be deferred until late in the design process. the design process.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 6
the design process. the design process. 5. The representation of data structure should be known only to 5. The representation of data structure should be known only to
those modules that must make direct use of the data contained those modules that must make direct use of the data contained
within the structure. within the structure. 6. A library of useful data structures and the operations that may be 6. A library of useful data structures and the operations that may be
applied to them should be developed. applied to them should be developed.
7. A software design and programming language should support 7. A software design and programming language should support
the specification and realization of abstract data types.the specification and realization of abstract data types.
Architectural StylesArchitectural Styles
Each style describes a system category that encompasses: (1) a Each style describes a system category that encompasses: (1) a set of set of componentscomponents (e.g., a database, computational modules) that perform a (e.g., a database, computational modules) that perform a function required by a system, (2) a function required by a system, (2) a set of connectorsset of connectors that enable that enable “communication, coordination and cooperation” among components, “communication, coordination and cooperation” among components, (3) (3) constraintsconstraints that define how components can be integrated to form that define how components can be integrated to form the system, and (4) the system, and (4) semantic modelssemantic models that enable a designer to that enable a designer to understand the overall properties of a system by analyzing the known understand the overall properties of a system by analyzing the known properties of its constituent parts. properties of its constituent parts.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 7
�� DataData--centered architecturescentered architectures
�� Data flow architecturesData flow architectures
�� Call and return architecturesCall and return architectures
�� ObjectObject--oriented architecturesoriented architectures
�� Layered architecturesLayered architectures
DataData--Centered ArchitectureCentered Architecture
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 8
Data Flow ArchitectureData Flow Architecture
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 9
Call and Return ArchitectureCall and Return Architecture
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 10
Layered ArchitectureLayered Architecture
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 11
Architectural PatternsArchitectural Patterns
�� Concurrency Concurrency —— applications must handle multiple tasks in a applications must handle multiple tasks in a manner that enables parallelism manner that enables parallelism �� operating system process managementoperating system process management patternpattern
�� task schedulertask scheduler patternpattern
�� Persistence Persistence —— 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
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 12
�� 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
�� Distribution Distribution —— 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 ‘middleacts as a ‘middle--man’ between the client component and a 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 systems, the design should define the external entities (other systems, devices, people) that the software interacts with and the nature devices, people) that the software interacts with and the nature of the interactionof the interaction
�� A set of architectural archetypes should be identifiedA set of architectural archetypes should be identified
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 13
�� A set of architectural archetypes should be identifiedA set of architectural archetypes should be identified
�� 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 system by The designer specifies the structure of the system by defining and refining software components that defining and refining software components that implement each archetypeimplement each archetype
Architectural ContextArchitectural Context
target system:
Safehome
ProductInternet-based
system
surveillance
control
panel
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 14
target system:
Security Functionuses
uses peershomeowner
surveillance
function
sensors
panel
sensors
uses
ArchetypesArchetypesCont roller
Node
communicates with
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 15
Figure 10.7 UML relat ionships for SafeHome securit y funct ion archetypes
(adapted f rom [BOS00] )
Detector Indicator
Component StructureComponent Structure
SafeHome
Execut ive
Ext ernal
Communicat ion
Funct ion
select ion
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 16
Management
GUI Int ernet
Int erface
Securit y Surveillance Home
management
Cont rol
panel
processing
det ect or
management
alarm
processing
Refined Component StructureRefined Component Structure
Ext ernal
Communicat ion
Management
Security
SafeHome
Execut ive
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 17
sensorsensor
sensorsensor
sensorsensorsensor
sensor
GUI Internet
Interface
Cont rol
panel
processing
det ect or
m anagem ent
alarm
processing
Key pad
p rocessing
CP d isplay
funct ions
schedu ler
sensorsensorsensorsensor
phone
com m unicat ion
alarm
Analyzing Architectural DesignAnalyzing Architectural Design
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 been 3. Describe the architectural styles/patterns that have been chosen to address the scenarios and requirements:chosen to address the scenarios and requirements:
• module view• module view• process view• process view
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 18
• process view• process view• data flow view• data flow view
4. Evaluate quality attributes by considered each attribute 4. Evaluate quality attributes by considered each attribute in isolation. 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 MethodAn Architectural Design Method
"four bedrooms, three baths,lots of glass ..."
customer requirements
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 19
architectural design
Deriving Program ArchitectureDeriving Program Architecture
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 20
ProgramProgramArchitectureArchitecture
Partitioning the ArchitecturePartitioning the Architecture
�� “horizontal” and “vertical” partitioning are “horizontal” and “vertical” partitioning are requiredrequired
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 21
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
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 22
function 1function 1 function 3function 3
function 2function 2
Vertical Partitioning:Vertical Partitioning:FactoringFactoring
�� design so that decision making and work are design so that decision making and work are stratifiedstratified
�� decision making modules should reside at the top decision making modules should reside at the top
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 23
of the architectureof the architecture
workersworkers
decisiondecision--makersmakers
Why Partitioned Architecture?Why Partitioned 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
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 24
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
Structured DesignStructured Design
�� objective:objective: to derive a program to derive a program
architecture that is partitionedarchitecture that is partitioned
�� approach:approach:
�� the DFD is mapped into a program the DFD is mapped into a program architecturearchitecture
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 25
architecturearchitecture
�� the PSPEC and STD are used to indicate the the PSPEC and STD are used to indicate the content of each modulecontent of each module
�� notation:notation: structure chartstructure chart
Flow CharacteristicsFlow Characteristics
Transform flow
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 26
Transaction
flow
General Mapping ApproachGeneral Mapping Approach
Isolate incoming and outgoing flow Isolate incoming and outgoing flow
boundaries; for transaction flows, isolate boundaries; for transaction flows, isolate
the transaction centerthe transaction center
Working from the boundary outward, mapWorking from the boundary outward, map
DFD transforms into corresponding modulesDFD transforms into corresponding modules
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 27
DFD transforms into corresponding modulesDFD transforms into corresponding modules
Add control modules as requiredAdd control modules as required
Refine the resultant program structureRefine the resultant program structure
using effective modularity conceptsusing effective modularity concepts
Transform MappingTransform Mapping
data flow model
ab
c
d e fg h
ij
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 28
"Transform" mappingx1
x2 x3 x4
b c
a
d e f g i
h j
FactoringFactoring
typical "decision making" modules
direction of increasing decision making
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 29
typical "worker" modules
First Level FactoringFirst Level Factoring
main programcontroller
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 30
inputcontroller
processingcontroller
outputcontroller
Second Level MappingSecond Level Mapping
D
C
BA
A
B
main
control
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 31
C
B
Dmapping from the flow boundary outward
Transaction FlowTransaction Flow
T
incoming flow
action path
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 32
Transaction ExampleTransaction Example
operatorcommands
processoperator commands
fixture setting
report
fixtureservos
displayscreen
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 33
robot control
robotcontrolsoftware
in reality, other commandswould also be shown
assemblyrecord
Refining the Analysis ModelRefining the Analysis ModelWrite an English language processing narrative Write an English language processing narrative
for the level 01 flow modelfor the level 01 flow model
Apply noun/verb parse to isolate processes, data Apply noun/verb parse to isolate processes, data
items, store and entitiesitems, store and entities
Develop level 02 and 03 flow modelsDevelop level 02 and 03 flow models
1.1.
2.2.
3.3.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 34
Develop level 02 and 03 flow modelsDevelop level 02 and 03 flow models
Create corresponding data dictionary entriesCreate corresponding data dictionary entries
Refine flow models as appropriateRefine flow models as appropriate
... now, we're ready to begin design!... now, we're ready to begin design!
3.3.
4.4.
5.5.
Deriving Level 1Deriving Level 1Processing narrative for " process operator commands"Processing narrative for " process operator commands"
Process operator command software reads operator commands from Process operator command software reads operator commands from the cell operator. An error message is displayed for invalid commands. the cell operator. An error message is displayed for invalid commands. The command type is determined for valid commands and appropriate The command type is determined for valid commands and appropriate action is taken. When fixture commands are encountered, fixture action is taken. When fixture commands are encountered, fixture status is analyzed and a fixture setting is output to the fixture servos. status is analyzed and a fixture setting is output to the fixture servos. When a report is selected, the assembly record file is read and a When a report is selected, the assembly record file is read and a report is generated and displayed on the operator display screen. report is generated and displayed on the operator display screen. When robot control switches are selected, control values are sent to When robot control switches are selected, control values are sent to the robot control system. the robot control system.
Processing narrative for " process operator commands"Processing narrative for " process operator commands"
nounnoun--verbverb
parseparse
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 35
the robot control system. the robot control system.
Process operator command software Process operator command software readsreads operator operator commandscommands from from the cell the cell operatoroperator. An . An error messageerror message is is displayeddisplayed for for invalid commandsinvalid commands. . The The command typecommand type is is determineddetermined for for valid commandsvalid commands and appropriate and appropriate action is action is takentaken. When . When fixture commandsfixture commands are are encounteredencountered, , fixture fixture statusstatus is is analyzedanalyzed and a and a fixture settingfixture setting is is outputoutput to the to the fixture servosfixture servos. . When a When a reportreport is is selectedselected,, the the assembly record fileassembly record file is is readread and a and a report is report is generatedgenerated and and displayeddisplayed on the operator on the operator display screendisplay screen. . When When robot control switchesrobot control switches are are selectedselected, , control valuecontrol values s are are sentsent to to the the robot control system. robot control system.
parseparse
Transaction Mapping PrinciplesTransaction Mapping Principles
isolate the incoming flow pathisolate the incoming flow path
define each of the action paths by looking for define each of the action paths by looking for the "spokes of the wheel"the "spokes of the wheel"
assess the flow on each action pathassess the flow on each action path
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 36
assess the flow on each action pathassess the flow on each action path
define the dispatch and control structuredefine the dispatch and control structure
map each action path flow individuallymap each action path flow individually
Transaction MappingTransaction Mapping
data flow model
ab
t
de f
gh
i
j
k
l
m
n Mappingx1
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 37
n Mapping
b
a
x1
t
x2
d e f
x3
g h x3.1
i j
k
x4
l m n
Map the Flow ModelMap the Flow Model
process operator
commands
command input
controller
determine type
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 38
controller
read command
validate command
produce error
message
fixture status
controller
report generation controller
send control value
each of the action paths must be expanded further
Refining the Structure ChartRefining the Structure Chartprocess operator
commands
command input
controller
determine type
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 39
read command
validate command
produce error
message
send control value
read fixture status
determine setting
format setting
read record
calculate output values
format report
fixture status
controller
report generation controller
Recommended