Asignación de Tratamientos a Responsabilidades en el contexto del Diseño Dirigido por Modelos
David Ameller & Xavier FranchUniversitat Politècnica de Catalunya
0. Contenidos
1. Motivación
2. ¿Qué aporta RDT?
3. RDT al detalle
4. AR3L: De la teoría a la práctica
5. Ejemplo
6. Aportaciones
7. Trabajo futuro
1. Motivación
Tratamiento: En el contexto de este trabajo, un tratamiento es una acción asociada a una responsabilidad con el fin de satisfacerla.
Responsabilidad: una responsabilidad abarca uno o más de los propósitos u obligaciones de un elemento.
Especificación Diseño
2. ¿Qué aporta RDT?
• Las responsabilidades actúan como elemento unificador.
3. RDT al detalleArtefactos de entrada
Conjunto de responsabilidades
detectables
Detección de las responsabilidades de los artefactos
Refinamiento de las responsabilidades
Personalización de los tratamientos
Preferencias para la selección de tratamientos
Conversión de las responsabilidades a la arquitectura seleccionada
Model Driven Development
específico para cada modelo
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 practicaUML es el artefacto de entrada
La detección y transformación de responsabilidades se han unificado en AndroMDA
Disponemos de la arquitectura en 3 capas como elemento de salida
Al no tener un modelo como
elemento de salida no podemos
automatizar el proceso MDD
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 (responsabilidades)
Extensión del metamodelo
proporcionado por AndroMDA
Cada elemento mantiene una colección con sus responsabilidades
Estereotipos usables en restricciones OCL
del metamodelo
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
Top Related