FINAL MonografiaDaibert

0
FACULDADE METODISTA GRANBERY – FMG

CURSO DE BACHARELADO EM SISTEMAS DE INFORMAÇÃO
TRABALHO DE CONCLUSÃO DE CURSO

PERSISTÊNCIA EM SOFTWARE ORIENTADO A OBJETOS:
SOLUÇÕES DE MAPEAMENTO OBJETO-RELACIONAL
MARCELO SANTOS DAIBERT
JUIZ DE FORA
2005
1
MARCELO SANTOS DAIBERT

PERSISTÊNCIA EM SOFTWARE ORIENTADO A OBJETOS:
SOLUÇÕES DE MAPEAMENTO OBJETO-RELACIONAL
Trabalho de Conclusão de Curso

apresentado pelo acadêmico Marcelo
Santos Daibert ao curso de Bacharelado
em Sistemas de Informação da Faculdade
Metodista Granbery, como requisito para
obtenção do título de Bacharel em
Sistemas de Informação.
ORIENTADOR:
Prof. Marco Antônio Pereira Araújo, M.Sc.
CO-ORIENTADORA:
Profa. Alessandreia Marta de Oliveira
Julio, M.Sc.
JUIZ DE FORA
2005
2
AGRADECIMENTOS
Agradeço inicialmente aos meus pais, Ricardo e Helene, que buscam me

proporcionar o que há de melhor nessa vida. Que me instruíram, me prepararam e
que me ensinaram a lutar pela vida e pelos meus ideais.
À minha esposa Patrícia que com sua dedicação e amor me deu forças
para vencer o meu dia a dia e enfrentar todos os obstáculos da vida.
Ao meu filho Yago, que com o seu sorriso me estimulou nos momentos de
desânimo, quando somente o choro tomava minha vida.
Aos meus orientadores Marco Antônio e Alessandreia que, com paciência,
carinho, dedicação e competência me fizeram entender que a vida é feita de
desafios, e estes desafios foram feitos para serem vencidos. Mostraram-me que
somente com muito trabalho e dedicação conseguimos chegar aos nossos objetivos.
Aos meus familiares, que sempre estiveram ao meu lado, não me fazendo
desistir da minha caminhada.
Aos participantes do projeto de iniciação científica a qual este trabalho
está vinculado. Em especial aos amigos Renato, Leandro, Valdete, João.
Aos amigos e colegas que estimulavam a caminhada.
E, por fim, aos demais professores da Faculdade Metodista Granbery pelo
incentivo e pela dedicação à atividade docente.
3
“Primeiro faça o necessário;

Depois faça o possível;
e, de repente, você vai perceber
que pode fazer o impossível”
São Francisco de Assis
4
FACULDADE METODISTA GRANBERY – FMG

CURSO DE BACHARELADO EM SISTEMAS DE INFORMAÇÃO

FOLHA DE APROVAÇÃO
Após a exposição do discente Marcelo Santos Daibert, matrícula

2002102013, sobre a realização do Trabalho de Conclusão de Curso, a Banca
Examinadora, composta pelos professores abaixo identificados, reuniu-se e aprovou
o presente relatório monográfico que, por atender aos requisitos estabelecidos,
recebeu a nota 87 (oitenta e sete), como sendo a média da Banca.
Juiz de Fora, 07 de Dezembro de 2005
Professor Marco Antônio Pereira Araújo – Orientador
Professora Alessandreia Marta de Oliveira Julio – Co-Orientadora
Professora Melise Maria Veiga de Paula – Examinadora
Juiz de Fora
2005
5
LISTA DE FIGURAS
Figura 2.1 – Mapeamento Objeto-Relacional ...........................................................16

Figura 2.2 – Estratégias de Mapeamento para Herança..........................................19
Figura 2.3 – Mapeamento de Associação do Tipo 1:1 .............................................20
Figura 2.4 – Mapeamento de Associação do Tipo 1:n .............................................21
Figura 2.5 – Mapeamento de Associação do Tipo n:n .............................................21
Figura 3.1 – Camada SQL........................................................................................22
Figura 3.2 – Camada de Classes para Dados a Dados ...........................................23
Figura 3.3 – Camada de Persistência ......................................................................24
Figura 4.1 – Componentes DePO ............................................................................29
Figura 4.2 – Configurando Componente DePO........................................................29
Figura 4.3 – Model Explorer .....................................................................................36
Figura 4.4 – Componentes Instant Objects ..............................................................37
Figura 4.5 – Adicionando Nova Classe ....................................................................38
Figura 4.6 – Criação das Tabelas em Base de Dados Relacional ...........................40
Figura 4.7 – Criação do Atributo de Relacionamento para uma Referência ............41
Figura 4.8 – Criação do Atributo de Relacionamento para Várias Referências .......42
Figura 4.9 – Configuração do Componente InstantSelector.....................................42
Figura 4.10 – Componentes TiOPF..........................................................................46
Figura 5.1 – Modelo MVC.........................................................................................55
Figura 5.2 – Diagrama de Caso de Uso ...................................................................56
Figura 5.3 – Diagrama de Classes ...........................................................................57
Figura 5.4 – Interação da Classe Controle - Gerente...............................................58
Figura 5.5 – Interface de Pesquisa de Curso ...........................................................65
Figura 5.6 – Diagrama de Sequência da Operação Pesquisa .................................66
Figura 5.7 – Diagrama de Sequência da Operação Incluir Curso ............................68
Figura 5.8 – Interface de Incluir Curso .....................................................................69
Figura 5.9 – Diagrama de Sequência da Operação Atualizar Curso........................71
Figura 5.10 – Interface de Atualizar Curso...............................................................72
Figura 5.11 – Diagrama de Sequência da Operação Excluir Curso .........................74
6
Figura 5.12 – Interface de Excluir Curso ..................................................................75

Figura 5.13 – Diagrama de Sequência da Operação Consultar Curso ....................76
Figura 5.14 – Interface de Consultar Curso .............................................................77
7
LISTA DE TABELAS
Tabela 4.1 – Principais Propriedades e Métodos do DePO .....................................30

Tabela 4.2 – Comparativo Entre os frameworks ......................................................52
8
LISTA DE LISTAGENS DE CÓDIGO FONTE
Listagem 4.1 – Definição das Classes .....................................................................30

Listagem 4.2 – Mapeamento das Classes ...............................................................32
Listagem 4.3 – Instanciação e Persistência de um Objeto.......................................34
Listagem 4.4 – Recuperação de um Objeto .............................................................34
Listagem 4.5 – Atualização de um Objeto ................................................................35
Listagem 4.6 – Exclusão de um Objeto....................................................................35
Listagem 4.7 – Definição das Classes .....................................................................39
Listagem 4.8 – Instanciação e Persistência de um Objeto.......................................44
Listagem 4.9 – Recuperação de um Objeto .............................................................44
Listagem 4.10 – Atualização de um Objeto ..............................................................44
Listagem 4.11 – Exclusão de um Objeto..................................................................44
Listagem 4.12 – Configurando o Acesso à Base de Dados .....................................47
Listagem 4.13 – Criando Tabela ..............................................................................47
Listagem 4.14 – Verifica Existência da Tabela.........................................................47
Listagem 4.15 – Exclusão da Tabela .......................................................................47
Listagem 4.16 – Definição das Classes ...................................................................48
Listagem 4.17 – Definição de Relacionamento ........................................................48
Listagem 4.18 – Definição da Classe de Lista de Objetos .......................................49
Listagem 4.19 – Mapeamento Objeto-Relacional.....................................................50
Listagem 5.1 – Definição das Classes Curso e Professor........................................62
Listagem 5.2 – Mapeamento Objeto-Relacional do Curso e Professor....................63
Listagem 5.3 – Método ObterCursos........................................................................66
Listagem 5.4 – Método RecuperarObjetos...............................................................67
Listagem 5.5 – Método Criar ....................................................................................70
Listagem 5.6 – Método Gravar Campos - Persistir...................................................70
Listagem 5.7 – Método Persistir ...............................................................................70
Listagem 5.8 – Método Obter ...................................................................................72
Listagem 5.9 – Método RecuperaObjeto..................................................................72
Listagem 5.10 – Método LerCampos .......................................................................73
9
Listagem 5.11 – Método Gravar Campos - Atualizar................................................73

Listagem 5.12 – Método Excluir - Gerente ...............................................................75
Listagem 5.13 – Método Excluir – Classe Curso......................................................75
10
SUMÁRIO
1 INTRODUÇÃO ...................................................................................14
2 MAPEAMENTO OBJETO-RELACIONAL .........................................16

2.1 Introdução.........................................................................................................16
2.2 OID (Object Identificator) .................................................................................16
2.3 Mapeamento .....................................................................................................18
2.3.1 Mapeando Atributos.................................................................................18
2.3.2 Mapeando Classes ...................................................................................18
2.3.3 Mapeando Herança...................................................................................18
2.3.4 Mapeando Relacionamentos ...................................................................19
2.3.4.1 Diferença Entre Associação e Agregação/Composição ...............20
2.3.4.2 Associação do Tipo 1:1 ...................................................................20
2.3.4.3 Associação do Tipo 1:n ...................................................................20
2.3.4.4 Associação do Tipo n:n ...................................................................21
2.4 Conclusão .........................................................................................................21
3 CAMADA DE PERSISTÊNCIA ..........................................................22

3.1 Introdução.........................................................................................................22
3.2 Estratégias de Persistência.............................................................................22
3.2.1 Camada SQL .............................................................................................22
3.2.2 Camada de Classes para Acesso a Dados.............................................23
3.2.3 Camada de Persistência ..........................................................................23
3.2.3.1 Requisitos de uma Camada de Persistência...................................24
3.3 Programação em Camadas Utilizando Camada de Persistência .................26
3.4 Conclusão .........................................................................................................26
4 FRAMEWORKS DE PERSISTÊNCIA................................................28
4.1 Delphi Persistent Objects ................................................................................28
11
4.1.1 Componentes DePO.................................................................................28

4.1.2 Classes e Propriedades ...........................................................................29
4.1.3 Relacionamentos......................................................................................31
4.1.4 Mapeamento Objeto-Relacional ..............................................................32
4.1.5 Manipulação de Objetos ..........................................................................34
4.1.6 Considerações Finais ..............................................................................35
4.2 Instant Objects .................................................................................................36
4.2.1 Componentes Instant Objects.................................................................37
4.3 TechInside Object Persistent Framework ......................................................45
4.3.1 Componentes TiOPF ................................................................................46
4.4 Conclusão .........................................................................................................51
5 ESTUDO DE CASO ...........................................................................53

5.1 Introdução.........................................................................................................53
5.2 Projeto de Inciação Científica .........................................................................53
5.3 Sistema de Controle Acadêmico.....................................................................54
5.4 Implementação .................................................................................................55
5.4.1 Introdução.................................................................................................55
5.4.2 Operação Pesquisa de Curso..................................................................65
5.4.3 Operação Incluir Curso............................................................................67
5.4.4 Operação Atualizar Curso .......................................................................70
5.4.5 Operação Excluir Curso...........................................................................74
12
5.4.6 Operação Consultar Curso......................................................................76

5.5 Conclusão .........................................................................................................77
6 CONSIDERAÇÕES FINAIS ...............................................................78
ANEXO A – DOCUMENTAÇÃO SISTEMA ACADÊMICO ...................80
REFERÊNCIAS BIBLIOGRÁFICAS ...................................................115
BIBLIOGRAFIA...................................................................................117
13
RESUMO
O paradigma orientado a objetos cada vez mais vem se destacando e vem

sendo amplamente utilizado no desenvolvimento de aplicações, trazendo diversos
benefícios tanto para a equipe de desenvolvimento quanto para a qualidade do software.
Entretanto, os desenvolvedores enfrentam problemas quando necessitam persistir objetos,
uma vez que os bancos de dados puramente orientados a objetos não são maduros o
suficiente e com desempenho inferior aos bancos relacionais. Neste contexto, uma das
estratégias de persistência de objetos muito utilizada pelos desenvolvedores é o
mapeamento objeto-relacional para a persistência em sistemas gerenciadores de bancos de
dados relacionais (SGBDR). Todavia, a estrutura dos bancos de dados relacionais difere
substancialmente dos mecanismos de persistência da orientação a objetos, o que gerará um
maior esforço do desenvolvedor. Este trabalho tem como objetivo conceituar e discutir as
estratégias de mapeamento objeto-relacional e camadas de persistência, além de
exemplificar o uso de alguns frameworks que se propõem a realizar o papel de camada de
persistência entre o banco de dados relacional e a aplicação orientada a objetos. São
avaliados frameworks de código fonte livre (opensource) para o ambiente de
desenvolvimento Delphi e ao final é apresentado um estudo de caso abordando o que foi
conceituado no trabalho.
Palavras Chave: Banco de Dados Relacional, Camada de Persistência, Mapeamento

Objeto Relacional, Orientação a Objeto, Frameworks de Persistência.
14
1 INTRODUÇÃO
Com o avanço e fundamentação das técnicas do paradigma orientado a objetos,
cada vez mais empresas e desenvolvedores desenvolvem suas aplicações com esta
metodologia, buscando alcançar todos os benefícios difundidos pela orientação a objetos,
como reutilização de código, processo bem definido de desenvolvimento, documentação,
manutenabilidade, entre outros.
Entretanto, as empresas e desenvolvedores passam dificuldades quando têm
que optar pela estratégia de armazenamento de dados, uma vez que os sistemas
gerenciadores de banco de dados orientadas a objetos não são maduros o suficiente
quando comparados aos sistemas gerenciadores de banco de dados relacionais.
O modelo relacional esta muito bem fundamentado e ainda é o padrão para o
armazenamento de informações, sendo o modelo mais utilizado pela Engenharia de
Software e encontrado nos principais bancos de dados das empresas, inclusive muito
abordado no meio acadêmico. O modelo é baseado na relação entre linhas (tuplas) e
colunas (atributos), o que gera um problema no desenvolvimento orientado a objetos, uma
vez que estes podem possuir estruturas complexas, diferente das utilizadas no modelo
relacional (integer, date, varchar, dentre outras).
É necessário então um esforço maior de programação para adequar os objetos
ao modelo relacional, a isso é dado o nome de mapeamento objeto-relacional. Uma das
soluções para este problema é a utilização de uma camada de persistência entre a
aplicação e o banco de dados, um framework. Esta camada é responsável pelo controle e
manipulação dos objetos, além de servir de comunicação entre o banco de dados e a
aplicação.
A persistência de objetos se faz necessária quando é preciso guardar as
informações dos atributos dos objetos em um banco de dados, ou em outra estratégia de
armazenamento, para que se possa recuperá-lo posteriormente. No escopo deste trabalho é
analisada somente a persistência de objetos em banco de dados relacional (SGBDR).
Este trabalho tem então como objetivo conceituar mapeamento objeto-relacional,
exemplificando as principais técnicas existentes. Apresentar os conceitos e estratégias de
camadas de persistência, além de definir e exemplificar o uso de frameworks de persistência
objeto-relacional opensource disponíveis para o ambiente de desenvolvimento Delphi.
No segundo capítulo são apresentados os conceitos e estratégias de
mapeamento objeto-relacional. É definido como mapear as classes e relacionamentos do
modelo orientado a objetos para o as tabelas e atributos do modelo relacional. No terceiro
capítulo são definidos os conceitos de camadas de persistência e suas estratégias (camada
15
SQL, camada de acesso aos dados e camada de persistência). São apresentados os

requisitos de uma camada de persistência e como ela deve se portar dentro de uma
aplicação.
O capítulo quatro descreve três frameworks de persistência objeto-relacional de
código livre aberto (opensource) para o ambiente de desenvolvimento Delphi, alem de seus
conceitos e aplicações.
No quinto capítulo é desenvolvido um estudo de caso utilizando todos os
conceitos dos primeiros capítulos. Este estudo de caso foi projetado e desenvolvido
utilizando as teorias propostas pela Engenharia de Software, utilizando formalmente todas
as metodologias de desenvolvimento. O projeto conta com documentação, seguindo a UML
(especificação de requisitos, diagramas de classe, diagramas de estudo de caso,
especificação de caso de uso e diagramas de seqüência). Foi utilizado um sistema de
versionamento para desenvolvimento, além da utilização de um sistema de rastreio de
defeitos - bugs (bugtracking). Para o versionamento foi utilizado o sistema SVN (Subversion)
(SUBVERSION, 2005) e para o rastreio de bugs foi utilizado o NSN Project (NSN, 2005).
Por fim, no sexto capítulo, são apresentadas as considerações finais e
sugestões para trabalhos futuros.
16
2 MAPEAMENTO OBJETO-RELACIONAL
2.1 Introdução
Um dos principais passos para se persistir um objeto em um banco de dados
relacional é o mapeamento. Neste passo são definidas quais as classes do domínio viram
tabelas e quais atributos da classe viram campos no modelo relacional, além de ser feito o
mapeamento dos relacionamentos entre as classes.
É importante destacar a escolha o OID (Object Identification), que será a chave
primária no modelo relacional. Uma definição formal, bem como as estratégias de escolha
de OIDs são apresentadas no item 2.2.
Como mostrado na Figura 2.1, para se mapear um modelo orientado a objetos
para o modelo relacional, basicamente deve-se (AMBLER, 2000):
mapear classes para tabelas;
mapear atributos para colunas;
mapear os relacionamentos: um-para-um, um-para-muitos, muitos-para-
muitos, agregação, composição e herança.
Tabelas
Classes
Figura 2.1. Mapeamento Objeto-Relacional.
2.2 OID (Object Identification)

Todo objeto possui um OID que estabelece sua identidade. Esse OID é único
para cada instância e não é compartilhado para nenhuma outra, sendo exclusivo. O OID de
um objeto é gerado em tempo de execução da aplicação assim que o objeto é instanciado.
Entretanto esse OID gerado em tempo de execução não é acessível para a aplicação, ele se
resume a um endereço de memória, o que o torna inadequado para identificador de objetos
no mapeamento objeto-relacional.
Deve-se então configurar um OID manualmente dentro da classe, para que esse
seja o campo chave primária no modelo relacional. Esse atributo identificador deve ser único
17
e exclusivo, para que não ocorra redundância no banco de dados relacional. Existem alguns
detalhes que requerem atenção antes da escolha (AMBLER, 2000):
não se deve utilizar atributos da modelagem de negócios para OID’s: Ao
utilizar esses atributos a mudança de alguma regra de negócio ou até mesmo
o modelo, pode causar problemas na manutenção dos dados já existentes no
banco. Lembrando que as chaves primárias têm grandes chances de ser
chaves estrangeiras em outras tabelas, aumentando assim o problema, como
informações relativas ao CPF e CNPJ;
um OID deve ser único para toda a hierarquia de classes: É muito comum
utilizar um campo de auto incremento para ser utilizado como chave primária
em um banco de dados relacional, mas em um modelo orientado a objetos,
onde existe toda uma hierarquia entre classes e relacionamento entre elas,
existe uma facilidade de existir duplicidade de chave primária no banco,
gerando problemas de inconsistência de dados. Um OID deve ser único e
exclusivo para todos os objetos, consequentemente único também no modelo
relacional.
Dentre as estratégias para a escolha de um OID, destaca-se (AMBLER, 2000):
manter uma tabela com valores de OID’s: Esta estratégia consiste em criar
uma tabela onde são armazenados os OID’s. Antes de persistir qualquer
objeto, a aplicação acessa o banco e executa a função MAX() na tabela de
OID’s, buscando assim o maior valor de OID inserido. Após, soma-se mais
um a este valor obtido, persiste-se o objeto na sua tabela determinada pelo
mapeamento e insere o OID do objeto na tabela de OID’s. Esta estratégia
causa depreciação na desempenho da aplicação, uma vez que é necessário
mais um acesso ao banco para realizar a operação;
GUIDs/UUIDs: Estratégia que gera uma string de 128bits que é calculada em
tempo de execução com base no hashing dos valores do endereço físico da
placa de rede e no dia e hora atual do computador. Esta estratégia garante
um OID único para todos os objetos;
recurso de alguns SGBDs para geração de valores únicos: Alguns SGBDs,
como o ORACLE, possuem recursos de geração de valores únicos que
podem ser utilizados como OID. A desvantagem desta estratégia é que
ocorrerá uma dependência do banco de dados.
18
2.3 Mapeamento
Existem algumas estratégias para o mapeamento objeto-relacional que buscam
minimizar os esforços de organização dos dados no banco de dados relacional. Estas
estratégias tratam não somente dos atributos e classes, mas também como estes podem se
relacionar com as tabelas no modelo relacional.
2.3.1 Mapeando Atributos

Inicialmente, os atributos das classes são mapeados para colunas no modelo
relacional. Um atributo pode ser mapeado para zero ou mais colunas, de acordo com a
necessidade (AMBLER, 2000).
Quando um atributo é um tipo simples (integer, date, string, boolean, etc.) ele é
mapeado para uma coluna. Já se ele for de um tipo complexo deve ser mapeado em
quantas colunas forem necessárias, e dependendo do caso pode até ser mapeado em outra
classe. Quando este último ocorrer é importante observar a criação de uma coluna para
manter o relacionamento entre a tabela original e a tabela criada ao se mapear o tipo
complexo, ou seja, é criado um campo com o conceito de chave estrangeira.
2.3.2 Mapeando Classes

