2 The SEI: Who we are -1 The Software Engineering Institute (SEI) is a federally funded research and development centersponsored by the U. S. Department of Defensehosted by Carnegie Mellon University in Pittsburghstaffed by about 200 peopleThe SEI’s core purpose is to help others make measured improvements in their software engineering capabilities.
3 Software architecture The SEI: Who we are - 2First 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 isSoftware architecture
4 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 itbooks devoted to itdefined “architect” roles in organizationscourses and training for it
5 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.
6 Today’s talk What is software architecture and why is it important? A benefit of architecture: Software product linesEvaluating software architecturesDocumenting software architectures
7 Today’s talk What is software architecture and why is it important? A benefit of architecture: Software product linesEvaluating software architecturesDocumenting software architectures
9 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
11 Implications of this Definition – 3 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 allYou 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.
16 Views -1An 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 structures1992: 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.
17 Views -2 A view is a representation of a set of architectural elements and the relations associated with them.Not all architecturalelements -- some of them.A view binds elementtypes and relation typesof interest, and showsthose.All informationSome information
18 Views -3In 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.
26 Today’s talk What is software architecture and why is it important? A benefit of architecture: Software product linesEvaluating software architecturesDocumenting software architectures
27 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.
31 Economics of Product Lines CurrentPracticeWith Product Line ApproachCumulativeCostNumber of ProductsDerived from data supplied byLucent TechnologiesBell Laboratories Innovations
32 Example: Cummins, Inc.World’s largest manufacturer of large diesel engines(over 200 hp)25,000 employees350 controls andelectronics engineers$7B annual sales
33 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.
34 Changing the Way to Do Business In 1994, with six engine projects under way and 12 more planned, Cumminsrealized that it could not continue to do business the old wayrealized hiring to fill the need was out of the questionlaunched a software product linebuilt a core asset base from the most successful of its projectsturned the other projects into product development projects using the core assets
35 Cummins’ ResultsIn 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 customization9 basic engine types4-18 cylindersliter displacement12 kinds of electronic control modules5 kinds of microprocessors10 kinds of fuel systemsdiesel fuel or natural gas
36 Quantitative Results - 1 20 product groups launched, which account for over 1000 separate engine applications75% of all software, on average, comes from core assetsProduct 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.
37 Quantitative Results - 2 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.
38 Quantitative Results - 3 Achieving this flexibility without the product line approach would have required 3.6 times the current staff.
39 Quantitative Results - 4 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.
40 Lessons LearnedCummins story echoes product line success themes seen on other successful efforts, namelya compelling business casedeep domain expertisea rich legacy basea dedicated championorganizational cohesioncourage to try new engineering approaches
52 Conceptual Flow of ATAMSM ArchitecturalDecisionsScenariosQualityAttributesApproachesBusinessDriversSoftwareArchitectureAnalysisRisksSensitivity PointsTradeoffsNon-RisksimpactsRisk Themesdistilledinto
53 Today’s talk What is software architecture and why is it important? A benefit of architecture: Software product linesEvaluating software architecturesDocumenting software architectures
54 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.
55 “Views and Beyond” approach to documentation Views give us our first principle of architecture documentation:Document the relevant views,and then add informationthat applies to more than one view.
56 Which views are relevant? -1 Kruchten’s 4+1 viewsLogical view: supports behavioral requirements. Key abstractions, which are objects or object classesProcess 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.
58 Which views are relevant? -3 Software Cost Reduction method(Parnas, et al., 1980s)Module view: shows modules as units of encapsulation; used to isolate changes and achieve modifiabilityProcess view: shows processes and how they synchronize and communicate at run-time; used to achieve performanceUses view: shows programs and how they depend on each other; used to achieve incremental development and the ability to quickly field subsets
59 Which views are relevant? -4 Which views are relevant? It depends on:who the stakeholders arehow they will use the documentation.Three primary uses for architecture documentation:Education -- introducing people to the projectCommunication -- among stakeholdersAnalysis -- assuring quality attributes
60 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.
61 What views are available? -2 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?
62 What views are available? -3 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)
63 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 thestakeholders, and the resources available.
64 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.)
65 Documenting a view -1 1. A primary presentation Usually graphical (we call this a cartoon)May be textual -- e.g., a tableIf graphical, includes a key explaining the notation (or pointing to explanation)Shows elements and relationships among themShows information you wish to convey about the view (view packet) firstMany times, the primary presentation is all you get. It’s not enough!
66 Documenting a view -2 2. An element catalog Explains the elements depicted in the primary presentationLists 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 presentatioInterfaces of elements3. A context diagramShows how system (or portion shown in this view packet) relates to its environment.
67 Documenting a view -3 4. A variability guide Shows the architectural mechanisms available to change the element5. Architecture backgroundRationale 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 designAnalysis results validating the design decisionsAssumptions about the environment and about the need that the system is fulfilling
68 Documenting a view -4 6. Other information System- and project-specific.CM information, ownership informationMapping to requirementsNot architectural, strictly speaking. But useful to capture alongside the architecture anyway.7. Related view packetsPointers to sibling, child, and parent view packets
69 Documentation beyond views - 1 1. Documentation roadmapHow the documentation is organized to serve a stakeholderList of views, with the elements/relations of each, and a statement of what the view is forScenarios for using the documentation, showing which parts should be consulted2. View templateExplanation of how each view is documentedThe standard organization for each view
70 Documentation beyond views -2 3. System overviewAn informal, prose description of the system and its purpose and functionalityGoal is to provide context for new memberPerfectly OK to point to overview elsewhere if one exists in overall system documentation4. Mapping between viewsEstablishes useful/insightful correspondence between various viewsTabular
71 Documentation beyond views -3 5. DirectoryAn index showing where every element, relation, and property is defined and used.6. Architecture glossary and acronym listMay be subset of overall system glossary and acronym list. OK to point to larger document if so.7. Background, design constraints, and rationaleAs in views, but applied to cross-view design decisions.
72 Software product lines Source of material - 1General overview1998 (second edition 2003)Software product lines2001
73 Source of material - 2 Architecture evaluation 2001 Architecture documentation2002
74 For more information SEI’s software architecture work: SEI’s software product line work:Contact information:Paul ClementsSoftware Engineering InstituteCarnegie Mellon UniversityPittsburgh, PA 15213