Capítulo 3 - Universidad Nacional de Colombia ... · desarrollo de software usado y los elementos de modelo que representan ... El resto de este capítulo está compuesto de cuatro

78

Capítulo 3 El Patrón de Trazabilidad

Este capítulo define un Patrón de Trazabilidad como el metamodelo que soporta un marco

conceptual de trazabilidad basado en la transformación de modelos. Dicho marco de trabajo

provee los elementos necesarios para la definición de Modelos de Trazado como patrones que

controlan de la transformación de modelos. Para lograr esto se definen los siguientes objetivos: (1)

estandarizar la construcción de modelos de trazabilidad para el desarrollo dirigido por modelos, y

(2) definir la forma de verificación de la consistencia y la completitud desde los Modelos de

Trazado.

El patrón de trazabilidad se define como una extensión del metamodelo UML y se diseña

sistemáticamente desde el nivel del metamodelo para facilitar la creación de artefactos de

trazabilidad llamado Modelos de Trazado. Estos artefactos controlan la transformación de modelos

y proveen los elementos necesarios para verificar su consistencia y la completitud. En este nivel,

los Modelos de Trazado son vistas versionadas que muestran la traza de los requisitos y los

elementos de modelo que los representan en diferentes niveles de abstracción.

El equipo de desarrollo define los Modelos de Trazado como plantillas de control que soportan la

gestión de la configuración de los proyectos de desarrollo de software. Esta definición se hace de

acuerdo a necesidades particulares de verificación de consistencia y completitud en los diferentes

tipos de proyectos.

Las definiciones descritas en este capítulo se ejemplifican usando el caso de estudio del Sistema de

Subasta.

Capítulo 3.El Patrón de Trazabilidad Introducción

79

3.1 Introducción

La Trazabilidad o Rastreabilidad es una práctica de control y verificación de la evolución y

transformación de los requisitos en artefactos de software a través del ciclo de vida de desarrollo.

Usualmente, el equipo de desarrollo hace transformaciones “no formales” de acuerdo al proceso de

desarrollo de software usado y los elementos de modelo que representan el sistema en diferentes

niveles de abstracción (por ejemplo, el proceso de desarrollo unificado y elementos de modelo tales

como casos de uso, clases y componentes [Arlow and Neustad 2005]). No obstante, la práctica de la

trazabilidad depende de los criterios de calidad adoptados por el equipo de desarrollo y los

mecanismos ofrecidos por herramientas CASE de modelado tales como las matrices y modelos de

trazabilidad. Actualmente, estas herramientas ofrecen también un nivel básico de transformación de

modelos de clases de análisis en modelos de clases en una plataforma específica.

En los últimos años, enfoques del desarrollo dirigido por modelos MDD (Model-Driven

Development) proponen metamodelos o mecanismos de trazabilidad para registrar las

transformaciones de los modelos, de tal forma que se resuelvan problemas de interoperabilidad

durante el proceso de transformación, se establezcan vínculos de trazado que soporten la

transformación para verificar la consistencia y completitud, o para realizar la propagación del

cambio mediante actualizaciones incrementalmente [Bondé et al. 2005], [Feng et al. 2006],

[Almeida et al. 2006], [Kurtev et al. 2007], [Amar et al. 2008], [Drivalos et al. 2008], [Paige et al.

2008] como se describió en el capítulo anterior.

Este capítulo define un enfoque donde la trazabilidad se convierte en la práctica que controla la

transformación de los modelos para garantizar su consistencia y completitud. Para lograr esto se

define un metamodelo que soporta la definición de elementos trazables, vínculos de trazado y otros

elementos necesarios para desarrollar los “Modelos de Trazado” como patrones de control durante

el proceso de la transformación de los modelos de desarrollo en diferentes niveles de abstracción.

Sus instancias son modelos de trazabilidad versionados e independientes de los modelos de

desarrollo. La Figura 6 ilustra una vista del enfoque general de esta disertación y en especial de los

Modelos de Trazado que disponen de un modelo de transformación para generar modelos de

desarrollo desde los requisitos, a través del análisis y diseño donde el grupo de desarrollo toman

decisiones de modelado orientadas a lograr la consistencia y la completitud de los modelos y lograr

productos de software confiables. Así, los modelos de trazado se convierten en el mecanismo base

para el manejo del cambio.

Capítulo 3.El Patrón de Trazabilidad Introducción

80

Figura 6. Una vista de la Trazabilidad en el contexto MDD basada en Modelos de Trazado.

El resto de este capítulo está compuesto de cuatro secciones que discuten el marco conceptual de

trazabilidad de la siguiente forma. La Sección 3.2 presenta la teoría básica que respalda la

transformación de modelos y el tratamiento de la trazabilidad. La Sección 3.3 define el metamodelo

denominado Patrón de Trazabilidad que provee un conjunto de metaclases que definen elementos

trazables, el modelo de trazado y el modelo de transformación que soporta el desarrollo dirigido por

modelos. La Sección 3.4 desarrolla los Modelos de Trazado como artefactos de trazabilidad que

controlan la transformación de modelos. La Sección 3.5 presenta el manejo de la consistencia y la

completitud de los modelos de desarrollo a partir de la información que proveen los Modelos de

Trazado. La Sección 3.6 presenta una discusión acerca de las fortalezas y debilidades que presenta

el Patrón de Trazabilidad. La Sección 3.7 hace un análisis de los trabajos relacionados y,

finalmente, la Sección 3.8 concluye este trabajo y muestra la dirección del trabajo futuro en

investigación y aplicación.

3.2 La Ingeniería Dirigida por Modelos

La ingeniería dirigida por modelos MDE (Model-Driven Engineering) provee un ambiente de

desarrollo metodológico orientado por conceptos de modelos y dominios definidos por el OMG

(Object Management Group)14. MDE es un conjunto de propuestas basadas en el modelado de

14 www.omg.org/

Capítulo 3.El Patrón de Trazabilidad La Ingeniería dirigida por modelos

81

software definidas con base en MDA (Model-Driven Architecture) el cual a su vez define la

separación de modelos y las características necesarias para realizar la transformación demodelos en

diferentes niveles de abstracción conservando los objetivos de portabilidad, interoperabilidad, y

reuso [MDA-Guide 2003].

3.2.1 Definición General de Transformación de Modelos

Kleppe et al. definen una transformación como la producción automática de un modelo destino

desde un modelo fuente de acuerdo a una definición de transformación. Esto significa que un

conjunto de reglas de transformación describen como un modelo en su lenguaje fuente podría ser

transformado en otro modelo en su lenguaje destino. Así, una regla de transformación es una

descripción de cómo uno o más constructores del lenguaje fuente puede ser transformado en uno o

más constructores del lenguaje destino [Kleppe et al. 2003].

De acuerdo con Brown, definir la transformación de modelos no es una tarea fácil [Brown 2004].

Esta tarea requiere conocimiento especializado del dominio del negocio y las tecnologías usadas

para su implementación. Además, la transformación puede ser aplicada a descripciones abstractas

de un sistema para adicionar detalles que hacen las conversiones de elementos de modelo [Brown

2004].

En general, la transformación de modelos puede ser entendida como la evolución que los modelos

sufren durante el proceso de desarrollo ya sea por refinamiento, correlación con otros modelos, o

por los cambios naturales del sistema.

3.2.2 Arquitectura dirigida por modelos (MDA)

Un modelo tiene sentido de acuerdo a su descripción o especificación en un sistema y ambiente para

lograr un objetivo particular. MDA define las siguientes separaciones arquitectónicas: CIM, PIM,

PSM.

CIM (Computation Independent Model). Este tipo de modelo es una vista de un sistema

independiente de la computación. Son modelos del dominio, modelos del negocio o requisitos del

espacio del problema independientes de la computación. Es decir, estos modelos describen como el

sistema debe ser usado independiente a como el sistema es implementado.

PIM (Platform Independent Model). Este tipo de modelo es una vista de un sistema independiente

de la plataforma. Este tipo de modelo tiene un grado de independencia de la plataforma conveniente

para usar en plataformas diferentes.


82

PSM (Platform Specific Model). Este tipo de modelo es una vista del sistema en una plataforma

específica. Este modelo combina la especificación PIM con el detalle específico de la plataforma en

la cual será implementado el sistema, i.e., esquemas de bases de datos, Java, C++, etc.

MDA propone las siguientes técnicas que guían la transformación de modelos:

Refinamiento: es una transformación donde un modelo abstracto es transformado en un

modelo más concreto definido en el mismo lenguaje.

Abstracción: es una transformación donde un modelo concreto es transformado en un

modelo más abstracto definido en el mismo lenguaje.

Correlación (mapping): es una transformación de un modelo de entrada en su modelo de

salida ya sea que estén definidos en el mismo o diferente lenguaje.

MDA facilita el uso de marcas en los modelo para identificar características especiales de los

elementos de modelo involucrados en una transformación. Las marcas podría ser roles (definidos

desde patrones), tipos (especificado por clase, asociación y otros elementos de modelo),

estereotipos definidos en un perfil (profile), elementos de metamodelo (definidos desde MOF

(Meta-Object Facility) [MOF-OMG 2006]), etc. Cada marca definida se debe estructurar, restringir,

modelar y parametrizar. Así, un conjunto de marcas pueden llegar a estar relacionadas con una

plantilla (template) para indicar que un modelo debe ser transformado de acuerdo a dicha plantilla.

3.2.3 Desarrollo Dirigido por Modelos (MDD)

El desarrollo dirigido por modelos (Model-Driven Development) provee mecanismos y marcos de

trabajo (frameworks) para realizar la transformación de modelos basada en patrones de

transformación. Este tipo de desarrollo de software dirige sus esfuerzos a la construcción de

modelos a partir de un modelo fuente, la especificación de reglas de transformación, el uso de

herramientas de transformación y la generación automática de código.

Kulkarni y Reddy afirman que el MDD comienza con una especificación abstracta A que debe ser

transformada en una especificación concreta C en la arquitectura destino [Kulkarni and Reddy

2003]. Comúnmente, este tipo de desarrollo se soporta en cada capa que representa una vista del

sistema.

De acuerdo con Stahl y Volter las ventajas de un proceso de software MDD son [Stahl & Volter

2006]:

Aumentar la productividad.


83

Reducir el número de defectos durante el desarrollo y los altos costos de mantenimiento

Asegurar la inversión a largo plazo en arquitecturas tecnológicas. Esto significa, si la

plataforma tecnológica cambia, o si el uso de ambientes heterogéneos se considera,

entonces las aplicaciones podrían cambiar o fusionarse sin problema.

Permitir a las compañías desarrolladoras de software enfatizar las habilidades de sus

desarrolladores cuando tienen recursos restringidos, permitiendo la especialización de

expertos en el dominio del negocio o en técnicas de desarrollo de software.

Mantener el control de la propagación del cambio.

Asegurar partes significativas del sistema y así facilitar el desarrollo por familias de

productos.

Es común que los enfoques MDD definan la transformación de modelos desde PIM hacia PSM ya

que estos representan elementos estructurales que casi siempre facilitan una transformación uno a

uno. Las PIM se representan frecuentemente en diagramas de clases UML el cual facilita una

directa transformación a PSM cuyos elementos son estructuras definidas en una arquitectura

específica, por ejemplo, tablas o artefactos de despliegue. Los CIM requieren un esfuerzo adicional

para crear la transformación de modelos desde los procesos del negocio hacia la solución

[Chowdhary et al. 2006].

3.2.4 Patrón de Transformación

MDA provee un patrón donde un modelo de trasformación se encarga de hacer la transformación

unidireccional del modelo fuente al modelo destino, y cada uno de estos se define desde su propio

metamodelo. La Figura 7 ilustra un patrón genérico de transformación definido desde la

arquitectura OMG. Este orienta la forma de visualizar y realizar la transformación de modelos

desde cuatro capas de abstracción: la capa del meta metamodelo, la capa del metamodelo, la capa de

los modelos y la capa de las instancias de los modelos [MOF-OMG 2006], [MOF-QVT 2005].

Muchos enfoques usan esta arquitectura combinada con la transformación propuesta por la MDA

[Kulkarni and Reddy 2003], [Bezivin et al. 2005], [Koch 2006].


84

Figura 7. Patrón de Transformación propuesto por la OMG.

La capa M3 define el “Meta Metamodelo”. Este modelo define las estructuras y el comportamiento

más genérico o abstracto que se puede usar para crear otros metamodelos o modelos. En este caso,

este es el meta metamodelo MOF (Meta Object Facility) [MOF-OMG 2006].

La capa M2 define los metamodelos fuente y destino de acuerdo a los meta elementos que provee el

meta metamodelo MOF. El metamodelo M1 provee un lenguaje específico para definir el modelado

de sus elementos de modelo y el metamodelo M2 provee el lenguaje específico para definir el

modelado de sus elementos de modelo. Por ejemplo M1=UML metamodel y M2=Relational

metamodel. En esta capa se declara el modelo de transformación necesario para lograr el objetivo

de la transformación de modelos en una herramienta específica o conceptualmente.

La capa M1 representa los modelos fuente y destino, la solución específica para un problema del

