Elaborar o diagrama da máquina de estados

Prévia do material em texto

ANÁLISE E 
PROJETO DE 
SISTEMAS
Cleverson Ledur
Elaborar diagrama de 
máquina de estados
Objetivos de aprendizagem
Ao final deste texto, você deve apresentar os seguintes aprendizados:
 � Reconhecer os conceitos básicos sobre o diagrama.
 � Identificar as relações entre os estados da solução.
 � Elaborar o diagrama de máquina de estados adequadamente.
Introdução
O diagrama de máquina de estados é um dos diagramas disponíveis na 
UML para a modelagem dos aspectos dinâmicos de sistemas. Assim como 
o diagrama de sequência, o diagrama de máquina de estados muitas 
vezes baseia-se em um caso de uso descrito e apoia-se no diagrama 
de classes. Nele, são definidos os estados e transições destes estados 
para obter, de forma clara, os possíveis estados que um objeto pode ter 
durante o seu tempo de vida. 
Neste texto, você vai conhecer o diagrama de máquina de estados, 
seus elementos e os principais conceitos em torno desta ferramenta 
da UML. Também vai ver as transações que podem ocorrer entre os 
estados, elementos de escolha e junção, barras de sincronização e, por 
fim, as informações essenciais para que você consiga criar um diagrama 
de forma adequada. 
Conceitos básicos
O diagrama de máquina de estado UML é uma percepção melhorada do 
conceito matemático de um autômato finito, conforme expresso na notação 
Unified Modeling Language (UML). Os conceitos por trás disso são sobre 
organizar a forma como um dispositivo, programa de computador ou outro 
processo (muitas vezes técnico) funciona de forma que uma entidade ou cada 
uma de suas subentidades esteja exatamente em um dos vários estados possí-
veis e onde estejam definidas entre esses estados (LILIUS; PALTOR, 1999).
A máquina de estado UML é uma variante baseada em objetos do conjunto 
de estados de Harel, adaptada e estendida pela UML. O objetivo das máquinas 
de estado UML é superar as principais limitações das máquinas tradicionais 
de estados finitos, mantendo seus principais benefícios. Os gráficos de estados 
UML introduzem os novos conceitos de estados hierarquicamente aninhados 
e regiões ortogonais, ao mesmo tempo, que estendem a noção de ações. As 
máquinas de estado UML têm as características das máquinas Mealy e das 
máquinas Moore. Elas suportam as ações que dependem do estado do sistema 
e do evento desencadeante, como em máquinas Mealy, além de ações de 
entrada e saída, que estão associadas a estados em vez de transições, como 
em máquinas Moore.
O termo máquina de estado UML pode se referir a dois tipos de máquinas 
de estado: máquinas de estado comportamental e máquinas de estado de 
protocolo. As máquinas de estado comportamental podem ser usadas para 
modelar o comportamento de entidades individuais, por exemplo, instâncias 
de classe. As máquinas de estado de protocolo são usadas para expressar 
protocolos de uso e podem ser usadas para especificar os cenários de uso legal 
de classificadores, interfaces e portas (GUEDES, 2008).
Máquina de estado
Muitos sistemas de software são conduzidos por eventos, o que significa que 
eles esperam continuamente a ocorrência de algum evento externo ou interno, 
como um clique do mouse, um botão pressionado, um horário ou a chegada de 
um pacote de dados. Depois de reconhecer o evento, esses sistemas reagem 
ao realizar a computação apropriada, que pode incluir manipular ou gerar 
eventos que desencadeiam outros componentes de software internos. Uma 
vez que o tratamento de eventos está completo, o sistema volta a aguardar o 
próximo evento.
A resposta a um evento, geralmente, depende do tipo de evento e do estado 
interno do sistema, e pode incluir uma mudança de estado que leva a uma 
transição de estado. O padrão de eventos, estados e transições de estados entre 
esses estados podem ser abstraídos e representados como uma máquina de 
estados finitos (FSM).
A UML preserva a forma geral dos diagramas de estados tradicionais. Os 
diagramas de máquina de estado UML são grafos direcionados nos quais os 
Elaborar diagrama de máquina de estados2
nós indicam estados e conectores indicam transições de estado. Por exemplo, 
a Figura 1 mostrará um diagrama de estado UML correspondente à máquina 
de estado do teclado do computador. Em UML, os estados são representados 
como retângulos arredondados rotulados com nomes de estados. As transi-
ções, representadas como setas, são rotuladas com os eventos desencadeantes 
seguidos, opcionalmente, pela lista de ações executadas. A transição inicial 
é originada do círculo sólido e especifica o estado padrão quando o sistema 
começa pela primeira vez. Todo diagrama de estados deve ter uma transição 
que não deve ser rotulada, uma vez que não é desencadeada por um evento. 
A transição inicial pode ter ações associadas. Veja na Figura 1, o exemplo de 
diagrama de máquina de estados para uma porta.
Figura 1. Exemplo de diagrama de máquina de estados de uma porta.
Aberta Fechada
Fechar [Entrada Vazia]
Abrir
Trancada
Destrancar Trancar
Eventos
Um evento é algo que acontece e afeta o sistema. Estritamente falando, na 
especificação UML, o termo evento refere-se ao tipo de ocorrência e não a 
qualquer instância concreta dessa ocorrência. Por exemplo, digitar uma tecla 
CTRL no seu teclado é um evento para o teclado, mas cada pressionar da tecla 
não é um evento, e sim, uma instância concreta do evento CTRL.
Um evento pode ter parâmetros associados, permitindo que a instância do 
evento transmita não apenas a ocorrência de algum incidente interessante, mas, 
também, informações quantitativas sobre essa ocorrência. Já uma ocorrência de 
3Elaborar diagrama de máquina de estados
evento ultrapassa a ocorrência instantânea que o gerou e pode transmitir essa 
ocorrência para uma ou mais máquinas de estado. Uma vez gerada, a instância 
do evento passa por um ciclo de vida de processamento que pode consistir em 
até três estágios. Primeiro, a instância do evento é recebida quando aceita e 
aguarda o processamento, por exemplo, é colocado na fila de eventos. Mais 
tarde, a instância do evento é despachada para a máquina de estado, nesse 
ponto ele se torna o evento atual. Finalmente, é consumido quando a máquina 
de estado finaliza o processamento da instância do evento. 
Condições guard
As condições guard são expressões booleanas avaliadas dinamicamente com 
base no valor das variáveis de estado estendido e dos parâmetros do evento. 
As condições guard afetam o comportamento de uma máquina de estado ao 
ativar ações ou transições quando elas avaliam TRUE e desativando-as quando 
avaliam FALSE. A necessidade de condições guard é a consequência imediata 
de adicionar variáveis de estado de memória expandida ao formalismo da 
máquina de estado. Usado com moderação, variáveis de estado estendido e 
condições guard constituem um poderoso mecanismo que pode simplificar 
os projetos. 
Ações e transições
Quando uma instância de evento é despachada, a máquina de estado responde 
executando ações, como mudar uma variável, executar E / S, invocar uma 
função, gerar outra instância de evento ou mudar para outro estado. Qualquer 
valor de parâmetro associado ao evento atual está disponível para todas as 
ações diretamente causadas por esse evento.
Alternar de um estado para outro é chamado de transição de estado, e o 
evento que causa isso, é chamado de evento desencadeante ou simplesmente 
o gatilho. Em máquinas de estado prolongado, uma transição pode ter uma 
proteção, o que significa que a transição pode disparar somente se o controle 
for verdadeiro. Um estado pode ter muitas transições em resposta ao mesmo 
gatilho, desde que tenham guards que não sobrevivam. No entanto, essa 
situação pode criar problemas na sequência de avaliação dos guards, quando 
Elaborar diagrama de máquina de estados4
ocorre o gatilho comum. A especificação UML intencionalmente não estipula 
nenhuma ordem específica. Em vez disso, a UML coloca o fardo no designer 
para criar guards de forma que a ordem de sua avaliação não importe. Pra-
ticamente, isso significaque as expressões de condições guard não devem 
ter efeitos colaterais, pelo menos, nenhum que altere a avaliação de outros 
guards com o mesmo gatilho.
Modelo de execução run-to-completion
Todos os formalismos de máquinas de estado, incluindo máquinas de estado 
UML, assumem universalmente que uma máquina de estado conclua o pro-
cessamento de cada evento antes que ele possa começar a processar o próximo 
evento. Esse modelo de execução é chamado de executar até a conclusão ou 
RTC.
No modelo RTC, o sistema processa eventos em etapas RTC discretas e in-
divisíveis. Novos eventos recebidos não podem interromper o processamento do 
evento atual e devem ser armazenados (normalmente, em uma fila de eventos) 
até que a máquina de estado fique novamente ociosa. Essas semânticas evitam 
completamente problemas de concorrência interna em uma única máquina de 
estado. O modelo RTC também contorna o problema conceitual de processar 
ações associadas a transições, em que a máquina de estado não está em um 
estado bem definido durante a duração da ação. Durante o processamento do 
evento, o sistema não responde, de modo que o estado mal definido durante 
esse período não tem significado prático.
No entanto, note que o RTC não significa que uma máquina de estado 
tenha que monopolizar a CPU até o passo RTC estar completo. A restrição 
de preempção aplica-se, apenas, ao contexto de tarefa da máquina de estado 
que já está ocupada processando eventos. Em um ambiente multitarefa, outras 
tarefas (não relacionadas ao contexto da tarefa da máquina de estado ocupada) 
podem estar em execução, possivelmente, antecipando a máquina de estado 
atualmente em execução. Enquanto outras máquinas de estado não compar-
tilharem variáveis ou outros recursos entre si, não há riscos de concorrência.
A principal vantagem do processamento RTC é a simplicidade. A maior 
desvantagem é que a capacidade de resposta de uma máquina estatal é de-
terminada pelo seu passo RTC mais longo. Alcançar pequenos passos RTC 
geralmente podem complicar, significativamente, os projetos em tempo real.
5Elaborar diagrama de máquina de estados
Relações entre estados e diagramação
Agora que você viu alguns conceitos sobre máquinas de estados e diagramação, 
irá entender como tudo isso é representado no diagrama de máquina de estados. 
Inicialmente, você vai aprender os elementos do diagrama de estados e como 
eles se relacionam para expressar as informações de estados de classes/objetos.
Estados
Um estado é denotado por um retângulo redondo com o nome estado escrito 
dentro dele (OBJECT MANAGEMENT GROUP, 2007). Na Figura 2, há uma 
imagem que mostra um estado. 
Figura 2. Exemplo 
de um elemento de 
estado.
Estado
Estados iniciais e finais
O estado inicial é denotado por um círculo preto preenchido e pode ser rotu-
lado com um nome. Enquanto que o estado final é denotado por um círculo 
com um ponto interno e também pode ser rotulado com um nome. A Figura 
3 apresenta um estado inicial (OBJECT MANAGEMENT GROUP, 2007). 
Já na Figura 4, pode ser notado um estado final. E na Figura 5 é mostrado o 
uso dos dois elementos no diagrama.
Elaborar diagrama de máquina de estados6
Figura 3. Exemplo de 
um elemento inicial.
Figura 4. Exemplo de 
um elemento final.
 
