Aula 5 Conteudo Online

Prévia do material em texto

Diagramas de interação 
Os sistemas orientado a objetos implementam as funcionalidades que oferecem, pela troca de mensagens entre 
os objetos, ou seja, um objeto envia uma mensagem a outro quando deseja que este realize uma tarefa. Baseado 
nesse contexto, podemos entender de que forma os diagramas de interação atuam. Vamos entender isso 
partindo do conceito de diagrama de casos de uso e diagrama de classes. Veja: O diagrama de casos de uso 
apresenta as funcionalidades. O diagrama de classes mostra a estrutura (nome, atributos e métodos) e 
relacionamentos entre as classes necessárias ao sistema. Os diagramas de interação mostram como as classes 
(na verdade, os objetos) trocam mensagens, ou seja, interagem para oferecer uma funcionalidade (ou realizar um 
caso de uso). Uma mensagem representa a solicitação que um objeto requisitante faz a um objeto receptor para 
que este execute uma das operações definidas em sua classe. 
Tipos de diagramas de interação: Os diagramas de interação, de uma forma geral, mostram como as classes 
colaboram em determinados comportamentos. Visam ilustrar como os objetos interagem, por meio de 
mensagens. São dois tipos de diagramas de interação: o diagrama de sequência e o diagrama de comunicação. 
Veja algumas características desses dois tipos de diagramas de interação: 
• De uma forma genérica, o diagrama de sequência é o mais rico dos dois, mas o diagrama de comunicação 
também tem sua finalidade, na medida em que é mais flexível quanto ao desenho. Cada um dos diagramas de 
interação tem suas vantagens e desvantagens que os tornam úteis em diferentes situações. 
• De uma forma geral, ambos visam estabelecer a integração entre o diagrama de classes e o diagrama de 
especificações textuais dos casos de uso, mostrando como as classes colaboram na realização de um cenário de 
uso (um caso de uso é um conjunto de cenários de uso). 
• Uma das grandes contribuições dos diagramas de interação é a identificação de novos métodos para as classes e 
ainda a ajuda na identificação de qual classe deve conter um determinado método. 
A UML, em sua versão 2.0, oferece algumas formas de modelar interações, e o diagrama de sequência é o mais 
usado deles. O outro é o diagrama de comunicação, que nas versões anteriores à 2.0 da UML era chamado de 
diagrama de colaboração. A seguir, veja algumas diretrizes sobre os diagramas de interação: 
• Num mesmo projeto, podemos até usar os dois diagramas de interação, mas para representar 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 focos diferentes. 
• Para cenários, casos de uso ou comportamentos diferenciados, podemos optar por um dos dois. Mas em geral, 
usa-se apenas um deles por todo o projeto. 
Comparativo: Como vimos, os diagramas de interação podem ser de dois tipos: diagrama de sequência e 
diagrama de comunicação. Cada um tem sua vantagem, que por sua vez atua como desvantagem para o outro. 
Veja, a seguir, um comparativo das vantagens, quando usar, pontos fortes e fracos de cada tipo de diagrama: 
 
 
O tripé da análise: Do ponto de vista da fase de análise 
de sistemas, existem três modelos que se integram e 
formam uma base mínima para a modelagem e 
documentação de sistemas. São eles: 
• Diagrama de casos de uso e especificações de casos 
de uso; 
• Diagrama de classes; 
• Diagrama de sequência ou diagrama de colaboração. 
Esses três diagramas formam o chamado tripé da 
análise. Veja essa relação na figura ao lado: 
Casos de uso (em suas especificações) — Especificam o comportamento do sistema (ou parte dele), descrevendo 
as funcionalidades deste. O caso de uso é um conjunto de cenários, no qual: • O cenário é uma sequência de 
passos que descreve uma interação entre o 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 conceitual de classes mostra as classes do domínio do problema. 
O diagrama de sequência ou comunicação mostra a interação (como trocam mensagens) entre os objetos 
(classes) de um determinado cenário (caso de uso). 
Pontos importantes sobre o diagrama de interação: 
 Para cada cenário de um caso de uso, teremos um diagrama de interação.  Em contrapartida, os diagramas de 
interação contribuem com a descoberta de novas operações, que serão acrescidas nos métodos das classes 
envolvidas.  É sob essa ótica que desenvolveremos o diagrama de sequência, tendo 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 melhorias e acréscimos tanto nas especificações de casos de uso, no 
diagrama de casos de uso quanto, principalmente, no diagrama de classes. Neste, além de novos métodos para as 
classes já existentes, poderemos também modelar novas classes e até mesmo atributos.  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. 
O Diagrama de Sequência: A partir de agora vamos conhecer as 
especificidades do diagrama de sequência. Você já sabe que 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), ao longo da linha do tempo. O foco aqui é a 
sequência da troca de mensagens. Assim, o diagrama de 
sequência mostra o passo a passo da especificação do cenário 
de uso, evidenciando as classes relacionadas e como elas 
trocam mensagens entre si, conforme ilustra a imagem (trecho 
de diagrama de sequência) a seguir: 
O objeto Controlador envia uma mensagem de nome Procurar 
Cliente() ao objeto Cliente. 
O Diagrama de Sequência e seus Elementos: Dentre os elementos principais de um diagrama de sequência, 
podemos destacar: • Os objetos participantes da interação são organizados na horizontal; • Abaixo de cada 
objeto, existe uma linha pontilhada (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. 
Exemplo de diagrama de sequência: A seguir, veja um 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 ator é o mesmo do caso de uso: 
Correntista, com a mesma representação do 
boneco (stickman); 2. Interface é o formulário 
com o qual o ator interage com o sistema; 3. 
Conta Corrente e Movimento Conta são classes 
do modelo conceitual de classes, envolvidas no 
cenário de uso em questão; 4. Agência e Conta 
e Senha são dados informados pelo ator correntista, sobre sua conta corrente; 5. Validar AgConta (Agência e 
Conta) e Validar Senha () são métodos da classe Conta Corrente, que são acionados por uma mensagem 
(síncrona) enviada à classe; 6. ObterSaldoConta (Agência, 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 que está sendo chamado pertence à 
própria classe. Isto também é chamado de autodelegação; 8. A linha pontilhada vertical queaparece em cada 
elemento — Ator, Interface e Classes, chama-se Linha da Vida; 9. As caixas que aparecem ao longo da linha da 
vida, abaixo de cada elemento (ator, interface e classes), 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 Validar Senha tem [Agência e 
Contas Validas]. Esta é 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 (Agência, Conta e Data), temos a condição de guarda [Agência, Conta e Senha válidos], 
indicando que o referido método apenas será executado se a condição for verdadeira. Para chegamos a esse dia-
grama de sequência, tínhamos o seguinte em mãos (Cabe destacar que o diagrama de sequência apresentado re-
fere-se ao Cenário Principal do caso de uso Emitir Saldo Conta, abaixo descrito e cujo trecho de diagrama segue): 
1) Especificação de casos de uso Caso de uso: Emitir Saldo Conta - Cenário principal: 1. Correntista informa 
agência e conta corrente; 2. Sistema valida agência 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. Sistema apresenta saldo ao correntista. 
2) Trecho de diagrama de caso de uso relacionado à interação → 
3) Diagrama de classes – Esta figura exibe o trecho de dia- 
grama de classe relacionado a esse diagrama de sequência: ↓ 
 
 
 
