UML

1. LENGUAJE UNIFICADO DE MODELADO

2. El lenguaje unificado de modelado (UML, por sus siglas en inglés, Unified
Modeling Language) es el lenguaje de modelado de sistemas
de software más conocido y utilizado en la actualidad; está respaldado por
el Object Management Group (OMG).
Es un lenguaje gráfico para visualizar, especificar, construir y documentar
un sistema. UML ofrece un estándar para describir un "plano" del sistema
(modelo), incluyendo aspectos conceptuales tales como procesos,
funciones del sistema, y aspectos concretos como expresiones de
lenguajes de programación, esquemas de bases de datos y compuestos
reciclados.

3. Es importante remarcar que UML es un "lenguaje de modelado" para
especificar o para describir métodos o procesos. Se utiliza para definir un
sistema, para detallar los artefactos en el sistema y para documentar y
construir. En otras palabras, es el lenguaje en el que está descrito el
modelo.
Se puede aplicar en el desarrollo de software gran variedad de formas para
dar soporte a una metodología de desarrollo de software (tal como
el Proceso Unificado Racional, Rational Unified Process o RUP), pero no
especifica en sí mismo qué metodología o proceso usar.

4. UML no puede compararse con la programación estructurada, pues UML
significa Lenguaje Unificado de Modelado, no es programación, solo se
diagrama la realidad de una utilización en un requerimiento. Mientras que
programación estructurada es una forma de programar como lo es la
orientación a objetos, la programación orientada a objetos viene siendo un
complemento perfecto de UML, pero no por eso se toma UML solo para
lenguajes orientados a objetos.
UML cuenta con varios tipos de diagramas, los cuales muestran diferentes
aspectos de las entidades representadas.

5. TIPOS DE DIAGRAMAS EN UML
Existen dos clases principales de tipos de diagramas:
diagramas estructurales y diagramas de comportamiento.
Estos últimos incluyen varios que representan diferentes
aspectos de las interacciones. Estos diagramas pueden ser
categorizados jerárquicamente como se muestra en el
siguiente diagrama de clases:

7. Estructurales
Los diagramas estructurales muestran la estructura
estática del sistema y sus partes en diferentes niveles de
abstracción. Existen un total de siete tipos de diagramas
de estructura:
Diagrama de clases
Es un tipo de diagrama de estructura estática que describe la estructura de un
sistema mostrando las clases del sistema, sus atributos, operaciones (o
métodos), y las relaciones entre los objetos.
Los diagramas de clase son, sin duda, el tipo de diagrama UML más utilizado.
Es el bloque de construcción principal de cualquier solución orientada a
objetos. Muestra las clases en un sistema, atributos y operaciones de cada
clase y la relación entre cada clase. En la mayoría de las herramientas de
modelado, una clase tiene tres partes, nombre en la parte superior, atributos en
el centro y operaciones o métodos en la parte inferior. En sistemas grandes con
muchas clases relacionadas, las clases se agrupan para crear diagramas de
clases. Las diferentes relaciones entre las clases se muestran por diferentes
tipos de flechas.

8. Miembros
UML proporciona mecanismos para representar los miembros de la clase, como atributos y métodos, así como
información adicional sobre ellos.
Visibilidad
Para especificar la visibilidad de un miembro de la clase (es decir, cualquier atributo o método), se coloca uno
de los siguientes signos delante de ese miembro:
+ Público
- Privado
# Protegido
/ Derivado (se puede combinar con otro)
~ Paquete

9. Ejemplo de diagrama de clases de una Universidad.

10. Ámbitos
UML especifica dos tipos de ámbitos para los miembros: instancias y clasificadores y estos últimos
se representan con nombres subrayados.
 Los miembros clasificadores se denotan comúnmente como “estáticos” en muchos lenguajes
de programación. Su ámbito es la propia clase.
o Los valores de los atributos son los mismos en todas las instancias
o La invocación de métodos no afecta al estado de las instancias
 Los miembros instancias tienen como ámbito una instancia específica.
