Software Architecture in Practice

Software Architecture in Practice
Carnegie Mellon University Software Engineering Institute Software Architecture in Practice Paul C. Clements Software Engineering Institute Carnegie Mellon University Pittsburgh, PA Sponsored by the U.S. Department of Defense © 2002 by Carnegie Mellon University Highlights of our thinking on how to design, document, analyze, and implement architectures. Much of this is documented in more detail in recent papers. 1 © 2002 by Carnegie Mellon University

The SEI: Who we are -1 The Software Engineering Institute (SEI) is
a federally funded research and development center sponsored by the U. S. Department of Defense hosted by Carnegie Mellon University in Pittsburgh staffed by about 200 people The SEI’s core purpose is to help others make measured improvements in their software engineering capabilities.

Software architecture
The SEI: Who we are - 2 First objective: Accelerate the introduction and widespread use of high-payoff software engineering practices and technology by identifying, evaluating, and maturing promising or underused technology and practices. We are a small organization. We have to pick these practices carefully. One we have chosen is Software architecture

The Ascendance of Software Architecture
Over the past 10 years, software architecture has emerged as the prominent paradigm in large-system development. There are: worldwide conferences devoted to it books devoted to it defined “architect” roles in organizations courses and training for it

And yet... It is still not well understood in some circles.
Some organizations have no “architect” position. Others have the position but it is informally defined. Some organizations are still proceeding to development without an architecture in place. The tools of the trade -- styles and patterns, views, evaluation -- are used sparingly if at all.

Today’s talk What is software architecture and why is it important?
A benefit of architecture: Software product lines Evaluating software architectures Documenting software architectures

What Is Software Architecture?
Software architecture is the structure or structures of the system, which comprise software elements, the externally visible properties of these elements, and the relationships among them. The exact structures to consider and the ways to represent them vary according to engineering goals. Replace building photo, and improve runaround. © 2002 by Carnegie Mellon University 17

Implications of this Definition – 1
A software architecture is an abstraction of a system. Architecture defines elements and how they interact. Architecture suppresses purely local information about elements; private details are not architectural. Externally-visible properties of elements are assumptions that one elements can make about another: provided services, required services, performance characteristics, fault handling, resource usage

Every system has an architecture. Every system is composed of elements and there are relationships among them. In the simplest case, a system is composed of a single elements, related only to itself. Just having an architecture is different from having an architecture that is known to everyone: The architecture versus specification of the architecture If you don’t explicitly develop an architecture, you will get one anyway – and you might not like what you get. © 2002 by Carnegie Mellon University

This means that box-and-line drawings alone are not architectures; but they are just a starting point. You might imagine the behavior of a box labeled “database” or “executive” -- but that’s all You need to add specifications and properties. Systems have many structures (views). No single structure can be the architecture. The set of candidate structures is not fixed or prescribed: choose whatever is useful for analysis, communication, or understanding.

Example of Multiple Views
Software Architecture for A-7E Corsair II Aircraft U. S. carrier-based, light attack aircraft Used from the 1960s through the 1980s Small computer on board for navigation, weapons delivery The A-7E Corsair II was a single-seat, carrier-based light attack aircraft used by the U.S. Navy from the 1960s through the 1980s. An earlier version, the A-7C, was among the very first production aircraft in the world to be equipped with an on-board computer to help the pilot with navigation and “weapons delivery” (a military term for attacking a ground target). The A-7E’s software was responsible, in broad terms, for reading sensors and updating cockpit displays that helped the pilot navigate to drop weapons on target. The A-7E software did not actually fly the aircraft, as more modern avionics systems do. A-7Es were retired from active duty in the US Navy in the late 1980s, but current generation fighters feature a heads-up display and weapon-delivery and navigation modes that show heavy influence from the Corsair. © 2002 by Carnegie Mellon University

