Computación y Sistemas Vol.3 No.3 pp. 202- 213

@ 2000, CIC -IPN. ISSN 1405-5546 Impreso en México

Extensiones al Sistema de Clasificación de UML

José A. Troyano, Manuel Mejías, Jesús Torres y Miguel Toro

Artículo recibido el7 de iulio. 1999: acevtado el2O de diciembre. 1999

1 IntroducciónResumen

Este trabajo plantea cómo extender las capacidades

taxonómicas del modelo UML (Unifled Modeling Language).Básicamente lo que proponemos es afinar un poco más lasemántica que propone UML al mecanismo denominado ge-neralización (ya su mecanismo inverso: la especialización).Inicialmente UML define la generalización como un meca-

nismo abstracto de ordenación de clases que permitejactorizar los elementos comunes de varias clases en una clasemás general, la superclase. Nuestro objetivo es ir un pocomás allá, vinculando esta jactorización a la idea de taxono-mía, de manera que las poblaciones (conjuntos de objetos)de las clases especializadas constituyan subconjuntos de la

población de la superclase.Para ello necesitamos dos cosas, en primer lugar lo que

denominaremos criterios de clasificación, que nos permiti-rán decidir qué objetos de la superclase cumplen las condi-ciones de cada especialización (sub clase). Dado que un ob-jeto de la superclase podrá cumplir los criterios de variassub clases tendremos que ser capaces de compaginar las dis-tintas características especificadas para cada clase, 1anto lasde la superclase como las de las sub clases a las que el objetopertenece. Esto es, precisamente, lo segundo que necesita-mos: un método de combinación de especificaciones.

En este trabajo nos ocuparemos de la primera de estas ne-cesidades, es decir, propondremos cómo se pueden especifI-car criterios de clasificación utilizando los elementos que pro-

porciona UML.

A la hora de comprender el mundo en el que existimos, la

clasificación se presenta como una herramienta cognoscitivaimprescindible. Podemos definir clasificación como la capa-

cidad de agrupar bajo un nombre o concepto todas aquellasentidades que presenten características comunes, precisamenteserá ese nombre o concepto lo que denominaremos clase (o

tipo ). La definición en sí es un poco vaga, pero resulta impo-sible ser del todo preciso hasta que no se acote claramentedentro de qué ámbito se encuentran las entidades que quere-

mos estudiar.Podemos clasificar de dos formas distintas, bien de manera

inductiva o deductiva (Parets, 1996):D En una clasificación inductiva partimos del conocimien-

to de las entidades ya través del estudio de sus propieda-des obtenemos las clases en las que se encuadran.

D En una clasificación deductiva partimos de las defini-ciones abstractas de las clases, de manera que el procesode clasificación es una evaluación de las propiedades delas entidades que determina a qué clase pertenece cadauna de ellas.

El problema de la clasificación está bastante ligado al tra-dicional problema filosófico de los Universales, esto es, laexistencia o no de las ideas generales frente a las entidades

particulares. El punto de vista inductivo se acerca a la aproxi-mación de Aristóteles, que creía imposible llegar a las ideasgenerales sin antes haber experimentado las entidades reales,por su parte el modelo deductivo se acerca al planteamientode Platón, que pensaba que los universales pueden ser alcan-zados simplemente con la razón y las entidades reales sóloson consecuencias de estas ideas generales.

Palabras clave:

Clasificación, generalización, taxonomía, orientación a bbjetos.

202

Departamento de Lenguajes y Sistemas Informáticos

Universidad de Sevilla (España)

e-mail:troyano@lsi.us.es

J. A. Troyano, M. Mejías, J. Torres y M. Toro: Extensiones al Sistema de Clasificación de UML

Supone, por tanto, un recorrido descendente del árboltaxonóinico.

Por tanto la relación entre la superclase y la sub clase puedeser de generalización o de especialización según sea el senti-do en el que se estudie. Precisamente por ello (y en ciertomodo abusando del significado de los términos) se suele uti-

lizar la palabra especialización para denotar a la sub clase y lapalabra generalización para denotar a la superclase.

Con esta introducción hemos pretendido presentar las ideasabstractas que han motivado la realización de este trabajo, elresto del artículo se dedica precisamente al estudio de cómoaplicarlas en el ámbito del modelado de sofware orientado aobjetos y más concretamente en el contexto de la notaciónUML (Rumbaugh el al., 1998). La organización del resto del

trabajo es la siguiente: la sección segunda estudia qué papeljuega el concepto de taxonomía en el proceso de desarrollode software, la sección tercera presenta la forma en la que enla notación UML se tratan estas ideas, la sección cuarta pre-

senta una serie de extensiones (entre las que destaca el con-cepto de criterio de clasificación) que permiten mejorar la

capacidad taxonómica de UML, en la sección quinta se mues-tran algunos criterios de clasificación alternativos al presen-tado en la sección cuarta, por último la sección sexta se dedi-

ca a extraer conclusiones ya plantear los trabajos futuros.

2 Papel de la Taxonomía en el Modeladode Software

A pesar de que el modelo aristotélico se presenta como unplanteamiento profundamente interesante de por sí, es poco

útil dentro del ámbito de la ingeniería de software, ya que enella las entidades no son reales, sino que son abstraccionesque en algunos casos ni siquiera tienen relación directa con

objetos reales.Por el contrario, el modelo platónico sí se presenta útil para

ser aplicado en el proceso de desarrollo de software. De he-

cho es la base de las metodologías orientadas a objetos; en lasetapas de análisis y diseño definimos las características de lasclases de objetos que compondrán el sistema y será, por Últi-mo, en el modelo de ejecución donde aparezcan los objetosconcretos creados según las características especificadas paralas clases.

Con la clasificación, y la consecuente idea de clase, tene-

mos ya una fomia de manejar la complejidad, tanto en elcampo del conocimiento humano, como en el del desarrollode software. Podemos decir en cierto modo, que estos con-ceptos constituyen una forma natural de ordenar el conoci-miento.

Pero aún se puede afinar más en el proceso de comprenderun sistema de la mano de un nuevo concepto: la taxonomía.Podemos definirla como la capacidad de establecer relacio-nes de inclusión entre clases, de manera que además de orde-nar las entidades dentro de clases, podremos ordenar las pro-

pias clases estableciendo que unas son más generales que otras.

Esto es lo que hacemos cuando pensamos en una clase gene-ral como Ser vivo y luego en otra un poco más concreta como

Vegetal. Denominaremos superclase a la clase más generaly sub clase a la más concreta.

Aunque hemos utilizado el término taxonomía para nom-brar a este nuevo concepto, muchas veces se suele utilizar

simplemente el término clasificación, englobando tanto elproceso de adscribir entidades a clases como el de ordenarlas clases según su grado de abstracción.

El resultado del proceso taxonómico se puede representar

gráficamente en forma de árbol1, que según sea recorrido dalugar a dos mecanismos de modelado:

D La generalización parte de la existencia de clases menosgenerales, ya partir de ellas define una clase más gene-ral que aglutina las características comunes a todas ellas.Supone, por tanto, un recorrido ascendente del árbol

taxonómico.D La especialización parte de la existencia de una clase más

general ya partir de ella define un conjunto de clases

más concretas que incluyen las características de la clasegeneral, además de ciertas características específicas.

Ya hemos visto la utilidad de la taxonomía como herramien-ta de apoyo en el proceso de conocimiento de un sistema,pero en un campo como el de la ingeniería del software depoco valen los conceptos generales si de ellos no se puedeobtener una aplicación útil. Para ello lo primero que tenemosque hacer es delimitar exactamente el campo de aplicación,cosa que por suerte se puede hacer en un ámbito tan concretocomo éste. Precisamente por esta concreción, la orientación aobjetos se presenta como un buen campo de ensayo donde

aplicar muchas ideas que a lo largo de la historia se han de-mostrado infructuosas en campos tan generales como la filo-sofía y la teoría del conocimiento, pero que pueden ayudarbastante cuando el objeto de estudio se concreta a aplicacio-

nes informáticas, que pese a ser abstractas y relativamentecomplejas, entran dentro de los límites de lo que puede com-prender un ser humano.

A pesar de que los objetos son los elementos principales enun modelo orientado a objetos, realmente este protagonismono se alcanza totalmente hasta el modelo de ejecución. Antesde eso debemos definir el modelo, y en ese proceso son lasclases las que juegan el papel principal, más concretamentelos aspectos de especificación de las mismas. En este sentido,

los conceptos de especialización y generalización (este últi-

I En algunas situaciones en lugar de árboles obtendremos cierto tipo de

grafo, pero a efecto introductorio nos basta con la representación arbórea

como primera aproximación.

203

J. A. Troyano, M. Mejías, J. Torres y M. Toro: Extensiones al Sistema de Clasificación de UML

mo en menor medida) alcanzan una nueva dimensión y pa-san a ser constructores sintácticos o mecanismos de especifi-

cación, al mismo nivel que los conceptos de clase, asocia-

ción, agregación, interacción, etc.La especialización es un mecanismo que partiendo de una

especificación de una superclase nos debe permitir obtener laespecificación de una sub clase. Para ello se deben indicar doscosas fundamentales:

I:J ¿ Qué condiciones deben cumplir los objetos de la

superclase para ser considerados objet9s de la sub clase?Esto es lo que denominaremos criterio de clasificación,

y es lo que asegura el carácter taxonómico del mecanis-mo.

I:J ¿ Qué propiedades deben tener los objetos de la sub clase ?

En este caso, y dado que estamos diseñando un mecanis-mo de especificación hemos de partir de la existencia deuna especificación para la superclase y de una serie de

características específicas de la sub clase. Cada una deestas especificaciones constituirá una serie de restriccio-nes estructurales y de comportamiento que deben cum-plir en conjunto los objetos de la sub clase. Este aspectoestá relacionado con el problema de la Conformidad de

comportamientos, estudiado entre otros en los trabajos(Saake et al., 1994; Nierstraz, 1995; Wieringa et al.,

1995).A la hora de pensar en un mecanismo de especificación

vinculado a la generalización, nos damos cuenta de que no

aparece de una forma tan natural como en la especialización.Un hipotético mecanismo debería partir de las especificacio-nes de varias subc1ases y extraer las características comunesa todas ellas. En realidad lo que haría este mecanismo seríaun proceso de síntesis de propiedades que va contra corrien-te a lo que se supone que hacemos cuando construimos un

modelo, que en definitIva es analizar. De alguna forma laespecialización está en el mismo sentido del modelo platÓni-

co de clasificación (deductivo) y es por ello que se puedeimaginar un mecanismo de especificación que sea útil en elproceso de modelado de software que a fin de cuentas tam-bién es deductivo. Ocurre justamente lo contrario con la ge-

neralización que se ajusta al modelo inductivo, lo'que haceantinatural su uso en un sistema donde las entidades (los ob-jetos) son las últimas en aparecer.

quía en la que podemos asociar propiedades abstractas a lasclases más generales y propiedades más concretas a las cla-ses más especializadas.

Pero además de esta capacidad de introducir informacióntaxonómica en el modelo, la especialización combinada conotros mecanismos como la asociación alcanza gran riqueza

expresiva permitiendo modelar ciertas situaciones de una for-ma compacta, elegante y conceptualmente clara. Por ejem-

plo si definimos una clase Persona y dos especializaciones

Estudiante y Trabajador, podemos aprovechar la división dela población de la clase persona que se establece con dichas

especializaciones para establecer relaciones entre unsubconjunto de los objetos de la clase Persona con otras cla-ses. Por ejemplo podemos establecer una asociación entre la

clase Trabajador y una nueva clase Empresa, en la que como

mínimo cada Trabajador está vinculado a una Empresa.Como se ve en la figura 1 (en la que utilizamos la notación

gráfica UML que presentaremos completamente en la sec-ción 3), la asociación entre Trabajador y Empresa tiene comorestricción de multiplicidad en el lado de la empresa 1..* lo

que significa que cada trabajador debe estar vinculado almenos a una empresa. Este detalle no podría haberse especi-ficado con tanta precisión si la asociación se estableciese en-tre las clases Persona y Empresa, ya que no todas las perso-nas son forzosamente trabajadores.

En realidad lo que estamos haciendo es aprovechar la se-

mántica propia del mecanismo de especialización para espe-cificar de una forma precisa ciertas propiedades, que de noser así deberían haberse descrito completando el modelo grá-

fico con información textual.Con ejemplos como éste es fácil ver que la especialización,

entendida como concepto y también como mecanismo

sintáctico, puede ser de gran ayuda a la.hora de comprenderun modelo orientado a objetos, pero ¿realmente se explotaesta ayuda? La respuesta es no del todo, y en las siguientes

secciones intentaremos explicar el porqué.

2.1 Integración en el Modelo de Objetos

El mecanismo de especialización por sí solo es suficiente-mente interesante ya que permite establecer una organiza-ción de los objetos más fina que la que se obtiene con el con-

cepto de clase. En cierto modo, si con las clases podemosponer orden entre los objetos, con la especialización pode-mos hacer lo mismo con las clases, estableciendó una jerar- Figura Especialización y asociación

204

J. A. Troyano, M. Mejías, J. Torres y M. Toro: Extensiones al Sistema de Clasificación de UML

2.2 No Esencialidad 3 El sistema de Clasificación de UML

El primer problema que se plantea con el mecanismo de es-pecializaciÓn, es que no es del todo esencial, es decir, se pue-de llegar a construir un modelo orientado a objetos sin utili-zarlo, aunque el problema que estemos modelando pida agritos !a ordenación de las clases utilizadas en un esquema

taxonómico. Por ejemplo, si queremos modelar una situación

en las que los objetos de una clase Persona puedan adoptarlas características de Estudiante y Trabajador e incluso delos dos a la vez, p-odemos representarlo de manera abstractahaciendo que Estudiante y Trabajador sean especializacio-nes de Persona, o simplemente podemos definir tantas clases

independientes como situaciones taxonómicas haya2.En este sentido son pocos los conceptos que se pueden con-

siderar esenciales en el modelo orientado a objetos, en reali-dad tan sólo los de clase, propiedad, objeto, e identificación,ya que el resto podrían ser representados de una manera máso menos abstracta sobre ellos. Por ejemplo, las asociaciones

pueden ser modeladas con atributos que mantengan la identi-

ficación de los objetos vinculados, y lo mismo ocurre con lasagregaciones. Quizá la razón del porqué estos mecanismos síestán claramente asentados y no lo está la especialización hayaque buscarla en la simpleza conceptual de los primeros, fren-

te a la complejidad de la especialización, sobre todo a la hora

de compaginar las características de comportamiento desuperclase y sub clase.

2.3 Falta de Consenso

En esta sección describiremos brevemente los aspectos quela notación UML dedica a la que hasta ahora hemos presen-tado con el nombre de generalización y especialización. A

grandes rasgos podríamos decir que UML no desarrolla conprofundidad estos conceptos y en la documentación que has-

ta ahora han publicado los creadores de la notación, práctica-mente tan sólo se tienen en cuenta los aspectos gráficos derepresentación y la idea abstracta de inclusión entre las po-blaciones de objetos de la superclase y la sub clase.

La relación taxonómica entre un elemento más general yotro elemento más específico, que es totalmente consistente

con el primero y al que añade información adicional, se con-sidera en UML mediante el concepto de generalización.

La generalización se muestra como un camino de línea só-lida desde el elemento más específico (sub clase) al elementomás general (superclase), con un triángulo hueco al final delcamino en el extremo asociado al elemento más general (fi-

gura 2). Un grupo de caminos de generalización correspon-dientes a una misma clasificación para una superclase dadase puede representar como una estructura arborescente conun segmento, incluyendo el triángulo, que se bifurca en mÚl-tiples caminos, cada uno de los cuales direcciona a una

sub clase (figura 3).

El camino de generalización puede ir acompañado de unacadena de texto que corresponde al discriminador que definela clasificación. El discriminador es el nombre de una parti-ción de las sub clases de la superclase. Varios caminos de ge-neralización hacia una misma clase, que se encuentran acom-pañados por el mismo discriminador, indican que las sub clases

correspondientes representan particiones de una misma cla-sificación definida sobre la superclase. Sobre una mismasuperclase se pueden establecer diferentes clasificaciones, demanera que los caminos de generalización integrados en unamisma clasificación estarán acompañados por el mismo

discriminador (figura 2).UML permite definir restricciones semánticas entre las

sub clases. De esta forma el lenguaje incorpora cuatro restric-

ciones predefinidas:

Aunque la mayoría de las metodologías de análisis orientado

a objetos defienden una visión abstracta del concepto de es-

pecializaciÓn en la fase de análisis (Champeaux el al., 1993 ;

Cook y Daniels, 1994; Rumbaugh el al., 1991 ), etc., esta vi-

sión se puede contaminaF fácilmente por su cercanía (sólo en

ciertos aspectos) con el mecanismo de herencia soportado por

los lenguajes de programación orientados a objetos.

La conexión entre el concepto de herencia y el de especia-

lización está en que al compaginar las características de la

superclase y la clase especializada (la sub clase ), debemos

aplicar cierto tipo de herencia que nos permita combinar ambas

especificaciones.El problema está en que en los lenguajes de programación,

la herencia se suele utilizar simplemente como mecanismo

de reutilización, sin asegurar ningún tipo de relación entre

las propiedades de la superclase y la sub clase, y en la mayo-

ría de los casos es ésta la idea que se suele aplicar en etapas

tempranas como el análisis, en lugar de explotar la abstrac-

cióQ que proporciona la especialización.

D Overla1212ing: las sub clases pueden compartir instancias.

D Disjoint: las sub clases no comparten instancias.

D Com12lete: se han especificado todas las sub clases posi-

bles.

D Incom12lete: no se han especificado todas las sub clases

posibles.

Para definir las restricciones entre las sub clases se sitúa entre

llaves una lista de las palabras claves correspondientes y lo-

calizadas en las proximidades del triángulo indicativo de la

generalización (en el caso de que varios caminos de generali-

2 En este caso serían sólo cuatro: Persona, PersonaEstudiante,

PersonaTrabajador y PersonaEstudianteTrabajador, pero es evidente que

cuando el número de especializaciones crece, las clases independientes lo

hacen de forma exponencial.

205

J. A. Troyano, M. Mejías, J. Torres y M. Toro: Extensiones al Sistema de Clasificación de UML

4 Extensioneszación compartan un mismo triángulo), o de una línea a tra-zos que cruza todas las líneas de generalización que se ven

afectadas por las restricciones correspondientes (figura 2).

Persona

ocupació

{ overlapping } }

