ISTP “CARLOS CUETO FERNANDINI”

ÁREA ACADÉMICA DE COMPUTACIÓN E INFORMÁTICA

DIAGRAMA DE ESTADOS Y ACTIVIDAD

ALUMNOS: ALVAREZ VALDEZ, ALEXANDER

RIVERA PEÑA, YEFRY

PANTA REYES, JOSEPH

LIMA – PERU 2021

DIAGRAMA DE ESTADOS
1. Definición..............................................................................................................3
2. Para qué sirve el diagrama de estado..................................................................4
3. Características:.....................................................................................................5
4. Elementos.............................................................................................................6
4.1 Estado inicial......................................................................................................6
4.2 Estado final........................................................................................................7
4.3 Evento................................................................................................................7
4.3.1. Evento Cambio:.........................................................................................7
4.3.2. Evento Señal:.............................................................................................7
4.3.3. Evento Llamada.........................................................................................8
4.3.4.EventoTiempo:............................................................................................8
4.4 Punto de salida..................................................................................................8
4.5 Pseudoestado de opción...................................................................................8
4.6 Estado................................................................................................................9
4.6.1. Estado determinado por los Atributos.......................................................9
4.6.2. Estado determinado por las acciones del objeto.......................................9
4.6.3. Esta pasivo o en espera..........................................................................10
4.7 Acciones..........................................................................................................10
4.8 Fork..................................................................................................................11
4.9 Join..................................................................................................................11
4.10 Transición......................................................................................................11
4.10.1 Transición simple....................................................................................12
4.10.2 Transición interna...................................................................................12
4.10.3 Transacción compleja.............................................................................13
4.11 Subestados (submaquina)............................................................................13
5. Clasificación.......................................................................................................14
5.1. Estado simple.................................................................................................14
5.2. Estado compuesto..........................................................................................14
5.2.1. Estados secuenciales (Submaquina)......................................................15
5.2.2 Estados compuesto concurrentes (Submaquina)....................................16
6. Ventajas.............................................................................................................17
7. Desventajas.......................................................................................................17
DIAGRAMA DE ANALISÍS
8. Definición …………………………………………………………………………….19
9. El propósito de los diagramas de actividad ……………………………………….. 20
10. Las notaciones para los diagramas de actividades UML ………………………. 20
11. Actividades ……………………………………………………………………….…. 21
12. Acciones …………………………………………………………………………….. 22
12.1 Object Actions …………………………………………………………………….. 24
12.2 Link Actions ……………………………………………………………………….. 24
12.3 Link Objects Actions ……………………………………………………………… 24
12.4 Structural Feature Actions ………………………………………………………. 25
12.5 Variable Actions ………………………………………………………………….. 25
12.6 Accept Event Actions ……………………………………………………………. 25
12.7 Structured Actions ……………………………………………………………….. 26
12.8 Expansion Regions ……………………………………………………………… 27
12.9 Reduce Actions ………………………………………………………………….. 27
12.10 Raise Exceptions Actions …………………………………………………….. 28
13 Nodos de objeto …………………………………………………………………… 28
13.1 PIN ……………………………………………………………………………….. 28
13.2 Nodos de parámetros de actividad …………………………………………… 29
13.3 Nodo central del almacenamiento ……………………………………………. 30
13.4 Nodos de almacenamiento de datos …………………………………………. 30
14 Nodos de control ………………………………………………………………….. 30
14.1 Los nodos de inicio (Nodos Iniciales) ………………………………………… 31
14.2 Los nodos finales detinen el flujo de una actividad …………………………. 31
14.3 Nodos de paralelización y nodos de sincronización ………………………… 32
14.4 Los nodos de ramificación y los nodos de conexión ………………………... 33
 DIAGRAMA DE ESTADOS

1. Definición

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.
Un diagrama de estado también recibe el nombre diagrama de transición de
estados o diagrama de máquina de estados muestra los estados por los que
pasa una máquina de estados finitos, es decir, un modelo de comportamiento
que consiste en acciones permite representar el ciclo de vida completa de
cualquier sistema, subsistema o componentes o el objeto.
 Como podrían ser una máquina de café.
 Un lector de libros electrónicos.
 Un componente tecnológico de un vehículo.

Según:
Un diagrama de estados muestra el flujo de control entre estados (en qué
estados posibles puede estar “cierto algo” y como se producen los cambios
entre dichos estados) Una máquina de estados es un comportamiento que
especifica las secuencias de estados por las que pasa un objeto a lo largo de
su vida en respuesta a eventos, junto con sus
respuestas a esos eventos
(Booch, Rumbaugh, Jacobson)
 2. Para qué sirve el diagrama de estado

Como ya hemos mencionado, el objetivo de los diagramas de estado es

describir el comportamiento de un sistema con la máxima precisión. Entre otras

cosas, esta representación gráfica de los procesos debería dar respuesta a

las siguientes preguntas:

 ¿Qué sucede cuando el objeto está en un estado concreto?

 ¿En qué estado debe estar el objeto para cambiar de comportamiento?
 ¿Cuáles son los desencadenantes?
 ¿Qué propiedades debe tener el objeto para poder cambiar de estado?

Por lo tanto, los diagramas de estado UML se utilizan para optimizar cualquier

proceso de desarrollo donde sea útil visualizar los estados del objeto y las

condiciones para que se produzca la transición de un estado a otro. Suelen

emplearse, por ejemplo, en el diseño de sistemas embebidos, donde las

señales automatizadas y los procesos en segundo plano deben estar

perfectamente coordinados.

En este caso, el diagrama de estado ayuda a los desarrolladores a

desarrollador esa visualizar todas las funciones de control y regulación más

importantes en un solo esquema.

La función de interrupción de la toma de agua que tienen casi todas

las lavadoras pueden servirnos de ejemplo para imaginar un diagrama de

estado UML. En este contexto, esta función se representaría como un sistema

independiente. En este caso,

el esquema mostraría en qué estado y bajo qué condiciones se activa la

3. Características:

 Representación de un objeto en los diferentes

espacios de tiempo que le van sucediendo. Cuando hablamos de estado
estamos hablando de los diferentes estados que puede tener un objeto.

 Hay un estado de inicio y un estado final.

 Cada evento representa algo que hace que nuestro objeto pueda cambiar.

 Existen unas líneas que llamamos líneas de transición, su finalidad es

describir el movimiento de un estado a otro. A estas líneas le ponemos el
nombre del evento que origina la transición.

 Se deben considerar las técnicas que sean necesarias para su utilización.

 4. Elementos

Vamos a ver un pequeño resumen de los elementos que componen un diagrama

de estado:

4.1. Estado inicial

El estado inicial de un objeto tiene su propia única notación, un punto
sólido con una flecha que apunta al primer estado asociado. El estado
inicial indica el estado en el que un objeto se crea o se construye.

- Es obligatorio.

- Solo un estado inicial es permitido por diagrama.

- El estado inicial es representado a través de un circulo sólido.

4.2. Estado final
Un objeto puede alcanzar un estado final en que ninguna otra actividad puede
ocurrir y desde la que no se puede regresar a un estado activo. 

 Son opcionales.

 Puede existir más de un estado final por diagrama.

4.3. Evento 
Es una ocurrencia que puede causar la transición de un estado a otro de un
objeto. El nombre de un evento tiene alcance dentro del paquete en el cual está
definido y puede ser usado en los diagramas de estado por las clases que
tienen visibilidad dentro del paquete. Un evento no es local a la clase donde
está declarado. Pueden ser un:

4.3.1. Evento Cambio:

Condición que toma el valor de verdadero (normalmente descrita como una
expresión booleana).

4.3.2. Evento Señal:

Es una recepción de una señal explícita de un objeto a otro.

4.3.3. Evento Llamada

Es una recepción de una llamada a una operación.
4.3.4. Evento Tiempo:
Es un. paso de cierto período de tiempo, después de entrar al estado actual, o de
cierta hora y fecha concretas.

4.4. Punto de salida

El punto en el cual un objeto escapa del estado compuesto o maquina de estado el
cual se indica por medio de un circulo cruzado con una X.

4.5. Pseudoestado de opción

Un símbolo de diamante que indica una condición dinámica con resultados
potenciales ramificados (bifurcación).

4.6. Estado 
Un estado identifica una condición o una situación en la vida de un objeto
 durante la cual satisface alguna condición, realiza una actividad o espera un
evento, puede estar en cualquier estado durante una cantidad de tiempo
determinado en su forma es un rectángulo redondeado que muestra el estado
en que se encuentra un objeto.

4.6.1. Estado determinado por los Atributos

La primera situación que determina el estado de un objeto se define por los
datos que en ese momento están asociados al objeto analizado. En otras palabras
a los valores de alguno o algunos de sus atributos por
Ejemplo:
Una persona que tenga edad 8 años esta en el estado “niñez” si edad es 14
esta en “adolescencia” y así respectivamente el atributo más simple que podría
definir el estado.

4.6.2. Estado determinado por las acciones del objeto

La segunda situación que determina del estado del objeto analizando son las
acciones realizadas por el mismo en un momento determinado
Ejemplo
Un productor de MP3 cuando toca la música esta en estado de “tocando” un avión
que va surcando los cielos esta “volando”.

”.
4.6.3. Esta pasivo o en espera
El estado mas simple es aquel en el que el objeto analizado simplemente
espera a que algo ocurra en el entorno para pasar a un nuevo estado.
Ejemplo
Nuevamente con el reproductor de MP3, este esta en “pausa” hasta que el usuario
le indique que continúe reproduciendo la música o se detenga totalmente

4.7. Acciones
Podemos especificar la solicitud de un servicio a otro objeto como consecuencia de
la transición, Se puede especificar el ejecutar una acción como consecuencia de
entrar, salir, estar en un estado, o por la ocurrencia de un evento.
• Una llamada a una operación (al objeto al cual pertenece el diagrama de estado o
también a otro objeto visible).

• La creación o la destrucción de otro objeto.

• El envío de una señal a un objeto.

4.8. Fork

Desprende dos estados que suceden al mismo tiempo, resultando de un único

estado.
4.9. Join

Une dos estados que suceden al mismo tiempo, tiene como resultado un único
estado.

4.10. Transición
Una transición se representa con una flecha continua que une dos estados.
estados y que se dirige al estado al que cambia el componente. Junto a
ella se coloca una etiqueta que debe contener al menos el nombre del
evento que provoca la transición.

Según el nivel de detalle, puede presentar otros elementos con el formato

siguiente:
4.10.1. Transición simple
Una transición simple es una relación entre dos estados que indica que un objeto
en el primer estado puede entrar al segundo estado y ejecutar ciertas operaciones,
cuando un evento ocurre y si ciertas condiciones son satisfechas.

4.10.2. Transición interna

Es una transición que permanece en el mismo estado, en vez de involucrar dos

estados distintos. Representa un evento que no causa cambio de estado. Se
denota como una cadena adicional en el compartimiento de acciones del estado

4.10.3. Transacción compleja

Una transición compleja relaciona tres o mas estados en una transición de
múltiples fuentes y/o múltiples destinos. Representa la subdivisión en theads del
control del objeto o una sincronización. Se representa como una línea vertical de la
cual salen o entran varias líneas de transición de estado.
4.11. Subestados (submaquina)
También llamado submaquina un estado puede descomponerse en subestados,
con transiciones entre ellos y conexiones al nivel superior. Las conexiones se ven
al nivel inferior como estados de inicio o fin, los cuales se suponen conectados a
las entradas y salidas del nivel inmediatamente superior.

5. Clasificación

5.1. Estado simple

Es una relación entre dos estados que indica que un objeto en el primer estado
puede entrar al segundo estado y ejecutar ciertas operaciones, cuando un evento
ocurre y si ciertas condiciones son satisfechas.
Una transición simple se representa gráficamente como una línea continúa dirigida
desde el estado origen hasta el estado destino.

5.2. Estado compuesto

Las características de los estados y de las transiciones, vistas en los apartados
anteriores, resuelven un gran número de problemas a la hora de modelar un
diagrama de estado. Sin embargo, hay otra característica de las máquinas de
estado de UML, los subestados, que nos ayudan a simplificar el modelado de
aquellos comportamientos complejos. Un estado simple es aquel que no tiene
estructura. Un estado que tiene subestados, es decir, estados anidados, se
denomina estado compuesto. Un estado compuesto puede contener bien
subestados secuenciales (disjuntos) o bien subestados concurrentes (ortogonales).

Acción
 Entrry : Acción que se realiza cuando se llega a un estado.
Do : Actividad que se ejecuta mientras esta en un estado.
Exit : Acciones que se ejecuta cuando se abandona un estado.

5.2.1. Estados secuenciales (Submaquina)

Contiene uno o más subestados. Cuando el estado está activo significa que lo esta
uno de los subestados, este tipo de estados compuestos es una ayuda para
simplificar máquinas de estado mediante un mecanismo de abstracción de
agregación de estados dependientes.
5.2.2 Estados compuesto concurrentes (Submaquina)

Las regiones ortogonales permiten especificar dos o más máquinas de estados

anidadas que se ejecutan en paralelo en el contexto del objeto que las contiene.
El estado compuesto acaba mediante una sincronización de las regiones
ortogonales: las regiones que alcanzan sus estados finales quedan a la espera
hasta que todas las regiones acaban, y entonces concluye el estado compuesto
Cada región ortogonal puede tener un estado inicial, un estado final y un estado de
historia.

6. Ventajas

 Permite que el analista se centre en las necesidades del usuario.

 El diagrama de estados tiene éxito en sistemas interactivos, ya que expresa
la intención que tiene el actor(usuario) al hacer uso del sistema.

 Asu ves durante la extracción el analista se concentra en las tareas

centrales del usuario describiendo por lo tanto los casos de uso que mayor.

 valor aporta al negocio facilitando la priorización del requerimiento.

7. Desventajas

 La inclusión de estas relaciones hace que los diagramas sean más difíciles

de leer, sobre todo para los clientes.

DIAGRAMA DE ANALISIS
8. DEFINICIÓN
Un diagrama de Actividad demuestra la serie de actividades que deben ser
realizadas en un uso-caso, así como las distintas rutas que pueden irse
desencadenando en el uso-caso.
Es importante recalcar que, aunque un diagrama de actividad es muy similar
en definición a un diagrama de flujo (típicamente asociado en el diseño de
Software), estos no son lo mismo. Un diagrama de actividad es utilizado en
conjunción de un diagrama uso-caso para auxiliar a los miembros del equipo
de desarrollo a entender como es utilizado el sistema y cómo reacciona en
determinados eventos. Lo anterior, en contraste con un diagrama de flujo
que ayuda a un programador a desarrollar código a través de una
descripción lógica de un proceso. Se pudiera considerar que un diagrama de
actividad describe el problema, mientras un diagrama de flujo describe la
solución.

9. EL PROPÓSITO DE LOS DIAGRAMAS DE ACTIVIDAD

Los diagramas de actividad UML pertenecen al grupo de diagramas de
actividad UML. Además de los diagramas de actividades, los diagramas de
casos de uso y los diagramas de máquinas de estado también se incluyen
en este grupo. Los diagramas funcionan de manera similar en términos de
uso y notación a los diagramas de flujo , pero son adecuados para la
programación orientada a objetos. Por ejemplo, una acción es «cascar un
huevo» seguida de «cascar un huevo con especias».
La segunda acción está subordinada a la primera acción. Entonces, una
actividad tiene dos puntos de partida, desde los cuales las personas
 comienzan esa actividad y pasan de una acción a otra. En el diagrama de
