Your SlideShare is downloading. ×
026 Estado Del Arte De Mdd Model Driven Development
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

026 Estado Del Arte De Mdd Model Driven Development

2,373
views

Published on

Published in: Technology, Business

1 Comment
2 Likes
Statistics
Notes
No Downloads
Views
Total Views
2,373
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
134
Comments
1
Likes
2
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • 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
  • <number>
    Domain Knowledge: Business processes, Business rules, Information, Business driven
    Technological Knowledge: Technology driven, Cyclical waves
  • <number>
  • <number>
  • <number>
  • <number>
  • Transcript

    • 1. MDD 1Dr. Pedro J. Molina, MMIX.14 de Septiembre, 2009 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. Desarrollo de Software 1/9 8/9
    • 4. 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.
    • 5. MDD Agenda  introducción  qué  porqué  hoy  mañana  conclusión Model Driven Development Desarrollo Dirigido por Modelos
    • 6. 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
    • 7. MDD 8Dr. Pedro J. Molina, MMIX.14 de Septiembre, 2009 qué
    • 8. niveles de abstracción Código máquina COBOL / C / Basic / Java Ensamblador 4GL Modelos / Especificaciones Dominio de aplicación Gapsemántico Niveldeabstracción 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
    • 9. ¿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
    • 10. <CallRecord> <caller><number>07713248</number> ¿qué es un lenguaje? ∂C(x) h2 ∂ 2 C(x) ∂ t 2m ∂ x2ih = – Textual Gráfico Declarativo Imperativo class Factura : Documento { public void Emitir() Luís galletas 24 verde José pasteles 32 azul Empleado Nombre Dirección Promocionar Puesto Descripción Salario Asignar 0..* a>b && c==d Llamada Grabación Duración × Coste min. DB
    • 11. ¿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.
    • 12. 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
    • 13. 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
    • 14. 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
    • 15. ¿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?
    • 16. ¿¡modelarlo todo!? 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!  ¿Qué características deben ser añadidas a un modelo?  Aproximación totalmente pragmática: dirigida por la ley de Novak. Sí No 1 2 3
    • 17. ¿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)
    • 18. 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.
    • 19. mapa conceptual de la generación de código EspecificaciónCódigo Fuente Plantilla Meta-modelo Algoritmos de transformación Programas Modelos Clases / Tipos / Meta Instancias Ingeniería Inversa Abstracción Síntesis Correspon- dencias Instanciación Abstracción 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
    • 20. MDD 21Dr. Pedro J. Molina, MMIX.14 de Septiembre, 2009 porqué
    • 21. ROI  Economía de alcance  Economía de escala  El modelo económico de MDD  Calidad  Impacto en la ciclo de vida del desarrollo
    • 22. 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.
    • 23. 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]
    • 24. industrialización Producción en masa Cambio de proceso Estable Dinámico Cambioenelproducto DinámicoEstable Producto artesanoPersonalización en masa Mejora continua CMM Agil MDD, Factorías de SW CD, DVD, Copia de ficheros 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
    • 25. 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
    • 26. MDD: modelo económico  Coste tradicional = N * CT  Coste con MDD = Inv + N * CF Miembros de la familia 1 2 3 4 5 5 CT 4 CT 3 CT 2 CT CT Costeacumulado Inv Ahorro AF = CT - CF
    • 27. 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
    • 28. coste de defectos y distribución Defecto Bug Característica Feature vs
    • 29. coste de defectos y distribución % Defectos Análisis Diseño Construcción Mantenimiento Ciclo de vida tradicional Ciclo de vida con MDD Coste exponencial de los defectos Efecto Bola de nieve 1 € 2 € 4 € 8 €
    • 30. MDD 32Dr. Pedro J. Molina, MMIX.14 de Septiembre, 2009 hoy
    • 31. 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
    • 32. 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  …
    • 33. 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
    • 34. experiencias de mercado 1. Terminal Financiero 2. Cumplimiento de regulaciones  Frameworks / Arquitecturas cliente  Guías de estilo / Reglas de nombrado  Sabarney Oxley / Audit Trail  Accesibilidad AAA / Section 508 3. CUIP  Interfaces de usuario Multicanal
    • 35. 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
    • 36. 1. terminal financiero  Entorno de trabajo integrado en Visual Studio
    • 37. 1. terminal financiero  DSL: Lenguaje de acción a medida  Sintaxis coloreada  Soporte a Intelisense
    • 38. 1. terminal financiero  Gestión de errores integrada en Visual Studio
    • 39. 1. terminal financiero  Ejemplo de DSL  Diagrama de navegación
    • 40. 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
    • 41. 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”
    • 42. 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
    • 43. 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
    • 44. 3. CUIP Más información en http://pjmolina.com/cuip y en http://pjmolina.com/es/investigacion/tesis.php
    • 45. 3. interfaces de usuario multi-canal
    • 46. 3. interfaces de usuario multi-canal
    • 47. 3. interfaces de usuario multi-canal
    • 48. arquitectura: generación de código Especificación Código fuente Síntesis Plantillas Transformaciones Algoritmos 2. Inferencia 1. Carga 3. Generación Modeloexplicito enmemoria Generador
    • 49. 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
    • 50. MDD 52Dr. Pedro J. Molina, MMIX.14 de Septiembre, 2009 desafíos
    • 51. desafíos: problemas abiertos  round trip  escapes de usuario  evolución de esquema  depuración de modelos  escalabilidad  rigidez  complejidad
    • 52. 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
    • 53. 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
    • 54. personalización  Acantilados de personalización DSL DSL Lenguaje destino Lenguaje destino Aprendiz Iniciado Normal Experto
    • 55. test de regresión automatizados Modelo Generador Código generado Test de regresión generado Código manual Test de regresión manual + + Aplicación Test de regresión 1. Generar código y tests 2. Aplicar los parches 3. Ejecutar los test de regresión 4. Publicar versión
    • 56. 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; } }
    • 57. 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:GenexusUMLMOF
    • 58. MDD 60Dr. Pedro J. Molina, MMIX.14 de Septiembre, 2009 conclusión
    • 59. 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
    • 60. 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
    • 61. lecciones aprendidas El valor está en el modelo
    • 62. MDD: objetivo Ingeniero de SW Automatizar el 80% para poder ser de nuevo Artista en el 20% restante
    • 63. MDD 65Dr. Pedro J. Molina, MMIX.14 de Septiembre, 2009 referencias
    • 64. 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.
    • 65. 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 @