Diagrama Descripción Elementos Vista

Clases Tipo de diagrama que describe la estructura de un Clases Estática

sistema mostrando sus clases, atributos y las Atributos
relaciones entre ellos. Relaciones

CDU Un caso de uso es una descripción de un conjunto

de secuencias de acciones y variantes, ejecutadas
por un sistema para producir un resultado
observable de un valor para el actor.

Estado representa una máquina de estados, constituida

por estados transiciones, eventos y actividades.
Modelan el comportamiento de una interfaz, una
clase o una colaboración. Resaltan el
comportamiento dirigido por eventos de un objeto.

Entidad Relación

Despliegue muestra un conjunto de nodos y sus relaciones. nodos estática

Describen la vista de despliegue estática de una
arquitectura.

Matriz de riesgo

Actividad muestra un conjunto de acciones, el flujo secuencial

o ramificado de acción en acción, y los valores que
son producidos o consumidos por las acciones.

Secuencia es un diagrama de interacción que resalta la Dinámica

ordenación temporal de los mensajes. Un diagrama
de secuencia presenta un conjunto de roles y los
mensajes enviados y recibidos por las instancias
que interpretan los roles.

Colaboración es un diagrama que muestra interacciones

organizadas alrededor de los roles. Muestra cómo
las instancias específicas de las clases trabajan
juntas para conseguir un objetivo común.
Implementa las asociaciones del diagrama de
clases mediante el paso de mensajes de un objeto
a otro. Dicha implementación es llamada "enlace".
Qué es una Clase?

Una clase es una descripción de un grupo o conjunto de objetos que tienen en común atributos,
relaciones, operaciones y semánticas.
Las utilizamos para capturar el vocabulario de un sistema en desarrollo. Estas clases pueden incluir
abstracciones que formen parte del dominio del problema, así como clases que constituyan una
implementación. Las clases se pueden utilizar para representar cosas que sean software, hardware o
cosas puramente conceptuales.
Gráficamente una clase se representa con un rectángulo.

Definamos 'Nombre' para una clase

Un nombre es una cadena de texto. Ese nombre lo definimos como nombre simple; un nombre
calificado consta del nombre de la clase precedido por el nombre del paquete(con paquete nos
referimos a un conjunto en el cual podemos agrupar todo tipo de datos, ya sean clases, casos de
uso u otros paquetes, Ej; paquete diccionario clase letraA se denomina diccionario::letraA) en el
que se encuentra. A las clases las podemos dibujar mostrando sólo su nombre.

Definamos 'Atributo' para una clase

Un atributo es una propiedad de una clase a la que identificamos con un nombre, describe un rango de
valores que pueden tomar las instancias de la propiedad. Una clase puede tener varios atributos o
ninguno. Un atributo representa alguna propiedad del elemento que se está modelando que es
compartida por todos los objetos de una clase.
Un atributo es una abstracción de un tipo de dato o estado que puede incluir un objeto de la clase.
Gráficamente, los atributos se listan en un compartimento justo debajo del nombre de la clase.

Definamos 'Operación' para una clase

Una operación es la implementación de un servicio que puede ser requerido a cualquier objeto de la
clase para que muestre un comportamiento.
Una operación es una abstracción de algo que se le puede hacer a un objeto y que es compartido por
todos los objetos de la clase.
Una clase puede tener cualquier número de operaciones o ninguna.
Gráficamente, las operaciones se listan en un compartimento justo debajo de los atributos de la clase.
El nombre de una operación puede ser texto, igual que el nombre de una clase. En la práctica, el nombre
de una operación es un verbo corto o una expresión verbal que representa un compartimento de la clase
que la contiene

Definamos 'Responsabilidad' para una clase

Una responsabilidad es un contrato o una obligación de una clase. Al crear una clase, se está
expresando que todos los objetos de esa clase tienen el mismo tipo de estado y el mismo tipo de
comportamiento.
A un nivel más abstracto, estos atributos y operaciones son simplemente las características por medio de
las cuales se llevan a cabo las responsabilidades de la clase.
Al modelar clases, un interesante punto de partida consiste en especificar las responsabilidades de los
elementos del vocabulario. Una clase puede tener cualquier número de responsabilidades, aunque, en la
práctica, cada clase bien estructurada tiene al menos una responsabilidad y a lo sumo, unas pocas.
¿De que se tratan las Relaciones en UML?
Al realizar abstracciones(crear clases) uno puede observar que muy pocas clases se encuentran
aisladas, en su mayoría colaboran entre sí de varias maneras. Por lo cual, mientras modelamos un
sistema no solamente hay que identificar los elementos que conforman el vocabulario del mismo, sino
que también hay que modelar cómo se relacionan estos elementos entre sí.