actividades, los dos actores en acción juegan un papel importante, pero no
reciben su propia designación. Se mueven de principio a fin, atravesando el
flujo o el objeto de prueba y pasando de una acción a otra.
Hay dos tipos de tokens en los diagramas de actividad de UML. El primero
es un objeto token que pasa información al nodo de acción, inicia una acción
allí y almacena el resultado como un valor. Si el resultado y el token
coinciden con una especificación definida por pin, ese pin de salida envía el
objeto token a través del flujo de objetos a la siguiente acción. El token debe
cumplir con las especificaciones del pin de entrada antes de que se pueda
iniciar esta acción.
Inicia una acción, pero no envía ningún dato. Los diagramas de casos de
uso, por otro lado, representan los requisitos del sistema que deben
cumplirse. Por supuesto, los diagramas de actividad UML no son solo para
aplicaciones comunes. Al integrar herramientas UML en un entorno de
desarrollo integrado, los diagramas pueden actuar como un marco de código
utilizando la transformación XML como lenguaje de programación.

El Object Management Group (OMG), que especifica el lenguaje unificado

de modelado (UML), resume las posibles tareas de los diagramas de
actividades UML de la siguiente manera:

 Programación informática procedimental que asigna jerarquías a las

actividades.
 En los modelos orientados a objetos, las actividades actúan como
métodos que describen los procesos con más detalle.
 Visualización de flujos de trabajo y procesos empresariales.
 En el caso de los sistemas de aplicación asistidos por ordenador, las
actividades especifican los procesos a nivel de sistema.

10. Las notaciones para los diagramas de actividades UML

Las formas dentro del UML pueden ser equiparadas a los componentes de
las oraciones en un idioma. Por lo tanto, el lenguaje de modelado asigna un
significado a cada forma. Los modificadores se encargan de describir las
formas con más detalle y de relacionarlas entre sí. Además, hay que tener
en cuenta que, a veces, las formas necesitan otras formas o etiquetas para
crear un diagrama significativo. Del mismo modo que el lenguaje hablado
solo tiene sentido si se respetan ciertas reglas gramaticales básicas, UML
solo funciona como medio de comunicación si se respetan las
especificaciones.

UML 2.5 es la especificación más reciente del lenguaje de modelado y, por

lo tanto, constituirá la base de las indicaciones que siguen. UML determina
la notación de los tipos de diagrama basándose en sus áreas de aplicación.
Dado que el diagrama de actividades UML representa el flujo de los
procesos del sistema y los casos de uso, el metamodelado le asigna los
formularios apropiados.
 ¿Cómo se muestran visualmente los componentes individuales y qué
funciones cumplen los símbolos en el diagrama de actividades UML?

11. ACTIVIDADES
En UML 2 una actividad (activity en inglés) es un comportamiento que
supedita las unidades subordinadas (acciones y objetos) a una secuencia
cronológica. Para ello, utiliza modelos de flujo de datos y de control. El
diagrama de actividades se puede visualizar como parte de un sistema más
grande junto con otros tipos de diagrama. Un rectángulo grande y
redondeado marca la actividad como un sistema cerrado (aunque puede
omitirse). En la imagen de ejemplo, más abajo, se puede ver la actividad
“Cocinar espárragos”. En el encabezado del rectángulo grande se escribe el
título. El cuerpo contiene flechas (bordes, edges en inglés) y rectángulos que
simbolizan las acciones, los objetos y los flujos de datos o de control de la
operación.
 Las actividades se consideran clases en UML (su metaclase es el
comportamiento) que pueden definirse más concretamente con propiedades.
Esto puede influir en los elementos subordinados. Una actividad se da por
finalizada cuando un token se ha movido, a través de las diversas acciones,
desde su punto de partida inicial hasta el punto final. El punto finaldestruye
el token, así como a todos los demás tokens, de forma que la actividad
detiene todas las acciones sincrónicas.

NOTA:
UML 1 define los diagramas de actividad de forma diferente a UML 2. En
versiones anteriores, se asignó un rol especial de diagrama de máquina de
estados, limitando el área de la aplicación. Si está utilizando el motor UML,
debe asegurarse de que sea compatible con la representación deseada.
Idealmente, debería ser UML2.5 o posterior.

12. ACCIONES
Una acción (en inglés, action, executable node) es un elemento del modelo
que está jerárquicamente subordinado a la actividad: la acción es una
instancia de la clase actividad. Las acciones representan a un
comportamiento dentro de un sistema: son los bloques de construcción
básicos utilizados para expresar el comportamiento en UML. Se utilizan
tanto en los diagramas de actividades como en las interacciones.
Al crear un diagrama de actividades, se utiliza la notación “Acción” para
representar las partes ejecutables de una actividad. En el ejemplo anterior,
la acción de “pelar los espárragos y ponerlos en la olla” es un paso hacia la
finalización de la actividad “cocinar los espárragos”. Las acciones reciben
información de entrada, la procesan y producen información de salida. Una
acción no se detiene hasta que se completa.
Dentro de los diagramas de actividades UML, las acciones pertenecen a los
nodos de actividad. Las flechas conectan las acciones entre sí. UML
distingue entre flujos de objetos (flujos de datos) y flujos de control
(transporta tokens de control). Las acciones solo procesan flujos de control.
Cuando los flujos de datos se mueven entre acciones, los pins (nodos de
objetos) aceptan los tokens de objetos como entrada, los convierten para
procesarlos en la acción y luego generan la salida de objetos que se mueve
como tokens de objetos.

La categoría de nodo activo se introdujo en UML2. Hay tres subtipos: botón

de control, nodo de objeto y botón de ejecución (acción). No existe una
jerarquía entre estos tres. Se pueden ejecutar en cualquier orden (es decir,
tan pronto como un token entrante cumpla con los criterios del nodo) o en
paralelo, a menos que estén concatenados o definidos de forma más precisa
en el grupo de 'operaciones'.

Solo cuando se cumplen las condiciones especificadas en los pines, los

datos introducen una acción (pin de entrada) o la acción produce un
resultado (pin de salida). Incluso si una acción tiene varios flujos de control
de entrada, cada una debe ofrecer un token antes de que se inicie la acción.

Para las acciones dentro de un diagrama de actividad, la sintaxis presenta la

forma simple del rectángulo redondeado. Sin embargo, los modeladores
también pueden recurrir a acciones específicas para obtener descripciones
más detalladas. UML emplea su propia notación para expresar algunas de
ellas:

 Opaque actions son “acciones opacas”. Actúan como marcadores de

posición o se especifican mediante una sintaxis de texto concreta (no
definida por UML).
 Invocation actions son acciones que causan un cierto
comportamiento, tanto directa como indirectamente.
Esto incluye:
  Call actions: Una call behavior action es una llamada directa a un
comportamiento. Una call operation action, en cambio, envía una
petición a un objeto que llama a un comportamiento asociado. La start
object behavior action hace que un objeto ejecute directamente su
comportamiento de instancia. Si no se determina ninguna, puede
desencadenar el comportamiento de clase de nivel superior (classifier
behavior).

La notación de una acción que origina un comportamiento es un rectángulo

redondeado y en él deberás introducir el nombre del comportamiento. Las
call behavior actions también están marcadas con un símbolo de tridente
(como se muestra en la imagen de abajo). Esto representa la ramificación
jerárquica adicional creada por la acción.

 Send actions: En el gráfico de actividad, la acción de envío siempre

envía datos de forma asincrónica (los diagramas de secuencia
también reconocen los mensajes sincrónicos). Esto significa que no
espera una respuesta del objeto de destino y, por lo tanto, no bloquea
el hilo del objeto. La acción finaliza tan pronto como se envía el
mensaje. Por lo tanto, es posible tener entradas para los argumentos
como parámetros, pero no se produce una salida resultante. Además,
puede enviar un mensaje a varios destinatarios al mismo tiempo. Las
acciones del remitente, las acciones de la señal de difusión y las
acciones del remitente se incluyen en esta categoría.
Las acciones de envío de señales se desvían en su notación de la forma
habitual (el rectángulo redondeado) y en su lugar un pentágono indica la
dirección de la señal transmitida como una gran flecha. Si el contenido de
una acción de objeto de envío también consiste en una señal, puede utilizar
la misma notación.

12.1 OBJECT ACTIONS

Las object actions modifican el estado de los objetos (y también las

instancias de una clase). Puedes crearlos o destruirlos, compararlos con
otras instancias, leerlos y luego asignarlos a una clase o modificar la
clasificación. Las instancias de acciones de objetos existen bajo UML 2 son
las siguientes:
 Las create object actions generan instancias de una clase, es decir, objetos.
 Las destroy object actions destruyen el objeto en su pin de entrada.
 Las test identity actions examinan si dos valores en su pin de entrada
representan el mismo objeto.
 Read self actions, determinan su propio objeto de contexto.
 Value specification actions, examinan las especificaciones de valor. La
notación lleva la etiqueta value specification.
 Read extent actions, encuentran todos los objetos de una clase, así como
los objetos de sus especificaciones. Por razones prácticas, los modeladores
suelen limitar el radio de alcance.
 Reclassify object actions, cambian la clase del objeto en el pin de entrada.
 Read is classified object actions, determinan si un objeto en el pin de
entrada pertenece a una clase.
 Start classifier behavior actions desencadenan un comportamiento para un
objeto que está determinado por su clase. El comportamiento es entonces
asincrónico.

12.2 LINK ACTIONS

Las link actions cambian el comportamiento de las asociaciones (las

relaciones entre clasificadores, por lo general de dos clases) y sus
instancias, los enlaces. Aquí se incluyen:
 Read link actions: recuperan valores (datos de fin de enlace) en una página
de una asociación.
 Create link actions: crean enlaces (no tienen pins de salida porque los
enlaces no son datos en sí mismos) y enlazan objetos.
 Destroy link actions: eliminan los enlaces y los objetos de enlace si
corresponden a un valor de datos del extremo del enlace especificado.

12.3 LINK OBJECT ACTIONS

Las link object actions influyen en el comportamiento de los objetos
enlazados de forma similar a las link actions, pero consideran los objetos
desde otros puntos de vista. Estas son las instancias de acciones de objetos
de enlace:
 Read link object end actions, que recuperan objetos finales de objetos
enlazados.
 Read link object end qualifier actions, que recuperan los valores finales del
clasificador de los objetos de enlace.
 Create link object actions, que son acciones Create link especiales que se
pueden utilizar para crear objetos de enlace.

12.4 STRUCTURAL FEATURE ACTIONS