o Los valores de los atributos pueden variar entre instancias
o La invocación de métodos puede afectar al estado de las instancias(es decir, cambiar el
valor de sus atributos)
Para indicar que un miembro posee un ámbito de clasificador, hay que subrayar su nombre. De lo
contrario, se asume por defecto que tendrá ámbito de instancia.

11. Relaciones
Una relación es un término general que abarca los tipos específicos de conexiones lógicas que se pueden
encontrar en los diagramas de clases y objetos. UML presenta las siguientes relaciones:
Relaciones a nivel de instancia
Enlace
Un enlace es la relación más básica entre objetos.
Asociación
Ejemplo de diagrama de clases con una asociación de dos clases (en inglés)

12. Una asociación representa a una familia de enlaces. Una asociación binaria (entre dos clases)
normalmente se representa con una línea continua. Una misma asociación puede relacionar
cualquier número de clases. Una asociación que relacione tres clases se llama asociación
ternaria.
A una asociación se le puede asignar un nombre, y en sus extremos se puede hacer
indicaciones, como el rol que desempeña la asociación, los nombres de las clases relacionadas,
su multiplicidad, su visibilidad, y otras propiedades.
Hay cuatro tipos diferentes de asociación: bidireccional, unidireccional, agregación (en la que se
incluye la composición) y reflexiva. Las asociaciones unidireccional y bidireccional son las más
comunes.
Por ejemplo, una clase vuelo se asocia con una clase avión de forma bidireccional. La asociación
representa la relación estática que comparten los objetos de ambas clases.

13. Agregación
Ejemplo de diagrama de clases con una agregación entre dos clases (en inglés)
La agregación o agrupación es una variante de la relación de asociación “tiene un”: la agregación es más específica
que la asociación. Se trata de una asociación que representa una relación de tipo parte-todo o parte-de.
Como se puede ver en la imagen del ejemplo (en inglés), un Profesor 'tiene una' clase a la que enseña.
Al ser un tipo de asociación, una agregación puede tener un nombre y las mismas indicaciones en los extremos de
la línea. Sin embargo, una agregación no puede incluir más de dos clases; debe ser una asociación binaria.
Una agregación se puede dar cuando una clase es una colección o un contenedor de otras clases, pero a su vez, el
tiempo de vida de las clases contenidas no tienen una dependencia fuerte del tiempo de vida de la clase
contenedora (de el todo). Es decir, el contenido de la clase contenedora no se destruye automáticamente cuando
desaparece dicha clase.
En UML, se representa gráficamente con un rombo hueco junto a la clase contenedora con una línea que lo conecta
a la clase contenida. Todo este conjunto es, semánticamente, un objeto extendido que es tratado como una única
unidad en muchas operaciones, aunque físicamente está hecho de varios objetos más pequeños.

14. Composición
El rombo negro muestra una relación de composición: el almacén está compuesto de cuentas, si se
elimina el almacén las cuentas por si solas no tienen sentido como una entidad separada del
almacén y se eliminan también. El rombo sin rellenar muestra una relación de agregación: el
almacén tiene clientes, si el almacén cierra los clientes irán a otro, su razón de existir sigue teniendo
sentido sin el almacén.
La representación en UML de una relación de composición es mostrada con una figura de diamante
rellenado del lado del la clase contenedora, es decir al final de la línea que conecta la clase
contenido con la clase contenedor

15. Diferencias entre Composición y Agregación
Relación de Composición
Cuando intentamos representar un todo y sus partes. Ejemplo, un motor es una parte de un coche.
Cuando se elimina el contenedor, el contenido también es eliminado. Ejemplo, si eliminamos una
universidad eliminamos igualmente sus departamentos.
Relación de Agregación (o Agrupación)
Cuando representamos las relaciones en un software o base de datos. Ejemplo, el modelo de motor
MTR01 es parte del coche MC01. Como tal, el motor MTR01 puede ser parte de cualquier otro
modelo de coche, es decir si eliminamos el coche MC01 no es necesario eliminar el motor pues
podemos usarlo en otro modelo.
Cuando el contenedor es eliminado, el contenido usualmente no es destruido. Ejemplo, un profesor
tiene estudiantes, cuando el profesor muere los estudiantes no mueren con él o ella.
Así, una relación de agregación es a menudo "clasificar" o "catalogar" contenido para distinguirlo del
todo "físico" del contenedor.

