Diagrama de Secuencia

Muestra un diagrama bidimensional. La dimensión vertical es el eje del tiempo, el tiempo avanza hacia debajo de la página. La dimensión horizontal muestra los roles que representan cada uno de los objetos en la colaboración. Cada rol está representado por una columna vertical que contiene una cabeza de símbolo y una línea vertical que representa la vida del objeto. Durante el tiempo que el objeto existe la línea punteada se muestra. Durante el tiempo que un procedimiento de un objeto está activo, la línea de vida es dibujada como una línea doble [Rumbaugh+2005]. Destaca la ordenación temporal de los mensajes [Booch+2006]. Los usuarios tienden a entender los diagramas de secuencia mejor que los diagramas de comunicación ya que son más sencillos de leer. Los diagramas de comunicación tienden a saturarse muy rápidamente (…) Son la forma de interacción más flexible [Arlow+2006].

 Al igual que ocurre con los diagramas de clases, los desarrolladores suelen pensar que los diagramas de secuencia son exclusivamente para ellos. Sin embargo, el staff de la organización puede encontrar los diagramas de secuencia útiles para comunicar la forma en que la organización trabaja actualmente mostrando cómo interactúan los objetos de negocio (…) Además, los diagramas de secuencia se pueden utilizar como un documento para comunicar los requerimientos del futuro sistema [Bell2004-2].

Cuando se modela, normalmente empieza una realización de caso de uso, utilizando un diagrama de comunicación porque es más sencillo situar líneas de vida en el diagrama y conectarlas. Sin embargo, cuando necesita centrarse en la secuenciación real de los eventos, siempre es mucho más sencillo utilizar un diagrama de secuencia [Arlow+2006].

Creación y destrucción de objetos

Los diagramas de secuencia pueden mostrar cómo los objetos se crean y se destruyen como parte del escenario documentado. Un objeto puede crear otro objeto a través de un mensaje. El objeto creado es dibujado con su símbolo de objeto colocado donde es creado (sobre el eje de tiempo vertical). El mensaje de creación es mostrado con líneas punteadas y cabeza de flecha abierta. Cuando el objeto es destruido, es marcado con un símbolo de ALTO; una X grande. La destrucción es indicada con una la línea de vida de ese objeto sólo hasta el punto en el que fue destruido [Eriksson+2004]. Ver Figura 3‑35.

Figura 3-35: Creación y destrucción de objetos - [Eriksson+2004]

Figura 3-35: Creación y destrucción de objetos – [Eriksson+2004]

Elementos

Frame

En UML 2, se adicionó un elemento a la notación, denominado frame, ver Figura 3‑36. El frame se utiliza como elemento de base para muchos otros elementos en UML 2, pero se lo encuentra como un elemento estructural que limita al diagrama. El frame es un elemento opcional.

Figura 3-36: Un frame UML 2 vacío – [Bell2004-2]

Figura 3-36: Un frame UML 2 vacío – [Bell2004-2]

Además de proporcionar una frontera visual, el frame tiene una funcionalidad importante en los diagramas que representan interacciones, tales como el diagrama de secuencia. Los mensajes entrantes y salientes (alias, interacciones) pueden ser modelados por la conexión de los mensajes con la frontera del frame, ver Figura 3‑37.

Figura 3-37: Diagrama de secuencia con mensajes entrantes y salientes – [Bell2004-2]

Figura 3-37: Diagrama de secuencia con mensajes entrantes y salientes – [Bell2004-2]

Adicionalmente, la etiqueta del diagrama muestra las letras ‘sd’ por Diagrama de Secuencia.

La especificación de UML proporciona valores de texto específicos para tipos de diagramas (por ejemplo, sd=Diagrama de secuencia, activity=Diagrama de actividad, y use case=Diagrama de casos de uso) [Bell2004-2].

Mensajes

El primer mensaje de un diagrama de secuencia siempre comienza en la parte superior y, por lo general, se encuentra en la parte izquierda del diagrama para facilitar su lectura.

