Este documento describe los diferentes tipos de diagramas UML, incluyendo diagramas de casos de uso, diagramas de estados, diagramas de colaboración, diagramas de componentes, diagramas de distribución, diagramas de secuencia, diagramas de objetos, diagramas de actividades y diagramas de clase. Cada diagrama se utiliza para representar un aspecto diferente del sistema, como el flujo de trabajo, la estructura de componentes o la interacción entre objetos.

1. TIPOS DE DIAGRAMA UML
ADSI 36
CAICEDO VASCO HEIDY
SALAZAR VILLANO DANIELA
TRUJILLO DANIEL STEVEN

2. DIAGRAMA DE CASOS DE USO
En el , un diagrama de casos de uso es una especie de diagrama de
comportamiento UML mejorado. El (UML), define una para representar
casos de uso llamada modelo de casos de uso. UML no define estándares
para que el formato escrito describa los , 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.

3. La descripción escrita del comportamiento del sistema al afrontar una tarea de
negocio o un requisito . 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.

5. El diagrama de la derecha describe la funcionalidad de un Sistema Restaurante
muy simple. Los casos de uso están representados por elipses y los están,
por ejemplo, los casos de uso se muestran como parte del sistema que está
siendo modelado, los actores no.
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 reexaminados. 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.

6. DIAGRAMAS DE ESTADOS
Los diagramas de estado muestran el conjunto de estados por los cuales pasa
un objeto durante su vida en una aplicación en respuesta a eventos (por
ejemplo, mensajes recibidos, tiempo rebasado o errores), junto con sus
respuestas y acciones. También ilustran qué eventos pueden cambiar el
estado de los objetos de la clase. Normalmente contienen: estados y
transiciones. Como los estados y las transiciones incluyen, a su vez, eventos,
acciones y actividades, vamos a ver primero sus definiciones.
Al igual que otros diagramas, en los diagramas de estado pueden aparecer notas
explicativas y restricciones.

8. DIAGRAMAS DE COLABORACION
Un diagrama de colaboración es fácilmente representada por el modelado de
objetos en unsistema y que representan las asociaciones entre los objetos
como vínculos. La interacción entrelos objetos se representa por las flechas.
Para identificar la secuencia de la invocación de estosobjetos, un número se
coloca junto a cada una de estas flechas

10. DIAGRAMA DE COMPONENTES
Un diagrama de componentes representa cómo un sistema de es dividido en y
muestra las entre estos componentes. Los componentes físicos incluyen ,
cabeceras, , , , o . Los diagramas de Componentes prevalecen en el campo
de la 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, éstos 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.

12. DIAGRAMAS DE DISTRIBUCION
El elemento primordial del hardware es el nodo, que es un nodo genérico para
todo tipo de recurso de computo es posible usar dos tipos de nodos un
procesador el cual puede ejecutar un componente , y un dispositivo que no lo
ejecuta
En el uml un cubo no representa un nodo se debe asignar un nombre para el
nodo y se podrá utilizar un estereotipo para indicar el tipo de recurso
El nombre es una cadena de texto. Si el nombre es parte de un paquete el nodo
puede contener el del paquete, el cubo se divide en compartimientos donde
se agrega información la conexión no puede ser simplemente por cable si no
que también esta la infraroja o satelital.

14. DIAGRAMA DE SECUENCIA
Es un tipo de diagrama usado para modelar interacción entre objetos en un
sistema según . En inglés se pueden encontrar como "sequence diagram",
"event-trace diagrams", "event scenarios" o "timing diagrams.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. Mientras que
el 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.

15. Típicamente se examina la descripción de un para determinar qué objetos son
necesarios para la implementación del escenario. Si se dispone de la
descripción de cada 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.

17. DIAGRAMA DE OBJETOS
Un diagrama de Objeto se puede considerar un caso especial de un diagrama de clase.
Los diagramas de objetos usan un sub conjunto de elementos de un diagrama de
clase para enfatizar la relación entre las instancias de las clases en algún punto en el
tiempo. Estos son útiles para entender los diagramas de clases. Estos no muestran
nada diferente en su arquitectura a los diagramas de secuencia, pero reflejan
multiplicidad y roles.
Los elementos de clase y objeto
El siguiente diagrama muestra las diferencias en apariencia entre un
elemento clase y un elemento objeto. Tener en cuenta que el elemento clase
consiste de tres partes, divididas en compartimientos de nombres, atributos y
operaciones; por predeterminado, los elementos objetos no tienen
compartimientos. La exhibición de los nombres es también diferente: los
nombres de los objetos están subrayados y pueden mostrar el nombre del
clasificador desde el cual el objeto se instancia.

19. DIAGRAMA DE ACTIVIDADES
En un diagrama de actividades se muestra un proceso de negocio o un proceso
de software como un flujo de trabajo a través de una serie de acciones. Estas
acciones las pueden llevar a cabo personas, componentes de software o
equipos.
Puede usar un diagrama de actividades para describir procesos de diversos
tipos, como los ejemplos siguientes:
Un proceso de negocio o un flujo de trabajo entre los usuarios y el sistema. Para
obtener más información, vea .
Los pasos realizados en un caso de uso. Para obtener más información, vea .
Un protocolo de software, es decir, las secuencias de interacciones permitidas
entre los componentes.
Un algoritmo de software.

21. DIAGRAMA DE CLASE
El diagrama de Clase muestra los bloques de construcción de cualquier sistema
orientado a objetos. Los diagramas de clases describen la vista estática del
modelo o parte del modelo, describiendo que atributos y comportamientos
tienen en lugar de detallar los métodos para realizar operaciones. Los
diagramas de Clase son más útiles para ilustrar relaciones entre clases e
interfaces. Las generalizaciones, agregaciones, y asociaciones son todas
valiosas al reflejar herencias, composición o uso, y conexiones
respectivamente.
El siguiente diagrama ilustra relaciones de agregación entre clases. La
agregación que tiene la punta de flecha en color más claro, indica que la
clase Account usa AddressBook, pero no necesariamente contiene una
instancia de este. La agregaciones compuestas con una punta de flecha más
oscura de los otros conectores, indican pertenencia o contención de las
clases de orígen por las clases destino, por ejemplo los valores Contact y
ContactGroup estarán contenidos en AddressBook.

23. BIBLIOGRAFIA
http://utnsimocametodologia.blogspot.com/2011/11/aprendiendo-uml-hora-12-diagrama-de
http://es.wikipedia.org/wiki/Lenguaje_Unificado_de_Modelado
http://users.dcc.uchile.cl/~psalinas/uml/modelo.html
http://mitareadeuml.blogspot.com/
http://www.sparxsystems.com.ar/resources/tutorial/uml2_activitydiagram.html