1.::(

~

~

Como hemos visto, el mecanismo que UML dedica a expre-sar cualidades taxonómicas de los modelos es la generaliza-

ción. Sin embargo, observamos las siguientes deficiencias:

O Al igual que en muchos otros mecanismos, en la defini-ción de la generalización quedan muchos aspectos sin

concretar, lo que hace imposible una interpretación con-

creta de este mecanismo, que es el que más se acerca alconcepto de taxonomía.

O No existe una forma clara de establecer criterios de cla-sificación. Tan sólo está el concepto de discriminanteque se asocia a un atributo o papel de asociación, perolas clasificaciones que se pueden establecer con él son

bastante rígidas.O A pesar de que UML contempla la definición de espe-

cializaciones dinámicas, no establece con claridad la for-ma en la que los objetos pueden migrar de una especiali-zación a otra.

Figura 2: La generalización en UML

Todos estos aspectos se pueden solventar introduciendo elconcepto de criterio de clasificación. Para ello introducire-mos un nuevo elemento de modelado mediante la definición

UML contempla el concepto de powertype para hacer refe-rencia a una metaclase cuyas instancias son sub clases de otraclase. La notación utilizada por UML para representar un"powertype" hace uso del estereotipo «powertype», que pue-de ser aplicado al símbolo básico de representación de la cla-se o a una dependencia que relaciona la superclase con la

metaclase a cuyas instancias corresponden las sub clases (fi-

gura 3).En realidad el powerype más que un elemento de ayuda en

la descripción de una taxonomía es una información deriva-da de ésta, de manera que se aprovecha la definición de una

serie de sub clases de una determinada clase para obtener una

metaclase cuyas instancias son dichas sub clases.Figura 4: Notación gráfica para la especialización

de un estereotipo del elemento Clase. Denominaremos a este

estereotipo Especialización, y utilizaremos como símbolo depresentación el que se muestra en la figura 4.

Describiremos la semántica de este estereotipo -siguiendo

el mismo estilo que el utilizado en la definición de UML-con el siguiente párrafo en lenguaj~ natural:

Una Especialización es un estereotipo de Clase quecontiene un criterio que sirve para determinar si unobjeto dado pertenece a ella. Toda especializacióndebe estar ligada a través de una relación de Genera-lización con otra clase más abstracta (que puede ser ,

a su vez, una especialización o no), lo que impideque una especialización sea la raíz de un árbol de

generalización.

Para completar la definición anterior sólo queda concretarqué es un criterio. En principio sólo estudiaremos la opciónmás evidente, que no es otra que considerar que un criterioestá constituido por una expresión lógica. Sin embargo, al

Figura 3: Uso del powertype en UML

206

J. A. Troyano, M. Mejías, J. Torres y M. Toro: Extensiones al Sistema de Clasificación de UML

final de esta sección enumeraremos una serie de criterios al-

ternativos que, aunque en la mayoría de loS casos pueden ser

expresados a través de criterios con expresiones lógicas (lue-go no constituyen una ampliación del poder descriptivo) son

interesantes, ya que pueden dar lugar a especificaciones másclaras y compactas al modelar ciertas situaciones taxonómicas.Un criterio será por tanto lo siguiente:

nos pennitirán establecer las particiones del colectivo de per-sonas.

Persona

sexo: Sexo { constante }

matrículas : Natural

contratos: Natural

A

Hombre

criteriosexo = masc

Parado

criterio

matrículas=O

and contratos=O

. ~ studiante ...

criterio

matrículas > O

Una expresión lógica formada con atributos de las

clases antecesoras en el árbol de generalización. Para

construir diOOas expresiones disponemos de la po-

tencia que nos proporcionan los operadores dellen-

guaje de especificación de restricciones OCL (Object

Constraint Language).

Dada una especialización C y su generalización C,

todo objeto de C que cumplh el criterio de C perte-necerá también a esta última. i Mujer ...

criteriosexo = fem

Trabajador

criterio

contratos > O

Figura 5: Clasificación estáticas y dinámicas

El criterio se especificará en un nuevo compartimento de laclase que se titulará criterio. Este compartimento irá justodespués del nombre de la clase y sólo se podrá utilizar en las

especializaciones (figura 5).El mero hecho de introducir este simple elemento hace que

se amplíen considerablemente las posibilidades de describir

situaciones taxonómicas con respecto a los elementos bási-cos de UML. En concreto podremos definir clasificaciones

estáticas, dinámicas, colectivas, individuales y especificarrestricciones de clasificación de una manera mucho más flexi-ble y compacta que la planteada en el modelo original. En las

siguientes secciones mostraremos todas estas ventajas.

Como se puede observar con facilidad, las clases Hombre

y Mujer son especializaciones estáticas, ya que al depender

sus criterios sólo de atributos constantes, no podrá variar la

evaluación de dichos criterios para un objeto determinado.

Por su parte las clases Estudiante, Trabajador y Parado son

claramente dinámicas, ya que cualquier modificación del

número de contratos o matrículas de un objeto Persona pue-

de hacer variar su situación.

El ejemplo muestra, además, la flexibilidad del concepto

de criterio de clasificación frente al concepto de discriminan-

te incorporado en UML. Mientras que las especializaciones

Hombre y Mujer son fácilmente expresables en UML hacien-

do que el discriminante sea el atributo sexo de la clase Perso-

na, no ocurre lo mismo con las otras clases en las que los

atributos que discriminan son de un tipo infinito (como es el

Natural), lo que imposibilita establecer particiones si no es

con el uso de predicados, o incluso se combinan dos atribu-

tos como en el caso de la clase Parado.

4.1 Clasificaciones Estáticas y Dinámicas

La primera consecuencia de la introducción de las especiali-

zaciones es la capacidad.de describir tanto clasificaciones

estáticas como dinámicas. En realidad la característica estáti-

ca o dinámica no estaría asociada a la jerarquía completa de

clasificación, sino que será una cualidad específica de una

determinada especialización, que dependerá exclusivamente

de la estructura de su criterio de clasificación:

4.2 Clasificaciones no Disjuntas

o Si el criterio de una especialización se basa exclusiva-

mente en atributos constantes de las clases antecesoras

la especialización será estática.

O Si el criterio de una especialización contiene algún atri.

buto variable de las clases antecesoras, la especializa-

ción será dinámica.

Denominaremos clasificaciones no disjuntas a aquellas en la

que se definen varias especializaciones de una superclase que

pueden compartir instancias. El ejemplo de la figura 5 es evi-

dentemente una clasificación no disjunta, ya que es posible la

existencia de objetos que pertenezcan a varias de las especia-

lizaciones de la clase Persona. Así, podemos imaginar un

objeto de la clase Persona que pertenezca a las especializa-

ciones Hombre, Trabajador y Estudiante. Para ello tan sólo

será necesario que dicho objeto verifique simultáneamente

En la figura 5 se muestra una taxonomía en la que se defi-

nen cinco especializaciones de la clase Persona, cuyos obje-

tos están caracterizados (entre otras cosas) por su sexo, el

número de contratos de trabajo que dicha persona tiene vi-

gentes, y el número de matrículas efectuadas en entidades

educativa~. Precisamente serán estos tres atributos los que

.'07

J. A. Troyano, M. Mejías, J. Torres y M. Toro: Extensiones al Sistema de Clasificación de UML

A diferencia de las clasificaciones individuales, en una cla-

sificación colectiva no hace falta que un objeto cambie de

estado para que su adscripción a una especialización cambie,ya que basta cualquier cambio en los atributos de ámbito declase para que cambie el sentido de evaluación del criterio.

los criterios de estas especializaciones, cosa que dada la es-

tructura de dichos criterios es perfectamente posible.

Esta posibilidad de definir clasificaciones no disjuntas (o

solapables) ya estaba accesible, aunque de forma más limita-da, en el modelo original de UML a través de la restricciónde clasificación {overlapping}. Decimos que este mecanis-

mo es más limitado ya que lo único que permite es declarar

que una serie de especializaciones son solapables, sin definir

bajo qué condiciones un determinado objeto puede pertene-cer a todas ellas. La riqueza que aporta el criterio de clasifi-cación está en que permite establecer de forma explícita estas

condiciones.

4.3 Clasificaciones Colectivas

En el ejemplo de la figura 510s criterios eran expresiones que se

construían basándose en atributos individuales de loS objetos,lo que hace que la adscripción de un objeto a una determinada

especialización dependa exclusivamente de su estado. Sin em-bargo, combinando la idea de criterio con lo que UML denomi-na atributos de ámbito de clase, podemos modelar clasificacio-nes en las que la adscripción de un objeto a una especialización

no dependa sólo de su estado, sino que dependa también delestado del resto de objetos de la generalización.

En la figura 6 se muestra un ejemplo de este tipo de clasifi-

caciones, en ella se define la generalización Persona que se

caracteriza por el atributo individual altura y por los atribu-tos de ámbito de clase lia y Isa que mantienen el límite infe-rior y el límite superior de altura respectivamente, es decir, la

altura de la persona más baja y la altura de la persona más

alta. Estos límites, que serán conocidos por todos los objetos,serán actualizados cada vez que cualquier cambio en cual-quiera de los objetos de la clase Persona haga que cambien.

Basándonos en dichos ~tributos podemos establecer tres di-visiones dentro de las personas, los bajos que serían los quese encuentran en el primer tercio del rango de alturas, los

medios que se encontrarían en el segundo y los altos en eltercero y último.

4.4 Clasificación Múltiple y Clasificación Negativa

La generalización en UML puede ser múltiple en el sentidode que una determinada clase especialice a varias clases másgenerales. Sin embargo, desde un punto de vista taxonómicoesto sólo tiene sentido si todas esas clases más generales son

a su vez especializaciones de otra clase aún más general.Por ejemplo, en la figura 2 se muestra la clase NoBecado

que se obtiene a partir de la especialización de las clases Tra-

bajador y Estudiante. Con esta clase se caracterizan aquellosestudiantes que a la vez trabajan, limitándoles la posibilidadde optar a una ayuda económica ya que disponen de una fuente

de ingresos debida a su trabajo.La introducción de este tipo de especializaciones con va-

rias clases padre hace que en lugar de árboles taxonómicos

tengamos grafos acíclicos dirigidos. Además estos grafos ten-dr~n una raíz única, es decir debe destacarse siempre una cla-se más general que sea superclase de todas las demás. De esta

forma, si imaginamos una relación que vincule a una espe-cializaciÓn con más de una generalización que no sean a suvez especializaciones de una clase más general, puede ser

por alguno de los siguientes motivos:

O Que esa clase más general exista realmente pero que aún

no la hemos contemplado en el modelo, y precisamentea la hora de idear la nueva especialización nos percata-mos de su existencia.

O Que la relación que queremos especificar no sea

taxonómica y por tanto debemos utilizar otro mecanis-mo que no sea la generalización para expresarla. Algoparecido a esto es lo que ocurre con la herencia múltipleen muchos lenguajes de programación orientados a ob-

jetos, que realmente lo que modela es algo parecido auna agregación donde la clase hija aglutina las propieda-

des de todas las clases padre.

En realidad lo que hemos llamado clasificación múltipleno es más que una consecuencia de la existencia de las clasi-

ficaciones no disjuntas, que al dar lugar a clases solapables

permiten caracterizar el conjunto de objetos que pertenecen atodas ellas.

Este tipo de especialización con varias generalizacionespuede tener un criterio de clasificación que filtre el conjuntode objetos que deben pertenecer a ella. Por ejemplo, en el

caso de la clase NoBecado podemos establecer como criterioque el sueldo de ese Trabajador-Estudiante sobrepase cierta

cantidad, de forma que todos aquellos que tengan una rentaFigura 6: Clasificaciones colectivas

208

J. A. Troyano, M. Mejías, J. Torres y M. Toro: Extensiones al Sistema de Clasificación de UML

cialización de la clase Adulto, en la que no se incluyen losobjetos de las clases Estudiante y Trabajador. De esta fonna

explicitamos que la condición que deben cumplir los objetosde esa clase es precisamente la no pertenencia a dichas cla-

ses. En este ejemplo se ha definido la clase ParadoPrioritariocomo clase sin criterio, pero perfectamente podría habersedefinido un criterio para ella, en ese caso los objetos de dicha

clase además de ceñirse a las limitaciones de sus generaliza-ciones negativas deberían cumplir también dicho criterio de

clasificación.

4.5 Criterios Frente a Restricciones de clasifi-cación

Las restricciones de clasificación de UML nos permiten defi-nir propiedades de una determinada jerarquía de clasifica-ción. Con ellas podemos indicar que ciertas clases sondisjuntas o solapables o que constituyen una clasificacióncompleta de una clase más general. En principio esta formade especificar resulta bastante abstracta, sin embargo en al-gunas situaciones aparentemente simples, el número de res-tricciones que tenemos que contemplar suele ser tan elevadoque utilizar exclusivamente el método de las restriccionespuede dejar de ser interesante. Por ejemplo en la clasifica-ción de la figura 5, necesitamos hasta siete restricciones declasificación para caracterizar completamente las posiblessituaciones que se pueden dar (figura 8).

menor no sean catalogados como «no-becables».Precisamente esta multiplicidad que introducen las espe-

cializaciones no disjuntas nos permite introducir un nuevotipo de relación: la generalización negativa, que aunque sepuede llegar a expresar combinando las relaciones existentes

con las restricciones de clasificación, en algunas ocasionespuede servir para hacer más claro ( o explícito) un modelo.

Para representar este tipo de relación utilizaremos la mis-

ma flecha que la utilizada para la generalización pero contrazo punteado. Sólo podremos utilizar esta relación en elcontexto de un árbol de generalización y su semántica será la

siguiente:

I:J Una clase que tenga una relación de generalización ne-gativa con otra clase será disjunta con respecto a ella.

I:J Una clase inmersa en un árbol de generalización siem-pre será especialización positiva de la clase raíz del ár-bol de generalización (aunque sólo tenga definidas rela-

ciones de especialización negativas).

Como consecuencia directa de la segunda propiedadresulta imposible establecer una relación de generalizaciónnegativa con la clase raíz del árbol de generalización. Cosapor cierto totalmente lógica ya que si así fuese, estaríamosdefiniendo una especialización cuyos objetos no pertenecena la clase más general de todas (la clase raíz).

Como se puede ver, la semántica de esta nueva relación noaporta mucho más de lo que ya proporciona la propiedaddisjoint. La utilidad de esta relación hay que buscarla en laclaridad y en la obtención de diagramas más explícitos.

I-~~..V7~

Figura 8: Restricciones de clasificación

i~ ., I

I

ParadoPrioritario

Figura 7: Generalización negativa

Evidentemente especificar siete restricciones de clasifica-ción para tan sólo cinco especializaciones de una clase resul-ta poco claro y de una complejidad que no se ajusta al tamaño

del problema. Sin embargo, con la introducción de los crite-

rios de clasificación podemos llegar a reducir el número derestricciones ya que algunas de ellas podrán ser deducidasdirectamente de las fórmulas que sirven de criterio a las espe-cializaciones. En concreto, con los criterios especificados enla propia figura 5, no haría falta indicar ninguna de las pro-

piedades.Con esto no queremos decir que las restricciones de clasifi-

cación no sean un método abstracto y útil, sino que constitu-yen un método complementario a los criterios de clasifica-

La figura 7 muestra un ejemplo de utilización de la genera-lización negativa, en la que basándonos en el ejemplo de lafigura 2 se define la clase ParadoPrioritario como una espe-

,,{\O

J. A. Troyano, M. Mejías, J. Torres y M. Toro: Extensiones al Sistema de Clasificación de UML

damentalmente el interés por las clasificaciones dinámicas.ción de gran ayuda, sobretodo, en las siguientes situaciones'

D Cuando queremos asegurar una propiedad entre espe-

cializaciones y los criterios que hemos descrito no son losuficientemente precisos como para que dicha propie-dad se pueda demostrar a partir de ellos.

D Cuando queremos enfatizar una propiedad que, aunque

pueda ser demostrable en base a los criterios, decidimoshacer explícita por considerar que constituye una infor-mación relevante para el modelo.

TROLL (Jungcaluss el al., 1991) tiene en el role (en ade-lante papel) el mecanismo básico para establecer clasifica-ciones. En este caso el criterio de clasificación utilizado sebasa en la existencia de un evento de creación y otro de des-

trucción del papel, de manera que el objeto de la clase padrejuega el papel de la especialización durante el período com-

prendido entre su participación entre ambos eventos. La ma-yor diferencia con nuestro modelo radica en la forma en laque se representan los objetos de la especialización, para no-sotros es el mismo que el de la clase padre (tiene la misma

identificación) mientras que en TROLL las características dela especialización se delegan en un nuevo objeto.

En cierto modo, la introducción de los criterios como mé-todo más preciso de clasificación, nos da mayor margen demaniobra a la hora de decidir cuál es la notación adecuadapara expresar una determinada característica.

En SYNTROPY (Cook y Daniels, 1994) se utiliza el con-cepto de state types (lo podemos traducir como subtipo diná-mico o sub clase dinámica) para modelar clasificaciones di-námicas. Una sub clase dinámica contendrá en cada momen-to a los objetos de su superclase que se encuentren en un es-tado concreto de la máquina de estados que define el com-

portamiento de la superclase. De esta forma se aprovecha laespecificación de comportamiento de la clase padre (que esdiagramática) para identificar la estancia en alguno de susestados con la pertenencia a las especializaciones. Aunqueen algunas situaciones este criterio gráfico pueda resultar másnatural, en general siempre será menos flexible que el crite-rio basado en predicados sobre atributos.

4.6 Criterios e Invariantes

ROSES (Costa et al., 1996) se apoya en los conceptos de

clases derivadas y clases seleccionadas por eventos para ex-

presar relaciones taxonómicas de los modelos 00. Una clase

derivada contiene a todos aquellos objetos de su superclase

que cumplen una condición. Esta condición se apoyará sólo

en atributos individuales, por lo que no será posible estable-

cer clasificaciones colectivas. Por su parte una clase selec-

cionada por eventos contiene aquellos objetos de su superclase

que han sido insertados en ella (mediante un evento de entra-

da) y no han sido retirados de ella (mediante un evento de

salida).

En UML se define el estereotipo «invariant» que nos pennite

establecer una condición que deben cumplir todos los obje-tos de una clase. El hecho de que el criterio de clasificación

que hemos presentado sea también una condición nos puedellevar a pensar que estos dos conceptos pueden tener algoque ver.

En realidad son dos conceptos claramente distintos peroque tienen una característica común: la constancia en la eva-luación a nivel de clase. En efecto tanto el invariante como elcriterio de clasificación son predicados que serán siempreciertos para los objetos de una detenninada clase, la que dife-rencia a estos conceptos es la fonna en la que se asegura esta

constancia de evaluación.

D En el caso del invariante, conseguiremos que los objetos

de la clase siempre la cumplan evitando todo aquel cam-bio de estado que lleve a que el invariante se incumpla.

D En el caso del criterio de clasificación, es cierto para to-dos los objetos de la clase simplemente porque cuando

deja de serIo el objeto deja de pertenecer a la clase.

De esta forma, el invariante impone una restricción másfuerte, tanto que es imposible que se incumpla, mientras queel criterio describe una restricción más leve, que cuando seincumple tan sólo tiene el efecto de retirar al objeto de la

especialización couespondiente.

5 Otros Posibles Criterios de Clasificación

Hemos presentado tan sólo un tipo de criterio de clasifica-

ción, el predicado sobre atributos del objeto y de la clase, por

ser el más compacto y potente. Sin embargo se pueden ima-

ginar otros criterios, que aunque en su mayoría pueden ser

implementados mediante la introducción de atributos y la

evaluación de predicados, en algunas situaciones taxonómicas

pueden dar lugar a soluciones más claras y abstractas. En las

siguientes subsecciones plantearemos algunos de ellos.

4.7 Trabajos Relacionados

Como ya hemos comentado anteriormente, hay muchas pro-puestas que están en sintonía con las ideas presentadas en elartículo. De todas ellas queremos reseñar tres: TROLL,SYNTROPY y ROSES. Las tres son propuestas de modeladoorientadas a objetos y tienen en común (también con nuestrotrabajo) el haber desarrollado mecanismos taxonómicos y fun-

210

J. A. Troyano, M. Mejías, J. Torres y M. Toro: Extensiones al Sistema de Clasificación de UML

5.1 Cambio de Especialización Mediante Eventos tos de la clase Persona en dicha asociación, el siguiente pre-dicado nos sirve de criterio:

#trabaja > O

Donde el operador # aplicado a un papel de asociación cal-

cula cuántos enlaces tiene un determinado objeto a través de

dicha asociación.

5.4 Predicados de Lógica Temporal

Este tipo de criterio se basa en la definición de eventos quehacen que los objetos entren o salgan de una determinada

especialización. En cierto modo lo que hacemos es utilizarcomo criterio la causa del cambio de estado (la ocurrencia deeventos) en lugar del efecto (el propio cambio de estado).

Por ejemplo, para la clase Persona y su especialización

Estudiante, podemos pensar en los eventos matrícula y

fin-de-curso para determinar, respectivamente, el comienzoy el fin del período durante el que el objeto de la clase Perso-na pertenece a la clase Estudiante .

Puede ser expresado mediante predicados definiendo un

atributo que cambie de valor cuando el objeto participe endichos eventos destacados.

5.2 Predicados sobre Trazas de Eventos

En lugar de establecer un criterio en base al estado actual de

los objetos, podemos referirnos a los valores que han toma-do los atributos en el pasado. Imaginemos, por ejemplo, unsistema bancario en el que la clase Cliente recoge las propie-

dades de los usuarios del banco. Si un cliente solicita un prés-tamo al banco, a éste último le interesaría saber si el clientees fiable o no. Uno de los criterios que el banco puede utilizares comprobar si a lo largo de su relación con el cliente éste hatenido alguna vez un saldo negativo.

Este tipo de propiedades puede ser expresada mediante fÓr-mulas de pasado de lógica temporal (Manna et al., 1992). Elcriterio para la especialización NoFiable de la clase Clientepodría ser:

Este criterio es una generalización del anterior, pero en lugarde inspeccionar sólo un evento, evalúa la traza de eventos enlos que el objeto ha participado hasta el momento. Para poder

utilizar este tipo de criterio necesitamos ampliar nuestro len-guaje de especificación de propiedades con operaciones de

manejo de trazas de eventos (Hoare, 1985).Por ejemplo, la especificación Parado de la clase Persona

puede ser caracterizada en base al número de veces que unobjeto ha participado en los eventos contrato y despido:

e (Saldo < O)

#contrato( tr )=#despido( tr) Donde el operador e significa «alguna vez en el pasado»

El hecho de utilizar fórmulas acerca del pasado nos asegu-ra la ejecutabilidad del criterio. En el caso concreto del ejem-plo bastaría con un atributo de tipo lógico que recordase sialguna veZ el predicado Saldo<O ha sido violado.

La operación #contrato aplicada a una traza de eventos cal-cula el número de veces que el evento contrato aparece en dichatraza. Igualmente ocurre con la operación #despido. Así, si latraza tr representa la vida del objeto, la fórmula anterior carac-

terizaría a todos los objetos de la clase Persona que hayan sufri-

do el mismo número de contrataciones y despidos. 5.5 Creación Directa

5.3 Predicados sobre el Estado Externo al Obje-to ya la Clase

Este tipo de criterio se basa en la definición de distintas opera-ciones de creación de objetos para cada especialización (en lu-gar de evaluar objetos ya existentes de una clase general para

determinar a qué especialización pertenece). La idea de la crea-ción directa es bastante similar a la que proporcionan los len-guajes de programación con el concepto de constructor, demanera que según sea la característica que provoca la creacióndel objeto se decide a qué especialización pertenece.

De todos los criterios planteados en esta sección, tan sólo la

creación directa no es expresable directamente mediante predi-cados sobre el estado, ya que éstos trabajan sobre objetos yaexistentes y determinan a qué clase deben pertenecer, mientrasque la creación directa usa precisamente la forma de creacióndel objeto para determinar a qué clase va a pertenecer.

En este tipo de criterios utilizaremos un estado que no se re-

coge directamente a través de los atributos de los objetos sinoque está disperso a lo largo de diversos elementos del siste-ma. El ejemplo más claro de este tipo de estado viene dadopor las asociaciones.

Supongamos un sistema en el que existan las clases Perso-na y Empresa, entre las que se establece una asociación Con-

trato. En este caso podemos deducir que un objeto de la clasePersona es a su vez Trabajador preguntando por el númerode enlaces que el objeto Persona tiene a través de la asocia-ción Contrato. Así, si trabaja es el papel que juegan los obje-

21

J. A. Troyano, M. Mejías, J. Torres y M. Toro: Extensiones al Sistema de Clasificación de UML

6 Conclusiones Referencias

A pesar de que hemos propuesto un~ serie de ampli~ciones auna notación como UML, quizá la aportación más importan-te que se puede destacar es de corte metodológico, ya que se

plantea la utilización del mecanismo de generalización paradar soporte al concepto de taxonomía. En este sentido el áni-mo del artículo no es alterar la semántica de ningún elementode UML, sino establecer de qué manera se pueden utilizar

elementos que ya están en UML para llegar a expresar deforma clara relaciones taxonómicas en los modelos que cons-

truyamos.Como solución concreta hemos propuesto la definición del

estereotipo «especialización», que permite adscribir un cri-terio de clasificación a una determinada clase de objetos.

Hemos propuesto que este criterio de clasificación sea una

expresión lógica escrita en el lenguaje de especificación derestricciones OCL, aunque como hemos visto en la sección5, se pueden pensar otros tipos de criterios que permitan ob-

tener unas especificaciones más compactas y ajustadas a cada

problema concreto. A partir de la introducción del conceptode criterio de clasificación, hemos visto que con él se pueden

definir taxonomías de distintos tipos: constantes, variables,

individuales, colectivas, múltiples o negativas, mostrando conejemplos la utilidad que puede tener cada una de ellas.

Todos los elementos presentados en este artículo han sidotratados formalmente en la Tesis Doctoral (Troyano, 1998),en dicho trabajo se estudia el concepto de clasificación en el

contexto del lenguaje de especificación formal TESORO (To-

rres, 1997) desarrollado en el Departamento de Lenguajes ySistemas Informáticos de la Universidad de Sevilla. En estos

trabajos, además de tratarse el concepto de criterio de clasifi-cación se plantea el otro gran problema asociado a la defini-ción de taxonomía: la combinación de comportamientos. En

efecto, si con el mecanÍsmo de generalización posibilitamosque un objeto pertenezca a una clase general ya una o más

clases especializadas, necesitames una manera de combinarlas especificaciones de comportamiento de todas estas clases

para obtener el patrón.de comportamiento de estos objetos.

Nuestro trabajo futuro está orientado hacia dos líneas:

Champeaux D., D. Lea y P. Faure. «Object Oriented System

Development». Addison-WesleyPublishing Company.1993.Cook S. y J. Daniels. "Designing Object Oriented Systems.

Object Oriented Modelling with SYNTROPY", Prentice Hall

lnternational. 1994.Costa P., M. Barceló, D. Costal, A. Olivé, C. Quer, A. Rosellóy M.R. Sancho. "Las Clases de Objetos en ROSES". In

proceedings of I Jornadas de Investigación y Docencia enBases de Datos. La Coruña (Spain). 1996.Hoare C.A.R. "Communicating Sequential Processes".

Prentice-Hall International Series in Computer Science. 1985.Jungclaus R., G. Saake, T. Harlmann, C. Sernadas. "Object-Oriented Specification of Information Systems: The TROLL

Language". Informe interno. Technische UniversitiitBraunschweig. 1991.Manna Z. y A. Pnueli. "The Temporal Logic of Reactive and

Concurrent Systems. Specification". Springer- Verlag. 1992.Nierstraz O. , "Regular Types for Active Objects. In ObjectOriented Software Composition". Eds: 0. Nierstraz and D.

Tsichritzis. Prentice Hall. 1995.Parets J. "Clasificación Evolutiva en el Desarrollo de Soft-ware". In proceedings of I Jornadas de Ingeniería del Soft-

ware. Sevilla (Spain). 1996.

Rumbaugh J., M. Blaha, W. Premerlani, F. Eddy y W.Lorensen. "Object-Oriented Modelling and Design ".

Prentice-Hall International. 1991.Rumbaugh J., I. Jacobson y G. Booch. "The Unified

Modeling Language Reference Manual". Addison Wesley.1998.Saake G., P. Harlel, R.Jungclaus, R. Wieringa y R. Feenstra.

"Inheritance Conditions for Object Life Cycle Diagrams". InFormale Grundlagen für den Entwurf von

Informationsystemen. Eds: U. W. Lipeck and G. Vossen.Institut für Informatik, Universtait Hannover (Germany ).

1994.Torres J. "Especificaciones Orientadas a Objetos basadas enRestricciones. Prototipado en un Lenguaje Orientado a Pro-cesos". Tesis Doctoral. Universidad de Sevilla (Spain). 1997.

Troyano J.A.. "Herencia y Clasificación en un Lenguaje deEspecificación Orientado a Objetos". Tesis Doctoral. Uni-versidad de Sevilla (Spain). 1998.

Wieringa R., W. de Jonge y P. Spruit. "Using DynamicClasses and Role Classes to model Object Migration". TheoryandPractice ofObjectSystems. Vol. I. Pp. 61-83.1995.

D El estudio de la compatibilidad de comportamientos para

los distintos diagramas de especificación de comporta-

mientos de UML.D La inclusión en UML de los criterios presentados en la

sección 5 junto con la elaboración de una guía

metodológica que permita ayudar a elegir el mejor tipode criterio para cada situación.

212

J. A. Troyano, M. Mejías, J. Torres y M. Toro: Extensiones al Sistema de Clasificación de UML

José A. Troyano obtuvo el grado de Doctor en Informática en 1998 por la Universidad deSevilla (España). Desde 1991 es profesor en el Departamento de Lenguajes y SistemasInformáticos en la Universidad de Sevilla. Su investigación se centra en los lenguajes deespecificación y en los conceptos de herencia y taxonomía en modelos orientados a obje-

tos.

Manuel Mejías recibió el grado de Doctor Ingeniero Industrial en 1997 por la Universidadde Sevilla (España). Es profesor de Ingeniería del Software en la Universidad de Sevilladesde 1987. Actualmente basa su actividad investigadora en Técnicas de Descripción Formal,Modelado Orientado a Objetos de Sistemas Software y Sistemas de Gestión de Redes de

Comunicaciones.

Jesús Torres obtuvo el grado de Doctor en Informática en 1997 por la Universidad de

Sevilla (España). Desde 1991 es profesor en el Departamento de Lenguajes y Sistemas

Informáticos en la Universidad de Sevilla. Sus áreas de interés son la ingeniería de requi-

sitos, la orientación a objetos y los sistemas distribuidos.

Miguel Toro obtuvo el grado de Doctor Ingeniero ]ndustrial en ]987 por la Universidad

de Sevilla (España). Desde ]985 es profesor en el Departamento de Lenguajes y Sistemas

]nformáticos en la Universidad de Sevilla. Sus investigaciones se centran en los campos de

la ingeniería de software, los sistemas distribuidos y los métodos formales.

213