negocio. En esta capa se declara las reglas de transformación que se usan en cada transformación.

Finalmente, la capa M0 define las instancias de los modelos fuente y destino (objetos).

3.2.5 Lenguajes de Transformación

MDD está directamente relacionado a los lenguajes de transformación, frameworks y herramientas

que soportan la transformación de modelos. Un lenguaje de transformación estandariza la forma de

construir y describir la transformación de los modelos por medio de reglas. En los últimos años se

han creado lenguajes, marcos de trabajo y herramientas para realizar la transformación. Algunos de

ellos se definen en herramientas open source con el IDE Eclipse : GReAT [Sprinkle et al 2003],

MOLA [Kalnins et al. 2004], VIATRA [Csertan et al. 2002], GROOVE [Rensink 2004], el iUML

(intelligent UML) [Bloomfield 2005], y grafos de transformación [Pérez et al. 2006], [Mens et al.


85

2006(b)]. Los lenguajes de transformación más conocidos que soportan la trazabilidad son QVT

[MOF-QVT 2005], ATL [Jouault and Kurtev 2005], y KERMETA [Falleri et al. 2006]. Este último

permite definir los modelos fuente y destino. Los próximos párrafos introducen las características

más relevantes de estos lenguajes proveen para el tratamiento de la trazabilidad.

MOF™ Query / Views / Transformations (QVT). Este lenguaje corresponde a una parte neutral

de la tecnología de MOF que está orientada a las consultas (queries), a las vistas (views), y a las

transformaciones (transformations). Cada tópico tiene su función específica en la transformación:

las “consultas” toman un modelo (fuente) y seleccionan elementos específicos de este modelo, las

“vistas” son modelos derivados (el destino) de otros modelos, y las “transformaciones” toman un

modelo de la fuente como una entrada y actualizan o crean el nuevo modelo destino. Una

transformación se define como una relación “Relation” que proporciona diferentes escenarios de

interpretación. El QVT es la base para lograr transformaciones modeladas en MDA [MOF-QVT

2005].

El MOF-QVT define tres actividades claves que deben estar implicadas en las transformaciones

modelas [MOF-QVT 2005]: selección de componentes de modelos de la fuente; construcción de

nuevos modelos para formar el destino de la transformación; modificación del modelo fuente de

modo que esto sea usado para formar parte del modelo destino.

Las características básicas de operación de QVT son [MOF-QVT 2005]:

Transformaciones de control para verificar que los modelos fuente y destino estén

relacionados con una forma específica de transformación.

Habilidades para establecer relaciones manuales o automáticas (por medio de herramientas

de transformación) entre modelos preexistentes.

Transformaciones horizontales, incrementales y bidireccionales (hacia delante y hacia

atrás).

Habilidades para manejar (adicionar o borrar) los objetos y los valores.

Las Relaciones (Relation) y dominios (Domain) para definir la transformación de

modelos y los elementos de modelo involucraos en la transformación.

Los dominios son variables con una identidad que puede ser asociada con un tipo específico

de modelo. Cada dominio tiene un patrón que se puede ver como un grafo con sus objetos

(nodos), propiedades, y arcos (asociaciones).


86

Las relaciones especifican los vínculos entre dos elementos de modelo de diferentes

dominios los cuales pueden tener restricciones que deben ser atendidas por ellos.

Las relaciones especifican cuando y donde se hace la transformación. Por ejemplo, la

Relation: ClassToTable necesita ser soportada cuando se hace la Relación

PackageToSchema entre el paquete que contiene la clase y el esquema que contiene la

tabla. Así, es necesario indicar donde se hace la transformación. Por ejemplo, la relación

ClassToTable debe mantener la relación AttributeToColumn. Estas cláusulas pueden

complementarse con expresiones OCL. La Figura 8 muestra un ejemplo de una regla

declarativa definida en QVT [MOF-QVT 2005].

Transformation UML2Rdbms (Uml: UML2.0, Rel:RDBMS) { TopLevel Relation Class2Table { checkonly domain Uml c: Class {name = n} checkonly domain Rel t: Table {name = n} when {isPersistent = true} where {Attribute2Column (c, t) }

} Relation Attrribute2Column { checkonly domain Uml c: Class { attribute = a: Attribute {name = an, type = p: DataType {name = dt}} } checkonly domain Rel t: Table {column: col:Column {name = an, type.name = dt} } when {not a.isMultivalued()} where {col.type = a.type} }

}

Figura 8. Una transformación definida en QVT.

Cuando se ejecuta una regla de transformación en QVT la transformación implícitamente crea

rastros entre elementos de modelos es decir, por cada relación hay una clase de traza con

características de trazabilidad y propagación del cambio para soportar y controlar la

operacionalización y ejecución de las reglas cuando se hace un cambio. Estas características están

definidas en la clase Trace la cual es una clase MOF con propiedades que se refieren a objetos y

valores en modelos que están relacionados por la transformación. Una clase de traza se deriva de

una Relation, pero la clase no es explícitamente declarada y usada en la transformación.

Una instancia de traza es una instancia de una clase de traza que representa un vínculo entre los

modelos establecidos para una ejecución de la transformación. Las instancias de la clase de traza

son localizadas y creadas desde las reglas de transformación. Una vez que ellas son ejecutadas, los

cambios del modelo fuente pueden ser propagados al modelo destino. Esto puede ser hecho


87

ejecutando de nuevo la transformación en el contexto de la traza para generar elementos de los

modelos destino que son relevantes para el cambio, sin modificar el resto del modelo. La Figura 9

ilustra un ejemplo de una regla declarativa definida en QVT [MOF-QVT 2005] donde se define la

clase Trace como el modelo destino de una relación de transformación.

relation RelationToTraceclass

{

checkonly domain relations r:Relation{name=rn,

domain = rd:RelationDomain

{ pattern=t:ObjectTemplateExp

{bindsTo=tv:Variable

{name=vn, type=c:Class {}}

}}}

enforce domain core rc:Class { name='T'+rn,

ownedAttribute=a:Property {name=vn, type=c}

}

where { SubTemplateToTraceClassProps(t, rc);}

}

Figura 9. Una Relación QVT y su clase de traza.

ATL. ATL es un lenguaje de transformación de modelos y un conjunto de herramientas

desarrollado por el grupo de ATLAS en la plataforma Eclipse. Así, ATL proporciona un conjunto

de herramientas para hacer transformaciones con modelos construidos en EMF (Eclipse Modeling

Framework)15 [Steinberg et al. 2008]. Las principales características de las reglas de transformación

ATL son [Bezivin et al. 2005], [Jouault and Kurtev 2005]:

Es una expresión declarativa compuesta de un patrón fuente y un patrón destino, y es

unidireccional.

Su sintaxis separa el modelo fuente del modelo destino con variables y patrones.

Se identifica de acuerdo a uno de las siguientes formas de lanzamiento: Standard, regla

que se aplica una vez por cada asociación que se encuentre entre modelos fuente y destino;

Lazy, regla que se lanza desde otras reglas (regla dependiente de una tipo Standard);

Unique Lazy regla que también se provoca por medio de otras reglas, pero solo se aplican

una vez para una asociación dada.

Soporta herencia entre reglas: una regla (llamada subrule) puede heredar desde otras

reglas (regla padre). Esto implica un número de restricciones en patrones fuente de sub-

reglas.

15 www.eclipse.org/emf/

Capítulo 3.El Patrón de Trazabilidad Definición del Patrón de Trazabilidad

88

Se soportan en tuplas OCL.

La Figura 10 muestra un ejemplo de transformación Class2Table definida en ATL. Esta regla

integra la trazabilidad al programa de transformación Class2Relational por medio de un

elemento traceLink.

module Class2Relational; /* ATL transformation rule with traceability link */ create OUT : Relational, trace: Trace from IN : Class; rule Class2Table { from c : Class!Class to out : Relational!Table (

name <- c.name, col <- Sequence {key}->union(c.attr->select(e | not e.multiValued)),

key <- Set {key} ),

key : Relational!Column (

name <- 'objectId',

type <- thisModule.objectIdType ), traceLink : Trace!TraceLink (

ruleName <- ' Class2Table', targetElements <- Sequence {t} )

do {traceLink.refSetValue('sourceElements', Sequence {s}); }

}

Figura 10. Regla de transformación ATL donde el componente traceLink registra la traza durante la transformación.

3.3 Definición del Patrón de Trazabilidad

3.3.1 Motivación de Creación del Patrón de Trazabilidad

Mejorar la práctica de la trazabilidad en la industria de software no es algo simple debido a las

costumbres o normatividades que los equipos de desarrollo siguen en su proceso de desarrollo. No

obstante, dichas prácticas pueden inhiben la adopción y uso de nuevos paradigmas tanto de

desarrollo como de gestión de la configuración. Para estrechar la brecha entre las prácticas reales y

los nuevos paradigmas de desarrollo como el desarrollo dirigido por modelos, en esta disertación se

define un framework conceptual que orienta la gestión de la configuración desde el uso de los

modelos de trazabilidad como elementos que controlan la transformación de modelos, ayudando a

los equipos de desarrollo a tomar decisiones de modelado en función de la consistencia y la

completitud de los modelos.


89

Por lo tanto, en este capítulo se define un “Patrón de Trazabilidad” (Traceability Pattern) que ayuda

a soportar los siguientes aspectos: (i) estandarización del uso de las relaciones de traza (abstracción

y realización) proporcionadas por UML para la construcción de modelos de trazabilidad; (ii)

formalización de vínculos de trazado como artefactos que controlan las transformaciones de los

modelos; (iii) control de predecesores y sucesores para mantener la consistencia y la completitud de

los modelos de desarrollo; (iv) manejo del cambio desde modelos de trazado. Cada uno de estos

aspectos se expone en los siguientes párrafos.

Estandarización del uso de las relaciones de abstracción y realización definidas por UML en

modelos de trazabilidad. UML proporciona relaciones de abstracción y realización para vincular

elementos modelos que deben ser rastreados en modelos de trazabilidad [UML-Superstructure

2005]. Estas relaciones tienen su significado, sin embargo su uso puede variar según la

interpretación de equipo de desarrollo o el tipo del sistema de software que desarrollan. Lograr una

estandarización en el uso de estas relaciones mejora la creación de modelos de trazado

independientes de los modelos de desarrollo. Por ejemplo, la Figura 11 ilustra dos modelos de

trazabilidad que involucran elementos de modelo del mismo tipo y cuyas relaciones abstracción

siendo iguales los vincula de forma diferente cambiando su significado de refinamiento o

correlación. Los modelos de trazabilidad definen las siguientes trazas:

a. UseCaseRealization-1 realiza (usando el estereotipo <<refine>>) al UseCase-1, el

cual a su vez realiza (usando el estereotipo <<realize>>) al Requirement-1.

b. UseCaseRealization-2 realiza (usando el estereotipo <<realize>>) al UseCase-2, el

cual a su vez traza (usando el estereotipo <<trace>>) al Requirement-2.

Figura 11. Uso de las relaciones de abstracción y realización en modelos de trazabilidad.

custom Traceability Model

Requirement-1Use Case-1

UseCase Realization-1

Requirement-2Use Case-2

UseCase Realization-2

(a)

(b)

«realize»«trace»

«realize» «refine»


90

La forma en que un modelo de trazabilidad es construido depende de los estándares de calidad

usados por el equipo de desarrollo o por su experiencia. Esta situación podría causar una

interpretación inadecuada del rastreo de requisitos y el manejo del cambio.

Formalización de los vínculos de trazado para controlar las transformaciones modelos. Las

relaciones de abstracción UML usadas en un modelo de trazabilidad no están relacionadas con un

modelo de transformación formal. La trazabilidad está limitada a la identificación de la dependencia

entre elementos de modelos por refinamiento o correlación, usando matrices de trazabilidad. La

transformación es intuitiva o usa algunos vínculos de trazado para registrar las transformaciones.

Definir modelos de trazabilidad como controladores de la transformación de los modelos en el

contexto MDD mejora la gestión de la configuración para proceso de desarrollo comúnmente

usados como el proceso unificado.

Control de Predecesores y Sucesores. Cuando un elemento modelo es refinado, o mapeado, desde

un nivel de abstracción n hacia un nivel de abstracción n+1, es importante conocer y conservar a sus

precursores y sucesores a fin de facilitar la verificación de la consistencia y completitud de los

modelos de desarrollo durante su transformación. Además, esto facilita la traza y la transformación

bidireccional.

Manejo del Cambio. El equipo de desarrollo debe reconocer los modelos de trazabilidad como

patrones o artefactos de software básico para la gestión de la configuración y así consolidar el

análisis del impacto y la propagación del cambio soportado en un modelo de transformación.

Controlar el rastro que deja un requisito de software en el ciclo de vida de

desarrollo se refleja en el nivel de confiabilidad que logran los artefactos o

elementos de modelo que lo implementan como producto

3.3.2 Descripción del Patrón de Trazabilidad

El “Patrón de Trazabilidad” es un metamodelo que facilita la práctica de la trazabilidad que se

realiza iterativamente durante la transformación de modelos para garantizar su consistencia y

