Carnegie University Carnegie Mellon Mellon University

Software Engineering Software Engineering Institute

Institute

Software Architecture in Practice
Paul C. Clements Software Engineering Institute Carnegie MellonInstitute Software Engineering University Pittsburgh, PA 15213-3890 USA Carnegie Mellon University
Pittsburgh, PA 15213-3890

Sponsored by the U.S. Department of Defense ©Sponsored byCarnegie Mellon University 2002 by the U.S. Department of Defense
© 1999 by Carnegie Mellon University
Version 1.0 CECOM Course 2, Lecture 1 - page 1
1

Carnegie Mellon University

Software Engineering Institute

Schedule and Outline
0900 - 0915 Introductions 0915 - 0945 The Architecture Business Cycle 0945 -1000 What is architecture? 1000 - 1030 Why is architecture important? 1030 - 1045 Break 1045 - 1115 Architectural structures 1115 - 1200 New developments in software architecture

© 1999 by Carnegie Mellon University

Version 1.0

CECOM Course 2, Lecture 1 - page 2

Carnegie Mellon University

Software Engineering Institute

Schedule and Outline
0900 - 0915 Introductions 0915 - 0945 The Architecture Business Cycle 0945 -1000 What is architecture? 1000 - 1030 Why is architecture important? 1030 - 1045 Break 1045 - 1115 Architectural structures 1115 - 1200 New developments in software architecture

© 1999 by Carnegie Mellon University

Version 1.0

CECOM Course 2, Lecture 1 - page 3

Carnegie Mellon University Software Engineering Institute Factors Influencing Architectures Architectures are influenced by • stakeholders of a system • technical and organizational factors • architect’s background © 1999 by Carnegie Mellon University Version 1. Lecture 1 .page 4 .0 CECOM Course 2.

not changed very often! Architect Ohhhhh. security. low cost. leveraging existing corporate assets! Neat features. short time to market. keeping people employed..page 5 .0 CECOM Course 2. parity with competing products! Behavior.Carnegie Mellon University Software Engineering Institute Stakeholders of a System Development organization’s management stakeholder Marketing stakeholder End user stakeholder Maintenance organization stakeholder Customer stakeholder Low cost. reliability! Modifiability! Low cost. performance. © 1999 by Carnegie Mellon University Version 1.. timely delivery. Lecture 1 .

Carnegie Mellon University Software Engineering Institute Development Organization Concerns Business issues • investing in.supporting specialized expertise • maintaining the standard method of doing business © 1999 by Carnegie Mellon University Version 1. e.page 6 . and then utilizing personnel Organizational structure issues • furthering vested interests.0 CECOM Course 2. .maintaining an existing database organization . and then amortizing the infrastructure • keeping cost of installation low • investing in..g. Lecture 1 .

Available technology: decisions on using a centralized or decentralized system depend on processor cost and communication speed. Lecture 1 .page 7 . both are changing quantities. © 1999 by Carnegie Mellon University Version 1.0 CECOM Course 2.Carnegie Mellon University Software Engineering Institute 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.

Lecture 1 .page 8 . © 1999 by Carnegie Mellon University Version 1. • Prior bad experiences will be avoided in the new design.Carnegie Mellon University Software Engineering Institute Architect’s Background Architects develop their mindset from their past experiences. • Prior good experiences will lead to replication of prior designs.0 CECOM Course 2.

0 CECOM Course 2. Lecture 1 .Carnegie Mellon University Software Engineering Institute Summary: Influences on the Architect Architect’s influences Stakeholders Requirements Development organization Technical environment Architect’s experience Architect(s) Architecture System © 1999 by Carnegie Mellon University Version 1.page 9 .

Carnegie Mellon University Software Engineering Institute What Makes a Good Architect? People skills: must be able to • negotiate competing interests of stakeholders • promote inter-team collaboration Technical skills: must understand • the relationships between qualities and structures • current technology • that most requirements for an architecture are not written down in any requirements document Communication skills: must be able to • clearly convey the architecture to teams (both verbally and in writing) • listen to and understand multiple viewpoints © 1999 by Carnegie Mellon University Version 1.0 CECOM Course 2. Lecture 1 .page 10 .

Carnegie Mellon University

Software Engineering Institute

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

© 1999 by Carnegie Mellon University

Version 1.0

CECOM Course 2, Lecture 1 - page 11

Carnegie Mellon University

Software Engineering Institute

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 a collection of similar systems, organizational units reflect common components (e.g., operating system unit or database unit).

© 1999 by Carnegie Mellon University

Version 1.0

CECOM Course 2, Lecture 1 - page 12

Carnegie Mellon University

Software Engineering Institute

Architecture Influences the Development Organization 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.

© 1999 by Carnegie Mellon University

Version 1.0

CECOM Course 2, Lecture 1 - page 13

Carnegie Mellon University Software Engineering Institute Architecture Influences Customer Requirements Knowledge of similar fielded systems leads customers to ask for particular features.page 14 . Lecture 1 . © 1999 by Carnegie Mellon University Version 1. Customers will alter their requirements on the basis of the availability of existing systems.0 CECOM Course 2.

