Modelagem inicial

Modelagem de sistema com processo

unificado

Esta aula demonstra a modelagem de um estudo de caso no domínio

de locadoras de veículos, utilizando as principais técnicas de
modelagem da UML. A documentação abrange as atividades de
requisitos, análise e projeto, correspondentes à fase de elaboração do
processo unificado.
Entre os diversos modelos de processo da engenharia de software, o
processo unificado foi escolhido devido à sua característica de manter
um ciclo de vida incremental e iterativo. Esse modelo apoia o
desenvolvimento incremental, permitindo que os modelos evoluam
com a inclusão de novos detalhes durante a execução das atividades
(Workflow). A cada ciclo do processo unificado, uma nova versão do
produto é entregue aos usuários, conhecida como iteração.
A Figura 1 ilustra o ciclo de vida do processo unificado, mostrando no
eixo X as fases de Concepção, Elaboração, Construção e Transição.
Cada fase inclui um conjunto de atividades – Requisitos, Análise e
Projeto, Implementação e Testes – representadas no eixo Y, que são
executadas de forma incremental e evolutiva, resultando na entrega
dos artefatos de software. A figura destaca a fase de Elaboração, na
qual predominam as atividades de Requisitos e Análise e Projeto. A
documentação a seguir detalha as principais técnicas de modelagem
estruturais e comportamentais da UML adotadas na modelagem do
estudo de caso proposto.
 Figura 1 |
Processo unificado. Fonte: Medeiros (2004, p. 16).
Iniciando a modelagem do sistema denominado "Locação de
Veículos" na primeira fase do processo unificado – Concepção,
considerou-se:
1. O planejamento do projeto alinhado com a metodologia definida
para o desenvolvimento do sistema.
2. A definição da ideia inicial do negócio, compreendendo o domínio
do problema ou do sistema, ou seja, entendendo o contexto para o
qual a solução foi provida.
3. A delimitação do escopo do sistema, identificando os processos de
negócio aplicáveis aos requisitos do sistema.
4. O entendimento do contexto do sistema por meio da identificação
dos atores envolvidos e a natureza da interação entre esses atores e
o sistema, em uma perspectiva de alto nível.
5. A definição dos principais casos de uso do sistema, consistindo na
compreensão dos requisitos funcionais do sistema.
Fase de elaboração

É na fase de Elaboração que se define como o sistema será

construído, a partir da especificação dos requisitos funcionais do
sistema, estabelecendo a arquitetura e mecanismos para o
desenvolvimento do sistema. Nessa fase, prevalece a execução das
atividades de Requisitos e Análise e Projeto, conforme foi destacado
na Figura 1.
Na descrição do estudo de caso é possível identificar vários requisitos
funcionais que estão explícitos na descrição, ou seja, as
funcionalidades que o sistema deve prover para os diferentes atores
que interagem com o sistema. Alguns requisitos funcionais já
descrevem as suas regras de negócio (políticas, condições ou
restrições que devem ser consideradas na execução dos processos),
como para o requisito funcional “Cadastro de Cliente” estão evidentes
algumas regras, sendo “a locadora de veículos aluga carros aos
clientes previamente cadastrados”; “um cliente ativo ou preferencial
poderá alugar vários carros em datas e horários distintos, com
reserva prévia ou não”.
Atividade de requisitos
No modelo de processo de engenharia de software conhecido como
processo unificado, a atividade de Requisitos é a primeira do ciclo de
cada fase do processo. Abstrair, entender e definir os requisitos do
domínio do problema é uma das tarefas mais desafiadoras da
engenharia de software, pois essa etapa fundamenta e sustenta todo
o processo de desenvolvimento do software.
Segundo Sommerville (2018), a engenharia de requisitos preocupa-se
com o que deve ser feito, ou seja, a compreensão do problema, e não
com como fazer, considerando o domínio do sistema. A engenharia de
requisitos é o processo de descobrir, analisar, documentar e verificar
os serviços e restrições.
Uma primeira classificação dos requisitos de um sistema é dividida
em requisitos de usuário e requisitos de sistema, conforme ilustrado
na Figura 2 (Sommerville, 2018):

 Requisitos de usuário: são declarações em uma linguagem

natural, com ou sem diagramas, sobre quais serviços o sistema
deverá fornecer aos seus usuários e as restrições sob as quais
ele deve operar.
 Requisitos de sistema: são descrições mais detalhadas das
funções, serviços e restrições operacionais do sistema de
software. O documento de requisitos do sistema, denominado
especificação funcional, deve definir exatamente o que a
funcionalidade deve implementar.

Figura 2 | Exemplo de requisito de usuário e requisito de sistema.

Fonte: Catarino (2020, p.).
Os requisitos de sistema são classificados em duas categorias:
1. Requisitos funcionais (RF): são declarações dos serviços que o
sistema deve fornecer, como o sistema deve reagir a entradas
específicas e como deve se comportar em determinadas situações.
Representam funcionalidades que o sistema deve oferecer para
atender às necessidades dos usuários.
2. Requisitos não funcionais (RNF): Expressam restrições aos serviços
ou funções, ou qualidades específicas às quais o software deve
atender. Essas restrições podem se referir a tempo, ao processo de
desenvolvimento e são frequentemente impostas por normas
organizacionais. Surgem devido às necessidades dos usuários,
restrições de orçamento, políticas organizacionais e outros motivos.
Um requisito não funcional pode estar vinculado a um requisito
funcional ou pode se aplicar ao sistema como um todo.
Das técnicas de modelagem da UML, pode-se adotar o diagrama de
casos de uso para modelar os requisitos funcionais, que
posteriormente guiarão o processo de desenvolvimento; o diagrama
de atividades para representar o comportamento de cada requisito
funcional do sistema, subsistemas ou de um ou mais processos de
negócio do domínio do sistema; e o diagrama de sequência para
especificar o cenário de cada funcionalidade identificada como
requisito funcional.
Para iniciar a modelagem dos requisitos do sistema "Locação de
Veículos", adotamos o diagrama de atividades em compartimentos,
no formato de swimlanes (raias de natação), para facilitar a
compreensão e o entendimento do domínio do sistema,
representando o fluxo de atividades dos principais processos de
negócio que demonstram o comportamento do sistema. A Figura 3
ilustra o diagrama de atividades, mostrando os atores "Locadora" e
"Cliente" que realizam as atividades de locação e devolução de um
carro de forma geral, sem detalhar as ações específicas envolvidas
em cada atividade, e considerando que o aluguel de um carro é
realizado a partir de uma reserva.
Fonte 3 | Diagrama de atividades – locação e devolução de carro.
Fonte: Catarino (2020, p.).
A partir da descrição do estudo de caso e da representação das
atividades gerais que compõem o processo de locação e devolução
de um carro a partir de uma reserva prévia, conforme ilustrado na
Figura 3, foram identificados os principais requisitos funcionais,
listados no Quadro 1. No quadro, estão relacionados apenas os
requisitos funcionais referentes aos cadastros e controles dos
processos de locação e devolução. As consultas e relatórios não
foram incluídos, mas serão representados diretamente no diagrama
de casos de uso na modelagem da próxima atividade.
Nº Requisito Descrição
RF1 Cadastro O sistema deve prover um cadastro de filiais
de filial da locadora de veículos. O cadastro será
mantido pelo administrador do sistema.
RF2 Cadastro O sistema deve prover um cadastro de
de cliente clientes. Um cliente pode se cadastrar via
web ou aplicativo. Cada cliente deve ser
gerenciado pela sua situação (ativo,
preferencial, inadimplente ou encerrado).
RF3 Cadastro O sistema deve prover um cadastro das
de empresas conveniadas com a locadora de
empresa veículos.
RF4 Cadastro O sistema deve prover um cadastro de grupos
de grupo de carros para categorizar os carros por
de carro características.
 Nº Requisito Descrição
RF5 Cadastro O sistema deve prover um cadastro dos
de carro carros disponíveis para o aluguel. Cada carro
deve ser gerenciado pela sua situação
(disponível, alugado, manutenção interna,
manutenção externa ou encerrado).
RF6 Controle O sistema deve prover um controle de
de reserva reserva de carros para clientes da locadora.
de carro Uma reserva pode ser realizada por telefone,
web ou aplicativo. Cada reserva deve ser
gerenciada pela situação (agendada,
cancelada, realizada, aprovado ou
reprovado). Toda reserva efetivada deve
enviar um comprovante da reserva para o
cliente via e-mail e/ou SMS.
RF7 Controle O sistema deve prover um controle de aluguel
de aluguel de carros para clientes da locadora.
de carro
RF8 Emissão O sistema deve emitir cópias do contrato de
de aluguel.
contrato
de aluguel
RF9 Controle O sistema deve prover um controle de
de devolução de carros. Uma devolução refere-
devolução se à baixa de um aluguel. O controle de
de carro devolução estará integrado com o módulo de
pagamento.
RF1 Emissão O sistema deve emitir a nota fiscal de serviço,
0 de nota referente ao aluguel de um carro. A nota
fiscal de fiscal pode ser impressa ou enviada por e-
aluguel mail para o cliente.

Quadro 1 | Listagem dos requisitos funcionais. Fonte: Catarino (2020,

p.).
Atividade análise e projeto

