Diagramas UML

UML son las siglas de “Unified Modeling Language” o “Lenguaje Unificado de

Modelado”. Se trata de un estándar que se ha adoptado a nivel internacional por
numerosos organismos y empresas para crear esquemas, diagramas y
documentación relativa a los desarrollos de software (programas informáticos).
Diagrama de clase
Un diagrama de clase es el corazón de UML. Representa los propósitos
fundamentales de UML porque separa los elementos de diseño de la codificación
del sistema. UML ha sido establecido como un modelo estandarizado para
describir un enfoque de programación orientado a objetos. Dado que las clases
son el bloque de construcción de los objetos, los diagramas de clase son los
bloques de construcción de UML. Los componentes de creación de diagramas en
un diagrama de clase pueden representar las clases que realmente van a ser
programadas, los objetos principales, o las interacciones entre clases y objetos.
Básicos de los diagramas de clase
Clase – Anatomía del diagrama

 El diagrama de clase está compuesto de tres partes:

 Sección superior – Nombre de la clase – Esta sección siempre es necesaria
sin importar si está hablando del clasificador o de un objeto
 Sección media – Atributos de la clase – Los atributos describen las
variables que describen las cualidades de la clase. Esto solamente es
necesario al describir una instancia específica de una clase.
 Sección inferior – Operaciones de la clase (métodos) – Mostrado en formato
de lista, cada operación tiene su propia línea. Las operaciones describen
cómo una clase puede interactuar con los datos.

Modificador de acceso de miembro

