See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/47618981

Uma arquitetura de software distribuída, configurável e adaptável

aplicada às várias missões de controle de satélites (SICSDA)

Article
Source: OAI

CITATIONS READS
0 198

3 authors:

Adriana Thomé Maurício Gonçalves Vieira Ferreira

University of Oxford National Institute for Space Research, Brazil
7 PUBLICATIONS 7 CITATIONS 99 PUBLICATIONS 138 CITATIONS

SEE PROFILE SEE PROFILE

Jbosco Scunha
Universidade Federal de Itajuba
4 PUBLICATIONS 7 CITATIONS

SEE PROFILE

All content following this page was uploaded by Maurício Gonçalves Vieira Ferreira on 31 March 2015.

The user has requested enhancement of the downloaded file.

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

da Vinci
da Vinci
, Curitiba,
, Curitiba,
v. 2v., n.
2 ,1,n.p.1,105-116,
p. 1-208,2005
2005 117
 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 ofereci-
das 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 siste-
ma 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. 117-132, 2005

 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 apli-
cada às várias missões de controle de satélites”, realizada no Instituto Nacional de Pesquisas
Espaciais (INPE) e concluída em novembro de 2004.
O Instituto Nacional de Pesquisas Espacias (INPE), como uma das principais organi-
zaçõ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 com-
preende 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 desen-
volvido 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

da Vinci , Curitiba, v. 2 , n. 1, p. 117-132, 2005 119

 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, ocasionan-
do um grande esforço despendido para que as novas características pudessem ser incorpora-
das 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 evolu-
am à 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 facil-
mente, à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 rapida-
mente à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 adicio-
nal, 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. 117-132, 2005

 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 des-
crever 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 adici-
onar 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 da-
dos 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 Contro-
le 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é-defini-
do. Isso significa que os objetos da aplicação podem ser instanciados em máquinas diferentes

da Vinci , Curitiba, v. 2 , n. 1, p. 117-132, 2005 121

 UMA ARQUITETURA DE SOFTWARE DISTRIBUÍDA, CONFIGURÁVEL E...

na rede, ocasionando, portanto, uma distribuição do código do sistema. O middleware é res-

ponsá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 acomo-
dar 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 armaze-
nar 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. 117-132, 2005

 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 espe-
cialistas 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 proble-

ma 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 encon-
tradas em JOHNSON(2002) e YODER(2001).

da Vinci , Curitiba, v. 2 , n. 1, p. 117-132, 2005 123

 UMA ARQUITETURA DE SOFTWARE DISTRIBUÍDA, CONFIGURÁVEL E...

Figura 3 – Diagrama de classes para os satélites SCD1, SCD2 e CBERS2.

124 da Vinci , Curitiba, v. 2 , n. 1, p. 117-132, 2005

 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, direcionou-

se 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.

da Vinci , Curitiba, v. 2 , n. 1, p. 117-132, 2005 125

 UMA ARQUITETURA DE SOFTWARE DISTRIBUÍDA, CONFIGURÁVEL E...

<<<entity>> <<<entity>> <<<entity>>

sateliteEntityBean 1 frameEntityBean estacaoEntityBean
codigo : integer data : String nome : String
1..*
nome : String hora : String latitude : float
num_frames : integer <<<entity>> codigo : integer longitude : float
nomeEstacao : String
1..* 1
subsistemaEntityBean
<<createMethod>> create() codigoSatelite : integer <<createMethod>> create()
1..* nome : String
<<finderMethod>> findSat() codigoSatelite : integer <<finderMethod>> findEstacao()
<<createMethod>> create()
<<finderMethod>> findFrame()
<<createMethod>> create()
<<finderMethod>> findSub()
1 <<<entity>>
propriedadeEntityBean <<<entity>>
est_tipoPropEntityBean
nome : String
tipo : String 0..* nomeTipoProp : String
1..*
valor : String nomeEstrategia : String
1 <<<entity>> nomeMensagem : String
1..*
mensagemEntityBean tipoPropriedade : String <<createMethod>> create()
nome : String <<finderMethod>> findEst_TP()
codigoFrame : integer <<createMethod>> create()
nomeSubsistema : String 0..* <<finderMethod>> findProp()
tipoMensagem : String 1

