MODELAGEM DE DADOS E PROGRAMAÇÃO ORIENTADA A OBJETO INTEGRADOS AO 

DESIGN DE INTERFACES: DESENVOLVIMENTO DE UM SISTEMA DE CADASTRO E 
GERAÇÃO DE DOCUMENTOS 
 

Fernanda F. Serrate, Mestranda (UFRGS)  Rafael J. F. Puig, Mestrando (UFRGS) 

fernandaserrate@gmail.com  rafaelfpuig@gmail.com  
   
Fábio G. Teixeira, Dr. (UFRGS)  Underléa M. Bruscato, Dra. (UFRGS) 
fgtdsg@gmail.com  arq.leiab@gmail.com 
 
  

RESUMO 

Este  artigo  tem  por objetivo desenvolver um sistema para gerenciamento de informações e 

geração  de  documentos  acadêmicos  aliando  o  projeto  de  design  de  interface  com  o 
processo  de  programação  do  primeiro  protótipo  funcional.  A  partir  da  pesquisa  sobre  as 
necessidades  dos  usuários  e  aplicação  da  Programação  Orientada  a  Objeto  geraram-se 
requisitos e funcionalidades iniciais que pudessem ser contempladas no primeiro protótipo 
do  sistema  desenvolvido.  Objetiva-se com este estudo desenvolver um sistema que otimize 
o  processo  de  preenchimento  dos  documentos  necessários  à  realização  das  bancas  de 
defesa  de  Mestrado  e  Doutorado  do  PGDesign  UFRGS.  A  construção  do  projeto  baseou-se 
nos  procedimentos  metodológicos  voltados  ao  desenvolvimento  de  produtos 
dígito-virtuais,  integrando  às  etapas  projetuais  do  design  com  a  modelagem  de  dados  do 
banco  de  dados  e  o  desenvolvimento  do  sistema  através  da  Programação  Orientada  a 
Objeto.  ​Como  resultado,  obteve-se  uma  proposta  de  estrutura  projetual  que  poderá  ser 
investigada para uso em futuros projetos.  

Palavras-chave:  modelagem  de  banco  de  dados,  programação  orientada  ao  objeto, 
desenvolvimento de produto, design de interface.   
1. INTRODUÇÃO 

O  objetivo  principal  deste  artigo  é  apresentar  o desenvolvimento de um sistema de 

cadastro  e  busca  de  informações  de  alunos  e  professores  buscando  otimizar  o 
preenchimento  dos  documentos  necessários  à  realização  das  bancas  de  Mestrado  e 
Doutorado.  O  projeto  está  em  desenvolvimento  no  laboratório  de  pesquisa  Virtual  Design 
(ViD),  na  Faculdade  de  Engenharia  da  Universidade  Federal  do  Rio  Grande  do  Sul (UFRGS). 
O  sistema  em  questão  pode  ser  caracterizado  pela  integração  da  utilização  de  uma 
Linguagem  de  Programação  Orientadas  a  Objetos  (LPOO)  e  um  Bancos  de  Dados 
Relacionais (BDR) como mecanismo de persistência. 

O  projeto  consiste  no  desenvolvimento  de  um  sistema  de  cadastro  e  busca  de 
informações  de  alunos,  professores,  trabalho  e  bancas para otimizar o preenchimento dos 
documentos  necessárias  à  realização  das  bancas  de  defesa.  Atualmente  os  documentos 
são  preenchidos  manualmente,  de  forma  individual  em  processadores  de  textos  o  que 
despende  tempo  além  de  dificultar  a  padronização  gráfica  dos  materiais  institucionais  do 
Programa.  As  informações  são  armazenadas  em  um  banco  de  dados,  manipuladas 
diretamente  pelo  sistema.  Através  das  interfaces  gráficas  o  usuário  poderá  visualizar  e 
manipular  as  informações,  navegando  entre  os  cadastro  de  forma  segura  e  objetiva.  O 
acesso  às  informações  comuns  a  vários  alunos  e  professores  otimiza  o  processo,  assim 
como  informações  como  início  de  trabalho  e  término  de  trabalho  podem  ser  úteis  para  a 
gestão dos trabalhos ativos no PG. 

Fig. 1 - Representação gráfica do protótipo desenvolvido 

​Fonte: Elaborado pelos autores 

 A  partir  da  experiência  apresentada,  elaborou-se  um  modelo  a  partir  de  uma 
metodologia  projetual  para  o  desenvolvimento  de  produtos  dígito-virtuais,  onde  optou-se 
pelo  Projeto  E  (MEURER,  2014,  2009),  que  integra  as  camadas  de  desenvolvimento  do 
sistema.  Acredita-se  que  a  modelagem  de  dados  integrada  ao  desenvolvimento  das 
interfaces gráficas por meio de uma metodologia de design pode melhorar a elaboração de 
interfaces  de  sistemas  de  manipulação  de  informações  como  o  exemplificado  neste 
projeto. 

