Guia 4

U N I V E R S I D A D D E E L S A LVA D O R
FA C U LTA D D E I N G E N I E R I A Y A R Q U I T E C T U R A Ciclo
ESCUELA DE INGENIERIA DE SISTEMAS

II
I N F O R M AT I C O S
Tecnologa Orientada a Objetos TOO115

Catedrtico: Ing. Elmer Arturo Carballo Ruiz Msc.
Gua de Laboratorio #4
Universidad de El Salvador TOO-115 Gua de Laboratorio #4
Contenido
1. Objetivos ................................................................................................................................. 3
2. Introduccin ............................................................................................................................ 3
3. Diagramas de Clases ............................................................................................................... 4
3.1. Diagrama de Modelo del Dominio ..................................................................................... 4
3.2. Diagrama de Implementacin de Clases............................................................................ 5
4. Clases ...................................................................................................................................... 5
4.1. Estereotipos Estndar para las Clases................................................................................ 9
4.2. Plantilla de Clase............................................................................................................... 12
5. Interfaces .............................................................................................................................. 12
6. Tipo de Datos ........................................................................................................................ 14
6.1. Tipos primitivos ................................................................................................................ 15
6.2. Enumeracin ..................................................................................................................... 16
7. Operacin.............................................................................................................................. 17
7.1. Mtodo ............................................................................................................................. 20
7.2. Operacin Abstracta ......................................................................................................... 21
8. Multiplicidad ......................................................................................................................... 21
8.1. Multiplicidad ..................................................................................................................... 22
8.2. Elemento de multiplicidad ............................................................................................... 23
9. Constraint ............................................................................................................................. 24
10. Asociacin ......................................................................................................................... 26
10.1. Extremo de la asociacin .............................................................................................. 28
10.2. Navegabilidad ............................................................................................................... 29
10.3. Aridad ............................................................................................................................ 31
10.4. Agregacin compartida y compuesta .......................................................................... 32
10.5. Clase asociacin ............................................................................................................ 32
10.6. Link ................................................................................................................................ 33
11. Agregacin ........................................................................................................................ 33
12. Composicin ..................................................................................................................... 36
13. Generalizacin .................................................................................................................. 38
Ing. Elmer Arturo Carballo Ruiz Msc.

2
13.1. Herencia ........................................................................................................................ 38

13.2. Set de Generalizacin ................................................................................................... 40
14. Dependencia ..................................................................................................................... 41
14.1. Usage ............................................................................................................................. 43
15. Abstraccin ....................................................................................................................... 45
15.1. Derive ........................................................................................................................ 48
15.2. Refine ........................................................................................................................ 48
15.3. Trace ......................................................................................................................... 49
________________________________________________________________________________
1. Objetivos
Que el estudiante sea capaz de:
Describir las relaciones entre los distintos elementos de un sistema a partir del uso
de los distintos clasificadores provistos por UML 2.5
Definir los distintos tipos de relaciones posibles a ser representadas en UML para
poder representar la interaccin existente entre elementos de un sistema de
estudio
Construir un diagrama de clases para presentar la estructura de un sistema en
especfico de estudio.
2. Introduccin
UML se encarga de proveer la estandarizacin del conjunto de herramientas para el
modelado del funcionamiento de los sistemas. Bsicamente el diagrama de clases permite
describir de manera grfica la estructura de un sistema a nivel de clases e interfaces. Incluye
informacin relevante a cualquier etapa del ciclo de vida puesto que adems representa
caractersticas del comportamiento de las instancias a obtener de las distintas clases del
diagrama. UML inclusive permite describir el acceso, visibilidad, navegabilidad,
multiplicidad e innumerables caractersticas que este tipo de diagrama esttico puede
poseer para definir mejor el comportamiento del sistema que modela.

3
3. Diagramas de Clases
El diagrama de clases es un diagrama de estructura UML que muestra la estructura de un

sistema diseado al nivel de clases e interfaces, muestra sus caractersticas, restricciones
y relaciones asociaciones, generalizaciones, dependencias, etc.
Algunos tipos comunes de diagramas de clases son:
Diagrama de Modelo del Dominio

Diagrama de Implementacin de Clases
3.1.Diagrama de Modelo del Dominio
Diagrama general del dominio clases, interfaces, asociaciones,

usos, realizacin, multiplicidad

4
3.2.Diagrama de Implementacin de Clases
4. Clases
Una clase es un clasificador que describe un conjunto de objetos que comparten las
mismas:
Caractersticas,
Restricciones,
Semnticas (significado).
Una clase se representa por un rectngulo de lnea gruesa conteniendo el nombre de la

clase, y opcionalmente con compartimentos separados por lneas horizontales conteniendo
caractersticas u otros miembros del clasificador.
Como la clase es el clasificador ms ampliamente usado, no hay necesidad de agregar la

palabra reservada class entre comillas sobre el nombre de la clase. El nombre de la clase

5
debera estar centrado y en negrita, con la primera letra del nombre de la clase en
maysculas (si el conjunto de caracteres maneja maysculas).
Las caractersticas de una clase son atributos y operaciones.
Cuando una clase es representada con tres compartimentos, el compartimento de en

medio almacena la lista de atributos y el compartimento de abajo almacena la lista de
operaciones. Tanto atributos y operaciones deberan estar justificados a la derecha, sin
negritas y con la primera letra de sus nombres en minsculas.
Las caractersticas que se representan podrn ser de instancias de un clasificador,

consideradas de manera individual (no estticos) o para el clasificador en si (estticos). La
misma caracterstica no puede ser esttica en un contexto y no esttica en otro.
Con respecto a las caractersticas estticas, se reconocen dos alternativas para la

semntica. La caracterstica esttica puede tener:
Valores diferentes para diferentes clasificadores, o

El mismo valor por todos los clasificadores
De acuerdo con las semnticas, la herencia de valores para caractersticas estticas es

permitida pero no requerida segn UML 2.
Las caractersticas estticas se subrayan pero solamente sus nombres. Una elipsis ()
colocada como elemento final de una lista de caractersticas indica que existen
caractersticas adicionales pero que no se muestran en la lista.

6
Los atributos de una clase son representados por instancias de propiedad que son posedas
por la clase. Algunos de estos atributos pueden representar finales navegables de
asociaciones binarias.
Los objetos de una clase deben contener valores para cada atributo que es miembro de esa
clase, cumpliendo con las caractersticas definidas para ese atributo. Por ejemplo, debera
estar de acuerdo en el tipo y la multiplicidad.
Los atributos y las operaciones pueden ser agrupadas por visibilidad. Una palabra reservada
o smbolo especial se puede dar a todo el conjunto de caractersticas que comparten dicha
visibilidad.
Se pueden proveer compartimentos adicionales a las clases con dos fines: presentar ms
detalles de las mismas, tales como restricciones, o para dividir las caractersticas que ya se
estn presentando.
Una clase en UML puede ser usada como un espacio de nombres (namespace) para otros
clasificadores incluyendo clases, interfaces, casos de uso, etc. Los clasificadores anidados
son visibles nicamente dentro del namespace de la clase donde se encuentran.

7
La clase en UML 2.5 se volvi estructurada, encapsulada y con comportamientos mediante

la extensin del clasificador de encapsulado y el clasificador de comportamiento. Es por
esto que algunas clases pueden tener cierta estructura interna y puertos.
El anidamiento de clasificadores definido dentro del alcance de una clase estructurada,

limita la visibilidad de los clasificadores al alcance del namespace de la clase estructurada
que la contiene y por ende soporta la encapsulacin (ocultamiento de informacin) a travs
de los puertos.
Clases Abstractas
UML 2.4 menciona las clases abstractas, pero no provee ninguna definicin. Podemos
probablemente relacionar la definicin de clasificador abstracto a una clase abstracta.
Pudiramos asumir que en UML 2.x la clase abstracta no tiene una declaracin completa y
tpicamente no puede ser instanciada. Una clase abstracta est pensada para ser usada
por otros clasificadores (por ejemplo, como el objetivo de relaciones de generalizacin).
UML 2.4 no provee explicacin para una declaracin incompleta de una clase ni con lo
que est relacionado con el concepto de operacin abstracta que tambin estaba
presente en UML 1.4.2 y que est ausente en UML 2.x.
El intento de crear una instancia de una clase abstracta est indefinido algunos lenguajes
de programacin tomaran esta accin como ilegal, otros crearan una instancia parcial con
propsitos meramente de pruebas.

8
El nombre de una clase abstracta se presenta en cursivas.
Un clasificador abstracto puede ser representado usando la palabra reservada {abstract}

tanto despus o abajo del nombre.
La clase abstracta fue definida en UML 1.4.2 como una clase que no puede ser directamente
instanciada. La clase abstracta existe nicamente para que otras clases hereden de ella y
para darle soporte a la reusabilidad de caractersticas que declara. No debe haber nunca
una instancia directa de una clase abstracta, aunque un objeto puede ser una instancia
indirecta a travs de una subclase que no sea abstracta.
4.1. Estereotipos Estndar para las Clases

Hay varios estereotipos del estndar UML que aplican a las clases:
Estereotipos Estndar para las clases UML

Nombre Descripcin
Auxiliary Auxiliary es una clase que da soporte a otra clase ms
fundamental o cntrica, normalmente implementando lgica
secundaria o control de flujo. La clase a la que auxiliary da
soporte debe ser definida claramente, ya sea de manera
explcita usando una clase foco (focus class) o de manera
implcita mediante una relacin de dependencia.
Las clases auxiliares usualmente son usadas para especificar
lgica secundaria del negocio o para controlar el flujo de los
componentes durante la fase de diseo.
Focus Focus es una clase que define la lgica central (core logic) o el
control de flujo para una o ms clases de soporte. Las clases de
suporte pueden ser definidas tanto explcitamente usando
clases auxiliares o implcitamente por relaciones de
dependencia.
Las clases foco se utilizan usualmente para especificar lgica
central del negocio o controlar el flujo de componentes
durante la fase de diseo.
ImplementationClass La implementacin de una clase en algn lenguaje de
programacin (por ejemplo: C++, Smalltalk, Java) en donde una
instancia no debe tener ms de una clase.
Esto en contraste a la clase UML, para la cual una instancia
puede tener mltiples clases en un momento y puede ganar o

9
perder clases a lo largo del tiempo, y un objeto puede poseer

mltiples clases de manera dinmica.
Una clase implementacin (implementation class) puede
realizar un variado nmero de tipos (types). Los atributos
fsicos y asociaciones de una clase implementacin no tienen
que ser los mismos que aquellos de cualquier otro clasificador
que realice, y la clase implementacin puede proveerle
mtodos para sus operaciones en trminos de sus atributos
fsicos y asociaciones.
Metaclass Una clase cuyas instancias son tambin clases.
Type Type es una clase que especifica un dominio de objetos junto a
las operaciones aplicables a ellos, sin definir la implementacin
fsica de los objetos.
Un tipo puede tener atributos y asociaciones. Las
especificaciones del comportamiento de las operaciones del
tipo pueden ser expresadas usando, por ejemplo, diagramas de
actividad. Un objeto puede tener como mximo una clase
implementacin, sin embargo, puede ajustarse a mltiples
tipos diferentes.
Utility Utility es una clase que tiene atributos y operaciones estticas
al alcance de la clase nicamente. Por tanto, la clase utilidad
normalmente no posee instancias.
Tome en cuenta que, la convencin de nombramiento para los estereotipos y los

estereotipos aplicados fue cambiada en UML 2.4.1 para tener la primera letra de los mismos
en mayscula. An observar estereotipos en minscula (por ejemplo: focus, type)
puesto que tomar un tiempo cambiarse a la nueva notacin.

10
Hay algunos estereotipos no estandarizados, pero rutinariamente usados disponibles en

varias herramientas de UML, incluyendo al IBM Rational Software Architect (RSA) y Sparx
Enterprise Architect; tales como: Boundary, Control, Entity.
Estos estereotipos de clases son parte del Analysis Profile en RSA, que es aplicado por
defecto con la plantilla de Modelo de Anlisis. Los estereotipos corresponden
aproximadamente a las partes del patrn de diseo Modelo-Vista-Controlador (MVC),
donde Boundary representa la Vista, Control es el Control, y Entity corresponde al Modelo.
Estereotipos no estandarizados para las Clases UML

Nombre Descripcin
Boundary Es una clase u objeto estereotipado que representa alguna frontera del
sistema (por ejemplo, una pantalla de interfaz de usuario), una interfaz del
sistema o un objeto de interfaz de dispositivo. Puede ser utilizado en la
fase de anlisis o la fase conceptual del desarrollo para capturar usuarios
o sistemas externos que interactan con el sistema bajo desarrollo. Se usa
usualmente en diagramas de secuencia que demuestran interacciones del
usuario con el sistema.
Control Es una clase u objeto estereotipado usado para modelar el flujo de control
o alguna coordinacin en el comportamiento. Una o varias clases de
control pueden describir una realizacin de un caso de uso. Los controles
del sistema representan la dinmica del sistema diseado y usualmente
describen alguna lgica del negocio.
Entity Es una clase u objeto estereotipado que representa alguna informacin o
datos que usualmente (pero no necesariamente) son persistentes.
Una entidad se dibuja como un crculo con una lnea ubicada en la parte
baja del mismo. Tambin puede ser representado como una clase con el
estereotipo Entity.
Las Entidades del Negocio (Business Entities) representan alguna cosas,
tems, documentos, o informacin manejada, usada o procesada por
trabajadores del negocio mientras realizan el negocio. Algunos ejemplos
de entidades del negocio son: la prescripcin en la oficina del doctor, el
men en un restaurante, o el ticket en un aeropuerto.
Las Entidades del Sistema (System Entities) representan alguna
informacin o datos, usualmente (pero no necesariamente) persistentes,
que son procesados por el sistema.
Tome nota que en UML 1.4.2 el estereotipo entity representaba una
clase pasiva, que era una clase cuyos objetos no iniciaban interacciones
por si mismos. UML 2.0 actualiz el estereotipo estndar Entity para
poder aplicarse a componentes y para que represente un concepto del
negocio de una informacin persistente.

11
4.2. Plantilla de Clase

Las clases UML pueden ser con plantilla (templated) o enlazadas (bound).
El ejemplo de abajo presenta la clase con plantilla Array con dos parmetros formales de
plantilla. El primer parmetro de plantilla T es un parmetro de plantilla de una clase sin
restricciones. El segundo parmetro de plantilla n es un parmetro de plantilla de una
expresin entera.
El enlazamiento con plantilla para la clase enlazada Clientes substituye la clase sin
restricciones T con la clase Cliente y el lmite n con el valor entero 24. As, la clase enlazada
Clientes es un Array de 24 objetos de la clase Cliente.
5. Interfaces
Una interfaz es un clasificador que declara un conjunto de caractersticas u obligaciones
pblicas coherentes. Una interfaz especifica un contrato. Cualquier instancia de un
clasificador que realice (implemente) la interfaz, debe cumplir ese contrato y as proveer
los servicios descritos por el mismo.
Puesto que las interfaces son declaraciones, no es posible tener instancias de ellas. En su
lugar, se implementa una especificacin de interfaz por una instancia de un clasificador
instanciable, lo que significa que el clasificador instanciable presenta una fachada (facade)
pblica que se acopla a la especificacin de la interfaz.
Cualquier clasificador dado puede implementar ms de una interfaz. Una interfaz puede ser
implementada por un nmero diferente de clasificadores.
Una asociacin entre una interfaz y cualquier otro clasificador implica que una asociacin
respectiva debe existir entre cualquier implementacin de la interfaz y ese otro clasificador.

12
En particular, una asociacin entre interfaces, implica que la asociacin respectiva debe
existir entre implementaciones de dichas interfaces.
Notacin
Una interfaz puede ser presentada usando el smbolo de un rectngulo con la palabra
reservada interface precediendo al nombre.
Interface SiteSearch
Las obligaciones que pueden estar asociadas a una interfaz estn en la forma de varios tipos
de restricciones (tales como pre- y post- condiciones) o especificaciones de protocolo, las
cuales pueden imponer restricciones de orden en las interacciones a travs de la interfaz.
Las interfaces implementadas por un clasificador son sus interfaces provistas, y

