ELABORAÇÃO DE UM SOFTWARE PARA ESTIMAR A PROPAGAÇÃO DE UM ...cristina/SoftwareQuimica.pdf · ilimitado. Porém, essa realidade já é bem diferente. A Lei 9.433 instituiu que

UNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁPR

UNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁ

CAMPUS CURITIBA

DEPARTAMENTO ACADÊMICO DE INFORMÁTICA

DEPARTAMENTO ACADÊMICO DE QUÍMICA E BIOLOGIA

TECNOLOGIA EM INFORMÁTICA

TECNOLOGIA EM QUÍMICA AMBIENTAL

FABIO BATISTA

FERNANDA DAMACENO TAVARES

ELABORAÇÃO DE UM SOFTWARE PARA ESTIMAR

A PROPAGAÇÃO DE UM CONTAMINANTE NO SOLO

CURITIBA

DEZEMBRO - 2008

FABIO BATISTA


ELABORAÇÃO DE UM SOFTWARE PARA ESTIMAR

A PROPAGAÇÃO DE UM CONTAMINANTE NO SOLO

Trabalho de Conclusão de Curso apresentado

como requisito à obtenção do título de

Graduação em Tecnologia em Informática e em

Tecnologia em Química Ambiental, do

Departamento Acadêmico de Informática e do

Departamento Acadêmico de Química e

Biologia do Campus Curitiba, da UTFPR.

Orientadora:

Profª. Ana Cristina Barreiras Kochem

Vendramin, MSc.

Co-orientadora:

Profª. Valma Martins Barbosa, Drª.

CURITIBA

DEZEMBRO - 2008

TERMO DE APROVAÇÃO

FABIO BATISTA


TÍTULO DO TRABALHO

ELABORAÇÃO DE UM SOFTWARE PARA ESTIMAR A PROPAGAÇÃO DE UM

CONTAMINANTE NO SOLO

Trabalho de Conclusão de Curso aprovado como requisito parcial à obtenção do grau de

TECNÓLOGO EM QUÍMICA AMBIENTAL, do Departamento Acadêmico de Química e

Biologia, pelo aluno FABIO BATISTA, e do grau de TECNÓLOGO EM INFORMÁTICA,

do Departamento Acadêmico de Informática, pela aluna FERNANDA DAMACENO

TAVARES, da Universidade Tecnológica Federal do Paraná – Campus Curitiba, pela

seguinte banca examinadora:

Membro 1 – Prof. Dr. JÚLIO CÉSAR RODRIGUES DE AZEVEDO

Departamento Acadêmico de Química e Biologia (UTFPR)

Membro 2 – Prof. MSc. LUIZ AUGUSTO PELISSON

Departamento Acadêmico de Informática (UTFPR)

Orientadora: Profª. MSc. ANA CRISTINA BARREIRAS KOCHEM VENDRAMIN

Departamento Acadêmico de Informática (UTFPR)

Co-orientadora: Profª. Drª. VALMA MARTINS BARBOSA

Departamento Acadêmico de Química e Biologia (UTFPR)

Curitiba, 10 de dezembro de 2008.

iv

AGRADECIMENTOS

Agradecemos a professora Ana Cristina Barreiras Kochem Vendramin e a

professora Valma Martins Barbosa pela orientação, apoio, conselhos e correções do

trabalho. A Eimmy Machado dos Santos, pelas valiosas contribuições no decorrer do

projeto.

Agradecemos também a Marilia Rodrigues Santelo e Rudolf August Wolter

pelas brincadeiras, piadas e momentos hilários; os quais fizeram da universidade um

lugar mais feliz.

v

“Quando a última árvore tiver caído,

...quando o último rio tiver secado,

...quando o último peixe for pescado,

...vocês vão entender que dinheiro não se come”.

Provérbio Indígena

vi

BATISTA, Fabio; TAVARES, Fernanda Damaceno. ELABORAÇÃO DE UM

SOFTWARE PARA ESTIMAR A PROPAGAÇÃO DE UM CONTAMINANTE NO

SOLO, 2008, Trabalho de Conclusão do Curso de Graduação de Tecnologia em

Informática – Departamento Acadêmico de Informática e do Curso de Graduação de

Tecnologia em Química Ambiental – Departamento Acadêmico de Química e

Biologia, Universidade Tecnológica Federal do Paraná, Curitiba, 80 p.

RESUMO

Este trabalho apresenta o desenvolvimento de um software para estimar a

extensão da propagação de uma pluma de contaminação no solo. O sistema foi

desenvolvido baseado no conceito de usabilidade, possuindo apenas as

funcionalidades mínimas para obtenção de resultados matemáticos e gráficos

necessários para a compreensão do modelo de derramamento estudado. O IDE

(Integrated Development Environment - Ambiente de Desenvolvimento Integrado)

utilizado para a programação foi o NetBeans, utilizando-se a linguagem Java. O

software desenvolvido foi aplicado para o lançamento de tricloroetileno, cádmio e

sódio a partir da Vala Séptica da Cidade Industrial de Curitiba com o intuito de

verificar o risco de estes atingirem córregos e rios vizinhos com o passar do tempo.

Palavras chaves: pluma de contaminação, Java, modelos matemáticos, software,

solo.

vii

BATISTA, Fabio; TAVARES, Fernanda Damaceno. ELABORATION OF A

SOFTWARE TO ESTIMATE THE PROPAGATION OF A CONTAMINANT IN SOIL,

2008, Conclusion paper for the graduate course of Informatics Technology –

Informatics Academic Department and the course of Environmental Chemistry

Technology – Chemistry and Biology Academic Department, Parana State, Federal

University of Technology, Curitiba, 80 p.

ABSTRACT

This project presents the development of a software intended to estimate the

propagation of a contaminant in soil. The system was developted based on the

concept of usability, with only the minimal functionalities for the obtention of

mathematical results and the necessary plots for the comprehension of the studied

spill model. The Integrated Development Environment used in the development was

NetBeans, using the Java programming language. The software was applied for the

trichloroethylene, cadmium and sodium spill in the Hospital Waste Landfill located in

the Industrial Park, Curitiba, in order to verify the risk of contamination of streams and

rivers in the neighborhood by these substances as time goes by.

Key words: contaminant plume, Java, mathematical models, software, soil.

viii

SUMÁRIO

RESUMO.................................................................................................................... vi

ABSTRACT ............................................................................................................... vii

LISTA DE FIGURAS ................................................................................................... x

LISTA DE TABELAS ................................................................................................. xii

LISTA DE QUADROS ............................................................................................... xii

LISTA DE EQUAÇÕES..... ........................................................................................ xii

LISTA DE ABREVIATURAS E SIGLAS ................................................................... xiii

LISTA DE SÍMBOLOS .............................................................................................. xiv

1 INTRODUÇÃO ...................................................................................................... 1

1.1 Apresentação ...................................................................................................... 1

1.2 Justificativa da Escolha do Tema ........................................................................ 2

1.3 Objetivos ............................................................................................................. 2

1.3.1 Objetivo Geral ............................................................................................. 2

1.3.2 Objetivos Específicos .................................................................................. 2

1.4 Organização do Documento ............................................................................... 3 2 REVISÃO BIBLIOGRÁFICA ................................................................................. 4

2.1 Áreas Contaminadas .......................................................................................... 4

2.1.1 Gerenciamento de Áreas Contaminadas .................................................... 5

2.2 Transportes de Contaminantes no Solo ............................................................ 10

2.3 Modelos Matemáticos de Transporte de Substâncias no Solo ......................... 11

2.3.1 Derramamento Puntiforme Momentâneo .................................................. 12

2.3.2 Derramamento Puntiforme Contínuo ........................................................ 13

2.4 Estado da Arte .................................................................................................. 14

2.5 Usabilidade ....................................................................................................... 14

2.5.1 Avaliação Heurística ................................................................................. 15

2.5.2 Percurso Cognitivo .................................................................................... 17

2.6 Modelos de Processo de Desenvolvimento de Software .................................. 20

2.6.1 Modelo em Espiral .................................................................................... 21

2.7 Sistema Multiplataforma ................................................................................... 22 3 METODOLOGIA ................................................................................................. 24

3.1 Análise das Interfaces dos Softwares Existentes.............................................. 24

3.2 Levantamento de Requisitos............................................................................. 24

3.3 Construção de Protótipos ................................................................................. 24

ix

3.4 Desenvolvimento .............................................................................................. 25

3.4.1 Fases de Testes ....................................................................................... 25

3.5 Recursos Empregados ..................................................................................... 27

3.5.1 Recursos Financeiros ............................................................................... 27

3.5.2 Recursos de Hardware e Software ........................................................... 27

3.5.3 Recurso Pessoal ....................................................................................... 27 4 RESULTADOS E DISCUSSÃO .......................................................................... 28

4.1 Análise das Interfaces dos Softwares Existentes.............................................. 28

4.2 Modelagem ....................................................................................................... 29

4.2.1 Descrição da Arquitetura........................................................................... 29

4.2.2 Requisitos Funcionais e não Funcionais ................................................... 30

4.2.3 Diagramas de Caso de Uso ...................................................................... 30

4.2.4 Diagrama de Classes ................................................................................ 33

4.2.5 Diagrama de Seqüência............................................................................ 34

4.3 Construção de Protótipos ................................................................................. 37

4.4 Implementação ................................................................................................. 39

4.5 Vantagens do Software Desenvolvido .............................................................. 43

4.6 Aplicação do Software ...................................................................................... 43

4.6.1 Caracterização da Área ............................................................................ 43

4.6.2 Parâmetros Adotados ............................................................................... 48

4.6.3 Resultados e Análises .............................................................................. 51 5 CONCLUSÃO ..................................................................................................... 55 6 SUGESTÕES PARA TRABALHOS FUTUROS .................................................. 56 REFERÊNCIAS ......................................................................................................... 57 APÊNDICE ................................................................................................................ 61

x

LISTA DE FIGURAS

Figura 1 – Mapa das áreas com população sob risco de exposição a resíduos

perigosos na RMC. .............................................................................................. 6

Figura 2 – Mapa das áreas com população sob risco de exposição a resíduos

perigosos na RMC. .............................................................................................. 7

Figura 3 – Fluxograma das etapas do gerenciamento de ACs.................................... 9

Figura 4 – Modelo de processo de desenvolvimento de software em espiral. .......... 21

Figura 5 – Compilador tradicional. ............................................................................. 23

Figura 6 – Compilador Java e bytecode. ................................................................... 23

Figura 7 – Interface do MODFLOW da U.S. Geogical Survey................................... 28

Figura 8 – Interface do HSSM da U.S. Environmental Protection Agency ................ 29

Figura 9 – Casos de Uso ........................................................................................... 31

Figura 10 – Diagrama de Classes ............................................................................. 34

Figura 11 – Diagrama de Seqüência – Abrir arquivo ................................................. 35

Figura 12 – Diagrama de Seqüência – Calcular variável .......................................... 35

Figura 13 – Diagrama de Seqüência – Construir gráfico ........................................... 36

Figura 14 – Diagrama de Seqüência – Salvar arquivo .............................................. 36

Figura 15 – Primeiro Protótipo ................................................................................... 37

Figura 16 – Segundo Protótipo .................................................................................. 38

Figura 17 – Terceiro Protótipo ................................................................................... 38

Figura 18 – Tela Inicial do Software .......................................................................... 39

Figura 19 – Tela com Aba Dados Iniciais Selecionada ............................................. 40

Figura 20 – Tela com Aba Previsão Gráfica Selecionada ......................................... 40

Figura 21 – Barra de Ferramentas ............................................................................ 41

Figura 22 – Menu Arquivo ......................................................................................... 41

xi

Figura 23 – Menu Ajuda ............................................................................................ 41

Figura 24 – Tela do Item Tópicos de Ajuda ............................................................... 42

Figura 25 – Tela do Item Sobre o Akasha ................................................................. 42

Figura 26 – Localização da vala séptica. .................................................................. 44

Figura 27 – Localização dos bens a proteger no entorno da vala séptica. ................ 45

Figura 28 – Demonstração das velocidades de fluxo subterrâneo. ........................... 46

Figura 29 – Localização dos poços de monitoramento e piezométricos.. ................. 47

Figura 30 – Localização dos Córregos 1, 2 e 3 e das nascentes 1, 2 e 3. ................ 49

Figura 31 – Lançamento Contínuo do Sódio – Concentração x Tempo .................... 51

Figura 32 – Lançamento Contínuo do TCE – Concentração x Tempo ...................... 52

Figura 33 – Lançamento Contínuo do TCE – Faixas de Concentração .................... 53

Figura 34 – Lançamento Momentâneo do Cádmio – Concentração x Tempo .......... 53

xii

LISTA DE TABELAS

Tabela 1 – Descrição do caso de uso Abrir Arquivo .................................................. 31

Tabela 2 – Descrição do caso de uso Salvar Arquivo ............................................... 32

Tabela 3 – Descrição do caso de uso Calcular Variável ........................................... 32

Tabela 4 – Descrição do caso de uso Construir Gráfico ........................................... 33

Tabela 5 – Velocidade de fluxo subterrâneo ............................................................. 46

Tabela 6 – Profundidade do Aqüífero ........................................................................ 47

Tabela 7 – Comparação entre as amostras dos poços e os Valores Orientadores da

CETESB (2005). ................................................................................................ 48

Tabela 8 – Parâmetros para os Contaminantes Sódio e TCE ................................... 50

LISTA DE QUADROS

Quadro 1 – Valores Orientadores para Solo e Água Subterrânea.............................52

LISTA DE EQUAÇÕES

Equação 1 – Solução Analítica para Derramamento Puntiforme Momentâneo......... 12

Equação 2 – Solução Analítica para Derramamento Puntiforme Contínuo................13

xiii

LISTA DE ABREVIATURAS E SIGLAS

AC Área Contaminada AP Área Potencialmente Contaminada APA Área de Proteção Ambiental AS Área Suspeita de Contaminação C Linguagem de Programação C C++ Linguagem de Programação C++

CETESB Companhia de Tecnologia de Saneamento Ambiental do Estado de São Paulo

CONAMA Conselho Nacional do Meio Ambiente COMEC Coordenação da Região Metropolitana de Curitiba HSSM Hydrocarbon Spill Screening Model IDE Integrated Development Environment ISO International Organization for Standardization JVM Java Virtual Machine MINEROPAR Minerais do Paraná SA PA Pará PMC Prefeitura Municipal de Curitiba RMC Região Metropolitana de Curitiba SMMA Secretaria Municipal do Meio Ambiente TCC Trabalho de Conclusão de Curso TCE Tricloroetileno UML Unified Modeling Language UTFPR Universidade Tecnológica Federal do Paraná

VIGISOLO Vigilância em Saúde de Populações Expostas a Solo Contaminado

xiv

LISTA DE SÍMBOLOS

αL Dispersão Longitudinal

αT Dispersão Transversal

c Concentração

d Dias

∆M Massa de Poluentes Momentaneamente Emitidos

erfc Integral de Erro Complementar de Gauss

g Grama

L Litros

λ Taxa de Degradação

m Espessura do Aqüífero

m Metros

m³ Metro Cúbico

M Quantidade de Emissão da Substância

nf Porosidade Efetiva

ppm Partes por Milhão

R Fator de Retardamento

t Tempo

va Velocidade do Lençol Freático

x Coordenada Longitudinal

y Coordenada Transversal

Capítulo 1 – Introdução 1

1 INTRODUÇÃO

1.1 Apresentação

Assim como a água, o solo foi por muito tempo considerado um recurso natural

ilimitado. Porém, essa realidade já é bem diferente. A Lei 9.433 instituiu que a água

é um recurso natural limitado de domínio público e que, em situações de escassez,

deve-se priorizar o consumo humano e a dessedentação de animais (BRASIL,

1997).

O solo é um meio complexo e heterogêneo que serve de “habitat” para várias

espécies de seres vivos e possui funções imprescindíveis à vida no planeta.

Freqüentemente atua como um filtro, devido à capacidade de depurar e imobilizar

grande parte dos compostos nele depositados. Entretanto há um limite na

capacidade de depuração do solo, o qual muitas vezes acaba sendo

desconsiderado. Uma vez presente no solo, o contaminante pode ser adsorvido,

arrastado pelo vento ou pelas águas do escoamento superficial, ou ainda lixiviado

pelas águas de infiltração, podendo atingir as águas subterrâneas. Águas essas que

são fontes altamente atraentes para abastecimento, devido principalmente ao baixo

custo de captação e às condições inadequadas de qualidade das águas superficiais

(CETESB, 2008).

O artigo 255 da Constituição Federal versa sobre o direito que todo cidadão

tem de possuir um meio ambiente ecologicamente equilibrado. Portanto é também

dever do poder público assegurar a efetividade desse direito, zelando pela

preservação e restauração dos processos ecológicos essenciais (BRASIL, 1988).

Com o intuito de preservar o meio ambiente, surgem tecnologias que podem

auxiliar nos processos gerenciamento, remediação e contenção de áreas

contaminadas. Uma delas é o uso de modelos matemáticos.

Um modelo matemático não traduz a realidade em uma expressão exata, mas

cria um cenário onde nos é permitido compreendê-la, possibilitando a adoção de

ações de preservação ambiental (FILHO, 2003).


O uso destes modelos traz avanços significativos na gestão da poluição, pois

permite analisar e fazer previsões que possibilitarão eventuais ações de limitação,

juntamente com planos de melhoria da qualidade de vida da população (MOREIRA e

TIRABASSI, 2004).

1.2 Justificativa da Escolha do Tema

Para o cálculo de modelos matemáticos foram criados softwares como o

“HSSM – Hydrocarbon Spill Screening Model” (U.S. ENVIRONMENTAL

PROTECTION AGENCY, 2008) e o “MODFLOW” (U.S. GEOGICAL SURVEY,

2008). Ambos permitem a visualização de situações de derramamento de

substâncias químicas no solo e a previsão do comportamento destas substâncias ao

longo do tempo no local estudado. Ocorre, porém, que a utilização destes softwares

se torna uma tarefa dispendiosa e cansativa devido à interface pouco amigável que

possuem. Além disso, esses softwares oferecem pouca ou nenhuma orientação

sobre como o programa deve ser utilizado, possibilitando assim que o usuário

cometa erros durante a entrada de dados ou que não consiga efetivamente realizar

a previsão gráfica da situação analisada.

1.3 Objetivos

1.3.1 Objetivo Geral

Desenvolver um software para estimar a propagação de um contaminante no

solo visando proporcionar uma interface que facilite a utilização de suas

funcionalidades.

1.3.2 Objetivos Específicos

Analisar as interfaces de softwares existentes

a) Selecionar as funcionalidades que serão implementadas no software do

projeto;

b) Identificar as possíveis dificuldades encontradas durante a utilização das

interfaces estudadas.


Pesquisar e analisar os dados teóricos

a) Identificar os dados a serem utilizados;

b) Obter os dados teóricos através de referências;

c) Definir os tipos de variáveis numéricas a serem utilizadas na programação do

software e a precisão necessária nos cálculos matemáticos.

Desenvolver o software

a) Construir uma interface focada no conceito de usabilidade;

b) Desenvolver um sistema multiplataforma e de código aberto.

Aplicar os dados teóricos no software

1.4 Organização do Documento

Este trabalho está dividido em seis capítulos, sendo que neste estão os

objetivos, a justificativa e a apresentação do trabalho. No segundo capítulo consta a

revisão bibliográfica, explicando os conceitos de áreas contaminadas, transporte de

contaminantes no solo, modelos matemáticos, usabilidade e modelos de processo

de desenvolvimento de software. O terceiro capítulo apresenta a metodologia

seguida, na qual estão inseridos as etapas e os métodos utilizados na pesquisa e

levantamento de requisitos, a concepção da interface gráfica, o desenvolvimento da

programação e os testes do sistema. O quarto capítulo expõe as análises e os

resultados obtidos após a aplicação dos dados teóricos no software desenvolvido.

No quinto capítulo consta a conclusão do trabalho realizado e, por fim, serão

apresentadas sugestões para trabalhos futuros no sexto capítulo.

Capítulo 2 – Revisão Bibliográfica 4

2 REVISÃO BIBLIOGRÁFICA

2.1 Áreas Contaminadas

O conceito de Áreas Contaminadas é bastante variado no âmbito nacional e

internacional, contudo, podemos definir Área Contaminada (AC) como (CETESB,

2001):

Área onde há comprovadamente poluição causada por quaisquer

substâncias ou resíduos que nela tenham sido depositados, acumulados,

armazenados, enterrados ou infiltrados, e que determina impactos negativos

sobre os bens a proteger.

O conceito de Bens a Proteger é de extrema importância, principalmente dentro

do Gerenciamento de AC, pois é em torno destes bens que se define qual a

metodologia a ser aplicada.

Segundo a Política Nacional do Meio Ambiente (BRASIL, 1981), são

considerados bens a proteger:

• A saúde e o bem-estar da população;

• A fauna e a flora;

• A qualidade do solo, das águas e do ar;

• Os interesses de proteção à natureza/paisagem;

• A ordenação territorial e planejamento regional e urbano;

• A segurança e ordem pública.

Com isso, observa-se a importância de se identificar e monitorar uma AC, pois

pode representar graves problemas, tanto para a saúde pública quando para o meio

ambiente, uma vez que o contaminante pode deslocar-se para diferentes áreas.

Segundo Sánches (2001), quando uma indústria finaliza suas atividades, deixa

de emitir seus efluentes. Os líquidos e os gases, devido a sua natureza de fluido, se

dispersam no meio, enquanto que os sólidos permanecem presentes e acumulados

no solo ao longo do tempo, podendo lentamente poluir as águas subterrâneas ou

superficiais, prejudicando toda a biota.


Segundo o Ministério da Saúde, em um levantamento recente, foram

identificadas mais de 15 mil áreas no Brasil que apresentam solo potencialmente

contaminado. De acordo com a VIGISOLO - Vigilância em Saúde de Populações

Expostas a Solo Contaminado (2005), a Região Metropolitana de Curitiba possui

algumas áreas nas quais a população sofre o risco de exposição a resíduos

perigosos, conforme ilustram as Figuras 1 e 2.

2.1.1 Gerenciamento de Áreas Contaminadas