Las structural feature actions determinan el comportamiento de las
características estructurales en los diagramas de actividades. Para ello
necesitan un pin de entrada, ya que normalmente se les asigna un objeto y
una característica estructural de un clasificador especificada estáticamente.
La acción de las características estructurales afecta a ambos elementos.
Existen los siguientes tipos:
 Read structural feature action: leen los valores de las características
estructurales y los transmiten como salida.
 Add structural feature value actions: requieren un pin de entrada de valores.
Especifican el valor que la acción asigna a una característica estructural.
 Remove structural feature value actions: restan un valor de una
característica estructural. Un pin de entrada de valores con multiplicidad 1..1
especifica este valor.
 Clear structural feature actions: eliminan todos los valores de un elemento
de estructura.

12.5 VARIABLES ACTIONS

Las variable actions influyen en las variables especificadas estáticamente
que están definidas por una actividad o un nodo de actividad estructurado.
Hay tres tipos:
 Add variable value actions, también requieren un pin de entrada de valores.
Debe ser del mismo tipo que la variable y añadirle exactamente un valor.
 Remove variable value actions, eliminan un valor especificado por el pin.
 Clear variable actions, eliminan todos los valores de una variable.

12.6 ACCEPT EVENT ACTIONS

Los accept event actions pertenecen a los llamados puntos de espera (wait
points). Esto significa que la acción espera que tenga lugar un evento (event)
del pool de eventos del objeto context. La acción cuenta con
desencadenantes que provocan la acción cuando se producen uno o más
estados prescritos. UML describe tres especializaciones:
 Accept call actions: tienen un disparador que acepta eventos de llamada.
Dos pins de salida de resultados y un pin de salida de información de retorno
completan el acuerdo. Si se debe ejecutar una acción de respuesta, la
información necesaria para ello se almacena en el pin de salida de
información de retorno.

 Reply actions: tienen una conexión con las acciones de aceptar llamada.
Por un lado, los desencadenantes deben coincidir para que la acción de
respuesta, en el caso de un evento de llamada, pueda reaccionar a la acción
de aceptación de llamada ejecutada previamente. Por otro lado, el
comportamiento del cual depende coloca su valor de salida en el pin de
entrada de información de retorno de la acción de respuesta.
 Unmarshall actions: consultan los valores de las características de la
estructura de referencia. Para reconocer el objeto, tienen un pin de entrada
de objeto. Los valores obtenidos se emiten en un pin de salida.
 12.7 STRUCTURED ACTIONS
Las structured actions están declaradas en el diagrama de actividades con
UML 2 como una acción y como un grupo de actividades (ver arriba). Esto
significa, por un lado, que su comportamiento está determinado por los
nodos de actividad y las flechas y, por el otro, que ciertos subtipos de estas
acciones prescriben un determinado comportamiento para los nodos
ejecutables debido a su semántica, en particular con respecto a su
secuencia.
Estos son los subtipos de acciones estructuradas:
 Conditional nodes, consisten en una o más cláusulas que representan las
diferentes ramas de las posibles acciones ejecutables. Una cláusula
contiene un segmento de prueba y un segmento de cuerpo, que a su vez
incluyen nodos ejecutables sin cortes. En primer lugar, la cláusula ejecuta la
acción en el área de prueba. Si su valor de salida es verdadero, la cláusula
ejecuta la acción en el área del cuerpo.
 Loop nodes, describe un grupo de acciones que se repiten dentro de un
bucle. Las acciones se dividen en tres secciones: configuración, prueba y
cuerpo. El bucle siempre ejecuta la configuración primero, seguido por una
prueba o cuerpo que luego se repetirá alternativamente.
 Sequence nodes, imponen una secuencia a los nodos ejecutables dentro
de sus límites. Estos se representan con flujos de datos como flechas, que
pueden apuntar hacia dentro o hacia fuera de la estructura.

12.8 EXPANSION REGIONS

Las expansión regions son otro tipo de nodo activo estructurado. Aceptan
uno o más conjuntos de valores de entrada. De camino al área de extensión,
el candado de entrada copia cada ficha ingresando el número de elementos
de la colección. Cada nodo de la colección está interesado en cada valor de
la colección. El giro se considera una carrera prolongada. Un nodo de sonda
(un tipo de nodo de objeto) indica una interfaz en el área de la sonda.
Externamente, representa sus valores como un conjunto e internamente,
cada elemento del conjunto se trata como un valor. Para puntuar, se dibuja
 un rectángulo con esquinas redondeadas con una línea de puntos. El nodo
de expansión aparece como un rectángulo segmentado y se dibuja
directamente en la línea, como se muestra a continuación. La segmentación
debe representar una lista de conjuntos de valores.

12.9 REDUCE ACTIONS

Las reduce actions provocan un comportamiento hasta que un único valor
emerge de una colección de valores. Para este fin, la acción combina los
elementos de la colección. Por lo tanto, la acción tiene dos parámetros de
entrada, pero sólo un parámetro de salida o retorno.

12.10 RAISE EXCEPTION ACTIONS

Las raise exception actions terminan por sí mismas tan pronto como
causan una excepción. Por lo tanto, no terminan como las acciones
normales, que se detienen cuando se completa la acción. Se extienden
hacia el exterior a través del sistema hasta el siguiente nodo de actividad
estructurado superior. Si tienes un controlador que coincide con la
excepción, la acción se detiene. De lo contrario, sigue propagándose.

