Loading presentation...

Present Remotely

Send the link below via email or IM


Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.


Feature Model Driven Generation of Software Artifacts

WAPL 2015 @ FedCSIS 2015, https://www.fedcsis.org/2015/wapl/

Valentino Vranić

on 22 September 2015

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Feature Model Driven Generation of Software Artifacts

Feature Model Driven Generation of Software Artifacts
Institute of Informatics and Software Engineering
> Feature model driven generation of software artifacts

> Besides an enhanced feature model, no other models are necessary

> Transformations are not limited in affecting the software system

> The concept of metatransformations: modify the common transformations prior to their execution

> Challenges: comprehensibility and maintainability, non-exclusive application, complex feature models, practical adoption, and changes as transformations

Roman Táborský and Valentino Vranić
crudecrude@gmail.com vranic@stuba.sk
WAPL 2015 @ FedCSIS 2015
Łódź, September 13, 2015

Feature Modeling
> A feature model defines variants in a structured way
> Domain engineering / software product lines
> Configurability first; appropriate implementation mechanisms selected accordingly
> Need not necessarily involve
academic feature modeling notation
A. Hubaux, A. Classen, M. Mendonca, and P. Heymans: A Preliminary Review on the Application of Feature Diagrams in Practice, VaMoS 2010
> A simple FODA-like style used here
> Abstracting from advanced concepts like binding time, additional constraints among features, feature cardinality...
> Features sometimes can be implemented as well localized components

> But often the realization of one feature is spread over several components

> Sometimes this involves crosscutting: a case for aspect-oriented programming
But how exactly to implement features?
What are they in code?
> Our idea: make each feature's realization a transformation

> Selecting a feature activates the corresponding transformation

> A transformation can affect all code, including the other transformations

> Virtually, this is a distributed generator embedded into a feature model

> The actual generator is then simple and generic

> This raises a number of issues...
> A simple conditional compilation can cope with this, but the code of crosscutting features would be scattered

> Generative approaches rely on the set of selected features to generate highly specialized code

> Generators can be external, but also metaprogramming based

> In either case, features are understood as the structure and behavior to be added, adapted, or removed
> Metatransformations
> Complexity of transformations
> Where to keep the transformations?

> One way is to attach them directly to the feature model that may conveniently be kept in the XML format
<?xml version="1.0" encoding="utf-8" ?>
<feature name="SimpleWeb" ID="1" Transformation="org.crd.dp.CaseStudy.SimpleWebFinal,org.crd.dp.CaseStudy.SimpleWebFinal.Transformations.CreateFolder" FolderName="Site" >
<feature name="StaticContent-History" ID="2" Transformation="org.crd.dp.CaseStudy.SimpleWebFinal,org.crd.dp.CaseStudy.SimpleWebFinal.Transformations.CreateStaticHTMLPage" htmlContent="&lt;h1&gt;History&lt;/h1&gt;&lt;p&gt;Lorem Ipsum&lt;/p&gt;" htmlTitle="StaticPage- History" PageName="Site\\History.html" />
<feature name="ContactPage" ID="3"
street="Ulica 29. Augusta 4" city="Bratislava" Folder="Site"/>

<feature name="DynamicContent-AccessLog" ID="4" Transformation="org.crd.dp.CaseStudy.SimpleWebFinal,org.crd.dp.CaseStudy.SimpleWebFinal.Transformations.DynamicContent" htmlTitle="Dynamic page - Access log" PageName="Site\\log.html"/>
<feature name="DynamicContentProvider" ID="5" Transformation="org.crd.dp.CaseStudy.SimpleWebFinal,org.crd.dp.CaseStudy.SimpleWebFinal.Transformations.Empty" >
<feature name="ASP.Net" ID="7" Transformation="org.crd.dp.CaseStudy.SimpleWebFinal,org.crd.dp.CaseStudy.SimpleWebFinal.Transformations.ASP" />
<feature name="DatabaseBackend" ID="6" Transformation="org.crd.dp.CaseStudy.SimpleWebFinal,org.crd.dp.CaseStudy.SimpleWebFinal.Transformations.Empty" >
<feature name="MSSQL" ID="8" Transformation="org.crd.dp.CaseStudy.SimpleWebFinal,org.crd.dp.CaseStudy.SimpleWebFinal.Transformations.MSSQL" />
<feature name="XML" ID="9" Transformation="org.crd.dp.CaseStudy.SimpleWebFinal,org.crd.dp.CaseStudy.SimpleWebFinal.Transformations.XML" />
<feature name="MicroformatSupport" ID="10" Transformation="org.crd.dp.CaseStudy.SimpleWebFinal,org.crd.dp.CaseStudy.SimpleWebFinal.Transformations.MicroformatSupport"/>
<feature name="CustomHTMLHeader" ID="11" Transformation="org.crd.dp.CaseStudy.SimpleWebFinal,org.crd.dp.CaseStudy.SimpleWebFinal.Transformations.CustomHtmlHeaders"/>
<feature name="GeneratorDoc" ID="12" Transformation="org.crd.dp.CaseStudy.SimpleWebFinal,org.crd.dp.CaseStudy.SimpleWebFinal.Transformations.MetaDoc" />

<!-- Transformation information including
the event chain, metatransformation
information, requirements, etc. -->
> Another way is to keep only references to transformations in the feature model (this is what we did)

> The actual code of the transformations is in the corresponding files
> Parse the feature model configuration from the XML file

> Parse and execute the metatransformations contained within the transformations from the XML file

> Check the requirements of the parsed transformations

> Execute the transformations

> In the end, transformations are objects that share a common interface
public interface ITransformation {

> The generator takes these objects and executes the corresponding methods

> The transformations have to be executed in the right order: can be adjusted using the priority attribute

> Digression:

Transformations as changes

> Aspect-oriented change realization
> Assess the comprehensibility and maintainability of a software system expressed by a number of transformations: does this preserve the intent?

> Explore a non-exclusive application of the approach in which only some features would be realized as transformations

> How to deal with complex feature models consisting of several separate feature diagrams with references between them

> Foster the practical adoption of the approach by providing directly reusable transformations, transformation templates, and transformation schemes or examples

V. Vranić. Aspect-Oriented Change Realization. Habilitation thesis, Slovak University of Technology in Bratislava, April 2010. http://fiit.sk/~vranic/pub/AOCR.pdf
Full transcript