Buenos Aires, 18 de Septiembre de 2007 Desarrollo de Software conducido por Modelos Quinto Congreso...

Buenos Aires, 18 de Septiembre de 2007

Desarrollo de Software

conducido por Modelos

Quinto Congreso Internacional en Innovación Tecnológica InformáticaQuinto Congreso Internacional en Innovación Tecnológica InformáticaFacultad de Tecnología Informática y CAETI Facultad de Tecnología Informática y CAETI

Universidad Abierta Interamericana (UAI)Universidad Abierta Interamericana (UAI)

LIFIA – Facultad de Informática, UNLP

CAETI- Universidad Abierta Interamericana

CONICET - Consejo Nacional de investigaciones Científicas y Técnicas

Dra. Claudia Pons


Uso de funciones en aplicaciones instaladas:

Never45%

Rarely19%

Sometimes16%

Often13%

Always7%

Fuente: Jim Johnson of the Standish Group, Keynote Speech XP 2002

La crisis del software comenzó en los 60’s …


*Fuente: Giga Group, Gartner Group, Standish Group, CCTA, Brunel University

•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

El costo de la baja calidad


¿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-determinismoExterno debido a los inputsInterno debido a la concurrencia

• Enorme conjunto de comportamientosAunque los requerimientos fuesen completos, no-cambiantes y formalmente especificados, es imposible analizar todos los comportamientos.


“sólo necesitamos resolver el problema correcto, correctamente”

programadores

Order

Item

Ship viaRequirements

Ingenieros de Software :analistas, diseñadores, arquitectosUsuarios/clientes

El problema real La especificación La implementación

Descripción informal, y por lo tanto, no verificable

Testing, prueba y error

Pero…no parece tan difícil!



Order

Item


El problema real La especificación La implementación

Técnicas y herramientas formales al rescate!

Lenguajes formales de especificación : Z, VDM, B

Verificación formal y derivación de propiedades

Refinement calculusDerivacion automatica de

programasVs.

Hoare’s LogicsVerificacion formal de

programas


• 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.

Pero….



Order

Item


El problema real El modelo La implementación

MDD: una alternativa interesante

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.

: ClientCompany Order

makeOrder new

Order Item

**

ClientmakeOrder


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 stakeholdersComprender 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ñoGuiar la implementación

Los modelos en las ingenierías tradicionales

Veamos que cosa es un modelo…


Abstractos Enfatizan ciertos aspectos, mientras que ocultan otrosComprensibles Expresados en un lenguaje comprensible por los usuarios y stakeholdersPrecisos Fieles representaciones del objeto o sistema modeladoPredictivos Deben de poder ser usados para inferir conclusiones correctasBaratos Más fáciles y baratos de construir y estudiar que el propio sistema

[Selic, 2003]

Características de los modelos


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]

: ClientCompany Order

makeOrder new

Order Item

**

ClientmakeOrder

¿Qué es un modelo de softwarede 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.

Limitaciones actuales de los modelos (de software))


Code C#

"from human-readable to computer-understandable“J. Bézivin

El gran desafío

MODELOS: de contemplativos a productivos


Mapear modelos a plataformas múltiples y evolutivas

MOF/UML como base estándar.

Valores organizacionales expresados como modelos

Trasformación de modelos para su mapeo a plataformas específicas.

Modelos independientes de la plataforma, basados en MOF http://www.omg.org/mda

MDD la nueva visión de OMG


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


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.


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.


El PIM en detalle


Capas de la Aplicación

Interfase de Usuario

Java Server Pages (JSP)

Interfase de Usuario

Java Server Pages (JSP)

De negocios

Enterprise Java Beans (EJB)

De negocios

Enterprise Java Beans (EJB)

Base de Datos

Relacional

Base de Datos

Relacional


MDD – del PIM al PSM

Como cada capa usa una tecnología diferente se crean 3 PSM uno para cada capa.

Corresponde a la capade Base de Datos.

Y el modelo será un DER

Se crean modelos de UMLcon estereotipos para el EJB

Se crean modelos de UMLcon estereotipos para WEB

• PIM conceptos sin nivel tecnológico

• PSM son dependientes de la plataforma

• CODIGO específico para la plataforma


¿ Cómo influye MDD en el ciclo de vida del software?


El ciclo de vida tradicional

requerimientos

análisis

diseño

codificación

testeo

deployment

Proceso iterativo(en teoría)

El atajo de losprogramadores

Básicamente texto

texto ydiagramas

texto ydiagramas

código

código


El ciclo de vida MDD

requerimientos

análisis

Diseño automático

Codif. automática

Testeo automático

deployment

Básicamente texto

PIM

PSM

código

código


Pongamos MDD en marcha

¿ ¿ Cómo se hace?


Pongamos MDD en marcha

Necesitamos algunos elementos …


Definiendo el lenguaje de modelado y el repositorio de modelos

•MOF•UML y sus Profiles•EMF (eCORE)•XMI•DSL Tools. Domain Model Editor


Meta Object Facility (MOF) - eCORE (light MOF)


XML Metadata Interchange (XMI)

Formalismo para almacenar modelos MOF usando XMLObjetivo: compartir Modelos

Ejemplo:


Definiendo los editores gráficos

• Manual Programming• GEF• GMF• DSL Tools. Model Designer



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

Eclipse Modelling Framework + Graphical Modeling Framework



•Microsoft DSL Tools permiten definir lenguajes gráficos.•sintaxis abstracta (metamodelo) en una notación propietaria.•XML como mecanismo de persistencia.

DSL Tools - Model Designer


Transformando de Modelo a Modelo

• Programación manual (ej. en Java)• QVT• ATL• MTF• AGG (graph transformation)


Ejemplo de transformación - Lenguaje QVT


Transformando de Modelo a Código

• Programación manual• MOF2Text • MOFScript


Transformando de Modelo a Código

Ejemplo: generación de código C# a partir de un diagramas UML


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


Precise

Assistant for the

Modeling

Process

Activities

Nuestro aporte al área: el proyecto PAMPA

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.


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.


PAMPA en Visual Studio

http://www.frlp.utn.edu.ar/pampa

DSLDomain-Specific Language Tools


PAMPA en Eclipse

Project Explorer

Properties of Selected Element

OCLEvaluation

Errors

Refinementspecification

•Creación de artefactos UML.Creación de artefactos UML.•Visualización de errores.Visualización de errores.• EspecificaciónEspecificación de refinamientos de modelos.

http://portal-lifia.info.unlp.edu.ar/eclipse


PAMPA en Eclipse

Especificación en OCL: invariantes, pre y post condiciones


¿ MDD es una buena alternativa?

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

OBJETIVOS ESTRATEGICOS SOLUCIONES TECNOLOGICAS

• 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

(eficiencia y efectividad) (MDD)


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!

Jornadas de Investigación y Desarrollo en Ingeniería de Software – JIDIS

Buenos Aires – 18 de Abril de 2006

Most new ideas in software developments are really new variations on old ideas.


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.

Jornadas de Investigación y Desarrollo en Ingeniería de Software – JIDIS

Buenos Aires – 18 de Abril de 2006

¿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:

Buenos Aires, 18 de Septiembre de 2007 Desarrollo de Software conducido por Modelos Quinto Congreso...

Documents

Transcript of Buenos Aires, 18 de Septiembre de 2007 Desarrollo de Software conducido por Modelos Quinto Congreso...