Constru¸ c˜ ao e processamento dos relat´ orios

6.2 Gera¸ c˜ ao de relat´ orios

6.2.3 Constru¸ c˜ ao e processamento dos relat´ orios

Já foi explicada a concep¸cão e implementa¸cão do Report e já se estabeleceu a forma como o componente observador se relaciona com o elemento observado, para que o primeiro possa ter acesso aos relatórios gerados pelo último. Falta agora explicar como é que se constrói um objecto do tipo Report, isto é, quando, onde e como inserir a informa¸cão dos métodos invocados em Report ; e explicar como é que o componente observador pode/deve processar a informa¸cão do Report.

A constru¸cão dos objectos Report está relacionada com a implementa¸cão da inter- face Observed, cuja adapta¸cão à DIR e mais genericamente à versão original da framework Dolphin é explicada na Seçcão 7.3. Fica no entanto aqui um pequeno exemplo, representado na Figura 6.13, que ilustra como é que o processo se desenrola para o método bool ins- Node(FlowNode*) de CFG. Como é explicado na Seçcão7.3, os métodos que alteram o estado dos elementos têm que ser reescritos. Por exemplo, neste caso bool O CFG::insNode(FlowNode*) reescreve o método base (bool R CFG::insNode(FlowNode*)). Isto não significa que o mé- todo base deixa de existir, apenas que o utilizador passa a ver o método reescrito, em vez do método base.

As opera¸cões efectuadas pelo método reescrito visam essencialmente assegurar a manu- ten¸cão do Report. Não são efectuadas opera¸cões que estejam directamente relacionadas com o elemento em causa (elemento observado). Assim, o método reescrito come¸ca por invocar o método base (bool st= R CFG::insNode(n);); depois testa a variável rep para determinar se Report existe, se assim for, é criado um objecto do tipo Method, no qual se inserem os valores dos parâmetros, o valor do resultado e o identificador do método e da classe. Por fim, faz-se a notifica¸cão dos observadores através de Observed::notify(), enviando o relatório, se este tiver sido solicitado.

(1) bool _O_CFG::insNode(FlowNode *n){

(2) bool st=_R_CFG::insNode(n);

(3) if(___rep){

(4) Method<bool,TL1(FlowNode*)> *m

(5) =new Method<bool,TL1(FlowNode*) >(n);

(6) if(m){ (7) m->setR(st); (8) m->setMID("insNode"); (9) m->setCID("CFG"); (10) ___rep->enqueue(m); (11) } (12) } (13) Observed::notify(); (14) return st; (15) }

Figura 6.13: Exemplo da constru¸c˜ao de um objecto do tipo Report.

Falta apenas explicar o que acontece do lado do componente observador. Este tem que processar cada um dos AbstractMethods contidos na fila de Report. Acontece no entanto, que através de AbstractMethod não é poss´ıvel utilizar os métodos definidos em Method, funda-

mentais para se aceder aos parâmetros e ao valor de retorno. Infelizmente e tanto quanto foi poss´ıvel apurar, em C++ não há muitas mais alternativas do que efectuar um dynamic cast para determinar o tipo concreto de Method representado por AbstractMethod. Isto é feito, indicando ao dynamic cast o tipo de Method que se espera obter, isto é, assinalando o tipo de retorno e os tipos dos parâmetros. Se a opera¸cão de casting for poss´ıvel de efectuar, o que significa que o AbstractMethod realmente corresponde ao Method que se pretende obter, então será devolvido um apontador para este último, caso contrário será devolvido NULL.

E evidente que o componente não tem como saber qual o Method concreto representado por AbstractMethod, pelo que o processo de identifica¸cão é efectuado por tentativas. Isto é particularmente grave se o componente estiver a observar muitos elementos da RIC e se esses elementos possu´ırem muitos métodos que permitam alterar o seu estado. O que implica por um lado ter que efectuar muitos testes para identificar o método, e por outro lado, ter que implementar muitos contra-métodos, colocando em questão a utiliza¸cão desta solu¸cão.

