Elementos

Elementos de
de UML
UML

Elementos de UML

Diagrama de casos de uso

Los diagramas de casos de uso describen las relaciones y las dependencias entre un
grupo de casos de uso y los actores que participan en el proceso.

Es importante tener en cuenta que los diagramas de casos de uso no son apropiados
para representar el diseño y que no pueden describir las interioridades de un sistema.
Los diagramas de casos de uso sirven para facilitar la comunicación con los futuros
usuarios del sistema y con el cliente, y resultan de especial interés para determinar las
funciones que debe poseer el sistema. Los diagramas de casos de uso revelan qué debe
hacer el sistema, pero no (ni pueden especificar) cómo deben hacerlo.

Umbrello UML Modeller mostrando un diagrama de casos de uso

Caso de uso

Un caso de uso describe (desde el punto de vista de los actores) un grupo de actividades
en un sistema que produce un resultado concreto y tangible.
Los casos de uso son descripciones de las interacciones típicas entre los usuarios de un
sistema y el mismo sistema. Representan la interfaz externa del sistema y especifican
una forma de los requisitos que el sistema debe cumplir (recuerde, solo lo que debe
hacer, no cómo debe hacerlo).

Cuando trabaje con casos de uso es importante que recuerde algunas reglas simples:

Cada caso de uso está relacionado con al menos un actor

Cada caso de uso posee un iniciador (es decir, un actor)

Cada caso de uso lleva a un resultado relevante (un resultado con «valor de
negocio»)

Los casos de uso también pueden tener relaciones con otros casos de uso. Los tres tipos
más frecuentes de relaciones entre casos de uso son:

<<inclusión>>, que indica que un caso de uso tiene lugar dentro de otro caso de
uso.

<<extensión>>, que indica que en cierta situación o en algún punto (denominado

punto de extensión), un caso de uso será extendido por otro.

Generalización, que indica que un caso de uso hereda las características de otro
«supercaso de uso» y puede redefinir algunas de ellas o añadir otras nuevas de un
modo similar a la herencia entre clases.

Actor

Un actor es una entidad externa (situada fuera del sistema) que interactúa con el sistema
participando en (y a menudo iniciando) un caso de uso. Los actores pueden ser personas
de la vida real (por ejemplo, los usuarios del sistema), sistemas de computadoras o
eventos externos.

Los actores no representan a personas físicas ni a sistemas, sino a su rol. Esto significa
que cuando una persona interactúa con el sistema de formas distintas (asumiendo
diferentes roles), estará representada por varios actores. Por ejemplo, una persona que
da soporte telefónico al cliente e introduce pedidos del cliente en el sistema estaría
representada por un actor «Equipo de apoyo» y un actor «Agente de ventas».

Descripción del caso de uso

Las descripciones de los casos de uso son narraciones textuales de los mismos. Suelen
adoptar la forma de una nota o de un documento enlazado de algún modo con el caso de
uso y explican los procesos o las actividades que tienen lugar en el caso de uso.

Diagrama de clase
Los diagramas de clase muestran las distintas clases que componen un sistema y cómo
se relacionan entre sí. Se dice que los diagramas de clase son «estáticos» porque
muestran las clases, junto a sus métodos y atributos, así como las relaciones estáticas
entre ellos: qué clases «conocen» a otras clases, o qué clases «son parte» de otra clase,
aunque no muestran las llamadas a los métodos entre ellas.

Umbrello UML Modeller mostrando un diagrama de clase

Clase

Una clase define los atributos y los métodos de un conjunto de objetos. Todos los objetos
de una clase (instancias de la clase) comparten el mismo comportamiento y poseen el
mismo conjunto de atributos (cada objeto tiene su propio conjunto). A veces se usa el
término «tipo» en lugar de «clase», pero es importante tener presente que no son lo
mismo, ya que «tipo» es un término más general.

En UML, las clases se representan por rectángulos con el nombre de la clase, que
pueden mostrar los atributos y las operaciones de la clase en dos «compartimentos»
dentro del rectángulo.