representan las obligaciones que instancias de ese clasificador tienen con sus clientes.
Describen los servicios que las instancias de ese clasificador ofrecen a sus clientes.
La dependencia que existe de una interfaz participando en una realizacin de interfaz se

representa como un crculo o bola, etiquetada con el nombre de la interfaz y unida por una
lnea gruesa al clasificador que realiza (implementa) esa interfaz.

13
Una interfaz requerida especifica los servicios que un clasificador necesita para desarrollar
su funcin y cumplir sus propias obligaciones a sus clientes. Se especifica mediante una
dependencia de uso (usage dependency) entre el clasificador y la interfaz correspondiente.
La dependencia de uso desde un clasificador hacia una interfaz se muestra representando

a la interfaz como un semicrculo o socket, etiquetado con el nombre de la interfaz, y unido
por una lnea gruesa al clasificador que requiere de esa interfaz.
Seguido ocurre el caso en la prctica, donde dos o ms interfaces son acopladas

mutuamente a lo largo de las dependencias especficas de la aplicacin. En esas situaciones,
cada interfaz representa un rol especfico en un protocolo pluripartidista. Este tipo de
roles de protocolo acoplados pueden ser capturados por asociaciones entre interfaces.
Una interfaz en UML puede ser usada como un namespace por otros clasificadores,
incluyendo clases, interfaces, casos de uso, etc. Los clasificadores anidados son visibles
nicamente dentro del namespace de la interfaz que los contiene.
Note que en UML 1.4 una interfaz era formalmente equivalente a una clase abstracta sin
atributos ni mtodos y solamente operaciones abstractas.
6. Tipo de Datos
Un tipo de dato (data type) es un clasificador -similar a una clase- cuyas instancias son
identificadas nicamente por su valor.
Un uso tpico de un tipo de dato podra ser para representar tipos por valor (value types)
de un dominio de negocio, tipos primitivos o tipos estructurados de un lenguaje de
programacin. Por ejemplo, date/time, gnero, moneda, direccin, etc., todos pueden ser
definidos como tipos de datos. Todas las copias de una instancia de un tipo de dato y
cualquier instancia de ese tipo de dato con el mismo valor son consideradas instancias
iguales.
Un tipo de datos se representa usando un smbolo de rectngulo con la palabra reservada

dataType.

14
Un tipo de dato puede contener atributos y operaciones que den soporte al

modelamiento de tipos de datos estructurados. Las instancias de un tipo de dato
estructurado se consideran iguales si la estructura es la misma y los valores de los
atributos correspondientes son iguales.
Cuando un tipo de dato es referenciado, por ejemplo, como un atributo de una clase, se
representa simplemente como el nombre del tipo de dato.
6.1. Tipos primitivos

Un tipo primitivo es un tipo de dato que representa valores atmicos de datos, esto es
valores que no poseen partes o estructura. Un tipo de dato primitivo puede tener
semnticas precisas y operaciones definidas fuera de UML, por ejemplo, de tipo
matemtico.

15
Los tipos primitivos estndar incluidos en UML son:
Booleano (Boolean),
Entero (Integer),
Natural sin lmites (UnlimitedNatural),
Cadena de caracteres (String),
Real.
Las instancias de los tipos primitivos no tienen identidad. Si dos instancias tienen la misma
representacin, entonces son indistinguibles.
Un tipo primitivo tiene la palabra reservada primitive sobre o antes del nombre del tipo
primitivo.
6.2. Enumeracin
Una enumeracin es un tipo de datos cuyos valores son enumerados en el modelo como
literales de enumeracin definidos por el usuario.
Una enumeracin puede ser presentada usando cualquier notacin de clasificador (un
rectngulo) con la palabra reservada enumeration. El nombre de la enumeracin se
coloca en la parte superior del compartimento. Un compartimento listando los atributos
de la enumeracin se coloca bajo el compartimento del nombre. Un compartimento
listando las operaciones de la enumeracin se coloca bajo el compartimento de atributos.
Una lista de literales de la enumeracin puede ser colocada, uno por lnea, en el
compartimento ms bajo. Los compartimentos de los atributos y de las operaciones
pueden ser omitidos, lo que normalmente se hace si estarn vacos.

16
7. Operacin
La especificacin UML 2.5 define una operacin como:
Una operacin es una caracterstica de comportamiento que puede pertenecer a una

interfaz, tipo de datos, o clase. Las operaciones tambin pueden estar basadas en
plantillas y ser usadas como parmetros de plantilla. Una operacin puede ser
invocada directamente en instancias de los clasificadores que la ofrecen. La operacin
especifica nombre, tipo, parmetros, y restricciones para dichas invocaciones.
Una operacin es invocada en una instancia de un clasificador que la posee. Si una

operacin es marcada como isQuery, la ejecucin de la operacin deja el estado del
sistema sin cambios, no ocurren efectos colaterales. El valor por defecto para esa
propiedad es falso, de manera que se asume que una operacin tendr efectos colaterales
y cambiar el estado del sistema.
Una operacin en UML puede tener como mximo un parmetro de retorno. Una
operacin puede, adems, lanzar una excepcin durante su invocacin.
Una operacin puede ser redefinida en una especializacin del clasificador principal. Esta
redefinicin puede especializar los tipos de parmetros que posee, agregar nuevas
precondiciones o pos-condiciones, agregar nuevas excepciones a lanzar, o de otra manera
refinar la especificacin de la operacin.
Cuando una operacin es presentada en un diagrama, el texto debera adecuarse a la

sintaxis definida en la especificacin UML. Tome en cuenta que las especificaciones UML
de la 2.2 a la 2.4 parecen tener un anidamiento incorrecto para las propiedades de las
operaciones, haciendo que la presencia de las propiedades dependa de la presencia del
tipo de retorno. La sintaxis provista abajo no es normativa y difiere un poco de aquella en
la especificacin UML 2.5:
operacin ::= [ visibilidad ] firma [ propiedades-operacin ]
La visibilidad de la operacin es opcional, y si se presenta debera ser una de las

siguientes:
visibilidad ::= + | - | # | ~

17
La firmad de la operacin tienen una lista de parmetros opcionales y la especificacin del

retorno.
firma ::= nombre-operacin ( [ lista-parmetros ] ) [ :

especificacin-retorno ]
El nombre-operacin es el nombre de la operacin. La lista-parmetros es una

lista de parmetros de la operacin en el siguiente formato:
Lista-parametros ::= parmetro [ , parmetro ]*
Parmetro ::= [ direccin ] nombre-parmetro : expresin-

tipo [ [ multiplicidad ] ] [ = default ] [ propiedades-
parmetro ]
El nombre-parmetro es el nombre del parmetro. Expresin-tipo es una

expresin que especifica el tipo del parmetro. La multiplicidad es la multiplicidad
del parmetro. Default es una expresin que define la especificacin del valor para el valor
por defecto del parmetro.

18
La direccin del parmetro se describe como una de las siguientes:
Direccin ::= in | out | inout | return
Y por defecto es in si se omite.
Las propiedades-parmetro opcionales, describen propiedades con valores

adicionales que aplican al parmetro.
Propiedades-parmetro ::= { propiedad-parmetro [ ,

propiedad-parmetro ]* }
La especificacin del retorno, si se presenta se define como:
Especificacin-retorno ::= [ tipo-retorno ] [ [

multiplicidad ] ]
El tipo de retorno es el tipo del resultado, si fue definido por la operacin. La

especificacin de retorno tambin tiene multiplicidad opcional para el tipo de retorno.
Las propiedades de la operacin son opcionales, y si se presentan deberan seguir la

siguiente regla:
Propiedades-operacin ::= { propiedad-operacin [ ,

propiedad-operacin ]* }
Propiedad-operacin ::= redefines nombre-operacin |

query | ordered | unique | restriccin-operacin

19
Las propiedades de la operacin describen la operacin en general o el parmetro de

retorno, y son definidas como:
redefines nombre-operacin la operacin redefine una operacin heredada