Na segunda atividade do modelo processo unificado – análise e

projeto, a atividade de análise foca em identificar e definir as funções
do sistema de software a partir de uma perspectiva lógica do negócio,
enquanto a atividade de projeto visa determinar como o software
será desenvolvido, alinhado às tecnologias, linguagens de
programação e bancos de dados escolhidos para a implementação do
software.
Em um processo de desenvolvimento iterativo, embora a análise
geralmente preceda o projeto, ambas as atividades podem ocorrer
simultaneamente. Segundo Bezerra (2007, p. 176), “os modelos
especificados na análise esclarecem o problema a ser resolvido. No
entanto, as perspectivas do sistema fornecidas por esses modelos
não são suficientes para se ter uma visão completa do sistema para
que a implementação comece”.
Durante a atividade de análise, inicia-se a modelagem definindo os
casos de uso baseados nos requisitos funcionais identificados
anteriormente, elaborando o modelo de casos de uso. Uma vez que o
modelo de casos de uso esteja pronto, a próxima etapa envolve
analisar cada caso de uso para iniciar a identificação das classes de
objetos, determinando quais classes estão envolvidas na realização
de cada caso de uso e como o sistema será estruturado
internamente. Especifica-se, então, o modelo de classes, geralmente
em várias perspectivas de visão. Com a primeira versão do modelo de
classes definida, é possível aprimorar a modelagem dos casos de uso
com descrições detalhadas, já que os objetos que colaboram e
participam da execução de cada caso de uso são claramente
identificados nesta fase.
Modelo de casos de uso e diagrama de classes

A partir da definição dos requisitos funcionais analisamos os

requisitos identificados e abstraímos as regras de negócio do sistema,
e assim foi decidido estruturar os casos de uso em dois pacotes.
Na UML, os agrupamentos que organizam um modelo (conjunto de
diagramas) são chamados de pacotes.
Antes de começar a especificação dos casos de uso, é crucial
catalogar todos os casos de uso identificados para decidir se devem
ser agrupados por categoria ou tema. Isso permite a criação do
diagrama de pacotes e dos diagramas de casos de uso para cada
pacote, formando assim o modelo de casos de uso.
A Figura 4 demonstra o diagrama de pacotes para os casos de uso.
Foram estabelecidos dois pacotes principais – “mdL_duc_Negocio” e
“mdL_duc_ConsultaRelatorio”, ambos parte do módulo de locação, e o
pacote “md_Pagamento_duc”, vinculado ao módulo de pagamento,
que foi integrado ao módulo de locação em especificação. Portanto,
os pacotes são apresentados com suas respectivas dependências,
organizando os casos de uso por temas para estruturar o modelo de
casos de uso.

Figura 4 | Diagrama de pacotes – modelo de casos de uso. Fonte:

Catarino (2020, p.).
A Figura 5 mostra o diagrama de casos de uso do pacote
"mdL_duc_Negocio", destacando os casos de uso relacionados aos
requisitos funcionais e outros identificados pela análise desses
requisitos, considerando também o contexto do domínio do sistema.
Os atores principais, como "Funcionário Adm", "Cliente", "Empresa" e
"Gerente", interagem com os casos de uso, desempenhando um
papel crucial na execução desses casos de uso. É essencial analisar
cada requisito funcional definido previamente para estabelecer os
casos de uso e suas inter-relações, já que um requisito pode ser
representado por múltiplos casos de uso. Além disso, deve-se
considerar a usabilidade do sistema para os usuários ao definir o
propósito de cada caso de uso.
A Figura 5 também inclui a representação básica de casos de uso e
suas interações, como o caso de "Reservar Carro". Nele, uma reserva
efetuada pelo cliente gera automaticamente um comprovante
enviado por e-mail, ilustrado pelo relacionamento de inclusão
<<Include>>. Se o cliente desejar, pode imprimir esse comprovante
após confirmar a reserva, mostrado no diagrama pelo relacionamento
de extensão <<Extend>>. Lembre-se que os relacionamentos
<<Extend>> e <<Include>> são tipos específicos de dependências
entre casos de uso, indicando sequências de interações e execuções
obrigatórias, respectivamente.

Figura 5 | Diagrama de casos de uso – pacote mdL_duc_Negocio.

Fonte: Catarino (2020, p.).
A Figura 6 representa o diagrama de casos de uso correspondente ao
pacote “mdL_duc_ConsultaRelatorio”, que concentra os casos de uso
definidos para as funcionalidades das consultas e relatórios
operacionais do sistema. Perceba que alguns casos de uso estão
associados ao ator genérico “Colaborador”, o qual indica que os
atores especializados “Funcionário Adm” e “Gerente” têm acesso a
todos os casos de uso associados ao ator genérico.
Figura 6 | Diagrama de casos de uso – pacote
mdL_duc_ConsultaRelatorio. Fonte: Catarino (2020, p.).
Após a abstração dos casos de uso, inicia-se a identificação das
classes de objetos e a elaboração do diagrama de classes, utilizando
essa técnica como a principal abordagem de modelagem estrutural
da UML para representar a parte estática do sistema. Esse diagrama
exibe classes, seus atributos, operações e relações.
Dentre as várias técnicas de identificação de classes — como análise
textual de Abbott, análise dos casos de uso, cartões CRC (Classes,
Responsabilidades e Colaboradores), e taxonomia de conceitos —
escolhemos a análise dos casos de uso. Por exemplo, no caso de uso
“Manter Cliente”, é necessário definir uma classe para clientes que
permite operações de inclusão, alteração, exclusão e pesquisa,
adequadas ao contexto do domínio do sistema.
Após identificar as classes e atributos, é crucial verificar a
consistência entre eles e os casos de uso já estabelecidos, ajustando
para incorporar novas classes ou remover redundâncias. A primeira
versão do diagrama de classes é, então, refinada e detalhada
conforme as tecnologias de implementação escolhidas.
No contexto do sistema de “Locação de Veículos”, as classes foram
organizadas no pacote “md_Locacao_dc”, que possui uma
dependência com o pacote “md_Pagamento_dc”, referente ao módulo
de pagamentos, como mostrado no diagrama de pacotes da Figura 7.

Figura 7 | Diagrama de pacotes. Fonte: Catarino (2020, p.).

A Figura 8 exibe o diagrama de classes de análise para o pacote
"md_Locacao_dc", seguindo as normas básicas de modelagem e as
regras de negócio do sistema.
No diagrama, são apresentadas as classes e seus relacionamentos,
que facilitam a troca de informações entre os objetos durante a
execução do sistema. Notavelmente, o diagrama inclui um
relacionamento de generalização entre a superclasse "Pessoa" e as
subclasses "PessoaFisica" e "PessoaJuridica". Todos os outros
relacionamentos são de associação binária.
A classe "FilialLoja" é destacada em uma cor diferente e não tem
atributos ou operações listados, pois embora exista no sistema, seus
objetos são gerenciados diretamente no banco de dados pelo
administrador do sistema. Contudo, é essencial representar essa
classe para definir sua associação com as classes "Reserva" e
"AluguelDevolucao".
Fonte 8 | Diagrama de classes (análise) – md_Locacao_dc. Fonte:
Catarino (2020, p.).
Ao definir a nomenclatura para o nome das classes, atributos e
operações em um modelo de classes, é essencial seguir convenções
específicas para manter a clareza e a consistência. Aqui estão as
recomendações:
1. Nome da classe: deve ser um substantivo ou uma expressão breve,
único dentro do modelo. Por convenção, o nome é sempre no singular
e, em caso de palavras compostas, elas devem ser concatenadas com
a primeira letra de cada palavra em maiúscula, como
"ClienteFidelizado".
2. Atributos: representam propriedades do objeto e são nomeados por
substantivos ou expressões que indicam uma propriedade da classe,
geralmente escritos em letra minúscula. Para palavras compostas, a
segunda palavra e subsequentes começam com letra maiúscula,
como "dataNascimento" e "endereçoEletrônico".
3. Operações: correspondem às ações dos objetos e são nomeadas
por um verbo ou uma locução verbal breve. Seguem a mesma
convenção dos atributos, usando letras minúsculas e maiúsculas
conforme necessário, por exemplo, "criarCliente", "alterarCliente",
"validarDataNascimento" e "calcularIdade".
Um aspecto crucial é a definição e listagem de atributos em uma
classe. É importante que cada atributo seja atômico, ou seja,
indivisível. Não se deve dividir um atributo em subcampos, como é o
caso de "CPF" ou "estadoCivil". Atributos compostos, como "filiação"
(nome da mãe e nome do pai) ou "endereço" (incluindo logradouro,
número, complemento, bairro, cidade, estado e CEP), não devem ser
listados como um único atributo, pois cada componente pode ser
considerado separadamente. A Figura 9 ilustraria um erro ao listar um
atributo composto, demonstrando a importância de manter cada
atributo simples e claro.

Figura 9 | Classes com atributo composto e atributo simples. Fonte:

Catarino (2020, p.).
Alguns atributos compostos podem ser representados como atributos
simples em uma classe, como no caso do atributo "nome" de uma
pessoa. É importante considerar o contexto do domínio do sistema.
Em alguns casos, o atributo "nome" pode ser tratado como um único
atributo que inclui tanto o nome quanto o sobrenome da pessoa. Em
outros contextos, pode ser necessário separar o atributo "nome" do
atributo "sobrenome" para uma representação mais detalhada.
Agora que temos a primeira versão do diagrama de classes, a
documentação de cada caso de uso torna-se mais fácil. A UML não
define um formato específico para a documentação dos casos de uso,
permitindo flexibilidade na escolha do formato. A documentação pode
ser feita de diversas maneiras, incluindo o uso de pseudocódigo,
código de programação ou prototipação de interface gráfica para
facilitar a compreensão da execução do caso de uso.
O formato sugerido para a documentação dos casos de uso é o
formato numerado de descrição dos cenários – principal e
alternativos. O cenário principal descreve uma tarefa em um mundo
perfeito, sem exceções, enquanto os cenários alternativos relatam
quaisquer situações que representam exceções ou condições do
cenário principal.
Posteriormente, deve-se continuar a modelagem comportamental e
de interação do sistema, a partir do detalhamento do funcionamento
dos casos de uso, adotando o diagrama de atividades, diagrama de
sequência ou o diagrama de visão geral de interação, bem como
especificar os estados e suas transições dos objetos das classes que
apresentam estados relevantes, como é o caso das classes
“Reserva”, “Carro” e “Pessoa”.

Considerando as regras de negócio definidas no complemento da

descrição do estudo de caso, para o módulo “Pagamento” segue o
diagrama de classes como proposta de uma solução possível.

Figura 10 | Diagrama de classes (análise) – md_Pagamento_dc. Fonte:

Catarino (2020, P.).
Observa na figura a classe “AluguelDevolucao”, que faz parte do
módulo “Locação de Veículos”, e as classes “Caixa”,
“CreditoParcelado”, “ParcelaCreditoParcelado” e “TipoPagamento”,
que são as classes especificadas para o módulo “Pagamento”.
A classe “CreditoParcelado” foi representada com uma associação do
tipo composição, indicando objetos todo-parte, sendo que os objetos
da “ParcelaCreditoParcelado” representam as partes com a obrigação
de, no mínimo, ter uma parcela. Foi estabelecido também um
relacionamento do tipo dependência entre a classe
“CreditoParcelado” com o pacote “GatewayPagamento”, que indica
que, para as compras lançadas como crédito a receber (contas a
receber), a partir do pagamento efetuado com cartão de débito ou
crédito, é reutilizado um gateway de pagamento (um serviço
destinado a pagamentos virtuais por cartão, mantido por uma
operadora financeira que autoriza pagamentos de transações feitas
on-line em websites de empresas) para efetuar esses pagamentos.

Modelagem complementar

Diagrama de estrutura composta

Tendo finalizado o diagrama de casos de uso e o diagrama de classes

na fase de análise, prosseguimos com a modelagem do sistema
"Locação de Veículos", focando agora na modelagem comportamental
das suas funcionalidades. Nesta fase, empregaremos as principais
técnicas de modelagem comportamental da UML para ilustrar o
comportamento e a interação entre os elementos do sistema,
documentando, assim, a dinâmica do sistema.
Dentro das técnicas de modelagem da UML, divididas em estruturais
e comportamentais, a perspectiva de interação é um subgrupo dos
diagramas comportamentais. Esses diagramas detalham como os
objetos dentro do sistema se comunicam e colaboram para executar
as funcionalidades definidas pelos casos de uso. Para aprimorar a
compreensão das interações entre os objetos envolvidos nos casos de
uso chave - reserva, aluguel e devolução - do domínio do sistema,
iniciaremos com a representação do diagrama de estrutura composta.
O diagrama de estrutura composta é uma ferramenta estrutural da
UML projetada para identificar a arquitetura de elementos que
interagem durante a execução de um sistema. Esse diagrama
destaca a colaboração entre elementos que se comunicam, mas não
detalha o comportamento dessa colaboração, que é explorado nos
diagramas comportamentais da UML.
De acordo com Guedes (2018), o diagrama de estrutura composta
detalha a estrutura interna de um componente, classe ou uma
colaboração entre um conjunto de instâncias que cooperam para
realizar uma tarefa específica, descrevendo as partes componentes e
suas comunicações, representando uma composição de elementos
interligados por conexões de comunicação que colaboram para
alcançar um objetivo comum. Portanto, foi escolhido o diagrama de
estrutura composta para representar a colaboração nos casos de uso
"Reservar Carro", "Alugar Carro" e "Devolver Carro".
A Figura 2 mostra o diagrama de estrutura composta para a
colaboração "Reservar Carro", abrangendo o caso de uso "Reservar
Carro" e seus relacionamentos, como "Imprimir Comprovante de
Reserva" e "Enviar E-mail do Comprovante da Reserva". O diagrama
ilustra a colaboração durante a execução dos casos de uso
envolvidos, no qual cada reserva é instanciada na classe Reserva.
Cada reserva estabelece um vínculo que demonstra a comunicação
entre os objetos envolvidos para concretizar a reserva. Esse processo
envolve a referência aos seguintes objetos:

 O objeto cliente (PessoaFisica), indicando quem realiza a

reserva.
 O objeto loja (FilialLoja), especificando a loja para retirada do
carro.
  Outro objeto loja (FilialLoja), para a devolução do carro.
 O objeto grupo de carro (GrupoCarro), escolhendo o modelo de
carro a ser alugado.
 O objeto item adicional (ItemAdicional), para selecionar itens
extras que complementem o aluguel do carro, se necessário.

Vale ressaltar que, embora um diagrama de estrutura composta

possa corresponder à colaboração de casos de uso, o nome da
colaboração pode coincidir com o de um caso de uso quando
representa exatamente um ou mais casos de uso relacionados.

Fig
ura 2 | Diagrama de estrutura composta – Reservar Carro. Fonte:
Catarino (2020, p.).
A Figura 3 mostra o diagrama de estrutura composta para a
colaboração chamada "Alugar Carro", que inclui o caso de uso "Alugar
Carro" junto com seus relacionamentos, como "Reservar Carro",
"Emitir Contrato de Aluguel" e "Enviar E-mail do Comprovante do
Aluguel". O diagrama ilustra a colaboração considerando a execução
dos casos de uso envolvidos, em que cada processo de aluguel é
instanciado na classe Aluguel. Para cada aluguel, estabelece-se uma
conexão que reflete a comunicação entre os objetos envolvidos para
efetivar o aluguel. Assim, entende-se que cada aluguel pode estar
associado aos seguintes objetos:

 O objeto reserva (Reserva), que determina se o aluguel será

baseado em uma reserva pré-existente.
 O objeto cliente (PessoaFisica), indicando quem está realizando
o aluguel.
 O objeto loja (FilialLoja), especificando a loja de onde o carro foi
retirado.
 Outro objeto loja (FilialLoja), que define a loja onde o carro será
devolvido.
 O objeto carro (Carro), especificando o carro escolhido para o
aluguel e, com a confirmação do aluguel, a situação do carro
deve ser atualizada para "Alugado".
 O objeto item adicional (ItemAdicional), se necessário, para
complementar o carro alugado com itens adicionais.

Esse diagrama serve para visualizar não apenas a estrutura, mas

também as dinâmicas de interação necessárias para concretizar o
serviço de aluguel de carros.
Figura 3 | Diagrama de estrutura composta – Alugar Carro. Fonte:
Catarino (2020, p.).
A Figura 4 apresenta o diagrama de estrutura composta para a
colaboração "Devolver Carro", que inclui o caso de uso "Devolver
Carro" e suas interações relacionadas, como "Efetuar Pagamento" e
"Emitir Nota Fiscal de Serviço". Esse diagrama destaca a integração
de seus componentes na conclusão do processo de um aluguel, onde
cada devolução envolve:

 A recuperação do objeto aluguel (AluguelDevolucao), a partir do

qual a devolução será processada.
 A interação com o módulo de pagamento (Pagamento),
indicando uma integração funcional com outro segmento do
sistema.
 O objeto carro (Carro), que precisa ter seu status atualizado
para "Manutenção Interna" assim que a devolução do carro for
confirmada.
Figura 4 | Diagrama de estrutura composta – Devolver Carro. Fonte:
Catarino (2020, p.).
Esse diagrama de estrutura composta é fundamental para apoiar a
modelagem comportamental do sistema, ajudando a solidificar a
compreensão de como cada caso de uso opera durante a execução
do sistema e melhorando a percepção do contexto operacional do
sistema.
Diagrama de máquina de estados

Em seguida, iniciaremos a modelagem dos estados para objetos cujos

