Tratamiento de modelos UML mediante Enterprise...

1© MJ Escalona. 2007

Web: www.sevinge.es e-mail: [email protected] Telf.: 954 091 086 – FAX: 954 460 306

Pabellón de Italia. C/ Isaac Newton s/n. Planta 4ª Isla de la Cartuja. 41092 Sevilla

DraDra. María José Escalona Cuaresma. María José Escalona [email protected]

www.lsi.us.es/~escalona

D. Javier D. Javier JesúsJesús GutiérrezGutiérrez RodríguezRodrí[email protected]

www.lsi.us.es/~javierj

Universidad de SevillaETS Ingeniería Informática

Av. Reina Mercedes S/N41015 Sevilla

Tlf. 954553867Fax. 954553917

Tratamiento de modelos UML mediante Tratamiento de modelos UML mediante EnterpriseEnterpriseArchitectureArchitecture


Pabellón de Italia. C/ Isaac Newton s/n. Planta 4ª Isla de la Cartuja. 41092 Sevilla

Relaciones entre el modelo de requisitos y el modelo de análisis.Transformación modelo de requisitos de almacenamiento a modelo conceptual básico.Transformación modelo de requisitos de información a modelo navegacionalbásico.

Índice


Transformaciones entre modelos de NDTTransformaciones entre modelos de NDT

Relaciones entre el modelo de requisitos y el modelo de análisis.


Relaciones entre modelos

Transformación: proceso por el que, a partir de un modelo de origen se genera un modelo de destino.¡¡ El modelo de destino no puede tener más información que el modelo de origen !!


Relaciones entre modelos

No son las únicas, sólo las que se han

definido y estudiado.

No son las únicas, sólo las que se han

definido y estudiado.

Estas relaciones permitirán establecer un conjunto de reglas que nos permita obtener modelos conceptuales y de navegación básicos a partir de los requisitos.

Las transformaciones y

posteriores revisiones pueden

obligar a modeificarlos resultados de la ing. De requisitos.

Las transformaciones y

posteriores revisiones pueden

obligar a modeificarlos resultados de la ing. De requisitos.



Transformación modelo de requisitos de almacenamiento a modelo conceptual básico.


Modelo de requisitos de almacenamiento a modelo conceptual

Esta transformación consta de tres pasos:1. Transformación de requisitos de almacenamiento (RA) y nuevas

naturalezas (NA) a clases.2. Transformación de datos específicos a atributos.3. Transformación de datos específicos a asociaciones entre clases.



1. Transformación de requisitos de almacenamiento y nuevas naturalezas a clases.a) Por cada requisito de almacenamiento o nueva naturaleza se crea una

nueva clase.b) El nombre y descripción de la clase son las mismas que en el requisito o

naturaleza.c) El nombre de una clase obtenida de un RA empieza por CL y el de una

clase obtenida de una NA.por CLn.d) Opcionalmente, se pueden agrupar todas las clases CL en un mismo

paquete y todas las clases CLn en otro paquete.



Ejemplocd Requisitos de almacenamiento

«RA»RA01. Enlaces

- nombre: Cadena- categoría: NA01. Categorías- URL: Cadena- Descripción: Cadena- Aprobado: Enumerado = No- Fecha: Fecha [0..1]

«RA»RA02. Administradores

- clave: Cadena- nombre: Cadena

«RA»4.1.2.DEFINICIÓN DE LAS NUEVAS NATURALEZAS::

NA01. Categorías

- nombre: Cadena- categoría padre: Cadena



2. Transformación de datos específicos a atributos.a) Sólo se tiene en cuenta los datos específicos (DE) cuya naturaleza es

una naturaleza predefinida o una nueva naturaleza, nunca otro RA.b) El nombre de cada atributo es el nombre de cada dato específico.c) La descripción de cada atributo es la descripción de cada DE.d) El tipo de cada atributo es la naturaleza del DE.

Se resuelven primero todos los datos específicos de naturalezas predefinidas de los RAs y NAs.

Después, por cada dato específico con una nueva naturaleza, se crea un atributo del tipo de la clase generada por la nueva naturaleza.

Se resuelven primero todos los datos específicos de naturalezas predefinidas de los RAs y NAs.

Después, por cada dato específico con una nueva naturaleza, se crea un atributo del tipo de la clase generada por la nueva naturaleza.



