Transcript Document

Architectural Design
More on layers
Architecture Reviews
Architecture Business Cycle
ECEN 5543 / CSCI 5548 SW Eng of Standalone
Programs, University of Colorado, Boulder
October 20, 2005
Architectural Design, ECEN 5033
1
Scenario V
October 20, 2005
Architectural Design, ECEN 5033
2
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
October 20, 2005
Architectural Design, ECEN 5033
3
Implementation Steps -- continued
7. Structure individual layers
8. Specify communication between adjacent layers
1. push
2. pull
9. Decouple adjacent layers
1. top-down: J+1 knows about J; J can ignore J+1
2. bottom-up:
1. can use callbacks
2. Can decouple the upper from the lower somewhat
10. Design an error-handling strategy
October 20, 2005
Architectural Design, ECEN 5033
4
Known Uses
• Virtual Machines
• APIs
• Information systems – lower layer is
database
Presentation
Application logic
Domain layer
Database
• Some operating systems – Windows NT
October 20, 2005
Architectural Design, ECEN 5033
5
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.
October 20, 2005
Architectural Design, ECEN 5033
6
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
October 20, 2005
Architectural Design, ECEN 5033
7
Benefits
October 20, 2005
Architectural Design, ECEN 5033
8
Liabilities
October 20, 2005
Architectural Design, ECEN 5033
9
Overview
How to conduct an architectural review
Architecture Business Cycle (ABC)
October 20, 2005
Architectural Design, ECEN 5033
10
Analyzing Development Qualities at the
Architectural Level
The Cat only grinned when it saw Alice ... “Cheshirepuss,” 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
October 20, 2005
Architectural Design, ECEN 5033
11
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 ...
October 20, 2005
Architectural Design, ECEN 5033
12
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
October 20, 2005
Architectural Design, ECEN 5033
13
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
October 20, 2005
Architectural Design, ECEN 5033
14
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
October 20, 2005
Architectural Design, ECEN 5033
15
Overview of SAAM
Software 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*
October 20, 2005
Architectural Design, ECEN 5033
16
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
October 20, 2005
Architectural Design, ECEN 5033
17
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
October 20, 2005
Architectural Design, ECEN 5033
18
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
October 20, 2005
Architectural Design, ECEN 5033
19
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*
October 20, 2005
Architectural Design, ECEN 5033
20
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
October 20, 2005
Architectural Design, ECEN 5033
21
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
October 20, 2005
Architectural Design, ECEN 5033
22
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
October 20, 2005
Architectural Design, ECEN 5033
23
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
October 20, 2005
Architectural Design, ECEN 5033
24
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?”
October 20, 2005
Architectural Design, ECEN 5033
25
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?
October 20, 2005
Architectural Design, ECEN 5033
26
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
October 20, 2005
Architectural Design, ECEN 5033
27
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
October 20, 2005
Architectural Design, ECEN 5033
28
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
October 20, 2005
Architectural Design, ECEN 5033
29
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
October 20, 2005
Architectural Design, ECEN 5033
30
Overview
How to conduct an architectural review
Architecture Business Cycle
October 20, 2005
Architectural Design, ECEN 5033
31
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
October 20, 2005
Architectural Design, ECEN 5033
32
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
October 20, 2005
Architectural Design, ECEN 5033
33
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
October 20, 2005
Architectural Design, ECEN 5033
34
Architecture – where “-ilities” begin to “set”
• 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; some are exposed...
October 20, 2005
Architectural Design, ECEN 5033
35
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)
October 20, 2005
Architectural Design, ECEN 5033
36
• 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
performance
reliability
availability
ease of modification
October 20, 2005
- platform compatibility
- memory utilization
- network usage
- security
- interoperability with other systems
Architectural Design, ECEN 5033
37
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
October 20, 2005
Architectural Design, ECEN 5033
38
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)
October 20, 2005
Architectural Design, ECEN 5033
39
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
October 20, 2005
Architectural Design, ECEN 5033
40
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
October 20, 2005
Architectural Design, ECEN 5033
41
Architecture Business Cycle
Customer & End User
Architecture
Developing Organization
Technical Environment
Archi
Architect’s Experience
System
Requirements
(Qualities)
October 20, 2005
Architectural Design, ECEN 5033
42
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
October 20, 2005
Architectural Design, ECEN 5033
43
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, McGrawHill, ISBN 0-07-019902-7 – excellent, compact
compendium of historical software engineering.
October 20, 2005
Architectural Design, ECEN 5033
44
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-13629155-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-TR025, 1996.
October 20, 2005
Architectural Design, ECEN 5033
45