estados são cruciais. Considerando o contexto e as regras de negócio
já estabelecidas no estudo de caso, as classes "Reserva", "Carro", e
"Pessoa" foram identificadas no diagrama de classes como
possuidoras de estados relevantes. Adicionalmente, a classe
"AluguelDevolucao" também foi definida com estados importantes
para melhorar o controle e a eficiência das consultas e relatórios.
Conforme Booch, Jacobson e Rumbaugh (2006, p. 285), o diagrama
de máquina de estados é descrito como um modelo que "especifica
as sequências de estados pelos quais um objeto passa ao longo de
sua vida, em resposta a eventos, e suas reações a esses eventos".
Ao desenvolver o diagrama de máquina de estados, é essencial
identificar as regras de negócio que se aplicam aos objetos com
estados relevantes, definindo de maneira clara os estados e suas
transições, que são os componentes fundamentais do diagrama.
A seguir, estão detalhadas as regras de negócio que governam as
transições de estados para cada classe e o respectivo diagrama de
máquina de estados.
Para os objetos da classe "Pessoa", que podem ser uma pessoa física
atuando como cliente ou uma pessoa jurídica representando uma
empresa, os estados definidos são: Ativa, Preferencial, Inadimplente e
Encerrada. As regras específicas são:

 Ao ser cadastrada, toda pessoa deve automaticamente ser

classificada como Ativa.
 Uma pessoa Ativa torna-se Preferencial após realizar o décimo
aluguel.
 Uma pessoa Ativa pode tornar-se Inadimplente caso falhe no
pagamento de um aluguel.
 Uma pessoa Ativa pode ser classificada como Encerrada se a
gerência determinar por um motivo específico.
 Uma pessoa Preferencial pode tornar-se Inadimplente se um
aluguel não for pago dentro de 30 dias.
 Uma Pessoa Inadimplente pode retornar ao estado Ativa, caso o
pagamento em atraso seja efetuado.
 Uma pessoa Encerrada não pode transitar para outro estado.

O diagrama de máquina de estados, apresentado na Figura 5, ilustra

os estados definidos para a classe "Pessoa" e suas transições de
estado, que são marcadas com condições de guarda conforme as
regras de negócio estabelecidas.
Figura 5 | Diagrama de máquina de estados – Classe Pessoa. Fonte:
Catarino (2020, p.).
Para os objetos da classe "Reserva", os estados definidos são:
Realizada, Confirmada e Cancelada. As regras estabelecidas para
essas transições de estado são:

 Ao ser cadastrada, toda reserva deve automaticamente entrar

no estado Realizada.
 Uma reserva no estado Realizada deve mudar para Confirmada
uma vez que o aluguel associado seja efetuado.
 Uma reserva Realizada pode ser alterada para Cancelada, caso
o cliente ou o gerente decida pelo cancelamento.
 Reservas nos estados Confirmada ou Cancelada não devem
transitar para outros estados.

O diagrama de máquina de estados, mostrado na Figura 6, destaca os

estados definidos para a classe "Reserva". As transições entre esses
estados são claramente marcadas com condições de guarda,
refletindo as regras de negócio descritas.
Figura 6 | Diagrama de máquina de estados – Classe Reserva. Fonte:
Catarino (2020, p.).
Para os objetos da classe "Carro", os estados definidos são:
Disponível, Alugado, Manutenção Interna, Manutenção Externa e
Inativo. Seguem as regras específicas para essas transições de
estado:

 Um carro, ao ser cadastrado, entra automaticamente no estado

Disponível.
 Um carro Disponível muda para Alugado assim que um aluguel
é efetuado.
 Um carro Alugado deve ser colocado em Manutenção Interna
após sua devolução.
 Um carro em Manutenção Interna retorna ao estado Disponível
após a conclusão da vistoria técnica e lavagem.
 Um carro em Manutenção Interna pode mudar para Manutenção
Externa se o gerente determinar, devido a problemas técnicos
que não possam ser resolvidos internamente.
 Um carro Disponível pode ser colocado em Manutenção Interna
por decisão gerencial devido a razões pontuais.
 Um carro em Manutenção Externa deve voltar para Manutenção
Interna para uma inspeção geral após os reparos externos.
 Um carro em Manutenção Interna pode ser classificado como
Inativo por decisão da gerência.
 Um carro no estado Inativo não transita para outro estado.

O diagrama de máquina de estados, apresentado na Figura 7, ilustra

os estados definidos para a classe "Carro", e as transições entre esses
estados são claramente indicadas com condições de guarda,
refletindo as regras de negócio estipuladas.

Figura 7 | Diagrama de máquina de estados – Classe Carro. Fonte:

Catarino (2020, p.).
Para os objetos da classe “AluguelDevolução”, definimos estados
específicos para a fase de aluguel e devolução do veículo. Para o
lançamento de um aluguel, os estados são: Realizado, Registrado e
Cancelado. As regras aplicáveis são:

 Um aluguel, ao ser lançado, entra automaticamente no estado

Realizado.
 Um aluguel Realizado transita para o estado Registrado uma
vez que o aluguel seja confirmado.
 Um aluguel Realizado pode ser alterado para Cancelado se o
aluguel não for confirmado por algum motivo.

Para a fase de devolução dos carros alugados, os estados definidos

são: Recuperado, Atualizado e Cancelado. As regras para estas
transições são:
  Ao ser lançada, toda devolução de carro assume
automaticamente o estado Recuperado.
 Do estado Recuperado, a devolução passa para Atualizado
quando a devolução do carro é confirmada.
 Do estado Recuperado, a devolução pode passar para
Cancelado se a devolução do carro não for confirmada por
algum motivo.

O diagrama de máquina de estados, apresentado na Figura 8, ilustra

os estados definidos para a classe “AluguelDevolução”, com
transições de estados claramente indicadas por condições de guarda,
refletindo as regras de negócio estabelecidas. O diagrama destaca
dois estados compostos: um para a ocorrência do aluguel e outro
para a devolução do carro, evidenciando que ambos ocorrem em
períodos distintos, com a devolução funcionando como uma
atualização ou "baixa" do aluguel inicial.

Figura 8 | Diagrama de máquina de estados – Classe

AluguelDevolucao. Fonte: Catarino (2020, p.).
No diagrama, é possível observar que, em ambos os estados
compostos, uma ação de saída (cláusula “Exit”) é indicada,
associando a operação `atualizarSituacaoCarro` aos subestados
“Registrando” e “Atualizando” dentro dos estados “Alugando” e
“Devolvendo”, respectivamente. Conforme o processo avança, após o
registro de um aluguel, a situação do carro é atualizada para
“Alugado”. Em seguida, quando a devolução do carro é efetivada, a
situação deve ser alterada para “Manutenção Interna”.
Durante a fase de implementação do processo de desenvolvimento
do sistema, a especificação detalhada no diagrama de máquina de
estados será crucial para apoiar a implementação das classes de
forma consistente com as regras de negócio estabelecidas para os
estados dos objetos no sistema. Essa abordagem assegura que as
transições de estado e as ações associadas sejam corretamente
incorporadas e funcionem conforme o planejado, refletindo os
requisitos e fluxos de trabalho definidos.
Diagrama de atividades e diagrama de sequência

Considerando que os casos de uso estão definidos, é crucial avançar

na modelagem comportamental do sistema para uma compreensão
mais profunda da lógica operacional de cada caso de uso.
A UML não prescreve uma técnica específica para modelagem
comportamental ou de interação, deixando essa escolha para o
analista de sistemas ou para a metodologia de desenvolvimento da
empresa. É responsabilidade do analista determinar a técnica mais
adequada de modelagem comportamental da UML com base nas
características e na aplicabilidade de cada caso de uso. Nesse
contexto, optamos pela técnica de diagrama de atividades para
detalhar o caso de uso “Reservar Carro”.
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.
Conforme descrito no cenário principal do caso de uso "Reservar
Carro", descrito no Quadro 1, a Figura 9 apresenta o diagrama de
atividades, organizado em fluxos de controle sequencial. Seguindo as
diretrizes da UML, os nomes dos elementos básicos do diagrama,
como Atividade ou Nó de Ação, devem iniciar com um verbo no
infinitivo, refletindo a perspectiva de execução do sistema. Por
exemplo, se o cliente fornece os dados, o sistema é representado
como recebendo ou aceitando esses dados. Uma Atividade, nesse
contexto, é uma sequência de tarefas dentro de um fluxo de trabalho
que define o comportamento de um processo e consiste em várias
ações.
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:

1. Cliente solicita reserva de carro.

2. Cliente informa dados (loja/filial, data e hora) da retirada do veículo.
3. Sistema recupera lojas cadastradas para retirada.
4. Cliente escolha loja para retirada.
5. Cliente informa dados (loja/filial, data e hora) da devolução do veículo.
6. Sistema recupera lojas cadastradas para devolução.
7. Cliente seleciona loja para devolução.
8. Sistema recupera grupos de carros disponíveis no período indicado.
9. Cliente seleciona o grupo de carro desejado.
10. Sistema recupera itens opcionais do carro.
11. Cliente informa itens opcionais do carro desejado.
12. Cliente acessa sua conta pessoal.
13. Sistema recupera dados do cliente.
14. Sistema calcula valor total da reserva.
15. Cliente confirma reserva.
16. Sistema registra reserva.
17. Sistema disponibiliza opção de imprimir comprovante da reserva.
18. Sistema envia por e-mail comprovante da reserva.
 19. Sistema envia SMS comprovante da reserva.

Quadro 1 | Documentação do caso de uso – Reservar Carro. Fonte:

Catarino (2020,p.).
No diagrama de atividades mostrado na Figura 9, observa-se que
alguns nós de ação, como "Recuperar lojas/filiais para retirada",
interagem com o nó de objeto "FilialLoja", e "Recuperar grupos de
carros disponíveis para reserva" interage com "GrupoCarro", entre
outros. No diagrama, os elementos representados por retângulos
pequenos com bordas arredondadas e um nome centralizado em
cinza são nós de ação. Exceção feita ao elemento "Manter cliente",
que é branco e representa uma atividade ligada ao caso de uso de
cadastrar um novo cliente. Por convenção da ferramenta CASE Visual
Paradigm, o nome da Atividade também é centralizado, mas
posicionado na parte superior do retângulo.
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 10 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 11 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.

Figura 10 | Diagrama de sequência – Alugar Carro. Fonte: Catarino

(2020, p.).
Transição de análise para projeto

Lembre-se de que a UML não distingue a modelagem

das atividades de análise e projeto em um processo de
desenvolvimento de software. A atividade de projeto é
uma extensão refinada dos diagramas elaborados na
análise, com detalhes aplicados à implementação, e a
análise e o projeto podem ocorrer simultaneamente. A
decisão de trabalhar com modelagem simultânea ou de
apresentar uma única modelagem para as atividades
de análise e projeto com diferentes perspectivas de
visão é definida pela metodologia de desenvolvimento
do sistema, conforme a preferência de cada equipe de
desenvolvedores ou empresa.
Modelagem de projeto

Dependendo do domínio e da complexidade dos sistemas de

software, é essencial fornecer diversas perspectivas da modelagem
orientada a objetos, abrangendo diferentes aspectos de análise e
detalhamento. Isso pode ser feito por meio de uma única modelagem
de análise e projeto ou por meio de modelagens distintas para essas
atividades. Conforme o Processo Unificado de desenvolvimento de
software, que enfatiza a iteração, a análise e o projeto são atividades
integradas que ocorrem ao longo das fases de Concepção,
Elaboração, Construção e Transição (Pressman, 2016). No entanto, ao
utilizar a UML para a modelagem de sistemas orientados a objetos,
não há uma regra específica sobre quais técnicas de modelagem
estrutural ou comportamental devem ser adotadas e em que
momento aplicá-las. Essa decisão cabe ao analista de sistemas, de
acordo com a metodologia da empresa de desenvolvimento.
É crucial compreender que a UML oferece uma maneira sistemática e
evolutiva de modelar sistemas orientados a objetos em diversas
perspectivas estáticas e dinâmicas, utilizando suas técnicas de
modelagem estrutural, comportamental e de interação.
Na atividade de análise, a modelagem especificada na análise de
requisitos é desenvolvida, concentrando-se na solução do problema
por meio da abstração, identificação, definição e documentação do
que o sistema deve fazer, considerando a visão lógica do negócio,
independentemente das tecnologias utilizadas na implementação do
sistema. Posteriormente, essa análise especificada é transformada
em projeto, com novos detalhes e refinamentos que definem os
aspectos físicos do sistema e as tecnologias a serem adotadas na
implementação.
Segundo Bezerra (2014), no desenvolvimento de sistemas orientados
a objetos, as mesmas técnicas de modelagem são utilizadas tanto na
análise quanto no projeto, caracterizando uma uniformidade na
modelagem do sistema durante o desenvolvimento. No entanto, essa
uniformidade pode obscurecer a distinção entre o que é especificado
na análise e o que é feito no projeto. Assim, pode-se dizer que a
modelagem da análise transforma-se na modelagem de projeto à
medida que o desenvolvimento do sistema avança.
Como refinamento dos aspectos estáticos e estruturais das técnicas
de modelagem da UML na atividade de projeto, o foco principal está
na técnica de modelagem estrutural, o diagrama de classes. As
recomendações são:
1. Refinamento de classes: definir as classes de projeto ou criar novas
classes. Uma classe de análise pode resultar em várias classes de
projeto.
2. Definição de estereótipos: classificar as classes em estereótipos de
fronteira (<<boundary>>), controle (<<control>>) ou entidade
(<<entity>>).
3. Tipo de dados: estabelecer o tipo de dados de cada atributo de
acordo com a linguagem de programação que será utilizada na
implementação.
4. Detalhamento de operações: listar todas as operações identificadas
nos diagramas comportamentais e de interação.
5. Revisão de visibilidade: definir a visibilidade das classes e
operações, estabelecendo o nível de acessibilidade de atributos ou
operações por outros objetos, que pode ser privada, pública,
protegida ou de pacote.
6. Revisão de relacionamentos: revisar os tipos de relacionamentos
entre as classes, como associação (incluindo associação reflexiva,
binária, ternária, classe associativa e agregação), generalização,
dependência ou realização, além de indicar a navegabilidade de cada
associação.
7. Definição de classes abstratas e interfaces: especificar classes
abstratas, interfaces, padrões de projeto (design patterns),
componentes de software reutilizáveis, frameworks e demais detalhes
pertinentes às tecnologias de desenvolvimento a serem utilizadas
durante a implementação, definindo assim a arquitetura de um
sistema orientado a objetos.
Modelagem de classe de projeto

As boas práticas da engenharia de software enfatizam a redução dos

esforços e custos de produção por meio da reutilização de software.
Isso pode ser alcançado utilizando recursos como componentes de
software e frameworks usuais para desenvolvimento web e de
aplicações móveis, aplicados às diferentes tecnologias de
desenvolvimento de software. Assim, ao adotar esses recursos que
agilizam o desenvolvimento de software, eles devem ser integrados à
modelagem de projeto, estabelecendo a arquitetura do software
(Rumbaugh, 1997).
Na representação do diagrama de classes na atividade de projeto, é
importante revisar os relacionamentos estabelecidos entre as classes
de objetos. Os relacionamentos usuais no diagrama de classes de
análise são do tipo associação e generalização. No entanto, na versão
do diagrama de projeto, é comum incluir componentes de software e
aplicar design patterns, o que pode introduzir relacionamentos do tipo
realização e dependência. Vamos revisar os conceitos referentes a
esses tipos de classes:

 Realização: relacionamento que modela a conexão entre uma

interface e uma classe ou componente, na qual um dos
elementos especifica um contrato de uso com o outro. A
representação gráfica é uma linha tracejada com uma grande
seta vazia, apontando para o elemento que especifica o
contrato.
 Dependência: relacionamento de utilização entre classes,
indicando que uma alteração na especificação de um elemento
pode afetar outro que o utiliza. A representação gráfica é uma
linha tracejada, apontando para o item do qual o outro
depende.
Ainda na definição das classes de projeto, é necessário definir o
estereótipo das classes. Um estereótipo representa uma classificação
do elemento. Alguns estereótipos de classe adotados no diagrama de
classes de projeto são (Bezerra, 2014):

 De fronteira (<<boundary>>): identifica uma classe que serve

de comunicação entre os atores externos e o sistema,
geralmente associada à interface do sistema. É importante em
sistemas que requerem a definição de uma interface específica.
 De controle (<<control>>): identifica classes que
intermediariam as classes de fronteira e as outras classes do
sistema. Os objetos de controle interpretam eventos sobre os
objetos de fronteira e os retransmitem para os objetos das
classes de entidade.
 De entidade (<<entity>>): também chamadas de classes do
negócio, representam os conceitos do domínio do sistema,
contendo informações recebidas ou geradas pelo sistema.
Baseando-se nessas classes, define-se quais objetos devem ser
persistentes, geralmente armazenados em um sistema de
gerenciamento de banco de dados.

A Figura 1 ilustra um recorte do diagrama de classes de projeto do

sistema “Locação de Veículos”, focando na classe “Reserva”,
correspondente ao caso de uso “Reservar Carro”. Apresenta parte do
refinamento da classe com os aspectos sugeridos anteriormente. Por
simplificação, apenas o refinamento de uma classe foi exemplificado.
Em uma situação real, todas as classes de análise devem ser
consideradas.
Figura 1 | Recorte do diagrama de classes (Projeto) – md_Locacao_dc.
Fonte: Catarino (2020, p.).
O diagrama de classes na atividade de projeto complementa os
elementos do diagrama, permitindo enriquecer os detalhes físicos,
obtendo um modelo suficientemente completo e aproximando-o da
implementação real.
A Figura 2 ilustra uma visão do diagrama de classes de projeto do
pacote "md_Locacao_dc", refinado com a definição do tipo de dados
dos atributos correspondentes à linguagem de programação Java; a
indicação do estereótipo das classes do tipo entidade (<<entity>>);
e a representação das classes definidas com o estereótipo
enumeração (<<enumeration>>), correspondentes aos valores do
atributo situação das classes "Reserva", "Carro" e "Pessoa" (Catarino,
2020).
Foi estabelecido o relacionamento do tipo dependência entre as
classes enumeradas e as classes que as referenciam. No entanto, não
é obrigatório estabelecer esses relacionamentos de dependência
entre essas classes. Além disso, a indicação da navegabilidade nas
associações binárias define a referência entre os objetos, sendo que a
ausência da indicação de navegabilidade representa a referência
bidirecional entre os objetos associados.
Figura 2 | Diagrama de classes (Projeto) – md_Locacao_dc. Fonte:
Catarino (2020, p.).
No diagrama também foi indicada a restrição, também conhecida
como classificador do relacionamento de generalização. Os
classificadores de generalização são usados para definir melhor a
semântica das classes especializadas derivadas da classe genérica.
Eles são escritos entre chaves, próximos à seta de generalização, e os
tipos predefinidos para classes especializadas incluem (Rumbaugh,
1997):

 Completo: indica que qualquer instância da superclasse

(abstrata) será uma instância de uma das subclasses
especializadas.
 Incompleto: indica que pode existir um conjunto de objetos de
novas subclasses não representadas, e uma instância do tipo
pode existir apenas da própria superclasse (concreta).
 Disjunção: indica que qualquer instância da superclasse pode
ser uma instância de apenas uma das subclasses, ou seja,
exclusiva de uma subclasse.
 Sobreposição: indica que uma instância da superclasse pode
pertencer a mais de uma subclasse.
Na UML 2.0 até a versão 2.4.1, o classificador de generalização
padrão era “{incompleta, disjunção}”. Na UML 2.5, o padrão foi
alterado para “{incompleta, sobreposição}”. Portanto, se o contexto
do domínio do sistema for diferente desse padrão, deve-se
representar o classificador da generalização; caso contrário, ele pode
ser suprimido. A especificação UML não determina como essa
equivalência semântica será implementada nem como a integridade
entre os objetos será mantida a partir da indicação do classificador de
generalização.

Refinamento dos aspectos

comportamentais

A modelagem de projeto pode ser complementada com diagramas

comportamentais e de interação adicionais da UML que não foram
especificados na análise, ou os diagramas de análise podem ser
refinados com detalhes para aplicação na implementação.
Segundo Bezerra (2014, p. 177), “[…] embora o estudo dos aspectos
dinâmicos do sistema já comece na etapa de análise, é na fase de
projeto que esse estudo se concretiza e onde se realiza o
detalhamento das colaborações nas quais cada classe participa”.
Na modelagem comportamental de projeto com a UML, é
recomendável evoluir o modelo de casos de uso detalhando todos os
relacionamentos de inclusão (<<Include>>) e extensão
(<<Extend>>) entre os casos de uso. É necessário também garantir
a consistência das operações listadas nas classes de objetos com as
mensagens que executam operações indicadas nos diagramas de
sequência e com as ações definidas nos diagramas de atividades.
Além disso, é importante revisar as ações de estados representadas
pelas cláusulas predefinidas “entry, exit e do” em cada estado nos
diagramas de máquina de estados, em que cada ação de estado deve
indicar uma operação nas respectivas classes de objetos. A
modelagem comportamental deve começar na atividade de análise
para representar os aspectos dinâmicos do sistema e ser
posteriormente detalhada na modelagem de projeto.
A modelagem de projeto também inclui a definição de algoritmos
para implementação das funcionalidades do sistema, utilizando o
diagrama de atividades da UML para especificar os algoritmos. Além
disso, pode-se elaborar o projeto das interfaces gráficas (por
exemplo, formulários/telas e relatórios) correspondentes aos casos de
uso que requerem uma interface amigável, com alta usabilidade e
facilidade de operação, seguindo os princípios básicos da Interação
Humano-Computador (IHC).
De forma geral, Bezerra (2014) sintetiza as seguintes características
da evolução da documentação de análise para projeto:

 Refinamento dos aspectos estáticos e estruturais da

modelagem do sistema.
 Detalhamento dos aspectos dinâmicos da modelagem do
sistema.
 Detalhamento da arquitetura do sistema, com base na
decomposição lógica e física do sistema.
 Definição dos mecanismos de armazenamento dos dados
manipulados pelo sistema.
 Definição dos algoritmos a serem utilizados na implementação
do sistema.
 Elaboração do projeto da interface gráfica das funcionalidades
do sistema.

Finalmente, toda a documentação da atividade de projeto do sistema

deve ser estabelecida de acordo com a metodologia da empresa de
desenvolvimento, atendendo às características e particularidades do
domínio do sistema de software.

Aspectos de qualiade no desenvolvimento

O diagrama de classes, uma das ferramentas mais
utilizadas no design orientado a objetos, serve como
um mapa que detalha os tipos de objetos a serem
utilizados no sistema, suas inter-relações e outros
atributos. Quando se trata de mapeá-los para um
SGBDR, precisamos converter cada classe, atributo e
relação em elementos equivalentes dentro de uma
estrutura de banco de dados relacional, como tabelas,
colunas e chaves estrangeiras. Esse mapeamento não é
apenas uma tradução direta, mas também uma
reinterpretação dos requisitos e comportamentos dos
objetos em um novo contexto, o que pode incluir a
normalização de dados e a implementação de
restrições de integridade.

Persistência de objetos para o modelo

relacional

Os princípios básicos do paradigma orientado a objetos e do modelo

relacional são distintos. As tecnologias orientadas a objetos se
baseiam no princípio do encapsulamento, em que os objetos são
abstrações de comportamento (Guedes, 2018). No modelo relacional,
os elementos correspondem a dados em formato tabular, utilizando
um Sistema Gerenciador de Banco de Dados Relacional (SGBDR).
Portanto, um aspecto importante na modelagem de projeto é o
mecanismo de armazenamento persistente de dados, que
corresponde ao mapeamento de classes de objetos para o modelo
relacional.
Para especificar o mapeamento de classes para tabelas do modelo de
dados relacional, é comum adotar técnicas de modelagem de dados
e/ou definir o uso de frameworks de mapeamento objeto-relacional
como estratégia de armazenamento persistente. Assim, como parte
da documentação do projeto de banco de dados, deve-se apresentar
pelo menos a construção do esquema do banco de dados.
Considerando que foi definido o uso de SGBDR como mecanismo de
armazenamento dos objetos, é necessário mapear os valores de
atributos de objetos das classes persistentes para as tabelas de
banco de dados relacional, com base no modelo de classes.
A maioria das ferramentas CASE de modelagem orientada a objetos
fornece a funcionalidade de mapeamento automático para geração
de um esquema relacional a partir do modelo de classes e da
definição do SGBDR a ser utilizado. No entanto, é importante que
você conheça os procedimentos existentes para a conferência ou
elaboração do mapeamento. Vamos conhecer algumas regras
fundamentais para fazer o mapeamento de objetos para o modelo
relacional.
Primeiramente, deve-se identificar se os objetos das classes são
transientes ou persistentes. Normalmente, os objetos de entidade são
persistentes e devem ser armazenados em meio físico durante a
execução do sistema para serem manipulados. Os objetos transientes
existem somente durante uma sessão de uso do sistema e
geralmente são objetos de fronteira e de controle.
Em seguida, as classes persistentes e seus relacionamentos são
analisados, e as alternativas de mapeamento são aplicadas conforme
indicado, mantendo uma padronização na representação das tabelas
para constituir o esquema do Banco de Dados Relacional (BDR):
1. Identificação de objetos: determine se os objetos das classes são
transientes (existem apenas durante uma sessão) ou persistentes
(armazenados fisicamente).
2. Mapeamento de atributos: mapear os valores dos atributos das
classes persistentes para as colunas das tabelas no banco de dados
relacional.
3. Análise de relacionamentos: analise os relacionamentos entre as
classes persistentes e aplique as regras de mapeamento para refletir
esses relacionamentos nas tabelas do banco de dados.
4. Uso de ferramentas CASE: utilize ferramentas CASE para
automatizar a geração do esquema relacional, mas revise
manualmente o mapeamento para garantir a precisão.
Essas regras ajudam a criar um esquema de banco de dados
relacional eficiente e bem estruturado a partir do modelo de classes,
facilitando a implementação e manutenção do sistema.
Nome da tabela (coluna 1, coluna 2, coluna 3, coluna 4,… coluna n)

 Cada coluna representa um atributo da classe mapeada, no

entanto, atenção aos atributos derivados, pois eles não são
mapeados para uma coluna.
 Destaca-se a coluna que representa a chave primária com
sublinhado simples e as colunas que representam chaves
estrangeiras com sublinhado tracejado.
 Representa-se em cada tabela derivada de classe, no geral,
uma coluna que indica o identificador (Id) para a chave
primária. Essa estratégia de notação dos “Ids” define a
identidade independente dos objetos, conforme os princípios da
orientação a objetos.

Mapeamento de associação binária e mapeamento de

classe associativa

Mapeamento de associação binária: para as classes relacionadas à

associação binária, com multiplicidade um-para-muitos, mapeia-se
cada classe em uma tabela, conforme exemplo ilustrado na Figura 1.

Figura 2 | Recorte do diagrama de classes com associação binária

(um-para-muitos). Fonte: Catarino (2020, p.).
Mapeamento:
Marca (marcaId, nome).
GrupoCarro (grupoCarroId, nome, descricao, valorDiaria,
precoKm, marcaId).
Carro (carroId, anoFabricacao, placa, anoModelo, renavam, chassi,
km, imagem, observacao, situacao, combustivel, grupoCarroId).
Em uma associação binária de multiplicidade um-para-um, é possível
mapear as classes em tabelas separadas ou combinar os atributos de
ambas em uma única tabela. A escolha entre essas opções
geralmente depende das preferências do designer de banco de
dados, considerando aspectos como extensibilidade, quantidade de
tabelas e desempenho.
A Figura 3 demonstra o mapeamento realizado em tabelas distintas.
No exemplo apresentado, não são mostradas as outras classes que se
associam a ambas as classes, as quais incluiriam outras chaves
estrangeiras. Por isso, ao final de cada tabela que corresponde às
classes, foi adicionada a sigla “demaisFK”. Esse formato também é
utilizado em outros exemplos subsequentes.

