2.4.1 Diagrama de caso de uso
En el Lenguaje de Modelado Unificado, un diagrama de casos
de uso es una especie 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.
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.
El diagrama 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.
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.
2.4.2 Diagrama 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
2.4.3 Diagrama de secuencias
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 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.
Tipos de mensaje
Existen dos tipos de mensajes: sincrónicos y asincrónicos.
Los mensajes sincrónicos 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
cabeza llena. Los mensajes asincrónicos terminan inmediatamente, y crean un
nuevo hilo de ejecución dentro de la secuencia. Se representan con flechas con
la cabeza abierta.
Pueden ser usados de 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.
Material extra:
http://tt717.galeon.com/DSecuencia.htm
Material extra:
http://tt717.galeon.com/DSecuencia.htm
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.
Usos
Un uso de un diagrama de colaboración es mostrar la
implementación de una operación. La comunicación muestra los parámetros y las
variables locales de la operación, así como asociaciones más permanentes.
Cuando se implementa el comportamiento, la secuencia de los mensajes
corresponde a la estructura de llamadas anidadas y el paso de señales del
programa.
Un diagrama de secuencia muestra secuencias en el tiempo
como dimensión geométrica, pero las relaciones son implícitas. Un diagrama de
comunicación muestra relaciones entre roles geométricamente y relaciona los
mensajes con las relaciones, pero las secuencias temporales están menos claras.
Tipos
Es útil marcar los objetos en cuatro grupos: los que existen
con la interacción entera; los creados durante la interacción (restricción
{new}); los destruidos durante la interacción (restricción {destroyed}); y los
que se crean y se destruyen durante la interacción (restricción {transient}).
Aunque las comunicaciones muestran directamente la
implementación de una operación, pueden también mostrar la realización de una
clase entera. En este uso, muestran el contexto necesario para implementar
todas las operaciones de una clase. Esto permite que el modelador vea los roles
múltiples que los objetos pueden desempeñar en varias operaciones.
No hay ejemplos de los diagramas, diferentes casos o
sistemas, ya que con UML se modelan áreas de un negocio así como los sistemas
que estos requieren.
Material extra ejemplo:
http://gzloluna8sm.blogspot.mx/2010/06/diagramas-de-colaboracion.html
Material extra ejemplo:
http://gzloluna8sm.blogspot.mx/2010/06/diagramas-de-colaboracion.html
No hay comentarios:
Publicar un comentario