Software Product-Line Engineering: A Family-Based Software Development Process: Designing The Family: Part 1 David Weiss
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 COMS 309 Weiss Spring 2010 Design The Family2
Product Engineering Environment A FAST Process Domain Engineering Product Engineering Products Feedback Investment Payback COMS 309 Weiss Spring 2010 Design The Family3
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) COMS 309 Weiss Spring 2010 Design The Family4
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 COMS 309 Weiss Spring 2010 Design The Family5
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) COMS 309 Weiss Spring 2010 Design The Family6
Interlude Architecture 7COMS 309 Weiss Spring 2010 Design The Family
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 8COMS 309 Weiss Spring 2010 Design The Family
Hagia Sophia, Istanbul COMS 309 Weiss Spring 2010 Design The Family9
Built COMS 309 Weiss Spring 2010 Design The Family10
Designers: Anthemius of Tralles and Isidorus of Miletus (Mathematicians, Engineers, Architects) COMS 309 Weiss Spring 2010 Design The Family11
Pendentives COMS 309 Weiss Spring 2010 Design The Family12
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. COMS 309 Weiss Spring 2010 Design The Family13
St. Paul’s Cathedral, London COMS 309 Weiss Spring 2010 Design The Family14
Architect: Sir Christopher Wren COMS 309 Weiss Spring 2010 Design The Family15
Built COMS 309 Weiss Spring 2010 Design The Family16
View From The Dome (1) COMS 309 Weiss Spring 2010 Design The Family17
View From The Dome (2) Millenium Bridge COMS 309 Weiss Spring 2010 Design The Family18
How Did They Know It Would Stay Up? COMS 309 Weiss Spring 2010 Design The Family19
Buckling Load B ~ ET/R T= Thickness R= Radius E = Elastic Modulus Assumptions 1.Spherical 2.Isotropic - identical properties at each point T R How Did They Know It Would Stay Up? Prototypes Theoretical Models COMS 309 Weiss Spring 2010 Design The Family20
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, …) COMS 309 Weiss Spring 2010 Design The Family21
What is Software Architecture? Literally Hundreds of definitions 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 … COMS 309 Weiss Spring 2010 Design The Family22
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 COMS 309 Weiss Spring 2010 Design The Family23
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)} COMS 309 Weiss Spring 2010 Design The Family24
a b c d e f g COMS 309 Weiss Spring 2010 Design The Family25
Structures and Models Every structure (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? COMS 309 Weiss Spring 2010 Design The Family26
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 COMS 309 Weiss Spring 2010 Design The Family27
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 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? COMS 309 Weiss Spring 2010 Design The Family28
Key Architectural Structures Module Structure –Explains the principles used to design the information hiding structure of the architecture, and shows how responsibilities are allocated among the major modules. Uses Structure –Describes the allowed “uses” relationships between modules and limits what other modules the implementer of a module may use. Process Structure –Defines the distinct processes in the system; Specifies the module(s) that make up the process, synchronization between processes … 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 COMS 309 Weiss Spring 2010 Design The Family29
Modules COMS 309 Weiss Spring 2010 Design The Family
“... program structure should be such as to anticipate its adaptations and modifications. Our program should not only reflect (by structure) our understanding of it, but it should also be clear from its structure what sort of adaptations can be catered for smoothly. Thank goodness the two requirements go hand in hand.” Edsger W. Dijkstra On Program Families COMS 309 Weiss Spring 2010 Design The Family
“... program structure should be such as to anticipate its adaptations and modifications. Our program should not only reflect (by structure) our understanding of it, but it should also be clear from its structure what sort of adaptations can be catered for smoothly. Thank goodness the two requirements go hand in hand.” Edsger W. Dijkstra On Program Families If you can modify it, you understand it. COMS 309 Weiss Spring 2010 Design The Family
Modules Module: Work assignment for a developer or small team of developers Concept explored and extended by David Parnas and others starting around 1970 Goals of modularization –Manage complexity by separating concerns –Make the system easier to: Understand Integrate and build Maintain (change) Test Verify Develop by a team –Free modules from product specific dependencies COMS 309 Weiss Spring 2010 Design The Family33
Modularization Criteria Possible ways to organize a system into modules –Functional: each module is a function –Steps in processing: each module is one step in a chain of processing –Information hiding: each module hides a design decision Information hiding principle –Independently-changeable information, such as design decisions, should be hidden in independently-changeable modules –Changes to module implementations are hidden behind well- defined interfaces that are stable over time –Secret: decision that’s hidden in a module COMS 309 Weiss Spring 2010 Design The Family34
Typical secrets SecretTypical Change How to monitor a sensorNew more reliable sensor, higher resolution sensor How to control a deviceFaster, “larger”, version of device Platform characteristicsFaster processor, multi- processor, larger memory How to control a displayReorganization of screen real- estate, look and feel How to exchange dataProtocol change Database physical structureFields added, faster access needed, field sizes change AlgorithmDifferent time-space trade-off needed, more accurate algorithm invented Representation of system entities such as jobs and users Change in performance requirements More system entities COMS 309 Weiss Spring 2010 Design The Family35
Describing Modules What’s the secret? –Example: Conditions under which outputs are produced Module: Behavior Hiding Module –Example: How to use services provided by other modules to obtain averaged wind speed data and transmit it at a fixed period. Module: Message Generation Module What service(s) are provided by the module? –Example: Periodically retrieve data from the Data Banker and transmit it. Module: Message Generation Module COMS 309 Weiss Spring 2010 Design The Family36
Organizing Secrets Hierarchically Environment characteristics –External device characteristics (How to monitor sensors) –External system characteristics (Protocol needed to communicate externally) –Platform characteristics Platform specific services Resource allocation algorithms –Thread Management –Processor scheduling –Memory allocation Required behavior –Conditions under which outputs are produced (How often to send a message) Software design decisions –How to store data –Computational algorithms (Averaging?) COMS 309 Weiss Spring 2010 Design The Family37
The Module Hierarchy A is a submodule of B means that A’s secret is a subsecret of B’s secret Example –Device Interface: How to monitor and control devices –Sensor Device Driver (How to monitor sensor) –Transmitter Device Driver (How to control transmitter) COMS 309 Weiss Spring 2010 Design The Family38
The Module Hierarchy: Questions That The Structure Answers How do I assign work to developers? –Testers? What changes will be easy to accommodate? –Hard to accommodate? What are the abstractions used in the system? –How can I understand the system? COMS 309 Weiss Spring 2010 Design The Family39
COMS 309 Weiss Spring 2010 Design The Family40 Sensor Device FWS Behavior HidingDevice InterfaceSoftware Design Hiding Transmitter Device Message Generation Message Format Averager Data Banker Sensor Monitor FWS Module Hierarchy Graphical View
COMS 309 Weiss Spring 2010 Design The Family41
The Module Guide Textual description of the module hierarchy Each module described by its secret COMS 309 Weiss Spring 2010 Design The Family42
Excerpts From The FWS Module Guide (1) 1.Behavior Hiding Modules The behavior hiding modules include programs that need to be changed if the required outputs from a FWS and the conditions under which they are produced are changed. Its secret is when (under what conditions) to produce which outputs. Programs in the behavior hiding module use programs in the Device Interface module to produce outputs and to read inputs. 1.1 Controller Service Provide the main program that initializes a FWS. Secret How to use services provided by other modules to start and maintain the proper operation of a FWS. Associated variabilities and parameters of variation None COMS 309 Weiss Spring 2010 Design The Family43
Excerpts From The FWS Module Guide (2) 2.Device Interface Modules The device interface modules consist of those programs that need to be changed if the input from hardware devices to FWSs or the output to hardware devices from FWSs change. The secret of the device interface modules is the interfaces between FWSs and the devices that produce its inputs and that use its output. 2.1.Sensor Device Driver Service Provide access to the wind speed sensors. There may be a submodule for each sensor type. Secret How to communicate with, e.g., read values from, the sensor hardware. Associated variabilities and parameters of variation V7., the wind speed sensor hardware. Note This module hides the boundary between the FWS domain and the sensors domain. The boundary is formed by an abstract interface that is a standard for all wind speed sensors. Programs in this module use the abstract interface to read the values from the sensors. COMS 309 Weiss Spring 2010 Design The Family44
Abstraction Abstraction: many-to-one mapping –Not “vague” –Not mathematical –Not high-level Model common aspects, but not all aspects –Device abstraction: abstract away from details of control sequences –Data abstraction: abstract away from data representation –… One model, implementable many ways –Commonality and variability Levels of abstraction?? COMS 309 Weiss Spring 2010 Design The Family45
Different views of information hiding modules A set of programs and shared data Work Assignment: Design and implement the programs and the data structures that those programs share Public Interface: The subset of the module’s programs that are visible, forming an abstract interface for the module’s users. The programs may include data types, signals, exceptions, and other devices that the implementers employ to reflect the assumptions that the module’s users are allowed to make about the module. Secret: How the programs are implemented, what the internal representation of the data is, and what internal programs are needed as part of the implementation. An abstract interface and its implementation Work assignment: Design and implement the interface. The interface is abstract in that there are many possible implementations of it. Public Interface: A set of programs that provide the services offered by the module to its users. The programs may include data types, signals, exceptions, and other devices that the implementers employ to reflect the assumptions that the module’s users are allowed to make about the module. Secret: What programs and data structures are hidden behind the interface and how they are implemented. COMS 309 Weiss Spring 2010 Design The Family46
Different views of information hiding modules A state machine Work assignment: Implement the state transition function of the state machine. Public Interface: Typically, a set of programs that provide ways to read the state of the module and to cause the module to transition from one state to another. Secret: How the state transition function is implemented, i.e., what programs and data structures are used to implement it. A class Work assignment: Design and implement the public and private methods and the data structures needed to implement the module. Public Interface: The public methods and data of the class. Secret: How the methods are implemented, what the private methods are, and what data structures are used by the methods but do not appear in the interface. COMS 309 Weiss Spring 2010 Design The Family47
Different views of information hiding modules An abstract data type Work assignment: Design and implement the data structure used to hold the data for variables of the type, and the operations that may be performed on the data. Public Interface: The operations that may be performed on the data type, including functions that read and change the value of the data. Secret: What the representation of the data structure is and how the operations are implemented. An abstraction Work assignment: Design and implement instances of the many-to-one mapping that constitutes the abstraction. Public Interface: The range of the many-to-one mapping, i.e., those programs and data that embody the services offered by the abstraction to its users. One may think of these as the common parts of the abstraction. Secret: How the details of the mapping are implemented so that the common parts of the abstraction remain fixed for different instances. COMS 309 Weiss Spring 2010 Design The Family48
Different views of information hiding modules A collection of macros and preprocessor directives Work assignment: Design and implement the macros and directives. Public Interface: The set of macros and directives that the developers of other modules may use. Secret: How the macros are implemented. Note design time binding. A black box Work assignment: Design and implement the external appearance and the internal implementation. Public Interface: The buttons and dials that the users can use. Secret: How the box is built. COMS 309 Weiss Spring 2010 Design The Family49
Information hiding modules as abstractions Module defines an abstraction (many-to-one mapping) –Common part is what’s revealed to module’s users (the one) –Secret is how the module is implemented (the many) Services (capabilities) that the module provides allows module users to take advantage of the abstraction –Abstract data types: Users operate on the data without knowing its representation –GUI creation environments (VB): Users construct GUIs without knowing details of how to display –Protocols: Users send and receive data without knowing details of channel operation –Methods: Users invoke methods without knowing module’s algorithms COMS 309 Weiss Spring 2010 Design The Family50
Information Hiding Modules And Product Lines We want to be able to change the value of each variability independently Create a module for each variability –Secret of the module is how the variability is implemented There may be additional modules for other design decisions Example: Message Format Module –Secret: How to create a message in the correct format for transmission –Variability: MsgType (V2, P4) COMS 309 Weiss Spring 2010 Design The Family51
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 Guidance for constructing the modular structure Define interface specifications for each module Define a uses relation among programs that appear on module interfaces Define the process structure COMS 309 Weiss Spring 2010 Design The Family52
Summary Information hiding modules are work assignments that hide design decisions We organize information hiding modules into a module hierarchy, described in the module guide for the family In a product line, for each variability there is a module whose secret is how the variability is implemented Architecture is a set of structures, such as module structure, uses structure, process structure, plus interface specifications COMS 309 Weiss Spring 2010 Design The Family53
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 Secret Abstraction Module Hierarchy, Module Guide Uses Process COMS 309 Weiss Spring 2010 Design The Family54
Exercise 4: Modifying a Modular Structure: Part 1a Review the FWS Module Guide, answering the following questions. 1. For each module, is the module in an appropriate place in the hierarchy? If not, identify the misplaced module(s) and where they should be located. 1. Are there modules that are missing from the Module Guide? If so, what are they, what are their secrets, and where should they be placed in the hierarchy? COMS 309 Weiss Spring 2010 Design The Family55
Exercise 4: Modifying a Modular Structure: Part 1b Review the FWS Module Guide, answering the following questions. 3. For each variability, which module has the implementation of the variability as its secret? 4. Pick one module and describe the abstraction that it represents. Try to do this in one sentence. COMS 309 Weiss Spring 2010 Design The Family56
Exercise 4: Modifying a Modular Structure: Part 2 1.Propose a new module for the FWS that will be needed to implement a new variability for the FWS that you propose. State an appropriate secret for this module. Variability: Module (name and secret): COMS 309 Weiss Spring 2010 Design The Family57
2.Add your new module to the FWS Module Hierarchy Graphical View COMS 309 Weiss Spring 2010 Design The Family58 Sensor Device FWS Behavior HidingDevice InterfaceSoftware Design Hiding Transmitter Device Message Generation Message Format Averager Data Banker Sensor Monitor
3.Add your new module to the FWS Module Guide COMS 309 Weiss Spring 2010 Design The Family59 Section: Module Name: Service Secret Associated variabilities and parameters of variation: