Loading…

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

Like this presentation? Why not share!

Like this? Share it with your network

Share

026 Estado Del Arte De Mdd Model Driven Development

on

  • 3,738 views

 

Statistics

Views

Total Views
3,738
Views on SlideShare
3,682
Embed Views
56

Actions

Likes
2
Downloads
131
Comments
1

4 Embeds 56

http://www.slideshare.net 30
http://www2.gxtechnical.com 23
https://twimg0-a.akamaihd.net 2
https://si0.twimg.com 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
  • Muy bueno
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Desarrollo de SW: ¿Arte o Ingeniería? - ¿Somos artesanos? ¿La calidad de nuestros productos depende de artesanos y artistas: de la inspiración y del genio creativo? - ¿O somos ingenieros? ¿Tenemos un método reproducible para la construcción? ¿La calidad no depende tanto de la creatividad del individuo sino de que el método sea correctamente aplicado? ¿Y la arquitectura? ¿Es arte o es ingeniería? (Ej. Calatrava / VLC CaC) Tal vez seamos a la vez artistas e ingenieros (o eso me gusta pensar). Lo que fabricamos ha de ser funcional y operativo, sin renunciar a la belleza y al diseño emocional. El mundo del siglo XXI, la llamada Sociedad del Conocimiento demanda cada vez más SW para agilizar labores de gestión, mejorar procesos productivos y mejorar nuestra calidad de vida. Necesitamos producir SW en cantidades industriales . Rápido, barato y robusto (a ser posible). Por tanto: no debemos descuidar la parte artística pero me atrevería a decir que el 90% de nuestro trabajo como en un coche o en un edificio es Ingeniera y solo un 10% de arte. (Solo un 10% aunque este 10% sin duda marque la diferencia.)
  • Fontanería. Plumbing
  • ¿Cómo podemos satisfacer la demanda mejorando al tiempo calidad, productividad y reduciendo costes?
  • ¿Podemos modelarlo todo? En el extremo ¡sín duda! Pero... ¿a qué coste? El análisis de coste/beneficio responde a la pregunta Coste de implementación frente a la frecuencia y coste de un desarrollo convencional Evitar añadir características de diseño a modelos conceptuales  Usar Modelos de diseño (PSM) en su lugar
  • Domain Knowledge: Business processes, Business rules, Information, Business driven Technological Knowledge: Technology driven, Cyclical waves

