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 Architectural Design, ECEN 5033

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 • 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 • Virtual Machines • APIs • Information systems – lower layer is database Presentation Application logic Domain layer Database • Some operating systems – Windows NT Architectural Design, ECEN 5033

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

Benefits Architectural Design, ECEN 5033

Liabilities Architectural Design, ECEN 5033

Overview How to conduct an architectural review Architecture Business Cycle (ABC) Architectural Design, ECEN 5033

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

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 Architectural Design, ECEN 5033

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

Overview How to conduct an architectural review Architecture Business Cycle Architectural Design, ECEN 5033

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

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 Architectural Design, ECEN 5033

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” • 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) • 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

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 Architectural Design, ECEN 5033

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

Customer & End User Developing Organization Technical Environment Architect’s Experience Requirements (Qualities) Architecture Business Cycle Architecture Archi System Architectural Design, ECEN 5033

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

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. Architectural Design, ECEN 5033

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

Architectural Design