index.html

---
layout: default
title: Home
description: Simple documentation template for Github pages
permalink: /
---

<p> </p>

<div class="jumbotron">
  <!--<h1 class="display-4">Variability Modeling Language</h1>-->
  <p class="lead"><em>Variability Modeling DSL</em> (VM-DSL) focuses on abstracting the realized variability in the code assets of
    a variability-rich system</a>.
    It aims to capture and model the reusable structure of the code assets.
    The approach is based on abstracting the used variability implementation techniques coming
    from object-oriented or functional programming, such as inheritance, overloading, or software design patterns.
    <!--It is based on abstracting the used variability implementation techniques coming
    from object-oriented or functional programming, such as inheritance, overloading, or software design patterns.
    Thus, -->
    <!--instead of refactoring or annotating the code in terms of features, -->
    <!-- it captures and models the reusable
    structure of the code assets themselves. --> <!--, which can be traced to features. -->
  </p>
  
  <hr class="my-4">
  <p style="color: teal;"> VM-DSL emerged during the research work on <a href="https://en.wikipedia.org/wiki/Software_product_line">software product line engineering</a>, 
    specifically on understanding the variability implementation approaches of similar software-intensive systems.</p>
  <!--<p class="lead">
    <a class="btn btn-primary btn-lg" href="#" role="button">Learn more</a>
  </p>-->
</div>




<section class="bs-docs-section">
  <h1 id="overview" class="page-header">Overview</h1>

  Variability Modeling DSL (VM-DSL) is a domain specific language (DSL), realized in Scala language.
  <!--In the following, it will be referred as VM-DSL. -->
  Here are presented its main language constructs and an illustrative example of usage.

  <!--<blockquote>
    This is a Jekyll template I use for my GitHub projects documentations. It is heavily based on official Bootstrap
    documentation and is designed to be quickly deployed.
  </blockquote> -->
  <p></p>
  <h1 id="download" class="page-header">Availability</h1>
  <!--You can choose to take only the JAR of this language, and to use in your software product line.
  Or, to take its source, which comes with three illustrative software product lines. -->
    <p>The VM-DSL is available for download from <a href="https://github.com/ternava/Variability-CChecking">its Github repository</a>.  </p>
    <!--<p>You can download the VM-DSL in one of these two options. </p>
    <ul>
    <li>The JAR file: <a href="https://github.com/ternava/Variability-CChecking">DSL-variability-modeling_01.jar</a> </li>
    <li>The source with SPL examples: <a href="https://github.com/ternava/Variability-CChecking">DSL-variability-modeling_02.jar</a> </li>
  </ul>-->
  <p>* It is important to know that VM-DSL is an IntelliJ (2018.2.1)
    project. Therefore to use it easily you should install
    <a href="https://www.jetbrains.com/idea/download/#section=windows">IntelliJ</a>. </p>

  <h1 id="syntax" class="page-header">VM-DSL syntax</h1>
  <p>The detailed language syntax of VM-DSL is <a href="/syntax/">available</a>. It can be used to realize the VM-DSL using another programming language.</p>

  <p> </p>
  <hr class="my-4">

  <h1 id="usage" class="page-header">Usage</h1>

  <h3 class="page-header3">Language concepts</h3>

    By using the VM-DSL one can model the variability of code assets in a Java-based variability-rich system in terms of
    <code class="highlighter-blue">variation points</code> with
    <code class="highlighter-blue">variants</code> in a technical variability model
    <code class="highlighter-blue">tvm</code>. According to their definition:
   <ul>
       <li><code class="highlighter-blue">variation point</code>identifies one or more locations at which the variation will occur. </li>
       <li><code class="highlighter-blue">variants</code> express the way that a
           <code class="highlighter-blue">variation point</code> is going to vary.</li>
       <li><code class="highlighter-blue">tvm</code> stands for technical variability model, which consists of two parts:
         <ol type="1">
              <li>The captured abstractions of <code class="highlighter-blue">variation points</code> with
                <code class="highlighter-blue">variants</code>
                 that are associated with the variable elements in
                reusable code assets, and</li>
              <!--<li>The documented variability in a <code class="highlighter-purple">fragment</code> construct</li>-->
               <!--<li> the abstractions of <code class="highlighter-blue">variation point</code> with
                   <code class="highlighter-blue">variants</code>,</li>
               <li> their tags for keeping the consistency with the variable elements in code assets, and </li>-->
               <li> The described dependencies of <code class="highlighter-blue">variation points</code>
                   with <code class="highlighter-blue">variants</code> with their characteristic properties,
                   such as <code class="highlighter-purple">logical relation</code>,
                   <code class="highlighter-purple">binding time</code>,
                   and <code class="highlighter-purple">evolution</code> properties, using the
                 <code class="highlighter-red">fragment</code> construct.</li>
         </ol>
       </li>
   </ul>

  <h3 class="page-header3">Set up of VM-DSL</h3>

  <p>
    The VM-DSL can be used to model the variability of a variability-rich system implemented in Java or Scala languages.
    In the following is shown its usage for modeling the variability of an illustrative system implemented in Scala.
  </p>

  <p>To set up the VM-DSL</p>
  <ol>
    <li>Download the VM-DSL from <a href="https://github.com/ternava/Variability-CChecking">its repository</a> and add it in your project. </li>
      <!--<li>Add <a href="https://github.com/ternava/Variability-CChecking">DSL-variability-modeling_01.jar</a>
      to the dependencies of your SPL project, for example, in
      <a href="https://stackoverflow.com/questions/1051640/correct-way-to-add-external-jars-lib-jar-to-an-intellij-idea-project">IntelliJ</a> or
      <a href="https://stackoverflow.com/questions/3280353/how-to-import-a-jar-in-eclipse">Eclipse.</a></li> -->
    <li>Create a package named, for examle, <code>tvm</code> in your SPL project, which will hold the modeled variability.</li>
    <li>Then, for each subdomain of your choice, for example, for each package, you can create a new <em>tvm_x.scala</em> class to hold / model its variability.</li>
  </ol>

  <p>Or, alternatively to steps 2 and 3, the VM-DSL can just be imported into the current scope, for example, package,
    file, or class, where variability needs to be separately abstracted within a <code class="highlighter-blue">tvm</code>. </p>

  <h3 class="page-header3">Usage pattern</h3>
  <p>Here is a pattern for using the VM-DSL: </p>



  <!-- @formatter:off -->
  {% highlight scala %}
  /* tvm_x.scala */
  import dsl._
  import scala.reflect.runtime.universe._

  <vp_name>        := <vp_type>(<tag to the variable asset>)
  <variant_name>   := Variant(<tag to the variable asset>)

  import dsl.fragment._
  fragment(<class | file | package name>) {
      <vp_name> is <logical relation> with_variants (<list of variant_name(s)>)
      use <technique> with_binding <binding time> and_evolution <evolution>
  }
  {% endhighlight %}
  <!-- @formatter:on -->


          <!--<vp_type>                   := <VP | oVP | tVP |nVP>
          <tag to the variable asset> := asset(<class | method | field>)
          <vp_name> | <variant_name>  := String

          <logical relation> := <MND | OPT | ALT | MUL>
          <technique>        := <Inheritance | Overriding | ...>
          <binding time>     := <Compilation | Start up | Runtime | ...>
          <evolution>        := <Open | Close>-->

 <p><b>Line 1: </b> First, a <em>tvm_x.scala</em> class is created.</p>           
