diagrama+de+estado

Prévia do material em texto

Diagrama 
de estado
Objetivos de aprendizagem: nesta unidade 
vamos aprender sobre o diagrama de estado, em 
que terão alguns diagramas simples e compostos, 
e mostrar as diferenças entre elas.
Unidade
3
 Introdução
O diagrama de estado é uma representação do estado ou situação que 
o objeto se encontra ou pode se encontrar no decorrer do processamento 
do sistema. O diagrama de estado representa uma máquina de estado que 
mostra como um objeto se comporta quando recebe eventos ou estímulos 
externos. Os elementos de modelo cujos comportamentos não variam com 
o seu estado não precisam de máquinas de estado para descrever seus 
comportamentos. Geralmente esses elementos são classes passivas cuja 
responsabilidade principal é gerenciar dados.
Esse diagrama é uma técnica conhecida para descrever o comporta-
mento de um sistema. Ele mostra como um objeto age e responde quando 
recebe eventos externos.
Existem três tipos de estados: estado simples, estado composto e 
submaquina de estado.
 Estado simples
Um estado representa uma ação executada, uma condição satisfeita 
ou uma situação estática de espera que um objeto se encontra durante 
sua existência ou durante o processo de execução de alguma atividade.
No Quadro 3.1 é mostrado um diagrama de estado simples em que 
temos como exemplo o telefone. Note que temos também nesse diagrama 
o estado, evento e a transição.
92 Análise de sistemas III
Quadro 3.1 Diagrama de estado simples
Um evento é uma ocorrência digna de nota. Como exemplo, o apare-
lho é tirado do gancho. O estado é a condição do objeto em determinado 
momento no tempo; como exemplo, o telefone está ocioso após ter sido 
colocado no ganho. A transição é um relacionamento entre dois estados. 
Quando um evento ocorre, o objeto muda do estado anterior para o estado 
subsequente. Quando o evento ocorre, o telefone muda do estado ocioso 
para o estado ativo.
Nas versões anteriores da UML, a semântica do estado não foi efetiva-
mente alterada.
 Diagrama composto
O diagrama de estado composto é organizado em regiões onde são 
executadas em paralelo. No Quadro 3.2 é dado um exemplo de diagrama 
de estado composto. Também pode ocorrer de termos um diagrama de 
estado em regiões separadas por uma linha tracejada na vertical ou na 
horizontal, mostrado no Quadro 3.3.
Diagrama de estado 93
Quadro 3.2 Diagrama de Estado Composto
Estado_Simples 2
Estado_Composto
Estado_Simples 1
Quadro 3.3 Diagrama de estado composto com regiões
Diagrama_Composto_Região
94 Análise de sistemas III
 Diagrama submáquina de estado
O diagrama submáquina é equivalente a um estado composto. Mas a 
diferença é que os recursos podem ser reutilizados em vários contextos.
No Quadro 3.4 temos como exemplo um caixa eletrônico bancário.
Quadro 3.4 Diagrama submáquina de estado
VerificaCartão
VerificaTransacao
AceitarCartao
LiberarCartao
LerQuantia Abortado
LiberaCartao
ForaDeServiço
ForadeServico
 Transições
A máquina de estado consiste em estados, vinculados por transições. 
Uma transição é um relacionamento entre dois estados que é disparado 
por algum evento que executa determinadas ações ou avaliações e que 
resulta em um estado final.
A transição é um relacionamento entre dois estados indicando que um 
objeto no primeiro estado executará certas ações e entrará no segundo 
estado quando um evento específico ocorre e determinadas condições fo-
rem satisfeitas. Para que a transição seja acionada, o objeto está no estado 
de origem; após o seu acionamento, o objeto está no estado de destino. 
A transição possui várias propriedades:
 Estado de origem: estado afetado pela transição. Se um objeto esti-
ver no estado de origem, uma transição de saída pode ser acionada 
quando o objeto receber um evento trigger da transição;
Diagrama de estado 95
 Acionador de eventos: o evento torna a transição passível de ser 
acionada quando recebido pelo objeto no estado de origem;
 Condição de guarda: uma expressão booleana é avaliada quando 
a transição é disparada pela recepção do disparador de evento. 
Se o valor for verdadeiro, então é acionada a transição; caso 
seja falso, a transição não será acionada. Se não houver outra 
transição que possa ser disparada pelo mesmo evento, então este 
será perdido;
 Ação: um cálculo que não pode ser dividido, executado, que pode 
agir diretamente sobre o objeto, que possui a maquina de estado e, 
indiretamente em outros objetos visíveis ao objeto. As ações podem 
incluir chamadas de operação, a criação ou a destruição do outro 
objeto ou o envio de um sinal para outro objeto;
 Estado de destino: o estado é ativado após a conclusão da transição.
 Técnicas de modelagem
Geralmente, as máquinas de estado são usadas para modelar o com-
portamento de um objeto em sua vida útil. Elas são necessárias quando os 
objetos dependem de um comportamento do estado. Os objetos podem ser 
classes, subsistemas, casos de uso e interfaces em que podem ter máquinas 
de estado. No caso de sistemas em tempo real, elas são também utilizadas 
para cápsulas e protocolos.
A modelagem da vida útil de um objeto envolve definições no sentido 
de o objeto poder responder coerentemente a eventos iniciados no mo-
mento da criação do objeto até sua destruição. A modelagem da vida útil 
envolve três itens:
 Especificação dos eventos ao qual o objeto pode responder;
 Resposta a esses eventos;
 Impacto do comportamento passado no atual.
 Máquinas de estado abstratas
É uma máquina de estado em que é necessário incluir mais detalhes 
para que possa ser utilizada para finalidades práticas. As maquinas de 
96 Análise de sistemas III
estado abstratas podem ser utilizadas para definir um comportamento 
genérico e reutilizável, em que serão refinados os elementos de modelos 
subsequentes.
 Estudo de caso
No Quadro 3.5 é mostrado o diagrama de estado da classe automóvel. 
O estado do veículo começa em Disponível. O carro pode ir para manu-
tenção e ficar no estado Manutenção. Quando locado, o automóvel fica no 
estado Locado. Também tem o estado Vendido, pois uma locadora sempre 
renova seus carros, mas os dados desse carro quando vendido não podem 
simplesmente desaparecer do banco de dados.
Quadro 3.5 Estudo de caso. Diagrama de estado da classe automóvel
Diagrama de estado 97
Saiba 
Leia no livro de LARMAN, 
Craig. Utilizando UML e pa-
drões. 3. ed. Editora Bookman, 
os textos das páginas 490 a 497.
Para saber 
Segundo o autor Lima, o 
diagrama de Estado tem por 
objetivo facilitar o estudo do 
comportamento do objeto e 
analisar todos os estados pos-
síveis de cada objeto, do modo 
mais abrangente de todo o sis-
tema modelado.
Leia o trecho a seguir extraído de Page-Jones Meilier. Fundamentos 
do desenho orientado a objeto com UML. Ed. Pearson (p. 165-180) 
para aprender mais sobre o tema.
Aprofundando o conhecimento
Diagramas de estado 
O diagrama de estado para uma classe mostra os estados que os objetos 
dessa classe podem assumir e as transições que eles podem fazer de estado 
para estado.1 Acompanhando o trabalho de David Harel e outros (veja Harel, 
1987, ou Henderson-Sellers e Edwards, 1994, como exemplo), os autores da 
UML estenderam a notação básica da transição de estado com, por exemplo, 
estados aninhados. Neste capítulo, descrevo brevemente o diagrama de estado 
básico e, em seguida, exploro algumas elaborações proveitosas sobre ele: a 
utilização de estados aninhados; a incorporação de argumentos de mensa-
gens; a representação de estados concorrentes interagindo; e, finalmente, a 
acomodação de atributos continuamente variáveis no diagrama de estado.2 
 6.1 Diagramas de estado básicos 
Um diagrama de estado é ideal para a modelação de um atributo com as 
duas características a seguir: 
 o atributo possui poucos valores; 
 o atributo tem restrições em transições autorizadas entre esses valores. 