identificada por nombre-operacin.
query la operacin no cambia el estado del sistema.
Ordered los valores del parmetro de retorno son ordenados.
Unique los valore retornados por el parmetro no tienen duplicados.
Restriccin-operacin es una restriccin que aplica a la operacin.
7.1. Mtodo
Una operacin perteneciente a una clase puede tener un mtodo relacionado que define
su comportamiento detallado.
El mtodo fue definido en el Glosario de la ahora obsoleta especificacin UML 1.4.2

como:
Mtodo es la implementacin de una operacin. Especifica el algoritmo o

procedimiento asociado con una operacin.
Abajo est la explicacin del mtodo de la especificacin UML 2.5:

20
Una operacin tambin puede tener un mtodo, el cul es una definicin detallada de
su comportamiento requerido. Es una responsabilidad del modelador asegurarse que
el comportamiento modelado detallado por el mtodo de la operacin cumpla con los
requerimientos de comportamiento dados por las pre- y pos-condiciones de la
operacin.
Tome en cuenta que, sin embargo, la pos-condicin no es requerido mantenerla

durante la ejecucin transitoria del comportamiento del mtodo, pero s al punto
estable de la finalizacin de la ejecucin de ese comportamiento. Una clase puede
tener tambin condiciones invariantes que pueden ser ciertas antes o despus de la
ejecucin de la operacin pero pueden ser violadas durante el curso de la ejecucin del
mtodo de la operacin.
La resolucin del mtodo es un proceso que permite determinar un mtodo a ser usado
cuando una operacin fue invocada. Este proceso debera tomar en cuenta:
La operacin que est siendo solicitada,

El objeto que est recibiendo la solicitud, y
Los valores de los parmetros de ingreso asociados con esa solicitud.
Los mtodos de una operacin pueden ser invocados tanto sncrona como
asncronamente, dependiendo de cmo ha sido llamada la operacin.
7.2. Operacin Abstracta

En UML 2.5 una caracterstica de comportamiento debe tener por defecto una
implementacin en el clasificador o alguna implementacin debe ser heredada. Entonces
por defecto una operacin debe tener un mtodo.
Si la propiedad isAbstract de una operacin es verdadera (true), significa que la operacin

no tiene ningunos mtodos implementndola, con la expectativa que las
implementaciones sern provistas por elementos ms especficos.
No hay notacin en cursiva para la operacin abstracta en UML 2.5 pero probablemente
an puede ser marcada utilizando {abstract}.
8. Multiplicidad
La multiplicidad en UML permite especificar cardinalidad esto es el nmero de
elementos de alguna coleccin de elementos.
El elemento de multiplicidad define alguna coleccin de elementos, e incluye tanto la

multiplicidad as como la especificacin del orden y unicidad de la coleccin de elementos.

21
Tome en cuenta que en la especificacin UML 2.4.1 no se separa multiplicidad de

elemento de multiplicidad, usando ambos de manera intercambiable y dando lugar a
cierta confusin para entender la especificacin.
8.1. Multiplicidad
Es una definicin de cardinalidad esto es el nmero de elementos de alguna coleccin
de elementos proveyendo un intervalo inclusivo de enteros no negativos para especificar
el nmero permitido de instancias del elemento descrito. El intervalo de multiplicidad
tiene una frontera inferior y una frontera superior (posiblemente infinita) segn se
describe a continuacin.
Rango-multiplicidad ::= [ frontera-inferior .. ] frontera

superior
Frontera-inferior ::= especificacin-valor-natural
Frontera-superior ::= especificacin-valor-natural | *
Las fronteras superior e inferior pueden ser constantes naturales o expresiones

constantes evaluadas a un nmero (no negativo). La frontera superior puede tambin ser
especificada por un asterisco * que denota un ilimitado nmero de elementos. La
frontera superior debera ser mayor o igual a la frontera superior.
Algunos ejemplos tpicos de multiplicidad son:
Multiplicidad Opcin Cardinalidad

0..0 0 La coleccin debe estar vaca
0..1 Ninguna o una instancia
1..1 1 Exactamente una instancia
0..* * Cero o ms instancias
1..* Al menos una instancia
5..5 5 Exactamente 5 instancias
m..n Al menos m pero no ms que n instancias
Si la multiplicidad es asociada a un elemento cuya notacin es una cadena de texto (tal

como un atributo de clase), el rango de multiplicidad es colocado dentro de corchetes
como parte de esa cadena de texto.

22
Si la multiplicidad es asociada a un elemento que aparece como un smbolo (tal como un

caso de uso o clase), el rango de multiplicidad se despliega sin los corchetes.
8.2. Elemento de multiplicidad

El elemento de multiplicidad define alguna coleccin de elementos, e incluye tanto la
multiplicidad como una especificacin del orden y unicidad de los elementos de la
coleccin.
Algunas subclases del elemento de multiplicidad son caracterstica estructural (structural

feature), operacin, parmetro, pin.
Las propiedades de la coleccin pueden ser descritas por la siguiente sintaxis no

normativa:
Tipo-coleccin ::= rango-multiplicidad [ { opciones-

coleccin } ]
Las opciones de la coleccin especifican si los valores en una instancia de un elemento

deberan ser nicos o/y ordenados:
Opciones-coleccin ::= designante-orden [, designante-

unicidad ] | designante-unicidad [, designante-orden]
Designante-orden ::= ordered | unordered
Designante-unicidad ::= unique | nonunique

23
Tipo de Coleccin isOrdered isUnique

Multiset, bag Falso Falso
Sequence, array Verdadero Falso
Set Falso Verdadero
Set ordenado Verdadero Verdadero
Si el elemento de multiplicidad es multivaluado y especificado como ordenado (ordered),

entonces la coleccin de valores en una instancia de este elemento es ordenada
secuencialmente. Por defecto, las colecciones no son ordenadas.
Si el elemento de multiplicidad es multivaluado y especificado como nico (unique),

entonces cada valor en la coleccin de valores en una instancia de este elemento debe ser
nico. Por defecto, cada valor en la coleccin es nico.
9. Constraint
Una restriccin (constraint) es un elemento empaquetable que representa alguna
condicin, restriccin o asercin relacionada a algn elemento (a quien le pertenece la
restriccin) o varios elementos. Las restricciones usualmente son especificadas por
expresiones Booleanas que deben evaluar a cierto (true) o a falso (false). Una restriccin
debe ser satisfecha (esto es evaluada a cierto) por un diseo correcto del sistema. Las
restricciones se usan normalmente por varios elementos en los diagramas de clases.
En general hay muchos tipos posibles de dueos para una restriccin. El elemento dueo
debe tener acceso a los elementos de la restriccin para verificarla. El dueo de la
restriccin determinar cuando sea evaluada la misma. Por ejemplo, una operacin puede
tener restricciones de pre-condicin y/o pos-condicin.
Una restriccin puede tener un nombre opcional, usualmente un sinnimo. Adems, se

representa por una cadena de texto entre llaves de acuerdo a la siguiente sintaxis:

24
Constraint ::= { [ nombre : ] expresin-Booleana }
La especificacin UML no restringe los lenguajes que pueden ser usados para expresar
restricciones. Algunos ejemplos de lenguajes para restricciones son:
OCL
Java
Lenguaje de mquina comprensible
Lenguaje natural
OCL es un lenguaje para restricciones predefinido en UML pero si est utilizando una
herramienta para diagramar el UML, cualquier lenguaje para restricciones que esa
herramienta use puede ser aplicado.
Para un elemento cuya notacin es una cadena de texto (tal como un atributo de clase), la
cadena de restriccin puede seguir al elemento de cadena de texto entre llaves.
Para una restriccin que aplique a un nico elemento (tal como una clase o un camino de
asociacin), la cadena de restriccin puede ser colocada cerca del smbolo para dicho
elemento, preferiblemente cerca del nombre, si lo hubiere. Una herramienta UML debe
hacer posible determinar los elementos restringidos.
Para una restriccin que aplique a dos elementos (tales como dos clases o dos
asociaciones), la restriccin puede ser presentada como una lnea punteada entre los
elementos etiquetados por la cadena de restriccin entre llaves.

