Un estudio comparativo de la expresividad de relaciones entre

Un estudio comparativo de la expresividad
de relaciones entre clases en OO-Method y UML
Emilio Insfrán✝, Vicente Pelechano✝, Jaime Gómez✝✝, Oscar Pastor✝
✝
Departament de Sistemes Informàtics i Computació
Universitat Politècnica de València
Camí de Vera, S/N, 46071 València
Tel: 96-3877350; Fax: 96-3877359
✝✝
Departamento de Lenguajes y Sistemas Informáticos
Universidad de Alicante
Carretera San Vicente s/n
03690 San Vicente del Raspeig - Alicante - España
jaime@dlsi.ua.es
Resumen
En la fase de modelización conceptual, y desde el punto de vista estructural, un
problema importante con el que un analista se encuentra es el determinar correctamente las
relaciones existentes entre las diferentes clases que ha identificado para el sistema en
desarrollo. Una vez superado el problema epistemológico de que si una clase está asociada o
está compuesta de otra clase, el problema que surge es definir precisamente qué quiere decir
estar asociado con y los matices que se puedan definir para esa asociación. En este trabajo
presentamos una comparativa de las expresividades para describir las relaciones existentes
entre clases en OO-Method, como método basado en un modelo formal que subyace a
modelos gráficos convencionales, y en UML, recientemente adoptado como estándar
notacional para la modelización de sistemas. No se trata de una mera comparación de las
relaciones entre clases entre dos propuestas OO, porque OO-Method es un método original
de producción de software cuya notación pretende ser compatible con la propuesta por UML.
Este trabajo fija las bases para que pueda ser visto así, detectando las diferencias para abordar
su integración.
1. Introducción
La mayoría de los métodos y notaciones orientados a objetos para el desarrollo de
aplicaciones (OMT [Rum91], Booch [Boo94], UML[BRJ97]), tienen muy poco rigor y se
definen en base a la experiencia acumulada antes que empleando técnicas formales para la
especificación de los elementos que se utilizan en el modelado de los sistemas de
información. Aun así, mucha gente los utiliza y los considera útiles.
El metamodelado es una técnica para modelar modelos. En este contexto, los
metamodelos ayudan a aumentar el rigor de los métodos sin sacrificar su utilidad, y aunque
probablemente sean los diseñadores e implementadores de herramientas CASE los que más
utilicen esta técnica, también es muy útil para que los analistas puedan conocer mejor el
modelo subyacente a la técnica de modelado que utilizan. Esto ayuda al analista a medir la
potencia expresiva de la técnica de modelado utilizada, a detectar ambigüedades y a
compararla con otras técnicas.
UML es el sucesor de técnicas de Análisis y Diseño OO que aparecieron a finales de
los años ‘80 y los ’90, y es presentado como la unificación directa de los métodos de Booch,
Rumbaugh (OMT) y Jacobson. UML ha sido aprobado por el Object Management Group
(OMG) como estándar notacional para el modelado conceptual orientado a objetos. En su
estado actual está constituido por una notación y un metamodelo [BRJ97], que aunque no se
encuentra totalmente definido, se centra principalmente en describir aspectos gráficos.
Este trabajo ha sido parcialmente financiado por la “Comisión Interministerial de Ciencia y Tecnología”
(CICYT) a través del proyecto con referencia TIC 97-0593-C05-01.
OO-Method [Pas96, Pas97-2] es una metodología de producción automática de
software basada en OASIS [Pas97-1], un lenguaje de especificación formal y orientado a
objetos, y en el uso de modelos gráficos similares a los empleados por metodologías
convencionales (OMT, Booch...). Esta propuesta proporciona un marco formal bien definido
que nos permite construir modelos conceptuales de gran expresividad y desarrollar
aplicaciones robustas, aprovechando las buenas propiedades de ambas aproximaciones
(formales y convencionales). En OO-Method, la información recogida del sistema de
información, durante la fase de modelado conceptual, se realiza por medio de una serie de
modelos gráficos que están orientados a completar una especificación formal en OASIS, pero
ocultando los aspectos sintácticos que requiere una especificación de esta naturaleza1.
En este artículo se presenta un estudio comparativo de la expresividad de las
relaciones entre clases de UML y OO-Method. La comparativa se realiza además utilizando la
técnica del metamodelado para presentar con más rigor los conceptos que se analizan. El
artículo está estructurado de la siguiente forma: en primer lugar se presentan los tipos de
relaciones entre clases de OO-Method y sus características esenciales, basándonos en el
metamodelo de OO-Method [PIP98]; en el siguiente punto se presentan las características
esenciales de las relaciones entre clases de UML con su respectivo metamodelo. En la cuarta
sección se realiza un estudio comparativo, a nivel de las relaciones entre clases, resaltando las
características comunes de ambas técnicas, explicando cómo se pueden representar ciertos
conceptos que no se representan directamente en una u otra notación, y se hace un
planteamiento crítico de las características que se consideran ambiguas, poco expresivas o
redundantes. Para terminar se propondrán líneas de trabajo futuro para construir un método
OO-Method UML “compliant” más potente y expresiva.
2. Relaciones entre clases en OO-Method
Una de las aportaciones interesantes de la simbiosis OO-Method/OASIS es la
semántica sumamente expresiva de los modelos gráficos utilizados, y en particular a las
relaciones entre clases. A continuación, vamos a presentar, apoyándonos en el metamodelo
OO-Method con notación UML, las características esenciales de estas relaciones.
Las relaciones estructurales
entre clases pueden ser de
agregación (parte-de), y de
herencia (es-un). En OO-Method
otro tipo de relación es la de
agentes, que no es una relación
estructural, pero que posee una
semántica muy interesante por
representar el aspecto cliente /
servidor de los objetos del sistema.
En OO-Method llamamos
clases complejas a aquellas que se
construyen a partir de otras
Figura 1. Relaciones entre clases en OO-Method
mediante relaciones de agregación
y/o herencia. Una caracterización del concepto de clase compleja a través del metamodelo de
la Figura 1 es: una clase es compleja si tiene al menos una relación estructural con otras clases
1
Los modelos gráficos de OO-Method son vistos como una una abstracción sobre los aspectos formales
del modelo de objetos subyacente utilizando notaciones convencionales.
2
(o consigo misma en el caso de agregaciones recursivas), en caso contrario se trata de una
clase elemental. Ese tiene se representa en la Figura 1 como el rol relacion_cons de la
agregación se construye, tomando como origen clase y como destino relación.
Tipo=count(relacion_cons) denota el número de relaciones definidas para una clase dada. Por
eso, si es mayor que cero la clase es compleja. Además, cualquier clase OO-Method
(compleja o elemental) puede participar en diversas relaciones como clase base de una
especialización o generalización, o como clase componente de una agregación.
También es importante señalar que la especificación de una clase en OO-Method no
acaba indicando atributos, servicios y relaciones entre clases, sino que se tiene una plantilla de
definición de clases [Pas97-1] que recoge información sobre restricciones de integridad,
actividad interna, ciclos de vida, interacción, etc.
2.1. Agregación
Desde las primeras propuestas de Modelado Semántico de Datos hasta los más
modernos lenguajes de especificación OO, la definición de agregación varía en función de los
criterios tenidos en cuenta a la hora de fijar el significado de ‘poner juntos’ objetos en un
objeto compuesto. En OO-Method la agregación puede verse desde varios puntos de vista,
dependiendo de qué características del objeto componente se consideren relevantes con
respecto al objeto compuesto, por lo que caracterizamos los diferentes tipos de agregación de
acuerdo con las siguientes dimensiones:
1. Disjunta o no disjunta: ¿puede un objeto componente de un objeto compuesto ser
compartido por varios objetos compuestos (por diferentes instancias de la misma clase
agregada)? Dependiendo si la respuesta es positiva o negativa hablaremos de agregación
no disjunta o disjunta respectivamente.
2. Flexible o estricta: ¿puede un objeto componente existir sin pertenecer a ninguna
agregación? o ¿la existencia de un objeto componente se entiende sólo como
componente de un objeto compuesto? En el primer caso, tenemos una agregación
flexible; en el segundo, una estricta.
3. Univaluada o multivaluada: dependiendo del número de objetos componentes
asociados a un objeto compuesto dado, distinguiremos entre agregación univaluada
(sólo uno) y multivaluada (tantos como se especifique).
4. Null o Not Null: si el objeto compuesto puede no tener componente en un momento
dado, tenemos una agregación que permite valores nulos (null); si no, tenemos una que
no los permite (not null).
5. Estática o Dinámica: ¿tiene la agregación una composición fija una vez ha sido creada
o, por otra parte, su composición cambia con el tiempo debido a la ocurrencia de
servicios de inserción y borrado para añadir y eliminar componentes?. En el primer
caso, estamos hablando de una agregación estática y en el segundo, la agregación es
dinámica. Un caso particular de agregación dinámica es la asociación (se le suele
llamar clase derivada en otros métodos) que se utiliza para manipular colecciones de
objetos como una nueva clase agregada, y posee una propiedad importante:
•
la posibilidad de definir una condición de "agrupación" (group_by) y una
condición de "selección" (where) que deben cumplir los objetos de esta clase.
6. Inclusiva o Relacional: dependiendo del tipo de ligadura o relación entre compuesto y
componente distinguiremos entre agregación inclusiva y relacional o referencial.
3
•
La agregación inclusiva es aquella que verifica que sus componentes no pueden
existir fuera del objeto compuesto. Su principal característica es que cualquier
objeto componente está completamente encapsulado en la agregación, en el sentido
de que su estado sólo puede ser alterado por eventos locales, adecuadamente
coordinados con los eventos proporcionados por la interfaz de la agregación. En
consecuencia, si tenemos una agregación inclusiva, los objetos componentes sólo
podrán ser accedidos a través del objeto compuesto.
•
La agregación relacional difiere de la inclusiva por el hecho de que sólo
denotamos una relación entre los objetos de las clases participantes, sin tener una
inclusión completa de los objetos componentes en el objeto compuesto. Los
objetos componentes no están encapsulados en el objeto compuesto y su
comportamiento es independiente del comportamiento del padre.
Además de las categorías anteriores, en OO-Method se le puede asociar un nombre a
la relación de agregación y se puede especificar el papel o rol que juega una clase agregada
y/o una clase componente en la agregación. Cada uno de los roles con los que participa una
clase en las relaciones de agregación poseen una cardinalidad mínima y máxima. La cuatro
primeras dimensiones presentadas las podremos obtener de automáticamente a partir de dicha
cardinalidad.
•
De componente a compuesto:
Máx.: N → no disjunta / 1 → disjunta
Mín.: 1 → estricta/ 0 → flexible
•
De compuesto a componente:
Máx.: N → multivaluada / 1→ univaluada
Mín.a: → 1 not null / 0 → null.
También se puede especificar si
una
clase
componente
tiene
dependencia de identificación de la
compuesta o viceversa, es decir, si el
identificador de la componente se
construye utilizando el identificador de
la compuesta o viceversa. Por ejemplo
en el caso de las clases provincia y
ciudad, teniendo ciudad dependencia de
identificación
de
provincia,
la
Figura 2. Agregación en OO-Method
identificación de la ciudad estaría
compuesta por la identificación de la provincia relacionada más el identificador propio de la
ciudad.
2.2. Herencia
Las relaciones de herencia en OO-Method son la especialización y generalización.
• especialización, para tratar la herencia descendente o derivación de clases hijas a partir
de una clase padre.
• generalización, que es la inversa a la anterior y se utiliza para tratar la herencia
ascendente o generación de clases (padre) a partir de propiedades comunes de clases
definidas (hijas) con anterioridad.
La especialización a su vez puede ser temporal o permanente:
4
• temporal o rol: un objeto ‘jugará
el papel’ correspondiente a la
clase especializada cuando ocurra
un evento de creación del rol o
portador (que se definirá en la
signatura de eventos de la clase
padre) o cuando se cumpla una
condición de especialización
sobre atributos variables de la
clase padre. El objeto dejará el rol
cuando
ocurra
un
evento
liberador o deje de cumplirse la
condición de especialización.
Cuando un objeto deja de
desempeñar el rol, el objeto sigue
su vida de acuerdo con el
comportamiento definido para la
clase padre.
• permanente o universal: cuando
Figura 3. Jerarquía de Herencia
un objeto pertenece a una clase
especializada desde el momento mismo de su creación, debido a que se cumple una
condición de especialización sobre atributos constantes de la clase padre. Esta
condición de especialización se especificará de forma obligatoria. Es importante resaltar
que el objeto será durante toda su existencia miembro de la clase especializada y de la
superclase.
La generalización puede ser disjunta si una instancia de una clase generalizada es una
instancia de una y sólo una de las clases descendientes, o no-disjunta en caso contrario.
2.3. Agentes
Por último nos quedan las relaciones de agente, que aunque no son relaciones
structurales, tienen una importancia relevante
en OO-Method para la especificación
completa de la relación entre clases del
sistema.
Un objeto en su visión general puede
verse como una cápsula con estados y
servicios que ofrece a la sociedad de objetos,
esta es su faceta servidora. En una visión
complementaria un objeto también puede ser
cliente de los servicios ofrecidos por otros
objetos del sistema. En OO-Method esta
relación cliente/servidor es la relación de
agentes.
Figura 4.. Las relaciones de agente
5
3. Relaciones entre clases en UML
En UML el diagrama de clases describe los tipos de objetos en el sistema modelado y
los distintos tipos de relaciones estáticas entre ellos. Básicamente se distinguen dos tipos de
relaciones estáticas: asociaciones y generalizaciones.
3.1. Asociación
Las asociaciones representan relaciones entre instancias de clases. Cada asociación
tiene dos roles. Cada rol es una dirección en la relación: si C1 – está-asociado-con – C2, la
relación de C1 con C2 tiene un rol de C1 a C2 y otro de C2 a C1.
Los roles poseen un nombre (si no se indica un nombre de rol, el nombre del rol es el
nombre de la clase destino). Además un rol tiene una mutiplicidad que indica cuántos objetos
pueden participar en una relación dada (límite inferior y límite superior). Cuando el límite
superior es mayor a 1, se conoce como rol multivaluado. La convención usual es que este rol
multivaluado sea un conjunto, aunque puede aplicarse la restricción {ordered} para
considerarlo una lista (sin repeticiones), o {bag} o {ordered bag}.
Otra restricción que se puede
asociar a los roles es {frozen} y sirve
para indicar que el valor de un rol no
puede cambiar durante su tiempo de
vida (no pueden añadirse, borrarse o
modificarse enlaces entre objetos) y
{addOnly} permite que solamente se
puedan agregar nuevos enlaces entre
objetos de las clases involucradas.
Otra
propiedad
de
las
asociaciones permite especificar la
navegabilidad de la relación. La
navegabilidad indica que los objetos
de la clase podrán hacer uso de las
propiedades de los objetos de la clase
relacionada en la dirección indicada
por la navegabilidad exclusivamente.
Si la navegabilidad existe sólo en un
sentido se llama asociación unidireccional, y si existe en los dos
Figura 5. Relaciones entre clases en UML
sentidos asociación bi-direccional. La
asociación sin navegabilidad puede considerarse como bi-direccional o no-especificada. La
asociación bidireccional añade la restricción de que los dos roles son invertibles uno con otro.
Dos casos particulares de la asociación son: agregación y composición.
La agregación es la relación parte-de, que expresa un acoplamiento más fuerte entre
clases. Una de las clases actúa como compuesta y la otra como componente y por defecto
representa una relación transitiva, asimétrica y reflexiva. Este concepto de agregación es una
noción puramente lógica, completamente independiente de las opciones de representación
adoptadas.
La composición es una forma más fuerte de agregación. En la composición, el objeto
parte puede pertenecer sólo a un todo y no puede ser cambiado (cualquier borrado del todo se
6
considera un borrado en cascada de sus partes, aunque esta restricción también puede
expresarse mediante un rol con mutiplicidad 1:1).
Las asociaciones derivadas son aquellas que se calculan a partir de otras asociaciones.
Las asociaciones cualificadas, se construyen mediante un calificador que está
constituido por un atributo o conjunto de atributos cuyos valores sirven para particionar el
conjunto de objetos asociados con un objeto a través de la asociación. La asociación-or es en
realidad una restricción sobre dos o más asociaciones para especificar que un objeto de una
clase asociada con otras sólo puede participar como mucho en una de las asociaciones en las
que participa.
Las clases de asociación permiten añadir propiedades (atributos, operaciones, ...) a
asociaciones. Asociación n-aria, es una asociación entre 3 o más clases y donde cada
instancia de la asociación es una tupla de n valores de las respectivas clases. En este caso, no
puede ser agregación ni composición.
3.2. Generalización
Es la relación taxonómica entre una clase más general y otra más específica que es
totalmente consistente con la primera y que le añade información.
Una clase puede especializarse según ciertos criterios. Cada criterio de la
generalización se indica asociando un discriminador a la relación de generalización. Dicho
discriminador es el nombre de una partición de los subtipos de la superclase. Este
discriminador puede ser un atributo de la clase generalizada o el nombre de la partición. La
generalización puede aplicarse a clases o a asociaciones (aunque en este último caso es
preferible representar la asociación como una clase de asociación).
Pueden aplicarse diferentes restricciones a las relaciones de generalización para
distinguir diversas formas de generalización, en principio por defecto la generalización
simboliza una descomposición disjunta.
La restricción {disjoint} indica que las subclases descendientes de una clase A no
pueden especializarse en una subclase común (no puede existir una subclase obtenida a partir
de herencia múltiple de las subclases de A ya que estas son disjuntas entre sí).
La restricción {overlapping} indica que una subclase descendiente de las subclases de
una clase A puede heredar de más de una de las subclases de A (es lo opuesto a disjoint).
La restricción {complete} indica que la generalización está terminada y no es posible
añadir subclase; inversamente, la restricción {incomplete} designa una generalización
extensible.
Pueden representarse grupos de generalizaciones semánticamente relacionados como
árboles con un segmento compartido. Si se añade una etiqueta a este segmento compartido
(como nombre de la partición) se aplica a todo el grupo de generalización.
3.3. Dependencia y refinamiento
Además de las relaciones estructurales que hemos comentado, en UML existen dos tipos
más de relaciones: la dependencia y el refinamiento.
La relación de dependencia es una conexión semántica entre dos elementos del modelo,
uno dependiente y otro independiente. Particularmente respecto a las relaciones entre clases,
indica que la clase dependiente utiliza métodos o propiedades de la clase independiente.
Mediante la utilización de estereotipos se definen los tipos de dependencias. UML usa el
7
concepto de estereotipo como un mecanismo general de extensión del modelo,
particularizando determinados aspectos que quedan recogidos en el estereotipo introducido, y
que a partir de ese momento se convierten en un componente más del modelo.
Una relación de refinamiento es una relación entre dos descripciones de una misma cosa
pero a diferente nivel de abstracción, por ejemplo entre clases cuando se construyen modelos
de análisis y estos se refinan en modelos de diseño, en estas situaciones es interesante enlazar
las clases de análisis con sus correspondientes clases en el diseño.
4. OO-Method vs. UML. Un estudio comparativo a nivel de
relaciones entre clases
En esta sección describiremos qué características comunes y diferencias se encuentran
entre UML y OO-Method referentes a la semántica de las relaciones entre clases.
4.1. Características similares
4.1.1. Asociación - Agregación
En UML una asociación es una conexión entre dos o más objetos. Dependiendo de la
semántica asociada a dicha conexión, puede clasificarse nuevamente en: asociación (en el
caso general), agregación (caso específico de la relación parte-de de los modelos semánticos)
y composición (una agregación donde la relación existente entre los objetos involucrados es
más fuerte).
En el caso de OO-Method esta relación entre objetos es llamada en general
agregación. Se definen dos dimensiones principales que determinan el grado de interrelación
entre los objetos involucrados: referencial (el objeto compuesto está asociado con el objeto
componente, y la vida de los objetos participantes son independientes entre sí) e inclusiva (el
objeto compuesto encapsula y está compuesto por el objeto componente).
La composición de UML se corresponde directamente en OO-Method con la
agregación inclusiva con las propiedades de disjunta y estricta (cardinalidad de componente a
compuesto 1:1).
La clase de asociación de UML se corresponde en OO-Method con una clase
compleja por agregación relacional teniendo por componentes las dos clases asociadas por la
relación de asociación en el modelo UML.
Una asociación n-aria de UML es en OO-Method una nueva clase compleja por
agregación relacional, teniendo por componentes las clases que participan en la asociación naria. Si la relación n-aria tuviese una clase de asociación relacionada, en este caso no existe
en OO-Method la nueva clase compleja y es esta misma clase de asociación la que tiene
como componentes a los integrantes de la relación n-aria.
La navegabilidad en asociaciones UML puede ser unidireccional o bidireccional. Si no
se especifica explícitamente puede considerarse que es aun desconocida o bidireccional. En
OO-Method la navegabilidad en la agregación es bidireccional.
En la Tabla 4.1 se muestran las correspondencias respectivas de las dos
aproximaciones comparadas.
8
Otro aspecto a resaltar en UML es la posibilidad de definir reglas (usualmente en
OCL2) que describen restricciones sobre la semántica de ciertos elementos del modelo, en
particular en la Tabla 4.2 se muestran algunas de estas reglas predefinidas para la asociación.
y su correspondencia en OO-Method.
UML
Asociación
Agregación
Composición
Multiplicidad
Rol
Clase de asociación
Asociación n-aria
Navegabilidad
(unidireccional o bidireccional)
OO-Method
Agregación Relacional
Agregación Inclusiva
Agregación inclusiva, disjunta y
estricta
Cardinalidad
Rol de Agregación
Clase compleja por Agregación
Relacional
Clase compleja por Agregación
Relacional
Bidireccional
Tabla 1
Las restricciones {ordered3, bag4, ...} y otras de este tipo, son restricciones sobre el
almacenamiento y manipulación de la población de objetos relacionados. En OO-Method
estas restricciones se especifican mediante propiedades de la propia agregación {list, stack,
...}que hacen referencia a la forma en que se almacenan los componentes, y dependiendo del
tipo de almacenamiento elegido se dispone de los operadores correspondientes para su
manipulación.
Las restricciones {or} y {subset} de UML para asociaciones excluyentes y
asociaciones que deben ser un subconjunto de otra, respectivamente, en OO-Method se
pueden especificar como una restricciones de integridad estáticas (en la plantilla de definición
de clases) sobre la población de los objetos que participan en la relación.
La restricción frozen de UML se corresponde con la propiedad estática de la
agregación en OO-Method, y la restricción addOnly se corresponde a la agregación dinámica
cuando sólo se han especificado servicios de inserción.
Restricciones UML
{ordered}
{bag}
{or}
{subset}
{frozen}
{addOnly}
OO-Method
Propiedad de la agregación
Propiedad de la agregación
Restricción estática
Restricción estática
Agregación estática
Agregación Dinámica
(sólo servicios de inserción)
Tabla 2
2
OCL es el acrónimo de Object Constraint Language.
3
Orderered (ordenado), indica que el conjunto de objetos relacionados se conservan un cierto orden de
acuerdo a un criterio específico (mayor a menor, tiempo de inserción en la relación, etc).
4
Bag (bolsa) indica que pueden incluirse objetos relacionados duplicados.
9
4.1.2. Herencia - Generalización.
UML utiliza un único concepto (generalización) para tratar la herencia en forma
amplia como la relación entre una clase más general y otra más específica. En OO-Method se
categoriza la herencia de acuerdo a su naturaleza, y puede ser la herencia descendente o
especialización o la herencia ascendente o generalización.
La especialización en OO-Method se distingue nuevamente en dos tipos: la
permanente y la temporal. En UML (versión 1.1) no se distingue explícitamente esta
clasificación, se entiende en general permanente5. Siempre existe la posibilidad de definir un
estereotipo para dar cuenta de ese tipo de especialización, pero no se trata de un concepto
claramente definido en la semántica básica de la herencia en UML.
La falta de precisión asociada a la semántica de UML con respecto a la generalización
impide en cierto modo poder realizar una correspondencia clara entre conceptos UML y OOMethod, por lo que nos restringiremos a mostrar ciertas equivalencias.
Dada una relación de generalización entre dos clases6 en UML, el discriminador
proporciona un criterio para particionar los subtipos (subclases) de la superclase. Este
discriminador puede ser un atributo de la clase generalizada o el nombre de la partición; en
OO-Method se pueden definir particiones mediante condiciones de especialización sobre
atributos de la superclase. Si esta condición de especialización se establece únicamente sobre
atributos constantes de la superclase se refiere a una especialización permanente, y en caso
contrario se refiere a una especialización temporal.
En principio, la generalización en UML simboliza una descomposición disjunta
[Mull97], aunque con restricciones es posible indicar exactamente el tipo de descomposición
deseada.
La restricción {disjoint} aplicada a la generalización de UML establece que dado un
conjunto de subclases de una superclase A, una instancia de la superclase A sólo puede
especializarse en una (y sólo una) de las subclases de A. En OO-Method esta propiedad se
representa dependiendo del tipo de herencia deseado. Si se trata de una herencia ascendente se
especificará como una generalización disjunta; y si se trata de una herencia descendente se
puede especificar como especializaciones (entre la superclase y cada una de las subclases)
asegurando que las condiciones de especialización sean mutuamente excluyentes entre las
subclases de participantes.
La restricción {overlapping} sobre la generalización es conceptualmente opuesta a la
restricción {disjoint} en UML. En OO-Method, su representación será la generalización no
disjunta (si se trata de una herencia ascendente) o condiciones de especialización no disjuntas
entre sí (si se trata de una herencia descendente).
Las dos restricciones previas {overlapping} y {disjoint} tienen una equivalencia con la
especialización temporal por evento de OO-Method, y deben ser especificadas a nivel del
comportamiento de la superclase definiendo las secuencias válidas de eventos que aseguren la
existencia o no de instancias de las subclases definidas.
5 UML trata la semántica asociada a la generalización muy superficialmente, por ejemplo qué
propiedades se heredan y cómo, qué puede sobreescribirse, ...
6
En UML también es posible definir un árbol de generalización (para herencia simple) para un conjunto
de subclases, en este caso es común que el discriminador de especialización sea común para todas las particiones
definidas.
10
4.2. Diferencias entre UML y OO-Method
En este apartado se muestran las diferencias de expresividad encontradas entre UML y
OO-Method para la especificación de relaciones entre clases.
Como se verá a continuación algunos aspectos presentes en la expresividad de los
diagramas de UML no se encuentran explícitamente en OO-Method, aunque éstos en general
representan información orientada más bien a aspectos de diseño físico o implementación que
a nociones de modelado.
4.2.1. Asociación - Agregación
La asociación calificada en UML es una asociación con un calificador. El calificador
está definido por un conjunto de atributos que pertenecen a la asociación (estos atributos no
pertenecen a la signatura de ninguna de las dos clases que participan en la asociación) y se
encuentra en un extremo de la asociación binaria. Esta asociación calificada se utiliza para
seleccionar exactamente una partición del conjunto de objetos asociados en el otro extremo de
la asociación. En OO-Method esta propiedad de la asociación no tiene una correspondencia
directa, aunque una representación conceptualmente equivalente puede especificarse mediante
una nueva clase que agregue ambas clases asociadas y que tendrá como identificación para
sus instancias, la identificación de la clase en el extremo origen de la asociación calificada
más los atributos del calificador.
Las asociaciones derivadas de UML representan información sobre relaciones ya
existentes en el modelo, se muestran sólo a efectos expresivos; en el modelo subyacente a
OO-Method esta información está disponible aunque no tiene representación gráfica.
La expresividad de la relación de agregación dinámica en OO-Method es una
diferencia importante respecto a UML ya que no solamente indica que los componentes del
objeto compuesto pueden cambiar sino también cómo. Para ello es posible definir eventos de
inserción y borrado que realizan esta tarea. Estos eventos de inserción y borrado van a ser
eventos compartidos7 entre el componente y el compuesto.
Las agregaciones multivaluadas en OO-Method tienen una propiedad interesante, que
es la posibilidad de utilizar operadores de manejo de colecciones desde el objeto compuesto
sobre el conjunto de objetos componentes, por ejemplo: count, sum,.... En OO-Method un
caso particular de agregación dinámica y mutivaluada es la asociación (también llamada
agrupación) se utiliza para el manejo de colecciones de objetos como una nueva clase
compleja agregada cuyas instancias se construirán a partir de todas aquellas instancias de la
componente que cumplan una condición definida sobre la población de la clase componente.
4.2.2. Herencia - Generalización.
En OO-Method se distingue entre generalización y especialización y, aunque estos
sean dos puntos de vista antagónicos del concepto de clasificación, expresan en qué sentido se
utiliza una jerarquía de herencia y es útil a nivel de modelado conceptual.
La especialización temporal es una forma de especialización no contemplada
explícitamente en UML. En OO-Method está tratada profundamente por considerarse muy
útil en el modelado de sistemas de información. Como característica relevante está la
posibilidad de declarar un conjunto de propiedades en una subclase que un objeto de la
7
Los eventos de inserción y borrado son eventos compartidos entre el compuesto y el componente
porque, por ejemplo, cuando el objeto compuesto inserta un componente, el objeto componente es insertado
(afecta el estado de ambos objetos en el mismo instante de tiempo).
11
superclase en un instante determinado puede adquirir como resultado de satisfacer una
condición de especialización o por la ocurrencia de un evento portador. El objeto se dice que
cumple un rol mientras la condición se mantenga o hasta que ocurra un evento liberador,
entonces deja el rol y se comporta nuevamente de acuerdo a lo especificado en la clase padre.
Una propiedad interesante está asociada con la semántica de la compatibilidad entre la
superclase y la subclase. La subclase debe tener compatibilidad de signatura [Pas97-1], a
diferencia de la herencia permanente que debe respetar la compatibilidad de comportamiento.
Para la relación de generalización en UML se definen dos restricciones sobre la
construcción del modelo como notas para el analista y son: {complete} y {incomplete}. La
restricción complete se refiere a que la jerarquía de generalización está completamente
definida a este nivel y no se espera definir nuevas subclases en un futuro. La restricción
incomplete indica que pueden definirse más subclases. En OO-Method este tipo de notas no
forman parte del modelo y no se expresan.
Una diferencia importante ente UML y OO-Method es la posibilidad en UML de tratar
grupos de particiones en los casos de subclasificación múltiple. Esto es útil para expresar
ciertas restricciones sobre grupos de particiones, por ejemplo {disjoint} o {overlapping}.
5. Conclusiones
En este trabajo hemos presentado una comparación de expresividades para las
relaciones entre clases de OO-Method y UML. Una crítica generalizada a UML es su
genericidad y falta de semántica precisa para muchos aspectos que hemos presentado, y todo
esto por su orientación a ser un estándar notacional para la modelización de cualquier tipo de
sistema orientado a objetos. Sin embargo esto tiene su lado provechoso, puede ser adoptado
con cierta facilidad a modelos suficientemente formales y semánticamente ricos. Este es el
caso de OO-Method que tiene su propia notación gráfica. Una línea de trabajo de nuestro
grupo de investigación es la adopción de esta notación estándar para la construcción de
modelos conceptuales, basados en el modelo de objetos OASIS, en el mismo marco nuestro
método OO-Method.
6. Bibliografía
[Boo94] Booch G. OO Analysis and Design with Applications. Addison-Wesley, 1994.
[BRJ97] Booch G., Rumbaugh J., Jacobson I. UML. v1.1 Rational Software Co., 1997.
[Jac92] Jacobson I., Christerson M., Jonsson P., Overgaard G. OO Software Engineering , A Use Case Driven
Approach. Reading, Massachusetts. Addison –Wesley, 1992.
[Let96] Letelier, P.; Ramos, I. Un MetaModelo Estático para Especificaciones OASIS y su Implementación en
una Base de Datos Relacional, DSIC-II/19/96, Universidad Politécnica de Valencia, 1996.
[Pas96] Pastor O., Pelechano V., Bonet B., Ramos I. OO-Method 2.0 : una metodología de Análisis y Diseño
Orientada a Objetos. Informe técnico, DSIC-UPV, 1996.
[Pas97-1] Pastor, O.; Ramos, I. Oasis 2.2: A Class-Definition Language to Model Information Systems Using an
Object-Oriented Approach, SPUPV-95.788, Universitat Politècnica de València. 1997.
[Pas97-2] Pastor, O.; Insfrán, E.; Pelechano, V.; Romero, J.; Merseguer, J. OO-METHOD: An OO Software
Production Environment Combining Conventional and Formal Methods. Conference on Advanced
Information Systems Engineering (CAiSE '97). Barcelona, Spain. June 1997.
[PIP98] Pelechano V., Insfrán E., Pastor O. El Metamodelo OO-Method y su Repositorio Relacional. Informe
técnico, DSIC-II/16/98-UPV, 1998.
[Rum91] Rumbaugh, J.; Blaha, M.; Permerlani, W.; Eddy, F.; Lorensen, W. Object Oriented Modeling and
Design. Englewood Cliffs, Nj. Prentice-Hall. 1991.
12