Captulo 6

Modelado Conceptual: Fundamentos

TEMAS CLAVE EN ESTE CAPTULO

Atributos
Conceptos
Asociaciones
Colecciones
Organizacin del modelo conceptual: estructural, asociativa, y
temporal
Invariantes
Construccin iterativa del modo conceptual

6.1 Introduccin al modelado conceptual

El Anlisis del Dominio consiste en descubrir y modelar la informacin

que tiene que ser administrado por el sistema. Esto significa que el equipo
debe descubrir cmo la informacin tiene que ser estructurada y
transformada. Se inicia durante el Inicio con el modelo conceptual preliminar
y contina durante la Elaboracin, cuando dicho modelo es refinado y
completado segn el anlisis de requerimientos se profundiza con los casos
de uso expandido.

Uno puede analizar dos aspectos de la informacin: esttica (tambin

llamado estructural), que se estudia en este captulo y en el captulo 7, y
funcional, estudiado en el captulo 8 El aspecto esttico puede ser
representado en el modelo conceptual y el aspecto funcional en los
contratos de operacin del sistema.

Durante el anlisis no existe un modelo dinmico para los objetos, porque el

anlisis toma en consideracin slo una vista externa del sistema. El modelo
dinmico, que consiste en las colaboraciones entre los objetos, se realiza
durante el diseo (Captulo 9), porque slo en ese momento son tratados los
aspectos internos del sistema. As, el modelo funcional del anlisis slo
indica qu informacin entra y sale del sistema, sin decir cmo se
transforma la informacin. Ms tarde, el modelo dinmico de diseo
mostrar claramente cmo las colaboraciones de los objetos podran
cambiar la informacin.

El modelo conceptual describe la informacin que el sistema va a

gestionar. Es un artefacto del dominio del problema, no del dominio de la
solucin. Por lo tanto, el modelo conceptual no se debe confundir con el
Diagrama de Clase de Diseo (DCD), que pertenece a la arquitectura del
software (Captulo 9). El DCD, aunque en un principio derivado del modelo
conceptual, pertenece al dominio de la solucin y por lo tanto sirve para
diferentes propsitos.
El modelo conceptual no debe tambin ser confundido con el modelo de
datos (Captulo 13), debido a que el modelo de datos enfatiza la
representacin y la organizacin de los datos almacenados, mientras que el
modelo conceptual tiene por objeto representar la comprensin de la
informacin por los usuarios, no su representacin fsica. Por lo tanto, un
modelo de datos relacional es slo una de las posibles representaciones
fsicas de un modelo conceptual ms esencial.

Una forma interesante de comprender el modelo conceptual es imaginar

que los elementos descritos por ella corresponden a la informacin que
existe en un principio slo en la mente del usuario, tal como se representa
en la Figura 6.1, y no en un sistema de tienda fsica.

FIGURA 6.1El modelo conceptual es una representacin de la vista de los

usuarios de la informacin.

Un usuario enva informacin al sistema y recibe informacin desde

el sistema a travs de eventos y retornos del sistema,
respectivamente. En este punto, el sistema no necesita ni siquiera ser
considerado un sistema computacional, porque existe la informacin
independientemente del soporte informtico para el almacenamiento y
gestin.
 El objetivo del anlisis es estudiar el problema. Pero el sistema
computacional es una solucin, y por lo tanto, pertenece al diseo. La
solucin del sistema incluso podra disearse sin la tecnologa informtica.
Es posible analizar toda una situacin y luego proponer una solucin manual
para ponerlo en prctica, en la que, por ejemplo, los datos se almacenan en
hojas de papel, y las operaciones realizadas por los trabajadores utilizan
lpiz, goma de borrar, y engrapadoras.

Al igual que los casos de uso esenciales, el modelo conceptual es

independiente de las soluciones fsicas que se podran adoptar, y debe
contener slo elementos que pertenecen al dominio del problema, dejando
al diseo, los elementos de la solucin, es decir, todos los elementos
relacionados a la tecnologa, como las interfaces, almacenamiento,
comunicacin, y as sucesivamente.

El modelo conceptual representa slo el aspecto esttico de la informacin.

Por lo tanto, en el modelo conceptual, no pueden existir referencias a
operaciones o aspectos dinmicos del sistema. Aunque el modelo
conceptual se representa mediante el diagrama de clases UML, el analista
an no debe incluir ningn mtodo. Captulo 9 muestra cmo identificar y
disear mtodos utilizando un enfoque sistemtico. Cuando se utiliza el
diagrama de clases para el modelado conceptual, hay precisamente tres
tipos de elementos a utilizar para la representacin de la informacin:

Atributos: alfanumrico simple o informacin primitiva, como nmeros,

textos, fechas, etc. Ejemplos de atributos en el proyecto Livir son el
nombre del cliente, fecha de pago, ttulo del libro, y el valor total de la
orden. Un atributo est siempre conectado a un elemento ms complejo:
el concepto.
Conceptos: La representacin de la informacin compleja que tiene un
significado coherente en el dominio. Los Conceptos generalmente
agregan atributos y no pueden describirse simplemente como
alfanumrico. Los conceptos tambin pueden estar asociados entre s.
Ejemplos de conceptos en el proyecto Livirsonel libro, los clientes, el
orden y el pago.
Asociaciones: Un tipo de informacin que vincula diferentes conceptos.
Sin embargo, las asociaciones son ms que simples enlaces: ellos son
informacin. En el ejemplo Livir deberan existir asociaciones entre las
rdenes y el cliente, y tambin entre las rdenes y libros, por ejemplo.
Estos tres elementos se detallan en las siguientes secciones. Es
prcticamente imposible explicar uno sin mencionar a los otros, porque
los tres estn fuertemente entrelazados.

6.2 Atributos

Los atributos son, en el modelo conceptual, los elementos primitivos y

alfanumricos, como la fecha, el dinero, nmero, cadena, intervalo, etc.
Aunque la mayora de los lenguajes de programacin permiten atributos,
que se definen como estructuras de datos como listas, matrices, conjuntos,
rboles, etc., no es aconsejable en el modelado conceptual porque esas
estructuras son mejores modelada como asociaciones, como se explica en
los siguientes secciones.

Los Conceptos complejos (clases) tampoco deben ser utilizados como

atributos de otros conceptos (aunque, de nuevo, los lenguajes de
programacin lo permiten). Por ejemplo, un libro no debe ser un atributo de
una orden. Si existe una relacin entre los libros y las rdenes, entonces,
una asociacin se debe utilizar en su lugar, porque los libros y las rdenes
son conceptos complejos. Una excepcin a esta recomendacin se produce
cuando se utiliza un tipo primitivo (Seccin 6.2.5) o la enumeracin (Seccin
6.2.4) para etiquetar un atributo; tipos primitivos y enumeraciones se
definen como clases estereotipadas, pero no se comportan como los
conceptos. Se utilizan como tipos de atributos. Por ejemplo, una fecha est
compuesta por partes como ao, mes y da, sin embargo, una fecha de
nacimiento se considera un atributo de una persona, no un concepto
complejo asociado a una persona. Los atributos en UML siempre se
representan dentro de una clase, como se muestra en la Figura 6.2, donde
la clase Cliente tiene los atributos: nombre, DNI, domicilio y telfono.

FIGURA 6.2Atributos representados dentro de una clase.

6.2.1 Tipos de atributos

Los atributos pueden tener un tipo, aunque esto no es obligatorio para el

modelo conceptual. La Figura 6.3 presenta una versin de la clase de la
Figura 6.2 con atributos con tipos. Los Tipos en modelos conceptuales,
tienen el mismo significado que tienen en los lenguajes de programacin. En
la Figura 6.3, tenemos el tipo clsico Cadena, y los tipos primitivos definidos
por el usuario IDnumber y PhoneNumber. Cuando un atributo se define por
reglas de formacin, como en el caso de id y phone, es recomendable
definir un tipo primitivo especialmente para l, como se hace en la Figura
6.3. La direccin es algo especial. Es un atributo o un concepto complejo?
Es simplemente una cadena o un concepto complejo compuesto de calle,
cdigo postal, nmero, ciudad, etc.? Este caso, como muchos otros, se
decide mediante el anlisis de las necesidades de informacin de los
usuarios. Si las direcciones se utilizan slo para imprimir sobres y enviar
correo, entonces se comportan simplemente como cadenas, y pueden ser
representados como atributos con tipo como cadenas. Sin embargo, si se
utilizan las direcciones para calcular distancias y rutas, o si se utilizan para
agrupar a los clientes que viven en el barrio, entonces, se comportan como
conceptos complejos y deben ser modelados como un tipo primitivo.
Adems, si tienen una estructura de asociaciones entre ellos, entonces
deben ser modelados como conceptos complejos.

FIGURA 6.3Atributos con tipo.

6.2.2 Los valores iniciales

Un atributo puede ser declarado con un valor inicial, es decir, cada vez que
se crea una nueva instancia del concepto, ese atributo recibir
automticamente un valor inicial definido, que se puede cambiar ms
adelante si es necesario. En el sistema Livir, una orden puede ser creado,
por ejemplo, con un valor total que es inicialmente cero. Esta puede ser
definida en el diagrama de clases, como se muestra en la Figura 6.4. La
definicin de un valor inicial para un atributo tambin se puede crear con el
uso del lenguaje de restriccin de objetos (OCL) (Object Management Group,
2010).

FIGURA 6.4 Una clase que muestra un atributo con un valor inicial

Cada expresin OCL debera ser declarado en un contexto que corresponde

a una clase. La mayora de las declaraciones OCL tambin tienen un
subcontexto, que consiste en una propiedad de clase, es decir, un atributo,
rol de asociacin, o incluso un mtodo. Al declarar el valor inicial para el
atributototalValue en la clase Order, el contexto es Order y el subcontexto
es totalValue. Por lo tanto, la expresin OCL se inicia como:

Context Order::totalValue

Opcionalmente, el tipo de atributo puede ser adicionado:

Context Order::totalValue:Money

Con el fin de indicar que la expresin OCL es la definicin de un valor inicial

para un atributo, el clausula init: se utiliza, seguido de la expresin que
cuando se evala produce el valor inicial para el atributo. Como en el
ejemplo el valor inicial es la constante 0, la expresin puede definirse como
Contexto Pedido ::totalValue: Money init: 0 La expresin tambin puede
simplificarse omitiendo el tipo del atributo: Contexto Orden :: totalValue init:
0 Un atributo puede tener su valor inicial definido por expresiones ms
complejas. Ms tarde, se presentan ejemplos de expresiones OCL ms
complejas, que puede ser utilizado para inicializar atributos con valores
producidos por operaciones matemticas y lgicas.

6.2.3 Los atributos derivados

Los atributos derivados se entienden aqu como valores alfanumricos

derivados. Si un "atributo derivado" se refiere a objetos o a estructuras de
datos, se les llama asociaciones derivadas (Seccin 6.4.3). Los atributos
derivados difieren de los atributos normales, ya que no se pueden cambiar
directamente. En otras palabras, son de slo lectura.

Un atributo derivado es calculado y debe ser definido por una expresin. En

el diagrama de clases, un atributo derivado puede ser representado por una
barra (/) que precede al nombre de atributo (y tipo), seguido por la
expresin (OCL) que define el atributo. La Figura 6.5 muestra un ejemplo en
el que el beneficio se define como la diferencia entre el precio y el costo.

FIGURA 6.5 Una clase que muestra un atributo derivado.

Los atributos derivados tambin pueden ser definidos por las expresiones
OCL. 1 La expresin de nuevo tiene una clase como contexto y un atributo
como subcontexto. Esta es seguida por la palabra derive: esto indica que la
expresin que sigue, define cmo calcular el valor del atributo derivado. La
expresin del ejemplo de la Figura 6.5 define beneficio usando los valores
de otros dos atributos de la misma clase: beneficio=precio - costo.

Por ahora, podemos considerar que las expresiones OCL despus de las
clusulas tales como init: y derive: comienzan con una expresin que
denota una instancia del contexto de la clase. Esa instancia se conoce
por la palabra self.

1 No necesariamente, porque muchos analistas pueden elegir el lenguaje natural u

otros lenguajes de especificacin. Sin embargo, como OCL es parte del paquete de
UML, es aconsejable utilizarla.

La notacin self.property permite acceder al valor de una propiedad

(atributo, asociacin rol, o mtodo) que pertenece al objeto. Por ejemplo,
en el contexto de la clase Book, la expresin self.cost denota el valor del
atributo costo de una instancia de Libro.
Por lo tanto, la expresin OCL que define el valor derivado del atributo
profitdela clase Libro es

Context Book::profit
derive:
self.price-self.cost

En OCL es posible omitir la expresin self cuando el contexto no es ambiguo.

En el ejemplo anterior, la expresin podra simplificarse a

Context Book::profit
derive:
price-cost

En el contexto Libro, el precio y el costo no pueden ser otra cosa que los
atributos de libro. Entonces, la palabra self puede omitirse de la expresin.

Los atributos derivados no se pueden actualizar directamente. En la clase

Libro de la Figura 6.5 slo los atributos de cost y price se pueden actualizar
directamente. El atributo derivado profit es de slo lectura: se calcula
como el resultado de su expresin definida. 2
2 En este punto, algunos lectores que tambin son programadores podran estar
preocupados por los problemas de rendimiento con el cdigo que se utilizar para aplicar
atributos derivados. Segn ellos son por definicin, "calculados", parece una prdida de
tiempo de procesamiento repetir los clculos si los valores originales de costo y el precio no
cambian. Sin embargo, los lectores pueden mantener la calma porque los mecanismos de
optimizacin de cdigo estn disponibles para los atributos derivados. Por ejemplo, el valor
calculado para una atributo derivado se puede mantener en la memoria cach y se vuelve a
calcular cuando se cambia uno de sus componentes. Por ejemplo, beneficio tiene que
volverse a calcular cuando la instancia de libro cambia los valores de precio o costo.

6.2.4 Las Enumeraciones

Las enumeraciones son un equilibrio entre los conceptos y atributos. Son

bsicamente cadenas, y se comportan as. Pero hay un conjunto predefinido
de cadenas vlidas que constituye el dominio de enumeracin. Por ejemplo,
un da del calendario slo puede tener un valor en un conjunto de siete
posibilidades: domingo, lunes, martes, mircoles, jueves, viernes, y
sbados. Por lo tanto, un atributo definido como CalendarDay (tipeado con
esa enumeracin) slo asumira uno de los siete valores.

Las enumeraciones pueden aparecer en diagramas UML como clases