25
Si la restriccin se presenta como una lnea punteada entre dos elementos, se puede
colocar una punta de flecha en uno de los extremos. La direccin de la flecha es
informacin relevante dentro de la restriccin. El elemento en la cola de la flecha es
mapeado a la primera posicin y el elemento en la cabeza de la flecha es mapeado a la
segunda posicin en la coleccin de elementosRestringidos (constrainedElements).
La cadena de restriccin puede ser colocada con el smbolo de una nota (el mismo usado
para comentarios) y adjuntado a cada uno de los smbolos para los elementos restringidos
por medio de una lnea punteada.
10. Asociacin
Una asociacin es una relacin entre clasificadores que es usada para representar que las
instancias de los clasificadores pueden estar: vinculadas entre ellos o combinadas lgica o
fsicamente en algn tipo de agregacin.
La especificacin UML categoriza las asociaciones como relaciones semnticas. Algunas

otras fuentes UML tambin categorizan la asociacin como una relacin estructural.
Aunque Wikipedia define que la asociacin es una relacin a nivel de instancia y que las

26
asociaciones pueden ser presentadas nicamente en los diagramas de clases, en realidad

en ninguna especificacin UML dice tal cosa. De hecho una asociacin puede ser usada en
diferentes tipos de diagramas de estructura UML:
Asociaciones del diagrama de clases,

Asociaciones del diagrama de casos de uso,
Asociaciones de artefactos del diagrama de despliegue,
Caminos de comunicacin del diagrama de despliegue.
Hay varios conceptos relacionados a las asociaciones, como:
propiedad (ownership) del extremo de la asociacin,

navegabilidad,
aridad de la asociacin,
tipo de agregacin.
La especificacin UML 2.4 sostiene que para la asociacin: El tipo de agregacin, la

navegabilidad, y la propiedad del extremo son conceptos ortogonales, lo que es
claramente una exageracin. Puesto que lo ortogonal normalmente se relaciona a lo
completamente independiente. Mientras que la notacin para tipo de agregacin,
navegabilidad, y propiedad del extremo de la asociacin pueden ser aplicados
independientemente, los conceptos en s mismos no son ortogonales. Por ejemplo, en
UML 2.4 la propiedad del extremo de una asociacin poseda por una clase final es
navegable, lo que claramente hace a la navegabilidad dependiente de la propiedad
(ownership).

27
Una asociacin normalmente se dibuja como una lnea gruesa conectando a dos
clasificadores o a un nico clasificador a s mismo. El nombre de la asociacin puede ser
ubicado en algn lugar cercano a la mitad de la lnea pero no muy cerca al final de
cualquiera de los extremos. Cada extremo de una lnea puede ser decorado con el nombre
del extremo de la asociacin (association end).
10.1. Extremo de la asociacin

Del ingls association end, es una conexin entre la lnea que representa una asociacin y
el cono que representa al clasificador conectado. El nombre del extremo de la asociacin
puede ser colocado cerca del extremo de la lnea. El nombre del extremo de asociacin es
referido normalmente con el nombre de rol (pero no se define como tal en el estndar
UML 2.4). El nombre de rol es opcional y suprimible.
La idea del rol es que el mismo clasificador puede jugar el mismo o diferentes roles en las
asociaciones. Por ejemplo, el Profesor puede ser un autor de algunos Libros o un editor.
El extremo de la asociacin puede pertenecer a:
Un clasificador del extremo (end classifier), o a

Una asociacin por s misma.
Los extremos de asociacin con ms de dos extremos deben ser posedos por la
asociacin.
La propiedad (ownership) de los extremos de asociacin por un clasificador asociado

puede ser indicada grficamente por un crculo pequeo relleno (tambin conocido como
punto del ingls dot). El punto es dibujado en el punto donde la lnea se encuentra con el
clasificador. Puede ser interpretado como representando que el modelo incluye una

28
propiedad del tipo representado por el clasificador tocado por el punto. Esta propiedad le
pertenece al clasificador al otro extremo.
El punto de propiedad puede ser usado en combinacin con otras notaciones de lneas
grficas para las propiedades de las asociaciones y los finales de las asociaciones. Esto
incluye al tipo de agregacin y a la navegabilidad.
El estndar UML no obliga al uso explcito de la notacin de pertenencia, pero define una
notacin que debera aplicarse en modelos donde eso haya sido escogido. La notacin del
punto debe ser aplicada a nivel de asociaciones completas o superiores, de manera que la
ausencia del punto representa pertenencia a la asociacin. En otras palabras, en
asociaciones binarias el punto ser omitido para aquellos extremos que no pertenecen al
clasificador.
La notacin de atributo puede ser usada para un extremo de asociacin que le pertenece
a una clase, porque un extremo de asociacin posedo por una clase tambin es un
atributo. Esta notacin puede ser usada en conjuncin con la notacin de flecha para
dejar perfectamente claro que el atributo tambin es un extremo de una asociacin.
10.2. Navegabilidad
La propiedad al extremo de una asociacin es navegable desde el lado opuesto de la
asociacin si instancias del clasificador en ese final del link pueden ser accedidos
eficientemente en tiempo de ejecucin desde instancias al otro lado del link.
UML 2.4 provee la siguiente definicin de navegabilidad:

29
Una propiedad al extremo de una asociacin, que pertenece a una clase final, o que es un
extremo navegable perteneciente a la asociacin; indica que la asociacin es navegable
desde los extremos opuestos; de lo contrario, la asociacin no es navegable desde los
extremos opuestos.
Notacin:
Un extremo navegable se indica por una punta de flecha abierta al final de una
asociacin
Un extremo no navegable se indica por una x pequea en el final de una
asociacin
Un extremo de asociacin sin adornos al final significa navegabilidad no
especificada.

30
Un smbolo de visibilidad puede ser aadido como adorno a un extremo navegable para
mostrar la visibilidad de ese extremo como un atributo del clasificador principal.
10.3. Aridad
Cada asociacin tiene una aridad especfica, ya que podra relacionar a dos o ms
elementos.
Asociacin Binaria
La asociacin binaria relaciona dos instancias con tipos. Normalmente se representa

como una lnea gruesa conectando a dos clasificadores, o una lnea gruesa conectando a
un nico clasificador consigo mismo (los dos extremos son distintos). La lnea puede
consistir de uno o ms segmentos conectados.
Un pequeo tringulo rellenado puede ser colocado al lado o en lugar del nombre de la
asociacin binaria para representar el orden de los extremos de la asociacin. La flecha
apunta a lo largo de la lnea con direccin al ltimo extremo en el orden del final de
asociacin. Esta notacin tambin indica que la asociacin puede ser leda del principio al
final del ltimo extremo.

31
Asociacin N-aria
Cualquier asociacin podra ser dibujada como un diamante (ms grande que el diamante
dibujado al final de la lnea) con una lnea gruesa para cada extremo de la asociacin
conectando al diamante con el clasificador que es del tipo del extremo. Una asociacin n-
aria con ms de dos extremos nicamente puede ser dibujada de esta manera.
10.4. Agregacin compartida y compuesta

La agregacin es una asociacin binaria representando alguna relacin de tipo
todo/parte. El tipo de agregacin puede ser:
Agregacin compartida (tambin llamada agregacin), o

Agregacin compuesta (tambin llamada composicin)
10.5. Clase asociacin

Una asociacin puede ser redefinida para poseer su propio conjunto de caractersticas;
esto es, caractersticas que no pertenecen a ninguno de los clasificadores conectados pero
que preferiblemente pertenecen a la asociacin en s misma. Dicha asociacin es llamada
una clase asociacin. Es a la vez una asociacin, conectando un conjunto de clasificadores
y una clase, y como tal puede tener caractersticas que podran incluirse en otras
asociaciones.

32
10.6. Link
Un vnculo (link) es una instancia de una asociacin. Es una tupla con un valor para cada
extremo de la asociacin, donde cada valor es una instancia del tipo de ese extremo. La
asociacin tiene por lo menos dos extremos, representados por propiedades
(propiedades de extremo).
Un link se representa usando la misma notacin que para una asociacin. La lnea gruesa
conecta las instancias en lugar de a los clasificadores. El nombre del link puede mostrarse
subrayado, aunque no es requerido. Los nombres de los extremos (roles) y las flechas de
navegacin pueden mostrarse tambin.
11. Agregacin
La agregacin compartida (o simplemente agregacin) es una asociacin binaria entre
una propiedad y uno o ms objetos compuestos que agrupan un conjunto de instancias.
Es una forma dbil de agregacin cuando las instancias de las partes son independientes
de la compuesta. La agregacin compartida tiene las siguientes caractersticas:
Es una asociacin binaria,

