Típicamente se usan para modelar los escenarios de uso del sistema, describiendo de qué formas puede usarse. La secuencia puede expresar tanto un caso de uso completo como quizá un caso concreto del mismo contemplando algunas alternativas.
También son una buena herramienta para explorar la lógica de una operación compleja o los elementos implicados en la prestación de un servicio. Nos pueden ayudar a identificar cuellos de botella en la fase de diseño, detectar cuáles van a ser las clases más complejas de implementar y decidir cuáles de ellas van a necesitar diagramas de estados (que veremos más adelante) para facilitar su implementación.
Se componen de los siguientes elementos:
• Objeto: instancia de una clase que podemos empezar a identificar como participante en la secuencia de operaciones que representa este caso de uso.
• Actor: los actores pueden comunicarse con los objetos, por lo tanto formarán parte de este diagrama.
• Vida del objeto: indicamos la existencia de un objeto a lo largo
del tiempo mediante una línea discontinua. El fin del mismo se indica mediante un aspa.
• Activación: indicamos cuándo el objeto está realizando una tarea concreta.
• Mensaje: la comunicación entre objetos y sus activaciones.
Una de las características de los diagramas de secuencia es que casi no necesitan aclaraciones en cuanto a su notación. En la parte superior, vemos los participantes en la secuencia (también denominados “clasificadores” que implementan la misma). En general siempre será un actor el que inicie la secuencia, y el resto de participantes pueden ser objetos (representados con una caja en la que escribiremos el nombre del objeto), otros actores, o quizá un caso de uso completo.
Cada participante tiene un intervalo en el que éste está activo en la secuencia, que se indica mediante un rectángulo sobre la línea discontinua que representa la vida del objeto. El rectángulo empiezacuando el objeto recibe un mensaje (representado mediante una flecha que incorpora el nombre de la llamada) y termina cuando éste devuelve su última respuesta (representada mediante una flecha discontinua). Los mensajes suelen incluir números de secuencia que facilitan la comprensión del diagrama y el seguimiento del orden en que se producen los mensajes. A veces un error puede provocar una línea discontinua de retorno hasta el primer participante, de forma similar a cómo se propagaría una excepción. Así pues, las líneas de retorno pueden incluir también etiquetas para indicar si representan un error o no. Finalmente, un aspa al final de la vida del objeto indica que éste puede destruirse.
Finalmente, enumeramos un conjunto de buenas prácticas en la representación de diagramas de secuencia:
• El orden entre los mensajes y los participantes debe ser siempre de izquierda a derecha y de arriba abajo para facilitar la comprensión del diagrama.
• El nombre de los actores debe ser consistente con los casos de uso.
• El nombre de los objetos debe ser consistente con los diagramas de clases.
• Incluir notas en las secuencias.
• Sólo incluir el aspa de destrucción del objeto en casos en que proporcione información sobre cuándo debe destruirse, en caso contrario “ensuciaremos” el diagrama innecesariamente.
Fuentes:
Popkin Software and Systems. Modelado de Sistemas con UML. Un estudio a fondo de UML. Diagramas de Secuencia. Recuperado el 20 de Noviembre 2011, de http://www.ibiblio.org/pub/linux/docs/LuCaS/Tutoriales/doc-modelado-sistemas-UML/multiple-html/c12.html
UOC Formación de posgrado. Software libre. Ingeniería del software en entornos de SL. Marzo (2005). Marc Gibert Ginestà, Álvaro Peña González. Recuperado el 20 de Noviembre 2011, de http://www.sw-computacion.f2s.com/Linux/009-Ingenieria_del_software.pdf
No hay comentarios:
Publicar un comentario