UML Capítulo 3: Conceptos Básicos II

¡Hola de nuevo internauta!,

       En el capítulo anterior vimos unos cuantos diagramas así que en este tocan ver los siguientes: Diagrama de máquina de estado, diagrama de actividad, diagrama de secuencia y diagrama de comunicación. En una entrada posterior veremos los que nos quedan. ¡Vamos al meollo!.

Aviso a navegantes: Los diagramas expuestos como ejemplos no son los usados en la notación correcta de UML (estos los veremos en sucesivas entradas) pero los uso igualmente porque reflejan de una manera gráfica la explicación dada.

• Diagrama de máquina de estados: Este tipo de diagrama se usa para modelar el comportamiento de un objeto de una clase a lo largo del tiempo especificando los distintos estados del mismo que desencadenan los eventos.
Actualmente existen dos tipos de máquinas de estado: las finitas y las infinitas.




Tranquilo Jackie que ahora te lo explicamos

La explicación es muy sencilla, la máquina de estados finitos es la que manejamos en la actualidad y se llaman así porque los bits toman valores discretos (0 ó 1), o dicho de otra manera, ejecuto este evento o este otro pero nunca dos a la vez, para ver un ejemplo fijaros en el dibujo de abajo; las máquinas de estados infinitas aún no existen pero ya se están en camino y se debe a los ordenadores cuánticos que usan Qubit, los cuales toman valores continuos (desde aquí, hasta el infinito y más allá).


¿Qué me indica este diagrama?: Cuando el usuario inicia este estado (porque a llegado a el desde otro anterior o es el principal) se presenta el objeto Pantalla(las pantallas no son objetos dirán los puristas, y tienen razón, pero lo presento aquí de ejemplo para que se comprenda mejor el flujo), si en esta se ejecuta el evento aceptar se llama a BuscarPersona, que ejecuta a su vez los eventos existe y no existe. En el primer caso devuelve el control a Pantalla y en el segundo se llama a AltaPersona que devuelve el evento alta y nos lleva a la pantalla de nuevo. En la gráfica podemos ver lo que se denomina un efecto, en este caso liberar(), y representa una acción (no un evento) que se realiza tras la ejecución de un evento, en este caso, liberar recursos (¡soy tan original!).

• Diagrama de actividad: Este tipo de diagramas son los que la gente conoce mejor debido a que es la representación gráfica del algoritmo mostrando así el flujo de control entre las actividades computacionales. Permiten comprender a un alto nivel la ejecución de un sistema sin profundizar en sus detalles internos.


Se pueden representar tanto vertical como horizontalmente. ¿Y qué queremos indicar aquí?, bueno, lo mismo que lo explicado en el punto anterior pero de una manera más intuitiva. Se parece a una máquina de estados pero no es lo mismo, fijaros bien, aquí representamos el algoritmo mientras que en el diagrama de estados representamos los estados y sus comportamientos sin indicar cómo es la ejecución del algoritmo (no sé si me he explicado bien).

• Diagrama de secuencia: En este tipo de diagramas describimos el intercambio de mensajes entre los objetos del sistema ordenados en una secuencia temporal. Se modela para cada caso de uso y contiene detalle para la implementación del escenario, cada mensaje de este tipo de diagrama responde a una operación de una clase o a un evento disparado.




¿Y esto que nos está diciendo?, que para el alta persona el tiempo (representado con rectángulos verticales) total de la aplicación (indicado en el rectángulo debajo del actor) es igual a la suma de tiempo usado por los objetos, que son: Actor, persona:Persona (que se divide en otros dos objetos: Buscar y Alta) y almacenar. Los mensajes de cada objetos están representados mediante las flechas y sus nombre coinciden con los eventos representados en el diagrama de estados (liberar() no aparece porque no es un evento sino un efecto). La secuencia temporal es la siguiente:


1. El usuario pulsa aceptar.
2. Se llama a Buscar (representa a getPersona() pero el nombre era demasiado largo para la gráfica) y si existe se devuelve el control al usuario(fin del proceso puesto que no hay más flechas). Si no existe se continúa.
3. Se llama a Alta (representa a setPersona()).
4. Se almacena la información y se devuelve un valor al objeto que inició la llamada (Alta en este caso).
5. Alta devuelve el valor al Actor (fijaros que no a Buscar porque dicho objeto no se vuelve a llamar(lo que coincide con el diagrama de estados y el diagrama de actividad) puesto que su tiempo de vida a expirado en el sistema.

Ahora bien, no se especifica si lo que se devuelve es un mensaje de error o de operación correcta ya que eso no es competencia de este tipo de diagrama. Aquí sólo se representa el tiempo de vida de los objetos y su intercambio de mensajes que bien puede ser una operación (return) o eventos (aceptar, existe, etc).

• Diagrama de comunicación: En este diagrama se modela las interacciones entre objetos mediante mensajes secuenciales (dicha secuencia se muestra en el diagrama mediante números) mostrando así la implementación de cualquier operación. Mientras el diagrama de secuencia muestra la secuencia temporal, el diagrama de comunicación muestra de una manera geométrica las relaciones entre roles adjacentes(representan la vida de los distintos objetos a lo largo del tiempo) y y relaciona los mensajes (aceptar, existe,...) con los conectores.




¿Y esto qué significa?. Podemos observar varias cosas:


1. Sólo se representan los mensajes entre roles adyacentes por lo tanto podemos ver que el mensaje 5:return sólo se representa entre el rol BBDD Persona y setPersona quedando sin implementar el mensaje entre setPersona y Actor ya que no son adyacentes dichos roles.
2. Podemos intuir la secuencia de mensajes (el orden en el que se ejecutan) por su número.
3. Vemos las relaciones entre los distintos roles: Actor -> getPersona, getPersona-> setPersona y setPersona -> BBDD Persona. Que coincide con lo representado en el diagrama de secuencia pero sin especificar de una manera tan implícita en este diagrama el tiempo.

¿Cuándo usar un diagrama de secuencia y otro de comunicación?

 Usando un poco el sentido común, me explico, si lo que queremos es dar a entender a nuestro interlocutor (cliente, jefe, ...) la relación entre los objetos o roles y los mensajes enviados usaremos un diagrama de comunicación pero si además de esto, queremos especificar el tiempo en el que dichos mensajes son enviados, usaremos un diagrama de secuencia. En ambos se ven obviamente que mensajes se envian por orden pero en el de secuencia podemos ver exactamente en que momento son enviados.

Y hasta aquí la segunda parte de conceptos básicos sobre UML. Esta entrada me ha quedado muy larga pero espero que os haya servido de ayuda. En la siguiente entrada veremos el resto de diagramas que nos quedan.

¡Gracias por leerme!