TCC - Sistema Gerenciador de Base de Dados e Dicionário

UNIVERSIDADE REGIONAL DE BLUMENAU
CENTRO DE CIÊNCIAS EXATAS E NATURAIS
CURSO DE CIÊNCIA DA COMPUTAÇÃO – BACHARELADO
SISTEMA GERENCIADOR DE BASE DADOS E DICIONÁRIO
WILLIAM MELLO
BLUMENAU
2022
WILLIAM MELLO
SISTEMA GERENCIADOR DE BASE DADOS E DICIONÁRIO
Trabalho de Conclusão de Curso apresentado

ao curso de graduação em Ciência da
Computação do Centro de Ciências Exatas e
Naturais da Universidade Regional de
Blumenau como requisito parcial para a
obtenção do grau de Bacharel em Ciência da
Computação.
Profa. Luciana Pereira de Araújo Kohler, Mestra - Orientadora
BLUMENAU
2022
Dedico este trabalho aos familiares, amigos,
professores, colegas de trabalho e
especialmente aqueles que me ajudaram a
chegar até aqui e realizar este trabalho com
sucesso.
AGRADECIMENTOS
Gostaria de agradecer aos meus pais, José Adriano Mello e Estela Hemkemaier Mello,
por todo o apoio, persistência e incentivo para que eu conseguisse alcançar meus objetivos.
A minha orientadora Luciana Pereira de Araújo Kohler, por toda a disponibilidade,
compreensão, paciência e competência para que este trabalho fosse concluído.
Aos meus amigos e colegas de trabalhos pelo compartilhamento de conhecimento e
sugestões.
A todos os meus professores, que de alguma forma contribuíram com conhecimentos
necessários para a conclusão deste trabalho. Em especial ao professor Alexander Roberto
Valdameri, pelos esclarecimentos de dúvidas ligadas a bancos de dados relacionais.
A todos os meus colegas de faculdade que fizeram parte de toda a minha trajetória e me
ajudaram com discussões e ideias.
Feliz aquele que transfere o que sabe e aprende
o que ensina.
Cora Coralina
RESUMO
Esse trabalho apresenta o desenvolvimento de um sistema web para gerenciamento de

dicionário e de um SGBD. A ideia surgiu para auxiliar na construção de sistemas legados que
usam de SGBD Oracle como opção de armazenamento das informações da aplicação. Dessa
forma, tem-se a possibilidade de manter as tabelas e seus atributos por meio da uma interface
gráfica web. Além disso, o sistema web permite ao usuário realizar engenharia reversa do banco
de dados por meio da estrutura de metadados e gerar uma Unit em Pascal de conexão ao SGDB
Oracle para o sistema legado. A aplicação foi inspirada no estilo de programação front-end one
page, em que existe uma única página com as principais funcionalidades do sistema. A
aplicação foi desenvolvida seguindo os padrões de usabilidade para web e para isso foi utilizado
frameworks Bootstrap, com linguagem HTML, CSS e Javascript para o front-end. Já para o
back-end foi utilizado framework Dapper e linguagem C#. O objetivo desse trabalho é tornar a
dinâmica de utilização de banco de dados manual para sistemática, auxiliando no decorrer do
desenvolvimento de sistemas comercias, uma vez que operações manuais podem acabar
gerando scripts incorretos e atrasando desenvolvimentos. Dessa forma, o sistema com uma
interface gráfica web e boa usabilidade, pode ser usado para facilitar e permitir agilizar o fluxo
de desenvolvimento de empresas comerciais que utilizam como linguagem de programação
Object Pascal. Para testar o sistema desenvolvido, foram aplicados testes de desempenho e
vulnerabilidade com as ferramentas Google PageSpeed, Suip.biz e Pentest-tools. Como
resultados obteve-se que o sistema possui usabilidade acima da média indicando que o sistema
está adequado na experiência de usuário, para esse teste foi utilizada as heurísticas de SAPO
(2022). No âmbito tecnológico esse sistema contribui com a melhor organização estrutural de
bancos de dados, possibilitando a redução do tempo gasto no processo de engenharia de
sistemas e melhorando a manutenibilidade dos mesmos. Como contribuição científica, este
trabalho compartilha a avaliação de usabilidade realizada sendo uma a partir de um checklist
consolidado, de SAPO (2022). Como algumas limitações do trabalho, destacam-se a geração
de código-fonte para diversas linguagens, compatibilidade com diversos bancos de dados, entre
outros. Por fim, pode-se concluir que os objetivos foram alcançados, conforme apresentado no
decorrer desse trabalho.
Palavras-chave: Sistemas legados. Engenharia reversa. Metadados.

ABSTRACT
This work presentes a web system to manager a dictionaire of a Manager Database System.
This system emerged as an assistant to develop legacy systems that use Oracle Manager
Database System with option to storing application information. In this way, it has the
possibility to maintain tables, tables atributes and the relationship among the tables by the web
graphic interface. Moreover, the web system allow to user do reverse engeneering of the
database throw the metadata structure and allow to the user generate a Pascal Unit. The system
was develop like a front-end one page, this is, has just one page with the main functionalities
of the system. For the development of system it was follow the usability patterns for web and
for this it was used the Bootstrap and Font Awesome frameworks, the HTML, CSS and
Javascript language for the front-end. For the back-end it was used the Dapper framework and
the C# language. The purpose of this work is change the dinamic of use database of manual to
systematic, assistant the development of comercial systems, at once that with manual way can
genereted incorrect scripts. Thus, the system with a good graphic interface web and a good
usability can be used to facility and expedite the development flow commercial companies that
use the Object Pascal programming language. As usability tests was used the SAPO heuristics
that indicates that system is over the average of user experience. As technological relevance
this system contribute with the better structural organization of database with the systems with
interest in use this developed system in the reverse engeneering process, that can be reduce the
spend time int the reverse engeneering systems and better the manutenibility. As scientific
relevance this work share the evaluations did, that was one by a usability questonnaire
consolidated (SAPO, 2022). As a limitation of this work, it has the generation of code to other
programming languages than Object Pascal, the compatibilities with other databases. By the
end, it can be concluded that the goals were achieved according what is presented along this
work.
Key-words: Legacy systems. Reverse engineering. Metadata.

LISTA DE FIGURAS
Figura 1 – Engenharia reversa de banco de dados de um SGBD ............................................. 23

Figura 2 – Modelagem de diagramas de classes da UML no Web Modeler 2.0 ...................... 25
Figura 3 – Resultado da importação de tabelas por engenharia reversa no Web Modeler 2.0 . 26
Figura 4 – Conceito gráfico do padrão de projeto MVC .......................................................... 27
Figura 5 – Interface principal do sistema (editor de diagramas MER) .................................... 27
Figura 6 – Arquitetura da implementação do sistema .............................................................. 28
Figura 7 – Diagrama de casos de uso do sistema gerenciador de dicionário ........................... 34
Figura 8 – Diagrama das classes principais da aplicação ......................................................... 35
Figura 9 – Diagrama representando a arquitetura .................................................................... 37
Figura 10 – Diagrama de componentes .................................................................................... 38
Figura 11 – Organização do projeto front-end ......................................................................... 40
Figura 12 – Organização do projeto back-end.......................................................................... 40
Figura 13 – Comando de remoção para a coluna RAZA_SOCIAL da tabela CLIENTES ...... 62
Figura 14 – Diagrama de classes de conexão Pascal ao Oracle gerado pelo sistema............... 67
Figura 15 – Diagrama de classes representando a estrutura de colunas em Pascal .................. 68
Figura 16 – Ilustração fictícia de uma tabela CLIENTES no banco de dados ......................... 69
Figura 17 – Diagrama de classe estrutural dos índices e colunas dos índices no código-fonte
Pascal gerado pelo sistema gerenciador de dicionário .......................................... 70
Figura 18 – Diagrama de classes estrutural das chaves estrangeira e de suas colunas no
código-fonte Pascal gerado pelo sistema gerenciador de dicionário ..................... 72
Figura 19 – Diagrama de classe estrutural das tabelas no código-fonte Pascal gerado pelo
sistema gerenciador de dicionário ......................................................................... 73
Figura 20 – Exemplo de formulário desenvolvido em código-fonte Pascal para cadastro de
clientes ................................................................................................................... 77
Figura 21 – Diagrama de atividades do sistema gerenciador de dicionário ............................. 81
Figura 22 – Realizando engenharia reversa .............................................................................. 81
Figura 23 – Criando uma nova tabela, colunas da tabela ......................................................... 82
Figura 24 – Criando uma nova tabela, índices da tabela .......................................................... 82
Figura 25 – Criando uma nova tabela, chaves estrangeiras da tabela ...................................... 83
Figura 26 – Convertendo a base de dados ................................................................................ 83
Figura 27 – Consultando o histórico de conversões do SGBD ................................................ 84
Figura 28 – Gerando códigos-fontes de dicionário e tabelas.................................................... 84
Figura 29 – Arquivos Pascal gerados pelo sistema .................................................................. 85
Figura 30 – Criando uma tabela CLIENTES no sistema gerenciador de dicionário ............... 88
Figura 31 – Adicionando uma chave primária a nova tabela CLIENTES ............................... 89
Figura 32 – Gravação da nova tabela CLIENTES realizada com sucesso............................... 89
Figura 33 – PL/SQL Developer indicando que a tabela CLIENTES não existe no SGBD
Oracle ..................................................................................................................... 90
Figura 34 – Conversão do SGBD pelo sistema gerenciador de dicionário .............................. 90
Figura 35 – Nova tabela CLIENTES criada com sucesso no SGBD Oracle ........................... 91
Figura 36 – Gerando código-fonte Pascal utilizando o sistema gerenciador de dicionário ..... 91
Figura 37 – Códigos-fonte Pascal gerados pelo sistema gerenciador de dicionário ................ 92
Figura 38 – Formulário para cadastro de clientes desenvolvido em Pascal ............................. 92
Figura 39 – Inserindo um novo cliente pelo sistema legado desenvolvido sobre os fontes
gerados pelo sistema gerenciador de dicionário .................................................... 93
Figura 40 – Checagem de inserção do novo cliente direto no SGBD Oracle pelo PL/SQL
Developer ............................................................................................................... 93
Figura 41 – Acrescentando uma nova coluna DATA_CADASTRO na tabela CLIENTES ....... 94
Figura 42 – Acrescentando um novo índice PK_CLIENTES_ID na tabela CLIENTES ....... 94
Figura 43 – Conversão da nova coluna DATA_CADASTRO e do novo índice
IND_CLIENTES_NOME ...................................................................................... 95
Figura 44 – Conferindo a criação da coluna DATA_CADASTRO na tabela CLIENTES ......... 95
Figura 45 – Conferindo a criação do novo índice IND_CLIENTES_NOME na tabela
CLIENTES ............................................................................................................ 95
Figura 46 – Código-fonte Pascal gerado pelo sistema gerenciador de dicionário com a nova
coluna e novo índice .............................................................................................. 96
Figura 47 – Inserindo um novo cliente no SGBD Oracle......................................................... 98
Figura 48 – Conferência do valor na nova coluna DATA_CADASTRO da tabela CLIENTES 98
Figura 49 – Modelo entidade relacionamento das tabelas do sistema .................................... 108
Figura 50 – Segunda parte do diagrama de classes da aplicação. .......................................... 109
Figura 51 – Resultado dos testes da PageSpeed ..................................................................... 112
Figura 52 – Resultado da avaliação de segurança do Pentest-tools ....................................... 114
Figura 53 – Tamanho da Tablespace e da base de dados utilizada no teste de carga............. 115
Figura 54 – Quantidade de tabelas processadas pelo sistema no banco de dados .................. 115
Figura 55 – Tempo em milissegundos de cada processo da engenharia reversa .................... 116
LISTA DE QUADROS
Quadro 1 – Informações obtidas por meio de metadados de um SGBD Oracle via PL/SQL
Developer ............................................................................................................... 24
Quadro 2 – Requisitos Funcionais da aplicação ....................................................................... 31
Quadro 3 – Requisitos Não Funcionais da aplicação ............................................................... 32
Quadro 4 – Matriz de rastreabilidade do sistema ..................................................................... 33
Quadro 5 – Controlador de entrada do back-end para a engenharia reversa ............................ 41
Quadro 6 – Comandos de criação da DIC_TABLE e DIC_TABLEID ................................... 42
Quadro 7 – Descoberta de tabelas do banco de dados utilizando USER_TABLES ................. 43
Quadro 8 – Engenharia reversa das tabelas implementadas no back-end ................................ 43
Quadro 9 – Comandos de criação da DIC_TABLE_COLUMNS e DIC_TABLE_COLUMNSID
............................................................................................................................... 44
Quadro 10 – Descobrindo as colunas das tabelas utilizando USER_TAB_COLUMNS ............ 45
Quadro 11 – Engenharia reversa das colunas das tabelas implementados no back-end .......... 46
Quadro 12 – Comandos de criação da DIC_TABLE_INDEXES e
DIC_TABLE_INDEXESID .................................................................................. 47
Quadro 13 – Descoberta de índices das tabelas usando USER_INDEXES e
USER_CONSTRAINTS ......................................................................................... 48
Quadro 14 – Engenharia reversa de índices das tabelas implementadas no back-end ............. 50
Quadro 15 – Comandos de criação da DIC_INDEXES_COLUMNS e
DIC_INDEXES_COLUMNSID ............................................................................. 51
Quadro 16 – Descoberta das colunas dos índices usando o metadados USER_IND_COLUMNS
............................................................................................................................... 52
Quadro 17 – Implementação da descoberta de colunas dos índices no back-end do sistema
gerenciador de dicionário ...................................................................................... 53
Quadro 18 – Comandos de criação da tabela DIC_FOREIGN_KEYS e da sequence
DIC_FOREIGN_KEYSID .................................................................................... 54
Quadro 19 – Descoberta de chaves estrangeiras utilizando o metadados
USER_CONSTRAINTS do tipo R ......................................................................... 55
Quadro 20 – Implementação da descoberta de chaves estrangeiras no back-end do sistema
Quadro 21 – Comandos para criação da tabela DIC_FOREIGN_KEYS_COLUMNS e da
sequence DIC_FOREGN_KEYS_COLUMNSID.................................................... 57
Quadro 22 – Descoberta de colunas das chaves estrangeiras usando o metadados
USER_CONS_COLUMNS ...................................................................................... 58
Quadro 23 – Implementação da descoberta das colunas das chaves estrangeiras no back-end
do sistema gerenciador de dicionário .................................................................... 59
Quadro 24 – Controlador de entrada do back-end para manutenção de tabelas....................... 61
Quadro 25 - Comparação de estrutura de tabela antes e depois de alteração na tabela............ 62
Quadro 26 – Controlador de entrada do back-end para conversão de SGBD .......................... 63
Quadro 27 – Controlador de entrada do back-end para geração de fontes ............................... 64
Quadro 28 – Código-fonte Pascal uDicEnums ...................................................................... 65
Quadro 29 – Parte do código-fonte uDicConstants .......................................................... 66
Quadro 30 – Código-fonte Pascal de enumeradores gerado pelo sistema gerenciador de
dicionário ............................................................................................................... 67
Quadro 31 – Exemplo de código-fonte Pascal de uma tabela PRODUTO gerada pelo sistema
Quadro 32 – Exemplo de um código-fonte de constantes Pascal para uma tabela PRODUTO,
gerado pelo sistema gerenciador de dicionário ...................................................... 77
Quadro 33 – Exemplo de gravação utilizando as classes de código-fonte Pascal geradas pelo
sistema ................................................................................................................... 78
Quadro 34 – Exemplo de busca de clientes utilizando as classes de código-fonte Pascal
geradas pelo sistema gerenciador de dicionário .................................................... 79
Quadro 35 – Exemplo de exclusão de clientes utilizando as classes geradas pelo sistema
Quadro 36 – Relacionamento de Heurísticas e Problemas Identificados por Blocos .............. 86
Quadro 37 – Necessidade de armazenar clientes no banco de dados em um sistema legado .. 87
Quadro 38 – Acrescentando a DATA_CADASTRO no código-fonte Pascal do sistema legado e
compilando-o ......................................................................................................... 97
Quadro 39 – Comparativo dos trabalhos correlatos ................................................................. 99
Quadro 40 – Endereço do sistema e parametrização a ser testado pelo Suip.biz ................... 113
Quadro 41 – Execução do Suip.biz a procura de vulnerabilidades ........................................ 113
Quadro 42 – Resultado da execução do Suip.biz ................................................................... 113
LISTA DE TABELAS
Tabela 1 – Tempos de execução de cada processo da engenharia reversa em segundos ... Erro!
Indicador não definido.
LISTA DE ABREVIATURAS E SIGLAS
API – Application Programming Interface
BLOB – Binary Large Object
CASE – Computer-Aided Software Engineering
CLOB – Character Large Object
CLS – Cumulative Layout Shift
CNPJ – Cadastro Nacional de Pessoas Jurídicas
CPF – Cadastro de Pessoa Física
CRUD – Create Read Update Delete
CRUDL – Create, Read, Update, Delete, List
Lista de tabelas CSS – Cascading Style Sheets
DAO – Data Access Object
DBA – Database Administrator
DDL – Data Definition Language
DML – Data Manipulation Language
DNS – Domain Name System
DOM – Document Object Model
HTML – HyperText Markup Language
IDE – Integrated Development Environment
IP – Internet Protocol
JSON – JavaScript Object Notation
MER – Modelo Entidade Relacionamento
MVC – Model View Control
PAS – Formato de arquivo interpretado pela IDE Delphi na linguagem Object Pascal
RF – Requisito funcional
RNF – Requisito não funcional
SGBD – Sistema Gerenciador de Banco de Dados
SQL – Select Query Language
SUS – System Usability Scale
UC – Use Case (Caso de uso)
UML – Unified Modeling Language
XMI – XML Metadata Interchange
XML – eXtensible Markup Language

SUMÁRIO
1 INTRODUÇÃO .................................................................................................................. 18
1.1 OBJETIVOS ...................................................................................................................... 20
1.2 ESTRUTURA.................................................................................................................... 20
2 FUNDAMENTAÇÃO TEÓRICA .................................................................................... 21
2.1 SISTEMA LEGADO......................................................................................................... 21
2.2 ENGENHARIA REVERSA .............................................................................................. 21
2.3 METADADOS .................................................................................................................. 23
2.4 TRABALHOS CORRELATOS ........................................................................................ 24
2.4.1 FERRAMENTA WEB PARA MODELAGEM LÓGICA EM PROJETOS DE BANCOS
DE DADOS RELACIONAIS ......................................................................................... 24
2.4.2 UMA FERRAMENTA DE SOFTWARE PARA GERAR UMA ARQUITETURA
MODEL-VIEW-CONTROLLER BASEADA NO MODELO ENTIDADE-
RELACIONAMENTO ................................................................................................... 26
2.4.3 ENGENHARIA REVERSA DE BANCO DE DADOS RELACIONAL PARA
MODELO UML .............................................................................................................. 29
3 DESENVOLVIMENTO DO SISTEMA .......................................................................... 31
3.1 REQUISITOS .................................................................................................................... 31
3.2 ESPECIFICAÇÃO ............................................................................................................ 32
3.2.1 Diagrama de casos de uso ............................................................................................... 33
3.2.2 Diagramas de classes....................................................................................................... 34
3.2.3 Diagrama de arquitetura .................................................................................................. 37
3.2.4 Diagrama de componentes .............................................................................................. 38
3.3 IMPLEMENTAÇÃO ........................................................................................................ 39
3.3.1 Técnicas e ferramentas utilizadas.................................................................................... 39
3.3.2 Engenharia reversa .......................................................................................................... 41
3.3.3 Manutenção de tabelas .................................................................................................... 60
3.3.4 Conversão de base ........................................................................................................... 62
3.3.5 Geração de códigos-fontes .............................................................................................. 63
3.3.6 Operacionalidade da implementação .............................................................................. 80
3.4 ANÁLISE DOS RESULTADOS ...................................................................................... 85
3.4.1 Avaliação de usabilidade................................................................................................. 86
3.4.2 Avaliação de usabilidade por demonstração ................................................................... 87
3.4.3 Comparativo dos correlatos com o sistema gerenciador de dicionário ........................... 99
4 CONCLUSÕES ................................................................................................................ 101
4.1 EXTENSÕES .................................................................................................................. 102
REFERÊNCIAS ................................................................................................................... 104
APÊNDICE A – MODELO ENTIDADE RELACIONAMENTO .................................. 106
APÊNDICE B – SEGUNDA PARTE DO DIAGRAMA DE CLASSES ......................... 109
APÊNDICE C – AVALIAÇÕES DE DESEMPENHO, VULNERABILIDADE E CARGA
........................................................................................................................................... 111
18
1 INTRODUÇÃO
Em muitos sistemas legados, segundo Zafar et al. (2019) a manutenibilidade se torna

difícil devido a indisponibilidade de documentação adequada e a complexidade dos softwares
dificultam ainda mais manter esses sistemas. Com a aplicação da engenharia reversa nesses
sistemas legados é possível extrair informações úteis ocultas de um baixo nível de abstração
para um alto nível de abstração a fim de melhorar a manutenibilidade desses sistemas (ZAFAR
et al., 2019). Para Pinto e Braga (2004) apud Barbosa e Candido (2017) os sistemas legados
são sistemas críticos que estão em uso a um longo período, que possivelmente foram
desenvolvidos com tecnologias consideradas atualmente ultrapassadas e que são peças
fundamentais para a organização que o mantem. Devido a essas tecnologias ultrapassadas,
compromete o processo interno da organização de readaptação e evolução do mesmo perante
as novas mudanças.
Essas novas mudanças, segundo Pressmann (2011) apud Santos e Bianchini (2019),
podem ocorrer devido as novas tecnologias, mudanças comerciais, técnicas, legislativas, de
sistemas operacionais ou necessidade de operar em outras plataformas. Um exemplo é a
computação em nuvem, que vem sendo adotada em larga escala entre as organizações, que
viram como importante estratégia de negócios obrigando a evoluir seus sistemas legados para
as estruturas da nuvem. Uma técnica, que vem crescendo nos últimos tempos, a fim de tornar
essas mudanças menos complexas entre os sistemas legados é a engenharia reversa e Pressman
(2011) apud Santos e Bianchini (2019) descrevem na como:
[...] De forma ampla, engenharia reversa é o processo de entender como algo funciona
através da análise de sua estrutura, função e operação permitindo conhecer como um
produto foi pensado e desenhado mesmo sem possuir o projeto original.[...]
Engenharia reversa pode ser usada para entender como algo funciona, ou como foi
feito, mesmo sem possuir a sua documentação [...]. (SANTOS; BIANCHINI, 2019,
p.3).
Após a aplicação da engenharia reversa nesses sistemas legados, Pressman (2011) apud
Santos e Bianchini (2019), afirma que é obtido como resultado a especificação de um produto
que é gerada a partir das análises realizadas no sistema. Com isso é possível entender o
funcionamento do mesmo, para alterar, realizar manutenções futuras e acrescentar novas
funcionalidades ao software em questão. Essa técnica de engenharia reversa cresceu muito e
possibilita o entendimento e melhoria do software, até na descoberta de segredos industriais e
comerciais.
Para Vieira (2020), uma das formas para se realizar engenharia reversa em um sistema
que utiliza conectividade com banco de dados relacional é a Structured Query Language (SQL),
19
que possibilita administrar Sistemas Gerenciadores de Banco de Dados (SGBD) e foi

desenvolvida pela IBM na década de 1970 para gerenciar seus bancos de dados internos da
empresa. Com o passar do tempo a SQL foi aceita internacionalmente por todos os SGBDs
relacionais para realização de processamento de informações. A SQL está dividida em duas
partes, Linguagem de Definição de Dados (DDL) e Linguagem de Manipulação de Dados
(DML). Na DDL é definido o esquema do banco de dados, estrutura de armazenamento,
métodos de acesso, propriedades específicas dos dados e restrições de consistência e integridade
do banco de dados. Na DML é possível acessar e realizar nos dados as operações de
recuperação, inserção, exclusão e alteração de informações.
Vieira (2020) afirma que o SGBD é uma ferramenta que utiliza da linguagem SQL para
criar, processar e gerenciar um banco de dados, tal como criar tabelas e estruturas de suporte.
Uma das finalidades de um SBGD é fornecer uma ferramenta ao usuário para definição de
estruturas para armazenar e manipular informações, além de garantir segurança dos dados,
evitar falhas de sistema, acessos não autorizados, entre outros. Um SGBD é uma aplicação que
interage com o usuário e o banco de dados fazendo uma espécie de ponte entre um e outro, para
obter e analisar dados. Segundo Vieira (2020), os bancos de dados mais utilizados no mercado
são: MySQL, Oracle Database, SQL Server, IBM Db2 e PostgreSQL.
Ferreira et al. (2012) apud Aires et al. (2013) colocam que dentro desses SGBDs existem
algumas estruturas para controle dos dados que são armazenados, uma delas são os metadados.
Elas permitem a um administrador identificar um recurso, por meio de filtragem de objetos,
auxiliar na recuperação dos dados e também manter a integridade dos dados. Esses metadados
são explicados como sendo dados estruturados sobre dados e que a partir deles pode-se
recuperar algumas informações a respeito das tabelas, campos, relacionamentos e forma que foi
construído alguma aplicação. Ou seja, para qualquer tipo de objeto, independente de forma e
de aplicabilidade, possui três qualidades representadas por meio dos metadados: conteúdo,
contexto e estrutura. Esses metadados são possíveis de serem acessados por consultas SQLs e
devolvem praticamente quase toda a informação que é preciso saber sobre como os dados estão
estruturados dentro de um SGBD, permitindo a realização da engenharia reversa dos mesmos.
A partir dessas informações, este trabalho disponibiliza um sistema com interface gráfica
Web para auxílio no processo de engenharia de software, por meio do gerenciamento das
tabelas, de seus campos e de seus relacionamentos. Esse sistema também permite realizar
engenharia reversa por meio da leitura dos metadados do SGBD, realizar a conversão e
atualização automática do SGBD com base nos dados das tabelas que se encontram na interface
gráfica Web e gerar código-fonte Pascal com as tabelas existentes no sistema, pois o autor deste
20
trabalho tem vivência com Pascal e nota que existe necessidade em auxiliar na geração de
código-fonte Pascal com a estrutura do banco de dados existente em sistemas.
1.1 OBJETIVOS
O objetivo deste trabalho é disponibilizar um sistema web que permita a manipulação

de tabelas de um banco de dados relacional sem a necessidade da compreensão e execução de
comandos de SQL de forma manual.
Os objetivos específicos são:
a) disponibilizar a geração de código-fonte em uma Unit em Pascal conforme a
estrutura configurada na interface gráfica para facilitar a conexão do sistema legado
ao SGBD Oracle;
b) disponibilizar a aplicação web com boa usabilidade seguindo os padrões de
usabilidade para web.
1.2 ESTRUTURA
Este trabalho está dividido em quatro capítulos. Sendo o primeiro a introdução, em que
são relatados os motivos para o desenvolvimento do mesmo e os objetivos elencados.
No segundo capítulo é apresentada a fundamentação teórica, em que estão os conceitos
de sistemas legados, engenharia reversa e metadados. Na última seção do capítulo são
apresentados os trabalhos correlatos.
No terceiro capítulo é apresentado o desenvolvimento da aplicação, em que é relatado
os requisitos, os diagramas de casos de uso, modelo de entidade e relacionamento, diagrama de
classes, diagrama de arquitetura, diagrama de componentes e ainda, as técnicas utilizadas e
operacionalidade da implementação. Por fim, são apresentados os resultados e discussões.
No quarto e último capítulo são apresentadas as conclusões que foram alcançadas com
o trabalho, além das limitações deste. Ainda, são elencadas algumas extensões e melhorias para
a aplicação.
21
2 FUNDAMENTAÇÃO TEÓRICA
Esta seção tem como objetivo explorar os conceitos e fundamentos mais importantes
para realização desse trabalho. A subseção 2.1 descreve sobre sistema legado. A subseção 2.2
aborda sobre engenharia reversa. Por fim, a subseção 2.3 abrange sobre metadados,
especificadamente de banco de dados.
2.1 SISTEMA LEGADO
Segundo Pinto e Braga (2004) apud Barbosa e Candido (2017) define-se sistema legado
como sistema crítico que está em uso a um longo período, que possivelmente foi desenvolvido
com tecnologias ultrapassadas e que é peça fundamental para a organização que o mantém e
para Pinto e Braga (2005), esses sistema estão na contramão da evolução, pois as tecnologias
estão em constante evolução uma vez que esses sistemas costumam entrar em produção
desatualizados tecnologicamente, devido a atrasos no desenvolvimento. Uma das possíveis
explicações do porque esses sistemas ainda existem até hoje é uma questão de custo, pois seu
desenvolvimento inicial pode ter levado a um custo muito alto e que só haverá retorno desse
investimento após vários anos de uso. O tempo de duração de sistemas de software é muito
variável e sistemas de grande porte permanecem em uso por mais de dez anos. Outra possível
explicação pode estar ligada ao quão importante esse sistema é para a organização que o
desenvolveu e para as empresas que o utilizam, de modo que uma simples falha dos serviços
desse sistema possa causar sérios efeitos colaterais no dia a dia de ambos.
Para Pfleeger (2007) apud Barbosa e Candido (2017) geralmente um sistema
considerado legado não possui uma documentação adequada ou quando a possui, está
incompleta em relação as funcionalidades atuais dele. Devido a isso, pode ser inviável
financeiramente evolui-lo, pois qualquer modificação poderá impactar em outras
funcionalidades do software ou poderá levar muito tempo para concluir determinada
modificação.
2.2 ENGENHARIA REVERSA
Segundo Pressman (2011) apud Santos e Bianchini (2019), engenharia reversa é o

processo de entender como algo funciona através da análise de sua estrutura, função e operação
permitindo conhecer como ele foi pensado e desenhado mesmo sem possuir o projeto original.
Engenharia reversa pode ser usada para entender como algo funciona, ou como foi feito, mesmo
sem possuir a sua documentação. O resultado da engenharia reversa é a especificação de um
produto que é gerada a partir das análises realizadas no sistema. Com isso permite entender o
22
funcionamento do mesmo, para alterar ou realizar manutenções futuras, ou até mesmo

acrescentar novas funcionalidades ao software em questão. Essa técnica de engenharia reversa
cresceu muito, e hoje possibilita o entendimento e melhoria do software, até na descoberta de
segredos industriais e comerciais. Para Pfleeger (2007) apud Barbosa e Candido (2017), a
manutenção e evolução do sistema pode eventualmente se tornar financeiramente inviável
quando não se tem a documentação do sistema, pois qualquer modificação pode impactar em
outras funcionalidades do software, assim como o tempo pode acabar se estendendo por longos
prazos. Para isso pode-se fazer uso da engenharia reversa para documentar o que já está em
funcionamento, no intuito de criar uma documentação para entender seu funcionamento e
facilitar as alterações. Essa engenharia de banco de dados muitas vezes acaba utilizando dos
recursos dos SGBDs para serem realizadas com sucesso. Uma delas é leitura dos dados
estruturados sobre dados, conhecido como metadados.
Segundo Pressman (2011) apud Barbosa e Candido (2017), o termo engenharia reversa
possui suas origens no mundo do hardware. Por exemplo, uma empresa desmonta um produto
qualquer que seja, de sua concorrente na tentativa de conhecer os segredos do projeto e
fabricação desse concorrente para aplicar ou desenvolver seu produto ainda melhor que o do
concorrente. Esses segredos poderiam ser facilmente entendidos se fosse possível obter as
especificações de projeto e fabricação do concorrente, porém, como esses documentos são de
propriedade privada eles não estão disponíveis, tornando a engenharia reversa a única maneira
de se conseguir uma documentação com especificação do projeto e fabricação da amostra do
produto desmontado do concorrente. Para a área de sistemas, a engenharia reversa é similar ao
exemplo de Pressman (2011) apud Barbosa e Candido (2017), e de certa maneira, mais fácil de
aplicá-la pois as informações são mais completas e rápidas de serem obtidas, graças as grandes
evoluções tecnológicas tanto em hardware quanto em software nos últimos anos.
Na Figura 1 é possível ver uma ilustração da técnica de engenharia reversa de banco
dados de um SGBD, na qual os dados de cada coluna das entidades (tabelas) estão dispersos na
estrutura interna do SGBD e por meio de uma consulta SQL nos metadados USER_TAB_COLUMNS
é possível organizá-los e extrair informações dessas tabelas, como por exemplo, nome das
colunas, tipo de dado das colunas, tamanho das colunas, relacionamentos entre tabelas etc.
23
Figura 1 – Engenharia reversa de banco de dados de um SGBD
Fonte: elaborado pelo autor.
2.3 METADADOS
Metadados, segundo Catarino e Baptista (2010) apud Aires et al. (2013) é definido como
dados estruturados sobre dados, que permitem identificar um recurso, facilitar na filtragem de
objetos, auxiliar na recuperação de um dado etc. Neles estão contidas informações a respeito de
sua aplicabilidade em sistemas de informação, tais como: definição, administração ou
gerenciamento, formas e direitos de uso, entre outros. Segundo Alves (2012) apud Aires et al.
(2013) para explicar o conceito de metadados de banco de dados, pode-se classificar uma
pessoa, ou seja, todo ser humano possui as características: nome, sexo, cor, endereço etc. Dentro
de um SGBD que tenha uma tabela que guarde informações de pessoas, tem-se os metadados
ligados a essa tabela pessoa para identificar os campos, relacionamentos com outras tabelas e
integridades (ALVES, 2012 apud AIRES et al., 2013). Esses metadados sempre são controlados
pelo próprio SGBD e servem de artifício para descobrir informações desconhecidas ou ocultas
que ninguém sabe sobre um banco de dados ou sistema de informação.
Segundo Ferreira et al. (2012) apud Aires et al. (2013) Os metadados são organizados
por uma estrutura padronizada, que permite manter as informações a respeito de objetos digitais
de forma simples, associando as características relevantes a cada elemento a ser armazenado.
Para Hasegawa e Aires (2007) apud Aires et al. (2013) esses metadados podem ser classificados
de acordo com três tipos fundamentais: metadados descritivos; estruturais; e administrativos. O
primeiro descreve ou identifica um recurso de informação, auxiliando na busca e na recuperação
dos objetos. O segundo indica como objetos compostos se relacionam, como por exemplo, a
ordem das páginas de um livro. O terceiro evidencia informações, auxiliando o gerenciamento
24
de recurso, como por exemplo, data de criação e autor, tipos de arquivo, tamanho, além de
outras informações técnicas. Boa parte dos padrões de metadados acabam utilizando da forma
descritiva, pois permite a colocação de informação adicionar aos dados armazenados,
auxiliando na organização dos elementos.
Segundo Codd (1970), para que um banco de dados seja considerado relacional é
necessário que obedeça a algumas normas. A primeira forma normal proposta por Codd (1970)
é de que um banco de dados relacional represente toda e qualquer informação explicitamente
no nível lógico e de forma exatamente por valores em tabelas, ou seja, seus valores de coluna
em linhas dentro das tabelas.
No Quadro 1 é possível ver um exemplo com as informações possíveis de extrair por
meio de tabelas dos metadados em um SGBD Oracle. A ferramenta utilizada para acessar o
SGBD foi o PL/SQL Developer e nela é possível recuperar todas as colunas da tabela CIDADE,
bem como seu tipo de dado, tamanho máximo permitido, se é permitido gravar dados nulos,
comentário sobre a coluna e, se existir, valor padrão para ela, entre outras informações.
Quadro 1 – Informações obtidas por meio de metadados de um SGBD Oracle via PL/SQL
Developer
2.4 TRABALHOS CORRELATOS
Nessa seção são apresentados três trabalhos correlatos que possuem características
semelhantes a proposta desse trabalho. Os três trabalhos são ferramentas CASE para
gerenciamento de banco de dados, a fim de facilitar o cotidiano de programadores e analistas
de sistema.
2.4.1 FERRAMENTA WEB PARA MODELAGEM LÓGICA EM PROJETOS DE

BANCOS DE DADOS RELACIONAIS
Bugmann (2012) apresenta uma ferramenta Web para modelagem lógica em projetos de
banco de dados relacionais, de nome Web Modeler 2.0, com o objetivo de melhorar projetos de
banco de dados de grandes sistemas e dar continuidade ao aplicativo web para definição do
modelo lógico no projeto de banco de dados relacional, Web Modeler 1.0 (BUGMANN, 2012,
p. 15). A ferramenta foi melhorada para permitir ao usuário criar, gerenciar um banco de dados,
independente do SGBD utilizado, e construir “[...] diagramas da UML, casos de uso, classes e
25
atividades.” (BUGMANN, 2012, p. 28), controlar projetos de banco de dados e suas versões,
com restrição de acesso a usuários em determinados projetos e criar diagramas para modelar
tabelas, colunas e relacionamentos de forma gráfica. O Web Modeler 2.0 foi desenvolvido em
linguagem de programação Java, com arquitetura Model View Controller (MVC) e alguns
padrões de projeto, como Data Access Object (DAO) e Command. De alguns aspectos que
foram melhorados no Web Modeler 2.0, pode-se citar a funcionalidade de aproximar, distanciar,
imprimir diagramas com geração de scripts para criação/atualização de bancos de dados e
adicionar uma rotina que permita realizar engenharia reversa de um banco de dados, capaz de
varrer a estrutura do banco de dados e descobrir as tabelas existentes (já criadas) no banco de
dados em que o usuário está conectado (BUGMANN, 2012).
Na Figura 2 tem-se o diagrama de classes carregado na ferramenta Web Modeler 2.0.
Nessa ferramenta há disponível as opções de gerenciar tabelas, diagramas, scripts, importar e
editor de diagramas. No menu de tabelas, é possível manter as tabelas do SGBD. Na opção de
diagramas, é possível consultar as tabelas por meio de diagramas da Unified Modeling
Language (UML). Na opção de scripts, é possível gerar os scripts para converter a base de
dados. Na opção importar, é possível importar diagramas criados na ferramenta. Por último, o
editor de diagramas, que há as ações necessárias para a construção de diagramas de classes,
atividades e de casos de uso, como por exemplo, inserir associações, composições, atores, casos
de uso, fluxo, atividade final, entre outros.
Figura 2 – Modelagem de diagramas de classes da UML no Web Modeler 2.0
Fonte: Bugmann (2012, p. 26).

Ao final do trabalho, Bugmann (2012) conclui que os objetivos iniciais foram
alcançados e que o aplicativo Web Modeler 2.0 desenvolvido permite que um banco de dados
relacional seja modelado, por meio de diagramas, independente do SGBD utilizado. Na Figura
3 pode-se ver o resultado da importação de tabelas por meio da técnica de engenharia reversa
26
do banco de dados utilizado por Bugmann (2012). Ou seja, o Web Modeler 2.0 identificou as
tabelas tb_compra, tb_material e tb_tipo_material no SGBD, importou elas para o Web
Modeler 2.0 (por meio da engenharia reversa) e gerou uma representação gráfica na ferramenta
para visualizar o resultado e permitir alterá-las (BUGMANN, 2012).
Figura 3 – Resultado da importação de tabelas por engenharia reversa no Web Modeler 2.0
Fonte: Bugmann (2012, p. 62).
2.4.2 UMA FERRAMENTA DE SOFTWARE PARA GERAR UMA ARQUITETURA

MODEL-VIEW-CONTROLLER BASEADA NO MODELO ENTIDADE-
RELACIONAMENTO
Soto et al. (2020) apresentam uma ferramenta CASE capaz de gerar código Model-
View-Controller (MVC) com base em um diagrama de Modelo-Entidade-Relacionamento
(MER) e um script de banco de dados correspondente ao diagrama traduzido. A ferramenta é
desenvolvida na linguagem de programação Angular e tem por objetivo aprimorar o
aprendizado do padrão de projeto MVC, promovendo boas práticas de programação e a
reutilização de código (SOTO et al., 2020).
Na Figura 4, Krasner e Pope (1988) apud Soto et al. (2020) explicam como funciona o
padrão de projeto MVC e suas camadas, sendo: o modelo (Model) tem a função de assumir a
parte do sistema que gerencia todas as tarefas relacionadas aos dados, como por exemplo,
validação e persistência de dados ligadas ao banco de dados; a visão (View) possui a função de
interagir com o usuário por meio de interfaces gráficas gerenciáveis, ou seja, formulários,
botões e todos os outros elementos gráficos da aplicação (parte visual); e controlador
(Controller), tem a responsabilidade de cuidar dos eventos disparados pela camada de visão ou
27
acionados por um processo do sistema, ou seja, gerencia os eventos entre a camada de visão e
a camada de modelo (KRASNER, 1988 apud SOTO et al., 2020).
Figura 4 – Conceito gráfico do padrão de projeto MVC
Fonte: Adaptado de Krasner e Pope (1988, p. 5).

Na Figura 5 é possível visualizar as funcionalidades principais. A primeira é a criação
de diagrama MER pelo usuário com apoio do editor do sistema no centro da tela acessada pela
opção Producción. A segunda é a geração do projeto base em Angular com as camadas de
visões, modelos, controladores e script do banco de dados compactada para download
localizada a esquerda na opção Guardar Diagrama. Por último o aprendizado, permitindo o
usuário gerar o código-fonte, modificá-lo e estudar o funcionamento do padrão MVC a esquerda
na opção Aprender MVC (SOTO et al., 2020).
Figura 5 – Interface principal do sistema (editor de diagramas MER)
Fonte: Soto et al. (2020, p. 61).

28
Na Figura 6 é ilustrada a arquitetura de implementação do trabalho dividida em duas

camadas, sendo elas: camada lógica de dados e camada de apresentação. A camada lógica de
dados (na esquerda) possui: o servidor NodeJS2, representando o serviço para criação do
projeto base em Angular; biblioteca GoJS3 para JavaScript e TypeScript permitindo modelar e
projetar os diagramas MER na camada de apresentação do sistema; e JSON4, utilizado para
transformar o diagrama MER em um objeto com formato JavaScript Object Notation (JSON)
para ser enviado e processado pelo servidor. Na camada de apresentação foram utilizados os
componentes Angular 7, TypeScript, HyperText Markup Language (HTML), Cascading Style
Sheets (CSS), JavaScript e Bootstrap com intuito de tornar a aplicação visualmente amigável
(SOTO et al., 2020).
Figura 6 – Arquitetura da implementação do sistema
Fonte: adaptado de Soto et al. (2020, p. 61).

Como método de validação, Soto et al. (2020) utilizaram a escala de usabilidade do
sistema (System Usability Scale - SUS) para quantificar o grau da usabilidade da ferramenta.
Essa escala engloba 10 itens em sua avaliação, podendo variar os valores de 0 a 100 para cada
item (SOTO et al., 2020). Os itens são: acho que gostaria de usar este sistema com frequência;
achei o sistema desnecessariamente complexo; achei o sistema fácil de usar; acho que precisaria
de apoio de um técnico para usar este sistema; achei que as várias funções deste sistema
funcionavam bem integradas; eu pensei que havia muita inconsistência neste sistema; eu
imagino que a maioria das pessoas aprenderiam a usar este sistema muito rapidamente; achei o
sistema muito complicado de usar; me senti muito confiante ao usar o sistema e eu precisava
aprender muitas coisas antes de conseguir usar este sistema (SOTO et al., 2020). Ao final do
trabalho Soto et al. (2020) concluem que a ferramenta desenvolvida obteve ótimos resultados,
29
pois após ter sido testada e qualificada por 18 usuários aleatórios, a média de pontos entre os
10 itens da escala de usabilidade do sistema (SUS) foi superior a 70 pontos.
Soto et al. (2020) também concluem que a adoção do padrão de projeto MVC em
desenvolvimento de sistemas aumenta a produtividade, evita tarefas monótonas e reduz
significativamente os tempos de desenvolvimento, mesmo que eles não tenham testado
diretamente isso. Nesse primeiro trabalho eles focaram a avaliação na usabilidade e pretendem
posteriormente avaliarem aspectos de linhas de código economizadas e também o quanto pode
impactar no tempo de desenvolvimento de sistemas (SOTO et al., 2020).
2.4.3 ENGENHARIA REVERSA DE BANCO DE DADOS RELACIONAL PARA

MODELO UML
Zafar et al. (2019) apresenta uma ferramenta de conversão de esquema de banco de

dados SQL para arquivos eXtensible Markup Language Metadata Interchange (XMI) 2.1, por
meio da engenharia reversa de entidades relacionais existentes em bancos de dados. O arquivo
resultante dessa técnica é utilizado como entrada de dados em sistemas gráficos de modelagem
UML, como por exemplo, o MagicDraw.
Zafar et al. (2019) esclarecem os principais objetivos do trabalho, sendo eles: identificar
as entidades através de suas chaves primárias e identificar os relacionamentos que podem ser
associações, generalizações, especializações e agregações. Para identificar os relacionamentos
de associação entre duas entidades E1 e E2, foi utilizada a técnica de que se existe uma chave
estrangeira entre E1 e E2, porém a chave primária for diferente entre elas, uma associação existe
entre essas entidades. Para identificar os relacionamentos de generalização/especialização, foi
utilizada a técnica de que se a chave primária das entidades E1 e E2 forem iguais e com chave
estrangeira nessas chaves primárias, apontando de E1 para E2 ou vice-versa, significa que uma
herança existe entre essas duas entidades. Para descobrir as cardinalidades de relacionamentos
de associação, foi utilizada a técnica de que entre duas entidades E1 e E2, se a chave primária
de E1 é uma chave estrangeira de E2, então cada instância de E2 é associada a exatamente uma
instância de E1 (um para um). Se houver entre duas entidades E1 e E2, a chave primária de E1
e E2 serem composição de uma chave estrangeira correspondente a E1 e E2, então existe uma
cardinalidade de muitos-muitos (ZAFAR et al., 2019).
No processo de tradução, um SQL de Linguagem de Definição de Dados (DDL) é
analisado para gerar tokens e depois o XMI é elaborado para o modelo Unified Modeling
Language (UML) com os tokens gerados. Nessa abordagem, para gerar o arquivo XMI 2.1
foram extraídas informações explícitas e implícitas, como o mapeamento das cardinalidades,
30
generalização, tipo de entidade, relacionamentos de dependência, associação entre outras. Em

seguida, utilizou-se esse arquivo XMI como entrada na ferramenta MagicDraw para montar os
diagramas da UML conhecidos (ZAFAR et al., 2019).
Zafar et al. (2019) implementaram a ferramenta na linguagem de programação Java,
com analisador de SQL e conversor de tokens, a fim de gerar o documento XMI 2.1 para
importação no MagicDraw. A abordagem utilizou Modelo de Objeto de Documento (DOM),
padrão Application Programming Interface (API) em suporte com analisadores XML, para
trabalhar com XMI e esse DOM é representado como árvores de nós. Para testar a ferramenta,
Zafar et al. (2019) realizaram a geração forçada de tabelas, que consiste em criar manualmente
uma estrutura de tabelas e relacionamentos no SGBD fictícia, ou seja, que não é utilizada por
ninguém, cujo propósito serviu apenas para validar suas técnicas e teorias (ZAFAR et al., 2019).
Ao final do trabalho, Zafar et al. (2019) concluem que a ferramenta é capaz de descobrir
com sucesso, os seguintes componentes da UML: entidade, relação, generalização, dependência
e mapeamento de cardinalidades. Contudo, Zafar et al. (2019) destacam que a incorreta
modelagem do banco pode acabar causando divergências nos resultados e que seguiram os
padrões da UML para realizar a engenharia reversa das entidades do banco de dados. Zafar et
al. (2019) comentam que o diferencial do trabalho é gerar um arquivo universal para as
ferramentas visuais, ao contrário de outros projetos que geram apenas arquivos em formatos
próprios. Zafar et al. (2019) ressaltam que melhorias ao projeto são bem-vindas futuramente, a
fim de enriquecer os diagramas, como por exemplo, resgatar informações sobre atributos
multivalorado, relação N-ária, entre outros.
31
3 DESENVOLVIMENTO DO SISTEMA
Neste capítulo são apresentados os processos utilizados para o desenvolvimento do

sistema denominado sistema gerenciador de dicionário. Na primeira seção são apresentados os
Requisitos Funcionais (RF) e os Requisitos Não Funcionais (RFN) que englobam o sistema. Na
segunda seção é apresentada as especificações relacionadas com os requisitos funcionais e não
funcionais. Também é apresentado os diagramas de Caso de Uso (UC), de classes, de
arquitetura, de componentes e o Modelo de Entidade e Relacionamento (MER). A terceira seção
descreve as técnicas empregadas, apresentando trechos do código-fonte com a sua descrição e
um roteiro da utilização do sistema. Na última seção são analisados os resultados obtidos nos
testes de segurança, confiabilidade, desempenho e estresse.
3.1 REQUISITOS
Nesta seção são apresentados os requisitos do trabalho. Esses requisitos são divididos
em Requisitos Funcionais (RF), apresentados no Quadro 2, e Requisitos Não Funcionais (RNF),
apresentados no Quadro 3.
Quadro 2 – Requisitos Funcionais da aplicação
Requisitos Funcionais
RF01: o sistema deverá manter (Create, Read, Update, Delete, List – CRUDL)
tabelas
RF02: o sistema deverá manter (CRUDL) campos de tabelas
RF03: o sistema deverá manter (CRUDL) o relacionamento entre tabelas
RF04: o sistema deverá gerar uma visualização das tabelas por meio da
descoberta dos dados do SGBD utilizando consulta na base de dados
RF05: o sistema deverá permitir realizar login no SGBD Oracle escolhido
RF06: o sistema deverá permitir realizar conversão e atualização automática da
base de dados conforme informações das tabelas existentes no sistema
RF07: o sistema deverá permitir realizar engenharia reversa do SGBD Oracle
por meio de leitura nos metadados
RF08: o sistema deverá permitir gerar código-fonte Pascal para conexão do
sistema legado ao banco de dados
RF09: o sistema deverá permitir manter usuários
RF10: o sistema deverá permitir manter enumeradores e seus itens de
enumeradores
32
Quadro 3 – Requisitos Não Funcionais da aplicação

Requisitos Não Funcionais
RNF01: o sistema deverá ser desenvolvido para a plataforma Web
RNF02: o sistema deverá ser desenvolvido para se comunicar nativamente com
SGBDs Oracle
RFN03: o sistema deverá possuir interface central com um menu lateral
intuitivo
RNF04: o front-end do sistema deverá ser desenvolvido utilizando as
linguagens HTML, CSS, Javascript e Ajax na IDE Visual Studio Code
RNF05: o back-end do sistema deverá ser desenvolvido utilizando a linguagem
de programação C#, com Rest Web Api na IDE Visual Studio
RNF06: o sistema deverá possuir interface gráfica responsiva conforme os
padrões de usabilidade de sistemas Web
3.2 ESPECIFICAÇÃO
Nesta seção é apresentada a especificação do sistema gerenciador de dicionário,

inicialmente pela matriz de rastreabilidade entre os requisitos funcionais e os casos de uso. Em
seguida tem-se a representação do banco de dados por meio do Modelo Entidade
Relacionamento (MER), o qual apresenta as tabelas criadas para estruturação do back-end, com
suas respectivas relações. Na sequência, são apresentados os diagramas de classes, de
arquitetura e de componentes do sistema gerenciador de dicionário, tanto do front-end quanto
do back-end. Os diagramas de classes, de casos de uso e o MER foram desenvolvidos utilizando
a ferramenta Astah UML. Já os diagramas de arquitetura e de componentes foram
desenvolvidos utilizando a ferramenta Draw.io.
O Quadro 4 apresenta os Requisitos Funcionais (RF) do sistema web e sua
rastreabilidade com os Casos de Uso (UC) correspondentes. Este quadro associa-se com o
diagrama de casos de uso da Figura 7.
A subseção 3.2.1 contém o diagrama de casos de uso do sistema gerenciador de
dicionário, o qual tem um aspecto de permitir manter as estruturas de tabelas do banco de dados.
Já a subseção 3.2.2 apresenta o diagrama de classes da aplicação. Na subseção 3.2.3 é
apresentado o diagrama de arquitetura, de como os diferentes ambientes interagem entre si.
Também é apresentado na subseção 3.2.4 o diagrama de componentes do sistema, com detalhes
de como os componentes internos da aplicação interagem entre si. Por último, é demonstrada a
estrutura do banco de dados da aplicação, representado no diagrama de Modelo Entidade
Relacionamento (MER) no Apêndice A.
33
Quadro 4 – Matriz de rastreabilidade do sistema

Requisitos Funcionais Casos de Uso
RF01: o sistema deverá manter (Create, Read, Update, Delete, List – UC02
CRUDL) tabelas
RF02: o sistema deverá manter (CRUDL) campos de tabelas UC02
RF03: o sistema deverá manter (CRUDL) o relacionamento entre tabelas UC02
RF04: o sistema deverá gerar uma visualização das tabelas por meio da UC02
descoberta dos dados do SGBD utilizando consulta na base de dados
RF05: o sistema deverá permitir realizar login no SGBD Oracle escolhido UC04
RF06: o sistema deverá permitir realizar conversão e atualização UC06
automática da base de dados conforme informações das tabelas existentes
no sistema
RF07: o sistema deverá permitir realizar engenharia reversa do SGBD UC05
Oracle por meio de leitura nos metadados
RF08: o sistema deverá permitir gerar código-fonte Pascal para conexão do UC03
sistema legado ao banco de dados
RF09: o sistema deverá permitir manter usuários UC07
RF10: o sistema deverá permitir manter enumeradores e seus itens de UC01
enumeradores
3.2.1 Diagrama de casos de uso
A Figura 7 apresenta o diagrama de casos de uso do sistema gerenciador de dicionário.

Esse sistema é operado pelo manager, usuário com total acesso às funcionalidades do sistema.
Abaixo dele vem o analista, com acessos mais restritos. Por último, vem o programador,
cuja o acesso é um dos mais restritos.
O primeiro passo a ser realizado começa com o manager, por meio dos UC04 –
Realizar login e UC07 – Manter usuários, que efetua o login e o cadastro de todos os
usuários necessários para a utilização do sistema. Esse ator herda todas as funcionalidades dos
analistas e programadores. Sendo assim, o manager é usuário com acesso total as
funcionalidades do sistema.
Em um outro momento, o programador, por meio do UC02 – Manter tabelas, efetua
alterações nas tabelas, campos das tabelas e relacionamento das tabelas via interface web.
Também é possível o programador, por meio do UC01 – Manter enumerados e seus itens
de enumerados, criar enumeradores com seus respectivos itens no sistema web. A cada
alteração realizada nas estruturas das tabelas, o sistema gera scripts correspondentes a essas
alterações efetuadas pelo programador automaticamente. Uma vez com as tabelas
alteradas/analisadas, o programador, por meio do UC03 – Gerar código-fonte Pascal,
gera os códigos-fontes das tabelas e estruturas de dicionário necessárias para o sistema legado.
Os códigos-fontes são gerados em formato compactado (.zip) e com extensão PAS.
34
Figura 7 – Diagrama de casos de uso do sistema gerenciador de dicionário

Como última etapa o analista, com base no UC06 – Converter base de dados,
analisa as modificações efetuadas pelo programador e realiza a conversão dos scripts no banco
de dados. Essa etapa é feita pelo sistema e o analista só acompanha o processo de execução
pela interface gráfica. Também é possível o analista, por meio do UC05 – Realizar
engenharia reversa, efetuar uma carga/leitura de todas as tabelas do banco de dados para a
estrutura interna do sistema, utilizando os metadados do SGBD, a fim de gerar uma
representação interativa na interface web. Além destas funcionalidades, o analista pode
executar as ações do programador, uma vez que herda os casos de uso deste ator.
3.2.2 Diagramas de classes
Na Figura 8Erro! Fonte de referência não encontrada. é apresentado o diagrama das

classes principais da aplicação. Nele é perceptível a semelhança com o Modelo entidade
relacionamento descrito no Apêndice A, pois o carregamento dos registros do banco de dados
é semelhante no back-end.
35
Figura 8 – Diagrama das classes principais da aplicação

A seguir são apresentadas breves descrições das classes principais utilizadas no sistema
gerenciador de dicionário (Figura 8):
a) IndexTypes: enumerador para representar os tipos de índices;
b) DataTypes: enumerador para representar os tipos primitivos das colunas;
c) IndexColumnOrder: enumerador para representar as formas de ordenação em que
36
as colunas no índice estão dispostas;

d) GenerateFontesType: enumerador para representar quais são os tipos de fontes a
serem gerados pela aplicação;
e) ReverseEngineeringType: representa as opções de engenharia reversa disponíveis
na aplicação;
f) DicTable: representa as tabelas do dicionário;
g) DicTableColumns: representa as colunas das tabelas, ela está associada a classe
DataTypes;
h) DicTableIndexes: representa os índices das tabelas e está associada a classe
IndexTypes;
i) DicIndexesColumns: representa as colunas dos índices das tabelas;
j) DicForeignKeys: representa as chaves estrangeiras das tabelas;
k) DicForeignKeysColumns: representa as colunas das chaves estrangeiras das
tabelas;
l) GenerateFontesCustom: representa os arquivos de código-fonte Pascal a serem
gerados para o solicitante. Essa classe está associada a GenerateFontesType;
m) DicTableCustom: classe especializada da DicTable que representa por orientação
a objetos, as colunas, índices e chaves estrangeiras da tabela. Essa classe possui
associação com as classes DicTableColumnsCustom, DicTableIndexesCustom e
DicForeignKeysCustom;
n) DicTableColumnsCustom: classe especializada da DicTableColumns, que
representa o descritivo do nome da tabela em que a coluna está associada;
o) DicTableIndexesCustom: classe especializada da DicTableIndexes, que
representa o nome da tabela em que o índice está associado;
p) DicIndexesColumnsCustom: classe especializada da DicIndexesColumns que
representa o nome do índice e o nome da coluna em que existe essa associação nos
índices;
q) DicForeignKeysCustom: classe especializada da DicForeignKeys que representa
o nome da tabela associada, o nome da tabela referenciada, o nome do índice
associada e o nome do índice referenciado. Essa classe associa-se a classe
DicForeignKeysColumnsCustom;
r) DicForeignKeysColumnsCustom: classe especializa da DicForeignKeysCustom
que representa nome da chave estrangeira ao qual a coluna está associada, o nome
da coluna associada e o nome da coluna referenciada;
37
s) IComparable: interface que representa a ordenação de seus elementos internos.
As classes que possuem em seu sufixo Custom, a proposta principal é tornar o acesso
aos dados no front-end mais fácil em relação a dados ou estruturas básicas fornecidas pelo back-
end, ou seja, as classes sem o sufixo Custom.
No Apêndice B, é apresentada a segunda parte do diagrama de classes.
3.2.3 Diagrama de arquitetura
Na Figura 9 é apresentado o diagrama contendo as ferramentas e tecnologias utilizadas

para executar a aplicação. Ele contém informações de forma ilustrativa de como os ambientes
interagem entre si.
Figura 9 – Diagrama representando a arquitetura

A seguir é realizada uma breve descrição sobre as etapas presentes no diagrama de
arquitetura:
a) Bootstrap: framework utilizado no front-end para tornar as páginas com as
funcionalidades mais bonitas e responsivas. Esse por sua vez é quem acaba
interagindo com usuário;
b) Javascript: linguagem de programação que responde aos comandos de entrada dos
usuários no front-end. Ela é um dos recursos que se comunicam com o back-end por
requisições;
c) JQuery: biblioteca do Javascript que também se comunica com o back-end por meio
de requisições e serve para buscar e retornar informações pertinentes aos requisitos
da aplicação. Essa biblioteca é consumida pelo recurso Ajax e através dele, são feitas
requisições do tipo get (pegar ou buscar) ao back-end;
d) nuvem: serviço de terceiro responsável por redirecionar uma requisição de um
endereço DNS ao IP local do sistema web. Esse serviço permite que seja acessado
o website de qualquer local do mundo pela internet. O nome do serviço de terceiro
utilizado no trabalho é o no-ip;
38
e) localhost: computador em que está executando o back-end;

f) Dapper: framework utilizado no back-end para realizar requisições ao banco de
dados Oracle. Ele abstrai algumas funções e métodos do banco de dados, como por
exemplo comandos DML e transações;
g) Oracle: SGBD em que os dados estão armazenados. Também é utilizado para a
leitura dos dados, alteração, gravação e exclusão por meio da aplicação web.
3.2.4 Diagrama de componentes
Na Figura 10 é apresentado o diagrama de componentes do sistema gerenciador de

dicionário. Nele é possível entender, de forma ilustrativa, como os componentes interagem
entre si e alguns recursos do sistema web.
Figura 10 – Diagrama de componentes

Observando o diagrama de componentes da Figura 10, é identificado que os
componentes responsáveis pelas funcionalidades de Engenharia reversa, Conversão de
base e Geração de códigos-fontes consomem os recursos do componente framework
Bootstrap para exibir as informações em interface web e receber as entradas dos usuários do
sistema gerenciador de dicionário. Esse por sua vez, acaba consumindo dos recursos dos
componentes Javascript e JQuery para comunicar-se com o back-end, através de requisições,
e obter os resultados processados pelo do sistema.
39
O componente responsável por receptar essas requisições no back-end é o Controller.

Para cada tipo de requisição, esse por sua vez, acaba consumindo um componente Repository
ou Service corresponde para melhor atender a requisição vinda do front-end do sistema. Tanto
o componente Repository quanto o componente Service, concentram as principais lógicas
do sistema do lado do back-end, ou seja, é ali que ocorre todo o processamento mais pesado da
aplicação.
Quando ocorre alguma solicitação ao componente Repository ou Service, esse por
sua vez consome os componentes Repository ou Oracle. Uma vez alcançado o componente
Oracle, não há mais caminhos possíveis, já que toda e qualquer informação útil para a aplicação
localiza-se nesse componente cuja função é buscar os dados do SGBD Oracle.
3.3 IMPLEMENTAÇÃO
Nesta seção é apresentado como foi desenvolvido o sistema, abordando as técnicas e

ferramentas utilizadas para o front-end e back-end, junto de alguns trechos de código-fonte
apresentando sua implementação. Ainda, é detalhada a operacionalidade do sistema e por fim,
são apresentados os resultados e discussões.
3.3.1 Técnicas e ferramentas utilizadas
Nesta subseção são apresentadas as ferramentas utilizadas para codificar, armazenar

dados e avaliar o sistema. Dessa forma, as ferramentas utilizadas foram:
a) Astah UML Student v8.4.1 para desenvolvimento dos diagramas de classes, de casos
de uso e do MER;
b) Draw.io para desenvolvimento dos diagramas de arquitetura e de componentes;
c) C# como linguagem para desenvolvimento do back-end;
d) HTML, CSS, Javascript como linguagens para desenvolvimento do front-end;
e) Microsoft Visual Studio Community 2019 v16.8.6 como IDE de desenvolvimento
para o back-end;
f) Oracle Database 11g Enterprise Edition v11.2 como banco de dados;
g) PL/SQL Developer 13 para execução e validação de comandos DML e DDL no
banco de dados;
h) Microsoft Visual Studio Code v1.67.2 como IDE de desenvolvimento para o front-
end;
i) Bootstrap 5.1.3 como framework para o front-end;
j) Dapper 2.0.123 como framework para o back-end;
40
k) No-ip como serviço de terceiro para redirecionamento DNS ao IP local da máquina

onde está publicada o sistema web;
l) Delphi XE8 v22 como validador dos código-fonte Pascal gerados.
O front-end do sistema foi desenvolvido totalmente em HTML, CSS e Javascript junto

com Bootstrap e JQuery, utilizando o modelo de programação convencional da plataforma web
no estilo one page, em que cada página da aplicação é uma pasta contendo um arquivo
index.html. Utilizando esse estilo, as principais funcionalidades do sistema estão contidas em
uma única página. A Figura 11 apresenta essa organização do projeto no front-end:

Figura 11 – Organização do projeto front-end

O back-end do sistema foi desenvolvido totalmente em C# junto com Dapper, utilizando
o modelo de programação Repository com orientação a objetos. A Figura 12 apresenta a
organização do projeto back-end do sistema, bem como a separação das pastas do padrão de
projeto Repository.
Figura 12 – Organização do projeto back-end

41
3.3.2 Engenharia reversa
A engenharia reversa é apresentada aos usuários em uma espécie de planilha e está

dividida em doze (12) passos distintos. O primeiro passo é excluir todas as tabelas utilizadas no
controle do sistema e cria-las novamente, bem como as sequências de cada tabela, conforme é
apresentado no Apêndice A. Do segundo ao sétimo passo, é realizado a descoberta de todas as
tabelas do banco de dados, que não sejam marcadas como temporárias, nem secundárias no
metadados, as colunas das tabelas, os índices, as colunas dos índices, as chaves estrangeiras e
as colunas das chaves estrangeiras, respectivamente. O oitavo e nono passos, consistem em
criar as tabelas de conversões e histórico de conversões, respectivamente. Essas tabelas de
conversões contêm informações relevantes sobre quem alterou as estruturas de dicionário,
quando alterou e os scripts a serem executados no SGBD. O décimo e décimo primeiro passos
consistem em criar as tabelas ligadas as funcionalidades de enumeradores e itens de
enumeradores, respectivamente. Essa funcionalidade para a criação de enumeradores acaba não
gerando nenhum script de conversão para o SGBD, pois eles não existem nativamente como
um tipo de dado válido para o SGBD. Para o décimo segundo e último passo da engenharia
reversa, é realizada a criação da tabela responsável pelas sequências do SGBD, conhecidas no
termo em inglês por sequences. Nessa tabela de sequências, estão contidas as informações sobre
o menor valor da sequência, o maior valor, o valor inicial, o valor de cada incremento, seu nome
e uma breve descrição sobre sua necessidade ou propósito.
No Quadro 5 é apresentado o código responsável pela funcionalidade de engenharia
reversa. Notam-se duas funções habilitadas para a engenharia reversa, sendo elas: Get() (linha
19) e Post() (linha 25). Com a função Get() é possível descobrir quais estruturas de
dicionário existem no banco de dados. Já a função Post() realiza algum dos passos citados
anteriormente conforme o valor recebido por parâmetro.
Quadro 5 – Controlador de entrada do back-end para a engenharia reversa

Internamente na função InsertByType(), apresentado no Quadro 5, tem-se diversos
comandos responsáveis pela criação e descobertas de informações úteis para o sistema, ligadas
42
à engenharia reversa, sendo eles: engenharia reversa de tabelas; engenharia reversa de colunas
das tabelas; engenharia reversa de índices de tabelas; engenharia reversa de colunas dos índices
das tabelas; engenharia reversa de chaves estrangeiras de tabelas e engenharia reversa de
colunas das chaves estrangeiras de tabelas. Esses comandos serão detalhados nas subseções
seguintes.
3.3.2.1 Engenharia reversa de tabelas
Os comandos de criações da sequence DIC_TABLEID e da tabela DIC_TABLE,

responsáveis por fazerem parte da engenharia reversa de tabelas, é demonstrado no Quadro 6.
Quadro 6 – Comandos de criação da DIC_TABLE e DIC_TABLEID
1 CREATE TABLE DIC_TABLE(
2 ID NUMBER(10) NOT NULL,
3 NAME VARCHAR2(30) NOT NULL,
4 IDENTIFIER VARCHAR2(8) NOT NULL,
5 CONSTRAINT DIC_TABLE_PK_ID PRIMARY KEY (ID),
6 CONSTRAINT DIC_TABLE_UK_TABLE_NAME UNIQUE (NAME),
7 CONSTRAINT DIC_TABLE_UK_IDENTIFIER UNIQUE (IDENTIFIER)
8 );
9 CREATE SEQUENCE DIC_TABLEID;
Conforme demonstrado no Quadro 6, entre as linhas 1 e 8 é realizada a criação da

tabela DIC_TABLE, responsável por armazenar todas as tabelas do banco de dados no sistema
desenvolvido. Suas características são: ID é uma coluna numérica única, auto incrementada
pela sequence DIC_TABLEID, não visível para o usuário e gerenciado internamente pelo sistema;
NAME é uma coluna alfanumérica única, visível ao usuário e que contém o nome da tabela; e
IDENTIFIER é uma coluna alfanumérica única, visível ao usuário e que é utilizada para
controles internos do sistema nas criações de nomes de índices e chaves estrangeiras das tabelas.
Na linha 9 do Quadro 6 é realizada a criação do objeto de banco sequence chamado
DIC_TABLEID utilizado na inserção de novas tabelas no sistema, conforme apresentado no
Quadro 7.
No Quadro 7 é apresentado o comando responsável por descobrir todas as tabelas do
banco de dados através do metadados USER_TABLES.
43
Quadro 7 – Descoberta de tabelas do banco de dados utilizando USER_TABLES

1 INSERT INTO DIC_TABLE (ID, NAME, IDENTIFIER)
2 SELECT DIC_TABLEID.NEXTVAL,
3 TRIM(UT.TABLE_NAME),
4 UPPER(CASE
5 WHEN
6 LENGTH(REPLACE(TRIM(UT.TABLE_NAME),'_','')) > 8 THEN
7 DBMS_RANDOM.STRING('U', 8)
8 ELSE SUBSTR(REPLACE(TRIM(UT.TABLE_NAME),'_',''),
9 0, 8) END)
10 FROM USER_TABLES UT
11 WHERE UT.TEMPORARY <> 'Y'
12 AND UT.SECONDARY <> 'Y'
13 AND UT.TABLE_NAME NOT LIKE 'DIC_%';
14 COMMIT;
Conforme destacado no Quadro 7, entre a linha 1 e linha 13 é realizada a descoberta

das tabelas do banco de dados e inserido na tabela DIC_TABLE do sistema desenvolvido que não
possua as iniciais DIC_ no nome da tabela, que não seja temporária e nem secundária, filtrado
entre as linhas 11 e 13 pela clausula WHERE. Na linha 2 tem-se o valor numérico único
fornecido pela sequence DIC_TABLEID. Na linha 3 tem-se o nome da tabela armazenada no
metadados. Entre as linhas 4 e 9 é realizada uma tentativa de gerar um código alfanumérico
único, caso o nome da tabela possua tamanho superior a oito. Se eventualmente o tamanho do
nome da tabela for inferior ou igual a oito é considerado o próprio nome da tabela como valor
para a coluna IDENTIFIER na tabela DIC_TABLE. A linha 14, contendo o comando COMMIT, é
responsável por efetivar os registros encontrados no metadados USER_TABLES na tabela
DIC_TABLE, encerrando esses fluxos de comandos no sistema.
No Quadro 8 é possível visualizar um código equivalente aos Quadro 6 e Quadro 7
desenvolvidos em C# no back-end do sistema.
Quadro 8 – Engenharia reversa das tabelas implementadas no back-end

Ao receber a requisição do usuário que seja pertinente a engenharia reversa de tabelas,
o sistema executa os comandos das linhas 295 a 315 do Quadro 8. Esses por sua vez, realizam
44
a criação da tabela DIC_TABLE, a criação da sequence DIC_TABLEID e por último a descoberta

das tabelas do banco no metadados USER_TABLES.
3.3.2.2 Engenharia reversa de colunas das tabelas
No Quadro 9 são apresentados os comandos responsáveis por criar as estruturas de

armazenamento das colunas da tabela no sistema desenvolvido.
Quadro 9 – Comandos de criação da DIC_TABLE_COLUMNS e DIC_TABLE_COLUMNSID
1 CREATE TABLE DIC_TABLE_COLUMNS(
3 ID_TABLE NUMBER(10) NOT NULL,
5 TYPE NUMBER(10) NOT NULL,
6 LENGTH NUMBER(10) NOT NULL,
7 NULLABLE VARCHAR2(1) NOT NULL,
8 DESCRIPTION VARCHAR2(254) NULL,
9 DEFAULT_VALUE VARCHAR2(254) NULL,
10 CONSTRAINT DIC_TABLE_COLUMNS_PK_ID PRIMARY KEY (ID),
11 CONSTRAINT DIC_TABLE_COLUMNS_UK_ID_IDTABL UNIQUE
12 (ID_TABLE, NAME),
13 CONSTRAINT DIC_TABLE_COLUMNS_FK_ID_TABLE FOREIGN KEY
14 (ID_TABLE) REFERENCES DIC_TABLE (ID)
15 );
16 CREATE SEQUENCE DIC_TABLE_COLUMNSID;
17 --Type = (Integer, String, DateTime, Float, Blob, Char, Clob)
Conforme o Quadro 9, entre as linhas 1 e 15 é realizada a criação da tabela
DIC_TABLE_COLUMNS, com as seguintes características: ID é numérico único auto incrementado
pela sequence DIC_TABLE_COLUMNSID; ID_TABLE é numérico relacionado com o ID da tabela

DIC_TABLE; NAME é alfanumérico único por tabela e compõe o nome da coluna da tabela; TYPE
é numérico e representa o tipo de dado da coluna da tabela, os tipos possíveis são destacados
na linha 17 do Quadro 9; LENGTH é numérico que indica o tamanho que a coluna possui,
quando diferente de alfanuméricos, o valor é zero; NULLABLE é alfanumérico de uma posição
para indicar se a coluna permite gravar valores nulos, sendo 0 para falso e 1 para verdadeiro;
DESCRIPTION é alfanumérico responsável por armazenar uma descrição de até 254 posições
sobre a coluna da tabela; e por último, DEFAULT_VALUE sendo alfanumérico para permitir indicar
valores padrões para a coluna da tabela.
Na linha 16 é realizada a criação da sequence DIC_TABLE_COLUMNSID, utilizada na
linha 3 do Quadro 10.
45
Quadro 10 – Descobrindo as colunas das tabelas utilizando USER_TAB_COLUMNS

1 INSERT INTO DIC_TABLE_COLUMNS (ID, ID_TABLE, NAME, TYPE,
2 LENGTH, NULLABLE, DESCRIPTION, DEFAULT_VALUE)
3 SELECT DIC_TABLE_COLUMNSID.NEXTVAL, ID_TABLE, NAME, TYPE,
4 LENGTH, NULLABLE, DESCRIPTION, DEFAULT_VALUE FROM (
5 SELECT DT.ID ID_TABLE,
6 UTC.COLUMN_NAME NAME,
7 CASE
8 WHEN UTC.DATA_TYPE = 'NUMBER' THEN 0
9 WHEN UTC.DATA_TYPE = 'VARCHAR2' THEN 1
10 WHEN UTC.DATA_TYPE = 'DATE' THEN 2
11 WHEN UTC.DATA_TYPE = 'FLOAT' THEN 3
12 WHEN UTC.DATA_TYPE = 'BLOB' THEN 4
13 WHEN UTC.DATA_TYPE = 'CHAR' THEN 5
14 WHEN UTC.DATA_TYPE = 'CLOB' THEN 6
15 ELSE -1 END TYPE,
16 UTC.CHAR_LENGTH LENGTH,
17 DECODE(UTC.NULLABLE, 'Y', 1, 0) NULLABLE,
18 (SELECT TRIM(SUBSTR(UCC.COMMENTS, 0, 254)) FROM
19 USER_COL_COMMENTS UCC WHERE UCC.TABLE_NAME = DT.NAME AND
20 UCC.COLUMN_NAME = UTC.COLUMN_NAME) DESCRIPTION,
21 CASE
22 WHEN UTC.DATA_TYPE = 'NUMBER' THEN
23 PKGDIC0001.FNC_CNVLONGTOVARCHAR2(UTC.TABLE_NAME,
24 UTC.COLUMN_NAME)
25 WHEN UTC.DATA_TYPE = 'VARCHAR2' THEN
27 UTC.COLUMN_NAME)
28 WHEN UTC.DATA_TYPE = 'DATE' THEN
30 UTC.COLUMN_NAME)
31 WHEN UTC.DATA_TYPE = 'FLOAT' THEN
33 UTC.COLUMN_NAME)
34 WHEN UTC.DATA_TYPE = 'BLOB' THEN
36 UTC.COLUMN_NAME)
37 WHEN UTC.DATA_TYPE = 'CHAR' THEN
39 UTC.COLUMN_NAME)
40 WHEN UTC.DATA_TYPE = 'CLOB' THEN
42 UTC.COLUMN_NAME)
43 ELSE NULL END DEFAULT_VALUE
44 FROM DIC_TABLE DT,
45 USER_TAB_COLUMNS UTC
46 WHERE DT.NAME = UTC.TABLE_NAME);
47 COMMIT;
Conforme apresentado no Quadro 10, entre as linhas 1 e 48 é realizada a descoberta
de todas as colunas das tabelas do banco de dados, para isso foi usado o metadados
USER_TAB_COLUMNS, extraindo o nome da coluna na linha 6, o tipo de dado da coluna entre
as linhas 7 e 15, o tamanho da coluna na linha 16, se a coluna permite gravar nulo na linha
17, se existe algum comentário para a coluna da linha 18 a 20 e por último, se existe algum
46
valor padrão para a coluna entre as linhas 21 e 43. Na linha 47 são efetivados os registros
na DIC_TABLE_COLUMNS por meio do comando COMMIT.
A implementação dos comandos dos Quadro 9 e Quadro 10 no back-end do sistema são
apresentados no Quadro 11.
Quadro 11 – Engenharia reversa das colunas das tabelas implementados no back-end

47
Conforme destacado no Quadro 11, após receber a solicitação do usuário, no back-end,

para efetuar a engenharia reversa das colunas das tabelas, o sistema executa os comandos entre
as linhas 316 e 383 apresentados nos Quadro 9 e Quadro 10, sendo eles: criação da tabela
DIC_TABLE_COLUMNS entre as linhas 317 e 329; criação da sequence DIC_TABLE_COLUMNSID
na linha 330; e por último, executa a descoberta de todas as colunas de todas as tabelas
importadas no Quadro 8 entre as linhas 331 e 382.
3.3.2.3 Engenharia reversa de índices das tabelas
No Quadro 12 são apresentados comandos responsáveis por criar as estruturas de

armazenamento dos índices das tabelas no sistema gerenciador de dicionário.
Quadro 12 – Comandos de criação da DIC_TABLE_INDEXES e DIC_TABLE_INDEXESID
1 CREATE TABLE DIC_TABLE_INDEXES(
5 TYPE NUMBER(10) NOT NULL,
6 CONSTRAINT DIC_TABLE_INDEXES_PK_ID PRIMARY KEY (ID),
7 CONSTRAINT DIC_TABLE_INDEXES_UK_ID_TAB_NA UNIQUE
8 (ID_TABLE, NAME),
9 CONSTRAINT DIC_TABLE_INDEXES_FK_ID_TABLE FOREIGN KEY
10 (ID_TABLE) REFERENCES DIC_TABLE (ID)
11 );
12 CREATE SEQUENCE DIC_TABLE_INDEXESID;
13 -- Type = (primary key, unique, normal)
Conforme destacado no Quadro 12, entre a linha 1 e 11 é efetuada a criação da tabela
DIC_TABLE_INDEXES responsável por armazenar os índices do sistema gerenciador de
dicionário. Suas características são: ID numérico único, auto valorado pela sequence
DIC_TABLE_INDEXESID; ID_TABLE, cujo objetivo é realizar amarração com tabela DIC_TABLE;
NAME contendo o nome do índice; e por último, TYPE contendo o tipo desse índice, podendo ser
primário (0), único (1) ou ainda, normal (2), destacado na linha 13. Na linha 12 é realizada
a criação da sequence DIC_TABLE_INDEXESID, utilizada na descoberta de índices de tabelas do
Quadro 13.
No Quadro 13 é apresentada a descoberta de índices das tabelas usando USER_INDEXES
e USER_CONSTRAINTS.
48
Quadro 13 – Descoberta de índices das tabelas usando USER_INDEXES e USER_CONSTRAINTS

1 INSERT INTO DIC_TABLE_INDEXES (ID, ID_TABLE, NAME, TYPE)
2 SELECT DIC_TABLE_INDEXESID.NEXTVAL, ID_TABLE, NAME, TYPE FROM(
3 SELECT ID_TABLE, NAME, TYPE FROM (
5 TRIM(SUBSTR(UI.INDEX_NAME,1,30)) NAME,
6 DT.NAME TABLE_NAME,
7 CASE
8 WHEN UC.CONSTRAINT_TYPE = 'P' THEN 0
9 WHEN UC.CONSTRAINT_TYPE = 'U' THEN 1
10 ELSE 2 END TYPE
12 USER_INDEXES UI,
13 USER_CONSTRAINTS UC
14 WHERE DT.NAME = UI.TABLE_NAME
15 AND UI.INDEX_NAME = UC.INDEX_NAME
16 AND UI.TABLE_OWNER = UC.OWNER
17 AND UI.TABLE_OWNER = (SELECT
18 SYS_CONTEXT('USERENV','CURRENT_SCHEMA') FROM DUAL)
19 UNION ALL
21 UI.INDEX_NAME NAME,
22 DT.NAME TABLE_NAME,
23 2 TYPE
25 USER_INDEXES UI
26 WHERE DT.NAME = UI.TABLE_NAME
27 AND NOT EXISTS (SELECT 1
28 FROM USER_CONSTRAINTS UC
29 WHERE UC.INDEX_NAME = UI.INDEX_NAME
30 AND UC.OWNER = UI.TABLE_OWNER)
31 AND UI.INDEX_TYPE NOT IN ('LOB')
32 AND UI.TABLE_OWNER = (SELECT
33 SYS_CONTEXT('USERENV','CURRENT_SCHEMA') FROM DUAL)));
34 COMMIT;
Conforme o Quadro 13, a descoberta de índices está dividida em dois segmentos ou em
duas consultas distintas que são combinadas pelo comando UNION ALL na linha 19. Na
primeira consulta (linha 4 a 18) são utilizados os metadados USER_INDEXES e
USER_CONSTRAINTS sendo que para cada tabela descoberta é posicionado o nome da
USER_INDEXES (UI.INDEX_NAME na linha 15) com o nome da USER_CONSTRAINTS
(UC.INDEX_NAME na linha 15), com o objetivo de descobrir todos os índices que estão ligados
com uma constraint. Além disso, também foi realizada uma filtragem nas linhas 17 e 18 para
que só busque os índices na base de dados do usuário correta, por meio da função SYS_CONTEXT
que permite retornar qual é a base de dados conectada. Para adequar as informações vindas dos
metadados é verificado por meio da coluna CONSTRAINT_TYPE se o índice é primário ou único
(linhas 17 a 10), convertendo para 0 índices primários, 1 para índices únicos e qualquer índice
diferente desses é convertido para 2. No metadados USER_CONSTRAINTS os índices primários
ficam marcados como P e os índices únicos ficam marcados como U. Essa primeira consulta
49
acaba encontrando, em sua maioria, índices primários das tabelas e índices únicos, ou seja,
aqueles que possuem associação com constraints.
Já para a segunda consulta, entre as linhas 20 e 33 do Quadro 13, a descoberta de
índices é um pouco diferente, pois acaba só descobrindo os índices normais que não possuem
amarração com alguma constraint (linha 27 a 30). Como prova disso, é fixado o tipo do índice
como sendo sempre 2 na linha 23. Nessa segunda consulta foi aplicado o mesmo filtro da
primeira consulta, para que só descubra as informações pertinentes à base de dados em que o
usuário está conectado, destacado na linha 32 e 33. Para a linha 34 é realizada a efetivação
dos registros, por meio do comando Commit(), que foram encontrados nos metadados
USER_INDEXES e USER_CONSTRAINTS na tabela DIC_TABLE_INDEXES, controlada pelo sistema
gerenciador de dicionário.
No Quadro 14 é apresentado como estão implementados os comandos do Quadro 12 e
Quadro 13, para a descoberta de índices das tabelas.
50
Quadro 14 – Engenharia reversa de índices das tabelas implementadas no back-end

Conforme o Quadro 14, ao receber a solicitação do usuário para executar a descoberta
de todos os índices das tabelas, o back-end do sistema executa os códigos da linha 384 a 427.
Nessa execução é realizada a criação da DIC_TABLE_INDEXES (linha 385 a 394), passando
para a criação da sequence DIC_TABLE_INDEXESID (linha 395) e por último a descoberta
definitiva dos índices, utilizando os metadados USER_INDEXES e USER_CONSTRAINTS (linha
396 a 426).
3.3.2.4 Engenharia reversa de colunas dos índices das tabelas
No Quadro 15 são apresentados os comandos responsáveis pela criação da tabela

DIC_INDEXES_COLUMNS e da sequence DIC_INDEXES_COLUMNSID.
51
Quadro 15 – Comandos de criação da DIC_INDEXES_COLUMNS e DIC_INDEXES_COLUMNSID

1 CREATE TABLE DIC_INDEXES_COLUMNS(
3 ID_INDEX NUMBER(10) NOT NULL,
4 ID_COLUMN NUMBER(10) NOT NULL,
5 SEQUENCE NUMBER(10) NOT NULL,
6 DESCEND NUMBER(10) NOT NULL,
7 CONSTRAINT DIC_INDEXES_COLUMNS_PK_ID PRIMARY KEY (ID),
8 CONSTRAINT DIC_INDEXES_COLUMNS_UK_IND_COL UNIQUE
9 (ID_INDEX, ID_COLUMN),
10 CONSTRAINT DIC_INDEXES_COLUMNS_FK_ID_INDE FOREIGN KEY
11 (ID_INDEX) REFERENCES DIC_TABLE_INDEXES (ID),
12 CONSTRAINT DIC_INDEXES_COLUMNS_FK_ID_COLU FOREIGN KEY
13 (ID_COLUMN) REFERENCES DIC_TABLE_COLUMNS (ID)
14 );
15 CREATE SEQUENCE DIC_INDEXES_COLUMNSID;
16 -- Descend = (Asc, Desc)
Conforme o Quadro 15, a tabela DIC_INDEXES_COLUMNS (linha 1 a 11) tem o objetivo
de armazenar todas as colunas da tabela que fazem parte de um determinado índice, sendo
criada pelo comando CREATE TABLE. Suas propriedades são: ID como sendo um numérico
único, gerenciado pelo sistema; ID_INDEX numérico, relacionado com a tabela
DIC_TABLE_INDEXES, para representar o índice que essa coluna faz parte da composição;
ID_COLUMN numérico, relacionado com a tabela DIC_TABLE_COLUMNS, para representar a qual
coluna que pertence a esse índice; SEQUENCE numérico, para indicar a posição em que a coluna
está dentro do índice, se é na primeira posição, na segunda etc.; e por último, DESCEND numérico,
com o objetivo de indicar se a coluna possui ordenação crescente (Asc) ou decrescente (Desc),
presente na linha 16. Na linha 15 é realizada a criação da sequence
DIC_INDEXES_COLUMNSID por meio do comando CREATE SEQUENCE.
No Quadro 16 é apresentada a descoberta de todas as colunas dos índices, utilizando o
metadados USER_IND_COLUMNS do SGBD Oracle.
52
Quadro 16 – Descoberta das colunas dos índices usando o metadados USER_IND_COLUMNS

1 INSERT INTO DIC_INDEXES_COLUMNS (ID, ID_INDEX, ID_COLUMN,
2 SEQUENCE, DESCEND)
3 SELECT DIC_INDEXES_COLUMNSID.NEXTVAL, ID_INDEX, ID_COLUMN,
4 SEQUENCE, DESCEND FROM (
5 SELECT DTI.ID ID_INDEX,
6 DTC.ID ID_COLUMN,
7 UIC.COLUMN_POSITION SEQUENCE,
8 DECODE(UIC.DESCEND, 'ASC', 0, 1) DESCEND
9 FROM DIC_TABLE_INDEXES DTI,
10 DIC_TABLE DT,
11 USER_IND_COLUMNS UIC,
12 DIC_TABLE_COLUMNS DTC
13 WHERE DTI.ID_TABLE = DT.ID
14 AND DT.NAME = UIC.TABLE_NAME
15 AND DTI.ID_TABLE = DTC.ID_TABLE
16 AND DTI.NAME = UIC.INDEX_NAME
17 AND UIC.COLUMN_NAME = DTC.NAME);
18 COMMIT;
Conforme o Quadro 16 é realizada a descoberta das colunas dos índices entre a linha
5 e 17. Para isso foi utilizado o metadados USER_IND_COLUMNS relacionando sempre com o
índice e uma coluna existe na tabela em questão (linha 16 e 17). Por meio desse metadados,
é possível obter informações sobre como a coluna que compõe o índice (linha 6), a posição
dessa coluna dentro do índice (linha 7) e se a ordenação da coluna é crescente ou decrescente
(linha 8). Na linha 18 é realizada a efetivação dos registros no banco de dados usando o
comando Commit().
No Quadro 17 são apresentados detalhes da implementação da descoberta das colunas
dos índices no back-end do sistema.
53
Quadro 17 – Implementação da descoberta de colunas dos índices no back-end do sistema

gerenciador de dicionário

Conforme o Quadro 17, quando o usuário solicita ao back-end do sistema que o mesmo
deseja executar a descoberta das colunas dos índices são executados os comandos da linha
428 a 462. Como primeiro passo é realizada a criação da tabela DIC_INDEXES_COLUMNS, por
meio do comando CREATE TABLE (linha 429 a 443), passando pela criação da sequence
DIC_INDEXES_COLUMNSID, por meio do comando CREATE SEQUENCE (linha 444) e por último
inserida as colunas descobertas por meio do metadados USER_IND_COLUMNS na linha 445 a

461.
3.3.2.5 Engenharia reversa de chaves estrangeiras das tabelas
No Quadro 18 são apresentados os comandos de criação da tabela DIC_FOREIGN_KEYS

e da sequence DIC_FOREIGN_KEYSID responsáveis por armazenar as chaves estrangeiras do
sistema gerenciador de dicionário.
54
Quadro 18 – Comandos de criação da tabela DIC_FOREIGN_KEYS e da sequence

DIC_FOREIGN_KEYSID
1 CREATE TABLE DIC_FOREIGN_KEYS(
5 ID_TABLE_REF NUMBER(10) NOT NULL,
6 ID_INDEX NUMBER(10) NULL,
7 ID_INDEX_REF NUMBER(10) NOT NULL,
8 ENABLED VARCHAR2(1) NOT NULL,
9 CONSTRAINT DIC_FOREIGN_KEYS_PK_ID PRIMARY KEY (ID),
10 CONSTRAINT DIC_FOREIGN_KEYS_UK_NAME UNIQUE (NAME),
11 CONSTRAINT DIC_FOREIGN_KEYS_FK_ID_TABLE FOREIGN KEY
12 (ID_TABLE) REFERENCES DIC_TABLE (ID),
13 CONSTRAINT DIC_FOREIGN_KEYS_FK_IDTABREF FOREIGN KEY
14 (ID_TABLE_REF) REFERENCES DIC_TABLE (ID),
15 CONSTRAINT DIC_FOREIGN_KEYS_FK_ID_IND FOREIGN KEY
16 (ID_INDEX) REFERENCES DIC_TABLE_INDEXES (ID),
17 CONSTRAINT DIC_FOREIGN_KEYS_FK_ID_INDRE FOREIGN KEY
18 (ID_INDEX_REF) REFERENCES DIC_TABLE_INDEXES (ID)
19 );
20 CREATE SEQUENCE DIC_FOREIGN_KEYSID;
Conforme o Quadro 18, é realizada a criação de uma tabela chamada
DIC_FOREIGN_KEYS por meio do comando CREATE TABLE (linha 1 a 19) e a criação de uma
sequence DIC_FOREIGN_KEYSID por meio do comando CREATE SEQUENCE. A tabela
DIC_FOREIGN_KEYS possui as seguintes características: ID como sendo numérico único,
gerenciado pelo sistema; NAME alfanumérico único como sendo o nome da chave estrangeira;
ID_TABLE numérico, relacionado com a DIC_TABLE, a fim de descobrir a qual tabela essa chave
estrangeira pertence; ID_TABLE_REF como sendo responsável por indicar qual é a tabela
(DIC_TABLE) relacionada a essa chave estrangeira; ID_INDEX como sendo o índice da tabela
local que a chave estrangeira vai utilizar; ID_INDEX_REF como sendo o índice da tabela
referenciada que a chave estrangeira vai utilizar para criar o relacionamento entre uma tabela e
outra; e por último ENABLED como sendo um indicativo se a chave estrangeira está ativada ou
não está ativada.
No Quadro 19 são apresentados em detalhes a descoberta de chaves estrangeiras
utilizando o metadados USER_CONSTRAINTS do tipo R.
55
Quadro 19 – Descoberta de chaves estrangeiras utilizando o metadados USER_CONSTRAINTS

do tipo R
1 INSERT INTO DIC_FOREIGN_KEYS DFK (DFK.ID, DFK.NAME,
2 DFK.ID_TABLE, DFK.ID_TABLE_REF, DFK.ID_INDEX,
3 DFK.ID_INDEX_REF, DFK.ENABLED)
4 SELECT DIC_FOREIGN_KEYSID.NEXTVAL, NAME, ID_TABLE,
5 ID_TABLE_REF, ID_INDEX, ID_INDEX_REF, ENABLED FROM (
6 SELECT UC.CONSTRAINT_NAME NAME,
7 (SELECT DT.ID FROM DIC_TABLE DT WHERE TRIM(DT.NAME) =
8 TRIM(UC.TABLE_NAME)) ID_TABLE,
9 (SELECT DTI.ID_TABLE FROM DIC_TABLE_INDEXES DTI WHERE
10 DTI.NAME = UC.R_CONSTRAINT_NAME) ID_TABLE_REF,
11 NULL ID_INDEX,
12 (SELECT DTI.ID FROM DIC_TABLE_INDEXES DTI WHERE
13 DTI.NAME = UC.R_CONSTRAINT_NAME) ID_INDEX_REF,
14 DECODE(UPPER(UC.STATUS), 'ENABLED', 1, 0) ENABLED
15 FROM USER_CONSTRAINTS UC,
16 USER_TABLES UT
17 WHERE UC.TABLE_NAME = UT.TABLE_NAME
18 AND UT.TABLE_NAME NOT LIKE 'DIC_%'
19 AND UC.CONSTRAINT_TYPE = 'R'
20 AND UC.OWNER = (SELECT
21 SYS_CONTEXT('USERENV','CURRENT_SCHEMA') FROM DUAL));
22 COMMIT;
Conforme destacado no Quadro 19, é realizado a descoberta das chaves estrangeira
utilizando o metadados USER_CONSTRAINTS do tipo R na linha 6 a 21. Para isso foi necessário
indicar ao metadados USER_CONSTRAINTS que só busque chaves estrangeiras e não índices
primários ou índices únicos (filtro realizado na linha 19). Além disso, para a correta
descoberta, foram feitos subconsultas para descobrir o ID da tabela (linha 7 a 8), outra
subconsulta para recuperar o ID da tabela referenciada (linha 9 a 10) e uma outra subconsulta
para descobrir o índice da tabela referenciada (linha 12 a 13). Na linha 14 também é possível
verificar se a chave estrangeira está ativa ou inativa pela coluna STATUS da USER_CONSTRAINTS.
No Quadro 20 é apresentada a implementação da descoberta de chaves estrangeiras no
back-end do sistema gerenciador de dicionário, utilizando o metadados USER_CONSTRAINTS que
possui como tipo de constraint igual a R.
56
Quadro 20 – Implementação da descoberta de chaves estrangeiras no back-end do sistema


Conforme o Quadro 20, quando o usuário solicita ao back-end do sistema que seja
realizada a descoberta das chaves estrangeiras da tabela, o sistema executa os comandos da
linha 463 a 507 começando pela criação da tabela DIC_FOREIGN_KEYS através do comando
CREATE TABLE na linha 464 a 485, passando depois para a criação da sequence
DIC_FOREIGN_KEYSID com o comando CREATE SEQUENCE na linha 486 e por último,
executando a descoberta das chaves estrangeiras por meio do metadados USER_CONSTRAINTS
que possui o tipo de constraint igual a R na linha 487 a 506.
3.3.2.6 Engenharia reversa de colunas das chaves estrangeiras das tabelas
No Quadro 21 são apresentados os comandos para a criação da tabela

DIC_FOREIGN_KEYS_COLUMNS e da sequence DIC_FOREIGN_KEYS_COLUMNSID, responsáveis
por armazenar as colunas das chaves estrangeiras no sistema gerenciador de dicionário.
57
Quadro 21 – Comandos para criação da tabela DIC_FOREIGN_KEYS_COLUMNS e da sequence

DIC_FOREGN_KEYS_COLUMNSID
1 CREATE TABLE DIC_FOREIGN_KEYS_COLUMNS(
3 ID_FOREIGN_KEY NUMBER(10) NOT NULL,
4 ID_COLUMN NUMBER(10) NOT NULL,
5 ID_COLUMN_REF NUMBER(10) NOT NULL,
6 CONSTRAINT DIC_FOREIGN_KEYS_COL_PK_ID PRIMARY KEY (ID),
7 CONSTRAINT DIC_FOREIGN_KEYS_COL_UK_CORE UNIQUE
8 (ID_FOREIGN_KEY, ID_COLUMN),
9 CONSTRAINT DIC_FOREIGN_KEYS_COL_FK_IDFK FOREIGN KEY
10 (ID_FOREIGN_KEY) REFERENCES DIC_FOREIGN_KEYS (ID),
11 CONSTRAINT DIC_FOREIGN_KEYS_COL_FK_IDIC FOREIGN KEY
12 (ID_COLUMN) REFERENCES DIC_TABLE_COLUMNS (ID),
13 CONSTRAINT DIC_FOREIGN_KEYS_COL_FK_IDCR FOREIGN KEY
14 (ID_COLUMN_REF) REFERENCES DIC_TABLE_COLUMNS (ID)
15 );
16 CREATE SEQUENCE DIC_FOREIGN_KEYS_COLUMNSID;
Conforme o Quadro 21 é realizada a criação de uma tabela chamada
DIC_FOREIGN_KEYS_COLUMNS entre a linha 1 e a 15 por meio do comando CREATE TABLE,
que possui a finalidade de armazenar as colunas das chaves estrangeiras. Ela possui as seguintes
características: ID numérico único, gerenciado pelo sistema; ID_FOREIGN_KEY como sendo a
referência para a chave estrangeira a coluna pertence; ID_COLUMN como sendo a referência a
coluna da tabela em si; e por último, ID_COLUMN_REF como sendo a coluna na tabela
referenciada. Na linha 16 é realizada a criação da sequence DIC_FOREIGN_KEYS_COLUMNSID.
No Quadro 22 é apresentada a descoberta de colunas das chaves estrangeiras, utilizando
o metadados USER_CONS_COLUMNS.
58
Quadro 22 – Descoberta de colunas das chaves estrangeiras usando o metadados

USER_CONS_COLUMNS
1 INSERT INTO DIC_FOREIGN_KEYS_COLUMNS (ID, ID_FOREIGN_KEY,
2 ID_COLUMN, ID_COLUMN_REF)
3 SELECT DIC_FOREIGN_KEYS_COLUMNSID.NEXTVAL ID,
4 DFK.ID ID_FOREIGN_KEY,
5 (SELECT DTC.ID
6 FROM DIC_TABLE DTX,
7 DIC_TABLE_COLUMNS DTC
8 WHERE UC.TABLE_NAME = DTX.NAME
9 AND DTX.ID = DTC.ID_TABLE
10 AND UCC.COLUMN_NAME = DTC.NAME) ID_COLUMN,
11 (SELECT DTC.ID
13 USER_CONS_COLUMNS UCCx,
14 DIC_TABLE_COLUMNS DTC,
15 DIC_TABLE DT
16 WHERE UC.R_CONSTRAINT_NAME = UCCx.CONSTRAINT_NAME
17 AND UC.CONSTRAINT_NAME = DFK.NAME
18 AND UCCx.TABLE_NAME = DT.NAME
19 AND DT.ID = DTC.ID_TABLE
20 AND UCCx.COLUMN_NAME = DTC.NAME
21 AND UCC.POSITION = UCCX.POSITION) ID_COLUMN_REF
23 DIC_TABLE DT,
24 DIC_FOREIGN_KEYS DFK,
25 USER_CONS_COLUMNS UCC
26 WHERE UC.TABLE_NAME = DT.NAME
27 AND UC.CONSTRAINT_NAME = DFK.NAME
28 AND UC.CONSTRAINT_NAME = UCC.CONSTRAINT_NAME;
29 COMMIT;
Conforme o Quadro 22, a realização da descoberta de colunas das chaves estrangeira é
feita por meio do metadados USER_CONS_COLUMNS (linha 25). Com esse metadado é possível
obter uma relação de todas as colunas de uma determinada constraint (chave estrangeira). Para
adequar essas informações são realizadas subconsultas (linha 5 a 10 e linha 11 a 21) para
encontrar o ID da coluna na DIC_TABLE_COLUMNS, pois no metadados há apenas o nome da
coluna e não o ID da coluna (DIC_TABLE_COLUMNS). A linha 29 é responsável por efetivar os
registros encontrados no metadados USER_CONS_COLUMNS na tabela
DIC_FOREIGN_KEYS_COLUMNS, por meio do comando Commit.
No Quadro 23 é apresentada a implementação da descoberta das colunas das chaves
estrangeiras no back-end do sistema gerenciador de dicionário.
59
Quadro 23 – Implementação da descoberta das colunas das chaves estrangeiras no back-end

do sistema gerenciador de dicionário

Conforme apresentado no Quadro 23, quando o usuário solicita ao back-end do sistema
a realização da descoberta das colunas das chaves estrangeiras, o sistema executa os comandos
da linha 508 a 556, começando pela criação da tabela DIC_FOREIGN_KEYS_COLUMNS entre as
linhas 509 e 525, seguindo para a criação da sequence DIC_FOREIGN_KEYS_COLUMNSID na
linha 526 e finalizando com a descoberta das colunas das chaves estrangeiras na linha 527 a
555 por meio do metadados USER_CONS_COLUMNS.
60
3.3.3 Manutenção de tabelas
A manutenção de tabelas é apresentada ao usuário em quatro (4) telas principais, sendo

a primeira com os dados apenas da tabela, como nome e identificador. A segunda sendo
pertinente as colunas e suas informações, como o tipo de dados, o nome, a descrição, o tamanho
máximo e valor padrão. A terceira tela é responsável pelas informações dos índices da tabela,
como o nome, as colunas que o compõem e a forma de ordenação de cada coluna organizada
dentro do índice, podendo ser por ordenação crescente, de A à Z ou de forma decrescente, de Z
à A. Já a quarta e última tela diz respeito as chaves estrangeiras e suas informações, como o
nome, o índice local utilizado, a tabela relacionada, o índice da tabela relacionada, se a chave
estrangeira está habilitada e por último as colunas da tabela local relacionada com as colunas
da tabela referenciada, ilustrada entre a Figura 23 e a Figura 25 na seção de operacionalidade
da implementação. Para toda e qualquer alteração realizada em qualquer tabela do sistema, é
gerado um script equivalente às alterações da interface para conversão e efetuação posterior na
funcionalidade de conversão automática de banco de dados. A técnica utilizada para identificar
essas mudanças na estrutura das tabelas é denominada merge, o conceito é apenas uma
comparação de característica por característica, de coluna a coluna, de índice a índice, de chave
estrangeira, ou seja, quando alguma característica da tabela sofre uma alteração pelo usuário, o
controle de manutenção de tabelas, detecta essa mudança e monta scripts correspondentes para
serem executados no SGBD.
No Quadro 24 é apresentado o controlador responsável por receber a requisição do front-
end para os controles de manutenção de tabelas. Nela são identificadas quatro funções possíveis
de receptação de requisições, sendo elas: a função Get(); a função Post(); a função Put(); e
por último, a função Delete().
A função Get(), localizada entre as linhas 21 e 29, possui a responsabilidade de
retornar todas as informações uteis sobre uma ou mais tabelas, sendo elas informações sobre
colunas, com suas respectivas tipagens de dados, tamanhos, valores padrões, nomes e
descrições. Informações sobre os índices, as colunas desses índices e informações sobre as
chaves estrangeiras e as colunas das chaves estrangeiras. Essas informações são carregadas
conforme a parametrização solicitada pelo front-end.
A função Post(), localizada entre as linhas 33 e 35, possui a responsabilidade de criar
as tabelas, recebendo todas as informações necessárias no corpo da requisição pelo parâmetro
FromBody. As informações passadas são o nome da tabela, o identificar, as colunas dessa tabela,
os índices, as colunas dos índices, as chaves estrangeiras e colunas das chaves estrangeiras.
61
A função Put(), localizada entre as linhas 39 e 41, possui a responsabilidade de

atualizar as informações pertinentes as tabelas. Ela também recebe o mesmo parâmetro
FromBody da função Post(), porém é na função Put() que está a lógica principal da aplicação,
pois ela realiza um merge completo da estrutura da tabela antes das alterações e compara com
as novas alterações feitas pelo usuário e assim, gera os scripts necessários para conversão do
banco de dados, como por exemplo, CREATE TABLE, ALTER TABLE etc.
Quadro 24 – Controlador de entrada do back-end para manutenção de tabelas

Por último, a função Delete(), localizada entre as linhas 48 e 56, possui a
responsabilidade de excluir tabelas do SGBD. As formas de exclusão da tabela podem ser pelo
ID, TableName ou Identifier.
Para melhor detalhar o controle de alterações feitas nas tabelas, é apresentado uma
possível alteração feita pelo usuário, onde o mesmo remove uma coluna (RAZAO_SOCIAL) de
uma tabela chamada CLIENTES. O algoritmo comparou os campos da tabela antes e depois e
gerou o comando equivalente a essa remoção de coluna para o ser executado no SGBD.
62
Quadro 25 - Comparação de estrutura de tabela antes e depois de alteração na tabela

O código corresponde a essa remoção é ALTER TABLE CLIENTES DROP COLUMN
RAZAO_SOCIAL, conforme ilustrado na Figura 13.
Figura 13 – Comando de remoção para a coluna RAZA_SOCIAL da tabela CLIENTES

Essa mesma técnica de comparação por merge antes e depois das alterações é realizada
para qualquer característica da coluna, para todo e qualquer índice e para toda e qualquer chave
estrangeira.
3.3.4 Conversão de base
A conversão de base é apresentada ao usuário em uma espécie de planilha, permitindo

carregar as conversões pendentes e suas informações, como um descritivo da alteração, o
usuário que alterou, a data que foi realizado a alteração e o script ligado a essa conversão que
será executado pelo back-end do sistema gerenciador de dicionário no SGDB, ilustrado na
Figura 26.
No Quadro 26 é apresentado o controlador de entrada para a funcionalidade de
conversão do SGBD. Nela é destacado as duas funções para requisição do front-end, sendo a
Get() e a Post().
63
Quadro 26 – Controlador de entrada do back-end para conversão de SGBD

A função Get(), localizado entre as linhas 22 e 24, possui a responsabilidade de
retornar quais conversões estão pendentes a serem executadas e que foram realizadas pelo
usuário. Uma vez executada a conversão, o registro ligado a conversão é duplicado para o
histórico de conversões e excluído da fila de conversões. Já a função Post(), localizado entre
as linhas 28 e 40, possui a responsabilidade de executar conversões recebidas pelo parâmetro
FromBody da função, vindo do front-end. Para cada conversão o back-end retorna uma
mensagem de sucesso ou, caso ocorra erro de conversão, a mensagem descritiva com o erro de
conversão, podendo ser um erro gerado pelo SGBD ou pela alteração de dicionário do usuário.
3.3.5 Geração de códigos-fontes
A geração de códigos-fontes é apresentada ao usuário em formato de grade ou em

planilha, juntamente com dois componentes de checagem (checkbox). Nos componentes de
checagem é possível escolher entre gerar os códigos-fontes de dicionário e/ou os códigos-fontes
de enumeradores. Já o componente em grade, exibe todas as tabelas disponíveis no sistema para
geração dos códigos-fontes, ilustrado na Figura 28.
No Quadro 27 é apresentado o controlador de entrada para a funcionalidade de geração
de códigos-fontes. Nele é destacado a única função possível para requisições do front-end, a
função Post().
64
Quadro 27 – Controlador de entrada do back-end para geração de fontes

A função Post(), localizado entre as linhas 26 e 37, possui a responsabilidade de
receber pelo parâmetro FromBody, vindo do front-end, o indicativo dos arquivos nos quais o
usuário deseja que sejam gerados pelo sistema, podendo ser, os códigos-fontes de dicionário,
de enumeradores e a lista de tabelas. Todos os arquivos gerados são disponibilizados em
formato compactado (.zip) e dentro deles, em formato de código-fonte Pascal (PAS). Para cada
tabela passada pelo parâmetro FromBody, da função Post(), são gerados códigos-fontes
equivalentes para essas tabelas, que consistem em um código-fonte de conexão a essa tabela no
banco de dados e um segundo código-fonte Pascal com as constantes dessa tabela, sendo uma
constante para o nome da tabela, uma constante com o nome de cada coluna da tabela e uma
constante com o nome de cada índice da tabela.
Para melhor detalhar essas implementações e desenvolvimentos na geração de código-
fonte Pascal, são apresentadas as estruturas dos arquivos gerados pelo sistema gerenciador de
dicionário, por meio de diagramas de classes da UML seguido de explicações. Esses arquivos
são classificados como: arquivos de dicionário; arquivo de enumeradores; arquivos de tabelas;
e arquivos de constantes das tabelas.
Os arquivos de dicionário são separados em três códigos-fonte distintos, sendo eles:
uDicionary.pas (explicado da Figura 14 até a); uDicEnums.pas, apresentado no Quadro 28;
e por último o uDicConstants.pas, possuindo as constantes das tabelas indispensáveis para o
correto funcionamento das classes de dicionário relacionadas, destacado no Quadro 29.
65
Quadro 28 – Código-fonte Pascal uDicEnums

Conforme o Quadro 28, o código-fonte Pascal uDicEnums apenas possui a declaração
dos enumeradores de tipos de dados das colunas (TDataTypes), de tipos de índices
(TIndexTypes), de tipos de ordenação das colunas dentro de um índice (TIndexColumnOrder)
e por último, a forma de pesquisa a ser realizada no banco de dados, utilizando as classes do
código-fonte uDicionary.
Os tipos de dados suportados pelo código-fonte apresentado, são: numérico inteiro
(dtInteger); alfanumérico (dtString); data e hora (dtDateTime); decimal (dtFloat); e por
último, binário longo (dtBlob). Os demais tipos de dados não apresentados, não são suportados.
66
Quadro 29 – Parte do código-fonte uDicConstants

Conforme apresentado no Quadro 29 foi desenvolvido no código-fonte uDicConstants
diversas classes com as constantes das tabelas de dicionário, com suas respectivas colunas. As
classes são consequência do Modelo Entidade Relacionamento (MER) apresentado no apêndice
B e abrangem as tabelas DIC_TABLE, DIC_TABLE_COLUMNS, DIC_TABLE_INDEXES,
DIC_INDEXES_COLUMNS, DIC_FOREIGN_KEYS e DIC_FOREIGN_KEYS_COLUMNS. Nenhum outro
conteúdo adicional foi aplicado ao uDicConstants além de possuir as constantes das tabelas
de dicionário.
Já o arquivo de enumeradores, o sistema gerenciador de dicionário o gera com todos os
enumeradores e itens de enumeradores criados pelo usuário na interface gráfica web. No
Quadro 30 é apresentado um exemplo de um arquivo dessa categoria gerado (uEnumerates).
67
Quadro 30 – Código-fonte Pascal de enumeradores gerado pelo sistema gerenciador de

dicionário

Conforme destacado no Quadro 30, há dois enumeradores criados para um sistema
legado em Pascal, sendo TACAO e TTIPO_OPERADOR. Para o enumerador TACAO, há os itens de
enumeradores: aInserido; aAlterado; aExcluido; e por último, aCarregado. Uma finalidade
para esse enumerador em um sistema legado em Pascal, pode ser listas de componentes ao estilo
de planilha no qual os registros são inseridos, alterados, excluídos e carregados em tempo de
execução. Já o enumerador TTIPO_OPERADOR possui os itens de enumeradores: toResivor;
toPesador; toAdministrador; toGestor; e por último, toCoordenador. Sua finalidade é
apenas didática.
Na Figura 14 é apresentado o diagrama de classes responsável por efetuar a conexão dos
códigos-fonte Pascal com o SGBD Oracle.
Figura 14 – Diagrama de classes de conexão Pascal ao Oracle gerado pelo sistema

68
Conforme apresentado na Figura 14, é possível visualizar a classe TConnect,

responsável por conectar o sistema legado ao banco de dados Oracle, por meio de associação e
utilização da classe TSQLConnection. Na classe TConnect foi aplicado o padrão de projeto
Singleton com o objetivo de tornar único seu acesso a toda e qualquer rotina do sistema legado,
uniformizando a conexão aos dados do banco de dados. Nela também há a implementação do
construtor e destrutor da classe, responsáveis por alocar e deslocar os objetos em memória.
Para permitir garantir mais segurança nas manipulações de informações entre sistema
legado Pascal e banco de dados Oracle foi desenvolvido controles de transações, por meio da
classe TDBXTransaction. Para iniciar a transação deve-se invocar o método
StartTransaction(). Para efetivar os dados alterados no banco de dados, deve-se invocar o
método Commit() e por último, caso ocorra algum lançamento de exceção durante a execução
do sistema legado, deve-se invocar o método Rollback() para abortar a transação e voltar a o
último estado válido dos registros.
Na Figura 15 é possível visualizar o diagrama de classe estrutural que representa as
colunas de tabelas no código-fonte Pascal, gerados pelo sistema gerenciador de dicionário. A
classe TConnect foi abstraída pois está apresentada na Figura 14.
Figura 15 – Diagrama de classes representando a estrutura de colunas em Pascal

Conforme a Figura 15, para representar as colunas das tabelas foi implementada a classe
TDicTableColumns. Nela há todas as propriedades relevantes das colunas da tabela, como por
exemplo: o nome da coluna (Name); o tamanho da coluna (Length); se permite gravar nulo
69
(Nullable); se possui alguma descrição breve (Description); se possui valor padrão. Além
disso, por meio da associação com o enumerado TDataTypes, qual o tipo de dado da coluna,
podendo ser: numérico (dtInteger); alfanumérico (dtString); data e hora (dtDateTime);
decimal (dtFloat) e binário longo (dtBlob). A classe utiliza da associação com a classe
TConnect para conectar e buscar as informações no banco de dados. As propriedades Value e
ValueMax são responsáveis por guardar o valor da coluna a ser inserida. Por exemplo, uma
tabela chamada CLIENTES com o nome da coluna NOME tem a possibilidade de conter o valor
EUCLIDES PIRES a ser gravado ou retornado do banco, conforme ilustrado no comando SELECT
* FROM CLIENTES do Figura 16.

Figura 16 – Ilustração fictícia de uma tabela CLIENTES no banco de dados

A classe TListDicTableColumns especializada da TList representa uma lista de
objetos da classe TDicTableColumns, pelo fato em que uma tabela pode possuir uma ou mais
colunas em sua composição. Na Figura 17 é apresentado o diagrama de classe estrutural dos
índices das tabelas, representando sua montagem no código-fonte Pascal gerado pelo sistema
70
Figura 17 – Diagrama de classe estrutural dos índices e colunas dos índices no código-fonte
Pascal gerado pelo sistema gerenciador de dicionário

Conforme apresentado na Figura 17, foi implementada a classe TDicIndexesColumns
que representa uma coluna pertence a um índice, suas características são: ID como sendo o
identificador numérico único, gerenciado pelo sistema; Sequence como sendo a posição em
que esse campo está disposto dentro do índice, se é a primeira posição, se é a segunda posição
etc.; uma associação com a classe TIndexColumnOrder chamada Descend, com o objetivo de
indicar se a coluna dentro do índice possui ordenação crescente (icoAsc) ou decrescente
(icoDesc); outra associação com a classe TDicTableColumns chamada Column, com o
objetivo de indicar qual é a coluna da tabela que o índice está utilizando. Já a classe
TListDicIndexesColumns é uma especialização da classe TList e representa uma lista de
colunas.
Continuando no diagrama de classes da Figura 17, existe a implementação da classe
TDicTableIndexes que é responsável por representar os índices de uma tabela, com as
seguintes características: ID como sendo o identificador numérico único, gerenciado pelo
sistema; Name como sendo o nome do índice; uma associação com a classe TIndexTypes
chamada IndexType, com o objetivo de indicar qual é o tipo desse índice, podendo ser primário
(itPrimary), único (itUnique) ou normal (itNormal); e por último, uma associação com a
71
classe TListDicIndexesColumns, com o objetivo de representar todas as colunas de um

determinado índice. Para as classes TConnect e TDicTableColumns, seus conteúdos foram
abstraídos, pois já foram apresentados nas Figura 14 e Figura 15, respectivamente.
Para melhor detalhar a estrutura das classes das chaves estrangeiras e suas respectivas
colunas é apresentado o diagrama de classes na Figura 18. Para representar as chaves
estrangeiras das tabelas do banco de dados foi implementada a classe TDicForeignKeys, com
as seguintes características: ID como sendo o identificador numérico único da chave
estrangeira, apenas gerenciado pelo sistema; NAME como sendo o nome alfanumérico da chave
estrangeira; uma associação com a classe TDicTableIndexes para representar qual o índice
que a chave estrangeira está utilizando, esse índice precisa estar na mesma tabela em que está
a chave estrangeira (propriedade Index do diagrama); outra associação com a classe
TDicTable para representar em qual tabela está essa chave estrangeira; outra associação com a
classe TDicTableIndexes para representar qual é o índice referenciado, ou seja, o índice da
outra tabela que ocorre a amarração (propriedade IndexRef no diagrama); outra associação
com a classe TListDicForeignKeysColumns, com o objetivo de representar todas as colunas
de uma chave estrangeira (propriedade ListColumns do diagrama); e a última característica
denominada Enabled para indicar se a chave estrangeira está ou não ativada no banco de dados.
Com uma chave estrangeira desativada, as validações de restrições não são feitas pelo SGBD
no momento de inserções, alterações ou exclusões de registros.
As colunas das chaves estrangeiras são representadas pela classe
TDicForeignKeysColumns possuindo as seguintes características: ID como sendo o
identificador numérico único, apenas gerenciado pelo sistema; uma associação com a classe
TDicTableColumns, com o objetivo de representar qual coluna da tabela está sendo utilizada
(propriedade Column do diagrama); e outra associação com a classe TDicTableColumns,
representando a coluna referenciada de outra tabela, responsável por gerar a amarração entre
uma tabela e outra (propriedade ColumnRef do diagrama). Essas características são carregadas
no construtor Create das classes do diagrama.
72
Figura 18 – Diagrama de classes estrutural das chaves estrangeira e de suas colunas no

código-fonte Pascal gerado pelo sistema gerenciador de dicionário

Os construtores (Create) e destrutores (Destroy) das classes do diagrama, possuem a
finalidade de alocar e desalocar espaço em memória para os objetos dessas classes. As classes
TConnect e TDicTableIndexes foram abstraídas, pois já estão detalhadas nas Figura 14 e
Figura 17. Já a classe TDicTableColumns foi apresentada e detalhada na Figura 15. Por último,
a classe TDicTable é apresentada na Figura 19.
73
Figura 19 – Diagrama de classe estrutural das tabelas no código-fonte Pascal gerado pelo
sistema gerenciador de dicionário

Conforme ilustrado na Figura 19, foi implementada a classe TDicTable com o objetivo
de representar uma determinada tabela do banco de dados em código-fonte Pascal com todas
suas propriedades, sendo elas: ID como sendo o identificador numérico único da tabela,
gerenciado pelo sistema; Name como sendo o nome da tabela; Identifier como sendo um
identificador alfanumérico único da tabela; uma associação com a classe
TListDicTableColumns chamada ListColumns, com objetivo de representar todas as colunas
dessa tabela; uma associação com a classe TListDicTableIndexes chamada ListIndexes,
com a finalidade de representar todos os índices da tabela; uma associação com a classe
TListDicForeignKeys chamada ListForeignKeys, com o objetivo de representar todas as
chaves estrangeiras da tabela.
Além dessas características, a classe TDicTable possui alguns métodos e funções para
controles de acesso aos dados das tabelas, começando pelo método First(), cuja
funcionalidade é para posicionar no primeiro registro da tabela. Já método Last() é o inverso
74
do First(), pois ele posiciona no último registro da tabela. O método Next() posiciona no
registro atual +1, ou seja, o próximo registro da consulta na tabela. Já o método Prior() é
inverso do Next(), pois ele posiciona no registro atual -1, ou seja, o registro antecessor ao atual
na tabela. Existe a função HasRecord(), que tem a finalidade de retornar verdadeiro ou falso
para a existência de registro na tabela, quando não houver registro posicionado na tabela,
retorna falso, já quando houver registro posicionado, retorna verdadeiro. A função
GetFieldValue() é responsável por procurar por uma determinada coluna dentro da estrutura
(parâmetro FieldName) da classe TDicTable e retornar o valor dessa coluna do banco de dados.
Já a função SetFieldValue() é o inverso da GetFieldValue(), pois ela recebe algum valor
vindo de formulários (parâmetro Value), procura a coluna (parâmetro FieldName) da estrutura
da classe TDicTable e seta o valor no banco de dados para a coluna desejada. Como existem
vários tipos de dados no mundo da programação, existem vários métodos SetFieldValue(),
um para cada tipo de dado suportado pelo código-fonte gerado, sendo inteiro, textual, data/hora,
decimal e binário longo. Há ainda funções de pré-fixo Get com a finalidade de pesquisar um
intervalo de valores dentro da tabela, como por exemplo, clientes que possuem identificador
entre 10 a 100. As funções Get suportadas são: GetEqual(), utilizando operador relacional
igual (=); GetNotEqual(), utilizando operador relacional diferente (<>); GetGreater(),
utilizando operador relacional maior (>); GetGreaterEqual(), utilizando operador relacional
maior ou igual (>=); GetLess(), utilizando operador relacional menor (<); e por último,
GetLessEqual(), utilizando o operador relacional menor ou igual (<=). Esses operadores estão
representados na classe de enumerador TSearchOperador ilustrado no diagrama da Figura 19.

Também há implementado os comandos DML principais para manipulação de valores nas
tabelas, acessíveis pelos métodos Insert(), Update() e Delete(). O método Insert() insere
os dados na tabela dentro do banco de dados, por meio do comando INSERT INTO do SGBD.
O método Update() atualiza os dados na tabela dentro do banco de dados, por meio do
comando UPDATE SET do SGBD. O Delete() apaga os dados na tabela dentro do banco de
dados, por meio do comando DELETE FROM do SGBD. Por último existem os controles de
transação, sendo o método IsTransactionActive() responsável por indicar se há ou não uma
transação aberta, o método StartTransaction() para iniciar uma nova transação, o método
Commit() para encerrar a transação e efetivar os dados no SGBD e por último o RollBack()
responsável por abortar uma transação e descartar os dados enviados para o SGBD.
Para as classes abstraídas TConnect, TDicTabelColumns, TDicTableIndexes e
TDicForeignKeys, seus diagramas estão apresentados em figuras anteriores a Figura 19.
75
No Quadro 31 é apresentado um código-fonte Pascal modelo de uma tabela PRODUTO

gerada pelo sistema gerenciador de dicionário. Como boa prática em programação Pascal, as
classes devem iniciar seu nome com um pré-fixo T, ou seja, para uma chamada PRODUTO, a
nomenclatura padrão para a classe é TPRODUTO.
Quadro 31 – Exemplo de código-fonte Pascal de uma tabela PRODUTO gerada pelo sistema

Conforme destacado no Quadro 31, o sistema gera o código-fonte Pascal com base no
nome da tabela e suas colunas (linha 27 a 50), bem como os índices primários e únicos com
76
suas respectivas colunas dos índices (linha 52 a 59). O padrão de nome para os arquivos são
uTable + nome da tabela + .pas. No construtor da classe da tabela (TPRODUTO) é indicada a
constante com o nome da tabela para carregar todas as propriedades ligadas a essa tabela
(TBL_PRODUTO, na linha 29). Nesse arquivo também constam os acessos a cada coluna da
tabela, com seus respectivos tipos de dados, permitindo facilitar o desenvolvimento de sistemas
legados, pois muitas funções são encapsuladas no interior da classe TDicTable.
No Quadro 32 é apresentado o código-fonte das constantes em Pascal gerado pelo
sistema gerenciador de dicionário. O padrão de nome para os arquivos de constantes são uTable
concatenado ao nome da tabela com o pós fixo CNT.pas. Nesse código-fonte Pascal estão
disponíveis constantes para o nome da tabela (linha 7), para o nome de todas as colunas da
tabela (linha 8 a 9) e para o nome de todos os índices da tabela (linha 10). As constantes
com os nomes das tabelas são utilizadas pelos construtores das classes de tabela (exemplo:
TPRODUTO) para indicar qual tabela a classe está representando. Já as constantes com o nome de
todas as colunas são utilizadas para recuperar ou gravar os valores vindos de formulários do
sistema legado, conforme ilustrados no Quadro 31 entre as linhas 32 e 50. Por último são
acrescentadas rotinas de busca ao banco de dados para todos os índices da tabela que possuem
o tipo primário ou único, pois índices marcados com esses tipos acabam não repetindo registros
de mesmo valor dentro da tabela. Por exemplo: se uma coluna chamada NOME de uma tabela
CLIENTES possuir um índice único na coluna NOME, o valor JOÃO não pode se repetir, gerando
erro de restrição exclusiva caso ocorra uma tentativa de inserir um segundo registro de nome
JOÃO na tabela CLIENTES.
Os padrões de nomes das constantes seguem a seguinte lógica: TBL_ concatenado ao
nome da tabela; FLD_ concatenado ao o nome da tabela seguido de um underscore (_)
concatenado ao o nome da coluna; IDX_ concatenado ao nome da tabela seguido de um
underscore (_) concatenado ao nome do índice.
77
Quadro 32 – Exemplo de um código-fonte de constantes Pascal para uma tabela PRODUTO,

gerado pelo sistema gerenciador de dicionário

Figura 20 – Exemplo de formulário desenvolvido em código-fonte Pascal para cadastro de
clientes

O exemplo de formulário para cadastro de clientes escrito em Pascal na Figura 20 pode
ser comparado a um sistema legado, apenas com a finalidade de simular a utilização dos
arquivos gerados pelo sistema gerenciador de dicionário apresentado nessa seção 3.3.5.
A funcionalidade desse sistema legado apresentado na Figura 20 é permitir cadastrar
clientes no banco de dados, que possuam como informação o identificador numérico único
(gerenciado internamente pelo sistema), o nome do cliente com 90 posições de digitação
máxima, a razão social podendo ser CPF ou CNPJ, o telefone com 14 posições de digitação
máxima e por último o endereço de localização do cliente, podendo digitar até 90 caracteres.
Para que esse pequeno sistema legado funcione, é necessário fazer a implementação do
botão gravar com o objetivo de enviar os dados inseridos pelo usuário no formulário para o
78
banco de dados. Esse código-fonte correspondente a essa funcionalidade pode ser visto no
Quadro 33.
Quadro 33 – Exemplo de gravação utilizando as classes de código-fonte Pascal geradas pelo
sistema

No Quadro 33 é realizada primeiramente uma checagem na linha 110 com o objetivo
de verificar se o cliente já está cadastrado no banco de dados ou se eventualmente é um cliente
novo. O valor dessa checagem é armazenado na variável booleana lbNewRecord. Na sequência
é inicializado uma transação (linha 119) e atribuída as informações do cliente para as classes
geradas pelo sistema gerenciador de dicionário (linhas 120 a 124) e se eventualmente for um
novo cliente é aplicado um comando Insert(), seguido de Commit() (linhas 127 e 128) para
inserir e efetivar os dados no banco de dados. Caso já exista o cadastro do cliente, o sistema
desvia o fluxo de execução do programa e aplica o comando Update(), seguido de Commit()
(linhas 136 e 137) para atualizar e efetivar os dados no banco de dados. Caso ocorra o
lançamento de alguma exceção causada pelo programa, o fluxo de execução será desviado para
79
as linhas 146 a 153, correspondente ao bloco de comando Try Except, cujo objetivo é
permitir ao programador tratar exceções lançadas indevidamente pelo programa.
Para o carregamento das informações no sistema legado, pertinentes a clientes utilizando
os arquivos gerados pelo sistema gerenciador de dicionário, é apresentado um código-fonte de
modelo no Quadro 34.
Quadro 34 – Exemplo de busca de clientes utilizando as classes de código-fonte Pascal
geradas pelo sistema gerenciador de dicionário

Utilizando as classes geradas pelo sistema gerenciador de dicionário, primeiramente é
obrigatório o posicionamento do identificador do cliente nas classes de tabelas (fCLIENTES =
TCLIENTES) na linha 158 do Quadro 34. Se eventualmente o identificador informado pelo
usuário no sistema legado for encontrado no banco de dados é só atribuir o valor das colunas
da tabela em componentes visuais no sistema legado e pronto, nenhum código a mais é
necessário das classes de tabelas. Nesse exemplo do Quadro 34, foi realizada uma codificação
adicional para que se o identificar do cliente, informado pelo usuário, não for encontrado no
banco de dados, o sistema legado inicia o cadastro de um novo cliente, habilitando o botão de
gravação e os componentes de digitação no formulário para o usuário informar os dados desse
novo cliente.
Para executar a exclusão de algum cliente da base de dados utilizando as classes geradas
pelo sistema gerenciador de dicionário é possível seguir o modelo apresentado no Quadro 35.
80
Quadro 35 – Exemplo de exclusão de clientes utilizando as classes geradas pelo sistema


Conforme apresentado no Quadro 35, uma vez com identificador do cliente posicionado,
na linha 158 do Quadro 34, basta iniciar uma transação (linha 91) e invocar o comando
Delete() (linha 92) das classes de tabelas geradas pelo sistema gerenciador de dicionário.
Se tudo ocorrer sem nenhum lançamento de exceção, o programa irá invocar o comando
Commit() para efetivar a exclusão do cliente no banco de dados, porém se ocorrer um
lançamento de exceção pelo programa, o fluxo de execução será desviado para o bloco de
comando TRY EXCEPT nas linhas 100 a 108, invocando o comando Rollback() para o último
ponto válido antes da tentativa de exclusão do cliente.
3.3.6 Operacionalidade da implementação
Nesta seção é apresentada a operacionalidade da implementação, abordando o fluxo

principal do sistema, começando pela execução da engenharia reversa até o final gerando
código-fonte Pascal, ilustrado através do diagrama de atividades da Figura 21.
Conforme ilustrado no diagrama de atividades da Figura 21, para o usuário conseguir
gerar códigos-fontes pelo sistema, é necessário primeiramente conectar na aplicação com o
usuário MANAGER, que possui todos os acessos liberados, e criar uma conta a partir do MANAGER
para usuários convencionais, podendo ser um usuário programador ou analista. Uma vez
com as contas criadas e conectado na aplicação com o usuário MANAGER, irá selecionar a opção
Engenharia Reversa no menu principal e clicar sobre o botão Importar, para executar a
engenharia reversa do SGBD, conforme destacado na Figura 22. Uma vez executada a
engenharia reversa, o sistema irá criar todas as estruturas necessárias para rodar a aplicação sem
81
problemas. Essas estruturas supracitadas são as classes apresentadas nos diagramas de classes
das Figura 8 e Figura 50 presente no Apêndice B.
Figura 21 – Diagrama de atividades do sistema gerenciador de dicionário

Figura 22 – Realizando engenharia reversa

Uma vez com a engenharia reversa executada é possível criar a tabela com suas colunas,
índices e chaves estrangeiras, no qual deseja-se gerar os códigos-fontes, escolhendo a opção
com o ícone de mais ao lado da palavra Tabelas no menu lateral a esquerda da tela, chamado
Estruturas, conforme apresentado na Figura 22. Com a funcionalidade de adição de tabelas
82
aberta no sistema gerenciador de dicionário, são acrescentadas as informações pertinentes a

tabela como as colunas, os índices e as chaves estrangeiras, conforme as Figura 23 até a Figura
25. Nesse exemplo, foi incluído uma tabela chamada USUARIOS com informações pertinentes a
alguma pessoa que utilizará um segundo software, considerado nesse caso, legado,
desenvolvido em Pascal, como o NOME, SENHA, DATA_NASCIMENTO do usuário etc.
Figura 23 – Criando uma nova tabela, colunas da tabela

