Máquinas de estados del protocolo de construcción en uml 2

Cuando usted quiere mostrar la secuencia de eventos de un objeto reacciona a - y el comportamiento resultante - utiliza la notación UML que crea diagramas de estado de comportamiento (también conocido como máquinas): Este tipo de diagramas de estado tienen pares / acción de eventos, acciones, acciones de entrada de salida, y hacer actividades. La mayoría de los diagramas de estado utilizan estas características-, en efecto, son máquinas de estados de comportamiento.

A veces, sin embargo, lo que desea es mostrar una secuencia específica de eventos que el objeto responde a - y cuando se puede responder - sin tener que mostrar su comportamiento. Tal secuencia especificada se llama protocolo de evento. En UML 2, usted puede mostrar protocolos de eventos por diagramación máquinas de estado de protocolo. Estos difieren de las máquinas de estado de comportamiento y tienen usos especiales.

Normalmente debería utilizar diagramas de estado regulares para mostrar secuencias internas de conducta para todos los objetos de una clase. A veces, sin embargo, que desea mostrar un protocolo complejo (conjunto de normas que rigen la comunicación) al utilizar una interfaz para una clase. Por ejemplo, cuando usted está diseñando clases que tienen acceso a una base de datos para su aplicación es necesario utilizar las operaciones comunes como abrir, cerrar y consultar una base de datos. Sin embargo, estas operaciones deben ser llamados en el orden correcto. No se puede consultar la base de datos antes de abrirlo.

Una solución para el diseño de una clase de acceso base de datos simple es desarrollar una clase DatabaseAccessor con una interfaz dbaccess como se muestra en la Figura 1. Sin embargo, la interfaz dbaccess tiene un protocolo complejo que rige su uso debido a las normas que regulan la comunicación entre cualquier otro objeto y la DatabaseAccessor clase que implementa la interfaz dbaccess. Para utilizar la interfaz correctamente, usted tiene que abrir la base de datos y después establecer una consulta. Puedes poner estas reglas en un diagrama de estado para indicar el protocolo que se debe seguir al utilizar la interfaz.

Diagramas de estado regulares no te ayudan con las interfaces porque las interfaces no describen el comportamiento de la aplicación que acaba de declarar lo que las operaciones de la clase debe realizar. Todo depende de la clase para especificar la implementación de una interfaz. Por otro lado una máquina de estado de protocolo le permite declarar qué operaciones pueden suceder y el orden en que pueden ocurrir sin tener que decir nada acerca de la implementación comportamiento.

La figura 1 muestra la interfaz dbaccess unido al DatabaseAccessor de clase la clase DatabaseAccessor debe ajustarse a la secuencia de la operación (es decir, el protocolo) de la interfaz dbaccess: La apertura, cierre, consulta, búsqueda, cancelar, crear y operaciones de matar debe ser implementado en el orden especificado por el protocolo del interfaz de dbaccess (mostrado en la Figura 2).

Dibuja una máquina de estados del protocolo de la misma forma de dibujar cualquier otra máquina de estados. Recuerde, sin embargo, a seguir algunas reglas especiales:

• Los estados pueden tener nombres, pero no pueden mostrar las acciones de entrada, las acciones de salida, las acciones internas, o realizar actividades.

• Transiciones muestran las operaciones, pero no acciones o enviar eventos (como diagramas de estado regulares CAN).

• Las transiciones pueden tener condiciones previas y poscondiciones muestran entre corchetes [], como en el siguiente ejemplo:

• [queryStatement lt;> nula] consulta / [conjunto Comarea]

• A condición previa establece lo que debe ser verdad antes de que el objeto puede pasar de un estado a otro. En este ejemplo, cuando un objeto que se ajusta a la interfaz DBaccessor recibe la operación de consulta, el atributo queryStatement se comprueba para ver si es nulo. Si el objeto está en el estado abierto, y la queryStatement no es nulo entonces las transiciones de objetos al estado consultando.

• A postcondition establece lo que debe ser verdad una vez que el objeto completa su transición y ahora está en un nuevo estado. En este ejemplo, cuando un objeto que se ajusta a la interfaz DBaccessor hace una transición exitosa al estado siendo consultado, eso significa que el postcondition ahora debe ser verdad - la Comarea se establece.

• Dibuja tu máquina de estados del protocolo como un grupo de subestados dentro de un marco grande.

• Usted debe nombrar a la máquina de estados del protocolo como lugar tal- el protocolo de palabras clave entre llaves {} al lado del nombre.

El diagrama de la Figura 2 muestra una máquina de estado de protocolo para la interfaz DBaccessor. Cualquier clase de acuerdo con la interfaz dbaccess debe implementar la máquina de estados del protocolo. Usted puede mostrar la aplicación de la máquina de estados del protocolo como una máquina de estado regular con todas las acciones y comportamientos de actividad tirado. De esa manera es claro para otros desarrolladores de cómo va a implementar el protocolo para una clase específica en su diseño.

Diagramas de estado no tienen el propósito de mostrar el flujo de datos de un paso a otro proceso. En su lugar, se supone que deben mostrar donde el flujo de control pasa cuando algún comportamiento ocurre. No deje que su diagrama de estado mutar en un diagrama de flujo de datos.