Construction des machines d'état de protocole à UML 2

Lorsque vous voulez montrer la séquence des événements d'un objet réagit à - et le comportement résultant - vous utilisez la notation UML qui crée schémas comportementaux de l'Etat (aussi connu comme machines): Ces diagrammes d'états ont événements paires / d'action, les actions d'entrée, les actions de sortie, et de faire des activités. La plupart de vos diagrammes d'états utilisent ces Caractéristiques- En effet, ils sont machines de comportement de l'Etat.

Parfois, cependant, vous voulez juste pour montrer une séquence d'événements spécifié que votre objet répond à - et quand il peut répondre - sans avoir à montrer son comportement. Une telle séquence spécifiée est appelée une protocole d'événement. Dans UML 2, vous pouvez afficher les protocoles d'événements en schématisant machines d'état de protocole. Elles diffèrent des machines de comportement de l'Etat et avoir des utilisations spéciales.

Normalement, vous devriez utiliser des diagrammes réguliers de l'Etat pour montrer les séquences internes de comportement pour tous les objets d'une classe. Parfois, cependant, vous voulez montrer un protocole complexe (ensemble de règles régissant la communication) lorsque vous utilisez une interface pour une classe. Par exemple, lorsque vous concevez des classes qui accèdent à une base de données pour votre application, vous devez utiliser les opérations courantes, comme ouvrir, fermer et d'interroger une base de données. Mais ces opérations doivent être appelés dans le bon ordre. Vous ne pouvez pas interroger la base de données avant de l'ouvrir.

Une solution à la conception d'une classe d'accès de base de données simple est de développer une classe de DatabaseAccessor avec une interface dbAccess comme le montre la figure 1. Mais l'interface dbAccess a un protocole complexe qui régit son utilisation à cause des règles régissant la communication entre tout autre objet et l'DatabaseAccessor classe implémentant l'interface dbAccess. Pour utiliser l'interface correctement, vous devez ouvrir la base de données et puis mettre en place une requête. Vous pouvez mettre ces règles dans un diagramme d'état pour indiquer le protocole qui doit être suivie lors de l'utilisation de l'interface.

Diagrammes d'états réguliers ne vous aident pas avec des interfaces parce interfaces ne décrivent pas la mise en œuvre de comportement qu'ils déclarent exactement ce que les opérations de la classe doit effectuer. Il appartient à la classe de préciser la mise en œuvre d'une interface. D'autre part, une machine d'état de protocole vous permet de déclarer les opérations qui peuvent se produire et l'ordre dans lequel ils peuvent se produire sans avoir à dire quoi que ce soit à propos de la mise en œuvre de comportement.

La figure 1 montre l'interface dbAccess attaché à la DatabaseAccessor de classe de la classe DatabaseAccessor doit être conforme à la séquence de fonctionnement (qui est, le protocole) de l'interface dbAccess: L'ouverture, fermeture, requête, récupérer, d'annuler, de créer, et les opérations de tuer doit être mise en œuvre dans l'ordre spécifié par le protocole de l'interface dbAccess (représenté sur la figure 2).

Vous dessinez une machine d'état de protocole de la même manière dont vous dessinez une autre machine d'état. Rappelez-vous, toutefois, de suivre quelques règles particulières:

• Unis peuvent avoir des noms, mais ne peuvent pas montrer les actions d'entrée, les actions de sortie, des actions internes, ou faire des activités.

• Transitions montrent opérations, mais pas les actions ou envoient des événements (comme les diagrammes d'états réguliers CAN).

• Transitions peuvent avoir des conditions préalables et postconditions indiquées entre crochets [], comme dans l'exemple suivant:

# 8226- [queryStatement lt;> null] requête / [jeu de Comarea]

# 8226- Une condition préalable Unis ce doit être vrai avant que l'objet ne peut passer d'un état à un autre. Dans cet exemple, quand un objet conforme à l'interface DBaccessor reçoit l'opération de requête, l'attribut queryStatement est vérifié pour voir si elle est nulle. Si l'objet est à l'état ouvert, et l'queryStatement est non nulle alors les transitions de l'objet à l'état interrogé.

# 8226- Une postcondition Unis ce doit être vrai, une fois l'objet achève sa transition et est maintenant dans un état neuf. Dans cet exemple, quand un objet conforme à l'interface DBaccessor fait une transition réussie vers l'état interrogé, cela signifie que la postcondition doit maintenant être vrai - l'Comarea est réglé.

• Vous dessinez votre protocole machine d'état comme un groupe de sous-états au sein d'un grand cadre.

• Vous devez nommer la machine d'état de protocole que le lieu such- le protocole de mot-clé dans les accolades {} à côté du nom.

Le schéma de la figure 2 montre une machine d'état de protocole pour l'interface DBaccessor. Toute classe conforme à l'interface dbAccess doit mettre en œuvre la machine d'état de protocole. Vous pouvez afficher la mise en œuvre de la machine d'état de protocole comme une machine régulière de l'état de toutes les actions et les comportements d'activité jetés. De cette façon, il est clair à d'autres développeurs comment vous allez mettre en œuvre le protocole pour une classe spécifique dans votre conception.

Les diagrammes d'états ne sont pas destinées à montrer le flux de données d'une étape de procédé à l'autre. Au lieu de cela, ils sont censés montrer où le flux de contrôle va quand certains comportements qui se passe. Ne laissez pas votre diagramme d'état muter en un diagramme de flux de données.