Module View (2 Levels) Hardware-Hiding Module Device interface module
Extended computer Behavior-Hiding Module Function driver Shared services Data banker Physical models module Application data types mod. Filter behavior module Software utilities module System generation mod. Software -Decision-Hiding Module This diagram shows the second-level modules of each main module; based on this module structure, teams can now be formed to do the work for each module, with assignments made based on the relevant expertise of the available programmers. © 2002 by Carnegie Mellon University

Data Flow View Pilot, external world Device interfaces Data banker
sensor inputs values to display calculated real-world values Data banker Physical models computed values stored values stored values Shared services sensor values The data flow view emerges from the roles described on the previous slide. The original developers never used the data flow view explicitly, but they all probably had it in their minds are they built the other architectural structures. computed values filtered values Function drivers Filter behaviors © 2002 by Carnegie Mellon University

Layers View Function drivers Shared services Data banker Physical
models Filter behaviors Software utilities Device interfaces What emerges from the uses rules is a picture of a system partitioned into layers. The extended computer is on the bottom-most layer, with the application data types module built right on top of it; the two of them form a virtual machine. A procedure at a particular level is allowed to use a procedure at the same or any lower level. At the high end of the layering come the function drivers and the shared services modules, which have the freedom to use a wide variety of system facilities to do their jobs. In the middle layers lie the data banker, physical models, and filter behaviors modules. The software utilities reside in parallel with this structure and are allowed to use anything (except the function drivers) necessary to accomplish their individual tasks. Application data types Extended computer © 2002 by Carnegie Mellon University

Views -1 An architecture is a very complicated construct -- too complicated to be seen all at once. Views are a way to manage complexity. 1974: Parnas observed that software is composed of many structures 1992: Perry and Wolf recognize that, similar to buildings (with plumbing and electrical and wall diagrams), different views of a system are required. 1995: Kruchten defined the “4+1 views” approach to software architecture. 2000: Hofmeister, Nord, and Soni defined the “Siemens Four Views” approach to software.

Views -2 A view is a representation of a set of architectural
elements and the relations associated with them. Not all architectural elements -- some of them. A view binds element types and relation types of interest, and shows those. All information Some information

Views -3 In box-and-line diagrams, a way of asking what the boxes and lines mean is: “What element types and relation types are you showing? In other words, “What view are you showing?” Which view shows “the” architecture? None of them. All of them.

Architecture As Communication Vehicle
Architecture provides a common frame of reference in which competing interests may be exposed and negotiated. negotiating requirements with users and other stakeholders keeping the customer informed of progress and cost implementing management decisions and allocations © 2002 by Carnegie Mellon University

Architecture Constrains Implementation
An architecture defines constraints on an implementation. Architectures are descriptive and prescriptive descriptive for communication prescriptive for design and implementation Global resource allocation decisions constrain implementations of individual components System tradeoffs regarding quality attributes are in the architectural realm. © 2002 by Carnegie Mellon University

Architecture Organizes the Development Project
The architecture influences the organizational structure for development/maintenance efforts. Examples include division into teams units for budgeting, planning basis of work breakdown structure organization of documentation organization of CM libraries basis of integration basis of test plans, testing basis of maintenance Incremental deployment © 2002 by Carnegie Mellon University

Architecture Permits/Precludes Achievement of Quality Attributes
For example If you desire Examine performance inter-component communication modifiability component responsibilities security inter-component communication, specialized components (e. g., kernels) scalability localization of resources ability to subset inter-component usage reusability inter-component coupling © 2002 by Carnegie Mellon University

Architecture is Key to Managing Change
An architecture helps reason about and manage change. important since 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. © 2002 by Carnegie Mellon University

Architecture is Basis for Incremental Development
An architecture helps with evolutionary prototyping and incremental delivery. Architecture serves as a skeletal framework into which components can be plugged. By segregating functionality into appropriate components, experimentation is easier. Risky elements of the system can be identified via the architecture and mitigated with targeted prototypes. © 2002 by Carnegie Mellon University

