Development of a Feature Modeling Tool using Microsoft DSL Tools.

Development of a Feature Modeling Tool using Microsoft DSL Tools. GIRO Technical Report 2009-1.ver 1.0 (05/01/2009) Rubén Fernández, Miguel A. Laguna, Jesús Requejo, Nuria Serrano. Department of Computer Science, University of Valladolid. Campus M. Delibes, 47011 Valladolid, Spain mlaguna@infor.uva.es {rubenkame, jesus.requejo, nuriaserrano}@gmail.com Abstract. Feature models are the basic instrument to analyze and configure the variability of product lines (PL). However, is quite difficult to find a tool that offers enough functionality to develop them and defining their feature models. For that reason, we have built a tool to define and configure the feature diagrams of a product line in order to get the architectural structure of specific products automatically using and MDE approach. Besides, we integrate this tool in the same IDE we will use later to implement the product line, so we concentrate all the phases of the software development process in the same tool. 1. Introduction The product lines approach can be quite complex because of the huge size of most of them. Besides, it is difficult to find a tool that offers enough functionality to develop a PL easily. For that reason, we are working on a tool that simplifies the management of product lines. We have defined our own domain specific language (DSL) to construct feature diagrams. Based on this DSL, we have built a tool that allows the user to represent and manage the variability of a product line. The original definition for features diagrams was FODA [6]. Feature Oriented Domain Analysis proposed features as the basis for analyzing and representing commonality and variability of applications in a domain. A feature represents a system characteristic realized by a software component. There are four types of features in feature modeling: Mandatory, Optional, Alternative, and Or groups of features. We also based our DSL in other feature diagram definitions such as FORM [7] and FeatuRSEB [3].

Previously we have manually developed some case studies of PL, however, the productivity (and the complexity in non-trivial product lines) requires the construction and derivation of the different models to be automated. Model Driven Engineering (MDE) is a recent paradigm that bases the software development in models and their transformation to code. The best known approach is Model Driven Architecture (MDA). MDA was introduced by the Object Management Group (OMG) and is based on the Platform Independent Model (PIM) concept, a specification of a system with independence of platforms (e.g..net, or J2EE) [8]. The PIM must be transformed into a Platform Specific Model (PSM) [9]. As the main strength of MDE paradigm is the manipulation of models, it is very convenient use its techniques to define the transformations between feature, goal, and UML models of a product line. This approach requires the establishment of precise rules, using meta-modeling and transformation tools. To establish these rules, the recurring patterns in the feature models must be discovered and correlated to UML structures, in this case UML packages. The connection of the feature model with the design of the solution or product line architecture is usually implemented by an object-oriented framework. This explicit connection allows the instantiation of the domain framework into each specific application to be automated. Figure 1 shows the relationship scheme between these models. To obtain the architectural models from the goal/feature models is not simple. The solution offered by most of the methods proposed in the literature is to register the traceability between features and standard models of UML. Fig. 1. Relationships between the product line models.

Using this approach we have developed a tool to automate these transformations from feature models to UML models using Microsoft DSL Tools, in order to integrate the most part of the development process of a PL into the same IDE, in this case Visual Studio 2008. DSL Tools is a specific tool integrated as an SDK in Visual Studio 2008 that provides the user a powerful tool to define domain specific languages. We used this tool to define our specific feature model language and build the tool that will be used to modeling our feature diagrams. The aim is to introduce product line as one of the project types provided by the development platform. The interface and underlining meta-model of the FMT is similar to the fmp eclipse plug-in [2] and compatible with it, allowing the direct import of fmp models. The advantages of this FMT are direct integration into the Visual Studio IDE and the possibility of visual representation and manipulation of features and mutex/require constraints. As additional benefits, the package structure of the product line and configuration files can be directly generated. The rest of the document is as follows: The next section explains what a feature model is, and gives and overview of the meta-model used to develop this tool. Section 3 describes the meta-model based patterns used to guide the transformation from the feature diagrams to UML package models. Section 4 shows the environment in which this tool has been built, DSL Tools. Section 5 presents the description of the developed tool. Section 6 refers some related tools and, finally, the Section 7 concludes the document and proposes future work. 2 Feature Diagrams Feature models represent the functional variability of a product line. They connect the goals with the UML models. A feature diagram describes all possible variability of a product line. With a configuration of this diagram we can obtain a definition of a specific product of the PL. There are several definitions of different types of feature diagram; we based our meta-model of feature diagrams in the next: Feature Oriented Domain Analysis [6] proposed features as the basis for analyzing and representing commonality and variability of applications in a domain. A feature represents a system characteristic realized by a software component. There are four types of features in feature modeling: Mandatory, Optional, and Alternative features. Posterior proposals included Or groups of features and cardinality aspects. Besides, it has a textual form to describe constraints. These constraints can be of two different types: require and mutex. Later, Kang et al. have proposed the Feature-Oriented Reuse Method (FORM) [7] as an extension of FODA. Their main motivation was to enlarge the scope of feature modeling. They argue that feature modeling is not only relevant for requirements engineering but also for software design. In terms of feature diagrams, several changes occurred but there is only one change that is relevant for us: feature diagrams

are single-rooted directed acyclic graphs (DAG) instead of simple trees and feature names appear in boxes. The FeatuRSEB method [3] is a combination of FODA and the Reuse-Driven Software Engineering Business (RSEB) method. RSEB is a use-case driven systematic reuse process, where variability is captured by structuring use cases and object models with variation points and variants, FeatuRSEB feature diagrams have the following characteristics: 1. They are DAGs, not only trees. 2. Decomposition operator or is added to xor and and. Features whose sons are decomposed through or or xor are called variation points and those sons are called variants. 3. They have a graphical representation (dashed arrows) for the constraints requires and mutex. So, we based our meta-model on these proposals, and we finally have the next elements: Mandatory features: are present in a concept instance if their parent is present. They are shown by a filled circle at the end of the edge. Optional features: may be present only if their parent is present. They are shown by an empty circle at the end of the edge. Alternative features: are a set of features from which one is present if their parent is present. They are shown by an arc grouping their edges. Or groups of features: are a set of features from which a subset of them are present if their parent is present. They are shown by a filled arc grouping their edges. Mutex and requires. These relationships can only exist between features. Requires operator means that when we select a feature the required featured must be selected too. Then mutex operator means that once we choose a feature the other feature must be excluded. Cardinality of the edges shows the number of features that must be selected. This cardinality is represented by a minimum and maximum number between []. For example, [1..3] cardinality means that at least one feature and no more than three features can be selected in a or group of features. After an evaluation of various alternatives, the meta-model proposed by Czarnecki et al. in [1] has been selected because the simplicity of the related transformation. In this

approach, the distinctive property of the relationships is the cardinality. Figure 2 shows a simple example of that kind of diagrams. Payment Registered Guest 1..3 PaymentType CreditCard DebitCard ElectronicCheque Fig. 2 Example of a simple feature diagram Figure 3 shows the above-mentioned meta-model. In that meta-model, the relationships are implicit and the source of the transformation must be the cardinality attribute of the features and group of features. Fig. 3 Feature simplified meta-model, adapted from Czarnecki et al. [7]

3 From Feature Model to Architectural Model and Code We have discussed in our previous work the advantages and disadvantages of many approaches and proposed to separate completely the representation of variability of the product line from the residual variability of the concrete applications [4]. We use for this the UML package merge mechanism. The package merge mechanism basically consists of adding details to the models in an incremental way. According to the specification of UML 2, <<merge>> is defined as a relationship between two packages that indicates that the contents of both are combined. It is very similar to the generalization and is used when elements in different packages have the same name and represent the same concept, beginning with a common base. The concept is extended incrementally in each separate package. Selecting the desired packages, it is possible to obtain a tailored definition from all the possible ones. Though the examples in UML focus on class diagrams, the mechanism can be extended to any UML model, in particular use cases and sequence diagrams. This mechanism allows a clear traceability between feature and UML models to be established. Each optional feature is described by an optional package of the product line that will be selected or not in function of the concrete configuration of features. The process consists of establishing for each UML model, a base package that embodies the common part of the product line. Then, associated to each optional feature, a new package is built, so that all the necessary changes in the model remain located. This package is connected through the <<merge>> relationship with its base package in the exact point of the package hierarchy. The sense of the relationship expresses the dependence between packages: the base or merged package can always be included in a specific product, the receiving package is an extension of the base package and can only be included if the base package is also selected. This is exactly the way the expert decides which features are included or not during the configuration process, and must be directly reflected in the configuration of packages. In the example of Figure 9, obtained directly from the specification UML 2, the package S includes the classes, C, D, and B, with the peculiarity that A is a specialization of S::D and also includes the details of Q::A. Evidently, the rules that establish the specification of UML 2 are strict in order to avoid inconsistencies. For example, cycles are not allowed, the resulting multiplicity ranges are the least restrictive possible, the operations should conform in number, order and type of parameters, etc. The concepts that UML 2 uses are basically: Merged package (first operand), receiving package (second operand) and resulting package (contains the results of the merge and is the same package as the receiving package after the merge has been performed). Merged element, receiving element and resulting element (element in the resulting package after the merge is performed or unchanged element that have no matching)

This mechanism allows a clear traceability between feature and UML models to be established. The application of this mechanism to our problem consists of establishing for each UML model, a base package that embodies the common part of the product line. This base package can be organized in the ordinary way (using recursive package composition and <<import>> or<<access>> relationships). Then, associated to each optional feature, a new package is built, so that all the necessary changes in the model remain located, fulfilling one of the requirements of the previous Section. This package is connected through the<<merge>> relationship with its base package in the exact point of the package hierarchy. The sense of the relationship expresses the dependence between packages: the base or merged package can always be included in a specific product, the receiving package is an extension of the base package and can only be included if the base package is also selected. This is exactly the way the expert decides which features are included or not during the configuration process, and must be directly reflected in the configuration of packages. Fig. 9 Example of the package merge mechanism [5] Even, if it were possible to extend the traceability towards the implementation model using partial classes. In our development process we use the related concept of partial class of C# to implement the product lines. In C# it is possible to split the definition of a class or interface over two or more source files. Each source file contains a section of the class definition, and all parts are combined when the application is compiled to form the final type. The approach that uses C# allows a project (or a solution in Microsoft Visual Studio terminology) to be organized in packages with partial classes. So, if the framework that implements the product line is organized in packages with partial classes (base and variants), for deriving a given specific application, it is enough to import/ reference the packages

4 DSL Tools DSL tools is a Microsoft tool integrated in Visual Studio SDK 2008 that allows the user define their own domain specific language. A domain-specific language is used to perform a specific task in a given problem domain. This makes it different from a general-purpose language. By using Domain- Specific Language Tools, you can build customized modeling tools. You can define a modeling language and implement it in a straightforward way. For example, a user of DSL tools can create a specialized language that describes a user interface, a business process, a database, or in our case, feature diagrams. Next, the code can be generated from those descriptions. You can use Domain-Specific Language Tools to generate visual designers that are customized for your problem domain. For example, you can create a tool to describe concepts that are specific to how your organization models business processes. By creating your own domain-specific language and custom-generated designer, you can specify exactly what state chart concepts you need in your tool. That makes DSL Tools a very interesting tool to design our own language for feature diagrams and develop a CASE tool to build this diagrams as is shown in the next section. Figure 4 shows a simple example of how a meta-model for a domain specific language can be defined used DSL tools. We have to define each domain class and their relationships with the other classes. We also have to describe the attributes of these classes and the multiplicity of their relationships. Fig. 4 Example of a DSL definition

