•

W ALDEtv1AR CELES FlLHO

Modelagem Configurável de Subdivisões Planares Hierárquicas

Tese de Doutorado

Departamento de I1úormática ' Rio de Janeiro, 4 de julho de 1995

Modelagem Configurável de , Subdivisões Planares Hierárquicas'.(

\\'aldemar Celes Filho

Orientador: Marcelo Gattass

Tese apresentada ao Departamento de Infonnática da PUC-Rio como parte dos requisitos para a obtenção do título de Doutor em Informática: Ciência da Computação.

Programa de Computação Gráfica Departamento de Infom1ática Pontifícia Universidade Católica do Rio de Janeiro

Rio de Janeiro, 4 de julho de 1995

Resumo

As estruturas de dados topológicas têm sido usadas como base para o desenvolvimento de aplicações que trabalham com representações que são essencialmente subdivisões do plano, às quais atribuem-se propriedades pertinentes. Em diversos domínios, estes sistemas requerem uma disposição hierárquica das subdivisões não sendo atendida pelas estruturas de dados convencionais. Para dar suporte adequado ao desenvolvimento destas aplicações, identificamos as propriedades de representações hierárquicas e propomos uma estrutura de dados topológica que permite a representação de subdivisões planares hierárquicas numa única base de dados. A estrutura proposta responde às relações de adjacências entre as entidades topológicas e possui um conjunto de operadores básicos que garantem a consistência do modelo nas operações de edição.

Para permitir o acoplamento do sistema de gerenciamento da estrutura de dados em aplicações de domínios específicos, propomos uma arquitetura de implementação onde acopla-se um módulo cliente responsável pela caracterização semântica das entidades do modelo. Neste aspecto, discutimos configuração de aplicações como estratégia de re-uso de software, tendo em vista que ferramentas de configuração permitem o desenvolvimento de programas específicos com elevado grau de abstração, pois permitem um fácil acesso às tecnologias implementadas por outros sistemas.

Para diversas aplicações técnico-científicas, os atributos associados às entidades caracterizam a semântica do modelo matemático usado. Para permitir a incorporação de mecanismos de configuração nestas aplicações, propomos um sistema de configuração baseado na especificação de atributos. Apresentamos regras de comunicação entre aplicação e ambiente de configuração que orientam o desenvolvimento de aplicações configuráveis.

Como ferramenta auxiliar de configuração, propomos um sistema para desenvolvimento de interfaces gráficas interativas com elevado grau de abstração. Deste modo, provemos acesso simples e abstrato a objetos de interface convencionais e a objetos gráficos ativos. Isto permite que usuários configuradores, com pouco conhecimento em programação, rapidamente construam sofisticados diálogos de interface, instanciando objetos de interface próprios, projetados para o domínio de interesse.

Os serviços de configuração e a estrutura de dados propostos foram integrados, resultando num sistema configurável para modelagem de subdivisões planares hierárquicas.

Abstract

Topological data structures have been used to support applications that work with planar subdivisions. Many of these applications require a hierarchical representation, which is currently not supported by the usual data structures. This work proposes a topological data structure to represent hierarchical planar subdivisions. The proposed data structure answers ai! the relationships between the topological entities. A set of operators, needed to model such subdivisions, is presented and discussed.

To allow the use of such representations over different domains, a strategy for adding a client model to characterize the semantic associated with the model entities is proposed. The development of customizable applications as a strategy of softv;are reuse is also discussed. Customization tools that allow software development with high levei of abstraction provide users an easy access to the technology implemented by the applications. For severa! classes of technical-scientific applications, attributes characterize the semantics of the underlying mathematical model. So, an embedded system for adding configuration mechanisms to applications, based on attributes, is proposed. A model for the communication between an application and the configuration environment, with clearly defined boundaries, is presented.

An auxiliary too! for deve!oping highly abstract, interactive graphical applications is also described. Simple, high leve! prograrnmab!e access is provided to both conventional interface objects and active graphical objects that are specific to the application domain. This a!lows occasional programmers to quickly develop their own sophisticated interactive dialogs.

The configuration system and the data structure proposed are integrated to provide a powerful hierarchical planar subdivisions modeling tool.

Agradecimentos

Este trabalho foi desenvolvido ao longo de quatro anos em que pude contar com a colaboração de diversas pessoas, sem as quais não seria possível realizá-lo. Em especial, agradeço ao Prof. Marcelo Gattass que diretamente me orientou no desenvolvimento desta pesquisa e a quem devo minha formação profissional adquirida nos diversos projetos que desenvolvemos nesses anos. Agradeço também a Luiz Henrique de Figueiredo que participou efetivamente de todas as contribuições aqui apresentadas, passando-me conhecimentos e critérios de avaliação indispensáveis para o desenvolvimento desta pesquisa.

Aos Profs. Paulo Cezar Pinto Carvalho e Roberto lerusalimschy agradeço a sólida co­orientação no desenvolvimento de meus exames de qualificação para o doutorado, os quais deram origem ao trabalho aqui apresentado.

Agradeço às pessoas que formam a equipe do TeCGraf, em especial a Carlos Henrique Levy, Ivan Menezes, Luiz Cristovão Gomes Coelho e Marcelo Tilio Monteiro de Carvalho pelas constantes discussões, idéias e sugestões, e a Camilo Freire pelos importantes testes da linguagem Lua e do sistema EDG em aplicações industriais.

Agradeço à Ruth pela incansável atenção com que sempre me orientou na solução das etapas legais junto ao Departamento de Informática.

Agradeço à CAPES pelo financiamento desta pesquisa.

A realização deste trabalho foi também possível graças ao amor e à dedicação com que lvana, minha esposa, me incentivou durante todas as etapas desta realização. À Ivana agradeço, ainda, a revisão deste texto.

A meus pais,

Waldemar e Helena

• lndice

1. INTRODUÇÃO···················································-···························································································· 1

1.1 HISTÓRICO························································································································································· 3

1.2 ORGANIZAÇÃO DO TEXTO .................................................................................................................................. 4

l. GERENCIAMENTO DE SUBDIVISÕES PLANARES HIERÁRQUICAS ................................................ 6

2.1 CONCEITUAÇÃO DE HIERARQUIA E MULTI·RESOLUÇÃO ..................................................................................... 6

2.2 REPRESENTAÇÃO DE HIERARQUIA COM ESTRUTURAS CONVENCIONAIS ............................................................. 7

2.3 PROPRIEDADES DE SUBDIVISÃO PLANAR HIERÁRQUICA ..................................................................................... 9

2.4 REPRESENTAÇÃO DE SUBDJVISÔES PLANARES HIERÁRQUICAS ......................................................................... 12

2.4.1 Classes das entidades topológicas e geométricas ............. ..................................................................... 12

2.4.2 Estruturação das entidades............................................. ................................................. 13

2.4.3 Operadores básicos........................................... ...................... .................. /7

2.4.4 Relações de adjacéncias ... . .. . ................... .......... .. ... .................. . ..................... 20

2.4.5 Comentários sobre espaço de memória.. .............. ................. .................... . ........................ 26

2.5 MODELAGEM DE SUBDIVISÕES PLANARES HJERÁRQUICAS ............................................................................... 28

2.5. l Estratégias de inserção ..

2.5.2 Operadores de alto nível ....... .

2.5.3 Persistência do modelo

2.5.4 lnterface com o cliente

. .. 28

. 29

............... ·················· ······. 31

........ ································ 32

3. CONFIGURAÇÃO VIA ESPECIFICAÇÃO DE ATRIBUTOS ................................................................. 34

3.1 CONFIGURAÇÃO COMO ESTRATÉGIA DE RE·USO .............................................................................................. 35

3.2 REQUISITOS PARA CONFIGURAÇÃO DE APLICAÇÕES .......................................... , .............................................. 35

3.2. J Acesso às tecnologias das aplicaçâes ................................. ........................ . ............................ 36

3.2.2 Características da linguagem de programação ............... . ............................................................... 37

3.2.3 Agentes e níveis de abstração......... ............... ...................... ........................... . ........... 38

3 .3 LINGUAGEM DE CONFIGURAÇÃO ...................................................................................................................... 39

3.3.1 Variáveis e tipos. . ................................ ········· 39

3.3.2 Construtores de tipos.......................................................... . .......................................... 40

3.3.3 Mecanismo defallback.................................... ................ . ...................... 40

3. 3.4 Especialização da linguagem................... ......... ......... . .......................... 40

3.4 FERRAMENTAS PARA CRIAÇÃO DE INTERFACES GRÁFICAS ............................................................................... 41

3.4. l Características do sistema EDG ......................................................................................................... 42

3.4.2 Con1paração con1 siste1nas correlatos .................................................................................................... 49

3 .5 PROPOSTA DE CONFIGURAÇÃO VIA ESPECIFICAÇÃO DE A TRIBUTOS ................................................................. 51

3.5.J Caracterização da semântica ............................................................................................................... 52

3.5.2 Estruturação do modelo de configuração....................... . ........................................................... 52

3.5.3 Definição de insrâncias de atributos ................................. . . ................................................... 53 3.5.4 Estratégia de in1plen1entação e interface com o usuário ... . ·············································· ...... 54 3.5. 5 Acoplamento dos serviços de configuração às aplicações. . ............ ···································· 55 3.5.6 Acesso aos serviços de configuração.................................. . ................ 56

3.5. 7 Tarefa de configuração da aplicação............................... . ................................ 57

3.5.8 Exemplo de especificação de atributos........... ................. . ................................................ 58

3.6 APLICAÇÃO NO MODELADOR DE SUBDIVISÕES HIERÁRQUICAS ........................................................................ 61

3. 6.1 Operações de validação semântica .................................. ...................................................................... 61

3.6.2 Feedback e operações de entrada e saída ............................................................................................... 62

4. CONCLUSÃO···-····················································································· .. ····················································· 64

4. l REPRESV.1 AÇÃO DE SUBDIVISÕES PLANARES HIERÁRQUICAS ......................................................................... 64

4.2 CONFIGURAÇÃO DE Al'LICAÇÔES VlA ESPECIFICAÇÃO DE A TRIBtffOS .............................................................. 65

4.3 FERRAMENTA PARA CRIAÇÃO DE INTERFACES GRÁFICAS INTERATIVAS ........................................................... 65

4.4 TRABALHOS FUTUROS ...................................................................................................................................... 66

APÊNDICE A: CÁLCULO DE INTERSEÇÃO DE SEGMENTOS COM TOLERÂNCIAS ..................... 66

APÊNDICE B: CONSTRUÇÃO DE PROGRAMAS DE INTERFACES ...................................................... 70

CARACTERiSTICAS DOS PROGRAMAS DE INTERFACE .............................................................................................. 70

PROCESSO DE DESENVOL VlMfNTO DE APLICAÇÕES EDG ...................................................................................... 71

REFERÊNCIAS .................................................................................................................................................. 73

Índice de Figuras

FIGURA 1.1: HISTÓRICO DAS LINHAS DE PESQUISA .......................................................................•.......................... 5

FIGURA 2.1: NIVEIS HIERÁRQUICOS DOS MODELOS DE ELEMENTOS FINIT05 (CARVALHO ET AL., 1990):

(A) GEOMETRIA; (B) SUB·REGIÔES; (C) SUBDIVISÕES; (D) MALHA ....................................................... 8

FIGURA 2.2: (A) SUBDIVISÃO PLANAR; (B) PARTIÇÃO DO PLANO QUE NÃO t Sl'BDIVJSÃO PLANAR ........................ 10

FIGURA 2.3: ENTIDADES DE UM MODELO HIERÁRQUICO ........................................................................................ 11

FIGURA 2.4: CLASSES DAS ENTIDADES TOPOLÓGICAS E GEOMETRICAS .................................................................. 12

FIGURA 2.5: DISPOSIÇÃO IIlERÁRQUJCA DAS ENTIDADES TOPOLÓGICAS ................................................................ 14

FIGURA 2.6: DISPOSIÇÃO DAS ENTIDADES EM ÁRVORES E LISTAS .......................................................................... 14

FIGURA 2.7: DIAGRAMA DAS ESTRUTURAS DE CADA ENTIDADE ............................................................................ 15

FIGURA 2.8: QUADRO DOS OPERADORES BÁSICOS ................................................................................................. 1 8

FIGURA 2.9: MODELO COM TRlS NÍVEIS HIERÁRQUICOS ........................................................................................ 20

FIGURA 2.JO: RELAÇÕES DE ADJACENCIAS EM S\JBDJVISÕES PLANARES HIER.i.RQUICAS ....................................... 21

FIGURA 2.11: OBTENÇÃO DA INFORMAÇÃO V-+U ................................................................................................ 24

FIGURA 2.12: OBTENÇÃO DA INFORMAÇÃO V-+L. ............................................................................................... 24

FIGURA 2.13: OBTENÇÃO DA INFORMAÇÃO U-+L. .............................................................................................. 25

FIGURA 2.14: OBTENÇÃO DA INFORMAÇÃO U-+L. ...................................... . ················································· 25

FIGURA 2.15: NÚMERO DE ENTIDADES NA REPRESENTAÇÃO DE UM MODELOCO~I SUBDIVISÕES SUCESSIVAS ....... 27

FIGURA 2.16: NÚMERO DE ENTIDADES NA REPRESENTAÇÃO DOS NÍVEIS PROPOSTOS POR CARVALHO ET AL ........ 27

FIGURA 2.17: EXEMPLO DE APLICAÇÃO DAS ESTRATEGIAS DE INSERÇÃO .............................................................. 29

FIGURA 2.] 8: COMBINAÇÃO DE INSERÇÃO E DESTRUIÇÃO SEM RETOR.NAR À SITTJAÇÃO ORJGINAL ...................... 31

FIGURA 2.19: INTERFACE ENTRE E O GERENCIADOR E A APLICAÇÃO ..................................................................... 32

FIGURA 3.1: ARQUITETURA DE CONFIGURAÇÃO COM USO DE LINGUAGENS ESPECÍFICAS ...................................... 36

FIGURA 3.2: ARQUITETURA DAS APLICAÇÕES COM USO DE UMA LINGUAGEM CQ)-TJGUR.ÀVEL.. ............................ 37

FIGURA 3.3: AGENTES E l\ÍVEJS DE ABSTRAÇÃO............................................ . ............................................ 38

FIGURA 3.4: ARQUITETURA NA ESPECIALIZAÇÃO DE LUA. . ................ . ... 41

FIGURA 3 .5: ARQUITETURA DO SISTEMA EDG ................................... . ··········· 42

FIGURA 3.6: EXEMPLO DE UM DlÁLOGO SIMPLES ................................................................................................. 44

FIGURA 3. 7: MARCAS PARA TRANSFORMAÇÃO DE OBJETOS ................................................................................ 46

FIGURA 3.8: EDIÇÃO DE UMA LINHA POLIGONAL ................................................................................................ 47

FIGURA 3.9: EXEMPLO DE UM POTENClÔMETRO .................................................................................................. 48

FIGURA 3.10: TRANSFERf'<CIA DE OBJETOS ElffRE APLICAÇÕES EDG ................................................................. 49

FIGURA 3.] ] : ESTRUTUR.,ÇÃO DO MODELO DE CONFJGURAÇÃO ........................................................................... 52

FIGURA 3.12: l.4YOL.TS ABSTRATO E CONCRETO DA INTERFACE PARA DEFINIÇ..\O DE ATRIBUTOS .......................... 54

FlGURA 3.13: COMUNJCAÇÃO ENTRE APLICAÇÃO E AMBIENTE DE CONFIGUR.•Ç..\O .............................................. 55

FIGURA 3.14: EXEMPLO DE DIÁLOGOS PARA DEFINJÇÃO DE ATRJBUTOS ............................................................... 60

FIGURA 3.15: ARQUITETURA PARA OPERAÇÕES DE SAiDA ..................................................................................... 62

FIGURA 3.16: ARQUITETURA PARA OPERAÇÕES DE ENTRADA ............................................................................... 63

FIGURA 3.) 7: ARQUITETURA FINAL DO GERENCIADOR DE SUBDIVISÕES PLAl'ARES HIERÁRQUICAS ...................... 63

1. Introdução

Diversas aplicações computacionais nas áreas de Engenharia, Mineração, Geologia, Cartografia e Geografia trabalham com representações que são essencialmente subdivisões do espaço, às quais atribuem-se propriedades pertinentes. Como exemplos destas aplicações, podemos citar os geradores de malhas de elementos finitos, os simuladores de escavação subterrânea, os simuladores de transformações geológicas, as representações de mapas cartográficos e os sistemas de informações geográficas.

Além da característica comum de modelagem através de subdivisões do espaço, observa-se, em aplicações afins, a freqüente necessidade de representação de modelos hierárquicos. Não raro, estes sistemas requerem uma disposição hierárquica das subdivisões: em mapas cartográficos, as fronteiras dos estados são hierarquicamente inferiores às fronteiras dos países; geradores de malhas de elementos finítos subdividem o modelo em regiões, sobre as quais se aplicam os métodos de discretização do domínio; simuladores de transformações geológicas agrupam diversas camadas litológicas em módulos que viabilizam as simulações.

A representação dos modelos hierárquicos numa única base de dados é um tópico de muita relevância para o desenvolvimento de aplicações nas áreas citadas acima. Entretanto, existem poucas propostas que asseguram completitude e suficiência destes modelos hierárquicos (Puppo e Dettori, 1995). Para estas representações serem completas e suficientes, precisamos garantir a obtenção das relações de adjacências entre as diferentes entidades que compõem o modelo (Weiler, 1986).

Outro tópico ainda menos explorado é o reaproveitamento desta tecnologia para representação de hierarquias em diferentes domínios. Tendo em vista as diversas áreas que trabalham com estas subdivisões espaciais hierárquicas, é necessário provermos meios para que as estruturas de dados, que asseguram a representação destes modelos, possam ser aplicadas em domínios abrangentes.

O desafio que surge consiste em saber:

i. como representar subdivisões espaciais hierárquicas;

ii. como tomar estas representações aplicáveis em diferentes domínios.

A representação de subdivisões espaciais tem sido feita através de estruturas de dados topológicas. Essas estruturas são adequadas, pois permitem a manipulação dos modelos de forma consistente (respeitando as propriedades de uma subdivisão espacial) e garantem eficiência na obtenção das relações de adjacências entre as diversas entidades topológicas presentes (Weiler, 1986). As implementações atuais ou utilizam as estruturas topológicas para representação de subdivisões simples (Wawrzynek, 1987), ou criam artifícios para que essas estruturas convencionais sejam aplicadas na representação de subdivisões hierárquicas (Martha, 1989), ou tratam entidades de níveis hierárquicos superiores como agregações de entidades de níveis inferiores (Bruegger e Frank, 1989; Puppo e Dettori, 1995).

Neste trabalho, focamos nossa pesquisa na representação de subdivisões espaciais hierárquicas através das estruturas topológicas para representação da fronteira dos sólidos (B-

2

rep), da área de Modelagem de Sólidos (Weiler 1986; Mãntylã, 1988). Para os casos bidimensionais, as estruturas originalmente elaboradas para a representação da fronteira de sólidos manifold vêm sendo usadas com sucesso, interpretando o modelo corno o grafo planar associado a um sólido 3D (Wawrzynek, 1987; Campos 1991). Nos casos tridimensionais, estruturas mais complexas são requeridas, pois estas devem suportar representações non­manifold (Martha, 1989; Cavalcanti, 1992).

Entretanto, estas estruturas foram projetadas para representar subdivisões espaciais simples. A utilização delas para a representação de modelos hierárquicos cria artificios aplicados sobre estas estruturas convencionais. Por serem artificíos, empregados sobre estruturas originalmente elaboradas para suportar modelos não hierárquicos, tomam ainda mais complexas estas implementações, tendo em vista as dificuldades já inerentes ao tratamento de estruturas topológicas. A manutenção da consistência destes modelos recai, invariavelmente, em códigos de dificil entendimento e manutenção.

Visando responder à primeira questão acima enumerada, discutimos os problemas relacionados com a representação de modelos hierárquicos; identificamos as propriedades de subdivisões planares hierárquicas; e propomos uma estrutura de dados topológica que permite a representação destas subdivisões hierárquicas, provendo os recursos necessários para a manutenção da consistência do modelo e a obtenção das relações de adjacências entre as entidades topológicas, inclusive entre os diversos níveis de hierarquia (Ceies et ai., l 994a).

Para viabilizar a aplicação da estrutura de dados proposta em diferentes domínios, criamos uma interface abstrata para gerenciamento da estrutura que permite o acoplamento de um módulo cliente responsável pela caracterização semântica das entidades do modelo. Desta forma, a estrutura topológica garante a validação sintática do modelo, respeitando as propriedades de subdivisões planares hierárquicas, e deixa a cargo do cliente a validação semântica, feita através de um mecanismo de notificação de eventos que venham a ocorrer sobre o modelo.

Porém, a arquitetura para gerenciamento da estrutura proposta com o acoplamento do módulo cliente ainda não cria um nível de abstração adequado para permitir a particularização da aplicação para um domínio específico. É necessário cri~os mecanismos de configuração para permitir que a tarefa de especificação do domínio seja facilmente implementada.

Neste contexto, discutimos os problemas relacionados com configuração de aplicação e propomos a implementação de modeladores de subdivisões planares configuráveis. As aplicações devem ser estruturadas dividindo-as em duas partes: a implementação dos serviços e o acesso programável a esses serviços (Valdés, 1991). A implementação dos serviços representa a tecnologia da aplicação que deve poder ser facilmente acessada através dos recursos de configuração. Com isto, conseguimos re-usar uma mesma tecnologia para fins específicos, ampliando o domínio de atuação das aplicações. Este é um fato importante tendo em vista a crescente demanda por software e seu alto custo de desenvolvimento.

Corno estratégia de configuração, propomos o acoplamento de serviços que permitem especificar os atributos associados às entidades do modelo. Isto porque, em aplicações técnico-científicas, estes atributos caracterizam a semântica do modelo matemático utilizado. Os mecanismos de configuração apresentados são incorporados às representações de modelos

3

hierárquicos, criando uma ferramenta adequada para modelagem bidimensional. Porém, estes serviços de configuração podem ser acoplados a aplicações diversas, desde que nestas aplicações possamos associar atributos às entidades para caracterizar sua semântica.

Os principais desafios em oferecer serviços de configuração é assegurar alto nível de abstração para facilitar o trabalho dos usuários configuradores (Krueger, 1991) e impedir que conceitos semânticos sejam incorporados às tecnologias implementadas pelas aplicações, limitando o escopo de sua aplicabilidade. Para tanto, identificamos os diversos agentes envolvidos no desenvolvimento da aplicação final e propomos um conjunto de regras para comunicação entre a aplicação e o ambiente de configuração que orientam o desenvolvimento de aplicações configuráveis. Os serviços oferecidos buscam minimizar as tarefas de programação procedimental por parte dos usuários configuradores, que não são profissionais em computação, e oferecem meios para que os atributos sejam especificados de forma descritiva, que nos parece mais natural para esses profissionais.

Por fim, observa-se que as tarefas de configuração de aplicações gráficas invariavelmente envolvem acesso a objetos de interface. É comum o usuário configurador ter necessidade de projetar diálogos para interação com o usuário final. A criação de interfaces com os recursos usuais de programação é não trivial. Para dar suporte adequado a realização destas tarefas, propomos uma ferramenta para criação de interfaces gráficas interativas que oferece acesso facilitado tanto a objetos de interface convencionais quanto a objetos gráficos. O acesso a objetos gráficos, e a possibilidade de programação dos eventos sobre eles incidentes, possibilita a criação de objetos de interface próprios, direcionados para o domínio da aplicação.

