Presentacion Mda

Model Driven Architecture Ingenieria Informatica Empresarial 1

Agenda Introducción Model Driven Development (MDD). Model Driven Architecture (MDA). Agile MDD. Agile MDA. Proceso Desarrollo (AUP). Herramientas (AndroMDA). MDA en I2E. Ejemplos y Demostración. 2

Introducció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. En términos del desarrollo de software, lo esencial es la funcionalidad, y lo no esencial es la plataforma tecnológica. 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 Development (MDD)). 3

Agenda Introducción Model Driven Development (MDD). Model Driven Architecture (MDA). Agile MDD. Agile MDA. Proceso Desarrollo (AUP). AndroMDA. MDA en I2E. Ejemplos y Demostración. 4

Model Driven Development MDD es un estilo de desarrollo de software donde el artefacto primario son los modelos, a partir de los cuales se obtiene el código y otros artefactos. Los modelos se usan para pensar en el dominio del problema y en el dominio de la solución. Además de crear los modelos, podemos crear reglas para automatizar la transformación de estos modelos en otros, este estilo de MDD es conocido como Model Driven Architecture (MDA). 5

Model Driven Development MDD usa los modelos para capturar los requerimientos, y automatizar parcial o totalmente la implementación. 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ón, y liberarnos de los detalles de la implementación. El esfuerzo invertido en el modelado tiene una continuidad durante el desarrollo, esto modelos no son meramente parte de la documentación sino que dirigen de forma automatizada el desarrollo del código. 6

Model Driven Development Software Factories-Assembling Applications with Patterns, Models, Frameworks, and Tools (Wiley) 7

Model Driven Development Aproximaciones al Modelado Model-Driven Software Development (Springer) 8

Model Driven Achitecture Model Driven Architecture (MDA) es un framework para el desarrollo software definido por el Object Management Group (OMG). 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 desarrollo de software esta dirigido por la actividad de modelar el software. 10

Model Driven Achitecture La aproximación MDA utiliza los estándares abiertos de modelado establecidos por la OMG’s: Unified Modeling Language (UML), Meta-Object Facility (MOF), and Common Warehouse Metamodel (CWM). Modelos independientes de la Plataforma tecnológica pueden ser construidos usando estos estándares de modelado y pueden ser transformados en plataformas empresariales libres o propietarias, incluyendo CORBA, J2EE, .NET, etc. 11

Model Driven Achitecture Tenemos 3 tipos de Modelos en función del nivel de abstracción. CIM (Computation Independent Model). Modelado del Negocio y requerimientos PIM (Platform Independent Model). Análisis y diseño independiente de la plataforma tecnológica. Un PIM se transforma en uno o mas PSM PSM (Platform Dependent Model). Diseño dependiente de la plataforma tecnológica. Cada PSM se transforma en código. 12

Model Driven Achitecture PIM Un PIM describe un sistema de software que describe un negocio. Con el PIM el sistema es modelado desde el punto de vista del negocio. El Analista suele ser el encargado de realizar el PIM que describe el sistema. PSM El PIM es transformado en uno o mas PSM, para cada plataforma tecnológica especifica se genera un PSM. El Arquitecto es el encargado de adaptar el modelo para una implementación tecnológica especifica. 13

Model Driven Achitecture Model-Driven Software Development (Springer) 14

MDA Framework UML Profiles Son extensiones para adaptar UML a un dominio particular. Introduce un conjunto de stereotypes que extienden UML. 15

MDA Framework La transformación de modelos es una parte clave de MDA. La herramienta de transformación coge un PIM y lo transforma en uno o mas PSM. Una segunda (o la misma) herramienta transforma el PSM a código. MDA Explained: The Model Driven Architecture™: Practice and Promise (Addison Wesley) 16

MDA Framework Definición de las transformaciones. QVT (Query/Views/Trasnformations) es el estándar definido por la OMG para las transformación entre modelos. 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. 17

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

Necesitamos un poco de Agilidad 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. AMDD es una estrategia critica para ir escalando los procesos de desarrollo ágiles mas allá de los proyectos pequeños. 20

Agile MDD 21

Agile MDD Aproximaciones a AMDD. Manual. Herramientas simples, como una pizarra o un papel, se realizan modelos simples. Herramienta de Diseño. Modelos simples son usados para explorar los requerimientos con los stakeholders, y para analizar los requerimientos. Agile MDA. Herramientas MDA de modelado se usan para crear modelos extensivos desde los cuales se generan código ejecutable. 22

Agile MDA 24

Necesitamos un Proceso de Desarrollo Agile Unified Process (AUP) Es una versión simplificada de RUP Aplica técnicas ágiles incluidas Test Driven Development, AgileMDD, Agile change management. 26

AgileUP 27

Herramientas AndroMDA http://www.andromda.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 plugins de 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. El proceso de transformación se controla utilizando los plugins llamados cartridges, cada cartridge se puede modificar para adaptarlo a nuestras necesidades. 29

AndroMDA AndroMDA significa principalmente: escribir menos código manualmente. Eliminamos las tareas repetitivas y aburridas, al mismo tiempo utilizamos el modelo para comunicar realmente lo que el sistema esta haciendo. AndroMDA genera código empresarial 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 añades o modificas el código a medida. Si deseas generar artefactos a medida desde el modelo, puedes escribir un cartridge a medida. 30

AndroMDA Existen 2 componentes primarios usados en el sistema de AndroMDA: 1)AndroMDA code generation engine. El engine es una plataforma que contiene los módulos de código (llamados cartridges) que realizan la generación del código. 31

