Universidade Federal do Vale do São Francisco, 48902-300 ...banco de dados (Elmasri e Navathe,...

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


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


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.


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


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


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).


127




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.




c4: todas-as-chaves-estrangeira-

inter-tabela;



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.


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:


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).


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


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 é


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))


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.


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.


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.

Universidade Federal do Vale do São Francisco, 48902-300 ...banco de dados (Elmasri e Navathe,...

Documents

Transcript of Universidade Federal do Vale do São Francisco, 48902-300 ...banco de dados (Elmasri e Navathe,...