Es asimtrica solamente un extremo de la asociacin puede ser una agregacin
Es transitiva los links de agregacin deberan formar un grfico a-cclico y directo
de manera que ninguna instancia compuesta pueda indirectamente ser parte de s
misma.
Una parte compartida puede ser incluida en varias composiciones, y si alguna o
todas las composiciones son borradas, la parte compartida an podra existir.
Notacin
La agregacin compartida es representada como una asociacin decorada con un

diamante vaco al final del extremo agregado de la lnea de asociacin. El diamante debe
ser notablemente ms pequeo que aquel de la notacin de asociaciones n-arias.
El ejemplo de abajo muestra al Triangulo como un agregado de exactamente tres

segmentos de lnea (lados). La multiplicidad * del extremo de la asociacin del lado del

33
Tringulo significa que cada lnea Segmento podra ser una parte de varios tringulos, o
podra no pertenecer a ningn tringulo. Borrar una instancia de Tringulo especfica no
significa de ninguna manera que cualquiera o todos los segmentos sern borrados
tambin. (Note que hemos llamado a la coleccin de esas tres lneas Segmentos lados,
mientras que la convencin UML usual es usar la forma singular, esto sera lado, inclusive
para las colecciones.)
Una agregacin compartida puede ser representada junto a otros adornos de asociacin,
tales como navegabilidad y propiedad de extremo de asociacin. En el ejemplo abajo, la
lnea Segmento es navegable desde Tringulo. El extremo de asociacin lados le
pertenece al Tringulo (no por la asociacin en s misma), lo que significa que lados es un
atributo de Tringulo.
Errores
La agregacin es una relacin asimtrica solamente un extremo de la asociacin se

puede marcar como una agregacin compartida o compuesta. Tanto UML 1.x como UML
2.x no permiten agregar un diamante a ambos extremos de una lnea de asociacin. El
razonamiento del ejemplo siguiente fue que cada instancia de Estudiante tiene una lista
de los cursos a los que se ha registrado, y cada Curso tiene una lista de los estudiantes
registrados para ese curso.

34
Tampoco ayudara si dibujsemos dos agregaciones separadas como se muestra abajo. Los
links de la agregacin deberan formar un grfico a-cclico directo de manera que ninguna
instancia compuesta podra ser parte directa o indirecta de s misma.
Historia
En UML 1.x los tipos para las agregaciones eran none, aggregate, y composite. UML 2.0
renombr el tipo de agregacin aggregate a shared, de manera que en UML 2.x los tipos
de agregacin son: none, shared, y composite.
Ejemplo
Modelo de dominio de Librera.
(Siguiente pgina)

35
12. Composicin
Una agregacin de composicin (o solamente composicin) es una forma de agregacin
fuerte con las siguientes caractersticas:
Es una asociacin binaria,

Es una relacin de tipo todo/parte,
Una parte puede ser incluida en, como mximo, una composicin (un todo) a la
vez, y
Si una composicin (un todo) es borrado, todas las partes que lo componen
normalmente se borran con l.

36
Notacin
Una agregacin de composicin se representa por una asociacin binaria decorada con un
diamante con relleno negro en el extremo del todo.
Cuando una composicin es usada en modelos de dominio, tanto la relacin todo/parte

como el evento de borrado de la composicin, deberan ser interpretados de manera
figurada, no necesariamente como una contencin o terminacin fsica. La especificacin
UML necesita ser actualizada para permitir esta interpretacin de manera explcita.
Note que, aunque parezca extrao, la multiplicidad del todo puede ser especificada como
0..1 (al menos uno) lo que significa que se le permite a la parte existir por s misma sin
estar obligada a pertenecer a un todo especfico.
Errores
La composicin es una relacin asimtrica solamente a un extremo de la asociacin se le

permite ser marcado como una agregacin compartida o compuesta. Tanto UML 1.x y
UML 2.x no permiten agregar un diamante ambos extremos de la asociacin.

37
13. Generalizacin
Es una relacin dirigida de taxonoma binaria (es decir, de clasificacin) entre un
clasificador ms general (sper clase) y un clasificador ms especfico (sub clase).
Cada instancia del clasificador especfico es tambin una instancia indirecta del
clasificador general, de manera que podemos decir Paciente es una Persona, Cuenta de
ahorro es una Cuenta, etc. A causa de esto, la relacin de generalizacin es tambin
formalmente llamada relacin es un.
La generalizacin es poseda por el clasificador especfico.
Una generalizacin se representa con una lnea con un tringulo vaco como punta de
flecha entre los smbolos representando a las clases involucradas. La punta de la flecha
apunta al smbolo representando al clasificador general. Esta notacin es referida como el
estilo de destino separado.
Las relaciones de generalizacin que referencian al mismo clasificador general pueden ser
conectadas juntas con el mismo estilo de destino compartido.
13.1. Herencia
La herencia del ADOO (Anlisis y Diseo Orientado a Objetos) usualmente se define como
un mecanismo por el cul clases ms especficas (llamadas subclases o clases derivadas)

38
incorporan la estructura y el comportamiento de clases ms generales (llamadas sper

clases o clases base).
La herencia fue explicada en UML 1.4.2 usando los conceptos de un descriptor completo y
de un descriptor de segmento. Un descriptor completo contiene una descripcin de todos
los atributos, asociaciones, operaciones, y restricciones que el objeto contiene, y es
usualmente implcito porque se construye a partir de segmentos incrementales
combinados usando la herencia.
La especificacin UML 2.4 y la reciente UML 2.5 no proveen definicin para la herencia.
Las especificaciones UML 2.x dicen que con los clasificadores de especializacin de
generalizacin heredan caractersticas de un clasificador ms general. Adems, cualquier
restriccin aplicable a instancias de un clasificador general tambin aplica a las instancias
de los clasificadores especficos.
UML 2.5 provee una explicacin vaga e incompleta de cmo funciona la herencia en UML:
Cuando un Clasificador es generalizado, algunos miembros de sus generalizaciones son

heredados, esto es que se comportan como si fuesen definidos en el mismo Clasificador
que los hereda. Por ejemplo, un miembro heredado que es un atributo tiene un valor o
coleccin de valores en cualquier instancia del Clasificador que lo hereda, y un miembro
heredado que es una Operacin puede ser invocado en una instancia del Clasificador que
lo hereda.
Herencia Mltiple
La herencia mltiple es permitida implcitamente por el estndar UML, a la vez que no

provee una definicin para lo que es.
Un clasificador en UML puede tener cero, uno o ms relaciones de generalizacin hacia

ms clasificadores generales. En ADOO la herencia mltiple se refiere a la habilidad de
una clase de heredar comportamientos y caractersticas de ms de una sper clase.
El origen de la herencia mltiple ser combinado en taxonomas ortogonales. Por ejemplo,

el diagrama de arriba combina dos diferentes clasificadores de empleados uno basado
en si el empleado es permanente o temporal, y otro basado en la posicin que posee el
empleado.
Aunque el estndar UML permite implcitamente la herencia mltiple, no provee

resoluciones explcitas o recomendaciones para ciertos problemas y ambigedades
conocidas, tal como el problema del diamante.

39
En el problema mostrado arriba, la clase Botn hereda dos diferentes implementaciones

de equals( ) mientras que no posee su propia implementacin para la operacin. Cuando
botn.equals( ) sea llamado, se desconoce cul implementacin de Rectngulo o de
Clickable ser usada.
Los perfiles UML permiten especializar la semntica de la generalizacin. Por ejemplo, en

el perfil del lenguaje Java la generalizacin de clases restringe a que sea nicamente la
herencia simple.
13.2. Set de Generalizacin