13. NODOS DE OBJETO

 Los nodos de objetos son subtipos de los nodos de actividad. En UML, un
objeto suele ser la instancia con valor más pequeña. Los objetos
representan datos en el diagrama de actividades. Mientras se ejecuta una
acción, los nodos de objeto retienen estos datos. Porque solo los tokens de
control pueden recorrer una acción. Los tokens de objeto, en cambio, entran
como valores por un pin de entrada y son enviados desde el pin de salida al
flujo de objetos.

Los nodos de objetos se introdujeron por primera vez en el diagrama de

actividades del UML-2. Son elementos tipificados. Si un nodo de objeto
corresponde a un determinado tipo, los tokens de objeto que se mueven
sobre él deben tener valores correspondientes. Una excepción son los
tokens nulos que no tienen valor, ajustándose a cada nodo de objeto.

Los nodos de objeto prescriben el orden en el que los tokens los dejan. Hay
cuatro maneras de hacerlo:

 Desordenado (no especificado)

 Ordenado (comportamiento definido por el modelador)
 FIFO (first in first out): el orden de entrada y salida sigue siendo el mismo.
 LIFO (last in first out): el orden es exactamente el opuesto.

13.1 PIN
Ya hemos hablado de los pins. En el primer gráfico se podía ver la notación
básica de los pins. Debido a su función de enlace entre las acciones y los
flujos de objetos, los modeladores suelen dibujarlos como pequeños
rectángulos directamente sobre el símbolo de la acción. Los pins de entrada
(input pins) están marcados con un borde (un flujo de objeto) en la dirección
de la acción. Para los pins de salida (output pins) la flecha se aleja de la
acción. El siguiente gráfico muestra cómo se pueden acortar la
representación de pins del mismo tipo (izquierda) o cómo se pueden dibujar
pins de entrada y salida si se omiten los bordes (derecha).

13.2 NODOS DE PARÁMETROS DE ACTIVIDAD

La actividad pertenece a la metaclase de la descripción del comportamiento.
Según UML, todo comportamiento tiene parámetros. Antes de que se
ejecute un comportamiento, puedes alimentarlo con valores para su
procesamiento. Una vez procesados, el sistema devuelve nuevos valores.
En esta estructura, los parámetros son los marcadores de posición que
permiten introducir o emitir estos valores. El nodo de parámetro de actividad
se encarga de esto en el diagrama de actividades UML. Esto significa que
los nodos de parámetros de actividad se encuentran al principio y al final de
una actividad.
Como resultado, un nodo de este tipo tiene solo flechas de actividad de
entrada o de salida. Los nodos de parámetros de actividad de entrada se
dibujan con flechas de salida y los nodos de parámetros de actividad de
salida con flechas de entrada. Hay un nodo de parámetro de actividad por
parámetro, donde ambos son del mismo tipo.

13.3 NODO CENTRAL DE ALMACENAMIENTO

Al igual que los pins, el nodo tampón (nodo tampón central) se aplica
directamente en el diagrama de actividades. Este nodo de objeto almacena
los valores en cualquier punto del diagrama. Sin embargo, a diferencia de la
clavija o pin, no está vinculada a un nodo de actividad. El nodo de buffer
utiliza el flujo de objetos para conectar objetos entrantes y salientes con
otros nodos de objetos, por ejemplo, con un pin. Los nodos de búfer se
utilizan para almacenar en búfer los flujos entrantes y salientes de un objeto.
Por lo tanto, acepte todos los tokens de objetos entrantes y póngalos a
disposición en el flujo de objetos salientes. Se emite una nota para el objeto
en el otro extremo de la secuencia y el token se devuelve solo si se aceptan
los parámetros del objeto. En notación UML, este nodo consta de un
rectángulo simple. Sus características especiales quedan demostradas por
el modelo de "centralBuffer".
 13.4 NODOS DE ALMACENAMIENTO DE DATOS
Como los nodos de buffer, los nodos de almacenamiento de datos también
se instalan entre flujos de objetos sin ligarlos a una acción. Este subtipo del
nodo buffer tiene una característica especial: almacena una copia de cada
token enviado hasta que la actividad a la que está supeditada se completa.
Cada valor existe solo una vez en el nodo de almacenamiento de datos. Si el
nodo ya almacena un objeto token con una identidad fija, no acepta tokens
nuevos con exactamente las mismas propiedades. Como con todas las
notas de objeto, el nodo de almacenamiento de datos se representa como
un rectángulo. Para diferenciarlo, escribe el estereotipo “datastore” en la
cabecera.

14. NODOS DE CONTROL

Dentro de un diagrama de actividades UML, los tokens vagan por varias
acciones hasta que la actividad concluye cuando el primer token llega al
nodo final. Dado que este proceso puede incluir varios tokens al mismo
tiempo, se requiere un determinado orden. Los nodos de control sirven para
asegurar un flujo de proceso claro, gestionando exclusivamente los flujos de
control en su trayecto desde el principio del diagrama de actividades hasta
las acciones y el final de la actividad. Los nodos de control no pueden
almacenar tokens en caché, a diferencia de nodos de objeto como el nodo
de búfer.
Una diferencia significativa entre los flujos de objeto y de control es que solo
los tokens de control se mueven en los flujos de control. A diferencia de los
tokens de objeto, estos tokens no llevan ningún dato con ellos. Son meros
marcadores. Por lo tanto, las acciones no requieren que los nodos de objeto
(especialmente los pines) tomen y pasen las fichas de control. Un testigo de
control inicia una acción, se mueve al siguiente y luego lo pone en
movimiento. Por lo tanto, controla la ejecución cronológica de la actividad.

