David Weiss [email protected]

47
Software Product- Line Engineering: A Family-Based Software Development Process: Designing The Family David Weiss [email protected]

description

Software Product-Line Engineering: A Family-Based Software Development Process: Designing The Family. David Weiss [email protected]. FAST Process. A process for defining families and developing environments for generating family members Find abstractions common to the family - PowerPoint PPT Presentation

Transcript of David Weiss [email protected]

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

Interlude

Architecture

Session 4 24 May 2009 DMW 17

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

Hagia Sophia, Istanbul

Session 4 24 May 2009 DMW 19

Built 532-537

Session 4 24 May 2009 DMW 20

Designers: Anthemius of Tralles and Isidorus of Miletus (Mathematicians,

Engineers, Architects)

Session 4 24 May 2009 DMW 21

Pendentives

Session 4 24 May 2009 DMW 22

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

St. Paul’s Cathedral, London

Session 4 24 May 2009 DMW 24

Architect: Sir Christopher Wren

Session 4 24 May 2009 DMW 25

Built 1675-1708

Session 4 24 May 2009 DMW 26

View From The Dome (1)

Session 4 24 May 2009 DMW 27

View From The Dome (2)

Millenium Bridge

Session 4 24 May 2009 DMW 28

How Did They Know It Would Stay Up?

Session 4 24 May 2009 DMW 29

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

a

bc

d

e

f

g

Session 4 24 May 2009 DMW 35

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