INPE-12515-TDI/1000 SICDA UMA ARQUITETURA DE SOFTWARE DISTRIBUÍDA CONFIGURÁVEL E ADAPTÁVEL APLICADA ÀS VÁRIAS MISSÕES DE CONTROLE DE SATÉLITES Adriana Cursino Thomé Tese de Doutorado do Curso de Pós-Graduação em Computação Aplicada, orientada pelos Drs. Maurício Gonçalves Vieira Ferreira e João Bosco Schumann Cunha, aprovada em 30 de novembro de 2004. INPE São José dos Campos 2005
681.3.06 THOMÉ, A. C. SICSDA uma arquitetura de software distribuída configurável e adaptável aplicada às várias missões de controle de satélites / A. C. Thomé. São José dos Campos: INPE, 2004. 254p. (INPE-12515-TDI/1000). 1.Objetos distribuídos. 2.Flexibilidade. 3.Programação dinâmica. 4.Metadados. 5.Sistemas de informação adaptáveis. I.Título.
Aprovado (a) pela Banca Examinadora em cumprimento ao requisito exigido para obtenção do Título de Doutorado em Computação Aplicada Aluno (a): Adriana Cursino Thomé São José dos Campos, 30 de novembro de 2004
O rio atinge seus objetivos porque aprendeu a contornar obstáculos. Lao Tsé
Para meu esposo Thomé. Para meus filhos Ruan e Louise, tão adoravelmente à vontade nesta foto.
AGRADECIMENTOS Agradeço primeiramente a Deus, por mais uma oportunidade de estar aqui neste planeta, podendo, a cada dia, aprender a servir. Agradeço, também, a meus pais, pela preocupação e dedicação que sempre tiveram para comigo, e por toda ajuda que me deram para que eu me tornasse a pessoa que sou hoje. Agradeço, ainda, a meus familiares, que muito me ajudaram nos momentos difíceis, especialmente, auxiliando cuidar do Ruan e da Louise, nas tantas vezes que precisei me ausentar. Agradeço aos meus orientadores, Mauricio e Bosco, pelas idéias e sugestões que viabilizaram a realização deste trabalho. Gostaria de enviar, ainda, um agradecimento especial ao meu esposo Thomé e aos meus filhos Ruan e Louise, pela paciência que tiveram nestes quase cinco anos de dedicação à elaboração deste trabalho.
RESUMO Neste trabalho propõe-se uma arquitetura de software distribuída, configurável e adaptável aplicada às várias missões de controle de satélites, chamada SICSDA. O objetivo desta arquitetura é controlar mais de um satélite a partir de um mesmo conjunto de computadores, possibilitando a escolha de qual satélite deseja-se monitorar em um determinado instante. Outro fator importante é a necessidade de se ter uma arquitetura que permita que uma nova missão possa ser acomodada sem a necessidade de se criar um sistema específico para o satélite a ser lançado, fazendo com que o esforço necessário para adaptar o sistema a esse novo requisito seja minimizado. Além disso, deseja-se que os especialistas do domínio e que os desenvolvedores de software possam configurar, se necessário, atributos e regras do negócio para os satélites já lançados, e que possam também, acrescentar novos elementos ao domínio do problema sem a necessidade de programação extra. As funcionalidades oferecidas pela aplicação, como por exemplo, visualização de telemetrias e envio de telecomandos, poderão estar distribuídas em um domínio de rede pré-definido. O serviço de carga do sistema irá definir a localização dos objetos, o que significa que cada máquina na rede poderá ter uma visão diferente dos metadados armazenados no banco de dados. Uma visão, neste contexto, é a parte do modelo de objeto adaptável que será instanciada naquela máquina.
SICSDA AN ADAPTIVE CONFIGURABLE DISTRIBUTED SOFTWARE ARCHITECTURE APPLIED TO SATELLITE CONTROL MISSIONS ABSTRACT This work proposes an adaptive configurable distributed software architecture applied to satellite control missions called SICSDA. The main purpose of this architecture is to control more than one satellite through one set of computers, enabling the choice of each satellite to be monitored in any given period of time. This architecture allows a new mission to be settled without the need for the creation and addition of a specific software component for the satellite being launched, thus minimizing the effort needed to adapt the complete system to the new requirement. It also provides domain specialists and software developers with the capability to configure, if necessary, attributes and business rules to the satellites already launched, adding new elements to business domain without the need of extra codification. The functionalities offered by the application, for example, telemetry visualization and the sending of telecommands, can be distributed into a network pre-defined domain. The system charge distribution service will define the objects location, what means that each machine in the network will be able to have a different view of the metadata stored in the database. A view, in this context, is the piece of the adaptive object model that will be instantiated in that machine.
SUMÁRIO LISTA DE FIGURAS LISTA DE TABELAS Pág. CAPÍTULO 1 INTRODUÇÃO... 25 1.1 - Objetivos do Trabalho de Pesquisa... 28 1.2 Motivação do Trabalho de Pesquisa... 29 1.3 Metodologia de Desenvolvimento do Trabalho de Pesquisa... 32 1.4 Estrutura do Relatório... 34 CAPÍTULO 2 SISTEMA DE RASTREIO E CONTROLE DE SATÉLITES 37 2.1 O Centro de Controle de Satélites (CCS)... 38 2.2 As Estações Terrenas... 39 2.3 A Rede de Comunicação de Dados (RECDAS)... 40 2.4 O Software Aplicativo (SICS)... 41 2.4.1 Principais Funções do SICS... 41 2.4.2 Outras Arquiteturas Propostas para o SICS... 45 2.4.2.1 A Arquitetura SOFTBOARD... 45 2.4.2.2 A Arquitetura SICSD... 48 2.5 Projeto Multi-Missão do INPE... 51 CAPÍTULO 3 COMPUTAÇÁO BASEADA EM OBJETOS DISTRIBUÍDOS... 57 3.1 Plataforma J2EE... 63 3.1.1 As Camadas Físicas e Lógicas do J2EE... 64 3.1.2 Componentes e Contêineres... 65 3.1.2.1 Componentes EJ... 66
3.1.2.2 Componentes Web... 68 3.1.2.3 Clientes J2EE... 70 3.1.3 Serviços-Padrão J2EE... 72 3.1.4 A Persistência na Plataforma J2EE... 74 3.1.5 Aplicativos J2EE... 76 CAPÍTULO 4 MODELOS DE OBJETOS ADAPTÁVEIS... 79 4.1 O Pattern Type Object... 81 4.2 O Pattern Property... 82 4.3 O Pattern Accountability... 84 4.4 O Pattern Strategy... 86 4.5 O Pattern Composite... 88 4.6 O Pattern Rule Object... 90 4.7 O Pattern Interpreter... 92 4.8 O Pattern Builder... 94 4.9 Interpretadores de Metadados... 95 4.10 Arquitetura dos Modelos de Objetos Adaptáveis... 97 4.11 Projeto de Modelos de Objetos Adaptáveis... 99 4.12 Aspectos de Implementação... 99 4.12.1 Tomada de Modelos Persistentes... 99 4.12.2 Tornando os Modelos Persistentes... 99 4.12.3 Apresentando o Modelo para os Usuários... 101 4.12.4 Histórico de Regras e Dados... 102 4.13 Abordagem e Tecnologias Relacionadas aos Modelos de Objetos Adaptáveis... 102 CAPÍTULO 5 A ARQUITETURA SICSDA... 109 5.1 As Tecnologias Utilizadas para a Modelagem da Aplicação... 112 5.2 As Características da Arquitetura Proposta... 114
5.3 A Carga Inicial do Sistema... 121 5.4 A Carga dos Metadados do Sistema... 123 5.5 A Interação do Usuário com o Sistema... 123 5.6 A Escolha do Satélite a ser Monitorado... 124 5.7 O Atendimento da Solicitação de um Serviço... 125 5.8 A Configuração da Disposição dos Objetos... 126 5.9 A Configuração Inicial dos Metadados... 126 5.10 A Re-configuração dos Metadados... 127 5.11 O Funcionamento do Sistema... 128 5.12 O Controle de Versões... 131 CAPÍTULO 6 ESTRATÉGIAS PARA A IMPLANTAÇÃO DA ARQUITETURA PROPOSTA... 135 6.1 Conhecendo o Domínio do Problema... 136 6.2 Construindo o Modelo Independente de Plataforma do Sistema... 138 6.3 Construindo o Serviço de Configuração... 143 6.4 Construindo o Serviço de Usuário... 147 6.5 Construindo o Serviço de Persistência... 151 6.6 Construindo o Serviço de Carga... 158 6.7 Construindo o Serviço de Adaptação... 160 6.8 Integrando a Arquitetura SICSDA com o Simulador de Satélites... 163 CAPÍTULO 7 ESTRATÉGIAS PARA A CONSTRUÇÃO DO SERVIÇO DE ADAPTAÇÃO... 167 7.1 Construindo o Modelo Independente de Plataforma Genérico... 168 7.1.1 Aplicando o Pattern Type Object... 169 7.1.2 Aplicando o Pattern Property... 172 7.1.3 Obtendo a Arquitetura TypeSquare... 173 7.1.4 Aplicando o Pattern Accountability... 175
7.1.5 Aplicando o Pattern Strategy... 176 7.2 Projetando o Serviço de Adaptação... 180 7.2.1 Projetando o Metamodelo... 180 7.2.2 Projetando as Classes do Domínio... 181 7.2.3 Projetando os Objetos do Domínio... 183 7.2.4 Projetando as Propriedades... 185 7.2.5 Projetando os Relacionamentos... 187 7.2.6 Projetando as Regras de Negócio... 189 7.2.7 Acrescentando os Atributos de Relacionamento... 190 7.2.8 Representando as Classes como Enterprise Java Beans... 191 7.2.9 Construindo os Diagramas de Seqüência... 193 7.3 Implementando o Serviço de Adaptação... 197 CAPÍTULO 8 CONSTRUÇÃO DO PROTÓTIPO... 201 8.1 As Ferramentas Adotadas para a Implementação do Protótipo... 201 8.1.1 A Plataforma de Programação Java... 201 8.1.2 O Gerenciador de Banco de Dados Caché... 202 8.1.3 O Ambiente de Desenvolvimento JBuilder... 204 8.1.4 O Servidor de Aplicações JBoss... 204 8.2 O Ambiente de Testes... 205 8.3 Implementando o Protótipo... 205 8.4 Exemplos de Realização de Casos de Uso... 218 8.4.1 Criando um Novo Tipo de Mensagem... 218 8.4.2 Visualizando Telemetrias... 223 CAPÍTULO 9 CONCLUSÃO... 233 9.1 Resultados Obtidos... 237 9.2 Trabalhos Futuros... 241 9.3 Considerações Finais... 242
REFERÊNCIAS BIBLIOGRÁFICAS... 245 APÊNDICE A PROBLEMAS ENCONTRADOS NA IMPLEMENTAÇÃO DA ARQUITETURA... 255 GLOSSÁRIO... 259
LISTA DE FIGURAS Pág. 2.1 Arquitetura simplificada do SICS... 37 2.2 A arquitetura SOFTBOARD... 46 2.3 - Uma visão dos serviços da arquitetura SICSD... 48 2.4 A arquitetura SICSD e seus objetos... 49 2.5 Integração do módulo de serviço MMP e dos possíveis módulos de payload... 52 2.6 - Diagrama de blocos da plataforma multi-missão MMP... 54 3.1 Modelo de três camadas físicas... 64 3.2 Arquitetura lógica da plataforma J2EE... 66 3.3 Um cliente usa a JNDI e a RMI para acessar um EJB... 67 3.4 Uso típico de componentes centrados na Web... 70 3.5 Um cliente independente interagindo diretamente com um EJB... 71 3.6 A plataforma J2EE com os serviços disponíveis... 73 3.7 Padrão DAO... 75 4.1 TypeObject..... 82 4.2 Property.. 83 4.3 TypeSquare..... 84 4.4 Accountability pattern..... 85 4.5 O pattern strategy...... 87 4.6 O pattern composite... 89 4.7 O pattern ruleobject...... 91 4.8 TypeSquare com regras... 91 4.9 O pattern interpreter... 93 4.10 O pattern builder......... 94 4.11- Arquitetura comum dos modelos de objetos adaptáveis... 98 4.12- Armazenando e recuperando metadados... 100
5.1 - Arquitetura SICSDA... 118 5.2 A carga inicial do sistema... 122 5.3- A dinâmica da interação em cada nó entre os serviços e os objetos da aplicação... 129 6.1 Diagrama de casos de uso para os satélites SCD1, SCD2 e CBERS2... 139 6.2 Diagrama de classes para os satélites SCD1, SCD2 e CBERS2... 140 6.3 Diagrama de pacotes da arquitetura SICSDA... 142 6.4 Diagrama de casos de uso para o serviço de configuração... 144 6.5 EJB de sessão do serviço de configuração... 145 6.6 A representação da visão de um cliente do EJB de sessão do serviço de configuração... 146 6.7 Diagrama de casos de uso para o serviço de usuário... 148 6.8 EJB de sessão do serviço de usuário... 149 6.9 A representação da visão de um cliente do EJB de sessão do serviço de usuário... 149 6.10 Diagrama de casos de uso para o serviço de persistência... 153 6.11 Representação de um EJB de entidade... 154 6.12 A representação da visão de um cliente de um EJB de entidade... 155 6.13 EJB de sessão do serviço de persistência... 156 6.14 A representação da visão de um cliente do EJB de sessão do serviço de 157 persistência... 6.15 Diagrama de casos de uso para o serviço de carga... 159 6.16 Diagrama de casos de uso para o serviço de adaptação... 161 6.17 EJB de sessão do serviço de adaptação... 161 6.18 A representação da visão de um cliente do EJB de sessão do serviço de 162 adaptação... 6.19 Arquitetura SICSDA X simulador de satélites... 165 7.1 Diagrama de classes após a aplicação do Pattern TypeObject... 169 7.2 Diagrama de classes após a aplicação do Pattern TypeObject novamente. 171 7.3 Diagrama de classes após a alicação do Pattern Property... 173 7.4 Diagrama de classes com a arquitetura TypeSquare... 174
7.5 Diagrama de classes após a aplicação do Pattern Accountability... 176 7.6 Diagrama de classes após a aplicação do Pattern Strategy... 177 7.7 Modelo independente de plataforma genérico... 179 7.8 Atributos de relacionamento... 191 7.9 Classes representadas como Enterprise Java Beans de entidade... 192 7.10 Diagrama de seqüência para adicionar um novo tipo de mensagem... 194 7.11 Diagrama de seqüência para ativar uma operação no sistema... 198 8.1 Dados de Estação... 217 8.2 Dados de TipoMensagem... 218 8.3 Execução do caso de uso Criar um Novo Tipo de Mensagem... 219 8.4 Escolhendo a opção TipoMensagem... 220 8.5 Inserindo um novo tipo de mensagem... 220 8.6 Execução do caso de uso Visualizar Telemetria... 224 8.7 Interface do serviço de usuário... 225 8.8 Visualizando telemetrias para o satélite SCD1... 231
LISTA DE TABELAS Pág. 5.1 Estados da Aplicação... 125 6.1 Nós/EJBs... 147 6.2 Usuários/Grupos... 151 7.1 A Classe TipoMensagem e suas Instâncias... 182 7.2 A Classe tipo TipoMensagem e suas Instâncias... 182 7.3 A Classe Mensagem e suas Instâncias... 183 7.4 A Classe Estação e suas Instâncias... 184 7.5 A Classe Frame e suas Instâncias... 184 7.6 A Classe Subsistema e suas Instâncias... 184 7.7 A Classe Satélite e suas Instâncias... 185 7.8 A Classe TipoDePropriedade e suas Instâncias... 186 7.9 A Classe Propriedade e suas Instâncias... 187 7.10 A Classe TipoDeRelacionamento e suas Instâncias... 188 7.11 A Classe Relacionamento e suas Instâncias... 189 7.12 A Classe Estratégia e suas Instâncias... 189
CAPÍTULO 1 INTRODUÇÃO A grande extensão do país e a existência de imensas áreas com baixa densidade populacional, especialmente na região Amazônica, são características predominantes para justificar o uso de satélites como instrumentos de integração do território nacional, através de suas redes de comunicação, serviços de previsão de tempo e acompanhamento dos processos de uso do solo. Essas condições fisiográficas, aliadas à prática adquirida no estudo e na utilização de técnicas espaciais, foram motivos suficientes para se iniciar um programa de desenvolvimento da tecnologia espacial no Brasil. O Instituto Nacional de Pesquisas Espacias (INPE), como uma das principais organizações envolvidas na evolução tecnológica espacial brasileira, assumiu a responsabilidade do lançamento e controle dos primeiros satélites brasileiros. O programa espacial brasileiro compreende o lançamento de quatro satélites, sendo os dois primeiros utilizados para coleta de dados, e os outros, para sensoriamento remoto (Ferreira,2001). Tanto os satélites de coleta de dados (o Sistema de Coleta de Dados 1 (SCD1) e o Sistema de Coleta de Dados 2 (SCD2)), quanto os satélites de sensoriamento remoto (o China Brazil Earth Research Satellite 1 (CBERS1) e o China Brazil Earth Research Satellite 2 (CBERS2)), já foram lançados; porém, apenas os satélites SCD1, SCD2 e CBERS2 continuam se comunicando com a Terra. Para gerir todas as peculiaridades inerentes ao controle de um satélite, o INPE criou uma infra-estrutura robusta, apoiada por duas estações de rastreamento e aplicativos de software para o controle de satélites (Ferreira,2001). 25
Para cada satélite já lançado, portanto, foi desenvolvido um aplicativo de software que permite que se faça o seu monitoramento em terra. Isso é necessário, pois cada satélite tem características próprias, que normalmente variam, mesmo que sutilmente, de um satélite para outro. O acesso a esses aplicativos está restrito aos controladores de satélites fisicamente localizados no Centro de Controle de Satélites (CCS) no INPE em São José dos Campos. Cada satélite lançado necessita, portanto, que seja destinada a ele uma máquina ou um conjunto de máquinas específicas onde um aplicativo específico para aquele determinado satélite é executado, auxiliando no recebimento de seus dados e monitoramento de seu estado interno. Isto significa que para cada novo satélite a ser lançado, um aplicativo deverá ser desenvolvido ou adaptado para aquele satélite em especial, e máquinas deverão ser destinadas à execução desse software específico, implicando em um custo de desenvolvimento adicional a cada novo lançamento, tanto em termos de hardware, quanto em termos de software. Esse contexto nos leva a pensar na criação de um único sistema de software para o controle de satélites, que permita que os diferentes tipos de satélites possam ser monitorados de uma mesma máquina ou de um mesmo conjunto de máquinas. Ainda assim, a necessidade de uma adaptação no sistema, por exemplo, para incorporar características de um novo satélite a ser monitorado, traria uma série de dificuldades para a adaptação do software, ocasionando um grande esforço despendido para que as novas características pudessem ser incorporadas ao sistema de forma que a qualidade do mesmo fosse mantida. Todas essas questões, aliadas ao desejo crescente de se obter aplicações que evoluam à medida que o domínio do problema evolui, fez com que se pensasse em construir 26
aplicações que pudessem ser mais facilmente configuráveis, flexíveis e adaptáveis, permitindo que o sistema possa ser adaptado, mais facilmente, às novas necessidades do domínio, acompanhando a evolução dos requisitos, porém, mantendo sua qualidade. Uma forma de se conseguir isto é mover certos aspectos do sistema, como regras de negócio, por exemplo, para o banco de dados, fazendo com que, dessa forma, elas possam ser facilmente modificadas. O modelo resultante permite que o sistema possa se adaptar rapidamente às novas necessidades do domínio através de modificações nos valores armazenados no banco de dados, ao invés de modificações no código (Yoder,2001). Isto encoraja o desenvolvimento de ferramentas que permitam que os especialistas do domínio introduzam novos elementos ao software sem a necessidade de programação adicional, e que façam mudanças em seus modelos de domínio em tempo de execução, reduzindo significantemente o tempo para incorporação de novos requisitos ao software. Arquiteturas que podem dinamicamente se adaptar em tempo de execução a novos requisitos de usuários são chamadas de arquiteturas reflexivas ou meta-arquiteturas. Esse tipo de arquitetura baseia-se na propriedade de reflexão, onde reflexão é a propriedade de um sistema através da qual a estrutura e a operação desse sistema podem ser controladas e atualizadas de fora dele (Killijian,2000). Assim, um sistema reflexivo tem uma representação de si mesmo que pode ser observada (auto-representação). Freqüentemente, essa auto-representação é expressa em termos de entidades abstratas que podem ser manipuladas para modificar o comportamento do sistema. Então, um sistema reflexivo promove a escrita de componentes genéricos e reusáveis que manipulam essa auto-representação (Nguyen- Tuong,1999). O modelo reflexivo sugere um novo paradigma para o desenvolvimento de sistemas. Nesse novo paradigma, um sistema é decomposto em pelo menos dois níveis: (1) o nível base, onde estão agrupadas as funções relacionadas exclusivamente ao domínio do 27
problema e (2) o nível reflexivo que agrupa o código que supervisiona, adapta e retorna informações sobre o nível base (Stehling,1999). Arquiteturas reflexivas permitem que sistemas de software possam ser escritos de forma dinâmica, adaptável, altamente flexível e extensível (Amano,1999). Uma arquitetura de modelos de objetos adaptáveis (Adaptive Object Model Architecture) é um tipo particular de arquitetura reflexiva que abrange sistemas orientados a objeto que gerenciam elementos de algum tipo, e que podem ser estendidos para adicionar novos elementos. Sistemas que têm este tipo de arquitetura podem ser chamados de Modelos de Objetos Ativos (Active Object Models), Modelos de Objetos Dinâmicos (Dynamic Object Models), ou Modelos de Objetos Adaptáveis (Adaptive Object Models) (Yoder,2001). Usar a abordagem dos modelos de objetos adaptáveis no desenvolvimento de sistemas pode amenizar alguns dos problemas que vêm sendo encontrados pelos desenvolvedores de software, principalmente em relação à flexibilidade e evolução, permitindo que o custo total do desenvolvimento e manutenção possa ser reduzido (Ledeczi,2000). 1.1- Objetivos do Trabalho de Pesquisa Este trabalho visa o estabelecimento de uma arquitetura distribuída, configurável e adaptável para o software de controle de satélites, que está baseada em modelos de objetos adaptáveis. Esta arquitetura apresenta-se como uma evolução da arquitetura SOFTBOARD, proposta em Cunha(1997), e da arquitetura SICSD, proposta em Ferreira(2001). O objetivo de se propor esta arquitetura é permitir que o controle dos vários satélites possa ser feito usando-se o mesmo conjunto de máquinas, possibilitando que se possa escolher qual dos satélites se deseja monitorar em um determinado instante. É 28
importante ressaltar que não é possível, pelo menos por enquanto, monitorar mais de um satélite por vez, já que apenas a estação de Cuiabá encontra-se em operação. Outro fator importante é a necessidade de se ter uma arquitetura que permita que uma nova missão possa ser acomodada sem a necessidade de se criar um sistema específico para o satélite a ser lançado, fazendo com que o esforço necessário para adaptar o sistema a esse novo requisito seja minimizado. Além disso, deseja-se que os especialistas do domínio (engenheiros e controladores de satélites) e que os desenvolvedores do software de controle de satélites (programadores e administradores) possam configurar, se necessário, atributos e regras de negócio para os satélites já lançados, e que possam também, acrescentar novos elementos ao domínio do problema sem a necessidade de programação adicional; embora isso seja incomum, uma vez que os satélites já lançados dificilmente sofrem alterações deste tipo. A camada de apresentação dos dados para o sistema aqui proposto, ou seja, a interface humana, também deve ser configurável, já que diferentes satélites poderão ter uma interface humana composta por elementos peculiares ao funcionamento de cada um deles. Porém, as estratégias para a construção de uma interface configurável não foram abordadas neste trabalho, uma vez que esse assunto já foi bastante explorado em Siqueira (2001). 1.2- Motivação do Trabalho de Pesquisa Embora a computação genérica e os sistemas reflexivos já venham sendo explorados há algum tempo, os modelos de objetos adaptáveis ainda são pouco conhecidos, e apresentam, portanto, um grande potencial para ser explorado, especialmente, quando aliados ao conceito de distribuição. 29
Apesar de algumas aplicações baseadas em modelos de objetos adaptáveis já terem sido desenvolvidas, nenhuma que se tem conhecimento explorou o conceito de distribuição dos metadados do sistema; embora algumas tivessem citado a possibilidade de se usar bancos de dados distribuídos. Exemplos de aplicações desenvolvidas usando-se modelos de objetos adaptáveis podem ser encontrados em Johnson (2002), Yoder (2001) e Yoder (2003). Alguns trabalhos de pesquisa têm sido desenvolvidos aplicando-se distribuição e adaptação no contexto de sistemas móveis, como, por exemplo, os trabalhos apresentados em Augustim (2002), Chen, Hiltunen e Schlichting (2001), Pirmez (2002), Silva (2003) e Souza (2004). Nesse contexto, a adaptação refere-se, principalmente, à possibilidade de recuperação de falhas, ou seja, o sistema deve ser capaz de interromper ou iniciar uma determinada atividade dependendo do contexto em que se encontra. Dessa forma, a recuperação de falhas nesses trabalhos é vista como um processo de adaptação. A adaptação, no contexto deste trabalho, tem uma conotação um pouco diferente da utilizada na bibliografia, pois, além do comportamento dinâmico do sistema, existe a possibilidade de se criar, também em tempo de execução, novos elementos, alterando-se o domínio do sistema, o que acrescenta ao trabalho uma particularidade bastante interessante para ser explorada. Um outro indicativo de que os modelos de objetos adaptáveis têm potencial para ser explorado foi dado em Poole (2001) e Vaduva (2001). Nestes artigos os modelos de objetos adaptáveis são colocados como uma possível evolução à Model Driven Architecture (MDA), recentemente proposta pelo Object Management Group (OMG). Mais detalhes sobre a MDA e seus padrões podem ser encontrados em Atkinson e Kühne (2003), Breton e Bérzivin (2001), Deva (2000), OMG (2002), Sprinkle (2001), Tan (2002) e Witthawaskul e Johnson (2003). 30
Além disso, em Vaduva (2001), o uso de modelos de objetos adaptáveis para a construção de software é visto como uma forma de se aumentar a flexibilidade e a adaptabilidade do sistema, pois eles possibilitam que um sistema se adapte mais facilmente a novos requisitos do domínio, e são, por natureza, facilmente extensíveis. Mais um indicativo foi dado em Stehling (1999). Nesta dissertação o modelo reflexivo é visto como um novo paradigma para o desenvolvimento de sistemas. Assim sendo, existe potencial para explorar esse tipo de modelo sob o ponto de vista da engenharia de software, ou seja, provavelmente será necessário que se conceba uma nova forma de se desenvolver esse tipo de sistema, adequando metodologias e processos de desenvolvimento propostos pela área de engenharia de software a esse novo contexto. Este trabalho une, portanto, áreas que até então eram exploradas de forma independente, trazendo para si uma característica multidisciplinar, ou seja, possibilitando a integração e colaboração de várias áreas. Além disso, o trabalho proposto aproveita esforços do passado através da elaboração de uma arquitetura que modela a aplicação para o controle de satélites com base nas arquiteturas SOFTBOARD e SICSD. Outra motivação importante para o desenvolvimento deste trabalho vem do próprio INPE. Visando aproveitar o esforço despendido no projeto e na construção dos equipamentos que compõe um satélite, o INPE lançou um projeto multi-missão que deverá entrar em vigor em 2007. Esse projeto propõe a construção de um barramento configurável, chamado de plataforma multi-missão (Multi-Mission Platform MMP) que serve como base para a construção de vários satélites (INPE,2001). Ao propor a plataforma multi-missão MMP, o INPE demonstrou o seu interesse em reaproveitar esforços realizados, visando à concepção de arquiteturas de hardware mais flexíveis, e que possam ser facilmente configuráveis. 31
O projeto multi-missão vem de encontro ao trabalho aqui proposto, uma vez que o reaproveitamento do esforço despendido para gerir as missões pode ser melhorado ainda mais, se for reaproveitado, além do hardware, o esforço realizado para o desenvolvimento do software de controle. 1.3- Metodologia de Desenvolvimento do Trabalho de Pesquisa Na primeira etapa deste trabalho, realizou-se um levantamento da bibliografia existente e um estudo das diversas metodologias, tecnologias, filosofias e arquiteturas que abrangiam os aspectos que o motivaram. Assim, este estudo abrangeu o Sistema de Controle de Satélites do INPE e seu software de controle SICS, os sistemas de objetos distribuídos e suas tecnologias, a arquitetura SICSD, aspectos sobre sistemas configuráveis, a arquitetura SOFTBOARD, conceitos sobre computação reflexiva, programação genérica, arquiteturas dirigidas a modelos, e finalmente, conceitos e aplicações de modelos de objetos adaptáveis e tecnologias existentes. Nesta primeira etapa, foram então definidas e apresentadas as motivações do trabalho a ser desenvolvido, delimitados seus objetivos e as contribuições esperadas e, também, definidas as tecnologias e metodologias que seriam utilizadas durante sua elaboração. Esta etapa foi compreendida pela proposta de Tese de Doutorado apresentada. Uma vez definidos os objetivos da arquitetura proposta, foram buscados complementos na literatura relacionada e procuradas as tecnologias e ferramentas pertinentes. Este trabalho, tal qual proposto, incorpora e utiliza a Unified Modeling Language (UML) como notação para representar os diagramas de casos de uso, de classe, de pacotes, de componentes e de seqüência, bem como, a tecnologia de comunicação e distribuição J2EE, e a tecnologia de banco de dados orientado a objetos para o armazenamento e recuperação dos metadados. Assim, dentro deste universo, foram pesquisados e procurados sistemas e ferramentas que contemplassem estas tecnologias, metodologias e arquiteturas, e as escolhas recaíram sobre os sistemas e ferramentas que se mostraram 32
suficientemente abrangentes, de fácil instalação, e que estavam disponíveis para estudo e pesquisa. Nesta fase, as ferramentas foram escolhidas, instaladas e analisadas. Definidas as ferramentas, passou-se para a fase de delimitação e detalhamento da arquitetura SICSDA e seus componentes, ou seja, delimitação e detalhamento da estrutura e funcionamento da arquitetura como um todo, e em relação a cada um de seus componentes. Desta forma, foram delimitados e detalhados, quanto às suas estruturas e funcionamento, cada um dos seguintes componentes da arquitetura SICSDA: Serviço de Persistência, Serviço de Configuração, Serviço de Carga, Serviço de Usuário e Serviço de Adaptação. Delimitados e definidos os componentes da arquitetura, passou-se para as fases de análise e projeto do software, utilizando-se a ferramenta UML escolhida e instalada para a geração dos devidos diagramas de software. Obviamente, devido à complexidade do domínio e à necessidade de sigilo de informações, apenas uma parte das funções de um sistema de controle de satélites real foi abordada nestes diagramas, mais precisamente, foram abrangidas as funções de recebimento de telemetria, envio de telecomandos e obtenção de medidas de distância e calibração. A geração do diagrama de classes genérico foi obtida através de design patterns especialmente direcionados para este tipo de transformação. Terminada esta etapa, foi desenvolvido um protótipo baseado no projeto realizado, visando avaliar o quão factível mostrava-se esta arquitetura, e como seus componentes poderiam, de fato, interagir e colaborar para a execução adequada do Software de Controle de Satélites. Para testar o sistema, primeiramente foram inseridos os metadados para os satélites SCD1, SCD2 e CBERS2, através da interface disponibilizada pelo Serviço de Configuração. Feito isso, pode-se testar o sistema quanto à realização das operações de Visualização de Telemetrias, Envio de Telecomandos e Obtenção de Medidas 33
para os satélites citados, utilizando-se para tal, a interface disponibilizada pelo Serviço de Usuário. Finalmente, o trabalho de pesquisa realizado foi expresso neste relatório, que tem a sua estrutura detalhada a seguir. 1.4- Estrutura do Relatório Para que a arquitetura SICSDA pudesse ser definida e projetada, algumas tecnologias já mencionadas são apresentadas, de forma, sucinta, nos primeiros capítulos deste trabalho. Assim, tem-se: Capítulo 2 Sistema de Rastreio e Controle de Satélites: neste capítulo é apresentada uma visão geral do Sistema de rastreio e controle de satélites do INPE, mostrando suas funções, funcionamento e componentes. Capítulo 3 Computação Baseada em Objetos Distribuídos: neste capítulo são abordados os sistemas de objetos distribuídos e descritas, em linhas gerais, as arquiteturas e tecnologias que surgiram como soluções e alternativas para estes sistemas, e que estão incorporadas ao projeto da arquitetura SICSDA. Capítulo 4 Modelos de Objetos Adaptáveis: neste capítulo são abordados os conceitos de modelos de objetos adaptáveis, suas particularidades, e os design patterns que estão envolvidos na obtenção de um metamodelo ou de um modelo genérico para representar um sistema. São abordadas, ainda, algumas vantagens e desvantagens envolvidas no uso de modelos de objetos adaptáveis. Uma vez que foram apresentadas as tecnologias, metodologias e arquiteturas que embasaram esta pesquisa, são apresentados os capítulos referentes à própria arquitetura SICSDA: 34
Capítulo 5 A Arquitetura SICSDA: neste capítulo é definida e descrita a arquitetura SICSDA através da descrição e definição do escopo e do funcionamento de seus componentes, bem como de sua estrutura e funcionamento geral. É definida também a sua relação com as tecnologias de armazenamento, comunicação e distribuição que foram abrangidas. Capítulo 6 Estratégias para a Construção da Arquitetura Proposta: neste capítulo são descritas as estratégias utilizadas para a implantação da arquitetura SICSDA, ou seja, as estratégias adotadas para o desenvolvimento dos serviços propostos. Cada serviço é detalhado sob o ponto de vista de seu funcionamento e futura implementação. Capítulo 7 Estratégias para a Construção do Serviço de Adaptação: neste capítulo são descritas, mais especificamente, as estratégias utilizadas para se construir o Serviço de Adaptação, o que inclui a construção do metamodelo (modelo genérico) para o sistema de controle de satélites e a representação dos modelos de cada satélite como sendo metadados. Capítulo 8 Construção do Protótipo: neste capítulo são descritos os passos seguidos para a implementação do protótipo da arquitetura SICSDA. São feitas também, considerações a respeito das tecnologias e ferramentas adotadas para o desenvolvimento do protótipo, apontando-se, quando se julgou necessário, justificativas para o uso das tecnologias e ferramentas adotadas. Capítulo 9 Conclusão: neste capítulo são apresentados as conclusões e resultados obtidos com o trabalho de pesquisa, bem como, algumas sugestões para a realização de trabalhos complementares. Para finalizar este trabalho são mostrados as referências bibliográficas, o apêndice e o glossário. Assim tem-se: 35
Referências Bibliográficas: neste item são apresentadas todas as referências bibliográficas que são citadas no texto. Apêndice Problemas Encontrados na Implementação da Arquitetura: no apêndice estão colocados alguns dos problemas encontrados durante o desenvolvimento e implementação da arquitetura, principalmente no tocante às ferramentas adotadas. Glossário: neste item são apresentadas as siglas utilizadas no texto, bem como seus respectivos significados. 36
CAPÍTULO 2 SISTEMA DE RASTREIO E CONTROLE DE SATÉLITES O sistema de rastreio e controle de satélites do INPE é constituído pelo Centro de Controle de Satélites (CCS - São José dos Campos), por duas estações terrenas remotas, uma em Cuiabá (MT) e outra em Alcântara (MA), por uma rede de comunicação de dados que interliga estas unidades (RECDAS) e, finalmente, por um software aplicativo (Sistema de Controle de Satélites SICS), projetados especialmente para controlar os satélites desenvolvidos pelo INPE, como ilustra a Figura 2.1. FIGURA 2.1- Arquitetura simplificada do SICS. FONTE: Adaptada de Rozenfeld (2002). 37
2.1- O Centro de Controle de Satélites (CCS) A finalidade do Centro de Controle de Satélites (CCS) é assegurar o funcionamento perfeito do satélite, desde sua injeção em órbita, até o fim de sua vida útil. A partir do CCS, são programadas e controladas as atividades das estações terrenas. O sistema computacional do CCS se compõe computadores PCs, cujo software aplicativo (SICS) desempenha as funções listadas a seguir (Ferreira,2001): Receber, em tempo real, das estações terrenas, os dados de telemetria, contendo informações sobre a atitude, temperaturas e parâmetros funcionais dos equipamentos de bordo do satélite, processá-los e arquivá-los. Esta função permite às equipes de controle de solo monitorar continuamente a orientação do satélite no espaço (atitude) e o seu estado de funcionamento. Receber das estações e arquivar os dados de localização do satélite (medidas de distância ou angulares). Gerar e transmitir às estações terrenas, telecomandos que, quando irradiados pelas estações ao satélite, são recebidos e executados por seus sistemas de bordo. Isto permite que se atue a partir do solo no satélite para a re-configuração do estado de funcionamento de seus equipamentos, ou execução de manobras de controle de atitude ou órbita. Monitorar o estado de funcionamento dos equipamentos residentes nas estações terrenas. 38
O ciclo de vida de um satélite compreende etapas que vão desde a fase de lançamento até a fase de rotina. A fase de lançamento é considerada a mais crítica, devido a problemas que podem ocorrer com o próprio veículo lançador. Na fase seguinte (aquisição), são captados os primeiros sinais do satélite. A próxima fase (aceitação) objetiva testar as funcionalidades de todos os subsistemas internos do satélite. Depois de um teste geral, o controle de um satélite entra na fase de rotina. A fase de rotina é intercalada, periodicamente, com a fase de manobras, que consiste, basicamente, da realização de manobras para alterar a atitude do satélite (Ferreira,2001). As atividades do CCS são desenvolvidas em instalações apropriadas para cada fase da vida do satélite em órbita. Assim, nas fases críticas (lançamento e manobras), as atividades de controle são executadas a partir da sala de controle principal. Na fase de rotina, as atividades são executadas a partir de uma sala de controle dedicada ao satélite em questão. Na fase de lançamento de órbitas iniciais (FLOI), as atividades de controle seguem procedimentos desenvolvidos previamente ao seu lançamento, que constituem o chamado Plano de Operações de Vôo para o FLOI. Na fase de rotina, devido à característica repetitiva das operações de controle, o plano de vôo é gerado periodicamente, de forma automática, com o auxílio de um programa computacional desenvolvido para essa finalidade. 2.2- As Estações Terrenas As estações terrenas são o elo de ligação entre o CCS e o satélite em órbita. Suas atividades básicas são (Ferreira,2001): Adquirir o sinal do satélite e segui-lo durante sua passagem sobre a estação; 39
extrair do sinal recebido os dados do estado dos equipamentos de bordo, datá-los e encaminhá-los ao CCS; irradiar para o satélite os telecomandos recebidos do CCS no horário determinado; e efetuar as medidas de localização (distância do satélite até a estação e ângulos de azimute e de elevação do satélite em relação à estação), datá-las e encaminhá-las ao CCS para que sejam processadas, possibilitando assim, a determinação da órbita do satélite. 2.3- A Rede de Comunicação de Dados (RECDAS) Esta rede interliga o CCS às estações terrenas e apresenta as seguintes características (Ferreira,2001): É uma rede privada de comunicação de dados que implementa o protocolo de acesso TCP/IP; é constituída por três nós, um em cada local, e por um centro de gerenciamento de redes localizado no CCS; e implementa a topologia em estrela, sendo o nó de São José dos Campos o centro da rede. 40
2.4- O Software Aplicativo (SICS) O desenvolvimento de software para controle de satélites no INPE se intensificou na década de 80 com o surgimento da Missão Espacial Completa Brasileira (MECB), e o Sistema de Controle de Satélites (SICS), foi o primeiro sistema desenvolvido para atender a essas necessidades. Ele foi implementado em FORTRAN 77, e implantado, inicialmente, em computadores VAX da DIGITAL; e posteriormente, foi migrado para computadores ALPHA da própria DIGITAL. A versão atual do SICS tem uma arquitetura cliente-servidor e apresenta-se disponível em plataformas PCs, como ilustra a Figura 2.1. Para o seu desenvolvimento e implementação, utilizou-se o ambiente de desenvolvimento Visual C++ da Microsoft e uma metodologia orientada a objetos (Ferreira,2001). O SICS é composto pelo Software Operacional do Satélite do Centro de Controle de Satélites (CCS), denominado Software de Controle de Satélites (SCS), que fica localizado em São José dos Campos (SP), e pelo Software Operacional de Estação Terrena (CET), que fica localizado, juntamente com outros equipamentos, em Cuiabá (MT) e em Alcântara (MA). O SCS realiza as tarefas de tempo real para controle de satélites e as tarefas de comunicação com as entidades externas ao CCS. Ele também efetua a monitoração e controle de satélites e a monitoração e controle das estações terrenas (ET). O CET faz parte do software aplicativo do computador das estações terrenas de Alcântara e Cuiabá, e tem como objetivo dar apoio às funções de supervisão dos equipamentos das estações, às funções de controle de antena e às funções de back-up parcial do CCS, em operações de contingências. Os principais equipamentos das 41
estações terrenas relacionados à comunicação com o satélite, com exceção dos computadores, são: ANTENA: responsável pela recepção e transmissão de dados para o satélite; TELECOMANDO: equipamento responsável pelo envio de telecomandos para o satélite; TELEMETRIA: equipamento responsável pelo recebimento de telemetrias do satélite e RANGING: equipamento responsável pelas medidas de distância e calibração. Existem várias categorias de usuários para controles de satélites, dentre elas pode-se ressaltar: a) Controladores de satélites: apresentam-se como responsáveis pela execução do plano de vôo de um satélite. b) Engenheiros de satélites: responsabilizam-se pelo acompanhamento dos subsistemas internos de um satélite, tais como bateria, carga útil etc. 42
2.4.1- Principais Funções do SICS As principais funções do SICS são (Ferreira,2001): Prover meios para a transmissão de telecomandos, cancelamento de telecomandos a serem transmitidos, execução da validação e da verificação de comandos, através de telemetria de tempo real e gravação dos comandos enviados em um histórico. Prover meios para a visualização dos dados de telemetria em tempo real e a partir de um histórico; assinalar, no caso de visualização de tempo real, os dados de telemetria fora dos limites, que são identificados através do processamento da telemetria; visualizar todos os dados de telemetria fora dos limites de um mesmo quadro (frame) e recuperar, no caso de tempo real, os últimos eventos recebidos de visualização. Gerenciar a antena, permitindo a execução de uma estratégia de aquisição e rastreio do satélite durante a passagem. A estratégia de aquisição selecionada deve ser monitorada e interrompida, caso necessário. Calcular os dados de apontamento da antena para uma dada estratégia e enviar para o operador da antena. Enviar telecomando que liga o transmissor de bordo do satélite. Prover meios para o acompanhamento visual da órbita do satélite em tela mural do CCS. 43
Prover meios para manutenção, armazenamento e recuperação de dados em arquivos históricos. Prover meios para a visualização, em tempo real, dos dados de supervisão dos equipamentos de uma determinada estação terrena, tanto localmente, como remotamente, no CCS. Gravar os dados de supervisão num arquivo histórico de supervisão da estação e reportar problemas críticos detectados nos equipamentos. Prover meios para auxiliar na operação de uma estação terrena e realizar funções auxiliares de operação do segmento solo: comunicação operador/operador, envio de dados de previsão de passagem do satélite (no CCS), reconhecimento de alarmes, visualização da configuração do segmento solo para que o operador tenha conhecimento das conexões ativas, ativação e desativação de procedimentos de varredura da antena (na estação terrena), recebimento do estado de operação da antena, interrupção de um processo de aquisição, e teste de uma determinada estratégia de aquisição. A maioria dessas funções deve estar disponível tanto no CCS quanto nas estações terrenas. Prover meios para a solicitação e o armazenamento de medidas de distância do satélite e de medida de calibração do Conjunto de Medidas de Distância (CMD) da estação terrena, armazenar as medidas de distância e de calibração, que forem consideradas válidas num histórico. Prover meios para inicialização e atualização do relógio dos computadores do CCS e das estações terrenas com o horário universal (GMT). 44
Prover meios para a troca de mensagens entre os componentes do SCS e demais hospedeiros da rede de comunicação de dados de satélites (RECDAS) ou da estações de rastreio e controle estrangeiras. Prover meios para a transferência de arquivos de dados entre o CCS e as estações terrenas e/ou o armazenamento de arquivos de previsão de passagem em disco para o histórico no CCS. Supervisionar o estado dos equipamentos de uma estação terrena; configurar os equipamentos da estação para passagem, calibração e testes. Prover meios para o armazenamento e processamento em tempo real dos dados de telemetria e dos dados de testes, prover meios para recuperação de alarmes, armazenamento de mensagens válidas de telemetria e do computador de bordo em tempo real, prover meios para a validação dos quadros (frames) de telemetria de tempo real e das mensagens de telemetria de testes. 2.4.2- Outras Arquiteturas Propostas para o SICS A seguir são apresentadas duas outras arquiteturas propostas para o SICS em teses de doutorado realizadas no INPE. 2.4.2.1- A Arquitetura SOFTBOARD A arquitetura SOFTBOARD é uma a arquitetura de sistema de software configurável baseado em objetos que foi proposta em Cunha(1997). Com essa arquitetura buscou-se, principalmente, um incremento na reutilização do software, propondo-se a divisão de 45
um sistema de software em componentes que, na medida do possível, são reaproveitados para o desenvolvimento de vários tipos de sistemas. A Figura 2.2 ilustra esta arquitetura, onde: CDP: refere-se ao Componente Domínio do Problema, e contém as classes e objetos da essência da aplicação. CIH: refere-se ao Componente Interface Humana, e contém todas as classes e objetos necessárias para a realização da interface entre as classes e objetos do CDP e os usuários. CGT CIH CDP CDP CGD CMOOS CIS BD Catálogo Outros Sistemas FIGURA 2.2 A arquitetura SOFTBOARD. FONTE: Adaptada de Cunha (1997). 46
CGD: refere-se ao Componente Gerenciador de Dados, e contém as classes e objetos necessárias para armazenar e recuperar no/do banco de dados as classes e objetos do CDP. CIS: refere-se ao Componente de Interface entre Sistemas, e contém as classes&objetos necessárias para a realização da interface entre as classes e objetos do CDP de um determinado sistema com classes&objetos do CDP de outros sistemas. CGT: refere-se ao Componente Gerenciador de Tarefas, e contém as classes e objetos necessárias para agregar as classes&objetos do CDP, CIH, CIS e CGD que compõe cada tarefa. CMOOS: refere-se ao componente Gerenciador de Configuração de Sistema Baseado em Objetos. Ele é o componente responsável por manter um repositório de descritores (informações que possibilitam que o CIH, CGT, CIS e CGD se adaptem quando um CDP diferente é colocado no sistema de software). Além das informações de configuração, o CMOOS possui a classe e objetos Servidor- CMOOS que disponibiliza os serviços para montar, alterar em tempo de execução e recuperar as configurações de um dado objeto, seja ele do CDP, CGD, CIH ou CIS. O desenvolvimento de uma nova aplicação consiste em gerar uma SOFTBOARD e customizá-la, configurando-se o seu repositório de configurações mantido pelo CMOOS, e desenvolvendo-se apenas as classes e objetos do CDP, já que as classes e objetos dos outros componentes poderão ser re-configuradas, proporcionando, assim, um grande incremento na reutilização. 47
Esse trabalho proposto em Cunha (1997) coloca vários exemplos ilustrando o sistema de controle de satélites, e aponta como trabalho futuro, a implementação da SOFTBOARD para o Sistema de Controle de Satélites do INPE. 2.4.2.2- A Arquitetura SICSD Essa arquitetura, proposta em Ferreira (2001), modela a aplicação para controle de satélites através de objetos e os distribui dentro de um domínio de rede pré-definido. Ela incorpora todas as funcionalidades presentes nas versões anteriores do SICS, agregando também novas capacidades ao sistema como, por exemplo, os serviços de agentes, persistência, segurança e balanceamento. A Figura 2.3 ilustra a arquitetura SICSD e seus serviços. objetos da aplicação APLICAÇÃO Serviço de Persistência Serviço de Segurança ORB(CORBA) Middleware Serviço dos Agentes Serviço de Balanceamento Fig. 6.2 Uma visão dos serviços da arquitetura SICSD. FIGURA 2.3 - Uma visão dos serviços da arquitetura SICSD. FONTE: Adaptada de Ferreira (2001). Nessa arquitetura, a rotina de carga do sistema define a localização inicial dos objetos. A partir desse momento, eles podem migrar ou ser replicados, de uma máquina para 48
outra, de acordo com a demanda por solicitação de serviço, ou seja, eles apresentam um comportamento dinâmico. Os objetos da Figura 2.4 são exemplos baseados no atual sistema de controle de satélites e servem para ilustrar o funcionamento da arquitetura SICSD. telemetria 01 telemetria N Simulador Equipamen -to Middleware Usuários Estação 01 Estação N Ranging telecoman dos 01 telecoman dos N FIGURA 2.4 A arquitetura SICSD e seus objetos. FONTE: Ferreira (2001). Na arquitetura SICSD, os objetos da aplicação se comunicam através de um middleware, sendo que pode existir mais de uma cópia de um objeto instanciado em nós diferentes da rede, conforme está detalhado a seguir: Telemetria: este objeto encapsula o estado interno do satélite, como por exemplo, a voltagem de um determinado circuito, o posicionamento de uma 49
determinada chave (ligada ou desligada), como também os métodos inerentes ao objeto, tais como processar telemetria, visualizar telemetria etc. Telecomando: este objeto encapsula os telecomandos que podem ser enviados para o satélite, bem como os métodos pertinentes ao objeto, tais como enviar telecomando, visualizar telecomandos, etc. Estação: este objeto contém a descrição das estações utilizadas para recepção dos dados dos satélites, que são controlados pelo INPE. Atualmente existem duas estações: Cuiabá e Alcântara. Como a arquitetura proposta modela a aplicação para controle de satélites em objetos, atribui-se a estes objetos os parâmetros pertencentes a uma estação, tais como latitude, longitude, etc. Ranging: este objeto encapsula as medidas de distância do satélite em relação à Terra, bem como os métodos responsáveis por esse cálculo. Equipamento: contém a descrição dos equipamentos instalados para a recepção e transmissão de dados de/para o satélite. Esse objeto encapsula os atributos dos equipamentos utilizados para controle de satélites, tais como freqüência, potência etc. Simulador: este objeto simula os possíveis estados de um satélite e disponibiliza esses dados para todos os outros objetos através de uma interface. Entende-se por estado de um satélite as possíveis condições internas nas quais ele pode se encontrar em um determinado instante. A capacidade de simular uma falha em um determinado circuito elétrico, ou mesmo o posicionamento de uma chave (ligada ou desligada), devem ser atribuições do objeto simulador. Através das telemetrias tem-se um panorama do funcionamento interno de um satélite e com o 50