Software architecture for product lines

1. Rodrigo Mendes Software architecture for product lines

2. Schedule • Software Product Lines • Architecture for Product Lines • SLA Quality Tools • Nortel’s Study Case • Conclusion • References

3. Software Product Lines (SPL)

4. Motivation • Based on approaches like Eli Whitney (interchangeable parts) and Henry Ford (interchange parts and assembly line) • Standard Practice that proposes a proative reuse, stimulating interchangeable components to construct high-quality products faster and cheaper.

5. [MCGREGOR et al] • Introduction of SPL in a organization has two strategies: • Heavyweight Strategy – e.g. Cumins Company. • Lightweight Strategy – e.g. Nokia Company. A comparison of heavyweight and lightweight strategies and single-system development.

6. Keys of Success • A successful SPL practice are common in three efforts: • Exploration of commonality among products; • Encouraging architecture centric development; • Two Tiered Organization Structure.

7. Exploring commonality and variability • “We consider a set of programs to constitute a family whenever it is worthwhile to study programs from the set by first studying the common properties of the set and then determining the special properties of the individual family members.” [David Parnas] • SPL scope is specified such that the products have a high degree of commonality.

8. Exploring commonality and variability • Variation points has two major dimensions: • Time Dimension • Space Dimension • In a heavyweight strategy, assets are acquired before creating products. • In lightweight initiation schemes, assets are acquired in time production.

9. Architecture centric development • Architecture is the major key to a SPL strategy have success. • Creation of a design architecture for SPL provides a set a range of values for each quality attribute necessary to represent all products.

10. Two Tiered Organization Structure • A organization using SPL practice facilitates two fundamental roles: • Development of reusable assets • Development of products that uses those assets • In heavyweight approaches, there are a specific team to produce assets, components and architecture. • In lightweight approaches, few products are created and then mining efforts to extract common assets.

11. Software Product Line Architecture

12. Software Product Line Architecture (SPLA) • A product-line architecture is an abstraction: it is a specification of the high level structures of a family of applications. These structures reveal complementary facets of an architecture (static structure, dynamic structure, etc… ) and contain elements like components, connections, data, processes [Bass et al, 1998].

13. Architecture-Centric Evolution • In product lines, a key challenge is that a product line approach requires different methods of development. • In a product line approach, one must also consider requirements for the family of systems, and the relationship between those requirements and the ones associated with each particular instance.

14. [Garlan D.] • There must be an up-front (and on-going) investment in developing a reusable architecture that can be instantiated for each product. Product Line Architectures

15. [Lalanda P.] • A product-line architecture has to meet three fundamental requirements: • It has to drive the architectural design of new applications in the product-line; • It has to facilitate the reuse of components at the product-line level; • It has to permit various analyses in order to assess the impact (cost, performance, etc… ) of specific requirements for the development of new applications in the product-line.

16. [Lalanda P.] • A product-line architecture has to capture both architectural commonalities and variabilities of a family of applications. Commonalities and variabilities may concern any element of an architecture as components, topology, dynamics and physical environment for example.

17. Designing a SPLA • In order to design a SPLA, commonalities e variabilities must be expressed as follows: • Commonalities: • Standard software components and the way they are connected • Standard execution modes • Standard execution threads • Standard mappings onto execution platforms

18. Designing a SPLA • Variabilities: • As indicated in [Perry, 1998], several techniques can be used in order to encapsulate variability. The most important techniques are: Under-specification, Provisions and Decision points. • Can be expressed in three ways: • Encapsulating architectural elements that vary and to leave them unspecified; • Making provisions; • Encapsulating architectural elements that vary and to specify a list of possibilities or parameters.

19. Style Specific Techniques • A way to get more specific is to take into account architectural styles and to express what should be done to build a product-line architecture as a function of styles. • In order to achieve a more effective guidance, is necessary: • Identify in the business units the domains that could benefit from a product-line approach; • Identify the architectural styles used in the selected domains and describe them as architectural patterns; • Provide style-specific techniques to guide the design of product-line architectures in the selected domains.