1.1 Histórico

Todos estes requisitos, desde a representação de modelos hierárquicos até a cnaçao de interfaces interativas, surgiram de diversos programas gráficos interativos para uso industrial que temos desenvolvido dentro do convênio do TeCGraf (Grupo de Tecnologia em Computação Gráfica da PUC-Rio) com o CENPES/PETROBRAS. De fato, as propostas aqui apresentadas estão dentro de uma linha de pesquisa que tem diversas ramificações. A Figura 1.1 ilustra as diferentes pesquisas desenvolvidas nesta área.

A representação de subdivisões espaciais hierárquicas foi originalmente proposta por Martha (1989), que apresentou uma estratégia para representação de modelos de subdivisões hierárquicas usando a estrutura radial edge (Weiler, 1986). A estratégia porposta por Martha (1989) foi aplicada em sistemas bidimensionais para geração de malhas de elementos finitos (Campos, 1991; Vianna, 1992). A representação de subdivisões planares foi tratada pela implementação da estrutura half edge (Mãntylã, 1988) iniciada por Cavalcanti et ai. (1991) e concluída por Ceies et ai. (1993). Essa estrutura tem sido usada no desenvolvimento de diversas pesquisas, e foi empregada como base de dados no desenvolvimento de diversos aplicativos, onde destacamos o gerador de malhas de elementos finitos bidimensionais Mtool

(TeCGraf, 1992) e o simulador de transformações geológicas Recon (Ferraz, 1993). A evolução do trabalho feita por Calvacanti (1992) trata de problemas para criação e manipulação de Subdivisões Espaciais.

4

Por outro lado, a crescente demanda por software re-usáveis, e de meta-ferramentas que facilitassem o desenvolvimento de programas, deu origem à linha de pesquisa iniciada com o desenvolvimento do sistema para entrada de dados ED (Figueiredo et al., 1992). As limitações deste sistema para programação estruturada e a necessidade de criarmos uma linguagem para descrição de objetos (necessária para o desenvolvimento do programa PGM (TeCGraf,1994)) inspirou o desenvolvimento da linguagem Lua (Figueiredo et ai., 1994; lerusalimschy et. ai, 1995).

Os serviços de configuração oferecidos (Ceies e Gattass, 1995) e a ferramenta para criação de interfaces - EDG (Ceies et ai., 1995) - acessam o sistema de interface IUP (Levy, 1993) e representam especializações da linguagem Lua. Lua é uma linguagem para extensão de aplicações que provê os recursos usuais de uma linguagem procedimental e permite a especialização da linguagem para domínios específicos. Estas especializações baseiam-se em poderosos mecanismos para descrição de dados e na possibilidade de incorporar semânticas próprias à sintaxe da linguagem. A utilização de Lua como suporte para acesso programável às tecnologias implementadas pelas aplicações uniformiza a forma de configuração das aplicações e evita a proliferação de pequenas linguagens de configuração.

A proposta para representação de subdivisões planares hierárquicas HPS (Ceies, 1994a) é uma evolução da estrutura para subdivisões simples e, aliada ao ambiente de configuração proposto, representa uma base adequada para o desenvolvimento de modeladores configuráveis de representações hierárquicas bidimensionais. Na Figura 1. 1 o escopo desta tese está definido pela área sombreada.

1.2 Organização do texto

O texto desta tese está estruturado em cinco capítulos. Após esta introdução, o Capítulo 2 discute a representação de subdivisões planares hierárquicas. Analisam-se estratégias anteriormente utilizadas e apresenta-se uma proposta para representação do modelo hierárquico numa única base de dados. Apresenta-se também uma interface abstrata para gerenciamento da estrutura.

O Capítulo 3 discute configuração de aplicações como estratégia de re-uso de software e os problemas relacionados com o acesso às tecnologias implementadas pelas aplicações. Propõe­se um sistema para configuração baseado na especificação dos atributos associados às entidades do modelo. Esta proposta de configuração prevê a incorporação da semântica por parte dos atributos, permitindo que o usuário configurador valide semanticamente as edições realizadas sobre o modelo. O Capítulo 3 apresenta, ainda, uma ferramenta para para criação de interfaces gráficas interativas, provendo acesso facilitado a objetos de interface convencionais e objetos gráficos. A ferramenta permite o tratamento dos eventos sobre os objetos de interface e gráficos e, com isto, cria um suporte adequado para criação de objetos de interfaces próprios.

Por fim, o Capítulo 4 expõe as conclusões deste trabalho e enumera possíveis trabalhos futuros que representam continuidades das pesquisas aqui realizadas.

casca ram(lflJ, 1991

casca Vimmn, 1992

...

Radial Edge Wrilrr. l98fi

Franc 30 AJurrh". / 9H9

\ SE

Cm·ofcanti, 19?1

/

HED . ' 1991) Cm·alcm1!1 e! li.,

\ HED

Cf'lr.~ er ai., 1991

/+ Recon

Frrm:, /993

ED 1 1991 Fifl;llf'iM'rlfl el n .,

.. . Figura 1. 1. is . has de pesquisa . . H. tórico das hn

ConfigurnçlJo l99J Ct/t,,,. Garta.u,

' :';.: ~

...

IUP f.t'I'}'. /99J

"'-.~.

Lua llm,chl' ri oi., 1991 /tMH'1 · ·

•••

2. Gerenciamento de Subdivisões Planares Hierárquicas

Diversas aplicações baseiam-se na representação de subdivisões planares. Nesta área, incluem-se os geradores de malhas de elementos finitos e os programas para representação de mapas cartográficos. Uma característica marcante desses aplicativos é a necessidade de editar a subdivisão planar representada e consultar as relações de adjacências entre as entidades existentes.

Devido a esse alto grau de interatividade, é necessano que a subdivisão planar seja representada por uma estrutura que permita a manipulação do modelo de maneira eficiente e consistente (sem invalidar a representação). Por isso, subdivisões espaciais têm sido representadas pelas estruturas de dados topológicas da área de Modelagem de Sólidos (Wawrzynek, 1987; Martha, 1989; Cavalcanti, 1992).

Observa-se, no entanto, que em muitas dessas aplicações, o modelo completo é formado por diversas subdivisões espaciais dispostas hierarquicamente. É o caso típico da representação de mapas cartográficos com instanciação de países, estados e municípios; ou da representação de modelos de elementos finitos onde diferentes regiões são discretizadas em elementos finitos.

A implementação de sistemas similares, com uso de estruturas topológicas convencionais, precisam criar artifícios para garantir a representação destas hierarquias. As seções subseqüentes apresentam uma proposta para o gerenciamento de subdivisões planares hierárquicas, utilizando uma única base de dados. Esta base única é manipulada por um conjunto pré-definido de operadores que garantem a consistência da representação nas tarefas de edição. Assegura-se também a obtenção das relações de adjacências de maneira eficiente, através de acessos diretos ou buscas locais. A estrutura de dados é gerenciada por uma ferramenta que abstrai as complexidades de acesso aos operadores básicos e implementa uma interface com operações de nível mais elevado, tais como inserção e eliminação de arestas e vértices. A arquitetura de implementação permite que aplicações clientes incorporem, às entidades da subdivisão, características semânticas próprias. Dessa forma, consegue-se uma base adequada para o desenvolvimento de aplicações que instanciam subdivisões planares hierárquicas.

2.1 Conceituação de hierarquia e multi-resolução

Antes de nos aprofundarmos na discussão sobre representações hierárquicas, é preciso definir o escopo do conceito de hierarquia explorado neste trabalho. O conceito de hierarquia também é usado para definir multi-resolução. Muitos trabalhos na área de sistemas geográficos de informação (GIS) propõem o tratamento de hierarquia para trabalhar com um mesmo mapa em diferentes resoluções (Egenhofer et ai., 1994; Puppo e Dettorí, 1995). Tipicamente, consegue-se multi-resolução topológica fazendo com que as entidades (células) topológicas de níveis hierárquicos superiores representem agregações de entidades topológicas de níveis inferiores. Deste modo, num mapa cartográfico, a fronteira de um dado estado pode ser representado por entidades topológicas de diferentes níveis, variando c-0nforme a resolução solicitada (Brueger e Frank, 1989).

1

Diferente dessas propostas da área de GIS, associamos uma caracterização semântica a cada nível hierárquico. Direcionamos o enfoque para a representação de níveis de subdivisões com semânticas distintas relacionados hierarquicamente. Como base para representação destes modelos, exploramos as estruturas de dados utilizadas para representação da fronteira (B-rep) de sólidos na ârea de Modelagem de Sólidos.

A obtenção de multi-resolução geométrica é ortogonal à representação de hierarquias topológicas. Multi-resolução geométrica pode ser representada via os atributos geométricos associados às entidades topológicas. Por exemplo, através da representação de curvas usando strip trees (Ballard, 1981 ), pode-se associar uma resolução geométrica a cada nível hierárquico e, com isto, conseguir que uma mesma entidade topológica tenha resoluções geométricas distintas em diferentes nívéis.

2.2 Representação de hierarquia com estruturas convencionais

Nesta seção, discute-se a representação de subdivisões hierárquicas com a utilização das estruturas topológicas convencionais para representação da fronteira de sólidos. Analisam-se duas propostas, ambas já empregadas no desenvolvimento de aplicações (com uso industrial) para geração de malhas de elementos finitos.

O emprego do método dos elementos finitos, nas simulações numéricas da área de engenharia, exige que o domínio do problema seja discretizado em pequenos (finitos) elementos (Gattass et ai., 1991 ). Muitos dos métodos empregados para a geração automática desta discretização impõem restrições topológicas às áreas de mapeamento. Mapeamentos transfinitos, por exemplo, só podem ser empregados, nos casos 2D, em regiões topologicamente equivalentes a triângulos ou retângulos.

Estas restrições topológicas, associadas à propna natureza heterogênea dos modelos (representação de diferentes materiais e/ou propriedades tisicas, geométricas e analíticas), caracterizam diferentes níveis hierárquicos de subdivisão. O modelo é constituído por diferentes regiões (com suas respectivas propriedades), que são subdivididas em sub-regiões para viabilização dos mapeamentos. Estes mapeamentos discretizam as sub-regiões em elementos finitos.

Nos trabalhos de Martha (1989) e Campos (1991 ), o modelo para geração da malha de elementos finitos é dividido em quatro níveis (considerando o caso 20). O primeiro nível contém o modelo geométrico, representando as diferentes regiões do domínio. No próximo nível, encontra-se o modelo de sub-regiões formado pelas subdivisões necessárias para emprego dos mapeamentos. No terceiro nível, encontra-se o nível das subdivisões das arestas das sub-regiões. Por fim, existe o modelo da malha propriamente dita, formando o quarto nível hierárquico (Figura 2.1 ).

8

o (a) (b)

(e) (d)

Figura 2.1: Níveis hierárquicos dos modelos de elementos finitos (Carvalho et ai., 1990):

(a) geometria; (b) sub-regiões; (e) subdivisões; (d) malha.