Ejemplo



3. Transformación de datos específicos a asociaciones entre clases.a) Sólo se tiene en cuenta los datos

específicos (DE) cuya naturaleza es otro RA.

b) Se define una asociación binaria entre la clase que se ha creado para el otro RA y la clase que contiene el DE.

c) El rol y la multiplicidad son las definidas en el dato específico.

cd Diagrama conceptual

«CL»X

«CL»Y

Asociación bidireccional: ambos RA se referencian.

Asociación unidireccional: un RA referencia al otro. En este caso, el extremo unidireccional toma multiplicidad 0..n y el nombre / descripción de la naturaleza

Asociación bidireccional: ambos RA se referencian.

Asociación unidireccional: un RA referencia al otro. En este caso, el extremo unidireccional toma multiplicidad 0..n y el nombre / descripción de la naturaleza



Ejemplocd Requisitos de almacenamiento

«RA»RA01. Enlaces

- nombre: Cadena- categoría: NA01. Categorías- URL: Cadena- Descripción: Cadena- Aprobado: RA-02.Administradores = No- Fecha: Fecha [0..1]

«RA»RA02. Administradores

- clave: Cadena- nombre: Cadena

cd Diagrama conceptual

«CL»CL-01.Enlaces

Atributo+ nombre: Cadena+ categoría: CLn-01.Categorías+ URL: Cadena+ Descripción: Cadena+ fecha: Fecha

«CL»CL-02.

Administradores

Atributo+ nombre: Cadena+ clave: Cadena

+Administradores

0..*

+aprobado

1



Sistema de tablón de anuncios:» Realizar las transformaciones paso a paso del modelo de requisitos de

almacenamiento de información al modelo conceptual



Transformación modelo de requisitos de interacción a modelo navegacional básico.


Modelo de requisitos de interacción a modelo navegacional

Transformaciones (una por cada elemento):1. Transformación de actores del sistema a grupo de actores en estudio.2. Transformación de prototipos de visualización a nodos.3. Transformación de prototipos de visualización a queries.4. Transformación de prototipos de visualización a índices.5. Inferencia de menús.6. Transformación de prototipos de visualización a enlaces.

Existirá un modelo de navegación por cada grupo de actores en estudio.Existirá un modelo de navegación por cada grupo de actores en estudio.



1. Transformación de actores del sistema a grupo de actores en estudio.a) Creación de un actor en estudio por cada actor raíz (no hereda de

nadie).b) A cada actor en estudio se agregan los actores derivados del actor raíz

que le dio origen que no tengan prototipos de visualización diferentes (todos los PV del hijo incluidos en los del padre).

c) Si hay algún actor derivado con sus propios prototipos se crean nuevos actores en estudio a partir de ellos



2. Transformación de prototipos de visualización a nodos.a) Se crea un nodo por cada prototipo de visualización.b) El identificador de cada nodo se genera automáticamente (PV-X => NO-

X).c) Los atributos serán los datos específicos del patrón de visualización.d) Las operaciones serán los requisitos funcionales asociados al patrón de

visualización.



Ejemplo de transformación de prototipos de visualización a nodos.



3. Transformación de prototipos de visualización a queries.a) Cada frase del prototipo se traduce en una query.b) El nombre y el cuerpo de la query es el mismo que el de la frase.



Ejemplo de transformación de prototipos de visualización a queries.

cd 5.2.1.2.QUERYS

«FR»4.4.1.DEFINICIÓN DE FRASES::FR01. Búsqueda de

enlaces por nombre

«FR»4.4.1.DEFINICIÓN DE FRASES::FR02. Búsqueda de

enlaces por categorías

«QU»QU-01. Búsqueda de enlaces por nombre

«QU»Qu-02. Búsqueda de enlaces por categorías.



4. Transformación de prototipos de visualización a índices.a) Sólo para relaciones entre prototipos de visualización con atributo

múltiple.b) Para cada PV que tenga cómo destino otro PV con atributo múltiple se

crea un índice antes que el nodo.c) Si el PV destino ha generado una query (es decir, tenía una frase), el

índice lleva a dicha query.



Ejemplo de transformación de prototipos de visualización a índices.» Supongamos un PV01, un PV02, y una asociación múltiple del 01 al 02.» Supongamos que el PV02 tiene dos frases.

cd Ejemplo suelto