Los mensajes de retorno son opcionales, un mensaje de retorno se dibuja como una línea de puntos con una punta de flecha de retorno hacia el objeto original, y encima de esta línea se coloca el valor de retorno de la operación. En la Tabla 3‑5 se describen los mensajes.

Tabla 3-5: Tipo de mensajes [IBM2004]

Tabla 3-5: Tipo de mensajes [IBM2004]

Guardas

Establecen una condición que debe cumplirse para que el mensaje sea enviado. Estos ya existían en UML 1.x. La notación es:
[Boolean Test]

Por ejemplo:
[pastDueBalance=0]

[Bell2004-2]

Fragmentos combinados y operadores

Los diagramas de secuencia se pueden dividir en trozos llamados fragmentos combinados. Un fragmento combinado encapsula porciones del diagrama de secuencia. Estos fragmentos se encuentran rodeados por un frame. El especificador en la esquina superior izquierda describe como el fragmento es manejado [Eriksson+2004], ver Figura 3‑38. Todo fragmento combinado tiene un operador, uno o más operandos y cero o más condiciones de protección. El operador determina como se ejecutan sus operandos [Arlow+2006].

Figura 3-38: Sintaxis de fragmento combinado - [Arlow+2006]

Figura 3-38: Sintaxis de fragmento combinado – [Arlow+2006]

Las condiciones de protección son expresiones booleanas, y el operando se ejecuta si y solo si la expresión se evalúa en verdadero. Una sola condición de protección se puede aplicar a todos los operandos, o cada operando puede tener su propia condición de protección única, ver Tabla 3‑6.

Tabla 3-6: Lista de operadores - [Arlow+2006]

Tabla 3-6: Lista de operadores – [Arlow+2006]

Los operandos más importantes son: opt, alt, loop, break, ref, par y critical [Arlow+2006].

Alt – Alternativas

Las alternativas son usadas para designar una opción mutuamente excluyente entre dos o más secuencias de mensaje. Permiten el modelado del clásico "if then else" lógico [Bell2004-2]. Cada operando tiene su propia condición y se ejecutará si la condición es verdadera. Un operando opcional con una condición [else] se ejecuta si ninguna de las otras condiciones son verdaderas, ver Figura 3‑39.

Figura 3-39: operadores opt y alt - [Arlow+2006]

Figura 3-39: operadores opt y alt – [Arlow+2006]

Opt – Opción

Una opción se utiliza para modelar un simple " if then " [Bell2004-2]. El operador opt, indica que su único operando se ejecuta si, y sólo si, la condición de protección es verdadera, ver Figura 3‑39. De lo contrario, la ejecución continúa después del fragmento combinado, opt es equivalente al constructor de programación:

if (condicion1) then

     acción1

loop Bucle

Sirve para modelar secuencias repetitivas. En UML 2, las secuencias repetitivas han mejorado con la adición del fragmento loop. El fragmento loop es muy similar al option, se trata de un frame que muestra la palabra loop [Bell2004-2].

Tabla 3-7: Tipos de bucles - [Arlow+2006]

Tabla 3-7: Tipos de bucles – [Arlow+2006]

break – Pausa

Puede utilizar break para indicar bajo qué condiciones el bucle se rompe [Arlow+2006].

par – Paralelo

Un fragmento paralelo (par), tiene dos o más sub-fragmentos. Cuando es el turno del fragmento, todos los sub-fragmentos son ejecutados simultáneamente. La secuencia relativa de los mensajes de los sub-fragmentos es indeterminada y los mensajes pueden ser intercalados en cualquier orden. Cuando todos los sub-fragmentos han finalizado su ejecución, la ejecución concurrente se une de nuevo en un solo flujo [Rumbaugh+2005].

Recursividad

Ocurre cuando una función se llama a sí misma, usada en numerosos algoritmos. El mensaje es siempre síncrono y marcado como tal en el diagrama de secuencia, el valor de respuesta es considerado implícito y puede prescindirse [Eriksson+2004], ver Figura 3‑40.

Figura 3-40: la función oper() se llama a sí misma - [Eriksson+2004]

Figura 3-40: la función oper() se llama a sí misma – [Eriksson+2004]

Referenciar a otro diagrama de secuencia

Los diagramas de secuencia pueden referenciar a otras interacciones. Se pueden construir completos y complejos diagramas de secuencia a partir pequeñas y simples interacciones. Una interacción es representada con un frame etiquetado con la etiqueta ref, y el nombre de la interacción a que se hace referencia se encuentra dentro del marco del área de contenido, junto con los parámetros y los tipos de retorno [IBM2004]. Por ejemplo, en la Figura 3‑41, el diagrama de secuencia hace referencia a los diagramas “Balance Lookup” y “Debit Account”. La secuencia se inicia cuando el cliente envía un mensaje al objeto cajero, el cajero envía un mensaje al objeto theirBank, el diagrama de secuencia “Balance Lookup” es llamado, el cual devuelve la variable balance. A continuación el fragmento de combinación option es llamado a verificar que el balance es superior al monto. El diagrama de secuencia “Debit Account” es llamado, pasa el número de cuenta y el monto como parámetros, después de que se completa la secuencia, el monto de cash es retornado al cliente [Bell2004-2].

Figura 3-41: Un diagrama de secuencia que hace referencia a otros dos - [Bell2004-2]

Figura 3-41: Un diagrama de secuencia que hace referencia a otros dos – [Bell2004-2]

Bibliografía

[Arlow+2006] Arlow, Jim y Neustadt, Ila. 2006. UML2. [ed.] Victor Manuel Ruiz Calderón y Susana Krahe Pérez-Rubín. [trad.] Beatriz Parra Fernández. Madrid : ANAYA MULTIMEDIA, 2006. pág. 609. ISBN: 84-415-2033-X.

[Bell2004-2] Bell, Donald. 2004. UML's Sequence Diagram. [En línea] 16 de Febrero de 2004. [Citado el: 18 de Abril de 2008.] http://www.ibm.com/developerworks/rational/library/3101.html.

[Booch+2006] Booch, Grady, Rumbaugh, James y Jacobson, Ivar. 2006. El Lenguaje Unificado de Modelado: Guía de usuario. [ed.] Martín-Romo Miguel. [trad.] Jesús J. Garcia Molina y José Sáez Martínez. Segunda Edición. Rivera del Loira : PEARSON EDUCACIÓN S.A., 2006. pág. 527. ISBN 10: 84-7829-076-1.

[Eriksson+2004] Eriksson, Hans-Erik, y otros. 2004. UML™ 2 Toolkit. [ed.] Kevin Kent. Indianapolis, Indiana, EE.UU. : Wiley Publishing, Inc., 2004. 0-471-46361-2.

[IBM2004] IBM. 2004. Messages in UML diagrams. [En línea] 2004. [Citado el: 31 de Diciembre de 2008.] http://publib.boulder.ibm.com/infocenter/rsmhelp/v7r0m0/index.jsp?topic=/com.ibm.xtools.sequence.doc/topics/cmsg_v.html.

[Rumbaugh+2005] Rumbaugh, James, Jacobson, Ivar y Booch, Grady. 2005. The Unified Modeling Language: Reference Manual. Second Edition. Boston : Pearson Education, Inc., 2005. pág. 742. ISBN 0-321-24562-8.


 

 

 

Acerca de Daniel

Soy ingeniero de sistemas con muchos años de experiencia en el desarrollo de software y gestión de proyectos. El objetivo al desarrollar este sitio web el de brindar información y conocimientos, tanto a nivel académico como profesional sobre diversas tecnologías involucradas en las disciplinas computacionales. Confio en brindar información lo mas didactica y clara en lo referente contenido académico. Así como ejemplos y casos reales de soluciones problemas que se presentan en un entorno de producción.
Esta entrada fue publicada en UML, UML2 y etiquetada , . Guarda el enlace permanente.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *

Puedes usar las siguientes etiquetas y atributos HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>


Última modificación: 23/09/2012