Arquitectura Dirigida por el Modelo (MDA)

Especialista Universitario Java Enterprise

MDA en i2e - 1© 2009-2010 Depto. Ciencia de la Computación e IA

Arquitectura Dirigida por el Modelo (MDA)

Sesión 1: MDA en i2e


MDA en i2e - 2MDA

Puntos a Tratar

• Introducción• Model Driven Software Development (MDSD)• Model Driven Architecture (MDA)• Agile MDD y Agile MDA• Proceso Desarrollo (Scrum + AUP)• AndroMDA• MDA en I2E

o Ejemplos

© 2009-2010 Depto. Ciencia de la Computación e IA


MDA en i2e - 3MDA © 2009-2010 Depto. Ciencia de la Computación e IA

Quienes Somos

• I2e es una empresa que desarrolla software a medida.• Fundada el año 2007 (desde 2005 como autónomos) por

nosotros 2o José Luís Ramírez o Emilio Bravo

• Fuimos alumnos del especialista en la 3ª edición (curso 04-05)

• Actualmente trabajamos 2 personas• Más información en http://www.i2e.com.es/• Blog: http://www.i2e.com.es/blog/• Twitter: http://twitter.com/i2e_es

http://www.i2e.com.es/

http://www.i2e.com.es/blog/

http://twitter.com/i2e_es

http://twitter.com/i2e_es




Estructura de i2e

i2e

Buscando … Buscando … Buscando … Buscando …

Jose Luis RamirezCEO

Emilio BravoCTO

También Buscamos la colaboración con otras empresas y profesionales



Nuestras Inquietudes

• Creemos que la línea a seguir es el desarrollo dirigido por modelos (MDSD)

• Basada en el uso de las siguientes tecnologíaso GWT • realización de RIA (Rich Internet Applications) utilizando

Java, GWT compila el código Java a Javascript.o Eclipse RCP • para aplicaciones de escritorio.o Spring • limpieza de código, control de transacciones, inyección de

dependencias, no obliga a la utilización de un servidor de aplicaciones completo.

o Hibernate • implementación de JPA más extendida, actualmente es el framework ORM más completo.

o Lucene • indexación de grandes volúmenes de texto (la mayoría de la información ahí fuera no esta estructurada).

o Alguna tecnología para dispositivos móviles, Java ME?, Android?.



Puntos a Tratar


o Ejemplos



Abstracción

Via: http://twitter.com/david_bonilla (via http://lou.pe/)

http://twitter.com/david_bonilla

http://lou.pe/



Abstracción

• Unos de los principios básicos de la ingeniería del software es la abstracción, para separar lo esencial de lo no esencial



Abstracción en el desarrollo de Software.

An introduction to Model Driven Architecture (ibm.com)

• En términos del desarrollo de software, lo esencial es la funcionalidad, y lo no esencial es la plataforma tecnológica.

• Evolución de la Abstracción en el desarrollo de Software



Abstracción y Modelos

• Estas abstracciones nos las proveen los modelos.• El modelado y la transformación de modelos hasta el

nivel de abstracción requerido, constituye el núcleo del Desarrollo Dirigido por los Modelos (Model Driven Software Development (MDSD)).



Abstracción



Model Driven Software Development

• También conocido como Model Driven Development (MDD).

• MDSD usa los modelos para capturar los requerimientos, y automatizar parcial o totalmente la implementación.o ‘Compilamos’ los modelos para producir ejecutables, o facilitar el

desarrollo manual.

• Con los modelos podemos centrarnos en el diseño lógico de la aplicacióno Nos liberarnos de los detalles de la implementación.

• El esfuerzo invertido en el modelado tiene una continuidaddurante el desarrolloo Los modelos no son meramente parte de la documentacióno Dirigen de forma automatizada el desarrollo del código, durante todas

las fases e iteraciones del proyecto.



Proceso MDSD

Software Factories-Assembling Applications with Patterns, Models, Frameworks, and Tools (Wiley)



Aproximaciones al Modelado