No entanto, a experiência adquirida com a aplica¸cão do Report à framework Dolphin (versão definitiva), permitiu constatar que se a escolha dos elementos a observar for bem feita, raramente é necessário observar mais do que um ou dois tipos diferentes de elementos. Constatou-se também, que normalmente o número de métodos para os quais o componente tem que identificar e implementar contra-métodos, é bastante restrito. Isto porque:

• Em muitos casos, apenas parte da informa¸cão de um elemento, interfere com o estado do componente. Como tal, apenas é necessário controlar os métodos que alteram a informa¸cão da qual o componente é dependente, e não todos os métodos do elemento observado;

• Constata-se também que muitos métodos são implementados exclusivamente com base noutros métodos mais primitivos. Nestes casos, é suficiente implementar contra-métodos para os métodos primitivos. Os restantes apenas necessitam que se mantenha o estado do componente em UPDATED ;

• E também, porque em determinados componentes nem sempre é fácil ou vantajosa a implementa¸cão de contra-métodos.

De notar que, por omissão e no sentido de precaver o correcto funcionamento de todo o sistema, quando um método não é identificado ou quando não existem contra-métodos, o estado do componente deve ser colocado em OUTDATED. Isto permite que a identifica¸cão dos métodos seja feita, considerando apenas os métodos para os quais se implementou contra- métodos, o que reduz substancialmente o número de opera¸cões de dynamic cast. Convém no entanto explicar que há alguns casos particulares. Por exemplo, como anteriormente se disse, um método que invoque exclusivamente métodos mais primitivos, não requer a implementa¸cão de contra-métodos no sentido estrito do termo. Na prática, é necessário implementar um contra-método, não para contrapor as altera¸cões ocorridas na RIC, mas para evitar que o estado do componente passe a OUTDATED. É como tal necessária a identifica¸cão prévia deste tipo de métodos.

A Figura 6.14 ilustra como é que, segundo esta solu¸cão, é poss´ıvel implementar os contra-métodos e o método bool notify(Observed*,Report*), para o exemplo da Figura6.5. O Cap´ıtulo 8contém um exemplo completo feito com um componente da framework Dolphin. Esta forma de processar o Report não é certamente a solu¸cão ideal, mas foi a solu¸cão encontrada que melhor se adequava às necessidades do problema em causa. Não estão no entanto exploradas todas as alternativas, pelo que poderá haver solu¸cões melhores para este problema em concreto.

6.2. Gera¸c˜ao de relat´orios 121

(1) bool Comp::procM(Observed *obs,Method<int,TL1(char*)> *m){...}

(2) bool Comp::procM(Observed *obs,Method<int,TL1(int)> *m){...}

(3) bool Comp::procM(Observed *obs,Method<int,TL2(char*,int)> *m){...}

(4)

(5) bool Comp::notify(Observed *obs,Report *r){

(6) bool st; (7) AbstractMethod *m; (8) if(r && getState()==UPDATED){ (9) int i, nn=r->howMany(); (10) for(i=0;i<nn;i++){ (11) m=r->dequeue(); (12) st=false;

(13) Method<int,TL1(char*)> *m1

(14) =dynamic_cast<Method<int,TL1(char*)>*>(m);

(15) if(m1) st=procM(obs,m1);

(16) else{

(17) Method<int,TL1(int)> *m2

(18) =dynamic_cast<Method<int,TL1(int)>*>(m);

(19) if(m2) st=procM(obs,m2);

(20) else{

(21) Method<int,TL2(char*,int)> *m3

(22) =dynamic_cast<Method<int,TL2(char*,int)>*>(m);

(23) if(m3) st=procM(obs,m3); (24) } (25) } (26) if(!st) setState(OUTDATED); (27) r->enqueue(m); (28) } (29) } (30) return st; (31) }

Figura 6.14: Exemplo do processamento do Report.

No documento Um modelo arquitectónico para desenvolvimento de compiladores: aplicação à framework Dolphin (páginas 135-137)