Un Set de Generalizacin (Generalization set) es un elemento empaquetable que nos
permite definir jerarquas de clasificacin combinando algunas generalizaciones un
clasificador general en particular en (sub) sets. Cada set de generalizacin puede estar
asociado con un clasificador llamado su powertype.
Cada set de generalizacin posee dos propiedades isCovering (restriccin de tipo

completo/incompleto) y isDisjoint (restriccin de tipo disyunto/solapamiento, del ingls
disjoint/overlapping), para clarificar que tipo de set es.
La propiedad isCovering de los sets de generalizacin especifica si el set de los clasificadores

especficos en el set de generalizacin est completo. S est completo ({complete}), cada
instancia del clasificador general es tambin una instancia de (por lo menos) uno de los
clasificadores especficos. Si el set no es completo ({incomplete}), puede haber algunas
instancias del clasificador general que no pueden ser clasificadas como cualquiera de los
clasificadores especficos del set de generalizacin.

40
La propiedad isDisjoint especifica si los clasificadores especficos del set de generalizacin

pueden solaparse. En el set de generalizacin restringido con {disjoint} no se tiene instancia
de cualquier clasificador especfico que tambin pueda ser instancia de otro clasificador
especfico (esto es, no hay solapamiento de los clasificadores). Si el set de generalizacin es
{overlapping}, alguno o todos los clasificadores especficos puede compartir instancias
comunes.
Por defecto, de UML 2.0 a UML 2.4.1 el set de generalizacin es {incomplete, disjoint},
mientras que en UML 2.5 el valor por defecto fue cambiado a {incomplete, overlapping}.
En el diagrama, las restricciones del set de generalizacin se colocan luego de los sets, cerca
de la punta de flecha comn o cerca de la lnea punteada del set de generalizacin.
La especificacin del powertype se muestra como dos puntos seguidos del nombre del
clasificador de powertype cerca del correspondiente set de generalizacin.
14. Dependencia
Es una relacin dirigida que es usada para mostrar que algn elemento UML o conjunto
de elementos requiere, necesita o depende de otros elementos del modelo para su
especificacin o implementacin. Por esto, la dependencia es llamada relacin cliente-
proveedor (supplier-client), donde el proveedor brinda algo al cliente, y as el cliente es en
cierto sentido incompleto mientras que es dependiente estructural o semnticamente del
elemento proveedor. Una modificacin al proveedor podra impactar en los elementos
cliente.
La dependencia es una relacin entre elementos nombrados, que en UML incluye varios
diferentes elementos, por ejemplo: clases, interfaces, componentes, artefactos,
paquetes, etc. Hay varios tipos de dependencia, como se muestra en el diagrama de
abajo.

41
Usage es una dependencia donde un elemento nombrado (cliente) requiere a otro

elemento nombrado especfico para completar su definicin o implementacin.
La abstraccin relaciona dos elementos representando el mismo concepto pero a

diferentes niveles de abstraccin.
El despliegue (deployment) es una dependencia que muestra la asignacin (despliegue)

de un artefacto a un destino de despliegue. (No es muy claro porque UML 2.4.1 define
deployment como una dependencia pero no como una asociacin o solo una relacin
dirigida).
Una dependencia se representa generalmente como una flecha punteada apuntando

desde el cliente al proveedor. La flecha puede ser etiquetada con un estereotipo opcional
o un nombre opcional.

42
La dependencia puede ser usada en varios tipos de diagramas UML, como:
Diagrama de clases
Diagrama de estructura compuesta
Diagrama de paquetes
Diagrama de componentes
Diagrama de despliegue
Aqu algunos ejemplos de dependencias:
El paquete WebShopping usa (depende de) el paquete Payment.
Interface SiteSearch es realizada (implementada) por SearchService.
Note que, la dependencia de abstraccin tiene por convencin poner al elemento ms

abstracto como proveedor y al ms especfico, o el elemento de la implementacin, como
cliente pero la especificacin UML permite dibujarlo de manera opuesta tambin.
14.1. Usage
La dependencia de uso (usage) es una relacin de dependencia en donde un elemento
(cliente) requiere otro elemento (o conjunto de elementos) (proveedores) para su
completa implementacin u operacin.
La dependencia de uso no especifica como el cliente usa al proveedor ms que por el

hecho que el proveedor es usado por la definicin o la implementacin del cliente. Por
ejemplo, podra significar que algn mtodo dentro de una clase (cliente) usa objetos (por
ejemplo, como parmetros) de otra clase (proveedor).
La dependencia de uso se muestra con una dependencia con la palabra reservada use
sobre ella.

43
Clase SearchController usa la clase SearchEngine.
Create
Un create es una dependencia de uso que denota que el clasificador del cliente crea
instancias del clasificador del proveedor. Se denota por el estereotipo estndar create
La clase DataSource crea Connection.
Un create tambin especificar que la caracterstica designada crea una instancia del
clasificador al cual la caracterstica est agregado. Esta dependencia puede ser promovida
al clasificador conteniendo la caracterstica.
El create puede relacionar un valor de instancia a un constructor de una clase,

describiendo el valor nico retornado por la operacin del constructor. La operacin es el
cliente, la instancia creada, el proveedor. El valor de la instancia puede referenciar
parmetros declarados por la operacin.
El constructor de la Cuenta crea nuevas instancias de Cuenta.
Call
Es una dependencia de uso que especifica que la operacin fuente invoca a la operacin
destino. Esta dependencia puede conectar una operacin fuente a alguna operacin
destino que se encuentre dentro del alcance incluyendo, pero no limitada a, operaciones
del clasificador que la encierra y operaciones de otros clasificadores visibles. Se denota
por el estereotipo estndar call cuya fuente es una operacin y cuyo destino es
tambin una operacin.

44
Esta relacin tambin puede ser aplicada a la clase que contiene una operacin, con la
idea que existe una operacin en la clase a la cul aplica la dependencia.
Send
Es una dependencia de uso cuya fuente es una operacin y cuyo destino es una seal,
especificando que la fuente enva una seal destino. Se denota con el estereotipo
estndar send.
Interface requerida
La interfaz requerida especifica servicios que un clasificador necesita para poder

desarrollar su funcin y completar sus obligaciones con sus clientes. Se especifica
mediante una dependencia de uso entre el clasificador y la correspondiente interface.
La dependencia de uso desde un clasificador hacia una interface se representa mediante

un semicrculo o socket, etiquetado con el nombre de la interface, unido mediante una
lnea gruesa al clasificador que requiere de esa interface.
Interface SiteSearch es usada (requerida) por SearchController.
Si la interface es representada mediante la notacin de rectngulo, la dependencia de uso

se representa mediante la flecha de dependencia. El clasificador en la cola de la flecha usa
(requiere) la interface en la punta de la flecha.
Interface SiteSearch es usada (requerida) por SearchController.
15. Abstraccin
La abstraccin es una relacin de dependencia que relaciona dos elementos nombrados
o conjuntos de elementos nombras representando el mismo concepto pero a diferentes
niveles de abstraccin o desde diferentes puntos de vista.

45
Puesto que la abstraccin es una dependencia, usualmente se define como una relacin
entre cliente/proveedor donde el cliente (sub-set o fuente) depende del proveedor (sub-
set o destino). Corresponde a una convencin comn de ADOO considerar al elemento
ms abstracto de la relacin el proveedor. Sin embargo, el modelador UML puede decidir
que para cierto dominio especfico o tarea es ms apropiado tener al elemento proveedor
ms abstracto dependiendo del elemento cliente ms especfico.
La abstraccin permite hacer al mapeo entre el proveedor y el cliente de tipo formal o

informal, y unidireccional o bidireccional, dependiendo de la subclase o estereotipo
especfico de la abstraccin. Por ejemplo, la derivacin puede ser formal y unidireccional,
mientras que el rastro (trace) puede ser informal y bidireccional.
Si una abstraccin tiene ms de un cliente, el proveedor se mapea en el conjunto de

clientes como un grupo. Por ejemplo, una clase nivel de anlisis puede servir como una
abstraccin para uno o varias clases del nivel de diseo. Un caso de uso podra ser una
abstraccin para varias colaboraciones.
Sintaxis de la Abstraccin
La abstraccin tiene dos sub clases realizacin y manifestacin. Una manifestacin se