026 Estado Del Arte De Mdd Model Driven Development Presentation Transcript

  • 1. Dr. Pedro J. Molina Ingeniero de Software Capgemini España | Valencia http:// pjmolina.com / metalevel Estado del arte MDD
  • 2. Desarrollo de software:
    • ¿arte o ingeniería?
    Ciudad de las Artes y Las Ciencias. Valencia, España.
  • 3.  
  • 4. Desarrollo de Software 1/9 8/9
  • 5. Escenario actual
    • Siglo XXI, Sociedad del Conocimiento
      • Demanda SW en gran cantidad
        • De calidad, robusto, rápido ( Time to Market )
        • Más a menor precio
      • La demanda cae en épocas de crisis
    • Sin embargo el SW, en general
      • Es muy complejo  gestión de la configuración, análisis de impacto
      • Tareas repetitivas  propensas a errores ( plumbing )
      • Requiere de profesionales cualificados, experimentados y motivados .
  • 6. Agenda
    • introducción
    • qué
    • porqué
    • hoy
    • mañana
    • conclusión
    MDD Model Driven Development Desarrollo Dirigido por Modelos
  • 7. breve presentación
    • Pedro J. Molina
      • Doctor e Ingeniero en Informática por la Univ. Politécnica de Valencia, 2003
      • Tesis doctoral en Generación de código para Interfaces de Usuario en aplicaciones de negocio
      • Ingeniero Técnico en Informática de Gestión por la Univ. de Castilla-La Mancha en Albacete, 1996
    • UPV y CARE Technologies
      • Investigador de Ingeniería de SW
      • Desarrollo de generadores de código comerciales para interfaces de usuario de aplicaciones de negocio
    • Capgemini España
      • Arquitecto de SW
      • Jefe de proyectos
      • Especialista en MDD y .NET
  • 8. qué
  • 9. niveles de abstracción Código máquina COBOL / C / Basic / Java Ensamblador 4GL Modelos / Especificaciones Dominio de aplicación Gap semántico The entire history of software engineering is one of rising levels of abstraction (abstraction is the primary way we as humans deal with complexity). Grady Booch Nivel de abstracción
  • 10. ¿qué es un dominio? Implementación Especificación Requisitos Despliegue Sistemas de Gestión Sistemas de Tiempo Real Sistemas de control aéreo Sistemas de Gestión de Equipajes Sistemas de Gestión de Seguros
  • 11. ¿qué es un lenguaje? <CallRecord> <caller><number>07713248</number> Textual Gráfico Declarativo Imperativo class Factura : Documento { public void Emitir() a>b && c==d  C(x) h    C(x)  t 2m  x  ih = – Luís galletas 24 verde José pasteles 32 azul Empleado Nombre Dirección Promocionar Puesto Descripción Salario Asignar 0..* Llamada Grabación Duración  Coste min. DB
  • 12. ¿qué es un modelo?
    • Un modelo permite describir una familia de problemas dentro de un dominio dado
    • Tiene el grado de abstracción cuidadosamente seleccionado para:
      • Descartar detalles irrelevantes (reduce complejidad)
      • Descartar detalles constantes en la familia (reduce complejidad)
      • Explicitar los aspectos importantes (variables) (pero no oculta lo relevante )
    • ¿Qué es un meta-modelo?
      • Un modelo de definición de modelos.
  • 13. regla de Novak
    • “ La programación automática se define como la síntesis de un programa a partir de una especificación (o modelo).
    • Para que la programación automática sea útil , la especificación debe ser más pequeña y fácil de crear que el programa construido de la manera convencional con un lenguaje de programación.”
    • G.S. Novak
  • 14. principios de modelado
    • Tan simple como sea posible ( KISS )
      • pero expresivo
    • Semánticamente bien definido
    • Canónico ( DRY )
      • solo una manera de expresar el mismo concepto
    • Correcto nivel de abstracción
    • Separación de aspectos ( SoC )
    • Mantener modelos organizados y manejables
    • Agnóstico respecto a la tecnología
    • Punto de vista pragmático
      • si no lo vas a usar, no lo modeles, todavía
  • 15. principios para generación de código
    • Ingeniería hacia delante
      • Forward Engineering
    • El valor esta en el modelo  el código es descartable
      • Refactorizable, regenerable siempre que sea necesario
    • La tecnología cambia más rápido que los modelos
  • 16. ¿modelarlo todo?
    • Generar el 100% del código ¿Utopía?
      • Depende mucho del dominio y de lo acotado que esté
      • Posible en el 5-10% de los casos, resto aproximación del 80%-20%
      • La pregunta útil no es:
        • ¿Podemos modelarlo todo?
      • Las preguntas pragmáticas son:
        • ¿Merece la pena modelar esta característica?
        • ¿El nivel de abstracción estará todavía en sincronía con el modelo tras añadir la característica?
  • 17. ¿¡modelarlo todo!?
    • ¿Qué características deben ser añadidas a un modelo?
    • Aproximación totalmente pragmática: dirigida por la ley de Novak.
    Nueva característica propuesta al modelo ¿Puede ser modelada? Análisis de Coste/Be-neficio Cambio manual al código Proporcionar un punto de extensión al usuario en el código generado Incluir la característica en el Modelo y Editores Sí No Rentable No rentable Característica que no puede ser modelada hoy ¿La nece-sitamos? ¡Olvidalo! Sí No 1 2 3
  • 18. ¿qué (y qué no) incluir en el modelo?
    • “ Lo bueno, si breve,
    • dos veces bueno.”
        • Baltasar Gracián, (siglo XVII)
    Variable vs Inmutable
    • “ Everything should be as simple as possible,
    • but no simpler .”
        • Albert Einstein, (siglo XX)
  • 19. separation of concerns (SoC)
    • Conocimiento capturado en dos compartimentos separados:
    ¿Qué? ¿Cómo?
      • Conocimiento de negocio: capturado y encapsulado en forma de modelos (especificaciones): aislado de aspectos tecnológicos.
      • Conocimiento tecnológico: capturado y encapsulado en forma de buenas practicas, frameworks, plantillas, patrones diseño en generadores de código e interpretes.
  • 20. mapa conceptual de la generación de código Especificación Algoritmos de transformación Programas Modelos Clases / Tipos / Meta Instancias Cambia con la tecnología Cambia con el negocio Tiende a ser bastante estable Código descartable ¡AGIL! Cambia con la tecnología Tecnología Negocio Código Fuente Plantilla Meta-modelo Ingeniería Inversa Abstracción Síntesis Correspon-dencias Instanciación Abstracción
  • 21. porqué
  • 22. ROI
    • Economía de alcance
    • Economía de escala
    • El modelo económico de MDD
    • Calidad
    • Impacto en la ciclo de vida del desarrollo
  • 23. economía de escala
    • Economía de escala ( economies of scale ):
      • La condición donde pocas entradas, como esfuerzo y tiempo, son necesarias para producir grandes cantidades de una única salida . [Wit96]
      • Pero: ¡No aplica en Software!
      • Una vez producido el bien
      • ¡el coste de copia es = ¥ 0!
    Fabrica de galletas japonesa: Línea de producción.
  • 24.  
  • 25. economía de alcance
    • Economía de alcance ( economies of scope ):
      • La condición donde pocas entradas, como esfuerzo y tiempo, son necesarias para producir una gran variedad de salidas . Se produce mayor valor añadido produciendo de manera conjunta diferentes salidas. Producir cada salida de modo aislado provoca un sobrecosto en las partes comunes.
      • La economía de alcance ocurre cuando el coste de combinar dos o más productos en una sola línea de producción es menor que producirlos por separado. [Wit96]
  • 26. industrialización Producción en masa Cambio de proceso Estable Dinámico Cambio en el producto Dinámico Estable Basado en trasparencia original de: Steve Cook Economía de escala Economía de alcance Aseguramiento de la calidad Mejora del proceso Pieza única Irrepetible Arte Producto artesano Personalización en masa Mejora continua CMM Agil MDD, Factorías de SW CD, DVD, Copia de ficheros
  • 27. MDD: modelo económico Ingeniería de Dominio Ingeniería de Aplicación Entorno de desarrollo de aplicaciones Aplicaciones
    • Retroalimentación:
      • Sugerencias de los clientes
      • Sugerencias sobre el entorno de desarrollo
    Retorno (ahorro en la construcción) Inversión
  • 28. MDD: modelo económico
    • Coste tradicional = N * C T
    • Coste con MDD = Inv + N * C F
    Miembros de la familia 1 2 3 4 5 5 C T 4 C T 3 C T 2 C T C T Coste acumulado Inv Ahorro A F = C T - C F
  • 29. impacto en el ciclo de vida
    • Mas tiempo en análisis y diseño
    • Menos tiempo en codificación
    • Menos defectos, más calidad
    • Más productividad
      • ordenes de magnitud
    • Integración continua
    • Ciclos de desarrollo más ágiles
    • Menos coste
  • 30. coste de defectos y distribución Defecto Bug Característica Feature vs
  • 31. coste de defectos y distribución % Defectos Coste exponencial de los defectos Efecto Bola de nieve 1 € 2 € 4 € 8 € Análisis Diseño Construcción Mantenimiento Ciclo de vida tradicional Ciclo de vida con MDD
  • 32. hoy
  • 33. UML/MDA ¿es suficiente?
    • UML
      • Origen: notación de compromiso (propuesta de unificación)
      • OCL: lenguaje de restricciones
      • Gran aceptación, lenguaje común para ingenieros de software
    • MDA : Model Driven Architecture
      • MDA = MDD con UML
      • Propuesta de la OMG
      • Profiles
      • PIM/PSM
      • MOF / XMI
    • “ Only a 20% of UML is generally needed for SW development.” Ivar Jacobson
      • Pero: ¿Qué porcentaje de mi problema resuelve ese 20%?
    • Carencias
      • Semántica
      • Lenguaje de acción
      • Dominios no cubiertos por UML: p.e. Interfaces de usuario
      • El abuso de profiles fuerza los modelos
      • Herramientas: multitud de dialectos de XMI  Torre de Babel
      • Interoperabilidad prometida  Pesadilla
      •  DSL (Domain Specific Languages) y modelos a medida
  • 34. quién está haciendo qué
    • Eclipse EMF/GMF
      • IBM
      • SAP
    • OpenArchitectureware
      • XText
      • Itemis
    • xUML / MDA
      • Kennedy Carter
      • Blue Age
      • Artisan
      • AndroMDA
      • Olivanova Model Execution
    • Microsoft
      • DSL Tools
      • OSLO
    • MetaCase
      • MetaEdit+
    • JetBrains
      • MPS
    • Intentional Software
      • ??
    • Muchos otros
  • 35. un vistazo a Genexus desde “fuera”
    • Hechos
    • Base de conocimiento (KB)
    • Enfocado en el dominio de aplicaciones de negocio
    • DSLs en Genexus
      • entidades, modelado de datos
      • reglas de negocio
      • procedural
      • consultas (vistas sobre datos)
      • flujos de trabajo
      • interfaz de usuario
    • Modelo independiente de tecnología
    • Generación de código a múltiples entornos
    • Conclusiones
    • Ingeniería hacia a delante
    • Independencia de tecnología
    • Separación del KH de negocio del KH tecnológico
    • Diversos DSL para especificar diferentes aspectos (SoC)
    • El valor está en el “modelo de negocio” (KB)
    • Genexus es un buen ejemplo de MDD hecho realidad
  • 36. experiencias de mercado
    • Terminal Financiero
    • Cumplimiento de regulaciones
      • Frameworks / Arquitecturas cliente
      • Guías de estilo / Reglas de nombrado
      • Sabarney Oxley / Audit Trail
      • Accesibilidad AAA / Section 508
    • CUIP
      • Interfaces de usuario Multicanal
  • 37. 1. terminal financiero
    • PISA es un entorno completo de modelado construido para Bancaja sobre Visual Studio.
      • MS DSL Tools, XML Schema, gramáticas, compiladores, generadores de código a C#
    • El entorno permite modelar y desarrollar funciones de negocio para un Terminal Financiero de un banco
    • Entorno cerrado: generación de código al 100%.
    • Totalmente agnóstico respecto a la tecnología.
      • Facil de cambio de arquitectura  Cambio del generador
  • 38. 1. terminal financiero
    • Entorno de trabajo integrado en Visual Studio
  • 39. 1. terminal financiero
    • DSL: Lenguaje de acción a medida
    • Sintaxis coloreada
    • Soporte a Intelisense
  • 40. 1. terminal financiero
    • Gestión de errores integrada en Visual Studio
  • 41. 1. terminal financiero
    • Ejemplo de DSL
    • Diagrama de navegación
  • 42. 2. cumplimiento de regulaciones
    • Frameworks / Arquitecturas cliente
      • Guías de estilo / Guías de nombrado
        • Un generador las aplica SIEMPRE  Sin errores, ni olvidos
        • Más aun: cuando no existe regla, el generador proporciona una regla de facto determinista
      • MDD aporta  soluciones específicas para cada cliente
      • Sectores propicios
        • Gran volumen: Banca, Seguros, Energía, Retail, Telco, Distribución
        • Objetivo: reducir el TCO
  • 43. 2. cumplimiento de regulaciones
    • Sabarney Oxley / Audit Trail
      • Caso Enron  Cotizadas en bolsa en EE.UU.
      • Auditoria ferrera: ¿quién hizo qué cuando?
      • Caso: Cliente del sector energético
        • Tamaño: 100 clases (110 tablas)
        • Persistencia a BD con Audit-Trail
        • Diseño de solución implica 3 triggers por tabla
        • Generado al 100%. Audit-Trail como opción si/no del generador
    • Accesibilidad AAA / Section 508
      • Garantizar accesibilidad sobre IU es complejo
      • Requiere de auditorias
      • Algunas pautas de accesibilidad pueden ser incorporadas a los generadores de código
        • Garantizando que los productos producidos cumplen las pautas “ por método de construcción”
  • 44. 2. cumplimiento de regulaciones
    • Las regulaciones son aburridas
      • Obligan a los desarrolladores a tenerlas todas en cuenta a la vez y a aplicarlas en cada caso particular
      • Un olvido  no cumplimiento
      • Regulaciones = Fontanería ( Plumbing )
        • Como el hielo bajo el agua del iceberg
        • No se ve, no se valora, pero es muy trabajoso
      • Recomendación
        • Que sea la máquina la que se encargue de la mayor parte del trabajo pesado, aburrido y propenso a errores
        • Un generador garantiza el 100% de calidad y cumplimiento
  • 45. 3. CUIP
    • Patrones Conceptuales de Interfaz de Usuario (CUIP)
      • Una colección de patrones conceptuales para aplicaciones de gestión en el dominio de interfaces de usuario
      • Incrementa el nivel de abstracción en el diseño de interfaces de usuario
    • Interfaces multicanal
      • La habilidad de producir múltiples IUs para diferentes dispositivos a partir de un modelo origen común
      • Basado en Patrones Conceptuales de Interfaz de Usuario, el problema de la correspondencia se simplifica a:
        • hacer corresponder cada patrón con una solución de diseño en el dispositivo particular
  • 46. 3. CUIP
    • Más información en http://pjmolina.com/cuip
    • y en http:// pjmolina.com /es/ investigacion / tesis.php
  • 47. 3. i nterfaces de usuario multi-canal
  • 48. 3. i nterfaces de usuario multi-canal
  • 49. 3. i nterfaces de usuario multi-canal
  • 50. arquitectura: generación de código Especificación 2. Inferencia 1. Carga 3. Generación Modelo explicito en memoria Generador Código fuente Síntesis Plantillas Transformaciones Algoritmos
  • 51. cadena de generación de código Generador de ORM Modelo Abstracto Modelo de ORM Modelo de capa Lógica Modelo de DB Modelo de IU Generador de Persistencia Generador de capa Lógica Generador de IU Scripts de DB Generador de BD especifico ORM Mappings Generador especifico de ORM Código de capa Lógica Generador de Lógica especifico Código de IU Generador de IU especifico
  • 52. desafíos
  • 53. desafíos: problemas abiertos
    • round trip
    • escapes de usuario
    • evolución de esquema
    • depuración de modelos
    • escalabilidad
    • rigidez
    • complejidad
  • 54. round trip
    • Una de las características más impresionantes de aplicar MDD es que:
      • el código generado tiene integridad por si mismo
    • Si se permite mezclar código manual y código generado las cosas se complican.
    • Una vez se introduce una línea de código manual, nadie puede garantizar la integridad de la mezcla
      • El modelo puede ser validado y comprobado
      • El código manual puede ser válido y compilar
      • Sin embargo, la mezcla de los dos puede no serlo
  • 55. escapes de usuario
    • Punto de vista pragmático: TODO no puede ser modelado
      • Tarde o temprano deberemos permitir escapes al usuario
    • Los escapes de usuario permiten añadir código manual
      • Per solo en los lugares designados
      • Para extender la funcionalidad que estamos proporcionando
    • Deben ser cuidadosamente documentados para dejar claro:
      • Los lugares permitidos
      • El objetivo y los problemas que el código de extensión solventará y lo que NO solventará
      • Las asunciones y convenciones que deban ser seguidas
      • Los cambios a realizar al código manual cuando una nueva versión de nuestras herramientas aparecen
        •  cuidadosos con la compatibilidad hacia atrás
    • Técnicas para añadir escapes de usuario
      • Creación de Librerías
      • Herencia y sobrecarga en el código generado
      • Clases parciales (C#)
      • Eventos, Intercepción
      • AOP
  • 56. personalización
    • Acantilados de personalización
    DSL DSL Lenguaje destino Lenguaje destino Aprendiz Iniciado Normal Experto
  • 57. test de regresión automatizados
    • 1. Generar código y tests
    Modelo Generador Código generado Test de regresión generado Código manual Test de regresión manual + + Aplicación Test de regresión 2. Aplicar los parches 3. Ejecutar los test de regresión 4. Publicar versión
  • 58. escalabilidad de modelos
    • Particionado
    • SoC
    • El editor importa
    namespace Demo { class Customer { string Name; string Surname; } } namespace Demo { class Customer { string Address; string Country; int Rating; } } namespace Demo { class Customer { string Name; string Surname; string Address; string Country; int Rating; } }
  • 59. evolución de modelos
    • Delta de cambios
      • Históricos
      • Diferencia de modelos
      • Versionado
    M0 M1 M2 M3 Aplic. en ejecución Modelo UML para contabilidad Metamodelo de UML Primitivas Aplicación del cliente Z KB para contabilidad Metamodelo de Genexus Primitivas Cliente: Luis Lopez Factura: 25643 Entidad: Factura Propiedad: Apellido Definición de entidad Definición de formulario Objetos Relaciones Valores Referencias Ejemplos: Genexus UML MOF
  • 60. conclusión
  • 61. conclusiones
    • MDD es una aproximación al desarrollo de SW
      • Ingenieril
      • Repetible, auditable, medible, optimizable
        • (En CMMI  niveles de calidad)
      • Menor dependencia del artesano
      • Proporciona un fuerte separación entre
        • El conocimiento del negocio (Bz KH)
        • El conocimiento de la tecnología (Tech KH)
    • La tecnología cambia cíclicamente como las modas…
      • Evitar que un cambio tecnológico impacte en el negocio
  • 62. conclusiones
    • Hay teoría donde fundamentar MDD
    • Hay herramientas reales para poner MDD en práctica
    • Inevitable
      • Es el siguiente paso lógico en la madurez del desarrollo de SW
    • Hay fabricantes apostando muy fuerte por MDD
    • El modo de desarrollo de SW está cambiando y va tomando velocidad
  • 63. lecciones aprendidas
      • El valor está en el modelo
  • 64. MDD: objetivo
      • Ingeniero de SW
      • Automatizar el 80%
      • para poder ser de nuevo
      • Artista en el 20% restante
  • 65. referencias
  • 66. referencias
    • Comunidades sobre MDD / MDA/ DSL
      • Model Driven Software Network
      • http:// modeldrivensoftware.net /
      • Conferencia Code Generation 2010 http:// www.codegeneration.net /cg2010/
    • DSL
      • Eclipse EMF/GMF
      • openArchitectuware
      • Microsoft DSL Tools
      • Microsoft OSLO
      • Antlr
    • Generación de código
      • Program Generators with XML and Java. J. Craig Cleaveland. Prentice Hall, 2001.
      • Software Product-Line Engineering: A Family Based Software Development Process. Chi Tau Robert Lai (Preface), David M. Weiss, David L. Parnas. Addison-Wesley, 1999.
  • 67. contacto
    • Dr. Pedro J. Molina
      • Ingeniero de Software
      • Capgemini España | Valencia
      • Blog: http://pjmolina.com/metalevel
      • Página: http://pjmolina.com/
      • pjmolina gmail.com
      • Patrones Conceptuales de Interfaz de Usuario
        • CUIP: http://pjmolina.com/cuip
        • Tesis doctoral: http://pjmolina.com/es/investigacion/tesis.php
    @