Todas las clases tienen diferentes niveles de acceso dependiendo del modificador
de acceso (visibilidad). Aquí tenemos los siguientes niveles de acceso con sus
símbolos correspondientes:

 Público (+)
  Privado (-)
 Protegido (#)
 Paquete (~)
 Derivado (/)
 Estático (subrayado)

Ámbito del miembro.

Hay dos ámbitos para los miembros: clasificadores e instancias. Los

clasificadores son miembros estáticos mientras que las instancias son instancias
específicas de la clase. Si está familiarizado con la teoría básica de OO, no hay
nada innovador.
Interacciones objeto / clase en los diagramas de clase

Las interacciones entre objetos y clases es una parte integral de los diagramas de
clase.

Herencia

Herencia es cuando un objeto hijo asume todas las características de su objeto

padre. Por ejemplo, si tenemos el objeto vehículo, un hijo de clase Coche
heredaría todos los atributos (velocidad, número de pasajeros, combustible) y los
métodos (moverse (), detenerse (), cambiar de dirección ()) del padre de clase
además de los atributos específicos (tipo de modelo, # de puertas, fabricante del
coche) y los métodos de su propia clase (Radio (), limpia para brisas (),
AA/calefacción ()). La herencia se muestra en un diagrama de clase usando una
línea sólida con una flecha cerrada y hueca.

Asociaciones bidireccionales
Las asociaciones bidireccionales son las asociaciones por defecto entre dos clases
y están representadas por una línea recta entre dos clases. Ambas clases son
conscientes la una de la otra y sus relaciones entre ellas. En el ejemplo anterior,
la clase Coche y la clase ViajePorCarretera están interrelacionadas. En un
extremo de la línea el Coche toma la asociación de “Coche Asignado” con el valor
de multiplicidad de 0... 1 lo que significa que cuando exista la instancia
ViajePorCarretera, puede tener una instancia de Coche asociada con ella o no
tener Coches asociados con ella. En este caso, una clase Caravana separada con
una multiplicidad de 0... * es necesaria para demostrar que ViajePorCarretera
podría tener múltiples instancias de Coches asociadas con ella. Dado que una
instancia de Coche podría tener múltiples asociaciones de “Obtener Viaje Por
Carretera” – en otras palabras, un coche podría ir a múltiples viajes por carretera
– el valor de la multiplicidad se establece en 0... *.

Asociación unidireccional

Una asociación unidireccional se dibuja como una línea continua con una punta
de flecha abierta apuntando desde la clase de complicidad a la clase conocida. En
este caso, en su viaje por carretera hacia Arizona podría correr hacia una trampa
de velocidad donde una cámara de velocidad registra su actividad de conducción,
pero no sabe sobre ella hasta que le llega la notificación por correo. No se dibuja
en la imagen, pero en este caso el valor de la multiplicidad sería 0...* en función
de la cantidad de veces que usted conduce por la cámara de velocidad.
Ejemplos de diagramas de clase UML
¿Qué es un diagrama de objetos en UML?
Un diagrama de objetos UML representa una instancia específica de un diagrama
de clases en un determinado momento en el tiempo. Cuando se lo representa
gráficamente, verás muchas similitudes con el diagrama de clases. Usamos el
mismo ejemplo de clase de coche de la página de diagramas de clases para
ilustrar los diagramas de objetos. Nuestra biblioteca de figuras UML puede
ayudarte a diseñar cualquier diagrama de objetos personalizado por medio de
nuestra herramienta UML en línea.
Diagrama de objetos vs. Diagrama de clases

Ejemplo de diagrama de objetos

Ejemplo de diagrama de clases

Un diagrama de objetos se enfoca en los atributos de un conjunto de objetos y
cómo esos objetos se relacionan entre sí. Por ejemplo, en el siguiente diagrama de
objetos, las tres cuentas bancarias están ligadas al banco mismo. Los títulos de
clase muestran el tipo de cuentas (ahorros, corriente y tarjeta de crédito) que un
cliente dado podría tener con este banco en particular. Los atributos de clase son
diferentes para cada tipo de cuenta. Esto se ilustra por el hecho de que el objeto
de tarjeta de crédito tiene un límite de crédito, mientras que las cuentas de
ahorros y corriente tienen tasas de interés. El diagrama de objetos no está
limitado a casos de uso bancario. Puedes crear un diagrama de objetos para
árboles genealógicos, departamentos corporativos, es decir, cualquier sistema con
partes interrelacionadas.

Aplicaciones de los diagramas de objetos

Hay muchos casos en los que a un desarrollador le resultarían útiles los
diagramas de objetos. Dichos casos incluyen:
Revisión de una iteración específica de un sistema general.
Obtención de una vista de nivel alto del sistema que desarrollarás.

Prueba de un diagrama de clases que creaste para la estructura general del

sistema, por medio de diagramas de objetos para casos de uso específicos.
Elementos de los diagramas de objetos

Los diagramas de objetos son sencillos de crear: se componen de objetos,

representados por rectángulos, conectados mediante líneas. Estos son los
elementos principales de un diagrama de objetos:
Objetos - son instancias de una clase. Si un coche es una clase, un Altima 2007
de Nissan es un objeto de una clase. Los objetos en la clase "Padres" son tus
padres específicos, por ejemplo, Elaine y Gary.
Títulos de clases - los atributos específicos de la clase. En el diagrama de objetos
de árbol genealógico, se trata del nombre, género y edad de los integrantes de la
familia. Se pueden enumerar como elementos en el objeto o incluso en las
propiedades del propio objeto (p. ej., color).
Atributos de clases - un rectángulo con dos pestañas que indica un elemento de
software.
Enlaces - se trata de las líneas que conectan un objeto con otro. El diagrama de
objetos corporativo siguiente muestra cómo los departamentos están conectados
en un estilo de organigrama tradicional.

Otros ejemplos de diagramas de objetos UML

Las especificaciones UML realmente no cambian cuando describimos un

diagrama de objetos en diferentes lenguajes de programación. La idea de UML es
que podamos planificar software independientemente de las plataformas
específicas. A continuación se encuentran los tipos de diagramas de objetos más
comúnmente buscados en diferentes lenguajes de programación.
Diagrama de objetos en Objetive C
Objetive C se ha vuelto muy popular desde el lanzamiento de "Objetive C 2.0" de
Apple, y ahora es el lenguaje de programación preferido para las aplicaciones de
la tienda virtual de Apple. Alguien que busque un diagrama de objetos en
Objetive C probablemente esté intentando mostrar instancias de una aplicación
de iPhone.
Diagrama de objetos en Java

Este término requiere un poco de desambiguación. Hay diagramas de objetos que

se pueden usar en UML para describir instancias que se pueden programar en
Java en última instancia. También existen diagramas que describen objetos Java
que no tienen nada que ver con UML. Ya sea que busques los primeros o los
últimos.
Qué es un diagrama de secuencia

Para comprender qué es un diagrama de secuencia, es importante saber cuál es

el rol de UML. UML o el lenguaje unificado de modelado es un conjunto de
herramientas de modelado que dirige la creación y notación de muchos tipos de
diagramas, incluidos los diagramas de comportamiento, diagramas de interacción
y diagramas de estructura. Los diagramas de secuencia son un tipo de diagrama
de interacción porque describen cómo un grupo de objetos trabaja en conjunto y
en qué orden lo hacen. Tanto los desarrolladores de software como los
empresarios usan estos diagramas para comprender los requisitos de un sistema
nuevo o documentar un proceso existente. Los diagramas de secuencia a veces se
conocen como diagramas de eventos o escenarios de eventos.
Recuerda que hay dos tipos de diagramas de secuencia: los que se basan en UML
y los que se basan en un código. Los últimos se obtienen de un código de
programación y no estarán incluidos en esta guía.
Usos de los diagramas de secuencia

Los diagramas de secuencia pueden ser diagramas de referencia útiles para las
empresas y otras organizaciones. Intenta dibujar un diagrama de secuencia para:
Representa los detalles de un caso de uso en UML.
Modelar la lógica de una operación, una función o un procedimiento sofisticados.
Ver cómo las tareas se mueven entre los objetos o componentes de un proceso.

Planificar y comprender la funcionalidad detallada de un escenario actual o

futuro
COMPONENTES DE LOS DIAGRAMAS DE SECUENCIA

Para comprender qué es un diagrama de secuencia, debes estar familiarizado con

sus componentes. Los diagramas de secuencia están formados por los siguientes
elementos:

Símbolo de objeto

Esta figura de caja representa una clase u objeto en UML. Demuestra

cómo se comportará un objeto en el contexto del sistema. Los atributos de las
clases no deben aparecer en esta figura.
Casilla de activación

Simbolizada con una figura rectangular, una casilla de activación

representa el tiempo necesario para que un objeto finalice una tarea. Cuanto más
tiempo lleve la tarea, más larga será la casilla de activación.
Símbolo de actor

Se muestran con una figura de varilla. Los actores son entidades que
interactúan con el sistema, pero que son externos a este.
Símbolo de paquete

También conocido como marco, es una figura rectangular que se usa en

la notación UML 2.0 para contener los elementos interactivos del diagrama. Esta
figura contiene un pequeño rectángulo interior para etiquetar el diagrama.
Símbolo de línea de vida

Una línea vertical discontinua que representa el paso del tiempo a

medida que se extiende hacia abajo. Además del tiempo, representa eventos
secuenciales que le ocurren a un objeto durante el proceso graficado. Las líneas
de vida pueden comenzar con una figura rectangular etiquetada o un símbolo de
actor.
 Símbolo de bucle de opción

Una figura rectangular que contiene dentro una etiqueta más pequeña.
Este símbolo se emplea para modelar escenarios del tipo "Si... entonces...", es
decir, una circunstancia que solo sucederá en determinadas condiciones.
Símbolo de alternativas

Se usan para simbolizar una decisión (que, por lo general, es

mutuamente exclusiva) entre dos o más secuencias de mensajes. Para
representar alternativas, emplea la figura rectangular etiquetada con una línea
discontinua en su interior.
Símbolos de mensajes de secuencia UML

Paquetes de información que se transmiten entre los objetos. Pueden reflejar el

inicio y la ejecución de una operación o el envío y la recepción de una señal.
Símbolo de mensaje sincrónico

Representados por una línea continua y una punta de flecha sólida. Este
símbolo se utiliza cuando un remitente debe esperar una respuesta a un mensaje
antes de proseguir. El diagrama debe mostrar el mensaje y la respuesta.
Símbolo de mensaje asincrónico
Representados por una línea continua y una punta de flecha simple. Los
mensajes asincrónicos son aquellos que no necesitan una respuesta para que el
remitente siga adelante. Solo la llamada se debe incluir en el diagrama.
Símbolo de mensaje de respuesta asincrónico
Representados por una línea discontinua y una punta de flecha simple.
Símbolo de crear mensaje asincrónico
Representados por una línea discontinua y una punta de flecha simple.
Estos mensajes se envían a las líneas de vida para crearse por sí solos.
Símbolo de mensaje de respuesta

Están representados con una línea discontinua y una punta de flecha

simple. Estos mensajes son las respuestas a las llamadas.
Símbolo de eliminar mensaje

Están representados por una línea continua y una punta de flecha

sólida, seguida de un símbolo X. Estos mensajes indican la destrucción de un
objeto y están ubicados en su ruta de la línea de vida.

Ejemplos de diagramas de secuencia UML

Este diagrama de secuencia desglosa el sistema de creación y anuncio de un
nuevo evento en un calendario. Una situación como esta ocurre siempre que usas
el Calendario de Google para programar una reunión de trabajo o una cita que no
te puedes perder.

Usos populares del diagrama de secuencia

Escenario de uso - Un escenario de uso es un diagrama de cómo se podría usar
tu sistema potencialmente. Es una excelente manera de asegurar que has
estudiado la lógica de cada escenario de uso para el sistema.
Lógica del método - Al igual que utilizarías un diagrama de secuencia UML para
explorar la lógica de un caso de uso, puedes usarlo para explorar la lógica de
cualquier función, procedimiento o proceso complejo.
Lógica de servicio - Si consideras que un servicio es un método de alto nivel
empleado por diferentes clientes, un diagrama de secuencia es una forma ideal de
trazarlo.
Diagrama de secuencia Visio - Todo diagrama de secuencia que crees con Visio
también se podrá subir a Lucidchart. Lucidchart permite la importación de
archivos .vsd y .vdx y es una excelente alternativa a Microsoft Visio.

Diagramas de Casos de Uso

El diagrama de casos de uso representa la forma en como un Cliente (Actor) opera

con el sistema en desarrollo, además de la forma, tipo y orden en como los
elementos interactúan (operaciones o casos de uso). Un diagrama de casos de uso
consta de los siguientes elementos:
 Actor.
Casos de Uso.
Relaciones de Uso, Herencia y Comunicación.
Elementos
Actor

Una definición previa, es que un Actor es un rol que un usuario juega co

n respecto al sistema. Es importante destacar el uso de la palabra rol, pues con
esto se especifica que un Actor no necesariamente representa a una persona en
particular, sino más bien la labor que realiza frente al sistema.
Como ejemplo a la definición anterior, tenemos el caso de un sistema de ventas
en que el rol de Vendedor con respecto al sistema puede ser realizado por un
Vendedor o bien por el Jefe de Local.
Caso de Uso

Es una operación o tarea específica que se realiza tras una orden de algún agente
externo, sea desde una petición de un actor o bien desde la invocación desde otro
caso de uso.

Nombre Descripción Símbolo

Las relaciones se explicaron de manera específica en el apartado 1.2.4 de este módulo,

Relaciones ahora se explica de manera sencilla para observar su uso dentro de los diagramas de casos
de uso.

Es el tipo de relación más básica que indica la invocación desde un actor o caso de uso a
Asociación
otra operación (caso de uso). Dicha relación se denota con una flecha simple.
Dependencia o Es una forma muy particular de relación entre clases, en la cual una clase depende
Instanciación de otra, es decir, se instancia (se crea). Dicha relación se denota con una flecha punteada.

Este tipo de relación es uno de los más utilizados, cumple una doble función dependiendo de
Generalización su estereotipo, que puede ser de Uso (<<uses>>) o de Herencia (<<extends>>).

Este tipo de relación está orientado exclusivamente para casos de uso (y no para actores).
extends Se recomienda utilizar cuando un caso de uso es similar a otro (características). <<extends>>

Se recomienda utilizar cuando se tiene un conjunto de características que son similares en

Uses <<uses>>
más de un caso de uso y no se desea mantener copiada la descripción de la característica.

De lo anterior cabe mencionar que tiene el mismo paradigma en diseño y

modelamiento de clases, en donde está la duda clásica de usar o heredar.

Ejemplo: Como ejemplo está el caso de una Máquina Recicladora: Sistema que
controla
una máquina de reciclamiento de botellas, tarros y jabas. El sistema debe
controlar y/o aceptar lo siguiente:

Registrar el número de ítems ingresados.

Imprimir un recibo cuando el usuario lo solicita: El usuario/cliente presiona el

botón de comienzo
Describe lo depositado
El valor de cada ítem
Total
Existe un operador que desea saber lo siguiente:
Cuantos ítems han sido retornados en el día.

Al final de cada día el operador solicita un resumen de todo lo depositado

en el día.
El operador debe además poder cambiar:
Información asociada a ítems.
Dar una alarma en el caso de que:
Ítem se atora.
No hay más papel.

Como una primera aproximación identificamos a los actores que interactúan con
el sistema:
Luego, tenemos que un Cliente puede Depositar Ítems y un Operador puede
cambiar la información de un Ítem o bien puede Imprimir un informe:

Además podemos notar que un ítem puede ser una Botella, un Tarro o una Jaba.

Otro aspecto es la impresión de comprobantes, que puede ser realizada después

de depositar algún ítem por un cliente o bien puede ser realizada a petición de un
operador.
Entonces, el diseño completo del diagrama casos de uso es: