Variability Management in Software Product Line Activity Diagrams

Diego R. Fiori , Itana M. S. Gimenes , Jos C. Maldonado and Edson A. Oliveira Junior e Informatics Department - State University of Maring - Brazil a Email: diegorafael.ori@gmail.com, {itana, edson}@din.uem.br Computing Systems Department - University of S o Paulo - Brazil a Email: jcmaldon@icmc.usp.br

AbstractThe software product line (PL) approach aims at promoting the generation of specic products based on the reusing of its core assets. Such core assets contain similar elements as well as features which vary according to specic products. The variability management has been an intensive and essential activity for the PL development. Several approaches are mainly focused on managing UML-based PL variabilities, more specically in use cases and classes models. Therefore, this paper presents a proposal for managing variabilities in PL activity diagrams. Thus, the SMarty approach has been extended allowing the evolution of its UML prole, the SMartyProle, and its variability management process, the SMartyProcess. The SEIs Arcade Game Maker (AGM) PL was used to illustrate the variability management in its main features activity diagrams. Keywords-Activity Diagram, Software Product Line, Variability Management, UML.

I. I NTRODUCTION Software systems development is increasing every day as well its complexity and granularity. Reusing techniques can be seen as a realistic opportunity to decrease such a complexity by taking advantage of existing and well succeeded approaches, such as component-based development and software product lines. The software product line (PL) engineering approach has gained increasing attention over the last years due to competitiveness in the software development segment. The economic considerations of software companies, such as cost and time to market, motivate the transition from single-product development to the PL approach, in which products are developed in a large-scale reuse perspective [7]. A PL represents a set of systems sharing common features that satisfy the needs of a particular market or mission segment [7], [11]. This set of systems is also called a product family. The familys members are specic products developed in a systematic way from the PL core assets. The core asset has a set of common features as well as a set of variable parts, which represent later design decisions [11]. The composition and the conguration of such assets yield specic products. The PL approach focuses mainly on a two-life-cycle model [7]: domain engineering, where the PL core asset is developed for reuse; and application engineering, where the core asset is reused to generate specic products. The

success of the PL approach depends on several principles, in particular variability management [4], [6], [7], [11], [17]. However, most of the existing solutions are only applied to specic PL approaches. Thus, there is a lack of an overall reasoning about variability management applied to more general approaches [3] which take advantages of widely consolidated standard notations as, for instance, UML and its proling extension mechanism [9] for specic domain applications. Although several approaches use this mechanism as a basis to represent variability [2], [4], [6], [18], most of them are not supported by a systematic process that provides guidelines to instruct the users on how to deal with variability issues in PL UML-based artifacts. SMarty [8] is an approach for variability management in UML-based PL. This approach is supported both by a UML prole, the SMartyProle, and a systematic variability management process, the SMartyProcess. SMarty makes it easier to deal with variability issues in PL. However, such an approach only supports use case, class and component models. Therefore, this paper presents an extension of the SMarty approach to encompass activity diagram models by means of the SMartyProle and new guidelines for the SMartyProcess. This paper is organized as follows: Section II presents basic concepts of UML activity diagrams; Section III discusses the main concepts of variability and the SMarty approach; Section IV proposes an extension of the SMarty approach by encompassing UML activity diagram models; Section V discusses related work; and Section VI presents the conclusion and directions for future work. II. UML AND ACTIVITY D IAGRAMS UML is a language for modeling object-oriented systems which is based in a wide vocabulary and concepts [9]. By means of its diagrams it is possible to represent software systems in such a way that stakeholders can communicate one another the systems main requirements and features. Amongst the several UML diagrams, the activity diagram is one of the most important as it is responsible for communicating the actions via information/object ows. Moreover, such a diagram can represent artifacts produced during the execution of actions, as well as indicate partitions in which one might establish group of actions. The ow amongst

actions is usually based on decision nodes, as well as join and merge nodes. Table I present the main elements of a UML activity diagram.
Table I M AIN UML ACTIVITY D IAGRAM E LEMENTS [9].
UML Metamodel InitialNode ActivityFinal Action ControlFlow DecisionNode MergeNode ForkNode JoinNode Notation Description It indicates the beginning of a flow. Final node of a diagram. It represents the end of a flow. It represents a step of an activity. It indicates a flow between two actions. It represents a choice among exit flows. It merges various income flows to only one outcome flow. It splits a flow in multiple concurrent flows. It synchronizes multiple flows in only one exit flow. It groups actions for a certain feature.

ActivityPartition

Activity diagrams have been used for several reasons as: (i) generating test cases [12]; (ii) Business Process Modeling (BPM) [10]; and (iii) modeling PL variabilities [13][15]. III. VARIABILITY M ANAGEMENT IN S OFTWARE P RODUCT L INES Variability is the general term used to refer to the variable aspects of the products of a PL. It is described through variation points and variants. A variation point is the specic place in a PL artifact to which a design decision is connected. Each variation point is associated with a set of variants that corresponds to design alternatives to resolve the variability [7], [11]. According to [7], [11], variability management is related to every activity of a PL approach and must comprise the following activities: variability identication, consists of identifying the differences between products and where they take place within PL artifacts; variability delimitation, denes the binding time and multiplicity of variabilities; variability implementation, is the selection of implementation mechanisms; variant management, controls the variants and variation points. These activities and the related concepts form the basis of the SMarty approach. SMarty [8] is an approach for UML Stereotype-based Management of Variability in PL. It is composed of a UML 2 prole, the SMartyProle, and a process, the SMartyProcess. SMartyProle contains a set of stereotypes and tagged values to represent variability in PL models. Basically,

SMartyProle uses a standard object-oriented notation and its proling mechanism [9] both to provide an extension of UML and to allow graphical representation of variability concepts. Thus, there is no need to change the system design structure to comply with the PL approach. SMartyProcess is a systematic process that guides the user through the identication, delimitation, representation, and tracing of variabilities in PL models. It is supported by a set of application guidelines as well as by the SMartyProle to represent variabilities. The SMartyProle represents the relationship of major PL concepts with respect to variability management. There are four main concepts: variability [1], variation point [11], variant [11], and variant constraints [1]. SMartyProle is composed of the following stereotypes and respective tagged values: variability represents the concept of PL variability and is an extension of the metaclass Comment. This stereotype has the following tagged values: name, the given name by which a variability is referred to; minSelection, represents the minimum number of variants to be selected to resolve a variation point or a variability; maxSelection, represents the maximum number of variants to be selected in order to resolve a variation point or a variability; bindingTime, the moment at which a variability must be resolved, represented by the enumeration class BindingTime; allowsAddingVar, indicates whether it is possible or not to include new variants in the PL development; variants, represents the collection of variant instances associated with a variability; and realizes, a collection of lower-level model variabilities that realize this variability. variationPoint represents the concept of PL variation point and is an extension of the metaclasses Actor, UseCase, Interface, and Class. This stereotype has the following tagged values: numberOfVariants, indicates the number of associated variants that can be selected to resolve this variation point; bindingTime, the moment at which a variation point must be resolved, represented by the enumeration class BindingTime; variants, represents the collection of variant instances associated with this variation point; and variabilities, represents the collection of associated variabilities. variant represents the concept of PL variant and is an abstract extension of the metaclasses Actor, UseCase, Interface, and Class. This stereotype is specialized in four other non-abstract stereotypes which are: mandatory , optional , alternative OR , and alternative XOR . The stereotype variant has the following tagged values: rootVP, represents the variation point with which this variant is associated; and variabilities, the collection of variabilities with which this variant is associated. mandatory represents a compulsory variant that is

part of every PL product. optional represents a variant that may be selected to resolve a variation point or a variability; alternative OR represents a variant that is part of a group of alternative inclusive variants. Different combinations of this kind of variants may resolve variation points or variabilities in different ways. alternative XOR represents a variant that is part of a group of alternative exclusive variants. This means that only one variant of the group can be selected to resolve a variation point or variability; mutex represents the concept of PL variant constraint and is a mutually exclusive relationship between two variants. This means that when a variant is selected another variant must not also be selected; requires represents the concept of PL variant and is a relationship between two variants in which the selected variant requires the choice of another specic variant; variable is an extension of the metaclass Component. It indicates that a component has a set of classes with explicit variabilities. This stereotype has the tagged value classSet which is the collection of class instances that form a component. Variability identication is a domain-dependent activity which requires abilities of the PL managers and analysts. Therefore, SMartyProcess provides guidelines to support the variability identication activity, which include: G.1 elements of use case models related to the extend and extension points mechanism1 [9] suggest variation points with associated variants which might be inclusive or exclusive alternative; G.2 in class models, variation points and their variants are identied in the following relationships [9]: generalization, the most general classiers are the variation points and the most specic ones are the variants; interface realization, the suppliers (specications) are variation points and the implementations (clients) are the variants; aggregation association, the typed instances with hollow diamonds are the variation points and the associated typed instances are the variants; and composite aggregation, the typed instances with lledin diamonds are the variation points and the associated typed instances are the variants; G.3 elements of use case models related to the include (dependency) or association from actors relationships [9] suggest either mandatory or optional variants; G.4 elements of class models related to the association relationship in which the aggregationKind attribute has value none [9], i.e., neither an aggregation nor a composition suggest either mandatory or optional variants;
1 In SMarty, use case generalization is not used to represent variation points and variants as it does not represent the adding of specic actions from specialized use cases, as the extend relationship does [2].

G.5 variants that require the existence of other variants must tag their relationships as requires ; G.6 mutually exclusive variants for a certain product must tag their relationships as mutex ; and G.7 components, in component models, with variation point or variant classes are stereotyped as variable . IV. M ANAGING VARIABILITY IN ACTIVITY D IAGRAMS In order to gathering activity diagram variability management state of the art, a Systematic Literature Review (SLR) was performed. Such a SLR resulted in 223 primary studies, from indexed repositories (IEEE Xplore, ACM Digital Library, ScienceDirect and SpringerLink). From the total, 16 were selected for full reading. Thus, 5 studies were classied as relevant, which are discussed in Section V. Based on the set of relevant studies, it was proposed an extension of the SMarty approach. Therefore, the following sections present such an extension, as well as an example of this extension applied to activity diagrams of the Arcade Game Maker (AGM) PL [16] main features. A. Extending SMarty to Support Activity Diagrams The proposed extension for SMarty is twofold: (i) an evolution of SMartyProle by extending new metaclasses; and (ii) the addition of new guidelines for identifying and representing variability in activity diagrams. The evolved version of the SMartyProle (Figure 1) encompasses the extension of three metaclasses as follows: DecisionNode which might be considered a variation point and can be tagged with variationPoint as it allows the choice of different ows; Action which might be identied as a variant of any of the following types mandatory ( mandatory ), optional ( optional ), alternative inclusive ( alternative OR ) or alternative exclusive ( alternative XOR ); and ActivityPartition which might be dened with variable as it can encompass decision and action nodes with variability. New guidelines were proposed for complementing the current SMartyProcess guidelines. Such new guidelines aim at identifying and representing variability in activity diagrams based on the three metaclasses extended in Figure 1: G.8 DecisionNode elements in activity diagrams suggest variation points tagged with variationPoint as they explicitly represent multiple paths for distinct actions groups; G.9 Action elements in activity diagrams might be dened as mandatory or optional variants tagged, respectively, with mandatory and optional ; G.10 Action elements in activity diagrams which represent alternative exit ows from a DecisionNode

package SMartyProfile v1.1 [

Untitled1 ]

UML2 Metamodel
<<metaclass>> DecisionNode <<metaclass>> Actor <<metaclass>> UseCase <<metaclass>> Interface <<metaclass>> Class <<metaclass>> Action <<metaclass>> ActivityPartition <<metaclass>> Com ponent <<metaclass>> Dependency <<metaclass>> Comm ent

{required}

{required} {required} {required}

{required}

<<import>>

<<profile>>

SMartyProfile

<<stereotype>> variationPoint [Actor, Class, DecisionNode, Interface, UseCase] +numberOfVariants : Integer = 0 +bindingTime : BindingTime [1] = DESIGN_TIME -variants : Collection [0..*] +variabilities : Collection [0..*]

<<stereotype>> variant [Action, Actor, Class, Interface, UseCase] -rootVP : variationPoint [1] = null +variabilities : Collection [0..*]

<<stereotype>> variable [ActivityPartition, Component] +classSet : Collection [1..*]

<<stereotype>> m utex [Dependency]

<<stereotype>> requires [Dependency]

<<stereotype>> variability [Comment] +name : String +minSelection : Integer [1] = 1 +maxSelection : Integer [1] = 1 +bindingTime : BindingTime [1] = DESIGN_TIME +allow sAddingVar : Boolean [1] = true +variants : Collection [1..*]

<<enumeration>> BindingTim e DESIGN_TIME LINK_TIME COMPILE_TIME RUNTIME

<<stereotype>> m andatory [Actor, Class, Interface, UseCase]

<<stereotype>> optional [Actor, Class, Interface, UseCase]

<<stereotype>> alternative_OR [Actor, Class, Interface, UseCase]

<<stereotype>> alternative_XOR [Actor, Class, Interface, UseCase]

Figure 1.

SMartyProle Supporting Activity Diagram Elements.

suggest inclusive ( alternative OR ) or exclusive ( alternative XOR ) variants; and G.11 ActivityPartition elements in activity diagrams which contain elements with associated variability, DecisionNode as a variation point or Action as a variant, must be tagged with variable . B. Application Example of the Extended SMarty The Arcade Game Maker (AGM) [16] is a pedagogical PL for deriving games for mobile devices created by the SEI to support learning and experimenting based on PL concepts. Its main features are: play selected game, install game, save game, and load game. The essential AGM UML models [8] are the feature model, the use case model, the core asset class model, and the component architecture. Figure 2 presents the saveGame() method activity diagram. Such a diagram was obtained by reverse engineering the AGM source code. This feature can be triggered by the GamePlayer actor represented by the ActivityPartition. A variation point is identied in a DecisionNode right after the action String byteString = null; according to guideline G.8. Thus, it is possible to decide which actions must be followed. The three possible actions are tagged with alternative OR (according to guideline G.10) as a possible derived product might save more than one game. The DecisionNode path guard expressions decide which ow(s) must be followed according to guideline G.10. A variability named record store is associated with the variation point DecisionNode. Such a variability requires the selection of at least one (minSelection) and at most three

(maxSelection) variants and it must be done at design time (bindingTime). In the case of the evolution of the AGM, this variability allows adding new variants (allowAddingVar). The ActivityPartition is tagged with variable according to guideline G.11 as it contains the variability record store.

Figure 2.

AGM saveGame() Method Activity Diagram.

Figure 3 presents the loadGame() method activity diagram. This feature can be triggered by the GamePlayer and GameInstaller actors represented by the ActivityPartition. A variation point is identied right after the action byteString = new String(rs.getRecord(i)); according to guideline G.8. Thus, it is possible to decide which actions must be executed. The three possible actions are tagged with (according to guideline G.10) as alternative OR a possible derived product might load more than one game. The DecisionNode path guard expressions decide which ow(s) must be followed according to guideline G.10. A variability named record load is associated with the DecisionNode. Such a variability requires the selection of at least one (minSelection) and at most three (maxSelection) variants and it must be done at design time (bindingTime). In the case of the evolution of the AGM, this variability allows adding new variants (allowAddingVar). The ActivityPartition is tagged with variable according to guideline G.11 as it contains the variability record load.

Figure 3.

AGM loadGame() Method Activity Diagram.

V. R ELATED W ORK The existing literature provides a set of relevant related works which allow us to perform an overall analysis. Robak et al. [14] propose the identication of variability in activity diagrams based on feature models with variability represented. Features are bound to representative methods or components of a PL. Each method/component is associated with an activity diagram in which variable actions

are tagged with variable . Moreover, each action is related to a corresponding feature. In the extended version of SMartyProle, each action can be a variant related to one or more variation points. The variants granularity is lower with relation to the strategy adopted by Robak et al. Therefore, it is possible to represent variations with lower granularity in an activity diagram, avoiding postponing them to components and their classes. Reuys et al. [12] present an approach for deriving test scenarios from activity diagrams. Most of testing strategies is based on concepts as multiple paths and using/denition. Such paths can be seen as activity diagram inherent variabilities, from which case tests are dened. Thus, Reuys et al. propose the use of the stereotype VP to represent a variation point in a DecisionNode. Actions that represent each variation point decision node path are tagged with variant . However, as discussed in previous works [3], [8], it is necessary to explicitly represent the kind of a variant (mandatory, optional, inclusive ou exclusive) in order to support the identication of the kind of variant-variation point relationship and guarantee the correct derivation of PL products. Therefore, SMartyProle by means of its abstract stereotype variant and its concrete stereotypes mandatory , optional , alternative OR , and alternative XOR contribute to make such a representation sharper. Ripon et al. [13], as Reuys et al. [12], propose the use of the stereotype variant in activity diagram actions. However, such an approach aims at generating test cases, thus, providing no details with regard to variability-related concepts. Shinieders [15] presents a variability mechanism-driven process for representing PL architecture. In such a process, macro-actions can be dened as variation points tagged with VarPoint . Internally, each macro-action is composed of various actions and the ow amongst action pins can be variable Variable . Such a representation approach is interesting. However, activity diagram with such a level of details were not identied in our SLR, thus, not yet taken into consideration by SMarty. Heuer et. al. [5] present syntax and semantic formal denitions for variabilities in activity diagrams based on Petri nets. These denitions contributed to extend SMarty by analyzing how DecisionNodes are seen whereas they encompass possible executable paths. Such paths allow the variability representation in a PL as multiple paths can coexist in a same product. Moreover, Heuer et al.s work indicates the need of adding formal expressions to the SMartyProle variability models as, for instance, using the Object Constraint Language (OCL). VI. C ONCLUSION AND F UTURE W ORK This paper proposed the extension of the SMarty approach for encompassing UML activity diagram models by

providing both new extended metaclasses support to the SMartyProle and new guidelines to the SMartyProcess. An example of the extended SMarty approach was applied to two main features of the AGM PL: save game and load game. The existing literature points out interesting related works, however none of them direct guided the SMarty extension strategy. Each of such works contributed in a specic basis, however several adjustments were done in order to make the extension as general as possible. The extended SMartyProle allows the application of its stereotypes to three metaclasses: DecisionNode, Action, and ActivityPartition. Variation points can be identied based on the proposed guideline G.8, which suggests the application of the stereotype variationPoint to DecisionNodes. Actions can be dened as variants according to guidelines G.9 and G.10, based on the concrete stereotypes mandatory , optional , alternative OR , and alternative XOR . Guideline G.11 suggests the application of the stereotype variable to ActivityPartitions that contain any type of internal variation. This paper is limited with relation to formal denitions of variabilities in activity diagrams. Instructions of OCL or another formal language must support the SMartyProle in order to guarantee the correct generation of PL products. Moreover, PL activity diagrams with more details must be used for validating the effectiveness of the extended SMarty. Directions for future works are as follows: (i) apply OCL to SMartyProle elements bringing out formalism to SMarty; (ii) analyze whether is possible to represent variability in pins and low granularity activity diagram elements; (iii) perform an experimental study for verifying the effectiveness of the extended SMarty; and (iv) investigate variability management in sequence diagrams as they are extremely rich in details and may contain essential variabilities for a PL. R EFERENCES
[1] J. Bosch, Preface, in Proc. Workshop on Software Variability Management: Software Product Families and Populations. Groningen, The Netherlands: University of Groningen, 2004, pp. 12. [2] A. Braganca and R. J. Machado, Extending UML 2.0 Metamodel for Complementary Usages of the extend Relationship within Use Case Variability Specication, in Proc. Software Product Lines Conf. Washington, DC, USA: IEEE Computer Society, 2006, pp. 123130. [3] L. Chen, M. A. Babar, and N. Ali, Variability Management in Software Product Lines: a Systematic Review, in Proc. Software Product Lines Conf. Pittsburgh, PA, USA: Carnegie Mellon University, 2009, pp. 8190. [4] H. Gomaa, Designing Software Product Lines with UML: from Use Cases to Pattern-based Software Architectures. Boston, MA, USA: Addison-Wesley, 2005.

