MDD
1Dr. Pedro J. Molina, MMIX.14 de Septiembre, 2009
Dr. Pedro J. Molina
Ingeniero de Software
Capgemini España | Valenci...
Desarrollo de software:
¿arte o ingeniería?
Ciudad de las Artes y Las Ciencias. Valencia, España.
Desarrollo de Software
1/9
8/9
Escenario actual
 Siglo XXI, Sociedad del Conocimiento
 Demanda SW en gran cantidad
 De calidad, robusto, rápido (Time ...
MDD Agenda
 introducción
 qué
 porqué
 hoy
 mañana
 conclusión
Model Driven Development
Desarrollo Dirigido por Mode...
breve presentación
Pedro J. Molina
 Doctor e Ingeniero en Informática por la Univ. Politécnica de
Valencia, 2003
 Tesis ...
MDD
8Dr. Pedro J. Molina, MMIX.14 de Septiembre, 2009
qué
niveles de abstracción
Código máquina
COBOL / C / Basic / Java
Ensamblador
4GL
Modelos / Especificaciones
Dominio de
aplic...
¿qué es un dominio?
Implementación
Especificación
Requisitos
Despliegue
Sistemas
de Gestión
Sistemas de
Tiempo Real
Sistem...
<CallRecord>
<caller><number>07713248</number>
¿qué es un lenguaje?
∂C(x) h2
∂ 2
C(x)
∂ t 2m ∂ x2ih = –
Textual Gráfico
De...
¿qué es un modelo?
 Un modelo permite describir una familia de problemas dentro de un
dominio dado
 Tiene el grado de ab...
regla de Novak
“La programación automática se define como la
síntesis de un programa a partir de una
especificación (o mod...
principios de modelado
 Tan simple como sea posible (KISS)
 pero expresivo
 Semánticamente bien definido
 Canónico (DR...
principios para generación de código
 Ingeniería hacia delante
 Forward Engineering
 El valor esta en el modelo
 el có...
¿modelarlo todo?
 Generar el 100% del código ¿Utopía?
 Depende mucho del dominio y de lo acotado que esté
 Posible en e...
¿¡modelarlo todo!?
Nueva característica
propuesta al modelo
¿Puede ser
modelada?
Análisis de
Coste/Be-
neficio
Cambio manu...
¿qué (y qué no) incluir en el modelo?
“Lo bueno, si breve,
dos veces bueno.”
Baltasar Gracián, (siglo XVII)
Variable
vs
In...
separation of concerns (SoC)
Conocimiento capturado en dos compartimentos separados:
¿Qué?
¿Cómo?
 Conocimiento de negoci...
mapa conceptual de la generación de código
EspecificaciónCódigo
Fuente
Plantilla Meta-modelo
Algoritmos de
transformación
...
MDD
21Dr. Pedro J. Molina, MMIX.14 de Septiembre, 2009
porqué
ROI
 Economía de alcance
 Economía de escala
 El modelo económico de MDD
 Calidad
 Impacto en la ciclo de vida del
de...
economía de escala
 Economía de escala (economies of scale):
 La condición donde pocas entradas, como esfuerzo y tiempo,...
economía de alcance
 Economía de alcance (economies of scope):
 La condición donde pocas entradas, como esfuerzo y
tiemp...
industrialización
Producción en masa
Cambio de proceso
Estable Dinámico
Cambioenelproducto
DinámicoEstable
Producto artesa...
MDD: modelo económico
Ingeniería de Dominio
Ingeniería de Aplicación
Entorno de desarrollo
de aplicaciones
Aplicaciones
Re...
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 ...
impacto en el ciclo de vida
 Mas tiempo en análisis y diseño
 Menos tiempo en codificación
 Menos defectos, más calidad...
coste de defectos y distribución
Defecto
Bug
Característica
Feature
vs
coste de defectos y distribución
% Defectos
Análisis Diseño Construcción Mantenimiento
Ciclo de vida tradicional
Ciclo de ...
MDD
32Dr. Pedro J. Molina, MMIX.14 de Septiembre, 2009
hoy
UML/MDA ¿es suficiente?
 UML
 Origen: notación de compromiso (propuesta de unificación)
 OCL: lenguaje de restricciones...
quién está haciendo qué
 Eclipse EMF/GMF
 IBM
 SAP
 OpenArchitectureware
 XText
 Itemis
 xUML / MDA
 Kennedy Carte...
un vistazo a Genexus desde
“fuera”
Hechos
 Base de conocimiento (KB)
 Enfocado en el dominio de
aplicaciones de negocio
...
experiencias de mercado
1. Terminal Financiero
2. Cumplimiento de regulaciones
 Frameworks / Arquitecturas cliente
 Guía...
1. terminal financiero
 PISA es un entorno completo de modelado
construido para Bancaja sobre Visual Studio.
 MS DSL Too...
1. terminal financiero
 Entorno de
trabajo
integrado en
Visual Studio
1. terminal financiero
 DSL: Lenguaje
de acción a
medida
 Sintaxis
coloreada
 Soporte a
Intelisense
1. terminal financiero
 Gestión de
errores integrada
en Visual Studio
1. terminal financiero
 Ejemplo de DSL
 Diagrama de
navegación
2. cumplimiento de regulaciones
 Frameworks / Arquitecturas cliente
 Guías de estilo / Guías de nombrado
 Un generador ...
2. cumplimiento de regulaciones
 Sabarney Oxley / Audit Trail
 Caso Enron  Cotizadas en bolsa en EE.UU.
 Auditoria fer...
2. cumplimiento de regulaciones
 Las regulaciones son aburridas
 Obligan a los desarrolladores a tenerlas todas en cuent...
3. CUIP
 Patrones Conceptuales de Interfaz de Usuario (CUIP)
 Una colección de patrones conceptuales para aplicaciones d...
3. CUIP
Más información en http://pjmolina.com/cuip
y en http://pjmolina.com/es/investigacion/tesis.php
3. interfaces de usuario multi-canal
3. interfaces de usuario multi-canal
3. interfaces de usuario multi-canal
arquitectura: generación de código
Especificación
Código fuente
Síntesis
Plantillas
Transformaciones
Algoritmos
2. Inferen...
cadena de generación de código
Generador
de ORM
Modelo
Abstracto
Modelo
de ORM
Modelo
de capa
Lógica
Modelo
de DB
Modelo
d...
MDD
52Dr. Pedro J. Molina, MMIX.14 de Septiembre, 2009
desafíos
desafíos: problemas abiertos
 round trip
 escapes de usuario
 evolución de esquema
 depuración de modelos
 escalabili...
round trip
 Una de las características más impresionantes de
aplicar MDD es que:
 el código generado tiene integridad po...
escapes de usuario
 Punto de vista pragmático: TODO no puede ser modelado
 Tarde o temprano deberemos permitir escapes a...
personalización
 Acantilados de personalización
DSL DSL
Lenguaje destino Lenguaje destino
Aprendiz
Iniciado
Normal
Experto
test de regresión automatizados
Modelo
Generador
Código generado Test de regresión
generado
Código manual Test de regresió...
escalabilidad de modelos
 Particionado
 SoC
 El editor importa
namespace Demo
{
class Customer
{
string Name;
string Su...
evolución de modelos
 Delta de cambios
 Históricos
 Diferencia de modelos
 Versionado
M0
M1
M2
M3
Aplic. en ejecución
...
MDD
60Dr. Pedro J. Molina, MMIX.14 de Septiembre, 2009
conclusión
conclusiones
 MDD es una aproximación al desarrollo de SW
 Ingenieril
 Repetible, auditable, medible, optimizable
 (En...
conclusiones
 Hay teoría donde fundamentar MDD
 Hay herramientas reales para poner
MDD en práctica
 Inevitable
 Es el ...
lecciones aprendidas
El valor está en el modelo
MDD: objetivo
Ingeniero de SW
Automatizar el 80%
para poder ser de nuevo
Artista en el 20% restante
MDD
65Dr. Pedro J. Molina, MMIX.14 de Septiembre, 2009
referencias
referencias
 Comunidades sobre MDD / MDA/ DSL
 Model Driven Software Network
http://modeldrivensoftware.net/
 Conferenc...
contacto
 Dr. Pedro J. Molina
 Ingeniero de Software
 Capgemini España | Valencia
 Blog: http://pjmolina.com/metalevel...
026 Estado Del Arte De Mdd Model Driven Development
026 Estado Del Arte De Mdd Model Driven Development
Upcoming SlideShare
Loading in …5
×

026 Estado Del Arte De Mdd Model Driven Development

2,843 views

Published on

Published in: Technology, Business

026 Estado Del Arte De Mdd Model Driven Development

  1. 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. 2. Desarrollo de software: ¿arte o ingeniería? Ciudad de las Artes y Las Ciencias. Valencia, España.
  3. 3. Desarrollo de Software 1/9 8/9
  4. 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. 5. MDD Agenda  introducción  qué  porqué  hoy  mañana  conclusión Model Driven Development Desarrollo Dirigido por Modelos
  6. 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. 7. MDD 8Dr. Pedro J. Molina, MMIX.14 de Septiembre, 2009 qué
  8. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 20. MDD 21Dr. Pedro J. Molina, MMIX.14 de Septiembre, 2009 porqué
  21. 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. 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. 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. 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. 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. 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. 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. 28. coste de defectos y distribución Defecto Bug Característica Feature vs
  29. 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. 30. MDD 32Dr. Pedro J. Molina, MMIX.14 de Septiembre, 2009 hoy
  31. 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. 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. 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. 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. 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. 36. 1. terminal financiero  Entorno de trabajo integrado en Visual Studio
  37. 37. 1. terminal financiero  DSL: Lenguaje de acción a medida  Sintaxis coloreada  Soporte a Intelisense
  38. 38. 1. terminal financiero  Gestión de errores integrada en Visual Studio
  39. 39. 1. terminal financiero  Ejemplo de DSL  Diagrama de navegación
  40. 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. 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. 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. 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. 44. 3. CUIP Más información en http://pjmolina.com/cuip y en http://pjmolina.com/es/investigacion/tesis.php
  45. 45. 3. interfaces de usuario multi-canal
  46. 46. 3. interfaces de usuario multi-canal
  47. 47. 3. interfaces de usuario multi-canal
  48. 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. 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. 50. MDD 52Dr. Pedro J. Molina, MMIX.14 de Septiembre, 2009 desafíos
  51. 51. desafíos: problemas abiertos  round trip  escapes de usuario  evolución de esquema  depuración de modelos  escalabilidad  rigidez  complejidad
  52. 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. 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. 54. personalización  Acantilados de personalización DSL DSL Lenguaje destino Lenguaje destino Aprendiz Iniciado Normal Experto
  55. 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. 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. 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. 58. MDD 60Dr. Pedro J. Molina, MMIX.14 de Septiembre, 2009 conclusión
  59. 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. 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. 61. lecciones aprendidas El valor está en el modelo
  62. 62. MDD: objetivo Ingeniero de SW Automatizar el 80% para poder ser de nuevo Artista en el 20% restante
  63. 63. MDD 65Dr. Pedro J. Molina, MMIX.14 de Septiembre, 2009 referencias
  64. 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. 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 @

×