Representación visual de una clase en UML

Atributos
En UML, los atributos se muestran como mínimo con su nombre, aunque también
pueden mostrar su tipo, su valor inicial y otras propiedades. Los atributos también se
pueden mostrar con su visibilidad:

+ representa atributos públicos

# representa atributos protegidos

- representa atributos privados

Operaciones

Las operaciones (métodos) también se muestran como mínimo con su nombre, aunque
pueden mostrar también sus parámetros y los tipos que devuelven. Las operaciones
pueden, al igual que los atributos, mostrar su visibilidad:

+ representa operaciones públicas

# representa operaciones protegidas

- representa operaciones privadas

Plantillas

Las clases pueden tener plantillas, un valor que se usa para una clase o un tipo sin
especificar. El tipo de la plantilla se especifica cuando se inicia la clase (es decir, cuando
se crea un objeto). Las plantillas existen en C++ moderno y se introducirán en Java 1.5,
donde se llamarán «genéricas».

Asociaciones de clases

Las clases se pueden relacionar (estar asociadas) con otras de diferentes modos:

Generalización

La herencia es uno de los conceptos fundamentales de la programación orientada a

objetos, en la que una clase «gana» todos los atributos y las operaciones de la clase de
la que hereda, y puede redefinir o modificar algunos de ellos, así como añadir más
atributos y operaciones propios.

En UML, una asociación de generalización entre dos clases las coloca en una jerarquía
que representa el concepto de herencia de una clase derivada a partir de una clase base.
En UML, las generalizaciones se representan con una línea que conecta las dos clases,
con una flecha en el lado de la clase base.
 Representación visual de una generalización en UML

Asociaciones

Una asociación representa una relación entre clases, y proporciona la semántica y

estructura común para muchos tipos de «conexiones» entre objetos.

Las asociaciones son el mecanismo que permite que los objetos se comuniquen entre sí.
Describe la conexión entre diferentes clases (la conexión entre objetos reales se
denomina «conexión de objetos» o enlace).

Las asociaciones pueden tener un rol que indica el propósito de la asociación y pueden
ser unidireccionales o bidireccionales (indica si los dos objetos que participan en la
relación pueden enviar mensajes del uno al otro, o si solo uno de ellos tiene conocimiento
del otro). Cada extremo de la asociación también posee un valor de multiplicidad, que
dicta cuántos objetos a dicho lado de la asociación pueden relacionarse con un objeto del
otro lado.

En UML, las asociaciones se representan con líneas que conectan las clases que
participan en la relación, y que también pueden mostrar el rol y la multiplicidad de cada
uno de los participantes. La multiplicidad se muestra como un intervalo [mín..máx] de
valores no negativos, con una estrella (*) en el extremo máximo para representar el
infinito.

Representación visual de una asociación en UML

Agregación

Una agregación es un tipo especial de asociación en la que las dos clases participantes
no poseen un estado de igualdad, aunque forman una relación «completa». Una
agregación describe cómo la clase que tiene el papel del todo se compone de otras
clases (las posee), que tienen el papel de las partes. Para las agregaciones, las clases
que actúan como el todo siempre tienen una multiplicidad de uno.
En UML, las agregaciones se representan mediante una asociación que muestra un
rombo en la parte del todo.

Representación visual de una relación de agregación en UML

Composición

Las composiciones son asociaciones que representan agregaciones muy fuertes. Esto
significa que las composiciones también forman relaciones todo-parte, aunque la relación
es tan fuerte que las partes no pueden existir por sí mismas: solo pueden existir dentro
del todo y, si el todo se destruye, las partes también se destruirían.

En UML, las composiciones se representan con un rombo sólido en la parte del todo.

Otros elementos de los diagramas de clases

Los diagramas de clases pueden contener otros elementos distintos las clases.

Interfaces

