usecases/variability/index.php

<?php  																														require_once($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/app.class.php");	require_once($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/nav.class.php"); 	require_once($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/menu.class.php"); 	$App 	= new App();	$Nav	= new Nav();	$Menu 	= new Menu();		include($App->getProjectCommon());    # All on the same line to unclutter the user's desktop'

	#*****************************************************************************
	#
	# template.php
	#
	# Author: 		Freddy Allilaire
	# Date:			2005-12-07
	#
	# Description: Type your page comments here - these are not sent to the browser
	#
	#
	#****************************************************************************

	#
	# Begin: page-specific settings.  Change these.
	$pageTitle 		= "AMW Use Case - Variability Management in a Model-Driven Software Product Line";
	$pageKeywords	= "Software product line, MTTL, Variability, Feature model, Model weaving";
	$pageAuthor		= "Kelly Garcés";

	# End: page-specific settings
	#

	# Paste your HTML content between the EOHTML markers!
	$html = <<<EOHTML

	<!-- Main part -->
	<div id="midcolumn">
		<h1><font color='#280882'>AMW</font> Use Case - Variability Management in a Model-Driven Software Product Line<br/></h1>

		<a name="goals"></a>
		<img align="right" src="../../resources/amwLogoSmall.png" valign="top" style="padding-left: 10px;" alt="AMW Logo" />
		<blockquote>
			<ul>
				<li><a href="#overview"><b>Overview</b></a></li>
				<li><a href="#download"><b>Download and examples</b></a></li>
				<!--<li><a href="#acknowledgement"><b>Acknowledgements</b></a></li>				-->
				<li><a href="#reference"><b>References</b></a></li>

			</ul>
		</blockquote>

		<hr class="clearer" />

		<table>
			<COLGROUP>
				<COL width="2%">
				<COL width="98%">
		<tr>
			<td>
			</td>

				This use case illustrates an approach to manage variability during the SPLs construction process, using a MD-SPL approach.
				The approach was developed by the <a href="http://agamenon.uniandes.edu.co/~csw">Software Construction Group</a> of The University of Los Andes (Colombia).
		
		<h4 STYLE="font-size: 10pt; padding: 0; border-bottom: 2px solid #49457C; background-position: top left; background-repeat; repeat-x;">

		<a name="overview">Overview</a></h4>

		Software industry have been evolving from hand-craft process to semi-automatic process to improve productivity and quality.
		An approach to achieve this goal is the reuse. Software Product Line (SPL) is an approach to develop software products by reusing
		sets of components called core assets. On the other hand, Model Driven Architecture (MDA) [1] is an approach of generative
		reusability. Results of recent investigations have shown how the mixture of MDA and SPLs (MD-SPL) is an approach that makes
		possible the definition of a SPLs creation process [2, 3].

		In [4], we present a proposal to manage variability during the SPLs construction process, using a MD-SPL approach.
		For this, we separated the concepts related to a product line in different domains: (1) the business logic domain,
		(2) the architecture domain, and (3) the technological platform domain. We created metamodels, feature models, weaving models,
		and transformation rules as core assets. This scheme enables us to transform one initial source model into different (variable) target
		models for obtaining variable SPL members. In order to generate variable target models, we created three types of transformation rules:
		(1) base rules, (2) control rules, and (3) specific rules. We exemplify this proposal with a SPL for the Cupi2 project [5].
		For the construction process we used GMF [6] like modelling  environment, AMW [7] to make weaving models,
		ATL [8] to transform model-to-model and Acceleo [9] to transform model-to-code.

		This use case illustrates our proposal. First, we introduce an application context. Later, we summarizes our approach to manage variability
		using MD-SPL.

		<h3>Application context</h3>

		We created a SPL for the Cupi2 project [5]. Cupi2 is part of a series of efforts from the Software Construction Group of The University of Los Andes
		(Colombia) to find new ways to teach/learn computer programming. In Cupi2, complete examples and exercises are used to illustrate
		different topics. Each example/exercise includes a graphical interface, a set of requirements, a set of unit tests, java code,
		and documentation. There are 18 levels in total. Each level adds new concepts to the previous ones. We build a SPL which generates examples for level 7.
		In this level, among other topics, we deal with ordering and searching algorithms in collections.

		Cupi2 examples share commonality and variability. All Cupi2 examples are stand-alone applications without complex non-functional requirements;
	    they are developed using the same technological platform, in this case Java. All the examples are structured by two components:
	    the kernel and the user interface. The kernel component implements the concepts of business logic. The user interface component implements
	    information visualization and interaction between users and kernel components.  Structures of aggregation can represent the kernel concepts and
		their relationships. In an aggregation structure, there is always a main element that groups the other elements of the kernel.  For example,
	    in the Music Store application, a MusicStore assembles a set of Discs and each Disc assembles a set of Songs. To build a graphical user interface (GUI),
	    Cupi2 applications employ a set of elements like panels, lists, labels, images, and radio buttons, among others. The GUI elements can be grouped in
	    views of different types (main view, extension view, set view, search view, information view, and aggregation view).
	    In Figure 1, we present a possible GUI configuration with four different types of views.

		<p align="center">
				 <img src="resources/cupi2_gui.png"/>
	  			<br /><br />
				<b>Figure 1. Cupi2 example GUI</b>
		</p>

		<h3>The Variability Management Approach</h3>

		Now we present briefly our approach using the application context. We separate concepts related to a SPL in domains to manage variability.
		These domains are the business logic, the architecture domain, and the technological platform domain. Our strategy follows the MDA approach
		and it is based on the automatic transformation of models until obtaining executable applications. We start from a business logic model,
		we transform it into an architectural model, after that we transform it into a technological platform model and finally we generate source
		code from it. Before each transformation is done, the user selects the features that he wants. To achieve this, we build (1) metamodels for each domain,
	    (2) feature models for each target domain, (3) weaving models and transformations.

		<h4>Metamodels</h4>

		We define three different metamodels as core assets for Cupi2 applications: business logic, architecture, and technological platform metamodel.
	    Business logic metamodel includes the essential concepts of the problem; architecture metamodel  the concepts related to the graphic user interface;
	    finally, the technological platform metamodel includes Java concepts. For the last one, we created a simplified Java metamodel.

	    <h4>Feature model</h4>

	    Feature models are a standard de facto used to represent common and different characteristics of members from a product line [10].
	    The features can be mandatory, optional, or alternative. In our approach, feature models describe common and different characteristics of applications
	    in target domains. Cupi2 SPL has two target domains: architecture and technological domain. We develop a feature model for each of them.
		Figure 2 presents a subset of features for the architecture and technological  domain. For instance, Architecture feature model describes
		MainView is mandatory feature and InformationView, SetView and AddView are optional. Java feature model describes items are grouped using
		JCombobox or JList.

	    <p align="center">
				 <img src="resources/cupi2_features.png"/>
	  			<br /><br />
				<b>Figure 2. Cupi2 feature models</b>
		</p>

	    <h4>Weaving models and transformations</h4>

		User selects the features that he wants before the execution of each transformation. He makes the selection by associating (source) model
		elements and (target) features. We use a weaving model to create the associations. Figure 3 shows links between business model
		elements and architecture features. For instance, one link associates Disc element and SetView feature. It generates a SetView which groups
		discs by using a list. Another link associates MusicStore element and Serialization feature.

	    <p align="center">
				 <img src="resources/cupi2_weaving.png"/>
	  			<br /><br />
				<b>Figure 3. Weaving model between business model and architecture features</b>
		</p>

		After the weaving process, a transformation is executed. A transformation has two inputs (source model and weaving model) and one output
		(target model). Transformation applies base, control, or specific rules. We create base rules for the metamodel concepts that have to be always
		transformed into the same target feature. We create control and specific rules for  the metamodel concepts that can be transformed into
		different (variable) target features. We implement the base rules using declarative programming, and the specific rules using imperative
		programming. The control rules are implemented in a mixed way, it means, they have a declarative section and an imperative one.
		Listing 1 presents an example for each type of rule. The mainView is a base rule. The setView, in line 7, is a control rule. The declarative section
		is in the lines 8 to 13 and the imperative section is in the lines 14-16. The setView rule searches in the weaving model the elements that have the
		feature SetView associated (line 9). For those elements, a View is created (line 13) and the addComponent imperative rule is called (line 15).
		The addComponent rule creates concepts associated to the created View giving the characteristics needed for a SetView.

		 <p align="center">
				 <img src="resources/cupi2_rules.png"/>
	  			<br /><br />
				<b>Listing 1. Base, control, and specific transformation rules</b>
		</p>

		Then all model-to-model transformations are executed. We apply a model-to-code transformation to obtain the source code. Finally,
		we manually complete the applications.

		<h4 STYLE="font-size: 10pt; padding: 0; border-bottom: 2px solid #49457C;
							background-position: top left; background-repeat; repeat-x;">
		<a name="download">Download and examples</a></h4>

		<table>
			<COLGROUP>
				<COL width="25%">
				<COL width="75%">

		<tr>
		<td align="center">
			<a href="VariabilityManagementMDSPL.pdf"><h3>Publication</h3></a>
		</td>
		<td>
			The publication titled "Variability Management in a Model-Driven Software Product Line" presents our approach in more details.
			<p/>
		</td>
		</tr>

		<tr>
		<td align="center">
			<a href="../../examples/variability/cupi2MDSPL.zip"><h3>Example</h3></a>
		</td>
		<td>
			This example is the complete scenario to generate Cupi2 examples.
			<p/>
		</td>
		</tr>

		<tr>
		<td align="center">
			<a href="Cupi2MDSPLUserGuide.pdf"><h3>Example User Guide</h3></a>
		</td>
		<td>
			This document explains how to generate a specific Cupi2 example.
			<p/>
		</td>
		</tr>

		</table>

		<p/>
	<h4 STYLE="font-size: 10pt; padding: 0; border-bottom: 2px solid #49457C; background-position: top left; background-repeat; repeat-x;">
			<a name="reference"></a>References
		</h4>

		[1] J. Mukerji, and J. Miller, "MDA Guide," 2003. <br/>

		[2] J. Estublier, and G. Vega, "Reuse and variability in large software applications" in 13th ACM SIGSOFT Lisbon, Portugal 2005.<br/>

		[3] A. L. Santos, A. Lopes, and K. Koskimies, "An MDA Approach to Variability Management in Product-Line Engineering ".<br/>

		[4] K. Garcés, C. Parra, H. Arboleda, A. Yie, and R. Casallas, "Variability Management in a Model-Driven
			Software Product Line" in Proceedings of the Congreso Colombiano de Computación, Bogotá, Colombia 2007.<br/>

		[5] "Proyecto CUPI2" Access 2007; [Online]. Available: http://cupi2.uniandes.edu.co.<br/>

		[6] "Graphical Modeling Framework " Access 2006; [Online]. Available: http://www.eclipse.org/gmf/.<br/>

		[7] "AMW Home Page" Access 2006; [Online]. Available: http://www.eclipse.org/gmt/amw/.<br/>

		[8] "ATL Home Page"  Access 2006; [Online]. Available: http://www.eclipse.org/gmt/atl/.<br/>

		[9] "Acceleo" Access 2006; [Online]. Available: http://www.acceleo.org.<br/>

		[10] K. Kang, S. Cohen, J. Hess et al., Feature-Oriented Domain Analysis (FODA) Feasibility Study, Software Engineering Institute,
			 Carnegie Mellon University, Pittsburgh, Estados Unidos 1990.<br/>

<p/>
	</div><p/>
	<div id="rightcolumn">
		<div class="sideitem">
			<h6>General Information</h6>
			<ul>
				<li style="list-style:none">August 2007</li>
				<li style="list-style:none">By <a href="mailto://kellygarce@gmail.com">Kelly Garcés</a> (Software Construction Group)</li>
			</ul>
		</div>
	</div>


EOHTML;


	# Generate the web page
	$App->generatePage($theme, $Menu, $Nav, $pageAuthor, $pageKeywords, $pageTitle, $html);
?>