5. DESIGN I:SOFTWARE
ARCHITECTURE
Plan project
Integrate & test system
Analyze requirements
Design
Maintain
Test unitsImplement
Software Engineering Roadmap: Chapter 5 Focus
Identify corporate practices
Develop Architecture
Develop Detailed Design (next chapter)
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Chapter Learning Goals
• Understand “Software Architecture” term
• Utilize frameworks, design patterns, and
models
• Develop architecture alternatives
• Relate architectures to detailed designs
• Apply the IEEE SDD standardAdapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
1. Introduction to system engineering and software architecture
System Engineering and s/w Acrh.
• System Engineering = analysis and design process which decomposes an application (system) in components (hardware, software, people) and then reassembles it
Systems analysis – decomposes a system into its component pieces for the purpose of studying how well those component parts work and interact - deals with “What”
Systems design – reassembles a system’s component pieces back into a complete system … hopefully, an improved system (via addition, change) – deals with “How”
• Software Architecture = design at the highest level– Beyond requirements that defined what system must do, where it
must do it and when – Focus moves strongly toward how system will meet requirements
Player m
GameCorp Billing server
Player n
A Physical Configuration for Internet-based Encounter
Key:
EncounterGUI
EncounterGUI
. . . .
Hardwareplatform
Softwaresubsystem
Internet
Encounter Server
Encounterengine
EncounterReporter
Accountdatabase
Accountprocessing
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Autocontrol
processor
Antilock Braking System Diagram
Key:
ABS controller
Hardware Softwaresubsystem
Wheel speed sensor
Speed thresh-hold alert
Hydraulic pressuremodulator unit
Warning lamp
Pressure controller
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
An example of Embedded s/w
Workshop
• In your project teams …• Consider a high-rise building of 25 stories
composed of offices.• Draw a high-level architecture showing the
major h/w and s/w components
Cohesion and Coupling
1
2 3 4
5 6High cohesion Low couplingBridge
component
component
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Effective modularization = max. cohesion within modules + min. coupling between modules
Cohesion and Coupling
1
2 3 4
5 6High cohesion Low coupling
High coupling
Bridge
component
component
component
Steeltruss
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Why High Cohesion /Low Coupling?
• Extensibility – easy to add requirements• Facilitates change / replacement• Simplicity of structure … easy to
understand, implement, maintain• Usually more efficient – smaller in size,
faster, requires less resources• Facilitates layered and distributed
architectures• THESE ARE THE KEY DESIGN GOALS
1. Develop a mental model of the application at a high level.– as if it were a small applicatione.g., personal finance application ... … “works by receiving money or paying out money,
in any order, controlled through a user interface”.2. Decompose into the required components.
– look for high cohesion & low couplinge.g., personal finance application ... … decomposes into Assets, Suppliers, & Interface.
3. Repeat this process for the components.
Begin Selecting a Basic Architecture
Note: To use established architectures, see the rest of this chapter
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Workshop
• In your project teams …• Consider the high-rise building of 25 stories
once more.• Can you increase cohension within
components and decrease coupling between components through re-design?
• Focus on two related components and take them to the next level of detail (eg. Electrical and Security subsystems)
2. Models, frameworks, and design patterns
Definitions:
• Model = a perspective (usually graphical) of the decomposition of a system into components and the relationship between those components– Different models are used for each system
• Framework = a family or class of applications for which models can be reused– Design patterns of interrelated classes that have
been used many times (eg. queuing system)– A general RPG framework will be developed
for role playing games, then used for Encounter
TargetApplication
Class model“with objects of these classes ...”
e.g., with Engagement … classes
State model“reacting to these events ...”
e.g., when foreign character enters
Use-case model“Do this ...”
e.g., engage foreign character
Component model“in this way ...”
e.g., data flows from … to
To express requirements, architecture & detailed designModels
ModelsTarget
Application
Class model: “with ...”
State model: “when”
Use-case model: “do this”
Component model: “how”
class
methods
States
Transitions
Use case
Scenarios
Business use case
Component
Sub-component
Data flow
Local data flow
elaborated by ...Sequencediagram
package
consistsof ...
organizedby ...
Substatesdecomposedinto ...
Jacobson et al
«application package»
RPG Video Game Layering
«framework package»
Characters
PlayerCharacter
EncounterCharacter
ForeignCharacter
EncounterCharacters
PlayerQualityWindow
«uses»
Framework layer
Application layer
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
«framework package»
«framework package»
«framework package»
«application package»
Characters RolePlayingGame
GameEnvironment
EncounterEnvironmentPlayerCharacter
EncounterCharacter
«application package»
ForeignCharacter
EncounterCharacters «application package»
EncounterGame Engagement
EngagementDisplay
EncounterGame
Area
PlayerQualityWindow
EncounterAreaConnection
Framework layer
Application layer
Role-Playing Game, and Encounter Packages -- showing domain classes
ConnectionHyperlink
«uses»
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
1. Create domain classes
-- from requirementsanalysis
3. Create design classes
-- specific to this application-- to complete the class model
One Way to Obtain The Class Model
2. Create and/or use framework classes
-- for architectureMore
general
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Categorization of Software Architectures (Shaw & Garlan)
• Dataflow architectures• Batch sequential• Pipes and Filters
• Independent components
• Parallel communicating processes
• Client-server systems• Event systems
• Virtual machines • Interpreters• Rule-based systems
• Repository architectures
• Databases• Hypertext systems• Blackboards
• Layered architectures
• Comm. stacks
Design patternArchitecturalDesign Patterns:Summary
Design Goal Design patternProvide an interface to a set of objects of various classes. Facade
Cause an object to behave in a manner determined by its current state. State
Encapsulate ways of "visiting" the objects in a collection, so that client code can select a way of visiting at runtime.
Iterator
Facilitate the response of interested entities to changes in a data source. Observer
Interpret statements written in a formal grammar. Interpreter
Client code
see ...
3.2.1
3.2.3
3.4.1
3.2.2.1
3.4.1
Setup code
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
3. Software architecture alternatives and their class models
(design patterns)
Facade Design Pattern Structure
P
«exposed»
This shows a direct call to a process “P” from Client
Client
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Q «exposed»
Wide field of accessto server objects
Facade Design Pattern Structure
Q «not exposed»
P
«not exposed»
Façade«exposed»
The call is replaced by 1 & 2; (Client can’t refer to “P”)
Client1
2
«not exposed» «not exposed»
«not exposed»
«not exposed»
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Settingqualities
Sketch of Encounter State-Transition Diagram
Setting up
Engaging
Waiting
Player completes
setup
Player dismisses
report window
Reporting
Foreign character
enters area
Encounter completed
Player dismisses
set qualities widow
Player requests status
Player requests to
set qualities Foreign
character enters area
[foreign character absent]
[foreign character present]
Player moves to adjacent
areaPlayer quits
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
TargetStateBhandleRequest()
TargetdoRequest()
State Design Pattern Structure: doRequest() behaves according to state of Target
targetState TargetStatehandleRequest()
Client
TargetStateAhandleRequest()
1
{ targetState.handleRequest(); }
. . . . . .
target:Target
Gamma et al
RolePlayingGameState Design Pattern Applied to Role-Playing Game
RPGamehandleEvent()
GameStatehandleEvent()
state
{ state.handleEvent(); }
ReportinghandleEvent()
EngaginghandleEvent()
SettingUphandleEvent()
EncounterGame EncounterGame
WaitinghandleEvent()
Setting QualitieshandleEvent()
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
A Typical Repository Architecture
Database
DBMS
GUI
Analysisprocess
1
Analysisprocess
n…...…...
Control
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Entity Relationship Modeling
ERD = Entity Relationship Diagram
An Example: Relational Tables
pnum pdesc psd ped1 E911 Apr Nov2 CAPC Aug Dec
eid ename9902 Ritter, Tex0103 Nasium, Jim
aid ………………..apnum aeid alnum abd aed1 9902 Hfx1 May Oct1 0103 Hfx1 May Aug2 0103 Yrm2 Sep Oct
lnum laddressHfx1 1234 Barrington St.Yrm2 56 Front St.
PROJECT EMPLOYEE
ASSIGNMENTLOCATION
Role-playing game layer
Layered Architecture
Characters LayoutRolePlayingGame
EncounterCharacters
EncounterEnvironment
Encounter Game
Application layer
3D engine layer
«uses»
«uses»
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Example of Architecture Uses
Parallel communi-cating processes Event system
Rule-basedsystem
Databasesystem
DatabasesystemLayered
system
Characters
Artifacts
RolePlayingGame
Layout
Encounter Layout
Posible architecture types used
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
1. Decompose into self-contained modules.2. Compare with a standard architecture (e.g., Garlan
and Shaw’s classification). Improve decomposition.– Data flowing in batches between processing stations?
• batch sequential dataflow– Processing stations waiting for data, then executing?
• pipe-and-filter dataflow– Processes executing in parallel?
• parallel communicating processors – A process supplying the needs of user processes?
• client-server– A process only reacting to events occurring upon it?
• event systems– Each execution the interpretation of a script?
• interpreters– An application centered on a data store?
• repository– Arranged in layers?
• layeredTry to develop at least two alternative architectures.
Select an Architecture 1
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
2. Select among the alternatives identified.3. Add classes to those from requirements analysis, to
accommodate the architecture selected– e.g., data flow: … to control flow among the elements– e.g., event systems: … to control transitions among states
4. Apply an existing framework and/or design pattern.– if a helpful one can be identified
5. Partition the collection of classes into packages– ideally, 4-8 (nest packages for larger applications) – each package should make sense in the language of the
application (e.g., “videos” OK; “big classes” not OK) 6. Verify high cohesion within parts; low coupling
among parts -- otherwise, adjust choice.7. Consider introducing a Façade class/object to
control the interface to each package
Select an Architecture 2
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
IEEE 1016-1987 SDD Example Table of Contents (Reaffirmed 1993)
1. Introduction 1.1. Purpose 1.2. Scope 1.3. Definitions, acronyms & abbreviations2. References3. Decomposition description 3.1. Module decomposition 3.1.1 Module 1 description 3.1.1 Module 2 description 3.2 Concurrent process decomposition 3.2.1 Process 1 description 3.2.2 Process 2 description 3.3 Data decomposition 3.3.1 Data entry 1 description 3.3.2 Data entry 2 description
4. Dependency description 4.1 Intermodule dependencies 4.2 Interprocess dependencies 4.3 Data dependencies5. Interface description 5.1 Module interface 5.1.1 Module 1 description 5.1.2 Module 2 description 5.2 Process interface 5.2.1 Process 1 description 5.2.2 Process 2 description6. Detailed design 6.1 Module detailed design 6.1.1 Module 1 detail 6.2.2 Module 2 detail 6.2 Data detailed design 6.2.1 Data entity 1 detail 6.2.2 Data entity 2 detail
Architecture
5. Architecture selection QA
Architecture 1 Architecture 2 Architecture 3
QualityQuality weight:
1-109 =High; 5 = Medium; 2 = Low
Extension e ea1 ea2 ea3
Change c ca1 ca2 ca3
Simplicity s sa1 sa2 sa3
Efficiency: speed esp espa1 espa2 espa3
Efficiency: storage est esta1 esta2 esta3
TOTAL:e*ea1 + c*ca1 + s*sa1 + esp*espa1 + est*esta1
e*ea2 + c*ca2 + s*sa2 + esp*espa2 + est*esta2
e*ea3 + c*ca3 + s*sa3 + esp*espa3 + est*esta3
Table 5.2 Fuzzy method for comparing architectures
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Architecture Alternative
1. State design pattern
2. ad hoc GUI-driven
3. State-transition table
Quality Quality weight:1-10 High = 9; Medium = 5; Low = 2
Extension 9 High Low Medium
Change 7 High Low Medium
Simplicity 5 Low High Medium
Efficiency: speed 5 Medium High Medium
Efficiency: storage 2 Low Low Medium
TOTAL: (higher = better) 183 126 140
Table 5.4 Fuzzy method for comparing architectures
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
WORKSHOP
• Outline three different architectures for an electronic mail system for Acadia staff.
• Use the following matrix to decide which architecture would be best (weight = 1-5).
Quality Weight Alt. 1Client/Server
Alt. 2 Browser-based
Alt. 3Telnet-based
Extension 4 5 20Change 5 3 15Simplicity 5 3 15Eff. Speed 3 5 15Eff. Storage 1 4 4TOTALS 69
Notes on Architecture Inspections
• Payoff for defect detection is highest at the early stages
• Lots of room for creativity, appears to be difficult to inspect
• Inspect against requirements.
• Check with Use Cases – does the arch. cover all scenarios
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Preparing
Defects in Encounter State-Transition Diagram
Setting up
EngagingWaiting
Player completes
setup
Player dismisses window
Reporting
Move to adjacent
area
Foreign character
enters area
Player ready to proceed
Foreign character
enters area
Player dismisses qualities
menuPlayer
requests status
Player clicks qualities
menu
Not specific enough Not
specific enough
Does not handleplayer’s entry to area containing
foreign character
State unclear
Settingqualities
Sketch of Encounter State-Transition Diagram
Setting up
Engaging
Waiting
Player completes
setup
Player dismisses
report window
Reporting
Foreign character
enters area
Encounter completed
Player dismisses
set qualities widow
Player requests status
Player requests to
set qualities Foreign
character enters area
/ foreign character
absent
/ foreign character present
Player moves to adjacent
areaPlayer quits
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Schedule Following Architecture Selection
Month 11 2 3 4
Month 21 2 3 4
Month 31 2 3 4
Month 41 2 3 4
Month 51 2 3 4
Milestones
Iteration 1
Iteration 2
Release to productionComplete testingFreeze requirements
Characters I
Characters IIRolePlayingGame I
Layout I
EncounterCharacters I
EncounterGame I
EncounterLayout I
Integration& Test I
Integration& Test II
RolePlayingGame I
Layout I
EncounterCharacters II
EncounterGame II
EncounterLayout II
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Case Study
RPG Framework for Role-Playing Video Games
CharactersRolePlayingGame
Artifacts
GameEnvironment
RPG Framework for Role-Playing Video Games
CharactersRolePlayingGame
RPGamehandleEvent()
GameStatehandleEvent()
state
{ state.handleEvent(); }
GameCharacter
ArtifactsGameArea
RPGEvent
GameAreaConnection
2GameLayout
0..n
GameEnvironment
For future releases
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Architecture and Modularization of Encounter Role-playing Game
EncounterCharacters
EncounterGame
EncounterCast«facade»
EncounterGame«facade»
EncounterEnvironment
EncounterEnvironment«facade»
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Settingqualities
Sketch of Encounter State-Transition Diagram
Setting up
Engaging
Waiting
Player completes
setup
Player dismisses
report window
Reporting
Foreign character
enters area
Encounter completed
Player dismisses
set qualities widow
Player requests status
Player requests to
set qualities Foreign
character enters area
/ foreign character
absent
/ foreign character present
Player moves to adjacent
areaPlayer quits
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Encounter Use Cases
Encounterforeign
character
player
Initialize
Travel toadjacent
area
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Architecture / Modularization
EncounterCharacters
EncounterGame
EncounterCast
EncounterGame
EncounterEnvironment
EncounterEnvironment
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
FrameWork / Application Dependency
EncounterCharacters
EncounterGameEncounterCast
EncounterGame
EncounterEnvironment
EncounterEnvironment
Characters GameEnvironment RolePlayingGame
«uses»*«uses»
«uses»
Encounter video game layer
Role-playing game layer (framework)
* by member classes implemen-ting framework interfaces
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.