Figura 24 – Criando uma nova tabela, índices da tabela

83
Figura 25 – Criando uma nova tabela, chaves estrangeiras da tabela

Com a criação da tabela efetuada no sistema gerenciador de dicionário é necessário
proceder com a conversão do banco de dados, a fim de efetivar a nova tabela no SGBD. Para
isso é necessário escolher a opção Conversão no menu superior da tela, posteriormente
carregar e por último, executar as conversões pendentes, conforme destacado na Figura 26.
Nessa funcionalidade, é possível visualizar uma breve descrição do tipo de conversão, o usuário
responsável pela alteração e a data da alteração, bem como o script a ser executado no SGBD
pelo sistema após selecionar a opção executar.
Figura 26 – Convertendo a base de dados

84
Também é possível consultar o histórico de conversões da base de dados, escolhendo a

opção Histórico de conversões no menu superior da aplicação, conforme destacado na
Figura 27. Essa funcionalidade não está classificada como pré-requisito para geração dos
códigos-fontes, sendo apenas um opcional do sistema gerenciador de dicionário para auxiliar
os analistas.
Figura 27 – Consultando o histórico de conversões do SGBD

Por fim, com todas as etapas anteriores concluídas, deve-se selecionar a opção no menu
superior do sistema, chamado Gerar fontes, escolher as opções de geração de arquivos e
posteriormente em Gerar fontes, conforme destacado na Figura 28.
Figura 28 – Gerando códigos-fontes de dicionário e tabelas

85
Na Figura 29 é apresentada a saída gerada pelo botão Gerar fontes da Figura 28. Os
arquivos ficam disponíveis ao usuário em compactação zip e em formato de código-fonte
Pascal para serem executados posteriormente em ambiente de desenvolvimento Delphi. Esses
arquivos gerados resolvem apenas a questão de conexão da aplicação Pascal com o SGBD
Oracle, possibilitando auxiliar na construção de CRUDs em Delphi utilizando esses códigos-
fontes. Os detalhes individuais de cada arquivo gerado pelo sistema gerenciador de dicionário
são apresentados na seção 3.3.5.
Figura 29 – Arquivos Pascal gerados pelo sistema
3.4 ANÁLISE DOS RESULTADOS
Nesta seção serão apresentados os resultados adquiridos a partir da avaliação de

velocidade e desempenho utilizando a ferramenta PageSpeed. Também é apresentada a
avaliação de vulnerabilidade utilizando as ferramentas Suip.biz e Pentest-tools. Além disso, foi
realizada uma avaliação de carga com uso prática em uma base de dados de sistema comercial.
As avaliações de velocidade, vulnerabilidade e carga são apresentadas no apêndice C.
Para análise do segundo objetivo específico foi realizada uma avaliação de usabilidade
com 28 heurística de padrões de usabilidade de SAPO (2022) e uma demonstração de utilização
do sistema, com o intuito de comprovar seu correto funcionamento. Por fim, é apresentado um
comparativo dos trabalhos correlatos com o sistema desenvolvido.
86
3.4.1 Avaliação de usabilidade
Para a avaliação de usabilidade, foram utilizadas heurísticas de usabilidade a fim de

identificar se o sistema está adequado o suficiente para uma boa experiência entre os usuários
que utilizarão a aplicação desenvolvida. Para este teste, utilizou-se as métricas de usabilidade
do SAPO.UX (2022) no desenvolvimento do sistema, as quais foram validadas posteriormente
pelo autor deste trabalho, sendo considerado o especialista. Dentre esse conjunto de métricas
existem 28 heurísticas organizadas em 8 blocos distintos, sendo eles: navegação e Feedback;
layout; legibilidade; formulários e mensagens; ajuda; redes sociais; responsive e performance
(SAPO, 2022). Cada heurística foi validada e seus problemas foram elencados, sendo exibidos
no Quadro 36 como um resumo relacionando as heurísticas com problemas identificados por
blocos.
Quadro 36 – Relacionamento de Heurísticas e Problemas Identificados por Blocos
Blocos Número de Heurísticas Número de Problemas
relacionadas encontrados
Navegação e Feedback 8 1
Layout 5 1
Legibilidade 4 0
Formulários e Mensagens 5 2
Ajuda 2 1
Redes sociais 1 1
Responsive 1 0
Performance 2 2
Observando o Quadro 36 é possível identificar que em 20 das 28 heurísticas não
constaram problemas, o que representam 71,42% de heurísticas presentes no sistema para uma
boa experiência de usabilidade. Para as oito heurísticas que apresentaram problemas, são
consideradas problemáticas parcialmente ou totalmente, em razão ao que as heurísticas
estipulam como critério, isso representa 28,58% do total de pontos de verificação.
A seguir são apresentadas as heurísticas em que o sistema desenvolvido não se enquadra
nos padrões de usabilidade:
a) os itens não clicáveis não se parecem com links ou botões: quando um link ou botão
não estão clicáveis o aspecto visual do sistema não é alterado a fim de retratar ao
usuário que o acesso a funcionalidade está indisponível;
b) existe uma folha de estilos específica para impressão: o sistema não está adequado
o suficiente para atender essa heurística, ou seja, o tamanho das páginas pode não
atender 100% o tamanho mínimo recomendado para uma impressão físicas das
funcionalidades;
87
c) as mensagens de erro estão junto dos elementos que contêm o erro: o sistema atente
parcialmente essa heurística. Nos formulários que não possuem grade ou tabelas, a
mensagem de erro acompanha o campo, porém quando há um erro dentro de uma
grade ou tabela, a mensagem é exibida fora do contexto em que se localiza o erro;
d) as ações principais são claramente distinguíveis das ações secundárias nos
formulários: o sistema não deixa claro para o usuário a diferença entre as principais
informações das secundárias, como por exemplo, campos opcionais e obrigatórios;
e) existe ajuda contextual nas interações mais complexas: o sistema não fornece dicas
quanto a sua utilização, apenas emite aviso de erro e uma possível solução do
problema, mas uma documentação de ajuda não está disponível;
f) foram adicionadas as tags “Open Graph”: o sistema não inclui nenhuma tag Open
Graph para partilhas de redes sociais;
g) todos os ficheiros estáticos foram minificados e comprimidos: o sistema não está
adequado para otimizar a performance das figuras, dos arquivos e dos ficheiros;
h) os conteúdos foram optimizados para mobile: o sistema não está adequado para
utilização em dispositivos móveis, tanto para a questão de performance quanto para
o redimensionamento de telas pequenas.
3.4.2 Avaliação de usabilidade por demonstração
Para avaliar o correto funcionamento da aplicação, essa subseção irá demonstrar o

funcionamento do sistema, desde a criação de uma tabela para atender a necessidade de um
cadastro de clientes, escrito em código-fonte Pascal, até a conversão e geração de fonte pascal.
Assim, será considerada a necessidade de gravação de informações sobre clientes com as
características do Quadro 37.
Quadro 37 – Necessidade de armazenar clientes no banco de dados em um sistema legado

Para criar uma tabela que atenda ao cadastro de clientes com nome, razão social,
telefone e endereço, cria-se a tabela utilizando o sistema gerenciador de dicionário conforme
a Figura 30.
88
Figura 30 – Criando uma tabela CLIENTES no sistema gerenciador de dicionário

No passo número um indicado em vermelho na Figura 30 é aberta no sistema a
funcionalidade de criação de tabelas. Nos passos 2, 3 e 4 desta mesma figura, são informadas
as colunas, os índices e as chaves estrangeiras ligadas a essa necessidade. Aqui vale destacar
que foi acrescentada uma coluna ID numérica única, por questão de normalização de banco de
dados. Também é destacado que não há chaves estrangeiras nesse modelo de dados para
cadastro de clientes.
Na Figura 31 é apresentada a interface gráfica para adição, edição e exclusão de índices
da tabela. Para essa necessidade, foi criado um índice primário chamado PK_CLIENTES_ID, por
questões de normalização de banco de dados. Assim, tem-se um identificador único para cada
cliente que for inserido na base de dados, tornando pesquisas por clientes no sistema legado
mais velozes em comparação a uma mesma tabela sem esse par de ID com índice primário.
89
Figura 31 – Adicionando uma chave primária a nova tabela CLIENTES

Após todas as informações adicionadas e conferidas para um cadastro de clientes, é
efetuada a gravação dessa tabela no sistema gerenciador de dicionário e sua saída é apresentada
na Figura 32.
Figura 32 – Gravação da nova tabela CLIENTES realizada com sucesso

Ainda na Figura 32, é possível identificar que a nova tabela CLIENTES já se encontra
visível no menu lateral principal do sistema gerenciador de dicionário. Com isso, é possível
realizar a geração do código-fonte Pascal, porém a base de dados ainda não foi convertida e
que, portanto, essa tabela não existe no SGBD, apenas nas estruturas do sistema gerenciador de
dados, conforme apresentado na Figura 33.
90
Figura 33 – PL/SQL Developer indicando que a tabela CLIENTES não existe no SGBD Oracle

Para que essa nova tabela CLIENTES seja criada de fato no SGBD Oracle, é necessário
acessar a funcionalidade de conversão no sistema gerenciador de dicionário e realizar a
conversão com a criação dessa nova tabela CLIENTES, conforme apresentado na Figura 34.
Figura 34 – Conversão do SGBD pelo sistema gerenciador de dicionário

Na Figura 34 é possível identificar que há uma descrição da alteração feita pelo usuário,
um registro de qual usuário o fez e também uma data de realização. Por questões de
transparência também é possível visualizar todos os comandos DDLs gerados pela alteração do
usuário na interface web e que serão executados no SGBD Oracle após selecionar a opção
Converter.
Com a conversão de criar a nova tabela CLIENTES realizada, é conferido se de fato essa
tabela foi criada no SGBD Oracle, para que o sistema legado posteriormente venha a cadastrar
valores nessa nova tabela. Essa checagem é apresentada na Figura 35.
91
Figura 35 – Nova tabela CLIENTES criada com sucesso no SGBD Oracle

Agora que há a tabela CLIENTES gerada no SGBD Oracle, é possível gerar o código-
fonte Pascal que possibilitará ao programa do sistema legado criar um formulário para cadastro
de clientes. Para isso, é necessário acessar a funcionalidade de gerar fontes no menu superior
do sistema gerenciador de dicionário, selecionar a tabela CLIENTES e clicar em gerar fontes,
conforme destacado na Figura 36.
Figura 36 – Gerando código-fonte Pascal utilizando o sistema gerenciador de dicionário

Os arquivos que o sistema gerenciador de dicionário gera são apresentados na Figura 37.
Com eles é possível desenvolver um formulário para cadastro de clientes no sistema legado em
Pascal.
92
Figura 37 – Códigos-fonte Pascal gerados pelo sistema gerenciador de dicionário

Dando continuidade à avaliação de funcionalidade, foi desenvolvido uma espécie de
sistema legado modelo para o cadastro de clientes com os fontes gerados pelo sistema
gerenciador de dicionário e sua montagem é apresentada na Figura 38.
Figura 38 – Formulário para cadastro de clientes desenvolvido em Pascal

Para um teste inicial, foi realizado o cadastro de um cliente novo pelo sistema legado,
apresentado na Figura 39 e a validação se o registro foi inserido com sucesso apresentado na
Figura 40.
93
Figura 39 – Inserindo um novo cliente pelo sistema legado desenvolvido sobre os fontes
gerados pelo sistema gerenciador de dicionário

Na apresentação da Figura 39 foram informados os dados William Mello para o nome,
09882185935 para a razão social, 997722526 para o telefone e Rua Capinsal, 187, Garcia,
Blumenau para o endereço. Na sequência, foi selecionado o botão Gravar para confirmar as
informações no SGBD Oracle.
Figura 40 – Checagem de inserção do novo cliente direto no SGBD Oracle pelo PL/SQL
Developer

Conforme destacado na Figura 40, as informações foram inseridas com sucesso no
SGBD Oracle. Supondo uma segunda necessidade em gravar a data de cadastro de novos
clientes, bem como agilizar a pesquisa pelo nome de clientes no sistema legado, será realizada
a seguinte alteração: acrescentado uma nova coluna chamada DATA_CADASTRO do tipo
DateTime e acrescentado um índice normal chamado IND_CLIENTES_NOME, conforme
destacado na Figura 41 e Figura 42.
94
Figura 41 – Acrescentando uma nova coluna DATA_CADASTRO na tabela CLIENTES

Figura 42 – Acrescentando um novo índice PK_CLIENTES_ID na tabela CLIENTES

Uma vez com as alterações de dicionário efetuadas com sucesso, será necessário
executar a conversão com as alterações no SGBD Oracle, para que existe uma nova coluna
chamada DATA_CASDASTRO e um novo índice normal chamado PK_CLIENTES_NOME, conforme
apresentado na Figura 43.
95
Figura 43 – Conversão da nova coluna DATA_CADASTRO e do novo índice

IND_CLIENTES_NOME

Para garantir que a coluna e o índice tenham sidos criados no SGBD Oracle, após a
conversão com sucesso é realizada a verificação na Figura 44 e na Figura 45.
Figura 44 – Conferindo a criação da coluna DATA_CADASTRO na tabela CLIENTES

Figura 45 – Conferindo a criação do novo índice IND_CLIENTES_NOME na tabela CLIENTES

Após a conferência das informações do lado do SGBD Oracle, será gerado o código-
fonte novamente da tabela CLIENTES com a nova coluna DATA_CADASTRO para efetivar sua
implementação a cada novo cliente cadastro no sistema legado, conforme apresentado na Figura
46.
96
Figura 46 – Código-fonte Pascal gerado pelo sistema gerenciador de dicionário com a nova
coluna e novo índice

Com os códigos-fontes gerados com sucesso, é realizado o desenvolvimento no sistema
legado acrescentando essa nova coluna de data do cadastro de um novo cliente. Essa
implementação pode ser vista no Quadro 38, na linha 127.
97
Quadro 38 – Acrescentando a DATA_CADASTRO no código-fonte Pascal do sistema legado e

compilando-o

Com o sistema legado compilando e funcionando após a alteração em seu código-fonte
Pascal, é realizada a inserção de um novo cliente, com a finalidade verificar se as rotinas geradas
pelo sistema gerenciador de dicionário cumprem seu papel. O novo cliente inserido é
apresentado na Figura 47.
98
Figura 47 – Inserindo um novo cliente no SGBD Oracle

Conforme destacado na Figura 47, foi informado um novo cliente com as informações
EUCLIDES PIRES para o nome, 25416384545949 para a razão social, 98785875325 para o
telefone e Rua Amazonas 123, Garcia, Blumenau para o endereço. Após informar esses dados
foi selecionado o botão Gravar do sistema legado para efetivar a inserção no SGBD Oracle.
Como a data de cadastro do cliente é alimentada apenas no momento de inserção do
registro, não sendo visível para o usuário que o cadastrou em formulário, é realizada uma
checagem direto no SGBD Oracle para conferir se essa nova coluna da tabela CLIENTES foi
inserida com sucesso após todos os ajustes em dicionário e código-fonte Pascal. Essa checagem
é apresentada na Figura 48.
Figura 48 – Conferência do valor na nova coluna DATA_CADASTRO da tabela CLIENTES

Conforme destacado na Figura 48, as alterações realizadas tanto em dicionário utilizando
o sistema gerenciador de dicionário quanto no código-fonte Pascal, foram efetuadas com
sucesso.
99
3.4.3 Comparativo dos correlatos com o sistema gerenciador de dicionário
O Quadro 39 mostra o comparativo entre os trabalhos correlatos apresentados nas seções

anteriores a este trabalho. Nas linhas são referenciadas as funcionalidades enquanto que nas
colunas ficam os trabalhos correlatos.
Quadro 39 – Comparativo dos trabalhos correlatos
Ferramenta de Ferramenta de Sistema
Trabalhos Correlatos Web Modeler geração engenharia gerenciador
2.0 Model-View- reversa de de
Características (BUGMANN, Controller banco de dados dicionário
2012) (SOTO et al., (ZAFAR et al.,
2020) 2019)
Engenharia reversa de banco de X X X X
dados
Geração de código-fonte X X
Criação e edição de diagramas da X X
UML
Utilizado padrão de projeto MVC X
Ferramenta web X X X
Geração de arquivo XMI 2.1 X
Gerenciamento de estruturas de X X X X
banco
Conforme apresentando no Quadro 39 todas as ferramentas realizam engenharia reversa
e gerenciam as estruturas de SGBDs, sendo as principais funcionalidades do trabalho
desenvolvido. Dentre elas, apenas as ferramentas Web Modeler (BUGMANN, 2012) e
Ferramenta de geração Model-View-Controller (SOTO et al., 2020) estão desenvolvidas na
plataforma Web. Apenas a Ferramenta de geração Model-View-Controller (SOTO et al., 2020)
permite a geração de código-fonte e apenas o Web Modeler (BUGMANN, 2012) utilizou o
padrão de projeto MVC. A geração de arquivos XMI 2.1 só foi implementada na Ferramenta
de engenharia reversa de banco de dados de Zafar et al. (2019).
O sistema apresentado engloba parcialmente algumas das funcionalidades de cada
trabalho correlato apresentado no Quadro 39. Permite por meio de uma interface gráfica Web
manter as tabelas, seus campos e seus relacionamentos presentes nos SGBDs Oracle, realizar
consultas nos metadados com o propósito de descobrir informações da estrutura dos SGBDs e
transformá-las em informações gráficas de alto nível de abstração, como por exemplo, textos,
ilustrações etc. Desta forma, este trabalho possibilita gerar código-fonte para Object Pascal
(Delphi) com as estruturas de tabelas e seus campos, a fim de auxiliar na conexão entre sistema
legado e o banco de dados Oracle, ou seja, na manutenibilidade de sistemas construídos sobre
essa linguagem de programação. O sistema também permite por meio de interface gráfica a
conversão e atualização automática dos SGBDs com as alterações realizadas nas tabelas,
100
campos e relacionamentos dentro da interface gráfica, para reduzir desgastes com execução
unitária de comandos DML e DDL.
O sistema desenvolvido além de unificar as funcionalidades de todos os correlatos,
possui o diferencial de permitir ao usuário gerar código-fonte Pascal para linguagem de
programação Object Pascal auxiliando na manutenibilidade de sistemas legados escritos nessa
linguagem.
101
4 CONCLUSÕES
Para este trabalho foi desenvolvido um sistema para gerenciamento de dicionário e

banco de dados Oracle para auxiliar no processo de desenvolvimento e manutenibilidade de
sistemas comerciais. A implementação foi realizada por meio do editor de código Visual Studio,
utilizando a linguagem de programação C# (C Sharp) para o back-end. Já para o front-end foi
utilizado o editor de código Visual Studio Code, utilizando a linguagem de programação
Javascript. Para hospedagem do servidor Web foi utilizada a ferramenta Wampserver em
máquina local (localhost) e serviço da No-ip para acesso remoto da aplicação fora da rede local.
Para geração de código-fonte Pascal foi utilizado o editor de código Delphi e PL/SQL para
acesso ao SGBD Oracle durantes os testes.
O primeiro objetivo específico que é fornecer uma Unit em Pascal conforme a estrutura
configurada na interface gráfica para facilitar a conexão do sistema legado ao banco de dados
foi alcançado, pois o sistema entrega uma interface gráfica com usabilidade acima da média
para geração de código-fonte Pascal. Nesse código-fonte Pascal são fornecidos códigos
relativos a conexão, execução de consulta, inserção, remoção e atualização as tabelas
disponíveis na interface gráfica para editor de código Delphi e sistemas legados.
O segundo objetivo específico que é disponibilizar a aplicação web com boa usabilidade
seguindo os padrões de usabilidade para web também foi alcançado, mesmo não atingindo
100% de usabilidade, conseguindo entregar uma usabilidade acima média. Do total de 100%,
alcançou 71,42% de heurísticas atendidas, seguindo o modelo de SAPO (2022) para avaliação
de usabilidade do sistema.
Dessa forma, com os objetivos específicos alcançados, tem-se que o objetivo geral do
trabalho foi atendido, disponibilizando um sistema que auxilia no processo de desenvolvimento
e manutenibilidade de sistemas comerciais, gerando código-fonte Pascal funcional, oferecendo
CRUDL de tabelas do banco, convertendo banco de dados e gestão de usuários e com qualidade
acima da média de usabilidade. Até o presente momento esse sistema não está em utilização
por nenhuma empresa comercial que desenvolve sistemas em código-fonte Pascal, porém esse
trabalho será continuado com melhorias e novas funcionalidades pelo autor desse trabalho.
A falta de experiência como desenvolvedor destacou-se como a maior dificuldade
encontrada. Este foi o primeiro projeto fullstack desenvolvido pelo autor nessa magnitude, com
integração 100% funcional entre front-end e back-end, visto que o autor apenas possui vivência
com sistema em código-fonte Pascal. Por outro lado o controle, configuração e manuseio de
banco de dados Oracle foi considerado relativamente simples pelo autor, pois o mesmo já
102
possuía vivências com SGBDs Oracle. Mesmo possuindo dificuldades com o desenvolvimento
do sistema web, a documentação disponível pelas empresas docentes das linguagens, ajudou
com significativa contribuição, com exemplos, dicas e recomendações de boas práticas em
programação.
As limitações encontradas no sistema consistem em não possuir controle para manter
sequences e falta de suporte para colunas de tabelas dos tipos: auto-sequence; enumerador;
boolean; BLOB; CLOB; e CRUDL de jobs.
No âmbito tecnológico esse sistema contribui com a melhor organização estrutural de
bancos de dados dos sistemas interessados em utilizar o sistema de auxílio no processo de
engenharia de software, possibilitando a redução do tempo gasto no processo de engenharia de
sistemas e melhorando a manutenibilidade deles.
Como contribuição científica, este trabalho compartilha as avaliações realizadas sendo
uma a partir de um questionário de usabilidade consolidado de SAPO (2022) e outra a partir de
uma ferramenta de desempenho da Google, o Page Speed. Com o uso desses recursos, pode-se
avaliar a usabilidade de um sistema e seu desempenho. Também compartilha das avaliações de
vulnerabilidades, das ferramentas Suip.biz e Pentest-tools, com o intuito de avaliar se o sistema
possui um bom nível de segurança. Por fim, um teste de carga funcional, aplicando sobre uma
base de dados real de um sistema comercial, com o intuito de deferir tempos de processamento.
Os resultados apresentaram, mesmo sem interferir seu funcionamento, algumas
limitações quando comparado com os trabalhos correlatos, principalmente referente ao
gerenciamento de tabelas e padrões de usabilidade. As sugestões de extensões, constantes na
subseção 4.1 visam atender a adequação às heurísticas de usabilidade, aprimorando o feedback
e a boa experiência de usuário, além de garantir mais segurança em autenticação de usuário,
bem como acrescentar mais funcionalidades ao sistema desenvolvido.
4.1 EXTENSÕES
Nesta seção são apresentadas possíveis extensões ou melhorias. Os pontos de extensões