Model-Driven Software Development (Springer)



Estado actual del desarrollo de software

Fuente: Peter Friese, itemis



Domain Specific Languages (DSL)

http://www.eclipse.org/Xtext/

• DSL es un lenguaje de programación o un lenguaje de especificación dedicado a un dominio particular.




http://modeling-languages.com/blog/content/relationship-between-mdamdd-and-mde

• MDD (Model Driven Development) es un paradigma de desarrollo que usa los modelos como el artefacto primario del proceso de desarrollo.

• MDA (Model Driven Architecture) es la visión particular de la OMG sobre MDD.

• MDE (Model Driven Engineering) va mas allá de la actividades de desarrollar software.














Puntos a Tratar


o Ejemplos



Model Driven Achitecture

• MDA is the OMG's particular vision of MDD and thus relies on the use of OMG standards.

• Model Driven Architecture (MDA) es un framework para el desarrollo software definido por el Object Management Group (OMG).



Model Driven Achitecture

• MDA es una vía para organizar y gestionar las arquitecturas empresariales, soportada por herramientas automatizadas para definir los modelos y facilitar las transformaciones entre modelos.

• Con MDA el proceso de desarrollode software esta dirigido por la actividad de modelar el software.



Basada en Estándares

• La aproximación MDA utiliza los estándares abiertos de modelado establecidos por la OMG’s:

oUnified Modeling Language (UML)

oMeta-Object Facility (MOF)

oCommon Warehouse Metamodel (CWM).



Tipos de Modelos

• Tenemos 3 tipos de modelos en función del nivel de abstracción.

o CIM (Computation Independent Model).Modelado del negocio y requerimientos a nivel de usuario.

o PIM (Platform Independent Model).Análisis y diseño independiente de la plataforma tecnológica.

o PSM (Platform Dependent Model).Diseño dependiente de la plataforma tecnológica.



Relación Entre los Modelos

Model-Driven Software Development (Springer)


MDA en i2e - 27MDA © 2009-2010 Depto. Ciencia de la Computación e IA MDA en i2e - 28

•La transformación entre inclusive models(CIM) y PIMs es manual.

•La transformación entre PIMs y PSMs requiere herramientas sofisticadas.

Artefactos en cada nivel de abstracción



PIM vs PSM

• PIM

o Representa un sistema de software que describe un negocio.El sistema se modela desde el punto de vista del negocio.

o El analista suele ser el encargado de realizar el PIM que describe el sistema.

o No está atado a ninguna plataforma tecnológica



PIM vs PSM

• PSM

o El PIM se transforma en uno o más PSMPara cada plataforma tecnológica especifica se genera un PSM.

o Modelo muy cercano al códigoEl sistema se modela desde el punto de vista de la tecnología.

o El arquitecto se encarga de adaptar el modelo para una implementación tecnológica especifica.



Extendiendo UML

• Son extensiones para adaptar UML a un dominio particular.• Podemos extender UML con nuestro lenguaje.• Introduce un conjunto de stereotypes (estereotipos) que

extienden UML.o Los estereotipos son anotaciones que ofrecen información

extra sobre los elementos

Profiles UML

• Necesitamos extender UML para adaptar el lenguaje al dominio en el que trabajemos.



Transformación de Modelos

• La transformación de modelos es una parte clave de MDA. También se conoce como mappingo Un mapping es un conjunto de reglas y técnicas que

permiten a un tipo de modelo convertirse en otro.

• La herramienta de transformación parte de un PIM y lo transforma en uno o mas PSM y de PSM a código.

• Las reglas de transformación se aplican en función de los estereotipos.

MDA Explained: The Model Driven Architecture™: Practice and Promise (Addison Wesley)



Definición de las Transformaciones

• QVT (Query/Views/Transformations) es el estándar definido por la OMG para las transformación entre modelos.o Actualmente muchas herramientas utilizan motores de plantillas

o lenguajes de scripting para la definición de las transformaciones.

• Poder adaptar las transformaciones a nuestras necesidades es uno los puntos fuertes de MDA.

