DIAGRAMA DE COMPORTAMIENTO

MARTES 29 DE JULIO 2014.

INTRODUCCIÓN

En esta clase solo vimos de forma ràpida lo que son los diagrama de comportamiento.No estudiamos todos los diagramas.Pero aquì les dare a conocer un poco de cada diagrama.

Se conocerá cuáles eran los beneficios que se obtienen al utilizar cada uno de estos diagramas, es bueno referirse de que cada diagrama tiene su función, esto ayudan a resolver problemas, a desarrollar de mejor manera un proyecto de software.

MARCO TEORICO
DIAGRAMA DE COMPORTAMIENTO.

Los diagramas de comportamiento se emplean para visualizar, especificar, construir y documentar los aspectos dinámicos de un sistema.

Los aspectos dinámicos de un sistema  de softwareinvolucran cosas tales como el flujo de mensajes a lo largo del tiempo y el movimiento físico de componentes  en una red. A continuación se describe y ejemplifica cada uno de los cinco diagramas de comportamiento de UML.

Diagrama de casos de uso

Los casos de uso y el diagrama de uso de caso UML ayudan a determinar la funcionalidad y características del software desde la perspectiva del usuario. Para proporcionarle una aproximación a la manera en la que funcionan los casos de uso y los diagramas de uso de caso, se crearán algunos para una aplicación de software que gestiona archivos de música digital, similar al software iTunes de Apple. Algunas de las cosas que puede incluir el software son funciones para:

• Descargar un archivo de música MP3 y almacenarlo en la biblioteca de la aplicación.

• Capturar música de streaming (transmisión continua) y almacenarla en la biblioteca de la aplicación.

• Gestionar la biblioteca de la aplicación (por ejemplo, borrar canciones u organizarlas en listas de reproducción).

• Quemar en CD una lista de las canciones de la biblioteca.

• Cargar una lista de las canciones de la biblioteca en un iPod o reproductor MP3.

• Convertir una canción de formato MP3 a formato AAC y viceversa.

Un caso de uso describe la manera en la que un usuario interactúa con el sistema, definiendo los pasos requeridos para lograr una meta específica (por ejemplo, quemar una lista de canciones ¿en un CD). Las variaciones en la secuencia de pasos describen varios escenarios (por ejemplo, ¿y si todas las canciones de la lista no caben en un CD?).

Un diagrama UML de uso de caso es un panorama de todos los casos de uso y sus relaciones.

El mismo proporciona un gran cuadro de la funcionalidad del sistema. En este diagrama.Por lo general, los sistemas complejos tienen más de un actor. Por ejemplo, una aplicación de máquina expendedora puede tener tres actores que representan clientes, personal de reparación y proveedores que rellenan la máquina.

En el diagrama de uso de caso, los casos de uso se muestran como óvalos. Los actores se conectan mediante líneas a los casos de uso que realizan. Observe que ninguno de los detalles de los casos de uso se incluye en el diagrama y, en vez de ello, necesita almacenarse por separado.

Observe también que los casos de uso se colocan en un rectángulo, pero los actores no.

Este rectángulo es un recordatorio visual de las fronteras del sistema y de que los actores están afuera del sistema.

Algunos casos de uso en un sistema pueden relacionarse mutuamente. Por ejemplo, existen pasos similares al de quemar una lista de canciones en un CD y cargar una lista de canciones en un iPod. En ambos casos, el usuario crea primero una lista vacía y luego agrega las canciones de la biblioteca a la lista. Para evitar duplicación en casos de uso, por lo general es mejor crear un nuevo caso de uso que represente la actividad duplicada y luego dejar que los otros casos de uso incluyan este nuevo caso de uso como uno de sus pasos. Dado que despliega todos los casos de uso, un diagrama de uso de caso es un auxiliar útil para asegurar que cubrió toda la funcionalidad del sistema. En el organizador de música digital,seguramente querría más casos de uso, tal como uno para reproducir una canción de la biblioteca.

Diagrama de actividad

Un diagrama de actividad UML muestra el comportamiento dinámico de un sistema o de parte deun sistema a través del flujo de control entre acciones que realiza el sistema. Es similar a un diagrama de flujo, excepto porque un diagrama de actividad puede mostrar flujos concurrentes.