Architecture is a Reusable Model
An architecture is an abstraction: enables a one-to-many mapping (one architecture, many systems). Systems can be built from large, externally developed components that are tied together via architecture. Architecture is the basis for product (system) commonality. Entire software product lines can share a single architecture. © 2002 by Carnegie Mellon University

What is a Software Product Line?
A software product line is a set of software-intensive systems sharing a common, managed set of features that satisfy the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way.

Software Product Lines
pertain to Market strategy/ Application domain is satisfied by share an Architecture Products used to structure CORE ASSETS are built from Components Product lines take economic advantage of commonality bound variability © 2002 by Carnegie Mellon University

How Do Product Lines Help?
Product lines amortize the investment in these and other core assets: requirements and requirements analysis domain model software architecture and design performance engineering documentation test plans, test cases, and data people: their knowledge and skills processes, methods, and tools budgets, schedules, and work plans components earlier life- cycle reuse more benefit © 2002 by Carnegie Mellon University 8

The Key Concepts Use of a common asset base
of a related set of products in production © 2002 by Carnegie Mellon University 10

Economics of Product Lines
Current Practice With Product Line Approach Cumulative Cost Number of Products Derived from data supplied by Lucent Technologies Bell Laboratories Innovations

Example: Cummins, Inc. World’s largest manufacturer of large diesel engines (over 200 hp) 25,000 employees 350 controls and electronics engineers $7B annual sales

Complex Domain Of Variation
Today’s diesel engines are driven by software. Micro-control of ignition timing to achieve optimum mix of power, economy, emissions. Conditions change dynamically as function of road incline, temperature, load, etc. Must also respond to statutory regulations that often change. Reliability is critical! Multi-million dollar fleets can be put out of commission by a single bug. 130KSLOC -- C, assembler, microcode. Different sensors, platforms, requirements.

Changing the Way to Do Business
In 1994, with six engine projects under way and 12 more planned, Cummins realized that it could not continue to do business the old way realized hiring to fill the need was out of the question launched a software product line built a core asset base from the most successful of its projects turned the other projects into product development projects using the core assets

Cummins’ Results In early 1995, the first product was launched on time (relative to re-vamped schedule) with high quality. Others followed -- on time and with high quality. Cummins achieved a product family capability with a breathtaking capacity for variation, or customization 9 basic engine types 4-18 cylinders liter displacement 12 kinds of electronic control modules 5 kinds of microprocessors 10 kinds of fuel systems diesel fuel or natural gas

Quantitative Results - 1
20 product groups launched, which account for over 1000 separate engine applications 75% of all software, on average, comes from core assets Product cycle time has plummeted. Time to first engine start went from 250 person-months to a few person-months. One prototype was built over a weekend. Software quality is at an all-time high, which Cummins attributes to product line approach.

Customer satisfaction is high. Productivity gains enable new features to be developed (more than 200 to date). Projects are more successful. Before product line approach, 3 of 10 were on track, 4 were failing, and 3 were on the edge. Now, 15 of 15 are on track. Widespread feeling that developers are more portable, and hence more valuable.

Achieving this flexibility without the product line approach would have required 3.6 times the current staff.

Today’s largest teams are smaller than yesterday’s smallest teams. Two-person teams are not unusual. Cummins management has a history of embracing change, but carefully targeted change. They estimate that process improvement alone has brought a benefit/cost ratio of 2:1 to 3:1. They estimate that the product line approach has brought a benefit/cost ratio of 10:1. Product line approach let them quickly enter and then dominate the industrial diesel engine market.

Lessons Learned Cummins story echoes product line success themes seen on other successful efforts, namely a compelling business case deep domain expertise a rich legacy base a dedicated champion organizational cohesion courage to try new engineering approaches

