DAM ED06 PDFContenidos 2015
DAM ED06 PDFContenidos 2015
DAM ED06 PDFContenidos 2015
Caso práctico
Ada decide que no pueden parar ahora, y que hay que hacer un esfuerzo final para que los
conocimientos del equipo sean globales y puedan enfrentarse a cualquier desarrollo software con
solvencia.
1 de 44 25/08/15 16:30
Diseño orientado a objetos. Elaboración de diagramas de compo... http://127.0.0.1:51235/temp_print_dirs/eXeTempPrintDir_r_Z...
Caso práctico
En el tema anterior vimos cómo crear un diagrama de clases para un problema determinado, ésto nos ayuda a ver
el problema con otra perspectiva y descubrir información nueva, sin embargo no tiene en cuenta elementos como
la creación y destrucción de objetos, el paso de mensajes entre ellos y el orden en que deben hacerse, qué
funcionalidad espera un usuario poder realizar, o cómo influyen elementos externos en nuestro sistema. Un
diagrama de clases nos da información estática pero no dice nada acerca del comportamiento dinámico de los
objetos que lo forman, para incluir éste tipo de información utilizamos los diagramas de comportamiento que
incluyen:
Diagramas de secuencia.
Diagramas de comunicación.
Diagramas de interacción.
Diagramas de tiempo.
Introducción a UML.
2 de 44 25/08/15 16:30
Diseño orientado a objetos. Elaboración de diagramas de compo... http://127.0.0.1:51235/temp_print_dirs/eXeTempPrintDir_r_Z...
Caso práctico
-No, una descripción textual puede inducir a errores de interpretación y suele dejar cabos sueltos, y
no contempla otra información, como quién realiza las acciones que describimos, por ejemplo.
Necesitamos algo más específico.
Los diagramas de casos de uso son un elemento fundamental del análisis de un sistema desde la perspectiva de
la orientación a objetos porque resuelven uno de los principales problemas en los que se ve envuelto el proceso
de producción de software: la falta de comunicación entre el equipo de desarrollo y el equipo que necesita de una
solución software. Un diagrama de casos de uso nos ayuda a determinar QUÉ puede hacer cada tipo diferente de
usuario con el sistema, en una forma que los no versados en el mundo de la informática o, más concretamente el
desarrollo de software, pueda entender.
Los diagramas de casos de uso documentan el comportamiento de un sistema desde el punto de vista
del usuario. Por lo tanto, los casos de uso determinan los requisitos funcionales del sistema, es
decir, representan las funciones que un sistema puede ejecutar.
Un diagrama de casos de uso es una visualización gráfica de los requisitos funcionales del sistema, que está
formado por casos de uso (se representan como elipses) y los actores que interactúan con ellos (se representan
como monigotes). Su principal función es dirigir el proceso de creación del software, definiendo qué se espera de
él, y su ventaja principal es la facilidad para interpretarlos, lo que hace que sean especialmente útiles en la
comunicación con el cliente.
Reflexiona
Los diagramas de casos de uso se crean en las primeras etapas de desarrollo del software y se
enmarcan en el proceso de análisis, para definir, de forma detallada, la funcionalidad que se espera
cumpla el software y que, además, se pueda comunicar fácilmente al usuario pero ¿termina aquí su
función?
3 de 44 25/08/15 16:30
Diseño orientado a objetos. Elaboración de diagramas de compo... http://127.0.0.1:51235/temp_print_dirs/eXeTempPrintDir_r_Z...
2.1.- Actores.
Caso práctico
Los actores representan un tipo de usuario del sistema. Se entiende como usuario cualquier cosa
externa que interactúa con el sistema. No tiene por qué ser un ser humano, puede ser otro sistema
informático o unidades organizativas o empresas.
Siempre hay que intentar independizar los actores de la forma en que se interactúa con el sistema. Por ejemplo,
un usuario del sistema puede interpretar diferentes roles según la operación que esté ejecutando, cada uno de
estos roles representará un actor diferente, es decir, un actor en un diagrama de casos de uso representa un rol
que alguien puede estar jugando, no un individuo particular por lo tanto puede haber personas particulares que
puedan estar usando el sistema de formas diferentes en diferentes ocasiones. Suele ser útil mantener una lista de
los usuarios reales para cada actor.
Tipos de actores:
Primarios: interaccionan con el sistema para explotar su funcionalidad. Trabajan directa y frecuentemente
con el software.
Secundarios: soporte del sistema para que los primarios puedan trabajar. Son precisos para alcanzar algún
objetivo.
Iniciadores: no interactúan con el sistema pero desencadenan el trabajo de otro actor.
Es posible que haya casos de uso que no sean iniciados por ningún usuario, o algún otro elemento software, en
ese caso se puede crear un actor "Tiempo" o "Sistema".
Autoevaluación
4 de 44 25/08/15 16:30
Diseño orientado a objetos. Elaboración de diagramas de compo... http://127.0.0.1:51235/temp_print_dirs/eXeTempPrintDir_r_Z...
¿Un sistema software externo, como una entidad para la autentificación de claves, podría
considerarse como un actor en un diagrama de casos de uso?
Verdadero.
Falso.
5 de 44 25/08/15 16:30
Diseño orientado a objetos. Elaboración de diagramas de compo... http://127.0.0.1:51235/temp_print_dirs/eXeTempPrintDir_r_Z...
Caso práctico
Se utilizan casos de uso para especificar tareas que deben poder llevarse a cabo con el apoyo del sistema que se
está desarrollando.
Un caso de uso especifica una secuencia de acciones, incluyendo variantes, que el sistema puede
llevar a cabo, y que producen un resultado observable de valor para un actor concreto. El conjunto de
casos de uso forma el "comportamiento requerido" de un sistema.
El objetivo principal de elaborar un diagrama de casos de uso no es crear el diagrama en sí, sino la descripción
que de cada caso se debe realizar, ya que esto es lo que ayuda al equipo de desarrollo a crear el sistema a
posteriori. Para hacer ésto utilizamos, sobre todo otros diagramas que permiten describir la dinámica del caso de
uso, como el diagrama de secuencia que veremos después, y una descripción textual, en la que se deben incluir,
al menos, los siguientes datos (a los que se denomina contrato):
Actores: aquellos que interactúan con el sistema a través del caso de uso.
Precondiciones: aquellas que deben cumplirse para que pueda llevarse a cabo el caso de uso.
Flujo normal: flujo normal de eventos que deben cumplirse para ejecutar el caso de uso exitosamente,
desde el punto de vista del actor que participa y del sistema.
Flujo alternativo: flujo de eventos que se llevan a cabo cuando se producen casos inesperados o poco
frecuentes. No se deben incluir aquí errores como escribir un tipo de dato incorrecto o la omisión de un
parámetro necesario.
Postcondiciones: las que se cumplen una vez que se ha realizado el caso de uso.
La representación gráfica de un caso de uso se realiza mediante un óvalo o elipse, y su descripción se suele hacer
rellenando una o más tablas como la de la imagen (obtenida de la herramienta Visual Paradigm).
6 de 44 25/08/15 16:30
Diseño orientado a objetos. Elaboración de diagramas de compo... http://127.0.0.1:51235/temp_print_dirs/eXeTempPrintDir_r_Z...
Autoevaluación
"Tras comprobar todos los artículos el pedido queda en el almacén a la espera de ser
recogido."
7 de 44 25/08/15 16:30
Diseño orientado a objetos. Elaboración de diagramas de compo... http://127.0.0.1:51235/temp_print_dirs/eXeTempPrintDir_r_Z...
2.3.- Relaciones.
Caso práctico
-De acuerdo, y ahora ¿cómo asociamos a los actores con los casos
de uso que pueden realizar?
Los diagramas de casos de uso son grafos no conexos en los que los nodos son actores y casos de uso, y las
aristas son las relaciones que existen entre ellos. Representan qué actores realizan las tareas descritas en los
casos de uso, en concreto qué actores inician un caso de uso. Pero además existen otros tipos de relaciones que
se utilizan para especificar relaciones más complejas, como uso o herencia entre casos de uso o actores.
Inclusión: se utiliza cuando queremos dividir una tarea de mayor envergadura en otras más sencillas, que
son utilizadas por la primera. Representa una relación de uso, y son muy útiles cuando es necesario
reutilizar tareas.
Extensión: se utiliza para representar relaciones entre un caso de uso que requiere la ejecución de otro en
determinadas circunstancias.
Generalización: se utiliza para representar relaciones de herencia entre casos de uso o actores.
8 de 44 25/08/15 16:30
Diseño orientado a objetos. Elaboración de diagramas de compo... http://127.0.0.1:51235/temp_print_dirs/eXeTempPrintDir_r_Z...
Una asociación se representa mediante un linea continua que une un actor con un caso de uso. Por ejemplo, un
usuario de un sistema de venta por Internet puede hacer un pedido, lo que se representa del siguiente modo:
9 de 44 25/08/15 16:30
Diseño orientado a objetos. Elaboración de diagramas de compo... http://127.0.0.1:51235/temp_print_dirs/eXeTempPrintDir_r_Z...
2.3.2.- Generalización.
Es posible que, igual que con los diagramas de clases, existan casos de uso que tengan comportamientos
semejantes a otros que los modifican o completan de alguna manera. El caso base se define de forma abstracta y
los hijos heredan sus características añadiendo sus propios pasos o modificando alguno. Normalmente la herencia
se utiliza menos en diagramas de casos de uso que en diagramas de clases.
Por ejemplo, el usuario del sistema de venta por Internet puede a su vez darse de alta en la página web para que
tengan sus datos registrados a la hora de hacer el pedido, en este caso el usuario es la generalización del socio.
Ambos actores pueden hacer un pedido, pero solo el socio puede modificar sus datos en el sistema.
10 de 44 25/08/15 16:30
Diseño orientado a objetos. Elaboración de diagramas de compo... http://127.0.0.1:51235/temp_print_dirs/eXeTempPrintDir_r_Z...
2.3.3.- Extensión.
Se utiliza una relación entre dos casos de uso de tipo "extends" cuando se desea especificar que el
comportamiento de un caso de uso es diferente dependiendo de ciertas circunstancias.
La principal función de esta relación es simplificar el flujo de casos de uso complejos. Se utiliza cuando existe una
parte del caso de uso que se ejecuta sólo en determinadas ocasiones, pero no es imprescindible para su
completa ejecución. Cuando un caso de uso extendido se ejecuta, se indica en la especificación del caso de uso
como un punto de extensión. Los puntos de extensión se pueden mostrar en el diagrama de casos de uso.
Por ejemplo, cuando un usuario hace un pedido si no es socio se le ofrece la posibilidad de darse de alta en el
sistema en ese momento, pero puede realizar el pedido aunque no lo sea.
11 de 44 25/08/15 16:30
Diseño orientado a objetos. Elaboración de diagramas de compo... http://127.0.0.1:51235/temp_print_dirs/eXeTempPrintDir_r_Z...
2.3.4.- Inclusión.
Se incluye una relación entre dos casos de uso de tipo "include" cuando la ejecución del caso de uso
incluido se da en la rutina normal del caso que lo incluye.
Las descripciones de los casos de uso son más cortas y se entienden mejor.
La identificación de funcionalidad común puede ayudar a descubrir el posible uso de componentes ya
existentes en la implementación.
La inclusión de estas relaciones hace que los diagramas sean más difíciles de leer, sobre todo para los
clientes.
Cuando usamos relaciones de inclusión o extensión no podemos olvidar que los casos de uso
extendidos o incluidos deben cumplir con las características propias de un caso de uso, es decir,
deben representar un flujo de actividad completo desde el punto de vista de lo que un actor espera
que el sistema haga por él, así como no utilizar estas herramientas sólo para descomponer un caso de
uso de envergadura en otros más pequeños, piedra angular del diseño estructurado y no del orientado
a objetos.
Fuente: Youtube
12 de 44 25/08/15 16:30
Diseño orientado a objetos. Elaboración de diagramas de compo... http://127.0.0.1:51235/temp_print_dirs/eXeTempPrintDir_r_Z...
Autoevaluación
Asociación.
Generalización.
extends.
Include.
13 de 44 25/08/15 16:30
Diseño orientado a objetos. Elaboración de diagramas de compo... http://127.0.0.1:51235/temp_print_dirs/eXeTempPrintDir_r_Z...
Caso práctico
Sea cual sea el tipo de diagrama que estemos creando, cuando lo hacemos realizamos un proceso de abstracción
por el cual representamos elementos de la realidad esquemáticamente, y en el diagrama de casos de uso pasa
igual, necesitamos abstraer la realidad en un dibujo, en el que representamos qué cosas pueden hacerse en
nuestro sistema y quién las va a hacer. Necesitamos diagramas que incluyan suficiente información para que el
equipo de desarrollo tome las decisiones más adecuadas en la fase de análisis y diseño con el fin de desarrollar
un software que cumpla con los requerimientos, así como que sean útiles en la fase de implementación en un
lenguaje orientado a objetos.
Partiremos de una descripción lo más detallada posible del problema a resolver y trataremos de detectar quién
interactúa con el sistema, para obtener los actores diagrama de casos de uso, a continuación buscaremos qué
tareas realizan estos actores para determinar los casos de uso más genéricos. El siguiente paso es refinar el
diagrama analizando los casos de uso más generales para detectar casos relacionados por inclusión (se detectan
fácilmente cuando aparecen en dos o más casos de uso generales), extensión y generalización. Al diagrama
generado se le denomina diagrama frontera.
Se conoce como diagrama frontera al diagrama de casos de uso que incluye todos los casos de uso
genéricos del sistema, que podrán ser desglosados después en nuevos diagramas de casos de uso
que los describan si es necesario. Se especifica enmarcando los casos de uso en un recuadro, que
deja a los actores fuera.
Debes conocer
La elaboración de casos de uso no es un proceso inmediato, en la siguiente presentación tienes la
descripción de cómo elaborar el diagrama de casos de uso del sistema con el que estamos
trabajando. También tienes un enlace a la descripción del sistema que queremos modelar.
Revísalo con cuidado para comprender los conceptos que acabamos de ver.
14 de 44 25/08/15 16:30
Diseño orientado a objetos. Elaboración de diagramas de compo... http://127.0.0.1:51235/temp_print_dirs/eXeTempPrintDir_r_Z...
15 de 44 25/08/15 16:30
Diseño orientado a objetos. Elaboración de diagramas de compo... http://127.0.0.1:51235/temp_print_dirs/eXeTempPrintDir_r_Z...
2.5.- Escenarios.
Caso práctico
Un caso de uso debe especificar un comportamiento deseado, pero no imponer cómo se llevará a cabo ese
comportamiento, es decir, debe decir QUÉ pero no CÓMO. Esto se realiza utilizando escenarios que son casos
particulares de un caso de uso.
Un escenario es una ejecución particular de un caso de uso que se describe como una secuencia de
eventos. Un caso de uso es una generalización de un escenario.
Por ejemplo, para el caso de uso hacer pedido podemos establecer diferentes escenarios:
16 de 44 25/08/15 16:30
Diseño orientado a objetos. Elaboración de diagramas de compo... http://127.0.0.1:51235/temp_print_dirs/eXeTempPrintDir_r_Z...
Caso práctico
Los diagramas de secuencia se utilizan para formalizar la descripción de un escenario o conjunto de ellos
representando que mensajes fluyen en el sistema así como quién los envía y quién los recibe.
Los objetos y actores que forman parte del escenario se representan mediante rectángulos distribuidos
horizontalmente en la zona superior del diagrama, a los que se asocia una linea temporal vertical (una por cada
actor) de las que salen, en orden, los diferentes mensajes que se pasan entre ellos. Con ésto, el equipo de
desarrollo puede hacerse una idea de las diferentes operaciones que deben ocurrir al ejecutarse una determinada
tarea y el orden en que deben realizarse.
Reflexiona
Los diagramas de secuencia completan a los diagramas de casos de uso, ya que permiten al equipo
de desarrollo hacerse una idea de qué objetos participan en el caso de uso y cómo interaccionan a
lo largo del tiempo.
17 de 44 25/08/15 16:30
Diseño orientado a objetos. Elaboración de diagramas de compo... http://127.0.0.1:51235/temp_print_dirs/eXeTempPrintDir_r_Z...
Caso práctico
En un diagrama de secuencia se dibujan las entidades que participan dentro de rectángulos que se distribuyen
horizontalmente. De cada rectángulo o entidad sale una línea de puntos que representa el paso del tiempo, se les
denomina línea de vida y representan que el objeto existe.
Para formar el nombre de una linea de vida de un objeto se usa el nombre del objeto, que es opcional, seguido del
símbolo dos puntos y a continuación el nombre de la clase a la que pertenece.
Una línea de vida puede estar encabezada por otro tipo de instancias como el sistema o un actor que
aparecerán aparecen con su propio nombre. Usaremos el sistema para representar solicitudes al
mismo como, por ejemplo, pulsar un botón para abrir una ventana o una llamada a una subrutina.
Cuando tenemos un objeto que puede tener varias instancias aparece como un rectángulo sobre otro, como en es
el caso de las lineas del pedido que pueden ser varias.
Invocación de métodos.
Los mensajes, que significan la invocación de métodos, se representan como flechas horizontales que van de una
linea de vida a otra, indicando con la flecha la dirección del mensaje. Los extremos de cada mensaje se conectan
con una línea de vida que conecta a las entidades al principio del diagrama. Los mensajes se dibujan desde el
objeto que envía el mensaje al que lo recibe, pudiendo ser ambos el mismo objeto y su orden viene determinado
por su posición vertical, un mensaje que se dibuja debajo de otro indica que se envía después, por lo que no se
hace necesario un número de secuencia.
Iteraciones y condicionales.
Además de presentar acciones sencillas que se ejecutan de manera secuencial también se pueden representar
algunas situaciones más complejas como bucles usando marcos, normalmente se nombra el marco con el tipo de
bucle a ejecutar y la condición de parada. También se pueden representar flujos de mensajes condicionales en
18 de 44 25/08/15 16:30
Diseño orientado a objetos. Elaboración de diagramas de compo... http://127.0.0.1:51235/temp_print_dirs/eXeTempPrintDir_r_Z...
Por último destacar que se puede completar el diagrama añadiendo etiquetas y notas en el margen izquierdo que
aclare la operación que se está realizando.
19 de 44 25/08/15 16:30
Diseño orientado a objetos. Elaboración de diagramas de compo... http://127.0.0.1:51235/temp_print_dirs/eXeTempPrintDir_r_Z...
Este es el diagrama ya terminado, en el se han incluido todas las entidades (actores, objetos y sistema) que
participan en el diagrama, y se han descrito todas las operaciones, incluidos los casos especiales, como es el
registro de usuarios o la gestión de los datos bancarios. También incluye el modelado de acciones en bucle, como
es la selección de artículos y de acciones regidas por condición, tal y como es, por ejemplo, la posibilidad de
cancelar el pedido si hay problemas con la tarjeta de crédito.
Debes conocer
En la siguiente presentación puedes encontrar una descripción de como elaborar este diagrama con
Visual Paradigm.
Autoevaluación
20 de 44 25/08/15 16:30
Diseño orientado a objetos. Elaboración de diagramas de compo... http://127.0.0.1:51235/temp_print_dirs/eXeTempPrintDir_r_Z...
Actor.
Objeto.
Bucle.
Evento.
21 de 44 25/08/15 16:30
Diseño orientado a objetos. Elaboración de diagramas de compo... http://127.0.0.1:51235/temp_print_dirs/eXeTempPrintDir_r_Z...
Caso práctico
Como, a diferencia de los diagramas de secuencia, no se incluye una línea temporal los mensajes son numerados
para determinar su orden el el tiempo.
En este diagrama de colaboración el actor Iniciador manda un mensaje al objeto c1 que inicia el escenario, a
continuación el objeto c1 envía el mensaje mensaje1 que lleva un parámetro al objeto c2 y después el mensaje
mensaje2, que no tiene parámetros de nuevo al objeto c2.
Reflexiona
Los diagramas de colaboración y secuencia utilizan los mismo elementos pero distribuyéndolos de
forma diferente, ¿crees que son semejantes?
22 de 44 25/08/15 16:30
Diseño orientado a objetos. Elaboración de diagramas de compo... http://127.0.0.1:51235/temp_print_dirs/eXeTempPrintDir_r_Z...
Caso práctico
Un objeto puede ser cualquier instancia de las clases que hay definidas en el sistema, aunque
también pueden incluirse objetos como la interfaz del sistema, o el propio sistema, si esto nos
ayuda a modelar las operaciones que se van a llevar a cabo.
Los objetos se representan mediante rectángulos en los que aparece uno de estos nombres.
:nombreClase: cuando se coloca el símbolo ":" delante del nombre de la clase quiere decir que hace
referencia a un objeto genérico de esa clase.
23 de 44 25/08/15 16:30
Diseño orientado a objetos. Elaboración de diagramas de compo... http://127.0.0.1:51235/temp_print_dirs/eXeTempPrintDir_r_Z...
Caso práctico
Para que sea posible el paso de mensajes es necesario que exista una asociación entre los objetos. En la imagen
es posible el paso de mensajes entre el objeto objeto1 y objeto2, además de quedar garantizada la navegación y
visibilidad entre ambos.
Un mensaje es la especificación de una comunicación entre objetos que transmite información y desencadena una
acción en el objeto destinatario. La sintaxis de un mensaje es la siguiente:
donde:
Secuencia: representa el nivel de anidamiento del envío del mensaje dentro de la interacción. Los mensajes
se numeran para indicar el orden en el que se envían, y si es necesario se puede indicar anidamiento
incluyendo subrangos.
Condición de guarda: debe cumplirse para que el mensaje pueda ser enviado.
ValorDevuelto: lista de valores devueltos por el mensaje. Estos valores se pueden utilizar como parámetros
de otros mensajes. Los corchetes indican que es opcional.
Como se ve en el ejemplo, se puede usar la misma asociación para enviar varios mensajes. Vemos que hay dos
mensajes anidados, el 1.1 y el 2.1, se ha usado el nombre de los mensajes para indicar el orden real en el que se
envían.
24 de 44 25/08/15 16:30
Diseño orientado a objetos. Elaboración de diagramas de compo... http://127.0.0.1:51235/temp_print_dirs/eXeTempPrintDir_r_Z...
Cuando tenemos una condición se repite el número de secuencia y se añaden las condiciones necesarias, como
vemos en la imagen según la condición se enviará el mensaje 1 o el 2, pero no ambos, por lo que coinciden en
número de secuencia.
La iteración se representa mediante un * al lado del número de secuencia, pudiendo indicarse ente corchetes la
condición de parada del bucle.
Nota: VP-UML modifica el orden en el que aparecen los datos pero no su notación.
25 de 44 25/08/15 16:30
Diseño orientado a objetos. Elaboración de diagramas de compo... http://127.0.0.1:51235/temp_print_dirs/eXeTempPrintDir_r_Z...
Las actividades que se repiten o pueden repetirse se marcan con un asterisco y su condición.
Las condiciones de guarda se escriben en el mismo nombre del mensaje.
El flujo alternativo de eventos según si el usuario cancela el pedido o no, obliga a modificar los números de
secuencia de los mensajes 5 y 6, pasando a tener los mensajes 5a y 6a y 5b y 6b, según la condición.
Puedes modificar el número se secuencia de los mensajes abriendo la especificación del diagrama, y
seleccionando la pestaña Mensajes, donde puedes editar los números de secuencia haciendo doble clic
sobre ellos.
Al objeto "sistema" se le ha asignado el estereotipo system.
Fuente: Youtube
Autoevaluación
Indica qué afirmación no es correcta para el siguiente
diagrama:
26 de 44 25/08/15 16:30
Diseño orientado a objetos. Elaboración de diagramas de compo... http://127.0.0.1:51235/temp_print_dirs/eXeTempPrintDir_r_Z...
27 de 44 25/08/15 16:30
Diseño orientado a objetos. Elaboración de diagramas de compo... http://127.0.0.1:51235/temp_print_dirs/eXeTempPrintDir_r_Z...
Caso práctico
El Diagrama de Actividad es una especialización del Diagrama de Estado, organizado respecto de las acciones,
que se compone de una serie de actividades y representa cómo se pasa de unas a otras. Las actividades se
enlazan por transiciones automáticas, es decir, cuando una actividad termina se desencadena el paso a la
siguiente actividad.
Se utilizan fundamentalmente para modelar el flujo de control entre actividades en el que se puede distinguir
cuales ocurren secuencialmente a lo largo del tiempo y cuales se pueden llevar a cabo concurrentemente.
Permite visualizar la dinámica del sistema desde otro punto de vista que complementa al resto de diagramas. En
concreto define la lógica de control:
En el modelado de los procesos del negocio: permiten especificar y evaluar el flujo de trabajo de los
procesos de negocio.
En el análisis de un caso de uso: permiten comprender qué acciones deben ocurrir y cuáles son las
dependencias de comportamiento.
En la comprensión del flujo de trabajo, a través de varios casos de uso: permiten representar con
claridad las relaciones de flujo de trabajo (workflow) entre varios casos de uso.
Un diagrama de actividades es un grafo conexo en el que los nodos son estados, que pueden ser de actividad o
de acción y los arcos son transiciones entre estados. El grafo parte de un nodo inicial que representa el estado
inicial y termina en un nodo final.
Reflexiona
¿Por qué decimos que el diagrama de actividades visualiza el comportamiento desde otro punto de
vista del resto de diagramas?
28 de 44 25/08/15 16:30
Diseño orientado a objetos. Elaboración de diagramas de compo... http://127.0.0.1:51235/temp_print_dirs/eXeTempPrintDir_r_Z...
Caso práctico
Estado de actividad: elemento compuesto cuyo flujo de control se compone de otros estados de
actividad y de acción.
Estado de acción: estado que representa la ejecución de una acción atómica, que no se puede
descomponer ni interrumpir, normalmente la invocación de una operación. Generalmente, se
considera que su ejecución conlleva un tiempo insignificante.
Pueden definirse también otro tipo de estados:
Inicial.
Final.
Transiciones: relación entre dos estados que indica que un objeto, en el primer estado, realizará ciertas
acciones y pasará al segundo estado cuando ocurra un evento específico y satisfaga ciertas condiciones.
Se representa mediante una línea dirigida del estado inicial al siguiente. Podemos encontrar diferentes tipos
de transacciones:
Secuencial o sin disparadores: al completar la acción del estado origen se ejecuta la acción de
salida y, sin ningún retraso, el control sigue por la transición y pasa al siguiente estado.
Bifurcación(Decision node): especifica caminos alternativos, elegidos según el valor de alguna
expresión booleana. Las condiciones de salida no deben solaparse y deben cubrir todas las
posibilidades (puede utilizarse la palabra clave else). Pueden utilizarse para lograr el efecto de las
iteraciones.
Fusión (Merge node): redirigen varios flujos de entrada en un único flujo de salida. No tiene tiempo
de espera ni sincronización.
División (Fork node): permiten expresar la sincronización o ejecución paralela de actividades. Las
actividades invocadas después de una división son concurrentes.
Unión (Join node): por definición, en la unión los flujos entrantes se sincronizan, es decir, cada uno
espera hasta que todos los flujos de entrada han alcanzado la unión.
Objetos: manifestación concreta de una abstracción o instancia de una clase. Cuando interviene un objeto
29 de 44 25/08/15 16:30
Diseño orientado a objetos. Elaboración de diagramas de compo... http://127.0.0.1:51235/temp_print_dirs/eXeTempPrintDir_r_Z...
no se utilizan los flujos de eventos habituales sino flujos de objetos (se representan con una flecha de igual
manera) que permiten mostrar los objetos que participan dentro del flujo de control asociado a un diagrama
de actividades. Junto a ello, se puede indicar cómo cambian los valores de sus atributos, su estado o sus
roles.
Se utilizan carriles o calles para ver QUIÉNES son los responsables de realizar las distintas actividades, es decir,
especifican qué parte de la organización es responsable de una actividad.
30 de 44 25/08/15 16:30
Diseño orientado a objetos. Elaboración de diagramas de compo... http://127.0.0.1:51235/temp_print_dirs/eXeTempPrintDir_r_Z...
En las bifurcaciones se ha añadido la condición que indica si se pasa a una acción o a otra.
Las acciones "Seleccionar artículo" y "Seleccionar cantidad" se han considerado concurrentes.
En este otro diagrama se simplifican las acciones a realizar y se eliminan los objetos para facilitar la inclusión de
calles que indican quien realiza cada acción:
Nota: para añadir las calles en Visual Paradigm se utiliza la herramienta del panel "Vertical Swimlane".
Autoevaluación
Los diagramas de actividades, a diferencia del resto, permiten incluir la concurrencia en la
representación del diagrama.
Verdadero.
Falso.
31 de 44 25/08/15 16:30
Diseño orientado a objetos. Elaboración de diagramas de compo... http://127.0.0.1:51235/temp_print_dirs/eXeTempPrintDir_r_Z...
Caso práctico
Ada espera que su equipo continúe con tan buen ánimo para estudiar un tipo
de diagrama más, que completará las diferentes visiones de la dinámica de
un sistema que proporciona UML. Son los diagramas de estados los que les
permitirán analizar cómo va cambiando el estado de los objetos que tienen
una situación variable a lo largo del tiempo.
Basado en los statecharts de David Harel. Representan máquinas de estados ( autómatas de estados finitos)
para modelar el comportamiento dinámico basado en la respuesta a determinados eventos de aquellos objetos
que requieran su especificación, normalmente por su comportamiento significativo en tiempo real y su
participación en varios casos de uso. El resto de objetos se dice que tienen un único estado.
Un objeto está en un estado concreto en un cierto momento, que viene determinado, parcialmente, por los
valores de sus atributos.
La transición de un estado a otro es momentánea y se produce cuando ocurre un determinado evento.
Una máquina de estados procesa un evento cada vez y termina con todas las consecuencias del evento
antes de procesar otro. Si ocurren dos eventos simultáneamente se procesan como si se hubieran
producido en cualquier orden, sin pérdida de generalidad.
Un diagrama de máquina de estados expresa el comportamiento de un objeto como una progresión a través de
una serie de estados, provocada por eventos y las acciones relacionadas que pueden ocurrir. Por ejemplo, aquí
tenemos el diagrama de estados de una puerta.
Autoevaluación
Analiza el diagrama de estados de la puerta, según está dibujado, ¿se puede abrir una puerta
que está cerrada con llave directamente?
Verdadero.
Falso.
32 de 44 25/08/15 16:30
Diseño orientado a objetos. Elaboración de diagramas de compo... http://127.0.0.1:51235/temp_print_dirs/eXeTempPrintDir_r_Z...
Caso práctico
Un estado es una situación en la vida de un objeto en la que satisface cierta condición, realiza alguna
actividad o espera algún evento.
Elementos de un estado
Nombre
Acciones entrada/salida.
Actividad a realizar.
Subestados, cuando el estado es complejo y necesita de un diagrama que lo defina.
Eventos diferidos.
Estado inicial: es un pseudoestado que indica el punto de partida por defecto para una transición cuyo
destino es el límite de un estado compuesto. El estado inicial del estado de nivel más alto representa la
creación de una nueva instancia de la clase.
Estado final: estado especial dentro de un estado compuesto que, cuando está activo, indica que la
ejecución del estado compuesto ha terminado y que una transición de finalización que sale del estado
compuesto está activada.
Un evento es un acontecimiento que ocupa un lugar en el tiempo y espacio que funciona como un
estímulo que dispara una transición en una máquina de estados. Existen eventos externos y eventos
internos según el agente que los produzca.
Tipos de eventos:
Señales (excepciones): la recepción de una señal, que es una entidad a la que se ha dado nombre
explícitamente (clase estereotipada), prevista para la comunicación explícita - y asíncrona- entre objetos. Es
enviada por un objeto a otro objeto o conjunto de objetos. Las señales con nombre que puede recibir un
objeto se modelan designándolas en un compartimento extra de la clase de ese objeto. Normalmente una
señal es manejada por la máquina de estados del objeto receptor y puede disparar una transición en la
máquina de estados.
Llamadas: la recepción de una petición para invocar una operación. Normalmente un evento de llamada es
modelado como una operación del objeto receptor, manejado por un método del receptor y se implementa
como una acción o transición de la máquina de estados.
Paso de tiempo: representa el paso del tiempo (ocurrencia de un tiempo absoluto respecto de un reloj real
o virtual o el paso de una cantidad de tiempo dada desde que un objeto entra en un estado). Palabra clave
after: after (2 segundos); after 1 ms desde la salida de devInactivo.
Cambio de estado: evento que representa un cambio en el estado o el cumplimiento de una condición.
33 de 44 25/08/15 16:30
Diseño orientado a objetos. Elaboración de diagramas de compo... http://127.0.0.1:51235/temp_print_dirs/eXeTempPrintDir_r_Z...
Palabra clave when, seguida de una expresión booleana, que puede ser de tiempo o de otra clase: when (hora
= 11:30); when ( altitud < 1000).
34 de 44 25/08/15 16:30
Diseño orientado a objetos. Elaboración de diagramas de compo... http://127.0.0.1:51235/temp_print_dirs/eXeTempPrintDir_r_Z...
6.2.- Transiciones.
Caso práctico
Estados origen y destino: la transición se disparará si, estando en el estado origen se produce el evento
de disparo y se cumple la condición de guarda (si la hay), pasando a ser activo el estado final.
Evento de disparo: cuando se produce un evento, afecta a todas las transiciones que lo contienen en su
etiqueta. Todas las apariciones de un evento en la misma máquina de estados deben tener la misma
signatura. Los tipos de evento los hemos visto en el punto anterior.
Acción: computación atómica ejecutable. Puede incluir llamadas a operaciones del objeto que incluye la
máquina de estados (o sobre otros visibles), creación o destrucción de objetos o el envío de una señal a
otro objeto.
Autoevaluación
35 de 44 25/08/15 16:30
Diseño orientado a objetos. Elaboración de diagramas de compo... http://127.0.0.1:51235/temp_print_dirs/eXeTempPrintDir_r_Z...
36 de 44 25/08/15 16:30
Diseño orientado a objetos. Elaboración de diagramas de compo... http://127.0.0.1:51235/temp_print_dirs/eXeTempPrintDir_r_Z...
Pendiente: está en este estado desde que se confirma el pedido hasta que se selecciona para preparar su
envío.
En almacén: está en este estado cuando es elaborado el paquete y se ha asignado a una ruta, hasta que
se envía a través de la ruta que le corresponde.
Servido: cuando el pedido es enviado. En este caso, se envía una señal física desde el almacén cuando el
transporte abandona el almacén.
Cancelado: puede llegarse a esta situación por dos motivos, o bien se cancela mientras se está haciendo
por problemas con la tarjeta de crédito, o bien porque, una vez pendiente de su gestión el usuario decide
cancelarlo, la diferencia fundamental entre ambos es que en el segundo caso hay que devolver el importe
pagado por el pedido al socio que lo ha comprado.
Las transiciones entre estados se producen por llamadas a procedimientos en todos los casos, no intervienen
cambios de estado o el tiempo, ni señales.
En las transiciones se ha incluido el nombre de la transición, al evento que la dispara (normalmente hacer clic en
algún botón de la interfaz), si existe condición de guarda se pone entre corchetes y la acción a realizar para llegar
al siguiente estado junto al símbolo /. En todos los casos el evento de disparo es de tipo llamada (incluye la
llamada a una función o pulsar un botón de la interfaz), salvo en el caso de pedido enviado que se controla por
una señal que se envía cuando el transporte abandona el almacén.
A los estados se les ha añadido la acción a realizar, apartado do/ y en algunos casos la acción de entrada, por
ejemplo en el caso del estado pendiente, se debe revisar que los artículos a enviar tengan disponibilidad y la de
salida, en el ejemplo disminuir el stock.
Nota: para incluir las condiciones de guarda en el diagrama debes rellenar el apartado "Guard" de la
especificación, si necesitas añadir alguna acción puedes hacerlo rellenando el apartado "Effect". Los eventos de
disparo.
En este enlace puedes acceder a una explicación sobre los ejemplos de diagramas de actividad y
los diagramas de estado.
37 de 44 25/08/15 16:30
Diseño orientado a objetos. Elaboración de diagramas de compo... http://127.0.0.1:51235/temp_print_dirs/eXeTempPrintDir_r_Z...
Los usuarios del sistema navegan por la web para ver los artículos, zapatos, bolsos y complementos que se
venden en la tienda. De los artículos nos interesa su nombre, descripción, material, color, precio y stock. De los
zapatos nos interesa su número y el tipo. De los bolsos nos interesa su tipo (bandolera, mochila, fiesta). De los
complementos (cinturones y guantes) su talla.
Los artículos se organizan por campañas para cada temporada (primavera/verano y otoño/invierno) de cada año.
Los artículos son de fabricación propia, pero, opcionalmente, pueden venderse artículos de otras firmas. De las
firmas nos interesa saber su nombre, CIF y domicilio fiscal. La venta de artículos de firma se realiza a través de
proveedores, de forma que un proveedor puede llevar varios artículos de diferentes firmas, y una firma puede ser
suministrada por más de un proveedor. Los artículos pertenecen a una firma solamente. De los proveedores
debemos conocer su nombre, CIF, y domicilio fiscal.
Los usuarios pueden registrarse en el sitio web para hacerse socios. Cuando un usuario se hace socio, debe
proporcionar los siguiente datos: nombre completo, correo electrónico y dirección.
Los socios pueden hacer pedidos de los artículos. Un pedido está formado por un conjunto de detalles de pedido
que son parejas formadas por artículo y la cantidad. De los pedidos interesa saber la fecha en la que se realizó y
cuanto debe pagar el socio en total. El pago se hace a través tarjeta bancaria, cuando se va a pagar una entidad
bancaria comprueba la validez de la tarjeta. De la tarjeta interesa conocer el número.
Las campañas son gestionadas por el administrativo de la tienda que se encargará de dar de baja la campaña
anterior y dar de alta la nueva siempre que no haya ningún pedido pendiente de cumplimentar.
Existe un empleado de almacén que revisa los pedidos a diario y los cumplimenta. Ésto consiste en recopilar los
artículos que aparecen en el pedido y empaquetarlos. Cuando el paquete está listo se pasa al almacén a la espera
de ser repartido. Del reparto se encarga una empresa de transportes que tiene varias rutas preestablecidas. Según
el destino del paquete (la dirección del socio) se asigna a una u otra ruta. De la empresa de transportes se debe
conocer su nombre, CIF y domicilio fiscal. Las rutas tienen un área de influencia que determina los destinos, y
unos días de reparto asignados. Se debe conocer la fecha en la que se reparte el pedido. Si se produce alguna
incidencia durante el reparto de algún pedido se almacena la fecha en la que se ha producido y una descripción.
Los socios pueden visualizar sus pedidos y cancelarlos siempre y cuando no hayan sido cumplimentados por el
empleado de almacén. Así mismo, puede modificar sus datos personales.
38 de 44 25/08/15 16:30
Diseño orientado a objetos. Elaboración de diagramas de compo... http://127.0.0.1:51235/temp_print_dirs/eXeTempPrintDir_r_Z...
Como se indicaba en los contenidos del apartado 2.2, lo más importante en la elaboración de un diagrama de
casos de uso, no es el diagrama en sí, sino la documentación de los casos de uso que es lo que permitirá
desarrollar otros diagramas que ayuden en la codificación del sistema, y la elaboración de los casos de prueba de
caja negra.
A modo de ejemplo vamos a desarrollar la documentación del caso de uso "Hacer Pedido", ya que, por su
complejidad, abarca todos los apartados que hemos visto. El ejemplo se hará con la herramienta Visual Paradigm
for UML, aunque tu puedes usar la herramienta que consideres más oportuna. Recordamos el aspecto del caso
de uso:
Los datos que debemos incluir para elaborar la documentación del caso de uso, el contrato, eran:
Para incluir el nombre, actores, propósito, precondiciones y postcondiciones abrimos la especificación del caso
de uso. Ésto da lugar a la aparición de una ventana con un conjunto de pestañas que podemos rellenar:
En la pestaña "General" rellenamos el nombre "Hacer pedido", y tenemos un espacio para escribir una
breve descripción del caso de uso, por ejemplo:
"El cliente visualiza los productos que están a la venta y los que se pueden seleccionar para añadirlos al
pedido. También, puede añadir tantos artículos como desee, cada artículo añadido modifica el total a pagar
según su precio y la cantidad seleccionada.
Cuando el cliente ha rellenado todos los productos que quiere comprar, debe formalizar el pedido.
En caso de que el cliente no sea socio de la empresa antes de formalizar la compra, se le indica que puede
hacerse socio y, si el cliente acepta, se abre el formulario de alta, en caso contrario se cancela el pedido.
En caso de que se produzca algún problema con los datos bancarios, se ofrecerá la posibilidad se volver a
introducirlos.
En la pestaña "Valores etiquetados" encontramos un conjunto de campos predefinidos, entre los que se
encuentran el autor, precondiciones y postcondiciones, que podemos rellenar de la siguiente manera:
Autor: usuario.
Precondiciones: existe una campaña abierta con productos de la temporada actual a la venta.
Postcondiciones: se ha añadido un pedido con un conjunto de productos para servir con el estado
"pendiente" que deberá ser revisado.
39 de 44 25/08/15 16:30
Diseño orientado a objetos. Elaboración de diagramas de compo... http://127.0.0.1:51235/temp_print_dirs/eXeTempPrintDir_r_Z...
También, se pueden incluir otros datos como la complejidad, el estado de realización del caso de uso la
complejidad que no hemos visto en esta unidad.
Para incluir el resto de los datos, en el caso de uso hacemos clic en la opción "Open Use Case Details..." del
menú contextual, lo que da lugar a la aparición de una ventana con una serie de pestañas. En ellas se recupera la
información de la especificación que hemos rellenado antes, además, podemos rellenar el flujo de eventos del
caso de uso, en condiciones normales usaríamos la pestaña "Flow of events", sin embargo, como esta opción
sólo está disponible en la versión profesional, utilizaremos la pestaña "Descripción", que está disponible en la
versión community. Para activarla pulsamos el botón "Create/Open Description".
Podemos añadir varias descripciones de diferentes tipos, pulsando el botón "Nuevo". Para añadir filas al flujo de
eventos, pinchamos en el botón. En principio, añadimos la descripción principal, luego añadiremos otras
alternativas.
Esta es la descripción principal, en ella se describe el flujo normal de eventos que se producen cuando se ejecuta
el caso de uso sin ningún problema.
Author usuario
EL usuario selecciona un conjunto de artículos, junto con la cantidad de los mismos, para
Brief
crear el pedido. Cuando se formaliza se comprueba que el usuario sea socio. A
Description
continuación se comprueban los datos bancarios, se realiza el cobro y se crea el pedido.
Post-conditions Se crea un pedido con los datos del usuario que lo realiza y los artículos solicitados.
1 Inicia el pedido.
3 Selecciona un artículo.
7 Se acepta el pedido.
40 de 44 25/08/15 16:30
Diseño orientado a objetos. Elaboración de diagramas de compo... http://127.0.0.1:51235/temp_print_dirs/eXeTempPrintDir_r_Z...
Añadimos un par de descripciones alternativas para indicar que hacer cuando el usuario no es socio y cuando los
datos bancarios no son correctos:
Flujo alternativo para el caso de uso Hacer Pedido cuando el usuario no está
registrado.
Author usuario
Brief Cuando el usuario hace un pedido si no está registrado se abre la opción de registro para
Description que se dé de alta.
1 Inicia el pedido.
3 Selecciona un artículo.
4 Selecciona la cantidad.
8 Acepta el pedido.
41 de 44 25/08/15 16:30
Diseño orientado a objetos. Elaboración de diagramas de compo... http://127.0.0.1:51235/temp_print_dirs/eXeTempPrintDir_r_Z...
Flujo alternativo para hacer pedido cuando los datos bancarios no son correctos.
Author usuario
Una vez que se han seleccionado los artículos y se han introducido los datos del socio, al
Brief
hacer la comprobación de los datos bancarios con la entidad externa se produce algún
Description
error, se da la posibilidad al usuario de modificar los datos o de cancelar el pedido.
Post-conditions Se crea un pedido con los datos del usuario que lo realiza y los artículos solicitados.
1 Inicia el pedido.
3 Selecciona un artículo.
7 Se acepta el pedido.
El resto de casos, se documentan de forma similar hasta completar la descripción formal de la funcionalidad del
sistema.
42 de 44 25/08/15 16:30
Diseño orientado a objetos. Elaboración de diagramas de compo... http://127.0.0.1:51235/temp_print_dirs/eXeTempPrintDir_r_Z...
43 de 44 25/08/15 16:30
Diseño orientado a objetos. Elaboración de diagramas de compo... http://127.0.0.1:51235/temp_print_dirs/eXeTempPrintDir_r_Z...
44 de 44 25/08/15 16:30