O  trabalho  está  organizado  da  seguinte  forma,  inicialmente  apresentamos  os 

princípios  que  embasaram  seu  desenvolvimento, ressaltando os conceitos principais sobre 
Orientação  a  Objetos,  Banco  de  Dados  Relacional  e  a  metodologia  projetual escolhida. Em 
seguida,  apresentamos  desenvolvimento  da  aplicação,  descrevendo  as  etapas de projeto e 
a sua implementação ao longo de seu desenvolvimento.  

2. FUNDAMENTAÇÃO TEÓRICA 

O  projeto  sustenta-se  em  estudos  realizados  sobre  Orientação  a  Objeto  (OO)  e 

modelagem  de  banco  de  dados  relacional  como  mecanismo  de  persistência.  Conceitos 
básicos  que  fundamentam  o  projeto  são  apresentados  nesta  seção  seguidos  pela 
metodologia projetual escolhida como base para os procedimentos desenvolvidos. 

2.1 Orientação a Objeto (OO) 

A  Orientação  a  Objetos  (OO)  se  preocupa  com  os  objetos e seus relacionamentos e 

introduz  uma  abordagem  na  qual  o  programador  visualiza  seu  programa  em  execução 
como  uma  coleção  de  objetos  cooperantes  que  se  comunicam  por  meio  de  trocas 
mensagens.  Uma  ​mensagem  ​é  uma  solicitação  para  que  um  objeto  execute  um  de  seus 
métodos.  O  método  solicitado  pode  alterar  o  estado  interno  do  objeto  e/ou  enviar 
mensagem  a  outros  objetos.  No  paradigma  da OO, dados e procedimentos fazem parte de 
um  único  elementos  básico,  o  ​objeto​.  Cada  objeto  tem  uma  cópia  dos dados definidos na 
classe  e  encapsula  estado e comportamento. Cada um dos objetos é uma instância de uma 
classe  e  todas  as  classes  formam  uma  hierarquia  de  classes  unidas  via  relacionamento de 
herança.  Para  melhor  compreender  o  que  significa  esse  paradigma,  além  de  objeto,  é 
necessário o entendimento de alguns conceitos apresentados a seguir. 
 O  conceito  de  ​classe  é  essencial  para  o  entendimento  da  programação  OO, 
podendo  ser  definido  por  um  conjunto  estático de atributos (ou dados salvos do objeto) e 
métodos  ​(ou  funções  membro)  que  representam  operações  que  podem  ser  realizadas 
sobre  os  dados.  De  uma  classe  genérica  (classe  pai  ou  classe-base),  podem  ser  definidas 
novas  classes  (subclasse,  classe  filha  ou  classe  derivada),  através  do  relacionamento  de 
herança​.  Com  o  mecanismo  de  herança,  cria-se  uma  hierarquia  de  especialização,  onde 
uma  classe  mais  especializada  herda  as  propriedades  da(s)  classe(s)  mais  genérica(s)  que 
está  acima  dela  na  hierarquia.  A  herança  permite  a reusabilidade via o compartilhamento, 
extensão e restrição de características herdadas da classe pai. 

Além  da  herança,  o  paradigma  da  orientação  a  objetos  possui  mais  três  conceitos 
fundamentais:  abstração,  encapsulamento  e  polimorfismo.  Sendo  a  ​abstração​,  a 
capacidade  de  focar  nos  pontos  mais  importantes  do  domínio  de  aplicação  do  sistema  e 
abstrair  os  detalhes  menos  relevantes.  Uma  classe  tende  a  ser  a  abstração  de  entidades 
existentes  no  mundo  real,  por  exemplo,  Aluno,  Professor,  Trabalho.  Nessa  representação 
de  um objeto real, três quesitos devem ser considerados: a identidade que será criada para 
o objeto, as propriedades (características) do objeto e, os métodos. 

O  ​encapsulamento​,  uma  técnica  empregada  para  garantir  a  ocultação  de 

informações.  Segundo  Binder  (1999),  a  herança  enfraquece  o  encapsulamento,  isto  é, 
enfraquece  o  mecanismo  de  controle  de  acesso  que  determina  a  visibilidades  de  dados 
(atributos)  e  métodos  dentro  de  uma  classe.  Sendo  assim  é  fundamental  compreender  os 
detalhes  de  implementação  da  hierarquização  das  classes.  Com  isso,  é  possível 
implementar  métodos  específicos  para  cada  classe  ou  implementar  mudanças  de  um 
método  sem  afetar  outras classes. Outro conceito essencial é o ​polimorfismo que permite 
objetos  semelhantes  sejam  tratados  de  maneira  uniforme  de  forma  que  uma  mesma 
mensagem  pode  ser  enviada  a  todo  o conjunto de objetos, sendo possível que cada objeto 
responda  de  maneira  diferente  em  função  da  mensagem  recebida.  É  possível  também 
acrescentar  novos  métodos  à  classes  já  criadas  sem  a  necessidade  de  recompilar  a 
aplicação. 