Classes são mapeadas para tabelas, mas não diretamente. Existem diferentes
estratégias para este mapeamento, que se configuram de acordo com certos fatores
(AMBLER, 2000), como:
mapeamento de herança;
mapeamento de associação do tipo 1:1;
mapeamento de associação do tipo 1:n;
mapeamento de associação do tipo n:n;
mapeamento de composição;
mapeamento de agregação.
2.3.3 Mapeando Herança

Para efetuar o mapeamento de herança se faz necessário o uso de OID’s únicos
e exclusivos para não causar inconsistência nos dados. Existem fundamentalmente três
estratégias para mapear herança em um banco de dados relacional, como mostra a Figura
2.2 (AMBLER, 2000):
19
Uma tabela por Uma Tabela por Uma Tabela por

hierarquia Classe Concreta Classe
Figura 2.2. Estratégias de Mapeamento para Herança.
uma tabela por hierarquia: Mapear toda a hierarquia de classes para uma
tabela, onde todos os atributos das classes da hierarquia serão armazenados
nesta única tabela. A desvantagem desta estratégia é que toda vez que um
objeto da hierarquia for persistido no banco, é necessário persistir também os
valores da classe irmã vazios, causando uma grande quantidade de campos
vazios. Entretanto o acesso ao banco para a manipulação dos dados é mais
rápido, uma vez que todos os dados estão em somente uma tabela. É
adicionada uma coluna na tabela que referencia qual o tipo de objeto, ou seja,
de qual classe aqueles dados pertencem;
uma tabela por classe concreta: Cada classe concreta mapeada vira uma
tabela com todos os atributos herdados das super classes abstratas. A
vantagem desta estratégia é a facilidade de manipulação de dados, uma vez
que todos os dados de cada classe estão em apenas uma única tabela. Como
desvantagem, destaca-se: Quando se modifica uma classe abstrata, é
necessário modificar todas as tabelas geradas pelas classes filhas no modelo
relacional;
uma tabela por classe: Cada classe é mapeada para uma tabela, onde a
chave primária da classe abstrata é a chave primária da classe concreta.
2.3.4 Mapeando Relacionamentos

Um relacionamento ocorre quando um objeto refere-se a outro objeto. Para se
persistir este objeto, é importante que esta referência possa ser persistida também, para que
se mantenha a consistência dos dados e os relacionamentos em uma posterior manipulação
do objeto (SATZINGER e ORVIK, 1996).
20
Para que isso ocorra é necessário que o relacionamento seja também mapeado,
para que a aplicação ao manipular o objeto já persistido possa saber suas referências ou a
quem o referencia.
2.3.4.1 Diferença Entre Associação e Agregação/Composição

Ao manipular um objeto que referencia uma classe agregada ou composta é
natural que ocorra a visualização de todos os dados da classe agregada ou composta do
objeto referenciado. O que não acontece em uma associação. Essa é a diferença básica do
ponto de vista do banco de dados relacional entre associação e agregação/composição
(AMBLER, 2000).
Ou seja, toda vez que recuperar um objeto do banco que tenha uma agregação
ou composição deve-se recuperar também os objetos da classe agregada ou composta
referenciada. Raciocínio análogo vale para a exclusão.
2.3.4.2 Associação do Tipo 1:1

A associação do tipo 1:1 entre classes é mapeado colocando o atributo
identificador da classe referenciada na classe que o referencia, criando então o conceito de
uma chave estrangeira no modelo relacional, como demonstrado na Figura 2.3 (AMBLER,
2000).
Figura 2.3. Mapeamento de Associação do Tipo 1:1
2.3.4.3 Associação do Tipo 1:n

Da mesma forma que a associação do tipo 1:1, o relacionamento 1:n também é
mapeado colocando o atributo identificador da classe referenciada na classe que o
referencia, criando então o conceito de uma chave estrangeira no modelo relacional, como
demonstrado na Figura 2.4 (AMBLER, 2000).
21
Figura 2.4. Mapeamento de Associação do Tipo 1:n
2.3.4.4 Associação do Tipo n:n

Para mapear uma associação do tipo n:n, é necessário utilizar o conceito de
tabela associativa, cujo único propósito é manter o relacionamento entre duas ou mais
tabelas do modelo relacional (AMBLER, 2000).
Cria-se então uma tabela associativa com os OID’s das classes que se
referenciam, garantindo então a navegabilidade do relacionamento, como exemplificado na
Figura 2.5.
Figura 2.5. Mapeamento de Associação do Tipo n:n
2.4 Conclusão
Este capítulo teve como objetivo apresentar, conceituar e exemplificar as
estratégias existentes atualmente para mapeamento objeto-relacional.
As estratégias de mapeamento objeto-relacional mostram-se interessantes para
efetivamente utilizar os sistemas gerenciadores de banco de dados relacional (SGBDR) na
persistência de objetos, uma vez que as estratégias de armazenamento puramente
orientadas a objetos não estão maduras o suficiente.
Com isso, unem-se a maturidade e rapidez dos bancos de dados relacionais,
com os benefícios da orientação a objetos.
22
3 CAMADA DE PERSISTÊNCIA
3.1 Introdução
Camada de persistência refere-se a uma estrutura responsável por manipular
objetos em alguma forma de armazenamento, ou seja, faz com que uma informação
solicitada uma vez, esteja disponível outras vezes na aplicação, ou até mesmo para outra
aplicação.
Deve prover os serviços de criar, recuperar, atualizar e excluir um objeto (CRUD
– Create, Retrieve, Update e Delete) (AMBLER, 2000). Estes serviços são os responsáveis
por manter a persistência e manipulação de objetos dentro da aplicação.
Existem 3 estratégias de camadas de persistência responsáveis por persistir
objetos no banco de dados relacional (AMBLER, 2000):
camada SQL;
camada de classes para acesso aos dados;
camada de persistência.
3.2 Estratégias de Persistência
3.2.1 Camada SQL

Tipo de persistência de objetos muito comum, mas pouco portável, onde em
cada classe de domínio existem métodos com código SQL embutido que são responsáveis
por persistir os atributos dos objetos na base de dados relacional. A Figura 3.1 ilustra o
acesso direto das classes de domínio ao banco de dados relacional (AMBLER, 2000).
SQL
SGBDR
Classes de Domínio
Figura 3.1. Camada SQL
Este tipo proporciona uma rapidez na codificação das classes e do sistema, mas
em contra partida não as deixa reutilizáveis nem portáveis.
23
Não é utilizado um esquema pré-definido de mapeamento objeto-relacional, o

próprio SQL embutido na classe se responsabiliza por definir o mapeamento, o que torna o
código não reutilizável.
3.2.2 Camada de Classes para Acesso a Dados

Semelhante ao tipo Camada SQL, mas com a diferença que os códigos SQL são
embutidos em novas classes, denominadas classes para acesso aos dados. As classes de
domínio se relacionam com estas classes de dados para que possam ser acionados
métodos para a manipulação dos dados no banco de dados relacional. A Figura 3.2 faz
referência à utilização das classes para acesso a dados pelas classes de domínio
(AMBLER, 2000).
SQL
SGBDR
Classes de
Classes de Domínio Acesso a Dados
Figura 3.2. Camada de Classes para Acesso a Dados
Assim como na camada SQL, também não é utilizada nenhuma estrutura

de mapeamento objeto-relacional. A mesma é de responsabilidade das classes de
acesso a dados.
3.2.3 Camada de Persistência

É uma estrutura agregada à aplicação responsável por toda a manipulação dos
objetos, conexão ao banco e mapeamento das classes. A camada se utiliza de uma
estratégia de mapeamento objeto-relacional para que, de forma genérica em uma única
estrutura, possa manipular os objetos, como a Figura 3.3 evidencia.
Umas das estruturas de veiculação mais utilizadas e difundidas para o
mapeamento objeto-relacional é o arquivo XML (Extensible Markup Language) (XML, 2005).
Dentro do arquivo XML é definido todo o mapeamento do modelo de acordo com a estrutura
XML já definida pela camada de persistência, ficando assim todo o mapeamento fora da
codificação da aplicação.
24
Uma outra forma, também muito utilizada, é adicionar o mapeamento na

codificação da aplicação.
SQL
Camada
de SGBDR
Persistência
Classes de Domínio
Figura 3.3. Camada de Persistência
A camada de persistência é responsável por gerar todos os códigos SQL

necessários para persistir, recuperar, alterar e excluir objetos em um banco de dados
relacional. Todas essas operações se passam de forma transparente ao programador, que
somente acessa métodos da camada para que as operações possam ocorrer (AMBLER,
2000).
Existem dois tipos de camada de persistência: as intrusivas e não intrusivas. As
intrusivas são aquelas que exigem que as classes persistentes de domínio herdem da
classe responsável pela persistência e manutenção de objetos da camada de persistência,
para que, dessa forma, os objetos instanciados possam por herança herdar os métodos de
persistência e manutenção de objetos na base de dados.
As não intrusivas são as que não necessitam que as classes de domínio tenham
nenhum relacionamento com nenhuma classe da camada de persistência, bastando
somente invocar um método da camada, passando por referência o objeto a ser persistido
ou manipulado.
3.2.3.1 Requisitos de Uma Camada de Persistência

Abaixo, características desejáveis que devem ser implementadas em uma
Camada de Persistência (AMBLER, 2000):
suporte a diversos tipos de mecanismos de persistência: um mecanismo de
persistência pode ser definido como a estrutura que armazena os dados –
seja ela um SGBD relacional, um arquivo XML ou um SGBD OO, por
exemplo. Uma Camada de Persistência deve suportar a substituição deste
mecanismo e permitir a gravação do estado de objetos em qualquer um
destes meios;
25
encapsulamento completo da camada de dados: o usuário do sistema de

persistência de dados deve utilizar-se, no máximo, de mensagens de alto
nível como save ou delete para lidar com a persistência dos objetos, deixando
o tratamento destas mensagens para a camada de persistência em si;
ações com multi-objetos: deve ser capaz de salvar e retornar lista de objetos
da base de dados, tendo em vista a freqüência desta situação, como em
relacionamentos do tipo muitos (1:n e n:n);
transações: ao utilizar-se da Camada de Persistência, o programador deve
ser capaz de controlar o fluxo da transação – ou ter garantias sobre o mesmo,
caso a própria Camada de Persistência preste este controle;
extensibilidade: a camada de persistência deve permitir a adição de novas
classes ao esquema e a modificação do mecanismo de persistência;
identificadores de objetos: a implementação de algoritmos de geração de
chaves de identificação garante que a aplicação trabalhará com objetos com
identidade única e sincronizada entre o banco de dados e a aplicação;
cursores e proxies: as implementações de serviços de persistência devem
saber que, em muitos casos, os objetos armazenados são muito grandes e
recuperá-los por completo a cada consulta não é uma boa idéia. Técnicas
como o lazy loading (carregamento tardio) utilizam-se dos proxies para
garantir que atributos só serão carregados à medida que forem importantes
para o usuário.
registros: apesar da idéia de lidar somente com objetos, as camadas de
persistência devem, em geral, dispor de um mecanismo de recuperação de
registros - conjuntos de colunas são encapsuladas na forma de objetos, como
resultado de suas consultas. Isto permite integrar as camadas de
persistências a mecanismos de geração de relatórios que não trabalham com
objetos, por exemplo, além de permitir a recuperação de atributos de diversos
objetos relacionados com uma só consulta;
múltiplas arquiteturas: o suporte a ambientes de programas stand-alone,
cenários onde o banco de dados encontra-se em um servidor central e
mesmo arquiteturas mais complexas (em várias camadas) deve ser inerente à
Camada de Persistência, já que a mesma deve visar a reusabilidade e fácil
adaptação a arquiteturas distintas;
diversas versões de banco de dados e fabricantes: a Camada de Persistência
deve reconhecer diferenças de recursos, sintaxe e outras minúcias existentes
26
no acesso aos bancos de dados suportados, isolando isto do usuário do

mecanismo e garantindo portabilidade entre plataformas;
múltiplas conexões: um gerenciamento de conexões (usualmente utilizando-
se de pooling) é uma técnica que garante que vários usuários utilizarão o
sistema simultaneamente sem quedas de desempenho;
consultas SQL: apesar do poder trazido pela abstração em objetos, este
mecanismo não é funcional em todos os casos. Para os casos extremos, a
Camada de Persistência deve prover um mecanismo de consultas que
permita o acesso direto aos dados – ou então algum tipo de linguagem de
consulta simular à SQL, de forma a permitir consultas com um grau de
complexidade maior que o comum;
controle de concorrência: acesso concorrente a dados pode levar a
inconsistências. Para prever e evitar problemas decorrentes do acesso
simultâneo, a Camada de Persistência deve prover algum tipo de mecanismo
de controle de acesso. Este controle geralmente é feito utilizando-se dois
níveis – com o travamento pessimístico (pessimistic locking), as linhas no
banco de dados relativas ao objeto acessado por um usuário são travadas e
tornam-se inacessíveis a outros usuários até o mesmo liberar o objeto. No
mecanismo otimístico (optimistic locking), toda a edição é feita em memória,
permitindo que outros usuários venham a modificar o objeto.
3.3 Programação em Camadas Utilizando Camada de Persistência

A camada de persistência é apenas mais uma a se relacionar com a camada de
negócio e domínio. As classes de domínio e negócio acessam os métodos da camada de
persistência para poder persistir suas instâncias (AMBLER, 2000).
Existem as classes de interface, que são responsáveis pela interação com o
usuário. Estas trocam mensagens com as classes de domínio/negócio e com as classes de
controle, que por sua vez trocam mensagens com as classes da camada de persistência, ou
seja, a camada de persistência é somente mais uma camada da aplicação.
3.4 Conclusão
Este capítulo mostrou as estratégias de persistência de objetos a nível de
sistema, além de definir formalmente camada de persistência, que é uma camada
27
responsável pela persistência e manipulação de objetos de forma transparente ao

programador.
A essência das camadas de persistência é auxiliar de forma transparente o
programador na tarefa de tornar persistente os objetos da aplicação. Para isso foram
mostradas também características desejáveis das camadas de persistência para que
eficazmente e eficientemente possam realizar esta função.
Foram apresentadas três estratégias de camadas de persistência. A primeira, a
camada SQL, que adiciona métodos responsáveis por persistir os objetos através de código
SQL nas classes de domínio. A segunda, a camada para acesso aos dados, que cria
classes especificamente para se relacionar com os classes de domínio que são
responsáveis pela persistência das instancias das classes do domínio. E por fim, foram
apresentadas as robustas camadas de persistência, que são frameworks, que de forma
genérica se responsabilizam pela persistência dos objetos das classes de domínio.
28
4 FRAMEWORKS DE PERSISTÊNCIA
Um framework de Persistência é um conjunto de ferramentas e classes que
facilitam uma aplicação a desempenhar o papel de persistir e manipular objetos.
O objetivo deste capítulo é analisar os frameworks de persistência de código
fonte livre (opensource) disponíveis para o ambiente Delphi. São apresentados os seguintes
frameworks:
DePO (Delphi Persistent Objects);
IO (Instant Objects);
TIOPF (TechInside Object Persistent Framework).
4.1 Delphi Persistent Objects

O DePO (Delphi Persistent Objects) (DEPO, 2005) é um framework que se
propõe a realizar o papel da camada de persistência entre o banco de dados relacional e a
aplicação orientada a objetos. Totalmente desenvolvido em Delphi como um componente, o
DePO utiliza um esquema de mapeamento que determina quais atributos das classes de
domínio da aplicação são mapeados para os campos das tabelas de dados.
Este esquema de mapeamento funciona de forma transparente ao
desenvolvedor, ou seja, este acessa os métodos do framework para manipular os objetos no
banco de dados. Esta tarefa de manipulação dos objetos é de responsabilidade do DePO. O
desenvolvedor não precisa criar uma única linha de código SQL para realizar estas tarefas
(DAIBERT, JULIO e ARAUJO, 2005).
Atualmente, o DePO é compatível com todas as versões do Delphi a partir da
versão 5. Com algumas modificações em seu código fonte, os pacotes do DePO ficam
compatíveis também com a versão 3 do Kylix para o ambiente Linux.
4.1.1 Componentes DePO

Depois de instalado, o DePO cria uma paleta chamada Liws no painel de paletas
na IDE do Delphi, nas versões mais atuais esta paleta tem o nome de DePO. Nesta paleta
estão os componentes DePO, como pode ser visualizado na Figura 4.1.
Para iniciar um projeto, basicamente são necessários dois dos componentes: o
componente de conexão ao banco de dados relacional dpoDBXMechanism para
comunicação utilizando SQLConnection do DBExpress ou dpoADOMechanism para
comunicação utilizando ADOConnection, e o componente de mapeamento
29
dpoDBMappingManager. O framework possui suporte para qualquer banco de dados

relacional, bastando apenas a máquina possuir o driver específico (DAIBERT, JULIO e
ARAUJO, 2005).
Figura 4.1. Componentes DePO
Ao configurar os componentes, deve-se configurar o componente de conexão ao

banco, associando-o a um driver previamente configurado e a um mecanismo de
mapeamento. Deve-se configurar também os parâmetros do banco de dados relacional
sendo utilizado, como usuário, senha, SQLDialect e caminho da base de dados, como
mostra a Figura 4.2.
Figura 4.2. Configurando Componente DePO
4.1.2 Classes e Propriedades

Ao se definir uma classe que será persistida utilizando o DePO, deve-se ter
atenção aos seguintes detalhes (DAIBERT, JULIO e ARAUJO, 2005):
Toda classe que efetuar persistência de objetos deve herdar da superclasse
TdpoPersistentObject, direta ou indiretamente. Nesta superclasse estão
definidos todos os métodos e atributos necessários para a manipulação e
gerenciamento do mecanismo de persistência e de mapeamento;
30
Em caso de herança, a classe pai deve herdar de TdpoPersistentObject ou

herdar de uma classe que já herde, para que os métodos e atributos de
persistência e mapeamento possam estar presentes na classe filho;
DePO utiliza a RTTI (Run Time Type Information) do Delphi para poder
acessar as propriedades publicadas, somente estas propriedades poderão
ser persistidas e mapeadas pelo DePO;
Como é utilizado o conceito de propriedades do Delphi (property) para poder
modificar e recuperar os valores dos atributos de um objeto, o
encapsulamento é respeitado.
As principais propriedades de configuração do DePO estão descritas na Tabela
4.1.
Tabela 4.1. Principais Propriedades e Métodos do DePO
Propriedade Descrição
AttributeName Define o nome do atributo que está na seção published, que será
persistido
AttributesMapping Declara todos os atributos da classe que serão persistidos
Bindings Define qual atributo resolverá o relacionamento
Cardinality Define a cardinalidade do relacionamento
ClassObject Declara a classe a ser mapeada
ColumnName Declara o nome da coluna no modelo relacional
IndexType Indica a criação de índice e tipo de índice
IsOid Identifica se o atributo é o identificador da classe
MasterAttribute Define o atributo responsável pelo relacionamento
RelatedClass Declara a classe com a qual é feito o relacionamento
RelatedObject Declara o objeto com o qual é feito o relacionamento
RelationshipsMapping Declara todos os relacionamentos da classe
Required Indica se o atributo é campo obrigatório na tabela
Retrieve Função que recupera o objeto da base de dados
Retrieved Função que verifica se o objeto foi recuperado
Size Define o tamanho do campo na tabela
StorageName Declara a tabela onde os objetos serão persistidos
A Listagem 4.1 fornece um exemplo de criação de classes utilizando o DePO. O

exemplo mostra uma herança, em que TAluno e TProfessor herdam da superclasse
TPessoa.
Listagem 4.1. Definição das Classes

type
TPessoa = Class;
TAluno = Class;
TProfessor = Class;
31
TPessoa = class(TdpoPersistentObject)
private
FCodigo: Integer;
FNome: String;
published
property Codigo: Integer read FCodigo write FCodigo;
property Nome: String read FNome write FNome;
end;
TProfessor = class(TPessoa)
private
FCPF: Integer;
published
property CPF: Integer read FCPF write FCPF;
end;
TAluno = class(TPessoa)
private
FMatricula: Integer;
published
property Matricula: Integer read FMatricula write FMatricula;
end;
4.1.3 Relacionamentos
Existem duas estratégias de se definir um relacionamento: utilizar os métodos,
classes e propriedades disponibilizados pelo DePO, ou defini-los manualmente (gerenciando
os relacionamentos de forma manual, sem auxílio do framework).
O DePO implementa todos os recursos necessários para a definição de
relacionamentos. Dentre as características principais são citadas (DAIBERT, JULIO e
ARAUJO, 2005):
tipo responsável por resolver um relacionamento através do mapeamento:
TdpoRelationshipResolver;
propriedade RelatedObject, responsável por retornar os objetos relacionados
de uma classe;
método Bindings.Add, adiciona um atributo na classe referenciada. Este
atributo guarda informações referentes ao objeto referenciado, funcionando
como uma chave estrangeira no modelo relacional;
método RelationshipsMapping.Add, responsável por definir o mapeamento
objeto-relacional dos relacionamentos.
Para múltiplas referências, ou seja, quando um objeto referencia “n” outros

objetos, o DePO possui recursos de gerenciamento de coleções de objetos em uma classe,
permitindo o mapeamento de relacionamentos de grau “n” entre classes. Este recurso é
32
especialmente útil quando temos um relacionamento entre objetos em que uma instância
pode referenciar-se a várias outras instâncias.
A criação de uma estrutura de coleção de objetos se faz necessária para que
possa manter a navegabilidade bidirecional. Esta estrutura pode ser traduzida no modelo
relacional para uma tabela navegacional.
Para isso, é necessário criar uma nova classe, herdando de uma superclasse
chamada TdpoPersistentObjectList, responsável por intermediar o acesso aos objetos que
compõe a lista.
4.1.4 Mapeamento Objeto-Relacional

