MDE: Ingeniería dirigida por modelos. Otra forma de...

MDE: Ingeniería dirigida por modelos.Otra forma de construir software

Dr. Juan Manuel Cueva LovelleDra. B. Cristina Pelayo García-Bustelo

Departamento de Informática

Universidad de Oviedo

Universidad Distrital Francisco José de CaldasBogotá, Noviembre de 2008

Introducción

Estado del Arte

Desarrollo ágil conMDA

Conclusiones

Referencias

MDEContenidos

1 Introducción

2 Base teórica y Estado del Arte

3 Desarrollo ágil con MDA

4 Conclusiones

5 Referencias

Introducción

ResumenPlanteamiento delproblema

Estado del Arte


Conclusiones

Referencias

MDEContenidos

1 IntroducciónResumenPlanteamiento del problema



4 Conclusiones

5 Referencias

Introducción


Estado del Arte


Conclusiones

Referencias

MDEResumen

El Desarrollo de Software Dirigido por Modelos(DSDM) es una propuesta para la construcción desoftware en la que se le atribuye a los modelos el papelprincipal de todo el proceso, frente a las propuestastradicionales basadas en lenguajes de programación,plataformas de objetos y componentes software.

Introducción


Estado del Arte


Conclusiones

Referencias

MDEResumen

DSDM persigue elevar el nivel de abstracción en eldesarrollo de software, convirtiendo a los modelos y alas transformaciones entre ellos en los principalesartefactos de todas las fases del proceso de desarrollode software: captura y gestión de los requisitos, diseño,análisis, implementación, despliegue, con�guración,mantenimiento, evolución, etc. [BBC+06]

Introducción


Estado del Arte


Conclusiones

Referencias

MDEResumen

El éxito de esta iniciativa ha originado la evolución dedistintos paradigmas englobados dentro del contextodel DSDM, como por ejemplo:

la iniciativa MDA (Model Driven Architecture) de laOMGlas técnicas de Agile Model-Driven Development(AMDD)las propuestas de Domain Speci�c Modeling (DSM)las estrategias de Domain-Oriented Programming(DOP)las Software Factories (SF)

Cada una de ellas aborda el proceso de DSDM dediferente forma, y con distintos mecanismos.

Introducción


Estado del Arte


Conclusiones

Referencias

MDEResumen

En particular, la iniciativa MDA cubre un amplioespectro de áreas de investigación:

metamodelos basados en MOFper�les UMLtransformaciones de modelos y de�nición de lenguajesde transformación (QVT)construcción de modelos PIM y PSM ytransformaciones de PIM a PSMconstrucción de herramientas de soporteaplicación en métodos de desarrollo y en dominiosespecí�cos

Algunos de estos aspectos están bien fundamentados yse están empezando a aplicar, otros sin embargo estántodavía en fase inicial

Introducción


Estado del Arte


Conclusiones

Referencias

MDEResumen

MDE es el acrónimo de Model Driven Engineering(Ingeniería Dirigida por Modelos) y hace referencia aluso sistemático de modelos, como los elementosprincipales en la ingeniería de software, durante el ciclode vida completo del proyecto [Sch06]

Concibe al desarrollo de software bajo la idea centralde que los artefactos fundamentales son los modelos (yno los programas)

Implica la generación automática de programas a partirde modelos. Model Driven Engineering (MDE) es unaforma genérica de de�nir el DSDM y los MDA

Introducción


Estado del Arte


Conclusiones

Referencias

MDEResumen

El principal objetivo del MDE es bajar el coste ymejorar la calidad de las inversiones en software.Las soluciones que aportan este tipo de modelos son:

Separar los aspectos del dominio de los aspectos de latecnologíaEl conocimiento queda registrado en los modelos y lastransformaciones y puede ser rehusadoSe automatizan partes signi�cantes del procesoImplementación de componentes usables por otraspartes

Introducción


Estado del Arte


Conclusiones

Referencias

MDEContenidos

1 IntroducciónResumenPlanteamiento del problema

Introducción


Estado del Arte


Conclusiones

Referencias

MDEPlanteamiento del problema

En la sociedad actual:

Demanda del Software ⇑ y el coste ⇑Se intenta aumentar la productividad:

⇑ nivel de abstracción⇑ nivel de reutilización

Premisa

¾Cómo aumentar la productividad en la construcción de

software a través del aumento de la abstracción y el

aumento del nivel de reutilización?

Introducción


Estado del Arte


Conclusiones

Referencias


La iniciativa Model Driven Architecture (MDA)Es una iniciativa del Object Management Group (OMG)

Planteamiento de los MDA's

El proceso de crear software debería ser dirigido por laformulación de MODELOS en lugar de por la escrituramanual de código fuente.

Con ello se conseguiría: ⇑ nivel de abstracción + ⇑ nivel dereutilización + Interoperabilidad

Introducción


Estado del Arte


Conclusiones

Referencias


La iniciativa Model Driven Architecture (MDA)Los modelos de MDA [RFW+04] representaran todos losaspectos del programa �nal ejecutable, por tanto deben ser:

formales

precisos

semántica bien de�nida

Deben conseguir un nivel de abstracción que permita surealización en múltiples plataformas [MRM03]

Transformación [KWB03]

El proceso de transformar una especi�cación software en unprograma ejecutable será automático, por tanto el códigofuente de las aplicaciones se debería generar a partir de losmodelos en un proceso de transformación

Introducción


Estado del Arte


Conclusiones

Referencias


Desarrollo ágil de softwareDe�ne nuevas metodologías para afrontar el desarrollo delsoftware de una forma más e�ciente, y por tanto menoscostosa [Lar03]

Los métodos ligeros asumen el cambio como algo inevitabley están centrados en el código, que será la principaldocumentación del proyecto.Los métodos ágiles suponen procesos y relaciones con elcliente y su mantenimiento, no código.

Modelos ejecutables [Amb04]

Si asumimos que un modelo ejecutable es código, se puedenaplicar los principios ágiles a la construcción de modelosejecutables

Introducción


Estado del Arte


Conclusiones

Referencias


La propuesta MDA de OMG tiene dos importantes carenciasrelacionadas con el tratamiento de los modelos iniciales:

No se aclara cómo deben manejarse los modelosligados al negocio, lo que se conoce como modelosindependientes de la computación ó CIM.

No se describe cómo deben asociarse esos modelosCIM con los primeros modelos del software adesarrollar, es decir, con los PIM (modelosindependientes de plataforma).

