Modelos conceptuales UML semánticamente

Assignatura 2008-2009
Modelos conceptuales UML semánticamente equivalentes
(Catálogo de refactorings de especificación)
Un modelo conceptual de análisis sobre un sistema real representa conceptos, relaciones y reglas de
restricción del mundo real. Por lo tanto el diagrama de clases UML del modelo de datos junto con las
restricciones de integridad debe tener una interpretación unívoca desde el momento inicial y su significado
preciso no puede ser objeto de la opinión de cada uno puesto que representa una realidad (de un sistema
presente o futuro) que asumimos como única.
¿Qué pasa pues cuando dos modelos conceptuales sobre un mismo sistema presentan diagramas distintos?
Ciertamente es posible representar en UML un mismo sistema de varias maneras distintas. Si partimos de la
premisa de que la realidad es única, la diversidad de diagramas sólo puede ser posible si son equivalentes
entre sí. Ello implica pues que deberán existir reglas de transformación que permitan pasar de uno al otro sin
variar su significado (semántica). Usualmente a algunas de estas transformaciones se les denomina
normalizaciones.
En este artículo se presenta un catálogo básico de transformaciones (o refactorizaciones).
Diremos que dos diagramas de clases UML son semánticamente equivalentes si existe al menos una secuencia
de transformaciones que llevan de uno al otro.
El objeto de un catálogo de refactorizaciones es sentar las bases para entrenar y ejercitar la detección de
secuencias de transformación entre diversas representaciones de modelo con el fin de determinar si son
semánticamente equivalentes o no. En el ámbito denominado de los “UML practitioners” se producen a
menudo debates sobre el rigor de los modelos UML y la adecuación de su nivel de formalismo. Sin entrar la
cuestión de cómo debe ser el formalismo del UML aceptaremos por principio la regla de que una actividad de
ingeniería exige que el significado de una especificación no dependa de la interpretación que se le dé sino que
debe tener una única interpretación, tal como pretenden los planos y memorias técnicas de las ingenierías
clásicas.
Las dos opciones que se presentan en cada transformación de este catálogo (la A y la B) son equivalentes
entre sí desde el punto de vista semántico. En todas ellas las opciones A son más adecuadas que las opciones
B para la fase de análisis, en la que tratamos de representar conceptos del mundo real. Las opciones A
aprovechan mejor las capacidades el lenguaje UML que las B. Otra cuestión es que debido a limitaciones
tecnológicas nos inclinemos por una u otra. Por ejemplo si se utiliza una herramienta UML que no soporta
asociaciones n-arias podemos representar el modelo con la opción B.
El término de equivalencia semántica utilizado en este artículo se refiere a la equivalencia entre modelos
conceptuales de datos para representar una misma realidad de forma aceptable.
Los fundamentos teóricos y metodológicos de esta forma de representar la realidad fueron establecidos por
Peter Chen en su artículo “The entity-relationship model. A basis for the enterprise view of data” en 1976.
- 1/8 -
Assignatura 2008-2009
1.- Binaria * a * dos binarias 1 a *
Opción A:
Opción B:
+ Una restricción: Una misma pareja de instancias A, B no puede asociarse con más de una instancia de AB.
Comentarios:
•
•
•
•
Si en la opción A no hay clase asociativa AB entonces la clase AB de la opción B no tiene atributos
La restricción se ha representado textualmente ya que UML no dispone de notación gráfica para
expresarla.
AB no tiene clave externa (es asociativa)
Esta transformación es la clásica normalización de relaciones * a * en dos 1 a *
- 2/8 -
Assignatura 2008-2009
2.- Ternaria tres binarias 1 a *
Opción A:
B
*
A
C
*
*
ABC
Opción B:
+ Una restricción: Una misma terna de instancias de A, B y C no puede asociarse con más de una instancia de
ABC.
Comentarios:
•
•
•
•
Si en la opción A no hay clase asociativa ABC entonces la clase ABC de la opción B no tiene
atributos.
La restricción se ha representado textualmente ya que UML no dispone de notación gráfica para
expresarla.
ABC no tiene clave externa (es asociativa)
Esta transformación también de denomina normalización al igual que en el caso anterior.
- 3/8 -
Assignatura 2008-2009
3.- Ternaria 2 Binarias asociativas en cascada
Opción A:
B
*
A
C
*
*
ABC
Opción B:
Comentarios:
•
•
Una asociación ternaria necesita una instancia de A, una de B y una de C
La multiplicidad 1..* de C garantiza que no pueda existir una instancia de AB sin estar asociada por
lo menos a una de C.
- 4/8 -
Assignatura 2008-2009
4.- Atributos Asociaciones 1 a 1
4bis.- Atributos asociaciones * a 1
Opción A (sin opcionalidad):
Opción A (con opcionalidad)
Opción B (sin opcionalidad):
Opción B (con opcionalidad):
Opción Bbis (sin opcionalidad):
Opción Bbis (con opcionalidad):
Comentarios:
•
Los atributos de una clase son tipos de datos simples (tipos primitivos) o bien tipos de datos.
o
o
•
Definimos un tipo de datos como un conjunto de valores para los cuales su identidad única
no es significativa en nuestro modelo conceptual, como es el caso de Magnitud en la figura.
Otro ejemplo similar y frecuente es la clase Dirección, que puede tener una estructura
compleja. Sin embargo normalmente la identidad de las instancias de Dirección serán
irrelevantes en nuestro modelo a no ser que utilicemos un sistema de “callejero”. Dicho de
otro modo, si una misma dirección aparece varias veces tendremos varias instancias
idénticas representando a la misma dirección (tal como pasa con los atributos de una clase).
Un atributo puede definirse como una simplificación notacional de la opción B1. La opción B2 no
representa exactamente lo mismo pero en la práctica sí puede significar lo mismo. En este caso la
información no se repite. Si se transforma en atributo entonces sí que se repetiría pero la semántica
del modelo no variaría. Por lo tanto se puede aceptar la equivalencia semántica.
o
o
Un ejemplo de lo mencionado anteriormente se da en los String de Java. Si dos cadenas
iguales en Java entonces tienen un mismo hashCode en cuyo caso son el mismo objeto por
lo que no se duplica la información en memoria. Este mecanismo de detección de cadenas
iguales en memoria lo realiza la máquina virtual automáticamente.
Es por ello que las cadenas en Java son inmutables (no se pueden modificar).
- 5/8 -
Assignatura 2008-2009
5.- Clase asociativa explícita Clase asociativa implícita
Opción A:
+ Varias restricciones de integridad:
• Clave externa de Factura: num-factura
• Clave externa de LineaFactura: num-linea
• num-linea empieza por 1 y con el resto son correlativos
Opción B:
+ Varias restricciones de integridad:
• Clave externa de Factura: num-factura
• Clave externa de LineaFactura: no tiene (está asociada a Factura)
• num-linea empieza por 1 y con el resto son correlativos
• num-linea no se puede repetir para una factura determinada
Comentarios:
•
•
•
•
•
Diremos que en la opción A LineaDetalleFactura es una clase asociativa explícita y en la opción B
LineaDetalleFactura es una clase asociativa implícita. Las clases asociativas no tienen clave externa.
La opción B se puede obtener a partir de la opción A aplicando la transformación 3 (Binaria *..* a dos
binarias 1..*) y luego poniendo num-linea como un atributo de LineaDetalleFactura
En la opción A el concepto línea de factura tiene identidad. El concepto línea 1 se instancia una sola vez y
mediante la clase asociativa se establecen los atributos de cada línea de Factura. En la opción B el numlinea es un atributo más sin ningún tipo de identidad propia.
La Opción A utiliza mejor el lenguaje UML ya que necesita una restricción menos (no de clave), sin
embargo el gráfico de B es más simple y es muy frecuentemente utilizado. Entre las dos opciones
podríamos dar un empate técnico aunque la opción A es más purista.
La clase asociativa implícita corresponde a la entidad débil del modelo entidad-relación.
- 6/8 -
Assignatura 2008-2009
6.- Herencia Asociaciones 1 a 0..1
Opción A:
A
attr1
A2
A1
attr2
Opción B:
Comentarios:
•
•
•
•
En la opción A, A1 y A2 comparten el mismo OID. En la opción B los OID de A, A1 y A2 son distintos.
Sin embargo las multiplicidades 1 a 0..1 posibilitan la biyectividad y garantizan la inyectividad de las
asociaciones por lo que se pueden definir reglas que ofrezcan equivalencia semántica
Una restricción del tipo Disjoint se traducirá en una regla como “Una instancia de A no puede asociarse
con una de A1 y A2 simultáneamente”.
Un atributo como attr1 podría ser el nombre de la partición.
- 7/8 -
Assignatura 2008-2009
Anexo: Comentario acerca del tratamiento de las fechas. Ejemplo de secuencia de transformaciones.
•
•
•
El concepto de fecha puede tener identidad en nuestro modelo conceptual de análisis pero éste puede
acabar siendo almacenado en formato YYYY-MM-DD en un campo de tipo Date (o texto) de una
tabla. De ser así el objeto fecha YYYY-MM-DD no tiene identidad y por tanto la misma información
se repetirá tantas veces como veces aparezca la misma fecha. En una base de datos Date es un tipo de
datos reconocido de forma nativa.
Si quisiéramos que las fechas tuvieran identidad habría que crear una tabla de días. Uno de sus
campos podría ser el nombre del día de la semana. Si no se hace es porque hay la alternativa de
calcularlo cada vez a partir de YYYY-MM-DD.
A continuación se muestra una transformación habitual en la que una fecha forma inicialmente parte
de una ternaria i finalmente pasa a ser un atributo. La secuencia de transformaciones aplicada es 2 y
4bis.
*
+ Restricción:
• Una misma pareja de instancias A, B no puede asociarse con varias instancias de AB con la misma fecha
Nota: AB no tiene clave externa
Xavier Pi (2008) – [email protected]
- 8/8 -