O processo de gerenciamento de ACs tem por objetivo proteger e minimizar os

possíveis riscos aos quais estão sujeitos a população e os recursos ambientais. Por

isso a CETESB (2005) elaborou o “Manual de Gerenciamento de Áreas

Contaminadas”, visto que não existe ainda uma resolução federal sobre

gerenciamento de ACs, o que o torna uma referência no país.

Neste manual, dependendo do nível de informações obtidas no decorrer do

gerenciamento, as áreas podem ser classificadas em áreas potencialmente

contaminadas (APs), áreas suspeitas de contaminação (ASs) ou áreas

contaminadas (ACs).

O sistema proposto, conforme ilustra a Figura 3, pode ser dividido em dois

segmentos básicos que servem como base para o gerenciamento, a identificação e

a recuperação da AC, os quais são subdivididos em etapas seqüenciais, sendo que

as informações de cada etapa servem de subsídio para a etapa seguinte.

O processo de identificação de áreas contaminadas é dividido em:

• Definição da região de interesse: determina-se a área a ser realizado o

gerenciamento e os objetivos a serem atingidos, levando sempre em

consideração os bens a proteger;

• Identificação de áreas potencialmente contaminadas: identificação das

áreas potencialmente contaminadas (APs) contidas na região de interesse;


Figura 1 – Mapa das áreas com população sob risco de exposição a resíduos perigosos na RMC. Fonte: Modificado de VIGISOLO (2005)


Figura 2 – Mapa das áreas com população sob risco de exposição a resíduos perigosos na RMC. Fonte: Modificado de VIGISOLO (2005)


• Avaliação preliminar: baseia-se em um diagnóstico preliminar da(s) AP(s)

identificadas, com o intuito de documentar provas que confirmem a

suspeita da contaminação, possibilitando a sua classificação ou a sua

exclusão do cadastro. Verifica-se também, caso seja necessário, a adoção

de medidas emergenciais nas áreas;

• Investigação confirmatória: utilizam-se métodos específicos de investigação

para a confirmação da contaminação, possibilitando a classificar como ACs

ou a excluindo do cadastro.

Posteriormente, caso caracterizado a contaminação, é iniciado o processo de

recuperação das ACs, o qual divide-se em:

• Investigação detalhada da área: assim como a investigação confirmatória,

a investigação detalhada utiliza métodos bastante específicos de análise,

entretanto com o objetivo de quantificar o contaminante e o seu

deslocamento. Tais métodos incluem o uso de modelos matemáticos para

a análise do comportamento da pluma de contaminação;

• Avaliação de risco: cujo objetivo é determinar os riscos que a AC causa aos

bens a proteger, com a possibilidade do uso de modelos matemáticos para

a análise e posterior escolha da metodologia de recuperação da área ou da

compatibilização do uso do solo com o nível de contaminação;

• Investigação para remediação: em que é realizado um levantamento das

técnicas de remediação aplicáveis à área. Em seguida, estabelece-se o

plano de investigação para a execução de ensaios piloto em campo e em

laboratório, juntamente com o uso de modelos matemáticos para avaliar a

eficiência e a confiabilidade das técnicas, selecionando a mais adequada;

• Projeto de remediação: o qual é elaborado com a finalidade de ser avaliado

pelo órgão gerenciador ou órgão de controle ambiental, o qual deverá

autorizar ou não a implantação e operação dos sistemas de remediação

propostos. O projeto deve conter todas as informações sobre a área

contaminada, além dos planos detalhados de segurança dos trabalhadores

e vizinhança; plano detalhado de implantação e operação do sistema de

remediação e o plano de monitoramento da eficiência do sistema;


Figura 3 – Fluxograma das etapas do gerenciamento de ACs Fonte: Modificado de CETESB (2001)


• Remediação: consiste no emprego da técnica de remediação previamente

definida, encerrando-se quando os níveis definidos no projeto de

remediação forem atingidos;

• Monitoramento: durante toda a etapa de remediação, a área deverá ser

monitorada, por período de tempo definido pelo órgão de controle

ambiental, cujo objetivo é verificar a eficiência da remediação e verificar se

os objetivos estão sendo atingidos.

As informações obtidas no processo de gerenciamento podem ser utilizadas

para diversos usos, como, por exemplo, o planejamento urbano da região. Sendo

assim, esses dados devem ser armazenados no Cadastro de Áreas Contaminadas,

o qual constitui o elemento central do gerenciamento de ACs.

Entretanto, para o correto gerenciamento de uma AC, faz-se necessário a

compreensão das interações entre o contaminante e o solo, bem como do

deslocamento do poluente no meio em que se encontra. Neste contexto, estimativas

de como um contaminante pode se transportar num determinado meio e qual será o

seu alcance tornam-se ferramentas importantes.

2.2 Transportes de Contaminantes no Solo

Independente da fonte da contaminação ser proveniente do esgoto sanitário,

da disposição de resíduos decorrente de atividades agrícolas ou da exploração de

recursos e vazamento de combustíveis, a substância permanece muito tempo em

contato com a superfície do solo até que seja tomada alguma decisão, ocasionando

a sua contaminação e possivelmente das águas subterrâneas.

Assim, o conhecimento dos mecanismos de transportes, bem como os efeitos

dos poluentes na água subterrânea e no solo é fundamental para o gerenciamento

de uma área contaminada. Entretanto, o transporte dessas substâncias no solo

depende diretamente das condições locais, pois as características geomorfológicas

e hidrogeologias do solo e subsolo variam muito.

Para Schianetz (1999), o transporte dos contaminantes na zona não-saturada

(situada imediatamente abaixo da superfície e acima do nível freático, em que os

poros estão parcialmente preenchidos por gases, ar e vapor de água e por água)


pode ser descrito, resumidamente, como transporte de substâncias mescláveis, as

quais são solúveis em água, e de substâncias não – mescláveis, insolúveis em água.

Ainda segundo Schianetz (1999), o transporte de substâncias mescláveis, da

superfície para o subsolo, ocorre através da água percolante da precipitação pluvial,

sendo o contaminante parcialmente retido na zona não-saturada do solo e

parcialmente arrastados para zonas mais profundas. Ao atingir o lençol freático, o

poluente pode ser carregado tanto pela superfície do aqüífero quanto para camadas

mais profundas, enquanto que as substâncias não – mescláveis (os óleos minerais e

os hidrocarbonetos clorados), que por se tratarem de compostos não miscíveis,

fluem com a água formando várias fases.

Os óleos minerais, os quais são mais leves do que a água, ao atingirem o

lençol freático, deslocam-se sobre sua superfície no sentido do fluxo aquático,

enquanto que os hidrocarbonetos clorados, por apresentarem uma maior densidade,

atingem o nível mais inferior do aqüífero, onde se difundem formando poças e

posteriormente propagam-se na direção do fluxo (SCHIANETZ, 1999).

Embora o transporte de contaminantes no solo seja um processo

extremamente complexo, simplificações podem ser adotadas para a obtenção de

soluções analíticas. Partindo-se do fato da propagação de poluentes ser orientada

por gradientes de pressão física e concentração química, esta pode ser descrita

matematicamente com a ajuda de equações de transporte.

2.3 Modelos Matemáticos de Transporte de Substâncias no Solo

O uso de modelos matemáticos de transporte de substâncias no

gerenciamento ambiental tem ganhado destaque, pois permite avaliar o alcance do

contaminante no solo em um curto espaço de tempo, o que é fundamental para a

solução de ameaças proeminentes aos bens a proteger.

Contudo, para uma boa utilização dos modelos, faz-se necessário um bom

conhecimento sobre as características físicas, químicas e biológicas do o

contaminante, bem como do meio em que ele se encontra.


Neste trabalho serão abordados dois casos de contaminação pontual do solo:

derramamento puntiforme momentâneo e derramamento puntiforme contínuo

(SCHIANETZ, 1999).

2.3.1 Derramamento Puntiforme Momentâneo

A estimativa do comportamento de um poluente gerado através de um

lançamento puntiforme e momentâneo no solo pode ser representada pela Equação

1.

Equação 1 – Solução Analítica para Derramamento Puntiforme Momentâneo Fonte: SCHIANETZ (1999)

Onde:

• c = concentração (g/m³);

• ∆M = massa de poluentes momentaneamente emitidos (g);

• x, y = coordenadas longitudinal e transversal (m);

• t = tempo (d);

• m = profundidade do aqüífero (m);

• nf = porosidade efetiva;

• αL , αT = dispersão longitudinal e transversal (m);

• va = velocidade do lençol freático (m/d);

• R = fator de retardamento;

• λ = taxa de degradação.


2.3.2 Derramamento Puntiforme Contínuo

A solução analítica para a emissão puntiforme contínua é descrita pela

Equação 2.

Equação 2 – Solução Analítica para Derramamento Puntiforme Contínuo

Fonte: SCHIANETZ (1999)

Onde:

• c = concentração (g/m³);

• M = quantidade de emissão da substância (g/d);

• x, y = coordenadas longitudinal e transversal (m);

• t = tempo (d);

• m = espessura do aqüífero (m);

• nf = porosidade efetiva;

• αL , αT = dispersão longitudinal e transversal (m);

• va = velocidade do lençol freático (m/d);

• R = fator de retardamento;

• λ = taxa de degradação;

• erfc = integral de erro complementar de Gauss.

Devido à complexidade dos cálculos matemáticos, foram desenvolvidos

softwares específicos com a finalidade de agilizar o processo de gerenciamento de

áreas contaminadas. Estes softwares tornam-se importantes, pois otimizam recursos

e tempo ao auxiliarem na investigação detalhada da área e preverem se existem

possíveis riscos que a AC pode vir ou não a causar aos bens a proteger.


2.4 Estado da Arte

Atualmente um grande número de softwares desenvolvidos para estimar o

comportamento de contaminantes no solo está disponível através da Internet, em

sites particulares ou de governos. A maior parte destes softwares funciona de

maneira impecável, efetuando cálculos e gráficos precisos, mas foram nitidamente

desenvolvidos sem o foco na usabilidade.

Os softwares pesquisados possuem interface gráfica rebuscada e de difícil

compreensão, com símbolos gráficos em demasia; apresentam funcionalidades

necessárias para a execução de uma tarefa específica de maneira desconexa em

sua parte gráfica, ao passo que deveriam estar visivelmente interligadas; não

disponibilizam mecanismos de ajuda ao usuário e controladores eficientes para

validar dados de entrada.

Todas as características acima citadas contribuem para a não aceitação do

software. Usuários que não se sentem confortáveis ao utilizar um sistema

simplesmente saem à procura de novas soluções. Por outro lado, se utilizarem algo

que não consigam compreender, poderão cometer erros com maior freqüência e o

tempo para realizar uma tarefa pode ser maior do que o esperado, gerando no

usuário uma visão negativa em relação ao programa.

2.5 Usabilidade

Segundo o Guidance on Usability - ISO 9241-11 (1998):

Usabilidade é a extensão na qual um produto pode ser usado por usuários

específicos para alcançar objetivos específicos com efetividade, eficiência e

satisfação em um contexto de uso específico.

A norma ISO 9241-11 (1998) ainda acrescenta os critérios a seguir para

definição e medição da usabilidade de um sistema:

• Facilidade de aprendizado: qualquer usuário, mesmo que não tenha tido

experiência na utilização do sistema, deve ter facilidade em operá-lo e

realizar tarefas;


• Facilidade de memorização: o usuário não deve enfrentar dificuldades ao

realizar tarefas após um período sem utilizar o sistema;

• Baixa taxa de erros: o sistema não deve apresentar erros catastróficos e

deve ser consistente durante o uso (erros, tais como a divisão por zero,

necessitam de tratamento). O usuário deve realizar suas tarefas sem

maiores transtornos e, caso ocorram, os erros devem ser facilmente

recuperados.

Nielsen, autor do livro Usability Engineering (1994), determina que a

usabilidade é um dos critérios de qualidade para sistemas e acrescenta duas outras

características às da norma citada anteriormente:

• Eficiência: o sistema deve permitir ao usuário executar suas tarefas com

alto nível de produtividade;

• Satisfação: o usuário deve se sentir confortável e confiante para interagir

com o sistema e realizar tarefas.

Para o estudo de usabilidade de um software existem métodos de avaliação

bastante específicos, tais como a avaliação heurística e o percurso cognitivo.

2.5.1 Avaliação Heurística

Segundo Nielsen (1990) e Nielsen (1994):

Avaliação heurística é um método no qual o avaliador analisa uma interface

através de um conjunto de princípios com a finalidade de detectar

problemas de usabilidade.

Ainda segundo Nielsen (1994), o conjunto de princípios, ou heurísticas, para a

avaliação do design de uma interface é composto por dez itens gerais, sendo eles:

• Visibilidade do status do sistema: o sistema deve sempre manter o usuário

informado sobre o que está acontecendo através de feedback apropriado e

em um tempo razoável;

• Compatibilidade entre o sistema e o mundo real: o sistema deve utilizar

palavras, frases e conceitos familiares ao usuário, e evitar a utilização de


termos específicos (códigos do sistema). Deve seguir convenções do

mundo real, fazendo com que a informação seja disponibilizada em ordem

lógica e natural;

• Controle e liberdade para o usuário: “saídas de emergência” devem ser

claramente definidas e disponibilizadas ao usuário quando funções do

sistema forem selecionadas por engano e se desejar desfazer uma

operação imediatamente;

• Consistência e padrões: a interface deve ter convenções não-ambíguas.

Ou seja, não deve disponibilizar situações, palavras ou ações que tenham

o mesmo significado de maneira desigual;

• Prevenção de erros: erros são considerados as principais fontes de

frustração, ineficiência e ineficácia durante a utilização do sistema;

• Reconhecimento em lugar de lembrança: objetos, ações e opções devem

estar sempre visíveis e disponibilizados de modo coerente. As instruções

para o uso do sistema devem também estar visíveis ou facilmente

acessíveis;

• Flexibilidade e eficiência de uso: o sistema deve ser adequado tanto para

usuários inexperientes quanto para usuários experientes;

• Projeto minimalista e estético: os diálogos não devem conter informações

irrelevantes ou raramente necessárias;

• Auxiliar o usuário a reconhecer, diagnosticar e recuperar erros: mensagens

de erro devem ser expressas em linguagem natural (sem códigos do

sistema), indicando precisamente o erro e sugerindo uma solução;

• Ajuda e documentação: estas informações devem ser de fácil localização,

centradas na tarefa do usuário, não muito extensas e listarem passos

concretos a serem seguidos. A ajuda deve estar facilmente acessível e

também on-line.

Assim, cada princípio recebe uma nota na escala de 0 a 4 durante o teste com

a interface. Esta escala serve para identificar o grau de severidade do problema de

usabilidade referente ao item analisado e é composta pelos seguintes níveis:


• 0: Não é considerado problema de usabilidade;

• 1: Problema cosmético: não é necessário repará-lo, ao menos que haja

tempo extra disponível para a finalização do projeto;

• 2: Problema simples de usabilidade: baixa prioridade de reparo;

• 3: Problema grave de usabilidade: alta prioridade de reparo;

• 4: Catástrofe de usabilidade: é imprescindível o reparo deste item antes do

produto ser disponibilizado.

Ao final da avaliação heurística é gerado um relatório contendo as notas

relativas a cada item analisado, de acordo com o comportamento da interface.

2.5.2 Percurso Cognitivo

Segundo Wharton et al. (1994):

O percurso cognitivo é um método analítico que avalia uma proposta de

projeto de Interface Homem-Computador no contexto de tarefas específicas

do usuário.

Também é possível definir o percurso cognitivo como um método que tem por

finalidade a avaliação de um design de interface quanto ao aspecto de facilidade de

aprendizado por exploração.

O aprendizado por exploração compreende a ação de adquirir o conhecimento

necessário para a perfeita execução das tarefas durante a própria utilização do

sistema, sem a necessidade de treinamento extra ou utilização de manuais de

instruções, por exemplo.

O percurso cognitivo pode ser realizado em uma simulação em desenho da

interface, em um protótipo mínimo ou em um protótipo completo; não admitindo a

participação de usuários e sendo realizado individualmente pelo projetista ou em

grupo de pessoas relacionadas ao projeto.

Os principais focos de investigação deste método são:

• A existência de similaridade entre o conceito de uma tarefa na perspectiva

dos usuários e na perspectiva dos projetistas;


• A escolha do vocabulário a ser utilizado na interface;

• A existência de feedback adequado decorrente de uma ação no sistema.

Antes da fase de avaliação ocorre a fase de preparação do teste, na qual se

definem:

• Quem serão os futuros usuário do sistema;

• Quais tarefas farão parte do cenário de tarefas a ser analisado;

• Qual a seqüência correta de ações para a execução de cada tarefa;

• Qual será a proposta de design, juntamente com a descrição de todas as

ações necessárias para a execução das tarefas e o respectivo feedback do

sistema.

A fase de avaliação compreende os seguintes passos:

1. O projetista apresenta a proposta de design;

2. O avaliador constrói roteiros de interação do usuário com a interface,

baseando-se no cenário de tarefas definido anteriormente;

3. O avaliador realiza a simulação da execução das tarefas efetuando

perguntas a cada passo, visando detectar problemas passíveis de

ocorrência durante a interação do usuário com o sistema;

4. O avaliador registra informações relevantes, tais como o que o usuário

precisa saber antes de realizar a tarefa ou o que o usuário deve aprender

ao realizar a tarefa.

Em um bom projeto de interface, é esperado que o usuário selecione a ação

desejada corretamente durante a execução de uma tarefa no software. Caso isto

não seja observado, hipóteses sobre as possíveis causas do problema são

levantadas e analisadas, para que posteriormente sejam propostas soluções

alternativas.

A seguir estão listadas as perguntas básicas, assim como as perguntas

adicionais específicas associadas a cada uma delas e as soluções típicas para as

falhas mais comuns:


O usuário conseguirá atingir a meta correta?

• O usuário saberá como proceder, caso a tarefa esteja dividida em

subtarefas?

• Qual atitude o usuário tomará a cada momento?

• Conseguirá localizar o próximo passo?

Se ocorrerem falhas neste ponto, podem-se adotar as seguintes soluções:

• Fornecer uma indicação de que a ação deve ser executada;

• A tarefa pode ser parcialmente modificada para que o usuário compreenda

a necessidade da execução da ação;

• Eliminar a necessidade de execução da ação pelo usuário. Para isso pode-

se inserir a ação em questão em outra de maior notabilidade ou fazer o

sistema responsabilizar-se pela execução.

O usuário perceberá que a ação correta está disponível?

• Onde se localiza o elemento de interface referente ao próximo passo?

• Quais ações a interface torna disponíveis?

Caso o usuário tenha o conhecimento sobre como proceder para atingir a meta

correta e deseje tomar a ação necessária para tal, mas não consegue localizar a

ação disponível na interface, as soluções abaixo podem ser aplicadas:

• Relacionar a ação a uma parte de uma estrutura, na qual possa ser

facilmente encontrada, tal como um submenu;

• Utilizar um operador mais explícito para identificar a ação, tal como itens de

menu ou instruções.

O usuário associará o elemento de interface correto à meta a ser

atingida?

• O elemento de interface explicita a sua finalidade e seu comportamento?

• O usuário identifica facilmente os elementos de interface?


Este problema pode ser corrigido através da inclusão de termos do vocabulário

do usuário em rótulos e em descrições sobre as ações realizadas pelos elementos

de interface.

Para isso o designer precisa conhecer o perfil do usuário e a maneira como ele

descreveria as tarefas do sistema.

O usuário perceberá que progrediu em direção à solução da tarefa, caso a

ação correta seja tomada?

• De que maneira a interface fornece o resultado de cada ação tomada?

• O resultado fornecido corresponde ao objetivo do usuário?

Para um feedback ser considerado útil ele deve sempre indicar o que ocorreu e

não somente que algo aconteceu.

Além desta característica, o feedback deverá conter termos ou símbolos

familiares à linguagem do usuário.

2.6 Modelos de Processo de Desenvolvimento de Software

O processo de desenvolvimento de software faz parte da Engenharia de

Software e é um dos principais mecanismos para a obtenção de sistemas de

qualidade, sendo composto por um conjunto de atividades previamente ordenadas.

Para a representação abstrata e organização da seqüência de execução das

atividades de um processo de desenvolvimento foram criados os modelos de

processo. Os modelos auxiliam no controle de gastos e no melhoramento da

produtividade e da qualidade do software de um projeto.

Existem diversos tipos de modelos de processo, cada qual possuindo uma

seqüência de atividades diferenciadas, que podem ser aplicados a diferentes tipos

de projeto, dependendo, dentre outros fatores, das particularidades do software a

ser desenvolvido.

Considerando-se que os requisitos que um sistema deve atender podem ser

alterados durante a execução de um projeto, a iteração, ou repetição da seqüência


das atividades de um modelo de processo, torna-se fundamental para evitar o

comprometimento do software desenvolvido.

Alguns modelos, tal como o Modelo em Espiral, utilizam a iteração como uma

forma de gerar soluções alternativas para atingir os objetivos de um projeto quando,

por exemplo, o cliente não sabe exatamente o que deseja como produto final.

2.6.1 Modelo em Espiral

Em 1988, Barry Boehm sugeriu o modelo em espiral, conhecido por destacar a

análise de riscos (riscos são ocasiões passíveis de acontecimento, tal como a

ocorrência de falhas em equipamentos utilizados no desenvolvimento do software) e

o planejamento, permitindo que as idéias iniciais e o progresso sejam verificados e

avaliados constantemente, tal como ilustrado na Figura 4.

Figura 4 – Modelo de processo de desenvolvimento de software em espiral.

Fonte: BOEHM (1988)


Segundo Boehm (1988), o modelo em espiral descreve um fluxo de atividades

cíclico e evolutivo constituído de quatro fases:

• Na primeira fase são determinados os objetivos e as soluções alternativas;

• Na segunda fase é realizada a análise de riscos das decisões da fase

anterior. Durante este estágio podem ser construídos protótipos e realizadas

simulações;

• A terceira fase envolve as atividades de desenvolvimento seguidas da

verificação apropriada para cada especificação que vai surgindo a cada ciclo;

