Software Architecture in Practice Chapter 15: Architecture as a Reusable Asset

1. Software Architecture in PracticeChapter 15: Architecture as a Reusable Asset

2. Lecture Objectives • This lecture will enable students to understand • how architecture is an asset that can be reused within an organization • what a product line is, and the role architecture plays in it • how architecture enables the construction of component-based systems • different approaches for dealing with component mismatch

3. Ways to Reuse an Architecture Within an Organization • Product line: Use an architecture as the basis for building a related set of products that share a managed set of features that together address a particular market segment. • Component-based system development: Use an architecture as a skeletal framework in which to plug replaceable components.

4. Product Lines and Component-Based Development • The two concepts are related and synergistic. • Component-based development is one way to produce an architecture-based product line. • The product line achieves different features by replacing discrete components. • Both require avoiding architectural mismatch to make the components work together correctly. • In mature domains, the architecture (and especially the set of components) becomes standard, the result of consensus.

5. Topics • Product lines • Component-based development • Architectural mismatch • Mature domains

6. Product Lines -1 • An architecture represents a significant investment. Why use it for only one system? • Architecture can form the foundation for a product line that allows competitive advantage in the marketplace. • Commercial examples include • cars • commercial aircraft • appliances • light bulbs

7. Product Lines -2 • Product lines built using a common set of assets epitomize strategic, planned reuse. • Individual systems (products) are modifications of a (hypothetical) central core system. • Products are produced by • tailoring the architecture • instantiating tailorable components • generating, rather than building • emphasizing integration, not coding

8. Product Lines -3 • Reuse potential exists for • architecture • software components and legacy systems • requirements and design decisions • documentation • algorithm research • test plans, test cases, testing • personnel and their expertise • business/management assets • schedules and budgets • marketing literature • processes and tools

9. Product Lines -4 • Benefits of reuse • defect reduction: defect fixed in one product automatically fixed for all future products • performance: performance issues addressed for all products (e.g., schedulability, deadlock, distributed system issues) • planning: more accurate because all products are produced in the same way • reduction in • time to market • staffing

10. Product Line Issues • Creation of core assets pushes cost of first product up: you must plan and price accordingly. • Evolution: as product line assets evolve, do you back-fit products? As products evolve, do you back-fit product line assets? • Organization: Unit that maintains core assets should be separate from units that produce products (and report to customers).

11. Product Line Organization/Roles Product line capabilities Marketers Customer Requirements Customerneeds Asset capabilities Product capabilities Managers Direct vision Detailed requirements Systems Core assets group Product production group Assets • understand domain • understand application • design with ease & skill • can abstract • are technically current • can mediate • understand application • understand customer • problems • can engineer from “building blocks” • can customize • have implementation • expertise develop assets choose assets

12. Topics • Product lines • Component-based development • Architectural mismatch • Mature domains

13. Component-Based Systems • Hardly any system is built completely from scratch these days. • It is better to buy components that fulfill your requirements than to build them. • quickly adopt new products/technology • reduce time to market • maintain high productivity: reuse/integrate, not code/test • concentrate on application area, requirements • use more reliable components • produce changeable, extensible systems

14. Drawbacks of Buying Components -1 • You don’t know if a component meets all of your requirements until you try it. • How secure is it? How reliable? • What is its performance? • Components that are “almost” compatible: “almost” is a euphemism for “not.” • Incompatibilities may not appear until after the system has been deployed and may be difficult or impossible to resolve.

15. Drawbacks of Buying Components -2 • Product evolution is out of your control and may be undesirable. • Vendor may go out of business. • There can be architectural incompatibilities: “architectural mismatch” due to different architectural assumptions.

16. Topics • Product lines • Component-based development • Architectural mismatch • Mature domains

17. Architectural Mismatch • An architecture is essential for building a component-based system. Architecture • identifies components to be built/bought • determines requirements for the components • Integrating components may be troublesome due to architectural mismatch (i.e., the components’ differing assumptions about each other). • What can you do about architectural mismatch? • detect it • repair it

18. Detecting Architectural Mismatch -1 • Be precise about what component functions and interactions are expected. • Interface • means more than application program interface • includes all the assumptions that components can make about each other • performance • use of shared resources • interconnection mechanisms • includes provides assumptions • includes requires assumptions

19. Detecting Architectural Mismatch -2 • Standards help, but often do not specify complete interfaces in this sense of the word. • Even if they do, how do you know that a component is compliant? • Often, rigorous component qualification is required. • uncover a component’s “requires” assumptions • verify and augment a component’s “provides” assumptions

20. Repairing Architectural Mismatch • Modifying legacy software by changing the implementation of one or more components • Introducing new software to fix the mismatch • wrapper: introduce new interface, replace all old calls with calls to new interface • bridge: similar to UNIX filters; separately invoked, separately running • mediator: includes a planning function that (at runtime) chooses which bridges to use to mediate between two components

21. Topics • Product lines • Component-based development • Architectural mismatch • Mature domains

22. Domain • A domain is a body of specialized knowledge. • A product or system often belongs to many domains. • For example, a management information system may comprise knowledge about • database management systems • enterprise management • business rules • accounting

23. Mature Domains -1 • Component-based systems are possible in mature domains. • Mature domains feature standard well-documented reference architectures. • compilers • database management systems • operating systems • network communication systems

24. Mature Domains -2 • Standard architectures create component markets. • Architectural standards can be formal or informal. • Design decisions have been made and agreed to by a community; this saves developers from having to work from first principles.

25. Stages of Maturation -1 • Reference models come from • researcher’s desire for abstraction • customer’s desire for basis for comparison of systems • Reference models yield • common understanding of problems • first approximation of work assignments

26. Stages of Maturation -2 • Reference architectures come from • product developers • standards groups • Reference architectures yield • interchangeable components • interoperable components

27. Stages of Maturation -3 • Component generators come from product development organizations. • Component generators yield rapid production of tailorable components. • Application generators come from product development organizations. • Application generators yield rapid production of systems.

28. Lecture Summary • Both product lines and component-based systems rely on architectures to allow different versions of the system to be fielded quickly and reliably. • Architectural mismatch is a danger in component-based systems. Mismatch can be detected or repaired. • Mature domains tend to produce common architectural models and reusable components.

29. Discussion Questions -1 • 1. Some writers draw a distinction between a • product line (a set of products that together • address a certain market segment or mission and • a product family (a set of products built from a • common set of software assets). Under this • distinction, a product line need not be a product • family if the products are built independently of • each other. In this lecture, we have been • describing a product line built as a product • family. Can you describe a product line that is • not a product family? Can you describe a • product family that is not a product line?

30. Discussion Questions -2 • 2. Suppose a company builds two similar systems • using a large set of common assets, including a • common architecture. Clearly these two systems • form a product line. Suppose the two systems • share only an architecture but no components. • Are they still a product line? Suppose they share • only a single component. What then? Suppose • that all they share is the same operating system • and programming language runtime libraries. Are • they a product line then? Suppose that the • shared asset between them is the same team of • developers. What about then?