ELABORAÇÃO DE UM SOFTWARE PARA ESTIMAR A PROPAGAÇÃO DE UM ...cristina/SoftwareQuimica.pdf ·...
Transcript of ELABORAÇÃO DE UM SOFTWARE PARA ESTIMAR A PROPAGAÇÃO DE UM ...cristina/SoftwareQuimica.pdf ·...
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
FERNANDA DAMACENO TAVARES
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
FERNANDA DAMACENO TAVARES
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).
Capítulo 1 – Introdução 2
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.
Capítulo 1 – Introdução 3
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.
Capítulo 2 – Revisão Bibliográfica 5
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;
Capítulo 2 – Revisão Bibliográfica 6
Figura 1 – Mapa das áreas com população sob risco de exposição a resíduos perigosos na RMC. Fonte: Modificado de VIGISOLO (2005)
Capítulo 2 – Revisão Bibliográfica 7
Figura 2 – Mapa das áreas com população sob risco de exposição a resíduos perigosos na RMC. Fonte: Modificado de VIGISOLO (2005)
Capítulo 2 – Revisão Bibliográfica 8
• 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;
Capítulo 2 – Revisão Bibliográfica 9
Figura 3 – Fluxograma das etapas do gerenciamento de ACs Fonte: Modificado de CETESB (2001)
Capítulo 2 – Revisão Bibliográfica 10
• 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)
Capítulo 2 – Revisão Bibliográfica 11
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.
Capítulo 2 – Revisão Bibliográfica 12
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.
Capítulo 2 – Revisão Bibliográfica 13
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.
Capítulo 2 – Revisão Bibliográfica 14
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;
Capítulo 2 – Revisão Bibliográfica 15
• 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
Capítulo 2 – Revisão Bibliográfica 16
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:
Capítulo 2 – Revisão Bibliográfica 17
• 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;
Capítulo 2 – Revisão Bibliográfica 18
• 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:
Capítulo 2 – Revisão Bibliográfica 19
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?
Capítulo 2 – Revisão Bibliográfica 20
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
Capítulo 2 – Revisão Bibliográfica 21
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)
Capítulo 2 – Revisão Bibliográfica 22
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.
Capítulo 2 – Revisão Bibliográfica 23
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.
Capítulo 3 – Metodologia 25
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.
Capítulo 3 – Metodologia 26
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.
Capítulo 3 – Metodologia 27
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.
Capítulo 4 – Resultados e Discussão 29
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.
Capítulo 4 – Resultados e Discussão 30
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.
Capítulo 4 – Resultados e Discussão 31
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
Capítulo 4 – Resultados e Discussão 32
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
Ator Envolvido Usuário
Pré-condições Sessão iniciada
Pós-condições Arquivo salvo no sistema
Fluxo básico
Ator Sistema
Solicitar salvamento Sistema salva o arquivo
{fim}
O caso de uso termina
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
Ator Envolvido Usuário
Pré-condições Sessão iniciada
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}
O caso de uso termina
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
Capítulo 4 – Resultados e Discussão 33
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.
Ator Envolvido Usuário
Pré-condições Sessão iniciada
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}
O caso de uso termina
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;
Capítulo 4 – Resultados e Discussão 34
• 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.
Capítulo 4 – Resultados e Discussão 35
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
Capítulo 4 – Resultados e Discussão 36
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
Capítulo 4 – Resultados e Discussão 37
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.
Capítulo 4 – Resultados e Discussão 38
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
Capítulo 4 – Resultados e Discussão 39
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.
Capítulo 4 – Resultados e Discussão 40
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.
Capítulo 4 – Resultados e Discussão 41
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
Capítulo 4 – Resultados e Discussão 42
Figura 24 – Tela do Item Tópicos de Ajuda
Figura 25 – Tela do Item Sobre o Akasha
Capítulo 4 – Resultados e Discussão 43
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.
Capítulo 4 – Resultados e Discussão 44
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
Capítulo 4 – Resultados e Discussão 45
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.
Capítulo 4 – Resultados e Discussão 46
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)
Capítulo 4 – Resultados e Discussão 47
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)
Capítulo 4 – Resultados e Discussão 48
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.
Capítulo 4 – Resultados e Discussão 49
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.
Capítulo 4 – Resultados e Discussão 50
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
Capítulo 4 – Resultados e Discussão 51
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.
Capítulo 4 – Resultados e Discussão 52
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.
Capítulo 4 – Resultados e Discussão 53
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
Capítulo 4 – Resultados e Discussão 54
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.
COMPANHIA DE TECNOLOGIA DE SANEAMENTO AMBIENTAL DO ESTADO DE
SÃO PAULO (CETESB). Solo. Disponível em:
<http://www.cetesb.sp.gov.br/Solo/solo/poluicao.asp>. Acesso em: 3 mar. 2008.
COMPANHIA DE TECNOLOGIA DE SANEAMENTO AMBIENTAL DO ESTADO DE
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
Ou clicando sobre o botão na barra de ferramentas:
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”:
Ou clicando sobre o botão na barra de ferramentas:
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]