98 Análise de sistemas III
Por exemplo, consideremos a classe ItemComercializável, que contém 
os atributos de instância preçoDeVenda: Dinheiroe condiçãoDeIns-
peçãoAtual: CondiçãoDeInspeção. Há duas diferenças qualitativas 
entre esses atributos: 
1. O atributo preçoDeVenda, por se tratar de uma instância de Di-
nheiro, tem um grande número de valores possíveis, tais como 
US$ 1,98, US$ 4,95, US$ 5,95 e assim por diante. O atributo condi-
çãoDeInspeçãoAtual, por outro lado, tem somente um pequeno 
conjunto de valores possíveis, tais como recebido (acabou de chegar 
do vendedor), sobInspeção (sendo examinado minuciosamente, 
mesmo quando estamos falando), aprovado (passou pelo exame 
mais detalhado do inspetor) e rejeitado (descartado na condição 
de sem valor). 
2. Existe provavelmente pouca restrição empresarial aplicável nas alterações 
permitidas a preçoDeVenda. Em outras palavras, o preçoDeVenda 
de um objeto pode mudar de US$ 4,95 a US$ 5,95 ou de US$ 6,50 a 
US$ 5,99 ou o que for. Todavia, uma condiçãoDeInspeçãoAtual 
não pode mudar diretamente de recebido a aprovado sem passar 
primeiro pelo valor sobInspeção. 
O atributo preçoDeVenda não é um candidato apropriado a ser modelado 
por meio de um diagrama de estado porque ele tem muitos valores possíveis e 
praticamente nenhuma restrição nas transições entre esses valores. O atributo 
condiçãoDeInspeçãoAtual, por outro lado, tem as duas propriedades que 
o tornam ideal para um diagrama de estado. Como já vimos, esse atributo tem 
somente poucos valores possíveis e existem restrições significativas nas transi-
ções de um valor para outro. Um atributo de instância, tal como condição-
DeInspeçãoAtual, com as duas características ideais já listadas, e valores 
que refletem os estados naturais de seu objeto proprietário, é denominado 
atributo de estado. Um atributo de estado é um mecanismo para representar 
os estados de um objeto. 
A Figura 6.1 mostra o diagrama de estado para ItemComercializável.
condiçãoDeInspeçãoAtual. Na figura, cada um dos retângulos contém um 
valor de condiçãoDeInspeçãoAtual e representa o estado de um objeto 
ItemComercializável.3 As setas representam transições entre estados. 
Cada transição é anotada com uma etiqueta de duas partes. O texto acima da 
Diagrama de estado 99
linha descreve um evento, que é normalmente provocado por uma mensagem 
de entrada para o objeto. 
Um evento causa uma transição de um estado para outro. A presença de 
vários eventos acima da linha indica que qualquer um desses eventos pode 
provocar a transição.4 
O texto abaixo da linha descreve a ação que é desencadeada por uma tran-
sição entre estados. Essa ação é normalmente uma mensagem de saída vinda 
do objeto. A presença de várias ações abaixo da linha indica que todas as ações 
são executadas durante a transição. Para algumas transições, possivelmente não 
haverá ações associadas. Na Figura 6.1, mostro apenas um exemplo de ação: 
uma mensagem de saída registrando o fato de que havia um item rejeitado (a 
saber, self) dentro da remessa atual. 
O estado inicial de um diagrama de estado, marcado por um ponto preto 
situado no topo da Figura 6.1, é um estado no qual o objeto não despende 
Figura 6.1 Diagrama de estado para ItemComercializável.
condiçãoDeInspeçãoAtual.
100 Análise de sistemas III
qualquer tempo. Em vez disso, o objeto imediatamente passa para o estado 
inicialmente adquirido em sua geração ou inicialização. Essa transição desde 
o estado inicial normalmente não é etiquetada; se bem que você, se assim o 
desejar, pode etiquetá-la com o evento criador do objeto. 
O estado final de um diagrama de estado, marcado por um ‘olho-de-boi’, 
representa o término da atividade do objeto. Há um exemplo de um estado 
final, na Figura 6.6. (Mais precisamente, como veremos quando examinarmos 
os estados aninhados na próxima seção, o estado final representa o término 
da atividade dentro do estado circundante.) 
O diagrama de estado da UML, que descrevi até o momento, associa ações 
com transições, e é geralmente denominado de convenção de Mealy. Entre-
tanto, a UML também suporta ações associadas com estados; nesse caso, o 
diagrama é denominado convenção de Moore. Eu mostro um exemplo de ações 
em estados no decorrer deste capítulo. Portanto, na UML sempre há algo para 
todos — quer se trabalhe em um ambiente Mealy, Moore, Mearly, Moorly ou 
em qualquer outro local de trabalho. 
 6.2 Estados aninhados 
