Lenguaje de modelado unificado (UML) es un lenguaje de modelado en el campo de la ingeniería de software que tiene como objetivo establecer formas estándar de visualizar el diseño de un sistema. UML guía la creación de múltiples tipos de diagramas, como diagramas de interacción, estructura y comportamiento. A diagrama de secuencia es el más utilizado interacción diagrama.

Diagrama de interacción

Se utiliza un diagrama de interacción para mostrar la comportamiento interactivo de un sistema. Dado que visualizar las interacciones en un sistema puede resultar difícil, utilizamos diferentes tipos de diagramas de interacción para capturar diversas características y aspectos de la interacción en un sistema.

• Un diagrama de secuencia simplemente representa la interacción entre los objetos en un orden secuencial, es decir, el orden en que ocurren estas interacciones.
• También podemos utilizar los términos diagramas de eventos o escenarios de eventos para referirnos a un diagrama de secuencia.
• Los diagramas de secuencia describen cómo y en qué orden funcionan los objetos de un sistema.
• Estos diagramas son ampliamente utilizados por empresarios y desarrolladores de software para documentar y comprender los requisitos de sistemas nuevos y existentes.

Temas importantes para los diagramas de secuencia

• Notación del diagrama de secuencia
• actores
  • Líneas de vida
  • Mensajes
  • Crear un mensaje
  • Borrar mensaje
  • Auto mensaje
  • Mensaje de respuesta
  • Mensaje encontrado
  • Mensaje perdido
  • guardias
• ¿Cómo crear diagramas de secuencia?
• Casos de uso de diagramas de secuencia
• Desafíos del uso de diagramas de secuencia

1. Notación del diagrama de secuencia

1.1. actores

Un actor en un diagrama UML representa un tipo de rol donde interactúa con el sistema y sus objetos. Es importante señalar aquí que un actor siempre está fuera del alcance del sistema que pretendemos modelar utilizando el diagrama UML.

Usamos actores para representar varios roles, incluidos usuarios humanos y otros sujetos externos. Representamos a un actor en un diagrama UML utilizando una notación de persona tipo palo. Podemos tener múltiples actores en un diagrama de secuencia.

Por ejemplo:

Aquí, el usuario en el sistema de reserva de asiento se muestra como un actor que existe fuera del sistema y no forma parte del mismo.

1.2. Líneas de vida

Una línea de vida es un elemento con nombre que representa a un participante individual en un diagrama de secuencia. Básicamente, cada instancia en un diagrama de secuencia está representada por una línea de vida. Los elementos de la línea de vida se encuentran en la parte superior de un diagrama de secuencia. El estándar en UML para nombrar una línea de vida sigue el siguiente formato:

Nombre de instancia: Nombre de clase

leer desde csv java

Mostramos una línea de vida en un rectángulo llamado cabeza con su nombre y tipo. La cabeza está ubicada encima de una línea discontinua vertical (denominada tallo), como se muestra arriba.

• Si queremos modelar una instancia sin nombre, seguimos el mismo patrón excepto que ahora la parte del nombre de la línea de vida se deja en blanco.
• Diferencia entre un salvavidas y un actor
  • Una línea de vida siempre representa un objeto interno del sistema, mientras que los actores se utilizan para representar objetos externos al sistema.

El siguiente es un ejemplo de un diagrama de secuencia:

1.3. Mensajes

La comunicación entre objetos se representa mediante mensajes. Los mensajes aparecen en orden secuencial en la línea de vida.

• Representamos mensajes mediante flechas.
• Las líneas de vida y los mensajes forman el núcleo de un diagrama de secuencia.

Los mensajes se pueden clasificar ampliamente en las siguientes categorías:

Mensajes sincrónicos

Un mensaje sincrónico espera una respuesta antes de que la interacción pueda avanzar. El remitente espera hasta que el receptor haya completado el procesamiento del mensaje. La persona que llama continúa solo cuando sabe que el receptor ha procesado el mensaje anterior, es decir, recibe un mensaje de respuesta.

• Una gran cantidad de llamadas en programación orientada a objetos son sincrónicas.
• Usamos un punta de flecha sólida para representar un mensaje sincrónico.

Mensajes asincrónicos

Un mensaje asincrónico no espera una respuesta del receptor. La interacción avanza independientemente de que el receptor procese o no el mensaje anterior. Usamos un punta de flecha rayada para representar un mensaje asincrónico.

1.4. Crear un mensaje

Usamos un mensaje Crear para crear una instancia de un nuevo objeto en el diagrama de secuencia. Hay situaciones en las que una llamada de mensaje particular requiere la creación de un objeto. Se representa con una flecha de puntos y la palabra de creación está etiquetada para especificar que es el símbolo de creación de mensaje.

Por ejemplo:

La creación de un nuevo pedido en un sitio web de comercio electrónico requeriría la creación de un nuevo objeto de clase Pedido.

1.5. Borrar mensaje

Usamos un mensaje de eliminación para eliminar un objeto. Cuando a un objeto se le quita memoria o se destruye dentro del sistema, utilizamos el símbolo Eliminar mensaje. Destruye la aparición del objeto en el sistema. Está representado por una flecha que termina en una x.

Por ejemplo:

significado de la comisión de selección de personal

En el siguiente escenario, cuando el usuario recibe el pedido, el objeto de la clase de pedido puede destruirse.

1.6. Auto mensaje

Pueden surgir ciertos escenarios en los que el objeto necesite enviarse un mensaje a sí mismo. Estos mensajes se denominan Automensajes y se representan con un flecha en forma de U .

Otro ejemplo:

Considere un escenario en el que el dispositivo quiere acceder a su cámara web. Este escenario se representa mediante un automensaje.

1.7. Mensaje de respuesta

Los mensajes de respuesta se utilizan para mostrar el mensaje que se envía desde el receptor al remitente. Representamos un mensaje de devolución/respuesta utilizando un punta de flecha abierta con una línea de puntos . La interacción avanza sólo cuando el receptor envía un mensaje de respuesta.

Por ejemplo:

Considere el escenario en el que el dispositivo solicita una foto al usuario. Aquí el mensaje que muestra la foto que se envía es un mensaje de respuesta.

1.8. Mensaje encontrado

Un mensaje encontrado se utiliza para representar un escenario en el que una fuente desconocida envía el mensaje. Se representa mediante una Flecha dirigida hacia una línea de vida. desde un punto final.

clasificación de matriz java

Por ejemplo:

Considere el escenario de una falla de hardware.

Puede deberse a múltiples motivos y no estamos seguros de qué causó la falla del hardware.

1.9. Mensaje perdido

Un mensaje perdido se utiliza para representar un escenario en el que el sistema no conoce al destinatario. Se representa mediante una flecha dirigida hacia un punto final de una línea de vida.

Por ejemplo:

Considere un escenario en el que se genera una advertencia.

La advertencia podría generarse para el usuario u otro software/objeto con el que interactúa la línea de vida. Como el destino no se conoce de antemano, utilizamos el símbolo de Mensaje perdido.

1.10. guardias

Para modelar condiciones utilizamos guardias en UML. Se utilizan cuando necesitamos restringir el flujo de mensajes con el pretexto de que se cumple una condición. Los guardias desempeñan un papel importante al permitir que los desarrolladores de software conozcan las limitaciones asociadas a un sistema o proceso en particular.

Por ejemplo:

Para poder retirar efectivo, tener un saldo mayor a cero es una condición que se debe cumplir como se muestra a continuación.

El diagrama de secuencia anterior muestra el diagrama de secuencia de un reproductor de música basado en emociones:

1. En primer lugar, el usuario abre la aplicación.
2. Luego, el dispositivo obtiene acceso a la cámara web.
3. La cámara web captura la imagen del usuario.
4. El dispositivo utiliza algoritmos para detectar el rostro y predecir el estado de ánimo.
5. Luego solicita a la base de datos un diccionario de posibles estados de ánimo.
6. El estado de ánimo se recupera de la base de datos.
7. El estado de ánimo se muestra al usuario.
8. La música se solicita desde la base de datos.
9. La lista de reproducción se genera y finalmente se muestra al usuario.

2. ¿Cómo crear diagramas de secuencia?

La creación de un diagrama de secuencia implica varios pasos y, por lo general, se realiza durante la fase de diseño del desarrollo de software para ilustrar cómo interactúan los diferentes componentes u objetos a lo largo del tiempo. Aquí hay una guía paso a paso sobre cómo crear diagramas de secuencia:

1. Identifique el escenario:
   • Comprenda el escenario o caso de uso específico que desea representar en el diagrama de secuencia. Podría ser una interacción específica entre objetos o el flujo de mensajes en un proceso particular.
2. Enumere los participantes:
   • Identificar los participantes (objetos o actores) involucrados en el escenario. Los participantes pueden ser usuarios, sistemas o entidades externas.
3. Definir líneas de vida:
   • Dibuja una línea discontinua vertical para cada participante, que represente la línea de vida de cada objeto a lo largo del tiempo. La línea de vida representa la existencia de un objeto durante la interacción.
4. Organizar líneas de vida:
   • Coloque las líneas de vida horizontalmente en el orden de su participación en la interacción. Esto ayuda a visualizar el flujo de mensajes entre los participantes.
5. Agregar barras de activación:
   • Para cada mensaje, dibuje una barra de activación en la línea de vida del participante que lo envía. La barra de activación representa el período de tiempo durante el cual el participante procesa activamente el mensaje.
6. Dibujar mensajes:
   • Utilice flechas para representar mensajes entre los participantes. Los mensajes fluyen horizontalmente entre líneas de vida, indicando la comunicación entre objetos. Los diferentes tipos de mensajes incluyen mensajes sincrónicos (flecha sólida), asíncronos (flecha discontinua) y automensajes.
7. Incluir mensajes de respuesta:
   • Si un participante envía un mensaje de respuesta, dibuje una flecha discontinua que regrese al remitente original para representar el mensaje de respuesta.
