october 20, 2005architectural design, ecen 50331 architectural design more on layers architecture...

October 20, 2005 Architectural Design, ECEN 5033 1

Architectural Design

More on layers

Architecture Reviews

Architecture Business Cycle

ECEN 5543 / CSCI 5548 SW Eng of Standalone Programs, University of Colorado, Boulder


Scenario V


Implementation Steps

1. Define which of the abstraction criteria you will use

2. Determine the number of abstraction levels according to your criterion

3. Name the layers and assign tasks to each of them

4. Specify the services

5. Refine the layering

1. repeat steps 1-4 until natural, stable layering evolves

2. Finding layers is not orderly – yo-yo development

6. Specify an interface for each layer


Implementation Steps -- continued

7. Structure individual layers8. Specify communication between adjacent layers

1. push2. pull

9. Decouple adjacent layers1. top-down: J+1 knows about J; J can ignore J+12. bottom-up:

1. can use callbacks2. Can decouple the upper from the lower somewhat

10. Design an error-handling strategy


Known Uses

• Virtual Machines• APIs• Information systems – lower layer is

databasePresentationApplication logicDomain layerDatabase

• Some operating systems – Windows NT


Windows NT

• Structured according to Microkernel pattern (also described in POSA)

• The NT Executive component corresponds to the microkernel component of the Microkernel pattern.

• The NT Executive is a Relaxed Layered System which is a variant of Layers.– Relaxed Layered – less restrictive

about the relationship between layers. A layer may use the services of all layers below.


Windows NT layers• System services – interface between

subsystems and the NT Executive• Resource Management Layer

– Object Manager, Security Reference Monitor, Process Manager, I/O Manager, Virtual Memory Manager, Local Procedure Calls

• Kernel – basic functions such as interrupt and exception handling, thread scheduling and dispatching

• HAL (Hardware Abstraction Layer) – hides hardware differences between machines of different processor families

• Hardware


Benefits


Liabilities


Overview

How to conduct an architectural review

Architecture Business Cycle (ABC)


Analyzing Development Qualities at the Architectural Level

The Cat only grinned when it saw Alice ... “Cheshire-puss,” she began, rather timidly ... “Would you tell me, please, which way I ought to go from here?”

“That depends a good deal on where you want to go to,” said the Cat.

“Oh, I don’t much care where –” said Alice.

“Then it doesn’t matter which way you go,” said the Cat.

“—so long as I get somewhere,” said Alice.

“Oh, you’re sure to do that,” said the Cat, “if you only walk long enough.”

Lewis Carroll, Alice’s Adventures in Wonderland


Architecture is a key to quality

• Important role: early handle for achieving a system’s quality attributes

• Specific quality goals are manifested in architectural decisions

• Analysis of an architecture can (and should) be performed to evaluate it with respect to how well suited it is for its intended purpose

• Analysis is only useful in the presence of clearly articulated goals

• Analyzing an architecture without knowing the criteria for “goodness” is like ...


Necessary but not sufficient

• An architecture cannot guarantee functionality or quality– Downstream design, implementation, testing,

management decisions always have an opportunity to undermine ...

• Architecture-based assessment evaluates the ability of the architecture to support the desired qualities.

• Necessary to refine the architecture into an implementation that preserves those qualities


Scenarios about Quality• An architecture should be evaluated on basis of whatever

is needed to answer questions about the desired, stated qualities

• Probably will start with whatever-description-is-available; if other views are needed, that will become clear

• Some want to analyze architectures w.r.t. quality attributes using words such as maintainability, security, performance– convenient way to (fail to) describe desired attributes– most are too complex & vague to evaluate on a linear

scale*• Quality attributes only have meaning in context – hence

the notion of quality scenarios


Scenarios• Brief description of a single interaction of a stakeholder

within the system• Similar to use cases

– Use cases focus on runtime behavior with the stakeholder who is a user

– Scenarios include other interactions with the system, too• e.g. maintainer carrying out a modification• e.g. tester running a test suite

• Are a means to characterize how well an architectural design responds to the demands on it

• Scenario serves as a representative for a class of scenarios• RHD observation: A scenario executes an imaginary

prototype


Overview of SAAMSoftware Architecture Analysis Method

• from the Bass, Clements, Kazman book, Software Architecture in Practice

• Develop scenarios• Describe candidate architecture in some notation that

– covers computation and data components and all relevant connections

– Description of how system behaves over time• Classify scenarios as direct and indirect*• Perform scenario evaluations*• Reveal scenario interaction*• Overall evaluation*


Classify scenarios• Direct

– System supports the scenario with no modification to the system

• Indirect– Not directly supported; requires a system change

that can be represented architecturally• How one or more components performs an activity