Las metodologías de desarrollo ágil de software tiene comopunto fuerte la conexión de los aspectos asociados alnegocio con los tecnológicos. Sin embargo, no se ajusta a laespeci�cación MDA.

Introducción


Estado del Arte


Conclusiones

Referencias


Hipótesis

La combinación de la especi�cación MDA con

la idea del desarrollo ágil resultaría muy

ventajosa de cara a un desarrollo de software

�exible y asociado a los procesos del negocio.

Introducción


Estado del Arte


Conclusiones

Referencias


Objetivo PrincipalDe�nir una metodología para el desarrollo de software quepermita la creación de software a partir del modelado deprocesos del negocio de acuerdo a la especi�cación MDA yel desarrollo de software ágil.

Centrado en las etapas iniciales del proceso de desarrollo,aquellas relacionadas con los modelos CIM y PIM de MDA.

Introducción


Estado del Arte


Conclusiones

Referencias


Objetivos Parciales

Objetivo Parcial 1:Realizar un estudio de las áreas relacionadas con elobjetivo principal, es decir, MDA, desarrollo ágil desoftware, patrones de diseño y estándares.

Objetivo Parcial 2:De�nir una metodología para el desarrollo de softwareágil de acuerdo a la especi�cación MDA.

Objetivo Parcial 3:Crear un prototipo que implemente la metodología.

Objetivo Parcial 4:Desarrollar una aplicación usando la metodología yutilizando el prototipo.

Introducción

Estado del Arte

Software ÁgilMDAPatronesUMLOCLMOFXMIS.PersistenciaGeneración CódigoPlataformas


Conclusiones

Referencias

MDEContenidos

1 Introducción



4 Conclusiones

5 Referencias

Introducción

Estado del Arte



Conclusiones

Referencias

MDEContenidos

1 Introducción

2 Base teórica y Estado del ArteDesarrollo de Software ágilModel Driven Architecture (MDA)Patrones de DiseñoUni�ed Modeling Language (UML)Object Constraint Language (OCL)Meta-Object Facility (MOF)XML Metadata Interchange (XMI)Sistemas de PersistenciaGeneración automática de InterfacesPlataformas: J2EE y .NET

Introducción

Estado del Arte



Conclusiones

Referencias

MDESoftware Ágil

Métodos ligeros de desarrollo

Desarrollado por Kent Beck [BEC99a]

Proceso de desarrollo de Software es impredecible

Debe ser FLEXIBLECaso de Estudio: Extreme Programming

MDA ágiles

Código = los modelos ejecutablesUn modelo ejecutable puede ser construido, ejecutado,probado y modi�cado en ciclos cortos e incrementales.

Introducción

Estado del Arte



Conclusiones

Referencias

MDEPrincipios del Software Ágil (1/2)

Los métodos ligeros están centrados en el código

Solución de compromiso entre la ausencia de proceso yel exceso de proceso

Diferencias entre métodos pesados y ágiles según Fowler[FOW95]

Adaptación al Cambio:Los métodos ágiles son adaptables,los métodos pesados que plani�can el proceso de desarrollosólo funciona mientras las cosas no cambian.Aceptación a la naturaleza de las personas: Centrados en laspersonas no en el proceso.

Introducción

Estado del Arte



Conclusiones

Referencias

MDEPrincipios del Software Ágil (2/2)

Mani�esto para el Desarrollo de Software Ágil [BEC01]

Se pre�ere frente a

las personas y las relaciones los procesos y herramientasel software que funciona la documentaciónla colaboración del cliente los contratosresponder a los cambios seguir un plan

Procesos y relaciones con el cliente y sumantenimiento, no código.

Introducción

Estado del Arte



Conclusiones

Referencias

MDEMétodos del Software Ágil

Extreme Programming (XP)

Scrum

Adaptive Software Development (ASD)

Crystal Clear y otras metodologías de la familia Crystal

DSDM

Feature Driven Development

Lean software development

Introducción

Estado del Arte



Conclusiones

Referencias

MDELas 12 Prácticas de Extreme Programming (XP)

1 Plani�cación (historias, iteracciones y tareas)2 Versiones Cortas3 Metáfora4 Diseño Simple5 Pruebas continuas6 Factorización7 Programación en parejas8 Propiedad colectiva del código9 Integración continua10 Trabajo de 40 horas semanales11 Cliente en el sitio12 Estándares de codi�cación

Introducción

Estado del Arte



Conclusiones

Referencias

MDEContenidos

1 Introducción


Introducción

Estado del Arte



Conclusiones

Referencias

MDEModel Driven Architecture (MDA)

Arquitectura formulada por el Object ManagementGroup (OMG)Proporciona un enfoque para:

Especi�car un sistema de manera independiente a laplataforma de soporteEspeci�car plataformasElegir una plataforma particular para el sistemaTransformar la especi�cación del sistema para unaplataforma en concreto.

Objetivos [PGBCLST05]

Separación arquitectónica de conceptos para:

Portabilidad

Interoperatibilidad

Reusabilidad

Introducción

Estado del Arte



Conclusiones

Referencias


Conceptos Básicos (1/4)

Sistema: Los conceptos de MDA serán expresados entérminos del sistema existente.Modelo: Descripción o especi�cación del sistemamediante un modelo.Dirigido por modelos: aporta los medios para usar losmodelos directamente para el entendimiento, diseño,construcción, despliegue, operación, mantenimiento ymodi�cación.Arquitectura del sistema es una especi�cación de laspartes y los conectores del sistema y las reglas para lainteracción de las partes usando conectores.Punto de vista es la técnica para la abstracciónutilizando un conjunto seleccionado de conceptos de laarquitectura y reglas estructurales

Introducción

Estado del Arte



Conclusiones

Referencias



Vista: representación del sistema desde la perspectivadel punto de vista elegido

Plataforma: hace referencia a los detalles tecnológicosy de ingeniería que no son relevantes de cara a lafuncionalidad esencial del sistema

Aplicación: funcionalidad que se está diseñando

Independencia de Plataforma

El modelo de computación independiente (CIM): noenseña la estructura de los sistemas, el principalusuario son los conocedores del dominio. Es un puenteentre los expertos del dominio y sus requisitos, y losexpertos en el diseño y construcción de artefactos quejuntos satisfacen los requisitos del dominio.

Introducción

Estado del Arte



Conclusiones

Referencias



