ISO/IEC 26557:2016

DRAFT INTERNATIONAL STANDARD
ISO/IEC DIS 26557
ISO/IEC JTC 1/SC 7 Secretariat: SCC
Voting begins on: Voting terminates on:
2015-08-10 2015-11-10
Software and systems engineering — methods and tools for
variability mechanisms in software and systems product
line
Titre manque
ICS:
THIS DOCUMENT IS A DRAFT CIRCULATED
FOR COMMENT AND APPROVAL. IT IS
THEREFORE SUBJECT TO CHANGE AND MAY
NOT BE REFERRED TO AS AN INTERNATIONAL
STANDARD UNTIL PUBLISHED AS SUCH.
IN ADDITION TO THEIR EVALUATION AS
BEING ACCEPTABLE FOR INDUSTRIAL,
TECHNOLOGICAL, COMMERCIAL AND
USER PURPOSES, DRAFT INTERNATIONAL
STANDARDS MAY ON OCCASION HAVE TO
BE CONSIDERED IN THE LIGHT OF THEIR
POTENTIAL TO BECOME STANDARDS TO
WHICH REFERENCE MAY BE MADE IN
Reference number
NATIONAL REGULATIONS.
ISO/IEC DIS 26557:2015(E)
RECIPIENTS OF THIS DRAFT ARE INVITED
TO SUBMIT, WITH THEIR COMMENTS,
NOTIFICATION OF ANY RELEVANT PATENT
RIGHTS OF WHICH THEY ARE AWARE AND TO
©
PROVIDE SUPPORTING DOCUMENTATION. ISO/IEC 2015

---------------------- Page: 1 ----------------------
ISO/IEC DIS 26557:2015(E)

COPYRIGHT PROTECTED DOCUMENT
© ISO/IEC 2015, Published in Switzerland
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form
or by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior
written permission. Permission can be requested from either ISO at the address below or ISO’s member body in the country of
the requester.
ISO copyright office
Ch. de Blandonnet 8 • CP 401
CH-1214 Vernier, Geneva, Switzerland
Tel. +41 22 749 01 11
Fax +41 22 749 09 47
copyright@iso.org
www.iso.org
ii © ISO/IEC 2015 – All rights reserved

---------------------- Page: 2 ----------------------
ISO/IEC DIS 26557

Table of Content Page
1 Scope .1
2 Normative references .1
3 Terms and Definitions .1
4 Variability mechanisms for software and systems product line .4
4.1 Overview .4
4.2 Reference model .5
5 Variability mechanism management .9
5.1 Variability mechanism planning .9
5.1.1 Estimate adequate resources needed for variability mechanism operation .9
5.1.2 Assign responsibility for variability mechanism operation .10
5.1.3 Defining quality assurance measures for variability mechanism operation .10
5.2 Variability mechanism enabling .11
5.2.1 Enable variability mechanism pool .11
5.2.2 Provide guidance for variability mechanism operation .12
5.2.3 Enable measurement infrastructure for quantifying variability mechanism operation .12
5.2.4 Procure resources needed to perform variability mechanism operation .12
5.3 Variability mechanism managing .13
5.3.1 Review the plan versus actual of variability mechanism operation .13
5.3.2 Assess issues in variability mechanism operation .14
5.3.3 Make corrective actions for variability mechanism operation .14
6 Variability mechanism operation .15
6.1 Variability mechanisms in requirements .15
6.1.1 Categorize requirements variability .16
6.1.2 Assess requirements level variability mechanism .16
6.1.3 Specify requirements level variability mechanism .17
6.1.4 Prepare bindings at requirements level .17
6.1.5 Verify requirements level variability mechanism .17
6.2 Variability mechanisms in design .18
6.2.1 Make architectural decisions on binding times .19
6.2.2 Assess variability mechanisms depending on the binding time .19
6.2.3 Define guides and rules on variability mechanisms in architectural texture .19
6.2.4 Specify architectural variability mechanisms .20
6.2.5 Prepare bindings at architecture level .20
6.2.6 Verify architectural variability mechanisms .21
6.3 Variability mechanisms in realization .21
6.3.1 Examine architectural decisions and architectural texture on realization .22
6.3.2 Assess detailed design level variability mechanisms .22
6.3.3 Specify detailed design level variability mechanisms .23
6.3.4 Define post-detailed design guides on variability mechanisms .23
6.3.5 Verify detailed design level variability mechanisms .24
6.3.6 Assess implementation level variability mechanisms .24
6.3.7 Specify implementation level variability mechanisms .24
6.3.8 Enable implementation level configurability .25
6.3.9 Prepare bindings at realization time .25
6.3.10 Verify implementation level variability mechanisms .26
6.4 Variability mechanisms in compile time .26
6.4.1 Examine architectural decisions and architectural texture on compile time .27
6.4.2 Assess compile time variability mechanisms .27
iv © ISO 2015 – All rights reserved

---------------------- Page: 3 ----------------------
ISO/IEC DIS 26557

6.4.3 Specify compile time variability mechanisms . 27
6.4.4 Enable compile time configurability . 28
6.4.5 Prepare bindings at compile time . 28
6.4.6 Verify compile time variability mechanisms . 28
6.5 Variability mechanisms in post-compile time . 29
6.5.1 Examine architectural decisions and architectural texture affecting post-compile time30
6.5.2 Assess post-compile time variability mechanisms . 30
6.5.3 Specify link time variability mechanisms . 30
6.5.4 Specify load time variability mechanisms . 31
6.5.5 Specify deployment time variability mechanisms . 31
6.5.6 Enable post-compile time configurability . 31
6.5.7 Prepare bindings at post-compile time . 32
6.5.8 Verify post-compile time variability mechanism . 32
6.6 Variability mechanisms at run time . 32
6.6.1 Examine architectural decisions and architectural texture affecting runtime
reconfiguration . 33
6.6.2 Assess run time variability mechanism . 33
6.6.3 Enable run time configurability . 34
6.6.4 Prepare bindings at run time . 34
6.6.5 Verify run time variability mechanism . 34
6.7 Variability mechanisms in testing . 35
6.7.1 Examine test strategy on variability mechanisms . 35
6.7.2 Assess the decisions on variability mechanisms of requirements, architecture, and
realization. 36
6.7.3 Specify variability mechanisms in each test level . 36
6.7.4 Enable reusability in testing . 36
6.7.5 Prepare bindings at test phase . 37
6.7.6 Verify variability mechanism in testing . 37
7 Variability mechanism support . 38
7.1 Relating variability mechanism to variability model . 38
7.1.1 Relate variability mechanism to variability model . 38
7.1.2 Add annotation to relationship . 39
7.2 Quality Assurance for Variability Mechanism . 39
7.2.1 Objectively evaluate variability mechanism processes . 40
7.2.2 Objectively evaluate variability mechanism work products . 40
7.2.3 Communicate and resolve noncompliance issues . 41
7.2.4 Establish records of variability mechanism quality assurance activities . 41
7.3 Binding time decision support . 41
7.3.1 Determine the value of decision variables on a decision table . 42
7.3.2 Specify decisions on binding time . 42
7.3.3 Verify the decision table . 43
7.4 Application configuration support . 43
7.4.1 Support realizing configurability . 43
7.4.2 Apply decision rules for configuration . 44
7.4.3 Improve configurability . 44
Bibliography . 46
Annex A. Variability mechanisms by development phases . 47
Annex B. Binding time decision from variability types . 48

© ISO 2015 – All rights reserved v

---------------------- Page: 4 ----------------------
ISO/IEC DIS 26557

Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies (ISO
member bodies). The work of preparing International Standards is normally carried out through ISO technical
committees. Each member body interested in a subject for which a technical committee has been established has
the right to be represented on that committee. International organizations, governmental and non-governmental, in
liaison with ISO also take part in the work. ISO collaborates closely with the International Electrotechnical
Commission (IEC) on all matters of electro-technical standardization.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 3.
Draft International Standards adopted by the technical committees are circulated to the member bodies for voting.
Publication as an International Standard requires approval by at least 75 % of the member bodies casting a vote.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights.
ISO shall not be held responsible for identifying any or all such patent rights.
(draft) International Standard ISO/IEC 26557 was prepared by Technical Committee ISO/IEC JTC1, Joint Technical
Committee 1, Subcommittee SC 7, Systems and Software Engineering.



vi © ISO 2015 – All rights reserved

---------------------- Page: 5 ----------------------
ISO/IEC DIS 26557

Introduction
Software and Systems Product Line (SSPL) engineering and management creates, exploits, and manages a
common platform to develop a family of products (e.g., software products, systems architectures) at lower cost,
reduced time to market, and with better quality. As a result, it has gained increasing global attention since 1990s.

