260 likes | 600 Views
Diagrama de actividades. Daniel Correa Botero José López Vélez Universidad de Antioquia 2013-II. Para ver la parte dinámica de las interacciones entre objetos se utilizan los diagramas de interacción.
E N D
Diagrama de actividades Daniel Correa BoteroJosé López VélezUniversidad de Antioquia 2013-II
Para ver la parte dinámica de las interacciones entre objetos se utilizan los diagramas de interacción Los diagramas de comportamiento muestran la conducta en tiempo de ejecución del sistema, tanto visto como un todo como de las instancias u objetos que lo integran. Los diagramas estructurales presentan elementos estáticos del modelo, tales como clases, paquetes o componentes
Diagrama de Actividades • Se usa para representar un conjunto de acciones que conducen a realizar un objetivo. • Típicamente utilizado para representar los modelos del negocio y para modelar la lógica detallada de una regla del negocio. • Permite modelar el comportamiento dinámico de un procedimiento, una transacción o un caso de uso, haciendo énfasis en el proceso que se lleva a cabo.
Elementos del diagrama • Nodo de inicio • Nodo de fin • Acción/Paso • Transición Acción/Paso
Elementos del diagrama • Nodo de decisión Se evalúa a Falso o Verdadero y deben ser excluyentes [condición de guarda] [condición de guarda] Alternativas de flujo de control, en función de la condición de guarda Acción 1 Acción2 Nodo Merge
Nodo de decisión • Las condiciones de guarda deben ser mutuamente excluyentes. ¿Cuál de las 2 condiciones esta mala?
Ejemplo • Realizar el diagrama de actividades para el caso de uso: “Create a new blog account”
Más elementos • La palabra "actividad" es usada frecuentemente en lugar de la palabra "acción" para describir un paso en un diagrama de actividad, pero no son lo mismo. • Una actividad es el proceso que se está modelando, tal como el lavado de un coche. Una acción es un paso en la actividad general, como enjabonado, enjuague y secado.
Fork & Join • Representan ejecuciones en paralelo • Todas las acciones deben llevarse a cabo para poder continuar con la primer acción después del join. Preparar hamburguesa Entregar Domicilio Preparar Papas
Eventos de tiempo • Pueden ser periodos de espera. • Pueden ser eventos repetitivos.
Llamando a otras actividades Se usa un símbolo de tridente invertido
Señales • Representan interacciones del proceso que se está describiendo, con sistemas u otros procesos externos a él. • Existen 2 elementos Nodo señal de recepción Nodo señal de envío
Señales • Una actividad también puede comenzar con una señal de recepción. En este caso indica que puede aceptar una o muchas señales.
Particiones • Ayudan a organizar el diagrama de actividades mediante la aclaración de las partes responsables
Anotaciones • Otra forma de delegar responsabilidades Se coloca entre paréntesis el nombre de la entidad responsable
Resumen formas de iniciar una actividad • Por un nodo de inicio • Por una señal de recepción • Por un evento de tiempo
Actividad Represente el siguiente ejercicio con un diagrama de actividades (utilice particiones, fork & join, nodos de decisión y eventos de tiempo). • Un cliente llega a un restaurante McRonals, el cliente empieza seleccionando una gaseosa, luego selecciona las papas y por último la hamburguesa. • Una cajera registra la información y luego asigna el pedido al Chef. • El chef automáticamente prepara la gaseosa, las papas y la hamburguesa (en el proceso de preparación de la hamburguesa espera 5 minutos mientras se cocina la carne y luego arma la hamburguesa). • Cuando las papas, la hamburguesa y la gaseosa están listas, el chef envía el pedido a la cajera. La cajera automáticamente entrega el pedido al cliente • El cliente finalmente valida que el pedido sea el correcto, si no es correcto la cajera nuevamente registra el pedido.
Bibliografía • Learning UML 2.0 O’Reilly. 2006. • Software Modeling & desing. UML, use cases, patterns, & software architectures. Hassan Gomma. 2011. • UML y patrones. Craig Larman. 1999. • Ingeniería del software. Un enfoque practico 5ta edición. Roger S. Pressman. 2002. • Use Case DrivenObjectModelingwith UML, Theory and Practice. Doug Rosenberg. 2007.