universidade do vale do itajaí centro de ciências tecnológicas da
Propaganda
UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR CURSO DE CIÊNCIA DA COMPUTAÇÃO SISTEMA WEB PARA GERENCIAMENTO DE REQUISIÇÕES DE UM OBSERVATÓRIO REMOTO Área de Sistemas de Computação por Maiara Heil Cesar Albenes Zeferino, Dr. Orientador Roberto Miguel Torres, Dr. Co-orientador Itajaí (SC), dezembro 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 WEB PARA GERENCIAMENTO DE REQUISIÇÕES DE UM OBSERVATÓRIO REMOTO Área de Sistemas de Computação por Maiara Heil 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: Cesar Albenes Zeferino, Dr. Itajaí (SC), dezembro de 2005 DEDICATÓRIA Este trabalho é dedicado a todos os cientista e pesquisadores que se empenham em descobrir novos horizontes, buscando cada vez mais, melhorar a vida das pessoas. iii AGRADECIMENTOS A meus pais, que sempre me deram todo apoio que precisava, bem como a educação e o exemplo de vida que venho seguindo ao longo dos anos. A meu noivo e mestre Rafael Luiz Cancian, pelo apoio e compreensão, e pela paciência pelos longos momentos de não estar ao seu lado. Aos meus colegas e amigos que tive ao longo desta caminhada, compartilhando alegrias e angústias. Ao meu orientador Cesar Albenes Zeferino, pela oportunidade do desafio a ser enfrentado e os ensinamentos que serão para sempre recordados. Ao meu co-orientador Roberto Miguel Torres, pelas muitas horas de paciência que teve ao meu lado mostrando o quão maravilhoso é o céu. À banca examinadora do meu trabalho, pelas sugestões e criticas para que o trabalho fosse bem elaborado. A todos os professores que tive ao longo deste período acadêmico, pelos ensinamentos adquiridos. iv SUMÁRIO LISTA DE ABREVIATURAS.................................................................vii LISTA DE FIGURAS..............................................................................viii LISTA DE TABELAS ................................................................................ x LISTA DE EQUAÇÕES ...........................................................................xi RESUMO...................................................................................................xii ABSTRACT..............................................................................................xiii 1. INTRODUÇÃO ...................................................................................... 1 1.1. OBJETIVOS ..................................................................................................... 5 1.1.1. Objetivo Geral................................................................................................ 5 1.1.2. Objetivos Específicos...................................................................................... 5 1.2. METODOLOGIA............................................................................................. 5 1.3. ESTRUTURA DO TRABALHO ..................................................................... 6 2. FUNDAMENTAÇÃO TEÓRICA ........................................................ 7 2.1. OBSERVAÇÃO ASTRONÔMICA................................................................. 7 2.1.1. Movimento aparente dos astros..................................................................... 7 2.1.2. Sistemas de Referências ................................................................................. 9 2.1.3. Sistemas de Coordenadas Horizontais ........................................................ 10 2.1.4. Sistema de Coordenadas Equatoriais.......................................................... 12 2.1.5. Sistema de Coordenadas Horárias .............................................................. 14 2.1.6. Outros sistemas de Coordenadas ................................................................ 15 2.1.7. Redução ao dia ............................................................................................. 15 2.2. PROJETOS DE OBSERVATÓRIOS VIRTUAIS E REMOTOS ............... 16 2.2.1. Sistema AST/RO .......................................................................................... 16 2.2.2. Sistema ROCS .............................................................................................. 17 2.2.3. Educação em Ciências com Observatórios Virtuais................................... 18 2.2.4. Observatório do Valongo............................................................................. 19 2.2.5. New Mexico Skies......................................................................................... 20 2.2.6. Considerações............................................................................................... 21 2.3. REQUISITOS ................................................................................................. 22 2.3.1. Requisitos para o cadastro........................................................................... 22 2.3.2. Requisitos de acesso ..................................................................................... 23 2.3.3. Requisitos de agendamento ......................................................................... 23 2.3.4. CONSIDERAÇÕES..................................................................................... 23 2.3.5. Requisitos funcionais ................................................................................... 23 2.4. ESCALONAMENTO DE REQUISIÇÕES................................................... 23 2.4.1. FIFO (First In First Out)............................................................................. 25 2.4.2. Prioridade..................................................................................................... 26 2.4.3. Filas múltiplas .............................................................................................. 27 2.4.4. SJF (Smallest Job First)............................................................................... 28 2.4.5. EDF (Earliest Deadline First)...................................................................... 28 2.4.6. SSTF (Smallest Seek Time First)................................................................. 29 2.4.7. Scan............................................................................................................... 30 2.4.8. Considerações............................................................................................... 31 2.5. AMBIENTE DE DESENVOLVIMENTO .................................................... 32 2.5.1. Rotinas disponíveis....................................................................................... 33 2.5.2. Fluxo de execução......................................................................................... 35 3. DESENVOLVIMENTO ...................................................................... 37 3.1. PROJETO ....................................................................................................... 37 3.1.1. Análise de Requisitos ................................................................................... 37 3.1.2. Especificações ............................................................................................... 38 3.1.3. Arquitetura do Sistema................................................................................ 41 3.1.4. Diagramas UML........................................................................................... 43 3.1.5. Banco de Dados ............................................................................................ 55 3.2. IMPLEMENTAÇÃO ..................................................................................... 56 3.2.1. Acesso............................................................................................................ 56 3.2.2. AstraWeb...................................................................................................... 59 3.2.3. Núcleo do Sistema ........................................................................................ 60 3.2.4. Interface........................................................................................................ 63 3.2.5. Integração do Sistema.................................................................................. 67 4. CONCLUSÃO ...................................................................................... 68 REFERÊNCIAS BIBLIOGRÁFICAS ................................................... 70 GLOSSÁRIO............................................................................................. 71 APÊNDICE I – DIAGRAMAS DE SEQUENCIA................................ 72 APENDICE II – CRONOGRAMA DO TCCII..................................... 78 ANEXO I – FORMULÁRIO DO MINIOBSERVATÓRIO ASTRONÔMICO ..................................................................................... 82 ANEXO II – RESUMO PUBLICADO NOS ANAIS DA REUNIÃO ANUAL DA SAB....................................................................................... 87 ANEXO III – ARTIGO APRESENTADO NO SIMS 2005 (A SER PUBLICADO EM EDIÇÃO DA REVISTA HIFEN)........................... 88 ANEXO IV – ARTIGO PUBLICADO E ACEITO NO I2TS (A SER APRESENTADO EM DEZEMBRO/2005) ........................................... 89 vi LISTA DE ABREVIATURAS CARA CCD CCMN CSED EDF EOS ESA EUA FIFO HTML HTTP INPE LSED NASA OAI OOA&D OOSE ROCS SJF SSTF TCC TCCI TCCII TCP TIE UFRJ UML UNIVALI URL Center for Astrophysical Resource in Antarctica Charge Coupled Device Centro de Ciências Matemáticas e da Natureza Grupo de Concepção em Sistemas Embarcados e Distribuídos Earliest Deadline First Electro Optic Systems European Space Agency Estados Unidos da América First in first out Hyper Text Markup Language HyperText Transfer Protocol Instituto Nacional de Pesquisas Espaciais Laboratório de Sistemas Embarcados e Distribuídos National Aeronautics and Space Administration Observatório Astronômico Itinerante Object Oriented Analysis & Design Object Oriented Software Engineering Robotic Observatory Control System Smallest Job First Smallest Seek Time First Trabalho de Conclusão de Curso Primeira parte do Trabalho de Conclusão de Curso Segunda parte do Trabalho de Conclusão de Curso Tranmission Control Protocol Telescopes in Education Universidade Federal do Rio de Janeiro Unified Modeling Language Universidade do Vale do Itajaí Universal Resource Locator LISTA DE FIGURAS Figura 1. Imagem do telescópio em que este projeto está inserido: (a) foto do telescópio; (b) e (d) fotos laterais do telescópio; (c) foto da lente do telescópio..............................................2 Figura 2. Imagem do telescópio em que este projeto está inserido: (a) e (b) fotos da manete; (c) e (d) fotos da conexão com a câmera CCD (Charge Coupled Device). ............................3 Figura 3. Trajetória vista por um observador..............................................................................9 Figura 4. Parâmetros vinculados aos sistemas de referência.....................................................10 Figura 5. Sistema de coordenadas horizontais ...........................................................................11 Figura 6. Sistema de Coordenadas Equatoriais .........................................................................13 Figura 7. Sistema de Coordenadas Horárias..............................................................................14 Figura 8. Arquitetura do sistema do observatório AST/RO......................................................17 Figura 9. Arquitetura geral do sistema ROCS...........................................................................18 Figura 10. Tela que apresenta temperatura, vento e corrente no New México Skies ..............20 Figura 11. Tela que apresenta tempo claro no New México Skies.............................................21 Figura 12. Escalonamento dos processos utilizando FIFO ........................................................25 Figura 13. Escalonamento dos processos utilizando FIFO visualizado na forma de diagrama de Gantt................................................................................................................................26 Figura 14. Escalonamento dos processos utilizando prioridade ................................................26 Figura 15. Escalonamento dos processos utilizando prioridade visualizado na forma de diagrama de Gantt...............................................................................................................27 Figura 16. Escalonamento dos processos utilizando filas múltiplas ..........................................27 Figura 17. Escalonamento dos processos utilizando filas múltiplas visualizada como diagrama de Gantt................................................................................................................................28 Figura 18. Escalonamento dos processos utilizando SJF ...........................................................28 Figura 19. Escalonamento dos processos utilizando SJF visualizado no diagrama de Gantt...28 Figura 20. Escalonamento dos processos utilizando EDF..........................................................29 Figura 21. Escalonamento dos processos utilizando EDF visualizado no diagrama de Gantt .29 Figura 22. Escalonamento dos processos utilizando SSTF ........................................................30 Figura 23. Escalonamento dos processos utilizando SCAN .......................................................31 Figura 24. Escalonamento dos processos utilizando SCAN .......................................................31 Figura 25. Representação do contexto global do projeto de um observatório remoto .............41 Figura 26. Ligações do contexto global do projeto do observatório remoto .............................42 Figura 27. Camadas envolvidas no projeto do observatório remoto .........................................43 Figura 28. Diagrama de caso de uso do administrador..............................................................44 Figura 29. Diagrama de caso de uso do usuário .........................................................................45 Figura 30. Diagrama de classes do Astra Web ...........................................................................46 Figura 31. Diagrama de classes do Astra Kernel .......................................................................47 Figura 32. Diagrama de colaboração..........................................................................................48 Figura 33. Diagrama de seqüência do cadastro do usuário .......................................................50 Figura 34. Diagrama de seqüência da requisição.......................................................................51 Figura 35. Passos que o sistema segue para a validação da requisição .....................................52 Figura 36. Diagrama de seqüência da execução da requisição ..................................................53 Figura 37. Diagrama de implantação .........................................................................................54 Figura 38. Modelagem do banco de dados..................................................................................55 Figura 39. Teste de execução do AstraWeb .................................................................................58 Figura 40. Comunicação via socket TCP entre os programas AstraWeb e o AstraKernel .........59 Figura 41. Implementação parcial da Classe Astrônomo ..........................................................60 Figura 42. Implementação da Classe do Driver da Estação Meteorológica...............................61 Figura 43. Implementação da Classe Meteorologista.................................................................62 Figura 44. Janela de teste do núcleo do Astra ............................................................................63 Figura 45. Tela Acesso ao Sistema ..............................................................................................64 Figura 46. Tela Cadastro do Usuário..........................................................................................65 Figura 47. Tela Solicitação de Requisição ..................................................................................66 Figura 48. Diagrama de seqüência de avaliação do cadastro do usuário ..................................72 Figura 49. Diagrama de seqüência da exclusão de usuários ......................................................73 Figura 50. Diagrama de seqüência do login do administrador ..................................................73 Figura 51. Diagrama de seqüência da manutenção do observatório.........................................74 Figura 52. Diagrama de seqüência de listar requisições pendentes...........................................74 Figura 53. Diagrama de seqüência de modificação de agendamento ........................................75 Figura 54. Diagrama de seqüência de visualização do cadastro dos usuários...........................75 Figura 55. Diagrama de seqüência de visualização da utilização do telescópio ........................76 Figura 56. Diagrama de seqüência de login................................................................................76 Figura 57. Diagrama de seqüência de visualização de condições meteorológicas .....................77 ix LISTA DE TABELAS Tabela 1. Comparação entre os sistemas pesquisados ...............................................................22 Tabela 2. Processos a serem escalonados....................................................................................25 Tabela 3. Algoritmos das filas .....................................................................................................27 LISTA DE EQUAÇÕES Equação 1.....................................................................................................................................11 Equação 2.....................................................................................................................................11 Equação 3.....................................................................................................................................12 Equação 4.....................................................................................................................................12 Equação 5.....................................................................................................................................13 Equação 6.....................................................................................................................................14 Equação 7.....................................................................................................................................15 Equação 8.....................................................................................................................................15 Equação 9.....................................................................................................................................16 Equação 10...................................................................................................................................16 RESUMO HEIL, Maiara. Sistema Web para gerenciamento de requisições de um observatório remoto. Itajaí, 2005. 87 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í, 2005. A observação astronômica necessita de equipamentos especiais, uma vez que a maioria absoluta dos objetos celestes não é visível a olho nu. Ao conjunto dado por um telescópio profissional, pelos equipamentos necessários à sua utilização e pelo espaço físico construído ao seu redor, dá-se o nome de observatório astronômico. Dados os custos elevados, a necessidade de pessoal especializado, de condições ambientais (atmosféricas, luminosas, geográficas) favoráveis no local de observação e a complexidade da construção, operação e manutenção de um observatório astronômico, torna-se clara a necessidade de compartilhamento desse tipo de recurso. No Laboratório de Astrofísica da Universidade do Vale do Itajaí (Univali), está sendo desenvolvido, com o apoio da Petrobrás, um projeto de observatório astronômico. O acesso remoto ao observatório traz várias vantagens, como a utilização de infra-estrutura e equipamentos de alto custo sem necessidade de sua aquisição, bem como sua otimização. Este projeto desenvolveu um sistema Web para gerenciamento das requisições para acesso remoto a esse observatório através da Internet. Neste trabalho é apresentada uma revisão bibliográfica sobre conceitos relacionados com o objetivo proposto, como aspectos da observação astronômica, descrição de trabalhos relacionados e técnicas para o escalonamento de requisições. O texto também apresenta o projeto e o desenvolvimento do sistema que foi implementado neste Trabalho de Conclusão de Curso. Palavras-chave: Sistemas de Informação. Escalonamento de Requisições. Observação Astronômica Remota. ABSTRACT The astronomical observation needs special equipments, since the absolute majority of the celestial objects is not visible. Astronomical observatory is the name given to the collection of a professional telescope, the equipments needed to its utilization and the building where it is inserted. Due to expensive costs, the need of specialized workers and favorable environment conditions, the complexity related to building, operation and maintenance of the astronomical observatory, it is important to share this kind of resource. At Astrophysical Laboratory at University of Vale do Itajaí (Univali) it is being developed a project of an astronomical observatory supported by Petrobras. The remote access to the observatory has many advantages, as the utilization of expensive structures and infra-structure without buying it, and its optimization. This project to develop a Web system to manage requisitions for access this observatory in a remote way by using the Internet. In this work, it is presented review on the concepts related with the proposed, including astronomical observation issues related works and techniques used to schedule requisitions in computer systems. This text also presents the design of the system that was implemented in this research. Keywords: Information Systems. Requisition Scheduler. Remote Astronomical Observation. 1. INTRODUÇÃO A observação astronômica científica necessita de equipamentos especiais, uma vez que a maioria absoluta dos objetos celestes não é visível a olho nu. Os equipamentos mais utilizados para a observação astronômica são antenas e telescópios. Antenas conseguem captar os espectros mais baixos de freqüência (ondas de rádio) da energia emitida por corpos celestes, enquanto os telescópios, com auxílio de filtros, conseguem captar os espectros que vão desde o infra-vermelho até os raios ultra-violeta. Desse modo, considera-se os telescópios como equipamentos indispensáveis para a observação astronômica. Telescópios existem em diferentes tipos de óptica, montagens e tamanhos. Entre os tipos de óptica, destacam-se a newtoniana, a cassegrain e outras. Os principais tipos de montagens são a equatorial, a equatorial-germânica e a alto-azimutal. O tamanho de um telescópio é dado pelo diâmetro de sua objetiva (lente ou espelho), que pode variar de cerca de 4 polegadas até alguns metros. O diâmetro do espelho define o tamanho do telescópio e a sua utilização. Telescópios amadores têm diâmetros de até poucas dezenas de polegadas e são portáteis, não exigindo nenhum equipamento extra para a sua utilização. Telescópios profissionais, muito mais úteis à astronomia científica, podem ter diâmetro de até vários metros e pesar muitas toneladas, de forma que não podem ser operados manualmente e exigem outros equipamentos e local apropriado, especialmente construído para sua operação (uma vez que não são portáteis). Ao conjunto dado por um telescópio profissional, pelos equipamentos necessários à sua utilização e pelo espaço físico construído ao seu redor, dá-se o nome de observatório astronômico. Dados os custos elevados, a necessidade de pessoal especializado, de condições ambientais (atmosféricas, luminosas, geográficas) favoráveis e a complexidade da construção, operação e manutenção de um observatório astronômico, torna-se clara a necessidade de compartilhamento desse tipo de recurso. Ao redor do mundo, na última década, têm surgido diversos projetos que visam compartilhar o acesso a imagens obtidas por telescópios (projetos de telescópios virtuais) ou compartilhar o acesso aos próprios telescópios (projetos de telescópios remotos). A diferença principal entre esses tipos de projeto consiste no simples acesso remoto a bases de dados de imagens já obtidas (no primeiro caso) ou então a possibilidade de controlar remotamente um telescópio real e obter novas imagens (no segundo caso). Para controlar remotamente um telescópio, faz-se necessário um cadastro de usuários com prioridades, e um escalonamento das requisições. Um projeto envolvendo um observatório itinerante e um fixo na Univali está alocado no Laboratório de Astrofísica, que foi aprovado e contou com financiamento da Petrobrás. O projeto incluiu a aquisição de quatro telescópios, sendo dois de pequeno porte (lente de 6” e 10” de diâmetro) para saída de campo e atividades relacionadas efetivamente ao projeto denominado Observatório Astronômico Itinerante (OAI), um terceiro telescópio de pequeno porte sem automatização para servir de base a projetos de instrumentação astronômica, desenvolvidos pelo LSED (Laboratório de Sistemas Embarcados e Distribuídos). O quarto telescópio, mostrado na Figura 1 e na Figura 2 de 12” de diâmetro, deverá ser utilizado no observatório da Univali, a ser construído, com o propósito de adquirir imagens com maior resolução para serem transmitidas via Web às instituições de ensino médio. (a) (b) (c) (d) Figura 1. Imagem do telescópio em que este projeto está inserido: (a) foto do telescópio; (b) e (d) fotos laterais do telescópio; (c) foto da lente do telescópio 2 (b) (a) (d) (c) Figura 2. Imagem do telescópio em que este projeto está inserido: (a) e (b) fotos da manete; (c) e (d) fotos da conexão com a câmera CCD (Charge Coupled Device). Os principais objetivos do projeto de um observatório fixo são (i) a aquisição de imagens para o Website da Univali e folders de divulgação; (ii) monitoramento de cometas para missões espaciais da NASA (National Aeronautics and Space Administration) e da Agência Espacial Européia (ESA - European Space Agency); (iii) divulgação da universidade em projetos de extensão junto à comunidade; e (iv) servir de base a outros projetos de pesquisa na Univali. No estágio atual do desenvolvimento de todo o projeto, os quatro telescópios mencionados e os demais acessórios já foram adquiridos (custo aproximado de R$ 28.000,00), passaram por testes mecânicos, ópticos e eletrônicos, e encontram-se disponíveis para uso. Os dois telescópios relacionados ao projeto do observatório itinerante foram usados em dez saídas de campo, tendo atendido mais de 1000 alunos de escolas-pólo dos estados de Santa Catarina e Paraná. O telescópio de menor diâmetro a ser utilizado para automatização já foi alvo de um projeto de conclusão de curso, denominado “Sistema Embarcado para controle de Telescópio”, desenvolvido por Silva (2003). O telescópio de maior diâmetro ainda aguarda as condições necessárias para ser utilizado. 3 As maiores dificuldades do projeto do observatório da Univali são a disponibilização de um espaço físico para a construção do observatório que abrigará o telescópio de maior diâmetro, e a aquisição de câmera CCD, para ser acoplada ao telescópio. O presente Trabalho de Conclusão de Curso (TCC) insere-se no contexto do observatório fixo e desenvolveu um sistema de gerenciamento das requisições de um observatório remoto, utilizando o telescópio recentemente adquirido pela parceria Univali/Petrobrás. O observatório remoto pode ser acessado através da página Web que possui um cadastro de usuários, que pode ser escolas do ensino médio ou instituições de pesquisa interessadas em obter imagens de corpos celestes. Cada usuário tem uma prioridade associada a si e às requisições solicitadas por ele. Na geração da requisição, o sistema faz uma série de verificações de consistência, como a da existência do corpo celeste solicitado, das coordenadas celestes informadas ou da visibilidade do astro no momento da observação. Sendo consistente, a requisição é escalonada e tem sua execução agendada. Na data agendada, o sistema verifica as condições meteorológicas (temperatura, umidade e velocidade do vento) e se forem aceitáveis, a requisição será executada, ou seja, a cúpula se movimentará, a trapera1 será aberta, o telescópio será apontado para o astro selecionado, a imagem é capturada e enviada por e-mail para o solicitante. Caso as condições meteorológicas não sejam aceitáveis, a requisição será reagendada e o solicitante avisado. Este trabalho é importante por diversos fatores. Inicialmente, deve ser abrangente o suficiente para poder ser utilizado em diferentes observatórios com certo grau de automação, permitindo que eles sejam operados remotamente. O acesso remoto ao observatório traz outras vantagens, como a utilização de infra-estrutura e equipamentos de alto custo sem necessidade de sua aquisição, bem como sua otimização. A instituição detentora do observatório (a Univali) também é beneficiada por ter seu nome divulgado e por manter ocupado um recurso que de outra forma permaneceria ocioso. Este sistema também permite que entidades situadas em locais desfavoráveis à observação astronômica (poluições luminosa ou atmosférica, ar úmido, céu nebuloso, etc.) possam utilizar um observatório melhor situado. Outra vantagem é que o agendamento das requisições libera o pesquisador da necessidade de estar acompanhando o telescópio no momento da observação. Este projeto se justifica como um Trabalho de Conclusão de Curso em Ciência da Computação por fazer uso de diversas tecnologias e conceitos estudados no curso de Ciência da 1 Trapera: componente da cúpula que se abre para permitir a saída do telescópio 4 Computação, como desenvolvimento para Web, banco de dados, engenharia de software e escalonamento de recursos. Além disso, ele se justifica também pelo seu aspecto de divulgação científica e vínculo com os grupos de pesquisa da Univali, como o CSED (Grupo de Concepção em Sistemas Embarcados e Distribuídos) e o Grupo de Astrofísica. 1.1. OBJETIVOS 1.1.1. Objetivo Geral O objetivo geral deste projeto foi desenvolver um sistema Web para gerenciamento de um observatório remoto que recebe requisições de observações de corpos celestes, faz a análise e consistência dessas requisições, seu escalonamento e o seu atendimento. 1.1.2. Objetivos Específicos Os objetivos específicos deste projeto são: • Pesquisar soluções existentes para observatórios remotos e analisar seus pontos fracos e fortes; • Pesquisar conceitos relativos à astronomia (movimento aparente dos astros); • Pesquisar algoritmos de escalonamento e métodos de alocação de recursos; • Realizar a modelagem do sistema; • Implementar o sistema; • Testar e validar a implementação do sistema; e • Documentar o projeto. 1.2. METODOLOGIA 5 A metodologia utilizada no desenvolvimento deste trabalho é baseada nas seguintes etapas: (i) Estudo; (ii) Modelagem; (iii) Desenvolvimento; (iv) Validação; (v) Documentação e Apresentação. Na etapa Estudo foi realizada uma revisão bibliográfica baseada na leitura de textos disponíveis em livros, artigos técnico-científicos e sites especializados na Internet. Também foram feitas entrevistas com o especialista em Astronomia, das quais obteve-se os requisitos do sistema a ser implementado. Realizou-se então uma análise comparativa das características do sistema proposto com aquelas de outros já disponíveis. Em seguida, efetuou-se uma análise dos diversos algoritmos de escalonamento, visando determinar quais seriam adotados neste projeto. Também foi efetuado um estudo a fim de determinar a plataforma de desenvolvimento a ser utilizada. Na etapa Modelagem foi realizado o projeto do sistema. Inicialmente fez-se a análise do projeto utilizando o modelo UML (Unified Modeling Language), onde foram desenvolvidos diversos diagramas para descrever o projeto. Quatro ciclos (versões) envolvendo análise, projeto, implementação e testes foram necessários. As etapas de estudo e modelagem foram realizadas na primeira parte deste trabalho, denominado TCCI que foi entregue em julho/2005. As etapas Desenvolvimento e Validação foram objeto da segunda fase desta pesquisa, denominada TCCII e foram entregues em novembro/2005. A etapa de Documentação, desenvolvida durante todo o trabalho, incluiu a redação dos textos que compõem este relatório, bem como de um resumo submetido e aceito à um evento científico. 1.3. ESTRUTURA DO TRABALHO Este texto é dividido em quatro capítulos, incluindo a Introdução. No Capítulo 2, é apresentada a fundamentação teórica, na qual se descreve os assuntos relevantes a este trabalho. No Capítulo 3, é descrita a modelagem e o desenvolvimento do sistema que foi desenvolvido e, no Capítulo 4, são apresentadas as considerações finais. 6 2. FUNDAMENTAÇÃO TEÓRICA Ao redor do mundo, na última década, têm sido desenvolvidos diversos projetos que visam compartilhar o acesso a imagens obtidas por telescópios (projetos de telescópios virtuais) ou aos próprios telescópios (projetos de telescópios remotos). A diferença principal entre esses tipos de projeto consiste no simples acesso remoto a bases de dados de imagens já obtidas (no primeiro caso) ou então a possibilidade de controlar remotamente um telescópio real e obter novas imagens (no segundo caso). Para controlar remotamente um telescópio, faz-se necessário um cadastro de usuários com prioridades e um escalonamento das requisições. Alguns exemplos desses tipos de projetos e conceitos astronômicos são apresentados depois do estudo realizado sobre Astronomia. 2.1. OBSERVAÇÃO ASTRONÔMICA 2.1.1. Movimento aparente dos astros Sobre a esfera celeste, pode-se observar o “movimento diurno aparente” do Sol dar-se de leste para oeste, em qualquer hemisfério que se encontre o observador. Por sua vez, se um observador prestar atenção em uma estrela de uma constelação2, observará seu “movimento noturno aparente” realizar-se também de leste para oeste. Se durante dias ou meses observarmos no mesmo horário e direção, a mesma região no céu, será possível perceber a presença de novas constelações ocupando aquela posição outrora pertencente à outra constelação. Em virtude do movimento de translação da Terra em torno do Sol, as mesmas constelações voltarão após um ano a ocupar novamente aquela posição naquele mesmo instante de tempo. A esse movimento das estrelas em intervalos de um ano denomina-se “movimento anual aparente” das estrelas. Existem estrelas que nunca se põe e ficariam sempre visíveis se o Sol não dificultasse sua observação. Essas estrelas são denominadas de estrelas circumpolares. Para um observador no Hemisfério Norte, olhando para o ponto cardeal norte, observaria as estrelas circumpolares executarem um movimento anti-horário em torno do Ponto Celeste Norte. Por sua vez, um observador no Hemisfério Sul, observando o ponto cardeal sul, verificaria que as estrelas circumpolares executam um movimento horário em torno do Ponto Celeste Sul. Além disso, quanto 2 Por definição, uma constelação é um agrupamento aparente de estrelas mais ao norte encontrar-se a estrela, menos tempo ela fica visível, para um observador do Hemisfério Sul. Por exemplo, as estrelas que se encontram mais ao sul, ficariam visíveis aproximadamente vinte e quatro horas (supondo, mais uma vez, que o Sol não interferisse em sua observação). A este movimento que as estrelas executam em quase um dia, dá-se o nome de “movimento diário aparente”. O movimento diurno dos astros (movimento cíclico em 24 horas), de leste para oeste, é um reflexo do movimento de rotação da Terra, de oeste para leste. Ao longo do dia, todos os astros descrevem no céu arcos paralelos ao Equador. Se considerarmos a esfera celeste como referencial, a Terra estaria em repouso no centro dela e todos os astros girariam em torno da Terra, descrevendo trajetórias circulares em torno de um ponto fixo no céu (ponto celeste sul ou ponto celeste norte). O Sol, por exemplo, se move no céu, nascendo a Leste e se pondo a Oeste, o que nos dá a impressão de a esfera celeste estar girando de Leste para Oeste. A inclinação dos arcos descritos pelo astro em relação ao horizonte depende da latitude do lugar. A Figura 3 mostra a trajetória do astro vista por um observador, situado no equador terrestre, em outra latitude qualquer e num dos pólos. 8 Figura 3. Trajetória vista por um observador Fonte: Rosa (1994) 2.1.2. Sistemas de Referências Para definir a posição de qualquer astro na esfera celeste, é conveniente que seja usado um sistema de coordenadas. A escolha do sistema de coordenadas é fundamental para uma solução rápida e fácil. Dentre os diversos tipos, o que os difere é somente a escolha dos elementos básicos, sendo sempre possível a transformação de um sistema para o outro. A montagem de um telescópio depende da utilização de um sistema de coordenadas. 9 A intersecção entre o céu e a terra, muito ao longe, por um observador, num lugar bem plano, é chamada de linha do horizonte e o plano definido por esta linha, de plano do horizonte. Dessa forma, a linha perpendicular a esse plano denomina-se de vertical do lugar. Essa vertical, parece furar o céu num ponto bem acima da cabeça do observador, denominado de ponto de zênite, conforme a Figura 4. Figura 4. Parâmetros vinculados aos sistemas de referência Fonte: Boczko (1984) 2.1.3. Sistemas de Coordenadas Horizontais O sistema de coordenadas horizontais é um sistema local, no sentido de que é fixo na Terra. Seus planos fundamentais são definidos pelo plano que contém o horizonte do observador (plano horizontal) e pelo plano meridiano, que contém a linha Norte-Sul, passando pelo observador e pelo zênite, conforme ilustrado na Figura 5. Nesse sistema, as coordenadas que definem a posição de um astro são denominadas azimute e altura. 10 Figura 5. Sistema de coordenadas horizontais Fonte: Boczko (1984) O azimute, A , é o ângulo medido no plano do horizonte, desde a direção norte, no sentido para leste, até o vertical do astro, satisfazendo à relação: 0 ≤ A ≤ 360 Equação 1 A altura, h , é o ângulo contado no plano vertical do astro, a partir do horizonte até o astro. Por convenção, é admitido positivo acima do horizonte (astro visível) e negativo abaixo do horizonte (astro invisível), obedecendo à relação: − 90 ≤ h ≤ +90 Equação 2 É uma prática comum utilizar, em vez da altura do astro, a distância zenital do astro, z , ou seja, o ângulo entre o zênite e o astro, por se tratar de ângulos complementares, prevalecendo a relação: 11 Equação 3 h + z = 90 A distância zenital é medida a partir do zênite até o astro em questão, valendo-se da relação: 0 ≤ z ≤ 180 Equação 4 Segundo Társia (1993), apesar de ser o de melhor visualização, o sistema de coordenadas horizontais, conforme Figura 5, apresenta alguns inconvenientes de uso. Em primeiro lugar, as coordenadas de um mesmo astro, vistas por dois observadores em lugares distintos, são diferentes. A outra inconveniência de uso das coordenadas horizontais reside no fato que, tanto a altura quanto o azimute de um astro variam com o tempo, devido ao movimento de rotação da Terra. 2.1.4. Sistema de Coordenadas Equatoriais O sistema de coordenadas equatoriais é fixo na esfera celeste. Portanto suas coordenadas não dependem de lugar e instante da observação, ou seja, as coordenadas dos astros se mantém constantes. Neste sistema, os planos principais são a projeção do equador terrestre na esfera celeste, chamado de equador celeste. O outro plano é o do meridiano celeste, que é a projeção do plano do meridiano terrestre na esfera celeste, contendo o ponto Áries (também chamado de ponto Gama, , ou ponto Vernal, sendo um ponto do equador, ocupado pelo sol no equinócio da primavera do Hemisfério Norte), conforme Figura 6. 12 Figura 6. Sistema de Coordenadas Equatoriais Fonte: Santiago (2001) No sistema equatorial, as coordenadas da estrela são representadas por: ascensão reta e declinação. A ascensão reta, , é o ângulo medido sobre o Equador, com origem no meridiano que passa pelo ponto e pelo círculo horário que contém a estrela. A ascensão reta varia segundo a relação: 0 h ≤ α ≤ 24 h Equação 5 sendo que 1h de tempo corresponde a 15 de arco. A contagem é efetuada no sentido horário, quando vista desde o Pólo Sul. A declinação, , é o ângulo medido sobre um círculo horário, entre o equador e o paralelo que passa pela estrela. Por convenção, a declinação é positiva para estrelas do Hemisfério Norte e negativa para estrelas do Hemisfério Sul, tornando-se válida a relação: 13 − 90 ≤ δ ≤ +90 Equação 6 Segundo Santiago (2001), a ascensão reta e a declinação de um astro permanecem praticamente constantes por longos períodos de tempo. O sistema equatorial é usado nos catálogos de objetos celestes, já que suas coordenadas são praticamente constantes. 2.1.5. Sistema de Coordenadas Horárias O sistema de coordenadas horárias baseia-se no fato que, apesar de ser fixo a Terra, uma das coordenadas da estrela permanece constante, variando apenas a outra. Neste sistema, adota-se os seguintes planos fundamentais de referência: o plano do equador e o plano meridiano. Conforme a estrela realiza seu movimento diário, seu ângulo (declinação) até o equador continua constante, mas varia o ângulo entre o meridiano do observador e o círculo horário que contém a estrela (ângulo horário), conforme esquematizado na Figura 7. Assim, a posição de uma estrela num dado instante de tempo é definida pelas seguintes coordenadas: ângulo horário e declinação. Figura 7. Sistema de Coordenadas Horárias Fonte: Santiago (2001) 14 O ângulo horário, H, é o ângulo medido sobre o equador, com origem no meridiano local ( H = 0 ) e extremidade no círculo horário que passa pelo astro. Em particular, este ângulo cresce conforme o tempo passa, sendo válidas as seguintes relações: 0 h ≤ H ≤ 24 h Equação 7 ou − 12 h ≤ H ≤ +12 h Equação 8 Nesta segunda relação, valores negativos indicam que o astro está localizado no Hemisfério Oriental, ou seja, antes de sua passagem pelo meridiano do observador. Por sua vez, valores positivos indicam que o astro se encontra no Hemisfério Ocidental. A declinação, , segue a mesma definição apresentada anteriormente. O sistema de coordenadas horárias é o sistema próprio dos telescópios, para poderem manter indefinidamente um astro em seu campo de visão. 2.1.6. Outros sistemas de Coordenadas Existem ainda, outros sistemas de coordenadas que podem ser citados, entre eles o sistema de coordenadas geográficas e o sistema de coordenadas eclípticas. Os Sistemas de Coordenadas Geográficas são usados para medir a posição sobre a superfície da Terra, tendo como as coordenadas principais: a latitude e a longitude geográfica. Os Sistemas de Coordenadas Eclípticas são utilizados para estudos das posições e movimentos relativos ao Sol e objetos do Sistema Solar, sendo que, o plano fundamental é o plano da eclíptica, que é o plano da órbita da Terra em relação ao Sol. Suas coordenadas são a latitude e longitude eclíptica. 2.1.7. Redução ao dia Segundo Társia (1993) “pelo termo redução ao dia entendemos todo o processo de cálculo da transformação das coordenadas de um astro em um dado instante, a partir de suas coordenadas 15 em uma época, diferente deste instante”. Para este propósito, obtém-se de catálogos estelares de determinadas épocas (T0), as coordenadas 0 e 0 da estrela, utilizando o ponto 0 da época, e faz-se as transformações para as coordenadas da data (data atual). Existem alguns passos para obter a correção desejada da data, são elas: • Correção devido à precessão (P); • Correção devido ao movimento próprio dos astros (MP); • Correção devido a nutação (N); • Correção devido à paralaxe anual (PA); • Correção devido à aberração anual (AA); • Correção devido à paralaxe diária (PD); • Correção devido à aberração diária (AD); e • Correção devido à refração atmosférica (R). Pode-se representar todas essas correções utilizando as seguintes expressões: α = α 0 + ∆α P + ∆α MP + ∆α N + ∆α PA + ∆α AA + ∆α PD + ∆α AD + ∆α R Equação 9 δ = δ 0 + ∆δ P + ∆δ MP + ∆δ N + ∆δ PA + ∆δ AA + ∆δ PD + ∆δ AD + ∆δ R Equação 10 2.2. PROJETOS DE OBSERVATÓRIOS VIRTUAIS E REMOTOS Nesta sessão serão apresentados os projetos de observatórios virtuais e remotos, bem como suas especificações e características deles. 2.2.1. Sistema AST/RO O Centro para Pesquisa Astrofísica da Antártida (CARA – Center for Astrophysical Resourse in Antarctica3) é uma fundação norte americana de ciência com sede na Universidade de Chicago e gerencia o AST/RO, que é um telescópio de 1,7 metros de diâmetro em operação em 3 Home-page disponível em: <http://astro.uchicago.edu/cara>. Acesso em: 08 abril 2005. 16 Amundsen-Scott, no pólo sul, desde 1995 (CARA, 1995). Todo o sistema AST/RO é altamente automatizado para reduzir ao mínimo a necessidade da intervenção humana e possibilitar sua utilização durante o inverno, período no qual a estação deve ser abandonada. Disponível para acesso remoto apenas para seus pesquisadores, a arquitetura do sistema do observatório do AST/RO é apresentada na Figura 8. Figura 8. Arquitetura do sistema do observatório AST/RO Fonte: Cara (1995) 2.2.2. Sistema ROCS 17 Em 2002, a Electro Optic Systems (EOS), empresa australiana que fabrica cúpulas e diversos outros equipamentos para observatórios astronômicos, lançou o ROCS (Robotic Observatory Control System), a terceira geração de software para controle de observatórios, que permite a operação realmente autônoma de observatórios de maneira extremamente flexível. Ele realiza operações de calibração e manutenção do telescópio, bem como agenda o atendimento a requisições remotas de observação (ELECTRO OPTIC SYSTEMS, 2002). A arquitetura geral do sistema ROCS é apresentada na Figura 9. Figura 9. Arquitetura geral do sistema ROCS Fonte: Electro Optic Systems (2002) 2.2.3. Educação em Ciências com Observatórios Virtuais 18 Ainda no Brasil, o Instituto Astronômico e Geofísico da Universidade de São Paulo concebeu, em 2002, o projeto “Educação em Ciências com Observatórios Virtuais”, que agrega diversas instituições de ensino e pesquisa no país. Essa iniciativa nacional possibilitou a inclusão de um de seus integrantes no projeto TIE (Telescopes in Education) da NASA, que utiliza o telescópio do observatório do Monte Wilson (EUA) para observações remotas em projetos pedagógicos para o ensino de astronomia. 2.2.4. Observatório do Valongo O Observatório do Valongo (WERNECK, NADER e CAMPOS, 2004) é um Instituto do Centro de Ciências Matemáticas e da Natureza (CCMN) da Universidade Federal do Rio de Janeiro (UFRJ), que, em 2004, adquiriu, juntamente com outras cinco instituições astronômicas, um conjunto de equipamentos necessários para montagem de um observatório remoto (telescópio, câmera CCD, conjunto de filtros, etc.). Com a chegada do equipamento, foi feito o projeto da cúpula controlada por computador e hoje esse observatório já pode ser utilizado, sendo que dele já foram obtidas imagens celestes. Porém, a completa operação remota ainda não foi implementada pela ausência de uma interface adequada, impossibilitando que o observatório seja controlado remotamente. Segundo Werneck, Nader e Campos (2004), ainda está em estudo a interface a ser disponibilizada para acesso remoto. O aceso encontra-se disponível apenas para as escolas parceiras, onde estas devem preencher um formulário on-line. Foi enviada uma mensagem ao Dr. André Milone (2005) do INPE (Instituto Nacional de Pesquisas Espaciais), descrevendo este projeto e solicitando algumas informações, na qual foi respondido com a mensagem abaixo: em 2005, jah começaremos atender a pedidos de qq instituição de ensino que fizer contato conosco; muito embora nunca tenhamos recebido um pedido das escolas parceiras do Projeto OVs (http://www.observatoriovirtual.pro.br/). Então, por enquanto não enfrentamos ainda o problema real de gerenciamento dos pedidos de observação. Os dados do formulário são enviados ao e-mail [email protected] cuja analise deve ser feita por nossa equipe. Pretendemos ainda transformar tal formulário numa estrutura mais didática, c/menos dados técnicos e interativo. Você nao quer experimentar p/a fazer um pedido "real"? E, quem sabe, executar uma observação em si no modo remoto que estah sendo o nosso objetivo atual (colocar no ar o modo remoto)? Sinta a vontade p/a criticar o formulario bem como p/a nos questionar no que for preciso. A pagina do formulário eh http://www.das.inpe.br/miniobservatorio/formulario/index.htm O formulário citado na mensagem acima encontra-se no anexo. 19 2.2.5. New Mexico Skies O observatório New Mexico Skies (MIKE & LYNN RICE, 2005), no estado do Novo México (EUA), situa-se em uma área privilegiada, em termos de astronomia. A cidade mais próxima fica a 100 milhas do observatório, de modo que o céu dessa localidade é conhecido como dark skies. Para assegurar essa condição, o governador do estado do Novo México assinou, em 1999, uma lei que proibia qualquer tipo de poluição luminosa naquela área. O observatório possui uma ampla estrutura e faz uso de vários telescópios. Em sua página na Internet (MIKE & LYNN RICE, 2005), são disponibilizadas, em tempo real, informações necessárias para observação astronômica, como velocidade do vento, temperatura, massa de ar, condições do céu, etc. Todas as informações podem ser obtidas com imagens dinâmicas e com legendas claras e objetivas, conforme mostrada na Figura 10 e na Figura 11. Figura 10. Tela que apresenta temperatura, vento e corrente no New México Skies Fonte: Mike & Lynn Rice (2005) 20 Figura 11. Tela que apresenta tempo claro no New México Skies Fonte: Mike & Lynn Rice (2005) Na página, também é disponibilizada uma imagem astronômica em tempo real e uma imagem interna do observatório. Os telescópios desse observatório são alugados para o público, com taxas que variam de U$ 165,00 por dia a U$ 100,00 por hora. 2.2.6. Considerações Os sistemas avaliados nesta subseção incorporam soluções para obtenção de obtenção de imagens de forma remota, como o sistema proposto neste trabalho. Mas, como pode ser observado na Tabela 1, os sistemas estudados não possuem um sistema de agendamento como o proposto neste TCC. No tópico a seguir, serão apresentadas informações necessárias para a solicitação deste agendamento. 21 Tabela 1. Comparação entre os sistemas pesquisados Observatório do Valongo TIE (Telescopes New México in Education) Skies AST/RO ROCS Oferece acesso remoto Sim ao observatório? Sim Sim Sim Sim Oferece agendamento? Não Não Não Sim Sim O agendamento é feito Não de forma automática? Não Não Sem informação Sem informação Limitações* Disponível apenas Observação para participantes apenas no local do projeto Disponível apenas para participantes do projeto Situado no pólo sul, ótima área para observação Disponível apenas para participantes do projeto Disponível apenas para participantes do projeto Observatório em funcionamento Disponível apenas para participantes do projeto Características: Ainda não tem interface implementada Vantagens* A parte física do observatório já está equipado Desvantagens* Disponível apenas para escolas com parceria * Em relação ao projeto proposto Observatório em funcionamento Ótima estrutura Disponível apenas Acesso pago para participantes do projeto 2.3. REQUISITOS Os requisitos especificam genericamente as funções providas deste sistema. 2.3.1. Requisitos para o cadastro Para utilizar os recursos do observatório, a pessoa ou instituição, deve preencher um cadastro para avaliação do responsável pelo observatório. Os campos desse cadastro, citados abaixo, são os requisitos necessários para esta etapa. • Informações pessoais: nome, CPF, RG, endereço, telefone, data de nascimento, profissão, e-mail, celular, numero, complemento, CEP, bairro, cidade, estado e país; e • Informações institucionais: nome, tipo, departamento, curso, telefone, endereço, número, complemento, CEP, bairro, cidade, estado e país. 22 2.3.2. Requisitos de acesso O usuário estando cadastrado deve fazer uso do login e senha para acessar o sistema e então fazer sua requisição. Os campos da tela de acesso são os requisitos desta etapa, que são eles: login e senha. 2.3.3. Requisitos de agendamento Estes requisitos são os dados fundamentais para a solicitação de uma requisição. Nele, o usuário vai identificar o tipo, a data e todas as informações necessárias para o agendamento de uma requisição. São eles: • Informações sobre o astro: nome do astro ou as coordenadas dele; • Informações sobre a data de observação: intervalo de data ou data específica; • Informações sobre o horário da observação: intervalo de horário ou horário específico; e • Opções: tempo de exposição, imagens consecutivas, filtros ou imagens consecutivas com todos os filtros. 2.3.4. CONSIDERAÇÕES Para melhor visualizar estes requisitos, na Seção 3.2 estão apresentadas as telas do sistema, com os dados necessários preenchidos, o escalonamento da requisição poderá ser realizado. 2.3.5. Requisitos funcionais Os requisitos funcionais descrevem os passos que o sistema deve seguir, ou seja, o que ele deve fazer. Estes requisitos serão melhor especificados na seção de modelagem do projeto. 2.4. ESCALONAMENTO DE REQUISIÇÕES O gerenciamento das requisições do projeto deste trabalho baseia-se em escalonar as requisições de modo a obedecer todos os critérios que serão expostos nas próximas sessões. Uma forma conhecida de escalonamento na área da computação é o escalonamento de processos no Sistema Operacional e o escalonamento de requisições de acesso ao disco rígido. Nas próximas subseções serão apresentadas as características de seis algoritmos de escalonamento. 23 Em um Sistema Operacional, o escalonador (scheduler) é o componente responsável pelo agendamento de processos, ou seja, determina a ordem de execução dos processos prontos a executar e os despacha ao processador (aloca o processo ao processador), o qual pode, então, executar suas instruções (CANCIAN, 2000). Para proteger o sistema e impedir que um processo mais importante espere na fila por outros menos importantes que está executando, o Sistema Operacional deve ter a capacidade de interromper a execução de um processo (através de uma interrupção do timer), retirá-lo do processador (colocando-o novamente na fila) e escolher outro processo na fila para executar. À capacidade do escalonador de interromper a execução de processos dá-se o nome de preempção. Em escalonadores de sistemas em tempo real4, é essencial que o escalonamento seja preemptivo, o que melhora o desempenho do sistema e pode diminuir consideravelmente a taxa de perdas de deadline5, de acordo com Cancian (2000). Butazzo (1997) fornece uma definição mais formal: Suponha três conjuntos: um conjunto de n tarefas J = {J1, J2, ..., Jn}, um conjunto de m processadores P = {P1, P2, ..., Pm} e um conjunto de s tipos de recursos R = {R1, R2, ..., Rs}. Além disso relações, de precedência entre tarefas podem ser especificadas através de um grafo acíclico dirigido, e restrições temporais podem ser associadas a cada tarefa. Neste contexto, escalonamento significa associar processadores de P e recursos de R a tarefas de J de modo a completar todas as tarefas sob as restrições impostas. Neste trabalho são apresentadas as características de sete escalonadores: (i) FIFO; (ii) prioridade; (iii) filas múltiplas; (iv) SJF; (v) EDF; (vi) SSTF; e (vii) SCAN. Para demonstrar como ocorre o escalonamento em cada tipo de algoritmo, foi elaborada a Tabela 2 , com processos a serem escalonados, instante de chegada (instante em que cada processo está pronto para o início da execução), tempo de execução do processo (tempo de processamento), prioridade, deadline absoluto e setor (este caso para exemplos de escalonamento para acesso a disco). Essas características serão utilizadas de acordo com o algoritmo de escalonamento, sendo apresentado como cada algoritmo atende o mesmo conjunto de processos, de maneiras diferentes. 4 Sistema de tempo real é um sistema no qual a corretude depende não apenas dos resultados lógicos da computação, mas também do tempo no qual os resultados são produzidos. 5 Deadline é o tempo máximo em que um processo pode terminar sua execução. 24 Tabela 2. Processos a serem escalonados Processo P1 P2 P3 P4 P5 Instante de chegada 0 0 2 3 5 Tempo de execução 5 4 1 3 2 Prioridade Deadline absoluto 13 8 5 15 10 2 4 3 1 0 Setor Selecionado 70 30 20 50 20 2.4.1. FIFO (First In First Out) O algoritmo de escalonamento FIFO seleciona os processos conforme seu instante de chegada, ou seja, o primeiro processo criado será o primeiro a ser escalonado. Esse algoritmo não considera quaisquer características dos processos além de seu tempo de chegada, tendo como única vantagem a sua simplicidade. Conforme mostrado na Figura 12, o escalonamento FIFO executa o processo que chega primeiro até seu término, para depois iniciar a execução do processo seguinte na fila, sem levar em consideração outras características que não seja o tempo de chegada dos processos. A seta para cima ( ) indica o instante de criação do processo, ou seja, o momento que ele está pronto para ser executado. Processos P5 P4 P3 P2 P1 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 Tempo Figura 12. Escalonamento dos processos utilizando FIFO Silberchatz (2000) apresenta outra forma de visualização do atendimento dos processos é utilizando o diagrama de Gantt. Esse diagrama mostra as unidades de tempo e o processo que foi executado em cada uma. Na Figura 13, é apresentado o diagrama de Gantt para os processos da tabela quando escalonados pelo algoritmo FIFO. 25 Tempo P1 0 1 P1 2 P1 3 P1 4 P1 5 P2 Processos P2 P2 P2 6 7 8 9 P3 10 P4 11 P4 12 P4 13 P5 14 P5 Figura 13. Escalonamento dos processos utilizando FIFO visualizado na forma de diagrama de Gantt 2.4.2. Prioridade No algoritmo de escalonamento por prioridade, a cada processo é atribuída uma prioridade. O algoritmo escalona primeiro os processos com maior prioridade e se dois processos têm a mesma prioridade, a cada um deles é fornecido uma fatia de tempo (quantum) e eles passam a compartilhar o processador (escalonamento circular). Em geral, utiliza-se a notação que um valor numérico menor significa maior prioridade, ou seja, prioridade 0 é o maior nível de prioridade. Na Tabela 2, o processo P5 é mais prioritário e o processo P1 é menos prioritário. Um dos problemas deste algoritmo é a possibilidade de postergação indefinida dos processos, ou seja, processos pouco prioritários podem ser adiados indefinidamente. Uma possível solução para esse problema é o uso da técnica de envelhecimento, na qual a prioridade dos processos que aguardam por muito tempo é incrementada. Neste método de escalonamento, a prioridade é reavaliada a cada chegada de um novo processo. Um processo pode ser preemptado para permitir a execução de outro processo mais prioritário que esteja pronto para ser executado naquele momento. Na Figura 14, é ilustrado o uso deste escalonamento sobre os processos da Tabela 2. O símbolo e nas células indica que o processo está esperando, ou seja, foi preemptado para permitir a execução de um processo mais prioritário. É o caso do processo P4, que inicia sua execução no tempo 3 e é interrompido no tempo 5 pela chegada do processo P5, mais prioritário. Processos P5 P4 P3 P2 P1 e 0 1 2 3 e 4 e 5 e e 6 e 7 e 8 Tempo Figura 14. Escalonamento dos processos utilizando prioridade 26 9 10 11 12 13 14 Tempo P1 0 P1 1 2 P1 3 P4 4 P4 5 P5 6 Processos P5 P4 P1 7 8 9 P1 10 P3 11 P2 12 P2 13 P2 14 P2 Figura 15. Escalonamento dos processos utilizando prioridade visualizado na forma de diagrama de Gantt 2.4.3. Filas múltiplas No escalonamento de filas múltiplas, os processos pendentes são colocados em uma de várias possíveis filas, dependendo de suas características. Cada fila tem uma prioridade diferente e os processos em cada uma das filas podem ser escalonados por algoritmos diferentes. Desse modo, apenas se a fila mais prioritária estiver vazia, a segunda fila mais prioritária será analisada e assim sucessivamente. Esse algoritmo permite dividir os processos em categorias (filas), e atender cada categoria utilizando um critério diferente. Diz-se que o algoritmo de filas múltiplas é o escalonador de “alto nível”, enquanto cada algoritmo utilizado em uma fila específica, é o escalonador de “baixo nível”. Como exemplo, na Tabela 3 estão apresentadas as filas e o algoritmo de cada uma delas, e na Figura 16, são mostrados os processos da tabela, executando com base nesse algoritmo. Tabela 3. Algoritmos das filas Fila 1 2 3 Processos P5 P4 P3 P2 P1 Algoritmo Circular Prioridade FIFO e e e 0 1 2 3 e 4 5 6 7 8 9 Tempo Figura 16. Escalonamento dos processos utilizando filas múltiplas 27 10 11 12 13 14 Tempo 0 P1 1 P1 2 P1 3 P4 4 P1 5 P4 6 Processos P1 P4 P5 7 8 9 P5 10 P5 11 P4 12 P2 13 P2 14 P2 Figura 17. Escalonamento dos processos utilizando filas múltiplas visualizada como diagrama de Gantt 2.4.4. SJF (Smallest Job First) No escalonamento SJF, a cada processo é atribuída uma estimativa do seu tempo de execução e o escalonador seleciona primeiro o processo com a estimativa de menor duração. Esse algoritmo tem dois problemas principais: a dificuldade em estimar corretamente o tempo de execução de um processo e a possível postergação indefinida de processos. A Figura 18 apresenta o escalonamento dos processos da Tabela 2, quando usado o algoritmo SJF. Ainda na Figura 18, pode-se observar que o processo P1 ficou por último por ser o maior, e os processos de tamanhos menores foram executados primeiro. Processos P5 P4 P3 P2 P1 e 0 1 2 3 4 5 6 7 8 Tempo 9 10 11 12 13 14 Figura 18. Escalonamento dos processos utilizando SJF Tempo 0 P1 1 P1 2 P2 3 P3 4 P3 5 P5 6 Processos P5 P4 P4 7 8 9 P4 10 P1 11 P1 12 P1 13 P1 14 P1 Figura 19. Escalonamento dos processos utilizando SJF visualizado no diagrama de Gantt 2.4.5. EDF (Earliest Deadline First) Neste escalonamento, a cada processo pendente é atribuído um prazo final para sua execução (deadline). O processo com o prazo final mais próximo será executado primeiro. Esse é o 28 algoritmo de tempo real mais difundido, embora não considere outras características da tarefa além de seu prazo final. As setas para baixo ( ), mostradas na Figura 20, representam os tempos máximos em que esses processos podem ser executados. Os processos que não forem executados no prazo necessário serão perdidos, ou seja, não são mais executados. É o caso que ocorre com o processo P1, que deveria executar em 5 unidades de tempo, executou três e foi perdido, pois não conseguiu cumprir seu deadline. Um bom escalonador de tempo real deve ter uma taxa de perda de deadline baixa. Processos P5 P4 P3 P2 P1 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 Tempo Figura 20. Escalonamento dos processos utilizando EDF Tempo 0 P2 1 P2 2 P3 3 P3 4 P3 5 P2 6 Processos P2 P5 P5 7 8 9 P1 10 P1 11 P1 12 P4 13 P4 14 P4 Figura 21. Escalonamento dos processos utilizando EDF visualizado no diagrama de Gantt 2.4.6. SSTF (Smallest Seek Time First) O algoritmo SSTF é usado no escalonamento de requisições geradas por processos que queiram acessar setores do disco rígido. Ele ordena as requisições pendentes com base na distância entre o setor requisitado por cada processo e a posição atual do cabeçote de leitura/gravação do driver do disco rígido. A requisição que necessitar de menor deslocamento (seek time) do cabeçote será atendida primeiro. Esse algoritmo tende a minimizar o movimento do cabeçote, embora possa causar a postergação indefinida de requisições muito distantes. A Figura 22 representa um disco rígido com o braço do cabeçote posicionado no setor 40. 29 Setores 70 P1 60 P4 50 40 30 P2 20 10 P3 0 1 2 P5 3 4 5 6 7 Tempo 8 9 10 11 12 13 14 Figura 22. Escalonamento dos processos utilizando SSTF No instante 0, há duas requisições pendentes para o setor 70 (P1) e para o setor 30 (P2). O braço do cabeçote desloca-se então para baixo e a requisição do processo P2 é atendida. O símbolo “ ” indica o atendimento das requisições. No tempo 1, a única requisição pertence a P1 (setor 70), pois o P3 só é criado no tempo 2. Após, o cabeçote desloca-se para cima para atender o processo P1, mas no tempo 2, o processo P3 é criado e sua requisição (setor 20) está mais próxima do braço do cabeçote. E esse, então, inverte seu movimento e atende a requisição do processo P3 no tempo 4. Nesse instante, a requisição mais próxima é a do P4 (setor 60) e o braço do cabeçote desloca-se para cima. No tempo 5, o processo P5 é criado e sua requisição está mais próxima. O braço inverte o movimento e desloca-se para baixo a fim de atendê-lo, o que ocorre no instante 6. Após, o braço do cabeçote desloca-se para cima e atende a requisição do P4 (setor 60) e requisição do P1 (setor 60). 2.4.7. Scan O algoritmo SCAN também é aplicado no escalonamento de requisições de acesso ao disco rígido e movimenta o cabeçote de leitura/gravação numa direção, atendendo todas as requisições pendentes em seu caminho, até a requisição mais distante. Após, ele inverte a direção e procede da mesma maneira. Esse algoritmo pode levar a mais movimentos do cabeçote do que o algoritmo SSTF, entretanto, não causa postergação indefinida. A Figura 23 mostra a execução dos processos utilizando o algoritmo SCAN supondo que o cabeçote de leitura esteja no setor 40 se movendo para baixo. A Figura 24 sugere o mesmo escalonamento mas com o cabeçote do setor 40 movimentando-se para cima. 30 Na Figura 23, quando o braço move-se para baixo, vai atendendo as requisições de processos que estejam em seu caminho, neste caso atendendo os processos P2 e P3. O braço do cabeçote move-se então para acima até seu extremo, atendendo os processos P5, P4 e P1 que estão em seu caminho neste momento. Setores 70 P1 60 P4 50 40 30 P2 20 P3 10 0 1 2 P5 3 4 5 6 7 Tempo 8 9 10 11 12 13 14 Figura 23. Escalonamento dos processos utilizando SCAN Já na Figura 24, quando o braço desloca-se para cima primeiro, faz novamente a movimentação até seus pontos extremos, atendendo todos os processos em seu caminho. Nesse caso, atende os processos P4 e P1 quando movimenta-se para cima e os processos P3, P5 e P2 quando movimenta-se para baixo. Setores 70 P1 60 P4 50 40 30 P2 20 P3 10 0 1 2 P5 3 4 5 6 7 Tempo 8 9 10 11 12 13 14 Figura 24. Escalonamento dos processos utilizando SCAN 2.4.8. Considerações O escalonamento das requisições de observações astronômicas deste trabalho faz uso de características de diversos escalonadores citados nas sessões acima, conforme exemplos práticos citados abaixo. • FIFO: no caso de mais de uma requisição de usuários com mesma prioridade, o sistema os atenderá por ordem de chegada; 31 • Prioridade: a cada usuário cadastrado será atribuída uma prioridade. No escalonamento das requisições, será utilizado o método de prioridade para executar a requisição; e • EDF: este algoritmo será utilizado no escalonamento de requisições com tempo exato para atendimento. Por exemplo, na ocorrência de um eclipse solar, se a requisição não for atendida no momento agendado, ela será perdida; Como proposta a uma etapa seguinte deste trabalho, sugere-se um refinamento (otimização) das requisições escalonadas. Esse refinamento baseia-se em fazer melhor uso do telescópio, ou seja, otimizar a sua movimentação. Para isto, será feito o uso de outros métodos de escalonamento, que são descritos a seguir: • SSTF: A requisição que necessitar de menor deslocamento do telescópio seria atendida primeiro. Esse algoritmo tende a minimizar o movimento do telescópio, embora possa causar a postergação indefinida de requisições muito distantes. Mas fatia com que o telescópio sofresse pequenos movimentos para atender diversas requisições; e • SCAN: a característica deste escalonador em relação a este trabalho, é que quando o telescópio movimenta-se para um determinado local, ele atenda as requisições que estejam em seu caminho. Isto evitaria que o telescópio fosse movimentado para um local, e depois, para atender outra requisição, fizesse um caminho semelhante. 2.5. AMBIENTE DE DESENVOLVIMENTO Para o desenvolvimento do sistema proposto, foi escolhida a linguagem C++ pois possui recursos necessários a este trabalho. Conforme destaca Deitel (2001), “como C é uma linguagem padronizada, independente de hardware e amplamente disponível, aplicativos escritos em C podem ser freqüentemente executados com pouca ou nenhuma modificação em uma ampla variedade de sistemas de computação diferentes”. Essa linguagem também permite o desenvolvimento orientado a objeto, que tem diversas vantagens, tais como: • Compatibilidade, portabilidade; • Segurança; • Reusabilidade; 32 • Facilidade de integração; • Facilidade de extensão; e • Eficiência. Esta linguagem também permitiu que uma interce Web fosse gerada, utilizando componentes disponíveis. Isso trouxe vários benefícios a este trabalho, pois todo o desenvolvimento foi feito utilizando uma única ferramenta. Além disso, ressalta-se que existem diversas rotinas astronômicas já desenvolvidas em C (SILVA, 2003), as quais serão utilizadas no projeto e são descritas brevemente na subseção a seguir. 2.5.1. Rotinas disponíveis Um TCC desenvolvido na Univali (SILVA, 2003) referiu-se a um protótipo para automatizar um telescópio. O desenvolvimento e a implantação deste projeto, visaram a criação de um sistema embarcado, baseado em um microcontrolador, para controlar um telescópio com montagem equatorial, possibilitando o auxílio na observação astronômica para pesquisadores e alunos, visando uma melhor aprendizagem, através do acompanhamento e localização automática dos corpos celestes. A seguir são apresentadas as rotinas implementadas no Trabalho de Conclusão de Curso (SILVA, 2003) e que são relevantes a este trabalho. • Verificar comando: esta função apresenta o menu, espera o comando informado pelo usuário e invoca o processo responsável por executá-lo; • Encaminhar dados: nesta função é verificada qual informação é digitada pelo usuário, e para qual processo devem ser enviados os dados lidos, de acordo com a opção; • Ler longitude: processo que converte uma string recebida para uma estrutura do tipo longitude, enviando a estrutura para ser validada e posteriormente convertida em graus decimais; • Validar longitude: este processo verifica se uma longitude fornecida pelo usuário está correta, ou não; 33 • Converter longitude: função que converte uma estrutura do tipo longitude em graus para a unidade de graus decimais, recebendo uma estrutura do processo ler longitude e enviando o resultado para verificar comando; • Ler hora: este processo recebe uma opção na qual determina onde deve ser feita a validação da hora, declinação, ascensão reta ou latitude, enviando em seguida a estrutura para ser em um número real; • Validar Hora_Ar: este processo verifica se uma estrutura do tipo hora ou ar (ascensão reta) fornecida pelo usuário está correta, ou não; • Validar Dec_Lat: esta função verifica se uma estrutura do tipo declinação ou latitude fornecida pelo usuário está correta, ou não; • Converter Hora: função que converte uma estrutura do tipo hora no formato hh/mm/ss para a unidade de horas decimais, recebendo uma estrutura do processo Ler Hora, e enviando o resultado para verificar comando; • Ler Inteiro: processo que recebe uma string e transforma em inteiro enviado para verifica comando; • Movimentar: processo que tem o objetivo de verificar qual tecla foi pressionada, enviando assim o número de passos correspondentes para o motor de passo adequado; • Calcular Passo Motor Z: processo que controla o motor de passo Z, bem como calcular e controlar sua posição atual, e movimentos futuros; • Calcular Passo Motor H: processo que controla o motor de passo H, bem como calcular e controlar sua posição atual e movimentos futuros; • Calcular Passo Anti-Horário: processo que calcula o próximo passo a ser realizado pelo motor de passo no sentido anti-horário; • Calcular Passo Horário: processo que calcula o próximo passo a ser realizado pelo motor de passo no sentido horário; • Calcular dia Juliano: esta função calcula o dia Juliano através da hora, data, e da longitude atual; • Processo 5.2 Calcula TS: este processo é utilizado para calcular o tempo sideral, através do dia juliano e da longitude local. Este processo é de autoria de Thorstensen (1993); 34 • Incrementa TS: esta função recebe e incrementa o tempo sideral a cada segundo, e a cada 240 segundos, que equivale a 4 minutos (considerando que o motor de passo gire um grau por passo), enviando um passo e o tempo sideral para calcular H; • Calcula Z: este processo calcula a distância zenital e recebe através da função calcular H as informações da estrela. Verifica também, se o Zênite é menor que o ângulo permitido de 60º, e enviando a quantidade de passos e a direção para o Calcula Passo Motor Z; • Calcular H: calcula o Ângulo Horário através do tempo sideral e da ascenção reta da estrela a ser observada; • Ler EEPROM: função que procura na EEPROM interna e externa uma estrela com código igual à obtida; • Gravar EEPROM: função que procura nas EEPROM’s interna e externas um endereço livre e grava uma estrutura do tipo estrela num endereço vago. Se a estrela já está armazenada na memória, o processo grava a nova estrela na posição da estrela anterior; • Calcular Precessão: calcula a precessão da Estrela, a partir do ano do catálogo até a data atual. 2.5.2. Fluxo de execução Conforme Silberchatz (2000), o estado de um processo é definido por pelos recursos que ele está utilizando e pela posição na qual está sendo executado. Existem muitos casos em que seriam úteis o acesso e o compartilhamento o acesso e o compartilhamento simultâneo de recursos. Essa situação é realizada com um novo contador de instruções, ou fluxo de execução chamada thread, com o processamento compartilhando o mesmo espaço de endereçamento. Esse mesmo autor define fluxo de execução (thread), também chamado de processo leve (lightweight process), como uma unidade básica de utilização da CPU, consistindo de um contador de instruções, um conjunto de registradores e um espaço de pilha. O fluxo de execução compartilha com fluxos irmãos sua seção de código, a seção de dados e recursos do sistema operacional, como arquivos abertos e sinais, conhecido coletivamente como uma tarefa. Silberchatz (2000) também define soquete ou socket como interfaces para operações de entrada e saída em rede, que, por analogia, pode ser comparado a um soquete de energia elétrica em 35 que qualquer para eletrodoméstico poderia ser conectado. Dessa forma, a interface do soquete consiste em rotinas do sistema que permitem a uma aplicação criar um soquete, conectar um soquete local e um endereço remoto (que conecta esta aplicação a um soquete criado por outra aplicação), de forma a poder enviar e receber pacotes com dados por essa conexão. [FIM DE SEÇÃO. Não remova esta quebra de seção] 36 3. DESENVOLVIMENTO Neste capítulo, são apresentados o projeto e a implementação do sistema. O projeto descreve a análise dos requisitos, as especificações e a modelagem do sistema, enquanto que a implementação apresenta aspectos relativos à materialização e à validação. A modelagem foi feita utilizando UML (Unified Modeling Language) que é uma linguagem de modelagem padronizada para engenharia de sistemas orientados a objeto. De acordo com Furlan (1998), a UML foi concebida a partir de várias técnicas de projeto e análise orientados a objeto (OOA&D - Object Oriented Analysis & Design) existentes, desenvolvidas por diferentes autores, como Coad e Yourdon, Shlaer e Mellor, Odell e Martin e, principalmente, a partir do "método unificado" OOSE (Object Oriented Software Engineering), de Booch, Rumbaugh e Jacobson. Pode-se dizer que o objetivo principal da UML é definir uma linguagem de modelagem visual e expressiva, no sentido de prover facilidades na visualização, ou seja, o pleno entendimento das funções de um sistema a partir de diagramas que o representem, no gerenciamento de complexidade, permitindo uma representação simplificada das atividades do sistema, ou seja, que cada aspecto funcional dele seja representado em modelos específicos e, por fim, na comunicação, unificando a comunicação da equipe de desenvolvimento na forma de diagramas. Um diagrama é uma apresentação gráfica de uma coleção de elementos de modelo, freqüentemente mostrado como um gráfico conectado de arcos (relacionamentos) e vértices (outros elementos do modelo). Nas sessões a seguir serão apresentados os requisitos funcionais, as especificações e os diagramas que representam este projeto. 3.1. PROJETO 3.1.1. Análise de Requisitos Os requisitos funcionais descrevem a funcionalidade que o sistema possui, ou seja, o que ele faz. Esses requisitos serão melhor descritos na especificação do sistema. Abaixo, são descritos os requisitos funcionais: • O sistema permite que usuários se cadastrem; • O sistema permite que usuários submetam requisições; • O sistema agenda requisições de acordo com a prioridade de cada usuário e conforme segue: 1. O horário escolhido para observação deve ser no período noturno; 2. No formulário da requisição o usuário pode escolher entre o nome do astro ou definir as coordenadas; 3. O astro deve estar visível no horário escolhido; 4. Agenda a requisição somente se não houver nenhuma requisição mais prioritária na hora e data especificadas; 5. Se houver uma requisição menos prioritária, esta é reagendada e tem sua prioridade incrementada; e 6. Se houver requisição idêntica quanto à observação a ser realizada (coordenadas, data e hora), faz agrupamento com a requisição mais prioritária. • Na data especificada, o sistema dá inicio à execução, realizando as seguintes funções: 1. Verifica se as condições meteorológicas estão adequadas; 2. Envia o comando de abertura da cúpula; 3. Envia o comando de calibração; 4. Envia o comando de localização das coordenadas; 5. Captura imagem; 6. Envia imagem por e-mail; 7. Se alguma das condições anteriores não for satisfeita, a requisição é reagendada e usuário avisado por e-mail. 3.1.2. Especificações As especificações são os requisitos funcionais apresentados de forma mais detalhada, incluindo informações importantes para o sistema, como a tecnologia utilizada e a descrição de como foram realizados. Os itens abaixo descrevem as especificações deste sistema: 38 • O sistema permite que usuários se cadastrem. O sistema possui uma interface Web com um formulário eletrônico com campos de informações que devem ser preenchidos pela pessoa/instituição que deseja utilizar o observatório. A pessoa solicita a submissão das informações deste formulário, que são armazenadas em um banco de dados e marcadas como “cadastro pendente”. No momento adequado o administrador avaliará os cadastros pendentes e decide pela sua aprovação ou rejeição, marcando o cadastro como “ativo” ou excluindo as informações do banco de dados, e, após, notificando o usuário. Caso o usuário tenha o seu cadastro aprovado ele poderá efetivamente acessar o sistema; • O sistema permite que usuários submetam requisições. Para a submissão de requisições, o usuário deve efetuar sua autenticação (login) no sistema. Estando autenticado, ele deve preencher um formulário eletrônico com informações da sua requisição (nome do astro, coordenadas, horário, filtro, etc.). Após o usuário submeter o formulário, o sistema faz a validação desses campos. Caso todos os campos satisfaçam as condições impostas, a requisição é escalonada e o usuário recebe uma mensagem com a data e o horário nos quais a requisição será atendida. Caso haja problemas de validação, o sistema rejeitará a requisição e o usuário recebe uma mensagem com o motivo dessa rejeição. As validações feitas pelo sistema no momento da solicitação da requisição são especificadas a seguir: 1. O horário escolhido para observação deve ser no período noturno: Esta validação é realizada apenas caso o usuário tenha especificado um horário na requisição. São utilizados cálculos astronômicos que determinam os instantes do pôr do Sol e do nascer do Sol em uma determinada data. Se o horário escolhido estiver entre esses instantes, então ele corresponderá ao período noturno; 2. No formulário da requisição o usuário pode escolher entre o nome do astro ou definir as coordenadas: Caso o usuário escolha o nome de um astro, as coordenadas já estarão armazenadas no banco do sistema e, serão portanto, consistentes. Se ele escolher as coordenadas, essas são verificadas por meio da simples comparação dos valores com os limites aceitáveis para coordenadas; 3. O astro deve estar visível no horário escolhido: Dadas a coordenadas do astro, o sistema fará uma redução ao dia para verificar se, na data e horário especificados, o astro se encontrará no mínimo a 20º sobre o horizonte; 39 4. Agenda a requisição somente se não houver nenhuma requisição mais prioritária na hora e data especificadas: Se na data e hora especificadas em uma requisição não houver nenhum agendamento, esta requisição será agendada. Se na data e hora houver uma requisição mais prioritária, a requisição será negada. Caso na data e hora especificadas houver uma requisição com prioridade mais baixa, a requisição atual será agendada, e a menos prioritária será reagendada e sua prioridade incrementada; e 5. Se houver requisição idêntica quanto à observação a ser realizada (coordenadas, data e hora), faz agrupamento com a requisição mais prioritária: Quando uma requisição entra no sistema, a primeira coisa a ser feita é uma varredura em todas as requisições para verificar se já existe requisição idêntica, pois, se existir, o sistema insere mais um usuário a uma requisição já criada, não precisando criar nova requisição. • Atender a requisição na data especificada: Para atender uma requisição, as seguintes funções são realizadas: 1. Verifica se as condições meteorológicas estão adequadas: O sistema faz verificação de umidade, vento e temperatura interna e externa do observatório através de sensores no observatório ou páginas meteorológicas. Se os valores dessas verificações estiverem dentro dos limites especificados pelo sistema, dá-se continuidade ao atendimento, caso contrário, a requisição é reagendada e o usuário notificado; 2. Envia o comando de abertura da cúpula: Se as condições meteorológicas estiverem adequadas, então a cúpula poderá ser aberta. Este comando será enviado ao driver do sistema embarcado, um programa responsável pela comunicação com o sistema computacional dedicado ao acionamento dos componentes do observatório; 3. Envia o comando de calibração: Se esta for a primeira requisição a ser atendida no dia, o telescópio é ligado e faz uma calibração para identificar as coordenadas em que ele se encontra. Caso não seja a primeira requisição, nenhuma ação será tomada; 4. Envia o comando de localização das coordenadas: O sistema encaminha, ao driver do sistema embarcado, as coordenadas correntes do astro da requisição que será atendida. Este então aciona o telescópio; 40 5. Capturar imagem: O sistema passará para o driver um comando para que a câmera CCD acoplada ao telescópio faça a captura da imagem; 6. Envia imagem por e-mail: O sistema recebe a imagem gerada pela câmera CCD e gera uma mensagem eletrônica que é enviada aos usuários que solicitaram a requisição atendida; e 7. Se alguma das condições anteriores não for satisfeita, a requisição é reagendada e usuário avisado por e-mail. 3.1.3. Arquitetura do Sistema Como o trabalho aqui proposto está inserido em um projeto de observatório remoto, foram desenvolvidas ilustrações que representam a arquitetura do projeto como um todo, detalhando a parte em que este trabalho de conclusão de curso se limita. A Figura 25 representa o contexto global do projeto de um observatório remoto. O acesso será via Internet, onde o usuário acessa o servidor e realiza a requisição de observação. Na data e hora em que uma requisição deve ser atendida, o sistema que está no servidor acessa uma estação meteorológica que retorna valores ao servidor, o sistema, de acordo com os valores meteorológicos pode acionar o sistema embarcado que interage com o telescópio e a cúpula. O contexto deste trabalho limita-se ao sistema que está no servidor, não fazendo parte deste, os sistemas embarcados e controles da estação meteorológica e do observatório. Estação Meteorológica Internet Sistema Embarcado ‘ Figura 25. Representação do contexto global do projeto de um observatório remoto 41 A Figura 26 mostra as ligações do contexto global do projeto do observatório remoto, separando o servidor em Interface e Núcleo do Sistema. Tanto a interface quanto o núcleo compõe o projeto aqui proposto. A interface é o meio em que o usuário interage com o sistema do observatório, e o núcleo faz o gerenciamento das requisições. Internet Interface Núcleo do Sistema Driver do Sistema Embarcado Interface Estação Sistema Embarcado Figura 26. Ligações do contexto global do projeto do observatório remoto A Figura 27 representa as camadas envolvidas no projeto do observatório remoto, destacando, a proposta do presente TCC. O usuário acessa a página Web que se comunica com o gerenciador do sistema, este por sua vez, aciona o escalonador que utiliza outros recursos (Astrônomo, Temporizador, Meteorologista) para escalonar a requisição, ou o Executor, para executar uma requisição agendada. 42 Usuário Interface Web Sistema Astra Gerenciador Escalonador Executor Astrônomo Temporizador Meteorologista Driver do Sistema Embarcado Interface da Estação Meteorológica Sistema Embarcado Estação Meteorológica Observatório Figura 27. Camadas envolvidas no projeto do observatório remoto 3.1.4. Diagramas UML Abaixo são apresentados os diagramas UML com suas devidas explicações. Foram utilizados os diagramas que representam aspectos da estrutura e aspectos dinâmicos do sistema. 3.1.4.1. Diagrama de Caso de uso Diagramas de caso de uso descrevem os requerimentos funcionais do sistema de maneira conceitual entre usuários e desenvolvedores de sistemas. Ele fornece uma descrição consistente e clara sobre as responsabilidades que devem ser cumpridas pelo sistema, além de formar a base para a fase de desenho (FURLAN, 1998). O sistema possui dois atores, o usuário e o administrador; por este motivo foi construído dois diagramas de caso de uso, um para cada ator, conforme mostra a Figura 28 e a Figura 29. A figura abaixo ilustra todas as ações que o administrador tem condições de realizar. 43 ud Caso de uso do Administrador Aprov ar/Reprov ar Cadastro do Usuário Ver Cadastro de Usuários Fazer Login Listar Requisições Pendentes de usuários Modificar Agendamento Administrador Ver Utilização do Telescópio Fazer Manutenção do Observ atório Excluir Usuários Listar Usuários Fazer Administração do Site Figura 28. Diagrama de caso de uso do administrador O diagrama de caso de uso do usuário ilustra todas as ações que o usuário é capaz de realizar. 44 ud Caso de uso do usuário Ver Condições Metereológicas Preencher Cadastro Submeter Cadastro Listar Requisições Pendentes Confirmar Cadastro Preencher Requisição Alterar Cadastro Usuário Pedir Exclusão do Cadastro Submeter Requisição Alterar Requisição Fazer Login Excluir Requisição Figura 29. Diagrama de caso de uso do usuário 3.1.4.2. Diagrama de Classes O diagrama de classes representa a estrutura lógica estática em uma superfície e a coleção de elementos que descrevem o modelo e as suas relações. Cada classe descreve as ações que serão realizadas. A Figura 30 descreve as classes desse sistema, que são: Gerenciador, Escalonador, Meteorologista, Executor, Astrônomo e Temporizador; todos com as suas devidas ações a serem realizadas. 45 c d As tr a W e b TW e b Mo d u le TW e bM odule 1 # # # # # # # # # # # - p p In d e x: TP a g e P ro d u c e r* C lie n tS o cke t: TC lie n tS o ck e t* p p P rin cip a l: TP a g e P ro d u ce r* p p C a d a s tro : TP a g e P ro d u ce r* p p R e q u is ic a o : TP a g e P ro d u ce r* p p L o g in In va lid o : TP a g e P ro d u ce r* T im e rT im e o u t: TTim e r* p p E s q u e c e u S e n h a : TP a g e P ro d u ce r* p p E n vio u S e n h a : TP a g e P ro d u ce r* p p R e q P e n d e n te s : TP a g e P ro d u ce r* p p R e q L is ta : T P a g e P ro d u ce r* a Tim e o u t: b o o l # # # # # # # # # # # # + W e b Mo d u le 1 Actio n S u b m itR e q u e s tActio n (TO b je ct* , TW e b R e q u e s t* , T W e b R e s p o n s e * , b o o l& ) : vo id W e b Mo d u le 1 P o s tL o g in Actio n (TO b je ct* , T W e b R e q u e s t* , TW e b R e s p o n s e * , b o o l& ) : vo id p p P rin cip a lH TML Ta g (TO b je ct* , TTa g , An s iS trin g , TS trin g s * , An s iS trin g & ) : vo id W e b Mo d u le 1 G e tP rin c ip a lAc tio n (TO b je ct* , TW e b R e q u e s t* , TW e b R e s p o n s e * , b o o l& ) : vo id T im e rT im e o u tTim e r(T O b je c t* ) : vo id W e b Mo d u le 1 a cS u b m itS e n h a Actio n (TO b je ct* , T W e b R e q u e s t* , TW e b R e s p o n s e * , b o o l& ) : vo id W e b Mo d u le 1 a cS u b m itR e q u is ica o Ac tio n (TO b je ct* , TW e b R e q u e s t* , TW e b R e s p o n s e * , b o o l& ) : vo id p p R e q u is ic a o H TML Ta g (TO b je ct* , TT a g , An s iS trin g , TS trin g s * , An s iS trin g & ) : vo id p p R e q P e n d e n te s H TML T a g (TO b je c t* , TTa g , An s iS trin g , TS trin g s * , An s iS trin g & ) : vo id W e b Mo d u le 1 a cR e q u is ica o Actio n (TO b je c t* , TW e b R e q u e s t* , TW e b R e s p o n s e * , b o o l& ) : vo id W e b Mo d u le 1 a cR e s P e n d e n te s Actio n (TO b je ct* , T W e b R e q u e s t* , TW e b R e s p o n s e * , b o o l& ) : vo id W e b Mo d u le 1 a cS u b m e te C a d a s tro Actio n (TO b je ct* , TW e b R e q u e s t* , TW e b R e s p o n s e * , b o o l& ) : vo id Ve rifica P a ra m e tro s C o rre to s U R L (TO b je ct* , TW e b R e q u e s t* , TW e b R e s p o n s e * , b o o l& ) : vo id C o n n e ctTo As tra K e rn e l() : b o o l D is co n n e ctTo As tra K e rn e l() : vo id S e n d Me s s a g e To As tra K e rn e l(S trin g ) : in t S e n d Fie ld s To As tra K e rn e l() : in t S e n d Fie ld s To As tra K e rn e l(S trin g ) : in t R e c e ive Me s s a g e Fro m As tra K e rn e l() : S trin g G e tR e q u e s tFie ld s () : S trin g G e tQ u e ryFie ld s () : S trin g G e tQ u e ryFie ld (S trin g ) : S trin g T W e b Mo d u le 1 (TC o m p o n e n t* ) Figura 30. Diagrama de classes do Astra Web 46 c d As tr a Ke rne l ClGe re n c ia dor - Me te o ro lo g is ta : C lMe te o ro lo g is ta * E s ca lo n a d o r: C lE s c a lo n a d o r* C a rte iro : C lC a rte iro * Ta b U s u a rio s : C lT a b U s u a rio s * Ta b As tro s : C lTa b As tro s * Ta b H o ra rio s : C lTa b H o ra rio s * Ta b R e q u is ico e s : C lTa b R e q u is ic o e s * Ta b Me te o ro lo g ic o s : C lTa b Me te o ro lo g ico s * Ta b R e q u is ico e s _ U s u a rio : C lTa b R e q u is ic o e s _ U s u a rio * Ta b In s titu ic o e s : C lTa b In s titu ico e s * Ta b C a rg o s : C lT a b C a rg o s * S e rve rS o c k e t: TS e rve rS o c k e t* + + + + - C lG e re n c ia d o r(vo id ) _ Fa z_ Te s te s () : vo id _ C ria G ra fic o C o n d ic o e s (in t) : vo id _ C ria G ra fic o R e q (in t, in t) : vo id _ E fe tu a _ L o g in (S trin g , S trin g , s R e g is tro U s u a rio *) : in t _ O n S o ck e tG e tTh re a d (S ys te m ::TO b je c t*, TS e rve rC lie n tW in S o ck e t* , TS e rve rC lie n tTh re a d * & ) : vo id _ Tra ta Me n s a g e m W e b (S trin g , S trin g *) : vo id _ Tra ta Me n s a g e m L o g in (TS trin g L is t* ) : S trin g _ Tra ta Me n s a g e m G e tN u m R e q (TS trin g L is t* ) : S trin g _ Tra ta Me n s a g e m E s q u e ce u S e n h a (TS trin g L is t* ) : S trin g _ Tra ta Me n s a g e m S u b m e te R e q u is ic a o (T S trin g L is t* ) : S trin g _ Tra ta Me n s a g e m G e tN o m e As tro s (TS trin g L is t*) : S trin g _ Tra ta Me n s a g e m G e tR e q P e n d e n te s (TS trin g L is t* ) : S trin g _ Tra ta Me n s a g e m S u b m e te C a d a s tro (TS trin g L is t*) : S trin g C lL o g ClAs tronom o # # # # # # # # C lAs tro n o m o (vo id ) Fa c a _ R e d u c a o _ a o _ D ia (TD a te Tim e , d o u b le , d o u b le , TD a te T im e , d o u b le * , d o u b le * ) : vo id D e te rm in e _ P e rio d o _ Vis ive l_ n a _ D a ta (TD a te Tim e , d o u b le , d o u b le , TD a te Tim e , TD a te Tim e *, TD a te Tim e *) : vo id C a lc u le _ D a ta _ J u lia n a (flo a t, TD a te Tim e , flo a t) : flo a t C a lc u le _ Te m p o _ S id e ra l(flo a t, flo a t) : flo a t C a lc u le _ An g u lo _ H o ra rio (flo a t, flo a t) : flo a t C a lc u le _ Z(flo a t, flo a t) : flo a t C a lc u le _ Altu ra _ As tro (TD a te Tim e , d o u b le , d o u b le , T D a te Tim e , TD a te Tim e ) : flo a t C lL o g ClEs c a lona d or ClEx e c utor + - As tro n o m o : C lAs tro n o m o * m e n s a g e m : S trin g E xe c u to r: C lE xe c u to r* Te m p o riza d o r: C lT e m p o riza d o r* C a rte iro : C lC a rte iro * Ta b H o ra rio s : C lTa b H o ra rio s * Ta b R e q u is ic o e s _ U s u a rio : C lTa b R e q u is ic o e s _ U s u a rio * Ta b R e q u is ic o e s : C lTa b R e q u is ico e s * Ta b U s u a rio s : C lTa b U s u a rio s * Ta b As tro s : C lTa b As tro s * # # # - C lE s c a lo n a d o r(vo id ) R e q u is ic a o _ Te rm in a d a () : in t E s c a lo n e _ R e q u is ic a o (TS trin g L is t* , s R e g is tro R e q u is ic a o , b o o l) : S trin g _ Ve rifiq u e _ As tro _ Vis ive l_ N a _ D a ta (TD a te Tim e , TD a te Tim e , d o u b le , d o u b le , T D a te Tim e ) : b o o l Ve rifiq u e _ As tro _ Vis ive l(s R e g is tro R e q u is ic a o ) : b o o l _ E xe c u te _ R e q u is ic a o () : vo id _ In ic ie _ Te m p o riza c a o _ E s ca lo n a m e n to () : in t _ Ag ru p e _ R e q u is ic a o (T S trin g L is t*, s R e g is tro R e q u is ica o *, TD a te Tim e , TD a te Tim e ) : in t _ E xc lu i_ R e q u is ic a o _ B a n c o (in t) : vo id _ E s ca lo n e _ R e q u is ic a o _ P a ra (TS trin g L is t*, s R e g is tro R e q u is ica o , TD a te Tim e , TD a te Tim e , b o o l) : _ Ve rifiq u e _ R e s tric o e s (s R e g is tro R e q u is ic a o ) : S trin g Figura 31. Diagrama de classes do Astra Kernel 47 - Me te o ro lo g is ta : C lMe te o ro lo g is ta * Te m p o riza d o r: C lTe m p o riza d o r* D rive rS E : C lD rive rS E * C a rte iro : C lC a rte iro * Ta b U s u a rio s : C lTa b U s u a rio s * Ta b As tro s : C lTa b As tro s * Ta b R e q u is ic o e s _ U s u a rio : C lTa b R e q u is ic o e s _ U s u a rio * a T im e o u t: b o o le a n + + - C lE xe c u to r(vo id ) E xe c u te _ R e q u is ic a o (s R e g is tro R e q u is ic a o ) : in t _ T im e o u t() : vo id _ In ic ie Te m p o riza c a o (in t, in t) : vo id S trin g 3.1.4.3. Diagrama de Colaboração O diagrama de colaboração descreve os métodos invocados, quem invoca e quem é invocado. Na Figura 32, as comunicações foram numeradas para facilitar a explicação das ligações. Interface Gerenciador Servidor Web 7 1 4 6 Escalonador Temporizador 5 3 Meteorologista Executor 2 Astrônomo Web Interceptor Figura 32. Diagrama de colaboração Abaixo é apresentada a descrição de cada ligação: • Ligação 1: o Gerenciador recebe os parâmetros da interface Web e invoca o Escalonador para executar todo o processo de escalonamento; • Ligação 2: o Escalonador invoca o Astrônomo, pois um dos passos do escalonamento é a consistência astronômica dos dados submetidos pelo usuário; • Ligação 3: o Escalonador invoca o método Temporizador, sendo que este guarda a data e hora da próxima execução. Então caso o sistema tenha recebido uma nova requisição, o Temporizador deve ser atualizado; • Ligação 4: o Temporizador invoca o Escalonador quando chegar a data e hora da requisição ser atendida; • Ligação 5: caso o Escalonador tenha sido invocado para executar, ele invoca o Executor, que será responsável pela execução; • Ligação 6: quando o Executor estiver ativado, ele invoca o Meteorologista para verificar as condições meteorológicas; e 48 • Ligação 7: o Gerenciador invoca o Meteorologista quando precisa de informações meteorológica para alimentar o banco de dados ou quando um usuário requisitar informações meteorológicas atualizadas. 3.1.4.4. Diagramas de Seqüência O diagrama de seqüência expõe o aspecto do modelo que enfatiza o comportamento dos objetos em um sistema em seqüência temporal de mensagem e representação das atividades e operações. Os objetos são desenhados em linhas verticais e a seqüência das linhas é lida de cima para baixo. Pode-se desenvolver um diagrama de seqüência para cada caso de uso existente. Nas próximas figuras serão apresentados os diagramas de seqüência que descrevem os principais casos de uso deste sistema. No apêndice são apresentados os diagramas de seqüência dos demais casos de uso. No diagrama de seqüência do cadastro do usuário, o usuário acessa a interface, submete o cadastro que vai para o Gerenciador. O cadastro é enviado ao administrador que faz uma avaliação. Caso esta avaliação seja positiva, o Gerenciador grava o cadastro no banco. Um retorno desta avaliação é enviado ao usuário. 49 s d C a d a s t r o d o U s u á r io U s u á ri o In te rfa c e G e re n c i a d o r Ad m P r e e n c h e c a m p o s d o c a d a s tro S u b m e te c a d a s tro S u b m e te c a d a s tr o (d a d o s ) U s u á ri o Va l i d a C a d a s tro Figura 33. Diagrama de seqüência do cadastro do usuário A Figura 34 mostra o diagrama de seqüência da solicitação de uma requisição. O usuário preenche o cadastro e o submete. O Gerenciador envia-o ao Escalonador, que verifica com o Astrônomo se os dados astronômicos inseridos são válidos. Se não forem, ele envia uma mensagem ao usuário informando o problema. O Escalonador ainda verifica se existe choque com outras requisições nesta data e hora. Se for necessário reescalonar uma requisição, ele o faz. O Escalonador também verifica a possibilidade de agrupamento de requisições. Se a requisição for inserida, o Escalonador atualizará o Temporizador e retornará uma mensagem ao usuário. 50 s d S olic ita Re quis iç ã o U s u á rio In te rfa c e G e re n c ia d o r E s c a lo n a d o r As trô n o m o Te m p o riza d o r E fe tu a lo g in [s e n ã o a u te n tica d o ]: "lo g in in vá lid o " [s e a u te n tic a d o ]: P re e n c h e re q u is iç ã o [s e re q u is içã o p re e n c h id a ]: S u b m e te re q u is içã o In c lu i R e q u is iç ã o In c lu i R e q u is iç ã o Ve rifica r co n s is tê n c ia d o s d a d o s a s tro n ô m ic o s [s e d a d o s in c o n s is te n te s ]: "D a d o s in vá lid o s " [s e d a d o s co n s is te n te s e s e n e c e s s ita r d e re e s c a lo n ]: R e e s c a lo n a o u tra s re q u is içõ e s [s e d a d o s a s tro n ô m ic o s o k ]: E fe tu a e s c a lo n a m e n to [s e d a d o s a s tro n ô m ic o s o k ]: Atu a liza te m p o riza d o r [s e e s c a lo n a m e n to o k ]: "R e q u is iç ã o a g e n d a d a c o m s u ce s s o " Figura 34. Diagrama de seqüência da requisição A seguir serão mostrados, em forma de código estruturado, os passos que o sistema segue para a validação e possível inclusão de uma requisição no sistema. 51 C a lc u la a p rio rid a d e d a re q u isiçã o S e (d a ta e h o rá rio d e o b s e rva çã o fo ra m e sp e cific a d o s) e n tã o o E fe tu a re d u ç ã o a o d ia p a ra a d a ta e h o rá rio e sp e cifica d o s a fim d e ve rifica r se o a stro e sta rá n o m ín im o a 2 0 d o h o riz o n te S e (fo r p e rm itid a a o b s e rva ç ã o ) e n tã o S e (n ã o h o u ve r n e n h u m a re q u is içã o p a ra a d a ta e h o rá rio e s p e cifica d o s) e n tã o C a d a s tra a n o va re q u isiçã o S enão S e (já h o u ve r u m a re q u isiçã o a g e n d a d a p a ra o m e sm o a s tro n a d a ta e n o h o rá rio e s p e c ifica d o s) e n tã o A g ru p a re q u isiçõ e s Senão S e (p rio rid a d e d a re q u isiçã o já c ad a stra d a fo r m a io r o u ig u a l q u e a p rio rid a d e d a n o va re q u is içã o ) e n tã o m sg (“n ã o é p o ssíve l ca d a stra r a re q u is içã o p a ra e sta d a ta e /o u h o rá rio !!”) Senão In cre m e n ta a p rio rid a d e d a re q u isiçã o a n tig a C a d a stra a n o va re q u isiç ã o E fe tu a o re a g e n d a m e n to d a re q u isiçã o a n tig a Senão m sg (“n ã o é p o s síve l ca d a stra r a re q u is içã o !”) S e (a p e n a s a d a ta d e o b se rva ç ã o fo i e s p e cifica d a ) e n tã o S e (já h o u v e r u m a re q u is içã o a g e n d a d a p a ra o m e sm o a stro n a d a ta e sp e c ific a d a ) e n tã o A g ru p a re q u is içõ e s Senão S e (n a d a ta e s p e c ific a d a h o u ve r d is p o n ib ilid a d e d e h o rá rio n o p e río d o d e o b s e rva çã o p e rm itid o ) e n tã o B u s ca h o rá rio d is p o n íve l, e fe tu a n d o a re d u çã o a o d ia , a té e n c o n tra r u m h o rá rio e m q u e o a stro e ste ja n o o m ín im o a 2 0 d o h o rizo n te S e (fo r p e rm itid a a o b se rva çã o ) e n tã o C a d a stra a n o va re q u is içã o Senão m s g (“n ã o é p o ss íve l ca d a s tra r a re q u isiçã o !”) S enão S e (h o u ve r re q u isiçã o co m m e n o r p rio rid a d e ) e n tã o E fe tu a re d u ç ã o a o d ia p a ra v e rific a r se n o h o rá rio d a re q u isiçã o d e m e n o r p rio rid a d e o a stro e sta rá o n o m ín im o a 2 0 d o h o riz o n te S e (fo r p e rm itid a a o b se rva ç ã o ) e n tã o In cre m e n ta a p rio rid a d e d a re q u isiçã o a n tig a C a d a stra a n o va re q u isiç ã o E fe tu a o re a g e n d a m e n to d a re q u isiçã o a n tig a Senão m sg (“n ã o é p o ssíve l ca d a stra r a re q u is içã o !”) Senão m s g (“n ã o é p o ss íve l ca d a s tra r a re q u isiçã o !”) S e (a p e n a s o h o rá rio d e o b se rva çã o fo i e s p e cifica d o ) e n tã o S e (já h o u v e r u m a re q u is içã o a g e n d a d a p a ra o m e sm o a stro n o h o rá rio e sp e cific a d o ) e n tã o A g ru p a re q u is içõ e s Senão B u sca d a ta d isp o n ív e l, e fe tu a n d o a re d u çã o a o d ia , a té e n c o n tra r u m a d a ta e m q u e n o h o rá rio e sp e c ifica d o o a s tro e ste ja o n o m ín im o a 2 0 d o h o rizo n te S e (fo r p e rm itid a a o b se rv a çã o ) e n tã o C a d a s tra a n o va re q u isiçã o S enão m sg (“n ã o é p o ssíve l c a d a stra r a re q u isiç ã o !”) S e (n e m a d a ta e n e m o h o rá rio fo ra m e sp e c ific a d o s) e n tã o S e (já h o u v e r u m a re q u is içã o a g e n d a d a p a ra o a s tro d e s e ja d o ) e n tã o A g ru p a re q u is içõ e s Senão B u sca d a ta e h o rá rio d isp o n íve is, e fe tu a n d o a re d u ç ã o a o d ia , a té e n co n tra r u m a d a ta e u m h o rá rio e m q u e o a stro e s te ja o n o m ín im o a 2 0 d o h o rizo n te S e (fo r p e rm itid a a o b se rv a çã o ) e n tã o C a d a s tra a n o va re q u isiçã o S enão m sg (“n ã o é p o ssíve l c a d a stra r a re q u isiç ã o ”) Figura 35. Passos que o sistema segue para a validação da requisição O diagrama de seqüência da execução é ilustrado na Figura 36. O início da execução parte do Temporizador, que aciona o Escalonador na data e hora da execução. O escalonador verifica 52 qual será a requisição a ser atendida e envia o sinal ao Executor. O Executor verifica no Meteorologista as condições presentes, se estiverem dentro do limite aceitável pelo sistema, ele dá continuidade a execução, caso contrário, reagenda a requisição e envia uma mensagem ao usuário. Se as condições estiverem de acordo, a requisição é executada e o Escalonador atualizado. O executor envia um sinal ao Sistema Embarcado do observatório que faz a captura da imagem. Esta imagem é enviada ao usuário solicitante. s d Ex e c uç ã o U s u á rio G e re n c ia d o r T e m p o riza d o r E s ca lo n a d o r E xe c u to r Me te re o lo g is ta [s e te m p o = te m p o d e e xe cu ta r]: Ac o rd a r! E xe c u te Ve rific a c o n d iç õ e s m e te o ro ló g ica s re to rn a [s e c o n ciç õ e s m e te o ro ló g ic a s n ã o p e rm itid a s ]: R e e s ca lo n a [s e re q u is iç ã o re a g e n d a d a ]: a le rta d e re e s c a lo n a m e n to E -m a il c o m d a ta d o re a g e n d a m e n to [s e c o n d içõ e s m e te o ro ló g ic a s p e rm itid a s ]: E xe cu ta Ativa d rive r d o s is te m a e m b a rca d o p a ra in te ra g ir co m a c ú p u la e o te le s c ó p io R e to rn a im a g e m o b tid a Atu a liza te m p o d e a co rd a r [s e e xe cu çã o o k ]: re to rn a im a g e m E -m a il c o m im a g e m (fro m S o lic ita R e q u isiçã o ) (fro m S o lic ita R e q u isiç ã o ) Figura 36. Diagrama de seqüência da execução da requisição 3.1.4.5.Diagrama de Implantação 53 SE O diagrama de implantação descreve a estrutura física do projeto. A Figura 37 ilustra esta estrutura: vários PCs conectados ao servidor, ou seja, usuários acessando o sistema para solicitar requisições de observações, o servidor ligado a uma estação meteorológica (para as verificações) e ligado também ao driver do sistema embarcado que é responsável pela interação com a parte mecânica do observatório (abertura da cúpula, movimentação do telescópio, etc.) dd Dia gr a m a de Im pla nta ç ã o P C Re m oto P C Re m o to ... P C S e r vido r Es ta ç ã o M e te o r ológic a S is te m a Em b a r c a do O bs e r va tór io Figura 37. Diagrama de implantação 54 ... P C Re m o to 3.1.5. Banco de Dados O banco de dados utilizado no desenvolvimento deste projeto foi o Paraddox (DEITEL, 2001). Ele interage muito bem com C++ (linguagem de programação utilizada no desenvolvimento deste projeto) e possui gerenciamento simplificado. A Figura 38 mostra o modelo lógico do banco de dados. c d m a ia r a + n» n» n» n» n» n» n» C o d U s u a rio : Nom e: C o d E n d e re c o : C o d In s ti tu i c a o : E m a il : Senha: C a rg o : « P K » P K _ T a b U s u a r io s () *P K « co lu m « co lu m « co lu m « co lu m « co lu m « co lu m « co lu m « co lu m « co lu m + + « P K » P K _ T a b C a rg o s ( ) + C o d R e q u is ica o : P rio r id a d e In i c i a l: As c e n c a o : D e clin a c a o : D a ta In i c i a l: D a ta F i n a l: D a ta E s p e c ifi c a : H o ra ri o In i c i a l: H o ra ri o F in a l : H o ra ri o E s p e c i fi c o : T e m p o E xp o s i c a o : D i a s C o n s e c u tivo s : Ve ze s R e a g e n d a d a : D a ta R e q u i s ic a o : H o ra ri o R e q u i s i c a o : D a ta Ag e n d a d a : H o ra ri o Ag e n d a d o : C o d S ta tu s : C o d F il tro : P rio r id a d e Atu a l : Id C o n s e c u ti va : C o d As tro : « P K » P K _ T a b R e q u i s ic o e s () * P K « c o lu m n » S i g la : « c o lu m n » N o m e : + « P K » P K _ T a b E s ta d o s () n» n» n» n» n» C o d In s ti tu ic a o : N o m e In s ti tu ic a o : T i p o In s ti tu i c a o : C o d E n d e re c o : P ri o ri d a d e : T a b T ip o In s t itu ic o e s * P K « c o l u m n » C o d T i p o In s ti tu ic a o : « c o l u m n » T i p o In s titu ic a o : + « P K » P K _ T a b T ip o In s ti tu i c o e s () « P K » P K _ T a b In s ti tu i c o e s () T a b T ip o Filtr o s T a b R e q u is ic o e s n» n» n» n» n» n» n» n» n» n» n» n» n» n» n» n» n» n» n» n» n» n» C o d E n d e re c o : Rua: N u m e ro : C o m p le m e n to : C EP: B a i rro : C id a d e : C o d E s ta d o : T e le fo n e : T a b In s titu ic o e s * P K « c o lu m « c o lu m « c o lu m « c o lu m « c o lu m + * P K « co lu m « co lu m « co lu m « co lu m « co lu m « co lu m « co lu m « co lu m « co lu m « co lu m « co lu m « co lu m « co lu m « co lu m « co lu m « co lu m « co lu m « co lu m « co lu m « co lu m « co lu m « co lu m n» n» n» n» n» n» n» n» n» « P K » P K _ T a b E n d e re c o s () Ta bCa r gos * P K « c o l u m n » C o d C a rg o : « c o l u m n » C a rg o : « c o l u m n » D i fP ri o ri d a d e : T a b Es t a d o s T a b En d e r e c o s T a b U s u a r io s * P K « co lu m « co lu m « co lu m « co lu m « co lu m « co lu m « co lu m * P K « c o l u m n » C o d F i ltro : « c o l u m n » F i ltro : + « P K » P K _ T a b T ip o F i ltro s () T a b T ip o S ta tu s * P K « c o lu m n » C o d S ta tu s : « c o lu m n » N o m e : + « P K » P K _ T a b T i p o S ta tu s () T a b A s tr o s * P K « c o lu m « c o lu m « c o lu m « c o lu m « c o lu m + n» n» n» n» n» C o d As tro : N om e: As c e n c a o : D e c l in a c a o : C o d T i p o As tro : T a b T ip o A s tr o * P K « c o l u m n » C o d T i p o As tro : « c o l u m n » T ip o As tr o : + « P K » P K _ T a b T i p o As tro () « P K » P K _ T a b As tro s () T a b M e te o r o lo g ic o * P K « c o l u m n » C o d U s u a rio : * P K « c o l u m n » C o d R e q u is i c a o : « c o l u m n » Id C o n s e c : * P K « c o lu m « c o lu m « c o lu m « c o lu m « c o lu m + + T a b R e q u is ic a o U s u a r io « P K » P K _ T a b R e q u i s i c a o U s u a ri o (, ) n» n» n» n» n» D a ta : H o r a r io : Ve n to : T e m p e ra tu ra : U m id a d e : « P K » P K _ T a b M e te o ro l o g ic o ( ) Figura 38. Modelagem do banco de dados 55 T a b H o r a r io s * P K « c o lu m n » D a ta In i c i o : « c o lu m n » H o r a r io In ic io : « c o lu m n » H o r a r io F i m : + « P K » P K _ T a b H o ra ri o s () 3.2. IMPLEMENTAÇÃO Nesta sessão será apresentada a forma com que o sistema foi implementado, incluindo os métodos e os componentes que foram utilizados. Serão também apresentados os procedimentos realizados para validação e teste do sistema. 3.2.1. Acesso O sistema desenvolvido possui dois processos independentes. O primeiro consiste de um gerador de interface Web para interação com os usuários remotos. O segundo consiste do núcleo do sistema, que é responsável por realizar as tarefas relacionadas à execução das requisições dos usuários. A comunicação entre os dois processos é feita através de sockets. O acesso ao sistema dá-se através da internet, digitando uma URL (Universal Resource Locator) como, por exemplo, http://www.observatorio.univali.br/cgi-bin/astraWeb.exe/index. Através de mecanismos de roteamento da internet, a primeira parte da URL (http://www.observatorio.univali.br) é avaliada e a solicitação HTTP (Get, Post, Put) chega à máquina destino, onde um servidor Web aguarda conexões no port 80 (padrão do protocolo HTTP). O servidor Web (Apache, por exemplo) recebe a solicitação e invoca o programa especificado na segunda parte da URL (/cgi-bin/astraWeb.exe). Este programa, denominado aqui de AstraWeb, tem sua execução iniciada a cada nova solicitação HTTP e recebe a última parte da URL, denominada caminho ou path (/index). Com base nesse caminho, esse programa deve tomar as ações necessárias e gerar a resposta adequada à solicitação. Como o programa invocado pelo servidor Web terá múltiplas instâncias em execução, e sendo isso indesejável ao núcleo do sistema Astra, o programa AstraWeb é apenas um interceptador de solicitações Web, e sempre que necessário comunica-se com outro processo independente, o AstraKernel, que compreende o núcleo do sistema Astra. Deste modo, pode haver inúmeras instâncias do AstraWeb em execução, mas uma única instância do AstraKernel. Outro motivo para ter-se dois programas independentes é que o núcleo “acorda” em instantes específicos para executar as requisições já cadastradas ou para armazenar as condições meteorológicas atuais, e não pode depender da existência de solicitações HTTP para executar. Embora o sistema deva executar de maneira independente das solicitações HTTP, ele também deve ser capaz de atendê-las rapidamente, uma vez que há um timeout associado às 56 solicitações. Uma solução seria fazer uma varredura periódica. Entretanto, além de imprecisa, essa solução é ineficiente e teria um alto custo de desempenho. Assim, optou-se pela separação do atendimento às solicitações Web e geração das páginas HTML de resposta (responsabilidade do AstraWeb) do processamento e escalonamento das requisições de observação astronômica (responsabilidade do AstraKernel). A comunicação entre esses programas é assíncrona e é realizada através de sockets TCP. O AstraWeb reside na pasta cgi-bin do servidor Web da máquina (normalmente c:\apache\cgi-bin) e é invocado a cada nova solicitação HTTP. Basicamente, ele transmite a solicitação via socket TCP para o núcleo do Astra que realiza o tratamento e envia informações de retorno de volta ao AstraWeb através da mesma conexão TCP. Deste modo, uma única instância do AstraKernel permanece sempre executando. Para evitar a verificação periódica de requisições TCP, o núcleo do Astra cria um socket servidor (port 5000) que é ativado apenas quando há uma nova solicitação. Se houver muitos usuários conectados à internet gerando solicitações ao sistema, pode ser inaceitável haver um único núcleo atendendo tais requisições. Portanto, assim como em implementações normais de socket servidores, cada conexão aceita pelo núcleo do Astra cria uma nova thread específica para atendê-la. 3.2.1.1. Testes e validações Os testes ao acesso ao sistema Astra envolveram duas etapas distintas: (i) Teste de execução do AstraWeb a partir de um bronwser e a geração de uma página HTML de resposta; e (ii) comunicação via socket TCP entre os programas AstraWeb e o AstraKernel. Para a realização do primeiro teste, iniciou-se o servidor Apache na máquina que continha a aplicação AstraWeb. Com o servidor executando, invocou-se a aplicação através de navegadores Internet Explorer, tanto da própria máquina quanto de outras máquinas conectadas à internet. Em todos os casos obtinha-se, na janela do navegador utilizado, as páginas HTML geradas pelo AstraWeb. A Figura 39 apresenta uma parte da tela do sistema onde pode-se ver o resultado de uma solicitação no navegador, com destaque à URL digitada. 57 Figura 39. Teste de execução do AstraWeb Em relação ao segundo teste, foram criadas duas aplicação (cliente e servidor) que se comunicam via socket, No exemplo abaixo, o cliente envia uma mensagem ao servidor, que identifica o cliente e recebe a mensagem, conforme Figura 40. 58 Figura 40. Comunicação via socket TCP entre os programas AstraWeb e o AstraKernel 3.2.2. AstraWeb Para o desenvolvimento desta aplicação foi utilizado um componente TWebModule, que é composto por vários componentes TActions. Em geral, existe um action para cada caminho ou página que pode ser acessada pela aplicação. O action é responsável por montar a página Web de resposta para o solicitante. Para facilitar a criação da página Web de resposta, cada action tem associado a si um componente TPageProducer que monta páginas Web a partir de um template, substituindo tags genéricas, não reconhecidas pelo HTTP. Quando a solicitação do usuário tem como resposta uma página Web simples, ou seja, ainda sem interação com banco de dados e classes do sistema (exemplo de /index), o action correspondente simplesmente monta a página com base no PageProducer e envia a página como resposta. Entretando, quando é necessário a interação com o restante do sistema Astra (por exemplo na submissão de requisição de observação ou validação do login), o action correspondente cria um socket cliente e estabelece uma conexão TCP com o núcleo do sistema (AtraKernel), que então trata adequadamente a requisição e devolve informações que permite ao PageProducer montar a página que será mostrada ao usuário. 59 3.2.3. Núcleo do Sistema Esta aplicação permanece sempre ativa, ou seja, carregada na memória da máquina, mas estará efetivamente em execução em três situações: (i) ao receber uma conexão por socket TCP iniciada pelo AstraWeb; (ii) quando chegar o momento de atender uma requisição de observação astronômica, e (iii) quando chegar o momento de periodicamente armazenar informações meteorológicas no banco de dados. No primeiro caso em que o sistema estará em execução, sempre que a aplicação Web solicitar alguma validação ou inclusão de registro, o núcleo do Astra executará essas tarefas, pois o acesso as tabelas são realizadas apenas pelo núcleo. Quando o sistema solicitar a validação de uma requisição, por exemplo, o sistema faz as verificações astronômicas, como mostra a Figura 41 onde a classe Astrônomo faz a redução ao dia. void __fastcall ClAstronomo::Faca_Reducao_ao_Dia(TDateTime dataCoordenadas, double ascencao, double declinacao, TDateTime dataNova, double *ascencaoNova, double *declinacaoNova) { } float T,pa,pd,n,m,ar,dec; T = (double)(dataCoordenadas - dataNova)/100; //estrela.ano=ano com 4 dígito - ano atual m = 3.07496 + (0.00186 *T); n = 1.33622 - (0.00057 *T); ar = (((ascencao * 15) * pi)/180); //estrela.ar = ascensão reta antigo dec = ((declinacao * pi)/180); //estrela.dec = declinação antigo pa = (m + ((n * sin(ar) * tan(dec)))); pd = (n * cos(ar)); *ascencaoNova = ascencao + (pa/3600); //estrela.ar = nova *declinacaoNova = declinacao + (pd*15/3600); //estrela.dec = nova Figura 41. Implementação parcial da Classe Astrônomo No segundo caso em que o sistema estará em execução, cada requisição cadastrada no sistema tem um momento exato para ser executada. Para isso, o sistema possui a classe Temporizador, que é programado para “acordar” o escalonador no tempo em que a próxima requisição deve ser executada, sendo atualizado sempre que uma nova requisição for cadastra (pois ela pode ser a próxima a ser executada) ou quando uma requisição for executada. Uma vez chego o momento da execução, o Temporizador invoca o Escalonador (que tem todos os dados da requisição) e este invoca o Executor. O Executor tem a responsabilidade de verificar as condições meteorológicas (invocando o Meteorologista) e executar a requisição, caso as condições 60 Meteorológicas estejam de acordo com o previsto pelo sistema, ou reagenda a requisição, caso algo não esteja de acordo. A Figura 42 mostra parte do código fonte da classe da estação meteorológica, na figura está a implementação da busca da temperatura interna e externa, esta classe ainda faz a leitura da umidade e do vento. __fastcall ClDriverEstacaoMet::ClDriverEstacaoMet() { hardwareSimulator = new ClHardwareSimulator(); for (int id = 0; id < 4; id++) { hardwareSimulator->sensor_init(id); } } float __fastcall ClDriverEstacaoMet::GetTempInterna() { float value; hardwareSimulator->sensor_read(1, 0, &value); return value; } float __fastcall ClDriverEstacaoMet::GetTempExterna() { float value; hardwareSimulator->sensor_read(0, 0, &value); return value; } Figura 42. Implementação da Classe do Driver da Estação Meteorológica O núcleo do sistema também estará em execução quando chegar o momento do sistema gravar diariamente as condições meteorológicas no banco de dados, para que se possa ter estatísticas do tempo ao longo dos dias. Desta forma, tem-se um Temporizador exclusivo para esta ação, ele usa a função Timer que tem como finalidade ser acordado em determinado momento. De acordo com o tempo cadastrado no sistema, o Temporizador acorda e executa a função de gravar os dados na tabela. A Figura 43 mostra a implementação da classe Meteorologista fazendo uso do Timer. 61 __fastcall ClMeteorologista::ClMeteorologista(){ meuDriverEstacao = new ClDriverEstacaoMet(); TabMeteorologicos = new ClTabMeteorologicos(); Timer = new TTimer(NULL); Timer->Enabled = false; Timer->OnTimer = _TimerTimer; } void __fastcall ClMeteorologista::_TimerTimer(TObject *Sender) { Timer->Enabled = false; _GraveCondicoesMeteorologicas(); _EsperePor(aD, aH, aMin, aS); } void __fastcall ClMeteorologista::_EsperePor(int d, int h, int min, int s) { aFaltam = s*1e3 + min*60*1e3 + h*3600*1e3 + d*24*3600*1e3; Timer->Interval = aFaltam; Timer->Enabled = true; } void __fastcall ClMeteorologista::GraveCondicoesCada(int d, int h, int min, int s) { aD = d; aH = h; aMin = min; aS = s; _EsperePor(aD, aH, aMin, aS); } void __fastcall ClMeteorologista::_GraveCondicoesMeteorologicas() { sRegistroMeteorologico reg; reg.temperatura = meuDriverEstacao->GetTempExterna(); reg.umidade = meuDriverEstacao->GetUmidade(); reg.vento = meuDriverEstacao->GetVento(); reg.data = Now().CurrentDate(); reg.horario = Now().CurrentTime(); TabMeteorologicos->IncluiRegistro(reg); } Figura 43. Implementação da Classe Meteorologista 3.2.3.1. Testes e validações Os testes do núcleo do Astra foram realizados fazendo simulações com os drivers, gerando valores aleatórios de condições meteorológicas. A interação com a parte física do observatório, também foi simulada, gerando mensagens para informar o administrador quando a cúpula estivesse aberta ou fechada. Desta forma, a requisição era submetida ao sistema, os drivers simulados e as consistências realizadas. Na Figura 44 é mostrada a janela em que foram realizados os testes dos drivers, da temporização, envio de e-mail ao usuário e simulação de visualização da imagem do telescópio. 62 Figura 44. Janela de teste do núcleo do Astra 3.2.4. Interface As próximas figuras mostram as três telas do sistema: Acesso ao Sistema, Cadastro do Usuário e Solicitação de uma Requisição. 63 Figura 45. Tela Acesso ao Sistema 64 Figura 46. Tela Cadastro do Usuário 65 Figura 47. Tela Solicitação de Requisição 66 3.2.5. Integração do Sistema A integração entre o AstraWeb e o AstraKernel estão em desenvolvimentos e serão apresentados à banca no dia da defesa deste trabalho, sendo desta forma, a descrição do desenvolvimento acrescentada ao texto para versão final. [FIM DE SEÇÃO. Não remova esta quebra de seção] 67 4. CONCLUSÃO Este trabalho apresentou a descrição geral de um sistema Web para gerenciamento de acesso remoto a um observatório astronômico. Os objetivos propostos inicialmente para este trabalho incluíam o desenvolvimento para Web, e o recebimento, análise, escalonamento e atendimento de requisições remotas de observações astronômicas. Pelo que foi apresentado ao longo do texto e pelos resultados obtidos com o sistema, conclui-se que o mesmo atendeu completamente os objetivos propostos, pois é capaz de realizar todas as ações previstas de modo satisfatório, podendo efetivamente ser utilizado no controle de um observatório astronômico. Entre os benefícios conseguidos com o desenvolvimento deste sistema estão a divulgação da Universidade do Vale do Itajaí, dos grupos de pesquisa associados (Grupo de Astrofísica e Grupo de Concepção de Sistemas Embarcados e Distribuídos), e da astronomia em geral, bem como a disponibilidade de uso remoto do futuro observatório, maximizando sua utilização, e a integração com outros projetos de pesquisa, como o AstroFácil, que realiza a automação de telescópios de pequeno porte. Além disso, este projeto oferece subsídios para a realização de outros projetos de pesquisa e trabalhos de conclusão de curso necessários ao funcionamento completo do observatório remoto, como mecanismos de automação da cúpula. Apesar das vantagens do sistema, o mesmo também apresenta algumas limitações. Uma deles refere-se ao fato de ter sido implementados cálculos para determinação da posição de estrelas e outros objetos distantes, mas não os cálculos para determinação da posição de planetas de nosso sistema solar, que possuem movimentos diferenciados. Deste modo, pode-se solicitar a observação de uma estrela distante, mas não de Marte, por exemplo. Outra limitação relaciona-se à necessidade do sistema estar instalado em servidor Windows, devido às ferramentas de desenvolvimento utilizadas. Essa restrição é considerada uma desvantagem pelo fato do Linux ser comumente utilizado como interface a telescópios profissionais. Várias dificuldades foram encontradas durante o desenvolvimento deste trabalho, sendo que a principal delas foi como fazer a integração da interface web com o núcleo do sistema e com os drivers dos sistemas embarcados. Inicialmente a proposta foi a utilização de páginas desenvolvidas em PHP com conexão via pipes com o núcleo, mas esta solução não se mostrou possível de implementar em tempo hábil. Estudou-se então outras soluções, que foi o uso de sockets, com bons resultados. Para tal, fez-se necessário o desenvolvimento de ambas aplicações em C Builder e a utilização de threads, que demandou vários estudos adicionais. Ainda em relação ao desenvolvimento do sistema, possíveis melhorias na funcionalidade do sistema podem ser incluídas em trabalhos futuros, sendo que algumas foram identificadas durante o desenvolvimento deste trabalho e são apresentadas a seguir. Embora o escalonamento implementado utilize bons algoritmos (prioridade, EDF, SSTF), diferentes abordagens ainda podem ser testadas em trabalhos futuros, dependendo do objetivo final (maximizar utilização, minimizar movimento do telescópio, etc). Embora não tenha feito parte do escopo deste trabalho, a utilização remota de um observatório astronômico demandará administração e manutenção, e essas tarefas devem estar integradas ao sistema desenvolvido, pois é necessário que o administrador gerencie usuários e requisições e também agende períodos de inatividade ao observatório para manutenção. Outra sugestão para futuros trabalhos refere-se à implementação dos mecanismos físicos de automação da cúpula do observatório, da estação meteorológica e seus sensores, e dos drivers correspondentes. Outras sugestões incluem trabalhos relacionados ao tratamento digital das imagens obtidas, que promoverão grande importância ao sistema. Em relação à divulgação do trabalho científico, foram submetidos quatro artigos/resumos a eventos nacionais e internacionais, sendo que três dessas submissões foram aceitas. O desenvolvimento deste trabalho já foi divulgado no XXXI Reunião Nacional da Sociedade Astronômica Brasileira (SAB), em São Paulo, no X Simpósio de Informática e V Mostra de Software Acadêmico (SIMS), em Uruguaiana, Rio Grande do Sul, e foi também apresentado no 4th International Information and Telecommunication Technologies Symposium (I2TS), de 14 a 16 de dezembro deste ano em Florianópolis. Por fim, o desenvolvimento desse trabalho deve beneficiar estudantes, professores e amantes da astronomia, por disponibilizar o acesso a um recurso sofisticado e caro que provavelmente não se teria acesso de outro modo e ainda possibilitar a execução de novos projetos que venham a aumentar mais a sua utilidade. 69 REFERÊNCIAS BIBLIOGRÁFICAS BOCZKO, Roberto. Conceitos de astronomia. São Paulo: E. Blücher, São Paulo, 1984. BUTAZZO, Giorgio; SENSINI, Fabrizio. Hard Real Time Computing Systems. Boston, 1997. 373 p. ISBN: CANCIAN, Rafael Luiz. Avaliação de Desempenho de Algoritmos de Escalonamento e Tempo Real para o Ambiente de Multicomputador CRUX. 2001. 174 p. Dissertação de Mestrado em Ciência da Computação – Universidade Federal de Santa Catarina, Florianópolis, 2000. CARA – Center for Astrophysical Resourse in Antarctica, 1995 Disponível em: <http://astro.uchicago.edu> Acesso em 01 mar 2005. DEITEL, H. M.; DEITEL, P. J.. C++ Como Programar. 3. ed. Porto Alegre, 2001. 1098 p. ISBN: 8573077409 ELECTRO OPTIC SYSTEMS. Electro Optic Systems. 2005 Disponível em <http://www.eosaus.com/dowloads/ROCS.pdf, 2002> Acesso em 01 mar 2005 FURLAN, José Davi. Modelagem de objetos através da UML. Makron Books. 1998. 329 p. ISBN: MIKE & LYNN RICE. New México Skies. Disponível em: <http://www.nmskies.com/weather.html>. Acesso em: 15 mar. 2005. ROCK BOTTOM OBSERVATORY. Robotic observatory project. 2003. Disponível em: <http://www.observingstars.com/robotic-observatory-project.htm>. Acesso em: 01 mar. 2005. ROSA, Roberto. Astronomia elementar. 2. ed. Uberlândia: Edufu, 1994. 161 p. ISBN: SANTIAGO, Basílio Astronomia Geodésica. Porto Alegre: UFRGS, 2001. Disponível em <http://www.if.ufrgs.br/~santiago/lectures/fis2005/textos/index.htm>. Acesso em 22 abr 2005. SILBERCHATZ, A.; GALVIN, P.B. Sistemas Operacionais Conceitos. 5. ed. Prentice Hall, 2000. 901 p. ISBN: 0471365084 SILVA, Marcos Roberto. Sistema embarcado para controle de telescópios. 2003. 112 p. Trabalho de Conclusão de Curso (Graduação em Ciência da Computação)–Curso de Ciência da Computação, Universidade do Vale do Itajaí, Itajaí, 2003. TÁRSIA, Rodrigo Dias. Astronomia fundamental. Belo Horizonte: UFMG, 1993. 248 p. ISBN: 8570410549 WERNECK, Lucas S.; NADER, Rundsthen V.; CAMPOS, José Adolfo S. de. O telescópio remoto do Observatório do Valongo. In: MARTIN, Vera A. Fernandes. Boletim da Sociedade Astronômica Brasileira. Rio de Janeiro: UFRJ,2004. p. 189-189. GLOSSÁRIO Azimute Constelação Deadline Equador celeste Equinócio Meridiano celeste Path Preempção Sistema de tempo real Soquete Thread Trapera Zênite coordenada que define a posição de um astro agrupamento aparente de estrelas tempo máximo em que um processo pode terminar sua execução. projeção do equador terrestre na esfera celeste cada uma das duas épocas em que o Sol passa pelo equador projeção do plano do meridiano terrestre na esfera celeste caminho capacidade do processador interromper um processo em execução sistema no qual a corretude depende não apenas dos resultados lógicos da computação, mas também do tempo no qual os resultados são produzidos interface para operações de entrada e saída fluxo de execução componente da cúpula que se abre para permitir a saída do telescópio ponto bem acima da cabeça do observador [FIM DE SEÇÃO. Não remova esta quebra de seção] APÊNDICE I – DIAGRAMAS DE SEQUENCIA Conforme citado na modelagem do projeto, neste apêndice serão mostrados os diagramas de seqüência de todos os casos de uso. Diagrama dos casos de uso do administrador: s d Ava lia r c a da s tr o do us uá r io U s u á rio S is te m a Ad m in is tra d o r P re e n ch e ca d a s tro S u b m e te ca d a s tro C a d a s tro p a ra a va lia çã o Ava lia çã o d o ca d a s tro [s e a va lia çã o = a p ro va d a ]: G ra va c a d a s tro co m o a tivo [s e a va lia ç ã o = re cu s a d o ]: Avis o d e ca d a s tro re cu s a d o [S e a va lia çã o = a p ro va d o ]: E -m a il p a ra c o n firm a çã o d o ca d a s tro R e to rn a c o n fira m ç ã o Figura 48. Diagrama de seqüência de avaliação do cadastro do usuário s d Ex c luir us uá r ios Ad m in is tra d o r S is te m a Ace s s a c a d a s tro d o u s u á rio E xclu i ca d a s tro "C lie n te e xclu íd o " Figura 49. Diagrama de seqüência da exclusão de usuários s d Fa ze r login Ad m in is tra d o r S is te m a E fe tu a lo g in [s e va lid a çã o re cu s a d a ]: "L o g in in vá lid o " [s e va lid a ç ã o a p ro va d a ]: Ace s s o a o s is te m a Figura 50. Diagrama de seqüência do login do administrador 73 s d Fa ze r m a nu te nç ã o do obs e r va tór io Ad m in is tra d o r S is te m a S is te m a e m b a rca d o O b s e rva tó rio Ace s s a s is te m a p a ra m a n u te n çã o d o o b s e rva tó rio C o m u n ica -s e co m o s is te m a e m b a rca d o R e a liza m a n u te n çã o n o o b s e rva tó rio Figura 51. Diagrama de seqüência da manutenção do observatório s d Lis ta r r e quis iç õe s pe nd e nte s Ad m in is tra d o r S is te m a L is ta r re q u is iç õ e s p e n d e n te s L is ta d e re q u is içõ e s p e n d e n te s Figura 52. Diagrama de seqüência de listar requisições pendentes 74 s d M odific a r a ge nd a m e n to Ad m in is tra d o r G e re n c ia d o r E s ca lo n a d o r T e m p o riza d o r Ace s s a re q u is iç ã o Alte ra d a ta d e a g e n d a m e n to Ve rifica ch o q u e d e d a ta e h o ra co m o u tra re q u is iç ã o [s e h o u ve r ch o q u e co m o u tra re q u is içã o ]: Já e xis te re q u is içã o p a ra e s ta d a ta /h o ra [s e n ã o h o u ve r ch o q u e co m o u tra re q u is içã o ]: Alte ra d a ta [s e d a ta a lte ra d a ]: Atu a liza te m p o riza d o r D a ta a lte ra d a Figura 53. Diagrama de seqüência de modificação de agendamento s d V e r c a da s tr o do s us uá r ios Ad m in is tra d o r S is te m a Ve r ca d a s tro d o s u s u á rio s R e to rn a ca d a s tro s Figura 54. Diagrama de seqüência de visualização do cadastro dos usuários 75 s d V e r utiliza ç ã o do te le s c ópio Ad m in is tra d o r S is te m a S o licita lis ta g e m d e e xe c u çõ e s Mo s tra lis ta g e m d e e xcu çõ e s Figura 55. Diagrama de seqüência de visualização da utilização do telescópio s d Login U s u á rio S is te m a Fa z lo g in [s e va lid a çã o re p ro va d a ]: lo g in in vá lid o [s e va lid a lç ã o a p ro va d a ]: Ace s s o a o s is te m a Figura 56. Diagrama de seqüência de login 76 s d V e r c ondiç õe s m e te or ológic a s U s u á rio S is te m a Me te o ro lo g is ta Ve r c o n d içõ e s m e te o ro ló g ica s Ac e s s a co n d içõ e m e te o ro ló g ica s C o n d içõ e s m e te o ro ló g ica s Figura 57. Diagrama de seqüência de visualização de condições meteorológicas 77 APENDICE II – CRONOGRAMA DO TCCII Etapa 3: Desenvolvimento. Esta etapa visa transformar o modelo conceitual da etapa de modelagem num sistema real, a solução proposta em si, que será posteriormente testada e validada. Esta etapa compreende principalmente a codificação dos processos descritos no Projeto do sistema. Atividade Descrição 3.1 Recursos necessários Pré-requisitos Metodologia Indicador físico Duração Implementar o software do Sistema Web para gerenciamento de requisições de um observatório remoto Descrição do recurso Qtd. Microcomputador PC 01 Atividade 2.2 A implementação do sistema de escalonamento das requisições será feita usando a linguagem definida no tem 1.5, seguindo estritamente a análise já realizada. O sistema deve possuir, a princípio, módulos de verificação de consistência, junção, escalonamento e atendimento das requisições. Código-fonte 16 semanas Etapa 4: Validação. Esta etapa realiza experimentação e testes sobre a solução proposta, tentando falseá-la, com o objetivo de eliminar os erros existentes em sua modelagem ou desenvolvimento. Os testes incluem a modelagem, o software desenvolvido, e a real utilidade dessa solução. Atividade 4.1 Descrição Recursos necessários Pré-requisitos Metodologia Indicador físico Duração Realizar testes e validação com as rotinas astronômicas Descrição do recurso Microcomputador PC Qtd. 01 Atividade 3.1 Realizar testes com as rotinas astronômicas, utilizando comparações com outros softwares consagrados. Documentação dos testes realizados com relatos da comprovação do funcionamento do software, ou correção dos erros em caso de falhas apresentadas durante a simulação (o relatório servirá de referência para a revisão da modelagem e da implementação). 01 semana 78 Atividade 4.2 Descrição Recursos necessários Pré-requisitos Metodologia Indicador físico Duração Atividade 4.3 Descrição Recursos necessários Pré-requisitos Metodologia Indicador físico Duração Atividade 4.4 Descrição Recursos necessários Pré-requisitos Metodologia Indicador físico Duração Realizar testes e validação das consistências das requisições Descrição do recurso Qtd. Microcomputador PC 01 Atividade 3.1 As consistências devem verificar principalmente a existência do astro selecionado, a consistência das coordenadas, a possibilidade de movimentação do telescópio para a posição determinada e a disponibilidade do telescópio (sobreposição de requisições). Documentação dos testes realizados com relatos da comprovação do funcionamento do software, ou correção dos erros em caso de falhas . 01 semana Realizar testes e validação com as rotinas de escalonamento Descrição do recurso Qtd. Microcomputador PC 01 Atividade 3.1 Fazer testes com as rotinas de escalonamento verificando o agendamento correto das requisições. Documentação dos testes realizados com relatos da comprovação do funcionamento do software, ou correção dos erros em caso de . 01 semana Realizar testes na execução do atendimento das requisições Descrição do recurso Microcomputador PC Qtd. 01 Atividade 3.1 Para o atendimento das requisições, é necessário inicialmente verificar as condições meteorológicas (umidade) do local. Se a umidade estiver acima de um valor critico a requisição deve ser reagendada. Em caso contrário, a cúpula deve ser movimentada, a trapera deve ser aberta e o telescópio posicionado para o astro selecionado. Pode ser necessário acompanhar o astro por vários minutos ate a imagem ser obtida. Após obtida a imagem deve ser enviada por e-mail aos requisitantes. Documentação dos testes realizados com relatos da comprovação do funcionamento do software, ou correção dos erros em caso de falhas apresentadas durante a simulação (o relatório servirá de referência para a revisão da modelagem e da implementação). 01 semana 79 Etapa 5: Documentação. Esta etapa visa deixar registrado todo o processo perminente à pesquisa científica, desde a descrição do problema, a proposta de uma nova solução (modelagem), o desenvolvimento dessa solução, os testes e validação da nova solução e os resultados final. A documentação deve permitir a outros pesquisadores reproduzir a nova solução e realizar os mesmos experimentos e testes feitos para sua validação. Além da documentação completa (o texto do TCC), será produzido um artigo científico para divulgação da pesquisa realizada. Atividade 5.1 Descrição Recursos necessários Pré-requisitos Metodologia Indicador físico Duração Atividade 5.2 Descrição Recursos necessários Pré-requisitos Metodologia Indicador físico Duração Redigir o texto do TCC I Descrição do recurso Microcomputador PC Qtd. 01 Nenhum A redação do TCC I se dará ao longo de todo o primeiro semestre, através das produções textuais que são os indicadores físicos das atividades já planejadas. O texto final deve estar conciso, claro, bem apresentado e com boa cadência. O objetivo do TCC I é definir bem o tema/problema de pesquisa, justificar sua importância e abrangência, fornecer o referencial teórico e apresentar as soluções já existentes para o problema exposto. Documento textual do TCC I a ser apresentado à banca avaliadora 04 meses Redigir o texto do TCC II Descrição do recurso Microcomputador PC Qtd. 01 Etapas de estudo (1) e modelagem (2) - faz parte das atividades 3.1 a 5.1 A redação do TCC II se dará ao longo de todo o segundo semestre, através das produções textuais que são os resultados das atividades já planejadas. O texto final deve estar conciso, claro, bem apresentado e com boa cadência. O objetivo do TCC II é documentar o desenvolvimento da solução proposta, de forma que possa ser reproduzida por outros pesquisadores, deve apresentar a verificação e validação do projeto, e finalmente os resultados alcançados e as conclusões tiradas. Documento textual do TCC II a ser apresentado à banca avaliadora 04 meses 80 Atividade 5.3 Descrição Recursos necessários Pré-requisitos Metodologia Indicador físico Duração Redigir um artigo científico Descrição do recurso Microcomputador PC com acesso à internet Atividade 4.1 A redação do artigo iniciará com a descrição sucinta do referencial teórico usado, do desenvolvimento, dos testes e das conclusões deste projeto. Para isso serão analisados artigo já publicados em eventos científicos de relevância na área de enquadramento deste projeto. Documento textual a ser submetido para publicação em evento técnico-científico 03 semanas Cronograma de desenvolvimento para o TCC II Atividade 08 / 05 Qtd. 01 09 / 05 10 / 05 11 / 05 12 / 05 3.1 4.1 4.2 4.3 4.4 5.2 5.3 81 ANEXO I – FORMULÁRIO DO MINIOBSERVATÓRIO ASTRONÔMICO 82 83 84 85 86 ANEXO II – RESUMO PUBLICADO NOS ANAIS DA REUNIÃO ANUAL DA SAB 87 ANEXO III – ARTIGO APRESENTADO NO SIMS 2005 (A SER PUBLICADO EM EDIÇÃO DA REVISTA HIFEN) ANEXO IV – ARTIGO PUBLICADO E ACEITO NO I2TS (A SER APRESENTADO EM DEZEMBRO/2005) 89