20. E.g.: Repository Style • Components communicate via a shared memory called a repository. The repository represents the only vector of communication for the system components. • Repository styles are structured into: • Independent software components containing domain knowledge, called domain components. They are defined by their inputs and outputs; • A structured repository accessible by every component (read and write accesses); • A control component which purpose is to activate and coordinate the domain components.

21. E.g.: Repository Style • A set of actions should be performed to design a SLA in repository-style domains. The major actions are the following: • Standardisation of the shared repository; • Definition of reusable domain components; • Definition of a standard control component.

22. Feature-Oriented Reuse Method (FORM) • The Feature-Oriented Domain Analysis (FODA) method has a focus on requirements in assets core development. • Although marketing and product plan (MPP) can provide new assets. • FORM is an extension of FODA with support to architecture design and object-oriented component development, also incorporating a marketing perspective and exploring its analysis and design issues.

23. Feature-Oriented Reuse Method (FORM) • Consists in two major processes: • Asset development Consists in analyse product line and developing architectures and reusable components based on analysis results. • Product development Includes analysis requirements, selecting features and architecture and adapting components and generating code for the product.

24. Feature-Oriented Reuse Method (FORM) Feature-Oriented Reuse Method product line engineering process.

25. Feature-Oriented Reuse Method (FORM) Global control behavior of the low-end home integration system.

26. Evaluation of Product Line Methods • There are number of software architecture design methods have been developed. SPLIT, CoPAM and FORM are the major methods on achieve the needs of software product lines. • Evaluation Framework based on three sources: • NIMSAD (Normative Information Model-based Systems Analysis and Design) evaluation framework; • The definition of a method and its ingredients • Evaluation framework for component based software development methodologies • The evaluation results are divided into four elements: context, user, contents and validation.

27. Evaluation Elements The framework elements and the questions used in the analysis.

28. Evaluation of SPLA Methods Results • Context • FORM the most indepth method outputs by generating results that are quite close to the implementation; • CoPAM takes a wider insight into the issue by also considering the business and organizational aspects. • SPLIT method are at the domain modeling level, resulting in a definition of a product line by means of requirements, architecture, components and variation points.

29. Evaluation of SPLA Methods Results • User • None of the methods under evaluation highlight the user benefits of the methods. • SPLIT and CoPAM recognizes that a successful method utilizes skills that are already widely known among software professionals. The FORM method differs with the others in at least in two ways: first, it defines notation, techniques and a tool, ASADAL, explicitly. Second, the skills that are explicitly specified are not widely known among software developers. • Under the interpretation above, SPLIT and CoPAM are more practical methods and aimed at industrial use, whereas FORM is aimed at the academic audience.

30. Evaluation of SPLA Methods Results • Contents • FORM and the SPLIT methods state that an interface between the requirements and architecture design is needed. • For instance, platform engineering of CoPAM develops a platform of reusable components, which refers to the design of domain components and architecture in FORM and SPLIT.

31. Evaluation of SPLA Methods Results • Validation • The SPLIT method is the most immature method, whereas the FORM is the most long-lived one, having being applied to several industrial case studies on various domains. • CoPAM is surely the first of its kind, but it comprises existing (and therefore mature) family engineering methods, and inherits the strengths of those methods;

32. SLA Quality Tools

33. SPLA Quality Tools • ARCHMETRIC • Tool that provides support an architect in identifying and locating potential structural weaknesses. • ARCHREFACTOR • Tool that complements Ménage (a design environment) in implementing a set of pre-defined refactoring strategies. An architect simply provides ARCHREFACTOR with input on which refactoring algorithm to apply on which part of the architecture.

34. Nortel’s Study Case

35. Nortel Study • Nortel’s leadership in digital switch architecture enabled the company to capture US and international markets. After the 1984 breakup of AT&T, only Nortel could provide Bell operating companies with the capability to offer customers equal access to long-distance carriers. The company’s high product quality allowed it to become the first digital switch supplier in Japan.

36. Nortel Study • Problem • After nearly 20 years of successful use, however, the digital switch architecture began to show signs of needing renewal. In the late 1980s, the company considered a major restructuring of the architecture, but the CEO decided to wait. This decision had severe consequences, with a reduction in product quality and a tripling in the length of release cycles. • Nortel later attributed these problems to architecture breakdown.2 The company took action and rebounded. After reporting substantial losses in 1993, Nortel posted profits of $408 million in 1994, $473 million in 1995, and $623 million in 1996.

