Software Product-Line Engineering: A
Family-Based Software Development
Process:Designing The Family
David [email protected]
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
Session 4 24 May 2009 DMW 2
Product Engineering Environment
A FAST Process
Domain Engineering
Product Engineering
Products
Feedback
Investment
Payback
Session 4 24 May 2009 DMW 3
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)
Session 4 24 May 2009 DMW 4
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
Session 4 24 May 2009 DMW 5
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)
Session 4 24 May 2009 DMW 6
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
Session 4 24 May 2009 DMW 7
Session 4 24 May 2009 DMW 8
FWS
Behavior HidingDevice Interface Software Design Hiding
SensorDevice
TransmitterDevice
MessageGeneration
MessageFormat
Averager DataBanker
SensorMonitor
FWS Module Structure
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
Session 4 24 May 2009 DMW 9
FWS Uses Relation On Modules
Session 4 24 May 2009 DMW 10
Controller
MessageGeneration
SensorMonitor
Averager
DataBanker
Sensor DeviceDriver
Transmitter DeviceDriver
MessageFormat
Importance of Uses (1)
• Uses determines the order in which modules should be implemented– Data Banker & Sensor Device Driver Before Sensor
Monitor & Averager
Session 4 24 May 2009 DMW 11
Controller
MessageGeneration
SensorMonitor
Averager
DataBanker
Sensor DeviceDriver
Transmitter DeviceDriver
MessageFormat
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
Session 4 24 May 2009 DMW 12
Controller
MessageGeneration
SensorMonitor
Averager
DataBanker
Sensor DeviceDriver
Transmitter DeviceDriver
MessageFormat
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
Session 4 24 May 2009 DMW 13
Laser DeviceDriver
Controller
MessageGeneration
SensorMonitor
Averager
DataBanker
Wind Speed SensorDevice Driver
Transmitter DeviceDriver
MessageFormat Water Temperature Sensor
Device Driver
Session 4 24 May 2009 DMW 14
FWS
Behavior HidingDevice Interface Software Design Hiding
SensorDevice
TransmitterDevice
MessageGeneration
MessageFormat
Averager DataBanker
SensorMonitor
FWS Module Structure
Wind Speed SensorDevice Driver
Water Temperature SensorDevice Driver
Laser DeviceDriver
RadioDriver
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
Session 4 24 May 2009 DMW 15
Controller
MessageGeneration
SensorMonitor
Averager
DataBanker
Sensor DeviceDriver
Transmitter DeviceDriver
MessageFormat
From Parameters Of Variation To Implementations: The
Decision Model
Session 4 24 May 2009 DMW 16
System Composition Mapping
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
Session 4 24 May 2009 DMW 18
Designers: Anthemius of Tralles and Isidorus of Miletus (Mathematicians,
Engineers, Architects)
Session 4 24 May 2009 DMW 21
Hagia Sophia Interior. Four arches swing across the piers,linked by four pendentives. The apices of the arches and the pendentivessupport the circular base of the huge central dome.http://www.patriarchate.org/ecumenical_patriarchate/chapter_4/html/hagia_sophia__page_2.html
Session 4 24 May 2009 DMW 23
Buckling LoadB ~ ET/R
T= ThicknessR= RadiusE = Elastic Modulus
Assumptions1. Spherical2. Isotropic
- identical properties at each point
T
R
How Did They Know It Would Stay Up?• Prototypes• Theoretical Models
Session 4 24 May 2009 DMW 30
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, …)
Session 4 24 May 2009 DMW 31
What is Software Architecture?
• Literally Hundreds of definitionshttp://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 …
Session 4 24 May 2009 DMW 32
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
Session 4 24 May 2009 DMW 33
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)}
Session 4 24 May 2009 DMW 34
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
Session 4 24 May 2009 DMW 36
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?
Session 4 24 May 2009 DMW 37
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 …
Session 4 24 May 2009 DMW 38
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.
Session 4 24 May 2009 DMW 39
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
Session 4 24 May 2009 DMW 40
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?
Session 4 24 May 2009 DMW 41
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
Session 4 24 May 2009 DMW 42
Session 4 24 May 2009 DMW 43
Controller
MessageGeneration
SensorMonitor
Averager
DataBanker
Sensor DeviceDriver
Transmitter DeviceDriver
MessageFormat
FWS
Behavior HidingDevice Interface Software Design Hiding
TransmitterDevice
MessageGeneration
MessageFormat
Averager DataBanker
SensorMonitor
SensorDevice
FWS Module Structure
FWS Uses Structure
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
Session 4 24 May 2009 DMW 44
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
Session 4 24 May 2009 DMW 45
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.
Session 4 24 May 2009 DMW 46
TeamsRole Responsibility Person
Systems Engineer Commonality/variability analysis, decision model
Architect Module, uses, process structures, interface specifications
Developer Module implementation
Tester & Integrator
Module tests, System generation and verification
Project Manager Economic model, project planSession 4 24 May 2009 DMW 47
Top Related