Asignación de Tratamientos a Responsabilidades en el contexto del Diseño Dirigido por Modelos

1. Asignación de Tratamientos a Responsabilidades en el contexto del Diseño Dirigido por Modelos David Ameller & Xavier Franch Universitat Politècnica de Catalunya

2. 0. Contenidos • Motivación • ¿Qué aporta RDT? • RDT al detalle • AR3L: De la teoría a la práctica • Ejemplo • Aportaciones • Trabajo futuro

3. 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.

4. 2. ¿Qué aporta RDT? • Las responsabilidades actúan como elemento unificador.

5. 3. RDT al detalle Artefactos de entrada Conjunto de responsabilidades detectables Detección de las responsabilidades de los artefactos Personalización de los tratamientos Refinamiento de las responsabilidades Preferencias para la selección de tratamientos Model Driven Development específico para cada modelo Conversión de las responsabilidades a la arquitectura seleccionada

6. 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

7. 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

8. 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

9. 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

10. 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

11. 4.1. Responsabilidades • Las responsabilidades detectables son: • Cardinalidad de asociaciones • Identificadores de clase • Pre/post condiciones de operaciones • insertElement, deleteElement, listAll, existsElement, notEmptyPopulation

12. 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

13. 4.3. Implementación (responsabilidades) Extensión del metamodelo proporcionado por AndroMDA Cada elemento mantiene una colección con sus responsabilidades Las responsabilidades se detectan desde el elemento responsable Estereotipos usables en restricciones OCL del metamodelo

14. 5. Ejemplo

15. 5.1. Screenshots (input) Cardinalidad Identificador Pre/Post

16. 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

17. 5.3. Screenshots (output 1) Requisitos no funcionales Descripciones dinámicas en las responsabilidades

18. 5.4. Screenshots (output 2) Descripciones dinámicas para un mismo tipo de responsabilidad Descripciones dinámicas para tipos distintos de responsabilidades

19. 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.

20. 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.

21. Gracias por vuestra atención! • AR3L homepage (código disponible) • www.lsi.upc.edu/~gessi/AR3L • Información de contacto • David Ameller: • dameller@lsi.upc.edu • www.lsi.upc.edu/~dameller • Xavier Franch: • franch@lsi.upc.edu • www.lsi.upc.edu/~franch