estereotipadas. Se sugiere que las enumeraciones que son de dominio
independiente no se coloquen en el mismo diagrama que contiene el
modelo conceptual, sino en un paquete especial destinado a contener las
enumeraciones, como se muestra en la Figura 6.6, porque las
enumeraciones independientes del dominio (como CalendarDay) son muy
reutilizables de aplicacin en aplicacin. Slo las enumeraciones de dominio
especfico se guardarn junto con las otras clases del modelo conceptual
para que la gente pueda ver su significado ms fcilmente.
En la Figura 6.6, el atributo validity de la clase Offer puede haber asignado a
este, uno de los siete valores posibles para la enumeracin CalendarDay.

FIGURA 6.6 Definicin y uso de una enumeracin

Las enumeraciones pueden ser consideradas clases estereotipadas. Aunque

pueden tener asociaciones y atributos propios, el analista no se anima a
utilizar estas caractersticas, ya que simplemente podran convertir la
enumeracin en un concepto complejo y probablemente perdera
reutilizacin. Por ejemplo, considere la enumeracin CalendarDay. Se trata
simplemente de una lista de siete nombres. Supongamos ahora que el
analista aade algunos atributos a la enumerationCalendarDay, tales como,
por ejemplo, las horas de trabajo. Entonces, por ejemplo, de lunes a viernes
puede tener horas definidas 09 a.m a 5 p.m., los sbados de 9 am hasta el
medioda de trabajo, y el domingo puede no tener las horas de trabajo en
absoluto. Diferentes aplicaciones pueden definir las horas de trabajo de una
manera diferente. En este caso, cul es la diferencia entre esta
enumeracin y un concepto complejo, ya que tambin tiene atributos y,
posiblemente, asociaciones e incluso los mtodos ms adelante? En lugar
de crear atributos o asociaciones para una enumeracin sera aconsejable
crear un nuevo concepto complejo que acomode la enumeracin y los
dems atributos. En el ejemplo, un nuevo concepto da de trabajo se podra
crear con dos atributos: das calendario (todava una enumeracin), y las
horas de trabajo (atributo normal como se explica ms arriba). Por lo tanto,
enumeraciones que son pensadas a incorporar funcionalidades adicionales
deben mantenerse fuera de la estructura e incluirlas en clases normales.

Para seguir siendo reutilizable, una enumeracin no debe ser capaz de

acceder a otra clase a travs de una asociacin, pero cualquier otra clase
debe ser capaz de acceder a la enumeracin. El hecho de que en la Figura 6
Offer tenga un atributo marcado con CalendarDay permite a la clase normal
Offer acceder a la enumeracin CalendarDay, pero no viceversa. Esto
mantiene la enumeracin desacoplada de las clases que la utilizan y por lo
tanto es reutilizable.

Los valores de enumeracin en OCL pueden ser representados por el

nombre de enumeracin seguido por "::" y el nombre del valor, como, por
ejemplo, CalendarDay :: martes.

6.2.5 Los tipos primitivos

El equipo puede y debe definir los tipos primitivos cuando se relacionan con
los atributos que tienen reglas de formacin, como en el caso del ISBN. Los
tipos primitivos pueden definirse como clases estereotipada <<primitive>>
como se muestra en la Figura 6.7.

La clase ISBN, que est estereotipada de tal manera, es un TYPE que se

puede utilizar para definir atributos. No es un concepto complejo como el
libro, los clientes, etc. tiene un valor con acceso pblico (marcado con "+"),
y un predicado de validacin que es privado (marcado con "-"), lo que
significa que se puede acceder slo por mtodos dentro de la propia clase.
Eso predicado se puede llamar para verificar si el valor de ISBN es vlido o
no, teniendo en cuenta su regla de formacin. 3

3 La Regla de formacin del ISBN se explica en http://www.isbn.org/standards/home/isbn/us/isbnqa.asp.

Ese predicado puede ser utilizado en el constructor (el mtodo que crea
instancias de la clase) para garantizar que slo los nmeros ISBN vlidos
son creados. Recuerde que las clases conceptuales no tienen mtodos, pero
los tipos primitivos no son parte del modelo conceptual. Son, componentes
de bajo nivel reutilizables definidos por el usuario.

FIGURE 6.7 Ejemplo de un tipo primitivo.

Aunque el valor del tipo primitivo tiene acceso pblico que est
normalmente aceptado a ser inmutable. Eso significa que el valor del tipo
primitivo puede definirse slo en tiempo de la creacin, y no se actualiza
despus. Esto es para que sea coherente con la idea de elementos de datos
primitivos como constantes, y no como objetos. Los objetos pueden cambiar
su estado interno, y las constantes normalmente no lo hacen. 4

4 Algunos lenguajes como Smalltalk permiten constantes para cambiar su valor en tiempo de
ejecucin, pero esto no suele ser el caso, y no se recomienda para la mayora de
aplicaciones.

Algunos tipos primitivos, tales como Date y Money, ya estn disponibles en

algunos lenguajes de programacin y sistemas de gestin de base de datos.
Otros tipos no tan comunes, como el ISBN, cdigo postal, los nmeros
impares, etc., se pueden crear.

La regla de formacin de tipo primitivo debe definirse sintcticamente, es

decir, mediante la evaluacin de expresiones que no necesitan consultar los
datos gestionados por el sistema. Si una norma de la formacin depende de
consultar los valores de atributos o de asociacin, entonces no es,
probablemente, un tipo primitivo, sino una clase normal. Por ejemplo, la
regla de formacin de los nmeros primos se puede comprobar sin consultar
objetos y asociaciones, pero un nombre de cliente registrado no puede ser
un tipo primitivo, porque para comprobar si una cadena es un nombre de
cliente registrado, es necesario consultar los nombres existentes de los
clientes actuales. Un tipo primitivo generalmente es independiente de la
aplicacin, es decir, su significado generalmente es independiente del
sistema o proyecto que est desarrollando. El ISBN tiene el mismo
significado y la norma de la formacin en cualquier dominio de aplicacin
que lo utiliza. Conceptos como cliente, libro, y la Orden pueden tener
diferentes definiciones en diferentes aplicaciones y no pueden por lo
general ser reutilizados sin algn esfuerzo de refactorizacin. Sin embargo,
los tipos primitivos suelen ser 100% reutilizable, sin necesidad de ajustes o
modificaciones.

6.3 Conceptos

Los conceptos son ms que los valores alfanumricos. Tambin son ms que
un montn de atributos, porque llevan significado y pueden estar asociados
entre s. Modelado conceptual puede comenzar con los conceptos y las
asociaciones solamente, como se muestra en la seccin 3.6, es decir, los
atributos no son necesarios de inmediato. Sin embargo, cuando se examina
en detalle, un concepto por lo general contiene un grupo coherente de
atributos.

6.3.1 Atributos nicos

Se supone que las diferentes instancias de un concepto son distinguibles

entre s slo por el hecho de que fueron creados de forma independiente.
Este no es el caso con los tipos primitivos. Dos fechas, tales como
05/03/2013 y 05/03/2013, son los mismos. Sin embargo, dos clientes con
nombre John Smith no son necesariamente la misma persona. Algunos
lenguajes de programacin de hecho utilizan dos predicados de
comparacin, uno para comprobar si dos objetos son iguales (tienen los
mismos valores para sus atributos) y otra para comprobar si son idnticos
(que comparten el mismo espacio en la memoria).

Diferentes instancias son por lo tanto siempre distinguibles entre s, pero,

adems, pueden tener atributos que son nicas para ellos. Una vez que un
atributo ha sido estereotipado como <<unique>>, dos instancias del
concepto no pueden tener el mismo valor para ese atributo. Un ejemplo de
un atributo nico es el ISBN para los libros, que es nico para cada libro
(Figura 6.8), mientras que los otros atributos pueden tener valores idnticos
para diferentes libros.

Atributos nicos no deben confundirse con las claves principales, <<pk>>.

Las claves principales se utilizan sobre todo para el diseo de bases de
datos para proporcionar una identificacin nica para una instancia. Pero
<<unique>> y <<pk>> no son idnticos, ya que un concepto puede tener
slo una clave principal, pero ms de un atributo nico.

Atributos nicos estn ms cerca de la idea de claves candidatas en las

bases de datos relacionales (fecha, 1982).

FIGURA 6.8 Clase que muestra un atributo estereotipado como << nica >>

6.3.2 Clase de Control de Sistema

Por lo general, se espera que el modelo conceptual sea un grafo conectado,

es decir, cada concepto tiene una ruta (una secuencia de asociaciones) que
conecta a todos los dems conceptos. Cuando eso no es el caso, se supone
que algo falta, es decir, asociaciones o conceptos importantes no se han
descubierto todava.

Aunque algunos autores se oponen a ella, un concepto que representa al

sistema como un todo (en nuestro ejemplo Livir) puede ser til en el modelo
conceptual si se toman algunas precauciones. En primer lugar, que el
concepto debe ser declarado como Singleton, 5 y en segundo lugar, no debe
tener atributos, siendo slo una clase de control. Esta clase se corresponde
con el controlador del sistema o de controlador fachada, ya mencionado
en el Captulo 5, no representa ningn dato; slo sirve como punto de
referencia para agregar asociaciones con otras clases, como se ve en las
siguientes secciones. Todos los conceptos estn asociados directa o
indirectamente a la clase controlador con el fin de ser accesible por la
aplicacin.

5 Un patrn de diseo que indica que una clase con una sola instancia puede ser accesible a
nivel global.

La clase controlador del sistema puede ser estereotipada con <<control >>
o dibujada usando (1994) el icono de Jacobson, como se muestra en la
Figura 6.9.
Figura 6.9 Una clase controlador de sistema

En el captulo 9, las ventajas de utilizar la clase controlador se explican en

detalle. Hay algunas situaciones que estn muy bien modelados en las
asociaciones de la clase de control.

6.4 Asociaciones

Cuando los conceptos complejos estn relacionados, se dice que hay una
asociacin entre ellos. Las asociaciones suelen ocurrir slo entre dos
conceptos, pero tambin se pueden definir entre tres o ms conceptos.
Tambin puede haber asociaciones reflexivas entre instancias de la misma
clase. Por ejemplo, la asociacin que une a los padres a hijos se define como
una asociacin reflexiva de persona a persona.

Cuando las clases estn asociadas, entonces sus instancias pueden estar
enlazadas. Por ejemplo, una orden est enlazada a los libros que se orden,
y tambin al cliente que crea la orden. Un pago, si es que existe, est
vinculado a un orden en el ejemplo de la librera.

Las asociaciones pueden ser difciles de identificar en los textos de casos de

uso, sobre todo porque a veces decidir si algo es un concepto o asociacin
puede ser borrosa. Por ejemplo, es una reserva de libros una asociacin
entre un libro y un cliente? O es un concepto? Si se considera un concepto,
cules son sus propias asociaciones?

Por otra parte, los casos de uso de texto de a menudo mencionan las
operaciones que no son exactamente asociaciones estticas. Las
operaciones como comprar de libros, o hacer una reserva, son
transformaciones dinmicas sobre datos. Podran producir conceptos
para representar su existencia, pero por lo general representarlas como
asociaciones no son adecuados. Es necesario tener en cuenta la diferencia
entre las asociaciones (esttica) y operaciones (dinmicos):

Una asociacin es una relacin esttica que pueda existir entre los
conceptos complejos, complementando la informacin acerca de ellos en
un momento dado (una instantnea de su estado), o se refieran a la
nueva informacin asociativa (por ejemplo, vecino o los padres / hijos).
Una operacin es el hecho de acceder y transformar la informacin
existente.

Como una descripcin de un proceso dinmico, un caso de uso textual esta

por lo general est lleno de referencias explcitas a las operaciones, pero las
asociaciones tienen por lo general que inferirse del texto.
En un concesionario de automviles usados hay gente que compra carros de
otras personas. Cuando alguien compra un carro est realizando una
operacin. Esa operacin cambia los vnculos entre los objetos: un enlace
propietario deja de existir, mientras que otro se crea en su lugar. No sera
apropiado representar una operacin como una asociacin, como se
muestra en la Figura 6.10.

FIGURA 6.10 Una operacin inadecuadamente etiquetada como una

asociacin.

Por qu no es la interpretacin adecuada? Porque comprar no es un estado

de la informacin, es una transicin entre estados.

El estado de la informacin sobre los carros y la gente en este caso es la

propiedad: a determinada persona posee un carro o no. Esto se puede
representar como una asociacin entre la persona y carro (Figura 6.11).

FIGURA 6.11 Representacin de una asociacin esttica entre dos

conceptos.

Sin embargo, hay diferentes maneras en que la gente y el carro se pueden

asociar, adems de la propiedad. Una persona puede ser pasajero de un
carro, o su conductor, o la asociacin puede representar simplemente que a
alguien le gusta un carro determinado. Para eliminar esas ambigedades, es
conveniente en muchos casos utilizar un nombre de funcin en uno o ambos
extremos de asociacin con el fin de indicar qu papel juega una clase. Los
nombres de los roles no estn asignados a la asociacin en su conjunto, sino
a sus extremos. Por lo tanto, una asociacin binaria tiene dos nombres de
roles: uno para cada clase participante. En la Figura 6.12, por ejemplo, una
persona est en el rol de propietario relacionada con un carro y un carro
pertenece al rol flota de una persona. Diferentes roles pueden ser
representados por diferentes asociaciones, como se muestra en la Figura
6.13.
FIGURA 6.12 Una asociacin con nombres de roles

FIGURA 6.13 Mltiple asociaciones entre los mismos conceptos.

Cuando un nombre de rol explcito falta en el diagrama, se supone que el

nombre de la clase (no capitalizados) es el nombre de rol por defecto. En el
caso de la Figura 6.13, un carro tiene relacionadas dos roles de las personas:
propietario y conductor. Desde el punto de vista de una persona, hay dos
roles para los vehculos: la flota, que corresponde a los carros que una que
determinada persona posee, y un rol predeterminado de nombre carro, que
corresponde al carro que una persona conduce.

Segn la especificacin UML, las asociaciones tambin pueden tener

nombres (Figura 6.11 presenta un ejemplo), que se colocan en el centro del
borde que une las clases. Sin embargo, este tipo de nombre, adems de ser
difcil de dar (analistas novatos utilizan para llenar sus diagramas con una
gran cantidad de asociaciones con la etiqueta "tiene" o sinnimos), no
tienen mucho uso prctico.

Puede ser ms fcil y ms til trabajar con nombres de roles en lugar de

nombres de asociaciones. En la prctica, se puede ignorar el hecho de que
las asociaciones pueden tener un nombre. Los modelos conceptuales
pueden ser perfectamente claro con nombres de roles que sustituyen
nombres de asociacin. Nombres de roles son ms fciles de dar, ya que
definen las posibilidades de navegacin entre conceptos y son tiles
tambin para dar nombre a los elementos de cdigo de programacin
derivados tales como las variables que representaran la asociacin cuando
se genera el cdigo. Si por algn medio el nombre de la asociacin sigue
siendo necesaria, siempre es posible crearlo mediante la composicin de los
nombres de rol; lo contrario no es cierto. Por ejemplo, una asociacin entre
un libro y un cliente podra ser llamado book2customer si realmente
necesita tener un nombre (por ejemplo, para fines de referencia).

