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

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:

• dameller@lsi.upc.edu• www.lsi.upc.edu/~dameller

• Xavier Franch: • franch@lsi.upc.edu• www.lsi.upc.edu/~franch