observados do trabalho são:
a) geração de códigos-fontes para diversas linguagens de programação;
b) compatibilidade com diversos SGBDs;
c) acrescentar controle CRUDL para jobs;
d) acrescentar diversos tipos de dados para as colunas das tabelas;
e) acrescentar controle CRUDL para sequences;
f) acrescentar controle para colunas de tabelas auto-sequence;
103
g) acrescentar controle de login por token;

h) melhorar filtros de pesquisa de funcionalidades de consultas em grade;
i) melhorar visualização das grades de consultas com paginações;
j) acrescentar mecanismo de pesquisa no rodapé do menu lateral principal.
104
REFERÊNCIAS
AIRES, Paulo João et al. Usando o padrão Dublin Core para definição de metadados de
imagens médicas. Revista eletrônica Fafit/Facic, Itararé-SP, v. 4, n. 2, p. 1-12, Dez. 2013.
ALVES, C. D. Metadados para a Recuperação de Imagens na WEB: utilizando o software
ADOBE BRIDGE. Revista eletrônica PontodeAcesso, Minas Gerais, v. 6, n. 1, p. 32–48,
Jun. 2012.
BARBOSA, Pedro L. S.; CANDIDO, Adriano L. Diferenças entre engenharia reversa e
reengenharia nos sistemas de informação. Revista interfaces, Icó-CE, v. 4, n. 13, Dez. 2017.
BUGMANN, Paulo Alberto. Ferramenta Web para modelagem lógica em projetos de
bancos de dados relacionais. 2012. 84 f., il. Trabalho de Conclusão de Curso (Graduação em
Ciência da Computação) - Centro de Ciências Exatas e Naturais, Universidade Regional de
Blumenau, Blumenau, 2012.
CATARINO, Maria Elisabete; BAPTISTA, Ana Alice Rodrigues Pereira. Ontologia stap:
um vocabulário de termos de metadados. In ENCONTRO NACIONAL DE PESQUISA EM
CIÊNCIA DA INFORMAÇÃO (ENANCIB), 11, Rio de Janeiro, Brasil, 2010.
CODD, E. F. A relational model for large shared data banks. Communications of the ACM,
Califórnia, v. 13, n. 6, p. 377-387, Jun. 1970.
FERREIRA, M. K. et al. Customização do DSpace para sincronizar diferentes fontes de dados
e padrões de atualização: o caso do repositório digital da UFRGS. In: Actas TICAL 2012.
Proceedings... Lima : RedCLARA, 2012. p. 364.
HASEGAWA, F. M.; AIRES, J. P. Proposta de um padrão de metadados para imagens
médicas. In: XIV ERI-PR 2007 ISBN: 978-85-7669-115-0 48, 2007, Ponta Grossa. Anais...
Ponta Grossa: UTFPR, 2007. p. 48-56.
KRASNER, Glenn E.; POPE, Stephen. A Description of the Model-View-Controller User
Interface Paradigm in the Smalltalk80 System. Journal Of Object Oriented Programming,
Santa Bárbara-CA, v. 1, Jan. 1988.
PFLEEGER, Shari Lawrence. Engenharia de Software: teoria e prática, 2. ed. São Paulo:
Pearson, 2007.
PINTO, Herbert L. M.; BRAGA, José L. Sistemas legados e as novas tecnologias: técnicas de
integração e estudo de caso. Informática Pública, v. 7, n. 1, p. 48-69, 2004.
PINTO, Herbert L. M.; BRAGA, José L. Sistemas legados e as novas tecnologias: técnicas de
integração e estudo de caso. Informática Pública, v. 8, n. 1, p. 47-69, 2005.
PRESSMAN, R. S. Engenharia de Software: uma abordagem profissional, 7. ed. Porto
Alegre: AMGH, 2011.
SANTOS, Ademir C.; BIANCHINI, Calebe P. Engenharia reversa de um sistema pdv.
2019. 15 f. Trabalho de conclusão de Curso (Graduação em Sistemas de Informação) -
Faculdade de Computação e Informática, Universidade Presbiteriana Mackenzie, São Paulo.
SAPO. Usabilidade (Web): checklist de pontos de verificação. [S.I.], [2022?]. Disponível
em: https://ux.sapo.pt/checklists/usabilidade. Acesso em: 24 jun. 2022.
105
SOTO, Jésus et al. . In: INTERNATIONAL CONFERENCE IN SOFTWARE

ENGINEERING RESEARCH AND INNOVATION (CONISOFT), 8, 2020, Quintana Roo.
Proceedings... Mexico: International Conference in Software Engineering Research and
Innovation (CONISOFT), 2020. p. 1-7.
VIEIRA, Luiz Flavio. Comparação de performance de sistemas gerenciadores de banco
de dados. 2020. Monografia (Bacharelado em Ciência da Computação) - Universidade
Tecnológica Federal do Paraná, Medianeira.
ZAFAR, Sherin et al. Reverse Engineering of Relational Database Schema to UML Model.
In: INTERNATIONAL CONFERENCE ON ELECTRICAL, ELECTRONICS AND
COMPUTER ENGINEERING (UPCON), 6, 2019, Nova Jersey. Proceedings… Nova Jersey:
International Conference on Electrical, Electronics and Computer Engineering (UPCON),
2019. p. 1-6.
106
APÊNDICE A – Modelo entidade relacionamento
Esse apêndice apresenta em detalhes o diagrama de Modelo entidade relacionamento do

banco de dados do sistema gerenciador de dicionário. Vale destacar que existem algumas
tabelas desenvolvidas que não foram contempladas no sistema por nenhum requisito ou
objetivo.
Na Figura 49 é apresentado graficamente a modelagem das tabelas do sistema, por meio
do diagrama de Modelo entidade relacionamento. A seguir é apresentado uma breve descrição
das tabelas relacionadas ao sistema gerenciador de dicionário:
a) dic_users: tabela responsável por armazenar os usuários para acesso e utilização
da ferramenta web;
b) dic_permissions: tabela responsável por armazenar as permissões de acesso as
funcionalidades da ferramenta;
c) dic_users_permissions: tabela intermediária, relacionada com a dic_users e
dic_permissions, responsável por indicar as permissões de acesso para cada
usuário;
d) dic_table: tabela responsável por armazenar as definições de tabelas do banco de
dados;
e) dic_table_columns: tabela relacionada com a dic_table, responsável por
armazenar as definições de cada coluna das tabelas;
f) dic_table_indexes: tabela relacionada com a dic_table, responsável por
armazenar as definições de cada índice das tabelas;
g) dic_indexes_columns: tabela intermediária, relacionada com a
dic_table_indexes e dic_table_columns, responsável por armazenar as
definições de cada coluna dos índices;
h) dic_foreign_keys: tabela relacionada com a dic_table, responsável por
armazenar as chaves estrangeiras das tabelas;
i) dic_foreign_keys_columns: tabela intermediária, relacionada com a
dic_foreign_keys e dic_table_columns, responsável por armazenar as
definições das colunas das chaves estrangeiras;
j) dic_conversion_queue: tabela responsável por armazenar os scripts de dicionário
que são rodados pela conversão automática da ferramenta;

k) dic_conversion_hist: tabela responsável por armazenar um histórico das
conversões automáticas da ferramenta;
107
l) dic_enumerates: tabela responsável por armazenar os enumeradores de dicionário

m) dic_enumerates_item: tabela relacionada com a dic_enumerates, responsável
por armazenar os itens dos enumeradores;
n) dic_sequences: tabela responsável por indicar as sequências auto incremento.
Estrutura extensível do trabalho, pois não foi desenvolvida e aplicada no sistema
Para toda tabela modelada, existe uma sequence, estrutura do banco de dados utilizada
para gerar um código numérico único (destacado em retângulo azul), atribuída as colunas ID
das mesmas e gerenciadas pelo back-end da aplicação. Isso se faz necessário pois o SGBD
Oracle não permite criar, nativamente, essas sequências automáticas. Portanto é necessário
gerar um controle manual externo ao SBGD para colunas auto incrementáveis.
108
Figura 49 – Modelo entidade relacionamento das tabelas do sistema

109
APÊNDICE B – Segunda parte do diagrama de classes
Esse apêndice apresenta em detalhes o a segunda parte do diagrama de classes da

aplicação, destacando em breves explicações o objetivo atribuído a cada classe e a estrutura
utilizada no sistema gerenciador de dicionário.
A Figura 50 apresenta a segunda parte do diagrama de classes da aplicação, tanto para o
front-end, quanto para o back-end.
Figura 50 – Segunda parte do diagrama de classes da aplicação.

A seguir são apresentadas breves descrições sobre as classes da segunda parte do
diagrama de classes (Figura 50):
a) DicUsers: representa os usuários cadastrados na aplicação;
b) DicPermissions: representa as permissões disponíveis na aplicação;
c) DicUsersPermissions: representa as permissões de cada usuário;
d) DicUsersCustom: classe especializada da DicUsers, com a responsabilidade de
guardar as permissões de cada usuário. Essa classe associa-se com a
DicPermissions;
e) DicConversionQueue: representa os scripts de conversões de banco de dados, bem

como o nome do usuário de alteração do banco de dados;
f) DicConversionQueueCustom: classe especializada da DicConversionQueue, com
a responsabilidade de guardar um textual dos scripts, facilitando a leitura dos scripts
de cada conversão;
g) DicConversionHist: representa o histórico de todas as conversões executadas na
DicConversionQueue;
h) DicConversionHistCustom: classe especializada da DicConversionHist, com a

responsabilidade de guardar um textual com os scripts convertidos, bem como o
110
nome do usuário que alterou e converteu a base de dados;

i) DicEnumerates: classe com objetivo de representar os enumeradores do dicionário.
Estruturalmente, não existe uma tabela no banco de dados correspondente a ela. Sua
existência é derivada do motivo em que as linguagens de programação permitem ao
programador criar enumeradores;
j) DicEnumeratesItem: classe com o objetivo de representar os itens de cada
enumerador criado para a classe DicEnumerates;
k) DicSequences: classe com intuito de representar as sequências criadas no banco de
dados, porém essa estrutura é extensível no trabalho devido a não implementação
no front-end.
111
APÊNDICE C – Avaliações de desempenho, vulnerabilidade e carga
Esse apêndice possui o propósito de demonstrar avaliações de desempenho, de

vulnerabilidade e de carga na aplicação. Esses testes são aplicados a sistemas de informação
com o intuito de quantificar ou qualificar de diversas formas o quão veloz é um sistema, o quão
seguro é um sistema e o quão boa é sua operacionalidade sobre estresse excessivo.
Para avaliar o desempenho quanto a velocidade do sistema foi utilizada a ferramenta
PageSpeed da Google. Ela avalia o carregamento dos arquivos da página web e a velocidade de
interação dos elementos no front-end do sistema, bem como a otimização e compactação dos
arquivos responsáveis pela renderização dos elementos das páginas do sistema.
Na Figura 51 é apresentado o resultado dos testes da ferramenta PageSpeed. O sistema
alcançou 57% de desempenho geral, segundo a ferramenta, com 3,7 segundos de atraso para o
sistema realizar a primeira renderização dos conteúdos (first contentful paint), 3,7 segundos
para o índice de velocidade, 4,2 segundos para o carregamento da página (largest contentful
paint), 3,8 segundos para o tempo até a interatividade da página (time to interactive), 0
milissegundos para o tempo total de bloqueio e 0,005 CLS para mudança de layout cumulativa.
112
Figura 51 – Resultado dos testes da PageSpeed

Para a avaliação de vulnerabilidade do sistema, foram utilizadas duas ferramentas
distintas para avaliar de fato o quão seguro é o sistema, são eles Suip.biz e Pentest-tools. O
Suip.biz possui foco em detectar vulnerabilidade de SQL Injection, em tradução, Injeção de
SQL. Por meio desse SQL Injection um invasor possui a possibilidade de excluir estruturas,
registros, dados da aplicação em nível de banco de dados, sem qualquer autorização para
execução.
Já o Pentest-tools acaba ampliando os testes de vulnerabilidade a acessos de arquivos,
diretórios visíveis e as funcionalidades não autorizadas a invasores. Ele também faz checagens
em níveis de criptografia ao servidor e requisições feitas por ele, bem como sugere algumas
possíveis melhorias para segurança do sistema como um todo, a fim de ajudar a evitar acessos
não autorizados.
Apresentando a primeira ferramenta, tem-se o Suip.biz que solicita o endereço no qual
está hospedado o sistema para execução dos testes e realiza uma parametrização inicial
necessária para sua correta execução durante os testes, destacado no Quadro 40.
113
Quadro 40 – Endereço do sistema e parametrização a ser testado pelo Suip.biz

No Quadro 41 são destacados todos os tipos de injeções de SQL que o Suip.biz executa,
a fim de localizar alguma vulnerabilidade de Injeção de SQL no sistema da URL indicado no
Quadro 40. Mesmo o sistema gerenciador de dicionário sendo desenvolvido em banco de dados
Oracle, ele realiza tentativas para os bancos de dados MySQL, PostgreSQL, SQL Server de
diversos ângulos diferentes.
Quadro 41 – Execução do Suip.biz a procura de vulnerabilidades

No Quadro 42 é apresentado o resultado da execução dos testes do Suip.biz. É destacado
que todos os testes foram executados e não foi encontrado nenhuma vulnerabilidade para
Injeção de SQL para o sistema desenvolvido nesse trabalho.
Quadro 42 – Resultado da execução do Suip.biz

Um segundo teste de segurança, utilizando a ferramenta Pentest-tools, mostrou que há
algumas vulnerabilidades no sistema, classificando uma vulnerabilidade como alto risco, duas
vulnerabilidades como risco médio, seis vulnerabilidades de baixo risco e dez sugestões de
melhoria para o sistema, destacado na Figura 52. Para a vulnerabilidade de alto risco, a
ferramenta destaca que a versão utilizada pelo servidor Web Wampserver precisar estar mais
atualizada em nível de PHP, a fim de evitar possíveis invasores, como por exemplo, aceitar uma
URL com senha inválida como URL válida.
Já para as vulnerabilidades de médio risco, a ferramenta destaca que não há a utilização
de certificado digital e acesso HTTPS, pois como o sistema é publicado localmente, não está
114
utilizando esses recursos de segurança, bem como o servidor localhost foi liberado de diversas
formas para acesso remoto, como por exemplo, liberação de portas no firewall e liberação de
acesso global no servidor Web Wampserver. A ferramenta ainda destaca que através do servidor
Web Wampserver é possível um invasor explorar os diretórios e arquivos do mesmo, tornando
vulnerável arquivos sensíveis do sistema.
Para as vulnerabilidades de baixo risco, a ferramenta destaca que não há presença de
alguns cabeçalhos de segurança nas requisições HTTP feitas pelo sistema entre o front-end e
back-end, como por exemplo, a ausência do cabeçalho Content-Security-Policy, X-Frame-
Options, X-XSS-Protection, X-Content-Type-Options e Referrer-Policy. Nessa etapa, a
ferramenta Pentest-tools também destaca novamente que as versões dos serviços utilizados
estão visíveis há possíveis invasores e que isso pode ser usado em desfavor do sistema para
ataques não autorizados.
No geral, apesar de haver algumas vulnerabilidades médias e altas identificadas pela
ferramenta Pentest-tools, a aplicação possui um nível de segurança adequado, pois boa parte
das vulnerabilidades estão ligadas ao servidor Web no localhost.
Figura 52 – Resultado da avaliação de segurança do Pentest-tools

115
Para a avaliação de carga da aplicação foi utilizado um banco de dados Oracle em

servidor local (dblocal) de um cliente da empresa em que o autor desse trabalho presta serviço.
Essa base de dados foi exportada do cliente e importada em servidor local (localhost). Essa base
de dados possui como tamanho aproximado de 7,04 GigaBytes e o tamanho da Tablespace
possui aproximadamente 7,35 GigaBytes, destacado na Figura 53.
Figura 53 – Tamanho da Tablespace e da base de dados utilizada no teste de carga

Como a funcionalidade de engenharia reversa de banco de dados desenvolvido no
trabalho processa todas as tabelas do SGBD para as estruturas internas do sistema (apresentada
no Apêndice A), a quantidade de tabelas disponíveis no banco acaba influenciando a
performance de execução dos algoritmos necessários para concluir a engenharia reversa. Nessa
base de dados emprestada para os testes, possuem 3.666 tabelas para serem processadas pelo
sistema gerenciador de dicionário, destacado na Figura 54.
Figura 54 – Quantidade de tabelas processadas pelo sistema no banco de dados

Como dados estatísticos da execução da engenharia reversa, chegou-se aos resultados
performáticos apresentados na Tabela 1 e também destacados na Figura 55. Vale frisar que o
tempo dos processos são relativos a performance do computador/servidor e também do banco
de dados.
Tabela 1 – Tempos de execução de cada processo da engenharia reversa em segundos
Processo Tempo necessário (segundos)
Excluir todas as estruturas existentes 1,458
Descobrir todas as tabelas 0,53
Descobrir todas as colunas das tabelas 6,349
Descobrir todos os índices das tabelas 3,09
Descobrir todas as colunas dos índices das tabelas 1,068
Descobrir todas as chaves estrangeiras das tabelas 5,253
Descobrir todas as colunas das chaves estrangeiras das tabelas 7,028
Criar a estrutura de fila de conversão 0,058
Criar a estrutura de histórico de conversões 0,058
Criar a estrutura de enumerados 0,053
Criar a estrutura com os itens de enumerados 0,060
Criar a estrutura de sequências 0,093
Total 25,10
116
Figura 55 – Tempo em milissegundos de cada processo da engenharia reversa

TCC - Sistema Gerenciador de Base de Dados e Dicionário

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

TCC - Sistema Gerenciador de Base de Dados e Dicionário

Enviado por

Direitos autorais:

Formatos disponíveis

UNIVERSIDADE REGIONAL DE BLUMENAU

CENTRO DE CIÊNCIAS EXATAS E NATURAIS

CURSO DE CIÊNCIA DA COMPUTAÇÃO – BACHARELADO

SISTEMA GERENCIADOR DE BASE DADOS E DICIONÁRIO

SISTEMA GERENCIADOR DE BASE DADOS E DICIONÁRIO

Trabalho de Conclusão de Curso apresentado

Profa. Luciana Pereira de Araújo Kohler, Mestra - Orientadora

Esse trabalho apresenta o desenvolvimento de um sistema web para gerenciamento de

Palavras-chave: Sistemas legados. Engenharia reversa. Metadados.

Key-words: Legacy systems. Reverse engineering. Metadata.

Figura 1 – Engenharia reversa de banco de dados de um SGBD ............................................. 23

API – Application Programming Interface

BLOB – Binary Large Object

CASE – Computer-Aided Software Engineering

CLOB – Character Large Object

CLS – Cumulative Layout Shift

CNPJ – Cadastro Nacional de Pessoas Jurídicas

CPF – Cadastro de Pessoa Física

CRUD – Create Read Update Delete

CRUDL – Create, Read, Update, Delete, List

Lista de tabelas CSS – Cascading Style Sheets

DAO – Data Access Object

DBA – Database Administrator

DDL – Data Definition Language

DML – Data Manipulation Language

DNS – Domain Name System

DOM – Document Object Model

HTML – HyperText Markup Language

IDE – Integrated Development Environment

JSON – JavaScript Object Notation

MER – Modelo Entidade Relacionamento

MVC – Model View Control

RNF – Requisito não funcional

SGBD – Sistema Gerenciador de Banco de Dados

SQL – Select Query Language

SUS – System Usability Scale

UC – Use Case (Caso de uso)

UML – Unified Modeling Language

XMI – XML Metadata Interchange

XML – eXtensible Markup Language

Em muitos sistemas legados, segundo Zafar et al. (2019) a manutenibilidade se torna

que possibilita administrar Sistemas Gerenciadores de Banco de Dados (SGBD) e foi

O objetivo deste trabalho é disponibilizar um sistema web que permita a manipulação

2.1 SISTEMA LEGADO

2.2 ENGENHARIA REVERSA

Segundo Pressman (2011) apud Santos e Bianchini (2019), engenharia reversa é o

funcionamento do mesmo, para alterar ou realizar manutenções futuras, ou até mesmo

Figura 1 – Engenharia reversa de banco de dados de um SGBD

Fonte: elaborado pelo autor.

Fonte: elaborado pelo autor.

2.4 TRABALHOS CORRELATOS

2.4.1 FERRAMENTA WEB PARA MODELAGEM LÓGICA EM PROJETOS DE

Fonte: Bugmann (2012, p. 26).

Fonte: Bugmann (2012, p. 62).

2.4.2 UMA FERRAMENTA DE SOFTWARE PARA GERAR UMA ARQUITETURA

Fonte: Adaptado de Krasner e Pope (1988, p. 5).

Fonte: Soto et al. (2020, p. 61).

Na Figura 6 é ilustrada a arquitetura de implementação do trabalho dividida em duas

Fonte: adaptado de Soto et al. (2020, p. 61).

2.4.3 ENGENHARIA REVERSA DE BANCO DE DADOS RELACIONAL PARA

Zafar et al. (2019) apresenta uma ferramenta de conversão de esquema de banco de

generalização, tipo de entidade, relacionamentos de dependência, associação entre outras. Em

Neste capítulo são apresentados os processos utilizados para o desenvolvimento do