Está en la página 1de 10

Integración del enfoque MDA con ADD

Enver José Carlos Maquen Niño


Universidad Nacional Pedro Ruiz Gallo
ejcmaquen@hotmail.com

Resumen
“En éste paper se presenta integración del Método ADD (Diseño Dirigido por Atributos) para la
construcción de la Arquitectura del Software, dentro del desarrollo de Software empleando MDA (
Arquitectura Basada en Modelos).
Es importante la definición de la Arquitectura del Software, el Modelo de Ciclo de Vida Genérico para MDA
no tiene en cuenta la Arquitectura de Software el método ADD nos da un conjuntos de pasos para definir la
arquitectura del Software, teniendo en cuenta los Requerimientos Funcionales y los de calidad., estos últimos
son importantes para Obtener un Software de Calidad y la mayoría de problemas se dan, porque el software no
los cumple”

1.Introducción
Existen herramientas CASE que cubren algunas fases de la construcción de Desarrollo de
Software, las cuales están siendo utilizadas desde la década de los 80, y que han ido
evolucionando en el transcurso del tiempo. Sin embargo, no han cubierto todas las necesidades
de los desarrolladores para aliviar problemas de cambios, modificaciones durante la fase de
desarrollo de software, o también problemas de modificaciones como parte del mantenimiento del
Software.
Durante los últimos años se han logrado progresos en el desarrollo de software que ha
permitido construir sistemas grandes y complejos. Aun así la construcción de software de manera
tradicional sigue teniendo problemas
En la actualidad la construcción de software se enfrenta a continuos cambios, lo que implica
hacer esfuerzos importantes tanto en el diseño de la aplicación, para adaptar las diferentes
tecnologías a incorporar, como en el mantenimiento, para adaptar la aplicación a cambios en los
requisitos.
A partir del 2001 aproximadamente, aparece la MDA(Arquitectura Basada en Modelos)
presentada por la OMG (Object Management Group), nace con la finalidad de apoyar durante
todo el proceso de Desarrollo de Software, y además en el proceso de Mantenimiento de
Software.
La propuesta de OMG, MDA utiliza los modelos como elementos de primera clase en el
desarrollo de aplicaciones, a diferencia de otros paradigmas que los utilizan únicamente como
elementos de representación, comunicación y documentación.
ADD (Diseño Dirigido por Atributos), es un método para diseñar la Arquitectura del
Software, para satisfacer tanto requerimientos de calidad como requerimientos funcionales.
Siendo necesaria la definición de la Arquitectura del Software, antes de utilizar MDA para el
desarrollo del Software, es que se propone la Aplicación del método ADD para definirla
El resto de éste paper está organizado de la siguiente manera. En la sección 2 se muestra
los Trabajos Previos. La sección 3 describe MDA . La descripción de ADD se encuentra en la
sección 4. La Utilización de ADD en el Enfoque MDA se detalla en la sección 5. En la sección 6
la Aplicación de la Integración de ADD en el Enfoque MDA a través de un ejemplo y finalmente,
las conclusiones están en la sección 7.
2. Trabajos Previos

Si bien existen muchos estudios e investigaciones de la aplicación del MDA para el


desarrollo de software, y asi mismo, existen muchos trabajos relacionados con ADD, no existen
trabajos previos de la integración del MDA con ADD, que mediante algún Método de software
permitan la aplicación de ambos en el proceso de desarrollo de software.

3. Descripción de la Arquitectura Dirigida por Modelos (MDA)


