Arquitetura

Inserir TítulodeAqui
Software
Inserir Título Aqui
Mapeamento Objeto-Relacional e Camada de Persistência

Responsável pelo Conteúdo:

Prof. Me. Wilson Vendramel

Revisão Textual:
Prof. Esp. Claudio Pereira do Nascimento
 Mapeamento Objeto-Relacional
e Camada de Persistência

Nesta unidade, trabalharemos os seguintes tópicos:

• Mapeamento Objeto-Relacional e Camada de Persistência.

Fonte: iStock/Getty Images

Objetivos
• Entender o mapeamento de objetos para o modelo relacional e a construção da camada
de persistência.

Caro Aluno(a)!

Normalmente, com a correria do dia a dia, não nos organizamos e deixamos para o
último momento o acesso ao estudo, o que implicará o não aprofundamento no material
trabalhado ou, ainda, a perda dos prazos para o lançamento das atividades solicitadas.

Assim, organize seus estudos de maneira que entrem na sua rotina. Por exemplo, você
poderá escolher um dia ao longo da semana ou um determinado horário todos ou alguns
dias e determinar como o seu “momento do estudo”.

No material de cada Unidade, há videoaulas e leituras indicadas, assim como sugestões

de materiais complementares, elementos didáticos que ampliarão sua interpretação e
auxiliarão o pleno entendimento dos temas abordados.

Após o contato com o conteúdo proposto, participe dos debates mediados em fóruns de
discussão, pois estes ajudarão a verificar o quanto você absorveu do conteúdo, além de
propiciar o contato com seus colegas e tutores, o que se apresenta como rico espaço de
troca de ideias e aprendizagem.

Bons Estudos!
UNIDADE
Mapeamento Objeto-Relacional e Camada de Persistência

Contextualização
Na maioria dos sistemas de software desenvolvidos que utilizam a tecnologia de orien-
tação a objetos e a tecnologia de banco de dados relacional, uma parte considerável do
tempo de desenvolvimento geralmente é usado com o mapeamento objeto-relacional,
uma tarefa relativamente complexa e propensa a erros. Apesar de serem tecnologias
diferentes, muitos sistemas de software utilizam conceitos de ambas em sua construção.
Em geral, as regras de negócio, interface de usuário e toda a camada de infraestrutura de
software são construídas utilizando tecnologias que contemplam a orientação a objetos
enquanto que os mecanismos de armazenamento físico de dados utilizam um Sistema
Gerenciador de Banco de Dados Relacional (SGBDR). Em sistemas de software dessa
natureza, inclusive aplicações Web, torna-se necessário que objetos de negócio de domínio
persistam entre diferentes seções de uso do sistema, sendo requerido um esforço adicional
para adaptar as estruturas de dados de objetos para estruturas relacionais (tabelas).

Um framework de mapeamento objeto-relacional pode ajudar a reduzir considera-

velmente a complexidade no processo de desenvolvimento de sistemas de software,
diminuindo o tempo gasto na implementação e aumentando a qualidade do software.
De qualquer forma, é preciso entender que a adoção de um framework objeto-relacio-
nal não resolverá todos os problemas causados pelas diferenças existentes entre essas
duas tecnologias.

6
Mapeamento Objeto-Relacional
e Camada de Persistência
Este material teórico apresenta o mapeamento objeto-relacional e a camada de per-
sistência, enfatizando o mapeamento de objetos para o modelo relacional e o padrão de
projeto para persistência de dados Data Access Object (DAO). Para facilitar a compre-
ensão da representação do mapeamento objeto-relacional e da camada de persistência
de dados, serão utilizadas notações da Unified Modeling Language (UML), especifica-
mente os diagramas de classes, de pacotes e de implantação.

Modelo de Objetos Versus Modelo Relacional

As tecnologias que utilizam o paradigma orientado a objetos são comumente adotadas
no desenvolvimento de aplicações de software, em contrapartida a tecnologia de banco
de dados relacional também está bastante presente na maioria dos sistemas de software,
inclusive nos sistemas distribuídos e baseados na Web. Apesar da utilização mútua dessas
tecnologias, cada uma delas tem como fundamentos bem distintos. Enquanto no modelo
de objetos, os elementos correspondem a abstrações de comportamento, no modelo
relacional, os elementos correspondem aos dados no formato de tabela.

Em um sistema de software orientado a objetos, os elementos (objetos) podem ser

transientes ou persistentes. Os objetos transientes só existem em tempo de execução,
isto é, na memória da máquina durante uma sessão de uso do sistema. Os objetos visão
e objetos controladores são exemplos típicos de objetos transientes. Os objetos persis-
tentes existem durante várias execuções do sistema; para tal, esses objetos precisam
ser armazenados quando a sessão de uso termina e recuperados quando outra sessão
é inicializada. Os objetos do tipo modelo são exemplos típicos de objetos persistentes.
(BEZERRA, 2015)

No caso de objetos persistentes, surge o problema de conciliar as informações repre-

sentadas pelo estado de um objeto e pelos dados armazenados na forma de registros em
uma tabela. Esse problema, denominado impedance mismatch, representa um conjun-
to de conceitos e dificuldades técnicas quando um banco de dados relacional é utilizado
por um sistema de software orientado a objetos.

Informações mais técnicas sobre impedance mismatch podem ser encontradas em https://goo.gl/53lSls

Certo, há diferenças entre as representações do modelo de objetos e o modelo rela-

cional. Nesse caso, o que devemos fazer?

Um esforço significativo de desenvolvimento recai sobre a solução que o desenvolve-

dor de software deve dar a esse problema, tentando evitar a falta de consistência entre
as informações quando os objetos vêm do banco de dados para a memória principal ou
vão desta última para o banco de dados.

7
7
UNIDADE
Mapeamento Objeto-Relacional e Camada de Persistência

Projeto de Banco de Dados

Na Unidade 1, foi apresentando um modelo geral do processo de design de sistema
de software. Vamos lembrar rapidamente desse modelo? Eu penso ser importante rever
este modelo antes de darmos sequência na explanação dos conceitos desta unidade.

A figura 1 apresenta um modelo geral do processo de design de sistema de software

(Sommerville, 2011). Observe que cada atividade de projeto resulta em uma saída de proje-
to. O projeto de arquitetura resulta na arquitetura de sistema; o projeto de interface resulta
na especificação de interface; o projeto de componentes resulta na especificação de compo-
nentes e o projeto de banco de dados resulta na especificação de banco de dados. Observe
ainda que o projeto de banco de dados é uma das atividades de projeto (design) e que apre-
senta relações com o projeto de arquitetura e o projeto de componentes, mostrando que
o projeto de banco de dados é influenciado por ambos os projetos. Vale lembrar que todas
essas saídas (especificações) compõem o projeto (design) de arquitetura de software.

Figura 1 – Modelo geral do processo de design

Fonte: Sommerville, 2011 p.26

Outro aspecto importante é comparar brevemente o que cada unidade anterior desta
disciplina abordou em relação ao modelo de processo de design apresentado na figura 1.
Vamos lá!

A Unidade 1, conforme já foi dito, abordou o modelo geral do processo de design de

sistema de software; a Unidade 2 abordou o projeto de arquitetura (padrões de projeto
e padrões de arquitetura); a Unidade 3 refinou a abordagem do projeto de arquitetura
(arquitetura lógica e arquitetura física), o projeto de interface (de classe, subsistema e
componente) e o projeto de componentes. Já a Unidade 4 aborda o projeto de banco
de dados. Desta forma, as quatro atividades de projeto (design) mencionadas na figura 1
são contempladas nesta disciplina.

8
 Quais são as principais atividades realizadas em um projeto (design) de banco de dados?

Inicialmente, você pode pensar na construção do esquema do banco de dados. Você

está certo, porém essa não é a única atividade relacionada. Quando projetamos um
banco de dados, nós pensamos também em outras atividades, como a criação de índi-
ces, a criação de visões, a permissão de direitos de acesso, o procedimento de backup
dos dados. Isso significa que o projeto de um banco de dados vai além da construção
do esquema do banco. Mesmo assim, esta unidade se concentra em criar o esquema do
banco de dados. O diferencial é que o esquema será criado a partir do modelo de obje-
tos, especificamente do modelo de classes.

Para maiores detalhes sobre projeto de banco de dados, você também pode explorar o
livro Banco de dados: projeto e implementação de Machado (2014), disponibilizado na
Biblioteca Virtual Pearson, disponível em: https://goo.gl/g72tci

Mapeamento de Objetos
Ao utilizar tecnologias relacionadas com o paradigma orientado a objetos, principal-
mente uma linguagem de programação orientada a objetos para desenvolver sistemas de
software, e um sistema gerenciador de banco de dados relacional para armazenamento
físico dos dados, é necessário mapear os valores dos atributos de objetos persistentes
para tabelas, por conta das diferenças conceituais e de tecnologia entre o modelo de ob-
jetos e o modelo relacional. É importante ressaltar que o mapeamento objeto-relacional
não é algo exato e rígido, podendo ser adaptado de acordo com o problema em questão.
Não é à toa que esse procedimento de transposição de objetos para tabelas é chamado
de mapeamento.

Como é feito esse mapeamento?

O mapeamento de objetos para o modelo relacional é feito a partir do modelo de classes.

Outra forma bastante comum de criação do esquema do banco de dados é a partir do mape-
amento do Modelo Entidade-Relacionamento (MER), também conhecido como Modelo ER.

A construção do esquema do banco de dados a partir do modelo de classes é seme-

lhante ao mapeamento do modelo ER, mas não idêntico, pois o modelo de classes tem
mais recursos do que o modelo ER. Além disso, o modelo ER é um modelo de dados,
enquanto o modelo de classes representa objetos (dados e comportamento), sendo, por-
tanto, modelos de representação distintos.

Maiores informações sobre o Modelo ER podem ser encontradas em https://goo.gl/oOIpX3

A figura 2 mostra uma visão minimalista do mapeamento de objetos para o modelo

relacional. Apesar dos diversos conceitos existentes em ambos os modelos, a ênfase está
no mapeamento de classes e atributos para tabelas e colunas.

9
9
UNIDADE
Mapeamento Objeto-Relacional e Camada de Persistência

Figura 2 – Visão minimalista do mapeamento de objetos para o modelo relacional

Fonte: Machado, 2014 p.233

Vamos agora mapear os objetos a partir do modelo de classes do projeto de sistema

de software de locadora de carros abordado nas unidades anteriores?

Antes, para facilitar o entendimento, é interessante definir a forma de notação para

representar o procedimento de mapeamento, sendo que não há uma notação universal
para tal. O mapeamento deste material adotou as seguintes notações:
• cada relação (tabela) será representada pelo seu nome em negrito e suas colunas
(campos) entre parênteses;
• a chave primária (primary key – PK) será representada em negrito;
• a chave estrangeira (foreign key – FK) será representada em itálico.

Para manter uma padronização nos objetos mapeados e por ser uma das melhores
maneiras de associar identificadores a objetos mapeados para tabelas, uma coluna de
implementação (id) é utilizada como chave primária de cada tabela, lembrando que essa
coluna id é um identificador sem significado no domínio de negócio.

Para realizar o procedimento de mapeamento dos objetos a partir das classes do

projeto de sistema de software de locadora de carros, vamos utilizar como base o dia-
grama de classes de projeto apresentado na figura 3. Observe que o referido diagrama
de classes apresenta somente classes que representam objetos persistentes, os quais o
mapeamento tem interesse de mapear para tabelas do banco de dados relacional. Ob-
serve também que o escopo de classes foi ampliado, permitindo assim a aplicação de
mais regras de mapeamento envolvendo classes, atributos e relacionamentos.

O procedimento mais simples é mapear cada classe como uma tabela e cada atributo como
uma coluna, mas nem sempre há correspondência unívoca entre classes e tabelas. Quanto
ao atributo, este pode ser mapeado para uma ou mais colunas, vai depender do contexto. ]

10
 Figura 3 – Diagrama de classes de projeto
Fonte: Elaborado pelo autor

As regras de mapeamento aplicadas no diagrama de classes do projeto de sistema

de software de locadora de automóveis foram baseadas nos livros de Bezerra (2015),
Machado (2014) e Waslawick (2015). É importante ressaltar que nem todas as regras
de mapeamento apresentadas pelos referidos livros foram aplicadas nesta unidade, mas
somente as regras necessárias para mapear o diagrama de classes de projeto da figura
3. Também é importante enfatizar que as regras de mapeamento não são rígidas, po-
dendo variar para cada situação. Isso significa que você pode encontrar diferenças no
procedimento de mapeamento.

Vamos iniciar o mapeamento das classes relacionadas por meio de associações com
conectividade um-para-muitos. A figura 4 mostra as classes selecionadas para este
mapeamento. Ao realizar o mapeamento de uma relação com conectividade um-para-
-muitos, é importante verificar qual classe está com o lado muitos (*) do relacionamen-
to. Observe também o atributo idade na classe Cliente com a propriedade derivado
(/). Atributos derivados não são mapeados, pois seus valores são derivados de outros
atributos, havendo serventia somente em tempo de execução (na memória principal);
os valores dos atributos derivados são transientes, não sendo relevantes para persis-
tência de dados.