El modelo de plataforma independiente (PIM): vistadel sistema centrada en la operación del mismo queesconde los detalles necesarios para una determinadaplataforma, puede ser utilizado con varias plataformasdiferentes de forma similar. Una técnica muy común esa través de una máquina virtual

Introducción

Estado del Arte



Conclusiones

Referencias



El modelo de plataforma especi�ca (PSM): combina lasespeci�caciones del PIM con los detalles que especi�cacómo utiliza el sistema un tipo particular de plataforma

Transformación del modelo: proceso de convertir unmodelo en otro del mismo sistema.

Servicios difundidos: servicios disponibles en unaamplia gama de plataformas.

Implementación: especi�cación, que suministra toda lainformación necesaria para la construcción del sistema.

Introducción

Estado del Arte



Conclusiones

Referencias


Transformaciones de modelos (1/3)

Las transformaciones son un punto clave de MDA

Introducción

Estado del Arte



Conclusiones

Referencias



Transformaciones de PIM a PSM:

Implementaciones del estándar QVT(Query/View/Transformation) de OMG:

Borland Together ArchitectSmartQVTMOMENT

VIsual Automated model TRAnsformation (VIATRA 2)ATLAS Transformation Language (ATL)Motor de Transformaciones de BOA 2Model-To-Model Transformation (M2M)

Introducción

Estado del Arte



Conclusiones

Referencias



Transformaciones de PSM a Código:

Sistemas de Generación de Código:

Code mungingExpansor de código en línea (inline-code expander)Generación de código mezclado (mixed-codegeneration)

Motores de Plantillas

Introducción

Estado del Arte



Conclusiones

Referencias


Implementaciones de MDAs

En el mercado existen múltiples herramientas queimplementan total o parcialmente los conceptos deMDA

Herramientas analizadas:

AndroMDA (version 3 y papers de la version 4)OpenArchitectureWare (oAW)Software Factories de MicrosoftBorland Together Architect Edition

Introducción

Estado del Arte



Conclusiones

Referencias

MDEContenidos

1 Introducción


Introducción

Estado del Arte



Conclusiones

Referencias

MDEPatrones de Diseño

Conceptos

Los Patrones de Diseño [GHJV95] son la base para labúsqueda de soluciones a problemas comunes en eldesarrollo de softwareLos patrones de diseño software describen solucionessimples y elegantes a una serie de problemas concretosque tienen lugar en el diseño orientado a objetosCuatro elementos esenciales:

1 El nombre del patrón permite describir un problema dediseño así como sus soluciones y consecuencias

2 El problema describe cuándo aplicar el patrón3 La solución describe los elementos que constituyen el

diseño, sus relaciones, responsabilidades ycolaboraciones

4 Las consecuencias son los resultados de aplicar elpatrón, así como sus ventajas e inconvenientes

Introducción

Estado del Arte



Conclusiones

Referencias

MDEPatrones de Diseño

Clasi�cación

Patrones de Creación: tienen un propósito de creaciónde objetos

Patrones Estructurales: tratan con la composición declases u objetos

Patrones de Comportamiento: caracterizan el modo enque las clases y objetos interactúan y se reparten laresponsabilidad

Introducción

Estado del Arte



Conclusiones

Referencias

MDEContenidos

1 Introducción


Introducción

Estado del Arte



Conclusiones

Referencias

MDEUni�ed Modeling Language (UML)

El lenguaje uni�cado de modelado es unaespeci�cación del Object Management Group (OMG)

UML es un lenguaje estándar para escribir planos desoftware

UML es un lenguaje

para visualizarpara especi�carpara construirpara documentar

Introducción

Estado del Arte



Conclusiones

Referencias


Modelo conceptual de UML

Elementos principales:

los bloques básicos de construcción de UMLlas reglas que dictan cómo se pueden combinar estosbloques físicosmecanismos comunes que se aplican a través de UML

Introducción

Estado del Arte



Conclusiones

Referencias


Arquitectura

Vista de Casos de Uso

Vista de Diseño

Vista de Procesos

Vista de Implementacion

Vista de Despliegue

Introducción

Estado del Arte



Conclusiones

Referencias


UML ejecutable

Es un per�l de UML que de�ne una semántica deejecución para un subconjunto de UML [Mel04]

Toma un subconjunto del lenguaje UML sinconstrucciones semánticamente ambiguas y les añadela semántica de ejecución a través de Action Semantics

Se obtiene una propuesta computacionalmentecompleta

Introducción

Estado del Arte



Conclusiones

Referencias

MDEContenidos

1 Introducción


Introducción

Estado del Arte



Conclusiones

Referencias

MDEObject Constraint Language (OCL)

OCL es un lenguaje para la descripción precisa derestricciones que se aplican a los modelos grá�cos UML

Desarrollado por IBM y adoptado en octubre de 2003por el grupo OMG como parte de UML 2.0

Características del Lenguaje

Lenguaje de expresión puro: garantiza que unaexpresión OCL no tendrá efectos colaterales, no puedecambiar nada en el modelo

Lenguaje de modelado no es un lenguaje deprogramación: no es posible escribir lógica de programao �ujo de control en OCL

Lenguaje Formal: todos los constructores tienen unsigni�cado formalmente de�nido, por ser OCL parte dela especi�cación UML

Introducción

Estado del Arte



Conclusiones

Referencias


Utilización de OCL

Como lenguaje de consulta

Dentro del modelo de clase para expresar invariantessobre clases y tipos

Para especi�car tipos invariantes para Estereotipos

Para describir pre y postcondiciones sobre Operacionesy Métodos

Para describir controles

Para especi�car objetivos para mensajes y acciones

Para especi�car restricciones sobre operaciones

Para especi�car reglas de derivación de atributos parauna expresión sobre el modelo UML

Introducción

Estado del Arte



Conclusiones

Referencias


Elementos de OCL

Expresiones, tipos y valores en OCL

Tipos de�nidos por el usuario

Tipos Collection

Introducción

Estado del Arte



Conclusiones

Referencias


Ejemplo de utilización OCL para invariantes

Tenemos un diagrama de clases con un clase Cliente deBanco

Restricción: La edad de cualquier cliente es siempremayor o igual a cero.

Restricción de Invariantecontext Cliente inv:

mEdad>=0

Introducción

Estado del Arte



Conclusiones

Referencias


Ejemplo de utilización OCL para pre y postcondiciones

Extracto del diagrama de clases con dos clases Clientey Cuentas de Banco

Restricción: Retirada de efectivo si el saldo de lacuenta es mayor que el importe