En UML hay tres tipos de relaciones:

● Dependencias

● Generalizaciones

● Asociaciones

Cada una de estas relaciones proporciona una forma diferente de combinar las abstracciones(clases).

¿Qué es la Dependencia?

Cuando hablamos de dependencia, nos referimos a una relación de uso que declara un elemento, utiliza
la información y servicios de otro elemento, pero no necesariamente a la inversa.

La mayoría de las veces las dependencias se utilizaran en el contexto de las clases para indicar que una
de ellas utiliza operaciones, variables o parámetros de otra. Claramente estamos hablando de una
relación de uso(si la clase utilizada cambia, la operación de la otra clase puede verse afectada también,
por que la clase utilizada puede presentar ahora una interfaz o un comportamiento diferente)

¿Qué es la Generalización?
Es una relación de especialización/generalización en la cual los objetos del elemento especializado(el
hijo) pueden sustituir a los objetos del elemento general(el padre) pero no a la inversa. El hijo comparte
la estructura y el comportamiento del padre que a menudo (pero no siempre) añade atributos y
operaciones a las que hereda. La implementación de una operación en un hijo redefine la
implementación de la misma operación del padre; esto se conoce como polimorfismo.
Una clase puede tener ninguno, uno o varios padres. Una clase sin padre y uno o mas hijo se denomina
clase raíz o clase base. Una clase sin hijos se llama clase hoja. Una clase con un único padre se dice
que utiliza herencia simple y una clase con más de un padre se dice que utiliza herencia múltiple.
Gráficamente, la generalización se representa con una línea con punta de flecha vacía .

¿Qué es la Asociación?

Una asociación es una relación estructural que especifica que los objetos de un elemento están
conectados con los objetos de otro. Dada una asociación entre clases, se puede establecer una relación
desde un objeto hasta algunos objetos de la otra clase.

Además de su forma básica encontramos cuatro formas de asociación más.

Se tratan de:

● Nombre

● Rol
 ● Multiplicidad

● Agregación

¿De que se trata 'Nombre' dentro de una Asociación?

Una asociación puede tener un nombre, utilizado para describir la naturaleza de la relación. Para que no
haya ambigüedad en su significado, se puede dar una dirección al nombre por medio de una flecha que
apunte en la dirección en la que se pretende que se lea el nombre

¿De que se trata 'Rol' dentro de una Asociación?

Cuando una clase participa en una asociación, tiene un rol específico que cumple en esa relación;
Cuando hablamos de rol, simplemente nos referimos a la cara(rol) que la clase de un extremo de la
asociación presenta a la otra del otro extremo. Puede darse un nombre explícito al rol que juega una
clase dentro de una asociación. El rol que juega una clase se denomina nombre de extremo.
(grafico)

¿De que se trata 'Multiplicidad' dentro de una Asociación?

Una asociación representa una relación estructural entre objetos. Es importante señalar cuántos objetos
pueden conectarse a través de una instancia de asociación, este proceso se denomina multiplicidad
representando un rango de enteros que especifican el tamaño posible del conjunto de objetos
relacionados.
La multiplicidad se escribe como una expresión con un valor mínimo y un valor máximo, pudiendo ser
iguales, se utilizan dos puntos consecutivos para separar ambos valores. Al indicar una multiplicidad, se
esta especificando cuantos objetos de la clase de ese extremo puede haber para cada objeto de la clase
en el otro extremo
(grafico)

¿De que se trata 'Agregación' dentro de una Asociación?

Una asociación normal entre dos clases representa una relación estructural entre iguales, es decir,
ambas clases están conceptualmente en el mismo nivel, sin ser ninguna más importante que la otra. A
veces, se desea modelar una relación "todo/parte", en la cual una clase representa una cosa grande(el
"todo), que consta de elementos más pequeños(las "partes). Este tipo de relación se denomina
agregación, la cual representa una relación del tipo "tiene un", o sea, un objeto del todo tiene objetos de
la parte. En realidad, la agregación es solo un tipo especial de asociación y se especifica añadiendo una
asociación normal un rombo vacío en la parte del todo
(grafico)

¿Qué es un Diagrama de Clases?

