II Taller sobre Desarrollo de Software Dirigido por Modelos, MDA y Aplicaciones (DSDM'05) MDA e Ingeniería de Requisitos para Líneas de Producto Bruno

II Taller sobre Desarrollo de Software Dirigido por Modelos, MDA y Aplicaciones (DSDM'05)

MDA e Ingeniería de Requisitos para Líneas de

Producto

Bruno González-Baixauli

Miguel A. Laguna

12 de Septiembre de 2005 Page 2

Index

Introduction

MDA & Product Lines

Support

Conclusions


Index

IntroductionProduct Lines (PL)

Process – PL Requirements Engineering (RE)

PL Models

MDA

MDA & Product Lines

Support

Conclusions


Product Lines (PL)

Reuse ApproachMore successful

Coarse-grained components

Top-down systematic approach

High effort & complex

Lack of process definition

Two Processes:Product Line Engineering Process (for reuse)

Product Engineering Process (with reuse)


Product Line Process (1)

Goal: reduce investment and present results earlier

Features:Defined with SPEM

Using best practices

Two different process

Iterative


Product Line Process (2)

Product Line Engineering

Process

Product Line Engineering

Process Asset

management (Reuse library)

Asset management (Reuse library)

Product Engineering Process

Inicio Elaboración Construcción Transición Inicio Elaboración Construcción Transición Inception Elaboration Construction Transition

AssetsAssets

RequirementEngineering

ReferenceArchitecture

definition

Component Implementation

Domaindefinition

Assets Assets


PL Engineering Process

Three phases:PL inceptionPL elaborationPL construction

Six disciplines:Domain definitionPL Requirement engineeringReference architecture definitionComponent implementationOther (Test & Change management)


PL Requirements Engineering

Initial: features & use-cases [solution oriented]

Add Goals:Intentional viewpoint – explicit

Problem oriented

NFR dealing

Analyze alternatives


Goal Model Examples

D D

D

Persona Discapacitada

Comunicar

Receptor

Mensaje

D

Facilidad de Uso

Movilidad

D D

D

D

Comunicador Aumentativo Y Alternativo

(CAA)

D Entregar Mensaje D

Facilidad de Uso

D D

D D Mensaje

Obtener Mensaje

D D

ALCANZARComunicación

AND

ALCANZAR Mensaje

Introducido

ALCANZAR Mensaje

Reproducido

OR OR

Mediante Texto

Mediante SPC

Usando Texto

Usando Voz

ACTORLeyenda HARDGOAL

SOFTGOAL

RECURSO TASK


PL Models

Goal Model

Feature Model Feature SubModel

Product Line Model

Application Model

Soft-goal Model

Application Goal Model

<<refine>>

<<refine>> <<refine>>

<<refine>>

<< instanceOf >>

<< instanceOf >>

<<instanceOf>>


MDA

Model Driven Architecture (MDA)

Introduced by OMG

Based in models:Platform Independent Model (PIM)

Platform Specific Model (PSM)

Automatic transformations PIM -> PSM

Can be applied to our process?


Index

Introduction

MDA & Product LinesProcess

Model Transformation

Support

Conclusions


MDA & Product Lines

Several model types:Goal & SoftgoalFeatureArchitecture (class)

Different scope:All PL (variability & communality)Each application

PIM modelsPIM to PIM transformations


PL Architecture(OO Framework)

ApplicationFeature

Sub-Model

ApplicationModel

Application EJB

PIM to PSMtransformations

Application .NET

PIM to PIMTransformations?

ApplicationGoal/soft-goal

Model

Instantiation

SelectionGoal/soft-goal

Model

ConfigurationFeatureModel

Rationale

DefinitionPL Architecture(OO Framework)

ApplicationFeature

Sub-Model

ApplicationModel

Application EJB


Application .NET



Model

Instantiation

SelectionSelectionGoal/soft-goal

Model

ConfigurationConfigurationFeatureModel

Rationale

Definition

Process


Model Transformations

Horizontal Selection – Domain engineer

Configuration – Trazability

Application from PL – Trazability

VerticalPL development

Goals to Features

Features to Architecture

Application development (PIM to PSM)


PL Architecture(OO Framework)

ApplicationFeature

Sub-Model

ApplicationModel

Application EJB


Application .NET



Model

Instantiation

SelectionGoal/soft-goal

Model

ConfigurationFeatureModel

Rationale

DefinitionPL Architecture(OO Framework)

ApplicationFeature

Sub-Model

ApplicationModel

Application EJB


Application .NET



Model

Instantiation

SelectionSelectionGoal/soft-goal

Model

ConfigurationConfigurationFeatureModel

Rationale

Definition

Transformation



Feature Metamodel


UML Class Metamodel


Features to Architecture Transformation

Consist on:Feature model -> PackageEach Feature -> Class

Associate SolitaryFeatures to owner featureFeatureGroup -> super-class of owned features + association

Describe transformations with Query/View/Transformation (QVT)

OMGLast submited version


FeatureModelToNamespace

m:FeatureModel<<domain>>

name=fm

n:Namespace

name=fm

<<domain>>uml, efm, c

FeatureModel to Namespace

Feature Model is transformed in a Package


whenFeatureModelToNamespace(m,n)

RootFeatureToClass

f:RootFeature<<domain>>

name=fn

m:FeatureModel

c:Class

name=fn

<<domain>>

uml, efm, c

where

SolitaryFeatureToClass(f,c)

FeatureGroupToClass(f,c)

n:Namespace

RootFeature to Class

The RootFeature is transformed to the first class


whereSolitaryFeatureToClass(sf,sc);FeatureGroupToClass(sf,sc);

SolitaryFeatureToClass

f:Feature<<domain>>

sf:SolitaryFeature

c:Class<<domain>>

uml, efm, c

a:Association

name=snfeatureCardinality=fc

sc:Class

name=sn

ae2:AssociationEnd

multiplicity=fc

ae1:AssociationEnd

multiplicity=“1..1”

SolitaryFeature to Class

SolitaryFeatures are transformed into classes and associated to the owner feature with multiplicity featureCardinality


whereGroupedFeatureToClass(fg,cg);

FeatureGroupToClass

f:Feature<<domain>>

fg:FeatureGroup

uml, efm, c

name=gngroupCardinality=gc

c:Class<<domain>>

a:Association

ae2:AssociationEnd

multiplicity=gc

ae1:AssociationEnd

multiplicity=“1..1”

cg:Class

name=gn

FeatureGroup to Class

FeatureGroups are transformed to super-classes of owned GroupedFeatures and associated with multiplicity groupCardinality


whereSolitaryFeatureToClass(f,c)FeatureGroupToClass(f,c)

GroupedFeatureToClass

fg:FeatureGroup<<domain>>

f:GroupedFeature

gc:Class<<domain>>

uml, efm, c

name=fn

c:Class

name=fn

g:Generalization

parent

child

GroupedFeature to Class

GroupedFeatures are transformed to Classes


Index

Introduction

MDA & Product Lines

Support

Conclusions


Support

Specification independent of implementation.

Based on:Models representation.

Transformation implementation.

Two approaches:XML + XSLT / Java

Graph Grammars + AGG


XML + XSLT

Under Eclipse

Feature Model -> Xfeature plugin:XML

Customizability of meta-model

Architecture Model -> EMFXML vs XMI

MDA based

Ecore


<xsl:template match="fm:FeatureModel">

<xsl:apply-templates select="fm:RootFeature"/>

</xsl:template>



<xsl:template match="fm:RootFeature">

<xsl:apply-templates select="fm:FeatureGroup"/>

<xsl:apply-templates select="fm:SolitaryFeature"/>

</xsl:template>



<xsl:template match="fm:SolitaryFeature">



</xsl:template>



<xsl:template match="fm:FeatureGroup">

<xsl:apply-templates select="fm:GroupedFeature"/>

</xsl:template>



<xsl:template match="fm:GroupedFeature">



</xsl:template>


XFeature


Resulting Model


Eclipse Integration


Index

Introduction

MDA & Product Lines

Support

Conclusions


Conclusions

Exploration MDA to PL

Transformation Feature -> Architecture

Hidden set of NFR:Separate aspects explicitly

Add NFR details manually from base PIM

Use goals to derive optimal feature sub-graph

From features, rebuild architectural PIM

Trazability mechanism needed


THANK YOUQuestions?,

Advices?,

Ideas?,

…?


GRACIASAlguna Pregunta?,

Sugerencia?,

Idea?,

…?


Índice

Introducción

Aplicación de MDA a Líneas de Producto

Soporte

Conclusiones


Índice

IntroducciónLíneas de Producto

Proceso – Ingeniería de Requisitos

Modelos

MDA® – MDE

Aplicación de MDA a Líneas de Producto

Soporte

Conclusiones


Graph Transformations

Models = Graphs

Model Transformations = Graph Transformations

Metamodel = Type Graph

Models = Typed Graphs + Attributes

Rule ordering: Layered Graph Grammars

AGG: State of the art graph transformation tool

Context + Layers + Attributes


Graph Transformation Rules

QVT rule translates into a set of GG rules:Create classes

Classes in the target model matching features in the source model

Move childrenLink Features in the source model to the transformed parent class

Delete Feature NodeTransformed Feature node has no children and can be deleted


Rule Ordering

LayersL0: FeatureModelToNamespace

L1: RootFeatureToClass

L2: SolitaryFeatureToClass

L3: FeatureGroupToClass

L4: GroupedFeatureToClass

Dangling edges restriction

Loop over layers


RootFeature To Class Rules


Initial Feature Model


Resulting Architecture Model

Documents

II Taller sobre Desarrollo de Software Dirigido por Modelos, MDA y Aplicaciones (DSDM'05) MDA e Ingeniería de Requisitos para Líneas de Producto Bruno