El componente principal de un diagrama de actividad es un nodo acción, representado mediante un rectángulo redondeado, que corresponde a una tarea realizada por el sistema de software. Las flechas desde un nodo acción hasta otro indican el flujo de control; es decir, una flecha entre dos nodos acción significa que, después de completar la primera acción, comienza la segunda acción. Un punto negro sólido forma el nodo inicialque indica el punto de inicio de la actividad. Un punto negro rodeado por un círculo negro es el nodo final que indica el fin de la actividad.

Un tenedor(fork) representa la separación de actividades en dos o más actividades concurrentes.

Se dibuja como una barra negra horizontal con una flecha apuntando hacia ella y doso más flechas apuntando en sentido opuesto. Cada flecha continua representa un flujo de controlque puede ejecutarse de manera concurrente con los flujos correspondientes a las otras flechas continuas. Dichas actividades concurrentes pueden realizarse en una computadora, usando diferentes hebras o incluso diferentes computadoras.

Ejemplo:

La figura que se  muestra  a continuación, es un ejemplo de diagrama de actividad que involucra hornear un pastel.

El primer paso es encontrar la receta. Una vez encontrada pueden medirse los ingredientes secos y líquidos, mezclarse y precalentar el horno. La mezcla de los ingredientes secos puede hacerse en paralelo con la mezcla de los ingredientes líquidos y el precalentado del horno.

Una unión (join) es una forma de sincronizar flujos de control concurrentes. Se representa mediante una barra negra horizontal con dos o más flechas entrantes y una flecha saliente. Elflujo de control representado por la flecha saliente no puede comenzar la ejecución hasta que todos los flujos representados por las flechas entrantes se hayan completado.

En la figura muestra que se tiene una unión antes de la acción de mezclar en conjunto los ingredientes líquidos y secos.

Esta unión indica que todos los ingredientes secos deben mezclarse y que debe hacerse lo mismo con todos los ingredientes líquidos antes de poder combinar las dos mezclas. La segunda unión en la figura indica que, antes de comenzar a hornear el pastel, todos los ingredientes deben mezclarse juntos y el horno debe estar a la temperatura correcta.

Un nodo de decisión corresponde a una rama en el flujo de control con base en una condición.

Tal nodo se despliega como un triángulo blanco con una flecha entrante y dos o más flechas salientes. Cada flecha saliente se etiqueta con una guardia (una condición dentro de corchetes).

El flujo de control sigue la flecha saliente cuya guardia es verdadera. Es recomendable asegurarsede que las condiciones cubran todas las posibilidades, de modo que exactamente una de ellas sea verdadera cada vez que se llegue a un nodo de decisión. La figura muestra un nodo de decisión que sigue al horneado del pastel. Si el pastel está hecho, entonces se saca del horno. De otro modo, se hornea un poco más.

Una de las cosas que no dice el diagrama de actividad de la figura ya anteriormente observada es quién o qué hace cada una de las acciones. Con frecuencia, no importa la división exacta de la mano de obra. Pero si quiere indicar cómo se dividen las acciones entre los participantes, puede decorar el diagrama de actividad con “canales”, como se muestra en la siguiente figura. Los canales, como el nombreimplica, se forman dividiendo el diagrama en tiras o “carriles”; es decir como si fuera una alberca con carriles de natación, cada uno de los cuales corresponde a uno de los participantes. Todas las acciones en un carril las realiza el participante correspondiente. En la figura, Evan es responsable de la mezcla de los ingredientes secos y, luego, de mezclar juntos los ingredientes secos y los líquidos; Helen es responsable de calentar el horno y sacar el pastel; y Mary es responsable de todo lo demás.

Diagrama de Estado

Un diagrama de estado UML modela los estados de un objeto, las acciones que se realizandependiendo de dichos estados y las transiciones entre los estados del objeto.

Como ejemplo, considere el diagrama de estado para una parte de un compilador Java. La entrada al compilador es un archivo de texto, que puede considerarse como una larga cadena de caracteres. El compilador lee caracteres uno a uno y a partir de ellos determina la estructura del programa. Una pequeña parte de este proceso de lectura de caracteres involucra ignorarcaracteres de “espacio blanco” (por ejemplo, los caracteres espacio, tabulador, línea nueva y retorno) y caracteres dentro de un comentario.

