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

Presentación del tema: "Asignación de Tratamientos a Responsabilidades en el contexto del Diseño Dirigido por Modelos David Ameller & Xavier Franch Universitat Politècnica de."— Transcripción de la presentación:

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

3 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ónDiseño

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

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

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 Estereotipos usables en restricciones OCL del metamodelo Las responsabilidades se detectan desde el elemento responsable

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