Restricción de pre y postcondicioncontext Cuenta :: retirar(importe : real) : realpre : importe>0 and getSaldo()>=importepost : result=importe

Introducción

Estado del Arte



Conclusiones

Referencias

MDEContenidos

1 Introducción


Introducción

Estado del Arte



Conclusiones

Referencias

MDEMeta-Object Facility (MOF)

El Meta-Object Facility es un estándar del ObjectManagement Group (OMG)

MOF se utiliza como Metamodelo para de�nir UML

Metamodelo

Es un modelo de un modelo.Un modelo es una abstracción y un metamodelo es unaabstracción de mayor nivel, cuyo propósito es de�nir laspropiedades del modelo en sí mismo.

Introducción

Estado del Arte



Conclusiones

Referencias


Metamodelo de UML

Introducción

Estado del Arte



Conclusiones

Referencias


Metanivel MOF en el ámbito de los MDA

Metanivel Descripción

M3 MOFM2 MetamodelosM1 ModelosM0 Objetos y Datos

Ejemplos:

MOF: Clase MOF, Atributo MOF,. . .

Metamodelos: Clase UML, Atributo UML,. . .

Modelos: Clase Cuenta en un banco, clase Cliente,. . .

Objetos y Datos: Cliente Cris Pelayo, Cuenta111118,. . .

Introducción

Estado del Arte



Conclusiones

Referencias


Implementaciones de MOF

Metadata Repository (MDR) de la plataforma deherramientas de desarrollo NetBeans

Eclipse Modeling Framework (EMF) es un frameworkde modelado y una utilidad de generación de código

Introducción

Estado del Arte



Conclusiones

Referencias

MDEContenidos

1 Introducción


Introducción

Estado del Arte



Conclusiones

Referencias

MDEXML Metadata Interchange (XMI)

XMI es un estándar del Object Management Group(OMG) para el intercambio de información vía XML

Se utiliza como formato de intercambio de modelosUML, es decir, se puede utilizar para la serialización demetamodelos.

Desde la perspectiva de modelado de OMG, los datosse dividieron:

Modelos abstractos: representan la informaciónsemántica, son instancias de lenguaje de modeladobasado en MOFModelos concretos: representan diagramas visuales,para estos se utiliza el XMI

Introducción

Estado del Arte



Conclusiones

Referencias


Facilita el intercambio de los metadatos entre lasherramientas de modelado UML y los repositorios demetadatos MOF

XMI hace la correspondencia (mapping) de MOF aXML para permitir el intercambio entre herramientasde modelado

XMI integra estándares

Introducción

Estado del Arte



Conclusiones

Referencias


DTD, XML Schemas y Documentos XML

Producción de DTD desde un modelo de objetos.Producción de XML Schemas desde un modelo deobjetos.Producción de documentos XML desde un modelo deobjetos.

Introducción

Estado del Arte



Conclusiones

Referencias

MDEContenidos

1 Introducción


Introducción

Estado del Arte



Conclusiones

Referencias

MDESistemas de Persistencia

De�niciones de Persistencia

Es el tiempo en el que los datos existen y sonutilizables [AMP86] , por tanto es el mantenimiento delos valores de los datos durante todo su tiempo de vida.

Principio secundario del modelo de objetos [Boo94] :cualidad de un objeto de mantener su identidad yrelaciones con otros objetos con independencia delsistema o proceso que lo creó

Introducción

Estado del Arte



Conclusiones

Referencias

MDESistemas de Persistencia

Desarrollo de Aplicaciones Persistentes

El modelo de datos dominante es el modelo relacionalrepresentado por el lenguaje SQLUtilización de SQL desde un lenguaje de programacióncómo Java

de forma directa: JDBC o SQLJde forma indirecta: sistemas de traducciónobjeto-relacional como JDO o Hibernate o unframework de persistencia especí�co (Enterprise JavaBeans o Spring)

Introducción

Estado del Arte



Conclusiones

Referencias

MDEContenidos

1 Introducción


Introducción

Estado del Arte



Conclusiones

Referencias

MDEGeneración automática de Interfaces

Generación de interfaces de usuario a partir de modelosconceptuales.

Dos conceptos fundamentales en la creación deinterfaces: la usabilidad y la accesibilidad

El Modelo Vista Controlador (MVC)

Introducción

Estado del Arte



Conclusiones

Referencias


El Modelo Vista Controlador (MVC)

Patrón de arquitectura de software inventado porTrygve Reenskaug e introducido en el entorno dedesarrollo del SmallTalk 80

Tres elementos:

Modelo: representación del dominio de la informaciónsobre la cual funciona la aplicación (Capa de dominioo negocio)Vista: presenta el modelo en un formato adecuadopara interactuar, es el mecanismo encargado derealizar la correspondencia entre los datos provenientesdel modelo y la interfaz.Controlador: realiza el control del �ujo de navegaciónde la aplicación.

Introducción

Estado del Arte



Conclusiones

Referencias


Flujo de la Información en MVC

El usuario interactúa con la interfaz de usuario dealguna forma, por ejemplo pulsando un botón.

El controlador gestiona el evento que llega.

El controlador accede al modelo, modi�cándolo deforma adecuada a la acción solicitada por el usuario.

El controlador delega a los objetos de la vista la tareade desplegar la interfaz de usuario. La vista obtiene susdatos del modelo para generar la interfaz apropiadapara el usuario donde se re�eja los cambios en elmodelo.

La interfaz de usuario espera nuevas interacciones delusuario, comenzando el ciclo nuevamente.

Introducción

Estado del Arte



Conclusiones

Referencias


Implementaciones del MVC orientadas a la Web

JavaServer Faces

Apache Struts

XForms

Introducción

Estado del Arte



Conclusiones

Referencias

MDEContenidos

1 Introducción


Introducción

Estado del Arte



Conclusiones

Referencias

MDEPlataformas: J2EE y .NET

La Plataforma J2EE

Conjunto de especi�caciones diseñadas por Sun quepermiten la creación de aplicaciones empresariales

J2EE = JVM + Lenguaje Java + API Java + Utilidades

Introducción

Estado del Arte



Conclusiones

Referencias


Características de la JVM (Java Virtual Machine)

Pila de ejecución y un repertorio de instrucciones quemanipulan dicha pila.Puede dar soporte a varios hilos (threads) de ejecuciónconcurrente.Compilación JITVeri�cación estática de bytescodesGestión de memoria dinámicaDependencia del lenguaje Java

Introducción

Estado del Arte



Conclusiones

Referencias


El lenguaje Java

Este lenguaje fue desarrollado por J. Gosling en 1993

Características:

SencilloOrientado a Objetos PuroInterpretado y compiladoDistribuido y con multihilosIndependiente de la plataforma y portableRobusto y seguro

Introducción

Estado del Arte



Conclusiones

Referencias


La Plataforma .NET

Desarrollada por Microsoft.

Intenta simpli�car el desarrollo de aplicaciones en unentorno altamente distribuido como es Internet.

Introducción

Estado del Arte



Conclusiones

Referencias


Características de la CLR (Common Language Runtime)

Utilización de una pila de ejecución

Compilación JIT

Generación de código en tiempo de instalación

Veri�cación estática de tipos

Gestión dinámica de memoria

Independiente del lenguaje

Sistema de Componentes

Introducción

Estado del Arte



Conclusiones

Referencias


Los Lenguajes .NET

Lenguaje Visual Basic

Lenguaje C#

Lenguaje C++ administrado

Lenguaje Jscript .NET

Lenguaje J#

Introducción

Estado del Arte



Conclusiones

Referencias


Otros elementos de la Plataforma .NET

CTS: Sistema Común de TiposTipos de valorTipos de referencia

Biblioteca de clases de .Net

Introducción

Estado del Arte


FundamentaciónProceso TradicionalProceso con MDATALISMANPrototipoEjemplo

Conclusiones

Referencias

MDEContenidos

1 Introducción



4 Conclusiones

5 Referencias

Introducción

Estado del Arte



Conclusiones

Referencias

MDEContenidos

1 Introducción


3 Desarrollo ágil con MDAFundamentaciónProceso de Desarrollo TradicionalProceso de Desarrollo con MDATALISMAN: Metodología ágil con MDAPrototipo asociado a TALISMANEjemplo: �Casas Rurales en Asturias�

Introducción

Estado del Arte



Conclusiones

Referencias

MDEFundamentación

Capacidad de los MDAs con metodologías ágiles frentea los métodos tradicionales.

Analizar el impacto de los MDAs en el proceso dedesarrollo de software.

Disciplina de Ingeniería

Algunos autores consideran que el desarrollo deherramientas MDA es un requisito indispensable paraconvertir el proceso de crear software en una verdaderadisciplina de ingeniería. [Fra03] [KWB03] [RFW+04]

Introducción

Estado del Arte



Conclusiones

Referencias

MDEContenidos

1 Introducción



Introducción

Estado del Arte



Conclusiones

Referencias

MDEProceso de Desarrollo Tradicional (1/9)

Etapas básicas

Análisis de requisitos

Modelo de análisis

Modelo de diseño

Escritura del códigofuente

Despliegue del sistema

Introducción

Estado del Arte



Conclusiones

Referencias


Etapas básicas del proceso de desarrollo de Software,propuesto inicialmente por Royce [Roy70]

Modelo de ciclo de vida en cascada (waterfall model)

Modelo en espiral de Boehm [Boe88]

Evolucionario [MZ96]

Modelo incremental [Som01]

Uni�ed Proccess (UP), la implementación másadoptada de este método es el Racional Uni�edProccess (RUP) [Kru00]

Introducción

Estado del Arte



Conclusiones

Referencias


La iteración como respuesta al cambio

Todos estos modelosadoptan la iteración cómoherramienta principal paraabordar los cambios en elsoftware

Se acepta que los cambiosen los requisitos delsoftware son inevitables[Bec99a]

El proceso de desarrollodebe estar preparado paraabsorberlos

Introducción

Estado del Arte



Conclusiones

Referencias


Problemas con la Iteración

Los métodos con ciclo de vida iterativo producen grancantidad de artefactos en forma básicamente dedocumentos de texto y diagramas, pero estos estándesconectados entre sí y del código fuente querepresentan [KWB03]

Dos alternativas opuestas:

Retroceder a la fase de desarrollo apropiada y

acometer el cambio, provoca un �exceso deburocracia� [Fow05]

Realizar los cambios únicamente en el código. Lastareas de análisis, modelado y documentaciónprevias a la codi�cación dejan de considerarseimprescindibles

Introducción

Estado del Arte



Conclusiones

Referencias


Métodos ágiles

Acortan el plazo de iteración y apuestan por undesarrollo evolutivo

Utilizan una plani�cación adaptativa

Apuestan por la entrega incremental

Incorporan prácticas de desarrollo que buscan permitiruna respuesta rápida y �exible a los cambios

Uni�ed Proccess (UP)

Considerarlo pesado o ágil dependerá de su implantaciónconcreta. Martin Fowler en [Fow05] señala que en laindustria pueden encontrarse utilizaciones del UP que vandesde rígidos modelos en cascada a instanciasperfectamente ágiles

Introducción

Estado del Arte



Conclusiones

Referencias


Problemas de los Métodos ágilesFalta de datos empíricos que prueben su efectividadNo escalabilidad a la hora de su aplicación en proyectosgrandes [TFR02]

Excesiva dependencia del conocimiento tácito de losmiembros del equipo de desarrollo debido a la ausenciade una documentación formal [Coc01]Alto acoplamiento entre las diferentes prácticas de XPy la falta de documentación de sus interrelaciones[Van05]

Métodos ágiles = Métodos anárquicos

Esta consideración es errónea dado que en el �Mani�esto Ágil�(Agile Manifesto) [Bec01], en el principio número 10 se señalaque la excelencia técnica y los buenos diseños aumentan laagilidad

Introducción

Estado del Arte



Conclusiones

Referencias


Modelado y Codi�cación

Un error en muchos enfoques metodológicos dedesarrollo software ha sido obviar la importancia de laactividad de codi�cación.

Royce equiparó la codi�cación a la fase de construcciónde otras ingenierías [Roy70]

Fowler [Fow05] señala que en otras ingenierías:El diseño es más difícil de predecir y requiere la gentecon mayor formación y creatividadLa actividad de construcción es más fácil de predecir,requiere gente con menos formación y es, en general,mucho más costosa¾Puede obtenerse un diseño que haga de lacodi�cación una actividad de construcción predecible?Y si esto es posible ¾será rentable en términos decostes?

Introducción

Estado del Arte



Conclusiones

Referencias


Modelado y Codi�caciónEl problema fundamental es la gran distancia existenteentre:

