06 Herramientas Modelamiento Uml

HERRAMIENTAS DE MODELAMIENTO UML
SEMANA 6
Diagramas en UML:
diagramas de comportamiento e interacción
Todos los derechos de autor son de la exclusiva propiedad de IACC o de los otorgantes de sus licencias. No está
permitido copiar, reproducir, reeditar, descargar, publicar, emitir, difundir, poner a disposición del público ni 1
ESTE
utilizarDOCUMENTO
los contenidos paraCONTIENE LAdeSEMANA
fines comerciales 6
ninguna clase.
2
ESTE DOCUMENTO CONTIENE LA SEMANA 6
ÍNDICE
INDICE DE IMÁGENES .......................................................................................................................... 4

DIAGRAMAS EN UML: DIAGRAMAS DE COMPORTAMIENTO E INTERACCIÓN ................................... 5
OBJETIVOS ESPECÍFICOS ...................................................................................................................... 5
INTRODUCCIÓN ................................................................................................................................... 5
1. DIAGRAMAS DE COMPORTAMIENTO ......................................................................................... 6
1.1.1. DEFINICIÓN...................................................................................................................... 6
1.1.2. ELEMENTOS ..................................................................................................................... 7
1.1.2.1. ACTOR.......................................................................................................................... 7
1.1.2.2. CASO DE USO............................................................................................................... 8
1.1.2.3. RELACIONES................................................................................................................. 8
1.1.2.4. ASOCIACIÓN ................................................................................................................ 9
1.1.2.5. DEPENDENCIA ............................................................................................................. 9
1.1.2.6. GENERALIZACIÓN ........................................................................................................ 9
1.1.2.7. PRE – CONDICIONES Y POST - CONDICIONES ............................................................ 10
1.1.2.8. INCLUSIONES Y EXTENSIONES ................................................................................... 10
1.1.2.9. NARRATIVA ................................................................................................................ 11
1.2. DIAGRAMA DE ACTIVIDAD ................................................................................................ 12
1.2.1. DEFINICIÓN.................................................................................................................... 12
1.2.2. ELEMENTOS ................................................................................................................... 13
1.2.2.1. ACTIVIDADES ............................................................................................................. 13
1.2.2.2. ACCIONES .................................................................................................................. 14
1.2.2.3. RESTRICCIONES ......................................................................................................... 14
1.2.2.4. FLUJO DE CONTROL ................................................................................................... 14
1.2.2.5. NODO INICIAL ............................................................................................................ 14
1.2.2.6. FLUJO DE OBJETOS .................................................................................................... 15
1.2.2.7. NODOS DE DECISIÓN Y COMBINACIÓN..................................................................... 15
1.2.2.8. NODOS DE BIFURCACIÓN Y UNIÓN ........................................................................... 15
1.2.2.9. REGIÓN DE EXPANSIÓN ............................................................................................. 16
1.2.2.10. GESTOR DE EXCEPCIÓN ............................................................................................. 16
1.2.2.11. REGIÓN DE ACITIVIDAD INTERRUMPIBLE ................................................................. 16
3
1.2.2.12. PARTICIÓN ................................................................................................................. 17
1.2.2.13. PARÁMETROS ............................................................................................................ 17
COMENTARIO FINAL.......................................................................................................................... 19
REFERENCIAS ..................................................................................................................................... 20
INDICE DE IMÁGENES
Imagen 1: Ejemplo de Diagrama de Casos de uso ............................................................................. 7

Imagen 2: Ejemplo de Diagrama de Casos de Uso ............................................................................ 11
Imagen 3: Ejemplo de Diagrama de Actividad .................................................................................. 13
Imagen 4: Ejemplo de Diagrama de Actividad .................................................................................. 18
4
DIAGRAMAS EN UML: DIAGRAMAS DE COMPORTAMIENTO E
INTERACCIÓN
OBJETIVOS ESPECÍFICOS
 Comprender elementos actor, caso de uso, actividades y acciones de los diagramas de
caso de uso y de actividad en UML.
 Elaborar diagramas de caso de uso y de actividad como parte de la fase de diseño de

