UMA ARQUITETURA DE SOFTWARE DISTRIBUÍDA, CONFIGURÁVEL E ADAPTÁVEL APLICADA ÀS VÁRIAS MISSÕES DE CONTROLE DE SATÉLITES

Transcrição

1 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É Professora - Engenharia da Computação - UnicenP/Centro Universitário Positivo adriana.thome@unicenp.edu.br MAURICIO G. V. FERREIRA Pesquisador - INPE/Instituto Nacional de Pesquisas Espaciais mauricio@ccs.inpe.br JOÃO BOSCO S. CUNHA Professor - UNIFEI/Universidade Federal de Itajubá bosco@unifei.edu.br 117 da Vinci da Vinci,, Curitiba, v. 2 v., n. 2, 1, n. p. 1, , p ,

2 UMA ARQUITETURA DE SOFTWARE DISTRIBUÍDA, CONFIGURÁVEL E... RESUMO Neste artigo é proposta 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. Palavras-chave: modelos de objetos adaptáveis, metamodelos, sistemas distribuídos. ABSTRACT This paper 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. Key-words: adaptive object models, metamodels, distributed systems. 118 da Vinci, Curitiba, v. 2, n. 1, p , 2005

3 ADRIANA CURSINO THOMÉ, MAURICIO G. V. FERREIRA, JOÃO BOSCO S. CUNHA 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É / MAURICIO G. V. FERREIRA / JOÃO BOSCO S. CUNHA 1 INTRODUÇÃO Este artigo apresenta um resumo da tese de Doutorado em Computação Aplicada intitulada SICSDA uma arquitetura de software distribuída, configurável e adaptável aplicada às várias missões de controle de satélites, realizada no Instituto Nacional de Pesquisas Espaciais (INPE) e concluída em novembro de 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 (SCD1 (Sistema de Coleta de Dados 1) e SCD2 (Sistema de Coleta de Dados 2)), e os outros, para sensoriamento remoto (CBERS1 (China Brazil Earth Research Satellite 1) e CBERS2 (China Brazil Earth Research Satellite 2)), todos já lançados. Para gerir todas as peculiaridades inerentes ao controle de um satélite, o INPE criou uma infra-estrutura robusta, ilustrada na Figura 1, composta pelo Centro de Controle de Satélites (CCS), por duas estações de rastreamento (Estações de Cuiabá e Alcântara), por uma rede de comunicação (RECDAS) e por aplicativos de software para o controle de satélites (SICS). As estações remotas localizadas em Cuiabá e Alcântara oferecem, juntamente com o CCS, o suporte em terra para o controle dos satélites em órbita (FERREIRA,2001). Para cada satélite já lançado foi desenvolvido um aplicativo de software que permite 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 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 um custo de desenvolvimento adicional a cada novo lançamento, tanto em termos de hardware, quanto em termos de software. Este 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 119 da Vinci, Curitiba, v. 2, n. 1, p ,

4 UMA ARQUITETURA DE SOFTWARE DISTRIBUÍDA, CONFIGURÁVEL E... 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 estas questões, aliadas ao desejo crescente de se obterem aplicações que evoluam à medida que o domínio evolui, fizeram com que se pensasse em construir aplicações mais configuráveis, flexíveis e adaptáveis, permitindo que o sistema pudesse se adaptar, mais facilmente, às novas necessidades do domínio, acompanhando a evolução dos requisitos, porém, mantendo sua qualidade. Figura 1- Arquitetura simplificada do SICS. Fonte: adaptada de Rozenfeld(2002). 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. 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. Uma arquitetura de modelos de objetos adaptáveis (Adaptive Object_Model Architecture) é um tipo 120 da Vinci, Curitiba, v. 2, n. 1, p , 2005

5 ADRIANA CURSINO THOMÉ, MAURICIO G. V. FERREIRA, JOÃO BOSCO S. CUNHA particular de arquitetura reflexiva que abrange sistemas orientados a objetos que gerenciam elementos de algum tipo, e que podem ser estendidos para adicionar novos elementos (YODER,2001). Dessa forma, um modelo de objetos adaptável é um sistema que representa classes, atributos e relacionamentos como sendo metadados. Os usuários modificam os metadados (modelo de objetos) para refletir as mudanças no domínio. Essas mudanças modificam o comportamento do sistema. Em outras palavras, o sistema armazena o modelo de objetos em um banco de dados e o interpreta. Conseqüentemente, o modelo de objetos é ativo, e quando ele é modificado, o sistema muda imediatamente. Assim sendo, os metadados são usados em modelos de objetos adaptáveis para descrever o modelo em si. Desde que o sistema consiga interpretar os metadados para construir e manipular as descrições das classes do modelo em tempo de execução, torna-se fácil adicionar novas classes ao modelo de objetos adaptável, e torná-las imediatamente disponíveis para os usuários (JOHNSON,2002). Usar a abordagem dos modelos de objetos adaptáveis (AOMs) no desenvolvimento de sistemas pode amenizar alguns dos problemas que vêm sendo encontrados pelos desenvolvedores de software, principalmente em relação à flexibilidade, evolução e manutenção do sistema, permitindo que o custo total do desenvolvimento e manutenção possa ser reduzido (LECDEZI,2000). 2 A ARQUITETURA SICSDA O objetivo da arquitetura SICSDA é 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 deseja-se monitorar em um determinado instante. É 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. A arquitetura SICSDA modela a aplicação para o controle de satélites baseando-se nos modelos de objetos adaptáveis (AOMs). Isso significa que nesta arquitetura os objetos do domínio do problema, por exemplo, telemetria, telecomando, ranging; ao invés de estarem localizados no código que implementa a aplicação, estão armazenados em um banco de dados para que possam ser instanciados em tempo de execução. Isto significa que o sistema tem um código genérico implementado em uma linguagem de programação orientada a objetos, que representa o metamodelo para as classes do domínio do problema do Sistema de Controle de Satélites. Esse código genérico (metamodelo) deve ser capaz de acomodar os diferentes modelos de objetos (metadados) dos vários satélites. A arquitetura SICSDA, principalmente por questões de tolerância às falhas, é distribuída, e as funcionalidades oferecidas pela aplicação, por exemplo, visualização de telemetria, emissão de telecomando, podem estar distribuídas dentro de um domínio de rede pré-definido. Isso significa que os objetos da aplicação podem ser instanciados em máquinas diferentes 121 da Vinci, Curitiba, v. 2, n. 1, p ,

6 UMA ARQUITETURA DE SOFTWARE DISTRIBUÍDA, CONFIGURÁVEL E... na rede, ocasionando, portanto, uma distribuição do código do sistema. O middleware é responsável por prover a localização desses objetos, ou seja, em que máquina da rede eles estão disponíveis. Pode-se dizer que a arquitetura SICSDA é adaptável porque é possível, em tempo de execução, alternar entre os metadados dos diversos satélites, ocasionando uma instancialização de um novo modelo de objetos em cima do metamodelo cada vez que uma troca de contexto desse tipo for requisitada pelo usuário, ou seja, cada vez que se desejar controlar outro satélite. Pode-se dizer ainda que a arquitetura SICSDA é adaptável, porque é capaz de acomodar possíveis mudanças no domínio do problema através da configuração apropriada dos metadados, permitindo que se possa acompanhar a evolução dos requisitos do domínio, e adaptando-se às necessidades dos usuários. Dessa forma, os especialistas do domínio (controladores de satélites e engenheiros de satélites) e os desenvolvedores do software podem adaptar o sistema para acomodar novas classes através da criação, em tempo de execução, dessas classes e seus atributos. Pode-se dizer que a arquitetura SICSDA é configurável em relação às regras de negócio, pois é possível que novas regras de negócio (ou novos métodos) sejam associadas a uma classe do domínio em tempo de execução. A Figura 2 ilustra a estrutura e o funcionamento da arquitetura SICSDA. A seguir são detalhados os elementos que aparecem na Figura 2. Figura 2 - Arquitetura SICSDA. - Aplicação Distribuída para o Controle de Satélites: contém os objetos do software aplicativo que realiza o controle dos satélites (telecomando, ranging, telemetria etc.). - Serviço de Persistência: é responsável por armazenar e recuperar do banco de dados os metadados do sistema. Adicionalmente, ele é responsável por armazenar e recuperar de uma base de dados chamada de Base de Configurações, os dados de autenticação dos usuários e os dados da configuração dos objetos nos nós onde a arquitetura SICSDA está implantada. 122 da Vinci, Curitiba, v. 2, n. 1, p , 2005

7 ADRIANA CURSINO THOMÉ, MAURICIO G. V. FERREIRA, JOÃO BOSCO S. CUNHA - Serviço de Configuração: faz parte da camada de apresentação do sistema e é responsável por manter os metadados do sistema e por manter a configuração dos objetos nos nós onde a arquitetura SICSDA está implantada. Deve oferecer aos especialistas do domínio e desenvolvedores de software uma interface adequada para que eles realizem tal tarefa. - Serviço de Carga: é responsável por dar a carga inicial do sistema, ou seja, executar a rotina de carga do sistema nos nós onde a arquitetura SICSDA foi implantada. - Serviço de Usuário: faz parte da camada de apresentação do sistema e é responsável por oferecer aos especialistas do domínio a interface adequada para a visualização de telemetria, emissão de telecomando, obtenção de medidas de distância e calibração etc, do satélite desejado. Além disso, ele deve prover aos usuários a interface para a autenticação no sistema. - Serviço de Adaptação: é responsável por prover o metamodelo que permitirá com que efetivamente os objetos trazidos do banco de dados sejam instanciados, e que possam ser modificados em tempo de execução. - Simulador de Satélites: é o software que simula a interação com os satélites, ou seja, que simula a chegada e envio de dados dos/para os satélites. 3 RESULTADOS OBTIDOS Baseando-se no diagrama de classes que representa as classes do domínio do problema dos satélites SCD1, SCD2 e CBERS2, mostrado na Figura 3, pode-se obter um diagrama de classes genérico que representa o metamodelo para as classes do domínio do problema do Sistema de Controle de Satélites. Esse metamodelo é apresentado na Figura 4. Ele foi obtido através da aplicação de uma seqüência de design patterns: pattern TypeObject, pattern Property, pattern Accountability e pattern Strategy. Mais informações sobre esses design patterns podem ser encontradas em JOHNSON(2002) e YODER(2001). 123 da Vinci, Curitiba, v. 2, n. 1, p ,

8 UMA ARQUITETURA DE SOFTWARE DISTRIBUÍDA, CONFIGURÁVEL E... Figura 3 Diagrama de classes para os satélites SCD1, SCD2 e CBERS da Vinci, Curitiba, v. 2, n. 1, p , 2005

9 ADRIANA CURSINO THOMÉ, MAURICIO G. V. FERREIRA, JOÃO BOSCO S. CUNHA Figura 4 Diagrama de classes genérico. Após a obtenção do diagrama de classes genérico apresentado na Figura 4, direcionouse o metamodelo para a plataforma de implementação adotada. Como foi estabelecido o J2EE como plataforma de implementação, cada classe apresentada no diagrama de classes da Figura 4 foi representada na Figura 5 como sendo um Enterprise Java Bean de entidade. 125 da Vinci, Curitiba, v. 2, n. 1, p ,

10 UMA ARQUITETURA DE SOFTWARE DISTRIBUÍDA, CONFIGURÁVEL E... sateliteentitybean 1 codigo : integer nome : String num_frames : integer subsistemaentitybean 1..* nome : String <<findermethod>> findsat() codigosatelite : integer <<findermethod>> findsub() 1..* 1 1..* mensagementitybean nome : String codigoframe : integer nomesubsistema : String tipomensagem : String 1..* frameentitybean estacaoentitybean data : String nome : String hora : String latitude : float codigo : integer longitude : float 1..* 1 nomeestacao : String codigosatelite : integer <<findermethod>> findestacao() <<findermethod>> findframe() 1 propriedadeentitybean nome : String tipo : String valor : String nomemensagem : String tipopropriedade : String <<findermethod>> findprop() 1 est_tipopropentitybean nometipoprop : String nomeestrategia : String <<findermethod>> findest_tp() <<findermethod>> findmens() 1 tipomensagementitybean 1 nome_tipomensagem : String tipotipomensagem : String est_tipomensentitybean nomemensagem : String nomeestrategia : String <<findermethod>> findest_tipom() > tipodepropriedadeentitybean nome : String tipo : Type tipomensagem : String tipotipomensagem : String <<findermethod>> findtprop() <<findermethod>> findtipomens() 1 1 tipotipomensagementitybean nome_tipotipo : String 1 estrategiaentitybean nome : String <<findermethod>> findest() <<findermethod>> findttmens() 1 est_tipotipomensentitybean relacionamentoentitybean classe1 : String classe2 : String tipo : String nomemensagem : String tipoderelacionamentoentitybean nome : String classe1 : String classe2 : String multiplicidade1 : String multiplicidade2 : String tipomensagem : String nometipotipo : String nomeestrategia : String <<findermethod>> findest_tm() <<findermethod>> findrel() 1 tipotipomensagem : String <<findermethod>> findtiporel() Figura 5 - Diagrama de classes genérico direcionado para J2EE. 126 da Vinci, Curitiba, v. 2, n. 1, p , 2005

11 ADRIANA CURSINO THOMÉ, MAURICIO G. V. FERREIRA, JOÃO BOSCO S. CUNHA O ambiente para o protótipo da arquitetura SICSDA foi desenvolvido usando-se a linguagem Java versão 1.4.1, o banco de dados Caché, versão 5.0.5, o ambiente de desenvolvimento Jbuilder versão X, e o servidor de aplicações J2EE Jboss versão O metamodelo foi representado no banco de dados, e os metadados para cada satélite puderam ser armazenados através de uma interface gráfica disponibilizada pelo Serviço de Configuração. Através dessa interface, é possível realizar alterações em tempo de execução nas classes e seus atributos armazenados, e também associar novos métodos às classes. A tela principal do Serviço de Configuração desenvolvida para o protótipo é mostrada na Figura 6. Povoou-se o banco de dados com os metadados dos satélites usando-se a interface do Serviço de Configuração. Os metadados inseridos basearam-se, na medida do possível, em valores aproximados aos usados pelos sistemas de controle reais. A seguir, a título de exemplo, são apresentados os dados inseridos para a classe Estação no banco de dados Caché e também para a classe TipoMensagem, nas Figuras 7 e 8, respectivamente. Figura 6 Tela principal do Serviço de Configuração. Figura 7 Dados de Estação. Figura 8 Dados de TipoMensagem. 127 da Vinci, Curitiba, v. 2, n. 1, p ,

12 UMA ARQUITETURA DE SOFTWARE DISTRIBUÍDA, CONFIGURÁVEL E... O usuário interage com o sistema para a realização de alguma funcionalidade, por exemplo, Visualizar Telemetria, Enviar Telecomando ou Obter Medidas, através da interface provida pelo Serviço de Usuário. A Figura 9 ilustra o pedido de visualização de telemetrias para o satélite SCD1. As telemetrias recuperadas são apresentadas na caixa ao lado dos botões. Figura 9 Visualizando telemetrias para o satélite SCD1. Dessa forma é possível, dependendo do satélite que se deseja operar, solicitar uma operação ao sistema e recuperar os valores associados a essa operação. Essa operação é, na verdade, invocada dinamicamente, pois o nome e as informações sobre seus parâmetros e valores de retorno só são conhecidos em tempo de execução. Assim, é possível associar métodos já criados a novos tipos de mensagens, o que significa que é possível, até certo ponto, alterar o comportamento do sistema em tempo de execução, uma vez que, se um determinado tipo de mensagem for associado a um determinado método em tempo de execução, esse tipo de mensagem poderá solicitar a execução dessa operação. Na Figura 10 pode-se visualizar o diagrama de seqüência que representa a realização dessas operações no sistema. Deve-se observar que, em virtude das classes do metamodelo serem genéricas, apenas um diagrama de seqüência foi necessário para representar a realização das operações citadas. 128 da Vinci, Curitiba, v. 2, n. 1, p , 2005

13 ADRIANA CURSINO THOMÉ, MAURICIO G. V. FERREIRA, JOÃO BOSCO S. CUNHA Figura 10 Diagrama de seqüência genérico. 129 da Vinci, Curitiba, v. 2, n. 1, p ,

14 UMA ARQUITETURA DE SOFTWARE DISTRIBUÍDA, CONFIGURÁVEL E... 4 CONCLUSÕES Apesar de muitos aspectos apontarem para o fato de que, pelos menos inicialmente, as arquiteturas baseadas em AOMs exigem mais esforço para serem construídas, pretende-se com este trabalho dar um passo significativo em direção à melhoria da reusabilidade e alterabilidade do Sistema de Controle de Satélites, já que os sistemas adaptáveis têm a característica de acompanhar mais facilmente a evolução dos requisitos do negócio. Na verdade, o esforço para se realizarem alterações em sistemas desse tipo pode ser bastante minimizado, já que alterações no código podem ser reduzidas substancialmente. Adicionalmente, com este tipo de arquitetura pode-se permitir que os próprios especialistas do domínio realizem algumas alterações, melhorando a alterabilidade e diminuindo a intervenção dos desenvolvedores do software na evolução do sistema. Além disso, com esse tipo de arquitetura pode-se dar um passo em relação à melhoria do fator economicidade do Sistema de Controle de Satélites, uma vez que futuras missões poderão aproveitar quase todo o investimento de hardware e software já feito em outras missões. O trabalho aqui descrito une, portanto, áreas que normalmente são exploradas de forma independente, trazendo para si uma característica multidisciplinar, ou seja, possibilitando a integração e colaboração da área de sistemas distribuídos, modelos de objetos adaptáveis e engenharia de software. Além disso, o trabalho 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, propostas em FERREIRA(2001) e CU- NHA(1997), respectivamente. O trabalho desenvolvido originou a tese expressa em THOMÉ(2004)(e) e, atualmente, já foi apresentado e/ou publicado em THOMÉ(2003)(a), THOMÉ(2003)(b), THOMÉ(2004)(c) e THOMÉ(2004)(d); e originou os trabalhos sendo desenvolvidos em ALMEIDA(2004) e CARDOSO(2004). Espera-se, desta forma, colaborar, mesmo que de forma modesta, para o avanço da pesquisa no Brasil, e para o sucesso da missão espacial brasileira, oferecendo uma nova alternativa para a arquitetura do software para o controle de satélites, e, principalmente, abrindo novos campos de estudo em direção aos sistemas adaptáveis. 130 da Vinci, Curitiba, v. 2, n. 1, p , 2005

15 ADRIANA CURSINO THOMÉ, MAURICIO G. V. FERREIRA, JOÃO BOSCO S. CUNHA REFERÊNCIAS BIBLIOGRÁFICAS ALMEIDA, W. R. Uma abordagem para a persistência dos modelos de objetos de sistemas distribuídos, configuráveis e adaptáveis. São José dos Campos, Dissertação (Mestrado em Computação Aplicada) - Instituto Nacional de Pesquisas Espaciais (INPE). CARDOSO, P. E. Modelo de objetos dinâmico aplicado ao processamento de telemetrias de satélites. São José dos Campos, Dissertação (Mestrado em Computação Aplicada) - Instituto Nacional de Pesquisas Espaciais (INPE). CUNHA, J. B. S. Uma abordagem de qualidade e produtividade para desenvolvimento de sistemas de software complexos utilizando a arquitetura de placa de software: softboard. São José dos Campos, Tese (Doutorado em Computação Aplicada) - Instituto Nacional de Pesquisas Espaciais (INPE). FERREIRA, M.G.V. Uma arquitetura flexível e dinâmica para objetos distribuídos aplicada ao software de controle de satélites. São José dos Campos, Tese (Doutorado em Computação Aplicada) - Instituto Nacional de Pesquisas Espaciais (INPE). JOHNSON, R.; YODER, J. W. The adaptive object-model architectural style. In: IEEE/IFIP CONFERENCE ON SOFTWARE ARCHITECTURE, 2002, Canada. Anais... LEDECZI, A. et al. Synthesis of self-adaptive software. IEEE Areospace Conference Proceedings, v. 4, p , ROZENFELD, P.; Orlando, V.; Ferreira, M.G.V. Applying the 21th century technology to the 20th century mission control. In: SPACE OPS 2002, USA. Anais... USA, THOMÉ, A. C. et al. SICSDA An adaptive configurable distributed software architecture applied to satellite control missions. In: SBES - SIMPÓSIO BRASILEIRO DE ENGE- NHARIA DE SOFTWARE, 17., WORKSHOP DE TESES EM ENGENHARIA DE SOFTWARE, 2003, Manaus. Anais... Manuas, THOMÉ, A.C.et. al. Uma arquitetura de software distribuída, configurável e adaptável aplicada às várias missões de controle de satélites (SICSDA). In: WORKSHOP DOS CURSOS DE COMPUTAÇÂO APLICADA DO INPE, 3., 2003, São José dos Campos. Anais... São José dos Campos, THOMÉ, A. C. et al. Establishing an adaptive configurable distributed software architecture applied to satellite control missions. In: INTERNATIONAL CONFERENCE ON SPACE OPERATIONS, 8., SPACEOPS 2004, Montreal. Anais... Montreal, THOMÉ, A. C. et al. SICSDA: an adaptive configurable distributed software achitecture applied to satellite control missions. In: EUROPEAN CONFERENCE ON OBJECT- ORIENTED PROGRAMMING - ECOOP 2004, 18. Oslo. Anais... Oslo, da Vinci, Curitiba, v. 2, n. 1, p ,

16 UMA ARQUITETURA DE SOFTWARE DISTRIBUÍDA, CONFIGURÁVEL E... 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. São José dos Campos, Tese (Doutorado em Computação Aplicada) - Instituto Nacional de Pesquisas Espaciais (INPE). YODER, J. W. et al. Architecture and design of adaptive object-models. ACM Sigplan Notices. v. 36, n. 12, p , December da Vinci, Curitiba, v. 2, n. 1, p , 2005