«NO»NO-01. PV01

«NO»NO-02. PV02

«QU»QU-01. Query 1


«IN»IN-01. Índice para PV02.



5. Inferencia de menús.a) Sólo genera el menú inicial.b) Se genera el grafo navegacional.

Nodos, queries, índices -> Vértices.Enlaces -> Aristas.

a) Se cuentan las componentes conexas.a) Si sólo hay una no es necesario menú.b) Si hay más de una:

a) Seleccionar el vértice con mayor valencia de salida de cada componente conexa.

b) Si es un query o índice o modo sin query, estupendo.c) Si no, se selecciona la query.

b) Se crea un menú que enlace a cada uno de los vértices seleccionado.



cd Tienda de música

«QU»QU-01. Buscar

canción

«IN»IN-01.

Selección de álbumes

«NO»NO-02. Canción

«NO»NO-03. Album

«ME»ME-01. Menú

principal.

«IN»IN-02. Índice de

canciones.

«IN»Canciones reusltado

«EN»«EN»

«EN»

«EN»

«EN»«EN»

«EN»«EN»

«EN»



Se tienen el siguiente grafo navegacional.Se tienen el siguiente grafo navegacional.

¿Componentes conexas?¿Componentes conexas? 22

Componentes con mayor varianzaComponentes con mayor varianza NO-04 (2), NO-03 (2), NO-01 (2)NO-04 (2), NO-03 (2), NO-01 (2)



Menú principal.Menú principal.



Ejemplo de inferencia de menú.cd Nodos

«NO»NO-01. Enlaces

Atributo de nodo- RA01. Categoría: - RA01. Nombre: - RA01. Fecha: - RA01. URL: - RA01. Descripción:

Operacion de nodo+ añadirNuevoEnlace() : void+ buscarEnlaces() : void+ verDetallesDeEnlaces() : void

«QU»5.2.1.2.QUERYS::QU-01.

Búsqueda de enlaces por nombre

«QU»5.2.1.2.QUERYS::Qu-02.

Búsqueda de enlaces por categorías.

«EN»

«EN»

cd Nodos




«QU»5.2.1.2.QUERYS::QU-01.


«QU»5.2.1.2.QUERYS::Qu-02.


«ME»ME-01. Menú principal

«EN»

«EN»

«EN»

«EN»



6. Transformación de prototipos de visualización a enlaces.Sea NO-X obtenido de PV-X y NO-Y obtenido de PV-YLos enlaces son unidireccionales o bidireccionales dependiendo del atributo deVueltaa) Si PV-Y es destino de PV-X y no es múltiple, entonces se añade un enlace entre NO-x y

NO-Yb) Si lo es con el atributo múltiple, debe añadirse un índice antes de PV-Y, un enlace de PV-X

al índice y otro del índice a PV-Y.c) Si NO-Y tiene queries, todos los enlaces que vayan a PV-Y deben pasar antes por las

queries. Además se añade un enlace desde las queries a PV-Y.



Ejemplo:» Supongamos un PV01, un PV02, y una asociación múltiple del 01 al 02.» Supongamos que el PV02 tiene dos frases.

cd Ejemplo suelto

«NO»NO-01. PV01

«NO»NO-02. PV02



«IN»IN-01. Índice para PV02.«EN»

«EN»

«EN»

«EN»

«EN»



Ejemplo del catálogo de enlaces:cd Nodos




«QU»5.2.1.2.QUERYS::QU-01.


«QU»5.2.1.2.QUERYS::Qu-02.


«ME»ME-01. Menú principal

«EN»

«EN»

«EN»

«EN»

¡ Este diagrama es incorrecto !¡ Este diagrama es incorrecto !

¿ Cómo se podría solucionar ?¿ Cómo se podría solucionar ?



Ejercicio: realizar las transformaciones de los PV y FR del sistema de tablón de anuncios.Desarrollar sólo el modelo para el actor en estudio administrador y tres PV: eventos, categorías y administradores.A elegir las asociaciones entre PVs que son unidireccionales y bidireccionales, así como la multipicidad.



Generación de modelos finales.


Generación de modelos finales

Supongamos que queremos hacer cambios al modelo conceptual obtenido:1. Añadir una nueva clase.2. Fusionar tres clases en una única nueva clase.3. Añadir una nueva asociación.4. Cambiar una asociación por una agregación.5. Añadir una nueva generalización.

