Architectural design
1 / 45

Architectural Design - PowerPoint PPT Presentation

  • Uploaded on

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. Define which of the abstraction criteria you will use

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about ' Architectural Design' - callia

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Architectural design

Architectural Design

More on layers

Architecture Reviews

Architecture Business Cycle

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

Architectural Design, ECEN 5033

Scenario v
Scenario V

Architectural Design, ECEN 5033

Implementation steps
Implementation Steps

  • Define which of the abstraction criteria you will use

  • Determine the number of abstraction levels according to your criterion

  • Name the layers and assign tasks to each of them

  • Specify the services

  • Refine the layering

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

    • Finding layers is not orderly – yo-yo development

  • Specify an interface for each layer

Architectural Design, ECEN 5033

Implementation steps continued
Implementation Steps -- continued

  • Structure individual layers

  • Specify communication between adjacent layers

    • push

    • pull

  • Decouple adjacent layers

    • top-down: J+1 knows about J; J can ignore J+1

    • bottom-up:

      • can use callbacks

      • Can decouple the upper from the lower somewhat

  • Design an error-handling strategy

Architectural Design, ECEN 5033

Known uses
Known Uses

  • Virtual Machines

  • APIs

  • Information systems – lower layer is database


    Application logic

    Domain layer


  • Some operating systems – Windows NT

Architectural Design, ECEN 5033

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.

Architectural Design, ECEN 5033

Windows nt layers
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

Architectural Design, ECEN 5033


Architectural Design, ECEN 5033


Architectural Design, ECEN 5033


How to conduct an architectural review

Architecture Business Cycle (ABC)

Architectural Design, ECEN 5033

Analyzing development qualities at the architectural level
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

Architectural Design, ECEN 5033

Architecture is a key to quality
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 ...

Architectural Design, ECEN 5033

Necessary but not sufficient
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

Architectural Design, ECEN 5033

Scenarios about quality
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

Architectural Design, ECEN 5033


  • 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

Architectural Design, ECEN 5033

Overview of saam software architecture analysis method
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*

Architectural Design, ECEN 5033

Classify scenarios
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

Architectural Design, ECEN 5033

Perform scenario evaluations
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

Architectural Design, ECEN 5033

Reveal scenario interaction
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

Architectural Design, ECEN 5033

Interaction of semantically unrelated scenarios
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*

Architectural Design, ECEN 5033

Overall evaluation
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

Architectural Design, ECEN 5033

Authors observations on saam based on their experience
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 Design, ECEN 5033

Architectural review is saam and 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

Architectural Design, ECEN 5033

Architecture review techniques
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

Architectural Design, ECEN 5033

Questioning techniques
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?”

Architectural Design, ECEN 5033

Measuring techniques
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?

Architectural Design, ECEN 5033

Systems prototypes experiments
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

Architectural Design, ECEN 5033

When should we use which
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

Architectural Design, ECEN 5033

When it s time
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

Architectural Design, ECEN 5033

Bass clements and kazman based on
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

Architectural Design, ECEN 5033


How to conduct an architectural review

Architecture Business Cycle

Architectural Design, ECEN 5033

Abc architecture business cycle
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

Architectural Design, ECEN 5033


  • 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

Architectural Design, ECEN 5033

Something somewhat tangible
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

Architectural Design, ECEN 5033

Architecture where ilities begin to set
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...

Architectural Design, ECEN 5033

Competing contradictory concerns that s why we call it engineering
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)

Architectural Design, ECEN 5033


    • 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


    • 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

Architectural Design, ECEN 5033

Developing organization
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

Architectural Design, ECEN 5033

Background and experience of architects
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)

Architectural Design, ECEN 5033

Technical environment
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

Architectural Design, ECEN 5033

Ghostly influences
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

Architectural Design, ECEN 5033

Architecture business cycle

Customer & End User

Developing Organization

Technical Environment

Architect’s Experience

Requirements (Qualities)

Architecture Business Cycle




Architectural Design, ECEN 5033

How does the architecture affect
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

Architectural Design, ECEN 5033


  • 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.

Architectural Design, ECEN 5033

Bibliography cont
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.

Architectural Design, ECEN 5033