completitud. Provee la estructura necesaria para estandarizar, desde el nivel del metamodelo, la

práctica de la trazabilidad en el contexto del desarrollo dirigido por modelos y el desarrollo

orientado por aspectos. A partir de este metamodelo se define el marco conceptual objetivo de esta

disertación. La Figura 12 ilustra el patrón de trazabilidad descrito en las de tres capas de la

jerarquía definida por el OMG [UML-Infrastructure 2006].


91

Figura 12. Patrón de trazabilidad definido en tres de las capas de metamodelos OMG.

A continuación se describen cada una de las capas en las cuales se define el Patrón de Trazabilidad

(desde el concepto de la jerarquía de capas de la OMG).

Capa M3. Establece el metamodelo UML [UML-Superstructure 2005] en el nivel meta donde las

estructuras y el comportamiento más abstracto son usados para la definición del Patrón de

Trazabilidad.

Capa M2. Define el Patrón de Trazabilidad como una instancia del meta metamodelo UML. La

Figura 13 ilustra la estructura que incluye nuevos elementos, relaciones, y operaciones que

especifican las estructuras y el comportamiento necesarios para realizar la trazabilidad y controlar la

transformación de los modelos. En esta capa, los equipos de desarrollo definen Modelos de Trazado

como patrones para controlar la transformación de los modelos en diferentes niveles de abstracción,

garantizando su consistencia y completitud.

Capa M1. Es la capa de los modelos de desarrollo que han sido transformados de acuerdo al

Modelo de Trazado abstracto que controla la transformación. Aquí también se obtienen las vistas

<<metamodel>>

UML

M3- Meta metamodel Layer

<<metamodel>>

Traceability Pattern

<<instanceOf>>

M2- Metamodel Layer<<instanceOf>> <<instanceOf>><<instanceOf>>

M1- Model Layer

<<instanceOf>>

Tracing Model Transformation Model


92

versionadas de los modelos de trazado para cada objetivo del sistema. En la Figura 13 muestra una

instancia de un modelo de trazado definido en el Patrón de Trazabilidad de forma abstracta. En este

caso, la instancia corresponde a la trazabilidad del objetivo “Vender Bienes (Sell Goods)” en el

Sistema de Subasta (Auction System), versión 1.0.0. Este sistema se encuentra descrito en el

Apéndice C16.

Figura 13. Una vista de la estructura del Patrón de Trazabilidad en el nivel del metamodelo (M2).

La estructura del patrón consiste de tres paquetes: EABaseModels,

TransformationRulesModel, y TracingControllerModel (los paquetes en la Figura 13).

Estos agrupan un conjunto de metaclases que determinan un objetivo específico del patrón. Cada

uno de estos paquetes es descrito detalladamente en los siguientes párrafos.

1. Paquete EABaseModels. Este paquete proporciona una extensión de la metaclase Element

definida en el metamodelo de UML [UML-Infraestructure 2006] u otro metamodelo definido desde

MOF. Esto significa que además de los elementos definidos en el metamodelo UML

(namedElement, Relationship, Classifier, etc.), nuevos elementos de metamodelo son

especializados desde Element con constructores bien definidos para soportar los objetivos del

Patrón de Trazabilidad. La Figura 14 ilustra las metaclases originales que especializan a Element 16 Este caso de estudio se describe y desarrolla en el idioma inglés durante todo el documento con el fin de estandarizar

los términos usados en nuestras publicaciones y otros artículos de la comunidad en general que usan este mismo caso de estudio.


93

(en blanco y cuya definición está dada en [UML-Superstructure 2004]) y que a su vez son

extendidas por las nuevas metaclases (en amarillo) Requirement, Concern (Functional,

BusinessRules, QualityService, Information, Context), DependencyConcern,

TracingModel, ConcernModel, TracingLink, el atributo baseAbstractionLevel y el rol de

relación modelLevel. En los siguientes párrafos se explican cada uno de estos nuevos

metaelementos.

Figura 14. Una vista de la metaclase Element del Patrón de Trazabilidad con sus especializaciones y enriquecimiento semántico.

Requirement. Es una metaclase que especializa a ValueExpression y Namespace. Un

Requirement (requisito) es una expresión que formaliza necesidades de usuarios y sistema dentro

de un Namespace en el cual es definido. Este es un elemento nombrado con propiedades añadidas

como identification, description, type, priority, complexityLevel, etc. También, es

un elemento que puede ser refinado o correlacionado a otros elementos del metamodelo. Por

ejemplo, un requisito podría ser refinado a un caso de uso o a una operación en una clase.

Concern. Es una clase abstracta que especializa Package. Un Concern es un contenedor que

puede agregar una colección coherente de elementos tales como Requirement, UseCase, Class,

Collaboration, etc. El Concern se especializa en Functional, BusinessRules,

QualityServices, Information, y Context. Cada uno de ellos identifica el tipo de

comportamiento o información que agrupa.


94

DependencyConcern. Es una clase abstracta que especializa a la relación de Dependency. Esta

metaclase facilita la definición de relaciones entre Concerns en un modelo de asuntos.

TracingLink. Es una clase abstracta que especializa a las relaciones Abstraction y

Realization. Las relaciones Association, Aggregation, Generalization, y Dependency

son elementos trazables definidos al nivel del metamodelo mientras que Abstraction,

Realization, Refine y Trace serán parte de los modelos de trazado.

ConcernModel. Es una clase abstracta que especializa a Model. Es un contenedor de Concerns

que permite mantener la integridad de los objetivos del sistema.

TracingModel. Es una clase abstracta que especializa a Model. En ella se declaran los modelos de

trazado abstractos que actúan como patrones de control durante el proceso de transformación.

baseAbstractionLevel. Es un nuevo atributo de la metaclase Element para identificar el nivel

de abstracción en el cual un elemento es definido por defecto.

modelLevel. Es un nuevo role definido desde la relación con la metaclase Model que especifica el

modelo en el cual un elemento es una instancia. Los modelos agrupan elementos definidos o

transformados en diferentes niveles de abstracción. Los valores que este rol puede tomar se

expresan al nivel de los siguientes modelos: desde el modelo de representaciones abstractas de los

Requisitos del sistema (que puede ser entendido como modelos CIM), a través de modelos más

concretos de Análisis (que puede ser entendido como PIM), hacia modelos más concretos de Diseño

que definidos de acuerdo a la arquitectura del sistema (que puede ser entendido como PSM). Los

siguientes párrafos definen el significado de cada uno de estos modelos de desarrollo definidos en

los diferentes modelos de abstracción.

Modelo de Requisitos (Requirements Model). Los modelos definidos en el nivel de

abstracción de requisitos podrían contener elementos de modelo como procesos del

negocio, requisitos funcionales y no funcionales, casos de uso, actividades, prototipos,

modelo del dominio, y otros tipos de requisitos o artefactos conceptuales que representan

una arquitectura inicial en el espacio del problema. En este nivel de abstracción no es fácil

estandarizar la forma de representar los requisitos, por lo tanto el metamodelo fuente define

el lenguaje y los elementos trazables para definir la traza y la transformación. Comúnmente,

la especificación de requisitos depende del alcance del proceso de desarrollo en las etapas

tempranas, o la herramienta usada para el modelado de los requisitos durante el proceso de

ingeniería.

CapítDefin

Con e

abstra

por su

casos

instan

ejemp

ilustr

ulo 3.El Patrónición del Patr

Modelo d

se define

modelos

ellos son

otros com

fuente y

requisitos

Modelo d

diseño co

sistema.

arquitectu

operacion

el objetivo d

acción los m

u parte son s

s de uso, el m

ncia de un e

plo de jerarq

ra la sintaxis

Figura 15. J

ón de Trazabión de Trazabi

de Análsis (A

en por medi

más concret

: UseCaseR

mo prototipo

el destino en

s hasta el dis

de Diseño (D

ontienen ele

El patrón d

ura UML tal

nes de servic

de estandariz

modelos de d

separados po

modelo de cl

elemento es

quía de mod

usada para l

Jerarquía de m

lidad ilidad

Analysis M

io del Patró

tos que repre

Realizatio

s, modelo de

n unas traza

eño arquitec

Design Mod

ementos de

de trazabilid

les como col

cio, asuntos a

ar la constru

desarrollo son

or los tipos de

lases, el mod

la hoja fina

delos para el

a definición

modelos para

95

Model). En

ón de Trazab

esentan los r

on (Collabo

e clases, diag

as cuando la

ctónico.

del). Los m

modelo má

dad está orie

laboraciones

al nivel del d

ucción de los

n separados

e modelos us

delo de activ

l de una jer

l Auction Sys

de un eleme

a los modelos

el nivel de a

bilidad. Esto

requisitos en

oration al

gramas inter

transformac

modelos defin

ás concretos

entado a us

de diseño, c

diseño, etc.

s modelos en

por objetivo

sados en la tr

vidades, y el

arquía de m

stem y el ob

ento de mode

s de desarroll

abstracción d

os modelos

el nivel del

nivel del an

activos, etc.

ción se hace

nidos en el n

que repres

sar los elem

componentes

n esta diserta

os, subsistem

ransformació

modelo de i

modelos. La F

bjetivo Sell G

elo en un mod

lo para el obj

de análisis los

contienen e

Análisis. A

nálisis), Act

Estos mode

desde el niv

ivel de abstr

entan la sol

mentos de m

s, conectores

ción, en cad

mas, o asunto

ón (p.ej., el m

interaccione

Figura 15 m

Goods y la F

delo de desa

etivo Sell Go

s modelos

elementos

lgunos de

ivity, y

los son la

vel de los

racción de

lución de

modelo de

s, puertos,

a nivel de

os, y ellos

modelo de

s). Así, la

muestra un

Figura 16

arrollo.

oods.


96

Figura 16. Definición de elementos de modelo en un modelo de un nivel de abstracción.

2. Paquete TransformationRulesModel. En este paquete se define la metaclase

ModelTransformations la cual facilita la definición al nivel meta de reglas de transformación y

operaciones relacionadas con la transformación de modelos. La Figura 17 ilustra la metaclase donde

cada regla es única e identifica los elementos del modelo fuente y del modelo destino. Además es

un elemento nombrado que se distingue por un tipo que le da sentido y orden durante la ejecución

en el modelo de transformación. Una regla puede estar subordinada (subordinateOf) a otra para

mantener la consistencia de ejecución de forma directa. El modelo de transformación que soporta al

Patrón de Trazabilidad se detalla en el Capítulo 4.

Figura 17. Una vista de la metaclase ModelTransformations y su relación con otras metaclases.

3. Paquete TracingControllerModel. En este paquete se definen un conjunto de metaclases

que actúan como un motor de trazabilidad para controlar la transformación de modelos desde los

requisitos y a través de diferentes niveles de abstracción. La Figura 18 ilustra las clases que son

parte de este paquete, donde las relaciones de dependencia con otros paquetes se transforman en

Definición: System::Modelo::Element::Name

Instancias: Auction System::Analysis::UseCase::Sell Goods

Auction System::Analysis::Package::UseCase::Sell Goods | R1: Enroll Users

(este caso particular define Element como una jerarquía de elementos, al igual que sus nombres separados por el carácter “|”)

Nombre del modelo donde puede ser instanciado el elemento

Tipo de elemento

Nombre de elemento que es instanciado

Sistema que se desarrolla


97

asociaciones de composición para que los elementos trazables y el modelo de transformación sean

parte de los “Modelos de Trazado” (TracingModels).

Figura 18. Una vista del paquete TracingControllerModel.

A continuación se definen cada una de las metaclases que hacen parte de este paquete.

TracingModel. Es la metaclase que le da el sentido a una semántica de trazado donde elementos

trazables y vínculos de trazado forma Modelos de Trazado abstractos que serán usados como

artefactos de control de la transformación de modelos. Cada Modelo de Trazado se identifica por

medio del atributo typeTracingModel y diferencia los elementos rastreables por medio un rol

que define sus responsabilidades de transformación y control el dicho modelo. Estos roles son: eje

de trazado (<<axisTracing>>), predecesor (<<predecessor>>), y sucesor (<<sucesor>>).

Los vínculos de trazado establecen el rastro, controlan la transformación, facilitan la verificación de

consistencia y completitud, y controlan la propagación de cambio. En el nivel del modelo, sus

instancias son vistas de modelos que registran la evolución de los requisitos proporcionando la

información necesaria para proveer servicios de control de versiones.

TracingLink. Es la metaclase que define el rastro entre elementos trazables. Los vínculos de

trazado son una especialización de las relaciones UML de Abstraction o Realization que se

definen para controlar las ejecución de las reglas de transformación (metaclase

ModelTransformations) y gestionar las Secuencias de Traza (metaclase TraceSequence) que

soporta la consistencia y la completitud de los modelos. El uso de los vínculos de trazado se

describe en las siguientes secciones.

Capítulo 3. El Patrón de Trazabilidad Modelos de Trazado

98

3.4 Modelos de Trazado

Un Modelo de Trazado (tracingModel) especifica qué tipos de elementos participan en la

trazabilidad de los requisitos, y cómo ellos están relacionados por medio de vínculos de trazado