A veces, puede ser interesante mantener la informacin sobre operaciones o

transacciones que se realizaron. Por ejemplo, podra ser til para el sistema
de ventas de automviles almacenar informacin sobre las transacciones de
venta, por ejemplo, fecha, valor, etc. En este caso, la informacin acerca de
la transaccin est representada en el diagrama como un concepto
complejo (Figura 6.14), y representa la forma esttica de la operacin que
se realiz.
FIGURA 6.14 Una transaccin representada como un concepto.

En este caso, la transaccin se representa como un concepto, mientras que

sus asociaciones representan las relaciones estticas entre conceptos.

6.4.1 Multiplicidad del Rol

En un modelo conceptual, es fundamental saber cuntos elementos acepta

un rol. Por ejemplo, en la asociacin entre Persona y Carro con nombre de
rol conductor en la Figura 6.13, Cual es la cantidad de autos que puede
conducir alguien? Cuntos conductores pueden tener un carro?

La respuesta depende de un estudio de la naturaleza del problema y del

significado real de la asociacin, sobre todo si representa el tiempo presente
o el pasado. Por ejemplo, si la asociacin de la Figura 6.13 representa el
presente, entonces el carro puede tener un solo conductor (uno a la vez).
Pero si la asociacin representa el pasado, entonces es posible que un carro
haya tenido un nmero de conductores que conducan durante diferentes
perodos de tiempo.

Por lo tanto, es fundamental que el equipo decida claramente lo que

significa la asociacin antes de decidir sobre su multiplicidad del rol. Tienen
que recordar que las asociaciones son las restricciones estticas; que
representan lo que puede existir entre las instancias de las clases
asociadas. Por lo tanto, dependiendo del significado de la asociacin,
pueden tener diferentes multiplicidades de rol.

Hay, bsicamente, dos decisiones que se hicieron acerca de la multiplicidad

de un rol de asociacin:

1. Es el rol obligatorio o no? Por ejemplo, una persona debe tener al

menos un carro? Podra un carro tener al menos un conductor o
propietario?
2. El nmero de instancias que pueden estar vinculado a travs del rol
tuene un lmite conceptual definido? Por ejemplo, Hay un nmero
mximo o mnimo nmero de carros que una persona puede conducir o
poseer?

Las respuestas a estas preguntas pueden ser difciles. En cuanto a la

primera decisin, por ejemplo, volviendo al proyecto Livir, se espera que
cada orden debe tener un pago. Pero eso no califica al rol pago de un pedido
como obligatorio, ya que una orden puede existir sin un pago por un perodo
de tiempo. Con el tiempo, cualquier orden se espera ser pagado, pero no
necesariamente pronto. Por lo tanto, este rol no es obligatorio para la orden.
El otro tema delicado se refiere al nmero mximo de elementos que un rol
permite. Fsicamente hablando, el nmero mximo de carros que una
persona puede poseer es el nmero de carros que existen en el planeta
Tierra (el nmero va en aumento, pero se define en un momento dado de
tiempo, incluso si es difcil de contar). Pero a medida que los carros nuevos
son construidos, se pueden comprar. Por lo tanto, aunque hay un lmite
fsico para la funcin de propiedad, no hay lmite conceptual o lgico. Por lo
tanto, el rol debe ser considerado prcticamente sin lmite superior.

La multiplicidad rol en UML est representada por una expresin numrica

donde

El asterisco "*" significa "alguna cantidad", e indica que no hay lmite

superior.
La coma "," significa "o".
Dos puntos ".." significa "hasta".

Los siguientes son ejemplos de los lmites multiplicidad habituales para

modelos conceptuales:

1 exactamente uno

0,1 cero o uno

0,* cero o ms

1,* uno o mas

2..5 dos hasta cinco

2,5 dos o cinco

2,5..8 dos o cinco hasta ocho

Los lmites de multiplicidad que incluyen cero representan roles que son
opcionales para un concepto. Todos los otros lmites son obligatorios.

La Figura 6.15 muestra un ejemplo donde una persona puede tener una
flota con un nmero indeterminado de carros (opcional), y una persona
puede ser conductor de un carro como mximo (tambin opcional). Por otro
lado, muestra que un carro debe tener un nico propietario (obligatorio) y
que puede tener un conductor o no (opcional).

FIGURA 6.15 Ejemplo de asociaciones con roles mltiples

De acuerdo con las leyes de muchos pases, un carro puede tener ms de un

propietario, o puede ser propiedad de una corporacin; en algunas
situaciones un carro tambin puede tener ningn propietario en absoluto. El
modelo conceptual (tal como el de la Figura 6.15) no representa
necesariamente una verdad general, pero las necesidades de informacin
para una aplicacin dada. Para algunos sistemas de informacin que podra
ser obligatorio que un carro, con el fin de ser registrado, tiene un solo dueo
y que este propietario debe ser una persona. En este caso, el modelo
conceptual debe representar la informacin concreta y pragmtica necesita
para ese sistema.

6.4.2 Direccin de Asociacin

Una asociacin en un modelo conceptual debe ser no direccional, es decir,

la navegabilidad de la asociacin no debe todava ser determinada (Booch
et al., 2007). Esto se debe al hecho de que para fines de anlisis, slo es
necesario saber si dos conceptos estn asociados o no; el diseo dinmico
decidir ms tarde sobre la navegabilidad.

Hay, por lo general, poco beneficio a una prematura (antes de diseo

dinmico) definicin de direccin de navegabilidad. Asociaciones
unidireccionales en general tienen las siguientes ventajas sobre los
bidireccionales:

No es necesario definir un nombre de funcin para ambos lados (slo

uno).
Son ms fciles de implementar.

Slo la primera ventaja tiene algn significado para el modelado conceptual,

pero es demasiado dbil como para justificar la toma de decisiones antes de
tiempo.

6.4.3 Asociacin Derivada

Tan tiles como los atributos derivados son las asociaciones derivadas, es
decir, las asociaciones que en lugar de ser representados fsicamente se
calculan a partir de la informacin disponible. Por ejemplo, supongamos que
a menudo es necesario saber qu libros ha comprado un determinado
cliente en el sistema Livir. Como los libros no estn vinculados directamente
al cliente en el modelo conceptual, referirse a esa informacin podra ser un
poco ms complicado de lo esperado. La Figura 6.16 muestra un ejemplo de
cmo un modelo conceptual para Livir podra relacionar libros y clientes
indirectamente a travs de los pedidos y la compra de artculos; en este
caso, el conjunto de todos los libros comprados por un cliente sera referido
como el conjunto de libros vinculados a los artculos vinculados a las
rdenes vinculadas al cliente.
FIGURA 6.16 Un cliente indirectamente asociado a libros.

En comparacin con el modelo conceptual preliminar del Captulo 3, la

Figura 6.16 presenta el concepto Artculo entre Libro y Pedido. Los artculos
son necesarios si el concepto Libro significa el ttulo publicado, no la copia
fsica. En este caso, lo que se ordena es un Artculo, el cual representa a una
o ms copias fsicas de un libro determinado. El libro puede tener su precio
actualizado regularmente, pero un cambio el precio del libro no debe afectar
el precio de los antiguas rdenes. Por lo tanto, el precio de un artculo sigue
siendo el mismo, incluso si el precio del libro fue cambiado.

Tenga en cuenta que con este modelo no existe un vnculo directo entre el
cliente y los libros que ya se ha comprado. La creacin de una nueva
asociacin lineal entre el Cliente y el Libro no sera una buena solucin, ya
que sera redundante con el modelo, segn el conjunto de libros se puede
obtener de forma indirecta. Por otra parte, una nueva asociacin entre el
Cliente y el Libro podra asociar cualquier cliente con cualquier libro, no slo
los que ya fueron comprados por el cliente a travs de sus rdenes. Este
modelo permite la representacin de informacin inconsistente, lo que
requerira algn mecanismo de control (por ejemplo, permitiendo que slo
los libros que fueron comprados puedan ser asociados con el cliente).

Una solucin de modelado para ese caso, cuando es relevante tener acceso
directamente a una coleccin de objetos que ya se pueden derivar de la
informacin existente, es utilizar una asociacin derivada, tal como se
representa en la Figura 6.17.

Figura 6.17 Una asociacin derivada

UML permite asociaciones derivadas a ser navegado en ambas direcciones.

Se supone que ambos roles son derivados. En el caso de la Figura 6.17 el rol
opuesto a Cliente debe ser considerado tambin derivado, aunque si su
nombre de rol por defecto no lo indica en este diagrama.

La multiplicidad de los dos roles de la asociacin derivada de la Figura 6.17

es mltiple ya que navegando en las asociaciones normales se puede
observar que un cliente podra haber ordenado cero o ms libros, y que un
libro puede haber sido ordenado por cero o ms clientes. Por lo general, la
multiplicidad de una asociacin derivada se define por el producto de las
multiplicidades de las funciones que deben ser navegadas para alcanzar el
concepto de destino. Las siguientes reglas pueden usarse para determinar
la multiplicidad:
 El lmite inferior de la multiplicidad derivada es el producto de los lmites
inferiores de los roles en la ruta de navegacin.
El lmite superior de la multiplicidad derivada es el producto de los
lmites superiores de los roles en la ruta de navegacin.

Por ejemplo, si las multiplicidades que se encuentran en la ruta de acceso

son 1 ... 5, 2 .. * y 1, a continuacin, la multiplicidad derivada es 2 ..*
debido a que los lmites inferiores son 1, 2, y 1 (1 *2* 1 = 2), y el lmites
superiores son 5, infinito, y 1 (5 *infinita * 1 = infinita).

Sin embargo, si los filtros se aplican a la definicin de la asociacin

derivada, la multiplicidad resultante puede ser diferente. Por ejemplo, si la
asociacin derivada se define de forma que se vincula a un cliente para el
libro ms caro que ya ha comprado, a continuacin, la multiplicidad
derivada es 1, y no *.

A diferencia de las asociaciones normales que permiten los enlaces entre los
objetos individuales que se agregan y se quitan, una asociacin derivada
slo puede ser consultada (similar a los atributos derivados, que slo se
leen).

Una asociacin derivada puede ser definida tambin por una expresin OCL.
El ejemplo de la Figura 6.17 puede ser definido como

Context Cliente ::orderedBook

derive:
self.order.item.book

Las siguientes observaciones se pueden hacer sobre esta expresin OCL:

El contexto es la clase en el origen de la asociacin derivada (Cliente). El

subcontexto es el nombre de la funcin de la asociacin derivada
(orderedBook).
La clusula derive: se utiliza de manera similar al caso de los atributos
derivados. Qu determina si la expresin est definiendo un atributo
derivado o asociacin es el contexto y el tipo de informacin que es
devuelto por la expresin. Los atributos derivados se definen por las
expresiones que devuelven un alfanumrico, enumeracin, o tipo
primitivo, mientras que las asociaciones derivadas se definen por las
expresiones que devuelven un objeto o una coleccin de objetos
(estructura de datos).

En los lenguajes de programacin orientados a objetos, por lo general la

notacin "." slo se puede utilizar en un solo objeto. OCL, sin embargo,
permite que sea utilizado sobre colecciones de objectos. 7 Si x es una
coleccin, entonces el significado de x.y es la coleccin de y que se puede
obtener como propiedades de x. Por ejemplo, self.order denota el conjunto
de pedidos de un cliente en el ejemplo actual; self.order.item es el conjunto
de elementos vinculados a las rdenes de un cliente determinado; y
self.order.item.book es el conjunto de todos los libros vinculados a los
elementos que estn vinculados a las rdenes que estn vinculados con el
cliente.

7 De hecho, en OCL, incluso un solo objeto se considera una coleccin con un solo elemento.
Esto es equivalente a la nocin natural de un conjunto, pero no a la nocin matemtica,
porque en la teora de conjuntos, un conjunto con un elemento no es el elemento. En OCL un
conjunto con un elemento y el elemento son la misma cosa.

Una asociacin derivada tambin puede ser usada para definir un

subconjunto de objetos de un conjunto de objetos enlazados por la
aplicacin de un filtro. Por ejemplo, imagine que la librera tiene un registro
de los clientes especiales que han comprado por encima de 1.000 dlares
en el valor de los libros. Podemos llamarlos clientes oro. Supongamos
tambin que la clase Customer tiene un atributo derivado VentasTotales con
la suma de todos los pedidos de un cliente. La definicin del atributo
derivado no es importante para el ejemplo y ser ignorada ahora. Una
asociacin derivada entre el Controlador y la clase Cliente puede utilizarse
para modelar los clientes de oro como un subconjunto de los clientes de
Livir. La Figura 6.18 muestra el modelo conceptual parcial para este
ejemplo.

Figura 6.18 Asociacin derivada definiendo un subconjunto de una

asociacin normal

La expresin OCL para esta asociacin derivada tiene como contexto el

controlador Livir mismo, porque est en el origen de la asociacin. La
expresin que define la asociacin derivada tiene a denotar el conjunto de
clientes que han comprado ms de 1.000 dlares, es decir, las instancias de
cliente cuyo valor de VentasTotales es superior a 1,000.

La expresin OCL para obtener un subconjunto de elementos que satisfacen

una expresin booleana dada como este es select. La expresin booleana
se coloca dentro de parntesis, despus del comando select. La expresin
booleana por lo general comienza con una variable de iteracin que en el
caso de la siguiente expresin se llam: aCustomer.

Context Livir::goldCustomer
derive:
self.customer->select (aCustomer|aCustomer.totalSales>1000)

En el caso de esta expresin, la variable de iteracin se llama "aCustomer"

pero podra tener cualquier otro nombre. Este denota cada uno de los
clientes para la evaluacin de la expresin aCustomer.totalSales>1000.
La notacin flecha "->" se usa antes de select en lugar de la notacin .
porque la funcin select se aplica sobre la estructura del conjunto, no sobre
su elementos.8

8 En el caso de un conjunto de personas p, si alguien quiere recibir el conjunto de todas las

edades, que poda escribir pgina. Sin embargo, el tamao del conjunto no es una propiedad
de las personas; es una propiedad de la estructura de conjunto. Por lo tanto, para obtener el
tamao del conjunto de la -.size expresin () debe ser utilizado. Si se escribe como P.SIZE,
entonces estara representando el conjunto de los tamaos de cada persona, no el tamao
de set.

OCL tambin permite que la variable de iteracin a ser omitido si el

contexto de la expresin no es ambigua. Por lo tanto, la expresin anterior
se puede simplificar a

Context Livir: goldCustomer

derive:
cliente->select (totalSales.1000)

Observe que dentro de los parntesis despus de select el contexto es

potencialmente ambigua. All, la propiedad VentasTotales podra referirse
tanto a un cliente y a la instancia de Livir. Lo que nos permite eliminar la
ambigedad es el hecho de que la propiedad VentasTotales slo existe en la
clase Cliente; no existe en la clase Livir. Si exista en ambas clases, a
continuacin, la notacin abreviada no se debe utilizar con el fin de eliminar
la expresin ambigua.

6.4.4 Agregacin y composicin

Algunas asociaciones pueden considerarse ms fuerte que otros en el

sentido de que definen un tipo de objeto que se compone de los dems. Una
casa, por ejemplo, se compone de habitaciones, un libro de captulos, una
carrera de pregrado de los cursos, etc.

Si la asociacin es exclusiva, en el sentido de que un objeto no puede ser

parte de otro objeto, al mismo tiempo, entonces se considera una
asociacin fuerte parte-todo, que se denomina una agregacin compuesto, 9
y se dibuja con un diamante negro en el papel que representa el todo
(Figura 6.19).

FIGURA 6.19 Un ejemplo de agregacin compuesto.

9 "Una asociacin puede representar una agregacin compuesta (es decir, en su conjunto la
relacin/part). Slo las asociaciones binarias pueden ser agregaciones. Agregacin
Compuesta es una forma fuerte de agregacin que requiere ser incluida una instancia de la
parte en a lo sumo un compuesto a la vez. Si se elimina un compuesto, todas sus partes
normalmente se eliminar con l. Tenga en cuenta que una parte puede (donde sea
permitido) ser retirado de un material compuesto antes de que se elimina el compuesto, y
por lo tanto no se puede eliminar como parte del compuesto. Las composiciones pueden
estar relacionados en un grfico dirigido acclico con caractersticas de delecin transitivo; es
decir, la eliminacin de un elemento en una parte de la grfica tambin se traducir en la
eliminacin de todos los elementos de la grfica sub debajo de ese elemento "(Object
Management Group, 2011).

La multiplicidad del role que representa el compuesto (el lado donde esta el
diamante), en el caso de una agregacin compuesta, debe ser de 1 o 0..1, y
nada ms, ya que los compuestos no comparten partes, incluso con objetos
de la misma clase.

La Agregacin Composite indica exclusividad en la asociacin parte-todo.

Cuando esta exclusividad no es obligatorio (la parte puede ser parte de
otros agregados), a continuacin, un diamante blanco se utiliza en lugar, y
la asociacin se denomina agregacin compartida (Figura 6.20)

FIGURA 6.20 Un ejemplo de agregacin compartida.

El diamante blanco indica una agregacin compartida donde la parte puede

pertenecer a diferentes totales al mismo tiempo. En la Figura 6.20, un
artculo determinado debe ser parte de una solicitud, pero tambin puede
ser parte de una venta.

La agregacin compuesta y compartida son asociaciones especiales y debe

ser utilizado con mucha parsimonia, es decir, que se deben utilizar slo
cuando el equipo est seguro de que es el caso de que un objeto es en
realidad parte de otro, y no slo una asociacin normal. Incluso la
especificacin UML (Object Management Group, 2011) afirma que la
semntica precisa de una agregacin compartida vara entre las reas de
aplicacin y modeladores.

Es comn ver a la agregacin y composicin ser abusados en los modelos,

cuando los objetos que no son parte-todo relacionado est unida por ese
tipo de asociacin. Por ejemplo, un cliente no es parte de una orden, si no
por otra razn, sino el hecho de que un cliente es una persona y un objeto
no es una cosa fsica, sino una transaccin. Agregaciones compuestas y
compartidos deben unir elementos de la misma naturaleza: fsica con fsica
y abstractas con abstracto. Un pedido puede estar asociado a un cliente,
pero el pedido no se hace de los clientes.

Hay pocas ventajas reales en el uso de la agregacin en el modelado

conceptual. Esta es otra razn para minimizar o incluso suprimir su uso en
modelos conceptuales. Entre las ventajas es que las partes de agregacin
compuestos o compartidas por lo general tienen atributos que se combinan
y derivan en el conjunto. Por ejemplo, el valor total de la orden es la suma
de sus elementos; el peso de un paquete es la suma del peso de cada libro;
cuando se vende un carro, todas sus piezas se venden tambin; etctera.

Sin embargo, estas preocupaciones suelen aparecer slo en tiempo de

diseo.

6.4.5 Asociaciones n-arias

La mayora de las asociaciones son binarios, es decir, la mayora de las

asociaciones slo tienen dos roles. Sin embargo, hay situaciones en las que
se necesitan asociaciones con tres o ms roles. En UML, estas asociaciones
se pueden representar mediante un diamante que conecta todas las
funciones de la asociacin, como en la Figura 6.21.

FIGURA 6.21 Un ejemplo de una asociacin ternaria.

El ejemplo de la Figura 6.21 se tom de una aplicacin de control de

presupuesto. Cada proyecto puede estar asociado a mltiples partidas
presupuestarias y mltiples ejercicios. Cada ejercicio puede tener un
nmero de partidas del presupuesto por proyecto. Una asociacin ternaria
(es decir, una asociacin con tres funciones) representa esta situacin,
como se ve en la Figura 6.21.

Estos casos no son frecuentes, pero pueden aparecer en un proyecto. Antes

de decidirse a utilizar una asociacin ternaria o n-aria (que puede ser un
dolor de cabeza durante el diseo e implementacin), el equipo debe
verificar si no se confunden con una situacin en la que una combinacin de
asociaciones binarias se debe utilizar en su lugar. Por ejemplo, el caso que
se muestra en la Figura 6.22 no se modela correctamente como una
asociacin ternaria, porque la relacin entre el autor y el editor ocurre slo
cuando el autor publica un libro con una editorial. Entonces, la asociacin
entre el autor y el editor sera una derivada.

FIGURA 6.22 Una asociacin ternaria inadecuada

El modelo representado en la Figura 6.23 es ms preciso que el de la Figura

6.22 para el caso que se discute. Slo en un escenario donde el mismo
autor podra publicar el mismo libro con una editorial diferente y el editor
puede publicar el mismo libro con un autor diferente (!) Habra un caso de
una asociacin ternaria.

FIGURA 6.23 El modelo de la Figura 6.22 correctamente representado con

dos asociaciones binarias

Asociaciones ternarias reales, sin embargo, todava pueden ser sustituidos

por una combinacin de asociaciones binarias. Quizs el enfoque ms
simple de lograr esto es para remplazar la asociacin ternaria (o n-aria) por
un nuevo concepto (clase). A veces, nombrar el nuevo concepto puede ser
complicado, pero se puede hacer. Por ejemplo, el modelo de la Figura 6.21
podra ser sustituido por el que se muestra en la Figura 6.24.
FIGURA 6.24 Modelo donde una asociacin ternaria se sustituye por un
nuevo concepto

Sin embargo, existe una diferencia semntica sutil entre los modelos en las
figuras 6.21 y 6.24. En el caso de la Figura 6.24, puede haber dos o ms
instancias Gastables con exactamente la misma partida presupuestaria,
ejercicio financiero y proyecto. Esto no puede suceder en el caso de la
Figura 6.21. As, por esta simplificacin a tener la misma semntica que la
asociacin ternaria, es necesario complementarlo con un invariante (ver
seccin 6.7).

6.5 Colecciones

Las colecciones simples de objetos que no tienen ningn significado o

estructura particular no deben, en principio, ser representados como
conceptos, sino como asociaciones. Cualquier rol de asociacin ya
representa una coleccin de objetos de la clase asociada. Por lo tanto,
considerando de nuevo el ejemplo de la Figura 6.15, flota es un rol que
asocia un conjunto de carros a una persona. El modelo que se presenta en la
Figura 6.25, es innecesaria y redundante.

FIGURA 6.25 Una sencilla coleccin est representada de manera

inadecuada como clase.

Por lo tanto, a menos que la flota tenga sus propios atributos o asociaciones
(por ejemplo, una persona que tiene mltiples flotas ubicadas en diferentes
lugares) la forma correcta de representar una simple coleccin de objetos es
a travs de un rol de asociacin, no a travs de una clase (Figura 6.26).
FIGURA 6.26 Un modelo ms sencillo para la situacin presentada en la
Figura 6.25.

Por lo tanto, el equipo debe ser consciente de que si la coleccin tiene

atributos o asociaciones particulares, entonces este debe representarse
como un concepto. Por ejemplo, un Pedido est entendido inicialmente
como un conjunto de elementos, pero un Pedido tambin tiene atributos
como la fecha de emisin, valor total, descuento, etc., y asociaciones como
la que tiene con el cliente, que puede tener varios pedidos. En ese caso, la
coleccin es un concepto. Sin embargo, una coleccin sin atributos o
asociaciones particulares es slo una coleccin, y por lo tanto se modela
como una funcin de asociacin.

Los roles de asociacin pueden ser considerados como la representacin de

tipos de datos abstractos (Liskov, 1974) en los modelos conceptuales. En los
modelos de diseo ellos podran tambin representar tipos de datos
concretos. Tipos de datos abstractos se definen nicamente por un
comportamiento, no por la estructura. Aparecen, por ejemplo, en:

La estructura set, en el que los elementos no se repiten y no tienen

ninguna posicin definida.
La estructura bag, en la que los elementos se pueden repetir, pero
todava no tienen una posicin definida.
La estructura de conjunto ordenado, en el que los elementos no se
repiten, pero tienen una posicin definida.
La estructura de secuencia, en la que los elementos se pueden repetir y
tienen una posicin definida.

Los tipos de datos concretos, por otro lado, son implementaciones fsicas
para las versiones abstractas. Por ejemplo, una lista puede implementarse
en muchas formas, tales como una matriz, rbol binario, lista enlazada, etc

En el caso de tipos de datos concretos, adems de comportamiento,

tambin hay una estructura fsica que las define.

6.5.1 Set

Un rol de asociacin, de forma predeterminada, es un set, es decir, una

estructura en la que los elementos no se repiten y donde no existe una
posicin definida por ellos. En la Figura 6.26, la flota es un ejemplo de un
conjunto (set).

Si alguien trata de vincular el mismo carro a la misma persona por segunda

vez, no pasa nada, porque ya pertenece al conjunto.

6.5.2 Conjunto ordenado

Supongamos que un libro que an no est en stock tiene una lista de
personas interesadas en comprarlo tan pronto como est disponible. Si no
se puede asegurar que la cantidad de libros recibidos llenar todas las
rdenes, entonces la manera ms justa para atender a estos clientes es
mediante el establecimiento de una lnea desde la reserva ms antigua a la
ms reciente. Esto requiere que los clientes tengan una posicin en la lnea.

Si el mismo cliente no puede reservar el mismo libro ms de una vez,

entonces es todava una estructura sin elementos repetidos, pero ahora con
posiciones definidas. Esto lleva a la estructura de conjunto ordenado.

En el diagrama, el rol puede ser marcado con la restriccin ordenado {}

para indicar que es una coleccin donde los elementos no se repiten, pero
han definido posiciones, como se ve en la Figura 6.27.

La restriccin ordenada {} en un rol de asociacin significa que los

elementos vinculados en ese rol tienen posicin (primero, segundo,
tercero, ..., ltimo), pero todava no se pueden repetir.

Figura 6.27 Un conjunto ordenado de reservaciones para un libro

6.5.3 Bag

Hay situaciones en las que la posicin de los elementos no importa, pero

cada elemento puede aparecer ms de una vez en la coleccin. Esa
estructura se llama bolsa.

Por ejemplo, uno puede necesitar saber cuntas personas vieron los detalles
de un libro, y puede ser importante tambin saber cuntas veces cada uno
lo ve. No es necesario conocer quienes vieron primero, pero la informacin
sobre el nmero de vista es necesaria. Este es un caso tpico de uso de una
bolsa. Cada vez que una persona ve los detalles de un libro, se aade un
nuevo eslabn en la asociacin que se define como una bolsa. El modelo se
muestra en la Figura 6.28.

Figura 6.28 Un ejemplo de bag

6.5.4 Secuencia

La secuencia permite que los elementos se repitan y tambin se asigna una

posicin a ellos. Por ejemplo, imagina que las personas que compran un
determinado valor en libros renen los requerimientos para recibir un
regalo, pero solo una cantidad limitada de regalos es disponible. Por lo
tanto, una lista de personas que renen los requerimientos para recibir el
regalo puede ser construido y los regalos se distribuir a los primeros
miembros de la lista tan pronto como los regalos estn disponibles. Si
alguien compra de nuevo, ms que el lmite establecido para recibir un
regalo, l o ella va a entrar en la lista de nuevo.

FIGURA 6.29 Un ejemplo de una secuencia

Por lo tanto, en esa estructura la posicin de un elemento es relevante y

cada elemento puede aparecer ms de una vez: esto corresponde a una
estructura de secuencia, como se ve en la Figura 6.29.

La multiplicidad en el lado Livir significa que no todos los clientes estn

calificados para un regalo y que pueden calificar ms de una vez.

La secuencia tiene dos casos especiales importantes. Cuando el primer

elemento a ser eliminado siempre es el ms antiguo de la secuencia, como
en el caso de la Figura 6.29, a continuacin, la estructura es tambin una
cola. UML no define una restriccin para las colas, pero un estereotipo en la
secuencia de restriccin hara el trabajo: {secuencia} << cola >>.

Cuando el primer elemento que se va a quitar es el ms nuevo en la

secuencia, se comporta como una pila, y puede ser estereotipada como tal:
{secuencia} << pila >>. Las colas y las pilas que no repiten elementos
pueden ser definidas, respectivamente, como {ordenado} << cola >> y
{ordenado} << pila >>. Una lista puede tener elementos extrados e
insertados en cualquier posicin. Las colas y las pilas tienen elementos
insertados y removidos slo en posiciones predeterminadas, como se
explic anteriormente, aunque, en algunos casos, la totalidad de sus
elementos puede ser navegada.

Una curiosidad que mencionar ahora es que en el mundo real la mayora de

las colecciones son estrictamente conjuntos y no secuencias, pero aun as,
la estructura de programacin ms utilizada sigue siendo la secuencia, y no
el conjunto, lo que indica una brecha entre la realidad y las estructuras de
datos utilizado en la programacin.

6.5.5 Mapa

Cuando un concepto tiene un atributo nico, un mapa puede ser creado a

partir de ese atributo en el concepto, de tal manera que es ms fcil de
identificar y encontrar instancias especficos del concepto. Por ejemplo,
como el ISBN es nico para un libro, las asociaciones de libro pueden ser
calificados por el ISBN, lo que significa que en vez de tener un conjunto de
libros, la clase origen tiene acceso a un mapa que permite la identificacin
inmediata de cualquier libro si su ISBN se conoce. Figura 6.30 muestra un
ejemplo de asociacin cualificada.

