Strategic Reuse and Product Lines
Development and With the IBM
Rational Systems Platform
Eran Gery
Distinguished Engineer – IBM Continuous Engineering
IBM Confidential
© 2014 IBM Corporation
Please note
IBM’s statements regarding its plans, directions, and intent are subject to change or
withdrawal without notice at IBM’s sole discretion.
Information regarding potential future products is intended to outline our general product
direction and it should not be relied on in making a purchasing decision.
The information mentioned regarding potential future products is not a commitment, promise,
or legal obligation to deliver any material, code or functionality. Information about potential
future products may not be incorporated into any contract. The development, release, and
timing of any future features or functionality described for our products remains at our sole
discretion.
Performance is based on measurements and projections using standard IBM benchmarks in
a controlled environment. The actual throughput or performance that any user will experience
will vary depending upon many factors, including considerations such as the amount of
multiprogramming in the user’s job stream, the I/O configuration, the storage configuration,
and the workload processed. Therefore, no assurance can be given that an individual user
will achieve results similar to those stated here.
Information is confidential and must not be shared or redistributed without permission from
IBM. Plans are based on best information available and may change in future.
IBM Confidential
Agenda
• Why strategic reuse?
• The solution approach
• Solution elements
– Product definitions
– Configurations
– Parameterization
• Solution extensions
• Summary
3
IBM Confidential
Motivation
IBM Confidential
4
Why PLE - What is the problem/need?
• Too expensive to maintain multiple programs, that are all similar
• Need to reach broader spectrum of market, with a broader set of
customized products
• Serve multiple customers, different versions of products
• Reuse development IP across different customers
IBM Confidential
Strategic reuse: leveraging the high degree of commonality
to all those variants…
How do we effectively engineer all
those programs?
What is the engineering cost of
engineering this entire line?
How do we manage requirements
for each customer?
How many designs do we have to
maintain?
How do we effectively test it?
IBM Confidential
6
Product Line Engineering and Variant Management
A problem is found and
change applied
Problem fixed on platform
And propagates
Core platform/Base
product
Variant 1
Variant 2
Problem found in variant 2
Variant 3
Time
• Management of base platform engineering
• Enable parallel engineering of platform variants
• Enable controlled reuse and change propagation downstream and upstream
IBM Confidential
The Solution Approach
IBM Confidential
8
Key objectives for strategic in Rational’s SSE
Tests
•
Facilitate reuse of engineering assets across
product variants
–
•
Defining cross-domain product structure
Consistently manage product configurations
across all lifecycle domains
Create cross domain baselines
Support end to end consistent traceability,
navigation, query, and reporting
Tests
Requirements
Design
Requirements
Effectively creating new product variants
using generic architectures
Code
Variant n
“where is this asset used”
“where does this change need to go”
–
•
Variation
Effectively handling change propagation to
multitude of variants
–
–
•
Design
Understand component reuse across product
variants
–
–
•
Code
Reuse of requirements, tests, architectures,
implementation, and also others and 3rd party
assets across variants
–
•
Requirements
Tes
ts
Code
Variant 2
Parametric asset derivation
Tests
Design
Transitioning from “clone and own” to reuse
architecture
Requirements
Code
Variant 1
Function
Design
9
IBM Confidential
3 PLE Patterns
Multi-stream
•
•
•
#ifdef
Managing product variants as branches of engineering components and
artifacts across the lifecycle
RELM, RDNG, RTC, RQM, Rhapsody + DM
Intent is to deliver the core capability in 2014, complete 2015
Parameterized
•
•
•
Deriving variant components and artifacts from core product line assets using
parameters
RELM PD, Rhapsody, RTC SCM
Intent is for initial delivery in 2014, core capability in 2015
Feature-driven
•
•
•
Assembling variants by features
Consists partner tool integrations
Intent is to deliver throughout 2015/2016
IBM Confidential
10
Multi-Branch Variant
Management
IBM Confidential
11
Components and configurations
•
•
•
•
•
Components are collection of logically related artifacts from a particular domain
Artifacts have versions
A (component) configuration specifies the included artifacts and their versions
Configurations can share common artifacts and manage variability of other artifacts
Configurations can be mutable (stream) or immutable (baseline)
Requirements (DOORS NG)
R2
R1
R3
Component (Requirements Module)
Design (Design Manager)
R2
D2
R3
D1
D3
R1
Source Code (RTC)
D2
D1
= Concept artifact
= Version artifact
R2-V1
R2-V2
US
Test (Quality Manager)
Europe
R1-V1
R1-V2
= configuration
1212
D3
T2
R3-V1
China
IBM Confidential
shared artifact
R3-V2
T1
T3
Example: Components and configurations
Power Train [Base]
A1.1
A3.1
Common Requirement
A2.1
A4.1
Variant requirement
A5.1
Added requirement
Power Train [Model A]
A1.1
A3.1
A2.1
A4.2
A5.2
Power Train [Model B]
A1.1
A3.1
A2.1
A4.2
A5.3
Power Train [Model C]
A1.1
A3.1
A2.1
A4.2
A6.1
1313
IBM Confidential
A7.1
A5.3
The bigger picture – global configurations
• How do we configure requirements along with the respective tests, architecture,
and code?
• Global configurations (GCs) create compositions of configurations into multidomain composite configurations
• GCs are part of OSLC configuration management
• GCs can be hierarchical
A hierarchical GC
Domain (tool) configurations
Requirements
Architecture
System
Model v1.1
Test
Code
Requirements
Architecture
Subsystems L1
Gear v2.1
Test
Engine v1.1
Code
Requirements
Architecture
Subsystems L2
Pump 2.1
Spark v3.1
Test
Code
14
IBM Confidential
Cfgm
Global configurations - streams and baseline
• A stream is an evolution of a (global) configuration
over time, associated with a set of baselines
• Baselines record state in time and are immutable
• Streams are reusing common artifacts a use
different version where there is variability
• Artifacts can propagate across streams
• Product variants are realized as streams
Requirements
Architecture
AMR v1.1
Test
Requirements
Server v2.1
Reader v1.1
Architecture
Test
Requirements
Cellular 1.2
GPS v3.1
Architecture
Test
AMR
Manual AMR 2012
Time
A Stream
Manual AMR
A Baseline
Mobile AMR 2014
Mobile AMR
= Baseline
Grid AMR
= Artifact propagation
Function
IBM Confidential
The PD Tool - product structure & configurations
The product definition tool organizes
engineering artifacts in a structure of
hierarchical components. It also creates
global configurations across lifecycle tools
AMR
<2014>
Meter
Interface
<1.0>
Meter
Requirements
Requirements 1.0
A2
Meter
Design
Meter
Code
A1
Models 1.1
A2
A1
Meter
Test
Reader
<1.0>
A3
A3
Source code 1.2
A2
Reader
Requirements
Reader
Code
A1
A3
Test Cases 1.3
A2
A1
Reader
Test
AMR
Server
<1.0>
IBM Confidential
A3
Product Definition: Adding a new variant
AMR
Requirements 1.0
Meter
Interface
A2
Meter
Requirements
A1
A3
Requirements 2.0
A2
Models 1.1
A1
Meter
Design
Meter
Code
A3
A2
A1
A3
Source code 1.2
Models 2.1
A2
A1
A3
A2
Meter
Test
A1
A3
A2
Test Cases 1.3
Reader
Source code 2.2
A1
A3
A2
A1
AMR
Var=mobile
Meter
Interface
Var=GSM
A3
Test Cases 2.3
A2
A1
Meter
Requirements
Meter
Design
Meter
Code
Meter
Test
Reader
IBM Confidential
A3
PD tool functions
• Promoting reuse of components across
products and projects
Meter
Interface
– Finding components
– Reusing components in context
Meter
Requirements
Meter
Design
• Where used? – which products are using a
component
• Defining meta-data on components
Meter
Code
Meter
Test
– Attributes
Reader
• Compare product structures
• Parameterizing products
Reader
Requirements
– 150% Structures
Reader
Code
Reader
Test
Meters
Server
18
IBM Confidential
Parameterized variant
handling
19
IBM Confidential
© 2014 IBM Corporation
Parametric Variant Management
• Parametric components enable artifact reuse by parameterization
• Actual parameter settings derive concrete configurations of the parameterized artifacts
– Conditional inclusion
– Value substitution
Example: a parameterized component
Project washing machine; Configuration Base
Variability Parameters:
p_Market: Null
p_Controls: Null
p_NoPrograms: Null
[Condition: “market == EU”]
Environmental reqs EU
General requirements
Market: [p_market]
Controls: [p_controls]
NoPrograms:[p_NoPrograms]
TypeSignal:[p_Signal]
[Condition: “market == US”]
Environmental reqs US
[Condition: “market == China”]
Environmental reqs China
IBM Confidential
Program „short“
Program „medium“
Program „long“
[condition: #programs =3]
Example: Washing machine – derivation using parameters
Project WashingMachine; Configuration Europe
Variability Parameters:
p_Market: Europe
p_Controls: Both
p_NoPrograms: 2
General requirements
Environmental reqs EU
Market: Europe
Controls: Both
NoPrograms: 3
Program „ Short“
Program „Medium“
Project WashingMachine; Configuration US
Variability Parameters:
p_Market: US
p_Controls: Sensor
p_NoPrograms: 3
p_Signal: Both
p_Color: Black
General requirements
Environmental reqs US
Market: US
Controls: Sensor
NoPrograms: 3
Program „ short“
Program „Medium“
Program „Long“
IBM Confidential
Parametric Structure in RELM
Car
Car
<US>
pEngine = <>
pGearbox = <>
pSunroof = <>
pEngine = gas
pGearbox =auto
pSunroof = false
Power
Train
Power
Train
Engine
<Gas>
Engine
<Gas>
pEngine==Gas
Engine
<Turbo>
Engine
<Turbo>
pEngine==Turbo
GearBox
<Manual>
GearBox
<Manual>
pGear==Manual
GearBox
<Automatic>
GearBox
<Automatic>
pGear==Auto
Sunroof
Sunroof
pSunroof == TRUE
IBM Confidential
Platform Based Parametric PLE organization
[
Product line
(platform)
[]
[]
[]
[]
[]
[]
[]
Variability
parameters
Variant
4
Parameter
configuration 4
Variant
1
[]
Parameter
configuration 1
[]
Variant
2
Parameter
configuration 2
[]
[]
Variant
3
= Baseline
= Parameterized baseline
= Artifact derivation
Parameter
configuration 3
Tim
e
IBM Confidential
Solution Extensions
IBM Confidential
24
Integrating Feature Models
• Feature models represent the
“problem domain” abstraction of
the product line
• Capture a functional view of the
system components and their
variabilities from a product line
management standpoint
• Feature models have
configurations called feature
profiles, which drive the variability
parameters of the solution
Feature Model
Car
Market
US
Europe
• We plan to enable 3rd party feature
modeling tools to integrate with the
platform PLE services
L
XL
Gas
Hybrid
XLT
Feature Configuration
Constraint:
Hybrid only
Possible if
XLT
Car
Market
US
IBM Confidential
Diesel
Trim Level
– In our case they can be mapped to
dimension and dimension values
25
Engine
Engine
Trim Level
XL
Gas
Adding feature management to drive product configurations
Feature selection
Variant/
Feature
Market
Trim
Engine
Variant 1
EU
L
Diesel
Variant 2
US
XL
GAS
Variant 3
US
XLT
GAS
…
Car
…
OR
Market
US
Engine
Trim Level
Gas
XL
Parameters configuration
Engine =
Gas
Trim =
XL
Geo =
US
Parameterized Artifacts
Product Artifacts
26
IBM Confidential
Summary: the Rational solution
• Integrated multi domain product variability management
– Coarse and fine grain variability management
– Supports component based approaches
• Support reuse across all lifecycle domains
– Reuse of all engineering artifacts – not only source code
– From requirements through verification & validation
• Enables a transition from product centric reuse
approach to platform centric approach
– Avoid disruption through continuous evolution
• Supports all 3 dimensions of component and artifact
variation
– Temporal evolution, Parallel development, Functional
variation
• Supports a federated multi-tool approach based on
open protocols and standards
– Allows integration of new domains such as electronics
and 3rd party ALM tools
• Integrations with 3rd party feature based modeling tools
IBM Confidential
IBM Confidential
28
Thank You
IBM Confidential
An engineering view of a product – the PD tool
AMR
Meter
Interface
Meter
Requirements
Meter
Design
Meter
Code
Meter
Test
Requirements
A2
A1
A3
Models
A2
A1
A3
Source code
A2
Reader
A1
Reader
Requirements
A3
Test Cases
A2
Reader
Code
Reader
Test
AMR
Server
A1
A3
The product definition tool organizes engineering
artifacts in a structure of hierarchical
components referencing domain tool
components
IBM Confidential
Representing product configurations
AMR
<Base>
Meter
Interface
<
Meter
Requirements
Requirements 1.0
A2
Meter
Design
Meter
Code
A1
Models 1.1
A2
A1
Meter
Test
Reader
A3
A3
Source code 1.2
A2
Reader
Requirements
Reader
Code
A1
A3
Test Cases 1.3
A2
A1
Reader
Test
AMR
Server
IBM Confidential
A3
Configurations: Adding a new variant
Manual
AMR
Requirements 1.0
Meter
Interface
A2
Meter
Requirements
A1
A3
Requirements 2.0
A2
Models 1.1
A1
Engine
Design
Engine
Code
A3
A2
A1
A3
Source code 1.2
Models 2.1
A2
A1
A3
A2
Engine
Test
A1
A3
A2
Test Cases 1.3
Reader
Source code 2.2
A1
A3
A2
A1
Mobile
AMR
A3
Test Cases 2.3
A2
Meter
Interface
A1
Engine
Requirements
Engine
Design
Engine
Code
Engine
Test
Reader
IBM Confidential
A3
An engineering view of a product – the PD tool
Car
The product definition tool organizes
engineering artifacts in a structure of
hierarchical components
Power
Train
Engine
Engine
Requirements
Requirements (DOORS)
A2
Engine
Code
A1
A3
Source code (RTC)
Engine
Test
A2
A1
GearBox
A3
Test Cases (RQM)
GearBox
Requirements
A2
A1
GearBox
Code
GearBox
Test
IBM Confidential
A3
Defining complex configurations with RELM
The product definition tool organizes
engineering artifacts in a structure of
hierarchical components. It also specifies
global configurations across lifecycle domains
Car <US>
Power
Train 1.0
Engine 2.0
Requirements 1.0
Engine
Requirements
Requirements 1.2
A2
Engine
Code
Car <EU>
A1
A3
Source code 1.1
Engine
Test
Source code 1.2
Power
Train 2.0
A2
A1
A3
Engine 3.0
Test Cases 1.0
Engine
Requirements
Test Cases 1.1
Engine
Code
A2
A1
Engine
Test
IBM Confidential
A3
Parameters and conditions in RELM
• Product definitions in RELM may
contain
– Variability Parameters Definitions
– Conditional components
• Enables variant product structures that
can be reused across multiple variants
• Variability Parameters
– A set of “<variable>=<value>” pairs
– Can be used by downstream domain
tools
• E.g. For #ifdef statements
• Conditional components
– Essentially a variation point in the
structure whether a component should
be included as part of the variant or
not
• Implications on RTC
– When updating the RTC stream only
the conditional components that their
condition evaluates to true are
included
35
IBM Confidential
Configuring Variant artifact using parameters
Parameterized Asset
Trim
Variability
Parameters
Configured Asset
CO2
Car
Car
MaxCO2 = 100
MaxCO2 = [co2]
Gear
Gear
ESP
[Trim=LX]
Variability
Expressions
IBM Confidential
CO2 =
100
Trim =
L
Automated Meter Reader Scenario
IBM Confidential
37
Hierarchical Product Lines – producer/consumer scenario
• Components can be managed
like smaller products
– Having their own baselines
– Developed by different teams
and schedules
0
1
2
3
4
Model X
• Component teams and product
teams
0
1
Model Y
Model Y.1
Model x.1
Gear v2.1
Gear v2.1
Engine v1.1
Spark v3.1
Engine v2.0
Spark v3.1
Pump 2.1
Pump 1.1
0
1
2
3
Engine v1
0
1
Engine v2
0
1
2
3
Pump v1
Components are also products that are used by
larger products
IBM Confidential
0
Pump v2
1
Conceptual Links
• What happens to links when we create new versions of requirements?
– Conceptual links are defined relatively to conceptual requirements e.g. A1, A2, A3,
A4, A5
Power Train [Base]
A1.1
A2.1
A3.1
Common Requirement
L2
L1
A4.1
Variant requirement
A5.1
Added requirement
Power Train [Model A]
L1
A1.1
A2.1
L1
A3.1
L2
A4.2
A5.2
Conceptual Links persist when versions of objects are
replaced in a configuration
3939
IBM Confidential
Parallel development of components with streams
• All lifecycle tools implement configurations of components
– RTC, DOORS NG, Rhapsody Design Manager, RQM
• In RTC, a stream contains multiple components, reflecting a global
configuration of source components
• Streams are mapped to workspaces in the various domain tools
• Changes can be delivered across streams
– Deliveries may result in conflict detection that leads to a merge
Req 3
V1
Req 3
V3
Workspace
V 2012
Accept changes
Workspace
V 2013
Engineer A
Req 3
V2
40
Engineer B
IBM Confidential
Req 3
V4
V4 = merge (v2,v3)