O componente dpoDBMappingManager é uma implementação da interface
necessária para que a tarefa de mapeamento objeto-relacional possa ser realizada. Toda a
interação com este componente é feita através de mecanismos específicos para a conexão
com o SGDB. Atualmente estão implementados os mecanismos ADOMechanism para
comunicação utilizando ADOConnection e o DBXMechanism para comunicação utilizando
SQLConnection do DBExpress (DAIBERT, JULIO e ARAUJO, 2005).
Na atual versão do DePO existem funcionalidades para o mapeamento das
classes em arquivos XML. Esta implementação carrega um arquivo XML com as definições
de mapeamento substituindo o mapeamento feito dentro da aplicação.
É importante que o mapeamento das classes seja executado antes de instanciar
qualquer objeto desta classe. Isto pode ser feito no evento OnCreate do Form Principal
(DAIBERT, JULIO e ARAUJO, 2005). É interessante criar um procedimento e adicionar toda
a codificação do mapeamento e assim chamá-lo no evento OnCreate. Na Listagem 4.2
pode ser verificado um exemplo de mapeamento da classe TPessoa, TAluno e TProfessor.
Listagem 4.2. Mapeamento das Classes

procedure TPrincipal.FormCreate(Sender: TObject);
begin
with dpoDBMappingManager.Classes.Add do
begin
ClassObject := TPessoa;
StorageName := 'Pessoa';
with AttributesMapping.add do
begin
AttributeName := 'Codigo';
IsOid := True;
ColumnName := 'Codigo';
IndexType := idxUnique;
Required := True;
end;
begin
33
AttributeName := 'Nome';
IsOid := False;
ColumnName := 'Nome';
Required := True;
Size := 100;
end;
end;
begin
ClassObject := TAluno;
InheritsMappingFrom := TPessoa;
StorageName := 'Aluno';
begin
IsOid := True;
Required := True;
end;
begin
AttributeName := 'Matricula';
IsOid := False;
ColumnName := 'Matricula';
Required := True;
end;
end;
begin
ClassObject := TProfessor;
InheritsMappingFrom := TPessoa;
StorageName := 'Professor';
begin
IsOid := True;
Required := True;
end;
begin
AttributeName := 'CPF';
IsOid := False;
ColumnName := 'CPF';
Required := True;
end;
end;
end;
Observa-se que, no mapeamento das classes TProfessor e TAluno, é redefinido

o atributo identificador da superclasse (Codigo) para que o DePO possa resolver herança.
Além disso, o atributo InheritsMappingFrom é definido com o nome da classe pai
(TPessoa) (DAIBERT, JULIO e ARAUJO, 2005).
Um ponto importante na persistência de objetos em um SGBD relacional é como
a camada de persistência vai se relacionar com a base de dados. No DePO, existem
34
métodos que sincronizam as tabelas da base de dados com o modelo mapeado. Caso não
exista a tabela na base de dados, o DePO fará esta sincronização, criando a tabela. O
método ApplySchemaInfo do TdpoCustomMechanism, criará as instruções SQL
necessárias para esta sincronização. É disponibilizado junto com os códigos fontes do
framework classes com diversos métodos utilitários. É o caso do método
__InitializeDatabase(dpoDBXMechanism), que ao ser invocado faz a leitura do
mapeamento e gera automaticamente as tabelas na base de dados relacional.
4.1.5 Manipulação de Objetos

A manipulação de objetos é feita através de operações elementares definidas
pela sigla CRUD: Criar (Create), Recuperar (Retrieve), Atualizar (Update) e Excluir (Delete)
(AMBLER, 2000).
Todos os métodos necessários para operações CRUD são definidos na
superclasse TdpoPersistentObject e herdados pela classe que irá persistir os objetos
(DAIBERT, JULIO e ARAUJO, 2005).
A Listagem 4.3 apresenta a instanciação e persistência, através do método
Save, de um objeto da classe TAluno. A Listagem 4.4 exemplifica a recuperação de um
objeto, através do método Retrieve. Este método retorna true quando obtiver sucesso na
recuperação do objeto e false em caso contrário. A Listagem 4.5, por sua vez, apresenta
uma atualização de um objeto, basicamente combinando as técnicas de recuperação e
persistência. Finalmente, a Listagem 4.6 exemplifica a exclusão de um objeto recuperado,
através do método Delete seguido do método Save.
Listagem 4.3. Instanciação e Persistência de um Objeto

var
Aluno: TAluno;
begin
Aluno:= TAluno.Create(dpoDBXMechanism);
Aluno.Codigo:= '1';
Aluno.Nome:= 'José da Silva';
Aluno.Matricula:= '2002102013';
Aluno.Save;
end;
Listagem 4.4. Recuperação de um Objeto

var
Aluno: TAluno;
begin
Aluno.Codigo:= '1';
if not Aluno.Retrieve then
begin
35
MessageDlg('Aluno não existe', mtWarning, [mbOK], 0);

end;
end;
Listagem 4.5. Atualização de um Objeto

var
Aluno: TAluno;
begin
Aluno.Codigo:= '1';
if Aluno.Retrieve then
begin
Aluno.Nome:= 'Joaquim Souza';
Aluno.Save;
end;
end;
Listagem 4.6. Exclusão de um Objeto

var
Aluno: TAluno;
begin
Aluno.Codigo:= '1';
if Aluno.Retrieve then
begin
Aluno.Delete;
Aluno.Save;
end;
end;
4.1.6 Considerações Finais