Entre los símbolos del diagrama de actividades UML, los nodos de control
son probablemente los más diversos. Pertenecen a los nodos de actividad.
UML 2 distingue seis tipos:

14.1 LOS NODOS DE INICIO (NODOS INICIALES)

Puede haber más de un nodo de inicio por operación. Si se inicia una

operación, el nodo de inicio pone en movimiento inmediatamente el flujo de
control. Si existen varios nodos de inicio, los respectivos flujos de control se
inician simultáneamente. Los nodos de operación estructurados también
pueden tener nodos de inicio. Estos también se inician inmediatamente al
iniciar la actividad estructurada, siempre y cuando no se hayan establecido
condiciones para su inicio. Puesto que los nodos iniciales están al principio,
todos los indicadores son flechas de actividad salientes. Estos son siempre
flujos de control. Otra característica especial de los nodos de inicio: las
fichas de control colocadas en el nodo de inicio al comienzo de una actividad
pueden permanecer allí si el flujo de control no acepta o bloquea la ficha
ofrecida.
14.2 LOS NODOS FINALES DETIENEN EL FLUJO DE UNA
ACTIVIDAD.
Hay dos tipos de nodos finales: el nodo final de la actividad termina toda la
actividad destruyendo todos los tokens dentro de la actividad cuando recibe
el primer token. Solo se conservan los testigos de objeto en la salida de los
nodos de parámetros de actividad.

Todas las acciones sincrónicas también se detienen con él. Las acciones
asíncronas se ejecutan hasta que se completan. Los nodos finales aceptan
todos los tokens entrantes. A diferencia del nodo de inicio, un nodo final solo
tiene flechas de actividad entrantes. Es posible más de un nodo final.

Si dibujas un diagrama de actividad con más de un nodo final, las acciones

pueden detenerse antes de que hayan servido a su propósito, porque una
ficha ya ha alcanzado el primer punto final. El nodo final de flujo detiene un
flujo de control y destruye todos los tokens entrantes. Esto no afecta a otros
movimientos de control. Por lo tanto, este nodo final es una alternativa
práctica si se modelan varios puntos finales en el diagrama de actividades.

14.3 NODOS DE PARALELIZACIÓN Y NODOS DE SINCRONIZACIÓN

(NODOS DE HORQUILLA Y NODOS DE UNIÓN)
Un nodo de paralelización divide una flecha de actividad entrante en varios
flujos de salida simultáneos. Solo puede entrar una flecha en el nodo de
paralelización. Si se trata de un flujo de control, todas las flechas de salida
son también flujos de control; el mismo principio se aplica a los flujos de
objetos. El nodo crea copias del token de entrada para todos los
movimientos de salida. Si se acepta un token en el destino del flujo de
salida, se borra del nodo fuente. Si otro objetivo no acepta su token, el nodo
de paralelización puede excepcionalmente retener el token hasta que sea
aceptado.

Los nodos de sincronización funcionan exactamente al revés. Varios bordes

entran, pero sólo uno de ellos puede salir. Si la totalidad de los bordes de
entrada consiste en flujos de control, también sale un flujo de control, y si
entre ellos hay solo un flujo de objeto, UML especifica el borde de salida
como flujo del objeto. Si también se reciben tokens de control, en este caso,
caducarán y sólo saldrán los tokens de objeto. Si dos objetos tienen la
misma identidad, el nodo los fusiona en un token. En general, los tokens solo
pueden salir si todos los bordes entrantes ofrecen uno (operación and). Esto
sucede bajo el principio first in first out (el que entra primero, sale el primero).
Si se asigna una especificación de valor al nodo de sincronización con
joinSpec, el nodo espera a los tokens que cumplen explícitamente estos
requisitos antes de emitir tokens.

14.4 LOS NODOS DE RAMIFICACIÓN Y LOS NODOS DE

CONEXIÓN (NODOS DE DECISIÓN Y NODOS DE FUSIÓN)
Un nodo de rama requiere al menos uno, pero no más de dos bordes
entrantes. UML llama a uno primary incoming edge (borde primario
entrante). A un segundo lo denomina flujo de entrada de decisiones
(decision input flow). El que los flujos salientes representen a flujos de objeto
o de control, depende del tipo de borde primario. La tarea del nodo es
entonces decidir entre los bordes salientes, que le ofrecen sus nodos
entrantes sin copiarlos. El token solo podrá tomar entonces un camino.
Un nodo de conexión agrupa varios movimientos entrantes en un único
movimiento saliente. A diferencia del nodo de sincronización, el nodo de
conexión no fusiona ningún token en uno nuevo ni sincroniza los tipos de
bordes entrantes. Por lo tanto, para un flujo de control de salida, todos los
bordes de entrada deben ser también flujos de control. Lo mismo se aplica a
los flujos de objetos. El nodo de conexión simplemente ofrece todos los
tokens recibidos para el borde de salida.