Variability, which differentiates a member product from other products within a product line, plays an important role
in SSPL. Variability mechanism means ways to implement variability; it realizes variability in the product line
artifacts. Variability mechanisms differ in accordance with the binding time of variability. And variability of a product
line is introduced from product line scoping through product line testing, and its binding can occur at any phases of
product line development. Thus, variability mechanism should be systematically managed for the right operation in
domain engineering and for the right binding in application engineering. Furthermore, variability mechanisms
should support easy variability management and traceability management. Accordingly, this International Standard
provides processes with their supporting methods and tools capabilities for variability mechanism operation and for
managerial supports for the right use of variability mechanisms at domain engineering phases and the right
bindings at application engineering phases.
This International Standard can be used in the following modes:
-- By the users of this International Standard – to benefit people who want to adopt SSPL for producing their
products by guiding variability mechanism operation, variability mechanism management, and variability
mechanism supports.
-- By a product line organization – to provide guidance in the evaluation and selection for methods and tools for the
tasks of providing variability mechanism operation, variability mechanism management, and variability mechanism
supports.
-- By providers of tools and methods – to provide guidance in implementing or developing tools and methods by
providing a comprehensive set of the capabilities of methods and tools for supporting variability mechanism
operation, variability mechanism management, and variability mechanism supports.





© ISO 2015 – All rights reserved vii

---------------------- Page: 6 ----------------------
ISO/IEC DIS 26557


Software and systems engineering – Methods and tools for
variability mechanisms in software and systems product line
1 Scope
This International Standard deals with the tools and methods of variability mechanisms for software and system
product line. The scope of this International Standard is as follows:
 provide the terms and definitions related to variability mechanisms for software and systems product
lines.
 define processes and their subprocesses for operating variability mechanisms at each product line life
cycle stages and those for providing managerial supports. Those processes are described in terms of
purpose, inputs, tasks, and outcomes.
 define method capabilities to support the defined tasks of each process.
 define tool capabilities to automate/semi-automate tasks or defined method capabilities.

This International Standard does not concern processes and capabilities of tools and methods for a single system
but rather deals with those for a family of products.

2 Normative references
 ISO/IEC 26550:2013 Software and systems engineering – Reference model for product line engineering
and management
 ISO/IEC 26551:2013 Software and systems engineering – Tools and methods for product line
requirements engineering
 ISO/IEC 26552: Software and systems engineering – Tools and methods for product line architecture
(TBD)
 ISO/IEC 26555:2013 Software and systems engineering – Tools and methods for product line technical
management

3 Terms and Definitions
For the purposes of this document, the following terms and definitions apply. The general terms common to all
software and systems product line have been excluded. For more information concerning the general terms, the
reader should refer to “ISO/IEC 26550 Software and systems engineering ―Reference model for product line
engineering and management”.

3.1 application configuration
derivation for a member product specific executables from domain assets in realization
NOTE The specific configuration of an application is the binding results for the variation points with the selected
variants.
© ISO 2014 – All rights reserved 1

---------------------- Page: 7 ----------------------
ISO/IEC DIS 26557


3.2 binding
task for making a decision on relevant variants using domain variability model and decision tables
3.3 binding time
moment of variability resolution
NOTE The choice of binding time is independent from variability modeling. It is consequence of decisions made
from requirements through runtime. Demands for flexibility and the support of tools allow late binding times or
even the use of variable binding times.

3.4 binding time decision
selection for variability defined in platforms in accordance with the functional distinction between variability in time
and variability in space

3.5 configurability
degree of how well a variability mechanism supports the configuration of a member product

3.6 decision
determination for the value of decision variables in a decision table for describing the individual member product

3.7 decision table
table that specifies decision variables (including rules, constraints, and relevancy among variables) that will be
determined by application engineers

3.8 post-compile time
collective name for link time and load time that are right after the compilation of components

3.9 realization
stage for detailed design and construction

3.10 run time
stage that a member product is executed
NOTE Components can be developed, compiled, linked and loaded separately. Only at run-time they are
combined into a working system.

3.11 variability
characteristics that may differ among members of a product line
NOTE 1 The differences between members may be captured from multiple viewpoints such as functionality,
quality attributes, environments in which the members are used, users, constraints, and internal mechanisms that
realize functionality and quality attributes.
NOTE 2 It is important to distinguish between the concepts of system and software variability and product line
variability. Any system partially or fully composed of software can be considered to possess software variability
because software systems are inherently malleable, extendable, or configurable for specific use contexts. Product
line variability is concerned with the variability that is explicitly defined by product management. This International
Standard is primarily concerned with product line variability.
2 © ISO 2015 – All rights reserved

---------------------- Page: 8 ----------------------
ISO/IEC DIS 26557

EXAMPLE 1  In the case of a home automation system, in accordance with business strategy the use of a LAN
as an alternative to the EIB (European Installation Bus) in a home automation system might be a competitive
advantage for the company, since it allows the use of low-cost components.
EAMAPLE 2  Annex B provides variability examples in accordance with variability types.

3.12 variability mechanism
variability representation/implementation technique for the product line variability

NOTE It deals with variabilities based on the binding time at the specific life cycle stage