Un diagrama de clases es un tipo de diagrama estático que describe la estructura de un sistema
mostrando sus clases, atributos y las relaciones entre ellos. Los diagramas de clases son utilizados
durante el proceso de análisis y diseño de los sistemas, donde se crea el diseño conceptual de la
información que se manejará en el sistema, y los componentes que se encargarán del funcionamiento y
la relación entre uno y otro.
En un diagrama de clases se pueden distinguir los siguientes elementos:

● Clases
● Relaciones
 ● Responsabilidades

TÉRMINOS Y CONCEPTOS
Una nota es un símbolo gráfico para representar restricciones o comentarios asociados a un
elemento u colección de ellos, gráficamente es representada como o un rectángulo con una
esquina doblada, junto a un comentario textual o gráfico.

Un estereotipo es una extensión del vocabulario UML que permite crear nuevos tipos de
bloques de construccion similares a los existentes, pero específicos al problema que se está
modelando, gráficamente se representa como un nombre entre comillas francesas (<< >>) y se
coloca sobre el nombre de otro elemento. Opcionalmente el elemento con el estereotipo puede
dibujarse con un nuevo icono asociado a ese estereotipo.

Un valor etiquetado es una propiedad de un estereotipo que permite añadir una nueva
información en el elemento que lleva ese estereotipo. Gráficamente , un valor etiquetado se
representa como una cadena de caracteres de la forma ‘ nombre = Valor’ dentro de una nota
asociada al objeto.

Una restricción es una especificación de la semántica de un elemento de UML, que permite

añadir nuevas reglas o modificar existentes. Gráficamente se representa como una cadena de
caracteres entre llaves colocada junto al elemento al que está asociada a ese elemento o
elementos por relaciones de dependencia.(también se puede representar en una nota)

NOTAS
Se utilizan para especificar cosas
como requisitos, observaciones,
revisiones y explicaciones, además de
representar restricciones(puede
contener texto, gráficos, url activas u
otro doc).

OTROS ADORNOS
Los adornos son complementos gráficos
o textuales añadidos a la notación básica
de un elemento para mostrar detalles
como roles y la multiplicidad. La mayoría
de los adornos se muestran colocando
texto junto al elemento de interés o
añadiendo un símbolo gráfico a la notación básica. En el caso de
elementos como clases se puede añadir un compartimiento extra bajo los
comportamientos habituales para proporcionar esta información. (a menos que
sea obvio por su contenido, es bueno dar explícitamente un nombre a cualquier
compartimiento extra, para que no haya confusión sobre su significado).
ESTEREOTIPOS
Estereotipo se puede pensar como en un metatipo(un tipo que define otros
tipos) porque cada uno crea el equivalente de una nueva clase en el metamodelo de UML. No es lo
mismo que una clase padre en una relación de generalización padre/hijo.
cuando se aplica un estereotipo sobre un elemento como un nodo o una clase se está, de hecho,
entendiendo UML. Se esta creando un nuevo bloque de construcción como cualquiera de los existentes,
pero con sus propias características(cada estereotipo está habilitado a proporcionar su propio conjunto
de valores etiquetados), semántica(puede proporcionar sus propias restricciones), y notación(puede
proporcionar su propio icono)especiales.
Lo representamos como <<nombre>> y se coloca sobre el nombre de otro elemento. Como señal visual,
se puede definir un icono para y mostrar ese icono a la derecha del nombre(si se utiliza la notación
básica para el elemento) o utilizar ese icono como símbolo básico para el elemento estereotipado

VALORES ETIQUETADOS

COn ellos se pueden añadir nuevas propiedades a

un estereotipo.
Podemos definir etiquetas que se apliquen a
estereotipos individuales, de forma que cualquier
elemento con ese estereotipo tenga ese valor
etiquetado. Un valor etiquetado es diferente a un
atributo de una clase. Se puede ver un valor
etiquetado como un metadato, porque su valor se
aplica a la especificación del elemento, no a sus
instancias.

Los valores etiquetados se colocan en notas

asociadas al elemento afectado

Uno de los usos más comunes es especificar

propiedades relevantes a la generación de código
o gestión de configuraciones.

