Desarrollo de Software

1
Quinto Congreso Internacional en Innovación
Tecnológica InformáticaFacultad de Tecnología
Informática y CAETI Universidad Abierta
Interamericana (UAI)

• Desarrollo de Software
• conducido por Modelos

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 60s
Fuente Jim Johnson of the Standish Group,
Keynote Speech XP 2002
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
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.

5
Perono 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
programadores
Usuarios/clientes
Descripción informal, y por lo tanto, no
verificable
Testing, prueba y error
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. Hoares Logics Verificacion formal
de programas
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.

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

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

11
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

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.

13
El gran desafío
MODELOS de contemplativos a productivos
"from human-readable to computer-understandable J
. Bézivin
14
Mapear modelos a plataformas múltiples y
evolutivas
MDD la nueva visión de OMG
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.

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

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.

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.

18
El PIM en detalle
19
Capas de la Aplicación
Interfase de Usuario Java Server Pages (JSP)
De negocios Enterprise Java Beans (EJB)
Base de Datos Relacional
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
21
Cómo influye MDD en el ciclo de vida del
software?
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
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
24
Pongamos MDD en marcha
Cómo se hace?
25
Pongamos MDD en marcha
Necesitamos algunos elementos
26
Definiendo el lenguaje de modelado y el
repositorio de modelos

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

27
Meta Object Facility (MOF) - eCORE (light MOF)
28
XML Metadata Interchange (XMI)
Formalismo para almacenar modelos MOF usando
XML Objetivo compartir Modelos
Ejemplo
29
Definiendo los editores gráficos

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

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

32
Transformando de Modelo a Modelo

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

33
Ejemplo de transformación - Lenguaje QVT
34
Transformando de Modelo a Código

• Programación manual
• MOF2Text
• MOFScript

35
Transformando de Modelo a Código
Ejemplo generación de código C a partir de un
diagramas UML
36
Herramientas para MDD

• OptimalJ PIM -gt J2EE.
• ArcStyler PIM -gt J2EE , .NET.
• AndroMDA open source tool PIM -gt J2EE, Spring,
  .NET
• Rational Architect PIM -gt PIM, J2EE , .NET.
• ATL / TMF EMF Transformation Engines PIM -gt
  PIM
• MS DSL tools Microsoft Domains Specific Languages

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

39
PAMPA en Visual Studio
DSL Domain-Specific Language Tools
http//www.frlp.utn.edu.ar/pampa
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
41
PAMPA en Eclipse
Especificación en OCL invariantes, pre y post
condiciones
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

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