16.  El diagrama de clases puede tener como ejemplo: una clase que sería un objeto o
persona misma en la cual se especifica cada acción y especificación.
 Propiedades de objetos que tienen propiedades y/u operaciones que contienen un
contexto y un dominio, los primeros dos ejemplos son clases de datos y el tercero clase de
lógica de negocio, dependiendo de quién diseñe el sistema se pueden unir los datos con
las operaciones.
 El diagrama de clases incluye mucha más información como la relación entre un objeto y
otro, la herencia de propiedades de otro objeto, conjuntos de operaciones/propiedades
que son implementadas para una interfaz gráfica.
 Presenta las clases del sistema con sus relaciones estructurales y de herencia.
 El diagrama de clases es la base para elaborar una arquitectura MVC o MVP.

17. Diagrama de componentes
Un diagrama de componentes muestra la relación estructural de los componentes de un sistema de software.
Estos se utilizan principalmente cuando se trabaja con sistemas complejos que tienen muchos componentes.
Los componentes se comunican entre sí mediante interfaces. Las interfaces se enlazan mediante conectores.
Un diagrama de componentes representa cómo un sistema de software es dividido en componentes y muestra
las dependencias entre estos componentes. Los componentes físicos incluyen archivos, cabeceras, bibliotecas
compartidas, módulos, ejecutables, o paquetes. Los diagramas de Componentes prevalecen en el campo de
la arquitectura de software pero pueden ser usados para modelar y documentar cualquier arquitectura de
sistema.
Debido a que los diagramas de componentes son más parecidos a los diagramas de casos de usos, estos son
utilizados para modelar la vista estática y dinámica de un sistema. Muestra la organización y las dependencias
entre un conjunto de componentes. No es necesario que un diagrama incluya todos los componentes del
sistema, normalmente se realizan por partes. Cada diagrama describe un apartado del sistema.
En él se situarán librerías, tablas, archivos, ejecutables y documentos que formen parte del sistema.
Uno de los usos principales es que puede servir para ver qué componentes pueden compartirse entre sistemas
o entre diferentes partes de un sistema.

18. Diagrama de despliegue
Un diagrama de despliegue muestra el hardware de su sistema y el software de ese hardware. Los
diagramas de implementación son útiles cuando la solución de software se despliega en varios
equipos, cada uno con una configuración única.
El Diagrama de Despliegue es un tipo de diagrama del Lenguaje Unificado de Modelado que se utiliza
para modelar la disposición física de los artefactos software en nodos (usualmente plataforma
de hardware) Muestra la arquitectura del sistema como el despliegue (la distribución) de los artefactos de
software a los objetivos de despliegue.

19. Aspectos Generales
La mayoría de las veces el modelado de la vista de despliegue implica modelar la topología del hardware
sobre el que se ejecuta el sistema. Aunque UML no es un lenguaje de especificación hardware de propósito
general, se ha diseñado para modelar muchos de los aspectos hardware de un sistema a un nivel suficiente
para que un ingeniero software pueda especificar la plataforma sobre la que se ejecuta el software del
sistema.
Usos
Algunos de los usos que se les da a los diagramas de despliegue son para modelar:
 Sistemas empotrados: Un sistema empotrado es una colección de hardware con una gran cantidad de
software que interactúa con el mundo físico.
 Sistemas cliente-servidor: Los sistemas cliente-servidor son un extremo del espectro de los sistemas
distribuidos y requieren tomar decisiones sobre la conectividad de red de los clientes a los servidores y
sobre la distribución física de los componentes software del sistema a través de nodos.
 Sistemas completamente distribuidos: En el otro extremo encontramos aquellos sistemas que son amplia
o totalmente distribuidos y que normalmente incluyen varios niveles de servidores. Tales sistemas contienen
a menudo varias versiones de componentes software, alguno de los cuales pueden incluso migrar de un
nodo a otro. El diseño de tales sistemas requiere tomar decisiones que permitan un cambio continuo de la
topología del sistema.