Un diagrama de estado muestra los estados mediante rectángulos redondeados, cada uno de los cuales tieneun nombre en su mitad superior. También existe un círculo llamado “pseudoestado inicial”, queen realidad no es un estado y en vez de ello sólo apunta al estado inicial.

En la figura que está a continuación el estado start es el estado inicial. Las flechas de un estado a otro estado indican transiciones o cambios en el estado del objeto. Cada transición se etiqueta con un evento disparador, una diagonal (/) y una actividad. Todas las partes de las etiquetas de transición son opcionales en los diagramas de estado. Si el objeto está en un estado y el evento disparador ocurre para una de sus transiciones, entonces se realiza dicha actividad de transición y el objeto toma un nuevo estado, indicado por la transición. Por ejemplo, en la figura A1.13, si el objeto EliminadorEspacioBlancoyComentario está en el estado start y el siguiente carácter es “/”, entonces EliminadorEspacioBlancoyComentario avanza desde dicho carácter y cambia al estado vio ‘/’.

Si el carácter después de “/” es otra “/”, entonces el objeto avanza al estado línea comentario y permanece ahí hasta que lee un carácter de fin de línea. Si en vez de ello el siguiente carácter después de “/” es “*”, entonces el objeto avanza al estado bloque comentario y permanece ahí hasta que ve otro “*” seguido por un “/”, que indica el final del bloque comentario. Estudie el diagrama para asegurarse de que lo entiende. Observe que, después de avanzar por el espacio en blanco o por un comentario, EliminadorEspacioBlancoyComentario regresa al estado start y comienza de nuevo. Dicho comportamiento es necesario, pues puede haber varios comentarios sucesivos o caracteres de espacio en blanco antes de cualquier otro carácter en el código fuente Java.

Un objeto puede transitar a un estado final, lo que se indica mediante un círculo negro con un círculo blanco alrededor de él, lo que indica que ya no hay más transiciones. En la figura, el objeto EliminadorEspacioBlancoyComentario termina cuando el siguiente carácter no es espacio en blanco o parte de un comentario. Observe que todas las transiciones, excepto las dos que conducen al estado final, tienen actividades que consisten en avanzar al siguiente carácter. Las dos transiciones hacia el estado final no avanzan sobre el siguiente carácter porque el siguiente carácter es parte de una palabra o símbolo de interés para el compilador.

Observe que, si el objeto está en el estado vio ‘/’, pero el siguiente carácter no es “/” o“*”, entonces “/” es un operador división o parte del operador /= y, por tanto, no se quiere avanzar.

De hecho, se quiere regresar un carácter para hacer el “/” en el siguiente carácter, de modo que “/” pueda usarse por parte del compilador. En la figura, esta actividad se etiqueta como retroceder ‘/’.

 

Un diagrama de estado le ayudará a descubrir situaciones pérdidas o inesperadas, es decir, con un diagrama de estado, es relativamente sencillo garantizar que todos los posibles eventos disparadores para todos los estados posibles se representaron. Por ejemplo, en la figura que se observó anteriormente, puede verificar fácilmenteque cada estado incluyó transiciones para todos los posibles caracteres.

Los diagramas de estado UML pueden contener muchas otras características no incluidas en la figura ya observada. Por ejemplo, cuando un objeto está en un estado, por lo general no hace más que sentarse y esperar que ocurra un evento disparador. Sin embargo, existe un tipo especial deestado, llamado estado de actividad, donde el objeto realiza alguna actividad, llamada haceractividad, mientras está en dicho estado. Para indicar que un estado es un estado de actividad en el diagrama de estado, se incluye, en la mitad inferior del rectángulo redondeado del estado, la frase “do/” seguida por la actividad que debe realizar mientras está en dicho estado. El “hacer actividad” puede terminar antes de que ocurra cualquier transición de estado, después de lo cual el estado de actividad se comporta como un estado normal de espera. Si una transición del estado de actividad ocurre antes de terminar el “hacer actividad”, entonces se interrumpe el “hacer actividad”.

Puesto que un evento disparador es opcional cuando ocurre una transición, es posible que ningún evento disparador pueda mencionarse como parte de una etiqueta de transición. En tales casos, para estados de espera normales, el objeto inmediatamente transitará de dicho estado al nuevo estado. Para estados de actividad, tal transición se realiza tan pronto como termina el “hacer actividad”.

Diagrama de Comunicación