3.13 variability model
explicit definition for product line variability
NOTE It introduces variation points, types of variation for the variation points, variants offered by the variation
points, variability dependencies, and variability constraints. Variability models may be orthogonal to or integrated
in other models such as requirements or design models. There are two types of variability models: application
variability models and domain variability models.

3.14 variant
an option or an alternative that may be used to realize particular variation points
NOTE One or more variants must correspond to each variation point. Each variant has to be associated with one
or more variation points. Selection and binding of variants for a specific product determine the characteristics of
the particular variability for the product.

3.15 variant selection
decision making for a choice of a variant in a variation point
Syn: binding, variability resolution
3.16 variation point
representation corresponding to particular variable characteristics of products, domain assets, and application
assets in the context of a product line
NOTE Variation points show what of the product line element varies. Each variation point should have at least
one variant.

© ISO 2015 – All rights reserved 3

---------------------- Page: 9 ----------------------
ISO/IEC DIS 26557

4 Variability mechanisms for software and systems product line(SSPL)
4.1 Overview
Variability mechanism means a method for implementing the variability of a product line, and it incorporates
variability into the product line development artifacts. Because variability is introduced at the whole product line
life cycle stages and so binding does, variability mechanisms for implementing variability in accordance with its
binding time should be provided. It is necessary to classify variability mechanisms by binding times so the users
of this International Standard can choose proper variability mechanisms in accordance with the binding time
decisions. This subsection provides a set of variability mechanisms used at given binding times.
Bindings can occur at requirements phase. In the case of requirements binding decisions for whether external
requirements variabilities exist or not are made. Variability mechanisms in requirements differ in accordance with
requirements artefacts. Variability mechanisms in requirements can be summarized as follows:
 SSPL specifically defined mechanism: feature variability notation;
 Language extension mechanism: stereotype in activity diagram, sequence diagram, and state machine
diagram, colored notations in state machine diagram;
 Language supported mechanism: extends and includes in use case model, swim lane and notes in
activity diagram, notes in textual specification and sequence diagram, tags or markups in textural use
case scenario.

During architecture design bindings also occur. In the case of design time binding elements that compose
architectural structure such as components, ports, and connectors are selectable. In accordance with the variant
selection architectural structure differs. Components and interfaces are also substituted with another. Variability
mechanisms in design can be summarized as follows:
 SSPL specifically defined mechanism: plug-ins in component framework diagram, composite structure
diagram, package diagram, and deployment diagram, architecture reorganization in process table;
 Language extension mechanism: stereotype in component diagram, class diagram, E-R diagram, and
communication diagram;
 Language supported mechanism: notes or tagged values in component diagram, frameworks, pre- and
post-conditions in OCL(Object Constraint Language).

At realization phase additional variation points can be introduced and bindings can occur, so variability
mechanisms supporting variability in realization phase are required. Variability mechanisms in realization can be
summarized as follows:
 SSPL specifically defined mechanism: orthogonal feature set in model-driven approaches (e.g. KobrA);
 Language extension mechanism: stereotype in entity model, stereotype in detailed design level model;
 Language supported mechanism: generalization/specialization(extension) in classes,
aggregation(optional) in class, Abstract class designed as parameterized class(template) and concrete
classes(optional), tagged values in entity model, generics in codes, pointcut and advice concepts in
AOP(Aspect Oriented Programming), framework implementation methods (e.g. hotspots and hooks) in
framework.

There exists variability binding during compilation. And in some cases all bindings can be delayed after
compilation. Most bindings occurred during compilation are difficult to change in subsequent phase. Variability
mechanisms at compile time can be summarized as follows:
 SSPL specifically defined mechanism: break(variation point), adapt(include), and select(variants) in XVCL,
Markup(vp, insert_before, insert_after, insert) and highlighted variant elements code in frame technology;
 Language extension mechanism: None;
 Language supported mechanism: macro, #ifdef, and directives mark in codes for conditional compilation,
parameters in makefile.

4 © ISO 2015 – All rights reserved

---------------------- Page: 10 ----------------------
ISO/IEC DIS 26557

After compilation, bindings can occur for generating different linked configurations. Such bindings at compile time
and at link time are also difficult to change in subsequent phase. Variability mechanisms at link time can be
summarized as follows:
 SSPL specifically defined mechanism: configuration space including rules and constraints for different
bindings at link time;
 Language extension mechanism: None;
 Language supported mechanism: configuration files or linker directives for linking static libraries,
parameters in makefiles.

Bindings also occur for loading different executable files. Variability mechanisms at load time can be summarized
as follows:
 SSPL specifically defined mechanism: rules and constraints description for bindings at load time;
 Language extension mechanism: None;
 Language supported mechanism: import in source code or external makefile for load time dynamic linking.

For supporting different installation in accordance with the customer preferences or system environments,
bindings occur at deployment/installation time.
...