Nem todos os diagramas de estado são tão simples quanto o da Figura 6.1. 
Alguns diagramas de estado requerem estados internos, aninhados no interior 
de outros estados externos. Como exemplo, vamos considerar os diagramas 
de estado para a classe Máquina, que representa uma máquina de chão de 
fábrica em uma aplicação de controle de fábrica. 
A classe Máquina apresenta dois status: um status de operação atual, re-
presentado pelo atributo statusDeOperação, e um status de manutenção 
atual, representado pelo atributo statusDeManutenção. Conforme exibido 
pela Figura 6.2, statusDeOperação, o status de operação da máquina, 
tem quatro estados: estadoDeEspera, acelerando, funcionando e 
desacelerando. No diagrama de estado, o evento 
when (self.velocidadeReal >= velocidadeDeOperação) 
é um evento de mudança na UML (conhecido em outras abordagens como 
transição booleana ou transição predicativa). Supõe-se que ele ocorra no mo-
mento em que a expressão booleana entre parênteses (após a palavra-chave 
when) se altera de false para true. 
Diagrama de estado 101
Igualmente, na Figura 6.2, a expressão [self.statusDeManutenção = 
Funcionando] 
é conhecida como condição de guarda. A condição de guarda em uma 
transição significa que a transição se realiza somente se a expressão booleana 
entre colchetes for true quando o evento desencadeador ocorrer. Nesse 
exemplo, a máquina só dará partida através do comando do operador se ela 
estiver apta a entrar em funcionamento. 
Isso leva-nos caprichosamente para a Figura 6.3, que mostra os três estados 
de statusDeManutenção, o status de manutenção da máquina: Funcio-
nando, esperandoPorConserto e emConserto. 
Figura 6.2 O diagrama de estado para Máquina.statusDeOperação. 
102 Análise de sistemas III
À primeira vista, Máquina provavelmente aparenta ter doze estados pos-
síveis — três statusDeManutenção multiplicado por quatro statusDeO-
peração. Mas isso não corresponde à realidade se fizermos uma suposição 
razoável de que, para essa específica aplicação, somente uma máquina que 
esteja apta a entrar em funcionamento pode expressivamente acelerar, de-
sacelerar e assim por diante. Dessa forma, existem na realidade apenas seis 
estados legítimos, em razão de os dois atributos anteriormente, statusDeMa-
nutenção e statusDeOperação, não serem mutuamente independentes; 
statusDeOperação apenas tem algum significado quando statusDeMa-
nutenção = Funcionando. 
A Figura 6.4 mostra a combinação dos dois diagramas de estado constan-
tes nas Figuras 6.2 e 6.3, em que o segundo diagrama é aninhado dentro do 
estado Funcionando do primeiro.5 Esse aninhamento dos quatro estados 
status-DeOperação no interior do estado Funcionando ilustra a restri-
ção segundo a qual statusDeOperação somente tem significado quando 
statusDeManutenção = Funcionando. De fato, esse aninhamento 
somente tem utilidade quando há restrições tais como as encontradas entre 
esses diagramas de estado para uma classe. 
Figura 6.3 O diagrama de estado para Máquina.statusDeManutenção.
Diagrama de estado 103
Observe que, agora, o estado aninhado representativo de operabilidade 
indica que a máquina tem tanto o status de operação de operabilidade como 
o de manutenção de Funcionando. Inversamente, já que o estado emCon-
serto não tem qualquer estado aninhado, o status de operação da máquina 
é indefinido quando ela tem o status de manutenção de emConserto. Com 
a adição dessa restrição a nosso modelo, podemos remover a condição de 
guarda [self.status-DeManutenção = Funcionando] da transição 
estadoDeEspera /acelerando exibida na Figura 6.2, porque a transi-
ção somente tem significado para uma máquina que esteja apta a entrar em 
funcionamento.Figura 6.4 O diagrama de estado, combinado ou aninhado, para 
Máquina.statusDeManutenção e Máquina.
statusDeOperação. 
104 Análise de sistemas III
Na Figura 6.4, existem dois símbolos do estado inicial — os pequenos 
pontos pretos. O ponto externo indica que quando um objeto da classe Má-
quina é criado, o valor de statusDeManutenção deve ser inicializado 
para Funcionando. O ponto mais interno significa que, não importando 
quando um objeto da classe Máquina entra no estado Funcionando — 
isto é, sempre que o valor do statusDeManutenção ficar igual a Fun-
cionando —, o valor do statusDeOperação deverá ser inicializado para 
estadoDeEspera. 
A Figura 6.5 mostra parte do diagrama de estado para uma máquina de 
lavar roupa. Bastante semelhante à máquina de fábrica da Figura 6.4, a máquina 
de lavar roupa completa o ciclo dela somente quando estiver funcionando, o 
que no caso dessa máquina de lavar implica que sua tampa esteja fechada. En-
tretanto, há uma diferença crucial entre a máquina de lavar roupa e a máquina 
de fábrica típica: se a tampa da lavadora abrir, e em seguida fechar, ela não 
deverá retornar a seu estado inicial — parada —, mas sim, ao seu estado um 
pouco anterior à abertura da tampa. Em outras palavras, a lavadora deve ser 
capaz de restabelecer o subestado prévio de funcionabilidade quando 
o estado funcionabilidade for reiniciado. 
Para representar isso, a UML segue David Harel quanto ao emprego do 
símbolo de história (history symbol), um H presente no interior de um pequeno 
círculo (veja Harel, 1987). Esse símbolo tem o seguinte significado: “Entrar 
em qualquer subestado que estava ativo por último, mediante a entrada sub-
sequente no estado circundante”. Se o símbolo de história caracteriza uma 
transição para um subestado (como ele fez para parada na Figura 6.5), então 
isso significa que “Entre neste subestado quando da primeira entrada no estado 
circundante”. O símbolo de história pode dessa forma substituir o símbolo do 
estado inicial por um subestado, conforme feito na Figura 6.5. 
 6.3 Estados concorrentes e sincronização 