• Na quarta fase são realizados a revisão das etapas anteriores e o

planejamento para o próximo ciclo. Neste planejamento, dependendo dos

resultados obtidos nas fases anteriores, pode-se optar por seguir outro

modelo de processo diferente do espiral ou pela construção de novos

protótipos mais aprimorados, seguidos da avaliação dos novos riscos e do

replanejamento do processo.

As fases listadas acima são repetidas até que o produto final esteja de acordo

com todas as especificações que devem ser atingidas ou até que outros fatores, tais

como prazos e falta de recursos delimitem o final do processo.

2.7 Sistema Multiplataforma

Algumas linguagens de programação, tal como C e C++ são consideradas

multiplataforma, ou seja, podem ser executadas em mais de uma plataforma, tais

como Windows, Unix, Macintosh, mas os programas através delas desenvolvidos

necessitam serem compilados para construir arquivos binários contendo instruções

específicas da plataforma onde serão executados.

Isto torna impossível, por exemplo, executar um programa desenvolvido em

Windows em um sistema Unix ou Macintosh, devido às diferentes instruções

contidas no arquivo binário.

A Figura 5 demonstra o funcionamento de um compilador tradicional gerando

arquivos binários específicos para cada plataforma.


Figura 5 – Compilador tradicional. Fonte: JONES e NEFF (1997)

Por outro lado, quando um programa desenvolvido em linguagem Java, da Sun

Microsystems, é compilado, é gerado um código intermediário, denominado

bytecode. Este bytecode é o mesmo independentemente do hardware ou sistema

operacional no qual o programa será executado.

A Máquina Virtual Java (JVM) é um interpretador, o qual traduz, em tempo de

execução, os bytecodes Java em código executável de máquina, aplicando o

conceito “write once, run anywhere”, ou seja, tornando possível que programas

escritos em Java funcionem da mesma forma em diferentes plataformas de

hardware ou software que possua uma JVM.

A Figura 6 demonstra o funcionamento do compilador Java (Javac.exe)

transformando o arquivo contendo o código fonte (Java Source Code) em bytecode

(Java Bytecode) e o executando em diferentes plataformas (Java.exe).

Figura 6 – Compilador Java e bytecode. Fonte: JONES e NEFF (1997)

Capítulo 3 – Metodologia 24

3 METODOLOGIA

Durante o projeto utilizou-se o modelo de processo de desenvolvimento de

software em espiral (BOEHM, 1988), para organização da seqüência de execução

das atividades listadas abaixo. Concomitantemente, foi realizada, através de

levantamentos em referências, a pesquisa de dados teóricos referentes a

características do solo de Curitiba para a posterior aplicação no software.

3.1 Análise das Interfaces dos Softwares Existentes

Primeiramente foram analisadas, através de simulações de utilização, as

interfaces dos softwares “HSSM – Hydrocarbon Spill Screening Model”, da “U.S.

Environmental Protection Agency”, e o “MODFLOW”, da “U.S. Geogical Survey”, que

realizam a estimativa do comportamento de poluentes no solo.

3.2 Levantamento de Requisitos

Após a análise das interfaces existentes, foram definidos quais os tipos de

dados a serem utilizados na programação e como seriam tratadas as peculiaridades

nos cálculos matemáticos, tais como definição do número de casas decimais,

arredondamento de resultados entre outros. Foram também analisadas as

funcionalidades a serem implementadas e como estas se relacionariam dentro do

sistema.

3.3 Construção de Protótipos

Utilizando o ambiente de desenvolvimento integrado “NetBeans IDE”, foram

confeccionados alguns protótipos de interfaces a serem utilizados pelo software,

assim, tendo em foco a usabilidade do sistema, foi analisado o comportamento

destas interfaces e determinada a mais apropriada.

Concomitantemente, foi confeccionada a documentação visual da arquitetura,

através de diagramas que demonstram as relações entre as funcionalidades do

software e como o sistema interage com o usuário.


3.4 Desenvolvimento

A linguagem de programação Java e o ambiente “NetBeans IDE” foram

escolhidos para implementar o software, sendo regularmente realizados testes para

verificar o correto funcionamento do sistema e suas formas de interação com o

usuário.

Evitou-se a construção de uma interface repleta de ícones e outros símbolos

supérfluos que pudessem comprometer a facilidade de utilização do software pelo

usuário. As funcionalidades também foram reduzidas somente àquelas necessárias

ao estudo do derramamento em questão.

3.4.1 Fases de Testes

A seguir são descritas as fases de testes executadas no sistema desenvolvido.

3.4.1.1. Testes de Unidade

Cada funcionalidade presente no sistema foi implementada e testada

individualmente, visando certificar o correto funcionamento da execução de suas

tarefas específicas.

Esta fase esteve mais voltada para a correção de erros em pequenos trechos

do código fonte da programação.

3.4.1.2. Testes de Integração

Nesta fase foram testadas as integrações dos módulos do sistema, tendo por

objetivo detectar a ocorrência de erros em trocas de mensagens entre os

componentes internos e verificar a correta implementação do código de acordo com

a arquitetura previamente estabelecida.

3.4.1.3. Testes de Sistema

Os testes de sistema constituíram-se na simulação de tarefas comumente

realizadas pelo usuário final.


Deste modo foi possível observar o comportamento do software como um todo

e analisar a qualidade das interações através de sua interface, como o recebimento

de mensagens de erro e o retorno de resultados.

3.4.1.4. Testes de Regressão

Foram utilizados testes de regressão a cada nova implementação no sistema,

realizando-se assim todo o ciclo anteriormente definido, os quais englobam as fases

de testes de unidade, testes de integração e testes de sistema.

Primeiramente o novo trecho de código era analisado e testado

individualmente. Caso não fossem encontrados erros nesta fase, iniciava-se então a

fase de testes de integração, onde era verificado o comportamento entre os módulos

do sistema. Finalmente eram realizados os testes de sistema para certificar o bom

funcionamento do software após a inserção do novo trecho de código.

3.4.1.5. Testes de Usabilidade

O foco na usabilidade manteve-se durante toda a etapa de construção de

protótipos e desenvolvimento do software, exigindo, portanto, a realização de testes

para verificar as características de usabilidade e cognição da interface do sistema.

3.4.1.5.1 Testes de Avaliação Heurística

Durante o desenvolvimento do projeto foram realizados testes de utilização do

sistema para verificar se todos os dez princípios gerais definidos por Nielsen (1994)

eram atendidos de maneira satisfatória.

3.4.1.5.2 Testes de Percurso Cognitivo

Ao longo do desenvolvimento foram realizadas contínuas análises pelos

autores, os quais executaram tarefas no sistema, sempre verificando a existência de

cognição na interface do software que permitisse a memorização das etapas e

assimilação de ícones gráficos, tornado assim mais agradável e fácil a utilização do

programa pelo usuário.


3.5 Recursos Empregados

Abaixo são listados os recursos empregados no desenvolvimento do projeto.

3.5.1 Recursos Financeiros

Não ocorreram gastos financeiros significativos durante a execução do projeto

que necessitem serem aqui contabilizados.

3.5.2 Recursos de Hardware e Software

Os recursos de hardware e software utilizados durante o projeto se resumem a

uma máquina com as configurações mínimas necessárias para a confecção dos

protótipos de interface e programação do sistema e ferramentas de desenvolvimento

disponíveis gratuitamente na Internet.

A máquina utilizada é de propriedade dos autores e atende as características

acima citadas. Portanto não houve a necessidade de adquirir recursos extras de

hardware ou software.

3.5.3 Recurso Pessoal

Os próprios autores realizaram todas as etapas de execução do projeto,

possuindo o conhecimento necessário para tal, não havendo a necessidade de

contratação de recurso pessoal extra.

Capítulo 4 – Resultados e Discussão 28

4 RESULTADOS E DISCUSSÃO

4.1 Análise das Interfaces dos Softwares Existentes

Foram detectados problemas de usabilidade que poderiam comprometer

seriamente a utilização dos programas analisados, tais como a interface precária do

MODFLOW, da U.S. Geogical Survey, conforme mostra a Figura 7, e a inexistência

de tratamento de erros eficaz na entrada de dados do HSSM, da U.S. Environmental

Protection Agency, ilustrado na Figura 8.

Figura 7 – Interface do MODFLOW da U.S. Geogical Survey

Além destes problemas, observou-se que as interfaces analisadas não eram

intuitivas e não apresentavam as funcionalidades dispostas de maneira a facilitar a

utilização pelo usuário durante a execução de uma tarefa.

No HSSM, da U.S. Environmental Protection Agency, o menu de ajuda contido

na interface não disponibiliza claramente o passo a passo para a realização de

tarefas, entretanto um guia de usuário é disponibilizado online juntamente com o

programa para download.


Figura 8 – Interface do HSSM da U.S. Environmental Protection Agency

O MODFLOW, da U.S. Geogical Survey, não disponibiliza menu de ajuda,

somente documentações e um guia de usuário online que, porém, não são

adequados à linguagem do usuário, pois contém somente informações específicas

sobre a estrutura e a programação do software.

4.2 Modelagem

A seguir está especificada a modelagem do software Akasha, contendo a

descrição da arquitetura, requisitos funcionais e não funcionais e os diagramas UML

(Unified Modeling Language).

4.2.1 Descrição da Arquitetura

A arquitetura do software é orientada a objetos, pois implementa um conjunto

de classes, na qual cada classe define um ou mais objetos e determina seu

comportamento, seu estado e como este se relaciona com outros objetos dentro do

sistema.


4.2.2 Requisitos Funcionais e não Funcionais

O software atende os seguintes requisitos funcionais:

• Fornece resultados algébricos consistentes;

• Salva e abre arquivos de relatórios;

• Realiza previsões gráficas dos processos de derramamento de resíduos no

solo.

O software atende os seguintes requisitos não-funcionais:

• Auxilia no processo de inserção de dados, exibindo mensagens de erro

através de um formulário inteligente;

• Possui tópicos de ajuda para auxiliar o usuário na execução de tarefas no

sistema;

• Possui uma interface clara e cognitiva, sem elementos em excesso ou que

dificultem no aprendizado de utilização do software;

• Fornece os resultados necessários para a perfeita compreensão e

visualização do estado do modelo estudado.

4.2.3 Diagramas de Caso de Uso

A Figura 9 ilustra os casos de uso, os quais correspondem aos requisitos

funcionais do software.


Figura 9 – Casos de Uso

As Tabelas 1, 2, 3 e 4 apresentam respectivamente a descrição dos seguintes

casos de uso:

• Abrir Arquivo;

• Salvar Arquivo;

• Calcular Variável;

• Construir Gráfico.

Tabela 1 – Descrição do caso de uso Abrir Arquivo

Nome do caso de uso Abrir Arquivo

Descrição Permite ao usuário abrir um arquivo

Ator Envolvido Usuário

Pré-condições Sessão iniciada

Pós-condições Arquivo aberto no programa

Fluxo básico

Ator Sistema

Solicitar abertura Sistema abre o arquivo

{fim}

O caso de uso termina


Tabela 2 – Descrição do caso de uso Salvar Arquivo

Nome do caso de uso Salvar Arquivo

Descrição Permite ao usuário salvar um arquivo



Pós-condições Arquivo salvo no sistema

Fluxo básico

Ator Sistema

Solicitar salvamento Sistema salva o arquivo

{fim}


Tabela 3 – Descrição do caso de uso Calcular Variável Nome do caso de uso Calcular Variável

Descrição Permite ao usuário calcular o valor de uma variável



Pós-condições Valor mostrado ao usuário

Fluxo básico

Ator Sistema

Solicitar cálculo Sistema calcula o valor da variável

Mostra o valor da variável

{fim}


Fluxos alternativos

Informar sobre falta de

dados ou dados

incorretos: antes de

{Sistema calcula o valor

da variável}, quando é

detectado erro ou falta

de dados para realizar o

cálculo

Sistema mostra mensagem informando que os dados

não foram fornecidos ou preenchidos corretamente

Retorna ao ponto onde o processo foi interrompido


Tabela 4 – Descrição do caso de uso Construir Gráfico

Nome do caso de uso Construir Gráfico

Descrição Permite ao usuário construir a previsão gráfica do

modelo estudado, baseada nos dados iniciais

inseridos.



Pós-condições Gráfico mostrado ao usuário

Fluxo básico

Ator Sistema

Solicitar previsão

gráfica

Sistema constrói o gráfico

Mostra o gráfico

{fim}


Fluxos alternativos

Informar sobre falta de

dados ou dados

incorretos: antes de

{Sistema constrói o

gráfico}, quando é

detectado erro ou falta

de dados para realizar o

cálculo

Sistema mostra mensagem informando que os dados

não foram fornecidos ou preenchidos corretamente

Retorna ao ponto onde o processo foi interrompido

4.2.4 Diagrama de Classes

A Figura 10 ilustra o diagrama de classes do software.

A programação do software é formada pelas classes:

• Arquivo;

• ArquivoPuntiforme;

• Calculo;


• CalculoPuntiforme;

• Grafico;

• GraficoFaixas;

• GraficoTempo;

• Interface.

As classes ArquivoPuntiforme e CalculoPuntiforme são respectivamente

generalizações das classe Arquivo e Calculo.

As classes GraficoFaixas e GraficoTempo são generalizações da classe

Grafico.

A classe Interface contém a interface e os métodos dos componentes gráficos

do sistema.

Figura 10 – Diagrama de Classes

4.2.5 Diagrama de Seqüência

As Figuras 11, 12, 13 e 14 ilustram respectivamente os diagramas de

seqüência:

• Abrir Arquivo;

• Calcular Variável;

• Construir Gráfico;

• Salvar Arquivo.


4.2.5.1. Diagrama de Seqüência – Abrir Arquivo

Figura 11 – Diagrama de Seqüência – Abrir arquivo

4.2.5.2. Diagrama de Seqüência – Calcular Variável

Figura 12 – Diagrama de Seqüência – Calcular variável


4.2.5.3. Diagrama de Seqüência – Construir Gráfico

Figura 13 – Diagrama de Seqüência – Construir gráfico

4.2.5.4. Diagrama de Seqüência – Salvar Arquivo

Figura 14 – Diagrama de Seqüência – Salvar arquivo


4.3 Construção de Protótipos

A partir das dificuldades encontradas na utilização dos softwares analisados e

da definição das funcionalidades a serem implementadas, foram construídos

protótipos de interface, utilizando-se o “NetBeans IDE”.

A Figura 15 ilustra o primeiro protótipo confeccionado, visando como seriam

dispostas as funcionalidades na interface do programa. Neste protótipo também foi

definido o gráfico a ser utilizado para demonstrar o comportamento da concentração

em função do tempo.

Figura 15 – Primeiro Protótipo

Visando aprimorar a forma com que o usuário seleciona o modelo de

derramamento a ser utilizado, foi desenvolvido o segundo protótipo, de acordo com

a Figura 16, no qual também foi definido o tipo de gráfico a ser utilizado na

visualização do comportamento do poluente no solo.


Figura 16 – Segundo Protótipo

O terceiro protótipo confeccionado, como mostra a Figura 17, teve por objetivo

disponibilizar as funcionalidades do programa de maneira mais organizada,

separando por abas o formulário de entrada de dados inicias da previsão gráfica do

solo.

Figura 17 – Terceiro Protótipo


No quarto, e último, protótipo construído foi concebida a interface final do

programa, a qual foi implementada no software Akasha. Neste protótipo aprimorou-

se novamente a maneira como o usuário seleciona o modelo de derramamento a ser

utilizado e a disposição de suas funcionalidades.

4.4 Implementação

A Figura 18 mostra a tela inicial do programa Akasha, onde seleciona-se o

modelo de derramamento desejado.

Figura 18 – Tela Inicial do Software

Após a seleção do modelo, o programa disponibilizará a tela correspondente,

como demonstrado na Figura 19, contendo a aba Dados Iniciais, onde o usuário

insere os dados para o cálculo a ser efetuado.

Selecionando-se a aba Previsão Gráfica, como mostra a Figura 20, o usuário

informa os dados requeridos e constrói gráficos baseados nos dados inseridos

anteriormente na aba de Dados Iniciais.


Figura 19 – Tela com Aba Dados Iniciais Selecionada

Figura 20 – Tela com Aba Previsão Gráfica Selecionada

Na Figura 21 é ilustrada a barra de ferramentas do software, a qual contém os

botões Novo arquivo, Abrir arquivo e Salvar arquivo, dispostos nesta seqüência.


Figura 21 – Barra de Ferramentas

O programa possui o menu Arquivo, como mostra a Figura 22, composto pelos

sub-menus Novo arquivo, responsável por disponibilizar novas telas iniciais ao

usuário; Abrir arquivo, o qual abre uma nova janela do programa com o formulário de

dados iniciais preenchido com dados do arquivo selecionado no sistema; Fechar, o

qual fecha a janela do modelo de derramamento previamente selecionado e retorna

à janela inicial do programa; Salvar, responsável por salvar arquivos no sistema,

contendo os dados informados na aba Dados Iniciais; e Sair, o qual fecha totalmente

a janela do programa.

Figura 22 – Menu Arquivo

O menu Ajuda é composto pelos sub-menus Tópicos de ajuda, cujos tópicos

encontram-se descritos no Apêndice, e Sobre o Akasha, de acordo com a Figura 23.

O primeiro abre a tela de ajuda do programa, ilustrada na Figura 24, a qual

contém tópicos sobre como realizar tarefas. O segundo sub-menu abre uma tela

contendo informações sobre o programa, como mostra a Figura 25.

Figura 23 – Menu Ajuda


Figura 24 – Tela do Item Tópicos de Ajuda

Figura 25 – Tela do Item Sobre o Akasha


4.5 Vantagens do Software Desenvolvido

O software desenvolvido neste trabalho tem como diferencial sua interface de

compreensão simples, desenvolvida com foco nos conceitos de usabilidade, onde o

usuário em poucas etapas pode realizar facilmente:

• Cálculos algébricos de complexidade moderada;

• Previsões gráficas que demonstram o comportamento do poluente no solo;

• Salvar e abrir relatórios contendo dados das variáveis referentes ao modelo

de derramamento.

Além destas características, o sistema também possui um menu de ajuda, no

qual o usuário pode selecionar a ação desejada e obter informações sobre como

realizar uma tarefa passo a passo, é multiplataforma, ou seja, não dependerá do uso

de hardware ou software específicos para funcionar, e possui código aberto, o que

possibilitará futuros aperfeiçoamentos e implementações.

4.6 Aplicação do Software

Uma vez concluído o desenvolvimento do software Akasha, foram realizadas

aplicações práticas utilizando a Vala Séptica da Cidade Industrial de Curitiba como

exemplo do local da fonte da contaminação.

4.6.1 Caracterização da Área

A Vala de Resíduos Sólidos de Serviços de Saúde de Curitiba – Vala Séptica

localiza-se na Avenida Juscelino Kubitschek de Oliveira, s/n°, no Bairro Cidade

Industrial de Curitiba, como demonstrado na Figura 26, e possui uma área total de

92.694 m², das quais 83.390 m² são destinados à disposição de resíduos.


Figura 26 – Localização da vala séptica. Modificado de GOOGLE MAPS (2008)

Desde o início de suas atividades, em outubro de 1988, até o seu fechamento

definitivo em abril de 2005, a Vala Séptica ficou responsável pelo recebimento de

resíduos provenientes de clínicas, consultórios odontológicos e médicos, postos de

saúde, hospitais, entre outros, proveniente dos municípios de Curitiba, São José dos

Pinhais, Piraquara, Pinhais, Mandirituba, Almirante Tamandaré e Araucária,

Campina Grande do Sul e Quatro Barras.

Segundo Santos (2008), em um estudo sobre a Vala Séptica, foi constatada a

contaminação da área durante a etapa da investigação confirmatória do local. Isto se

deve ao prolongamento da utilização da Vala, de 18 meses, inicialmente previsto no

projeto, para 16 anos, o que causou a extrapolação da taxa de autodepuração da

área, e aliado à falta de um sistema de coleta de chorume no subsolo da região,

proporcionou o surgimento de plumas de contaminação.

Ainda segundo Santos (2008), durante a inspeção de reconhecimento da área,

foram detectados alguns bens a proteger no entorno da Vala, tais como rodovias,

áreas residenciais, comerciais e industriais, corpos hídricos e vegetação, como

demonstra a Figura 27. Outro fator relevante para a área em estudo é a sua

proximidade com a APA do Passaúna, a qual envolve toda represa do Rio Passaúna

que serve para abastecimento público do município. Porém, com relação à bacia

hidrográfica, a área das valas possui em seus arredores dois córregos (chamados de

Córrego da Vala e Córrego das Araucárias) que são afluentes do Rio Bariguí. De

acordo com Santos (Apud SMMA/PMC, 2006), apesar da proximidade ao


reservatório do Passaúna, a bacia de contribuição das águas incidentes sobre a vala

é a Bacia do Rio Bariguí.

Figura 27 – Localização dos bens a proteger no entorno da vala séptica.

Fonte: SANTOS (Apud Modificado de GOOGLE MAPS, 2008)

Na área existem dez poços de monitoramento (PM), seis piezométricos (PZ) e

três de amostras de águas superficiais (P) para análise de parâmetros físico-

químicos de amostras de água subterrânea, água superficial e solo, bem como para

a determinação de valores de velocidade, indicados na Tabela 5, e direção de fluxo

subterrâneo, indicado na Figura 28.

Estes poços são identificados de acordo com o local de origem, conforme

ilustra a Figura 29.


Figura 28 – Demonstração das velocidades de fluxo subterrâneo.

Fonte: SANTOS ( Apud Adaptado de PMC, 2006).

Tabela 5 – Velocidade de fluxo subterrâneo

Indicação no Mapa Velocidade (m/ano) Poço a Montante Poço a Jusante

V1 24,9 PM-05 PM-23

V2 30,3 PZ-11 PZ-13

V3 36,9 PM-03 PM-24

V4 2,5 PM-15 PM-21

V5 78,8 PM-20 PM-25

V6 132,7 PZ-10 PZ-19

Fonte: SANTOS ( Apud PMC, 2006)


Figura 29 – Localização dos poços de monitoramento e piezométricos. Fonte:

SANTOS ( Apud Adaptado de PMC, 2006).

A partir de alguns poços de monitoramento, foram determinados os valores de

profundidades do aqüífero listados na Tabela 6.

Tabela 6 – Profundidade do Aqüífero

Poço Profundidade (m) PM-01 1,790 PM-02 1,220 PM-03 3,060 PM-04 1,650 PM-05 5,210 PM-06 5,060 PM-07 2,800 PM-09 2,010 PM-10 1,910 PM-11 2,680 PM-12 4,310 PM-13 4,250 PM-14 6,200 PM-15 2,070 PM-16 1,790 PM-17 1,900 PM-18 2,300 PM-19 1,920

Fonte: Modificado de SANTOS ( Apud PMC, 2006)


A partir de análises químicas realizadas pela BIOLÓGICA Consultoria

Ambiental e Serviços Ltda. (SANTOS Apud SMMA/PMC, 2006) nos poços, foram

detectados valores acima dos Valores Orientadores da CETESB (2005) para

intervenção de águas subterrâneas, os quais estão indicados na Tabela 7.

Tabela 7 – Comparação entre as amostras dos poços e os Valores Orientadores da CETESB (2005).

Parâmetro AMOSTRAS VALORES ORIENTADORES CETESB (2005)

Unidades PM-03 PM-06 PZ-13 PM-20 PM-21 PM-22 PM-23 INTERVENÇÃO ÁGUAS

SUBTERRÂNEAS

Ferro mg/L 0,036 16,5 < 0,01

0,016 0,729 0,114 2,6 300 µg/L

Alumínio mg/L 0,052 < 0,01 0,024 0,096 0,062 0,163 0,296 200 µg/L

Chumbo mg/L < 0,01 < 0,01 < 0,01

< 0,01 < 0,01 < 0,01 < 0,01 10 µg/L

Cádmio mg/L < 0,001 < 0,001 191 < 0,001 <0,001 < 0,001 < 0,001 5 µg/L

Níquel mg/L 0,023 < 0,01 0,00017 < 0,01 0,026 < 0,01 < 0,01 50 µg/L

Mercúrio mg/L < 5E-5 0,00015 < 0,01 < 0,0001 < 0,0001 < 0,0001 0,00013 1 µg/L

Zinco mg/L 0,111 0,026 < 0,01 0,125 0,255 0,046 0,026 5000 µg/L

Boro mg/L < 0,01 0,048 < 0,01 < 0,01 < 0,01 < 0,01 < 0,01 500 µg/L Cromo

total mg/L < 0,01 < 0,01 0,03 < 0,01 < 0,01 < 0,01 < 0,01 50 µg/L Nitrogênio

nitrato mg/L 1 < 0,2

< 0,2 < 0,1 < 0,1 0,2 10000 µg/L

Fonte: SANTOS ( Apud SMMA/PMC, 2006) Nota: Os valores em vermelho correspondem aos resultados acima dos valores de

referência.

Para a realização do estudo da Vala utilizando o software desenvolvido, foram

aplicados dados referentes à análise destes poços, entretanto, visando o andamento

do projeto foram adotados alguns parâmetros e feitas algumas considerações,

entendendo-se que o foco principal do trabalho não é determinar a real

concentração do contaminante e sim realizar a análise do comportamento da pluma

no solo.

4.6.2 Parâmetros Adotados

Devido a contaminação do poço PZ-13 por altos níveis de cádmio, e por estar

inserido em uma área, cujo fluxo subterrâneo, V2, flui em direção ao Córrego 1,

adotou-se este poço como sendo o ponto inicial da contaminação.


O Córrego 1, conhecido também como Córrego da Vala, encontra-se dentro de

um raio de 500 metros do centro da Vala Séptica, conforme ilustra a Figura 30,

possui maior vazão dentre os três córregos próximos à Vala, passa por regiões

habitacionais, deságua no Rio Bariguí e possui contribuição das águas de drenagem

e subterrâneas da região oeste da vala. (SANTOS, 2008)

Figura 30 – Localização dos Córregos 1, 2 e 3 e das nascentes 1, 2 e 3. Fonte:

SANTOS ( Apud Adaptado de PMC, 2006).

O valor de profundidade de aqüífero utilizado é referente ao poço PM-05, por

este estar localizado próximo ao poço PZ-13.

Na ausência de todos os dados necessários para poder aplicar o software,

foram utilizados dados de um estudo realizado sobre o fluxo dos contaminantes no

Lixão do Aurá, em Belém – PA (VENTURIERI, 2001). Considerando que as

características físicas do solo do Lixão são semelhantes às da Vala Séptica, onde há

uma alternância entre solos arenosos e argilosos, foram tomados os valores

indicados na Tabela 8, em que o tricloroetileno (TCE) e o Sódio provenientes do

chorume são adotados como contaminantes.


Tabela 8 – Parâmetros para os Contaminantes Sódio e TCE

Parâmetro Valor Adotado

Porosidade efetiva 0,30

Dispersão longitudinal 10 m

Dispersão transversal 1 m

Concentração inicial do Sódio 8,00 ppm

Taxa de biodegradação do Sódio 0,00

Retardamento do Sódio 1,00

Concentração inicial do TCE 0,001 ppm

Taxa de biodegradação do TCE 0,003

Retardamento do TCE 2,00

Fonte: Modificado de VENTURIERI (2001)

Assim, para os contaminantes acima citados, tem-se a produção diária de

aproximadamente 613,88 gramas de sódio e de 75,74 gramas de TCE, visto que

estimativas apontam a produção de 27.264.497,19 L/ano de chorume para os

próximos anos na Vala Séptica da Cidade Industrial de Curitiba (SANTOS, apud

PMC, 2006). Por esta razão, ambos contaminantes serão aplicados no modelo de

lançamento puntiforme contínuo, pois apresentam taxas diárias de lançamento no

solo.

Pelo fato de não se obter a taxa de lançamento diária do contaminante cádmio,

adotou-se a concentração obtida no poço PZ-13 (191 mg/L), a qual apresentou um

valor muito acima do orientado pela CETESB (5 µg/L), como sendo a massa total

emitida no solo. Conseqüentemente utilizou-se o modelo puntiforme momentâneo

para o estudo do comportamento do cádmio na região.

A taxa de degradação e o fator de retardamento do composto cádmio foram

considerados 0 e 1, respectivamente. Isto se deve ao fato de ter sido considerada

uma degradação nula do composto e desconsiderado as interações do cádmio com

o solo.

Considerando que a pluma de contaminação desloca-se no sentido do fluxo do

aqüífero, tem-se uma coordenada transversal nula, e devido à localização do


córrego estar dentro de um raio de 500 metros do centro da Vala, adotou-se o valor

de 400 metros para a coordenada longitudinal no estudo do sódio e do TCE. Porém,

a coordenada longitudinal adotada para o caso do cádmio foi de 200 metros, pois o

poço PZ-13 localiza-se fora da área cercada da Vala e mais próximo ao Córrego 1.

4.6.3 Resultados e Análises

A Figura 31 demonstra a curva de concentração em função do tempo, quando

utilizado o software para o lançamento puntiforme contínuo do sódio.

Figura 31 – Lançamento Contínuo do Sódio – Concentração x Tempo

Observa-se que a partir da desativação da vala em 2005, hoje teríamos uma

concentração nula do composto próximo ao Córrego. Constata-se também que a

concentração máxima do sódio atinge 23,1698 mg/L. Isto demonstra que o

lançamento do sódio proveniente do chorume não constitui uma contaminação, uma

vez que o padrão de aceitação da água para consumo humano permitido, segundo o

Ministério da Saúde (2005), é de até 200 mg/L.

A Figura 32 apresenta a curva de concentração pelo tempo para o lançamento

puntiforme contínuo do TCE.


Figura 32 – Lançamento Contínuo do TCE – Concentração x Tempo

Como não foi possível determinar a concentração para os 400 metros

estabelecidos para a coordenada longitudinal, reduziu-se esta distância

gradativamente até 50 metros, no qual se obteve um valor não nulo para a

concentração. A partir desta situação observa-se que decorridos 1.000 dias o TCE

atinge sua concentração máxima, a qual se encontra abaixo dos valores

orientadores da CETESB, indicados no Quadro 1, e mantém-se constante.

Quadro 1 – Valores Orientadores para Solo e Água Subterrânea

Fonte: Modificado de CETESB (2005) Nota: na - não se aplica para substâncias orgânicas.

Também é constatado que o contaminante TCE não atinge o Córrego 1 nesta

situação, devido ao seu fator de retardamento (2,00) e à sua taxa de degradação

(0,003) combinados ao tempo decorrido.


A Figura 33 apresenta as faixas de concentração do TCE no solo obtidas no

software. Ao analisar o gráfico é possível observar a disposição da pluma do

contaminante no milésimo dia de lançamento da substância.

Figura 33 – Lançamento Contínuo do TCE – Faixas de Concentração

A curva de concentração em função do tempo obtida no software para o

lançamento puntiforme momentâneo do cádmio encontra-se ilustrada na Figura 34.

Figura 34 – Lançamento Momentâneo do Cádmio – Concentração x Tempo


Analisando os resultados obtidos, nota-se que mesmo a concentração do

cádmio estando acima dos valores orientados pela CETESB no poço de

monitoramento PZ-13, a concentração máxima que atinge o córrego,

aproximadamente 0.000016 mg/L, encontra-se abaixo dos valores orientadores da

CETESB (2005): 0,005 mg/L; da Portaria 518 do Ministério da Saúde (2004): 0,005

mg/L; e da Resolução CONAMA 357 (2005) para Águas Classe III: 0,01 mg/L.

Entretanto, deve-se ater ao fato de que os cálculos realizados utilizaram

apenas a massa da concentração obtida na análise do ponto PZ-13. Contudo, caso

fosse considerado todo o cádmio gerado no chorume ao longo do tempo, esta

situação poderia ser alterada, podendo ocorrer a contaminação do Córrego 1 e

possivelmente do Rio Bariguí.

Assim, utilizando-se o software, observa-se que a partir dos resultados, em

relação aos pontos e às substâncias aplicadas, a princípio, não são inferidos riscos a

outros bens a proteger, se limitando a contaminação apenas às áreas próximas do

ponto de disposição. Para uma real análise seria necessário um estudo mais

sistêmico levando em consideração outros contaminantes, pontos de amostragem e

fatores.

Capítulo 5 – Conclusão 55

5 CONCLUSÃO

A interface do software Akasha, a qual é baseada no conceito de usabilidade,

influi positivamente durante a utilização do sistema, pois facilita o processo de

entrada de dados e a apresentação dos resultados, aumentando a satisfação do

usuário e evitando que o software seja considerado mais um obstáculo durante a

execução de suas tarefas.

Assim, o software torna-se uma ferramenta fundamental durante o processo de

gerenciamento de Áreas Contaminadas, pois otimiza recursos principalmente em

situações de risco eminente aos bens a proteger.

Durante a aplicação do software no caso da Vala Séptica da Cidade Industrial

de Curitiba, foi constatado que as substâncias aplicadas (cádmio, sódio e

tricloroetileno), a principio, não oferecem riscos a outros bens a proteger, se

limitando apenas às áreas de solo próximas ao ponto de disposição.