Las interfaces son clases abstractas, lo que significa que no se pueden crear
directamente instancias de ellas. Pueden contener operaciones, pero no atributos. Las
clases pueden heredar de interfaces (mediante una asociación de realización), en cuyo
caso se pueden hacer instancias de estos diagramas.

Tipo de datos

Los tipos de datos son primitivas que se se suelen integrar en los lenguajes de
programación. Ejemplos típicos son los enteros y los booleanos. No pueden tener
relaciones con las clases, aunque las clases sí pueden tener relaciones con ellos.

Enumeraciones

Una enumeración es una simple lista de valores. Un ejemplo típico es una enumeración
de los días de la semana. Las opciones de una enumeración se llaman «literales de
enumeración». Como los tipos de datos, no pueden tener relaciones con las clases,
aunque las clases sí pueden tener relación con ellas.
Paquetes

Los paquetes representan un espacio de nombres de un lenguaje de programación. Se

usan en los diagramas para representar partes de un sistema que contienen más de una
clase (posiblemente cientos de clases).

Diagramas de secuencia

Los diagramas de secuencia muestran el intercambio de mensajes (es decir, llamadas a

métodos) entre varios objetos en una situación específica delimitada por un tiempo. Los
objetos son instancias de clases. Los diagramas de secuencia ponen especial énfasis en
el orden y en las veces que se envían mensajes a los objetos.

En los diagramas de secuencia, los objetos se representan mediante líneas discontinuas

verticales con el nombre de los objetos en la parte superior. El eje del tiempo también es
vertical, incrementándose hacia abajo, de modo que los mensajes se envían de un objeto
a otro en forma de flechas, con el nombre de la operación y los parámetros.

Umbrello UML Modeller mostrando un diagrama de secuencia

Los mensajes pueden ser sincrónicos, el tipo normal de llamada de mensaje donde el
control se pasa al objeto llamado hasta que dicho método haya terminado su ejecución, o
asincrónicos, donde el control se devuelve directamente al objeto que realiza la llamada.
Los mensajes sincrónicos disponen de un rectángulo vertical en el lado del objeto
llamado para mostrar el flujo del control del programa.

Diagramas de colaboración
Los diagramas de colaboración muestran las interacciones que ocurren entre los objetos
que participan en una determinada situación. Esta es más o menos la misma información
que muestran los diagramas de secuencia, aunque en ellos el énfasis recae en cómo
ocurren las interacciones con el paso del tiempo, mientras que los diagramas de
colaboración ponen de relieve las relaciones entre los objetos y su topología.

En los diagramas de colaboración, los mensajes enviados de un objeto a otro se

representan mediante flechas que muestran el nombre del mensaje, sus parámetros y su
secuencia. Los diagramas de colaboración son apropiados para mostrar el flujo
específico de un programa o de una situación y son uno de los mejores tipos de
diagramas para mostrar o explicar rápidamente un proceso con la lógica del programa.

Umbrello UML Modeller mostrando un diagrama de colaboración

Diagrama de estados

Los diagramas de estados muestran los diferentes estados de un objeto durante su vida
y los estímulos que hacen que el objeto cambie su estado.

Los diagramas de estados ven los objetos como máquinas de estados o autómatas
finitos que pueden estar en uno de un conjunto finito de estados y que pueden cambiar
su estado mediante uno de un conjunto finito de estímulos. Por ejemplo, un objeto de tipo
ServidorDeRed puede estar en uno de los siguientes estados durante su vida:

Preparado

A la escucha

Trabajando
 Detenido

y los eventos que pueden hacer que el objeto cambie de estado son

El objeto se ha creado

El objeto recibe un mensaje de escucha

Un cliente solicita una conexión a través de la red

Un cliente termina una petición

La petición se ejecuta y termina

El objeto recibe un mensaje de detención

etc.

Umbrello UML Modeller mostrando un diagrama de estados

Estado