software.
INTRODUCCIÓN
En los contenidos de esta semana se presentan los diagramas de caso de uso y los diagramas de
actividad, los cuales describen aspectos del funcionamiento del sistema, tanto en los estados que
se procesan durante la ejecución de este, como también se muestran las actividades de todo el
proceso.
En los diagramas de casos de uso se analiza el actor como uno de los componentes principales de
este tipo de diagramas, los casos de usos como los procesos que provocan el comportamiento y
las relaciones como las asociaciones entre los actores y los casos de uso o entre ellos mismos.
También se presentan otros elementos o subelementos que componen cada uno de los
componentes expuestos.
Además, se presenta el diagrama de actividad con cada uno de sus elementos, tales como:
actividad, acción, nodos que lo componen, momentos e instancias de ejecución, como también las
excepciones y las zonas que corresponden a la ejecución total del diagrama.
En ambos diagramas es importante conocer y entender los elementos que lo componen, ya que
con ellos se puede representar de mejor manera un sistema analizado.
5
1. DIAGRAMAS DE COMPORTAMIENTO
Los diagramas UML de comportamiento permiten visualizar, especificar, construir y documentar

los aspectos dinámicos de un sistema. Los diagramas de comportamiento se clasifican de la
siguiente manera: diagramas de casos, diagramas de interacción, diagramas de estado de gráficos
y diagramas de actividad.
 Una buena introducción para estos diagramas la puedes

obtener en la siguiente presentación, la cual explica los
diagramas de comportamiento y sus principales
características
https://goo.gl/8WHbww
El primer diagrama que se analiza son los diagramas de casos de uso.
1.1. DIAGRAMA DE CASOS DE USO

Los diagramas de casos de uso presentan una vista exterior de la forma de los elementos de un
sistema, cómo se comportan y cómo pueden ser utilizados en el contexto (W3ii, 2017).
Un caso de uso describe la secuencia de acciones que un sistema realiza produciendo resultados
visibles. Se muestra la interacción de las cosas fuera del sistema con el propio sistema. Los casos
de uso se pueden aplicar a todo el sistema, así como a una parte del sistema visible.
1.1.1. DEFINICIÓN
Una definición para este tipo de diagramas es la entregada por Salinas y Histchfeld (2010, Casos de
uso, párr. 1), quien plantea que “el diagrama de casos de uso representa la forma en como un
Cliente (Actor) opera con el sistema en desarrollo, además de la forma, tipo y orden en como los
elementos interactuan (operaciones o casos de uso)”.
Esta descripción da a entender por qué es un diagrama de comportamiento, ya que representa

cómo el sistema actúa en base a determinadas acciones gatilladas por el actor.
Un ejemplo de casos de uso es el siguiente:
6
Imagen 1. Ejemplo de diagrama de casos de uso
Fuente: https://goo.gl/iZ9mve
1.1.2. ELEMENTOS
Entre los principales elementos de un diagrama de este tipo se encuentran:
1.1.2.1. ACTOR
Un actor especifica un rol jugado por un usuario o cualquier otro sistema que interactúa con el
sujeto. Un actor puede ser una persona (por ejemplo, estudiante, atención al cliente), un
dispositivo (por ejemplo, estación de trabajo) u otro sistema (por ejemplo, banco, institución)
(W3ii, 2017).
7
Es importante destacar el uso de la palabra rol, pues con esto se especifica que un actor no
necesariamente representa a una persona en particular, sino más bien la labor que realiza frente
al sistema (Salinas y Histchfeld, 2010).
Ejemplo: cliente
Nota: Ver Imagen 1, ejemplo de diagrama de casos de uso.
1.1.2.2. CASO DE USO
Un caso de uso describe la secuencia de acciones que un sistema realiza produciendo resultados.
Es “una operación/tarea específica que se realiza tras una orden de algún agente externo, sea
desde una petición de un actor o bien desde la invocación desde otro caso de uso” (Salinas y
Histchfeld, 2010, Casos de uso, párr. 6).
Ejemplo: consultar producto
1.1.2.3. RELACIONES
Las relaciones representan los tipos de asociaciones de los casos actores con los casos de uso o
entre los mismos casos de uso.
Es el tipo de relación más básica que indica

la invocación desde un actor o caso de uso a
Asociación
otra operación (caso de uso). Dicha relación
se denota con una flecha simple.
8
Es una forma muy particular de relación
entre clases, en la cual una clase depende
Dependencia o
de otra, es decir, se instancia (se crea).
Instanciación
Dicha relación se denota con una flecha
punteada.
Este tipo de relación es uno de los más
utilizados, cumple una doble función
Generalización dependiendo de su estereotipo, que puede
ser de uso (<<uses>>) o de herencia
(<<extends>>).
1.1.2.4. ASOCIACIÓN
Respecto de las asociaciones se plantea que (Umbrello, 2012):
 Una asociación representa una relación entre clases, y proporciona la semántica y

estructura común para muchos tipos de “conexiones” entre objetos.
 Las asociaciones son el mecanismo que permite que los objetos se comuniquen entre sí.
Describe la conexión entre diferentes clases (la conexión entre objetos reales se denomina
“conexión de objetos” o enlace).
 Las asociaciones pueden tener un rol que indica el propósito de la asociación y pueden ser
unidireccionales o bidireccionales (indica si los dos objetos que participan en la relación
mensajes del uno al otro, o si solo uno de ellos tiene conocimiento del otro).
 Cada extremo de la asociación también posee un valor de multiplicidad, que dicta cuántos
objetos a dicho lado de la asociación pueden relacionarse con un objeto del otro lado.
En UML, las asociaciones se representan con líneas que conectan las clases que participan en la
relación, y que también pueden mostrar el rol y la multiplicidad de cada uno de los participantes.
La multiplicidad se muestra como un intervalo [mín..máx] de valores no negativos, con una estrella
(*) en el extremo máximo para representar el infinito.
1.1.2.5. DEPENDENCIA
Es una relación de uso entre dos clases (una usa a la otra). Esta relación es las más básicas entre
clases y, comparada con los demás tipos de relación, la más débil.
1.1.2.6. GENERALIZACIÓN
9
Una asociación de generalización entre dos clases las coloca en una jerarquía que representa el
concepto de herencia de una clase derivada a partir de una clase base. En UML, las
generalizaciones se representan con una línea que conecta las dos clases, con una flecha en el lado
de la clase base.
1.1.2.7. PRECONDICIONES Y POSCONDICIONES
Según lo planteado por Jummp (2011), las pre y poscondiciones son:
La precondición está formada por el conjunto de condiciones que se tienen que cumplir para que
se pueda iniciar un caso de uso. En muchos casos supone la ejecución de casos de uso previos.
La poscondición refleja el estado en que se queda el sistema una vez ejecutado el caso de uso.
En ambos casos lo que se representa es un estado y no la ejecución de una serie de acciones

(previas o posteriores al caso de usosimulado).
1.1.2.8. INCLUSIONES Y EXTENSIONES
Las inclusiones y extensiones tienen que ver con (IngSw, 2012):
 Inclusión
Una relación adicional entre casos de uso es la de inclusión, la cual apoya la reutilización de los
casos de uso. Mediante la relación de inclusión es necesario describir las partes similares una vez
en lugar de repetirlas para todos los casos de uso con comportamiento similar. Se conoce a los
casos de uso que se extraen como casos de uso abstractos, ya que no serán instanciados
independientemente, sirviendo solo para describir partes que son comunes a otros casos de uso.
Se conoce a los casos de uso que realmente serán instanciados como casos de uso concretos.
<<Include>>. En términos muy simples, cuando relacionamos dos casos de uso con un “include”,
estamos diciendo que el primero (el caso de uso base) incluye al segundo (el caso de uso incluido).
Es decir, el segundo es parte esencial del primero. Sin el segundo, el primero no podría funcionar
bien; pues no podría cumplir su objetivo.
<<extend>>. La polémica al querer seleccionar una de las dos relaciones es que en el “extend”
también se puede ver, desde la perspectiva del usuario, a los dos flujos como si fueran uno solo. Y
en ciertos escenarios el caso de uso base no podría cumplir su objetivo si no se ejecutara la
extensión. Pero una de las diferencias básicas es que en el caso del “extend” hay situaciones en
que el caso de uso de extensión no es indispensable que ocurra, y cuando lo hace ofrece un valor
10
extra (extiende) al objetivo original del caso de uso base. En cambio, en el “include” es necesario
que ocurra el caso incluido tan solo para satisfacer el objetivo del caso de uso base.
1.1.2.9. NARRATIVA
El caso de uso se puede ver como un documento narrativo que describe la secuencia de eventos
de un actor que utiliza un sistema para completar un proceso. Los casos de uso son historias o
casos de utilización de un sistema; no son exactamente los requerimientos ni las especificaciones
funcionales, sino que ejemplifican e incluyen los requerimientos en las historias que narran.
Imagen 2. Ejemplo de diagrama de casos de uso

Fuente: https://goo.gl/NKAeDe
En este diagrama se muestra el comportamiento de un usuario con el sistema, donde el actor

ingresa al sistema que da un conjunto de opciones a ejecutar en un cajero bancario: cambio de
NIP, solicitud de saldo, retiro de efectivo, pago de servicio. Dependiendo de la acción que ejecute,
el usuario ejecuta una serie de pasos para cumplir con el proceso solicitado.
11
1.2.DIAGRAMA DE ACTIVIDAD
Según lo planteado por Microsoft (2014), un diagrama de actividades muestra un proceso de

negocio o un proceso de software como un flujo de trabajo a través de una serie de acciones. Las
personas, los componentes de software o los equipos pueden realizar estas acciones.
 Para conocer más sobre los diagramas de actividad y de la

forma de utilizar UML, revisa este video que explica este
tipo de diagrama, sus componentes y la forma de crearlo en
Star UML.
https://youtu.be/tmg_xqrmUYo
1.2.1. DEFINICIÓN
Los diagramas de actividades describen la secuencia de actividades de un sistema con la ayuda de

actividades. Son una forma especial de los diagramas de estados que solo (o principalmente)
contienen actividades (Umbrello, 2012).
12
Imagen 3. Ejemplo de diagrama de actividad
Fuente: https://goo.gl/vwgsn9
1.2.2. ELEMENTOS
Los principales elementos de un diagrama de actividad son los que se plantean a continuación:
1.2.2.1. ACTIVIDADES
Una actividad es un paso único de un proceso, un estado de un sistema con actividad interna y, al
menos, una transición de salida. Las actividades también pueden tener más de una transición de
salida si poseen distintas condiciones.
Las actividades pueden formar jerarquías, lo que significa que una actividad se puede componer
de varias actividades “detalladas”, en cuyo caso las transiciones de entrada y de salida deben
corresponderse con las transiciones de entrada y de salida del diagrama detallado.
13
Un ejemplo de actividad es la expuesta en la imagen anterior:
1.2.2.2. ACCIONES
Una acción representa un solo paso dentro de una actividad. Las acciones se denotan por
rectángulos con las puntas redondeadas
1.2.2.3. RESTRICCIONES
Las restricciones se pueden adjuntar a una acción.
1.2.2.4. FLUJO DE CONTROL
Un flujo de control muestra el paso de una acción a otra. Su notación es una línea con una punta
de flecha.
1.2.2.5. NODO INICIAL
14
Un nodo inicial o de comienzo se describe por un gran punto negro, como se muestra a
continuación.
1.2.2.6. FLUJO DE OBJETOS
Un flujo de objeto es la ruta a lo largo de la cual pueden pasar objetos o datos. Un objeto se
muestra como un rectángulo.
Un flujo de objeto se muestra como un conector con una punta de flecha denotando la dirección a
la cual se está pasando el objeto.
Un flujo de objeto debe tener un objeto en por lo menos uno de sus extremos.
1.2.2.7. NODOS DE DECISIÓN Y COMBINACIÓN
Los nodos de decisión y combinación tienen la misma notación: una forma de diamante. Los dos se
pueden nombrar. Los flujos de control que provienen de un nodo de decisión tendrán condiciones
que permitirán al control para fluir si alguna condición se cumple.
1.2.2.8. NODOS DE BIFURCACIÓN Y UNIÓN
Las bifurcaciones y uniones tienen la misma notación: tanto una barra horizontal como vertical; la
orientación depende de si el flujo de control va de derecha a izquierda o hacia abajo y arriba. Estos
indican el comienzo y final de hilos actuales de control.
15
Una unión es diferente de una combinación ya que la unión sincroniza dos flujos de entrada y
produce un solo flujo de salida. El flujo de salida desde una unión no se puede ejecutar hasta que
todos los flujos se hayan recibido. Una combinación pasa cualquier flujo de control directamente a
través de esta. Si dos o más flujos de entrada se reciben por un símbolo de combinación, la acción
a la que el flujo de salida apunta se ejecuta dos o más veces.
1.2.2.9. REGIÓN DE EXPANSIÓN
Corresponde a una actividad estructurada que se ejecuta muchas veces. Los nodos de expansión
de salida y entrada se dibujan como un grupo de tres casillas representando una selección múltiple
de ítems. La clave reiterativa, paralelo, o flujo se muestra en la esquina izquierda arriba de la
región.
Imagen 4: región de expansión

