Máquinas de estado del protocolo de construcción en uml 2
Cuando se quiere mostrar la secuencia de eventos de un objeto reacciona a - y el comportamiento resultante - que 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 principales, acciones de salida, y hacer actividades. La mayoría de los diagramas de estados 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 una protocolo de evento. En UML 2, puede mostrar los protocolos de eventos mediante diagramas 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 comportamiento para todos los objetos de una clase. A veces, sin embargo, que desea mostrar un complejo protocolo (conjunto de normas que rigen la comunicación) al usar una interfaz para una clase. Por ejemplo, cuando se está diseñando clases que tienen acceso a una base de datos para su aplicación necesita utilizar 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 un simple clase de acceso de base de datos es el desarrollo de 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 el DatabaseAccessor clase que implementa la interfaz dbaccess. Para utilizar la interfaz correctamente, usted tiene que abrir la base de datos y entonces establecer una consulta. Usted puede poner estas reglas en un diagrama de estado para indicar el protocolo que se debe seguir al usar la interfaz.
Video: Diagrama de Estados
Figura 1: Diagrama de clases con interfaz dbaccess.
diagramas de estado regulares no le ayudan con 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 estados protocolo que permite declarar qué operaciones pueden ocurrir y el orden en que pueden ocurrir sin tener que decir nada sobre el comportamiento aplicación.
La Figura 1 muestra la interfaz dbaccess unido a la DatabaseAccessor de clase de la clase DatabaseAccessor debe ajustarse a la secuencia de operación (es decir, el protocolo) de la interfaz dbaccess: El abrir, cerrar, consulta, búsqueda, cancelar, crear, y matar a las operaciones debe implementarse en el orden especificado por el protocolo del interfaz dbaccess (que se muestra en la Figura 2).
Video: Bobinadora Semiautomática ByS-01
Figura 2: DBaccessor máquina de estado de protocolo.
Se dibuja una máquina de estado de 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 principales, acciones de salida, las acciones internas, o realizar actividades.
- Las transiciones muestran las acciones de operaciones, pero no envían o eventos (como diagramas de estado regulares CAN).
- Las transiciones pueden tener condiciones previas y condiciones posteriores se muestran en corchetes [], como en el siguiente ejemplo:
• [queryStatement lt; gt; nula] consulta / [conjunto Comarea]
• UN condición previa establece qué debe cumplir 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 para el estado consultado.
• UN postcondition establece qué debe cumplir 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 consultado, eso significa que el postcondition debe ahora ser cierto - el Comarea se establece.
- Se dibuja la máquina de estado de protocolo como un grupo de subestados dentro de un marco grande.
- Debe nombrar la máquina de estado de protocolo como tal- lugar el protocolo de palabras clave entre llaves {} junto al nombre.
Video: Curso Bitbloq 2 - extras - Máquinas de estado
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 estado de protocolo. 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 esta manera es claro para otros desarrolladores cómo va a implementar el protocolo para una clase específica en su diseño.
diagramas de estado no son para mostrar el flujo de datos de una etapa de proceso a otra. En su lugar, se supone que deben mostrar donde el flujo de controlar pasa cuando sucede algún comportamiento. No deje que su diagrama de estado mutar en un diagrama de flujo de datos.