• the WWW for information systems • the three-tier architecture for database systems © 1999 by Carnegie Mellon University Version 1. a system or an architecture will affect the technical environment. Lecture 1 . Occasionally.Carnegie Mellon University Software Engineering Institute Architecture Influences the Architect’s Experience and Technical Environment Creation of a system affects the architect’s background.page 15 .0 CECOM Course 2.

0 CECOM Course 2.page 16 .Carnegie Mellon University Software Engineering Institute Architecture Business Cycle (ABC) Architect’s influences Stakeholders Requirements Development organization Technical environment Architect’s experience Architect(s) Architecture System © 1999 by Carnegie Mellon University Version 1. Lecture 1 .

Carnegie Mellon University Software Engineering Institute ABC Summary Architecture involves more than just technical requirements for a system. • Architects learn from experience. such as the • architect’s background • development environment • business goals of the sponsoring organization Architecture influences the factors that affect it. © 1999 by Carnegie Mellon University Version 1.page 17 . Lecture 1 . • The development environment is expanded and altered.0 CECOM Course 2. • Businesses gain new marketing possibilities. It also involves non-technical factors.

0915 Introductions 0915 .1115 Architectural structures 1115 .Carnegie Mellon University Software Engineering Institute Schedule and Outline 0900 .1030 Why is architecture important? 1030 .0 CECOM Course 2.page 18 . Lecture 1 .1045 Break 1045 .1200 New developments in software architecture © 1999 by Carnegie Mellon University Version 1.0945 The Architecture Business Cycle 0945 -1000 What is architecture? 1000 .

Carnegie Mellon University Software Engineering Institute Some Usual Descriptions of Architecture “Components and connectors” “Overall structure of system” A diagram: Control process (CP) Prop loss model (MODP) © 1999 by Carnegie Mellon University Reverb model (MODR) Version 1.0 Noise model (MODN) CECOM Course 2. Lecture 1 .page 19 .

Carnegie Mellon University Software Engineering Institute What’s Wrong with “Components and Connectors?” What kind of component? • task? process? • object? program? function? • library? compilation unit? • processor? What kind of connector? • calls? invokes? signals? uses? data flow? • subclass? • runs with? excludes? • co-located with? © 1999 by Carnegie Mellon University Version 1.0 CECOM Course 2. Lecture 1 .page 20 .

Carnegie Mellon University Software Engineering Institute What’s Wrong with “Overall Structure?” Which structure? Software is composed of many structures.0 CECOM Course 2. • module • task • uses • logical • functional When seeing boxes and lines.page 21 . we must ask • What do the boxes represent? • What do the arrows mean? © 1999 by Carnegie Mellon University Version 1. Lecture 1 .

Lecture 1 . rather.0 CECOM Course 2. they are a starting point. © 1999 by Carnegie Mellon University Version 1.Carnegie Mellon University Software Engineering Institute What’s Wrong with the Diagram? Same questions as the previous slide.page 22 . • What kind of components? • What kind of connectors? • What structures? • What do the boxes and arrows mean? Plus new questions • What is the significance of the layout? • Why is control process on a higher level? Box and arrow drawings alone are not architectures.

0 CECOM Course 2. Notice this means that • box-and-line drawings alone are not architectures. which comprise software components.page 23 . the externally visible properties of those components.Carnegie Mellon University Software Engineering Institute The Definition of Software Architecture The software architecture of a program or computing system is the structure or structures of the system. • architecture includes behavior of components © 1999 by Carnegie Mellon University Version 1. Lecture 1 . but a starting point. and the relationships among them.

Lecture 1 . They suggest patterns of runtime interaction. and topologies of components.0 CECOM Course 2. Styles are underspecified architectures. © 1999 by Carnegie Mellon University Version 1.page 24 .Carnegie Mellon University Software Engineering Institute Architectural Style -1 Architectural style: a description of component and connector types and a pattern of their runtime control and/or data transfer [Shaw 96] Architectural styles are a set of canonical architectural solutions to problems.

Lecture 1 .page 25 .Carnegie Mellon University Software Engineering Institute Architectural Style -2 A style may be thought of as • a set of constraints on an architecture • an abstraction for a set of related architectures Styles appearing in the literature include • client server • cooperating process • data-centered • layered © 1999 by Carnegie Mellon University Version 1.0 CECOM Course 2.

1045 Break 1045 .1030 Why is architecture important? 1030 .1200 New developments in software architecture © 1999 by Carnegie Mellon University Version 1.page 26 .1115 Architectural structures 1115 .0945 The Architecture Business Cycle 0945 -1000 What is architecture? 1000 .0915 Introductions 0915 .Carnegie Mellon University Software Engineering Institute Schedule and Outline 0900 . Lecture 1 .0 CECOM Course 2.

Carnegie Mellon University Software Engineering Institute Importance of Architecture to a Development Organization’s Business Software for a system or group of systems • provides leverage over a marketplace • provides a vehicle for management oversight • provides for the scoping of products • can be used as a sales tool (e.. Lecture 1 .0 CECOM Course 2.g. conforms to industry standards) Enterprise architectures enable • shorter learning time • specialized tool support • sharing of infrastructure costs among systems © 1999 by Carnegie Mellon University Version 1.page 27 .