Exemplo dos principais elementos do diagrama de sequência: A 
figura a seguir, extraída do livro UML essencial: um breve guia 
para a linguagem-padrão de modelagem de objetos, 3a edição, 
de Martin Fowler, mostra os elementos principais de um 
diagrama de sequência. Todos os elementos que citamos no 
exemplo dado acima estão bem elucidados na imagem: 1) 
Participantes - Ator e classes que participam da interação; 2) 
Linha da vida de cada participante (classes: Um Pedido, Uma 
Linha de Pedido, Um Produto e Um Cliente); 3) Caixa de ativação, 
indicando o quanto o participante está ativo na interação; 4) 
Mensagem – Chamado de um método da classe, aonde chega a 
mensagem; 5) Retorno – Mensagem de retorno da mensagem 
(chamada ao método da classe); 6) Autochamada – Chamada de um método da própria classe. No exemplo 
anterior, corresponde ao método calcular PreçoBase, da classe um Pedido. 
Representando decisões no diagrama de sequência: Muitas vezes, precisamos representar que determinadas 
mensagens serão enviadas ou não de acordo com a chamada condição de guarda; ou ainda representar um 
conjunto de mensagens mutuamente exclusivas (no qual, dentre várias mensagens possíveis, apenas uma delas é 
enviada). Na imagem a seguir, vemos um trecho 
de diagrama de sequência, no qual representa-
mos a decisão. Observe que temos o retângulo, 
com uma linha tracejada dentro, com o rótulo de 
nome “alt”, indicando um fragmento alternativo 
para a lógica condicional de exclusão mútua, 
expresso em guardas. 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 = J]. Descrição: 
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 da linha tracejada; a. Ator informa os dados da pessoa 
física (dados cliente físico); 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, na 
qual temos 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 a linha tracejada; a. Ator informa os dados da pessoa 
jurídica (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. 
 
Além dos elementos já discutidos, o diagrama de sequência possibilita que especifiquemos repetições, ou seja, 
uma ou mais mensagens que são enviadas repetidas vezes. Veja um exemplo: Esse trecho de diagrama de 
sequência representa a repetição, na caixa LOOP, chamada de 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 
(ProcurarProd(), Inserir 
Novo Item() e Incluir 
Item() ). O retângulo que 
representa a repetição 
tem o rótulo “Loop”, 
indicando fragmento de 
repetição enquanto a 
condição de guarda for 
verdadeira. Observe que 
os métodos Inserir Novo 
Item() e Incluir Item() 
serão executadas se a condição [Se produto Exists) for verdadeira. E tal condição varia em função do resultado do 
método ProcurarProd(), contido na classe Produto. 
 
Criação e destruição de objetos: O diagrama de sequência dispõe de duas notações extras para representar, 
respectivamente, a criação (<<Create>>) e a destruição (<<Destroy>>) 
de objetos participantes da interação. A seguir, veja exemplos das 
duas notações: 
Uso da criação: Na figura ao lado, vemos o uso da criação do 
participante (Objeto Criado). Depois de criado, quando recebe a 
mensagem <<create>>, representado pelo método CriaObjeto(), o 
Objeto Criado pode receber e enviar mensagens normalmente. 
 
Uso da destruição: Nesta figura, temos o exemplo da destruição 
de objetos, quando o objeto destruidor envia a mensagem 
<<destroy>>, representado 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 (neste caso, é como se o objeto enviasse uma destruição a si próprio). 
ATENÇÃO: Como hoje as linguagens possuem um 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 aplicados sobre o diagrama de sequência, até aqui, 
usaram apenas a mensagem síncrona, ou seja, aquela que uma vez enviada, aguarda o retorno (seta pontilhada 
na direção contrária) com a sua conclusão (tal qual uma chama de rotina em um programa). O outro tipo é a 
mensagem assíncrona, ou seja, a que uma vez enviada não necessita esperar por uma resposta e pode continuar 
o fluxo do processamento. Um bom exemplo de uso de 
mensagens assíncronas são os sistemas que necessitam 
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 a seguir a Message2(), síncrona (seta 
cheia), para que você perceba a diferença. 
Responsabilidade das Classes: Quando definimos uma mensagem no modelo de interações, estamos atribuindo 
uma responsabilidade a uma classe. A modelagem de interações é um procedimento cuja finalidade é decompor 
as responsabilidades do sistema e alocá-las a classes. Exemplo:Se partimos do princípio que um sistema terá N 
responsabilidades, podemos pensar em algumas soluções de divisões de responsabilidades entre as classes desse 
sistema. As soluções extremas seriam: uma classe contendo as N responsabilidades ou N classes contendo uma 
responsabilidade cada. Claro que essas duas soluções são inviáveis na prática, mas entre elas existem outras 
possibilidades. A tarefa de identificação de classes e atribuição de responsabilidades é complexa e existem várias 
formas para realizá-la. A melhor solução dependerá, obviamente, da expertise do modelador e da correta 
aplicação de alguns princípios básicos de desenvolvimento de software. A coesão e o acoplamento são dois 
desses princípios. Ela é uma medida que indica o quão relacionadas (afins) são as responsabilidades de uma 
classe. Um bom projeto indica uma alta coesão, ou seja, as responsabilidades de uma classe devem ser 
fortemente relacionadas entre si. Ao modelarmos classes, uma questão de relevância surge. Veja: 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 um baixo acoplamento e alta coesão entre as classes. ATENÇÃO: Existe um padrão chamado 
de “padrão especialista” (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). 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 a 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 de classe, na qual 
inicialmente alocamos determinados métodos. 
Classes de Interface e Controle: No conceito do desenvolvimento em camadas, devemos separar as classes em: 
INTERFACE: É a classe de interface, cujo estereótipo é <<boundary>>, que identifica uma classe que serve de 
comunicação entre os atores e o sistema; CONTROLE: É a classe de controle, com o estereótipo de <<Control>>, 
que serve de intermediação entre a classe de interface e as demais classes. Fica responsável por interpretar 
eventos ocorridos sobre os objetos <<boundary>> (eventos de mouse e teclado) e encaminhar a classe correta 
que precisa receber aquele evento; ENTIDADE: São as classes de entidade, com o estereótipo <<entity>>, que 
representam as classes do domínio do problema, que 
contém o conhecimento do negócio. 
Em geral, temos uma classe de interface por cenário de 
uso e uma classe de controle por caso de uso. 
Tipicamente a sequência entre as classes ocorre conforme 
o procedimento descrito na imagem a seguir: 1) O ator 
solicita a ação desejada, pela interface do cenário de uso; 
2) A classe de interface encaminha o pedido a classe de 
controle; 3) A classe de controle traduz o pedido e solicita 
à respectiva entidade que execute determinada operação; 
4) A sequência de retornos acontece, até que pela interface com o usuário tem a sua resposta. 
Ao lado, veja o diagrama equivalente, alterando apenas 
a forma de apresentar a classe de entidade: 
 
Quando tratamos do relacionamento entre classes no 
diagrama de classes genérico, em que a classe de con-
trole intermedia a comunicação entre as classes de in-
terface e as classes de entidade, seguimos este modelo: 
 
 
 
 
 
 
 
 
 
 
 
 
 
ATIVIDADE: Com base na documentação abaixo, elabore o diagrama de sequência para o cenário principal do 
caso de uso Registrar Locação: 
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. 
 
 
 
 
 
 
 
 
 
 
* GABARITO NA PÁGINA 14 DA AULA 5 (CONTEÚDO ONLINE) 
Figura 1 DIAGRAMA DE CASO DE USO 
Figura 2 DIAGRAMA DE CLASSES 
DESCRIÇÃO DO CASO DE USO