Architectural Design Resolution
Architectural Design Process
Analyzed
SRS
Develop Architectural
Design Alternatives
Evaluate Architectural
Alternatives
Select Architectural
Resolution
[else ]
[selected ]
Finalize Software
Architectural Document
SAD
Various Alternatives to Generating
Architectural Design
1.
Develop Functional Components
–
Based on transforming SRS functions and data requirements
Determine/Modify Components Based on “Quality Attributes”:
maintainability, reusability, performance, availability &
security (non-functional attributes)
from 2.
scratch
–
3.
Based on transforming non-functional SRS requirements
Modifying Existing Architecture (for follow-on releases)
–
4.
Based on existing architecture as a starting point and
transforming it to satisfy the new system
Elaborate an Architecture Style (chapter 15)
–
5.
Based on an existing architectural style and elaborate on that
style
Transform a Conceptual Model (chapter 11-Destailed Design)
–
Based on viewing the SRS problem description as a solution
description and transforming that to fit the new system
Architectural Design
(team or individual activity?)
•
In software engineering, many activities are
performed as a team effort --- for
–
–
–
•
Productivity
Quality
Morale and General Acceptance
But for Architectural Design:
1. Better done as an individual first
2. Bring together all the individual architectural
design suggestions
3. Evaluate the alternatives
Determine Functional Components
(Using the “AquaLush Irrigation System” Example in
textbook – p.82 and p.164)
AquaLush Product Vision:
The AquaLush Irrigation system will use soil moisture sensors to control
irrigation, thus saving money for customers and making better use of
water resources.
AquaLush Major Product Features (from requirements):
1.
- Monitor water usage and limit usage (by moisture level) to amounts set by users
2.
3.
4.
5.
- Allow users to specify times when irrigation occurs
- Be operated from a simple central control panel
- Have a web-based simulator
- Allow users to monitor parts and schedule repairs
What would you list as major “functional components ?”
(e.g.)
1. user interface to initialize, set-up, monitor and control the irrigation system
2. sensor inputs processing
3. water irrigation control
4. web-based simulator
5. parts monitor and repair
Determining Functional Components from SRS
(page 289 – 291textbook solution)
1. configure the program at startup
2. controlling irrigation (manually and automatically)
3. providing a user interface
4. allowing users to monitor and repair system
From page 180
<<component>>
Monitor and Repair
From page 289
<<component>>
User Interface
<<component>>
Irrigation Control
<<component>>
Startup
Do the functional components and the relation “lines” make sense to you?
(Should there be a line between User Interface and Startup ?)
Determining Functional Components
(page 289 – 291textbook solution for product)
1. configure the program at startup
2. controlling irrigation (manually and automatically)
3. providing a user interface
4. allowing users to monitor and repair system
<<component>>
User Interface
<<component>>
Monitor and Repair
Note that Monitor and
Repair component can use
the Data Store to communicate
with Irrigation Control component,
without a line between them.
<<component>>
Irrigation Control
<<read & write>>
AquaLush Parts
Status
<<component>>
Startup
<<startup reads config. data>>
AquaLush
Configuration
Component Responsibilities
• There needs to be some description of each
component’s responsibilities:
– User Interface: interacts with control panel hardware and
implements control panel interface; obtains data from Monitor
and Repair ------– Monitor and Repair: Obtains data from Parts Status to pass on
to -----– Irrigation Control: Controls valve, reads sensors; reads clock;
implements irrigation cycles; --– Startup: reads the configuration data of valves, zones, etc.
and send them to Irrigation Control & (also alternatively also
include Monitor Repair) ---– Parts Status: a database that keeps track of all failed and
repaired parts, etc.
– Configuration: a database of all the installed parts of valves,
sensors, etc. of the customer’s Aqualush system
Determining Functional Components
(page 293 textbook - for adding web- simulator)
<<component>>
Simulating User
interaction
<<component>>
Monitor and Repair
<<component>>
Simulating
Valves and sensors
<<component>>
Irrigation Control
<<read & write>>
AquaLush Parts
Status
<<component>>
Startup
<<startup reads config. data>>
AquaLush
Configuration
Determining Components based on
“non-Functional” or “Quality’ attributes
• AquaLush has the following non-functional (NF)
requirements:
– Reusability : design must be used in the product, websimulator, and future versions
– Hardware adaptability: design should consider adaptability
to multiple valve types, sensor types, keypads, and screen
display types
– Reliability: must not fail “often” in normal usage
– Modifiability: accommodate future changes in irrigation
strategy (formula)
Note that reliability of not failing “often” is a nebulous and subjective statement
NonFunctional: Reusability Attribute
• Requires components to be cohesive and loosely
coupled so that they can be reused.
• Consider each component for these:
– Would you subdivide User Interface/interaction component
into several subcomponents (interface to Irrigation Control
and to Monitor and Repair separately)?
– Would you separate out Irrigation Control component into
a) manual and b) auto subcomponents?
etc.
Irrigation Control
Manual control
automatic control
NonFunctional : Hardware Adaptability &
Modifiability
• Requires the component to have device adaptability also implies
– separate cohesive subcomponents
– low coupling subcomponents, each representing different device
– hide the device specific internals and keep the interface unchanging
• In AquaLush, the Irrigation Control has interfaces to multiple
devices.
• In AquaLush, Monitor and Repair component and Startup
component has interface to a data-store
Virtual Device Interface
May change
algorithm
based on
different
sensors
valve
sensor
display
Screen
buttons
keypad
Everything inside the Device Interface components are device dependent, but hidden
from outside; all interfaces to outside of the component should stay stable
How would
you design
a single
read/write
“interface”
?
NonFunctional: Reliability and other
components
• Reliability may be argued many ways:
– Small cohesive module is by definition more reliable
– Add user interface to control irrigation both manually and
automatically AND also have direct control of the devices
User Interface
Emergency
Control
Irrigation Control
manual
auto
Virtual Device Interface
valve
keypad
Sensor
Agree with
all the interaction
lines ? Do we need
a new component ?
display
Screen buttons
Designer’s view of providing reliability ---- “ not fail often in normal usage”
Design Alternatives
• Design alternatives are good to have and can
improve the design:
– Generate and document these alternatives as the design is
getting formulated
– Combine some of the parts of the generated design
alternatives from:
• Functional Components
• Non-functional Components
– Try to alter and fit to an existing Design Style, if applicable
Architectural Design Resolution
Architectural Design Process
Analyzed
SRS
Develop Architectural
Design Alternatives
Evaluate Architectural
Alternatives
Select Architectural
Resolution
[else ]
[selected ]
Finalize Software
Architectural Document
SAD
Evaluating Architecture Alternatives
•
What does one look at when evaluating
architecture?
–
Would the architecture result in a system that will satisfy:
1.
2.
Functionality requirements
“Quality” (non-functional) requirements
–
–
–
–
–
–
–
Maintainability
Reusability
Performance
Availability
Reliability
Security
Would the architecture result in a system that will
•
•
Have “great” user experience or user interface
Delight the customer and the users
We can not tell what will happen since the architecture is not code, we
can only “guess” whether the architecture will most likely meet the above
conditions
An Architecture Evaluating Technique
• Utilize a “profile,” which is a set of scenarios generated to fit the
characteristics of interest. (e.g.)
– Usage profile is a set of scenarios that describes the user
requirements (sometimes known as regular “business” workflow)
– Reliability profile is a set of scenarios that portrays the nonfunctional requirement of how a system behaves under adverse
situations
– Performance profile is a set of scenarios that portrays the nonfunctional requirements of how a system behaves under time limit
constraints or capacity limit constraints
–
etc.
• Each architecture alternative is evaluated by going through the
scenarios in the profile and assessing whether the architecture, if
implemented, would satisfy the profile.
Developing Profiles with “utility tree”
• A utility tree is a tree whose each sub-tree is
a “profile” and the leaves of the sub-tree are
the scenarios for that profile
1. The profiles are generated, using
SRS and some brainstorming
Utility tree
2. The scenarios within each profile
are also developed using SRS, ‘team’
Functionalities
brainstorming, and prioritizations.
Irrigation control (automatic)
3. Within each profile, keep the number
Irrigation control (manual)
of scenarios to 3 to 10
4. Each scenario should include:
Maintenance repair
- initial state
- activity flow involving actors and
Hardware adaptability
the product
- post activity state
Valve type modification
Adding new valve types
* * think of special circumstances and
non-traditional scenarios, too
Another Architecture Evaluating Technique
• Build a “prototype” of part of or the complete
software product to evaluate certain aspects
(functional and non-functional) of the
product.
– Advantages:
• Can provide measurements
• Can provide experiential feedbacks
– Disadvantages:
• Prototypes takes resources
• Prototypes takes time
Much of the prototyping and profiling techniques are aimed at evaluating
the architecture against the “basic” design principles (discussed earlier) :
- feasibility,
- adequacy,
- economy, and
- changeability
Selecting Alternatives
• How do we select the architecture from the various
alternatives ?
– Evaluate the Pros and Cons of each of the alternatives
• By Number of pros and cons
• By Weights of pros and cons
– Multi-dimensional analysis table (p. 306 of text):
• A Column of scenarios
– Weight for each scenario (use normalized weight so each is a fraction
of the total and the total is 1)
• A Column for each architectural alternative
– Rate all the scenarios for that alternative ( e.g. 1-5)
– Score the scenario by multiplying the scenario weight and the rate
– Sum the scores for that alternative
• Compare the total score for each of the architectural alternatives
Architectural Design Resolution
Architectural Design Process
Analyzed
SRS
Develop Architectural
Design Alternatives
Evaluate Architectural
Alternatives
Select Architectural
Resolution
[else ]
[selected ]
Finalize Software
Architectural Document
SAD
Finalizing The Architectural Design
• This step ensures that the selected architecture does
satisfy the various functional and non-functional
requirements (and possibly may delight the users) and
is clearly documented.
– Architectural design satisfying the “basic” design principles of:
•
•
•
•
Feasibility
Adequacy
Economy
Changeability
(from chapter 8 of text)
Think about these
for your assignment 4
– Also, The SAD document itself is
•
•
•
•
Well formed (organized)
Complete (include all the components/relationships/descriptions)
Clear (understandable by others)
Consistent (no conflicting information)
Design Review in Finalizing the SAD
• A Review is an examination and evaluation of
the work by qualified and affected
stakeholders
There are many different types of “reviews”:
1. Desk Check – by the author
2. Walkthrough – informal review by team members
3. Inspection – formal review by a trained inspection team with moderator
4. Audit – review conducted by experts who are not part of the team
5. Active Review – inspection by experts who answer specific aspects
of the design (this allows pinpoint reviews and is less
costly)
A “Formal inspection” requires 3 formal steps:
- preparation
- conducting the inspection
- rework and inspection “closeout” report