La regla de Pareto aplicada a MDD

La regla de Pareto (también conocida como la regla 80-20 ) dice que para muchos casos, aproximadamente el 80% del efecto viene sólo de un 20% de las causas, e.g. “80% de las ventas viene del 20% de los clientes”.

En resumen, que para casi todo un 20% del todo es importante mientras que el otro 80% es trivial con lo que claramente, hay que focalizarse en el 20% imporatnte para mejorar la productividad.

En mi opinión este principio se aplica también al desarrollo de software dirigido por modleos. Mi definició de la regla de pareto para MDD es la siguiente:

20% of the modeling effort suffices to generate 80% of the application code

Esto implica que podemos mejorar y mucho nuestra productividad y conseguir la mayoría de los beneficios del modelado sin tener que dibujar modelos totalmente completos y precisos. Ésta es de hecho la idea detrás de los servicios ofrecidos por el portal (por cierto, el servicio de transformación XMI será operativo en pocos días, seguid atentos). Creo que para muchas empresas este 80% es más que suficiente o como mínimo les puede ser útil para empezar a experimentar con los processo de desarrollo model-driven.

Veamos un ejemplo. Para conseguir un 100% de generación de código, hay que definir completamente durante la fase de modelado el comportamiento de todas las operaciones del sistema (usando, por ej., un lenguaje tipo Action Semantics de UML). No obstante, resulta que la mayoría de estas operaciones (como no podía ser de otra manera, alrededor de un 80%) son típicas operaciones CRUD (create/read/update/delete), cuyo número, especificación, parámetros y código puede deducirse automáticamente sólo mirando a la información estática del diagrama de clases (ej. si tenemos una classe Cliente , es lógico suponer que necesitaremos una operación para crear nuevos clientes, para actualizar los atributos de los ya existentes,…). Es decir, con un 20% de esfuerzo (sólo la definición de los aspectos estáticos del sistema) podemos generar automáticamente un 80% de todas las operaciones que tiene que ofrecer la aplicación (podéis ver en este artículo un par de casos de estudio que hicimos para validar este resultado)

Por ejemplo, dado este modelo :

podemos generar automáticamente este otro:

donde la especificación y el código de todas las operaciones se ha definido completamente. Si os interesan los detalles del método de generación usado en este ejemplo concreto mirad este artículo: Deriving Operation Contracts from UML Class Diagrams paper o su versión extendida : Automatic Generation of Basic Behavior Schemas from UML Class Diagrams

Si te ha gustado esta entrada, puedes subscribirte a este Software Modeling blog y/o seguirme en twitter y/o a través de la lista de distribución del portal Y si realmente te ha gustado ayúdame a hacerlo llegar a otros utilizando los bookmarks que tienes a continuación: