UML
Máquina de Estados
Máquinas de estado: definição
Diagrama de Estados
Superestados
Estados concorrentes
Máquina de Estados
Faz a modelagem do comportamento de um objeto ao longo do seu tempo de vida.
Empregado na modelagem dos aspectos dinâmicos de um sistema.
Pode ser usado na modelagem comportamental de um sistema inteiro, em especial sistemas reativos (que respondem aos sinais de atores externos).
Pode ser visualizado de duas formas:
Diagrama de Estados
Máquina de Estados
Diagrama de Estados
Ênfase aos estados dos objetos e às transições entre
estados.
Comportamento ordenado por eventos.
Diagrama de Atividades
Ênfase ao fluxo de controle de uma atividade para
outra.
Diagrama de Estados
É projetado para uma única classe.
Mostra o comportamento de um objeto ao longo do seu tempo de vida.
Descreve:
todos os estados possíveis de um objeto.
como o estado de um objeto muda a partir de eventos.
Existem várias formas de diagramas de estado, com pequenas diferenças semânticas.
O estilo UML é baseado no statechart de David Harel
evento [guarda] / ação
ponto inicial ponto final
Nome do Estado
do/atividade
Auto-transição
Diagrama de Estados
Ponto inicial – onde o objeto nasce.
Ponto final – onde o objeto deixa de existir.
Transição – relacionamento entre dois estados. Indica que um
objeto no 1º estado realizará certas ações (processos) e entrará no 2º estado quando um evento ocorrer ou uma condição (guarda) for satisfeito.
Estado – possui um nome a várias partes internas, que são opcionais. A atividade é um processo associado ao estado.
rótulo de transição
evento [guarda] / ação
Nome do Estado
Diagrama de Estados
O Rótulo de transição possui 3 partes, sendo todas opcionais:
evento: ocorrência de um estimulo que aciona uma mudança de estado.
guarda: é uma condição lógica; a transição ocorre quando a guarda for verdadeira.
ação: processo associado à transição; a mudança de estado ocorre quando a ação é executada.
N o m e d o e s ta d o e n try: a ç ã o d e e n tra d a e xit: a ç ã o d e s a íd a d o : a tivid a d e
Diagrama de Estados
Entry
ação executada sempre que se chega ao estado.
Exit
ação executada sempre que se sai do estado.
Do
enquanto estiver neste estado, o objeto executará esta ação. Uma seqüência de ações também pode ser especificada.
On evento
a ação será executada ao ocorrer este evento, sem que o objeto saia deste estado. Também chamado de transição interna.
Exemplo - Pedido
Ve r ifi ca n d o d o: v e ri fic a r it e m Ag u a rd a n d o E n tre g a n d o do : in ici a r e nt re g a E n tre g u e o b te r p rim e iro it e m [ n e m t o do s os iten s ve rifi c ad o s ] / p e g a r p ró xim o ite m[ to d o s o s ite n s ve rific a d o s & & a lg u n s ite n s n ã o e s tã o e m e s to q u e ]
ite m r ec e b id o [ a lg u n s i te n s n ã o es tã o e m es to qu e ]
[ t o d os o s ite ns ve rifi c a do s & & to d o s o s ite n s d is p o n íve is ]
ite m re c e b id o [ to d o s o s ite n s d is p o n íve is ]
Exemplo - Pedido
A 1º transição vai do ponto inicial ao estado “Verificando”. Ela possui
apenas a ação “Obter 1º item” que , uma vez realizada, permite ao objeto ir para o novo estado.
O estado “Verificando” tem uma atividade associada a ele chamada “Verificar item”, que é executada para cada item.
Este estado possui três transições para fora dele que não contêm eventos. A primeira é uma auto-transição com uma guarda (“nem todos os itens
verificados”) e uma ação (“pegar próximo item”): enquanto a guarda for verdadeira, a ação é executada.
V e ri fi ca n d o do : ver i fi car i te m o b te r p ri m e i ro i te m [ ne m to d o s o s i te n s ve ri fi ca d o s ] / p e g a r p ró xi m o i te m
Exemplo - Pedido
As outras duas transições possuem apenas uma guarda que, ao ser verdadeira, levam a uma mudança de estado.
Note que a transição só pode levar a um único estado. Desta forma, as condições que compõe a guarda de cada transição devem ser mutuamente exclusivas. Ve rific a n d o d o : ve rific a r ite m o b te r p rim e iro ite m [ n e m to d o s o s ite n s ve rific a d o s ] / p e g a r p ró xim o ite m
[ to d o s o s ite n s ve r ifi c ad o s & & to d o s o s i te n s d is p o n íve is ]
[ to d o s o s ite n s ve rific ad o s & & a lg u n s ite n s n ã o e s tã o e m e s to q u e ]
Exemplo - Pedido
O estado “Aguardando” não possui atividade e fica aguardando por um evento.
Quando o evento “item recebido” ocorre, as guardas são avaliadas e a transição apropriada é efetuada: ou a auto-transição que continua
neste estado, ou a transição que vai para o estado “Entregando”.
Ve r ifi ca n d o d o: v e ri fic a r it e m o b te r p rim e iro it e m [ n e m t o do s os iten s ve rifi c ad o s ] / p e g a r p ró xim o ite m
[ t o d os o s ite ns ve rifi c a do s & & to d o s o s ite n s d is p o n íve is ]
[ to d o s o s ite n s ve rific a d o s & & a lg u n s ite n s n ã o e s tã o e m e s to q u e ] ite m re c e b id o [ to d o s o s ite n s d is p o n íve is ] Ag u a rd a n d o ite m r ec e b id o [ a lg u n s i te n s n ã o es tã o e m es to qu e ]
Exemplo - Pedido
O estado “Entregando” tem uma atividade (“Iniciar entrega”) e uma transição sem guarda, que é acionada pelo evento “Entregue”. Esta transição só ocorrerá quando este evento ocorrer.
Ve r ifi ca n d o d o: v e ri fic a r it e m o b te r p rim e iro it e m [ n e m t o do s os iten s ve rifi c ad o s ] / p e g a r p ró xim o ite m
[ t o d os o s ite ns ve rifi c a do s & & to d o s o s ite n s d is p o n íve is ]
[ to d o s o s ite n s ve rific a d o s & & a lg u n s ite n s n ã o e s tã o e m e s to q u e ] ite m re c e b id o [ to d o s o s ite n s d is p o n íve is ] Ag u a rd a n d o ite m r ec e b id o [ a lg u n s i te n s n ã o es tã o e m es to qu e ] E n tre g a n d o do : in ici a r e nt re g a e n tre g u e E n tre g u e
Diagrama de Estados - Superestados
Ajuda a simplificar a modelagem de comportamentos complexos.
Um superestado é composto de vários estados, ou
Um sub-estado é aninhado em outro estado. Este é dito um estado composto.
Seus sub-estados herdam as transições do superestado.
Um estado composto pode ser seqüencial ou concorrente.
Na UML, um estado composto é representado como um estado simples, mas com um diagrama de estados aninhado.
Exemplo de Superestados – Pedido
V e r ifi ca n d o d o : v e ri fic a r it e m o b te r p ri m e i ro it e m [ n e m t o d o s o s i te n s ve ri fi c ad o s ] / p e g a r p ró xi m o ite m[ t o d os o s ite ns ve ri fi c a do s & & to d o s o s i te n s d is p o n íve i s ] [ to d o s o s i te n s ve ri fi c a d o s & & a lg u n s ite n s n ã o e s tã o e m e s to q u e ] i te m r e c e b i d o [ to d o s o s i te n s d is p o n íve is ] A g u a r d a n d o ite m r e c e b i d o [ a lg u n s i te n s n ã o e s tã o e m es to qu e ] E n tre g a n d o d o : in ici a r e n t re g a e n tre g u e E n tre g u e Cancelado Ativado cancelado
Exemplo de Superestados – Pedido
No exemplo do sistema de pedidos, queremos
cancelar um pedido a qualquer momento antes
de ele ser entregue.
Uma maneira simples é criar um superestado
(ou estado composto) “Ativado”que engloba os
três estados que fazem o cancelamento, e
Estados concorrentes
Um objeto pode ter duas seqüências distintas de
estados que retratam comportamentos independentes
em situações diferentes.
Estes comportamentos distintos são representados em
diferentes diagramas de estados, onde um objeto pode
estar em dois estados diferentes, um em cada
diagrama.
Estes diagramas podem ser combinados em um único
diagrama de estados concorrentes.
Quando o objeto deixa os estados concorrentes, ele
Estados Concorrentes - Exemplo
No exemplo do sistema de pedidos, temos também estados
baseados em autorização de pagamento. A partir destes estados, podemos ter um diagrama como este:
Au to riza n d o d o : ve rific a r p a g a m e n to Au to riza d o E n tre g u e R e je ita d o [ p a g a m e n to o k ] [ p a g a m e n to n ã o o k ]
Estados Concorrentes - Exemplo
Entregue Rejeitado Cancelando Aguardando Verificando Entregando Autorizado AutorizandoDiagrama de Estados
Quando usar um diagrama de estados?
São bons para descrever o comportamento de um objeto através de vários casos de uso.
Não são bons para descrever um comportamento que envolve vários objetos em colaboração.
O diagrama de estados não deve ser descrito para todas as classes do sistema, apenas para as quais ele ajude a
compreender o comportamento.
Quando um objeto possui muitos conjuntos concorrentes de comportamento, gerando vários diagramas de estado