• Esta característica es una de las que mas marcan la diferencia entre las herramientas MDA y los antiguos generadores de código.



Ejemplo Framework MDA

MDA Explained: The Model Driven Architecture™: Practice and Promise (Addison Wesley)



MDA Reduce los Tiempos de Desarrollo

• MDA se centra en los modelos, no en el código.

• Los modelos se producen a nivel de negocio, y se traducen a código mediante herramientas sofisticadas de generación de código.

• La destreza para pasar del modelo de negocio a la implementación reduce la mayoría de los esfuerzos de codificación.

• Al tener los modelos en las primeras iteraciones, permite la disponibilidad de un sistema ejecutable en fases tempranas del ciclo de vida del proyecto.



MDA y la Calidad Homogénea del Software

• MDA pone bajo el control del arquitecto el proceso automático de transformar los modelos en implementaciones.

• El arquitecto puede producir reglas de transformación para convertir los modelos en código.

• Estas reglas serán comunes a todos los modelos de un mismo tipo.

• Este proceso de transformación también se puede aplicar a cualquier proyecto de desarrollo, resultando en un software consistente respecto a su calidad y uso de estándares.



MDA y la Portabilidad de Plataforma

• Los modelos que inician el proceso MDA son independientes de la plataforma.

• Estos modelos se conocen como PIM (Platform Independent Model / Modelos Independientes de la Plataforma)

• Mediante el uso de generadores de código a medida para un tipo especifico de plataforma (Java EE, .NET, PHP…), MDA permite a los sistemas abarcar cualquier tecnología o framework para el cual exista el correspondiente generador de código.



MDA vs Modelado Tradicional

• Las herramientas de modelado como Borland Together o MagicDraw permiten al ingeniero de software emplear modelos UML para modelar/desarrollar aplicaciones.o ¿En qué se diferencian los procesos centrados en el uso de estas

herramientas respecto a un enfoque de desarrollo MDA?

• Las semejanzas entre los 2 enfoques son muy claras:o Potencian las técnicas de modelado para dirigir el proceso de

desarrolloo El conjunto de herramientas necesarias es complejo y necesita de

cierto tiempo para tener destreza.



Ventajas

• MDA fomenta el uso de PIMs de alto nivel para conducir el proceso de desarrollo.

• Centrada en el negocioo Primero se modela el PIM, y a posterior, los diferentes PSM.

• Soporta un proceso incrementalo A partir del PIM+PSM, se crea el esqueleto del proyecto.

• Facilita los cambioso Si modificamos el PIM, regeneramos los diferentes

implementaciones.

• Menos errores de aplicacióno Al codificar menos, hay menos errores.

• Portabilidad de tecnologíao Si aparece una nueva tecnología, creamos un nuevo PSM (EJB 3.0).



Inconvenientes

• Trabajo con Sistemas Heredados (Legacy)o La ingeniería inversa desde código a PSM, o directamente a PIM

no es muy efectiva.o El mapping de PSM a PIM es complejo y difícil de automatizar.o Si ya disponemos de PIM y de código heredado, los cambios en el

PIM “machacan” el código existente.

• Viabilidado El paso de PIM a PSM es una tarea compleja.

o Más complejo es automatizar el proceso.o Se necesitan herramientas complejas.



Puntos a Tratar

• Introducción• Model Driven Software Development (MDD)• Model Driven Architecture (MDA)• Agile MDD y Agile MDA• Proceso Desarrollo (Scrum + AUP)• AndroMDA• MDA en I2E

o Ejemplos



Agile Model Driven Development

• Propuesto por Scott W. Amber.

• Con AMDD en vez de crear modelos extensivos antes de escribir el código creamos modelos ágiles. Creamos los modelos mínimos necesarios para obtener el máximo de código.

• AMDD es una estrategia critica para ir escalando los procesos de desarrollo ágiles mas allá de los proyectos pequeños.

• Realizamos el mínimo modelado necesario para obtener el máximo de código posible. Regla 20/80



