Desarrollo de Software conducido por Modelos

1. Quinto Congreso Internacional en Innovación Tecnológica InformáticaFacultad de Tecnología Informática y CAETI Universidad Abierta Interamericana (UAI) Dra. Claudia Pons Desarrollo de Software conducido por Modelos LIFIA – Facultad de Informática, UNLP CAETI- Universidad Abierta Interamericana CONICET - Consejo Nacional de investigaciones Científicas y Técnicas Buenos Aires, 18 de Septiembre de 2007

2. Uso de funciones en aplicaciones instaladas: La crisis del software comenzó en los 60’s … Fuente: Jim Johnson of the Standish Group, Keynote Speech XP 2002 Buenos Aires, 18 de Septiembre de 2007

3. El costo de la baja calidad • El NIST (National Institute of Standards and Technology) reporta que al menos $350 Billón se pierden cada año en IT, en el mundo* • Proyectos abandonados; • Proyectos que no terminan en plazo; • Proyectos que no se ajustan al presupuesto inicial; • Baja calidad del software generado: • Software que no cumple con las especificaciones; • Rectificación de errores; • Perdidas como consecuencia de errores y fallas; • Código difícil de mantener que dificulta la gestión y evolución del proyecto. • No todo esto puede evitarse con mejores procesos • Errores operacionales • Condiciones de negocio muy cambiantes • Ahorro potencial: al menos $200 Billón por año *Fuente: Giga Group, Gartner Group, Standish Group, CCTA, Brunel University Buenos Aires, 18 de Septiembre de 2007

4. ¿Por qué construir software es tan difícil? • El elemento humano: • Requerimientos inconsistentes e incompletos; • Condiciones de negocio cambiantes; • Contexto de uso cambiante; • Necesidad de trabajar colaborativamente. • El elemento matemático: • No-determinismo • Externo debido a los inputs • Interno debido a la concurrencia • Enorme conjunto de comportamientos • Aunque los requerimientos fuesen completos, no-cambiantes • y formalmente especificados, es imposible analizar todos los comportamientos. Buenos Aires, 18 de Septiembre de 2007

5. Pero…no parece tan difícil! “sólo necesitamos resolver el problemacorrecto, correctamente” El problema real La especificación La implementación Order Item Ship via Requirements Ingenieros de Software : analistas, diseñadores, arquitectos programadores Usuarios/clientes Descripción informal, y por lo tanto, no verificable Testing, prueba y error Buenos Aires, 18 de Septiembre de 2007

6. Técnicas y herramientas formales al rescate! “sólo necesitamos resolver el problemacorrecto, correctamente” El problema real La especificación La implementación Order Item Ship via Requirements Lenguajes formales de especificación : Z, VDM, B Verificación formal y derivación de propiedades Refinement calculus Derivacion automatica de programas Vs. Hoare’s Logics Verificacion formal de programas Buenos Aires, 18 de Septiembre de 2007

7. Pero…. • El desarrollo de sistemas usando métodos formales lleva a sistemas robustos y consistentes, y facilita la verificación por parte del usuario, disminuyendo los defectos importantes. Entonces ¿Por qué los MFs no han sido adoptados masivamente en la industria? • Porque su adopción requiere: • estándares aceptados mundialmente; • metodologías claras y sencillas; • herramientas de soporte. Buenos Aires, 18 de Septiembre de 2007

8. MDD: una alternativa interesante “sólo necesitamos resolver el problemacorrecto, correctamente” El problema real El modelo La implementación Order Item Ship via Requirements Model Driven Development (MDD) promueve la separación de la especificación de la funcionalidad del negocio de la implementación de esta funcionalidad en plataformas específicas. Los modelos son los conductores primarios en todos los aspectos del desarrollo de software. Buenos Aires, 18 de Septiembre de 2007

9. Los modelos en las ingenierías tradicionales Veamos que cosa es un modelo… • Los modelos son tan antiguos como las Ingenierías • Los ingenieros “tradicionales” siempre construyen modelos antes de construir sus obras y artefactos Los modelos sirven para: • Especificar el sistema • • Estructura, comportamiento,… • • Comunicarse con los distintos stakeholders • Comprender el sistema (si ya existe) • Razonar y validar el sistema • • Prototipado (ejecutar el modelo) • • Inferir y demostrar propiedades • • Detectar errores y omisiones en el diseño • Guiar la implementación Buenos Aires, 18 de Septiembre de 2007

10. Características de los modelos [Selic, 2003] • Abstractos • Enfatizan ciertos aspectos, mientras que ocultan otros • Comprensibles • Expresados en un lenguaje comprensible • por los usuarios y stakeholders • Precisos • Fieles representaciones del • objeto o sistema modelado • Predictivos • Deben de poder ser usados • para inferir conclusiones • correctas • Baratos • Más fáciles y baratos de construir • y estudiar que el propio sistema Buenos Aires, 18 de Septiembre de 2007

11. ¿Qué es un modelo de software? • A descriptionof (part of) a system written in a well-defined language. (Equivalent to specification.) [Kleppe, 2003] • An specificationof the system and its environment for some certain purpose. A model is often presented as a combination of drawings and text. [MDA Guide, 2003] Buenos Aires, 18 de Septiembre de 2007

12. Limitaciones actuales de los modelos (de software) • Sólo se usan como documentación • Que además no se actualiza! • “Gap” entre el modelo y la implementación del sistema • - Grandes diferencias semánticas en los lenguajes respectivos • - No hay herramientas de propagación automática de cambios • • Cambios en el modelo no se reflejan en el código • • Cambios en el código no se reflejan en el modelo • Los distintos modelos del sistema no se armonizan • - Suponen vistas de un mismo sistema, pero no hay forma de relac. • - No hay herramientas de integración de modelos • - el lenguaje de cada vista tiene una semántica distinta del resto • No hay ni lenguajes ni herramientas para manejar modelos • - Solo editores, pero no hay “compiladores”, “optimizadores”, • “validadores”, “transformadores de modelos”, etc. Buenos Aires, 18 de Septiembre de 2007

13. Code C# El gran desafío MODELOS: de contemplativos a productivos "from human-readable to computer-understandable“ J. Bézivin Buenos Aires, 18 de Septiembre de 2007

14. MDD la nueva visión de OMG Mapear modelos a plataformas múltiples y evolutivas Modelos independientes de la plataforma, basados en MOF http://www.omg.org/mda • MOF/UML como base estándar. • Valores organizacionales expresados como modelos • Trasformación de modelos para su mapeo a plataformas específicas. Buenos Aires, 18 de Septiembre de 2007

15. La idea central de MDD: PIMs & PSMs • Platform Independent Model (PIM) “Un modelo de un sistema que no contiene información acerca de la plataforma o la tecnología que es usada para implementarlo” • Platform Specific Model (PSM) “Un modelo de un sistema que incluye información acerca de la tecnología especifica que se usará para su implementación sobre una plataforma especifica” • Transformación de modelos especifica el proceso de conversión de un modelo en otro modelo del mismo sistema. Cada transformación incluye (al menos): • un PIM, • un Modelo de la Plataforma, • una Transformación, y • un PSM Buenos Aires, 18 de Septiembre de 2007

16. MDD: aplicando transformaciones sucesivas • El patrón MDD es normalmente utilizado sucesivas veces para producir una sucesión de transformaciones. • Un PSM resultante de la aplicación de una transformación será el PIM en la siguiente transformación. Buenos Aires, 18 de Septiembre de 2007

17. Ejemplo: Servicio de Desayuno de Rosa • Datos a ingresar: Hora y Lugar de entrega. • Elegir uno de los desayunos de la página web. • Posibilidad de pagar con tarjeta. • Un mismo pedido puede ser para distinta cantidad de personas y distintos tipos de desayunos. • Estilos: Simple, Mejorado o Deluxe • Flexibles: Es posible agregar cantidad de ingredientes, quitar otros. • Algunos desayunos no admiten estilo simple. • Rosa tiene 10 empleados que entran a las 5 de la mañana, 5 preparan desayunos y 5 los entregan. • En stock están todos los ingredientes menos el pan que se compra en una panadería cerca de Rosa. Buenos Aires, 18 de Septiembre de 2007

