Informática y Sistemas (β)

2009/09/09 - 9 septiembre 2009

Diagramas de Estado y modelado de Sistemas

Anteriormente presenté un Diagrama  de Estados, como versión simplificada de los Diagramas de Máquinas de Estado del UML, y un ejemplo de un diagrama básico con sus elementos fundamentales; en este post lo veremos como un auxiliar del arquitecto de sistemas para modelar y definir comportamiento.

Diagramas de estados tipo

Diagramas de estados tipo

El ejemplo de la imagen es bien abstracto, con el fin de ser didacticos. El objetivo del diagrama es definir todos los posibles estados que puede tener un objeto, en nuestro caso de aplicación práctica se referirá a documentos de organizaciones o empresas; recordemos que debe hacerse un diagrama independiente por cada documento de tipo electrónico que maneje el sistema. 

Un estado, según el UML v2.2, modela una situación en la que algunas condiciones invariantes (normalmente implícitas) se mantienen. En el caso de nuestros objetos de documento, se interpreta como un modelo estable conformado por un subconjunto de las propiedades de los documentos adoptando valores perfectamente definidos, y que permiten un comportamiento determinado del documento. El caso más simple y recomendado, es que exista una sola propiedad del documento que adopte el valor que justamente define el estado, sobre la base del cual el sistema permite un cierto comportamiento.

Al ser este comportamiento parte de las reglas de negocio del sistema, se hace necesario definirlos y consensuarlos conjuntamente con los usuarios o clientes internos de la organización; y una vez establecidos serán fijos e inamovibles, dado que provienen del conocimiento de los verdaderos conocedores del negocio.

Resumiendo, estos estados rotulados por un nombre representativo consisten en un conjunto de propiedades del documento que cumplen ciertas condiciones. A la vez, los estados se enlazan en una red de transiciones, donde los conectores en forma de flecha dan el sentido en que se produce la transición. De este modo se refleja una faceta del comportamiento del objeto o documento que modela en forma bastante estricta lo que serán las interacciones de los procesos de negocios. Volviendo al UML v2.2, una transición es una relación directa entre un “vertex” (estado o pseudoestado) de origen hacia uno de destino. En nuestro caso las transiciones representan toda posible relación directa permitida entre estados, tomados de dos en dos.

Para el diseño, si estamos tratando con arquitectura en capas, debe considerarse que un diagrama de este tipo corresponde a la lógica a nivel de negocio del sistema (business layer). Si estuviéramos en una arquitectura orientada a objetos, deberá definir el comportamiento del documento considerado como un objeto. El principal punto a considerar es que la transición entre dos estados se corresponde básicamente a una transformación de las propiedades del documento; que puede estar dada a través de una o varias funciones, y aquí recomiendo enfáticamente de que exista una correspondencia entre la transición y solo una función o método transformador, ya que esta identidad ayudará a evitar inconsistencias en la operación del sistema.

La siguiente recomendación es que los estados y sus transiciones no residan programados “en duro” (hardcoded), y se parametricen en tablas (sean XML o de base de datos), de este modo se podrá modificar más fácilmente el comportamiento de los documentos sin tener que recurrir a modificaciones del código, con todo lo que eso implica (desarrollo, pruebas,  implementaciones, etc.). Por ejemplo, para el diagrama superior tendríamos la siguiente tabla que describen todas las transiciones posibles del documento:

 

Tabla de Transiciones posibles

Origen       Destino

Estado1     Estado2

Estado1     Estado3

Estado1     Estado4

Estado2     Estado1

Estado2     Estado4

 

 Las transiciones en este tipo de diagramas, se corresponden a métodos que se ejecutan a partir de eventos disparados por usuarios o tareas programadas automatizadas. En definitiva, en caso de que se desencadenen por los usuarios, estos contarán con alguna interfaz de operación, donde gracias a la parametrización de los diagramas de estados, dispondrán de un conjunto de estados destino a los que pueden llevar el documento, o de una serie de métodos correspondientes a estas transiciones. Y aquí la buena práctica indica que se debe elegir un modo de interacción con los usuarios consistentes a lo largo de todo el proceso: o se le ofrecen los estados destino o los métodos asociados a las transiciones; pero no una mezcla o sucesión de los mismos.

Aquí se simplifican los conceptos, pero señalan los lineamientos a tener en cuenta en cualquier desarrollo; por ejemplo es común que no todas las transiciones definidas a partir de un estado estén disponibles al mismo tiempo, y dependan de alguna manera de propiedades del documento, el grado de privilegio del usuario para realizar cambios, o simplemente del transcurso del tiempo; pero estos comportamientos pueden adicionarse en forma programática fácilmente sin necesidad de trasgredir los principios aquí expuestos.

 (tiny)

Anuncios

Dejar un comentario »

Aún no hay comentarios.

RSS feed for comments on this post. TrackBack URI

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

Crea un blog o un sitio web gratuitos con WordPress.com.

A %d blogueros les gusta esto: