1

Diagrama de Estado

Conteúdo adaptado e replicado do autor Ian Sommerville, 9ª edição. Pearson Prentice Hall, Engenharia de Software. 2011
 Introdução
● Uma aplicação e seus objetos podem passar por diferentes estados durante o
seu ciclo de vida, em que a transição entre estados é realizada através do
acontecimento de eventos internos ou externos do sistema.
● Através da análise das transações entre estados dos objetos de um sistema,
podem-se prever todas as possíveis operações realizadas, em função de
eventos que possam ocorrer.
● O Diagrama de Estados permite descrever o ciclo de vida de objetos de uma
classe, os eventos que causam a transição de um estado para outro e a
realização de operações resultantes.

CK0247: Engenharia de Software - Prof. Rossana M. C. Andrade 2

 Introdução
● Principais elementos de uma Diagrama de Estados:
● Estados;
● Transições;
● Eventos;
● Condições de Guarda;
● Ações;
● Atividades;

CK0247: Engenharia de Software - Prof. Rossana M. C. Andrade 3

 Estados
● Um estado é uma situação na vida de um objeto durante a qual ele satisfaz
alguma condição ou realiza alguma atividade.

CK0247: Engenharia de Software - Prof. Rossana M. C. Andrade 4

 Transições
● Estados estão associados através de transições.
● Uma transição é mostrada como uma linha conectando dois estados.

CK0247: Engenharia de Software - Prof. Rossana M. C. Andrade 5

 Eventos
● Uma transição possui um Evento associado. Um evento é algo que acontece
em algum ponto no tempo e que pode modificar o estado de um objeto.

CK0247: Engenharia de Software - Prof. Rossana M. C. Andrade 6

 Exemplo

CK0247: Engenharia de Software - Prof. Rossana M. C. Andrade 7

 Condições de Guarda
● A guarda é uma expressão que resulta em um valor booleano.
● É representada entre colchetes [condição de guarda].

CK0247: Engenharia de Software - Prof. Rossana M. C. Andrade 8

 Ações
● Ao transitar de um estado para outro, um objeto pode realizar uma ou mais
ações.
● A ação é representada na linha de transição e deve ser precedida por uma barra
inclinada para a direita.
● A ação associada a uma transição é executada somente se a transição for
disparada.
● Uma ação pode gerar outros eventos.

CK0247: Engenharia de Software - Prof. Rossana M. C. Andrade 9

 Exemplo

CK0247: Engenharia de Software - Prof. Rossana M. C. Andrade 10

 Atividades
● Semelhante às ações, porém, uma atividade está sempre associada a um
estado.
● As atividades são divididas em três tipos:
● On Entry: Executada assim que se entra no Estado em questão.
● On Exit: Executada assim que o estado vai ser modificado.
● Do Action: Executada durante o tempo que o objeto se encontra no Estado
em questão.

CK0247: Engenharia de Software - Prof. Rossana M. C. Andrade 11

 Exemplo

CK0247: Engenharia de Software - Prof. Rossana M. C. Andrade 12

 Barra de sincronização e
Junção
● Uma barra de sincronização determina o momento em que o processo passou a
ser executado em paralelo e em quantos sub-processos se dividiu.

● Uma junção serve para indicar a união de dois ou mais processos paralelos em
um único processo.

CK0247: Engenharia de Software - Prof. Rossana M. C. Andrade 13

 Exemplo

CK0247: Engenharia de Software - Prof. Rossana M. C. Andrade 14

 Auto-Transição
● Transições Internas ocorrem durante o estado de um objeto sem modificá-lo.

CK0247: Engenharia de Software - Prof. Rossana M. C. Andrade 15

 Pseudo-estado de Escolha
● Define um ponto de transição em que deve ser escolhido qual o estado a ser
gerado. A condição de escolha é colocada como condições de guarda
[condição]:

CK0247: Engenharia de Software - Prof. Rossana M. C. Andrade 16

 Estado Composto
● Um estado que contém diversos outros estados é dito composto.
● Todos os estados dentro de um estado composto herdam qualquer transição
deste último.

CK0247: Engenharia de Software - Prof. Rossana M. C. Andrade 17

 Estado Concorrente
● Tipo especial de estado composto.
● Um objeto em um estado concorrente pode, na verdade, se encontrar em dois
ou mais estados independentes.

CK0247: Engenharia de Software - Prof. Rossana M. C. Andrade 18

Exemplo - Microondas

CK0247: Engenharia de Software - Prof. Rossana M. C. Andrade 19

20

Diagrama de
Sequência

Conteúdo adaptado e replicado do autor Ian Sommerville, 9ª edição. Pearson Prentice Hall, Engenharia de Software. 2011
 Introdução
● O objetivo dos modelos vistos até agora é fornecer um entendimento do
problema correspondente ao sistema a ser desenvolvido.

● Entretanto, esses modelos deixam algumas perguntas sem respostas.

CK0247: Engenharia de Software - Prof. Rossana M. C. Andrade 21

 Introdução
● Casos de Uso:
● Quais são as operações que devem ser executadas internamente ao
sistema?
● A que classes estas operações pertencem?
● Quais objetos participam da realização deste caso de uso?
● Modelo de Classes:
● De que forma os objetos colaboram para que um determinado caso de uso
seja realizado?
● Em que ordem as mensagens são enviadas durante esta realização?
● Que informações precisam ser enviadas em uma mensagem de um objeto a
outro?
● Será que há responsabilidades ou mesmo classes que ainda não foram
identificadas?
CK0247: Engenharia de Software - Prof. Rossana M. C. Andrade 22
 Introdução
● Para responder às questões anteriores, o modelo de interações deve ser criado.

● Esse modelo representa mensagens trocadas entre objetos para a execução de

cenários dos casos de uso do sistema.

● Diagramas de interação representam como o sistema age internamente para

que um ator atinja seu objetivo na realização de um caso de uso.

CK0247: Engenharia de Software - Prof. Rossana M. C. Andrade 23

 Mensagem
● O conceito básico da interação entre objetos é a mensagem.

● Uma mensagem representa a requisição de um objeto remetente a um objeto

receptor para que este último execute alguma operação definida para a sua
classe. Essa mensagem deve conter informação suficiente para que a operação
do objeto receptor possa ser executada.

CK0247: Engenharia de Software - Prof. Rossana M. C. Andrade 24

Mensagem x Responsabilidade
● Qual o objetivo da construção dos diagramas de interação?
● Identificar mensagens e, em última análise, responsabilidades (operações e
atributos).

CK0247: Engenharia de Software - Prof. Rossana M. C. Andrade 25

 Notações
● O rótulo de uma mensagem deve seguir a seguinte sintaxe:
● [[expressão-seqüência] controle:] [v :=] nome [(argumentos)]

● Onde o termo controle pode ser uma condição ou um iteração:

● *[ cláusula-iteração ] ou [ cláusula-condição ]

● O único termo obrigatório corresponde ao nome da mensagem.

CK0247: Engenharia de Software - Prof. Rossana M. C. Andrade 26

 Exemplos

CK0247: Engenharia de Software - Prof. Rossana M. C. Andrade 27

Diagrama de Sequência

CK0247: Engenharia de Software - Prof. Rossana M. C. Andrade 28

 Diagrama de Sequência
● Elementos básicos em um diagrama de sequência:
● Atores;
● Objetos e classes;
● Mensagens;
● Linhas de vida e focos de controle;
● Criação e destruição de objetos;
● Iterações.

CK0247: Engenharia de Software - Prof. Rossana M. C. Andrade 29

Diagrama de Sequência

CK0247: Engenharia de Software - Prof. Rossana M. C. Andrade 30

 Mensagem Reflexiva
● Em uma mensagem reflexiva o remetente é também o receptor.

CK0247: Engenharia de Software - Prof. Rossana M. C. Andrade 31

Criação e Destruição de Objetos

CK0247: Engenharia de Software - Prof. Rossana M. C. Andrade 32

 Quadro de Interação
● Notação

CK0247: Engenharia de Software - Prof. Rossana M. C. Andrade 33

 Exemplo

CK0247: Engenharia de Software - Prof. Rossana M. C. Andrade 34

Fluxo de Controle: Alternativas

CK0247: Engenharia de Software - Prof. Rossana M. C. Andrade 35

Fluxo de Controle: Opções

CK0247: Engenharia de Software - Prof. Rossana M. C. Andrade 36

Fluxo de Controle: Iterações

CK0247: Engenharia de Software - Prof. Rossana M. C. Andrade 37

 Diagrama de Sequências do caso de uso Transferir Dados do MHCPMS

CK0247: Engenharia de Software - Prof. Rossana M. C. Andrade 38

 Construção de Modelos de
Interação
● Dica:
● Identifique as classes conceituais que participam em cada caso de uso.
● Defina também que objetos criam (destroem) outros objetos.
● Verifique a consistência dos diagramas de interação em relação ao MCU e
ao modelo de classes.
● Se certifique de que o objeto de controle realiza apenas a coordenação da
realização do caso de uso.
● Faça o máximo para construir diagramas de interação o mais inteligível
possível.
● Utilize o princípio de projeto conhecido como Lei de Demeter.
CK0247: Engenharia de Software - Prof. Rossana M. C. Andrade 39
 Lei de Demeter
● Esse princípio impõe restrições acerca de quais são os objetos para os quais
devem ser enviadas mensagens na implementação de uma operação:
● Ao próprio objeto da classe;
● Um objeto recebido como parâmetro do método;
● Um atributo da classe;
● Um objeto criado dentro do método;
● Um elemento de uma coleção que é atributo da classe.
● A intenção é evitar acoplamento excessivo em um objeto e também evitar que
ele tenha conhecimento das associações entre outros objetos.

CK0247: Engenharia de Software - Prof. Rossana M. C. Andrade 40

 Procedimento de Construção
● Para cada caso de uso, selecione um conjunto de cenários relevantes:
● O cenário correspondente ao fluxo principal do caso de uso deve ser incluído.
● Considere também fluxos alternativos e de exceção que tenham potencial em
demandar responsabilidades de uma ou mais classes.
● Para cada cenário selecionado, identifique os eventos de sistema:
● Posicione o(s) ator(es), objeto de fronteira e objeto de controle no diagrama.
● Para cada passo do cenário selecionado, defina as mensagens a serem enviadas de
um objeto a outro.
● Defina as cláusulas de condição e de iteração, se existirem, para as mensagens
● Adicione objetos de entidade à medida que a sua participação se faça necessária no
cenário selecionado.

CK0247: Engenharia de Software - Prof. Rossana M. C. Andrade 41

 Observações sobre o
Procedimento
● A definição das mensagens deve ser feita com base nas responsabilidades de
cada objeto envolvido:
● O nome da mensagem;
● Os argumentos de cada mensagem;
● O valor de retorno da operação correspondente;
● Cláusulas de condição e de repetição, se existirem.
● A maioria dos objetos já devem ter sido identificados durante a construção do
modelo de classes.

CK0247: Engenharia de Software - Prof. Rossana M. C. Andrade 42

 Observações sobre o
Procedimento
● Mais de um controlador podem ser criados em um mesmo caso de uso,
dependendo de sua complexidade.

● O controlador pode mesmo ser suprimido, também em função da complexidade

do caso de uso.

CK0247: Engenharia de Software - Prof. Rossana M. C. Andrade 43

 Mapa UML

CK0247: Engenharia de Software - Prof. Rossana M. C. Andrade 44

 Referências
[1] SOMMERVILLE, Ian. Engenharia de software , 9º ed., Pearson, 2011.

[2] BEZERRA, Eduardo. Princípios De Análise E Projeto De Sistemas Com Uml-3a Edição. Elsevier Brasil, 2006.
GUEDES, Gilleanes T. A. UML: Uma abordagem prática. São Paulo: Novatec, 2006.

[3] REVISTABW. UML: Diagrama de Estados. Disponível em: <http://www.revistabw.com.br/revistabw/uml-diagrama-de-

estados/> Acesso: 24/05/2017.

Copyright Ⓒ GREat 2018

CK0247: Engenharia de Software - Prof. Rossana M. C. Andrade 45