<<createMethod>> create() <<<entity>> <<<entity>>>

<<finderMethod>> findMens() est_tipoMensEntityBean tipoDePropriedadeEntityBean

nomeMensagem : String nome : String

0..* nomeEstrategia : String tipo : Type
tipoMensagem : String
1 <<createMethod>> create() tipoTipoMensagem : String

<<<entity>> <<finderMethod>> findEst_TipoM()

<<createMethod>> create()
tipoMensagemEntityBean 1 <<finderMethod>> findTProp()
nome_tipoMensagem : String 0..* 0..*
tipoTipoMensagem : String
0..*
<<createMethod>> create() 0..*
<<finderMethod>> findTipoMens() 0..*
<<<entity>>
1 0..* estrategiaEntityBean
0..* 1
<<<entity>> nome : String
1
tipoTipoMensagemEntityBean
<<createMethod>> create()
nome_tipoTipo : String
<<finderMethod>> findEst()

<<createMethod>> create()
<<finderMethod>> findTTMens() 0..* 0..*

1
<<<entity>>
0..* est_tipoTipoMensEntityBean
<<<entity>> nomeTipoTipo : String
tipoDeRelacionamentoEntityBean nomeEstrategia : String
<<<entity>>
relacionamentoEntityBean nome : String
<<createMethod>> create()
classe1 : String
classe1 : String <<finderMethod>> findEst_TM()
0..* classe2 : String
0..* classe2 : String
multiplicidade1 : String
tipo : String multiplicidade2 : String
nomeMensagem : String
0..*
tipoMensagem : String
tipoTipoMensagem : String
<<createMethod>> create() 1
<<finderMethod>> findRel()
<<createMethod>> create()
<<finderMethod>> findTipoRel()

Figura 5 - Diagrama de classes genérico direcionado para J2EE.

126 da Vinci , Curitiba, v. 2 , n. 1, p. 117-132, 2005

 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 desenvolvi-
mento Jbuilder versão X, e o servidor de aplicações J2EE Jboss versão 3.0.8.
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 medi-
da do possível, em valores aproximados aos
usados pelos sistemas de controle reais. A
seguir, a título de exemplo, são apresenta-
dos 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”.

da Vinci , Curitiba, v. 2 , n. 1, p. 117-132, 2005 127

 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 determina-
do 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. 117-132, 2005

 ADRIANA CURSINO THOMÉ, MAURICIO G. V. FERREIRA, JOÃO BOSCO S. CUNHA

Figura 10 – Diagrama de seqüência genérico.

da Vinci , Curitiba, v. 2 , n. 1, p. 117-132, 2005 129

 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 carac-
terí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 inter-
vençã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, possibili-
tando a integração e colaboração da área de sistemas distribuídos, modelos de objetos adap-
tá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, atualmen-
te, 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 alter-
nativa 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. 117-132, 2005

 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 sis-
temas distribuídos, configuráveis e adaptáveis. São José dos Campos, 2004. 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, 2004. 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, 1997. Tese (Doutorado em Computação Aplicada) - Institu-
to Nacional de Pesquisas Espaciais (INPE).

FERREIRA, M.G.V. Uma arquitetura flexível e dinâmica para objetos distribuídos apli-
cada ao software de controle de satélites. São José dos Campos, 2001. 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. 501-507, 2000.

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 , 2002.

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, 2003.

THOMÉ, A.C.et. al. Uma arquitetura de software distribuída, configurável e adaptável aplica-
da à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, 2003.

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 , 2004.

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, 2004.

da Vinci , Curitiba, v. 2 , n. 1, p. 117-132, 2005 131

 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, 2004. Tese (Douto-
rado 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. 50-60, December 2001.

132 da Vinci , Curitiba, v. 2 , n. 1, p. 117-132, 2005

View publication stats