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 ESTE LAdeSEMANA 6 utilizarDOCUMENTO los contenidos paraCONTIENE fines comerciales ninguna clase.

1

ESTE DOCUMENTO CONTIENE LA SEMANA 6

2

Í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

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

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.

Asociación

Es el tipo de relación más básica que indica la invocación desde un actor o caso de uso a otra operación (caso de uso). Dicha relación se denota con una flecha simple.


8

Dependencia o Instanciación

Generalización

Es una forma muy particular de relación entre clases, en la cual una clase depende de otra, es decir, se instancia (se crea). 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 dependiendo de su estereotipo, que puede ser de uso (<>) o de herencia (<>).

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. <>. 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. <>. 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. Nota: Ver Imagen 1, ejemplo de diagrama de casos de u so.

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

Recommend Documents