¿Cuáles de estos cambios nos obligan a modificar el DRS?¿Cuáles de estos cambios nos obligan a modificar el DRS?



, el cambio afecta al resultado de la fase de requisitos

, el cambio no afecta al resultado de la fase de requisitos

, el cambio no afecta directamente al resultado de la fase de requisitos, pero es conveniente revisar posibles errores o incongruencias.






Supongamos que queremos hacer cambios al modelo de navegación obtenido:1. Pasar de un índice a una ruta guiada o viceversa.2. Añadir un nuevo índice o ruta guiada.3. Establecer una jerarquía de menús.4. Añadir una nueva query.

¿Cuáles de estos cambios nos obligan a modificar el DRS?¿Cuáles de estos cambios nos obligan a modificar el DRS?


Generación del modelo navegacional final

Antes obtuvimos un diagrama de navegación incorrecto.Lo solucionamos añadiendo un enlace unidireccional desde NO-01. enlaces a ME-01. Menú principal.A la vista de las transparencias anteriores, ¿obramos bien? ¿tenemos que revisar / modificar el DRS?



1. Si se estima la necesidad de añadir un enlace entre dos nodos, es necesario revisar el resultado de la ingeniería de requisitos para estudiar los prototipos de salida de los PV que generaron dichos nodos y añadir la nueva posibilidad de navegación.

2. La única explicación para detectar la necesidad de añadir un enlace se debe a que se permita la opción de volver atrás. En este caso, se puede añadir el enlace sin repercusión alguna en otros modelos.

1. Si se estima la necesidad de añadir un enlace entre dos nodos, es necesario revisar el resultado de la ingeniería de requisitos para estudiar los prototipos de salida de los PV que generaron dichos nodos y añadir la nueva posibilidad de navegación.

2. La única explicación para detectar la necesidad de añadir un enlace se debe a que se permita la opción de volver atrás. En este caso, se puede añadir el enlace sin repercusión alguna en otros modelos.

Nuevos enlacesNuevos enlaces



Generación del modelo navegacional final.



Tras obtener el modelo navegacional, el analista debe realizar una serie de revisiones para ver si el modelo puede ser modificado para adecuarse o resultar más cercano a la realidad del sistemaRevisiones:» Revisión de nodos.» Revisión de índices y rutas guiadas.» Revisión de las queries.» Revisión de los menús.» Revisión de los enlaces.» Revisión de nombres y descripciones.» Revisión de la navegación del modelo.



Revisión de nodos.» Añadir un nuevo nodo:» Borrar un nodo:» Varios nodos del modelo básico pasan a ser uno solo en el modelo final:» Un nodo del modelo básico pasa a ser varios nodos en el modelo final:» Añadir nuevos atributos en un nodo:» Borrar atributos en un nodo:



Revisión índices y rutas guiadas.» Pasar de un índice a una ruta guiada o viceversa:» Añadir un nuevo índice o ruta guiada:» Borrar un índice o ruta guiada:



Revisión de las queries.» Añadir una nueva query:» Borrar una query: » Modificar las frases de una query:



Revisión de los menús.» Añadir un nuevo menú:» Borrar un menú:» Establecer una jerarquía de menús:» Modificaciones de los destinos en los menús.



Revisión de los enlaces.» Añadir un nuevo enlace:» Borrar un enlace:» Pasar un enlace unidireccional a otro bidireccional.

Si se estima la necesidad de añadir un enlace entre dos nodos, es necesario revisar el resultado de la ingeniería de requisitos para estudiar los prototipos de salida de los PV que generaron dichos nodos y añadir la nueva posibilidad de navegación.La única explicación para detectar la necesidad de añadir un enlace se debe a que se permita la opción de volver atrás. En este caso, se puede añadir el enlace sin repercusión alguna en otros modelos.



Revisión de nombres y descripciones.» Cualquier cambio en nombres y descripciones no afectará a los

resultados de las fases anterioresRevisión de la navegación del modelo.» No debe existir ningún vértice aislado.» No debe existir puntos de no retorno. » Todos los puntos de la navegación deben ser alcanzables desde

cualquier otro punto.

Tratamiento de modelos UML mediante Enterprise...

Documents

Transcript of Tratamiento de modelos UML mediante Enterprise...