David Weiss weiss@sei.pku

1. Software Product-Line Engineering: A Family-Based Software Development Process:Designing The Family David Weiss weiss@sei.pku.edu.cn

2. FAST Process • A process for defining families and developing environments for generating family members • Find abstractions common to the family • Define a process for producing family members • Design a language for specifying family members • Generate software from specifications • Family-oriented Abstraction, Specification, Translation

3. Product Engineering A FAST Process Investment Domain Engineering Feedback Product Engineering Environment Payback Products

4. The Domain Model • Conceptual Framework • Family Definition • Commonalities and Variabilities Among Family Members • Common Terminology for the Family • Decision Model • Economic Analysis • Product Line Architecture • Optional: Application Modeling Language (AML): Language for stating requirements • Mechanism for generating products • Composer or Compiler (AML)

5. The Conceptual Framework (1) • Qualify The Domain • Is it economically viable? • Artifact: Economic Model • Define The Family • What do members of the family have in common and how do they vary? • Artifact: The Commonality/Variability Analysis • Define The Decision Model • What decisions must be made to identify a family member? • Artifact: The Decision Model Table

6. The Conceptual Framework (2) • Create The Architecture • What is a good modular structure and a good uses structure? • Artifacts: Module Guide, Interface Specifications, Uses Relation • Design The System Composition Mapping • What modules are needed for which decisions? • Artifacts: System Composition Mapping, Uses Relation • Design The Product Engineering Environment • What are good mechanisms for using the decision model to produce products or to generate products from the AML? • Artifacts: Decision Model GUI, Generator or Compiler (AML)

7. Architecture for the Product Line • Purpose: Enable product generation through composition of modules, each module hiding a parameter of variation • Apply information hiding to create a modular architecture • Each variability is the hidden decision of a module • Define interface specifications for each module • Define a uses relation among programs that appear on module interfaces

8. FWS Module Structure FWS Device Interface Behavior Hiding Software Design Hiding Sensor Device Transmitter Device Message Generation Message Format Data Banker Sensor Monitor Averager

9. The Uses Relation • Program A uses program B means B must be present and operating correctly for A to operate correctly • Program = function, method, procedure, object, module, main program • “Operating correctly” = Conforming to its specification

10. FWS Uses Relation On Modules Controller Message Generation Sensor Monitor Averager Transmitter Device Driver Message Format Data Banker Sensor Device Driver

11. Importance of Uses (1) • Uses determines the order in which modules should be implemented • Data Banker & Sensor Device Driver Before Sensor Monitor & Averager Controller Message Generation Sensor Monitor Averager Transmitter Device Driver Message Format Data Banker Sensor Device Driver

12. Importance of Uses (2) • Uses determines the modules that are needed to build a family member • If message generation is included, then so must be averager, transmitter device driver, message format, data banker, sensor device driver Controller Message Generation Sensor Monitor Averager Transmitter Device Driver Message Format Data Banker Sensor Device Driver

13. Importance of Uses (3) • Uses determines the modules that are needed to build a family member • In most product lines, some modules are common and always included, some are only included for certain products Controller Message Generation Sensor Monitor Averager Transmitter Device Driver Message Format Laser Device Driver Data Banker Wind Speed Sensor Device Driver Water Temperature Sensor Device Driver

14. FWS Module Structure FWS Device Interface Behavior Hiding Software Design Hiding Sensor Device Transmitter Device Message Generation Message Format Data Banker Sensor Monitor Averager Wind Speed Sensor Device Driver Water Temperature Sensor Device Driver Laser Device Driver Radio Driver

15. Importance of Uses (4) • Uses determines the modules that are needed to build a family member • Modules at the lowest level that are needed to build a product are developed first • Modules at the lowest level are usually invoked most often and should execute fastest Controller Message Generation Sensor Monitor Averager Transmitter Device Driver Message Format Data Banker Sensor Device Driver

16. From Parameters Of Variation To Implementations: The Decision Model System Composition Mapping

17. InterludeArchitecture

18. What Is Architecture? “The art or science of building; esp. the art or practice of designing and building edifices for human use, taking both aesthetic and practical factors into account.” The Shorter Oxford English Dictionary, Fifth Edition, 2002 Merriam Webster Online Dictionary “In wider use, the term ‘architecture’ always means ‘unchanging deep structure.’ ” Stewart Brand, How Buildings Learn

19. Hagia Sophia, Istanbul

20. Built 532-537

21. Designers: Anthemius of Tralles and Isidorus of Miletus (Mathematicians, Engineers, Architects)

22. Pendentives

23. Hagia Sophia Interior.  Four arches swing across the piers, linked by four pendentives. The apices of the arches and the pendentives support the circular base of the huge central dome. http://www.patriarchate.org/ecumenical_patriarchate/chapter_4/html/hagia_sophia__page_2.html

24. St. Paul’s Cathedral, London

25. Architect: Sir Christopher Wren

26. Built 1675-1708