Fuente: https://goo.gl/60aat6
1.2.2.10. GESTOR DE EXCEPCIÓN
Cuando se determina que hay una excepción, provoca que se puedan ejecutar esas acciones
asociadas a la excepción.
Imagen 5: Gestor de excepción

Fuente: https://goo.gl/60aat6
1.2.2.11. REGIÓN DE ACITIVIDAD INTERRUMPIBLE
Una región de actividad interrumpible rodea un grupo de acciones que se pueden interrumpir.
16
Imagen 6. Ejemplo región de actividad interrumpible
Fuente: https://goo.gl/hZxeeg
1.2.2.12. PARTICIÓN
Una partición de una actividad se muestra como calles horizontales o verticales. En el siguiente
diagrama, las particiones se usan para separar acciones dentro de una actividad en aquellas
realizadas por el departamento de contabilidad y aquellas realizadas por el cliente.
Imagen 7. Ejemplo partición

Fuente: https://goo.gl/qREXZu
1.2.2.13. PARÁMETROS
Los parámetros son aquellos que se traspasan entre una actividad y otra a través de un flujo. Cada
parámetro es relevante para la actividad que lo recibe, ya que permite ejecutar los procesos de
esta, como también es importante su salida, ya que lleva los resultados de la actividad que lo
genera o modifica.
17
Imagen 8. Ejemplo de diagrama de actividad
Fuente: https://goo.gl/el6sTM
En este simple ejemplo se muestra el diagrama de actividad del control remoto de un televisor,
donde el oprimir una tecla genera un cambio de canal y, si el usuario considera que quiere ver ese
canal, se llega al fin de la actividad, y si decide cambiar de se muestra un nuevo canal a través de la
televisión, que sería el dispositivo de salida.
18
COMENTARIO FINAL
Los diagramas de casos de uso y actividad permiten tener una visión de las acciones que se
ejecutan en el sistema como también de las reacciones que provocan estas acciones. Siempre es
recomendable tener distintas miradas respecto de un sistema, en este caso los actores provocan
actos que hacen que el sistema reaccione y ejecute una serie de procesos, como también acciones
que gatillan el actuar de otros procesos.
En el diagrama de actividad se muestran las actividades que realiza el sistema como un flujo, el
cual puede contar con bifurcaciones, decisiones y elementos de control que permiten mostrar la
realidad del sistema diagramado.
Siempre es importante para la creación de cada diagrama un buen análisis en la organización que
se ejecuta el sistema y no necesariamente el sistema debe ser una aplicación ya automatizada,
porque pueden ser acciones manuales que se desean automatizar.
 Los diagramas expuestos son aquellos que nos permiten ver

los casos donde se usan los procesos gatillados por los
actores u otros procesos.
 En un diagrama de actividad se muestran las actividades que
