Tratamiento de modelos UML mediante Enterprise...
Transcript of 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
2© MJ Escalona. 2007
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
3© MJ Escalona. 2007
Transformaciones entre modelos de NDTTransformaciones entre modelos de NDT
Relaciones entre el modelo de requisitos y el modelo de análisis.
4© MJ Escalona. 2007
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 !!
5© MJ Escalona. 2007
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.
6© MJ Escalona. 2007
Transformaciones entre modelos de NDTTransformaciones entre modelos de NDT
Transformación modelo de requisitos de almacenamiento a modelo conceptual básico.
7© MJ Escalona. 2007
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.
8© MJ Escalona. 2007
Modelo de requisitos de almacenamiento a modelo conceptual
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.
9© MJ Escalona. 2007
Modelo de requisitos de almacenamiento a modelo conceptual
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
10© MJ Escalona. 2007
Modelo de requisitos de almacenamiento a modelo conceptual
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.
12© MJ Escalona. 2007
Modelo de requisitos de almacenamiento a modelo conceptual
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
13© MJ Escalona. 2007
Modelo de requisitos de almacenamiento a modelo conceptual
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
14© MJ Escalona. 2007
Modelo de requisitos de almacenamiento a modelo conceptual
Sistema de tablón de anuncios:» Realizar las transformaciones paso a paso del modelo de requisitos de
almacenamiento de información al modelo conceptual
15© MJ Escalona. 2007
Transformaciones entre modelos de NDTTransformaciones entre modelos de NDT
Transformación modelo de requisitos de interacción a modelo navegacional básico.
16© MJ Escalona. 2007
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.
17© MJ Escalona. 2007
Modelo de requisitos de almacenamiento a modelo conceptual
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
18© MJ Escalona. 2007
Modelo de requisitos de almacenamiento a modelo conceptual
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.
19© MJ Escalona. 2007
Modelo de requisitos de almacenamiento a modelo conceptual
Ejemplo de transformación de prototipos de visualización a nodos.
20© MJ Escalona. 2007
Modelo de requisitos de almacenamiento a modelo conceptual
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.
21© MJ Escalona. 2007
Modelo de requisitos de almacenamiento a modelo conceptual
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.
22© MJ Escalona. 2007
Modelo de requisitos de almacenamiento a modelo conceptual
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.
23© MJ Escalona. 2007
Modelo de requisitos de almacenamiento a modelo conceptual
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
«QU»QU-02. Query 2
«IN»IN-01. Índice para PV02.
24© MJ Escalona. 2007
Modelo de requisitos de almacenamiento a modelo conceptual
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.
25© MJ Escalona. 2007
Modelo de requisitos de almacenamiento a modelo conceptual
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»
26© MJ Escalona. 2007
Modelo de requisitos de almacenamiento a modelo conceptual
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)
27© MJ Escalona. 2007
Modelo de requisitos de almacenamiento a modelo conceptual
Menú principal.Menú principal.
28© MJ Escalona. 2007
Modelo de requisitos de almacenamiento a modelo conceptual
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
«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.
«ME»ME-01. Menú principal
«EN»
«EN»
«EN»
«EN»
29© MJ Escalona. 2007
Modelo de requisitos de almacenamiento a modelo conceptual
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.
30© MJ Escalona. 2007
Modelo de requisitos de almacenamiento a modelo conceptual
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
«QU»QU-01. Query 1
«QU»QU-02. Query 2
«IN»IN-01. Índice para PV02.«EN»
«EN»
«EN»
«EN»
«EN»
31© MJ Escalona. 2007
Modelo de requisitos de almacenamiento a modelo conceptual
Ejemplo del catálogo de enlaces: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.
«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 ?
32© MJ Escalona. 2007
Modelo de requisitos de almacenamiento a modelo conceptual
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.
33© MJ Escalona. 2007
Transformaciones entre modelos de NDTTransformaciones entre modelos de NDT
Generación de modelos finales.
34© MJ Escalona. 2007
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?
35© MJ Escalona. 2007
Generación de modelos finales
, 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.
, 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.
36© MJ Escalona. 2007
Generación de modelos finales
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?
37© MJ Escalona. 2007
Generación de modelos finales
, 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.
, 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.
38© MJ Escalona. 2007
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?
39© MJ Escalona. 2007
Generación del modelo navegacional final
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
40© MJ Escalona. 2007
Transformaciones entre modelos de NDTTransformaciones entre modelos de NDT
Generación del modelo navegacional final.
41© MJ Escalona. 2007
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.
42© MJ Escalona. 2007
Generación del modelo navegacional final
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:
43© MJ Escalona. 2007
Generación del modelo navegacional final
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:
44© MJ Escalona. 2007
Generación del modelo navegacional final
Revisión de las queries.» Añadir una nueva query:» Borrar una query: » Modificar las frases de una query:
45© MJ Escalona. 2007
Generación del modelo navegacional final
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.
46© MJ Escalona. 2007
Generación del modelo navegacional final
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.
47© MJ Escalona. 2007
Generación del modelo navegacional final
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.