Carnegie Mellon University Software Engineering Institute Important of Architecture to a Development Project Architecture is important for three primary reasons. It is the manifestation of the earliest design decisions about a system.0 CECOM Course 2. 2. © 1999 by Carnegie Mellon University Version 1. It provides a vehicle for communication among stakeholders. reusable abstraction of a system. 1. 3.page 28 . Lecture 1 . It is a transferable.

cost • implementing management decisions and allocations Architecture constrains the implementation and therefore the implementors • implementations must conform to architecture • (global) resource allocation decisions constrain implementations of individual components © 1999 by Carnegie Mellon University Version 1.Carnegie Mellon University Software Engineering Institute Communication Vehicle Architecture is a frame of reference in which competing interests may be exposed. Lecture 1 . • negotiating requirements with users • keeping customer informed of progress.page 29 . negotiated.0 CECOM Course 2.

0 CECOM Course 2. Lecture 1 .page 30 .Carnegie Mellon University Software Engineering Institute Result of Early Design Decisions -1 The architecture dictates organizational structure for development/maintenance efforts. planning • basis of work breakdown structure • organization for documentation • organization for CM libraries • basis of integration • basis of test plans. Examples include • division into teams • units for budgeting. architecture is extremely hard to change! © 1999 by Carnegie Mellon University Version 1. testing • basis of maintenance Once decided.

Carnegie Mellon University Software Engineering Institute Result of Early Design Decisions -2 Architecture permits/precludes achievement of a system’s desired quality attributes. kernels) localization of resources inter-component usage inter-component coupling The architecture influences qualities.page 31 . Lecture 1 . © 1999 by Carnegie Mellon University Version 1. but does not guarantee them.0 CECOM Course 2.. specialized components (e. g. For example: If you desire performance modifiability security scalability ability to subset reusability Examine inter-component communication component responsibilities inter-component communication.

page 32 .0 CECOM Course 2. and coordination mechanisms A good architecture is one in which the most likely changes are also the easiest to make. • local: modifying a single component • non-local: modifying several components • architectural: modifying the gross system topology.Carnegie Mellon University Software Engineering Institute Result of Early Design Decisions -3 An architecture helps users reason about and manage change (about 80% of effort in systems occurs after deployment). Lecture 1 . communication. © 1999 by Carnegie Mellon University Version 1. Architecture divides all changes into three classes.

© 1999 by Carnegie Mellon University Version 1. Entire product lines can share a single architecture.0 CECOM Course 2.page 33 . many systems). Lecture 1 .Carnegie Mellon University Software Engineering Institute Reusable Model An architecture is an abstraction: a one-to-many mapping (one architecture. Architecture is the basis for product (system) commonality. Systems can be built from large. externally developed components that are tied together via architecture.

0 CECOM Course 2.1200 New developments in software architecture © 1999 by Carnegie Mellon University Version 1.Carnegie Mellon University Software Engineering Institute Schedule and Outline 0900 .0945 The Architecture Business Cycle 0945 -1000 What is architecture? 1000 .1045 Break 1045 .page 34 .1115 Architectural structures 1115 .0915 Introductions 0915 . Lecture 1 .1030 Why is architecture important? 1030 .

page 35 .1115 Architectural structures 1115 . Lecture 1 .0915 Introductions 0915 .0945 The Architecture Business Cycle 0945 -1000 What is architecture? 1000 .1030 Why is architecture important? 1030 .1045 Break 1045 .Carnegie Mellon University Software Engineering Institute Schedule and Outline 0900 .1200 New developments in software architecture © 1999 by Carnegie Mellon University Version 1.0 CECOM Course 2.

Carnegie Mellon University Software Engineering Institute Architectural Structures -1 In a house. there are plans for • rooms • electrical wiring • plumbing • ventilation Each of these constitutes a “view” of the house. © 1999 by Carnegie Mellon University Version 1.page 36 . • used by different people • used to achieve different qualities in the house • serves as a description and prescription So it is with software architecture.0 CECOM Course 2. Lecture 1 .

Lecture 1 . and why? Common structures include • module • process • uses • calls • data flow • class • physical A structure provides a view of the architecture.page 37 . © 1999 by Carnegie Mellon University Version 1.Carnegie Mellon University Software Engineering Institute Architectural Structures -2 Which structures are used.0 CECOM Course 2.

Lecture 1 .” “shares a secret with” Used: as a basis of team structure and resource allocation Affected attributes include: maintainability. understandability © 1999 by Carnegie Mellon University Version 1.page 38 . work assignments Relations: “is a submodule of.Carnegie Mellon University Software Engineering Institute Module Structure Components: modules.0 CECOM Course 2.

exploit multiprocessing hardware Affected attributes include: performance © 1999 by Carnegie Mellon University Version 1. processes Relations: “synchronizes with. Lecture 1 .0 CECOM Course 2.” “preempts” Used: to tune system runtime performance.Carnegie Mellon University Software Engineering Institute Process Structure Components: tasks.page 39 .” “excludes.

Carnegie Mellon University Software Engineering Institute Uses Structure Components: procedures Relations: “assumes the correct presence of” Used: to engineer subsets. supersets Affected attributes include: reusability.page 40 . testability. incremental development © 1999 by Carnegie Mellon University Version 1.0 CECOM Course 2. Lecture 1 .

maintainability. for debugging Affected attributes include: buildability.page 41 .Carnegie Mellon University Software Engineering Institute Calls Structure Components: procedures Relation: invokes Used: to trace control flow.0 CECOM Course 2. Lecture 1 . understandability © 1999 by Carnegie Mellon University Version 1. testability.

Lecture 1 .0 CECOM Course 2.Carnegie Mellon University Software Engineering Institute Data Flow Structure Components: programs. accuracy © 1999 by Carnegie Mellon University Version 1. correctness.page 42 . modules Relation: “may send data to” Used: for traceability of functionality Affected attributes include: performance.

” “is instance of” Used: to exploit similarity among objects Affected attributes include: development time. Lecture 1 .0 CECOM Course 2. maintainability © 1999 by Carnegie Mellon University Version 1.page 43 .Carnegie Mellon University Software Engineering Institute Class Structure Components: objects Relation: “inherits from.

Lecture 1 . processors Relation: “resides on same processor” Used: to manage process-to-processor allocation Affected attributes include: performance © 1999 by Carnegie Mellon University Version 1.page 44 . processes.0 CECOM Course 2.Carnegie Mellon University Software Engineering Institute Physical Structure Components: tasks.

Lecture 1 .page 45 .Carnegie Mellon University Software Engineering Institute What Are Structures Used For? Descriptive: documentation vehicle for • current development • future development • managers • customers To document the architecture. Prescriptive: engineering tool to help achieve qualities © 1999 by Carnegie Mellon University Version 1. document the views.0 CECOM Course 2.

(For example. different structures collapse into a single one. process structure may be the same as module structure for extremely small systems.) © 1999 by Carnegie Mellon University Version 1. Lecture 1 .0 CECOM Course 2.page 46 . In some systems.Carnegie Mellon University Software Engineering Institute Architectural Structures Summary Structures are related to each other in complicated ways.

page 47 . More later.) What to do? Choose the structures that are useful to the system being built and to the achievement of qualities that are important to you. © 1999 by Carnegie Mellon University Version 1. Lecture 1 . but these are not views of the software architecture.Carnegie Mellon University Software Engineering Institute Which Views Should I Use? Rational Unified Process: 4+1 views Siemens 4-view model (C4ISR framework prescribes 3 views.0 CECOM Course 2.

Lecture 1 . S. used from the 1960s through the 1980s Small computer on board for navigation. light attack aircraft.Carnegie Mellon University Software Engineering Institute Architectural Structures Example: A-7E Corsair II Aircraft U.page 48 .0 CECOM Course 2. weapons delivery © 1999 by Carnegie Mellon University Version 1. carrier-based.

Hardware-Hiding Module Extended computer module Behavior-Hiding Module Shared services module © 1999 by Carnegie Mellon University Version 1.page 49 . Lecture 1 .0 CECOM Course 2. Filter behavior module Software utilities module System generation mod.Carnegie Mellon University Software Engineering Institute A-7E Module Structure (2 Levels) Software -Decision-Hiding Module Device interface module Function driver module Data banker module Physical models module Application data types mod.

page 50 .0 CECOM Course 2.Carnegie Mellon University Software Engineering Institute Data Flow View Pilot. Lecture 1 . external world Device interfaces values to display sensor inputs Data banker computed values stored values stored values calculated real-world values Physical models Shared services sensor values filtered values computed values Function drivers Filter behaviors © 1999 by Carnegie Mellon University Version 1.

0 CECOM Course 2.Carnegie Mellon University Software Engineering Institute “Uses” View Function drivers Shared services Data banker Physical models Filter behaviors Software utilities Device interfaces Application data types Extended computer © 1999 by Carnegie Mellon University Version 1.page 51 . Lecture 1 .

page 52 .0 CECOM Course 2.Carnegie Mellon University Software Engineering Institute A-7E Subset: Display HUD Altitude Function drivers Shared services Data banker Physical models Filter behaviors Software utilities Device interfaces Application data types Extended computer © 1999 by Carnegie Mellon University Version 1. Lecture 1 .

documented as views.0 CECOM Course 2. Lecture 1 . Engineer and document the structures that help to achieve your desired qualities.page 53 . © 1999 by Carnegie Mellon University Version 1. Each structure provides engineering leverage on different qualities.Carnegie Mellon University Software Engineering Institute Lecture Summary -1 Architecture is important because • it provides a communication vehicle among stakeholders • it is the result of the earliest design decisions system about a An architecture is composed of many structures. which are software components and their relationships.

1045 1045 .1030 1030 .Predictable assembly from certifiable components Version 1.Software product lines .Carnegie Mellon University Software Engineering Institute Schedule and Outline 0900 .0915 0915 .1115 1115 .0945 0945 -1000 1000 . Lecture 1 .1200 Introductions The Architecture Business Cycle What is architecture? Why is architecture important? Break Architectural structures New developments in software architecture .0 CECOM Course 2.page 54 © 1999 by Carnegie Mellon University .Aspect-oriented software development .

page 55 .Carnegie Mellon University Software Engineering Institute CelsiusTech Systems Swedish defense contractor • approximately 2000 employees • about $300 million in annual sales Long-time supplier of naval shipboard command and control systems © 1999 by Carnegie Mellon University Version 1. Lecture 1 .0 CECOM Course 2.

Carnegie Mellon University Software Engineering Institute 1985: Disaster Struck! CelsiusTech marketers landed two large contracts simultaneously. • Earlier systems were troublesome to integrate and had cost schedule overruns.page 56 .000.0 CECOM Course 2. Lecture 1 . • 1. © 1999 by Carnegie Mellon University Version 1.000 SLOC each (estimated) • greater complexity of requirements than before CelsiusTech realized they could not fulfill both contracts unless they started doing business in a totally new way. • Hiring was not an option: there was a shortage of engineers.

software .0 CECOM Course 2. Lecture 1 .supporting development approach • configure systems from product family.page 57 .hardware. each new project was added to the family © 1999 by Carnegie Mellon University Version 1.Carnegie Mellon University Software Engineering Institute CelsiusTech’s Response Business strategy • create a product family • make the software scaleable over a wide range of systems Technical strategy • create a new generation of system .

Carnegie Mellon University Software Engineering Institute What CelsiusTech Did Assembled a small expert architecture team with • extensive domain knowledge • previous systems experience • Objective: produce architecture that would suffice for both systems plus new systems in the same domain. Lecture 1 . .page 58 construction.0 © 1999 by Carnegie Mellon University CECOM Course 2. not Version 1. configurable across a wide variety of envisioned uses System-building became a matter of integration. Produce software components that populated this architecture • Components were flexible.

0 CECOM Course 2. processor Workstation © 1999 by Carnegie Mellon University Version 1.Carnegie Mellon University Software Engineering Institute SS2000 System Architecture Workstation Processor Data processor Gun processor Surface to air missile interface Radar detector E/O director Torpedo processor dual Ethernet LAN Workstation Processor Data processor Processor Standard interface unit Surface to surface missile interface Plot and target extractor Video switch Comm.page 59 . Lecture 1 .

Lecture 1 .0 CECOM Course 2.Carnegie Mellon University Software Engineering Institute Typical System Configuration 15-30 nodes on LAN 30-70 CPUs 100-300 Ada programs 1-1.page 60 .5 million Ada SLOC © 1999 by Carnegie Mellon University Version 1.

0 CECOM Course 2.Carnegie Mellon University Software Engineering Institute Members of SS2000 Product Family Over 55 variants • 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 © 1999 by Carnegie Mellon University Version 1. Lecture 1 .page 61 .

page 62 .0 CECOM Course 2. Lecture 1 .Carnegie Mellon University Software Engineering Institute Result of Changes: Shrinking. Predictable Schedules A B C Ships D E F G 1986 1988 1990 1992 1994 1996 Hardware-to-software cost ratio changed from 35:65 to 80:20 © 1999 by Carnegie Mellon University Version 1.

page 63 . Lecture 1 .0 CECOM Course 2.Carnegie Mellon University Software Engineering Institute Result of Changes: Lower Staffing 200 180 160 140 120 100 80 60 40 20 0 1986 1987 1988 1989 1990 1991 1992 1993 1994 1995 1996 © 1999 by Carnegie Mellon University Version 1.

Lecture 1 .0 CECOM Course 2.Carnegie Mellon University Software Engineering Institute Result of Changes: Reuse 140 Number of System Modules 120 100 80 60 40 20 0 A Unique application National application © 1999 by Carnegie Mellon University B Ships Modified C D E Common (verbatim) Reusable application Version 1.page 64 .

0 CECOM Course 2.page 65 .Carnegie Mellon University Software Engineering Institute Cummins. © 1999 by Carnegie Mellon University Version 1. World’s largest manufacturer of large diesel engines. Inc. Lecture 1 .

assembler. economy. requirements © 1999 by Carnegie Mellon University Version 1. emissions • Conditions change dynamically as function of road incline. temperature.page 66 . etc. platforms. • 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 -.Carnegie Mellon University Software Engineering Institute Complex domain of variation Today’s diesel engines are driven by software • Micro-control of ignition timing to achieve optimum mix of power.C. Lecture 1 . load. microcode • Different sensors.0 CECOM Course 2.

Lecture 1 . Cummins had a problem Six engine projects were underway Another 12 were planned. Two were trying to use O-O methods. Each project had complete control over its development process. architecture. © 1999 by Carnegie Mellon University Version 1.out of the question.0 CECOM Course 2.page 67 .Carnegie Mellon University Software Engineering Institute In 1993. even choice of language. Ron Temple (VP in charge) realized that he would need another 40 engineers to handle the new projects -. This was no way to do business.

page 68 . • One half built core assets -.Carnegie Mellon University Software Engineering Institute What Cummins did In May. 1994 Temple halted all the projects. the product was launched on time (relative to re-vamped schedule) with high quality. documentation. © 1999 by Carnegie Mellon University Version 1. Others followed. Lecture 1 .generic software. and other assets that every product could use • Other half became pilot project for using the core assets to turn out a product In 1995. He split the leading project.0 CECOM Course 2.

© 1999 by Carnegie Mellon University Version 1.page 69 .164 liter displacement • 12 kinds of electronic control modules • 5 kinds of microprocessors • 10 kinds of fuel systems • diesel fuel or natural gas Highly parameterized code. 300 parameters are available for setting by the customer after delivery.0 CECOM Course 2.Carnegie Mellon University Software Engineering Institute Cummins’ results Achieved a product family capability with a breathtaking capacity for variation.9 . Lecture 1 . or customization • 9 basic engine types • 4-18 cylinders • 3.

Time to first engine start went from 250 person-months to a few person-months. on average. which Cummins attributes to product line approach. © 1999 by Carnegie Mellon University Version 1.Carnegie Mellon University Software Engineering Institute Cummins’ results by the numbers -1 • 20 product groups launched. • Software quality is at an all-time high. which account for over 1000 separate engine applications • 75% of all software. Lecture 1 . One prototype was bulit over a weekend.0 CECOM Course 2.page 70 . comes from core assets • Product cycle time has plummeted.

Productivity gains enables new features to be developed (more than 200 to date) • Projects are more successful. Before product line approach. Now. • Widespread feeling that developers are more portable. and 3 were on the edge.0 CECOM Course 2.page 71 . 4 were failing. © 1999 by Carnegie Mellon University Version 1.Carnegie Mellon University Software Engineering Institute Cummins’ results by the numbers -2 • Customer satisfaction is high. Lecture 1 . and hence more valuable. 3 of 10 were on track. 15 of 15 are on track.

Lecture 1 .Carnegie Mellon University Software Engineering Institute Cummins’ results by the numbers -3 Supported Components 1992 1993 1994 1995 1996 1997 1998 ====================================================== Electronic control modules (ECMs) 3 3 4 5 5 11 12 Fuel systems Engines Features * ECM 2 3 60 2 3 80 3 5 180 5 5 5 12 10 16 11 17 370 1100 2200 2400 Achieving this flexibility without the product line approach would have required 3.0 CECOM Course 2.page 72 . © 1999 by Carnegie Mellon University Version 1.6 times the staff Cummins has.

Carnegie Mellon University Software Engineering Institute Cummins’ results by the numbers -4 Cummins management has a history of embracing change. Lecture 1 . but carefully targeted change. They estimate that the product line approach has brought a benefit/cost ration of 10:1.page 73 . © 1999 by Carnegie Mellon University Version 1. They esimate that process improvement alone has brought a benefit/cost ration of 2:1 to 3:1. Product line approach let them quickly enter and then dominate the industrial diesel engine market.0 CECOM Course 2.

Carnegie Mellon University Software Engineering Institute Two companies. CECOM Course 2. same goals High quality High quality Quick time to market Quick time to market Effective use of limited resources Effective use of limited resources Product alignment Product alignment Low cost production Low cost production Low cost maintenance Low cost maintenance Mass customization Mass customization Improved efficiency and productivity How? Strategic reuse. Lecture 1 .0 .page 74 © 1999 by Carnegie Mellon University Version 1.

page 75 . Lecture 1 .Carnegie Mellon University Software Engineering Institute Reuse History: From Ad-Hoc to Systematic 1960’s Subroutines 1970’s Modules 1980’s Objects 1990’s Components 2000’s Software Product Lines © 1999 by Carnegie Mellon University Version 1.0 CECOM Course 2.

0 CECOM Course 2. Lecture 1 .page 76 .Carnegie Mellon University Software Engineering Institute What Is a Product Line? A product line is a group of products sharing a common. pertain to Market strategy/ Application domain Products © 1999 by Carnegie Mellon University Version 1. managed set of features that satisfy specific needs of a selected market or mission.

Carnegie Mellon University

Software Engineering Institute

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.

© 1999 by Carnegie Mellon University

Version 1.0

CECOM Course 2, Lecture 1 - page 77

Carnegie Mellon University

Software Engineering Institute

Software Product Lines
pertain to Market strategy/ Application domain is satisfied by share an Architecture Products are built from used to structure Components CORE ASSETS

Product lines
• • • • take economic advantage of commonality take economic advantage of commonality bound variability bound variability
Version 1.0 CECOM Course 2, Lecture 1 - page 78

© 1999 by Carnegie Mellon University

Carnegie Mellon University

Software Engineering Institute

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 product lines = strategic reuse
© 1999 by Carnegie Mellon University Version 1.0 CECOM Course 2, Lecture 1 - page 79

earlier lifecycle reuse more benefit

page 80 . Lecture 1 .Carnegie Mellon University Software Engineering Institute Economics of Product Lines Current Practice Cumulative Cost With Product Line Approach Number of Products Derived from data supplied by Lucent Technologies Bell Laboratories Innovations © 1999 by Carnegie Mellon University Version 1.0 CECOM Course 2.

Lecture 1 .Carnegie Mellon University Software Engineering Institute The Key Concepts Use of a common asset base in production of a related set of products Architecture Scope Definition Production Plan Business Case Version 1.0 CECOM Course 2.page 81 © 1999 by Carnegie Mellon University .

. to launch. Lecture 1 .0 CECOM Course 2..Carnegie Mellon University Software Engineering Institute Organizational Benefits Improved productivity by as much as 10x Decreased time to market (to field.) by as much as an order of magnitude Decreased cost by as much as 60% Decreased labor needs by as much as 10X fewer software developers Increased quality by as much as 10X fewer defects © 1999 by Carnegie Mellon University Version 1.page 82 .

Carnegie Mellon University Software Engineering Institute Product Line Practice Contexts for product lines vary widely • nature of products • nature of market or mission • business goals • organizational infrastructure • workforce distribution • process maturity • artifact maturity © 1999 by Carnegie Mellon University Version 1. CECOM Course 2. Lecture 1 .0 But there are universal essential elements and practices.page 83 .

• • • • People issues: how to bring about change. how to launch the effort Organizational structure: Who builds the core assets? Funding: How are the core assets paid for? Interacting with the customer has whole new dimension Version 1.Carnegie Mellon University Software Engineering Institute CelsiusTech and Cummins both learned vital lessons Lessons in software engineering • • • • • architectures for product lines testing variable architectures and components importance of having and capturing domain knowledge managing variations important of large.0 CECOM Course 2. Lecture 1 .page 84 © 1999 by Carnegie Mellon University . pre-integrated chunks Lessons in technical/project management • importance of configuration management. and why it’s harder for product lines • product line scoping: What’s in? What’s out? • Tool support for product lines Lessons in organizational management.

0 CECOM Course 2.Carnegie Mellon University Software Engineering Institute Embodying the knowledge: SEI Product Line Practice Framework Web-based.page 85 . evolving document Describes product line essential activities • Core asset development • Product development • Management Describes essential and proven product line practices in the areas of • software engineering • technical management • organizational management © 1999 by Carnegie Mellon University Version 1. Lecture 1 .

page 86 .Carnegie Mellon University Software Engineering Institute Framework Goals Identify the foundational concepts underlying the software product lines and the essential issues to consider before fielding a product line. Provide guidance to an organization about how to move to a product line approach for software. © 1999 by Carnegie Mellon University Version 1. Lecture 1 . Define practices in each practice area where current knowledge is sufficient to do so.0 CECOM Course 2. Identify practice areas that an organization creating or acquiring software product lines must master.

Lecture 1 .0 CECOM Course 2. experience reports.page 87 .Carnegie Mellon University Software Engineering Institute SEI Information Sources Case studies. and pilots Workshops Surveys Collaborations with customers on actual product lines © 1999 by Carnegie Mellon University Version 1.

Carnegie Mellon University Software Engineering Institute Practice Areas A practice area is a body of work or a collection of activities that an organization must master to successfully carry out the essential work of a product line. Lecture 1 . • Are finer chunks than the essential activities • Must be mastered to carry out the essential activities • Provide starting points for organizations wanting to make and measure product line progress © 1999 by Carnegie Mellon University Version 1.0 CECOM Course 2.page 88 .

Carnegie Mellon University Software Engineering Institute Software Engineering Practice Areas Architecture Definition Architecture Evaluation Component Development COTS Utilization Mining Existing Assets Requirements Engineering Software System Integration Testing Understanding Relevant Domains © 1999 by Carnegie Mellon University Version 1.page 89 . Lecture 1 .0 CECOM Course 2.

Metrics. and Tracking Make/Buy/Mine/Commission Analysis Process Definition Product Line Scoping Technical Planning Technical Risk Management Tool Support © 1999 by Carnegie Mellon University Version 1.Carnegie Mellon University Software Engineering Institute Technical Management Practice Areas Configuration Management Data Collection.page 90 . Lecture 1 .0 CECOM Course 2.

Carnegie Mellon University Software Engineering Institute Organizational Management Practice Areas Achieving the Right Organizational Structure Building and Communicating a Business Case Customer Interface Management Developing and Implementing an Acquisition Strategy Funding Launching and Institutionalizing a Product Line Market Analysis Operations Organizational Planning Organizational Risk Management Technology Forecasting Training © 1999 by Carnegie Mellon University Version 1. Lecture 1 .page 91 .0 CECOM Course 2.

Lecture 1 .ground-based satellite systems • first family member required 1/10 normal number of developers Hewlett Packard .FLEXworks Project (family of one-way pagers) • 4x cycle time improvement • 80% reuse Nokia .1 Motorola .mobile phones • went from 4 different phones produced per year to 50 per year National Reconnaissance Office’s Control Channel Toolkit .printer systems • 2-7x cycle time improvement (some 10x) • Sample Project –shipped 5x number of products –that were 4x as complex –and had 3x the number of features –with 4x products shipped/person Version 1.0 © 1999 by Carnegie Mellon University CECOM Course 2.Carnegie Mellon University Software Engineering Institute Examples of Product Line Practice .page 92 .

page 93 .3 MarketMaker Software AG .0 CECOM Course 2. Lecture 1 .German financial info provider • able to field a customer-specific solution in about a week • small company (under 50 people) © 1999 by Carnegie Mellon University Version 1.Carnegie Mellon University Software Engineering Institute Examples of Product Line Practice .

define the product line’s scope proactively • Learn all you can from domain analysis • Product line adoption is an organization-wide affair • Cummins and CelsiusTech both took this approach Reactive • Start with 1-2 products • React to new customers as they arrive Extractive • Extract commonality from existing products • Form common asset base from what you already have • Product line adoption can start in small pockets.Carnegie Mellon University Software Engineering Institute Adoption strategies Proactive (predictive) • Look ahead. spread as acceptance grows © 1999 by Carnegie Mellon University Version 1.0 CECOM Course 2. Lecture 1 .page 94 .

Lecture 1 .0 Linda Northrop Director Product Line Systems Program Telephone: 412-268-7638 Email: lmn@sei.edu World Wide Web: http://www. PA 15213-3890 SEI Fax: 412-268-5758 CECOM Course 2.cmu.edu For questions about this talk: Paul Clements Product Line Systems Program Email: clements@sei.S. mail: Software Engineering Institute Carnegie Mellon University Pittsburgh.edu U.smu.cmu.cmu.edu/plp © 1999 by Carnegie Mellon University Version 1.page 95 .sei.Carnegie Mellon University Software Engineering Institute For Additional Information on SEI’s Product Line Systems Program Dave White Business Development Product Line Systems Program Telephone: 412-268-4796 Email: dwhite@sei.

Architecture evaluation .Achievement of system qualities through architecture © 1999 by Carnegie Mellon University Version 1.Carnegie Mellon University Software Engineering Institute To read more about CelsiusTech Software Architecture in Practice Len Bass Paul Clements Rick Kazman Addison Wesley 1998 .page 96 .Seven case studies in successful software architectures .0 CECOM Course 2. Lecture 1 .Architecture business cycle .

Carnegie Mellon University Software Engineering Institute To read more about Cummins Software Product Lines: Practices and Patterns Paul Clements Linda Northrop Addison Wesley 2001 ~600 pages .Product line fundamentals and economics .Practice areas described .0 CECOM Course 2.Patterns for adoption .page 97 .3 Detailed case studies .Product Line Technical Probe © 1999 by Carnegie Mellon University Version 1. Lecture 1 .

Software product lines . Lecture 1 .1200 Introductions The Architecture Business Cycle What is architecture? Why is architecture important? Break Architectural structures New developments in software architecture .0915 0915 .Carnegie Mellon University Software Engineering Institute Schedule and Outline 0900 .Aspect-oriented software development .1045 1045 .1115 1115 .1030 1030 .0945 0945 -1000 1000 .Predictable assembly from certifiable components Version 1.page 98 © 1999 by Carnegie Mellon University .0 CECOM Course 2.

interaction protocols .an architectural packaging decision . Lecture 1 .” Recognition that separation of concerns may be performed in many ways.Carnegie Mellon University Software Engineering Institute Aspect-Oriented Software Development (AOSD) Also called “multi-dimensional separation of concerns. Example: • Dividing a system into elements based on likely application-based changes • Each element still must reflect .…and many others © 1999 by Carnegie Mellon University Version 1.a particular error-handling philosophy .0 CECOM Course 2.page 99 .naming conventions .

AOSD represents the introduction of truly architectural thinking into program development. © 1999 by Carnegie Mellon University Version 1.Carnegie Mellon University Software Engineering Institute AOSD (cont’d.) AOSD tools and languages let programmers weave these separate concerns together in discrete elements.0 CECOM Course 2.aosd. For more information: http://www. Lecture 1 .net.page 100 . so that these global design decisions (that have farreaching effects) can be changed locally.

1115 1115 .1045 1045 .Aspect-oriented software development .Carnegie Mellon University Software Engineering Institute Schedule and Outline 0900 .page 101 © 1999 by Carnegie Mellon University .1200 Introductions The Architecture Business Cycle What is architecture? Why is architecture important? Break Architectural structures New developments in software architecture .Predictable assembly from certifiable components Version 1.1030 1030 .Software product lines .0915 0915 . Lecture 1 .0945 0945 -1000 1000 .0 CECOM Course 2.

Lecture 1 .page 102 .Carnegie Mellon University Software Engineering Institute Predictable Assembly of Certifiable Components (PACC) At the vanguard of work on component-based systems. © 1999 by Carnegie Mellon University Version 1. and building frameworks for component-based systems. This work focuses on building systems with provable quality attributes from components.0 CECOM Course 2. Previous work has concentrated on component selection and qualification.

Preliminary results with latency.edu/pacc/index. For more information: http://www.cmu. starting to work on reliability.html © 1999 by Carnegie Mellon University Version 1. what can you conclude about the qualities of a system including those component? • Given a quality attribute need for a system.page 103 .Carnegie Mellon University Software Engineering Institute PACC -2 Two driving questions: • Given a set of components with certified quality attributes. what must you be able to certify about its components to know you’ve satisfied that need? Very early work.0 CECOM Course 2.sei. Lecture 1 .

Sign up to vote on this title
UsefulNot useful