18. El PIM en detalle Buenos Aires, 18 de Septiembre de 2007

19. Capas de la Aplicación Interfase de Usuario Java Server Pages (JSP) De negocios Enterprise Java Beans (EJB) Base de Datos Relacional Buenos Aires, 18 de Septiembre de 2007

20. MDD – del PIM al PSM • PIM conceptos sin nivel tecnológico • PSM son dependientes de la plataforma • CODIGO específico para la plataforma Como cada capa usa una tecnología diferente se crean 3 PSM uno para cada capa. Corresponde a la capa de Base de Datos. Y el modelo será un DER Se crean modelos de UML con estereotipos para el EJB Se crean modelos de UML con estereotipos para WEB Buenos Aires, 18 de Septiembre de 2007

21. ¿Cómo influye MDD en el ciclo de vida del software? Buenos Aires, 18 de Septiembre de 2007

22. El ciclo de vida tradicional requerimientos Básicamente texto Proceso iterativo (en teoría) análisis texto y diagramas diseño texto y diagramas codificación código El atajo de los programadores testeo código deployment Buenos Aires, 18 de Septiembre de 2007

23. El ciclo de vida MDD requerimientos Básicamente texto análisis PIM Diseño automático PSM Codif. automática código Testeo automático código deployment Buenos Aires, 18 de Septiembre de 2007

24. Pongamos MDD en marcha ¿ ¿Cómo se hace? Buenos Aires, 18 de Septiembre de 2007

25. Pongamos MDD en marcha Necesitamos algunos elementos … Buenos Aires, 18 de Septiembre de 2007

26. Definiendo el lenguaje de modelado y el repositorio de modelos • MOF • UML y sus Profiles • EMF (eCORE) • XMI • DSL Tools. Domain Model Editor Buenos Aires, 18 de Septiembre de 2007

27. Meta Object Facility (MOF) - eCORE (light MOF) Buenos Aires, 18 de Septiembre de 2007

28. XML Metadata Interchange (XMI) Formalismo para almacenar modelos MOF usando XML Objetivo: compartir Modelos Ejemplo: Buenos Aires, 18 de Septiembre de 2007

29. Definiendo los editores gráficos • Manual Programming • GEF • GMF • DSL Tools. Model Designer Buenos Aires, 18 de Septiembre de 2007

30. Definiendo los editores gráficos Eclipse Modelling Framework + Graphical Modeling Framework EMF es un framework para definición de lenguajes de modelado y generación de código a partir de los modelos. Implementa eCore. GMF es un framework para definición de la sintaxis grafica del lenguaje Buenos Aires, 18 de Septiembre de 2007

31. Definiendo los editores gráficos DSL Tools - Model Designer • Microsoft DSL Tools permiten definir lenguajes gráficos. • sintaxis abstracta (metamodelo) en una notación propietaria. • XML como mecanismo de persistencia. Buenos Aires, 18 de Septiembre de 2007

32. Transformando de Modelo a Modelo • Programación manual (ej. en Java) • QVT • ATL • MTF • AGG (graph transformation) Buenos Aires, 18 de Septiembre de 2007

33. Ejemplo de transformación - Lenguaje QVT Buenos Aires, 18 de Septiembre de 2007

34. Transformando de Modelo a Código • Programación manual • MOF2Text • MOFScript Buenos Aires, 18 de Septiembre de 2007

35. Transformando de Modelo a Código Ejemplo: generación de código C# a partir de un diagramas UML Buenos Aires, 18 de Septiembre de 2007

36. Herramientas para MDD • OptimalJ PIM -> J2EE. • ArcStyler PIM -> J2EE , .NET. • AndroMDAopen source tool PIM -> J2EE, Spring, .NET • Rational Architect PIM -> PIM, J2EE , .NET. • ATL/ TMF EMF Transformation Engines PIM -> PIM • MS DSL tools Microsoft Domains Specific Languages Buenos Aires, 18 de Septiembre de 2007

37. Nuestro aporte al área: el proyecto PAMPA Precise Assistant for the Modeling Process Activities PAMPA es un proyecto de desarrollo de herramientas de soporte para el desarrollo de software dirigido por modelos, usando notaciones gráficas con fundamentos formales. Buenos Aires, 18 de Septiembre de 2007

38. Funcionalidad de PAMPA • Edición de Modelos UML. • Persistencia de Modelos. • Serialización de Modelos en XMI • Evaluación de restricciones en OCL. • Generación de Código. • Refinamiento de Modelos. • Refinamiento de Invariantes y aserciones de prueba. • Traducción a otros lenguajes de especificación formal (como Z). • Transformación de Modelos. Buenos Aires, 18 de Septiembre de 2007

39. PAMPA en Visual Studio DSL Domain-SpecificLanguage Tools http://www.frlp.utn.edu.ar/pampa Buenos Aires, 18 de Septiembre de 2007

40. PAMPA en Eclipse http://portal-lifia.info.unlp.edu.ar/eclipse • Creación de artefactos UML. • Visualización de errores. • Especificación de refinamientos de modelos. Refinement specification Project Explorer OCL Evaluation Errors Properties of Selected Element Buenos Aires, 18 de Septiembre de 2007

41. PAMPA en Eclipse Especificación en OCL: invariantes, pre y post condiciones Buenos Aires, 18 de Septiembre de 2007

42. ¿ MDD es una buena alternativa? OBJETIVOS ESTRATEGICOS SOLUCIONES TECNOLOGICAS (eficiencia y efectividad) (MDD) • Preservar las inversiones en Software, luchando contra la obsolescencia tecnológica. • Manejar la explosión de la complejidad. • Capitalizar la experiencia y conocimientos. • Bajar los costos y mejorar la calidad. • Facilitar la colaboración con terceros • Separar los aspectos del dominio de los aspectos de la tecnología. • El conocimiento queda registrado en los modelos y las transformaciones y puede ser reusado. • Se automatizan partes significantes del proceso . Favorece la corrección del producto final. • Implementación de componentes usables por otras partes Buenos Aires, 18 de Septiembre de 2007

43. Conclusiones (1) • MDD es una opción muy prometedora para desarrollo de software ! • Conceptualmente clara y bien definida. • Protege las inversiones al separar el modelo del negocio de las tecnologías de soporte. • - costos y + calidad • Pero MDD no es la panacea … • No es posible generar código automáticamente al 100% • Las transformaciones son complejas y difíciles de definir! • No es claro como transformar comportamiento. • No es claro como manejar sistemas legados. • Hace falta continuar investigando e implementar herramientas de soporte! Most new ideas in software developments are really new variations on old ideas. Jornadas de Investigación y Desarrollo en Ingeniería de Software – JIDIS Buenos Aires – 18 de Abril de 2006 Buenos Aires, 18 de Septiembre de 2007

44. Conclusiones (2) • El desarrollo de MDD cuenta con el apoyo del OMG (abierto, internacional y con participación de la industria). • MDD esta respaldado por la comunidad de software tool vendors; incluyendo Microsoft, IBM y Sun; quienes soportan los principales estándares (UML, XMI, MOF, CWM) que MDD involucra. • MDD no intenta reemplazar otros paradigmas, lenguajes o herramientas, sino armonizarse con ellos. ¿Corremos el riesgo de que MDD no cumpla sus promesas y se transforme en otro acrónimo pasado de moda? Hay buenas razones para pensar que MDD será diferente de la miríada de acrónimos que fluyen en la comunidad del software: Jornadas de Investigación y Desarrollo en Ingeniería de Software – JIDIS Buenos Aires – 18 de Abril de 2006 Buenos Aires, 18 de Septiembre de 2007