Los modelos software o descripciones del softwarerealizadas a un elevado nivel de abstracción.El código fuente que comprende la aplicación y querealiza los modelos desarrollados sobre una plataformatecnológica concreta.

Enfoque pragmático: Modelado ágil [AJ02]

El modelado es importante, como herramienta decomunicación, NO de documentaciónNo se construyen modelos detallados del softwareLos modelos sólo especi�can las partes más complejas de laaplicación, los problemas sencillos de diseño se resuelvendirectamente en la fase de codi�cación

Introducción

Estado del Arte



Conclusiones

Referencias


Problemas en los Procesos de Desarrollo Actuales

La desconexión entre los artefactos de modelado, yentre éstos y el código fuente del programa, hacedesaconsejable la realización de un modelado formal,detallado e integral.

Si no se realiza un modelado formal se plantea unproblema importante de mantenimiento.Otros problemas comunes a los métodos de desarrolloiterativos son:

ProductividadCalidadTrazabilidad de requisitosReutilización

Introducción

Estado del Arte



Conclusiones

Referencias

MDEContenidos

1 Introducción



Introducción

Estado del Arte



Conclusiones

Referencias

MDEProceso de Desarrollo utilizando MDA (1/4)

El Enfoque MDA de OMG

Importantes cambios en cómo se acometen las fases enel proceso de desarrolloCambios sustanciales en las fases del análisis y deldiseño debido a la doble transformación automática:

entre un PIM y un PSMentre un PSM y el código fuente de la aplicación

PIM se corresponde con la fase de diseño del modelotradicional

La transformación es el conocimiento experto sobre laplataforma tecnológica

Introducción

Estado del Arte



Conclusiones

Referencias


El Enfoque MDA de OMG

Se favorece la reutilización de:

Mismos modelos con diferentes de�niciones detransformaciónMismas de�niciones de transformación con diferentesmodelos

La doble transformación automática (PIM-PSM yPSM-código fuente) implica que los modelos seperciban como ejecutables:

Permite validar los modelos realizados

Permite determinar cuándo se ha terminado de

modelar: cuando el PIM veri�que todos los casos de

pruebas diseñados [RFW+04]

Introducción

Estado del Arte



Conclusiones

Referencias


Especi�cación e implementación con MDA

Separación del análisis ydel diseño, realizados porgrupos de especialistasdiferentesLa herramienta MDAacepta como entradas:

Modelo de diseño(PIM)De�nición de latransformación

A partir de las entradas segenera el PSM

El PSM será transformadoa código fuente

Introducción

Estado del Arte



Conclusiones

Referencias


Ciclo de Vida con MDA

Iteración para afrontar elcambio en los requisitos,pero son más efectivas

Cambio en requisitostecnológicos ⇒ ajusteen las transformacionesque son reutilizablespara otras aplicacionesCambio en requisitosde negocio ⇒modi�caciones en elmodelo de análisis.

Como la transformación PIM - Código fuente esautomática se pueden validar los modelos de análisisejecutando los PIM

Introducción

Estado del Arte



Conclusiones

Referencias

MDEContenidos

1 Introducción



Introducción

Estado del Arte



Conclusiones

Referencias

MDEMetolodología propuesta (1/11)

Los métodos ágiles de desarrollo constituyen unarespuesta a la realidad cambianteEl proceso de desarrollo propuesto en TALISMAN secaracteriza por:

Generación de código automática a partir deespeci�caciones en XMLSer ágil en base a XP basada en la simplicidad,comunicación y retroalimentaciónSer dirigido por modelos especi�cados en XMLSer un proceso AMDD (Agile Model DrivenDevelopment)

Introducción

Estado del Arte



Conclusiones

Referencias


Proceso de Desarrollo Ágil con TALISMAN

Introducción

Estado del Arte



Conclusiones

Referencias


Análisis

Basado en Casos de Uso

Escenarios que especi�canlos Casos de Uso

Especi�cación completadel proceso (story board)

de cada Escenario

Interfaz Grá�ca ligada acada Escenario

Introducción

Estado del Arte



Conclusiones

Referencias


Diseño

Diccionario de Clases

Comportamiento internode los métodos de cadaclase

Especi�cación de laarquitectura software

Especi�cación de laarquitectura hardware

Otros tipos de Modelos

Introducción

Estado del Arte



Conclusiones

Referencias


Modelo especi�cado en XML

Especi�cación de requisitos en XML

Aporta contenido semántico a UML a través deextensiones

Especi�cación del comportamiento de los métodos(algorítmica de los métodos)

Información de los per�les

Implementación de Patrones de Diseño

Introducción

Estado del Arte



Conclusiones

Referencias


Arquitectura de TALISMAN

Utiliza el Modelo especi�cado en XML para generarcódigoRealiza la validación semánticaConstruye el sistema de persistencia, los interfaces deusuario con ayuda de herramientas generadoras deinterfaces y genera el código por medio detransformaciones

Introducción

Estado del Arte



Conclusiones

Referencias


Arquitectura de TALISMAN

La arquitectura tiene varios modelos

CIMPIMPSM

Guías de transformación entre modelos:

PIM a PIMPIM a PSMPSM a PSM

Introducción

Estado del Arte



Conclusiones

Referencias


Modelo CIM de la Arquitectura de TALISMAN

Centrado en el dominio del negocio

Especi�cado en XML

Introducción

Estado del Arte



Conclusiones

Referencias


Modelo PIM de la Arquitectura de TALISMAN

Especi�cación del funcionamiento propias del sistemajunto a la especi�cación para la implementación en unmedio informático

Especi�cado en XMLN-Capas

Diccionario de ClasesModelo de interfaz de usuarioEscenarios que se utilizan para de�nir la lógica denegocio

Introducción

Estado del Arte



Conclusiones

Referencias


Modelo PSM de la Arquitectura de TALISMAN

Se combina el punto de vista independiente de laplataforma con los detalles y características propias deluso de una plataforma de desarrolloN-Capas

Base de Datos a través de especi�cación XMLInterfaces de usuario a través de especi�cación XMLModelo de negocio a través de especi�cación XML

Introducción

Estado del Arte



Conclusiones

Referencias


Guías de transformación entre modelos de TALISMAN

CIM a PIM: los aspectos independientes decomputación se transforman en una especi�caciónformal de la estructura y forma del sistema

PIM a PIM: con objeto de re�namiento

PIM a PSM: un PIM re�nado se transforma en unmodelo dependiente de la infraestructura �nal deejecución

PSM a PSM: con objeto de re�namiento

