Transcript Presentaci n (1.229Mb)

Asignación de Tratamientos a
Responsabilidades en el contexto
del Diseño Dirigido por Modelos
David Ameller & Xavier Franch
Universitat Politècnica de Catalunya
0. Contenidos
1.
2.
3.
4.
5.
6.
7.
Motivación
¿Qué aporta RDT?
RDT al detalle
AR3L: De la teoría a la práctica
Ejemplo
Aportaciones
Trabajo futuro
1. Motivación
Responsabilidad: una responsabilidad
abarca uno o más de los propósitos u
obligaciones de un elemento.
Especificación
Diseño
Tratamiento: En el contexto de este
trabajo, un tratamiento es una acción
asociada a una responsabilidad con el
fin de satisfacerla.
2. ¿Qué aporta RDT?
• Las responsabilidades actúan como elemento
unificador.
3. RDT al detalle
Artefactos de
entrada
Conjunto de
responsabilidades
detectables
Personalización de
los tratamientos
Model Driven
Development
específico para
cada modelo
Detección de las
responsabilidades
de los artefactos
Refinamiento de las
responsabilidades
Preferencias
para la selección
de tratamientos
Conversión de las
responsabilidades
a la arquitectura
seleccionada
3.1. Responsibility Detection
• Validar el modelo de
especificación
• Identificar
responsabilidades con la
información del
repositorio
• Generar
responsabilidades con
los metadatos
necesarios para la
transformación
3.2. Responsibility Editor
• Añadir, quitar o modificar responsabilidades
• Visualizar gráficamente las responsabilidades
desde distintas perspectivas
• Según el origen y el tipo (jerárquico)
• Grafo de relaciones
3.3. Treatment Editor
• Añadir, quitar o modificar
tratamientos y requisitos no
funcionales
• Seleccionar los tratamientos
aplicables a cada
responsabilidad
• Adaptar las tablas de
asignación de tratamientos
• Definir cómo se aplica el
tratamiento
3.4. Responsibility Transformation
• Seleccionar el mejor de los
tratamientos aplicables a
cada responsabilidad según
los requisitos no funcionales
• Generar el modelo y la
arquitectura seleccionada a
partir de las
responsabilidades con
tratamientos asignados
4. AR3L: De la teoría a la practica
UML es el
artefacto de
entrada
La detección y
transformación de
responsabilidades
se han unificado en
AndroMDA
Al no tener un
modelo como
elemento de salida
no podemos
automatizar el
proceso MDD
Disponemos de la
arquitectura en 3
capas como
elemento de salida
4.1. Responsabilidades
• Las responsabilidades detectables son:
• Cardinalidad de asociaciones
• Identificadores de clase
• Pre/post condiciones de operaciones
• insertElement, deleteElement, listAll, existsElement,
notEmptyPopulation
4.2. Tratamientos
• Los tratamientos
soportados por AR3L
nos permiten evaluar la
viabilidad del proyecto
• Los tratamientos
disponen de
mecanismos dinámicos
para definir su
comportamiento en la
descripción
4.3. Implementación
Extensión del
metamodelo
proporcionado
por AndroMDA
Estereotipos usables
en restricciones OCL
del metamodelo
(responsabilidades)
Cada elemento
mantiene una
colección con sus
responsabilidades
Las responsabilidades
se detectan desde el
elemento responsable
5. Ejemplo
5.1. Screenshots (input)
Cardinalidad
Identificador
Pre/Post
5.2. Screenshots (process)
1. Carga el módulo AR3L
2. Carga el modelo UML
3. Valida el modelo
4. Genera listado de
responsabilidades con
tratamientos
5.3. Screenshots (output 1)
Requisitos no
funcionales
Descripciones
dinámicas en las
responsabilidades
5.4. Screenshots (output 2)
Descripciones
dinámicas para un
mismo tipo de
responsabilidad
Descripciones
dinámicas para
tipos distintos de
responsabilidades
6. Aportaciones
• RDT permite partir de diversos modelos de
entrada (incluso simultáneamente) ya que
usamos un elemento unificador, las
responsabilidades.
• Por el mismo motivo, los tipos de modelos
generados pueden ampliarse mediante
módulos específicos para su uso en nuevas
herramientas de generación de código.
• El automatismo alcanzado en la generación de
modelos permite usar esta propuesta para la
evaluación de distintas soluciones de una
misma pieza de software.
7. Trabajo futuro
• Implementar el soporte de más artefactos de
entrada y la detección de más tipos de
responsabilidades.
• Implementar la generación automática de
modelos como artefacto de salida e
incrementar el número de tratamientos
disponibles.
• Enfocar el marco de trabajo hacia las
necesidades reales de los usuarios.
Gracias por vuestra atención!
• AR3L homepage (código disponible)
• www.lsi.upc.edu/~gessi/AR3L
• Información de contacto
• David Ameller:
• [email protected]
• www.lsi.upc.edu/~dameller
• Xavier Franch:
• [email protected]
• www.lsi.upc.edu/~franch