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