Figura 4 – Classes relacionadas por meio de associação um-para-muitos

Fonte: Elaborado pelo autor

O resultado do mapeamento do diagrama de classes da figura 4 é apresentado no

quadro 1. Note que cada classe foi mapeada para uma tabela e cada atributo para uma

11
11
UNIDADE
Mapeamento Objeto-Relacional e Camada de Persistência

coluna. A tabela Locação cujas linhas (registros) estão sujeitas de ocorrer diversas vezes
é a que recebe as chaves estrangeiras correspondentes às tabelas Cliente e Carro. O
atributo idade da Classe Cliente não foi mapeado para uma coluna da tabela Cliente por
ser um atributo derivado.

Quadro 1 – Mapeamento das classes relacionadas por meio de associação um-para-muitos

Locacao (idLocacao, dataretirada, horaretirada, datadevolucao, horadevolucao,

valorlocacao, idCliente, idCarro)
Cliente (idCliente, cpf, nome, email, data_nasc)
Carro (idCarro, modelo, chassi, cor, km, valordiaria)
Fonte: Elaborado pelo autor

O próximo mapeamento a ser realizado é o das classes relacionadas por meio de

associações com conectividade muitos-para-muitos com classe associativa, também cha-
mada de classe de associação. A figura 5 mostra as classes selecionadas para este ma-
peamento. Ao realizar o mapeamento de uma relação com conectividade muitos-para-
-muitos com classe associativa, é importante notar que a classe associativa tem atributos
associados às classes Carro e Acessório. Por exemplo, um carro pode ser locado com
duas cadeiras de bebê e que essas cadeiras também podem ser acessórios para outros
carros alugados, sendo necessário saber quantos itens de acessório foram contratados e
o valor para cada um desses itens.

Figura 5 – Classes relacionadas por meio de associação muitos-para-muitos com classe associativa
Fonte: Elaborado pelo autor

O resultado do mapeamento do diagrama de classes da figura 5 é apresentado no

quadro 2. Note que cada classe foi mapeada para uma tabela e cada atributo para uma
coluna. A classe associativa ItemAcessorio também foi mapeada para uma tabela, onde
as colunas idCarro e idAcessorio formam uma chave primária composta e que também
são chaves estrangeiras, fazendo referência às classes Carro e Acessório, respectivamente.

12
 Quadro 2 – Mapeamento das classes relacionadas por meio de
associação muitos-para-muitos com classe associativa

Carro (idCarro, modelo, chassi, cor, km, valordiaria)

Acessorio (idAcessorio, descricao, valor)
ItemAcessorio (idCarro, idAcessorio, qtdeitem, valoritem)
Fonte: Elaborado pelo autor

O próximo mapeamento a ser realizado é o das classes relacionadas por meio de

composição. A figura 6 mostra as classes selecionadas para este mapeamento. Vale
lembrar que o relacionamento de composição representa uma relação todo-parte. O ma-
peamento dos relacionamentos de composição pode ser o mesmo adotado nos relacio-
namentos de associação, inclusive as conectividades. A diferença está na forma de como
o banco de dados deve se comportar quando um registro da tabela correspondente ao
todo deve ser excluído ou atualizado, ou seja, quando um objeto todo é excluído ou atu-
alizado, é natural excluir ou atualizar os objetos parte também.

A forma de como o banco de dados deve se comportar em relação aos registros de tabelas
mapeadas a partir de classes relacionadas por meio de composição pode ser implemen-
tada por meio de recursos do próprio Sistema Gerenciador de Banco de Dados Relacional
(SGBDR), tais como trigger e stored procedure.

Figura 6 – Classes relacionadas por meio de composição

Fonte: Elaborado pelo autor

O resultado do mapeamento do diagrama de classes da figura 6 é apresentado no

quadro 3. Note que cada classe foi mapeada para uma tabela e cada atributo para uma

13
13
UNIDADE
Mapeamento Objeto-Relacional e Camada de Persistência

coluna. Para assegurar a exclusão ou atualização dos registros das tabelas Motor e Roda
quando algum registro da tabela Carro for excluído ou atualizado, a chave primária da
tabela Carro também é chave primária das tabelas Motor e Roda, sendo nestas últimas
também uma chave estrangeira que faz referência à tabela Carro.

Quadro 3 – Mapeamento das classes relacionadas por meio de composição

Carro (idCarro, modelo, chassi, cor, km, valordiaria)

Motor (idCarro, idMotor, torque, potencia, cavalos)
Roda (idCarro, idRoda, modelo, aro)

Fonte: Elaborado pelo autor

O próximo mapeamento a ser realizado é o das classes relacionadas por meio de ge-
neralização. Vale lembrar que o relacionamento de generalização representa uma relação
de generalização/especialização (herança). A figura 7 mostra as classes selecionadas para
este mapeamento. É importante saber que para esse tipo de relacionamento, há mais de
uma alternativa de mapeamento, sendo que cada uma tem suas vantagens e desvantagens.
A escolha de uma ou mais opções depende do sistema de software a ser desenvolvido e da
equipe de desenvolvimento. De acordo com Bezerra (2015), as opções de mapeamento
de generalização são: a) uma relação para cada classe da hierarquia; b) uma relação para
toda a hierarquia; c) uma relação para cada classe concreta da hierarquia.

Figura 7 – Classes relacionadas por meio de generalização

Fonte: Elaborado pelo autor

O resultado do mapeamento do diagrama de classes da figura 7 é apresentado no

quadro 4. Note que a superclasse e cada subclasse foram mapeadas para tabelas distintas
e cada atributo para uma coluna. Para refletir melhor o modelo de objetos, evitar pos-
síveis valores nulos e facilitar a manutenibilidade, foi escolhida a alternativa de mapear

14
cada classe da hierarquia para uma relação, sendo que a chave estrangeira da tabela
Passeio e da tabela Utilitário faz referência à chave primária da tabela Carro. Uma pos-
sível desvantagem desse mapeamento é a perda de desempenho por precisar manipular
os relacionamentos entre as tabelas (joins), mas esse problema tende a acontecer com
heranças profundas, ou seja, hierarquias de generalização e especialização com muitos
níveis, o qual não é o caso do diagrama de classes mostrado na figura 7.

Quadro 4 – Mapeamento das classes relacionadas por meio de generalização

Carro (idCarro, modelo, chassi, cor, km, valordiaria)

Passeio (idCarroP, qtdelugares, idCarro)
Utilitário (idCarroU, capacidadecarga, idCarro)

Fonte: Elaborado pelo autor

Existem ferramentas que automatizam o mapeamento para a criação do banco de dados

relacional a partir do modelo de classes. Mesmo assim, essas ferramentas não resolvem
totalmente o problema do impedance mismatch. Além disso, nem sempre há uma ferra-
menta disponível e mesmo que haja, é importante o desenvolvedor de software ter conhe-
cimento, mesmo que básico, dos procedimentos de mapeamento.

Camada de Persistência
Além da construção do esquema de banco de dados, outros aspectos importantes e
relacionados ao armazenamento de objetos em um banco de dados relacional devem ser
definidos, principalmente a construção de uma camada de persistência.

O propósito de uma camada de persistência é isolar os objetos de negócio de um

sistema de software dos detalhes de comunicação com o banco de dados. Havendo
necessidade de alterações no esquema do banco de dados, os objetos da camada de
negócio permanecem intactos. Se um banco de dados diferente tiver que ser utilizado
pelo sistema de software, apenas a camada de persistência é modificada. Em síntese, a
criação de uma camada de persistência diminui o acoplamento (dependência) entre os
objetos de negócio da aplicação e a estrutura do banco de dados, tornando o sistema de
software mais manutenível e portável (BEZERRA, 2015).

O padrão de projeto Data Access Object (DAO) é uma estratégia para se construir
uma camada de persistência, pois possibilita o desacoplamento dos objetos de negócio
do banco de dados.

Nessa estratégia, um sistema de software orientado a objetos obtém acesso a objetos

de negócio através de uma interface, denominada interface DAO. As classes que imple-
mentam essa interface transformam informações provenientes do mecanismo de arma-
zenamento em objetos de negócio e vice-versa. Nesse caso, o sistema de software se co-
munica com o objeto DAO através de uma interface, sendo que a implementação desse
objeto não faz diferença para a aplicação, já que o objeto DAO isola completamente os

15
15
UNIDADE
Mapeamento Objeto-Relacional e Camada de Persistência

objetos consumidores da aplicação dos mecanismos de armazenamento físico de dados.

(BEZERRA, 2015)

A figura 8 mostra a estrutura do padrão de projeto para persistência de Dados DAO.

Observe alguns aspectos interessantes nessa figura: a RegiãoCliente representa o con-
junto de objetos consumidores que se comunica com o objeto DAO através da interface;
a classe DAO está encapsulada por trás da interface; a classe DAO precisa conhecer a
estrutura da ClasseEntidade para poder restaurar, atualizar ou excluir o objeto modelo
em questão; a fonte de dados está sendo acessada e manipulada por meio da classe
DAO. Em suma, os objetos de negócio da aplicação estão isolados do banco de dados
utilizado pela aplicação, devido à construção de uma camada de persistência de dados.

Figura 8 – Estrutura do padrão DAO

Fonte: Bezerra, 2015 p. 384

Maiores informações sobre o padrão de projeto DAO podem ser encontradas em

https://goo.gl/fLWfR5 e em https://goo.gl/8JWF

Para facilitar a compreensão da representação da camada de persistência de dados, o

diagrama de pacotes da figura 9 exibe um subsistema (pacote) DAO com as classes DAO
alocadas nele. Para cada classe que representa um objeto de negócio (objeto modelo) do
projeto de sistema de software de locadora de carros, foi criada uma classe DAO. Essa
figura representa o subsistema DAO em uma arquitetura lógica.

Figura 9 – Subsistema (Pacote) DAO

Fonte: Elaborado pelo autor

16
 A camada de persistência de dados também pode ser representada no diagrama de
implantação, conforme mostra a figura 10. O componente de persistência é represen-
tado em um nó de processamento referente à camada de dados. Essa figura representa
o subsistema DAO em uma arquitetura física, denominado componente de persistência.
Observe que esse componente representa uma camada intermediária entre o servidor
de aplicação e o banco de dados, isolando os componentes da aplicação onde se en-
contram os objetos de negócio do Sistema Gerenciador de Banco de Dados (SGBDR).

Figura 10 – Diagrama de implantação com alocação do componente de persistência

Fonte: Elaborado pelo autor

Na plataforma Java, há um framework para mapeamento objeto-relacional chamado

Hibernate. Na plataforma Microsoft, esse framework se chama NHibernate. Maiores infor-
mações sobre o framework Hibernate podem ser encontradas em https://goo.gl/aHFndK e
em https://goo.gl/1zbDsG

Este material teórico aplicou algumas regras de mapeamento de objetos para o modelo
relacional. Vale lembrar que nem todas as regras de mapeamento foram aplicadas nesta
unidade, mas somente as regras necessárias para mapear o diagrama de classes do projeto
de sistema de software de locadora de carros. Também é importante enfatizar que as re-
gras de mapeamento não são exatas nem rígidas, podendo variar para cada situação. Isso
significa que você pode se deparar com o procedimento de mapeamento objeto-relacional
realizado de formas diferentes. De qualquer forma, é importante você buscar maiores in-
formações sobre o tema nas referências utilizadas e no material complementar.

Eu encerro esta disciplina por aqui. Muito obrigado pela sua atenção!

17
17
UNIDADE
Mapeamento Objeto-Relacional e Camada de Persistência

Material Complementar
Indicações para saber mais sobre os assuntos abordados nesta Unidade:

Sites
Hibernate
https://goo.gl/1zbDsG
Biblioteca virtual Cruzeiro do Sul
https://goo.gl/g72tci
Oracle
https://goo.gl/8JWF

Leitura
Object-relational impedance mismatch
https://goo.gl/53lSls
Hibernate
https://goo.gl/aHFndK
Objeto de acesso a dados
https://goo.gl/fLWfR5

18
Referências
BEZERRA, E. Princípios de Análise e Projeto de Sistemas com UML. 3. ed. São
Paulo: Elsevier, 2015.

MACHADO, F. N. R. Banco de dados: projeto e implementação. 3. ed. São Paulo:

Érica, 2014.

SOMMERVILLE, I. Engenharia de software. 9. ed. São Paulo: Pearson, 2011.

WASLAWICK, R. S.; Análise e design orientados a objetos para sistemas de

informação: modelagem com UML, OCL e IFML. 3. ed. Rio de Janeiro: Campus
Elsevier, 2015.

19
19