[5] A. Heuer, C. J. Budnik, S. Konrad, K. Lauenroth, and K. Pohl, Formal Denition of Syntax and Semantics for Documenting Variability in Activity Diagrams, in Proc. Int. Conf. Software Product Lines. Berlin, Heidelberg: Springer-Verlag, 2010, pp. 6276. [6] B. Korherr and B. List, A UML 2 Prole for Variability Models and their Dependency to Business Processes, in Proc. Int. Conf. Database and Expert Systems Applications. Washington, DC, USA: IEEE Computer Society, 2007, pp. 829834. [7] F. J. v. d. Linden, K. Schmid, and E. Rommes, Software Product Lines in Action: The Best Industrial Practice in Product Line Engineering. Secaucus, NJ, USA: SpringerVerlag New York, Inc., 2007. [8] E. A. Oliveira Junior, I. M. S. Gimenes, and J. C. Maldonado, Systematic Management of Variability in UML-based Software Poduct Lines, Journal of Universal Computer Science, vol. 16, no. 17, pp. 23742393, 2010. [9] OMG, UML Specication - Superstructure v2.2, 2009. [Online]. Available: http://www.omg.org/cgi-bin/doc?formal/ 09-02-02 [10] D. Peixoto, V. Batista, A. Atayde, E. Borges, R. Resende, and C. P dua, A Comparison of BPMN and UML 2.0 Activity a Diagrams, in Proc. Simposio Brasileiro de Qualidade de Software, Florianopolis-SC, Brazil, 2008, pp. 114. [11] K. Pohl, G. B ckle, and F. J. v. d. Linden, Software Product o Line Engineering: Foundations, Principles, and Techniques. Secaucus, NJ, USA: Springer-Verlag, 2005. [12] A. Reuys, S. Reis, E. Kamsties, and K. Pohl, Derivation of Domain Test Scenarios from Activity Diagrams, in Proc. Int. Workshop on Product Line Engineering, 2003, pp. 17. [13] S. H. Ripon, K. H. Talukder, and M. K. I. Molla, Modeling Variability for System Families, Malaysian Journal of Computer Science, vol. 16, no. 1, pp. 3746, 2003. [14] S. Robak, B. Franczyk, and K. Poltitowicz, Extending the UML for Modeling Variability for System Families, Int. Journal of Applied Mathematics and Computer Science, vol. 12, no. 2, pp. 285298, 2002. [15] A. Schnieders, Variability Mechanism Centric Process Family Architectures, in Proc. IEEE Int. Symposium and Workshop on Engineering of Computer Based Systems. Washington, DC, USA: IEEE Computer Society, 2006, pp. 289298. [16] SEI, Arcade Game Maker Pedagogical Product Line, 2010. [Online]. Available: http://www.sei.cmu.edu/productlines/ppl [17] M. Svahnberg, J. v. Gurp, and J. Bosch, A Taxonomy of Variability Realization Techniques: Research Articles, Software Practice and Experience, vol. 35, no. 8, pp. 705 754, 2005. [18] T. Ziadi, L. H lou t, and J. M. J z quel, Towards a UML e e e e Prole for Software Product Lines, in Proc. Product Family Engineering, 2003, pp. 129139.