1.4. SUYÛṬÎ’NİN HAYATI VE ESERLERİ HAKKINDA YAPILAN ÇALIŞMALAR
1.4.2. Diğer Çalışmalar
Após termos inserido alguns casos de testes na implementação da máquina, iremos fazer algumas considerações sobre os resultados obtidos e concluirmos em quais casos o uso de cada uma das estruturas é benéĄco à composição.
No Caso Teste 1, propomos dois cenários: no primeiro, com o Retry, tivemos um ganho no tempo total de execução da composição, em virtude do grande atraso que teríamos na espera da primeira execução do serviço; já no segundo, realizamos algumas tentativas que atrasaram o tempo total de execução da composição. Nesses dois casos, vemos que a escolha do valor do tempo de espera pela resposta de um serviço tem uma importância elevada, pois a escolha de valores inapropriados podem fazer com que tenhamos uma perda de eĄciência na execução da composição como um todo. Como o valor da especiĄcação é aplicado a todos os serviços, é necessário realizar um estudo sobre o tempo médio de resposta de todos os serviços e calcular um valor médio de espera para que haja o maior ganho possível de eĄciência na execução.
No Caso Teste 2, propomos um cenário em que um determinado serviço não realizasse a execução de uma solicitação do usuário. Na indisponibilidade do mesmo, foi necesário a troca deste serviço por outro que realizasse a mesma tarefa. Não colocamos aqui os critérios pelos quais nos baseamos para escolher a ordem dos serviços. Um dos motivos dessa escolha é que, por exemplo, o serviço em stand-by tem critérios menos atratíveis ao usuário. Entretanto, em relação às prioridades, a maior delas é a execução de uma composição. A indisponibilidade do primeiro serviço poderia fazer com que a mesma não executasse se não houvessem medidas alternativas a serem tomadas. Sendo assim, independente do tempo ou do custo de execução da composição, o Rebinding dá robustez à composição por permitir a troca e a continuação da execução de uma composição na ocorrência de uma falha de um serviço individual. Em alguns casos, um tempo de espera maior um maior número de tentativas poderia acarretar na execução do primeiro serviço, trazendo um custo menor para o usuário. Mesmo assim, o Rebinding dá a capacidade de mais soluções alternativas para a composição.
No Caso Teste 3, injetamos falhas na execução de serviços que estavam em uma sub- composição alternativa de uma pilha de subcomposições. Neste caso, utilizamos dois cenários: no primeiro, a falha ocorria logo no início da execução da subcomposição, enquanto no segundo caso, a falha ocorria em algum serviço próximo ao Ąm da subcomposição. Com a falha ocor- rendo no início da subcomposição, e não havendo mais soluções a serem aplicadas (Retry e Rebinding), temos de excluir este e os outros vértices restantes da subcomposição. O número
5.5. Conclusão dos Experimentos 101
de vértices excluídos é bem maior do que a ocorrência de uma falha no Ąnal da subcomposi- ção, entretanto, como nenhum processamento tinha sido realizado, não haverá inconsistências no resultado Ąnal com a troca de subcomposição. Já no segundo caso, com a falha ocorrendo no Ąm da subcomposição, o número de vértices a serem excluídos é bem menor, pois muitos foram executados e reduzidos. Entretanto, surge o problema da possível inconsistência em virtude de não ser possível realizar um roll-back. O ponto inicial de execução é retornado, entretanto, o processamento realizado não é desfeito. Na composição utilizada, não houve perdas, nem incon- sistências, pois estavamos trabalhando apenas com consultas. Porém, se existissem serviços que estivessem alterando informações que necessitassem ser desfeitas pela ocorrência de uma falha, teríamos resultados inesperados e muitas inconsistências no Ąnal da execução da composição. Sendo assim, o uso de subcomposições alternativas proporciona mais possilibidades do término da execução principal, mas outras falhas podem surgir, dependendo do processamento realizado antes da ocorrência da falha. Portanto, é preciso saber em quais momentos podemos utilizar subcomposições alternativas sem causar prejuízos ao resultado Ąnal das composições.
Por Ąm, o Caso Teste 4 utilizou todos os mecanismos de recuperação de falhas propostos. Sendo assim, trazemos também os benefícios e inconsistências dos três métodos.
Para o uso desses mecanismos, temos alguns custos na criação das estruturas. Com o tempo de resposta como critério de detecção, criamos um temporizador para cada execução de serviço. No ambiente utilizado para execução, não existe um Şparalelismo realŤ, tanto entre serviços quanto entre um serviço e o temporizador. Na proximidade entre os tempos de espera e de tempo execução de um serviço, pode acontecer que várias execuções tenham resultados diferentes: (i) um serviço pode executar antes do temporizador e enviar um sinal de executado para a máquina, ou (ii) um temporizador executa antes do serviço e envia um sinal para abortar sua execução. Por Ąm, temos um conjunto de soluções de recuperação que podem levar à execução completa da composição. Entretanto, existem alguns custos de eĄciência e inconsistência que devem ser analisados para se chegar a uma conclusão sobre a viabilidade do uso dos mecanismos em determinados pontos da composição.
103
6 CONCLUSÃO
Neste trabalho, apresentamos uma proposta de extensão de um ambiente de execução de composições de serviços com recuperação de falhas para uma variante da linguagem PEWS, cuja proposta foi implementada num ambiente real de execução de composições de Serviços Web, a máquina de redução de grafos PEWS-AM.
O processo baseou-se em mecanismos que foram descritos em alguns trabalhos, citados no capítulo 2 deste documento. Estes trabalhos abordam diferentes formas de tratamento. A partir da revisão bibliográĄca sobre as diferentes abordagens, escolhemos alguns mecanismos que cobrissem uma parte signiĄcante de falhas ocorridas em tempo de execução de composições de Serviços Web, abordando o tratamento de falhas de disponibilidade, sendo que os mecanismos de recuperação adotados foram: Retry, Rebinding e Restructure, que fazem, respectivamente, várias tentativas de conexão com o serviço, reconexão com outro serviço e substituição de trechos da composição principal por trechos alternativos.
Para que pudéssemos dar suporte a estes métodos, realizamos mudanças tanto na vari- ante de PEWS quanto na estrutura da máquina abstrata. Em PEWS, estendemos a linguagem para que a mesma desse suporte ao Retry (especiĄcando o número de tentativas de conexão com um mesmo serviço), Rebinding (criando uma nova construção na gramática que permitisse a especiĄcação de vários serviços que pudessem receber diferentes parâmetros de entrada, mas que tivessem a mesma saída) e Restructure (criando uma nova estrutura que desse a possibi- lidade de especiĄcar uma ou mais subcomposições que realizem uma mesma tarefa, havendo a substituição no caso de falha em qualquer ponto de uma subcomposição em execução). Esses métodos foram colocados como forma opcional de uso, ou seja, o designer da composição pode usar as especiĄcações da forma antiga.
Já na máquina abstrata, introduzimos a estrutura de dados pilha e criamos dois novos tipos de vértices compostos: as pilhas de chamadas de serviços e as pilhas de subcomposições. Serviços ou subcomposições errôneas que fazem parte de uma pilha são excluídos e substituídos por outro serviço ou subcomposição que faz parte da mesma pilha e que realizará a mesma tarefa. Para o suporte aos métodos, tivemos que realizar algumas alterações em determinadas reduções de alguns vértices, principalmente no vértice de entrada de serviços. A redução dos mesmos só ocorrerá quando a resposta for dada antes do tempo máximo esperado. Serviços e subcomposições alternativas devem ser especiĄcadas pelo designer da composição.
Além dessas extensões, implementamos algumas melhorias na máquina de redução: • Inserimos a capacidade da veriĄcação de variáveis não-inicializadas, dando suporte ao
tratamento desses casos em tempo de execução;
• Realizamos a diferenciação entre variáveis e strings, onde estes eram inseridos da mesma forma na especiĄcação da composição;
• Alteramos a semântica dos vértice Unfolding e Unfold, para o possível ganho de eĄciência em futuras implementações de uma outra máquina real (ou até mesmo do melhoramento de PEWS-AM) e também para o tratamento de vértices do tipo unfold, onde os mesmos não eram vértices avaliáveis, porém pertenciam a uma das regras simples da gramática; • Criamos um arquivo de saída para a análise dos dados de redução e demos a capacidade
do mesmo de descrever mais informações sobre os estados da máquina, como: arestas de controles entre os vértices, arestas de dependências entre os vértices, detalhes da redução dos vértices, etc.
Em virtude da vizualiação dessas estruturas no modo texto não ser uma forma viável para uma boa compreensão, integramos a máquina de redução com a ferramenta GraphViz, que tem a capacidade de construir grafos direcionados. Através da criação de algumas estruturas, conseguimos mostrar os estados da máquina em imagens a cada análise e redução dos vértices. Nas imagens, é possível visualizar vértices que executaram corretamente, vértices que falharam, vértices a serem excluídos após uma determinada redução, pilhas de chamadas e subcomposições, entre outros fatores.
Outro fator importante é que a implementação foi realizada de forma a permitir outros métodos de detecção de falhas. Podemos inserir outros métodos de detecção na máquina real apenas com a criação de classes especíĄcas ao mecanismo de detecção.
Os testes realizados mostram que, em muitas situações, o uso das estruturas criadas são benéĄcos à composição, uma vez que dão possibilidade para vários tipos de execuções al- ternativas. Já em alguns casos, vimos que o uso do Retry pode atrasar o tempo de execução total da composição de serviços, caso seus parâmetros não tenho sido bem especiĄcados. Sendo o maior objetivo a execução completa e correta da composição, concluímos que, para um maior ganho de eĄciência, devemos fazer um estudo da composição por inteiro, a Ąm de escolher-se os parâmetros cujo ganho de tempo seja o maior possível.
A máquina apresenta algumas limitações, principalmente quanto à compensação às al- terações realizadas. Na ocorrência de uma falha em uma subcomposição, todo o processamento anteriormente realizado por vértices pertencentes a ela não são desfeitos, ou seja, podem existir determinados casos em que inconsistências ou até mesmo erros não consigam ser evitados. Além disso, o ambiente que guarda o valor das variáveis suporta apenas o tipo de dados inteiro, ou seja, determinadas composições que precisam de tipos de dados textuais gravados no ambiente ainda não são possíveis. Outro fator a ser citado é que a descrição WSDL dos serviços necessita estar dentro da máquina para a execução das composições, não sendo possível ainda a execução de Serviços Web totalmente externos a esta.
Em trabalhos futuros, pretendemos alcançar os seguintes objetivos:
• Implementar novos mecanismos de detecção de falhas (por exemplo, Qos) e, possivelmente, fazer com que os vários mecanismos de detecção possam trabalhar em conjunto;
105
• Criar novos mecanismos de recuperação de falhas, onde os mesmos podem tratar outros tipos de falhas além das falhas de disponibilidade;
• Dar capacidade a execução de serviços que não necessariamente possuam o WSDL embu- tido na máquina, dando mais Ćexibilidade à execução de serviços externos;
• Realização de experimentos com aplicações que possuam um maior grau de complexibi- lidade, chegando-se a conclusões mais precisas quanto a eĄciência e eĄcácia da máquina com a inserção dos mecanismos de recuperação;
• Suporte a vários tipos de dados persistentes no ambiente, não limitando-se apenas a um ambiente de variáveis inteiras;
• Permitir a descrição e atribuição de valores distintos de TE e NM T para serviços, tentando evitar problemas relativos ao paralelismo na execução de serviços;
Apesar da simplicidade dos métodos de recuperação de falhas abordados, acreditamos que nossa proposta contribui como esforço inicial para a geração de composições de serviços mais robustas em PEWS. Mesmo em casos onde houve aumento no tempo global de execução das composições, os mecanismos propostos permitiram a conclusão bem sucedida da aplicação mesmo diante das falhas simuladas.
107
Referências
[1] http://www.sinĄc.pt/SinĄcNewsletter/sinĄc/Newsletter43/Dossier2.html, 2012. Citado na página25.
[2] S. Andler. Predicate path expressions. In Proceedings of the 6th ACM SIGACT-SIGPLAN
symposium on Principles of programming languages, pages 226Ű236. ACM, 1979. Citado
na página33.
[3] A. Assaf, A. A. Intalio, S. A. Intalio, S. Fordin, W. J. Sap, K. Kawaguchi, D. Orchard, et al. Web service choreography interface 1.0. .., 2002. Citado na página24.
[4] C. Ba, M. Carrero, M. H. Ferrari, and M. Musicante. Pews: A new language for building web service interfaces. Journal of Universal Computer Science, 11(7):1215Ű1233, 2005. Citado 5 vezes nas páginas 24,33,34,35e 36.
[5] L. Baresi, C. Ghezzi, and S. Guinea. Towards self-healing composition of services. In
Contributions to ubiquitous computing, pages 27Ű46. Springer, 2007. Citado 6 vezes nas
páginas17,29,32,47,48 e 124.
[6] D. Box, D. Ehnebuske, G. Kakivaya, A. Layman, N. Mendelsohn, H. F. Nielsen, S. Thatte, and D. Winer. Simple object access protocol (soap) 1.1, 2000. Citado na página23. [7] F. Budinsky. Eclipse modeling framework: a developerŠs guide. Addison-Wesley Professional,
2004. Citado na página78.
[8] D. A. d. S. Carvalho. Uma máquina de redução de grafos para serviços web. Mestrado, DIMAP, Centro de Ciencias Exatas e da Terra, UFRN, 2012. Citado 6 vezes nas páginas
18,19,36,37,42 e 78.
[9] W. Chen, Y. Xu, B. Peng, and W. Sun. Dynamic monitor based service recovery for composite service in manets. In Communication Technology, 2008. ICCT 2008. 11th IEEE
International Conference on, pages 557Ű560. IEEE, 2008. Nenhuma citação no texto.
[10] N. Curbera and Weerawarama. Web services: Why and how. IBM Research Center, 2001. Citado 2 vezes nas páginas17 e 24.
[11] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, and T. Berners-Lee. Hypertext transfer protocolŰhttp/1.1, 1999. Citado na página23.
[12] T. M. Fruchterman and E. M. Reingold. Graph drawing by force-directed placement.
Software: Practice and experience, 21(11):1129Ű1164, 1991. Citado na página83.
[13] E. R. Gansner. Drawing graphs with graphviz. Technical report, Technical report, AT&T Bell Laboratories, Murray, 2009. Citado 3 vezes nas páginas18,67 e83.
[14] E. R. Gansner, Y. Koren, and S. North. Graph drawing by stress majorization. In Graph
Drawing, pages 239Ű250. Springer, 2005. Citado na página83.
[15] Y. Hu. Eicient, high-quality force-directed graph drawing. Mathematica Journal, 10(1):37Ű 71, 2005. Citado na página83.
[16] M. P. Jones. jacc: just another compiler compiler for java a reference manual and user guide, 2004. Citado na página78.
[17] M. Karray, C. Ghedira, and Z. Maamar. Towards a self-healing approach to sustain web services reliability. In Advanced Information Networking and Applications (WAINA), 2011
IEEE Workshops of International Conference on, pages 267Ű272. IEEE, 2011. Citado 3
vezes nas páginas17,29 e 123.
[18] R. Khalaf, N. Mukhi, and S. Weerawarana. Service-oriented composition in bpel4ws. WWW
(Alternate Paper Tracks), 2003. Citado 2 vezes nas páginas 24e 29.
[19] R. B. Kieburtz. The g-machine: A fast, graph-reduction evaluator. In Functional Program-
ming Languages and Computer Architecture, pages 400Ű413. Springer, 1985. Citado na
página 36.
[20] H. Kreger et al. Web services conceptual architecture (wsca 1.0). IBM Software Group, 5:6Ű7, 2001. Citado 5 vezes nas páginas 17,21,22,23 e24.
[21] P. A. Lee and T. Anderson. Fault tolerance principles and practice, volume 3 of dependable computing and fault-tolerant systems, 1990. Citado na página26.
[22] T. Murata. Petri nets: Properties, analysis and applications. Proceedings of the IEEE, 77(4):541Ű580, 1989. Citado na página29.
[23] E. Newcomer. Understanding Web Services: XML, Wsdl, Soap, and UDDI. Addison-Wesley Professional, 2002. Citado 2 vezes nas páginas22 e24.
[24] C. Ouyang, E. Verbeek, W. M. van der Aalst, S. Breutel, M. Dumas, and A. H. ter Hofstede. Wofbpel: A tool for automated analysis of bpel processes. In Service-Oriented Computing-
ICSOC 2005, pages 484Ű489. Springer, 2005. Citado na página 29.
[25] M. P. Papazoglou. Service-oriented computing: Concepts, characteristics and directions. In Web Information Systems Engineering, 2003. WISE 2003. Proceedings of the Fourth
International Conference on, pages 3Ű12. IEEE, 2003. Citado na página21.
[26] M. P. Papazoglou, P. Traverso, S. Dustdar, and F. Leymann. Service-oriented computing: State of the art and research challenges. Computer, 1(11):38Ű45, 2007. Citado na página
17.
[27] M. P. Papazoglou and W.-J. Van Den Heuvel. Service oriented architectures: approaches, technologies and research issues. The VLDB journal, 16(3):389Ű415, 2007. Citado na página 21.
Referências 109
[28] C. Peltz. Web services orchestration and choreography. Computer, 36(10):46Ű52, 2003. Citado na página25.
[29] J. Postel. Simple mail transfer protocol. Information Sciences, 1982. Citado na página23. [30] J. Postel and J. Reynolds. File transfer protocol. 1985. Citado na página 23.
[31] J. Rao and X. Su. A survey of automated web service composition methods. In Semantic
Web Services and Web Process Composition, pages 43Ű54. Springer, 2005. Citado na página
36.
[32] H. Saboohi and S. A. Kareem. Requirements of a recovery solution for failure of composite web services. In International Journal of Web and Semantic Technology (IJWesT). IEEE, 2012. Citado 2 vezes nas páginas26 e 33.
[33] A. W. Scheer. ARIS: business process modeling. Springer, 2000. Citado na página 24. [34] J. Simmonds, S. Ben-David, and M. Chechik. Guided recovery for web service applications.
In Proceedings of the eighteenth ACM SIGSOFT international symposium on Foundations
of software engineering, pages 247Ű256. ACM, 2010. Nenhuma citação no texto.
[35] J. Simmonds, S. Ben-David, and M. Chechik. Monitoring and recovery of web service applications. In The smart internet, pages 250Ű288. Springer, 2010. Citado 3 vezes nas páginas17,29 e 123.
[36] J. M. Six and I. G. Tollis. Circular drawings of biconnected graphs. In Algorithm Engine-
ering and Experimentation, pages 57Ű73. Springer, 1999. Citado na página83.
[37] J. Steyn. Approaches to failure and recovery in service composition, 2006. Citado 4 vezes nas páginas17,26,28 e33.
[38] K. Sugiyama, S. Tagawa, and M. Toda. Methods for visual understanding of hierarchical system structures. Systems, Man and Cybernetics, IEEE Transactions on, 11(2):109Ű125, 1981. Citado na página83.
[39] F. Tartanoglu, V. Issarny, A. Romanovsky, and N. Levy. Dependability in the web services architecture. In Architecting dependable systems, pages 90Ű109. Springer, 2003. Citado 2 vezes nas páginas27 e28.
[40] R. Vaculin and K. Sycara. Specifying and monitoring composite events for semantic web services. In Web Services, 2007. ECOWSŠ07. Fifth European Conference on, pages 87Ű96. IEEE, 2007. Nenhuma citação no texto.
[41] R. Vaculín, K. Wiesner, and K. Sycara. Exception handling and recovery of semantic web services. In Networking and Services, 2008. ICNS 2008. Fourth International Conference
on, pages 217Ű222. IEEE, 2008. Citado 4 vezes nas páginas17,29,30 e124.
[42] M. Van Steen. Distributed systems principles and paradigms. Network, 4:20, 2004. Citado na página27.
[43] K. Wiesner, R. Vaculín, M. Kollingbaum, and K. Sycara. Recovery mechanisms for se- mantic web services. In Distributed Applications and Interoperable Systems, pages 100Ű105. Springer, 2008. Citado 5 vezes nas páginas17,29,30,31e 123.
[44] T. Yu and K.-J. Lin. Adaptive algorithms for Ąnding replacement services in autonomic distributed business processes. In Autonomous Decentralized Systems, 2005. ISADS 2005.
111
APÊNDICE A Ű Código do arquivo
Pews.jacc
%{ package pews.parser; import pews.main.Main; import pews.grafos.*; import pews.maquina.Maquina; import pews.maquina.TipoToken; %} %semantic Token %token ‘+’ ‘-’ ‘*’ ‘/’ ‘(’ ‘)’ ‘[’ ‘]’ ‘;’ ‘,’ ‘?’ ‘<’ ‘>’ ‘=’ ‘.’ ‘%’ ‘@’ ‘{’ ‘}’ UNFOLDING UNFOLD PARALELO MAIORIGUAL MENORIGUAL IGUALIGUAL AND OR NOT INTEGER IDENTIFIER IF TEMPORESPOSTA STRING%left OR %left AND
%left IGUALIGUAL
%left MAIORIGUAL MENORIGUAL ‘<’ ‘>’ ‘;’
%left ‘+’ ‘-’ PARALELO ‘?’ ‘=’ ‘.’ UNFOLD IF ‘@’ ‘%’ TEMPORESPOSTA %left ‘*’ ‘/’
%left ‘(’ ‘)’
%right NOT UNFOLDING
%%
prog : prog ’?’ P {this.maquina = new Maquina($3);}
| TEMPORESPOSTA ‘(’ INTEGER ‘,’ INTEGER ‘)’ P {this.maquina = new Maquina($9,$3,$5);} | P {this.maquina = new Maquina($1);}
;
P : ‘[’ E ‘]’ P ‘+’ ‘[’ E ‘]’ P { $$ = new Grafo($2, $4, $7, $9); } | IF ‘[’ E ‘]’ P { $$ = new Grafo($3, $5); }
| P ‘;’ P { $$ = new Grafo($1, $3, "SEQFORTE"); } | P ‘.’ P { $$ = new Grafo($1, $3, "SEQFRACA"); } | P PARALELO P { $$ = new Grafo($1, $3, "PARALELO"); } | UNFOLDING P { $$ = new Grafo($2); }
| UNFOLD { $$ = new Grafo("unfold"); } | ‘(’ P ‘)’ { $$ = $2; }
| IDENTIFIER ‘(’ E ‘,’ IDENTIFIER ‘)’ { $$ = new Grafo($1, $3, $5, "CHAMADA"); } | ‘@’ IDENTIFIER ‘(’ E ‘,’ IDENTIFIER ‘)’ SAlt { $$ = new Grafo($2, $4,
| ‘{’ P CAlt { $$ = new Grafo ($2, $3, "PILHA SUBCOMPOSICOES"); } ;
SAlt : ‘%’ IDENTIFIER ‘(’ E ‘,’ IDENTIFIER ‘)’ SAlt { $$ = new Grafo($2, $4, $6, $8, "ALTERNATIVO"); } | ‘@’ { $$ = new Grafo (); }
;
CAlt : ‘%’ P CAlt { $$ = new Grafo ($2, $3, "SUBCOMPOSICAO ALTERNATIVA"); } | ‘}’ { $$ = new Grafo (); }
;
E : E ‘;’ E { $$ = new Expressao ($1, $3);}
| E ‘+’ E { $$ = new Expressao ($1, $3, Operador.SOMA, TipoToken.EXPRESSAO);} | E ‘-’ E { $$ = new Expressao ($1, $3, Operador.SUB, TipoToken.EXPRESSAO);} | E ‘*’ E { $$ = new Expressao ($1, $3, Operador.MULT, TipoToken.EXPRESSAO);} | E ‘/’ E { $$ = new Expressao ($1, $3, Operador.DIV, TipoToken.EXPRESSAO);} | E ‘<’ E { $$ = new Expressao ($1, $3, Operador.MENOR, TipoToken.EXPRESSAO);} | E ‘>’ E { $$ = new Expressao ($1, $3, Operador.MAIOR, TipoToken.EXPRESSAO);}
| E MAIORIGUAL E { $$ = new Expressao ($1, $3, Operador.MAIORIGUAL, TipoToken.EXPRESSAO);} | E MENORIGUAL E { $$ = new Expressao ($1, $3, Operador.MENORIGUAL, TipoToken.EXPRESSAO);} | E AND E { $$ = new Expressao ($1, $3, Operador.AND, TipoToken.EXPRESSAO);}
| E OR E { $$ = new Expressao ($1, $3, Operador.OR, TipoToken.EXPRESSAO);} | NOT E { $$ = new Expressao ($2, Operador.NOT, TipoToken.EXPRESSAO);} | ‘(’ E ‘)’ { $$ = $2; }
| IDENTIFIER { $$ = new Expressao ($1, TipoToken.IDENTIFICADOR); } | INTEGER { $$ = new Expressao ($1, TipoToken.INTEGER); }
| STRING { $$ = new Expressao ($1, TipoToken.STRING); } ;
%%
private PewsLexer lexer; private Maquina maquina;
public PewsParser(PewsLexer lexer) { this.lexer = lexer;
};
private void yyerror(String msg) {
Main.error(yyerrno<0 ? msg : yyerrmsgs[yyerrno]); };
113
APÊNDICE B Ű Uso do GraphViz em
PEWS-AM
A linguagem dot, pertencente ao GraphViz, tem a capacidade de desenhar grafos direcionados. Suas características incluem: layout para a desenho de nós, bordas, rótulos de borda, registros, estruturas de dados, cluster e uma linguagem de arquivos subjacente para ferramentas de gráĄcos orientados a streams.
O construtor digraph G indica a construção de grafos direcionados, onde G é o nome dado a este grafo. O padrão estrutural do GraphViz mostra os grafos de forma vertical. Para que vizualizamos os mesmos de forma horizontal usamos o atributo rankdir=LR, em alusão à left-right. Utilizamos também os chamados clusters). Na máquina de redução estendida, temos dois tipos de vértices compostos, sendo eles as pilhas de chamadas e as pilhas de subcomposições. Podemos necessitar ligar arestas de controle a estas estruturas, que no GraphViz não serão nós, e sim clusters. Dessa forma, precisamos explicitar que iremos permitir a ligação entre vértices e estruturas. Isso é feito setando o parâmetro compound=true. Então, visto estes parâmetros, temos a seguinte situação inicial na construção do arquivo para geração das Ąguras:
Digraph G {
rankdir=LR; compound=true; ...
}
Dentro deste construtor, podemos descrever os vértices e as ligações entre eles. Por exemplo, queremos construir dois vértices e criar uma aresta entre ambos. Isso pode ser feito de duas formas: (i) escrevendo primeiramente a identiĄcação dos vértices e depois as ligações, ou (ii) realizar esses dois passos de uma vez. Se queremos criar dois vértices chamados entrada e saida e uma ligação entre eles, podemos fazer isso, utilizando os passos acima, da maneira mostrada na Ągura 32:
Figura 32 Ű Exemplo de entrada e saída de um código no GraphViz