p.gina de rosto.doc -...
262
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
-
Upload
phungnguyet -
Category
Documents
-
view
231 -
download
0
Transcript of p.gina de rosto.doc -...
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.
Aluno (a): Adriana Cursino Thomé
São José dos Campos, 30 de novembro de 2004
Aprovado (a) pela Banca Examinadora emcumprimento ao requisito exigido paraobtenção do Título de Doutorado emComputação Aplicada
“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
persistência...............................................................................................
157
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
adaptação..................................................................................................
162
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
25
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).
26
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
27
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
28
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. É
29
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.
30
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).
31
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.
32
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
33
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”
34
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:
35
• 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:
36
• 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.
37
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).
38
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.
39
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;
40
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.
41
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
42
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.
43
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.
44
• 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).
45
• 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
46
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.
FIGURA 2.2 – A arquitetura SOFTBOARD.
FONTE: Adaptada de Cunha (1997).
CIH
CGT
CGD CIS
CMOOS
CDP CDP
CatálogoBD Outros
Sistemas
47
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.
48
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.
APLICAÇÃO
Serviço dosAgentes
Serviço dePersistência
Serviço deSegurança
Fig. 6.2 Um a visão dos serviços da arquitetura SICSD.
Serviço deBalanceam ento
objetos daaplicação
ORB(CORBA)
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
FIGURA 2.3 - Uma visão dos serviços da arquitetura SICSD.
FONTE: Adaptada de Ferreira (2001).
Middleware
49
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.
• •
• • • •
tele-metria 01
tele-metria N
Usuários Esta- ção N
Ran-ging
tele-comandos 01
Simu-lador
Equi-pamen-to
Middleware
tele-comandos N
Esta- ção 01
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
FIGURA 2.4 – A arquitetura SICSD e seus objetos.
FONTE: Ferreira (2001).
50
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
51
auxílio dos telecomandos pode-se alterar o estado de um satélite (ligar ou desligar
uma determinada chave). Portanto, além do estado de um satélite, esse objeto
encapsula os métodos para visualizar estes estados (recuperar telemetria) ou
modificá-los (enviar telecomando).
Os usuários interagem com os objetos distribuídos através de um middleware. O
middleware atende às solicitações de serviços dos usuários e se incumbe de localizar o
objeto capaz de atendê-las.
A replicação de um objeto em mais de um nó da rede está relacionada com o número de
usuários que utilizam os serviços disponíveis desse objeto, bem como com a
necessidade de disponibilidade de um determinado serviço em caso de falha.
Atualmente, está operando no CCS um protótipo que implementa a arquitetura SICSD
que utiliza a plataforma de localização e distribuição de objetos J2EE (Java 2
Enterprise Edition).
2.5- Projeto Multi-Missão do INPE
O INPE, visando aproveitar o esforço despendido no projeto e na construção dos
equipamentos que compõe um satélite, 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).
O conceito de plataforma multi-missão está relacionado à capacidade de suportar uma
variedade de missões usando a mesma plataforma básica (ou módulo de serviço) em que
diferentes instrumentos de payload (carga útil) podem ser acoplados. O parâmetro
principal do projeto da plataforma multi-missão é a modularidade, ou seja, permitir a
52
integração do módulo de payload dos vários satélites ao módulo de serviço,
independentemente de sua estrutura. A Figura 2.5 ilustra a disposição do módulo de
serviço MMP e dos vários módulos de payload.
FIGURA 2.5 – Integração do Módulo de Serviço MMP e dos Possíveis Módulos de
Payload.
A plataforma multi-missão deve suportar uma variedade de aplicações de observação da
Terra, ciência e comunicação de órbitas baixas, e por isso deve ser versátil o suficiente
para se adaptar às necessidades específicas de uma dada missão em termos de massa,
poder, propulsão e capacidade de armazenamento de dados.
Os seguintes subsistemas compõem a plataforma multi-missão (INPE,2001):
• Subsistema de Estrutura (Structure Subsystem): provê o suporte mecânico para
todos os subsistemas MMP, equipamentos de hardware e acessórios, e também o
suporte mecânico para o módulo de payload do satélite.
• Subsistema de Fornecimento de Energia (Power Supply Subsystem):
responsável por converter a energia solar em energia elétrica e armazená-la em
Módulo de Serviço MMP
Módulo de Payload
53
baterias, e por prover o controle e distribuição da energia para os vários
equipamentos e plataformas payload.
• Subsistema de Controle Térmico (Thermal Control Subsystem): responsável
por prover a distribuição do calor de forma que todos os equipamentos a bordo
operem dentro de seus limites de temperatura, sob todas as possíveis atitudes do
satélite a serem experimentadas durante a vida de uma missão.
• Subsistema de Controle de Atitude e Tratamento de Dados (Attitude Control
and data Handling Subsystem): responsável por prover o controle de atitude e
órbita e também por prover o processamento de dados, a capacidade de
armazenamento e o controle do equipamento MMP através de um computador de
bordo.
• Subsistema de Propulsão (Propulsion Subsystem): responsável por prover a
aquisição de órbita e manutenção.
• Subsistema de Telemetria e Telecomando (Telemetry and Telecommand
Subsystem): responsável por prover a comunicação entre a plataforma e as
estações terrenas de recebimento de telemetria e envio de telecomando, de forma a
assegurar a capacidade de monitorar e controlar o satélite durante as várias fases
da missão.
Dessa forma, o módulo de serviço MMP deve prover os seguintes serviços para o
módulo de payload (INPE,2001):
• Telemetria, telecomando e transmissão de dados através de linhas seriais
dedicadas;
• fornecimento de energia; e
54
• armazenamento de dados.
A título de ilustração, é apresentado na Figura 2.6 o diagrama de blocos do módulo de
serviço MMP.
FIGURA 2.6 - Diagrama de blocos da plataforma multi-missão MMP.
FONTE: INPE (2001).
A Figura 2.6 mostra, basicamente, o relacionamento entre os diversos equipamentos que
compõe a plataforma MMP. Ao centro tem-se o computador de bordo (Onboard
Computer – OBC) que é responsável por controlar os outros equipamentos.
A Unidade de Distribuição de Energia (Power Conditional Distribution Unit – PCDU),
gerencia o carregamento da bateria (batery) que, por sua vez, usa a energia solar obtida
através de painéis solares (Solar Panels). O Dispositivo de Direcionamento Solar (Solar
Array Drive Assembly – SADA), é responsável por girar os painéis solares de forma que
55
eles possam aproveitar ao máximo a incidência de luz do sol à medida que o satélite
percorre sua órbita.
A plataforma é composta também por um Global Position System (GPS) e por alguns
sensores, são eles: Sensor Solar (Solar Sensor), Sensor de Estrelas (Star Sensor),
Magnetômetro (Magnetometer) e o Giroscópio (GYRO Package). Esses equipamentos
têm, basicamente, a função de auxiliar no cálculo da posição da órbita do satélite.
O Equipamento de Telecomando e Telemetria (TT&C) é responsável por prover o
recebimento de telecomandos e o envio de telemetrias. As Rodas de Reação (Reaction
Wheels) e os Pontos de Torque (Torque Roots) são equipamentos relacionados ao
controle de atitude do satélite.
O módulo de serviço é composto também por um tanque (Tank), que armazena o
combustível necessário para que os motores (Thursters) possam fornecer empuxo para a
realização de manutenções de órbita.
Como se pode notar, ao propor a plataforma multi-missão MMP, o INPE demonstra 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.
56
57
CAPÍTULO 3 – COMPUTAÇÃO BASEADA EM OBJETOS DISTRIBUÍDOS
A tecnologia de distribuição de objetos dá a oportunidade de distribuir e globalizar, de
forma transparente, uma aplicação. Ela pode ser definida, de forma ampla, como a
agregação de três tecnologias: tecnologia de objetos, tecnologia de distribuição e
tecnologia web (Ferreira,2001).
A combinação do uso destas tecnologias mudou, de maneira fundamental, a forma
como os sistemas de software são construídos. Surgiu, dessa forma, um novo paradigma
em computação, cujo foco é a interoperabilidade de objetos, entendendo-se por
interoperabilidade a possibilidade de um programa, em um sistema, acessar programas e
dados em outros sistemas. Pode-se citar várias vantagens técnicas que advém deste novo
paradigma, como por exemplo:
• Empacotamento em objeto (object wrapper): esse empacotamento em objeto
consiste no encapsulamento de um conjunto de serviços providos por uma
aplicação não-orientada a objetos ou no encapsulamento de uma interface de
programa de maneira a poder tratar essa aplicação, ou interface, como um objeto.
Por exemplo, esse empacotamento poderá ser utilizado para criar uma interface
para uma aplicação legada, isto é, já existente, para que esta possa ser tratada
como um objeto. Desta forma, um sistema legado pode ser utilizado em um
ambiente distribuído encapsulado como um objeto, poupando o desenvolvimento
de um novo sistema orientado a objetos que ofereça as funcionalidades do sistema
já existente. Esse empacotamento pode também ser aplicado a vários recursos já
existentes, simplificando, assim, a comunicação entre eles através da rede.
58
• Distribuição dos objetos locais e remotos de uma determinada aplicação em
computadores que melhor realizem as tarefas a eles definidas: essa
distribuição pode ser feita sem a necessidade de se alterar a localização da
aplicação que se utiliza desses objetos. Por exemplo, um objeto que realiza uma
computação que exige bastante da Unidade Central de Processamento (UCP) pode
ser colocado em um computador mais rápido, enquanto objetos de apresentação
que interagem com o usuário, por exemplo, ficariam em uma estação de trabalho
mais lenta. Essa distribuição permite uma melhor utilização de recursos de
hardware.
• Facilidade na migração da implementação de um objeto de uma plataforma a
outra: isto é possível, pois os objetos, mesmo remotos, podem parecer como
sendo locais aos seus clientes. O cliente não sabe onde e em que tipo de máquina
realmente reside a implementação de um objeto utilizado por ele.
• Recursos de hardware e software disponíveis em plataformas heterogêneas
podem ser utilizados por uma aplicação: apesar disso, tem-se a imagem de um
sistema único que, na realidade, é formado por uma aplicação construída por
objetos distribuídos.
Dessa forma, a tecnologia de distribuição de objetos permite que:
• Objetos de uma aplicação possam residir em qualquer lugar da rede;
• serviços de persistência possam armazenar e recuperar objetos eficientemente;
59
• serviços de pesquisa possam localizar objetos apropriadamente, onde quer que eles
residam;
• serviços de segurança possam restringir o acesso a objetos sensíveis;
• serviços de concorrência possam prover isolamento de ações entre usuários; e
• serviços de transações possam coordenar atualizações em múltiplos objetos.
Pode-se dizer que um sistema baseado em objetos distribuídos, assim como qualquer
sistema distribuído, possui as seguintes características:
Distribuição: o sistema é executado numa rede de computadores independentes
e heterogêneos.
• Transparência: o sistema esconde o ambiente distribuído e outros detalhes
desnecessários ao usuário. Por exemplo, um sistema pode prover a característica
de transparência de localização e, com isso, o usuário não precisa se preocupar
com a localização física de um objeto para fazer uma invocação.
• Tolerância às falhas: a falha de um computador, ou de um objeto, representa
apenas uma falha parcial do sistema; sendo a perda restrita ao computador ou ao
objeto. O restante do sistema continua processando.
• Disponibilidade: o sistema assegura a disponibilidade dos objetos,
independentemente da ocorrência de falhas nos computadores.
60
• Autonomia dos objetos: o sistema permite ao criador do objeto especificar os
clientes autorizados a operar sobre ele, podendo-se criar, dessa forma, mecanismos
de proteção para os objetos.
• Concorrência no processamento: o sistema permite que objetos de um programa
possam ser atribuídos a múltiplos processadores, para que eles possam ser
executados concorrentemente.
• Concorrência nos objetos: um objeto pode atender a múltiplas invocações de
clientes concorrentemente.
Em sistemas distribuídos orientados a objetos, o mecanismo de gerenciamento de
objetos envolve:
Gerenciamento de transações: tem a função de gerenciar transações, onde uma
transação é uma coleção de operações que executa uma única função lógica numa
aplicação. As transações têm as seguintes propriedades:
Serialização: transações concorrentes são escalonadas de forma a serem
executadas seqüencialmente em alguma ordem.
Atomicidade: uma transação é completada de forma total ou é abortada.
Sincronização: tem a função de garantir que atividades de múltiplas transações
invocando o mesmo objeto, não conflitem ou interfiram entre si.
61
Segurança de acesso: tem a função de atribuir diferentes níveis de segurança aos
usuários para operar sobre diferentes conjuntos de objetos.
Confiabilidade de objetos: tem a função de detectar e recuperar objetos.
Geralmente, a confiabilidade de objetos é obtida por sistemas de recuperação de
falhas, podendo ocorrer de duas maneiras: (1) recuperar a falha ocorrida num
objeto ou (2) replicar os objetos em vários computadores e utilizar a cópia
disponível.
Uma outra função de um sistema distribuído orientado a objetos é gerenciar a invocação
entre objetos cooperantes. O sistema deve ser capaz de:
Localizar um determinado objeto: prover a propriedade de transparência de
localização, que possibilita a um cliente invocar um objeto sem conhecer a sua
localização.
Manipular as interações entre os objetos: quando um cliente faz uma
invocação sobre um objeto, o sistema é responsável por executar os passos
necessários para entregar o pedido para o objeto servidor especificado, e retornar o
resultado para o cliente.
Detectar falhas de invocação: detectar falhas de hardware ou software que
ocorram antes de uma invocação ser iniciada ou durante a execução de uma
invocação.
Além disso, um sistema distribuído orientado a objetos deve prover mecanismos para
gerenciar os recursos físicos da rede, que incluem:
62
Persistência: um objeto tem seus dados persistentes quando os armazena num
meio relativamente permanente, como, por exemplo, um disco. Tornar os dados do
objeto persistentes significa que é possível ao objeto parar de executar e na
próxima instanciação utilizar os dados persistentes anteriormente armazenados.
Balanceamento de carga: o principal objetivo do balanceamento de carga é
maximizar a taxa de resposta do sistema. Isto pode ser obtido de duas formas: (1)
os objetos podem ser atribuídos a processadores que estão mais ociosos para que
eles trabalhem concorrentemente ou (2) objetos que interajam freqüentemente
podem ser atribuídos ao mesmo processador, ou a processadores próximos para
reduzir o custo de comunicação entre eles.
Para que todas estas características de um sistema distribuído orientado a objetos sejam
transparentes ao usuário, deve haver um meio que permita que diferentes objetos se
comuniquem entre si, de forma que eles não precisem conhecer detalhes de localização
e implementação uns dos outros. Isto é possível com a utilização da tecnologia
middleware.
Um middleware é, na verdade, um software de conectividade que consiste de um
conjunto de serviços, que permite a interação, através da rede, de múltiplos processos
em execução em uma ou mais máquinas. Esse software se localiza entre a aplicação e o
sistema operacional, e oferece serviços como:
Ir ao encontro de uma grande variedade de aplicações: por exemplo, ser
capaz de traduzir ou facilitar a adição de mensagens de vários formatos a serem
utilizadas em diversas aplicações.
63
Ser implementado de forma a possibilitar a execução em plataformas
distintas: por exemplo, em sistemas distribuídos, as aplicações localizadas em
diferentes plataformas podem usar o serviço middleware para se comunicar e/ou
trocar dados, aumentando assim a interoperabilidade.
Possibilitar o acesso remoto: possibilitar que ele seja acessado remotamente por
outros serviços ou aplicações.
Suportar um protocolo padrão: por exemplo, Transmission Control
Protocol/Internet Protocol (TCP/IP) ou International Standards Organization
(ISO) Open System Interconnect (OSI).
A seguir é descrita, brevemente, uma das principais plataformas existentes atualmente
no mercado que incorpora o uso de middlewares: o Java 2 Enterprise Edition (J2EE) da
Sun Microsystems.
3.1- Plataforma J2EE
A plataforma J2EE, criada a partir da linguagem de programação Java e de tecnologias
Java, é um padrão para a produção de aplicativos corporativos seguros, escaláveis e
altamente disponíveis. O padrão define quais serviços devem ser fornecidos pelos
servidores que suportam J2EE. Esses servidores fornecerão contêineres J2EE nos quais
os componentes J2EE serão executados, ou seja, os contêineres fornecerão um conjunto
definido de serviços para os componentes (Bond, 2003).
A especificação da plataforma J2EE inclui uma grande variedade de Application
Programming Interfaces (APIs) e abordagens de programação (EJB, JSP, Servlets, entre
outras) para o desenvolvimento de aplicativos.
64
A seguir, são apresentados mais detalhes a respeito da arquitetura e dos serviços
oferecidos pelo J2EE.
3.1.1- As Camadas Físicas e Lógicas do J2EE
A arquitetura J2EE está centrada no modelo de três camadas físicas (3-tier), como
ilustra a Figura 3.1.
FIGURA 3.1 – Modelo de três camadas físicas.
FONTE: Adaptada de Bond (2003).
Este modelo divide um aplicativo de forma que a lógica do negócio resida entre a
camada da Lógica da Apresentação (que determina como o usuário interage com o
aplicativo e como as informações são apresentadas) e a camada da Lógica de Acesso
aos Dados (que governa a conexão com todas as fontes de dados usadas pelo
aplicativo). Esta camada pode ser chamada de camada física intermediária, camada
física do negócio ou camada física de Enterprise Java Beans (EJBs).
Dessa forma, a lógica da apresentação está separada em sua própria camada lógica e em
uma camada física própria. Isso significa que diferentes tipos de lógicas de
apresentação, podem acessar a mesma lógica do negócio na camada física intermediária.
A separação em camadas lógicas torna os sistemas mais flexíveis, de modo que as
partes podem ser alteradas independentemente. A separação em camadas físicas
distintas oferece a oportunidade de injetar maior flexibilidade e disponibilidade, através
da duplicação de máquinas e software em diferentes camadas físicas.
Lógica de Apresentação
Lógica do Negócio
Lógica deAcesso a Dados Banco de
Dados
65
3.1.2- Componentes e Contêineres
O J2EE especifica que um servidor de aplicativos compatível com J2EE deve fornecer
um conjunto definido de contêineres para abrigar os componentes J2EE. Os contêineres
fornecem um ambiente em tempo de execução para os componentes. Desse modo, a
Java 2 Platform Standard Edition (J2SE) que é uma linguagem independente de
plataforma, está disponível em cada contêiner. As APIs também estão disponíveis para
fornecer comunicação entre componentes, persistência, localização de serviços, etc. Os
contêineres são implementados pelos fornecedores de servidor de aplicativos.
Diferentes componentes realizam diferentes tarefas, portanto, eles exigem diferentes
contêineres. Um provedor de produtos pode fornecer qualquer um dos seguintes
contêineres: (1) contêiner de applet, (2) contêiner de clientes de aplicativo; (3) contêiner
web, (4) contêiner de EJBs, (5) contêiner de JSPs e (6) contêiner de servlets. Todos
esses contêineres devem fornecer, aos componentes que abrigam, certos serviços e
protocolos de comunicação, além de dar acesso a certas APIs J2EE.
Existem dois tipos de componentes distribuídos, gerenciados e executados em um
servidor J2EE (Bond, 2003):
• Componentes Web: um componente web interage com um cliente com base na
web, como um navegador da web. Há dois tipos de componentes web no J2EE: (1)
componentes servlet e (2) componentes JSP (Java Server Pages). Os dois tipos
manipulam apresentação de dados para o usuário.
• Componentes EJB: existem 3 tipos de componentes Enterprise JavaBean: (1)
beans de sessão; (2) beans de entidade e (3) beans dirigidos por mensagens.
A Figura 3.2 a seguir mostra os relacionamentos entre os diferentes contêineres e
componentes no ambiente J2EE.
66
FIGURA 3.2 – Arquitetura Lógica da plataforma J2EE.
FONTE: Bond (2003).
3.1.2.1- Componentes EJB
Em um aplicativo corporativo típico construído na plataforma J2EE, a lógica do negócio
é encapsulada em EJBs. É possível usar outros tipos de componentes ou objetos Java
puros para implementar lógica do negócio, mas os EJBs fornecem uma maneira
conveniente de encapsular e compartilhar lógica do negócio comum, assim como tirar
proveito dos serviços fornecidos pelo contêiner de EJBs. Assim, o modelo EJB faz uso
de dois mecanismos encontrados no J2SE: a Remote Method Invocation (RMI) e a Java
Naming and Directory Interface (JNDI )para facilitar a interação entre o EJB e seu
cliente.
Quando um EJB é criado, a funcionalidade que ele oferece para os clientes é definida
como uma interface remota RMI. Quando um EJB é implantado, sua localização é
registrada no serviço de atribuição de nomes. Então, um cliente usará a JNDI para
procurar a localização do EJB, interagindo com um objeto-fábrica, chamado de base do
EJB´s home (EJB), para obter uma instância do EJB. Isso é equivalente ao uso de new
Servidor J2EE
Contêiner Web
Servlet Página JSP
Contêiner EJBs
Bean Corporativo
Bean Corporativo
Banco de Dados
Navegador
Contêiner de Clientes de Aplicativo
Cliente de Aplicativo
67
para criar uma instância de um objeto local. Quando o cliente tem uma referência para o
EJB, ele pode usar a funcionalidade do negócio oferecida pelo EJB. Essa seqüência é
apresentada na Figura 3.3.
FIGURA 3.3 – Um cliente usa a JNDI e a RMI para acessar um EJB.
FONTE: Adaptada de Bond (2003).
Como diferentes componentes corporativos são chamados para se comportar de
diferentes maneiras, existem vários tipos de EJBs definidos, que podem ser usados para
encapsular diferentes partes da lógica do negócio de um aplicativo. São eles:
• Beans de sessão: um bean de sessão é destinado a encapsular um conjunto de
funções corporativas comuns. Esses EJBs oferecem uma interface síncrona através
da qual o cliente pode usar a lógica do negócio. Os dados que um bean de sessão
contém tenderão a ser temporários (relevantes apenas para a sessão de usuário
corrente), em vez de persistentes. Se um bean de sessão quiser obter dados de um
banco de dados, ele poderá usar chamadas Java DataBase Connectioni (JDBC).
Como alternativa, os dados do aplicativo podem ser obtidos através de EJBs de
entidade.
3- Chama métodos do negócio
2- Obtém a instância
Contêiner EJB
Componente
Fábrica
Bean Corporativo
Base
Cliente
BD
Contêiner Cliente
RMI
RMI
1- Consulta EJB
68
• Beans de entidade: um bean de entidade é uma representação de algum dado
corporativo. Esses objetos corporativos representam os principais dados
manipulados durante os processos corporativos. Os beans de entidade oferecem
uma interface síncrona através da qual o cliente pode acessar seus dados e sua
funcionalidade. Os beans de entidade acessarão as fontes de dados subjacentes
para reunir todas as informações corporativas que representam. O bean de
entidade atua, então, como uma representação dinâmica desses dados
corporativos, fornecendo métodos para atualizá-los e recuperá-los de várias
maneiras. Os beans de entidade são freqüentemente usados juntos com beans de
sessão para fornecer a funcionalidade de negócio de um sistema.
• Beans de mensagem: um EJB dirigido por mensagens cumpre propósitos
semelhantes a um bean de sessão, mas é assíncrono por natureza. Os beans de
mensagem oferecem, então, uma interface assíncrona através da qual os clientes
podem interagir com eles. O bean é associado a uma fila de mensagens em
particular, e todas as mensagens que chegarem nessa fila serão distribuídas para
uma instância do bean dirigido por mensagens. Assim como os beans de sessão,
os beans dirigidos por mensagens são destinados a abrigar a lógica do negócio, em
vez de dados; portanto, eles acessarão todos os dados exigidos através de JDBC ou
de beans de entidade. Para usar os serviços de um bean dirigido por mensagens,
um cliente enviará uma mensagem para sua fila de mensagens associada. Se uma
resposta for exigida, normalmente outra fila de mensagens será usada. Os beans
dirigidos por mensagens interagem diretamente com o Java Message Service
(JMS).
3.1.2.2- Componentes Web
Para criar uma interface com o usuário com base na web, será necessária aplicação de
componentes centrados na web. O J2EE fornece dois tipos de componentes centrados na
web, ambos são aplicados na camada da apresentação e fornecem serviços para clientes
que usam Hypertext Transport Protocol (HTTP) como meio de comunicação:
69
• Servlets: servlets são componentes no lado do servidor. Elas podem ser usadas
para estender a funcionalidade de qualquer servidor compatível com Java, mas
normalmente são usadas para escrever aplicativos web em um servidor da web.
Com freqüência, elas são usadas para criar páginas da web dinâmicas. A
desvantagem do uso de servlets é o fato de que o desenvolvedor precisa gerar
muitas informações de formatação dentro do Java, tornando difícil diferenciar a
camada da apresentação da camada da lógica de um aplicativo, não permitindo
que os papéis de desenvolvedor Hypertext Markup Language (HTML) e de
programador Java sejam facilmente separados.
• JSP: uma JSP é também um componente no lado do servidor que pode ser usado
para gerar páginas web dinâmicas, porém, o código Java em uma JSP é inexistente
ou muito simples, e pode ser prontamente entendido por quem não seja
programador Java. Uma JSP consiste em uma combinação de tags JSP e scriplets
que contém o código executável e a marcação estática, como HTML ou Extensible
Markup Language (XML). O código contido na JSP é identificado e executado
pelo servidor, e a página resultante é enviada para o cliente.
Dessa forma, a diferença fundamental entre servlets e JSPs é: (1) as servlets geram
código HTML de código Java e (2) as JSPs incorporam código Java em código HTML
estático.
A Figura 3.4 mostra um cliente centrado na web fazendo uma requisição para uma
servlet ou para uma JSP. O componente do lado do servidor analisa a requisição do
cliente, em seguida, chama o EJB. Quando a servlet ou a JSP recebe uma resposta do
EJB, ela fica responsável por apresentar os dados que recebe. Depois da servlet ou da
JSP ter preparado a resposta, ela devolve para o cliente, completando o ciclo requisição-
resposta.
70
Não é necessário usar EJBs como parte de uma solução centrada na web. Uma aplicação
simples pode consistir de páginas de marcação, por exemplo, HTML, e servlets ou JSPs;
ou uma combinação de servlets e JSPs.
Quando um cliente faz uma requisição HTTP para uma JSP, o contêiner de JSP
converte a JSP para um arquivo fonte Java e o compila. Na maioria das implementações
esse arquivo é uma servlet. A servlet encaminha a requisição para um componente de
lógica do negócio. O componente executa alguma ação e retorna a resposta para a
servlet. A servlet passa a resposta para uma JSP, que gera a linguagem de marcação que
o cliente apresentará. Por fim, o contêiner de JSPs e o servidor da web retornam a
marcação para o cliente.
FIGURA 3.4 – Uso típico de componentes centrados na Web.
FONTE: Adaptada de Bond (2003).
3.1.2.3- Clientes J2EE
O J2EE suporta uma ampla variedade de clientes. Todos os clientes J2EE chamam e,
subseqüentemente, recebem uma resposta dos componentes da camada física
intermediária do J2EE. A seguir são apontados alguns dos clientes J2EE:
Camada da Apresentação Requisição HTTP
Resposta HTTP
Servidor J2EE
Contêiner Web
Contêiner de EJBs
Cliente Centrado
na Web
Camada do Negócio
JSP ou Servlet
EJB
71
• Clientes HTTP: o J2EE fornece serviços para clientes HTTP através dos
componentes JSP e servlets. Esses clientes podem ser clientes HTML estáticos,
clientes HTML dinâmicos, clientes applet Java, ou ainda outros clientes HTTP,
como por exemplo, dispositivos de aplicação móvel, como os celulares.
• Clientes Independentes: todos os clientes HTTP usam um modelo que,
basicamente, consiste de um cliente, uma camada de apresentação e uma camada
de negócio. Entretanto, existem outros clientes que podem assumir as
responsabilidades inerentes a alguma dessas camadas físicas. Por exemplo, um
aplicativo pode se conectar a um EJB através de seu contêiner, em vez de rotear
através de uma JSP na camada de apresentação, como ilustra a Figura 3.5.
FIGURA 3.5 – Um cliente independente interagindo diretamente com um EJB.
FONTE: Adaptada de Bond (2003).
Pode-se ainda usar clientes não-Java para acessar aplicativos J2EE e componentes
aplicativos. Esses clientes podem usar HTTP para acessar os serviços oferecidos por
uma servlet ou JSP. No caso de um EJB, uma solução seria expor um EJB como um
servidor Common Object Request Broker Architecture (CORBA), que pode ser usado
por clientes CORBA escritos em C++ ou mesmo em COBOL; ou então acessar os EJBs
através de um cliente Microsoft COM.
Cliente
Independente
Servidor J2EE
Contêiner de EJBs
EJB
72
3.1.3- Serviços-Padrão J2EE
Os contêineres devem fornecer a cada tipo de componente um conjunto de serviços
definido. Resumidamente, esses serviços consistem em (Bond,2003):
• Conectividade: os contêineres devem suportar conectividade com outros
componentes e com os clientes do aplicativo. Uma forma de conectividade
requerida é com objetos distribuídos através do Java RMI e do CORBA, conforme
implementado pelo pacote Java Interface Definition Language (Java IDL) e pela
Remote Method Invocation over Internet Inter-ORB Protocol (RMI sobre IIOP). A
conectividade de Internet deve ser fornecida através de HTTP e de Hypertext
Transport Protocol Secure (HTTPS).
• Serviços de diretório: os servidores J2EE são obrigados a fornecer serviços de
atribuição de nomes nos quais os componentes podem ser registrados e
localizados. As Java Naming and Directory Interfaces (JNDIs) fornecem uma
maneira de acessar esses serviços.
• Acesso a dados e persistência: o acesso a dados é fornecido através da API Java
Database Connection (JDBC). Essa API funciona em nível de aplicativo para
fazer a interface com bancos de dados e também com provedores de serviços que
constroem drivers para bancos de dados específicos.
• Conectividade legada: a Java Connector Architecture (JCA) fornece suporte para
J2EE na integração de servidores de informações corporativas e de sistemas
legados.
• Segurança: a segurança está incorporada no modelo J2EE. APIs como o Java
Authentication and Authorization Service (JAAS) ajudam o aplicativo corporativo
J2EE na imposição das verificações de autenticação e autorização de segurança
para usuários.
73
• Suporte para XML: a Java API for XML Processing (API JAXP) suporta a
análise de documentos XML.
• Transações: um servidor J2EE deve fornecer serviços de transações para seus
componentes através da Java Transaction API (JTA).
• Troca de mensagens e e-mail: o Java Message Service (JMS) permite aos
componentes enviar e receber mensagens assíncronas, normalmente dentro do
limite organizacional. A API JavaMail permite que a correspondência da Internet
seja enviada pelos componentes e também oferece funcionalidade para recuperar
e-mail de depósitos de correspondências.
A Figura 3.6 mostra a arquitetura J2EE com os serviços disponíveis para seus
contêineres. Todo servidor compatível com J2EE deve suportar esses serviços.
FIGURA 3.6 – A plataforma J2EE com os serviços disponíveis.
FONTE: Adaptada de Bond (2003).
HTTP
Servidor J2EE
Contêiner Web
Servelet Página JSP
Contêiner EJB
Bean Corporativo
Bean Corporativo
Banco de Dados
Contêiner de Applet
Cliente de Aplicativo
JMS JAXP
JAAS JDBC
Cliente de Applet
Contêiner de Applet
J2SE
J2SE HTTP JavaMail JMS JAXP JAAS
JDBC JTA JAF Conexões
JavaMail JMS JAXP JAAS
JDBC JTA JAF Conexões
74
3.1.4 – A Persistência na Plataforma J2EE
Na plataforma J2EE os objetos do domínio que deverão ser persistidos podem ser
representados como sendo Enterprise Java Beans (EJBs) de entidade.
Um EJB de entidade é, na verdade, um objeto distribuído, compartilhado, transacional e
persistente. Os métodos dos EJBs de entidade oferecem operações que atuam sobre os
dados representados pelo EJB. Isso significa que, para os atributos de um EJB de
entidade são gerados métodos de recuperação (get) e armazenamento (set), além de
métodos localizadores (finders).
Existem dois tipos de mecanismos de persistência que os EJBs de entidade podem usar,
são eles: (1) persistência gerenciada pelo contêiner (Container Managed Persistence –
CMP) e (2) persistência gerenciada pelo EJB (Bean Managed Persistence – BMP)
(SunMicrosystems(a),2004).
Na persistência gerenciada pelo contêiner (CMP) o contêiner EJB é responsável por
gerenciar todo o acesso ao banco de dados requerido pelo EJB, ou seja, os dados do EJB
de entidade são mantidos automaticamente pelo contêiner, usando um mecanismo à sua
escolha. Por exemplo, um contêiner implementado em cima de um sistema de
gerenciamento de banco de dados relacional pode controlar a persistência armazenando
os dados de cada EJB como uma linha em uma tabela (J2EE,2004).
Dessa forma, o código do EJB não contém nenhuma chamada de acesso ao banco de
dados. Como resultado, o código do EJB torna-se mais portátil, uma vez que não fica
atrelado a um dispositivo de armazenamento específico.
Na persistência gerenciada pelo EJB, o EJB é responsável por gerenciar a persistência e,
portanto, o EJB é totalmente responsável por armazenar e recuperar seus dados de
instância (InterSystems,2004).
75
Isso significa que é necessário escrever código para as chamadas de acesso ao banco de
dados no código do EJB. Apesar disso aparentemente ser uma desvantagem, através
dessa abordagem pode-se ter mais controle de como o EJB de entidade acessa o banco
de dados.
Deve-se ressaltar que os EJBs de entidade não representam a única resposta para toda a
exigência da persistência. Pode-se também utilizar um Data Access Object (DAO) para
extrair e encapsular todos os acessos às origens dos dados.
O DAO implementa o mecanismo de acesso exigido para trabalhar com a fonte de
dados requerida, ocultando completamente os detalhes da implementação da fonte dos
dados de seus clientes. Uma fonte de dados pode ser, por exemplo, um banco de dados
relacional, um banco de dados orientado a objetos, um repositório de XML etc.
Como a interface exposta pelo DAO a seus clientes não se altera quando a
implementação da fonte de dados se altera, o DAO pode se adaptar a esquemas
diferentes de armazenamento sem afetar seus clientes. Essencialmente, o DAO age
como um adaptador entre seu cliente e a origem de dados (Alur,2002).
A Figura 3.7 mostra o diagrama de classes que representa o padrão DAO.
ValueObject
BusinessObject DataSourceDataAccessObjectuti liza encapsula
cria/uti l iza
obtém/modifica
FIGURA 3.7 – Padrão DAO.
FONTE: adaptada de Alur (2002).
76
Na Figura 3.7, BusinessObject representa o cliente de dados, ou seja, ele é o objeto que
requer o acesso à fonte de dados para obter e armazenar dados. DataSource representa
uma implementação de fonte de dados. ValueObject representa um objeto de dados
utilizado como transportador de dados. O DataAccessObject (DAO) pode utilizar o
objeto de dados para retornar dados ao cliente, ou utilizá-lo para receber dados do
cliente para atualizar os dados na fonte de dados.
3.1.5- Aplicativos J2EE
Um aplicativo J2EE consiste no seguinte:
• Zero ou mais componentes web empacotados como Web Archives (arquivos
WAR);
• zero ou mais componentes EJB empacotados como arquivos EJB-JAR;
• zero ou mais componentes clientes empacotados como arquivos JAR e
• zero ou mais conectores empacotados como Resource Archives (arquivos RAR).
Os componentes que constituem um aplicativo devem ser empacotados juntos para que
possam ser transportados e implantados. Para isso, todos os componentes de um
aplicativo J2EE são armazenados em um tipo específico de arquivo JAR, chamado
Enterprise Application Archive ou EAR.
Um aplicativo J2EE precisa levar consigo informações sobre como suas partes se inter-
relacionam e sobre os requisitos do ambiente em que será implantado. Essas
informações são transmitidas em uma série de documentos XML chamados “descritores
de implantação”. Existe um descritor de implantação de aplicativo global (armazenado
no arquivo EAR) que define requisitos em nível de aplicativo. O arquivo EAR também
77
pode ter um descritor de implantação específico do contêiner, contendo informações
úteis para o contêiner, mas que saem da abrangência do descritor de implantação de
aplicativo J2EE.
78
79
CAPÍTULO 4 - MODELOS DE OBJETOS ADAPTÁVEIS
Um modelo de objetos adaptável é um sistema que representa classes, atributos e
relacionamentos como sendo metadados.
O sistema é um modelo baseado em instâncias ao invés de classes. 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, quando ele é modificado, o sistema é
alterado imediatamente (Yoder,2001).
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 (Yoder,2000).
Na verdade, os modelos de objetos adaptáveis provêem uma alternativa ao projeto
orientado a objetos tradicional. No projeto orientado a objetos tradicional, são geradas
classes para os diferentes tipos de entidades de domínio, e atributos e métodos são
associados a elas. As classes modelam o domínio do problema, então, uma mudança no
domínio causa uma mudança no código e leva a uma nova versão da aplicação. Um
modelo de objetos adaptável não modela essas entidades de domínio como classes. Ao
invés disso, elas são modeladas por descrições que são interpretadas em tempo de
execução. Então, sempre que uma mudança no domínio do problema é necessária, essas
descrições são alteradas, o que é imediatamente refletido na aplicação em execução
(Yoder,2001).
Assim sendo, pode-se dizer que um modelo de objetos adaptável é aquele em que a
representação dos objetos do domínio em estudo tem um modelo de objetos que é
80
interpretado em tempo de execução. Tal modelo de objetos pode ser modificado com
efeitos imediatos (mas controlados) no sistema que o está interpretando e executando
(Yoder,2000).
Pode-se usar os modelos de objetos adaptáveis para se construir um sistema quando
(Riehle,2000):
Existem muitos tipos de objetos que se diferenciam somente em poucos campos
e quando se deseja reduzir o número de classes do sistema;
deseja-se criar novos tipos de objetos com propriedades diferentes em tempo de
execução;
deseja-se construir aplicações que permitam que os usuários finais configurem
muitos tipos de objetos;
a aplicação requer modificações freqüentes e evolução rápida;
é necessário um modelo explícito da estrutura dos objetos e deseja-se que esse
modelo seja acessado em tempo de execução;
deseja-se prover validação automática de tipos (em linguagens tipadas
dinamicamente); e
deseja-se uma linguagem de modelagem específica para o domínio.
A obtenção da arquitetura de modelo de objeto adaptável é usualmente conseguida
através da aplicação de vários design patterns (Johnson,2002).
81
Os design patterns servem de diretrizes para os desenvolvedores, fazendo com que os
modelos de computação que usam o mesmo design pattern sejam construídos de acordo
com os mesmos princípios (Lee,2001).
O processo de transformar um modelo usando um design pattern é chamado de pattern-
based refactoring. Pode-se criar processos rigorosos de transformação usando design
patterns através do desenvolvimento de metamodelos chamados “especificações das
transformações” (France,2003).
A seguir serão detalhados os design patterns que são mais freqüentemente usados para a
construção de arquiteturas de modelos de objetos adaptáveis.
4.1 - O Pattern TypeObject
A maioria das linguagens orientadas a objetos estrutura um programa como sendo um
conjunto de classes, onde uma classe define a estrutura e o comportamento dos objetos
da classe.
É comum em um sistema orientado a objetos uma determinada classe requerer, além de
um número desconhecido de instâncias, também um número desconhecido de
subclasses. Como sistemas orientados a objetos geralmente usam uma classe separada
para cada tipo de objeto, introduzir um novo tipo de objeto requer que se construa uma
nova classe, o que requer programação (Johnson,1998).
O TypeObject faz com que as classes desconhecidas sejam simples instâncias de uma
classe genérica, como ilustrado na Figura 4.1. Assim sendo, novas classes podem ser
criadas dinamicamente em tempo de execução através da instanciação da classe
genérica (Yoder,2001).
A Figura 4.1 apresenta um exemplo simples em que uma dada hierarquia é representada
com a classe “TipoDeEntidade” e suas instâncias com a classe “Entidade”. Substituir
uma hierarquia como essa é possível quando o comportamento entre as subclasses é
82
bastante similar ou pode ser quebrado em objetos separados. Por essa razão, as
diferenças primárias entre subclasses são seus atributos (Yoder,2001).
FIGURA 4.1 – TypeObject.
FONTE: Adaptada de Yoder (2001).
4.2 - O Pattern Property
Os atributos de um objeto são usualmente implementados por suas variáveis de
instância, sendo que essas variáveis são usualmente definidas em cada subclasse.
Porém, com a utilização do pattern TypeObject, objetos de tipos diferentes estarão todos
em uma mesma classe, o que significa que deve-se adotar uma forma alternativa para
implementar seus atributos.
UmaClasse
SubClasse2 SubClasseN
Antes
Depois
SubClasse1
Entidade
atributosEspecíficos: tipo +algumasOperações( )
TipoDeEntidade
atributosCompartilhados: tipo +tipoOperações( )
0..*
83
Isso pode ser conseguido da seguinte forma: ao invés de cada atributo ser uma variável
de instância diferente, deve-se fazer com que uma variável de instância englobe uma
coleção de atributos, como mostrado na Figura 4.2. Nesse exemplo, “Propriedade”
engloba o nome do atributo, seu tipo e seu valor corrente (Yoder,2001).
FIGURA 4.2 – Property.
FONTE: Adaptada de Yoder (2001).
Na maioria das arquiteturas de modelos de objetos adaptáveis o pattern TypeObject é
aplicado duas vezes: antes e depois de se usar o pattern Property; ou seja, o TypeObject
divide o sistema em entidades e tipos de entidades. Entidades têm atributos que podem
ser definidos usando-se o pattern Property. Cada propriedade (atributo) tem um tipo,
chamado de tipoDePropriedade, e cada tipo de entidade pode então, especificar os tipos
das propriedades para suas entidades. A Figura 4.3 representa a arquitetura resultante
depois de se aplicar esses dois patterns, que pode ser chamada de TypeSquare. Ela
freqüentemente guarda o nome da propriedade e se o valor da propriedade é um
número, uma data, uma string etc.
Entidade
primeiroAtributo: String = qualquer segundoAtributo: String = qualquer ...
Propriedade
nome: String = primeiroAtributo tipo: String = String valor: String = qualquer ...
Antes
Entidade
Depois
0..*
atributos
84
4.3- O Pattern Accountability
Diferentes tipos de objetos usualmente têm diferentes tipos de relacionamentos e
diferentes tipos de comportamentos, e um modelo de objetos adaptável precisa de uma
maneira para descrever e alterar os relacionamentos e comportamento dos objetos. Ou
seja, a aplicação necessita expor os relacionamentos entre os elementos do domínio
(entidades), pois cada relacionamento estabelece papéis aos participantes. Papéis podem
mudar e o sistema precisa saber quais são os papéis correntes que estão sendo praticados
e validados (Yoder,2003).
FIGURA 4.3 – TypeSquare.
FONTE: Adaptada de Yoder (2001).
Atributos são propriedades que se referem a tipos de dados primitivos como, por
exemplo, números, strings, ou datas. Entidades usualmente têm uma associação unária
(one-way associations) com seus respectivos atributos. Os relacionamentos, porém, são
propriedades que se referem a outras entidades, e são usualmente associações binárias
(two-way associations).
Essa distinção, que vem acontecendo desde a modelagem entidade-relacionamento e
que foi incorporada às notações mais modernas da modelagem orientada a objetos, faz,
Entidade TipoDeEntidade
Propriedade TipoDePropriedade
nome: String tipo: Type
0..*
0..*
0..* 0..*
tipo
tipo
propriedades propriedades
85
normalmente, parte de uma arquitetura de modelo de objetos adaptável. Ela
freqüentemente nos leva a ter duas subclasses de propriedades, uma para atributos e
uma para relacionamentos.
Assim sendo, uma maneira de separar os atributos dos relacionamentos é usar o pattern
Property duas vezes, uma para atributos e uma para associações.
Uma outra forma é construir duas subclasses de propriedade: atributo e relacionamento.
Um relacionamento deve conhecer sua cardinalidade, como ilustra a Figura 4.4.
FIGURA 4.4 – Accountability pattern.
FONTE: Adaptada de Yoder (2003).
Como ilustra a Figura 4.4, através do pattern Accountability pode-se manipular muitos
relacionamentos entre grupos. Responsabilidades podem ser organizadas em tipos, de
forma que cada tipo de responsabilidade conheça os tipos de grupos associados a ela,
onde cada tipo de grupo, por sua vez, conhece os membros de seu grupo (Fowler,1995).
Uma terceira forma de separar atributos de relacionamentos é pelo valor da propriedade.
Uma propriedade cujo valor é uma entidade representa um relacionamento, enquanto
1..*
1..*
0..*n
0..*
0..* 1..*
1..*
responsável legal
membro legal
0..*TipoDeRelacionamento supertipo
1..*
TipoDeGrupo
Grupo
0..*
tipotipo
Relacionamento
0..*
1..*
supertipo
responsável
membro
86
que propriedades cujo valor são tipos primitivos de dados são atributos (Johnson e
Yoder,2002).
Representar esses relacionamentos como objetos permitem manipulações em tempo de
execução, permitindo a um usuário com certos poderes imediatamente adaptar essas
entidades-relacionamentos às mudanças de requisitos do domínio (Yoder,2001).
4.4- O Pattern Strategy
As regras de negócio tendem a mudar mais freqüentemente do que os outros objetos do
domínio com os quais elas estão associadas. Essas regras são tipicamente
implementadas nos métodos de um objeto do domínio. As regras também fazem
referência a outros objetos, formando uma teia de dependências difícil de ser mantida.
Dessa forma, mudar uma regra de negócio pode causar um impacto no conjunto de
objetos que dependem daquela regra (Arsanjani,2000).
Regras de negócio para sistemas orientados a objetos podem ser representadas de muitas
formas. Algumas regras irão definir tipos de entidades em um sistema, juntamente com
seus atributos. Outras regras podem definir subtipos legais, o que é usualmente feito
através de subclasses. Outras regras irão definir os tipos legais dos relacionamentos
entre entidades. Essas regras podem definir também restrições básicas como, por
exemplo, cardinalidade de relacionamentos e se um certo atributo é requerido ou não.
A maioria desses tipos de regras é pertinente à estrutura básica, e já foi mostrado,
previamente neste capítulo, como os modelos de objetos adaptáveis podem adaptar
essas regras em tempo de execução. Contudo, algumas regras não podem ser definidas
desta forma. Elas têm uma natureza mais funcional ou procedural. Por exemplo, pode
existir uma regra que descreva que tipos de valores legais um atributo pode ter. Ou,
pode existir uma regra que especifique que certas entidades-relacionamentos serão
somente legais se as entidades tiverem certos valores, e assim, outras restrições são
87
adicionadas. Essas regras de negócio são, por natureza, mais complexas, e os modelos
de objetos adaptáveis usam Strategies e RuleObjects para tratá-las.
Modelos de objetos adaptáveis usualmente começam com estratégias (Strategies)
simples que são, na verdade, as funções básicas necessárias para os tipos de entidades
(EntityTypes). Essas estratégias podem ser mapeadas para o tipo de entidade através de
informações descritivas que são interpretadas em tempo de execução.
Uma estratégia é um objeto que representa um algoritmo. O pattern Strategy define uma
interface padrão para uma família de algoritmos de forma que clientes possam trabalhar
com qualquer um deles. Se o comportamento de um objeto é definido por uma ou mais
estratégias, então o seu comportamento é fácil de ser mudado (Yoder,2002).
A intenção do pattern Strategy é, então, definir uma família de algoritmos, encapsulá-
los, e torná-los intercambiáveis (Chung,2002).
A Figura 4.5 ilustra a estrutura do pattern Strategy. Ela nos mostra que o cliente invoca
uma estratégia, que, dependendo do contexto, aciona a estratégia específica que deve ser
usada diante daquele contexto. Isso permite que o comportamento dos objetos possa ser
alterado em tempo de execução de acordo com o contexto em que ele se encontra.
FIGURA 4.5 - O pattern strategy.
FONTE: Adaptada de Chung (2002).
Estratégia Contexto
interface_contexto()
Estratégia
interface_algoritmo()
EstratégiaConcreta A
interface algoritmo()
EstratégiaConcreta B
interface_algoritmo()
EstratégiaConcreta C
interface_algoritmo()
88
Então, na Figura 4.5, o objeto “Estratégia” declara uma interface comum a todos os
algoritmos suportados. O objeto “Contexto” usa essa interface para chamar o algoritmo
definido pelo objeto “EstratégiaConcreta”. O objeto “EstratégiaConcreta”, por sua vez,
implementa o algoritmo usando a interface fornecida pelo objeto “Estratégia”. O objeto
“Contexto” é configurado com um objeto “EstratégiaConcreta” e mantém uma
referência para ele.
O objeto “Estratégia” e o objeto “Contexto” interagem para implementar o algoritmo
escolhido. O contexto repassa as requisições dos seus clientes para a estratégia.
Normalmente há uma família de classes de “EstratégiaConcreta” para que cada cliente
possa escolher dentre uma delas (Gamma,1995).
4.5- O Pattern Composite
O pattern Composite compõe objetos em estruturas de árvore para representar
hierarquias todo-parte. Ele faz com que clientes tratem objetos individuais e
composições de objetos uniformemente, descrevendo como se usar a composição
recursivamente de forma que os clientes não necessitem fazer essa distinção
(Gamma,1995). A estrutura do pattern Composite é mostrada na Figura 4.6 a seguir.
Dessa forma, o objeto “Componente”: (1) declara uma interface para os objetos na
composição, (2) implementa o comportamento padrão para a interface comum a todas
as classes, (3) declara uma interface para o acesso e gerenciamento dos componentes de
seus filhos e (4) define uma interface para acessar o pai de um componente na estrutura
recursiva e a implementa.
O objeto “Folha” representa um objeto terminal na composição, o que significa que ele
não tem filhos. Ele define o comportamento para objetos primitivos na composição.
89
Componente
Ope ração()Ad iciona(Componen te)Remove(Componente)Recupe raFilho(i nt)
Folha
Operação()
Filhos
Composto
Operação()Adiciona(Componente)Remove(Componente)RecuperaFilho(int)
**
Cliente
FIGURA 4.6 – O pattern composite.
FONTE: Adaptada de Gamma (1995).
O objeto “Composto” define o comportamento para objetos que têm filhos. Ele guarda
os componentes dos filhos e implementa operações relacionadas aos filhos na interface
do objeto “Componente”.
O objeto “Cliente” manipula objetos na composição através da interface provida por
“Componente”.
Assim, os clientes usam a interface da classe “Componente” para interagir com objetos
na estrutura de composição. Se o receptor é uma “Folha”, então a requisição é tratada
diretamente. Se o receptor é um “Composto”, então ele usualmente repassa as
requisições para os componentes de seus filhos, possivelmente realizando operações
adicionais antes e depois do repasse.
Dessa forma, o pattern Composite define hierarquias de classes que consistem de
objetos primitivos e objetos compostos. Objetos primitivos podem ser compostos em
90
objetos mais complexos, que por sua vez, podem também ser compostos, e assim por
diante, recursivamente (Gamma,1995).
4.6 - O Pattern RuleObject
Se regras de negócio mais poderosas são necessárias, as estratégias podem evoluir para
se tornar mais complexas. Essas regras podem ser regras primitivas ou uma
combinação de regras de negócio através da aplicação do pattern Composite. Assim
sendo, o pattern Composite permite que regras possam ser compostas de outras regras.
Por exemplo, regras que representam predicados são compostas de conjunções e
disjunções, regras que representam valores numéricos são compostas de regras de
adição e subtração, regras que representam conjuntos são compostas pelas regras união
e intersecção. Essas estratégias mais complexas são chamadas de RuleObjects.
Dessa forma, o pattern RuleObject faz com que o projeto e a implementação de
processos de negócio computadorizados sejam extensíveis e adaptáveis, sem causar uma
cadeia de mudanças, pois as regras que governam os processos de negócio se tornam
“plugáveis”, ou facilmente intercambiáveis (Arsanjani,2000).
Na verdade, com o pattern RuleObject pode-se ter o conceito de estratégias
configuráveis, já que novas estratégias podem ser criadas a partir de regras já existentes.
A Figura 4.7 mostra a estrutura do pattern RuleObject.
91
FIGURA 4.7 – O pattern ruleObject.
FONTE: Adaptada de Yoder (2003).
A Figura 4.8 mostra a aplicação do pattern TypeObject duas vezes, a aplicação do
pattern Property, do pattern RuleObject e do pattern Composite para representar o
comportamento dos objetos. Essa arquitetura resultante é freqüentemente vista em
sistemas adaptáveis.
FIGURA 4.8 – TypeSquare com regras.
FONTE: Adaptada de Yoder (2001).
Para se construir as regras de negócio em tempo de execução pode-se usar diversas
abordagens, desde o uso de table driven systems, o uso de uma abordagem orientada à
Entidade TipoDeEntidade
Propriedade TipoDePropriedade
nome: String tipo: Type
0..*
0..*
0..* 0..*
tipo
tipo
propriedades propriedades
Regra
RegraComposta RegraPrimária
regra
0..*
CondiçãoAND
*
1RegraPrimitiva
CondiçãoOR
ObjetoRegra
RegraComposta
CondiçãoNOT
92
gramática (Grammar-oriented object design), ou até o uso de uma abordagem orientada
por workflow.
Se as regras de negócio descrevem um workflow, a arquitetura Micro-Workflow descrita
em Manolescu (2000) pode ser usada. Ela descreve classes que representam uma
estrutura workflow como uma combinação de regras como, por exemplo, repetição,
condição, seqüência, bifurcação e regras primitivas. Essas regras podem ser construídas
em tempo de execução para representar um processo workflow particular.
As regras também podem ser construídas a partir de Table Driven Systems, como
descrito em Perkins (2000). Nessa abordagem as diferenças nas regras de negócio
podem ser parametrizadas e armazenadas em um banco de dados. O sistema sendo
executado pode interpretar essas mudanças da tabela do banco de dados ou uma função
apropriada pode ser chamada com os valores modificados no banco de dados. Isso pode
ser feito através de triggers ou de stored procedures.
Pode-se usar também uma abordagem orientada à gramática, que é conhecida como
Grammar-oriented Object Design (GOOD). Essa abordagem aplica uma combinação de
princípios de linguagens específicas de domínio para a modelagem do negócio e os
mapeia para arquiteturas de software baseadas em componentes. Mais detalhes sobre
essa abordagem para a construção de regras podem ser encontrados em Arsanjani
(2001).
Prover essa construção de regras mais complexas é, geralmente, a parte mais difícil do
projeto de modelos de objetos adaptáveis (Yoder,2002).
4.7 - O Pattern Interpreter
O pattern Interpreter descreve como se representam sentenças em uma linguagem e
interpretar essas sentenças. Um dos benefícios do pattern Interpreter é que ele permite
que se adicione novas formas de se interpretar expressões (Nakamura,1998). Assim
93
sendo, ele define a representação da gramática de uma linguagem, juntamente com seu
interpretador. A Figura 4.9 mostra a estrutura do pattern Interpreter.
ExpressãoTerminal
Interpreta(Contexto)
ExpressãoNãoTerminal
Interpreta(Contexto)
Express ãoAbstrata
Interpreta(Contexto)**
Cliente
Contexto
FIGURA 4.9 – O pattern interpreter.
FONTE: Adaptada de Gamma (1995).
Um objeto “ExpressãoAbstrata” declara uma operação “Interpreta” que é comum a
todos os nós na árvore de sintaxe abstrata.
Uma “ExpressãoTerminal” implementa uma operação “Interpreta” associada a símbolos
terminais na gramática. É requerida uma instância desse objeto para cada símbolo
terminal em uma seqüência.
Uma “ExpressãoNãoTerminal” representa, por exemplo, uma expressão de repetição,
seqüência ou condição em uma gramática. Uma classe desse tipo é requerida para cada
regra R ::= R1R2...Rn na gramática, e são necessárias variáveis de instância do tipo
“Expressão Abstrata” para cada símbolo desde R1 até Rn para implementar uma operação
“Interpreta” para símbolos não terminais na gramática. Essa operação tipicamente
chama a si mesmo recursivamente nas variáveis representando R1 até Rn.
94
O “Contexto” contém informações globais ao interpretador. O “Cliente” constrói uma
árvore de sintaxe abstrata representando uma sentença particular na linguagem que a
gramática define. A árvore de sintaxe abstrata é montada das instâncias das classes
“ExpressãoTerminal” e “ExpressãoNãoTerminal”.
Assim sendo, o “Cliente” constrói a sentença como uma árvore abstrata de instâncias de
“ExpressãoTerminal” e “ExpressãoNãoTerminal”, e inicia o “Contexto” invocando a
operação “Interpreta”. Cada nó “ExpressãoNãoTerminal” define “Interpreta” em termos
de “Interpreta” em cada sub-expressão. A operação “Interpreta” de cada
“ExpressãoTerminal” define o caso base na recursão. A operação “Interpreta” para cada
nó usa o “Contexto” para armazenar e acessar o estado do interpretador (Gamma,1995).
4.8 - O Pattern Builder
O pattern Builder é utilizado para separar a construção de um objeto de sua
representação, permitindo que a sua representação interna possa ser modificada
facilmente, sem que essas alterações afetem o sistema globalmente, além de isolar seu
código de construção e representação, aumentando a modularidade. Ele é utilizado
quando a forma de se compor um objeto deve ser independente de suas partes e de como
essas se conectam, ou quando o objeto pode ter diferentes configurações, que só serão
informadas em tempo de execução. A Figura 4.10 mostra a aplicação do pattern
Builder.
FIGURA 4.10 – O pattern builder.
FONTE: Adaptada de Gamma (1995).
construtorDiretor
Construir()
Construtor Concreto
ConstruirParte() PegarResultado()
Construtor
ConstruirParte()
Produto
95
O “Construtor” especifica uma interface abstrata para a criação das partes de um objeto
“Produto”.
O “ConstrutorConcreto” constrói e monta as partes de um produto implementando a
interface “Construtor”. Ele define e guarda a representação que criou, provendo uma
interface para a recuperação do produto.
O “Diretor” constrói um objeto usando a interface “Construtor”. O “Produto” representa
o objeto complexo em construção.
4.9- Interpretadores dos Metadados
Os metadados para a descrição das regras de negócio e do modelo de objetos são
interpretados em dois momentos: (1) quando os objetos são construídos, isto é, quando
o modelo de objetos é instanciado e (2) durante a interpretação das regras de negócio
em tempo de execução (Johnson,2002).
A informação a respeito dos tipos de entidades, propriedades, relacionamentos, e
comportamentos pode ser armazenada em um banco de dados, ou então, pode ser
armazenada em arquivos XML. Se ela for armazenada em arquivos XML pode-se usar
ferramentas de construção XDT para a manipulação em tempo de execução, permitindo
que o modelo possa ser atualizado e imediatamente refletido nas aplicações
interpretando o dado.
Independentemente de como a informação acerca dos tipos de entidades, propriedades,
relacionamentos, e comportamentos, é armazenada, ela deve ser interpretada para que se
possa, em um primeiro momento, montar o modelo de objetos adaptável que representa
o modelo do domínio real.
Se um banco de dados orientado a objetos está sendo usado para armazenar os
metadados, os tipos dos objetos e relacionamentos podem ser construídos pela simples
96
instanciação das classes genéricas (Entidade, TipoDeEntidade, etc.) com os metadados
armazenados no banco.
Caso contrário, os metadados deverão ser lidos do banco de dados para que se possa
construir esses objetos, que podem ser construídos usando-se o pattern Interpreter e o
pattern Buider. O pattern Builder e o pattern Interpreter são comumente usados para a
construção das estruturas do metamodelo ou para a interpretação dos resultados nesses
casos.
O segundo momento onde os metadados têm que ser interpretados é quando acontecem
mudanças no domínio, por exemplo, novos tipos de objetos são criados com seus
respectivos atributos e operações; pois essas mudanças têm que ser refletidas na
aplicação sendo executada, e para isso o repositório de metadados deve ser atualizado.
Quando as novas operações criadas são simples estratégias, algum metadado pode
descrever o método que precisa ser invocado juntamente com a estratégia apropriada.
Essas estratégias podem ser “plugadas” ao objeto apropriado durante a instanciação de
tipos.
Contudo, se forem necessárias regras mais dinâmicas, uma linguagem específica de
domínio deve ser projetada através de RuleObjects. Por exemplo, regras primitivas
podem ser definidas e compostas em objetos que formem uma estrutura de árvore que é
interpretada em tempo de execução.
Às vezes, as necessidades do sistema se tornam tão complexas que a única solução é
criar uma linguagem de regras usando gramática, árvores de sintaxe abstrata, linguagens
de restrições, e interpretadores complexos (Yoder,2001).
Regras e gramáticas requerem esforço para serem mantidas, mas, podem ser
relativamente fáceis para os usuários, ou pelo menos mais fáceis do que escrever código
na linguagem base. Ferramentas e linguagens visuais podem ser construídas para dar
97
suporte para os usuários finais na manutenção das regras de negócio de uma forma
ainda mais simplificada.
4.10- Arquitetura dos Modelos de Objetos Adaptáveis
Os modelos de objetos adaptáveis são usualmente construídos através da aplicação de
um ou mais patterns citados neste capítulo. A Figura 4.11 mostra a arquitetura comum
dos modelos de objetos adaptáveis.
Esta figura divide a arquitetura de modelos de objetos adaptáveis em dois níveis: (1) o
nível operacional, onde estão as classes que guardam informações relacionadas
exclusivamente ao domínio do problema e (2) o nível de conhecimento, onde estão as
classes que guardam informações a respeito das classes do nível operacional.
As classes envolvidas pela elipse onde se lê “Classes com seus atributos e
relacionamentos”, representam as classes responsáveis por guardar os tipos de
entidades, tipos de relacionamentos e tipos de atributos existentes no domínio.
As classes envolvidas pela elipse onde se lê “Comportamento” representam as classes
que especificam o comportamento do sistema através de regras.
Deve-se notar que, a arquitetura de modelos de objetos adaptáveis pode ser obtida
através da aplicação dos patterns, o que não significa que se tenha um framework para a
construção de modelos de objetos adaptáveis.
Frameworks, nesse contexto, são projetos reusáveis, onde todas as partes do sistema são
descritas por um conjunto de classes abstratas e pela forma com que as instâncias dessas
classes colaboram entre si (Roberts,1998).
Na realidade, cada modelo de objetos adaptável é um framework de algum tipo, mas não
existe ainda um framework genérico para construí-los. Um framework genérico para a
98
construção de TypeObjects, Properties, e seus relacionamentos pode provavelmente ser
construído, porém, esses elementos são fáceis de serem definidos e a dificuldade está
geralmente associada às regras descritas pela linguagem do domínio. Isso é algo que
normalmente é bem específico do domínio e varia de acordo com cada um deles.
FIGURA 4.11- Arquitetura comum dos modelos de objetos adaptáveis.
FONTE: Adaptada de Yoder (2003).
1
0..*
10..*
Classes com Atributos e Relacionamentos
1
0..*
tipo
0..*
0..*
tipo Relacionamento
relacionamentos
0..*Entidade TipoDeEntidade
Propriedade
valorUsado: ()
TipoDePropriedade
nome tipo
1
0..* 0..*
tipo
propriedades
tiposDePropriedades
Regra
ValorUsado: ()
RegraComposta RegraPrimaria
regras
0..*
TipoDeRelacionamento
0..*
tiposDeRelacionamentos
1
0..*
Operacional Conhecimento(meta)
Comportamento
99
4.11- Projeto de Modelos de Objetos Adaptáveis
O projeto de modelos de objetos adaptáveis envolve três atividades principais: (1)
definição das entidades do negócio, regras e relacionamentos; (2) desenvolvimento de
um projeto de uma máquina para instanciar e manipular essas entidades de acordo com
as suas regras na aplicação e (3) desenvolvimento de ferramentas para descrever essas
entidades, regras e relacionamentos (Yoder,2001).
Essas atividades podem ser conseguidas através da aplicação de um ou mais patterns
previamente mencionados, em conjunto com regras de engenharia de software para
análise, projeto e implementação de sistemas.
4.12- Aspectos de Implementação
Os aspectos primários de implementação que precisam ser abordados quando se está
desenvolvendo modelos de objetos adaptáveis são: (1) como armazenar e representar o
modelo no banco de dados, (2) como apresentar os elementos do domínio para o
usuário, (3) como manter o modelo e (4) como se lidar com o histórico dos valores de
dados, versões e histórico de regras. A seguir, será abordado cada um desses aspectos
mais detalhadamente (Johnson,2002).
4.12.1- Tornando os Modelos Persistentes
Os modelos de objetos adaptáveis modelam os objetos como metadados, isto significa
que esses metadados podem ser armazenados em bancos de dados seguindo-se regras
bem conhecidas. Bancos de dados orientados a objeto são a maneira mais fácil de se
manejar a persistência dos objetos. Contudo, também é possível obter a persistência do
modelo usando-se um banco de dados relacional. Mais informações sobre o
mapeamento de objetos para bancos de dados relacionais podem ser obtidas em
Keller(1998), Rumbaugh(1991) e Yoder(1998).
100
Além disso, é possível armazenar os metadados usando-se o XML. Deve-se notar que
independentemente da maneira com que os metadados sejam armazenados, o sistema
tem que ser capaz de ler e popular o modelo de objetos adaptável com a configuração
correta das instâncias. Isso pode ser conseguido usando-se construtores (builders) e
interpretadores (interpreters) para a criação e configuração das entidades, atributos,
relacionamentos e comportamentos da meta-descrição. Pode-se ter uma idéia de como
isso poderia ser feito observando-se a Figura 4.12.
FIGURA 4.12- Armazenando e recuperando metadados.
FONTE: Adaptada de Yoder (2003).
A Figura 4.12 elucida que o modelo de objetos adaptável pode estar armazenado tanto
em um banco de dados, quanto em arquivos XML. Independentemente de como ele está
armazenado, ele deve ser instanciado e estar disponível no repositório de metadados
para que possa ser utilizado pela aplicação. Isso será feito, no caso do modelo de objetos
estar armazenado em um banco de dados, através do mecanismo de persistência e da
arquitetura AOM, e no caso do modelo de objetos estar armazenado em arquivos XML,
através do XML Parser, do interpretador e do construtor (Interpreter/Builder) de
metadados e da arquitetura AOM.
Mecanismo de Persistência
XML Parser
Repositório de Metadados
Objetos do Domínio
Banco de Dados
XML
Aplicação
Interpreter/ Builder
A R Q U I T E T U R A
A O M
101
Mudar o modelo altera diretamente o comportamento do software, resultando em uma
extensão completa em tempo de execução. Por exemplo, publicar uma nova versão de
um modelo no repositório faz com que todos os sistemas de software no ambiente
automaticamente ajustem seus comportamentos para refletir as mudanças. Assim sendo,
os metadados podem ser atualizados enquanto o sistema está sendo executado, e as
mudanças resultantes no comportamento e estrutura do sistema têm efeito assim que o
modelo de objetos é interpretado (Poole,2001).
4.12.2- Apresentando o Modelo para os Usuários
Uma das maiores razões para se projetar um modelo de objetos adaptável é permitir que
especialistas do domínio possam modificar o comportamento do sistema definindo
novas entidades, relacionamentos e regras, sem a necessidade de desenvolver novos
códigos na linguagem base (Johnson,2002).
Para permitir esse tipo de modificações, as arquiteturas de modelos de objetos
adaptáveis delegam a complexidade das possíveis mudanças no domínio para a
configuração dos dados, delegando as decisões de configuração para os usuários.
Assim, os usuários acabam se tornando “programadores especialistas” em uma
linguagem específica de domínio (Manolescu,1999).
Isso faz com que se tenha a necessidade de oferecer a esses especialistas ferramentas
simples para que eles possam efetivamente realizar as tarefas descritas anteriormente.
Dessa forma, é essencial em um sistema adaptável que se tenha uma interface gráfica
para que se possa definir novas entidades, relacionamentos e regras de forma interativa.
Embora os modelos de objetos adaptáveis provenham técnicas poderosas para a criação
dos objetos do domínio, mapeá-los para interfaces gráficas pode ser difícil, pois eles são
abstrações de um nível mais alto. É possível projetar interfaces dinâmicas, porém, isso
pode ser trabalhoso de ser conseguido, e normalmente é bem específico do domínio em
questão (Johnson,2002).
102
4.12.3- Mantendo o Modelo
O armazenamento dos metadados no banco de dados ou em arquivos XML/XMI pode
ser realizado, no entanto, os desenvolvedores terão que aprender como o modelo será
armazenado, bem como a semântica para descrever as regras de negócio. Uma solução
comum é desenvolver editores e ferramentas de programação para auxiliar os usuários
na realização dessas tarefas (Roberts,1998).
4.12.4- Histórico de Regras e Dados
Outro aspecto de implementação importante é como se lidar com o histórico dos valores
de dados e como se lidar com versões e histórico de regras.
Uma forma simples de se lidar com o histórico de valores de dados é guardar como os
valores mudam ao longo do tempo e fazer com que o interpretador sempre use a versão
correta quando estiver lendo esses valores. As regras podem ser tratadas similarmente,
incluindo-se a informação do histórico de cada regra e fazendo com que o interpretador
sempre use a versão correta das regras. Isso é especialmente importante quando valores
podem ser válidos em um ponto no tempo, porém, inválidos em outro (Johnson,2002).
Isso pode ser conseguido usando-se um modelo de dados temporal, onde são
especificados não apenas os aspectos estáticos da aplicação, mas também os dinâmicos,
permitindo o armazenamento da evolução de seus objetos. Nesse modelo, pode-se
armazenar as versões de um objeto e, para cada versão, o histórico das mudanças
realizadas nos valores de seus atributos dinâmicos e relacionamentos (Moro et al,2001).
4.13 –Abordagens e Tecnologias Relacionadas aos Modelos de Objetos Adaptáveis
A seguir, estão listadas algumas das abordagens ou tecnologias que estão relacionadas
aos modelos de objetos adaptáveis:
103
• Geradores de código (code generators): produzem código executável ou código
fonte. Focam na geração automática dos sistemas através de descrições de alto
nível. Estão relacionados com os modelos de objetos adaptáveis no sentido de que a
funcionalidade dos sistemas não é diretamente produzida por programadores, mas
especificada usando-se construtores relacionados ao domínio. Podem usar, também,
editores para a descrição dos metadados para a geração do código. Essas técnicas
são diferentes dos modelos de objetos adaptáveis, principalmente, porque
“separam” o metamodelo do sistema em si. Os modelos de objetos adaptáveis, ao
contrário, imediatamente refletem as mudanças nos requisitos do negócio sem
qualquer geração de código ou re-compilação (Yoder,2001).
• Metamodelagem (metamodeling): foca a manipulação do modelo e do
metamodelo de um sistema e o suporte para as transformações válidas entre
representações. Freqüentemente o foco é maior nos metamodelos, e não na
aplicação final que irá refletir os requisitos do negócio. Assim como os modelos de
objetos adaptáveis, também têm um metamodelo que é usado para descrever (ou
refletir) o domínio do negócio e usam ferramentas de interface gráfica especiais
para a manipulação do modelo. O metadado também é usualmente interpretado
para a criação do modelo real. A primeira diferença entre metamodelagem e os
modelos de objetos adaptáveis, é que as técnicas de metamodelagem, como as
providas por ferramentas CASE, geram o código a partir de informações
descritivas, enquanto que os modelos de objetos adaptáveis interpretam a
informação descritiva em tempo de execução. Dessa forma, se a informação sobre
o domínio for alterada com uma ferramenta CASE, será necessário gerar um novo
programa, compilá-lo e gerar uma nova versão para os usuários. Com os modelos
de objetos adaptáveis, mudanças nas informações do domínio não têm o mesmo
impacto, uma vez que elas são armazenadas em um banco de dados compartilhado
ao qual os sistemas sendo executados têm acesso. Então, assim que a informação se
torna disponível, o sistema imediatamente reflete as novas mudanças sem a
necessidade de gerar uma nova versão do sistema (Yoder,2001).
104
• Técnicas de Reflexão (reflection techniques): a programação reflexiva nos leva a
um programa que usa reflexão em tempo de execução para alterar valores de
campos na classe alvo (Fowler,2002). Essas técnicas estão relacionadas com os
modelos de objetos adaptáveis no sentido de que estas também definem um meta-
nível onde os metadados são mantidos, porém, as técnicas de reflexão não
estabelecem que o metadado deve ser armazenado em um banco de dados. Pode-se
dizer que os modelos de objetos adaptáveis usam técnicas reflexivas.
• Model Driven Architecture (MDA): é uma abordagem para a integração de todo o
ciclo de vida dos sistemas, englobando software, hardware, pessoas e práticas de
negócio, proposta pelo Object Management Group (OMG). Ela provê um
framework para se entender, projetar, operar e evoluir todos os aspectos desses
sistemas, usando métodos de engenharia e ferramentas.
A MDA define uma abordagem para a especificação de sistemas que separa a
especificação das funcionalidades do sistema, da especificação da implementação
dessas funcionalidades em uma plataforma de tecnologia específica. Dessa forma, ela
define uma arquitetura para modelos que provê um conjunto de diretrizes para estruturar
especificações expressas como modelos.
A abordagem MDA e os padrões que ela suporta, permitem que o mesmo modelo que
especifica as funcionalidades do sistema, seja implementado em múltiplas plataformas
através de padrões genéricos de mapeamento, e através de mapeamentos pontuais para
plataformas específicas. Ela permite também que diferentes aplicações sejam integradas
relacionando-se explicitamente seus modelos, possibilitando a integração e a
interoperabilidade, e suportando a evolução do sistema à medida que as plataformas
evoluem. Dessa forma, pode-se ter uma arquitetura neutra tanto em termos de
linguagem, quanto em termos de fabricante e de middleware.
Para criar aplicações baseadas na MDA, o primeiro passo é criar um Modelo
Independente de Plataforma (Platform Independent Model – PIM), que pode ser
105
expresso em UML. O PIM pode ser mapeado para um Modelo Dependente de
Plataforma (Platform Specific Model– PSM) para focar em plataformas como o Modelo
de Componentes CORBA (CORBA Component Model – CCM), o Enterprise
JavaBeans (EJB) ou o Microsoft Transaction Server (MTS). Assim, o PSM, que é
também expresso em UML, pode ser implementado em uma plataforma particular
(OMG,2002).
A arquitetura definida pela MDA engloba um conjunto de serviços já especificados pelo
OMG, incluindo serviços de diretório, tratamento de eventos, persistência, transações, e
segurança. Dessa maneira, a MDA permite que se crie modelos de domínios de
problemas padronizados para aplicações específicas. Além disso, com a abordagem
MDA é possível construir novas aplicações baseadas em MDA usando as plataformas e
o middleware de sua preferência. Uma abordagem deste tipo também torna mais fácil
integrar aplicações e facilidades ao middleware.
O futuro da MDA pode ser abordado em duas etapas (Poole,2002): (1) conseguir a
interoperabilidade baseada em transformações PIM-PSM e no compartilhamento de
metadados e (2) implementar modelos de objeto adaptáveis (AOMs) como uma
evolução da MDA.
A interoperabilidade baseada em transformações PIM-PSM e no compartilhamento de
metadados proposta pela MDA, prevê um ambiente em que exista interoperabilidade
eficiente entre diversas aplicações, ferramentas e bancos de dados através do
intercâmbio de modelos compartilhados. Os componentes que participam do ambiente
usam serviços padrões providos por implementações dos padrões MDA, o que
possibilita que esses componentes exponham e troquem seus metadados como
instâncias de modelos. Esses serviços de plataforma têm definições padrões que são
expressas via modelos de programação padrões (APIs), que são gerados
automaticamente dos modelos independentes de plataforma. As APIs, então, definem
um modelo de programação para o serviço que representam.
106
Essa interoperabilidade já vem sendo conseguida, pois os padrões definidos pela MDA
formam a base para a construção de esquemas para criação, publicação e gerenciamento
de modelos, e tecnologias de suporte já vem sendo especificadas e implementadas por
várias organizações.
Pode-se pensar em um próximo estágio para a MDA através da implementação de
modelos de objetos adaptáveis; o que corresponde a se ter software capaz de descobrir
automaticamente as propriedades de seu ambiente e se adaptar a ele, incluindo a
modificação dinâmica de seu comportamento. Isso representa uma migração da
interoperabilidade baseada em metadados, para sistemas cujo comportamento é
determinado em tempo de execução por modelos de objetos adaptáveis (Poole,2002).
Dessa forma, sistemas baseados na MDA poderão se acomodar mais facilmente às
mudanças no ambiente e reagir apropriadamente sem a necessidade da intervenção do
programador. No futuro (uma evolução da MDA), o processo de mapeamento será
descartado e os modelos serão interpretados diretamente por software, fazendo com que
se tenha uma arquitetura dinâmica e sistemas adaptáveis.
Quando esses sistemas precisarem ser modificados, isso pode ser conseguido alterando-
se o modelo do sistema. Isso pode ser feito por especialistas de domínio que não
necessitam ser necessariamente especialistas de software, ou talvez pelo sistema em si,
através da implementação de um mecanismo de aprendizado.
Sistemas desse tipo podem interpretar modelos diretamente e modificar seus próprios
comportamentos de acordo com as necessidades. Nesse paradigma, mudando-se o
modelo, diretamente muda-se o comportamento do software; por exemplo, uma nova
versão de um modelo em um repositório faz com que todos os sistemas de software no
ambiente ajustem automaticamente seus próprios comportamentos para refletir as
mudanças.
107
Essa evolução da MDA através dos modelos de objeto adaptáveis ainda está sendo
estudada, e é um dos temas deste trabalho.
108
109
CAPÍTULO 5 – A ARQUITETURA SICSDA
Neste capítulo são apresentadas as idéias gerais de uma arquitetura distribuída,
configurável e adaptável, proposta para o Sistema de Controle de Satélites do INPE,
denominada arquitetura Sistema de Controle de Satélites Distribuído e Adaptável
(SICSDA).
Esta arquitetura, como o próprio nome já diz, integra duas tecnologias emergentes, a
tecnologia de objetos distribuídos e a tecnologia de modelos de objetos adaptáveis; e
procura, na medida do possível, beneficiar-se das vantagens intrínsecas que essas
tecnologias podem trazer para um sistema de software concebido sob suas diretrizes.
Dessa forma, sob o ponto de vista da distribuição, a arquitetura deve SICSDA deve
prover:
• Um aumento da disponibilidade de serviços: a tecnologia de objetos
distribuídos provê mecanismos que asseguram a disponibilidade dos objetos e,
conseqüentemente, o aumento da disponibilidade de serviços, independentemente
de falhas nos computadores.
• A tolerância às falhas: a tecnologia de objetos distribuídos implementa, com uma
certa transparência, a localização física de um objeto. Caso ocorra uma falha no nó
onde ele esteja instanciado, uma nova conexão pode ser estabelecida com outro
objeto que preste o mesmo serviço.
• O aumento da concorrência e desempenho: a capacidade de instanciar cópias
de um mesmo objeto em mais de um nó da rede, apresenta-se como um fator que
deve ser levado em consideração para explorar o recurso de concorrência em
110
sistemas distribuídos, ou seja, dois ou mais usuários podem solicitar o mesmo
serviço ao sistema, mas sendo atendidos por objetos instanciados em diferentes
nós.
• A interoperabilidade: o desenvolvimento da tecnologia de distribuição levou ao
uso da tecnologia middleware. Pode-se considerar que essa tecnologia propõe a
disponibilidade de um conjunto de facilidades comumente necessárias para integrar
componentes (objetos ou não) num sistema distribuído, contribuindo para a
existência de um novo paradigma em computação, cujo foco é a interoperabilidade,
entendendo-se por interoperabilidade a possibilidade de um programa, em um
sistema, acessar programas e dados em outros sistemas.
• A descentralização: a carga de uma aplicação distribuída não se restringe a um
único computador e sim a vários. A descentralização proporciona a existência de
réplicas de um mesmo objeto que são instanciadas em computadores distintos,
aumentando a disponibilidade de serviços prestados pelo sistema.
• Superação da separação entre usuários e recursos computacionais: a
transparência de localização de objetos constitui uma característica peculiar de
sistemas distribuídos, ou seja, o usuário simplesmente solicita um serviço ao
sistema, e a localização de quem irá atender a este serviço fica sob
responsabilidade do sistema.
Analogamente, sob o ponto de vista dos modelos de objetos adaptáveis, a arquitetura
SICSDA deve prover:
• Maior estabilidade na estrutura das classes: à medida que o sistema evolui a
estrutura das classes tende a ser mais estável do que nos sistemas orientados a
111
objetos tradicionais, já que, mudanças na especificação levam a mudanças no
conteúdo do banco de dados.
• Facilidade de se fazer mudanças: uma das maiores vantagens de se usar uma
arquitetura baseada em modelos de objetos adaptáveis é a facilidade de se fazer
mudanças no sistema, permitindo que, além dos desenvolvedores do software
(programadores e administradores) , os próprios especialistas do domínio
(engenheiros e controladores de satélite) estendam seu sistema dinamicamente.
• Redução do tempo para incorporação de novas idéias ao software: com o uso
de ferramentas apropriadas os especialistas do domínio e os desenvolvedores do
software podem introduzir novos elementos ao software, e fazer mudanças em seus
modelos de domínio em tempo de execução, reduzindo significantemente o tempo
para incorporação de novas idéias ao software.
• Redução do custo total do desenvolvimento: embora inicialmente exija um
investimento maior, a um longo prazo, a utilização desse tipo de arquitetura pode
levar a uma redução do custo total do desenvolvimento, uma vez que a manutenção
e a evolução do sistema podem ser mais facilmente absorvidas.
Dessa forma, tendo visto as vantagens provenientes de um sistema distribuído e
adaptável, o objetivo deste trabalho concentra-se em propor uma arquitetura distribuída
configurável e adaptável aplicada às várias missões de controle de satélites. Assim, a
arquitetura proposta visa obter:
• Facilidade na acomodação de novas missões: a arquitetura deve permitir 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.
112
• Possibilidade de se monitorar mais de um satélite: a arquitetura deve 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.
• Facilidade de se configurar e estender o sistema de controle para um
determinado satélite: a arquitetura deve permitir que especialistas do domínio e
desenvolvedores do software 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.
• Economia de desenvolvimento e investimento para futuras missões: a
arquitetura deve possibilitar que futuras missões aproveitem grande parte do
investimento de hardware e software já realizado em outras missões.
5.1- As Tecnologias Utilizadas para a Modelagem da Aplicação
A estrutura computacional existente hoje para o controle de satélites no INPE está
baseada em uma arquitetura cliente-servidor e o software aplicativo (SICS) apresenta-se
disponível em plataformas PCs. Para o seu desenvolvimento e implementação, utilizou-
se o ambiente de desenvolvimento Visual C++ da Microsoft e uma metodologia
orientada a objetos.
Atualmente, está operando também no Centro de Controle de Satélites (CCS), um
protótipo que implementa a arquitetura SICSD, proposta em Ferreira (2001). Essa
arquitetura baseia-se no conceito de objetos distribuídos, e para o seu desenvolvimento
e implantação utilizou-se: PCs com o sistema operacional Windows, linguagem de
programação Java, a plataforma J2EE para distribuição e uma metodologia orientada a
objetos.
113
Analisando-se as duas possíveis soluções existentes para a distribuição dos objetos, a
plataforma J2EE e a plataforma .NET, chegou-se às seguintes decisões:
• Para a implementação do protótipo descartou-se a possibilidade de se usar a
arquitetura .NET, já que ela é uma solução proprietária da Microsoft, e que, até o
momento não apresenta portabilidade, uma vez que suporta apenas a plataforma
Windows como sistema operacional, o hardware suportado por ela, e só é
executável no ambiente .NET (Vawter,2001).
• A arquitetura proposta foi desenvolvida utilizando-se a plataforma J2EE, pelos
seguintes motivos: (1) o J2EE oferece neutralidade de plataforma de sistema
operacional, de hardware, e de ambiente de execução, o que nos dá um certo grau
de portabilidade; (2) pode-se escolher entre uma série de ferramentas que contém a
arquitetura J2EE, o que nos dá um certo grau de liberdade para utilizar a
ferramenta que mais seja adequada tanto em termos de custos, quanto em termos
de facilidades oferecidas e de disponibilidade para o uso e (3) já existe um
histórico de utilização do J2EE, uma vez que o protótipo que implementa a
arquitetura SICSD foi implementado usando-se essa plataforma.
No capítulo 5 deste trabalho foram apresentadas três soluções para a persistência do
modelo de objetos adaptável. Assim, analisando-se as possíveis soluções, chegou-se às
seguintes decisões:
• Para a implementação do protótipo descartou-se a possibilidade de se usar um
banco de dados relacional, pois, embora alguns exemplos tivessem sido
desenvolvidos utilizando esse tipo de tecnologia, devido à necessidade de se
armazenar e recuperar objetos, essa abordagem apresentou-se mais complexa.
114
• Para a implementação do protótipo descartou-se a possibilidade de se usar o XML
já que ele não é propriamente um banco de dados, o que dificulta, a princípio, o
gerenciamento e manutenção dos dados.
• Para a implementação do protótipo foi usado um banco de dados orientado a
objetos já que esta solução mostrou-se, a princípio, mais simples, uma vez que a
própria definição do esquema do banco de dados refere-se a classes, poupando a
necessidade de se fazer um mapeamento objeto-relacional para o armazenamento e
recuperação dos metadados.
Uma análise mais aprofundada das soluções para a persistência do modelo de objetos
adaptável está sendo desenvolvida em Almeida (2004). Esse trabalho explora o
armazenamento do metamodelo através de um banco de dados relacional, de um banco
de dados orientado a objetos e de arquivos XML. Assim, o objetivo do trabalho em
questão é traçar estratégias para o armazenamento do metamodelo nessas três soluções,
apontando as diferenças entre as abordagens e possíveis vantagens e desvantagens de
usar cada uma delas.
5.2- As Características da Arquitetura Proposta
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 implementados em um
banco de dados orientado a objetos para que possam ser instanciados em tempo de
execução.
115
Isso significa que o sistema tem um código genérico (metamodelo) implementado em
uma linguagem orientada a objetos, que é 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.
Isto significa que os objetos da aplicação podem ser instanciados em máquinas
diferentes na rede, ocasionando, portanto, uma distribuição do código do sistema. O
middleware proverá a localização desses objetos, ou seja, em que máquina da rede eles
estarão disponíveis.
Isto significa que cada máquina da rede pode ter uma “visão” do metadado armazenado
no banco de dados. Entende-se por “visão”, neste contexto, uma determinada parte do
modelo de objetos adaptável que será instanciada naquela máquina.
Dessa forma, uma determinada máquina da rede tem acesso apenas à parte do modelo
de objetos adaptável que lhe cabe, instanciando apenas os objetos pré-definidos na
configuração do sistema.
Pode haver replicação de um objeto em mais de um nó na rede, e isto está relacionado
com o número de usuários que utilizam os serviços disponíveis nesse objeto, bem como
com a necessidade da disponibilidade de um determinado serviço em caso de falha.
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 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.
116
Pode-se dizer ainda que a arquitetura SICSDA é adaptável, porque será 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 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
Na arquitetura proposta, não é possível que regras de negócio sejam criadas em tempo
de execução, já que a criação de novas regras é, por si só, uma tarefa complexa e por
isso não foi considerada neste trabalho.
Esse assunto acabou originando o trabalho que está sendo desenvolvido em
Cardoso(2004). O trabalho em questão procura definir uma linguagem de alto nível,
específica para o domínio do sistema de controle de satélites, onde, em tempo de
execução, possam ser criadas novas regras de negócio através da composição de regras
simples e regras compostas definidas por essa linguagem.
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).
117
A Figura 5.1 ilustra a estrutura da arquitetura SICSDA. A seguir são detalhados os
elementos que compõe a Figura 5.1:
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.
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 etc, do satélite desejado. Além
disso, ele deve prover aos usuários (especialistas do domínio e desenvolvedores do
software) a interface para a autenticação no sistema.
118
• 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.
A opção pela divisão da arquitetura SICSDA em serviços surgiu como forma de se criar
uma infra-estrutura capaz de suportar uma arquitetura flexível, onde a necessidade de
incorporação de novos serviços para agregar novas funcionalidades, possa ser feita
causando o mínimo de impacto possível nos serviços já existentes.
FIGURA 5.1 - Arquitetura SICSDA.
Na arquitetura SICSDA, os objetos da aplicação se comunicam através de um
middleware, que implementa a arquitetura J2EE, podendo existir mais de uma cópia de
um objeto instanciado em nós diferentes da rede, conforme está detalhado a seguir:
J2EE
Aplicação Distribuída para o Controle de Satélites
Simulador de
Satélites Serviço de
Configuração
Serviço de
Usuário
Serviço de
Persistência
Serviço de
Carga
Sistema Operacional
Rede
Serviço de Adaptação
BD
Base de Configurações
119
• Telemetria: este objeto encapsula o estado interno do satélite, como por exemplo,
a voltagem de um determinado circuito, o posicionamento de uma determinada
chave (ligada ou desligada), como também os métodos inerentes ao objeto, tais
como processar telemetria, visualizar telemetria etc. Para este sistema as
telemetrias são subdivididas em:
♦Telemetria Analógica: monitora, por exemplo, o valor da voltagem de um
determinado circuito do satélite, podendo estar entre um limite superior e um
limite inferior.
♦Telemetria Digital: monitora o estado de uma determinada chave interna do
satélite, podendo esta estar ligada (valor armazenado = 1) ou desligada (valor
armazenado = 0).
♦Telemetria ModeEquation: representa um conjunto de telemetrias digitais.
• 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. Para este sistema os telecomandos são
subdivididos em:
♦Telecomando Manual: representa um telecomando que é enviado pelo
operador do satélite para a realização de algum procedimento durante uma
passagem do mesmo.
120
♦Telecomando Seqüencial: representa um conjunto de telecomandos agrupados
que podem ser enviados seqüencialmente para a realização de alguma tarefa
rotineira.
♦Telecomando Temporizado: são telecomandos que têm um tempo definido
para o envio.
• 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 em objetos a
aplicação para controle de satélites, foram atribuídos a este objeto 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. Para este sistema os
rangings são subdivididos em: medidas e calibração.
♦Medidas: contém a distância entre a antena e o satélite.
♦Calibração: contém a distância do equipamento de ranging até a antena.
• Satélite: este objeto contém as informações necessárias a respeito de um satélite,
como por exemplo, seu código, seu nome e o número de quadros (frames) que são
necessários para armazenar uma telemetria enviada por esse satélite.
121
• Subsistema: este objeto encapsula as informações a respeito dos subsistemas que
compõe um satélite, como por exemplo, o nome e o código de um determinado
subsistema. Exemplos de subsistemas para um satélite podem ser: Subsistema
Fornecimento de Energia (Power Supply Subsystem), Subsistema TMTC
(Telemetry e Telecommand Subsystem), Subsistema Supervisão a Bordo (Onboard
Supervision Subsystem) etc. Cada subsistema tem associado a ele um conjunto de
mensagens, que podem ser mensagens de telemetria, de telecomando e de ranging.
• Mensagem: este objeto representa as mensagens que chegam através de um frame
de um determinado satélite.
• Frame: este objeto encapsula as informações a respeito de um frame que é
recebido ou enviado pelo sistema de controle. Cada frame pode conter uma ou
mais mensagens. As informações essenciais que um objeto frame deve conter são:
o código do frame, a data e a hora de seu recebimento ou envio.
5.3- A Carga Inicial do Sistema
Considerando as políticas de segurança do sistema de controle de satélites, deve-se
estabelecer previamente um conjunto de nós para a implantação da arquitetura SICSDA.
Desta forma, apesar de o sistema ser distribuído, existe uma relação de nós onde os
objetos pertencentes ao sistema podem ser instanciados.
Na arquitetura SICSDA, carga inicial do sistema é representada pelo Serviço de Carga,
e é realizada em todos os nós escolhidos para a implantação da arquitetura proposta.
Para facilitar a informação de quais nós pertencem ao conjunto de máquinas onde a
arquitetura pode ser instanciada, pode-se manter uma base de dados, chamada de “Base
de Configurações” presente em cada nó, que contenha a relação dos nós pertencentes ao
122
sistema. A Figura 5.2 ilustra a execução da rotina de carga para os vários nós da
arquitetura proposta.
FIGURA 5.2 – A carga inicial do sistema.
A carga inicial do sistema em cada nó envolve, portanto:
1) A carga do serviço responsável pela persistência (Serviço de Persistência);
2) a carga do serviço responsável pela configuração (Serviço de Configuração);
3) a carga do serviço responsável pela interação com o usuário (Serviço de
Usuário);
4) a carga do serviço responsável pela instanciação e adaptação dos objetos (Serviço
de Adaptação) e
5) a carga do Simulador de Satélites.
Todos os serviços poderão ser instanciados em cada nó, com exceção do “Simulador de
Satélites”, que deverá ser instanciado em apenas um dos nós. Esse nó deve ter sido
previamente estabelecido e essa informação armazenada na Base de Configurações do
sistema.
Nó 3 Nó 2
Nó 1
Serviço de Carga
Serviço de Carga
Serviço de Carga
BD
123
5.4 – A Carga dos Metadados do Sistema
Para que o Serviço de Adaptação de cada nó possa carregar os objetos da aplicação
pertinentes àquele nó, ele deve previamente ter a informação de qual dos satélites será
monitorado naquele instante. Essa informação é de responsabilidade do Serviço de
Usuário e será abordada mais adiante.
Para que os objetos da aplicação do satélite escolhido possam ser carregados, eles
precisam, primeiramente, ser recuperados do dispositivo de armazenamento e
instanciados na memória. Para realizar tal tarefa o Serviço de Adaptação aciona o
Serviço de Persistência.
A disposição dos objetos da aplicação em nós diferentes faz com que cada máquina da
rede tenha uma “visão” do metadado armazenado no banco de dados, ou seja, faz com
que uma determinada máquina da rede tenha acesso apenas à parte do modelo de
objetos adaptável que lhe cabe.
5.5- A Interação do Usuário com o Sistema
O Serviço de Usuário é responsável pela interface entre os usuários (especialistas do
domínio e desenvolvedores do software) e a arquitetura proposta.
Primeiramente, o Serviço de Usuário deverá identificar o usuário para que se possa
disponibilizar as funções do sistema de acordo com o seu perfil. Isso é necessário, pois
cada tipo de usuário tem responsabilidades diferentes perante o sistema, e, portanto,
pode realizar apenas as atividades que lhe são pertinentes.
Por exemplo, um controlador de satélites tem a responsabilidade de monitorar as
telemetrias recebidas dos satélites; um engenheiro de satélites, por sua vez, concentra
sua atenção no funcionamento interno dos subsistemas de um satélite, como por
exemplo, o funcionamento da bateria.
124
Após a autenticação do usuário no sistema, este deve informar através de uma interface
disponibilizada pelo Serviço de Usuário, qual dos satélites ele deseja monitorar naquele
instante, o que significa que, atualmente, o usuário poderá escolher entre o
monitoramento dos satélites SCD1, SCD2 e CBERS2.
Após a escolha do satélite a ser monitorado, o usuário poderá, então, solicitar um
serviço ao sistema, como, por exemplo, visualizar a telemetria, enviar telecomando.
Para cada serviço solicitado deverá ser apresentada para o usuário uma interface de
acordo com os dados do satélite em questão, pois eles podem variar de um satélite para
outro.
5.6- A Escolha do Satélite a ser Monitorado
Quando o usuário escolhe o satélite a ser monitorado através da interface
disponibilizada pelo Serviço de Usuário, este imediatamente aciona o Serviço de
Adaptação, pois ele é responsável por carregar os objetos da aplicação.
Quando o usuário deseja monitorar outro satélite ele informa a decisão ao sistema
através da interface provida pelo Serviço de Usuário, e este aciona, novamente, o
Serviço de Adaptação, que imediatamente carrega os objetos da aplicação do novo
satélite.
Dessa forma, pode-se dizer que a aplicação, dependendo do satélite que está sendo
monitorado em um determinado instante, encontra-se em um dos estados ilustrados na
Tabela 5.1.
125
TABELA 5.1 – ESTADOS DA APLICAÇÃO
Estado 1
(SCD1)
Estado 2
(SCD2)
Estado 3
(CBERS2)
Os objetos que fazem parte
da monitoração do SCD1
devem estar instanciados.
Os objetos que fazem parte
da monitoração do SCD2
devem estar instanciados.
Os objetos que fazem parte
da monitoração do CBERS2
devem estar instanciados.
Isso significa que o metamodelo através do Serviço de Adaptação é capaz de “alternar”
entre os metadados dos satélites monitorados, ou seja, ele é capaz de realizar uma “troca
de contexto”, retirando do ar os objetos do satélite “A”, por exemplo, e instanciando os
objetos do satélite “B” em “cima” do mesmo metamodelo, para que o satélite “B” possa
ser monitorado.
5.7- O Atendimento da Solicitação de um Serviço
Quando o usuário solicita um serviço através da interface disponibilizada pelo Serviço
de Usuário o middleware verifica, primeiramente, se no nó onde o usuário está
conectado existem objetos da aplicação que atendam à solicitação desejada. Em caso
afirmativo, estabelece-se a conexão no próprio nó. Caso contrário, o middleware se
encarrega de recuperar aqueles objetos que atendam ao serviço solicitado,
estabelecendo-se a conexão com o objeto instanciado em um dos nós disponíveis.
Os dados referentes aos satélites para a simulação de um atendimento a uma
determinada solicitação de serviço poderão ser obtidos através do simulador de satélites.
126
5.8- A Configuração da Disposição dos Objetos
O usuário responsável pelo gerenciamento e manutenção do sistema (configurador)
deverá estabelecer através de uma interface disponibilizada pelo Serviço de
Configuração, a disposição dos objetos da aplicação nos nós onde a arquitetura SICSDA
está implantada.
Ao fazer isto, o configurador define, para cada satélite, quais objetos serão instanciados
em quais nós. Isto significa que cada máquina da rede poderá ter uma “visão” do
metadado referente àquele determinado satélite armazenado no banco de dados.
Dessa forma, uma determinada máquina da rede terá acesso apenas à parte do modelo
de objetos adaptável que lhe cabe, carregando através do Serviço de Adaptação apenas
os objetos pré-definidos pelo Serviço de Configuração do sistema.
Essa informação deverá ser armazenada na Base de Configurações através do Serviço
de Persistência. É perfeitamente possível que o configurador reorganize a disposição
dos objetos de cada satélite nos nós, e isso pode ser feito através da mesma interface
disponibilizada pelo Serviço de Configuração. Isso pode ser necessário por questões de
desempenho, por exemplo.
5.9- A Configuração Inicial dos Metadados
Como o modelo de objetos de cada satélite é representado como sendo metadados no
banco de dados, é necessário que para cada satélite seja configurado no banco de dados
o seu modelo de objetos adaptável.
Isso significa que, deve-se armazenar, para cada satélite, seu modelo de objetos no
banco de dados para que ele possa ser instanciado em momento oportuno.
127
O configurador será responsável por realizar esta tarefa, e a fará através de uma
interface disponibilizada pelo Serviço de Configuração. Nesta interface o configurador
poderá fornecer os dados dos objetos que compõem o modelo, bem como seus atributos,
métodos e relacionamentos. Esses dados serão armazenados no banco de dados para que
se possa montar o modelo de objetos real de um determinado satélite em tempo de
execução.
Para a realização desta tarefa, o Serviço de Configuração acionará o Serviço de
Adaptação, que, em tempo de execução, criará na memória os objetos que compõe o
modelo de objetos de cada satélite para que eles possam ser armazenados no banco de
dados, ou vice e versa.
Para realizar o armazenamento dos metadados, o Serviço de Adaptação acionará o
Serviço de Persistência, que se encarregará desta tarefa.
Para cada novo satélite lançado, pode-se configurar seu modelo de objetos no banco de
dados da mesma forma, desde que ele seja compatível com o metamodelo, podendo-se,
desta maneira, reaproveitar grande parte do desenvolvimento realizado em outras
missões.
Isso é possível, pois, uma vez criado o modelo de objetos que representa aquele novo
satélite, pode-se inseri-lo no banco de dados através do Serviço de Configuração e
torná-lo disponível para o uso, não sendo necessário que se realize toda a etapa de
codificação novamente.
5.10- A Re-configuração dos Metadados
Se o metadado de um determinado satélite precisar ser alterado para refletir mudanças
no domínio, o configurador poderá, através da mesma interface provida pelo Serviço de
Configuração para a configuração inicial dos metadados, realizar tais alterações.
128
Para que essas alterações possam ser realizadas o Serviço de Adaptação será acionado, e
novos objetos, atributos e relacionamentos poderão ser criados. Poderão ser também,
configurados novos métodos para os objetos.
Assim que as mudanças forem realizadas, elas devem ser refletidas no modelo de
objetos adaptável armazenado no banco ou vice e versa, e para isso o Serviço de
Adaptação deve acionar o Serviço de Persistência.
Assim que for modificado, o modelo de objetos adaptável deve estar disponível para o
uso, já com as alterações realizadas.
5.11- O Funcionamento do Sistema
Como já mencionado, a arquitetura SICSDA foi implementada em um domínio de rede
pré-definido. A dinâmica de interação em cada nó, entre os serviços e os objetos da
aplicação, é mostrada na Figura 5.3.
Nesta Figura, o Serviço de Carga foi duplicado para uma melhor disposição e clareza
das interações representadas. Cada seqüência de ativação no sistema foi representada
com um número que rotula as setas que indicam a ordem de ativação dos serviços e
objetos dentro daquela seqüência. Como os serviços e objetos participam de várias
seqüências de ativação diferentes, as setas que chegam e saem desses elementos podem
estar rotuladas com vários números separados por vírgulas.
A seguir é detalhado o funcionamento de cada seqüência de ativação do sistema
conforme a Figura 5.3. Para acompanhar cada seqüência basta seguir os rótulos das
setas que representam o número de cada uma dessas seqüências. Assim, tem-se:
129
1- Para que o sistema possa funcionar, primeiramente, o usuário (configurador)
deve armazenar os metadados referentes aos satélites a serem monitorados no banco
de dados. Isso pode ser feito através de uma interface apropriada fornecida pelo
Serviço de Configuração. O Serviço de Configuração, por sua vez, deve acionar o
Serviço de Adaptação para que ele possa criar esses objetos através do metamodelo.
O Serviço de Adaptação aciona o Serviço de Persistência para que os metadados
sejam armazenados.
2- É necessário também que o configurador estabeleça quais objetos serão
instanciados em quais nós, e isso também pode ser feito através de uma interface
provida pelo Serviço de Configuração. Essa informação é ser armazenada em uma
Base de Configurações através do Serviço de Persistência.
FIGURA 5.3 – A dinâmica da interação em cada nó entre os serviços e os objetos da
aplicação.
4
4
33
1,8
3
6
5,71,8
5,7
1,8
Aplicação
Serviço de Persistência
Serviço de Configuração
Serviço de Adaptação
Serviço de Usuário
Simulador de Satélites
2,9
2,9,4
5,7
BD
Base de Configurações
5,7
6
3
Serviço de Carga
Serviço de Carga
5,7
130
Realizadas as configurações necessárias para o funcionamento do sistema, ele está apto
para o uso. A seguir estão descritos os procedimentos principais ativados durante um
uso do sistema.
Em cada um dos nós pertencentes ao domínio de rede onde está implantada a arquitetura
SICSDA, deve-se realizar a carga inicial do sistema, representada em cada nó pelo
Serviço de Carga daquele nó.
3- A primeira ação realizada pelo Serviço de Carga de cada nó consiste em instanciar
os objetos do Serviço de Persistência, do Serviço de Configuração, do Serviço de
Usuário, e do Serviço de Adaptação em cada nó. Somente um dos nós contém o
Simulador de Satélites, e apenas o Serviço de Carga daquele nó é responsável por
instanciar este objeto.
Para que o Serviço de Adaptação possa carregar os objetos da aplicação, o usuário
(controladores de satélites e engenheiros de satélites) precisa escolher qual dos satélites
será monitorado naquele instante.
Porém, antes disso, o sistema precisa fazer a autenticação do usuário para que ele possa
adequar as funções disponibilizadas pelo sistema ao seu perfil. O usuário interage com o
sistema através do Serviço de Usuário.
4- O usuário fornece seus dados de autenticação através da interface disponibilizada
pelo Serviço de Usuário e este aciona o Serviço de Persistência para que a
autenticação do usuário possa ser realizada.
5- Após ter se autenticado, o usuário poderá escolher o satélite que deseja monitorar.
Quando isso acontece o Serviço de Usuário aciona o Serviço de Adaptação para que
ele carregue os objetos daquele satélite em especial. Esses objetos são instanciados
131
através do Serviço de Adaptação e recuperados do banco de dados através do Serviço
de Persistência.
6- Os objetos da aplicação estão distribuídos, então, quando o usuário solicita um
serviço ao sistema através do Serviço de Usuário, como, por exemplo, visualizar
telemetria, o middleware estabelece uma conexão com o objeto que atenderá a
requisição. Os dados referentes aos satélites podem ser obtidos através do Simulador
de Satélites.
7- Quando o usuário decide monitorar outro satélite, ele informa sua decisão através
da interface disponibilizada pelo Serviço de Usuário, que imediatamente solicita ao
Serviço de Adaptação que carregue os metadados do satélite escolhido. A
recuperação desses metadados é feita pelo Serviço de Persistência.
8- Se os metadados dos satélites precisarem ser alterados, o configurador pode fazer
isto através da interface provida pelo Serviço de Configuração. As mudanças são
realizadas através do Serviço de Adaptação e são imediatamente refletidas no
modelo armazenado no banco de dados através do Serviço de Persistência.
9- O configurador pode também, mudar a disposição dos objetos nos nós através de
uma interface provida pelo Serviço de Configuração. A nova configuração da
disposição dos nós deve ser armazenada na Base de Configurações. Essa operação
deve ser realizada pelo Serviço de Persistência.
5.12- O Controle de Versões
O controle de versões para sistemas baseados em modelos de objetos adaptáveis
apresenta aspectos um pouco diferentes em relação a um sistema orientado a objetos
132
tradicional. Isso acontece porque nesse tipo de sistema, o usuário pode, efetivamente,
realizar modificações no modelo do sistema em tempo de execução.
Essas modificações, por sua vez, poderão acarretar mudanças de comportamento do
sistema, o que torna necessário que se tenha um controle de versões não apenas em
relação a alterações no código do sistema, mas também, em relação a alterações nos
metadados que estão armazenados no banco de dados.
Neste trabalho não são especificadas estratégias para se implementar o controle das
versões do sistema e o armazenamento do histórico dos metadados. Na verdade,
considera-se que esse assunto seja suficientemente complexo para ser abrangido
inicialmente, e por isso, ele não é abordado de forma aprofundada.
Apesar disso, procurou-se identificar as situações que poderiam gerar uma nova versão
do sistema em questão, como uma forma de ressaltar a importância que deve ser dada
esse tipo de controle durante o ciclo de vida de um sistema.
Na arquitetura proposta, o usuário responsável por realizar mudanças nos metadados é o
configurador, o que significa que ele deverá ter a responsabilidade de controlar as
versões do sistema.
A cada nova inclusão de uma nova missão no sistema, e a cada mudança nos metadados
realizada pelo configurador, uma nova “versão” do sistema deverá ser gerada. Isso
significa que a configuração dos metadados antes da mudança deverá ser armazenada
para que se possa montar um histórico desses metadados.
Cada nova versão dos metadados gerada deverá ser disponibilizada imediatamente para
o usuário (operadores e engenheiros de satélites), e isso significa que o Serviço de
Adaptação deverá ser capaz de instanciar o modelo alterado na memória, e assim,
disponibilizá-lo para o uso.
133
Pode-se ter, também, a necessidade de se modificar o metamodelo, por exemplo, para
acomodar uma nova missão, ou a necessidade de se mudar o código de algum dos
serviços disponibilizados pela arquitetura; seja para a correção de um erro, para a
realização de alguma melhoria, ou até mesmo para a inclusão de um novo serviço. Esses
tipos de modificações, normalmente realizadas pelos desenvolvedores, também gerarão
uma nova versão do sistema.
Para esta arquitetura, a re-configuração da disponibilidade dos objetos da aplicação nos
nós não está sendo considerada como um elemento suficiente para gerar uma nova
versão do sistema, já que esse tipo de alteração não causa nenhuma mudança de
comportamento da aplicação. Portanto, mudanças desse tipo não implicarão na geração
de uma nova versão do sistema.
134
135
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 a construção dos serviços propostos no
Capítulo 6 deste trabalho. A seguir essas estratégias são sumarizadas:
1) Inicialmente, foram construídos modelos independentes de plataforma (PIMs)
para o Sistema de Controle de Satélites. Esta etapa compreendeu a construção de
um diagrama de casos de uso para o sistema, a construção de um diagrama de
pacotes para o sistema e a construção de um diagrama de classes representando
as classes do domínio do problema para o sistema.
2) Construídos os modelos independentes de plataforma para o sistema, cada
serviço que compõe a arquitetura foi detalhado sob o ponto de vista de seu
funcionamento. Para cada serviço foi construído um modelo independente de
plataforma representado por um diagrama de casos de uso para aquele serviço.
3) Construídos os modelos independentes de plataforma para cada serviço, cada um
dos serviços foi detalhado sob o ponto de vista de projeto através da construção
de seu modelo dependente de plataforma (PSM). Os modelos dependentes de
plataforma visam à arquitetura J2EE e foram apresentados como representações
gráficas de EJBs de sessão e de entidade.
4) O funcionamento do simulador de satélites foi detalhado e foram estabelecidas
as formas de comunicação e integração da arquitetura SICSDA com o
simulador.
5) O metamodelo para os satélites foi gerado através da aplicação de alguns dos
design patterns especificados no Capítulo 5 deste trabalho. Esta estratégia é
descrita e melhor detalhada no Capítulo 8 deste trabalho.
136
O processo de desenvolvimento adotado para a construção da arquitetura SICSDA está
baseado nos conceitos propostos pela Model Driven Architecture (MDA). Dessa forma,
pôde-se aliar os modelos de objetos adaptáveis, vistos por alguns como uma evolução
da MDA, às técnicas de modelagem e intercâmbio entre modelos propostos pela própria
MDA, acrescentando às mesmas, algumas medidas adicionais. Essas medidas adicionais
referem-se, principalmente, à obtenção do metamodelo e dos metadados do sistema,
etapa que é abordada durante o detalhamento da construção do Serviço de Adaptação no
Capítulo 8 deste trabalho.
Em termos de ciclo de vida do sistema, pode-se dizer que, na fase de “Análise” do
Sistema foi estudado sobre o domínio do problema em questão e foram construídos os
modelos independentes de plataforma (PIMs). Na fase de “Projeto” foram obtidos os
modelos dependentes de plataforma iniciais (PSMs), e na fase de “Implementação e
Testes” foram implementados, efetivamente, os modelos dependentes de plataforma, e a
arquitetura pode ser testada.
6.1- Conhecendo o Domínio do Problema
Para o desenvolvimento da arquitetura proposta, assim como para o desenvolvimento de
qualquer sistema de software, é necessário que se tenha inicialmente um profundo
conhecimento do domínio do problema em questão, sem o qual, é impossível modelar
um software que atenda aos requisitos estabelecidos pelos usuários e um sistema que
reflita realmente as necessidades do domínio.
Dessa forma, mesmo com a intenção de produzir um metamodelo para o sistema de
controle de satélites, é necessário que se conheça sobre o domínio do problema de cada
um dos satélites em questão. Para isso foi construído um modelo independente de
plataforma (PIM) que representa o sistema de controle para os satélites sendo
abordados, e que foi chamado de PIM de domínio.
137
O Capítulo 2 deste trabalho fornece uma visão básica do funcionamento e das funções
do Sistema de Rastreio e Controle e Satélites do INPE. Porém, para conhecer um pouco
mais sobre o funcionamento do Sistema de Controle de cada satélite monitorado,
assistiu-se a algumas passagens dos satélites no Centro de Controle de Satélites (CCS).
Foram realizadas, também, algumas entrevistas com operadores e engenheiros de
satélites, onde foram extraídas informações a respeito do funcionamento e operação do
Sistema de Controle de cada satélite monitorado.
Como além de suportar mudanças no domínio do problema de um determinado satélite,
a arquitetura SICSDA também permite que os metadados dos vários satélites possam ser
carregados pelo mesmo metamodelo, procurou-se construir um modelo para os satélites
onde cada satélite fosse constituído de um conjunto de subsistemas. Para um satélite
pode-se ter, basicamente, os seguintes subsistemas:
• Subsistema de Fornecimento de Energia (Power Supply Subsystem):
responsável pelo fornecimento de energia para o satélite.
• Subsistema de TMTC (Telemetry and Telecommand Subsystem): responsável
pelo envio de telecomandos e recebimento de telemetrias.
• Subsistema de Supervisão a Bordo (Onboard Supervision Subsystem):
responsável pelo armazenamento das telemetrias quando o satélite está fora de
visada.
• Subsistema de Controle de Atitude (Attitude Control Subsystem): responsável
por coletar os dados que serão utilizados para o cálculo da atitude do satélite.
• Subsistema de Coleta de Dados Payload (Data Collecting Payload Subsystem):
responsável pela coleta dos dados de carga útil de um satélite.
138
• Subsistema de Ranging (Ranging Subsystem): responsável por auxiliar o
processo de cálculo da distância do satélite para a Terra.
Como já enfatizado anteriormente, este trabalho não pretende, por inúmeras razões,
desenvolver um novo Sistema de Controle, e sim, propor uma nova arquitetura para o
mesmo e desenvolver um protótipo para validar as idéias propostas. Por este motivo, os
modelos aqui desenvolvidos concentram-se, principalmente, na obtenção de telemetrias
e envio de telecomandos de/para os satélites monitorados, e na obtenção de medidas de
distância e calibração.
Dessa forma, as inúmeras outras funções realizadas pelo Sistema de Controle, conforme
descrito no Capítulo 2 deste trabalho, e os outros subsistemas existentes, não foram
abordados em nossas considerações.
6.2- Construindo o Modelo Independente de Plataforma do Sistema
Fazendo-se um estudo mais apurado dos sistemas de controle dos satélites SCD1, SCD2
e CBERS2, pode-se notar que as diferenças entre os subsistemas pertencentes a cada um
desses satélites e entre os seus funcionamentos são pequenas e, conseqüentemente, suas
classes, atributos e métodos são praticamente os mesmos.
As diferenças básicas se dão, principalmente, nos valores possíveis para os atributos e
na quantidade de objetos instanciados em uma determinada classe. Por exemplo, o
satélite SCD1 tem 150 telemetrias diferentes, enquanto que o satélite SCD2 tem 145, e o
CBERS2 tem 2000.
Dessa forma, pode-se obter um diagrama de casos de uso único para representar o
Sistema de Controle dos três satélites, como ilustrado na Figura 6.1.
139
<<extends>>
<<extends>>
Usuário
Arma zena r Dado s Usu ári o
Consultar Dados AutenticaçãoAutenticar Usuário
<<extends>>
<<includes>>
Armazenar Metadados
Armazenar Nova Configuração
Configurar Metadados
Configurar Nós
Configurador
Carregar Sistema
Ca lcul ar Medidas
Escolher Satélite
Operador
Visualizar Telemetrias
Envi ar Telecom an do
FIGURA 6.1 – Diagrama de casos de uso para os satélites SCD1, SCD2 e CBERS2.
140
Analogamente, o diagrama de classes para representar as classes do domínio do
problema dos satélites SCD1, SCD2 e CBERS2, é mostrado na Figura 6.2. Este
diagrama foi concebido através de uma análise dos sistemas de controle de satélites
existentes e através de entrevistas realizadas com controladores e engenheiros de
satélites. A partir deste diagrama são realizadas todas as transformações através de
design patterns para que seja obtido o metamodelo para o sistema de controle de
satélites.
FIGURA 6.2 – Diagrama de classes para os satélites SCD1, SCD2 e CBERS2.
medidastempo_total
calcularMedidas()
calibracaotempo_solo
manual
analogicalimitevalorNominalInfvalorNominalSup
temporizadotempo
digitalvalorAlarme modeEquation
1..*1..*
rangingvalor
telecomandocodigoInternonumerodescricao
enviarTelecomando()armazenarTelecomando()
sequencial
1..*1..*
telemetrianumerodescricaowordprocessTypevalorMaxvalorMin
visualizarTelemetria()armazenarTelemetria()receberTelemetria()
subsistemanomecodigo
estacaonomelatitudelongitude
satelitecodigonomenum_frames 1..*1..*
mensagemnome
1..*1..*
framedatahoracodigo
11..* 11..*
1..*1 1..*1
1..*
1
1..*
1
141
Na Figura 6.2 tem-se:
• Os frames são recebidos e enviados pelo sistema de controle. Cada frame é
proveniente ou será enviado de/para uma das duas estações terrenas. Cada frame está
vinculado também a um determinado satélite, já que ele agrupa uma ou mais
mensagens de/para um determinado satélite.
• Cada satélite, por sua vez, possui um conjunto de subsistemas (por exemplo,
TMTC, Payload, Power Suply, etc.) associado a ele.
• Cada subsistema possui um conjunto de mensagens associadas a ele, sendo que
cada uma delas que pode ser, de acordo com o modelo, do tipo telemetria,
telecomando ou ranging.
• Cada mensagem telecomando pode ser do tipo seqüencial, manual ou temporizada,
sendo que cada mensagem telecomando seqüencial pode ser composta de uma ou
mais mensagens telecomando.
• Cada mensagem telemetria pode ser analógica, digital ou mode equation, sendo
que uma mensagem telemetria mode equation pode ser composta de uma ou mais
mensagens telemetria digital.
• Uma mensagem ranging pode ser do tipo medidas ou do tipo calibração.
É interessante ressaltar que, na concepção do diagrama da Figura 6.2, foi aplicado o
pattern Composite apresentado no capítulo 4, uma vez que um telecomando seqüencial
pode ser composto de vários telecomandos.
Na Figura 6.3 pode-se ter uma visão geral da arquitetura proposta. Esta figura mostra o
diagrama de pacotes para a arquitetura SICSDA, onde cada serviço da arquitetura é
visto como um pacote.
142
Serviço de Pers is tência
Serviço de Configuração
Serviço de Carga
Serviço de Us uá ri o
Serviço de Adaptação
<<ins tantia tes >>
<<ins tantia tes >>
<<ins tantia tes >>
<<ins tant ia tes >>
<<ins tantia tes >>
<<ins tantia tes >>
<<ins tantia tes >>
<<ins tantia tes >>
<<ins tantia tes >>
FIGURA 6.3 – Diagrama de pacotes da arquitetura SICSDA.
O diagrama de casos de uso da Figura 6.1, o diagrama de classes da Figura 6.2 e o
diagrama de pacotes da Figura 6.3 representam, então, modelos independentes de
plataforma (PIMs) para a arquitetura SICSDA.
A seguir, cada um dos serviços da arquitetura é detalhado em termos de suas
funcionalidades e principais aspectos de projeto e são apresentados os modelos
independentes (PIMs) e dependentes (PSMs) de plataforma para esses serviços.
A passagem de PIM para PSM foi realizada manualmente tomando-se como base o
UML-EJB Profile apresentado em SunMicrosystems(b)(2004).
Os detalhes da implementação prática de um ambiente para o protótipo da arquitetura
proposta são apresentados no Capítulo 9.
143
6.3- Construindo o Serviço de Configuração
O Serviço de Configuração provê a interface gráfica para que o configurador possa
realizar as seguintes tarefas:
1) Configurar os metadados iniciais de cada satélite para que eles possam ser
utilizados pelo sistema, ou seja, armazenar, para cada satélite, seu modelo no
banco de dados.
2) Alterar os metadados dos satélites armazenados no banco de dados para refletir
mudanças ocorridas no domínio.
Além disso, o Serviço de Configuração permite que o configurador estabeleça a
disposição dos objetos da aplicação nos nós onde a arquitetura SICSDA está
implantada, provendo a interface gráfica necessária para a comunicação com o
configurador e acionando os serviços necessários para que a configuração da disposição
dos objetos possa ser efetivada.
Assim sendo, o Serviço de Configuração interage diretamente com o Serviço de
Adaptação, no caso da configuração dos metadados; e interage diretamente com o
Serviço de Persistência, no caso da configuração dos nós.
A Figura 6.4 ilustra o diagrama de casos de uso para o Serviço de Configuração.
Ao prover uma interface que aciona ou requisita os serviços providos, respectivamente,
pelo próprio Serviço de Configuração ou pelos outros Serviços da arquitetura proposta;
o Serviço de Configuração isola a lógica da apresentação dos dados de configuração do
sistema, da lógica do negócio e da lógica do acesso aos dados.
144
<<extends>>
Apresentar InterfaceServiço de
Configuração
Requisitar Serviços
Obter Esco lh as Conf ig ura r Nós
<<extends >>
FIGURA 6.4 – Diagrama de casos de uso para o serviço de configuração.
Isso faz com que mudanças na apresentação das informações e na forma com que o
usuário interage com o sistema para realizar tais tarefas, tenham um impacto reduzido
no restante da aplicação, uma vez que a interface em si fica livre de conter o código que
implementa as funcionalidades do sistema e o acesso aos dados.
A interface provida pelo Serviço de Configuração foi representada, na fase de projeto do
sistema, ou seja, na fase de construção do modelo dependente de plataforma (PSM),
como sendo uma interface do lado do cliente que acessa os Enterprise Java Beans
(EJBs) publicados pelo servidor de aplicações, para que as tarefas pertinentes à
configuração do sistema possam ser realizadas.
Além da interface, o Serviço de Configuração é composto também de um EJB de sessão
que é responsável por efetivar a configuração dos nós, acessando para isso o Serviço de
Persistência. Na Figura 6.5 pode-se visualizar um exemplo do EJB de sessão do Serviço
de Configuração. Por questões de simplificação do modelo, nem todos os métodos que
comporiam o EJB de sessão desse serviço foram representados.
145
Conf igurationSessionBean
conf igurarNos()<<createMethod>> create()
<<<control>>> Conf igurationSessionBean
conf igurarNos()<<createMethod>> create()
<<<control>>>
FIGURA 6.5 – EJB de sessão do serviço de configuração.
A Figura 6.5 apresenta a visão externa desse EJB, ou seja, mostra apenas as partes do
EJB visíveis pelos clientes, que são: a interface local (home) e a interface remota
(remote). O estereótipo <<control>> foi utilizado para enfatizar que esse EJB é um EJB
de controle, e aparece em todos os EJBs de sessão ao longo deste texto. O estereótipo
<<createMethod>> indica que create() é um método da interface local utilizado para a
criação de uma instância do EJB. Os métodos da interface remota aparecem na figura
sem estereótipos (SunMicrosystems(b),2004).
Na Figura 6.6 a seguir, pode-se visualizar, de forma mais detalhada, a representação da
visão de um cliente do EJB de sessão do Serviço de Configuração. Essa representação
foi baseada em SunMicrosystems(b)(2004).
Para que o configurador possa estabelecer a disposição dos EJBs da aplicação nos nós
onde a arquitetura SICSDA está implantada, faz-se necessário que se mantenha na Base
de Configurações a informação de quais EJBs devem ser instanciados em quais
máquinas na rede.
146
ConfigurationSessionBean<<EJBSessionBean>>
ConfigurationHome
<<instantiate>>
ConfigurationHome
Configuration
<<EJBRemote Meth od>> conf ig ura rNo s()
<<EJBRemoteInterface>>
ConfigurationHome
<<EJBCreateMethod>> create()
<<EJBSessionHomeInterface>>
FIGURA 6.6 – A representação da visão de um cliente do EJB de sessão do serviço de
configuração.
Isso pode ser feito mantendo-se na Base de Configurações uma tabela, conforme
ilustrado na Tabela 6.1, que contenha a relação dos nomes dos EJBs que devem ser
instanciados em cada nó. Essa tabela é constituída dos seguintes campos: nome do EJB,
nó onde deve ser instanciado, e endereço de rede do nó.
147
TABELA 6.1 – NÓS/EJBS
Nome do EJB Nome da Máquina Endereço
SateliteBean lefkas 150.163.21.51
SubsistemaBean anafi 150.163.21.52
MensagemBean zitise 150.163.21.50
TipoMensagem skopelos 150.163.21.56
FrameBean lefkas 150.163.21.51
6.4- Construindo o Serviço de Usuário
O Serviço de Usuário é responsável por prover os mecanismos para que o usuário se
autentique no sistema, de forma que as funções do sistema possam ser disponibilizadas
para ele de acordo com o perfil adequado. Isso significa que o Serviço de Usuário provê
a interface gráfica para que o usuário se autentique e aciona os serviços necessários para
que a autenticação possa ser efetivada.
Além disso, o Serviço de Usuário provê a interface gráfica para que os controladores e
engenheiros de satélites possam realizar as seguintes tarefas:
1) Escolher qual dos satélites deseja-se monitorar em um determinado instante.
2) Solicitar um serviço ao sistema, como, por exemplo, visualizar telemetria, enviar
telecomando, etc.
Assim sendo, o Serviço de Usuário interage diretamente com o Serviço de Adaptação,
no caso da escolha de um satélite a ser monitorado e da solicitação de um serviço; e
com o Serviço de Persistência no caso da autenticação do usuário.
148
A Figura 6.7 ilustra o diagrama de casos de uso para o Serviço de Usuário.
<<extends>>
Aprese ntar InterfaceServiço de Usuário
Autenticar Usuário
Requisitar Serviços
Obter Escolhas
<<extends>>
FIGURA 6.7 – Diagrama de casos de uso para o serviço de usuário.
Ao prover uma interface que aciona ou requisita os serviços providos, respectivamente,
pelo próprio Serviço de Usuário ou pelos outros Serviços da arquitetura proposta; o
Serviço de Usuário, assim como o Serviço de Configuração, isola a lógica da
apresentação da autenticação e uso do sistema, da lógica do negócio e da lógica do
acesso aos dados.
A interface provida pelo Serviço de Usuário foi representada, na fase de projeto do
sistema, como sendo uma interface do lado do cliente que acessa os Enterprise Java
Beans (EJBs) publicados pelo servidor de aplicações para que as tarefas pertinentes à
autenticação e uso do sistema possam ser realizadas.
Além da interface, o Serviço de Usuário é composto também de um EJB de sessão que é
responsável por efetivar a autenticação do usuário no sistema, acessando para isso o
Serviço de Persistência.
149
Na Figura 6.8 pode-se visualizar um exemplo do EJB de sessão do Serviço de Usuário.
Por questões de simplificação do modelo, nem todos os métodos que comporiam o EJB
de sessão desse serviço foram representados.
UserSessi onBea n
autenticarUsuario()<<createMethod>> create()
<<<control>>>
FIGURA 6.8 – EJB de sessão do serviço de usuário.
Na Figura 6.9, pode-se visualizar a representação mais detalhada da visão de um cliente
do EJB de sessão do Serviço de Usuário.
UserSessionBean<<EJBSes sionBean>>
ConfigurationHome
Configuration
<<instantiate>>
ConfigurationHome
Configuration
<<EJBRemoteMethod>> autenticarUsuario()
<<EJBRemoteInterface>>
<<EJBCreateMethod>> create()
<<EJBSessionHomeInterface>>UserHome
User
FIGURA 6.9 – A representação da visão de um cliente do EJB de sessão do serviço de
usuário.
150
No Serviço de Usuário proposto, o mecanismo de autenticação do usuário tem a
finalidade de prover um acesso seguro à arquitetura SICSDA, permitindo que somente
usuários previamente cadastrados e autorizados possam usar o sistema.
A autenticação do usuário engloba a identificação do acesso, a identificação do grupo e
a concessão de privilégios para os usuários da arquitetura SICSDA.
A identificação de acesso engloba a solicitação de nome do usuário (username) e senha
(password). A identificação do grupo tem como objetivo identificar em que grupo de
usuários cadastrados no sistema um determinado usuário se encontra, pois, dependendo
do grupo, são concedidos ou não, a este usuário, determinados privilégios.
Por exemplo, existem, basicamente, dois tipos de usuários para a arquitetura SICSDA:
(1) os especialistas do domínio (2) e os desenvolvedores do software. Apenas os
usuários responsáveis pela configuração do sistema, sejam eles especialistas do domínio
ou desenvolvedores, têm o privilégio de modificar a configuração do sistema, como, por
exemplo, configurar os metadados do sistema, configurar a disposição dos EJBs nos
nós, etc.
Então, para que o usuário consiga se autenticar no sistema, faz-se necessário que se
mantenha na Base de Configurações as informações necessárias, como por exemplo, o
username, a password e o grupo a que este usuário pertence. Isso pode ser feito,
inicialmente, mantendo-se na Base de Configurações uma tabela, conforme ilustrado na
Tabela 6.2, que contenha a relação dos usuários cadastrados.
151
TABELA 6.2 – USUÁRIOS/GRUPOS
Nome do Usuário Senha Grupo
adriana adriana123 Configurador
mauricio mauricio123 Normal
Bosco bosco123 Normal
O mecanismo de autenticação de usuário proposto inicialmente é extremamente simples
e não leva em consideração uma série de requisitos importantes em relação à segurança
da autenticação, como, por exemplo, o cadastro de senhas impróprias ou fáceis de serem
descobertas.
Além disso, não foi explorada neste trabalho uma série de recursos de segurança
oferecidos pela plataforma J2EE, como, por exemplo, o controle de acesso do cliente a
determinados componentes através da definição de papéis, definição de domínios de
autenticação que podem ser usados durante o desenvolvimento do aplicativo, etc. Mais
detalhes sobre os recursos de segurança oferecidos pela plataforma J2EE podem ser
encontrados em SunMicrosystems (2004).
6.5 – Construindo o Serviço de Persistência
O serviço de Persistência disponibiliza, para os objetos persistentes da aplicação, os
serviços de acesso ao banco de dados e à base de configurações (armazenamento,
recuperação e exclusão).
Na arquitetura proposta os objetos persistentes nem sempre permanecem instanciados
no nó onde eles devem ser armazenados. Desta forma, o objetivo do serviço de
persistência é tornar transparente o acesso e a localização do banco de dados e da base
de configurações.
152
O Serviço de Persistência proposto tem, basicamente, as seguintes funcionalidades:
1) Ele é responsável por armazenar e recuperar do banco de dados os metadados do
sistema.
2) É responsável por armazenar e recuperar de uma base de configurações a
configuração da disposição dos objetos da aplicação nos nós.
3) É responsável por armazenar e recuperar de uma base de configurações os dados
de autenticação dos usuários.
A Figura 6.10 ilustra o diagrama de casos de uso para o Serviço de Persistência
proposto.
153
Armazenar Metadados
Armazenar Nova Configuração
Consultar Conf ig ura ção do s Nós
Armazenar Telecomando
Armazenar Telemetria
Serviço de Persistência
FIGURA 6.10 – Diagrama de casos de uso para o serviço de persistência.
O Serviço de Persistência proposto utiliza-se das facilidades para a persistência
oferecidas pela plataforma J2EE. Na realidade, na fase de projeto do sistema, esse
serviço é provido, de forma transparente, pelos EJBs de entidade projetados e por um
EJB de sessão auxiliar.
Na Figura 6.11 pode-se visualizar um exemplo do EJB de entidade que representa as
informações para a autenticação de um usuário no sistema. O estereótipo <<entity>> foi
utilizado para enfatizar que esse EJB representa uma entidade do domínio, e aparece em
154
todos os EJBs de entidade ao longo deste texto. O estereótipo <<finderMethod>> indica
um método localizador provido pela interface local.
UsuarioEntityBeann omesenhag rup o
g etNo me()g etSe nha()g etGrupo ()setNom e()setSenha ()setGrup o()<<createMethod>> cre ate ()<<finde rMethod >> findUsuari o()
<<<entity>>>
FIGURA 6.11 – Representação de um EJB de entidade.
Na Figura 6.12 a seguir, pode-se visualizar a representação mais detalhada da visão de
um cliente do EJB de entidade da Figura 6.11.
Como ilustrada na Figura 6.12, cada EJB de entidade tem uma classe de chave primária
que é responsável por manter os métodos requeridos a fim de processar as pesquisas
usando a chave primária do EJB. Essa classe que contém a chave primária é usada no
método localizador finderByPrimaryKey() para localizar o EJB de entidade por sua
chave primária. Essa classe deve suportar no mínimo os métodos hashCode() e
equals().
155
Dad os Us uar io<<EJBEntityBean>>
Us u ari o
<<EJBRem oteM ethod>> getNom e()<<EJBRem oteM ethod>> getSenha()<<EJBRem oteM ethod>> getGrupo()<<EJBRem oteM ethod>> setNom e()<<EJBRem oteM ethod>> setSenha()<<EJBRem oteM ethod>> setGrupo()
<<EJBRem oteInterface>>
Us u ari oHom e
<<EJBCreateM ethod>> create()<<EJBFinderM ethod>> findByPrim aryKey()<<EJBFinderM ethod>> findByNom e()
<<EJBEntityHom eInterface>>
<<ins tantiate>>
Us uari oKey
has hCode()equals ()
<<EJBPrim aryKey>>
Us u ari o
<<EJBRem oteM ethod>> getNom e()<<EJBRem oteM ethod>> getSenha()<<EJBRem oteM ethod>> getGrupo()<<EJBRem oteM ethod>> setNom e()<<EJBRem oteM ethod>> setSenha()<<EJBRem oteM ethod>> setGrupo()
<<EJBRem oteInterface>>
Us u ari oHom e
<<EJBCreateM ethod>> create()<<EJBFinderM ethod>> findByPrim aryKey()<<EJBFinderM ethod>> findByNom e()
<<EJBEntityHom eInterface>>
<<ins tantiate>>
Us uari oKey
has hCode()equals ()
<<EJBPrim aryKey>>
FIGURA 6.12 – A representação da visão de um cliente de um EJB de entidade.
O EJB de entidade que representa a informação dos objetos que devem ser instanciados
nos nós tem uma representação análoga à apresentada nas Figuras 6.11 e 6.12. Os EJBs
de entidade do domínio da aplicação são mais detalhados no capítulo 8 deste trabalho,
onde são apresentadas as diretrizes para a obtenção do metamodelo para os satélites.
O EJB de sessão do Serviço de Persistência contém os métodos que executam consultas
gerais no banco de dados, como, por exemplo, consultas para a listagem de todos os
objetos de uma determinada classe no banco de dados. Na Figura 6.13 pode-se
visualizar um exemplo do EJB de sessão do Serviço de Persistência. Por questões de
simplificação do modelo, nem todos os métodos que comporiam o EJB de sessão desse
serviço foram representados.
156
PersistenceSessionBean
listarSatelite()listarSubsistema()listarFrame()listarEstacao()listarMensagem()listarPropriedade()listarTipoMensagem()listarTipoPropriedade()listarTipoTipoMensagem()listarRelacionamento()listarTipoRelacionamento()listarEstrategia()pesquisarMensagem()getTelemetrias()<<createMethod>> create()
<<<control>>>
FIGURA 6.13 – EJB de sessão do serviço de persistência.
Na Figura 6.14 pode-se visualizar a representação mais detalhada da visão de um cliente
do EJB de sessão do Serviço de Persistência.
157
PersistenceSessionBean<<EJBSessionBean>>
ConfigurationHome
<<instantiate>>
Conf ig ura ti onHo meUserHome
Persistence
<<EJBRemoteMethod>> listarSatelite()<<EJBRemoteMethod>> listarSubsistema()<<EJBRemoteMethod>> listarFrame()<<EJBRemoteMethod>> listarEstacao()<<EJBRemoteMethod>> listarMensagem()<<EJBRemoteMethod>> listarPropriedade()<<EJBRemoteMethod>> listarTipoMensagem()<<EJBRemoteMethod>> listarTipoPropriedade()<<EJBRemoteMethod>> listarTipoTipoMensagem()<<EJBRemoteMethod>> listarRelacionamento()<<EJBRemoteMethod>> listarTipoRelacionamento()<<EJBRemoteMethod>> listarEstrategia()<<EJBRemoteMethod>> pesquisarMensagem()<<EJBRemoteMethod>> getTelemetrias()
<<EJBRemoteInterface>>
PersistenceHome
<<EJBCre ateMeth od>> crea te ()
<<EJBSessionHomeInterface>>
FIGURA 6.14 – A representação da visão de um cliente do EJB de sessão do serviço de
persistência.
O Serviço de Persistência interage diretamente com o Serviço de Adaptação, para o
armazenamento e carregamento dos metadados de um satélite; e com o Serviço de
Usuário e Serviço de Configuração, para o armazenamento e recuperação dos dados da
Base de Configurações.
158
6.6- Construindo o Serviço de Carga
O Serviço de Carga é responsável por dar a carga inicial do sistema. Assim sendo, o
Serviço de Carga tem a responsabilidade de executar a rotina inicial de carga do sistema
em cada nó onde a arquitetura SICSDA está implantada, realizando: (1) a carga do
Serviço de Persistência; (2) a carga do Serviço de Configuração; (3) a carga do Serviço
de Usuário; (4) a carga do Serviço de Adaptação e (5) a carga do Simulador de Satélites
(apenas no nó escolhido).
A Figura 6.15 ilustra o diagrama de casos de uso para o Serviço de Carga. Carregar os
serviços propostos na arquitetura SICSDA, significa, mais precisamente, publicar os
EJBs que compõe esses serviços nos nós onde a arquitetura está implantada, tornando-
os, assim, disponíveis para serem requisitados pelos clientes.
A rotina inicial de carga do sistema envolve, portanto, a realização, em cada nó, de
alguns procedimentos básicos. São eles:
1) Instanciar o servidor de aplicações J2EE.
2) Publicar no servidor de aplicações os EJBs dos serviços que devem ser
instanciados naquele nó.
3) Instanciar o simulador de satélites no nó escolhido, deixando-o, assim,
disponível para o uso.
4) Instanciar a aplicação cliente nos nós, deixando-a disponível para o uso.
159
<<includes>>
<<includes>>
<<includes>>
<<includes>>
<<extends>>
Serviço de Carga
Carregar Serviço de Persistência
Carregar Serviço de Configuração
Carreg ar Serviço de Usuári o
Carregar Serviço de Adaptação
Carregar Simulad or
Carregar Sistema
FIGURA 6.15 – Diagrama de casos de uso para o serviço de carga.
Estes procedimentos são realizados manualmente e devem seguir a disposição dos
nós/EJBs escolhida pelo configurador do sistema e armazenada na Base de
Configurações, como ilustra a Tabela 6.1. Dessa forma, essa tabela pode ser consultada
pelo usuário responsável por realizar a rotina inicial de carga sempre que for necessário
carregar o sistema.
160
6.7- Construindo o Serviço de Adaptação
O Serviço de Adaptação é responsável por prover o metamodelo que permitirá com que
efetivamente os objetos armazenados no banco de dados sejam instanciados, e que
possam ser modificados em tempo de execução.
O Serviço de Adaptação é responsável, então, por realizar as seguintes tarefas:
1) Possibilitar a criação dos metadados iniciais de cada satélite através do código
genérico implementado.
2) Instanciar na memória os metadados de um satélite, compondo, desta forma, o
modelo de objetos real para aquele satélite.
3) Possibilitar a alteração dos metadados de cada satélite através do código genérico
implementado.
A Figura 6.16 ilustra o diagrama de casos de uso para o Serviço de Adaptação.
O objetivo do Serviço de Adaptação é, então, prover o mecanismo para que os
metadados possam efetivamente ser criados, configurados, e instanciados em tempo de
execução.
O Serviço de Adaptação proposto consiste, basicamente, do metamodelo do sistema e
dos modelos para os satélites. Na verdade, o metamodelo foi representado, na fase de
projeto, através de classes no banco de dados (para que o modelo de cada satélite
pudesse ser armazenado), e foi representado na aplicação como sendo EJBs de entidade.
161
Configurar MetadadosServiço de Adaptação Instanciar Classes
In stanciar Atributos
Instanciar Relacionamentos
Instan ci ar Métodos
Instanciar Metadados
<<includes>>
<<includes>>
<<includes>>
<<includes>>
FIGURA 6.16 - Diagrama de casos de uso para o serviço de adaptação.
Além disso, o Serviço de Adaptação conta com um EJB de sessão que contém a
implementação dos métodos dos objetos do domínio da aplicação de controle de
satélites. Na Figura 6.17 pode-se visualizar um exemplo do EJB de sessão do Serviço de
Adaptação. Por questões de simplificação do modelo, nem todos os métodos que
comporiam o EJB de sessão desse serviço foram representados.
AdaptationSessionBean
visualizarTelemetrias()enviarTelecomando()calcularMedidas()<<createMethod>> create()
<<<control>>>
FIGURA 6.17 – EJB de sessão do serviço de adaptação.
162
Na Figura 6.18 pode-se visualizar a representação mais detalhada da visão de um cliente
do EJB de sessão do Serviço de Adaptação.
O Serviço de Adaptação interage diretamente com o Serviço de Persistência para a
criação, alteração e instancialização dos metadados do sistema. Na realidade, pode-se
dizer que os EJBs de entidade que representam o metamodelo do sistema fazem uso do
Serviço de Persistência para concretizar sua persistência na base de dados escolhida.
O Serviço de Adaptação é o foco principal deste trabalho, e como tal, é abordado mais
detalhadamente no Capítulo 8.
AdaptationSessionBean<<EJBSessionBean>>
ConfigurationHome
Conf igurati on
<<EJBRemoteMethod>> visualizarTelemetrias()<<EJBRemoteMethod>> enviarTelecomando()<<EJBRemoteMethod>> calcularMedidas()
<<EJBRemoteInterface>>
<<EJBCreateMethod>> create()
<<EJBSessionHom eInterface>>
<<instantiate>>
AdaptationHom e
Adaptation
FIGURA 6.18 – A representação da visão de um cliente do EJB de sessão do serviço de
adaptação.
163
6.8- Integrando a Arquitetura SICSDA com o Simulador de Satélites
O simulador de satélites referenciado neste trabalho foi implementado durante o
desenvolvimento da arquitetura SICSD. Na realidade, esse simulador incorpora apenas
algumas características, se comparado a um simulador de satélites real, porém, vem
sendo constantemente melhorado à medida que novos trabalhos vão sendo
desenvolvidos.
A finalidade principal do simulador de satélites é permitir o treinamento dos operadores
quanto ao controle e rastreio dos satélites, e prover um ambiente virtual que possa ser
usado para a elaboração dos testes de aceitação do software do Sistema de Controle de
Satélites.
Assim, o simulador de satélites desempenha as seguintes funções (Burgareli,2003):
• Simular características físicas necessárias à operação do satélite, como, por
exemplo, órbita, atitude, campo magnético, incidência de luz solar.
• Simular as funções dos subsistemas do satélite real, como por exemplo, telemetria,
telecomando, temperatura, medidas de distância, azimute, elevação, carga e
descarga da bateria e funções das estações de rastreio.
• Controlar o processo de simulação, ativando ou desativando as funções de acordo
com as solicitações do operador, como por exemplo, iniciação ou finalização do
processo de simulação.
164
• Prover a visualização e monitoração dos estados correntes do processo de
simulação.
• Prover o registro e a emissão de relatórios que descrevem configurações de
arquivos de configuração.
• Permitir a edição de arquivos de configuração.
• Permitir a inserção de falhas no satélite simulado.
O simulador de satélites é operado através da interface com o operador em um terminal
exclusivo onde o simulador é iniciado. O responsável pela simulação pode então,
acompanhar o andamento do processo, monitorando o estado do satélite simulado e
interagindo com o simulador a fim de exercer ações de controle ou provocar falhas.
Na realidade, como a arquitetura SICSDA foca a obtenção de telemetrias e o envio de
telecomandos de/para os satélites monitorados, e a obtenção de medidas de distância e
calibração; o simulador de satélites deve prover uma interface com a arquitetura
SICSDA que possibilite a interação e comunicação de forma a realizar essas atividades.
A Figura 6.19 ilustra a interação entre a arquitetura SICSDA e o simulador.
165
FIGURA 6.19 – Arquitetura SICSDA X simulador de satélites.
Assim, de acordo com a Figura 6.20, o simulador deve prover uma interface com a
arquitetura SICSDA de forma que:
1) Ao se enviar um telecomando específico, possa-se receber a sua telemetria
correspondente, lembrando que um telecomando pode ser enviado para, por
exemplo, ligar uma chave, desligar um sensor; ou seja, para alterar o estado de
algum equipamento.
2) Ao se enviar um pedido de visualização de telemetria, possa-se receber os
valores das telemetrias do satélite simulado.
3) Ao se enviar um pedido de obtenção de medidas de distância e calibração,
possa-se receber as medidas correspondentes.
Atualmente, o simulador de satélites provê interface apenas com o SICSD, o que
significa que para que ele possa ser utilizado pela arquitetura proposta neste trabalho,
SICSDA
Simulador de
Satélites
Enviar Telecomando
Enviar Telemetria Correspondente
Obter Medidas
Enviar Medidas
Visualizar Telemetria
Enviar Telemetrias
166
ele deve sofrer algumas alterações. Isso é necessário, pois o formato das telemetrias
recebidas e dos telecomandos enviados pela arquitetura SICSD é diferente do formato
proposto na arquitetura SICSDA. Assim sendo, para que possa haver interoperabilidade
entre a arquitetura SICSDA e o simulador existente é necessário que essas modificações
sejam incorporadas ao simulador.
167
CAPÍTULO 7 – ESTRATÉGIAS PARA A CONSTRUÇÃO DO SERVIÇO DE
ADAPTAÇÃO
Neste capítulo são abordadas as estratégias utilizadas para a construção do Serviço de
Adaptação proposto na arquitetura SICSDA. Dentre essas estratégias incluem-se
aquelas utilizadas durante a construção do modelo independente de plataforma, e
também durante o projeto do modelo dependente de plataforma para este serviço. A
seguir essas estratégias são sumarizadas:
1) Inicialmente, o metamodelo para os satélites foi gerado através da aplicação de
regras de mapeamento referenciadas nos patterns TypeObject, Property,
Accountability e Strategy apresentados no capítulo 4 deste trabalho. Esse
metamodelo foi chamado de modelo independedente de plataforma genérico
(PIM genérico) e foi representado através de um diagrama de classes.
2) A partir do PIM genérico, pode-se obter o modelo dependente de plataforma
(PSM) para esse metamodelo. Inicialmente, cada classe do metamodelo foi
projetada como uma classe no banco de dados, e seus atributos e tipos foram
especificados. Em seguida, foram acrescentados atributos de relacionamento
para essas classes e, finalmente, essas classes foram representadas como EJBs de
entidade.
3) Para uma melhor compreensão da dinâmica do funcionamento do Serviço de
Adaptação e do sistema em si, foram construídos alguns diagramas de seqüência
para os casos de uso que envolviam classes do metamodelo.
O metamodelo gerado deve ser implementado através de uma linguagem de
programação e funciona como uma máquina instanciadora de objetos, o que significa
que ele representa o “Serviço de Adaptação” proposto na arquitetura SICSDA; ou seja,
ele é capaz de instanciar os metadados que estão no banco de dados de acordo com o
168
satélite que se deseja monitorar em um determinado instante. Além disso, ele é capaz de
refletir mudanças feitas no domínio, o que significa que se o domínio mudar, as
mudanças podem ser refletidas na aplicação através do código genérico.
Com isso não é necessário realizar o processo de geração de código sempre que
mudanças acontecerem no domínio, já que as alterações podem ser realizadas nos
modelos armazenados no banco de dados através do metamodelo implementado. A
implementação deste serviço propriamente dita está detalhada no capítulo 9 deste
trabalho.
7.1- Construindo o Modelo Independente de Plataforma Genérico
Obtido o modelo independente de plataforma (PIM) de domínio apresentado na Figura
7.2, pôde-se obter o metamodelo que o representará. Esse metamodelo foi chamado de
modelo independente de plataforma (PIM) genérico, e foi obtido através de regras de
mapeamento que aplicam o uso de alguns dos design patterns especificados no Capítulo
5 deste trabalho.
O processo de transformar um modelo usando um design pattern é chamado de pattern-
based refactoring. Pode-se conseguir este processo através dos seguintes passos
(France,2003):
1) Identificar os elementos do modelo que irão participar de uma determinada
solução através de um determinado pattern. Modificá-los para que eles possam
se comportar como o pattern especificado.
2) Adicionar novos elementos ao modelo à medida que forem necessários para a
realização do comportamento especificado no pattern.
169
Dessa forma, o diagrama de classes da Figura 6.2 foi analisado sob o ponto de vista de
cada design pattern comumente encontrado em modelos de objetos adaptáveis, para que
fosse obtida a transformação do PIM de domínio em PIM genérico.
7.1.1- Aplicando o Pattern TypeObject
O primeiro pattern a ser aplicado é o TypeObject. A Figura 7.1 a seguir mostra o
diagrama da Figura 7.2 após a aplicação desse pattern.
tipoDeTelemetrianome_tipoTelemetrialimi tevalorNominalIn fvalorNominalSupvalorAlarmemodeEquation_Dig ital
telemetrianumerodescricaowordprocessTypevalorMaxvalorMin
visualizarTelemetria()armazenarTelemetria()receberTelemetria()
1
0..*
1
0..*tipoDeTelecomando
nome_tipoTelecomandotemposequencial_Telecomando
telecomandocodigoInternonumerodescricao
enviarTelecomando()arm azenarTelecom ando()
1
0..*
1
0..*tipoDeRanging
nome_tipoRangingtempo_totaltempo_solo
calcularMedidas()
rangingvalor
1
0..*
1
0..*
subsistemanome
estacaonomelatitudelongitude
satelitecodigonomenum_frames 1..*1..*
mensagemnome
1..*1..*
framedatahoracodigo
11..* 11..*
1..*1 1..*1
1..*
1
1..*
1
FIGURA 7.1 - Diagrama de classes após a aplicação do Pattern TypeObject.
170
Pode-se observar na Figura 7.1 que após a aplicação do pattern TypeObject, as
estruturas de herança existentes nas classes “telecomando”, “telemetria” e “ranging”
foram eliminadas, e foram acrescentadas as classes “tipodeTelecomando”,
“tipoDeTelemetria” e “tipoDeRanging” no diagrama de classes.
Os atributos e métodos comuns a todos os tipos de “telemetria”, “telecomando” e
“ranging” permaneceram nas classes “telemetria”, “telecomando” e “ranging,
respectivamente. Os atributos e métodos específicos de cada tipo foram trazidos para as
classes “tipoDeTelemetria”, “tipoDeTelecomando” e “tipoDeRanging”,
respectivamente.
Por exemplo, um “ranging” pode ser do tipo “medidas” ou “calibração”. Se ele for do
tipo “medidas”, terá como atributo específico: “tempo_total”. Se ele for “calibração”,
terá como atributo específico: “tempo_solo”. Esses atributos específicos foram trazidos
para a classe “tipoDeRanging”, sendo que os atributos comuns a todos os objetos
“ranging” permaneceram na classe “ranging”.
Porém, como se pode notar na Figura 7.1, ainda existe uma estrutura de herança que
pode ser eliminada, e por esta razão, o pattern TypeObject foi aplicado novamente. O
diagrama de classe resultante é apresentado na Figura 7.2.
171
tipoTipoMensagemnome_tipoMensagemcodigoInternowordprocessTyoevalorMaxvalorMinnumerodescricaovalor
enviarTelecomando()armazenarTelecomando()visualizarTelemetria()armazenarTelemetria()receberTelemetria()
subsistemanome
t ipoMensagemnome_tipoTelemetrialimitevalorNominalInfvalorNominalSupvalorAlarmemodeEquationDigitalnome_tipoTelecomandotemposequancial_Telecomandonome_tipoRangingtempo_totaltempo_solo
calcularMedidas()
10..* 10..*
estacaonomelatitudelongitude
satelitecodigonomenum_frames 1..*1..*
mensagemnome
1.. *1.. *
1
0..*
1
0..*
framedatahoracodigo
11..* 11..*
1..*1 1..*1
1..*
1
1..*
1
FIGURA 7.2 - Diagrama de classes após a aplicação do Pattern TypeObject novamente.
Pode-se observar na Figura 7.2 que após a aplicação do pattern TypeObject novamente,
a estrutura de herança existente na classe “mensagem” foi eliminada, e foram
acrescentadas as classes “tipoMensagem” e “tipoTipoMensagem” no diagrama de
classes.
Os atributos e métodos comuns a todos os tipos de “mensagem” permaneceram na
classe “mensagem”, e os atributos e métodos específicos de cada tipo foram trazidos
para a classe “tipoMensagem”. Por exemplo, uma “mensagem” pode ser do tipo
“seqüencial”, “manual”, “temporizado”, “analógica”, “digital”, “modeEquation”,
“medidas” ou “calibração”. Se ela for do tipo “temporizado”, terá como atributo
específico: “tempo”. Esses atributos específicos foram trazidos para a classe
172
“tipoMensagem”, sendo que os atributos comuns a todos os objetos “mensagem”
permaneceram na classe “mensagem”.
Adicionalmente, foi necessário criar a classe “tipoTipoMensagem”, já que cada
mensagem também pode ser do tipo “telemetria”, “telecomando” ou “ranging”. A
classe “tipoTipoMensagem” contém os atributos e métodos das classes “telecomando”,
“telemetria” e “ranging”, apresentadas na Figura 7.1.
7.1.2- Aplicando o Pattern Property
Como se pode observar na Figura 7.2, após a aplicação do pattern TypeObject, objetos
de tipos diferentes estarão todos em uma mesma classe “tipo”, o que significa que é
necessário adotar uma forma alternativa para implementar seus atributos.
Uma maneira de resolver esta questão é aplicar o pattern Property no modelo. A Figura
7.3 a seguir mostra o diagrama da Figura 7.2 após a aplicação desse pattern.
Como se pode observar na Figura 7.3, após a aplicação do pattern Property, os atributos
específicos de cada tipo representados na classe “tipo” foram eliminados, e foi
acrescentada a classe “propriedade”, que representará esses atributos. Por exemplo, na
classe “tipoTipoMensagem” foram eliminados os atributos: “word”, “processType”,
“valorMax”, “valorMin”, “número”, “descrição”, “valor” e “codigoInterno”.
173
estacaonomelatitudelongitude
tipoTipoMensagemnome_tipoTipo
enviarTelecomando()armazenarTelecomando()visualizarTelemetria()armazenarTelemetria()receberTelemetria()
subsistemanome
propriedadenome : Stringtipo : Stringvalor : String
tipoMensagemnome_tipoMensagemtipoTipoMensagemmodeEquation_Digitalsequencial_Telecomando
calcularMedidas()
10..* 10..*
0..*0..*
satelitecodigonomenum_frames 1..*1..*
mensagemnome
1..*1..*
0..*0..*
1
0..*
1
0..*
framedatahoracodigo
11..* 11..*
1..*1 1..*1
1..*
1
1..*
1
FIGURA 7.3 - Diagrama de classes após a aplicação do Pattern Property.
7.1.3- Obtendo a arquitetura TypeSquare
Com aplicação do pattern Property resolveu-se o problema de se ter atributos
específicos de diferentes tipos de entidades representados na mesma classe “tipo”,
porém, ainda assim, não é possível identificar quais propriedades pertencem a quais
tipos de entidades, uma vez que as propriedades estão associadas aos objetos da classe
“entidade” e não a objetos da classe “tipo”.
Para resolver este problema, a maioria das arquiteturas de modelos de objetos
adaptáveis aplica o pattern TypeObject antes e depois de se usar o pattern Property. Ou
seja, o pattern TypeObject divide o sistema em entidades e tipos de entidades. Entidades
174
têm atributos que podem ser definidos usando-se o pattern Property. Cada propriedade
(atributo) tem um tipo, chamado de “tipoDePropriedade”, e cada tipo de entidade pode
então, especificar os tipos das propriedades para suas entidades. A arquitetura resultante
depois de se aplicar esses patterns pode ser chamada de TypeSquare.
Dessa forma, o próximo pattern a ser aplicado é o TypeObject novamente, para que se
possa obter a arquitetura TypeSquare. A Figura 7.4 a seguir mostra o diagrama da
Figura 7.3 após a aplicação desse pattern.
tipoDePropriedadenome : Stringtipo : Type
tipoTipoMensagemnome_tipoTipo
enviarTelecomando()armazenarTelecomando()visualizarTelemetria()armazenarTelemetria()receberTelemetria()
0..*
1
0..*
1
subsistemanome
propriedadenome : Stringtipo : Stringvalor : String
1
0..*
1
0..*
t ipoMensagemnome_tipoMensagemtipoTipoMensagemmodeEquation_Digitalsequencial_Telecomando
calcularMedidas()
0..*0..*
0..*1 0..*1
10..* 10..*
estacaonomelatitudelongitude
satelitecodigonomenum_frames 1..*1..*
mensagemnome
1..*1..*
0..*0..*
1
0..*
1
0..*
framedatahoracodigo
11..* 11..*
1..*1 1..*1
1..*
1
1..*
1
FIGURA 7.4 - Diagrama de classes com a arquitetura TypeSquare.
Como se pode observar na Figura 7.4, após a aplicação do pattern TypeObject
novamente, pôde-se obter a arquitetura TypeSquare. Para tal, foi acrescentada ao
modelo a classe “tipoDePropriedade”. Dessa forma, torna-se mais simples verificar
quais tipos de entidades podem ter acesso a quais propriedades.
175
7.1.4- Aplicando o Pattern Accountability
Os atributos são propriedades que se referem a tipos de dados primitivos como, por
exemplo, números, strings, ou datas. As entidades usualmente têm uma associação
unária (one-way associations) com seus respectivos atributos.
Os relacionamentos, porém, são propriedades que se referem a outras entidades, e são
usualmente associações binárias (two-way associations). Para representar os
relacionamentos, foi aplicado o pattern Accountability. A Figura 7.5 a seguir mostra o
diagrama da Figura 7.4 após a aplicação desse pattern.
Como se pode observar na Figura 7.5, após a aplicação do pattern Accountability, foram
criadas as classes “relacionamento” e “tipoDeRelacionamento”. Os atributos de
relacionamento “modeEquation_Digital” e “seqüencial_Telecomando” que estavam na
classe “tipoMensagem” foram eliminados, e foram representados através de um
“relacionamento”.
176
tipoDePropriedadenome : Stringtipo : Type
tipoDeRelacionamentonomeclasse1classe2multiplicidade1multiplicidade2
tipoTipoMensagemnome_tipoTipo
enviarTelecomando()armazenarTelecomando()visualizarTelemetria()armazenarTelemetria()receberTelemetria()
0..*
1
0..*
1
0 .. *
1
0 .. *
1
subsistemanome
propriedadenome : Stringtipo : Stringvalor : String
1
0..*
1
0..*
relacionamentoclasse1classe2tipo
1
0..*
1
0..*
t ipoMensagemnome_tipoMensagemtipoTipoMensagem
calcularMedidas()
0..*0..*
0..*
1
0..*
1
0..*
1
0..*
1
0..*
1
0..*
1
10..* 10..*
estacaonomelatitudelongitude
satelitecodigonomenum_frames 1..*1..*
mensagemnome
1..*1..*
0..*0..*
0..*
1
0..*
1
1
0..*
1
0..*
framedatahoracodigo
11..* 11..*
1..*1 1..*1
1..*
1
1..*
1
FIGURA 7.5 - Diagrama de classes após a aplicação do Pattern Accountability.
7.1.5- Aplicando o Pattern Strategy
Para representar as regras de negócio foi aplicado o pattern Strategy. A Figura 7.6 a
seguir mostra o diagrama da Figura 7.5 após a aplicação desse pattern.
177
estacaonomelatitudelongitude
satelitecodigonomenum_frames
subsistemanome1..*
framedatahoracodigo
11..*1..*
1
relacionamentoclasse1classe2tipo
mensagemnome
1..*
0..*
1
1..*
1
1..*
1
t ipoDeRelacionamentonomeclasse1classe2multiplicidade1multiplicidade2
1
0..*
propriedadenome : Stringtipo : Stringvalor : String0..*
tipoMensagemnome_tipoMensagemtipoTipoMensagem
0..*
0..*
1
0..*
1
1
0..*
tipoTipoMensagemnome_tipoTipo
0..*
1
10..*
estrategianome0..*0..* 0..*0..*
0..*
0..*
0..*
0..*
tipoDePropriedadenome : Stringtipo : Type
1
0..*
0..*1
0..*
1
0..*
0..*
0..*
0..*
FIGURA 7.6 - Diagrama de classes após a aplicação do Pattern Strategy.
Como se pode observar na Figura 7.6, após a aplicação do pattern Strategy, foi criada a
classes “estratégia”. Os métodos das classes “tipoMensagem” e “tipoTipoMensagem”
foram eliminados, e foram representados através de uma “estratégia”.
Pode-se observar também que as classes “satélite”, “subsistema”, “estação” e “frame”
permaneceram intactas após a aplicação dos patterns desde a Figura 7.2 até a Figura
7.6. Isso é perfeitamente possível, pois não necessariamente todas as classes do domínio
têm que ser adaptáveis.
Na realidade, deve-se analisar, para a aplicação em questão, quais partes do sistema
precisam ou não ser adaptáveis em função das necessidades do domínio. No caso desta
178
aplicação específica, essas classes não foram consideradas como “adaptáveis”, uma vez
que dificilmente sofrerão mudanças em sua estrutura ao longo das várias missões.
Com o uso do pattern Strategy, torna-se possível que novos métodos sejam associados a
uma classe do domínio em tempo de execução, fazendo com que a arquitetura SICSDA
possa ser configurável em termos das regras de negócio associadas às suas classes do
domínio.
O pattern RuleObject não foi utilizado na obtenção do metamodelo, pois como
especificado na definição da arquitetura proposta, as regras do negócio para este
trabalho são configuráveis, mas não adaptáveis como propõe este pattern.
Assim, neste primeiro momento, não é possível criar novos métodos ou regras de
negócio em tempo de execução, o que significa que é possível apenas associar regras já
implementadas às classes do domínio.
Para que fosse possível criar novas regras de negócio em tempo de execução seria
necessário que se construísse uma linguagem de alto nível voltada para os especialistas
do domínio e também todas as ferramentas necessárias para o funcionamento adequado
desta linguagem como, por exemplo, debuggers, parsers, e interfaces apropriadas para a
construção de novas regras de negócio por parte dos especialistas do domínio.
Como as classes do domínio representadas pela classe genérica “tipoTipoMensagem”
não têm objetos diretos, constatou-se que o relacionamento existente entre as classes
genéricas “propriedade” e “tipoMensagem”; e “tipoMensagem” e “relacionamento”
podiam ser eliminados.
Entende-se por “objetos diretos” nesse contexto, o fato de que as classes do domínio
“telemetria”, “telecomando” e “ranging” são classes estéreis, uma vez que só suas
classes filhas têm objetos instanciados. Por exemplo, uma “mensagem” nunca será do
179
tipo “telecomando” simplesmente, ela sempre será ou um “telecomando seqüencial”, ou
um “telecomando manual”, ou um “telecomando temporizado”.
O diagrama de classes apresentado na Figura 7.7 já apresenta essas alterações. A Figura
7.7 representa, na realidade, a versão final do PIM genérico para o PIM de domínio
apresentado na Figura 7.2, após a aplicação dos patterns citados.
estacaonomelatitudelongitude
satelitecodigonomenum_frames
subsistemanomecodigoSatelite
1..*
framedatahoracodigonomeEstacaocodigoSatelite
11..*1..*
1
relacionamentoclasse1classe2tiponomeMensagem
mensagemnomecodigoFramenomeSubsistematipoMens agem
1..*
0..*
1
1..*
1
tipoDeRelacionamento
nomeclasse1classe2multiplicidade1multiplicidade2t ipoMensagemt ipoTipoMensagem1
0..*
propriedadenome : Stringtipo : Stringvalor : StringnomeMens agemtipoPropriedade
0..*
tipoMensagemnome_tipoMensagemtipoTipoMensagem
0..*
1
1
0..*
tipoTipoMensagemnome_tipoTipo
0..*
1
10..*
estrategianome0..*0..*
0..*
0..*
tipoDePropriedadenome : Stringtipo : TypetipoMensagemtipoTipoMensagem
1
0..*
0..*1
0.. *
1
0..*
0..*
FIGURA 7.7 – Modelo independente de plataforma genérico.
180
7.2- Projetando o Serviço de Adaptação
Obtido o modelo independente de plataforma genérico que representa o metamodelo
para o modelo independente de plataforma do domínio do sistema, pôde-se iniciar o
projeto do Serviço de Adaptação, que consistiu em se traçar estratégias para a futura
implementação do metamodelo, e conseqüentemente, para o armazenamento das classes
do domínio do sistema de controle de satélites, suas propriedades, relacionamentos e
métodos.
Na verdade, durante o projeto procurou-se associar o que foi estabelecido no modelo
independente de plataforma com as estruturas de armazenamento de dados e de
programação que precisaram ser definidas na plataforma de implementação do sistema,
o que significa que, nessa fase, iniciou-se o processo de construção do modelo
dependente de plataforma (PSM) para este serviço.
7.2.1- Projetando o Metamodelo
O metamodelo do sistema apresentado na Figura 7.7 deve ser implementado utilizando-
se uma linguagem de programação, o que significa que as classes mostradas nesse
metamodelo devem ser representadas como classes em uma linguagem de programação.
Na verdade, como a arquitetura proposta neste trabalho está baseada na plataforma
J2EE, cada classe representada no metamodelo deve ser implementada futuramente
como um EJB de entidade.
O metamodelo deve ser representado também no banco de dados para que seja possível,
futuramente, armazenar os metadados do domínio do sistema como instâncias desse
metamodelo. Como a arquitetura proposta faz uso de um banco de dados orientado a
objetos para o armazenamento dos metadados, cada classe mostrada na Figura 7.7
deverá estar igualmente implementada no banco de dados.
181
7.2.2- Projetando as Classes do Domínio
As classes do domínio do sistema representadas no diagrama de classes apresentado na
Figura 6.2 que serão adaptáveis deverão ser armazenadas no banco de dados como
instâncias de suas classes-tipo correspondentes, apresentadas no diagrama de classes
mostrado na Figura 7.7.
Por exemplo, as classes do domínio “telecomando”, “telemetria” e “ranging” serão
armazenadas no banco de dados como instâncias da classe genérica
“tipoTipoMensagem” apresentada na Figura 7.6. As classes “seqüencial”, “manual”,
“temporizado”, “analógica”, “digital”, “modeEquation”, “medidas” e “calibração”
serão armazenadas no banco de dados como instâncias da classe genérica
“tipoMensagem”.
As classes-tipo implementadas no código da aplicação e no banco de dados deverão
conter um atributo que represente seu “nome”, como ilustrado nas classes
“tipoMensagem” e “tipoTipoMensagem” da Figura 7.7.
O valor desse atributo deverá conter, para cada instância da classe-tipo, o nome do tipo
representado. Por exemplo, para uma instância da classe “tipoTipoMensagem” que
represente telemetria, o valor para o atributo “nome” desse objeto deverá ser
“telemetria”.
As Tabelas 7.1 e 7.2 mostram, respectivamente, as classes-tipo “tipoMensagem” e
“tipoTipoMensagem” e suas possíveis instâncias.
182
TABELA 7.1 – A CLASSE “TIPOMENSAGEM” E SUAS INSTÂNCIAS.
ID NOME
1 Seqüencial
2 Manual
3 Temporizado
4 Analógica
5 Digital
6 ModeEquation
7 Medidas
8 calibração
TABELA 7.2 – A CLASSE “TIPOTIPOMENSAGEM” E SUAS INSTÃNCIAS.
ID NOME
1 Telecomando
2 Telemetria
3 Ranging
As classes “satélite”, “subsistema”, “frame” e “estação” da Figura 7.2 não fazem parte
das classes que serão adaptáveis, e por isso foram mantidas na Figura 7.6 exatamente
como estavam representadas na Figura 7.2. Essas classes não têm classes-tipo
correspondentes, e por isso, devem ser armazenadas no banco de dados exatamente
como são.
183
7.2.3- Projetando os Objetos do Domínio
Os objetos do domínio do sistema que serão instâncias das classes adaptáveis deverão
ser armazenados no banco de dados como instâncias de suas classes-entidade
correspondentes, apresentadas no diagrama de classes mostrado na Figura 7.6.
Por exemplo, os objetos “Telecomando-Manual 001”, “Telecomando-Temporizado
032”, “Telemetria-Digital 014” etc., deverão ser armazenados no banco de dados como
instâncias da classe genérica “Mensagem”.
As classes-entidade implementadas no código da aplicação e no banco de dados deverão
conter atributos que representem seu “número” e sua “descrição”, como ilustrado na
classe “Mensagem” da Figura 7.6.
Os valores desses atributos deverão representar, respectivamente, para cada instância da
classe-entidade, o número e a descrição da entidade representada. Por exemplo, para
uma instância da classe “Mensagem” que representa o telecomando manual de número
001, o valor para o atributo “número” desse objeto deverá ser “001” e sua descrição
deverá conter o valor “Telecomando manual”.
A Tabela 7.3 mostra a classe-entidade “Mensagem” e alguns exemplos de suas
possíveis instâncias.
TABELA 7.3 – A CLASSE “MENSAGEM” E SUAS INSTÂNCIAS.
ID NÚMERO DESCRIÇÃO
1 001 Telecomando manual
2 014 Telemetria Digital
3 032 Telecomando Temporizado
184
Os objetos das classes “satélite”, “subsistema”, “frame” e “estação” não são instâncias
de classes adaptáveis, e por isso podem ser armazenados no banco de dados como
instâncias de suas próprias classes. As Tabelas 7.4, 7.5, 7.6 e 7.7 mostram,
respectivamente, alguns exemplos de instâncias para as classes “estação”, “frame”,
“subsistema” e “satélite”.
TABELA 7.4 – A CLASSE “ESTAÇÃO” E SUAS INSTÂNCIAS.
ID NOME LATITUDE LONGITUDE
1 Cuiabá -15.55 -56.07
2 Alcântara -2.31 -44.42
TABELA 7.5 – A CLASSE “FRAME” E SUAS INSTÂNCIAS.
ID DATA HORA
1 25/07/2004 10h:20m:30s
2 27/08/2004 23:h45m:10s
3 06/10/2004 00h:34m:08s
TABELA 7.6 – A CLASSE “SUBSISTEMA” E SUAS INSTÂNCIAS.
ID CÓDIGO NOME
1 001 Power Suply
2 054 TMTC
3 067 Onboard Supervision
4 123 Attitude Control
5 056 Data Collecting Payload
6 890 Ranging
185
TABELA 7.7 – A CLASSE “SATÉLITE” E SUAS INSTÂNCIAS.
ID CÓDIGO NOME NUM_FRAMES
1 001 SCD1 1
2 002 SCD2 1
3 003 CBERS2 6
7.2.4- Projetando as Propriedades
As propriedades das classes adaptáveis do domínio do sistema representadas no
diagrama de classes apresentado na Figura 7.2 deverão ser armazenadas no banco de
dados como instâncias da classe “tipoDePropriedade”, apresentada no diagrama de
classes mostrado na Figura 7.6.
Por exemplo, as propriedades da classe do domínio “telemetria” serão armazenadas no
banco de dados como instâncias da classe genérica “tipoDePropriedade” apresentada na
Figura 7.6. Isso significa que cada “telecomando” conhece os tipos de propriedades que
ele pode conter.
A classe “tipoDePropriedade” deve conter um atributo que represente o “nome” da
propriedade e seu “tipo”. Por exemplo, a classe do domínio “telemetria” contém o
atributo “word”. Esse atributo deverá ser representado como uma instância da classe
“tipoDePropriedade”, onde seu “nome” é “word” e seu tipo é “java.lang.integer”.
A Tabela 7.8 mostra a classe “tipoDePropriedade” e algumas de suas possíveis
instâncias, considerando que ela representa os atributos da classe do domínio
“telemetria”.
186
TABELA 7.8 – A CLASSE “TIPODEPROPRIEDADE” E SUAS INSTÂNCIAS.
ID NOME TIPO
1 word java.lang.integer
2 processType java.lang.integer
3 valorMax java.lang.float
4 valorMin java.lang.float
Os valores das propriedades dos objetos das classes adaptáveis do domínio do sistema,
deverão ser armazenados no banco de dados como instâncias da classe “propriedade”,
apresentada no diagrama de classes mostrado na Figura 7.7.
Por exemplo, o valor da propriedade “valorAlarme” para o objeto “Telemetria Digital
01” da classe do domínio “digital” deverá ser representado como uma instância da
classe genérica “propriedade”.
A classe “propriedade” deve conter um atributo que represente o “nome” da
propriedade, o seu “tipo” e o seu “valor”. Por exemplo, para a propriedade
“valorAlarme” com valor “50” do objeto “Telemetria Digital 01”, seu “nome” será
“valorAlarme”, seu “tipo” será “inteiro” e seu valor será “50”.
A Tabela 7.9 mostra a classe “propriedade” e uma de suas possíveis instâncias,
considerando que ela representa os valores dos atributos do objeto “Telemetria Digital
01” da classe do domínio “digital”. O objeto “Telemetria Digital 01” tem ainda outras
propriedades associadas, uma vez que ele herda os tipos de propriedades definidos para
a classe do domínio “telemetria”, porém, na tabela 7.9 foi representado apenas a
propriedade específica da classe do domínio “digital”.
187
TABELA 7.9 – A CLASSE “PROPRIEDADE” E SUAS INSTÂNCIAS.
ID NOME TIPO VALOR
1 valorAlarme integer 50
7.2.5- Projetando os Relacionamentos
Os relacionamentos que as classes adaptáveis do domínio do sistema têm com outras
classes, deverão ser armazenados no banco de dados como instâncias da classe
“tipoDeRelacionamento”, apresentada no diagrama de classes mostrado na Figura 7.7.
Por exemplo, as classes “digital” e “modeEquation” têm um relacionamento entre si, já
que uma telemetria modeEquation pode ser composta de uma ou mais telemetrias
digitais. Esse relacionamento deve ser representado como uma instância da classe
genérica “tipoDeRelacionamento” apresentada na Figura 7.6. Isso significa que as
classes “digital” e “modeEquation” conhecem o tipo de relacionamento que elas podem
ter.
A classe “tipoDeRelacionamento” deve conter um atributo que represente o “nome” do
relacionamento, os atributos “classe1” e “classe2” que devem conter as classes
participantes do relacionamento, e os atributos “multiplicidade1” e multiplicidade2” que
representam a cardinalidade do relacionamento para ambas as classes.
Por exemplo, as classes do domínio “digital” e “modeEquation” tem um
relacionamento cujo “nome” poderá ser “digital-modeEquation”, “classe1” poderá ter o
valor “digital”, “classe2” poderá ter o valor “modeEquation” , “multiplicidade1” terá o
valor “1..*”, e “multiplicidade2” terá o valor “1”.
A Tabela 7.10 mostra a classe “tipoDeRelacionamento” e suas possíveis instâncias.
188
TABELA 7.10 – A CLASSE “TIPODERELACIONAMENTO” E SUAS
INSTÂNCIAS.
ID NOME CLASSE 1 CLASSE 2 MULT 1 MULT 2
1 digital-
modeEquation
digital modeEquation 1..* 1
2 telecomando-
seqüencial
telecomando seqüencial 1..* 1
Os objetos que compõe um relacionamento entre objetos das classes do domínio
adaptáveis devem ser representados como instâncias da classe genérica
“relacionamento”. Por exemplo, o objeto “telemetria mode-Equation 035” da classe do
domínio “modeEquation” pode ser composto dos objetos “telemetria digital 01” e
“telemetria digital 02” da classe do domínio “digital”. O objeto “telecomando
seqüencial 089” da classe do domínio “seqüencial” pode ser composto dos objetos
“telecomando manual 90”, “telecomando temporizado 67” e “telecomando seqüencial
029”, das classes do domínio “manual”, “temporizado” e “seqüencial”, respectivamente.
A classe “relacionamento” deve conter os atributos “objeto1” e “objeto2” indicando os
nomes dos objetos participantes do relacionamento, e o atributo “tipo” indicando o tipo
de relacionamento. Por exemplo, o objeto “telemetria mode-Equation 035” tem um
relacionamento cujo tipo é “digital-modeEquation” com o “objeto” “telemetria digital
01”; e também tem um relacionamento cujo tipo é “digital-modeEquation” com o
“objeto” “telemetria digital 02”.
A Tabela 7.11 mostra a classe “relacionamento” e algumas de suas possíveis instâncias.
189
TABELA 7.11 – A CLASSE “RELACIONAMENTO” E SUAS INSTÂNCIAS.
ID OBJETO 1 OBJETO 2 TIPO
1 telemetria mode-Equation
035
Telemetria digital 01 digital-modeEquation
2 telemetria mode-Equation
035
Telemetria digital 02 digital-modeEquation
7.2.6- Projetando as Regras de Negócio
Cada regra de negócio pertencente às classes de domínio adaptáveis deverá ser
representada no banco de dados como uma instância da classe genérica “estratégia”. A
classe “estratégia” deve conter um atributo “nome” que representa o nome da regra de
negócio. Por exemplo, a classe do domínio “telemetria” possui três regras de negócio
que são: “visualizarTelemetria”, “armazenarTelemetria” e “receberTelemetria”. Cada
uma dessas regras deve ser representada como uma instância da classe “estratégia”,
onde o atributo “nome” vale, respectivamente, “visualizarTelemetria”,
“armazenarTelemetria” e “receberTelemetria” para cada uma das regras citadas.
A Tabela 7.12 mostra a classe “estratégia” e algumas de suas possíveis instâncias.
TABELA 7.12 – A CLASSE “ESTRATÈGIA” E SUAS INSTÂNCIAS.
ID NOME
1 visualizarTelemetria
2 armazenarTelemetria
3 receberTelemetria
190
É importante ressaltar que, de acordo com a estratégia de representação das regras de
negócio definida para este trabalho, apenas os nomes das regras serão armazenados no
banco de dados. O código dos métodos das classes de negócio será, portanto,
implementado via linguagem de programação e residirá no código da aplicação.
O usuário configurador poderá escolher, em tempo de execução, de dentro de um
conjunto de regras disponíveis, quais delas ele deseja associar a cada classe do domínio,
representadas na Figura 7.6 como instâncias das classes “tipoMensagem” e
tipoTipoMensagem”. Uma vez associadas a um objeto das classes “tipoMensagem” e
tipoTipoMensagem”, essas regras poderão ser executadas pelo objeto normalmente.
7.2.7- Acrescentando os Atributos de Relacionamento
O diagrama de classes apresentado na Figura 7.7 não mostra o projeto dos
relacionamentos entre as classes genéricas. Porém, para que esse metamodelo possa ser
implementado futuramente, é necessário que se projete quais classes “conhecerão” quais
classes, sendo necessário que se inclua, no diagrama de classes, os atributos de
relacionamento necessários para representar os relacionamentos entre as classes
genéricas.
Na Figura 7.8 pode-se visualizar o diagrama de classes da Figura 7.7 já incluindo os
atributos de relacionamento das classes genéricas; além das classes de associação
“est_TipoProp“, “est_TipoMens“ e “estTipoTipoMens”, que são decorrentes dos
relacionamentos muitos para muitos existentes. A Figura 7.8 inclui também o tipo de
cada atributo.
191
estacaonome : Stringlatitude : floatlongitude : float
satelitecodigo : in tegernome : Stringnum_frames : integer
subsistemanome : StringcodigoSateli te : integer
1..*
framedata : Stringhora : Stringcodigo : integernomeEstacao : Str ingcodigoSateli te : integer
11..*
1..*
1
relacionamentoclasse1 : Stringclasse2 : Stringtipo : StringnomeMensagem : String
mensagemnome : StringcodigoFrame : integernomeSubsistem a : StringtipoMensagem : String
1 .. *
0..*
1 1..*
1
1..*
1
tipoDeRelacionamentonome : Stringclasse1 : Stringclasse2 : Stringmul tipl icidade1 : Stringmul tipl icidade2 : StringtipoMensagem : StringtipoTipoMensagem : String1
0..*
propriedadenome : Stringtipo : Stringvalor : StringnomeMensagem : StringtipoPropriedade : String
0..*
tipoMensagemnome_tipoMensagem : StringtipoTipoMensagem : String
0..*
1
1
0..*
tipoTipoMensagemnome_tipoTipo : String
0.. *
1
10..*
estrategianome : String0..*0..* 0..*0..*
0..*
0..*
0..*
0..*
tipoDePropriedadenome : Stringtipo : TypetipoMens agem : StringtipoTipoMens agem : String
1
0..*
0..*1
0..*
1
0..*
0..*
0..*
0..*
est_tipoPropnomeT ipo Pro p : StringnomeEstrateg ia : St ring
est_tipoTipoMensnomeTipoTipo : StringnomeEstrategia : String
est_tipoMensnomeMensagem : StringnomeEstrategia : String
FIGURA 7.8- Atributos de relacionamento.
7.2.8- Representando as Classes como Enterprise Java Beans
Após a inclusão no diagrama de classes dos atributos de relacionamento, faz-se
necessário direcionar 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 7.8 foi representada na Figura 7.9 como
sendo um Enterprise Java Bean de entidade.
192
estacaoEntityBeannome : Stringlatitude : floatlongitude : float
<<createMethod>> create()<<finderMethod>> findEstacao()
<<entity>>sateliteEntityBean
codigo : integernome : Stringnum_frames : integer
<<createMethod>> create()<<finderMethod>> findSat()
<<entity>>
subsistemaEntityBeannome : StringcodigoSatelite : integer
<<createMethod>> create()<<finderMethod>> findSub()
<<entity>>
1..*
frameEntityBeandata : Stringhora : Stringcodigo : integernomeEstacao : StringcodigoSatelite : integer
<<createMethod>> create()<<f inderMethod>> findFrame()
<<entity>>
11..*
1..*
1
relacionamentoEntityBean
classe1 : Stringclasse2 : Stringtipo : StringnomeMensagem : String
<<createMethod>> create()<<finderMethod>> findRel()
<<entity>>
mensagemEntityBeannome : StringcodigoFrame : integernomeSubsistema : StringtipoMensagem : String
<<createMethod>> create()<<finderMethod>> findMens()
<<entity>>
1..*
0..*
1 1..*
1
1..*
1
tipoDeRelacionamentoEntityBean
nome : Stringclasse1 : Stringclasse2 : Stringmultiplicidade1 : Stringmultiplicidade2 : StringtipoMensagem : StringtipoTipoMensagem : String
<<createMethod>> create()<<finderMethod>> findTipoRel()
<<entity>>
1
0..*
propriedadeEntityBeannome : Stringtipo : Stringvalor : StringnomeMensagem : StringtipoPropriedade : String
<<createMethod>> create()<<finderMethod>> findProp()
<<entity>>
0..*
tipoMensagemEntityBeannome_tipoMensagem : StringtipoTipoMensagem : String
<<createMethod>> create()<<finderMethod>> findTipoMens()
<<entity>>
0..*
1
1
0..*
tipoTipoMensagemEntityBean
nome_tipoTipo : String
<<createMethod>> create()<<finderMethod>> findTTMens()
<<entity>>
0..*
1
1
0..*estrategiaEntityBean
nome : String
<<createMethod>> create()<<finderMethod>> findEst()
<<entity>>0..*
0..*
0..*
0..*
0..*0..* 0..*0..*
tipoDePropriedadeEntityBean
nome : Stringtipo : TypetipoMensagem : StringtipoTipoMensagem : String
<<createMethod>> create()<<finderMethod>> findTProp()
<<entity>>
1
0..*
0..*
1
0..*
1
0..*
0..*
0..*
0..*
est_tipoPropEntityBeannomeTipoProp : StringnomeEstrategia : String
<<createMethod>> create()<<finderMethod>> findEst_TP()
<<entity>>
est_tipoTipoMensEntityBean
nomeTipoTipo : StringnomeEstrategia : String
<<createMethod>> create()<<finderMethod>> findEst_TM()
<<entity>>
est_tipoMensEntityBeannomeMensagem : StringnomeEstrategia : String
<<createMethod>> create()<<finderMethod>> findEst_TipoM()
<<entity>>
FIGURA 7.9- Classes representadas como Enterprise Java Beans de entidade.
193
Na Figura 7.9, por questões de simplificação, não são mostrados os métodos providos
pela interface remota dos EJBs de entidade (gets e sets para cada atributo), mas apenas
os métodos providos pela interface local.
7.2.9- Construindo os Diagramas de Seqüência
Para que fosse possível ter um entendimento adequado da dinâmica do funcionamento
do Serviço de Adaptação, foram construídos diagramas de seqüência para os casos de
uso que envolviam as classes adaptáveis do metamodelo. Por questões de simplificação,
apenas alguns desses diagramas são apresentados no texto.
O objetivo principal da apresentação desses diagramas é enfatizar que, como as classes
do metamodelo são genéricas, conseqüentemente, os diagramas de seqüência que
representam a requisição de serviços do sistema também serão representados, pelo
menos parcialmente, de forma genérica. Isso torna possível que poucos diagramas de
seqüência (em relação a um sistema orientado a objetos tradicional) consigam
representar todas as funcionalidades do sistema.
Dessa forma, pode-se dizer que as arquiteturas que são baseadas em modelos de objetos
adaptáveis têm, pelo menos parte de sua funcionalidade, representada de forma
genérica. Na realidade, como uma classe genérica pode representar várias classes do
domínio da aplicação, é possível que diagramas de seqüência que representariam
funcionalidades diferentes do sistema, sejam fundidos em um único diagrama mais
genérico.
Neste trabalho, como as classes do domínio da aplicação foram representadas através de
classes genéricas no metamodelo, sempre que elas forem ativadas no diagrama de
seqüência para cumprir alguma funcionalidade da aplicação, elas serão apresentadas
através de sua classe genérica. Isso significa que classes do domínio da aplicação que
são representadas pela mesma classe no metamodelo são apresentadas de forma única
no diagrama de seqüência.
194
Na Figura 7.10 é apresentado o diagrama de seqüência que representa a criação de um
novo tipo de mensagem. Deve-se notar que para qualquer tipo de mensagem, por
exemplo, “telecomando temporizado”, “telemetria analógica”, “ranging medidas” etc.,
o diagrama de seqüência é o mesmo, uma vez que a classe “tipo Mensagem” é genérica.
tipoMensagem:tipoMensagemEntityBean
Interface do Serviço de Configuração
persistence:PersistenceSessionBeanConfigurador : <Actor
Name>
3:RecuperarTiposPropriedades(tipoTipoMensagem)
2:EJBcreate( )
1:AdicionarTipoMensagem(tipoTipoMensagem, codigo, nome)
9:Confirmação
4:EJBcreate()
5:setCodigo(codigo)
6:setNome(nome)
7:setTipoTipo(tipoTipoMensagem)
8:setTiposPropriedades(tiposProps)
FIGURA 7.10 – Diagrama de seqüência para adicionar um novo tipo de mensagem.
De acordo com a Figura 7.10, o usuário configurador através da interface provida pelo
Serviço de Configuração, dispara a criação de um novo tipo de mensagem. A criação
desse novo tipo de mensagem faz com que, em tempo de execução, o modelo de objetos
do domínio da aplicação seja alterado. Essa alteração deve ser refletida nos metadados
armazenados no banco de dados para que a modificação seja efetivamente realizada.
A interface do Serviço de Configuração na Figura 7.10 solicita a criação de uma
instância do EJB de sessão do Serviço de Persistência e aciona o método
“RecuperarTiposPropriedades” desse EJB, fornecendo o tipo do novo tipo de mensagem
a ser criada. O EJB de sessão do Serviço de Persistência recupera os tipos de
propriedades já criados para o tipo do tipo da mensagem a ser criada. A interface do
195
Serviço de Configuração, solicita a criação de uma instância do EJB de entidade
“tipoMensagemEntityBean” e aciona os métodos “setCodigo”, “setNome”,
“setTipoTipo” e “setTiposPropriedades” desse EJB, passando como parâmetro os
valores recebidos da interface, no caso de código, nome e tipo do tipo, e valores
recebidos do EJB de sessão do Serviço de Persistência no caso dos tipos de
propriedades. A instância de “tipoMensagemEntityBean” criada é atualizada com os
valores passados como parâmetros nos métodos “setCodigo”, “setNome”,
“setTipoTipo” e “setTiposPropriedades”, e solicita a atualização de sua classe
correspondente no banco de dados. Finalmente, a interface do Serviço de Configuração
envia para o usuário uma mensagem de sucesso ou não da operação.
O diagrama de seqüência apresentado nas Figuras 7.10 ilustra seqüências de ativação de
métodos acionadas durante a inserção dos metadados no banco de dados através do
Serviço de Configuração.
O diagrama de seqüência apresentado na Figura 7.11, no entanto, ilustra seqüências de
ativação de métodos acionados durante o uso do sistema em si, por exemplo, durante a
visualização de uma telemetria, a emissão de um telecomando ou a obtenção de medidas
de distância e calibração. Deve-se notar que, independentemente do tipo de operação
realizada, o diagrama de seqüência é o mesmo, uma vez que as classes do metamodelo
são genéricas.
De acordo com a Figura 7.11, o usuário solicita a ativação de uma operação para a
interface do Serviço de Usuário. Esta operação pode ser “Visualizar Telemetria”,
“Enviar Telecomando” ou “Obter Medidas”.
A interface do Serviço de Usuário, por sua vez, solicita uma conexão com o simulador,
enviando juntamente com o pedido de conexão, a operação solicitada pelo usuário, o
valor associado a essa operação, e o satélite do qual deseja-se solicitar a operação.
196
O “valor associado à operação” é particularmente importante no caso de “Enviar
Telecomando”, pois para um determinado telecomando enviado, o simulador deve
devolver a telemetria correspondente àquele telecomando específico.
No caso de “Visualizar Telemetria” e “Obter Medidas” não existe valor associado à
operação, já que, ao receber a solicitação de visualização de telemetria o simulador deve
devolver todas as telemetrias associadas àquele satélite; e ao receber a solicitação de
obtenção de medidas, o simulador deve devolver o valor das medidas e calibração do
satélite correspondente.
Após a obtenção da conexão com o simulador, este envia para a interface do Serviço de
Usuário o frame ou os frames contendo a resposta à operação solicitada. A interface do
Serviço de Usuário solicita a criação de uma instância do EJB de sessão do Serviço de
Adaptação, e enquanto existirem frames, solicita à instância de
“AdaptationSessionBean” que instancie aqueles frames.
É importante ressaltar que, os frames enviados pelo simulador dependerão da operação
solicitada, por exemplo, se for solicitada a visualização de telemetria, os frames
enviados conterão todas as telemetrias associadas ao satélite sendo simulado. Se for
solicitado o envio de um telecomando, o frame, ou os frames enviados conterão a
telemetria correspondente àquele telecomando. Se for solicitada a obtenção de medidas,
o frame, ou os frames enviados conterão os valores de medidas e calibração para o
satélite sendo simulado.
Instanciar o frame significa, primeiramente, criar uma instância do EJB de entidade
“frameEntityBean”, e em seguida atualizar seus atributos com os valores
correspondentes. Além disso, deve-se, para todas as mensagens recebidas no frame,
criar uma instância do EJB de entidade “mensagemEntityBean”, e em seguida atualizar
seus atributos com os valores correspondentes.
197
Cada mensagem, por sua vez, pode ter várias propriedades, e deve-se, para todas as
propriedades associadas à mensagem, criar uma instância do EJB de entidade
“propriedadeEntityBean”, e em seguida atualizar seus atributos com os valores
correspondentes.
Existem mensagens que podem estar relacionadas a outras mensagens, por exemplo,
uma determinada mensagem “Telemetria modeEqution” pode estar associada a várias
mensagens “Telemetria digital”. Portanto, se houver relacionamentos para a mensagem,
deve-se criar uma instância do EJB de entidade “relacionamentoEntityBean”, e em
seguida atualizar seus atributos com os valores correspondentes.
Pode-se então, depois de realizadas as instanciações dos EJBs de entidade, mostrar o
resultado da operação solicitada ao simulador para o usuário. A interface do Serviço de
Usuário solicita para o EJB do Serviço de Adaptação que recupere as mensagens
recebidas como resposta à solicitação feita pelo usuário, e este cria uma instância do
EJB do Serviço de Persistência que recuperará os valores associados. Finalmente, os
valores recuperados são exibidos para o usuário.
Como se pode notar na Figura 7.11, com apenas um único diagrama de seqüência foi
possível representar todas as funcionalidades do sistema abordadas neste trabalho. Isso
vêm reforçar a flexibilidade e a facilidade de extensão que podem ser obtidas ao se
conceber um sistema que se baseia no uso de modelos de objetos adaptáveis.
7.3- Implementando o Serviço de Adaptação
A implementação do Serviço de Adaptação envolve a implementação dos EJBs de
entidade representados no diagrama da Figura 7.9 via linguagem de programação, e a
implementação desses EJBs no banco de dados. Além disso, deve-se também
implementar o EJB de sessão do Serviço de Adaptação.
198
FIGURA 7.11 – Diagrama de seqüência para ativar uma operação no sistema.
199
Deve-se lembrar que, uma vez implementado o metamodelo, é necessário popular o
banco de dados com os metadados do sistema para que o sistema possa ser utilizado.
Os detalhes da implementação desse serviço são especificados na descrição da
construção do protótipo abordada no Capítulo 9 deste trabalho.
200
201
CAPÍTULO 8 – CONSTRUÇÃO DO PROTÓTIPO
Neste capítulo são descritos os passos seguidos para a implementação prática de um
ambiente para o 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.
8.1- As Ferramentas Adotadas para a Implementação do Protótipo
A seguir são apresentadas algumas características das ferramentas escolhidas para a
implementação de um protótipo para a arquitetura SICSDA.
8.1.1- A Plataforma de Programação Java
O Java é uma plataforma de programação orientada a objetos que foi desenvolvida pela
Sun Microsystems Inc.
Com a crescente expansão do uso da Internet, a linguagem Java tem sido cada vez mais
difundida, uma vez que provê facilidades para que se desenvolva aplicações que podem
se “mover” ao longo da rede, independentemente da plataforma das máquinas
envolvidas (Ashok,1998).
Isso é possível porque ao contrário da maioria das linguagens de programação, o código
escrito em Java não é compilado para uma máquina real, mas sim para uma máquina
virtual chamada Java Virtual Machine (JVM).
Apesar de ter sido projetada para ser simples, a linguagem Java é poderosa e bastante
apropriada para o desenvolvimento de aplicações centradas em redes.
202
A linguagem Java contém uma série de classes pré-definidas agrupadas em categorias
chamadas pacotes ou bibliotecas. Essas bibliotecas de classes são também conhecidas
como APIs (Java Application Programming Interfaces). Alguns exemplos de APIs Java
são: Java Input/Output Package (java.io), Java Language Package (java.lang), Java
Remote Method Invocatio Package (java.rmi) etc.
A linguagem Java foi escolhida para a implementação deste trabalho, basicamente pelos
seguintes motivos: (1) ela é orientada a objetos, o que é um requisito indispensável na
construção de modelos de objetos adaptáveis, (2) ela já havia sido utilizada na
implementação do protótipo da plataforma SICSD e (3) dentro dos requisitos e
limitações estabelecidos para o protótipo, ela mostrou-se adequada, particularmente,
porque disponibiliza a API Java Reflection Package (java.lang.reflect), que está
direcionada à obtenção de características de reflexão em tempo de execução.
Através dessa API pode-se obter informações sobre superclasses, construtores, métodos
e campos de uma classe em tempo de execução. Além disso, pode-se descobrir quais
declarações de métodos pertencem a uma interface, pode-se criar uma instância de uma
classe, cujo nome é conhecido apenas em tempo de execução; pode-se obter e alterar o
valor de um campo de um objeto, mesmo se o nome do campo for conhecido apenas em
tempo de execução; pode-se invocar um método de um objeto, mesmo se o nome do
método só for conhecido em tempo de execução, entre outros.
Mais informações sobre a linguagem de programação Java podem ser encontradas em
Sun (2004).
8.1.2- O Gerenciador de Banco de Dados Caché
O Caché é um gerenciador de banco de dados que foi desenvolvido pela Intersystems
Corporation.
203
Ele possui um completo conjunto de ferramentas de desenvolvimento e administração,
permitindo, simultaneamente, operações relacionais e orientadas a objetos, garantindo
grande interoperabilidade e facilidade na migração de sistemas relacionais.
Todas as classes Caché são automaticamente acessíveis como tabelas relacionais via
Open Database Connectivity (ODBC) e Java Database Connectivity (JDBC), e podem
ser facilmente adaptadas para serem usadas com XML e tecnologias orientadas a objeto
(Java, C++, EJBs etc.).
O Caché provê três formas diferentes de conexão com o Java: (1) os dados do Caché
podem ser acessados com Structured Query Langage (SQL) via JDBC, (2) as classes
Caché podem ser projetadas como classes Java e (3) as classes Caché podem ser
projetadas como EJBs.
Na realidade, quando são usadas as projeções não é necessário que o desenvolvedor
Java gere código para fazer com que as classes Caché sejam projetadas como classes
Java ou como EJBs, pois, na verdade, as projeções são automatizadas. Ou seja, quando
as classes Caché são projetadas como EJBs, o próprio Caché cria os EJBs de entidade e
o código necessário para a comunicação entre o Java e o banco de dados no diretório
especificado, usando a abordagem de persistência gerenciada pelo EJB (BMP).
O Caché foi escolhido como o gerenciador de banco de dados para o armazenamento de
metadados neste trabalho, basicamente por dois motivos: (1) ele é orientado a objetos, o
que o tornou bastante interessante, uma vez que isso poderia facilitar o armazenamento
e recuperação dos metadados, e (2) ele estava disponível para o uso acadêmico.
Mais informações sobre o gerenciador de banco de dados Caché podem ser encontradas
em Intersystems (2004).
204
8.1.3- O Ambiente de Desenvolvimento JBuilder
O JBuilder é um ambiente de desenvolvimento para aplicações Java que foi
desenvolvido pela Borland Corporation.
Através de uma interface gráfica o JBuilder permite que o desenvolvimento de
aplicações que envolvem EJBs possa ser acelerado, facilitando o acompanhamento da
criação, codificação e publicação dos EJBs.
O JBuilder suporta vários servidores de aplicação J2EE existentes no mercado, como,
por exemplo, o Borland Enterprise Server (BES), Websphere, JBoss, entre outros.
O JBuilder foi escolhido como ambiente de desenvolvimento para este trabalho,
basicamente pelos seguintes motivos: (1) ele apresenta uma interface gráfica amigável e
(2) ele já havia sido usado anteriormente, o que facilitaria o desenvolvimento.
Mais informações sobre o ambiente de desenvolvimento JBuilder podem ser
encontradas em Borland (2004).
8.1.4- O Servidor de Aplicações JBoss
Servidores de aplicação são frameworks para o desenvolvimento e publicação de
softwares baseados em componentes. O servidor de aplicações oferece um ambiente no
qual os usuários podem publicar componentes da aplicação que correspondem à parte
do servidor em aplicações distribuídas (Fleury,2004).
O servidor de aplicações JBoss é um servidor J2EE de código aberto desenvolvido pela
JBoss Professional Open Source Company.
205
Pode-se dizer que o JBoss é um framework aberto no sentido de que os desenvolvedores
podem estender os serviços do framework através da publicação dinâmica de
componentes em um servidor sendo executado.
O JBoss foi escolhido como servidor de aplicações para este trabalho, basicamente por
dois motivos: (1) ele é um dos poucos servidores compatíveis com o Caché e (2) dentre
os servidores compatíveis, ele mostrou-se mais acessível uma vez que é um software de
livre instalação e uso.
Mais informações sobre o servidor de aplicações JBoss podem ser encontradas em
JBoss(2004).
8.2 – O Ambiente de Testes
O ambiente de testes utilizado foi composto por cinco máquinas pertencentes à rede
local do Centro de Controle de Satélites (CCS), sendo todas Pentium III com 256 M de
RAM.
8.3- Implementando o Protótipo
O ambiente para o protótipo da arquitetura SICSDA foi implementado 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 Enterprise versão X, e o servidor de aplicações JBoss versão
3.0.8. A seguir são apresentados os passos principais executados durante a sua
construção:
1) Cada classe representada no diagrama da Figura 8.8 do capítulo anterior foi
implementada como uma classe Caché. Os atributos de cada classe foram
declarados na linguagem nativa do Caché.
206
2) Para cada classe Caché foi definida uma projeção para um EJB, especificando o
servidor de aplicações usado. As classes foram projetadas como EJBs de
entidade. A seguir é mostrado um exemplo da classe “Estação”, conforme
definida no Caché.
//Início da definição da classe Estação
Class User.Estacao Extends %Persistent [ ClassType = persistent, Language = java,
Owner = _SYSTEM, ProcedureBlock ]
{
// Definindo a projeção
Projection ProjEJB As %Projection.EJBJBoss(APPSERVERHOME = "C:\JBOSS-
3.0.8", JAVAHOME = "C:\jdk1.4.1", PACKAGE = "User", ROOTDIR =
"C:\SICSDA");
Property Codigo As %Integer; //definindo a propriedade código
Index CodigoIndex On Codigo [ Unique ]; //definindo a chave
Property Latitude As %Float; //definindo o atributo latitude
Property Longitude As %Float; //definindo o atributo longitude
Property Nome As %String; //definindo o atributo nome
}
// fim da definição da classe Estação
3) As classes foram compiladas no Caché. Quando isso é feito as projeções são
realizadas automaticamente e o EJB de entidade correspondente a cada classe é
gerado nos diretórios especificados nas projeções. Quando a classe é exportada,
são gerados automaticamente pelo Caché os métodos de acesso aos atributos
(gets e sets) e os métodos localizadores (finders). A seguir é mostrado um
exemplo da interface remota e da interface local do “EJBEstacao” gerado para a
classe “Estação” exemplificada no item anterior.
207
// A Interface Remota EJBEstacao
package User;
/**
* Imports
*
**/
import javax.ejb.EntityContext;
import java.io.*;
import java.util.Collection;
import javax.ejb.FinderException;
import java.rmi.RemoteException;
import javax.ejb.CreateException;
import javax.naming.Context;
import javax.naming.InitialContext;
import javax.naming.NamingException;
import java.util.Properties;
import javax.ejb.EJBException;
import javax.ejb.SessionContext;
import com.intersys.EJB.objects.*;
import java.sql.SQLException;
import java.sql.Connection;
import javax.sql.DataSource;
import java.sql.PreparedStatement;
import java.sql.CallableStatement;
import java.sql.DriverManager;
import java.sql.ResultSet;
import javax.ejb.ObjectNotFoundException;
import java.util.Enumeration;
import java.util.Vector;
import java.util.ArrayList;
import java.util.HashMap;
208
import java.sql.Date;
import java.math.BigDecimal;
import java.sql.Time;
import java.sql.Timestamp;
import User.EJBEstacao_Pk;
// Definindo a Interface Remota
public interface EJBEstacao extends javax.ejb.EJBObject {
// Métodos de acesso
public Integer getID() throws RemoteException;
public Integer get_ID() throws RemoteException;
public Integer getCodigo() throws RemoteException;
public Integer get_Codigo() throws RemoteException;
public void setCodigo(Integer value) throws RemoteException;
public void set_Codigo(Integer value) throws RemoteException;
public Double getLatitude() throws RemoteException;
public Double get_Latitude() throws RemoteException;
public void setLatitude(Double value) throws RemoteException;
public void set_Latitude(Double value) throws RemoteException;
public Double getLongitude() throws RemoteException;
public Double get_Longitude() throws RemoteException;
public void setLongitude(Double value) throws RemoteException;
public void set_Longitude(Double value) throws RemoteException;
public String getNome() throws RemoteException;
public String get_Nome() throws RemoteException;
public void setNome(String value) throws RemoteException;
public void set_Nome(String value) throws RemoteException;
public String getx__classname() throws RemoteException;
public String get_x__classname() throws RemoteException;
public void setx__classname(String value) throws RemoteException;
public void set_x__classname(String value) throws RemoteException;
}// Fim da Interface Remota EJBEstacao
209
// A Interface Local EJBEstacao_Home
package User;
/**
* Imports
*
**/
import javax.ejb.EntityContext;
import java.io.*;
import java.util.Collection;
import javax.ejb.FinderException;
import java.rmi.RemoteException;
import javax.ejb.CreateException;
import javax.naming.Context;
import javax.naming.InitialContext;
import javax.naming.NamingException;
import java.util.Properties;
import javax.ejb.EJBException;
import javax.ejb.SessionContext;
import com.intersys.EJB.objects.*;
import java.sql.SQLException;
import java.sql.Connection;
import javax.sql.DataSource;
import java.sql.PreparedStatement;
import java.sql.CallableStatement;
import java.sql.DriverManager;
import java.sql.ResultSet;
import javax.ejb.ObjectNotFoundException;
import java.util.Enumeration;
import java.util.Vector;
import java.util.ArrayList;
import java.util.HashMap;
210
import java.sql.Date;
import java.math.BigDecimal;
import java.sql.Time;
import java.sql.Timestamp;
import User.EJBEstacao_Pk;
// Definindo a interface Local
public interface EJBEstacao_Home extends javax.ejb.EJBHome {
// Métodos Localizadores
public EJBEstacao findByPrimaryKey(EJBEstacao_Pk primaryKey) throws
FinderException , RemoteException;
public EJBEstacao findById(java.lang.Integer id) throws FinderException ,
RemoteException;
public EJBEstacao findByCodigoIndex(Integer Codigo) throws FinderException ,
RemoteException;
//Método para a Criação da Instância do EJB
public EJBEstacao create() throws CreateException , RemoteException;
}
// Fim da Interface Local EJBEstacao_Home
4) Os EJBs de entidade gerados pelo Caché foram publicados no servidor de
aplicações. Para publicá-los deve-se executar o arquivo “deployer.bat” que é
gerado juntamente com a exportação do EJB pelo Caché. Uma vez publicados,
os EJBs de entidade ficaram disponíveis para uso.
5) Os EJBs de sessão do Serviço de Adaptação e do Serviço de Persistência foram
implementados, compilados e publicados no servidor de aplicações. Foi
implementada a interface para o configurador e a aplicação foi compilada e
executada. A seguir, a título de exemplo, são apresentadas as interfaces remota e
local para o EJB de sessão do Serviço de Persistência. É mostrada também a
classe que implementa a lógica do negócio para esse EJB para ilustrar a conexão
com o Caché.
211
//Interface Remota do EJB do Serviço de Persistência
package sessionbeansicsda;
import javax.ejb.EJBObject;
import java.awt.List;
import java.rmi.RemoteException;
// Definindo a Interface Remota
public interface sessionIDs
extends EJBObject {
public List getIDsPropertiesTipoTipoMsg(Integer IDEJB) throws
RemoteException;
// Métodos Remotos
public List getIDsPropriedadesTipoMsg(Integer IDEJB) throws RemoteException;
public List getIDTipoPropriedadeTipomsg(Integer idEJB) throws
RemoteException;
public List getIDsPropriedadeMsg(Integer idEJB) throws RemoteException;
public List getIDsTipoRelacionamento(Integer idEJBTipo, Integer
idEJBTipoTipo)
throws RemoteException;
public List getIDsMensagemTipoRelacionamento(Integer idEJB) throws
RemoteException;
public List getIDsRegras(Integer idTipoMsg) throws RemoteException;
public List getIDsMsgRelacionadas(Integer idEJBMsg, Integer idEJBTipoRel)
throws RemoteException;
public String getValorProp(Integer idEJBMSG, Integer idEJBTipoProp) throws
RemoteException;
public List getTelemetrias(int sat) throws RemoteException;
}
// Fim da Interface Remota do EJB do Serviço de Persistência
// Interface Local do EJB do Serviço de Persistência
package sessionbeansicsda;
212
import javax.ejb.EJBHome;
import javax.ejb.CreateException;
import java.rmi.RemoteException;
// Definindo a Interface Local
public interface sessionIDsHome
extends EJBHome {
// Métodos Locais
public sessionIDs create() throws CreateException, RemoteException;
}
// Fim da Interface Local do Serviço de Persistência
//Início da classe que implementa a lógica do negócio para o EJB do Serviço de
Persistência
package sessionbeansicsda;
import javax.ejb.SessionBean;
import javax.ejb.SessionContext;
import javax.ejb.CreateException;
import java.awt.List;
import javax.naming.NamingException;
import javax.ejb.EJBException;
import java.sql.Connection;
import java.sql.SQLException;
import javax.naming.Context;
import javax.naming.InitialContext;
import javax.sql.DataSource;
import java.util.Properties;
//Definindo o EJB de sessão do Serviço de Persistência
public class sessionIDsBean
implements SessionBean {
SessionContext sessionContext;
Connection con = null;
213
private Context jndiCntx;
private DataSource ds;
//Classes que gerenciam a vida útil do EJB de sessão
public void ejbCreate() throws CreateException {
}
public void ejbRemove() {
}
public void ejbActivate() {
}
public void ejbPassivate() {
}
public void setSessionContext(SessionContext sessionContext) {
this.sessionContext = sessionContext;
}
//Definindo a conexão com o Caché
protected Connection getConnection() throws SQLException {
try {
try {
System.setProperty("java.naming.factory.initial","org.jnp.interfaces.NamingContext
Factory");
System.setProperty("java.naming.provider.url","jnp://169.254.97.170.41");
Properties pro = System.getProperties();
if (jndiCntx == null) jndiCntx = new InitialContext(pro);
if (ds == null) {
String dataSource = "java:comp/env/USERDatabase";
try {
ds = (DataSource)jndiCntx.lookup(dataSource);
}
catch (Exception e) {
throw new EJBException(e.getMessage());
}
214
}
try {
con = ds.getConnection();
if (con == null) throw new EJBException("ds.getConnection() unexpectedly
returns NULL: ds="+ds);
} catch (Exception ex) {
throw new EJBException("ds.getConnection() falied: ds="+ds+"
:ex="+ex.getMessage());
}
} catch (NamingException ne) {
throw new EJBException(ne);
}
return con;
} catch (Exception ne) {
java.io.StringWriter sw = new java.io.StringWriter();
ne.printStackTrace( new java.io.PrintWriter( sw));
throw new EJBException(sw.toString());
}}
//Pode-se iniciar agora o código dos métodos que implementam a lógica do
negócio do EJB...
}
//Fim da classe que implementa a lógica do negócio para o EJB do Serviço de
Persistência
6) O acesso à implementação dos métodos das classes adaptáveis foram conseguidos
através da API de reflexão do Java “java.lang.reflect”. A seguir é mostrado um
trecho do código do método “btnVisualizar_mousePressed” que usa os recursos
dessa API para invocar o método “Vtelemetria”, que possibilita a visualização das
telemetrias de um determinado satélite.
215
//Início do trecho de código de “btnVisualizar_mousePressed”
// O método da classe a ser invocado tem um parâmetro
Class partypes[] = new Class[1];
//Esse parâmetro é do tipo inteiro
partypes[0] = Integer.TYPE;
// O objeto dessa classe que invocará o método tem um argumento
Object arglist[] = new Object[1];
// Esse argumento tem o valor armazenado em “codSatEsc”
arglist[0] = new Integer(codSatEsc);
// Criando um objeto Class que corresponde ao objeto cujos métodos deseja-se
invocar, ou seja, retornando um objeto Class associado o valor da string
“sessionadaptation.Estrategia”
Class cls = Class.forName("sessionadaptation.Estrategia");
// Criando um objeto Method através da invocação do método getMethod, para
poder descobrir informações de um método (nome, o tipo de retorno, os tipos de
parâmetros e o conjunto de exceções levantadas por este método)
Method meth = cls.getMethod("VTelemetria", partypes);
//Invocando o método desejado através do método “invoke”, que tem como
argumentos um array com os valores dos argumentos do método a ser invocado e
um objeto cuja classe declara ou herda o método
Object retobj = meth.invoke(estrategia, arglist);
List retval = (List) retobj;
// Fim do trecho de código de “btnVisualizar_mousePressed”
7) Os EJBs publicados podem estar distribuídos nas várias máquinas da rede onde a
arquitetura pode estar instalada. Uma forma de conseguir que a aplicação cliente
encontre os EJBs é configurar a propriedade “java.naming.provider.url” do
arquivo de recurso do aplicativo “jndi.properties”, definindo o nome da máquina
que está executando o serviço JNDI e o número da porta do serviço. A seguir é
apresentado um exemplo de um trecho de código de uma aplicação cliente onde
isso foi feito.
216
//Definindo as classes de fábrica do provedor de serviços JNDI
System.setProperty("java.naming.factory.initial","org.jnp.interfaces.NamingContext
Factory");
//Definindo o nome da máquina e porta
System.setProperty("java.naming.provider.url","jnp://169.254.51.115:1099");
/Pegando as propriedades definidas
Properties pro = System.getProperties();
//Setando o contexto inicial com as propriedades definidas
InitialContext ctx = new InitialContext(pro);
//Fazendo o lookup no serviço de nomes
Object ref = ctx.lookup("sessionIDs");
Ou então, pode-se criar um arquivo onde o contexto inicial é setado com os valores
especificados em uma Hashtable, como ilustra o arquivo “Globais.Java” listado a
seguir. Dessa forma pode-se definir vários servidores diferentes, definindo para cada
um o contexto inicial específico, como ilustrado a seguir.
//Arquivo Globais.Java
import javax.naming.Context;
import javax.naming.InitialContext;
import javax.naming.NamingException;
import java.util.Hashtable;
public class Globais {
public Globais() {
}
//Setando o contexto inicial para o servidor 1
public static Context getInitialContext() throws NamingException {
Hashtable environment = new Hashtable();
environment.put(Context.INITIAL_CONTEXT_FACTORY,
"org.jnp.interfaces.NamingContextFactory");
217
environment.put(Context.URL_PKG_PREFIXES,
"org.jboss.naming:org.jnp.interfaces");
environment.put(Context.PROVIDER_URL, "jnp://169.254.170.41:1099");
return new InitialContext(environment);
}
//Setando o contexto inicial para o servidor 2
public static Context getInitialContextOutro() throws NamingException {
Hashtable environment = new Hashtable();
environment.put(Context.INITIAL_CONTEXT_FACTORY,
"org.jnp.interfaces.NamingContextFactory");
environment.put(Context.URL_PKG_PREFIXES,
"org.jboss.naming:org.jnp.interfaces");
environment.put(Context.PROVIDER_URL, "jnp://169.254.51.115:1099");
return new InitialContext(environment);
}
}
//Fim do Arquivo Globais.Java
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 Caché e
também para a classe “TipoMensagem”, nas Figuras 8.1 e 8.2, respectivamente.
FIGURA 8.1 – Dados de “Estação”.
218
8) A interface do Serviço de Usuário finalmente foi construída, e as operações
“Enviar Telecomando”, “Visualizar Telemetria” e “Obter Medidas” foram
implementadas e disponibilizadas para o usuário.
FIGURA 8.2 – Dados de “TipoMensagem”.
8.4- Exemplos de Realização de Caso de Uso
A seguir, são mostrados os passos principais executados pelo protótipo para a realização
do caso de uso “Criar um novo tipo de mensagem” e para o caso de uso “Visualizar
Telemetria”.
8.4.1- Criando um Novo Tipo de Mensagem
A Figura 8.3 ilustra o diagrama de seqüência para o caso de uso “Criar um novo tipo de
mensagem”. As setas adicionadas ao diagrama servem para facilitar a ilustração de
como foi implementada a execução de cada mensagem desse caso de uso.
219
Interface do Serviço de Configuração
persistence:PersistenceSessionBean
tipoMensagem:tipoMensagemEntityBeanConfigurador : <Actor
Name>
3:RecuperarTiposPropriedades(tipoTipoMensagem)
2:EJBcreate( )
1:AdicionarTipoMensagem(tipoTipoMensagem, codigo, nome)
9:Confirmação
4:EJBcreate()
5:setCodigo(codigo)
6:setNome(nome)
7:setTipoTipo(tipoTipoMensagem)
8:setTiposPropriedades(tiposProps)
FIGURA 8.3 – Execução do Caso de Uso “Criar um Novo Tipo de Mensagem”.
A mensagem “1” (apontada pela seta ) no diagrama da Figura 8.3 representa o
acionamento, por parte do usuário, da opção “Inserir Novo Tipo de Mensagem”, que é
realizada através da interface disponibilizada pelo Serviço de Configuração. A tela
principal do Serviço de Configuração desenvolvida para o protótipo é mostrada na
Figura 8.4.
Uma vez nessa tela, deve-se escolher a opção “TipoMensagem”, pois deseja-se criar um
novo tipo de mensagem. A Figura 8.5 ilustra a tela para a criação do tipo de mensagem
“Telecomando Manual”. O código do tipo do tipo da mensagem é “1”, pois corresponde
ao código de “telecomando”. A Figura 8.2 ilustra os tipos de mensagens criadas.
220
FIGURA 8.4 – Escolhendo a opção “TipoMensagem”.
FIGURA 8.5 – Inserindo um novo tipo de mensagem.
221
A mensagem “2” (apontada pela seta ) no diagrama da Figura 8.3 representa criação
de uma referência para o EJB de sessão do Serviço de Persistência. O código a seguir
ilustra a execução dessa operação.
//Criando uma referência para o EJB de sessão do Serviço de Persistência
session = session_home.create();
Na mensagem “3” (apontada pela seta ) é acionado o método do EJB do Serviço de
Persistência responsável por recuperar os tipos de propriedades já criadas para o tipo do
tipo da mensagem a ser criada, fornecendo para isso o tipo do novo tipo de mensagem a
ser criada. O código a seguir ilustra a execução dessa operação.
//Recuperando os tipo de propriedades já cadastradas para o tipo do tipo da
mensagem a ser criada, acionando para isso o método do EJB de sessão do Serviço
de Persistência “getIDsPropertiesTipoTipoMsg”
java.awt.List ids = session.getIDsPropertiesTipoTipoMsg(tipotipomsg.get_ID());
A seguir é apresentado o código do método “getIDsPropertiesTipoTipoMsg” do EJB de
sessão do Serviço de Persistência. Para realizar essa operação é necessário que se
estabeleça uma conexão com o banco de dados.
//Método do EJB do Serviço de Persistência “getIDsPropertiesTipoTipoMsg”
public List getIDsPropertiesTipoTipoMsg(Integer IDEJB) {
try {
try {
con = this.getConnection();
java.sql.Statement st = con.createStatement();
java.sql.ResultSet rs = st.executeQuery("SELECT ID FROM
TIPOPROPRIEDADE
WHERE TIPOTIPOMENSAGEM = " + IDEJB
);
222
List IDs = new List();
while (rs.next())
IDs.add(rs.getString(1));
return IDs;
} catch (Exception ne) {
java.io.StringWriter sw = new java.io.StringWriter();
ne.printStackTrace( new java.io.PrintWriter( sw));
throw new EJBException(sw.toString());
}
} finally {
try {
if (con != null) con.close();
con = null;
}catch (SQLException ce) {
throw new EJBException (ce.getMessage());
}
}
}
//Fim de “getIDsPropertiesTipoTipoMsg”
Na mensagem “4” (apontada pela seta ) a interface do Serviço de Configuração
solicita a criação de uma instância do EJB de entidade “tipoMensagemEntityBean”. O
código a seguir ilustra a execução dessa operação.
//Criando uma instância para o EJB de entidade tipo de mensagem
tipomsg = tipomsg_home.create();
Nas mensagens “5”, “6”, “7” e “8” (apontadas pelas setas ), a instância de
“tipoMensagemEntityBean” criada é atualizada com os valores passados como
parâmetros nos métodos “setCodigo”, “setNome”, “setTipoTipo” e
“setTiposPropriedades”. O código a seguir ilustra a execução dessa operação.
223
//Adicionando os valores para os atributos desse EJB
tipomsg.set_Codigo(new Integer(edCodigo.getText()));
tipomsg.set_Nome(edTipomsg.getText());
tipomsg.set_tipotipomensagem(tipotipomsg);
// Inserindo os tipos de propriedades
for (int i=0; i < ids.getItemCount(); i++) {
tipoprop = tipoprop_home.findById(new Integer(ids.getItem(i)));
prop = prop_home.create();
prop.set_Nome(tipoprop.get_Nome());
prop.set_Tipo(tipoprop);
prop.set_tipomensagem(tipomsg);
edValor = (JTextField)pnlProps.getComponent(i*2 + 1);
prop.set_Valor(edValor.getText());
}
Dessa forma, é possível, em tempo de execução, criar um novo tipo de mensagem,
alterando assim o modelo de objetos do domínio da aplicação. Ou seja, é possível,
através da modificação dos metadados armazenados no banco de dados, alterar, até
certo ponto, o comportamento do sistema em tempo de execução, uma vez que um novo
tipo de mensagem deve ser considerado daqui para frente.
8.4.2- Visualizando Telemetrias
A Figura 8.6 ilustra o diagrama de seqüência para o caso de uso “Visualizar
Telemetria”. As setas adicionadas ao diagrama servem para facilitar a ilustração de
como foi implementada a execução de cada mensagem desse caso de uso.
224
FIGURA 8.6 – Execução do Caso de Uso “Visualizar Telemetria”.
225
A mensagem “1” (apontada pela seta ) no diagrama da Figura 8.6 representa o
acionamento, por parte do usuário, de uma operação (Visualizar Telemetria, Enviar
Telecomando ou Obter Medidas) e do satélite desejado. A interface do Serviço de
Usuário desenvolvida para o protótipo é mostrada na Figura 8.7.
FIGURA 8.7 – Interface do serviço de usuário.
A mensagem “4” (apontada pela seta ) no diagrama da Figura 8.6 representa criação
de uma referência para o EJB de sessão do Serviço de Adaptação. Essa referência é
criada porque é o EJB de sessão do Serviço de Adaptação que contém os métodos que
implementam a lógica do negócio, neste caso, “Visualizar Telemetria”, “Enviar
Telecomando” ou “Obter Medidas”. O código a seguir ilustra a execução dessa
operação.
//Criando uma referência para o EJB de sessão do Serviço de Adaptação
estrategia = estrategia_home.create();
226
A mensagem “14” (apontada pela seta ) ilustra a recuperação das mensagens de acordo
com o satélite escolhido e com a operação solicitada. Nesse caso específico, a operação
solicitada é “Visualizar Telemetrias” e o satélite escolhido é o SCD1. O código a seguir
ilustra a execução dessa operação. Na verdade, a interface do Serviço de Usuário invoca
dinamicamente o método “VTelemetria”, que é um método do EJB do Serviço de
Adaptação. Isso significa que, apenas em tempo de execução, é conhecido o nome do
método a ser invocado, além de informações sobre seus parâmetros e valores de retorno.
// O método da classe a ser invocado tem um parâmetro que é do tipo inteiro
Class partypes[] = new Class[1];
partypes[0] = Integer.TYPE;
// O objeto dessa classe que invocará o método tem um argumento que tem o valor
armazenado em “codSatEsc” (satélite escolhido)
Object arglist[] = new Object[1];
arglist[0] = new Integer(codSatEsc);
//Invocando dinamicamente o método “VTelemetria” do EJB de sessão do Serviço
de Adaptação
try {
Class cls = Class.forName("sessionadaptation.Estrategia");
Method meth = cls.getMethod("VTelemetria", partypes);
Object retobj = meth.invoke(estrategia, arglist);
List retval = (List) retobj;
A seguir é apresentado o código do método “VTelemetria” do EJB de sessão do Serviço
de Adaptação. Esse método invoca um método do EJB de sessão do Serviço de
Persistência para que as telemetrias associadas ao satélite escolhido sejam recuperadas.
Antes disso, porém, é criada uma referência para o EJB de sessão do Serviço de
Persistência. Esta operação está representada no diagrama da Figura 8.6 pela mensagem
“15” (apontada pela seta ).
227
//Método “VTelemetria” do EJB de sessão do Serviço de Adaptação
public List VTelemetria (int sat){
try {
//Pegando contexto inicial
jndiContext = new InitialContext();
//Fazendo lookup e obtendo uma referência para o EJB de sessão do Serviço de
Persistência
Object ref = jndiContext.lookup(new String("sessionIDs"));
session_home = (sessionIDsHome) javax.rmi.PortableRemoteObject.narrow
(ref, sessionIDsHome.class);
session = session_home.create();
}
catch (Exception re) {
String msgin = re.getMessage();
System.out.println(msgin); }
//Chamando o método “getTelemetrias” do EJB de sessão do Serviço de
Persistência
try {
List telemetrias = session.getTelemetrias(sat);
return telemetrias;
}
catch (Exception re) {
String msgin = re.getMessage();
System.out.println("RemoteException re " + msgin);
return null;
}
}
//Fim do Método “VTelemetria” do EJB de sessão do Serviço de Adaptação
A mensagem “16” (apontada pela seta ) ilustra a ativação do método “getTelemetrias”
do EJB do Serviço de Persistência. Para que esse método possa ser realizado é
228
necessário que se estabeleça uma conexão com o banco de dados.O código a seguir
ilustra a execução dessa operação.
//Método “getTelemetrias” do EJB de sessão do Serviço de Persistência
public List getTelemetrias(int sat) {
List teles = new List();
try {
try {
con = this.getConnection();
java.sql.Statement st = con.createStatement();
//Se o satélite escolhido for o SCD1
if (sat==1){
java.sql.ResultSet rs = st.executeQuery(" SELECT MENSAGEM.DESCRICAO,"
+
"MENSAGEM.NUMERO," +"PROPRIEDADE.NOME," +
"PROPRIEDADE.VALOR " +
"FROM FRAME," + "MENSAGEM," + "TIPOMENSAGEM," +
"PROPRIEDADE," + "TIPOTIPOMENSAGEM " +
"WHERE FRAME.ID = MENSAGEM.FRAME " +
"AND FRAME.SATELITE = 1 " +
"AND MENSAGEM.TIPOMENSAGEM = TIPOMENSAGEM.ID " +
"AND TIPOMENSAGEM.TIPOTIPOMENSAGEM =
TIPOTIPOMENSAGEM.ID " +
"AND TIPOTIPOMENSAGEM.ID = 5 " +
"AND TIPOMENSAGEM.ID = PROPRIEDADE.TIPOMENSAGEM");
while (rs.next())
teles.add(rs.getString(1)+" "+rs.getString(2)+" "+rs.getString(3)+"
"+rs.getString(4));
}
//Se o satélite escolhido for o SCD2
else if (sat==2) {
229
java.sql.ResultSet rs = st.executeQuery(" SELECT MENSAGEM.DESCRICAO,"
+
"MENSAGEM.NUMERO," +
"PROPRIEDADE.NOME," + "PROPRIEDADE.VALOR " +
"FROM FRAME," + "MENSAGEM," + "TIPOMENSAGEM," +
"PROPRIEDADE," + "TIPOTIPOMENSAGEM " +
"WHERE FRAME.ID = MENSAGEM.FRAME " +
"AND FRAME.SATELITE = 2 " +
"AND MENSAGEM.TIPOMENSAGEM = TIPOMENSAGEM.ID " +
"AND TIPOMENSAGEM.TIPOTIPOMENSAGEM =
TIPOTIPOMENSAGEM.ID " +
"AND TIPOTIPOMENSAGEM.ID = 5 " +
"AND TIPOMENSAGEM.ID = PROPRIEDADE.TIPOMENSAGEM");
while (rs.next())
teles.add(rs.getString(1)+" "+rs.getString(2)+" "+rs.getString(3)+"
"+rs.getString(4));
}
//Se o satélite escolhido for o CBERS2
else {
java.sql.ResultSet rs = st.executeQuery(" SELECT MENSAGEM.DESCRICAO,"
+
"MENSAGEM.NUMERO," +
"PROPRIEDADE.NOME," + "PROPRIEDADE.VALOR " +
"FROM FRAME," + "MENSAGEM," + "TIPOMENSAGEM," +
"PROPRIEDADE," + "TIPOTIPOMENSAGEM " +
"WHERE FRAME.ID = MENSAGEM.FRAME " +
"AND FRAME.SATELITE = 3 " +
"AND MENSAGEM.TIPOMENSAGEM = TIPOMENSAGEM.ID " +
"AND TIPOMENSAGEM.TIPOTIPOMENSAGEM =
TIPOTIPOMENSAGEM.ID " +
"AND TIPOTIPOMENSAGEM.ID = 5 " +
230
"AND TIPOMENSAGEM.ID = PROPRIEDADE.TIPOMENSAGEM");
while (rs.next())
teles.add(rs.getString(1)+" "+rs.getString(2)+" "+rs.getString(3)+"
"+rs.getString(4));
}
return teles;
}
catch (Exception ne) {
java.io.StringWriter sw = new java.io.StringWriter();
ne.printStackTrace(new java.io.PrintWriter(sw));
throw new EJBException(sw.toString());
}
}
finally {
try {
if (con != null) con.close();
con = null;
}
catch (SQLException ce) {
throw new EJBException (ce.getMessage());
}
}
}
//Fim do Método “getTelemetrias”
Assim, para visualizar as telemetrias de um determinado satélite, o usuário deve
primeiramente escolher o satélite desejado e em seguida escolher a opção “Visualizar
Telemetria” na interface provida pelo Serviço de Usuário. A Figura 8.8 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.
231
FIGURA 8.8 – 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.
232
233
CAPÍTULO 9 - CONCLUSÃO
Este trabalho buscou, a partir dos desafios identificados inicialmente, e considerando-se
o escopo e as restrições estabelecidas, elaborar uma Arquitetura de Software Distribuída
Configurável e Adaptável Aplicada às Várias Missões de Controle de Satélites baseada
em modelos de objetos adaptáveis.
Esta arquitetura, chamada SICSDA (Sistema de Controle de Satélites Distribuído e
Adaptável), integra duas tecnologias emergentes, a tecnologia de objetos distribuídos e
a tecnologia de modelos de objetos adaptáveis; e procura, na medida do possível,
beneficiar-se das vantagens intrínsecas que essas tecnologias podem trazer para um
sistema de software concebido sob suas diretrizes.
Dessa forma, considerando as vantagens provenientes de um sistema distribuído e
adaptável, a arquitetura apresentada visou obter, como especificado no Capítulo 5 deste
trabalho, os seguintes objetivos:
• Facilidade na acomodação de novas missões;
• possibilidade de se monitorar mais de um satélite;
• facilidade de se configurar e estender o sistema de controle para um determinado
satélite; e
• economia de desenvolvimento e investimento para futuras missões.
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
instanciação de um novo modelo de objetos cada vez que uma troca de contexto desse
234
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 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 sejam associadas a uma classe do domínio
em tempo de execução.
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).
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, e obtenção de medidas de distância e calibração
podem estar distribuídas dentro do domínio de rede onde a arquitetura SICSDA está
instalada.
Isto significa que os objetos da aplicação podem ser instanciados em máquinas
diferentes na rede, ocasionando, portanto, uma distribuição do código do sistema. O
middleware provê a localização desses objetos, ou seja, em que máquina da rede eles
estarão disponíveis.
235
Isto significa que cada máquina da rede pode ter uma “visão” do metadado armazenado
no banco de dados. Entende-se por “visão”, neste contexto, uma determinada parte do
modelo de objetos adaptável que será instanciada naquela máquina.
Dessa forma, uma determinada máquina da rede tem acesso apenas à parte do modelo
de objetos adaptável que lhe cabe, instanciando apenas os objetos pré-definidos na
configuração do sistema.
Assim, na arquitetura SICSDA, os objetos da aplicação se comunicam através de um
middleware, que implementa a arquitetura J2EE, podendo existir mais de uma cópia de
um objeto instanciado em nós diferentes da rede, e isto está relacionado com o número
de usuários que utilizam os serviços disponíveis nesse objeto, bem como com a
necessidade da disponibilidade de um determinado serviço em caso de falha.
A arquitetura SICSDA, como mostrado no capítulo 5, foi dividida em serviços para que
se pudesse criar uma infra-estrutura capaz de suportar uma arquitetura flexível, onde a
necessidade de incorporação de novos serviços para agregar novas funcionalidades,
possa ser feita causando o mínimo de impacto possível nos serviços já existentes.
Nos Capítulos 6 e 7, cada serviço foi detalhado sob o ponto de vista de seu
funcionamento e implementação, e foram descritas as estratégias utilizadas para a
construção desses serviços atendo-se, mais detalhadamente, ao Serviço de Adaptação,
que é o foco principal deste trabalho.
O processo de desenvolvimento adotado para a construção da arquitetura SICSDA está
baseado nos conceitos propostos pela Model Driven Architecture (MDA). Dessa forma,
pôde-se aliar os modelos de objetos adaptáveis, vistos por alguns como uma evolução
da MDA, às técnicas de modelagem e intercâmbio entre modelos propostos pela própria
MDA, acrescentando ao processo de desenvolvimento proposto pela MDA os passos
236
necessários para a obtenção do metamodelo e dos metadados do sistema, como
apresentado no Capítulo 7 deste trabalho.
Em termos de ciclo de vida do sistema, pode-se dizer que, na fase de “Análise” do
Sistema foi estudado sobre o domínio do problema em questão e foram construídos os
modelos independentes de plataforma (PIMs), como mostrado nos Capítulos 6 e 7 deste
trabalho. Na fase de “Projeto” foram obtidos os modelos dependentes de plataforma
iniciais (PSMs), também apresentados nos Capítulos 6 e 7; e na fase de “Implementação
e Testes” foram implementados, efetivamente, os modelos dependentes de plataforma, e
a arquitetura pode ser testada, o que está detalhado no Capítulo 8.
O ambiente para o protótipo da arquitetura SICSDA foi implementado usando-se a
linguagem Java, o banco de dados Caché, o ambiente de desenvolvimento JBuilder
Enterprise , e o servidor de aplicações JBoss.
Após a implementação dos EJBs de entidade e de sessão que compõe a arquitetura,
povoou-se o banco de dados com os metadados dos satélites monitorados 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.
Uma vez inseridos os metadados, o usuário pode através da interface disponibilizada
pelo Serviço de Usuário, realizar as operações “Enviar Telecomando”, “Visualizar
Telemetria” e “Obter Medidas” para os satélites SCD1, SCD2 e CBERS2.
Neste trabalho não são especificadas estratégias para se implementar o controle das
versões do sistema e o armazenamento do histórico dos metadados. Apesar disso,
procurou-se, identificar as situações que poderiam gerar uma nova versão do sistema em
questão, como uma forma de ressaltar a importância que deve ser dada esse tipo de
controle durante o ciclo de vida de um sistema.
237
9.1- Resultados Obtidos
Através do desenvolvimento deste trabalho, e especialmente após a construção do
protótipo, pôde-se constatar que o estabelecimento de uma Arquitetura de Software
Distribuída, Configurável e Adaptável para o Sistema de Controle de Satélites mostrou-
se viável e adequado aos propósitos estabelecidos inicialmente.
Ao longo do desenvolvimento deste trabalho, contudo, pôde-se identificar alguns pontos
favoráveis e alguns pontos desfavoráveis da arquitetura proposta, que são detalhados a
seguir:
1) Pontos Desfavoráveis:
• A geração do metamodelo é uma tarefa complexa, pois à medida que os patterns
vão sendo aplicados e o modelo vai ficando cada vez mais genérico, torna-se cada
vez mais difícil ter em mente a sintaxe e a semântica do modelo de objetos real do
sistema. Dessa forma, construir o metamodelo exige um alto grau de abstração.
• A inserção dos metadados no banco de dados é bastante trabalhosa e lenta, além
de exigir bastante atenção do configurador. Isso é natural, pois, uma vez que a
semântica e a sintaxe do modelo estão sendo armazenadas, é necessário que se
entenda cada detalhe existente no modelo de objetos real, ou corre-se o risco de
não inseri-lo de forma correta no banco de dados. Na realidade observou-se que,
da forma como foi concebida a interface do Serviço de Configuração, é necessário
que o configurador conheça bem o modelo de objetos real e que tenha
familiaridade com a notação na qual ele está expresso, para que ele possa inserir
os metadados corretamente.
• Além disso, observou-se que a compreensão da sintaxe e da semântica dos
metadados armazenados no banco de dados também é complexa. Na realidade, o
que acontece é que um objeto do modelo de objetos real passa, no metamodelo, a
238
ter sua informação distribuída em várias classes genéricas, o que dificulta o
entendimento. Analogamente, manter os metadados pode ser considerado um
trabalho difícil e meticuloso.
• Outra questão importante observada diz respeito ao baixo desempenho do
sistema. De certa forma, isso já era esperado desde o início, devido à própria
concepção dos modelos de objetos adaptáveis e da arquitetura J2EE. Apesar de ser
considerado um ponto desfavorável, o desempenho não foi visto como uma
limitação da arquitetura, já que as máquinas utilizadas para o ambiente de testes
apresentavam uma configuração bastante inferior ao que se pode obter atualmente.
2) Pontos Favoráveis:
• A arquitetura permite 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. Ou seja, através do Serviço de Configuração pode-se configurar os
metadados para o novo satélite, diminuindo consideravelmente o esforço para a
adaptação do sistema a esse novo requisito.
• A arquitetura permite que o controle dos vários satélites possa ser feito usando-se
o mesmo conjunto de computadores, possibilitando que se possa escolher qual dos
satélites deseja-se monitorar em um determinado instante. Ou seja, conforme
mostrado no capítulo5, se o usuário desejar monitorar outro satélite, o Serviço de
Adaptação se encarregará de instanciar os metadados referentes àquele satélite
especificamente.
• A arquitetura permite que especialistas do domínio e desenvolvedores do
software 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
239
domínio do problema sem a necessidade de programação adicional. Ou seja, de
acordo com o capítulo 9, através do Serviço de Configuração é possível, se
necessário, realizar modificações nos modelos de objetos já existentes.
• A arquitetura possibilita que futuras missões aproveitem grande parte do
investimento de hardware e software já realizado em outras missões, conforme
proposto no Capítulo 5. Isso é possível porque através de um único aplicativo
pode-se monitorar os vários satélites, e que o esforço realizado para acomodar
novas missões pode ser minorado, já que a etapa de codificação do sistema pode
ser reduzida.
• Segundo Yoder(2001), o projeto de modelos de objetos adaptáveis envolve três
atividades principais: (1) definição das entidades do negócio, regras e
relacionamentos; (2) desenvolvimento de um projeto de uma máquina para
instanciar e manipular essas entidades de acordo com as suas regras na aplicação e
(3) desenvolvimento de ferramentas para descrever essas entidades, regras e
relacionamentos. Na realidade, a arquitetura proposta vai além da simples
execução dessas atividades, uma vez que, são propostas nos Capítulos 6 e 7,
estratégias para que essas atividades possam ser realizadas, considerando a
distribuição do sistema e a possibilidade de se ter mais de um modelo de satélites
que pode ser instanciado.
• Assim, apesar da dificuldade de se trabalhar com modelos adaptáveis, foram
propostas nos Capítulos 6 e 7 algumas estratégias que, se seguidas, podem facilitar
a concepção de arquiteturas adaptáveis e distribuídas. Indubitavelmente, essas
estratégias não têm a pretensão de serem suficientemente abrangentes para cobrir
o desenvolvimento de qualquer sistema, porém, apresentam, ao menos para o
domínio de controle de satélites, um caminho que pode ser seguido.
240
• A arquitetura proposta apresenta ainda, uma contribuição importante para a área
de modelos de objetos adaptáveis, uma vez que propõe que o modelo de objetos
adaptável seja distribuído, apresentando também, nos Capítulos 6, 7 e 8, formas
para se conseguir essa distribuição. Analogamente, pode-se dizer o mesmo para a
área de sistemas distribuídos.
• Outra contribuição para a área de modelos de objetos adaptáveis é a
possibilidade de se ter uma generalização da dinâmica do sistema, como mostrado
no Capítulo 7. Na verdade, ao se projetar os diagramas de caso de uso do sistema,
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 básicas do
sistema de controle abordado. Dessa forma, pôde-se também, representar a
dinâmica do sistema de forma genérica, diminuindo consideravelmente o número
de diagramas de seqüência que deveriam ser projetados.
• Pode-se dizer que a arquitetura proposta também apresenta uma contribuição
para a evolução da Model Driven Architecture (MDA), já que, segundo Poole
(2002), uma das metas futuras para a evolução da MDA é implementar modelos
de objetos adaptáveis.
• Além disso, a arquitetura SICSDA pode ser considerada, segundo a própria
MDA, como uma Domain Task Force (DTF) para o domínio de controle de
satélites, já que uma DTF representa um framework padronizado para um
determinado domínio de aplicação. Aliás, pode-se dizer que a arquitetura proposta
é mais do que uma DTF, uma vez que não só define um framework para o domínio
de controle de satélites, mas também o faz de forma genérica, aumentando ainda
mais a sua reusabilidade.
• Apesar de não serem especificadas estratégias para a implementação do controle
das versões do sistema e do armazenamento do histórico dos metadados, no
241
Capítulo 5 procurou-se, identificar as situações que poderiam gerar uma nova
versão do sistema e estabelecer medidas simples para minorar este problema.
9.2- Trabalhos Futuros
A conclusão deste trabalho não encerra, de forma alguma, as considerações a serem
feitas em relação ao desenvolvimento de um sistema adaptável e distribuído para o
Sistema de Controle de Satélites. Na realidade, este trabalho abre uma série de questões
que ainda podem ser exploradas, como por exemplo:
• Pode-se, futuramente, adequar a interface do Serviço de Configuração de forma
que ela fique mais próxima da realidade do configurador, tornando a atividade de
inserção e manutenção dos metadados mais adequada ao domínio de controle de
satélites.
• Apesar de terem sido estabelecidas neste trabalho algumas estratégias para o
desenvolvimento de sistemas adaptáveis, outro ponto que pode ser mais explorado
futuramente é a adequação de um processo de desenvolvimento de software que
foque esse tipo de sistema. Essa questão é bastante interessante, uma vez que, em
um sistema adaptável, é importante que se identifique quais os elementos do
domínio serão adaptáveis, e que, a partir daí, seja gerado o metamodelo
correspondente através da aplicação de patterns. Na realidade, isso acrescenta
algumas etapas ao processo de desenvolvimento tradicional, e torna necessário que
se adapte as metodologias e processos de desenvolvimento propostos pela área de
engenharia de software a esse novo contexto.
• Uma outra questão a ser explorada futuramente é o controle de versões para os
sistemas adaptáveis, já que nesse tipo de sistema o usuário pode, efetivamente,
realizar modificações no modelo do sistema em tempo de execução. Essas
modificações podem acarretar mudanças de comportamento do sistema, o que torna
necessário que se tenha um controle de versões não apenas em relação a alterações
242
no código do sistema, mas também, em relação a alterações nos metadados que
estão armazenados no banco de dados.
• Uma outra possibilidade de trabalho futuro é a construção de uma ferramenta
computacional que possibilite a geração do metamodelo de um sistema de forma
automática. Ou seja, a partir de um modelo de objetos, a ferramenta possa identificar
os patterns a serem aplicados, e possa gerar o metamodelo resultante da aplicação
de uma seqüência de patterns.
9.3- Considerações Finais
Apesar de muitos aspectos apontarem para o fato de que, pelos menos inicialmente, as
arquiteturas baseadas em modelos de objetos adaptáveis exigem mais esforço para
serem construídas, acredita-se com este trabalho, ter dado um passo significativo em
direção a reusabilidade de um sistema, já que os sistemas adaptáveis têm a característica
de acompanhar a evolução dos requisitos do domínio, e já que têm uma arquitetura
genérica, o que os torna altamente configuráveis e adaptáveis.
Outro passo importante foi dado em relação a alterabilidade de um sistema, já que nos
sistemas adaptáveis o esforço para se realizar alterações pode ser bastante minimizado,
uma vez 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 certas alterações, melhorando a alterabilidade e
diminuindo a intervenção dos desenvolvedores do software na evolução do sistema.
Além disso, foi dado um passo importante em relação a economicidade, uma vez que
futuras missões poderão aproveitar praticamente todo o investimento de hardware e
software já feito para o Sistema de Controle de Satélites em outras missões. Isso vem
diretamente de encontro aos objetivos do INPE ao propor a plataforma multi-missão
MMP; pois, assim como a MMP visa à concepção de arquiteturas de hardware para a
243
construção de satélites mais flexíveis e configuráveis; a arquitetura SICSDA tem os
mesmos objetivos em relação ao Sistema de Controle de Satélites.
As idéias deste trabalho já foram publicadas, até o momento, em Thomé (2003a),
Thomé (2003b), Thomé (2003c), Thomé (2004a), Thomé (2004b) e Thomé (2004c), e
originaram os trabalhos de mestrado que estão sendo desenvolvidos em Almeida (2004)
e em Cardoso (2004).
Espera-se, através do desenvolvimento deste trabalho, 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.
244
245
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. 2004. Dissertação (Mestrado em
Computação Aplicada) – Instituto Nacional de Pesquisas Espaciais, São José dos Campos,
2004.
Alur, D.; et al. Core J2EE patterns: as melhores práticas e estratégias de design. Rio de
Janeiro: Campus, 2002. 406p.
Amano, N.; Watanabe, T. An object-oriented reflective language for dynamically adaptable
software model. IEICE Transactions on Fundamentals of Electornics Communications
and Computer Science, v.E82-A, n.6, p.1009-1016, Jun. 1999.
Arsanjani, A. Rule Object: a pattern language for adaptive and scalable business rule
construction. In: Pattern Languages of Programming Conference, 7., 2000, Monticello,
Illinois, USA. Proceedings... Illinois: University of Illinois, 2000.
Arsanjani, A. Using grammar-oriented object design to seamlessly map business models to
component-based software architectures. In: International Association of Science and
Technology for Development, 2001, Pittsburgh. Proceedings... Calgari, Canada:
International Association of Science and Technology for Development, 2001.
Ashok, S.; Bansal, V. Java: network centric enterprise computing. Computer
Communications, v.20, n.16, p.1467-1480, Jan. 1998.
Atkinson, C; Kühne, T. Model-Driven Development: a metamodeling foudation. IEEE
Software, v.20, n.5, p.36-41, Sept./Oct. 2003.
246
Augustim, I; et al. ISAM, a software architecture for adaptive and distributed mobile
applications. In: IEEE International Symposium on Computers and Communications, 17.,
Jul. 2002, Italy. Proceedings.... Bologna: University of Bologna, 2002.
Bäck, T. Adaptive business intelligence based on evolution strategies: some application
examples of self-adaptive software. Information Sciences, v.148, n..1/4, p.113-121, Dec.
2002.
Barry, E. J.; Kemerer, C. F.; Slaughter, S. A. On the uniformity of software evolution
patterns. In: International Conference on Software Engineering, 25., may 2003, Portland,
Oregon, USA. Proceedings... Massachusetts: University of Massachusetts, 2003.
Bond, M; et al. Aprenda J2EE em 21 dias. São Paulo: Makron Books, 2003. 962p.
Borland Brasil. Disponível em: http://www.borland.com.br. Acesso em: 19 jun.2004.
Breton, E.; Bézivin, J. Model driven process engineering. In: IEEE Computer Society´s In:
International Computer Software and Applications Conference, 25.,2001, Chicago, USA.
Proceedings... Chicago: IEEE, 2001. p.225-230.
Burgareli, L. A. Abordagens de objetos distribuídos aplicados ao simulador de satélites
do INPE. 2003. 155p. (INPE-10052-TDI/888). Dissertação (Mestrado em Computação
Aplicada) – Instituto Nacional de Pesquisas Espaciais, 2003.
Cardoso, P. E. Estrutura de dados e regras de negócio configuráveis pelo usuário final.
Dissertação (Mestrado em Computação Aplicada) – Instituto Nacional de Pesquisas
Espaciais, São José dos Campos, 2004.
247
Chen, W.; Hiltunen, M. A.; Schlichting, R. D. Constructing adaptive software in distributed
systems. In: IEEE International Conference on Distributed Computing Systems, 21., apr.
2001, Phoenix, Arizona, USA. Proceedings... Arizona: IEEE, 2001. p.635-643.
Chung, L.; Cooper, K.; Yi, A. Developing adaptable software architectures using design
patterns: an NFR approach. Computer Standards & Interfaces, v.25, n.3, p.253-260,
2003.
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. 1997. Tese (Doutorado em Computação Aplicada). Instituto Nacional de
Pesquisas Espaciais, São José dos Campos, 1997.
Deva, D.; Sprinkle, G.; Maroti, M. Towards a standard for model specification and storage.
In: IEEE Systems, Man and Cybernetics Conference, Oct. 2000, Nashville, TN.
Proceedings... Washington: IEEE, 2000. p.364-369.
Fleury, M.; Reverbel, F. The jboss extensible server. Disponível em:
http://www.jboss.org/products/jbossas. Acesso em: 14 jun. 2004.
Ferreira, M. G. V. Uma arquitetura flexível e dinâmica para objetos distribuídos
aplicada ao software de controle de satélites. 2001. 244p. (INPE-8602-TDI/787). Tese
(Doutorado em Computação Aplicada) – Instituto Nacional de Pesquisas Espaciais, São
José dos Campos, 2001.
Foot, B.; Yoder, J. Metadata and active object-models. In: Conference on Patterns
Languages of Programs, 5., Aug. 1998, Monticello, Illinois, USA. Proceedings... Illinois:
University of Illinois, 1998.
248
Fowler, M. Analysis Patterns: reusable object models. Boston: Addison-Wesley, 1997.
357p.
Fowler, M. Using metadata. IEEE Software, v.19, n,6, p.13-17, Nov./Dec. 2002.
France, R.; et al. A metamodeling approach to pattern-based model refactoring. IEEE
Software, v.20, n.5, p.52-58, Sept./Oct. 2003.
Gamma, E.; et al. Design Patterns: elements of reusable object-oriented software. Boston:
Addison-Wesley, 1995. 395p.
Instituto Nacional de Pesquisas Espaciais. Multi-Mission Platform Specification.
Number A822000-PRR-01/03. São José dos Campos: INPE, ago. 2001.
Intersystems Corporation. Disponível em: http://www.sun.com. Acesso em: 15 jun. 2004.
JBoss Professional Open Source Company. Disponível em:
http://www.jboss.org/index.html. Acesso em: 15 jun. 2004.
Johnson, R.; Wolf, B. Type object. In: Martin R. S.; Riehle, D.; Buschmann, F. Pattern
languages of program design 3. Boston: Addison-Wesley, 1998.p.47-66
Johnson, R.; Yoder, J. W. The adaptive object-model architectural style. In: IEEE/IFIP
Conference on Software Architecture, 3.,Aug. 2002, Montreal, Canada. Proceedings...
Montreal: IEEE, 2002.
Keller, W.; Coldewey, J. Acessing relational databases. In: Martin, R. S.; Riehle, D.;
Buschmann, F. Pattern Languages of Program Design 3. Boston: Addison Wesley,
1998. p.313-343.
249
Killijian, M.; Fabre, J. C. Implementing a reflective fault-tolerant CORBA system. In:
Symposium on Reliable Distributed Systems, 19., Oct. 2000, Nurnberg Germany.
Proceedings... Washington: IEEE, 2000. p.154-163.
Ledeczi, A.; et al. Synthesis of self-adaptive software. In: IEEE Aerospace Conference,
2000, Manhattan. Proceedings... Manhattan: IEEE, 2000. p.501-507.
Lee, E. A. Computing for embedded systems. In: IEEE Instrumentation and Measurement
Technology Conference, May 2001, Budapest, Hungary. Proceedings... Budapest: IEEE,
2001. p.1830-1837.
Manolescu, D. A.; Johnson, R. E. Dynamic Object Model and Adaptive Workflow.
In: Metadata and Active Object-Model Pattern Mining Workshop,Oct. 1999,
Illinois. Proceedings... Illinois: University of Illinois, 1999.
Manolescu. D. “Micro-Workflow”: a workflow architecture supporting
compositional object-oriented software development. 2000. Tese (Doutorado em
Computer Science Technical Report) - University of Illinois, Illinois, USA, 2000.
Moro, M. M. et al. Dynamic specifications using versions and time. In: IEEE International
Database Engineering and Applications Symposium,2001, Montreal, Canada.
Proceedings... Montreal: IEEE, 2001. p.99-107.
Nakamura, H.; Johnson, R. Adaptive framework for the REA accounting model. In:
Workshop on Business Object Design and Implementation, 4., Oct. 1998, Vancouver,
Canda. Proceedings... Vancouver: OOPSLA, 1998.
250
Nguyen-Tuong, A.; Grimshaw, A. S. Using reflection for incorporating fault-tolerance
techniques into distributed applications. Parallel Processing Letters, v.9, n.2, p.291-301,
1999.
OMG. Model Driven Architecture (MDA): document number ormsc/2001-07-01.
Disponível em: http://www.omg.org. Acesso em: 28 mar. 2002.
Perkins, A. Business rules=meta-data. In: International Conference on Technology of
Object-Oriented Languages and Systems, 34., July/Aug. 2000, Santa Barbara, California,
USA.Proceedings... Washington: IEEE, 2000. p.285-294.
Pirmez, L.; Correia, R. B.; Bacellar, L. F. H. An adaptive distributed system based on
conditional dependencies. In: IEEE Workshop on Object-Oriented Real-Time Dependable
Systems, 17., Jan. 2002, San Diego, California. Proceedings... Washington: IEEE, 2002.
Poole, J. D. Model Driven Architecture: vision, standards and emerging technologies. In:
Workshop on Metamodeling and Adaptive Object Models, Apr.2001, Budapest, Hungary.
Proceedings... Budapest: IEEE, 2001.
Riehle, D.; et al. Dynamic object model. In: Conference on Patterns Languages of
Programs,7., Oct. 2000, Washington. Proceedings... Washington: Washington University,
Department of Computer Science, 2000.
Roberts, D.; Johnson, R. Patterns for Evolving Frameworks. In: Martin, R. S.; Riehle, D.;
Buschmann, F. Pattern languages of program design 3. Boston: Addison-Wesley, 1998.
p.471-486.
251
Rozenfeld, P.; Orlando, V.; Ferreira, M.G.V. Applying the 21th century technology to the
20th century mission control. In: Space Operations 2002 Conference, Oct. 2002.
Proceedings... Washington:: NASA, 2002.
Rumbaugh, M.; et al. Object-Oriented Modeling and Design. Englewood Cliffs, New
Jersey: Prentice-Hall, 1991.
Silva, F. J. S. Adaptação Dinâmica de Sistemas Distribuídos. 2003. 110p. Tese
(Doutorado em Ciência da Computação) – Instituto de Matemática e Estatística da
Universidade de São Paulo, São Paulo, 2003.
Siqueira, E. G. Estratégias e padrões para modelagem da interface humano-
computador de sistemas baseados na arquitetura SOFTBOARD. 2001. 171p. (INPE-
9621-TDI/844). Dissertação (Mestrado em Computação Aplicada) – Instituto Nacional de
Pesquisas Espaciais, São Jose dos Campos, 2001.
Soler, F. O.; Lovelle, J. M. C. Building a completely adaptable reflective system.In:
ECOOP´2001 Workshop on Metamodeling and Adaptive Object Models, Apr.2001,
Illinois. Proceedings... Illinois: University of Illinois, 2001.
Souza, A. D. D. Structuring adaptive applications using Aspect J. 2004. 93p.Dissertação
(Mestrado em Ciência da Computação) - Universidade Federal de Pernambuco, Recife,
2004.
Sprinkle, J. M.; et al. The new metamodelins generation. Annual IEEE International
Conference and Workshop on the Engineering of Computer Based Systems, 8., Apr. 2001,
Washington. Proceedings... Washington: IEEE, 2001. p.275-279
252
Stehling, R. O. Projeto e implementação de uma arquitetura de software reflexiva para
linguagem Xchart. 1999. 61f. Dissertação (Mestrado em Computação) - Instituto de
Computação,Universidade Estadual de Campinas, Campinas, 1999.
SunMicrosystems. J2EE 1.4 specification final release. Disponível em:
http://www.sun.com. Acesso em: 13 jun. 2004.
SunMicrosystems (a). Enterprise java beansTM specification version 2.1 . Disponível
em: http://www.sun.com. Acesso em: 13 jun.2004.
SunMicrosystems (b). UML profile for EJB. Disponível em: http://www.sun.com. Acesso
em: 13 ago.2004.
Tan, J.; Zaslavsky. Domain-specific metamodels for heterogeneous information systems.
In: IEEE Hawaii International Conference on System Sciences, 36., Jan. 2003, Island of
Hawai. Proceedings... Hawai: University of Hawai, 2003.
Thomé, A. C.; Ferreira, M. G. V.; Cunha, J. B. S. SICSDA: An adaptive configurable
distributed software architecture applied to satellite control missions. In: Simpósio
Brasileiro de Engenharia de Software, 17., out. 2003, Manaus, AM. Anais... Manaus:
Universidade Federal do Amazonas, 2003.
Thomé, A. C.; Ferreira, M. G. V.; Cunha, J. B. S.(b). Uma arquitetura de software reflexiva
baseada em modelos de objetos adaptáveis. In: Encontro de Informática de Campo Largo,
2., nov. 2003, Campo Largo, PR. Anais... Campo Largo: Faculdade Cenecista Presidente
Kennedy, 2003.
253
Thomé, A. C.; Ferreira, M. G. V.; Cunha, J. B. S.. Uma Arquitetura de Software
Distribuída, Configurável e Adaptável Aplicada às Várias Missões de Controle de Satélites
(SICSDA). In: Worshop dos Cursos de Computação Aplicada do INPE, 3., nov. 2003, São
José dos Campos, SP. Anais... São José dos Campos: INPE, 2003.
Thomé, A. C.; Ferreira, M. G. V.; Cunha, J. B. S. Establishing an adaptive configurable
distributed software architecture applied to satellite control missions. In: International
Conference on Space Operations, 8., May 2004, Montreal, Canada. Proceedings...
Montreal: National Research Council Canada, 2004.
Thomé, A. C.; Ferreira, M. G. V.; Cunha, J. B. S.(b). SICSDA: an Adaptive Configurable
Distributed Software Architecture Applied to Satellite Control Missions. In: European
Conference on Object-Oriented Programming, 18., June 2004, Oslo, Norway.
Proceedings... Oslo: University of Oslo, 2004.
Thomé, A. C.; Ferreira, M. G. V.; Cunha, J. B. S.(c). SICSDA - Uma Arquitetura de
Software Distribuída, Configurável e Adaptável Aplicada às Várias Missões de Controle de
Satélites. In: Worshop dos Cursos de Computação Aplicada do INPE, 4., out. 2004, São
José dos Campos, SP Anais... São José dos Campos: INPE, 2004.
Vaduva, A.; Kietz, J.; Zücker, R. M. A metamodel for data preprocessing. In: International
Workshop on Data Warehousing and OLAP, 4., Nov. 2001, Atlanta. Proceeding...
Atlanta: S.n, 2001. p.85-92.
Vawter, C.; Roman, E. J2EE vs. Microsoft.NET: a comparison of building XML-based web services. Disponível em: http://www.theserverside.com/articles/article.tss?l=J2EE-vs-DOTNET. Acesso em 16 abr. 2004. Vinosky, S. CORBA: Integrating diverse applications within distributed heterogeneous
environments. IEEE Communications Magazine, v.35, n.2, p.46-55, Feb.1997.
254
Wil. J2EE: arquitetura e tecnologias da plataforma J2EE. Disponível em:
http://www.wil.com.br/wil/Noticia.asp. Acesso em: 09 jul.2004.
Witthawaskul, W. Johnson, R. Specifying Persistence in Platform Independent Models. In:
Workshop in Software Model Engineering, Oct. 2003, San Francisco. Proceedings...
Washington: IEEE, 2003.
Yoder, J.; et al. Connecting business objects to relational databases. In: Conference on
Patterns Languages of Programs, 5., Aug. 1998, Monticello, Illinois. Proceedings...
Monticello: University of Illinois, 1998.
Yoder, J. W.; Razavi, R. Metadata and adaptive object-models. In: European Conference on
Object-oriented Programming, 14. June 2000, Sophia Antipolis and Cannes, France.
Proceedings... Sophia Antipolis: University of Nice Sophia Antipolis, 2000. p.104-112.
Yoder, J. W.; et al. Architecture and design of adaptive object-models. ACM Sigplan
Notices, v.36, n.12, p. 50-60, Dec. 2001.
Yoder, J. Johnson, R. Architecture and Design of Adaptive Object-Models. ACM Sigplan
Notices, v.36, n.12, p.50-60, Dec. 2001.
255
APÊNDICE A
PROBLEMAS ENCONTRADOS NA IMPLEMENTAÇÃO DA ARQUITETURA
Neste apêndice foram detalhados alguns dos problemas encontrados durante o
desenvolvimento e implementação da arquitetura, principalmente no tocante às ferramentas
adotadas. São eles:
• Escolha da linguagem de programação: a escolha da linguagem de programação foi
um item de extrema importância, já que era necessária uma linguagem suficientemente
robusta para suportar características de reflexão. A princípio houve dúvida entre o uso
de linguagens compiladas/interpretadas e puramente interpretadas. A escolha foi difícil,
pois as linguagens puramente interpretadas permitem uma maior flexibilidade em
relação à manutenção dos metadados, já que permitem, por exemplo, que uma linha de
código possa ser incorporada ao sistema em tempo de execução (sem a necessidade de
compilação). Por outro lado, de acordo com as características dos sistemas de controle
de satélites, o fato de ser necessário ou não realizar novamente a compilação do sistema
após a criação de uma nova regra de negócio não é importante, uma vez que, lançado o
satélite, suas regras de negócio não mudam durante a sua existência. Assim sendo, as
alterações nas regras de negócio normalmente serão realizadas apenas quando um outro
satélite for lançado. O Java, por outro lado, era uma linguagem já utilizada, e o seu
potencial para reflexão era conhecido, e o mais importante, fornecia condições para a
distribuição do sistema, o que não é bem estabelecido nas linguagens interpretadas.
Essas condições fizeram com que optássemos pelo Java.
• Escolha da plataforma de armazenamento dos metadados: o uso de bancos de
dados relacionais foi descartado desde o início, pois era suposto que os bancos de dados
orientados a objeto ou o uso de arquivos XML facilitariam a implementação. Por outro
256
lado, não se tinha nenhuma experiência com ambas as tecnologias (banco de dados
orientado a objetos e XML). A princípio tendeu-se para o XML, porém, o fato do XML
não permitir um gerenciamento dos dados mais elaborado fez com que se optasse pelos
bancos de dados orientados a objetos. A dificuldade inicial foi conseguir um banco de
dados orientado a objetos gratuito, e isto demandou algumas semanas de pesquisa.
Finalmente, foi encontrado o Intersystems Caché, que aparentemente supria todas as
necessidades da arquitetura. Instalá-lo e usá-lo exigiu algum tempo de dedicação. Foi
necessário atualizar a versão do compilador Java existente na máquina (1.0), já que o
Caché só suportava uma versão igual ou superior a versão 1.3. Inicialmente foi usada a
versão 5.0 do Caché, porém, para que ele pudesse ser utilizado concomitantemente com
o JBoss foi necessário fazer uma migração para a versão 5.0.5.
• Escolha do ambiente de desenvolvimento da aplicação: inicialmente foi utilizado o
PowerJ como ambiente de desenvolvimento, porém, percebeu-se que não seria possível
integrá-lo com o Caché , já que o PowerJ só suportava o Java 1.0. Não era possível usar
uma versão mais atualizada do PowerJ, pois as versões superiores não eram gratuitas.
Decidiu-se, então, procurar outro ambiente de desenvolvimento que fosse compatível
com o Caché, e optou-se pelo uso do SunOne. Novamente, foi necessário fazer um
upgrade do compilador Java, pois o SunOne só suportava o Java 1.4 ou superior.
Aplicações não distribuídas foram desenvolvidas nestas configurações, porém, quando
foi decido que se usaria a plataforma J2EE para a distribuição, principalmente por
questões de desempenho e facilidade de uso, novamente mudou-se o ambiente de
desenvolvimento, e foi decidido que se usaria o Jbuilder. Inicialmente foi utilizada a
versão IX, e mais tarde, migrou-se para a versão X.
• A escolha do servidor de aplicações J2EE: a princípio decidiu-se pelo uso do
Borland Enterprise Server (BES), porém, após algumas tentativas descobriu-se que ele
não era compatível com o Caché, e então, após uma pesquisa sobre os servidores
257
compatíveis potenciais, tomou-se a decisão de se usar o JBoss. Várias versões do JBoss
foram testadas e finalmente optou-se pela versão 3.0.8, já que outras mais avançadas
não apresentaram o resultado esperado no tocante à compatibilidade com o Caché.
Finalmente, o protótipo 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 Jboss versão 3.0.8.
258
259
GLOSSÁRIO
AOM – Adaptive Object Model ou Modelo de Objetos Adaptável
BMP – Bean Managed Persistense
CBERS1 – China Brazil Earth Research Satellite 1
CBERS2 – China Brazil Earth Research Satellite 2
CCS – Centro de Controle de Satélites
CDP – Componente Domínio do Problema
CGD – Componente Gerenciador de Dados
CGT – Componente Gerenciador de Tarefas
CIH – Componente Interface Humana
CIS – Componente Interface entre Sistemas
CMOOS – Componente Gerenciador de Configuração de Sistema Baseado em Objetos
CMP – Container Managed Persistense
CORBA – Common Object Request Broker Architecture
UCP – Unidade Central de Processamento
CWM – Common Warehouse Metamodel
DTD – Document Type Definitions
DTF – Domain Task Force
EJB – Enterprise Java Bean
FLOI – Fase de Lançamento de Órbitas Iniciais
HTML – Hypertext Markup Language
IDL – Interface Definition Language
J2EE – Java 2 Enterprise Edition
MDA – Model Driven Architecture
MMP – Multi-Mission Platform ou Plataforma Multi-Missão
MOF – Meta Object Facility
MTS - Microsoft Transaction Server
OMG – Object Management Group
260
PIM – Platform Independent Model ou Modelo Independente de Plataforma
PSM - Platform Specific Model ou Modelo Específico de Plataforma
SCD1 – Sistema de Coleta de Dados 1
SCD2 – Sistema de Coleta de Dados 2
SICS – Sistema de Controle de Satélites
SICSD – Sistema de Controle de Satélites Distribuído
SICSDA – Sistema de Controle de Satélites Distribuído e Adaptável
TMTC – Telemetry and Telecommand
UML – Unified Model Language
XMI – XML Metadata Interchange
XML – Extensible Markup Language
W3C – World Wide Web Consortium