Esta seção aborda os estados concorrentes que um objeto pode ter e ana-
lisa profundamente o tópico dos estados aninhados. Eu utilizo um exemplo 
corrente de um pedido comercial razoavelmente realista em uma companhia 
chamada Smibley & Futz, Inc. Muito embora a vida de um pedido na Smibley 
& Futz seja bastante complexa, ela ainda constitui uma simplificação do que 
talvez pudesse suportar um pedido em sua companhia. À medida que você 
for lendo, tenha em mente que um pedido real talvez tenha diversos itens em 
um grande número de estados, ou até mesmo itens parciais, quando somente 
uma parcela da quantidade inicial puder ser remetida. 
Diagrama de estado 105
Vamos examinar inicialmente a Figura 6.6, que mostra os estados do sta-
tusDeAutorizaçãoDeCliente de um pedido (o atributo de estado cujos 
valores são movidos principalmente pelo capricho do cliente, em vez de pelas 
decisões da Smibley & Futz). 
Quando um cliente liga para fazer um pedido, a companhia trata o pedido 
como padrão (default), sob a forma de tentativa, estado no qual ele é 
submetido à apreciação possivelmente para uma cotação de preço, mas não, 
pode ser imediatamente efetivado. Assim que o cliente confirma o pedido, 
fato esse que pode ocorrer durante a primeira ligação telefônica, o pedido 
assume o estado confirmado. De acordo com a diretriz de trabalho da S&F, 
esse é o único estado em que pode ocorrer um tipo de processamento real; 
retornaremos ao mesmo em breve. 
Figura 6.5 Estado de MáquinaDeLavarRoupa com história. 
106 Análise de sistemas III
O cliente pode cancelar um pedido a menos que os artigos já tenham sido 
remetidos; portanto, à condição de guarda, [self.statusDeCumprimento 
not= remetido]. Se o cliente cancelar o pedido, este fica — você adivi-
nhou! — cancelado. Conforme mostrado na Figura 6.6, a ação de entrada 
para o estado cancelado é a mensagem self.cancelar, acarretando 
que o objeto Pedido desfaça qualquer alocação de estoque porventura feito 
para ele.6 Repare que os pedidos “do tipo tentativa” são automaticamente 
cancelados após trinta dias, propiciando um exemplo de uma cláusula after 
da UML: after (períodoDeTempo) representa um evento temporal que 
ocorre quando o intervalo períodoDeTempo decorreu após a entrada no 
dado estado. 
Agora é hora de olharmos novamente para o estado confirmado. A 
pequena linha dentro do estado, na Figura 6.6, é um tipo de apêndice (stub) 
da UML, indicando um diagrama expandido no qual esse apêndice e outros 
detalhes incluídos do estado aparecem por inteiro. A Figura 6.7 é uma expansão 
do estado confirmado. 
Figura 6.6 Diagrama de estado para Pedido.
statusDeAutorizaçãoDeCliente. 
Diagrama de estado 107
O plano de trabalho na S&F é que pedidos grandes devem ser aprovados 
tanto por um gerente de crédito como por um gerente de cliente. (Eu não defino 
‘grande’ aqui, mas self.éGrande retorna true para um pedido grande.) 
Isso confere para um pedido grande confirmado o subestado inicial espe-
randoAprovação, que discuto a seguir. Um pedido pequeno confirmado, 
que obtém aprovação automática, inicia no subestado aprovado. 
Figura 6.7 Diagrama de estado para Pedido.statusDeCumprimento, 
uma expansão do estado confirmado. 
108 Análise de sistemas III
Uma vez que um pedido é aprovado, ele está pronto para ser cumprido, um 
estado em que os itens específicos dos tipos de produtos são alocados para entrega 
ao cliente. Mas, primeiramente, o estoque deve ser verificado: quer o estoque esteja 
disponível e a transição que está prestes a ser cumprida seja ativada, quer o esto-
que se encontre exaurido e a transição para o estado atrasoNoCumprimento 
seja ativada. Eu mostro isso no diagrama como duas transições com condições 
de guarda — por exemplo, [self.estoqueDisponível] — e sem eventos. 
Quando exibo essa abordagem para meus clientes e alunos, eles frequen-
temente me perguntam: “Por que você não utilizou uma cláusula when, 
tal como when (self.estoqueDisponível)?” Minha resposta é que 
aprovado é na realidade um estado transiente (ou estado de flow-through), 
significando que ele não persiste. (Observe sua propriedade {transiente} 
na Figura 6.7.) Em outras palavras, em vez de perambular em um estado tran-
siente, um objeto faz uma transição instantânea para outro estado, sem esperar por 
um evento. (Algumas pessoas denominam uma transição dessas, desprovida de 
evento, como transição não iniciadora.) Dessa forma, um estado transiente é 
como uma bifurcação em uma estrada, em que o objeto realiza uma transição 
baseado em seja qual for a condição de guarda colocada como true. 
O estado aprovado é transiente porque, nessa aplicação computadorizada, 
não precisaríamos aguardar que o sobrinho de Smibley saísse novamente para 
contar as caixas de WhizzoTM No-Cholesterol Dream Whip (Doce dos Sonhos 
Isento de Colesterol WhizzoR). Portanto, já que o sistema sabe ou não se há 
estoque, e atua conformemente, não há evento de when para ser modelado.7 
Note que o estado atrasoNoCumprimento é um estado antigo e comum 
não transiente, com when (self.estoqueDisponível) provocando a 
transição para cumprido.8 Quando o armazém expede os itens encomen-
dados, o estado tornase remetido. Eu estava tentado a retirar remetido 
do superestado confirmado, porque a S&f não cancelaria um pedido que 
tivesse sido remetido. Entretanto, desde que isso deixaria o estado remetido 
‘lá fora no frio’, ou teria requerido outro aninhamento, decidi modelar esse 
requisito com a condição de guarda [self.statusDeCumprimento not= 
remetido], conforme mostrado na Figura 6.6. 
O apêndice esperandoAprovação da Figura 6.7 indica uma expansão, 
que é mostrada na Figura 6.8. Esse diagrama de estado modela uma espera 
purgatorial (purificadora) de um grande pedido para o benefício dos gerentes 
de crédito e gerentes de cliente. Visto que esses gerentes são seres indepen-
dentes, dividimos a expansão de esperandoAprovaçãoem dois diagramas 
concorrentes — utilizando uma linha pontilhada vertical. 
Diagrama de estado 109
Mas ainda não estamos prontos! A aprovação na S&F significa esperar que 
ambos os gerentes façam seus gestos de aprovação; a rejeição por parte de 
qualquer um deles arremessa qualquer pedido para sua completa destruição. 
Para controlar essa situação, exploro a barra de sincronização (synchronization 
bar) da UML, mostrada na parte inferior de esperandoAprovação na Figura 
6.8. Essa barra grande e escura indica que ambas as aprovações, aprovadoPe-
loGerenteDeCrédito e aprovadoPeloGerenteDeCliente, devem ser 
atingidas antes de prosseguirmos. Quando ambos os estados são inicializados, 
nós imediatamente nos movemos para aprovado. 
Uma vez que a transição para rejeitado pode ocorrer desde espe-
randoAprovaçãoDoGerenteDeCrédito ou esperandoAprovaçãoDo-
GerenteDeCliente, não precisamos de qualquer sintonização — somente 
Figura 6.8 Diagrama de estado para Pedido.statusDeAprovação, 
uma expansão do estado esperandoAprovação. 
110 Análise de sistemas III
um par de transições diretas para rejeitado. Incidentalmente, a mensagem 
gerenteDeCliente.notificarRejeitado (self,...) trata-se 
apenas de uma mensagem de cortesia dizendo ao outro gerente para não se 
preocupar com a checagem de um pedido anteriormente rejeitado. 
 6.4 Estados Transientes de argumentos de mensagens 
