Software EngineeringITCS 3155Fall 2008
Dr. Jamie PaytonDepartment of Computer ScienceUniversity of North Carolina at Charlotte
Nov. 11, 2008
Lecture 19Engineering Design Resolution: Generating and Evaluating
Architectures
22
Lecture Overview
TodayChapter 10• How to Generate Software Architectures• Functional decomposition• Impact of quality attributes on architectural design
Announcements
Look at Appendix B. This is the full AquaLush Case Study including SRS, Use Cases, SAD, …
Refer to this before handing in deliverable
3
Architectural Design
In architectural design, we specify:Structure -- the software program’s major parts• Responsibilities• Properties• Interfaces
Behavior -- interactions among software program’s major parts
High-level description of structure and behavior is called asoftware architecture (This is where we are…)
4
5
Generating and Improving Architectures
Generate candidate architecturesFirst step in architectural design resolution
How?Commonly used techniques• Functional decomposition• Quality attribute-based decomposition• Modifying existing architecture• Elaborate architectural style• Transform conceptual model
Techniques to Generate Architectures
1) Functional decompositionLook at the functional requirements from the SRS and USE Case documentation that we have already generated. More Later.
2) Quality attribute-based decompositionStart with the non-functional requirements to begin creating the architecture. More later.
6
Techniques to Generate Architectures
3) Modifying existing architectureDo you have access to existing system. Perhaps it can be used as the basis for creating the architecture of the new system.
This is not commonly used for a couple of reasons.1) may have no access to a similar system.2) if you do have access to an existing system, you
are probably replacing it. If that is the case, one could study it to determine what deficiencies the current system contains.
7
Techniques to Generate Architectures
4) Elaborate architectural styleDesign Patterns. A general reusable solution to a commonly occurring problem in software design. In other words, a template to solve a problem that is adapted to your specific problem…
5) Transform conceptual modelChapter 11… next week
8
9
Functional Decomposition
Define functional components that are coherent collections of functional and data requirements
Study SRS and USE CasesBrainstorm • Candidate modules• Relationships between modules
AquaLush Use Case
10
Operator
Set Irrigation Parameters
Toggle Irrigation
Manual ControlIrrigation
Make Repairs
Report FailuresMaintainer
Start up
IrrigateValve
Sensor
AquaLush Use Case
11
Operator
Set Irrigation Parameters
Toggle Irrigation
Manual ControlIrrigation
Make Repairs
Report FailuresMaintainer
Start up
IrrigateValve
Sensor
User interface
Irrigation Control
Monitor and repair
12
AquaLush Functional Decomposition
AquaLush prioritized requirementsConfigure program at startupControl irrigation• Manually• Automatically
Provide user interfaceAllow users to monitor and repair system
13
Functional Decomposition Example:AquaLush Components
User InteractionIrrigation Control
Monitor and Repair
FunctionalComponent
Legend
Startup We are displaying all our major components with simple boxes along with a legend.
What are we missing?
14
Functional Decomposition Example:AquaLush Component Interactions
Who communicates with each other? Now we are getting there. We are using a simple box and line diagram.
Still not completely finished.
15
Functional Decomposition Example:AquaLush Data Storage (Option 1)
Functional Component
LegendInteracts With
AquaLush State
Data Store
AquaLush Configuration
User Interaction
Irrigation ControlMonitor and Repair
Startup
x Reads & Writes y
x Reads y
x
x
y
y
The configuration data must be stored in permanent storage. Failed/repaired parts are also stored.
How does Irrigation Control know when the system changes?
Answer: Polling
16
Functional Decomposition Example:AquaLush Data Storage (Option 2)
Functional Component
LegendInteracts With
AquaLush State
Data Store
AquaLush Configuration
User Interaction
Irrigation ControlMonitor and Repair
Startup
x Reads & Writes y
x Reads y
x
x
y
y
In this design “Monitor and Repair” notifies “Irrigation Control” when a change is made.
“Irrigation Control” reads data store for current state.
There are tradeoffs here!!!
Increased Coupling!!!
17
Quality Attribute-based Decomposition
Define modules and relationships to satisfy quality attributes
Add modules and relationships later to meet functional and data needs
18
Quality Attributes
We’ve heard of quality attributes before……but we called them Non-functional requirements
Classes of Quality AttributesDevelopment attributesOperational attributes
Define modules and relationships to satisfy non-functional requirements
Add modules and relationships later to meet functional and data needs
19
Quality Attributes
Also known as Non-functional requirement…
A quality attribute is a characteristic or property of a software product independent of its function that is important in satisfying stakeholder needs.
A quality attribute is a characteristic or property of a software product independent of its function that is important in satisfying stakeholder needs.
Development Attributes
Applies to the Developer:
Maintainability –Correctability – fixing bugs as they appear Improvability – adding functionalityPortability – moving to another platformModifiability – changing functionality
Reusability –Are we creating modules that may be used by other systemsIs it a priority?
20
Development Attributes
Testability –Is the design done in a way that facilitates the testing process
What attribute helps in creating a system that is easy to test?
Answer: Low coupling
21
22
Development Quality Attributes
MaintainabilityDegree to which a product can be corrected, improved, or ported• Specific maintainability attributes
ModifiabilityPortability
ReusabilityDegree to which a product’s parts can be reused in another product or future versions
TestabilityDegree to which a product’s associated requirements can be validated through testing
Operational Attributes
Applies to the User, Customer and Developer:Performance
Metric –Latency – startup time OR time delay between the moment something is initiated, and the moment one of its effects beginsor becomes detectableMemory usageThroughput - the amount of work that a computer does in a given time period.
ISDN has a latency of about 10ms. Its thoughput may only be twice that of a modem, but its latency is ten times better, and that's the key reason why browsing the web over an ISDN link feels so much better than over a modem.
23
24
Operational Quality Attributes
AvailabilityReadiness for useMetric: downtime
ReliabilityBehaves according to requirements under normal operating conditionsMetric: mean time to failure
SecurityResistance to harm or cause harm by hostile acts or influences
25
Architectural Decisions toAddress Quality Attributes
PerformanceLocalize time-intensive operations and optimize minimize communicationsUse large rather than fine-grain components
SecurityUse a layered architecture with critical assets in the inner layers
SafetyLocalize safety-critical features in a small number of sub-systems
AvailabilityInclude redundant components and mechanisms for fault tolerance
MaintainabilityUse fine-grain, replaceable components
26
Architectural Conflicts
Large-grain components improves performance reduces maintainability
Redundant data improves availability makes security more difficultMay decrease performance
Localizing safety-related featuressimplifies securitymore communication so degraded performance
27
AquaLush Quality Attribute-based Decomposition
AquaLush prioritized non-functional requirements1. Reusability
• Main irrigation software components must be reused in future versions
2. Modifiability• Must accommodate changes in irrigation strategy
3. Hardware adaptability• Must work with various valve types, sensors, displays, keypads,
screen buttons
4. Reliability• We can trust the system to perform accurately
28
Quality Attribute Decomposition Example:Addressing Reusability
Reusability requirements can be met by making parts highly modular
Small, cohesive partsParts hide informationLoosely coupled to other parts
Irrigation module must be reusableCreate a separate irrigation module
29
Quality Attribute Decomposition Example:Addressing Modifiability
Irrigation Control module must have modifiable strategies
Can also be met by making Irrigation Control module highly modular• Can replace or modify individual strategies
Module
Legend
Part Of
Irrigation Control
Manual IrrigationControl
AutomaticIrrigation Control
30
Quality Attribute Decomposition Example:Addressing Hardware Adaptability
A standard way to achieve hardware adaptabilityuse a device interface module…
… that contains virtual devices
A virtual device is a software simulation of, or interface to, a real
hardware device or system.
A virtual device is a software simulation of, or interface to, a real
hardware device or system.
31
Virtual Device Characteristics
Simulates an “ideal” device thatDoes exactly one job completely (cohesion)Has a simple, consistent, complete interface (simplicity)Is loosely coupled to the rest of the program (coupling)Hides its implementation (information hiding)Never changes (stability)
If physical device changes, only implementation of virtual device changes
Not the virtual device interface!Typically realized as a family of components for different real devices or systems
A device interface module, in our case
Virtual Device
What is this is an example of?
Design Pattern!!!
The “adapter” design pattern
32
33
Quality Attribute Decomposition Example:Addressing Hardware Adaptability
34
Quality Attribute Decomposition Example:Addressing Reliability
One strategy for making systems reliable is to make modules small and interactions simple
Already the case here!
35
Quality Attribute Decomposition Example:Addressing Missing Requirements
Module
Legend
Interacts With
Part Of
Device Interface
Valve
Sensor
Display
Keypad
Screen Buttons
Irrigation Control
Manual Irrigation Control
Automatic Irrigation Control
User Interface
Need a user interface!
The 2 Architectures:
36
Module
Legend
Interacts With
Part Of
Device Interface
Valve
Sensor
Display
Keypad
Screen Buttons
Irrigation Control
Manual Irrigation Control
Automatic Irrigation Control
User Interface
37
Generating Architectures
Commonly used techniquesFunctional decompositionQuality attribute-based decompositionTransform conceptual model (next week)Modifying existing architecture (we don’t have one)Elaborate architectural style (soon)
38
Architectural Design Process
We’ve generated…Now, how do we:
Improve?Evaluate?Select?
Architectural Design ProcessSRS : ProblemSAD : Solution
SRS
[adequate architecture]
[else]
Analyze SRS
Generate/ImproveCandidate Architectures
Evaluate CandidateArchitectures
Select Architecture
Finalize Architecture SAD
39
Improving Architectural Alternatives
Combine AlternativesCombine the best features of two or more alternatives• Example: Combine quality attribute generated with function
decomposition generated alternatives
Impose an Architectural StyleModify an architecture that almost fits a style so that it does fit the style
Apply Mid-Level Design PatternsModify an architecture to take advantage of mid-level design patterns
40
Evaluating Architectural Alternatives
Two primary techniquesScenariosPrototypes
Techniques may be complementary
41
Evaluating and Selecting with Scenarios
Walk through each scenarioJudge how well a design alternative supports the scenarioRecord a judgment for each scenario
Use a selection technique to choose an alternativePros and cons (compare strengths and weaknesses)Multi-dimensional ranking• Scoring matrix
42
Creating Profiles and Scenarios
A utility tree is a tree whose sub-trees are profiles and whose leaves are scenarios
Label the root “utility”Add children with profile names that reflect product requirementsFill in scenarios for each profile• Brainstorm scenarios• Rationalize the list• Weight each scenario• Eliminate low-weight scenarios until each profile has 3 to 10
leavesWrite scenario descriptions
43
Example Utility Tree
AquaLush Utility TreeProfiles correspond to non-functional and functional requirements!
Importance of Scenario (weight)
Functional requirements
Non-functional requirements
Scoring Matrix
Quantify the scenario values (H = 3, M = 2, L = 1)
Normalize so that the sum of the scenario weights are 1. Do this by dividing the scenario values by the sum of the scenario weights.
Create the scoring matrix for all candidate architectures
See Fig. 10-2-3 (p. 306)
44
Scenario
Add a Valve type – A developer modifies the AquaLush source code and design documents so that AquaLush supports a new type of valve. The developer completes the process in two days.
How do the two designs handle this scenario?
45
46
Evaluating and Selecting with Prototypes
Prototypes may be built to test out design alternativesScenario walkthroughs may give rise to a need for prototypingPrototypes provide the factual basis for selection using
Pros and cons (examine strength and weaknesses)Multi-dimensional ranking (scoring matrix)
Disadvantage - expensive
47
Summary
Generating Software Architectural DesignsUsing:
1) Functional Requirements2) Quality Attributes