37. Nortel Study - How do they get it? • The Answer was obtained through a rigorous methodology. The methodology applied is based on the following organizational principles: • Focusing on simplification, minimization, and clarification. • Adapting the architecture to future customer needs, technology, competition, and business goals. • Establishing a consistent and pervasive architectural rhythm—regular architecture and product releases that help coordinate the actions and expectations of all parties. • Partnering and broadening relations with stakeholders. • Maintaining a clear architecture vision across the enterprise. • Proactively managing risks and opportunities.

38. Nortel Study – The principles • Focusing on simplification • “A ruthless focus on simplification, clarification, and minimization is essential for a successful large software project”. [Booch] Simplification requires balancing the tension between the needs of current and potential users. (a) An architecture overly focused on future needs; (b) a well-balanced architecture; (c) an architecture overly focused on immediate needs.

39. Nortel Study - The principles • Adapting to future needs • Business pressures in 1986 caused the shifting of technology renewal funds to other uses. • In late 1980s, the architecture deteriorated, and developers would clone rather than share architecture components, increasing the amount of code. Initially this was seen as an increase in productivity,9 but by 1993 the time required to add features had tripled.

40. Nortel Study - The principles • Adapting to future needs • One manager said that instead of creating feature-rich products, they were creating products with “just the features that make you rich.” • The group planned the evolution of the architecture, tying new features to scheduled releases over the course of two years. Also, engineers worked collaboratively with customers and thus understood not only the technical aspects of the features, but also their market implications.

41. Nortel Study - The principles • Establishing architectural rhythm • Rhythm ensures that all involved—including customers, engineers, suppliers, managers, and executives— understand important issues and know their own responsibilities. • Planning, development, testing, problem resolution, creation of documentation, issuing of releases, and marketing all had their own predictable rhythm, and this allowed for synchronization and closure of tasks. Everyone knew the milestones preceding a release and the regular intervals between them.

42. Nortel Study - The principles • Establishing architectural rhythm In the case of architecture, balancing short-term results and far-reaching vision is a lot harder than it looks. Rhythm helps maintain a profitable balance.

43. Nortel Study - The principles • Partnering with stakeholders • Partnering was a key element in delivering the value of Nortel’s architecture. Internal stakeholders, like users and developers of architectures, encourage partnering and therefore reduce of architecture and product complexity. • Reward promotions and raises are influencied by Partnering.

44. Nortel Study - The principles • Maintaining Vision • Without a clear vision, something as abstract as a software architecture cannot be effectively shared. • Developers and users must feel confident that they know the general purpose of the designs and code and that they can identify individuals who know the details.

45. Nortel Study - The principles • Managing risks and opportunities • At specific stages, the architecture is reviewed with internal and external customers and stakeholders, tracking and testing the assumptions underlying customer requirements. • Risky areas were tested with prototypes representing alternative technical approaches, and the chosen solution was the first to be implemented, tested, and integrated. To avoid disrupting the rhythm of releases, the group delivered high-risk features in phases, over multiple releases.

46. Conclusion

47. Software Product Line Architecture (SPLA) • SPL is a trend of how produce software product lines, joining productivity, quality and reuse. • SPL challenges are more related to organizational problems than technical solutions. • SPLA is one of major ways to achieving a success SLA. • SPLA has some methods of design at community, and they are becoming mature, as we see in FORM.

48. References • Mcgregor, J. D. et al Initiating Software Product Lines. IEEE Software, 2002. • Kang C. el al, Feature-Oriented Product Line Engineering.IEEE Software, 2002. • David Garlan, Software Architecture: a Roadmap. School of Computer Science Carnegie Mellon University. ACM Press, 2000. • Philippe Lalanda, Style-specific techniques to design product-line architectures.

49. References • Mari Matinlassi, Evaluation of Product Line Architecture Design Methods. ICSR 2002, 2002. • Matt Critchlow et al, Refactoring Product Line Architectures. REFACE2003 , 2003. • David Dikel et al, Applying Software Product-Line Architecture. IEEE, 1997.