AndroMDA 2) Apache’s Maven project builder Cartridges: and management system. BPM4Struts Una serie de plugins de Maven para el simplificar el procesos de uso de jBPM AndroMDA. JSF EJB Cartridges Hibernate Son los plugins primarios del framework Java AndroMDA. Los cartridges procesan los Meta elementos del modelo que tienen unos stereotypes específicos (i.e. <<Entity>>, Spring <<Enumeration>>, etc.) o elementos del WebService modelo que cumplen ciertas condiciones XmlSchema inferidas del mismo (por ejemplo, todos los actores que tienen una dependencia con un<<Service>>). Cartridges procesan estos elementos del modelo usando los ficheros de plantillas definidos en el descriptor del cartridge. 32

AndroMDA configuracion AndroMDA El engine de AndroMDA esta 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. 33

AndroMDA Creando el modelo con UML La generación de código en AndroMDA esta dirigida por los esterotipos UML. Si encuentra un estereotipo reconocido, llama al cartridge para generar el código. Para simplificar el modelado, ha sido desarrollado un Profile de UML el cual debe ser incluido como parte de tu modelo. Este profile contiene los estereotipos necesarios para poder modelar. No genera el 100% del código ejecutable, debemos de implementar manualmente la lógica de negocio. 34

Herramientas MagicDraw Utilizamos magicDraw para la realización de los diagramas UML. AndroMDA esta perfectamente integrada con MagicDraw, nos proporciona los profiles para utilizarlos directamente desde MagicDraw. Es la herramienta que recomiendan el equipo de AndroMDA. Eclipse Utilizamos eclipse para el desarrollo de código. Gforge5 Utilizamos gforge para la gestión de los proyectos. 35

Agenda Introducción Model Driven Development (MDD). Model Driven Architecture (MDA). Agile MDD. Agile MDA. Proceso Desarrollo (AUP). Herramientas (AndroMDA). MDA en I2E. Descripción del proceso utilizado Descripción de los proyectos. Una iteración en el proceso. Ejemplos y Demostración. 36

MDA en I2E Se utiliza el proceso de desarrollo AUP, con unas pequeñas modificaciones para poder introducir AndorMDA. Equipo de desarrollo compuesto por 1 Jefe de Proyecto, 1 Jefe de Soporte, 1 Jefe de Calidad, 1 Jefe de Desarrollo, 1 Jefe de Seguridad y 1 Jefe de Implantación. El Jefe de Desarrollo es el que lleva el gran peso de desarrollo de la aplicación ya que a su cargo están los analistas, arquitectos, desarrolladores y diseñadores gráficos. Se elaboran 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 el código de negocio. 37

MDA en I2E Disponemos de tareas de ant para la compilación, el deploy en el servidor de aplicaciones ,la ejecución de test automáticos. También se han creado tareas de cobertura de los test, para comprobar cuanto código de servidor esta testeado. 38

MDA en I2E Ejemplo de una iteración en el proceso de desarrollo (AUP). Actividades (tareas) a realizar para cada una de las disciplinas. Entorno Tareas relacionadas con la puesta a punto del entorno de desarrollo, maquinas, herramientas etc… Gestión de la configuración El sistema CVS realiza casi todo por nosotros. Requerimientos Se toman nuevos requerimientos o se modifican los existentes. 39

MDA en I2E Modelar Primero realizamos un esbozo en pizarra o en papel, en caso de que no tengamos claro como vamos a modelar los requerimientos. Intentamos integrar a todos los participantes del proyecto en la realización de este primer esbozo. Una vez obtenido el esbozo utilizamos MagicDraw para realizar el modelo. 40

MDA en I2E Modelar Realizamos 3 diagramas de clases Diagrama con las entidades <<Entity>>. Diagrama con los servicio <<Service>>. 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. 41

MDA en I2E Modelar Una vez hemos finalizado el modelado, utilizamos las tareas de ant para generar el código y copiarlo al proyecto de desarrollo. En función de cómo hayamos configurado el proyecto de AndroMDA generara el código sobre una arquitectura u otra. Ejemplo arquitectura 42

MDA en I2E Modelar Código y ficheros de configuración generados 43

MDA en I2E Implementación Una vez hemos generado el código, implementamos la lógica de negocio y las consultas. AndroMDA nos proporciona el esqueleto sobre el cual implementar las funcionalidades del negocio, también nos proporciona ciertas funcionalidades ya implementadas. Este código se implementa en los métodos de las clases Impl generadas por AndroMDA. 44

MDA en I2E Implementación y Test Para la implementación podemos seguir la metodología Test Driven Development, realización del test antes de la implementación. Estos test se ejecutan desde un entorno de integración continua. 45

MDA en I2E Cobertura de los Test Utilizamos la Herramienta Cobertura para obtener el % de código cubierto por los test automáticos. Gracias a los informes obtenidos podemos observar que partes del código están sin probar. Análisis estático del Código Utilizamos Herramientas como findbugs 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. Estas Herramienta también nos pueden servir para mejorar la calidad del código generado automáticamente por la herramienta MDA. 46

MDA en I2E Integración Continua Con la integración continua automatizamos la compilación de la aplicación, los test, el análisis estático del código y la obtención del instalable. Gracias a la integración continua podemos ir controlando la evolución de la aplicación de una forma automatizada. Utilizamos Cruise Control como servidor de integración. 47

Proceso de Desarrollo 48

Ejemplo Aplicaciones ERP suministros eléctricos y domoticos 50

Ejemplo Aplicaciones Gestión de un Laboratorio de Farmacia 51

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

Gracias por su Atención José Luís Ramírez Terry Emilio Bravo García http://www.i2e.com.es 53

Presentacion Mda

4 comments

Notes on slide 1

3 Favorites