Presentación UML
Presentación UML
Presentación UML
Integrantes:
BR. Isaac Josué Grijalba lacayo.
br. Jordy Antonio Vargas Zapata.
BR. Luisángel Martín Marcia Palma.
BR. Jaime Román Silva.
Docente: Ariel Eduardo Chavez toruño
Grupo: 3m2 - is.
Objetivos
Objetivo General y Específicos 2
Objetivo General
Compartir la necesidad del Diagrama de Secuencia y su apropiado uso al momento de realizar la debida
documentación de un sistema informático desde el punto de Requerimientos y Análisis Sistémico.
Objetivos Específicos
❖ Dominar los diferentes términos técnicos que propone el lenguaje de modelado UML para la realización de
este tipo de documentación
❖ Comprender los diferentes elementos que intervienen en la elaboración de este tipo de diagrama UML
❖ Ubicar en qué categoría corresponde este diagrama referente a los tipos de diagramas que se encuentran en
el lenguaje modelado UML
❖ Otorgar un referente académico e informativo sobre el lenguaje modelado UML a partir de documentación
oficial en lenguaje inglés traducido al lenguaje español
❖ Relacionar el uso del Diagrama de Secuencia con otros tipos de diagramas UML sean de su categoría o de
alguna otra
Diagrama de Secuencia
Introducción
Interacción 3
Una interacción especifica cómo se intercambian mensajes y datos entre los socios de interacción.
Los socios de interacción son humanos, como profesores o estudiantes, o no humanos, como un servidor, una
impresora.
Una interacción puede ser una conversación entre varias personas, por ejemplo, un examen oral.
Alternativamente, una interacción puede modelar protocolos de comunicación como HTTP o representar el
intercambio de mensajes entre humanos y un sistema de software, por ejemplo, entre un profesor y el sistema de
administración de estudiantes cuando el profesor publica los resultados del examen. Una interacción también
puede ser una secuencia de llamadas a métodos en un programa o señales como una alarma de incendio y los
procesos de comunicación resultantes.
Diagrama de secuencia
Introducción
Diagrama de Interacción 4
Una interacción describe la interacción entre la interacción múltiple. socios y comprende una secuencia de
mensajes. El envió o recibo de un mensaje puede ser activado por la ocurrencia de ciertos eventos, por ejemplo,
la recepción de otro mensaje, y puede tener lugar en el momento especificado veces, por ejemplo, a las 05:00.
Las restricciones predefinidas especifican cualesquiera condiciones previas necesarias que deben cumplirse
para interacciones exitosas. Por ejemplo, continuando el proceso de comunicación descrito anteriormente, el
profesor debe iniciar sesión en el sistema antes de ingresar a los estudiantes los grados.
En UML, usa diagramas de interacción para especificar interacciones. En un diagrama de interacción, siempre
modela un escenario concreto, lo que significa que el intercambio de mensajes tiene lugar dentro de un contexto
específico para cumplir. Una tarea específica. Las interacciones generalmente solo describen una parte
específica de una situación. A menudo hay otras rutas de ejecución válidas que la interacción.
Diagrama de secuencia
Compañeros de Interacción
5
Interaction Partners (Compañeros de Interacción) son representados en el Diagrama de Secuencia como líneas
de vidas. Una línea de vida es mostrada como una vertical, usualmente por líneas no continuas que representan
la línea de vida de el objeto asociado con ello.
Diagrama de secuencia
Compañeros de Interacción
6
Al inicio de la línea es la cabeza de la línea de vida, un rectángulo el cual contiene una expresión en la forma
roleName:Class (figura 1.2.C). Esta expresión indica el nombre del role y la clase de el objeto asociado con la
línea de vida. De la misma manera como para el Diagrama de Objeto, uno de los dos nombres debería omitirse. Si
omites la clase, puedes omitir los dos puntos (figura 1.2.A); sin embargo, si especificas sólo la clase, los dos
puntos deben preceder el nombre de la clase (figura 1.2.B). Así, puedes definir un Diagrama de Secuencia para
ambos niveles de instancia y de clase.
Diagrama de secuencia
Compañeros de Interacción
7
En un Diagrama de Secuencia, el uso del concepto de role permite mayor flexibilidad en el modelado a simples
instancias o clases. Un objeto-siendo este, una instancia de una clase-puede tomar diferentes roles sobre el
tiempo de la línea de vida. Por ejemplo, tomemos en cuenta el caso de un sistema de control de inventario, es
concebible que la persona encargada del inventario, por ejemplo anaConda es inicialmente una contadora, que
luego se convirtió en supervisora de inventario, y finalmente en la encargada del almacén. Con cada nuevo role,
se tiene ciertas actividades que Ana Conda no le será permitida realizar o no tiene porqué realizar. Sin embargo,
habrán otras actividades las cuales ahora estará autorizada a realizar. Si consideramos la única clase de el
objeto anaConda a reflejarse en los diferentes roles que el objeto pueda tomar, cada tiempo que el role del
objeto cambie, tendremos que eliminar el objeto de esa instancia y por consecuencia crear uno nuevo con el
cambio de role previamente hecho. Alternativamente, la clase puede cambiar dinámicamente.
Diagrama de secuencia
Compañeros de Interacción
8
Los Roles pueden también estar conectados a más de un objeto. Este tipo de role es referido como un role
multivaluado. Sin embargo, una línea de vida puede estar únicamente representada a un objeto específico. Este
objeto es seleccionado por un selector. El selector es especificado como un cuadrado con llaves entre el
nombre del role y los dos puntos. Esto puede ser formulado por cualquier lenguaje, por ejemplo en el lenguaje
natural, pseudocódigo, Java, Python, C#, etc. Para especificar múltiples objetos de un role como interacciones
independientes compañeros de interacción simultáneamente, deberás asignar a cada objeto una línea de vida
por separado.
Diagrama de secuencia
Compañeros de Interacción
9
Una línea de vida puede representarse como un active object(objeto activo). Los Objetos Activos se suelen usar
para modelar sentencias de Threads (hilos). Un objeto activo tiene su propio control de flujo, lo cual significa
que puede operar independientemente de los otros objetos. La cabeza de su línea de vida está representada
como un objeto activo que tiene dobles líneas de márgenes por ambos de sus lados izquierdo y derecho.
Diagrama de secuencia
Compañeros de Interacción
10
En la Figura 1.2.F, la cabeza de la línea de vida contiene el nombre ‘self’. Esto se necesita cuándo la clase reluce
cierta interacción de contexto y es ella misma la involucrada durante esta interacción.
Diagrama de secuencia
Intercambio de mensajes
11
Los socios de interacción involucrados en la interacción son presentados en el eje horizontal y deben ser ordenados
en un orden claro.
El eje vertical modela el orden cronológico de la interacción, este determina la secuencia de la ocurrencia de eventos
en una línea de vida, aunque esto no define el orden de la ocurrencia de eventos en diferentes líneas de vida.
Diagrama de secuencia
Intercambio de mensajes
12
Las interacciones son consideradas como una secuencia de especificación del evento, estas especificaciones
cubren el envío y la recepción de mensajes o la ocurrencia de eventos basados en el tiempo.
Un orden a través de múltiples líneas de vida es forzado sólo si los mensajes son intercambiados entre diferentes
líneas de vida. A menos que se especifique lo contrario, se asume que la transmisión del mensaje no requiere ningún
tiempo, esto significa que el evento de envío del remitente y el evento de recibo del receptor toman lugar al mismo
tiempo.
La conexión cronológica entre un mensaje “a” y un mensaje “b” es expresada por el símbolo →. Por ejemplo, a → b
significa que el mensaje “a” es enviado antes que el mensaje “b”. Si el envío y recepción de eventos de dos mensajes
toman lugar a lo largo de la misma línea, el orden cronológico de estos eventos determina el orden de los mensajes.
Diagrama de secuencia
Mensajes
Mensaje Sincrónico 13
Un mensaje sincrónico es representado por una flecha de línea continua y una punta de flecha triangular.
Diagrama de Secuencia
Mensajes
Mensaje Asincrónico 14
Un mensaje asincrónico es representado por una flecha de línea continua y una punta de flecha abierta.
Diagrama de Secuencia
Mensajes
Mensaje de Respuesta 15
El mensaje de respuesta es representado por una flecha de línea discontinua y una punta de flecha abierta.
Diagrama de Secuencia
Mensajes
16
En el caso de mensajes sincrónicos, el emisor espera hasta recibir un mensaje de respuesta antes de continuar. Si
el contenido del mensaje de respuesta y el punto en el cual el mensaje de respuesta es enviado y recibido es claro
del contexto, entonces el mensaje de respuesta puede ser omitido en el diagrama. En una comunicación
asincrónica, el emisor continúa después de haber enviado el mensaje.
Diagrama de Secuencia
Mensajes
17
En ambos casos, un estudiante se comunica con un profesor para registrarse en un curso, donde en el primer caso,
el registro se hace vía email, por lo tanto, es asincrónico, ya que el estudiante no espera explícitamente el recibo de
confirmación del mensaje. En el otro caso, el estudiante se registra con el profesor personalmente y la
comunicación por lo tanto es sincrónica, ya que el estudiante espera hasta recibir un mensaje de respuesta.
Diagrama de Secuencia
Mensajes
Sintaxis de un mensaje de especificación 18
Los mensajes se identifican por un nombre, con una especificación opcional de parámetros y un valor de
retorno. Los parámetros están separados por comas y encapsulados en paréntesis. El valor de retorno puede
ser asignado opcionalmente a una variable.
Diagrama de Secuencia
Mensajes
Mensaje para crear objetos y Destrucción de evento 19
Un mensaje para crear objetos es un tipo especial de mensaje. Está representado por una flecha de línea
discontinua y con una punta de flecha abierta que finaliza en la cabeza de la línea de vida asociada al objeto a ser
creado. La flecha está nombrada con el nombre clave “nuevo” o “new”.
Si un objeto es eliminado durante el curso de una interacción, eso es, una destrucción de evento. El final de una
línea de vida está marcado por una “X”.
Diagrama de Secuencia
Mensajes
Mensaje Encontrado y Mensaje Perdido 20
Cuando el emisor de un mensaje es desconocido o irrelevante, esto se expresa como “mensaje encontrado”. En
este caso, se usa un circulo negro como fuente en vez de especificar un socio de interacción que envía el
mensaje. La contraparte de “mensaje encontrado” es “mensaje perdido”, donde es el receptor el desconocido. El
receptor también está representado de igual forma por un círculo negro.
Diagrama de Secuencia
Mensajes
Mensaje con Duración 21
Si queremos expresar el paso del tiempo entre el envío y recibo de un mensaje, se modela el mensaje con una
línea diagonal en el diagrama de secuencia en vez de una línea horizontal. Como la dimensión del tiempo está
representada verticalmente, esto visualiza la duración requerida para la transmisión de un mensaje. Este tipo de
mensaje está referido como “mensaje consumidor de tiempo” o “mensaje con duración”.
Diagrama de Secuencia
Fragmentos combinados
22
En el diagrama de secuencia se pueden usar fragmentos combinados (operadores) para modelar varias
estructuras de control de manera explícita lo cual permite describir rutas de ejecución de manera más
compacta y precisa.
Diagrama de Secuencia
Fragmentos combinados
23
En UML existen 12 tipos de operadores los cuales se dividen en tres categorías:
Operador Propósito
Ramas y bucles Alt Interacción alternativa
Opt Interacción opcional
Loop Interacción iterativa
break Interacción excepcional
Orden y concurrencia Seq Orden débil
Strict Orden estricto
Par Interacción concurrente
Critical Interacción atómica
Filtros y aserciones Ignore Interacción de partes irrelevantes
Consider Interacción de partes relevantes
Assert Interacción afirmada
neg Interacción invalida
Diagrama de Secuencia
Fragmentos Combinados
Ramas y Bucles 24
El operador alt representa secuencias alternativas, este operador tiene al menos dos operandos. Cada operando
representa una posible alternativa en la ejecución.
Cada operando tiene un guardia. Un guardia es una expresión booleana. Si no hay presencia del guardia se
asume el valor de [true] por defecto. Un guardia especial se le conoce como [else] el cual evalúa como [true] la
operación siempre y cuando otra condición no sea [true].
El operador opt representa una interacción secuencial el cual su ejecución es dependiente de un guardia.
Diagrama de Secuencia
Fragmentos Combinados
Ramas y Bucles 25
Diagrama de Secuencia
Fragmentos Combinados
Ramas y Bucles 26
El operador loop representa una secuencia que se va a ejecutar repetidamente. La palabra clave loop es seguida
por una especificación opcional que toma los valores min, max lo cual especifica las veces que se repiten las
interacciones.
El operador break tiene la misma estructura que un opt el cual consiste en un simple operando seguido de un
guardia. Break ofrece una manera simple de manejar las excepciones. Cuando en la interacción ocurre algún
tipo de excepción esta ejecuta el break en el que lleva a un punto del diagrama donde puede mandar algún tipo
de fallo y seguidamente finalizar la secuencia.
Diagrama de Secuencia
Fragmentos Combinados
Ramas y Bucles 27
Diagrama de Secuencia
Fragmentos Combinados
Orden y Concurrencia 28
El operador seq representa un orden por defecto, debe tener al menos un operando y expresa secuencias débiles.
El fragmento strict describe una interacción secuencial con un orden estricto. El orden de las ocurrencias de los
eventos en las diferentes líneas de vida entre diferentes operandos es significativo.
Diagrama de Secuencia
Fragmentos Combinados
Orden y Concurrencia 29
El fragmento par permite reservar cualquier orden cronológico entre mensajes en diferentes operandos. Desde
una perspectiva de tiempo, las rutas de ejecución de los diferentes operandos se pueden intercalar siempre que
se respetan las restricciones de cada operando individual. Por lo tanto, el orden de los diferentes operandos es
irrelevante.
Diagrama de Secuencia
Fragmentos Combinados
Orden y Concurrencia 30
Otra alternativa para asignar eventos en orden cronológico es usando un coregion, esto permite modelar eventos
concurrentes en una línea de tiempo simple.
Para asegurarse que ciertas partes en una interacción no sean interrumpidas por eventos inesperados, se utiliza
un fragmento critical.
Diagrama de Secuencia
Fragmentos Combinados
Filtros y ASerciones 31
Los filtros y aserciones definen cuales mensajes pueden ocurrir pero que no son relevantes en la descripción del
sistema, cuales mensajes deben ocurrir y cuales mensajes no deben ocurrir.
Los mensajes irrelevantes son indicados por el fragmento ignore el cual expresa que esos mensajes pueden ocurrir
en la corrida del sistema pero que no promueve significancia para las funciones representadas en el sistema.
El fragmento consider especifica aquellos mensajes que tienen una importancia particular para la interacción bajo
consideración. Todos los mensajes que ocurren en el fragmento consider pero que no están especificados en el
conjunto de los mensajes relevantes se clasifica automáticamente a irrelevante.
Diagrama de Secuencia
Fragmentos Combinados
Filtros y ASerciones 32
El fragmento assert identifica ciertos rastros modelados como obligatorios. Desviaciones que ocurren en la realidad
y no están en el diagrama no están permitidos. Por efecto esto significa que la implementación requiere un
modelado preciso y el modelo es una completa especificación.
Con el fragmento neg se modela una interacción invalida, esto es, describir situaciones que no deben ocurrir. El
fragmento neg consiste exactamente en un operando. Se puede usar este fragmento para resaltar explícitamente
errores frecuentes y representaciones críticas o secuencias incorrectas.
Diagrama de Secuencia
Otros Elementos del Lenguaje
Interacciones de referencia 33
Diagrama de Secuencia
Otros Elementos del Lenguaje
Puertas (Gates) 34
En principio, los mensajes no deben extenderse más allá de los límites de una interacción, una interacción
referenciada o a una interacción combinada, en otras palabras, no deben exceder la ventana arbitrariamente. Para
poder hacer esto UML ofrece gates. Los gates permiten enviar y recibir mensajes más allá de los límites el fragmento
de la interacción.
Diagrama de Secuencia
Otros Elementos del Lenguaje
MARCADORES DE continuación 35
Diagrama de Secuencia
Otros Elementos del Lenguaje
MARCADORES DE continuación 36
Diagrama de Secuencia
Otros Elementos del Lenguaje
Parámetros y ATRIBUTOS lOCALES 37
Igual que los otros tipos de diagramas en UML 2.4.1, el diagrama de secuencia está adjunto por una ventana
rectangular con un pentágono pequeño en la parte superior izquierda. El pentágono contiene la palabra clave
que indica que el contenido del rectángulo es un diagrama de secuencia. La palabra clave es seguida por el
nombre del diagrama de secuencia y parámetros opcionales separados por comas y adjunto con paréntesis.
También se puede declarar atributos locales en cualquier punto del diagrama, por lo cual la sintaxis de los
atributos corresponde a las especificaciones del atributo en el diagrama de clases. Se pueden declarar
atributos locales en una nota de forma alternativa.
Diagrama de Secuencia
Otros Elementos del Lenguaje
Limitaciones de Tiempo 38
Las limitaciones de tiempo especifican el tiempo que toma cuando ocurre cada evento o el tiempo entre dos
eventos.
La expresión de tiempo representa también una especificación de tiempo concreto por ejemplo {12:00} o una
regla de cálculo como {12:00+d}.
Puede especificar tiempos absolutos con la palabra clave at, por ejemplo {at(12:00)}.
Los tiempos relativos son especificados con referencia a un evento iniciado usando la palabra clave after, por
ejemplo {after(5sec)}.
También se pueden especificar un intervalo de tiempo, por ejemplo {12:00…13:00}.
La palabra clave now especifica el tiempo actual, puede ser asignado a cualquier atributo, por ejemplo, t=now,
{t…t+5}.
Diagrama de Secuencia
Otros Elementos del Lenguaje
Limitaciones de Tiempo 39
Diagrama de Secuencia
Otros Elementos del Lenguaje
Estados Invariantes 40
Se puede especificar los estados invariantes para una interacción. Un estado invariante afirma una cierta
condición que debe ser cumplida en un cierto tiempo. Siempre es asignado a una línea de vida específica. La
evaluación de si la invariante es verdadera toma lugar antes que el evento subsecuente ocurre. Si el estado
invariante no es verdadero, ya sea el modelo o la implementación está incorrecto.
Diagrama de Secuencia
Creando un diagrama de secuencia
La conexión entre un diagrama de clase y un diagrama de secuencia 41
Hemos dicho repetidamente que los diferentes diagramas UML no deberían ser considerado
independientemente uno del otro; simplemente ofrecen diferentes vistas de cierto contenido. Por ejemplo, el
diagrama de clase que se muestra en la figura, modela una parte de un sistema universitario que también incluye
sistema de administración estudiantil.
Diagrama de Secuencia
Creando un diagrama de secuencia
La conexión entre un diagrama de clase y un diagrama de secuencia 42
El sistema de administración de estudiantes tiene acceso directo a todos los estudiantes y cursos. El sistema
conoce los datos de registro para estudiantes y cursos que se almacenan en la clase Registro. Queremos
representar la comunicación que se requiere para crear un Nuevo registro de un determinado alumno para un
determinado curso. Para hacer esto, se debe llamar al método newRegistration de la clase StudentAdminSystem.
Para crear un nuevo registro, debemos conocer el objeto de estudiante que pertenece al número de matrícula
respectivo y al objeto del curso que pertenece al número de curso dado. Podemos obtenerlos llamando a las
operaciones getCourse y getStudent.
Diagrama de Secuencia
Creando un diagrama de secuencia
La conexión entre un diagrama de clase y un diagrama de secuencia 43
Tan pronto como tengamos esta información,
podemos crear un nuevo objeto del tipo
Registro y llamar al init operación que
establece el alumno y el curso para el objeto de
registro. Ahora solo tenemos que establecer la
conexión entre el registro y el curso, ya que se
supone la navegabilidad en ambas direcciones.
Hacemos esto llamando al método
setRegistration. No tenemos que hacer esto
para el registro y los objetos del alumno, como
navegación de Alumno a El registro no es
posible. El diagrama de secuencia resultante
se muestra a continuación:
Diagrama de Secuencia
Creando un diagrama de secuencia
Describiendo Patrones de Diseño 44
Los diagramas de secuencia a menudo se usan para
describir patrones de diseño. Los patrones ofrecen
soluciones para describir problemas recurrentes. En el
siguiente veremos el patrón Ensamblador de objetos
de transferencia [18], que modela la comunicación de
la Transferir objeto Patrón de ensamblador describe lo
que sucede cuando un cliente en un entorno distribuido
requiere información de tres objetos comerciales.
En la solución que se muestra en la figura, el cliente
requiere conocimiento sobre los tres objetos
comerciales para acceder a los datos requeridos. Por
lo tanto, el cliente está fuertemente vinculado a los
objetos de negocio, que generalmente no deseable.
Diagrama de Secuencia
Creando un diagrama de secuencia
Describiendo Patrones de Diseño 45
Podemos usar el patrón Transferir
ensamblador de objetos para desglosar
estas dependencias. En este patrón, un
ensamblador se fusiona los datos de
varios objetos comerciales en un objeto de
transferencia que es luego transferido al
cliente. El cliente recibe así los datos
requeridos. en forma encapsulada. En
términos concretos, se implementa el
patrón como se describe a continuación
(ver Fig. 6.32).
Diagrama de Secuencia
Diagramas de Comunicación, Temporización e Interacción General
46
En adición al Diagrama de Secuencia, UML apoya los siguientes tipos de diagramas de interacción:
• Diagrama de Comunicación
• Diagrama de Tiempo
• Diagrama de Interacción General
Los cuatro tipos de interacción de diagramas de UML son generalmente equivalentes por simples interacciones
basadas en los mismos elementos básicos. Con la especificación de los communication partners (compañeros
de comunicación) involucrados y los mensajes intercambiados, estos describen ciertas situaciones de
comunicación. Sin embargo, se enfocan en diferentes tipos de diagramas.
Diagrama de Secuencia
Diagramas de Comunicación, Temporización e Interacción General
47
La Figura 7.1 muestra el proceso de login como un Diagrama de Secuencia. De ahí los tres compañeros de
interacción: estudiante, sistema e-learning, y la base de datos. El estudiante quiere ingresar a través del login del
sistema y a partir de ahí envía un mensaje correspondiente a el sistema e-learning. Una consulta a la base de
datos verifica los derechos de acceso y el estudiante recibe una respuesta positiva por mensaje. Los posibles
casos de errores no son considerados. El estudiante luego solicita la lista de los cursos suscritos.
Figura 7.1
Diagrama de Secuencia
Diagramas de Comunicación, Temporización e Interacción General
48
Qué sucede con el hecho de que se cree el Diagrama de Secuencia inicialmente. Dado su estructura y enfoque
principal, podríamos proceder a relacionar de la misma manera tanto las clases que se relacionan como sus
interacciones para los diagramas antes mencionados. Tenemos que, entonces, nuestro Diagrama de
Comunicación es un diagrama estructurado que modela las relaciones entre los compañeros de interacción.
Este, Entonces, muestra directamente quién se comunica con quién. Las relaciones son el resultado del
intercambio de mensajes. Aquí, el tiempo no es una dimensión separada. El orden en cómo los mensajes son
intercambiados expresa el uso de clasificación decimal (secuencia numérica) por los mensajes.
Diagrama de Secuencia
Diagramas de Comunicación, Temporización e Interacción General
49
La Figura 7.2 muestra el proceso de Login previamente visto en
nuestro anterior diagrama pero a través del Diagrama de
Comunicación. De nuevo, los compañeros de interacción son:
estudiante, sistema e-learning, la base de datos. Este diagrama
muestra al estudiante comunicándose con el sistema e-learning dos
veces: la primera usando login(user, pw) y la segunda usando
getCourse(). Esto también muestra que el sistema e-learning
sistema comunica con la base de datos usando check(user, pw). Los
resultados de numeración en el orden login, check, y getCourse. Los
tres mensajes son mensajes sincronizados, se muestran por las Figura 7.2
cabezas de las flechas; los mensajes asíncronos se muestran con
cabezas de flechas abiertas. Mensajes de respuesta no están
representados en el Diagrama de Comunicación.
Diagrama de Secuencia
Diagramas de Comunicación, Temporización e Interacción General
50
Ahora con lo que respecta al Diagrama de Tiempo tenemos que este diagrama demuestra el estado cambiante entre
los compañeros de interacción tal que resulta en la ocurrencia de ciertos eventos. En contraste al Diagrama de
Secuencia, en donde el arreglo de los compañeros de interacción al eje de tiempo es exactamente opuesto, en el
Diagrama de Tiempo y los compañeros de interacción son listados en el eje vertical y en el eje horizontal se
representa el órden cronológico. A su vez en el Diagrama de Tiempo, las líneas de vida representan a cada área en la
cual declara los estados de transición que pueden ser representados. El nombre de la línea de vida (nombre de role
y/o clase) está determinado verticalmente hacia las limitaciones de la izquierda de el área.
Diagrama de Secuencia
Diagramas de Comunicación, Temporización e Interacción General
51
La Figura 7.3 así muestra los compañeros de interacción estudiante, sistema e-learning y base de datos. Un
estudiante puede estar en el estado de ‘loggueado’ o ‘desloggueado’ y el sistema e-learning puede tomar estados de
desocupado u ocupado. Para la base de datos se verifican los datos y así el estudiante se le es permitido el acceso
al sistema. El estudiante es informado de esto con un correspondiente mensaje de respuesta. El estudiante está
ahora en estado ‘loggueado’. El sistema e-learning puede brevemente retornar a el estado ‘desocupado’ hasta que el
estudiante envíe la solicitud ‘getCourse’.
Figura 7.3
Diagrama de Secuencia
Diagramas de Comunicación, Temporización e Interacción General
52
Para lo que corresponde al Diagrama General de Interacción se muestran las diferentes interacciones y se visualiza
el orden y las condiciones que cada una toma a lugar. Esto permite que puedas colocar varios diagramas de
interacción en un orden lógico. Para esto, usarás los conceptos primarios que el grupo encargado de Diagrama de
Actividad. En vez de eso, específicas nodos por acción y objetos, podrías especificar entre diagramas de interacción
y referencias de interacción como nodos los cuáles puedan ser colocados en el orden usando las estructuras de
control del Diagrama de Actividad. Un círculo sólido representa el nodo inicial y un círculo sólido representa el nodo
final. Puedes implementar diferentes caminos usando nodos de decisión representados por diamantes vacíos.
Diagrama de Secuencia
Diagramas de Comunicación, Temporización e Interacción General
53
La Figura 7.4 muestra una interacción sobre este tipo de diagrama, en adición a un nodo inicial y un nodo final,
también contiene el tipo de rama nodal. Si el estudiante tiene la autorización necesaria, el estudiante puede ejecutar
la interacción Forum, representado como un Diagrama de Secuencia
Figura 7.4
Diagrama de Secuencia
Conclusiones
54
El Diagrama de Secuencia forma parte vital entre los 4 diagramas de
interacción. Cabe destacar que gracias al Diagrama de Secuencia podemos
denotar las diferentes instancias que se van creando siempre y cuando
haya interacciones entre el Actor que efectúa la acción principal y los
diferentes objetos, entidades y clases que terminan acoplándose a la
situación que inicia por disparo de eventos el Actor. De igual forma
confírmamos la importancia de cada uno de los Diagramas a través de
cómo del Diagrama de Secuencia depende los demás diagramas de
interacción dado que la lógica entre la interacción de los Interaction Partner
brinda facilidad para las demostraciones en caso hipotético de la
depuración y funcionalidad de nuestro sistema sin aún necesariamente
haber estado codificando.
DIAGRAMA DE SECUENCIA
Conclusiones
55
Nuevamente confirmamos la importancia de la creación de la debida
documentación y cómo a través de UML podemos dar detalles sin perder
tiempo en codificación innecesaria la situación problémica que queremos
solucionar y de la mejor manera probar valoraciones para poder mejorar el
sistema previo a su codificación e implementación futura a tal grado que
los avances lógicos de un sistema queden reflejados como parte de la
concepción, desarrollo y nacimiento de un sistema de información Íntegro,
Confiable y Preciso para la realización de operaciones de la organización,
empresa o persona a la cual se destina.
DIAGRAMA DE SECUENCIA