product line engineering lecture – pl infrastructures iii (5) · 2010-12-17 · configuration...
TRANSCRIPT
© Fraunhofer IESE
0
Product Line Engineering Lecture –PL Infrastructures III (5)
Dr. Martin [email protected]
© Fraunhofer IESE
1
Schedule - Lectures
© Fraunhofer IESE
2
Schedule - Exercises
© Fraunhofer IESE
Product Line Scoping
--- RecapProduct Line Infrastructure
Part II: Variability Realisation ---
How to realize variability resolution support?
© Fraunhofer IESE
4
Core Assets
Content:
Product Model, Process Model, Resource
Lifecycle Phase:
Requirements, System Design, Unit Design, Code, Image, Data, Test, Integration, Documentation, Configuration, Patch
Granularity:
Subsystem, Component, Folder, Document, Document Fragment / Element
Genericity:
Generic, Specific
Data Type:
Model, Structured Text (e.g. XML), Text, Binary
© Fraunhofer IESE
5
2 Layers of Variability Management
Requirements Core Assets Architecture/Design Core Assets Realization Core AssetsA WSN must have wireless transmission.Transmitted data has <a /no> timestamp.
A WSN must have detection capabilities.<DetectionMode> is detected.
A WSN contains sensors.The sensor is a <SensorType> sensor.
textual graphical
WSN
W/OTime
PositionSensor
TiltDetect.
DropDetect.
NoiseDetect.
WirelessTransmiss.
WithTime
Detection Sensor
SoundSensor
Legend:
variation pointoptional variantalternative variantsmultiple coexist. var.refers to
Decision VP Resolut.
Time Transm. <a/no> N, yDetect. Type <Det.Mod> Tilt,
Drop,Noise
Sensors SensorType posit.,noise
Decision VP Resolut.
Time Transm. Wireless Tr. N, yDetect. Type Detection- tilt,
sub-feat. drop,noise
Sensors Sensor- Posit.,sub-feat. Noise
Requirements Variability Models
…
UML Structural Model
Arch./Design Var. ModelsDecision VP Resolut.
Time Transm. time_trans. N, yDetect. Type detector tilt,
sub-class drop,noise
…
void main() {init();
#if HAS_X_POS_SENSORinit_x_position();
#endif#if HAS_SOUND_SENSOR
init_sound();#endif
while(true) {if(period_elapsed) {
period_elapsed=false;...
Condit. Compiled C Code
Realization Var. ModelsDecision VP Resolut.
…Sensors HAS_?_SNS. X_POS,
SOUND
High-Level Variability ModelDecision Resolut. Low-level d.
Time Transm. N, y R1.Tim., R2.Tim., A1.Tim., …Detect. Type tilt, R1.Det., R2.Det., A1.Det, …
drop,noise
Sensors posit., R1.Sns., R2.Sns., …, I1.Sns.noise
R1 R2 I1A1
Core Asset Model
Variability Model(e.g. PuLSE Decision Model (DM))
© Fraunhofer IESE
6
Summary: Variability Realisation:What has to happen after the customer has selected his product?
• Markup, List Points, Point Cuts• Markup, List Points, Point CutsIdentify affected locations
• Provide background knowledge• Provide background knowledgeUnderstand context
• Provision of asset fragments, automated selection, generation, provision of realisation knowledge
• Provision of asset fragments, automated selection, generation, provision of realisation knowledge
Provide appropriaterealisation
• Automated integration (inclusion) of parts• Automated integration (inclusion) of partsIntegrate the realisationvariant into the Core Asset
• Separate core and variant (change), support diffand merge
• Separate core and variant (change), support diffand merge
Manage the core asset andthe variants
© Fraunhofer IESE
7
Variation Point
Variation Point :==
identifies a location
at which variation will occur
within core assets.
Goals: 1) to highlight where variant elements occur(which makes variation easy to see and control);
2) to improve traceability of variability(requires that goal 1 has been fulfilled).
© Fraunhofer IESE
8
Variability Mechanism
Variability Mechanism :==
is a particular way
of realizing variation
in core assets.
Goals: 1) to efficiently package common & variant elements;2) to reduce evolution effort.
© Fraunhofer IESE
9
Variability Mechanism Primitives
Selectionselecting predefined variants
e.g. component wiring, if-blocks, if-defs
Generationgenerating predefined variants
e.g. model-driven development
Substitutionreplacing a variation point by a valuee.g. parameterizatione.g. code weaving
selection
generation
substitution
© Fraunhofer IESE
10
General Purpose Approaches
Templating
Decision Modeling
Preprocessing
CPP, M4, sed, scripting languages
Frame-Technology
Model-Editor automation
Configuration Management
© Fraunhofer IESE
11
class Message {public:#ifdef T9_SUPPORTED
void checkWordList() {...}#endif#ifdef ATTACH_SUPPORTED
void addAttachment() {...}#endif};class MessageUI {public:
void edit(Message &msg) {#ifdef T9_SUPPORTED
if(t9Active) msg.checkWordList();#endif
// perform editing#ifdef ATTACH_SUPPORTED
msg.addAttachment();#endif}};
Conditional Compilation: Example
T9 #ifdef T9_SUPPORTEDvoid checkWordList() {...}
#endif
#ifdef T9_SUPPORTEDif(t9Active) tr.checkWordList();
#endif
#ifdef ATTACH_SUPPORTEDvoid enableAttachButton() {...}
#endif
#ifdef ATTACH_SUPPORTEDtr.enableAttachButton();
#endif
Attachment
class Message {public:
void checkWordList() {...}};class MessageUI {public:void edit(Message &msg) {if(t9Active)msg.checkWordList();
}};
Onepossibleproduct
SpecificationT9 supported
#define T9_SUPPORTED#undef ATTACH_SUPPORTED
© Fraunhofer IESE
12
Frame Technology
ADAPT Messaging.frameADAPT Addressbook.frame
Standard.spc
Class Messaging {....VP SendMsgToAddressBookVP_END.....}
Messaging.frame
Class AddrBook {....VP SendMsgToAddressBookVP_END.....}
Addressbook.frame
Base Product
© Fraunhofer IESE
Product Line Scoping
--- Product Line Infrastructure Part III: Configuration Management ---
How to realize variability resolution support?
How to manage variants?
© Fraunhofer IESE
14
Situation in modern software development
Software Complexity
ProcessComplexity
SoftwareEvolution can lead to
Problems with software
maintenance
© Fraunhofer IESE
15
Configuration Management to the rescue
SoftwareComplexity
ProcessComplexity
SoftwareEvolution
ConfigurationManagement controls
„which versionworked on date X"?
„what is the impact of
change X"?
„who is allowedto performchange X"?
© Fraunhofer IESE
16
Configuration Management Basic Functions
IdentificationIdentify what elements need to be controlledIdentify what elements are already being controlled
ControlControl the way a system evolves
Status accountingObtain information about the way a system evolves
AuditAssess the fulfillment of requirements
set goal(s)
characterizeand understand
selectmethods,techniques,tools
analyze experiences
prepare experiencesfor reuse
1122
334455
66
perform co
rrect
control
© Fraunhofer IESE
17
Additional Configuration Management Activities
Process Management
Enable the definition and enactment of development processes
Distributed Development
Explicitly support development in distributed teams
Communication facilities (e.g. chat, forums)
Support for medium to low bandwidth connections
Support for restricted connectivity (e.g. firewalls)
Replication
Extended awareness about ongoing changes
© Fraunhofer IESE
18
Main Concept: Configuration
Configuration
TagBaseline Release
© Fraunhofer IESE
19
CM Interactions
Artifact Artifact Artifact Artifact...
Product Line Processes
File Systems
software developersoftware developer
check out (version)update
check incommit
new versionnew branch
Configuration Management System
Implicit Knowledge Relying on Conventions(Naming, Branch Structure, ...)
wrt. variations in space
© Fraunhofer IESE
20
CM as an Variability Mechanism
ConcurrentVersionSystem(CVS)
Client Differentconfigurations
Mainly Releases
Configuration selection by name
Configurationselection bydate
© Fraunhofer IESE
21
Variability Management and Evolution
Changes
….
Engineering….
….
Changes
Engineering
….
Synchronization
Single System Development Product Line Development
Synchronization
Synchronization
Synchronization
Variability
© Fraunhofer IESE
22
Product Line Infrastructure
Product Line Life Cycle
Family Engineering
ProductLine
Artifact Base
Feedback
Application Engineering
ProductProduct
Requirements
Quality
Productivity
© Fraunhofer IESE
23
Management of Product Line Variation
Variation in Space x Time x Lifecycle[source: Biglever: The Systems and Software Product Line Lifecycle Framework]
© Fraunhofer IESE
24
--- Configuration Management ---Identification
© Fraunhofer IESE
25
Configuration Identification
Define the elements that need to be controlled
The controlled elements are called Configuration Items (CIs)
Aspects of identification
Selection (what is a CI, what is not a CI)
Structure (CI hierarchies)
Naming (unique identification)
Characterization (further meta data)
Access (CI server location, access rules)
© Fraunhofer IESE
26
Exercise: Which of the following artifacts should become CIs? Why? Why not?
Source code file
Make file
Requirements Specification
Architectural document
EXE file
Meeting minutes
Data base
configuration file
© Fraunhofer IESE
27
Structuring Configuration Items
Defining hierarchical structures of configuration itemsCommon Term: Product Structure
Defining baselines
Defining the “strictness” per configuration itemOnly IdentificationIdentification and Version ManagementControl, Version and Change Control
© Fraunhofer IESE
28
Example of a Product Structure
© Fraunhofer IESE
29
Software Architecture as a structuring mechanism
User Interface DisplaySound
MeasurementData Data Analysis Setup
Applications
Remote Access
System Interface
ConnectionManager
Data Collection
PC
Offline Analysis
Watch
Belt
User SetupData
Nesting of architectural elementscan guide the creation ofdirectories and files in CM
Dependencies
Bottleneck inconventional config.management
Configuration itemcandidates
© Fraunhofer IESE
30
Product Structures and Product Line Engineering
Product Line Structure
Product A Structure
Product B Structure
traceability
traceability
© Fraunhofer IESE
31
Naming Configuration Items
Configuration items must be assigned reasonable names
names == unique identifiers
The naming scheme can follow the product structure
The naming scheme should imply dependencies between CIs
For example
systemA/ui/service.c
systemA/ui/service.h
© Fraunhofer IESE
32
Naming and Product Lines
Naming may enable or hinder artifact reuse
Artifacts that are named in a way that can be reused:
ui/service.c
ui/service.h
Artifacts that are named in a way that is hard to reuse
systemA/ui/service.c
systemA/ui/service.h
© Fraunhofer IESE
33
--- Configuration Management ---Control
© Fraunhofer IESE
34
Configuration Control
Main component of configuration management
Configuration Control areas
Version management
Change management
Build management
Release management
© Fraunhofer IESE
35
Version Management
Main line Branch
Merge
Revision
© Fraunhofer IESE
36
Problems with Parallelism (1/2) Unclear Dependencies
© Fraunhofer IESE
37
Reuse and Configuration Management: Challenges
What control mechanisms should be applied to reusable artifacts
Is every reuse case to be documented?
How to propagate changes from Family to Application Engineering?
How to deal with the code ownership?
© Fraunhofer IESE
38
Illustrative Example: Sample Product Line
S
Application Engineering
Product 1
Product LineArtifact Base
Family Engineering
Application Engineering
Product 2Application
Engineering Product 3
A B
© Fraunhofer IESE
39
Illustrative Example: Sample Instantiations (black box)
SS
SS
SS
SS
S’S’
S’S’
Product 1
Product 2
Product 3
© Fraunhofer IESE
40
Illustrative Example: Sample Instantiations (white box)
S
A B
S
A’ B
S
A B
S
A B’
Product 1
Product 2
Product 3
Framework Engineering
© Fraunhofer IESE
41
Illustrative Example: Traceability given through CM
SS
SS
SS
SS
A
A
A
A A’
A
A
A
A A’
B
B
B
B
B’
B
B
B
B
B’
S’S’
S’S’
Product 1 branch of SProduct 1 branch of A
Product 1 branch of B
© Fraunhofer IESE
42
Illustrative Example: Complexity of CM
1. Open the version graph of S
2. Identify the product branches (there may be many other temporary branches next to the product branches)
3. For each product branch look for new S versions since the last synchronization between family and Application Engineering
4. For each new version of S query the configuration management system for the changes made in that version
5. Filter out product-specific changes and identify changes that may affect S
Find out if something has changed in the instances of S.
1 Activity requires 5 operations
© Fraunhofer IESE
43
Solution: Layer on top of configuration management
Configuration Management
Customization Layer
Product Line Engineer
PLE evolutioncontrol scenarios
Storage and controlled evolution ofversioned artifacts
© Fraunhofer IESE
44
Application EngineerFramework Engineer
Encapsulating Configuration Management
add-core-asset("Collection")
add directory in repository
mark it with special tag
add all directory entries
mark them with special tag
enable according permissions
release-core-asset("Collection")
enable according permissions for making "Collection" available for reuse
show-instance-diff("Collection")
check, is "Collection" a core asset?
search history of "Collection" for branches marked with special tag
traverse to branches, check history
instantiate-core-asset("Collection", "Product1")
check, is "Collection" a core asset?
do I have permissions?
create branch of core asset elements
mark branch with special tag
commit
common commit
show-core-diff("Collection")
check, have I branched off "Collection"?
check history of core asset "Collection"
is there a released change in the core asset?
© Fraunhofer IESE
45
Reuse in modern Configuration Management Systems
Basic Mechanism
Branching and Merging
Subversion
externals
Accurev
Streams
Clearcase
Views
© Fraunhofer IESE
46
Subversion: externals
$ svn propget svn:externals calc third-party/sounds http://sounds.red-bean.com/repos third-party/skins http://skins.red-bean.com/repositories/skinproj third-party/skins/toolkit -r21 http://svn.red-bean.com/repos/skin-maker
$ svn checkout http://svn.example.com/repos/calc
A calc
A calc/Makefile
…
Checked out revision 148.
Fetching external item into calc/third-party/sounds
A calc/third-party/sounds/ding.ogg
A calc/third-party/sounds/dong.ogg
A calc/third-party/sounds/clang.ogg
…
Defining elements thathave to be checked-out
in order for „calc“ to compile
© Fraunhofer IESE
47
AccuRev: Stream-based configuration management
Streams can be seen as „intelligent“ branches
Hierarchies of streams can be built
Propagating changes is easier than with standard branches
© Fraunhofer IESE
48
ClearCase Views
Views are also „intelligent“ branches
Views allow to put the focus on a particular area of development
Views can also be set-up in a hierarchical way
Propagating changes is easier
© Fraunhofer IESE
49
Simplifying product line development with ClearCase
Development Stream
that affects multiple variants
© Fraunhofer IESE
50
Further Reading
Alexis Leon (2005), Configuration Management Handbook, Artech House,
Berczuk, S. P. & Appleton, B. (2003), Software Configuration Management Patterns. Effective Teamwork, Practical Integration, Addison-Wesley, Boston.
Bays, M. E. (1999), Software Release Methodology, Prentice Hall PTR, Upper Saddle River.
Estublier, J. (1995), The Adele configuration manager, John Wiley & Sons, Inc., New York, NY, USA.
Conradi, R. & Westfechtel, B. (1998), 'Version Models for Software Configuration Management', ACM Computing Surveys 30(2), 232--282.
The Perforce Knowledge base, http://kb.perforce.com/