Construção do Protocolo de Máquinas de Estado em UML 2

Quando você quer mostrar a sequência de eventos um objeto reage a - e o comportamento resultante - Para usar a notação UML que cria diagramas de estados comportamentais (também conhecido como máquinas): Esses diagramas de estado têm pares / ação do evento, ações de entrada, ações de saída, e fazer atividades. A maioria de seus diagramas de estado usar essas características-na verdade, eles são máquinas de estados comportamentais.

Às vezes, porém, você só quer mostrar uma sequência específica de eventos que seu objeto responde a - e quando ele pode responder - sem ter que mostrar o seu comportamento. Tal sequência especificada é chamado um Protocolo evento. Na UML 2, você pode mostrar os protocolos de eventos pela diagramação máquinas de estado de protocolo. Estas diferem das máquinas de estados comportamentais e têm usos especiais.

Normalmente, você deve usar diagramas de estado regulares para mostrar sequências internas de comportamento para todos os objetos de uma classe. Às vezes, porém, você quer mostrar um protocolo complexo (conjunto de regras que regem a comunicação) ao utilizar uma interface para uma classe. Por exemplo, quando você está projetando classes que acessam um banco de dados para a sua aplicação você precisa usar operações comuns, como abrir, fechar e consultar um banco de dados. Mas estas operações devem ser chamados na ordem certa. Não é possível consultar o banco de dados antes de abri-lo.

Uma solução para criar uma classe de acesso de banco de dados simples é desenvolver uma classe DatabaseAccessor com uma interface dbAccess como mostrado na Figura 1. Mas a interface dbAccess tem um protocolo complexo que regula o seu uso por causa das regras que regem a comunicação entre qualquer outro objeto eo DatabaseAccessor classe que implementa a interface dbAccess. Para utilizar a interface corretamente, você tem que abrir o banco de dados e então configurar uma consulta. Você pode colocar essas regras em um diagrama de estado para indicar o protocolo que deve ser seguido quando se utiliza a interface.

Figura 1: diagrama de classe com a interface dbAccess.

diagramas de estado regulares não ajudá-lo com interfaces, porque as interfaces não descrevem a implementação comportamento que simplesmente declarar as operações que a classe deve executar. É até a classe para especificar a implementação de uma interface. Por outro lado, uma máquina de estado de protocolo permite que você declare as operações que podem acontecer e ordem em que pode acontecer sem ter que dizer nada sobre a implementação comportamento.

A Figura 1 mostra a interface dbAccess anexado ao DatabaseAccessor de aula da classe DatabaseAccessor deve estar de acordo com a sequência de operação (isto é, o protocolo) da interface dbAccess: A abrir, fechar, consulta, buscar, cancelar, criar e matar as operações devem ser implementado na ordem especificada pela interface de protocolo do dbAccess (mostrado na Figura 2).

Figura 2: DBaccessor máquina de estado de protocolo.

Você desenha uma máquina de estado de protocolo da mesma maneira como você chamar qualquer outra máquina de estado. Lembre-se, no entanto, seguir algumas regras especiais:

• Membros podem ter nomes, mas não pode mostrar ações de entrada, ações de saída, ações internas, ou fazer atividades.
• Transições mostrar ações operações, mas não ou enviar eventos (como diagramas de estado regular pode).
• Transições podem ter pré-condições e pós-condições indicadas entre colchetes [], como no exemplo a seguir:

# 8226; [queryStatement lt;> nulo] query / [set comArea]

# 8226; UMA condição prévia afirma que deve ser verdadeiro antes que o objeto pode fazer a transição de um estado para outro. Neste exemplo, quando um objeto que está em conformidade com a interface DBaccessor recebe a operação de consulta, o atributo queryStatement é verificado para ver se é nulo. Se o objeto está no estado aberto, e os queryStatement não é nulo, em seguida, o objeto passa para o estado consultado.

# 8226; UMA postcondition afirma que deve ser verdadeiro uma vez que o objeto completa sua transição e está agora em um novo estado. Neste exemplo, quando um objecto que está em conformidade com a interface DBaccessor faz uma transição para o estado consultado, isso significa que a pós deve agora ser verdadeiro - o comArea é definido.

• Você chamar a máquina de estado de protocolo como um grupo de subestados dentro de um quadro grande.
• Você deve nomear a máquina de estado de protocolo como o lugar such- o protocolo de palavra-chave em chaves {} ao lado do nome.

O diagrama na Figura 2 mostra uma máquina de estado de protocolo para a interface DBaccessor. Qualquer classe de acordo com a interface dbAccess deve implementar a máquina de estado de protocolo. Você pode mostrar a implementação da máquina de estado de protocolo como uma máquina de estado regular com todas as ações e comportamentos de atividade fique. Dessa forma, é claro, para outros desenvolvedores como você vai implementar o protocolo para uma classe específica em seu projeto.

Os diagramas de estado não são destinadas a mostrar o fluxo de dados a partir de um passo do processo para outro. Em vez disso, eles estão supostamente para mostrar onde o fluxo de ao controle vai quando algum comportamento acontece. Não deixe que o seu diagrama de estado se transformar em um diagrama de fluxo de dados.