20. Diagrama de objetos
Los diagramas de objetos, a veces denominados diagramas de instancia, son muy similares a los diagramas
de clases. Al igual que los diagramas de clases, también muestran la relación entre los objetos, pero usan
ejemplos del mundo real. Se utilizan para mostrar cómo se verá un sistema en un momento dado. Debido a
que hay datos disponibles en los objetos, a menudo se utilizan para explicar relaciones complejas entre
objetos.
En UML, diagrama que muestra una vista
completa o parcial de los objetos de un
sistema en un instante de ejecución específico.

21. El Object Management Group, en la especificación UML (versiones 2.1 y anteriores), definía al
diagrama de objetos como:
"Un diagrama de objetos es un gráfico de instancias, incluyendo objetos y datos. Un diagrama
de objetos es una instancia de un diagrama de clases; muestra una 'foto' del estado de un
sistema en un punto de tiempo determinado."
Los diagramas de objeto están ligados a los diagramas de clase y comparten virtualmente los
mismos símbolos para la notación. Los diagramas de objetos pertenecen a la categoría de
diagramas estructurales en UML.
Generación y Uso
Los diagramas de objetos se generan en las disciplinas de Arquitectura y diseño. Se utilizan para
mostrar estructuras de datos y las interacciones que existen entre objetos en tiempo de ejecución.

22. Diagrama de paquetes
Un diagrama de paquetes en el Lenguaje Unificado de Modelado representa las dependencias entre
los paquetes que componen un modelo. Es decir, muestra cómo un sistema está dividido en agrupaciones
lógicas y las dependencias entre esas agrupaciones.
Dado que normalmente un paquete está pensado como un directorio, los diagramas de paquetes
suministran una descomposición de la jerarquía lógica de un sistema.
Los paquetes están normalmente organizados para maximizar la coherencia interna dentro de cada
paquete y minimizar el acoplamiento externo entre los paquetes. Con estas líneas maestras sobre la mesa,
los paquetes son buenos elementos de gestión. Cada paquete puede asignarse a un individuo o a un
equipo, y las dependencias entre ellos pueden indicar el orden de desarrollo requerido.

23. Relaciones entre paquete
Entre paquetes pueden existir relaciones de dependencia y generalización.
Las dependencias entre paquetes denotan que algún elemento de un paquete depende de los elementos en otro
paquete. Existen diferentes tipos de relaciones de dependencia entre paquetes:
 Importación: Modelado como una dependencia estereotipada con <<import>>.
 Acceso: Modelado como una dependencia estereotipada con <<access>>.
 Combinación: Modelado como una dependencia estereotipada con <<merge>>.
 Exportación: Modelado implícitamente a través de la visibilidad pública en los elementos del paquete. No se
exporta explícitamente a algún paquete.
La importación de paquetes o import se define como "una relación entre un espacio de nombres de
importación y un paquete, lo que indica que el espacio de nombres importador agrega los nombres de los
miembros del paquete a su propio espacio de nombres".1 Por defecto, una dependencia entre dos paquetes sin
etiqueta se interpreta como una relación de este tipo.

24. Elementos básicos
 Paquete: Un mecanismo de propósito general para la organización de elementos y diagramas de
modelo en grupos. Proporciona un espacio de nombres encapsulado dentro del cual todos los
nombres deben ser únicos. Se utiliza para agrupar elementos relacionados semánticamente. Es un
espacio de nombres, así como un elemento que puede estar contenida en los espacios de nombres
de otros paquetes. Visualmente se representa como una carpeta.
 Dependencia: Indica que un elemento de un paquete requiere a otro de un paquete distinto.
Visualmente se representa mediante una flecha discontinua con inicio en el paquete que depende del
otro, es decir, la flecha parte del elemento de origen y apunta hacia el elemento destino.
 Estereotipos: Existen tres estereotipos de relación de dependencia entre paquetes. Visualmente un