2.1.1 PROGRAMAÇÃO ORIENTADA A OBJETOS  

Uma  linguagem  de  programação  é  um  método  padronizado  para  comunicar 

instruções  para  um  computador,  onde  um  conjunto  das  regras  sintáticas  e  semânticas 
constituem  um  código  (código-fonte)  que  define  o  software  (DERSHEM;  JIPPING,  1995; 
FISCHER;  GRODZINSKY,  1993).  Atualmente  existem  diversos  tipos  de  linguagens  de 
programação  que  seguem  diferentes  paradigmas. A Orientação a Objetos é atualmente é o 
paradigma  mais difundido entre todos por se tratar de um padrão que tem evoluído muito, 
principalmente  em  questões  relacionadas  à  segurança  e  da  reutilização  de  código, 
importantes  no  desenvolvimento de qualquer aplicação na atualidade. Além da capacidade 
de representação do sistema muito mais perto do que veríamos no mundo real. 

Uma  linguagem  de  programação  OO  contempla  em  si,  conforme  o nome indica, os 
quatro  pilares  da  OO  anteriormente  descritos:  abstração,  encapsulamento,  herança  e 
polimorfismo  (GASPAROTTO,  2014).  Atualmente  há  uma  grande  quantidade  de  linguagens 
de  programação  orientada  a  objetos  no  mercado,  como  Java,  C#  e  C++.  Cada  uma  delas 
possui  uma  abordagem  diferente  do  problema  que  as  torna  muito  boas  para  alguns  tipos 
de aplicações e não tão boas para outros. 

O  projeto  apresentado  no  presente  artigo  será  desenvolvido  em  ​Object  ​Pascal, 
também  conhecida  como  ​Delphi​,  devido  ao  nome  de  seu  ambiente  integrado  de 
desenvolvimento  (IDE, do inglês ​Integrated Development Environment​) que contém em si a 
linguagem  e  o  compilador. A linguagem Delphi é tida como uma linguagem acadêmica, por 
ser  mais  acessível  ao  aprendizado  (ANDRADE;  TEIXEIRA,  2018).  A  escolha  é  baseada  no 
conhecimento  básico  da  linguagem  pelos  integrantes  da  equipe  de  desenvolvimento  do 
projeto  na  linguagem,  adquirido  durante  a  disciplina  no  próprio  Programa  de 
Pós-Graduação  onde  ocorre  o  desenvolvimento  do  projeto  o  PGDesign  da  Universidade 
Federal do Rio Grande do Sul - UFRGS. 

2.2 Banco de Dados Relacional 

Um  banco  de  dados  relacional  (BDR)  é  um  mecanismo  de  persistência,  ou  seja, 
permite  a  armazenagem  de  dados  -  e  opcionalmente,  implementa  funcionalidades  - 
requeridas  por  aplicações  construídas  usando  tecnologias  procedurais  ou,  conforme  este 
projeto,  Orientadas  a  Objeto(OO).  O  software  que  controla  o  armazenamento, 
recuperação,  exclusão,  segurança  e  a  integridade  dos  dados  existe  no  banco  de  dados  é 
denominado  Sistema  Gerenciados  de  Banco  de  Dados  Relacional  (SGBDR).  Os  dados  são 
armazenados  tabelas,  organizadas  em  colunas  ou  instâncias.  Cada  coluna  armazena  um 
tipo  de  dados  com  diferentes  tipos  (caracteres,  números,  datas,  etc).  Os  dados  de  cada 
instância  de  uma  tabela  são  armazenados  como  uma linha, as entidades (​SILBERSCHATZ; 
KORTH;  SUDARSHAN,  1999)​.  Como  exemplo,  uma  tabela  nomeada  "Alunos"  pode  ter 
como  colunas  ID,  Nome,  Sobrenome,  e  uma  linha  na tabela conteria os dados, como "123, 
"Ana", "Dias".  

As funcionalidades que podem ser implementadas no SGBDRs são do tipo CRUD (do 
inglês  ​Create,  Read,  Update  e  Delete  –  que  significa  as  operações  de  Inserção,  Leitura, 
Atualização  e  Exclusão  de  dados),  para  isso seria necessário submeter declarações escritas 
na  linguagem  de  programação  SQL  ou  possuir  uma  IGA,  que  permitirá  que  qualquer  tipo 
de usuário acesse essas informações. 

As  tabelas  criadas  possuem  relacionamentos  que  permitem  acesso  às  informações 
sem  que  estas  fiquem  agrupadas  e  armazenadas  em  um  único  registro.  Isso  quer  que  o 
que  o  torna  relacional  é  a  maneira  como  os  dados  são  armazenados  e  organizados  no 
banco de dados. 

2.2.1 DESENVOLVIMENTO DE BD E A MODELAGEM DE DADOS 

Quando  inicia-se  um  projeto  de  banco  de  dados,  inicialmente  há um ​levantamento 
dos  requisitos  necessários  para  a  construção  do  produto  final,  identificando  as  principais 
partes,  objetos  envolvidos,  suas  possíveis  ações  e  responsabilidades, suas características e 
como  elas  interagem.  A  partir  das  informações  obtidas,  desenvolve-se  a  modelagem  dos 
dados  que  serão  utilizados  para  orientar o desenvolvimento efetivo do banco de dados em 
uma  linguagem.  Sendo  assim,  a  modelagem  de  dados  consiste  no  processo  anterior  à 
efetiva  construção  do  banco  de  dados  no  software  onde  são  determinadas  a  lógica  e 
estrutura  do  banco  a  ser  posteriormente  implementado.  Este  processo  é  divido  em  três 
etapas  de  modelagem:  conceitual,  lógica  e  física.  Na  modelagem  conceitual  ​é 
determinado  a  forma  (conceitual)  como  os dados estarão dispostos no banco de dados, na 
lógica de organização e a estrutura física dos dados são modelados na etapa seguinte. 

Um  projeto  de  desenvolvimento  de  banco  de  dados  consiste  basicamente  em  três 
etapas: Levantamento dos Requisitos do sistema; Modelagem de Dados e a Implementação 
do sistema em uma linguagem. 

Para  determinar  as  entidades  (dados)  existentes  no  BD,  seus  relacionamento  e 
atributos  é  possível  utilizar  a  abordagem  ER  (Entidade-Relacional)  ou  MER  (Modelo  de 
Entidade-Relacional)  (DATE,  2004).  Para  representar  essas  informações,  usa-se  o Diagrama 
Entidade  Relacionamento  (Diagrama  ER  ou  ainda  DER)  como  principal  ferramenta  de 
visualização  que  descrever  os  objetos  (entidades)  envolvidos  em  um  domínio de negócios, 
com  suas  características  (atributos)  e  como  se  relacionam  (relacionamentos).  O  diagrama 
ainda  facilita  a  comunicação  entre  os  integrantes  da  equipe,  fornecendo  uma  linguagem 
comum.  A  correta  modelagem,  e  principalmente  o  uso  do  diagrama,  permite  registrar  e 
comunicar  os  principais  aspectos  do  projeto  do  banco  de  dados  (DATE,  2004)  evitando 
desde falhas e erros de concepção e análise, à problemas de comunicação entre a equipe. 

A  Linguagem  de  Modelagem  Unificada  (UML  -  ​Unified  Modeling  Language​),  é  uma 

linguagem  de  boa  aceitação  no  mercado  e  com  integração  com  conceitos  da  Orientação a 
Objetos  (OO).  Os  sistemas  concebidos  a  partir  da  aplicação de práticas e técnicas de OO, a 
elaboração  de  documentos  modelando  os  componentes  esperados  é  feita  atualmente  a 
partir de diagramas UML.   

2.3 METODOLOGIA DE DESENVOLVIMENTO DE PRODUTOS DÍGITO-VIRTUAIS 

O  “Projeto  E”  (MEURER,  2014;  MEURER;  SZABLUK,  2009)  é  uma  metodologia 

projetual  com  aplicação  prática  em  projetos  profissionais  e  acadêmicos  de  design  de 
interação,  constituída  de  conceitos,  definições,  métodos  e  processos  de  autores 
consagrados  em  design  de  interação  e  arquitetura  da  informação,  assim  como  de  áreas 
adjacentes  como  design  editorial  e  de  idenidade  gráfico-visual.  As  etapas  estruturados  de 
acordo  com  as  etapas  sugeridas  por  Garrett  (2003):  E
​ stratégia,  Escopo​,  Estrutura​, 
Esqueleto​,  Estética  ​e  Execução; não sendo necessariamente sequenciais (MEURER, 2014). 
Devido  às  suas  características  é  possível  retornar  e  alterar  uma  ou  mais etapas para gerar 
novas alternativas em benefício do resultado final. 

Figura 2 - Projeto E para design de interfaces 

 
Elaborado pelos autores adaptado em Meurer (2014) 