RESTRICCIONES
con las restricciones se puede añadir una nueva semántica o modificar reglas existentes. Especifica
condiciones que deben cumpñlirse en cualquier configuracion en tiempo de ejecucion para que el modelo
esté bien formado. Por ejemplo, como se muestra en la figura , se podría especificar que la
comunicación fuese encriptada a través de una determinada asociación; una configuración que violase
esta restricción sería inconsistente con el modelo. Análogamente se podría especificar que de entre un
conjunto de asociaciones conectadas a una clase, una instancia específica sólo pueda tener enlaces
correspondientes a una de las asociaciones del conjunto.
Una restricción se representa como una cadena de caracteres entre llaves junto al elemento asociado.
Esta notación también se utiliza como un adorno a la notación básica de un elemento para ver las partes
de la especificación de un elemento que no tienen representación gráfica, Por ejemplo algunas de las
propiedades de las asociaciones (orden y cambios posibles) se muestran con la notación de
restricciones.

ELEMENTOS ESTÁNDAR
En UML podemos encontrar varios
estereotipos estándar para los
clasificadores, componentes,
relaciones y otros elementos de
modelado. Hay un estereotipo
estándar, de interés principalmente para los constructores de herramientas que permite modelar los
propios estereotipos
○ stereotype especifica que el clasificador es un estereotipo
que se puede aplicar a otros elementos.
Este estereotipo se utilizará cuando se desee modelar explícitamente los estereotipos definidos para el
proyecto.

PERFILES
Un perfil es un modelo UML con un conjunto predefinido de estereotipos, valores etiquetados,
restricciones y clases básicas. A su vez incluye un subconjunto de tipos de elementos de UML para ser
utilizados, evitando que un modelador se confunda con tipos de elementos innecesarios para una de
aplicacion especifica. Un perfil define una versión especializada de UML refiriéndose a un área en
particular. Al constituirse de elementos de UML, no representa un lenguaje nuevo, y puede ser soportado
por herramientas de UML.

Capítulo 17: Casos de Uso.

Casos de Uso

Un caso de uso es una descripción de un conjunto de secuencias de acciones y variantes,

ejecutadas por un sistema para producir un resultado observable de un valor para el actor.
Gráficamente se representa como una elipse.

Los casos de uso bien estructurados denotan sólo comportamientos esenciales del sistema o
de un subsistema, y nunca deben ser excesivamente genéricos ni demasiado específicos.
Sujeto

Un sujeto es una clase (sistemas o subsistemas) descrita por un conjunto de casos de uso
(representa aspectos y comportamientos de la misma). Las clases con las que interactúa el
sujeto son descritas por los actores.

Nombre

Un nombre es una cadena de texto. El nombre del caso de uso debe ser único para distinguirlo
de otros dentro del paquete que se encuentra. Hay dos tipos de nombres:

● nombre simple: Nombre del caso de uso.

● nombre calificado: Nombre del caso de uso + Nombre del paquete que lo contiene.

Ejemplo:

El nombre puede constituirse de gran cantidad de letras, numeros y signos de

puntuación(excepto los dos puntos que se utilizan para separar el nombre del caso de uso y el
nombre del paquete que lo contiene).

Actor

Un actor es quien representa conjunto coherentes de roles que los usuarios de los casos de
uso representan al interactuar con el sistema. Estos roles pueden ser interpretados por
personas, periféricos, u otros sistemas. El actor representa una interacción individual con el
sistema de forma específica. Los actores no forman parte del sistema, están fuera de la
aplicación en el entorno que la rodea.
Los actores no necesariamente coinciden con los USUARIOS. Un usuario puede interpretar
distintos roles, correspondientes a distintos actores.
Un actor puede intervenir en varios casos de uso, que a su vez, en un caso de uso puede
necesitar varios actores para lograr su objetivo.
Una asociación entre un actor y un caso de uso indica que se comunican entre sí, y cada uno
puede enviar y recibir mensajes.

Ejemplo:

Como se ve en el ejemplo, los actores se representan como monigotes. Se pueden definir

categorías generales de actores como “Cliente” y especializarlos como “ClienteComercial”
a través de relaciones de generalización.
Hay 2 tipos de actores:

● Primarios: interaccionan con el sistema para explotar su funcionalidad; trabajan directa y

frecuentemente con el software.

● Secundarios: soporte del sistema para que los primarios puedan trabajar.

Flujo de eventos

El comportamiento de un caso de uso se puede especificar describiendo un flujo de eventos de

