Engenharia de Software | Linguagem de modelagem unificada (UML) | Diagramas de Sequência, de Estados e de Atividade
Diagramas de interação
Os diagramas de interação, de forma geral, mostram como as classes colaboram em determinados comportamentos. A UML, em sua versão 2.0, oferece algumas formas de modelar interações, sendo o diagrama de sequência mais usado deles. Outro diagrama de interação popular é o diagrama de comunicação que, nas versões anteriores a 2.0 da UML, era chamado de diagrama de colaboração.
Num mesmo projeto, podemos até usar os 2 diagramas de interação: diagrama de sequência ou comunicação (antigo colaboração), mas para interações ou comportamentos diferentes. Não faz sentido usar ambos, por exemplo, para representar um mesmo cenário de uso, pois eles têm o mesmo objetivo, porém com focos diferentes. Todavia, para cenários, casos de uso ou comportamentos diferenciados, podemos optar por um dos dois. Em geral, usa-se apenas um deles por todo o projeto.
O diagrama de sequência é o mais adequado, pelo fato de focar a temporalidade (daí o seu nome) da interação, que é relevante. Já o diagrama de comunicação foca nas mensagens enviadas entre objetos que estão relacionados. Porém, cada um tem sua vantagem, que, por sua vez, atua como desvantagem.
Diagrama de sequência
Vantagem: há como saber a ordem de envio das mensagens.
Diagrama de comunicação
Vantagem: normalmente, permite construir modelos mais legíveis comparativamente aos diagramas de sequência.
Nesta aula, iremos nos ater apenas ao diagrama de sequência, devido à falta de tempo, mas incentivamos que você pesquise e entenda o funcionamento do diagrama de comunicação (ou colaboração, nas versões da UML anteriores a 2.0). Acompanhe, a seguir, o tripé da análise.
O tripé da análise
Do ponto de vista da fase de análise de sistemas existem 3 modelos que se integram e formam uma boa base mínima para modelagem e documentação de sistemas de informação. São eles: diagrama e especificações de casos de uso, diagrama de classes e diagrama de sequência, cuja relação é apresentada no esquema.
Esses três diagramas formam o chamado Tripé da Análise. Vejamos como tais diagramas se integram.
Casos de uso (em suas especificações) apresentam especificam o comportamento do sistema (ou parte dele), descrevendo as funcionalidades deste. O caso de uso é um conjunto de cenários, onde:
- O cenário é uma sequência de passos que descreve uma interação entre sistema e um usuário.
- Todo caso de uso tem o cenário principal, que é o “caminho sem erros”, ou seja, tudo acontece sem nenhum problema ou exceção.
- A cada problema ou exceção pode-se derivar um novo cenário, mostrando como o sistema vai se comportar.
- O diagrama de classes, conceitual, mostra as classes do domínio do problema.
- O diagrama de sequência mostra a interação entres os objetos (classes) de um determinado cenário (caso de uso).
Para cada cenário de um caso de uso, teremos um diagrama.
- Em contrapartida, o diagrama de sequência contribui com a descoberta de novas operações, que serão acrescidas nos métodos das classes envolvidas no diagrama de sequência.
É sob essa ótica, onde o diagrama de sequência contribui com a descoberta de novas operações, que para desenvolvermos esse diagrama de sequência é necessário ter em mãos:
- Diagrama de casos de uso;
- Especificação de cada caso de uso;
- Diagrama conceitual de classes.
Vale observar que, ao elaborarmos o diagrama de sequência, podemos realizar alterações de melhorias e acréscimos tanto nas especificações de casos de uso como no diagrama de casos de uso e, principalmente, no diagrama de classes, onde, além de novos métodos para as classes já existentes, poderemos também modelar novas classes. Essas alterações são normais, sadias e realmente acontecem, pois à medida que vamos evoluindo e nos aprofundando no sistema, aumentamos nossa compreensão e capacidade de modelar o sistema mais adequadamente. A seguir, vamos aprofundar sobre o diagrama de sequência.
O diagrama de sequência
O diagrama de sequência visa mostrar como as classes envolvidas interagem (trocam mensagens) para a realização de um caso de uso, mais especificamente de um cenário de uso (parte de um caso de uso). O nome “sequência” advém do fato de ele descrever, ao longo da linha do tempo, a sequência de comunicações entre os objetos.
Veja, a seguir, o primeiro exemplo de diagrama de sequência, a partir do qual explicaremos os elementos básicos e a correlação com casos de uso e classes.
1- O ato é o mesmo do caso de uso: correntista representado por boneco.
2- Interface é o formulário com o qual o ator interage.
3- Conta Corrente e Movimento Conta são classes do modelo conceitual de classes.
4- ‘Agencia e Conta’ e ‘Senha’ são dados informados pelo ator correntista sobre sua conta corrente.
5- Validar AgConta (Agencia e Conta) e Validar Senha são métodos da classe Conta Corrente, que são chamados por uma mensagem síncrona enviada à classe.
6- ObterSaldoConta (Agencia, Conta, Data) é um método da classe Movimento Conta, que é chamado por uma mensagem síncrona enviada à classe.
7- ObterSaldoConta, por sua vez, chama o método Calcular Saldo (Data) através de uma autochamada, ou seja, o método chamado pertence à própria classe. Isso também é chamado de autodelegação.
8- A linha pontilhada vertical que aparece em cada elemento: Ator, Interface e classes chama-se Linha da Vida.
9- A caixa que aparece ao longo da Linha da Vida chama-se Caixa de Ativação e mostra quando cada elemento está ativo na interação.
10- Observe que antes da chamada os métodos ValidarSenha têm [Agencia e Contas Validas]. Isso é uma condição de guarda. Entre colchetes as condições são apresentadas. O método ValidarSenha somente será executado se a condição for satisfeita.
11- Da mesma forma, antes da chamada ao método ObterSaldoConta (Agencia, Conta e Data), temos a condição de guarda [Ag, Conta e Senha válidos], indicando que o referido método apenas será executado se a condição for verdadeira.
Cabe destacar que o diagrama de sequência apresentado refere-se ao cenário principal do caso de uso Emitir Saldo Conta, abaixo descrito e cujo trecho de diagrama também é apresentado.
Especificação de casos de uso
Caso de Uso: Emitir Saldo Conta
Cenário Principal
1. Correntista Informa Agencia e Conta corrente
2. Sistema valida Agencia e Conta
3. Correntista Informa senha de acesso
4. Sistema valida senha de acesso
5. Sistema calcula saldo do dia corrente, com base nas movimentações da conta e saldo anterior.
6. Sistemas apresenta saldo ao correntista
Cabe destacar que o diagrama de sequência apresentado refere-se ao Cenário Principal do caso de uso Emitir Saldo Conta, abaixo descrito e cujo trecho de diagrama está abaixo.
Trecho de diagrama de caso de uso relacionado à interação:
Diagrama de classes – a figura abaixo exibe o trecho de diagrama de classe relacionado a esse diagrama de sequência:
O diagrama de sequência e seus elementos
Dentre os elementos do diagrama de sequência, podemos destacar:
- Os objetos participantes da interação são organizados na horizontal;
- Abaixo de cada objeto existe uma linha (linha de vida);
- Cada linha de vida possui o seu foco de controle (caixa de ativação);
- O foco de controle indica que o objeto está fazendo algo;
- As mensagens entre objetos são representadas com linhas horizontais rotuladas partindo da linha de vida do objeto remetente e chegando à linha de vida do objeto receptor.
A figura a seguir, extraída do livro UML essencial: um breve guia para a linguagem-padrão de modelagem de objetos, de Martin Fowler, mostra os elementos principais de um diagrama de sequência. Todos os elementos que citamos no exemplo dado anteriormente estão bem elucidados nela.
1. Participante: Ator e classes que participam da interação;
2. Linha da vida de cada participante;
3. Caixa de ativação indicando o quanto o participante está ativo na interação;
4. Mensagem: chamado de um método da classe, onde chega a mensagem;
5. Retorno: mensagem de retorno da mensagem (chamada ao método da classe);
6. Autochamada: chamada de uma método da própria classe.
Decisões e repetições no diagrama de sequência
Representando decisões no diagrama de sequência
Muitas vezes, precisamos representar que determinadas mensagens serão enviadas ou não, de acordo com uma condição, chamada condição de guarda, ou, ainda, representar um conjunto de mensagens mutuamente exclusivas.
Conforme podemos observar na imagem abaixo, vemos um trecho de diagrama de sequencia, onde representamos a decisão. Observe que temos o retângulo, com uma linha tracejada dentro.
Na parte de cima, inicial do retângulo, temos a condição de guarda [Tipo Cliente =F] e na parte de baixo, após a linha tracejada, temos outra condição de guarda [Tipo Cliente = F]. Vejamos como funciona:
1. O ator informa o tipo de cliente, que pode ser F (física) ou J (jurídica)
2. Se o Tipo Cliente = F (primeira condição de guarda) = VERDADE, executa-se as mensagens que estão associadas a essa condição, ou seja as mensagens que estão antes do tracejado.
a) Ator informa os dados da pessoa física (Dados Cliente Fis)
b) Ocorre a inserção desses dados , através da chamada ao método Inserir CliFis(), que está na classe Pessoa Física
3. Se o Tipo Cliente = F = FALSO, desvia-se para a execução das mensagens que estão após a linha tracejada, onde temos uma outra condição de guarda a ser avaliada,
4. Se Tipo Cliente = J (segunda condição de guarda) = VERDADE executa-se as mensagens que estão associadas a essa condição, ou seja as mensagens que estão após o tracejado.
a) Ator informa os dados da pessoa Juridica (Dados Jur)
b) Ocorre a inserção desses dados , através da chamada ao método Inserir CliJur(), que está na classe Pessoa Jurídica.
O exemplo a seguir, mostra que podem haver tantas condições de guarda quantas forem necessárias. Abaixo temos Opcão = A, Opção = B e Else.
Como funciona este diagrama?
Se [Opcão = A] é verdade, chama o método Msg1 do Objeto 1
Senão
Se [Opção = B] é verdade, chama o método Mgs2 do Objeto 2
Senão
Chama o método Msg3 do Objeto 3
Agora vejamos como representar Repetições no diagrama de sequencia. Além dos elementos já discutidos, o diagrama de sequencia possibilita que especifiquemos REPETIÇõES, ou seja uma ou mais mensagens que são executadas repetidas vezes. O trecho de diagrama de sequencia abaixo, a representação da repetição, na caixa LOOP, chamada quadro de interação, com a condição de guarda [Para cada item de venda], ou seja enquanto houver item na venda e o caixa (ator) digitar um cod produto, as mensagens e interações contidas na caixa LOOP serão executadas.
Criação de destruição de objetos
O diagrama de sequência dispõem de 2 notações extras para representar, respectivamente, a criação (<<Create>>) e a destruição (<<Destroy>>) de objetos participantes da interação.
Na figura, vemos o uso da criação do participante (Objeto Criado). Após criado, quando recebe a mensagem <<CREATE>>, representada pelo método (CriaObjeto()), o Objeto Criado pode receber e enviar mensagens normalmente.
Na figura, temos o exemplo da destruição de objetos, quando o objeto destruidor envia a mensagem <<destroy>>, representada pela execução do método DestroyMessage(). O Elemento, representado pelo X no objeto destruído, representa o seu fim.
Um objeto pode se autodestruir, o que é representado por um X ao final da linha de vida de um objeto (nesse caso, é como se o objeto enviasse uma destruição a si próprio).
Como hoje as linguagens possuem sistema de coleta de lixo, não se excluem objetos diretamente, mas pode ser relevante indicar que o objeto não é mais necessário e não pode ser utilizado.
Tipos de mensagens: síncronas e assíncronas
Os exemplos dados de diagramas de sequência usaram, até aqui, apenas um tipo de mensagem, a síncrona, ou seja, a que, uma vez enviada, aguarda o retorno (seta pontilhada na direção contrária à mensagem enviada) com a sua conclusão (tal qual uma chama de rotina em um programa).
O outro tipo é a assíncrona, ou seja, a que, uma vez enviada, não necessitar esperar por uma resposta, sendo possível continuar o fluxo do processamento.
Um bom exemplo de uso de mensagens assíncronas se dá em sistemas que necessitem de processamento concorrente, e por isso devem permitir representar mensagens concorrentes assíncronas (mensagens que são processadas em paralelo sem um tempo definido para a sua realização e sem esperar o retorno da mensagem para prosseguir).
A figura a seguir mostra um exemplo de mensagem assíncrona (seta vazia), representada pela chamada ao método Message1(), que sai do Objeto 1 para o Objeto 2. Mostramos, logo abaixo, a Message2(), síncrona (seta cheia), para que se perceba a diferença.
Responsabilidade das classes
Uma das questões de relevância que surge ao modelarmos classes é: qual classe deve ser responsável por um determinado método, ou seja, em qual classe devemos alocar esse método. Para tal decisão devemos levar em consideração volume, desempenho, segurança e outros aspectos físicos inerentes à implementação.
Existe um conjunto de critérios que devem ser avaliados, e nosso foco aqui não é nos estendermos nesse assunto, mas alertar da preocupação. Apenas para citar: devemos alocar os métodos de forma que tenhamos baixo acoplamento e alta coesão entre as classes.
Existe um padrão (solução já dada, estudada e adaptada) que diz que:
– O método deve ser colocado na classe que conhece a informação (tratada pelo método). Esse padrão chama-se “padrão especialista”.
Padrão é uma solução já usada em projetos anteriores, que deve ser usada e ajuda a dar soluções eficientes em nossos projetos. Existem outros padrões classificados em diferentes tipos a serem considerados, que podem ser objeto de uma pesquisa para expansão dos conhecimentos nesse sentido.
Os diagramas de interação, em que o diagrama de sequência é um deles, ajudam a clarear essa questão, e, muitas vezes, perceberemos que fizemos uma escolha equivocada da classe onde inicialmente alocamos determinados métodos. A seguir, faça a atividade proposta, relacionada ao conteúdo visto até aqui.
Atividade proposta
Considere o diagrama de casos de uso, a especificação (descrição textual) do caso de uso “Registrar Locação”, e o diagrama de classes a seguir.
Registrar locação/cenário principal
1. Atendente informa identificação do cliente;
2. Sistema localiza dados do cliente informado;
3. Atendente informa dados da mídia a ser locada;
4. Sistema localiza dados da mídia informada;
5. Sistema informa data de devolução da locação;
6. Atendente confirma locação;
7. Sistema registra locação;
8. Sistema emite boleto de locação para o Cliente.
Cenários alternativos
2.a. Cliente não localizado:
– Sistema informa “Cliente não registrado no sistema” e retorna ao
passo 1 do cenário principal.
4.a. Mídia não localizada:
– Sistema informa “Mídia não registrada no sistema” e retorna ao passo
3 do cenário principal.
Com base nessa documentação apresentada, elabore o diagrama de sequência para o cenário principal do caso de uso “Registrar Locação”.
Chave de resposta
Caso de uso: registrar locação
Cenário principal
Observe a especificação do caso de uso e veja que a ação 8 chama-se “Sistema Emite Boleto de Locação” (destacada em amarelo). Isso significa que é preciso que exista um método na classe LOCAÇÃO para formatar os dados já transacionados no caso de uso e emitir o boleto desejado. Adiante, uma das soluções do diagrama de sequência solicitado no enunciado.
Métodos identificados a serem incluídos no diagrama de classes:
1) O método PESQUISAR da classe MÍDIAS ainda não havia sido identificado no diagrama de classes até então. Veja na página acima a última versão do diagrama. O único método da classe MÍDIAS era INCLUIR;
2) O método EMITIR BOLETO DE LOCAÇÃO também é novo, conforme ilustrado.
O diagrama de máquina de estados
O diagrama de máquina de estados representa os possíveis estados de um objeto: demonstram, por meio das transições, os eventos que geram a mudança.
Esse tipo também é chamado de diagrama de transição de estados, que chamaremos de DTE doravante.
Estados, evento e transição
O Diagrama de Máquina de Estados representa os possíveis estados de um objeto, demonstram, por meio das transições, os eventos que geram a mudança.
O estado de um objeto é uma condição específica de um objeto, em algum momento em que o mesmo esta sendo usado no sistema. Segundo a definição de UML Guia de Usuário[Booch, Rumbauch e Jaconson, 2006], estado é uma condição ou situação na vida de um objeto durante o qual o objeto satisfaz alguma condição, realiza alguma atividade ou aguarda um evento. Um objeto permanece em um estado por um tempo finito.
- Um evento é a ocorrência de um estímulo gerado para o objeto, capaz de mudar o seu estado atual.
- Uma transição indica um movimento de um estado para o outro.
Vamos identificar os elementos do Diagrama de Estados, analisando a figura abaixo que apresenta o diagrama de estado de uma Classe QUARTO de um Sistema de Hotel.
- O inicio ocorre no pseudo estado inicial que é a bola preta cuja seta aponta para o estado DISPONíVEL, efetivamente o estado que fica o quarto inicialmente;
- Estando no estado de Disponível o quarto pode mudar para o estado de Reservado quando ocorre o evento “Cliente faz Reserva”;
- Estando no estado de Reservado podem haver 2 transições
– De volta para o estado de Disponível se ocorrer o evento “Reserva é cancelada”
– Para o estado de Ocupado , se ocorrer o evento “Cliente faz checkin”;
- Do estado Ocupado, vai haver a mudança para o estado Em Limpeza, na medida em que ocorre o evento “Cliente faz checkout”;
- Estando no estado Em Limpeza, o quarto voltará ao estado de Disponível na ocorrência do evento “Atendente libera Quarto”;
- Estando no estado Disponível, o Quarto pode mudar também para o estado Final, quando o mesmo for excluído do sistema (evento);
O diagrama de estados e seus elementos básicos
A figura a seguir, um diagrama simples de estados, mostra os elementos básicos que foram aplicados no exemplo anterior.
O estado inicial indica o estado quando o objeto é criado, por isso citou-se como pseudoestado; pois, na verdade, ainda não é um estado propriamente. Um diagrama de transição de estados (DTE) somente pode ter estado inicial.
O estado final é opcional, pois podemos ter objetos em estados cíclicos, como as estações do ano, os sinais de trânsito e até mais de um, no DTE.
Detalhando a transição
A transição, em um diagrama de estados, indica um movimento de um estado para outro. Cada transição possui um rótulo que possui três partes: Assinatura do gatilho [sentinela] / atividade, onde:
- Assinatura do gatilho, via de regra, é um único evento que demanda a mudança de estado. No exemplo inicial, sobre os estados do QUARTO de hotel, usamos apenas assinatura do gatilho, ou seja, o evento que ocasiona a transição de estado. É raro que esteja ausente, mas pode ocorrer e denota que a transição é feita imediatamente.
- Sentinela, se estiver presente, é uma condição que deve ser verdadeira para que a transição ocorra. Se ausente, indica que a transição sempre acontece.
- Atividade é um comportamento executado durante a transição. A ausência de atividade diz que nada é feito durante a transição.
Um evento pode denotar mais de uma transição, e, nesse caso, as sentinelas devem expressar condições que sejam mutuamente exclusivas, por motivos óbvios. O estado final indica que ciclo do objeto está encerrado e sua máquina de estados completa.
Ações de entrada e saída, transições internas e atividades
A seguir estão algumas características avançadas do DTE, que ajudam a otimizar e reduzir a quantidade de estados e complexidade do DTE.
Ações de Entrada e Saída
São ações que são realizadas dentro do estado, assim que entra no estado (entrada) e antes de sair do estado (saída), independente da transição. A cláusula ENTRY denomina uma ação de entrada no estado, assim como a cláusula EXIT é usada para ações de saída.
Transição interna
Os estados pode reagir a eventos, que não ocasionam transição, usando atividades internas. Ou seja, são eventos que precisam ser tratados, mas que não ocasionam transição de estado. As atividades internas não disparam ações de entrada e saída, na medida em que não saem e entram do objeto, em decorrência do evento.
Atividades
Em geral, objeto fica ocioso em um estado até que um evento ocorra. Porém, pode ser que você deseje que um objeto permaneça realizando uma tarefa até que determinado evento ocorra. Ou seja, executa uma atividade enquanto está nesse estado. A cláusula DO indica que há uma atividade naquele estado.
Retomando ao exemplo do DTE referente à classe QUARTO do sistema de hotel, poderíamos eliminar o estado EM LIMPEZA, fazendo com que a LIMPEZA seja uma ação de saída (Exit) do estado OCUPADO, e, assim, reduziremos o número de estados. Em outras palavras: quando o cliente fizer o checkin, evento que ocasiona a transição de OCUPADO, em vez de ir para o estado EM LIMPEZA, iria direto para DISPONÍVEL, e acrescentaríamos uma ação de saída (EXIT) de nome limpeza ao estado OCUPADO.
Veja um exemplo de como declarar no estado, ações de entrada (ENTRY), de saída (EXIT) e atividades (DO).
A continuidade do exemplo, acrescentando-se uma transição interna.
• O evento que demanda a ação;
• A condição de guarda para a execução da atividade;
• A atividade interna que será realizada.
Superestados
Um superestado ajuda a simplificar a modelagem de comportamentos complexos, sendo composto de vários estados . Um superestado é composto de subestados e é chamado de estado composto. Um estado composto pode ser sequencial ou concorrente. Abaixo o exemplo de um superestado sequencial, ilustrado em 2 imagens.
O primeiro diagrama é o principal e tem 1 superestado, de nome ATIVO. Observe que ele tem um símbolo dentro, que mostra que contém em si outros estados.
A segunda imagem mostra o desdobramento do estado ATIVO, compostos dos subestados SOLICITADO, EM PRODUÇãO, EMBALANDO e ENTREGUE.
O Estado CANCELADO tem uma transição do estado ATIVO, denotando que pode haver uma transição de qualquer estado do superestado ATIVO para o estado CANCELADO. Se não fosse assim haveria 1 transição de cada estado para CANCELADO, o que não estaria errado, mas tornaria o desenho mais complexo.
Passo a passo para construção do DTE
O DTE (diagrama de transição de estado) deve ser elaborado para classes cujos objetos tenham 2 ou mais estados.
1. Identifique todos estados relevantes para a classe.
2. Analise os possíveis eventos que ocasionam mudança de estado.
Para cada evento, identifique qual a transição que ele ocasiona.
3. Para cada estado:
- Identifique as transições possíveis quando um evento ocorre;
- Identifique os eventos internos e ações correspondentes.
4. Para cada transição:
- Verifique se há fatores que influenciam no seu disparo (definição de condições de guarda e ações).
5. Para cada condição de guarda e para cada ação, identifique os atributos e ligações eenvolvidos.
6. Defina o estado inicial e os eventuais estados finais.
7. Desenhe o diagrama.
Contribuições do DTE ao diagrama de classes
O DTE pode ser construído com base nas especificações de casos de uso, nos diagramas de interação e nos diagramas de classes.
- Novas propriedades (atributos e métodos) podem ser descobertos, ao elaboramos o DTE, e devem ser incorporados ao diagrama de classes.
Pode ser necessária a atualização de um ou mais métodos de uma classe para refletir o comportamento do objetos nos respectivos estados.
- Por exemplo, o comportamento do método sacar() da classe ContaBancária varia em função do estado no qual essa classe se encontra. E saques não podem ser realizados em uma conta que esteja no estado bloqueada.
REFERENCIAS
BEZERRA, Eduardo. Princípios de análise e projeto de sistemas com UML, 2/E. 2. ed. Campus, 2006. Capítulo 1.
BOOCH, G.; JACOBSON, I.; RUMBAUGH, J. UML – guia do usuário. 2. ed. Rio de Janeiro: Campus, 2006.
FOWLER, M. UML Essencial: um breve guia para a linguagem-padrão de modelagem de objetos. 3. ed. Porto Alegre: Artmed, 2005.
LARMAN, C. Utilizando UML e padrões: uma introdução à análise e ao projeto orientados a objetos e ao desenvolvimento interativo. 3. ed. Bookman, 2008.
PRESSMAN, R. S. Engenharia de Software: uma abordagem profissional. 7. ed. McGraw Hill Brasil – Grupo A, 2011.
SOMMERVILLE, I. Engenharia de Software. 8. ed. Pearson, 2007.
Engenharia de Software | Linguagem de modelagem unificada (UML) | Diagramas de Sequência, de Estados e de Atividade