Comentários
Modelagem a partir do Diagrama de Estrutura Composta das principais colaborações do sistema e, posteriormente a modelagem comportamental e de interação do sistema com a especificação dos principais Diagramas de Atividades, Diagramas de Máquina de Estados e Diagramas de Sequência.
Fonte: Shutterstock.
Deseja ouvir este material?
Áudio disponível no material digital.
Caro aluno, seja bem-vindo à seção sobre a modelagem complementar da atividade de Análise e Projeto do estudo de caso proposto!
Nesta seção continuamos a modelagem estrutural do sistema “Locação de Veículos”, a partir do Diagrama de Estrutura Composta. Na sequência, enfatizamos a modelagem dinâmica do sistema, considerando a adoção do Diagrama de Máquina de Estados para especificar os estados relevantes e suas transições de estados dos objetos das classes já identificadas no Diagrama de Classes. Por fim, adotamos o Diagrama de Atividades e o Diagrama de Sequência para documentar a realização dos principais casos de uso do sistema.
O Diagrama de Estrutura Composta é um novo diagrama estrutural da UML 2.0, que representa as colaborações entre elementos que cooperam entre si para executar uma função específica, ou seja, a realização de um ou mais casos de uso. O diagrama apresenta exatamente quais objetos são manipulados na execução de um caso de uso, assim, é importante adotá-lo para representar a colaboração entre os objetos de casos de uso mais complexos ou exatamente os casos de uso que representam as principais funcionalidades de negócio do sistema. Por exemplo, dos casos de uso identificados no sistema “Locação de Veículos”, foi elaborado o Diagrama de Estrutura Composta para os casos de uso “Reservar Carro”, “Alugar Carro” e “Devolver Carro”.
O Diagrama de Máquina de Estados mostra o comportamento de um elemento a partir de um conjunto finito de estados e suas transições de estado que expressam o comportamento de um caso de uso ou dos objetos de uma classe. O diagrama foi elaborado para as classes de objetos que identificamos e definimos estados relevantes, sendo as classes “Reserva”, “Pessoa”, “Carro” e “AluguelDevolucao”.
O Diagrama de Atividades mostra o fluxo de controle de um conjunto de atividades que representa a execução do sistema completo de processos de negócio, de casos de uso ou de até mesmo de um procedimento específico, referente a uma funcionalidade. Na modelagem da UML, o diagrama é fortemente recomendado para especificar os casos de uso, demonstrando, assim, o fluxo das ações necessárias para realizar o caso de uso. O Diagrama de Atividades foi elaborado correspondendo aos casos de uso “Reservar Carro” e “Acessar Conta Cliente”.
Finalizamos a modelagem aplicada à análise do sistema com o Diagrama de Sequência. Esse é um importante diagrama comportamental da UML que representa a ordem temporal em que as mensagens são trocadas entre os objetos envolvidos na execução de um processo, ou seja, de um caso de uso. Assim, o diagrama foi elaborado para especificar a realização dos casos de uso “Alugar Carro” e “Devolver Carro”.
Na Seção 4.1 você iniciou a modelagem estrutural do módulo “Pagamento”, que está integrado ao sistema de “Locação de Veículos”. Agora você, como analista de sistemas responsável por esse módulo, precisa avançar com a modelagem comportamental.
Na solução apresentada para a especificação do Diagrama de Classes, você observou que definimos um atributo situação para a classe “Caixa”, conforme ilustra a Figura 4.14. Então, vamos considerar que os objetos dessa classe apresentam os estados definidos a seguir, para o melhor controle e agilidade das consultas e relatórios gerados sobre os pagamentos efetuados.
Para os objetos da classe “Caixa”, os estados definidos são: Aberto, Liberado e Fechado. As regras definidas são as seguintes:
Reforce o seu aprendizado com a modelagem do projeto. Bom trabalho!
Considerando que o Diagrama de Casos de Uso e o Diagrama de Classes da atividade de Análise estão prontos, avançamos com a modelagem do sistema “Locação de Veículos”, enfatizando a modelagem comportamental das funcionalidades do sistema. Assim, vamos aplicar as principais técnicas de modelagem comportamentais da UML para representar o comportamento e a interação entre os elementos do sistema e, dessa forma, documentar a perspectiva da visão dinâmica do sistema.
Conforme a classificação das técnicas de modelagem da UML em estruturais e comportamentais, a perspectiva de interação representa um subgrupo dos diagramas comportamentais, que mostra a interação de como os objetos do sistema se comunicam, apoiando a realização das funcionalidades representadas pelos casos de uso. Para facilitar a compreensão da interação entre os objetos que participam da realização dos casos de uso correspondentes ao negócio do domínio do sistema – reserva, aluguel e devolução –, vamos primeiramente representar o Diagrama de Estrutura Composta.
O Diagrama de Estrutura Composta é um diagrama estrutural da UML que visa identificar a arquitetura do conjunto de elementos que interagem entre si durante a execução do sistema, formando uma colaboração entre esses elementos que se comunicam, contudo não especifica o comportamento da colaboração, que é o objetivo dos diagramas comportamentais da UML.
Segundo Guedes (2018), o Diagrama de Estrutura Composta representa a estrutura interna de um componente, classe ou uma colaboração entre um conjunto de instâncias que cooperam entre si para realizar uma tarefa, a partir da descrição das partes que o compõem e se comunicam, ou seja, a estrutura refere-se a uma composição de elementos interconectados por vínculos de comunicação que colaboram entre si para atingir um objetivo. Assim, foi adotado o Diagrama de Estrutura Composta para representar a colaboração dos casos de uso “Reservar Carro”, “Alugar Carro” e “Devolver Carro”.
A Figura 4.15 ilustra o Diagrama de Estrutura Composta correspondente à colaboração denominada “Reservar Carro”, que abrange o caso de uso “Reservar Carro” e seus relacionamentos – “Imprimir Comprovante de Reserva” e “Enviar E-mail do Comprovante da Reserva”. Observe que o diagrama representa a colaboração, considerando que durante a execução dos casos de uso que integram a colaboração, cada reserva é instanciada na classe reserva (Reserva) e, para cada reserva, estabeleceu-se um vínculo que apresenta a comunicação entre os objetos que interagem para atingir o objetivo de efetivação de uma reserva. Dessa forma, compreende-se que cada reserva pode referenciar:
Importa destacar que se um Diagrama de Estrutura Composta elaborado corresponde à colaboração de casos de uso, o nome da colaboração pode ser o mesmo de um caso de uso porque uma colaboração pode representar exatamente um único caso de uso ou mais de um caso de uso, desde que sejam casos de uso relacionados.
A Figura 4.16 ilustra o Diagrama de Estrutura Composta correspondente à colaboração denominada “Alugar Carro”, que abrange o caso de uso “Alugar Carro” e seus relacionamentos – “Reservar Carro”, “Emitir Contrato de Aluguel” e “Enviar E-mail do Comprovante do Aluguel”. Observe que o diagrama representa a colaboração, considerando que durante a execução dos casos de uso que integram a colaboração, cada aluguel é instanciado na classe aluguel (Aluguel) e, para cada aluguel, estabeleceu-se um vínculo que demonstra a comunicação entre os objetos que interagem para atingir o objetivo de efetivação de um aluguel. Dessa forma, compreende-se que cada aluguel pode referenciar:
E a Figura 4.17 ilustra o Diagrama de Estrutura Composta correspondente à colaboração denominada “Devolver Carro” que abrange o caso de uso “Devolver Carro” e seus relacionamentos – “Efetuar Pagamento” e “Emitir Nota Fiscal de Serviço”. Observe que o diagrama representa a colaboração, integrando seus elementos que participam da baixa de um objeto aluguel, assim, cada devolução refere-se:
A especificação do Diagrama de Estrutura Composta é importante para apoiar a modelagem comportamental do sistema e, assim, consolidar o entendimento de como funcionará em tempo de execução do sistema cada caso de uso, contribuindo para a melhor compreensão do contexto do sistema.
O Diagrama de Estrutura Composta representa as colaborações entre elementos que cooperam entre si para executarem uma função específica a partir da descrição das partes que o compõem e se comunicam. É um novo diagrama da UML 2.0 com notação gráfica simplificada, contudo ilustra exatamente os objetos das classes que participam da realização de um caso de uso ou de vários que integram uma colaboração.
Na sequência, vamos iniciar a modelagem dos estados de objetos que têm estados relevantes. Diante do contexto e de algumas regras de negócio já definidas na descrição do estudo de caso, as classes de objetos identificadas com estados relevantes no Diagrama de Classes especificado são “Reserva”, “Carro” e “Pessoa”. Entretanto, para melhor controle e agilidade das consultas e relatórios, também foi definida a classe “AluguelDevolucao”, com estados relevantes.
Segundo Booch, Jacobson e Rumbaugh (2006, p. 285), o Diagrama de Máquina de Estados representa “[…] um comportamento que especifica as sequências de estados pelos quais um objeto passa durante seu tempo de vida em resposta a eventos, juntamente com suas respostas a esses eventos”.
Lembre-se de que na elaboração do Diagrama de Máquina de Estados é fundamental identificar as regras de negócio aplicadas ao contexto dos objetos com estados relevantes, definindo consistentemente os estados e suas transições de estados, que são os elementos básicos do diagrama.
A seguir, são apresentadas as regras de negócio que indicam as transições de estados de cada classe e o seu Diagrama de Máquina de Estados correspondente.
Para os objetos da classe “Pessoa”, que pode ser uma pessoa física no papel de cliente ou uma pessoa jurídica no papel de empresa, os estados definidos são: Ativa, Preferencial, Inadimplente e Encerrada. As regras definidas são as seguintes:
O Diagrama de Máquina de Estados ilustrado na Figura 4.18 ilustra os estados definidos para os objetos da classe “Pessoa”, e suas transições de estados são indicadas com as condições de guarda, em conformidade com as regras de negócio indicadas.
![A imagem ilustra o diagrama de máquina de estados da classe Pessoa, mostrando o estados inicial, Ativando com a ação do: AtivarPessoa, Tornando preferencial com a ação do: tornarPreferencialPessoa, tornando inadimplente com a ação do: tornarinadimplentePessoa, encerrando com a ação do: encerrarPessoa e estado final. Do estado Ativando para o tornando preferencial há uma transição com o texto tornar Preferencial [igual 10 objetos aluguel registrados]. Do estado Ativando para o tornando inadimplente há uma transição com o texto tornar Inadimplente [igual objeto pagamento não realizado]. Do estado Tornando Inadimplente para Ativando há uma transição com o texto ativar [igual objeto pagamento pendente realizado]. Do estado tornando Preferencial para o Tornando inadimplente há uma transição com o texto tornar inadimplente [= objeto pagamento não realizado no prazo de 30 dias]. Do estado Ativando para o Encerrando há transição com o texto encerrar [usuário igual gerente determinar]. Do estado encerrando há uma transição para o estado final.](assets/img/Figura_4-18.png)
Para os objetos da classe “Reserva”, os estados definidos são: Realizada, Confirmada e Cancelada. As regras definidas são:
O Diagrama de Máquina de Estados ilustrado na Figura 4.19 ilustra os estados definidos para os objetos da classe “Reserva” e suas transições de estados são indicadas com as condições de guarda, considerando as regras de negócio apresentadas.
![A imagem ilustra o diagrama de máquina de estados da classe Reserva mostrando os estados inicial, Realizando com a ação do: realizarReserva, Confirmando com a ação do: confirmarReserva, Cancelando com a ação do: cancelarReserva e estado final. Do estado Realizando para o Confirmando há uma transição com o texto tornar Confirmar [igual objeto aluguel registrado]. Do estado Realizando para o cancelando há uma transição com o texto tornar Cancelar[igual objeto aluguel não registrado na data de início da reserva]. Dos estados Cancelando e Confirmando transição para o estado final.](assets/img/Figura_4-19.png)
Para os objetos da classe “Carro”, os estados definidos são: Disponível, Alugado, Manutenção Interna, Manutenção Externa e Inativo. As regras definidas são:
O Diagrama de Máquina de Estados ilustrado na Figura 4.20 ilustra os estados definidos para os objetos da classe “Carro”, e suas transições de estados são indicadas com as condições de guarda, considerando as regras de negócio apresentadas.
![A imagem ilustra o diagrama de máquina de estados da classe Carro mostrando os estados inicial, Disponibilizando com a ação do: disponibilizarCarro, Alugando com a ação do: alugarCarro, Encaminahndo ManutençãoInterna com a ação do: encaminharManutençãoInterna, EncaminhandoMatenaçãoExterna com a ação do encaminharManutençãoExterna, Inativando com a ação: InativarCarro e Estado final. Do estado Disponibilizando para o alugando há uma transição com o texto tornar alugar [igual objeto aluguel registrado]. Do estado Disponibilizando para o Encaminhando ManutençãoInterna há uma transição com o texto manutenir [usuário igual gerente determinar]. Do estado alugando para o Encaminhando ManutençãoInterna há uma transição com o texto manutenir [igual objeto aluguel baixado para devolução] Do estado Encaminhando ManutençãoInterna há uma condicional entre os estados disponibilizando com o texto disponibilizar [usuário igual oficina liberar] e encaminhando manutenção externa com o texto manutenir [ usuário igual gerente autorizar]. Do estado Encaminhado Manutenção Externa para encaminhando manutenção interna há uma transição com o texto manutenir. Do estado Encaminhando ManutençãoInterna para Inativando tem uma transição com o texto inativar [usuário igual gerente determinar]. Do estado inativando há a transição para o estado final.](assets/img/Figura_4-20.png)
Para os objetos da classe “AluguelDevolução”, os estados definidos para o lançamento de um aluguel são: Realizado, Registrado e Cancelado. As regras definidas são as que seguem:
Para os objetos da classe “AluguelDevolução”, os estados definidos para o lançamento da devolução do carro são: Recuperado, Atualizado e Cancelado. As regras definidas são:
O Diagrama de Máquina de Estados ilustrado na Figura 4.21 ilustra os estados definidos para os objetos da classe “AluguelDevolucao”, e suas transições de estados são indicadas com as condições de guarda, considerando as regras de negócio apresentadas. O diagrama mostra um estado composto para a ocorrência do aluguel de um carro e outro estado composto para a ocorrência da devolução, pois ocorrem em período distinto, sendo a devolução uma atualização ou “baixa” do aluguel.
![A imagem ilustra o diagrama de máquina de estados da classe AluguelDevolução mostrando os estados compostos alugando e Devolvendo. Do estado inicial segue para o estado composto Alugando com a ação do: alugar carro, com três estados internos: Realizando com as ações entry: verificarSitauçãoPessoa e do: realizarAluguel; Registrando com as ações do: registrarAluguel e exit: atualizarSituaçãoCarro, e Cancelando com a ação: cancelarAluguel. Do estado Realizando sai uma condicional para Registrando com o texto registrar[cliente confirmar aluguel] e para o Cancelando com o texto cancelar[cliente não confirmar aluguel]. Dos estados Registrando e Cancelando há transição para o estado final. Na sequência, temos uma transição para o estado composto Devolvendo com a ação do: Devolver carro, com três estados internos: Recuperando com a ação do: recuperarAluguel; Atualizando com as ações do: atualizarAluguel e exit: atualizarSituaçãoCarro, e Cancelando com a ação do: cancelarDevolução. Do estado Recuperando sai uma condicional para Atualizando com o texto atualizar[cliente confirmar devolução] e para o Cancelando com o texto cancelar[cliente não confirma devolução]. Dos estados Atualizando e Cancelando há transição para o estado final. A ação exit em registrando e atualizando está relacionado com a classe carro fora dos estados alugando e devolvendo.](assets/img/Figura_4-21.png)
Observe no diagrama que em ambos os estados compostos foi indicada uma ação de estado do tipo saída (cláusula “Exit”), referenciando a operação atualizarSituacaoCarro nos subestados “Registrando” e “Atualizando” dos estados “Alugando” e “Devolvendo”, respectivamente. A partir do registro de um aluguel, a situação do carro deve ser atualizada para “Alugado” e, posteriormente, ao efetivar a devolução do carro, a situação do carro deve ser atualizada para “Manutenção Interna”.
Considerando as particularidades de cada domínio de sistema, as regras de negócio aplicadas às transições de estados dos objetos são de total responsabilidade do analista de sistemas?
Posteriormente, na atividade de implementação do processo de desenvolvimento do sistema, a especificação do Diagrama de Máquina de Estados apoiará a implementação consistente das classes, em conformidade com as regras de negócio definidas para os estados dos objetos do sistema.
Considerando que os casos de uso estão definidos, é importante evoluir com a modelagem comportamental do sistema para uma melhor compreensão da lógica de funcionamento de cada caso de uso.
A UML não estabelece qual técnica de modelagem comportamental ou de interação é a ideal para especificar cada caso de uso. Você, como analista de sistemas ou de acordo com a metodologia de desenvolvimento da empresa, deverá definir a melhor técnica de modelagem comportamental da UML a ser adotada, conforme as características ou aplicabilidade de cada caso de uso. Assim, adotamos a técnica de modelagem Diagrama de Atividades para especificar dois casos de uso, o “Reservar Carro” e o “Acessar Conta Cliente”.
Segundo Bezerra (2014, p. 307), o Diagrama de Atividades
[…] pode ser visto como uma extensão dos fluxogramas. Além de possuir toda a semântica existente em um fluxograma, o diagrama de atividade possui notação para representar ações concorrentes, juntamente com a sua sincronização.
O Diagrama de Atividades demonstra o fluxo de controle de um conjunto de atividades que representa a execução de caso de uso, processo de negócio, subsistema ou até mesmo do sistema completo, ou seja, descreve os passos a serem percorridos para a realização de uma atividade específica.
Documentação do caso de uso – Reservar Carro:
Nome do caso de uso: Reservar Carro.
Descrição: Cliente solicita reservar um carro.
Ator principal: Cliente.
Cenário Principal:
A partir da descrição do cenário principal do caso de uso “Reservar Carro”, a Figura 4.22 ilustra o Diagrama de Atividades correspondente, no formato de fluxos de controle sequencial. Lembre-se que conforme orientação da UML, a nomenclatura dos elementos básicos do diagrama – Atividade ou Nó de Ação deve-se iniciar com verbo no infinitivo e sempre na perspectiva de execução do sistema, ou seja, se o cliente informou os dados, na perspectiva do sistema, o sistema recebe ou aceita os dados. Ainda, uma Atividade representa a sequência de tarefas em um fluxo de trabalho que resulta no comportamento de um processo, sendo que uma atividade é composta por um conjunto de ações.
Observe na Figura 4.22 que alguns nós de ação, como o “Recuperar lojas/filiais para retirada” acessa o nó de objeto “FilialLoja”, o “Recuperar grupos de carros disponíveis para reserva” acessa o nó de objeto “GrupoCarro” e assim por diante. No diagrama, todos os elementos representados por um retângulo pequeno com bordas arredondadas e um nome centralizado, na cor cinza, são nós de ação, com exceção do elemento “Manter cliente”, na cor branca, que representa uma atividade correspondente ao caso de uso para cadastrar um cliente novo. Por convenção da ferramenta CASE Visual Paradigm, o nome do elemento Atividade também é centralizado, contudo fica disposto na parte superior do retângulo com bordas arredondadas.
![A imagem ilustra o diagrama de máquina de atividades Reservar carro, a atividade inicia-se com a representação do nó de ação nomeado de Disponibilizar reserva, o fluxo segue para o nó de ação receber dados da retirada do carro, o fluxo segue para o nó de ação recuperar lojas/filiais para retirada, que acessa o nó de objeto FilialLoja, na sequência o fluxo segue para o nó de ação definir loja/filial de retirada, o fluxo segue para o nó de ação receber dados da devolução do carro, o fluxo segue para o nó de ação para recuperar lojas/filiais para devolução, que acessa o nó de objeto FilialLoja2, na sequência o fluxo segue para o nó de ação Definir loja/filial de devolução, o fluxo segue para o nó de ação recuperar grupos de carros disponíveis para reserva, que acessa o nó de objeto GrupoCarro, na sequência o fluxo segue para o nó de ação definir grupo de carros para reserva, o fluxo segue para o nó de ação recuperar itens opcionais de carro, o fluxo segue para o nó de ação definir itens opcionais para o carro reservado, o fluxo segue para o nó de ação receber dados do cliente, o fluxo segue para um nó de decisão, sendo na condição cliente cadastrado o fluxo segue direto para o nó de ação recuperar dados da conta do cliente, sendo a condição [cliente não cadastrado] o fluxo segue para o nó de ação Manter cliente, o fluxo segue para o nó de ação recuperar dados da conta do cliente, que acessa o nó de objeto PessoaFísica, na sequência o fluxo segue para o nó de ação calcular valor total da reserva, o fluxo segue para o nó de ação confirmar reserva, o fluxo segue para um nó de decisão, sendo na condição [não] o fluxo segue para o nó de ação cancelar, que segue para o estado final, sendo a condição [sim], o fluxo segue para o nó de ação registrar reserva, que acessa o nó de objeto Reserva, o fluxo segue para o nó de bifurcação com uma entrada e três fluxos de saídas Enviar comprovante da reserva por email, enviar comprovante da reserva por SMS, Disponibilizar comprovante para impressão, que finalizam com o nó final.](assets/img/Figura_4-22.png)
A Figura 4.23 ilustra o Diagrama de Atividades correspondente ao caso de uso “Acessar Conta Cliente”, também no formato de fluxos de controle sequencial. Observe que no diagrama constam a chamada a duas atividades – “Manter Cliente”, a partir da condição de cadastrar novo cliente, e “Trocar Senha”, a partir da condição de cadastrar nova senha. No nó de ação “Aceitar Senha” foi indicado uma restrição, representada no elemento nota, indicando o limite de três tentativas para aceitar uma nova senha.
![A imagem ilustra o diagrama de máquina de atividades Acessar Conta Cliente, a atividade inicia-se com a representação do nó de ação nomeado de Disponibilizar acesso à conta do cliente ou cadastrar novo cliente, o fluxo segue para um nó de decisão, sendo na condição [novo cliente] o fluxo segue Manter cliente, sendo na condição [acessar conta], o fluxo segue para o nó de ação receber login(e-mail) e senha, o fluxo segue para o nó de ação Validar e-mail correto, o fluxo segue para o nó de decisão, sendo na condição [não] o fluxo segue para o nó de ação exibir mensagem, informando que e-mail não é válido, o fluxo segue para o nó de ação aceitar e-mail, e o fluxo volta para o nó de ação validar e-mail correto, sendo na condição [sim], o fluxo segue para o nó de ação validar existência e-mail, o fluxo segue para o nó de decisão, sendo na condição [não existe], o fluxo segue para o nó de ação exibir mensagem, informando que o cliente não possui cadastro, o fluxo segue para o nó de ação disponibilizar cadastro de cliente, que finaliza com o nó final, sendo na condição [existe], o fluxo segue para o nó de ação validar senha, o fluxo segue para o nó de decisão, sendo na condição incorreta, o fluxo segue para o nó de ação exibir mensagem, informando que a senha é incorreta, o fluxo segue para o nó de de decisão, sendo a condição [nova senha] o fluxo segue para o nó de objeto trocar senha que finaliza com o nó final, na condição nova tentativa, o fluxo segue para o nó de ação aceitar senha com a indicação de restrição representado por uma nota do limite de 3 tentativas, senão bloqueia, o fluxo volta para o nó de ação validar senha, e na condição [correta], o fluxo segue para o nó de ação acessar conta do cliente que finaliza com o nó final.](assets/img/Figura_4-23.png)
A Figura 4.24 ilustra um exemplo de Diagrama de Atividades correspondente à atividade “Processar Pedido de Venda”, composta pelo fluxo de ações que apresentam o processo de um pedido de venda, específico para um domínio de vendas. O diagrama contempla a representação dos principais elementos de um Diagrama de Atividades.
A atividade inicia-se com a representação do nó de ação nomeado de Receber Pedido Venda, sinalizada com o nó inicial, que acessa o nó de objeto PedidoVenda, a partir de um fluxo de objeto. Na sequência, o fluxo de controle segue para um nó de decisão com duas decisões, cada uma indicada por uma condição de guarda, sendo que na condição “pedido completo”, o fluxo segue para um nó de bifurcação com uma entrada e dois fluxos de saída concorrentes, seguindo para um nó de união com dois fluxos de entrada e um único fluxo de saída direcionado para um nó decisão, que finaliza a atividade com a ação Finalizar Pedido Venda, sinalizada com o nó final.
Para finalizar a modelagem comportamental dos principais casos de uso, na sequência apresentamos os Diagramas de Sequência correspondentes aos casos de uso “Alugar Carro” e “Devolver Carro”.
Na modelagem da atividade de análise, recomenda-se utilizar o Diagrama de Sequência para descrever a realização dos casos de uso, representando os objetos que colaboram entre si a partir da troca de mensagens entre eles.
Segundo Bezerra (2014, p. 193), “[…] o objetivo do diagrama de sequência é apresentar as interações entre objetos na ordem temporal em que elas acontecem”.
Os principais elementos que compõem o Diagrama de Sequência são: Linha de Vida, Ator, Objeto, Foco de Controle e as Mensagens do tipo – síncrona, assíncrona, de retorno e de autochamada.
A Figura 4.25 ilustra o Diagrama de Sequência correspondente ao caso de uso “Alugar Carro”. O diagrama ilustra a interação entre os elementos ator Cliente; a linha de vida “Form_Alugar Carro” que representa a interface gráfica correspondente ao caso de uso, sendo que a partir dela o ator interage com o sistema; e as linhas de vida “Aluguel:AluguelDevolucao”, “reserva:Reserva”,”pessoaFisica:PessoaFisica”, “filialLoja:FilialLoja”, “carro:Carro” e “itemAdicional:ItemAdicional”, que representam os objetos que trocam as mensagens durante a realização do caso de uso. As mensagens 7 e 7.1 fazem parte de um fragmento combinado do tipo loop, indicando que vários itens adicionais podem ser selecionados para o carro alugado, enquanto o cliente indicar. Finalizando o processo do aluguel, ao registrar o aluguel do carro é indicado um fragmento de interação que é disparado para chamar o caso de uso de “Emitir Contrato de Aluguel”.
Lembre-se de que a representação dos fragmentos combinados ou dos fragmentos de interação possibilita o alinhamento de interações, sendo que cada fragmento representa uma interação independente e o mesmo fragmento de interação pode ser utilizado em vários Diagramas de Sequência.
A Figura 4.26 ilustra o Diagrama de Sequência correspondente ao caso de uso “Devolver Carro”. O diagrama ilustra a interação entre os elementos ator Cliente; a linha de vida “Form_Devolver Carro” que representa a interface gráfica correspondente ao caso de uso, sendo que a partir dela o ator interage com o sistema; e as linhas de vida “Aluguel:AluguelDevolucao” e “carro:Carro”, que representam os objetos que trocam as mensagens durante a realização do caso de uso. Após o cliente informar os dados do pagamento do aluguel, é indicado o fragmento de interação que é disparado para chamar o caso de uso “Efetuar Pagamento”. Por fim, outro fragmento de interação que chama o caso de uso é “Emitir Nota Fiscal de Serviço”.
Assim como as demais técnicas de modelagem da UML que podem ser apresentadas em diferentes níveis de detalhamento, o mesmo Diagrama de Sequência pode ser refinado em conformidade com padrões de implementação e compor a modelagem da atividade de projeto.
Das diferentes técnicas de modelagem comportamentais da UML, o Diagrama de Sequência é a técnica recomendada para especificar as interações entre os objetos que realizam os casos de uso. Assim, obrigatoriamente é necessário elaborar um Diagrama de Sequência para cada caso de uso?
Por fim, a partir do Diagrama de Sequência do caso de uso “Alugar Carro” gerou-se, automaticamente, na ferramenta CASE Visual Paradigm, o Diagrama de Comunicação correspondente ao caso de uso “Alugar Carro”. Observe que o diagrama representado na Figura 4.27 enfatiza exatamente a ligação por vínculos entre os objetos representados pela Lifeline, que participam da realização do caso de uso.
O Diagrama de Comunicação não demonstra a temporalidade da realização de um processo, no entanto, representa o relacionamento entre os objetos envolvidos na realização do caso de uso, agrupando as mensagens entre os objetos que participam de uma interação por vínculos estabelecidos entre os objetos.
BEZERRA, E. Princípios de análise e projeto de sistemas com UML. 3. ed. Rio de Janeiro: Elsevier, 2014.
BOOCH, G.; RUMBAUGH, J.; JACOBSON, I. UML: guia do usuário. 2. ed. Rio de Janeiro: Campus, 2006.
FELDERER, M.; HERRMANN, A. Comprehensibility of system models during test design: a controlled experiment comparing UML activity diagrams and state machines. Software Quality Journal, [s. l.], v. 27, n. 1, p. 125–147, 2019. DOI 10.1007/s11219-018-9407-9. Disponível em: Biblioteca Virtual – EBSCO HOST. https://bit.ly/3bBE3BI. Acesso em: 17 jun. 2020.
GUEDES, G. T. A. UML: uma abordagem prática. 3. ed. São Paulo: Novatec, 2018.
MEDEIROS, E. S. Desenvolvendo software com UML 2.0: definitivo. São Paulo: Pearson, 2004.
PRESSMAN, R.; MAXIM, B. Engenharia de software: uma abordagem profissional. 8. ed. Porto Alegre: AMGH, 2018.