para controlar las transformaciones de los modelos garantizando la consistencia y completitud

durante el proceso de desarrollo.

Un Modelo de Trazado está compuesto de elementos trazables o rastreables, y vínculos de trazado

definidos en el nivel del metamodelo con el fin de que cada modelo se pueda utilizar como una

plantilla (template) que controle la creación de modelos de desarrollo y sus transformaciones, en

diferentes tipos de proyectos.

Una instancia de Modelo de Trazado es una vista de los modelos de desarrollo de acuerdo a la

definición del Modelo de Trazado. Cada instancia está asociada a un número de versión que facilita

el control del cambio. La vista toma una versión ya sea cuando se crea por primera vez

(denominada línea base de la trazabilidad) o cuando se hace un cambio.

El uso de Modelos de Trazabilidad facilita enterder que:

“La trazabilidad es un asunto que interviene la transformación y

evolución de los requisitos para mantener su Consistencia y

Completitud”

El control de la versión es configurado por el grupo de desarrollo por medio del sistema de control

de versiones que utilicen. Algunos de ellos son: SCC17, CVS18, Subversion19 o TFS20. La Figura 19

muestra la definición de una vista versionada de un modelo de trazado: System name, Subsystem

name, version number. El ejemplo muestra una vista versionada general y por subsistemas, Sell

Goods y Buy Goods, para el Sistema de Subasta versión 1.0.0 (Auction System v.1.0.0.).

La vista de un modelo de trazado es el conjunto de instancias de los elementos trazables, vínculos

de trazado, secuencias de trazado y reglas que controlan la transformación de los modelos en un

momento determinado del tiempo. Por lo tanto las vistas versionadas no pueden ser modificadas;

17 http://www.sparxsystems.com/uml_tool_guide/uml_model_management/versioncontroloptionsscc.html. 18 http://www.nongnu.org/cvs/. 19 http://subversion.tigris.org/. 20 http://msdn.microsoft.com/en-us/magazine/cc163498.aspx.


99

sólo nuevos vínculos pueden ser adicionados si, y sólo si, son gestionados por medio de un requisito

de cambio (este es un caso especialmente tratado en el Capítulo 7 de Gestión del Cambio).

Figura 19. Una instancia de un Modelo de Trazado para el Auction System v.1.0.0.

3.4.1 Elementos Trazables

Un elemento trazable es un Element definido en un Modelo de Trazado e identificado en este por

medio de un rol que le asigna responsabilidades de control en el modelo. Un rol usa los siguientes

estereotipos: <<axisTracing>>, <<predecessor>>, y <<successor>>.

Eje de Trazado (<<axisTracing>>). Un elemento es declarado como eje de trazado para un

Modelo de Trazado si, y sólo si, este es un elemento seleccionado para controlar las

transformaciones de los modelos por medio de sus vínculos de trazado con elementos de

predecesores y sucesores. Varios elementos pueden ser declarados como ejes del trazado y uno de

ellos debe declararse como el líder de la traza a fin de establecer vínculos de trazado dominantes

con los predecesores y sucesores. Esta clase del elemento usa el estereotipo <<axisTracing>> y

todos los elementos definidos con este pertenecen al mismo nivel de abstracción y facilitan la

realización de las siguientes actividades.

Coordinación de la construcción de los vínculos de trazado que controlan la ejecución de

reglas de transformación asociadas con predecesores y sucesores.

Gestión del cambio durante la propagación y estimación del impacto de cambio.

Generación de secuencias de trazado para verificar la completitud y la consistencia.

La Expresión (1), abajo, muestra una definición básica de un elemento identificado con el rol

axisTracing en un Modelo de Trazado.


100

<<axisTracing>>system::modelLevel::Element::name

Ejemplo de una instancia:

<<axisTracing>>Auction System::Analysis::UseCase::Sell Goods

Donde: modelLevel es el modelo de desarrollo en el que se define la instancia del elemento definido como eje del trazado (esto también aplica a las definiciones de predecesores y sucesores).

(1)

Predecesor (<<predecessor>>). Un elemento es predecesor de otros si, y sólo si, es definido en

un nivel de abstracción anterior a los elementos declarados como ejes del trazado, en el mismo

modelo de trazado. Los predecesores están relacionados con elementos declarados como

<<axisTracing>> por medio de un vínculo de trazado dominante (p.ej., <<refine>> ó

<<realize>>). Si un elemento predecesor forma parte de reglas de transformación con elementos

modelos diferentes del axisTracing, entonces estas reglas serán ejecutadas para mantener la

consistencia del modelo. Aunque un predecesor sólo se debe generar por la ejecución de reglas de

transformación, su declaración en el modelo de trazado es una buena práctica tanto para optimizar

la ejecución de reglas de transformación como saber los elementos modelos básicos para validar la

completitud del modelo. Varios elementos pueden ser declarados como predecesores y uno de ellos

debe ser el líder del rastro a fin de establecer vínculos de trazado dominantes con el líder de los ejes

del trazado.

La Expresión 2 muestra una definición básica de un elemento identificado con el rol predecessor

en un Modelo de Trazado.

<<predecessor>>modelLevel::Element::name


<<predecessor>>Requirement::Requirement::Open an Auction to Sell Goods

(2)

Sucesor (<<successor>>). Un elemento obtiene un estereotipo de sucesor si, y sólo si, es definido

en un nivel de abstracción posterior del elemento axisTracing en el mismo modelo de trazado.

Los sucesores están relacionados con los ejes del trazado por medio de un vínculo de trazado

dominante (p.ej., <<refine>> ó <<realize>>). Si un elemento sucesor forma parte de reglas de

transformación con elementos modelos diferentes del axisTracing, entonces estas reglas serán

ejecutadas para mantener la consistencia del modelo. Aunque un sucesor sólo se debe generar por la

ejecución de reglas de transformación, su declaración en el modelo de trazado es una buena práctica

tanto para optimizar la ejecución de reglas de transformación como saber los elementos modelos

básicos para validar la completitud del modelo. Varios elementos pueden ser declarados como


101

sucesores y uno de ellos debe ser el líder del rastro a fin de establecer vínculos de trazado

dominantes con el líder de los ejes del trazado.

La Expresión (3) ilustra una definición básica de un elemento identificado con el rol successor en

un Modelo de Trazado.

<<successor>>modelLevel::Element::name


<<successor>>Design::Collaboration::Sell Goods

(3)

La Tabla 2 muestra algunos elementos trazables usados en este enfoque para demostrar el uso de los

Modelos de Trazado en el contexto de un desarrollo UML en diferentes niveles de abstracción

(Requirements, Analysis, y Design).

Tabla 2. Elementos Trazables en el nivel del metamodelo.

Name abstractionLevel Requirement Requirement UseCase Analysis Activity Analysis Class Analysis Sequence Analysis Collaboration Design Component Design Interface Design ... ...

Estos elementos trazables son usados con frecuencia en tareas de modelado durante el proceso de

desarrollo. Algunos de ellos tales como Activity o Sequence son conjuntos de clasificadores u

otros tipos de elementos que son parte de los diagramas de comportamiento UML. La asignación

del nivel de abstracción (abstractionLevel) corresponde al nivel de madurez donde el elemento

debe ser definido. Sin embargo, algunos de estos elementos se podrían refinar en modelos de

diferentes niveles de abstracción.

3.4.2 Vínculos de Trazado

Un vínculo de trazado es una relación de abstracción o realización UML relacionada con una o

varias reglas de transformación responsables de controlar la transformación de modelos fuente en

modelos destino. Las reglas pueden ser separadas en grupos de acuerdo a diferentes alternativas de

modelado que permiten que el equipo de desarrollo tome decisiones sin preocuparse de la

consistencia y la completitud que es asegurada por los vínculos de trazado. Las reglas de


102

transformación podrían ser implementadas en un lenguaje de transformación como QVT [MOF-

QVT 2005] o ATL [Bezivin et al. 2005]. La Expresión (4) define un vínculo de trazado (tracing

link).

<<tracingLink>>(SourceTrace, TargetTrace)[TransformationRule]

Donde:

sourceTrace y TargetTrace son elementos trazables definidos para un modelo de trazado.

Un Tracing Link puede estar asociado a 0, 1, ó n reglas de transformación las cuales se definen entre “[]”.

(4)

Así es posible definir un modelo de trazado abstracto en función de sus elementos trazables y los

vínculos de trazado. La Figura 20 y la Figura 21 ilustran dos vistas de la definición formal de un

Modelo de Trazado como la unión de elementos trazables definidos en cada rol y vínculos de

trazado horizontales (entre roles de trazado de diferente nivel de abstracción) y vínculos de trazado

verticales (entre roles de trazado de un mismo nivel de abstracción) con fin de controlar las

transformaciones de los modelos desde elementos cuyo rol es el <<axisTracing>>.

Figura 20. Definición de un Modelo de Trazado genérico con elementos trazables, vínculos de trazado y su transformación de modelos.

TracingModel = {HorizontalTraces} ∪ {VerticalTraces}

donde:

(i) Horizontal_Traces =

{<<tracingLink>>(<<axisTracing>>sourceModel::Elementi,

<<predecessor>>targetModel::Elementj)[transformationRule]}

∨ {<<tracingLink>>(<<successor>>sourceModel::Elementk,

i

i+1 i+n

J

j+n

k


103

<<axisTracing>>targetModel::Elementi)[transformationRule]}

(ii) VerticalTraces =

{<<tracingLink>>(<<axisTracing>>sourceModel::Elementi,

<<axisTracing>>targetModel::Elementi+n)[transformationRule]}

∨ {<<tracingLink>>(<<predecessor>>sourceModel::Elementj,

<<predecessor>>targetModel::Elementj+n)[transformationRule]}

∨ {<<tracingLink>>(<<successor>>sourceModel::Elementk,

<<successor>>targetModel::Elementk+n)[transformationRule]}

(iii) {Elementi, Elementi,..., Elementi+l} ∈ AbstractionLevelAL

(iv) {Elementj, Elementj,..., Elementj+m} ∈ AbstractionLevelAL-1

(v) {Elementk, Elementk,..., Elementk+n} ∈ AbstractionLevelAL+1

Figura 21. Definición formal de los Modelos de Trazado.

Definición de un Perfil TracingModel. La Figura 22 muestra un perfil definido en un ambiente

UML. Los roles de trazado (axisTracing, predecessor, y successor) son declarados como

estereotipos que extienden la metaclase Element. Ellos están asociados con las metaclases

Abstraction y Realization como fuente o destino de estas dependencias, y dichas metaclases

están asociadas con la metaclase ModelTransformations que declara reglas y el mecanismo de

transformación.

Figura 22. El perfil del TracingModel para implementar su uso en ambientes de modelado UML.


104

Tipos de Vínculos de Trazado. Para evitar la ambigüedad en el uso de las dependencias de

abstracción y realización UML que se usan los estereotipos <<trace>>, <<refine>> y

<<realize>>. A continuación se hace una adaptación a la definición básica de UML.

<<trace>> (sourceTrace, targetTrace). Este vínculo de trazado es una relación

de abstracción UML que representa la relación entre elementos de modelos o conjuntos de

elementos de modelo que representan el mismo concepto en modelos diferentes (ver la

definición UML en la Sección 2.2.2 del Capítulo 2, Pags.: 29-30). Las definiciones

siguientes describen el uso de este vínculo en el modelo de trazado.

Definición 1. Un vínculo de trazado <<trace>> se usa cuando los elementos de los

modelos de la fuente y destino representan el mismo concepto en modelos diferentes (p.ej.,

el modelo en la fuente: Activity, modelo en el destino: UseCase), del mismo nivel de

abstracción (p.ej, Analysis), y el mismo estereotipo de trazado (p.ej,

<<axisTracing>>). En este vínculo de trazado el elemento modelo de la fuente (que está

en la cola de la flecha, el cliente) traza el elemento de modelo destino (que está en la

saetilla, el proveedor); este significa que las reglas de transformación asociadas con el

vínculo de trazado podría ser bidireccional conservando la trazabilidad vertical.

Definición 2. Un vínculo de trazado <<trace>> se usa cuando los elementos de los

modelos de la fuente y destino representan el mismo concepto en modelos diferentes donde

la fuente es un elemento de comportamiento y el objetivo es un elemento estructural (p.ej,

modelo de la fuente: Class, modelo del destino: UseCase). Este significa que las reglas de

transformación asociadas con el vínculo de trazado podrían ser bidireccionales conservando

la trazabilidad vertical.

Definition 3. Un vínculo de trazado <<trace>> se usa para trazar la dependencia de un

elemento de cambio estereotipado como <<change>> con instancias de elementos de

modelo definidos un modelo de trazado. Un cambio no es la fuente o el destino de una regla

de transformación; este es el elemento que proporciona la información a los desarrolladores

para crear o actualizar elementos instancias del modelo.

La Figura 23(a) ilustra un modelo de desarrollo con dos elementos modelos que representan

el mismo concepto en el nivel de abstracción de Análisis: el UseCase::Sell Goods y la

Activity::AD-Sell Goods (ver su definición completa en el Apéndice C). Por otra parte,