estereotipo de dependencia se representa como el nombre de la dependencia entre un par de
símbolos mayor y un par de símbolos menor (<< >>), se coloca junto a la flecha que señala la
dependencia. <<import>> significa una importación pública, los elementos importados tienen
visibilidad pública dentro del espacio de nombre del paquete origen o paquete importador, <<access>>
significa una importación privada, se utiliza para indicar la visibilidad privada, y <<merge>> significa
que la fuente de la combinación importa los contenidos importados por el destino.

25. Visibilidad de los elementos
Los paquetes controlan la visibilidad de los elementos que contienen.
Visualmente se representa la visibilidad de los elementos anteponiendo a su nombre uno de los
símbolos: +, para los públicos, -, para los privados, y #, para los protegidos.
 +: El elemento es público. Se encuentra disponible a otros elementos del paquete contenedor o uno
de sus paquetes anidados, y a los paquetes que importan el paquete contenedor.
 -: El elemento es privado. No disponibles fuera del paquete contenedor.
 #: El elemento está protegido. No son posibles el resto de visibilidades.

26. Diagrama de estructura compuesta
Los diagramas de estructura compuesta se utilizan para mostrar la estructura interna de una clase.
Un diagrama de estructura es un tipo de diagrama en el Lenguaje de Modelado Unificado (UML), que muestra
la estructura interna de una clase y las colaboraciones que esta estructura hace posibles. Esto puede
incluir partes internas, puertas mediante las cuales, las partes interactúan con cada una de las otras o mediante
las cuales, instancias de la clase interactúan con las partes y con el mundo exterior, y conectores entre partes o
puertas. Una estructura compuesta es un conjunto de elementos interconectados que colaboran en tiempo de
ejecución para lograr algún propósito. Cada elemento tiene algún rol definido en la colaboración.
Ejemplo de diagrama de estructura compuesta

27. Diagrama de actividades
Los diagramas de actividad representan los flujos de trabajo de forma gráfica. Pueden utilizarse para
describir el flujo de trabajo empresarial o el flujo de trabajo operativo de cualquier componente de un
sistema. A veces, los diagramas de actividad se utilizan como una alternativa a los diagramas de máquina
del estado.
Diagrama de flujo sencillo con los pasos a seguir si
una lámpara no funciona

28. Diagrama de actividades para un loop (bucle)
El diagrama de flujo o flujograma o diagrama de actividades es
la representación gráfica de un algoritmo o proceso. Se utiliza en
disciplinas como programación, economía, procesos
industriales y psicología cognitiva.
En Lenguaje Unificado de Modelado (UML), es un diagrama de
actividades que representa los flujos de trabajo paso a paso. Un
diagrama de actividades muestra el flujo de control general.
En SysML el diagrama ha sido extendido para indicar flujos entre
pasos que mueven elementos físicos (p. ej., gasolina) o energía (p. ej.,
presión). Los cambios adicionales permiten al diagrama soportar
mejor flujos de comportamiento y datos continuos.
Estos diagramas utilizan símbolos con significados definidos que
representan los pasos del algoritmo, y representan el flujo de
ejecución mediante flechas que conectan los puntos de inicio y de fin
del proceso.

29. Normas de trabajo
Las siguientes son acciones previas a la realización del diagrama de flujo:
 Definir qué se espera obtener del diagrama de flujo.
 Identificar quién lo empleará y cómo.
 Establecer el nivel de detalle requerido.
 Determinar los límites del proceso a describir.
Los pasos a seguir para construir el diagrama de flujo son:
 Establecer el alcance del proceso a describir. De esta manera quedará fijado el comienzo y el final del
diagrama. Frecuentemente el comienzo es la salida del proceso previo y el final la entrada al proceso
siguiente.
 Identificar y listar las principales actividades/subprocesos que están incluidos en el proceso a describir y
su orden cronológico.
 Si el nivel de detalle definido incluye actividades menores, listarlas también.
 Identificar y listar los puntos de decisión.
 Construir el diagrama respetando la secuencia cronológica y asignando los correspondientes símbolos.

30. Descripción
En UML 1.x, un diagrama de actividades es una variación del diagrama de estado UNL donde los
"estados" representan operaciones, y las transiciones representan las actividades que ocurren cuando la
operación se termina.
El diagrama de mensajes de UML 2.0, mientras que es similar en aspecto al diagrama de actividades
UML 1.x, ahora tiene semánticas basadas en redes de Petri. En UML 2.0, el diagrama general de
interacción está basado en el diagrama de actividades. El diagrama de actividad es una forma especial
de diagrama de estado usado para modelar una secuencia de acciones y condiciones tomadas dentro de
un proceso.
La especificación del Lenguaje de Notificación Unificado (UNL) define un diagrama de actividad como:
“… una variación de los estados de una máquina, los cuales representan el rendimiento de las acciones
o subactividades y las transiciones se provocan por la realización de las acciones o subactividades.”1
El propósito del diagrama de actividad es modelar un proceso de flujo de trabajo (workflow) y/o modelar
operaciones.
Una Operación es un servicio proporcionado por un objeto, que está disponible a través de una interfaz.
Una Interfaz es un grupo de operaciones relacionadas con la semántica.

31. Diagrama de casos de uso
Como el tipo de diagrama UML más conocido, los diagramas de casos de uso ofrecen una visión general de
los actores involucrados en un sistema, las diferentes funciones que necesitan esos actores y cómo
interactúan estas diferentes funciones. Es un gran punto de partida para cualquier discusión del proyecto, ya
que se pueden identificar fácilmente los principales actores involucrados y los principales procesos del
sistema.
En el Lenguaje de Modelado Unificado, un diagrama de casos de uso es una forma de diagrama de
comportamiento UML mejorado. El Lenguaje de Modelado Unificado (UML), define una notación gráfica para
representar casos de uso llamada modelo de casos de uso. UML no define estándares para que el formato
escrito describa los casos de uso, y así mucha gente no entiende que esta notación gráfica define la
naturaleza de un caso de uso; sin embargo una notación gráfica puede solo dar una vista general simple de
un caso de uso o un conjunto de casos de uso. Los diagramas de casos de uso son a menudo
confundidos con los casos de uso. Mientras los dos conceptos están relacionados, los casos de uso son
mucho más detallados que los diagramas de casos de uso. En los conceptos se debe detallar más de un
caso de uso para poder identificar qué es lo que hace un caso de uso.

32.  La descripción escrita del comportamiento del sistema al afrontar una tarea de negocio o un requisito de
negocio. Esta descripción se enfoca en el valor suministrado por el sistema a entidades externas tales
como usuarios humanos u otros sistemas.
 La posición o contexto del caso de uso entre otros casos de uso. Dado que es un mecanismo de
organización, un conjunto de casos de uso coherentes y consistentes promueven una imagen fácil de
comprender del comportamiento del sistema, un entendimiento común entre el cliente/propietario/usuario y
el equipo de desarrollo.
En esta práctica es común crear especificaciones suplementarias para capturar detalles de requisitos que caen
fuera del ámbito de las descripciones de los casos de uso. Ejemplos de esos temas incluyen restricciones de
diseño como: rendimiento, temas de escalabilidad/gestión, o cumplimiento de estándares.

33. El diagrama anterior describe la funcionalidad de un Sistema Restaurante muy simple. Los casos de uso
están representados por elipses y los actores están, por ejemplo, los casos de uso se muestran como
parte del sistema que está siendo modelado, los actores no.
En este caso, podemos apreciar tanto declaraciones correctas como incorrectas. El probar la comida y
pagarla es un requerimiento funcional del sistema, pero beber vino no lo es, por lo tanto este caso de uso
está incorrecto.
La interacción entre actores no se ve en el diagrama de casos de uso. Si esta interacción es esencial
para una descripción coherente del comportamiento deseado, quizás los límites del sistema o del caso de
uso deban de ser re-examinados. Alternativamente, la interacción entre actores puede ser parte de
suposiciones usadas en el caso de uso. Sin embargo, los actores son una especie de rol, un usuario
humano u otra entidad externa puede jugar varios papeles o roles. Así el Chef y el Cajero podrían ser
realmente la misma persona.

