gestão de dados partilhados em ambientes de computação móvel

48 CAPÍTULO 3. APRESENTAÇÃO DO SISTEMA DOORS
interface definida. Esta aproximação permite criar um novo componente de um dado tipo de forma
independente, i.e., sem conhecer a implementação dos componentes com os quais ele interage.
Em alguns componentes utilizaram-se classes base abstractas para definir a interface do componente
(em vez de interfaces Java). Esta opção tem duas vantagens. Primeiro, permite criar definições típicas de
alguns métodos. Segundo, permite implementar de forma definitiva os métodos que executam funções
críticas para o sistema DOORS, como por exemplo, os métodos que lidam com a representação dos
coobjectos e subobjectos usada no núcleo do sistema (por exemplo, os identificadores). Esta aproximação
garante que o mau funcionamento de um coobjecto não corrompe outros coobjectos.
Sempre que necessário, um programador pode estender a interface básica definida para um dado
componente com novos métodos. A nova interface estendida pode ser usada, não só na criação de novos
componentes desse tipo, mas também na criação de outros componentes que necessitem de utilizar as
novas funcionalidades disponibilizadas pelos novos métodos. Neste caso, um componente que requeira
as novas funcionalidades apenas pode ser composto com um componente que implemente a interface
estendida, impondo assim uma restrição nas composições possíveis.
Um coobjecto é definido como uma composição de componentes definidos de acordo com o fra-
mework de componentes DOORS. No protótipo do sistema DOORS, o código de criação e ligação dos
vários componentes deve ser criado pelo programador como parte do código do componente cápsula.
Como se disse anteriormente, as ligações entre os vários componentes devem respeitar as interfaces
esperadas por cada um dos componentes.
No âmbito do projecto DataBricks [36] estão-se a investigar formas alternativas de definição dos
coobjectos. Assim, recorrendo a uma linguagem de composição de componentes, o ComponentJ [153],
a composição e ligação dos vários componentes de um coobjecto deve ser efectuada exteriormente ao
código dos componentes do coobjecto. Esta linguagem deve permitir ainda verificar estaticamente a
compatibilidade das ligações entre os vários componentes. Finalmente, deve ser possível criar esque-
letos (templates) de coobjectos. Um esqueleto de um coobjecto define uma composição típica para um
coobjecto no qual ficam por definir um ou mais componentes (em geral, os subobjectos). Assim, um
programador pode criar um coobjecto, a partir dos subobjectos que pretende gerir, usando o esqueleto
com a semântica desejada. Este trabalho está, no entanto, fora do âmbito desta dissertação.
3.4.1 Pré-processador
Actualmente, o protótipo do sistema DOORS inclui apenas um pré-processador para simplificar a criação
de componentes e subobjectos. Os programadores definem um componente ou um subobjecto como uma
classe na linguagem Java estendida com os seguintes elementos:
• Um conjunto de qualificadores de métodos (descritos na secção 3.2.2.5) que definem o tipo de