O DePO é um framework de persistência opensource para o ambiente de
desenvolvimento Delphi que realiza bem a sua função dentro de uma aplicação utilizando o
paradigma orientado a objetos.
De aprendizado relativamente fácil, o DePO pode ser usado tranquilamente em
projetos de desenvolvimento de software, não demandando muito tempo para adequação do
programador ao framework. É requerida mais atenção por parte do programador quando for
definido e mapeado um relacionamento entre classes, uma vez que este processo é mais
complicado.
Atualmente, o DePO está sendo desenvolvido por um brasileiro e conta com a
ajuda de uma grande comunidade de desenvolvedores no Brasil, facilitando assim o
processo desenvolvimento de algum projeto com o framework, visto que o acesso aos
desenvolvedores é facilitado. Existe inclusive um fórum específico para tirar dúvidas de
utilização (http://www.oodesign.com.br/forum/).
36
Entretanto, a documentação deixa desejar, não apresentando todas as suas

funcionalidades, muito menos exemplos de utilização. Somente no site do desenvolvedor
(DEPO, 2005) é que são encontrados alguns exemplos, mesmo assim nem todos os
códigos fonte encontrados estão comentados, dificultando assim o entendimento.
4.2 Instant Objects

O Instant Objects (IO, 2005), assim como o DePO, também é um framework que
se propõe a realizar, de forma intrusiva, a persistência de objetos de um sistema orientado a
objetos. Além de realizar a persistência em sistemas gerenciadores de banco de dados
relacionais, o Instant Objects ainda persiste os objetos em arquivos XML. Ele possui uma
interface para a definição das classes do modelo, facilitando o trabalho de desenvolvimento
da aplicação.
Esta interface pode ser acessada pelo item Model Explorer do menu View,
após os pacotes do Instant Objects estarem devidamente instalados na distribuição do
Delphi. A Figura 4.3 mostra esta interface de configuração de classes. Ao utilizar o Model
Explorer para criar classes, é então gerado automaticamente código fonte Delphi das
mesmas.
Figura 4.3. Model Explorer
Atualmente o Instant Objects é compatível com a versão 6, 7, 2005 e 2006 do

Delphi, além da compatibilidade com o Kylix 3 para ambiente Linux. Até a versão 1.6 do
framework, todas as conexões com a base de dados eram feitas através dos componentes
data-aware do Delphi (componentes que se conectam diretamente à base de dados através
de alguma fonte de dados). A partir da versão 2.0, novas implementações de conexão ao
banco de dados foram suportadas, não havendo a necessidade de comunicação com a
base de dados utilizando os componentes data-aware, no entanto ainda é suportado este
tipo de prática.
37
4.2.1 Componentes Instant Objects

Depois de instalado, o Instant Objects cria um paleta de mesmo nome no painel
de paletas da IDE do Delphi, como pode ser visto na Figura 4.4, além de criar um acesso ao
Model Maker através do menu View.
Figura 4.4. Componentes Instant Objects
Para iniciar um projeto com o Instant Objects, é necessário configurar os

componentes de acesso ao banco de dados e adicionar as classes através do Model
Maker.
Para a configuração dos componentes de acesso à base de dados deve-se
instalar o broker (componente de interface para acesso aos dados) específico. Existe uma
grande variedade de brokers para conexão às bases de dados relacionais implementados
no Instant Objects, entre elas as mais usadas são: DBXConnection, ADOConnection, Zeos,
IBX, BDE.
No exemplo da Figura 4.4 está sendo usado o componente broker
InstantDBXConnector que usa a interface DBXConnection. Para esta configuração é
necessário adicionar no projeto um componente do tipo SQLConnection e associá-lo ao
InstantDBXConnector. Observe que o responsável por conectar ao banco de dados é o
componente do Delphi. O InstantDBXConnetor é somente a interface de acesso do
InstantObjects à base de dados.
No componente SQLConnection são configurados os dados de acesso à base
de dados, como caminho, sql dialect, usuário e senha. Os demais componentes disponíveis
na paleta são para auxiliar na construção das aplicações, além de componentes visuais para
facilitar a manipulação das informações dos objetos persistidos. As demais funcionalidades
do Instant Objects são acessadas via código fonte.
O próximo passo é incluir as classes do modelo na aplicação através do Model
Maker, e então criar as tabelas da base de dados, através do botão Build DataBase,
38
disponível na sua interface. O Instant Objects gera automaticamente as tabelas de acordo

com as classes inseridas.

Ao adicionar as classes do modelo no Model Explorer, deve-se inicialmente
configurar a unit que armazenará o código fonte gerado, e isso deve ser feito acessando o
botão selecionar units (select units) presente na interface.
Para incluir uma nova classe ao projeto, clique com o botão direito sobre a
interface e selecione o item nova classe (new class). Aparece então uma janela, como
exemplificado na Figura 4.5, com a interface necessária para adicionar todos os itens da
classe, como:
nome da classe;
superclasse (toda classe que efetuar a persistência de objetos deve herdar da
superclasse TInstantObject, direta ou indiretamente. Nesta classe estão
definidos todos os métodos e atributos necessários para a manipulação e
gerenciamento do mecanismo de persistência do framework);
unit onde o código fonte gerado é armazenado;
tipo de persistência (Stored para classe persistente, ou seja, para classe que
irá persistir informações e Embedded para não persistente);
nome da tabela gerada no modelo relacional;
atributos.
Figura 4.5. Adicionando Nova Classe

39
Em atributos é configurado o tipo do atributo, nome, se ele é privado ou público,

o nome do campo gerado na tabela no modelo relacional, entre outros. Pode-se também
definir uma espécie de máscara para o atributo, como por exemplo, a máscara para o CPF.
Este recurso é interessante uma vez que o próprio framework se responsabiliza pela
validação da máscara e dos dados digitados na aplicação.
Observe que ao definir as classes através do Model Explorer, o desenvolvedor
está definindo também o mapeamento objeto-relacional do modelo. Ele mapeia quais
classes e atributos se tornarão tabelas e campos no modelo relacional.
Na Listagem 4.7 abaixo, é exibido o código fonte gerado automaticamente pelo
Instant Objects após a criação das classes. Observe que são gerados automaticamente
também os gets e sets dos atributos, para que o encapsulamento seja mantido. Note a
existência de um comentário entre a definição das classes, iniciando com IOMETADATA. É
através deste comentário que o Instant Objects enxerga o mapeamento e
consequentemente gera automaticamente o código SQL para criar as tabelas na base de
dados relacional.

type
TAluno = class;
TPessoa = class;
TProfessor = class;
TPessoa = class(TInstantObject)
{IOMETADATA stored;
Nome: String(100) default; }
_Nome: TInstantString;
private
function GetNome: string;
procedure SetNome(const Value: string);
published
property Nome: string read GetNome write SetNome;
end;
{IOMETADATA stored;
Matricula: Integer default; }
_Matricula: TInstantInteger;
private
function GetMatricula: Integer;
procedure SetMatricula(Value: Integer);
published
property Matricula: Integer read GetMatricula write SetMatricula;
end;
{IOMETADATA stored;
CPF: Integer default; }
_CPF: TInstantInteger;
private
function GetCPF: Integer;
procedure SetCPF(Value: Integer);
40
published
property CPF: Integer read GetCPF write SetCPF;
end;
Diferentemente do framework DePO, o Instant Objects faz o controle automático

do OID (Object Identification). O desenvolvedor não precisa declarar o atributo identificador
do objeto, tão menos declarar que campo será a chave primária no modelo relacional.
O Model Explorer possui ainda a funcionalidade de importação e exportação do
modelo de classes nele criado. Para isso basta acessar a opção disponível no clique do
botão direito da interface chamada exportar modelo (Export Model). Ao clicar é gerado um
arquivo XML com toda a estrutura e definições das classes.
Feita a criação das classes, deve-se então criar as tabelas na base de dados.
Para realizar esta tarefa é necessário clicar no botão construir banco de dados (build
database), disponível na interface do Model Explorer. É então exibida uma janela para
configuração de acesso à base de dados e criação das tabelas, como pode ser
exemplificado na Figura 4.6 abaixo.
Figura 4.6. Criação das Tabelas em Base de Dados Relacional

41
Com isso, as tabelas são criadas no banco de dados relacional e prontas para
persistirem as informações dos objetos, diferentemente do framework DePO, onde as
tabelas são criadas na execução do programa.
O Instant Objects possui uma estrutura especializada para a definição de
relacionamentos entre classes. Todos os relacionamentos são definidos através de escolha
de atributos chaves. Essa funcionalidade pode ser explorada no Model Explorer, quando se
define os atributos. A Figura 4.7 exemplifica o uso do tipo referencia (Reference) para o
atributo. O tipo referência é utilizando quando um objeto de classe referencia um único outro
objeto, como nos relacionamentos do tipo 1:1 e 1:n. Na Figura 4.7 pode-se observar o
relacionamento entre as classes TCurso e TDisciplina (uma disciplina é de um curso e um
curso pode ter várias disciplinas – Associação do tipo 1:n). Já a Figura 4.8 está sendo
exemplificado o uso do tipo referências (References) do atributo. Este tipo é utilizado
quando um objeto de classe referencia vários outros, como nos relacionamentos do tipo n:n.
É exemplificado na figura o relacionamento entre as classes TCurso e TAluno (um curso
pode ter vários aluno e um aluno pode cursar vários cursos – associação do tipo n:n).
Observa-se que para este tipo é requerido o nome para a tabela navegacional (External
Storage Name), que manterá a navegabilidade entre os objetos referenciados.
Figura 4.7. Criação de Atributo de Relacionamento para uma Referência

42
Figura 4.8. Criação de Atributo de Relacionamento para Várias Referencias
Para gerenciar listas de objetos, o Instant Objects possui uma estrutura

semelhante a um ClientDataSet, o componente InstantSelector. Quando adicionado na
aplicação, fornece uma estrutura de recuperação de objetos via consultas SQL, como é visto
na Figura 4.9. No componente pode-se definir qual a classe e qual o atributo são parâmetros
para a consulta.
Figura 4.9. Configuração do Componente InstantSelector

43
Para executar a consulta configurada no componente basta executar o

procedimento Open. Feito isso, o componente já estará com a lista de objetos resultantes
da consulta na memória prontos para serem manipulados de forma transparente ao
desenvolvedor. Todo o manejo dos objetos dentro do componente é muito semelhante ao
manejo de dados em um ClientDataSet.
A consulta configurada no componente pode também ser configurada de forma
dinâmica via código fonte, aumentando assim as possibilidades de desenvolvimento com
este componente, inclusive a criação do conceito de critério (criteria) de recuperação de
objetos, usando a cláusula WHERE do SQL.

Todo o mapeamento objeto-relacional no Instant Objects é feito na definição das
classes através da interface do Model Explorer. Não é necessário mais nenhum tipo de
esforço de programação.
Quando se define uma classe é definido também o seu mapeamento para o
modelo relacional. O mesmo ocorre quando se define um atributo desta classe.

Assim como o DePO, a manipulação de objetos pelo Instant Objects também é
feita através das operações elementares definidas pela sigla CRUDs: Criar (Create),
Recuperar (Retrieve), Atualizar (Update) e Excluir (Delete). Não é necessário escrever uma
única linha de código SQL para se manipular os objetos.
Todos os métodos necessários para operações CRUDs são definidos na
superclasse TInstantObject e herdados pelas classes persistentes do modelo definido pelo
desenvolvedor.
A Listagem 4.8 apresenta a instanciação e persistência, através do método
Store, de um objeto da classe TAluno. A Listagem 4.9 exemplifica a recuperação de um
objeto, através do método construtor Retrieve. Este método instancia um objeto com os
parâmetros passados para ele. A Listagem 4.10, por sua vez, apresenta uma atualização de
um objeto, basicamente combinando as técnicas de recuperação e persistência. Já a
Listagem 4.11 exemplifica a exclusão de um objeto recuperado, através do método
Dispose.
44
Listagem 4.8. Instanciação e Persistência de um Objeto

var
objAluno : TAluno;
begin
objAluno := TAluno.Create(dtmdlConexao.InstantDBXConnector);
objAluno.Nome := 'José da Silva';
objAluno.Matricula := 2002102013;
objAluno.Store();
end;
Listagem 4.9. Recuperação de um Objeto

var
objAluno : TAluno;
begin
try
objAluno := TAluno.Retrieve('ID',false,false,dtmdlConexao.InstantDBXConnector);
except
MessageDlg('Aluno não Existe', mtWarning, [mbOK], 0);
end;
end;
Listagem 4.10. Atualização de um Objeto

var
objAluno : TAluno;
begin
try
objAluno.Nome := 'Joaquim Souza';
objAluno.Matricula := 2003201245;
objAluno.Store();
except
end;
end;
Listagem 4.11. Exclusão de um Objeto

var
objAluno : TAluno;
begin
try
objAluno.Dispose();
except
end;
end;

O Instant Objects é um framework extremamente fácil de se lidar, com um
aprendizado muito rápido. Após sua versão 1.6 houve um grande avanço com relação à
maleabilidade de uso não necessitando utilizar componentes data-aware do Delphi.
45
A interface Model Explorer viabiliza o curto aprendizado do framework,

facilitando o desenvolvimento de aplicações. Ela diminui o esforço de programação do
desenvolvedor, deixando-a intuitiva e simples. Todo o mapeamento objeto-relacional é feito
de forma visual e muito menos suscetível a erros.
O framework conta com um suporte baseado em fóruns de discussão, onde a
comunidade que o utiliza ajuda os usuários menos experientes
(http://delphi.newswhat.com/geoxml/forumlistgroups?area=instantobjects). Entretanto, a
documentação, assim como a do DePO, também deixa a desejar. A documentação do
Instant Objects consiste em arquivos de texto explicando basicamente a sua instalação e
qual a utilidade de cada arquivo do seu código fonte. Não existe nenhum documento
explicando e exemplificando o uso de suas funcionalidades e métodos.
O único recurso que existe para exemplificar o seu uso é um vídeo tutorial
disponível para download no site do desenvolvedor, além de cinco pequenas aplicações
exemplo, com seu código fonte não comentado, dificultando assim o entendimento.
4.3 TechInside Object Persistent Framework

O TiOPF (TechInside Object Persistent Framework) (TIOPF, 2005) é um
framework de persistência objeto-relacional mais complexo que os demais acima
apresentados. Toda a estrutura de conexão à base de dados, bem como a estrutura de
mapeamento objeto-relacional é feitos via código fonte, diferentemente dos já apresentados,
que possuem componentes visuais para efetuar tal tarefa.
Também de código fonte aberto (opensource), o TiOPF possui uma estrutura
interessante de desenvolvimento. A empresa que o desenvolve, a TechInside, possui uma
política de testes unitários automáticos com o Dunit (DUNIT, 2005) que proporciona maior
confiabilidade e estabilidade nos códigos fontes desenvolvidos, e consequentemente menos
bugs para os usuários.
O DUnit, é um sistema que efetua testes unitários nas classes e métodos
escritos em Delphi e verifica a integridade das mesmas. Originalmente inspirado no JUnit,
para Java, o DUnit cumpre muito bem sua tarefa e proporciona uma agilidade na
programação, uma vez que os testes são feitos de forma automática (DUNIT, 2005).
O framework TiOPF é compatível com as versões 5, 6 e 7 do Delphi.
46
4.3.1 Componentes TiOPF

Depois de instalado, o TiOPF cria uma paleta chamada TechInside no painel de
paletas da IDE do Delphi, como pode ser visto na Figura 4.10.
Figura 4.10. Componentes TiOPF
O TiOPF possui uma grande quantidade de componentes disponíveis para o

uso, no entanto, praticamente todos os exibidos na Figura 4.10 são componentes data-
aware para acesso aos dados do framework. Não existem componentes de configuração
visual dos dados, o que o torna mais complexo de utilizar. Toda a configuração de acesso
ao banco de dados e o mapeamento objeto-relacional é feito via código fonte.
Dentre os componentes existentes é exemplificado o tiListView, semelhante ao
ListView do Delphi, o tiPerAwareEdit, semelhante ao Edit, o tiPerAwareMemo, semelhante
ao memo, entre outros. São no total 29 componentes disponíveis, sendo 27 data-aware.
Estes componentes possuem toda a estrutura para conexão ao mecanismo de persistência
do framework de forma natural, o que o torna os componentes do Delphi incompatíveis com
o framework.
Para persistência de dados, o TiOPF conta com a implementação das seguintes
estratégias: banco de dados relacional, arquivos XML e arquivos CSV (Comma Separate
Values). Para conexão ao banco de dados estão implementados suporte ao IBX (Interbase e
Firebird), OracleDOA (Oracle), BDE (Paradox) e ADO (MS Access e SQL Server).
O primeiro passo para se utilizar o TiOPF em um projeto e configurar o acesso à
base de dados. O mesmo deve ser feito como exemplificado pela Listagem 4.12. Veja que é
passado como parâmetro o caminho da base de dados, usuário, senha e a estratégia de
persistência (IBX, ADO, XML, CSV). O TiOPF possui uma espécie de gerente para o acesso
à camada de persistência. Este gerente é um objeto da classe tiPerAwareCtrls,
responsável pelo gerenciamento das conexões e manipulação dos objetos na base de
dados relacional.
O framework não possui nenhum recurso de geração automática das tabelas na
base de dados relacional. As mesmas devem ser criadas manualmente ou através de
métodos disponíveis nas classes do TiOPF, como exemplificado pela Listagem 4.13 abaixo.
Observe a criação da tabela Aluno, com os campos OID, Matricula e Nome. Já na listagem
4.14 é exibido um exemplo que verifica se alguma tabela existe no banco de dados. A
Listagem 4.15 exemplifica o uso dos métodos de se excluir tabelas diretamente na base de
47
dados. Lembrando que para acessar estes métodos do framework é necessário dar uses
nas units do TiOPF que gerenciam as conexões: tiPersist, tiDBConnectionPool e
tiPerAwareCtrls.
Listagem 4.12. Configurando o Acesso à Base de Dados.

gTIPerMgr.LoadPersistenceLayer('IBX','Dados.gdb','sysdba','masterkey');
Listagem 4.13. Criando Tabela

var
lTableMetaData : TtiDBMetaDataTable ;
begin
lTableMetaData := TtiDBMetaDataTable.Create ;
try
Screen.Cursor := crHourGlass;
lTableMetaData.Name := 'Aluno' ;
lTableMetaData.AddField( 'OID', qfkString, 36 ) ;
lTableMetaData.AddField( 'Nome', qfkString, 70 ) ;
lTableMetaData.AddField( 'Matricula', qfkInteger) ;
gTIPerMgr.CreateTable( lTableMetaData ) ;
finally
lTableMetaData.Free;
Screen.Cursor := crDefault;
end ;
end;
Listagem 4.14. Verifica Existência da Tabela

var
lDBMetaData : TtiDBMetaData ;
lPooledDB : TPooledDB ;
lDatabase : TtiDatabase ;
begin
lDBMetaData := TtiDBMetaData.Create ;
try
lPooledDB := gTIPerMgr.DefaultDBConnectionPool.Lock ;
try
lDatabase := lPooledDB.Database ;
lDatabase.ReadMetaDataTables(lDBMetaData);
result := lDBMetaData.FindByTableName('Aluno') <> nil;
finally
gTIPerMgr.DefaultDBConnectionPool.UnLock(lPooledDB);
end ;
finally
lDBMetaData.Free;
end ;
end;
Listagem 4.15. Exclusão de Tabela

gTIPerMgr.DropTable( 'Aluno' );

Assim como os frameworks já citados neste trabalho, o TiOPF também é um
framework intrusivo. Por este motivo, todas as classes definidas para serem persistidas
48
utilizando o TiOPF devem herdar diretamente ou indiretamente da superclasse TPerObjAbs,

como exemplificado na Listagem 4.16 onde é definida a classe TAluno.
Da mesma forma que o DePO, o TiOPF se utiliza da RTTI (Run Time Type
Information) do Delphi para ter acesso às propriedades dos objetos e consequentemente
aos seus atributos, por esta razão, todos os atributos dos objetos persistentes devem ser
declarados como propriedades na seção published na definição das classes.

TPessoa = class (TPerObjAbs)
private
FNome : string;
published
property Nome: string read FNome write FNome;
end;
TProfessor = class (TPessoa)

private
FCPF : Integer;
published
property Matricula : Integer read FCPF write FCPF ;
end;
private
FMatricula : Integer;
published
property Matricula : Integer read FMatricula write FMatricula ;
end;
O TiOPF não dispõe de nenhuma estrutura especialista para gerenciar
relacionamentos, como os demais frameworks apresentados. Os mesmos devem ser feitos
de forma manual. O único auxílio que o framework presta para esta tarefa é a criação
automática do campo de ligação das tabelas no modelo relacional quando um objeto
referencia outro objeto, como exemplificado na Listagem 4.17.
Veja que a classe TProfessor possui um atributo do tipo TDisciplina. Quando isto
acontece, o TiOPF cria automaticamente um campo no modelo relacional que referencia o
OID de TDisciplina, criando então o conceito de chave estrangeira.
Listagem 4.17. Definição de Relacionamento

private
FCPF : Integer;
FDisciplina : TDisciplina;
published
property CPF : Integer read FCPF write FCPF ;
49
property Disciplina : TDisciplina read FDisciplina ;

end;
TDisciplina = class(TPerObjAbs)
private
FNome : String;
FEmenta : String;
published
property Nome : String read FNome write FNome;
property Ementa : String read FEmenta write FEmenta;
end;
O framework dispõe ainda de uma estrutura de gerenciamento de listas de

objetos. Isto é feito através da classe TPerObjList. Quando um objeto herda desta classe,
ele herda consigo todos os métodos e atributos que o TiOPF dispõe para, de forma efetiva,
gerenciar uma lista de objetos. A Listagem 4.18 trás um exemplo de utilização desta classe.
Um recurso interessante desta classe é a persistência automática de vários objetos da lista.
Usando o método Add(), o desenvolvedor adiciona um objeto na lista e utilizando o método
Save(), ele persiste todos os objetos contidos naquela lista.
Listagem 4.18. Definição da Classe de Lista de Objetos

TAlunos = class( TPerObjList )
private
protected
function GetItems(i: integer): TAluno ; reintroduce ;
procedure SetItems(i: integer; const Value: TAluno); reintroduce ;
public
property Items[i:integer] : TAluno read GetItems write SetItems ;
procedure Add( pObject : TAluno ; pDefDispOrdr : boolean=true); reintroduce ;
procedure Clear ; override ;
procedure Read ; override ;
published
end;
A classe TAlunos acima exemplificada é capaz então, de prover uma interface

de gerenciar uma coleção de objetos do Tipo TAluno. Este recurso é especialmente útil
quando uma instancia de classe referencia várias outras.

Da mesma forma que o DePO, o mapeamento objeto-relacional deve ser
programado dentro do código fonte da aplicação. Não existe nenhuma outra estratégia a
não ser esta. A Listagem 4.19 exemplifica como que deve ser realizado um mapeamento
objeto-relacional no TiOPF. É com este código que o framework sabe para qual campo e
tabela da base de dados relacional são persistidos os atributos de determinado objeto.
Observa-se no exemplo que é executado o método RegisterMapping para mapear o
50
atributo e tabela e é utilizado o método RegisterCollection para mapear a classe que é

coleção de objetos de outra, como exemplificado anteriormente neste trabalho.
Listagem 4.19. Mapeamento Objeto-Relacional

gTIPerMgr.ClassDBMappingMgr.RegisterMapping(TAluno,'Aluno','OID','OID', [pktDB] );
gTIPerMgr.ClassDBMappingMgr.RegisterMapping(TAluno,'Aluno','Matricula','Matricula');
gTIPerMgr.ClassDBMappingMgr.RegisterCollection(TAlunos, TAluno);
O primeiro parâmetro a ser passado para o método RegisterMapping é o nome

da classe. No exemplo apresentado, a classe é a TAluno. O segundo é o nome da tabela
no modelo relacional que esta classe foi mapeada. O terceiro parâmetro é o nome da
propriedade de classe a ser mapeada. E por fim, o quarto é o nome do campo que a
propriedade foi mapeada no modelo relacional.
O mapeamento deve ser executado assim que a aplicação for carregada.

A manipulação de objetos através do framework TiOPF é feita através dos
componentes data-aware disponibilizados pela TechInside. Basicamente, todos os
componentes possuem um método de associação a um atributo de algum objeto, como por
exemplo, associar o componente tiAwareEdit ao atributo nome do aluno. Assim que for
adicionado algum texto no componente, este automaticamente popula o atributo do objeto.
Feito isso, o objeto é adicionado em uma lista de objetos e pode ser salvo
invocando o método Save() da lista de objetos. Para recuperar um objeto, o processo é o
mesmo, só que antes os objetos são recuperados na memória através do método List() da
lista. Com esta lista de objetos na memória é então facilitada a manipulação dos mesmos.
Existe ainda um recurso de recuperar objetos através de critérios.
Para que isso possa ser feito, deve-se criar uma outra classe herdando da
superclasse tiAwareCriteria. Nesta superclasse estão todos os métodos e atributos que
fornecem a estrutura de recuperação através de critérios de classificação. Este recurso
consiste em aceitar consultas SQL e recuperar os objetos que atendam ao que foi
consultado.
Para se excluir um objeto, primeiro se recupera e depois através do componente
data-aware é executado o método Delete. Com isso, o objeto é destruído da memória e tem
o seu registro excluído na base de dados relacional.
51

O TiOPF se mostra um framework de persistência bastante complexo e de difícil
utilização. A sua curva de aprendizado é bem maior, quando comparado ao DePO ou ao
Instant Objects. A sua falta de recursos visuais e integração com a IDE do Delphi o torna
complicado de configurar e consequentemente mais suscetível à falhas.
Um outro ponto negativo de sua utilização é a obrigatoriedade do uso dos
componentes data-aware por ele disponibilizados. Esta obrigatoriedade restringe as
possibilidades de programação e desenvolvimento aos 29 componentes disponíveis. No
entanto, ele cumpre muito bem sua tarefa de manipular objetos em uma base de dados
relacional.
Sua documentação, assim como todos os frameworks apresentados, também
deixa a desejar, no entanto, é o único que possui uma gama de exemplos com código fonte
documentados, facilitando assim o entendimento.
4.4 Conclusão
Este capítulo apresentou três frameworks opensource de persistência e
manipulação de objetos em sistemas gerenciadores de banco de dados relacionais para o
ambiente de desenvolvimento Delphi.
O primeiro apresentado foi o DePO (Delphi Persistent Objects). Este framework
possui toda uma estrutura para adequar o modelo orientado a objetos para o modelo
relacional. Foram apresentados exemplos da sua utilização, desde criação das classes
persistentes, até a manipulação de objetos (criar, recuperar, atualizar e excluir).
O Instant Objects foi o segundo a ser apresentado. Ele possui uma interface de
configuração chamada Model Explorer, que praticamente anula o esforço de programação
existente para adequar o modelo orientado a objetos para o modelo relacional. Esta
interface visual facilita o trabalho do desenvolvedor, além de minimizar os problemas que
por ventura podem ocorrer quando a configuração é feita via código fonte.
Ao final, foi apresentado o framework TiOPF (TechInside Object Persistent
Framework). Este, de aprendizado mais difícil, não possui nenhum recurso visual de
configuração. Toda a configuração é realizada via código fonte. Ele obriga o desenvolvedor
a utilizar seus componentes data-aware para a manipulação dos objetos, o que implica que
as aplicações tenham sempre as mesma interfaces, além de restringir o desenvolvedor a
sempre utilizar estes componentes.
Na Tabela 4.2 abaixo, é apresentado um comparativo entre os frameworks,
considerando os requisitos desejáveis de uma camada de persistência. Cada framework
52
comparado esta disposto em uma coluna que é relacionada com os requisitos que estão
apresentados nas linhas da tabela. Os requisitos de uma camada de persistência foram
apresentados e conceituados no item 3.2.3.1 deste trabalho.
Tabela 4.2. Comparativo Entre os Frameworks
Requisitos Framework
DePO InstantObjects TiOPF
Diversos tipos de mecanismos de persistência X
Encapsulamento da camada de dados X X X
Ações com multi-objetos X X X
Transações X X
Extensibilidade X X X
Geração de identificadores de objetos X X
Cursores e proxies
Registros X X X
Múltiplas Arquiteturas X X X
Diversas versões de banco de dados X X X
Múltiplas conexões X X
Consultas SQL X X
Controle de concorrência X X X
53
5 ESTUDO DE CASO
5.1 Introdução
O estudo de caso proposto neste trabalho baseia-se no estudo de caso utilizado
no projeto de iniciação científica “Estratégia de Persistência de Software Orientado a Objeto”
da faculdade Metodista Granbery, no qual o discente é participante.
Vislumbrando o estudo de diversas estratégias de persistência em software
orientado a objetos dentro do contexto do projeto de iniciação científica, este estudo de caso
foi escolhido por abordar de forma singular as principais características da orientação a
objetos.
O sistema escolhido para estudo de caso foi o “Sistema de Controle Acadêmico”,
abordado na cadeira de Laboratório de Programação III da Faculdade Metodista Granbery
(ARAUJO, 2004). Esta cadeira tem como objetivo capacitar os discentes para o
desenvolvimento de aplicações no ambiente de desenvolvimento Delphi. No entanto, a
aplicação toda foi desenvolvida com o paradigma estruturado. Coube aos membros do
projeto de iniciação científica fazer uma reengenharia do sistema, transformando-o em um
sistema orientado a objetos.
5.2 Projeto de Iniciação Científica

O projeto de iniciação científica intitulado “Estratégias de Persistência em
Software Orientado a Objetos” tem como objetivo o estudo exploratório das tecnologias de
persistência de objetos, incluindo tecnologias de banco de dados orientado a objetos e
objeto-relacionais, além de técnicas de mapeamento objeto relacional.
O seu objetivo é realizar um estudo comparativo entre as abordagens de
persistência em software orientado a objetos, envolvendo banco de dados orientado a
objetos, objeto-relacionais e camadas de mapeamento objeto-relacional para base de dados
relacionais. São avaliadas características como desempenho, soluções encontradas,
dificuldades, vantagens e desvantagens de cada abordagem. O objetivo final do projeto é a
criação de uma camada de persistência própria, para o ambiente de desenvolvimento
Delphi.
O projeto contou inicialmente com um estudo exploratório das tecnologias de
persistência de objetos. Após foi definida uma aplicação protótipo para a validação das
estratégias de persistência. Com isso foi feito um levantamento das soluções de
gerenciadores de banco de dados para a avaliação de viabilidade prática das abordagens.
Foi feita então, uma definição e implementação de uma nova ferramenta de persistência de
54
objetos, compatível com o ambiente Delphi. Ao final foi realizado uma comparação entre as
abordagens estudadas.
5.3 Sistema de Controle Acadêmico

O objetivo é construir uma aplicação protótipo usando a ferramenta de
desenvolvimento Delphi para testar como um framework de persistência interage com esta
ferramenta de desenvolvimento e quais as melhores práticas.
O framework de persistência escolhido para a implementação do protótipo é o
DePO (Delphi Persistent Objects). Esta escolha foi fundamentada inicialmente pela
facilidade de uso do framework e sua adequação ao modelo do sistema acadêmico. Além do
fato de que os desenvolvedores do framework serem brasileiros e de mais fácil acesso.
Com a reengenharia do sistema acadêmico, foi aplicado o padrão de projeto
MVC (Model-View-Controller) visando favorecer o estudo das estratégias de persistência,
dividindo o sistema em camadas.
Padrões de projeto são soluções genéricas e reutilizáveis, aplicáveis em classes
de problemas bem conhecidos. Soluções consagradas para problemas conhecidos, tornam-
se receitas para situações similares (desde que estas soluções tenham sido projetadas com
flexibilidade) (SHALLOWAY e TROTT, 2002).
O padrão MVC (Model-View-Controller) é um padrão de projeto bastante usado
em aplicações, pois permite que se separe o modelo de dados das várias formas que o
dado possa ser acessado e manipulado (MVC, 2005). Ou seja, o sistema é divido em
camadas, e esta interagem entre si.
O MVC oferece vantagens significativas no desenvolvimento de aplicativos,
através da separação das camadas, possibilitando implementar com maior facilidade e
clareza questões importantes como a persistência de dados, controle de segurança,
comunicação em rede e fluxo de visualização (SHALLOWAY e TROTT, 2002).
Permite ainda que as equipes de desenvolvimento possam se concentrar em
suas habilidades centrais e integrar as camadas através de interfaces bem definidas. Esta
separação permite que aplicativos possam ser facilmente modificados e estendidos para
atender a novas exigências, bem como possibilita que a interface com o usuário apresente
várias visões de um só modelo sem interferir com a lógica de negócio.
Como mostra a figura 5.1, o usuário interage com o sistema através das
interfaces (View). Estas se comunicam com os controladores (Controllers), que por sua vez
delega requisições para um dos tratadores apropriados, que estão localizados no modelo
55
(Model), que representa a lógica de negócio e o estado da aplicação. A requisição então é

respondida, através do controlador, e apresentada na interface (View), da maneira
adequada.
Figura 5.1. Modelo MVC (ARAUJO, 2005)
No Sistema de Controle Acadêmico, o Model está implementado em uma unit do

Delphi, onde todas as classes de domínio, com seus atributos e métodos, estão lá definidos.
Para o Controller foram criadas classes que levam o nome de gerente. Nos gerentes estão
implementados os métodos de manipulação dos dados recebidos da interface e exibição na
tela, conexões ao banco, entre outras operações. Para este estudo de caso foi utilizado o
conceito de gerente de funcionalidade, ou seja, o gerente é responsável por determinada
funcionalidade no negócio, diferentemente dos gerentes de classe, onde os gerentes são
responsáveis única e exclusivamente pelas classes e suas interfaces de comunicação.
O View é a parte do projeto que são as interfaces, capaz de interagir com o
usuário final, ou seja, são as telas de pesquisa e manutenção de cadastro, além dos
relatórios.
5.4 Implementação
5.4.1 Introdução
Buscando explicar e exemplificar a implementação do estudo de caso
apresentado neste trabalho é usado um fragmento do Sistema de Controle Acadêmico. Este
fragmento consiste na manutenção de cursos que compõe a inclusão, alteração, consulta e
exclusão dos dados persistidos pelo framework de persistência DePO.
O objetivo deste tópico é apresentar as interfaces de interação com o usuário e a
implementação das funcionalidades e chamadas do modelo MVC. São apresentados os
diagramas de seqüência com a interação dos fluxos de manutenção de cadastro de curso e,
56
a partir destes diagramas, são mostradas as implementações feitas em cada método

utilizando a linguagem de programação Delphi.
Em anexo a este trabalho (Anexo A), é apresentada toda a documentação do
sistema, seguindo a notação da UML (UML, 2005), além da documentação de requisitos no
padrão IEEE Std 830-1998 (IEEE, 2005).
Buscando exemplificar o fragmento escolhido para a apresentação do sistema, a
Figura 5.2 apresenta o Diagrama de Caso de Uso e a Figura 5.3 apresenta o diagrama de
classes sem atributos e métodos.
Figura 5.2. Diagrama de Caso de Uso

57
Pessoa
Turma Professor
0..* 1
0..* 1
0..*
0..*
0..*
0..* Aluno TurmaAluno
1
1..*
Coordena
0..1 Aloca
Avaliacao
0..*
1
Disciplina Curso
1..*
0..* 1
1
Figura 5.3. Diagrama de Classes
É implementado o modelo MVC através das classes de domínio, apresentadas

acima, as classes de controle (gerentes) e as classes de interface. Para as classes de
controle é implementado uma superclasse chamada TGerente, que possui os métodos
virtuais e abstratos dos seus filhos. Um exemplo do seu filho é o gerente
TGerenteCadastroCurso, exemplificado nos próximos tópicos deste estudo de caso.
Toda a interação entre as classes do MVC são apresentadas na Figura 5.4.
58
Figura 5.4. Interação da Classe Controle - Gerente
É apresentado abaixo, o fragmento de Manutenção de Cursos da especificação

de caso de uso disponível na documentação do sistema:
Caso de Uso 01: Manutenção de Cursos
Ator Principal:
Secretaria
Sumário:
Este caso de uso é iniciado pela secretaria quando ela requisita ao sistema um
cadastro de curso, selecionando a opção a partir de uma interface de pesquisa de curso,
informando os dados do mesmo. O objetivo deste caso de uso é possibilitar que ocorra a
inclusão de cursos no sistema, a consulta, a alteração ou a exclusão daqueles já existentes.
Pré-Condições:
Não Aplicável.
Fluxo Principal:
1. A secretaria solicita ao sistema o cadastro de cursos;
2. O sistema exibe uma lista com os cursos cadastrados, contendo código e descrição
do curso, ordenada alfabeticamente pela descrição do curso;
3. O sistema solicita a opção de inclusão de um novo curso ou alteração, exclusão ou
consulta de um curso selecionado;
59
4. A secretaria informa a opção desejada;

5. O sistema executa o subfluxo correspondente ao tipo de operação recebido (Incluir,
Alterar, Excluir ou Consultar).
Fluxos Alternativos:
1. A secretaria pode modificar a ordenação da lista de disciplinas cadastradas, podendo
ordenar pela descrição do curso ou pela descrição da disciplina;
2. A secretaria pode efetuar uma pesquisa na lista de disciplinas cadastradas, podendo
pesquisar pela descrição da disciplina ou pela descrição do curso. A pesquisa não
necessita ser exata, sendo feita a partir do início do campo pesquisado. A pesquisa
deve ignorar letras maiúsculas e minúsculas;
3. A secretaria pode filtrar as disciplinas exibidas selecionando o curso desejado
através de sua descrição;
4. A secretaria pode cancelar a operação de cadastramento, fechando a interface.
Subfluxo: Operação Incluir

1. O sistema exibe a interface com todos os campos habilitados;
2. O sistema exibe todos os campos vazios;
3. O sistema solicita a entrada dos seguintes dados: curso (selecionado pela descrição
e representado pelo código), código, descrição, período, número de aulas, ementa e
bibliografia;
4. A secretaria informa ao sistema os dados solicitados;
5. O sistema solicita a confirmação da operação;
6. A secretaria confirma operação;
7. O sistema efetua a validação dos campos (RN1, RN2, RN3);
8. O sistema efetua críticas de acesso concorrente (registro duplicado);
9. O sistema armazena os dados;
10. O sistema fecha a interface.
Subfluxo: Operação Pesquisar

1. O sistema exibe a interface com uma lista de todos os cursos disponíveis,
compreendendo: código e nome de curso;
Subfluxo: Operação Alterar

60
1. O sistema exibe a interface com todos os campos habilitados, exceto o código do

curso;
2. O sistema efetua a leitura do registro a partir do código do curso selecionado;
3. Sistema exibe os dados: código, descrição, carga horária, professor coordenador,
quantidade de períodos e tipo de curso;
4. Sistema solicita a modificação nos seguintes dados;
5. A secretaria altera os campos;
7. A secretaria confirma a operação;
9. O sistema efetua críticas de acesso concorrente (alteração de registro alterado ou
excluído);
Subfluxo: Operação Excluir

1. O sistema exibe a interface com todos os campos desabilitados;
3. Sistema exibe os dados nos respectivos campos;
6. O sistema efetua críticas de acesso concorrente (exclusão registro alterado ou
excluído);
7. O sistema exclui os dados;
Subfluxo: Operação Consultar

4. A secretaria fecha a interface.
61
1. A secretaria cancela a operação de inclusão. O sistema exibe novamente todos os

campos de entrada vazios;
2. A secretaria cancela a operação de alteração. O sistema exibe novamente os dados
originais do registro;
3. A secretaria fecha a interface durante as operações de inclusão ou alteração. Caso
tenham ocorrido modificações de informações, o sistema avisa da possibilidade de
perda de dados.
Fluxos de Exceção:
1. O código do curso não foi preenchido. Sistema exibe uma mensagem e retorna a
entrada ao campo código do curso;
2. A descrição do curso não foi preenchida. Sistema exibe uma mensagem e retorna a
entrada ao campo descrição do curso;
3. Registro duplicado. Sistema exibe uma mensagem informando que já existe um
registro com a mesma identificação informada;
4. Violação de integridade referencial. Sistema exibe uma mensagem informando que a
operação não pode ser realizada indicando a violação de integridade que foi
causada;
5. Alteração de registro alterado. Sistema exibe uma mensagem informando que a
operação não pode ser realizada indicando o motivo do cancelamento da operação;
6. Alteração de registro excluído. Sistema exibe uma mensagem informando que a
7. Exclusão de registro alterado. Sistema exibe uma mensagem informando que a
8. Exclusão de registro excluído. Sistema exibe uma mensagem informando que a
operação não pode ser realizada indicando o motivo do cancelamento da operação.
Requisitos de interface:
1. O professor coordenador deve ser exibido através de uma caixa de combinação

contendo todos os professores cadastrados;
2. A quantidade de períodos deve possibilitar o incremento e decremento do número de
períodos através de componente apropriado;
3. O tipo do curso deve ser selecionado através de botões de rádio.
Pós-condições:
62
Possibilitar o cadastro de disciplinas.

Possibilitar o cadastro de alunos.
Possibilitar o cadastro de turmas.
Requisitos não funcionais:
Não aplicável.
Regras de Negócio:
RN1: Os campos obrigatórios são: código e descrição do curso;

RN2: Os tipos de curso são: Graduação, Especialização “Lato Sensu”, Mestrado e
Doutorado;
RN3: Um curso pode ter de 1 a 10 períodos letivos.
A primeira etapa para construção do fragmento proposto é a definição das

classes no ambiente Delphi, como é exemplificado na Listagem 5.1. O próximo passo é
definir o mapeamento desta classe, como apresentado na Listagem 5.2.
Listagem 5.1. Definição das Classes Curso e Professor

Curso = Class(TPersistente)
private
FID : String;
FCodigoCurso : Integer;
FDescricao : string;
FCargaHoraria : Integer;
FProfessorResponsavel : Professor;
FIDProfessorResponsavel : string;
FQuantidadePeriodo : Integer;
FTipo : Integer;
public
class function Criar() : Curso;
function Excluir(pCursoID : String) : Boolean;
procedure Persistir();
class function RecuperaObjeto(pCursoID : String) : Curso;
class function RecuperaObjetos(vDados: TClientDataSet) : TClientDataSet;
published
property id : String read FID write FID;
property codigocurso : Integer read FCodigoCurso write FCodigoCurso;
property descricao : string read FDescricao write FDescricao;
property cargahoraria : Integer read FCargaHoraria write FCargaHoraria;
property quantidadeperiodo : Integer read FQuantidadePeriodo write
FQuantidadePeriodo;
property tipo : Integer read FTipo write FTipo;
property professorresponsavel : Professor read FProfessorResponsavel write
FProfessorResponsavel;
property idprofessorresponsavel : string read FIDProfessorResponsavel write
FIDProfessorResponsavel;
end;
63
Professor = Class(Pessoa)
private
FMatriculaProfessor : Integer;
FDataAdmissao : string ;
FTitulacao : Integer;
FTipoContrato : Integer;
FValeTransporte : string;
FValeAlimentacao : string;
public
class function Criar : Professor;
class function RecuperaObjeto(pProfessorID : String) : Professor;
class function RecuperaObjetos(vDados: TClientDataSet) : TClientDataSet;
published
property matriculaprofessor : Integer read FMatriculaProfessor write
FMatriculaProfessor;
property dataadmissao : string read FDataAdmissao write FDataAdmissao;
property titulacao : Integer read FTitulacao write FTitulacao;
property tipocontrato : Integer read FTipoContrato write FTipoContrato;
property valetransporte : string read FValeTransporte write FValeTransporte;
property valealimentacao : string read FValeAlimentacao write
FValeAlimentacao;
end;
Listagem 5.2. Mapeamento Objeto-Relacional de Curso e Professor

class procedure TModelManager.StartModel(MappingManager: TdpoDBMappingManager);
begin
//Curso
with MappingManager.Classes.Add do
begin
ClassObject := Curso;
StorageName := 'Curso';
begin
AttributeName := 'id';
IsOid := True;
ColumnName := 'id';
Required := True;
Size := 38;
end;
begin
AttributeName := 'codigocurso';
IsOid := False;
ColumnName := 'codigocurso';
Required := false;
end;
begin
AttributeName := 'descricao';
IsOid := False;
ColumnName := 'descricao';
Required := false;
Size := 50;
end;
begin
AttributeName := 'cargahoraria';
IsOid := False;
ColumnName := 'cargahoraria';
Required := false;
end;
begin
64
AttributeName := 'quantidadeperiodo';
IsOid := False;
ColumnName := 'quantidadeperiodo';
Required := false;
end;
begin
AttributeName := 'tipo';
IsOid := False;
ColumnName := 'tipo';
Required := false;
end;
begin
AttributeName := 'idprofessorresponsavel';
IsOid := False;
ColumnName := 'idprofessorresponsavel';
Required := false;
Size := 38;
end;
end;
//Professor
with MappingManager.Classes.Add do
begin
ClassObject := Professor;
StorageName := 'Professor';
InheritsMappingFrom := Pessoa;
begin
AttributeName := 'id';
IsOid := True;
ColumnName := 'id';
Required := True;
Size := 38;
end;
begin
AttributeName := 'matriculaprofessor';
IsOid := False;
ColumnName := 'matriculaprofessor';
Required := false;
end;
begin
AttributeName := 'dataadmissao';
IsOid := False;
ColumnName := 'dataadmissao';
Required := false;
Size := 50;
end;
begin
AttributeName := 'titulacao';
IsOid := False;
ColumnName := 'titulacao';
Required := false;
end;
begin
AttributeName := 'tipocontrato';
IsOid := False;
ColumnName := 'tipocontrato';
Required := false;
end;
65
begin
AttributeName := 'valetransporte';
IsOid := False;
ColumnName := 'valetransporte';
Required := false;
Size := 50;
end;
begin
AttributeName := 'valealimentacao';
IsOid := False;
ColumnName := 'valealimentacao';
Required := false;
Size := 50;
end;
end;
end;
5.4.2 Operação Pesquisa de Curso

A primeira janela de interação com o usuário é a de pesquisa de curso, conforme
a Figura 5.5, onde as informações de código de curso e descrição armazenados na base de
dados são exibidas. Nesta janela há a possibilidade de realizar pesquisas através de código
e descrição, bem como realizar a ordenação dos mesmos.
Figura 5.5. Interface de Pesquisa de Curso
Basicamente, o sistema retorna uma lista de objetos do tipo curso persistentes

na base de dados. A Figura 5.6 apresenta o diagrama de seqüência da operação de
pesquisa de curso.
66
Figura 5.6. Diagrama de Seqüência da Operação Pesquisa
Na primeira interação do diagrama de seqüência é apresentada a interface de

pesquisa, através da instanciação do formulário de pesquisa de curso. No evento Activate
deste formulário, é invocado o método CarregaDados. Este método é então, o responsável
por alimentar o componente do Delphi com os dados dos cursos. Este componente é um
ListView. Respeitando o MVC, o método CarregaDados, por sua vez, executa o método
ObterCursos() do gerente de cadastro de curso (Controller), como apresentado na
Listagem 5.3. Observe que antes, é instanciado um objeto do tipo TClientDataSet e este
recebe uma estrutura, executando o método ObterEstruturaCurso() do gerente. O
ObterEstruturaCurso, como o próprio nome diz retorna uma estrutura de campos para o
ClientDataSet criado.
Listagem 5.3. Método ObterCursos

class function TGerenteCadastroCurso.ObterCursos: TClientDataSet;
var
vDados :TClientDataSet;
begin
vDados := TClientDataSet.Create(nil);
vDados := TGerente.ObterEstruturaCurso;
vDados := curso.RecuperaObjetos(vDados);
result := vDados;
end;
O método ObterCursos faz então um acesso à camada de modelo do sistema

(Model) e invoca o método RecuperaObjetos() da classe curso, passando como parâmetro
o ClientDataSet criado. Este faz acesso aos métodos do framework de persistência DePO e
67
recupera todos os objetos persistidos na base de dados relacional. O código do método

RecuperaObjetos é exibido na Listagem 5.4.
Listagem 5.4. Método RecuperaObjetos

class function Curso.RecuperaObjetos(vDados: TClientDataSet): TClientDataSet;
var
objCurso : Curso;
begin
objCurso := curso.Criar;
with dtmdlDePO.dpoDBXMechanism.CreateQuery(Curso) do
begin
Open;
First;
while not IsDone do
begin
RetrieveObject(objCurso);
//Atribuindo objtetos ao TClientDataSet
vDados.Insert;
vDados.FieldByName('id').AsString := objCurso.id;
vDados.FieldByName('codigocurso').AsInteger := objCurso.codigocurso;
vDados.FieldByName('descricao').AsString := objCurso.descricao;
vDados.FieldByName('cargahoraria').AsInteger := objCurso.cargahoraria;
vDados.FieldByName('quantidadeperiodo').AsInteger :=
objCurso.quantidadeperiodo;
vDados.FieldByName('tipo').AsInteger := objCurso.tipo;
vDados.FieldByName('professor').AsString :=
objCurso.idprofessorresponsavel;
vDados.Post;
Next;
end;
end;
result := vDados;
end;
É observado que o método acima executa a função CreateQuery do DePO, com

a classe do objeto como parâmetro. Feito isso, é então executado um laço para alimentar,
com os dados dos objetos curso recuperados, o ClientDataSet passado como parâmetro.
Feito isso, a função retorna este ClientDataSet com os dados dos objetos aninhados em sua
estrutura.
Com isso a função ObterCursos() do GerenteCadastroCurso (Controller), retorna
também este ClientDataSet para a interface (View), que alimenta assim o componente
ListView do Delphi que é apresentada para o usuário. Conclui-se então a Operação de
Pesquisa Curso.
5.4.3 Operação Incluir Curso

Exibida a tela de pesquisa, o usuário pode então incluir ou manipular (atualizar,
excluir, consultar) os objetos nela contidos. Este tópico aborda a operação de inclusão de
curso, na abordagem do sistema acadêmico.
68
O diagrama de seqüência apresentado na Figura 5.7 aborda as interações para

a operação de inclusão. Observe que, as primeiras interações compreendem os fluxos de
pesquisa de curso, acima abordadas. A Figura 5.8, apresenta a interface que o usuário
insere os dados para esta operação.
Figura 5.7. Diagrama de Seqüência da Operação Incluir Curso

69
Figura 5.8. Interface de Incluir Curso
Após a exibição da tela de pesquisa para o usuário, ele então requisita ao

sistema, através do menu ou do clique direito do mouse, a inclusão de um novo curso no
sistema. Esta ação é compreendida através da interação Incluir do diagrama de seqüência
acima apresentado.
Assim que a interação incluir é executada, o sistema exibe então a interface
necessária para a inclusão. Para isso, inicialmente é invocado o método
ObterProfessores() do GerenteCadastroCurso (Controller) pelo formulário de cadastro de
curso (View). Este executa o método da classe professor (Model) RecuperaObjetos().
Assim como no exemplo da tela de pesquisa, este método retorna um ClientDataSet com
todos os objetos professor existentes na base de dados. Todo este processo inicial é
executado para montar uma lista de professores, para que os mesmos possam ser
escolhidos como professor responsável do curso a ser incluído.
Com os dados dos professores na interface (View), o sistema alimenta um
componente do Delphi chamado ComboBox, que provê uma estrutura de escolha
compatível com a estrutura de lista. Com isso é exibida a tela ao usuário.
O usuário então, informa os dados do novo curso (código, descrição, carga
horária, professor responsável, quantidade de períodos e tipo de curso). Ao clicar no botão
Incluir, o usuário invoca o método GravaRegistro do formulário. Esta alimenta um novo
ClientDataSet com os dados incluídos pelo usuário e o passa como parâmetro para o
método GravarCampos(TClientDataSet) do GerenteCadastroCurso (Controller). Este
invoca o método Criar() do modelo (Listagem 5.5), instanciando então um objeto do tipo
curso para que o mesmo possa ter seus atributos alimentados pelo ClientDataSet passado
como parâmetro, como apresentado na Listagem 5.6. Ao final é executado o método
70
Persistir() da classe curso, definido na Listagem 5.7, que tem como objetivo salvar o objeto
na base de dados. O método GravarCampos(TClientDataSet) é usado tanto para a
persistência de um novo curso, quando para a atualização de um já existente. É efetuado
um teste que verifica se a operação solicitada é de atualização ou de criação.
Feito isso a tela de inclusão é fechada para o usuário e o sistema exibe
novamente a tela de pesquisa já com o novo curso inserido.
Listagem 5.5. Método Criar

class function Curso.Criar(): Curso;
begin
result := self.Create(dtmdlDePO.dpoDBXMechanism);
end;
Listagem 5.6. Método GravarCampos - Persistir

function GravarCampos(pParametros : TClientDataSet): Boolean;reintroduce;
begin
self.objCurso := curso.Criar;
self.objCurso.ID := objCurso.SetGUID;
//Adicionar dados do ClientDataSet
self.objCurso.codigocurso := pParametros.FieldByName('codigocurso').AsInteger;
self.objCurso.descricao := pParametros.FieldByName('descricao').AsString;
self.objCurso.cargahoraria := pParametros.FieldByName('cargahoraria').AsInteger;
self.objCurso.quantidadeperiodo:=
pParametros.FieldByName('quantidadeperiodo').AsInteger;
self.objCurso.tipo := pParametros.FieldByName('tipo').AsInteger;
//Relacionamento
self.objCurso.idprofessorresponsavel :=
pParametros.FieldByName('professor').AsString;
//Persistindo
self.objCurso.Persistir;
result := true;
end;
Listagem 5.7. Método Persistir

procedure Curso.Persistir();
begin
self.Save;
end;
5.4.4 Operação Atualizar Curso

A operação de atualizar curso ocorre quando o usuário escolhe um item da lista
exibida pela tela de pesquisa e aciona a opção Alterar. Na Figura 5.9 é exibido o diagrama
de seqüência, contendo as interações da operação de atualizar curso.
Observe que é utilizado basicamente a mesma estrutura de interações da
operação de incluir.
71
Figura 5.9. Diagrama de Seqüência da Operação Atualizar Curso
Na Figura 5.10 é exibida a interface apresentada para a atualização de algum

curso no sistema.
72
Figura 5.10. Interface de Atualizar Curso
Ao solicitar ao sistema uma alteração de curso, o sistema monta o formulário de

cadastro de curso trazendo os dados do curso a ser alterado para a janela. Esta operação é
iniciada quando o formulário de cadastro de curso (View) acessa o método Obter() do
GerenteCadastroCurso (Controller), como definido na Listagem 5.8. É passado o atributo
identificador do objeto para este método (OID). Este então invoca o método da classe curso
RecuperaObjeto() (Model), passando também o OID como parâmetro, para que este possa
recuperar o objeto na base de dados e retorná-lo para o gerente, como apresentado na
Listagem 5.9.
Listagem 5.8. Método Obter

function TGerenteCadastroCurso.Obter(pCursoId: String): Boolean;
begin
result := false;
self.objCurso := curso.RecuperaObjeto(pCursoId);
if self.objCurso <> nil then
begin
result := true;
end;
end;
Listagem 5.9. Método RecuperaObjeto

class function Curso.RecuperaObjeto(pCursoID: String): Curso;
var
objCurso : Curso;
begin
result := nil;
objCurso := curso.Criar;
objCurso.id := pCursoID;
if objCurso.Retrieve then
begin
result := objCurso;
end;
end;
73
O gerente de curso, tendo o objeto na memória, retorna para o formulário de

cadastro de curso uma variável do tipo booleana com valor verdadeiro. Com isso o
formulário invoca o método LerCampos() do gerente. Este método tem como objetivo
atribuir os atributos do objeto para um ClientDataSet e este ser devolvido como retorno para
o formulário, como exemplificado na Listagem 5.10. Com isso, o sistema monta a janela com
os dados do curso recuperado, exibindo-a e aguardando as alterações do usuário.
Listagem 5.10. Método LerCampos

function TGerenteCadastroCurso.LerCampos: TClientDataSet;
var
vDadosCampos : TClientDataSet;
begin
vDadosCampos := TClientDataSet.Create(nil);
vDadosCampos := TGerente.ObterEstruturaCurso;
vDadosCampos.Insert;
vDadosCampos.FieldByName('id').AsString := self.objCurso.id;
vDadosCampos.FieldByName('codigocurso').AsInteger := self.objCurso.codigocurso;
vDadosCampos.FieldByName('descricao').AsString := self.objCurso.descricao;
vDadosCampos.FieldByName('cargahoraria').AsInteger:= self.objCurso.cargahoraria;
vDadosCampos.FieldByName('quantidadeperiodo').AsInteger :=
self.objCurso.quantidadeperiodo;
vDadosCampos.FieldByName('tipo').AsInteger := self.objCurso.tipo;
vDadosCampos.FieldByName('professor').AsString :=
self.objCurso.idprofessorresponsavel;
vDadosCampos.Post;
result := vDadosCampos;
end;
Após o usuário efetuar suas alterações no curso recuperado, ele clica no botão
Alterar da interface. Este aciona o método GravarRegistro do formulário de cadastro de
curso (View), que invoca o método GravarCampos(TClientDataSet) do
GerenteCadastroCurso, passando como parâmetro um ClientDataSet com os dados do
objeto alterado. O GravarCampos verifica se existe um objeto na memória e o atualiza com
os dados passados por parâmetro invocando o método persistir da classe curso, como
apresentado na Listagem 5.11.
Listagem 5.11. Método GravarCampos - Atualizar

function TGerenteCadastroCurso.GravarCampos(pParametros : TClientDataSet): Boolean;
begin
self.objCurso.codigocurso := pParametros.FieldByName('codigocurso').AsInteger;
self.objCurso.descricao := pParametros.FieldByName('descricao').AsString;
self.objCurso.cargahoraria:= pParametros.FieldByName('cargahoraria').AsInteger;
self.objCurso.quantidadeperiodo :=
pParametros.FieldByName('quantidadeperiodo').AsInteger;
self.objCurso.tipo := pParametros.FieldByName('tipo').AsInteger;
self.objCurso.idprofessorresponsavel :=
pParametros.FieldByName('professor').AsString;
self.objCurso.Persistir;
result:=true;
74
5.4.5 Operação Excluir Curso

A operação excluir ocorre quando o usuário escolhe um curso e aciona a opção
excluir disponível na interface. A Figura 5.11 apresenta o diagrama de seqüência da
operação e a Figura 5.12 apresenta a interface exibida na exclusão.
Figura 5.11. Diagrama de Seqüência da Operação Excluir Curso

75
Figura 5.12. Interface de Excluir Curso
A operação de excluir executa basicamente os mesmos fluxos que a operação

de atualizar, apenas com uma diferença: Assim que o curso selecionado para exclusão é
recuperado e exibido na tela, todos os campos são desabilitados, não permitindo a alteração
do usuário.
Com isso, o usuário pode visualizar o curso escolhido antes da sua exclusão. Ao
clicar e confirmar a função de excluir, o sistema invoca o método Excluir() do
GerenteCadastroCurso (Controller), exemplificado na Listagem 5.12, que por sua vez
executa o método da classe curso Excluir() (Model), como apresentado na Listagem 5.13.
Ambos os métodos recebem como parâmetro o OID do objeto, para que o mesmo possa ser
excluído. Com isso o objeto é excluído da base de dados e destruído da memória. Após, o
sistema exibe a janela de pesquisa para o usuário atualizada.
Listagem 5.12. Método Excluir - Gerente

function TGerenteCadastroCurso.Excluir(pCursoId:String): Boolean;
begin
result := false;
try
if objCurso <> nil then
begin
result := objCurso.Excluir(pCursoId);
end;
finally
objCurso.Destroy;
end;
end;
Listagem 5.13. Método Excluir - Classe Curso

function Curso.Excluir(pCursoID: String): Boolean;
begin
self.id := pCursoID;
76
0
if self.Retrieve then
begin
self.Delete;
self.Save;
result := true;
end
else
begin
result := false;
end;
end;
5.4.6 Operação Consultar Curso

A operação de consulta de curso ocorre quando o usuário escolhe um curso na
tela de pesquisa e aciona a opção consultar. Esta operação simplesmente recupera o objeto
escolhido e o exibe na janela, como já explicado nos itens anteriores. A Figura 5.13
apresenta o diagrama de seqüência desta operação e a Figura 5.14 apresenta a interface
exibida ao usuário ao consultar um curso.
Figura 5.13. Diagrama de Seqüência da Operação Consultar Curso

77
Figura 5.14. Interface de Consultar Curso
Assim como a interface de exclusão, a interface de consulta apresenta todos os

campos desabilitados para edição do usuário.
5.5 Conclusão
Este capítulo teve como objetivo exemplificar o uso da abordagem de
mapeamento objeto-relacional para persistência em software orientado a objetos, além da
utilização do framework de persistência DePO (Delphi Persistent Objects).
Foi utilizado um sistema de controle acadêmico como estudo de caso para este
trabalho e para este capítulo foi apresentado somente um fragmento dele: Manutenção de
Cursos.
Este estudo de caso serviu também para o aprendizado e implementação de
padrões de projeto, que são soluções genéricas e reutilizáveis, aplicáveis em classes de
problemas bem conhecidos.
Foi possível também apresentar na prática as estratégias dispostas neste
trabalho, bem como sua firmação como estratégia eficiente o suficiente para dar suporte em
ambientes de desenvolvimento de grande porte.
78
6 CONSIDERAÇÕES FINAIS
Este trabalho monográfico baseou-se na análise e estudo das estratégias de
persistência de objetos para sistema gerenciadores de banco de dados relacionais
(SGBDR). Foi apresentada inicialmente uma conceituação de mapeamento objeto-relacional
e suas abordagens, além dos conceitos, aplicações e estratégias de camadas de
persistência.
Após, foi realizado um estudo exploratório sobre alguns frameworks de
persistência opensource disponíveis para o ambiente de desenvolvimento Delphi. Nele
foram apresentados os frameworks DePO (Delphi Persistent Objects), IO (Instant Objects) e
TiOPF (TechInside Object Persistent Framework). Foi observado que nenhum dos
frameworks apresentados possuem documentação sólida, muito provavelmente por se tratar
de programas de código fonte aberto (opensource).
Para finalizar este trabalho, foi proposto um estudo de caso que está inserido no
contexto do projeto de iniciação científica “Estratégias de Persistência de Software
Orientado a Objetos” da Faculdade Metodista Granbery. Projeto este que desenvolveu um
estudo sobre as técnicas de persistência de objetos, seja através de banco orientado a
objetos, camadas de persistências para armazenamento em banco de dados relacionais e
banco de dados objeto relacionais.
Este estudo de caso foi resultado de uma reengenharia de um sistema de
controle acadêmico que foi desenvolvido utilizando o paradigma estruturado. O sistema foi
re-modelado e implementado utilizando o paradigma orientado a objetos. Para o
desenvolvimento do sistema foi usado o padrão de projeto MVC (Model-View-Controller) que
busca facilitar o reuso de código fonte e substituição de estratégias de persistência, uma vez
que o sistema será base para teste de diversas estratégias.
Este trabalho também teve como objetivo a divulgação dos resultados obtidos
nas pesquisas para toda a comunidade acadêmica. A documentação completa do sistema
acadêmico pode ser vista no Anexo A deste trabalho. No CD em anexo a este trabalho é
disponibilizado o executável e o código fonte do sistema acadêmico abordado no estudo de
caso.
Como sugestão para trabalhos futuros, é sugerido um estudo exploratório e
analítico das abordagens proprietárias dos frameworks de persistência para Delphi, da
mesma forma que foi realizado neste trabalho com as abordagens opensource. Como
exemplo das abordagens proprietárias é destacado o ECO (Enterprise Core Objects), ECO
II e Bold.
Como resultados obtidos neste trabalho é destacado:
79
artigo escrito e aceito para a revista ClubeDelphi (ClubeDelphi, 2005)

intitulado “Persistência de Objetos no Delphi: Introdução ao DePO(Delphi
Persistent Objects)”;
artigo “Persistência em Software Orientado a Objetos: Abordagens Utilizando
Frameworks OpenSource” aceito para apresentação oral no III Encontro de
Software Livre do Amazonas (ESLAM, 2005) em Manaus;
apresentação oral do workshop “Persistência em Software Orientado a
Objetos: Abordagens Utilizando Frameworks OpenSource” no II Festival de
Software Livre de Juiz de Fora (FESTSOL, 2005);
apresentação do minicurso “Persistência de Objetos em Delphi – Introdução
ao Framework DePO(Delphi Persistent Objects)” como parte das atividades
da disciplina de Seminários da Faculdade Metodista Granbery;
apresentação de palestras no contexto da disciplina de Analise de Sistemas II
da Faculdade Metodista Granbery.
Por fim, é importante destacar que este trabalho contribuiu muito para a
ampliação dos conhecimentos do discente em relação às estratégias de persistência em
software orientado a objetos. O que com certeza será aplicado na sua futura vida
profissional.
80
ANEXO A – DOCUMENTAÇÃO SISTEMA ACADÊMICO
FACULDADE METODISTA GRANBERY

BACHARELADO EM SISTEMAS DE INFORMAÇÃO
SCA – Sistema de Controle Acadêmico
Juiz de Fora
2005
81
Especificação dos Requisitos do Software
SCA
82
1. Introdução:
1.1. Propósito:
O presente documento tem o objetivo de especificar e estabelecer os requisitos

para o desenvolvimento de um sistema de controle acadêmico.
1.2. Escopo:
O objetivo deste sistema é o controle acadêmico, bem como a melhoria na

organização de suas informações e facilidade de uso destas. Esse sistema deverá
permitir o cadastro de cursos, cadastro de disciplinas, cadastro de professores,
cadastro de alunos, abertura de turmas, matrícula do aluno e lançamento de
avaliação. Deverá ainda emitir relatórios de alunos por turma, disciplina por curso e
histórico escolar.
1.3. Definições e Siglas:
SCA: nome dado ao Sistema de Controle Acadêmico.

83
2. Descrição Geral:
2.1. Visão Geral do Produto:
Esse sistema tem como objetivo controlar atividades acadêmicas

administrativas, assim como a melhoria na organização e facilidade de uso de suas
informações.
2.2. Perspectivas do Produto:
• O SCA é independente.
• O sistema utilizará uma camada de persistência que irá interagir entre o produto e
o banco de dados.
• Requisitos de Software: o sistema será desenvolvido utilizando a Ferramenta de

desenvolvimento Delphi 6 (Borland). Sistema Operacional mínimo para sua
utilização deverá ser Windows 98.
2.3.Funções do Produto:
• Cadastro de Cursos
• Cadastro de Disciplinas
• Cadastro de Professores
• Cadastro de Alunos
• Cadastro de Turmas
• Matrícula de Alunos
• Cadastro de Avaliações de Alunos
• Emissão de Relatório de Alunos por Turma
• Emissão de Relatório de Disciplinas por Curso
• Emissão de Histórico Escolar
84
3. Requisitos Específicos:
3.1. Requisitos Funcionais:
Requisito Funcional 1: O sistema deve permitir à secretaria incluir, alterar,

excluir e consultar cursos, contendo os dados código, descrição, carga horária,
professor coordenador (selecionado pelo nome e representado pela matrícula do
professor), quantidade de períodos e tipos de cursos (Graduação, Especialização
“Lato Sensu”, Mestrado e Doutorado);
Requisito Funcional 2: O sistema deve permitir à secretaria pesquisar e
ordenar os cursos por código ou por descrição;
excluir e consultar as disciplinas, contendo os dados curso (selecionado pela
descrição e representado pelo respectivo código), código, descrição, período,
número de aulas, ementa e bibliografia;
Requisito funcional 4: O sistema deve permitir à secretaria pesquisar e
ordenar as disciplinas por descrição de cursos ou por descrição de disciplinas. Deve
ser permitido uma filtragem das disciplinas por cursos;
Requisito Funcional 5: O sistema deve permitir ao professor incluir, alterar,
excluir e consultar os professores, contendo os dados matrícula, nome, data de
nascimento, data de admissão, e-mail, telefone residencial, telefone comercial,
telefone celular, fotografia, status (ativo ou inativo), logradouro, número,
complemento, bairro, cidade, UF, CEP, CPF, documento de identidade (número,
órgão expedidor, UF e data expedição), titulação máxima (graduação,
especialização, mestrado e doutorado), tipo de contrato (substituto, auxiliar,
assistente ou adjunto), benefícios (vale transporte e/ou vale alimentação) e alocação
das disciplinas lecionadas pelo professor (selecionadas pela descrição e
representadas pelos respectivos código);
Requisito Funcional 6: O sistema deve permitir ao professor pesquisar e
ordenar os professores por matrícula ou por nome do professor;
Requisito Funcional 7: O sistema deve permitir ao aluno incluir, alterar, excluir
e consultar alunos contendo os dados matrícula, nome, data de nascimento, curso
(selecionado pela descrição e representado pelo respectivo código), ano de início,
semestre de início, e-mail, telefone residencial, telefone comercial, telefone celular,
fotografia, logradouro, número, complemento, bairro, cidade, UF, CEP, CPF,
documento de identidade (número, órgão expedidor, UF e data expedição) e status
(ativo ou inativo);
Requisito Funcional 8: O sistema deve permitir ao aluno pesquisar e ordenar
os alunos por matrícula ou nome do aluno;
excluir e consultar as turmas, contendo os dados curso (selecionado pela descrição e
representado pelo respectivo código), disciplina (selecionada pela descrição e
representada pelo respectivo código), ano, semestre, descrição da turma, número
máximo de alunos e professor responsável (selecionado pelo nome e representado
pelo respectivo número de matrícula);
Requisito Funcional 10: O sistema deve permitir à secretaria pesquisar e
ordenar as turmas por descrição de curso, descrição de disciplina, ano, semestre ou
turma. O sistema deverá permitir à secretaria filtrar a lista de turmas, apenas, a partir
dos dados descrição de curso, descrição de disciplina, ano e semestre;
Requisito Funcional 11: O sistema deve permitir ao aluno incluir e alterar a
matrícula contendo dados para selecionar a turma (selecionada pela descrição e
representada pelo respectivo código) e os alunos (selecionado pelo nome e
85
representado pelo respectivo número de matrícula). Um aluno deve possuir apenas

uma matricula;
Requisito Funcional 12: O sistema deve permitir ao aluno pesquisar e ordenar
as matrículas por descrição de curso, descrição de disciplina, ano, semestre ou
turma. O sistema deverá permitir ao aluno filtrar a lista de turmas disponíveis para
efetuar matrícula, apenas, a partir dos dados descrição de curso, descrição de
disciplina, ano e semestre;
Requisito Funcional 13: O sistema deve permitir ao professor incluir, alterar e
consultar a avaliações contendo os dados para selecionar a turma (selecionada pela
descrição e representada pelo respectivo código) e os alunos (selecionados pelos
respectivos nomes e representados pelos números de matrícula correspondentes)
em uma lista, podendo, assim, inserir ou alterar os dados: faltas, avaliação1,
avaliação2 e avaliação final;
Requisito Funcional 14: O sistema deve permitir ao professor pesquisar e
ordenar as avaliações por descrição de curso, descrição de disciplina, ano, semestre
ou turma. O sistema deverá permitir o professor filtrar a lista de turmas disponíveis
para efetuar lançamento de avaliação, apenas, a partir dos dados descrição de
curso, descrição de disciplina, ano e semestre;
Requisito Funcional 15: O sistema deve permitir ao professor a emissão da
relação de alunos por turmas, contendo descrição do curso, descrição da disciplina,
ano, semestre, descrição da turma, nome do professor, matrícula do aluno e nome
do aluno;
Requisito Funcional 16: O sistema deve permitir à secretaria a emissão da
relação de disciplinas por curso, contendo nome do curso, nome das disciplinas, total
de disciplinas por curso, total de cursos e total de todas as disciplinas;
Requisito Funcional 17: O sistema deve permitir ao aluno a emissão do
histórico escolar, contendo matrícula do aluno, nome do aluno, ano, semestre,
descrição da turma, nome das disciplinas, número de aulas, número de faltas,
avaliação 1, avaliação 2 e avaliação final;
Requisito Funcional 18: o sistema não deve permitir ordenação composta (por
mais de um campo) em suas listagens.
3.2. Requisitos não-funcionais:
Requisito não funcional 1: O sistema deve ser totalmente aderente aos

principais conceitos de Orientação a Objeto (encapsulamento, herança, polimorfismo,
tipificação forte, etc.).
Requisito não funcional 2: O sistema deve possuir a estrutura cliente/servidor.
Requisito não funcional 3: O sistema deve tratar a concorrência para inserir,
deletar e atualizar registros no banco de dados.
Requisito não funcional 4: O sistema deve utilizar o banco de dados relacional
Interbase 6.0, da Borland – instalado no servidor.
Requisito não funcional 5: O sistema deve possibilitar que todos os relatórios
sejam pré-visualizados antes do envio para a impressora.
Requisito não funcional 6: O sistema deve apresentar o recurso de ajuda on-
line sensível ao contexto de seu uso;
Requisito não funcional 7: O sistema deve utilizar a ferramenta QuickReports
para a geração de relatórios;
Requisito não funcional 8: O sistema deve apresentar, durante sua abertura,
uma tela de apresentação que permanece por poucos segundos visível, exibindo
nome do sistema e número da versão atual;
86
Requisito não funcional 9: O sistema deve apresentar uma tela que exibe os
dados sobre o desenvolvimento do sistema. Os dados serão: nome do sistema,
número da versão atual, data da versão atual, nome do autor e e-mail para contato;
Requisito não funcional 10: O sistema deve apresentar, em sua tela principal,
a data atual, o nome do autor e a hora atual, num painel encontrado no rodapé dessa
interface.
87
Casos de Uso
SCA
88
4. Diagrama de Caso de Uso:
Cadastrar Alunos
Aluno
Matricular Alunos
Emitir Histórico Escolar
Cadastrar Professor
Lançar Avaliações
Professor
Emitir Relatório de Aluno por
Turma
Cadastrar Cursos
Cadastrar Disciplina
Secretaria
Cadastrar Turmas
Emitir Relatório Disciplina

por Curso
89
5. Especificação de Casos de Uso
Caso de Uso 01: Manutenção de Cursos
Ator Principal:
Secretaria
Sumário:
cadastro de curso, selecionando a opção a partir de uma interface de pesquisa de curso,
informando os dados do mesmo. O objetivo deste caso de uso é possibilitar que ocorra a
inclusão de cursos no sistema, a consulta, a alteração ou a exclusão daqueles já existentes.
Pré-Condições:
Não Aplicável.
Fluxo Principal:
1. A secretaria solicita ao sistema o cadastro de cursos;
2. O sistema exibe uma lista com os cursos cadastrados, contendo código e descrição
do curso, ordenada alfabeticamente pela descrição do curso;
3. O sistema solicita a opção de inclusão de um novo curso ou alteração, exclusão ou
consulta de um curso selecionado;
ordenar pela descrição do curso ou pela descrição da disciplina;
pesquisar pela descrição da disciplina ou pela descrição do curso. A pesquisa não
deve ignorar letras maiúsculas e minúsculas;
3. A secretaria pode filtrar as disciplinas exibidas selecionando o curso desejado
através de sua descrição;

e representado pelo código), código, descrição, período, número de aulas, ementa e
bibliografia;
Subfluxo: Operação Persquisar

90
1. O sistema exibe a interface com uma lista de todos os cursos disponíveis,

compreendendo: código e nome de curso;

1. O sistema exibe a interface com todos os campos habilitados, exceto o código do
curso;
4. Sistema solicita a modificação nos seguintes dados;
excluído);