Examples of Product Line Practice - 1
CelsiusTech - large shipboard command/control systems hardware-to-software cost ratio switched from 35:65 to 80:20 staff decreased from over 200 to about 40 Motorola - FLEXworks Project (family of one-way pagers) 4x cycle time improvement 80% reuse Hewlett Packard - printer systems 2-7x cycle time improvement Sample Project shipped 5x number of products that were 4x as complex and had 3x the number of features with 4x products shipped/person © 2002 by Carnegie Mellon University

Examples of Product Line Practice - 2
Nokia - mobile phones went from 4 different phones produced per year to per year 58 languages, multiple platforms, wide range of features National Reconnaissance Office’s Control Channel Toolkit - ground-based satellite systems first product using core assets requiring 1/10 the normal number of developers Market Maker - website stock market software each product uniquely configured for customer three days to put up a customized system © 2002 by Carnegie Mellon University

Architecture Evaluation
A software architecture is the earliest life-cycle artifact that embodies significant design decisions. Analyzing for system qualities early in the life cycle allows for a comparison of architectural options. With the advent of cost-effective, repeatable architecture evaluation methods, architecture evaluation should be a standard part of every architecture-based development methodology. It is always more cost-effective to evaluate software quality as early as possible in the life cycle. If problems are found early in the software life cycle, they are easier to correct - a change to a requirement, specification, or design is all that is necessary. Software quality cannot be appended late in a project; it must be inherent from the beginning, built in by design. It is in the project's best interest for prospective candidate designs to be evaluated (and rejected, if necessary) during the design phase, before long-term institutionalization occurs. When building a system, architectures are useful ways to try to ensure that the desired qualities or functionalities can be supported. However, the architecture cannot guarantee the quality or functionality, as there are factors later in the life cycle that can undermine it. But since architecture is the earliest artifact in the life cycle that shows the visibility of trade-offs, analysis of the architecture before it becomes the project’s accepted blueprint is of great benefit to the development organization. Unfortunately, the reality is that architecture analysis is often done later in the project as damage control when something goes wrong. © 2002 by Carnegie Mellon University

When and Why To Evaluate an Architecture
When building a system Evaluation should be done when deciding on architecture. When acquiring a system Architectural evaluation is useful if the system will have a long lifetime within organization. Evaluation provides a mechanism for understanding how the system will evolve. Evaluation can also provide insight into other visual qualities. When acquiring a large software system that will have a long lifetime within the acquiring organization, it is important that the organization develop an understanding of the underlying architecture of the candidates. This makes possible an assessment of the suitability of the candidates with respect to qualities of importance, as well as providing a mechanism for understanding how the system is likely to evolve. © 2002 by Carnegie Mellon University

Forces Preparation for Review
Documentation/specifications must be provided, hence they must exist or be created. Some evaluations use standard questions, and the architect can prepare ahead to ensure that the architecture scores well. Evaluations make the criteria for evaluation explicit by prioritizing requirements or quality goals. If one gives the reviewees an indication of the focus of the architecture review and the requirement for a representation of the architecture before the review is held, the reviewees are required to document the system’s architecture. Many systems do not have an architecture that is understandable to all of the developers. The existing description is either too brief or (more commonly) too long, perhaps thousands of pages. Furthermore, there are often misunderstandings among developers about some of the assumptions for their components. The process of preparing for the review will reveal many of these problems. Furthermore, the architecture review focuses on a few specific areas with specific questions to be answered. Answering these questions usually involves giving an explanation of the design choices and their rationales. Having a documented design rationale is important later in the life cycle so that the implications of modifications can be assessed. Capturing design rationales after the fact is one of the more difficult tasks in software development. By capturing the design rationale as presented in the architecture review (even by such low-cost methods are videotaping), invaluable information is available for later use. © 2002 by Carnegie Mellon University

Early Detection of Problems
The problems that can be found by an architecture evaluation 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. The earlier in the life cycle that problems are detected, the cheaper it is to fix them. The problems that can be found by an architectural level inspection include unreasonable (or expensive to meet) requirements, performance problems, and problems associated with potential downstream modifications. For example, an architecture review that exercises scenarios of typical system activity can manifest rough performance specifications. Exercising system modification scenarios can reveal portability and extensibility problems that will be especially critical if the architecture is to support a product line rather than just a single product. Architecture review, therefore, provides early insight into product capabilities and limitations. © 2002 by Carnegie Mellon University

Validation of Requirements
Evaluations 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. Discussion and examination of how well an architecture meets requirements also opens requirements up for discussion. What results is clearer understanding of the requirements and usually, prioritization of the requirements. Requirements creation, when performed in isolation from early design, usually results in specification of conflicting system properties. High performance, security, fault tolerance, and low cost are all easy to demand but difficult to achieve and are often impossible to achieve simultaneously. Architecture review uncover the conflicts and trade-offs and provide a forum for negotiated resolution. © 2002 by Carnegie Mellon University

Improved Architectures
Development organizations anticipate types of questions raised at evaluations and design architectures with questions in mind prepare documentation of the type needed at evaluation give explicit consideration to qualities to be evaluated The organizations that practice architecture review as a standard part of their development process report an improvement in the quality of the architectures that are reviewed. As development organizations learn to anticipate the kinds of questions that will be asked, the kinds of issues that will be raised, and the kinds of documentation that will be required for reviews, they naturally position themselves to maximize their performance on the reviews. Architecture reviews result not only in better architectures after the fact, but before the fact. Over time, an organization develops a culture that promotes good architectural design. © 2002 by Carnegie Mellon University

The ATAMSM The SEI has developed the Architecture Tradeoff Analysis MethodSM (ATAMSM). The purpose of ATAMSM is: to assess the consequences of architectural decisions in light of quality attribute requirements and business goals. © 2002 by Carnegie Mellon University

ATAMSM Steps 1. Present the ATAMSM 2. Present business drivers
3. Present architectural views 4. Identify architectural approaches 5. Generate quality attribute utility tree 6. Analyze architectural approaches 7. Brainstorm and prioritize scenarios 8. Analyze architectural approaches 9. Present results Phase 1: Evaluation team, key decision-makers Phase 2: Evaluation team, stakeholders © 2002 by Carnegie Mellon University

Conceptual Flow of ATAMSM
Architectural Decisions Scenarios Quality Attributes Approaches Business Drivers Software Architecture Analysis Risks Sensitivity Points Tradeoffs Non-Risks impacts Risk Themes distilled into

Documenting an architecture
Architecture serves as the blueprint for the system, and the project that develops it. It defines the work assignments. It is the primary carrier of quality attributes. It is the best artifact for early analysis. It is the key to post-deployment maintenance and mining. Documenting the architecture is the crowning step to creating it. Documentation speaks for the architect, today and 20 years from today.

“Views and Beyond” approach to documentation
Views give us our first principle of architecture documentation: Document the relevant views, and then add information that applies to more than one view.

Which views are relevant? -1
Kruchten’s 4+1 views Logical view: supports behavioral requirements. Key abstractions, which are objects or object classes Process view: addresses concurrency and distribution. Maps threads to objects. Development view: organization of software modules, libraries, subsystems, units of development. Physical view: maps other elements onto processing and communication nodes. “Plus one” view: Maps the other views onto important use cases to show how they work.

Siemens Four-Views (Hofmeister, Nord, Soni, Applied Software Architecture, 2000): Conceptual view Module interconnection view Execution view Code view Herzum & Sims (Business Component Factory, 1999): Technical architecture Application architecture Project management architecture Functional architecture

Software Cost Reduction method (Parnas, et al., 1980s) Module view: shows modules as units of encapsulation; used to isolate changes and achieve modifiability Process view: shows processes and how they synchronize and communicate at run-time; used to achieve performance Uses view: shows programs and how they depend on each other; used to achieve incremental development and the ability to quickly field subsets

