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

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

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

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

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

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

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.

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

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 crear instancias de estas clases.

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

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

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

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

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

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

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

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

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

Representación visual de una categoría en un diagrama EER