3. Sistema exibe os dados nos respectivos campos;
excluído);

perda de dados.
1. O código do curso não foi preenchido. Sistema exibe uma mensagem e retorna a
entrada ao campo código do curso;
2. A descrição do curso não foi preenchida. Sistema exibe uma mensagem e retorna a
entrada ao campo descrição do curso;
91

causada;
1. O professor coordenador deve ser exibido através de uma caixa de combinação
contendo todos os professores cadastrados;
2. A quantidade de períodos deve possibilitar o incremento e decremento do número de
períodos através de componente apropriado;
3. O tipo do curso deve ser selecionado através de botões de rádio.
Pós-condições:
Possibilitar o cadastro de disciplinas.
Possibilitar o cadastro de alunos.
Possibilitar o cadastro de turmas.

Não aplicável.
Regras de Negócio:
RN1: Os campos obrigatórios são: código e descrição do curso;
RN2: Os tipos de curso são: Graduação, Especialização “Lato Sensu”, Mestrado e
Doutorado;
RN3: Um curso pode ter de 1 a 10 períodos letivos.
Caso de Uso 02: Cadastrar Disciplinas
Ator Principal:
Secretaria
Sumário:
cadastro de disciplinas, selecionando a opção a partir da interface contém uma listagem de
disciplinas cadastradas e, posteriormente, informando os dados da mesma. O objetivo deste
caso de uso é possibilitar que ocorra a inclusão de disciplinas no sistema, a consulta, a
alteração ou a exclusão daquelas já existentes.
Pré-Condições:
Curso cadastrado.
Fluxo Principal:
1. A secretaria solicita ao sistema o cadastro de disciplinas;
2. O sistema exibe uma lista com as disciplinas cadastradas, contendo descrição do
curso e descrição da disciplina, ordenada, crescentemente, pela descrição do curso;
92
3. O sistema solicita a opção de inclusão de uma nova disciplina, alteração, exclusão

ou consulta de uma disciplina selecionada na lista;
ordenar pelo código ou pela descrição da mesma.
pesquisar pelo código ou pela descrição da disciplina. A pesquisa não necessita ser
exata, sendo feita a partir do início do campo pesquisado. A pesquisa deve ignorar
letras maiúsculas e minúsculas.

3. O sistema solicita a entrada dos seguintes dados: código, descrição, curso, período,
número de aulas, ementa e bibliografia;
7. O sistema efetua a validação dos campos (RN1, RN2);

1. O sistema exibe a interface com todos os campos habilitados, exceto o código da
disciplina e o curso ao qual ela se relaciona;
2. O sistema efetua a leitura do registro a partir do código da disciplina selecionada;
3. Sistema exibe os dados: curso (visualizado pelo nome e representado pelo código),
código, descrição, período, número de aulas, ementa e bibliografia;
4. Sistema solicita a modificação nos dados apresentados (exceto código e curso);
excluído);

3. Sistema exibe os dados da disciplina nos respectivos campo;.
excluído);
93

3. Sistema exibe os dados: código, descrição, curso, período, número de aulas, ementa
e bibliografia; em seus respectivos campos;
perda de dados.
1. O código da disciplina não foi preenchido. O sistema exibe uma mensagem e retorna
a entrada ao campo código do curso;
2. A descrição da disciplina não foi preenchida. O sistema exibe uma mensagem e
retorna a entrada ao campo descrição da disciplina;
3. O curso da disciplina não foi selecionado. O sistema exibe uma mensagem e retorna
a entrada ao respectivo campo;
causada;
1. O curso deve ser exibido através de uma caixa de combinação contendo todos os
cursos cadastrados;
2. O campo de período da disciplina deve possibilitar o incremento e decremento do
valor do mesmo através de componente apropriado;
3. A ementa da disciplina deve ter sua entrada a partir de um controle para digitar
textos em mais de uma linha;
4. A bibliografia da disciplina deve ter sua entrada a partir de um controle para digitar
textos em mais de uma linha.
Pós-condições:
Possibilitar o cadastro de turmas;
Possibilitar emissão do relatório disciplinas por curso.
94

Não aplicável.
Regras de Negócio:
RN1: Os campos obrigatórios são: código e descrição da disciplina, curso, período,
número de aulas e ementa;
RN2: O período da disciplina deve ser no mínimo 1 e no máximo o total de períodos do
curso selecionado.
Caso de Uso 03: Cadastrar Professores
Ator Principal:
Professor
Sumário:
Este caso de uso é iniciado pelo professor quando ele requisita ao sistema um
cadastro de professor, informando todos os dados, selecionando a opção correspondente a
partir da interface, exibida previamente, que contém uma listagem dos professores
cadastrados. O objetivo deste caso de uso é possibilitar que ocorra a inclusão de
professores no sistema, a consulta, a alteração ou a exclusão daqueles já existentes.
Pré-Condições:
Não aplicável.
Fluxo Principal:
1. O professor solicita ao sistema o cadastro de professores;
2. O sistema exibe uma lista com os professores cadastrados, contendo matrícula e
nome do mesmo, ordenada, crescentemente, pela matrícula do professor;
3. O sistema solicita a opção de inclusão de um novo professor, alteração, exclusão ou
consulta de um professor selecionado na lista;
4. O professor informa a opção desejada.
5. O sistema executa o subfluxo correspondente ao tipo de operação escolhido (Incluir,
Alterar, Excluir, Consultar).
1. O professor pode modificar a ordenação da lista de professores cadastrados,
podendo ordenar pela matrícula ou pelo nome do mesmo.
2. O professor pode efetuar uma pesquisa na lista de professores cadastrados,
podendo pesquisar pela matrícula ou pelo nome do professor. A pesquisa não
deve ignorar letras maiúsculas e minúsculas.
3. O professor pode cancelar a operação de cadastramento, fechando a interface.

3. O sistema solicita a entrada dos seguintes dados: matrícula, nome, data de
nascimento, data de admissão, e-mail, telefone residencial, telefone comercial,
telefone celular, fotografia, status (ativo ou inativo), coordenador (sim ou não),
logradouro, número, complemento, bairro, cidade, UF, CEP, CPF, documento de
identidade (número, órgão expedidor, UF e data expedição), titulação máxima
(graduação, especialização, mestrado e doutorado), tipo de contrato (substituto,
95
auxiliar, assistente ou adjunto), benefícios (vale transporte e/ou vale alimentação) e

alocação das disciplinas lecionadas pelo professor (selecionadas pela descrição e
representadas pelos respectivos código);
4. O professor informa ao sistema os dados solicitados;
6. O professor confirma operação;

1. O sistema exibe a interface com todos os campos habilitados, exceto a matrícula do
professor;
2. O sistema efetua a leitura do registro a partir da matrícula do professor selecionado;
3. O sistema exibe os dados: matrícula, nome, data de nascimento, data de admissão,
e-mail, telefone residencial, telefone comercial, telefone celular, fotografia, status
(ativo ou inativo), coordenador (sim ou não), logradouro, número, complemento,
bairro, cidade, UF, CEP, CPF, documento de identidade (número, órgão expedidor,
UF e data expedição), titulação máxima (graduação, especialização, mestrado e
doutorado), tipo de contrato (substituto, auxiliar, assistente ou adjunto), benefícios
(vale transporte e/ou vale alimentação) e alocação das disciplinas lecionadas pelo
professor (selecionadas pela descrição e representadas pelos respectivos código);
4. O sistema solicita a modificação nos dados apresentados (exceto a matrícula);
5. O professor altera os campos;
7. O professor confirma a operação;
excluído);

3. O sistema exibe os dados do professor nos respectivos campos;
5. O professor confirma a operação;
excluído);

3. O sistema exibe os dados: matrícula, nome, data de nascimento, data de admissão,
e-mail, telefone residencial, telefone comercial, telefone celular, fotografia, status
(ativo ou inativo), coordenador (sim ou não), logradouro, número, complemento,
bairro, cidade, UF, CEP, CPF, documento de identidade (número, órgão expedidor,
UF e data expedição), titulação máxima (graduação, especialização, mestrado e
doutorado), tipo de contrato (substituto, auxiliar, assistente ou adjunto), benefícios
96
(vale transporte e/ou vale alimentação) e alocação das disciplinas lecionadas pelo
professor (selecionadas pela descrição e representadas pelos respectivos código);
4. O professor fecha a interface.
1. O professor cancela a operação de inclusão. O sistema exibe novamente todos os
2. O professor cancela a operação de alteração. O sistema exibe novamente os dados
3. O professor fecha a interface durante as operações de inclusão ou alteração. Caso
perda de dados.
1. A matrícula do professor não foi preenchida. O sistema exibe uma mensagem e
retorna a entrada ao campo código do curso;
2. O nome do professor não foi preenchido. O sistema exibe uma mensagem e retorna
a entrada ao campo nome do professor;
causada;
1. Os dados data de nascimento, data de admissão e data de expedição devem estar
dispostos em controles de texto apropriados para utilização de máscara de data
“__/__/____”;
2. Os dados de telefone residencial, comercial e celular devem estar dispostos em
controles de texto apropriados para aplicação de máscara para número de telefone
“(__)____-____”;
3. CEP deve estar disposto em controle de texto que possibilite a implementação da
máscara “_____-___”;
4. CPF do professor deve estar disposto em controle de texto apropriado para a
aplicação da máscara “_________-__”;
5. Os cursos disponíveis devem estar dispostos num controle de lista para exibição da
sua descrição;
6. Os cursos em que o professor leciona devem estar dispostos num controle de lista
para exibição de sua descrição;
7. A alocação ou remoção de alocação de cursos para um professor devem se dar por
meio de comando de botão, para execução da ação apropriada, após selecionar a
lista; ou, então, através da técnica de arrastar a linha selecionada de uma lista para a
outra lista;
8. A foto do professor deve ser exibida em componente apropriado para exibição de
imagens;
97
9. As UFs devem ser exibidas em uma caixa de combinação;

10. A titulação máxima do professor deve estar disposta em grupo de botões de rádio;
11. tipo de contrato do professor deve estar disposto em grupo de botões de rádio;
12. Os benefícios possíveis ao professor devem estar dispostos em caixas de
verificação, agrupadas em painel;
13. Os dados data de nascimento e data de expedição devem ser informados seguindo o
formato “dd/mm/yyyy”.
Pós-condições:
Possibilitar o cadastro de turmas;
Possibilitar emissão do relatório disciplinas por curso.

Não aplicável.
Regras de Negócio:
RN1: Os campos obrigatórios são: matrícula e nome do professor;
RN2: Quanto à titulação do professor, devem ser respeitados os seguintes aspectos:
• Caso a titulação seja graduação, o professor poderá exercer apenas do tipo de
contrato substituto sem direito a benefícios;
• Caso a titulação seja especialização, o professor poderá exercer os tipos de
contrato substituto e auxiliar, podendo, ainda, gozar do benefício do vale
transporte;
• Caso a titulação seja mestrado, o professor poderá exercer os tipos de contrato
substituto, auxiliar e assistente e, ainda, gozar do benefício de vale alimentação;
• Caso a titulação seja doutorado, o professor poderá exercer os tipos de contrato
substituto, auxiliar, assistente e adjunto e gozar dos benefícios vale transporte e
vale refeição.
Caso de Uso 04: Cadastrar Aluno
Ator Principal:
Aluno
Sumário:
Este caso de uso é iniciado pelo aluno quando ele requisita ao sistema um cadastro
de aluno, informando todos os dados, selecionando a opção correspondente a partir da
interface, exibida previamente, que contém uma listagem dos alunos cadastrados. O
objetivo deste caso de uso é possibilitar que ocorra a inclusão de alunos no sistema, a
consulta, a alteração ou a exclusão daqueles já existentes.
Pré-Condições:
Não aplicável.
Fluxo Principal:
1. O aluno solicita ao sistema o cadastro de alunos;
2. O sistema exibe uma lista com os alunos cadastrados, contendo matrícula e nome
do mesmo, ordenada, crescentemente, pelo nome do aluno;
3. O sistema solicita a opção de inclusão de um novo aluno, alteração, exclusão ou
consulta de um aluno selecionado na lista;
4. O aluno informa a opção desejada;
98

1. O aluno pode modificar a ordenação da lista de alunos cadastrados, podendo
ordenar, crescentemente, pela matrícula ou pelo nome do mesmo.
2. O aluno pode efetuar uma pesquisa na lista de alunos cadastrados, podendo
pesquisar pela matrícula ou pelo nome do aluno. A pesquisa não necessita ser
exata, sendo feita a partir do início do campo pesquisado. A pesquisa deve ignorar
letras maiúsculas e minúsculas.
3. O aluno pode cancelar a operação de cadastramento, fechando a interface.

3. O sistema solicita a entrada dos seguintes dados: matrícula, nome, data de
nascimento, curso, ano de início, semestre de início, e-mail, telefone residencial,
telefone comercial, telefone celular, fotografia, status (ativo ou inativo), logradouro,
número, complemento, bairro, cidade, UF, CEP, CPF, documento de identidade
(número, órgão expedidor, UF e data expedição);
4. O aluno informa ao sistema os dados solicitados;
6. O aluno confirma operação;

1. O sistema exibe a interface com todos os campos habilitados, exceto a matrícula do
professor;
3. Sistema exibe os dados: matrícula, nome, data de nascimento, curso, ano de início,
fotografia, status (ativo ou inativo), logradouro, número, complemento, bairro, cidade,
UF, CEP, CPF, documento de identidade (número, órgão expedidor, UF e data
expedição);
4. Sistema solicita a modificação nos dados apresentados (exceto a matrícula);
5. O aluno altera os campos;
7. O aluno confirma a operação;
excluído);

2. O sistema efetua a leitura do registro a partir da matrícula do aluno selecionado;
3. Sistema exibe os dados do aluno nos respectivos campos;
5. O aluno confirma a operação;
99

excluído);

2. O sistema efetua a leitura do registro a partir da matrícula do aluno selecionado;
3. Sistema exibe os dados: matrícula, nome, data de nascimento, curso, ano de início,
fotografia, status (ativo ou inativo), logradouro, número, complemento, bairro, cidade,
UF, CEP, CPF, documento de identidade (número, órgão expedidor, UF e data
expedição);
4. O aluno fecha a interface.
1. O aluno cancela a operação de inclusão. O sistema exibe novamente todos os
2. O aluno cancela a operação de alteração. O sistema exibe novamente os dados
3. O aluno fecha a interface durante as operações de inclusão ou alteração. Caso
perda de dados.
1. A matrícula do aluno não foi preenchida. O sistema exibe uma mensagem e retorna
a entrada ao campo código do curso;
2. O nome do aluno não foi preenchido. O sistema exibe uma mensagem e retorna a
entrada ao campo nome do aluno;
causada;
1. Os dados data de nascimento e data de expedição devem estar dispostos em
controles de texto apropriados para utilização de máscara de data “__/__/____”;
2. Os dados de telefone residencial, comercial e celular devem estar dispostos em
controles de texto apropriados para aplicação de máscara para número de telefone
“(__)____-____”;
3. O CEP deve estar disposto em controle de texto que possibilite a implementação da
máscara “_____-___”;
4. O CPF do professor deve estar disposto em controle de texto apropriado para a
aplicação da máscara “_________-__”;
100
5. A foto do aluno deve ser exibida em componente apropriado para exibição de

imagens;
6. As UFs devem ser exibidas em uma caixa de combinação;
7. Os dados data de nascimento e data de expedição devem ser informados seguindo o
formato “dd/mm/yyyy”.
Pós-condições:
Possibilitar matrícula de alunos;
Possibilitar emissão do relatório de histórico escolar;
Possibilitar emissão do relatório de alunos por turma.

Não aplicável.
Regras de Negócio:
RN1: Os campos obrigatórios são: matrícula e nome do aluno;
RN2: Caso seja informado, o ano letivo deve conter apenas 4 dígitos;
RN3: Para semestre de início deve ser admitido apenas os valores 1 e 2, que ser
referem, respectivamente, ao primeiro e segundo semestre de um ano. Deve ser
composto, portanto, por um dígito apenas.
Caso de Uso 05: Cadastrar Turma
Ator Principal:
Secretaria
Sumário:
cadastro de turma, informando todos os dados, selecionando a opção correspondente a
partir da interface, exibida previamente, que contém uma listagem das turmas cadastradas.
O objetivo deste caso de uso é possibilitar que ocorra a inclusão de turmas no sistema, a
consulta, a alteração ou a exclusão daquelas já existentes.
Pré-Condições:
1. Curso cadastrado;
2. Disciplina cadastrada;
3. Professor cadastrado.
Fluxo Principal:
1. A secretaria solicita ao sistema o cadastro de turmas;
2. O sistema exibe uma lista com as turmas cadastradas, contendo descrição do curso,
descrição da disciplina, ano, semestre e descrição da turma; ordenada,
alfabeticamente, pela descrição do curso;
3. O sistema solicita a opção de inclusão de uma nova turma, alteração, exclusão ou
consulta de uma turma selecionada na lista;
101
1. A secretaria pode modificar a ordenação da lista de turmas cadastradas, podendo

ordenar, crescentemente, pela descrição do curso, descrição da disciplina, ano,
semestre e descrição da turma;
2. A secretaria pode efetuar uma pesquisa na lista de turmas cadastradas, podendo
pesquisar pela descrição do curso, descrição da disciplina, ano, semestre e
descrição da turma;

e representado pelo código), disciplina (selecionada pela descrição e representada
pelo código), descrição da turma, ano, semestre, número máximo de alunos e
professor responsável (selecionado pelo nome e representado pelo respectivo
código);
7. O sistema efetua a validação dos campos (RN1, RN2, RN3, RN4);

1. O sistema exibe a interface com todos os campos habilitados, exceto curso,
disciplina, ano, semestre e descrição da turma;
2. O sistema efetua a leitura do registro a partir do identificador da turma selecionada
na lista da interface de pesquisa;
3. Sistema exibe os dados: curso (selecionado pela descrição e representado pelo
código), disciplina (selecionada pela descrição e representada pelo código),
descrição da turma, ano, semestre, número máximo de alunos e professor
responsável (selecionado pelo nome e representado pelo respectivo código);
4. Sistema solicita a modificação nos dados apresentados (curso, disciplina, ano,
semestre e descrição da turma);
8. O sistema efetua a validação dos campos (RN1, RN2, RN3, RN4);
excluído);

2. O sistema efetua a leitura do registro a partir do identificador da turma, respectivo
àquela selecionada na interface de pesquisa;
3. O sistema exibe os dados da turma nos respectivos campos;
excluído);
102


2. O sistema efetua a leitura do registro a partir do identificador da turma, respectivo
àquela selecionada na interface de pesquisa;
3. O sistema exibe os dados: curso (selecionado pela descrição e representado pelo
código), disciplina (selecionada pela descrição e representada pelo código),
descrição da turma, ano, semestre, número máximo de alunos e professor
responsável (selecionado pelo nome e representado pelo respectivo código);
perda de dados.
1. O curso, ao qual à turma pertence, não foi selecionado. O sistema exibe uma
mensagem e retorna a entrada ao campo de seleção do curso;
2. A disciplina, ao qual à turma pertence, não foi selecionada. O sistema exibe uma
mensagem e retorna a entrada ao campo de seleção da disciplina;
3. O ano de abertura da turma não foi informado. O sistema exibe uma mensagem e
retorna a entrada ao campo de ano de abertura;
4. O semestre de abertura da turma não foi informado. O sistema exibe uma mensagem
e retorna a entrada ao campo de semestre de abertura;
5. A descrição da turma não foi preenchida. O sistema exibe uma mensagem e retorna
a entrada ao campo descrição da turma;
6. O professor responsável da turma não foi selecionado. O sistema exibe uma
mensagem e retorna a entrada ao campo de seleção do professor responsável;
causada;
1 Os dados curso, disciplina e professor responsável devem ser exibidos, cada qual,
em caixa de combinação.
103
Pós-condições:
1. Possibilitar matrícula de alunos;
2. Possibilitar emissão do relatório de histórico escolar;
3. Possibilitar emissão do relatório de alunos por turma.

Não aplicável.
Regras de Negócio:
RN1: Os campos obrigatórios são: curso, disciplina, ano, semestre, descrição da turma e
professor responsável;
RN2: O ano deve conter apenas 4 dígitos;
RN3: Para semestre de início deve ser admitido apenas os valores 1 e 2, que ser
referem, respectivamente, ao primeiro e segundo semestre de um ano. Deve ser
composto, portanto, por um dígito apenas;
RN4: A descrição da turma deve possuir no máximo 10 caracteres.
Caso de Uso 06: Matricular Alunos
Ator Principal:
Aluno
Sumário:
Este caso de uso é iniciado pelo aluno quando ele requisita ao sistema matricular
alunos, informando todos os dados, selecionando a turma correspondente a partir da
interface, exibida previamente, que contém uma listagem das turmas cadastradas. O
objetivo deste caso de uso é possibilitar que ocorra a matrícula de alunos em turmas, no
sistema, a modificação da lista de alunos matriculados na turma selecionada e, por
conseqüência, a remoção da matrícula de alunos da turma selecionada.
Pré-Condições:
1. Turma cadastrada;
2. Aluno cadastrado.
Fluxo Principal:
1. O aluno solicita ao sistema a matrícula de alunos;
3. O sistema solicita a opção de matricular alunos a partir da seleção de uma turma na
lista de turmas disponibilizada;
4. O aluno seleciona a opção de matricular alunos;
5. O sistema exibe a interface de matrícula com lista de alunos e o campo de pesquisa
de alunos habilitado;
6. O sistema preenche a interface de matrícula com os dados curso, disciplina, ano,
semestre, turma, lista de alunos (matriculados ou não), professor responsável, total
de vagas e vagas restantes;
7. O sistema solicita a matrícula de alunos ou a remoção de matrícula daqueles que
estiverem cadastrados;
8. O aluno marca a caixa de verificação, na lista, correspondente para cada aluno que
de seja matricular RN1;
104
9. O aluno desmarca a caixa de verificação correspondente para cada aluno que deseja
remover matrícula;
10. O sistema solicita confirmação da lista de matrícula configurada;
11. O aluno confirma os dados;
12. O sistema efetua validação dos campos RN2;
13. O sistema executa críticas de integridade referencial e acesso concorrente;
1. O aluno pode modificar a ordenação da lista de turmas cadastradas, podendo
2. O aluno pode efetuar uma pesquisa na lista de turmas cadastradas, podendo
3. O aluno pode filtrar a lista de turmas disponibilizada, na interface de pesquisa,
através do curso, disciplina, ano e semestre, necessariamente nessa ordem, de
acordo com a demanda desejada;
4. O aluno pode cancelar a operação de matrícula, fechando a interface;
5. O aluno pode pesquisar a lista de alunos disponível, na interface de matrícula, pela
matrícula ou pelo nome do aluno. A pesquisa não precisa ser exata, podendo ser
executada a partir do primeiro caractere do campo selecionado;
6. O aluno pode ordenar, crescentemente, a lista de alunos disponível na interface de
matrícula pelo número de matrícula ou pelo nome do aluno;
7. O aluno cancela a operação de matrícula. O sistema exibe novamente todos os
campos de entrada no seu estado original;
8. O aluno fecha a interface durante a operação de matrícula. Caso tenha ocorrido
modificação de informações, o sistema avisa da possibilidade de perda de dados;
causada;
1. Os alunos devem ser exibidos em uma lista com caixa de verificação para efetuar
matrícula ou remover a matrícula.
Pós-condições:
Possibilitar emissão do relatório de histórico escolar;
Possibilitar emissão do relatório de alunos por turma.

105
Não aplicável.
Regras de Negócio:
RN1: Durante a seleção dos alunos para efetuar matrícula, se o total de alunos
selecionados superar o número máximo de alunos admitidos por turma, a operação deve
ser permitida, porém o sistema deverá emitir o aviso pertinente;
RN2: O aluno deve possuir apenas uma matrícula.
Caso de Uso 07: Avaliação de Alunos
Ator Principal:
Professor
Sumário:
Este caso de uso é iniciado pelo professor quando ele requisita ao sistema avaliar
alunos matriculados em uma turma, informando todos os dados, selecionando a turma
correspondente a partir da interface, exibida previamente, que contém uma listagem das
turmas cadastradas. O objetivo deste caso de uso é possibilitar que ocorra o lançamento de
avaliação para alunos de uma turma, no sistema.
Pré-Condições:
2. Aluno matriculado.
Fluxo Principal:
1. O professor solicita ao sistema a avaliação de alunos;
3. O sistema solicita a opção de avaliar alunos a partir da seleção de uma turma na lista
de turmas disponibilizada;
4. O professor seleciona a opção de matricular alunos;
5. O sistema exibe a interface de matrícula com lista de alunos e o campo de pesquisa
de alunos habilitado;
6. O sistema preenche a interface de avaliação da turma com os dados curso,
disciplina, ano, semestre, turma, lista de alunos matriculados e professor
responsável;
7. O sistema solicita o lançamento de avaliação dos alunos;
8. O professor seleciona o aluno para lançara a avaliação;
9. O professor solicita a exibição da interface de lançamento da avaliação do aluno;
10. O sistema exibe a interface de avaliação do aluno, preenchendo-a com os dados
curso, disciplina, ano, semestre, turma, matrícula do aluno e nome do aluno,
deixando-os desabilitados. São disponibilizados os campos faltas, avaliação 1,
avaliação 2 e avaliação final;
11. O professor informa os dados da avaliação do aluno;
12. O sistema solicita confirmação da avaliação lançada;
13. O professor confirma a avaliação lançada (RN1, RN2, RN3, RN4);
14. O sistema armazena os dados da avaliação;
15. O professor fecha a interface de avaliação.
106
1. O professor pode modificar a ordenação da lista de turmas cadastradas, podendo
2. O professor pode efetuar uma pesquisa na lista de turmas cadastradas, podendo
3. O professor pode filtrar a lista de turmas disponibilizada, na interface de pesquisa,
através do curso, disciplina, ano e semestre, necessariamente nessa ordem, de
acordo com a demanda desejada;
4. O professor pode cancelar a operação de avaliação, fechando a interface;
5. O professor pode pesquisar a lista de alunos disponível, na interface de avaliação da
turma, pela matrícula ou pelo nome do aluno. A pesquisa não precisa ser exata,
podendo ser executada a partir do primeiro caractere do campo selecionado;
6. O professor pode ordenar, crescentemente, a lista de alunos disponível na interface
de avaliação de turmas pelo número de matrícula ou pelo nome do aluno;
7. O professor pode cancela a digitação da avaliação do aluno selecionado, caso haja
alguma modificação quanto aos dados anteriores, o estado original é restaurado;
8. O professor fecha a interface de avaliação do aluno. Se houve alguma modificação
nos dados, o sistema avisa que os dados serão perdidos;
9. O professor fecha a interface durante a operação de matrícula. Caso tenha ocorrido
modificação de informações, o sistema avisa da possibilidade de perda de dados;
causada;
1. Os alunos devem ser exibidos, na interface de avaliação da turma, em uma lista com
os dados matrícula, nome e os dados faltas, avaliação 1, avaliação 2 e avaliação
final;
2. Na avaliação dos alunos, os dados faltas, avaliação 1, avaliação 2 e avaliação final
devem ser disponibilizados por meio de caixas de texto.
Pós-condições:
Possibilitar emissão do relatório de histórico escolar.

Não aplicável.
Regras de Negócio:
RN1: Os dados faltas, avaliação 1, avaliação 2 e avaliação final devem são valores
numéricos;
107
RN2: Os dados avaliação 1, avaliação 2 e avaliação final devem são valores numéricos
podem assumir até 2 casas decimais;
RN3: As faltas podem assumir qualquer valor inteiro, positivo, entre 0 e 999;
RN4: Os dados avaliação 1, avaliação 2 e avaliação final devem são valores numéricos
podem assumir qualquer valor decimal, positivo, entre 0 e 10.
Caso de Uso 08: Relatório de Disciplinas por Curso
Ator Principal:
Secretaria
Sumário:
Este caso de uso é iniciado pela secretaria quando ela deseja visualizar as
disciplinas cadastradas em cada curso. O objetivo deste caso de uso é possibilitar que
ocorra emissão de um relatório de disciplinas por curso, previamente visualizado em tela e,
depois, podendo ser impresso e/ou exportado.
Pré-Condições:
1. Curso cadastrado;
2. Disciplina cadastrada.
Fluxo Principal:
1. A secretaria solicita, no menu Relatórios, ao sistema a emissão do relatório de
disciplinas por curso;
2. O sistema seleciona os dados descrição do curso e descrição da disciplina,
devidamente relacionados e ordenados, crescentemente, com essa mesma
precedência;
3. O sistema exibe o relatório composto de cabeçalho (contendo nome do sistema,
nome do relatório, data de emissão, logomarca do sistema, e cabeçalho dos dados a
sem exibidos);
4. O sistema exibe a descrição das disciplinas selecionadas agrupadas segundo à
descrição dos cursos selecionados;
5. O sistema totaliza o número de disciplinas por curso e exibe o total no rodapé de
cada grupo de disciplinas;
6. O sistema totaliza o número de cursos selecionados e exibe no rodapé do relatório;
7. O sistema totaliza a contagem distinta de disciplinas (independente de seus cursos)
e exibe o dado no rodapé do relatório;
8. A secretaria fecha o relatório.
1. A secretaria imprime o relatório através do respectivo comando na interface do
relatório;
2. A secretaria exporta o relatório através do respectivo comando na interface do
relatório.
1. Ao selecionar os dados, a composição está vazia. O sistema exibe o aviso
pertinente;
2. Não há dispositivo de impressão instalado, os comando de impressão aparece
desabilitado;
3. Não há espaço suficiente no dispositivo de armazenamento para reter o relatório
exportado. Uma mensagem pertinente é exibida;
108
4. Os dados que compõe o cabeçalho do relatório devem ser exibidos em negrito,

exceto pela data;
5. Os dados do curso devem ser exibidos em negrito;
6. A data de emissão do relatório deve estar no formato “dd/mm/yyyy”;
7. O sistema deve separar os dados dos alunos dos dados da turma através de uma
linha.
1. A interface do relatório deve permitir navegação entre as páginas, configuração do
dispositivo de impressão, impressão do relatório visualizado, ajustar visualização da
página à área disponível na tela, ajustar visualização da pagina para o tamanho real,
exportar o relatório visualizado. Cada uma das ações, acima previstas, deve ser
possibilitadas por meio de um clique num botão de comando, que deve possuir uma
figura representando cada uma das ações e mostrar uma dica da ação realizada;
2. O texto de explicativo de cada uma ação de comando do relatório deve ser exibido
apenas quando o cursor do dispositivo de ponteiro (mouse) esteja posicionado sobre
um dos botões, sem qualquer dos botões pressionados (continuamente ou não),
após um segundo na mesma posição;
3. Ao posicionar o cursor de ponteiro (mouse) sobre qualquer dos botões de comando
descritos no primeiro requisito de interface, os mesmos devem ser ressaltados por
um relevo ao painel que os agrupa;
exceto pela data de emissão;
5. Os dados do curso, que compõem o cabeçalho de cada página do relatório, devem
ser exibidos em negrito;
7. O sistema deve separar os dados dos cursos dos dados das disciplinas através de
uma linha;
8. Cada curso deverá iniciar sua exibição/impressão em uma nova página.
Pós-condições:
Não aplicável.

1. Os relatórios exportados devem estar sob a extensão .QRP.
Regras de Negócio:
Não aplicável.
Caso de Uso 09: Relatório de Alunos por Turma
Ator Principal:
Professor
Sumário:
Este caso de uso é iniciado pelo professor quando ele deseja visualizar os alunos
matriculados em uma ou mais turmas cadastradas em cada curso. O objetivo deste caso de
uso é possibilitar que o professor possa destacar a listagem de alunos matriculado na
disciplina desejada, podendo, posteriormente, ser impresso e/ou exportado.
Pré-Condições:
109
2. Aluno matriculado.
Fluxo Principal:
1. O professor solicita, no menu Relatórios, ao sistema a emissão do relatório de alunos
por turma;
2. O sistema seleciona os seguintes dados que compõe a turma e seu relacionamento
com os alunos matriculados nela: descrição do curso, descrição da disciplina, ano,
semestre, descrição da turma, matrícula do aluno, nome do aluno e nome do
professor responsável. Os dados são ordenados de acordo com a seguinte
precedência: descrição do curso, descrição da disciplina, ano da turma, semestre da
turma, descrição da turma e nome do aluno; todos em ordem crescente. (RN1, RN2);
sem exibidos);
4. O sistema exibe a descrição dos cursos em frente ao cabeçalho de curso;
5. O sistema exibe a descrição das disciplinas em frente ao cabeçalho de disciplina;
6. O sistema exibe os dados ano, semestre, turma, e professor responsável abaixo dos
respectivos cabeçalhos;
7. O sistema exibe os dados de matrícula do aluno e nome do aluno em detalhe,
agrupados sob a turma em que estão matriculados;
8. O sistema totaliza o número de alunos matriculados em uma turma e exibe o dado
no rodapé do grupo de turmas;
9. O sistema totaliza o número de turmas selecionadas e exibe o dado no rodapé do
relatório;
10. O professor fecha o relatório.
1. O professor imprime o relatório através do respectivo comando na interface do
relatório;
2. O professor exporta o relatório através do respectivo comando na interface do
relatório.
pertinente;
desabilitado;
exportado. Uma mensagem pertinente é exibida.
110

5. Os dados da turma, que compõe o cabeçalho de cada página do relatório devem ser
exibidos em negrito;
7. O sistema deve separar os dados dos alunos dos dados da turma através de uma
linha;
8. Cada turma deverá iniciar sua exibição/impressão em uma nova página.
Pós-condições:
Não aplicável.

Regras de Negócio:
RN1: Serão exibidos (visualizados, impressos e exportados), no relatório, somente os
alunos ativos;
RN2: Serão exibidos (visualizados, impressos e exportados), no relatório, somente os
alunos matriculados.
Caso de Uso 10: Relatório de Histórico Escolar
Ator Principal:
Aluno
Sumário:
Este caso de uso é iniciado pelo aluno quando ele deseja visualizar o seu histórico
escolar. O objetivo deste caso de uso é possibilitar que o aluno obtenha sua participação em
disciplinas do curso bem como a avaliação em cada uma dessas disciplinas.
Pré-Condições:
2. Aluno cadastrado.
Fluxo Principal:
1. O aluno solicita, no menu Relatórios, ao sistema, a emissão do relatório de histórico
escolar;
2. O sistema seleciona os seguintes dados: descrição do curso, descrição da disciplina,
número de aulas da disciplina, ano da turma, semestre da turma, matrícula do aluno,
nome do aluno, avaliação 1, avaliação 2, avaliação final e número de faltas. A
ordenação dos dados, de modo crescente, segue a seguinte ordem de precedência:
descrição do curso, nome do aluno, descrição da disciplina, número de aulas da
disciplina e status;
3. O sistema demonstra, baseado na seleção, um status de aprovação para cada
disciplina. (RN1, RN2, RN3 e RN4);
sem exibidos);
111
5. O sistema exibe a descrição dos cursos em frente ao cabeçalho de curso;

6. O sistema exibe os dados de matrícula do aluno e nome do aluno em frente aos
respectivos cabeçalhos;
7. O sistema exibe os dados descrição da disciplina, número de aulas, ano, semestre,
avaliação 1, avaliação 2, avaliação final, número de faltas e status em detalhe,
agrupados sob os dados do aluno;
8. O sistema totaliza a contagem de disciplinas cursadas, a contagem de aulas, a
contagem de faltas e faz uma média da avaliação final, exibindo esses dados no
rodapé do histórico de cada aluno;
9. O sistema totaliza o número de alunos sobre o qual foi relatado o histórico escolar,
exibindo o dado no rodapé do relatório;
10. O aluno fecha o relatório.
1. O aluno imprime o relatório através do respectivo comando na interface do relatório;
2. O aluno exporta o relatório através do respectivo comando na interface do relatório.
pertinente;
desabilitado;
exportado. Uma mensagem pertinente é exibida.
5. Os dados, que compõe o cabeçalho de cada página do relatório, devem ser exibidos
em negrito;
7. O sistema deve desenhar uma tabela para conter os dados do detalhe;
8. Cada histórico escolar deve ter seu início em uma nova página.
Pós-condições:
Não aplicável.

112
Regras de Negócio:
RN1: Serão selecionados dados históricos de disciplinas cursadas pelos alunos;
RN2: Caso o aluno tenha mais que 25% de infreqüência em uma disciplina, seu status,
na mesma, será reprovado por infreqüência; em caso contrário a próxima regra de
negócio é aplicada;
RN3: A avaliação final deve ser a média aritmética dos valores da avaliação 1, da
avaliação 2. Caso o aluno obtenha entre 7 e 10 pontos nessa média, seu status será
aprovado. No caso dessa média estar entre 3 e 6,99, a nota da avaliação final será
somada à média, anteriormente obtida, e uma nova média aritmética é calculada sobre a
soma realizada (nesse caso, se o aluno obtiver uma nota final entre 5 e 10, estará
aprovado, constando tal status no respectivo campo do relatório). Em caso contrário às
situações acima previstas, o status do aluno naquela disciplina deverá constar no
histórico como reprovado por nota;
RN4: A regra de negócio 2 precede, indiscutivelmente, sobre regra de negócio 3 desse

caso de uso.
113
6 – Diagrama de classes
Domínio:
Pessoa
nome : String
datanascimento : Date
email : String
telefonecomercial : String
telefoneresidencial : String
telefonecelular : String
logradouro : String
numero : Integer
complemento : String
bairro : String
cidade : String
UF : String
cep : String
cpf : String
docidentidade : String
orgaoexpedidor : String
dataexpedicao : Date
foto : Image
status : String
Professor
Turma matriculaprofessor : Integer
anoturma : Integer dataadmissao : Date
semestre : Integer titulacao : Integer
descricao : String 0..* 1 tipocontrato : Integer
nummaximoaluno : Integer valetransporte : String
valealimentacao : String
0..* 0..*
0..*
1
TurmaAluno
situacaoaluno : Integer Aloca Coordena
1
1
1 0..*
0..* Disciplina
Curso
Aluno codigodisciplina : String
codigocurso : Integer
descricao : String
matriculaaluno : Integer descricao : String
periodo : Integer
anoinicio : Integer cargahoraria : Integer
1..* 1..* numeroaulas : Integer
semestreinicio : Integer 0..* 1 quantidadeperiodo : Integer
ementa : String
tipo : Integer
bibliografia : String
0..*
1
0..1
Avaliacao
anoavaliacao : Integer
semestreavaliacao : Integer
avaliacao1 : float
avaliacao2 : float
avaliacaofinal : float
faltas : Integer
resultadofinal : Integer
114
MVC:
115
REFERÊNCIAS BIBLIOGRÁFICAS
AMBLER, S. W. Mapping Objects To Relational Databases, out. 2000. Disponível em:

<http://www.ambysoft.com/mappingObjects.html>. Acesso em: 10 jun. 2005.
AMBLER, S. W. The Design of a Robust Persistence Layer for Relational Databases,

Nov. 200. Disponível em: <http://www.ambysoft.com/persistenceLayer.html>. Acesso
em: 10 jun. 2005.
ARAUJO, M. A. P. Notas de Aula – Análise de Sistemas II, 2005.
ARAUJO, M. A. P. Apostila Programação em Delphi, 2004.
CLUBEDELPHI, Revista Clube Delphi. Disponível em <http://www.clubedelphi.net>.

Acesso em: 29 nov. 2005.
DAIBERT, M. S.; JULIO, A. M. O.; ARAÚJO, M. A. P. Persistência de objetos no Delphi:

Introdução ao DePO (Delphi Persistent Objects). Clube Delphi. Rio de Janeiro. N.
69. Dezembro 2005.
DEPO, Delphi Persistent Objects. Disponível em <http://www.liws.com.br/depo>. Acesso

em: 22 nov. 2005.
DUNIT, DUnit. Disponível em <http://dunit.sourceforge.net>. Acesso em: 29 nov. 2005.
ESLAM, Encontro de Software Livre do Amazonas. Disponível em <

http://eslam.comunidadesol.org>. Acesso em: 29 nov. 2005.
FESTSOL, Festival de Software Livre de Juiz de Fora. Disponível em

<http://www.festsol.com.br>. Acesso em: 29 nov. 2005.
IEEE, IEEE. Disponível em <http://www.ieee.org>. Acesso em: 29 nov. 2005.
IO, Instant Obejcts. Disponível em <http://www.instantobjects.org/>. Acesso em: 22 nov.

2005.
LEÃO, M. Borland Delphi 7 – Curso Completo. Rio de Janeiro: Axcel Books 2003. ISBN
85-7323-184-X.
MVC, Model-View-Controler. Disponível em <http://ootips.org/mvc-pattern.html>. Acesso

em: 22 nov. 2005.
NSN, NSN Project. Disponível em <http://www.nukescripts.net>. Acesso em: 22 nov. 2005.
SATZINGER, J.; ORVIK, T. Object-Oriented Approach. USA: Course Technology, 1996.
SHALLOWARY, A.,TROTT,J.; Explicando Padrões de Projeto Uma Nova Perspectiva em

Projeto Orientado a Objeto. São Paulo. Bookman, 2002.
116
SUBVERSION, SVN Subversion Project. Disponível em <http://subversion.tigris.org>.

Acesso em: 22 nov. 2005.
TIOPF, TechInside Object Persistent Framework. Disponível em

<http://www.nukescripts.net>. Acesso em: 22 nov. 2005.
UML, Unified Modeling Language. Disponível em <http://www.uml.org>. Acesso em: 29

nov. 2005.
XML, Extensible Markup Language. Disponível em <http://www.w3.org/xml>. Acesso em:

22 nov. 2005.
117
BIBLIOGRAFIA
AMBLER, Scott W. Análise e Projeto Orientado a Objetos – Volume 2. São Paulo: IBPI
Press, 1998.
BOOCH, Grady, RUMBAUGH, James, JACOBSON, Ivar. UML – Guia do Usuário. Rio de
Janeiro: Campus, 2000.
D’SOUZA, D. F.; WILSS, A. C. Objects, components and frameworks with UML : the
catalysis approach. United States of America : Addison-Wesley, 1998.
FAYAD, E. M.; SCHMIDT, D. C. Object-oriented application frameworks. New York. Oct.

1997.
LEÃO, M.; HAMPSHIRE, P.; BOLONHA, J. C. Delphi 8 para plataforma .Net – Curso
Completo. Rio de Janeiro: Axcel Books 2004. ISBN 8573232315.
HÜMMELGEN, M. Design patterns. Bate Byte, n. 89, p. 8-13, Ago. 1999.
OMG. Object Management Group. Disponível em: <www.omg.org>. Acesso em: 22 nov.
2005.
VLISSIDES, J. M. et al. Pattern languages of program design. Reading : Addison-Wesley,

1996.

FINAL MonografiaDaibert

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

FINAL MonografiaDaibert

Enviado por

Direitos autorais:

Formatos disponíveis

0

FACULDADE METODISTA GRANBERY – FMG

TRABALHO DE CONCLUSÃO DE CURSO

MARCELO SANTOS DAIBERT

MARCELO SANTOS DAIBERT

TRABALHO DE CONCLUSÃO DE CURSO

Trabalho de Conclusão de Curso

Agradeço inicialmente aos meus pais, Ricardo e Helene, que buscam me

“Primeiro faça o necessário;

FACULDADE METODISTA GRANBERY – FMG

TRABALHO DE CONCLUSÃO DE CURSO

Após a exposição do discente Marcelo Santos Daibert, matrícula

Juiz de Fora, 07 de Dezembro de 2005

Professor Marco Antônio Pereira Araújo – Orientador

Professora Alessandreia Marta de Oliveira Julio – Co-Orientadora

Professora Melise Maria Veiga de Paula – Examinadora

Figura 2.1 – Mapeamento Objeto-Relacional ...........................................................16

Figura 5.12 – Interface de Excluir Curso ..................................................................75

Tabela 4.1 – Principais Propriedades e Métodos do DePO .....................................30

LISTA DE LISTAGENS DE CÓDIGO FONTE

Listagem 4.1 – Definição das Classes .....................................................................30

Listagem 5.11 – Método Gravar Campos - Atualizar................................................73

2 MAPEAMENTO OBJETO-RELACIONAL .........................................16

3 CAMADA DE PERSISTÊNCIA ..........................................................22

4.1.1 Componentes DePO.................................................................................28

5 ESTUDO DE CASO ...........................................................................53

5.4.6 Operação Consultar Curso......................................................................76

6 CONSIDERAÇÕES FINAIS ...............................................................78

ANEXO A – DOCUMENTAÇÃO SISTEMA ACADÊMICO ...................80

REFERÊNCIAS BIBLIOGRÁFICAS ...................................................115

O paradigma orientado a objetos cada vez mais vem se destacando e vem

Palavras Chave: Banco de Dados Relacional, Camada de Persistência, Mapeamento

SQL, camada de acesso aos dados e camada de persistência). São apresentados os

2.2 OID (Object Identification)

2.3.1 Mapeando Atributos

2.3.2 Mapeando Classes

2.3.3 Mapeando Herança

Uma tabela por Uma Tabela por Uma Tabela por

Figura 2.2. Estratégias de Mapeamento para Herança.

2.3.4 Mapeando Relacionamentos

2.3.4.1 Diferença Entre Associação e Agregação/Composição

2.3.4.2 Associação do Tipo 1:1

Figura 2.3. Mapeamento de Associação do Tipo 1:1

2.3.4.3 Associação do Tipo 1:n

Figura 2.4. Mapeamento de Associação do Tipo 1:n

2.3.4.4 Associação do Tipo n:n

Figura 2.5. Mapeamento de Associação do Tipo n:n

3.2 Estratégias de Persistência

3.2.1 Camada SQL

Figura 3.1. Camada SQL

Não é utilizado um esquema pré-definido de mapeamento objeto-relacional, o

3.2.2 Camada de Classes para Acesso a Dados

Figura 3.2. Camada de Classes para Acesso a Dados

Assim como na camada SQL, também não é utilizada nenhuma estrutura

3.2.3 Camada de Persistência

Uma outra forma, também muito utilizada, é adicionar o mapeamento na

Figura 3.3. Camada de Persistência

A camada de persistência é responsável por gerar todos os códigos SQL

3.2.3.1 Requisitos de Uma Camada de Persistência

 encapsulamento completo da camada de dados: o usuário do sistema de

no acesso aos bancos de dados suportados, isolando isto do usuário do

3.3 Programação em Camadas Utilizando Camada de Persistência

responsável pela persistência e manipulação de objetos de forma transparente ao

encapsulamento completo da camada de dados: o usuário do sistema de

Em caso de herança, a classe pai deve herdar de TdpoPersistentObject ou