El diagrama de comunicación UML (llamado “diagrama de colaboración” en UML 1.X) proporciona otro indicio del orden temporal de las comunicaciones, pero enfatiza las relaciones entre los objetos y clases en lugar del orden temporal. El diagrama de comunicación que se ilustra en la figura siguiente, despliega las mismas acciones que se muestran en el diagrama de secuencia.

 

En un diagrama de comunicación, los objetos interactuantes se representan mediante rectángulos.

Las asociaciones entre objetos lo hacen mediante líneas que conectan los rectángulos.

Por lo general, en el diagrama existe una flecha entrante hacia un objeto que comienza la secuencia de pase de mensaje. Esa flecha se etiqueta con un número y un nombre de mensaje. Si el mensaje entrante se etiqueta con el número 1 y si hace que el objeto receptor invoque otros mensajes en otros objetos, entonces los mencionados mensajes se representan mediante flechas desde el emisor hacia el receptor a lo largo de una línea de asociación y reciben números 1.1, 1.2, etc., en el orden en el que se llaman. Si tales mensajes a su vez invocan otros mensajes, se agrega otro punto decimal y otro número al número que etiqueta dichos mensajes para indicar un anidado posterior del pase de mensaje.

 

Diagrama de Secuencia

En contraste con los diagramas de clase y con los diagramas de implementación, que muestran la estructura estática de un componente de software, un diagrama de secuencia se usa para mostrar las comunicaciones dinámicas entre objetos durante la ejecución de una tarea. Este tipo de diagrama muestra el orden temporal en el que los mensajes se envían entre los objetos para lograr dicha tarea. Puede usarse un diagrama de secuencia para mostrar las interacciones en un caso de uso o en un escenario de un sistema de software.

En la figura que se ilustra a continuación se ve un diagrama de secuencia para un programa de dibujo. El diagramamuestra los pasos involucrados, resaltando una figura en un dibujo cuando se le da clic. Por lo general, cada caja de la fila que hay en la parte superior del diagrama corresponde a un objeto, aunque es posible hacer que las cajas modelen otras cosas, como clases. Si la caja representa un objeto (como es el caso en todos los ejemplos), entonces dentro de la caja puede establecerse de manera opcional el tipo del objeto, precedido por dos puntos. También se puede escribir un nombre del objeto antes de los dos puntos, como se muestra en la tercera caja de la figura.

Abajo de cada caja hay una línea punteada llamada línea de vida del objeto. El eje vertical que hay en el diagrama de secuencia corresponde al tiempo, donde el tiempo aumenta conforme se avanza hacia abajo.

Un diagrama de secuencia muestra llamadas de método usando flechas horizontales desde el llamador hasta el llamado, etiquetado con el nombre del método y que opcionalmente incluye sus parámetros, sus tipos y el tipo de retorno. Por ejemplo, en la figura, MouseListener(escucha de ratón) llama al método getFigureAt() (obtener figura en) de Drawing (dibujo).

Cuando un objeto ejecuta un método (es decir, cuando tiene un marco de activación en la pila), opcionalmente puede mostrar una barra blanca, llamada barra de activación, abajo de la línea de vida del objeto. En la figura, las barras de activación se dibujan para todas las llamadas de método. El diagrama también puede mostrar opcionalmente el retorno de una llamada de método con una flecha punteada y una etiqueta opcional. En la figura, el retorno de la llamada de método getFigureAt() se muestra con una etiqueta del nombre del objeto que regresa.

 

CONCLUSIÓN

Los diagramas de casos de uso se utilizan para ilustrar los requerimientos del sistema al mostrar como reacciona una respuesta a eventos que se producen en el mismo.

El diagrama de estados, o de transiciones de estado, es otra herramienta para determinar los métodos delas clases.

Los diagramas de actividad muestran la secuencia de actividades en un proceso, incluyendo las actividades secuenciales y paralelas, además de las decisiones que se toman.

Los diagramas de secuencia pueden ilustrar una sucesión de interacciones entre clases o instancias de objetos a través del tiempo.

Los diagramas de comunicación describen las interacciones entre dos o más cosas en el sistema que desempeñan un comportamiento mayor a lo que cualquiera de las dos cosas pueden hacer por su cuenta.

BIBLIOGRAFÍA

Pressman, R. 2010. INGENIERÍA DEL SOFTWARE. Un enfoque práctico. Séptima edición.