forma textual, lo suficientemente claro para que alguien ajeno al sistema lo entienda fácilmente.
Cuando se escribe este flujo de eventos se debe incluir cómo y cuándo empieza y acaba el
caso de uso, cuándo interactúa con los actores y qué objetos se intercambian, el flujo básico y
los flujos alternativos del comportamiento.
El flujo de eventos puede especificar de muchas formas, incluyendo texto estructurado informal
como en el ejemplo, texto estructurado formal (con pre y poscondiciones) y pseudocódigo.
Se usa un diagrama de secuencia para especificar el flujo principal y se usan variaciones de
ese diagrama para especificar los flujos excepcionales del caso de uso (es conveniente separar
los porque un caso de uso describe un conjunto de secuencias, no una única secuencia, y sería
imposible expresar todos los detalles de un caso de uso no trivial en una única secuencia
diferente).

Escenarios

Un escenario es una secuencia específica de acciones que ilustra un comportamiento. Los

escenarios son a los casos de uso lo que las instancias a las clases, es decir, un escenario es
básicamente una instancia de un caso de uso.

Colaboraciones

La colaboración es un modelado (en UML) de una sociedad de clases y otros elementos, que
colaboran para llevar a cabo el comportamiento del caso de uso.

Ejemplo:

Como se ve en el ejemplo, la realización de un caso de uso puede especificarse explícitamente

mediante una colaboración. Pero aunque la mayoría de las veces, un caso de uso es realizado
exactamente por una colaboración, no será necesario mostrar explícitamente esta relación.

nota: aunque no se pueda visualizar esta relación explícitamente, las herramientas que se
utilicen para gestionar los modelados probablemente la mantendrán.

Organización de los casos de uso

Los casos de uso pueden organizarse agrupándolos en paquetes (al igual que las
clases).También pueden organizarse especificando relaciones para factorizar el
comportamiento común (extrayendo el comportamiento de los casos de uso que lo incluyen) y
también variantes (poniendo el comportamiento de otros casos de uso que lo extienden). Estas
relaciones son:

● Generalización: Es como la generalización de clases, el caso de uso hijo hereda el

comportamiento y significado del padre y puede añadir o redefinir dicho
comportamiento. Se representa con una línea continua con una punta de flecha vacía.

● Inclusión: Es cuando un caso de uso base incorpora explícitamente el comportamiento

 de otro caso de uso. El caso de uso incluido nunca se encuentra aislado, sino que es
instanciado como parte de otro caso de uso base más amplio. La Inclusión evita
describir el mismo flujo de eventos repetidas veces, poniendo el comportamiento en un
caso de uso aparte, que será incluido por otro caso de uso base. La inclusión se
representa como una dependencia, estereotipada con “include”.

● Extensión: Es cuando un caso de uso base incorpora explícitamente el comportamiento

de otro caso de uso. Este caso de uso puede estar aislado, que en algunas ocasiones
su comportamiento se extiende con el de otro caso de uso. Se puede extender
solamente en algunos puntos, denominados “puntos de extensión”. Se representa como
una dependencia, estereotipada como “extend”. Sirve para:
1. Modelar la parte del caso de uso que el usuario ve como comportamiento
opcional (separándolo del comportamiento obligatorio).
2. Modelar un subflujo que solo se ejecuta bajo ciertas condiciones.
3. Modelar varios flujos que se pueden insertar en un punto.
4. Distinguir la parte opcional del sistema.

Técnicas comunes de modelado: Modelado del comportamiento de un elemento