Which views are relevant? It depends on: who the stakeholders are how they will use the documentation. Three primary uses for architecture documentation: Education -- introducing people to the project Communication -- among stakeholders Analysis -- assuring quality attributes

What views are available? -1
Plenty! Too many! Already, we’ve seen 15 different views, and many more are available, based on examining the literature. An architect needs a way to choose the useful ones. One thing that would help is to organize the views into broad categories.

An architect must consider the system in three ways: How is it structured as a set of code units? How is it structured as a set of elements that have run-time behavior and interactions? How does it relate to non-software structures in its environment?

This suggests looking for three kinds of views that help: How is it structured as a set of code units? Module views (module viewtype) How is it structured as a set of elements that have run-time behavior and interactions? Component-and-connector views (C&C viewtype) How does it relate to non-software structures in its environment? Allocation views (allocation viewtype)

How many views do we need in our documentation package?
Each view comes with a cost. Each view comes with a benefit. Planning a view set requires understanding the needs of the stakeholders, and the resources available.

How to proceed? 1. Build a table. ROWS: Enumerate the stakeholders
COLUMNS: Enumerate the set of styles that could apply to the architecture being documented. This is our potential set of views. Check box (x,y) if stakeholder x would like view y. 2. Combine views appropriately to reduce number. 3. Prioritize views based on need. (Some stakeholders may have extra weight.)

Documenting a view -1 1. A primary presentation
Usually graphical (we call this a cartoon) May be textual -- e.g., a table If graphical, includes a key explaining the notation (or pointing to explanation) Shows elements and relationships among them Shows information you wish to convey about the view (view packet) first Many times, the primary presentation is all you get. It’s not enough!

Documenting a view -2 2. An element catalog
Explains the elements depicted in the primary presentation Lists elements and their properties (as defined by the relevant style guide) Explains relations, and any exceptions or additions to the relations shown in the primary presentatio Interfaces of elements 3. A context diagram Shows how system (or portion shown in this view packet) relates to its environment.

Documenting a view -3 4. A variability guide
Shows the architectural mechanisms available to change the element 5. Architecture background Rationale for design decisions that apply to the entire view (or to that portion of the view being shown), including rejected alternatives and factors that constrained the design Analysis results validating the design decisions Assumptions about the environment and about the need that the system is fulfilling

Documenting a view -4 6. Other information
System- and project-specific. CM information, ownership information Mapping to requirements Not architectural, strictly speaking. But useful to capture alongside the architecture anyway. 7. Related view packets Pointers to sibling, child, and parent view packets

Documentation beyond views - 1
1. Documentation roadmap How the documentation is organized to serve a stakeholder List of views, with the elements/relations of each, and a statement of what the view is for Scenarios for using the documentation, showing which parts should be consulted 2. View template Explanation of how each view is documented The standard organization for each view

Documentation beyond views -2
3. System overview An informal, prose description of the system and its purpose and functionality Goal is to provide context for new member Perfectly OK to point to overview elsewhere if one exists in overall system documentation 4. Mapping between views Establishes useful/insightful correspondence between various views Tabular

Documentation beyond views -3
5. Directory An index showing where every element, relation, and property is defined and used. 6. Architecture glossary and acronym list May be subset of overall system glossary and acronym list. OK to point to larger document if so. 7. Background, design constraints, and rationale As in views, but applied to cross-view design decisions.

Software product lines
Source of material - 1 General overview 1998 (second edition 2003) Software product lines 2001

Source of material - 2 Architecture evaluation 2001
Architecture documentation 2002

For more information SEI’s software architecture work:
SEI’s software product line work: Contact information: Paul Clements Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213

Software Architecture in Practice

Similar presentations

Presentation on theme: "Software Architecture in Practice"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Software Architecture in Practice

Similar presentations

Presentation on theme: "Software Architecture in Practice"— Presentation transcript:

Similar presentations

About project

Feedback