A  primeira  fase,  a  E
​ stratégia,  caracteriza-se  por  seus  processos  de  identificação  e 
análise.  Inicia  sempre  com  a  contextualização  do  projeto,  transcorrem  as  análises, 
resultando em uma lista de verificação constituída de restrições, requisitos e possibilidades 
projetuais.  Sendo  assim,  etapa  fundamental  para  orientar  o  desenvolvimento  do  produto 
nas etapas seguintes. 

A  projetação  do  produto  propriamente  dito,  inicia-se  na  etapa  de  ​Escopo  ​com  o 
começo  da  geração  de  alternativas  e  estas,  neste  momento,  são  de  caráter  linguístico.  É 
necessário  organizar  e  classificar  o  produto  e  definir  a  hierarquia  da  informação, 
ferramentas  e  transações.  Na  ​Estrutura  começa  a  geração de alternativas desenhísticas já 
estabelecendo  todas  as  inter-relações,  permissões  e  regras  de interação. Na terceira etapa 
que  são  geradas  alternativas  estruturais  e  arquiteturais  para  definir  densidade  e 
organização  da  informação  nas  telas  e  da  lógica-informacional  inter-telas  da  IGA  do 
produto.  No  ​Esqueleto  que  se  desenha  as  interação do usuário com o produto e para isso 
leva-se  consideração,  diretrizes  para  usabilidade  e  acessibilidade.  A  E
​ stética  é  definida 
pelo  uso  malhas  (​grids​)  para  a  diagramação  e  composição  e  uso  dos  elementos  da 
identidade  gráfico-visual  para  definir  o  posicionamento  da  linguagem  gráfico-visual  e 
layouts  do  produto.  A  identidade  gráfico-visual  do  produto  é  então  definida  através  das 
escolhas de logografia, cronografia, tipografia, pictografia e iconografia. 

Por  fim,  há  o  primeiro  passo  no  desenvolvimento  do  modelo  funcional  navegável 
para  simular  o  funcionamento  do  produto,  realizar  testes  de  interação  e  análises 
heurísticas  seguido  pela  posterior  implantação  e  /ou  produção  do  produto  final  na  etapa 
final  de  ​Execução​.  Segundo  Meurer  (2014),  na  etapa  final  é  executada  a  programação 
visual de um modelo funcional navegável (MFN) que, conforme ressalta, não se trata de um 
de  um  protótipo.  Sendo  um  modelo  dinâmico  que  apenas  exemplifica  as  principais 
funcionalidades  do  produto  servindo  para  o  cliente  e  usuário  tenham  uma  visão  geral  de 
como  será  o  produto  final.  Após  isso,  começasse  a  programação  computacional  que 
integra a superfície com o banco de dados através das regras de negócio (MEURER, 2014). 

É  importante  ressaltar  a  importância  da  ​Definição  dos  papéis  dentro  do  processo 
de  desenvolvimento  deste  tipo  de  produto.  Considerando  que  projetos  de  média  a  alta 
complexidade,  é  necessária  a  atuação  de  uma  equipe  interdisciplinar  com  a  participação 
de  profissionais  com  diferentes  formações  responsáveis  pelas  diferentes  camadas  do 
projeto.  A  primeira  camada,  a  interface  gráfica  amigável  (IGA)  é  a  superfície  do  projeto de 
responsabilidade  do  designer  gráfico  e  do  arquiteto  da  informação. A segunda camada (as 
regras  de  negócios)  define  como  o  usuário  irá  interagir  com  o  banco  de  dado,  que  é  a 
terceira  camada  do  sistema  a  ser  desenvolvido.  A  2a  e  a  3a  camada  são  planejadas  pelo 
analista de sistemas e projetadas pelo desenvolvedor. 
  
Figura 3 - Camadas do projeto de produtos dígito-virtuais 

 
Fonte: Elaborado pelos autores 

 
A  metodologia  Projeto  E  (Meurer,  2014)  ocupa-se  com  a  terceira  camada,  a 
superfície  das  interfaces  gráficas,  considerando  os outros atores além do designer, como o 
desenvolvedor  e  o  arquiteto  da  informação  em  seu  relacionamento  de  desenvolvimento 
dessa  camada.  Ao  final  da  última  etapa  executa-se  um  modelo  funcional navegável (MFN), 
que  difere-se  de  um  protótipo  onde  já  existe  programação  computacional  e  em  alguns 
casos, um sistema de persistência, como um banco de dados. Sendo assim, um protótipo já 
integra  em  seu  desenvolvimento  as  camadas  inferiores  do  produto  que  usualmente  são 
projetadas  pelos  outros  atores  em  outro  processo  projetual  independente  do 
desenvolvimento das interfaces gráficas. 

3. PROCEDIMENTOS METODOLÓGICOS 

Para  o  desenvolvimento  do  sistema  partiu-se  do  “Projeto  E”  como  macroestrutura 
projetual,  integrando  atividades  de  modelagem  de  dados  e  desenhos  do  diagrama  de 
classes,  juntamente  com  programação  computacional  das  principais  funções da aplicação. 
Com  isso,  as  três  camadas  do  projeto  (interface,  regras  de  negócio  e  banco  de  dados)  são 
desenvolvidas  orientadas  pelo  processo  de  design.  A  figura  a  seguir  ilustra  os 
procedimentos  realizados  durante  cada  etapa  assim  como  a  integração  do  processo  de 
desenvolvimento das três camadas.  
Conforme  representado  na  figura,  durante  o  Escopo,  durante  a  estruturação  e 
definições  estratégicas  do  projeto  houve  o desenvolvimento integrado das três camadas. A 
modelagem  dos  dados  executadas  em  suas  três  etapas (conceitual, lógica e estrutural) são 
executadas  na  fase  de  Escopo  e  Estrutura  juntamente  com  os  wireframes  e  estrutura  das 
telas  da  interface.  A  programação  das  regras  de  negócio  foram  implementadas  e  testadas 
durante  o  desenvolvimento  do  banco  de  dados  e  da  interface  o  que  permitiu importantes 
trocas  entre  os  membros  da  equipe  e  permitiu que decisões de projeto definidas, testadas 
e validadas mais rapidamente. 

Durante  as  cinco  etapas  propostas  (Estratégia,  Escopo,  Estrutura,  Esqueleto  e 

Estética)  o  protótipo  funcional  é  desenvolvido  e  importantes  definições  sobre  a  aplicação 
final  são  definidas.  A  partir  do  uso do protótipo importantes percepções sobre os usuários 
podem ser captadas e utilizadas para o término do desenvolvimento da aplicação final. 

 
​Figura 4 - Projeto integrado para produtos dígito-virtuais 

 
Fonte: Elaborado pelos autores 
 

 
4. DESENVOLVIMENTO PROJETUAL 

Detalhes  das  etapas  de  desenvolvimento  são  apresentados  a  seguir  conforme  os 
procedimentos e métodos anteriormente apresentados. 
 

4.1 ESTRATÉGIA 

Composta  por  etapas  de  contextualização,  análise,  verificação  com  listagem  de 
restrições,  requisitos  e  possibilidades  projetuais  do  sistema.  Na  contextualização,  foi 
realizada  a  descrição  do  produto  a  ser  desenvolvido,  ​identificação  do  público-alvo  e 
utilizadores  do  sistema​,  descrição  da  ​situação  inicial  e  final  ​esperada  para  o  projeto 
(MEURER, 2014; MEURER; SZABLUK, 2009), seguida da análise das informações levantadas. 

A  partir  disso,  definiu-se  como  requisitos  básicos  a  compatibilidade  da  aplicação 

com  a  plataforma  Microsoft®  Windows  (32bits)  e  conectividade  com  o  Banco  de  Dados 
Relacional  (a  ser  desenvolvido  em  MySQL™).  As  interfaces  gráficas  amigáveis  (IGAs)  do 
sistema  deveriam  permitir  ao  usuário  interagir  com  o  banco,  cadastrando  e  buscando 
informações.  As  interfaces  seriam  implementadas  e  programadas  no  ambiente  de 
desenvolvimento Delphi™ 10.3 Rio.  

4.2 ESCOPO 

No  ​Escopo  ​iniciou-se  a  Arquitetura  da  Informação  do  projeto  (MEURER,  2014; 
MEURER;  SZABLUK,  2009)  e  dos  dados  que  seriam  cadastradas  e  manipuladas  no  sistema 
de  gerenciamento. Esses dados foram categorizados em ​instâncias​, agrupados em ​classes 
e  representados  por  meio  de  um  Diagrama  ER,  utilizando  a  linguagem  UML.  As  classes, 
enfim,  deram  origem  à  tabelas(​tables​),  ​posteriormente  implementadas no banco de dados 
relacional e correspondendo às etapas conceitual e lógica da modelagem de dados. 

 
 fig. 5 - Representação gráfica da modelagem lógica dos dados

 
Fonte: Autores 

Por fim, foi realizado um organograma de tarefas a fim de definir o escopo das telas 
necessárias  para  a  implementação  do  sistema,  e,  definiu-se  a  linguagem  gráfico-visual 
conforme  diretrizes  existentes  no  manual  de  identidade  visual  de  marca,  pertencente  ao 
Programa de Pós-Graduação em Design da UFRGS. 

 
fig. 6 - Representação gráfica das atividades realizadas na etapa Escopo

 
Fonte: Autores 

 
 

 
  

4.3 ESTRUTURA E ESQUELETO 