Figura 3 | Recorte do diagrama de classes com associação binária

(um-para-um). Fonte: Catarino (2020, p.).
Mapeamento:
Reserva (reservaId, dataReserva, dataRetirada, horaRetirada,
dataPrevDevolucao, situacao, observacao, demaisFK).
AluguelDevolucao(aluguelDevolucaoId, dataAluguel,
dataPrevDevolucao, valorKm, valorDiaria, numeroContrato,
dataDevolucao, kmRodada, observacao,
formaPagto, reservaId, demaisFK).
Mapeamento de classe associativa: para as classes relacionadas com
associação de classe associativa, mapeia-se cada classe em uma
tabela, conforme exemplo ilustrado na Figura 3.

Figura 4 | Recorte do diagrama de classes com classe associativa.

Fonte: Catarino (2020, p.).
Mapeamento:
Carro (carroId, anoFabricacao, placa, anoModelo, renavam, chassi,
km, imagem, observacao, situacao, combustivel, grupoCarroId).
Opcionais (OpcionaisId, nome, descricao).
CarroOpcionais (carroId, OpcionaisId, original).
Para classes relacionadas com multiplicidade muitos-para-muitos,
cria-se a terceira tabela com apenas a chave primária composta,
conforme mostra a Figura 5.

Figura 5 | Recorte do diagrama de classes com associação binária

(muitos-para-muitos). Fonte: Catarino (2020, p.).
Mapeamento:
Reserva (reservaId, dataReserva, dataRetirada, horaRetirada,
dataPrevDevolucao, situacao, observacao, demaisFK).
ItemAdicional (itemAdicionalId, nome, descricao, valor).
ReservaItemAdicional (reservaId, itemAdicionalId).

Mapeamento de agregação, mapeamento

de composição e mapeamento de
generalização

Mapeamento de agregação: para classes relacionadas com

associação do tipo agregação, mapeia-se a classe “Todo” e “Parte”
para tabelas individuais. O identificador da classe “Todo” é indicado
como chave estrangeira na tabela que representa a classe “Parte”,
conforme é mostrado na Figura 6, ou seja, mesma forma de mapear
classes com associação binária.

Figura 6 | Recorte do diagrama de classes com agregação. Fonte: Catarino

(2020, p.).

Mapeamento:

Pais (paisId, nome, código, continente, idioma).

Estado (estadoId, nome, sigla, paisId).
Municipio (municipioId, nome, regiao, estadoId).
FilialLoja (filialLojaId, nome, cnpj, logradouro, complemento, bairro,
cep, telefone, celular, contatoResponsavel, municipioId).

Mapeamento de composição: no mapeamento de composição, em

que classes estão relacionadas por uma associação de composição
(um tipo específico de agregação), as classes "Todo" e "Parte" são
mapeadas para tabelas separadas. O identificador da classe "Todo" é
incorporado como parte da chave primária na tabela que representa a
classe "Parte", como ilustrado no exemplo na Figura 7.

Figura 7 | Recorte do diagrama de classes com composição. Fonte: Catarino

(2020, p.).

Mapeamento:

CreditoParcelado (creditoParceladoId, dataLancamento,

qtdadeParcelas, valorTotal, situacao, demaisFK).
ParcelaCreditoParcelado (creditoParceladoId,
parcelaCreditoParceladoId, dataVencimento, valorParcela,
dataPagamento, juro, multa, outrosAcrescimos, desconto).

Mapeamento de generalização: há três abordagens principais para o

mapeamento desse tipo de relacionamento em tabelas. Comumente,
a superclasse e suas subclasses são mapeadas cada uma em sua
própria tabela, utilizando um "Id" compartilhado. Além disso, um
atributo tipo é adicionado à tabela que representa a superclasse para
identificar os tipos de objetos que as subclasses representam,
conforme mostrado no exemplo da Figura 8.
 Figura 8 |
Recorte do diagrama de classes com generalização. Fonte: Catarino (2020,
p.)

Mapeamento – Alternativa 1:

Pessoa (pessoaId, nome, logradouro, numeroLogradouro, bairro,

cidade, estado, cep, telefone, celular, situacao,
enderecoEletronicoLogin, senhaAlfanumerica, tipoPessoa
[PF/PJ], demaisFK).
PessoaFisica (pessoaId, cpf, dataNascimento, sexo,
telefoneComercial, pessoaIdJ, demaisFK).
PessoaJuridica (pessoaId, cnpj, inscricaoEstadual, razaoSocial,
dataAberturaEmpresa, contato, desconto, demaisFK).
A segunda e a terceira abordagens são consideradas alternativas de
mapeamento de generalização.

Segundo Rumbaugh (1997, p. 506), “ […] elas são motivadas pelo

desejo de eliminar a navegação de superclasse para subclasse,
melhorando o desempenho”.

A segunda abordagem define a eliminação da tabela correspondente

à superclasse e mapeia-se uma tabela correspondente a cada
subclasse, reproduzindo todos os atributos da superclasse em cada
tabela da superclasse.

Mapeamento – Alternativa 2:

PessoaFisica (pessoaIdF, nome, logradouro, numeroLogradouro,

bairro, cidade, estado, cep, telefone, celular, situacao,
enderecoEletronicoLogin, senhaAlfanumerica, cpf, dataNascimento,
sexo, telefoneComercial, pessoaIdJ, demaisFK).
PessoaJuridica (pessoaIdJ, nome, logradouro, numeroLogradouro,
bairro, cidade, estado, cep, telefone, celular, situação,
enderecoEletronicoLogin, senhaAlfanumerica, cnpj, inscricaoEstadual,
razaoSocial, dataAberturaEmpresa, contato, desconto, demaisFK).

A terceira abordagem define a criação de uma única tabela

correspondente à superclasse, unindo todos os atributos das
subclasses ao nível da superclasse.

Mapeamento – Alternativa 3:

Pessoa (pessoaId, nome, logradouro, numeroLogradouro, bairro,

cidade, estado, cep, telefone, celular, situacao,
enderecoEletronicoLogin, senhaAlfanumerica, tipoPessoa [PF/PJ], cpf,
dataNascimento, sexo, telefoneComercial, pessoaIdJ, cnpj,
inscricaoEstadual, razaoSocial, dataAberturaEmpresa, contato,
desconto, demaisFK).

Para garantir a consistência da modelagem de análise e projeto de

um software, bem como a evolução da modelagem, é importante
utilizar todos os recursos das ferramentas CASE de modelagem e o
recurso de gerenciamento de versões ou visões dos modelos
especificados, para, assim, facilitar a leitura e interpretação do
conjunto de diagramas estáticos e dinâmicos que compõem a
documentação de um sistema de software (Catarino, 2020).

Encerramento da Unidade
Olá, estudante! Para desenvolver a competência desta Unidade, que
é aplicar técnicas, conceitos e ferramentas indispensáveis para lidar
com as potencialidades e fragilidades da UML no contexto de projetos
de software, você deverá primeiramente conhecer os conceitos
fundamentais sobre o processo de desenvolvimento de software. O
Processo Unificado (PU), pode ser utilizado para essa finalidade e o
interessante é que ele enfatiza a importância da modelagem visual,
utilizando a Unified Modeling Language (UML) para criar diagramas
que representam os diferentes aspectos do sistema. Isso facilita a
comunicação entre os membros da equipe e garante uma
compreensão clara e compartilhada do projeto. Além disso, o PU é
adaptável e pode ser customizado para atender às necessidades
específicas de diferentes projetos. Ele não é um processo rígido e
prescritivo, mas sim um framework que pode ser ajustado para
diferentes contextos e ambientes de desenvolvimento.
O PU é baseado em uma série de iterações, cada uma resultando em
uma versão incrementada do software em desenvolvimento. Essa
abordagem permite que problemas sejam identificados e corrigidos
nas fases iniciais do ciclo de desenvolvimento, reduzindo riscos e
melhorando a qualidade final do produto. As iterações são divididas
em quatro fases principais: Iniciação, Elaboração, Construção e
Transição (Bezerra, 2014).
Na fase de Iniciação, o objetivo é definir o escopo do projeto,
identificar os principais requisitos e estabelecer uma base sólida para
o desenvolvimento. Isso inclui a criação de um modelo de negócios e
a realização de uma análise de viabilidade para garantir que o projeto
seja economicamente viável e tecnicamente exequível.
A fase de Elaboração foca em detalhar os requisitos e a arquitetura
do sistema. Aqui, os desenvolvedores trabalham em estreita
colaboração com os stakeholders para refinar os requisitos e criar um
protótipo arquitetônico que sirva como base para o desenvolvimento
subsequente. Essa fase é crucial para identificar e mitigar riscos
técnicos e de negócios.
A fase de Construção envolve a implementação e a verificação do
sistema. Nessa etapa, o foco é construir o software de acordo com os
requisitos e a arquitetura definidos nas fases anteriores. O
desenvolvimento é feito em iterações curtas e frequentes, permitindo
a incorporação contínua de feedback e garantindo que o sistema
atenda às expectativas dos usuários.
Finalmente, a fase de Transição é dedicada a preparar o software
para ser entregue aos usuários finais. Isso inclui atividades como
testes finais, correção de defeitos, documentação e treinamento de
usuários. O objetivo é garantir que o sistema esteja pronto para ser
colocado em produção e que os usuários estejam preparados para
utilizá-lo de forma eficaz.
No Processo Unificado (PU), a Unified Modeling Language (UML) é
utilizada extensivamente para representar visualmente os diferentes
aspectos do sistema em desenvolvimento. Os diagramas da UML
desempenham um papel fundamental em todas as fases do PU,
evoluindo à medida que o projeto avança e se torna mais detalhado.
Aqui está uma visão de como o PU aborda os diagramas da UML em
cada fase e como eles evoluem ao longo do tempo (Bezerra, 2014).
Fase de Iniciação