la Figura 23(b) ilustra una instancia de un modelo de trazado donde se usa el vínculo de

trazado <<trace>> en instancias de modelo obtenidas por medio de las siguientes trazas:


105

• <<trace>>(

<<axisTracing>>AuctionSystem::Analysis::Activity::Sell Goods,

<<axisTracing>>AuctionSystem::Analysis::UseCase::Sell

Goods) [R1, R2, ..., Rn].

• <<trace>>(

<<axisTracing>>Analysis::AuctionSystem::UseCase::Sell Goods,

<<change>>Analysis::R20:Verify minimal goods number to offer).

El vínculo de trazado <<trace>> que crea la dependencia entre un elemento de modelo y

un cambio no tiene reglas de transformación asociadas. Sin embargo, para propagar el

cambio se activan las reglas de transformación asociadas al elemento directamente afectado

por el cambio cuya ejecución será coordinada por los elementos ejes del trazado asociados a

este.

Advertencia: si hay elementos declarados en el mismo rol que no están relacionados por

medio del vínculo de trazado <<trace>>, entonces ellos deben ser directamente

relacionados con elementos identificados con otros roles por medio de vínculos de trazado

<<realize>> ó <<refine>>. Esto garantiza la consistencia y completitud de estos

elementos, de lo contrario siempre serán reportados como inconsistencia e incompletitud.

Figura 23. Uso del vínculo de trazado <<trace>>. (a) Un modelo de desarrollo de Análisis. (b) Una instancia de un modelo de trazado aplicado al sistema de subasta.

<<refine>> (sourceTrace, targetTrace). Este vínculo de trazado es una relación

de realización UML que representa el refinamiento de elementos modelos en niveles de

abstracción diferentes (ver la definición UML en la Sección 2.2.2 del Capítulo 2, Pags.: 29-

30). Este es un vínculo de trazado denominado “dominante” establecido entre los ejes del


106

trazado y predecesores o sucesores. La siguiente definición describe el uso de este vínculo

en los modelos de trazado.

Definición. Un vínculo de trazado <<refine>> es usado cuando los elementos modelos de

la fuente y destino representan el mismo concepto en niveles de abstracción diferentes (p.ej,

nivel de la fuente: Analysis, nivel destino: Requirement), y tienen el estereotipo de

trazado diferente (p.ej, fuente: <<axisTracing>>Analysis:: UseCase::name,

destino: <<predecessor>>Requirement:: Requirement ::name). En este vínculo

de trazado el elemento modelo de la fuente (en la cola de la flecha, el cliente) refina el

elemento modelo destino (en la saetilla, el proveedor). Cuando el elemento modelo de la

fuente es declarado en el diseño (un sucesor) o nivel de abstracción de código, el elemento

destino (un eje de trazado) está en la saetilla triangular (el proveedor). Las reglas de

transformación asociadas con este vínculo de trazado podrían ser bidireccionales

conservando la trazabilidad horizontal. Esta es una relación dominante en los modelos de

trazado.

La Figura 24(a) muestra los modelos de desarrollo que participan en la traza. Sus elementos

de modelo representan el mismo concepto en diferentes modelos de abstracción: el

Requirement:: R1: Register Goods es creado en el nivel de Requisitos, el UseCase::

Sell Goods en el nivel del Análisis y la UseCaseRealization:: Sell Goods en el nivel

del diseño.

La Figura 24(b) muestra las instancias de un modelo de trazado donde los vínculos de

trazado definen la trazabilidad y la transformación de estos elementos de la siguiente forma:

el elemento de modelo Requierement::R1:Register Goods se crea en el nivel de

Requisitos y se refina en el UseCase::Sell Goods en el nivel del Análisis, el cual a su vez

es refinado por el UseCaseRealization::Sell Goods en el nivel del diseño.


107

Figura 24. Uso del vínculo de trazado <<refine>> en un Modelo de Trazado.

Las instancias del modelo de trazado se obtienen por medio de las siguientes trazas:

• <<refine>>(<<axisTracing>>Analysis::UseCase::Sell Goods, <<predecessor>>Requirement::Requirement::R1:Register Goods) [R5].

• <<refine>>(<<successor>>Design::Collaboration::Sell Goods, <<axisTracing>>Analysis::UseCase::Sell Goods) [R6].

<<realize>> (source, target). Este vínculo de trazado es una relación de

realización UML que representa la realización de un conjunto de elementos de modelo en

niveles de abstracción diferentes. Este es un vínculo de trazado dominante establecido entre

los ejes del trazado y sucesores. La siguiente definición describe el uso de este vínculo de

trazado en los modelos de trazado.

Definición. Un vínculo de trazado <<realize>> se usa cuando el elemento de modelo de

la fuente es realizado (o implementado) por un elemento modelo destino. Ellos son

representados en niveles de abstracción diferentes (p.ej, nivel de la fuente: Design, nivel

destino: Analysis) y tienen el estereotipo de trazado diferente (p.ej, fuente:

<<successor>> Collaboration::name, destino: <<axisTracing>>

UseCase::name). En este vínculo de trazado el elemento de modelo de la fuente (en la

cola de la flecha, el cliente) realiza el elemento del modelo destino (en la saetilla triangular,

el proveedor). Comúnmente, una relación de realización se define entre un axisTracing y

successor que lo implementan. Las reglas de transformación asociadas con este vínculo

de trazado pueden ser bidireccionales conservando la trazabilidad horizontal. Esta es una

relación dominante en los modelos de trazado.


108

La Figura 25(a) muestra dos modelos de desarrollo en diferentes niveles de abstracción. La

Figura 25(b) muestra una instancia del modelo de trazado donde la clase Class::Actioned

Good y la Collaboration::Sell Goods realizan el UseCase::Sell Goods. Las instancias

del modelo de trazado se obtienen por medio de las siguientes trazas:

• <<realize>>(<<successor>>Analysis::Class::Sell Goods, <<axisTracing>>Design::Collaboration::Sell Goods) [R8].

• <<realize>>(<<successor>>Analysis::Class::Sell Goods, <<axisTracing>>Design::Class::Auctioned Good) [R9]

Figura 25. Uso del vínculo de trazado <<realize>> en un Modelo de Trazado.

3.4.3 Tipos de Modelos de Trazado

Los tipos de Modelos de Trazado se definen con el fin de controlar y soportar la gestión de

configuración en diferentes tipos de procesos de desarrollo y diferentes tipos de proyectos de

software. Por lo tanto la creación de un Modelo de Trazado se definen por medio de los siguientes

criterios: Tipo de modelo o metodología de desarrollo, Características de modelado, y el Grado de

refinamiento y correlación.

Tipo de modelo o metodología de desarrollo. Se debe seleccionar la metodología, proceso

de desarrollo de software o el marco de trabajo que será soportado por un modelo de

trazado. Por ejemplo: el Proceso Unificado [Arlow and Neustad 2005], o los modelos de

Asuntos (descritos en el Capítulo 5).

Características de Modelado. Se deben identificar las principales características de

modelado que apoyen la gestión de configuración. Esto permite identificar elementos que

actuarán como ejes del trazado y sus vínculos de trazado para generar predecesores y

sucesores. Ellos pueden ser artefactos de desarrollo que guíen el desarrollo, elementos

modelos involucrados en diferentes niveles de abstracción, lenguajes de modelado, etc.


109

Grado de refinamiento y correlación de los elementos. Se debe establecer el nivel de

granularidad de los elementos que participan en la traza para conservar la consistencia y la

completitud en diferentes niveles de abstracción. Esta características es muy importante ya

pueden participar elementos de modelo definidos desde diferentes metamodelos.

Comúnmente, las compañías de software clasifican diferentes tipos de aplicaciones o proyectos de

software de acuerdo al dominio de aplicación y la complejidad del sistema. Esto facilita a los

equipos de desarrollo la selección del tipo de Modelo de Trazado que puede ser usado como un

patrón en diferentes proyectos de software. Dos tipos de Modelos de Trazado se definen en este

enfoque para demostrar la aplicación de los modelos de trazado.

Modelos de Trazado basados en Casos de Uso (Tracing Model base don Use Cases). Este tipo de

modelo de trazado actúa como un patrón para la gestión de la configuración en procesos de

desarrollo basados en casos de uso. A continuación se presenta el análisis de las características para

definir este tipo de modelo de trazado.

Tipo de modelo o metodología de desarrollo: el proceso de desarrollo unificado.

Características de modelado: centrado en casos de uso, centrado en la arquitectura,

lenguaje de modelado UML, iterativo e incremental.

Centrado en Casos de Uso. Esta característica indica que el UseCase es el elemento que

actúa como el eje del trazado y es el líder de traza para otros elementos tales como:

Activity y Class (Class Model). Estos son definidos en el nivel de abstracción del

Análisis, ya que este es un nivel de transición donde los elementos de modelo consiguen el

grado de madurez necesaria para mantener el vínculo de trazado con los requisitos (en el

espacio del problema) y el espacio de solución. Los predecesores (p.ej, Requirement) y

sucesor (p.ej, Component) son predefinidos por el equipo de desarrollo para determinar los

vínculos de trazado y las reglas de transformación.

Las compañías de software de desarrollo comúnmente adaptan el RUP según sus

necesidades, estilos de desarrollo, y tipo de aplicaciones de software. Probablemente el

equipo de desarrollo considera otros elementos como el eje del trazado en el nivel de

abstracción de análisis. Por ejemplo, si ellos son estrictos con el proceso unificado

[Jacobson et al. 2000], el eje de trazado es el UseCaseRealization ó Collaboration

en el nivel de Análisis, entonces el UseCase podría ser definido como el sucesor en el nivel

de Requisitos.


110

En MDA los modelos independientes de la computación (CIM) son frecuentemente

representados por modelos de casos de uso y sugiere una transformación directa a los

modelos independientes de la plataforma que a menudo son representados con modelos de

diseño de Componentes. Sin embargo, esta transformación sufre varios refinamientos ya que

no es fácil transformar el problema a la solución. Por lo tanto, esta situación aconseja el uso

de un nivel medio (análisis) para conseguir una verdadera transformación.

Centrado en la Arquitectura. Esta característica determina la organización de elementos

modelos en capas diferentes. Un estilo de arquitectura determinar los componentes,

interfaces, colaboraciones, composición, etc. Por lo tanto, este guía la simetría y la

transitividad necesaria entre algunos elementos modelos declarados como el eje del trazado

y sus elementos de trazado en otros niveles de abstracción como predecesores y sucesores.

Lenguaje de modelado UML. Esta característica sugiere que todos los elementos de los

modelos fuentes y destino, en diferentes niveles de abstracción, son definidos en un solo

lenguaje, en el UML.

Iterativa e Incremental. Esta característica sugiere el manejo de versiones para los

elementos de modelo transformados y las instancias de los modelos de trazado.

Grado de refinamiento y correlación: El proceso de desarrollo unificado determina los

elementos de modelos que son creados en las diferentes disciplinas y etapas del ciclo de vida

(de forma implícita) indicando así la traza que se debe realizar desde los requisitos hasta la

arquitectura de componentes. Esto orienta el nivel de consistencia y completitud que se debe

lograr y el tipo de los elementos de modelo que participan en el modelo de trazado para

lograrla. Por ejemplo, un UseCase es refinado por Collaboration y realizado por

Class que son la compilación de todos los roles que participan en todas las realizaciones del

caso de uso. Por lo tanto, el grado de refinamiento y correlación determina la simetría y la

transitividad necesaria entre algunos elementos modelos relacionados con los ejes del

trazado.

La Figura 26 ilustra la definición de un Modelo de Trazado basado en Casos de Uso en el cual

se definen elementos abstractos al nivel del metamodelo que están encargados de coordinar la

transformación de modelos cuando las instancias de los modelos fuentes son creadas o

modificadas.

De los elementos declarados como ejes del trazado <<axisTracing>>::UseCase,

Activity, Class, e InterationFragment (del Interaction Diagram), el UseCase coordina


111

la trazabilidad con predecesores y sucesores, por medio de los vínculos de trazado

<<refine>> y <<realize>> (trazas dominantes) los cuales tienen un conjunto de reglas de

transformación para generar los modelos de desarrollo destino y las instancias versionadas de

los modelos de trazado (la operacionalización de las transformaciones se define en el modelo de

transformación del Capítulo 4).

Figura 26. Una vista de un Modelo de Trazado basado en Casos de Uso.

De los elementos declarados como predecesores Requirement, Process (representado en

diagramas de actividades o notaciones similares), y Class en el modelo del dominio,

Requirement lidera la traza. Estos elementos tienen vínculos de trazado <<trace>> para

mantener la trazabilidad vertical y establecer la traza entre elementos de comportamiento y

estructurales que representan el mismo requisito en un nivel de abstracción inicial.

De los elementos declarados como sucesores Collaboration, Component, e Interface,

Collaboration lidera la traza. Ellos tienen vínculos de trazado <<trace>> para mantener la

trazabilidad vertical y establecer la traza entre elementos de comportamiento y estructurales que

representan el mismo requisito en un nivel de abstracción final. En este caso el elemento