FIGURA 6.30 Un ejemplo de una asociacin calificada representando un

mapa

El pequeo rectngulo en el lado izquierdo de la asociacin en la Figura 6.30

representa un calificador para la clase en el lado opuesto de la asociacin.
Observe que en lugar de "*" el papel de la derecha est ahora limitada por
"0..1"; la asociacin ahora debe leerse de la siguiente manera: "para cada
posible ISBN no hay ms de un libro." Algunos valores ISBN vlidos no
pueden asociarse a cualquier libro, debido a que no se registraron en el
sistema o porque el ISBN, aunque vlida, an no ha sido asignado
simplemente a un libro; Sin embargo, si uno ISBN es tomada por un libro,
ningn otro libro puede compartirlo.

En la prctica, una asociacin calificada sigue siendo una asociacin "para

muchos", pero los objetos que pertenecen al rol se puede acceder por uno
de sus atributos.

El rol en el lado izquierdo (el lado calificador) est marcado con "1", lo que
significa que cada libro tiene un solo ISBN, no menos o ms. Esto tiene que
ser necesariamente cierto, porque un ISBN es nico y no es opcional para la
clase de libro, y por lo tanto, es obligatorio y no permite la repeticin.

El calificador es no slo una manera de acceder a los objetos de una manera

ms fcil. Tambin es una potente herramienta de modelado. Por ejemplo,
considere una situacin en la que una persona puede poseer muchos
telfonos, pero slo uno de cada clase. Cmo nos representamos esto? Un
modelo elegante para esa situacin se muestra en la Figura 6.31.
FIGURA 6.31 El uso de un calificador como una herramienta de modelado.

En el caso de la Figura 6.31 una persona puede tener hasta cuatro

telfonos, pero slo uno de cada clase. Si se aaden ms tipos a la
enumeracin ms tarde, a continuacin, ms telfonos pueden estar
asociados a cada persona. Si el papel en el lado derecho fue de 1 en lugar
de 0..1, a continuacin, una persona necesariamente debe tener cuatro
mviles, a cada uno un tipo diferente. Que el uso de una asociacin
calificada con una funcin obligatoria por lo general slo tiene sentido
cuando el calificador es una enumeracin o un conjunto finito.

En el ejemplo de la Figura 6.30, el calificador es un atributo de la clase

cualificada, y en ese caso se denomina un calificador interna. Por otra parte,
en la Figura 6.31 el calificador no es un atributo de la clase, y se llama un
calificador externo.

6.5.6 Particin

En las figuras 6.30 y 6.31, la multiplicidad 1 o 0..1 en el lado derecho de la

figura significa que la asociacin es un mapa, es decir, para cada valor de la
clave hay a lo ms una instancia de la clase calificada.
Y si en lugar de "1" o "0..1" la multiplicidad fue marcado con "*"? En este
caso, la asociacin dira lo siguiente: "para cada clave hay un conjunto de
instancias de la clase calificada." Por ejemplo, los libros pueden ser
clasificados por gnero. Como muchos libros pueden pertenecer al mismo
gnero, el atributo de gnero puede no ser nico. Pero es posible definir una
particin en el conjunto de libros basados en su gnero, como se muestra
en la Figura 6.32.
FIGURA 6.32 Un ejemplo de una particin

La Figura 6.32 establece que para cada valor particular de gnero hay un
conjunto de libros (con cero o ms elementos). El papel multiplicidad 1 en el
lado izquierdo indica que cada libro tiene un gnero.

6.5.7 Relacin

Ahora, imagine que un libro puede tener ms de un gnero, como, por

ejemplo, la Gua del autoestopista galctico (Adams, 1979), que puede
clasificarse tanto como la ciencia ficcin y humor. Para que representa la
posibilidad de un libro que tiene ms de un gnero en el ejemplo de la
Figura 6.32, que sera suficiente para cambiar la multiplicidad en el lado
izquierdo de la asociacin a * (si un gnero es opcional) o 1 .. * (si es
obligatorio). Adems, el gnero debe ser removido de los atributos del libro,
convirtindose en un partido de clasificacin externa, porque el atributo
gnero debe permitir mltiples valores. LaFigura 6.33 muestra la relacin
resultante.

La relacin de la Figura 6.33 establece que un libro puede tener uno o ms

gneros y un gnero tiene un conjunto de libros asociados. Como un libro
puede tener ms de un gnero, entonces el calificador debe ser
necesariamente externo.
FIGURA 6.33 Un ejemplo de una relacin

6.6 Organizacin del modelo conceptual

La elaboracin del modelo conceptual implica ms que simplemente juntar

conceptos, atributos y asociaciones. Para que el modelo conceptual sea una
representacin confiable y organizada de informacin del mundo real, es
necesario el uso de algunas tcnicas de modelado.

Las principales tcnicas de organizacin de conceptos se pueden distinguir

en tres grupos:

Estructural: Representa las generalizaciones entre conceptos, como

por ejemplo, la generalizacin de CuentaAhorro y CuentaCheque.
Asociativo: Representa los roles asociativos que algunos conceptos
pueden desempear en relacin con otros conceptos, por ejemplo,
siendo Estudiante y Profesor roles que una Persona puede desempear
en relacin con una Escuela.
Temporal: Representa las relaciones entre los diferentes estados de un
concepto, por ejemplo una Orden estando en los estados
AtendiendoPago y Pagado.

Los analistas novatos y a veces incluso los experimentados tienden a pensar

que la nica manera de factorizar informacin es mediante el uso de la
herencia, o generalization.10 Sin embargo, es necesario aplicar un poco de
juicio antes de decidir sobre el uso de tal o cual tcnica. La herencia puede
ser utilizada slo cuando un concepto tiene efectivamente dos o ms
subtipos. Aunque UML permite a una instancia a cambiar su clase, slo unos
pocos lenguajes, como Smalltalk (Goldberg y Robson, 1989), trataron de
implementar esta caracterstica, tal vez porque hay algunas dificultades
inherentes no resueltos asociados al hecho de que una instancia pueda
cambiar su estructura interna sobre la marcha. La mayora de los lenguajes
orientados a objetos ignora esta caracterstica debido a los problemas que
plantea y debido al hecho de que por lo general es innecesaria, porque la
mayora de los comportamientos que podran ser modelados por esta
caracterstica tambin tienen representaciones alternas ms simples. As,
para trminos prcticos, por lo general una instancia no puede cambiar su
clase: si nace como miembro de una clase, va a morir un miembro de la
misma clase.11 A medida que los estudiantes pueden llegar a ser profesores,
no lo hacen calificar como subtipos de personas (la mejor solucin para el
modelado de esta situacin se da en la Seccin 6.6.2).

Otro contraejemplo es Trabajador y Cliente que se modelan como subclases

de Persona. Esto es malo en primer lugar porque nadie nace como un
trabajador o cliente; una persona se convierte en un trabajador o cliente
cuando se asocia a una empresa. Ms que eso, la misma persona puede ser
un cliente o trabajador en ms de una empresa. El uso de la herencia en
este caso creara problemas conceptuales que pueden producir la duplicidad
en los registros y datos de inconsistencia.
Las siguientes subsecciones presentan detalles en los tres enfoques para la
organizacin de conceptos.

10 Slo trate de buscar en Google para las imgenes con las palabras clave "UML" y
"herencia." Usted ver un montn de ejemplos de mal uso de la herencia, como, por
ejemplo, la persona como una generalizacin del estudiante y el profesor.

11 Ms especfico, un objeto es tambin una instancia de todas sus superclases

(Seccin 6.6.1). La idea es que el conjunto de las superclases no debe cambiar
despus que la instancia es creada.

6.6.1 Generalizacin, Especializacin y Herencia

Durante aos, la herencia se consider la caracterstica ms importante de

los lenguajes orientados a objetos. Lenguajes como Smalltalk, se
construyeron sobre una nica jerarqua de clases basadas en la herencia.

Con el tiempo, este nfasis perdi fuerza, porque la herencia no siempre es

la mejor idea para la solucin de problemas de modelado. Hoy en da, la
herencia se considera slo una de las tcnicas que ayudan a factorizar
informacin que de otro modo se repetir en las clases.

La Herencia, en los sistemas orientados a objetos, se produce cuando dos

clases se relacionan a travs de una asociacin especial llamada
generalizacin (o una especializacin, dependiendo de la direccin que
se mire). Una clase que generaliza otra clase es su superclase, y el
especializado es la subclase.

La Generalizacin se debe utilizar cada vez que hay un conjunto de clases

X1,. . ., Xn que tienen diferencias y similitudes comunes, de modo que las
similitudes se pueden agrupar en una superclase X (generalizacin de X1,...,
Xn) y las diferencias mantenidas en X1,. . ., Xn.

La generalizacin tiene una semntica muy diferente de las otras

asociaciones del modelo conceptual. Slo existe entre las clases, no entre
instancias como asociaciones normales. Por ejemplo, si una clase Cliente se
asocia a la clase Pedido por una asociacin normal, entonces las instancias
de Cliente pueden estar asociados a las instancias de Pedido: la asociacin
normal, permite que existan los vnculos. Por otro lado, si una clase
CuentaBanco es una generalizacin de CuentaCheque, entonces cada
instancia de CuentaBanco es tambin una instancia de CuentaCheque
(Figura 6.34). No hay dos instancias a ser vinculados, slo una instancia con
las propiedades definidas en ambas clases. En el ejemplo, cada instancia de
CuentaCheque tiene tres atributos: nmero, limiteSobreGiro y sobregiro. Sin
embargo, no todos las instancias de CuentaBanco son una instancia de
CuentaCheque: la generalizacin es anti-simtrica. Una instancia de
CuentaBanco tiene un solo atributo: nmero.
FIGURA 6.34 Un ejemplo de generalizacin con herencia

Por lo tanto, una de las razones para usar la herencia es cuando hay algunas
propiedades similares (atributos, asociaciones, o mtodos) en diferentes
clases, que se pueden factorizar (agrupar) en una construccin abstracta,
tal como una superclase.

Si la superclase puede tener sus propias instancias, entonces es una clase

normal. Sin embargo, la mayora de las superclases se definen para no
permitir las instancias directas: slo sus subclases pueden tener instancias.
En este caso se conocen como superclases abstractas. Superclases
abstractas se representan en UML mediante una clase con su nombre
escrito en cursiva, o, de forma ms visible, con la restriccin {abstract}
(Figura 6.35).

FIGURA 6.35 Dos clases que se generalizan por una clase abstracta.

En la Figura 6.35, la clase CuentaBanco es abstracta, y por lo tanto no

puede tener instancias directas; slo sus subclases pueden tener instancias.
Las instancias de CuentaCheque tienen nmero, limitesobregiro y sobregiro
como atributos; instancias de CuentaAhorro tienen nmero y tasadeInters
como atributos.

Ambas subclases tambin heredan la asociacin a la clase Cliente, y todas

las instancias de ambas clases deben, por lo tanto, estar vinculadas a una
instancia de cliente.
La Generalizacin no es recomendable cuando la superclase no tiene
propiedades, es decir, no hay atributos, asociaciones, o los mtodos de ella
(Figura 6.36).

Figura 6.36 Situacin en la que no se recomienda la generalizacin, porque

no hay propiedades generalizadas.

La Generalizacin tampoco debe utilizarse cuando las subclases no tienen

12
propiedades (atributos, asociaciones, o mtodos ) que los diferencian unos
de otros como en la Figura 6.37.

Figura 6.37 Situacin en la que no se recomienda la especializacin,

porque no hay propiedades estn especializados en las subclases.

En estos casos, la solucin ideal es utilizar un solo atributo, posiblemente

escrito con una enumeracin, para diferenciar los grupos de instancia de
objetos que tienen las mismas propiedades (Figura 6.38).
FIGURA 6.38 Un modelo ms adecuado para la situacin de la Figura 6.37.

Adems de estas reglas, antes de decidir el uso de la herencia, es

aconsejable verificar si la generalizacin realmente representa una
clasificacin estructural de los elementos, y no una asociacin u
organizacin temporal, como se ve en las siguientes secciones.

12 Los mtodos slo se consideran cuando se modelan las clases de diseo.

Recuerde que las clases conceptuales no tienen mtodos.

6.6.2 Clases de Asociacin

Un tema mal entendido con frecuencia en el modelado conceptual se

relaciona con la definicin de generalizacin entre las clases que no son
realmente subtipos estructurales, sino roles. Por ejemplo, una librera puede
tener dos "tipos" de personas: clientes y trabajadores. Despus de descubrir
que ambos tienen un nombre, direccin, telfono, etc, analista podra
suponer que se trata de dos conceptos que deben ser generalizadas como
Persona.

Pero esa solucin aparentemente simple (Figura 6.39) genera un problema

complicado, porque no son diferentes tipos de personas, sino diferentes
roles que la gente pudiera jugar al relacionarse a una empresa.

FIGURA 6.39 manera inadecuada para representar papeles con

generalizacin.

Por qu es esto un problema? Imagine que un trabajador de la librera

decide comprar libros en su lugar de trabajo.
En este caso el trabajador se comporta como un cliente. Una solucin muy
frecuente aunque no apta para esto es crear un segundo registro para el
trabajador como un cliente, como si fuera una persona diferente. Como
consecuencia, la misma persona tendra dos registros en el sistema: uno
como trabajador y otro como cliente. Esto produce redundancia de datos y
es una fuente de incoherencia de datos, porque, por ejemplo, si el
trabajador ha registrado un cambio en la direccin, el cliente todava puede
mantener la direccin antigua. Como son la misma persona, esta
informacin es inconsistente.
Una solucin ms adecuada es considerar que existe una persona que
pueda relacionarse con una empresa en por lo menos dos maneras: como
cliente y como trabajador. Las propiedades especficas de un cliente (lmite
de crdito, por ejemplo), y de un trabajador (salarios, por ejemplo), seran
las propiedades de las asociaciones, y no de la persona. Para representar
estas propiedades de asociacin, una clase de asociacin debe ser definida
para cada uno, como se muestra en la Figura 6.40.

FIGURA 6.40 Una representacin ms adecuada de roles como clase de

asociacin.

Por lo tanto, cuando el mismo objeto puede desempear diferentes

funciones relacionadas con otros objetos, estas funciones no deben ser
representadas como subclases, sino como clases de asociacin.

Con el fin de decidir qu situacin exige la herencia y que la situacin exige

clases de asociacin, puede ser verificado si los "subtipos" dependen de la
existencia de una tercera clase para tener sentido.

Si el "subtipo" depende de tercera clase, a continuacin, la solucin consiste

en utilizar una clase de asociacin. Por ejemplo, nadie puede ser
simplemente un estudiante; si alguien es un estudiante, entonces ella debe
estar asociada a una escuela o por lo menos a un maestro.
Por lo tanto, no es adecuado crear clases que representan tipos de personas
que en realidad no son subclases sino roles. Los trabajadores, profesores,
estudiantes, directores, clientes, etc, no deben ser subclases de Persona.
Conceptos como estos slo tienen sentido si se relaciona con otros
conceptos como Empresa, Escuela, Departamento, etc. Una persona puede
ser trabajador de una empresa, estudiante en una escuela, etc

La diferencia entre el uso de una clase de asociacin y un concepto (clase)

intermediaria es sutil. La Figura 6.41 muestra un ejemplo de una reserva
que se modela como un concepto intermediario, y la Figura 6.42 es una
versin de esa reserva modelado como una clase de asociacin.

En el caso de la Figura 6.41, una reserva asocia a un cliente a un libro. En el

caso de la Figura 6.42 el cliente y el libro se asocian directamente, y la
reserva, como una clase de asociacin, es una consecuencia de esa
asociacin. Sin embargo, en la Figura 6.41, el mismo cliente puede tener
muchas reservas para el mismo libro (nada en el modelo lo evita), mientras
que en la Figura 6.42 un cliente puede tener slo una reserva para cada
libro. El enlace entre el cliente y el libro puede existir o no; no es un bag. Sin
embargo, si ambas funciones de la asociacin en la Figura 6.42 se marcaron
con {bag}, entonces, un usuario podra tener ms de una reserva para el
mismo libro y el modelo en la Figura 6.42 sera equivalente a la de la Figura
6.41.

Figura 6.41 Una reserva siendo modelada como un concepto intermediario.

FIGURA 6.42 Una reserva est modelada como una clase de asociacin.

El problema de tener diferentes registros para la misma persona, como se

mencion anteriormente, a menudo crea problemas en los sistemas de
informacin. Por ejemplo, un estudiante entra a la universidad y se ha
registrado como tal.
FIGURA 6.43 representacin inadecuada de muchos registros de la misma
persona con la herencia.

Entonces, ella recibe una beca y se crea un nuevo registro. Entonces, ella
trabaja en un laboratorio, y se ha registrado de nuevo. Por ltimo, es
contratada como profesora y se crea un nuevo registro. Ella aparece muchas
veces en los registros de la universidad, como si fuera diferentes personas.
Sus viejos discos se convierten fuera de fecha; direcciones y nmeros de
telfono por lo general slo se actualizan en los registros ms recientes.
Esto sucede porque en estos casos los sistemas suelen utilizar la herencia
(Figura 6.43), o registros completamente separados (Figura 6.44).

Para evitar este problema, como se ha visto antes, la solucin es reconocer

que una persona es siempre la misma. Los roles de la persona en la
institucin cambian y la persona no se convierte en una nueva persona. Por
lo tanto, la solucin ms adecuada para esta situacin es cuando se basan
en clases de asociacin, como se muestra en la Figura 6.45.

FIGURA 6.44 representacin inadecuada de muchos registros de la misma

persona como conceptos separados.
FIGURA 6.45 Representacin de muchos registros de la misma persona
como clases de asociacin.

En la Figura 6.45, si una persona puede desempear el mismo rol ms de

una vez, entonces la multiplicidad en el lado izquierdo de la asociacin debe
ser *.

Una excepcin razonable puede ser admitida si existe un solo tipo de

persona en el contexto del sistema. Por ejemplo, si el sistema slo gestiona
la informacin sobre los profesores y que es el nico rol que una persona
puede jugar en la universidad en el contexto de ese sistema de informacin,
entonces sera ms fcil simplemente crear una clase llamada Profesor, y en
el contexto de ese sistema, el profesor es un sinnimo de persona porque
no hay otro tipo de gente. Lo mismo sucede en el ejemplo Livir, donde se
decidi mantener al cliente como la nica clase que representa la gente, en
vez de transformarla en una clase de asociacin.

6.6.3 Clases modales

Las clases modales son usadas para modelar conceptos con instancias que
pueden cambiar de un estado a otro durante su existencia, cambiar,
posiblemente, la estructura de sus propiedades, incluyendo atributos,
asociaciones y comportamiento. Aunque algunos lenguajes de programacin
permiten instancias a cambiar su estructura, cambiando su clase, esto no se
asume como un principio de modelado debido a que tales cambios pueden
crear problemas estructurales impredecibles.

Incluso si una instancia podra cambiar su clase, la redefinicin de sus

atributos y las asociaciones sigue siendo un problema. Sin embargo, hay
tcnicas de modelado que permiten representar situaciones que
necesitaran objetos que cambian de clase sin necesidad de utilizar esta
caracterstica. La idea no es cambiar la clase del objeto, sino su estado.
Cuando un televisor est encendido no se convierta en un nuevo tipo de TV:
slo cambia su estado.
Tres situaciones cada vez ms complejas relacionadas con el modelado del
estado se pueden identificar:

Transicin estable: Los diferentes estados de un objeto no afectan a

su estructura, sino slo los valores de sus propiedades (atributos y
enlaces).
Transicin montona creciente: A medida que el objeto cambia de
estado slo puede mantener sus propiedades o adquirir otras nuevas.
transicin no montona: 13 Segn el objeto cambia de estado se
puede mantener, adquirir o perder propiedades.

Las soluciones de modelado para las transiciones estables y montonas

crecientes son muy simples. Sin embargo, para el modelado de la transicin
no montona, un patrn de diseo llamado Estado (Gamma, Helm, Johnson,
y Vlissides, 1995) es necesario, como se ve en las siguientes subsecciones.

6.6.3.1 Transicin estable

Con frecuencia, los diferentes estados de un objeto pueden ser

representados por un atributo simple. De hecho, el conjunto de todos los
atributos y enlaces de un objeto define su estado. Por ejemplo, el estado de
un pedido puede ser modelado como un simple atributo de estado
mecanografiado con una enumeracin cuyos valores pueden ser
"atendiendo", "concluido" y "pagado."

Otro ejemplo es el atributo suspendido de la clase Direccin (Figura 6.46). Si

un paquete enviado a una direccin retorna, entonces la direccin se marca
como suspendido (el atributo se cambia a true). Cuando el cliente actualiza
la direccin se cambia de nuevo a false. El valor por defecto para el atributo
suspendido es false. Si el atributo suspendido es cierto, entonces la
direccin no se puede utilizar para las entregas.

FIGURA 6.46 Un concepto con una transicin de estado estable.

La transicin se considera estable porque slo el valor del atributo cambia.

La estructura interna del objeto se mantiene la misma. Esto no sucede con
los dos casos que se presentan en las siguientes subsecciones.

6.6.3.2 Transicin montona creciente

La situacin es un poco ms compleja cuando el concepto puede adquirir

nuevos atributos o asociaciones, segn cambia de estado. Por ejemplo, las
facturas que estn pendientes de pago slo tienen dueDate y dueValue
como atributos. Pero una factura que se paga, adems, tiene paymentDate
y paidValue (Figura 6.47).
13 El caso la disminucin montona se puede considerar aqu tambin (una transicin que
slo puede quitar propiedades de una instancia).

FIGURA 6.47 Un concepto con una transicin montona creciente.

Se dice que la transicin en la Figura 6.47 es montona creciente porque los

nuevos atributos y las asociaciones pueden ser creados por ella, pero no
eliminados. Esto implica que una factura pagada no puede volver a ser de
nuevo una nueva factura.

No sera adecuado modelar esta situacin con la herencia, como se ve en la

Figura 6.48, porque en ese caso, una instancia de NewInvoice debera
transformarse en una instancia de PaidInvoice, o tiene que ser destruido y
creado de nuevo desde cero, y todo sus referencias deben ser
reconstruidas.

FIGURA 6.48 Manera inadecuada para modelar una transicin montona

creciente con la herencia.

Otra solucin que no es muy agradable, pero sigue siendo muy popular,
consiste en crear una clase Factura y permitir que ciertos atributos sean
nulos hasta que la clase cambia de estado, como se muestra en la Figura
6.49. Por lo general, la verificacin de la consistencia de la instancia se hace
en los mtodos de actualizacin. Pero un invariante tambin podra ser
utilizado (como se explica en la Seccin 6.7) para garantizar que ninguna
instancia alcanza un estado no vlido, como, por ejemplo, con un
paymentDate definido y null paidValue.
FIGURA 6.49 Manera inadecuada para modelar una transicin montona
creciente con una nica clase y atributos nulos.

Este modelo todava no es bueno, ya que genera una clase con baja
cohesin, que tiene, en consecuencia, las reglas de consistencia complejas
que deben revisarse con frecuencia. Este tipo de clase es altamente
susceptible a errores de diseo y programacin.

Sera mejor modelar el concepto factura de modo que la consistencia de los

objetos puede verse limitada por la estructura del propio modelo, y no por
reglas externas. Como se trata de una transicin montona creciente,
entonces es posible modelar esta situacin con slo dividir el concepto
original en dos: una que representa la factura, y otra que representa su
pago con las propiedades que se agregaron cuando se produjo el pago.
Estos dos conceptos estn, entonces, conectados por un 1 a 0..1 asociacin
(Figura 6.50).

Con el modelo que se presenta en la Figura 6.50 es imposible que una

factura tenga una fecha de pago definido y valor indefinido pagado, y esto
est garantizado sin realizar ningn tipo de restriccin ms all de sus
atributos o asociaciones.

FIGURA 6.50 Manera efectiva para modelar una transicin montona

creciente.

El estado de una factura es un atributo derivado, que se calcula de la

siguiente manera: si no hay un pago enlazado a la factura, entonces la
factura es nueva; de lo contrario, es pagada. En OCL esa condicin puede
expresarse como:
Context Invoice::state
derive:
if self.payment - > isEmpty() then
InvoiceState::new
else
InvoiceState::paid
endif
La expresin anterior presenta dos nuevas caractersticas OCL:
if-then-else-endif, que es una de las funciones de seleccin de OCL. Si la
condicin despus de if es cierto, entonces la funcin resulta en la
evaluacin de la expresin despus de then; de lo contrario, se traduce
en la evaluacin de la expresin despus de else.
isEmpty(), que es una funcin aplicada a una estructura de coleccion y
devuelve verdadero si la coleccin est vaca o falso en caso contrario.
Es una forma fcil de comprobar si hay algn objeto vinculado a otro
objeto o no.

6.6.3.3 Transicin no montona

Con la transicin no montona, un objeto puede tanto ganar y perder

propiedades a medida que cambia su estado. Afortunadamente, no es
frecuente que un sistema de informacin requiere que cualquier informacin
se pierda. Sin embargo, a veces, que puede ser exactamente lo que se debe
hacer.

Hay muchas formas de concebir y modelar un sistema de reserva de un

hotel, por ejemplo. Uno de ellos consiste en considerar el hospedaje como
una entidad que evoluciona de una reserva en tres pasos:

1. Inicialmente, un cliente potencial hace una reserva que indica los das en
que tiene la intencin de llegar y salir, el tipo de alojamiento, y el
nmero de personas. El hotel ofrece la tarifa.
2. Cuando los cheques de clientes en la fecha de llegada se ha registrado
(puede ser la misma fecha de la reserva o una fecha diferente). El hotel
asigna una habitacin que puede ser diferente del inicialmente
reservado y, si este es el caso, se informa al husped de la nueva tarifa.
La fecha prevista de salida sigue existiendo, aunque se puede actualizar
durante la estancia.
3. Cuando el cliente paga, la fecha prevista de salida deja de existir y la
fecha de salida efectiva se ha registrado, y la factura tiene que ser
pagado.

Este conjunto de estados puede ser modelado durante el anlisis de

negocios con un diagrama de mquina de estados similares a de la Figura
6.51.

FIGURA 6.51 Un diagrama de mquina de estados para modelar un

proceso de hospedaje simple.

Si una reservacin slo adquiere nuevos atributos y asociaciones a medida

que evoluciona a travs de los estados de la Figura 6.51, entonces podra
ser representado por una cadena de conceptos como la que se muestra en
la Figura 6.52.

FIGURA 6.52 modelo posible para reservas como transiciones crecientes

montonas.

Sin embargo, es posible suponer que algunas transiciones de estado pueden

eliminar algunos atributos o asociaciones que no ms tienen significado en
el nuevo estado, como, por ejemplo, las fechas estimadas, que se
reemplazan por las fechas reales, y el tipo de habitacin, lo que har ser
reemplazado por una habitacin real que ya tiene un tipo.
Para representar este tipo de situacin, es necesario utilizar un patrn de
diseo conocido como Estado (Gamma, Helm, Johnson, y Vlissides, 1995).
De acuerdo con este modelo, una clase debe ser separado de sus estados.
Las propiedades que son compartidos por todos los estados se mantienen
en la clase original, y las propiedades que pertenecen slo a uno o algunos
estados se trasladan a los estados respectivos. Estos estados son
especializaciones de una clase abstracta, como se muestra en la Figura
6.53.
En la Figura 6.53, los atributos nrPeople y tarifa existen en cada posible
estado de un alojamiento, y es por eso que estn representados en la clase
Hosting. Las otras propiedades se distribuyen entre los tres estados
posibles:

Reservado: Un hospedaje, adems del nmero de personas, dispone de

llegada estimada y las fechas que salen y el tipo de alojamiento (todava
no una habitacin), del que se obtiene el valor inicial de la tarifa de
alojamiento.
CurrentLodging: Un hospedaje, adems del nmero de personas y tarifa,
tiene una fecha de registro efectiva, fecha estimada de salida, y un
cuarto efectivo asignado. El atributo estimatedArrival y el enlace directo
al tipo de hospedaje, ya no son necesarios y se descartan.
FinishedLodging: Un hospedaje, adems del nmero de personas y
tarifa, tiene registro de fechas de entrada y salida efectivo, y un cuarto
efectivo que le fue asignado. La fecha de salida estimada ya no es
necesario y se descarta.
FIGURA 6.53 transiciones de estado no montona modelados con el patrn
de diseo Estado

Desde el punto de vista de una Habitacin, que puede estar vinculado a lo

sumo un CurrentLodging (0..1), pero puede estar asociado a muchos
FinishedLodging (*). De esta manera, la propiedad temporal de dicha
asociacin tambin se modela, porque la asociacin de un cuarto para
alojamiento puede ser a lo sumo uno en el presente, pero muchos en el
pasado.

6.7 Invariantes

Hay situaciones en las que la expresividad de los diagramas no es suficiente

para representar las reglas que deben ser registrados en el modelo
conceptual. En estos casos, el analista debe utilizar invariantes.

Las Invariantes son limitaciones generales sobre las instancias de las