34. Relaciones de Casos de Uso
Las tres relaciones principales entre los casos de uso son soportadas por el estándar UML, el cual describe
notación gráfica para esas relaciones. Veamos una revisión de ellas a continuación:
Inclusión (include)
Es una forma de interacción o creación, un caso de uso dado puede "incluir" otro caso de uso. El primer caso
de uso a menudo depende del resultado del caso de uso incluido. Esto es útil para extraer comportamientos
verdaderamente comunes desde múltiples casos de uso a una descripción individual(si el actor realiza el caso
de uso base tendrá que realizar también el caso de uso incluido), desde el caso de uso. El estándar
de Lenguaje de Modelado Unificado de OMG define una notación gráfica para realizar diagramas de casos de
uso, pero no el formato para describir casos de uso. Mucha gente sufre la equivocación pensando que un
caso de uso es una notación gráfica (o es su descripción). Mientras la notación gráfica y las descripciones son
importantes, ellos forman parte de la documentación de un caso de uso --un propósito para el que el actor
puede usar el sistema. La notación es de una flecha de punta abierta con línea discontinua desde el caso de
uso que lo incluye hasta el caso de uso incluido, con la etiqueta "«include»". Este uso se asemeja a una
expansión de una macro, donde el comportamiento del caso incluido es colocado dentro del comportamiento
del caso de uso base. No hay parámetros o valores de retorno

35. Extensión (extend)
Es otra forma de interacción, un caso de uso dado (la extensión) puede extender a otro. Esta relación
indica que el comportamiento del caso de la extensión se utiliza en casos de uso, un caso de uso a otro
caso siempre debe tener extensión o inclusión. El caso de uso extensión puede ser insertado en el caso
de uso extendido bajo ciertas condiciones. La notación, es una flecha de punta abierta con línea
discontinua, desde el caso de uso extensión al caso de uso extendido, con la etiqueta «extend». Esto
puede ser útil para lidiar con casos especiales, o para acomodar nuevos requisitos durante el
mantenimiento del sistema y su extensión.
"La extensión, es el conjunto de objetos a los que se aplica un concepto. Los objetos de la extensión son
los ejemplos o instancias de los conceptos."
Documentan el comportamiento de un sistema desde el punto de vista de un usuario.
En otras palabras será utilizado cuando un caso de uso sea similar a otro pero con ciertas variaciones,
un ejemplo claro es que se necesite comprar azúcar y podemos seleccionar de entre azúcar rubia,
blanca o su unidad de medida bolsa, kilo, etc.

36. Generalización
"Entonces la Generalización es la actividad de identificar elementos en común entre conceptos y definir las
relaciones de una superclase (concepto general) y subclase (concepto especializado). Es una manera de
construir clasificaciones taxonómicas entre conceptos que entonces se representan en jerarquías de clases.
Las subclases conceptuales son conformes con las superclases conceptuales en cuanto a la intención y
extensión."
En la tercera forma de relaciones entre casos de uso, existe una relación generalización/especialización. Un
caso de uso dado puede estar en una forma especializada de un caso de uso existente. La notación es una
línea sólida terminada en un triángulo dibujado desde el caso de uso especializado al caso de uso general.
Esto se asemeja al concepto orientado a objetos de sub-clases, en la práctica puede ser útil factorizar
comportamientos comunes, restricciones al caso de uso general, describirlos una vez, y enfrentarse a los
detalles excepcionales en los casos de uso especializados. UML

37. Diagrama de máquina de estados
Los diagramas de máquina de estado son similares a los diagramas de actividad, aunque las anotaciones y el
uso cambian un poco. En algún momento se conocen como diagramas de estados o diagramas de diagramas
de estado también. Estos son muy útiles para describir el comportamiento de los objetos que actúan de
manera diferente de acuerdo con el estado en que se encuentran en el momento.
Diagrama de secuencia
Los diagramas de secuencia en UML muestran cómo los objetos interactúan entre sí y el orden en que se
producen esas interacciones. Es importante tener en cuenta que muestran las interacciones para un escenario
en particular. Los procesos se representan verticalmente y las interacciones se muestran como flechas. Los
diagramas de secuencia de UML forman parte de un modelo UML y solo existen dentro de los proyectos de
modelado UML.
El diagrama de secuencia es un tipo de diagrama usado para modelar interacción entre objetos en un
sistema según UML. En inglés se pueden encontrar como "sequence diagram", "event-trace diagrams".