27. View From The Dome (1)

28. View From The Dome (2) Millenium Bridge

29. How Did They Know It Would Stay Up?

30. T R Buckling Load B ~ ET/R T= Thickness R= Radius E = Elastic Modulus • Assumptions • Spherical • Isotropic - identical properties at each point • How Did They Know It Would Stay Up? • Prototypes • Theoretical Models

31. Attributes Of An Admired Architecture • Distinctiveness (Istanbul and London landmarks) • Beauty • Utility (used every day) • Persistence (1500 years and more!!) • Features that delight (whispering gallery, dome view) • Maintainable • Safe • Buildable (safe intermediate states, affordable) • Different structures for different purposes (load bearing, interior layout, building services, …)

32. What is Software Architecture? • Literally Hundreds of definitions http://www.sei.cmu.edu/architecture/definitions.html • Architecture is focused on • Partitioning the whole into parts • Specifying the relations among the parts • Satisfying Requirements • Functional Requirements • End User Features … • Other Engineering Requirements • Performance & Scalability, Reliability & Availability …

33. The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them. "Externally visible” properties refers to those assumptions other elements can make of an element, such as its provided services, performance characteristics, fault handling, shared resource usage, and so on. Software Architecture in Practice (2nd edition), (Bass, Clements, Kazman; Addison-Wesley 2003

34. Structure (View) • A structure is a binary relation • Set of ordered pairs {(a,b), (c,d), (b,a), (c,e)} • Defining a structure • Define the set of elements • a,b,c,d,e • Define the relation • Enumeration • Rule • Example: connected graph • Elements: nodes in the graph: a,b,c,d,e,f,g • Relation: “is connected to” • {(a,b), (a,c), (b,d), (b,f), (f,e), (c.g)}

35. a b c d f g e

36. Architectural Structures • There are many stakeholders in the architecture of a software system – individuals or groups who have an interest in products built using the architecture. • Product Management • System Engineering • Architects • Software Development • System Verification • Information Development • Project Management • R&D Management • Professional Services • Services

37. Architectural Structures • Different Stakeholders have Different Concerns: Some Examples • Product Management • How can I explain this architecture to customers, in a way that “sells” it to them? • What product variations are supported by the architecture? • System Engineering • What functionality does the a product built using this architecture offer to its users? • How are the product requirements embodied in the software? • Architects • What changes may be needed in the software in the future, and what changes are likely and need to be especially easy to make in the future? • Software Development, • What implementation constraints must I satisfy when I implement a module? • What technologies and standards are used to implement the modules defined by the architecture?

38. Architectural Structures • Module Guide • Explains the principles used to design the information hiding structure of the architecture, and shows how responsibilities are allocated among the major modules. • Uses View • Describes the allowed “uses” relationships between modules and limits what other modules the implementer of a module may use. • Process View • Defines the distinct processes in the architecture; Specifies the module(s) that make up the process, synchronization between processes …

39. Architectural Structures • Technology View • Maps the technology or technologies that will be used to implement each module in the architecture. • Integration View • Highlights what data and modules within the system are externally accessible • Design View • Ties together all of these design perspectives (e.g., workflow, data model, report model ….) to ensure that application customization was consistent across the CRM System.

40. Architectural Structures • Module Interface Specs • Define Services Provided and Services Needed • Define syntax and semantics for accessing services • Define data types, program effects, … • Define test cases • Record design decisions and implementation notes

41. Structures and Models • Every view should have a model associated with it • Every model should help answer questions about the products • Questions are driven by the concern(s) associated with the view • What is the buckling load? • Typical questions • How much does it cost to make a particular type of change? • How does performance vary with load on the product? • What is the expected availability?

42. Product Line Architecture: The FWS As An Example • Product Line Concerns • How to create an architecture that accommodates variabilities? • How to generate/build products? • Architectural Structures • The module structure • Modules encapsulate variabilities • The uses structure • Uses assures completeness in generation/building

43. FWS Module Structure Controller FWS Message Generation Sensor Monitor Device Interface Behavior Hiding Software Design Hiding FWS Uses Structure Message Generation Sensor Device Transmitter Device Message Format Averager Data Banker Sensor Monitor Averager Transmitter Device Driver Message Format Data Banker Sensor Device Driver

44. Summary • The uses relation determines what modules need to be included in a family member • The uses relation determines in what order modules should be developed • The decision model and system composition mapping follow the uses relation to compose a family member

45. Terminology • Family • Product Line • Conceptual Model • Domain Engineering • Domain Model • Product Engineering (aka Application Engineering) • Product Engineering Environment • Decision Model • Commonality/Variability Analysis • System Composition Mapping • Application Modeling Language • Structure • Module • Information Hiding • Secret • Abstraction • Module Hierarchy, Module Guide • Uses, Uses Relation

46. Exercise 7: Modifying a uses relation 1. Review the FWS uses relation 2. Put the new module(s) that you defined in exercise 6 into the FWS uses relation.

47. Teams