TIPOS DE DIAGRAMA UML

ADSI 36CAICEDO VASCO HEIDY

SALAZAR VILLANO DANIELATRUJILLO DANIEL STEVEN

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.

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.

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 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.

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.

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

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.

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.

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.

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.

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.

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.

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.

BIBLIOGRAFIA

http://utnsimocametodologia.blogspot.com/2011/11/aprendiendo-uml-hora-12-diagrama-de.html

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