PSM a Código: un PSM re�nado se transforma encódigo fuente en la plataforma de destino

Introducción

Estado del Arte



Conclusiones

Referencias

MDEContenidos

1 Introducción



Introducción

Estado del Arte



Conclusiones

Referencias

MDEConstrucción del prototipo (1/16)

Objetivos

Construir un prototipo utilizando la MetodologíaTALISMAN

Orientado al mundo Web

Plataforma .NET

Generación automática de código ASP.NET y C#

Se crean los modelos en XML y a partir de ellos serealiza el proceso de desarrollo, transformación yconstrucción del sistema hasta obtener el código deforma automática

Introducción

Estado del Arte



Conclusiones

Referencias


Características de las aplicaciones Web

En el desarrollo de aplicaciones Web se mezclan:Métodos tradicionales de desarrolloPropuestas de ingeniería WebMétodos para hipermedia

La agilidad en los desarrollos Web es fundamentalPronta disponibilidad del software en la redCiclos de desarrollo generalmente más cortosRequisitos de usuario desconocidosDesarrollos aparentemente muy sencillosNecesidad de entrega de versiones previas

Introducción

Estado del Arte



Conclusiones

Referencias


Adaptación de TALISMAN a los Sistemas Web:

La adaptación de TALISMAN se realiza de�niendonuevos artefactos adaptados a la Ingeniería WebCon los Diagramas y la información del Análisis y delDiseño se genera la documentación en XML coninformación de:

Clases con la información del Diagrama de ClasesFragmentos con la información semántica de las clasesdel Diagrama de FragmentosNavegación con la información sobre la navegación delDiagrama de NavegaciónUsuarios con sus roles que de�nidos en el Diagrama deUsuariosServicios Web de�nidos en los Diagrama de serviciosWeb y Servicios Web ClienteModelo de la lógica de Negocio

Introducción

Estado del Arte



Conclusiones

Referencias


Clases más representativas del Prototipo

Model

Resources

Generator

GeneratorASPNET2

Utils

Associations

Class

MultipleAssociation

ClassTest

Compiles

DataAccessBase

Links

Introducción

Estado del Arte



Conclusiones

Referencias


Clase Generator

Introducción

Estado del Arte



Conclusiones

Referencias


Diagrama de Estados de la Clase Generator

Introducción

Estado del Arte



Conclusiones

Referencias


Con�guración del Prototipo

Introducción

Estado del Arte



Conclusiones

Referencias


Construcción del PIM

El PIM de TALISMAN con la información de laaplicación se almacena en un archivo �pim.xml�

Se permite selecionar los modelos de entrada que seránutilizados

Introducción

Estado del Arte



Conclusiones

Referencias


Construcción del PSM

A partir del PIM se genera el PSM

A partir del PSM se genera el código fuente de laaplicación

Proceso completamente automático

Introducción

Estado del Arte



Conclusiones

Referencias


Generación de Código fuente

Se genera un proyecto de Visual Studio 2005denominado �solution.sln�

La solución consta de cinco proyectos

Introducción

Estado del Arte



Conclusiones

Referencias


Interfaz de Usuario (WebUI)

Proyecto principal

Páginas WebASPX generadas

Web.con�g con la con�guración de la aplicación

Servicios Web que se ofrecen y que se consumen

Archivos generadores de menús.

Introducción

Estado del Arte



Conclusiones

Referencias


Lógica de Negocio (Business)

Contiene las clase para las tablas que se generarán enla base de datos

Contiene los archivos que utiliza NHibernate paraindependizar el acceso a datos de la lógica de negocio

Lógica de Negocio (BusinessFacade)

Puente entre la capa de negocio y la capa de acceso adatos

Introducción

Estado del Arte



Conclusiones

Referencias


Persistencia (DataAccess)

Independiza el acceso a la base de datos del resto de laaplicación

Contiene métodos para guardar, obtener o borrarelementos de la base de datos

Introducción

Estado del Arte



Conclusiones

Referencias


Pruebas (TestUnit)

Pruebas unitarias generadas automáticamente

Introducción

Estado del Arte



Conclusiones

Referencias


Tablas de la base de datos

Script que genera la estructura de la base de datos

Para Sql Server 2005 se generará un archivo llamadoDataBase.sql

Introducción

Estado del Arte



Conclusiones

Referencias


Administración de usuarios y per�les de usuario

Se realiza la gestión de usuarios a través de lainformación generada en el archivo web.con�g

Se especi�can roles y permisos de acceso a toda oparte de la aplicación

Fragmento de web.con�g<location path=�Reserva.aspx�><system.web><authorization><allow roles=�Admin� /><deny users=�?� /></authorization></system.web></location>

Introducción

Estado del Arte



Conclusiones

Referencias


Registros(logs)Registro de proyecto generado con todas lasactividades de TALISMAN dividido en secciones:

Beginning: creación directorios y copia de archivoscomunes a todos los proyectosPIM to PIMPIM to PSMPSM to PSMPSM to Code

Registro de la ejecución del proyecto generadoAcciones que realiza el usuario de la aplicaciónMensajes de NHibernate generados durante laejecución

Introducción

Estado del Arte



Conclusiones

Referencias

MDEContenidos

1 Introducción



Introducción

Estado del Arte



Conclusiones

Referencias

MDEEjemplo de utilización del Prototipo (1/11)

Objetivo y Características generales

Objetivo: Comprobar la validez del prototipo creadosiguiendo TALISMAN

Características:

Plataforma ASP.NET 2.0Sistema de gestión de bases de datos Sql Server 2005

Casas Rurales en Asturias

Aplicación Web con información de casas rurales dediferentes zonas en Asturias y de las actividades que en ellasse pueden realizar

Introducción

Estado del Arte



Conclusiones

Referencias


Análisis y Diseño

Especi�cación en XML de los Requisitos

Diagramas:

Diagrama de ClasesDiagramas de Interfaz de Usuario a través de:

Diagrama de FragmentosDiagrama de Navegación

Diseño de la Lógica de Negocio a través de:

Diagrama de clases de servicios WebDiagrama de servicios Web ClienteDiagrama de usuarios

Introducción

Estado del Arte



Conclusiones

Referencias


Análisis y Diseño: Diagrama de Clases

Introducción

Estado del Arte



Conclusiones

Referencias


Análisis y Diseño: Diagrama de Fragmentos

Introducción

Estado del Arte



Conclusiones

Referencias


Análisis y Diseño: Diagrama de Navegación