<p><b>Line 2: </b Then, in the <em>tvm_x.scala</em> class you need to import the VM-DSL. </p>
<p><b>Line 3: </b> The VM-DSL use the reflection in Scala to tag the variable assets in code, therefore you need to import Scala reflection too. 
  You may need to import also the subdomain, specifically the package, or class with variability (not shown here).</p>
<p><b>Lines 4 and 5: </b> You need to create variation points and variants, respectively. First, you define them, by giving a name, and then you specify their type.</p>
<p> The VM-DSL supports five types of variation points:</p>
<p><code class="highlighter-red">VP</code> &nbsp;&nbsp;- Ordinary variation point,
  <code class="highlighter-red">uVP</code> - Unimplemented variation point, 
  <code class="highlighter-red">oVP</code> - Optional variation point, 
  <code class="highlighter-red">tVP</code> - Technical variation point, 
  <code class="highlighter-red">nVP</code> - Nested variation point.
 </p>

 <p>For abstracting variants, the VM-DSL provides the <code class="highlighter-red">Variant</code> construct</b>.</p>

 <p>The VM-DSL has an <code>asset</code> construct where you can use the
  reflection in Scala to tag the variability related <code>class</code>, <code>method</code>, or <code>field</code> in code assets.</p>


  <p><b>Lines 6 to 10: </b> Then, you import and use the <code class="highlighter-red">fragment</code> construct to model the variability in terms
    of the defined abstractions of <code class="highlighter-blue">variation points</code> and
    <code class="highlighter-blue">variants</code>.</p> 
  
    <p>First, the logical relation among the variants of a variation point are modeled. 
      For this, there are available four logical relations among the variants of a variation point: </p>
      <p><code class="highlighter-red">mandatory</code>, 
        <code class="highlighter-red">optional</code>, 
        <code class="highlighter-red">alternative</code>, 
        <code class="highlighter-red">or</code>.
      </p>

    <p>Secondly is abstracted the used technique to implement a variation point with its variants.
      The current VM-DSL supports the five techniques (new techniques can be added and used too): </p>
    <p><code class="highlighter-red">inheritance</code>, 
      <code class="highlighter-red">overloading</code>, 
      <code class="highlighter-red">overriding</code>, 
      <code class="highlighter-red">strategy</code>,
      <code class="highlighter-red">template</code>.
    </p>  

    <p>Thirdly, depending from the used technique, during the product derivation, variants can be bound at different times. 
      The current VM-DSL supports two binding times:
    </p>
    <p><code class="highlighter-red">compile_time</code> and <code class="highlighter-red">runtime</code>.</p>

    <p>Finally, a variation point can be open for evolution in the future or not, which property comes from the used technique. 
      Therefore, VM-DSL has two possible evolution properties for a variation point: </p>
      <p><code class="highlighter-red">open</code> and <code class="highlighter-red">close</code>.</p>


      <p>These four steps are repeated for abstracting each variation point with its variants and modeling the variability of some code assets.</p>
    <h3 class="page-header3">Usage example</h3>

    <p>Here is an example of a variation point with three variants in code assets of a variability-rich system: </p>

  <!-- @formatter:off -->
  {% highlight scala %}
  /* Class level variation point, vp_AbsLine2D */
  public abstract class AbstractLine2D extends 
    AbstractSmoothCurve2D implements 
    SmoothOrientedCurve2D, 
    LinearElement2D {

      /* First variant of vp_distance */
      public double distance(Point2D p) {
        return distance(p.x(), p.y());
      }
      
      /* Second variant of vp_distance */
      public double distance(double x, double y) {
          Point2D proj = projectedPoint(x, y);
          if (contains(proj))
              return proj.distance(x, y);
          /* Omitted code */
          return dist;
      }
    /* Omitted code */
  }
  {% endhighlight %}
  <!-- @formatter:on -->

  <!-- @formatter:off -->
  {% highlight scala %}
  /* First variant, v_Line2D, of vp_AbsLine2D */
  public class StraightLine2D extends AbstractLine2D implements 
    SmoothContour2D, Cloneable, CircleLine2D {
	  /* Omitted code */
  }
  {% endhighlight %}
  <!-- @formatter:on -->

  <!-- @formatter:off -->
  {% highlight scala %}
  /* Second variant, v_Segment2D, of vp_AbsLine2D */
  public class LineSegment2D extends 
    AbstractLine2D implements Cloneable, CirculinearElement2D {
	  /* Omitted code */
  }
  {% endhighlight %}
  <!-- @formatter:on -->

  <!-- @formatter:off -->
  {% highlight scala %}
  /* Third variant, v_Ray2D, of vp_AbsLine2D */
  public class Ray2D extends AbstractLine2D implements Cloneable {
	  /* Omitted code */
  }
  {% endhighlight %}
  <!-- @formatter:on -->

  <p>The variability of these code assets is modeled as in the following:</p>

  <!-- @formatter:off -->
  {% highlight scala %}
  /* tvm_line.java*/
  package tvm  // For example, all TVMs are kept within a package
  import dsl._
  import scala.reflect.runtime.universe._
  
  val vp_AbsLine2D   = VP(asset(typeOf[AbstractLine2D].typeSymbol))
  val v_Line2D       = Variant(asset(typeOf[StraightLine2D].typeSymbol))
  val v_Segment2D    = Variant(asset(typeOf[LineSegment2D].typeSymbol))
  val v_Ray2D        = Variant(asset(typeOf[Ray2D].typeSymbol))  
  
  import fragment._
  fragment("geom2D.line") {
    vp_AbsLine2D is ALT with_variants (v_Line2D, v_Segment2D, v_Ray2D) use
    INHERITANCE with_binding RUN_TIME and_evolution OPEN
  }
  {% endhighlight %}
  <!-- @formatter:on -->
  
  </section>