Agile MDD



Aproximaciones a AMDD.

• Manual. Herramientas simples, como una pizarra o un papel, se realizan modelos simples.

• Herramienta de Diseño. Modelos simples utilizados para explorar los requerimientos con ‘El Cliente’, y para analizar los requerimientos.

• Agile MDA. Uso de herramientas MDA de modelado para crear modelos, a partir de los cuales se genera código.



Agile MDA



Adopción de aproximaciones al modelado



Puntos a Tratar

• Introducción• Model Driven Software Development (MDD)• Model Driven Architecture (MDA)• Agile MDD y Agile MDA• Proceso de Desarrollo (Scrum + AUP)• AndroMDA• MDA en I2E

o Ejemplos



Scrum



Scrum

• Se trata de una metodología ágil para la Gestión de Proyectos, centrada en entregar en cada momento la funcionalidad con más valor para la empresa.

• El desarrollo se realiza de forma iterativa e incremental (en Sprints).o Al final de cada iteración/sprint se entrega una versión funcional del

software a partir de la cual el usuario y el equipo obtienen el feedback necesario.



Scrum

• Esta diseñado para adaptarse fácilmente a los cambios en los requerimientos.

• En el Product Backlog está la lista de requerimientoso La gestiona el Product Owner.

• En la Sprint Planning Meeting el equipo selecciona que requerimientos se pueden realizar en la siguiente iteración (Sprint) y se añaden al Sprint Backlog.



Agile Unified Process (AUP)

• Es una versión simplificada de RUP• Aplica técnicas ágiles:

o Desarrollo Dirigido por las Pruebas (TDD)o Modelado Ágil (AM)o Gestión del Cambio Ágil (ACM)

• Como proceso de desarrollo base utilizamos Scrum.



Agile UP

• De AUP nos quedamos con las disciplinas, algunos de los roles y si fuera necesario algún artefacto para la documentación del proyecto.



Puntos a Tratar


o Ejemplos



AndroMDA

• www.andormda.org

• AndroMDA es un framework MDA open source, recibe como entrada un modelo UML (almacenado en XMI o en EMF de eclipse) los combina con los pluginsde AndroMDA (cartridge y translation-libraries) y produce código fuente.

• Existen diferentes cartridges los cuales analizan el PIM de entrada y construyen un PSM sobre el cual se usan las plantillas para producir código.

http://www.andormda.org/



Prestaciones de AndroMDA

• AndroMDA significa principalmente escribir menos código manualmente.o Eliminamos las tareas repetitivas y aburridas.o Utilizamos el modelo para comunicar realmente lo que el

sistema está haciendo.

• AndroMDA genera código a medida para cubrir las necesidades particulares de un proyecto.

• Cuando necesitas modificar la aplicación, cambias primero el modelo, regeneras el código, y en caso de que sea necesario añades o modificas manualmente el código a medida.



Componentes AndroMDA

• Existen 2 componentes primarios usados en el sistema de AndroMDA:

1. AndroMDA code generation engine. Plataforma que contiene los módulos

de código (llamados cartridges / cartuchos) que realizan la generación del código.

2. Apache’s Maven project builder and management system. Serie de plugins de Maven para el

simplificar los procesos de uso de AndroMDA.



Cartridges

• Son los plugins primarios del framework AndroMDA.• Los cartridges procesan los elementos del modelo

que:o tienen unos stereotypes específicos (i.e. <<Entity>>,

<<Enumeration>>, etc.)

o cumplen ciertas condiciones inferidas del mismo (por ejemplo, todos los actores que tienen una dependencia con un <<Service>>).

• Procesan estos elementos a partir de los ficheros de plantillas definidos en el descriptor del cartridge.

• En resumen, son los responsables de generar el

código a partir del modelo.

• Cartridges:o BPM4Struts o jBPMo JSFo EJB o Hibernate o Javao Meta o Spring o WebServiceo XmlSchema



Configuración

• El engine de AndroMDA está dirigido por la información de configuración encontrada en el fichero andromda.xml

