Desarrollo de Software conducido por Modelos

Presentación del tema: "Desarrollo de Software conducido por Modelos"— Transcripción de la presentación:

1 Desarrollo de Software conducido por Modelos
Quinto Congreso Internacional en Innovación Tecnológica Informática Facultad de Tecnología Informática y CAETI Universidad Abierta Interamericana (UAI) Desarrollo de Software conducido por Modelos Good morning. I am going to present the PhD Thesis titled “On the Functional Size Measurement of Object-Oriented Conceptual Schemas: Design and Evaluation Issues”. This research work was conducted in the context of the OO-Method Research Group and the company CARE Technologies. Dra. Claudia Pons 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 … Uso de funciones en aplicaciones instaladas: El término crisis del software se acuñó en 1968, en la primera conferencia organizada por la OTAN sobre desarrollo de software (en esa misma conferencia también se acuañó el término Ingeniería de Software). El término fue acuñado por F. L. Bauer, aunque ya había sido usado antes por Edsger Dijkstra en su obra The Humble Programmer (catalogada en la obra de Dijkstra como EWD 340). Básicamente, la crisis del software se refiere a la dificultad en escribir programas libres de defectos, fácilmente comprensibles, y que sean verificables. ¿Por qué muchos Sistemas de Software históricamente no han cumplido con las expectativas? Assembler, Third Generation Languages, Relational Databases, Declarative Programming, Methodologies and CASE tools (Structured Analysis and Design, Object-Oriented Modeling, UML-based), Component-based Programming, Aspect-based, Agent-Oriented, Extreme Programming, Agile Methods, Requirements Engineering, Web Engineering… Pero siempre el mismo fantasma en la opera…. Crisis del Software!!! El proceso de desarrollo no ha cambiado mucho en los últimos 40 años… Fuente: Jim Johnson of the Standish Group, Keynote Speech XP 2002 Buenos Aires, 18 de Septiembre de 2007

3 Buenos Aires, 18 de Septiembre de 2007
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 Buenos Aires, 18 de Septiembre de 2007
¿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 problema correcto, correctamente” El problema real La especificación La implementación Order Item Ship via Requirements Ingenieros de Software : analistas, diseñadores, arquitectos Usuarios/clientes programadores 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 problema correcto, 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 ¿Por qué los MFs no han sido adoptados masivamente en la industria?
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 Buenos Aires, 18 de Septiembre de 2007
MDD: una alternativa interesante “sólo necesitamos resolver el problema correcto, 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 Buenos Aires, 18 de Septiembre de 2007
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 Buenos Aires, 18 de Septiembre de 2007
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 Buenos Aires, 18 de Septiembre de 2007
¿Qué es un modelo de software? A description of (part of) a system written in a well-defined language. (Equivalent to specification.) [Kleppe, 2003] An specification of 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 Buenos Aires, 18 de Septiembre de 2007
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 El gran desafío MODELOS: de contemplativos a productivos
Code C# "from human-readable to computer-understandable“ J. Bézivin Buenos Aires, 18 de Septiembre de 2007

14 Mapear modelos a plataformas múltiples y evolutivas
MDD la nueva visión de OMG Mapear modelos a plataformas múltiples y evolutivas Modelos independientes de la plataforma, basados en MOF 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 Buenos Aires, 18 de Septiembre de 2007
El PIM en detalle Buenos Aires, 18 de Septiembre de 2007

19 Buenos Aires, 18 de Septiembre de 2007
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 Buenos Aires, 18 de Septiembre de 2007
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 El atajo de los programadores código testeo deployment código Buenos Aires, 18 de Septiembre de 2007

23 Buenos Aires, 18 de Septiembre de 2007
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 deployment código Buenos Aires, 18 de Septiembre de 2007

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

25 Necesitamos algunos elementos …
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 Buenos Aires, 18 de Septiembre de 2007
Herramientas para MDD OptimalJ PIM -> J2EE. ArcStyler PIM -> J2EE , .NET. AndroMDA open 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 Buenos Aires, 18 de Septiembre de 2007
PAMPA en Visual Studio DSL Domain-Specific Language Tools 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 Buenos Aires, 18 de Septiembre de 2007
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) Most new ideas in software developments are really new variations on old ideas. 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! 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) ¿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: 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. 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