de Saída 
Conforme discutimos na Seção 6.2 sobre estados aninhados, a condição 
de guarda booleana e as expressões when são construídas a partir de uma 
combinação desses elementos: 
 atributos de um objeto (ou, às vezes, variáveis particulares); 
 argumentos de mensagens de entrada de dados ao objeto; 
 argumentos retornados de mensagens de saída para outros objetos. 
Vimos exemplos dos dois primeiros elementos na Figura 6.2. Por exemplo, 
a condição de guarda [self.statusDeManutenção = Funcionando] 
contém um atributo, statusDeManutenção. A expressão when 
when (self.velocidadeReal = velocidadeDeOperação) tem outro atri-
buto, velocidadeReal, e um argumento de mensagem de entrada, ve-
locidadeDeOperação, que se origina de operadorIniciaAMáquina 
(velocidade-DeOperação). 
Até o momento, entretanto, não vimos o impacto da terceira espécie de 
argumento, um argumento de retorno desde uma mensagem de saída. Um 
exemplo do modelo de máquina de chão de fábrica, na Figura 6.2, foi velo-
cidadeDeOperaçãoOK, na mensagem de saída para motorPrincipal: 
MotorPrincipal.ligar (velocidadeDeOperação, out velocidadeDeOperaçãoOK) 
A mensagem ligar informa ao objeto motorPrincipal para girar 
o motor real de fábrica à velocidadeDeOperação. Entretanto, se o valor 
de velocidadeDeOperação exceder ao que é permitido para a marca de 
motor instalada, então o motorPrincipal irá roncar e nada fará, exceto 
retornar para velocidadeDe-OperaçãoOK como false. Mas, então, te-
mos um problema de modelagem. Se velocidadeDeOperaçãoOK retorna 
como false, não podemos simplesmente fazer uma cômoda transição para 
acelerando, porque a máquina não está acelerando 
— ela ainda está parada! 
Diagrama de estado 111
Teoricamente, aqui colocaríamos um par de condições de guarda — um 
para cada valor de velocidadeDeOperaçãoOK (true ou false) — como 
faríamos se motorPrincipal.ligar fosse uma mensagem de entrada em 
vez de uma mensagem de saída. Mas é tarde demais para uma condição de 
guarda de acordo com uma ação motorPrincipal.ligar em razão de que 
a condição de guarda está testando um argumento de retorno (velocidade-
DeOperaçãoOK) da mensagem motorPrincipal.ligar em si. Para lidar 
com esse tipo de situação, utilizo um estado transiente, acionandoMotor, 
conforme mostrado na Figura 6.9, uma cópia revista da Figura 6.2. 
Esse estado transiente no meio da Figura 6.9 é um veículo para as duas 
condições de guarda [velocidadeDeOperaçãoOK] e [not velocida-
deDeOperaçãoOK]. Em outras palavras, ele faz a transição de estadoDe-
Figura 6.9 Parte do diagrama de estado para Máquina.
statusDeOperação. 
112 Análise de sistemas III
Espera para acelerando, uma transição que é condicional no tocante ao 
valor de velocidadeDe-OperaçãoOK. 
Finalmente, a transição de retorno ao estado de EstadoDeEspera pro-
voca a emissão de duas mensagens de saída (para desligar o motor principal 
e acionar o freio de emergência novamente). 
 6.5 Atributos continuamente variáveis 