• Addition of a component in order to perform the activity

• addition of a connection between existing components

• combination

• Note: useful to evaluate competing acquisitions


Perform Scenario Evaluations• For each indirect scenario

– the changes that are necessary in order to support the scenario must be listed

– estimate the cost of each change (weighting)• Output – summary table that lists all scenarios, direct

and indirect, with set of changes needed for each indirect scenario and coarse-grained weighting of the difficulty

• Careful: a monolithic system can score quite well – each indirect scenario requires a change to only one component – Next step is a counterbalance to that


Reveal Scenario Interaction

• Two indirect scenarios interact in a component when they both require changes to that component

• Interaction exposes the allocation of functionality to the product’s design


Interaction of semantically unrelated scenarios

• Explicitly shows which components compute semantically unrelated functions

• Reveals potentially poor separation of concerns• High interaction among fundamentally different

scenarios – corresponds to low cohesion– suggests high structural complexity– predictive of high number of defects in final product*


Overall Evaluation

• If architectures are being compared– a weight assigned to each scenario– a weight assigned to the scenario interactions re

relative importance– determine an overall ranking of the candidate

architectures• Assigning weights is subjective and needs to

involve the stakeholders


Authors’ Observations on SAAM, based on their experience

• Illuminates the management of change and support of different system stakeholders

• Relies heavily on experience and understanding of the people doing the analysis

• The evaluation will be only as good as the information available to the evaluators

• Relies on scenarios that explicit articulate the stakeholders’ primary requirements that can be satisfied by an architecture

• When done? Out of patience, out of money, or don’t expect a new scenario to reveal more


Architectural Review is SAAM and more

• Authors suggest that, because of the ABC, institutionalizing architectural reviews such as the following will have an impact on the organization and its culture (and vice versa)

• Why bother– Costs*: staff time, organizational overhead,

consumption of senior designers for review teams– Benefits*: financial, forced preparation, early

detection of problems, validation of requirements, architecture improvement, decreased risk


Architecture Review Techniques

• Category 1: those that generate qualitative questions to ask of an architecture

• Category 2: those that suggest quantitative measurements to made on an architecture

• The questioning techniques – used to evaluate an architecture for any given quality– but do not directly provide a means for

answering the questions• The measuring techniques – used to answer

specific questions re specific qualities


Questioning Techniques

• Scenarios – SAAM – product-specific interaction between a stakeholder and a system– also useful for communicating with non-technical

stakeholders• Questionnaire-based – General and relatively open

questions applying to all architectures– “Are all user-interface aspects of the system

separated from functional aspects?”• Checklist-based – focused on domain-specific qualities

– In a real-time system: “Is the system writing the same data multiple times to disk”

– “Does system handle peak and average loads?”


Measuring Techniques

• Metrics – quantitative interpretations placed on observable measurements of the architecture– e.g. fan in and fan out of components

• Reviews using measuring techniques need to focus on– the results of the measurement-metric– the assumptions under which the technique was

used– e.g. Coupling and cohesion metrics make

assumptions about the types of functions embodied in the components – are these assumptions valid?


Systems, Prototypes, Experiments

• Generally, detailed prototypes just for review purposes are probably too costly

• If doing iterative development– At start of new iteration, develop scenarios

incorporating new features– Reveal what has to change in existing

architecture by “walk-through” or by execution of previous iteration which is a kind of prototype


When Should We Use Which?

• If the development process produces simulations or integrated iterations, use them when appropriate.

– Specifically, performance questions can be answered with an increasing accuracy in iterative development; not just by running partially developed product but also by analyzing the actual emerging architecture

• Questionnaires and checklists are developed over time

– If organization is new to architectural reviews, use scenarios

– Put the scenarios into a database so they can be reference when developing questionnaires and checklists later

• Even if questionnaires and checklists exist, develop scenarios for stakeholder interests not covered by them


When “It’s Time!”• When a group really wants to conduct a review,

Software Architecture in Practice has a thorough but succinct set of guidelines and steps to follow re– preconditions– project representatives– review team– organizational expectations– review preparation– review activities– review output


Bass, Clements, and Kazman Based on...• Recommended Best Industrial Practice for

Software Architectural Evaluation– derived from series of workshops organized by

the authors, attended by 8 industrial and consulting organizations

• Notion of active design review described by Parnas (again!) in 1985– An active review is one in which the

participants take an active part by using the documentation to answer specific questions prepared in advance

31Architectural Design, ECEN 5033October 20, 2005

Overview

How to conduct an architectural review



ABC = Architecture Business Cycle• Where do architectures come from??

– Architectures are influenced by • system stakeholders

• technical factors

• organizational factors

– Architecture affects• business goals

• product requirements

• practitioners’ experience

• fielded (installed) systems

• This is a cycle that a business can manage


Stakeholders• Developing organization’s management

– low cost, keep people employed• Marketing

– neat features (sum of all sales targets’ desires), short time to market, low cost, parity with competing products, high margins

• End User– Product behavior, performance, security, reliability,

all the functions *I* want• Maintenance Organization

– Easy to modify• Customer

– Low cost, timely delivery, infrequent change


Something somewhat tangible

• Architecture is an early artifact that enables the priorities among competing concerns to be analyzed– If there is no Vision Document, the architecture

may be the first such artifact– Note that typical use cases don’t

• Architecture is the first artifact to manifest the concerns as system qualities– System’s response to these qualities is the result

of structural trade-offs made and (probably) not documented by the architects


• Relative costs of different concerns and the architectural alternatives that support them become more concrete when design begins

• Architecture is the summary result of business and technical decisions

or else• Architecture is the summary result of a failure to

consider the business and technical decisions together

• Every architecture makes a statement – some statements are designed;

Architecture – where “-ilities” begin to “set”

some are exposed...


Competing Contradictory Concerns(that’s why we call it engineering)

• Architects are influenced by– Requirements for product itself– Structure and goals of the developing organization– Available technical environment– Own background and experience (or lack)


• CUSTOMER

– pays for the development or purchase

– specifies requirements that ensure usability (we hope) to the end user

– may be more concerned with cost than usability if a compromise must be made

• END USERS

– use it

– many different categories (see operational profiles): input givers, administrators, output receivers

– Acceptability involves - behavior - platform compatibility

- performance - memory utilization

- reliability - network usage

- availability - security

- ease of modification - interoperability with other systems


Developing Organization• Immediate business

– existing architectures and products

– proposed system may be “next” in a product family so cost estimates assume high degree of reuse

• Long-term business

– desire an infrastructure to pursue strategic goals

– this product seen as the way to fund that

• Organizational structure

– For example, lack of certain expertise may require design that allows a subsystem to be subcontracted

– 4 strong personalities = 4 major components

– Or ... groups responsible for maintaining individual portions of the product family want the next generation product to require those groups


Background and Experience of Architects

• If a certain approach produced good results in the past, first inclination is to try that again even if factors have changed

• If a prior experience was a disaster, hard to muster the courage to try it again

• Architectural choices may also come from– the architect’s education and training– exposure to successful styles– exposure to systems that worked well or didn’t– desire to experiment (heh-heh)


Technical Environment

• Special case of the architect’s background and experience

• The technical environment that is current (popular) when the architecture is designed will influence that architecture

• Might (mind you, I said might!) include– industry standard practices– software engineering techniques prevalent in

the architect’s professional community


Ghostly influences• Often not consciously understood• Rarely fully articulated• Critical to identify and actively engage the

stakeholders to solicit their needs and expectations as early as possible– discover constraints and additional

requirements– avoid false starts by managing expectations and

negotiating priorities– Vision document helps to reveal and engage– Architectural reviews also engage– Iterative development helps to engage


Customer & End User

Developing Organization

Technical Environment

Architect’s Experience

Requirements (Qualities)


Architecture

Archi

System


How does the architecture affect ...

• the structure of the developing organization• the enterprise goals• customer requirements for the next system• the architect’s experience that influences next

system• the technical environment, the software

engineering culture


Bibliography

• Software Architecture in Practice, Len Bass, Paul Clements, Rick Kazman, Addison Wesley, ISBN 0-201-19930-0 – includes several case studies and the original chapters on architecture analysis that our text uses in chapter 32.

• Software Engineering Concepts, Richard Fairley, McGraw-Hill, ISBN 0-07-019902-7 – excellent, compact compendium of historical software engineering.


Bibliography (cont.)• Pattern-Oriented Software Architecture, A System of

Patterns, Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, Michael Stal, Wiley & Sons, 1996, ISBN 0 471 95869 7 – often referred to as the POSA book.

• Object-Oriented Software Construction, 2nd edition, Bertrand Meyer, Prentice Hall PTR, 1997, ISBN 0-13-629155-4 – excellent sections on the criteria of object orientation and how to get there; well (and humorously) written and thorough.

• “Recommended Best Industrial Practice for Software Architecture Evaluation.” G. Abowd, L. Bass, P. Clements, R. Kazman, L. Northrop, and A. Zaremski., SEI, Carnegie Mellon University, Technical Report CMU/SEI-96-TR-025, 1996.

october 20, 2005architectural design, ecen 50331 architectural design more on layers architecture...

Documents

architectural design

layer slide

architectural level

wonderland slide

boulder slide

adjacent layers

variant of layers

scenario v slide