Los estados son las piezas fundamentales de los diagramas de estado. Un estado
pertenece a exactamente una clase y representa un resumen de los valores que pueden
tener los atributos de una clase. Un estado de UML describe el estado interno de un
objeto de una determinada clase.
Tenga en cuenta que no todos los cambios en uno de los atributos de un objeto se deben
representar mediante un estado, sino solo aquellos cambios que puedan afectar
significativamente el funcionamiento de dicho objeto.

Existen dos tipo especiales de estados: «Inicial» y «Final». Son especiales porque no
existe ningún evento que pueda hacer que un objeto vuelva a su estado inicial ni que
pueda sacarlo de su estado final una vez lo haya alcanzado.

Diagrama de actividades

Los diagramas de actividades describen la secuencia de actividades de un sistema con la

ayuda de actividades. Los diagramas de actividades son una forma especial de los
diagramas de estados que solo (o principalmente) contienen actividades.

Umbrello UML Modeller mostrando un diagrama de actividades

Los diagramas de actividades son similares a los diagramas procedimentales de flujo,

con la diferencia de que todas las actividades están claramente conectadas con los
objetos.

Los diagramas de actividades están siempre asociados a una clase, a una operación o a
un caso de uso.

Los diagramas de actividades permiten el uso de actividades secuenciales o en paralelo.

La ejecución en paralelo se representa mediante iconos de bifurcación y de espera. Para
las actividades que se ejecutan en paralelo, no es importante el orden en que se llevan a
cabo (ya que se pueden ejecutar al mismo tiempo o una tras la otra).

Actividad

Una actividad es un paso único de un proceso. Una actividad es un estado de un sistema

con actividad interna y, al menos, una transición de salida. Las actividades también
pueden tener más de una transición de salida si poseen distintas condiciones.

Las actividades pueden formar jerarquías, lo que significa que una actividad se puede
componer de varias actividades «detalladas», en cuyo caso las transiciones de entrada y
de salida deben corresponderse con las transiciones de entrada y de salida del diagrama
detallado.

Elementos auxiliares

Existen varios elementos en UML que no poseen un valor semántico real para el modelo,
sino que ayudan a clarificar partes del diagrama. Estos elementos son:

Líneas de texto

Notas de texto y anclajes

Cuadros

Las líneas de texto son útiles para añadir cortas informaciones de texto a un diagrama.
Son textos libres y no poseen ningún significado para el modelo.

Las notas son útiles para añadir información más detallada sobre un objeto o sobre una
situación determinada. Tienen la gran ventaja de que se pueden asociar a elementos de
UML para mostrar que la nota «pertenece» a un determinado objeto o situación.

Los cuadros son rectángulos libres que se pueden usar para agrupar elementos para
facilitar la legibilidad de los diagramas. No poseen ningún significado lógico en el modelo.

Diagramas de componentes

Los diagramas de componentes muestran los componentes de software (ya sean

tecnologías de componentes, como KParts, CORBA o Java Beans, o solo secciones de
un sistema que se puedan distinguir claramente) y los artefactos de los que se
componen, como archivos de código fuente, bibliotecas de programación o tablas de
bases de datos relacionales.

Los componentes pueden tener interfaces (es decir, clases abstractas con operaciones)
que permiten asociaciones entre componentes.

Diagramas de despliegue
Los diagramas de despliegue muestran las instancias de los componentes en tiempo de
ejecución y sus asociaciones. Incluyen nodos, que son recursos físicos (normalmente,
una única computadora). También muestran interfaces y objetos (instancias de clases).

Diagramas entidad-relación

Los diagramas entidad-relación (diagramas ER) muestran el diseño conceptual de

aplicaciones de bases de datos. Describen las distintas entidades (conceptos) del
sistema de información y las relaciones y restricciones existentes entre ellos. Una
extensión de los diagramas entidad-relación, denominada «diagramas entidad-relación
extendidos» o «diagramas entidad-relación avanzados» (EER), se usa para incorporar
técnicas de diseño orientadas a objetos en los diagramas ER.

Umbrello mostrando un diagrama entidad-relación

