120
Evolvere ScientiaUNIVERSIDADE FEDERAL DO VALE DO SÃO FRANCISCO
Evolvere ScientiaUNIVERSIDADE 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.
[email protected], [email protected], [email protected],
[email protected] , [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
Evolvere Scientia, V. 2, N. 1, 2013
ARTIGO
Evolvere Science, V. 2, N. 1, 2013
121
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
De acordo com Elmasri e Navathe
(2005), um Banco de Dados (BD) é um
conjunto de dados relacionados que são
fatos que podem ser gravados e possuem
um significado implícito. Segundo o
mesmo autor, os BDs relacionais foram
criados para separar o armazenamento
físico dos dados de sua representação
conceitual e provê uma fundamentação
matemática para os bancos de dados. O uso
de BD relacionais nos mais variados setores
possibilitou a organização, segurança e
persistência de informações essenciais para
inúmeras atividades. As instituições
públicas, por exemplo, podem garantir,
fazendo uso de um Banco de Dados bem
construídos, uma melhor eficiência e
eficácia no desenvolvimento de suas
atividades. Para desenvolver um banco de
dados de qualidade, segundo alguns autores
como Silberchatz et al. (2006), e Elmasri e
Navathe (2005), devem ser seguidas as
seguintes etapas: etapas de requisitos,
projeto lógico e físico e finalizar com testes
de verificação das principais características
do BD.
Um dos principais objetivos da
atividade de teste de software e de banco de
dados é garantir que o sistema funcione
corretamente e atenda as especificações dos
usuários, porém é considerado o processo
mais caro no desenvolvimento de software
chegando a consumir mais de 30% dos
recursos necessários para este fim segundo
Hartman (2002). Chays (2000) comenta que
existem vários aspectos que indicam se o
sistema está funcionando corretamente,
como, por exemplo, o comportamento da
aplicação, se o esquema do banco de dados
reflete o mundo real, fatores como
segurança e privacidade estão protegidos de
forma correta e se o Sistema Gerenciador
de Banco de Dados (SGBD) realiza todas as
operações corretamente.
Um sistema de segurança pública,
por exemplo, envolve todas as áreas de
atendimento e gerência para tomadas de
decisão visando tornar o atendimento ágil,
controlar as ações, criar estratégias de
prevenção, construir relatos de execução e
poder gerenciar de forma rápida e segura
todos os materiais e mão de obras
envolvidas no atendimento. Levando esse
fato em consideração, o objetivo deste
Evolvere Science, V. 2, N. 1, 2013
122
trabalho foi a construção de um Banco de
Dados com qualidade para atender o setor
de segurança pública em Petrolina. Devido
às necessidades da Polícia Militar (PM) foi
implementado, inicialmente, um banco de
dados para armazenar as informações do
Boletim Interno (BI) e cadastrar as
informações pertinentes a todos os policiais
do 5º Batalhão. Para isso serão utilizados os
diagramas da Unified Modeling Language
(UML) e a técnica de teste funcional
baseada nas características do projeto de
banco de dados. É essencial para o setor de
Recursos Humanos (RH) da PM armazenar
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
geral do comportamento de cada ator dentro
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
eles: casos de uso, atividades e classes. Os
diagramas de casos de uso são visões que
modelam as funcionalidades do sistema
observadas pelos usuários de fora,
chamados atores. Um caso de uso é uma
unidade coerente de funcionalidade
expressada como uma transação entre
atores e o sistema, de acordo com
Rumbaugh (2004). O propósito do
diagrama de caso de uso é listar os atores e
casos de uso e mostrar qual ator participa
em cada caso de uso. Na Figura 1 é
apresentado o diagrama de casos de uso
modelado para o sistema da PM.
Figura 1 – Diagrama de Casos de Uso do
Sistema da PM
Segundo Rumbaugh (2004), o
diagrama de atividades descreve o
comportamento paralelo e procedural do
sistema. Uma atividade corresponde a um
conjunto de ações que devem ser
organizadas de acordo com as
responsabilidades, como descrito em
Ramos (2006). Na Figura 2, é possível
Evolvere Science, V. 2, N. 1, 2013
123
observar como os atores agem em cada caso
de uso (cada caso de uso possui um
diagrama de atividades) para que
determinada atividade possa ser realizada,
como, por exemplo, o cadastro de um
policial.
Figura 2 – Diagrama de Atividades do
sistema da PM .
Um diagrama de classe (Rumbaugh,
2004) é uma apresentação gráfica da visão
estática que mostra uma coleção de
elementos de modelo informativo (estático),
como, por exemplo, classes, tipos, e seus
conteúdos e relacionamentos. Na Figura 3 é
apresentado o diagrama de classes
confeccionado para o sistema da PM.
BANCO DE DADOS RELACIONAL
Um banco de dados é um conjunto
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:
modelagem conceitual, lógica e física dos
dados.
Figura 3 – Diagrama de Classes do Sistema
da PM
A criação de um projeto conceitual
é indispensável, para em seguida montar
um esquema conceitual dos dados. Essa
etapa independe do SGBD e o maior
propósito é tentar entender o mini-mundo.
O modelo conceitual proporciona uma
visão global dos principais dados e
relacionamentos do sistema, independente
de como serão implementados. O resultado
dessa fase do projeto é um esquema que
representa a realidade das informações
existentes.
A próxima etapa, o projeto lógico,
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
124
Finalmente, a partir do modelo
lógico, é criado o modelo físico onde são
descritas as estruturas físicas de
armazenamento de dados, como por
exemplo, o tamanho dos campos, os índices
e o tipo de preenchimento dos campos.
O banco de dados relacional possui
algumas características importantes como
as chaves, o domínio dos valores e as
restrições que compõem o modelo
relacional. As chaves permitem o
estabelecimento das relações entre linhas e
tabelas. Existem três tipos de chave: a
chave primária, a chave alternativa e a
chave estrangeira. O domínio dos valores
de um campo é o conjunto de valores
especificados para aquele campo, por
exemplo, o campo CPF da tabela policial da
base de dados da PM não pode conter
valores nulos e deve possuir onze caracteres
que são validados de acordo com um
algoritmo de validação do CPF.
Existem muitas limitações ou restrições
para os valores reais em um estado do
banco de dados (Elmasri e Navathe, 2005).
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:
• Em um conjunto de relacionamento
binário R entre conjuntos de entidades
A e B, a restrição de razão de
cardinalidade especifica o número
máximo que a instância de
relacionamentos das entidades pode
participar (Silberschatz e Korth., 2006;
Elmasri e Navathe, 2005).
Ex.: No BD da PM existem várias
tabelas, dentre elas: Policial, Punição e
Posto. Cada policial pode ter nenhuma
ou várias punições (notação: 1:N). Já
com relação às tabelas posto e policial,
cada policial só pode ter apenas um
posto (notação: 1:1).
• As restrições de chaves possuem duas
regras fundamentais de acordo com
Elmasri 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
primária não possa conter valores nulos
(nulls). Ex.: O código do policial (id)
deve ser único e não nulo.
• 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-
se referir a uma tupla existente nessa
relação. Ex.: Ao tentarmos inserir em
Evolvere Science, V. 2, N. 1, 2013
125
um policial um posto que não esteja
cadastrado, o banco de dados deve
rejeitar essa inserção.
• As restrições de integridade semântica,
segundo Mello (2003), têm como
objetivo abranger não apenas as
restrições de tipos de dados de um
atributo, mas também, seus valores
permitidos e transições de valores
válidos, de modo a garantir sua
integridade especificada e imposta em
um BD relacional. Ex.: Ao ser
cadastrado um novo policial a altura
dele deve estar entre 100 cm e 300 cm
(não existem policiais com menos de 1
metro nem com mais de 3 metros).
• Segundo Elmasri e Navathe (2005), a
Dependência Funcional (DF) é uma
restrição entre dois conjuntos de
atributos do BD. Representa-se por
X→Y, no qual X e Y são conjuntos de
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, X determinam
funcionalmente os valores de Y
(Machado e Abreu, 1996; Elmasri e
Navathe, 2005). Ex.: CPF→Nome, ou
seja, o CPF do policial determina
funcionalmente o nome do policial.
• Restrições de Domínio, segundo
Silberschatz e Korth (2006), são regras
que devem ser testadas pelo sistema,
para 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 sentido. Ex.: O CPF do policial
deve ser não nulo, e possuir exatamente
onze caracteres.
TESTE DE FUNCIONAL
Segundo Myers (1979), o teste de
programas consiste em exercitar o
programa através de dados de entrada
(dados de teste) e comparar os valores de
saída produzidos (resultado computacional)
com o resultado esperado (definido pelas
especificações do programa). O objetivo do
teste é encontrar defeitos existentes no
programa e é um método muito difundido,
embora imperfeito, de garantia de qualidade
de software (AMMANN e OUTT, 1994).
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).
A técnica de teste funcional é
também conhecida por técnica de teste
caixa preta, por não utilizar o código fonte e
sim extrair os requisitos de testes a partir da
especificação. Neste trabalho, a técnica
funcional foi aplicada no projeto de banco
Evolvere Science, V. 2, N. 1, 2013
126
de dados, extraindo os elementos de testes
do 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),
explorando as principais consultas que são
realizadas pela aplicação, constitui a
sistemática utilizada para testar o Banco de
Dados Relacional e verificam se essas
restrições foram implementadas
corretamente.
Segundo Delamaro (1993), os
critérios de testes são utilizados pelo
testador como uma forma de assegurar que
programa foi testado suficientemente. Os
critérios estabelecem um conjunto de
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
obtenção da qualidade do banco de dados.
Os critérios de teste apresentados a seguir
foram retirados de (Souza, 2008), visando
praticar na base de dados desenvolvida os
requisitos levantados durante a etapa de
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 o número máximo que a
instância de relacionamentos das entidades
pode participar (SILBERSCHATZ et al.,
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áxima-
inter-tabela;
c2: todas-as-cardinalidade-mínima-
inter-tabela;
Critério Baseado nas Chaves
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
primária não possa conter valores nulos
(nulls).
Evolvere Science, V. 2, N. 1, 2013
127
Os critérios identificados para
exercitar as estruturas de relacionamentos
estão definidos a seguir:
c3: todas-as-chaves-primária;
Critério Baseado na Integridade
Referencial
Segundo Eslmari 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.
Os critérios identificados para
exercitar as estruturas de relacionamentos
estão definidos a seguir:
c4: todas-as-chaves-estrangeira-
inter-tabela;
Os critérios identificados para
exercitar as estruturas de relacionamentos
estão classificados pelos dois fluxos
funcionais: intra-tabela e inter-tabela. Neste
trabalho foram tratados apenas os
relacionamentos inter-tabela.
Critério Baseado na Integridade
Semântica
As restrições de integridade
semântica, segundo Mello (2003), têm
como objetivo abranger não apenas as
restrições de tipos de dados de um atributo,
mas também, seus valores permitidos e
transições de valores válidos, de modo a
garantir sua integridade especificada e
imposta em um BD relacional.
Os critérios identificados para
exercitar a integridade semântica estão
classificados pelos dois fluxos funcionais:
intra-tabela e inter-tabela. Foram definidos
dois critérios de testes:
c5: todas-as-semânticas-atributos-
intra-tabela;
c6: todas-as-semânticas-atributos-
inter-tabela;
Critério Baseado no Domínio de
Atributos
Restrições de domínio segundo
Silberschatz e Korth (2006), são regras que
devem ser testadas pelo sistema, para
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.
Foram definidos dois critérios
baseados no domínio de atributos:
c7: todos-os-valores-padrão;
c8: todos-os-dominios-atributos-
intra-tabela;
METODOLOGIA
As etapas seguintes foram
utilizadas para desenvolvimento do projeto
de BD:
Evolvere Science, V. 2, N. 1, 2013
128
Etapa 1: Levantamento dos requisitos e
especificações dos objetos de dados a
serem armazenados e gerenciados pela
PM
Consistiu no estudo do modelo de
dados a ser desenvolvido em conjunto com
os policiais do 5º Batalhão da Polícia
Militar (5º BPM). O levantamento de
requisitos englobou todas as tarefas que
lidam com investigação, definição e escopo
de novos sistemas ou alterações. Nessa
etapa 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.
Essa etapa incluiu dois tipos de
atividades:
• Elicitação de requisitos: é a tarefa de
comunicar-se com os usuários para
determinar quais são as necessidades.
• Análise de requisitos: nessa atividade
foi verificado se o estado dos requisitos
é obscuro, incompleto, ambíguo, ou
contraditório. Essa atividade foi
realizada durante as revisões que
aconteciam semanalmente com os
membros do grupo de pesquisa.
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
conta todas as suas necessidades e
assegurando que eles compreenderão as
implicações do novo sistema.
Para um maior conhecimento acerca do
problema a ser resolvido com a implantação
do software no 5º BPM, inicialmente foram
realizadas visitas com o objetivo de colher
informações sobre o local, fichas de
cadastros, funcionamento dos processos e
perfil dos usuários. Essas informações
foram colhidas por meio de entrevistas,
observação participante, questionários e
anotações.
Durante as visitas também foram
colhidas informações sobre a configuração
dos computadores já existentes no local.
Essas informações foram analisadas pela
equipe de projeto para as devidas
preparações para implementação do
software.
Etapa 3: Elaboração dos Diagramas de Entidade e Relacionamento
Inicialmente foram levantados
todos os objetos de dados que foram
listados na etapa da engenharia de
requisitos, em seguida foram construídas as
tabelas e seus respectivos atributos e tipos
de dados de forma a atender o domínio da
informação a ser manipulada neste projeto.
Para a construção desta etapa foi utilizado
softwares abertos e o SGBD PostgreSQL
(também gratuito).
Evolvere Science, V. 2, N. 1, 2013
129
Etapa 4: Implementação do projeto
Físico e Implementação do Banco de
Dados
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
serão utilizados para a manipulação dos
dados. Implementação do Banco de Dados
no SGBD PostgreSQL em ambiente
cliente/servidor.
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
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
de dados (conceitual, lógica e física). Para a
modelagem conceitual dos dados foi feita a
análise de requisitos e a representação do
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.
A partir do modelo conceitual é
possível, então, fazer a modelagem lógica
do sistema, que consiste em normalizar as
tabelas, determinar o nome dos atributos e
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).
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
130
padrão 829 do Instituto dos Engenheiros
Eletricistas e Eletrônicos (IEEE), em que
foram prescritas a extensão, aproximação
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
estratégia de teste contida no documento de
testes. Nesse exemplo, os elementos
requeridos definem como classe válida de
valores para altura que o dado inserido no
banco que não seja nulo (not null) e que a
altura esteja entre 100 cm e 300 cm,
garantindo que os valores atendam a
semântica e reflitam o mundo real. O banco
deve estar preparado para rejeitar valores
nulos para a altura e/ou que tenha altura
menor que 100 cm ou maior que 300 cm.
Na figura 6, pode ser observado um
exemplo de parte da execução do teste, que
integra parte do documento Casos de Testes
e Execução, confeccionado após a
finalização do plano de testes. Nela é
apresentada uma parte da execução dos
testes, nos quais foram encontrados três
erros. Nos requisitos levantados é
especificado que o CEP deve ter
exatamente 8 números. Logo, o banco de
dados deve estar protegido caso ocorra uma
entrada em que o CEP possua menos ou
mais de 8 números.
CONCLUSÃO
Ao fim da primeira fase de testes,
quando a primeira versão do banco ficou
pronta ̧ foi constatado que eram necessário
realizar uma nova visita ao Batalhão da PM
para que fossem esclarecidos alguns dos
requisitos.
Feitas as entrevistas, o banco foi
modificado e uma nova fase de testes foi
realizada. A figura 6 possibilita uma melhor
visualização dos resultados obtidos ao
término da fase de testes da última versão
do BD.
A metodologia utilizada para o
desenvolvimento do BD é importante para a
garantia da qualidade do sistema. O ciclo
percorrido (plano de testes, execução dos
testes, correções) ao implementar o banco é
Evolvere Science, V. 2, N. 1, 2013
131
primordial para se atender ao máximo os
requisitos dos usuários. Após cada etapa de
correções novas entrevistas foram feitas e
alterações foram realizadas para atender os
novos requisitos identificados.
Figura 6 – Exemplo de parte da execução dos testes
Verificou-se, por exemplo, durante
a execução dos testes do sistema que foi
possível inserir o mesmo curso diversas
vezes para o mesmo policial (viola a
cardinalidade das tabelas policial e curso).
O defeito pôde ser corrigido colocando a
restrição de unicidade para o atributo
policial_id na tabela policial_curso.
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
apenas permitia a inserção de 8 dígitos.
Esse defeito foi corrigido através da
alteração da cláusula check que foi
implementada incorretamente.
A seguir é apresentado o trecho incorreto
do código:
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
((telefone>1000000000)AND(telefone<999
9999999))
Evolvere Science, V. 2, N. 1, 2013
132
Além desses, outros defeitos foram
encontrados na base de dados e em seguida
foram corrigidos. A qualidade do banco de
dados neste caso foi incrementada e apesar
da atividade de testes não garantir que o
sistema está livre de defeitos, o banco de
dados se encontra mais seguro.
CONCLUSÃO
Neste trabalho foi proposta a construção
e avaliação de um banco de dados para a
segurança pública de Petrolina, utilizando
um SGBD gratuito, o PostgreSQL, a fim de
criar materiais para o uso desses códigos
abertos e tornar seu uso praticável nos
meios públicos. Tendo isso em vista, a
implementação do BD foi realizada usando
ferramentas gratuitas como o PgAdmin
[www.pgadmin.org, 2010], o Astha
[astah.change-vision.com, 2010] e o
DbWrench [www.dbwrench.com, 2010].
Para garantir a qualidade do banco de
dados foi realizado um ciclo de testes
funcionais que começa com a confecção do
plano de testes, seguida da execução dos
testes e as correções dos defeitos da etapa
de projeto. A partir das restrições do
modelo relacional foram definidos os
critérios e estratégias. Os casos de testes
foram extraídos em seguida para
proporcionar uma forma sistemática de
execução dos testes. Os casos de testes
executados neste exemplo detectaram
vários tipos de defeitos que poderiam ter
interferido em outras etapas de testes da
aplicação posteriormente.
A detecção dos defeitos tem um
objetivo construtivo e garante a melhora na
qualidade do software produzido para o 5º
BPM. Como trabalhos futuros o teste
funcional e a metodologia utilizada para
desenvolver o BD poderia ser usada em um
Banco de Dados Objeto-Relacional,
contudo seria necessária a identificação de
novos critérios de testes e ajustes na
sistemática devido ao paradigma OO.
Todo esforço concentrado ao testar o
Banco de Dados na etapa de construção é
fundamental para a correção de várias
restrições não levantadas anteriormente,
nem nas revisões formais e nem nas
reuniões entre os desenvolvedores. A partir
das etapas de testes os critérios alinham as
divergências existentes e colocam uma série
de defeitos que persistiram ao longo do
desenvolvimento, bem como orientam a
equipe de implementação do sistema a
corrigir várias ações visando atender as
principais restrições existentes em um
banco de dados Relacional.
REFERÊNCIAS
P. AMMANN AND A. J. OUTT. Using
Formal Methods to Derive Test Frames
in Category-partition Testing. Proc. of the
9th Annual Conference on Computer
Assurance (COMPASS 94), pages 69-80,
Gaithersburg, MD, June 1994.
ASTAH. Disponível em
www.astah.change-vision.com, 2010.
Evolvere Science, V. 2, N. 1, 2013
133
CHAYS, D; DAN, S; FRANKL, P. G;
VOKOLOS, F. I; WEYUKER, E. J. A
Framework for Testing Database
Applications. In: 2000 ACM SIGSOFT
International Symposium on Software
Testing and Analysis – ISSTA, 2000,
Portland, Proceedings. Portland, 2000. ]
DBWRENCH. Disponível em
www.dbwrench.com, 2010.
DELAMARO, Márcio Eduardo;
MALDONADO, José Carlos; JINO, Mário.
Introdução ao Teste de Software. Rio de
Janeiro: Elsevier, 2007.
DELAMARO, M. E. Proteum – Um
Ambiente de Teste Baseado na Análise
de Mutantes. 1993. 113 f. Dissertação
(Mestrado em Ciências de Computação e
Matemática Computacional) – Instituto de
Ciências Matemáticas e de Computação de
São Carlos – ICMC/USP, São Carlos, 1993.
ELSMARI, R; NAVATHE, S. B. Sistemas
de Banco de Dados. 4ª ed. São Paulo:
Pearson Addison, 2005.
HARTMAN, A. Is ISSTA research
relevant to industry? Int.Symposium on
Software Testing and Analysis, Industry
panel. ACM SIGSOFT Software
Engineering Notes. 2002.
IEEE. IEEE Standard Glossary of
Software Engineering Terminology.
Standard 829, IEEE Computer Society
Press, 1990.
MACHADO, F. N. R; ABREU, M. P.
Projeto de Banco de Dados: uma visão
prática. 11ª Ed. São Paulo: Érica, 1996.
MALDONADO, J. C., DELAMARO, M.
E., FABBRI, S. C. P. F., SIMÃO, A. S.,
SUGETA, T., VINCEZI, A. M. R., and
MASIERO, P. C. � 2000). Proteum: A
family of tools to support specification
and program testing based on mutation.
In Mutation 2000 Symposium – Tool
Session, pages 113–116, San Jose, CA.
Kluwer Academic Publishers.
MACHADO, F.N.R., ABREU, M. Projeto
de Banco de Dados: uma visão prática.
São Paulo: Érica, 2004.
MYERS, G,J. The art of software testing.
J. Giley, 1979.
MELLO, R. S. Gerenciamento de Dados
XML. In: Escola de Informática Norte da
SBC –ENCOINFO/EIN, 5, 2003, Palmas.
Anais... Palmas: Centro Universitário
Luterano de Palmas – ULBRA, 2003, 20p.
p.15-34.
Evolvere Science, V. 2, N. 1, 2013
134
J. RUMBAUGH, I. Jacobson e G. Booch.
UML Reference Manual, Third Edition.
Addison Wesley Longman, 2004.
RAMOS, R.A. Treinamento Prático em
UML. Digerati Books, São Paulo 2006.
SILBERSCHATZ, A; KORTH, H. F;
SUDARSHAN, S. Sistema de Banco de
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
Dados Relacional. 2000. 204 f. Tese
(Doutorado em Engenharia Elétrica) -
Faculdade de Engenharia Elétrica e de
Computação da Universidade Estadual de
Campinas - FEEC/UNICAMP, Campinas,
2000.
PGADMIN. Disponível em
www.pgadmin.org, 2010.
Top Related