Conceitualmente, alguns atributos de coisas do mundo real variam de forma 
contínua, em vez de discretamente. Em outras palavras, se nós os medíssemos 
com a máxima precisão encontraríamos um número infinito de valores, não 
apenas alguns valores discretos. Eu os nomeio de atributos continuamente 
variáveis.9
Por exemplo, uma reação desenvolvendo-se em uma câmara de reação 
em uma fábrica de produtos químicos tem uma temperatura em curso, a qual 
é continuamente variável. Conforme mostrado pela Figura 6.10, o atributo 
Reação.temperaturaDeOperação representa a temperatura da reação 
(em que reação é a classe de reações químicas em uma câmara). Muito em-
bora temperaturaDeOperação constitua um atributo contínuo, em vez 
de um atributo discreto, ela também pode desempenhar certo papel em um 
diagrama de estado. 
Observe que cada um dos três estados do diagrama de estado — frio-
Demais, quenteDemais e OK — corresponde às seguintes faixas de valores 
da temperaturaDeOperação:10 
Notas
1. Em casos extremamente raros, uma classe em si 
(contrariamente a seus objetos) apresenta estados 
dignos de serem modelados com um diagrama de 
estado. Isso é similar à ideia de um atributo de classe 
versus um atributo de instância, que discutimos no 
Capítulo 3. 
2. O termo oficial na UML é diagrama de gráfico de 
estado, que é abreviado aqui como diagrama de es-
tado. Fica um pouco mais fácil para falar e eliminar 
a redundância construída no esquema de palavras 
oficial. Note também que as tabelas de estado con-
vencionais continuam úteis. 
3. Conforme veremos no Capítulo 10, um retângulo 
em um diagrama de transição de estado de-nota 
uma região no espaço-estado da classe. A região 
pode compreender um único ponto ou um grupo 
de pontos. 
4. Estilisticamente, a UML padrão prefere utilizar um 
símbolo de corte inclinado para a direita (/), em vez 
de uma linha horizontal, para separar eventos de 
ações. Portanto, nesta seção, você talvez queira subs-
tituir as palavras “antes do (/)” por “acima da linha” 
e “após o (/)” por “abaixo da linha”. 
5. Omiti as anotações nas transições apenas para fins de 
clareza neste exemplo.
6. A fim de se concentrar em diagramas de estado, este 
capítulo não se estende mais sobre as ações mencio-
nadas nos diagramas. 
7. Na realidade, um comando when(self.esto-
queDisponível) a partir de aprovado seria 
problemático: se o estoque já estivesse disponível 
quando da entrada em aprovado, o evento nunca 
ocorreria. Há tempos propus a cláusula when ever 
(self.estoqueDisponível), que combina 
Diagrama de estado 113
when (self.estoqueDisponível) e a con-
dição de guarda [self.estoqueDisponível] 
e permite aos estados aprovado e atraso No-
Cumprimento serem combinados. Entretanto, essa 
cláusula não ‘pegou’. Em vez disso, alguns modela-
dores, inclusive os autores de outros trabalhos sobre 
a UML, estão se valendo de estratagemas para tratar 
dessa questão utilizando when para significar whe-
never. Outros modeladores são mais absolutos em 
suas rejeições contra estados transientes, mas, devido 
ao problema acima, considero os estados transientes 
muito apropriados. Na próxima seção, revelo outra 
forma de representá-los, o que talvez me coloque em 
dificuldades perante os ministros da Ordem de Mo-
delagem do Novo Mundo. 
8. Por conveniência, neste modelo assumo que o obje-
to Pedido, em seu próprio termo, tem um atribu-
to estoqueDisponível, retornando um valor 
Booleano após verificação da disponibilidade de 
inventário. 
9. Eu me baseio no termo fluxo de dados contínuo, utili-
zado em Ward e Mellor, 198, para criar o termo atribu-
to continuamente variável.A ideia é que um atributo 
desse tipo — de qualquer forma, a princípio — varia 
continuamente em vez de só variar depois de eventos 
discretos. A pressão do ar em sua sala constitui um 
exemplo de um atributo continuamente variável. 
10. Como veremos no Capítulo 10, qualquer assertiva 
desse tipo é na realidade equivalente à definição de 
uma região de espaço-estado da classe.
 Para concluir o estudo da unidade 
Uma construção de software talvez não requeira vários diagramas de 
estado. Mas muito provavelmente possuirá pelo menos um diagrama de 
estado. Talvez não possua nenhum diagrama de estado, mas, na construção 
de um software para área comercial, frequentemente é necessário mostrar 
evolução ou andamento de determinado conjunto de cenários. Para esse 
tipo, o diagrama de estado é ideal.
 Resumo 
Esse diagrama representa uma máquina de estado que mostra como um 
objeto se comporta quando recebe eventos externos. Ele permite estudar 
o comportamento de vários classificadores como atores, casos de uso, 
interface etc.
A submáquina de estado é semanticamente equivalente a um estado 
composto, mas a diferença é que esse recurso pode ser reutilizado em 
vários contextos. Já o estado composto pode ser de dois tipos: simples, 
quando contém apenas uma região, ou ortogonal, quando contém duas 
ou mais regiões.