Presentation is loading. Please wait.

Presentation is loading. Please wait.

October 20, 2005Architectural Design, ECEN 50331 Architectural Design More on layers Architecture Reviews Architecture Business Cycle ECEN 5543 / CSCI.

Similar presentations


Presentation on theme: "October 20, 2005Architectural Design, ECEN 50331 Architectural Design More on layers Architecture Reviews Architecture Business Cycle ECEN 5543 / CSCI."— Presentation transcript:

1 October 20, 2005Architectural Design, ECEN 50331 Architectural Design More on layers Architecture Reviews Architecture Business Cycle ECEN 5543 / CSCI 5548 SW Eng of Standalone Programs, University of Colorado, Boulder

2 October 20, 2005Architectural Design, ECEN 50332 Scenario V

3 October 20, 2005Architectural Design, ECEN 50333 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

4 October 20, 2005Architectural Design, ECEN 50334 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

5 October 20, 2005Architectural Design, ECEN 50335 Known Uses Virtual Machines APIs Information systems – lower layer is database Presentation Application logic Domain layer Database Some operating systems – Windows NT

6 October 20, 2005Architectural Design, ECEN 50336 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.

7 October 20, 2005Architectural Design, ECEN 50337 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

8 October 20, 2005Architectural Design, ECEN 50338 Benefits

9 October 20, 2005Architectural Design, ECEN 50339 Liabilities

10 October 20, 2005Architectural Design, ECEN 503310 Overview How to conduct an architectural review Architecture Business Cycle (ABC)

11 October 20, 2005Architectural Design, ECEN 503311 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

12 October 20, 2005Architectural Design, ECEN 503312 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...

13 October 20, 2005Architectural Design, ECEN 503313 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

14 October 20, 2005Architectural Design, ECEN 503314 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

15 October 20, 2005Architectural Design, ECEN 503315 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

16 October 20, 2005Architectural Design, ECEN 503316 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*

17 October 20, 2005Architectural Design, ECEN 503317 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

18 October 20, 2005Architectural Design, ECEN 503318 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

19 October 20, 2005Architectural Design, ECEN 503319 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

20 October 20, 2005Architectural Design, ECEN 503320 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*

21 October 20, 2005Architectural Design, ECEN 503321 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

22 October 20, 2005Architectural Design, ECEN 503322 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

23 October 20, 2005Architectural Design, ECEN 503323 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

24 October 20, 2005Architectural Design, ECEN 503324 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

25 October 20, 2005Architectural Design, ECEN 503325 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?”

26 October 20, 2005Architectural Design, ECEN 503326 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?

27 October 20, 2005Architectural Design, ECEN 503327 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

28 October 20, 2005Architectural Design, ECEN 503328 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

29 October 20, 2005Architectural Design, ECEN 503329 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

30 October 20, 2005Architectural Design, ECEN 503330 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

31 October 20, 2005Architectural Design, ECEN 503331 Overview How to conduct an architectural review Architecture Business Cycle

32 October 20, 2005Architectural Design, ECEN 503332 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

33 October 20, 2005Architectural Design, ECEN 503333 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

34 October 20, 2005Architectural Design, ECEN 503334 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

35 October 20, 2005Architectural Design, ECEN 503335 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...

36 October 20, 2005Architectural Design, ECEN 503336 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)

37 October 20, 2005Architectural Design, ECEN 503337 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

38 October 20, 2005Architectural Design, ECEN 503338 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

39 October 20, 2005Architectural Design, ECEN 503339 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)

40 October 20, 2005Architectural Design, ECEN 503340 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

41 October 20, 2005Architectural Design, ECEN 503341 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

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

43 October 20, 2005Architectural Design, ECEN 503343 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

44 October 20, 2005Architectural Design, ECEN 503344 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.

45 October 20, 2005Architectural Design, ECEN 503345 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, 2 nd 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.


Download ppt "October 20, 2005Architectural Design, ECEN 50331 Architectural Design More on layers Architecture Reviews Architecture Business Cycle ECEN 5543 / CSCI."

Similar presentations


Ads by Google