38. Utilidad
Un diagrama de secuencia muestra la interacción de un conjunto de objetos en una aplicación a través
del tiempo y se modela para cada caso de uso. A menudo es útil para complementar a un diagrama de
clases, pues el diagrama de secuencia se podría describir de manera informal como "el diagrama de
clases en movimiento", por lo que ambos deben estar relacionados entre sí (mismas clases, métodos,
atributos...). Mientras que el diagrama de casos de uso permite el modelado de una vista business del
escenario, el diagrama de secuencia contiene detalles de implementación del escenario, incluyendo los
objetos y clases que se usan para implementar el escenario y mensajes intercambiados entre los objetos.
Típicamente se examina la descripción de un caso de uso para determinar qué objetos son necesarios
para la implementación del escenario. Si se dispone de la descripción de cada caso de uso como una
secuencia de varios pasos, entonces se puede "caminar sobre" esos pasos para descubrir qué objetos
son necesarios para que se puedan seguir los pasos. Un diagrama de secuencia muestra los objetos que
intervienen en el escenario con líneas discontinuas verticales, y los mensajes pasados entre los objetos
como flechas horizontales.

39. Tipos de mensaje
Existen dos tipos de mensajes: síncronos y asíncronos. Los mensajes síncronos se corresponden con llamadas
a métodos del objeto que recibe el mensaje. El objeto que envía el mensaje queda bloqueado hasta que termina
la llamada. Este tipo de mensajes se representan con flechas con la punta rellena. Los mensajes asíncronos
terminan inmediatamente, y crean un nuevo hilo de ejecución dentro de la secuencia. Se representan con
flechas con la punta hueca.
También se representa la respuesta a un mensaje con una flecha discontinua.
Pueden ser usados en dos formas
 De instancia: describe un escenario específico (un escenario es una instancia de la ejecución de un caso de
uso).
 Genérico: describe la interacción para un caso de uso. Utiliza ramificaciones ("branches"), condiciones y
bucles. A veces se puede usar para usted realizar trabajos

40. Diagrama de comunicación
un diagrama de comunicación es una versión simplificada del diagrama de colaboración de la versión de
UML 1.x
Un diagrama de comunicación modela las interacciones entre objetos o partes en términos de mensajes en
secuencia. Los diagramas de comunicación representan una combinación de información tomada desde el
diagrama de clases, secuencia, y diagrama de casos de uso describiendo tanto la estructura estática como el
comportamiento dinámico de un sistema.
Los diagramas de comunicación y de secuencia describen información similar, y con ciertas
transformaciones, pueden ser transformados unos en otros sin dificultad.
Para mantener el orden de los mensajes en un diagrama de comunicación, los mensajes son etiquetados
con un número cronológico y colocados cerca del enlace por el cual se desplaza el mensaje. Leer un
diagrama de comunicación conlleva comenzar en el mensaje 1.0, y seguir los mensajes desde un objeto
hasta el siguiente, sucesivamente.

41. Diagrama de tiempos
Los diagramas de sincronización son muy similares a los diagramas de secuencia. Representan el
comportamiento de los objetos en un marco de tiempo dado. Si es solo un objeto, el diagrama es directo,
pero si hay más de un objeto involucrado, también se pueden usar para mostrar interacciones de objetos
durante ese período de tiempo.
Diagrama global de interacciones
Los diagramas generales o globales de interacción son muy similares a los diagramas de actividad. Mientras
que los diagramas de actividad muestran una secuencia de procesos, los diagramas de interacción muestran
una secuencia de diagramas de interacción. En términos simples, pueden llamarse una colección de
diagramas de interacción y el orden en que suceden. Como se mencionó anteriormente, hay siete tipos de
diagramas de interacción, por lo que cualquiera de ellos puede ser un nodo en un diagrama de vista general
de interacción.