A  etapa  da  ​estruturação  parte  da  conversão  das  telas  definidas  durante  a  fase  do 
escopo  em  formulários  do  ambiente  Delphi.  Os  formulários  são  uma  interface  entre 
usuário  e  programa  que  utiliza  de  objetos  gráficos  para  compor  a  aparência  de  uma 
aplicação, quando é executada.  

 
fig. 7 - Representação gráfica das atividades realizadas nas etapas Estrutura e Esqueleto 

Fonte: os autores 
 

No  Delphi,  foi  estabelecido  que  cada  formulário,  correspondente  às  classes  do 
banco  de  dados,  também  fosse  uma  classe  de  objetos  do Delphi, segundo o paradigma da 
OO.  Assim,  ficou  definida  a  criação  de  formulários  “mães”  para  as  telas  de  cadastro  e  de 
consulta  de  cada  uma  dessas classes, sendo possível valer-se das relações de herança para 
padronizar esses formulários, o que agilizou o processo de criação dos mesmos. Da mesma 
forma,  os  procedimentos  previstos  para  os  componentes  desses  formulários,  a  exemplo 
dos botões, também foram transmitidos por herança, caracterizando o polimorfismo.  

   
  
fig. 8 - Representação gráfica da modelagem lógica dos dados 

 
Fonte: os autores 

A  partir  disso,  iniciou-se  a  etapa  do  ​esqueleto  com  a  formulação  do  w

​ ireframe 
(MEURER,  2014),  a  partir  da  formatação  dos  formulários  e  diagramação  do  seu  conteúdo. 
Assim  foram  definidos  os  dimensionamentos  e  espaçamentos  básicos  para  os 
componentes  (botões,  caixas  de  texto  e  afins),  bem  como  as  configurações  das  caixas  de 
textos (fontes, estilos, cores e tamanhos).  

Além  do  processo  de  formatação,  foi  necessário  construir  a  conexão  com  o  BDR, 
com  o  uso  de  um  Sistema  de  Gestão  de  Base  de  Dados  (SGBD).  No  caso  da  aplicação,  foi 
utilizado  o  SGBD  “mySQL”,  e  a  sua  conexão  com  o  ambiente  Delphi  foi  feita  através  de 
driver  nativo,  o  ​“FireDAC​”,  mais  especificamente  pelo  componente  “​TADConnection”, 
contido  em  sua  biblioteca​.  P
​ ara  essa  operação  foi  reservado  um  formulário  específico  na 
aplicação a fim de tratar especificamente das configurações da conexão.  

De  forma  complementar,  os  componentes  “​TADQuery”  e  ​“TDataSource”  ​foram 

utilizados  para  ler  e  gravar  os  dados  contidos  nas  tabelas  do  banco  de  dados, 
respectivamente.  Para  garantir  consistência  aos  dados  nesse  processo,  foi  utilizado  o 
componente  “​ TFDTransaction”,  ​responsável  pelas  transações  de  dados​.  ​Essa  medida 
corresponde  a  um  método  de  controle  de  concorrência  Multiversão  (MCC  ou  MVCC), 
garantindo consistência aos dados durantes as operações​ (BERNSTEIN; GOODMAN, 1983)​.  

 
 ​Fig. 9 - Representação gráfica do wireframe e tela criada para a função Compor Banca 

​Fonte: Elaborado pelos autores 

Por  fim,  a  geração  de  documentos  precisou  da  biblioteca  de  ferramentas  do 
“FastReport”,  gerador  de  relatórios  para  o  ambiente  Delphi,  com  dois  componentes.  O 
primeiro,  ​“TfrxDBDataSet”​,  utilizado  para  conectar  o  FastReport  às  tabelas  do  banco  de 
dados  a  fim  de  incluir  os  atributos  contidos  nas  mesmas  no  relatório  a  ser  gerado.  O 
segundo, ​“TfrxReport”​, é o componente que estrutura propriamente o relatório, permitindo 
formatar  o  documento.  Dessa  forma  foi  possível  criar  o  modelo  de  pôster  e  ata  para  as 
bancas  do  PGDesign,  com  as  informações  atualizadas  diretamente  do  BDR,  permitindo  a 
automação da criação desses documentos pela aplicação. 

4.5 PROTÓTIPO FUNCIONAL E APLICAÇÃO FINAL 