Interface tiene un vínculo de trazado <<trace>> con Component lo cual podría indicar que

transformationRule

transformationRule

/<<refine>>

Notation:R=<<realize>>/<<refine>>T=<<trace>>TRACING LINKSR={(UseCase, Requirement), (Collaboration, UseCase)}T<<axisTracing>>= {(Class, UseCase), (Activity, UseCase), (InteractionFragment, Class)}T<<predecessor>>= {(Requirement, ActivityBP), (Class, Requirement)}T <<predecessor>>= {(Interface, Collaboration), (Component, Collaboration)}


112

cualquier elemento declarado en el nivel de implementación podría ser trazado a un componente o

sus servicios.

Otros elementos tales como Actor, Operation, Property y Connector, también se definen

como parte de este modelo de trazado basado en casos de uso pero no se muestran por el espacio y

facilidad comprensión. Ellos complementan las transformaciones de los modelos de los elementos

básicos tales como UseCase, Class, y Component respectivamente conservando las relaciones

definidas en los paquetes del metamodelo UML.

Elementos tales como Business Process, User Interface (prototipos), Business Rules,

Testing Scenarios, también se pueden definir en el modelo de trazado de acuerdo a las

decisiones del grupo de desarrollo o el proceso establecido en la empresa.

Las Tabla 3 y la Tabla 4 muestran la definición del modelo de trazado basado en casos de uso. Cada

elemento que es la parte del modelo es definido con un role, en un nivel de abstracción y se

identifica por un nombre. Algunos elementos pueden ser definidos en varios niveles de abstracción,

que significan que ellos son refinados en estos niveles (p.ej., Class).

Tabla 3. Elementos trazables para el Modelo de Trazado basado en Casos de Uso.

Tracing Role Element composedOf <<axisTracing>> Analysis:: UseCase:: name General Features,

basicFlow, alternativeFlow, ExtensionPoint

<<axisTracing>> Analysis:: Actor:: name <<axisTracing>> Analysis:: Class:: name Property, Operation <<axisTracing>> Analysis:: Property:: name <<axisTracing>> Analysis:: Operation:: name <<axisTracing>> Analysis:: Activity:: name Action, ObjectNode,

... <<axisTracing>> Analysis:: InteractionFragment:: name <<axisTracing>> Analysis:: Relationship:: name <<axisTracing>> Analysis:: Association:: name <<axisTracing>> Analysis:: Generalization:: name <<axisTracing>> Analysis:: Dependency:: name <<predecessor>> Requirement:: Requirement:: name <<predecessor>> Requirement:: Activity (Business

Process) :: name Activity, process, ControlFlow, Entity, ...

<<predecessor>> Requirement:: Class (DomainModel) :: name

Properties, Operations

<<predecessor>> Requirement:: Relationshipv <<predecessor>> Requirement:: Association:: name <<predecessor>> Requirement:: Generalization:: name <<predecessor>> Requirement:: Dependency:: name <<successor>> Design:: Collaboration:: name <<successor>> Design:: Component:: name <<successor>> Design:: Interface:: name <<successor>> Design:: Connector:: name <<successor>> Design:: Relationship:: name <<successor>> Design:: Association:: name <<successor>> Design:: Generalization:: name <<successor>> Design:: Dependency:: name


113

Tabla 4. Vínculos de Trazado definidos para el Modelo de Trazado basado en Casos de Uso.

Tracing Link

SourceTrace TargetTrace TransformationRule

<<realize>> / <<refine>>

<<axisTracing>>Analysis:: UseCase:: name

<<predecessor>> Requirement:: Requirement:: name

- Requirement2UseCase - UseCase2Requirement

<<realize>> <<successor>>Design::Collaboration:: name

<<axisTracing>>Analysis::UseCase::name

UseCase2Collaboration

<<trace>> <<axisTracing>>Analysis::Class:: name


UseCase2Class

<<trace>> <<axisTracing>>Analysis::Activity:: name


UseCase2Activity

<<trace>> <<axisTracing>>Analysis::InteractionFragment:: name

<<axisTracing>>Analysis::Class::name

Class2InteractionFragment

<<trace>> <<predecessor>>Requirement::Requirement:: name

<<predecessor>>Requirement::Activity(Business Process)::name

ActityBP2Requirement

<<trace>> <<predecessor>>Requirement::Class(DomainModel):: name

<<predecessor>>Requirement::Requirement::name

Requirement2ClassDomainModel

<<trace>> <<successor>>Design::Component:: name

<<successor>>Design::Collaboration::name

Collaboration2Component

<<trace>> <<successor>>Design::Interface:: name

<<successor>>Design::Collaboration::name

Collaboration2Interface

Un vínculo de trazado es bidireccional si, y solo si las reglas de transformación asociadas con esta

se definen en doble sentido. Por ejemplo: Requirement2UseCase, UseCase2Requirement (ver

Tabla 4 primera fila).

La Figura 27 muestra una instancia del modelo de para el Auction System — Sell Goods v.1.0.0. Por

cada objetivo o asunto definido para el sistema son generados en una instancia versionada del

modelo de trazado. Por ejemplo se tendría una instancia de modelo de trazado para el subsistema de

Comprar Bienes (Auction System — Buy Goods v.1.0.0.), otra para el subsistema de Gestionar

Crédito (Auction System — Account Credit Management v.1.0.0.), etc. Cualquier operación de

cambio en los modelos de desarrollo se controla desde cada una de esas instancias.

Figura 27. Instancia del modelo de trazado para el sistema Auction System, subsistema Sell Goods v.1.0.0.


114

Dependiendo del tipo del proyecto de software, el grupo de desarrollo puede escoge el modelo de

trazado más conveniente.

La Figura 28 ilustra un modelo alternativo al Modelo de Trazado basado en Casos de Uso, donde

los predecesores y ejes del trazado son instancias del Patrón de Trazabilidad y los sucesores se

definen desde el metamodelo Relational Database.

Figura 28. Modelo de trazado alternativo al Modelo de Trazado basado en Casos de Uso donde los sucesores se definen el metamodelo de las Bases de Datos Relacionales.

transformationRule

transformationRule

CapítConsi

3.5

Los M

los m

muy

defin

3.5.1

Exten

Cons

Los v

artefa

mues

trazad

Un m

cuale

de lo

trazad

ulo 3.El Patróistencia y Com

Consiste

Modelos de T

modelos de d

claro el sign

nir cuáles son

Definició

ndiendo la de

istencia de lo

“L

pr

vínculos de t

actos que re

stra una defin

do establecen

modelo de tra

es proporcion

s modelos. L

do de la Figu

F

ón de Trazabimpletitud (C&

encia y Com

Trazado son

desarrollo dur

nificado de c

n los element

ón de Consis

efinición bás

os modelos c

La propiedad

en un mod

reservado cu

trazado ayud

epresentan el

nición forma

n el modo de

azado garant

nan la inform

La Tabla 5 m

ura 26.

Figura 29. Def

lidad &C)

mpletitud d

diseñados p

rante el proc

consistencia

tos o artefact

stencia

sica de consi

como:

d que garanti

delo fuente, en

ando se tran

mismo n

dan a control

l mismo req

al de la consi

e verificar es

tiza la consis

mación neces

muestra los v

finición de Co

115

de los Mod

ara soportar

ceso. Esto sig

y completitu

tos de softwa

istencia dada

iza el signific

n un nivel de

nsforma en un

nivel de abst

a las contrad

quisito en el

istencia para

sta propiedad

stencia por m

saria para rea

vínculos de t

onsistencia d

delos de D

y verificar l

gnifica que e

ud a partir d

are implicado

a en el capítu

cado de los r

e abstracción

n modelo des

tracción X.”

dicciones ent

l mismo niv

a modelos de

d en ellos.

medio del ví

alizar la verif

traza <<trac

desde el Patró

Desarrollo

la consistenc

el equipo de

de los Mode

os en la verif

ulo anterior,

requisitos def

n X, siendo e

stino definid

tre elemento

vel de abstra

e desarrollo d

ínculo de tra

ficación dura

ce>> definid

ón de Trazabi

ia y la comp

desarrollo d

los de Traza

ficación.

este enfoque

finidos

este

do en el

s modelos, m

acción. La F

donde los ví

azado <<tra

ante la transf

dos para el m

ilidad.

pletitud de

debe tener

ado, para

e define la

modelos o

Figura 29

ínculos de

ace>> los

formación

modelo de

CapítConsi

Tab

3.5.2

Exten

Comp

Los v

mode

Figur

víncu


bla 5. Definici

Tracing Link

<<trace>>

<<trace>>

<<trace>>

<<trace>>

<<trace>>

<<trace>>

<<trace>>

Definició

ndiendo la d

pletitud de lo

“La

fu

vínculos de t

elos, o artefa

ra 30 muest

ulos de trazad

F


ión de los vínuso para c

Sourc

<<axisTrais::Class<<axisTrais::Activ<<axisTrais:: Interactiname <<predeceement::Requirement<<predeceement::Cldel) name<<successComponent<<successInterface

ón de Compl

definición d

os modelos c

a propiedad

uente, de abst

de

trazado ayud

actos que rep

tra una defi

do establecen

Figura 30. Def

lidad &C)

nculos de trazcontrolar la co

ceElement

acing>>Analys:: name acing>>Analyvity name acing>>Analy

ionFragment

essor>>Requie t name essor>>Requilass(DomainMe sor>>Design:t name sor>>Design:e name

letitud

de completitu

como:

que garantiz

tracción nive

efinido en el

dan a control

presentan el

nición form

n el modo de

finición de Co

116

zado <<trace>onsistencia en

Ta

ys <<axisTr:UseCase

ys <<axisTr:UseCase

ys <<axisTr:Class n

ir <<predecnt:: Pro

irMo

<<predecnt:: Requirem

: <<succeslaborati

: <<succeslaborati

ud dada en

za que los ele

el X, es trans

nivel de abs

la la incomp

mismo requ

al de compl

e verificar es

ompletitud d

>> en el modn los modelos

argetElement

racing>>Anale::name racing>>Anale name racing>>Analname

cessor>>Requocess name

cessor>>Requ

ment name ssor>>Designion name ssor>>Designion name

el capítulo

ementos defi

sformado en

tracción Y (X

pletitud prod

uisito en dife

letitud para

ta propiedad

desde el Patró

delo de trazads de desarroll

T

lysis: UseC

lysis: UseC

lysis: ClasFrag

uireme Procnt

uireme Requ

n::Col Collpone

n::Col Collerfa

anterior, es

inidos en un

un modelo d

X≠Y).”

ducida por lo

erentes nivel

modelos de

d en ellos.

ón de Trazabi

do basado en lo.

ransformationRules

Case2Class

Case2Activit

ss2Interactigment

cess2Require

uirement2Cla

laboration2Cent laboration2Iace

ste enfoque

modelo

destino

os elementos

les de abstra

desarrollo d

ilidad.

casos de

n

ty

ion

eme

ass

Com

Int

define la

modelos,

acción. La

donde los

Capítulo 3.El Patrón de Trazabilidad Consistencia y Completitud (C&C)

117

Un modelo de trazado garantiza la completitud por medio de los vínculos de trazado <<realize>>

ó <<refine>> que establecen la correlación o el refinamiento entre elementos trazables de niveles

de abstracción diferentes (ver la Tabla 6).

Tabla 6. Vínculos de trazado <<realize>> ó <<refine>> para garantizar la completitud en los modelos de desarrollo cuya transformación es controlada por un modelo de trazado basado en casos de uso.

Tracing Link SourceTrace TargetTrace Transformation Rules

<<realize>> / <<refine>>

<<axisTracing>>Analysis:: UseCase::name

<<predecessor>> Requirement:: Requirement::name

Requirement2UseCase

<<realize>> <<successor>>Design::Collaboration::name


UseCase2Collaboration

El nivel de verificación de la consistencia y la completitud de un modelo de desarrollo se garantiza

de forma básica con los anteriores vínculos de trazado. No obstantes hay vinculos de trazado

indirectos que se deben manejar como secuencias de traza y trazas implícitas para garantizar un alto

nivel en estos atributos de calidad.

3.5.3 Secuencias de Traza

Una secuencia de traza es un conjunto de vínculos de trazado que forman parte de una expresión

lógica para garantizar la transitividad entre elementos trazables, con el fin de crear nuevos vínculos

de trazado que facilitan servicios de trazabilidad complementarios. Además, estos permiten crear un

encadenamiento de reglas de transformación para optimizar la interpretación realizada por las

operaciones del tracingModel cuando son generados los modelos de desarrollo destino y las

instancias versionadas de los modelos de trazado.

Las secuencias de traza facilitan el soporte a servicios complementarios de trazabilidad tales como

la propagación del cambio. Estas secuencias se deben generar automáticamente a partir de los

vínculos de trazado de un Modelo de Trazado cuando este se define por primera vez.

La Expresión (5) define una secuencia de elementos trazables cuyas relaciones son vínculos de

trazado que promueven una relación de transitividad. Esto significa que un Elementi tiene un

vínculo de trazado horizontal con un Elementj el cual a su vez tiene un vínculo de trazado vertical

con el Elementj+1, entonces, el Elementi tiene un vínculo de trazado horizontal con un

Elementj+1. Esta relación resultante de la transitividad se convierte en un vínculo de trazado

dinámico, complementario a los vínculos de trazado originalmente definidos. La transitividad es

conmutativa lo cual ayuda a tener los mismos resultados independientemente del orden de las

relaciones.

CapítConsi

El eq

verifi

defin

trazab

trazad

eleme

Figu


Trace S

Element

Donde:

- i y j

- El sítransit

- Elemede un v

- horizdominande la t

- Una strazado

quipo de desa

icar la consi

nición genera

bles y sus v

do dominant

entos de un m

ura 31. Secuen


Sequence=

ti horizontal<<t

j represent

ímbolo dtividad (se

enti, Elemevínculo de

zontal <<trntes que setransitivid

secuencia do horizonta

arrollo puede

stencia y la

al de un mod

ínculos de tr

tes R para de

mismo rol de

ncias de trazavínculos d

lidad &C)

tracingLink>> E

Ele

tan diferen

denotas el equenceFina

entj, and Etrazado en

racing linke conservandad.

de traza deal.

e definir secu

completitud

delo de traz

razado. Esto

efinir secuen

e trazado.

a definidas ende trazado es

118

Elementj ver

ementi horizon

ntes nivele

vínculo deal).