clases. Algunas limitaciones estn representadas en los roles de asociacin;
por ejemplo, una restriccin que establece que una orden debe tener no
ms de cinco elementos se puede representar como en la Figura 6.54.
FIGURA 6.54 Una limitacin que se puede representar como una
multiplicidad de rol.

Sin embargo, no todas los posible restricciones pueden estar representado

en los roles de asociacin. Considere el modelo que se muestra en la Figura
6.55.

FIGURA 6.55 Un ejemplo de una clase con una invariante.

El totalValue de una orden es un valor derivado en la Figura 6.55. La funcin

de suma en OCL devuelve la suma de los elementos numricos que se
producen para cada uno de los elementos del conjunto. La expresin entre
parntesis despus de suma indica cmo se obtiene cada valor numrico
individuo de los elementos del conjunto. La expresin utilizada para definir
el totalValue en la Figura 6.55 es una abreviatura de

Context Order::totalValue:Money
derive:
self.item->sum(anItem|anItem.subtotal)

Alguien podra tratar de escribir la expresin anterior como

self.item.subtotal -> sum (aSubtotal|aSubtotal) o self.item.subtotal->sum().
Sin embargo, en ese caso, como el elemento del rol es un conjunto y no una
bolsa o secuencia, los subtotales seran tambin un conjunto. Si dos objetos
tienen el mismo valor para el subtotal, entonces parecera slo una vez en
el set y la suma no reflejara las intenciones del modelador.

El subtotal en la clase de artculo es tambin un valor derivado que se

calcula mediante la siguiente expresin:

Contexto de artculo :: subtotal: Dinero

derive:
self.quantity * self.price

El precio del artculo tiene un valor inicial definido como el precio del libro
que est vinculado al artculo:
 Contexto de artculo :: Precio: Dinero
init:
self.book.price

Ahora, si hay una restriccin que establece que ninguna orden puede tener
un valor total superior a 1.000 dlares, no sera posible a que la represente
en el papel multiplicidad, como se hace en la Figura 6.54.

Sin embargo, la restriccin se podra representar mediante el uso de un

invariante como la siguiente:

Context Orden
inv:
self.totalValue <= 1,000

Invariantes pueden aparecer en el diagrama indicado como limitaciones

asociadas a una clase. El invariante mencionado anteriormente se
representa justo debajo del nombre de la clase de pedido en la Figura 6.55.

La declaracin invariante en OCL no tiene un subcontexto; debe ser cierto

para cada instancia de la clase, no para un atributo particular o rol de
asociacin.

Muchos desarrolladores de software, cuando se enfrentan con la necesidad

de utilizar restricciones como invariantes, deciden incorporar estas normas
en los mtodos que actualizan los atributos y vnculos de los objetos. Por
ejemplo, teniendo en cuenta la Figura 6.55, se podra aadir una prueba
para la restriccin al mtodo que aade un nuevo elemento a la orden para
comprobar si el valor total supera los mil dlares; en ese caso, la operacin
se impidi completar.

El problema con este enfoque es que la verificacin se hara slo en ese

mtodo, pero no sera una regla general para todos los mtodos. El
desarrollador sabe la regla ahora, pero qu pasa si otro desarrollador
asume el proyecto ms adelante? Qu pasa con el mantenimiento? Un
desarrollador que cambia el sistema algunos aos ms tarde no sera
necesariamente saber que existe esa regla. Ella probablemente no revisara
el documento de requerimientos (suponiendo que todava existe y se
actualiza), y ella sera potencialmente introducir un error conceptual en el
sistema si se permite que otros mtodos no sigan esa regla.

Por ejemplo, si la revisin se implement slo en la operacin que se suma

un nuevo articulo a un pedido, qu pasa si el artculo ha cambiado el
precio? Qu pasa si el artculo ha cambiado su cantidad?

Por lo tanto, las reglas conceptuales generales que se aplican siempre

deben ser explcitas en el modelo conceptual, y no relegado a las
comprobaciones en el cdigo de programacin. Instancias inconsistentes
pueden ser prevenidas. Si es posible, tales restricciones pueden estar
representados en el diagrama de la estructura; de lo contrario, deben ser
representados por invariantes.
Otro ejemplo, que sucede con frecuencia, es la necesidad de limitar dos
asociaciones que de otra manera seran independientes. En la Figura 6.56,
tenga en cuenta que los estudiantes se asocian a una carrera elegida, cada
carrera tiene cursos, y los estudiantes toman cursos.

Sin embargo, el modelo representado en la Figura 6.56 no garantiza que los

estudiantes elegirn cursos relacionados a su carrera. Segn el modelo, un
estudiante puede tomar cualquier curso, y si eso no es el caso, una
restriccin debe ser aadida al modelo. UML permite limitaciones que se
aaden entre las asociaciones (con el uso de lneas discontinuas). Esta
notacin es una forma alternativa para un invariante.

FIGURA 6.56 Un modelo que necesita una restriccin adicional para ser
consistente.

Para garantizar que un estudiante slo puede tomar cursos relacionados con
su propia carrera un invariante como la siguiente debe ser proporcionado:

Context Estudiante
inv:
self.course.career = self.career

La expresin utiliza una caracterstica de los conjuntos (que no permiten

elementos que se repiten) para verificar que todos los cursos tomados por el
estudiante pertenecen a la carrera del estudiante. La expresin self.career
resulta en la carrera del estudiante (un conjunto con un solo elemento
debido a la multiplicidad del rol de estudiante a la carrera). Por otro lado, los
resultados de la expresin self.course.career en el conjunto de todas las
carreras asociadas a todos los cursos tomados por el estudiante. Si hay
cursos de diferentes carreras, entonces ese conjunto no puede ser igual a
self.career (que tiene un solo elemento).

De lo contrario, si todas las carreras son iguales, entonces el conjunto

self.course.career contendr un nico elemento (porque los conjuntos no se
repiten elementos). Si ese elemento es el mismo que self.career, a
continuacin, el invariante ser verdadera y vlida.

6.8 Construccin iterativa del modelo conceptual

En esta seccin se muestra cmo el modelo conceptual puede ser refinado
con la informacin de los casos de uso expandidos. Inicialmente, se discute
cmo encontrar conceptos y atributos de los textos de casos de uso. A
continuacin, discutimos la forma de identificar las asociaciones del modelo.
Por ltimo, se presenta un ejemplo completo con algunos casos de uso
desde las primeras iteraciones del proyecto Livir, y su contribucin al
modelo conceptual.

6.8.1 Cmo encontrar conceptos y atributos?

El proceso de descubrimiento de los elementos del modelo conceptual

puede variar. Sin embargo, una de las tcnicas ms tiles es mirar el texto
de los casos de uso expandidos o diagramas de secuencia del sistema.

A partir de esos artefactos se pueden descubrir todos los elementos

textuales que con el tiempo se refieren a la informacin que se
administrarn.

Por lo general, estos elementos textuales estn compuestos por nombres

tales como "persona", "orden", "pago", etc, o por expresiones que denotan
sustantivos (conocidos en la lingstica como frases nominales), como la
"autorizacin de pago." Por otra parte, a veces incluso los verbos pueden
representar conceptos, cuando los verbos expresan una accin que
corresponde a un sustantivo, como, por ejemplo, el verbo "pagar", que
corresponde al sustantivo "pago".

El analista debe recordar los objetivos y el alcance del proyecto cuando

busca los elementos del modelo conceptual. No es aconsejable representar
en el modelo conceptual informacin que es irrelevante para el sistema. Por
lo tanto, no todos los nombre, adjetivo, o verbo deben considerarse como
un elemento del modelo.

El analista es responsable de entender cules son las necesidades de

informacin reales del sistema y para filtrar los irrelevantes.

El proceso de identificacin de conceptos y atributos consiste es el

siguiente:

1. Identificar en el texto de caso de uso extendido o en los argumentos de

las operaciones en el diagrama de secuencia de sistema, las palabras o
frases que corresponden a los conceptos que son relevantes para
mantener el registro.
2. Agrupar palabras o frases que se refieren a la misma entidad, por
ejemplo, "compra" y "adquisicin", etc
3. Decidir cul de los elementos identificados son conceptos complejos, y
cuales son meros atributos. Por lo general, los atributos son los
elementos que pueden ser considerados alfanumricos (nombres,
nmeros, cdigos, valores monetarios, valores booleanos, etc),
enumeraciones, o primitivas (fechas, nmeros ISBN, etc).
Aplicando esta tcnica para el caso de uso de la Figura 5.10, se pueden
encontrar los principales elementos relacionados con el caso de uso. La
Figura 6.57 muestra estos elementos subrayados.

Caso de uso 01: Solicitar libros

1. El cliente proporciona palabras clave para buscar libros.

2. El sistema genera una lista de libros para la venta que coincida con las
palabras clave, incluyendo al menos el ttulo, autor, precio, nmero de
pginas, editorial, ISBN, y la imagen de portada.
3. El cliente selecciona los libros de la lista e indica la cantidad deseada
cada uno para cada uno
4. El sistema genera el resumen del pedido (ttulo, autor, cantidad, precio
unitario y el subtotal por cada libro) y el valor total.
5. El cliente acaba la orden.

Excepcin 3a: La cantidad pedida es superior a la cantidad en stock para

uno o ms libros.
3a.1. El sistema informa de las cantidades disponibles para cada libro que
se orden por encima del stock
3a.2. El usuario cambia las cantidades deseadas para cumplir con la
cantidad en stock.
3a.3. Avanza al paso 4.

Excepcin 5a: El cliente no est identificada an.

5a.1. El cliente proporciona una identificacin vlida.
5a.2. Vuelva al paso 5.

Excepcin 5b: El cliente no tiene una cuenta.

5b.1. El cliente se registra a s misma, proporcionando nombre de usuario,
contrasea y direccin de correo electrnico.
5b.2. Vuelva al paso 5.

Excepcin 5c: Ningn libro fue seleccionado para comprar.

5c.1. Vuelva al paso 1.

FIGURA 6.57 Caso de uso con conceptos y atributos candidatos

subrayados.

Incluso si no hay un modelo conceptual preliminar, este caso de uso es

suficiente para identificar algunos conceptos que pertenecen al dominio del
sistema. Si ya existe el modelo conceptual preliminar, a continuacin, el
caso de uso ayuda a perfeccionar el modelo, lo que indica nuevos
conceptos, nuevos atributos, o cambios en la estructura. Para el ejemplo, se
supone que ya existe un modelo conceptual preliminar, que se representa
en la Figura 6.58.
FIGURA 6.58 Modelo conceptual preliminar para el ejemplo actual.

Los trminos identificados en el texto de caso de uso de la Figura 6.57 son,

en orden de aparicin:

Cliente: Una clase que ya est en el modelo conceptual.

Palabra clave: Las palabras clave se utilizan para la bsqueda; no se
consideran en este punto atributos de conceptos complejos (aunque
podran ser, si la historia de bsqueda o las preferencias han de
registrarse).
Libro: Una clase que ya est en el modelo conceptual.
Venta: En el contexto de ese caso de uso y en este punto del anlisis la
"venta" y "orden" podra considerarse sinnimos. Por lo tanto, esta es
una clase que ya est en el modelo conceptual.
Ttulo, autor, precio y nmero de pginas: Atributos de libro. Autor
todava podra considerarse un concepto complejo, si la informacin
sobre los autores es ms complejo que un solo nombre.
Editorial: Una clase que ya est en el modelo. El caso de uso
probablemente se refiere al nombre de la editorial.
ISBN y cubierta de Imagen: Atributos del libro.
Cantidad deseada: No puede ser considerado un atributo del libro, ya
que vara en funcin de la orden. No puede ser considerada como un
atributo de la orden ya sea porque vara dependiendo del libro (puede
haber muchos libros en una orden). La cantidad deseada es, por lo
tanto, un atributo de la asociacin entre un libro y una orden,
representado por un concepto intermediario o por una clase de
asociacin llamado Artculo.
Resumen del pedido: Esto es en referencia a una Orden; no parece ser
un concepto nuevo.
Ttulo, autor (o el nombre del autor), cantidad, precio unitario y el
subtotal: A excepcin de subtotal, todos los atributos han sido ya
 mencionados. Subtotal puede ser un atributo derivado de un Artculo.
Precio unitario es equivalente al Precio, que ya se considera un atributo
del libro. Sin embargo, puede de hecho ser tambin un atributo del
Artculo.
Valor total: atributo derivado de la Orden.
Finaliza la orden: Esto indica una accin que representa un cambio en el
estado de un pedido. Tal vez un atributo sera suficiente para
representar a este estado, pero ms anlisis sera recomendable con el
fin de ver si de terminar un pedido no es una operacin ms compleja
(que de hecho lo es).
Cantidad solicitada: Lo mismo que la cantidad.
Cantidad en stock: Probablemente un nuevo atributo del libro.
Cantidades disponibles: Sinnimo de cantidad en stock.
Identificada: Podra ser esto un estado de un cliente? Quizs no. Se
refiere a si el usuario est conectado o no.
Identificacin vlida: Este pertenece al dominio de seguridad. Sin
embargo, el modelo conceptual, probablemente, puede tener una forma
de identificar a los clientes. Nmeros de identificacin Normalmente
tales como el nmero de Seguro Social se usan para ese propsito.
Cuenta: Esta vez tiene que ver con el inicio de sesin.
Nombre de usuario, contrasea y direccin de correo electrnico:
Dependiendo del tipo de marco de seguridad que se utilizan (o no) estos
pueden ser atributos de un cliente (o atributos de un usuario que se
adjunta a un cliente), o incluso pueden ser completamente dirigida por
el marco de seguridad e ignorado en el modelo conceptual. Por ahora se
quedan como problemas de seguridad, y no se incluyen en el modelo
conceptual.

De la informacin coleccionada anteriormente, el modelo conceptual

preliminar puede ser refinado, y se convertira en la que se muestra en la
Figura 6.59, donde se destacan nuevas clases y atributos.

Tenga en cuenta que un solo caso de uso aadi nueva informacin

significativa al modelo. Esto no es casualidad, ya que este caso de uso se
considera el ms importante en el sistema y por lo tanto el primero que se
detalla en iteraciones. Su complejidad tiene mucho que aportar a la
comprensin de la estructura de informacin que el sistema debe gestionar.
FIGURA 6.59 La segunda versin del modelo conceptual, refinada despus
del anlisis del caso de uso 01: Solicitar libros.

No todas las asociaciones en la Figura 6.59 tienen sus multiplicidades

definidas. El valor por defecto de UML para un papel indefinido de
multiplicidad es 1, pero la situacin en la Figura 6.59 es que las asociaciones
sin multiplicidad definida simplemente no fueron analizadas hasta este
punto y se consideran "por definir."

6.8.2 Conceptos dependientes e independientes