8. Indique tiempo y orden:
   • Utilice números para indicar el orden de los mensajes en la secuencia. También puede utilizar líneas discontinuas verticales para representar la ocurrencia de eventos o el paso del tiempo.
9. Incluir condiciones y bucles:
   • Utilice fragmentos combinados para representar condiciones (como declaraciones if) y bucles en la interacción. Esto agrega complejidad al diagrama de secuencia y ayuda a detallar el flujo de control.
10. Considere la ejecución paralela:
    • Si hay actividades paralelas, represéntelas dibujando líneas discontinuas verticales paralelas y colocando los mensajes en consecuencia.
11. Revisar y perfeccionar:
    • Revise el diagrama de secuencia para mayor claridad y corrección. Asegúrese de que represente con precisión la interacción prevista. Refina según sea necesario.
12. Agregar anotaciones y comentarios:
    • Incluya cualquier información adicional, anotaciones o comentarios que proporcionen contexto o aclaración de los elementos del diagrama.
13. Suposiciones y restricciones del documento:
    • Si hay suposiciones o limitaciones relacionadas con la interacción, documéntelas junto con el diagrama.
14. Herramientas:
    • Utilice una herramienta de modelado UML o un software de diagramación para crear un diagrama de secuencia ordenado y de aspecto profesional. Estas herramientas suelen ofrecer funciones para facilitar la edición, la colaboración y la documentación.

3. Casos de uso de diagramas de secuencia

• Visualización del comportamiento del sistema:
  • Los diagramas de secuencia se utilizan para ilustrar el comportamiento dinámico de un sistema mostrando las interacciones entre varios componentes, objetos o actores a lo largo del tiempo.
  • Proporcionan una representación clara y visual del flujo de mensajes y eventos en un escenario específico.
• Diseño y arquitectura de software:
  • Durante la fase de diseño del desarrollo de software, los diagramas de secuencia ayudan a los desarrolladores y arquitectos a planificar y comprender cómo interactuarán los diferentes componentes y objetos para lograr funcionalidades específicas.
  • Proporcionan un modelo para el comportamiento del sistema.
• Comunicación y colaboración:
  • Los diagramas de secuencia sirven como herramienta de comunicación entre las partes interesadas, incluidos desarrolladores, diseñadores, directores de proyectos y clientes.
  • Ayudan a transmitir interacciones complejas en un formato visual fácil de entender, fomentando la colaboración y la comprensión compartida.
• Aclaración de requisitos:
  • Al perfeccionar los requisitos del sistema, se pueden utilizar diagramas de secuencia para aclarar y especificar las interacciones esperadas entre los componentes del sistema o entre el sistema y entidades externas.
  • Ayudan a garantizar una comprensión común del comportamiento del sistema entre todas las partes interesadas.
• Depuración y solución de problemas:
  • Los desarrolladores utilizan diagramas de secuencia como herramienta de depuración para identificar y analizar problemas relacionados con el orden y la sincronización de los mensajes durante las interacciones del sistema.
  • Proporciona una representación visual del flujo de control y ayuda a localizar y resolver problemas.

4. Desafíos del uso de diagramas de secuencia

• Complejidad y tamaño:
  • A medida que los sistemas crecen en complejidad, los diagramas de secuencia pueden volverse grandes e intrincados. Administrar el tamaño del diagrama y al mismo tiempo representar con precisión las interacciones puede ser un desafío, y los diagramas demasiado complejos pueden resultar difíciles de entender.
• Nivel de abstracción:
  • Lograr el equilibrio adecuado en términos de abstracción puede resultar un desafío. Los diagramas de secuencia deben ser lo suficientemente detallados para transmitir la información necesaria, pero demasiados detalles pueden abrumar a los lectores. Es importante centrarse en las interacciones más críticas sin empantanarse en minucias.
• Naturaleza dinámica:
  • Los diagramas de secuencia representan aspectos dinámicos de un sistema y, como resultado, pueden cambiar con frecuencia durante el proceso de desarrollo. Mantener los diagramas de secuencia actualizados con el sistema en evolución puede ser un desafío, especialmente en entornos de desarrollo ágiles o que cambian rápidamente.
• Ambigüedad en los mensajes:
  • A veces, puede resultar complicado definir la naturaleza exacta de los mensajes entre objetos. La ambigüedad en el contenido o significado del mensaje puede provocar malentendidos entre las partes interesadas y afectar la precisión del diagrama de secuencia.
• Concurrencia y Paralelismo:
  • Representar procesos concurrentes y paralelos puede resultar complejo. Si bien los diagramas de secuencia tienen mecanismos para indicar la ejecución paralela, visualizar múltiples interacciones que ocurren simultáneamente puede ser un desafío y puede requerir elementos esquemáticos adicionales.
• Restricciones en tiempo real:
  • Representar limitaciones en tiempo real y requisitos de sincronización precisos puede resultar un desafío. Si bien los diagramas de secuencia proporcionan una representación secuencial, capturar y comunicar con precisión aspectos en tiempo real puede requerir documentación adicional o diagramas complementarios.