Cuando se modela el comportamiento de estos elementos (modelado por el caso de uso, es

importante centrarse en lo que hace el elemento y no en cómo.
Es importante aplicar de esta forma los casos de uso a los elementos por tres razones:

1. El modelado del comportamiento de un elemento, mediante los casos de uso, permite a los
expertos del dominio especificar su vista externa del sistema a nivel suficiente para que los
desarrolladores construyan su vista interna. Los casos de uso proporcionan un foro en el que
pueden intercambiar opiniones los expertos del dominio, los usuarios finales y los
desarrolladores.

2. Los casos de uso proporcionan a los desarrolladores una forma de abordar y comprender un
elemento. Un sistema,subsistema o una clase pueden ser complejos y estar repletos de
 operaciones y otras partes. Cuando se especifican los casos de uso de un elemento, se
ayuda a que los usuarios de ese elemento lo puedan abordar directamente, de acuerdo con
el modo en que ellos utilizarán el sistema. En ausencia de estos casos de uso, los usuarios
tendrán que descubrir por su cuenta cómo usar el elemento. Los casos de uso permiten que
el creador de un elemento comunique su intención sobre cómo se debería usar

3. Los casos de uso sirven de base para probar cada elemento según evolucionan durante el
desarrollo. Al probar continuamente cada elemento frente a sus casos de uso, se está
validando su implementación a lo largo del desarrollo. Estos casos de uso no sólo sirven
como punto de partida para las pruebas de regresión, sino que cada vez que se añade un
caso de uso a un elemento, hay que reconsiderar su implementación, para asegurarse de
que ese elemento es flexible al cambio. Si no lo es, la arquitectura debe reorganizarse del
modo adecuado.

Para modelar el comportamiento de un elemento:

● Hay que identificar los actores que interactúan con el elemento. Los actores candidatos
pueden incluir grupos que requieran un cierto comportamiento para ejecutar sus tareas
o que se necesiten directa o indirectamente para ejecutar las funciones del elemento.

● Hay que organizar los actores identificando tanto los roles más generales como los más
especializados.

● Hay que considerar las formas más importantes que tiene cada actor de interactuar con
el elemento. También deben considerarse las interacciones que implican el cambio de
estado del elemento o su entorno o que involucran una respuesta ante algún evento.

● Hay que considerar también las formas excepcionales en las que cada actor puede
interactuar con el elemento.

● Hay que organizar estos comportamientos como casos de uso, utilizando reglas de
inclusión y extensión para factorizar el comportamiento común y distinguir el
comportamiento excepcional.

Por ejemplo, un sistema de venta interactúa con clientes, que efectuarán pedidos y querrán
llevar un seguimiento. A su vez, el sistema enviará todos los pedidos y facturas al cliente.
Como se muestra en elejemplor, el comportamiento de ese sistema se puede modelar
declarando estos comportamientos
Modelar es un todo completo del sistema
Diagramar es solo una vision de una porcion del sistema

Diagrama de colaboración
Un diagrama de colaboración en las versiones de UML 1.x es esencialmente un diagrama que
muestra interacciones organizadas alrededor de los roles. A diferencia de los diagramas de
secuencia, los diagramas de colaboración, también llamados diagramas de comunicación, muestran
explícitamente las relaciones de los roles. Por otra parte, un diagrama de comunicación no muestra
el tiempo como una dimensión aparte, por lo que resulta necesario etiquetar con números de
secuencia tanto la secuencia de mensajes como los hilos concurrentes.
 Muestra cómo las instancias específicas de las clases trabajan juntas para conseguir un
objetivo común.
 Implementa las asociaciones del diagrama de clases mediante el paso de mensajes de un
objeto a otro. Dicha implementación es llamada "enlace".
Un diagrama de comunicación es también un diagrama de clases que contiene roles de clasificador
y roles de asociación en lugar de sólo clasificadores y asociaciones. Los roles de clasificador y los
de asociación describen la configuración de los objetos y de los enlaces que pueden ocurrir cuando
se ejecuta una instancia de la comunicación. Cuando se instancia una comunicación, los objetos
están ligados a los roles de clasificador y los enlaces a los roles de asociación. El rol de asociación
puede ser desempeñado por varios tipos de enlaces temporales, tales como argumentos de
procedimiento o variables locales del procedimiento. Los símbolos de enlace pueden llevar
estereotipos para indicar enlaces temporales.
Diagrama de Secuencia
Destaca la ordenación temporal de los mensajes.
Los diagramas de secuencia tienen 2 características que los distinguen de los diagramas de
comunicación.
En primer lugar está la línea de vida (línea discontinua vertical que representa la existencia del
objeto a lo largo de un periodo de tiempo)
Pueden crearse objetos durante la interacción, sus líneas de vida comenzaran con la
receptación de un mensaje estereotipado como create y para finalizar uno estereotipado como
destroy (sumado a una X como señal visual)
En segundo lugar está el foco de control (rectángulo delgado y estrecho que representa el
periodo durante el cual un objeto ejecute una acción). Tambien puede mostrarse el anidamiento
de un foco de control (puede ser causado por una recursión llamada a operación propia o
desde otro objeto).
El contenido principal de estos diagramas son los mensajes.
Asíncrono: La flecha es abierta
Síncrono: La flecha es un triángulo relleno (una llamada)
Respuesta a mensaje asíncrono flecha abierta discontinua.
El orden del tiempo a lo largo de una línea de vida es significativo. Solo muestran secuencias
relativas, no son diagramas del tiempo a escala. Los mensajes pueden ocurrir en cualquier
orden.