Es un estándar de Object Management Group (OMG) que defiende el MDD y agrupa varios
lenguajes que pueden usarse para seguir esta aproximación. Según esta afirmacion, MDA posee
el valor añadido de proporcionar lenguajes con los que se puede definir métodos que sigan MDD.
Sin embargo, MDA no es por si mismo un método que define técnicas, etapas, artefactos, etc.,
solamente proporciona la infraestructura tecnológica y conceptual con la que construir estos
métodos MDD.
En definitiva, MDA no puede ser utilizado directamente para desarrollar software, es necesario
que se construyan métodos precisos que proporcionen a los equipos de desarrollo pautas y
técnicas que estos puedan seguir y utilizar.
El propósito indicado de estos dos párrafos era proporcionar los principios que se seguirán en la
revisión de la guía de MDA.
“MDA es una iniciativa de la Object Management Group (OMG) que propone definir un
conjunto de estándares no-propietarios que especificarán las tecnologías interoperable con las
cuales realizar el desarrollo de software dirigido por modelos con transformaciones
automatizadas. No todas estas tecnologías se referirán directamente a las transformaciones
implicadas en MDA. MDA no se basa necesariamente en el UML, sino que, como clase
especializada de Desarrollo Dirigido por Modelos (MDD), MDA implica necesariamente el uso
del modelo(s) en el desarrollo, que exige por lo menos que un lenguaje de modelamiento debe ser
utilizado. Cualquier lenguaje de modelamiento usado en MDA se debe describir en los términos
del lenguaje MetaObject Facility (MOF), que permita que la metadata deba ser entendida de una
manera estándar, la cual es una condición previa para poder realizar transformaciones
automatizadas”. 1
MDA Proporciona las bases para: [1]
 Definir un sistema independiente de la plataforma en que se construye
 Definir plataformas
 Elegir una plataforma particular
 Transformación hacia una plataforma particular

3.1. Modelos del MDA


PIM (Platform Independent Model)
Describe el Sistema pero no muestra los detalles del uso de su plataforma [1]. Es un modelo del
sistema de alto Nivel representa la estructura funcionalidad y restricciones del sistema
Al no incluir detalles específicos de la tecnología este modelo es útil en dos aspectos:
Es fácilmente compresible por los usuarios del sistema y por lo tanto les resultara más sencillo
validar la corrección.

1
Aprobado unánimemente por 17 participantes en la sesión plenaria de Object and Reference Model
Subcommittee of the Architecture Board (ORMSC), reunidos en Montreal del 23 al 26 de agosto, 2004.
Facilita la implementación de diferentes aplicaciones en diferentes plataformas dejando intacta su
estructura y funcionalidad básica
En la figura 1 podemos observar un ejemplo de un PIM, las clases no presentan detalles
específicos de alguna tecnología

Figura 1. Ejemplo de un PIM

Figura 1. Ejemplo de PIM

PSM (Platform Specific Model)


Es un modelo del sistema con detalles específicos de la plataforma en la que será implementado.
Un PSM combina las especificaciones en el PIM con los detalles que especifican cómo el sistema
usa un tipo particular de plataforma [1]. Podemos decir que un PSM es un PIM al que se le
añaden detalles específicos para ser implementado en una plataforma determinada.
Para la construcción de PSM se emplean Perfiles UML que son extensiones de UML que
permiten añadir información semántica a los modelos para expresar detalles específicos de la
plataforma. Por ejemplo el estereotipo de la <<EJBEntity>> de la figura 2 forma parte del Perfil
UML para la plataforma EJB. [2]

Figura 2. Ejemplo de PSM

El paso de PIM a PSM se puede realizar: [1]


Que las transformaciones sean realizadas de manera completamente manual por parte de los
desarrolladores del sistema.
Que sea necesaria la participación de los desarrolladores para llevar a cabo la transformación.
Siguiendo esta estrategia, la transformación puede estar guiada por herramientas o puede
aplicarse automáticamente para generar automáticamente una versión preliminar de los modelos
transformados.
Que a partir de modelos independientes de plataforma sea posible obtener de manera
completamente automática el PSM
A partir del PSM gracias a la herramienta de transformación se genera gran parte del código que
implementa el sistema. El desarrollador tendrá que añadir aquella funcionalidad que no puede ser
representada mediante el PIM o el PSM
3.2. Desarrollo tradicional vs Desarrollo con MDA
Problemas del Desarrollo tradicional: [3]
 Productividad .Produce gran cantidad de documentos y diagramas para especificar los
requisitos, clases, colaboraciones, etc. Cuando el sistema cambia realizar cambios en todas
las fases se hace inmanejable. Entonces, ¿para que perder tiempo en construir diagramas y
documentación de alto nivel?
 Portabilidad. Adaptación a nuevas tecnologías. Entonces el software debe adaptarse o
migrar a la nueva tecnología
 Interoperabilidad. Se necesita que se consiga de manera sencilla. La mayoría de los
sistemas necesitan comunicarse con otros, probablemente ya construidos
 Mantenimiento. Documentar consume mucho tiempo, tiene poca calidad y a veces se
encuentra desactualizada

Beneficios del MDA [3]


 Productividad. En MDA el foco del desarrollo recae sobre el PIM. Los PSM son
generados en gran parte automáticamente. Por supuesto alguien tiene que definir las
transformaciones exactas pero una vez definidas pueden utilizarse en múltiples desarrollos.
Y lo mismo ocurre con la generación de código a partir de los PSMs. Este enfoque basado
en PIM aísla los problemas específicos de cada plataforma y encaja con las necesidades del
usuario
 Portabilidad. El PIM al ser independiente de la tecnología todo lo definido es portable. El
peso recae sobre las herramientas de transformación, que realizaran automáticamente el
paso a la plataforma tecnológica deseada
 Interoperabilidad. Los PSMs generados a partir de un PIM normalmente estaran
relacionados , que es lo que en MDA se llama puentes, MDA no solo genera los PSMs sino
también los puentes
 Mantenimiento y Documentación. Los cambios realizados en el sistema se reflejan en
todos los niveles mediante la regeneración de los PSMs y del código

3.3. Proceso de Desarrollo con MDA


En la figura 3 se muestran el Ciclo de vida genérico para MDA, a A n a lis is d e
continuación se detallan cada una de las etapas : R e q u is ito s

La primera etapa corresponde a la fase de análisis de requisitos. Su


objetivo es obtener una especificación adecuada de cuáles son los M o d e la d o
I n d e p e n d ie n te d e la
requisitos del sistema que se desea desarrollar. Consideramos que ésta es P la ta fo r m a (P I M )

una de las fases más importantes, ya que disponer de un documento de


M o d e la d o
requisitos completo y preciso evitará propagar errores a las siguientes D e p e n d ie n te d e la
P la ta fo r m a (P S M )
fases del ciclo de vida.
Una vez obtenidos los requisitos del sistema, se pasará a la fase de
G e n e r a c io n d e
modelado independiente de la plataforma, en la que se construirán los C o d ig o
modelos que describen la funcionalidad del sistema de forma
independiente a la plataforma elegida para la implementación final del
mismo (PIM). P r u e b a d e l S is te m a

En la siguiente etapa, los modelos PIM se transformarán, si es posible de


forma automática, en modelos dependientes de la plataforma. Estos D e s p lie g u e y
modelos serán usados como entrada para la fase de generación de código. M a n te n im ie n to

A continuación sigue la fase de pruebas del sistema (si los resultados


Figura 3. Modelo de Ciclo de
Vida Genérico para MDA
obtenidos son erróneos, pueden implicar el regreso a la fase anterior de generación de código o a
la de modelado de los PIM o incluso la modificación de determinados requisitos)
Un grupo de personas (Experto del Negocio) construyen el PIM guiados por las necesidades del
negocio y de la funcionalidad que debe incorporar el sistema
Otro grupo de personas (Arquitecto de la Plataforma) se encargara de la transformación del PIM a
uno o varios PSMs. Estas personas tendrán conocimientos de diversas plataformas y arquitecturas
y conocerán las transformaciones disponibles en las herramientas que usan.
El código se genera mediante herramientas especializadas de Transformación, los programadores
se limitaran a añadir la funcionalidad que no pueda reflejarse en los modelos

4. Descripción del Método ADD (Diseño Dirigido por Atributos)


ADD es un acercamiento a la definición de una arquitectura de software que se basa en el proceso
de descomposición sobre los atributos de calidad que el software tiene que realizar. Esto es un
proceso de descomposición recursivo donde, en cada etapa, los modelos tácticos y
arquitectónicos son escogidos para satisfacer un conjuntos de escenarios de calidad y luego la
funcionalidad es asignada a instancias de los módulos proporcionados por el modelo. ADD se
aplica después del análisis de requerimientos, se puede comenzar cuando se conocen bien los
manejadores de arquitectura.
Para determinar los manejadores de arquitectura, identifique los objetivos del negocio de más alta
prioridad. Debería haber relativamente pocos de estos. Convierta estos objetivos del negocio en
escenarios de calidad o casos de uso. De esta lista, elegir los que tendrán el mayor impacto en la
arquitectura. Estos son los manejadores de arquitectura, y debe haber menos de diez
La entrada para ADD es un conjunto de requerimientos. ADD asume los requerimientos
funcionales (típicamente expresados como casos de uso) y restricciones como entrada, como lo
hacen otros métodos de diseño. Sin embargo, a ADD lo diferenciamos de aquellos métodos en
nuestro tratamiento de los requerimientos de calidad. ADD dice que los requerimientos de calidad
deben expresar un conjunto específico de escenarios de calidad del sistema.
Los requerimientos de Calidad son aquellos Requerimientos No funcionales que definen la
Arquitectura del Software
4.1. Pasos del Método ADD
Los pasos realizados para diseñar una arquitectura usando el método ADD son los siguientes: [4]
1. Escoja el módulo para descomponer. El módulo para comenzar generalmente es todo el
sistema entero. Todas las entradas requeridas para este módulo debe estar disponible
(restricciones, requerimientos funcionales, requerimientos de calidad).
2. Depure el módulo según estos pasos:
A. Escoja los manejadores de arquitectura concretos del conjunto de escenarios de
calidad y requerimientos. Este paso determina que es importante para la
descomposición.
B. Escoja un patrón de arquitectura que satisfaga a los manejadores de arquitecturas.
Cree (o seleccione) el patrón basado en tácticas que pueden ser usadas para
alcanzar a los manejadores. Identifique los módulos hijos requeridos para
implementar las tácticas.
C. Instanciar los módulos y asignar la funcionalidad de los casos de uso y representar
usando múltiples vistas.
D. Defina las interfaces de los módulos hijos. La descomposición proporciona
módulos y restricciones en los tipos de interacciones de módulo. Documentar esta
información en el documento de interfaz para cada módulo.
E. Verifique y refine casos de uso y escenarios de calidad y cree las restricciones
para los módulos hijos. Este paso verifica que nada importante sea olvidado y
prepara en adelante a los módulos hijos para descomposición o implementación.
3. Repita el paso para cada módulo que necesite descomposición en adelante.

5 Utilización de ADD en el enfoque MDA


A continuación se define las Fases o Etapas del Desarrollo de Software con MDA, las Fases se
vieron en el modelo de Ciclo Genérico visto en el acápite 3.3, se agrega después de la Fase de
Análisis de Requisitos, la Arquitectura del Software producto de utilización de ADD

Fases
A continuación en el siguiente cuadro se presenta los entregables en cada una de las fases para el
desarrollo con MDA.

Fases Actividad o entrega Principal Herramientas


I - Análisis de Especificación de Requerimientos Microsoft Word
Requisitos Modelo de Requisitos : Rational XDE
 Modelo de Casos de de Uso
 Modelo del Dominio
II - Arquitectura  Vista de Casos de Uso Microsoft Word
del Software  Aplicación del Método ADD Rational XDE
o Vista de Módulos
o Vista de Despliegue
III - Modelado  Construcción del Modelo EJB Entorno visual de
Independiente de  Modelo Accessor para la Capa Web modelización
la Plataforma MagicDraw
(PIM)
IV - Modelado  Inclusión de Marcas en el Modelo EJB para el Entorno visual de
Dependiente de diseño de la Base de Datos y de los EJBs Modelización
la Plataforma  Modelando Representer y Accesors MagicDraw
(PSM) Components

V - Generación  Generación de la Aplicación y de la Base de Herramienta ANT


de Código Datos del ArcStyler
 Codificación de Test Client Herramienta
 Refinamiento a través del IDE, del Código o Jbuilder
inclusión de funcionalidades que no se puedan Servidor de Base
modelar, de Datos Oracle 9i
Apache Tomcat
BEA WebLogic
VI - Prueba  Preparación del Plan de pruebas Herramienta ANT
 Elaboración de casos de prueba del ArcStyler
 Pruebas del Funcionamiento de la Aplicación

 Para la fase I (Arquitectura del Software), se toma en cuenta la metodología Objectory de


Jacobson, nos dice que el modelo de requisitos consta de tres modelos principales Casos
de Uso que define el Comportamiento, Dominio del Problema que representa la
Información, y el modelo de Interfaces que representa la Presentación
 Para la fase II (Arquitectura del Software), se toma en cuenta el método ADD (Diseño
Dirigido por Atributos) siguiente los Pasos definidos en el acápite 4.1
 Las fases III, IV, V y VI, utilizan la herramienta MDA ArcStyler, tiene en cuenta los
modelos propios de la herramienta [4]

6. Aplicación de ADD en el Enfoque MDA


La aplicación es un sistema Web Académico, implementa los procesos de Matricula y Notas,
Programación que se realizan en las distintas sedes a nivel nacional del PCAD (Programa de
Complementación Académica Docente) de la Universidad Nacional Pedro Ruiz Gallo

6.1. Fase de Análisis de Requisitos


Uno de los entregables de esta Fase es el documento de Especificación de Requerimientos que se
detalla a continuación
Requerimientos Funcionales
Autenticar Usuario
El caso de uso es iniciado por cualquier Usuario del Sistema con el objetivo de autenticarlo, el
Sistema Académico de acuerdo a la Clase de Usuario determinara los Servicios del Sistema que
puede utilizar
Actualizar el registro de Estudiantes
El caso de uso es iniciado por la Secretaria Central o de Sede desde los diferentes terminales con
el objetivo mantener actualizado el registro de estudiantes en el sistema. El sistema realizar la
toma de imágenes o agregar una foto del estudiante.
Actualizar el registro de Docentes
El caso de uso es iniciado por la Secretaria Central, con el objetivo de mantener actualizado el
registro de los docentes en el sistema. El sistema generará automáticamente el código de los
nuevos profesores. El sistema deberá impedir que se pueda cambiar el código.
Actualizar el registro de Cursos
El caso de uso es iniciado por la Secretaria Central que desde los diferentes terminales,, el
sistema permitirá la creación de los diversas asignaturas
Actualizar el registro de Curricula
Es iniciado por la Secretaria Central , se realizara la creación de la curricula con la asignación de
los cursos previamente registrados, esta curricula será asignada a algunas de las modalidades de
estudio
Programar cursos por Ciclo de Ingreso
El caso de uso es iniciado por la Secretaria Central, el sistema permitirá realizar la programación
de los cursos por ciclo de ingreso, la asignación de esta programación a un grupo de una sede y
docente
Programar a un Grupo de Sede
El caso de uso es iniciado por la Secretaria Central, el sistema permitirá realizar la asignación de
la anterior programación a un grupo de una sede y docente
Matricular Estudiante
El caso de uso es iniciado por la Secretaria Central o alguna de Secretaria de Sede ,con el objetivo
de realizar el proceso de matricula en los cursos que le corresponda al estudiante.
Registrar Actas de Notas
El caso de uso es iniciado por la Secretaria Central o alguna de Secretaria de Sede con el objetivo
de realizar el ingreso de Actas de un grupo de alguna sede en uno de los cursos programados, una
vez realizado este proceso se puede modificar posteriormente Escenarios
Generar de Plan de Estudios
Lo inicia una de la secretaria central o de Sede , el sistema generara automáticamente una vez
concluida la curricula el plan estudio por estudiante
Consultar Alumnos por curso
Este caso uso tiene como objetivo la consulta de los estudiantes matriculados en un determinado
curso. El formato del reporte tiene que permitir su impresión en A4.
Requisitos No funcionales
Usabilidad
Toda la interfaz deberá ser en formato Web acorde a los estándares de la facultad a la cual
pertenece el programa
Confiabilidad
El sistema deberá soportar hasta 70 usuarios simultáneamente.
Licencia e instalación
No se requerirán licencias de usuario para el funcionamiento del software en las computadoras de
los usuarios
Disponibilidad.
Ya que la facultad cuenta con un Pool de Servidores teniendo un portal de la Facultad las 24
horas los 7 días de la semana el Sistema estará disponible 24 X 7
Seguridad
La información y los servicios del sistema deben estar protegidos de accesos no autorizados, es
decir debe existir confidencialidad.
Modificabilidad
Asegurar que los servicios del proceso de matriculas y los del proceso de programación trabajen
juntos sin depender demasiado uno de otro.

