Presentation is loading. Please wait.

Presentation is loading. Please wait.

© 1998 by Carnegie Mellon University Intro - page 1 Version 1.1 1 The Architecture Business Cycle Paul C. Clements Software Engineering Institute Carnegie.

Similar presentations


Presentation on theme: "© 1998 by Carnegie Mellon University Intro - page 1 Version 1.1 1 The Architecture Business Cycle Paul C. Clements Software Engineering Institute Carnegie."— Presentation transcript:

1 © 1998 by Carnegie Mellon University Intro - page 1 Version The Architecture Business Cycle Paul C. Clements Software Engineering Institute Carnegie Mellon University Pittsburgh, PA Sponsored by the U.S. Department of Defense © 1998 by Carnegie Mellon University Carnegie Mellon University Software Engineering Institute

2 © 1998 by Carnegie Mellon University Intro - page 2 Version 1.1 The Importance of Architecture To a project vehicle for stakeholder communication key to achieving system qualities basis for development project structure To an organization can be reused from project to project forms a basis for product lines is a foundation for new market entry To a community standard models emerge for mature domains is a basis for component markets

3 © 1998 by Carnegie Mellon University Intro - page 3 Version 1.1 Definition of Software Architecture The software architecture of a program or computing system is the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships among them.

4 © 1998 by Carnegie Mellon University Intro - page 4 Version 1.1 Communication Vehicle Architecture provides a common frame of reference in which competing interests may be exposed and negotiated. negotiating requirements with users keeping the customer informed of progress and cost implementing management decisions and allocations

5 © 1998 by Carnegie Mellon University Intro - page 5 Version 1.1 Result of Early Design Decisions -1 An architecture defines constraints on an implementation. implementations must conform to architecture (global) resource allocation decisions constrain implementations of individual components system trade-offs are in the architectural realm

6 © 1998 by Carnegie Mellon University Intro - page 6 Version 1.1 Result of Early Design Decisions -2 The architecture dictates organizational structure for development/maintenance efforts. Examples include division into teams units for budgeting, planning basis of work breakdown structure organization for documentation organization for CM libraries basis of integration basis of test plans, testing basis of maintenance Once decided, architecture is extremely hard to change!

7 © 1998 by Carnegie Mellon University Intro - page 7 Version 1.1 Result of Early Design Decisions -3 Architecture permits/precludes achievement of a system’s desired quality attributes. For example: If you desireExamine performanceinter-component communication modifiability component responsibilities security inter-component communication, specialized components (e. g., kernels) scalability localization of resources ability to subset inter-component usage reusabilityinter-component coupling The architecture influences qualities, but does not guarantee them.

8 © 1998 by Carnegie Mellon University Intro - page 8 Version 1.1 Result of Early Design Decisions -4 An architecture helps users reason about and manage change (about 80% of effort in systems occurs after deployment). Architecture divides all changes into three classes. local: modifying a single component non-local: modifying several components architectural: modifying the gross system topology, communication, and coordination mechanisms A good architecture is one in which the most likely changes are also the easiest to make.

9 © 1998 by Carnegie Mellon University Intro - page 9 Version 1.1 Reusable Model Less is more: It pays to restrict the vocabulary of design alternatives. Architectural styles serve as that restricted vocabulary of design alternatives. Working with known styles reduces learning time enhances communication takes advantage of known style properties (e.g., performance, security, reliability)

10 © 1998 by Carnegie Mellon University Intro - page 10 Version 1.1 Where do architectures come from? Architectures are influenced by stakeholders of the system(s) being built technical and organizational factors architect’s background

11 © 1998 by Carnegie Mellon University Intro - page 11 Version 1.1 Stakeholders Customer: wants low cost, quick delivery, … End user: wants functionality, usability,... Maintainer: wants modifiability,... Developer: wants understandability, simple interfaces,... Developing organization: amortizing infrastructure, employing personnel, low cost,......

12 © 1998 by Carnegie Mellon University Intro - page 12 Version 1.1 Stakeholders of a System Marketing stakeholder Behavior, performance, security, reliability! Low cost, keeping people employed, leveraging existing corporate assets! Low cost, timely delivery, not changed very often! Modifiability! Neat features, short time to market, low cost, parity with competing products! Ohhhhh... Architect Development organization’s management stakeholder End user stakeholder Maintenance organization stakeholder Customer stakeholder

13 © 1998 by Carnegie Mellon University Intro - page 13 Version 1.1 Technical Environment Current trends: today’s information system will likely employ a database management system Web browser for delivery and distribution across platforms This was not true 10 years ago. Available technology: decisions on using a centralized or decentralized system depend on processor cost and communication speed; both are changing quantities.

14 © 1998 by Carnegie Mellon University Intro - page 14 Version 1.1 Architect’s Background Architects develop their mindset from their past experiences. Prior good experiences will lead to replication of prior designs. Prior bad experiences will be avoided in the new design.

15 © 1998 by Carnegie Mellon University Intro - page 15 Version 1.1 Summary: Influences on the Architect Architect’s influences Stakeholders Development organization Technical environment Architect’s experience Requirements Architecture System Architect(s)

16 © 1998 by Carnegie Mellon University Intro - page 16 Version 1.1 Factors Influenced by Architectures Structure of the development organization Enterprise goals of the development organization Customer requirements Architect’s experience Technical environment The architecture itself

17 © 1998 by Carnegie Mellon University Intro - page 17 Version 1.1 Architecture Influences the Development Organization Structure Short term: Work units are organized around architectural units for a particular system under construction. Long term: When company constructs collection of similar systems, organizational units reflect common components e.g., operating system unit or database unit especially true in product line organization

18 © 1998 by Carnegie Mellon University Intro - page 18 Version 1.1 Architecture Influences the Development Organization’s Enterprise Goals Development of a system may establish a foothold in the market niche. Being known for developing particular kinds of systems becomes a marketing device. Architecture becomes a leveraging point for additional market opportunities and networking.

19 © 1998 by Carnegie Mellon University Intro - page 19 Version 1.1 Architecture Influences Customer Requirements Knowledge of similar fielded systems leads customers to ask for particular features. Customers will alter their requirements on the basis of the availability of existing systems.

20 © 1998 by Carnegie Mellon University Intro - page 20 Version 1.1 Architecture Influences the Architect’s Experience and Technical Environment Creation of a system affects the architect’s background. Occasionally, a system or an architecture will affect the technical environment. the WWW for information systems the three-tier architecture for database systems

21 © 1998 by Carnegie Mellon University Intro - page 21 Version 1.1 A Cycle of Influences Architectures and organizations influence each other. Influences to and from architectures form a cycle. An organization can manage this cycle to its advantage.

22 © 1998 by Carnegie Mellon University Intro - page 22 Version 1.1 Architecture Business Cycle (ABC) Architect’s influences Stakeholders Development organization Technical environment Architect’s experience Requirements Architecture System Architect(s)

23 © 1998 by Carnegie Mellon University Intro - page 23 Version 1.1 Importance of the ABC Recognizing architecture as a capital asset develop it with care develop it with more than one system in mind keep it, nurture it, grow it, use it later Looking for new business opportunities that architecture opens up Planning and managing the feedback cycle

24 © 1998 by Carnegie Mellon University Intro - page 24 Version 1.1 Example of ABC: Product Lines Architecture enables entire suite of products to be built more efficiently Case study: CelsiusTech AB of Sweden

25 © 1998 by Carnegie Mellon University Intro - page 25 Version 1.1 ABC for CelsiusTech Architect’s influences Customer and end user Various navies Developing organization CelsiusTech Technical environment Ada Object orientation Iterative development Architect’s experience Real-time embedded C3I Requirements (Qualities) Fault tolerance Tailorability Asset reuse Time to market Architecture System SS2000 products Architect(s)

26 © 1998 by Carnegie Mellon University Intro - page 26 Version 1.1 CelsiusTech’s Software Architecture Two dominant styles layered architecture to separate application- specific software from software used across the entire product line blackboard style to decouple producers and consumers of data Both styles promote modifiability and reusability.

27 © 1998 by Carnegie Mellon University Intro - page 27 Version 1.1 Layered Architecture General applications: 100% Ada Common applications: 100% Ada Fundamentals: 95% Ada, 5% assembly language Base system 2000: 10% Ada, 90% C Operator’s console Target tracking Fire control ASCECM Picture compilations Common application IPC Fundamentals Tactical configuration Database Diagnostics Common functions LAN IPC OS-2000 Base system architecture

28 © 1998 by Carnegie Mellon University Intro - page 28 Version 1.1 Runtime Blackboard Architecture Similar to A-7E data banker module COOB Data-providing application HCI Track information Updates Requests Updates Track-ball updates

29 © 1998 by Carnegie Mellon University Intro - page 29 Version 1.1 Current Members of Product Family Sold 55 variants in SS2000 product family Swedish Goteborg class Coastal Corvettes (KKV) (380 tons) Danish SF300 class multi-role patrol vessels (300 tons) Finnish Rauma class Fast Attack Craft (FAC) (200 tons) Australian/New Zealand ANZAC frigates (3225 tons) Danish Thetis class Ocean Patrol vessels (2700 tons) Swedish Gotland class A19 submarines (1330 tons) Pakistani Type 21 class frigates Republic of Oman patrol vessels Danish Niels Juel class corvettes

30 © 1998 by Carnegie Mellon University Intro - page 30 Version 1.1 Result of Changes: Shrinking, Predictable Schedules ABCDEFGABCDEFG Ships

31 © 1998 by Carnegie Mellon University Intro - page 31 Version 1.1 Result of Changes: Lower Staffing

32 © 1998 by Carnegie Mellon University Intro - page 32 Version 1.1 Result of Changes: Reuse Ships Number of System Modules Unique application National application Modified Reusable application Common (verbatim) A B C D E

33 © 1998 by Carnegie Mellon University Intro - page 33 Version 1.1 ABC Feedback Loop CelsiusTech is now exploring other domains in which their architecture and product line approach offers promise. Air defense sector: Surprise! 40% of brand new system could be lifted verbatim from SS2000.

34 © 1998 by Carnegie Mellon University Intro - page 34 Version 1.1 How is architecture-based development different? The architecture-specific aspects of system creation include: forming an organizational structure that supports/reflects architecture architecture design process -using reference models and domain models -using patterns and styles -building skeletal system, incremental development architecture evaluation checking for conformance

35 © 1998 by Carnegie Mellon University Intro - page 35 Version 1.1 Can We Evaluate an Architecture? Yes. Since architecture is the key to system qualities involves decisions relevant to achieving those qualities is not a random process it follows that we can evaluate architectural decisions for their effect on qualities. Analyzing for system qualities early in the life cycle allows for a comparison of architectural options.

36 © 1998 by Carnegie Mellon University Intro - page 36 Version 1.1 Why evaluate an architecture? All design involves tradeoffs. Not all tradeoffs are optimal (or anywhere near). Architecture is the earliest artifact where trade-offs are visible. A evaluation ensures that: the right questions are asked... early tradeoff points are explicitly identified Since architecture has such a profound effect on the success/failure of a project, evaluating an architecture is cheap risk insurance.

37 © 1998 by Carnegie Mellon University Intro - page 37 Version 1.1 Cost of architecture evaluations AT&T 300 full-scale reviews done on projects of 700 staff-days or longer average cost per review: 70 staff days Rational Software 30 reviews done on projects gteq 500 KSLOC each average cost per review: $50,000 SEI SAAM evaluations ~15 reviews done on projects ranging from 100 KSLOC to 1,000 KSLOC average cost per review: 14 to 20 staff-days average length of review: 2 days

38 © 1998 by Carnegie Mellon University Intro - page 38 Version 1.1 Example of Indirect Staff Costs Using senior designers for evaluations instead of designing Loss of productivity (due to reassignment of superior designers) Time spent training staff in review techniques

39 © 1998 by Carnegie Mellon University Intro - page 39 Version 1.1 Benefits of Architectural Reviews Five different types of benefits result from holding architectural reviews. 1.financial 2.forces preparation for review 3.early detection of problems 4.validation of requirements 5.improved architectures

40 © 1998 by Carnegie Mellon University Intro - page 40 Version 1.1 Financial Benefits of Reviews AT&T estimated that each reviewed project saves 10% of total cost as a result of the review. Thus, a 70-staff-day review of projects of 700 staff-days pays for itself. Consultants who perform architecture evaluations report 80% repeat business.

41 © 1998 by Carnegie Mellon University Intro - page 41 Version 1.1 Forces Preparation for Review Documentation/specifications must be provided, hence they must exist or be created. Some reviews use standard questions, and the architect can prepare ahead to ensure that the architecture scores well. Reviews make the criteria for evaluation explicit by prioritizing requirements or quality goals.

42 © 1998 by Carnegie Mellon University Intro - page 42 Version 1.1 Early Detection of Problems The problems that can be found by an architectural level inspection include unreasonable requirements performance problems problems associated with potential future modifications The earlier in the life cycle that problems are found, the easier it is to fix them.

43 © 1998 by Carnegie Mellon University Intro - page 43 Version 1.1 Validation of Requirements Reviews put stakeholders in the same room with each other, often for the first time. uncovers conflicts and tradeoffs provides a forum for negotiated resolution of problems It often results in the generation of new requirements or the clarification of existing requirements.

44 © 1998 by Carnegie Mellon University Intro - page 44 Version 1.1 Improved Architectures Development organizations anticipate types of questions raised at reviews and design architectures with questions in mind prepare documentation of the type needed at review give explicit consideration to qualities to be reviewed

45 © 1998 by Carnegie Mellon University Intro - page 45 Version 1.1 Review Techniques There are a variety of techniques for performing architectural reviews; each has a different cost and provides different information. These techniques fall into one of two basic categories. 1.questioning techniques: applied to evaluate any aspect of an architecture for any given reason 2.measuring techniques: applied to answer questions about a specific quality

46 © 1998 by Carnegie Mellon University Intro - page 46 Version 1.1 Architecture Tradeoff Analysis Method (ATAM) ATAM is an architecture evaluation method that focuses on multiple quality attributes. In doing so, it: illuminates points in the architecture where quality attribute sensitivities & tradeoffs occur generates a framework for ongoing quantitative analysis

47 © 1998 by Carnegie Mellon University Intro - page 47 Version 1.1 ATAM and Risks The point of an ATAM analysis is not to provide precise analyses... the point is to discover areas of high potential risk in the architecture. We want to find trends: correlations between architectural parameters and measurable properties. These areas can then be made the focus of risk mitigation activities: e.g. further design, further analysis, prototyping.

48 © 1998 by Carnegie Mellon University Intro - page 48 Version 1.1 ATAM Benefits We have observed a number of benefits to performing ATAM analyses: stakeholder buy-in and interaction clarified requirements improved architecture documentation documented basis for architectural decisions And, obviously, improved architectures.

49 © 1998 by Carnegie Mellon University Intro - page 49 Version 1.1 Day 0 Day 1 Day 2 Scenario Elicitation Architecture Elicitation & Mapping Analysis ATAM Steps The ATAM takes 3 days to execute Each day follows the same set of steps, but with different emphases:

50 © 1998 by Carnegie Mellon University Intro - page 50 Version 1.1 Day 0: Information Exchange Purpose: to elicit or refine architectural descriptions, to identify stakeholders, to develop scenarios and initial analyses. Activities: identify important quality attributes document “seed” scenarios identify stakeholders needed at evaluation create initial representations of the architecture define homework for the architect Outcome: an analyzable architecture

51 © 1998 by Carnegie Mellon University Intro - page 51 Version 1.1 Day 1: Skeleton Analyses Purpose: to generate a baseline model that characterizes each quality attribute Activities: [On a per attribute basis] Elicit attribute-specific usage scenarios Map important usage scenarios onto relevant architectural views Attribute annotation/Skeleton analysis building Sensitivity point identification Initial tradeoff point identification Outcome: qualitative analyses of all important quality attributes

52 © 1998 by Carnegie Mellon University Intro - page 52 Version 1.1 Attribute Analysis Taxonomies Performance StimulusArchitecture ParametersResponse Mode Source Frequency Regularity regularoverload Clock interrupt e.g., load balancing e.g., message arrival e.g., missile detected Internal event External event PeriodicAperiodic Sporadic Random params: period params: min inter-arrival interval params: distribution

53 © 1998 by Carnegie Mellon University Intro - page 53 Version 1.1 Attribute Analysis Taxonomies Performance StimulusArchitecture ParametersResponse Resource Resource Arbitration Resource Consumption params: MIPS CPU memory networkdevices/ sensors params: bandwidth params: MB off-line on-line cyclic executive fixed priority dynamic priority queuing policy preemption policy locking (non-preemptable) shared (preemptable queuing per processor queue one-to-oneone-to-many SJFfixed priority deadline FIFO

54 © 1998 by Carnegie Mellon University Intro - page 54 Version 1.1 Attribute Analysis Taxonomies Performance StimulusArchitecture ParametersResponse Latency Throughput Precedence Response window Best/avg/worst case jitter Criticality Best/avg/ worst case variability window Criticality Ordering Partial Total

55 © 1998 by Carnegie Mellon University Intro - page 55 Version 1.1 Day 2: Finding Tradeoffs Purpose: to identify growth areas via sensitivities and tradeoffs Activities: Attribute-specific growth scenario elicitation and prioritization Mapping of growth scenarios onto architecture Sensitivity point identification Tradeoff point identification Outcome: potential sensitivity/tradeoff risk areas of the architecture identified

56 © 1998 by Carnegie Mellon University Intro - page 56 Version 1.1 Experience to date - 1 SAAM ~15 evaluations to date supporting artifacts (process model, handbook, tips and guidance, seed scenarios, artifact examples) good for functionality / modifiability investigations good for eliciting, prioritizing specific quality requirements good for eliciting architectural description

57 © 1998 by Carnegie Mellon University Intro - page 57 Version 1.1 Experience to date - 2 ATAM 4 evaluations so far, 6-10 more planned precise method is still firming up handbook being written customer feels good value is given good at non-run-time qualities plus run-time qualities (SAAM is a procedural subset)

58 © 1998 by Carnegie Mellon University Intro - page 58 Version 1.1 Conclusions Architecture is a fundamental asset in software development. Companies who manage it and let it work to their benefit are discovering pay-off. Architecture-based development must be matured as a discipline. A key aspect of architecture-based development is architecture evaluation.


Download ppt "© 1998 by Carnegie Mellon University Intro - page 1 Version 1.1 1 The Architecture Business Cycle Paul C. Clements Software Engineering Institute Carnegie."

Similar presentations


Ads by Google