Suporte á análise de compatibilidade comportamental e estrutural entre componentes no ambiente SEA
130
0
0
Texto
(2) Suporte a` An´alise de Compatibilidade Comportamental e Estrutural entre Componentes no Ambiente SEA. Roberto Silvino da Cunha. Esta Dissertac¸a˜ o foi julgada adequada para a obtenc¸a˜ o do t´ıtulo de Mestre em Ciˆencia da Computac¸a˜ o, a´ rea de concentrac¸a˜ o Sistemas de Computac¸a˜ o e aprovada em sua forma final pelo Programa de P´os-Graduac¸a˜ o em Ciˆencia da Computac¸a˜ o.. Prof. Raul Sidnei Wazlawick, Dr. Banca Examinadora. Prof. Ricardo Pereira e Silva, Dr. (Orientador). Prof. Marcelo T. C. da Costa, Dr.. Prof. Frank A. Siqueira, Dr.. Prof. Vit´orio B. Mazzola, Dr..
(3) iii. ”A perseveranc¸a austera, dura, cont´ınua, pode ser empregada pelos mais humildes entre n´os e raramente deixa de atingir seu fim, pois seu poder silencioso cresce, irresist´ıvelmente, com o tempo.” Johann Wolfgang Von Goethe.
(4) iv. Dedico esta dissertac¸a˜ o a Jorge, Carminha e Tati, os amores de minha vida..
(5) v. Agradecimentos. Agradec¸o a Deus, por ser o maior respons´avel pela evoluc¸a˜ o desta pesquisa. Ao meu orientador, Professor Ricardo Pereira e Silva, por estar sempre presente e com disposic¸a˜ o para transmitir o seu conhecimento. Muito aprendi com nossas conversas. Aos meus pais, Jorge e Carminha, a quem devo tudo o que sou. ` minha esposa Tatiana; seu apoio foi fundamental. A ` minha amiga Glady, por toda a motivac¸a˜ o e apoio durante os momentos dif´ıceis, A e ao Andr´e, pelo companheirismo. Ao laborat´orio Labsoft/Motorola pelo suporte a` realizac¸a˜ o deste trabalho. Aos meus amigos do Labsoft, em especial a` Pricilla, pelo seu apoio. ` toda a minha fam´ılia que, de uma forma ou de outra, ao longo deste trabalho, A tiveram afetadas suas rotinas di´arias, em especial o Rubens, a Karla e o Gustavo. ` Universidade Federal de Santa Catarina, por propiciar este mestrado, disponibiA lizando sua estrutura. Em particular aos professores e funcion´arios do Departamento de Inform´atica e Estat´ıstica, todos muito prestativos..
(6) vi. Conteudo ´. Gloss´ario. 10. Lista de Figuras. 11. Lista de Tabelas. 14. Resumo. 15. Abstract. 16. 1. Introduc¸a˜ o. 17. 1.1. Vis˜ao Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 18. 1.2. Motivac¸a˜ o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 19. 1.3. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 20. 1.3.1. Objetivo Geral . . . . . . . . . . . . . . . . . . . . . . . . . . .. 20. 1.3.2. Objetivos Espec´ıficos . . . . . . . . . . . . . . . . . . . . . . . .. 21. Apresentac¸a˜ o do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . .. 21. 1.4 2. 3. Desenvolvimento de Software Baseado em Componentes. 23. 2.1. Definic¸a˜ o de Componentes . . . . . . . . . . . . . . . . . . . . . . . . .. 23. 2.2. Estrutura de Componentes . . . . . . . . . . . . . . . . . . . . . . . . .. 24. 2.3. Perfis de Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 25. 2.4. Mecanismos de Conex˜ao de Componentes . . . . . . . . . . . . . . . . .. 27. 2.5. Mecanismos de Descric¸a˜ o de Componentes . . . . . . . . . . . . . . . .. 27. 2.6. Adaptac¸a˜ o de Componentes . . . . . . . . . . . . . . . . . . . . . . . .. 28. Compatibilidade entre componentes. 29. 3.1. Compatibilidade Estrutural . . . . . . . . . . . . . . . . . . . . . . . . .. 29. 3.2. Compatibilidade Comportamental . . . . . . . . . . . . . . . . . . . . .. 30. 3.3. Compatibilidade Funcional . . . . . . . . . . . . . . . . . . . . . . . . .. 32.
(7) vii. 3.4 4. Arquitetura de Componentes . . . . . . . . . . . . . . . . . . . . . . . .. Redes de Petri. 34. 4.1. Definic¸a˜ o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 34. 4.2. Comportamento Dinˆamico . . . . . . . . . . . . . . . . . . . . . . . . .. 35. 4.3. Definic¸a˜ o Formal de uma Rede de Petri . . . . . . . . . . . . . . . . . .. 36. 4.3.1. Rede de Petri . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 36. 4.3.2. Marcac¸a˜ o da Rede . . . . . . . . . . . . . . . . . . . . . . . . .. 37. 4.3.3. Grafo Associado e Notac¸a˜ o Matricial . . . . . . . . . . . . . . .. 38. 4.3.4. Rede de Petri Pura . . . . . . . . . . . . . . . . . . . . . . . . .. 39. 4.3.5. Transic¸a˜ o Sensibilizada . . . . . . . . . . . . . . . . . . . . . . .. 39. 4.3.6. Disparo de uma Transic¸a˜ o . . . . . . . . . . . . . . . . . . . . .. 40. 4.3.7. Conflito e Paralelismo . . . . . . . . . . . . . . . . . . . . . . .. 40. 4.3.8. Conjunto das Marcac¸o˜ es Acess´ıveis . . . . . . . . . . . . . . . .. 41. Propriedades de Redes de Petri . . . . . . . . . . . . . . . . . . . . . . .. 42. 4.4.1. Lugar k-Limitado e Bin´ario . . . . . . . . . . . . . . . . . . . .. 42. 4.4.2. Rede k-Limitada e Rede Bin´aria . . . . . . . . . . . . . . . . . .. 42. 4.4.3. Rede Marcada Viva . . . . . . . . . . . . . . . . . . . . . . . . .. 43. 4.4.4. Rede Reinicializ´avel . . . . . . . . . . . . . . . . . . . . . . . .. 43. T´ecnicas de An´alise da Rede de Petri . . . . . . . . . . . . . . . . . . . .. 43. An´alise por Enumerac¸a˜ o das Marcac¸o˜ es . . . . . . . . . . . . . . ´ 4.5.1.1 Arvore de Cobertura . . . . . . . . . . . . . . . . . . . ´ 4.5.1.2 Limitac¸o˜ es da Arvore de Cobertura na An´alise das Re-. 44. des de Petri . . . . . . . . . . . . . . . . . . . . . . .. 45. An´alise Estrutural da Rede de Petri . . . . . . . . . . . . . . . .. 45. 4.5.2.1. Componentes Conservativos e Invariantes de Lugar . .. 46. 4.5.2.2. Componentes Repetitivos e Invariantes de Transic¸a˜ o . .. 46. Relac¸a˜ o das Propriedades com o Comportamento dos Componentes . . .. 47. 4.4. 4.5. 4.5.1. 4.5.2. 4.6 5. 32. 44. Ambiente de Desenvolvimento de Software SEA e o Framework Ocean. 49. 5.1. Ambiente de Desenvolvimento de Software SEA . . . . . . . . . . . . .. 50. 5.1.1. A Estrutura de Especificac¸o˜ es no Ambiente SEA . . . . . . . . .. 52. 5.1.2. Interligac¸a˜ o de Elementos de Especificac¸a˜ o do Framework OCEAN 53. 5.1.3. Estrutura Semˆantica de Especificac¸o˜ es no Ambiente SEA . . . . .. 53. 5.1.4. Flexibilidade Funcional do Framework OCEAN . . . . . . . . .. 54.
(8) viii. 5.1.5. 5.2. 5.3. SEA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 56. 5.1.5.1. Especificac¸a˜ o da Interface de um Componente . . . . .. 56. 5.1.5.2. Especificac¸a˜ o de Componente . . . . . . . . . . . . . .. 59. 5.1.5.3. Uso de Componente . . . . . . . . . . . . . . . . . . .. 61. Frameworks Orientados a Objetos . . . . . . . . . . . . . . . . . . . . .. 62. 5.2.1. Definic¸a˜ o de Frameworks Orientados a Objetos . . . . . . . . . .. 63. 5.2.2. Caracter´ısticas de Frameworks . . . . . . . . . . . . . . . . . . .. 67. 5.2.3. Classificac¸a˜ o de Frameworks . . . . . . . . . . . . . . . . . . . .. 68. 5.2.4. Vantagens e Desvantagens do Uso de Frameworks . . . . . . . .. 69. 5.2.5. Desenvolvimento de Aplicac¸o˜ es Sobre Frameworks . . . . . . . .. 69. Framework Ocean . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 70. Suporte a` Criac¸a˜ o de Estruturas de Documentos . . . . . . . . . .. 71. 5.3.1.1. Estrutura de Documentos a Partir do OCEAN . . . . .. 72. 5.3.1.2. Visualizac¸a˜ o de Elementos de Especificac¸a˜ o . . . . . .. 73. 5.3.2. Suporte a` Edic¸a˜ o Semˆantica de Especificac¸o˜ es . . . . . . . . . .. 74. 5.3.3. Suporte a` Criac¸a˜ o e Uso de Ferramentas . . . . . . . . . . . . . .. 74. 5.3.1. 6. 7. Suporte ao Desenvolvimento e Uso de Componentes no Ambiente. Estado da Arte. 76. 6.1. Introduc¸a˜ o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 76. 6.2. Pesquisas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 77. 6.3. Conclus˜ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 81. Arquitetura de Componentes no Ambiente de Desenvolvimento de Software SEA 7.1. 83 A Especificac¸a˜ o de Arquitetura de Componentes no Ambiente SEA . . . 7.1.1. 7.2. 84. A Estrutura da Especificac¸a˜ o de Arquitetura de Componentes no Ambiente SEA . . . . . . . . . . . . . . . . . . . . . . . . . . .. 84. 7.1.2. O Editor de Arquitetura de Componentes no Ambiente SEA . . .. 86. 7.1.3. Janelas de Edic¸a˜ o dos Conceitos da Arquitetura de Componentes .. 89. 7.1.4. Restric¸o˜ es Semˆanticas do Modelo no Editor . . . . . . . . . . . .. 89. An´alise da Especificac¸a˜ o da Arquitetura de Componentes . . . . . . . . .. 92. 7.2.1. An´alise Estrutural . . . . . . . . . . . . . . . . . . . . . . . . . .. 93. 7.2.2. An´alise Comportamental . . . . . . . . . . . . . . . . . . . . . . 104 7.2.2.1. Rede de Petri Resultante . . . . . . . . . . . . . . . . . 104.
(9) ix. 7.2.2.2 7.2.3 7.3 8. Verificac¸a˜ o Comportamental . . . . . . . . . . . . . . 108. Estudo de Caso . . . . . . . . . . . . . . . . . . . . . . . . . . . 113. Conclus˜ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118. Conclus˜oes. 119. 8.1. Resultados Obtidos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119. 8.2. Limitac¸o˜ es . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120. 8.3. Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121. 8.4. Considerac¸o˜ es Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121. Bibliografia. 123. Bibliografia. 127.
(10) 10. Gloss´ario ADL. Architecture Description Language. CASE. Computer-Aided Software Engineering. COM. Component Object Model. CORBA. Common Object Request Broker Architecture. DSBC. Desenvolvimento de Software Baseado em Componentes. OO. Orientado a Objetos. RdP. Redes de Petri. UML. Unified Modeling Language.
(11) 11. Lista de Figuras 2.1. Estrutura de uma Interface . . . . . . . . . . . . . . . . . . . . . . . . .. 24. 2.2. Desenvolvimento de uma aplicac¸a˜ o baseada em componentes. . . . . . .. 26. 3.1. Exemplo de Reuse Contract para a especificac¸a˜ o da conex˜ao de componentes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 31. 4.1. Rede de Petri. Fonte: (CARDOSO; VALLET, 1997) . . . . . . . . . . . .. 35. 4.2. Seq¨ueˆ ncia de disparos em uma rede de Petri. Fonte: (CARDOSO; VALLET, 1997). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 36. 4.3. Rede de Petri. Fonte: (CARDOSO; VALLET, 1997) . . . . . . . . . . . .. 37. 4.4. Disparo de uma Transic¸a˜ o. Fonte: (CARDOSO; VALLET, 1997) . . . . . .. 40. 5.1. Estrutura do ambiente SEA constitu´ıdo a partir do framework OCEAN. Fonte: (SILVA, 2000) . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 5.2. Superclasses do framework OCEAN que definem a estrutura de uma especificac¸a˜ o. Fonte: (SILVA, 2000) . . . . . . . . . . . . . . . . . . . .. 5.3. 52. Tipos de ferramentas de ambiente sob o framework OCEAN. Fonte: (SILVA, 2000) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 5.4. 50. 56. Estrutura de canais e m´etodos de uma interface de componentes. Fonte: (SILVA, 2000) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 57. 5.5. Diagrama de Estrutura de Interface no ambiente SEA . . . . . . . . . . .. 57. 5.6. Rede de Petri no ambiente SEA. Fonte: (SILVA, 2000) . . . . . . . . . . .. 58. 5.7. Estrutura de classes correspondente a` implementac¸a˜ o da especificac¸a˜ o de interface descrita nas figuras 5.5 e 5.6. Fonte: (SILVA, 2000) . . . . . . .. 5.8 5.9. 60. Estrutura de classes correspondente a` implementac¸a˜ o da especificac¸a˜ o de uma interface contendo a classe da rede de Petri. . . . . . . . . . . . . .. 61. Aplicac¸a˜ o desenvolvida totalmente. Fonte: (SILVA, 2000) . . . . . . . . .. 64. 5.10 Aplicac¸a˜ o desenvolvida reutilizando classes de biblioteca. Fonte: (SILVA, 2000) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.11 Aplicac¸a˜ o desenvolvida reutilizando um framework. Fonte:(SILVA, 2000). 64 65.
(12) 12. 5.12 Elementos do desenvolvimento tradicional de aplicac¸o˜ es. Fonte: (SILVA, 2000) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 66. 5.13 Elementos do desenvolvimento de aplicac¸o˜ es baseado em frameworks. Fonte:(SILVA, 2000) . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 67. 5.14 Hierarquia das classes abstratas que definem a estrutura de um documento sob o framework OCEAN. Fonte: (SILVA, 2000) . . . . . . . . . . . . .. 72. 5.15 Estrutura de edic¸a˜ o de elementos de especificac¸a˜ o do framework OCEAN. Fonte: (SILVA, 2000) . . . . . . . . . . . . . . . . . . . . . . .. 73. 5.16 Estrutura de suporte a` produc¸a˜ o de ferramentas do framework OCEAN. Fonte: (SILVA, 2000) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.1. 74. Estrutura da Especificac¸a˜ o de Arquitetura de Componentes no Ambiente SEA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 85. 7.2. Estrutura de Classes do Editor no Ambiente SEA . . . . . . . . . . . . .. 86. 7.3. Editor de Arquitetura de Componente no Ambiente SEA . . . . . . . . .. 87. 7.4. Editor de Arquitetura representando Interface de Componente e Especificac¸a˜ o de Componente . . . . . . . . . . . . . . . . . . . . . . .. 88. 7.5. Editor de Arquitetura representando incompatibilidade estrutural . . . . .. 88. 7.6. Estrutura de Classes das Janelas do Editor . . . . . . . . . . . . . . . . .. 89. 7.7. Dados de identificac¸a˜ o do componente . . . . . . . . . . . . . . . . . . .. 90. 7.8. Lista com o nome das portas do componente . . . . . . . . . . . . . . . .. 91. 7.9. Links com outros elementos de especificac¸a˜ o . . . . . . . . . . . . . . .. 91. 7.10 Estrtura da interface do componente C1 . . . . . . . . . . . . . . . . . .. 96. 7.11 Estrtura da interface do componente C2 . . . . . . . . . . . . . . . . . .. 97. 7.12 Representac¸a˜ o gr´afica da Tela1 referenciada na tabela 7.3 . . . . . . . . .. 97. 7.13 Representac¸a˜ o gr´afica da Tela2 referenciada na tabela 7.3 . . . . . . . . .. 98. 7.14 Variac¸a˜ o da representac¸a˜ o gr´afica da Tela2 referenciada na tabela 7.3 . . .. 98. 7.15 Variac¸a˜ o da representac¸a˜ o gr´afica da Tela3 referenciada na tabela 7.3 . . .. 99. 7.16 Apresentac¸a˜ o dos servic¸os compat´ıveis na tela de identificac¸a˜ o do conector 99 7.17 Exemplo de um relat´orio de verificac¸a˜ o de compatibilidade estrutural . . . 103 7.18 Descric¸a˜ o comportamental de uma arquitetura de componentes. Fonte: (SILVA, 2000) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 7.19 Rede de Petri do Componente1 . . . . . . . . . . . . . . . . . . . . . . . 106 7.20 Rede de Petri do Componente2 . . . . . . . . . . . . . . . . . . . . . . . 106 7.21 Rede de Petri resultante da uni˜ao entre as redes da figura 7.19 e 7.20 . . . 107.
(13) 13. 7.22 Exemplo de uma rede de Petri salva, limitada e n˜ao reinici´avel . . . . . . 108 7.23 Exemplo de uma rede de Petri n˜ao salva . . . . . . . . . . . . . . . . . . 109 7.24 Exemplo de uma rede de Petri n˜ao limitada . . . . . . . . . . . . . . . . 109 7.25 Exemplo de uma rede de Petri reinici´avel . . . . . . . . . . . . . . . . . 111 7.26 Exemplo de um relat´orio de verificac¸a˜ o de compatibilidade comportamental112 7.27 Interface do componente de compatibilizac¸a˜ o . . . . . . . . . . . . . . . 115 7.28 Rede de Petri do componente de compatibilizac¸a˜ o . . . . . . . . . . . . . 115 7.29 Nova arquitetura de componentes com a interface do adaptador . . . . . . 116 7.30 Rede de Petri resultante da nova arquitetura de componentes . . . . . . . 117.
(14) 14. Lista de Tabelas 7.1. Telas de edic¸a˜ o dos conceitos da especificac¸a˜ o da arquitetura . . . . . . .. 90. 7.2. Algoritmo da An´alise Estrutural . . . . . . . . . . . . . . . . . . . . . .. 94. 7.3. Resoluc¸o˜ es da An´alise de Compatibilidade Estrutural . . . . . . . . . . .. 95. 7.4. Telas de Apresentac¸a˜ o da An´alise de Compatibilidade Estrutural . . . . . 100. 7.5. Interpretac¸a˜ o das propriedades da rede de Petri para o contexto de componentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110. 7.6. Dados representativos dos problemas de comportamentais analisados. . . 112.
(15) 15. Resumo. A utilizac¸a˜ o de componentes para o desenvolvimento de sistemas e´ uma abordagem que promove o reuso, tanto de c´odigo quanto de projeto, em um alto n´ıvel de abstrac¸a˜ o. Mas para que o reuso seja vantajoso, isto e´ , exija menos esforc¸o que o desenvolvimento de um novo artefato de software, ent˜ao o componente deve ser descrito de forma que, com o m´ınimo esforc¸o, sua compatibilidade com os outros componentes possa ser avaliada. Com esta avaliac¸a˜ o, poder´a ser tomada a decis˜ao sobre seu uso como est´a, em caso de constatac¸a˜ o da compatibilidade ou, no caso de incompatibilidade, decidir sobre compatibilizac¸a˜ o ou abandono. Este trabalho trata formas de automatizar a an´alise de compatibilidade estrutural e comportamental entre componentes, durante o processo de especificac¸a˜ o de projeto. A id´eia e´ modelar uma arquitetura de componentes, para que se possa visualizar suas conex˜oes, e com isto poder fazer as an´alises necess´arias para garantir a compatibilidade e o perfeito funcionamento desta arquitetura. Na implementac¸a˜ o foi utilizado o ambiente de desenvolvimento SEA, produzido sob o framework OCEAN. Eles permitem que especificac¸o˜ es e ferramentas possam ser desenvolvidas e que trabalhem integradas. Para a verificac¸a˜ o de compatibilidade estrutural s˜ao levantados os tipos de incompatibilidade e as soluc¸o˜ es permitidas dentro do universo de possibilidades da arquitetura da especificac¸a˜ o que se quer verificar. Redes de Petri ordin´arias s˜ao utilizadas para que as an´alises de suas propriedades e suas interpretac¸o˜ es, para o contexto de componentes, possa permitir a automac¸a˜ o da verificac¸a˜ o de compatibilidade comportamental. Ferramentas para as an´alises estruturais e comportamentais foram desenvolvidas e est˜ao integradas ao ambiente SEA, fazendo a leitura de informac¸o˜ es contidas nas especificac¸o˜ es da estrutura de componentes. Com as informac¸o˜ es da estrutura de componentes e as an´alises necess´arias levantadas neste trabalho e´ feita a verificac¸a˜ o automatizada da compatibilidade entre os componentes. Caso haja alguma incompatibilidade, poss´ıveis soluc¸o˜ es s˜ao propostas, ficando a cargo do desenvolvedor escolher, dentre elas, a melhor soluc¸a˜ o..
(16) 16. Abstract. The use of components for the development of systems is an approach that promotes reuse of code and of design, in a high abstraction level. But so that the reuse be advantageous, that is, demand less effort than the development of a new software artifact, then the component should be described so that, with the minimum effort, its compatibility with the other components can be appraised. With this evaluation, the decision can be made on its use how it is, in case of verification of the compatibility or, in the case of incompatibility, to decide on compatibilization or abandonment. This work treats forms of automating the structural and behavioral compatibility analysis among components, during the process of project specification. The idea is to model an architecture of components, so that we can to visualize their connections, and with this to make the analysis necessary to guarantee the compatibility and the perfect operation of this architecture.. The SEA development environment, built under the OCEAN. framework, was used for the implementation. They allow that specifications and tools can be developed and that they work integrated. For the structural compatibility verification the types of incompatibilities and the allowed solutions in the universe of the specification architecture being verified are raised. Ordinary Petri-nets are used so that the analysis of their properties and their interpretations, for the components context, it can allow the automation of the behavioral compatibility verification. Tools for the structural and behavioral analysis were developed and they are integrated into the environment SEA, making the reading of information contained in the specifications of the component structure. With the information of the components structure and the necessary analysis raised in this work is made the verification of the compatibility among the components by automated way. In the case of an incompatibility, possible solutions are proposed, being the developer responsible for choosing the best one among them..
(17) 17. 1. Introduc¸a˜ o. Uma das maiores preocupac¸o˜ es na ind´ustria da inform´atica e´ a necessidade de se criar software de modo mais veloz e a um baixo custo. O termo revoluc¸a˜ o industrial do software, segundo (MARTIN, 1994), tem sido usado para descrever o movimento em direc¸a˜ o a uma era em que software ser˜ao montados de componentes reutiliz´aveis. “Os componentes ser˜ao constru´ıdos de outros componentes e ser˜ao criadas grandes bibliotecas desses componentes. Software, como m´aquinas, ser˜ao constru´ıdos de componentes reutiliz´aveis. Os projetistas n˜ao precisar˜ao conhecer as engrenagens internas dos componentes. Um projetista de um videocassete n˜ao o projetaria transistor a transistor, mas sim a partir de componentes de alto n´ıvel, como um chip que pode conter centenas de milhares de transistores. Da mesma forma, deve haver componentes de software de alto n´ıvel, com algumas centenas de milhares de linhas de c´odigo, projetadas a zero erro.” (MARTIN, 1994). Este trabalho tem seu foco na verificac¸a˜ o de conex˜ao entre componentes, levantando problemas que n˜ao permitam o perfeito funcionamento da uni˜ao dos componentes. E´ implementada uma proposta de especificac¸a˜ o de componentes, criada por (SILVA, 2000), para que, sob esta especificac¸a˜ o de componentes, ferramentas de an´alises e propostas de soluc¸o˜ es possam ser apresentadas ao usu´ario1 , permitindo-lhe escolher opc¸o˜ es de resoluc¸a˜ o. Esta implementac¸a˜ o e´ feita em um ambiente de desenvolvimento de software, o SEA (SILVA, 2000). “A reutilizac¸a˜ o de software, em contraposic¸a˜ o ao desenvolvimento de todas as partes de um sistema, e´ um fator que pode levar ao aumento de qualidade e da produtividade da atividade de desenvolvimento de software. Isto se baseia na perspectiva de que o reuso de artefatos de software, j´a desenvolvidos e depurados, reduza o tempo de desenvolvimento de teste e as possibilidades de introduc¸a˜ o de erros na produc¸a˜ o de novos artefatos.” (SILVA, 2000) 1. Entenda-se por usu´ario quem utiliza o componente para a criac¸a˜ o de artefatos de software..
(18) 18. Para que ocorra a reutilizac¸a˜ o de artefatos de software, e´ imprescind´ıvel que sua produc¸a˜ o seja direcionada a este fim (SILVA, 2000). Inclusive, o tamanho do artefato de software, isto e´ , sua granularidade, influencia o aumento de produtividade em sua reutilizac¸a˜ o.“A granularidade do artefato de software reutilizado e´ um fator relevante em termos de produtividade no desenvolvimento de software”(SILVA, 2000), onde a granularidade do artefato na reutilizac¸a˜ o de software pode ir desde a reutilizac¸a˜ o de algumas linhas de c´odigo, passando pela reutilizac¸a˜ o de objetos, que e´ um n´ıvel granular maior que a reutilizac¸a˜ o de apenas algumas linhas de c´odigo, podendo reutilizar m´etodos e atributos, que s˜ao pequenos m´odulos de reutilizac¸a˜ o. Aumentando a granularidade, isto e´ , o tamanho dos artefatos de software, podese chegar ao reuso de frameworks, que s˜ao “estruturas de classes que constituem implementac¸o˜ es incompletas que, estendidas, permitem produzir diferentes artefatos de software” (SILVA, 2000). Neste caso n˜ao somente os m´odulos (classes) s˜ao reutilizados, mas todas as suas interligac¸o˜ es previamente projetadas. Um maior n´ıvel de granularidade, de artefatos de software, na reutilizac¸a˜ o, pode ser obtido com componentes, onde componente e´ “uma unidade de composic¸a˜ o com interfaces contratualmente especificadas e dependˆencia de contexto expl´ıcitas”(SZYPERSKI et al., 1996). Com o reuso de alta granularidade de frameworks e componentes, pode-se. enfatizar o reaproveitamento, n˜ao s´o do c´odigo, mas tamb´em do projeto.. 1.1. Vis˜ao Geral Em virtude do aumento constante da complexidade de software, e´ fundamental a. busca por soluc¸o˜ es mais eficientes para a diminuic¸a˜ o de esforc¸os e dos custos necess´arios a este desenvolvimento. H´a mais de quatro d´ecadas que t´ecnicas e tecnologias est˜ao sendo desenvolvidas com a promessa de diminuir os custos do desenvolvimento de software (MCILROY, 1969), por meio de uma eficiente reutilizac¸a˜ o dos recursos j´a desenvolvidos e conseq¨uente aproveitamento das soluc¸o˜ es j´a estabelecidas. Com o desenvolvimento baseado em componentes, pode-se utilizar diversas destas tecnologias operando sinergicamente em sua constituic¸a˜ o, como orientac¸a˜ o a objetos, lin-.
(19) 19. guagens de quarta gerac¸a˜ o 2 , ferramentas CASE (Computer-Aided Software Engineering) entre outras, tanto para o desenvolvimento de um componente quanto para a ligac¸a˜ o entre componentes na montagem de um sistema. O trabalho em conjunto destas tecnologias simplifica a montagem final dos sistemas, pois haver´a apenas a montagem dos componentes adquiridos de terceiros e n˜ao o seu desenvolvimento. A tendˆencia e´ que o acesso ao c´odigo seja eliminado, o que cria um problema, a compreens˜ao do funcionamento dos componentes. E e´ justamente neste ponto que este trabalho e´ engajado, em buscar soluc¸o˜ es que auxiliem na compreens˜ao do funcionamento dos componentes sem que haja acesso direto aos seus c´odigos.. 1.2. Motivac¸a˜ o A documentac¸a˜ o textual dos componentes de software e´ um caminho para o aux´ılio. a` sua compreens˜ao, mas h´a a falta de formalismo neste tipo de aux´ılio, o que causa a impossibilidade de verificac¸o˜ es automatizadas. O formalismo pode ser obtido de diversas maneiras. O que se deve ter em mente e´ que o formalismo a ser usado dever´a ser de f´acil3 utilizac¸a˜ o. Desta forma n˜ao cair´a em desuso e assim pode ser aplicado em grandes proporc¸o˜ es, que e´ o caso no desenvolvimento de software. Outro fator a ser considerado na utilizac¸a˜ o de componentes e´ que dificilmente poder˜ao ser usados como foram concebidos. Provavelmente, eles passar˜ao por um processo de adaptac¸a˜ o para terem condic¸o˜ es de se conectarem (BOSCH et al., 1997). Mas somente nos pontos de incompatibilidade entre os componentes dever˜ao sofrer estas adaptac¸o˜ es. Encontrar estes pontos de incompatibilidade e a forma de resolvˆe-los pode ser simples em pequenos sistemas, mas, em sistemas com dezenas ou centenas de componentes, se torna um processo exaustivo, onde uma falha humana poder´a estar mais presente. 2. S˜ao linguagens com estrutura mais pr´oxima da linguagem humana do que as linguagens de programac¸a˜ o de alto n´ıvel, como Basic, COBOL, C, Pascal, Delphi. Um bom exemplo de linguagem de quarta gerac¸a˜ o e´ o SQL (Structured Query Language) e o PL/SQL (Procedural Language). 3 F´acil, neste contexto, seria a utilizac¸a˜ o de m´etodos formais de validac¸a˜ o, por pessoas sem o conhecimento pr´evio dos mesmos, atrav´es, por exemplo, de modelos gr´aficos.
(20) 20. 1.3. Objetivos As tecnologias existentes no mercado, tais como COM, CORBA, Java BEANS,. contemplam somente a validac¸a˜ o estrutural da interconex˜ao de componentes, fazendo a verificac¸a˜ o de existˆencia do nome dos m´etodos, tanto no fornecedor, quanto no receptor, bem como seus parˆametros. Estudos sobre especificac¸o˜ es e verificac¸o˜ es comportamentais j´a foram feitos baseados em formalismos matem´aticos, como (CANAL et al., 1997). (SILVA, 2000) exp˜oe que, “por se tratar de uma notac¸a˜ o de baixo n´ıvel, torna-se dif´ıcil de aplic´a-la para descrever sistemas complexos”. Uma poss´ıvel soluc¸a˜ o para este problema poderia ser a utilizac¸a˜ o de reuse contracts (HONDT; LUCAS; STEYAERT, 1997), mas (SILVA, 2000) apresenta problemas na adoc¸a˜ o desta notac¸a˜ o, pois possui pouca formalidade, o que acarreta deficiˆencias, como a impossibilidade de verificac¸o˜ es de propriedades como deadlock,isto e´ , o travamento do programa, o que e´ cr´ıtico na execuc¸a˜ o de um sistema, dentre outras an´alises apresentadas nesta pesquisa.. 1.3.1. Objetivo Geral. O objetivo deste trabalho e´ o de buscar formas de automatizar a an´alise estrutural e comportamental da integrac¸a˜ o entre componentes durante o processo de especificac¸a˜ o, isso no ambiente de desenvolvimento SEA. Para a especificac¸a˜ o deste trabalho e´ utilizada a linguagem UML atrav´es do ambiente de desenvolvimento SEA (SILVA, 2000). Os componentes s˜ao vistos sob a o´ tica de sua utilizac¸a˜ o, contemplando sua interligac¸a˜ o. A parte de desenvolvimento de componentes n˜ao e´ abordada. Para a validac¸a˜ o dos objetivos ser´a apresentado um caso de uso. Este far´a um ciclo desde a especificac¸a˜ o singular de cada componente, onde incompatibilidades ser˜ao inseridas, passando pela gerac¸a˜ o das an´alises de integrac¸a˜ o destes componentes proposta neste trabalho, fornecendo subs´ıdios ao trabalho de adaptac¸a˜ o (SARTORI, 2005)dos componentes. E, como conclus˜ao, a validac¸a˜ o das implementac¸o˜ es e an´alises, onde o comportamento inicial do sistema deve ser mantido ap´os sua adaptac¸a˜ o e nenhum dos problemas encontrados anteriormente deve ser reincidente..
(21) 21. 1.3.2. Objetivos Espec´ıficos. Para que se possa automatizar a an´alise de componentes, alguns objetivos desta pesquisa devem ser destacados: • criac¸a˜ o de um editor para a especificac¸a˜ o da arquitetura de componentes no Ambiente SEA; • implementac¸a˜ o de uma ferramenta para a verificac¸a˜ o estrutural da conex˜ao entre componentes; • implementac¸a˜ o da persistˆencia de informac¸o˜ es dos problemas estruturais encontrados pela ferramenta de an´alise, com poss´ıveis soluc¸o˜ es, para que possam ser adaptados futuramente; • implementac¸a˜ o da rede de Petri resultante(SILVA, 2000) da uni˜ao entre as diversas redes de Petri que comp˜oe o sistema, para que as an´alises comportamentais do sistema possam ser realizadas; • identificac¸a˜ o de quais an´alises de rede de Petri podem ser aplicadas ao contexto de componentes; • automac¸a˜ o da soluc¸a˜ o de an´alise de componentes, como proposto em (SILVA, 2000), implementando uma ferramenta para a verificac¸a˜ o comportamental da conex˜ao entre componentes, aplicando as an´alises identificadas como u´ teis ao contexto de componentes.. 1.4. Apresentac¸a˜ o do Trabalho No cap´ıtulo 2 s˜ao apresentados os conceitos, estrutura e formas de trabalho sobre. Desenvolvimento de Software Baseado em Componentes (DSBC). Ser´a vista uma breve apresentac¸a˜ o sobre as tecnologias de componentes existentes no mercado, sendo que este trabalho n˜ao se at´em a uma tecnologia ou a um tipo espec´ıfico de componente. Os componentes, depois de desenvolvidos, s˜ao ligados entre si para a constituic¸a˜ o de um sistema. No cap´ıtulo 3 s˜ao vistos quais tipos de compatibilidades os componentes devem ter, para poderem ser interligados.. Mas as formas de validac¸a˜ o destas.
(22) 22. compatibilidades nem sempre podem ser feitas automaticamente, pois ainda n˜ao existe um padr˜ao definindo um formalismo para sua especificac¸a˜ o. A rede de Petri, que e´ apresentada no cap´ıtulo 4, serve justamente para formalizar esta especificac¸a˜ o e fornece subs´ıdios para que an´alises possam ser feitas sobre a modelagem de componentes. Para que um componente possa conter a especificac¸a˜ o de uma rede de Petri, um editor e algumas ferramentas foram desenvolvidos sobre um framework, o OCEAN, e sua aplicac¸a˜ o, o SEA, um ambiente de desenvolvimento de software. No cap´ıtulo 5 ser´a visto o que s˜ao frameworks e como eles auxiliam no desenvolvimento de software, juntamente com uma vis˜ao sobre o framework OCEAN e o ambiente de desenvolvimento SEA. Um levantamento sobre as tecnologias tratadas neste trabalho e´ apresentado no cap´ıtulo 6 sobre o estado da arte. O cap´ıtulo 7 apresenta o editor criado para representar a modelagem da conex˜ao entre componentes. Com a arquitetura de uma aplicac¸a˜ o especificada h´a como realizar an´alises de compatibilidade estrutural e comportamental. Estas an´alises apresentam, de forma automatizada, conjuntamente, problemas e suas poss´ıveis soluc¸o˜ es. Os dados obtidos destas an´alises s˜ao gerados em arquivo, para o usu´ario do ambiente poder visualiz´a-los e, tamb´em, armazenados na estrutura da especificac¸a˜ o da arquitetura de componentes, criada para que possa ser utilizada posteriormente por outras ferramentas. As conclus˜oes da dissertac¸a˜ o e as perspectivas de trabalhos futuros encontram-se descritas no cap´ıtulo 8.
(23) 23. 2. 2.1. Desenvolvimento de Software Baseado em Componentes. Definic¸a˜ o de Componentes “Minha tese e´ que a ind´ustria de software est´a debilmente fundada, em parte por causa da ausˆencia de uma sub-ind´ustria de componentes de software... A ind´ustria de componentes poderia ser imensamente bem sucedida”. (MCILROY, 1969). H´a mais de 3 d´ecadas existe a preocupac¸a˜ o de se construir aplicac¸o˜ es a partir da composic¸a˜ o de artefatos de software. McIlroy, em 1968, durante a “crise do software”, na Conferˆencia de Engenharia de Software da OTAN, fala da necessidade da ind´ustria de software produzir fam´ılias de componentes reus´aveis, onde os desenvolvedores de software deveriam poder escolher componentes conforme suas necessidades, e estes componentes deveriam ser tratados, em seus sistemas, como artefatos de software “caixapreta”, isto e´ , sem que seu conte´udo (especificac¸a˜ o) pudesse ser conhecido ou alterado. Um paradigma de desenvolvimento de software baseado em um conjunto de m´odulos produzidos separadamente e posteriormente interligados foi proposto por (DEREMER; KRON, 1975). Devido a limitac¸o˜ es para a implementac¸a˜ o destas tecnologias, este assunto s´o entrou em voga alguns anos mais tarde, quando, em 1996, houve o evento WCOP, onde se definiu componente como “uma unidade de composic¸a˜ o com interfaces contratualmente especificadas e dependˆencia de contexto expl´ıcitas. Componentes podem ser duplicados e estar sujeitos a composic¸a˜ o com terceiros” (SZYPERSKI et al., 1996). No evento seguinte, o WCOP 97, esta vis˜ao foi refinada: “o que torna alguma coisa, um componente, n˜ao e´ uma aplicac¸a˜ o espec´ıfica nem uma tecnologia de implementac¸a˜ o espec´ıfica. Assim, qualquer dispositivo de software pode ser considerado um componente, desde que possua uma interface definida.”(BOSCH et al., 1997)..
(24) 24. 2.2. Estrutura de Componentes Neste contexto, onde um componente e´ definido como uma caixa-preta e somente. pode ser acessado, compreendido e conectado a outros componentes, e´ importante enfatizar que a interface e´ “uma colec¸a˜ o de pontos de acesso a servic¸os, cada um com uma semˆantica estabelecida”(BOSCH et al., 1997). Mas, com a disponibilizac¸a˜ o de somente a descric¸a˜ o da interface, fica uma lacuna de informac¸o˜ es para a conex˜ao confi´avel entre componentes, pois informac¸o˜ es sobre a ordem de acesso, pr´e-condic¸o˜ es e contexto devem ser apresentadas. Estas informac¸o˜ es s˜ao de extrema importˆancia para os desenvolvedores de aplicac¸o˜ es e precisam de uma especificac¸a˜ o semˆantica, para que n˜ao haja problemas de ambig¨uidade na conex˜ao de componentes. Para que a semˆantica possa ser representada, ser´a utilizado algum formalismo, que ser´a visto no cap´ıtulo 3.. Figura 2.1: Estrutura de uma Interface. A interface de um componente pode prover diversos pontos de acesso, como ilustrado na figura 2.1, chamados de portas 1 . As portas, por sua vez, podem dispor de um ou mais servic¸os, onde cada um possui uma assinatura (similar a assinatura de um m´etodo sob o paradigma OO), como nome e, se necess´ario, parˆametros, que podem ser de entrada e/ou sa´ıda. Uma porta pode prover servic¸os, bem como requerˆe-los. Isto caracteriza a bidirecionalidade da porta. Devido a` caracter´ıstica de um sistema baseado 1. Em (SILVA, 2000) e (SILVA; PRICE, 2002) portas e canais s˜ao equivalentes..
(25) 25. em componentes ser unicamente composto de componentes, esta bidirecionalidade e´ intr´ınseca a este contexto.. 2.3. Perfis de Trabalho O desenvolvimento de software baseado em componentes possui dois perfis de. trabalho: o do desenvolvimento de componentes, que n˜ao est´a no escopo deste trabalho, e o da junc¸a˜ o destes componentes em sistemas. Geralmente as empresas que desenvolvem os componentes n˜ao s˜ao as mesmas que ir˜ao fazer a montagem dos sistemas.. As. empresas que desenvolvem os componentes o fazem de forma especializada, pois esta especializac¸a˜ o e´ o que as empresas que comp˜oem diversos componentes para a montagem de sistemas procuram. Para a empresa que ir´a fazer a composic¸a˜ o de componentes para montagem de um sistema, h´a uma s´erie de quest˜oes que devem ser vistas, como, por exemplo, a forma de identificac¸a˜ o para selec¸a˜ o dos componentes, como us´a-los e qual o seu comportamento. Isto demanda a identificac¸a˜ o de padr˜oes que permitam a criac¸a˜ o de componentes independentes que possam facilmente ser integrados (BOSCH et al., 1997). Desde que o desenvolvedor de sistemas baseados em componentes trabalhe com componentes caixaspretas, ou seja, segundo (BOSCH et al., 1997), n˜ao podem ser modificados internamente, assim, o que ele e´ , e o que ele faz, deve ser explicitado na interface. A quest˜ao do desenvolvimento de aplicac¸o˜ es, baseado em componentes, passa pela selec¸a˜ o, composic¸a˜ o e adaptac¸a˜ o de componentes, ao inv´es de pelo desenvolvimento tradicional, entendido aqui como o desenvolvimento que se inicia do zero.. O. desenvolvedor tem agora que, a partir de uma colec¸a˜ o de componentes disponibilizados no mercado, escolher e compor os que ele considera correto para o desenvolvimento de sua aplicac¸a˜ o. Esta tarefa parece simples, por´em traz uma s´erie de complicac¸o˜ es inerentes ao desenvolvimento de componentes, tais como citados abaixo: • pra o desenvolvedor de componentes: como representar a interface de seu produto para que seja simples e de r´apido entendimento, o que ele faz e como compor este com outros componentes, j´a que e´ imposs´ıvel testar um componente para todas as aplicac¸o˜ es e ambientes onde ele poder´a ser usado;.
(26) 26. • para o desenvolvedor de aplicac¸o˜ es: o problema e´ uma extens˜ao do anterior, ou seja, ele tem que selecionar um componente sem poder saber como ele e´ internamente. Mesmo que se saiba o que ele faz, h´a o problema de como integr´a-lo ao sistema (caso seja poss´ıvel) e como adapt´a-lo (caso seja necess´ario).. Figura 2.2: Desenvolvimento de uma aplicac¸a˜ o baseada em componentes.. A figura 2.2 mostra o desenvolvimento de uma aplicac¸a˜ o baseada em componentes e nela tem-se a vis˜ao de o desenvolvedor de aplicac¸o˜ es poder selecionar e reusar componentes prontos, desenvolver novos e adaptar os j´a existentes. Numa u´ nica tarefa de selec¸a˜ o e composic¸a˜ o..
(27) 27. 2.4. Mecanismos de Conex˜ao de Componentes A composic¸a˜ o de componentes e´ feita atrav´es da conex˜ao das portas das interfaces. dos componentes, mas para isso um mecanismo especializado deve ser utilizado. Este mecanismo deve permitir a operac¸a˜ o conjunta destes componentes, independente de sua linguagem de desenvolvimento, da plataforma de execuc¸a˜ o dos servic¸os ou da localizac¸a˜ o f´ısica dos mesmos. Os mecanismos de conex˜ao s˜ao usados para a interligac¸a˜ o entre componentes, mas e´ necess´ario que suas interfaces sejam compat´ıveis, ou seja, os servic¸os requeridos por um componente sejam fornecidos por outro. Para verificar esta compatibilidade faz-se necess´aria a compreens˜ao da descric¸a˜ o de componentes, como tratado a seguir. Como os mecanismos de conex˜ao de componentes n˜ao fazem parte do foco deste trabalho, n˜ao e´ dada eˆ nfase a este assunto. Para maiores detalhes sobre estes mecanismos pode-se utilizar como referˆencia (SZYPERSKI; GRUNTZ; MURER, 2002), onde todos os mecanismos atuais, juntamente com futuras tecnologias, s˜ao abordados com extrema riqueza de detalhes, fazendo inclusive estudos comparativos entre estes mecanismos.. 2.5. Mecanismos de Descric¸a˜ o de Componentes Segundo (SILVA, 2000), a forma usual de se descrever um componente consiste na. descric¸a˜ o de sua interface. Por´em, os mecanismos de descric¸a˜ o de interface existentes, em geral, s˜ao pobres para descrever componentes, porque produzem apenas uma vis˜ao externa, incapaz de descrever suas funcionalidades e como estes interagem (HONDT; LUCAS; STEYAERT, 1997).. “A descric¸a˜ o de um componente abrange trˆes aspectos. distintos: estrutural, comportamental e funcional” (SILVA, 2000), que ser˜ao aprofundados no cap´ıtulo seguinte. Como neste assunto est´a o foco deste trabalho foi reservado um cap´ıtulo para tratar do mesmo. “Um dos fatores que dificultam o reuso de componentes e´ a inexistˆencia de padr˜oes de descric¸a˜ o de componentes capazes de abranger todos os aspectos.”(SILVA, 2000).
(28) 28. 2.6. Adaptac¸a˜ o de Componentes Componentes prontos, encontrados no mercado, tˆem uma probabilidade muito. pequena de poderem ser ligados entre si na sua forma original. Segundo (BOSCH et al., 1997), isto se justifica pelo fato de o desenvolvedor de um componentes n˜ao conseguir prever todas as aplicac¸o˜ es poss´ıveis de seu componente e nem todas as circunstˆancias em que ele pode ser utilizado. Al´em disso, a inexistˆencia de um padr˜ao para modelagem de componentes e de t´ecnicas para realizar a integrac¸a˜ o dentro de sistemas colabora com a afirmac¸a˜ o acima. Dentro desta perspectiva, a adaptac¸a˜ o se torna uma etapa fundamental para o desenvolvimento baseado em componentes.. Mais detalhes poder˜ao ser vistos em. (SARTORI, 2005), visto seu trabalho ser focado em adaptac¸a˜ o de componentes. Para que uma adaptac¸a˜ o possa ser realizada, inicialmente se deve verificar a compatibilidade entre componentes, e, dependendo do tipo de incompatibilidade, adapt´alo adequadamente. No cap´ıtulo a seguir a compatibilidade entre componentes e´ tratada..
(29) 29. 3. Compatibilidade entre componentes. Componentes dificilmente poder˜ao ser usados como foram concebidos, provavelmente passar˜ao por um processo de adaptac¸a˜ o para terem condic¸o˜ es de se conectarem (BOSCH et al., 1997). Mas nem tudo deve ou tem que ser adaptado; somente os pontos de incompatibilidade entre os componentes. Para que se possa achar a incompatibilidade, o componente deve ser bem descrito. A citac¸a˜ o abaixo apresenta quais aspectos devem ser abordados nessa descric¸a˜ o. “A descric¸a˜ o de um componente abrange trˆes aspectos distintos: estrutural, comportamental e funcional... A descric¸a˜ o estrutural corresponde a` relac¸a˜ o das assinaturas dos m´etodos da interface. A comportamental tamb´em se at´em a` interface e especifica restric¸o˜ es na ordem de invocac¸a˜ o dos m´etodos. A descric¸a˜ o funcional vai al´em da interface e visa descrever o que o componente faz, pois, n˜ao e´ poss´ıvel saber o que os m´etodos fazem apenas conhecendo sua assinatura e restric¸a˜ o de ordem de invocac¸a˜ o.” (SILVA, 2000). Al´em da descric¸a˜ o espec´ıfica do componente, a descric¸a˜ o da arquitetura dos componentes deve ser considerada como de extrema importˆancia. A relevˆancia desta descric¸a˜ o e´ tratada superficialmente ainda neste cap´ıtulo, pois n˜ao far´a parte deste trabalho, podendo ser mais explorada em trabalhos futuros. Nas sec¸o˜ es seguintes s˜ao tratados os tipos de compatibilidade, e os problemas associados a` sua falta.. 3.1. Compatibilidade Estrutural A especificac¸a˜ o da interface de um componente engloba um contrato entre os. desenvolvedores dos servic¸os providos e os clientes deste componente (BOSCH et al.,.
(30) 30. 1997), pois certas regras de nomenclaturas de m´etodos e tipos de parˆametros devem ser obedecidas. Para que haja a compatibilidade estrutural entre duas portas de componentes, os servic¸os requeridos de um componente devem ser fornecidos pelo outro. Isto pode ser verificado atrav´es da comparac¸a˜ o das assinaturas dos m´etodos, definidos na interface dos componentes.. Caso um componente n˜ao contenha uma assinatura de m´etodo. correspondente na outra ponta da conex˜ao, ent˜ao h´a incompatibilidade estrutural entre eles. Um exemplo muito comum de incompatibilidade estrutural e´ a diferenc¸a na nomenclatura dos m´etodos, como, CREATE() sendo solicitado um componente, e NEW() sendo requerido em no outro. Assumindo que sejam funcionalmente compat´ıveis, isto e´ , tˆem a mesma funcionalidade, instanciar algo, ent˜ao devem ser adaptados. Esta adaptac¸a˜ o deve fazer com que, quando CREATE() for solicitado no componente, o outro fornec¸a o servic¸o NEW(). Isto se estende a diferenc¸as na quantidade e tipo de parˆametros. A resoluc¸a˜ o para a adaptac¸a˜ o entre componentes s˜ao vistas em (SARTORI, 2005). No ambiente SEA a estrutura de componente e´ especificada por um modelo pr´oprio, criado por (SILVA, 2000), atrav´es da especificac¸a˜ o de sua interface. Esta forma de especificac¸a˜ o e´ tratada em 5.1.5.1, a` p´agina 56.. 3.2. Compatibilidade Comportamental “Dois componentes s˜ao comportamentalmente compat´ıveis quando as restric¸o˜ es. associadas a ordem de execuc¸a˜ o de servic¸os fornecidos ou requeridos estabelecidas em um s˜ao respeitadas pelo outro.” (SILVA, 2000). Diversas propostas para a especificac¸a˜ o de compatibilidade comportamental s˜ao descritas e acabam se reunindo em alguns grupos caracter´ısticos. O modelo proposto por (HONDT; LUCAS; STEYAERT, 1997) Reuse Contract se baseia na descric¸a˜ o estrutural e comportamental, onde a especificac¸a˜ o comportamental documenta as dependˆencias interoperacionais entre um conjunto de componentes. A figura 3.1 apresenta, com uma notac¸a˜ o gr´afica, um exemplo de Reuse Contract..
(31) 31. Figura 3.1: Exemplo de Reuse Contract para a especificac¸a˜ o da conex˜ao de componentes.. Este modelo e´ de f´acil visualizac¸a˜ o e compreens˜ao, mas um problema levantado por (SILVA, 2000), e´ que ele e´ prec´ario em formalismo, o que e´ necess´ario para descrever precisamente a interac¸a˜ o entre componentes. Esta falta de formalismo n˜ao permite que an´alises automatizadas possam ser feitas sobre a especificac¸a˜ o. Formalismos alg´ebricos vˆem sendo amplamente utilizados para descrever protocolos de comunicac¸a˜ o e sistemas distribu´ıdos, e, conforme (CANAL et al., 1997), s˜ao adequados ao contexto de componentes, pois permitem que an´alises de propriedades possam ser realizadas, como equivalˆencia de comportamento entre componentes, verificac¸a˜ o sobre a possibilidade de deadlock, conforme tratado no cap´ıtulo anterior entre outras. Em (CANAL et al., 1997) e´ proposto que um m´etodo formal seja usado para a especificac¸a˜ o da arquitetura de componentes, chamado de Lambda Calculus. Mas um problema levantado por (SILVA, 2000) e´ que esta soluc¸a˜ o, por ser de baixo n´ıvel, torna-se dif´ıcil de ser aplicada para descrever sistemas complexos. Para que se pudesse obter a facilidade de compreens˜ao e de utilizac¸a˜ o de uma notac¸a˜ o gr´afica, e toda a rigidez do formalismo alg´ebrico, (SILVA, 2000) propˆos que Redes de Petri fossem adotadas. Os lugares da rede representariam pr´e ou p´os-condic¸o˜ es e as transic¸o˜ es representam o par(canal/m´etodo) do componente. Caso a transic¸a˜ o n˜ao esteja sensibilizada, isto e´ , todos os lugares antecessores a` transic¸a˜ o n˜ao contenham fichas, a transic¸a˜ o n˜ao poder´a ser disparada. No contexto de componente esta afirmac¸a˜ o ficaria da seguinte forma: Caso um m´etodo n˜ao esteja habilitado, isto e´ , as pr´e-condic¸o˜ es para n˜ao sejam satisfeitas, o m´etodo n˜ao poder´a ser invocado. No cap´ıtulo 5 e´ tratado, com detalhes, como as redes de Petri s˜ao desenvolvidas e utilizadas para a especificac¸a˜ o da interface de componentes no ambiente SEA. Apesar de n˜ao estar atualmente implementada verificac¸a˜ o de deadlock e outras an´alises, elas podem ser feitas sobre a rede de Petri da aplicac¸a˜ o, que e´ gerada a partir da uni˜ao das rede de.
(32) 32. Petri dos componentes. Mais detalhes sobre a rede da aplicac¸a˜ o s˜ao tratados na sec¸a˜ o 7.2.2.1.. 3.3. Compatibilidade Funcional Dois componentes possuem compatibilidade funcional quando as funcionalidades. requeridas por um s˜ao supridas pelo outro. Apenas as compatibilidades estrutural e comportamental n˜ao asseguram que a execuc¸a˜ o do conjunto de componentes ocorrer´a livre de problemas. Deve haver a verificac¸a˜ o de que suas funcionalidades tamb´em sejam compat´ıveis, para isso, ao se utilizar um componente, e´ imprescind´ıvel que sua compreens˜ao seja realizada. Um caso bastante divulgado, representando uma falha de compatibilizac¸a˜ o funcional, e´ a explos˜ao da aeronave Ariane-5 em seu vˆoo 501 (SILVA, 2000 apud LIONS, 1996). Segundos ap´os o seu lanc¸amento o sistema de autodestruic¸a˜ o foi ativado, devido a` uma falha no sistema de referˆencia inercial (velocidade horizontal), pois foi considerado que a aeronave estava caindo. Uma vez que o hardware e o software havia permanecido o mesmo do projeto anterior, o Ariane-4, optou-se por n˜ao realizar o teste com simulac¸a˜ o do sistema inercial. Isto acabou resultando no problema de incompatibilidade funcional. A estrutura e o comportamento dos componentes permaneceram intactos, mas a velocidade, cinco vezes maior, da aeronave, fez com que houvesse o estouro da capacidade interna de c´alculo do sistema.. 3.4. Arquitetura de Componentes Um software pode ser visto sob diferentes n´ıveis de abstrac¸a˜ o. Se um pequeno. detalhe de implementac¸a˜ o for o foco de vis˜ao sobre o software, ent˜ao o n´ıvel de abstrac¸a˜ o e´ pequeno, onde sua definic¸a˜ o pode ser feita pela leitura direta de c´odigo. Se o foco for a forma que as informac¸o˜ es deste software s˜ao armazenadas, ent˜ao o n´ıvel de abstrac¸a˜ o e´ maior, e sua definic¸a˜ o pode ser por interm´edio de frameworks. O maior n´ıvel de abstrac¸a˜ o e´ o da arquitetura deste software, onde sua definic¸a˜ o e´ feita em termos de um conjunto de artefatos e de conex˜oes entre esses artefatos. Segundo (SHAW; GARLAN, 1996), a arquitetura de software surgiu como uma.
(33) 33. evoluc¸a˜ o natural das abstrac¸o˜ es de projeto, na busca de novas formas de construir sistemas de software maiores e mais complexos. A arquitetura de software busca formas de descrever organizac¸o˜ es de sistemas de software existentes para promover o reuso de experiˆencia de projeto, possibilitando assim a escolha da forma mais adequada de organizac¸a˜ o de um sistema de software. “Uma arquitetura de software e´ definida a partir de um conjunto de artefatos de software e da forma como estes artefatos s˜ao interligados. Assim, um estilo arquitetˆonico define uma topologia de conex˜ao espec´ıfica, isto e´ , uma forma de interconectar os artefatos de uma arquitetura, o que restringe as possibilidades de interac¸a˜ o entre os artefatos da topologia... O que caracteriza um estilo arquitetˆonico e´ a forma como os artefatos est˜ao conectados e como interagem” (SILVA, 2000). Em sua tese, (SILVA, 2000) apresenta um levantamento de diversos estilos arquitetˆonicos para e produc¸a˜ o de artefatos de software. Diferentes tipos de linguagens possuem a capacidade de descrever um sistema como um conjunto de m´odulos interligados, como a linguagem ADA, IDL e o ambiente ADES (SILVA, 2000 apud FRAGA, 1988), outras linguagens, como a ADL, se prop˜oe a resolver a descric¸a˜ o da arquitetura. A falta de uma forma para expressar qual estilo arquitetˆonico est´a sento utilizado, e´ , segundo (SILVA, 2000), o maior problema na utilizac¸a˜ o de linguagens para a especificac¸a˜ o da arquitetura. Um caminho para se resolver este problema, e´ a utilizac¸a˜ o de t´ecnicas de decric¸a˜ o formal (SHAW; GARLAN, 1996). Neste trabalho a arquitetura ser´a abordada somente como o maior n´ıvel de abstrac¸a˜ o para a visualizac¸a˜ o de um software, onde a especificac¸a˜ o da arquitetura de componentes conter´a apenas a conex˜ao entre componentes, sem a restric¸a˜ o de topologia, isto e´ sem que seja verificado se a conex˜ao entre componentes deve obedecer alguma regra arquitetˆonica. Esta caracter´ıstica poder´a ser tratada em trabalhos futuros. O formalismo da rede de Petri, tratado no cap´ıtulo seguinte, vem para viabilizar a especificac¸a˜ o do comportamento do componente e da aplicac¸a˜ o como um todo. Com isto an´alises podem ser feitas para auxiliar na verificac¸a˜ o e resoluc¸a˜ o de poss´ıveis problemas comportamentais..
(34) 34. 4. Redes de Petri. O modelo de rede de Petri foi proposto por Carl Petri para modelar a comunicac¸a˜ o entre autˆomatos utilizados na e´ poca, para representar sistemas de eventos discretos. “Segundo os autores a rede de Petri por ser um modelo f´acil de compreender e com grande poder formal pode ser usado com muito sucesso para representar comportamento de sistemas.” (THOMAS, 1976). Neste cap´ıtulo s˜ao tratados os conceitos b´asicos utilizados neste modelo e as t´ecnicas de an´alise utilizadas para descobrir caracter´ısticas na rede de Petri que podem ser utilizadas para a an´alise comportamental da interac¸a˜ o entre componentes. Nas sec¸o˜ es seguintes s˜ao vistas as an´alises da rede de petri e a relac¸a˜ o das propriedades verificadas com o comportamento dos componentes numa interac¸a˜ o.. 4.1. Definic¸a˜ o Uma definic¸a˜ o informal de redes de Petri contempla um modelo formado por trˆes. elementos:. Lugar: e´ representado por um c´ırculo, que pode ser interpretado como uma condic¸a˜ o, uma posic¸a˜ o geogr´afica, entre outros. Em geral, todo lugar tem um predicado associado, por exemplo, m´aquina livre, pec¸a em espera, etc. Transic¸a˜ o: e´ representado por um retˆangulo, e associado a um evento que ocorre no sistema, como o evento iniciar a operac¸a˜ o..
(35) 35. Ficha: e´ representada por um ponto num lugar, indica que a condic¸a˜ o associada a este lugar e´ verificada. Pode representar um recurso, uma certa posic¸a˜ o geogr´afica. Por exemplo, uma ficha num lugar m´aquina livre indica que a m´aquina est´a livre, o predicado e´ verdadeiro. Se n˜ao tem fichas nesse lugar, o predicado e´ falso, por conseguinte a m´aquina n˜ao est´a livre.. A interpretac¸a˜ o destes elementos pode ser feita de diversas maneiras, como por exemplo: lugares podem representar pec¸as ou m´aquinas em uma linha de produc¸a˜ o, as fichas, a disponibilidade destes lugares, e transic¸o˜ es uma solicitac¸a˜ o de operac¸a˜ o de beneficiamento de uma pec¸a em uma m´aquina. A figura 4.1 concretiza este exemplo.. Figura 4.1: Rede de Petri. Fonte: (CARDOSO; VALLET, 1997). 4.2. Comportamento Dinˆamico A cada evento que ocorre no sistema, e´ associada uma transic¸a˜ o no modelo de rede. de Petri. A ocorrˆencia destes eventos (que faz com que se passe do estado atual para o pr´oximo estado) e´ representada, no modelo, pelo disparo de transic¸a˜ o ao qual este est´a associado. O disparo de uma transic¸a˜ o ocorre nos seguintes passos:. • retirar a ficha dos lugares de entrada, indicando que essa condic¸a˜ o n˜ao e´ mais verdadeira ap´os ocorrˆencia do evento. • depositar fichas em cada lugar de sa´ıda, indicando que essas atividades estar˜ao, ap´os a ocorrˆencia do evento, sendo executadas..
(36) 36. Este comportamento pode ser exemplificado pela figura 4.1.a, onde a ocorrˆencia do evento iniciar a operac¸a˜ o, associado a` transic¸a˜ o t, s´o pode ocorrer se houver ao menos uma ficha no lugar m´aquina livre e ao menos uma ficha no lugar pec¸a em espera. O disparo da transic¸a˜ o t na Rede de Petri, e´ a retirada de uma ficha do lugar m´aquina livre e uma ficha do lugar pec¸a em espera e a colocac¸a˜ o de uma ficha num lugar m´aquina em operac¸a˜ o como est´a na figura 4.1.b .. Figura 4.2: Seq¨ueˆ ncia de disparos em uma rede de Petri. Fonte: (CARDOSO; VALLET, 1997). A figura 4.2, representa o modelo de uma seq¨ueˆ ncia de um processo de fabricac¸a˜ o de uma pec¸a. As diferentes fases da operac¸a˜ o da pec¸a s˜ao representadas pelos lugares P1, P2 e P3, as quais obedecem uma seq¨ueˆ ncia para a fabricac¸a˜ o. Os eventos de passagem de uma fase a outra e as fichas, s˜ao as transic¸o˜ es t1, t2 e t3. A pec¸a que est´a no lugar P1 (na fase J1), ir´a, em seguida, para a fase J2, ou, uma outra pec¸a pode estar no lugar P3 (na fase J3).. Definic¸a˜ o Formal de uma Rede de Petri. 4.3 4.3.1. Rede de Petri. Uma rede de Petri e´ representada matematicamente por uma qu´adrupla:. R =< P, T, P re, P ost > Onde: P e´ um conjunto finito de lugares; T e´ um conjunto finito de transic¸o˜ es; Pre e´ a aplicac¸a˜ o dos lugares precedentes;. (4.1).
(37) 37. Post e´ a aplicac¸a˜ o dos lugares seguintes.. Graficamente, a rede de Petri pode ser representada, como o exemplo da figura 4.3.. Figura 4.3: Rede de Petri. Fonte: (CARDOSO; VALLET, 1997). 4.3.2. Marcac¸a˜ o da Rede. A marcac¸a˜ o de uma rede de Petri e´ representada matematicamente por uma dupla: N =< R, M >. (4.2). Onde:. R e´ uma rede de Petri; M e´ uma marcac¸a˜ o inicial, dada pela aplicac¸a˜ o. M : P →N Onde M(p) e´ o n´umero de marcas ou fichas contidas no lugar p.. (4.3).
(38) 38. 4.3.3. Grafo Associado e Notac¸a˜ o Matricial. As redes de Petri podem ser representadas por um grafo, como visto na figura 4.3, onde temos dois tipos de n´os: lugares e transic¸o˜ es. Um arco conecta um lugar p a uma transic¸a˜ o t se e somente se Pre(p,t) = 0. E, conecta uma transic¸a˜ o t a um lugar p se e somente se Post(p,t) = 0. Os valores n˜ao nulos de Pre e Post s˜ao associados aos grafos por etiquetas. Caso o valor for unit´ario, n˜ao e´ necess´ario etiquetar. A marcac¸a˜ o M, pode ser matematicamente representada pelas seguintes notac¸o˜ es, usando a figura 4.3 como referˆencia: P = p1, p2, p3 T = a, b, c, d . . 0 1 0 0. . . P re = 1 0 3 0 0 0 0 1 . 1 0 0 0. . . P ost = 0 1 0 3 0 0 1 0 . 1 −1. . C= 1 0. . 0. 0. 1. −3. 0. 1. 0. . 3 . −1. . M = 3 0. A marcac¸a˜ o M, representada acima pelo vetor, sendo a dimens˜ao, o n´umero de lugares; Pre, Post e C podem ser representados pelas matrizes onde o n´umero de linhas e´ igual ao n´umero de lugares e o n´umero de colunas e´ igual ao n´umero de transic¸o˜ es..
(39) 39. 4.3.4. Rede de Petri Pura. Uma rede de Petri e´ pura se nenhuma transic¸a˜ o possui um mesmo lugar como entrada e sa´ıda ao mesmo tempo. Por exemplo, a figura 4.3 e´ uma rede de Petri pura, enquanto que a figura 4.4 n˜ao e´ uma rede pura.. 4.3.5. Transic¸a˜ o Sensibilizada. Uma transic¸a˜ o t e´ sensibilizada, matematicamente, se e somente se:. ∀p ∈ P, M (p) ≥ P re(p, t). (4.4). Portanto, os lugares de entrada da transic¸a˜ o devem possuir o n´umero de fichas que correspondem ao peso do arco que conecta o lugar a` transic¸a˜ o, como ilustra a figura 4.3. Nesta figura, considerando para a marcac¸a˜ o inicial: . 0. . M = 3 0. com . 0. . . P re(•, a) = 1 0. e . 0. . P re(•, c) = 3 0 conclui-se que as transic¸o˜ es sensibilizadas s˜ao a e c, pois M > P re(•, a)eM = P re(•, c)..
(40) 40. 4.3.6. Disparo de uma Transic¸a˜ o. Se uma transic¸a˜ o t e´ sensibilizada por uma marcac¸a˜ o M, a nova marcac¸a˜ o M’ e´ originada atrav´es de um disparo, de forma que:. ∀p ∈ P, M 0 (p) = M (p) − P re(p, t) + P ost(p, t).. (4.5). Conforme a figura 4.4, citada como exemplo, ap´os disparada a transic¸a˜ o a considerando a marcac¸a˜ o inicial M, obt´em-se a seguinte marcac¸a˜ o M’:. Figura 4.4: Disparo de uma Transic¸a˜ o. Fonte: (CARDOSO; VALLET, 1997). 4.3.7. Conflito e Paralelismo. As noc¸o˜ es de conflito e paralelismo de transic¸o˜ es, s˜ao definidas em n´ıveis. Os conflitos na rede de Petri, podem ser:. • conflito estrutural: e´ estabelecido pela estrutura da pr´opria rede. Duas transic¸o˜ es t1 e t2 est˜ao em conflito estrutural se elas tem ao menos um lugar de entrada em comum:. ∃p ∈ P, P re(p, t1 ).P re(p, t2 ) 6= 0.. (4.6).
(41) 41. • conflito efetivo: e´ a quest˜ao circunstancial de disparo das transic¸o˜ es.. Duas. transic¸o˜ es t1 e t2 est˜ao em conflito efetivo para a marcac¸a˜ o M se e somente se ambas est˜ao sensibilizadas:. M ≥ P re(•, t1 )eM ≥ P re(•, t2 ).. (4.7). O paralelismo na rede de Petri e´ definido pelos n´ıveis estrutural e efetivo, descritos a seguir: • paralelismo estrutural: duas transic¸o˜ es t1 e t2 s˜ao paralelas estruturalmente se n˜ao possuem nenhum lugar de entrada em comum:. ∀p ∈ P, P re(p, t1 ).P re(p, t2 ) = 0. (4.8). • paralelismo efetivo: duas transic¸o˜ es t1 e t2 s˜ao paralelas para uma marcac¸a˜ o M, se e somente se s˜ao paralelas estruturalmente:. M ≥ P re(•, t1 )eM ≥ P re(•, t2 ).. (4.9). Tendo a figura BB como exemplo, as transic¸o˜ es a e c est˜ao em conflito estrutural, pois P re(p2 , a).P re(p2 , c) = 3 e as transic¸o˜ es b e d est˜ao em paralelismo estrutural.. 4.3.8. Conjunto das Marcac¸o˜ es Acess´ıveis. Para uma rede com marcac¸a˜ o inicial M0 define-se A(R, M0 ): o conjunto de marcac¸o˜ es que se pode atingir da marcac¸a˜ o atrav´es de uma seq¨ueˆ ncia de disparo. A notac¸a˜ o matem´atica definida para isso e´ :. n. s. A(R, M ) = Mi , ∃sM →, Mi. o. (4.10).
(42) 42. 4.4. Propriedades de Redes de Petri. 4.4.1. Lugar k-Limitado e Bin´ario. Um lugar p de uma rede e´ k-limitado se e somente se:. ∀M 0 ∈ A(R, M ), M 0 (p) ≤ k.. 4.4.2. (4.11). Rede k-Limitada e Rede Bin´aria. Uma rede de Petri marcada N e´ dita k-limitada ou simplesmente limitada se o n´umero de fichas em cada lugar n˜ao excede um n´umero finito para qualquer marcac¸a˜ o alcanc¸a´ vel desde M0 , isto e´ :. ∃k ∈ N/M (p) ≤ k, ∀M ∈ A(R, M0 ). (4.12). Se k = 1 diz-se que o lugar e´ seguro, salvo ou bin´ario. Por exemplo, na rede da figura abaixo, cada marcac¸a˜ o M 0 , a qual pode ser alcanc¸a´ vel desde M0 , tem no m´aximo uma ficha em p. O conceito de rede limitada corresponde ao fato de que um sistema f´ısico e´ sempre limitado. Entretanto, pode-se utilizar uma rede de Petri n˜ao limitada quando se quer avaliar o desempenho do sistema independentemente dos limites de seus elementos de armazenamento intermedi´arios. O conceito de redes salva significa que seus lugares representam condic¸o˜ es l´ogicas, a presenc¸a de mais de uma ficha num lugar significa que uma incoerˆencia foi introduzida no modelo. Em geral, trata-se de uma condic¸a˜ o l´ogica colocada durante um ciclo de funcionamento, que n˜ao foi utilizado e ser´a recolocado no ciclo seguinte para o valor v´alido. Numa rede bin´aria, apenas um processo e´ representado; as transic¸o˜ es paralelas que aparecem s˜ao devidas a` s divis˜oes existentes em algum momento, mas que se sincronizar˜ao em seguida..
(43) 43. 4.4.3. Rede Marcada Viva. O conceito de rede viva (vivacidade) est´a relacionado com a total ausˆencia de deadlock (bloqueios) na operac¸a˜ o de um sistema. Isto e´ , uma transic¸a˜ o t e´ sempre viva se:. t. ∀M ∈ A(R, M0 ), ∃M 0 ∈ A(R, M )/M → M 0 .. (4.13). Uma rede de Petri marcada N (R, M ) e´ viva se e somente se todas as suas transic¸o˜ es s˜ao vivas. As transic¸o˜ es podem ser vivas se for poss´ıvel sempre encontrar uma seq¨ueˆ ncia de disparos que as cont´em, ou quase viva se for somente dispar´avel uma vez.. 4.4.4. Rede Reinicializ´avel. Uma Rede de Petri marcada N = (R, M ) e´ reinicializ´avel para toda marcac¸a˜ o se e somente se seu grafo de marcac¸o˜ es acess´ıveis GA(R, M ) e´ fortemente conexo, isto e´ :. s. ∀M 0 ∈ (R, M )∃s/M 0 → Mo. (4.14). Em outras palavras, quando e´ poss´ıvel que de qualquer marcac¸a˜ o derivada da marcac¸a˜ o inicial se volte a` marcac¸a˜ o inicial.. 4.5. T´ecnicas de An´alise da Rede de Petri Uma vez expostas algumas das principais propriedades das redes de Petri, faz-. se necess´ario determinar se uma rede de Petri possui ou n˜ao tais propriedades para o qual desenvolveram-se certas metodologias de an´alise. Essas metodologias podem ser classificadas em trˆes grandes grupos seguintes (MURATA, 1989; CARDOSO; VALLET, 1997): • An´alises por Enumerac¸a˜ o das Marcac¸o˜ es:. (feita atrav´es da a´ rvore de. alcanc¸abilidade/cobertura) e´ dinˆamica e simula a execuc¸a˜ o da rede de Petri a partir.
Documentos relacionados
Este trabalho buscou, através de pesquisa de campo, estudar o efeito de diferentes alternativas de adubações de cobertura, quanto ao tipo de adubo e época de
No entanto, maiores lucros com publicidade e um crescimento no uso da plataforma em smartphones e tablets não serão suficientes para o mercado se a maior rede social do mundo
O objetivo do curso foi oportunizar aos participantes, um contato direto com as plantas nativas do Cerrado para identificação de espécies com potencial
esta espécie foi encontrada em borda de mata ciliar, savana graminosa, savana parque e área de transição mata ciliar e savana.. Observações: Esta espécie ocorre
O valor da reputação dos pseudônimos é igual a 0,8 devido aos fal- sos positivos do mecanismo auxiliar, que acabam por fazer com que a reputação mesmo dos usuários que enviam
2 - OBJETIVOS O objetivo geral deste trabalho é avaliar o tratamento biológico anaeróbio de substrato sintético contendo feno!, sob condições mesofilicas, em um Reator
Nessa situação temos claramente a relação de tecnovívio apresentado por Dubatti (2012) operando, visto que nessa experiência ambos os atores tra- çam um diálogo que não se dá
da quem praticasse tais assaltos às igrejas e mosteiros ou outros bens da Igreja, 29 medida que foi igualmente ineficaz, como decorre das deliberações tomadas por D. João I, quan-