realiza el sistema ya sea en forma de secuencia o paralela,
dependiendo de las características de este.
19
REFERENCIAS
IngSw (2012). Modelo de casos de Uso. Recuperado de: http://bit.ly/2nYM4HL
Jummp (2011). Las precondiciones y postcondiciones en los casos de uso. Recuperado de:
https://goo.gl/XAmNID .
Microsoft (2014). Diagrama de componentes de UML: referencia. Recuperado de:
https://goo.gl/9Py5Zv
Salinas, P. y Histchfeld, N. (2010). Tutorial de UML. Recuperado de: https://goo.gl/5JH9R
Umbrello (2012). Capítulo 2. Las bases de UML. Recuperado de: https://goo.gl/4ibWrV
W3ii (2017). Los diagramas de comportamiento UML. Recuperado de: https://goo.gl/KViJ57
PARA REFERENCIAR ESTE DOCUMENTO, CONSIDERE:
IACC (2017). Diagramas en UML: diagramas de comportamiento e interacción. Herramientas de
Modelamiento UML. Semana 6.
20
21

06 Herramientas Modelamiento Uml

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

06 Herramientas Modelamiento Uml

Uploaded by

Copyright:

Available Formats

HERRAMIENTAS DE MODELAMIENTO UML

INDICE DE IMÁGENES .......................................................................................................................... 4

Imagen 1: Ejemplo de Diagrama de Casos de uso ............................................................................. 7

 Elaborar diagramas de caso de uso y de actividad como parte de la fase de diseño de

Los diagramas UML de comportamiento permiten visualizar, especificar, construir y documentar

 Una buena introducción para estos diagramas la puedes

El primer diagrama que se analiza son los diagramas de casos de uso.

1.1. DIAGRAMA DE CASOS DE USO

Esta descripción da a entender por qué es un diagrama de comportamiento, ya que representa

Un ejemplo de casos de uso es el siguiente:

Entre los principales elementos de un diagrama de este tipo se encuentran:

Nota: Ver Imagen 1, ejemplo de diagrama de casos de uso.

1.1.2.2. CASO DE USO

Ejemplo: consultar producto

Nota: Ver Imagen 1, ejemplo de diagrama de casos de uso.

Es el tipo de relación más básica que indica

Respecto de las asociaciones se plantea que (Umbrello, 2012):

 Una asociación representa una relación entre clases, y proporciona la semántica y

1.1.2.7. PRECONDICIONES Y POSCONDICIONES

Según lo planteado por Jummp (2011), las pre y poscondiciones son:

En ambos casos lo que se representa es un estado y no la ejecución de una serie de acciones

1.1.2.8. INCLUSIONES Y EXTENSIONES

Las inclusiones y extensiones tienen que ver con (IngSw, 2012):

Nota: Ver Imagen 1, ejemplo de diagrama de casos de uso.

Imagen 2. Ejemplo de diagrama de casos de uso

En este diagrama se muestra el comportamiento de un usuario con el sistema, donde el actor

Según lo planteado por Microsoft (2014), un diagrama de actividades muestra un proceso de

 Para conocer más sobre los diagramas de actividad y de la

Los diagramas de actividades describen la secuencia de actividades de un sistema con la ayuda de

Las restricciones se pueden adjuntar a una acción.

1.2.2.4. FLUJO DE CONTROL

1.2.2.5. NODO INICIAL

1.2.2.6. FLUJO DE OBJETOS

1.2.2.7. NODOS DE DECISIÓN Y COMBINACIÓN

1.2.2.8. NODOS DE BIFURCACIÓN Y UNIÓN

1.2.2.9. REGIÓN DE EXPANSIÓN

Imagen 4: región de expansión

1.2.2.10. GESTOR DE EXCEPCIÓN

Imagen 5: Gestor de excepción

1.2.2.11. REGIÓN DE ACITIVIDAD INTERRUMPIBLE

Imagen 7. Ejemplo partición

 Los diagramas expuestos son aquellos que nos permiten ver

Microsoft (2014). Diagrama de componentes de UML: referencia. Recuperado de:

Salinas, P. y Histchfeld, N. (2010). Tutorial de UML. Recuperado de: https://goo.gl/5JH9R

Umbrello (2012). Capítulo 2. Las bases de UML. Recuperado de: https://goo.gl/4ibWrV

W3ii (2017). Los diagramas de comportamiento UML. Recuperado de: https://goo.gl/KViJ57

PARA REFERENCIAR ESTE DOCUMENTO, CONSIDERE:

IACC (2017). Diagramas en UML: diagramas de comportamiento e interacción. Herramientas de

Modelamiento UML. Semana 6.

You might also like