Software Architecture Design Principles and Techniques
Architecture
Design
Topics
Process
Foundational Architecture Design Principles and Techniques
Software Architecture Design
Reference Model
(ASRs/QAs)
Software Architecture Design
Architecture design is a systematic approach to making
design decisions
Checklist for QA Tactics Choices
Software Architecture Design
Starting with requirements …
Apply
design
best
practices and knowledge
Patterns
– structure scaffolding based on the ASR’s; select or
create
Design tactics
– proven design solutions in problem context
Foundational design principles and techniques
at the
module
level
Analyze design decisions
and refine – requirements satisfied, QA tradeoffs
addressed?
Quantitative
and
qualitative analysis
Document
the structures in
views
with supplemental information
Module, component-connector, allocation
Attribute Driven Design
Attribute Driven Design
Strategy
Important quality attributes affect the
whole
system
Therefore
design begins with the whole system
◦
Each
element may inherit
all or part of the
quality attribute requirements
from the whole
Design to satisfy all architecturally significant requirements – one or
more at a time
◦
Quality attributes (scenarios)
◦
Constraints and other ASR’s– e.g., legacy systems
◦
Functional requirements (use cases)
Attribute Driven Design
Strategy (cont)
Initial design
is generated from some combination of ….
◦
Existing
systems and frameworks
◦
Architecture
patterns
and tactics
selected
to satisfy quality attributes
◦
Domain functions (use cases)
allocated
to modules provided by the pattern
and associated tactics
Test the initial design
– does it satisfy requirements?
◦
Use
analysis techniques
( future topic) and
checklists
of ASR requirements
Attribute Driven Design
Strategy (cont)
Refine
initial design
by addressing missing requirements and applying
other design tactics
Recursive decomposition
- for some subsystem of the system…
◦
Repeat the process
When do you declare victory?
◦
All ASRs are satisfied
◦
Out of time and money – construction will refine
Attribute Driven Design “Strategy”
A
l
l
o
c
a
t
e
F
u
n
c
t
i
o
n
s
Function Driven Design
Functionality-Based
Architectural Design
S
t
a
r
t
i
n
g
f
r
o
m
f
u
n
c
t
i
o
n
a
l
r
e
q
u
i
r
e
m
e
n
t
s
…
D
e
f
i
n
e
s
y
s
t
e
m
c
o
n
t
e
x
t
I
d
e
n
t
i
f
y
s
u
b
s
y
s
t
e
m
s
(
f
i
r
s
t
o
r
d
e
r
f
u
n
c
t
i
o
n
a
l
a
b
s
t
r
a
c
t
i
o
n
s
)
◦
Top down, step wise refinement
◦
Is a bottom up approach ever advised?
D
e
c
o
m
p
o
s
e
i
n
t
o
m
o
d
u
l
e
s
(
s
e
c
o
n
d
o
r
d
e
r
f
u
n
c
t
i
o
n
a
l
a
b
s
t
r
a
c
t
i
o
n
s
)
Describe in system views
O
u
t
p
u
t
a
r
t
i
f
a
c
t
i
s
t
h
e
a
p
p
l
i
c
a
t
i
o
n
a
r
c
h
i
t
e
c
t
u
r
e
Abstraction
Detail
Estimate Quality Attributes
E
v
a
l
u
a
t
e
t
h
e
q
u
a
l
i
t
y
a
t
t
r
i
b
u
t
e
s
–
w
i
l
l
t
h
e
a
r
c
h
i
t
e
c
t
u
r
e
f
u
l
f
i
l
l
t
h
e
q
u
a
l
i
t
y
a
t
t
r
i
b
u
t
e
r
e
q
u
i
r
e
m
e
n
t
s
?
How to determine – actual values can’t be measured …
◦
“
F
o
r
m
a
l
”
a
r
c
h
i
t
e
c
t
u
r
e
a
n
a
l
y
s
i
s
t
e
c
h
n
i
q
u
e
s
◦
Architecture Tradeoff Analysis Method
(ATAM)
(discussed soon)
◦
S
i
m
u
l
a
t
i
o
n
–
b
u
i
l
d
a
s
k
e
l
e
t
o
n
o
f
t
h
e
e
n
t
i
r
e
s
y
s
t
e
m
,
o
r
p
r
o
t
o
t
y
p
e
p
a
r
t
s
t
o
e
x
e
c
u
t
e
s
c
e
n
a
r
i
o
s
◦
Q
u
a
n
t
i
t
a
t
i
v
e
(
m
a
t
h
e
m
a
t
i
c
a
l
)
m
o
d
e
l
i
n
g
o
f
s
c
e
n
a
r
i
o
s
;
e
.
g
.
,
q
u
e
u
i
n
g
n
e
t
w
o
r
k
t
h
e
o
r
y
◦
Q
u
a
l
i
t
a
t
i
v
e
e
x
p
e
r
i
e
n
c
e
-
b
a
s
e
d
a
s
s
e
s
s
m
e
n
t
In practice use more
than one method
Architecture Transformation
Compare
evaluation
estimates
to
requirements
If
requirements not satisfied
(likely), the architecture (or its context)
must be
changed
Apply
two or more
architecture transformation methods:
◦
Impose
architectural patterns
◦
Apply
design tactics
◦
Convert quality requirements to functionality
to extend the architecture
(e.g., exception handling)
◦
Distribute quality requirements to subsystems
Reevaluate
the transformed architecture against functional and quality
requirements
Issues
Quality attributes can be in conflict
– QA
tradeoffs
◦
Examples?
Complexity
– relatively
simple
functional
architectural
designs
may blow up
in
complexity to support quality attributes
◦
Lose conceptual understanding
Quality assessment estimates are
estimates
and may
lead to the wrong decisions
(GIGO)
◦
The only real validation is the final system
Foundational
Architecture Design
Techniques
FUNDAMENTAL PRINCIPLES
UNIT OPERATIONS
Some Historical Perspective
In the 60’s programmers started to develop good design practices out of
necessity
In the 70’s these were more formally captured in papers by people like
Fred Brooks, Edsger Dijkstra, and David Parnas
In the 80’s these practices were embodied in object oriented design
These design principles and unit operations can and should be applied
to software architecture design
Fundamental Principles and
Techniques of Software Construction
Software Partitioning Strategies
(e.g.)(Separation of Concerns)
Isolate:
◦
Hardware dependencies
◦
Time critical components
◦
Configuration data
◦
External interfaces
Separate:
◦
Logically cohesive domain functionality
◦
Human computer interface from domain model
◦
Main functions from utility functions (cross cutting concerns)
Additional Notes
Architecture concerns at a module level …
Most principles and techniques are closely related – complementary
Some principles contradictory
Integration and dependencies
Modularity and Software Cost
Software Changeability and
Dependency Management
The stable dependencies principle (SDP):
◦
“Depend in the direction of stability”; modules should only depend on
modules that are more stable than it is
Acyclic Dependencies Principle
◦
“Dependency structure for released components must be a directed acyclic
graph”; no cycles in the dependency structure
Interface Segregation Principle
◦
Clients should not be forced to implement interfaces they don’t use
Integration Strategies
How will various parts of the system communicate?
◦
E.g., COTS or legacy systems, major internal subsystems
◦
Build time versus run time binding decisions
Data-only integration (lower level of abstraction)
◦
Loose coupling through data exchange only in suitable formats
◦
Downside – user may be involved
Executable integration (higher level of abstraction)
◦
A
stand-alone executable component is used to perform a specific function
in the system for data interoperability
Unit Operations
Basic (primitive) operations applied to architecture design
Unit operations are the steps that one applies to derive patterns
Examples (object design derivation)
◦
Part-whole decomposition
◦
Is-a decomposition
◦
Replication
◦
Abstraction
◦
Compression
◦
Resource sharing
Unit Operations
Software
Architecture
Design Example
USING ATTRIBUTE DRIVEN DESIGN
Garage Door Example
Design a product line architecture for a garage door opener
integrated with a home information system
◦
Raise/lower door via switch, remote, home info system
◦
Problem diagnosis from home information system
For
new
(green field) systems it is the
whole system
For
legacy
, what is being
added
After the first iteration what comes next,
element breadth or
depth?
◦
Depth if technology risk or resourcing concerns
Garage door opener is the system
Step 1: Choose a System Element
to Design
Step 2: Identify the ASRs
(Architecturally Significant Requirements)
Start with quality
scenarios
◦
Device and controls differ for various products in product line
◦
Product processors differ
◦
Garage door descent must stop within 0.1 second after obstacle detection
◦
Access to opener from home info system for control and diagnostics with
proprietary protocol
Step 2: Identify the ASRs
(cont)
ASRs are a combination of
functional requirements, constraints and
quality attributes
Prioritize ASRs
and select those that will “drive“ the architecture design
Garage door system:
◦
Real-time performance
◦
Modifiability to support the product line
◦
Interoperability for on-line control and diagnostics
Step 3: Generate a Design Solution
For the Chosen Element
Goal: establish an
overall architecture design
that satisfies
architectural drivers
For each ASR
for this element choose a design solution …
The patterns, tactics, design principles
to achieve quality attributes
Watch for QA design tradeoffs between tactics
It’s possible the domain problem may call for a
“custom” architecture pattern
Step 3: Generate a Design
Solution (cont)
Performance
◦
Concerned with critical computational performance scheduling and
efficiency
◦
Need tactics to deal with the
control of resource demand and resource
management
◦
Choose “
increase resource efficiency
” and “
schedule resources
”
◦
Solution - separate critical and non-critical performance computation
Performance Tactics
Step 3: Generate a Design
Solution (cont)
Modifiability
◦
Primarily concerned with
changes at build time
, not runtime
◦
Need tactics to support
separation of responsibilities to localize changes
◦
Increase cohesion, reduce coupling
◦
Choose
“increase semantic coherence”, “encapsulation”, and
“abstract common services”
as our tactics
◦
Solution - separate responsibilities dealing with the user interface,
communication, and sensors into their own modules
Modifiability
Tactics
Pattern for Garage Door
Opener
Step 4: Validate Design and Refine
Requirements
Test the element design for requirements satisfaction
Step 4: Validate Design and Refine
Requirements
(cont)
Note: Previous designs become a constraint
Step 5: Repeat Until all ASRs Have Been
Satisfied
If all ASR’s satisfied, done –
a workable architecture
◦
Or elaborated sufficiently for construction
◦
(or you run out of time and money)
Otherwise …
Repeat step 1 - choose the next (sub)element(s) to design
Repeat steps 2-4
As necessary refine use cases and QA scenarios as ASRs for the
next design iteration
Are the ASR’s Satisfied?
Or is the Design Sufficient?
Device and controls differ for various products in product line
Product processors differ
Garage door descent must stop within 0.1 second after obstacle
detection
Access to opener from home info system for control and diagnostics
with proprietary protocol
Next Iteration Decomposition
Define sub-modules, assign functionality
Two types of virtual machine – sensors/actuators and communications
modules
Non-performance critical functional modules – diagnostics and normal
raising/lowering the door modules
Obstacle detection and halting the door functions assigned to
performance critical module
Connections
Next Iteration Design
Decomposition
Lets design the HC system
Users Register
Users select Health plan
- Online
- By Mail
- By phone
Exploring the systematic approach of architecture design in software engineering, this content covers foundational principles, design decisions, allocation of responsibilities, coordination, resource management, technology choices, and best practices. It emphasizes starting with requirements, applying design tactics, analyzing decisions, and documenting structures for effective software architecture design.
Uploaded on Sep 14, 2024 | 0 Views
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
E N D
Presentation Transcript
Architecture Design
Topics Process Foundational Architecture Design Principles and Techniques R I T Software Engineering
Software Architecture Design Reference Model Requirements: Domain functions Quality attributes Use cases Architecture Design Documentation (ASRs/QAs) Architecture Drivers Subset Module decomposition design Quality Attribute Scenarios Design decision analysis Pattern and design tactics selection Architecture Pattern Catalog R I T Software Engineering
Software Architecture Design Architecture design is a systematic approach to making design decisions Allocation of responsibilities Allocation of functional and non-functional responsibilities into structural modules Coordination model Module interaction and system interfaces Data model Data abstractions and physical organization Resource management Shared resource(hard and soft) allocation and utilization Architecture element mapping Mapping of module abstractions to physical resources Bind time decisions Timing for variability development, deployment, runtime Technology choices For hardware, software, tools Checklist for QA Tactics Choices R I T Software Engineering
Software Architecture Design Starting with requirements Apply design best practices and knowledge Patterns structure scaffolding based on the ASR s; select or create Design tactics proven design solutions in problem context Foundational design principles and techniques at the module level Analyze design decisions and refine requirements satisfied, QA tradeoffs addressed? Quantitative and qualitative analysis Document the structures in views with supplemental information Module, component-connector, allocation R I T Software Engineering
Attribute Driven Design Requirements: Domain functions Quality attributes Use cases Architecture Design Documentation Architecture Drivers Subset Module decomposition design Quality Attribute Scenarios Design decision analysis Architecture Pattern Catalog Pattern and design tactics selection R I T Software Engineering
Attribute Driven Design Strategy Important quality attributes affect the whole system Therefore design begins with the whole system Each element may inherit all or part of the quality attribute requirements from the whole Design to satisfy all architecturally significant requirements one or more at a time Quality attributes (scenarios) Constraints and other ASR s e.g., legacy systems Functional requirements (use cases) R I T Software Engineering
Attribute Driven Design Strategy (cont) Initial designis generated from some combination of . Existing systems and frameworks Architecture patterns and tactics selected to satisfy quality attributes Domain functions (use cases)allocated to modules provided by the pattern and associated tactics Test the initial design does it satisfy requirements? Use analysis techniques ( future topic) and checklists of ASR requirements R I T Software Engineering
Attribute Driven Design Strategy (cont) Refineinitial design by addressing missing requirements and applying other design tactics Recursive decomposition - for some subsystem of the system Repeat the process When do you declare victory? All ASRs are satisfied Out of time and money construction will refine R I T Software Engineering
Foundational Architecture Design Techniques FUNDAMENTAL PRINCIPLES UNIT OPERATIONS
Some Historical Perspective In the 60 s programmers started to develop good design practices out of necessity In the 70 s these were more formally captured in papers by people like Fred Brooks, Edsger Dijkstra, and David Parnas In the 80 s these practices were embodied in object oriented design These design principles and unit operations can and should be applied to software architecture design Component X Component Y R I T Software Engineering
Fundamental Principles and Techniques of Software Construction Abstraction Define conceptual boundaries Separation of Concerns Separate different or unrelated responsibilities Modularization Packaging of entities that form the logical structure of a system - modules Information Hiding Conceal module design details from its clients Encapsulation Group the elements of an abstraction that constitute its structure and behavior Coupling and Cohesion Inter- and intra- module dependency strength Sufficiency, Completeness and Primitiveness Satisfy minimum and necessary requirements as atomic operations Separation of Policy and Implementation Separation of context sensitive knowledge and rules from algorithmic implementation Separation of Interface and Implementation Separation of the declaration of functionality from its realization Single Point of Reference Declare and define a module only once to avoid inconsistency R I T Software Engineering
Software Partitioning Strategies (e.g.)(Separation of Concerns) Isolate: Hardware dependencies Time critical components Configuration data External interfaces Separate: Logically cohesive domain functionality Human computer interface from domain model Main functions from utility functions (cross cutting concerns) R I T Software Engineering
Additional Notes Architecture concerns at a module level Most principles and techniques are closely related complementary Some principles contradictory Integration and dependencies R I T Software Engineering
Modularity and Software Cost Cost to integrate Region of minimum cost Cost of Effort Cost/module Number of Modules R I T Software Engineering
Software Changeability and Dependency Management The stable dependencies principle (SDP): Depend in the direction of stability ; modules should only depend on modules that are more stable than it is Acyclic Dependencies Principle Dependency structure for released components must be a directed acyclic graph ; no cycles in the dependency structure Interface Segregation Principle Clients should not be forced to implement interfaces they don t use R I T Software Engineering
Integration Strategies How will various parts of the system communicate? E.g., COTS or legacy systems, major internal subsystems Build time versus run time binding decisions Data-only integration (lower level of abstraction) Loose coupling through data exchange only in suitable formats Downside user may be involved Executable integration (higher level of abstraction) A stand-alone executable component is used to perform a specific function in the system for data interoperability R I T Software Engineering
Unit Operations Basic (primitive) operations applied to architecture design Unit operations are the steps that one applies to derive patterns Examples (object design derivation) Part-whole decomposition Is-a decomposition Replication Abstraction Compression Resource sharing R I T Software Engineering
Unit Operations Part-whole decomposition Is-a decomposition Abstraction Replication Compression (Consolidation) Resource Sharing R I T Software Engineering
Software Architecture Design Example USING ATTRIBUTE DRIVEN DESIGN
Garage Door Example Design a product line architecture for a garage door opener integrated with a home information system Raise/lower door via switch, remote, home info system Problem diagnosis from home information system Diagnostics Alerts Garage Door Opener Home Info Sys Sensor/ Actuator Control Control Control Remote R I T Software Engineering
Step 1: Choose a System Element to Design For new (green field) systems it is the whole system For legacy, what is being added After the first iteration what comes next, element breadth or depth? Depth if technology risk or resourcing concerns Garage door opener is the system R I T Software Engineering
Step 2: Identify the ASRs (Architecturally Significant Requirements) Start with quality scenarios Device and controls differ for various products in product line Product processors differ Garage door descent must stop within 0.1 second after obstacle detection Access to opener from home info system for control and diagnostics with proprietary protocol R I T Software Engineering
Step 2: Identify the ASRs (cont) ASRs are a combination of functional requirements, constraints and quality attributes Prioritize ASRs and select those that will drive the architecture design Garage door system: Real-time performance Modifiability to support the product line Interoperability for on-line control and diagnostics R I T Software Engineering
Step 3: Generate a Design Solution For the Chosen Element Goal: establish an overall architecture design that satisfies architectural drivers For each ASR for this element choose a design solution The patterns, tactics, design principles to achieve quality attributes Watch for QA design tradeoffs between tactics It s possible the domain problem may call for a custom architecture pattern R I T Software Engineering
Step 3: Generate a Design Solution (cont) Performance Concerned with critical computational performance scheduling and efficiency Need tactics to deal with the control of resource demand and resource management Choose increase resource efficiency and schedule resources Solution - separate critical and non-critical performance computation R I T Software Engineering
Performance Tactics R I T Software Engineering
Step 3: Generate a Design Solution (cont) Modifiability Primarily concerned with changes at build time, not runtime Need tactics to support separation of responsibilities to localize changes Increase cohesion, reduce coupling Choose increase semantic coherence , encapsulation , and abstract common services as our tactics Solution - separate responsibilities dealing with the user interface, communication, and sensors into their own modules R I T Software Engineering
Modifiability Tactics Modifiability Tactics Reduce Coupling Defer Binding Increase Cohesion Reduce Size of a Module Changes Made and Deployed Change Requests Encapsulate Increase Semantic Coherence Split Module Use an Intermediary Restrict Dependencies Refactor Abstract Common Services R I T Software Engineering
Pattern for Garage Door Opener User Interface Non-Performance- Critical Computation Performance-Critical Computation Virtual Machine Schedule that Guarantees Deadlines R I T Software Engineering
Step 4: Validate Design and Refine Requirements Test the element design for requirements satisfaction Requirements satisfied Done, no more refinement Defer to the next iteration Delegate or distribute requirement satisfaction to sub-module elements Requirements not fully satisfied Revisit the design - backtrack Refine or push back on the requirement Requirements cannot be satisfied with this design R I T Software Engineering
Step 4: Validate Design and Refine Requirements (cont) ASRs Not Met Action Apply tactics to address tradeoff or downside Add responsibilities to existing module Create new module Modify the design Relax the constraint Quality attribute Functional responsibility Constraint Note: Previous designs become a constraint R I T Software Engineering
Step 5: Repeat Until all ASRs Have Been Satisfied If all ASR s satisfied, done a workable architecture Or elaborated sufficiently for construction (or you run out of time and money) Otherwise Repeat step 1 - choose the next (sub)element(s) to design Repeat steps 2-4 As necessary refine use cases and QA scenarios as ASRs for the next design iteration R I T Software Engineering
Are the ASRs Satisfied? Or is the Design Sufficient? Device and controls differ for various products in product line Product processors differ Garage door descent must stop within 0.1 second after obstacle detection Access to opener from home info system for control and diagnostics with proprietary protocol R I T Software Engineering
Next Iteration Decomposition Define sub-modules, assign functionality Two types of virtual machine sensors/actuators and communications modules Non-performance critical functional modules diagnostics and normal raising/lowering the door modules Obstacle detection and halting the door functions assigned to performance critical module Connections R I T Software Engineering
Next Iteration Design Decomposition User Interface Raising/Lowering Door Obstacle Detection Diagnose Scheduler that Guarantees Deadlines Communication Virtual Machine Sensor/Actuator Virtual Machine R I T Software Engineering
Lets design the HC system Users Register Users select Health plan - Online - By Mail - By phone R I T Software Engineering
