De los procesos de desarrollo a la definición de procesos
workflow
Daniel Romero1, Marcelo Uva1 1 Universidad Nacional de Río Cuarto
Ruta 36 – Km 601 CP X5804BYA - Tel/Fax: 54+358+4676235 {dromero, uva}@dc.exa.unrc.edu.ar
Abstract. El modelado de los procesos de negocio es de vital importancia en el desarrollo de toda industria, en particular, en la industria del software. La ingeniería y re-ingeniería de los procesos de negocio apuntan principalmente a elevar la calidad de los procesos de producción y consecuentemente, la de los productos desarrollados. Una de las formas de optimizar la producción es mediante la automatización de los procesos de negocio, lo que implica definir reglas de transición, recursos involucrados, responsables para cada actividad, etc. En el siguiente trabajo se propone una alternativa para el logro de la automatización de los procesos de desarrollo de software. Esta automatización, se obtiene luego de sucesivas transformaciones. Los procesos son modelados en SPEM (Software Process Engineering Metamodel) y luego de una secuencia de pasos, son transformados en procesos workflow.
Introducción
Un proceso de negocio es un conjunto de tareas lógicamente relacionadas, ejecutadas para obtener un cierto resultado de negocio. El modelado, análisis y administración de estos procesos, ha cobrado gran importancia ante la necesidad de una industria competitiva, dinámica, que se adapte rápidamente a los cambios, y donde se aprovechen al máximo los recursos disponibles. Toda esta situación ha provocado que uno de los objetivos principales de la industria actual sea la automatización de los procesos de producción.
Para el logro de este fin, se han venido utilizado tecnologías “Workflow”.
Se denomina workflow a la automatización parcial o total de un proceso de negocio. La WfMC (Workflow Management Coalition), es un conjunto de instituciones que se encarga de identificar áreas comunes de funcionalidad y de desarrollar especificaciones apropiadas para la implementación en productos workflow. Se pretende que esas especificaciones permitan la interoperabilidad entre productos heterogéneos y mejoren la integración de aplicaciones workflow con otros servicios IT tales como correo electrónico y administración de documentos.
Dentro de los estándares definidos por la WfMC, se encuentra la Interfaz 1 de definición de procesos workflow. Ésta define un formato de intercambio común para la transferencia de definiciones de procesos entre productos diferentes. Esto es realizado a través de un esquema XML (Extensible Markup Language) denominado
Lenguaje de Definición de Procesos XML (XML Process Definition Language - XPDL) [WFMC1025-2002].
La incorporación de tecnologías workflows permite automatizar los flujos de información que circulan a través de una determinada industria, posibilitando el secuenciamiento de las actividades y la optimización de los recursos.
El caso particular de la industria del desarrollo de software, no es diferente al del resto de las industrias. Dentro de ella, se encuentran los procesos de negocios tendientes a la construcción o generación de un producto (software) de calidad en un tiempo determinado. Actualmente, ingenieros de software trabajan para optimizar los procesos de desarrollo. Los procesos de negocios, dentro de la industria de desarrollo de software son conocidos como “metodologías de desarrollo”, encargadas de guiar la producción.
En este trabajo se propone la optimización del proceso de producción de software mediante la automatización de las metodologías de desarrollo. Para lograr este objetivo se realizaron los siguientes pasos:
Primero: Fue seleccionada una metodología de desarrollo de software para ser utilizada como caso de estudio en este trabajo. La metodología en cuestión es una instancia de la metodología RUP (Rational Unified Process) denominada SmallRUP, definida por Gary Pillice en su artículo “Using the RUP for small projects” [Pollice2003].
Segundo: Se utilizó el Metamodelo para la Ingeniería de Procesos de Software SPEM (Software Process Engineering Metamodel) definido por la OMG (Object
Management Group) para el modelado de procesos de desarrollo.
Tercero: Una vez especificado el proceso de desarrollo SmallRUP en SPEM, el paso siguiente fue la definición de un conjunto de reglas de transformación para convertir la especificación SPEM en una especificación XPDL (XML Process Definition
Language). Esta última, ya es una definición estándar de un proceso Workflow, por lo
que podrá ser ejecutada, como cualquier proceso automatizado, por un sistema workflow. Las reglas de transformación fueron definidas utilizando el lenguaje XSLT (XSL Transformations).
Este trabajo está organizado de la siguiente manera. En la sección 1 es presentado el caso de estudio SmallRUP. En la sección 2, se explican algunas características del metamodelo SPEM, y se muestra cómo es realizada la especificación de SmallRUP. La sección 3 muestra como es el proceso de transformación de una especificación SPEM a una definición de proceso workflow. Finalmente en la sección 4, las conclusiones.
1 Caso de estudio – SmallRUP
El caso de estudio utilizado es una instanciación particular del RUP (Rational Unified
Process - RUP) definida para pequeños proyectos [Pollice2003] denominada
SmallRUP. La elección del RUP se debió a que es una metodología que presenta buenas prácticas en el desarrollo de software moderno para una amplia gama de proyectos y organizaciones, está embebido en técnicas orientadas a objetos, utiliza
UML como notación principal, permite a organizaciones del software ajustar el proceso a su necesidad específica y cubre diferentes dominios particulares [Kruchten2002].
1.1 Ajustando el RUP para pequeños proyectos – SmallRUP
El Proceso Unificado Rational (Rational Unified Process - RUP) es una metodología de desarrollo de software orientada a objetos. El RUP mantiene pautas, plantillas, y ejemplos para todos los aspectos y fases de desarrollo del software. Además, establece cuatro fases de desarrollo, cada una de las cuales está organizada en iteraciones separadas que se van secuenciando a medida que se satisfacen determinados criterios.
Al ser el RUP un framework de procesos de desarrollo de software existen diversas formas en las que se lo puede instanciar, dependiendo de las características del proyecto. Una de estas variantes es “SmallRUP”.
1.2 Las cuatro fases del SmallRUP
SmallRUP posee cuatro fases de desarrollo. Fase de “Inicio”, ”Elaboración”, “Construcción” y “Transición”. Cada etapa determina un conjunto de actividades a desarrollar por un grupo de personas con determinados roles dentro del proyecto, por ej. Programador, Jefe de Programadores, etc. Como resultado, cada fase produce artefactos que serán utilizados por las fases subsecuentes.
En las Tablas 1, 2 3 y 4 se muestran las actividades de cada etapa con sus respectivos roles.
Tabla 1. Fase de Inicio, se identifican las características del proyecto, y su factibilidad.
Roles Actividades Artefacto
Administrador
del Proyecto Formular el alcance del proyecto Visión Plan de aceptación Administrador
del Proyecto Planificar y preparar los Casos de Uso de Negocio (CUN)
Modelo de Casos de Uso de Negocio
Lista de Riesgos
Modelo inicial de Casos de Uso de Sistema (CUS) Jefe de
Programadores Síntesis de la arquitectura candidate Bosquejo de la Arquitectura candidata Administrador
del Proyecto Preparar las condiciones del proyecto
Plan de proyecto preliminar Plan para empezar fase de elaboración
Tabla 2. Fase de Elaboración, se obtiene un delineamiento de la arquitectura del sistema.
Jefe de Programadore s
Definir, validar y delinear la arquitectura
Documentación de la arquitectura del software (SAD)
Administrador
del Proyecto Refinar la visión CUS y Lista de Riesgos (Actualizados) Administrador
del Proyecto
Crear y delinear el plan de iteración para la fase de construcción
Plan de iteración para la fase de construcción
Programador Iniciar el desarrollo Código Fuente V1.0 Jefe de
Programadore
s Crear el entorno de testeo Código de Testeo V1.0
Tabla 3. Fase de Construcción, el objetivo principal de esta etapa es completar el desarrollo del sistema.
Roles Actividades Artefacto
Administrador
del Proyecto Administrar los recursos y los procesos de control Planificación Programador Desarrollar componentes y testear los Componentes Administrador
del Proyecto Evaluar la iteración Plan de Iteración para la fase de Transición Tabla 4. Fase de Transición, se asegura que el software este disponible para el usuario final.
Roles Actividades Artefacto
Programador Finalizar los materiales de soporte para el usuario Plan de Despliegue Manual del Usuario Cliente Testear el producto entregado en el entorno del cliente Lista de Issues Programador Ajustar el producto sobre el feedback del cliente Producto final Administrador
del Proyecto Entregar el producto final
2 Especificación de los procesos de desarrollo
Para especificar las actividades propuestas por un proceso de desarrollo utilizamos el metamodelo definido por la OMG para la descripción de procesos de desarrollo denominado SPEM. En el SPEM se especifica cómo manipular los modelos utilizando XMI (XML Metadata Interchange). Se pretende con esto, obtener la especificación de nuestro proceso de desarrollo en un formato que sea posible de manipular.
2.1 Metamodelo para la Ingeniería de Procesos de Software - SPEM
El nacimiento del Proceso Unificado (Unified Process - UP) y del Lenguaje Unificado de Modelado (Unified Modeling Language -UML) a finales de 1990 produjo un cambio fundamental en la industria del desarrollo de software. Existen actualmente muchas variantes del UP que son utilizadas por todo el mundo. Esto provocó la necesidad de un estándar unificado en esta área, debido a que al existir diferentes técnicas de modelado de procesos, se utilizaban diferentes terminologías e incluso diferentes significados para las mismas palabras.
En reconocimiento a esta necesidad, la OMG definió el Metamodelo para la Ingeniería de Procesos de Software SPEM (Software Process Engineering
Metamodel).
SPEM es un metamodelo utilizado para describir procesos de desarrollo de software concretos o una familia de procesos de desarrollo de software relacionados.
El metamodelo SPEM permite abstraerse de las características particulares de cada proceso de desarrollo, dando la posibilidad de definir distintos procesos de desarrollo de software.
SPEM ofrece un framework para el modelado de procesos de desarrollo de software y sus componentes, dando una sintaxis y una estructura común para cada aspecto del proceso de desarrollo, incluyendo: roles, tareas, artefactos, lista de chequeo. El SPEM usa UML como notación [SPEMv1.0].
Estructura de Paquetes de SPEM
El metamodelo SPEM es construido extendiendo un subconjunto del metamodelo UML 1.4 el cual, es encapsulado en un paquete denominado SPEM_Foundation (figura 1).
El paquete SPEM_Foundation describe la estructura estática del modelo y hereda de los siguientes paquetes de UML 1.4: Data_Types, Core, Actions, State_Machines,
Activities_Graphs, Model_Managements [UML1.4]. SPEM_Foundation
SPEM_Extensions
Fig. 1. Paquetes SPEM_Foundation y SPEM_Extensions
El paquete SPEM_Extensions incorpora los constructores y la semántica propia para la ingeniería de procesos de desarrollo de software. El paquete SPEM_Extensions está compuesto por los siguientes subpaquetes: BasicElements, Dependencies,
BasicElements: Define los elementos básicos para la descripción de los procesos.
Dependencies: Define las dependencias entre los componentes. Se definen como
subclases de las clases del paquete SPEM_Foundation.
ProcessStructure: Define la estructura de los elementos.
ProcessComponents: Permite la división de una o más descripciones de procesos en
partes autocontenidas.
ProcessLifecycle: Incorpora los elementos de definición de procesos que ayudan a
definir la ejecución de los procesos.
2.2 Re-escribiendo SmallRUP con SPEM
El objetivo de esta sección es mostrar como se puede especificar un proceso de desarrollo utilizando el SPEM. Esto implica dar una instanciación de las clases de este metamodelo que se correspondan con el proceso de desarrollo que se quiere especificar.
Con las clases del SPEM definiremos nuestro modelo de objetos del proceso de desarrollo, y lo representaremos mediante la utilización de XMI, es decir, obtendremos un documento XMI que contiene el modelo de objetos que representa al SmallRUP en el SPEM.
Daremos primero un maping y un ejemplo entre las terminologías del SmallRUP y el SPEM para detectar que clases del SPEM corresponde con cada componente del SmallRUP, y luego como se definieron las dependencias entre actividades mediante la utilización de un diagrama de actividades como un caso particular del un diagrama de estados.
Tabla 5. Maping entre las terminologías del SmallRUP y el SPEM.
SmallRUP SPEM Ejemplo
Roles ProcessRoles Chief Programmer
Actividad Activity Síntesis de la arquitectura candidata Artefacto WorkProduct Arquitectura preliminar
Disciplina Discipline Captura de requisitos
Fase Phase Fase de Inicio
Iteración Iteration Primera Iteración
En la figura 2 se muestra como se define en el SPEM para una actividad, quienes participan, el artefacto que se produce y el tipo de este artefacto.
Por último, la figura 3 muestra la forma en la cual se construye el diagrama de objetos que corresponde a la dependencia entre actividades. Para ello se define un diagrama de actividad mediante un diagrama de estados, en donde se tienen estados de acción (ActionState) asociados a una actividad (Activity) por medio de la operación de la acción de entrada (CallAction) de ese estado.
De esta manera se pueden obtener todos los objetos que formarán nuestro modelo de objetos del SmallRUP. El paso siguiente es serializar este modelo utilizando XMI (XML Metadata Interchange).
Summary of Candidate Architecture : Activity ChiefProgrammer : ProcessRole
: ActivityParameter
UML Diagram : WorkProductKind Draf Architecture : WorkProduct
Iteration 1, Inception Phase : Iteration subWork parentWork behaviorallFeacture parameters activity assistant responsibleRole workProduct type kind
Fig. 2. Diagrama de Objeto: Actividades, roles y artefactos
To refine the vision :
Activity To create, and to delineate the iterationplan for the construction phase : Activity : CallAction : ActionState : CallAction : ActionState : Transition operation operation entry entry source target outgoing incoming
Figura 3. Dependencia de Actividades y Diagrama de Objeto
2.3 Serialización
El SPEM especifica cómo manipular los modelos utilizando XMI (XML Metadata
Interchange). Con esto se pretende obtener la especificación de nuestro proceso de
desarrollo en un formato que sea factible de manipular para luego transformarlo en la entrada de un motor workflow.
El principal propósito de la norma XMI propuesta por el OMG, es facilitar el intercambio de metadatos en entornos distribuidos heterogéneos, entre diferentes tipos de herramientas software y, en especial, entre herramientas de modelado basadas en UML y repositorios de metadatos basados en la propuesta MOF (Meta-Object
Facility). XMI permite que los metadatos puedan ser intercambiados como flujos o
archivos con un formato estándar basado en XML.
El proceso de producción de documentos XMI está definido como un conjunto de reglas, donde estas reglas son aplicadas a un modelo y se obtiene como resultado un documento XML. La inversa de estas reglas pueden ser aplicadas para reconstruir el modelo original. En ambos casos, las reglas son empleadas en el contexto del metamodelo para el metadato que está siendo intercambiado. La producción de XML esta representada en la forma Backus-Naur extendida EBNF (Extended Backus Naur
Form) [XMIv2.0].
3 Automatización de los procesos de desarrollo
La producción del software se realiza a través de la ejecución de un proyecto de desarrollo de software guiado por una metodología de desarrollo. Para su automatización se deberá definir, dentro de un proceso workflow, las actividades propuestas por la metodología.
Para poder intercambiar la definición de las actividades al motor workflow es preciso re-escribirlas en el lenguaje XPDL, y como la especificación de procesos de desarrollo de software está definida en XMI, bastará con definir las reglas de transformación necesarias para convertir un documento XMI en uno XPDL.
3.1 Workflow
Un workflow se define como la automatización total o parcial de un proceso de negocio, durante la cual documentos, información o tareas son intercambiadas entre los participantes conforme a un conjunto de reglas procedimentales preestablecidas [Allen2001].
Un workflow comprende un número de pasos lógicos, conocidos como actividades. Una actividad puede involucrar la interacción manual o automática con el usuario. Un motor workflow es un sistema de software que controla la ejecución de las actividades definidas en el workflow. La WfMC ha definido un Modelo de Referencia Workflow (Workflow Reference Model) [WFMC1003-1995]. Este modelo define 5 interfases para la interoperabilidad de diferentes productos con un motor workflow. La interfaz 1 especifica el formato de intercambio común para soportar la transferencia de definiciones de procesos entre productos diferentes, utilizando un Lenguaje de definición de Procesos (XML Process Definition Language - XPDL) [WFMC1025-2002].
El Lenguaje XPDL permite escribir especificaciones de procesos workflow de manera estandarizada. Esto significa que cualquier definición de proceso que cumpla con todos los requisitos establecidos en la interfaz 1 podrá ser tomada como entrada por cualquier motor workflow que respete el estándar establecido por la WfMC.
El metamodelo workflow está compuesto por entidades y relaciones. Las entidades principales del metamodelo Workflow son las siguientes:
Transition Information: Describe las transiciones entre actividades y las condiciones
que la habilitan o inhabilitan, durante la ejecución del workflow.
Workflow Participant Specification: Representa los participantes intervinientes en una
actividad. Puede ser un “rol”, un “humano”, u “otro sistema”.
Workflow Application Declaration: Es representada como una lista de las aplicaciones
o herramientas requeridas por el proceso workflow.
Workflow Relevant Data: Representa a la información que circula dentro de un
proceso workflow.
3.2 Workflow aplicado al Proceso de desarrollo
Workflow es una tecnología de información que puede contribuir al logro de los objetivos del proceso de desarrollo y al mejoramiento de sus resultados mediante la administración efectiva de las actividades que componen sus diferentes procesos por parte de los propios participantes. Un proceso de software consiste en un conjunto de actividades concurrentes y cooperativas, que tienen que ver con el desarrollo y mantenimiento de software, así como con la gestión del proyecto y la calidad del producto. Por lo tanto, un proceso de software puede verse como un caso particular de proceso, y puede aplicarse la tecnología de workflow para dar soporte al proceso de desarrollo de software [Acuña2000].
3.3 Definición de reglas de transformación
En la sección 2 se mostró como un proceso de desarrollo puede ser instanciado en SPEM, y como se puede representar en un documento XMI, el paso siguiente es transformar este documento en un documento XPDL. Para realizar esta transformación se utilizó XSLT (Transformaciones XSL - XSL Transformations) [XSLTv1.0], un lenguaje para transformar documentos XML en otros documentos XML, mediante definiciones de reglas de transformación.
Para la construcción de las reglas de transformación se establecieron asociaciones entre las clases del metamodelo SPEM y las entidades de la especificación XPDL. Las reglas de transformación definidas son independientes del proceso o instancia utilizada, dando así una forma general de transformación entre objetos del SPEM y entidades del XPDL.
Las reglas de transformación generadas, fueron aplicadas al caso de estudio SmallRUP.
A continuación se mostrarán algunas de las correspondencias entre entidades del metamodelo Workflow (XPDL) y clases de SPEM.
XPDL.TypeDeclaration: Los tipos de datos utilizados son los tipos que pueden tener
los artefactos producidos, SPEM:WorkProductKind. Ejemplo: “UML Diagram”.
XPDL.Application: A cada tipo de artefacto producido (SPEM:WorkProductKind), se
asoció un tipo de aplicación. Ejemplo: a un “UML Diagram” se asoció un “UML
XPDL.Activity: SPEM:Activity definen las actividades de tipo implementación del
XPDL, las actividades de tipo JOIN o FORK son definidas mediante
SPEM.PseudoState.
XPDL.DataField: Son los artefactos producidos, SPEM:WorkProduct. Ejemplo: el
artefacto “Model of business use case”.
XPDL.WorkFlowProcess: SPEM:Process, El “SmallRUP” define el WorkFlowProcess del XPDL.
XPDL.Transition: SPEM:Transition, cada transición definida en nuestro diagrama de
actividad se corresponde con las transiciones de las actividades en el XPDL.
XPDL.Participant: Los distintos roles que participan en el RUP, SPEM:Role.
Ejemplo: “Project Manager”.
Código de ejemplo correspondiente a la regla de transformación XSLT de la clase
SPEM:ProcessRole. <xsl:template name="xpdl_participants"> <xsl:text disable-output-escaping="yes"> <Participants></xsl:text> <xsl:for-each select="//SPEM.ProcessRole"> <xsl:text disable-output-escaping="yes"> <Participant Id="</xsl:text> <xsl:value-of select="@xmi.id"/> <xsl:text disable-output-escaping="yes"> " Name="</xsl:text> <xsl:value-of select="@name"/> <xsl:text disable-output-escaping="yes">"> <ParticipantType Type="ROLE" /> <Description> </xsl:text> <xsl:value-of select="@name"/> <xsl:text disable-output-escaping="yes"> </Description> </Participant> </xsl:text> </xsl:for-each> <xsl:text disable-output-escaping="yes"> </Participants></xsl:text> </xsl:template>
De esta manera se construyeron las reglas de transformación que se aplican a un modelo de objetos correspondiente a un proceso de desarrollo especificado en el SPEM en formato XMI.
3.4 Generando el documento XPDL
Una vez definidas las reglas de transformación, el paso siguiente es aplicar a la especificación del proceso de desarrollo en SPEM–XMI de éstas, reglas para generar la definición de procesos workflow en XPDL.
En la figura 4 se muestra la secuencia completa de los pasos de transformación.
Figura 4. Secuencia de transformaciones
4 Conclusión
Ante la competencia, eficiencia y velocidad que requiere actualmente el mercado globalizado, la automatización de los procesos de negocio dentro de la industria ocupa un lugar fundamental. El correcto desarrollo de las actividades, buen uso de los recursos, exigencias en cuanto a la producción y al control son puntos vitales para toda industria. El desarrollo del software no es ajeno a estos conceptos, y es por ello que existen varias líneas de investigación estudiando como colaborar en su automatización.
A la necesidad de automatización también se debe sumar la necesidad de la utilización de estándares para lograr un mejor entendimiento e integración con las demás tecnologías. Dos grandes estándares se utilizaron en este trabajo; el metamodelo para la descripción de procesos de software definido por la OMG denominado SPEM, y la especificación workflow definida por la WfMC.
En este trabajo lo que se presentó una alternativa que permite la automatización de un proceso de desarrollo de software (SmallRUP). Las ventajas que conllevan la automatización de un proceso de desarrollo de software son las siguientes:
Con respecto a la construcción del software: Se considera que el proceso de transformación optimiza la construcción del software debido a que se dispone de un sistema automatizado (motor workflow) que administrará los recursos y organizará a un equipo de ingenieros de software en el transcurso del desarrollo de un proyecto en particular. El proceso de desarrollo adopta todas las ventajas propias de un proceso
workflow, como son la ejecución y simulación del proceso, el rediseño buscando un modelo más óptimo, entre otras.
Con respecto a la independencia de las reglas de transformación: La utilización de un caso de estudio para este trabajo nos permitió aplicar las reglas de transformación en un caso concreto, lo que no limita la extrapolación de éstas reglas a otras metodologías de desarrollo, debido a que las reglas no hacen referencia a las particularidades de un proceso, sino que trabajan con las clases del metamodelo SPEM. La definición de las reglas de transformación de documentos XMI a XPDL fue construida de manera independiente al proceso de desarrollo sobre el cual puede aplicarse.
Con respecto a la interacción de diferentes herramientas: La utilización de estándares SPEM, XMI, XSLT, XPDL adoptados por organizaciones como OMG, WfMC, W3C y a escala mundial, por la comunidad informática, ofrece una mejor comprensión del trabajo y flexibilidad para futuras extensiones.
Referencias
[Acuña2000] Silvia Teresita Acuña, “La tecnología de workflow como soporte para la formalización de proceso software integral”, Anales de las Jornadas Universitarias sobre Computación de Santiago del Estero (JUCSE 2000); 5-6 de Octubre de 2000. Santiago del Estero, Argentina.
[Allen2001] Rob Allen, Open Image Systems Inc., United Kingdom Chair, WfMC External Relations Committee; “The Workflow Handbook 2001”; Workflow Management Coalition; Octubre de 2001.
[Kruchten2002] Philippe Kruchten; “Introduction to the Rational Unified Process”; 24th International Conference on Software Engineering; IEEE; 19 al 25 de Mayo de 2002; Orlando, Florida.
[Pollice2003] Gary Pollice – “Using the RUP for small projects: Expanding upon Extreme Programming”, A Rational Software White Paper – 17 de junio 2003.
[SPEMv1.0] Object Management Group; “Software Process Engineering Metamodel Specification”; An Adopted Specification of the Object Management Group, Inc; Version 1.0 formal/02-11-14; Noviembre de 2002.
[UMLv1.4] Object Management Group; “OMG Unified Modeling Language Specification”; An Adopted Specification of the Object Management Group, Inc; Version 1.5 formal/03-03-01; Marzo de 2003.
[WFMC1003-1995] Workflow Management Coalition; “The Workflow Reference Modelo”. The Workflow Management Coalition Specification; WFMC-TC-1003 Version 1.1 Issue; Enero de 1995.
[WFMC1025-2002] Workflow Management Coalition; “Workflow Process Definition Interface, XML Process Definition Language”. The Workflow Management Coalition Specification; WFMC-TC-1025 Version 1.0 Final Draft; Octubre de 2002.
[XMIv2.0] Object Management Group; “XML Metadata Interchange (XMI) Specification”; An Adopted Specification of the Object Management Group, Inc; Versión 2.0; Mayo 2003. [XSLTv1.0] Word Wide Web Consortiun; “XSL Transformations (XSLT)”; Version 1.0; 19 de