• El fichero <projectDir>/project.properties contiene

las propiedades de Maven que son pasadas a andromda.xml

• El fichero <projectDir>/build.properties

contiene las propiedades de Maven que son especificas para construir la versión.



Arquitectura generada por AndroMDA



Creando el Modelo con UML

• La generación de código en AndroMDA está dirigida por los esterotipos UML.

• Si encuentra un estereotipo reconocido, le cede el control al cartridge para generar el código.

• Para simplificar el modelado, ha sido desarrollado un Profilede UML el cual debe ser incluido como parte de tu modelo.o Este profile contiene los estereotipos necesarios para poder

modelar.• No genera el 100% del código ejecutable, debemos

implementar manualmente la lógica de negocio.o La lógica de negocio se implementa en clases que heredan

de las clases generadas en el core.



Implementando el código a media

• Utiliza el patrón template method para facilitar la implementación del código a medida. De esta manera durante el proceso de generación no se tocan las clases modificadas manualmente.

• En UsuarioServiceImpl implementamos el código a medida que necesitemos.



Implementando el código a mediaUsuarioServiceBase.java

public es.i2e.server.administracion.model.Usuario getUsuario(java.lang.Integer idUsuario)

{

if (idUsuario == null)

{

throw new IllegalArgumentException('idUsuario' can not be null");

}

try

{

return this.handleGetUsuario(idUsuario);

}

catch (Throwable th)

{

throw new

es.i2e.dpsrecobro.server.administracion.service.UsuarioServiceException(th, th);

}

}

protected abstract es.i2e.server.administracion.model.Usuario

handleGetUsuario(java.lang.Integer idUsuario) throws java.lang.Exception;



Otros Frameworks MDA

• OpenMDX• www.openmdx.org , Es una plataforma MDA Open

Source basada en los estándares MDA de la OMG. OpenMDX soporta Java SE, Java EE y .NET

• Taylor MDA• http://taylor.sourceforge.net , Taylor no es una

herramienta UML de propósito general. Es una herramienta especializada en construir aplicaciones empresariales utilizando tecnologías Java Open. Trabajamos directamente en un nivel PSM.



Herramientas para la Construcción de Frameworks a medida.

• Eclipse Modeling Project• www.eclipse.org/modeling/ , Eclipse Modeling Project

esta enfocado en la evolución y promoción de las tecnologías de desarrollo dirigido por modelos en la comunidad eclipse proveyendo frameworks de modelado, herramientas e implementaciones

estándar.

• Acceleo• http://acceleo.org/pages/home/en , Acceleo es una

herramienta para la construcción de generadores de codigo basada en eclipse.

• OpenArchitectureWare (oAW)• openArchitectureWare (oAW) es un framework de

generacion MDA/MDD modular basada en eclipse. Soporta EMF y otros modelos en UML2, XML o JavaBeans



Puntos a Tratar


o Ejemplos



MDA en I2E

• Utilizamos como proceso de desarrollo Scrum + AUPo con unas pequeñas modificaciones para adaptarlo a un proceso

MDSD.

• Iteraciones de 2 semanas en cada proyecto.• No generamos el 100% de la aplicación, utilizamos las

clases de infraestructura (core) sobre las cuales implementamos la lógica de negocio a medida.

• Todos los integrantes del equipo intervienen en cada decisión del proyecto.



Herramientas

• MagicDrawo Para la realización de los diagramas UML.o AndroMDA esta perfectamente integrada con MagicDraw, nos

proporciona los profiles para utilizarlos directamente desde MagicDraw.

o Es la herramienta recomendada por el equipo de AndroMDA.

• Eclipseo Para el desarrollo de código.

• Jira y Confluenceo Para la gestión de los proyectos.

• Hudsono Integración Continua.

• Subversion o Control de versiones



• Para cada aplicación, realizamos una división en 3 proyectos:

o Proyecto MDA donde se genera el código con AndroMDA a partir de los modelos.

o Proyecto de Servidor, donde realizamos el desarrollo de la lógica de negocio y los test.

o Proyecto cliente, el cliente puede ser: Escritorio • RCP, SWT, Swing

Web • Struts, GWT (Google Web Toolkit)

¿Cómo trabajamos con AndroMDA?



• Nos independizamos de cambios futuros en la estructura de los proyectos de AndroMDA.

• Podemos utilizar un sistema de control de versionescon el proyecto de desarrollo.

• Los diseñadores y arquitectos son los únicos que tocan el proyecto de diseño.

• Los programadores no tienen que preocuparse de aspectos del diseño ni conocer en profundidad tecnologías como EJB, Spring e Hibernate.

• Los desarrolladores del cliente o diseñadores gráficos pueden trabajar en local o remoto, están exentos del código del servidor.

Ventajas de la separación en proyectos



Proyecto 1 - MDA

• Este proyecto lo generamos utilizando andromdapp, herramienta para la creación de proyectos.

• Se realizan versiones en cada hito del proyecto.

• Diagrama UML.• Ant nos ayuda para realizar

copia del código generado al proyecto de desarrollo.



Proyecto 2 - Desarrollo

• Este proyecto esta bajo un sistema de control de versiones (Subversion o CVS)

• Sobre este proyecto trabajan los desarrolladores implementando la lógica de negocio y los test.



Proyecto 2 - Desarrollo • Tareas Ant

• Disponemos de tareas de Ant para:o la compilacióno el deploy en el servidor de

aplicacioneso la ejecución de test automáticos.

• También se han creado tareas de cobertura de los testo para comprobar cuanto código de

servidor esta testeado.



Proyecto 3 - Cliente

• También esta bajo Subversion (o CVS).

• Sobre este proyecto trabajan los desarrolladores y diseñadores gráficos

• Implementan la aplicación web o la aplicación de escritorio.



MDA en I2E

Stakeholders

Product Owner

Helpdesk

Usuarios

..etc..

Product Backlog

Product Backlog

Product Backlog

Product Owner

Product Owner

Scrum Master

Scrum Master

Scrum Master

Scrum of Scrum

Sprint Backlog

Sprint Backlog

Sprint Backlog



Ejemplo de una iteración (Sprint) en el proceso de desarrollo (Scrum + AUP)

1. Estimar: se estiman las pilas de producto y extraer nuevas pilas.

2. Planificar: se planifica el sprint en función del tamaño y la velocidad (recursos disponibles), se decide cuantos items del producto se puede realizar.

3. Modelar: se realiza una sesión de modelado.4. Generar: se genera el código y se empieza con el

trabajo.5. Demostrar: al final de la iteración se realiza una demo

con todo lo que se ha realizado.6. Realimentar: se obtiene el feedback de la demo para

realizar un nuevo sprint.



Proceso de Desarrollo

SVN



Sesión de Modelado

• Primero realizamos un esbozo en pizarra o en papel, en caso de que no tengamos claro como vamos a modelar los requerimientos.o Modelado Ágilo Intentamos integrar a todos los participantes del proyecto en

la realización de este primer esbozo.

• Una vez obtenido el esbozo utilizamos MagicDrawpara realizar el modelo.



Modelado

• Realizamos 3 diagramas de clases:1. Diagrama con las entidades <<Entity>>.2. Diagrama con los servicios <<Service>>.

3. Diagrama con los Value Objects o Data Transfer Objects<<ValueObject>>.

• En la herramienta de modelado tenemos que ir definiendo las estructura de paquetes para las clases.



Resultado del Modelado

• Tras el modelado, generamos el código y lo copiamos al proyecto de desarrollo.

o En función de cómo hayamos configurado el proyecto de AndroMDA generará el código sobre una arquitectura u otra.

• Ejemplo de arquitectura ->



Arquitectura de despliegue

Internet

Servidor Web ecommerce.

Tomcat

Servidor de Aplicaciones.

JBoss

Base de Datos.

MySQL (PostgreSQL,...)

Cliente Eclipse RCP

Cliente Eclipse RCP

Cliente Web

Cliente Eclipse RCP

Cliente Web



Código y ficheros de configuración generados



Implementación

• Una vez hemos generado el código, implementamos la lógica de negocio, las consultas y los test.

• AndroMDA nos proporciona:o el esqueleto sobre el cual implementar las funcionalidades

del negocioo y ciertas funcionalidades ya implementadas (CRUD).

• El código de negocio se implementa en los métodos de las clases Impl generadas por

AndroMDA.



Pruebas

• Para la implementación podemos seguir la metodología Test Driven Development, realizando las pruebas antes de la codificación de la implementación.

• Estos test se ejecutan desde un entorno de Integración Continua (CI).



Técnicas Complementarias

• Cobertura de los Testo Utilizamos la herramienta Cobertura

(http://cobertura.sourceforge.net/) para obtener el % de código cubierto por los test automáticos.

o Con los informes obtenidos podemos observar que partes del código están sin probar.

• Análisis Estático del Códigoo Utilizamos Herramientas como FindBugs

(http://findbugs.sourceforge.net/) o PDM para realizar un análisis estático del código y encontrar errores de implementación que reducen la calidad del código.

o Estas Herramienta también nos pueden servir para mejorar la

calidad del código generado automáticamente por la herramienta MDA.

http://cobertura.sourceforge.net/

http://findbugs.sourceforge.net/



Integraciones Continuas

• Con la integración continua automatizamos:o la compilación de la aplicacióno los testo el análisis estático del códigoo la generación del desplegable.

• También controlamos la evolución de la aplicación de una forma automatizada.

• Utilizamos Hudson (https://hudson.dev.java.net/) como servidor de integración. Lo utilizamos por su versatibilidad y la integración con Jira(http://www.atlassian.com/software/jira/).


http://cobertura.sourceforge.net/



Puntos a Tratar


o Ejemplos



ERP suministros eléctricos y domóticos



Gestión de un Laboratorio de Farmacia



Gestión del Boletín Oficial del Registro Mercantil (BORME)



Gestión Integral del Recobro de Deudas



Gestión Documental Despachos Profesionales



Para Saber Más• Bibliografía

o MDA Explained: The Model Driven Architecture(TM): Practice and Promise (Addison-Wesley).

o MDA Distilled (Addison-Wesley).o Model Driven Architecture: Applying MDA to Enterprise Computing (OMG Press).o Enterprise Patterns and MDA: Building Better Software with Archetype Patterns

and UML (Addison-Wesley).o Model-Driven Software Development: Technology, Engineering, Management

(Wiley).o Model-Driven Software Development (Springer).o Software Factories: Assembling Applications with Patterns, Models, Frameworks,

and Tools (Wiley).o Real-Life MDA: Solving Business Problems with Model Driven Architecture (The

MK/OMG Press)

• Presentaciones

o http://www.slideshare.net/peterfriese/software-automation-with-eclipse-modelingo http://www.slideshare.net/schogglad/introduction-to-mdd-2260834o http://www.slideshare.net/genexus/026-estado-del-arte-de-mdd-model-driven-

development

http://www.slideshare.net/peterfriese/software-automation-with-eclipse-modeling





































Para Saber Más

• Blogs

o http://modeling-languages.com/blogs/jordio http://www.theenterprisearchitect.eu/o http://blog.efftinge.de/o http://eclipsemde.blogspot.com/

• Enlaces

o http://www.omg.org/mda/o http://www.andromda.org/o http://www.modeldrivensoftware.neto http://www.codegeneration.neto http://www.agilemodeling.com/

o http://www.ibm.com/developerworks/rational/library/3100.html











http://www.omg.org/mda/

http://www.andromda.org/

http://www.modeldrivensoftware.net/



http://www.agilemodeling.com/

http://www.ibm.com/developerworks/rational/library/3100.html



¿Preguntas...?

Arquitectura Dirigida por el Modelo (MDA)

Documents

Transcript of Arquitectura Dirigida por el Modelo (MDA)