Com tudo, estas determinações foram baseadas na utilização de dados

pesquisados e considerações realizadas neste trabalho. Mas mesmo assim,

observou-se que o software realiza satisfatoriamente a estimativa do comportamento

de plumas de contaminação no solo.

Capítulo 6 – Sugestões para Trabalhos Futuros 56

6 SUGESTÕES PARA TRABALHOS FUTUROS

Como trabalhos futuros propõe-se:

• Aperfeiçoar a programação do software Akasha, com a finalidade de

aprimorar a performance do sistema;

• Implementar outros gráficos como, por exemplo, gráficos 3D, ou outros que

sejam considerados úteis na compreensão e interpretação dos resultados;

• Realizar testes em laboratório para a verificação e validação da precisão

dos cálculos dos modelos utilizados neste projeto;

• Realizar novos testes com o software Akasha para comprovar e otimizar

sua aplicação;

• Aplicar dados utilizados em outros trabalhos de modelagem matemática no

software Akasha para comparação e discussão de resultados.

Referências 57

REFERÊNCIAS

BOEHM, Barry W. A Spiral Model of Software Development and Enhancement.

1988. Disponível em: <http://www.cs.usu.edu/~supratik/CS%205370/r5061.pdf>.

Acesso em: 25 nov. 2008.

BRASIL. Constituição. Constituição da Republica Federativa do Brasil. Brasília,

DF: Senado, 1988.

BRASIL. Lei nº 9.433, de 08 de janeiro de 1997. Institui a Política Nacional de

Recursos Hídricos, cria o Sistema Nacional de Gerenciamento de Recursos

Hídricos, regulamenta o inciso XIX do art. 21 da Constituição Federal, e altera o

art. 1º da Lei nº 8.001, de 13 de março de 1990, que modificou a Lei nº 7.990, de

28 de dezembro de 1989. Brasília: Diário Oficial da República Federativa do Brasil,

1997.

BRASIL. Lei nº 6.938, de 31 de agosto de 1981. Dispõe sobre a Política Nacional

do Meio Ambiente, seus fins e mecanismos de formulação e aplicação, e dá

outras providências. Brasília: Diário Oficial da República Federativa do Brasil,

1981.

COMPANHIA DE TECNOLOGIA DE SANEAMENTO AMBIENTAL DO ESTADO DE

SÃO PAULO (CETESB). Manual de Gerenciamento de Áreas Contaminadas /

CETESB, GTZ – 2 ed. – São Paulo: CETESB, 2001.


SÃO PAULO (CETESB). Solo. Disponível em:

<http://www.cetesb.sp.gov.br/Solo/solo/poluicao.asp>. Acesso em: 3 mar. 2008.


SÃO PAULO (CETESB). Valores Orientadores para Solo e Água Subterrânea no

Estado de São Paulo. CETESB, São Paulo - SP, 2005.

CONSELHO NACIONAL DO MEIO AMBIENTE – CONAMA. Resolução nº 357 de

17/03/2005.

Referências 58

FILHO, Manuel Alves. Modelo Matemático desenvolvido na UNICAMP avalia

desastre Ambiental. Jornal da Unicamp. Disponível em:

<http://www.unicamp.br/unicamp/unicamp_hoje/ju/junho2003/ju216pg11a.html>.

Acesso em: 25 fev. 2008.

INTERNATIONAL ORGANISATION FOR STANDARDISATION – International ISO

DIS 9241-11 - Ergonomic requirements for office work with visual display

terminals (VDTs) / Part 11: Guidance on Usability. Disponível em:

<http://www.usability.ru/sources/iso9241-11.htm>. Acesso em: 11 set. 2008.

JAVA CHARTS. Chart. Disponível em:

<http://www.java2s.com/Code/Java/Chart/CatalogChart.htm>. Acesso em: 03 ago.

2008.

JAVA CODE CONVENTIONS. Disponível em :

<http://java.sun.com/docs/codeconv/CodeConventions.pdf>. Acesso em: 14 jul.

2008.

JFREE.ORG. JFreeChart. Disponível em: <http://www.jfree.org>. Acesso em: 15

ago. 2008.

JONES, Steven; NEFF, Ken. An Introduction to Java: What Non-Developers

Need to Know. Novell, 1997. Disponível em:

<http://support.novell.com/techcenter/articles/ana19970701.html>. Acesso em 15 jun.

2008.

MINISTÉRIO DA SAÚDE. Preservação Ambiental: uma questão de saúde.

Disponível em: <http://portal.saude.gov.br/saude/visualizar_texto.cfm?idtxt=21030>.

Acesso em: 05 set. 2008.

MINISTÉRIO DA SAÚDE. Portaria nº 518 de 25/03/2004.

MOREIRA, Davidson, TIRABASSI, Tiziano. Modelo Matemático de Dispersão de

Poluentes na Atmosfera: Um Instrumento Técnico para a Gestão Ambiental.

Campinas, 2004.

Referências 59

NIELSEN, Jakob. How to Conduct a Heuristic Evaluation. Disponível em:

<http://www.useit.com/papers/heuristic/heuristic_evaluation.html>. Acesso em: 07

out. 2008.

NIELSEN, Jakob. Ten Usability Heuristics. Disponível em:

<http://www.useit.com/papers/heuristic/heuristic_list.html>. Acesso em: 07 out. 2008.

NIELSEN, Jakob. Usability 101: Introduction to Usability. Disponível em:

<http://www.useit.com/alertbox/20030825.html>. Acesso em: 10 set. 2008.

SÁNCHES, Luis Enrique. Desengenharia: O Passivo Ambiental na Desativação de

Empreendimentos Industriais. São Paulo, 2001.

SANTOS, Eimmy Machado dos. A Vala Séptica da Cidade Industrial de Curitiba –

Um Estudo de Caso, 2008, Trabalho de Conclusão do Curso de Graduação em

Tecnologia em Química Ambiental – Departamento de Química e Biologia,

Universidade Tecnológica Federal do Paraná, Curitiba, 188 p.

SCHIANETZ, Bojan. Passivos ambientais. SENAI, Curitiba - PR, 1999.

TACLA, Cesar Augusto. Tecnologia de Orientação a Objetos. Disponível em:

<http://www.dainf.ct.utfpr.edu.br/~tacla/Tecno-OO/>. Acesso em: 20 jul. 2008.

U.S. ENVIRONMENTAL PROTECTION AGENCY. HSSM – Hydrocarbon Spill

Screening Model. Disponível em:

<http://www.epa.gov/ada/csmos/models/hssmwin.html>. Acesso em: 19 mar. 2008.

U.S. GEOGICAL SURVEY. MODFLOW. Disponível em:

<http://water.usgs.gov/nrp/gwsoftware/modflow.html>. Acesso em: 19 mar. 2008.

VENTURIERI, Alberto Vieira; A Utilização de Ferramenta Numérica para a

Modelagem do Fluxo dos Contaminantes no Subsolo do Lixão do Aurá. Belém

– PA, 2001.

VIGISOLO. Paraná. Disponível em:

<http://portal.saude.gov.br/SAUDE/visualizar_texto.cfm?idtxt=23756>. Acesso em:

02 set. 2008.

Referências 60

VIGISOLO. Resultados das Ações de Identificação Realizadas em 2004/2005.

Disponível em:<http://portal.saude.gov.br/SAUDE/visualizar_texto.cfm?idtxt=26236>.

Acesso em: 02 set. 2008.

WIKIMETRO. Desenvolvimento de Software. Disponível em:

<http://wiki.labmetro.ufsc.br/tiki-index.php?page=Desenvolvimento+de+Software>.

Acesso em: 25 jun. 2008.

WIKIMETRO. Documentação do Software. Disponível em:

<http://wiki.labmetro.ufsc.br/tiki-index.php?page=Documenta%C3%A7%C3%A3o+do

+ Software>. Acesso em: 25 jun. 2008.

WHARTON, Cathleen; RIEMAN, John; LEWIS. Clayton; POLSON, Peter. The

Cognitive Walkthrough Method: A Practitioner’s Guide. New York – NY, 1994.

Apêndice

APÊNDICE

Tópicos de ajuda

Como efetuar os cálculos

1) Selecione o modelo disponível.

Pode-se selecionar o modelo no início do programa, na janela de seleção de

modelos:

Ou selecionando a opção "Novo arquivo" no menu "Arquivo":

Ou clicando sobre o botão na barra de ferramentas:

2) Preencha corretamente todos os campos solicitados no formulário e clique no

botão "Calcular".

Apêndice

Caso ocorram erros ou omissões durante o preenchimento do formulário, o

programa os detectará e alertará através de mensagens e alterações na cor dos

campos que contêm erros.

Como construir os gráficos

1) Selecione o modelo disponível.

Pode-se selecionar o modelo no início do programa, na janela de seleção de

modelos:

Ou selecionando a opção "Novo arquivo" no menu "Arquivo":

Apêndice


2) Selecione uma das variáveis para ser calculada, na aba “Dados Iniciais”.

3) Preencha corretamente todos os valores solicitados no formulário.

OBS: Não é necessário realizar o cálculo da variável para construir o gráfico.

Basta apenas preencher o formulário corretamente.

4) Selecione o tipo de gráfico, na aba “Previsão Gráfica”.

5) Informe os valores solicitados para a construção do gráfico e em seguida clique

no botão “Construir gráfico”.

Caso ocorram erros ou omissões durante o preenchimento do formulário, o

programa os detectará e alertará através de mensagens e alterações na cor dos

campos que contêm erros.

Apêndice

Como abrir e salvar arquivos

Para salvar um arquivo contendo os dados informados ao programa durante

sua utilização, basta selecionar a opção “Salvar”, no menu “Arquivo”:

Ou ainda clicar sobre o botão na barra de ferramentas:

Para abrir um arquivo, basta selecionar a opção “Abrir arquivo”, no menu

“Arquivo”:

Ou clicar sobre o botão na barra de ferramentas:

Apêndice

Como abrir um novo formulário

Caso deseje manter o trabalho realizado até o momento, basta clicar na opção

“Novo arquivo”, no menu “Arquivo”:


Então uma nova janela contendo a interface inicial será disponibilizada,

mantendo a janela aberta anteriormente em funcionamento.

Caso deseje descartar o trabalho já realizado para recomeçar, selecione a

opção “Fechar”, no menu “Arquivo”:

E em seguida a opção “Novo arquivo”, também no menu “Arquivo”, ou clicando

sobre o botão na barra de ferramentas.

AUTORIZAÇÃO

Autorizamos a reprodução e/ou divulgação total ou parcial da presente obra,

por qualquer meio convencional ou eletrônico, desde que citada a fonte.

Nome do autor: Fabio Batista

Assinatura do autor: ____________________________

Nome da autora: Fernanda Damaceno Tavares

Assinatura da autora: ___________________________

Instituição: Universidade Tecnológica Federal do Paraná

Local: Curitiba, Paraná

E-mail: [email protected]

E-mail: [email protected]

Documents

ELABORAÇÃO DE UM SOFTWARE PARA ESTIMAR A PROPAGAÇÃO DE UM ...cristina/SoftwareQuimica.pdf · ilimitado. Porém, essa realidade já é bem diferente. A Lei 9.433 instituiu que