O  protótipo  funcional  cumpre  os  requisitos  esperados  para  o  mesmo,  sendo  essas 
conectar-se  ao  banco  de  dados;  gravar,  editar  e  excluir  dados  nos  formulários  e  no  BDR; 
buscar  por  professores,  trabalhos  e bancas de pós-graduação e, por fim,  reunir e imprimir 
informações  em  documentos  necessários  à  execução  da  banca  (posters  e  atas,  conforme 
apresentado  na  figura  a  seguir).  Sendo  assim,  o  propósito  do  protótipo  foi  alcançado: 
certificar-se  que  as  funcionalidades  básicas  da  aplicação  são  funcionais  e  adequadas  às 
necessidades  dos  usuários,  de  forma  que  convém  que  a  referida  fase  seja  executada 
apenas  para  a  aplicação  final.  A  próxima  etapa  a  cumprir,  seguindo  a  estrutura 
metodológica  definida  será  a  Estética,  na  qual  pretende-se  implementar  os  elementos  da 
identidade  gráfico-visual  do  PGDesign/UFRGS,  bem  como,  ajustes  percebidos  após 
execução do protótipo.  
 Fig. 10 - Documentos de banca de pós-graduação gerados pelo o protótipo funcional 

​Fonte: Elaborado pelos autores 

5. CONSIDERAÇÕES FINAIS 

Este  trabalho  teve  por  fim  o  projeto  de  um  sistema  para  gerenciamento  de 
informações  e  geração  de  documentos  acadêmicos  e  o  desenvolvimento  do  protótipo 
funcional  desta.  O  desenvolvimento  do  projeto  envolveu  uma  pesquisa  teórica  em  artigos 
científicos  e  técnicos  que  discorrem  a  respeito  de  Orientação  a  Objetos  (OO), 
desenvolvimento  de  banco  de  dados  e  processos  metodológicos  de  desenvolvimento  de 
projeto digitais. Pensando-se no desenvolvimento ágil deste tipo de projeto foi considerado 
unificar  o  desenvolvimento do projeto das três camadas do desenvolvimento de software e 
um  único  processo  metodológico.  Para isso, utilizou-se como base a metodologia projetual 
o  Projeto  proposto  por  Meurer  &  Szabluk  (2009)  e  revista  por  Meurer  (2014), e o processo 
de  desenvolvimento  de  banco  de  banco,  proposto  por  três  etapas  sendo  a  principal,  a 
modelagem  de  dados.  É  relevante  ressaltar  que  a  modelagem  de  dados  integrada  ao 
desenvolvimento  das  interfaces  gráficas  por  meio  de  uma  metodologia  de  design  pode 
melhorar a elaboração de interfaces de sistemas de manipulação de informações  

Devido  ao  cumprimento  dos  objetivos  almejados  e  a  aplicação  já  completar  sua 
principal  da aplicação, o presente projeto atendeu de forma objetiva e clara suas propostas 
iniciais,  indo  além  e  apresentando  uma  arquitetura  de  métodos  e  procedimentos  que  de 
forma  experimental  integrou  o  desenvolvimento  das  três  camadas  da  aplicação.  Sendo 
assim,  apresenta-se  uma  composição  de  um  processo  metodológico  de  adaptação  de 
procedimentos e métodos específicos que poderá servir de estudo a possíveis trabalhos. 

REFERÊNCIAS 

ANDRADE,  R.  M.​;  TEIXEIRA,  F.  G.  A  Programação  como  elemento  potencializador  do 
processo de Design de Interface. ​Revista Brasileira de Expressão Gráfica​, v. 6, n.2, 2018. 

BERNSTEIN,  P.  A.;  Goodman,  N. Multiversion Concurrency Control - Theory and Algorithms. 

ACM Transactions on Database Systems (TODS)​. v. 8, n.4, 1983.  

BINDER,  R.  V.  ​Testing  object-oriented  systems:  Models,  patterns,  and  tools​,  v.  1. 
Addison Wesley Longman, Inc., 1999. 

DATE,  C.  J..  ​Introdução  A  Sistemas  De  Bancos  De  Dados​.  8.  ed.  Rio  de  Janeiro:  Elsevier, 
2003 

DERSHEM,  H.  L.;  JIPPING,  M.  J.  Programming  Languages,  Structures  and  Models.  ​2ª  ed. 
Boston: PWS Publishing Company, 1999.  

FISCHER,  A.  E.;  GRODZINSKY,  F.  ​The  Anatomy  of  Programming  Languages.  Englewood 
Cliffs, New Jersey: Prentice Hall, 1993.  

MEURER,  H.  ​Ferramenta  de  gerenciamento  e  recomendação  como  recurso  na 

aprendizagem  baseada  em  projeto  de  design.  Tese  de  Doutorado  do  Programa  de 
Pós-Graduação  em  Informática  na  Educação da Universidade Federal do Rio Grande do Sul 
(UFRGS). 2014. 

SILBERSCHATZ,  A.;  KORTH,  H.  F.;  SUDARSHAN,  S.  ​Sistema  de  Banco  de  Dados​.  3. 
ed. São Paulo: Makron Books, 1999