Introducción

Estado del Arte



Conclusiones

Referencias


Análisis y Diseño: Lógica de Negocio

Introducción

Estado del Arte



Conclusiones

Referencias


Modelo especi�cado en XML

A partir de los Diagramas del Análisis y Diseño serealiza la documentación en formato XML

ClasesFragmentosNavegaciónUsuariosServicios WebServicios Web Cliente

Un único archivo que constituye la entrada aTALISMAN

Introducción

Estado del Arte



Conclusiones

Referencias


TALISMAN: Modelo PIM

Almacenado en el archivo �pim.xml�

Esqueleto del PIM<?xml version=�1.0� encoding=�utf-8�?><PIM><classes><fragments><navigation><users><webservices><webservicesClients>

</PIM>

Introducción

Estado del Arte



Conclusiones

Referencias


TALISMAN: Transformaciones mediante archivos XSLT yCSS

Especi�cación de transformaciones con archivos XSLT(eXtensible Stylesheet Language Transformations)

Actividad.xsltActPropia.xsltCasa.xsltDefault.xsltError.xsltReserva.xsltZona.xslt

Estilo de la aplicación Web a través de archivos CSS deHojas de Estilo (StyleSheet.css).

Introducción

Estado del Arte



Conclusiones

Referencias


TALISMAN: Recursos adicionales

Para crear la interfaz de usuario se proporcionanimágenes

Introducción

Estado del Arte



Conclusiones

Referencias


Salida GeneradaEl prototipo genera todos los archivos necesarios parala ejecución de la aplicación sobre la plataforma ASP.NET.Se generan más de 60 archivos

Introducción

Estado del Arte


Conclusiones

Referencias

MDEContenidos

1 Introducción



4 Conclusiones

5 Referencias

Introducción

Estado del Arte


Conclusiones

Referencias

MDEConclusiones

Aportaciones en el ámbito de MDA

De�nición de un entorno de desarrollo basado en MDA

De�nición de modelos CIM a partir de los procesos delnegocio

Directrices para la creación de modelos PIM a partir demodelos CIM

Una metodología que mejora la conexión entre lasreglas de negocio y las tecnologías MDA

Introducción

Estado del Arte


Conclusiones

Referencias

MDEConclusiones

Aportaciones en el ámbito del software ágil

Una metodología para el desarrollo de software ágil quepueda adaptarse a las necesidades y característicasparticulares de cada empresa

Una metodología de desarrollo de software quecombina las ventajas del MDA y el desarrollo ágil

Introducción

Estado del Arte


Conclusiones

Referencias

MDEContenidos

1 Introducción



4 Conclusiones

5 Referencias

Introducción

Estado del Arte


Conclusiones

Referencias

MDEReferencias

[Amb04] S.W. Ambler Agile Model Driven Development withUML 2. Cambridge University Press, 3rd edition, 2004.

[BBC+06] L. Balmelli, D. Brown, M. Cantor y M. MottModel-driven systems development. IBM Systems Journal,volumen 45 número 3, páginas 569 a 585. 2006.

[Bec01] K. Beck. Manifesto for agile softwaredevelopment.Technical Report, 2001.http://www.agilemanifesto.org/

[Fra03] David S. Frankel. Model Driven Architecture. ApplyingMDA to Enterprise Computing. OMG Press, 2003

[KWB03] A. Kleppe, J. Warmer y W. Bast MDA Explained. TheModel Driven Architecture: Practice and Promise.Addison-Wesley. 2003.

[Mel04] S. J. Mellor Agile MDA.The MDA Journal, páginas 144a 160, 2004

[MM03] J. Miller y J. Mukerji MDA Guide Version 1.0.1. ObjectManagement Group, 2003

Introducción

Estado del Arte


Conclusiones

Referencias

MDEReferencias

[MSU+04] S.J. Mellor, K. Scott, A. Uhl, y D. Weise. MDADistilled. Principles of Model-Driven Architecture. ObjectTechnology. Addison-Wesley, 2004.

[PCJ06] B. C. Pelayo García-Bustelo, J. M. Cueva Lovelle, yA.A. Juan Fuente. C3NET: Smart Environment For .NET CodeGeneration Using MDA. WORLDCOMP'06 Proceedings: The2006 World Congress in Computer Science, ComputerEngineering, and Applied Computing. Las Vegas, USA (2006).

[PC06a] B. C. Pelayo García-Bustelo y J. M. Cueva Lovelle.Arquitecturas dirigidas por modelos (MDA). El frameworkC3NET. II Congreso Internacional de Ingeniería de Computacióny Sistemas (IICIIS). Trujillo, Perú (2006).

[PC06b] B. C. Pelayo García-Bustelo y J. M. Cueva Lovelle.Usabilidad, accesibilidad y métricas de sitios Web. II CongresoInternacional de Ingeniería de Computación y Sistemas (IICIIS).Trujillo, Perú (2006).

Introducción

Estado del Arte


Conclusiones

Referencias

MDEReferencias

[PCS+05] B.C. Pelayo García-Bustelo, J.M. Cueva Lovelle, M.C.

Suárez Torrente, y A.A. Juan Fuente. C3NET: Framework para

la construcción de MDA en la Plataforma .NET. III Simposio

Internacional de Sistemas de Información en la Sociedad del

Conocimiento (SISOF 2005). Instituto Tecnológico de las

Américas, República Dominicana (2005)

[PC05] B. C. Pelayo García-Bustelo y J. M. Cueva Lovelle.

Evolución de las directrices de accesibilidad del W3C. III

Simposio Internacional de Sistemas de Información en la

Sociedad del Conocimiento (SISOF 2005). Instituto Tecnológico

de las Américas, República Dominicana (2005)

[RFW+04] C. Raistrick, P. Francis, J. Wright, C. Carter y I.Wilkie. Model Driven Architecture with Executable UML.Cambridge University Press, 2004.

Introducción

Estado del Arte


Conclusiones

Referencias

MDEReferencias

[Sch06] Douglas C. Schmidt. Model - Driven Engineering. IEEEComputer Society, páginas 25 a 31. Febrero 2006

[SFP04] Richard Soley, David S. Frankel, y John Parodi. TheMDA Journal: Model Driven Architecture Straight From TheMasters. Meghan Ki�er Pr, Noviembre 2004

MDE: Ingeniería dirigida por modelos. Otra forma de...

Documents

Transcript of MDE: Ingeniería dirigida por modelos. Otra forma de...