Para viabilizar a representação computacional destes modelos, Martha e Campos utilizaram a estrutura de dados topológica face-edge (radial-edge no caso 3D), inicialmente apresentada por Weiler (1986). A estrutura face-edge foi projetada para a representação de sólidos manifold. Trabalhando sobre a representação do grafo planar destes sólidos, consegue-se, com esta estrutura e similares, suporte para subdivisões planares e, portanto, para modelos bidimensionais de malhas de elementos finitos (Wa"WTZynek, 1987). Para cada nível hierárquico proposto por Martha e Campos, existe uma estrutura de dados associada. Como estes quatro níveis guardam entre si uma correspondência hierárquica (todas as entidades topológicas de níveis superiores devem, necessariamente, estar contidas nos níveis inferiores), as quatro estruturas de dados não podem ser independentes. Para garantir esta correspondência, criaram-se ponteiros entre entidades dos níveis hierárquicos adjacentes. Uma aresta do nível das sub-regiões, por exemplo, tem um ponteiro que indica qual a aresta correspondente no nível da geometria, a qual pode ou não existir. Com esta amarração, qualquer evento que ocorre em um determinado nível pode ser reportado aos demais, sendo portanto possível a manutenção da consistência do modelo.

A evolução dessa proposta eliminou o nível das subdivisões, tratando-as apenas como atributos das fronteiras das sub-regiões, tendo em vista a minimização do espaço de memória necessário para seu armazenamento (Vianna, 1992).

A estruturação em diferentes níveis hierárquicos dessas propostas trouxe uma significante contribuição na concepção da arquitetura dos sistemas de geração de malhas, enfatizando as diversas etapas na construção do modelo final (Carvalho et al., 1990). Do ponto de vista da estruturação dos dados, no entanto, essas propostas apresentam dois aspectos negativos. O primeiro diz respeito à duplicação de representações de entidades topológicas idênticas em

9

diferentes mve1s hierárquicos, tendo em vista que os modelos inferiores englobam, obrigatoriamente, os modelos superiores.

Um segundo aspecto mais importante está no grau de complexidade da manutenção da consistência. Embora cada nível seja representado por uma estrutura de dados já consagrada na área de modelagem e, portanto, bastante conhecida, a interligação dos diversos níveis, via ponteiros cruzados, exige uma implementação complexa, já que não se tem uma única base de dados para a representação do modelo como um todo. Com isto, perde-se o grande beneficio do uso dos operadores de Euler (Baurngart, J 972) para edição das subdivisões planares, pois eles não garantem a consistência entre os níveis hierárquicos. .

Baseado nestas experiências, e buscando atender a um pedido do Centro de Pesquisa da PETROBRÁS (CENPES) para o desenvolvimento de um gerador de malhas bidimensionais, propusemos e implementamos o modelo do gerador de malhas MTool (TeCGraf, 1992). Nesse desenvolvimento, procuramos minimizar as dificuldades do tratamento hierárquico, reduzindo a profundidade da hierarquia. Essa proposta simplifica o modelo e mantém um único nível representando a geometria e as sub-regiões (como se as sub-regiões fizessem parte da geometria). O restante é tratado como atributos das entidades topológicas. Assim, subdivisões das arestas são tratadas como atributos das arestas e as malhas geradas são atributos das regiões. Isto é, cada malha de cada sub-região é representada por uma estrutura de dados independente, que é atribuída à face do nível da geometria.

O modelo do MTool, entretanto, dificulta a compatibilização de malhas em regiões adjacentes. Para tratar esta compatibilidade, o programa faz uso de buscas geométricas, perdendo mais uma vez a garantia de consistência oferecida pelos operadores topológicos.

Portanto, ambas as propostas, embora funcionais e possíveis, apresentam dificuldades devido à ausência de uma formalização da hierarquia que permita o uso de uma única base de dados· para a representação do modelo hierárquico como um todo. Uma proposta para o gerenciamento destes modelos hierárquicos é apresentada nas seções subseqüentes.

2.3 Propriedades de subdivisão planar hierárquica

Por subdivisão planar entende-se uma partição do plano induzida por um mapeamento de um grafo planar (Preparata e Shamos, 1990). Nesta partição, identificamos três entidades topológicas: vértice, aresta e face. Seguindo as definições de Cavalcanti (1992), um vértice é uma entidade, de dimensão O, que corresponde a um único ponto do espaço !R2

• Não podem existir dois vértices com a mesma localização geométrica. Uma aresta é uma entidade, de dimensão 1, que corresponde a um segmento de curva homeomorfo a um segmento de reta. A fronteira de uma aresta é formada por dois vértices que são ditos ligados. Um ciclo é um subconjunto conexo e ordenado de vértices e arestas alternadamente. Um ciclo pode consistir de um único vértice, sendo chamado, neste caso, de ciclo pontual. Uma face é uma entidade, de dimensão 2, que corresponde a um subconjunto conexo do !R2

. Uma face é orientada e sua fronteira é composta por um ou mais ciclos.

Uma subdivisão planar guarda as seguintes propriedades: (í) a interseção de duas arestas ou é vazia ou é um vértice; (ii) a interseção de duas faces ou é vazia ou é um conjunto de vértices

10

ou é um conjunto de arestas e vértices. A Figura 2.2 mostra um exemplo·e um contra-exemplo de uma subdivisão planar.

@.

(a) (b)

Figura 2.2: (a) subdivisao planar; (b) partição do plano que não é subdivisão planar.

Múltiplas subdivisões planares podem estar relacionadas hierarquicamente: para tal devem satisfazer ao requisito de que toda entidade topológica de um nível inferior está inteiramente contida em uma entidade topológica do nível superior. Com isso, o conjunto de faces de um nível inferior que interceptam uma dada face/do nível superior está contido em/, e induzem uma subdivisão planar de f As diversas entidades topológicas que compõem um modelo de subdivisões planares hierarquicamente dispostas podem estar em diferentes níveis de hierarquia, de tal forma que cada nível deva corresponder a uma subdivisão planar válida, e todas as entidades topológicas de níveis hierárquicos superiores devem estar representadas (subdivididas ou não) nos níveis inferiores. A essas múltiplas partições do plano damos o nome de subdivisão planar hierárquica.

Formalmente, dizemos que uma seqüência de subdivisões planares define uma hierarquia quando cada entidade topológica de uma dada subdivisão está inteiramente contida em alguma entidade de cada subdivisão precedente. Uma entidade que pertence a um dado nível pode também exisitr no nível seguinte ou ser substituído por um conjunto de entidades "filhas".

Seja N um nível na hierarquia de um modelo. Denotamos por J\r+ o nível hierárquico

imediatamente acima de N e por N- o nível imediatamente abaixo. Dizemos que uma entidade

topológica t é definida no nível N quando t pertence a N e não a Af+. As entidades topológicas do modelo que propomos podem ser definidas em um nível hierárquico qualquer satisfazendo as seguintes propriedades:

• Se/é uma face definida em N, então existe uma facef'pertencente af\1+ que contém/

• Se/ é uma face pertencente a N, então ou/pertence a N- ou existe um conjunto de faces

definidas em N- cuja união corresponde a/

• Se e é uma aresta definida em N, então ou existe uma aresta e' pertencente a J\T+ que

contém e ou existe uma face f' pertencente a~ que contém e.

11

• Se e é uma aresta pertencente a N, então ou e pertence a!\'" ou existe um conjunto de

arestas definidas em !ir cuja união corresponde a e.

• Se v é um vértice pertencente a N, então v pertence a /ir.

A Figura 2.3 ilustra um modelo bastante simples de subdivisões planares com dois níveis hierárquicos. O primeiro nível hierárquico define a fronteira externa do modelo, tendo, portanto, duas faces (a interna, limitada, e a externa, ilimitada), quatro arestas e quatro vértices. O segundo nível subdivide a face interna do primeiro nível em duas outras faces, sendo representado, então, por três faces, sete arestas e seis vértices.

Observa-se que, no exemplo, as duas arestas inclinadas do nível 1 são mantidas no nível II, enquanto as horizontais são subdivididas. Portanto, para evitar duplicidade, as arestas inclinadas devem ser as mesmas, tanto no nível 1 como no nível II. Por outro lado, as arestas horizontais representadas no nível 1 não são entidades do nível ll, mas aparecem quatro novas arestas inexistentes no nível superior. As entidades topológicas desse exemplo estão identificadas na Figura 2.3.

v2 e1 v1

f O e f 1 e4

v3 e3 v4

v2 e6 v5 e5 v1

f O e2 f 2 f 3 e4

e9

v3 e7 v6 eB v4

Figura 2.3: Entidades de um modelo hierárquico.

No nível !, a face fl é' delimitada pela seguinte seqüência de vértices e arestas: vl-el-v2-e2-v3-e3-v4-e4. Já no nível II, a facej2 é delimitada por d-e6-v2-e2-v3-e7-v6-e9 e a facej3 por vl-e5-v5-e9-v6-e8-v4-e4. Além destas informações, identifica-se que as facesf2 e j3 são subdivisões da facefl, assim como as arestas e5, e6 e e7, e8 são subdivisões de ele e3, respectivamente.

13

As entidades topológicas são divididas em duas classes: Physical e Abstract. Dentro da classe Fisical encontram-se as entidades topológicas que têm representação tisica: Face, Edge e Vertex. Essas entidades podem ser acessadas pelo cliente e portanto têm características comuns que devem ser exploradas. As entidades abstratas, Loop e Use, não são diretamente acessadas pelo cliente e não são fisicamente representadas. Elas são necessárias apenas para a obtenção das relações de adjacências entre as entidades fisicas.

As classes Face, Edge e Vertex têm agregadas classes que caracterizam as respectivas propriedades geométricas: Bounding Box, Curve e Point. A classe Bounding Box armazena o menor retângulo que envolve a face e é usada para agilizar a localização de pontos sobre o modelo; a classe Curve descreve as características geométricas da aresta e pode ser decomposta entre os diferentes tipos de curva: poligonal (Polygonal), arco de elipse (Are), curva de bezier (Bezier), etc. Esta estruturação facilita o acoplamento .de novas classes de curvas, sendo necessário apenas implementar um conjunto pré-definido de métodos. Por fim, a classe Point representa a posição geométrica do vértice; sua redefinição pode, por exemplo, permitir a representação de subdivisões em planos no espaço 30.

Observa-se que, em muitas aplicações, a definição geométrica das arestas representa uma significativa quantidade de infonnação (e.g., digitalização de mapas cartográficos). Nesses casos, pode-se explorar a representação da hierarquia do modelo, fazendo com que as geometrias das arestas de níveis hierárquicos inferiores sejam definida através de valores simples que caracterizam as partes das geometrias das aresta arestas de níveis superiores que devem ser consideradas.

As entidades geométricas (Bounding Box, Curve e Point) têm agregadas classes que caracterizam os atributos gráficos para representação visual das entidades tisicas (Fill, Frame e Mark, respectivamente). A existência dessas classes de atributos gráficos é importante, pois permite que a aparência gráfica das primitivas seja configurada por agentes externos, sem perder o encapsulamento das entidades topológicas e geométricas.

2.4.2 Estruturação das entidades

As entidades topológicas presentes no modelo são dispostas na estrutura de dados seguindo uma hierarquia, onde as entidades de níveis inferiores representam a fronteira das entidades dos níveis superiores. A Figura 2.5 esquematiza esta disposição, que é a mesma das encontradas nas estruturas topológicas convencionais (Weiler, 1986). No topo, representa-se o modelo, ou uma lista de modelos independentes entre si. Um modelo é constituído por faces, arestas e vértices. As faces são delimitadas por laços (loops) que são definidos por uma seqüência de arestas. Cada aresta é apoiada em dois vértices. Para viabilizar a representação das relações de adjacências, representam-se, explicitamente, os usos de cada aresta (cada aresta tem dois usos) (Mãntylã, 1988).

Para tratar a representação de vértices isolados no interior de faces, os laços internos das faces podem ser definidos por vértices que não têm usos de arestas associados, i.e., não existem arestas incidentes nesses vértices.

12

A face externa do nível 1 não é subdividida e, portanto, também pertence ao nível II. Entretanto, nota-se que o conjunto de arestas que definem sua fronteira interna é diferente nos dois níveis. No nível 1, a fronteira interna da face externa é definida por vl-e4-v4-e3-v3-e2-v2-el, enquanto que no nível li é definida por vl-e4-v4-e8-v6-e7-v3-e2-v2-e6-v5-e5.

2.4 Representação de subdivisões planares hierárquicas

Nesta seção, apresentamos uma estrutura de dados para representação de subdivisões planares hierárquicas que guardam as propriedades definidas na seção anterior. A estrutura proposta, chamada HPS (Hierarchical Planar Subdivision), assegura a não duplicidade de entidades topológicas idêntica$ em níveis hierárquicos distintos, e representa as relações de adjacências entre as entidades topológicas de um nível hierárquico e entre entidades topológicas de níveis hierárquicos adjacentes. Isso garante a suficiência topológica para a representação não ambígua do modelo completo numa única base de dados.

2.4.1 Classes das entidades topológicas e geométricas

A estrutura de dados HPS foi implementada segundo o paradigma de programação orientada a objetos. O uso deste paradigma trouxe diversos beneficios. Entre eles destacam-se a modularidade e o encapsulamento obtidos, a possibilidade de tratar entidades afins de maneira uniforme, e, principalmente, a facilidade de futuras expansões do sistema para domínios mais

abrangentes.

As entidades topológicas, e suas respectivas representações geométricas, são estruturadas em classes. As classes geométricas têm agregadas classes de atributos gráficos para representação visual das entidades. A Figura 2.4 ilustra a hierarquia de classes para representação das

entidades.

Figura 2.4: Classes das entidades topológicas e geométricas.

14

modelo

laço

uso-~ - aresta

'---~-~---'

----t vértice

Figura 2.5: Disposição hierárquica das entidades topológicas.

Em contraste com as estruturas convencionais, as faces e arestas dos modelos são armazenadas em árvores, em vez de listas encadeadas. As estruturas de árvores são necessárias para representar as situações onde faces ou arestas de níveis superiores são subdivididas em níveis inferiores. Para ilustrar, a Figura 2.6 mostra um esquema da representação interna das entidades do modelo da Figura 2.3.

faces: fO- f1 1

f2-f3

arestas: e1 - e2- e3- e4 - e9 1 1

e5-e6 e7-e8

vértices: v1 - v2 - v3 - v4 - v5 - v6

Figura 2.6: Disposição das entidades em árvores e listas.

Observa-se que as arestas de níveis inferiores podem estar representadas de duas formas: quando surgem devido a subdivisões de arestas do nível superior, as entidades são colocadas como "filhas" na árvore; quando não têm correspondência nos níveis superiores (estão contidas em faces superiores), elas aparecem como nós primários da árvore do modelo. As faces recebem tratamento análogo, com uma diferença: somente as faces do nível mais superior serão dispostas como nós primários, já que todas as faces inferiores serão,

IS

obrigatoriamente, subdivisões de faces já existentes. Os vértices, por serem entidades indivisíveis, aparecem em estruturas de listas convencionais.

A Figura 2.7 ilustra as estruturas para implementação das entidades topológicas que compõem .o modelo. A estrutura da entidade modelo tem ponteiros para as árvores de faces e arestas, e para a lista de vértices que o compõem. Armazena-se ainda o número de níveis hierárquicos representados, além do encadeamento necessário para inseri-lo na lista global de modelos.

Modelo faoe_tree

re e:Jge_tree

,. ve-tex_lis

num le.lfi next ..

-e prev

..... Face ..- .

~ otr ..

/oot_prt - . Laço

IDDP. li& Laço faoe_ptr _.. 1-e parent

faoe _ptr _.!: 1-- ure_ptr next • ····-~7--+-- ----i

ure_ptr loop_ptr prev ----------<- ---t-.. loop_ptr next" o

' chi/d next __.! prev= O

.... prev •

.... Aresta ure1 otr - ...,. Uso .

~' ure2_prt ,.

Uso e:lge__ptr -'e parent

e:Jge_ptr loop_ptr . -: next Vfrlexytr loop_ptr • ~

prev Vfrlex_ptr • nexts • __[

- . 1-' • chi/d ..---e-> nexts =- prevs

t 1-' -l

·-1 .... prevs

Vértice ure_ptr

- - -~-----( -----f loop_ptr

next •

i-.. -.--1 prev

Figura 2.7: Diagrama das estruturas de cada entidade.

16

A estrutura da entidade face tem um ponteiro para o modelo ao qual pertence. Existem também um ponteiro para o laço externo da face (nulo para as faces externas, ilimitadas) e um ponteiro para uma lista de eventuais laços internos. A estrutura da face possui também os ponteiros para seu armazenamento na estrutura de árvore do modelo.

A estrutura da entidade laço possui um ponteiro para a face a qual pertence, e um ponteiro para a entidade adjacente, que pode ser um vértice (caso do laço ser composto por um único vértice) ou um uso de aresta (caso do laço ser composto por arestas).

A entidade topológica uso de aresta exige uma apresentação mais detalhada. A entidade tem um ponteiro para a aresta a que pertence e um ponteiro para o vértice de origem. Têm-se, ainda, um ponteiro para o laço a que pertence e elos de ligação para o próximo e o anterior usos de arestas desse laço. A representação da hierarquia requer que sejam· usados elos múltiplos. Como uma mesma aresta de nível superior pode existir em níveis inferiores, os usos de arestas podem ter tantos elos de ligação para a seqüência do laço quantos forem os níveis inferiores ao nível da aresta (inclusive). Para exemplificar. considera-se o uso associado à aresta e2 (Figura 2.3). Se estiver sendo percorrido o laço associado à facefJ (nível superior), o próximo uso do laço corresponde ao associado à aresta e3 (sentido anti-horário). No entanto, se estiver sendo percorrido o laço associado à face f2 (nível inferior), o próximo uso está associado à aresta e 7. Observa-se que esta estratégia é adequada, pois garante que usos de arestas de níveis inferiores tenham poucos elos, até o nível mais inferior onde só há necessidade de elos simples. Isto é razoável, pois o número de entidades deste nível tende a ser supenor aos demais, já que níveis inferiores representam refinamentos de níveis supenores.

A estrutura da entidade aresta tem dois ponteiros para os usos que a formam e os ponteiros para seu armazenamento na árvore de arestas do modelo.

Por fim, a estrutura da entidade vértice tem um ponteiro para a entidade adjacente, que pode ser o laço associado de nível mais inferior (caso do vértice não ter arestas incidentes) ou um uso associado do nível mais inferior (caso do vértice ter arestas incidentes). Observa-se que a entidade vértice pertence a todos os níveis inferiores ao nível de sua definição (inclusive). A estratégia de colocar um úníco ponteiro para o laço ou o uso do nível mais inferior é suficiente, pois podemos obter os respectivos laços ou usos associados dos demais níveis por relações de adjacências (seção 2.4.4). Para evitar essa busca na obtenção de laços ou usos superiores, pode-se implementar os vértices também com elos múltiplos para os laços ou usos de cada nível.

Adicionalmente, cada uma das entidades topológicas face, aresta ou vértice tem um indicador do nível no qual é definida. Este indicador de nível permite dispor as diversas entidades dos diferentes níveis em estruturas de dados comuns (e.g., vértices de diferentes níveis podem estar armazenados numa mesma lista). Outro aspecto importante é que não há duplicação de entidades idênticas em níveis hierárquicos não adjacentes. É possível, por exemplo, uma determinada face de um nível, digamos nível I, ser subdividida em diversas faces no nível lll. A face superior terá faces "filhas" de dois níveis abaixo, indicando que a face considerada no nível intermediário (no caso, o nível II) é idêntica à face superior e, portanto, não representada. Apenas se ocorrer uma operação que atue diretamente sobre a entidade não representada, há necessidade de ser feita uma cópia da entidade até então idêntica. Uma

17

desvantagem de colocar as entidades de níveis diferentes em estruturas comuns é que pode ser necessário percorrer todas as entidades do modelo para enumerar as entidades de um determinado nível.

Por fim, para possibilitar a implementação de mecanismos de persistência do modelo, existe um identificador (representado por um número inteiro) associado a cada uma das entidades face, aresta e vértice (seção 2.5.3).

Estas representações garantem a obtenção das relações de adjacências entre as entidades topológicas, conforme será discutido na seção 2.4.4.

2.4.3 Operadores básicos

Com a finalidade de garantir a manutenção da consistência durante a edição do modelo, definimos um conjunto de operadores básicos responsáveis pelas alterações na estrutura de dados. Nas estruturas topológicas não hierárquicas. este conjunto de operadores é constituído pelos operadores de Euler (Baumgart, 1972). Salientamos, ainda, que uma estrutura pode ser descrita por uma série de operadores necessários para reconstruir o modelo.

Aqui, também continuam aplicáveis os operadores de Euler em cada nível hierárquico. A diferença em relação às estruturas convencionais é que estes operadores podem atuar em diversos níveis ao mesmo tempo. Por exemplo, uma entidade inserida num nível superior também pode pertencer aos níveis inferiores. Observa-se que uma mesma e única entidade é adicionada em diversos níveis (daí a necessidade de haver múltiplos elos nos usos superiores). A questão que surge diz respeito à determinação dos níveis em que cada operador deve atuar. Uma extenção natural dos operadores de Euler convencionais seria exigir que o nível hierárquico de atuação do operador fosse explicitamente especificado. Por razões de engenharia de software, optamos por uma estratégia distinta: minimizamos as mudanças nas implementações destes operadores convencionais e utilizamos operadores adicionais que viabilizam a troca de nível de atuação das operações. Desta forma, os níveis de atuação destes operadores de Euler estendidos podem ser determinados implicitamente, pois as operações agem somente sobre entidades definidas no próprio nível de atuação do operador. Com isto, os códigos de operadores de Euler já existentes para aplicações não hierárquicas podem ser facilmente reaproveitados. A seguir, discute-se cada um dos operadores básicos necessários

· para edição do modelo hierárquico.

Os operadores de Euler escolhidos para implementação da estrutura HPS foram (Figura 2.8):

• mvfm (make ver/ex, face and model): necessário para a inserção do primeiro vértice do modelo;

• mvr (make ver/ex and ring): necessário para inserir um vértice no interior de uma face;

• mvse (make vertex, sp/ít edge): necessário para inserir um vértice sobre uma aresta;

• mekr (make edge. kill ring): necessário para inserir uma aresta que destrói um laço interno de uma face;

• mesf (make edge, split face): necessário para inserir uma aresta que divide uma face existente.

18

,,/ mvfm - - • • / 1 '\. ..

o mvr G • .. ~ mvse '---. .. .. 8 mekr G .. ..

o mesf Çj .. .. ~

CJ cf '-• .. ... ,. -..

~ ce

~ • ... .

~"- cep

~ • .. Figura 2.8: Quadro dos operadores básicos.

A estes operadores aliam-se os respectivos operadores inversos. Neste conjunto de operadores, três estão associados à inserção de vértices no modelo e dois estão associados à

inserção de arestas. Com exceção do operador primário (mvfm) que atua em todos os níveis do modelo (e obrigatoriamente é o primeiro operador a ser aplicado), os níveis hierárquicos de atuação de cada um dos demais operadores são determinados pela entidade sobre a qual a inserção será feita. Assim, os operadores mvr, mekr e mesf têm seus níveis de atuação determinados pelo nível da face sobre a qual eles atuam: o nível superior de atuação

19

corresponde ao nível da face (e as entidades criadas terão este nível); o nível inferior de atuação é o nível imediatamente superior ao nível das faces "filhas" da face em questão, ou o nível mais inferior, no caso da face não ter "filhas".

Analogamente, o operador mvse tem seus níveis de atuação determinados pela aresta sobre a qual o vértice será inserido: o nível superior de atuação corresponde ao nível da aresta; o nível inferior de atuação é o nível imediatamente superior ao nível das arestas "filhas" da aresta em questão, ou o nível mais inferior, no caso da aresta não ter "filhas".

Observa-se, ainda, que o fato de forçar a aplicação do operador primário (mvfm) em todos os níveis (sendo que as entidades criadas nesta operação são do nível mais superior) garante que todas as faces de níveis inferiores serão obrigatoriamente "filhas" de faces superiores, já que a face inicialmente criada cobre todo o plano.

Para possibilitar a mudança de nível de atuação dos operadores, criamos dois operadores: cf (copy face) e ce (copy edge). Estes operadores efetuam cópias de entidades superiores em níveis inferiores. Eles são necessários para viabilizar operações em níveis inferiores. Por exemplo, para subdividir uma face no nível inferior, faz-se, inicialmente, uma cópia da face no nível no qual se deseja atuar e, sobre esta cópia, aplica-se o operador mesf. Observa-se que estes operadores ( cf e ce) são os dois únicos operadores para os quais deve-se especificar explicitamente o nível de atuação, isto é, em que nível a cópia será realizada. Observa-se, ainda, que estes operadores criam situações temporárias para a edição do modelo. As cópias das entidades são feitas para que as operações subsequentes, que atuam sobre estas cópias, possam ser efetuadas. A estrutura impede a permanência de cópias de entidades no modelo. Por isso, existem os operadores inversos que permitem desfazer cópias de entidades idênticas.

Por fim, para possibilitar a inserção de arestas em níveis superiores que cobrem arestas já existentes em níveis inferiores, criamos o operador cep (change edge parent) que possibilita redefinir de que aresta uma outra ·será "filha". Verifica-se que, antes da operação, as arestas que foram cobertas por uma superior não eram "filhas" de nenhuma outra aresta, e, após a inserção, devem ser consideradas "filhas" da aresta inserida.

Para exemplificar a atuação dos operadores, consideremos o modelo de três níveis hierárquicos ilustrado na Figura 2.9. Suponhamos que se deseja inserir uma aresia no nível superior, definida pe!O segmento de reta que liga os vértices vi e v2. A inserção desta aresta deve ser feita através do operador mesf (make edge, sp/if face). Este operador atua nos níveis superior e intermediário, pois a face que será subdividida pertence ao nível superior e tem como "filhas" faces do nível inferior (a mesma face do nível superior pertence também ao nível intermediário). Observa-se que esta inserção de aresta é suportada pelos operadores, pois a aresta inserida é totalmente coberta por arestas definidas no nível inferior. Após a inserção da aresta, atualiza-se a hierarquia das arestas através do operador cep (change edge parent), pois as arestas e., eb e ec passam a ser "filhas" da nova aresta inserida.

Se, ao invés de fazermos a inserção da aresta no nível superior, desejássemos inseri-la no nível intermediário, seria necessário, antes de acionar o operador mesf (que, neste caso, só atuaria no nível intermediário), fazer uma cópia temporária da face superior, através do operador cf (copy face), e, então, inserir a aresta sobre esta nova face.

20

v,

"'

Figura 2.9: Modelo com três níveis hierárquicos.

2.4.3. I Classes dos operadores básicos

Os operadores básicos são implementados segundo uma hierarquia de classes. Cada operador representa uma subclasse da classe Operator. A principal finalidade da classe Operator é permitir que os diferentes operadores sejam tratados de maneira uniforme. Cada operação feita sobre a estrutura cria uma instância do operador correspondente. Cada classe de operador implementa métodos para efetuar a operação e para efetuar a operação inversa sobre a estrutura.

A execução de uma determinada ação (por exemplo, inserir uma nova curva na subdivisão) pode requerer a instanciação de diversos operadores básicos. Esses operadores, quando criados, são dispostos numa lista ordenada gerenciada pela classe Action. Desta forma, implementam-se facilmente os recursos para desfazer e refazer ações na estrutura: basta percorrer a lista da ação e aplicar os operadores (inversos ou não).

Este mecanismo de recuperação de erros também é utilizado para garantir a persistência dos modelos (seção 2.5.3). Uma estrutura topológica pode ser concisamente salva em disco se pudermos enumerar um conjunto de operadores que, quando aplicados, reconstituem o modelo. Portanto, o modelo é salvo destruindo-o e salvando as operações inversas usadas na destruição (Mãntylã, 1988).

2.4.4 Relações de adjacências

Segundo Weiler (1986), suficiência topológica de uma representação consiste na abilidade de representar de forma completa e sem ambigüidade as adjacências topológicas. Completitude implica na abilidade de gerar todas as informações topológicas da representação. A ausência de ambigüidade implica que, para qualquer conjunto de entidades da representação, existe

21

apenas um conjunto de informações topológicas correspondente. Prover suficiência topológica da representação de um modelo geométrico é uma importante parte do processo para verificar se a representação é correta para o domínio especificado. Numa subdivisão planar, a obtenção das relações de adjacência entre as entidades topológicas garante a suficiência da representação.

Para o domínio de representação de subdivisões planares hierárquicas, devemos atender à obtenção das relações de adjacências entre as entidades de cada subdivisão planar representada e entre as entidades de níveis hierárquicos adjacentes. O quadro apresentado na Figura 2.l O resume todas as relações de adjacências de modelos de subdivisões planares hierárquicas. Para a representação das relações de adjacências adotamos a terminologia proposta por Weiler ( 1986). Nesta terminologia, cada relação de adjacência é representada por um par de símbolos. O primeiro simbolo representa a entidade de referência e o segundo o grupo de entidades adjacentes à entidade de referência. Para representar as entidades, usamos F para faces, E para arestas e V para vértices. Assim, por exemplo, a relação VE significa a obtenção de todas as arestas adjacentes a um dado vértice. Além da informação a respeito do tipo de relação de adjacência, é importante especificar a ordém no grupo de entidades adjacentes. Usamos os símbolos < > para indicar um grupo ciclicamente ordenado e { } para indicar um grupo com ordem não especificada. Então, V<E> significa a obtenção das arestas adjacentes a um vértice ciclicamente ordenadas e FM significa a obtenção dos vértices adjacentes a uma face em ordem não especificada.

Não hierárquicas

F{F} F{V}

E{F} E{E} E{V}

V<E>

Hierárquicas

FF' F{F-}

Figura 2.1 O: Relações de adjacências em subdivisões planares hierárquicas.

Estendemos a terminologia proposta por Weiler (1986) para representar as relações hierárquicas e a representação das entidades laço (L) e uso de aresta (U) que definem as entidades face e aresta, respectivamente. Também assumimos que Unext representa o próximo uso de aresta dentro de um mesmo laço, que Echild e Fchild representam acesso a uma das entidades "filhas" da entidade aresta e face, respectivamente, e que Eparent e Fparent

representam acesso às entidades "mães". A hierarquia é representada pelos símbolos • para

22

indicar entidades do nível superior e • para indicar entidades do nível inferior. Assim, F{F°} significa a obtenção do conjunto não ordenado de faces "filhas" de uma face e FF• significa a obtenção da aresta "mãe" de uma face. Ainda, para indicar as representações obtidas das estruturas das entidades (seção 2.4.1 ), usamos o símbolo -+ que indica "acesso". Assim, F-+{l}

indica que de cada face se tem acesso à lista de laços que a definem (através do ponteiro existente na estrutura de cada face).

As subseções seguintes discutem a obtenção das relações de adjacências na estrutura HPS. Inicialmente, revê-se a obtenção das relações de adjacências de uma subdivisão planar simples usando as informações existentes na estrutura de dados HPS. A seguir, discutem-se as relações de adjacências hierárquicas da estrutura e, por fim, discute-se a obtenção das relações de adjacência de subdivisões planares em representações hierárquicas usando as informações das entidades da estrutura HPS.

2.4.4.1 Relações de adjacências numa subdivisão planar simples

Existem nove relações de adjacências entre as entidades face, aresta e vértice de uma subdivisão planar simples. Considerando a representação de uma subdivisão planar simples com as informações presentes na estrutura HPS, essas nove relações de adjacências podem ser obtidas pela:

EM combinação das informações E-+{U} e U-+V.

E{F} combinação das informações E-+{U}, U-+L e L-+F.

V<E> combinação das informações V-+U e U-+E para obter uma primeira aresta, das informações U-+E e E-+{U} para obter o uso conjugado a um dado uso, e das informações U-+Unext e U-+E para obter a próxima aresta, até que se retome à aresta inicial.

V<V> combinação da obtenção de V<E> e EM.

V<F> combinação da obtenção de V<E> e E{F) ou das informações V-+L e L-+F para vértices isolados.

F{E} combinação das informações F-+{L), L-+U e U-+E para obter as primeiras arestas de cada laço, e das informações U-+Unext e U-+E para obter as próximas arestas de cada laço, até que se retorne às arestas iniciais.

FM combinação da obtenção de F<E> e EM, e das informações F{L} e L-+V para acessar os vértices isolados.

F{F} combinação da obtenção de F<E> e E{F}.

E{E} combinação da obtenção de EM e V<E>.

2.4.4.2 Relações de a<ijacéncias hierárquicas

Existem quatro relações de adjacências entre arestas e faces de diferentes níveis hierárquicos. Os vértices são entidades indivisíveis, portanto são únicos em diferentes níveis hierárquicos. As quatro relações de adjacências são diretamente obtidas através das informações existentes

23

nas estruturas de árvores que annazenam as arestas e faces do modelo. A obtenção é feita pela:

EE+ informação E-->Eparent.

E{E } combinação das informações E-->Echild e E-->Enext.

FF+ informação F-->Fparent.

F{F-} combinação das informações F-->Fchild e F-->Fnext.

2.4.4.3 Relações de a<{jacências em um nível de subdivisões planares hierárquicas

Para garantir a suficiência da estrutura HPS para representação de subdivisões planares hierárquicas, devemos provar a obtenção das nove relações de adjacências entre as entidades topológicas de cada subdivisão representada, além das relações de adjacências hierárquicas mostradas na subseção anterior. As nove relações de adjacências de cada subdivisão planar estarão devidamente representadas se provarmos o acesso às informações usadas para obter essas relações de adjacências em subdivisões simples. Essas informações nem sempre estão diretamente representadas na estrutura, pois uma mesma entidade topológica pode pertencer a diversos níveis hierárquicos. Nestes casos, exige-se uma busca local para acessá-las.

As informações uti!Ízadas para a obtenção das relações de adjacências em subdivisões simples foram: E-->{U}, U-->E, F-->{L}, l-->F, u .... v, v .... u, L-->V, V-->l, U..+l e L .... u (subseção 2.4.4.1). Destas, as informação E-->{U} e U-->E continuam diretamente representadas, pois cada aresta continua tendo seus respectivos usos associados. Analogamente, as informação F-->{l} e L-->F também estão diretamente representadas, pois cada face é definida por um conjunto de laços. A informação u .... unexl é representada devido à existência dos elos múltiplos; portanto, mesmo que as arestas associadas a usos consecutivos sejam definidas em níveis hierárquicos distintos, o encadeamento está diretamente representado.

As informações u .... v e L-->V estão representadas uma vez que os vértices são entidades indivisíveis; portanto, mesmo que a aresta associada ao uso (ou a face associada ao laço) e o vértice sejam definidos em níveis hierárquicos distintos, o uso (ou o laço) continua tendo um ponteiro para o vértice. Entretanto, as informações inversas, v .... u e V-->L, nem sempre estão diretamente disponíveis se não utilizarmos elos múltiplos na estrutura dos vértices. A seguir. discutem-se os procedimentos necessários para a obtenção destas duas informações utilizando elos simples nos vértices. Também são discutidos os procedimentos para acessar U-->l e l-->U,

que também nem sempre estão diretamente disponíveis, uma vez que as respectivas aresta e face associadas podem pertencer a níveis hierárquicos distintos.

v .... u a informação de um uso associado a um determinado vértice só está diretamente representada na estrutura para o nível hierárquico mais inferior. A ilustra uma situação onde esta informação não está diretamente representada: o Figura 2.11 uso diretamente apontado pelo vértice está associado a uma aresta que é "filha" de uma outra aresta do nível superior. Para obter o uso associado ao vértice no nível superior, faz-se uma busca local para obter a informação: a partir do uso diretamente apontado pelo vértice, acessa-se a aresta que o

24

contém e, em seguida, acessa-se a aresta "mãe". Entre os dois usos da aresta "mãe", escolhe-se o que possuir o vértice em questão .

•

• Figura 2.11: Obtenção da informaçao V-+U.

V-+l a informação do laço associado. a um determinado vértice isolado só está diretamente representada na estrutura para o nível hierárquico mais inferior. Para acessar o laço associado ao vértice no nível superior, existem duas situações onde exige-se a realização de uma busca local para obtenção desta informação. A Figura 2.12 ilustra estas situações. A primeira ocorre quando o laço diretamente apontado pelo vértice está associado a uma face que é "filha" de uma outra face do nível superior (situação análoga à encontrada na busca da informação V-+U descrita acima). Neste caso, a partir do laço diretamente apontado pelo vértice, acessa-se a face que o contém e, em seguida, acessa-se a face "mãe". Entre os laços da face "mãe", busca-se o que possuir o vértice em questão. A segunda situação ocorre quando o vértice, que é isolado no nível superior, tem arestas incidentes no nível inferior. Neste caso, acessa-se uma aresta incidente através do uso diretamente apontado pelo vértice. Esta aresta estará, obrigatoriamente, totalmente contida na face de nível superior. Portanto, a partir de uma das faces adjacentes á aresta, chega-se à face "mãe" e, entre os laços dessa face "mãe", busca-se o que possuir o vértice em questão .

. •©..._©

(a) (b)

Figura 2.12: Obtençao da informação V-+l.

U-+l a informação do laço apontado por um uso só está diretamente disponível na estrutura se a aresta associada ao uso e a face associada ao laço forem definidos no mesmo nível hierárquico ou quando a aresta for definida em nível hierárquico inferior ao da definição da face. Entretanto, pode ocorrer a situação ilustrada na Figura 2.13 onde a aresta associada ao uso é definida no nível

25

superior ao da face associada ao laço. Neste caso, para obter a informação no nível inferior, acessa-se a face superior através do laço diretamente apontado pelo uso. A partir dessa face superior, busca-se, entre os laços das faces "filhas", um laço que contenha o uso em questão.

i

©

Figura 2.13: Obtenção da informação U-+L.

L-+U analogamente, a informação do uso apontado por um laço só está diretamente disponível na estrutura se a face associada ao laço e a aresta associada ao uso forem definidos no mesmo nível hierárquico, ou quando a face for definida em nível hierárquico inferior ao da definição da aresta. Entretanto, pode ocorrer a situação ilustrada na Figura 2.14 onde a face associada ao laço é definida no nível superior ao da aresta associada ao uso. Neste caso, para obter a informação no nível inferior, acessa-se a aresta superior através do uso diretamente apontado pelo laço. A partir dessa aresta superior, busca-se, entre os usos de uma aresta "filha", o uso que aponte para o làço em questão.

@-CD

Figura 2.14: Obtenção da informação U-+L.

( PUC- RIO)

26

O acesso a essas infonnações para entidades definidas entre níveis hierárquicos não adjacentes é implementado com versões recursivas dos procedimentos descritos acima. Portanto, as relações de adjacências entre as entidades topológicas são obtidas utilizando-se apenas procedimentos de buscas locais. Com isto, garante-se a suficiência da estrutura HPS para representação de subdivisões planares hierárquicas.

Entretanto, o tempo da busca local para obtenção da informação V-+L (utilizando elos simples nos vértices) é proporcional ao número de laços da face "mãe". Por sua vez, o tempo da busca para obtenção da informação U-+L é proporcional ao número de faces "filhas" da face superior, ao número de laços de cada face "filha" e ao número de arestas de cada um desses laços. Em muitas situações, essa busca (U-tL) é feita com mais eficiência verificando se no laço original existe algum uso associado a uma aresta do nível que se deseja obter a informação (neste caso, obrigatoriamente o uso apontaria para o laço desejado). As duas outras buscas descritas (obtenção das infonnações V-+U e L-+U) são feitas em tempo constante.

2.4.5 Comentários sobre espaço de memória

A estrutura proposta permite a representação de subdivisões hierárquicas numa mesma base de dados. Resta-nos fazer uma análise do espaço de memória necessário para esta representação.

Uma primeira análise consiste na comparação entre a utilização da estrutura hierárquica para representação de uma subdivisão planar simples e a utilização de uma estrutura convencional (sem hierarquia). Neste caso, o espaço adicional gasto pela estrutura proposta consiste nos indicadores de níveis presentes nas entidades face, aresta e vértice, e no armazenamento de arestas e faces em árvores (seria necessário apenas listas). Os elos múltiplos não existem neste caso, já que o único nível existente é também o nível mais inferior no qual são utilizados elos simples. Nota-se, ainda, que a utilização de linguagens orientadas a objetos permite tratar entidades de maneira uniforme. Assim, nas estruturas de laços e de vértices só existe um único ponteiro que pode representar um uso ou um vértice, no caso do laço, e um laço ou um uso, no caso do vértice.

Uma segunda comparação de gasto de memória possível pode ser feita com relação à simulação de subdivisões hierárquicas através de ponteiros cruzados de subdivisões independentes. Neste caso, o gasto com o annazenamento em estruturas de árvore é comparável ao espaço gasto com os ponteiros cruzados. A diferença existe na representação de elos múltiplos contra a duplicidade de entidades idênticas. Neste aspecto, pode-se afirmar que o espaço de memória adicional para a representação interna, se existente, está relacionado com o maior ou menor número de entidades idênticas entre as diversas subdivisões.

Salienta-se, no entanto, que o espaço para representação das entidades topológicas e seus elos de ligação não constituem a representação da subdivisão como um todo. A cada entidade associam-se atributos, nem sempre desprezíveis do ponto de vista de espaço de memória, que representam a semântica das aplicações. Neste ponto, o fato da estrutura assegurar a não duplicidade de entidades idênticas pode representar uma economia de memória significativa na representação completa da subdivisão, além de simplificar o gerenciamento dos atributos por parte das aplicações clientes.

27

Para exemplificar a redução de memória alcançada pela não duplicação de entidades idênticas podemos analisar dois casos. No primeiro, representado pela Figura 2.l S, suponhamos um modelo composto por quatro níveis hierárquicos onde todas as arestas e faces de um determinado nível são subdivididas no próximo nível. Neste caso, como não existem arestas e faces idênticas em níveis adjacentes, a única redução de memória que a estrutura proposta oferece é a não duplicação de vértices que pertencem a mais de um nível. Entretanto, observa­se que o número de vértice que deixam de ser representados corresponde a 10% do total de entidades existentes.

F

E

V

DEEE• Total

2/2

414

414

415

12/12

5/9

Total: 367 / 408

16/17

40/40

16 / 25

64 / 65 86 / 89

1441144 2001200

56/81 81/119

Redução: 10%

Figura 2.15: Número de entidades na representação de um modelo com subdivisões sucessivas.

No segundo caso (Figura 2.16), analisamos um modelo simples que implementa os quatro níveis hierárquicos propostos por Carvalho et al. (1990) para geração de malhas de elementos finitos bidimensionais. Observa-se que o número de entidades idênticas que deixam de ser representadas nos quatro níveis hierárquicos representa 29% do total de entidades existentes.

F

E

V

3/3

8/8

8/8

4/6

4/12

0/8

Total: 307 1433

r-......_~ a Total

0/6

48 / 48

36144

64 / 66 71/81

96/144 156 / 212

36 I 80 80 I 140

Redução: 29%

Figura 2.16: Número de entidades na representação dos nlveis propostos por Carvalho et ai. (1990).

Outro aspecto relevante que podemos observar é o fato de que todas as entidades do terceiro nível deste modelo pertencem também a algum outro nível. Com isto, a eliminação deste nível, proposta por Vianna (1992) para reduzir o espaço de memória necessário para a representação do modelo como um todo, não significa redução de entidades representadas pela estrutura proposta. Este ponto é muito importante pois podemos concluir que a inserção de níveis hierárquicos semânticos por parte das aplicações é adequadamente suportada pela estrutura, tendo em vista que o espaço adicional de memória necessário tende a ser minimizado.

28

2.5 Modelagem de subdivisões planares hierárquicas

As estruturas de dados topológicas são próprias para representação de modelos dinâmicos, isto é, modelos que, por agentes externos, sofram alterações. A cada ação externa deve-se garantir a consistência do modelo, o que pode ser feito através da utilização dos operadores básicos, que têm escopo local devido à disponibilidade das informações de adjacências.

Subdivisões planares têm uma forma natural de modelagem que é através da inserção de vértices e arestas que formam o modelo (Cavalcanti et ai., 1991). A disponibilidade destas operações, aliadas às funções destrutivas, propicia um adequado ambiente para construção destas representações, e o gerenciador da estrutura de dados deve. prover suporte para estas implementações.

No caso de subdivisões hierárquicas, deve-se definir normas que regulamentam as possíveis edições sobre o modelo. Operações de inserção em níveis hierárquicos superiores podem ser inibidas por entidades em níveis inferiores ou gerar eventos adicionais nesses níveis inferiores. Por outro lado, as entidades de níveis superiores impõem restrições para as operações destrutivas em níveis inferiores. Deve-se, ainda, prever ações adicionais para permitir transportar as entidades entre os diferentes níveis da hierarquia.

Na seção subseqüente, discutimos as diversas estratégias para regulamentar as operações construtivas sobre o modelo. A seguir, apresentamos, resumidamente, os operadores de alto nível implementados para acessar a estrutura de dados com alto grau de abstração. Por fim, apresentamos a arquitetura de comunicação entre a base de dados e o cliente. A arquitetura proposta garante o encapsulamento dos dados e permite que o cliente incorpore semântica própria às operações de edição e às entidades do modelo.

2.5.1 Estratégias de inserção

A regulamentação das normas que regem as operações de modelagem podem seguir estratégias distintas. O conjunto de operadores básicos disponíveis não permite, por exemplo, que um vértice seja criado no interior de uma face que tenha "filhas", a menos que este vértice já exista numa das faces "filhas". Situação análoga ocorre com relação à inserção de arestas: uma aresta só pode ser inserida sobre uma face com "filhas" se existir nestas faces "filhas" um conjunto de arestas que rnbrem a nova aresta.

Neste ponto, pode-se optar por três estratégias diferentes: top-down destrutiva, top-down construtiva e downward compatível. Na primeira, considera-se que a inserção de uma entidade num nível superior que não respeite as subdivisões inferiores induz uma destruição das subdivisões inferiores violadas. A segunda estratégia admite a inserção de entidades em níveis superiores gerando eventos de inserções análogas nos diversos níveis inferiores. A terceira respeita as restrições dos operadores e simplesmente impede inserções incompatíveis com as subdivisões inferiores. A Figura 2.17 ilustra a aplicaçõ destas três estratégias num modelo simples com dois níveis hierárquicos.

vi v2

~/_/ v3

vS

/77 vii

Insere aresta v1-v3

29

,5/ top-down

J0.w""'"'"' /7 il7

top-down destrutiva

downward compatível

Figura 2.17: Exemplo de aplicaçao das estratégias de inserçao.

Para cada uma das estratégias pode-se enumerar vantagens e desvantagens que dependem da forma de interação da aplicação. Por exemplo, inibir que subdivisões inferiores sejam violadas pode ser útil nos casos onde essas subdivisões inferiores sejam obtidas por métodos que garantem sua consistência para o domínio da aplicação. Isto é comum nos geradores de malhas de elementos finitos que trabalham com diversos tipos de mapeamentos para geração da malha (Gattass et ai., 1991 ). Por outro lado, sempre permitir a inserção em níveis superiores pode agilizar a execução das tarefas de interação, pois desobriga o usuário de compatibilizar individualmente cada nível. Portanto, o gerenciador da estrutura de dados deve permitir a implementação das três estratégias, deixando para a aplicação a decisão sobre qual estratégia deve ser utilizada.

2.5.2 Operadores de alto nível

O gerenciador da estrutura HPS disponibiliza diversos operadores de alto nível para modelagem das subdivisões planares hierárquicas. Estes operadores garantem a consistência geométrica das ações e executam os operadores básicos correspondentes para atualização da base de dados, garantindo a consistência topológica. Para o cálculo geométrico, o gerenciador trabalha com o conceito de tolerâncias, que são definidas pelo cliente. As tolerâncias geométricas funcionam como áreas de atração entre as entidades do modelo, sendo primordiais para possibilitar as edições interativas através de uma interface com o usuário por manipulação direta. O Apêndice A apresenta métodos básicos para cálculo de interseção geométrica com tolerâncias.

As operações para inserção são implementadas através de operadores para inserir pontos e curvas no modelo. O cliente passa a descrição geométrica e o nível hierárquico no qual deve­se inserir as entidades. Para a inserção de pontos e curvas já geometricamente consistentes, o gerenciador disponibiliza operadores que não acionam os testes geométricos e mapeiam as ações diretamente sobre os operadores básicos. Estas funções são importantes pois muitas vezes o cliente conhece a consistência geométrica de suas entidades e pode ganhar eficiência nas ações.

30

Além desses operadores de inserção, existem os operadores para destruir vértices e arestas do modelo. Entretanto, as operações de destruição sofrem restrições de entidades de níveis superiores:

• um vértice s6 pode ser destruído no nível de sua definição;

• uma aresta s6 pode ser destruída no nível de sua definição, com a condição de não ter aresta "mãe".

Para mudar os níveis hierárquicos de definição das entidades, existem operadores que permitem alterar os níveis de definição de vértices e arestas, entre níveis hierárquicos adjacentes. Essas operações são eficientemente implementadas pois assegura-se a compatibilidade geométrica dos diversos níveis: por exemplo, uma aresta que está definida num nível hierárquico inferior está inteiramente contida numa face do nível superior.

Os operadores de alto nível garantem que entidades idênticas não sejam representadas na estrutura. Para inserir entidades em níveis inferiores, acionam-se automaticamente os operadores d (copy face) ou ce (copy edge) que criam as cópias temporárias das entidades superiores. Por outro lado, para cada ação de destruição, verifica-se a existência de faces ou arestas idênticas resultantes. Se existirem, eliminam-se as cópias através dos operadores inversos a cf e ce. A identidade de faces e arestas é avaliada seguindo as seguintes premissas:

• uma aresta é idêntica à sua "filha" se e somente se a aresta só tiver essa "filha";

• uma face é idêntica à sua "filha" se e somente se a face só tiver essa "filha"; todas as arestas adjacentes à face "filha" forem definidas, ou forem "filhas" de arestas definidas, em nível superior ou igual ao nível da face "mãe"; e todos os vértices adjacentes forem definidos em nível superior ou igual ao nível da face "mãe".

Salienta-se que as operações de destruição não correspondem, necessariamente, às operações inversas das inserções. Para exemplificar, considera-se o modelo de dois níveis hierárquicos ilustrado na Figura 2. l 8a. No nível superior existe uma face que tem uma face "filha" do nível inferior, devido à existência do vértice no interior desta face "filha". A operação de inserção de um vértice na face superior, geometricamente coincidente ao já existente na face inferior, elimina automaticamente a face inferior, pois ambas as faces seriam idênticas (Figura 2. l 8b ). Se o vértice então criado for destruído, não se retorna à situação anterior. Simplesmente elimina-se o vértice da então única face existente (Figura 2. l 8c ). Para se ter no\'amente a configuração anterior,. dever-se-ia requerer a operação que transfere o vértice para o nível inferior (Figura 2. l 8d).

Os operadores de alto nível possibilitam a implementação das três estratégias, discutidas na seção anterior, para inserção de entidades. A implementação da estratégia downward compatível é diretamente suportada pelos operadores básicos e é implementada naturalmente pelos operadores de alto nível. A implementação da estratégia top-down construtiva exige que as operações sejam re11lizadas no nível hierárquico mais inferior, seguidas de operações para elevar os níveis das entidades inseridas, até que se alcance o nível desejado. Por fim, a implementação da estratégia top-down destrutiva exige que, através das relações de adjacências, sejam destruídas as entidades nos níveis inferiores que impedem a realização da

31

ação. Para tanto, utilizam-se as informações passadas ao cliente nas situações de insucesso das operações, discutidas na seção 2.5.4.

destrói () () o

(c)

insere

o ..

() (b)

transfere .. (a) o

(d)

Figura 2.18: Combinação de inserção e destruição sem retomar à situação original.

Além dos operadores de inserção e destruição, o gerenciador oferece funções para operações de entrada e saída, e operações para recuperação de erros (undolredo ).

2.5.3 Persistência do modelo

A persistência do modelo pode ser conseguida listando-se os operadores básicos necessários para reconstruí-lo (Mãntylã, 1988). Para identificar as entidades, acrescentamos um id nas estruturas das entidades face, aresta e vértice. A estrutura de dados deve garantir a unívocidade destes identificadores. Cada operador tem seus respectivos operandos dados via estes identificadores.

Para listar os operadores que reconstróem o modelo, utilizamos os recursos já existentes para desfazer ações (undos). Destrói-se o modelo por completo e salva-se a lista de operadores inversos aos usados nesta destruição. Para destruir o modelo hierárquico, iniciamos pelo nível mais inferior passando, sucessivamente, para os níveis superiores. Para cada nível, destróem­se primeiramente todas as arestas que são definidas naquele nível e que não tenham arestas "mães" associadas. A seguir, destróem-se todos os vértices definidos no nível. Garante-se que todos estes vértices poderão ser eliminados. Se os vértices estiverem sobre arestas definidas no nível em questão, significa que estas arestas não puderam ser eliminadas, pois tinham "mães·· associadas. A eliminação destes vértices fará com que o operador inverso ao ce (copy

edge) seja automaticamente acionado, pois as arestas restantes serão idênticas às arestas superiores.

32

Para carregar um modelo anteriormente salvo, basta executar cada um dos operadores. No entanto, para obtermos um procedimento eficiente, é necessário provermos mecanismos de buscas para obter urna entidade a partir de seu identificador (e.g., usando tabela de hash).

2.5.4 Interface com o cliente

Diversas aplicações de domínios específicos podem ser construídas sobre subdivisões planares hierárquicas. Para permitir que a estrutura proposta seja usada em domínios abrangentes, cada aplicação acopla uma classe cliente ao gerenciador da base de dados. O cliente é responsável por caracterizar a semântica associada às entidades do modelo. Num gerador de malhas de elementos finitos, por exemplo, as faces do nível inferior podem representar os elementos da malha; num programa para representação de mapas cartográficos, as faces inferiores podem representar os municípios.

A estrutura de dados, através de seus operadores, garante a validação sintática da modelagem. As subdivisões planares hierárquicas construídas respeitam as propriedades discutidas na seção 2.3. No entanto, a validação semântica da representação e das ações sobre esta representação deve ser feita pelo cliente. A estrutura de dados em si não tem acesso à semântica incorporada pelo cliente. Portanto, todas as operações feitas sobre o modelo são validadas sintaticamente pelos operadores da estrutura e validadas semanticamente pelo cliente. O gerenciador da estrutura de dados requisita do cliente a validação de cada operação efetuada sobre o modelo. A arquitetura do sistema é apresentada na Figura 2.19.

Aplicação

~::;:od~z:, / ~ / _Cellbacks .----......,

.-------......, - de eventos~ 1 Cliente

Gerenciador ...a Operadores de va/Jdaçáo

Operado\re~ básicos Operadores

de consulta

Estrutura de dados HPS

Figura 2.19: Interface entre e o gerenciador e a aplicaçao.

A estrutura de dados HPS é atualizada pelo gerenciador através dos operadores básicos. As consultas à base de dados são feitas com os operadores de consultas existentes. Estes operadores de consulta basicamente informam sobre as relações de adjacência entre as entidades topológicas. Para utilizar a estrutura HPS, a aplicação edita o modelo através dos operadores de alto nível disponíveis no gerenciador, e acopla um módulo cliente a este gerenciador. O módulo cliente é responsável principalmente por caracterizar a semântica das

33

entidades. Tipicamente, o módulo cliente associa e gerencia os atributos das entidades do modelo.

Cada operação efetuada sobre a base de dados é reportada ao cliente pelo gerenciador através das callbacks de eventos. Deste modo, a aplicação é informada sobre a criação e destruição de cada entidade do modelo. Através destes eventos, pode-se, então, validar as operações semanticamente e gerenciar os atributos associados às entidades, utilizando os operadores de consulta para obter informações complementares.

As callbacks de eventos reportam, ainda, os erros sintáticos na edição do modelo. Os erros sintáticos que podem ocorrer na edição do modelo são:

• inserção de um ponto geometricamente coincidente com um vértice do mesmo nível já existente;

• inserção de um vértice sobre uma face com "filhas" que não têm um outro vértice que seja geometricamente coincidente com o vértice a ser inserido;

• inserção de uma curva geometricamente coincidente com uma aresta do mesmo nível já existente;

• inserção de uma aresta sobre uma face com "filhas" que não têm outras arestas que "cubram" a aresta a ser inserida.

Com isto, baseada na semântica associada, a aplicação pode corrigir os erros sintáticos. Por exemplo, a implementação da estratégia top-down destrutiva, descrita na seção 2.5. l, pode ser implementada através deste mecanismo de callbacks: se uma inserção é invalidada sintaticamente por entidades de níveis inferiores, o cliente pode optar por destruir estas entidades, validando a ação.

Salienta-se que, na execução das cal/backs, a estrutura de dados deve corresponder a um modelo de subdivisões planares hierárquicas válido, mesmo que esta configuração represente um estado intermediário. na execução completa da ação requerida. Assegurar a validade do modelo é importante, pois do contrário a aplicação não teria disponível as funções de consulta, como também não poderia requisitar ações adicionais.

Para facilitar o acesso à tecnologia implementada pela estrutura HPS, pode-se implementar mecanismos de configuração, permitindo que os atributos associados às entidades sejam gerenciados com elevado grau de abstração. Os problemas e requisitos associados com configuração de aplicações são discutidos no próximo capítulo. Propõe-se também um modelo de configuração de aplicações via especificação de atributos.

3. Configuração via Especificação de Atributos

Uma das grandes preocupações da Engenharia de Software diz respeito à reutilização de código. Devido ao alto custo de desenvolvimento, faz-se necessário provermos mecanismos que possibilitem o re-uso de partes de programas anteriormente desenvolvidos, e já testados. O uso de ferramentas básicas na construção de software permite que aplicações complexas sejam desenvolvidas em tempo menor, justamente por oferecer níveis de abstração mais elevados para realização das tarefas de implementação. As ferramentas não só permitem o re­uso de código como também uniformizam a base de desenvolvimento das aplicações, o que facilita os serviços de manutenção e expansão dos programas.

No desenvolvimento de diversos programas gráficos para atender demandas da indústria, constatamos que diversas aplicações implementam tecnologias que podem ser utilizadas em diversos domí"nios específicos. Por exemplo, um modelador de subdivisões planares, que implementa tecnologias próprias da área de Modelagem Geométrica, pode ser utilizado para a representação de mapas cartográficos ou para a implementação de geradores de malhas de elementos finitos bidimensionais, conforme discutido no capítulo anterior. Por sua vez, um gerador de malhas de elementos finitos pode ser utilizado para gerar modelos para diferentes tipos de simulação numérica, tais como análise estrutural ou análise tem1odinâmica (Cook et ai., 1989). No entanto, é comum encontrarmos programas que, apesar de implementarem tecnologias bastante sofisticadas, não podem ser aplicados em áreas afins por simples inadequação de suas interfaces. Quando o são, requerem que o reaproveitamento seja feito com acesso direto à implementação da tecnologia, o que toma a tarefa árdua, mesmo que a aplicação tenha sido desenvolvida sob as mais rigorosas "regras de boa programação". Toma­se necessário oferecer ferramentas que auxiliem no desenvolvimento de aplicações configuráveis, possibilitando o reaproveitamento da tecnologia com elevado grau de abstração inclusive por parte dos usuários.

Neste capítulo, discutimos os problemas e reqms1tos associados com· configuração de aplicações e apresentamos um sistema. a ser acoplado às aplicações para tomá-las configuráveis. Os serviços de configuração oferecidos pelo sistema proposto baseiam-se na especificação dos atributos que podem estar associadas às entidades da aplicação. A estratégia de configuração de aplicações via especificação de atributos é válida, pois, em diversas classes de aplicações técnico-científicas, os atributos caracterizam a semântica do modelo matemático utilizado. A viabilidade de configuração dos atributos associados às aplicações nos permite desenvolver programas altamente versáteis, atendendo a uma gama variada de aplicações específicas.

Para o acoplamento dos serviços de configuração, identificamos os diversos agentes envolvidos no desenvolvimento de software e propomos regras de comunicação entre aplicações e ambientes de configuração que orientam o desenvolvimento de aplicações configuráveis.

35

3.1 Configuração como estratégia de re-uso

Krueger (1991) apresentou urna abrangente discussão a respeito de re-uso de código nos mais diversos níveis: desde a utilização de linguagens de programação de alto nível, e da simples prática de copiar trechos de códigos já feitos, até a utilização de ferramentas mais sofisticadas, que são formalmente estruturadas para o desenvolvimento de software re-usável. A discussão inclui, ainda, os chamados geradores de aplicação, isto é, programas desenvolvidos especificamente para auxiliar o desenvolvimento de aplicações de um determinado domínio.

O trabalho de Krueger caracteriza os diversos níveis de re-uso de código sob os conceitos de abstração, seleção, especificação e integração. A tarefa de re-usar software está intimamente ligada ao conceito de abstração. A eficácia na reutilização de técnicas pode ser medida pela distância cognitiva para reutilizar, parcial ou integralmente, um trabalho anteriormente desenvolvido (conceituando distância cognitiva, informalmente, como sendo o esforço intelectual que deve ser expendido para realizar tal tarefa). Portanto, o re-uso de código é facilitado se pudermos trabalhar com alto grau de abstração.

A dimensão de seleção retrata o trabalho de identificação da ferramenta mais apropriada para uma determinada aplicação. Quanto maior a abstração utilizada, mais facilmente pode-se selecionar uma ferramenta. A especificação de . ferramentas genéricas consiste na parametrização da parte variável da abstração. Por fim, a dimensão de integração requer o entendimento, por parte do usuário, da interface da ferramenta; interface esta que é, em última análise, também urna abstração.

O uso do paradigma de programação orientada a objetos no desenvolvimento de software facilita a tarefa de re-uso de código já implementado. No entanto, este reaproveitamento exige urna programação disciplinada e ainda não se apresenta com o grau de abstração necessário. Udell (1994) e Betz (1994) indicam como solução a viabilidade de comunicação entre processos através de transferência de objetos. Esses mecanismos já são oferecidos, com restrições, em alguns ambientes particulares como o MS-Windows (Clark, 1992). Entretanto, o uso desses mecanismos ainda encontra sérios problemas de portabilidade.

A configuração de aplicações pode ser vista também sob o enfoque de re-uso, Jª que reaproveitamos a implementação de uma mesma tecnologia para diversos fins mais específicos. A estratégia de configuração de aplicações em diferentes níveis, até o produto final, engloba diversas etapas de re-uso de software. Diversos agentes usam as mesmas ferramentas para construção de suas aplicações, que por sua vez também podem ser configuráveis. Esses agentes trabalham com níveis crescentes de abstração, tornando disponíveis aos programadores e usuários as tecnologias implementadas pelas aplicações.

3.2 Requisitos para configuração de aplicações

Aplicações complexas são melhor estruturadas se divididas em duas partes: a primeira consistindo na biblioteca de suporte, onde se encontra a implementação dos serviços existentes, e a segunda correspondendo ao mecanismo que oferece acesso programável aos serviços existentes (Valdés, 1991 ). Hoje, encontramos serviÇos com acesso programável em aplicações de diversas áreas: para banco de dados, serviços do sistema PARADOX são acessados pela linguagem PAL (Paradox Application Language); para planilhas, o Excel

36

trabalha associado a uma linguagem de macros própria; para CAD, o AutoCAD aceita programação em Autolisp.

A implementação dos serviços representa a tecnologia da aplicação (Celes et ai., J 994b). Para oferecer suporte para desenvolvimento de aplicações configuráveis é necessário tornar esta tecnologia disponível até mesmo para os usuários. A obtenção de serviços de configuração adequados requer o acesso às tecnologias com elevado grau de abstração.

3.2.1 Acesso às tecnologias das aplicações

Constata-se a necessidade de acessar as tecnologias implementadas pelas aplicações para que uma mesma aplicação possa ser configurada para se adequar a diversos usos específicos. Há bastante tempo, o uso de pequenas linguagens acopladas às aplicações é visto como uma solução adequada para promover esse acesso programável aos serviços implementados (Bentley, 1986). Hoje, é crescente o número de novas pequenas linguagens devido, principalmente, à existência de ferramentas utilitárias para a construção de compiladores (Valdés, 1991 ).

Em Física, acoplamento significa a interação entre dois sistemas. onde se transfere energia de um para o outro. No contexto deste trabalho, discute-se o acoplamento de uma linguagem com as aplicações, a fim de viabilizar a transferência da tecnologia da aplicação para o usuário e permitir, na outra direção, que o usuário possa adequar a aplicação ao seu uso.

O acesso programável aos serviços oferecidos por uma aplicação configurável pode ser feito através do acoplamento de linguagens específicas. Nesse caso, para cada aplicação, implementa-se uma linguagem direcionada para dar suporte ás possibilidades de configuração da aplicação. A Figura 3.1 ilustra a arquitetura de aplicações desenvolvidas sob este enfoque.

Usuário

Linguagem A Linguagem B

Aplicação A Aplicação B Aplicação C

Figura 3.1: Arquitetura de configuração com uso de linguagens específicas.

A desvantagem dessa estratégia está . na necessidade de se desenvolver uma linguagem específica para cada aplicação. Com isso, exige-se a implementação de compiladores específicos que, mesmo com ferramentas apropriadas do tipo lex e yacc (Levine e Brown, 1992), não é uma tarefa trivial. Além disso, com essa estratégia. o modo de configuração de cada aplicação será através de uma sintaxe específica, o que dificultará o aprendizado por parte dos usuários configuradores (Cowan e Veitch., 1992).

A fim de contornar esses problemas, propõe-se a utilização de uma única linguagem, que deve poder ser especializada para atender domínios específicos. A própria linguagem deve ser

37

configurável, o que evita a criação de vários compiladores e propicia a obtenção de uma sintaxe uniforme para as diversas aplicações. A Figura 3.2 ilustra a implementação desta estratégia.

Usuãrio

Figura 3.2: Arquitetura das aplicações com uso de uma linguagem configurável.

Programadores de aplicações podem estender a linguagem, construindo serviços abstratos direcionados para um determinado domínio de interesse, trabalhando num nível de abstração bastante superior ao desenvolvimento de compiladores. Dessa forma, a configuração permite acessar a tecnologia da aplicação através de serviços específicos implementados pela especialização da própria linguagem, além de poder contar com os recursos de programação inerentes à própria linguagem, tais como operadores básicos e controladores de fluxo. Além disso, um usuário familiarizado com uma aplicação não encontra dificuldades em aprender os serviços de configuração de uma outra aplicação, já que ambas apresentarão uma mesma sintaxe básica. Isto justifica o investimento inicial do usuário em aprender uma nova linguagem.

3.2.2 Características da linguagem de programação

Idealmente, os serviços de configuração de aplicações deveriam dispensar as linguagens de programação tradicionais e permitir a programação via recursos mais abstratos. Nesse sentido, muitas pesquisas têm sido feitas em programação visual (Chang, 1990). No entanto, apesar dos contínuos progressos, as linguagens de programação visual ainda não são suficientes para atender todas as tarefas de programação (Souza e Ferreira, 1994). Na prática, apenas a construção de interfaces convencionais tem sido plenamente atendida através de recursos visuais. O êxito da programação visual nessa etapa se deve principalmente a dois aspectos: primeiro, interfaces são compostas por um número pequeno de objetos (menus, botões, listas, etc.); segundo, interfaces são naturalmente visuais. Para implementação de procedimentos mais gerais, ainda precisamos de uma linguagem de programação convencional (Cowan et ai., 1992).

Em geral, usuários configuradores têm pouco conhecimento formal de princípios de programação. A própria tarefa de aprender uma linguagem de programação é árdua e pouco animadora. Eles não objetivam tornarem-se profissionais em programação, apenas necessitam acessar tecnologias para solucionar problemas específicos. Portanto, a linguagem oferecida a

38

esses profissionais deve ser simples e fácil de aprender. A linguagem também deve proteger o usuário de possíveis, e freqüentes, erros de programação (Cowan et ai., 1992). Não é possível exigir desses programadores conhecimentos para controlar ponteiros e gerenciamento de memória, para citar apenas um exemplo básico. Esses programadores devem trabalhar com linguagens que provêm os recursos de estruturação necessários, mas com elevado grau de abstração.

3.2.3 Agentes e níveis de abstração

Obrigatoriamente, o acesso à tecnologia da aplicação deve ser feito com alto grau de abstração, pois do contrário recairíamos no problema de acessar diretamente implementações complexas. Surge, então, o problema de identificação dos agentes responsáveis pelo desenvolvimento do produto como um todo, até ser passado ao usuário final para utilização. Existe uma estratificação dos agentes envolvidos no desenvolvimento do produto em diversos níveis, sendo crescente a abstração para a realização das tarefas. A Figura 3.3 ilustra esta estratificação. ·

produto usa ~ A • B configuração 4

COnf.!..f:!!..rD usulfirio mestrt s 1" . R e=:> A ç Â . o

aplicação • programa prog. aplicação

• ferramenta • e.rog_rama prog. esprcialista

Figura 3.3: Agentes e níveis de abstração.

Os especialistas em computação são responsáveis por oferecer ferramentas básicas para o desenvolvimento de aplicações. Esses profissionais trabalham com pouéo nível de abstração, priorizando a versatilidade e a eficiência da ferramenta que está sendo desenvolvida. As aplicações são desenvolvidas sobre essas ferramentas básicas. Os programadores de aplicação são pessoas com conhecimentos de computação e da área específica da aplicação. Nos níveis acima, podem existir diversas especializações das aplicações, onde se trabalha com níveis crescentes de abstração. Por fim, encontram-se os usuários mestres que são responsáveis pela configuração da aplicação para um determinado domínio. Esses profissionais têm conhecimento do domínio da aplicação mas não necessitam de muito conhecimento de programação, já que trabalham com um nível de abstração bastante elevado. Ao usuário final, cabe utilizar o produto já adequadamente configurado. Esses usuários não podem alterar as funcionalidades da aplicação; eles podem ter acesso apenas à configuração de preferências, tais como arranjo e cores dos objetos de interface. Esses usuários finais não necessitam de conhecimento de programação. Eles são especialistas da área específica de aplicação do produto.

39

3.3 Linguagem de configuração

Para prover àcesso programável às tecnologias das aplicações, utilizamos a linguagem de programação Lua (Figueiredo et ai., 1994; lerusalimschy et. ai, 1995). Lua é uma linguagem procedimental para extensão de aplicações com um poderoso mecanismo para descrição de dados. Lua é implementada como uma biblioteca, escrita em C, podendo ser acoplada a diferentes aplicações. Em Lua, não existe o conceito de programa principal: a linguagem depende de um programa hospedeiro, que pode chamar funções de Lua para serem executadas, ler e atribuir variáveis de Lua, e ainda registrar novas funções de C para serem chamadas de Lua. Além disto, Lua incorpora as facilidades usuais de uma linguagem procedimental -controle de fluxo, atribuições, definição de funções e operadores - e permite a abstração da linguagem para um domínio específico qualquer, através da criação de tipos e operadores com semântica própria. A linguagem Lua também suporta o paradigma de programação orientada a objetos, permitindo a definição de métodos e herança entre objetos.

Todos estes mecanismos e recursos são facilmente acessados através de uma sintaxe simples, semelhante à de Pascal. Lua garante ainda uma programação com alto nível de abstração, já que o programador não precisa se preocupar com detalhes, como declaração de tipos de variáveis e gerenciamento de memória. Com estruturas internas dinâmicas e coleta automática de lixo, o progràlnador usa livremente as diversas opções de estruturação de dados e deixa a cargo da própria linguagem as tarefas de re-alocação e liberação de memória.

Todos os comandos e construções de Lua são executados num único ambiente global. Este ambiente, que guarda todas as variáveis globais e definição de funções, é automaticamente inicializado no início do programa hospedeiro e persiste até o seu término. O ambiente global de Lua pode ser manipulado por códigos escritos em Lua ou pelo programa hospedeiro, através das funções de interface com e disponibilizadas pela linguagem.

As subseções seguintes descrevem as principais características da linguagem Lua e discute a especialização da linguagem para um determinado domínio.

3.3.1 Variáveis e tipos

Em Lua, as variáveis não têm tipo: os tipos estão associados aos dados armazenados na variável. Os dados podem ser de sete tipos distintos: nil, number, string,function, cfunction, userdata e table. O tipo níl representa o valor indefinido. Todas as variáveis ainda não inicializadas assumem o valor nil. O tipo number representa valores numéricos. Lua não faz distinção entre valores inteiros e reais. Todos os valores numéricos são tratados como sendo do tipo number. O tipo string representa cadeia de caracteres. As cadeias de caracteres podem ser livremente criadas e concatenadas; a linguagem se encarrega de fazer as alocações e liberações de memória necessárias.

Funções em Lua são consideradas valores de primeira classe. Isto significa que funções podem ser armazenadas em variáveis, passadas como parâmetros para outras funções, ou retomadas como resultados. A definição de uma função equivale a atribuir a uma variável global o valor do código que executa a função. Uma função em Lua pode ser do tipo function, quando escrita em Lua, ou do tipo cfunction, quando escrita em C e registrada em Lua.

40

O tipo userdata permite armazenar numa variável de Lua um ponteiro qualquer de C. Este tipo corresponde ao tipo void* de C e só pode ser atribuído ou comparado para igualdade a olltro

valor de mesmo tipo em Lua. Aliado ao mecanismo de fal/baclcs, o tipo userdata confere um poderoso mecanismo para criação de semânticas próprias na linguagem, como será discutido adiante.

O tipo table (tabela) é o tipo mais expressivo da linguagem. Este tipo implementa os chamados vetores associativos, que permitem indexação por valores de qualquer tipo, com exceção do tipo nil. As tabelas em Lua permitem a construção de vetores convencionais, listas e records numa mesma estrutura. Esta flexibilidade é a base do mecanismo existente em Lua para descrição de objetos.

3.3.2 Construtores de tipos

Na inicialização de tabelas, é possível associarmos uma função a ser chamada imediatamente após sua criação. Esta função recebe como parâmetro a tabela criada, e é chamada construtor de tipo. Tipicamente, o construtor de tipo é usado para verificar a validade da inicialização dos campos da tabela, para atribuir valores default a campos rião inicializados e para qualquer outra tarefa que complemente a inicialização da tabela ( e.g., registrar a nova instância criada numa estrutura de dados global).

A possibilidade de associarmos construtores de tipos às tabelas de Lua permite a criação de tipos com semânticas próprias. O programador não trabalha com o tipo tabela diretamente, mas sobre uma abstração direcionada para o domínio de interesse ( e.g., ao invés de criar uma tabela com campos x e y, cria-se um Ponto). Além disso, o construtor assegura a validade do objeto criado.

3.3.3 Mecanismo de fa/lback

Lua possui um mecanismo de fa!lbacks que permite estender sua semântica. Basicamente, uma fallback é uma função definida pelo programador que é executada sempre que ocorrer uma situação onde Lua não sabe como prosseguir. Por exemplo, se tentarmos somar duas tabelas, ocorrerá um erro de execução, pois Lua espera operandos do tipo number. No entanto, o programador pode associar urna função de fallback para ser executada sempre que esta condição de erro ocorrer. Assim, é possível ao programador implementar uma extensão para Lua tratar soma de tabelas (e.g., tratamento de números complexos).

Uma funcionalidade importante oferecida através do mecanismo de fal/backs é a manipulação direta de dados do programa hospedeiro através de programação em Lua. O programador pode registrar fallbacks que tratem de indexações feitas com o tipo userdata e, assim, permitir o tratamento de objetos C com a mesma sintaxe de objetos Lua. Com isto, uma "simples atribuição" em Lua pode executar um método no programa hospedeiro para atualizar a estrutura de dados.

3.3.4 Especialização da linguagem

Os recursos oferecidos pela linguagem Lua, em especial a possibilidade de associar construtores de tipos e tratar erros de execução através de fallbacks, permitem a

41

especialização da linguagem por parte dos programadores de aplicação. Com isto, o programador pode trabalhar com elevado nível de abstração, manipulando objetos específicos da aplicação.

A Figura 3.4 ilustra a arquitetura das aplicações na especialização da linguagem Lua para um determinado domínio. Observa-se que a parte configurada da linguagem acessa a tecnologia do domínio específico da aplicação. O programador final utiliza os recursos incorporados à linguagem através desta configuração, como também acessa os serviços inerentes à própria linguagem. Isto é, o programador trabalha com uma linguagem abstrata direcionada para um determinado domínio tendo acesso aos recursos usuais de uma linguagem de programação procedimental.

Apllcaçllo configurável

I Tecnologia da

apllcação

Figura 3.4: Arquitetura na especializaçao de Lua.

Lua tem sido usada em diversas aplicações desenvolvidas no TeCGraf (Ceies et ai., l 994b ). O fato de as aplicações usarem uma mesma linguagem de extensão facilita o aprendizado por parte do usuário e possibilita a comunicação entre aplicações (Cowan e Veitch, 1992).

3.4 Ferramentas para criação de interfaces gráficas

Para configuração de aplicações gráficas, é necessário que o usuário configurador tenha acesso à criação de diálogos de interface, pois, invariavelmente, fará parte da configuração a especificação de tarefas interativas. A programação de interfaces gráficas do tipo WIMP (windows, icons, menus, pointers), utilizando bibliotecas gráficas e too/kits de interface convencionais, é muito complexa. Portanto, é necessário oferecer aos usuários configuradores ferramentas que os permitam trabalhar com um nível de abstração maior.

Visando dar suporte adequado a estes serviços de configuração, projetamos e desenvolvemos a ferramenta EDG, um sistema que provê acesso facilitado tanto a objetos de interface tradicionais quanto a objetos gráficos, possibilitando que programadores ocasionais desenvolvam rapidamente interfaces com sofisticado grau de interação. Através do acesso aos objetos gráficos e da possibilidade de tratar eventos sobre eles incidentes, os programadores podem criar seus próprios objetos de interface, atribuindo-lhes funcionalidades próprias, direcionadas para o domínio da aplicação.

42

O sistema EDG foi inicialmente projetado como suporte ao desenvolvimento de interfaces gráficas para acessar tecnologias implementadas em aplicações já existentes (Apêndice B), representando uma evolução do sistema ED (Figueiredo et ai., 1992).

As seções subseqüentes apresentam os principais serviços oferecidos pelo sistema EDG e como estes são acessados pelo programador da interface. Por fim, comparamos as facilidades para construção de interfaces suportadas pelo EDG com as de outros sistemas correlatos.

3.4.1 Características do sistema EDG

A Figura 3.5 ilustra a arquitetura de implementação do sistema EDG.

Figura 3.5: Arquitetura do sistema EDG.

O código do EDG representa basicamente uma especialização da linguagem Lua, provendo ao programador acesso a objetos de interface tradicionais e objetos gráficos. Os objetos de interface representam uma abstração do sistema de interface com o usuário IUP (Levy, 1993). Os objetos gráficos são abstrações de primitivas gráficas da GLB. GLB é uma biblioteca construída para armazenar e gerenciar objetos gráficos estruturados. As primitivas gráficas podem ser hierarquicamente agrupadas criando entidades gráficas abstratas.

O programador instancia os objetos através de uma codificação descritiva. Por exemplo, o trecho de código abaixo descreve e instancia um objeto gráfico "linha":

segment = line {

)

x = {o.o, i.o},

y = {1.0, 1.0}.

color = EDG_YELLOW,

width = EDG DOUBLE

coordenadas X

coordenadas Y

cor da linha

espessura

O nome segment representa o objeto criado e serve de referência para esse objeto. Entretanto, a principal característica do sistema EDG é permitir a criação e manipulação de objetos gráficos construídos com um programa de edição de desenhos auxiliar. Os objetos gráficos

43

podem ser construídos diretamente no editor de desenhos e manipulados como objetos convencionais.

As subseções seguintes detalham como os objetos de interfaces tradicionais e os objetos gráficos são acessados, e discutem a criação de objetos de interface próprios através do tratamento dos eventos sobre os objetos gráficos.

3.4.1.1 Acesso a objetos de interface

Para possibilitar a construção de diálogos, deve-se prover acesso a objetos de interface. Nesse contexto, salientamos a distinção entre serviços de configuração de layout de diálogos e acesso programável aos objetos para construção de diálogos. O primeiro serviço (configuração de layout) é oferecido por diversos sistemas de interface. O sistema IUP, por exemplo, possui uma linguagem de especificação de diálogos - LED - que é interpretada em tempo de execução da aplicação. Através de LED, o layout e a composição dos diálogos das aplicações podem ser configurados pelo usuário. É possível, por exemplo, desabilitar determinadas funções, redefinir teclas associadas a ações da aplicação, alterar a composição dos diálogos e configurar cores. Esses serviços de configuração não possibilitam, no entanto, a criação de novas funcionalidades.

Os objetivos do sistema EDG são mais abrangentes. O configurador deve ter meios de criar diálogos associados às suas próprias funções, validando dados e transformando-os para serem processados. O usuário configurador deve trabalhar num ambiente com alto grau de abstração, mas a ferramenta deve ser versátil o suficiente para atender às tarefas de interação requeridas. O equilíbrio entre o nível de abstração e a versatilidade caracteriza a funcionalidade da ferramenta que atua como base do ambiente para desenvolvimento de interfaces: de nada adianta elevado grau de abstração sem poder de expressão; por outro lado, não nos servem ambientes versáteis com alto grau de complexidade, pois neste caso poderíamos disponibilizar para o configurador as linguagens convencionais de programação (tais como C ou Modula 2), o que está longe do objetivo que buscamos alcançar.

O sistema EDG oferece acesso a objetos de interface que representam abstrações dos objetos de interface do sistema IUP. Nestas abstrações, objetiva-se principalmente facilitar a captura e manipulação de dados. Para exemplificar, considera-se o tratamento dado aos valores associados aos objetos de interface. Os objetos que têm valores associados (campos de edição, lista de opções, etc.) apresentam no EDG duas formas correspondentes de expressão destes valores: um valor cadeia de caracteres (string) e um valor numérico. Esta estratégia tem trazido muitas facilidades na programação de captura de dados, pois livra o programador da tarefa de conversão de valores. Por exemplo, os valores associados a uma lista de opções são a cadeia de caracteres da opção selecionada e o número dessa opção. Assim, o programador utiliza o valor que lhe for mais adequado: a cadeia de caracteres ou a forma numérica.

Para exemplificar com mais detalhes, analisemos o objeto fie/d que possibilita a captura de uma cadeia de caracteres (campo de edição). A abstração fie/d caracteriza um objeto para captura de cadeias de caracteres, mas é estendida para captura de valores numéricos e expressões avaliadas em tempo de execução. Se o usuário entrar com uma cadeia de caracteres que pode ser convertida para um valor numérico equivalente, ambos os valores (cadeia de caracteres e valor numérico) ficam automaticamente disponíveis no ambiente de programação. Além disso, se o usuário preceder a cadeia de caracteres com um sinal de igual '=' . o restante

44

da cadeia é avaliado como uma expressão, ficando mais uma vez tanto a cadeia de caracteres da expressão quanto o valor avaliado disponíveis.

Além do objeto fie/d, o sistema permite a instanciação de diversos outros objetos, entre eles listas, botões, menus e os elementos de composição do IUP: caixa horizontal e caixa vertical. O trecho de código abaixo ilustra a construção do diálogo esquematizado na Figura 3.6.

nome = field { prompt = "Nome:"}

sexo vradio options = { "Masc" 1 "Fem''} }

dial dialog title = ''Dados Pessoais'1,

object = hbox { nome, sexo } }

}

Dados Pessoais

Nome:[ J ~-----~

@ Masc

o Fem

Figura 3.6: Exemplo de um diálogo simples.

Pode-se associar aos objetos de interface ações que são callbacks às interações do usuário. Os diálogos podem ser instanciados em forma modal ou não modal. O sistema permite ainda a associação de funções para validação dos dados capturados.

3.4.l.2 Acesso e manipulação de objetos gráficos

A principal característica do sistema EDG é prover fácil acesso à instanciação de objetos gráficos e permitir que sejam manipulados. A criação de representações gráficas complexas através de sistemas gráficos convencionais não é trivial: deve-se especificar as coordenadas de todas as primitivas gráficas que compõem o desenho.

EDG permite instanciar e manipular representações gráficas (complexas ou não) de maneira muito simples. Como no sistema ED original (Figueiredo et ai., 1992), o programador pode criar suas representações gráficas através de um programa de edição de desenhos, no caso o TeCDraw1

. Esse programa possui os recursos usuais encontrados em editores de desenho. Com simples operações de seleção com o mouse, o usuário pode criar diversos tipos de desenhos independentes de dispositivos. Como trabalha-se com objetos gráficos, esses podem ser livremente editados e transformados. Permite-se, ainda, importar desenhos gerados por outros sistemas.

A particularidade do TeCDraw é permitir que as primitivas gráficas que compõem o desenho sejam agrupadas e identificadas como entidades para serem manipuladas no ambiente de programação do EDG. A idéia é permitir que o programador desenhe livremente as

1 TeCDraw é um editor de desenhos desenvolvido no TeCGraf.

45

representações gráficas que deseja instanciar. Atribuindo-lhes um nome simbólico, ainda dentro do desenhador, essas representações tomam-se entidades que podem ser manipuladas . na codificação do programa EOG/Lua. Dentro desse código, os nomes atribuídos às entidades representam objetos que podem ser processados. Existem diversos métodos associados aos objetos gráficos que podem ser executados. É possível desenhar e apagar a entidade da área de desenho; mover, escalar ou rodar a entidade; atribuir-lhe novas cores e formas, etc:

A comunicação entre o TeCOraw e o EOG é possível porque utilizamos a sintaxe da própria linguagem Lua para escrever o metafile gerado pelo desenhador. Isto é, o arquivo gerado pelo desenhador é um código Lua que descreve cada objeto gráfico que compõe a imagem. Portanto, para o sistema EDG, carregar uma imagem é executar o código Lua correspondente. Como o programador também codifica em Lua, ele naturalmente tem acesso aos objetos gráficos contidos nos me/afiles.

A geração de metafiles com as descrições dos objetos gráficos em Lua apresenta diversas vantagens: pode-se usar a própria linguagem para interpretar o arquivo; é fácil editar o arquivo com editores de texto convencionais (tem-se uma descrição estruturada do desenho); possibilita a criação de objetos procedimentais ( e.g., é fácil descrever as coordenadas de uma linha por funções matemáticas). Como desvantagem, ainda existem problemas de eficiência na carga de imagens complexas.

3.4.1.3 Tratamento de eventos sobre os objetos gráficos

Para permitir a construção de interfaces gráficas interativas, o sistema EOG permite o tratamento de eventos de mouse sobre os objetos gráficos instanciados. O sistema filtra os detalhes da programação por eventos convencionais - tais como o gerenciamento de button down, bullon up e mouse motion - e passa ao programador a possibilidade de programar sobre dois eventos abstratos: objeto apontado (click) e objeto arrastado (drag). Sempre que um objeto gráfico for apontado ou arrastado, o sistema executa o método associado ao evento, que pode ser criado pelo programador.

O tratamento do evento de click permite criar aplicações para entrada de dados através de formulários gráficos (Figueiredo et ai., 1992): os objetos de uma imagem podem representar dados que o usuário deve especificar. Quando o usuário aponta um determinado objeto, o programa apresenta um diálogo auxiliar com os dados que devem ser capturados. Terminada a entrada de dados, o programa pode fornecer um feedback gráfico adequado para indicar que os dados referentes àquele objeto já foram fornecidos. A utilização de formulários gráficos é adequada para entrada de dados na área de engenharia, onde é comum existir representações gráficas que caracterizam a natureza dos dados a serem especificados.

A combinação dos eventos click e drag permite a programação de tarefas de interação mais sofisticadas, impossíveis no sistema ED original. Consideram-se dois exemplos típicos: especificação de transformações sobre objetos e edição de objetos. A especificação de transformações de objetos pode ser feita através da exposição de marcas de controle nas bordas do retângulo que circunscreve o objeto. O usuário especifica a transformação manipulando essas marcas. Assim, a configuração ilustrada na Figura 3.7a permite que o usuário arraste as marcas para aplicar escala sobre o objeto; e a configuração da Figura 3.7b permite que o usuário arraste as marcas para aplicar rotação e cisalhamento sobre o objeto.

46

(a) Marcas para escalamento. (b) Marcas para rotação e cisalhamento.

Figura 3. 7: Marcas para transformaçao de objetos

Para implementar essas funcionalidades com o EDG, pode-se programar o evento de click sobre o objeto para criar os objetos que representam as marcas de controle. A cada uma dessas marcas. associa-se uma função que transfonna o objeto original, através do evento drag.

Observa-se que este procedimento pode ser aplicado a qualquer objeto. As marcas podem assumir a forma desejada e suas ações associadas ao drag são implementadas independentemente. Portanto, pode-se criar diversas formas de manipulação dos objetos dentro de uma estrutura conceituai simples.

A edição de objetos (re-shape) também pode ser implementada com essa estratégia. Para ilustrar, considera-se a ação de editar uma linha poligonal. Para esta tarefa, criam-se marcas de controle em cada vénice da poligonal, e pennite-se que o usuário re-posicione os vértices. movendo essas marcas (Figura 3.8). No EDG, pode-se programar a ação de click sobre a poligonal para mostrar os objetos que representam as marcas de controle. A cada um desses objetos, programa-se o evento de drag para pennitir o reposicionamento do vértice da poligonal. O trecho de código abaixo ilustra a implementação dessa estratégia.

POLY = {}; MARCA= {}

function POLY:click ()

local i = 1

local n e self:getn()

while i<=n do

local m = mark{x=self:getx(i), y=self:gety(i),

filled=l, poly=sel f, index=i,

parent = MARCA

m:draw ()

i = i+l

end

end

define classe POLJ' e MARCA

trata C.'\'<!nto de "cfrck "

mim de ptos da poligonal

para cada vértice da poligonal

erra uma marca

fa= objeto herdar de MARCA

47

function MARCA:drag (xO, yo, xl, yl)

local i = self.index

trata "drag"

self .poly:clear() apaga poligonal

sel f: clear () apaga marca

self.poly.x[i] = self.poly.x[i] + (xl-xO)

self.poly.y[i] = self.poly.y[i] + (yl-yO)

self.x = self.x + (xl-xO)

self.x = self.x + (yl-yO)

self.poly:change("x", self.poly.x)

self. poly: change ( "y", self .poly. y)

self:move(xl-xO,yl-yO)

self.poly:draw()

self: draw ()

end

move marca

redesenha poligonal

redesenha marca

O conceito de edição de poligonais pode ser estendido para a edição de objetos gráficos quaisquer. O programador projeta a forma de edição de um objeto e implementa a criação das marcas de controle necessárias para o usuário realizar a edição. Assim, cada objeto pode ter sua forma própria de edição.

Figura 3.8: Edição de uma linha poligonal.

3.4.l.4 Exemplos de criação de objetos de interface próprios

Os recursos do sistema EDG também possibilitam a criação de objetos de interface próprios. É muito fácil construir novos objetos de interface e atribuir-lhes funcionalidades próprias. Para tanto, basta que o usuário desenhe o novo objeto de interface e depois associe funções que respondam às ações do usuário. Considera-se o exemplo de construir um objeto de interface que representa um potenciômetro. Supõe-se que queremos um potenciômetro que funcione com um ponteiro marcador, e que o usuário especifique o valor manipulando diretamente este ponteiro. A primeira etapa para criação do novo objeto de interface é desenhá-lo no programa TeCDraw. A Figura 3.9 ilustra um desenho para representar o potenciómetro. Para o usuário poder manipular o ponteiro, deve-se identificar as primitivas gráficas que representam o desenho do ponteiro como sendo uma entidade, conferindo-lhe um nome simbólico; por exemplo, hand.

48

50 25 1

' o-' 75

/

-100

Figura 3.9: Exemplo de um potenciômetro.

A codificação do funcionamento do potenciômetro é simples: basta escrever uma função associada à ação "arrastar a entidade hand". Como a função associada ao evento de drag recebe como parâmetros as posições inicial e final do mouse, pode-se apagar o ponteiro, calcular sua nova posição, posicioná-lo corretamente e então desenhá-lo. O valor do potenciômetro deve ser armazenado para permitir futuras consultas. O código abaixo implementa essa funcionalidade.

CONTROL = {}

function CONTROL:drag (xO,yO,xl,yl)

local ao= atan2(yO,xO)

local al = atan2(yl,xl)

self:clear{)

self:rotate(O, O, al-aO)

self:draw()

angulo = angulo - (al-aO)

valor = angulo*l00/180

end

angulo = O

valor = O

hand.parent CONTROL

define classe CONTROL

trata "drag"

ângulo inicial

ângulo final

apaga ponteiro

transforma ponteiro

redesenha ponteiro

atualiza angulo

calcula valor associado

inicializa angulo

inicializa \'alar

f<r ponteiro herdar de CONTROL

Nos eventos de drag, pode-se ainda programar feedback dos objetos sendo arrastados. A cada movimento do mouse, o sistema executa o método feedback que pode ser programado para mostrar as posições intermediárias do objeto.

Como segundo exemplo de criação de objetos de interface, considera-se a especificação de uma função XY. Esta tarefa de interação é muito utilizada nos sistemas de engenharia que trabalham com análises dinâmicas. As propriedades associadas às entidades podem variar em função .do tempo, sendo necessário, portanto, que o usuário especifique a função de variação dessas propriedades.

A função pode ser especificada de diversas formas. O sistema EOG provê recursos de programação que permite ao programador escolher a forma mais conveniente. A definição da função através de uma expressão é facilmente implementada devido aos recursos da

49

linguagem Lua e do acesso aos objetos de interface tradicionais. Entretanto, pode-se programar tarefas de interações mais sofisticadas para a definição da função. É possível a criação de um objeto de interface que represente o gráfico da função. Ao evento de click, podemos associar a criação de um novo ponto no gráfico. Para a edição do gráfico, podemos permitir que o usuário elimine pontos existentes ou altere os pontos, utilizando um procedimento análogo ao de edição de poligonais mostrado na seção anterior. Pode-se, ainda, projetar recursos adicionais como visualização de grids, escalas logarítmicas, etc.

Observa-se que os objetos de interfaces com tarefas de interação sofisticadas podem ser instanciados na especificação de atributos no sistema de configuração proposto no capítulo anterior. Como o programador tem acesso à redefinição dos métodos que manipulam os valores associados aos objetos de interface, estes novos objetos podem ser tratados de maneira uniforme pelo sistema de configuração.

3.4.J.5 Transferência de objetos entre aplicações

A programação de novos objetos de interface, como ilustrado na seção anterior, permite sua instanciação em qualquer aplicação EDG: basta que o arquivo com a codificação da funcionalidade e o arquivo metafile com a descrição da imagem sejam carregados pela aplicação.

Num aspecto mais abrangente, observa-se que o uso do EDG permite a transferência de objetos gráficos entre aplicações. A linguagem Lua tem funções próprias que permitem programar persistência de objetos. Assim, como os objetos podem ser totalmente descritos, incluindo métodos e dados, qualquer aplicação pode instanciá-los e manipulá-los. Os objetos transportam para outras aplicações inclusive seus estados correntes. Portanto, um mesmo objeto pode ser parcialmente editado numa aplicação e concluído em outra. A Figura 3 .1 O esquematiza essa transferência de objetos entre aplicações.

~A-pl-ic-•fã_o_A~ ---- li Objrro Mi1Mios

•

/~

Aplicação B -li Figura 3.10: Transferência de objetos entre aplicações EDG.

3.4.2 Comparação com sistemas correlatos

Existem diversos outros sistemas que oferecem suporte para o desenvolvimento de interfaces gráficas interativas. Nesta seção, comparamos três desses sistemas - Visual Basic, Tcl/Tk e ezd - com o EDG. Interessa-nos comparar a flexibilidade e a facilidade encontrada na construção de interfaces, principalmente para a instanciação de objetos de interfaces não convencionais.

so

Visual Basic tem sido amplamente utilizado para o desenvolvimento de aplicações gráficas interativas. Esse sistema permite a programação dos objetos de interface que compõem as aplicações via recursos visuais. As ações associadas aos eventos sobre os objetos de interface são codificadas em Basic. Para instanciação de representações gráficas, Visual Basic oferece duas formas: através dos controladores gráficos, primitivas (linha, imagem ou formas geométricas pré-definidas) que podem ser instanciadas visualmente em tempo de programação; e através de fanções que permitem programar o traçado de primitivas gráficas. Os controladores gráficos são tratados como objetos de interface sobre os quais podem ser programadas ações associadas aos eventos sobre eles incidentes (Microsoft, 1993).

Visual Basic oferece um ambiente de programação amigável, onde programadores ocasionais não encontram dificuldades em projetar suas interfaces. O tratamento das representações gráficas só tem suporte adequado para as primitivas instanciadas visualmente em tempo de programação. As representações gráficas não podem ser adequadamente estruturadas, não permitindo a criação de abstrações de objetos gráficos. Os gráficos desenhados via fanções têm que ser codificados (e visualizados apenas em tempo de execução) e não há tratamento de

eventos sobre eles.

TclfTk formam um sistema para desenvolvimento de aplicações provendo acesso à construção de interfaces gráficas Motif-like através da linguagem Te! (Ousterhout, 1994). Tk implementa um tookit completo de objetos de interface. O sistema também permite a instanciação e manipulação de primitivas gráficas. Essas primitivas podem ser identificadas por tags (nomes simbólicos) para serem posteriormente referenciadas. O mecanismo de tags permite agrupar primitivas especificando o mesmo tag para diversas primitivas. O sistema permite aplicar transformações geométricas e programar ações (com scripts na linguagem Tcl) em resposta a eventos (enter, leave, mouse motion, etc.) ocorridos sobre as primitivas.

Diversas extensões têm sido feitas no sistema TclfTk e diversas aplicações estão sendo desenvolvidas sobre essa base. A programação em Te! não apresenta uma sintaxe simples e clara, mas Tk provê acesso a um sofisticado too/kit de objetos de interface. A instanciação de representações gráficas tem que ser codificada. O uso de tags não é suficiente para uma estruturação adequada dessas representações.

O sistema ezd é um servidor gráfico situado entre o programa de aplicação e o servidor X, provendo acesso facilitado a objetos gráficos estruturados (Bartlett, 1991). Seu principal objetivo é ajudar o programador de aplicação no tratamento e instanciação de objetos gráficos e no gerenciamento dos eventos do X. O ezd estrutura os objetos gráficos de forma análoga ao EDG, permitindo agrupan1entos e associação de nomes simbólicos para futuras referências. O sistema filtra os eventos do X que interessam à aplicação. No entanto, o ezd também só permite instanciação das representações gráficas via codificação (em scheme).

A possibilidade do programador usar um editor de desenhos para criar as representações gráficas é uma característica única do EDG. As facilidades de estruturação dessas representações e a criação de abstrações sobre os objetos gráficos possibilitam uma programação adequada para interfaces que manipulam desenhos, sem necessidade de codificação de detalhes gráficos.

51

Deve-se considerar ainda a questão da portabilidade. Tanto Tcl/Tk quanto ezd foram desenvolvidos para sistemas Unix com X. O sistema Visual Basic é para programação em MS­Windows. O sistema EDG tem portabilidade assegurada pelo sistema de interface IUP (Figueiredo et ai., 1993). Atualmente, o sistema pode ser usado para programas desenvolvidos em ambientes X, MS-Windows e DOS.

3.5 Proposta de configuração via especificação de atributos

O domínio das aplicações pode ser caracterizado pelo conjunto de propriedades que podem estar associadas às entidades que representam o modelo. Essas propriedades, ou atributos, representam a semântica das aplicações e, portanto, caracterizam as funcionalidades oferecidas ao usuário final. Para oferecer suporte para a incorporação de mecanismos de configuração em aplicações, propomos uma estratégia baseada na especificação de atributos. Com o acoplamento do sistema de configuração proposto, os atributos associados às entidades do modelo tomam-se configuráveis. Com isso, configura-se a semântica das aplicações e permite-se que uma mesma aplicação possa ser utilizada em diversos domínios específicos. A estratégia de configuração via atributos deve prover mecanismos para que as edições sobre o modelo da aplicação sejam validadas no ambiente de configuração, uma vez que a aplicação em si não tem acesso à semântica incorporada pela configuração.

O paradigma de programação orientada a objetos oferece recursos de estruturação de classes que podem ser utilizados na estratégia de configuração. Se direcionamos o uso da ferramenta de configuração para atender a um determinado domínio de aplicações, podemos pré-definir super-classes e métodos que são usados pelo configurador para derivar suas classes específicas. Nesse caso, as super-classes incórporam conceitos semânticos relacionados com o domínio de interesse e portanto podem ser enumeradas atendendo à totalidade das aplicações nesse domínio específico (Carvalho, 1995).

A generalização dessa estratégia em domínios mais amplos pressupõe a eliminação de qualquer semântica na definição das super-classes: a semântica associada com a representação de mapas cartográficos não tem qualquer relação com a semântica de um gerador de malhas de elementos finitos, embora as duas aplicações possam ser desenvolvidas sobre um mesmo modelador de subdivisões planares. Portanto, não é possível enumerar um conjunto de classes que incorpore semântica para atender domínios abrangentes.

Do ponto de vista do usuário configurador, que não tem grandes conhecimentos de programação, acreditamos que o trabalho de configuração é facilitado à medida que aumentamos os serviços de descrição de objetos e diminuímos as exigências de programação procedimental. A descrição de objetos é muito mais natural do que o desenvolvimento de procedimentos computacionais, principalmente para programadores ocasionais.

As seções subseqüentes propõem uma estratégia de configuração de aplicações através da disponibilização de serviços para a especificação de atributos. Através de um código basicamente descritivo, o configurador da aplicação define quais atributos podem estar associados às diversas entidades que compõem o modelo, caracterizando a funcionalidade da aplicação através das validações semânticas das operações de edições requisitadas pelo usuário final.

52

3.5.1 Caracterização da semântica

A configuração de aplicações via especificação de atributos envolve duas tarefas. A primeira corresponde à própria especificação dos atributos. O configurador descreve os parâmetros que caracterizam os atributos, como esses parâmetros são definidos pelo usuário final num ambiente interativo e que atributos estão associados a que entidades do modelo.

A segunda tarefa está relacionada com o fato dos atributos caracterizarem a semântica da aplicação. Qualquer ação sobre as entidades do modelo deve ser validada pelo ambiente de configuração, pois a aplicação, por ser configurável, não tem conhecimento da natureza dos atributos que podem ser aplicados às entidades do modelo. Por exemplo, numa aplicação representada por subdivisões planares, a eliminação de uma aresta implica na união das faces adjacentes. Esta ação (eliminar uma aresta) pode ou não ser válida dependendo da compatibilização entre os atributos associados às faces que deverão ser unidas: é possível que as faces representem regiões com materiais distintos que não podem ser combinados. Portanto, cada ação de edição das entidades da aplicação deve ser validada semanticamente pelo ambiente de configuração.

3.5.2 Estruturação do modelo de configuração

O modelo de configuração é estruturado de maneira hierárquica onde os elementos de ordem inferior compõem os elementos de ordem superior. O modelo representa a raiz da estruturação

·e pode ser composto por diversas entidades de configuração. Cada entidade de configuração tem um conjunto de atributos associados. Essas entidades permitem o agrupamento de atributos com semânticas afins. Por sua vez, cada atributo é definido por um· conjunto de parâmetros. A Figura 3. l 1 ilustra esta estruturação.

~ {entidades}

t EV {atributos}

t ~ {parâmetros/

t ~ {atributos 1 parâmetros 1 valores}

Figura 3.11: Estruturaçao do modelo de configuraçao.

As entidades de configuração estão associadas às entidades da aplicação. No entanto, não é necessário que se tenha uma relação de uma para uma. Uma mesma entidade da aplicação pode estar associada a mais de uma entidade de configuração, ou vice-versa. Podemos optar por estruturar os atributos de uma entidade da aplicação em duas entidades de configuração, assim como podemos associar um mesmo conjunto de atributos a duas entidades da aplicação. Por exemplo, um modelador de subdivisões planares trabalha com três entidades topológicas:

53

face, aresta e vértice. Para a utilização desse modelador na geração de malhas de elementos finitos, podemos separar os atributos associados a uma face em duas entidades de configuração: uma agrupando os atributos fisicos e geométricos, e outra agrupando os atributos de carregamento e condições de contorno. Por outro lado, podemos fazer as entidades vértice e aresta estarem associadas a um mesmo conjunto de condições de contorno.

A tarefa de definição das entidades de configuração, e como elas estão associadas às entidades da aplicação, depende do projeto de interface com o usuário da aplicação, e é feita pelo programador da aplicação. Dentro desta estruturação, ao usuário configurador cabe definir o conjunto de atributos de cada entidade de configuração.

Os atributos representam propriedades que podem estar associadas às entidades, sendo definido pelos conjuntos de parâmetros que os compõem. Para dar flexibilidade na definição dos atributos, cada parâmetro pode representar um valor de diversos tipos, a saber:

• simples: usado quando o parâmetro é representado por um único valor, por exemplo, quando sua definição é feita por um valor numérico, um valor cadeia de caracteres ou uma opção de uma lista;

• múltiplo: usado quando o parâmetro é definido por uma lista de valores simples, por exemplo, quando podemos escolher diversas opções de uma lista de opções;

• composto: usado quando um parâmetro é definido por diversos outros parâmetros.

• exclusivo: usado quando se escolhe como valor um parâmetro entre possíveis opções exclusivas de um parâmetro composto;

• referência: usado quando o parâmetro tem como valor uma referência a um atributo (o valor representa um identificador do atributo referenciado);

Com esta classificação de valores, permite-se a definição de atributos gerais, possibilitando a composição hierárquica de atributos e parâmetros. A estruturação do modelo proposta define o escopo de aplicação do sistema de configuração desenvolvido. O sistema atende aos requisitos para incorporação dos mecanismos de configuração de uma aplicação se seus atributos puderem ser estruturados segundo o modelo apresentado.

3.5.3 Definição de instâncias de atributos

O usuário final pode criar diversas instâncias de cada atributo e aplicá-las nas entidades. Essas instâncias são armazenadas internamente em tabelas. gerenciadas pelo sistema de configuração. As instâncias têm dois identificadores associados: um interno e outro externo. O identificador interno, id, representa a posição na tabela onde a instância está armazenada, sendo gerenciado pelo sistema de configuração. O identificador externo serve para o usuário referenciar-se à instância. Este identificador representa um label (rótulo) implementado através de uma cadeia de caracteres. O label de cada instância pode ser definido explicitamente pelo usuário ou pode ser implicitamente construído pelo sistema.

Assume-se que as instâncias dos atributos devem poder ser definidas interativamente. Portanto, deve-se especificar quais os objetos de interface serão usados para a definição de

54

cada instância. O configurador da aplicação especifica quais os parâmetros que definem os atributos e que objetos de interface serão utilizados para capturá-los. O configurador especifica ainda se o identificador externo (labef) será explicitamente ou implicitamente definido. Se for explicitamente definido, deve-se especificar o objeto de interface para capturá-lo. Se for implicitamente definido, pode-se redefinir a função que constrói automaticamente o /abel, a partir do identificar interno e do valor associados.

3.5.4 Estratégia de implementação e interface com o usuário

A implementação do sistema segue o paradigma de orientação a objetos. Cada um dos tipos de valores representa uma classe que é automaticamente herdada pelos parâmetros. Os componentes da estruturação de configuração (modelo, enüdade, atributo e parâmetro) também representam classes. Cada modelo, entidade. atributo e parâmetro criados pelo configurador são subclasses automaticamente construídas pelo sistema. O configurador não tem que ter conhecimento de orientação a objetos, pois ele não acessa a hierarquia de classes explicitamente. apenas trabalha com descrição de objetos. O paradigma de orientação a objetos é usado apenas para permitir urna melhor estruturação da implementação do sistema e possibilitar que o configurador redefina o comportamento dos objetos.

Existem di\'ersos métodos associados às diferentes classes do sistema. Muitos desses métodos são os serviços oferecidos à aplicação para o acoplamento do mecarusmo de configuração. Outros métodos mais específicos caracterizam funcionalidades das classes e podem ser redefinidos pelo configurador.

Os serYiços oferecidos pré-definem os layouts dos diálogos. Configuradores mais exigentes podem redefinir os métodos básicos para construção desses layouts. Tipicamente, cada atributo tem uma composição dos objetos de interface como o esquematizado na Figura 3.12a. Ao lado. na Figura 3.12b, apresenta-se um exemplo de um /ayout concreto para definição de um atributo.

label

1nstances

dtalog

(a) (b)

Figura 3.12. Layouts abstrato e concreto da interface para definiçao de atributos

O objeto ínstances é uma lista das instâncias já existentes. O usuário pode escolher urna das instâncias da lista ou optar por criar urna nova instância. O label representa o objeto de interface para captura de Jabels explicitamente definidos, se for o caso. O objeto dialog representa o diálogo definido pelo configurador para captura dos parâmetros. Essa composição de objetos sofre pequenas variações de acordo com a tarefa de interação requisitada. Por exemplo, durante uma definição de instâncias, o usuário não pode alterar os

55

valores das instâncias já existentes. Por outro lado, durante uma edição de instâncias já existentes, o usuário não pode criar novas instâncias, mas acrescenta-se um objeto de interface que pennite eliminar urna das instâncias listadas. Para o caso de serem requisitadas ações de interação sobre urna entidade de configuração, o layout do diáJogo final é urna composição dos diálogos dos atributos que definem a entidade. Nesse caso, o usuário pode definir todos atributos da entidade ao mesmo tempo.

3.5.5 Acoplamento dos serviços de configuração às aplicações

A comunicação entre a aplicação e o an1biente de configuração é feita através de operadores como ilustrado na Figura 3.13.

1 operadores atribuição

1

Aplicação

t operadores

de \•a/1dação semánt1ca

operadores dt' consulta

Configuração

J

operadores ad1c1ona1s

Figura 3.13. Comunicação entre aplicação e ambiente de configuração.

A aplicação acessa os serviços de especificação e manipulação dos atributos via os operadores de atribuição. Estes operadores correspondem aos métodos associados às classes modelo, entidade ou atributo que são oferecidos como serviços para a apl icação, a saber:

• save: permite salvar as instâncias de atributos definidas:

• load: permite carregar as instâncias de atributos armazenadas em arquivo: combinado com o método sm·e. oferece serviços de persistência do ambiente de configuração;

• define: permite definir urna instância de atributo como corrente: pode-se escolher entre uma instância já existente ou criar uma nova;

• apply: permite aplicar a instância corrente à uma entidade da aplicação;

• edit: permite editar as instâncias de atributos já existentes;

• show: permite mostrar as instâncias de atributos aplicadas a uma entidade da aplicação;

A aplicação programa sua interface para que o usuário tenha acesso a esses serviços.

Para associar instâncias de atributos às entidades, a aplicação passa ao ambiente de configuração identificadores das entidades. Cada identificador pode ser quaJquer valor que identifica univocamente a entidade. mas deve ser imutável mesmo em operações de entrada e

56

saída (portanto, não se pode utilizar endereços de memória). A associação entre entidade da aplicação e instância do atributo aplicada é armazenada pelo sistema de configuração; a aplicação não armazena nem tem acesso às instâncias dos atributos aplicadas. Esta independência é importante, pois facilita o acoplamento dos serviços de configuração em aplicações já existentes.

Além dos operadores de atribuição, a aplicação acessa o ambiente de configuração via os operadores de validação semântica. Estes operadores são responsáveis por validar semanticamente as operações sobre as entidades da aplicação. Cada aplicação deve enumerar as possíveis operações sobre suas entidades e passar para o ambiente de configuração a responsabilidade de validá-las semanticamente. Por exemplo, ações do tipo criar, eliminar, unir e dividir entidades da aplicação devem ter seus operadores de validação correspondentes.

Para poder realizar as ações que lhe são requisitadas, o configurador tem acesso às entidades da aplicação via os operadores de consulta. O configurador não tem acesso à edição dessas entidades, mas necessita consultar propriedades da aplicação. Deve-se observar que não existe operadores de consulta para a aplicação acessar a configuração. Este fato é importante para criar uma modularização com fronteiras bem definidas e impedir que o comportamento da aplicação seja dependente de estados da configuração, o que descaracterizaria a propriedade de ser configurável.

Para completar a comunicação aplicação-<:onfiguração, deve-se prever, ainda, operadores adicionais que variam conforme as necessidades de cada aplicação. Estes operadores sãp necessários, por exemplo, para implementar operações de saída e entrada formatadas ou para permitir que a configuração forneça feedbacks gráficos dos atributos aplicados. Estes operadores adicionais devem ser criteriosamente projetados para não incorporar na aplicação ínformações específicas de uma configuração em particular.

3.5.6 Acesso aos serviços de configuração

Para acoplar os serviços de configuração propostos, as aplicações devem incorporar a biblioteca da linguagem de programação Lua e da ferramenta EDG. Os serviços de configuração em si são implementados por um código Lua (de aproximadamente J 000 linhas), que representa uma especialização da linguagem, construída sobre a ferramenta EDG. para gerenciamento do modelo de configuração. Desta forma, o configurador tem acesso às funcionalidades inerentes à linguagem Lua e acessa os serviços oferecidos pela ferramenta EDG para especificar os diálogos de interface.

Através dos mecanismos de comunicação da linguagem Lua com o programa hospedeiro (no caso, a própria aplicação), o programador da aplicação disponibiliza o acesso aos operadores de consulta e acessa os operadores de validação semântica e os operadores adicionais enumerados.

A aplicação estabelece que entidades de configuração podem ser instanciadas e projeta uma interface para que o usuário tenha acesso à especificação dos atributos. Durante a execução, a aplicação executa o código com os serviços de configuração e o código escrito pelo configurador que representa uma configuração em particular (seção 3.4.8).

57

Para exemplificar a utilização dos serviços de configuração na especificação de atributos, supõe-se uma aplicação que tem uma entidade região (region) à qual o configurador pode associar atributos. A aplicação pode projetar uma interface onde o usuário seleciona as entidades que representam regiões para aplicar os atributos desejados. Uma função típica para realizar esta tarefa é ilustrada pelo pseudocódigo abaixo.

function RegionApply ( J Region:define{)

end

for r ~ each selected region

Region:apply(r)

end

.. 3.5.7 Tarefa de configuração da aplicação

função para aplicar atributos em regiões

requisita a definição dos atributos associados

para cada região selecionada

aplico em r os atributos especificados

Para configurar uma aplicação que acople os serviços de configuração descritos, o usuário mestre (configurador) escreve um arquivo onde implementa os operadores de validação e operadores adicionais requeridos, e descreve os atributos associados a cada entidade de configuração.

A descrição dos atributos segue uma sintaxe simples, onde o configurador especifica os campos necessários para definição dos objetos, a saber:

• Parameter

• components: lista de parâmetros para o caso de ser composto por outros parâmetros; se somente um destes parâmetros pode estar ativo, indica-se ainda qual o inicialmente ativo;

• inte1face: objeto de interface par2 definição do parâmetro;

• default: valor inicial no caso de ter valor simples ou múltiplo.

• A/tribute

• name: nome do atributo;

• components: lista dos parâmetros que compõem o atributo;

• dialog: objeto de interface para composição das interfaces dos parâmetros;

• label: objeto de interface para definição explícita do label, se for o caso.

• Entity

• name: nome da entidade de configuração;

. • a/tributes: atributos aplicáveis à entidade.

• Model

• name: nome do modelo;

• entities: entidades de configuração que compõem o modelo.

58

Além da descrição dos objetos, o configurador pode redefinir alguns métodos associados a esses objetos (todos os métodos têm uma implementação default, desobrigando o configurador desta tarefa):

• valida/e: método de validação do valor capturado associado a cada parâmetro. A possibilidade de redefinir este método possibilita implementar críticas próprias sobre os valores capturados, fazer validações cruzadas entre componentes dos parâmetros ou definir valores de parâmetros implicitamente em função dos demais;

• getitfi•a/ue, setitfi·alue: métodos que pennitem transferir o valor associado ao objeto de interface para o parâmetro, e vice-versa. A redefinição desses métodos pode ser usada para construir valores mais adequados a partir dos dados fornecidos pelo usuário e para criar objetos de interface próprios.

• apply, getapplicd: métodos para aplicar (e consultar) uma instância de atributo a uma entidade da aplicação. A redefinição desses métodos é útil se for desejado pennitir a aplicação de mais de uma instância de um mesmo atributo numa única entidade.

• getlabel: método para capturar o label explícitamente definido pelo usuário ou para construir um label implícitamente. Sua redefinição permite, por exemplo, a construção de labe/s implícitos que identificam adequadamente a instância.

3.5.8 Exemplo de especificação de atributos

Para exemplificar a configuração de aplicações que acoplam o sistema proposto, analisamos a especificação de três atributos associados a regiões comuns à área de modeladores para análise numérica. Nestes exemplos, especificamos os objetos de interface usando a ferramenta EDG. Como primeiro exemplo, considera-se a especificação do atributo de espessura aplicado às regiões do modelo. A espessura de uma região é caracterizada por um valor que a define. Portanto, a descrição deste atributo pode ser dada pelo código a seguir.

tvalue = Parameter {

interface = field {prompt="value="),

default = l.O

Thickness = Attribute {

name = "Thickness",

components = {tvalue),

dialog = tvalue

}

captura valor via campo de edição

valor default

nome do atributo

composto por apenas un1 parámetro

interface é o próprio parámetro

Para completar a especificação do atributo, pode-se redefinir alguns de seus métodos. Como exemplo, considera-se a redefinição dos métodos para validação do valor capturado e para construção implícita do labe/.

59

function tvalue:validate (value)

if value < o.o then return nil

redefine validação do parâmetro

proíbe valores negativos

els e

end

return l

function Thickness:getlabel (id, value) redefineconstruçãoimplícitado/abel

return value [l] constrói label como sendo o valor da espessura

end

Como segundo exemplo, considera-se a especificação do atributo material, também aplicado a regiões do modelo. Supõe-se que o material pode ser de dois tipos distintos: elástico, definido pelos módulo de elasticidade e coeficiente de defonnação; e plástico, definido pelos módulo de elasticidade, coeficiente de deformação e tensão de escoamento. O trecho de código a seguir cria este atributo. O layout do diálogo construído é o que foi mostrado na Figura 3.l2b.

Eelast = Parameter { interface field {prompt="E="), default =

Kelast = Parameter { interface= field {prompt="K="), default

Elast = Parameter {

2100 }

0.2 }

components = {Eelast, Kelast}

interface = vbox {Eelast, Kelast}

parân1etro con1posto

composição vertical das obj. de interface

}

Eplast = Parameter { interface fiel d {prompt="E="},

Kplast = Parameter { interface = field {prompt="K="},

splast Parameter { interface = field {prompt="S= 11},

Plast = Parameter {

components = {Eplast, Kplast, Splast}

interface = vbox (Eelast, Kelast, Splast}

l

Type = Parameter {

default 2100 } default = 0.2 } default = 1400 }

components = {Elast, Plast; active = 1)

interface = zbox {Elast, Plast;

con1posição e.xc/usi\'e

composição sobreposta dos obj. de interface

options ::. { "Elastic" 1 ''Plastic"}

Material = Attribute {

name = "Material 11,

components = {Type],

dialog = Type

label = field {prompt="label: "} label capturado via campo de edição

Por fim, para exemplificar o uso de referências a outros atributos dentro de parâmetros, considera-se a definição do atributo de carregamento de pressão associado a regiões. Para definir este atributo, supõe-se que seja necessário definir o valor da pressão e a função que

60

indica a variação deste valor ao longo do tempo. Supõe-se, ainda, que a função é também um atributo definido por uma expressão (o label do atributo função é dado implicitamente pela própria expressão). A Figura 3.14 ilustra os /ayouts dos diálogos de interface para especificação destes atributos definidos no trecho de código apresentado a seguir.

Figura 3.14. Exemplo de diálogos para definiçao de atributos.

expr Parameter interface = field {prompt= "exp:::-: "}

Func = Attribute {

}

name = "Function",

components = { expr },

dialog = expr

function Func:getlabel (id, value)

return value (1)

end

define o atributo função

redefine construção implícita do label

constrói labe.' como sendo o \·alor da expressão

pvalue Parameter interface = field {prompt="Y.:üue="},

default = 1. O

Pressure = Attribute

name = "Pressure".

components = {pvalue, Func},

dialog = vbox {pvalue, Func},

label = field {prompt="Label: "}

define o atributo pressão

Para completar a tarefa de configuração, considera-se a especificação de uma entidade região associada aos atributos acima exemplificados e de um modelo.

61

Region = Entity { name = "Region", attributes e { Thickness, Material, Pressure }

l Config Model { name e "Finite Element Mesh",

entities = { Region, ... }

}

3.6 Aplicação no modelador de subdivisões hierárquicas

A estratégia de configuração apresentada na seção anterior pode ser aplicada num modelador · de subdivisões planares hierárquicas, que utiliza a base de dados proposta no Capítulo 2. Com isto, obtém,se um ambiente para modelagem genérico, configurável através da especificação dos atributos associados às entidades topológicas face, aresta e vértice.

Basicamente, o ambiente de configuração representa o módulo cliente na arquitetura do modelador (seção 2.5.4). Respeitando a estratégia de comunicação entre a aplicação e o ambiente de configuração, identificamos os conjuntos de operadores necessários para acoplar os serviços de configuração ao modelador. O operadores de consulta, que tipicamente informam sobre as relações de adjacências entre as entidades topológicas, são disponibilizados para o ambiente de configuração. Através destes operadores, o usuário configurador pode acessar informações da base de dados para validar semanticamente as edições. Os operadores de atribuição estão disponibilizados pelo sistema de configuração. À aplicação resta projetar uma interface adequada para acessar esses operadores, a fim de permitir a associação de atributos às entidades face, aresta e vértice.

3.6.1 Operações de validação semântica

Deve existir um operador de validação semântica para cada um dos operadores básicos da estrutura de dados. Assim, após a execução de cada operador básico, através das ca!lbacks de eventos, o módulo cliente da estrutura acessa o operador de validação correspondente escrito pelo configurador. Se o configurador invalidar a operação, o gerenciador da estrutura utiliza os recursos de undo para desfazer a operação na base de dados.

Neste ponto, existem dois aspectos que devem ser analisados. Primeiro, optamos por fazer a validação semântica sobre cada uma das operações básicas, ao invés de realizá-la sobre as operações de alto nível. Isto se deve ao fato de ser muito mais simples para o configurador validar ações simples do que tratar de ações complexas que geram.diversas alterações na base. de dados. Além disso, como cada operador básico atua localmente, o gerenciamento dos atributos associados às entidades é facilitado. Outro aspecto está relacionado com o fato de primeiro realizar a operação na base de dados e depois fazer a validação semântica. Esta ordem é importante pois o configurador, além de validar semanticamente a operação, gerencia os atributos das novas entidades já incorporadas na estrutura.

62

3.6.2 Feedback e operações de entrada e saída

A possibilidade do configurador poder associar feedbacks gráficos aos atributos aplicados nas entidades do modelo é de fundamental importância para o desenvolvimento de programas com interfaces adequadas. Outra funcionalidade imprescindível é a exportação e importação do modelo num formato próprio que una as descrições geométricas e topológicas das entidades com as descrições dos atributos a elas associados (operações de entrada e saída para persistência do modelo já são oferecidas pelo gerenciador de subdivisões planares e pelo ambiente de configuração).

Estas funcionalidades podem ser implementadas através dos . operadores adicionais na comunicação entre a aplicação e o ambiente de configuração. Para prover feedback gráfico aos atributos associados às entidades, podemos optar por duas estratégias distintas. Na primeira, disponibiliza-se para o configurador o acesso aos atributos gráficos associados às representações geométricas das entidades topológicas, representados pelas classes Fill, Frame e Point, no gerenciador de subdivisões planares (seção 2.4.4). Com isto, o configurador pode projetar (ou mesmo permitir que o usuário final defina) as aparências gráficas das entidades conforme as instâncias de atributos a elas associadas.

Na segunda estratégia para prover feedback gráfico, permite-se que o configurador acople representações gráficas às entidades com atributos. Esta estratégia é muito útil para modelos de engenharia, onde é comum se ter símbolos que representam os atributos ( e.g., representação de carregamentos através de uma seta com o sentido da força aplicada). Para implementar esta estratégia, deve ser possível ao configurador criar representações gráficas no ambiente de configuração. Esta característica é apresentada na ferramenta EDG desenvolvida para dar suporte aos serviços de configuração (seção 3.4.1.2).

Por fim, para implementar as funções de entrada e saída formatadas, incluem-se dois operadores adicionais acessados pela aplicação: operador de saída e operador de entrada. Para implementar o operador de saída, o configurador acessa os dados da estrutura através dos operadores de consulta e pode associá-los às descrições dos atributos, já que tem acesso às instâncias aplicadas. A Figura 3.15 ilustra a arquitetura de comunicação desta operação.

A n1birnte de confiv1racão

Atributos e instâncias

\

Op('radvr adicional de suÍÚl1

Estrutura de ,---~

função de

saída

~ dados ~er11d~re.1 L-------'

ór .COT1'1"11lla

-·t-······ ô

Figura 3.15: Arquitetura para operações de salda.

63.

Para implementar o operador de entrada, deve-se prever a possibilidade de cnaçao de entidades a partir do ambiente de configuração. Para tanto, disponibilizam-se, ao ambiente de configuração, operadores para realiz.ar estas operações. A Figura 3.16 ilustra a arquitetura de comunicação desta operação.

Ambiente de cor:zfi_guracâo

Atributos e instáncias

função de

entrada

Estrutura de dados

Figura 3.16: Arquitetura para operações de en.trada.

A Figura 3.17 ilustra a arquitetura final do gerenciador de subdivisões planares hierárquicas configurável. O programador da aplicação acessa a estrutura de dados e o sistema de configuração. O programador de aplicação também disponibiliza acesso ao módulo cliente para o ambiente de configuração. O configurador da aplicação acessa os serviços oferecidos pelo sistema de configuração, instanciando objetos de interface da ferramenta EDG e tendo acesso ás funcionalidades inerentes à linguagem Lua. Para validar semanticamente as operações ocorridas na mestrutura de dados, o configurador usa o acesso ao módulo cliente disponibilizado pelo programador da aplicação.

Aplicação

configurável 1 Configuração 1

\~ ~ r,::;=::i "'-.. ~S-i-st_e_m_a_d_e~ L'.:::J configuração

Gerenciador

/ Estrutura

HPS

Figura 3.17: Arquitetura final do gerenciador de subdivisões planares hierárquicas.

4. Conclusão

Esta tese aborda três tópicos que se mostraram relevantes para o desenvolvimento de diversas aplicações gráficas interativas dentro do convênio PUC-RiofTeCGral - PETROBRAS/CENPES:

representação de subdivisões planares hierárquicas, configuração de aplicações e criação de interfaces interativas. As propostas e ferramentas apresentadas estão sendo utilizadas para o desenvolvimento de aplicações em diversas áreas. A estrutura de dados para subdivisões planares hierárquicas tem aplicação natural para o desenvolvimento de geradores de malhas de elementos finitos, simuladores de transformações geológicas e representação de mapas e sistemas geográficos de informações. Os serviços de configuração via especificação de atributos foram aplicados no modelador de subdivisões planares e em programas para geração de malhas de elementos finitos. A ferramenta para criação de interfaces foi diretamente empregada para dar suporte aos serviços de configuração propostos. Esta ferramenta também tem sido amplamente utilizada para o desenvolvimento de programas de interface (Apêndice B) e como ferramenta auxiliar para programação das tarefas de interação das aplicações.

Dentro de cada um dos tópicos apresentados, acreditamos que este trabalho tem uma contribuição significante, seja através da exposição de novas estratégias para atender aos requisitos que se fazem necessários, seja na implementação e disponibilização de ferramentas que podem ser amplamante utilizadas em aplicações computacionais de diversas áreas.

As seções seguintes fazem urna análise conclusiva do trabalho apresentado e sugere futuros trabalhos que representam continuidade das pesquisas realizadas.

4.1 Representação de subdivisões planares hierárquicas

As estruturas topológicas têm sido empregadas com sucesso. para representação de subdivisões do espaço nas mais diversas áreas. Muitas aplicações apreséhtam urna natureza hierárquica e a representação desta hierarquia tem sido feita através de artifícios sobre as estruturas topológicas convencionais.

Apresentamos uma estrutura topológica capaz de representar subdivisões planares hierárquicas, utilizando uma única base de dados. A estrutura proposta busca minimizar a representação do modelo como um todo e impede a duplicidade de informações em níveis hierárquicos distintos. A disposição das entidades faces e arestas em estruturas de árvores, associada à utilização de listas com múltiplos elos nos encadeamentos dos usos das arestas, possibilita a obtenção das relações de adjacência convencioncais em cada nível hierárquico e das relações de adjacência entre entidades de níveis diferentes. Esta base assegura a execução das operações para alteração do modelo utilizando apenas buscas locais.

Propôs-se urna arquitetura para gerenciamento da estrutura de dados permitindo que o módulo cliente caracterize a semântica associada ao modelo. Com isto, a estrutura assegura a validação sintática das edições, respeitando as propriedades de subdivisões planares

65

enumeradas, e deixa a cargo do cliente a validação semântica destas edições. Essa estratégia possibilita a aplicação da base de dados em diferentes domínios.

4.2 Configuração de aplicações via especificação de atributos

Configuração de aplicações é urna estratégia válida de re-uso de software, pois pennite reaproveitar tecnologias sofisticadas implementadas pelas aplicações. O acesso programável a essas tecnologias deve ser feito através de uma linguagem configurável, a fim de evitar a proliferação de peqúenas linguagens específicas e propiciar urna sintaxe básica unifonne para a configuração. Existem diversos agentes envolvidos no desenvolvimento de aplicações configuráveis, e esses agentes trabalham com níveis crescentes de abstração.

A configuração de aplicações via a especificação de atributos é adequada, pois, em muitas aplicações técnico-científicas, são os atributos que caracterizam a semântica associada ao modelo representado. Neste trabalho, formalizamos a comunicação entre a aplicação e o ambiente de configuração através de operadores, evitando que as aplicações incorporem características próprias das configurações. O fato de a aplicação não armazenar nem ter acesso aos atributos aplicados facilita o acoplamento dos serviços de configuração em aplicações já existentes.

A estruturação do modelo de configuração proposta permite a composição hierárquica de atributos e parâmetros e define o escopo de aplicabilidade do sistema de configuração proposto. A definição dos atributos com codificação descritiva possibilita que usuários com pouco conhecimento de programação convencional configurem as aplicações com adequado grau de abstração. A possibilidade de definir comportamentos e validações próprios dos atributos através da redefinição dos métodos básicos toma o sistema de configuração versátil, podendo ser aplicado em diversas áreas específicas.

4.3 Ferramenta para criação de interfaces gráficas interativas

Oferecer acesso facilitado a objetos de interface é requisito básico para a construção de ferramentas de configuração para· aplicações interativas. O sistema EDG oferece acesso facilitado a objetos de interface convencionais e objetos gráficos estruturados. Na instanciação dos objetos gráficos, observa-se que criar desenhos com um editor gráfico é mais rápido, mais criativo e menos sujeito a erros do que programá-los usando bibliotecas gráficas convencionais. Além disso, a possibilidade de associar nomes a grupos de primitivas de um desenho permite a criação de objetos gráficos "ativos", cujos comportamentos podem ser adequadamente programados.

A programação de interfaces gráficas usando eventos abstratos, como click e drag, parece ser adequada a programadores ocasionais na criação de objetos de interface específicos ao seu domínio de interesse. A combinação destes eventos permite a programação de tarefas de interface com alto grau de interatividade.

O sistema EDG tem sido usado como suporte para os serviços de configuração e acoplado a aplicações, para facilitar a programação da interface pelo próprio programador da aplicação.

66

4.4 Trabalhos futuros

Conforme apresentado na introdução, este trabalho é parte de uma linha de pesquisa com domínios abrangentes. Com relação à estrutura de dados proposta, uma expansão natural é a incorporação de novas formas geométricas para a representação das curvas associadas às arestas. É necessário pesquisar mecanismos que permitam o armazenamento das geometrias em banco de dados, a fim de permitir o tratamento de representações complexas, como mapas digitalizados. Outro fator importante, ainda dentro deste contexto, é a implementação de mecanismos para se obter multi-resolução geométrica das curvas que caracterizam as arestas do modelo.

A proposta apresentada para representação da hierarquia pode ser estendida para subdivisões espaciais tridimensionais, tendo como base estruturas de dados para a representação do contorno (b-rep), como a radial edge. Para tanto, propõe-se um processo análogo ao feito para o caso bidimensional. Devem-se armazenar as entidades divisíveis em estruturas de árvores, usar elos múltiplos nas entidades que podem estar associadas a mais de um nível, estender os operadores da estrutura para atuarem em diversos níveis ao mesmo tempo e projetar novos operadores que permitam cópias de entidades em níveis inferiores.

Com relação à proposta para configuração de aplicações via especificação de atributos, é necessário testar sua aplicabilidade em sistemas de áreas diversas. Além dos aplicativos desenvolvidos sobre uma base para representação de subdivisões espaciais, acredita-se que o modelo de configuração também é adequado para aplicações que trabalham sobre a representação· de diagramas (controladores de processos químicos, controladores de distribuição de energia, etc.).

Quanto ao sistema para criação de interfaces interativas, prevê-se a criação de um ambiente integrado, onde o programador possa instanciar graficamente objetos de interfaces tradicionais e objetos gráficos, tendo acesso à programação procedimental da linguagem Lua.

Nesta direção, está sendo feita uma pesquisa que permite a instanciação e manipulação de objetos procedimentais em editores gráficos, usando a descrição dos objetos gráficos em Lua, conforme é feito no EDG.

Por fim, acreditamos que o modelador configurável de subdivisões planares hierárquicas possa ser usado por diversas aplicações computacionais, servindo de base para o desenvolvimento de pesquisas nas áreas de Engenharia, Geologia, Cartografia e Geografia, entre outras.

Apêndice A Cálculo de interseção de segmentos com tolerâncias

Diversos algoritmos têm sido apresentados para tratar problemas de interseção de segmentos de reta 2D (Paeth, 1990; Prasad, 1991; Shaffer e Feustel, 1992). Esses diferentes propostas visam obter eficiência e precisão no càlculo das interseções. Para modelar subdivisões planares, através de inserções de pontos e curvas interativamente, precisamos trabalhar com o conceito de tolerância. Distâncias menores que a toleráncia são desprezadas. Com isto, a igualdade entre dois pontos (Figura A. J) é testada de maneira ·simples pela inequação mostrada a seguir:

(1)

Figura A.1: Igualdade de pontos considerando tolerâncias.

Entretanto, a interseção entre segmentos de reta merece uma análise mais detalhada. Com o conceito de tolerâncias distintas nas direções ortogonais X e Y, existe um campo de atração envolvendo o segmento que deve ser considerado, conforme é mostrado na Figura A.2 (análogo ao feito para um ponto simples). O campo de atração é conseguido fazendo com que a "caixa" de atração de um vértice extremo seja arrastada até a outra extremidade. Qualquer ponto dentro da área de atração é considerado sobre o segmento.

Figura A.2: Campo de atração de um segmento de reta.

O cálculo de interseção de segmentos com tolerâncias recai no cálculo de interseções convenciónal se garantirmos que nenhum ponto extremo de um segmento está dentro da área de atração do outro segmento, e vice-versa. Portanto, o problema consiste em determinar se

68

um dado ponto está dentro da área de atração de um segmento de reta e, se estiver, qual o valor da interseção (valor parametrizado) do ponto sobre o segmento de reta.

Para calcularmos se um ponto é atraído por um segmento, podemos comparar a área do triângulo formado pelo ponto e pelo segmento com a área limite, definida pela área do triângulo formado por um ponto no extremo da área de tolerância e pelo segmento. Se a área correspondente ao ponto for menor que a área limite, significa que ele é atraído pelo segmento de reta. Para chegarmos a equação final, considera-se primeiramente a equação da reta que passa pelo segmento.

a.x+b.y+c=O

A distância entre um ponto e esta reta é dada por:

d= Ass(ª·)+b.y, +e) a' +b'

A equação de uma reta que passa por dois pontos é dado por:

ou

Se a reta passar pela origem, tem-se:

dy.x-dx.y= O

(2)

(3)

(4)

(5)

(6)

Usando esta equação, e aplicando a Equação 3, a distância do centro da caixa de tolerância ao segmento de reta, se esta tangencia o segmento (Figura A.3), é dada por:

y

fol\

Figura A.3: Distáncia do centro de tolerância ao segmento.

69

.:__ (dy(-to!X)-dx(to!Y)J h-ABS J 2 2 dy +dx (7)

Então, aplicando a fórmula da ãrea de um triângulo, a ãrea entre um ponto que tangencia a ãrea de atração e o segmento (que representa a base do triângulo) é:

2Alim = dy.to!X + dx.to!Y (8)

Com isto, para descobrir se um ponto é atraído pelo segmento, basta verificar se a área formada pelo ponto e os pontos extremos do segmento é menor que a área fornecida pela equação acima. O cálculo da área entre três pontos pode ser dada por:

(9)

Se o ponto é atraído pelo segmento, o valor parametrizado da interseção, calculado aplicando­se rotação (Figura A.4 ), é dado por:

(10)

dx.d>:p +dy.dyp 1 = dx' +dy2 (11)

)'

----r+---- • p

dy d;·,

Figura A.4: Cálculo do parâmetro por rotação.

Apêndice B Construção de programas de interfaces

A crescente demanda por software nas diversas áreas do conhecimento humano implica num maior número de pessoas diretamente envolvidas com o processo de desenvolvimento de programas. Em geral, esses programadores recém-chegados são profissionais qualificados nas áreas específicas em que atuam, mas com poucos conhecimentos em computação. No entanto, com a difusão de computadores pessoais poderosos e a existência de diversos programas batch que implementam tecnologias sofisticadas, invariavelmente eles necessitam criar interfaces adequadas para acessar essas tecnologias. Para possibilitar o trabalho desses programadores ocasionais, são necessanas meta-ferramentas que permitam o desenvolvimento de ferramentas específicas com interfaces adequadas para acessar tecnologias já implementadas. As meta-ferramentas devem apresentar elevado. grau de abstração. Não se pode exigir que esses programas específicos sejam desenvolvidos através dos princípios da engenharia dt software (Cowan et aL 1992), pois a prioridade é implementar as funcionalidades que são requeridas. Cabe aos profissionais em sistemas de computação prover meios para que esses programadores possam desenvolver seus próprios programas de urna maneira simples e eficiente.

Meta-ferramentas são programas que auxiliam no desenvolvimento de ferramentas específicas. Neste contexto, o sistema EDG apresenta-se corno uma meta-ferramenta para auxiliar o desenvolvimento de programas de interface que viabilizam o aproveitamento de tecnologias já implementadas.

Características dos programas de interface

Programas de interface são front-end que representam acesso a tecnologias específicas implementadas em sistemas maiores. Assim, os programas desenvolvidos são transformadores de dados. Suas funcionalidades principais baseiam-se na captura e transformação de dados para serem interpretados por outros sistemas; ou na aquisição e transformação de dados para serem interpretados pelos próprios usuários.

Por representarem interfaces, esses programas necessitam de recursos gráficos para serem implementados. É necessário prover acesso facilitado a objetos de interface tradicionais para composição de diálogos e mecanismos para criação de objetos de interfaces específicos, projetados para atender às funcionalidades específicas da aplicação. Para possibilitar a transformação dos dados, também são necessários recursos para manipulação e estruturação de informações. Construções estruturadas, bibliotecas de suporte e operações de entrada e saída devem estar disponíveis.

Estes requisitos são atendidos pelo sistema EDG que oferece acesso aos objetos de interface e permite que o programador use os recursos da linguagem Lua para estruturar, transformar e processar os dados capturados.

71

Um domínio típico para desenvolvimento de programas de interface é encontrado nos simuladores numéricos da área de engenharia. Diversos programas de simulação são desenvolvidos selJl uma interface adequada para a entrada dos dados, dificultando, ou mesmo inviabilizando, sua utilização. Interfaces grãficas são apropriadas para esse domínio, pois é comum existir representações gráficas que caracterizam a natureza dos dados a serem especificados. A Figura B. I ilustra um modelo de um vaso de pressão, com seus respectivos bocais. Para a captura dos dados que definem as características desse vaso, é conveniente que uma representação gráfica do vaso seja usada como objeto de interface, através do qual. o usuário informa os parâmetros necessários à simulação. Deste modo, pode-se programar urna interface onde o usuário aponta os diversos bocais do vaso cujos dados devem ser especificados. O programa pode prover um feedback adequado, indicando vi.sualmente que bocais ainda têm seus dados não fornecidos.

o

Figura B.1: Representação de um vaso de pressão 1 •

Processo de desenvolvimento de aplicações EDG

A Figura B.2 ilustra as etapas de trabalho no desenvolvimento de programas de interface utilizando o sistema EDG. O programador da aplicação utiliza o programa TeCDraw para construir os desenhos que são necessários. Através de um editor de texto, o programador escreve o código do programa usando a linguagem Lua. Nesse código, o programador pode instanciar diálogos acessando os objetos de interface, bem como codificar a manipulação dos objetos gráficos. Usando as funções básicas de Lua, o programador implementa mecanismos para salvar, carregar e transformar os dados fornecidos pelo usuário.

Durante a execução, o sistema EDG interpreta o código gerado pelo programador e o metafi/e gerado pelo TeCDraw. Na aplicação final, o usuário pode interagir com o programa e efetuar operações de entrada e saída de dados.

1 Representação extra Ida do programa Vasos desenvolvido pelo TeCGraf para a PETROBRAS/CENPES/DIPROM.

72

Figura B.2: Desenvolvimento de aplicações no EDG.

O sistema EDG tem sido usado no desenvolvimento de diversos programas de interface para acessar tecnologias implementadas em programas batch. Tipicamente, a comunicação entre os sistemas é feita através de arquivos, não requerendo que os programas existentes sejam modificados (muitos deles são "caixas pretas"). Assim; os dados são capturados através dos recursos de interface oferecidos pelo EDG, estruturados e transformados através dos recursos oferecidos pela linguagem lua e armazenados no formato requerido pelos sistemas que os processarão. O formato de saída da simulação pode ser interpretado, provendo ao usuário recursos para interpretação gráfica dos resultados. Neste. sentido, o EDG é uma ferramenta para construção defront-end de programas batch (Figura B.3).

Prog. de lnlerface

Programa batch 8 + /

ô ,1~-l, ~P"'I?_+ __ dr~ /

lnterface

Figura 8.3: Etapas da simulação com o uso de programas de interface.

Os recursos do sistema EDG também têm sido usados para a programação de interfaces de aplicações em desenvolvimento. Esta estratégia permite a prototipagem da interface e facilita o acoplamento de serviços de configuração às aplicações.

Referências

Ballard, D. H., "Strip Trees: A Hierarquical Representation for Curves", Communications of the ACM, 24 (5), 310-321, 1981.

Bartlett, J. F., "Don't Fidget with Widgets, Draw!", WRL research Report 9116, DECIWRL, 1991.

Baumgart, B., "Winged-Edge Polyhedron Representation", Stanford Artificial lnteligence, report no. CS-320, 1972.

Bentley, J, "Prograrnming Pearls: Little Languages", Communications of lhe ACM, 29, 711-721, 1986.

Betz, M., "Inter Operable Objects", Dr. Dobb's Journal 220, 18-38, October, 1994.

Bruegger, B. P., A. U. Frank, "Hierarchies over topological data structures", Technical papers ASPRSIACSM, 137-145, 1989.

Campos, J. A. P. de, "Geração de malhas de elementos finitos bidimensionais baseada em uma estrutura de dados topológica", Dissertação de Mestrado, Depto. de Eng. Civil, PUC­Rio, 1991.

Carvalho M. T. M. de, "Uma estratégia para o desenvolvimento de aplicações configuráveis em mecânica computacional'', Tese de Doutorado (em conclusão), Depto. de Eng. Civil, PUC-Rio, 1995.

Carvalho, P. C. P., M. Gattass and L. F. Martha, "A software too! which allows interactive creation planar subdivisions and applications to educational", CAT'S 90, E. Oiiate et ai. (Eds.), Barcelona, 1990.

Cavalcanti, P. R., P. C. P. Carvalho e L. F. Martha, "Criação e Manutenção de Subdivisões Planares", Anais do SJBGRAPJ IV, 13-24, 1991.

Cavalcanti, P. R., "Criação e Manutenção de Subdivisões do Espaço'', Tese de Doutorado, Depto. de Informática, PUC-Rio, 1992.

Ceies Filho, W., L. F. Martha, M. Gattass e M. Ferraz, "Gerenciamento de subdivisões do plano utilizando HED'', Caderno de ferramentas do VII Simpósio Brasileiro de Engenharia de Software, 51-52, 1993

Ceies Filho, W., M. Gattass e P. C. P. Carvalho, "Gerenciamento de Subdivisões Planares Hierárquicas", Anais do VII SJBGRAPI, 287-294, l 994a.

Ceies Filho, W., L. H. de Figueiredo, M. Gattass e R. Jerusalimschy, "Estratégias de re-uso de software no TeCGraf', Monografias em Ciência da Computação 20194, Depto. de Informática, PUC-Rio, 1994b.

74

Ceies Filho, W., L. H. de Figueiredo e M. Gattass, "EDG: uma ferramenta para criação de interfaces gráficas interativas", artigo submetido ao VIII SIBGRAPI, 1995.

Ceies Filho, W. e M. Gattass, "Configuração de aplicações via especificação de atributos", . artigo submetido ao IX Simpósio Brasileiro de Engenharia de Software, 1995.

Chang, S., Principies of Visual Programming Systems, Prentice-Hall, 1990.

Clark, J. D., Windows 3.1 - OLEIDDE: guia do usuário, Ed. Ciência Moderna, 1992.

Cook, R. D., D. S. Malkus e M. E. PLesha, Concepts and Applications of Finite Element Analysis, 3ª edição, John & Sons, 1989.

Cowan, D. D. e R. G. Veitch, "Composing Applications from Reuseable and Configurable Components",pre-print, Computer Systems Group, University ofWaterloo, 1992.

Cowan, D. D., R. Ierusalimschy e T. M. Stepien, "Programming · Environments for End­Users", Anais do l 2th World Computer Congress, vol. A-14, 5~0, 1992.

Egenhofer, M. J., E. Clementini e P. Di Feiice, "Evaluating inconsistencies among multiple representations",Advances in GIS Researchproceedings, vol. 2, 901-919, 1994.

Ferraz, M. F. R., "Reconstituição de Seções Geológicas Utilizando Subdivisões Planares, Transformações Geométricas e Computação Gráfica Interativa", Dissertação de Mestrado, PUC-Rio, Depto. de Informática, 1993.

Figueiredo, L. H. de, C. S. de Souz.a, M. Gattass e L. C. G. Coelho, "Geração de interfaces para captura de dados sobre desenhos", Anais do V SJBGRAPJ, 169-175, 1992.

Figueiredo, L. H. de, M. Gattass, C. H. Levy, "Uma estratégia de portabilidade para aplicações gráficas interativas", Anais do VJ SJBGRAPI, 203-211, 1993.

Figueiredo, L. H. de, R. Ierusalimschy e W. Ceies Filho, "The design and implementation of a language for extending applications", Anais do XXJ Semísh, 273-283, 1994.

Gattass, M., W. Ceies Filho e G. L. Fonseca, "Computação gráfica aplicada ao método dos elementos finitos", XIV Congresso Nacional de Matemática Aplicada e Computacional, CNMAC, SBMAC, Nova Friburgo, 1991.

lerusalimschy, R., L. H. de Figueiredo e W. Ceies Filho, "Reference manual of the prograrnming language Lua 2.1", Monografias em Ciência da Computação, Depto. de Informática, PUC-Rio, 1995.

Krueger, C. W., "Software Reuse", Communications of the ACM, October 1991.

Levine, J. R., T. M, D. Brown, Lex & Yacc, 2nd edition, O'Reilly and Associates, 1992 . . ,

Levy, C. H., "IUP/LED: uma ferramenta portátil de interface com usuário", Dissertação de Mestrado, Depto. de Informática, PUC-Rio, 1993.

15

Mãntylã, M., An lnlroduclion lo Solid Modeling Compuler, Science Press, 1988.

Martha, L. F., "Topological and geometrical modeling approach to numerical discretization and arbitrary fracture simulation in three-dimensions", Ph. D. Dissertion, Comei! University, Ithaca, N.Y., 1989.

Microsoft Corporation, Visual Basic Programmer's Guide, version 3.0, 1993.

Ousterhout, J. K., Tcl and lhe Tk toolkit, Addison-Wesley, 1994.

Paeth, A. W., "A fast 20 point-on-line test", Graphics Gems I, Academic Press Inc., 1990

Prasad, M., "Intersection of line segrnents", Graphics Gems II, Acadernic Press Inc., 1991.

Preparata, F. P. and M. lan Shamos, Compulalional Geometry - an introduction, Springer­Verlag, New York, 1990.

Puppo, E. e G. Dettori, "Towards a formal model for multiresolution spatial maps", Design and Implementalion of Large Spatial Databases, SSD '95, 1995.

Shaffer, C. A. e C. D. Feustel, "Exact computation of 2-D intersections", Graphics Gems III, Academic Press Inc., 1992.

Souza, C. S. de e D. J. Ferreira, "Especificações Formais para Linguagens Visuais de Programação", Anais do SIBGRAPI VII, 181-188, 1994.

TeCGraf, "MTOOL - Bidimensiona/ Mesh Too[ (versão 1.0), Manual do usuário", Grupo de Tecnologia em Computação Gráfica, PUC-Rio, convênio PETROBRÁS/CENPES, 1992.

TeCGraf, "PGM - Programa Gráfico Mestre (versão 1.1), Manual de utilização", Grupo de Tecnologia em Computação Gráfica, PUC-Rio, convênio PETROBRÁS/CENPES, 1994 .

. TeCGraf, "MI - Integrador e Editor e Malhas de Elementos Finitos, Manual do usuário", Grupo de Tecnologia em Computação Gráfica, PUC-Rio, convênio PETROBRÁS/CENPES, 1995.

Udell, J., "ComponentWare", BnE 19 (5), 46-56, May 1994.

Valdés, R., "Little Languages, Big Questions", Dr. Dobb's Journal 16 (9), 16-25, September 1991.

Vianna, A. C., "Modelagem geométrica para modelos bidimensionais de elementos finitos'', Dissertação de Mestrado, Depto. de Eng. Civil, PUC-Rio, 1992.

Wawrzynek, P. A., "lnteractive finite element of fracture proccess: an integrated approach", Departrnent ofStructural Engineering Report, Cornell University, lthaca, N. Y., 1987.

Weiler, K., "Topological structure for geometric modeling", Ph. D. Dissertion, Rensselaer Polytechnic Institute, Troy, N.Y., 1986.

Modelagem Configurável de Subdivisões Planares Hierárquicas

Tese de Doutorado apresentada por Waldemar Ceies Filho, em 04 de julho de 1995, ao Departamento de Informática da PUC-RIO e aprovada pela Comissão Julgadora formada pelos seguintes professores:

-RIO

Roberto Ierusalimschy - DI-PUC

12u,1/ Ronaldo Cesar Marinho P

arco Antônio Casanova - IBM

Luiz Fernando Martha - DEC-PUC-RIO

Visto e pennitida a impressão.

Rio de Janeiro, .2. de ~ de 1995.

} Coodenador dos Pro ª!Tf · ôe Pós-Graduação do Centro Técnic e Cientifico