SMartyParser: an XMI Parser for UML-based Software Product Line Variability Models

SMartyParser: an XMI Parser for

UML-based Software Product Line Variability Models

Leandro A. Lanceloti State University of Maringá (DIN-UEM) – Brasil

José C. Maldonado University of São Paulo (ICMC-USP) – Brasil

Itana M. S. Gimenes State University of Maringá (DIN-UEM) – Brasil

Edson A. Oliveira Junior [email protected]

State University of Maringá (DIN-UEM) - Brasil

SMartyParser: a XMI Parser for UML-based Variability Models – VaMoS 2013 – Edson Jr. 2

Outlines

l  Introduction

l  XMI for Metadata Interchange

l  The Parser for UML-based SPLs

l  SMartyParser Running Example l  Conclusions and On Going Works


Introduction l  Variability Management (VM) is a key issue for the success of

SPLs

l  Literature presents several well-known approaches for VM,

specially object-oriented

l  Several tools have been developed, such as, pure::variants and

SPLOT

l  however, a subset of the VM approaches is UML-based and

requires automated support for UML models

l  Tools have particular means to handle variabilities


Introduction l  Supporting for UML-based SPL models might be

provided by XMI files

l  Several questions: l  How to handle UML-based SPLs models containing variability in a

particular environment?

l  Do you have to adapt your environment to comply to existing tools?

l  How do you interchange SPL metadata between different environments?

l  …


The OMG’s XMI Standard l  XMI is the OMG’s standard for metadata interchanging

l  Plain XML parsers do not accurately support XMI files

1 <?xml version = '1.0' encoding = 'UTF-8' ?> 2 <XMI xmi.version = '1.2' 3 xmlns:UML = 'org.omg.xmi.namespace.UML' 4 xmlns:UML2 = 'org.omg.xmi.namespace.UML2' 5 timestamp = 'Tue Mar 06 20:22:06 BRT 2012'> 6 <XMI.content> 7 <UML:Diagram xmi.id = 'Iae204f0m135cde62a90mm58a3' 8 isVisible = 'true' 9 name = 'AGM - Core Assets'10 zoom = '0.91'>11 <UML:GraphElement.semanticModel>12 <UML:SimpleSemanticModelElement13 xmi.id = 'Iae204f0m135cde62a90mm7e5f'14 typeInfo = 'ClassDiagram'/>15 </UML:GraphElement.semanticModel>16 <UML:GraphElement.contained>17 ...18 ...19 </UML:GraphElement.contained>20 <UML:Diagram.owner>21 <UML:Uml1SemanticModelBridge22 xmi.id = 'Iae204f0m135cde62a90mm58a5'>23 <UML:Uml1SemanticModelBridge.element>24 <UML:Model25 xmi.idref = 'Iae204f0m135cde62a90mm4ae9'/>26 </UML:Uml1SemanticModelBridge.element>27 </UML:Uml1SemanticModelBridge>28 </UML:Diagram.owner>29 </UML:Diagram>30 <UML:Model xmi.id = 'Iae204f0m135cde62a90mm4ae9'31 name = 'Arcade Game Maker'>32 <UML:Namespace.ownedElement>33 <UML:Stereotype34 xmi.id = 'Iae204f0m135cde62a90mm544b'>35 <UML:Stereotype.baseClass>36 Permission</UML:Stereotype.baseClass>37 </UML:Stereotype>38 </UML:Namespace.ownedElement>39 </UML:Model>40 </XMI.content>41 </XMI>

Figure 1: Excerpt of the XMI Structure Main Ele-ments.

literature does not provide a solution for processing XMIfiles containing SPL variability models by means of the UMLprofiling mechanism, as discussed in Section 6.

2. XML METADATA INTERCHANGE (XMI)XMI [10] was created by the Object Management Group

(OMG) and it is a XML standard to facilitate the meta-data interchange between di↵erent tools based on the MetaObject Facility (MOF).

The XMI standard has been adopted because of its ca-pability of representing UML elements, including diagrams,classes, interfaces, relationships, inheritance, as well as infor-mation with regard to colors, fonts, formats, and position-ing. Several UML tools provide support for XMI files byimporting/exporting their UML models in the XMI format.

Although XMI is a widely adopted standard, interchang-ing UML models between tools might be a hard task. Thereare di↵erent XMI implementation versions. Most of the ex-isting UML tools support only one XMI version. In addition,some UML tools might extend UML in di↵erent ways, thusgenerating XMI code that does not comply with the stan-dard XMI.

Figure 1 presents an excerpt of the structure of a XMI fileand its main elements.

In Figure 1, the element UML:Diagram (line #7) representsa class diagram, as indicated by the attribute typeInfo =

‘ClassDiagram’ (line #14), as well as information with re-spect to its visual elements and their positions. Each di-agram contains references to its elements indicated by thetag UML:GraphElement.contained (line #19). The elementUML:Diagram.owner (line #20) indicates that the class dia-

Figure 2: Excerpt of the MDF Structure Elements.

Figure 3: Excerpt of a XTF File Showing How toExtract the Stereotype Element.

gram belongs (is associated) to the element UML:Model (line#30). Such an association is represented by the propertiesxmi.idref (line #25) and xmi.id (line #30). The attributexmi.id is the unique identifier of each object in a XMIfile. The attribute xmi.idref always refers to an attributexmi.id, thus, several objects can refer the same xmi.id

value. The UML:Model (line #30) is an essential element tothe XMI as it contains all the elements of an UML model hi-erarchically organized in the UML:Namespace.ownedElement

element (line #32).The processing of a XMI file is controlled by two XML-

based files, which are: the Metamodel Definition File (MDF),and the XMI Transformation File (XTF). For each MDF filethere might be various XTF files, one for each XMI version.These two files might be customized. The MDF file definesthe UML elements metamodel. Each element has its ownattributes, relationships, types, and metaclasses.

Figure 2 presents an excerpt of a MDF file containing thedefinition of the UML stereotype element.

In Figure 2 there are two data attributes, indicated bytype=“data”(lines # 206 and #207), which contain, respec-tively, the id and the name of the stereotype. The attributecontext (line #205) is a cross reference (type=“ref”) andit refers to its parent element. The attribute extendedele-ments (line #208) is similar to the previous one, however itmight contain more than one reference (multiplicity=“many”)and it refers to the elements that extend such a stereotype.

The XTF file defines how data is extracted from a XMIfile. It maps the UML metamodels according to the XMIspecifications. The XTF file must vary according to theXMI version to be processed or the UML tool version, whichexported such a XMI file. Figure 3 shows how to map thetransformation of the UML 1.4 element stereotype to XMI1.2.

In Figure 3, the tag xmitransformation (line #462) con-tains all required information to extract data from the el-ement UML:Stereotype. The attribute modelelement (line#462) indicates the type of element to which such trans-formation rule is applied and it must be the same declaredin the MDF file (Figure 2, line #204). The attribute xmi-

pattern (line #463) corresponds to the pattern of such an


Processing XMI Files l  Metamodel Definition File (MDF)

l  XMI Transformation File (XTF)










203 204 <modelelement name="stereotype">205 <attribute name="context" type="ref"/>206 <attribute name="id" type="data"/>207 <attribute name="name" type="data"/>208 <attribute name="extendedelements"209 type="ref" multiplicity="many"/>210 </modelelement>211 212


Figure 3: Excerpt of a XTF File Showing How toExtract the Stereotype Element.




based files, which are: the Metamodel Definition File (MDF),and the XMI Transformation File (XTF). For each MDF filethere might be various XTF files, one for each XMI version.These two files might be customized. The MDF file definesthe UML elements metamodel. Each element has its ownattributes, relationships, types, and metaclasses.

Figure 2 presents an excerpt of a MDF file containing thedefinition of the UML stereotype element.

In Figure 2 there are two data attributes, indicated bytype=“data”(lines # 206 and #207), which contain, respec-tively, the id and the name of the stereotype. The attributecontext (line #205) is a cross reference (type=“ref”) andit refers to its parent element. The attribute extendedele-ments (line #208) is similar to the previous one, however itmight contain more than one reference (multiplicity=“many”)and it refers to the elements that extend such a stereotype.

The XTF file defines how data is extracted from a XMIfile. It maps the UML metamodels according to the XMIspecifications. The XTF file must vary according to theXMI version to be processed or the UML tool version, whichexported such a XMI file. Figure 3 shows how to map thetransformation of the UML 1.4 element stereotype to XMI1.2.

In Figure 3, the tag xmitransformation (line #462) con-tains all required information to extract data from the el-ement UML:Stereotype. The attribute modelelement (line#462) indicates the type of element to which such trans-formation rule is applied and it must be the same declaredin the MDF file (Figure 2, line #204). The attribute xmi-












461 462 <xmitransformation modelelement="stereotype"463 xmipattern="UML:Stereotype">464 <trigger name="id" type="attrval" attr="xmi.id"/>465 <trigger name="name" type="attrval" attr="name"/>466 <trigger name="context" type="gcattrval"467 src="UML:ModelElement.namespace"468 attr="xmi.idref"/>469 <trigger name="extendedelements" type="gcattrval"470 src="UML:Stereotype.extendedElement"471 attr="xmi.idref"472 linkbackattr="stereotypes" />473 </xmitransformation>474 475 Figure 3: Excerpt of a XTF File Showing How toExtract the Stereotype Element.




based files, which are: the Metamodel Definition File (MDF),and the XMI Transformation File (XTF). For each MDF filethere might be various XTF files, one for each XMI version.These two files might be customized. The MDF file definesthe UML elements metamodel. Each element has its ownattributes, relationships, types, and metaclasses.Figure 2 presents an excerpt of a MDF file containing the

definition of the UML stereotype element.In Figure 2 there are two data attributes, indicated by

type=“data”(lines # 206 and #207), which contain, respec-tively, the id and the name of the stereotype. The attributecontext (line #205) is a cross reference (type=“ref”) andit refers to its parent element. The attribute extendedele-ments (line #208) is similar to the previous one, however itmight contain more than one reference (multiplicity=“many”)and it refers to the elements that extend such a stereotype.The XTF file defines how data is extracted from a XMI

file. It maps the UML metamodels according to the XMIspecifications. The XTF file must vary according to theXMI version to be processed or the UML tool version, whichexported such a XMI file. Figure 3 shows how to map thetransformation of the UML 1.4 element stereotype to XMI1.2.In Figure 3, the tag xmitransformation (line #462) con-

tains all required information to extract data from the el-ement UML:Stereotype. The attribute modelelement (line#462) indicates the type of element to which such trans-formation rule is applied and it must be the same declaredin the MDF file (Figure 2, line #204). The attribute xmi-



The SMartyParser l  SMartyParser stands for Stereotype-based Management

of Variability Parser

l  It is aimed at processing XMI files of UML-based SPL models in

which variabilities are represented by means of stereotypes

(UML profiles)

l  It was built taking as a basis the Open Core Framework,

from the SDMetrics project

l  Open Core provides Java classes for: l  Parsing XMI files

l  Define and apply metrics for OO models


SMartyParser Class Diagram

element in the XMI file. Each trigger maps how the stereo-type attributes are extracted. The attribute name declareswhich attribute must be retrieved and its value must matchto the declared in the MDF file. The attribute type indi-cates how the value is retrieved, whereas attr informs thesource of the value. There might be two or more xmitrans-formation tags for a same UML element, as the xmipatternvaries in di↵erent UML tools.

3. VARIABILITY CONCEPTS FOR PARS-ING SPL XMI FILES

Variability is the general term used to refer to the vari-able aspects of the products of a SPL. It is described throughvariation points and variants. A variation point is thespecific place in a SPL artifact to which a design decision isconnected. Each variation point is associated with a set ofvariants that corresponds to design alternatives to resolvethe variability [4, 7]. The selection of a variant might beconstrained by the selection of other variants for a particu-lar variation point.

The following items present the definition of each variabil-ity concept:

• Variability, according to Bosch [3], is “the ability ofa software or artifact to be changed, customized orconfigured for use in a particular context”;

• Variation Point is the resolution of variabilities ingeneric artifacts of a SPL. According to Jacobson etal. [6], “a variation point identifies one or more lo-cations at which the variation will occur.” Thus, avariation point may take place at generic artifacts andat di↵erent levels of abstraction. Basically, a variationpoint answers the question: What varies in a SPL? [7];

• Variant represents the possible elements through whicha variation point may be resolved. It may also repre-sent a way to directly resolve a variability. Basically,a variant answers the question: How does a variabilityor a variation point vary in a SPL? [7]. Variants mightbe: mandatory, optional, alternative inclusive (one ormore variants from a set of variants are selected), andalternative exclusive (only one variant from a set ofvariants is selected); and

• Constraints Between Variants define possible rela-tionships between two or more variants, thus enablingthe resolution of a specific variation point or a variabil-ity. Such constraints might be: requires - one variantrequires the presence of another variant; or mutex, onevariant imposes the absence of another variant.

4. THE SMARTYPARSER FOR PARSING SPLXMI FILES

In order to facilitate the handling of variability data pro-vided by UML-based SPLs by means of XMI files, we builtthe SMartyParser, a Stereotype-based Management of Vari-ability Parser.SMartyParser aims at processing XMI files to provide an

easier way of exchanging variability data between SPL en-vironments based on the representation of the variabilitiesmain concepts (Section 3) as UML profiles (stereotypes andtagged values).

SMartyParser Class Model

com.sdmetrics.model

XMIReader

br.uem.din.les.parserxmi

Model ProductLineModelParser

MetaModel

IProductLineUMLModelParser

XMITransformations

IProductLineVariabilityParser

XMITransformation

XMITrigger

ModelElement 1 1

MetaModelElement

1 1

1

*

1

*

* 1Transformati

*1

* 1

1

*

* 1 1

*

Figure 4: The SMartyParser Class Model.

Table 1: The SMartyParser Available Operations.

Once an UML-based SPL environment is designed, theSMartyParser speeds up the task of handling variabilitiesas it provides a set of operations to facilitate the queryingfor such SPL variabilities. Therefore, the development teamdoes not need to concentrate e↵orts in such a task.SMartyParser was built using the Java SE (Standard Edi-

tion) technology taking as a basis the Open Core frame-work [12] provided by the SDMetrics project. The OpenCore takes as input XMI files providing a means to ana-lyze UML models, perform measurements, and check UMLmodel rules. The parser’s three main classes (Figure 4) haveabout 350 lines of code (LOC) not counting the Open Coreimported classes, which has about 1,800 LOC. The averagetime to build the parser is 10 seconds over a Mac OS X,version 10.7.4, 1.7 GHz Intel Core i5 processor, 4 GB 1333MHz DDR3 RAM memory, and 128 GB flash hard drive.The average time for processing a 4.9 MB XMI file is about889 milliseconds.Figure 4 presents the SMartyParser class model.In the parser class model (Figure 4), the main class is Pro-

ductLineModelParser. Such a class implements two inter-faces: IProductLineUMLModelParser and IProductLineVari-

abilityParser. The former contains operations for han-dling basic UML elements, such as, classes, interfaces, usecases, actors, and components. The latter contains oper-ations specific for handling variabilities. Table 1 lists theavailable operations of such interfaces. Note that addingnew operations might extend such interfaces.The class ProductLineModelParser refers to a XMIReader,

which is responsible for processing the XMI file. The classXMIReader has two references: one for the UML metamodel(MDF) file, which is an instance of the MetaModel class; and


SMartyParser Available Operations

element in the XMI file. Each trigger maps how the stereo-type attributes are extracted. The attribute name declareswhich attribute must be retrieved and its value must matchto the declared in the MDF file. The attribute type indi-cates how the value is retrieved, whereas attr informs thesource of the value. There might be two or more xmitrans-formation tags for a same UML element, as the xmipatternvaries in di↵erent UML tools.

3. VARIABILITY CONCEPTS FOR PARS-ING SPL XMI FILES

Variability is the general term used to refer to the vari-able aspects of the products of a SPL. It is described throughvariation points and variants. A variation point is thespecific place in a SPL artifact to which a design decision isconnected. Each variation point is associated with a set ofvariants that corresponds to design alternatives to resolvethe variability [4, 7]. The selection of a variant might beconstrained by the selection of other variants for a particu-lar variation point.

The following items present the definition of each variabil-ity concept:

• Variability, according to Bosch [3], is “the ability ofa software or artifact to be changed, customized orconfigured for use in a particular context”;

• Variation Point is the resolution of variabilities ingeneric artifacts of a SPL. According to Jacobson etal. [6], “a variation point identifies one or more lo-cations at which the variation will occur.” Thus, avariation point may take place at generic artifacts andat di↵erent levels of abstraction. Basically, a variationpoint answers the question: What varies in a SPL? [7];

• Variant represents the possible elements through whicha variation point may be resolved. It may also repre-sent a way to directly resolve a variability. Basically,a variant answers the question: How does a variabilityor a variation point vary in a SPL? [7]. Variants mightbe: mandatory, optional, alternative inclusive (one ormore variants from a set of variants are selected), andalternative exclusive (only one variant from a set ofvariants is selected); and

• Constraints Between Variants define possible rela-tionships between two or more variants, thus enablingthe resolution of a specific variation point or a variabil-ity. Such constraints might be: requires - one variantrequires the presence of another variant; or mutex, onevariant imposes the absence of another variant.

4. THE SMARTYPARSER FOR PARSING SPLXMI FILES

In order to facilitate the handling of variability data pro-vided by UML-based SPLs by means of XMI files, we builtthe SMartyParser, a Stereotype-based Management of Vari-ability Parser.

SMartyParser aims at processing XMI files to provide aneasier way of exchanging variability data between SPL en-vironments based on the representation of the variabilitiesmain concepts (Section 3) as UML profiles (stereotypes andtagged values).

Figure 4: The SMartyParser Class Model.

Table 1: The SMartyParser Available Operations.Interface Method Description

IPro

duct

Line

UM

LMod

elPa

rser

getAllDiagrams Get all diagrams from the UML model getStructureDiagrams Get structural diagram getBehaviourDiagrams Get behavioral diagrams getInteractionDiagrams Get interaction diagrams getElementsByDiagram Get all elements of a given diagram

getElementsByDiagramByType Get all elements of a given diagram by type getElementByID Get an element by its ID

getElementsByType Get all elements of a given type

IPro

duct

Line

Varia

bilit

yPar

ser getAllVariabilities Get all variabilities (as UML comments)

getAllVariationPoints Get all variation points getAllVariables Get all variable elements

getOptionalVariants Get all optional variants getMandatoryVariants Get all mandatory variants getInclusiveVariants Get all inclusive variants getExclusiveVariants Get all exclusive variants getVariabilityByName Get a variability by its name

getVariantsOfAVariability Get all variants of a given variability getVariationPointOfAVariant Get the variation point of a given variant

getChildrenVariabilities Get all child variabilities from a given variability getVariantRequiredElements Get all variants required by a given variant

getVariantMutexElements Get all mutually exclusive variants of a given variant

Once an UML-based SPL environment is designed, theSMartyParser speeds up the task of handling variabilitiesas it provides a set of operations to facilitate the queryingfor such SPL variabilities. Therefore, the development teamdoes not need to concentrate e↵orts in such a task.

SMartyParser was built using the Java SE (Standard Edi-tion) technology taking as a basis the Open Core frame-work [12] provided by the SDMetrics project. The OpenCore takes as input XMI files providing a means to ana-lyze UML models, perform measurements, and check UMLmodel rules. The parser’s three main classes (Figure 4) haveabout 350 lines of code (LOC) not counting the Open Coreimported classes, which has about 1,800 LOC. The averagetime to build the parser is 10 seconds over a Mac OS X,version 10.7.4, 1.7 GHz Intel Core i5 processor, 4 GB 1333MHz DDR3 RAM memory, and 128 GB flash hard drive.The average time for processing a 4.9 MB XMI file is about889 milliseconds.

Figure 4 presents the SMartyParser class model.In the parser class model (Figure 4), the main class is Pro-

ductLineModelParser. Such a class implements two inter-faces: IProductLineUMLModelParser and IProductLineVari-

abilityParser. The former contains operations for han-dling basic UML elements, such as, classes, interfaces, usecases, actors, and components. The latter contains oper-ations specific for handling variabilities. Table 1 lists theavailable operations of such interfaces. Note that addingnew operations might extend such interfaces.

The class ProductLineModelParser refers to a XMIReader,which is responsible for processing the XMI file. The classXMIReader has two references: one for the UML metamodel(MDF) file, which is an instance of the MetaModel class; and


The SMartyParser l  SMartyParser was conceived based on the main UML-

based variability management concepts:

l  Variation Point

l  Variant (mandatory, optional, inclusive, exclusive)

l  Constraints between Variants (requires, mutex)


SMartyParser Configuration Properties Table 2: The SMartyParser Configuration FileAvailable Properties.

Property DescriptionX

MI-

rela

ted

uml_version the UML version xmi_version the XMI version

xmi_xtf_file_location the XTF file location xmi_mdf_file_location the MDF file location

xmi_model_file_location the XMI file location

Ste

reot

ype-

rela

ted

variability_stereotype the stereotype used for representing variabilities

variation_point_stereotype the stereotype used for representing variation points

mandatory_variant the stereotype used for representing mandatory variants

optional_variant the stereotype used for representing optional variants

inclusive_variant the stereotype used for representing inclusive variants

exclusive_variant the stereotype used for representing exclusive variants

variable_stereotype the stereotype used for representing variable elements

require_constraint the stereotype used for representing require constraints

mutually_exclusive_variant the stereotype used for representing mutually exclusive constraints

one for the transformation (XTF) file, which is an instanceof the XMITransformations class. It produces as a resultof the XMI file processing an instance of the Model class,which represents the UML model containing all the UMLelements modeled for a SPL. The Model class represents thebasic XMI element (UML:Model, Figure 1, line #30) and it iscomposed of a collection of ModelElement, which representsevery UML elements from an UML Model, such as, classes,relationships, diagrams, and packages. Each ModelElement

instance has its own MetaModelElement, describing its meta-model attributes.

The SMartyParser configuration is twofold: by definingthe XMI version of the XMI file to be processed, as well as itsrelated files (transformation and metamodel); and by settingup the stereotypes to be processed based on the variabilityconcepts discussed in Section 3.

Such a configuration can be performed by modifying thesmartyparser_config.properties file. This file contains aset of properties, which must be set for guiding the parser onprocessing a XMI file. Table 2 lists such available properties.

5. SMARTYPARSER USE EXAMPLEThis section illustrates how to use SMartyParser by con-

figuring and running it taking into account the SMarty ap-proach [8] for variability management and the Arcade GameMaker (AGM) SPL [13] UML models.

Note that SMartyParser is composed of a set of classesand operations for handling variability, therefore, it does notprovide any graphical user interface, facilitating its adoptionand configuration by SPL environments.

For the illustration purpose, we used the Stereotype-basedManagement of Variability (SMarty) approach [8] to pro-vide a SMartyParser use example.Table 3 presents the correspondence between the SMarty

stereotypes and the variability concepts presented in Section3. Thus, SMartyParser can be configured for processing suchstereotypes.The Arcade Game Maker (AGM) [13], according to the

SMarty approach [8], is used for illustrating the SMarty-Parser use example. AGM has a complete set of documentsand UML models.The AGM use case model has two actors, GamePlayer and

Table 3: Correspondence Between the SMartyStereotypes and Variability Concepts.

Figure 5: Arcade Game Maker Use Case Model Ac-cording to SMarty [8].

GameInstaller which trigger several use cases such as SaveGame, Exit Game, and Play Selected Game. The use casesCheck Previous Best Score and Save Score are triggeredby the GamePlayer actor, whereas Install Game is triggeredby GameInstaller.The use case Play Selected Game is the most important

use case. It has two extension points: initialization_ext_point and animation_ext_point. The former is respon-sible for allowing specific actions from the use case Ini-

tialization, whereas the latter is responsible for specificactions from Animation Loop which can be realized by dif-ferent games.The AGM.xmi file was generated by the Poseidon [5] tool

for the 1.2 XMI format. XTF and MDF files for Poseidonand other UML tools are available at the Open Core projectwebsite [12].By running SMartyParser, it automatically loads all of its

properties from the configuration file. The AGM examplewas built based on the UML 2.3, from which AGM modelswere exported as a XMI 1.2 file format.For instantiating the SMartyParser, the user only needs

to invoke the constructor of the ProductLineModelParser

class by executing the following instruction:ProductLineModelParser smartyParser =

new ProductLineModelParser();

Such a constructor is responsible for reading the respec-tive files indicated in the SMartyParser configuration file.Then, the SMartyParser interfaces operations (Table 1) areavailable to be called from the smartyParser reference.


SMartyParser Instantiation l  It is instantiated by running the following code:

ProductLineModelParser smartyParser = new

ProductLineModelParser();

l  The constructor is responsible for:

l  reading the respective files (MDF and XTF) indicated in the

SMartyParser configuration file; and

l  processing the XMI file


SMartyParser Variability Concepts and

Example Stereotypes Table 2: The SMartyParser Configuration FileAvailable Properties.








For the illustration purpose, we used the Stereotype-basedManagement of Variability (SMarty) approach [8] to pro-vide a SMartyParser use example.Table 3 presents the correspondence between the SMarty

stereotypes and the variability concepts presented in Section3. Thus, SMartyParser can be configured for processing suchstereotypes.The Arcade Game Maker (AGM) [13], according to the

SMarty approach [8], is used for illustrating the SMarty-Parser use example. AGM has a complete set of documentsand UML models.The AGM use case model has two actors, GamePlayer and


Variability Concept SMartyProfile Stereotype Variability «variability»

Variation Point «variationPoint» Mandatory Variant «mandatory» Optional Variant «optional» Inclusive Variant «alternative_OR» Exclusive Variant «alternative_XOR»

Require Constraint «requires» Mutually Exclusive Constraint «mutex»

Variable Elements «variable»


GameInstaller which trigger several use cases such as SaveGame, Exit Game, and Play Selected Game. The use casesCheck Previous Best Score and Save Score are triggeredby the GamePlayer actor, whereas Install Game is triggeredby GameInstaller.The use case Play Selected Game is the most important

use case. It has two extension points: initialization_ext_point and animation_ext_point. The former is respon-sible for allowing specific actions from the use case Ini-

tialization, whereas the latter is responsible for specificactions from Animation Loop which can be realized by dif-ferent games.The AGM.xmi file was generated by the Poseidon [5] tool

for the 1.2 XMI format. XTF and MDF files for Poseidonand other UML tools are available at the Open Core projectwebsite [12].By running SMartyParser, it automatically loads all of its

properties from the configuration file. The AGM examplewas built based on the UML 2.3, from which AGM modelswere exported as a XMI 1.2 file format.For instantiating the SMartyParser, the user only needs

to invoke the constructor of the ProductLineModelParser





Annotated Arcade Game Maker Use Case Model

Table 2: The SMartyParser Configuration FileAvailable Properties.








For the illustration purpose, we used the Stereotype-basedManagement of Variability (SMarty) approach [8] to pro-vide a SMartyParser use example.

Table 3 presents the correspondence between the SMartystereotypes and the variability concepts presented in Section3. Thus, SMartyParser can be configured for processing suchstereotypes.

The Arcade Game Maker (AGM) [13], according to theSMarty approach [8], is used for illustrating the SMarty-Parser use example. AGM has a complete set of documentsand UML models.

The AGM use case model has two actors, GamePlayer and


<<variability>>name = "play game"minSelection = 1maxSelection = 3bindingTime = DESIGN_TIMEallowsAddingVar = truevariants = {Play Brickels, Play Pong, Play Bowling}

<<variability>>name = "save score"minSelection = 0maxSelection = 1bindingTime = DESIGN_TIMEallowsAddingVar = truevariants = {Save Score}

<<variability>>name = "check score"minSelection = 0maxSelection = 1bindingTime = DESIGN_TIMEallowsAddingVar = truevariants = {Check PreviousBest Score}

<< mandatory >>Animation Loop

<< mandatory >>Initialization

<< mandatory >>Install Game

<< mandatory >>Uninstall Game

<< optional >>Check Previous Best Score

<< alternative_OR >>Play Bowling

<< alternative_OR >>Play Pong<< alternative_OR >>

Play Brickles

<< mandatory , variationPoint >>Play Selected Game

Extension Pointsinitialization_ext_point: animation_ext_point:

<< mandatory >>Exit Game

<< optional >>Save Score

<< mandatory >>Save Game

<< mandatory >>

GameInstaller

<< mandatory >>

GamePlayer

<< include >>

<< include >>

<< include >><< include >>

<< include >>

<< include >>

<< extend >> << extend >> << extend >>

<< requires >>


GameInstaller which trigger several use cases such as SaveGame, Exit Game, and Play Selected Game. The use casesCheck Previous Best Score and Save Score are triggeredby the GamePlayer actor, whereas Install Game is triggeredby GameInstaller.

The use case Play Selected Game is the most importantuse case. It has two extension points: initialization_ext_point and animation_ext_point. The former is respon-sible for allowing specific actions from the use case Ini-

tialization, whereas the latter is responsible for specificactions from Animation Loop which can be realized by dif-ferent games.

The AGM.xmi file was generated by the Poseidon [5] toolfor the 1.2 XMI format. XTF and MDF files for Poseidonand other UML tools are available at the Open Core projectwebsite [12].

By running SMartyParser, it automatically loads all of itsproperties from the configuration file. The AGM examplewas built based on the UML 2.3, from which AGM modelswere exported as a XMI 1.2 file format.

For instantiating the SMartyParser, the user only needsto invoke the constructor of the ProductLineModelParser





Executing SMartyParser l  To obtain all the diagrams, as a collection, one must

invoke the following operation:

smartyParser.getAllDiagrams();

l  For the AGM example, such an operation returns the following diagram as a ModelElement instance:

l  [AGM - Use Case Model]


Executing SMartyParser l  to obtain all variation points from the SPL models,

one can invoke the following operation:

smartyParser.getAllVariationPoints();

l  For the AGM example, such an operation returns the following variation points:

l  [Play Selected Game]


Conclusions

l  SMartyParser can be easily integrated to specific

environments for UML-based SPLs

l  The parser provides several operations based on UML

models and their variabilities represented as stereotypes

l  SMartyParser only requires one to properly configure its

configuration file avoiding misunderstanding of variability

concepts from de UML models


Limitations and On Going Works

l  Limitations of the parser includes:

l  variability representation based on stereotypes;

l  lack of an OCL engine for improving variability comprehension

and automatic product generation; and

l  the parser only processes use case, class, component and

activity diagrams.. so far….

l  On going works include:

l  the parser is being currently extended for sequence diagrams,

the UML package merging mechanism, SysML block definition

for ES, and the SPEM elements for process lines


Questions? Contributions?

l  If you prefer, contact me via e-mail:

l  [email protected]


l Obrigado ! ! !

l Grazie!!!

l Thank you ! ! !

Education

SMartyParser: an XMI Parser for UML-based Software Product Line Variability Models