projeto de banco de dados para a segurança

Evolvere Scientia, V. 2, N. 1, 2013
Evolvere Scientia
ARTIGO
UNIVERSIDADE FEDERAL DO VALE DO SÃO FRANCISCO
PROJETO DE BANCO DE DADOS PARA A SEGURANÇA PÚBLICA DE PETROLINA
Felipe Pinheiro Correia1, Ricardo Argenton Ramos², Edmundo S. Spoto³, Rodolfo do
Nascimento Zacarias4, Rodrigo Moreira Bacurau5
1,2,5
Universidade Federal do Vale do São Francisco, 48902-300 Juazeiro, BA, Brasil.
3
Universidade Federal de Goiás, 75801-615 Goiânia, GO, Brasil.
4
Faculdade Paraíso do Ceará, 63260-000 Juazeiro do Norte, CE, Brasil.
1
4
2
[email protected],
[email protected],
5
[email protected] , [email protected]
3
[email protected],
Resumo: Este artigo trata das etapas de elaboração do projeto e da construção de um Banco de
Dados para a Secretaria de Segurança Pública da cidade de Petrolina, no estado de Pernambuco.
O trabalho teve como objetivo o estudo e o aperfeiçoamento de técnicas para o projeto de
Bancos de Dados de grande porte, seguindo as práticas de engenharia e teste de softwares e
utilizar os resultados para que fosse elaborado o Banco de Dados. A metodologia para o projeto,
implementação e testes do Banco de Dados é discutida. Para o desenvolvimento do Banco de
Dados, inicialmente, o levantamento dos requisitos e especificações dos objetos de dados foi
realizado. Em seguida, os Diagramas Entidade Relacionamento (DER) foram elaborados. O
próximo passo consistiu na definição de um plano de testes e execução dos casos de testes. Os
resultados obtidos foram avaliados e os erros detectados foram corrigidos. Obteve-se um Banco
de Dados com uma quantidade reduzida de erros e uma metodologia para o projeto e
implementação de Bancos de Dados de grande porte.
Palavras-chave: Banco de dados, teste, engenharia de software
Abstract: This article deals with the stages of design and construction of a database for the
Public Security of Petrolina city, in Pernambuco, Brazil. The work aimed to study and improve
the techniques for the design of large databases, following the practices of software engineering
and test engineering and use the results to prepare the database. The methodology for the
design, implementation and testing of the database is discussed. In order to develop the database
a survey of the requirements and specifications of the data objects was performed. Then the
120
Evolvere Science, V. 2, N. 1, 2013
Entity Relationship Diagrams (ERD) was prepared. The next step consisted of defining a test
plan and executing test cases. The results were evaluated and the errors detected were corrected.
It has been obtained a database with a reduced amount of errors and a methodology for the
design and implementation of large databases.
Keywords: Database, test, software engineering
INTRODUÇÃO
Um dos principais objetivos da
De acordo com Elmasri e Navathe
atividade de teste de software e de banco de
(2005), um Banco de Dados (BD) é um
dados é garantir que o sistema funcione
conjunto de dados relacionados que são
corretamente e atenda as especificações dos
fatos que podem ser gravados e possuem
usuários, porém é considerado o processo
um
o
mais caro no desenvolvimento de software
mesmo autor, os BDs relacionais foram
chegando a consumir mais de 30% dos
criados para separar o armazenamento
recursos necessários para este fim segundo
físico dos dados de sua representação
Hartman (2002). Chays (2000) comenta que
conceitual e provê uma fundamentação
existem vários aspectos que indicam se o
matemática para os bancos de dados. O uso
sistema está funcionando corretamente,
de BD relacionais nos mais variados setores
como, por exemplo, o comportamento da
possibilitou a organização, segurança e
aplicação, se o esquema do banco de dados
persistência de informações essenciais para
reflete
inúmeras
instituições
segurança e privacidade estão protegidos de
públicas, por exemplo, podem garantir,
forma correta e se o Sistema Gerenciador
fazendo uso de um Banco de Dados bem
de Banco de Dados (SGBD) realiza todas as
construídos, uma melhor eficiência e
operações corretamente.
significado
implícito.
atividades.
Segundo
As
o
mundo
real,
fatores
como
suas
Um sistema de segurança pública,
atividades. Para desenvolver um banco de
por exemplo, envolve todas as áreas de
dados de qualidade, segundo alguns autores
atendimento e gerência para tomadas de
como Silberchatz et al. (2006), e Elmasri e
decisão visando tornar o atendimento ágil,
Navathe (2005), devem ser seguidas as
controlar as ações, criar estratégias de
seguintes etapas: etapas de requisitos,
prevenção, construir relatos de execução e
projeto lógico e físico e finalizar com testes
poder gerenciar de forma rápida e segura
de verificação das principais características
todos os materiais e mão de obras
do BD.
envolvidas no atendimento. Levando esse
eficácia
no
desenvolvimento
de
fato em consideração, o objetivo deste
121
Evolvere Science, V. 2, N. 1, 2013
trabalho foi a construção de um Banco de
eles: casos de uso, atividades e classes. Os
Dados com qualidade para atender o setor
diagramas de casos de uso são visões que
de segurança pública em Petrolina. Devido
modelam as funcionalidades do sistema
às necessidades da Polícia Militar (PM) foi
observadas
implementado, inicialmente, um banco de
chamados atores. Um caso de uso é uma
dados para armazenar as informações do
unidade
Boletim
as
expressada como uma transação entre
informações pertinentes a todos os policiais
atores e o sistema, de acordo com
do 5º Batalhão. Para isso serão utilizados os
Rumbaugh
diagramas da Unified Modeling Language
diagrama de caso de uso é listar os atores e
(UML) e a técnica de teste funcional
casos de uso e mostrar qual ator participa
baseada nas características do projeto de
em cada caso de uso. Na Figura 1 é
banco de dados. É essencial para o setor de
apresentado o diagrama de casos de uso
Recursos Humanos (RH) da PM armazenar
modelado para o sistema da PM.
Interno
(BI)
e
cadastrar
pelos
usuários
coerente
de
(2004).
O
de
fora,
funcionalidade
propósito
do
várias informações que compõem o BI e
montam um histórico do policial dentro da
polícia.
UML
De acordo com Rumbaugh (2004), a
UML é uma família de notações gráficas
utilizada no projeto e na descrição de
sistemas de software, particularmente em
softwares orientados a objetos. A partir da
confecção desses diagramas é possível
entender melhor e sistema e ter uma visão
Figura 1 – Diagrama de Casos de Uso do
geral do comportamento de cada ator dentro
Sistema da PM
de seus limites, ou seja, é possível entender
melhor o mundo real, ou como é chamado
às vezes de mini-mundo ou Universo de
Discurso (UoD).
Com os diagramas da UML é
possível realizar o processo de modelagem.
Com o objetivo de visualizar, construir, e
documentar os artefatos do sistema, alguns
diagramas da UML foram utilizados, são
122
Segundo
diagrama
de
Rumbaugh
atividades
(2004),
o
descreve
o
comportamento paralelo e procedural do
sistema. Uma atividade corresponde a um
conjunto
de
organizadas
ações
de
responsabilidades,
que
devem
ser
acordo
com
as
descrito
em
como
Ramos (2006). Na Figura 2, é possível
Evolvere Science, V. 2, N. 1, 2013
observar como os atores agem em cada caso
modelagem conceitual, lógica e física dos
de uso (cada caso de uso possui um
dados.
diagrama
de
atividades)
para
que
determinada atividade possa ser realizada,
como, por exemplo, o cadastro de um
policial.
Figura 3 – Diagrama de Classes do Sistema
da PM
A criação de um projeto conceitual
é indispensável, para em seguida montar
Figura 2 – Diagrama de Atividades do
um esquema conceitual dos dados. Essa
sistema da PM .
etapa independe do SGBD e o maior
Um diagrama de classe (Rumbaugh,
propósito é tentar entender o mini-mundo.
2004) é uma apresentação gráfica da visão
O modelo conceitual proporciona uma
estática que mostra uma coleção de
visão
elementos de modelo informativo (estático),
relacionamentos do sistema, independente
como, por exemplo, classes, tipos, e seus
de como serão implementados. O resultado
conteúdos e relacionamentos. Na Figura 3 é
dessa fase do projeto é um esquema que
apresentado
representa a realidade das informações
o
diagrama
de
classes
confeccionado para o sistema da PM.
de fatos que refletem características do
mundo real. Em todo o momento o que está
registrado no banco representa uma visão
instantânea do mini-mundo (Machado,
2004). Para construir um banco de dados é
necessário algumas etapas de projeto:
123
dos
principais
dados e
existentes.
A próxima etapa, o projeto lógico,
BANCO DE DADOS RELACIONAL
Um banco de dados é um conjunto
global
consiste em descrever as estruturas contidas
no banco de dados, resultando em um
esquema lógico. Existem três abordagens de
modelo
lógico:
hierárquica,
rede
e
relacional. Neste trabalho foi utilizado o
modelo relacional.
Evolvere Science, V. 2, N. 1, 2013
Finalmente, a partir do modelo
A e B, a restrição de razão de
lógico, é criado o modelo físico onde são
cardinalidade
descritas
máximo
as
o
número
físicas
de
como
por
relacionamentos das entidades pode
exemplo, o tamanho dos campos, os índices
participar (Silberschatz e Korth., 2006;
e o tipo de preenchimento dos campos.
Elmasri e Navathe, 2005).
armazenamento
estruturas
especifica
de
dados,
que
a
instância
de
O banco de dados relacional possui
Ex.: No BD da PM existem várias
algumas características importantes como
tabelas, dentre elas: Policial, Punição e
as chaves, o domínio dos valores e as
Posto. Cada policial pode ter nenhuma
restrições
que
ou várias punições (notação: 1:N). Já
relacional.
As
compõem
chaves
o
modelo
permitem
o
com relação às tabelas posto e policial,
estabelecimento das relações entre linhas e
cada policial só pode ter apenas um
tabelas. Existem três tipos de chave: a
posto (notação: 1:1).
chave primária, a chave alternativa e a
chave estrangeira. O domínio dos valores
•
regras fundamentais de acordo com
de um campo é o conjunto de valores
Elmasri e Navathe (2005), são elas a
especificados para aquele campo, por
restrição de unicidade e a integridade
exemplo, o campo CPF da tabela policial da
de identidade. A restrição de unicidade
base de dados da PM não pode conter
determina que duas tuplas distintas não
valores nulos e deve possuir onze caracteres
possam ter o mesmo valor para todos os
que são validados de acordo com um
seus atributos chaves. A integridade de
algoritmo de validação do CPF.
identidade determina que uma chave
Existem muitas limitações ou restrições
primária não possa conter valores nulos
para os valores reais em um estado do
(nulls). Ex.: O código do policial (id)
banco de dados (Elmasri e Navathe, 2005).
deve ser único e não nulo.
As restrições limitam possíveis valores dos
estados de um banco de dados para que ele
reflita o mundo real com maior precisão
(Chays, 2000). Os critérios de testes são
baseados
nas
restrições
do
Modelo
Relacional e são estabelecidos a partir da
especificação
do
software.
Existem
basicamente seis tipos de restrições:
•
As restrições de chaves possuem duas
•
Segundo Elmasri e Navathe (2005) a
Integridade Referencial é classificada
entre duas relações e é usada para
manter a consistência entre as tuplas
nas duas relações. Informalmente, a
restrição de integridade referencial
declara que uma tupla em uma relação,
que faz referência à outra relação, deve-
Em um conjunto de relacionamento
se referir a uma tupla existente nessa
binário R entre conjuntos de entidades
relação. Ex.: Ao tentarmos inserir em
124
Evolvere Science, V. 2, N. 1, 2013
•
um policial um posto que não esteja
que devem ser testadas pelo sistema,
cadastrado, o banco de dados deve
para verificar se os tipos de domínios
rejeitar essa inserção.
são compatíveis (ou válidos), como
As restrições de integridade semântica,
também, possibilitam testar consultas
segundo Mello (2003), têm como
para assegurar que as comparações
objetivo
as
façam sentido. Ex.: O CPF do policial
restrições de tipos de dados de um
deve ser não nulo, e possuir exatamente
atributo, mas também, seus valores
onze caracteres.
abranger
não
apenas
permitidos e transições de valores
válidos, de modo a garantir sua
integridade especificada e imposta em
um
•
BD
relacional.
Ex.:
Ao
ser
Segundo Myers (1979), o teste de
programas
consiste
em
exercitar
o
cadastrado um novo policial a altura
programa através de dados de entrada
dele deve estar entre 100 cm e 300 cm
(dados de teste) e comparar os valores de
(não existem policiais com menos de 1
saída produzidos (resultado computacional)
metro nem com mais de 3 metros).
com o resultado esperado (definido pelas
Segundo Elmasri e Navathe (2005), a
especificações do programa). O objetivo do
Dependência Funcional (DF) é uma
teste é encontrar defeitos existentes no
restrição
de
programa e é um método muito difundido,
atributos do BD. Representa-se por
embora imperfeito, de garantia de qualidade
X→Y, no qual X e Y são conjuntos de
de software (AMMANN e OUTT, 1994).
entre
dois
conjuntos
atributos e subconjuntos de uma relação
R. O conjunto de atributos de Y é
chamado de lado à direita e o X de lado
à esquerda. Pode-se dizer que Y
depende
funcionalmente,
ou
são
determinados por valores do conjunto
de
X,
ou
seja,
funcionalmente
•
TESTE DE FUNCIONAL
os
X
determinam
valores
de
Y
A atividade de testes pode se tornar
bastante
complexa,
dependendo
das
características e dimensões do sistema a ser
criado. Por isso, está sujeita a diversos tipos
de problemas que acabam resultando na
obtenção de um produto diferente daquele
que se esperava (DELAMARO et al, 2007).
(Machado e Abreu, 1996; Elmasri e
A técnica de teste funcional é
Navathe, 2005). Ex.: CPF→Nome, ou
também conhecida por técnica de teste
seja, o CPF do policial determina
caixa preta, por não utilizar o código fonte e
funcionalmente o nome do policial.
sim extrair os requisitos de testes a partir da
Restrições
segundo
especificação. Neste trabalho, a técnica
Silberschatz e Korth (2006), são regras
funcional foi aplicada no projeto de banco
125
de
Domínio,
Evolvere Science, V. 2, N. 1, 2013
de dados, extraindo os elementos de testes
praticar na base de dados desenvolvida os
do
requisitos levantados durante a etapa de
documento
de
requisitos.
Outras
informações para aquisição dos elementos
de testes também serão consultadas os
diagramas da UML utilizados no projeto do
sistema.
As restrições implementadas no
banco de dados são usadas para proteger o
banco de possíveis erros gerados na
aplicação, e o teste garante que essas
restrições de fato o protegem. A aplicação
de um conjunto de operações de comandos
Structure
Query
Language
(SQL),
levantamento de requisitos.
Critério Baseado nas Estruturas de
Relacionamentos
Em um conjunto de relacionamento
binário R entre conjuntos de entidades A e
B, a restrição de razão de cardinalidade
especifica
pela
aplicação,
constitui
a
sistemática utilizada para testar o Banco de
foram
implementadas
corretamente.
Segundo
Delamaro
(1993),
os
critérios de testes são utilizados pelo
testador como uma forma de assegurar que
condições que devem ser satisfeitas para
que o teste seja realizado com sucesso, ou
seja, eles estabelecem regras quanto ao que
vai ser testado no programa e quando os
testes devem parar (SPOTO et al., 1995).
CRITÉRIOS DE TESTE
Em geral o teste contribui para a
a
2006; ELMASRI e NAVATHE, 2005).
Os
critérios
identificados
para
exercitar as estruturas de relacionamentos
estão definidos a seguir:
c1: todas-as-cardinalidade-máximainter-tabela;
c2: todas-as-cardinalidade-mínimainter-tabela;
Critério Baseado nas Chaves
programa foi testado suficientemente. Os
critérios estabelecem um conjunto de
que
pode participar (SILBERSCHATZ et al.,
Dados Relacional e verificam se essas
restrições
número máximo
instância de relacionamentos das entidades
explorando as principais consultas que são
realizadas
o
As restrições de chaves possuem
duas regras fundamentais de acordo com
Elsmari e Navathe (2005), são elas a
restrição de unicidade e a integridade de
identidade.
A
restrição
de
unicidade
determina que duas tuplas distintas não
possam ter o mesmo valor para todos os
seus atributos chaves. A integridade de
identidade
determina
que
uma
chave
obtenção da qualidade do banco de dados.
primária não possa conter valores nulos
Os critérios de teste apresentados a seguir
(nulls).
foram retirados de (Souza, 2008), visando
126
Evolvere Science, V. 2, N. 1, 2013
Os
critérios
identificados
para
exercitar as estruturas de relacionamentos
garantir sua integridade especificada e
imposta em um BD relacional.
estão definidos a seguir:
Os
c3: todas-as-chaves-primária;
Critério
Baseado
na
Integridade
intra-tabela e inter-tabela. Foram definidos
dois critérios de testes:
a Integridade Referencial é classificada
entre duas relações e é usada para manter a
c5:
relações.
c6:
critérios
identificados
para
exercitar as estruturas de relacionamentos
Critério
c4:
Baseado
no
Domínio
de
Atributos
estão definidos a seguir:
Restrições de domínio segundo
todas-as-chaves-estrangeira-
inter-tabela;
Silberschatz e Korth (2006), são regras que
devem ser testadas pelo sistema, para
critérios
identificados
para
exercitar as estruturas de relacionamentos
classificados
pelos
dois
fluxos
funcionais: intra-tabela e inter-tabela. Neste
foram
tratados
apenas
Baseado
na
verificar se os tipos de domínios são
compatíveis (ou válidos), como também,
possibilitam testar consultas para assegurar
que as comparações façam sentidos.
os
relacionamentos inter-tabela.
Foram
restrições
de
definidos
dois
critérios
baseados no domínio de atributos:
Integridade
Semântica
As
todas-as-semânticas-atributos-
inter-tabela;
Os
Critério
todas-as-semânticas-atributos-
intra-tabela;
consistência entre as tuplas nas duas
trabalho
para
classificados pelos dois fluxos funcionais:
Segundo Eslmari e Navathe (2005)
estão
identificados
exercitar a integridade semântica estão
Referencial
Os
critérios
integridade
c7:
todos-os-valores-padrão;
c8:
todos-os-dominios-atributos-
intra-tabela;
semântica, segundo Mello (2003), têm
como objetivo abranger não apenas as
restrições de tipos de dados de um atributo,
METODOLOGIA
mas também, seus valores permitidos e
transições de valores válidos, de modo a
As
seguintes
foram
utilizadas para desenvolvimento do projeto
de BD:
127
etapas
Evolvere Science, V. 2, N. 1, 2013
Etapa 1: Levantamento dos requisitos e
assegurando que eles compreenderão as
especificações dos objetos de dados a
implicações do novo sistema.
serem armazenados e gerenciados pela
PM
Para um maior conhecimento acerca do
problema a ser resolvido com a implantação
Consistiu no estudo do modelo de
do software no 5º BPM, inicialmente foram
dados a ser desenvolvido em conjunto com
realizadas visitas com o objetivo de colher
os policiais do 5º Batalhão da Polícia
informações sobre o local, fichas de
Militar (5º BPM). O levantamento de
cadastros, funcionamento dos processos e
requisitos englobou todas as tarefas que
perfil dos usuários. Essas informações
lidam com investigação, definição e escopo
foram colhidas por meio de entrevistas,
de novos sistemas ou alterações. Nessa
observação participante, questionários e
etapa
anotações.
foi
possível
identificar
as
necessidades do 5º BPM. Uma vez que os
requisitos do sistema foram identificados,
os desenvolvedores do sistema começaram
a fase de modelagem do sistema.
atividades:
dos computadores já existentes no local.
equipe
de
preparações
Elicitação de requisitos: é a tarefa de
comunicar-se com os usuários para
determinar quais são as necessidades.
•
colhidas informações sobre a configuração
Essas informações foram analisadas pela
Essa etapa incluiu dois tipos de
•
Durante as visitas também foram
projeto
para
para
as
devidas
implementação
do
software.
Etapa 3: Elaboração dos Diagramas de
Entidade e Relacionamento
Inicialmente
Análise de requisitos: nessa atividade
foram
levantados
foi verificado se o estado dos requisitos
todos os objetos de dados que foram
é obscuro, incompleto, ambíguo, ou
listados
contraditório.
foi
requisitos, em seguida foram construídas as
realizada durante as revisões que
tabelas e seus respectivos atributos e tipos
aconteciam
de dados de forma a atender o domínio da
Essa
atividade
semanalmente
com
os
Partindo-se do pressuposto de que
novos sistemas mudam o ambiente e a
relação entre as pessoas, então é importante
identificar todos os envolvidos, levando em
128
todas
as
suas
necessidades
etapa
da
engenharia
de
informação a ser manipulada neste projeto.
membros do grupo de pesquisa.
conta
na
e
Para a construção desta etapa foi utilizado
softwares abertos e o SGBD PostgreSQL
(também gratuito).
Evolvere Science, V. 2, N. 1, 2013
Etapa 4: Implementação do projeto
de dados (conceitual, lógica e física). Para a
Físico e Implementação do Banco de
modelagem conceitual dos dados foi feita a
Dados
análise de requisitos e a representação do
Foram criados os relacionamentos e
controles de avaliação dos atributos. Foram
feitas, também, adaptações dos objetos de
dados para atenderem ao propósito deste
projeto de acordo com os formulários que
modelo através do DER. A partir da
modelagem conceitual foram realizadas as
modelagens lógica e física adicionando os
devidos detalhes de implementação nos
respectivos modelos.
serão utilizados para a manipulação dos
A partir do modelo conceitual é
dados. Implementação do Banco de Dados
possível, então, fazer a modelagem lógica
no
do sistema, que consiste em normalizar as
SGBD
PostgreSQL
em
ambiente
cliente/servidor.
tabelas, determinar o nome dos atributos e
Etapa 5: Definições de um plano de teste
e Execução dos casos de testes funcionais
no banco de dados
Nesta etapa foram colhidas algumas
dezenas de informações reais utilizadas
para testar e avaliar as características de
integridade referencial, semântica, chaves,
domínio, multiplicidade e de tabela criando
entidades abreviados quando necessário e
contemplar a cada atributo o seu tipo de
dado, o tamanho e determinar as restrições
de unicidade, integridade de identidade e
verificar quais atributos possuem valor
padrão. A partir dos modelos conceitual e
lógico é possível confeccionar o DER
(Figura 4).
assim as devidas correções detectadas.
Nesta etapa foi gerado um plano de testes
com o qual foi possível extrair os casos de
testes.
Etapa
6:
Avaliação
dos
resultados
obtidos e correções dos erros detectados
Após a etapa de teste, foram
corrigidos os erros detectados, bem como as
regras de verificação.
RESULTADOS
Após o levantamento de
requisitos através das visitas ao 5ºBPM,
iniciou-se a etapa de modelagem do banco
129
Figura 4 – DER do Sistema da PM
Foram criados um plano de teste e
tabelas de execução dos casos de teste para
que as funcionalidades fossem postas a
prova. O plano de teste foi elaborado
conforme as orientações presentes no
Evolvere Science, V. 2, N. 1, 2013
padrão 829 do Instituto dos Engenheiros
foram prescritas a extensão, aproximação
Eletricistas e Eletrônicos (IEEE), em que
recursos e o horário de todas as atividades
Figura 5 – Exemplo de Estratégia de Teste para o Critério Funcional Baseado no Domínio de
Atributos
de teste. Na figura 5 há um exemplo de
dados deve estar protegido caso ocorra uma
estratégia de teste contida no documento de
entrada em que o CEP possua menos ou
testes.
mais de 8 números.
Nesse
exemplo,
os
elementos
requeridos definem como classe válida de
valores para altura que o dado inserido no
CONCLUSÃO
banco que não seja nulo (not null) e que a
Ao fim da primeira fase de testes,
altura esteja entre 100 cm e 300 cm,
quando a primeira versão do banco ficou
garantindo que os valores atendam a
pronta¸ foi constatado que eram necessário
semântica e reflitam o mundo real. O banco
realizar uma nova visita ao Batalhão da PM
deve estar preparado para rejeitar valores
para que fossem esclarecidos alguns dos
nulos para a altura e/ou que tenha altura
requisitos.
Feitas as entrevistas, o banco foi
menor que 100 cm ou maior que 300 cm.
Na figura 6, pode ser observado um
modificado e uma nova fase de testes foi
exemplo de parte da execução do teste, que
realizada. A figura 6 possibilita uma melhor
integra parte do documento Casos de Testes
visualização dos resultados obtidos ao
e
término da fase de testes da última versão
Execução,
confeccionado
após
a
finalização do plano de testes. Nela é
apresentada uma parte da execução dos
do BD.
A
metodologia
utilizada
para
o
testes, nos quais foram encontrados três
desenvolvimento do BD é importante para a
erros.
é
garantia da qualidade do sistema. O ciclo
ter
percorrido (plano de testes, execução dos
exatamente 8 números. Logo, o banco de
testes, correções) ao implementar o banco é
Nos
especificado
130
requisitos
que
o
levantados
CEP
deve
Evolvere Science, V. 2, N. 1, 2013
primordial para se atender ao máximo os
alterações foram realizadas para atender os
requisitos dos usuários. Após cada etapa de
novos requisitos identificados.
correções novas entrevistas foram feitas e
Figura 6 – Exemplo de parte da execução dos testes
Verificou-se, por exemplo, durante
apenas permitia a inserção de 8 dígitos.
a execução dos testes do sistema que foi
Esse defeito foi corrigido através da
possível inserir o mesmo curso diversas
alteração da cláusula check que foi
vezes para o mesmo policial (viola a
implementada incorretamente.
cardinalidade das tabelas policial e curso).
A seguir é apresentado o trecho incorreto
O defeito pôde ser corrigido colocando a
do código:
restrição de unicidade para o atributo
policial_id na tabela policial_curso.
CONSTRAINT policial_telefone_check
CHECK((telefone>10000000)AND(telefon
e<99999999))
Que após a correção ficou dessa maneira:
CONSTRAINT
policial_telefone_check
CHECK
Figura 7 – Dados estatísticos da atividade de
testes do Sistema COPOM
Outro exemplo de defeito encontrado foi
o erro apresentado no cadastro do telefone
que deveria possuir 10 dígitos e o banco
131
((telefone>1000000000)AND(telefone<999
9999999))
Evolvere Science, V. 2, N. 1, 2013
Além desses, outros defeitos foram
A detecção dos defeitos tem um
encontrados na base de dados e em seguida
objetivo construtivo e garante a melhora na
foram corrigidos. A qualidade do banco de
qualidade do software produzido para o 5º
dados neste caso foi incrementada e apesar
BPM. Como trabalhos futuros o teste
da atividade de testes não garantir que o
funcional e a metodologia utilizada para
sistema está livre de defeitos, o banco de
desenvolver o BD poderia ser usada em um
dados se encontra mais seguro.
Banco
de
Dados
Objeto-Relacional,
contudo seria necessária a identificação de
CONCLUSÃO
novos critérios de testes e ajustes na
Neste trabalho foi proposta a construção
sistemática devido ao paradigma OO.
e avaliação de um banco de dados para a
Todo esforço concentrado ao testar o
segurança pública de Petrolina, utilizando
Banco de Dados na etapa de construção é
um SGBD gratuito, o PostgreSQL, a fim de
fundamental para a correção de várias
criar materiais para o uso desses códigos
restrições não levantadas anteriormente,
abertos e tornar seu uso praticável nos
nem nas revisões formais e nem nas
meios públicos. Tendo isso em vista, a
reuniões entre os desenvolvedores. A partir
implementação do BD foi realizada usando
das etapas de testes os critérios alinham as
ferramentas gratuitas como o PgAdmin
divergências existentes e colocam uma série
[www.pgadmin.org,
Astha
de defeitos que persistiram ao longo do
e
desenvolvimento, bem como orientam a
2010],
[astah.change-vision.com,
o
2010]
o
DbWrench [www.dbwrench.com, 2010].
equipe de implementação do sistema a
Para garantir a qualidade do banco de
corrigir várias ações visando atender as
dados foi realizado um ciclo de testes
principais restrições existentes em um
funcionais que começa com a confecção do
banco de dados Relacional.
plano de testes, seguida da execução dos
testes e as correções dos defeitos da etapa
REFERÊNCIAS
de projeto. A partir das restrições do
modelo relacional foram definidos os
P. AMMANN AND A. J. OUTT. Using
critérios e estratégias. Os casos de testes
Formal Methods to Derive Test Frames
foram
para
in Category-partition Testing. Proc. of the
proporcionar uma forma sistemática de
9th Annual Conference on Computer
execução dos testes. Os casos de testes
Assurance (COMPASS 94), pages 69-80,
executados
Gaithersburg, MD, June 1994.
extraídos
neste
em
seguida
exemplo
detectaram
vários tipos de defeitos que poderiam ter
interferido em outras etapas de testes da
ASTAH.
aplicação posteriormente.
www.astah.change-vision.com, 2010.
132
Disponível
em
Evolvere Science, V. 2, N. 1, 2013
IEEE.
IEEE
Standard
of
CHAYS, D; DAN, S; FRANKL, P. G;
Software
VOKOLOS, F. I; WEYUKER, E. J. A
Standard 829, IEEE Computer Society
Framework
Press, 1990.
for
Testing
Database
Engineering
Glossary
Terminology.
Applications. In: 2000 ACM SIGSOFT
International
Symposium
Software
MACHADO, F. N. R; ABREU, M. P.
Testing and Analysis – ISSTA, 2000,
Projeto de Banco de Dados: uma visão
Portland, Proceedings. Portland, 2000. ]
prática. 11ª Ed. São Paulo: Érica, 1996.
DBWRENCH.
on
Disponível
em
www.dbwrench.com, 2010.
MALDONADO, J. C., DELAMARO, M.
E., FABBRI, S. C. P. F., SIMÃO, A. S.,
SUGETA, T., VINCEZI, A. M. R., and
DELAMARO,
Márcio
Eduardo;
MASIERO, P. C. � 2000). Proteum: A
MALDONADO, José Carlos; JINO, Mário.
family of tools to support specification
Introdução ao Teste de Software. Rio de
and program testing based on mutation.
Janeiro: Elsevier, 2007.
In Mutation 2000 Symposium – Tool
Session, pages 113–116, San Jose, CA.
DELAMARO, M. E. Proteum – Um
Kluwer Academic Publishers.
Ambiente de Teste Baseado na Análise
de Mutantes. 1993. 113 f. Dissertação
MACHADO, F.N.R., ABREU, M. Projeto
(Mestrado em Ciências de Computação e
de Banco de Dados: uma visão prática.
Matemática Computacional) – Instituto de
São Paulo: Érica, 2004.
Ciências Matemáticas e de Computação de
São Carlos – ICMC/USP, São Carlos, 1993.
MYERS, G,J. The art of software testing.
J. Giley, 1979.
ELSMARI, R; NAVATHE, S. B. Sistemas
de Banco de Dados. 4ª ed. São Paulo:
MELLO, R. S. Gerenciamento de Dados
Pearson Addison, 2005.
XML. In: Escola de Informática Norte da
SBC –ENCOINFO/EIN, 5, 2003, Palmas.
HARTMAN,
A.
Is
ISSTA
research
Anais...
Palmas:
Centro
Universitário
relevant to industry? Int.Symposium on
Luterano de Palmas – ULBRA, 2003, 20p.
Software Testing and Analysis, Industry
p.15-34.
panel.
ACM
SIGSOFT
Engineering Notes. 2002.
133
Software
Evolvere Science, V. 2, N. 1, 2013
J. RUMBAUGH, I. Jacobson e G. Booch.
Dados Relacional. 2000. 204 f. Tese
UML Reference Manual, Third Edition.
(Doutorado em Engenharia Elétrica) -
Addison Wesley Longman, 2004.
Faculdade de Engenharia Elétrica e de
Computação da Universidade Estadual de
RAMOS, R.A. Treinamento Prático em
Campinas - FEEC/UNICAMP, Campinas,
UML. Digerati Books, São Paulo 2006.
2000.
SILBERSCHATZ, A; KORTH, H. F;
PGADMIN.
SUDARSHAN, S. Sistema de Banco de
www.pgadmin.org, 2010.
Dados. 5ª ed. Rio de Janeiro: Elsevier,
2006.
SOMMERVILLE,
I.
Engenharia
de
Software. 6º ed. São Paulo: Pearson
Addison Wesley, 2003.
SOUZA, J. P. Teste Funcional em
Aplicação de Banco de Dados Baseado
nos Diagramas da UML. 2008. 149f.
Dissertação (Mestrado em Ciência da
Computação)
–
Centro
Universitário
Eurípides de Marília. Fundação de Ensino
Eurípides Soares da Rocha, Marília, 2008.
SPOTO, E. S; PERES, L. M; BUENO, P.
M. Um Estudo de Critérios de Teste de
Software Baseados Em Fluxo de Dados.
1995. 102 f. Trabalho de Conclusão de
Disciplina (Tópicos de Engenharia da
Computação II) - Faculdade de Engenharia
Elétrica e de Computação da Universidade
Estadual de Campinas - FEEC/UNICAMP,
Campinas, 1995.
SPOTO, E. S. Teste Estrutural de
Programas de Aplicação de Banco de
134
Disponível
em