lementj+n sn el mismo

k>> son vínn en el vín

ebe tener a

uencias de tr

d de los mod

zado y una v

os conjuntos

cias de traza

n un modelo s analizada de

rtical<<tracingL

ntal<<tracingLin

es de abstr

e trazado r

on elementmodelo de

nculos de tnculo de tr

al menos un

raza adiciona

delos de desa

vista de este

están relacio

a con los vín

de trazado y esde la teoría

Link>> Elemen

nk>> Element

racción (i≠

resultado d

os que son trazado.

trazado razado resu

n vínculo d

ales que con

arrollo. La F

como un co

onados por m

culos de traz

cuya transitia de conjunto

ntj+n

tj+n

≠j).

de la

parte

ultado

de

(

nsidere neces

Figura 31 mu

onjunto de e

medio de ví

zado T defin

ivitad lograds.

(5)

arias para

uestra una

elementos

nculos de

idos entre

a con sus


119

Las siguientes secuencias de traza se definen para el modelo de trazado basado en casos de uso. La

Expresión (6) muestra una secuencia de trazado donde Collaboration realiza el UseCase el cual

a su vez traza a Requirement, entonces, Collaboration realiza a Requirement.

Collaboration<<realize>>UseCase<<refine>>Requirement

Collaboration<<realize>>Requirement

(6)

La Expresión (7) muestra una secuencia de traza donde el UseCase refina a Requirement y este a

su vez traza a Class (domain model), entonces, UseCase refina a Requirement.

UseCase<<refine>>Requirement<<trace>>Class(domain model)

UseCase<<refine>>Class(domain Model)

(7)

La Expresión (8) muestra una variante de este tipo de secuencia de traza. La traza en un nivel de

abstracción determina la transitividad de trazas secundarias de otro nivel de abstracción. Este tipo

de secuencias de traza ayudan a realizar transformaciones directas entre elementos del mismo tipo

definidos en diferentes niveles de abstracción. Por ejemplo, Interfaces usadas por una Class

pueden ser transformadas a partir de un vínculo de trazado proporcionando información desde las

operaciones que son parte de la Class.

(Interface<<trace>>Collaboration) <<realize>> (UseCase<<trace>>Class)

Interface<<realize>>Class

(8)

La Figura 32 muestra una instancia de un modelo de trazado basado en casos de uso para el sistema

Auction System, subsistema Buy Goods, versión 1.0.0. Este muestra los elementos principales que

permiten definir las secuencias de traza que garantiza la completitud y consistencia del modelo

cuando se hacen cambios en los modelos de desarrollo o en las mismas instancias del modelo de

trazado.

La Figura 32 muestra dos instancias de secuencias de trazado que facilitan las tareas de verificación

cuando se hace un cambio. En la Expresión (9) Activity traza a UseCase y este realiza al

BusinessProcess, entonces, la Activity refina el BusinessProcess. En la Expresión (10) se

usa la ley asociativa para lograr una traza directa entre los elementos Class y Activity. En estas

secuencias de traza el UseCase lidera las transformaciones de modelos con responsabilidades de

verificación.

Activity::BuyGoods<<trace>>UseCase::BuyGoods<refine>>BusinessProcess:BuyGoods

Activity::BuyGoods<<refine>>BusinessProcess::BuyGoods (9)


120

(Class::BuyGoods-Bids<<trace>>UseCase::BuyGoods) ∧ (Activity:: BuyGoods<<trace>>UseCase::BuyGoods)

Class::BuyGoods-Bids<<trace>>Activity::BuyGoods

(10)

Figura 32. Modelo de trazado basado en casos de uso, Auction System, subsistema Buy Goods, version 1.0.0.

La Tabla 7 muestra otras secuencias de traza.

Tabla 7. Otras secuencias de traza definidas para el Modelo de Trazado basado en Casos de Uso.

Id sequenceInitial sequenceFinal Transformation Rule

1 UseCase<<refine>>Requirement<<trace>>Class(Domain Model)

UseCase<<refine>>Class(Domain Model)

-

2 UseCase<<refine>>Requirement<<trace>>Activity(Bussines Process)

UseCase<<refine>>Activity(Business Process)

ActivityBP2UseCase

3 Activity<<trace>>UseCase<<refine>>Activity(BusinessProcess)

Activity<<refine>>Activity(BusinessProcess)

ActivityBP2Activity

4 (Class(Domain Model)<<trace>>Requirement

<<trace>>Activity(BusinessProcess) Class(Domain Model) <<trace>>Activity(Business Process)

ActivityBP2ClassDM or ClassDM2ActivityBP

5 Class<<trace>>UseCase<<refine>>Class(Domain Model)

Class<<refine>>Class(DomainModel) ClassDM2Class

6 (Activity<<trace>>UseCase) and (Class<<trace>>UseCase)

Class<<trace>>Activity or Activity<<trace>>Class

Activity2Class or Class2Activity

7 Collaboration<<realize>>UseCase<<refine>>Requirement

Collaboration<<realize>>Requirement

Requirement2Collaboration

8 Collaboration<<realize>>UseCase<<trace>>Activity

Collaboration<<realize>>Activity Activity2Collaboration

9 Collaboration<<realize>>UseCase<<trace>>ClassModel

Collaboration<<realize>>ClassModel .

10 Componet<<trace>>Collaboration<<realize>>ClassModel

Component<<realize>>ClassModel ClassModel2Component

11 Component<<realize>>ClassModel<<trace>>Class Component<<realize>>Class Class2Component 12 (Interface<<trace>>Collaboration) <<realize>>

(UseCase<<trace>>Class) Interface<<realize>>Class Class2Interface

... ... ... ...


121

Las secuencias de traza se complementan con “Trazas Implícitas”. Estas son tipos de vínculos de

trazado que se derivan de secuencias de traza formadas por elementos que son compuestos por otros

elementos. Por ejemplo el clasificador Class está compuesto por los elementos Property y

Operation (ver Tabla 3).

La Tabla 8 define las trazas implícitas que se derivan de las secuencias de traza de Class.

Tabla 8. Trazas implícitas para Operation que es parte del elemento Class.

idSeq Trace Transformation Rule 1 <<axisTracing>>Analysis::UC{basicFlow}<<realize>>

<<predecessor>>Requirement::Operation(DM) OperationDM2basicFlow

5 <<axisTracing>>Analysis::Operation(CM)<<realize>> <<predecessor>>Requirement::Operation(DM)

OperationDM2OperationCM

6 <<axisTracing>>Analysis::Class<<trace>> <<axisTracing>> Analysis::ObjectNode

ObjectNode2Class

12 <<successor>>Design::Interface<<realize>><<axisTracing>> Analysis:: Operation

Operation2Interface

Las trazas implícitas están asociadas a regla de transformación tipo subordinada o complementaria

(estos y otros tipos de reglas de transformación se describen en el Capítulo 4). Por ejemplo,

Operation2Interface cuya regla padre es Class2Interface la cual a su vez puede estar

relacionada a la traza Interface<<realize>>Class. La Tabla 9 muestra otras secuencias de traza y

las instancias para el objetivo Sell Goods.

Tabla 9. Instancias de secuencias de traza con y sin trazas implícitas.

Trace Sequence Instances Class(class model)<<trace>>UseCase<<refine>>Class(Domain Model)) Class(Class model)<<refine>>Class(Domain

Model)

<<refine>> (Analysis::Package::Class:: Class::Sell Goods | Auction, Requirement::Package::Class(Domain Model):: ClassDM::Sell Goods | Auction) <<refine>> (Analysis::Class:: Seller, Requirement::Class(Domain Model):: Seller) <<refine>> (Analysis::Class:: Goods, Requirement::Class(Domain Model):: Goods)

Activity<<trace>>UseCase<<refine>>Activity(BusinessProcess) Activity

<<refine>>Activity(BusinessProcess)

<<refine>> (<<axisTracing>>Analysis::Activity:: Sell Goods, <<predecessor>>Requirement:: Activity(BusinessProcess):: Sell Goods) Traza implícita: <<refine>> (<<axisTracing>>Analysis::Activity::Lane:: Sell Goods|Jugde, <<axisTracing>>Requirement::ActivityBP::Swimline:: Goods|Jugde) ...

Capítulo 3.El Patrón de Trazabilidad Discusión

122

Advertencia: Aunque cualquier secuencia debe estar asociada con una regla de transformación no

todas son ejecutadas necesariamente. Cuando el elemento destino ya existe y no necesita ser

actualizado entonces la secuencia sólo se usa para verificar consistencia y completitud durante el

proceso. También, en algunos casos sólo se necesitan para generar nuevas secuencias. Por ejemplo,

en la Tabla 7, línea 1, columna sequenceEnd, hay una secuencia de traza que no tiene que ver con

ninguna la regla de transformación, esta es usada en la línea 5 para construir una nueva secuencia de

traza.

3.6 Discusión

El Patrón de Trazabilidad definido en este capítulo provee una estructura definida al nivel de

metamodelo para soporta el marco de trabajo conceptual en el contexto del desarrollo dirigido por

modelos. Con base en este se logra controlar las transformaciones de los modelos desde modelos de

trazado que garantizan la consistencia y la completitud de los modelos durante el proceso de

desarrollo. En esta sección, se discuten algunas cuestiones que se identificaron durante la aplicación

de los modelos de trazado.

Estandarización de los Modelos de Trazado. Los modelos de trazado estandarizan la práctica de

la trazabilidad como un mecanismo de control de las transformaciones de modelos realizados o no

en UML, desde las etapas tempranas del proceso de desarrollo. Sin embargo, para mantener estos

modelos es requerido que la industria de software adopte criterios de calidad basados en los

modelos de trazado para obtener servicios de gestión de la configuración durante la transformación

de los modelos.

Por ejemplo, si el clasificador Class se define como el líder del eje del trazado en el nivel de

Análisis, entonces los líderes del trazado en los predecesores sucesores deben de cambiar a ser el

modelo del dominio en el nivel de requisitos y el componente o interfaz en el nivel de diseño. Otros

elementos como UseCase o Activity se pueden conservar como ejes del trazado. Aunque el

cambio de la coordinación de la traza es sutil, otras características de configuración del modelo de

trazado podrían cambiar. Por ejemplo, es posible no definir elementos con el rol de predecesor, y

los ejes de trazado son la fuente de transformación durante el proceso; por lo tanto, los esfuerzos de

transformación son menores ya que las alternativas de transformación son limitadas. Igualmente, el

impacto del cambio y la propagación de cambio serían dirigidos principalmente por medio de

elementos modelos estructurales.

La estandarización de los modelos de trazado remontar implica también decisiones sobre las

alternativas de modelado que deben ser adoptadas por el equipo de desarrollo ya que hay estilos o


123

tendencias del modelado diferentes entre desarrolladores principalmente por los tipos de proyecto

de software que se realizan. Por ejemplo, un caso común es el hecho que un caso de uso puede ser

trazado a varias clases (o viceversa), en el nivel modelo. Así, un modelo de trazado basado en el

caso de uso obedece a esto; sin embargo es necesario definir claramente las alternativas de

transformación relacionada con esta traza.

Varias alternativas de modelado implican tanto validación como tareas de ajuste para mejorar los

criterios de modelado y conseguir modelos destino confiables. Cuando el equipo de desarrollo usa

un proceso de desarrollo iterativo e incremental, esta práctica puede ser sana para minimizar el

número de defectos desde las etapas tempranas. Sin embargo, en algunos casos esta práctica puede

ser vista como compleja cuando las transformaciones hechas desde los modelos de Requisitos o

CIMs ya que casi siempre son tratados informalmente.

La adopción de Modelos de Trazado en un proceso de desarrollo normal (no MDD) es de tipo

metodológico ya que en la industria del software usa instrumentos de modelado comerciales cuyo

nivel de transformación es limitado para transformar diagramas de clase de PIM a PSM.

Consistencia y Completitud. Un modelo de trazado garantiza que los modelos de desarrollo estén

siempre consistentes y completos. Sin embargo, los equipos de desarrollo deben ser conscientes de

los elementos de modelo que deben ser considerados para conservar estos atributos de calidad en

los modelos de desarrollo y alcanzar beneficios con otros servicios de la gestión de la

configuración.

Por ejemplo, cuando el equipo de desarrollo que modela los procesos del negocio por medio de los

diagramas de Actividades con la notación BMPN (http: // www.bpmn.org/Documents/) estos deben

identificar y entender el uso de cada elemento de modelo del negocio para definir un modelo de

trazado apropiado. Por ejemplo, una función de un proceso (representado por un nodo de acción)

podría ser trazada a varios requisitos o pasos del flujo básicos en un caso de uso, un objeto de

acción podría ser trazado a clases en el modelo del dominio, y un subproceso (representado por un

CallBehaviorAction) podría ser trazado a un caso de uso base u otros como casos de uso

included/extend, etc.

Por lo tanto, las funciones operaracionalizables del proceso del negocio en el nivel de requisitos

pueden ser trazadas a diagramas de actividades u otros elementos modelos en el espacio de

solución. Conociendo estas trazas, el equipo de desarrollo puede definir un modelo de trazado

donde el modelo de procesos del negocio es básico para conseguir la consistencia y la completitud.


124

Otra cuestión que debe ser analizada es la definición de secuencias de traza. Aunque éstas sean

automáticamente generadas cuando un modelo de trazado se define como la plantilla de un proceso

de desarrollo, no todas ellas se aplican para verificar la consistencia y la completitud. Por lo tanto,

el equipo de desarrollo debe hacer una depuración de secuencias inútiles.

Integración de los Modelos de Trazado a Herramientas de Modelado. Aunque este capítulo

presente una estrategia de uso de los modelos de trazado, éstos deben ser integrados con

herramientas de modelado para facilitar su adopción y aplicación como una técnica de trazabilidad

y transformación de modelos. Además, el método de trazabilidad debe ser documentado de tal

modo que el modelo de trazado puede ser fácilmente usado durante un proceso de desarrollo.

Actualmente, la adopción de este acercamiento debe ser conceptual y metodológica a fin de

promover el uso de los modelos de trazado como estándares para controlar las transformaciones

intuitivas de los modelos que ahora son realizados por desarrolladores o equipos de calidad en

etapas tempranas del ciclo de vida.

Modelos de Desarrollo. La separación y jerarquía de modelos de desarrollo propuesta corresponde

a la sintaxis de los elementos de modelo definidos desde el patrón de trazabilidad. Los elementos de

los modelos y los modelos en si son únicos. Este enfoque se acerca a las prácticas de modelado en

los ambientes reales de desarrollo que usan el modelo UML. También estos obedecen a

características de modificabilidad que facilitan el control de las iteraciones en procesos de

desarrollo como el Proceso Unificado.

3.7 Trabajos Relacionados

En esta sección se analizan algunas fortalezas y debilidades del enfoque definido en este capítulo

con respecto a otros enfoques MDD que logran consistencia y completitud.

Al Nivel del Metamodelo. De los diferentes enfoques estudiados, AMPLE21 define un modelo de

trazabilidad con conceptos similares al patrón de trazabilidad propuesto en esta disertación [Galvão

et al. 2008]. No obstante, hay claras diferencias en cuanto a la definición y alcance de la

trazabilidad y los modelos propuestos. En la Tabla 14 se muestran las diferencias más

representativas.

21 www.ample-project.net

Capítulo 3.El Patrón de Trazabilidad Trabajos Relacionados

125

Tabla 10. Comparación entre Trazabilidad en AMPLE y el Patrón de Trazabilidad definido.

Característica AMPLE PATRÓN DE TRAZABILIDAD

Orientación general El metamodelo de trazabilidad de AMPLE está orientado a soportar la trazablidad de líneas de productos de software.

El patrón de trazabilidad está definido como metamodelo y tiene una orientación general, por lo tanto potencialmente aplicable en diferentes tipos de proyectos de software.

Objetivo del Metamodelo Proporcionar una estructura uniforme y reutilizable para definir modelos de traza (rastro) durante todas las fases del desarrollo de líneas de productos de software, basado en la transformación de modelos (MDD).

Este modelo puede garantizar consistencia y completitud pero no lo trata explícitamente desde el modelo de traza.

Proveer un marco de trabajo que facilite la creación de modelos de trazado (rastro) que controlen la transformación de los modelos de desarrollo garantizando su consistencia y la completitud.

Modelos de Traza Un modelo de traza almacena toda la información de trazabilidad de acuerdo a la correlación de un conjunto de artefactos de la fuente con un conjunto de artefactos destino, es decir dos conjuntos de artefactos trazables.

Se define como un contenedor de toda la información de trazabilidad relacionada con las relaciones entre los conjuntos de artefactos trazables. Por ejemplo, una instancia de esta metaclase puede ser un modelo de traza que contiene la información de trazabililidad relacionada con la correlación de un conjunto de requisitos en una arquitectura de software.

Los modelos de trazado son modelos abstractos compuestos por elementos trazables y vínculos de trazado que actúan como patrones para controlar la transformación de los modelos y garantizar su consistencia y completitud para diferentes tipos de proyectos de software.

Sus instancias son modelos de trazado versionados que reflejan una vista de la transformación de los modelos de acuerdo a los vínculos de trazado y las reglas de transformación asociadas a estos.

Elemento Trazable Un artefacto trazable en el repositorio puede desempeñar el rol del artefacto de la fuente y del destino al mismo tiempo. Por ejemplo, un artefacto arquitectónico podría ser un artefacto trazable del destino considerando la traza de los requisitos hacia la arquitectura, y dicho artefacto trazable del destino sería un artefacto de la fuente cuando se considera la traza de la arquitectura hacia la implementación.

Se define de forma abstracta cuando forma parte de un modelo de trazado. Un elemento trazable es un elemento que puede ser instanciado al nivel de los modelos de desarrollo.

En un modelo de trazado se definen elementos trazables que serán transformados para mantener la consistencia y la completitud de los modelos de desarrollo. Se definen en tres niveles de abstracción (Requistios, Análsis, y Diseño) asignándoles un rol que determina su responsablidad en la traza y determina la dirección básica en la cual se hace la transformación.

Vínculo de trazado Se definen dos tipos de vínculos de trazado:

Un TraceHyperLink abstrae la transición de un conjunto de artefactos de la fuente en otro conjunto de artefactos del destino.

Un TraceLink abstrae la transición de un conjunto de artefactos de la fuente en otro conjunto de artefactos del destino. Una instancia de esta metaclase representa un hiper vínculo dirigido que une dos juego de artefactos en el gráfico de rastro.

Además definen la metaclase TraceLinkType el cual permite definir el tipo de traza que se hace entre los elementos trazables.

Relaciones de abstracción y realización UML:

<<refine>>, <<realize>>, y <<trace>> con definición extendida para darle un significado estándar en los modelos de trazado.

Capítulo 3.El Patrón de Trazabilidad Trabajos Relacionados

126

Control de la Transformación de Modelos

No se aplica Provee un modelo de transformación asociado a los modelos de trazado.

Modelos de Traza para un proyecto de software

Un proyecto de software se compone de varios modelos de traza, que contiene vínculos de traza entre diferentes conjuntos de artefactos trazables, p.ej un modelo de traza para la correlación de requisitos en la arquitectura y otro modelo de traza para la correlación de la arquitectura en la implementación, otro modelo de traza para la correlación de requisitos en casos de prueba.

Se define o usa un modelo de trazado para un proyecto de software. Este define el refinamiento o la correlación entre los elementos que van a ser transformado.

Lenguaje de Soporte. El lenguaje ATL define: “La Semántica de Ejecución de Reglas Asociadas

donde la ejecución de una regla en un match adicional, crea un vínculo de trazabilidad en las

estructuras internas del motor de transformación. El algoritmo usa vínculos de trazabilidad para

identificar los elementos del destino creados desde un elemento de la fuente como resultado de la

aplicación de una regla de transformación”22. En otras palabras, un vínculo de traza ATL está

embebido en una regla de transformación simple por su definición. Por el contrario, los vínculos de

trazado definidos desde el patrón de trazabilidad están separados de las reglas de transformación

existiendo una asociación declarativa entre ellos. Al nivel del planeador de transformación se hace

una juntura temporal de ejecución. Así, la modificabilidad de un modelo de trazado es no invasiva

manteniendo la separación de los elementos.

Igualmente, el QVT provee vínculos de trazabilidad que pueden ser usados para determinar los

modelos destino que fueron creados por alguna otra regla y el uso del elemento como su propio

destino. En contraste con ATL los vínculos de trazado son instancias de la clase trace definida

independientemente de la relación de transformación.

Consistencia y Completitud. Estos atributos de calidad son tratados por otros enfoques dirigidos

por modelo que proponen modelos o metamodelos de trazabilidad que solucionan el problema de

interoperabilidad entre modelos heterogéneos o simplemente especifican la traza entre requisitos y

modelos en niveles de abstracción diferentes (usando matrices de trazabilidad) [Bondé 2005],

[Almeida 2006]. El patrón de trazabilidad proporciona la consistencia y la completitud como

servicios de los modelos de trazado aumentando la confiabilidad del modelo propuesto.

Sousa et al., presentan un enfoque de MDD que proporciona un mecanismo para hacer la

trazabildad desde el proceso del negocio hasta la interfaz de usuario para ayudar a analistas del

negocio en la predicción del impacto de cambios de proceso en la interacción de usuario y proponer

cambios de los procesos cuando la interacción de usuario es mejorada” [Sousa et al. 2008]. En

contraste, el patrón de trazabilidad proporciona la flexibilidad en la definición de los modelos de

22 www.eclipse.org/m2m/atl/

Capítulo 3.El Patrón de Trazabilidad Conclusiones

127

trazado y la transformación de modelos. Este ayuda al equipo de desarrollo a modelar el impacto de

cambios incluyendo otros elementos de modelo que serán la parte de actividades de modelado. Por

ejemplo, en el modelo de trazado basado en casos de uso (usado en el ejercicio), si el analista de

negocio considera necesario de incluir la interfaz de usuario como un eje de trazado, este será un

elemento con propiedades definidas para hacer las transformaciones con otros elementos.

3.8 Conclusiones

Este capítulo aplica directamente a la práctica de la trazabilidad en el contexto del desarrollo

dirigido por modelos. Para esto se definió un marco de trabajo conceptual soportado por el “Patrón

de Trazabilidad” el cual es un metamodelo que define la gestión de la trazabilidad por medio de

“Modelos de Trazado” abstractos. Estos modelos están compuestos por elementos trazables y

vínculos de trazado que controlan la transformación de los modelos de desarrollo garantizando su

consistencia y la completitud.

Específicamente, el Patrón de Trazabilidad:

Estandariza la práctica de la trazabilidad usando relaciones de abstracción y realización

UML como vínculos de trazado que tienen una función definida en los Modelo de Trazado.

Da un valor a los vínculos de trazado como controladores de la transformación en un

modelo de trazado. Aunque el modelo de transformación se define en el siguiente capítulo,

en este se muestra cómo los vínculos de trazado asocian reglas de transformación.

Proporciona la verificación de la consistencia y la completitud de los modelos de desarrollo

por medio de secuencias de traza que relacionan varios vínculos de trazado que por la ley

de transitividad se puedan lograr vínculos de trazado directos que provienen de jerarquías

de traza identificadas en los modelos de trazado.

Define el uso de las instancias de los modelos de trazado.

Los Modelos de Trazado se definen y tratan como artefactos de trazabilidad un marco conceptual

que estandarizan el uso de elementos de modelo como elementos trazables, relaciones de

dependencia como vínculos de trazado asociados a reglas de transformación. Por esta razón su uso y

adopción está orientado a las empresas desarrolladoras de software por medio de las herramientas

CASE que soporten la definición de modelos y las reglas de transformación por medio de perfiles, y

otros constructores o API por medio de los cuales se pueda implementar interfaces con el patrón de

trazabilidad.

Capítulo 3.El Patrón de Trazabilidad Conclusiones

128

El valor real de los Modelos de Trazado está en el concepto patrón de trazabilidad y control del

proceso de desarrollo. La práctica de la trazabilidad se aborta con facilidad por diferentes razones,

pero si ésta es conducida por este patrón que le de valor a los elementos trazables y cree un estilo de

trazabilidad desde diferentes puntos de vista para un proyecto, es posible que se le de mayor

continuidad e importancia o se adopte con mayor facilidad.

Todo artefacto software, independiente de su objetivo, debe tener un valor que ayude a cuantificar

el costo total del proyecto o de un cambio. Si la práctica de la trazabilidad no genera valor agregado

a la situación actual, donde realizarla es supremamente costoso, realmente ningún método serviría,

porque siempre sucedería lo mismo, “no se sabe cuanto vale No hacer trazabilidad”.