-
Notifications
You must be signed in to change notification settings - Fork 1
/
VEL-v1.0-csprd01-model.xml
5752 lines (5095 loc) · 224 KB
/
VEL-v1.0-csprd01-model.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<?xml version="1.0" encoding="ISO-8859-1"?>
<!--
For use when a committee document points at the OASIS web site for publishing:
<?xml-stylesheet type="text/xsl"
href="http://docs.oasis-open.org/templates/DocBook/spec-0.8/stylesheets/oasis-specification-html.xsl"?>
<!DOCTYPE article
PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd"
For use when a committee document points to an embedded installation of DocBook
(note the instructions for embedding DocBook requires pruning some directories
and adjusting the stylesheet and DocBook directories in these declarations):
<?xml-stylesheet type="text/xsl"
href="../htmlruntime/spec-0.8/stylesheets/oasis-note-html-offline.xsl"?>
<?oasis-spec-base-uri ../htmlruntime/spec-0.8/?>
<!DOCTYPE article
PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
"../htmlruntime/spec-0.8/docbook/docbookx.dtd"
For use when a committee document is published in a local environment only
(note the instructions for local publishing require adjusting the stylesheet
and DocBook directories in these declarations):
<?xml-stylesheet type="text/xsl"
href="file:///Users/admin/z/oasis/spec-0.8/stylesheets/oasis-specification-html-offline.xsl"?>
<!DOCTYPE article
PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
"file:///Users/admin/z/oasis/spec-0.8/docbook/docbookx.dtd"
-->
<?xml-stylesheet type="text/xsl"
href="db/spec-0.8/htmlruntime/spec-0.8/stylesheets/oasis-note-html-offline.xsl"?>
<?oasis-spec-base-uri ../htmlruntime/spec-0.8/?>
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
"db/spec-0.8/htmlruntime/spec-0.8/docbook/docbookx.dtd" [
<!--the document properties-->
<!ENTITY dir "VEL">
<!ENTITY name "&dir;-v&version;">
<!ENTITY pstage "xxxx">
<!ENTITY version "1.0">
<!ENTITY stage "csprd01">
<!ENTITY title "Variability Exchange Language Version &version;">
<!ENTITY standard "Committee Specification Draft 01 / Public Review Draft 01">
<!ENTITY this-loc "https://docs.oasis-open.org/vel/&dir;/v&version;/&stage;">
<!ENTITY previous-loc "https://docs.oasis-open.org/vel/&dir;/v&version;/&pstage;">
<!ENTITY latest-loc "https://docs.oasis-open.org/vel/&dir;/v&version;">
<!ENTITY pubdate "13 November 2020">
<!ENTITY % MATHML.prefixed "INCLUDE">
<!ENTITY % MATHML.prefix "mml">
<!ENTITY % equation.content "(alt?, (graphic+|mediaobject+|mml:math))">
<!ENTITY % inlineequation.content "(alt?, (inlinegraphic+|inlinemediaobject+|mml:math))">
<!ENTITY % mathml PUBLIC "-//W3C//DTD MathML 2.0//EN" "http://www.w3.org/Math/DTD/mathml2/mathml2.dtd">
%mathml;
]>
<article status="Committee Specification Draft 01 / Public Review Draft 01">
<articleinfo>
<productname>&name;</productname>
<productnumber>&stage;</productnumber>
<releaseinfo role="track">Standards Track</releaseinfo>
<releaseinfo
role="OASIS-specification-this-authoritative">&this-loc;/&name;-&stage;.html</releaseinfo>
<releaseinfo
role="OASIS-specification-this">&this-loc;/&name;-&stage;.pdf</releaseinfo>
<releaseinfo
role="OASIS-specification-this">&this-loc;/&name;-&stage;.xml</releaseinfo>
<!--
<releaseinfo role="OASIS-specification-previous-authoritative">&previous-loc;/&name;-&pstage;.html</releaseinfo>
<releaseinfo role="OASIS-specification-previous">&previous-loc;/&name;-&pstage;.pdf</releaseinfo>
<releaseinfo role="OASIS-specification-previous">&previous-loc;/&name;-&pstage;.xml</releaseinfo>
-->
<releaseinfo
role="OASIS-specification-latest-authoritative">&latest-loc;/&name;.html</releaseinfo>
<releaseinfo
role="OASIS-specification-latest">&latest-loc;/&name;.pdf</releaseinfo>
<releaseinfo
role="OASIS-specification-latest">&latest-loc;/&name;.xml</releaseinfo>
<releaseinfo role="committee"><ulink conformance="skip"
url="https://www.oasis-open.org/committees/vel">OASIS Variability Exchange
Language (VEL) TC</ulink></releaseinfo>
<authorgroup>
<editor>
<firstname>Michael</firstname>
<surname>Schulze</surname>
<affiliation>
<orgname><ulink conformance="skip"
url="http://www.pure-systems.com/">pure-systems
GmbH</ulink></orgname>
</affiliation>
<email>[email protected]</email>
</editor>
<editor>
<firstname>Uwe</firstname>
<surname>Ryssel</surname>
<affiliation>
<orgname><ulink conformance="skip"
url="http://www.pure-systems.com/">pure-systems
GmbH</ulink></orgname>
</affiliation>
<email>[email protected]</email>
</editor>
<!-- Chairs -->
<othercredit>
<firstname>Michael</firstname>
<surname>Schulze</surname>
<affiliation>
<orgname><ulink conformance="skip"
url="http://www.pure-systems.com/">pure-systems
GmbH</ulink></orgname>
</affiliation>
<email>[email protected]</email>
</othercredit>
<othercredit>
<firstname>Uwe</firstname>
<surname>Ryssel</surname>
<affiliation>
<orgname><ulink conformance="skip"
url="http://www.pure-systems.com/">pure-systems
GmbH</ulink></orgname>
</affiliation>
<email>[email protected]</email>
</othercredit>
</authorgroup>
<pubdate>&pubdate;</pubdate>
<copyright>
<year>2020</year>
</copyright>
<legalnotice role="additional">
<title>Additional artifacts</title>
<para>This prose specification is one component of a Work Product which
also includes:</para>
<itemizedlist spacing="compact">
<listitem>
<para>{XML schemas}</para>
</listitem>
<listitem>
<para>{Other parts}</para>
</listitem>
</itemizedlist>
</legalnotice>
<legalnotice role="related">
<title>Related work</title>
<para>This specification replaces or supersedes:</para>
<itemizedlist spacing="compact">
<listitem>
<para>{specification replaced by this standard}</para>
</listitem>
<listitem>
<para>{specification replaced by this standard}</para>
</listitem>
</itemizedlist>
<para>This specification is related to:</para>
<itemizedlist spacing="compact">
<listitem>
<para>{related specifications}</para>
</listitem>
<listitem>
<para>{related specifications}</para>
</listitem>
</itemizedlist>
</legalnotice>
<legalnotice role="namespaces">
<title>Declared XML namespaces</title>
<para><ulink
url="https://docs.oasis-open.org/ns/vel/xxxx">https://docs.oasis-open.org/ns/vel/xxxx</ulink></para>
</legalnotice>
<abstract>
<para>The Variability Exchange Language (VEL) enables the exchange of
variability information among tools for variant management and
systems development. VEL eliminates the cost of building
customized interfaces by defining a standard way for information to be
exchanged among corresponding tools. Using VEL, a variant management
tool is able to read the variability from a development tool and pass
configurations of selected system features to a development tool.</para>
<para>By defining a common variability data interface that can be
implemented by both the development tools and the variant management
tools, VEL enables a continuous development process for variable systems
and more flexible use of tools.</para>
</abstract>
<legalnotice role="status">
<title>Status</title>
<para>This document was last revised or approved by the OASIS
Variability Exchange Language (VEL) TC on the above date. The level of
approval is also listed above. Check the “Latest
stage” location noted above for possible later
revisions of this document. Any other numbered versions and other
technical work produced by the Technical Committee (TC) are listed at
<ulink
url="https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=vel#technical">https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=vel#technical</ulink>.</para>
<para>Technical Committee members should send comments on this
specification to the TC’s email list. Others should send
comments to the TC by using the “<ulink
conformance="skip"
url="http://www.oasis-open.org/committees/comments/index.php?wg_abbrev=vel">Send
A Comment</ulink>” button on the
TC’s web page at <ulink
url="https://www.oasis-open.org/committees/vel/">https://www.oasis-open.org/committees/vel/</ulink>.</para>
<para>This specification is provided under the <ulink conformance="skip"
url="https://www.oasis-open.org/policies-guidelines/ipr/#Non-Assertion-Mode">Non-Assertion
</ulink> Mode of the OASIS IPR Policy, the mode chosen when the
Technical Committee was established. For information on whether any
patents have been disclosed that may be essential to implementing this
specification, and any offers of patent licensing terms, please refer to
the Intellectual Property Rights section of the TC’s web
page (<ulink
url="https://www.oasis-open.org/committees/vel/ipr.php">https://www.oasis-open.org/committees/vel/ipr.php</ulink>).</para>
<para>Note that any machine-readable content (<ulink conformance="skip"
url="https://www.oasis-open.org/policies-guidelines/tc-process#wpComponentsCompLang">Computer
Language Definitions</ulink>) declared Normative for this Work Product
is provided in separate plain text files. In the event of a discrepancy
between any such plain text file and display content in the Work
Product’s prose narrative document(s), the content in
the separate plain text file prevails.</para>
</legalnotice>
<legalnotice role="citation">
<title>Citation format</title>
<para>When referencing this specification the following citation format
should be used:</para>
<bibliolist>
<bibliomixed conformance="skip"><abbrev>&name;</abbrev>
<citetitle>&title;. </citetitle> <bibliomisc>Edited by Michael Schulze
and Uwe Ryssel. </bibliomisc> <date>&pubdate;. </date>
<releaseinfo>OASIS &standard;. </releaseinfo> <bibliomisc><ulink
url="https://docs.oasis-open.org/vel/VEL/v1.0/csprd01/VEL-v1.0-csprd01.html">&this-loc;/&name;-&stage;.html</ulink>.
Latest version: <ulink
url="https://docs.oasis-open.org/vel/VEL/v1.0/VEL-v1.0.html">&latest-loc;/&name;.html</ulink>.</bibliomisc></bibliomixed>
</bibliolist>
</legalnotice>
<legalnotice role="notices">
<title>Notices</title>
<para>Copyright © OASIS Open 2019. All Rights Reserved.</para>
<para>All capitalized terms in the following text have the meanings
assigned to them in the OASIS Intellectual Property Rights Policy (the
“OASIS IPR Policy”). The full
<ulink conformance="skip"
url="https://www.oasis-open.org/policies-guidelines/ipr">Policy</ulink>
may be found at the OASIS website.</para>
<para>This document and translations of it may be copied and furnished
to others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published, and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this section are included
on all such copies and derivative works. However, this document itself
may not be modified in any way, including by removing the copyright
notice or references to OASIS, except as needed for the purpose of
developing any document or deliverable produced by an OASIS Technical
Committee (in which case the rules applicable to copyrights, as set
forth in the OASIS IPR Policy, must be followed) or as required to
translate it into languages other than English.</para>
<para>The limited permissions granted above are perpetual and will not
be revoked by OASIS or its successors or assigns.</para>
<para>This document and the information contained herein is provided on
an “AS IS” basis and OASIS
DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED
TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
ANY OWNERSHIP RIGHTS AND ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE.</para>
<para>OASIS requests that any OASIS Party or any other party that
believes it has patent claims that would necessarily be infringed by
implementations of this OASIS Committee Specification or OASIS Standard
notify OASIS TC Administrator and provide an indication of its
willingness to grant patent licenses to such patent claims in a manner
consistent with the IPR Mode of the OASIS Technical Committee that
produced this specification.</para>
<para>OASIS invites any party to contact the OASIS TC Administrator if
it is aware of a claim of ownership of any patent claims that would
necessarily be infringed by implementations of this specification by a
patent holder that is not willing to provide a license to such patent
claims in a manner consistent with the IPR Mode of the OASIS Technical
Committee that produced this specification. OASIS may include such
claims on its website, but disclaims any obligation to do so.</para>
<para>OASIS takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to pertain
to the implementation or use of the technology described in this
document or the extent to which any license under such rights might or
might not be available; neither does it represent that it has made any
effort to identify any such rights. Information on
OASIS’ procedures with respect to rights in any document
or deliverable produced by an OASIS Technical Committee can be found on
the OASIS website. Copies of claims of rights made available for
publication and any assurances of licenses to be made available, or the
result of an attempt made to obtain a general license or permission for
the use of such proprietary rights by implementers or users of this
OASIS Committee Specification or OASIS Standard, can be obtained from
the OASIS TC Administrator. OASIS makes no representation that any
information or list of intellectual property rights will at any time be
complete, or that any claims in such list are, in fact, Essential
Claims.</para>
<para>The name “OASIS” is a
trademark of <ulink conformance="skip"
url="https://www.oasis-open.org">OASIS</ulink>, the owner and developer
of this specification, and should be used only to refer to the
organization and its official outputs. OASIS welcomes reference to, and
implementation and use of, specifications, while reserving the right to
enforce its marks against misleading uses. Please see <ulink
url="https://www.oasis-open.org/policies-guidelines/trademark">https://www.oasis-open.org/policies-guidelines/trademark</ulink>
for guidance.</para>
</legalnotice>
</articleinfo>
<section id="S-INTRODUCTION">
<title>Introduction</title>
<section id="S-OVERVIEW">
<title>Overview</title>
<section>
<title>Section Prolog</title>
<para>VEL is an interoperability standard that enables the exchange of
variability information among variant management tools and systems
development tools. The essential tasks of a variants management tool are
to abstractly represent and analyze the variability of a system as well as to
define system configurations by selecting the desired system features. A
system development tool captures information of a specific kind, such as
requirements, architecture, component design, or tests. In order to
enable the development of variable systems, a development tool either
has to have native support to express and deal with variability, or an external
capability must be provided that adds this functionality to the development tool.</para>
<para>To interconnect variants management with systems development the
information exchange among the corresponding tools must be established.
A variants management tool must be able to read the
variability from a development tool and to pass a configuration, i.e. a
set of selected system features, to the development tool. Up to now the
interfaces that support this information exchange are built for each
development tool anew. With VEL, a
common interface is defined that can be implemented by both the
development tools and the variants management tool, thus VEL eliminates
the cost of building customized interfaces by defining a standard way
for information to be exchanged between tools.</para>
</section>
<section>
<title>Variants Management, System Variability, and Variation
Points</title>
<para>Variants management is an activity that accompanies the whole
system development process and, therefore, is orthogonal to the other
development tasks. Like safety, security, and other system properties,
variability cannot be built into a system at the end of the process.
Rather, the desired variability has to be determined, analyzed,
designed, implemented and tested continuously, starting at the very
beginning of the process through to the final delivery of the system
or the system variant respectively. This means that within each
development stage – requirements analysis, design,
implementation, test, documentation, etc. – variability is an
aspect that has to be considered.</para>
<para>We consider as variable system a system that can be tailored by
the system producer according to individual clients’
needs. All variants of a variable system are developed within one
development process. In addition to the standard development tasks the
process must also provide the means to tailor the system in order to get
the client specific variant of the system. This may happen at
different stages, also known as (variance) binding times.</para>
<para>Variability is embodied in variation points. Consider as example
a requirements document. A requirement toward a system may be
<emphasis>optional</emphasis>. In this case, two system variants can
be formed by either selecting or deselecting the requirement. A set of
requirements may be <emphasis>alternatives</emphasis>, then each
selection of one of these requirements forms one system variant.
Finally, a requirement may contain a <emphasis>parameter</emphasis>,
and then each value that can be selected for this parameter yields a
system variant.</para>
<para>The same definition of variation points holds for all other
artifacts that are created in the development process – be it
analysis or design models such as the views defined in the meta model,
test specifications, code, documentation, or whatever. In each
artifact there may be optional elements, alternative elements, and
parameterized elements.</para>
<para>We do not specify here how these variation points are
represented in the artifacts. Some artifact formats support the
definition of variation points, in other cases appropriate means have
to be added. This obviously also has an impact on the tools that are
used to create and manage the artifacts. In some cases they are
capable to express variation points. In other cases adaptors have to
be built in order to incorporate variation points.</para>
</section>
<section>
<title>Variability View and Variants Management Tools</title>
<para>It is an accepted best practice to define an explicit abstract
variability view on a system under development to support variants
management continuously throughout the process. This abstraction
contains the bare information on the variability of the system. This
means that it describes which variants exist, but does not describe
how the variability is implemented. The variability information is
derived from an analysis of the commonalities, differences, and
dependencies of the system’s variants and is often
represented as a feature model.</para>
<para>A variants management tool supports the creation of an artifact
– a variability model – that represents the abstract
variability information. Moreover, it offers operations to select or
deselect system features and via this feature configuration to specify
the system’s variants.</para>
<para>The information of the variability view has to be connected with
the system development artifacts in order to define how the feature
selection (system configuration) determines the resolution of the
variation points within these artifacts, i.e. the selection of a
variation for each variation point. As soon as these connections are
established a feature configuration can be carried over to a
configuration of the variation points of the concerned artifact. The
technical realization of this connection is addressed by the
<emphasis>Variability Exchange Language</emphasis>.</para>
<para>At present there is no standard that would define how variation
points are expressed in different artifacts. That means that a tool
supplier who builds a variants management tool has to implement an
individual interface to each other tool that is used in a development
process to create the corresponding artifacts. The purpose of the
<emphasis>Variability Exchange Language</emphasis> is to support the
standardization of these interfaces by a common exchange format that
defines which information is exchanged between a variants management
tool and a tool that is used to manage a specific kind of artifacts in
a development process. As mentioned above, such a tool may either be a
tool that already supports the definition of variation points for the
concerned artifact kind, or it may be an adaptor that adds this
capability to an development tool.</para>
<para>The <emphasis>Variability Exchange Language</emphasis> defines a
requirement on tools or tool adaptors that intend to support variants
management. Such a tool has to be able to extract the data that is
defined in the <emphasis>Variability Exchange Language</emphasis> from
the artifact that it manages and to incorporate the data that is sent
from the variants management tool into this artifact.</para>
<figure id="_fig-velUseCase">
<title>Use case for the Variability Exchange Language</title>
<mediaobject>
<imageobject>
<imagedata align="center" contentdepth="344" contentwidth="534"
fileref="Figures/image1.png"/>
</imageobject>
</mediaobject>
</figure>
<para>A use case for the <emphasis>Variability Exchange
Language</emphasis> can be defined as follows. Assume an artifact with
variation points is given, for instance an artifact created with tool
A as shown in <xref linkend="_fig-velUseCase"/>. First the development tool has
to collect the data defined in the <emphasis>Variability Exchange
Language, </emphasis>essentially given by the variation points
contained in the artifact. It passes this data to the variants
management tool that builds a variability model based on the data. The
variability model can be used to define a system configuration by
selecting the desired system features. The corresponding data, i.e.
the configuration, formatted according to the <emphasis>Variability
Exchange Language</emphasis>, is passed back to the development tool
or adaptor that uses this data to create or derive an artifact variant
that corresponds to the system variant defined in the variants
management tool.</para>
<para>Applying this scenario to all development tools and artifacts
yields a consistent set of development artifacts for any system
variant. The variation points that correspond to
customer relevant system features should coincide in all artifacts,
i.e. they always induce the same variability model in the variants
management tool. In addition to that, there may also be internal
variation points, for instance implementation variants that do not
alter the visible properties of the system but are relevant for the
system construction process. These variation points give rise to a
staged variability model in which customer features are separated from
internal features.</para>
<para>Since the system configuration is built once and for all in the
variants management tool an identical configuration is passed to all
development tools and thereby ensures consistency of the variants
selection. It might only happen that internal features for instance
are not interpreted by some development tool because it is not
concerned with internal decisions, such as a requirements document or
a system test.</para>
</section>
</section>
<section id="S-TERMINOLOGY">
<title>Terminology</title>
<section id="S-KEY-WORDS">
<title>Key words</title>
<para>The key words <glossterm>must</glossterm>, <glossterm>must
not</glossterm>, <glossterm>required</glossterm>,
<glossterm>shall</glossterm>, <glossterm>shall not</glossterm>,
<glossterm>should</glossterm>, <glossterm>should not</glossterm>,
<glossterm>recommended</glossterm>, <glossterm>may</glossterm>, and
<glossterm>optional</glossterm> are to be interpreted as described in
<xref linkend="rfc2119"/>. Note that for reasons of style, these words
are not capitalized in this document.</para>
</section>
<!-- section id="S-DEFINITIONS">
<title>Definitions</title>
<variablelist>
<varlistentry>
<term>term</term>
<listitem>
<para>Definition</para>
</listitem>
</varlistentry>
<varlistentry>
<term>term</term>
<listitem>
<para>Definition</para>
</listitem>
</varlistentry>
</variablelist>
</section -->
<!-- section id="S-KEY-CONCEPTS">
<title>Key concepts</title>
<variablelist>
<varlistentry>
<term>concept</term>
<listitem>
<para>Definition</para>
</listitem>
</varlistentry>
<varlistentry>
<term>concept</term>
<listitem>
<para>Definition</para>
</listitem>
</varlistentry>
<varlistentry>
<term>concept</term>
<listitem>
<para>Definition</para>
</listitem>
</varlistentry>
</variablelist>
</section -->
</section>
<section id="S-NORMATIVE-REFERENCES">
<title>Normative References</title>
<bibliolist>
<!--
<bibliomixed id="docbook"><abbrev>DocBook</abbrev> <citetitle>DocBook
4.5 </citetitle> <date>17 January 2005. </date> <releaseinfo>OASIS
Committee Draft 4.5. </releaseinfo> <bibliomisc><ulink
url="https://www.docbook.org/specs/docbook-4.5-spec.html">https://www.docbook.org/specs/docbook-4.5-spec.html</ulink>.</bibliomisc></bibliomixed>
-->
<bibliomixed id="rfc2119"><abbrev>RFC 2119</abbrev> <citetitle>Key
words for use in RFCs to Indicate Requirement Levels</citetitle>,
<date>March 1997. </date> <author>
<firstname>S.</firstname>
<surname>Bradner</surname>
</author>. <releaseinfo>IETF (Internet Engineering Task Force) RFC
2119, </releaseinfo> <bibliomisc><ulink
url="http://www.ietf.org/rfc/rfc2119.txt">http://www.ietf.org/rfc/rfc2119.txt</ulink>.</bibliomisc></bibliomixed>
<bibliomixed id="rfc3986"><abbrev>RFC 3986</abbrev> <citetitle>Uniform Resource Identifier (URI): Generic Syntax</citetitle>,
<date>January 2005. </date> <author>
<firstname>T.</firstname>
<surname>Berners-Lee</surname>
</author>. <releaseinfo>IETF (Internet Engineering Task Force) RFC
3986, </releaseinfo> <bibliomisc><ulink
url="http://www.ietf.org/rfc/rfc3986.txt">http://www.ietf.org/rfc/rfc3986.txt</ulink>.</bibliomisc></bibliomixed>
<bibliomixed id="autosar"><abbrev>AUTOSAR</abbrev>
<author>
<surname>AUTOSAR</surname>
</author>. <bibliomisc><ulink
url="http://www.autosar.org">http://www.autosar.org</ulink>.</bibliomisc></bibliomixed>
</bibliolist>
</section>
<section id="S-NON-NORMATIVE-REFERENCES">
<title>Non-Normative References</title>
<para>TODO</para>
<!--
<bibliolist>
<bibliomixed id="oasis-spec"><abbrev>oasis-spec</abbrev>
<citetitle>OASIS Specification Publishing in DocBook XML Version
&version;. </citetitle> <date>&pubdate;. </date> <releaseinfo>OASIS
Working Draft. </releaseinfo> <bibliomisc><ulink
url="https://docs.oasis-open.org/templates/DocBook/spec-1.0/oasis-specification-1.0-csprd01.html">https://docs.oasis-open.org/templates/DocBook/spec-&version;/oasis-specification-&version;-&stage;.html</ulink>.</bibliomisc></bibliomixed>
<bibliomixed id="xml-assoc"><abbrev>xml-assoc</abbrev>
<title>Associating Style Sheets with XML documents Version 1.0.
</title> <date>29 June 1999. </date> <author>
<firstname>James</firstname>
<surname>Clark</surname>
</author>. <releaseinfo>W3C Recommendation. </releaseinfo>
<bibliomisc><ulink
url="http://www.w3.org/1999/06/REC-xml-stylesheet-19990629">http://www.w3.org/1999/06/REC-xml-stylesheet-19990629</ulink></bibliomisc></bibliomixed>
</bibliolist>
-->
</section>
</section>
<section>
<title>Overview of the Variability Exchange Language [TODO rework needed]</title>
<section>
<title>Preface and Core [TODO rework needed]</title>
<para>The core of the <emphasis>Variability Exchange Language</emphasis>
is given by the definition of variation points and their variations
– by the classes <classname>VariationPoint</classname> and <classname>Variation</classname> (see <xref
linkend="_Ref408311811"/>). In the following we use the class
names from the meta-model presented in Chapter <xref
linkend="_sec-detailedSpec"/> to discuss the corresponding concepts, such
as <classname>VariationPoint</classname> and <classname>Variation</classname>. This chapter gives a survey on the main
classes, in particular the ones shown in <xref
linkend="_Ref408311811"/>.</para>
<para>A detailed specification of all classes is provided in Chapter <xref
linkend="_sec-detailedSpec"/>.</para>
<figure id="_Ref408311811">
<title>An Overview of the Variability Exchange Language [TODO: There are three locations to specify "artifacts":
1) VariabilityExchangeModel.uri
2) VariationPoint.variableArtifact
3) StructuralVariation.variableArtifact
The question is what is the relationship between these attributes? What is referenced and which attribute is used for what purposes? -- Important -- E.g. add an appendix with examples]
[TODO: Check also all figures whether they show the abstract trait of classes correctly e.g. Structural/ParameterVariationPoint] </title>
<mediaobject>
<imageobject>
<imagedata contentdepth="777" contentwidth="605"
fileref="Figures/VEL-Overview.svg"/>
</imageobject>
</mediaobject>
</figure>
<para>A Variability Exchange Language document starts with a
<classname>VariabilityExchangeModels</classname> element, which contains a number of
<classname>VariabilityExchangeModel</classname> elements. Each <classname>VariabilityExchangeModel</classname>
corresponds to one artifacts with variable elements.</para>
<para>A <classname>VariabilityExchangeModel</classname> in turn contains a number of
<classname>VariationPoint</classname>s. Thus, a <classname>VariabilityExchangeModel</classname> describes the variable
aspects of an artifact, but only those. All non-variable facets of the
artifact are ignored because they are not necessary for our
purpose.</para>
</section>
<section>
<title>VariationPoint and Variation [TODO rework needed]</title>
<para>As shown in <xref linkend="_Ref408311811"/>, we distinguish
between two different kinds of <classname>VariationPoint</classname>s:</para>
<orderedlist>
<listitem>
<para>StructuralVariationPoints are variation points where the
structure of a model changes during the binding process.
StructuralVariationPoints define which elements are contained in a
bound artifact. There are two kinds of structural variation
points:</para>
<orderedlist numeration="loweralpha">
<listitem>
<para>OptionalStructuralVariationPoint – variation points
that can be selected or deselected.</para>
</listitem>
<listitem>
<para>XorStructuralVariationPoint – i.e. variation points
that represent sets of alternatives from which exactly one can
be selected.</para>
</listitem>
</orderedlist>
</listitem>
<listitem>
<para>ParameterVariationPoints are variation points which select a
numerical value for a parameter during the binding process. They do
not change the structure of an artifact. There are two kinds of
parameter variation points:</para>
<orderedlist numeration="loweralpha">
<listitem>
<para>CalculatedParameterVariationPoint – variation points
where the parameter value is calculated by an expression.</para>
</listitem>
<listitem>
<para>XorParameterVariationPoint – variation points where
the parameter value is selected from a list of values.</para>
</listitem>
</orderedlist>
</listitem>
</orderedlist>
<para>Each <classname>VariationPoint</classname> is associated with one or more <classname>Variation</classname>s. The
<classname>Variation</classname>s enumerate the possible variants for their respective
<classname>VariationPoint</classname>s. When an artifact is bound, then one of these variations
(OptionalStructuralVariationPoints also allow zero variations here) is
selected to be included in the bound artifact, and all others are
discarded.</para>
<para>Both <classname>Variation</classname>s and <classname>VariationPoint</classname>s may refer to artifact elements
(<varname>variableArtifact</varname>), for example the Simulink block
or the line of code which correspond to the <classname>VariationPoint</classname> respectively
Variation.</para>
<para><classname>VariationPoint</classname>s can further define dependencies on other variation
points (<classname>VariationDependency</classname>), for example one variation point may
require another variation points. This is useful to express technical
dependencies in artifacts.</para>
<para>Furthermore, a <classname>VariationPoint</classname> may contain other <classname>VariationPoint</classname>s to
establish a hierarchy (<classname>VariationPointHierarchy</classname>), similarly to subsystem
blocks in Simulink or hierarchies in software architectures.</para>
</section>
<section id="_Ref409084549">
<title>Variation Point Descriptions versus Variation Point Configuration [TODO rework needed]</title>
<para>A <classname>VariabilityExchangeModel</classname> as defined in <xref
linkend="_Ref408311811"/> can actually serve two different
purposes:</para>
<itemizedlist>
<listitem>
<para>A <emphasis>variation point description</emphasis> lists all
variation points and <emphasis>all</emphasis> their variations; that
is it describes the complete variability of an artifact.</para>
</listitem>
<listitem>
<para>A <emphasis>variation point configuration</emphasis> also lists
all variation points, but selects depending on a variation point's type
zero, one, or more variations for each variation point. The attribute
<varname>selected</varname> of a variation is used for that purpose.
Any such selection must be consistent with the <varname>expression</varname>
or <varname>condition</varname> attribute of a variation, as well as
with dependencies between variation points.</para>
</listitem>
</itemizedlist>
<para>Both variation point description and variation point configuration
use the same structure; the attribute type of <classname>VariabilityExchangeModel</classname>
determines how a <classname>VariabilityExchangeModel</classname> should be interpreted.</para>
</section>
<section>
<title>Binding [TODO rework needed]</title>
<para>The <emphasis>Variability Exchange Language</emphasis> does not
make any assumptions on how the binding process for the associated
artifact works. We do however provide a way to attach Conditions or
Expressions to <classname>Variation</classname>s:</para>
<itemizedlist>
<listitem>
<para>In a <classname>StructuralVariationPoint</classname>, a <classname>Variation</classname>
comes with a <varname>condition</varname> that determines whether the associated artifact
element is part of a bound artifact.</para>
</listitem>
<listitem>
<para>In a <classname>ParameterVariationPoint</classname>, the <classname>Variation</classname> determines a value
for the associated artifact element. This is done either by
evaluating an <varname>expression</varname> or selecting from one of several
<varname>value</varname>s (<classname>ParameterVariation</classname>).</para>
</listitem>
</itemizedlist>
<para>In a variation point description (see section <xref
linkend="_Ref409084549"/>) the result of the evaluation of a condition
or expression in a Variation must be compatible with the attribute
selected of a Variation. That is, if the attribute selected of a
Variation has the value <emphasis>true</emphasis>, then its condition
must also evaluate to <emphasis>true</emphasis>.</para>
</section>
<section>
<title>Common Concepts</title>
<para>Most classes in the <emphasis>Variability Exchange
Language</emphasis> are based on the class <classname>Identifiable</classname>, which provides
them with a name and a unique identifier. Identifable also provide a way
to attach application-specific data (<classname>SpecialData</classname>) to elements in the
<emphasis>Variability Exchange Language</emphasis>.</para>
</section>
<!-- section>
<title>API</title>
<para>In addition to the contents of the exchange format basic
operations of a Variability Interface are defined in the class
VariabilityAPI. These operations cover the following operations:</para>
<itemizedlist>
<listitem>
<para>The import and export of <classname>VariabilityExchangeModels</classname></para>
</listitem>
<listitem>
<para>Getting and setting configurations, which are also
<classname>VariabilityExchangeModels</classname></para>
</listitem>
<listitem>
<para>Getting information on the read or write access (Capability) to
<classname>VariationPoint</classname>s and <classname>VariabilityExchangeModels</classname> as
configurations.</para>
</listitem>
</itemizedlist>
</section -->
<section>
<title>Example</title>
<figure id="_fig-exampleSource">
<title>Example source code with C-preprocessor directives</title>
<mediaobject>
<imageobject>
<imagedata contentdepth="777" contentwidth="605"
fileref="Figures/example.png"/>
</imageobject>
</mediaobject>
</figure>
<para>To demonstrate the applicability of the Variability Exchange
Language for the exchange of variability information, we show as an
example a simple source code section in <xref linkend="_fig-exampleSource"/>, in which the C-preprocessor (cpp) is
employed to realize variability, and the extract of that variability
defined according to Variability Exchange Language (see <xref
linkend="_fig-exampleVEL"/>). We could have used further artifact types
like requirements, UML models, tests, etc. but for the sake of
simplicity and understandability we opted for C-source code using the
cpp.</para>
<figure id="_fig-exampleVEL">
<title>Example source code with C-preprocessor directives [TODO: Example isn't correct according to the VEL.xsd]</title>
<mediaobject>
<imageobject>
<imagedata contentdepth="777" contentwidth="605"
fileref="Figures/example-vel.png"/>
</imageobject>
</mediaobject>
</figure>
<para>To note, the cpp is a stand-alone tool for text processing, which,
although initially invented for C, is not limited to a specific language
and can be used for arbitrary text and source code transformations
leading e.g. to conditional code compilation. The cpp tool works on the
basis of directives (a.k.a. macros) that control syntactic program
transformations. The directives supported by the cpp tool can be divided
into four classes: file inclusion, macro definition, macro substitution,
and conditional inclusion.</para>
<para>In our example, we only use the macros <emphasis>A</emphasis> and
<emphasis>B</emphasis> and conditional inclusion mechanisms. The source
code comments in Figure <xref linkend="_fig-exampleSource"/> explain how
the cpp will transform the code depending on the definition of the
macros. From an abstract point of view, the code contains two variation
points and three variations, which is reflected according to the
Variability Exchange Language in the exchange format definition in <xref
linkend="_fig-exampleVEL"/>. The first variation point spans the source
lines 1-9 and contains two alternative variations. The variation point's
corresponding elements of the artifact – in this case exactly the
source lines – are represented in the exchange format as well.
Regarding the variations, the first one (lines 2-6) will be selected if
macro A is defined. Otherwise the second variation (line 8) gets
selected. Assuming that the macro names are identically with features or
at least there exists a mapping from a feature to a macro name, then the
<emphasis>condition</emphasis> in the eighth line in <xref
linkend="_fig-exampleVEL"/> is the equivalent to the first source code
line.</para>
<para>The [XMLmind] variation point (lines 3-5) is nested within the
first variation of the first variation point, constituting a variation
point hierarchy. Within the corresponding exchange format, the variation
points are not nested but the nesting information is covered by the
definition in the lines 15-17 in <xref linkend="_fig-exampleVEL"/>.
There, the nested variation point is referenced by its
<emphasis>id</emphasis>, resulting in a tree-like structure at the
end.</para>
</section>
</section>
<section id="_sec-detailedSpec">
<title>Variability Exchange Language Class Reference</title>
<section id="sec_artifactelement">
<title>ArtifactElement</title>
<section>
<title>Description</title>
<para>An <classname>ArtifactElement</classname> is a reference to an element in an
artifact.</para>
</section>
<section>
<title>Specification</title>
<figure>
<title>UML Diagram for class <classname>ArtifactElement</classname></title>
<mediaobject>
<imageobject>
<imagedata contentdepth="121" contentwidth="284"
fileref="Figures/ArtifactElement.svg"/>
</imageobject>
</mediaobject>
</figure>
<variablelist>
<varlistentry>
<term>Attribute <varname>type</varname></term>
<listitem>
<para>The optional attribute <varname>type</varname> specifies the type of the artifact that
is addressed by this <classname>ArtifactElement</classname>. The attribute <varname>type</varname>
is a string, so any user-defined type identifier can be used.</para>
</listitem>
</varlistentry><varlistentry>
<term>Attribute <varname>uri</varname></term>
<listitem>