UNIVERSIDADE DO VALE DO ITAJAÍ
CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
SISTEMA DE DIVULGAÇÃO DE DADOS METEOROLÓGICOS
Área de Sistemas de Informação
por
Fernando Silveira de Quadro
Adriana Gomes Alves, M. Eng.
Orientador
Sergey Alex de Araújo, M. Sc.
Co-orientador
Itajaí (SC), junho de 2005
UNIVERSIDADE DO VALE DO ITAJAÍ
CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
SISTEMA DE DIVULGAÇÃO DE DADOS METEOROLÓGICOS
Área de Sistemas de Informação
por
Fernando Silveira de Quadro
Relatório apresentado à Banca Examinadora do
Trabalho de Conclusão do Curso de Ciência da
Computação para análise e aprovação.
Orientador: Adriana Gomes Alves, M. Eng.
Itajaí (SC), junho de 2005
i
EQUIPE TÉCNICA
Acadêmico
Fernando Silveira de Quadro
Professor Orientador
Adriana Gomes Alves, M.Eng
Professor Co-Orientador
Sergey Alex de Araújo, M.Sc
Coordenadora dos Trabalhos de Conclusão de Curso
Anita Maria da Rocha Fernandes, Dr ª. Eng.
Cesar Albenes Zeferino, Dr.
Coordenador do Curso
Luis Carlos Martins, Esp.
ii
DEDICATÓRIA
Dedico este trabalho a meus pais
Antonio Taurino de Quadro, Laci Silveira de Quadro
e a minha namorada Danielle Azevedo pelo apoio e
por acreditarem em mim desde o início.
iii
AGRADECIMENTOS
A Deus, que posso confiar sempre.
Aos meus pais, pela dedicação, amor, confiança, e por sempre me incentivarem e me apoiarem
em todas as decisões no decorrer da minha vida.
A minha namorada Danielle, que nos momentos mais difíceis esteve comigo me dando força e
em nenhum momento me deixou desanimar.
A todos os professores pelos ensinamentos ao longo destes anos. Em especial, a Professora
Adriana, minha orientadora que acreditou no meu potencial e sempre me incentivou.
Ao professor Sergey meu co-orientador pelo auxílio no desenvolvimento deste trabalho.
Ao Professor Carlos Henrique Bughi, pela paciência e pelo interesse com o qual me ajudou neste
trabalho.
A todos os meus amigos que me ajudaram, me incentivaram e me apoiaram nos momentos
difíceis, em especial a Felipe Farias, Rafael Mueller, Danilo Nunes. E também, aqueles que de
alguma forma contribuíram para a realização deste trabalho.
Aos colegas, tanto aqueles que ficaram no decorrer do curso, como aos que conseguiram junto
comigo chegar ao fim de mais uma etapa de nossas vidas.
Muito Obrigado!
iv
SUMÁRIO
LISTA DE ABREVIATURAS.................................................................vii
LISTA DE FIGURAS................................................................................ix
LISTA DE TABELAS ................................................................................ x
RESUMO...................................................................................................xii
ABSTRACT..............................................................................................xiii
1. INTRODUÇÃO ...................................................................................... 1
1.1. OBJETIVOS ..................................................................................................... 2
1.1.1. Objetivo Geral................................................................................................ 2
1.1.2. Objetivos Específicos...................................................................................... 2
1.2. METODOLOGIA............................................................................................. 3
1.3. ESTRUTURA DO TRABALHO ..................................................................... 4
2. FUNDAMENTAÇÃO TEÓRICA ........................................................ 5
2.1. CLIMATOLOGIA ........................................................................................... 5
2.2. LABORATÓRIO DE CLIMATOLOGIA ...................................................... 6
2.3. PORTAIS ........................................................................................................ 12
2.3.1. Classificação dos Portais.............................................................................. 14
2.4. WEB SERVICES............................................................................................ 16
2.4.1. XML.............................................................................................................. 18
2.4.2. SOAP ............................................................................................................ 21
2.4.3. WSDL ........................................................................................................... 24
2.4.4. UDDI ............................................................................................................. 29
2.5. FERRAMENTAS PARA O PROJETO ........................................................ 30
2.5.1. PHP ............................................................................................................... 30
2.5.2. PostgreSQL................................................................................................... 31
2.6. CONSIDERAÇÕES ....................................................................................... 32
3. DESENVOLVIMENTO ...................................................................... 33
3.1. REQUISITOS DO SISTEMA........................................................................ 33
3.1.1. Requisitos Funcionais .................................................................................. 33
3.1.2. Requisitos Não Funcionais........................................................................... 34
3.1.3. Regras de Negócio ........................................................................................ 34
3.2. DIAGRAMA DE ATIVIDADES ................................................................... 35
3.3. FUNCIONALIDADES DO SISTEMA.......................................................... 41
3.4. DIAGRAMA DE CASOS DE USO ............................................................... 43
3.5. DIAGRAMA DE CLASSES .......................................................................... 46
3.6. MODELAGEM DE DADOS.......................................................................... 48
3.7. IMPLEMENTAÇÃO ..................................................................................... 48
3.7.1. Área Restrita ................................................................................................ 48
3.7.2. Área Pública ................................................................................................. 51
3.7.3. Web Service .................................................................................................. 53
3.7.4. Importação de dados das estações............................................................... 56
4. CONSIDERAÇÕES FINAIS .............................................................. 57
REFERÊNCIAS BIBLIOGRÁFICAS ................................................... 58
GLOSSÁRIO............................................................................................. 61
APÊNDICE A – PCT01 ARMAZENAMENTO DE DADOS.............. 65
APÊNDICE B – PCT02 ADMINISTRAÇÃO DO SISTEMA............. 67
APÊNDICE C – PCT03 ÁREA PÚBLICA............................................ 79
APÊNDICE D – PCT04 WEB SERVICES............................................ 82
APÊNDICE E – MODELAGEM DOS DADOS ................................... 83
APÊNDICE F – ARQUIVO WSDL........................................................ 90
ANEXO I – ARTIGO ............................................................................... 91
vi
LISTA DE ABREVIATURAS
AOL
API
CGI
CTTMAR
DTD
EAI
FI
FTP
GOES
HTML
HTTP
IMAP
INMET
INPE
IP
J2EE
JAXB
JAXP
JSP
MIME
MVCC
NOAA
ODBC
OSI
PHP
POP3
POSIX
SGBD
SI
SMTP
SNMP
SOAP
SQL
SSL
TCC
TCP
TI
UDDI
UDDI4J
UML
UNIVALI
UOL
URI
URL
UTC
W3C
América On Line
Application Programming Interface
Common Gateway Interface
Centro de Ciências Tecnológicas da Terra e do Mar
Document Type Definition
Enterprise Application Integration
Form Interpreter
File Transfer Protocol
Geostationary Operational Environmental Satellites
Hipertext Markup Language
Hipertext Transfer Protocol
Internet Message Access Protocol
Instituto Nacional de Meteorologia
Instituto Nacional de Pesquisas Espaciais
Internet Protocol
Java to Plataform Enterprise Edition
Java API for XML Binding
Java API for XML Processing
Java Server Pages
Multipurpose Internet Mail Extensions
Multi Version Competition Control
National Oceanic and Atmospheric Administration
Open Database Conectivity
Open Systems Interconnection
Hypertext Preprocessor
Post Office Protocol version 3
Portable Operation System Interface
Sistema Gerenciador de Banco de Dados
Sistemas de Informação
Simple Mail Transfer Protocol
Simple Network Management Protocol
Simple Object Access Protocol
Structured Query Language
Secure Socket Layer
Trabalho de Conclusão de Curso
Transmission Control Protocol
Tecnologia de Informação
Universal Description, Discovery and Integration
Universal Description, Discovery and Integration for Java
Unified Modeling Language
Universidade do Vale do Itajaí
Universo On Line
Uniform Resource Identifier
Uniform Resource Locator
Universal Time Coordenate
World Wide Web Consortium
WSDL
WSDP
WWW
XML
XSL
Web Services Description Language
Web Services Developer Pack
World Wide Web
Extensible Markup Language
Extensible Stylesheet Language
viii
LISTA DE FIGURAS
Figura 1. Arquivo gerado pela estação meteorológica ......................................................................8
Figura 2. Imagem do satélite............................................................................................................9
Figura 3. Planilha com os dados da previsão marítima ..................................................................10
Figura 4. Website com os dados meteorológicos............................................................................11
Figura 5. Portal do UOL ................................................................................................................12
Figura 6. Funcionamento simplifcado de um Web service .............................................................18
Figura 7. Exemplo de um documento XML ...................................................................................20
Figura 8. Formato da mensagem SOAP .........................................................................................22
Figura 9. Operações básicas que usam a WSDL.............................................................................25
Figura 10. Exemplo de declaração de um definitions de um documento WSDL.............................26
Figura 11. Exemplo de definição de um types................................................................................26
Figura 12. Exemplo de definição de um message...........................................................................27
Figura 13. Sintaxe do operation e portType ...................................................................................28
Figura 14. Sintaxe do elemento binding.........................................................................................28
Figura 15. Sintaxe dos elementos service e port.............................................................................29
Figura 16. Diagrama de Atividades da estação antes do sistema proposto ......................................36
Figura 17. Diagrama de Atividades das estações após o sistema proposto......................................37
Figura 18. Diagrama de Atividades das previsões antes do sistema proposto .................................38
Figura 19. Diagrama de atividades das previsões após o sistema proposto .....................................39
Figura 20. Diagrama de Pacotes dos casos de uso do sistema.........................................................42
Figura 21. Pacote Armazenamento de Dados .................................................................................43
Figura 22. Pacote da Administração do Sistema.............................................................................44
Figura 23. Pacote Área Pública......................................................................................................45
Figura 24. Pacote Webservice ........................................................................................................46
Figura 25. Diagrama de classes do Framework ..............................................................................47
Figura 26. Tela de listagem dos dados ...........................................................................................49
Figura 27. Tela de detalhes de itens ...............................................................................................50
Figura 28. Tela de cadastro de dados .............................................................................................51
Figura 29. Home page do Laboratório de Climatologia..................................................................52
Figura 30. Layout da previsão do tempo ........................................................................................53
Figura 31. Tela de login para acessar o Web Service .....................................................................54
Figura 32. Tela de resultados do Web Service................................................................................55
Figura 33. Tela do código fonte de uma solicitação cliente ao Web Service ...................................55
LISTA DE TABELAS
Tabela 1. Limites do banco de dados PostgreSQL..........................................................................32
Tabela 2. Funcionalidades do pacote Armazenamento de Dados....................................................44
Tabela 3. Funcionalidades do pacote Administração do Sistema....................................................44
Tabela 4. Funcionalidades do pacote Área pública.........................................................................45
Tabela 5. Funcionalidades do pacote Web service..........................................................................46
Tabela 6. Classes do Framework ...................................................................................................46
Tabela 7. Descrição da tabelas utilizadas no sistema......................................................................48
Tabela 8. Descrição do Caso de Uso Armazena Imagens do Globo................................................65
Tabela 9. Descrição do Caso de Uso Armazena Dados Meteorológicos .........................................65
Tabela 10. Descrição do Caso de Uso Manutenção de Usuários.....................................................67
Tabela 11. Descrição do Caso de Uso Fazer Previsão do Tempo....................................................68
Tabela 12. Descrição do Caso de Uso Fazer Previsão Marítima .....................................................69
Tabela 13. Descrição do Caso de Uso Geração de Relatórios.........................................................70
Tabela 14. Descrição do Caso de Uso Login..................................................................................70
Tabela 15. Descrição do Caso de Uso Recados ..............................................................................71
Tabela 16. Descrição do Caso de Uso Armazena Fases da Lua ......................................................72
Tabela 17. Descrição do Caso de Uso Visualiza Criticas e Sugestões.............................................73
Tabela 18. Descrição do Caso de Uso Tábuas da Maré ..................................................................74
Tabela 19. Descrição do Caso de Uso Região ................................................................................74
Tabela 20. Descrição do Caso de Uso Áreas ..................................................................................75
Tabela 21. Descrição do Caso de Uso Por do Sol...........................................................................76
Tabela 22 Descrição do Caso de Uso Satélite ................................................................................77
Tabela 23 Descrição do Caso de Uso Estação ................................................................................78
Tabela 24. Descrição do Caso de Uso Visualiza Previsão do Tempo..............................................79
Tabela 25. Descrição do Caso de Uso Visualiza Previsão Marítima ...............................................79
Tabela 26. Descrição do Caso de Uso Consulta Dados Meteorológicos .........................................79
Tabela 27. Descrição do Caso de Uso Consulta Imagens do Satélite ..............................................80
Tabela 28. Descrição do Caso de Uso Consulta Pôr do Sol ............................................................80
Tabela 29. Descrição do Caso de Uso Fases da Lua .......................................................................80
Tabela 30. Descrição do Caso de Uso Envia Criticas e Sugestões ..................................................81
Tabela 31. Descrição do Caso de Uso Visualiza Recados...............................................................81
Tabela 32. Descrição do Caso Solicita dados meteorológicos ........................................................82
Tabela 33. Dicionário de dados da tabela tb_dados_meteorologicos ..............................................83
Tabela 34. Dicionário de dados da tabela tb_fases_da_lua .............................................................85
Tabela 35. Dicionário de dados da tabela tb_imagens_satelite .......................................................85
Tabela 36. Dicionário de dados da tabela tb_tipo_imagem.............................................................85
Tabela 37. Dicionário de dados da tabela tb_log ............................................................................85
Tabela 38. Dicionário de dados da tabela tb_por_do_sol................................................................86
Tabela 39. Dicionário de dados da tabela tb_previsao_maritima ....................................................86
Tabela 40. Dicionário de dados da tabela tb_dados_maritima ........................................................86
Tabela 41. Dicionário de dados da tabela tb_previsao_tempo ........................................................87
Tabela 42. Dicionário de dados da tabela tb_recados .....................................................................87
Tabela 43. Dicionário de dados da tabela tb_area...........................................................................87
Tabela 44. Dicionário de dados da tabela tb_regiao .......................................................................87
Tabela 45. Dicionário de dados da tabela tb_tabua_mare ...............................................................87
Tabela 46. Dicionário de dados da tabela arquivo ..........................................................................87
Tabela 47. Dicionário de dados da tabela modulos.........................................................................88
Tabela 48. Dicionário de dados da tabela arq_mod ........................................................................88
Tabela 49. Dicionário de dados da tabela conexoes........................................................................88
Tabela 50. Dicionário de dados da tabela operadores .....................................................................88
Tabela 51. Dicionário de dados da tabela permissoes.....................................................................89
Tabela 52. Dicionário de dados da tabela tb_contato......................................................................89
xi
RESUMO
QUADRO, Fernando Silveira de. Sistema de divulgação de dados meteorológicos. Itajaí, 2004.
105 f. Trabalho de Conclusão de Curso (Graduação em Ciência da Computação)–Centro de
Ciências Tecnológicas da Terra e do Mar, Universidade do Vale do Itajaí, Itajaí, 2004.
A meteorologia nos dias de hoje atingiu um grau de maturidade nas sociedades mais desenvolvidas,
como conseqüência do avanço tecnológico e metodologias mais condizentes. Desta forma,
possibilitou um nível de acerto maior nos seus prognósticos, levando a uma maior confiabilidade. O
Centro de Ciências Tecnológicas da Terra e do Mar (CTTMar) que já dispõe de infra-estrutura à
Climatologia e Meteorologia, inicialmente centrada ao ensino e posteriormente à pesquisa e
extensão, assumiu uma postura moderna de contribuir para o aperfeiçoamento e divulgação destas
tecnologias em prol da sociedade catarinense. Este trabalho tem como objetivo apresentar o projeto
de um sistema de informações para o Laboratório de Climatologia da UNIVALI, Itajaí – Santa
Catarina. O Laboratório não possuia um sistema de informações, e sim alguns software que
auxiliam no cumprimento das suas necessidades, demonstrando pouca flexibilidade. O sistema de
informações proposto e implementado neste trabalho organizou todas as informações do laboratório
em um banco de dados, reformulou a interface do sistema introduzindo a possiilidade de usar a web
e ainda e ainda disponibilizou informações através de um Web service.
Palavras-chave: Sistemas de Informações. Web Services. Dados Meteorológicos.
ABSTRACT
Nowadays the meteorology reached a degree of maturity in the societies more developed, as
consequence of the technological progress and more suitable methodologies. In a way, it turned
possible a level of bigger success in its prognostics, taking to a larger reliability. The Center called
CTTMar that has already disposed of infrastructure to the Climatology and Meteorology, initially
centered to the teaching and later to the research and extension, it assumed a modern posture of
contributing for the improvement and popularization of these technologies on behalf of the society
of “Santa Catarina” state. This work has as objective presents the project of an information system
to the Climatology Laboratory of UNIVALI, Itajaí–Santa Catarina, in the intention of supplying
needs of informatization of collection procedures and popularization of climatological data,
including weather forecast and tides. The system proposes the systematization of the data collection
of the meteorological station and of the satellite images and data, feeding a meteorology and
climatology database. The information of the database will be available in a dynamic web page,
and also through a webservice for supplying of meteorological and climatological data.
Keywords: Information System. Web Services. Meteorology Data.
1. INTRODUÇÃO
A meteorologia nos dias de hoje atingiu um grau de maturidade nas sociedades mais
desenvolvidas, como conseqüência do avanço tecnológico e metodologias mais condizentes. Desta
forma, possibilitou um nível de acerto maior nos seus prognósticos, levando a uma maior
confiabilidade. Como conseqüência, a sociedade passou a consumir seus produtos para as mais
diversas aplicações, como a verificação da previsão do tempo para um simples passeio até a
influenciar atividades mais complexas do campo econômico.
O Centro de Ciências Tecnológicas da Terra e do Mar (CTTMar) dispõe de infra-estrutura
para estudos de Climatologia e Meteorologia, inicialmente centrada ao ensino e posteriormente à
pesquisa e extensão. Ela assumiu uma postura moderna de contribuir para o aperfeiçoamento e
divulgação destas tecnologias em prol da sociedade catarinense, buscando parcerias com órgãos
importantes no desenvolvimento da meteorologia no Brasil, como o Instituto Nacional de
Meteorologia (INMET), Instituto Nacional de Pesquisas Espaciais (INPE) e empresas do setor
privado com experiência reconhecida na área, como a CLIMATERRA (empresa de
agrometeorologia).
O Laboratório de Climatologia da UNIVALI trata os dados da previsão do tempo, previsão
marítima e ainda trabalha com a captação de imagens de satélite. Como esses dados meteorológicos
são usados não só para divulgação via Web, mas também para a pesquisa, é necessário que eles
sejam armazenados de forma organizada, para ser possível acompanhar os eventos que acontecem e
possibilitar prognósticos no que tange as áreas climatológica e meteorológica.
O modelo proposto nesse projeto visou a organização dos dados meteorológicos e
climatológicos em uma base de dados, que proporcionou um melhor aproveitamento, dado o fato de
que os dados eram armazenados em formato texto. As informações organizadas estão auxiliando o
Laboratório de Climatologia na avaliação homogênea dos fatores climáticos e meteorológicos da
região.
A criação de um banco de dados permitiu a criação de um acervo histórico dos dados
meteorológicos, o que já existia, mas a sistematização adotada dificultava o acesso, consulta e uso.
Adicionalmente foi implementado um Web Service para disponibilizar os dados
armazenados e processados. Esta tecnologia foi escolhida pois apresenta vantagens como a
interoperabilidade, integração, eficiência de implementação, reciclagem de código e modularidade.
1.1. OBJETIVOS
1.1.1. Objetivo Geral
O objetivo deste trabalho é desenvolver um sistema de informações para o Laboratório de
Climatologia para organizar e divulgar os dados meteorológicos através de um portal Web e de
Web services.
1.1.2. Objetivos Específicos
Os objetivos específicos deste projeto de pesquisa são:
Pesquisar referências bibliográficas na área de divulgação de dados meteorológicos,
linguagens existentes para implementação e os conceitos do desenvolvimento e
aplicação dos Web Services;
Desenvolver a análise de requisitos e o modelo do sistema;
Desenvolver um banco de dados para armazenar os dados;
Criar um mecanismo para importar os dados atuais; e
Desenvolver o Web Service para a interoperabilidade de sistemas.
2
1.2. METODOLOGIA
As etapas para o cumprimento dos objetivos propostos são descritas em seguida.
Redação Pré-Proposta: exposto panorama geral do projeto de conclusão do Curso de
Ciências da Computação, objetivos, justificativas, importância, definição de critérios;
Levantamento Bibliográfico: O trabalho iniciou com a pesquisa de material bibliográfico:
livros, artigos, periódicos, teses, internet, com o propósito de fundamentar teoricamente as
tecnologias que deveriam ser abordadas no trabalho, e entrevistas com o co-orientador, que
é o responsável pelo Laboratório de Climatologia.
Revisão Bibliográfica: Confecção da monografia, utilizando o levantamento bibliográfico
realizado na etapa anterior, as fundamentações e conceituações sobre as tecnologias que
foram selecionadas para o desenvolvimento do trabalho, bem como o conhecimento
adquirido durante a pesquisa. Nesta etapa, houve então a fundamentação teórica do trabalho.
Este período foi acompanhado por reuniões semanais com o orientador, co-orientador e por
relatórios quinzenais entregues à coordenação do TCC.
Pré-modelagem da aplicação: Esboço geral do projeto, juntamente com os principais
serviços a serem disponibilizados.
Análise do Projeto: Análise do sistema bem como a modelagem do banco. Foi utilizada a
linguagem de modelagem UML (Unified Modeling Language), sendo que, o banco de dados
teve a aplicação de regras de mapeamento do modelo orientado a objetos, utilizado pela
UML, para o modelo relacional/objeto-relacional dos Bancos de Dados tradicionais. O
banco de dados foi modelado com base nas informações colhidas no Laboratório de
Climatologia. Esses dados foram definidos em reuniões com o professor responsável a fim
de atender as funcionalidades propostas; e
Preparação para Apresentação Banca TCC1: refinar conteúdo e estudar apresentação do
trabalho.
Implementação: Usar a análise para o desenvolvimento do sistema, seguindo os requisitos e
as regras de negócios estabelecidas.
3
Validação: Realizado o processo de validação do sistema com o auxílio do professor
responsável pelo Laboratório de Climatologia.
Preparação para Apresentação Banca TCC2: refinar conteúdo e estudar apresentação do
trabalho.
1.3. ESTRUTURA DO TRABALHO
Este trabalho trata de um sistema de informações que pretende ajudar o processamento e a
manutenção dos serviços providos pelo Laboratório de Climatologia.
Para isto, a primeira etapa do trabalho compreende um levantamento bibliográfico sobre
Climatologia, mais voltado para o Sul do Brasil, que é onde está localizado o Laboratório.
No tópico Laboratório de Climatologia é apresentada uma descrição do laboratório,
descrevendo suas atividades e dando uma visão da estrutura e procedimentos do referido
laboratório.
No tópico Portais, são apresentados os conceitos, classificação e comparações.
No tópico Web Services é feita uma análise do que é um Web service, seu funcionamento,
bem como são detalhadas os padrões XML, WSDL e SOAP que são utilizadas pelos Web Services.
Em seguida são descritas as ferramentas que foram utilizadas para a implementação do
sistema e do Web service.
Finalmente é então apresentado o sistema, mostrando os diagramas de classe, casos de uso,
dicionário dos dados e as telas.
4
2. FUNDAMENTAÇÃO TEÓRICA
2.1. CLIMATOLOGIA
Os modelos voltados para climatologia e meteorologia vêm avançando de forma sistemática
desde a década de 60, principalmente devido aos desenvolvimentos nos conhecimentos de física,
química e matemática ligados aos processos climáticos, bem como na capacidade de computação
instalada, tanto ao nível de hardware como de software.
Segundo Christofoletti (1998) “os modelos de processos climáticos envolvem desde
modelos para a circulação geral da atmosfera até os modelos para balanço hídrico e energético
locais, passando pelos modelos de dinâmica regional das massas de ar e caracterização e previsão
dos tipos de tempo”.
De acordo com Sadourny (1994), o estudo dos mecanismos da mudança climática baseia-se
em modelos de clima numéricos muito complexos. Tais modelos simulam a evolução conjunta do
oceano (correntes, pressão, temperatura, umidade, salinidade, gelos) e da atmosfera (ventos,
pressão, temperatura, umidade, nebulosidade, chuva e neve) na totalidade do globo terrestre.
Conforme Foucault (1993), as inúmeras variações do clima de local para local, determinadas
pelas diferentes combinações dos processos atmosféricos produzem, correspondentemente, um
grande número de tipos climáticos.
Segundo Vianello e Alves (1991), os fatores que atuam sobre os climas explicam duas
diversificações. A circulação geral sobre a América do Sul desempenha papel de destaque tanto no
sentido zonal quanto meridional. Associados aos anticiclones do Atlântico e do Pacífico, à alta da
Bolívia e à baixa do Chaco, às baixas pressões equatoriais e às altas pressões polares, inúmeros
mecanismos ocorrem durante o ano sobre o Brasil, tais como: as invasões de massa de ar frias e
secas, provenientes do Sul, em contraste com massas quentes e úmidas, que caracterizam sistemas
frontais periódicos, e o encontro dos alísios na faixa equatorial, que dá origem à zona de
convergência intertropical, predominante no norte do país. Mecanismos convectivos intensos são
responsáveis por elevados índices pluviométricos, ao mesmo tempo em que atuam como fontes de
energia para atmosfera.
Ao longo do litoral, o aquecimento diferenciado oceano-continente dá origem as brisas, que
combinam com outros fenômenos na formação de chuvas. A Cordilheira dos Andes forma uma
imensa barreira na direção norte-sul e exerce influência sobre o tempo e clima no Brasil. Até o
aquecimento das águas do Pacífico e do Atlântico é capaz de provocar efeitos climáticos apreciáveis
sobre as áreas continentais, especialmente no regime pluvial. Movimentos e descendentes de massa
de ar, nos sentidos zonal e meridional, associa-se ao deslocamento mais rápido ou ao bloqueio dos
sistemas frontais, promovendo chuvas ou secas prolongadas. Ao lado dos fatores de grande escala,
atuam combinadamente, os fatores locais e regionais (VIANELLO e ALVES, 1991).
Na região Sul, além do relevo e da posição geográfica, os sistemas de circulação atmosférica
influenciam bastante na caracterização climática da região Sul que apresenta duas características
próprias: a primeira é a homogeneidade quanto às chuvas e seu regime, e a outra é a umidade
climática (ibidem).
O clima na região Sul é subtropical, conforme a classificação de Strahler, abrange o Brasil
Meridional, porção localizada ao sul do Trópico de Capricórnio, com predominância da massa de ar
tropical atlântica, que provoca chuvas fortes. No inverno, tem freqüência de penetração de frente
polar, dando origem às chuvas frontais com precipitações devidas ao encontro da massa quente com
a fria, ocorre a condensação do vapor de água atmosférico. É a região climaticamente mais regular,
apresentando chuvas bem distribuídas durante todo o ano, e as quatro estações do ano são nítidas, o
calor do verão contrasta-se com as geadas do inverno. É a única região brasileira onde a queda de
neve ocorre, embora seja um fenômeno esporádico (ibidem).
2.2. LABORATÓRIO DE CLIMATOLOGIA
Em 1996, a Universidade do Vale do Itajaí (UNIVALI) adquiriu uma estação de recepção de
imagens de satélites, a qual receberia os sinais dos satélites da série NOAA (National Oceanic and
Atmospheric Administration) e METEOR (órbita polar) e do satélite meteorológico da série GOES
(Geostationary Operational Environmental Satellites), e também uma estação meteorológica
automática com a finalidade de complementar as aulas de Climatologia e Meteorologia.
Em 1998, a estação meteorológica e o satélite de imagens de baixa resolução foram
instalados no Laboratório de Climatologia, quando também foram adquiridos detectores de raios e
termômetros/higrômetros digitais. A implantação deste sistema, principalmente da estação
6
meteorológica, vem propiciando um ganho de qualidade no controle dos prognósticos
meteorológicos.
Estes equipamentos fizeram da UNIVALI, a pioneira no sul do Brasil entre as instituições de
ensino e de outras entidades ligadas à previsão do tempo, pois estações de recepção de imagens de
satélite existem somente na Faculdade de Meteorologia de Pelotas (RS) e na sede do Oitavo Distrito
de Meteorologia (INMET), em Porto Alegre (RS).
A estação meteorológica possui anemômetro (direção e velocidade do vento), coletor de
chuva,
sensor
digital
para
temperatura/umidade/pressão
atmosférica
e
console
de
coleta/visualização/transmissão de dados para microcomputador. Ela dispõe também de um
software que permite fazer a visualização/gravação/exportação dos dados, bem como a geração de
relatórios e gráficos. A estação está configurada para fazer a leitura dos dados de 15 em 15 minutos
e salvá-los a cada 45 minutos. Os dados que constam neste arquivo são: data, horário, índice de
desconforto térmico, temperatura interna/externa (máxima/mínima), índice de resfriamento pelo
vento, umidade, ponto de orvalho, velocidade do vento (máxima do dia), direção do vento, pressão
atmosférica e chuva diária.
A estação de recepção de imagens é composta de duas antenas de recepção: uma para
satélites geo-estacionários de órbita equatorial e outra para satélites de órbita polar, além de um
receptador e decodificador (geo-estacionário) e placa de recepção dos sinais das antenas para
visualização através de software. Este software permite acompanhar a órbita dos satélites, capturar,
gravar, visualizar, exportar e utilizar ferramentas para um refinamento das imagens, sendo que as
imagens recebidas estão num modo de baixa resolução. A estação está configurada para capturar
imagens da América do Sul, e da parte Leste do Globo, nos horários UTC (Universal Time
Coordenate) das 0, 3, 6, 9, 12, 15, 18 e 21 horas.
O antigo sistema operava com vários softwares que trabalham com arquivos formato texto e
arquivos do Microsoft Excel. A estação meteorológica, por exemplo, a cada 15 minutos fazia uma
coleta de dados e armazenava estes em arquivo texto (tipo “txt”). O software desenvolvido por
colaboradores do laboratório, acessava este arquivo e o transformava para um modelo HTML
(Hyper Text Markup Language). Feito isso outro software acessava este arquivo HTML e através de
uma conexão FTP (File Transfer Protocol) disponibiliza-o na Internet. Relatórios mensais e anuais
são gerados a partir da estação meteorológica em formato texto, conforme ilustra a Figura 1.
7
Figura 1. Arquivo gerado pela estação meteorológica
Fonte: Estação Meteorológica - UNIVALI - CTTMar - Itajaí - SC
A previsão do tempo era realizada através de um software desenvolvido em Delphi, que
construía um arquivo HTML a partir de um modelo pré-existente. Essa previsão é feita através da
análise de modelos matemáticos meteorológicos existentes na internet e a mesma não possuía um
acervo histórico, só existindo o arquivo diário que estava publicado no site do Serviço de Previsão
do Tempo On-Line – Litoral de SC (http://www.cttmar.univali.br/~tempo/), e toda vez que se
publicava um novo boletim o anterior era perdido.
O mesmo processo acontecia com as imagens de satélite captadas pela estação de recepção
de imagens de satélite da série GOES e NOAA, conforme mostra a Figura 2.
8
Figura 2. Imagem do satélite
Fonte: Estação Receptora de Imagens de Satélite - UNIVALI - CTTMar - Itajaí - SC
A Previsão Meteorológica Marítima é gerada pelos profissionais do Laboratório com
consulta também a modelos matemáticos meteorológicos e de ondas. Depois desta etapa era
confeccionado um boletim em arquivo do Microsoft Excel (Figura 3), e então salvo em arquivo de
formato HTML e colocado no site do Serviço de Previsão do Tempo. Os boletins eram arquivados
de forma manual para posterior consulta.
9
Figura 3. Planilha com os dados da previsão marítima
Fonte: http://www.cttmar.univali.br/~tempo/
As informações providas dos satélites atendem a acadêmicos, pessoas físicas, jurídicas,
provedores
de
mídia
e
a
(http://www.cttmar.univali.br/~tempo –
comunidade
em
geral
através
da
internet
Figura 4), onde os dados meteorológicos e imagens de
satélites ficam disponíveis. É importante ressaltar que a Previsão do Tempo e a Previsão Marítima
atendem a mais de 700 embarcações pesqueiras que operam no trecho do Rio Grande do Sul ao
Espírito Santo.
Como esses dados, imagens e boletins são usados não só para a divulgação na Web, mas
também para a pesquisa, era necessário que eles fossem armazenados de forma organizada, para
possível recuperação eficiente com o intuito de acompanhar os eventos meteorológicos e condições
de mar.
10
Figura 4. Website com os dados meteorológicos
Fonte: http://www.cttmar.univali.br/~tempo/
Foi identificado que o Laboratório de Climatologia não possuia seus softwares integrados, e
sim vários programas que serviam para dar apoio na geração das páginas da web e FTP (File
Transfer Protocol).
Devido ao fato de que o laboratório não possuía um banco de dados para armazenar as suas
informações, ocasionava o problema de não se ter um histórico de grande parte dos dados
meteorológicos previstos anteriormente.
Como os dados não são tratados de uma forma automatizada, o esforço despendido pela
equipe do Laboratório de Climatologia era muito grande, causando perda de tempo. Desta forma,
acredita-se que a automação desses serviços proporcionou mais tempo para a pesquisa e reduziu o
trabalho operacional.
Desta forma, este trabalho de conclusão de curso criou um sistema de informações para
organizar os dados e procedimentos do Laboratório de Climatologia, automatizando os seus
11
processos, e possibilitando um melhor aproveitamento das informações. Depois da organização
buscou-se a criação de um web service para disponibilizar os dados gerados pela estação
meteorológica, e reformular todo o layout do web site que estva em operação.
2.3. PORTAIS
Esta seção irá apresentar os portais web, conceituado-os, classificando os diferentes tipos
existentes e comparando as diferentes classificações.
São várias as definições para portais, mas a definição que será considerada neste texto é a
seguinte: "Espaço de articulação e comunicação que aglutina oportunidades de acesso a acervo
técnico, administrativo e/ou cultural relacionado à instituição, tema ou setor econômico" (CEM,
2003). A Figura 5, mostra um exemplo de um portal que emprega este conceito.
Figura 5. Portal do UOL
Fonte: http://www.uol.com.br
12
A idéia de portal surgiu nos Estados Unidos da América no ano de 1994. A princípio, a
única e exclusiva função dos portais era guiar os usuários da Internet em sua viagem pela rede. Por
conseqüência, eles reuniam sites e os apresentavam ao usuário, ajudando-o a localizar o conteúdo
desejado. A idéia inicial por trás do portal era ser o lugar por onde começava a ação do internauta,
que, a partir dele poderia construir os roteiros de leitura que desejasse ou o seu próprio hipertexto.
Ou seja, a página de partida para a experiência na Internet é o portal: pesquisa, comunicação,
entretenimento, comunicação (PÓVOA, 2000 apud BARBOSA, 2003).
Os primeiros portais tornaram-se na sua maioria, provedores da Internet buscando atrair o
maior número possível de internautas. Para isso passaram a agrupar os documentos e sites
disponibilizados por eles, e incorporar em seus conteúdos ferramentas que acrescentavam a
individualidade do usuário. Deste modo, surgiram os portais que põem a disposição diversos
assuntos, cabendo ao usuário decidir qual quer visitar. Segundo Barbosa (2003), a etapa seguinte,
foi a junção de outras funções, como comunidades virtuais e suas listas de discussão, chats em
tempo real, possibilidade de personalização dos sites de busca, assim como acesso a conteúdos
especializados.
O aumento dos usuários da Internet aumenta também o conteúdo da rede, visto que a
disponibilização de conteúdo é facilitada pelos portais, que permitem que os usuários coloquem
páginas pessoais em seus servidores gratuitamente. As organizações perceberam que os portais,
com toda a sua audiência podiam ser um ótimo ambiente de marketing e propaganda, tanto quanto
outras mídias como a televisão e o rádio, com a vantagem de a propaganda poder, além de ser vista
e ouvida, interagir com o usuário/consumidor. Parcerias com empresas foram feitas e as
propagandas espalharam-se pela Web. Além disso, os portais fizeram parcerias também com redes
de televisão, rádio, revistas e livrarias, numa tentativa de aumentar os usuários da rede e,
conseqüentemente, de consumidores para as empresas parceiras, que muitas vezes eram as próprias
empresas de mídia.
No Brasil, a trajetória dos portais começa pelo mesmo caminho verificado nos EUA: com os
mecanismos de busca. O Cadê, estreou na Web em outubro de 1995, expandiu-se baseado no
conceito original de portal (página inicial para a experiência das pessoas na Web), mas logo
precisou agregar serviços diferenciados para competir com os grandes portais que estavam se
consolidando, como UOL e ZAZ, além do norte americanos que estavam chegando, como
13
Altavista, MSN, Yahoo!, todos com versões em português dos seus sites ou em vias de lançá-las
como estratégia de expansão, entre os anos 1998 e 1999 (BARBOSA, 2003).
Segundo Dias (2001), as rápidas transformações no modelo de portal levaram a identificação
de quatro fases do progresso do portal Web: pesquisa booleana (baseada na associação de termos
"E", "OU" para restringir ou ampliar o universo pesquisado), navegação por categorias,
personalização e funções expandidas para outras áreas. É assim que surgem os diferentes tipos de
portais para conformar aplicações variadas.
2.3.1. Classificação dos Portais
Para Dias (2001), "há duas formas para classificar os portais: uma em relação ao contexto de
sua utilização (público ou corporativo) e outra em relação às suas funções (suporte à decisão e/ou
processamento corporativo)". O portal público, segundo a mesma autora:
"é aquele denominado portal Internet, portal Web ou portal de consumidores - a exemplo do
UOL (Universo Online), AOL (América Online), Yahoo!, Terra, pois provê ao consumidor
uma única interface à imensa rede de servidores que compõem a Internet. Tem como
função atrair o público geral que navega na rede para o seu site. Quanto maior o número de
visitantes, maior a probabilidade do estabelecimento de comunidades virtuais que
potencialmente comprarão o que os anunciantes daquele site têm para vender. Assim como
a televisão, o rádio e a mídia impressa, o portal público estabelece um relacionamento
unidirecional com seus visitantes e constitui-se em uma mídia adicional para o marketing
de produtos."
Segundo Dias (2001), o portal corporativo "tem o propósito de expor e fornecer informações
específicas de negócio, dentro de determinado contexto, auxiliando os usuários de sistemas
informatizados corporativos a encontrar as informações de que precisam para fazer frente aos
concorrentes".
Segundo Correa (2001 apud BARBOSA 2003), são descritos quatro tipos de portal:
Portal básico ou Primary portals: aqueles que resultaram da evolução dos mecanismos de
busca;
Micro Portais, Microportals ou Weblogs: portais construídos pelo usuário, com nível total
de personalização. Segundo Barbosa (2003), Weblogs, "são simplesmente diários, onde o
autor registra suas ações, inquietações, reflexões e descobertas, ou pode tratar de qualquer
assunto considerado relevante pelo seu autor". Esses diários são disponibilizados a todos
internautas na Web por portais/servidores gratuitamente.
14
Portal corporativo ou Enterprise Information Portals (EIP): "Espaço de integração dos
sistemas corporativos, com segurança e privacidade dos dados corporativos. Além de uma
plataforma mais confortável, o portal pode constituir-se em um verdadeiro ambiente de
trabalho e repositório de conhecimento para a organização e seus colaboradores" (CEM,
2003). O portal corporativo é considerado segundo Dias (2001), como uma evolução do uso
das Intranets, incorporando, a essa tecnologia, novas ferramentas que possibilitam
identificação, captura, armazenamento, recuperação e distribuição de grandes quantidades de
informações de múltiplas fontes, internas e externas, para os indivíduos e equipes de uma
instituição.
Portal vertical ou Vortal: Para Lima (2004), o portal vertical:
"é um website que fornece informações e recursos para uma audiência específica, com o
serviço focado nas preferências dos consumidores. Os portais, tipicamente, fornecem
notícias, pesquisas e estatísticas, instrumentos para debates, newsletter, ferramentas online
e muitos outros serviços que educam os usuários de um determinado segmento. Os portais
verticais são naturais construtores de comunidades".
Vortal foi um conceito inicialmente desenvolvido nos Estados Unidos, com o objetivo de se
criar comunidades de usuários de Internet com interesses comuns (CEM, 2003).
Comparando os conceitos das autoras Dias (2001) e Correa (2001), verifica-se o conceito de
Portal Corporativo que é compartilhado por ambas as autoras. Verifica-se também que o chamado
Portal Público por Dias é o mesmo Portal Básico citado por Saad Correa. Essa categoria de portal é
amplamente conhecida pelo público, porém, por serem genéricos, a localização das informações
buscadas pode requerer um tempo e conhecimento que muitos usuários não dispõe. Para solucionar
esse problema, surgiram os Vortais. Nesta categoria, Barbosa (2003) diz que pode encaixar, como
variante, o Portal Regional ou Portal Local, pela relação direta entre comunidade e conteúdo, já que
foca a sua atuação no atendimento da demanda de informações e serviços direcionados a uma
determinada região, focando, portanto, na segmentação. "Entre conteúdo, notícias e serviços, como
classificados, guia de compras e fórum de debates, o portal deve apresentar espaço para tirar
dúvidas, e-commerce, turismo, lazer e cultura, desde que não fuja do segmento proposto" (A
NOTICÍA, 2004).
O fato dos portais verticais reunirem, num único endereço, serviços e informações sobre
determinada área ou dirigem-se a um público específico, os diferenciam dos outros portais de
conteúdo chamado horizontal, que possuem como característica principal focar o seu modelo de
15
negócio em grandes audiências oferecendo a maior gama possível de serviços e informações, como
os portais públicos (LIMA, 2004).
2.4. WEB SERVICES
Um Web Service é uma aplicação de software que pode ser acessada remotamente usando
diferentes linguagens baseadas em XML. Normalmente um Web service é identificado por uma
URL (Uniform Resource Locator), exatamente como qualquer site Web (POTTS e KOPACK,
2003).
“Os Web Services são na essência interoperabilidade conectando programas e aplicações a
outros programas e aplicações, especialmente quando estes são desenvolvidos usando
diferentes linguagens, ferramentas ou plataformas. A tecnologia chave para esse fim, o
XML (Extensible Markup Language), tem todo um potencial de implementação e
integração com a tecnologia J2EE” (OLIVEIRA, 2004).
A tecnologia de Web Services permite que aplicações também se comuniquem. Ou seja, o
conteúdo pode ser transmitido através da Internet, por um Web Service, e recebido por uma
aplicação remota, pela qual os dados podem ser utilizados de variadas maneiras: processados e
exibidos em uma página da Internet, em uma aplicação desktop, ou em um dispositivo móvel. Neste
sentido, pode-se fazer uma analogia à orientação a objeto tradicional, sendo que os Web Services
são utilizados da mesma maneira que classes, no cliente, com a diferença que, em se tratando de
Web Services, os métodos podem ser acessados remotamente (AMUNDSEN, 2002 apud MORELLI
NETO, 2003).
“Um Web Service é um sistema de software projetado para suportar interação máquina-amáquina sobre uma rede. Ele tem uma interface descrita em um formato processável por
máquina (especificamente WSDL). Outros sistemas interagem com o Web Service em uma
maneira aconselhada por esta descrição usando mensagens SOAP, tipicamente
transportadas usando HTTP (Hipertext Transfer Protocol) com uma serialização XML em
conjunção com outros padrões relacionados à Web” (OLIVEIRA, 2004).
Segundo Oliveira (2004), alguns conceitos importantes dos Web services são:
SOAP (Simple Object Access Protocol): É o protocolo que faz a comunicação dos Web
Services. É um padrão de comunicação que trabalha com os dados no formato XML,
utilizando o protocolo HTTP para transportar dados.
WSDL (Web Services Description Language): Fornece a descrição das relações dos Web
Services detalhadamente no formato XML.
16
UDDI (Universal Description, Discovery and Integration): são as "listas dos classificados"
dos Web Services e possibilita uma forma padrão, rápida e fácil de encontrar Web Services
que sejam de acordo com seus interesses.
Devido ao fato de XML e Java trabalharem de maneira tão coesa juntas, ambas tecnologias
aos poucos se tornaram um ponto central para os Web services. Em Java, já na versão J2EE 1.3,
eram encontrados todos os recursos necessários para infra-estrutura de Web Services. A versão atual
(1.4, de 2004), apresenta integração nativa com Web Services (OLIVEIRA, 2004).
Destacam-se APIs como: JAXP (Java API for XML Processing), para leitura, criação,
manipulação, transformação de XML, e JAXB (Java API for XML Binding), que mapeia classes
Java a documentos XML. As APIs para XML e por conseqüência para Web Services,
complementam as APIs da plataforma J2EE APIs. O Java Web Services Developer Pack (Java
WSDP) disponibiliza todas essas APIs em um único pacote, facilitando assim a implementação na
plataforma da interoperabilidade (ibidem).
Conforme Tood e Szolkowski (2003) com o surgimento da tecnologia de portal, os Web
services se tornarão cada vez mais essenciais para as aplicações web. Exemplo disso são os portais
que oferecem front-ends ricos em recursos Web, permitindo que os usuários interajam com preços
de ações, previsões meteorológicas, grupos de discussões, horários de vôo ou o que for, tudo a partir
de um home page principal.
A Figura 6, mostra de uma forma simplificada o funcionamento de um Web service.
17
Figura 6. Funcionamento simplificado de um Web service
Fonte: Ayala et al., (2002 apud MORELLI NETO, 2003).
O objetivo dos Web Services é a comunicação aplicação para aplicação através da internet.
Mais especificamente, essa comunicação é realizada com a idéia de facilitar a integração de
aplicação empresarial (EAI - Enterprise Application Integration) e o comércio eletrônico,
particularmente de empresa para empresa (POTTS e KOPACK, 2003).
Segundo Ayala et al. (2002 apud MORELLI NETO 2003), são inúmeras as vantagens do
uso de Web Services, sendo as mais importantes: interoperabilidade, eficiência de implementação,
reciclagem de código e modularidade.
Os Web Services levam vantagens em relação as outras soluções devido ao fato de
trabalharem com os dados no formato XML, o que lhe dá uma alta flexibilidade, sendo o XML
texto puro. Com isso podendo-se trabalhar em qualquer plataforma e com qualquer linguagem de
programação que suporte XML (POTTS e KOPACK, 2003).
2.4.1. XML
A XML é um padrão do W3C para representação de dados. Possui um formato simples e
muito útil para o intercâmbio de dados, o que é conseguido através da característica de marcação da
linguagem. Uma característica marcante na XML é a possibilidade de definição de novas
18
linguagens de marcação. Isto é possível pelo fato de as tags de marcação poderem ser definidas pelo
usuário. Por isto, pode-se dizer que dados semi-estruturados são bem representados pela XML
(XML, 2004).
A XML fornece uma maneira padrão de codificar o conteúdo e, mais especificamente, uma
maneira de criar estruturas de dados flexivelmente. A XML usa a metáfora das marcas de elementos
para marcar conteúdo tomando como base um conjunto de regras que o autor do documento criou
(PITS-MOULTIS e KIRK, 2000).
Os documentos XML são formados por unidades de armazenamento chamados entidades,
que contêm dados analisados sintaticamente ou não. Os dados analisados sintaticamente são
constituídos por caracteres, alguns dos quais formam dados de caracteres e parte dos quais formam
a marcação. A marcação codifica uma descrição do armazenamento e da estrutura lógica do
documento. A XML fornece um mecanismo para impor restrições no layout de armazenamento e da
estrutura lógica (TESCH JÚNIOR, 2002).
A diferença entre o HTML (HyperText Markup Language) e a XML é que as tags do HTML
servem para a apresentação de dados, enquanto as tags do XML têm por finalidade descrever os
dados. Por exemplo, um documento XML descreve o dado como o nome do empregado, o sexo e a
idade. O dado é descrito pela criação de tags compreensíveis facilmente, sendo que essas tags
auxiliam na criação de documentos bem formatados. A XML é eficaz na troca de dados
estruturados entre aplicações desde que os documentos XML possuam uma estrutura definida que a
qualifique como um documento bem formatado (AYALA et al., 2002 apud MORELLI NETO,
2003).
A XML em si, é simples. O que a torna poderosa são as tecnologias que são utilizadas junto
à linguagem. Uma vez que se tem um documento estruturado em XML, como mostra a
Figura 7, é
possível utilizar ferramentas específicas, conhecidas como padrões companheiros, para manipulá-lo
da forma que se deseja (TESCH JÚNIOR, 2002).
19
Figura 7. Exemplo de um documento XML
2.4.1.1. Namespaces
Namespaces (espaços identificadores de nomes), tem como objetivo determinar o escopo
para os elementos declarados no documento e disponibilizar contêiners para os nomes usados
dentro de um documento (TESCH JÚNIOR, 2002).
Os namespaces são URI’s (Uniform Resource Identifiers), e determinam o contexto para os
tipos de elementos e nomes de atributos usados nos documentos XML. A grande parte dos
namespaces são escritos usando o formato de um URL (ibidem).
Os namespaces são case sensitive e são declarados através da xmlns, que significa que ele é
o namespace default. Utiliza-se prefixos após o nome xmlns para se poder obter novos namespaces
(ibidem).
2.4.1.2. XML Schemas
Um XML Schema define como um conjunto de dados pode-se parecer, eles contêm
informações sobre como os documentos XML que se ligam a ele devem ser estruturados (TESCH
JÚNIOR, 2002).
Segundo Tesch Júnior (2002), os documentos XML não precisam estar associados a um
schema. Quando isso acontece e o documento está escrito conforme os padrões XML diz-se que ele
é um documento bem-formado. Se o XML bem-formado possuir um schema associado então ele é
um documento XML válido.
20
2.4.2. SOAP
O protocolo SOAP é um padrão aberto que foi concebido em 1999, como uma
recomendação do W3C, originado da proposta conjunta da Microsoft, IBM e Userland.com, entre
outras empresas, sendo baseado nas especificações da XML-RPC, criada por David Winer, da
Userland.com, em 1998 (AMUNDSEN, 2002 apud MORELLI NETO, 2003).
O SOAP não é um produto que foi criado e vendido por um fornecedor, mas sim um
documento que descreve as características de um software. Ele é definido em um alto nível de
abstração para que quaisquer combinações de sistema operacional e linguagem de programação
possam criar suas especificações com o SOAP (POTTS e KOPACK, 2003).
A problemática a ser solucionada pelo SOAP baseia-se no fato de que, em se tratando de
aplicações Web convencionais, os dados transportados que eram padronizados, com o uso do
protocolo HTTP, eram apenas a URL, o HTTP (GET ou POST) e o cabeçalho HTTP. As demais
informações dependiam das estruturações específicas de cada servidor Web. Tratando-se de
comunicações entre aplicações de diferentes plataformas, existe a necessidade de um “idioma”
comum, para que seja possível a comunicação entre os servidores. Assim, o SOAP funciona como
este “idioma” comum, já que seu objetivo básico é utilizar a XML como forma de descrever
informações de bibliotecas de tipos, possibilitando a comunicação entre duas extremidades, dois
servidores, sem a dependência de sistemas operacionais específicos (AMUNDSEN, 2002 apud
MORELLI NETO, 2003).
O objetivo do SOAP é descrever um formato de mensagem que não esteja vinculado a
qualquer arquitetura de hardware ou software, mas que transmita uma mensagem de qualquer
plataforma para qualquer outra plataforma de uma maneira inequívoca (POTTS e KOPACK, 2003).
A arquitetura dos Web services se baseia no envio de mensagens XML em um formato
SOAP específico. O SOAP é uma especificação que define uma gramática XML para o envio e a
resposta de mensagens que são recebidas em outras partes (ibidem).
O SOAP permite passar dados sem informações de tipos de dados. Sendo que o padrão
usado é string, caso não seja especificado nenhum tipo (ibidem).
21
2.4.2.1. Mensagem SOAP
O que tem chamado a atenção para o SOAP é sua simplicidade. Uma mensagem SOAP,
conforme mostra a Figura 8, é composta por 2 partes obrigatórias, o envelope SOAP e o corpo
SOAP, e ainda uma parte opcional, o cabeçalho SOAP (POTTS E KOPACK, 2003).
Figura 8. Formato da mensagem SOAP
Fonte: Potts e Kopack (2003)
2.4.2.1.1. Envelope
Um envelope é o elemento base do documento XML representando a mensagem. O
envelope pode conter declarações de namespaces e também de atributos adicionais (BOX et al.,
2000 apud MORELLI NETO, 2003). A string xmlns é o namespace utilizado para identificar todas
as
tags
a
fim
de
evitar
conflitos
de
nomes
de
tags.
A
string
“http://schemas.xmlsoap.org/soap/envelope/” parece uma URL de um site normal. Porém, ela é uma
string que indica a versão do SOAP que se está utilizando. O Web service que recebe essa
requisição pode olhar essa string e verificar se ele é capaz de se comunicar utilizando essa versão do
SOAP (POTTS e KOPACK, 2003).
2.4.2.1.2. Corpo (Body)
O elemento corpo disponibiliza um mecanismo simples para a troca de informações
obrigatórias, também chamado de payload, destinado ao receptor da mensagem. Normalmente, o
payload é uma chamada de método a um computador remoto, ou simplesmente um documento
XML que está sendo transferido (ibidem). O elemento corpo deve ser o primeiro elemento após o
cabeçalho. Caso não tenha sido definido um cabeçalho, então o elemento corpo deve ser o primeiro
22
elemento da mensagem. Todos os elementos filhos do elemento corpo são chamados de body
entries (entradas). Cada entrada é codificada independentemente dentro do elemento corpo (BOX et
al., 2000 apud MORELLI NETO, 2003).
O formato do corpo é controlado por quem estiver criando um novo web service. Um
documento XML especial é criado para descrever como seria uma mensagem válida a um serviço e
de que forma uma resposta válida assumiria (POTTS e KOPACK, 2003).
2.4.2.1.3. Cabeçalho (Header)
O elemento cabeçalho é opcional em uma mensagem SOAP, mas se for definido deve ser o
primeiro elemento filho a aparecer no envelope SOAP (ibidem). O Cabeçalho é um mecanismo
genérico que adiciona características à mensagem SOAP. O uso típico do envelope seria para
autenticação, gerenciamento de transações, entre outros (BOX et al., 2000 apud MORELLI NETO,
2003).
Dois elementos são associados ao elemento cabeçalho: mustUnderstand e Actor.
O atributo actor define o final dos elementos no cabeçalho e especifica a URI do
intermediário no qual a informação do cabeçalho SOAP é o alvo (AYALA et al., 2002 apud
MORELLI NETO, 2003).
O atributo mustUnderstand é utilizado para indicar se a entrada do cabeçalho deve ser
processada. Este atributo assume um valor binário, e caso não seja definido, o atributo assume o
valor (1) (BOX et al., 2003 apud MORELLI NETO, 2003).
2.4.2.1.4. Falhas
O SOAP define um elemento para o corpo que é o fault (falha), utilizado para transmitir
erros e/ou informações dentro da mensagem SOAP, ou seja, comunicar que um problema ocorreu
na tentativa do processamento da requisição enviada ao Web Service (POTTS e KOPACK, 2003).
Se presente, o elemento falha deve aparecer no corpo da mensagem não mais que uma vez
(AYALA et al., 2002 apud MORELLI NETO, 2003).
Segundo Potts e Kopack (2003) e BOX et al. (2000 apud MORELLI NETO (2003), o
elemento falha define os quatro elementos descritos a seguir:
23
•
faultcode: Esse elemento é exigido pela especificação. Ele contém a informação que
indica o tipo do erro, que é destinada a aplicação, não podendo ser vista pelo usuário
final. Quatro tipos de faultcode genéricos são definidos pela especificação: server,
client, versionMistach e mustUnderstand;
•
faultstring: Este elemento é a informação contida no faultcode, de uma forma legível
para o usuário final.
•
faultactor: Este elemento é opcional e informa quem gerou a falha dentro do caminho
da mensagem;
•
detail: Esse elemento é destinado a conter o máximo de informações possíveis sobre
o estado do servidor no momento da falha. Ele normalmente contém os valores das
variáveis no momento da falha.
2.4.3. WSDL
Segundo Potts e Kopack (2003), um documento WSDL (Web Services Description
Language) é um documento XML que fornece todas as informações para se conectar a um Web
service. Ele também possui algumas informações de que se precisa para avaliar se o Web service
pode satisfazer as necessidades do cliente. Um arquivo WSDL é como um contrato entre o cliente e
o serviço, pois efetiva a comunicação entre as duas partes (AYALA et al., 2002 apud MORELLI
NETO, 2003). Na
Figura 9, é mostrada as operações básicas do WSDL.
Qualquer programa que queira usar um Web service utiliza o WSDL para descobrir como
invocá-lo. Para isso o autor do Web service cria o documento WSDL manualmente ou usando
alguma ferramenta que o gere. Ele publica enviando-o (ou seu URL) a um serviço de diretório,
também chamado de registro, UDDI (Universal Discovery Description and Integration) (POTTS e
KOPACK, 2003). O cliente requisitará o serviço através de uma solicitação SOAP (AYALA et al.,
2002 apud MORELLI NETO, 2003).
24
Figura 9. Operações básicas que usam a WSDL
Fonte: Potts e Kopack (2003)
Um documento WSDL é sudividido em duas partes, as descrições concretas e abstratas, que
também são chamadas de descrições funcionais e não-funcionais respectivamente. A descrição
concreta é composta dos elementos que fazem o vínculo entre o cliente e o serviço, e já a descrição
abstrata é composta dos elementos que fazem a descrição das capacidades do Web service (POTTS
e KOPACK, 2003).
Segundo Potts e Kopack (2003), os quatro elementos abstratos que podem ser definidos em
um documento WSDL são: types, message, operation, portType. E os três elementos concretos são:
service, port, binding.
2.4.3.1. Elemento definitions
Definitions é o elemento raiz em um documento WSDL, pois ele que define o nome do Web
service e contém os elementos para especificar o targetNamespace, bem como diversos namespaces
(POTTS e KOPACK, 2003). O targetNamespace é uma convenção XML Schemas que permite ao
documento WSDL referenciar a si próprio (CERAMI, 2002 apud MORELLI NETO, 2003).
Na Figura 10, existe um namespace padrão, o xmlns="http://stevepotts.com/customer.xsd”,
que significa que todos os elementos sem prefixo namespace, como message e portType, serão
assumidos como parte do namespace WSDL (ibidem).
25
Figura 10. Exemplo de declaração de um definitions de um documento WSDL
Fonte: Potts e Kopack (2003)
2.4.3.2. Elemento Types
O elemento types é utilizado para descrever todos os tipos de dados utilizados no WSDL.
Caso o serviço utilize apenas tipos simples, a definição do elemento types passa a não ser
obrigatória (POTTS e KOPACK, 2003). A Figura 11 traz um exemplo da definição de um elemento
types.
Figura 11. Exemplo de definição de um types
Fonte: Potts e Kopack (2003)
Na Figura 11, tem-se a declaração do elemento customer, um complexType, que foi
definido. A seqüência dos elementos, <xsd:sequence>, indica que todos os elementos definidos
devem ser fornecidos exatamente nessa seqüência, caso não fosse preciso teria que ser usado a tag
<xsd:all>, e o namespace “xsd:string”, indica que todos os campos são do tipo string.
26
2.4.3.3. Elemento message
As mensagens (message) são um elemento importante no WSDL, pois são elas que fazem a
comunicação em um único sentido de um computador para outro. É considerado um elemento
abstrato, pois descreve a mensagem logicamente ao invés de fisicamente (POTTS e KOPACK,
2003). A
Figura 12, mostra a declaração de um elemento message.
Figura 12. Exemplo de definição de um message
Fonte: Potts e Kopack (2003)
2.4.3.4. Elemento operation e portType
O elemento operation (operação) é análogo a chamada de um método do Java, a única
diferença é que ele permite três mensagens em uma operação: entrada, que define os dados que o
Web service espera receber; saída, define os dados que o Web service espera enviar; e falha, que
define as mensagens de erro que podem se retornadas pelo Web service (ibidem).
Segundo Potts e Kopack (2003) e Cerami (2002) apud Morelli Neto (2003), o WSDL
suporta quatro tipos de operações: Requisição/resposta, um cliente faz uma requisição e o Web
service responde; Solicitação/resposta, o Web service envia uma mensagem ao cliente e ele
responde; Sentido único, O cliente envia uma mensagem e não espera uma resposta do Web service;
e Notificação, quando um Web service envia uma mensagem ao cliente e não espera uma resposta.
O elemento portType é o conjunto de operações que um Web service pode aceitar. Ele
fornece informações sobre todas as operações que o cliente pode obter de um Web service (POTTS
e KOPACK, 2003).
A
Figura 13, mostra como é a sintaxe de um operation do tipo requisição/resposta e do
portType. Se a mensagem fosse do tipo solicitação/resposta o elemento output apareceria antes do
input, e se não houvesse nenhum output seria uma mensagem de sentido único.
27
Figura 13. Sintaxe do operation e portType
Fonte: Potts e Kopack (2003)
2.4.3.5. Elemento binding
Este elemento possui duas finalidades. Serve como vínculo entre os elementos abstratos e
concretos no documento WSDL, e fornece um contêiner para informações como o protocolo e o
endereço do Web service (POTTS e KOPACK, 2003).
Figura 14. Sintaxe do elemento binding
Fonte: Potts e Kopack (2003)
A Figura 14 mostra alguns atributos do elemento binding como o transport que indica que o
transporte será feito por SOAP HTTP. O atributo style indica o estilo completo do formato da
mensagem SOAP, que pode ser rpc ou document. Se for rpc o documento será enviado em formato
XML e se for document será enviado sem nenhuma modificação.
2.4.3.6. Elementos service e port
O elemento service é um contêiner para todas as portas que são representadas por um
documento WSDL. As portas de um serviço não podem ser encadeadas, pois a porta de saída é a
28
entrada para outra. O elemento port é um elemento filho do service que indica qual a porta e o ip do
Web service. A Figura 15, mostra como é a sintaxe dos elementos service e port.
Figura 15. Sintaxe dos elementos service e port
Fonte: Potts e Kopack (2003)
2.4.4. UDDI
Os Web services podem ser eficazes para reduzir o custo de fazer negócios facilitandoa
transmissão de dados de um computador para o outro. A possibilidade de conquistar novos clientes
ou desenvolver novos produtos requer mais do que o SOAP e a WSDL; ela requer um registro
(POTTS e KOPACK, 2003).
Um registro, é um banco de dados de serviços, e é simplesmente um passo revolucionário
pois a idéia de que um cliente potencial usaria os recursos de um registro de maneira semelhante à
de como usamos mecanismos de busca na internet. Digita-se alguma coisa do que se está
procurando e aparece uma lista dos possíveis serviços. Refinariar-se-ia a pesquisa até chegar o mais
próximo possível do que se está procurando (ibidem).
O UDDI (Universal Discovery, Description, and Integration) é um padrão de registro que
emergiu assumindo um papel importante nessa área. Ele é fruto do consórcio de centenas de
empresas, entre elas Intel, Microsoft, Fujitsu, Sun, entre outras (ibidem).
O UDDI é um mecanismo padronizado e transparente para descrever serviços, ele descreve
métodos simples para solicitar serviços, e especifica um registro central acessível dos outros. Outro
recurso é que os registros são baseados em um modelo confederado pelo qual copiam um dos
outros. Ou seja, quando acontece um registro de um Web service, os outros registros receberão
informações desse Web service que foi registrado na próxima vez que fizerem a sincronização
(ibidem).
29
O motivo pelo qual o UDDI é aceitável por todos os consorciados é que ele é construído
sobre os mesmos padrões do SOAP (POTTS e KOPACK, 2003).
Todas as APIs do UDDI são definidas em XML, inseridas em envelopes SOAP e enviadas
por HTTP. Programar com a API do UDDI é o mesmo que programar qualquer Web service, só
precisa-se saber codificar as mensagens no formato SOAP. No mundo Java, existe a UDDI4J que é
uma biblioteca comum para acessar os registro UDDI.
2.5. FERRAMENTAS PARA O PROJETO
A Web vem sendo um ambiente muito visado pelas empresas para fazer negócios, tendo em
vista a agilidade no processamento das informações (FEDOROV et al, 1998).
Segundo Castagnello et al. (2000), um site moderno não é formado só por um servidor Web,
ele também possibilita o armazenamento e consulta de dados, processamento de pedidos, geração
de documentos com informações apropriadas. Muitas são as opções para o desenvolvedor, não se
deve apenas considerar a tarefa de criar um site dinâmico, mas sim ter certeza de que poderá
continuar a fornecer o conteúdo independentemente das mudanças nas tecnologias tanto de
hardware como de software.
O objetivo deste capítulo é apresentar as características das ferramentas utilizadas para a
implementação do projeto.
2.5.1. PHP
No ano de 1994, um consultor de empresas, chamado Ramus Ledorf, enviava o endereço
eletrônico que continha o seu currículo, para os mais diversos empregadores. Devido a necessidade
que ele tinha de saber quem eram esses empregadores que estavam acessando sua página, ele
desenvolveu um script que colhia as informações sobre os seus visitantes, e media o número médio
de acessos. Para impressionar os empregadores, ele resolveu mostrar esses dados, e chamou todo
esse código de Personal Home Page Tools, e nascia então o PHP Tools (ANSELMO, 2002).
PHP, um acrônimo de PHP Hypertext Preprocessor (Pré-processador de hipertexto PHP), é
uma linguagem de script Open Source de uso geral, muito utilizada e especialmente guarnecida para
o desenvolvimento de aplicações Web embutida dentro do HTML (CASTAGNELLO, 2001).
30
O desenvolvimento do PHP é focado nos scripts do lado servidor. A melhor coisa em usar o
PHP está na facilidade e na quantidade de recursos oferecidos. Basicamente, qualquer coisa pode
ser programada com PHP, como coletar dados de um formulário, gerar páginas dinamicamente ou
enviar e receber cookies (ANSELMO, 2002).
De acordo com Martini (2003 apud BERNARDO JÚNIOR 2004), o PHP possui as
seguintes vantagens:
Linguagem de script de fácil utilização e com grande poder de interatividade;
Excelente velocidade de execução;
Ligação com diversos bancos de dados, como: MySQL, mSQL, SyBase, SQLServer, Oracle,
Informix e qualquer outro banco de dados via ODBC (Open Database Conectivity);
Suporta por meio de APIs e interfaces, um vasto conjunto de ferramentas e plataformas; e
Algumas ferramentas e protocolos comuns suportadas pelo sistema PHP são: IMAP, SMTP,
SNMP, POP3, HTTP, XML.
2.5.2. PostgreSQL
O PostgreSQL teve seu início na Universidade de Berkeley, em 1986. É um banco de dados
relacional e orientado a objetos, versátil, seguro, de grande porte e gratuito (POSTGRESQL, 2004).
É possível utilizá-lo em vários sistemas operacionais, inclusive o Windows, basta somente
este sistema operacional ser compatível com as especificações POSIX (Portable Operation System
Interface) (POSTGRESQL, 2004).
O uso deste banco é muito amplo, pois várias empresas perceberam que podem criar
soluções de alta confiabilidade sem a necessidade de altos custos na aquisição de licenças (ibidem).
Ele conta com conexões SSL, MVCC (Multi Version Competition Control), triggers,
integridade referencial, além de ser compatível com várias linguagens como PHP, Java, Python,
Perl, entre outras. (ibidem)
O PostgreSQL é um banco que suporta um grande volume de dados, isso é verificado pela
Tabela 1, que mostra os limites deste banco.
31
Tabela 1. Limites do banco de dados PostgreSQL
Tamanho Máximo
Dados em uma base
Uma tabela
Uma linha
Um campo
Uma linha por tabela
Uma coluna por tabela
Um índice por tabela
Limite
Ilimitado
16 Tb em todos os sistemas operacionais
1,6 Tb
1 Gb
Ilimitado
250 a 600
Ilimitado
Fonte: PostgreSQL (2004)
Como foi criado para ter vários recursos e suportar tarefas complexas, é mais indicado em
aplicações com grandes volumes de dados ou que possuam informações críticas, onde o banco é
grande e possui um grande número de tabelas.
2.6. CONSIDERAÇÕES
O Capítulo 2, foi parte importante neste trabalho, pois foi através desse capítulo que pode-se
buscar e analisar tanto o problema quanto as ferramentas para a solução dos problemas encontrados.
As necessidades do Laboratório de Climatologia, foram descritas e a partir disso a solução
adotada foi a criação de um sistema de informação que será um Portal, utilizando a ferramenta PHP,
e o banco de dados PostgreSQL. O Portal sobre os dados meteorológicos conta com as informações
meteorológicas fornecidas pelo laboratório.
Além de disponibilizar os dados através do portal, o laboratório agora conta também com
um Web service, que disponibiliza os dados providos pela estação meteorológica, no formato XML.
O estudo sobre a XML foi de fundamental importância, pois a XML é a base dos Web
services, e é através dela que os protocolos SOAP, WSDL e o UDDI são descritos.
Para a construção do Web service foi utilizado o NuSOAP é um pacote de classes para
desenvolvedores criarem e consumirem Web Services; Para sua utilização não é necessário
nenhuma biblioteca especial do PHP, o que possibilita o que todos os desenvolvedores possam
utiliza-la independente de plataforma.
O NuSOAP dá suporte aos arquivos WSDL. Podendo-se conectar a um servidor e criar uma
instancia local ou remota do WSDL.
32
3. DESENVOLVIMENTO
O desenvolvimento deste projeto teve como objetivo, organizar e gerenciar os dados do
Laboratório de Climatologia, de modo que suas atividades pudessem ser feitas de maneira
automatizada. O Sistema de Divulgação de Dados Meteorológicos primeiramente organizou todos
os dados do laboratório em um banco de dados, acabando então com o problema da ausência de um
acervo histórico para a previsão do tempo, previsão marítima e fases da lua. Depois isso, se
reformulou todo o site do laboratório tornando-o dinâmico, e assim eliminando os modelos usados
anteriormente ao sistema proposto. O sistema conta com uma área administrativa onde os
responsáveis pelo laboratório podem fazer a manutenção do site, e uma área pública onde os
internautas podem ver as informações disponibilizadas pelo Laboratório.
Após terem sido executados os passos descritos acima, foi implementado um Web service
para disponibilizar os dados que são coletados pela estação meteorológica. Através desse Web
service, o solicitante do serviço apenas entrará com o parâmetro do dado pretendido, o período que
o interessa, sua identificação, e então receberá os dados em formato XML, que possibilitará a ele
usar os dados da maneira que melhor o convier.
As seções seguintes apresentam o Sistema de Divulgação de Dados Meteorológicos, seu
projeto e implementação.
3.1. REQUISITOS DO SISTEMA
3.1.1. Requisitos Funcionais
Os requisitos funcionais que o sistema contempla são:
•
O sistema deve permitir a inserção, alteração e exclusão dos dados da previsão do
tempo;
•
O sistema deve produzir relatórios dos dados meteorológicos;
•
O sistema deve permitir que os visitantes possam visualizar os dados meteorológicos e
imagens de satélite;
•
O sistema deve permitir que os clientes possam obter os dados meteorológicos através
do Web service;
33
•
O sistema deve fazer a importação das imagens vindas de satélites;
•
O sistema deve disponibilizar um espaço para críticas e sugestões;
•
O sistema deve permitir inserção, alteração e exclusão de usuários;
•
O sistema deve permitir inserção, alteração e exclusão de recados;
•
O sistema deve permitir inserção, alteração e exclusão dos dados da previsão marítima;
•
O sistema deve ter um mecanismo de importação para as informações do pôr do sol; e
•
O sistema deve possui um mecanismo de importação dos dados da estação
meteorológica.
3.1.2. Requisitos Não Funcionais
Os requisitos não funcionais que o sistema contempla são:
•
O sistema deve ser compatível com browser Explorer 5.0;
•
As páginas web não devem levar mais de 15 seg. para serem carregadas no
navegador durante o uso normal do sistema;
•
O Web Service deve ser implementado com PHP;
•
O sistema deve utilizar banco de dados PostgreSQL;
•
Para a implantação do sistema deve ser disponibilizado um servidor;
•
O web site deve ser implementado usando a linguagem PHP; e
•
O Sistema deve possuir um mecanismo de segurança, para que os visitantes não
tenham acesso à administração do sistema.
3.1.3. Regras de Negócio
As principais regras de negócio que o sistema contempla são:
•
O período em que a estação meteorológica grava os dados no arquivo texto é de 45 minutos;
•
A previsão do tempo é para até 3 dias, sendo o primeiro dia o corrente;
34
•
Ao cadastrar a previsão para um dia, a previsão anterior deve ser mantida no banco de
dados; e
•
A estação está configurada para capturar imagens da América do Sul, e da parte Leste do
Globo, nos horários UTC das 0, 3, 6, 9, 12, 15, 18 e 21 horas.
3.2. DIAGRAMA DE ATIVIDADES
Os diagramas apresentados nas figuras 16 a 19 representam o funcionamento anterior ao
desenvolvimento do sistema proposto no presente trabalho bem como a situação encontrada após
sua implementação.
Na Figura 16, o diagrama de atividades mostra como os dados vindos da estação
meteorológica e da estação receptora de imagens de satélite eram tratados antes da implementação
do sistema proposto. Observa-se que a geração HTML era feita através de alguns programas
desenvolvidos por colaboradores do laboratório, que pegavam os dados e inseriam num modelo
HTML e depois faziam o FTP dos mesmos. Após a implementação, Figura 17, os dados são
armazenados em um banco de dados, ficando disponíveis para o site do sistema e para o
webservice.
De forma semelhante a Figura 18, apresenta o fluxo de atividades realizadas para as
previsões do tempo e marítima, antes da implantação do sistema. Observe que as previsões eram
feitas também usando modelos HTML, e que não eram armazenadas, sendo assim só se tinha as
previsões atuais que estavam online. Após a implementação do sistema proposto, o fluxo de
atividades para as previsões passa a ser conforme apresentado na Figura 19, o qual permite o
armazenamento do histórico das previsões de tempo e marítima.
35
Figura 16. Diagrama de Atividades da estação antes do sistema proposto
O diagrama apresentado na Figura 16 permite observar que alguns dados possuiam
histórico, porém nenhum deles é armazenado em um banco de dados e sim em arquivos do tipo
36
TXT. Também observa-se que o sistema trabalhava com modelos HTML e não com um site web
dinâmico.
Figura 17. Diagrama de Atividades das estações após o sistema proposto
37
Após a implementação do sistema, as informações que são geradas pela estação
meteorológica, não são mais armazenadas em arquivos texto, e sim em um banco de dados,
possibilitando um melhor aproveitamento das mesmas.
Figura 18. Diagrama de Atividades das previsões antes do sistema proposto
38
Como pode-se constatar as previsões eram realizadas de uma forma que seu histórico era
armazenado apenas no site, porém eram sempre substituídas pelo boletim mais atual, não se
obtendo assim um histórico dessas informações.
Figura 19. Diagrama de atividades das previsões após o sistema proposto
39
Seguindo o modelo adotado pelo Laboratório de Climatologia de fazer a previsões para os 3
próximos dias, após a implementação do sistema proposto os boletins das previsões são todos
armazenados no banco de dados, obtendo-se então um acervo histórico dos mesmos.
As Figuras 20 e 21 ilustram como era o processo realizado pelo Laboratório de Climatologia
para disponibilizar as informações e como ficou após a implementação do projeto.
Figura 20. Cenário anterior a implementação do sistema
A partir da Figura 20 pode-se perceber que o Laboratório funcionava da seguinte forma: a
estações geravam seus dados que através de softwares escritos nas linguagens C e Delphi e
planilhas do Excel eram tratados e a partir daí gerados modelos HTML que eram enviados via FTP
para o servidor e disponibilizados através do site da previsão do tempo.
Em paralelo o responsável pelo Laboratório de Climatologia realizava os boletins da
previsão do tempo, marítima, gráficos de temperatura, fases da lua, entre outros utilizando também
os softwares C, Delphi e planilhas do Excel que também era transformados em modelos HTML e
enviados via FTP para o site da previsão do tempo.
Através da figura percebe-se que não era utilizado um banco de dados, ou seja, muitas
informações eram perdidas, devido a sobreposição de arquivos que existia diariamente.
40
Figura 21. Cenário atual com a implementação do sistema
A Figura 21 retrata o funcionamento do Laboratório após a implementação do sistema que
ficou da seguinte forma. As estações geram seus dados que são enviados via FTP para o sistema de
informação. No sistema de informação esses dados são tratados pelo mecanismo de importação e
inseridos no banco de dados. O responsável pelo Laboratório paralelamente pode acessar á área
restrita (SiDMET) e fazer a manutenção dos dados que agora estão organizados em um banco de
dados realizando cadastros, alterações e exclusões. A partir das informações do banco de dados, os
dados são disponibilizados através do portal da previsão do tempo e também de web services (dados
meteorológicos e previsão do tempo).
3.3. FUNCIONALIDADES DO SISTEMA
O sistema proposto foi subdividido em quatro módulos: Armazenamento dos Dados,
Administração do sistema, Área pública e Web service, como mostra a Figura 22.
41
cd 3.1 Diagrama de pacotes
PCT01 - Armazenamento de dados
+ Estação meteorológica
PCT02 - Administração do sistema
+ Satélite
+ UC01.01 Armazena Imagens do Globo
+ Colaborador
+ UC01.02 Armazena Dados Meteorológicos
+ Professor
+ Por do Sol
+ UC02.01 Manutenção de Usuários
(from 3.2 Diagrama de casos de uso)
+ UC02.02 Faz Previsão do T empo
+ UC02.03 Faz Previsão Maritima
PCT04 - Webserv ice
+ UC02.04 Geração de Relatórios
+ Cliente
+ UC02.05 Login
+ UC04.01 - Solicita dados meteorológicos
+ UC02.06 Recados
+ UC02.07 Armazena Fases da Lua
+ UC02.08 Visualiza Criticas e Sugestões
(from 3.2 Diagrama de casos de uso)
+ UC02.09 T abuas da Maré
+ UC02.10 Região
PCT03 - Área pública
+ UC02.11 Áreas
+ Visitante
+ UC02.12 Estação
+ UC03.01 Visualiza Previsão do Tempo
+ UC02.13 Satélite
+ UC03.02 Consulta Previsão Maritima
(from 3.2 Diagrama de casos de uso)
+ UC03.03 Consulta Dados Meteorológicos
+ UC03.04 Consulta Imagens do Satélite
+ UC03.05 Consulta Por do Sol
+ UC03.06 Consulta Fases da Lua
+ UC03.07 Envia Criticas e Sugestões
+ UC03.08 Visualiza Recados
(from 3.2 Diagrama de casos de uso)
Figura 22. Diagrama de Pacotes dos casos de uso do sistema
No módulo armazenamento de dados, os dados da estação meteorológica através de
mecanismos desenvolvidos, são importados para o banco de dados, assim como as imagens de
satélite.
Na administração do sistema, os responsáveis pelo laboratório fazem a manutenção de todos
os dados desde o cadastramento de novos usuários até a leitura de sugestões e críticas enviadas por
visitantes do site. É neste módulo que são realizados
os boletins das previsões do tempo e
marítimas, gerados os relatórios do sistema, e também acessado o acervo históricos das previsões e
dos dados meteorológicos vindo do satélite e da estação meteorológica.
O módulo da área pública é onde os visitantes poderão usufruir dos serviços de previsões,
dados meteorológicos, imagens do satélite e também poderão enviar suas críticas e sugestões para
os profissionais do laboratório.
42
O quarto módulo trata do Web service, que disponibiliza os dados meteorológicos de um
certo período de tempo de interesse do solicitante em formato XML.
A seção seguinte detalha as funcionalidades de cada módulo do sistema, através dos casos
de uso.
3.4. DIAGRAMA DE CASOS DE USO
Os Casos de Uso facilitam o entendimento de um sistema pois eles são utilizados para
modelar o contexto de um sistema, subsistema ou classe. É uma das maneiras mais comuns de
documentar os requisitos do sistema, de delimitar o sistema, e de definir a sua funcionalidade
(FOWLER, 2000).
De acordo com as funcionalidades propostas, obteve-se os seguintes diagramas de caso de
uso, representados pelas figuras de 23 a 26 e nas tabelas de 2 a 5.
ud 01 - Armazenamento de Dados
UC01.01
Armazena
Imagens do Globo
Satélite
UC01.02
Armazena Dados
Meteorológicos
Estação meteorológica
Figura 23. Pacote Armazenamento de Dados
43
Tabela 2. Funcionalidades do pacote Armazenamento de Dados
Caso de Uso
Descrição
Armazena imagens do globo
Armazena uma imagem do globo a partir do satélite
Armazena dados meteorológicos Armazena os dados meteorológicos a partir da estação
meteorológica
ud PCT02 - Administração do Sistema
Por do Sol
UC02.07
Armazena Fases
da Lua
UC02.01
Manutenção de
Usuários
Colaborador
UC02.03 Faz
Prev isão Maritima
UC02.05 Login
Professor
UC02.12 Estação
UC02.08 Visualiza
Criticas e
Sugestões
UC02.11 Áreas
UC02.02 Faz
Prev isão do Tempo
UC02.13 Satélite
UC02.09 Tabuas
da Maré
UC02.06 Recados
UC02.10 Região
UC02.04 Geração
de Relatórios
Figura 24. Pacote da Administração do Sistema
Tabela 3. Funcionalidades do pacote Administração do Sistema
Caso de Uso
Manutenção de Usuários
Fazer previsão do tempo
Fazer previsão marítima
Geração de relatórios
Login
Recados
Armazena fases da lua
Visualiza críticas e sugestões
Tábuas da Maré
Região
Descrição
Permissão para manutenção de usuários do sistema
Permite a manutenção da Previsão do Tempo
Permite a manutenção da Previsão Marítima
Geração de Relatórios dos dados do sistema
Possibilita a entrada na parte administrativa do sistema
Manutenção de recados do sistema
Mecanismo de importação para as fases da lua
Possibilita a visualização e exclusão das críticas e sugestões
postadas no web site
Possibilita visualizar, editar e excluir as informações das Tábuas
da Maré
Possibilita visualizar, editar e excluir as informações das regiões
da previsão do tempo
44
Área
Possibilita visualizar, editar e excluir as informações das Áreas da
previsão marítima
Possibilita inserir, alterar e excluir dados para o por do sol
Manutenção das imagens do satélite
Manutenção dos dados da estação
Pôr do Sol
Satélite
Estação
ud PCT04 - Área pública
Visitante
UC03.03 Consulta
Dados
Meteorológicos
UC03.04 Consulta
Imagens do
Satélite
UC03.08 Visualiza
Recados
UC03.05 Consulta
Por do Sol
UC03.07 Env ia
Criticas e
Sugestões
UC03.02 Consulta
Prev isão Maritima
UC03.01 Visualiza
Prev isão do Tempo
UC03.06 Consulta
Fases da Lua
Figura 25. Pacote Área Pública
Tabela 4. Funcionalidades do pacote Área pública
Casos de Uso
Visualiza previsão do tempo
Consulta previsão marítima
Consulta dados meteorológicos
Consulta imagens do satélite
Consulta pôr do sol
Consulta fases da lua
Envia críticas e sugestões
Visualiza recados
Descrição
Possibilita o visitante obter a previsão do tempo para os 3
próximos dias
Possibilita o visitante obter a previsão marítima para os 3
próximos dias
Possibilita ao visitante consultar os dados meteorológicos
Possibilita ao visitante visualizar imagens de satélite do leste do
globo e da América do Sul
Possibilita ao visitante obter os horários do nascer e do pôr do sol
Possibilita ao visitante obter as informações das fases da lua
Possibilita ao visitante enviar criticas e sugestões para os
administradores do site
Possibilita ao visitante ter acesso a informações importantes
45
cd PCT04 - Webserv ice
UC04.01 - Solicita
dados
meteorológicos
Cliente
Figura 26. Pacote Webservice
Tabela 5. Funcionalidades do pacote Web service
Casos de Uso
Solicita dados meteorológicos
Descrição
Cliente obtém dados meteorológicos através do web service
A descrição completa dos casos de uso está nos Apêndices A,B,C e D.
3.5. DIAGRAMA DE CLASSES
O diagrama de classes é um diagrama que mostra um conjunto de classes, interfaces,
colaborações e seus relacionamentos, com o objetivo de permitir a visualização, especificação e
documentação de um modelo de sistema (FOWLER, 2000).
As classes utilizadas na implementação deste sistema fazem parte de um framework de
desenvolvimento utilizado pelo LCA (Laboratório de Computação Aplicada). A partir desse
framework foi desenvolvido todo o Sistema de Divulgação de Dados Meteorológicos
Tabela 6. Classes do Framework
Nome da Classe
htmlBase
htmlErro
htmlTempo
DBSQL
Db_Tempo
formBase
formDetalhe
formCadastro
formLista
Descrição
Classe abstrata para criar uma página web
Classe para mostrar as mensagens de erro na tela
Classe especializada de htmlBase para o sistema implementado
Classe abstrata para conexão a um banco de dados Postgres
Classe especializada para conexão a base de dados do sistema
Classe para criação de formulários em html
Classe especializada para detalhe dos dados
Classe especializada para cadastro dos dados
Classe especializada para listagem dos dados
46
A Figura 27, mostra o diagrama de classes do framework para este sistema. As classes
específicas do sistema implementado foram implementadas a partir da herança destas classes
básicas do framework.
Figura 27. Diagrama de classes do Framework
47
3.6. MODELAGEM DE DADOS
A modelagem de dados apresenta o modelo ER (Entidade Relacionamento) e a descrição das
tabelas utilizadas no banco de dados. A Tabela 7 fornece uma visão geral das tabelas do sistema. O
dicionário de dados está detalhado no Apêndice E.
Tabela 7. Descrição da tabelas utilizadas no sistema
Nome da tabela
ARQ_MOD
ARQUIVO
CONEXAO
MODULOS
OPERADORES
PERMISSOES
TB_AREA
TB_DADOS_MARITIMOS
TB_CONTATO
TB_DADOS_METEOROLOGICOS
TB_FASES DA LUA
TB_IMAGENS_SATELITE
TB_LOG
TB_POR_DO_SOL
TB_PREVISAO_MARITIMA
TB_PREVISAO_TEMPO
TB_RECADO
TB_REGIAO
TB_TABUA_MARE
TB_TIPO_IMAGEM
Descrição
Tabela que faz a relação entre os arquivos e os módulos
Tabela dos arquivos existentes no projeto
Tabela que contém o registro das conexões na área restrita
Tabela com os módulos do sistema
Tabela de usuários
Tabela com as permissões do sistema
Tabela com as áreas da previsão marítima
Tabela com os dados das áreas da previsão marítima
Tabela com as criticas e sugestões enviadas na área pública
Tabela que armazena os dados meteorológicos vindos da
estação meteorológica
Tabela que armazena as informações das fases da lua
Armazena as imagens recebidas pelo satélite
Faz a auditoria do sistema
Tabela que armazena as informações com os horários do pôr
do sol
Tabela que contem as informações das previsões marítimas
Tabela que contem as informações das previsões do tempo
Tabela que contém recados importantes que precisam ser
sabidos pelos usuários
Tabela com as regiões da previsão do tempo
Tabela com o nome e códigos dos portos
Tabela com os tipos das imagens vindas do satélite
3.7. IMPLEMENTAÇÃO
Esta seção aborda o funcionamento do sistema através da apresentação de suas telas, bem
como, as funções desenvolvidas a fim de atender as necessidades propostas à aplicação.
3.7.1. Área Restrita
A área restrita é o local, onde apenas os responsáveis pelo Laboratório de Climatologia e
pessoas autorizadas pelos mesmos acessam para fazer a manutenção dos serviços do sistema.
48
Na tela inicial, o usuário seleciona sua entrada digitando seu nome e sua senha, sendo assim
direcionado para o a tela principal onde pode escolher através do menu a ação desejada.
O sistema foi implementando seguindo um padrão para a visualização dos dados. Quando se
seleciona qualquer opção do menu é apresentada uma tela com a listagem de suas ocorrências, com
a opção de filtros de busca para selecionar dados específicos, conforme mostra a Figura 28.
Ainda na tela com a listagem das ocorrências existe a possibilidade da geração de relatórios
com um simples clique na opção “Gera PDF”.
Figura 28. Tela de listagem dos dados
Os detalhes das informações referentes aos itens listados podem ser visualizados através da
opção INFO, quando o sistema apresenta uma outra tela (Figura 29).
49
Caso seja escolhida opção Editar, é possível além de visualizar os detalhes do dado, excluir
o item selecionado.
Figura 29. Tela de detalhes de itens
Através deste padrão, todos os casos de uso foram implementados permitindo a consulta e
manutenção dos dados na área restrita do sistema.
Para fazer o cadastramento de novos dados, é preciso selecionar a opção Novo, que
apresenta uma tela com os campos necessários a serem preenchidos para a inserção do novo dado
no sistema. A Figura 30 ilustra como é feita a inserção dos dados para a previsão do tempo.
50
Figura 30. Tela de cadastro de dados
3.7.2. Área Pública
A área pública é o local onde os dados meteorológicos são disponibilizados para qualquer
pessoa que tenha interesse, sem restrições. A figura 31, mostra a tela inicial do sistema.
51
Figura 31. Home page do Laboratório de Climatologia
A área pública apresenta dados que são organizados dinamicamente, através de buscas no
banco de dados do sistema, apresentando-se, assim, as informações mais recentes.
A figura 32 mostra a tela da previsão do tempo, cujos dados foram cadastrados através da
área restrita do sistema, como demonstrado no item anterior.
52
Figura 32. Layout da previsão do tempo
3.7.3. Web Service
Esta seção aborda o funcionamento do Web Service o qual é composto nos módulos servidor
e cliente. O módulo servidor é o que interage com o banco de dados, através das solicitações SOAP
do cliente, respondendo conforme os métodos descritos no WSDL. O Apêndice F apresenta o
código fonte do WSDL.
Como o Web Service realiza suas função a partir do métodos descritos no WSDL, isto
implica que para se obter os dados do Web service precisa-se ter o conhecido do WSDL, não
importando então qual a linguagem será utilizada para fazer a conexão com o Web Service, apenas
que essa linguagem de programação suporte XML.
53
Dado o fato de que o módulo servidor foi implementado em PHP, a seguir será dado um
exemplo de como pode ser um módulo cliente, para acessar o Web service. O módulo cliente citado
a seguir também foi desenvolvido em PHP, mas nada impede que seja desenvolvido em outra
linguagem de programação.
O módulo cliente é composto de duas telas, conforme descrito a seguir.A Figura 33, mostra
a primeira tela do Web Service que é onde o cliente digita seu login, senha, período (data de início e
data de término) e seleciona o dado meteorológico desejado.
Figura 33. Tela de login para acessar o Web Service
Após a validação do usuário, é feita a solicitação para o módulo servidor através de
mensagens SOAP com os parâmetros digitados pelo cliente. O módulo servidor então faz a
solicitação ao banco de dados e retorna os dados solicitados na tela, como mostra a figura 34.
54
Figura 34. Tela de resultados do Web Service
A Figura 35, ilustra um exemplo de código fonte na linguagem de programação PHP para
uma solicitação do cliente ao Web Service.
Figura 35. Tela do código fonte de uma solicitação cliente ao Web Service
55
3.7.4. Importação de dados das estações
Dado o fato que a estação meteorológica armazena seus dados em arquivos texto, e tendo-se
um volume muito grande desses dados, torna-se inviável tratá-los neste formato. Sendo assim, foi
necessária a criação de um software Delphi para transmiti-los via FTP e de scripts em PHP, para
fazer a importação desses dados para o banco de dados.
Figura 36. Tela do software que faz FTP dos dados da estação
O software desenvolvido na linguagem de programação Delphi funciona da seguinte forma:
monitora o diretório onde são descarregados os dados da estação meteorológica e da estação de
captura de imagens verificado a existência de novos registros gerados pelas estações e a cada vinte
minutos esses dados são enviados para o sistema de informações e são tratados pelos scripts PHP.
Os scripts foram desenvolvidos para a importação dos dados meteorológicos, do pôr do sol e
para as imagens recebidas pelo satélite. Através desse mecanismo de importação foi possível tratar
os dados que se obteve um grande ganho em termos de qualidade e agilidade na obtenção de dados
meteorológicos.
56
4. CONSIDERAÇÕES FINAIS
Este projeto apresentou o Sistema de Informações para o Laboratório de Climatologia do
CTTMar, Univali. O desenvolvimento deste sistema contornou os principais problemas enfrentados
pela equipe do Laboratório no que diz respeito à organização, manutenção e divulgação de dados
meteorológicos da região litoral de Santa Catarina. Através da importação automática de dados da
estação meteorológica e de satélite, criação de um banco de dados e facilidades de manutenção de
dados e previsão meteorológica e marítima, o sistema possibilita o armazenamento de acervo
histórico que pode ser utilizado para futuros trabalhos de pesquisa na área.
O web service e as páginas de informações dinâmicas na web para divulgação de dados e
previsão do tempo e marítima, fornecem aos clientes do laboratório um grande ganho em termos de
qualidade e agilidade na obtenção de dados meteorológicos, ao mesmo tempo em que são
mecanismos facilitadores para os próprios técnicos do laboratório.
O sistema de informações de dados meteorológicos constitui-se em uma ferramenta de apoio
à equipe do Laboratório de Climatologia, facilitando suas operações e conferindo um alto grau de
segurança dos dados armazenados. Acredita-se que a automação desses serviços reduzirá o trabalho
operacional, proporcionando, assim, mais tempo para a pesquisa.
Encontrou-se dificuldades na busca de material sobre Web Services, principalmente no que
diz respeito a implementação na linguagem PHP. Existem poucos exemplos na Internet, e livros
também são de difícil acesso tanto na língua inglesa quanto na portuguesa.
Sugerem-se como trabalhos futuros a integração dos dados do Sistema de Divulgação de
Dados Meteorológicos a outros sistemas para obtenção de estatísticas e geração de análises de
dados. Uma proposta é a integração com o SGMA – Sistema de Gerenciamento de Mergulho
Autônomo, que está sendo desenvolvido para o Laboratório de Mergulho do CTTMar.
Este trabalho foi aprovado e apresentado no XIX CRICTE (Congresso Regional de Iniciação
Científica e Tecnológica em Engenharia).
57
REFERÊNCIAS BIBLIOGRÁFICAS
A NOTÍCIA, Jornal. Portais investem em público específico. Disponível em <http://www.an.com.br>.
Acesso em 08 de setembro de 2004.
ANSELMO, Fernando. PHP 4 e Mysql. Florianópolis, Visual Books, 2002, 241p.
BARBOSA, Suzana. Jornalismo Digital e a Informação de Proximidade. Tese de Mestrado. BOCC Biblioteca On-Line de Ciências da Comunicação. Disponível em <http://www.bocc.ubi.pt/pag/barbosasuzana-portais-mestrado.pdf>. Acesso em 19 de setembro de 2004.
BERNARDO JUNIOR, Álvaro. C. Portal de Serviços M-commerce para Corretora Seguros
ALMAPA. Monografia (Graduação em Ciência da Computação). Centro de Ciências Tecnológicas,
da Terra e do Mar, Universidade do Vale do Itajaí.
BOOTH, David et al. Web Services Architecture. Desenvolvido por Web Services Architecture
Working Group. Disponível em: http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/. Acesso
em:15 ago. 2004.
CASTAGNELLO, J et al. Professional PHP Programando. São Paulo, Makron Books, 2000.
800p.
CEM. Cem palavras para gestão do conhecimento, Brasília: Ministério da Saúde, 2003.28 p. (Série F. Comunicação e Educação em Saúde)
CHINNICI, Roberto. Web Services Description Language (WSDL) Version 2.0 Part 1: Core
Language. Desenvolvido por Web Services Description Working Group. Disponível em
http://www.w3.org/TR/wsdl20/. Acesso em:15 ago. 2004.
CHRISTOFOLETTI, A. Modelos descrevendo processos climáticos. In: Modelagem de sistemas
ambientais. São Paulo: Edgard Blücher, 1998.
CONVERSE, Tim. PHP A Bíblia. Rio de Janeiro, Campus, 2003. 904p.
CORREA, Elizabeth Saad. As estratégias da desconstrução Sobre o uso de estratégias diferenciadas
por empresas informativas na internet. Tese de livre docência. ECA/USP, São Paulo, 2001.
COUGO, Paulo Sergio. Modelagem conceitual e projeto de bancos de dados. Rio de Janeiro,
Campus, 1997. 254p.
DEITEL, H.M; DEITEL, P J. Java Como Programar. São Paulo, Bookman, 2002. 1205p.
DIAS, Cláudia Augusto. Portal Corporativo: Conceitos e Características - Ci. Inf., Brasília, v30,
n.1,p. 50-60, jan./abr. 2001. Disponível em <http://www.ibict.br/cionline/300101/30010107.pdf>.
Acesso em 09 de setembro de 2004.
FEDOROV et al. ASP 2.0 Professional. Wrox, 1998.
FIELDS, F; KOLB, M. Web Development with Java Server Pages. Greenwich, Manning, 2000,
584p.
FOUCAULT, Alain. O Clima História e Dever do Meio Terreste. Fayard, 1993.
FOWLER, Martin. UML Essencial. São Paulo, Bookman, 2000. 169p.
GUDGIN, Martin; LEWIS, Amy; SCHLIMMER, Jeffrey. Web Services Description Language
(WSDL) Version 2.0 Part 2: Message Patterns. Desenvolvido por Web Services Description
Working Group. Disponível em http://www.w3.org/TR/wsdl20-patterns/. Acesso em:15 ago. 2004.
HE ,Hão et al. Web Services Architecture Usage Scenarios. Desenvolvido por Web Services
Architecture Working Group. Disponível em: http://www.w3.org/TR/2004/NOTE-ws-archscenarios-20040211/. Acesso em:15 ago. 2004.
JORGENSEN, David. Developing .Net Web Services with XML. Rockland: Syngress Publishing, Inc.,
2002.
JSP. JSP Tutorial. Disponível em <http://www.visualbuilder.com>. Acesso em 19/09/2004.
KURNIAWAN, Budi. Java para Web com Servlets, JSP e EJB. Rio de Janeiro, Ciência
Moderna, 2002, 702p.
LARMAN, Craig. Utilizando UML e padrões. Porto Alegre, Bookman, 2000, 465p.
LIMA, Walter. Mídia digital: o vigor das práticas jornalísticas em um novo espaço. Tese de
Doutorado ECA/USP. Disponível em <http://www.walterlima.jor.br>. Acesso em 19 de setembro de
2004.
MITRA, Nilo. SOAP Version 1.2 Part 0: Primer. Desenvolvido por XML Protocol Working
Group. Disponível em http://www.w3.org/TR/soap12-part0/. Acesso em:15 ago. 2004.
MORELLI NETO, José. Proposta de um padrão para comunicação de dados em um sistema de
telemetria baseado em Web services. Monografia (Graduação em Ciência da Computação).
Centro de Ciências Tecnológicas, da Terra e do Mar, Universidade do Vale do Itajaí.
OLIVEIRA, Eric. Web Services: Java e XML juntos pela interoperabilidade. Disponível em
<http://www.linhadecodigo.com.br>. Acesso em 18/10/2004.
PITS-MOULTIS, Natanya, KIRK, Cheryl. XML Black Book. São Paulo, Makron Books, 2000.
630p.
POOTS, Stephen; KOPACK, Mike. Aprenda em 24 horas Web Services. São Paulo, Campus,
2003. 367p.
POSTGRESQL. PostgreSQL Official Site. Disponível em <http://www.postgresql.org/>. Acesso em
10/09/2004.
PÓVOA, Marcello. Anatomia da internet, investigações estratégicas sobre o universo digital. Rio de
Janeiro, Casa da Palavra, 2000.
SADORNY, R. Clima Terra. Biblioteca Básica de Ciência e Cultura, Lisboa, 1994.
TESCH Jr, José Roberto. XML Schema. Florianópolis: Visual Books, 2002.
59
TOOD, Nick, SZOLKOWSKI, Mark. Java Server Pages. O Guia do Desenvolvedor. Rio de
Janeiro: Elsevier, 2003. 621p.
VIANELLO, R; ALVES, R. Meteorologia Básica e Aplicações. Viçosa: Universidade Federal
deViçosa (Imprensa Universitária), 1991, p.138.
XML. Extensible Markup Language (XML). World Wide Web Consortium. Disponível em
<http://www.w3.org/XML/>. Acesso em 10/09/2004.
60
GLOSSÁRIO
Anemômetro
Instrumento que mede a velocidade e força do vento.
Anticiclone
Pressão máxima relativa. Área de pressão que diverge os ventos numa
rotação oposta à rotação da Terra. Move-se no sentido horário no
Hemisfério Norte e no sentido anti-horário no Hemisfério Sul. Também
conhecida como área de alta pressão; é o oposto de uma área de baixa
pressão, ou ciclone.
Anticiclone
subtropical
Séries de células de alta pressão alinhadas aproximadamente ao longo de
uma linha de latitude em ambos os hemisférios. O eixo do cinturão se
localiza nos níveis baixos a cerca de 35° de latitude em média e tem um
pequeno deslocamento meridional anual.
Calmaria
Condições atmosféricas destituídas de vento ou de qualquer outro
movimento do ar. Em termos oceânicos, é a ausência aparente de
movimento da superfície de água, quando não há nenhum vento ou
ondulação.
Céu claro
O estado do céu sem nenhuma nuvem ou cobertura total menos de um
octa (1/8 de nuvens). vistos ou detectados do ponto de observação.
Chuva
É o resultado da condensação na atmosfera que caem em direção ao solo,
quando as gotas superam as correntes verticais de ar. Normalmente é
medida a altura da precipitação em milímetros.
Chuva artificial
Há casos de nuvens em que, embora a temperatura do ar esteja abaixo de
0ºC, a quantidade de núcleos de condensação existentes no ar é
insuficiente para produzir gotas em quantidade capaz de originar chuva.
Isso sugere suprir a nuvem com quantidades suficientes de núcleos para
produzir chuva. A introdução de núcleos na chuva é conhecida como
"semeadura". As partículas que irão atuar como núcleos são comumente o
iodeto de prata e o gelo seco (gás carbônico congelado). Elas são lançadas
de avião na base ou no topo das nuvens consideradas capazes de originar
precipitação. Maiores sucessos tem sido observados quando a semeadura é
feita com iodeto de prata no topo de nuvens cuja temperatura é menor que
- 13ºC. A semeadura das nuvens pode ser feita do solo pela produção de
fumaça de iodeto de prata. A fumaça é conduzida para cima, e as correntes
convectivas ascendentes podem fazer com que os núcleos de iodeto
atinjam a base das nuvens. Entretanto não se sabe qual a esperança
matemática do êxito. Além disso ficou comprovado que o iodeto de prata
perde sua capacidade de agir como núcleo higroscópio na presença de luz
solar (se dissocia produzindo prata metálica) e essa perda é tão mais
rápida quanto menor a umidade relativa do ar. As experiências
demonstram que é possível provocar precipitação embora seja discutível a
sua viabilidade econômica. O emprego de iodeto a partir do solo é mais
incerto porém, qualquer sistema necessita ser estudado com maiores
cuidados.
Chuvisco
Precipitação bastante uniforme, composta exclusivamentede gotas d'
água
muito pequenas (diâmetro menor que 0,5 mm), muito próximas umas das
outras e parecendo quase flutuar no ar.
Convecção
Movimentos internos organizados dentro de uma camada de ar,
produzindo o transporte vertical de calor. A convecção é essencial para a
formação de muitas nuvens, especialmente do tipo cumulus
Coordenadas
Universais
Tempo
Um dos vários nomes para as 24 horas do dia, usado pelas comunidades
do científicas e militares. Outros nomes para esta medida de tempo são Zulu
(Z), ou Tempo Médio de Greenwich (GMT).
Higrômetro
Higrômetro para determinar a umidade do ar utilizando a absorção do
vapor de água por uma substância química higroscópica.
Imagens de satélite
É uma representação espacial das interações entre a energia e a matéria,
detectada por um sistema sensor à bordo de um satélite.
Imagens de satélite
É uma representação espacial das interações entre a energia e a matéria,
detectada por um sistema sensor à bordo de um satélite.
Índice
vento
de frio do Cálculo de temperatura que considera os efeitos do vento e da temperatura
no corpo humano. Descreve a média da perda de calor num corpo humano
e a maneira como a temperatura é sentida. Não é a temperatura atual do ar.
Para um exemplo, veja o mapa de frio do vento.
Massa de ar
Em meteorologia é uma região da atmosfera em que a temperatura e a
umidade, no plano horizontal apresentam características uniformes
Massa de ar ártica
Massa de ar que se desenvolve ao redor do Ártico, caracterizada pelo frio
da superfície nas grandes altitudes. O limite desta massa de ar é
frequentemente definido como frente Ártica, uma característica semipermanente, semi-contínua. Quando esta massa de ar se move de sua
região de origem, pode ficar mais rasa em altura, na medida em que se
movimenta para o sul.
Meteorologia
Ciência que estuda a atmosfera e os fenômenos atmosféricos. Algumas
áreas da meteorologia abrangem estudos sobre agricultura aplicada,
astrometeorologia, aviação, dinâmica, hidrometeorologia operacional e
sinóptica, entre outros. Cientistas que estudam a atmosfera e os fenômenos
atmosféricos.
62
NOAA
Seção do Departamento de Comércio dos Estados Unidos. É a principal
organização do National Weather Service (Serviço Nacional de
Meteorologia dos Estados Unidos). Promove e qualifica medidas de
interesse do meio-ambiente mundial, enfatizando os recursos atmosféricos
e marinhos. Para informação adicional, contate o NOAA, situado em
Silver Spring, Maryland.
Pressão
É a força por unidade de área causada pelo peso da atmosfera sobre um
ponto, ou sobre a superfície da Terra. Também conhecida como pressão
atmosférica ou pressão barométrica.
Pressão atmosférica
Pressão exercida pela atmosfera sobre qualquer superfície, em virtude de
seu peso. Equivale ao peso de uma coluna de ar de corte transversal
unitário, que se estende desde um nível dado até o limite superior da
atmosfera. Sua medida pode ser expressa em milibares, em polegadas ou
em milímetros de mercúrio (Hg). É também conhecida como pressão
barométrica. A pressão atmosférica varia de lugar para lugar. Essa
variação é causada pela altitude e principalmente pela temperatura.
Previsão
Descrição detalhada de ocorrências futuras esperadas. A previsão do
tempo inclui o uso de modelos objetivos baseados em certos parâmetros
atmosféricos, mais a habilidade e experiência de um meteorologista.
Também chamada de prognóstico.
Satélite
Qualquer objeto que esteja na órbita de um corpo celeste, como a Lua, por
exemplo. O termo, porém, é frequentemente usado para definir objetos
fabricados pelo homem e que estejam na órbita da Terra de forma geoestacionária ou polar. Algumas das informações colhidas por satélites
meteorológicos, como o da série GOES, incluem temperatura nas camadas
superiores da atmosfera, umidade do ar e registro da temperatura do topo
das nuvens, da Terra e do oceano. Os satélites também acompanham o
movimento das nuvens para determinar a velocidade dos ventos altos,
rastreiam o movimento do vapor de água, acompanham o movimento e a
atividade solar, e transmitem dados para instrumentos meteorológicos ao
redor do mundo.
Satélite
polar
de
órbita Satélite cuja órbita inclui passagens próximas a ou sobre ambos os Pólos
da Terra.
Satélite
geoestacionário
Satélite que mantém a mesma posição relativa ao Equador, quando da
rotação da Terra.
Satélite
meteorológico
É um satélite destinado exclusivamente para recepção e transmissão de
informações meteorológicas. Existem duas classes, os geoestacionários e
os de órbita polar.
63
Sistema
pressão
Sistema
pressão
de
alta Área de máxima pressão atmosférica relativa, com ventos divergentes que
se deslocam numa rotação oposta à rotação da Terra. Movem-se no
sentido horário no Hemisfério Norte e no sentido anti-horário no
Hemisfério Sul. Também conhecida como anticiclone, é o oposto de uma
área de baixa pressão atmosférica, ou ciclone.
de
baixa Área de mínima pressão relativa do ar e de ventos convergentes, que
circulam na mesma direção da rotação da Terra no sentido anti-horário no
Hemisfério Norte e no sentido horário no Hemisfério Sul. Também
conhecido como ciclone, é o oposto de uma área de alta pressão, ou
anticiclone. Veja baixa fechada, baixa fria e baixa de corte para exemplos
adicionais.
Temperatura
É a quantidade de calor que existe no ar. Ela é medida pelo termômetro
meteorológico, que é diferente do termômetro clínico. A diferença entre a
maior e a menor temperatura chama-se amplitude térmica.
Temperatura máxima A mais alta das temperaturas máximas mensais observadas em um mês
absoluta
dado, durante um número determinado de anos.
Temperatura média
Média da leitura de temperaturas verificada num período específico de
tempo. Frequentemente a média entre temperaturas máxima e mínima.
Temperatura mínima A mais baixa das temperaturas mínimas mensais observadas em um mês
absoluta
dado, durante um número determinado de anos.
Umidade do ar
É a quantidade de vapor de água contida na atmosfera. Ao subirem para a
atmosfera, as gotículas de água se concentram, formando nuvens, ao se
resfriar, a água se precipita, em forma de chuva, por isso, a chuva é um
tipo de precipitação de água chamado de precipitação pluvial, o
instrumento que mede a umidade do ar é o higrotermômetro e o que
registra é o higrotermógrafo.
UTC
Coordenada de Tempo Universal, com referência ao Meridiano de
Greenwich (Inglaterra), equivalente ao horário de Londres, que
corresponde a 3 horas a mais em relação ao horário de Brasília.
Velocidade do Vento
Quantificação do movimento do ar numa unidade de tempo. Pode ser
medida de vários modos. Quando está em observação, é medida em nós,
ou milhas náuticas por hora. A unidade mais freqüentemente adotada nos
Estados Unidos é a de milhas por hora.
ZULU
Um dos vários nomes para as 24 horas do dia, usado pelas comunidades
científicas internacional e militares. Outros nomes para esta medida de
tempo são Coordenada Universal do Tempo (UTC) e Tempo Médio de
Greenwich (GMT).
64
APÊNDICE A – PCT01 ARMAZENAMENTO DE DADOS
Tabela 8. Descrição do Caso de Uso Armazena Imagens do Globo
Funcionalidades
Nome do Caso de Uso
Descrição
Ator(es)
Pré Condições
Pós Condições
Fluxo Principal
Armazenamento das imagens do
satélite
Fluxos alternativos
Fluxos de exceção
Problemas ao salvar a imagem
Problemas na geração da imagem
Descrição
UC01.01 Armazena Imagens do Globo
Armazena uma imagem do globo a partir do satélite
Satélite
O satélite deve enviar dados para o sistema
Imagens do satélite catalogadas no banco de dados.
Passo 1. Sistema recebe imagem do globo gerada pelo Satélite
Passo 2. Verifica horário para saber qual imagem está sendo
gerada
Passo 3. Imagem é salva no banco
Passo 4. Sistema registra log de cadastro efetivado
Não possui
No passo 3, caso imagem não seja salva no banco:
Passo 3.1 Sistema mostra uma mensagem avisando que a
operação não foi concluída
No passo 1, caso imagem não seja recebida:
Passo 1.1 Sistema mostra uma mensagem avisando que a
operação não foi concluída
Tabela 9. Descrição do Caso de Uso Armazena Dados Meteorológicos
Funcionalidades
Nome do Caso de Uso
Descrição
Ator(es)
Pré Condições
Pós Condições
Fluxo Principal
Armazenamento dos dados
meteorológicos
Descrição
UC01.02 Armazena Dados Meteorológicos
Armazena os dados meteorológicos a partir da estação
meteorológica
Estação meteorológica
A estação meteorológica deve enviar dados para o sistema.
Dados meteorológicos estão armazenados no banco de dados.
Passo 1. Sistema recebe dados meteorológicos da Estação em
arquivo txt
Passo 2. Mecanismo de importação coloca os dados no banco
Passo 3. Sistema registra no log que importação foi efetivada
Fluxos alternativos
Fluxos de exceção
Não possui
Problemas na importação do
No passo 2, caso arquivo não seja importado:
arquivo
Passo 2. Sistema mostra uma mensagem avisando que a
operação não foi concluída
Problemas com o arquivo
No passo 1, caso arquivo não seja recebido:
Passo 1.1 Sistema mostra uma mensagem avisando que a
operação não foi concluída
66
APÊNDICE B – PCT02 ADMINISTRAÇÃO DO SISTEMA
Tabela 10. Descrição do Caso de Uso Manutenção de Usuários
Funcionalidades
Nome do Caso de Uso
Descrição
Ator(es)
Pré Condições
Pós Condições
Fluxo Principal
Cadastra Usuário
Fluxos alternativos
Altera usuário
Exclui usuário
Cancela operação
Fluxos de exceção
Senha não confere
Usuário já existente
Descrição
UC02.01 Manutenção de Usuários
Permite a manutenção de usuários do sistema.
Professor, Colaborador
Um Professor precisa estar logado no sistema.
Uma usuário foi criado, alterado ou eliminado do sistema.
Passo 1. O sistema apresenta lista de usuários já cadastrados.
Passo 2. O professor opta por criar novo usuário.
Passo 3. O sistema apresenta uma tela para a inserção de
usuários
Passo 4. O professor preenche as informações.
Passo 5. O Professor confirma a operação
Passo 6. O sistema valida os dados.
Passo 7. Sistema efetua a gravação do usuário.
Passo 8. O sistema registra a ocorrência no histórico de uso.
Passo 9. O sistema volta ao passo 1.
No passo 2, o professor pode optar por alterar um usuário
Passo 2.1. O sistema apresenta a tela para edição de um usuário
preenchido com as informações do usuário selecionado.
Passo 2.2. O professor preenche as informações
Passo 2.3 O Professor confirma.
Passo 2.4 Retorna ao passo 5
No passo 2, o professor pode optar por excluir um usuário
Passo 2.1. O sistema apresenta uma tela de confirmação da
exclusão do usuário selecionado.
Passo 2.2. O professor confirma exclusão
Passo 2.3. Sistema exclui usuário selecionado.
Passo 2.4. Retorna ao passo 7.
Se no passo 5 do fluxo principal, 2.2 do fluxo Exclui Usuário
ou 2.3 do fluxo Altera Usuário o professor optar por cancelar a
exclusão, retorna ao passo 1 do fluxo principal.
No passo 6, caso os campos senha e confere senha não
apresentem informações identicas, apresenta mensagem "As
senhas digitadas não são iguais. Por favor, informar senha
novamente." E volta para o passo 4.
No passo 6, caso o login informado já exista, uma apresenta
mensagem e volta para o passo 4.
67
Inconsistência na validação dos
dados
No passo 6, caso os campos obrigatórios não tenham sido
preenchidos ou o formato não é válido, apresenta uma
mensagem.
Sistema retorna ao passo 4 ou 2.2.
Tabela 11. Descrição do Caso de Uso Fazer Previsão do Tempo
Funcionalidades
Nome do Caso de Uso
Descrição
Ator(es)
Pré Condições
Pós Condições
Fluxo Principal
Cadastrar previsão
Fluxos alternativos
Altera previsão
Exclui previsão
Descrição
UC02.02 Fazer Previsão do Tempo
Permite a manutenção da Previsão do Tempo
Professor, Colaborador
Estar logado no sistema.
Previsão do tempo para os próximos 3 dias.
Passo 1. Seleciona opção para "previsão do tempo"
Passo 2. Seleciona fazer uma nova previsão
Passo 3. Sistema apresenta ultima previsão realizada e contida
no banco como sugestão
Passo 4. Seleciona a região
Passo 5. Professor faz a previsão
Passo 6. Confirma as informações
Passo 7. O sistema valida as informações
Passo 8. O sistema insere as informações no banco
Passo 9. Vai para a tela “Detalhes’
No passo 2, o Professor seleciona “Detalhes” da previsão que
deseja alterar
2.1 Abre a tela para com os detalhes do dado selecionado
2.2 Professor seleciona “Editar”
2.2 Sistema apresenta a previsão realizadas no dia informado
2.3 Abre tela com informações da previsão
2.4 Professor faz as alterações
2.5 Professor confirma as informaçõs alteradas
2.6 Sistema processa os dados
2.7 Volta ao passo 2
No passo 2, o Professor seleciona “Detalhes” da previsão que
deseja alterar
2.1 Abre a tela para com os detalhes do dado selecionado
2.2 Professor seleciona “Excluir”
2.3 Sistema apresenta tela de confirmação da exclusão
2.4 Professor confirma as informações alteradas
2.5 Sistema processa os dados
2.6 Volta ao passo 2
Fluxos de exceção
68
Inconsistência na validação dos
dados
No passo 7, caso os campos obrigatórios não tenham sido
preenchidos ou o formato não é válido, apresenta uma
mensagem.
Não confirma as informações
Se no passo 6 do fluxo principal, 3.4 do fluxo Exclui Previsão
ou 3.5 do fluxo Altera Previsão, o professor optar por cancelar
a operação, retorna ao passo 1 do fluxo principal.
Não existe previsão no banco
No passo 3, caso não seja encontrada nenhuma previsão para o
ultimo dia, o sistema deixará os campos em branco, para que o
Professor possa então fazer a previsão.
Tabela 12. Descrição do Caso de Uso Fazer Previsão Marítima
Funcionalidades
Nome do Caso de Uso
Descrição
Ator(es)
Pré Condições
Pós Condições
Fluxo Principal
Cadastrar previsão
Fluxos alternativos
Altera previsão
Exclui previsão
Descrição
UC02.03 Fazer Previsão Marítima
Permite a manutenção da Previsão Marítima
Professor, Colaborador
Estar logado no sistema.
Previsão para os próximos 3 dias.
Passo 1. Seleciona opção para "previsão marítima"
Passo 2. Seleciona fazer uma nova previsão
Passo 3. Sistema apresenta ultima previsão realizada e contida
no banco como sugestão
Passo 4. Professor faz a previsão
Passo 5. Confirma as informações
Passo 6. O sistema valida as informações
Passo 7. O sistema insere as informações no banco
Passo 8. Vai para a tela “Detalhes’
No passo 2, o Professor seleciona “Detalhes” da previsão que
deseja alterar
2.1 Abre a tela para com os detalhes do dado selecionado
2.2 Professor seleciona “Editar”
2.2 Sistema apresenta a previsão realizada no dia informado
2.3 Abre tela com informações da previsão
2.4 Professor faz as alterações
2.5 Professor confirma as informaçõs alteradas
2.6 Sistema processa os dados
2.7 Volta a tela “Detalhes”
No passo 2, o Professor seleciona “Detalhes” da previsão que
deseja alterar
2.1 Abre a tela para com os detalhes do dado selecionado
69
2.2 Professor seleciona “Excluir”
2.3 Sistema apresenta tela de confirmação da exclusão
2.4 Professor confirma as informações alteradas
2.5 Sistema processa os dados
2.6 Volta a tela “Detalhes”
Fluxos de exceção
Inconsistência na validação dos
dados
No passo 6, caso os campos obrigatórios não tenham sido
preenchidos ou o formato não é válido, apresenta uma
mensagem.
Não confirma as informações
Se no passo 5 do fluxo principal, 3.4 do fluxo Exclui Previsão
ou 3.5 do fluxo Altera Previsão, o professor optar por cancelar
a operação, retorna ao passo 1 do fluxo principal.
Não existe previsão no banco
No passo 3, caso não seja encontrada nenhuma previsão para o
ultimo dia, o sistema deixará os campos em branco, para que o
Professor possa então fazer a previsão.
Tabela 13. Descrição do Caso de Uso Geração de Relatórios
Funcionalidades
Nome do Caso de Uso
Descrição
Ator(es)
Pré Condições
Pós Condições
Fluxo Principal
Geração de relatórios
Fluxos alternativos
Fluxos de exceção
Descrição
UC02.04 Geração de Relatórios
Geração de Relatórios dos dados meteorológicos vindos da
estação meteorológica
Professor, Colaborador
Estar logado no sistema.
Visualizar relatório com as informações desejadas
Depois de selecionar qualquer opção do sistema, o professor
tem a opção de gerar relatórios
1. Professor seleciona opção para gerar relatórios [Gera PDF]
2. Sistema processa informações
3. Tela de relatórios é mostrada com informações processadas
4. Professor escolhe se deseja imprimir ou salvar
5. Volta a opção 1
Não possui
Não possui
Tabela 14. Descrição do Caso de Uso Login
Funcionalidades
Nome do Caso de Uso
Descrição
Descrição
UC02.05 Login
Possibilita entrada na parte administrativa do sistema
70
Ator(es)
Pré Condições
Pós Condições
Fluxo Principal
Fazer login
Fluxos alternativos
Fluxos de exceção
Falha no login
Professor, Colaborador
Possuir um login e uma senha para entrar no sistema.
Dispor dos recursos do sistema.
1. Abre tela de login
2. Usuario entra com seu login e senha
3. Sistema valida os dados
4. Abre tela principal do sistema
Não possui
No passo 3:
3.1 O sistema verifica que login ou senha são inválidos
3.2 O sistema mostra tela de aviso <<Login e/ou senha
invalidos>>
Tabela 15. Descrição do Caso de Uso Recados
Funcionalidades
Nome do Caso de Uso
Descrição
Ator(es)
Pré Condições
Pós Condições
Fluxo Principal
Insere Recado
Fluxos alternativos
Altera recado
Exclui recado
Descrição
UC02.06 Recados
Criação, alteração e exclusão de recados do sistema
Professor, Colaborador
Estar logado no sistema.
Recado inserido no banco de dados
1. Professor clica em "Recados"
2. Abre tela mostrando os últimos recados e campos para novo
recado
3. Professor preenche os campos do novo recado
4. Professor confirma
5. Sistema valida as informações
6. Sistema insere no banco de dados
7. Volta ao passo 2
No passo 2, o Professor seleciona “Detalhes” do recado que
deseja alterar
2.1 Abre a tela para com os detalhes do dado selecionado
2.2 Professor seleciona “Editar”
2.2 Sistema apresenta o recado selecionado
2.3 Abre tela com informações do recado
2.4 Professor faz as alterações
2.5 Professor confirma as informações alteradas
2.6 Sistema processa os dados
2.7 Volta ao passo 2
No passo 2, o Professor seleciona “Detalhes” do recado que
deseja alterar
2.1 Abre a tela para com os detalhes do dado selecionado
71
2.2 Professor seleciona “Excluir”
2.3 Sistema apresenta tela de confirmação da exclusão
2.4 Professor confirma as informações alteradas
2.5 Sistema processa os dados
2.6 Volta ao passo 2
Fluxos de exceção
Inconsistência na validação dos
dados
No passo 5, caso os campos obrigatórios não tenham sido
preenchidos ou o formato não é válido, apresenta mensagem
"Verifique os seguintes campos: <<listar campos>>."
Problemas no banco de dados
No passo 6, caso os dados não sejam inseridos no banco o
sistema mostra uma tela dizendo "Os dados não foram inseridos
no banco" e retorno para o passo 3
Cancela operação
Se no passo 4 do fluxo principal, 2.4 do fluxo Exclui Recado ou
do 2.5 do fluxo Altera Recado o professor optar por cancelar a
operação, retorna ao passo 1 do fluxo principal.
Tabela 16. Descrição do Caso de Uso Armazena Fases da Lua
Funcionalidades
Nome do Caso de Uso
Descrição
Ator(es)
Pré Condições
Pós Condições
Fluxo Principal
Armazena dados
Fluxos alternativos
Altera dados
Descrição
UC02.07 Armazena Fases da Lua
Mecanismo de importação para as fases da lua
Professor, Colaborador
Possui o arquivo com as informações das fases da lua
Informações inseridas no banco de dados
1. Professor clica em "Recados"
2. Abre tela mostrando os últimos recados e campos para novo
recado
3. Professor preenche os campos do novo recado
4. Professor confirma
5. Sistema valida as informações
6. Sistema insere no banco de dados
7. Volta ao passo 2
No passo 2, o Professor seleciona “Detalhes” do recado que
deseja alterar
2.1 Abre a tela para com os detalhes do dado selecionado
2.2 Professor seleciona “Editar”
2.2 Sistema apresenta o recado selecionado
2.3 Abre tela com informações do recado
2.4 Professor faz as alterações
2.5 Professor confirma as informações alteradas
2.6 Sistema processa os dados
72
2.7 Volta a tela “Detalhes”
Exclui dados
Fluxos de exceção
Problemas na importação do
arquivo
No passo 2, o Professor seleciona “Detalhes” do recado que
deseja alterar
2.1 Abre a tela para com os detalhes do dado selecionado
2.2 Professor seleciona “Excluir”
2.3 Sistema apresenta tela de confirmação da exclusão
2.4 Professor confirma as informações alteradas
2.5 Sistema processa os dados
2.6 Volta a tela “Detalhes”
No passo 6, caso arquivo não seja importado:
6.1 Sistema registra log que a importação não foi efetivada e
encerra o caso de uso
Tabela 17. Descrição do Caso de Uso Visualiza Criticas e Sugestões
Funcionalidades
Nome do Caso de Uso
Descrição
Ator(es)
Pré Condições
Pós Condições
Fluxo Principal
Visualiza sugestões
Fluxos alternativos
Exclui sugestões
Fluxos de exceção
Descrição
UC02.08 Visualiza Criticas e Sugestões
Possibilita visualizar e excluir as criticas e sugestões postadas
no web site.
Professor, Colaborador
Estar logado no sistema.
Mensagens lidas
1. Ao logar no sistema aparece listadas na tela as mensagem
que anda não foram lidas pelo professor
2. Professor clica no titulo da mensagem
3. Abre mensagem na tela
4. Professor lê a mensagem
5. Professor seleciona voltar
6. Volta ao passo 1
No passo 2 do fluxo principal, ao invés do professor selecionar
o titulo da mensagem ele seleciona a opção "Excluir".
2.1 Abre a tela de confirmação
2.2 Professor confirma
2.3 Mensagem é excluída
Não possui
73
Tabela 18. Descrição do Caso de Uso Tábuas da Maré
Funcionalidades
Nome do Caso de Uso
Descrição
Ator(es)
Pré Condições
Pós Condições
Fluxo Principal
Cadastra Tábua
Fluxos alternativos
Altera Tábua
Exclui Tábua
Fluxos de exceção
Descrição
UC02.09 Tábua da Maré
Possibilita visualizar, editar e excluir as informações das
Tábuas da Maré
Professor, Colaborador
Estar logado no sistema.
Possuir os portos cadastrados nos sistema
1. Professor clica em "Tábuas da Maré"
2. Abre tela mostrando dados existentes
3. Professor seleciona a opção "Novo"
4. Professor preenche os campos
5. Professor confirma
6. Sistema valida as informações
7. Sistema insere no banco de dados
8. Vai para tela de "Detalhes"
No passo 2:
2.1 Professor seleciona "Detalhes"
2.2 O Professor seleciona "Editar"
2.3. Professor altera os campos
2.4. Professor confirma
2.5. Sistema valida as informações
2.6. Sistema insere no banco de dados
2.7. Volta ao passo 2
No passo 2:
2.1 Professor seleciona "Detalhes"
2.2 O Professor seleciona "Excluir"
2.3. Professor altera os campos
2.4. Professor envia
2.5 Abre tela de confirmação
2.6 Professor confirma
2.7. Sistema valida as informações
2.8. Sistema insere no banco de dados
2.9. Volta ao passo 2
Não possui
Tabela 19. Descrição do Caso de Uso Região
Funcionalidades
Nome do Caso de Uso
Descrição
Descrição
UC02.10 Região
Possibilita visualizar, editar e excluir as regiões da previsão do
tempo
74
Ator(es)
Pré Condições
Pós Condições
Fluxo Principal
Cadastra Região
Fluxos alternativos
Editar Região
Exclui Região
Fluxos de exceção
Professor, Colaborador
Estar logado no sistema.
Mensagens lidas
1. Professor clica em "Regiões"
2. Abre tela mostrando dados existentes
3. Professor seleciona a opção "Novo"
4. Professor preenche os campos
5. Professor confirma
6. Sistema valida as informações
7. Sistema insere no banco de dados
8. Vai para tela de "Detalhes"
No passo 2:
2.1 Professor seleciona "Detalhes"
2.2 O Professor seleciona "Editar"
2.3. Professor altera os campos
2.4. Professor confirma
2.5. Sistema valida as informações
2.6. Sistema insere no banco de dados
2.7. Volta ao passo 2
No passo 2:
2.1 Professor seleciona "Detalhes"
2.2 O Professor seleciona "Excluir"
2.3. Professor altera os campos
2.4. Professor envia
2.5 Abre tela de confirmação
2.6 Professor confirma
2.7. Sistema valida as informações
2.8. Sistema insere no banco de dados
2.9. Volta ao passo 2
Não possui
Tabela 20. Descrição do Caso de Uso Áreas
Funcionalidades
Nome do Caso de Uso
Descrição
Ator(es)
Pré Condições
Pós Condições
Fluxo Principal
Visualiza sugestões
Descrição
UC02.11 Áreas
Possibilita visualizar, editar e excluir as áreas da previsão
marítima
Professor, Colaborador
Estar logado no sistema.
Mensagens lidas
1. Professor clica em "Áreas"
2. Abre tela mostrando dados existentes
3. Professor seleciona a opção "Novo"
4. Professor preenche os campos
75
Fluxos alternativos
Editar Área
Exclui Área
Fluxos de exceção
5. Professor confirma
6. Sistema valida as informações
7. Sistema insere no banco de dados
8. Vai para tela de "Detalhes"
No passo 2:
2.1 Professor seleciona "Detalhes"
2.2 O Professor seleciona "Editar"
2.3. Professor altera os campos
2.4. Professor confirma
2.5. Sistema valida as informações
2.6. Sistema insere no banco de dados
2.7. Volta ao passo 2
No passo 2:
2.1 Professor seleciona "Detalhes"
2.2 O Professor seleciona "Excluir"
2.3. Professor altera os campos
2.4. Professor envia
2.5 Abre tela de confirmação
2.6 Professor confirma
2.7. Sistema valida as informações
2.8. Sistema insere no banco de dados
2.9. Volta ao passo 2
Não possui
Tabela 21. Descrição do Caso de Uso Por do Sol
Funcionalidades
Nome do Caso de Uso
Descrição
Ator(es)
Pré Condições
Pós Condições
Fluxo Principal
Cadastra por do sol
Fluxos alternativos
Altera dados
Descrição
UC02.12 Pôr do Sol
Possibilita inserir, alterar e excluir dados para o por do sol
Professor, Colaborador
Ter selecionado a opção “Pôr do Sol”
Informações inseridas no banco de dados
1. Professor clica em "Por do Sol"
2. Abre tela mostrando dados existentes
3. Professor seleciona a opção "Novo"
4. Professor preenche os campos
5. Professor confirma
6. Sistema valida as informações
7. Sistema insere no banco de dados
8. Vai para tela de "Detalhes
No passo 2:
2.1 Professor seleciona "Detalhes"
2.2 O Professor seleciona "Editar"
2.3. Professor altera os campos
2.4. Professor confirma
76
Exclui dados
Fluxos de exceção
2.5. Sistema valida as informações
2.6. Sistema insere no banco de dados
2.7. Volta ao passo 2
No passo 2:
2.1 Professor seleciona "Detalhes"
2.2 O Professor seleciona "Excluir"
2.3. Professor altera os campos
2.4. Professor envia
2.5 Abre tela de confirmação
2.6 Professor confirma
2.7. Sistema valida as informações
2.8. Sistema insere no banco de dados
2.9. Volta ao passo 2
Tabela 22 Descrição do Caso de Uso Satélite
Funcionalidades
Nome do Caso de Uso
Descrição
Ator(es)
Pré Condições
Pós Condições
Fluxo Principal
Cadastra por do sol
Fluxos alternativos
Altera dados
Exclui dados
Descrição
UC02.13 Satélite
Possibilita inserir, alterar e excluir as imagens do satélite
Professor, Colaborador
Ter selecionado a opção “Satélite”
Informações inseridas no banco de dados
1. Professor clica em "Satélite"
2. Abre tela mostrando dados existentes
3. Professor seleciona a opção "Novo"
4. Seleciona a imagem
5. Professor confirma
6. Sistema valida as informações
7. Sistema insere no banco de dados
8. Vai para tela de "Detalhes
No passo 2:
2.1 Professor seleciona "Detalhes"
2.2 O Professor seleciona "Editar"
2.3. Professor altera os campos
2.4. Professor confirma
2.5. Sistema valida as informações
2.6. Sistema insere no banco de dados
2.7. Volta ao passo 2
No passo 2:
2.1 Professor seleciona "Detalhes"
2.2 O Professor seleciona "Excluir"
2.3. Professor altera os campos
2.4. Professor envia
2.5 Abre tela de confirmação
2.6 Professor confirma
77
Fluxos de exceção
2.7. Sistema valida as informações
2.8. Sistema insere no banco de dados
2.9. Volta ao passo 2
Tabela 23 Descrição do Caso de Uso Estação
Funcionalidades
Nome do Caso de Uso
Descrição
Ator(es)
Pré Condições
Pós Condições
Fluxo Principal
Cadastra por do sol
Fluxos alternativos
Altera dados
Exclui dados
Fluxos de exceção
Descrição
UC02.14 Estação
Possibilita inserir, alterar e excluir dados para os dados
meteorológicos vindos da estação
Professor, Colaborador
Ter selecionado a opção “Estação”
Informações inseridas no banco de dados
1. Professor clica em "Estação"
2. Abre tela mostrando dados existentes
3. Professor seleciona a opção "Novo"
4. Professor preenche os campos
5. Professor confirma
6. Sistema valida as informações
7. Sistema insere no banco de dados
8. Vai para tela de "Detalhes
No passo 2:
2.1 Professor seleciona "Detalhes"
2.2 O Professor seleciona "Editar"
2.3. Professor altera os campos
2.4. Professor confirma
2.5. Sistema valida as informações
2.6. Sistema insere no banco de dados
2.7. Volta ao passo 2
No passo 2:
2.1 Professor seleciona "Detalhes"
2.2 O Professor seleciona "Excluir"
2.3. Professor altera os campos
2.4. Professor envia
2.5 Abre tela de confirmação
2.6 Professor confirma
2.7. Sistema valida as informações
2.8. Sistema insere no banco de dados
2.9. Volta ao passo 2
78
APÊNDICE C – PCT03 ÁREA PÚBLICA
Tabela 24. Descrição do Caso de Uso Visualiza Previsão do Tempo
Funcionalidades
Nome do Caso de Uso
Descrição
Ator(es)
Pré Condições
Pós Condições
Fluxo Principal
Consulta previsão
Fluxos alternativos
Fluxos de exceção
Descrição
UC03.01 Visualiza Previsão do Tempo
Possibilita o visitante obter a previsão do tempo para os 3
próximos dias
Visitante
Ter clicado na opção "Previsão do Tempo".
Visualização da previsão do tempo
1. Visitante seleciona opção "Previsão do tempo"
2. O sistema processa as informações
3. Abre a tela com os dados da Previsão do tempo
Não possui
Não possui
Tabela 25. Descrição do Caso de Uso Visualiza Previsão Marítima
Funcionalidades
Nome do Caso de Uso
Descrição
Ator(es)
Pré Condições
Pós Condições
Fluxo Principal
Consulta previsão
Fluxos alternativos
Fluxos de exceção
Descrição
UC03.02 Visualiza Previsão Marítima
Possibilita o visitante obter a previsão marítima para os 3
próximos dias
Visitante
Ter clicado na opção "Previsão Marítima".
Visualização da previsão marítima
1. Visitante seleciona opção "Previsão Marítima"
2. O sistema processa as informações
3. Abre a tela com os dados da Previsão Marítima
Não possui
Não possui
Tabela 26. Descrição do Caso de Uso Consulta Dados Meteorológicos
Funcionalidades
Nome do Caso de Uso
Descrição
Ator(es)
Pré Condições
Pós Condições
Fluxo Principal
Descrição
UC03.03 Consulta Dados Meteorológicos
Possibilita o visitante a informações dos dados meteorológicos
Visitante
Ter clicado na opção " Dados Meteorológicos ".
Visualização dos dados meteorológicos
79
Consulta previsão
Fluxos alternativos
Fluxos de exceção
1. Visitante seleciona opção " Dados Meteorológicos "
2. O sistema processa as informações
3. Abre a tela com os dados meteorológicos
Não possui
Não possui
Tabela 27. Descrição do Caso de Uso Consulta Imagens do Satélite
Funcionalidades
Nome do Caso de Uso
Descrição
Ator(es)
Pré Condições
Pós Condições
Fluxo Principal
Consulta previsão
Fluxos alternativos
Fluxos de exceção
Descrição
UC03.04 Consulta Imagens do Satélite
Possibilita o visitante visualizar imagens de satélite do leste do
globo e da América do Sul
Visitante
Ter clicado na opção “Imagens de Satélite“.
Visualização das imagens de satélite
1. Visitante seleciona opção " Imagens de Satélite "
2. O sistema processa as informações
3. Abre a tela com as imagens
Não possui
Não possui
Tabela 28. Descrição do Caso de Uso Consulta Pôr do Sol
Funcionalidades
Nome do Caso de Uso
Descrição
Ator(es)
Pré Condições
Pós Condições
Fluxo Principal
Consulta previsão
Fluxos alternativos
Fluxos de exceção
Descrição
UC03.05 Consulta Pôr do Sol
Possibilita o visitante obter os horários do pôr do sol
Visitante
Ter clicado na opção “Pôr do Sol“.
Visualização dos horários do pôr do sol
1. Visitante seleciona opção " Pôr do Sol "
2. O sistema processa as informações
3. Abre a tela com as informações
Não possui
Não possui
Tabela 29. Descrição do Caso de Uso Fases da Lua
Funcionalidades
Nome do Caso de Uso
Descrição
Ator(es)
Pré Condições
Pós Condições
Descrição
UC03.06 Consulta Fases da Lua
Possibilita o visitante obter as informações das fases da lua
Visitante
Ter clicado na opção “Fases da Lua“.
Visualização das informações das fases da lua
80
Fluxo Principal
Consulta previsão
Fluxos alternativos
Fluxos de exceção
1. Visitante seleciona opção "Fases da Lua"
2. O sistema processa as informações
3. Abre a tela com as informações
Não possui
Não possui
Tabela 30. Descrição do Caso de Uso Envia Criticas e Sugestões
Funcionalidades
Nome do Caso de Uso
Descrição
Ator(es)
Pré Condições
Pós Condições
Fluxo Principal
Envia sugestão
Fluxos alternativos
Fluxos de exceção
Campo em branco
Erro no banco de dados
Descrição
UC03.07 Envia Criticas e Sugestões
Possibilita o visitante enviar criticas e sugestões para os
administradores do site
Visitante
Ter clicado na opção “Enviar Criticas e Sugestões “.
Sugestão enviada
1. Sistema apresenta Formulário.
2. Visitante preenche o formulário.
3. Sistema valida preenchimento.
4. Sistema coloca informações no banco de dados
5. Sistema apresenta mensagem "Obrigado por colaborar para a
melhora do nosso site!"
Não possui
No passo 3, caso alguma questão não tenha sido assinalada,
apresenta mensagem "Por favor, responda a todas as questões."
No passo 4, caso tenha dado algum problema ao inserir as
informações do formulário o sistema mostra uma tela dizendo
"Não foi possível inserir seus dados no nosso banco! Tente
novamente"
Tabela 31. Descrição do Caso de Uso Visualiza Recados
Funcionalidades
Nome do Caso de Uso
Descrição
Ator(es)
Pré Condições
Pós Condições
Fluxo Principal
Consulta previsão
Fluxos alternativos
Fluxos de exceção
Descrição
UC03.08 Visualiza Recados
Possibilita o visitante ter acesso a informações importantes
Visitante
Ter entrado no site
Visualização do recado
1. Visitante entra no site
2. Visitante visualiza recado
Não possui
Não possui
81
APÊNDICE D – PCT04 WEB SERVICES
Tabela 32. Descrição do Caso Solicita dados meteorológicos
Funcionalidades
Nome do Caso de Uso
Descrição
Ator(es)
Pré Condições
Pós Condições
Fluxo Principal
Consulta previsão
Fluxos alternativos
Fluxos de exceção
Inconsistência na validação dos
dados
Descrição
UC04.01 Solicita dados meteorológicos
Cliente obtém dados meteorológicos através do web service
Cliente
Ter acesso ao web service.
Dados meteorológicos em formato XML
1. Cliente passa os parâmetros através do link de quais dados
meteorológicos ele necessita e em qual período de tempo
2. Sistema processa as informações
3. Cliente recebe dados em formato XML
Não possui
No passo 1, caso os campos obrigatórios não tenham sido
preenchidos ou o formato não é válido, apresenta mensagem
"Verifique os seguintes campos: <<listar campos>>.
82
APÊNDICE E – MODELAGEM DOS DADOS
cd 4.1 Modelo de Dados
tb_recados
*PK «column» id_recado: integer
*
«column» titulo_recado: text
*
«column» recado: text
+
+
«PK» PK_Recados(integer)
«unique» UQ_id_recado()
tb_regiao
*PK «column» id_regiao: integer
*
«column» nome_regiao: varchar(40)
+
+
«PK» PK_tb_regiao(integer)
«unique» UQ_id_regiao()
tb_prev isao_tempo
*PK
*
*
*
*
*
*
*
*
*
tb_fases_da_lua
*
«column»
«column»
«column»
«column»
«column»
«column»
«column»
«column»
«column»
«column»
«column»
«column»
id_prev_tempo: integer = 0
data: timestamp
data_previsao: timestamp
hora: timestamp
temperatura_min: real
temperatura_max: real
vento: text
estado_mar: text
imagem_tempo: varchar(50)
regiao: varchar(50)
previsao: text
id_regiao: integer
+
+
+
«PK» PK_previsao_tempo(integer)
«unique» UQ_id_prev_tempo(integer)
«FK» id_regiao()
+
+
«PK» PK_tb_tipo_imagem(integer)
«unique» UQ_id_tipo_imagem(integer)
*PK
*
*
*
*
«column»
«column»
«column»
«column»
«column»
+
+
+
«PK» PK_Imagens_satelite(integer)
«unique» UQ_id_imagem(integer)
«FK» id_tipo_imagem()
tb_imagens_satelite
id_imagem: integer
data: varchar(50)
hora: varchar(50)
path_imagem: varchar(100)
id_tipo_imagem: varchar(50)
tb_tabua_mare
*PK «column» id_tabua: integer
*
«column» cod_porto: integer
*
«column» nome_porto: varchar(100)
+
+
«PK» PK_tb_tabua_mare(integer)
«unique» UQ_id_tabua()
arquiv o
*PK «column» arq_id: integer
«column» arq_nome: varchar(250)
*
«column» arq_status: boolean
+
+
tb_dados_meteorologicos
*PK
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
«column»
«column»
«column»
«column»
«column»
«column»
«column»
«column»
«column»
«column»
«column»
«column»
«column»
«column»
«column»
«column»
«column»
«column»
+
+
«PK» PK_dados_meteorologicos(integer)
«unique» UQ_id_dados_meteor(integer)
*PK «column»
«column»
«column»
«column»
«column»
«column»
«column»
«column»
*
+
+
oper_id: integer
oper_nome: varchar(150)
oper_login: varchar(30)
oper_senha: varchar(32)
oper_ativo: boolean
oper_defs: boolean
oper_anon: boolean
oper_email: varchar(255)
«PK» PK_operadores(integer)
«unique» UQ_oper_id(integer)
+
+
«PK» PK_fases_da_lua(integer)
«unique» UQ_id_fases(integer)
*PK
*
*
*
*
*
*
*
*
*
*
«column»
«column»
«column»
«column»
«column»
«column»
«column»
«column»
«column»
«column»
«column»
+
+
«PK» PK_Por_do_sol(integer)
«unique» UQ_id_por_do_sol(integer)
id_por_do_sol: integer
data: varchar(50)
astro_am: varchar(50)
naut_am: varchar(50)
civil_am: varchar(50)
nascer: varchar(50)
por_sol: varchar(50)
astro_pm: varchar(50)
naut_pm: integer
civil_pm: varchar(50)
horas_luz: varchar(50)
tb_prev isao_maritma
*PK «column» id_area:
*
«column» nome_area: varchar(40)
+
+
+
*PK
*
*
*
«column»
«column»
«column»
«column»
+
+
«PK» PK_previsao_maritma(integer)
«unique» UQ_id_prev_maritima(integer)
id_prev_maritima: integer
data: varchar(50)
data_previsao: varchar(50)
horario_previsao: varchar(50)
*
*
*
«column»
«column»
«column»
«column»
«column»
«column»
«column»
+
+
«FK» id_prev_mar()
«FK» id_area()
«PK» PK_tb_area()
«unique» UQ_id_area()
«unique» UQ_id_regiao()
arq_mod
*
*
*
+
+
*PK «column» id_auditoria: integer
*
«column» ip: varchar(20)
«column» mensagem: text
*
«column» id_oper: integer
operadores
id_fases: integer
fase: varchar(50)
lunacao: integer
hora: integer
data: timestamp
tb_dados_maritimos
tb_log
«PK» PK_Auditoria(integer)
«unique» UQ_id_auditoria()
«FK» id_oper()
id_dados_meteor: integer
date: varchar(12)
time: varchar(10)
th_index: real
temp_out: real
wind_chill: real
hi_temp: real
low_temp: real
hum_out: real
dew_pt: real
wind_speed: real
hi: real
dir: varchar(5)
rain: real
bar: real
temp_in: real
hum_in: real
arc_per: real
tb_area
«PK» PK_arquivo(integer)
«unique» UQ_arq_id(integer)
+
+
+
«column»
«column»
«column»
«column»
«column»
tb_por_do_sol
tb_tipo_imagem
*PK «column» id_tipo_imagem: integer
*
«column» nome: varchar(50)
*PK
*
*
*
«column» mod_id: integer
«column» arq_id: integer
«column» principal: boolean
«FK» arq_id()
«FK» mod_id()
permissoes
*
*
«column» perm_oper_id: integer
«column» perm_mod_id: integer
«column» perm_defs: boolean
+
+
«FK» perm_oper_id()
«FK» perm_mod_id()
modulos
*PK «column»
«column»
«column»
«column»
«column»
«column»
«column»
+
+
mod_id: integer
mod_abrv: varchar(20)
mod_nome: varchar(150)
mod_desc: varchar(250)
mod_sup_id: integer
mod_pos_menu: integer
mod_ord_menu: integer
«PK» PK_modulos(integer)
«unique» UQ_mod_id(integer)
conexoes
tb_contato
*PK «column» id_contato: integer
*
«column» nome: varchar(100)
«column» mensagem: text
«column» ip: varchar(16)
+
+
id_prev_mar: integer
id_area: integer
distancia_costa: integer
vento: varchar(12)
velocidade_vento: real
ondas_direcao: varchar(10)
ondas_altura: real
«PK» PK_tb_contato(integer)
«unique» UQ_id_contato(integer)
83
*PK «column»
«column»
«column»
«column»
«column»
«column»
«column»
«column»
+
+
+
cnx_id: integer
cnx_oper_id: integer
cnx_semente: varchar(10)
cnx_hash: varchar(32)
cnx_ativa: integer
cnx_saida: timestamp
cnx_entrada: timestamp
cnx_expira: timestamp
«PK» PK_conexoes(integer)
«unique» UQ_cnx_id(integer)
«FK» cnx_oper_id()
Tabela 33. Dicionário de dados da tabela tb_dados_meteorologicos
Nome do atributo
id_dados_meteor
Tipo
integer
Date
varchar(12)
Descrição
Código do dado meteorológico –
Chave primária
Data da coleta dos dados do satélite
Time
varchar(10)
Hora da coleta dos dados do satélite
th_index
real
Índice de desconforto térmico
(temperatura + umidade)
temp_out
real
Temperatura Ambiente
wind_chill
real
Índice de resfriamento pelo vento
(temperatura + vento)
hi_temp
real
Temperatura Máxima
low_temp
real
Temperatura mínima
hum_out
real
Umidade
dew_pt
wind_speed
Hi
Dir
Rain
Bar
Ponto de Orvalho
real
Velocidade do Vento
real
velocidade máxima do vento
real
Direção do Vento
varchar(5)
Quantidade de chuva
real
Pressão Atmosférica
temp_in
real
real
hum_in
real
Umidade interna do laboratório
arc_per
real
Medida interna do laboratório
Temperatura interna do laboratório
84
Tabela 34. Dicionário de dados da tabela tb_fases_da_lua
Nome do atributo
id_fases
Tipo
integer
fase
varchar(50)
Descrição
Código para controle do banco –
Chave primária
Fase da Lua
lunacao
integer
Código de Lunação
data
integer
Data
hora
integer
hora da previsão
Tabela 35. Dicionário de dados da tabela tb_imagens_satelite
Nome do atributo
id_imagem
Tipo
integer
data
varchar(50)
hora
varchar(50)
path_imagem
varchar(100)
tipo_imagem
varchar(50)
Descrição
Índice para controle do banco
Primary Key; Not Null; Unique;
Data que a imagem do satelite foi
gerada
Hora em que a imagem do satelite foi
gerada
Nome da imagem e caminho onde a
imagem estará localizada
Tipo da imagem
Tabela 36. Dicionário de dados da tabela tb_tipo_imagem
Nome do atributo
id_tipo_imagem
Nome
Tipo
integer
varchar(50)
Descrição
Código para controle do banco – Chave primária
Nome do local de origem da imagem
Tabela 37. Dicionário de dados da tabela tb_log
Nome do atributo
id_auditoria
id_usuario
Tipo
integer
integer
ip
varchar(20)
mensagem
text
Descrição
Código para controle do banco – Chave primária
Chave estrangeira que faz referencia a tabela
operadores
ip do usuario
Mensagem gerada pelo sistema com a ação
ocorrida
85
Tabela 38. Dicionário de dados da tabela tb_por_do_sol
Nome do atributo
id_por_do_sol
Tipo
integer
Descrição
Código para controle do banco –
Chave primária
Data
Data
Date
astro_am
Hour
Hora do nascer do sol, isto para quem
está voando.
naut_am
Hour
Hora do nascer do sol, só para quem
está no mar.
civil_am
Hour
Nascer do sol, para quem está a nivel
terrestre
Nascer
por_sol
astro_pm
Hour
Hour
Hour
naut_pm
Hour
civil_pm
Hour
horas_luz
Hour
horario do nascer do sol
horario do por do sol
Hora do por do sol, isto para quem
está voando.
Hora do Por do sol, só para quem está
no mar.
Por do Sol, para quem está a nivel
terrestre
Quantidade de luz neste dia
Tabela 39. Dicionário de dados da tabela tb_previsao_maritima
Nome do atributo
id_prev_maritima
data
data_previsao
hora
analise_sinotica
Tipo
integer
Date
Date
time
Hour
Descrição
Chave Primaria.
Data em que foi feita a previsão
Data para qual foi feita a previsão
Horário que foi feita a previsão
Analise sinótica
Tabela 40. Dicionário de dados da tabela tb_dados_maritima
Nome do atributo
id_prev_mar
Tipo
integer
id_area
integer
distancia_costa
vento
velocidade_vento
ondas_direcao
ondas_altura
integer
varchar(12)
integer
varchar(10)
real
Descrição
Chave Estrangeira que faz referencia
a tabela tb_previsao_maritima.
Chave Estrangeira que faz referencia
a tabela tb_area.
Inteiro que diz a distancia da costa
Direção do vento
Velocidade do vento
Direção das ondas
Altura das ondas
86
Tabela 41. Dicionário de dados da tabela tb_previsao_tempo
Nome do atributo
id_prev_tempo
data
data_previsao
hora
temperatura_min
temperatura_max
vento
estado_mar
imagem_tempo
regiao
Tipo
integer
Date
Date
Hour
real
real
text
text
varchar(50)
varchar(50)
Descrição
Índice para controle do banco
Data em que foi feita a previsão
Data para a qual foi feita a previsão
Horário da previsão
Temperatura mínima do dia
Temperatura Máxima do Dia
Condições do Vento
Condições do Mar
Imagem do tempo (picture)
Região da Previsão
Tabela 42. Dicionário de dados da tabela tb_recados
Nome do atributo
id_recado
titulo_recado
Recado
Tipo
integer
text
text
Descrição
Índice para controle do banco
Titulo do recado
Recado
Tabela 43. Dicionário de dados da tabela tb_area
Nome do atributo
Tipo
id_area
integer
descricao_area
varchar(120)
Descrição
Índice para controle do banco
Descrição da área
Tabela 44. Dicionário de dados da tabela tb_regiao
Nome do atributo
Tipo
id_regiao
integer
nome_regiao
varchar(40)
estado
varchar(2)
Descrição
Índice para controle do banco
Nome da região
Estado ao qual pertence a região
Tabela 45. Dicionário de dados da tabela tb_tabua_mare
Nome do atributo
Tipo
id_tb_mare
integer
cod_porto
integer
nome_porto
varchar(100)
Descrição
Índice para controle do banco
Código do Porto
Nome do Porto
Tabela 46. Dicionário de dados da tabela arquivo
Nome do atributo
Tipo
arq_id
integer
arq_nome
varchar(250)
status
boolean
87
Descrição
Chave primária
Nome do arquivo
Campo para verificar se o arquivo
está sendo usado
Tabela 47. Dicionário de dados da tabela modulos
Nome do atributo
Tipo
mod_id
integer
mod_abrv
varchar(20)
mod_nome
varchar(150)
mod_desc
varchar(250)
mod_sup_id
smallint
mod_pos_menu
varchar(1)
mod_ord_menu
smallint
Tabela 48. Dicionário de dados da tabela arq_mod
Nome do atributo
Tipo
mod_id
integer
arq_id
integer
principal
boolean
Descrição
Chave Primária
Abreviatura do nome do módulo
Nome do módulo
Descrição do módulo
Código do módulo pai
Código para ver se o módulo é
horizontal ou vertical
Código do posicionamento do menu
Descrição
Chave estrangeira que faz referencia
a tabela modulos
Chave estrangeira que faz referencia
a tabela arquivos
Campo para verificação se é principal
Tabela 49. Dicionário de dados da tabela conexoes
Nome do atributo
Tipo
cnx_id
integer
cnx_oper_id
integer
cnx_semente
varchar (10)
cnx_hash
varchar (32)
cnx_ativa
smallint
cnx_saida
timestamp
cnx_entrada
timestamp
cnx_expira
timestamp
Descrição
Chave Primária
Conexão do Operador
Código da semente
Hash
Status de ativado/desativado
Data e horário de saída da sessão
Data e horário de entrada na sessão
Data e horário expiração da sessão
Tabela 50. Dicionário de dados da tabela operadores
Nome do atributo
Tipo
oper_id
integer
oper_nome
varchar(150)
oper_login
varchar (30)
oper_senha
varchar (32)
oper_ativo
boolean
oper_defs
boolean[]
oper_anon
boolean
oper_email
varchar (255)
Descrição
Chave Primária
Nome do operador
Usuário para login
Senha do operador
Status de ativado/desativado
Permissões do operador
Opção para usuário anônimo
E-mail do usuário
88
Tabela 51. Dicionário de dados da tabela permissoes
Nome do atributo
Tipo
perm_oper_id
integer
perm_mod_id
integer
perm_defs
boolean
Descrição
Chave estrangeira que faz referencia
a tabela operadores
Chave estrangeira que faz referencia
a tabela modulos
Campo para verificação das
permissões
Tabela 52. Dicionário de dados da tabela tb_contato
Nome do atributo
id_contato
nome
ip
Tipo
integer
Varchar(100)
varchar(20)
Descrição
Código para controle do banco – Chave primária
Nome
ip do usuario
mensagem
text
Mensagem deixada de critica ou sugestão
89
APÊNDICE F – ARQUIVO WSDL
ANEXO I – ARTIGO
91