Curso de Engenharia de Computação FERRAMENTAS CASE...
31
Curso de Engenharia de Computação FERRAMENTAS CASE: IMPLEMENTAÇÃO DE UM PROTÓTIPO PARA MANUTENÇÃO DE BANCO DE DADOS Viviane Peloso Itatiba – São Paulo – Brasil Novembro de 2004
Transcript of Curso de Engenharia de Computação FERRAMENTAS CASE...
Curso de Engenharia de Computação
FERRAMENTAS CASE: IMPLEMENTAÇÃO DE UM
PROTÓTIPO PARA MANUTENÇÃO DE BANCO DE DADOS
Viviane Peloso
Itatiba – São Paulo – Brasil
Novembro de 2004
ii
O presente exemplar da monografia FERRAMENTAS CASE:
IMPLEMENTAÇÃO DE UM PROTÓTIPO PARA MANUTENÇÃO DE
BANCO DE DADOS contempla as correções sugeridas pela banca
examinadora durante a apresentação do Trabalho de Conclusão de Curso.
Itatiba/SP, 08 de Dezembro de 2004.
Prof Ms. José Aparecido Carrilho
USF – Universidade São Francisco – Itatiba – SP.
iii
Curso de Engenharia de Computação
FERRAMENTAS CASE: IMPLEMENTAÇÃO DE UM
PROTÓTIPO PARA MANUTENÇÃO DE BANCO DE DADOS
Viviane Peloso
Monografia apresentada à disciplina Trabalho de Conclusão de Curso, do Curso de Engenharia de Computação da Universidade São Francisco, sob a orientação do Prof. Ms. José Aparecido Carrilho, como exigência parcial para conclusão do curso de graduação. Orientador: Prof. Ms. José Aparecido Carrilho
Itatiba – São Paulo – Brasil
Novembro de 2004
iv
FERRAMENTAS CASE: IMPLEMENTAÇÃO DE UM PROTÓTIPO
PARA MANUTENÇÃO DE BANCO DE DADOS
Viviane Peloso
Monografia defendida e aprovada em 27 de novembro de 2004 pela Banca
Examinadora assim constituída:
Prof Ms. José Aparecido Carrilho
USF – Universidade São Francisco – Itatiba – SP.
Prof Ms. Alencar de Melo Junior
USF – Universidade São Francisco – Itatiba – SP.
Prof Ms. Thales Coelho Borges Lima
USF – Universidade São Francisco – Itatiba – SP.
v
.Agradecimentos
Agradeço primeiramente ao Professor José Aparecido Carrilho, meu orientador, que acreditou
em mim e incentivou-me para a conclusão deste trabalho, face aos inúmeros percalços do
trajeto.
Agradeço também ao Professor Alencar de Melo Júnior, um companheiro de percurso e de
discussões profícuas, dentro e fora do contexto deste trabalho, agraciando-me incontáveis
vezes com sua paciência, conhecimento e amizade.
Alguns experimentos e vários “entendimentos” não teriam sido possíveis sem a colaboração
de Fernando Davanço, Fábio Nascimbeni Lopes e Gladston José de Oliveira.
Eu agradeço fraternalmente a todos.
vi
Sumário
Lista de Siglas..........................................................................................................................vii
Lista de Figuras..................................................................................................................... viii
Lista de Tabelas .......................................................................................................................ix
Resumo.......................................................................................................................................x
Abstract......................................................................................................................................x
1 INTRODUÇÃO..................................................................................................................1
2 FERRAMENTAS CASE ...................................................................................................3 2.1 Ambientes CASE...........................................................................................................3 2.2 Vantagens e Desvantagens ............................................................................................4 2.3 Taxonomia.....................................................................................................................5 2.4 Arquitetura...................................................................................................................10
3 IMPLEMENTAÇÃO DO PROTÓTIPO.......................................................................11 3.1 Arquitetura do Banco de Dados Oracle.......................................................................11 3.2 Obtenção da Estrutura da Base de Dados....................................................................11 3.3 Verificação da Estrutura de Base de Dados.................................................................12
3.3.1 Gerador de Arquivo Binário .................................................................................12 3.3.2 Protótipo “DBComparer” .....................................................................................13
4 CONCLUSÃO ..................................................................................................................16 4.1 Contribuições...............................................................................................................16 4.2 Extensões .....................................................................................................................17
Apêndice 1 – Exemplos de comandos selects utilizados na implementação do protótipo 18
Referências Bibliográficas......................................................................................................20
Bibliografia Consultada .........................................................................................................21
vii
Lista de Siglas
CASE Computer Aided Software Engineering
ADS Ambiente de Desenvolvimento de Software
DFD Diagrama de Fluxo de Dados
E-R Entidade – Relacionamento
I-CASE Integrated Computer Aided Software Engineering
SCM Software Configuration Management
PRO Prototipação
SIM Simulação
viii
Lista de Figuras
Figura 2-1 – Blocos Construtivos de CASE............................................................................4
Figura 2-2 – Classificação de Ferramentas CASE.................................................................6
Figura 2-3 – Exemplos de Arquitetura de Ferramentas CASE..........................................10
Figura 3-1 – Telas dos aplicativos SQL Explorer e SQL Monitor atuando concorrentemente....................................................................................................................12
Figura 3-2 – Tela do Gerador de arquivos binários ............................................................13
Figura 3-3 – Tela principal do “DBComparer” ...................................................................14
Figura 3-4 – Mensagem exibida após o término da verificação .........................................14
Figura 3-5 – Tela principal do “DBComparer” com o Log de resultado ..........................15
ix
Lista de Tabelas
Tabela 2-1 – Classificação de Ferramentas CASE.................................................................6
x
Resumo
O objetivo deste trabalho é a implementação de um protótipo de Ferramenta CASE (Computer
Aided Software Engineering) direcionada a utilização de usuários finais, para a realização da árdua
tarefa de verificar a consistência da estrutura de base de dados Oracle, aproveitando para embasar a
realização de um estudo sobre os diversos tipos de Ferramentas CASE existentes atualmente no
mercado. Para isto a mesma foi dividida em duas partes. A primeira parte constitui um estudo sobre
Ferramentas CASE, na qual estão descritos não apenas os diversos tipos de Ferramentas existentes,
mas inclusive fatores como: definição, ambientes CASE, vantagens e desvantagens em sua utilização e
arquitetura. Esta parte terá a função de demonstrar a deficiência de Ferramentas CASE para usuários
finais existente no mercado atual. A segunda parte envolve a familiarização com a linguagem de
programação escolhida (Delphi 5) e com os aplicativos SQL Explorer e SQL Monitor, além da
realização de um estudo na arquitetura no banco de dados Oracle para a definição de uma forma de se
obter os dados referentes às estruturas das base de dados Oracle.
PALAVRAS-CHAVE: CASE, FERRAMENTA, BASE DE DADOS
Abstract
The objective of this work is the implementation an archetype of CASE Toll (Computer Aided
Software Engineering) directed the use final users, for the accomplishment of the arduous task to
verify the consistency the structure database Oracle, using to advantage to base the accomplishment of
a study on the diverse types of CASE Tools currently existing in the market. For this the same one was
divided in two parts. The first part constitutes a study on CASE Tools, in which is described not only
the diverse types of existing Tools, but also factors as: definition, CASE environments, advantages
and disadvantages in its use and architecture. This part will have the function to demonstrate the
deficiency of CASE Tools for final users existing in the current market. The second part involves the
familiarization with the chosen programming language (Delphi 5) and with applicatory SQL Explorer
and SQL Monitor, beyond the accomplishment of a study in the architecture in the database Oracle for
the definition a form if getting the referring data to the structures the database Oracle.
KEY WORDS: CASE, TOOL, DATABASE
1
1 INTRODUÇÃO
Desde 1955, engenheiros mecânicos e elétricos trabalhavam com ferramentas manuais
rudimentares como: livros, tabelas, réguas de cálculos, calculadoras mecânicas, lápis,
pranchetas e outros objetos que possibilitavam que um engenheiro criasse modelos do produto
a ser projetado.
Uma década se passou e este mesmo grupo de engenheiros começou a experimentar a
engenharia baseada em computador, surgiam os montadores e compiladores. A partir daí, a
primeira geração de Engenharia de Software Auxiliada por Computador, ou seja, de
ferramentas conhecidas atualmente como Ferramentas CASE foi sendo desenvolvida,
surgiram os dicionários de dados (1960), os editores textuais (1970) e os editores gráficos
(1980).
A segunda geração iniciou-se a partir de 1980, através de ferramentas para
documentação e diagramação, sendo seguida pelo surgimento de ferramentas de verificação
de análise e projeto, ferramentas de geração automática de código a partir do projeto e
ferramentas de automação do projeto. Apenas nos anos 90, com a terceira geração de
Ferramentas CASE, desenvolveram-se ferramentas com assistência inteligente, recurso para
reutilização e engenharia reversa.
Atualmente, os engenheiros de software dispõem de um número maior e mais variado
de ferramentas no mercado, que trazem benefícios ao processo de desenvolvimento de
produtos de software, a saber: encoraja um ambiente interativo, reduz custos de manutenção,
melhora a qualidade do produto de software, agiliza o processo de desenvolvimento, aumenta
a produtividade.
Toda ferramenta ou método que auxilie num processo de construção lógica ou física,
documentação ou teste pode ser considerada uma Ferramenta CASE.
A dissertação presente tem como foco o desenvolvimento de um protótipo de
Ferramenta CASE voltada a utilização de usuários finais, apresentado na seção sete, para a
verificação de estruturas de base de dados e a partir desta verificação detectar erros com maior
eficácia e eficiência. Aproveita-se também para realizar um estudo sobre os diversos tipos de
Ferramentas CASE encontradas atualmente no mercado, ressaltando a deficiência no mercado
de Ferramentas CASE para usuários finais.
2
Na seção dois são apresentados os conceitos gerais de Ferramentas CASE. A
implementação de um protótipo para a verificação de estruturas de base de dados Oracle é
descrita na seção três e as conclusões deste trabalho são apresentadas na seção quatro.
3
2 FERRAMENTAS CASE
Atualmente, a palavra ferramenta está muita associada à idéia de ferramenta de
software ou ferramenta automatizada, que é um software feito para auxiliar em alguma tarefa.
A Ferramenta CASE é a solução que mais tem causado revolução hoje em dia nos
ADS's (Ambiente de Desenvolvimento de Software), com ela é possível baixar em muito o
tempo total de desenvolvimento de software. Sua presença tornou-se vital para o bom
funcionamento de um ADS, auxiliando em todo o ciclo de desenvolvimento (Gerência,
Análise, Projeto, Implementação e Teste), além de exercer uma grande importância para a
manutenção do software.
Esta importância também pode estar associada ao apoio realizado pelas Ferramentas
CASE às metodologias e métodos que vão surgindo. Sem ferramentas, uma metodologia ou
método não terá boa aceitação no mercado, isto ocorreu com diagramas como o DFD
(Diagrama de Fluxo de Dados) e o E-R (Entidade – Relacionamento), que só foram
amplamente utilizados quando surgiram as primeiras ferramentas para auxiliar na tarefa de
diagramação.
2.1 Ambientes CASE
Em [YONEZAWA], o autor apresenta três tipos de ambientes CASE, a saber:
1. Lower-CASE – ferramentas de ambientes mais simples, provêm suporte à
codificação, teste, depuração e manutenção do código do software;
2. Upper-CASE – ferramentas de ambientes mais complexos, automatizam diversas
tarefas de análise e de projetos de sistemas e são capazes de gerar código
automaticamente, a partir das especificações dadas;
3. I-CASE (Integrated-CASE) – ambiente caracterizado por um grupo de Ferramentas
CASE integradas, isto é, que se relacionam entre si (entradas e saídas) e que permitem
controlar a consistência dos dados quando uma metodologia é seguida. A idéia de
metodologia embutida no ambiente garante uma maior integração entre as
ferramentas, permitindo que as próprias ferramentas façam a verificação de
consistência dos dados gerados por elas.
4
Figura 2-1 – Blocos Construtivos de CASE.
Para [PRESSMAN95], a Figura 2-1 representa uma fundação abrangente para a
integração de Ferramentas CASE. No entanto, a maioria das Ferramentas CASE utilizadas
hoje não foi construída usando todos esses blocos construtivos. De fato, algumas Ferramentas
CASE permanecem como “soluções pontuais”. Isto é, uma ferramenta é usada para assistir
uma atividade específica de engenharia de software (por exemplo, modelagem de dados) mas
não se comunica indiretamente com outras ferramentas, não está ligada a uma base de dados
de projeto, não é parte de um I-CASE. Apesar dessa situação não ser ideal, uma Ferramenta
CASE pode ser usada bastante efetivamente, mesmo sendo uma solução pontual.
2.2 Vantagens e Desvantagens
Ainda segundo [PRESSMAN95], dentre as vantagens na utilização das Ferramentas
CASE pode-se levar em consideração os seguintes itens, a saber:
1. Maior qualidade dos produtos finais – as Ferramentas CASE diminuem a
probabilidade de erros, uma vez que podem ajudar no controle de consistência dos
dados em um ADS. Também proporcionam maior eficácia dos produtos, ao auxiliarem
as fases de Análise e Teste do produto pelo usuário;
2. Produtividade – ao ajudar e até mesmo ao realizar algumas tarefas automaticamente,
as ferramentas contribuem para uma maior agilidade no desenvolvimento de software,
isto é, mais produtos em menos tempo;
3. Eliminação de trabalho monótono – as Ferramentas CASE podem realizar algumas
tarefas cansativas para os desenvolvedores, tais como procurar informações e desenhar
símbolos de um diagrama, as quais são mais suscetíveis ao erro;
4. Mais tempo para a tomada de decisão – em conseqüência de as ferramentas
realizarem certas atividades pelas pessoas, estas ficam liberadas para outras tarefas,
Ferramentas CASE
Arcabouço de integração
Plataforma de hardware
Serviços de portabilidade
Sistema operacional
Arquitetura do ambiente
5
geralmente mais nobres, que exigem tomadas de decisão e criatividade, ao invés de
tarefas repetitivas;
5. Flexibilidade para mudanças – as ferramentas permitem que sejam mudados dados e
diagramas de maneira mais rápida e fácil, o que ajuda o desenvolvedor no trabalho de
tentar satisfazer o usuário;
6. Menos programação – as ferramentas eliminam muito do trabalho de programação,
deixando mais tempo para que a equipe técnica se preocupe com a Análise do Sistema,
que é onde se define como solucionar o problema do usuário;
7. Melhor documentação – por armazenarem dados e diagramas, as ferramentas
também contribuem para uma melhor documentação do sistema, agilizando relatórios,
busca de informações e alterações;
8. Manutenção mais fácil e ágil – por conseqüência do item anterior, é possível ter
mais informações sobre o software na hora de realizar sua manutenção (correção,
atualização ou expansão).
Conforme [TRAVASSOS], as vantagens descritas acima podem ser rebatidas com
algumas desvantagens:
1. Incompatibilidade de ferramentas;
2. Elevado custo da ferramenta e do treino para a sua utilização;
3. Limitações na flexibilidade da documentação;
4. Impossibilidade de utilizar vários métodos na mesma ferramenta;
5. Modificação cultural;
6. Ferramentas de gerência não integradas ás atividades;
7. Armazenamento de dados inadequados.
2.3 Taxonomia
Para melhor entender o âmbito de CASE e para melhor apreciar onde tais ferramentas
podem ser aplicadas, é necessária a criação de uma taxonomia de Ferramentas CASE. Alguns
riscos são inerentes sempre que se tenta categorizar Ferramentas CASE, pois uma confusão
(ou antagonismo) pode surgir ao se colocar uma ferramenta específica numa categoria,
quando outros poderiam acreditar que ela pertencesse à outra categoria.
Segundo [TRAVASSOS], inicialmente pode-se considerar a seguinte taxonomia,
descrita na Figura 2-2:
6
1. Ferramentas Horizontais – oferecem serviços utilizados durante todo o ciclo de vida
de um software, tais como suporte à documentação e gerenciamento de versões e
configurações;
2. Ferramentas Verticais – são utilizadas em fases específicas do ciclo de vida de um
software, tais como análise de requisitos e teste de software.
Figura 2-2 – Classificação de Ferramentas CASE.
Um outro tipo de taxonomia pode ser criado conforme o conjunto de serviços
principais que as Ferramentas CASE oferecem. Um serviço é uma ação efetuada pelo
computador que é de interesse do desenvolvedor [SCHEFSTRÖ E BROEK]. Uma proposta
de classificação é apresentada na tabela 2-1 [PRESSMAN92]. Através desta tabela podemos
observar o amplo espectro de Ferramentas CASE existentes, apesar de ser comum a referência
a Ferramentas CASE como ferramentas específicas para análise e projeto de software.
Tabela 2-1 – Classificação de Ferramentas CASE.
Atividades Exemplos de Ferramentas
Planejamento de Sistemas Gerenciais Foundation, Interactive Engineering Workbench, Information Engineering Facility;
Gerenciamento de Projetos SuperProject, Microsoft Project, MacProject II, ESTIMATES;
Especificação de Requisitos CORE, RMS/PC, R-Trace; Especificação Formal de Sistemas CADIZ, OBJ; Documentação Interleaf, Page Maker (Aldus); Comunicação Utilitários do Unix, Microsoft mail; Controle de Qualidade Q/Auditor, Auditor; Gerenciamento de Versões e Configurações SCCS do Unix, PVCS ; Análise e Projeto de Software JSD, SADT, HOOD, PC Case, OMT; Projeto e Desenvolvimento de Interfaces Interviews, Lucas Film; Programação Turbo X’s, Anna.
7
Baseando-se agora em [PRESSMAN95], tem-se uma taxonomia de Ferramentas
CASE por função semelhante à descrita na tabela 2-1, a saber:
1. Ferramentas de Engenharia de Processo de Negócio – estas ferramentas modelando
os requisitos de informação estratégica de uma organização, fornecem um
“metamodelo” a partir do qual são derivados sistemas de informação específicos. Em
vez de focalizar os requisitos de uma aplicação específica, a informação do negócio é
modelada à medida que se move entre as várias entidades organizacionais de uma
companhia. O objetivo principal das ferramentas dessa categoria é representar os
objetos de dados de negócio, seus relacionamentos e como esses objetos de dados
fluem entre as diferentes áreas de negócio, dentro de uma companhia;
2. Ferramentas de Gerenciamento de Projetos – uma ferramenta para auxílio à
Gerência de Projetos de Desenvolvimento de Software deve armazenar informações
sobre orçamento (custos e investimentos), cronogramas, atividades, recursos,
documentos e decisões. Deve oferecer recursos para que sejam feitos gráficos tais
como atividades X pessoal, atividades X recursos, pessoal X recursos ou deve ela
mesma gerar estes gráficos a partir de informações fornecidas pelo usuário. Quando
houver algum problema (por exemplo, atraso no cronograma ou gastos excedentes), a
ferramenta deve avisar o Gerente de Projeto e recalcular as conseqüências (o novo
prazo ou o aumento nos custos). Esta ferramenta também deve ser responsável pelo
armazenamento dos documentos do Projeto (tais como relatórios de
andamento/atividades, planos, atas de reuniões, etc). Outra tarefa importante é o
Controle de Versões, pois durante o desenvolvimento de software, são criadas várias
versões do sistema, sendo que cada versão é composta de versões de módulos. Então,
a ferramenta deve armazenar informações sobre quais módulos foram utilizados, onde
eles estão guardados, quem os fez e como eles foram integrados. Estas informações
serão importantes no caso de manutenção do sistema;
3. Ferramentas de Documentação – ferramentas de produção de documentos e de
editoração eletrônica apóiam praticamente toda a engenharia de software. A maioria
das organizações de desenvolvimento de software gasta uma grande quantidade de
tempo desenvolvendo documentos e, em muitos casos, o processo de documentação
propriamente dito é bastante ineficiente. É comum uma organização de
desenvolvimento de software gastar 20% ou 30% de todo o esforço de
desenvolvimento de software em documentação. Por esta razão, as ferramentas de
documentação fornecem uma importante oportunidade para melhorar a produtividade;
8
4. Ferramentas de Garantia de Qualidade – a maioria das Ferramentas CASE que
alegam focalizar garantia de qualidade são na verdade ferramentas de métricas que
fazem a auditoria do código-fonte para assegurar o atendimento das normas de
linguagem. Outras ferramentas extraem métricas técnicas num esforço de projetar a
qualidade do software que está sendo construído;
5. Ferramentas de Gestão de Configuração de Software – a gestão de configuração de
software fica no miolo de qualquer ambiente CASE. As ferramentas podem assistir as
cinco principais tarefas de SCM (Software Configuration Management) (identificação,
controle de versão, controle de modificação, auditoria e listagem de categorias);
6. Ferramentas de Prototipação – diversas ferramentas diferentes de prototipação
podem ser usadas. Pintores de tela permite ao engenheiro de software definir o layout
de tela rapidamente para aplicações interativas. As ferramentas CASE de prototipação
mais sofisticadas permitem a criação de projeto de dados acoplado com layout, tanto
de tela quanto de relatório. Muitas ferramentas de análise e projeto têm extensões que
fornecem uma opção de prototipação. As ferramentas PRO/SIM
(Prototipação/Simulação) geram estruturas de código-fonte Ada e C para construir
aplicações (de tempo real). Finalmente, diversas ferramentas de quarta geração têm
característica de prototipação;
7. Ferramentas de Reengenharia – ferramentas para software herdado. Compõem um
conjunto de atividades de manutenção que atualmente absorvem uma significativa
porcentagem de todo o esforço relacionado a software. A categoria de ferramentas de
reengenharia pode ser subdividida nas seguintes funções:
7.1 Ferramentas de engenharia reversa para especificação – aceitam o código-
fonte como entrada e geram modelos gráficos de análise e projeto estruturado,
listas de onde onde-usado e outras informações de projetos;
7.2 Ferramentas de reestruturação e análise de código – analisam a sintaxe do
programa, geram um grafo de fluxo de controle e geram automaticamente um
programa estruturado;
7.3 Ferramentas de reengenharia de sistemas on-line – são usadas para
modificar sistemas de base de dados on-line.
Essas ferramentas são limitadas a linguagens de programação específicas (apesar da
maioria das principais linguagens serem apoiadas) e requerem algum grau de interação
com o engenheiro de software;
9
8. Ferramentas de Análise e Projeto – ferramentas de análise e projeto permitem ao
engenheiro de software criar modelos do sistema a ser construído. Os modelos contêm
uma representação dos dados, funções e comportamento (em nível de análise) e
caracterizações do projeto de dados, arquitetural, em nível de componente e de
interface. Pela a realização de verificações de consistência e de variedades de modelos,
as ferramentas de análise e projeto fornecem aos engenheiros de software um certo
grau de discernimento na representação da análise e ajudam a eliminar erros, antes que
se propaguem para o projeto, ou pior, para a implementação propriamente dita;
9. Ferramentas de Programação – hoje em dia já existem inúmeras ferramentas para
projeto e implementação automática de interfaces. As mais simples geram a interface
(inclusive o código do programa) a partir de descrições feitas por um projetista. Outras
permitem a criação interativa da interface através de facilidades tais como: escolher
um elemento de interface (menu, botão, barras, etc), posicioná-lo na tela, associar a ele
uma rotina a ser chamada, alterar suas propriedades (cor, título, etc). As novas
linguagens de programação (por exemplo, Visual-Basic, Delphi e Borland C++) já
trazem embutidas estas tais ferramentas, imprescindíveis para um ambiente de
programação. Entretanto, estas ferramentas ainda devem ser aperfeiçoadas para
permitir a criação de interfaces avançadas, por exemplo, que utilizam recursos de
multimídia (sons, imagens estáticas e vídeos);
10. Ferramentas de Integração de testes – em seu indicador de ferramentas de testes
de software, a engenharia de qualidade de software define as seguintes categorias de
ferramentas de testes:
10.1 Aquisição de dados – ferramentas que adquirem dados a serem usados
durante o teste;
10.2 Medição estática – ferramentas que analisam o código-fonte sem executar
casos de teste;
10.3 Medição dinâmica – ferramentas que analisam o código-fonte durante a
execução;
10.4 Simulação – ferramentas que simulam funções de hardware e outros
dispositivos externos;
10.5 Gestão de testes – ferramentas que assistem o planejamento,
desenvolvimento e controle de testes;
10.6 Ferramentas de cruzamento funcional – ferramentas que cruzam as
fronteiras das categorias precedentes.
10
Deve-se levar em conta que muitas ferramentas de testes têm características que
abrangem duas ou mais destas categorias.
2.4 Arquitetura
As Ferramentas CASE encontradas atualmente no mercado geralmente funcionam de
forma isolada. Estas utilizam formatos de dados proprietários, o que impede que ferramentas
façam uso dos dados produzidos uma das outras. Exemplos dos tipos de arquitetura existentes
são mostrados na Figura 2-3 [BROWN E FEILER].
Figura 2-3 – Exemplos de Arquitetura de Ferramentas CASE..
O exemplo 2-3a. mostra uma ferramenta filtro que recebe arquivo de dados como
entrada e transforma em arquivos de saída. Os arquivos trazem dentro de si o formato de
dados da ferramenta, que geralmente é de complexa compreensão. O exemplo 2-3b. mostra
uma ferramenta que utiliza um dicionário de dados para catalogar suas informações.
Finalmente, o exemplo 2-3c. ilustra uma ferramenta que utiliza um gerenciador de banco de
dados para armazenamento de suas informações.
Banco de Dados
Ferramentas
com Banco de Dados
Ferramentas
Filtro
Fontes Dados Derivados
Ferramentas
com Dicionário de
Dados
Dicionário de Dados
...
a)
b)
c)
11
3 IMPLEMENTAÇÃO DO PROTÓTIPO
O protótipo “DBComparer”, desenvolvido na linguagem de programação orientada a
objetos Borland Delphi 5, atua na fase de manutenção do ciclo de vida de um software, pois
realiza a tarefa de verificação da estrutura de base de dados dos bancos Oracle detectando a
existência de erros com eficiência e eficácia, sendo direcionado à utilização de usuários finais
no papel de clientes do produto de software.
Para a obtenção da estrutura da base de dados para a realização da verificação foi
necessária a realização de um estudo sobre a arquitetura dos Bancos de Dados Oracle,
apresentado na seção 3.1.
Na seção 3.2, está detalhada a forma de obtenção da estrutura da base de dados sendo
seguida pela seção 3.3, que apresenta a forma em que a verificação se baseia.
3.1 Arquitetura do Banco de Dados Oracle
Segundo [LONEY], um banco de dados Oracle armazena seus dados em arquivos,
sendo que existem estruturas internas do banco de dados que fornecem um mapeamento
lógico dos dados para estes arquivos, permitindo que diferentes tipos de dados sejam
armazenados separadamente. Essas divisões lógicas são chamadas de tablespaces. Cada banco
de dados tem no mínimo um tablespace chamado tablespace SYSTEM.
As tabelas de dicionário de dados armazenam todas as informações sobre todos os
objetos do banco de dados: código fonte dos pacotes, procedimentos, funções, triggers,
métodos etc. Os segmentos de dicionário de dados que armazenam fisicamente as tabelas de
dicionário de dados, estão armazenados no tablespace SYSTEM.
3.2 Obtenção da Estrutura da Base de Dados
A estrutura da base de dados é adquirida pelo protótipo através de comandos selects
nas tabelas dos dicionários de dados da tablespace SYSTEM do Oracle. Esses comandos
selects foram obtidos utilizando os aplicativos SQL Explorer e SQL Monitor
concorrentemente.
12
Figura 3-1 – Telas dos aplicativos SQL Explorer e SQL Monitor atuando concorrentemente
3.3 Verificação da Estrutura de Base de Dados
A forma de verificação da estrutura de base de dados se baseia na comparação da base
de dados do desenvolvedor com a base de dados do cliente.
3.3.1 Gerador de Arquivo Binário
Inicialmente foi desenvolvido um gerador de arquivos binários direcionado apenas a
utilização do desenvolvedor. Os usuários finais terão acesso apenas ao protótipo
“DBComparer” e a um arquivo binário criado pelo desenvolvedor através deste gerador,
contendo a estrutura de base de dados correta que será base de comparação com a estrutura de
base de dados do cliente.
A opção de trabalhar com arquivos binários foi escolhida na intenção de se evitar que
o usuário final altere dados contidos no arquivo, o que não seria possível com a utilização de
arquivos textos.
13
Figura 3-2 – Tela do Gerador de arquivos binários
Para a geração do arquivo binário é necessária a configuração do diretório de destino
do arquivo a ser gerado e a realização da conexão com a base de dados em que se deseja
armazenar a estrutura no arquivo.
3.3.2 Protótipo “DBComparer”
Ao ser iniciado, o protótipo considera as configurações de base de dados gravadas em
um arquivo .ini (inicialização) criado anteriormente. Caso este arquivo ainda não exista, é
necessário que antes do acionamento da verificação da base de dados, o usuário acesse a
opção de conexão com o banco de dados para que o protótipo se conecte a base de dados que
deverá ser verificada e gere o arquivo .ini.
O usuário terá a opção de realizar a verificação de todos os objetos existentes na
estrutura de uma base de dados ou de selecionar apenas o(s) objeto(s) que deseja verificar.
14
Figura 3-3 – Tela principal do “DBComparer”
Quando acionado o botão “Verificar Base” todos os objetos ou apenas os escolhidos
terão sua consistência verificada, sendo que toda comparação é realizada com base no arquivo
binário gravado no mesmo diretório que o executável do “DBComparer”.
Para a execução dos comandos selects na base do cliente e para o armazenamento dos
dados resultantes destes comandos, é utilizado um componente da linguagem DELPHI 5
chamado TQuery, destinado a transmitir comandos SQL para um banco de dados.
Com a estrutura correta armazenada no arquivo binário e a estrutura a ser verificada
armazenada em queries, o arquivo binário é aberto e lido para que seja iniciada a comparação
das duas base de dados.
Ao término da verificação, é exibida uma mensagem informando o usuário Figura 3-4.
Figura 3-4 – Mensagem exibida após o término da verificação
15
Com o término da verificação também é gerado um log (Figura 3-5) que pode ser
visualizado tanto na janela principal do “DBComparer” ou no arquivo .log gerado e gravado
no mesmo diretório que o executável do “DbComparer”.
Figura 3-5 – Tela principal do “DBComparer” com o Log de re sultado
16
4 CONCLUSÃO
A pesquisa desenvolvida ao longo deste trabalho buscou o conhecimento sobre
Ferramentas CASE, focando-se principalmente nos diversos tipos de Ferramentas existentes
atualmente no mercado, para que fosse possível destacar a deficiência no mercado destas para
usuários finais. Para tanto, foi implementado um protótipo de Ferramenta Case que atua na
fase de manutenção do ciclo de vida do software, realizando a tarefa de verificação da base de
dados dos clientes.
Ao longo desta pesquisa ficou claro o nível de entusiasmo representado pela área de
Ferramentas CASE perante a Engenharia de Software, já que é através dessas ferramentas que
os desenvolvedores observam suas técnicas e capacidades aplicadas ao próprio processo de
desenvolvimento de software, tornando este processo preciso, efetivo e assistido, além de
beneficiar a comunidade em geral obtendo um desenvolvimento de software de qualidade.
Talvez seja pelo fato de que as Ferramentas CASE sejam desenvolvidas objetivando a
automação de tarefas executadas durante o ciclo de vida de um software, que geralmente são
direcionadas apenas à utilização dos desenvolvedores de software. A implementação do
protótipo sugere a utilização “em conjunto” de desenvolvedores e usuários finais, o nde o
usuário final, no caso o cliente, atua diretamente na execução do protótipo de Ferramenta
CASE no lugar do desenvolvedor, que não possui mais a sua presença pessoal ou por telefone
solicitada para a realização da tarefa, já que com a utilização do protótipo, as informações
corretas não são mais de posse apenas do desenvolvedor. Desta forma, temos uma Ferramenta
CASE atuando na automação de uma tarefa executada durante uma das fases do ciclo de vida
de um software: a fase de manutenção, direcionada à utilização de usuários finais.
A tendência é de cada vez mais surgir ferramentas que auxiliem no desenvolvimento
de software, tornando os ambientes de desenvolvimento de software cada vez mais
qualitativos, automatizados e, conseqüentemente, mais eficazes e eficientes. Este é o atual
desafio da engenharia de software: projetar Ferramentas CASE que atuem o mais eficaz
possível.
4.1 Contribuições
Resumidamente, as principais contribuições gerais deste estudo foram o conhecimento
dos diversos tipos de Ferramentas CASE destacando sua importância para a Engenharia de
Software, além da implementação do protótipo de Ferramenta CASE direcionada a utilização
17
de usuários finais, que realiza a árdua tarefa de verificação da estrutura de bases de dados
Oracle, automatizando e tornando mais eficaz e eficiente a fase de manutenção do ciclo de
vida de softwares, auxiliando não apenas o trabalho do usuário final como também o trabalho
do desenvolvedor de software.
4.2 Extensões
Este trabalho pode ser continuado implementando-se à rotina de verificação de bases
de dados Oracle, uma rotina para correção automática dos erros encontrados na verificação.
Desta forma, além de realizar a árdua tarefa de verificar cada objeto da estrutura das bases de
dados Oracle, o protótipo também atualizaria automaticamente a estrutura da base de dados
do cliente caso fosse solicitado.
Uma outra aplicação que poderia ser realizada seria abranger a verificação para base
de dados de outros bancos de dados, não estando restrito apenas a base de dados Oracle. Esta
extensão seria de grande utilidade apesar de apresentar maior complexidade que a anterior.
18
Apêndice 1 – Exemplos de comandos selects utilizados na
implementação do protótipo
A seguir são apresentados alguns comandos selects utilizados para obtenção das estruturas
das bases de dados Oracle.
SELECT TABLE_NAME
FROM SYS.ALL_TABLES
WHERE OWNER = UPPERCASE('server name')
SELECT TABLE_NAME, INDEX_NAME, UNIQUENESS, STATUS
FROM SYS.ALL_INDEXES
WHERE (TABLE_NAME = 'nome tabela')
ORDER BY TABLE_NAME, INDEX_NAME
SELECT TABLE_NAME, CONSTRAINT_NAME, R_CONSTRAINT_NAME, STATUS
FROM SYS.ALL_CONSTRAINTS
WHERE ((TABLE_NAME = 'nome tabela') AND (CONSTRAINT_TYPE = 'R'))
ORDER BY TABLE_NAME, CONSTRAINT_NAME
SELECT TABLE_NAME, SEARCH_CONDITION
FROM SYS.ALL_CONSTRAINTS
WHERE ((TABLE_NAME = 'nome tabela') AND (CONSTRAINT_TYPE = 'C'))
ORDER BY TABLE_NAME, CONSTRAINT_NAME
SELECT TRIGGER_NAME, TRIGGER_TYPE, TRIGGERING_EVENT, TABLE_NAME,
TRIGGER_BODY, STATUS
FROM SYS.ALL_TRIGGERS
WHERE (TABLE_NAME = 'nome tabela')
ORDER BY TABLE_NAME, TRIGGER_NAME
SELECT OBJECT_NAME, STATUS
FROM SYS.ALL_OBJECTS
WHERE (OWNER = UPPER('server name')) AND
(OBJECT_TYPE = 'VIEW')
ORDER BY OBJECT_NAME
19
SELECT OBJECT_NAME, STATUS
FROM SYS.ALL_OBJECTS
WHERE OWNER = UPPER('server name') AND
((OBJECT_TYPE = 'FUNCTION') OR (OBJECT_TYPE = 'PROCEDURE'))
ORDER BY OBJECT_NAME
SELECT A.SEQUENCE_NAME, A.INCREMENT_BY, A.MIN_VALUE, A.CYCLE_FLAG,
A.ORDER_FLAG, A.CACHE_SIZE, B.STATUS
FROM SYS.ALL_SEQUENCES A, SYS.ALL_OBJECTS B
WHERE (A.SEQUENCE_OWNER = UPPER('server name') AND
A.SEQUENCE_NAME = B.OBJECT_NAME AND
A.SEQUENCE_OWNER = B.OWNER) AND
A.SEQUENCE_NAME = B.OBJECT_NAME)
ORDER BY A.SEQUENCE_NAME
20
Referências Bibliográficas
BROWN e FEILER. Understanding Integration in a Software Development Environment: Issues and Illustrations. Jounal of Systems Integration, 1993. LONEY, Kevin. Oracle 8i: o manual do DBA. 1a Edição. Campus, Rio de Janeiro, 2000. PRESSMAN, Roger S. Engenharia de Software. 5a Edição. Makron Books, São Paulo,1995. PRESSMAN, Roger S. Software Engineering: A Parctioner’s Approach. 3a Edição. McGraw-Hill,1992. SCHEFSTRÖ e BROEK. Tool Integration: Environments and Frameworks. John Wiley & Sons Ltd., Inglaterra, 1993. TRAVASSOS, Guilherme H. Ambientes de Desenvolvimento de Software. UFRJ COPPE/Sistemas, Rio de Janeiro, 2001. Disponível em: http://www.cos.ufrj.br/~ght. Acesso em: 17 abr. 2004. YONEZAWA, W. M. Engenharia de Software I. URL: http://www.dco.fc.unesp.br/~yonezawa/bsi1999_02/trabgrupo/grupo08t01.ppt. Recuperado em: 17/04/2004.
21
Bibliografia Consultada
CANTÚ, Marco. Delphi 5 – A Bíblia. 1ª Edição. São Paulo: Makron Books, 2000. FANDERUFF, Damaris. Oracle 8i – Utilizando SQL* Plus e PL/SQL. 1ª Edição. São Paulo: Makron Books, 2000. FISHER, Alan S. CASE – Utilização de Ferramentas para desenvolvimento de Software. 1ª Edição. Rio de Janeiro: Editora Campus, 1990. JANONES, Ramos de Souza e SANTOS JUNIOR, Linces Marques dos. Delphi & Oracle 8. 1ª Edição. São Paulo: Makron Books, 2000. MARTIN, James e McCLURE, Carma. Técnicas Estruturadas e CASE. 1ª Edição. São Paulo: Makron Books, 1991. SOMMERVILLE, Ian. Engenharia de Software. 6ª Edição. São Paulo: Addison Wesley, 2003. VAVASSORI, Fabiane Barreto. Análise Comparativa de Ferramentas CASE para Gerenciamento de Projeto. URL: http://inf.univali.br/~gemetrics/artigoicie2001.pdf. Recuperado em: 24/09/2004. WALLNAU, Kurt C. e FEILER, Peter H.Tool Integration and Environment Architectures. Software Engineering Institute, CMU/SEI-91-TR-11, 1991. URL: http://www.sei.cmu.edu/pub/documents/91.reports/pdf/tr11.91.pdf . Recuperado em: 24/10/2004.
