Análise e Projeto de Locadora de Veículos

Prévia do material em texto

Disciplina
ANÁLISE ORIENTADA A OBJETOS
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 de empresa O sistema deve prover
um cadastro das
empresas
conveniadas com a
locadora de veículos.
RF4 Cadastro de grupo de
carro
O sistema deve prover
um cadastro de
grupos de carros para
categorizar os carros
por características. 
RF5 Cadastro de carro O sistema deve prover
um cadastro dos
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 de reserva de
carro
O sistema deve prover
um controle de
reserva de carros para
clientes da locadora.
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
Disciplina
ANÁLISE ORIENTADA A OBJETOS
comprovante da
reserva para o cliente
via e-mail e/ou SMS. 
RF7 Controle de aluguel de
carro
O sistema deve prover
um controle de
aluguel de carros para
clientes da locadora. 
RF8 Emissão de contrato
de aluguel
O sistema deve emitir
cópias do contrato de
aluguel.
RF9 Controle de devolução
de carro
O sistema deve prover
um controle de
devolução de carros.
Uma devolução refere-
se à baixa de um
aluguel. O controle de
devolução estará
integrado com o
módulo de
pagamento.
RF10 Emissão de nota �scal
de aluguel
O sistema deve emitir
a nota �scal de
serviço, referente ao
aluguel de um carro. A
nota �scal pode ser
impressa ou enviada
por e-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 uni�cado – análise e projeto, a atividade de análise
foca em identi�car e de�nir 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 especi�cados na análise esclarecem o problema a ser resolvido. No entanto, as
Disciplina
ANÁLISE ORIENTADA A OBJETOS
perspectivas do sistema fornecidas por esses modelos não são su�cientes 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 de�nindo os casos de uso baseados nos
requisitos funcionais identi�cados 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 identi�caçã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.
Especi�ca-se, então, o modelo de classes, geralmente em várias perspectivas de visão. Com a
primeira versão do modelo de classes de�nida, é 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 identi�cados nesta fase.
Modelo de casos de uso e diagrama de classes
A partir da de�nição dos requisitos funcionais analisamos os requisitos identi�cados 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 especi�cação dos casos de uso, é crucial catalogar todos os casos de uso
identi�cados 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 especi�caçã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 identi�cados pela análise desses
Disciplina
ANÁLISE ORIENTADA A OBJETOS
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 de�nido 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 de�nir 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 >. Se o
cliente desejar, pode imprimir esse comprovante após con�rmar a reserva, mostrado no
diagrama pelo relacionamento de extensão >. Lembre-se que os relacionamentos
> e > são tipos especí�cos de dependências entre casos de uso, indicando
sequências de interações e execuções obrigatórias, respectivamente.
Disciplina
ANÁLISE ORIENTADA A OBJETOS
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 de�nidos 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 identi�caçã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 identi�caçã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
Disciplina
ANÁLISE ORIENTADA A OBJETOS
Cliente”, é necessário de�nir 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.
Siga em Frente...
Após identi�car as classes e atributos, é crucial veri�car 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, re�nada 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,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).
Disciplina
ANÁLISE ORIENTADA A OBJETOS
Siga em Frente...
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 identi�cador 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 (�lialLojaId, 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í�co de agregação), as classes
"Todo" e "Parte" são mapeadas para tabelas separadas. O identi�cador da classe "Todo" é
incorporado como parte da chave primária na tabela que representa a classe "Parte", como
ilustrado no exemplo na Figura 7.
Disciplina
ANÁLISE ORIENTADA A OBJETOS
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 identi�car os tipos de objetos que as
subclasses representam, conforme mostrado no exemplo da Figura 8.
Disciplina
ANÁLISE ORIENTADA A OBJETOS
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).
Disciplina
ANÁLISE ORIENTADA A OBJETOS
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 de�ne 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 de�ne 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 especi�cados,
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).
Vamos Exercitar?
Considerando as alternativas de mapeamento de classes para tabelas de banco de dados
relacional, segue o esquema do banco de dados correspondente ao sistema “Locação de
Veículos”.
Disciplina
ANÁLISE ORIENTADA A OBJETOS
Uma sugestão para elaborar o mapeamento é iniciar o mapeamento das tabelas que não têm
chave estrangeira, posteriormente as demais tabelas e, ao �nalizar o mapeamento, classi�car as
tabelas e listá-las em ordem alfabética.
Esquema do módulo md_Locacao_dc:
AluguelDevolucao(aluguelDevolucaoId, dataAluguel, dataPrevDevolucao, valorKm, valorDiaria,
numeroContrato, dataDevolucao, kmRodada, observacao, formaPagto, reservaId, carroId,
pessoaId, �lialIdR, �lialIdD, tipoPagamentoId)
AluguelDevolucaoItemAdicional (aluguelDevolucaoId, itemAdicionalId)
Carro (carroId, placa, anoFabricacao, anoModelo, renavam, chassi, km, imagem, observacao,
situacao, combustivel, grupoCarroId)
GrupoCarro (grupoCarroId, nome, descricao, valorDiaria, precoKm, marcaId)
ItemAdicional (itemAdicionalId, nome, descricao, valor)
Marca (marcaId, nome)
Pais (paisId, nome, código, nacionalidade, idioma, continente, sigla)
Pessoa (pessoaId, nome, logradouro, numeroLogradouro, bairro, cidade, estado, cep, telefone,
celular, situacao, enderecoEletronicoLogin, senhaAlfanumerica, tipoPessoa [PF/PJ], paisId)
PessoaFisica (pessoaId, cpf, dataNascimento, sexo, telefoneComercial, pessoaIdJ, pro�ssaoId)
PessoaJuridica (pessoaId, cnpj, inscricaoEstadual, razaoSocial, dataAberturaEmpresa, contato,
desconto, ramoId)
Pro�ssao (pro�ssaoId, cbo, nome)
RamoAtividade (ramoId, cnae, nome)
Reserva (reservaId, dataReserva, dataRetirada, horaRetirada, dataPrevDevolucao, situacao,
observacao, grupoCarroId, pessoaId, �lialIdR, �lialIdD)
ReservaItemAdicional (reservaId, itemAdicionalId)
Saiba mais
Quer entender mais sobre o mapeamento objeto-relacional? Leia o artigo Mapeamento objeto-
relacional: como funciona e técnicas.
Para entender mais sobre o SGBD, leia SGBD: o que é, como funciona e principais vantagens.
E para compreender ainda melhor os diagramas de classes, Acesse o livro UML Essencial e leia o
Capítulo 3.
Referências
CATARINO, I. C. S. Análise orientada a objetos. Londrina: Editora e Distribuidora Educacional S.A.,
2020.
GUEDES, G. T. A. UML: uma abordagem prática. 3. ed. São Paulo: Novatec, 2018.
https://blog.geekhunter.com.br/mapeamento-objeto-relacional/
https://blog.geekhunter.com.br/mapeamento-objeto-relacional/
https://www.fiveacts.com.br/sgbd
https://integrada.minhabiblioteca.com.br/reader/books/9788560031382/epubcfi/6/2%5Bidloc_000.xhtml-itemref%5D!/4%5Beid1%5D/2%5Beid2%5D%4050:3
Disciplina
ANÁLISE ORIENTADA A OBJETOS
RUMBAUGH, J. et al. Modelagem e projetos baseados em objetos. Rio de Janeiro: Campus, 1997.
Aula 5
Encerramento da Unidade
Videoaula de Encerramento
Este conteúdo é um vídeo!
Para assistir este conteúdo é necessário que você acesse o AVA pelo
computador ou pelo aplicativo. Você pode baixar os vídeos direto no aplicativo
para assistir mesmo sem conexão à internet.Dica para você
Aproveite o acesso para baixar os slides do vídeo, isso pode deixar sua
aprendizagem ainda mais completa.
Bem-vindo à nossa videoaula! Exploraremos a evolução dos diagramas da UML com o Processo
Uni�cado (PU) e o mapeamento de elementos do diagrama de classes para um Sistema
Gerenciador de Banco de Dados (SGBD). Esses conhecimentos são essenciais para criar projetos
de software robustos e e�cientes, fundamentais para a prática pro�ssional em desenvolvimento
de sistemas. Não perca esta oportunidade de aprimorar suas habilidades!
Ponto de Chegada
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 Uni�cado (PU),
pode ser utilizado para essa �nalidade e o interessante é que ele enfatiza a importância da
modelagem visual, utilizando a Uni�ed 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í�cas 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.
Disciplina
ANÁLISE ORIENTADA A OBJETOS
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 identi�cados e
corrigidos nas fases iniciais do ciclo de desenvolvimento, reduzindo riscos e melhorando a
qualidade �nal 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 é de�nir o escopo do projeto, identi�car 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 re�nar os
requisitos e criar um protótipo arquitetônico que sirva como base para o desenvolvimento
subsequente. Essa fase é crucial para identi�car e mitigar riscos técnicos e de negócios.
A fase de Construção envolve a implementação e a veri�cação do sistema. Nessa etapa, o foco é
construir o software de acordo com os requisitos e a arquitetura de�nidos 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
�nais. Isso inclui atividades como testes �nais, 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 e�caz.
No Processo Uni�cado (PU), a Uni�ed 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 identi�car 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, identi�cando 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 �uxo de atividades do sistema,
mostrando como os casos de uso se relacionam e como as atividades se desenrolam.
Fase de Elaboração
Disciplina
ANÁLISE ORIENTADA A OBJETOS
Durante a fase de Elaboração, os requisitos são re�nados e a arquitetura do sistema é de�nida.
Nessa fase, os diagramas da UML tornam-se mais detalhados e especí�cos:
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 de�niçã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í�ca. 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 de�niçã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 re�nado com a adição de detalhes como métodos
especí�cos, visibilidade e tipos de dados. O diagrama re�ete 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í�cas. 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 con�guraçã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: é �nalizado para re�etir a con�guração real do sistema no
ambiente de produção, incluindo detalhes sobre hardware, redes e componentes de
software implantados.
Disciplina
ANÁLISE ORIENTADA A OBJETOS
Diagrama de componentes: atualizado para re�etir a versão �nal 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í�cos 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 �nal  (Medeiros, 2004).
Vale ressaltar que o PU utiliza a UML de forma �exí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í�cas de cadaprojeto. 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 re�nados à medida que o projeto avança, re�etindo mudanças nos requisitos e
nas descobertas técnicas.
A �exibilidade 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 �uxo 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
in�uenciam 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 �exível do PU permite melhorias contínuas, ajustando quais diagramas são mais
e�cazes 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
Disciplina
ANÁLISE ORIENTADA A OBJETOS
de armazenamento persistente de dados é crucial, envolvendo o mapeamento de classes de
objetos para o modelo relacional (Catarino, 2020).
Para especi�car 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 de�nição do
SGBDR. No entanto, é essencial conhecer e revisar os procedimentos de mapeamento para
garantir precisão. O processo inclui identi�car 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 e�ciente, 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
identi�cadores (Ids), que de�nem 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 de�nir o esquema
do banco de dados ilustra a versatilidade da UML, mostrando que essa linguagem pode ser
aplicada em uma ampla variedade de projetos.
É Hora de Praticar!
Este conteúdo é um vídeo!
Para assistir este conteúdo é necessário que você acesse o AVA pelo
computador ou pelo aplicativo. Você pode baixar os vídeos direto no aplicativo
para assistir mesmo sem conexão à internet.
Considere que você é o projetista de banco de dados, integrante da equipe de desenvolvedores
responsável pelo sistema “Locação de Veículos”, e como parte da documentação referente a
modelagem de dados você precisa apresentar o mapeamento das classes para tabelas do Banco
de Dados Relacional (BDR) correspondente ao modelo de classes a seguir:
Disciplina
ANÁLISE ORIENTADA A OBJETOS
Figura 1 | Diagrama de classes (Análise) – md_Pagamento_dc. Fonte: Catarino (2020, p.).
Para especi�cação das tabelas, adote a notação “Nome da Tabela (coluna 1, coluna 2, coluna 3,
coluna 4, coluna n)”, representando, assim, o esquema completo do banco de dados.
Na de�nição dos relacionamentos do diagrama de classes, existe uma regra ou padrão para
de�nir a multiplicidade do relacionamento do tipo associação?
Das diferentes técnicas de modelagem comportamentais da UML, o diagrama de sequência é a
técnica recomendada para especi�car 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?
O relacionamento do tipo generalização estabelecido entre classes do diagrama de classes
indica o princípio de herança entre classes genéricas e classes especializadas, o qual representa
a propriedade pela qual uma classe pode herdar atributos e operações de uma classe que
generaliza as características e comportamentos comuns de um grupo de objetos. Assim, no
diagrama de classes re�nado para a atividade de projeto é obrigatório estabelecer o
relacionamento de generalização entre classes?
Considerando as alternativas de mapeamento de classes para tabelas de banco de dados
relacional, segue o esquema do banco de dados correspondente ao sistema “Locação de
Disciplina
ANÁLISE ORIENTADA A OBJETOS
Veículos”.
Uma sugestão para elaborar o mapeamento é iniciar o mapeamento das tabelas que não têm
chave estrangeira, posteriormente as demais tabelas e, ao �nalizar o mapeamento, classi�car as
tabelas e listá-las em ordem alfabética.
Caixa (caixaId, data, horaAbertura, horaFechamento, saldoEntrada, saldoMovimentacao,
saldoFechamento, situcao, aluguelDevolucaoId)
CreditoParcelado (creditoParceladoId, dataLancamento, qtdadeParcelas, valorTotal,
situacao, aluguelDevolucaoId)
ParcelaCreditoParcelado (creditoParceladoId, parcelaCreditoParceladoId, dataVencimento,
valorParcela, dataPagamento, juro, multa, outrosAcrescimos, desconto)
TipoPagamento (tipoPagamentoId, nome)
Assimile
Toda documentação da atividade de projeto do sistema deve ser estabelecida de acordo
com as de�nições da metodologia da empresa de desenvolvimento, atendendo às
características e particularidades do domínio do sistema de software. O infográ�co a seguir
sintetiza as seguintes características da evolução da documentação de análise para
projeto.
Disciplina
ANÁLISE ORIENTADA A OBJETOS
BEZERRA, E. Princípios de análise e projeto de sistemas com UML. 3. ed. Rio de Janeiro: Elsevier,
2014.
CATARINO, Iolanda Cláudia Sanches. Análise orientada a objetos. Londrina: Editora e
Distribuidora Educacional S.A., 2020.
MEDEIROS, E. S. Desenvolvendo software com UML 2.0: de�nitivo. São Paulo: Pearson, 2004.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 de�nir sua
associação com as classes "Reserva" e "AluguelDevolucao".
Disciplina
ANÁLISE ORIENTADA A OBJETOS
Fonte 8 | Diagrama de classes (análise) – md_Locacao_dc. Fonte: Catarino (2020, p.).
Ao de�nir a nomenclatura para o nome das classes, atributos e operações em um modelo de
classes, é essencial seguir convenções especí�cas 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 de�niçã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 "�liação" (nome da mãe e nome do
Disciplina
ANÁLISE ORIENTADA A OBJETOS
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 de�ne um formato especí�co para a documentação dos
casos de uso, permitindo �exibilidade 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á�ca 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 especi�car os
estados e suas transições dos objetos das classes que apresentam estados relevantes, como é
o caso das classes “Reserva”, “Carro” e “Pessoa”.
Vamos Exercitar?
Considerando as regras de negócio de�nidas 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
Disciplina
ANÁLISE ORIENTADA A OBJETOS
possível.
Figura 10 | Diagrama de classes (análise) – md_Pagamento_dc. Fonte: Catarino (2020, P.).
Observa na �gura 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 especi�cadas 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 �nanceira que autoriza pagamentos de transações feitas on-line em websites de
empresas) para efetuar esses pagamentos.
Saiba mais
O Processo Uni�cado (PU), também conhecido como Rational Uni�ed Process (RUP), é uma
metodologia de desenvolvimento de software criada pela Rational Software Corporation e
posteriormente adquirida pela IBM. Ele é baseado em uma abordagem orientada a objetos e é
projetado para ser iterativo e incremental, signi�cando que o software é desenvolvido em
Disciplina
ANÁLISE ORIENTADA A OBJETOS
pequenos ciclos, com funcionalidades adicionadas em cada iteração . Para ler mais sobre o
processo uni�cado, leia o artigo: O Processo Uni�cado.
Para poder modelar todos os diagramas vistos nesta aula, você pode utilizar a ferramenta online
Visual Paradigma Online.
O livro Utilizando UML e Padrões apresenta como essa linguagem é aplicada durante um projeto.
Referências
BEZERRA, E. Princípios de análise e projeto de sistemas com UML. 3. ed. Rio de Janeiro: Elsevier,
2014.
CATARINO, I. C. S. Análise orientada a objetos. Londrina: Editora e Distribuidora Educacional S.A.,
2020.
MEDEIROS, E. S. Desenvolvendo software com UML 2.0: de�nitivo. São Paulo: Pearson, 2004.
SOMMERVILLE, I. Engenharia de software. 10. ed. São Paulo: Pearson Education do Brasil, 2018.
Aula 2
Modelagem complementar
Modelagem complementar
Este conteúdo é um vídeo!
Para assistir este conteúdo é necessário que você acesse o AVA pelo
computador ou pelo aplicativo. Você pode baixar os vídeos direto no aplicativo
para assistir mesmo sem conexão à internet.
Dica para você
Aproveite o acesso para baixar os slides do vídeo, isso pode deixar sua
aprendizagem ainda mais completa.
Nesta videoaula, exploraremos a essencialidade da modelagem a partir do diagrama de estrutura
composta, enfocando nas colaborações fundamentais do sistema. Além disso, abordaremos a
modelagem comportamental e de interação, com ênfase em diagramas de atividades, máquina
https://medium.com/contexto-delimitado/o-processo-unificado-d102b1fc9d00
https://online.visual-paradigm.com/pt/diagrams/features/uml-tool/
https://integrada.minhabiblioteca.com.br/reader/books/9788577800476/pageid/0
Disciplina
ANÁLISE ORIENTADA A OBJETOS
de estados e sequência. Esses conteúdos são cruciais paraaprimorar sua prática pro�ssional,
oferecendo ferramentas robustas para o desenvolvimento e compreensão de sistemas
complexos. Não perca essa oportunidade de aprofundar seus conhecimentos! Assista agora e
fortaleça suas habilidades.
Ponto de Partida
Caro aluno, bem-vindo à aula dedicada à modelagem complementar na análise e projeto do caso
de estudo proposto!
Prosseguimos com a modelagem estrutural do sistema de "Locação de Veículos" iniciando pelo
diagrama de estrutura composta. Em seguida, focamos na modelagem dinâmica, utilizando o
diagrama de máquina de estados para detalhar os estados e transições dos objetos das classes
previamente identi�cadas no diagrama de classes. Concluímos com o diagrama de atividades e
o diagrama de sequência para documentar os principais casos de uso do sistema.
O diagrama de estrutura composta, parte da UML 2.0, ilustra as colaborações entre elementos
que executam funções especí�cas, essenciais para a realização dos casos de uso. Por exemplo,
para os casos de uso "Reservar Carro", "Alugar Carro" e "Devolver Carro" do sistema "Locação de
Veículos", esse diagrama detalha a interação entre objetos.
O diagrama de máquina de estados revela o comportamento dos objetos por meio de estados e
transições, elaborado para classes como “Reserva”, “Pessoa”, “Carro” e “AluguelDevolução”.
O diagrama de atividades descreve o �uxo de controle das atividades, essencial para representar
processos de negócios completos ou funcionalidades especí�cas, aplicado, por exemplo, aos
casos de uso "Reservar Carro" e "Acessar Conta Cliente".
O diagrama de sequência, outro componente vital da UML, ordena as interações temporais entre
objetos em um processo ou caso de uso, sendo utilizado para os casos de uso “Alugar Carro” e
“Devolver Carro”.
Na aula 4.1, iniciamos a modelagem estrutural do módulo "Pagamento", integrado ao sistema de
"Locação de Veículos". Agora, como analista de sistemas desse módulo, você deverá avançar na
modelagem comportamental.
No desenvolvimento do diagrama de classes, identi�camos um atributo de situação para a
classe “Caixa” (Figura 1). Consideramos, então, os estados "Aberto", "Liberado" e "Fechado" para
essa classe, com regras especí�cas para a transição entre esses estados. 
Disciplina
ANÁLISE ORIENTADA A OBJETOS
Figura 1 | Classe caixa – módulo pagamento. Fonte: Catarino (2020, p.).
Para os objetos da classe “Caixa”, os estados de�nidos são: Aberto, Liberado e Fechado. As
regras de�nidas são as seguintes:
Todo Caixa, ao ser cadastrado, deve assumir automaticamente a situação de Aberto.
Todo Caixa Aberto deve assumir a situação de Liberado a partir das 8h ou sob a
autorização de um gerente.
Todo Caixa Liberado deve assumir a situação de Fechado a partir das 18h ou sob a
autorização de um gerente.
Todo Caixa Fechado deve assumir a situação de Aberto a partir das 6h do próximo dia.
1. Considerando as regras de�nidas para a classe “Caixa”, elabore o diagrama de máquina de
estados.
2. Considerando os diagramas comportamentais apresentados nesta seção e os fragmentos
de interação apresentados nos diagramas, elabore o diagrama de visão geral de interação
Disciplina
ANÁLISE ORIENTADA A OBJETOS
(com quadros de ocorrência de interação do diagrama de sequência) correspondente ao
processo de locar um carro, envolvendo o cadastro de um cliente, a reserva de um carro, o
aluguel de um carro e o processo que envolve a devolução do carro.
Esse trabalho reforça seu aprendizado na modelagem de projetos. Bons Estudos!
Vamos Começar!
Diagrama de estrutura composta
Tendo �nalizado 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 de�nidas 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 identi�car
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í�ca, 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:
Disciplina
ANÁLISE ORIENTADA A OBJETOS
O objeto cliente (PessoaFisica), indicando quem realiza a reserva.
O objeto loja (FilialLoja), especi�cando 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.
Figura 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
re�ete a comunicação entre os objetos envolvidos para efetivar o aluguel. Assim, entende-se que
cada aluguel pode estar associado aos seguintes objetos:
Disciplina
ANÁLISE ORIENTADA A 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), especi�cando a loja de onde o carro foi retirado.
Outro objeto loja (FilialLoja), que de�ne a loja onde o carro será devolvido.
O objeto carro (Carro), especi�cando o carro escolhido para o aluguel e, com a con�rmaçã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 aestrutura, 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:
Disciplina
ANÁLISE ORIENTADA A OBJETOS
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 con�rmada.
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 solidi�car 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 identi�cadas no diagrama de classes como possuidoras de
estados relevantes. Adicionalmente, a classe "AluguelDevolucao" também foi de�nida com
estados importantes para melhorar o controle e a e�ciê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 "especi�ca 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 identi�car as regras de negócio
que se aplicam aos objetos com estados relevantes, de�nindo de maneira clara os estados e
suas transições, que são os componentes fundamentais do diagrama.
Disciplina
ANÁLISE ORIENTADA A OBJETOS
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 de�nidos são: Ativa, Preferencial,
Inadimplente e Encerrada. As regras especí�cas são:
Ao ser cadastrada, toda pessoa deve automaticamente ser classi�cada 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 classi�cada como Encerrada se a gerência determinar por um
motivo especí�co.
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 de�nidos 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 de�nidos são: Realizada, Con�rmada e
Cancelada. As regras estabelecidas para essas transições de estado são:
Ao ser cadastrada, toda reserva deve automaticamente entrar no estado Realizada.
Disciplina
ANÁLISE ORIENTADA A OBJETOS
Uma reserva no estado Realizada deve mudar para Con�rmada 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 Con�rmada ou Cancelada não devem transitar para outros estados.
O diagrama de máquina de estados, mostrado na Figura 6, destaca os estados de�nidos para a
classe "Reserva". As transições entre esses estados são claramente marcadas com condições
de guarda, re�etindo 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 de�nidos são: Disponível, Alugado, Manutenção
Interna, Manutenção Externa e Inativo. Seguem as regras especí�cas 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 classi�cado 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 de�nidos para a
classe "Carro", e as transições entre esses estados são claramente indicadas com condições de
guarda, re�etindo as regras de negócio estipuladas.
Disciplina
ANÁLISE ORIENTADA A OBJETOS
Figura 7 | Diagrama de máquina de estados – Classe Carro. Fonte: Catarino (2020, p.).
Para os objetos da classe “AluguelDevolução”, de�nimos estados especí�cos 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
con�rmado.
Um aluguel Realizado pode ser alterado para Cancelado se o aluguel não for con�rmado
por algum motivo.
Para a fase de devolução dos carros alugados, os estados de�nidos 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 é
con�rmada.
Do estado Recuperado, a devolução pode passar para Cancelado se a devolução do carro
não for con�rmada por algum motivo.
Disciplina
ANÁLISE ORIENTADA A OBJETOS
O diagrama de máquina de estados, apresentado na Figura 8, ilustra os estados de�nidos para a
classe “AluguelDevolução”, com transições de estados claramente indicadas por condições de
guarda, re�etindo 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çãodo processo de desenvolvimento do sistema, a especi�caçã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
Disciplina
ANÁLISE ORIENTADA A OBJETOS
associadas sejam corretamente incorporadas e funcionem conforme o planejado, re�etindo os
requisitos e �uxos de trabalho de�nidos.
Diagrama de atividades e diagrama de sequência
Considerando que os casos de uso estão de�nidos, é 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í�ca 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 �uxogramas. Além de possuir toda a semântica existente em um �uxograma, 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 �uxos 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 in�nitivo, re�etindo 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 �uxo de trabalho que de�ne 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/�lial, 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/�lial, data e hora) da devolução do veículo.
�. Sistema recupera lojas cadastradas para devolução.
7. Cliente seleciona loja para devolução.
�. 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.
Disciplina
ANÁLISE ORIENTADA A OBJETOS
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 con�rma reserva.
1�. Sistema registra reserva.
17. Sistema disponibiliza opção de imprimir comprovante da reserva.
1�. 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/�liais 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.
Disciplina
ANÁLISE ORIENTADA A OBJETOS
Figura 9 | Diagrama de atividades – Reservar Carro. Fonte: Catarino (2020, p.).
Siga em Frente...
Para �nalizar 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”.
Disciplina
ANÁLISE ORIENTADA A OBJETOS
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á�ca 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”, “�lialLoja: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á�ca 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 �m, 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 re�nado em
conformidade com padrões de implementação e compor a modelagem da atividade de projeto.
Disciplina
ANÁLISE ORIENTADA A OBJETOS
Figura 10 | Diagrama de sequência – Alugar Carro. Fonte: Catarino (2020, p.).
Disciplina
ANÁLISE ORIENTADA A OBJETOS
Figura 11 | Diagrama de comunicação – Devolver Carro. Fonte: Catarino (2020, p.).
Vamos Exercitar?
Considerando as regras de�nidas para as transições entre os estados dos objetos da classe
“Caixa”, segue o diagrama de máquina de estados, como proposta de uma solução.
Disciplina
ANÁLISE ORIENTADA A OBJETOS
Figura 12 | Diagrama de máquina de estado – Classe Caixa. Fonte: Catarino (2020, p.).
A Figura 13 mostra o diagrama de visão geral de interação, que ilustra o processo completo de
locação de um carro, englobando todos os casos de uso associados, como o cadastramento de
um cliente, a reserva de um carro, o aluguel de um carro e a devolução do carro:
Este diagrama é uma adaptaçãodo diagrama de atividades, combinando diferentes tipos de
diagramas de interação para mostrar um processo geral. No diagrama, são empregados dois
tipos de quadros:
1. Quadros de interação: incluem a representação completa de qualquer tipo de diagrama de
interação.
2. Quadros de ocorrência de interação: fazem referência a um diagrama de interação existente,
mas sem mostrar todos os detalhes.
Cada quadro de ocorrência de interação no diagrama da Figura 13 destaca os diagramas de
sequência para cada caso de uso envolvido no processo de locação de um carro.
Disciplina
ANÁLISE ORIENTADA A OBJETOS
Figura 13 | Diagrama de visão geral de interação – Locar Carro. Fonte: Catarino (2020, p.).
 
Disciplina
ANÁLISE ORIENTADA A OBJETOS
Saiba mais
O livro UML e C++ é um guia autoexplicativo para analistas e desenvolvedores de software. Ele
ensina como, realmente, praticar modelagem orientada a objeto usando a notação da UML e
implementar o modelo com C++.
Quer ler mais sobre os diagramas de estrutura composta? Acesse o livro UML Essencial e leia o
Capítulo 13.
O livro Utilizando UML e Padrões apresenta como essa linguagem é aplicada durante um projeto.
Referências
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.
CATARINO, I. C. S. Análise orientada a objetos. Londrina: Editora e Distribuidora Educacional S.A.,
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: de�nitivo. São Paulo: Pearson, 2004.
Aula 3
Transição de análise para projeto
Transição de análise para projeto
Este conteúdo é um vídeo!
Para assistir este conteúdo é necessário que você acesse o AVA pelo
computador ou pelo aplicativo. Você pode baixar os vídeos direto no aplicativo
para assistir mesmo sem conexão à internet.
Dica para você
https://plataforma.bvirtual.com.br/Leitor/Publicacao/40/pdf/0
https://integrada.minhabiblioteca.com.br/reader/books/9788560031382/epubcfi/6/2%5Bidloc_000.xhtml-itemref%5D!/4%5Beid1%5D/2%5Beid2%5D%4050:3
https://integrada.minhabiblioteca.com.br/reader/books/9788577800476/pageid/0
Disciplina
ANÁLISE ORIENTADA A OBJETOS
Aproveite o acesso para baixar os slides do vídeo, isso pode deixar sua
aprendizagem ainda mais completa.
Bem-vindo à nossa videoaula focada em modelagem de projeto, modelagem de classe de projeto
e re�namento dos aspectos comportamentais. Ao longo desta aula, você aprenderá a estruturar
projetos e�cientemente, criar classes de projeto claras e re�nar comportamentos essenciais,
habilidades cruciais para o sucesso na sua carreira de desenvolvedor. Esses conceitos não só
aprimoram sua capacidade técnica, mas também elevam sua visão estratégica em projetos
complexos. Não perca a oportunidade de aprofundar seu conhecimento.
Ponto de Partida
Caro aluno, nesta aula, apresentaremos a transição da análise para o projeto no desenvolvimento
de sistemas orientados a objetos, considerando a adoção da Linguagem de Modelagem
Uni�cada (UML – Uni�ed Modeling Language) e os princípios do Processo Uni�cado (PU –
Uni�ed Process), que surgiu para apoiar a UML. O PU enfatiza o desenvolvimento orientado a
casos de uso, de forma iterativa e incremental, fornecendo uma maneira sistemática e evolutiva
de modelar sistemas sob diferentes aspectos de análise e detalhamento.
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 re�nada 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 é de�nida pela metodologia de desenvolvimento do sistema, conforme a
preferência de cada equipe de desenvolvedores ou empresa.
Nas aulas anteriores, abordamos todas as características das técnicas de modelagem da UML.
Além disso, você compreendeu que a UML descreve um sistema em três principais perspectivas:
estrutural, que enfatiza a visão estática do sistema; funcional, que representa as funcionalidades
do sistema; e dinâmica, que representa o comportamento do sistema em tempo de execução.
Assim, dentre as técnicas de modelagem propostas pela UML – estruturais, comportamentais e
de interação –, o importante é saber de�nir quais técnicas são ideais para a modelagem de
análise e de projeto, conforme o tipo e domínio do sistema.
Nesta aula, você compreenderá os pontos essenciais do detalhamento dos aspectos estruturais
do diagrama de classes. Veremos como apresentar o diagrama de classes da atividade de
projeto, de�nir o tipo de dados de cada atributo, listar todas as operações identi�cadas na
modelagem dos diagramas comportamentais e de interação, e revisar os relacionamentos.
Para você exercitar o que aprendeu, escreva com suas palavras como deve ser o re�namento dos
diagramas elaborados na análise, com detalhes aplicados à implementação. Além disso,
apresente a importância deste re�namento e a utilização de estereótipos de classes.
Disciplina
ANÁLISE ORIENTADA A OBJETOS
Bons estudos!
Vamos Começar!
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
Uni�cado 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í�ca 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 especi�cada na análise de requisitos é desenvolvida,
concentrando-se na solução do problema por meio da abstração, identi�cação, de�niçã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 especi�cada é transformada em projeto, com novos detalhes e re�namentos que
de�nem 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 é especi�cado 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 re�namento 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. Re�namento de classes: de�nir as classes de projeto ou criar novas classes. Uma classe de
análise pode resultar em várias classes de projeto.
2. De�nição de estereótipos: classi�car as classes em estereótipos de fronteira (>),
controle (>) ou entidade(>).
Disciplina
ANÁLISE ORIENTADA A OBJETOS
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 identi�cadas nos diagramas
comportamentais e de interação.
5. Revisão de visibilidade: de�nir 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 re�exiva, 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. De�nição de classes abstratas e interfaces: especi�car 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, de�nindo 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 especi�ca um contrato de uso com o outro. A
representação grá�ca é uma linha tracejada com uma grande seta vazia, apontando para o
elemento que especi�ca o contrato.
Dependência: relacionamento de utilização entre classes, indicando que uma alteração na
especi�cação de um elemento pode afetar outro que o utiliza. A representação grá�ca é
uma linha tracejada, apontando para o item do qual o outro depende.
Ainda na de�nição das classes de projeto, é necessário de�nir o estereótipo das classes. Um
estereótipo representa uma classi�cação do elemento. Alguns estereótipos de classe adotados
Disciplina
ANÁLISE ORIENTADA A OBJETOS
no diagrama de classes de projeto são (Bezerra, 2014):
De fronteira (>): identi�ca 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 de�nição de uma interface especí�ca.
De controle (>): identi�ca 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 (>): 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, de�ne-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 re�namento da classe com os aspectos sugeridos anteriormente. Por
simpli�cação, apenas o re�namento de uma classe foi exempli�cado. 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 su�cientemente completo e
Disciplina
ANÁLISE ORIENTADA A OBJETOS
aproximando-o da implementação real.
A Figura 2 ilustra uma visão do diagrama de classes de projeto do pacote "md_Locacao_dc",
re�nado com a de�nição do tipo de dados dos atributos correspondentes à linguagem de
programação Java; a indicação do estereótipo das classes do tipo entidade (>); e a
representação das classes de�nidas com o estereótipo enumeração (>),
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 de�ne 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 classi�cador do
relacionamento de generalização. Os classi�cadores de generalização são usados para de�nir
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 prede�nidos para classes
especializadas incluem (Rumbaugh, 1997):
Completo: indica que qualquer instância da superclasse (abstrata) será uma instância de
uma das subclasses especializadas.
Disciplina
ANÁLISE ORIENTADA A OBJETOS
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 classi�cador 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 classi�cador
da generalização; caso contrário, ele pode ser suprimido. A especi�caçã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 classi�cador de generalização.
Siga em Frente...
Re�namento dos aspectos comportamentais
A modelagem de projeto pode ser complementada com diagramas comportamentais e de
interação adicionais da UML que não foram especi�cados na análise, ou os diagramas de análise
podem ser re�nados 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 (>) e extensão
(>) 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 de�nidas nosdiagramas de atividades. Além disso, é
importante revisar as ações de estados representadas pelas cláusulas prede�nidas “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 de�nição de algoritmos para implementação das
funcionalidades do sistema, utilizando o diagrama de atividades da UML para especi�car os
algoritmos. Além disso, pode-se elaborar o projeto das interfaces grá�cas (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).
Disciplina
ANÁLISE ORIENTADA A OBJETOS
De forma geral, Bezerra (2014) sintetiza as seguintes características da evolução da
documentação de análise para projeto:
Re�namento 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.
De�nição dos mecanismos de armazenamento dos dados manipulados pelo sistema.
De�nição dos algoritmos a serem utilizados na implementação do sistema.
Elaboração do projeto da interface grá�ca 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.
Vamos Exercitar?
O re�namento dos diagramas da UML elaborados na fase de análise para a implementação é um
processo essencial para garantir que os modelos estejam prontos para serem transformados em
código executável. Inicialmente, é crucial revisar os requisitos funcionais e não funcionais do
sistema para assegurar que todos os aspectos importantes estejam contemplados. Em seguida,
as classes identi�cadas durante a análise devem ser detalhadas com precisão. Isso envolve a
de�nição de atributos e métodos especí�cos, especi�cando tipos de dados e visibilidade
(público, privado, protegido), além de detalhar as responsabilidades de cada classe. As relações
entre as classes, como associações, heranças e agregações, também precisam ser claramente
especi�cadas, incluindo a cardinalidade e a direção das associações, para garantir uma
compreensão completa das interações entre os diferentes componentes do sistema.
Durante o re�namento, é importante aplicar os estereótipos de classes da UML, como
>, > e >, para categorizar as classes com base em suas
responsabilidades. As classes > representam objetos de negócio e dados persistentes,
como clientes ou produtos. As classes > servem como interfaces entre o sistema e
os atores externos, facilitando a comunicação com o usuário ou outros sistemas. Já as classes
> são responsáveis pela lógica de negócios e pelo controle do �uxo de atividades no
sistema. A utilização adequada desses estereótipos ajuda a organizar o sistema de maneira
mais estruturada, facilitando a manutenção e a escalabilidade.
O re�namento dos diagramas também envolve a revisão dos diagramas de sequência e de
colaboração para assegurar que o comportamento dinâmico do sistema esteja corretamente
modelado. Isso inclui a validação do �uxo de mensagens entre os objetos e a con�rmação de
que todas as interações necessárias são suportadas pela estrutura de classes de�nida. Além
disso, é necessário atualizar os diagramas de estados e atividades, se aplicável, para re�etir com
precisão os estados e as transições do sistema durante a execução.
Disciplina
ANÁLISE ORIENTADA A OBJETOS
A importância desse re�namento reside na garantia de que o modelo está su�cientemente
detalhado e livre de ambiguidades, permitindo que os desenvolvedores implementem o sistema
com con�ança. Um modelo bem re�nado reduz os riscos de retrabalho e de erros durante a
codi�cação, melhora a comunicação entre os membros da equipe e facilita a veri�cação e
validação do sistema contra os requisitos iniciais. Em última análise, o re�namento cuidadoso
dos diagramas da UML é um passo crucial para assegurar que o produto �nal atenda às
expectativas dos stakeholders e funcione conforme planejado.
Saiba mais
A ferramenta online Miro pode ser utilizada para modelar diagramas de classes. Acesse o site
MIRO e teste essa ferramenta para criar e re�nar os diagramas de classes.
Para ler mais sobre o diagrama de classes, acesse o site e saiba mais sobre os componentes
deste diagrama: Diagrama de Classes.
O Model-Driven Development (MDD) é uma abordagem de engenharia de software que enfatiza a
criação e utilização de modelos abstratos para guiar o desenvolvimento de sistemas. Nesse
método, os modelos não são apenas documentação, mas artefatos ativos que direcionam a
geração de código e a con�guração de sistemas. O MDD promove uma maior abstração no
processo de design, permitindo que os desenvolvedores se concentrem na lógica de negócios e
nas funcionalidades, ao invés de detalhes de implementação especí�cos da plataforma. Isso é
alcançado por meio do uso de linguagens de modelagem, como UML (Uni�ed Modeling
Language) e ferramentas especí�cas que podem transformar esses modelos em código
executável. A abordagem MDD pode aumentar a produtividade, melhorar a portabilidade entre
diferentes plataformas e facilitar a manutenção do software, visto que mudanças nos requisitos
podem ser implementadas no nível do modelo e automaticamente re�etidas no código gerado.
Para ler mais sobre esse assunto, acesse o artigo:  Model-Driven Development.
Referências
BEZERRA, E. Princípios de análise e projeto de sistemas com UML. 3. ed. Rio de Janeiro: Elsevier,
2014.
CATARINO, I. C. S. Análise orientada a objetos. Londrina: Editora e Distribuidora Educacional S.A.,
2020.
PRESSMAN, R.; MAXIM, B. Engenharia de software. 8. ed. Porto Alegre: AMGH, 2016.
RUMBAUGH, J. et al. Modelagem e projetos baseados em objetos. Rio de Janeiro: Campus, 1997.
https://miro.com/pt/diagrama/diagrama-classes-uml/
https://www.ibm.com/docs/pt-br/rational-soft-arch/9.6.1?topic=diagrams-class
https://www.inf.ed.ac.uk/teaching/courses/seoc/2006_2007/resources/Mod_MDD1.pdf
Disciplina
ANÁLISE ORIENTADA A OBJETOS
Aula 4
Aspectos de qualiade no desenvolvimento
Aspectos de qualidade no desenvolvimento
Este conteúdo é um vídeo!
Para assistir este conteúdo é necessário que você acesse o AVA pelo
computador ou pelo aplicativo. Você pode baixar os vídeos direto no aplicativo
para assistir mesmo sem conexão à internet.
Dica para você
Aproveite o acesso para baixar os slides do vídeo, isso pode deixar sua
aprendizagem ainda mais completa.
Nesta aula, você explorará conceitos fundamentais de persistência de objetos para o modelo
relacional, incluindo o mapeamento de associação binária, classe associativa, agregação,
composição e generalização. Esses conteúdos são essenciais para a prática pro�ssional, pois
garantem a e�ciência e a integridade dos dados em sistemas de banco de dados relacionais.
Prepare-se para aprimorar suas habilidades e fortalecer seu conhecimento.
Ponto de Partida
Esta aula aborda o mapeamento de elementos do diagrama de classes para sistemas
gerenciadores de bancos de dados relacionais (SGBDR), e tem como objetivo explorar a
intersecção entre o desenvolvimento orientado a objetos e o armazenamento de dados em
estruturas relacionais, um desa�o comum na engenharia de software. Ao desenvolver aplicações
que utilizam bancos de dados, frequentemente precisamos traduzir nossos modelos de classes,
tipicamente organizados em um diagrama de classes UML, para tabelas em um banco de dados
relacional. Esse processo é crucial para a persistência de dados de forma e�cientee organizada.
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.
Disciplina
ANÁLISE ORIENTADA A OBJETOS
Durante esta aula, vamos discutir técnicas e estratégias para realizar esse mapeamento de
maneira e�caz. Abordaremos como os conceitos de herança, associação e agregação em um
diagrama de classes podem ser representados em um banco de dados relacional. Com esses
conhecimentos, você estará melhor preparados para projetar e implementar sistemas robustos
que integrem e�cazmente o desenvolvimento orientado a objetos com a persistência relacional.
Considere que você é o projetista de banco de dados, integrante da equipe de desenvolvedores
responsável pelo sistema “Locação de Veículos”, e como parte da documentação referente a
modelagem de dados você precisa apresentar o mapeamento das classes para tabelas do Banco
de Dados Relacional (BDR) correspondente ao modelo de classes a seguir:
Figura 1 
Para especi�cação das tabelas, adote a notação “Nome da Tabela (coluna 1, coluna 2, coluna 3,
coluna 4, coluna n)”, representando, assim, o esquema completo do banco de dados.
Bom trabalho e ótimo estudo!
Vamos Começar!
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
Disciplina
ANÁLISE ORIENTADA A 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 especi�car o mapeamento de classes para tabelas do modelo de dados relacional, é
comum adotar técnicas de modelagem de dados e/ou de�nir 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 de�nido 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 de�niçã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 identi�car 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. Identi�cação de objetos: determine se os objetos das classes são transientes (existem apenas
durante uma sessão) ou persistentes (armazenados �sicamente).
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 re�etir 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.
Disciplina
ANÁLISE ORIENTADA A OBJETOS
Essas regras ajudam a criar um esquema de banco de dados relacional e�ciente 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
identi�cador (Id) para a chave primária. Essa estratégia de notação dos “Ids” de�ne 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
Disciplina
ANÁLISE ORIENTADA A OBJETOS
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 �nal 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.
Disciplina
ANÁLISE ORIENTADA A OBJETOS
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