Tratamiento de modelos UML mediante Enterprise Architecture

Tratamiento de modelos UML mediante Enterprise
Architecture
Dra. María José Escalona Cuaresma
[email protected]
www.lsi.us.es/~escalona
D. Javier Jesús Gutiérrez Rodríguez
[email protected]
www.lsi.us.es/~javierj
Web: www.sevinge.es e-mail: [email protected]
Telf.: 954 091 086 – FAX: 954 460 306
© MJ Escalona. 2007
Universidad de Sevilla
ETS Ingeniería Informática
Av. Reina Mercedes S/N
41015 Sevilla
Tlf. 954553867
Pabellón de Italia. C/ IsaacFax.
Newton
s/n. Planta 4ª 1
954553917
Isla de la Cartuja. 41092 Sevilla
Índice
¾ 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 navegacional
básico.
Pabellón de Italia. C/ Isaac Newton s/n. Planta 4ª
Isla de la Cartuja. 41092 Sevilla
© MJ Escalona. 2007
2
Transformaciones entre modelos de NDT
Relaciones entre el modelo de requisitos y
el modelo de análisis.
3
© 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 !!
4
© MJ Escalona. 2007
Relaciones entre modelos
No
No son
son las
las únicas,
únicas,
sólo
sólo las
las que
que se
se han
han
definido
definido yy
estudiado.
estudiado.
Las
Las
transformaciones
transformaciones yy
posteriores
posteriores
revisiones
revisiones pueden
pueden
obligar
obligar aa modeificar
modeificar
los
los resultados
resultados de
de la
la
ing.
ing. De
De requisitos.
requisitos.
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.
5
© MJ Escalona. 2007
Transformaciones entre modelos de NDT
Transformación modelo de requisitos de almacenamiento a
modelo conceptual básico.
6
© 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.
7
© 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.
8
© MJ Escalona. 2007
Modelo de requisitos de almacenamiento a modelo
conceptual
¾ Ejemplo
cd Requisitos de almacenamiento
«RA»
RA02. Administradores
«RA»
RA01. Enlaces
-
nombre: Cadena
categoría: NA01. Categorías
URL: Cadena
Descripción: Cadena
Aprobado: Enumerado = No
Fecha: Fecha [0..1]
-
«RA»
4.1.2.DEFINICIÓN DE LAS
NUEVAS NATURALEZAS::
NA01. Categorías
clave: Cadena
nombre: Cadena
-
nombre: Cadena
categoría padre: Cadena
9
© 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
Se resuelven
resuelven primero
primero todos
todos los
los datos
datos específicos
específicos de
de naturalezas
naturalezas predefinidas
predefinidas de
de
los
los RAs
RAs yy NAs.
NAs.
Después,
Después, por
por cada
cada dato
dato específico
específico con
con una
una nueva
nueva naturaleza,
naturaleza, se
se crea
crea un
un atributo
atributo
del
del tipo
tipo de
de la
la clase
clase generada
generada por
por la
la nueva
nueva naturaleza.
naturaleza.
10
© MJ Escalona. 2007
Modelo de requisitos de almacenamiento a modelo
conceptual
¾ Ejemplo
11
© 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
Asociación bidireccional:
bidireccional: ambos
ambos RA
RA se
se
referencian.
referencian.
Asociación
Asociación unidireccional:
unidireccional: un
un RA
RA referencia
referencia
al
al otro.
otro. En
En este
este caso,
caso, el
el extremo
extremo
unidireccional
unidireccional toma
toma multiplicidad
multiplicidad 0..n
0..n yy el
el
nombre
nombre // descripción
descripción de
de la
la naturaleza
naturaleza
12
© MJ Escalona. 2007
Modelo de requisitos de almacenamiento a modelo
conceptual
¾ Ejemplo
cd 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
+Administradores
+ nombre: Cadena
+ categoría: CLn-01.Categorías 0..*
+ URL: Cadena
+ Descripción: Cadena
+ fecha: Fecha
+aprobado
«CL»
CL-02.
Administradores
1 Atributo
+ nombre: Cadena
+ clave: Cadena
13
© 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
14
© MJ Escalona. 2007
Transformaciones entre modelos de NDT
Transformación modelo de requisitos de interacción a
modelo navegacional básico.
15
© MJ Escalona. 2007
Modelo de requisitos de interacción a modelo
navegacional
¾ Transformaciones (una por cada elemento):
1.
2.
3.
4.
5.
6.
Transformación de actores del sistema a grupo de actores en estudio.
Transformación de prototipos de visualización a nodos.
Transformación de prototipos de visualización a queries.
Transformación de prototipos de visualización a índices.
Inferencia de menús.
Transformación de prototipos de visualización a enlaces.
Existirá
Existirá un
un modelo
modelo de
de navegación
navegación por
por cada
cada grupo
grupo de
de actores
actores en
en estudio.
estudio.
16
© 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
17
© 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 => NOX).
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.
18
© MJ Escalona. 2007
Modelo de requisitos de almacenamiento a modelo
conceptual
¾ Ejemplo de transformación de prototipos de visualización a nodos.
19
© 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.
20
© 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.
21
© 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.
22
© 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 Ej emplo suelto
«QU»
QU-01. Query 1
«NO»
NO-01. PV01
«NO»
NO-02. PV02
«IN»
IN-01. Índice
para PV02.
«QU»
QU-02. Query 2
23
© 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.
24
© MJ Escalona. 2007
Modelo de requisitos de almacenamiento a modelo
conceptual
cd Tienda de música
«ME»
ME-01. Menú
principal.
«EN»
«EN»
«EN»
«IN»
IN-01.
Selección de
álbumes
«EN»
«QU»
QU-01. Buscar
canción
«EN»
«EN»
«IN»
Canciones
reusltado
«EN»
«NO»
NO-03. Album
«EN»
«IN»
IN-02. Índice de
canciones.
«NO»
NO-02. Canción
«EN»
25
© MJ Escalona. 2007
Modelo de requisitos de almacenamiento a modelo
conceptual
Se tienen el siguiente grafo navegacional.
¿Componentes
¿Componentes conexas?
conexas?
Componentes
Componentes con
con mayor
mayor varianza
varianza
22
NO-04
NO-04 (2),
(2), NO-03
NO-03 (2),
(2), NO-01
NO-01 (2)
(2)
26
© MJ Escalona. 2007
Modelo de requisitos de almacenamiento a modelo
conceptual
Menú principal.
27
© MJ Escalona. 2007
Modelo de requisitos de almacenamiento a modelo
conceptual
¾ Ejemplo de inferencia de menú.
cd Nodos
«NO»
NO-01. Enlaces
«QU»
5.2.1.2.QUERYS::QU-01.
Búsqueda de enlaces por nombre
«EN»
«QU»
5.2.1.2.QUERYS::Qu-02.
Búsqueda de enlaces por
categorías.
«EN»
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
cd Nodos
«NO»
NO-01. Enlaces
«QU»
5.2.1.2.QUERYS::QU-01.
Búsqueda de enlaces por nombre
«ME»
ME-01. Menú principal
«EN»
«EN»
«EN»
«QU»
5.2.1.2.QUERYS::Qu-02.
Búsqueda de enlaces por
categorías.
«EN»
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
28
© 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-Y
Los enlaces son unidireccionales o bidireccionales dependiendo del atributo deVuelta
a) Si PV-Y es destino de PV-X y no es múltiple, entonces se añade un enlace entre NO-x y
NO-Y
b) 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.
29
© 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 Ej emplo suelto
«QU»
QU-01. Query 1
«NO»
NO-01. PV01
«EN»
«IN»
IN-01. Índice
para PV02.
«EN»
«EN»
«EN»
«QU»
QU-02. Query 2
«NO»
NO-02. PV02
«EN»
30
© MJ Escalona. 2007
Modelo de requisitos de almacenamiento a modelo
conceptual
¾ Ejemplo del catálogo de enlaces:
cd Nodos
«NO»
NO-01. Enlaces
«QU»
5.2.1.2.QUERYS::QU-01.
Búsqueda de enlaces por nombre
«ME»
ME-01. Menú principal
«EN»
«EN»
«EN»
«QU»
5.2.1.2.QUERYS::Qu-02.
Búsqueda de enlaces por
categorías.
«EN»
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
¡ Este diagrama es incorrecto !
¿ Cómo se podría solucionar ?
31
© 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.
32
© MJ Escalona. 2007
Transformaciones entre modelos de NDT
Generación de modelos finales.
33
© MJ Escalona. 2007
Generación de modelos finales
¾ Supongamos que queremos hacer cambios al modelo
conceptual obtenido:
1.
2.
3.
4.
5.
Añadir una nueva clase.
Fusionar tres clases en una única nueva clase.
Añadir una nueva asociación.
Cambiar una asociación por una agregación.
Añadir una nueva generalización.
¿Cuáles de estos cambios nos obligan a modificar el DRS?
34
© MJ Escalona. 2007
Generación de modelos finales
3,
3, el
el cambio
cambio afecta
afecta al
al resultado
resultado
de
de la
la fase
fase de
de requisitos
requisitos
2,
2, el
el cambio
cambio no
no afecta
afecta al
al
resultado
resultado de
de la
la fase
fase de
de requisitos
requisitos
,
, el
el cambio
cambio no
no afecta
afecta
directamente
directamente al
al resultado
resultado de
de la
la
fase
fase de
de requisitos,
requisitos, pero
pero es
es
conveniente
conveniente revisar
revisar posibles
posibles
errores
errores oo incongruencias.
incongruencias.
35
© MJ Escalona. 2007
Generación de modelos finales
¾ Supongamos que queremos hacer cambios al modelo de
navegación obtenido:
1.
2.
3.
4.
Pasar de un índice a una ruta guiada o viceversa.
Añadir un nuevo índice o ruta guiada.
Establecer una jerarquía de menús.
Añadir una nueva query.
¿Cuáles de estos cambios nos obligan a modificar el DRS?
36
© MJ Escalona. 2007
Generación de modelos finales
3,
3, el
el cambio
cambio afecta
afecta al
al resultado
resultado de
de la
la
fase
fase de
de requisitos
requisitos
2,
2, el
el cambio
cambio no
no afecta
afecta al
al resultado
resultado
de
de la
la fase
fase de
de requisitos
requisitos
,
, el
el cambio
cambio no
no afecta
afecta directamente
directamente
al
al resultado
resultado de
de la
la fase
fase de
de requisitos,
requisitos,
pero
pero es
es conveniente
conveniente revisar
revisar posibles
posibles
errores
errores oo incongruencias.
incongruencias.
37
© 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 NO01. enlaces a ME-01. Menú principal.
¾ A la vista de las transparencias anteriores, ¿obramos bien?
¿tenemos que revisar / modificar el DRS?
38
© MJ Escalona. 2007
Generación del modelo navegacional final
Nuevos enlaces
1.
1. Si
Si se
se estima
estima la
la necesidad
necesidad de
de añadir
añadir un
un enlace
enlace entre
entre dos
dos nodos,
nodos, es
es necesario
necesario
revisar
revisar el
el resultado
resultado de
de la
la ingeniería
ingeniería de
de requisitos
requisitos para
para estudiar
estudiar los
los
prototipos
prototipos de
de salida
salida de
de los
los PV
PV que
que generaron
generaron dichos
dichos nodos
nodos yy añadir
añadir la
la
nueva
nueva posibilidad
posibilidad de
de navegación.
navegación.
2.
2. La
La única
única explicación
explicación para
para detectar
detectar la
la necesidad
necesidad de
de añadir
añadir un
un enlace
enlace se
se debe
debe aa
que
que se
se permita
permita la
la opción
opción de
de volver
volver atrás.
atrás. En
En este
este caso,
caso, se
se puede
puede añadir
añadir el
el
enlace
enlace sin
sin repercusión
repercusión alguna
alguna en
en otros
otros modelos.
modelos.
39
© MJ Escalona. 2007
Transformaciones entre modelos de NDT
Generación del modelo navegacional final.
40
© 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 sistema
¾ Revisiones:
»
»
»
»
»
»
»
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.
41
© 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:
42
© 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:
43
© 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:
44
© 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.
45
© 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.
46
© 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 anteriores
¾ Revisió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.
47
© MJ Escalona. 2007