Entidad

Una entidad es cualquier concepto del mundo real con una existencia independiente.
Puede ser un objeto con una existencia física (por ejemplo, una computadora o un robot)
o un objeto con una existencia conceptual (por ejemplo, un curso universitario). Cada
entidad posee un conjunto de atributos que describen sus propiedades.

Nota: No existe una notación estándar para representar diagramas ER. Diferentes textos
sobre este tema usan distintas notaciones. Los conceptos y notaciones para los
diagramas ER que usa Umbrello se han tomado del libro Fundamentos de sistemas de
bases de datos, 4ª edición, de Elmasri R. y Navathe S. (2004), Addison Wesley.

En un diagrama ER, las entidades se representan mediante rectángulos, con el nombre

de la entidad en la parte superior. También pueden mostrar los atributos de la entidad en
otro «compartimento» dentro del rectángulo.

Representación visual de una entidad en un diagrama ER

Atributos de las entidades

En los diagramas ER, los atributos de las identidades se muestran con su nombre en un
compartimento distinto de la entidad a la que pertenecen.

Restricciones

Las restricciones de los diagramas ER indican las restricciones de los datos en el

esquema de información.

Existen cuatro tipos de restricciones que permite usar Umbrello:

Clave primaria: El conjunto de atributos declarado como clave primaria es único

para la entidad. Solo puede existir una clave primaria en una entidad y ninguno de
los atributos que la constituyen puede ser nulo.

Clave única: El conjunto de atributos declarado como clave única es único para la
entidad. Pueden existir varias restricciones únicas en una entidad. Los atributos que
la constituyen pueden ser nulos. Las claves únicas y las claves primarias identifican
unívocamente una fila de una tabla (entidad).

Clave externa: Una clave externa es una restricción referencial entre dos tablas. La
clave externa identifica a una columna o a un conjunto de columnas de una tabla
que hacen referencia a una columna o a un conjunto de columnas de otra tabla. Las
columnas de la tabla referenciada deben formar una clave primaria o una clave
única.

Restricción de comprobación: Una restricción de comprobación (también conocida

como «restricción de comprobación de tabla») es una condición que define datos
válidos cuando se añade o se actualiza una entrada de un a tabla de una base de
datos relacional. Se aplica una restricción de comprobación a cada rila de la tabla.
 La restricción debe ser un predicado. Se puede referir a una o a varias columnas de
la tabla.

Ejemplo: precio >= 0

Conceptos de diagramas entidad-relación extendidos (EER)

Especialización

La especialización es un modo de formar nuevas entidades usando entidades ya

definidas. Las nuevas entidades, conocidas como entidades derivadas, poseen (o
heredan) los atributos de las entidades preexistentes, a las que se refieren como
entidades base. Están pensadas para ayudar a reutilizar los datos existentes con pocas o
ninguna modificaciones.

En Umbrello se puede especificar especialización de disyunción y de solapamiento.

Especialización de disyunción

La especialización de disyunción indica que las subclases de la especialización deben

ser disyuntivas. Esto significa que una entidad puede ser miembro de un máximo de una
de las entidades derivadas de la especialización.

Representación visual de una especialización de disyunción en un diagrama

EER

Especialización de solapamiento
Cuando las entidades derivadas no están restringidas para ser disyuntivas, se dice que
su conjunto de entidades está en una especialización de solapamiento. Esto significa que
la misma entidad del mundo real puede ser miembro de más de una entidad derivada de
la especialización.

Representación visual de una especialización de solapamiento en un diagrama

EER

Categoría

Se dice que una entidad derivada es una categoría cuando representa a una colección
de objetos que es un subconjunto de la unión de los distintos tipos de entidades. Una
categoría se modela cuando existe la necesidad de una relación de una
superclase/subclase con más de una superclase, donde las superclases representan
distintos tipos de entidades (muy parecido a la herencia múltiple de la programación
orientada a objetos).
Representación visual de una categoría en un diagrama EER