6.2. Fase Arquitectura del Software


Aplicación de ADD
1. Modulo a Descomponer
El modulo a descomponer es el Sistema Académico, los requerimientos funcionales y los no
funcionales se encuentran en el acápite 5.2.1.

2.a. Manejadores de la Arquitectura


- El Sistema deberá asegurar que el usuario es quien dice ser, accederá a los servicios del
sistema de acuerdo a su tipo de usuario.
- El usuario accederá a la información de acuerdo a su sede.
- Un cambio en el proceso de matricula no debería afectar el proceso de programación de
cursos por ciclo de ingreso o viceversa.

2.b. Patrón de Arquitectura


Los atributos de calidad críticos para el Sistema Académico son la Seguridad y la
Modificabilidad.
Las tácticas empleadas son las siguientes:
Autenticar Usuarios. Se debe asegurar que el usuario es quien dice ser, a través de creación de
Login y Password
Autorizar Usuarios. Una vez autenticados los usuarios deben acceder a los Servicios y la
Información de acuerdo a su Tipo de Usuario y Sede
Coherencia Semántica y Información Oculta. Separamos las responsabilidades tratando con la
Matricula y la Programación en sus propios módulos. Se espera que los 2 varíen debido a los
cambios de requerimientos
El patrón de Arquitectura resultante es el la imagen inferior
Autenticacion y Autorizacion

Matricula y Programacion

2.c. Instanciar Módulos y Asignar Funcionalidad Usando Múltiples Vistas

Vista de Descomposición de Módulos

S e g u rid ad

P ro g ra m acio n M a tricu la

Vista de Despliegue

Servidor Web/Mail
PCs Secretaria
Central
HTTP
HTTP
iNTRANET
Software Base: Internet Explorer 6
S.O. : Windows XP Profesional
Caract: PIII 1.7 Ghz, 20 GB Me...
PCs Secretaria Sedes
HTTP
INTERNET
HTTP

Software Base: Apache Tomcat 5


Servidor EJB Bea WebLogic
S.O. : Linux
Caract: PIV 2.3 Ghz, 40 GB Memoria
Servidor BaseDatos

Software Base: Oracle 9i


S.O. : Linux
Caract: PIV 2.3 Ghz, 80 GB Memoria
7. Conclusiones

a. En modelo de ciclo de Vida de desarrollo de Software con MDA es importante


definir una fase para la Arquitectura del Software
b. El método ADD nos permite definir la arquitectura del Software porque se
obtiene como resultado la Vista de Descomposición de Módulos y la Vista de
Despliegue
c. El método ADD tiene en cuenta los Requerimientos de Calidad del Software,
siendo necesario que el software cumpla ellos para que sea de calidad

Bibliografía
[1] Miller J. And J. Mukerjï, “MDA Guide Version 1.0.1” 2003 (62 Pages)
[2] Jesús García Molina, Jesús Rodríguez Vicente- Facultad de Informática de la Universidad de
Murcia, “Ingeniería de Modelos con MDA Estudio Comparativo de OptimalJ y ArcStyler”,2004
[3] Kleppe A. J. Warmer, and W. Bast, MDA Explained, 2003, Addison-Wesley
[4] Software Architecture in Practice, Len Bass, Paul Clements, Rick Kazman, 2003
Interactive Objects Software GmbH, “ArcStyler Overview”,2005