The next figure presents a DSL cycle life. In the first place we have the definition of the DSL made by the DSL designer using DSL tools by giving a graphical description of the meta-model. In the next step, the DSL has been created and DSL tool has created the CASE tool in order to the DSL user can make their diagrams. Fig. 5 DSL Cycle life 5 Feature Modeling Tool In order to build our tool we have first to give a definition of our DSL using Microsoft DSL Tools. DSL tools allow the user to enter this definition in a graphical way as has been described in the previous section. Figure 6 shows the above-mentioned definition. The left part of the figure presents the definition of the meta-model. The right part of the figure shows the properties of the shapes and graphical representation of the future diagrams. At first, we have to declare that a feature model has always a root feature. That is the meaning of the first relationship shown in the figure below. A feature can have a lot of different kinds of relationships: A feature can have another feature or group feature, or can include or exclude some other features. We have to declare as well the relationships that a group feature can have. In this case a feature group can have some features. Finally, we have to describe what a node is. A node can be a feature or a feature group for that reason we define it using inheritance.

Fig. 6 DSL definition for our feature modeling language (1 of 2) Once we have finished the definition of our DSL, compiling the project solution, DSL Tools can create a tool similar to a CASE Tool in order to we can design our models using the meta-model defined previously. Figure 8 shows the main window of the tool.

Fig. 7 DSL definition for our feature modeling language (2 of 2).

Fig. 8 Main window of the feature modeling tool The tool is divided into three sections. The central window is the model designer, in that part we can create our feature diagrams according to with the rules defined previously. The left part is the model configurator. In that section we have the same information that appears in the designed diagram. From this window we can select the features we want to appear in the future specific product of our product line. If we want to select a feature we have to check the corresponding cell. The changes will propagate automatically to the diagram and the model configurator. The tool checks the multiplicity and the constraints of the features as well. At last, in the third section located in the right part of the window we have the configured project. In that window we can see the transformation into package model of our configuration of the feature model. For each feature in the model will create a package. If we select a feature in the model configurator, its correspondent package will we marked as selected automatically in the configured project window as is shown in the feature, selected package are shown in yellow and will be include in the solution of the project while not selected packages are in white and will be excluded from the solution.

In the bottom of the tools there is a button called Export to XMI. Pressing that button we can obtain a file with an XMI description of the package model corresponding to the feature model configuration. We can export that XMI file to a CASE tool obtaining a UML package model. One of the advantages of this FMT is direct integration into the Visual Studio IDE and the possibility of visual representation and manipulation of features and mutex/require constraints. That is a great advantage because in other tools, such as fmp, the declaration of mutex/require constraints must be done using a constraint language like OCL. As additional benefits, the package structure of the product line and configuration files can be directly generated. In that first version of the tool, we are only considering transform the feature model into empty package with their merge relationship as is explained in the third section. 6 Related Work The Eclipse platform provides some similar tools to the now implemented by us, such as the fmp plug-in of Czarnecki et al. [2], that we used formerly to manage the configure product lines. The main problem is that the C# Eclipse environments provide fewer possibilities than those offered by the Microsoft platform and standard Java language has not the partial class mechanism we use to implement the features at code level. The Covamof approach [11] is a variability modeling approach that uniformly models the variability of the software product family in all abstraction layers. It treats variation points and dependencies as first-class citizens and provides means to model the relations between simple and complex dependencies. A completely different approach, focused on implementation instead of requirements or design, is the Feature Oriented Programming (FOP) paradigm the optional features are implemented as increments (refinements) in a java-like language. Starting from a base class, these increments are combined using a set of tools, provided with the AHEAD1 tool suite. AHEAD (Algebraic Hierarchical Equations for Application Design) is a basis for large-scale compositional programming. Features are the building blocks of systems; they are incremental units of program functionality that encapsulate "crosscuts" or fragments of many classes. Feature modules are similar to object-oriented frameworks in that they extend well-known methods of existing classes. Unlike aspects of aspect oriented programming (AOP), there is no quantification other than that used in traditional object-oriented design. The advance of AHEAD is scalability: both code and non-code representations of programs can be synthesized using algebraic models. Further, systems can be suites of different programs; such systems can also be synthesized in AHEAD

Other commercial tools, such as Big-Lever Gears or pure variants offer similar functionalities. Though these solutions are valid, the learning of new modeling or implementation techniques and the need of specialized CASE and IDE tools represent barriers for the adoption of the approach of product lines in many organizations; we therefore believe that the solution presented here improves the above mentioned proposals. 7 Conclusions and Future Work We have developed a CASE tool to design and manage the variability of product lines using feature modeling and integrated it into Visual Studio, using the Microsoft DSL tools. The advantages of that feature modeling tool are direct integration into the Visual Studio IDE and the possibility of visual representation and manipulation of features and mutex/require constraints. As additional benefits, the package structure of the product line and configuration files can be directly generated. The interface and underlining meta-model of the FMT is similar to the fmp eclipse plug-in [2] and compatible with it, allowing the direct import of fmp models. We can obtain a file with an XMI description of the package model corresponding to the feature model configuration. We can export that XMI file to a CASE tool obtaining a UML package model. In the first version of our tool we have only considered the transformation of feature models into UML package models, where these packages are empty. We are working on adding the transformations of features to classes and their attributes and even to use case diagrams inside the components of the package model in order to get a more complete and useful design model. 8 References [1] K. Czarnecki, S. Helsen, and U. Eisenecker. Staged Configuration Through Specialization Multi-Level Configuration of Feature Models. Software Process Improvement and Practice, special issue on "Software Variability: Process and Management, 10(2), 2005, pp. 143-169 [2] K. Czarnecki, S. Helsen, U. Eisenecker, Formalizing cardinality- based feature models and their specialization, In Software Process Improvement and Practice, Vol. 10, No. 1, 2005, pp.7-29. [3] Griss, M.L., Favaro, J., d'alessandro, M., "Integrating feature modeling with the RSEB", Proceedings of the Fifth International Conference on Software Reuse, p.76-85., 1998

[4] Miguel A.Laguna, Bruno González-Baixauli, José Manuel Marqués, Seamless Development of Software Product Lines: Feature Models to UML Traceability. Sixth International Conference on Generative Programming and Component Engineering (GPCE 07). Salzburg, Austria - oct 2007 [5] Miguel A. Laguna, Bruno González-Baixauli, and José M. Marqués. Feature Patterns and Multi-Paradigm Variability Models (GIRO Technical Report 2008/01-v0.9) University of Valladolid. Spain [6] Kang, K. C., S. Cohen, J. Hess, W. Nowak, and S. Peterson. Feature-Oriented Domain Análisis (FODA) Feasibility Study. Technical Report, CMU/SEI-90-TR-21, Software Engineering Institute (Carnegie Mellon), Pittsburgh, PA 15213 [7] Kang, K. C., Kim, S., Lee, J. y Kim, K. FORM: A Feature-Oriented Reuse Method with Domain-Specific Reference Architectures. Annals of Software Engineering, 5:143-168. 1998. [8] Object Management Group, MDA Guide Version 1.0, 2003 [9] Object Management OMG. Unified modeling language specification version 2.0: Infrastructure. Technical Report ptc/03-09-15, OMG, 2003. [10] Schobbens, P., Heymans, P., Trigaux, J., and Bontemps, Y. 2007. Generic semantics of feature diagrams. Comput. Netw. 51, 2, 456-479. Feb. 2007. [11] Marco Sinnema, Sybren Deelstra, Jos Nijhuis, Jan Bosch COVAMOF: A Framework for Modeling Variability in Software Product Families. Department of Mathematics and Computing Science, University of Groningen, PO Box 800, 9700 AV Groningen, The Netherlands.