Un concepto es dependiente de otros si necesita ser asociado a los mismos

con el fin de tener sentido, es decir, para representar la informacin con un
mnimo de significado.14 Al mirar la Figura 6.59, se puede ver que una Orden
no tendra sentido a menos que se asocie a un cliente y a un conjunto de
artculos. Sin esas asociaciones, el concepto Orden no tendra sentido. La
orden tambin tiene otras asociaciones, pero son opcionales.

14 Hay un paralelismo entre los conceptos de dependencia y los verbos transitivos.

La frase "Abri" no tiene sentido, porque el verbo necesita un complemento, como
por ejemplo, "Abri la lata."

Un concepto es independiente si tiene un significado incluso sin estar

asociado a otros.15 Por ejemplo, el concepto Editorial puede ser entendida
slo de sus atributos, sin estar asociado a otros conceptos. Las asociaciones
existentes para una editorial son opcionales. Por lo tanto, el concepto
Editorial, en ese sentido, es independiente.

15 Existe un paralelo entre conceptos independientes y los verbos intransitivos. La

frase "Durmi" tiene sentido porque el verbo no requiere un complemento. Sin
embargo, incluso los verbos intransitivos pueden tener informacin suplementaria
(por ejemplo, "Durmi durante tres horas"), como los conceptos independientes
hacen.

Pero, para qu sirve esta distincin? Se discuti en el Captulo 5 que slo

los conceptos ms simples pueden ser gestionados por los casos de uso
CRUD. Conceptos dependientes no deben ser considerados simples en
principio, mientras que los conceptos independientes pueden ser simples,
en principio.

En la Figura 6.59, casi todos los conceptos son dependientes. Por ejemplo,
una entrega depende de un pedido, la confirmacin depende de una
entrega, y as sucesivamente. Slo Editorial, Libro, y Cliente son conceptos
independientes y los candidatos a ser gestionados por los casos de uso
CRUD.

Los conceptos que son administrados por los casos de uso CRUD son
generalmente los que se pueden acceder directamente cuando se recupera
informacin de un sistema. Aunque la adicin de la clase controlador -
fachada para el modelo podra esperar por las actividades de modelado de
diseo (Captulo 9), se puede aadir ahora para indicar que conceptos son
los independientes. En principio, slo los conceptos independientes tienen
enlaces obligatorios a la clase controlador. Estar vinculado a la clase del
controlador significa que las instancias de la clase se pueden acceder
directamente. Por ejemplo, una instancia de libro se puede acceder
directamente por su ISBN.

Sin embargo, una instancia de Artculo no es accesible directamente. Para

acceder a un Artculo uno tiene que navegar de un Libro o una Orden. As, el
Artculo no est vinculado a la clase de control de fachada.

Aunque Libro es una clase independiente, no esta vinculado al controlador,

ya que tiene una asociacin obligatoria a otra clase independiente: la
Editorial. En este caso, ningn libro puede tener acceso a mirar el conjunto
de libros de las editoriales. Si ms adelante se descubre que los libros deben
ser accesibles directamente, independientemente de su editor, o que por
cualquier otro concepto necesita este tipo de acceso, entonces, las
asociaciones al controlador se pueden crear (derivados), segn sea
necesario, pero no se crean de forma predeterminada para todos los
conceptos, para evitar el aumento de acoplamiento entre las clases.

Hay, por lo tanto, dos caminos principales para llegar a la informacin en el

modelo de la Figura 6.60: de un editor, y de un cliente. El resto de
conceptos se alcanzan comenzando en uno de ellos. Ms tarde, como se ha
mencionado, las necesidades de informacin pueden requerir la definicin
de otros caminos. En el captulo 9, vemos que una orden tambin se debe
acceder directamente, debido a que un nmero de las operaciones del
sistema se necesita para obtener una orden por su nmero o fecha,
independientemente de quin es el cliente o lo que los libros estn en l.

FIGURA 6.60 Modelo conceptual refinado con un Controlador Fachada.

6.8.3 Cmo encontrar asociaciones?

Si la informacin relacionada con los conceptos y atributos se encuentra

fcilmente en los textos de casos de uso, las asociaciones no. Como se
mencion antes, los casos de uso indican muchas de las operaciones que
transforman la informacin, pero hay que buscar pistas sobre asociaciones.

As que, cmo podemos encontrar asociaciones entre conceptos

complejos? Hay al menos dos reglas que se pueden utilizar:

Conceptos dependientes (como Orden, Pago, Cancelacin, etc) deben

ser necesariamente asociados a los conceptos que los complementan
(que puede ser dependiente o independiente).
Informacin asociativa, es decir, las asociaciones que no son
obligatorios, pero que complementa la informacin en el modelo (por
ejemplo, "una persona es puede ser propietaria de un auto"), debe estar
representado por las asociaciones.

A veces, aparece informacin asociativa en los textos de casos de uso como

conceptos. Por ejemplo, una orden podra ser una asociacin entre un
cliente y los libros, pero esta es suficientemente compleja y es
representada como un concepto. Como una orden es un concepto
dependiente, existen asociaciones entre esos conceptos y sus
complementos.

Cuando uno afirma que una persona puede ser propietario de un carro, esa
informacin debe ser representada por una asociacin. Muchos
profesionales que trabajan con la programacin, pero no de modelado
podra producir modelos similares a la presentada en la Figura 6.61. Sin
embargo, esto no es adecuado, porque (primero) los atributos no deben
tener conceptos como tipo, y (segundo) el modelo disfraza una asociacin
real.

FIGURA 6.61 Un atributo disfrazar una asociacin

Tambin no es apto para usar claves externas (Date, 1982), como se

muestra en la Figura 6.62, debido a que tambin disfraza asociaciones. Este
error se hace comnmente por los modeladores utilizados para disear las
bases de datos relacionales. Las claves externas no deben ser utilizadas en
el modelado conceptual, ya que son una tcnica de implementacin.

FIGURA 6.62 Una asociacin disfrazada como un atributo de clave externa.

Por lo tanto, cuando dos conceptos complejos estn relacionados entre s, el
constructor a ser utilizado es la asociacin (Figura 6.63).

FIGURA 6.63 Representacin adecuado para la situacin que se muestra en

las Figuras 6.61 y 6.62.

El ejemplo de la Figura 6.63, contrariamente a los otros, respeta una regla

de cohesin que indica que un concepto slo debe contener sus propias
propiedades. A medida que la ID es un atributo del propietario, no debe ser
representado como un atributo de un carro (como en la Figura 6.62). Otra
razn para tener asociaciones no aparentes visibles es ms prctico: es ms
fcil ver qu objetos tienen referencias a otros. Ms adelante (Captulo 9),
se discute cmo se pueden utilizar estas lneas de visibilidad para el diseo
de cdigo orientado a objetos de calidad eficaz y buena.

6.8.4 Ejemplo de construccin iterativa del modelo conceptual

Se mencion antes que el Proceso Unificado es impulsado por los casos de

uso y es de arquitectura centrada. Pero, qu significa esto en la prctica?
Ya hemos visto cmo identificar y detallar casos de uso, y tambin hemos
visto que se pueden utilizar como una fuente de requerimientos para refinar
el modelo conceptual, que es la base para el diagrama de clase de diseo,
una parte importante de la arquitectura del sistema.

La Seccin 6.8.1 mostr cmo el modelo conceptual preliminar podra ser

refinado con la informacin del primer caso de uso detallado (Solicitar
libros).

La aplicacin nuevamente de ese proceso, simulando una segunda iteracin

para el caso de uso 02 Pagar Orden, se descubren nuevos conceptos y
atributos (Figura 6.64).

Caso de uso 02: Pago de Orden

1. El sistema genera el resumen de la orden pendiente (ttulo, autor,

cantidad, precio unitario y el subtotal por cada libro), as como el precio
total de la orden, y una lista de direcciones de entrega registrada para el
cliente.
2. El cliente selecciona una direccin de entrega.
3. El sistema genera la tasa de entrega y la fecha prevista para la llegada, y
una lista de las tarjetas de crdito ya registrados para el cliente (bandera
y ltimos cuatro dgitos del nmero de tarjeta de crdito).
4. El cliente selecciona una de sus tarjetas de crdito para el pago.
5. El sistema enva al respectivo operador de tarjetas de crdito los
siguientes datos: nmero de tarjeta, nombre del propietario, vigencia,
cdigo de seguridad, valor total de compra, el cdigo de la tienda.
6. El operador de tarjetas de crdito aprueba la venta mediante el envo de
un cdigo de autorizacin.
7. El sistema informa al cliente de que se aprob la venta y el nmero de
seguimiento del paquete entregado.

FIGURA 6.64 Flujo principal del caso de uso 02 Pagar libros con conceptos
candidatos y atributos identificados.

Los elementos identificados en este caso de uso son:

Las direcciones de entrega: Como cliente puede tener ms de una

direccin de entrega y como las direcciones se utilizan para calcular los
gastos de envo, que no puede ser representado por un atributo simple,
pero en cambio estn representados por una clase.
La segunda aparicin de la direccin de entrega se refiere a la direccin
especfica asociada a la orden actual. Por lo tanto, una nueva asociacin
se encuentra entre un orden y una direccin.
Tasa de entrega: Atributo de la orden. Pero de donde se obtiene este
valor? Si se analizan an ms los requerimientos que se descubri que
las diferentes ciudades tienen diferentes tasas que dependen
fundamentalmente de la distancia desde la ciudad hasta la sede de la
empresa. As, una nueva clase se crea (Ciudad), que se asocia a la
Direccin, y la tarifa por defecto para cada ciudad se define como un
atributo de esa clase.
Tarjetas de crdito: Nuevo concepto. En caso de ser asociada a un
cliente.
Bandera: Probablemente no un atributo, sino un concepto complejo
asociado a una tarjeta de crdito.
Tarjeta de pago: Una asociacin entre un orden y una tarjeta de crdito
de un cliente.
Operador de tarjetas de crdito: De hecho, es un actor externo; sus
datos pueden estar asociados a la bandera tarjeta de crdito.
Nmero de tarjeta, nombre del propietario, la validez, el cdigo de
seguridad: Atributos de una tarjeta de crdito.
Valor total de Compra: Igual que el valor total del pedido.
Cdigo de la tienda: No es un atributo de la librera, como podra
pensarse. Este cdigo identifica la librera para cada operador de la
tarjeta. Como diferentes operadores pueden proporcionar diferentes
cdigos, este atributo debe estar representado en el concepto de la
bandera de tarjetas de crdito, a menos que se est modelando una red
de tiendas.
Aprobacin: Esto sucede cuando se recibe un cdigo de autorizacin (ver
siguiente punto).
Cdigo de autorizacin: Puede ser considerado como un atributo de la
orden. Pero slo puede existir cuando una tarjeta de crdito ya est
vinculada a la orden. Por lo tanto, estara en mejores condiciones como
un atributo de la asociacin entre la tarjeta de crdito y el orden.
El nmero de seguimiento del paquete entregado: Puede ser un atributo
de la entrega.
Los nuevos elementos se destacan en la Figura 6.65, que es la tercera
versin del modelo conceptual para el ejemplo Livir. Tenga en cuenta que
todava hay algunos conceptos sin atributos y algunas asociaciones se
quedan con multiplicidad indefinida. Esto es porque los casos de uso
analizados para este punto no producir informacin para refinar esos
elementos. Ellos pueden refinarse cuando otros casos de uso se expanden y
su informacin son incorporados en el modelo conceptual.

Obsrvese que slo el flujo principal de este caso de uso se utiliz en el

ejemplo. Flujos alternativos de este caso de uso todava deben ser
analizados e incluidos. Recientemente, Jacobson et al. (2011) han propuesto
el caso de uso de tecnologa 2.0, lo que sugiere especficamente que un
caso de uso debera abordarse en rebanadas, y no como un todo indivisible.

FIGURA 6.65 Modelo conceptual refinado con la informacin del flujo

principal del caso de uso de la segunda iteracin: 02 Pago de orden.

Al menos dos invariantes todava deben aadirse al diagrama de la Figura

6.65 con el fin de evitar la existencia de informacin contradictoria: la
direccin de la orden debe ser una de las direcciones del cliente de la orden
y la tarjeta de crdito utilizada para pagar el pedido debe ser una de las
tarjetas de crdito del cliente. Esos invariantes pueden ser definidos en la
clase Order como

Contexto Orden
inv:
self.customer.address->Includes (self.address)
and
 self.customer.creditCard ->Includes (self.creditCard)

El predicado OCL includes verifica si el objeto recibido como argumento est

incluido en el conjunto. Es equivalente al operador matemticas " ". Por
ejemplo, self.customer.address-> Include (self.address) significa
self.customer.address self.address, es decir, self.customer.address contiene
self.address. Se supone que si el elemento recibido como un argumento es
el conjunto vaco, entonces la expresin es verdadera. Por lo tanto, si la
direccin de entrega y tarjeta de crdito an no se han definido, tampoco se
viola la invariante.

El anlisis del segundo caso de uso ha incrementado el modelo conceptual

con un nmero significativo de nuevas clases y atributos. La idea es que la
cantidad de novedades disminuye a medida que avance las iteraciones,
porque, al final, se abordarn slo elementos CRUDs ya estudiados y los
informes con la informacin que ya deberan estar en el sistema. No se
espera que vayan a aportar datos nuevos al modelo conceptual.

Observe que invirtiendo ese orden dejara para las iteraciones finales la
insercin de muchas clases y atributos, y esto requerira una gran cantidad
de retrabajo en el diseo, y que posiblemente se necesitar una
arquitectura de refactorizacin con el fin de adaptarse a esas necesidades.
Es por eso que es tan fundamental para iniciar el proyecto con los casos de
uso ms complejos y slo ms tarde incorporar los ms simples en la
arquitectura.

6.9 El proceso hasta ahora

6.10 Questions
1. Try to imagine a real world situation where the right structure to be used
is a sequence. Remember that a real sequence allows elements to be
repeated and assigns position to elements. Try not to get fooled by
natural language use of the word list. A grocery list, for example, is
not a sequence, because elements do not repeat and their position in
the list is irrelevant; a student roll call may be organized in alphabetical
order, but again, repetition is not allowed and the order is again
irrelevant although convenient. Thus, those are not real sequences.

2. What is the purpose of the controller class? What is its relation with
dependent and independent concepts?
3. Why should an attribute not be typed with a class name? Why should an
attribute not be used to reference another class?
4. Elaborate a list of concepts and subconcepts (subtypes of the original
concept, as, for example, dog and beagle) from common sense. Then,
try to identify the type of each relation: structural, associative, or
temporal. Try to have at least one example of each type in your list.
5. What is the difference between a normal association, an aggregation,
and a composition?
6. List some examples of data types that could be defined as primitive.