9.1 Identificación de eventos
El modelado de comportamientos permite describir un sistema de forma dinámica a través de eventos que ocurren en tiempos específicos de operación.
“El modelo de comportamiento indica la forma en la que responderá el software a eventos o estímulos externos” (Pressman, 2010).
El primer paso en el modelado de comportamiento es la identificación de eventos y la secuencia en la que se presentan en un sistema. Los diagramas de comportamiento que nos servirán para este tipo de modelos se le llaman diagrama de estado y diagramas de secuencia.
Según Sommerville (2011) este tipo de modelos asumen que los sistemas tienen un número finito de estados y eventos (estímulos) que pueden causar una transición de un estado a otro. A diferencia del diagrama de flujo de datos, no incluyen el flujo de información, pero pueden incluir información adicional para aclarar el procesamiento que se lleva a cabo en cada estado.
Cuando un sistema y un actor intercambian información aparece un evento. De hecho la mayoría de los eventos inician por alguna actividad del usuario, ya sea al hacer clic en un botón, elegir un elemento de una lista (combo box), cambiar de campo en una forma, teclear algún dato, todos son eventos que pueden ser configurados para que el sistema reaccione de diferente forma.
9.2 Representaciones de estado
Cualquier sistema de software puede llevar a cabo ciertas actividades y transiciones de un estado a otro (Pohl y Rupp, 2011).
Para construir un diagrama estado es necesario conocer sus partes:
Haz clic para conocer más detalle
Los estados se representan con rectángulos de esquinas redondeadas, mientras que las transiciones se dibujan utilizando flechas. Para realizar cualquier cambio de estado se requiere de un estímulo generalmente provocado por el usuario.
Los diagramas estado deben incluir un estado inicial y uno o varios estados finales. El primero se representa con un círculo relleno y el segundo con círculo semirelleno.
En un diagrama es posible encontrar transiciones en las que se inicie con el mismo estado en el que termina, tal y como se observa en la imagen anterior.
Un sistema que controla un cajero automático de un banco. El cliente introduce su tarjeta al cajero y le indica el PIN de 4 dígitos que tiene asignado para esa tarjeta. El sistema compara el PIN con los registros de los clientes y verifica que corresponda al número guardado. Si el PIN es incorrecto se procede a solicitarle al usuario ingrese nuevamente el código de 4 dígitos. Si esto se repite por 3 ocasiones la tarjeta es retenida. En caso que el PIN sea correcto, se le permitirá realizar movimientos como retiro de efectivo, compra de tiempo aire o consulta de saldos.
En este texto puedes observar el texto en negritas como eventos que suceden en el sistema de control de un cajero automático. Por ejemplo, los eventos son introducir tarjeta y PIN, comparación del PIN, retener la tarjeta por intentos fallidos, seleccionar acción.
Entre cada uno de los eventos es posible enviar o recibir información: introducir tarjeta, introducir PIN, selección del movimiento del cliente.
En este caso la tarjeta es considerada como información más que una tarjeta física, ya que cualquier tarjeta bancaria tiene una banda magnética o chip que contiene todos los datos de la cuenta del cliente y son recuperados por un lector del mismo cajero.
El evento de recuperar una tarjeta retenida no es parte del modelo de este diagrama ya que es un proceso que se realiza manualmente por el cliente y el gerente del banco.
Adecuación al modelo de estados, recuperado de Pressman, R. (2010). Ingeniería de Software. Un enfoque práctico. (7ª ed.). México: McGraw Hill. Figura 7.6. Sólo para fines educativos.
En estos diagramas también existe el concepto de jerarquía de estados y concurrencia.
En la jerarquía de estados es posible establecer que solo es posible llegar a ciertos estados siempre y cuando hayan pasado por subestados. Por ejemplo para llegar al estado E, es necesario haber pasado por el estado A y los subestados: B, C y D.
La concurrencia permite expresar que un evento puede provocar cambios de estados en paralelo.
9.3 Diagramas de secuencia
Los diagramas de secuencia son una herramienta bastante útil cuando se necesita aclarar la interacción entre el usuario y el sistema en un caso de uso en particular.
En el siguiente ejemplo, Sommerville (2011) nos ofrece un diagrama de secuencia que aclara los momentos en los que interactúa un asistente de un médico con un sistema que mantiene el historial médico de pacientes.
Imagen obtenida de Sommerville, I. (2011). Ingeniería de Software (9ª ed.). México: Pearson. Figura 5.6. Sólo para fines educativos.
El diagrama incluye los objetos y los actores que están involucrados en la parte superior. Cada uno de ellos se les dibuja una línea punteada hacia abajo, mientras las interacciones son representadas por flechas a las que se les coloca una etiqueta que explica las llamadas al objeto, sus parámetros (entre paréntesis) y los valores de respuesta con una flecha punteada. Observa que cada objeto incluye un rectángulo sobre la línea punteada indicando el momento de su creación, operación y eliminación.
Un diagrama de secuencias se inicia de izquierda a derecha, y de arriba hacia abajo. Sommerville incluye un flujo alternativo entre los objetos con un recuadro con la palabra “ALT”.
Explicación del diagrama:
- El diagrama empieza cuando la recepcionista solicita un registro médico de un paciente en particular incluyendo el número de paciente (PID) a través de la interfaz de usuario.
- La instancia P del objeto PacientInfo se crea e invoca a una base de datos (MHCPMS) solicitándole un reporte. En este caso se incluye el identificador del usuario (UID) con el fin de reconocer si el usuario tiene los permisos suficientes para consultar esa información.
- Las credenciales del usuario son verificadas por un sistema de autenticación.
- En caso de que la autorización sea positiva, la base de datos regresará la información solicitada o bien generará un error.
Como puedes observar el diagrama es bastante sencillo de interpretar. No todos los casos de uso requieren de este tipo de diagramas, solo aquellos en los que la interacción interviene varios objetos.
El siguiente ejemplo incluye un segundo actor que es el sistema de registro de pacientes (PRS) y trata de explicar las interacciones que aparecen cuando la recepcionista médico desea actualizar un registro médico de un paciente.
Descripción del diagrama:
- El primer paso sucede cuando la recepcionista médico solicita acceso al sistema de registros de pacientes.
- Si este sistema le otorga acceso entonces existen dos alternativas.
La primera es enviar la actualización de la información de un paciente. Si el usuario tiene permisos para actualizar ese registro en particular entonces el sistema de registros actualiza el registro en la base de datos y le confirma a la recepcionista el evento.
La segunda alternativa es crear un resumen que actualice la información del paciente utilizando una interfaz de usuario llamada Resumen.
- La interacción termina cuando la recepcionista médico sale del sistema con el método logout()
Imagen obtenida de Sommerville, I. (2011). Ingeniería de Software (9ª ed.). México: Pearson. Figura 5.7. Sólo para fines educativos
