Desarrollo de Aplicaciones con MDA

Desarrollo de Aplicaciones con MDA
Una nueva revolución MDA
Regularmente la industria del software se enfrenta a distintas revoluciones provocadas
por la constante búsqueda de metodologías que permitan desarrollar aplicaciones
mejores, en menos tiempo y con menores costes.
Estas revoluciones suelen ser bastante extensas y no siempre dejan algo nuevo y, valga
la redundancia, revolucionario. Muchos de nosotros fuimos testigos de varias
revoluciones. Hemos tenido que migrar de DOS a Windows, de gestores de archivos
locales a bases de datos relacionales, hemos visto como Internet entró en nuestros
ordenadores de escritorio y hemos adoptado la programación orientada a objetos,
aunque sin dejar del todo la programación estructurada.
En nuestros días, una de estas revoluciones dio origen a una nueva metodología llamada
Model Driven Architecture, relacionada con el análisis, diseño y programación
orientada a objetos. Como en muchas otras revoluciones exitosas tarde temprano
seremos absorbidos por los cambios introducidos por ella.
Delphi 7
Con el lanzamiento de Delphi 7 Borland está impulsando la adopción de la metodología
Model Driven Architecture en la cual Delphi es sólo una herramienta más. Es por ello
que Borland ha incluido en Delphi 7 una serie de herramientas de terceros que si bien
para algunos no son novedad para otros sí.
Los folletos publicitarios de Delphi 7 están llenos de frases y términos nuevos que
forman parte de la misma revolución que dio origen a la metodología Model Driven
Architecture. He aquí algunos ejemplos: UML; Patterns; Refactoring; Object
Persistence; Business Objects
A lo largo de este artículo explicaré de qué se trata todo esto y qué problemáticas nos
ayudan a resolver.
Cuatro paradigmas, cuatro
Desde hace tiempo dos paradigmas distintos han tenido gran aceptación en la industria
del software: la programación orientada a objetos y las bases de datos relacionales. El
primero dedicado a la creación de programas y el segundo al almacenamiento de datos.
Estos dos paradigmas han madurado hace ya unos cuantos años al punto de que
cualquier programador que se jacte de serlo no puede estar al margen de ninguno de
ellos. Me animaría a decir que el panorama actual es el siguiente:
• Utilizamos una herramienta - Delphi
• de desarrollo rápido de aplicaciones
• de desarrollo visual basado en componentes
• basada en un lenguaje orientado a objetos - object pascal
• para el desarrollo de aplicaciones de bases de datos
• Almacenamos los datos en bases de datos relacionales o en gestores locales
• Pero seguimos programando la lógica del negocio de acuerdo a un tercer
paradigma: la programación estructurada.
Creo no estar equivocado. Si usamos programación orientada a objetos es sólo para la
creación de componentes. Con esto no quiero decir que programamos mal o que sea un
pecado mortal usar programación estructurada. Simplemente estoy intentando describir
la situación actual para comprenderla mejor.
El hecho de que la mayoría de los programadores Delphi no utilicemos objetos delnegocio
no es un mero capricho. Por años hemos utilizado un conjunto de componentesque son una
auténtica invitación a resolver la lógica del negocio con programación
estructurada, fomentando así una mezcla entre programación orientada a objetos,
programación estructurada y bases de datos relacionales. Y esto no nos sucedió sólo a
nosotros, los programadores Delphi, sino también a la mayoría de los programadores de
aplicaciones de bases de datos, sin importar las herramientas que utilizaran.
Pero no le echemos la culpa a las herramientas de desarrollo. Lo cierto es que es muy
difícil unir el paradigma de la programación orientada a objetos con el paradigma de las
bases de datos relacionales y, a pesar de los esfuerzos realizados por crear bases de
datos orientadas a objetos, los ganadores de la batalla siguen siendo la programación
orientada a objetos y las bases de datos relacionales y la mejor manera de unir ambos
paradigmas es por medio de la programación estructurada.
El cuarto paradigma
La situación antes descripta dio origen a un cuarto paradigma: el desarrollo de
aplicaciones objeto-relacional. Este paradigma intenta resolver la problemática
planteada por la utilización de programación orientada a objetos y bases de datos
relacionales.
En primer lugar, el paradigma objeto-relacional plantea el uso de programación
orientada a objetos para el desarrollo del 100% de la aplicación, incluyendo la lógica del
negocio. Esto significa que tenemos que utilizar objetos del negocio, como por ejemplo
facturas, productos y clientes y procesos del negocio, como por ejemplo calcular los
impuestos de tal factura que contiene tales productos y es para tal cliente.
En segundo lugar, el paradigma objeto-relacional plantea que la persistencia de los
objetos del negocio se realiza en bases de datos relacionales. Sin un mecanismo de
persistencia los objetos tendrían vida mientras el ordenador estuviera encendido y esto
no sería de mucha utilidad. Habrán leído más de una vez en la documentación de Delphi
acerca del mecanismo de persistencia de los componentes. Básicamente es lo que
permite que podamos almacenar un proyecto un día, abrirlo al día siguiente y encontrar
todo como lo almacenamos.
Sobre la base de estos dos planteos, el paradigma objeto-relacional se concentra en
como realizar la persistencia de objetos en bases de datos relacionales de una manera
eficiente y en lograr que cambios en los objetos no provoquen necesariamente cambios
en la base de datos y viceversa. Esto no es fácil de lograr y menos aún si no contamos
con las herramientas apropiadas.
Arquitectura basada en tipos de clases
En su libro “Building Object Applications That Work”, Scott Ambler propone la
utilización de capas al momento de diseñar las clases de una aplicación. En la
arquitectura basada en tipos de clases cada capa se corresponde con una funcionalidad
concreta de la aplicación lo que nos permite agrupar las clases de acuerdo a su
funcionalidad. El siguiente gráfico muestra la arquitectura propuesta por Scott Ambler
en su estado más evolucionado.
En este estado, la arquitectura propuesta por Scott Ambler está compuesta por cinco
capas. En ella no sólo se definen las capas que la componen sino también las relaciones
entre cada una de ellas o, dicho de otra forma, las relaciones entre las clases agrupadas
en cada una de ellas. A continuación se describen cada una de estas cinco capas.
User Interface Classes: en esta capa debemos agrupar las clases responsables de
resolver la interface de la aplicación con los usuarios. Por ejemplo, en una aplicación
Delphi tradicional, todos los formularios (descendientes de TForm) corresponderían a
esta capa.
Controller/Process Classes: en esta capa debemos agrupar las clases responsables de
resolver procesos de negocios. Por ejemplo, un proceso encargado de calcular los
impuestos de una factura.
Business/Domain Classes: en esta capa debemos agrupar las clases que representan
objetos del negocio. Por ejemplo, cliente, producto, factura, etc.
Presistence Classes: en esta capa debemos agrupar las clases responsables de la
persistencia de los objetos del negocio. Por ejemplo, en una aplicación Delphi de bases
de datos, los componentes de acceso a datos corresponderían a esta capa.
System Clasess: en esta capa debemos agrupar las clases que representan procesos
específicos del sistema operativo. Por ejemplo, llamadas al API de Windows.
Es importante no sólo prestar atención a cada una de las capas sino también a la
interacción entre ellas. En el gráfico se puede ver claramente como las clases de la capa
User Interface Classes no deben interactuar nunca con las clases de la capa Persistence
Classes.
El paradigma objeto-relacional
La arquitectura propuesta por Scott Ambler es una de las tantas alternativas que intentan
resolver las problemáticas del paradigma objeto-relacional. La persistencia de los
objetos del negocio en una base de datos relacional es delegada en una capa lo que
permite cierto nivel de aislamiento entre los objetos del negocio y la base de datos
relacional permitiendo, entre otras cosas, cambiar el gestor de bases de datos
relacionales sin tener que modificar los objetos del negocio y mucho menos aún las
clases responsables de resolver la interface de la aplicación con los usuarios.
Model Driven Architecture
El concepto encerrado en la frase Model Driven Architecture es muy difícil de traducir
al castellano sin que pierda su significado. Y la dificultad aumenta si queremos hacerlo
en una frase breve. Es por eso que casi nunca se traduce.
Según la OMG...
Model Driven Architecture (MDA) es una nueva forma de escribir especificaciones y
desarrollar aplicaciones, ambos basados en un modelo independiente de la plataforma.
Una especificación MDA completa consiste en
• un modelo UML base y definitivo independiente de la plataforma,
© 2002 Grupo Danysoft - +34.916 638683 – www.danysoft.com
• uno o más modelos específicos de la plataforma y
• un conjunto de definiciones de interfaces, cada una describiendo como es
implementado el modelo base en una plataforma diferente.
Una aplicación MDA completa consiste en
• un modelo definitivo independiente de la plataforma,
• uno o más modelos específicos de la plataforma e
• implementaciones completas, una para cada una de las plataformas que el
desarrollador decida soportar.
El desarrollo MDA se concentra primero en la funcionalidad y el comportamiento de
una aplicación o sistema distribuido, si importar la tecnología o tecnologías en las
cuales será implementado. MDA separa los detalles de la implementación de las
funciones del negocio. De esta manera, no es necesario repetir el proceso de modelado
de la funcionalidad y el comportamiento de una aplicación o sistema cada vez que una
nueva tecnología (como XML/SOAP) aparece. Más información en
http://www.omg.org/mda y http://www.uml.org .
Atando cabos
Atemos los cabos sueltos. Debemos utilizar:
• Una metodología de análisis, diseño y programación orientada a objetos como
estándar para el desarrollo de aplicaciones.
• UML como estándar para el modelado de objetos.
• Una herramienta de desarrollo basada en un lenguaje orientado a objetos.
• Bases de datos relacionales como estándar para el almacenamiento de datos.
• Modelos entidad-relación como estándar para el modelado de bases de datos.
• Aplicaciones objeto-relacional como estándar para el desarrollo de aplicaciones de
bases de datos.
• Model Driven Architecture como metodología para administrar el ciclo de vida de
una aplicación.
Qué nos ofrece Borland en Delphi 7 Studio Architect
• Delphi 7, una herramienta de desarrollo basada en un lenguaje orientado a objetos.
• Model Maker, una herramienta para el modelado de objetos con UML integrada
con Delphi como ninguna otra.
• Bold For Delphi, un conjunto de componentes que permiten el desarrollo de
aplicaciones objeto-relacional con mínimo esfuerzo, implementando una capa de
visualización de objetos del negocio, una capa de objetos del negocio y una capa
de persistencia de objetos del negocio. Bold For Delphi utiliza UML y permite
importar un modelo desde Model Maker.
Como casi siempre, tenemos mucho que aprender pero el esfuerzo bien vale la pena.
Las herramientas incluidas en Delphi 7 Studio Architect harán que dicho esfuerzo sea
mucho menor.