Software Product-Line
Engineering: A FamilyBased Software
Development Process:
Producing Members Of The
Family
David Weiss
[email protected]
Topics
• Creating the decision model
• Implementing the modular structure
Session 5 24 May 2009 DMW
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
Session 5 24 May 2009 DMW
3
A FAST Process
Investment
Domain Engineering
Feedback
Product Engineering Environment
Product Engineering
Payback
Session 5 24 May 2009 DMW
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)
Session 5 24 May 2009 DMW
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
Session 5 24 May 2009 DMW
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)
Session 5 24 May 2009 DMW
7
FWS Module Structure
FWS
Device Interface
Sensor
Device
Transmitter
Device
Session 5 24 May 2009 DMW
Behavior Hiding
Message
Message
Generation Format
8
Software Design Hiding
Averager
Data
Sensor
Banker Monitor
FWS Uses Relation On Modules
Controller
Message
Generation
Sensor
Monitor
Averager
Transmitter Device
Driver
Session 5 24 May 2009 DMW
Message
Format
Data
Banker
9
Sensor Device
Driver
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
Session 5 24 May 2009 DMW
Message
Format
10
Data
Banker
Sensor Device
Driver
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
Session 5 24 May 2009 DMW
Message
Format
11
Data
Banker
Sensor Device
Driver
FWS Module Structure
FWS
Device Interface
Sensor
Device
Transmitter
Device
Behavior Hiding
Message Message
Generation Format
Software Design Hiding
Averager Data Sensor
Banker Monitor
FWS Uses Structure
Controller
Message
Generation
Sensor
Monitor
Averager
Transmitter Device Message
Driver
Format
Session 5 24 May 2009 DMW
Data
Banker
12
Sensor Device
Driver
FWS Variabilities
The following statements describe how a FWS may vary.
Behavior
V1. The formula used for computing wind speed from the sensor readings may vary. In
particular, the weights used for the high resolution and low resolution sensors may
vary, and the number of readings of each sensor used (the history of the sensor) may
vary.
V2. The types of messages that an FWS sends may vary according to both content and
format. There are currently only two types of messages, described in section 8.,
Appendix I.
V3. The transmission period of messages from the FWS may vary.
Devices
V4. The number of wind speed sensors on a FWS may vary.
V5. The resolution of the wind speed sensors may vary.
V6. The sensor period of the sensors on a FWS may vary.
V7. The wind speed sensor hardware on a FWS may vary.
V8. The transmitter hardware on a FWS may vary.
V9. The method used by sensors to indicate their reliability may vary.
Session 5 24 May 2009 DMW
13
Parameters of Variation For Behavior (Table A-1, p. 117)
Parameter
(Variabilities)
Meaning
Value Set
Binding
Time
Default
P1: HighResWeight, V1.
Weight applied to high
resolution sensor readings
[1..100]
Specification
50
P2: LowResWeight, V1.
Weight applied to low
resolution sensor readings
[1..100]
Specification
50
P3: History, V1.
Number of sensor readings
used per sensor in
calculating the weighted
average.
[1..10]
Specification
5
P4: MsgType, V2.
Type of message that will
be transmitted
{SHORTMSG,LO
NGMSG}
Specification
SHORTMSG
Session 5 24 May 2009 DMW
14
Parameters of Variation For Devices (Table A-1, p. 117)
Parameter
(Variabilities)
Meaning
Value Set
Binding
Time
Default
P5: MaxSensorPeriod,
V6.
Maximum Sensor Period
[1 .. 600]
Translator
Construction
600
P6: MaxSensors, V4.
Maximum number of
sensors on board a FWS
[2 ..20]
Translator
Construction
20
P7: MaxTransmitPeriod,
V3
Maximum Transmission
Period
[1 .. 600]
Translator
Construction
600
P8: MinLow, V4., V5.
Minimum number of low
resolution sensors
[2 ..
MaxSensors-2]
Translator
Construction
2
P9: MinHigh, V4., V5.
Minimum number of high
resolution sensors
[2 ..
MaxSensors-2]
Translator
Construction
2
P10: SensorCount, V4.
Number of wind speed
sensors
(LOW, HIGH)1,
Specification
1
P11: SensorPeriod, V6.
Sensor period
[1..MaxSensorP
eriod] sec.
Specification
5
P12: SensorRes, V5.
The resolution of each
sensor
For each sensor,
one of
{LOWRES,
HIGHRES}
Specification
LOWRES
P13: TransmitPeriod, V3.
Transmit period
[1..MaxTransmit
Period] sec.
Specification
10
1. LOW and HIGH are integers representing the number of low resolution and high resolution sensors
respectively, such that Minlow ≤ LOW ≤ L. Minhigh ≤ HIGH ≤ H, L+H ≤ MaxSensors
Session 5 24 May 2009 DMW
15
Ordering of Decisions (Table 5-4 p. 76)
Decision
Order (Phase)
Maximum number of sensors on board FWS (P6)
1
Maximum Sensor Period (P5)
1
Maximum Transmission Period (P7)
1
Minimum number of low resolution sensors (P8)
1
Minimum number of high resolution sensors (P9)
1
Type of message that will be transmitted (P4)
2
Weight applied to high resolution sensor readings (P1)
2
Weight applied to low resolution sensor reading (P2)
2
Length of the history of the sensor readings that will be used to
calculate the weighted average of sensor readings
(P3)
2
Number of wind speed sensors (P10)
2
Resolution of each sensor (P12)
2
Sensor period (P11)
2
Transmission period (P13)
2
Session 5 24 May 2009 DMW
16
User Selectable Parameters of Variation (Table 5-5 p. 83)
Decision
Parameter of Variation
Weight applied to high resolution
sensor readings
HighResWeight (P1)
Weight applied to low resolution
sensor reading
LowResWeight (P2)
Length of sensor-readings history
History (P3)
Type of message that will be
transmitted
MsgType (P4)
Number of wind speed sensors
SensorCount (P10)
Sensor period
SensorPeriod (P11)
Resolution of each sensor
SensorRes (P12)
Transmission period
TransmitPeriod (P13)
Session 5 24 May 2009 DMW
17
System Composition Mapping (Table 5-6 p. 92)
Decision (Parameter of Variation)
Module(s)
Number of low resolution sensors (P10)
Sensor Monitor, Data Banker, Sensor
Device Driver
Weight applied to low resolution sensors (P2)
Averager, Data Banker
Number of high resolution sensors (P10)
Sensor Monitor, Data Banker, Sensor
Device Driver
Weight applied to high resolution sensors (P1)
Averager, Data Banker
Length of sensor-readings history (P3)
Message Generation, Averager, Data
Banker, Sensor Device Driver
Sensor period (P11)
Sensor Monitor, Sensor Device Driver
Transmission period (P13)
Message Generation, Transmitter
Device Driver, Message Format,
Averager, Data Banker
Type of message (P4)
Message Format
Session 5 24 May 2009 DMW
18
Decision Model (1)
Parameter
Meaning
Value Set,
Default
Constraints
Binding
Time
Modules
P5:
MaxSensorPeriod
Maximum
Sensor Period
[1 .. 600]
D: 600
Translator
Const.
Sensor
Monitor
P6: MaxSensors
Maximum
number of
sensors on
board a FWS
[2 ..20]
D: 20
Translator
Const.
Averager,
Data
Banker
P7:
MaxTransmitPeriod
Maximum
Transmission
Period
[1 .. 600]
D: 600
Translator
Const.
Message
Generation
P8: MinLow
Minimum
number of low
resolution
sensors
[2 .. MaxSensors-2]
D: 2
Translator
Const.
Sensor
Monitor,
Data
Banker
P9: MinHigh
Minimum
number of
high
resolution
sensors
[2 .. MaxSensors-2]
D: 2
Translator
Const.
Sensor
Monitor,
Data
Banker
Session 5 24 May 2009 DMW
19
Decision Model (2)
Parameter
Meaning
Value Set
P1:
HighResWeight
Weight
applied to
high
resolution
sensor
readings
P2:
LowResWeight
Binding
Time
Modules
[1..100]
D: 50
Spec
Averager,
Data
Banker
Weight
applied to
low
resolution
sensor
readings
[1..100]
D: 50
Spec
Averager,
Data
Banker
P3: History
Number of
sensor
readings
used per
sensor in
calculating
the
weighted
average.
[1..10]
D: 5
Spec
Message
Generation,
Averager,
Data
Banker,
Sensor
Device
Driver
P4: MsgType
Type of
message
that will be
transmitted
{SHORTMSG,LONGMSG
}
D: SHORTMSG
Spec
Message
Format
Session 5 24 May 2009 DMW
Constraints
20
Decision Model (3)
Parameter
Meaning
Value Set
P10:
SensorCount
Number of
wind
speed
sensors
(LOW, HIGH)
P11:
SensorPeriod
Sensor
period
P12:
SensorRes
P13:
TransmitPeriod
Binding
Time
Modules
Spec
Sensor
Monitor, Data
Banker, Sensor
Device Driver
[1..MaxSensorPeriod] sec.
D: 5
Spec
Sensor
Monitor,
Sensor Device
Driver
Resolution
of each
sensor
For each sensor, one of
{LOWRES, HIGHRES}
D: LOWRES
Spec
Transmit
period
[1..MaxTransmitPeriod]
sec.
D: 10
Spec
Session 5 24 May 2009 DMW
Constraints
LOW and HIGH
are integers
representing
the no. of low
resolution and
high resolution
sensors
respectively,
such that
Minlow ≤ LOW ≤
L. Minhigh ≤
HIGH ≤ H, L+H
≤ MaxSensors
21
Message
Generation,
Transmitter
Device Driver,
Message
Format,
Averager, Data
Banker
From Parameters Of Variation To
Implementations: The Decision Model
System Composition Mapping
Session 5 24 May 2009 DMW
22
Summary
• The system composition mapping takes advantage of
the uses relation to determine which modules are
needed for each decision.
• The decision model uses the system composition
mapping to compose a family member from the
decisions made by the application engineer.
• The application engineer only needs to know the
decisions that have to be made, and need not see
the system composition mapping
Session 5 24 May 2009 DMW
23
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, Uses Relation
Session 5 24 May 2009 DMW
24
Exercise 8: Modifying the decision
model
1. Review the FWS decision model
2. Add the variability you created in Exercise 4 to the
decision model, modifying the the parameters of
variation and module and uses structures as necessary
Session 5 24 May 2009 DMW
25
Teams
Role
Responsibility
Systems Engineer
Commonality/variabili
ty analysis, decision
model
Architect
Module, uses,
process structures,
interface specifications
Developer
Module implementation
Module tests, System
generation and
verification
Economic model,
project plan
Tester & Integrator
Project Manager
Session 5 24 May 2009 DMW
26
Person
Topics
• Creating the decision model
• Implementing the modular structure
Session 5 24 May 2009 DMW
27
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 5 24 May 2009 DMW
28
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 5 24 May 2009 DMW
29
FWS Module Structure
FWS
Device Interface
Sensor
Device
Transmitter
Device
Session 5 24 May 2009 DMW
Behavior Hiding
Message
Message
Generation Format
30
Software Design Hiding
Averager
Data
Sensor
Banker Monitor
Abstract Interfaces: Key To Modular
Architecture
Session 5 24 May 2009 DMW
31
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
– Free modules from product specific dependencies
Session 5 24 May 2009 DMW
32
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 welldefined interfaces that are stable over time
– Secret: decision that’s hidden in a module
Session 5 24 May 2009 DMW
33
Typical secrets
Secret
Typical Change
How to control a device
Faster, “larger”, version of
device
Platform characteristics
Faster processor, multiprocessor, larger memory
How to control a display
Reorganization of screen realestate, look and feel
How to exchange data
Protocol change
Database physical structure
Fields added, faster access
needed, field sizes change
Algorithm
Different 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
Session 5 24 May 2009 DMW
34
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
Session 5 24 May 2009 DMW
35
Example Module Structure
Platform
External Interface
Platform Services
Data Source Interface
System Integration
External Platform Abstraction
Basic Transport
Session 5 24 May 2009 DMW
Communication Services
Communications Channel
Client Channel Control
Media Processing
Interactive Response Services
Shared Services
System Installation Module
System Administration
System Administration UI
Distributed System Module
License Service
Logging Service
Alarming
Internationalization Support
Product Naming and Branding
Scheduled Task
Security Services
User Interface Framework
Application Design Environment
Monitoring and Reporting
System Data Model
Data Management
Knowledgebase Management
Workflow Services
System State
Resource Presence and Availability
Work Item Services
Event Management
Resource Assignment Service
Communications Workflow
36
Behavior
Campaign Management
Behavior Services
Integration
Data Integration
Production Line Module
Context Management
Customization Management
Conventional CM
Build Management
Package Management
Modification Request Tracking
Product Dependency
Product Component Dependency
Product Deployment Policy
License Policy Module
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
Session 5 24 May 2009 DMW
37
What’s an abstract interface?
•
•
Set of assumptions that the developers of one module can make about another (not just
the signature)
– What access methods can I invoke?
• What are their parameters?
• What exceptions can occur?
– What is the effect of calling a method?
• What are legal sequences of invocations of access methods?
– Push(a)
– Push(a).pop
– Push(a).top
• What is the effect on one access method of calling another?
– Push(a).top returns a
– Set(x).get returns x
– What are the externally-visible states of the module?
Definition of interface used within context of writing interface specifications is broader
than definition used by languages such as Java
Session 5 24 May 2009 DMW
38
What’s an abstract interface?
• One interface that represents many possible actual
interfaces (many-to-one mapping)
– Abstract device interface: one interface that works for many
different implementations of the device (device driver)
• May have to re-implement the device driver for different
versions of the device, but the software that uses the
device driver doesn’t change
– Interface may abstract away from language or platform
• C, C++, Java, C#
– Provide mapping to different languages
– Will have a manifestation in a particular language
– Interface abstracts away from secret of the module
Session 5 24 May 2009 DMW
39
Interfaces and Assumptions
• Specifying the interface makes assumptions explicit
– Signatures leave important assumptions implicit
• Does top remove the top element of the stack or just
read it?
• Explicit assumptions
–
–
–
–
–
make the user’s job easier
make the reviewer’s job easier
make the implementer’s job easier
make the tester’s job easier
make it easier to predict what will be easy to change and
what will be hard to change
Session 5 24 May 2009 DMW
40
Some Small Examples
Session 5 24 May 2009 DMW
41
Session 5 24 May 2009 DMW
42
Session 5 24 May 2009 DMW
43
Points To Note
• G/S is short for two access methods:
– Get_AUDIBLE_SIGNAL
– Set_AUDIBLE_SIGNAL
• Get_AUDIBLE_SIGNAL has no effect (doesn’t
change the state)
– The value it returns is defined by the type of its output
parameter and the term !Aud signal!
• Ind_ctrl is a local data type that is used to define the
value space for a parameter; it is not an internal
variable. Compare to integer, which is used for
BEEP_RATE
• Performance has not been specified
Session 5 24 May 2009 DMW
44
Session 5 24 May 2009 DMW
45
Session 5 24 May 2009 DMW
46
Points To Note
• The module signals two events, one is the event that
the condition !RA valid! has become true, the other is
the event that !RA valid! has become false.
– The interface does not describe the mechanism used to
publish and subscribe to events
Session 5 24 May 2009 DMW
47
Goals for Creating Module Interface Specifications
• Clearly documents the behavior of the module
– reduces time & knowledge required to adopt module
• Clearly documents the interfaces used by the module
– Aids in creating stubs, mock interfaces and integration test scripts
• Improves the ability to isolate errors quickly
• Supports backwards compatibility.
• Defines implementers work assignment
– Interface specification is essentially a contract for the developer that
specifies the implementer’s task and the assumptions that users can make
• Enables straight-forward mapping between use case requirements and
methods
– reduces effort required for requirements traceability
Session 5 24 May 2009 DMW
48
Module Interface Specifications
•
•
•
Are not:
– Completed at end of development as “after-thought”
– Typical API which focuses on describing signature of interface
– Lengthy, 100+ page document
– Replacement for design documents
What they are:
– Critical step in design interval
– Description of minimal set of methods
• Do not include extra methods unless clearly understand how additional
functionality would be used
– Description of how to verify behavior of module in addition to how to use
module
– Easy to read, maintain
– Means for supporting module extensibility
Can be documented using Javadoc or other means.
– Interface specifications should be completed before implementation
Session 5 24 May 2009 DMW
49
A method for constructing abstract interfaces
• Define services provided and services needed (assumptions)
• Decide on syntax and semantics for accessing services
• In parallel
•
•
•
•
•
Define access method effects
Define terms and local data types
Define states of the module
Record design decisions
Record implementation notes
• Define test cases and use them to verify access methods
• Cover testing effects, parameters, exceptions
– Test both positive and error use cases
• Cover broader set of tests than typical unit tests
• Support automation
• Design test cases before implementing module
– Who is responsible for designing test cases?
Session 5 24 May 2009 DMW
50
Benefits
• Enables development of complex projects:
– Support partitioning system into separable modules
– Complements incremental development approaches
• Improves quality of software deliverables:
– Clearly defines what will be implemented
– Errors are found earlier
– Error Detection is easier
– Improves testability
• Defines clear acceptance criteria
• Defines expected behavior of module
• Clarifies what will be easy to change, what will be hard to change
• Clearly identifies work assignments
Session 5 24 May 2009 DMW
51
“Everything should be as simple as
possible, but no simpler.”
-- Albert Einstein
Session 2 20 May 2009 DMW
52
An FWS Example: The Data Banker
Interface Specification
Define services provided and services needed
Service
Provided Tested By
By
1. Initialize the set of stored sensor
readings.
2. Store a new sensor reading,
maintaining only the necessary
history, and retrieve the current
sensor reading history, keeping
reads and writes synchronized.
Session 5 24 May 2009 DMW
53
An FWS Example: The Data Banker Interface Specification
Decide on syntax and semantics for accessing services
Access Methods
Exceptions: None
Access
Parameter
Methods
name
Parameter
type
Parameter
Info
Performance
Best - Worst
–Mapping to
Services
Provided
1
Performance
Best - Worst
–Mapping to
Services
Provided
2
init
Exceptions: Uninitialized
Access
Parameter
Methods
name
Parameter
type
write
SensorReading
s: I
Parameter
Info
Exceptions: Uninitialized, Empty
Access
Methods
Parameter
name
Parameter
type
Parameter Info
read
r; O
Vector
Vector of
elements of type
SensorReading
Session 5 24 May 2009 DMW
54
Performance
Best - Worst
–Mapping to
Services
Provided
2
An FWS Example: The Data Banker Interface Specification
Decide on syntax and semantics for accessing services
(cont.)
Local Data Types
Type
SensorReading
SensorResolution
Value Space
A pair (r, v) where r is of type
SensorResolution and v is of
type SensorValue, representing
a sensor reading.
{HighRes, LowRes}
SensorValue
Integer i, where i ≥ 1
Session 5 24 May 2009 DMW
55
An FWS Example: The Data Banker Interface Specification
Decide on syntax and semantics for accessing services
(cont.)
Access Method Effects
Legal Traces: init, init.write, init.write.read
Equivalent Traces
Trace
Equivalent
write.read.read
write.read
Trace
Value
T.writei(si).read(v), i=1..n
v=(sk, …, sn ), where
(n-k) = min(n, HistoryLength)
Values
Session 5 24 May 2009 DMW
56
An FWS Example: The Data Banker
Interface Specification
Define test cases and use them to verify access method
Example
TC 1: Initialize
Step
Description
1
Initialize
data banker
Read from
the data
banker
2
Session 5 24 May 2009 DMW
Input
Type/Value
None
Expected
Results
Read from
the
DataBanker
returns an
exception.
57
Service
Preamble
1
None
2
An FWS Example: The Data Banker
Interface Specification
Complete services provided and services needed
Service
Provided Tested By
By
1. Initialize the set of stored sensor init
TC1, TC2, TC3, TC4, TC5
readings.
2. Store a new sensor reading,
read,
TC1, TC2, TC3, TC4, TC5
maintaining only the necessary
write
history, and retrieve the current
sensor reading history, keeping
reads and writes synchronized.
Session 5 24 May 2009 DMW
58
An FWS Example: The Data Banker
Interface Specification
Record design decisions
Interface Design Issues
1, Should we let the user read an empty vector of sensor readings after
initialization, or just throw an exception?
A1. Yes. An empty vector should be treated just as any other.
A2. No. There are no valid values in an empty vector that can be
averaged, so we should let he user know that the vector is empty by
throwing the exception.
Resolution: No. An empty vector is an exceptional case and the user
should be informed that he/she has tried to access the data banker
before any values have been read using the standard exception
mechanisms.
Session 5 24 May 2009 DMW
59
Summary
•
•
•
•
•
•
Each variability is used to identify the secret of a module, one module
per variability
Every module has an abstract interface that provides a way for other
modules to use its secret without knowing how the secret is
implemented
An interface is the set of assumptions that the users of a module can
make about the module
The interface specification for a module is a contract between the users
of the module and the implementers of a module
An abstract interface specification specifies both syntax and semantics
for the interface
There is a systematic process for developing interface specifications
Session 4 24 May 2009 DMW
60
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
Abstract Interface
Contract
Session 4 24 May 2009DMW
61
Exercise 9: Reviewing an interface
specification
1. Review the Data Banker Interface Specification,
answering the review questions in section 14 of the
specification.
Session 4 24 May 2009 DMW
62
Exercise 10: Modifying an interface
specification
Suppose that a variability were added to the FWS family
to allow for more than one type of sensor.
1.Propose a statement for such a variability.
2.Propose an associated parameter of variation.
3.Modify the Data Banker interface specification to
provide a service to store more than one type of sensor
data, consistent with the variability and parameter of
variation you proposed in 1 and 2.
Session 4 24 May 2009 DMW
63
Exercise 11: Writing an interface
specification
Write an abstract interface specification for an FWS
module other than the Data Banker or Message Format
Module
Session 5 31 May 2009 DMW
64
Teams
Role
Responsibility
Systems Engineer
Commonality/variability
analysis, decision
model
Architect
Module, uses,
process structures,
interface
specifications
Developer
Module
implementation
Module tests, System
generation and
verification
Economic model,
project plan
Tester & Integrator
Project Manager
Session 4 24 May 2009 DMW
65
Person
Descargar

Software Product Len Engineering