Figura 5. Exemplo de uso de elemento inicial e final.
Vivo
/ Criar / Destruir
Transições
As transições de um estado para outro são indicadas por linhas com pontas 
de seta (OBJECT MANAGEMENT GROUP, 2007). Uma transição pode ter 
um gatilho, uma proteção e um efeito, conforme abaixo. A Figura 6 apresenta 
o uso de uma transição. Já na Figura 7 você pode ver um pequeno exemplo 
do uso de gatilhos:
7Elaborar diagrama de máquina de estados
Figura 6. Exemplo de transição.
Estado
Figura 7. Exemplo de uso de transições e gatilhos.
Gatilho (Trigger) [Guard] / Efeito
Estado DestinoEstado Origem
Trigger ou gatilho é a causa da transição, que pode ser um sinal, um 
evento, uma mudança em alguma condição ou a passagem do tempo. Guard 
é uma condição que deve ser verdadeira para que o gatilho cause a transição 
(OBJECT MANAGEMENT GROUP, 2007). Já efeito é uma ação que será 
invocada diretamente no objeto que possui a máquina de estado como resultado 
da transição.
Autotransições
Um estado pode ter uma transição que retorna a si mesma, como no diagrama 
a seguir. Isso é mais útil quando um efeito está associado à transição. Veja na 
Figura 8 um exemplo de autotransição:
Figura 8. Exemplo de uma 
autotransição.
Aguardando
após 2 segundos / input
Elaborar diagrama de máquina de estados8
Pseudo-estado de escolha
Um pseudo-estado de escolha é mostrado como um diamante em uma transição 
que chega e duas ou mais transições que saem. O diagrama a seguir mostra que 
o estado de cada estado, após o pseudo-estado de escolha, depende do formato 
de mensagem selecionado durante a execução do estado anterior (OBJECT 
MANAGEMENT GROUP, 2007). A Figura 9 apresenta um exemplo de uso 
do elemento escolha.
Figura 9. Exemplo de uso de um elemento de escolha.
Selecionando
Formato de 
Mensagem
Criando Mensagem de Voz
Criando Mensagem SMS
Criando Mensagem Fax
[Voz]
[SMS]
[Fax]
Pseudo-estado de junção
Os pseudo-estados de junção são usados para encadear várias transições. Uma 
junção única pode ter uma ou mais transições entrantes. Um conceito guard 
pode ser aplicado a cada transição. Assim, as junções são semânticas, uma 
junção que divide uma transição entrante em múltiplas transições de saída 
realiza um ramo condicional estático, ao contrário de um pseudo-estado de 
escolha que realiza um ramo condicional dinâmico (OBJECT MANAGEMENT 
GROUP, 2007). A Figura 10 apresenta o elemento de junção sendo utilizado 
no diagrama de máquina de estados.
9Elaborar diagrama de máquina de estados
Figura 10. Exemplo de uso de um elemento de pseudo-estado de escolha.
State0
State1
[se condição 2 ]
[se condição 3 ]
[se condição 1 ]
Considerações importantes para criação de 
diagrama
Até o momento, você viu os conceitos e principais elementos do diagrama de 
estados. Mas ainda permanece a pergunta, quando realmente se precisa usar 
um diagrama de estados em um projeto de software?
 � Os diagramas de estado são muito bem empregados para descrever o 
comportamento de um objeto por meio de vários casos de uso. Eles 
permitem que os estados que um objeto em específico sejam descritos, 
assim, consegue-se entender e especificar o comportamento desse 
objeto conforme são realizadas diferentes ações (LARMAN, 2002). 
 � Os diagramas de máquina de estado não são bem empregados quando 
se precisa descrever um comportamento que envolve vários objetos 
em colaboração. Isso porque a descrição de apenas um objeto já torna 
o diagrama moderadamente complexo quando existem diversas con-
dições e ações. Agora, imagine adicionar um conjunto de objetos no 
mesmo diagrama, interagindo entre si. Possivelmente, o diagrama ficaria 
bastante poluído e com muitos elementos que dificultariam a leitura. 
 � O diagrama de máquina de estados não deve ser descrito para todas 
as classes do sistema, apenas para as quais ele ajude a compreender o 
comportamento. Deste modo, não precisamos é necessário criar uma 
infinidade de diagramas de máquina de estados para cada classe no 
projeto. A utilização dele é interessante para descrever o comporta-
Elaborar diagrama de máquina de estados10
mento daquelas classes em específico, que são estritamente necessárias 
(DRUSINSKY, 2006). 
 � Quando um objeto possui muitos conjuntos concorrentes de compor-
tamento, gerando vários diagramas de estado concorrentes, convém 
dividir este objeto em objetos separados. Assim, é possível facilitar a 
leitura desse diagrama, já que se pode fazê-la de forma particionada e 
modularizada (DRUSINSKY, 2006).
Em geral, as máquinas de estado são usadas para modelar o comportamento 
de objetos ao longo de sua vida útil e são necessárias quando os objetos têm 
comportamento dependente de estados. Dentro do contexto de análise e pro-
jetode software, os objetos que podem ter máquinas de estado são classes, 
subsistemas, casos de uso e interfaces.
Mas, nem todo objeto exige máquinas de estado. Por exemplo, se o com-
portamento de um objeto for simples, não variando muito de estado, a máquina 
de estado não será muito útil no projeto.
A modelagem da vida útil de um objeto envolve três itens: 
 � Especificação dos eventos aos quais o objeto pode responder.
 � Resposta a esses eventos. 
 � Impacto do comportamento passado no presente.
A modelagem da vida útil de um objeto também envolve a definição da 
ordem em que o objeto pode responder coerentemente a eventos, iniciado no 
momento da criação do objeto e permanecendo até sua a destruição.
DRUSINSKY, D. Modelling and verification using UML statecharts. Atlanta: Elsevier, 2006.
GUEDES, G. T. A. UML: uma abordagem prática. São Paulo: Novatec, 2008.
LARMAN, C. Utilizando UML e padrões. Porto Alegre: Bookman, 2002. 
LILIUS, J.; PALTOR, I. P. The semantics of UML state machines.Turku: Turku Centre for 
Computer Science, 1999.
OBJECT MANAGEMENT GROUP. UML Infrastructure Specification 2.1. Needham, 2007.
11Elaborar diagrama de máquina de estados
Leituras recomendadas
BOOCH, G.; RUMBAUGH, J.; JACOBSON, I. UML: guia do usuário. Rio de Janeiro: Elsevier 
Brasil, 2006.
DOUGLASS, B. P. UML statecharts. Embedded, New York, v. 12, n. 1, p. 22-42, 1999.
FOWLER, M. UML Essencial: um breve guia para linguagem padrão. Porto Alegre: 
Bookman, 2014.
IBM. Criando Diagramas de Máquina de Estado. New York, 2017. Disponível em: 
<https://www.ibm.com/support/knowledgecenter/pt-br/SS5JSH_9.1.2/com.ibm.
xtools.modeler.doc/topics/twrksmd.html>. Acesso em: 8 set. 2017.
SAMEK, M. A crash course in UML state machines. Embedded, New York, Mar. 2009.
SAMEK, M. Practical UML Statecharts in C/C ++: event-driven programming for Embe-
dded Systems. 2. ed. Oxford: Newnes, 2008.
Elaborar diagrama de máquina de estados12