Estando conclu´ıdo um prot´otipo do sistemaAlma ´e interessante ver o modelo do sistema tendo como base m´aquinas virtuais.
O processo de animac¸˜ao depende de duas tarefas distintas e independentes que, no entanto, devem estar sincronizadas: a reescrita e a visualizac¸ ˜ao da DAST. Todo este processo trabalha sobre essa representac¸ ˜ao interna abstracta, usando diferentes tipos de especificac¸ ˜oes relacionadas com: o desenho a gerar; a reescrita da ´arvore; o controlo do screen pointer; o controlo do tree pointer; e, por ´ultimo, o controlo global da animac¸˜ao gerada (ou seja, controlo do processo de sincronizac¸ ˜ao entre a reescrita da ´arvore a a gerac¸˜ao da visualizac¸ ˜ao).
Durante a especificac¸ ˜ao do sistema Alma detectou-se a necessidade de definir quais os comandos de desenho que poder˜ao ser utilizados na definic¸˜ao das regras de visualizac¸ ˜ao (linguagem de desenho). Um outro conjunto de comandos era tamb´em preciso para especificar as alterac¸ ˜oes que aDASTsofre aquando da aplicac¸ ˜ao de uma regra de reescrita (linguagem de transformac¸ ˜ao de ´arvores).
Para al´em disso, sentiu-se a necessidade de criar um mecanismo de sincronizac¸ ˜ao entre o processo de reescrita e o processo de visualizac¸ ˜ao. Este mecanismo permite controlar o detalhe da animac¸˜ao, con- trolando o n´umero de reescritas efectuadas antes de cada visualizac¸ ˜ao. Para que este controlo possa ser feito facilmente, a sua implementac¸ ˜ao baseia-se em comandos (mais uma linguagem a definir, linguagem
de controlo de animac¸˜ao) que permitem calcular a frequˆencia de amostragem.
Estas trˆes linguagens internas, que tiveram de ser definidas, podem ser consideradas como casos de DSL (Domain Specific Language): foram criadas para sistematizar a programac¸ ˜ao das regras; para facilmente alterar os desenhos da animac¸˜ao; para especificar a semˆantica associada aos programas que queremos animar ou a frequˆencia de amostragem da animac¸˜ao.
Na figura 5.17 est˜ao esquematizadas as v´arias tarefas envolvidas na construc¸ ˜ao da animac¸˜ao. Cada linguagem de especificac¸ ˜ao ficar´a sujeita `a respectiva m´aquina virtual, que interpreta o texto fonte e produz o respectivo resultado.
Ctrl MV1 Anim TreeWalker Visualizer VRB MV3 MV2 VL RL RRB TreeCtrl DAST ScrCtrl U S R I N T E R F A C E E TreeWalker Rewriter
Figura 5.17: Processo de construc¸ ˜ao das visualizac¸ ˜oes
A linguagem de desenho (VL) cont´em as instruc¸ ˜oes respons´aveis pelo desenho da ´arvore num dado instante. Esse desenho mostra um estado interno do programa fonte durante a sua execuc¸˜ao.
VL -> &
| Shape VL
Shape -> StructShp | OperationShp
StructShp -> (constshp|varshp|arrayshp|treeshp |queueshp|stackshp) tree_node
OperationShp-> (gen-opershp | relopershp) tree_node | readshp | writeshp
Estes comandos representam n˜ao s´o o desenho que ir´a ser produzido mas tamb´em os valores e etiquetas que ter˜ao que ser inclu´ıdos e que dependem dos atributos dos nodos daDAST(tree node).
A linguagem de reescrita serve para especificar as alterac¸ ˜oes que aDASTter´a que sofrer para representar um novo estado do programa fonte.
RL -> &
| RewStat RL
RewStat -> CondStat | Stat CondStat -> Cond+ Stat+
Cond -> Stat reloper Stat Stat -> setAtt tree_node att
| getAtt tree_node att
| copyNode tree_node tree_node | delNode tree_node
| Stat oper Stat
Cada RewStat representa uma instruc¸˜ao de reescrita que pode estar condicionada ou n˜ao. Estes co- mandos representam todo o processo de reescrita: n˜ao s´o incluem comandos que efectuam a alterac¸ ˜ao de valores (alterac¸ ˜oes semˆanticas) como ´e o caso de setAtt como tamb´em as condic¸ ˜oes necess´arias para que essas alterac¸ ˜oes sejam feitas. Os comandos copyNode e delNode implementam alterac¸ ˜oes sint´acticas naDAST.
A linguagem de controlo do screen pointer serve para poder manipular as posic¸ ˜oes de desenho no ecr˜a, criar novas janelas; abrir e fechar janelas j´a existentes.
ScrCtrl -> clear | new_wind coords int int int n_janela | close_wind int | set SP coords int |
open_wind int | get SP int
A linguagem de controlo do tree pointer serve para controlar as travessias na ´arvore (usado, principal- mente nas estruturas repetitivas); e para colocar marcas nos nodos que dever˜ao ou n˜ao ser visualizados (para controlar o detalhe da visualizac¸ ˜ao).
TreeCtrl -> set TP tree_node | get TP |go_home |
setvisible tree_node | setinvisible tree_node
A linguagem de controlo da animac¸˜ao serve para sincronizar o processo de reescrita com o processo de visualizac¸ ˜ao que tamb´em pode servir para controlar o detalhe das animac¸ ˜oes.
AnimCtrl -> rewrite tree_node | visualize tree_node
A especificac¸ ˜ao do sistemaAlmaj´a tem definido o posicionamento dos desenhos no ecr˜a. A disposic¸ ˜ao dos desenhos n˜ao ser´a program´avel. Os desenhos aparecem sequencialmente tal como ´e sequencial a execuc¸˜ao dos programas. O desenho de uma instruc¸˜ao b´asica (atribuic¸ ˜oes, leituras, escritas, invocac¸ ˜ao de func¸ ˜oes, etc) ocupa uma linha. Se se tratar uma instruc¸ ˜ao condicional ou c´ıclica, o desenho ocupa uma linha para a condic¸˜ao seguida de um n´umero linhas dependente do numero de instruc¸ ˜oes agrupadas. Sempre que h´a um agrupamento de instruc¸ ˜oes dentro de uma estrutura condicional ou c´ıclica ´e feita uma indentac¸ ˜ao em todas os desenhos relativos a essas instruc¸ ˜oes. Existem ainda alguns desenhos auxiliares que permitem distinguir uma instruc¸ ˜ao condicional da c´ıclica, assim como, para a distinc¸ ˜ao entre as instruc¸ ˜oes da primeira parte de uma instruc¸˜ao condicional (diz respeito ao THEN) e a segunda parte da mesma (diz respeito ao ELSE). Assim sendo, o ScrCtrl ´e feito com a ajuda do c´alculo do n´ıvel de aninhamento (n´umero de indentac¸ ˜oes) e do n´umero de instruc¸ ˜oes agrupadas (n´umero de linhas com indentac¸ ˜ao).
operrelShape : nome_oper,n_inst_agrupadas,n´ıvel_aninhamento -> desenho
O desenho associado a um operador relacional ´e definido na entidade operrelShape onde ir´a tamb´em ser armazenada informac¸ ˜ao sobre os desenhos das instruc¸ ˜oes agrupadas sob essa condic¸˜ao.
O chamado TreeCtrl ´e efectuado `a custa de etiquetas postas nos nodos da DAST, de modo a que a travessia da ´arvore seja por vezes interrompida ou repetida nalguns nodos, dependendo do valor das condic¸ ˜oes das estruturas condicionais ou c´ıclicas.
Exemplos:
putName(‘‘SKIP’’) no nodo que encabec¸a o grupo de instruc¸˜oes a ser ignorado
putName(‘‘REP’’) no nodo que encabec¸a o grupo de instruc¸˜oes a ser atravessado novamente.
Estes comandos s˜ao usados nas regras de reescrita. Durante o processo de reescrita a ´arvore ´e atravessada seguindo uma pol´ıtica pr´e-order, mas quando ´e aplicada uma regra que detecta a existˆencia de alguma destas etiquetas a travessia pode ser abortada ou repetida para alguns nodos.
Nesta nova perspectiva, ou vis˜ao, do back-end, podemos ent˜ao dizer que o sistemaAlma´e constru´ıdo `a custa de cinco DSL’s e inclui trˆes m´aquinas virtuais com os seguintes objectivos:
MV1 - para controlo do detalhe da animac¸˜ao; sincronizac¸ ˜ao entre o processo de reescrita e o processo de visualizac¸ ˜ao atrav´es da func¸˜ao shownow() do algoritmo de animac¸˜ao.
MV3 - para interpretac¸ ˜ao dos comandos de alterac¸˜ao dos atributos dos nodos que constam nas regras de reescrita.
Diferentes n´ıveis de utilizac¸˜ao do Sistema
Alma
Como se disse em [VH03], ap´os a implementac¸ ˜ao do prot´otipo do sistemaAlmaconcluiu-se que, para abranger outros tipos de linguagens ou outros tipos de visualizac¸ ˜oes, bastaria acrescentar mais regras ao sistema. O sistemaAlmatornou-se assim um sistema aberto, preparado para ser constantemente actual- izado mediante as necessidades. Esta tarefa de actualizac¸ ˜ao ´e bastante simples porque a implementac¸ ˜ao do sistema seguiu uma filosofia modular onde est˜ao muito bem definidas as partes fixas e as que podem ser modificadas.
A ideia de criar um sistema aberto surge da necessidade de conjugar a generalidade do sistema com a sua adequac¸ ˜ao aos diversos tipos de problemas a resolver. Sendo assim, a parte fixa do sistema concede-lhe a generalidade pretendida e a outra parte, que poder´a ou n˜ao ser modificada, concede-lhe a adequac¸ ˜ao necess´aria para obter bons resultados nas mais diversas situac¸ ˜oes.
Neste cap´ıtulo, ir˜ao ser apresentados trˆes n´ıveis de utilizac¸ ˜ao do sistema. O tipo de utilizac¸ ˜ao depende do tipo de utilizador: o utilizador final que usa o sistema para animar os seus mais diversos programas; o utilizador interm´edio que pretende preparar o sistema para uma nova linguagem (sem fazer alterac¸ ˜oes ao sistema); e o utilizador que pretende acrescentar ao sistema novas potencialidades. Estes dois ´ultimos implicam o acrescento de novas regras e conceitos, ou simplesmente a construc¸ ˜ao de um novo front-end.