etiqueta con la palabra reservada manifest, y es usada en diagramas de despliegue.
La abstraccin tambin tiene ciertos estereotipos estndar como Derive, Refine, y

Trace.

46
Notacin
Una relacin de abstraccin se representa con una flecha de relacin de dependencia

desde el cliente (en la cola de la flecha) hacia el proveedor (en la punta de la flecha), con
la palabra reservada abstraction o algn estereotipo predefinido unido a ella.
Por ejemplo, la clase del nivel de anlisis Cliente (proveedor, sub set o destino) puede ser
implementada en la clase de nivel de diseo ClienteInfo (cliente, sub set o fuente).
Customer del Dominio es una abstraccin de CustomerInfo de DataTransfer. (Ejemplo de

convencin comn el elemento ms abstracto es el proveedor.).

47
S el modelador de UML decide que es mejor presenta un elemento ms abstracto

dependiendo de un elemento ms especfico, la relacin se da vuelta.
Customer del Dominio es una abstraccin de CustomerInfo de DataTransfer. (Ejemplo de

notacin inversa el elemento menos abstracto es el proveedor.).
15.1. Derive
Es un estereotipo estndar de abstraccin que es usado para especificar la relacin de
derivacin en los elementos de un modelo que son usualmente, pero no necesariamente,
del mismo tipo. La derivacin es definida en UML como el cliente puede calcularse desde
el proveedor. La razn para tener tal cliente calculado puede ser la eficiencia en la
implementacin. El mapeo para la relacin de abstraccin especifica el clculo.
La relacin de derivacin se relaciona a las propiedades derivadas, propiedades cuyos

valores son producidos o calculados a partir de otra informacin, por ejemplo, usando
valores de otras propiedades.
Fecha
Nacimiento
Edad
La clase Edad es derivada de la clase FechaNacimiento
15.2. Refine
Es un estereotipo estndar de abstraccin que es usado para especificar una relacin de
refinamiento entre elementos de un modelo a diferentes niveles semnticos, tales como
anlisis, diseo e implementacin. Puede ser usado en transformaciones de modelos

48
desde el anlisis al diseo, del diseo a la implementacin, etc. El mapeo de la abstraccin

puede o no puede ser calculable, y puede ser unidireccional o bidireccional.
Los modelos pueden tener relaciones de refinamiento entre ellos, tpicamente

representadas por dependencias entre los elementos contenidos en los modelos.
Anlisis
ad Diseo
ad
La clase Customer del modelo de Diseo refina a la
clase Customer del modelo de Anlisis.
15.3. Trace
Es un estereotipo estndar de abstraccin que es usado principalmente para dar
seguimiento a requerimientos y cambios en los Modelos para los elementos o conjuntos
de elementos que representan un mismo concepto en diferentes modelos. As, trace una
relacin inter-modelo.
Este dependencias de mapeo/rastreo entre Modelos se representan por dependencias

entre elementos contenidos entre los modelos.
Algunos ejemplos del uso de Trace son:
Un caso de uso en el Modelo de casos de uso puede seguir un rastro (trace) a

colaboraciones o a un paquete en el correspondiente Modelo de Diseo.
Interfaces y clases del Modelo de Diseo pueden seguir un rastro (trace) a los
componentes en el Modelo de Implementacin.
Los componentes en el Modelo de Implementacin pueden seguir un rastro a
artefactos en el Modelo de Despliegue. En este caso, una alternativa sera usar una
relacin especializada de manifestacin.

49
Casos de Uso Diseo
El caso de uso Withdraw Cash del Modelo de Casos de Uso es rastreado por la
colaboracin Withdraw Cash en el Modelo de Diseo.
La direccin de un rastro (esto es, el etiquetado de cliente y proveedor) queda a

discrecin del modelador, y puesto que pueden ocurrir cambios en ambas direcciones del
modelo, la direccin de la dependencia puede ser muchas veces ignorada. El mapeo
especifica la relacin entre los dos, pero es raramente calculable y usualmente informal.

50

Guia 4

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Guia 4

Hochgeladen von

Copyright:

Verfügbare Formate

U N I V E R S I D A D D E E L S A LVA D O R

ESCUELA DE INGENIERIA DE SISTEMAS

Tecnologa Orientada a Objetos TOO115

Ing. Elmer Arturo Carballo Ruiz Msc.

13.1. Herencia ........................................................................................................................ 38

Ing. Elmer Arturo Carballo Ruiz Msc.

El diagrama de clases es un diagrama de estructura UML que muestra la estructura de un

Algunos tipos comunes de diagramas de clases son:

Diagrama de Modelo del Dominio

3.1.Diagrama de Modelo del Dominio

Diagrama general del dominio clases, interfaces, asociaciones,

Ing. Elmer Arturo Carballo Ruiz Msc.

3.2.Diagrama de Implementacin de Clases

Una clase se representa por un rectngulo de lnea gruesa conteniendo el nombre de la

Como la clase es el clasificador ms ampliamente usado, no hay necesidad de agregar la

Ing. Elmer Arturo Carballo Ruiz Msc.

Las caractersticas de una clase son atributos y operaciones.

Cuando una clase es representada con tres compartimentos, el compartimento de en

Las caractersticas que se representan podrn ser de instancias de un clasificador,

Con respecto a las caractersticas estticas, se reconocen dos alternativas para la

Valores diferentes para diferentes clasificadores, o

De acuerdo con las semnticas, la herencia de valores para caractersticas estticas es

Ing. Elmer Arturo Carballo Ruiz Msc.

Ing. Elmer Arturo Carballo Ruiz Msc.

La clase en UML 2.5 se volvi estructurada, encapsulada y con comportamientos mediante

El anidamiento de clasificadores definido dentro del alcance de una clase estructurada,

Ing. Elmer Arturo Carballo Ruiz Msc.

El nombre de una clase abstracta se presenta en cursivas.

Un clasificador abstracto puede ser representado usando la palabra reservada {abstract}

4.1. Estereotipos Estndar para las Clases

Estereotipos Estndar para las clases UML

Ing. Elmer Arturo Carballo Ruiz Msc.

perder clases a lo largo del tiempo, y un objeto puede poseer

Tome en cuenta que, la convencin de nombramiento para los estereotipos y los

Ing. Elmer Arturo Carballo Ruiz Msc.

Hay algunos estereotipos no estandarizados, pero rutinariamente usados disponibles en

Estereotipos no estandarizados para las Clases UML

Ing. Elmer Arturo Carballo Ruiz Msc.

4.2. Plantilla de Clase

Ing. Elmer Arturo Carballo Ruiz Msc.

Las interfaces implementadas por un clasificador son sus interfaces provistas, y

La dependencia que existe de una interfaz participando en una realizacin de interfaz se

Ing. Elmer Arturo Carballo Ruiz Msc.

La dependencia de uso desde un clasificador hacia una interfaz se muestra representando

Seguido ocurre el caso en la prctica, donde dos o ms interfaces son acopladas

Un tipo de datos se representa usando un smbolo de rectngulo con la palabra reservada

Ing. Elmer Arturo Carballo Ruiz Msc.

Un tipo de dato puede contener atributos y operaciones que den soporte al

6.1. Tipos primitivos

Ing. Elmer Arturo Carballo Ruiz Msc.

Los tipos primitivos estndar incluidos en UML son:

Ing. Elmer Arturo Carballo Ruiz Msc.

Una operacin es una caracterstica de comportamiento que puede pertenecer a una

Una operacin es invocada en una instancia de un clasificador que la posee. Si una

Cuando una operacin es presentada en un diagrama, el texto debera adecuarse a la

operacin ::= [ visibilidad ] firma [ propiedades-operacin ]

La visibilidad de la operacin es opcional, y si se presenta debera ser una de las

Ing. Elmer Arturo Carballo Ruiz Msc.

La firmad de la operacin tienen una lista de parmetros opcionales y la especificacin del

firma ::= nombre-operacin ( [ lista-parmetros ] ) [ :

El nombre-operacin es el nombre de la operacin. La lista-parmetros es una

Lista-parametros ::= parmetro [ , parmetro ]*

Parmetro ::= [ direccin ] nombre-parmetro : expresin-