Na fase de Iniciação, o foco está em compreender o escopo do projeto

e identificar os requisitos principais. Os diagramas da UML utilizados
nesta fase incluem:

 Diagrama de casos de uso: este diagrama ajuda a capturar os

principais requisitos funcionais do sistema, identificando os
atores (usuários ou outros sistemas) e suas interações com o
sistema. Ele fornece uma visão geral das funcionalidades
esperadas.
 Diagrama de atividades: utilizado para modelar o fluxo de
atividades do sistema, mostrando como os casos de uso se
relacionam e como as atividades se desenrolam.

Fase de Elaboração

Durante a fase de Elaboração, os requisitos são refinados e a

arquitetura do sistema é definida. Nessa fase, os diagramas da UML
tornam-se mais detalhados e específicos:

 Diagrama de classes: esse diagrama começa a ser esboçado

para representar a estrutura estática do sistema, mostrando as
classes, atributos, métodos e os relacionamentos entre elas. É
crucial para a definição da arquitetura do sistema.
 Diagrama de objetos: um diagrama de objetos pode ser usado
para ilustrar exemplos de objetos reais e suas relações,
fornecendo uma visão mais concreta dos modelos de classes.
 Diagrama de sequência: utilizado para detalhar como os objetos
interagem em uma sequência temporal, mostrando as
mensagens trocadas entre os objetos para realizar uma função
específica. Isso ajuda a esclarecer a dinâmica das interações.
  Diagrama de colaboração: semelhante ao diagrama de
sequência, mas focado nas colaborações entre objetos. Mostra
como os objetos colaboram para realizar operações.
 Diagrama de componentes: esse diagrama começa a ser
desenvolvido para mostrar a organização e dependências dos
componentes do sistema, auxiliando na definição da arquitetura
técnica.

Fase de Construção

Na fase de Construção, os diagramas da UML continuam a evoluir e

se detalham conforme o sistema é implementado:

 Diagrama de classes: continua a ser refinado com a adição de

detalhes como métodos específicos, visibilidade e tipos de
dados. O diagrama reflete a implementação real do sistema.
 Diagrama de sequência e colaboração: são utilizados
extensivamente para detalhar as interações entre objetos
durante a implementação de funcionalidades específicas. Eles
ajudam a garantir que o comportamento do sistema esteja
alinhado com os requisitos.
 Diagrama de máquina de estados: utilizado para modelar o
comportamento dinâmico de objetos individuais, especialmente
aqueles com estados complexos. Mostra como um objeto muda
de estado em resposta a eventos.
 Diagrama de implantação: começa a ser desenvolvido para
mostrar a configuração física do sistema, incluindo nós de
hardware e a distribuição de componentes de software. Este
diagrama é crucial para a preparação do sistema para a
produção.

Fase de Transição

Na fase de Transição, os diagramas da UML ajudam a garantir que o

sistema esteja pronto para ser entregue e utilizado:
  Diagrama de implantação: é finalizado para refletir a
configuração real do sistema no ambiente de produção,
incluindo detalhes sobre hardware, redes e componentes de
software implantados.
 Diagrama de componentes: atualizado para refletir a versão
final do sistema, mostrando todos os componentes
implementados e suas dependências.
 Diagrama de pacotes: pode ser utilizado para organizar e
modularizar o sistema, mostrando a organização dos pacotes
de software e suas relações.

Ao longo de todo o ciclo de vida do desenvolvimento, os diagramas

da UML no PU evoluem de representações abstratas e conceituais
para modelos detalhados e específicos que orientam a
implementação e a implantação do sistema. Essa evolução contínua
garante que todos os aspectos do sistema sejam bem compreendidos
e documentados, facilitando a comunicação entre os membros da
equipe e assegurando a qualidade do produto final (Medeiros, 2004).
Vale ressaltar que o PU utiliza a UML de forma flexível e adaptável,
permitindo que as empresas escolham os diagramas mais relevantes
para cada projeto. Em vez de exigir uma abordagem rígida e exata, o
PU oferece uma estrutura que pode ser personalizada de acordo com
as necessidades específicas de cada projeto. Isso permite que a
equipe de desenvolvimento selecione os diagramas que
proporcionam maior valor em termos de comunicação, compreensão
e documentação, adaptando-se à complexidade e aos requisitos do
sistema.
Durante o desenvolvimento, a equipe pode focar nos diagramas que
são mais críticos para o entendimento e a implementação do sistema.
Por exemplo, em projetos com uma estrutura estática complexa, pode
haver um foco maior nos diagramas de classes e componentes,
enquanto projetos com comportamento dinâmico complexo podem
enfatizar os diagramas de estados e de sequência. Essa abordagem
iterativa e incremental permite que os diagramas evoluam e sejam
refinados à medida que o projeto avança, refletindo mudanças nos
requisitos e nas descobertas técnicas.
A flexibilidade do PU também se estende à integração com outras
metodologias. Empresas podem combinar o PU com práticas ágeis ou
híbridas, utilizando apenas os elementos da UML que se alinham com
seu fluxo de trabalho e objetivos. Ferramentas de modelagem que
suportam a geração e atualização automatizada de diagramas
facilitam a manutenção de modelos atualizados, reduzindo o esforço
manual e permitindo que a equipe se concentre em aspectos mais
críticos do desenvolvimento.
Além disso, o envolvimento dos stakeholders e as considerações de
tempo e recursos influenciam a escolha dos diagramas. Diagramas
que ajudam a comunicar melhor as funcionalidades e o
comportamento do sistema aos stakeholders podem ser priorizados.
Em projetos com prazos apertados, a equipe pode optar por criar
apenas os diagramas essenciais. A abordagem flexível do PU permite
melhorias contínuas, ajustando quais diagramas são mais eficazes e
relevantes, garantindo assim o sucesso do projeto.
Outro ponto importante é compreender a abstração que pode ser
feita entre os diagramas de classes e os sistemas gerenciadores de
banco de dados relacional. Os princípios básicos do paradigma
orientado a objetos e do modelo relacional são distintos. Enquanto as
tecnologias orientadas a objetos se baseiam no encapsulamento,
abstraindo o comportamento através de objetos, o modelo relacional
organiza dados em formato tabular utilizando sistemas gerenciadores
de banco de dados relacional (SGBDR). Na modelagem de projeto, o
mecanismo de armazenamento persistente de dados é crucial,
envolvendo o mapeamento de classes de objetos para o modelo
relacional (Catarino, 2020).
Para especificar esse mapeamento, são adotadas técnicas de
modelagem de dados ou frameworks de mapeamento objeto-
relacional como estratégia de armazenamento persistente. A
documentação do projeto de banco de dados deve incluir a
construção do esquema do banco, detalhando como as classes são
traduzidas para tabelas no modelo relacional. Isso envolve mapear
atributos de objetos das classes persistentes para as tabelas do
banco de dados relacional, seguindo o modelo de classes.
Ferramentas CASE de modelagem orientada a objetos
frequentemente oferecem mapeamento automático para gerar
esquemas relacionais a partir do modelo de classes e da definição do
SGBDR. No entanto, é essencial conhecer e revisar os procedimentos
de mapeamento para garantir precisão. O processo inclui identificar
objetos transientes e persistentes, mapear atributos de classes
persistentes para colunas de tabelas e analisar relacionamentos entre
classes, aplicando as regras de mapeamento adequadas (Catarino,
2020).
Essas regras ajudam a criar um esquema de banco de dados
relacional eficiente, representando cada tabela com colunas
correspondentes aos atributos das classes mapeadas. Atenção deve
ser dada aos atributos derivados, chaves primárias e estrangeiras, e a
notação dos identificadores (Ids), que definem a identidade
independente dos objetos conforme os princípios da orientação a
objetos.
Com esses conhecimentos, é possível perceber que a UML é uma
poderosa ferramenta para o desenvolvimento de software. A evolução
dos diagramas contribui para a formulação de projetos mais bem
estruturados e concisos. A utilização do diagrama de classes para
definir o esquema do banco de dados ilustra a versatilidade da UML,
mostrando que essa linguagem pode ser aplicada em uma ampla
variedade de projetos.