Wladimir Braguini Domingues - IPTcassiopea.ipt.br/teses/2009_EC_Wladimir_Braguini.pdf · 2010-09-11 · Wladimir Braguini Domingues Linguagem Especíﬁca de Domínio para Governo

Instituto de Pesquisas Tecnológicas do Estado de São Paulo

Wladimir Braguini Domingues

Linguagem Específica de Domínio paraGoverno Eletrônico em Mídia Cruzada

São Paulo2009


Linguagem Específica de Domínio paraGoverno Eletrônico em Mídia Cruzada

Dissertação de Mestrado apresentada aoInstituto de Pesquisas Tecnológicas doEstado de São Paulo - IPT, como partedos requisitos para a obtenção do título deMestre em Engenharia de Computação

Data da aprovação: __ / __ / ____

Prof. Dra. Lucia Vilela Leite FilgueirasIPT – Instituto de Pesquisas Tecnológicasdo Estado de São Paulo

Membros da Banca Examinadora:

Prof. Dra. Lucia Vilela Leite Filgueiras (Orientadora)IPT — Instituto de Pesquisas Tecnológicas

Prof. Dr. Jose Eduardo Zindel Deboni (Membro)IPT — Instituto de Pesquisas Tecnológicas

Prof. Dr. João José Neto (Membro)EPUSP — Escola Politécnica da Universidade de São Paulo


Linguagem Específica de Domínio para

Governo Eletrônico em Mídia Cruzada

Dissertação de Mestrado apresentada ao

Instituto de Pesquisas Tecnológicas do

Estado de São Paulo - IPT, como parte

dos requisitos para a obtenção do título de

Mestre em Engenharia de Computação

Área de Concentração: Engenharia de

Software

Orientadora: Prof. Dra. Lucia Vilela Leite

Filgueiras

São Paulo

Dez/2009

Dedicatória

Dedico este trabalho aos meus avós, Zilda e Hermogenes Braguini (in memorian), porsempre acreditarem em mim e no valor da educação.

Agradecimentos

À minha orientadora Lucia, não só pela valiosa orientação, mas também pela amizadee compreensão.À minha esposa Luciana, pelo carinho, dedicação e, sobretudo, amor.À minha família, pela apoio constante e incondicional.Um agradecimento especial a todos do IPT por tornarem este trabalho possível.Ao Grupo de estudos em interação do PCS-LTS da Poli/USP, pelo convívio alegre,pelos momentos de descontração e pela troca de conhecimento.E a todos que, de alguma forma, contribuíram para essa minha vitória.Muito Obrigado!

RESUMO

Avanços tecnológicos criam novos meios de comunicação e ampliam osmodos de interação homem-computador proporcionando uma experiência de usopositiva. Um sistema de mídia cruzada se caracteriza pelo uso de múltiplos meiosde comunicação suportando um tema central ou conteúdo principal. Um temacentral que pode ser aplicado sobre múltiplas mídias é o de serviços de governo.Este trabalho objetiva projetar uma linguagem específica de domínio que consigaexpressar aspectos de serviços de governo em mídia cruzada. Com essa linguagemé possível modelar novos sistemas x-gov em um nível mais alto de abstração.

Palavras-chave: DSL, Serviços de Governo, x-gov, Mídia Cruzada.

ABSTRACT

Domain Specific Language for e-Government on Cross-Media

Technological advances creates new media that expands the modes ofhuman-computer interaction providing a positive experience of use. A cross-mediasystem is characterized by the use of multiple media, supporting a central theme orcontent. A central theme that can be applied over multiple media is the theme ofgovernment services. This work presents the design of a domain specific languagethat can express aspects of government services in cross-media. This languageallows modeling new x-gov systems in a high abstraction level.

Key Words: DSL, government services, x-gov, cross-media.

Lista de Ilustrações

Figura 3.1 Big Brother Brasil 9 [Fonte: Rede Globo (2009)] . . . . . . . . . . 36Figura 3.2 Cadeia de Conteúdo Digital [Fonte: Boumans (2004) - traduzido

pelo autor] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Figura 4.1 Composição de um X-Gov [Fonte: Elaborado pelo autor] . . . . . 43Figura 4.2 Arquitetura X-Gov [Fonte: Elaborado pelo autor] . . . . . . . . . 44Figura 4.3 ComponentModel [Fonte: Elaborado pelo autor] . . . . . . . . . . 45Figura 4.4 Componente GetTrackIdComponent [Fonte: Elaborado pelo autor] 47Figura 4.5 Padrões de Tarefas [Fonte: Elaborado pelo autor] . . . . . . . . . 48Figura 4.6 Modelo X-Gov [Fonte: Elaborado pelo autor] . . . . . . . . . . . 49Figura 4.7 Ferramenta gráfica para descrição de um serviço [Fonte: Elabo-

rado pelo autor] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51Figura 4.8 Configuração através do X-Builder e através da CroMeL [Fonte:

Elaborado pelo autor] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

Figura 5.1 Contexto da linguagem CroMeL [Fonte: Elaborado pelo autor] . . 55Figura 5.2 Mapeamento de contexto na linguagem CroMeL [Fonte: Elabo-

rado pelo autor] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57Figura 5.3 Etapas de implementação do interpretador CroMeL [Fonte: Ela-

borado pelo autor] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59Figura 5.4 Implantação de um script CroMeL [Fonte: Elaborado pelo autor] 64Figura 5.5 Interpretação de um script CroMeL [Fonte: Elaborado pelo autor] 65Figura 5.6 Grafo de dependência entre as regras sintáticas [Fonte: Elabo-

rado pelo autor] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

Figura B.1 Exemplo de classes de componentes . . . . . . . . . . . . . . . 99Figura B.2 Componentes FindEntityInfo para TV, Mobile e Web . . . . . . . 100Figura B.3 Componente GetPreServiceInfo para TV, Mobile e Web . . . . . 101Figura B.4 Classes de Transição . . . . . . . . . . . . . . . . . . . . . . . . . 101

Figura C.1 Diagrama de sintaxe da raiz da gramática . . . . . . . . . . . . . 111Figura C.2 Diagrama da sintaxe de declaração de um serviço . . . . . . . . 111Figura C.3 Diagrama da sintaxe dos elementos que pertencem a um serviço 111Figura C.4 Diagrama da sintaxe de uma atividade . . . . . . . . . . . . . . . 111

9

Figura C.5 Diagrama da sintaxe de declaração de parametros . . . . . . . . 111Figura C.6 Diagrama de sintaxe de transições . . . . . . . . . . . . . . . . . 112Figura C.7 Diagrama de sintaxe de navegação . . . . . . . . . . . . . . . . . 112Figura C.8 DFA reconhecedor dos Tokens da linguagem CroMeL . . . . . . 113Figura C.9 Ferramenta ANTLRWorks no desenvolvimento da CroMeL . . . . 114

Lista de Tabelas

Tabela 2.1 Padrões de Decisão [Fonte: Mernik et. al. (2005)] . . . . . . . . 27Tabela 2.2 Exemplos para os Padrões de Decisão [Fonte: Mernik et. al.

(2005)] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28Tabela 2.3 Padrões de Análise [Fonte: Mernik et. al. (2005)] . . . . . . . . . 29Tabela 2.4 Padrões de Projeto [Fonte: Mernik et. al. (2005)] . . . . . . . . . 29Tabela 2.5 Exemplos de linguagens para os Padrões de Projeto [Fonte: Mer-

nik et. al. (2005)] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30Tabela 2.6 Sistemas e Ferramentas de Desenvolvimento de Linguagem

[Fonte: Mernik et. al. (2005)] . . . . . . . . . . . . . . . . . . . . . . . . 31Tabela 2.7 Padrões de Implementação para DSLs executáveis [Fonte: Mer-

nik et. al. (2005)] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Lista de Códigos

5.1 Raiz da linguagem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 675.2 Sentenças de entrada para um serviço e declaração de variáveis . . . . 675.3 Gramática para descrição das ativadades de um serviço . . . . . . . . . 685.4 Sentenças de entrada para uma atividade . . . . . . . . . . . . . . . . . 685.5 Gramática para declaração de transições e navegações . . . . . . . . . 695.6 Sentenças de entrada para transição e navegação . . . . . . . . . . . . 705.7 Regras léxicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 705.8 Script CroMeL de entrada . . . . . . . . . . . . . . . . . . . . . . . . . . 735.9 Semântica de declaração de variável . . . . . . . . . . . . . . . . . . . . 755.10 Semântica de uma atividade . . . . . . . . . . . . . . . . . . . . . . . . 765.11 Semântica de navegação . . . . . . . . . . . . . . . . . . . . . . . . . . 775.12 Semântica de uma transição . . . . . . . . . . . . . . . . . . . . . . . . 785.13 Semântica dos parâmetros de componentes e transições . . . . . . . . 785.14 Semântica de expressões . . . . . . . . . . . . . . . . . . . . . . . . . . 795.15 Semântica de um Serviço . . . . . . . . . . . . . . . . . . . . . . . . . . 805.16 Codigo de Saida . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81C.1 Gramatica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102C.2 Semantica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104C.3 XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114C.4 Cromel Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116C.5 Component Factory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

Lista de Abreviaturas e Siglas

G2C Governo-Cidadão.x-gov Serviço de governo sobre mídia cruzada — cross-media

government.FXG Arcabouço de software para apoiar a criação de

serviços x-gov — Framework X-Gov.GPL General Purpose Language.DSL Domain-Specific Language.CroMeL Cross-Media Language.EDSL Embedded Domain Specific Language.IETF Internet Engineering Task Force.W3C World Wide Web Consortium.Mime Multipurpose Internet Mail Extensions.HTTP Hypertext Transfer Protocol.ANTLR ANother Tool for Language Recognition.YAML YAML Ain’t Markup Language.XAML eXtensible Application Markup Language.XUL XML User Interface Language.VB Visual Basic.

JSF Java Server Faces.EJB Enterprise Java Beans.IHC Interação Homem-Computador.CTA call-to-action.LP Linguagem de Programação.API Application Programming Interface.EBNF Extended Backus–Naur Form.AST Abstract Syntax Tree.IDE Integrated Development Environmnet.IPT Instituto de Pesquisas Tecnológicas.CMID Cross-Media Interaction Design.ORM Object Relational Mapping.AJAX Asynchronous JavaScript and XML.TDD Test Driven Development.MOP Meta-Object Protocol.

SUMÁRIO

1 INTRODUÇÃO 151.1 Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151.2 Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181.3 Resultados Esperados e Contribuições . . . . . . . . . . . . . . . . . . . . . 181.4 Método de Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191.5 Organização do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2 LINGUAGEM ESPECÍFICA DE DOMÍNIO 212.1 Abstrações e Linguagens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.2 Definição . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.3 Classificação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252.3.1 DSL Externa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252.3.2 DSL Interna . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262.4 Método de Desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . . . . . 262.4.1 Decisão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.4.2 Análise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282.4.3 Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292.4.4 Implementação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312.5 Considerações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3 MÍDIA CRUZADA E GOVERNO ELETRÔNICO 333.1 Mídia Cruzada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.1.1 Definição de Mídia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.1.2 Mídia Cruzada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.2 Governo Eletrônico em Mídia Cruzada . . . . . . . . . . . . . . . . . . . . . 373.2.1 e-gov, m-gov, t-gov, x-gov . . . . . . . . . . . . . . . . . . . . . . . . . . . 373.2.2 Serviços de Governo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383.2.3 Padrões de Tarefas para Serviços de Governo . . . . . . . . . . . . . . . . 39

4 FRAMEWORK X-GOV 424.1 Conceito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424.2 Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

14

4.2.1 Modelo de Domínio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444.2.2 Componentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464.3 Partes Integrantes do Framework . . . . . . . . . . . . . . . . . . . . . . . . 484.3.1 Gerenciador de Componentes . . . . . . . . . . . . . . . . . . . . . . . . . 504.3.2 Gerenciador de Transições . . . . . . . . . . . . . . . . . . . . . . . . . . . 504.3.3 Linguagem de Configuração . . . . . . . . . . . . . . . . . . . . . . . . . . 504.4 Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

5 A LINGUAGEM CroMeL 545.1 Introdução a CroMeL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545.1.1 Elementos da linguagem CroMeL . . . . . . . . . . . . . . . . . . . . . . . 555.1.2 Implementação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 595.2 Gramática . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 655.3 Semântica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 725.4 Discussão dos Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

6 CONCLUSÕES 856.1 Análise dos Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 866.2 Reflexões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 886.3 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

REFERÊNCIAS 91

APÊNDICES 95

A Exemplos de DSLs 96A.1 jMock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96A.2 API Fluente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

B Framework X-Gov 98B.1 Diagrama de Classes do FrameworkLibrary . . . . . . . . . . . . . . . . . . 98

C Implementação da CroMeL 102C.1 Regras Léxicas e Sintáticas da CroMeL . . . . . . . . . . . . . . . . . . . . . 102C.2 Regras Semânticas da CroMeL . . . . . . . . . . . . . . . . . . . . . . . . . 104C.3 Diagramas de Sintaxe da Linguagem CroMeL . . . . . . . . . . . . . . . . . 111C.4 Autômato Finito Determinístico da Linguagem CroMeL . . . . . . . . . . . . 113C.5 ANTLRWorks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114C.6 CroMeL XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114C.7 CromelService para Interpretador na versão C# . . . . . . . . . . . . . . . . 116C.8 ComponentFactory para Interpretador na versão C# . . . . . . . . . . . . . . 122

15

1 INTRODUÇÃO

A cada nova invenção concebida no transcorrer da história, o homem viu-seobrigado a descobrir meios de interagir com elas e, na maioria das vezes, a neces-sidade levou-o além, tornando-o capaz de ressignificar a função para a qual o objetofora originalmente pensado. Sharp et al. (2007) explicam:

Avanços nas interfaces gráficas, reconhecimento de fala e escrita, juntocom a chegada da Internet, telefones celulares, redes sem fios, tecnolo-gias de sensores e um conjunto de outras tecnologias disponíveis comtelas grandes e pequenas, mudaram como se dá a interação homem-computador[. . . ] Por exemplo, maneiras inovadoras de controlar e interagircom informações digitais foram desenvolvidas, o que inclui reconhecimentode gestos, interfaces sensíveis, e até a interação estimulada pela emoção.Pesquisadores e desenvolvedores começaram a combinar o mundo físicocom o digital, resultando em novas interfaces[. . . ] Com isso o projeto denovas interfaces vai além do usuário individual, suportando interações so-ciais de pequena e grande escala para pessoas em trânsito, em casa, ouno trabalho.

No mundo atual, onde as informações são produzidas em todo lugar e cadavez mais acessíveis por meios diversos, deve-se aproveitar essas características paracriar recursos melhores com o objetivo de facilitar novos tipos de interação.

1.1 Motivação

Cross media can be defined as the collaborative support of multiple mediato delivering a single story or theme, in which the storyline directs the recei-ver from one medium to the next, according to each medium’s strength tothe dialogue. (Filgueiras et al., 2008)

Um projeto de mídia cruzada pode ser visto como: “Uso de conteúdo sobre váriosdispositivos suportando um tema central.” Neste caso, o tema central será um serviçode governo.

Conforme defendido por Boumans (2004), o essencial ao conceito de mídiacruzada (cross-media) é que exista mais de uma mídia ou dispositivo de distribuição

16

para suportar o tema central ou conteúdo principal de um projeto com suas própriasforças. Assim, a informação é distribuída em múltiplas mídias ampliando as formas deacesso ao conteúdo, para o qual muda o paradigma de um usuário interagindo comum computador desktop, e possibilita o acesso a informações e serviços também pelaTV, telefone fixo ou celular, além da mídia impressa e do próprio computador desktop.A mídia cruzada é uma particularização importante do conceito de multimodalidade,no sentido de que há uma integração forte entre os meios (Filgueiras, 2007).

O governo necessita se comunicar de maneira eficiente e oferecer serviços aoscidadãos para cumprir na totalidade o seu papel. Sendo assim, poderia aproveitar-se das várias mídias disponíveis para ampliar as formas de comunicação. SegundoFilgueiras (2007), a mídia cruzada pode ser uma maneira promissora para ampliar ainteratividade Governo-Cidadão (G2C - Government to Citizen).

No entanto, existe uma grande dificuldade para desenvolver um sistema comapoio às características apresentadas devido à diversidade de tecnologias utilizadas(relacionadas a programação, interface, capacidade de rede e multimídia), sendo quecada programa necessita de um ambiente de execução apropriado. Esse ambientede execução, ou plataforma, é utilizado para construir e executar as aplicações quefazem parte do sistema. Pode-se observar facilmente que uma aplicação para um dis-positivo celular com apoio a apenas uma mídia poderia ser desenvolvida em diversasplataformas, como JavaME (Micro Edition), BREW, Symbian e .NET Mobile.

Um sistema em mídia cruzada envolve, normalmente, mais de uma aplicaçãoconstruída sobre diferentes tecnologias/plataformas. Deve ser projetado não apenaspara incluir as diversas aplicações, mas também coordená-las, transferir estado e es-truturar suas ações a serem executadas em conjunto para correto funcionamento dosistema. Portanto, visto dessa forma, um sistema em mídia cruzada torna-se com-plexo e distribuído.

Nesse contexto surge a necessidade de um framework que apóie a implemen-tação de sistemas em mídia cruzada.

Com o intuito de suprir essa necessidade iniciou-se, em 2007, o projeto X-Gov(Filgueiras, 2007), patrocinado pela Fundação de Amparo à pesquisa do Estado deSão Paulo (FAPESP) e Microsoft Research, com o objetivo de estudar a mídia cruzadacomo uma abordagem promissora para ampliar a interatividade entre o governo e ocidadão.

Em sua completude, o projeto X-Gov envolve uma série de sub-projetos, entreos quais se encontra esta proposta, que, quando reunidos, resultam em um arca-bouço de software (framework ) que facilita o desenvolvimento de serviços de governoutilizando diversos meios de comunicação. O propósito do Framework X-Gov é per-mitir um desenvolvimento rápido de aplicações, e para conseguir isso, conta com umconjunto de componentes de software, ferramentas de modelagem e uma aplicação

17

central que executa em um servidor web.No texto da proposta do projeto submetida à Fapesp foram colocadas sob enfo-

que as tendências mundiais referentes a governo eletrônico, e estas advogavam que,apesar dos aspectos positivos de comunicação e acessibilidade, o governo eletrônicotradicional seria suplantado pelo X-Gov, devido ao fato deste atingir o cidadão não so-mente pelo computador desktop, mas também pela televisão, telefone fixo ou celular,jornais, revistas, enfim, por múltiplas mídias. O cenário atual diferencia-se do projetoX-Gov por apresentar limitadas possibilidades de interação, uma vez que a experiên-cia do usuário restringe-se a um computador desktop, provavelmente em um centrode inclusão digital.

Considerando que estas interações ocorrem sobre diferentes plataformas e as-sociadas a elas estão diversas tecnologias, deve-se trabalhar em um nível de abstra-ção adequado, para construir sistemas que são constituídos de componentes distribuí-dos em vários dispositivos, sendo este nível de abstração, por sua vez, de importânciapara o tema desta dissertação; assim faz-se necessário um nível de abstração ade-quado para ser utilizado como ferramenta de modelagem no projeto X-Gov.

Buscar uma linguagem capaz de descrever os vários componentes contidosnos dispositivos de uma plataforma de mídia cruzada apresentou-se como uma opor-tunidade para explorar as diferenças entre um enfoque genérico e um específico apli-cado às disciplinas de engenharia de software. Assim, notou-se que um enfoque ge-nérico fornece soluções para muitos problemas, mas poderá não ser o mais adequadoquando se trata de um problema particular, enquanto que, um enfoque específico for-nece uma solução melhor para um pequeno grupo de problemas, porém sua utilizaçãoé limitada a essa classe de problemas, o que torna difícil sua aplicação em situaçõesdiferentes. Dentro dessa dicotomia em computação, encontra-se linguagens especí-ficas de domínio (DSLs) versus linguagens de propósito geral (GPLs) (van Deursenet al., 2000).

Segundo Brooks (1975) programadores criam instruções (statements), ou li-nhas de código, a uma taxa constante, portanto linguagens de mais alto nível sãomais produtivas. O uso de DSLs pode aumentar o nível de abstração aplicado naprogramação, podendo declarar, ou especificar o que deverá acontecer e deixar paracamadas inferiores, de interpretação, tratar de executar as instruções, uma caracterís-tica típica de linguagens declarativas ou de configuração.

A seguir são apresentadas algumas DSLs muito utilizadas, junto com seus res-pectivos domínios Jones (1996) apud Mernik et al. (2005):

• BNF (Backus–Naur Form): Especificação formal de sintaxe de linguagens;

• Excel: Manipulação de dados em planilhas;

• HTML: Páginas web com hipertexto;

18

• LATEX: Processador e formatador de textos;

• Make: Ferramenta para construção de software;

• MATLAB: Computação técnica matemática;

• SQL (Structured Query Language): Consulta a bancos de dados;

• VHDL (VHSIC hardware description language): Linguagem para descrição dehardware.

Linguagens específicas de domínio são importantes para o desenvolvimentode software porque representam uma maneira de codificar a solução de um problemade forma mais natural, com maior fidelidade e manutenabilidade do que as linguagensde propósito geral.

1.2 Objetivo

Essa pesquisa é motivada pela dificuldade em se criar sistemas constituídos dediversas tecnologias, característica intrínseca da mídia cruzada. Como as questõesde comunicação do governo com o cidadão são um forte fator motivador para aplicara mídia cruzada, faz-se necessário considerar uma forma de programação que facilitea criação de sistemas dessa natureza.

Dessa maneira, o principal objetivo desta pesquisa é elaborar uma linguagemespecífica de domínio que por meio de notações adequadas consiga expressar osconceitos de serviços de governo em mídia cruzada. Mais especificamente, a lingua-gem permite descrever quais são as etapas de um serviço, as mídias utilizadas e astransições entre mídias, além de servir para configurar os componentes utilizados den-tro de um processo de governo possibilitando assim disponibilizar aplicações sobre oFramework X-Gov.

1.3 Resultados Esperados e Contribuições

Esse trabalho tem como resultado prático, atendendo aos requisitos do mes-trado profissional, uma linguagem de programação que permitirá ao gestor públicodescrever os serviços de governo, auxiliando na criação de um sistema em ambientede mídia cruzada. Com auxílio dessa ferramenta, o gestor conseguirá implementar,validar e modificar os serviços com mais agilidade, já que para isso utiliza uma lingua-gem criada sob medida para esse problema.

Foi feito um ensaio da linguagem, aplicando-a na descrição de um cenário deserviço de governo, que pode ser utilizado para analisar o aspecto de como uma lin-guagem específica de domínio (DSL) pode contribuir para facilitar o desenvolvimento

19

de um novo sistema X-Gov. Esse ensaio, também serve de exemplo de script paraquem quiser utilizar futuramente esta linguagem.

O resultado deste trabalho contribui para o levantamento do vocabulário e adefinição de um modelo de domínio em sistemas de mídia cruzada, aplicado em go-verno eletrônico. O domínio e a linguagem poderão ser extrapolados para outra áreasde aplicações como jogos eletrônicos, publicidade, entretenimento, etc.

Entre as contribuições acadêmicas destacam-se o levantamento de referênciasque podem ser utilizadas para o desenvolvimento de linguagens específicas de domí-nio. Além disto, todo o código fonte está disponível para o uso no desenvolvimento denovas aplicações e para trabalhos futuros. Como contribuições adicionais, destacam-se a revisão de metodologias, ferramentas e técnicas para construção de uma DSL.

Este trabalho é parte integrante do projeto X-Gov e tornou-se a ferramenta demodelagem usada no framework, para definir novas aplicações.

1.4 Método de Trabalho

O desenvolvimento desta pesquisa segue as etapas listadas a seguir para atin-gir seu objetivo proposto:

Na etapa de revisão bibliográfica, obteve-se o estado da arte sobre lingua-gens específicas de domínio, com intuito de se determinar os conceitos, trabalhosrelacionados e método de desenvolvimento.

Em seguida, foi analisada a área de mídia cruzada, seu significado e aplicação,com destaque em serviços de governo. Posteriormente foram levantados os requisitosdo Framework X-Gov.

As referências teóricas o estudo da implementação de uma prova de conceitosão a base para proposta de uma nova linguagem que serve para modelar serviços degoverno sobre mídia cruzada. Na definição da sintaxe desta linguagem são analisadosos componentes do Framework X-Gov e as transições de mídias em três serviços degoverno simulados.

Após as considerações acima, têm início as fases clássicas de um projeto desoftware: análise, projeto, implementação e deployment.

Na fase de análise é descrito o modelo de domínio e são identificados os com-ponentes do Framework X-Gov associados aos padrões de tarefa. Assim pode-seagrupar o conhecimento em notações e operações úteis para a linguagem.

Na fase de projeto é criado um rascunho da DSL por meio do mapeamentodos conceitos de domínio com a implementação dos elementos do Framework X-Gov.

Observe que variabilidades indicam precisamente que informação é necessáriapara especificar uma instância do sistema. Essa informação deve ser especificadadiretamente em um programa da DSL ou derivada dele. Terminologia e conceitos são

20

utilizados para guiar o desenvolvimento das construções da DSL correspondente àsvariabilidades. O que é comum é utilizado para definir o modelo de execução (por umconjunto de operações comuns) e primitivas da linguagem.

Na fase de implementação as seguintes atividades foram executadas:

1. Construção da gramática da linguagem no nível léxico e sintático;

2. Construção de ações semânticas embutidas no reconhecedor gerado;

3. Construção de um conjunto de classes para servir como interface da linguagemcomo o framework.

Após a fase de implementação, foi necessário criar um mecanismo de deploy-ment para a linguagem ser instalada no Framework X-Gov.

Para efeito de avaliação da aplicabilidade da DSL, foi desenvolvida uma provade conceito para um serviço de agendamento médico que será utilizado como exemploposteriormente.

1.5 Organização do Trabalho

Este trabalho estrutura-se da seguinte forma:A Seção 1 é esta introdução.A Seção 2 intitulada LINGUAGEM ESPECÍFICA DE DOMÍNIO apresenta re-

visão da literatura do estado da arte sobre DSL, sua definição, os tipos, exemplos emetodologia de desenvolvimento.

A Seção 3 intitulada MÍDIA CRUZADA E GOVERNO ELETRÔNICO apresentauma breve descrição sobre os conceitos de mídia cruzada e serviço de governo ele-trônico.

A Seção 4 intitulada FRAMEWORK X-GOV apresenta as partes que consti-tuem o Framework X-Gov relevantes aos objetivos desse trabalho.

A Seção 5 intitulada A LINGUAGEM CroMeL introduz a linguagem CroMeL eapresenta seu projeto e implementação.

A Seção 6 intitulada CONCLUSÕES concentra os resultados obtidos e possí-veis direções para trabalhos futuros.

21

2 LINGUAGEM ESPECÍFICA DE DOMÍNIO

“Se sua única ferramenta é um martelo, você tende a ver todo problema como umprego.” (Abraham Maslow)

Este capítulo apresenta diversos trabalhos relacionados a linguagens especí-ficas de domínio com objetivo de definir seu conceito; a classificação dos diferentestipos existentes, e alguns exemplos para ilustrar as vantagens, técnicas de programa-ção e alternativas sobre métodos de desenvolvimento. Ainda serão analisados algunsprojetos e padrões que podem ser aplicados na solução proposta no capítulo 5.

Não existe um consenso entre os autores quanto à sigla DSL. Várias definiçõesforam criadas para a mesma como referenciadas em Mernik et al. (2005): linguagemorientada a aplicação (Sammet, 1969), linguagem de propósito especial (Wexelblat,1981), linguagem especializada (Bergin & Gibson, 1996), linguagem específica deuma tarefa (Nardi, 1993), linguagem específica de uma aplicação (Martin, 1985) elinguagens pequenas (Bentley, 1986).

2.1 Abstrações e Linguagens

Qual é a abstração ideal para uma aplicação particular? Segundo Hudak (1996)é uma linguagem de programação projetada para essa aplicação: deve capturar pre-cisamente a semântica do domínio do problema (nem mais, nem menos).

A Engenharia de Software e as linguagens atuais de programação propõemdiversos mecanismos de abstração: componentes, módulos, classes, objetos, tiposde dados abstratos, interfaces, funções de ordem superior, lambdas, monadas, con-tinuações, etc. Uma determinada linguagem de programação suporta melhor muitosdesses mecanismos do que outras.

Guy Steele Jr. 1 explica em Steele (1998):

[. . . ] um bom programador, nestes tempos, não apenas escreve progra-mas. [. . . ] um bom programador projeta uma linguagem, não do zero, massim a contrói a partir de uma linguagem base.

1Participou de comitês para especificação de linguagens como ECMAScript, C, Fortran, Scheme,*LISP, Java e mais recentemente Fortress

22

Considera-se que especialistas de um domínio possuem um vocabulário pró-prio que expressa conceitos dentro de um contexto particular, permitindo que façamafirmações sem explicar detalhes sobre o que estão falando, o que torna sua comu-nicação eficiente dentro do grupo no qual se insere. Pode-se ver que essa forma decomunicação acontece por meio de uma linguagem específica de domínio. Por exem-plo, um americano pode pedir um café no Starbucks da seguinte forma: “one nonfat, no whip, no foam, ventti half coffe latte” (um café com leite desnatado, tamanhogrande, sem expresso, sem espuma e sem chantilly 2) e, uma vez que fala dentro deum contexto, será corretamente interpretado.

van Deursen et al. (2000) destacam que ao longo do tempo as seguintes solu-ções foram adotadas para o desenvolvimento de aplicações:

1. Bibliotecas de subrotinas: contém subrotinas que executam tarefas relacionadasem um domínio bem definido como equações diferenciais, gráficos, GUI, bancosde dados — método clássico para reutilizar conhecimento de domínio.

2. Frameworks orientados a objetos e de componentes: Conjunto de classes quedefinem uma interface de programação (API) usada diretamente enquanto con-trola execução usando métodos fornecidos por um código específico da aplica-ção.

3. DSLs: linguagens pequenas, normalmente declarativas que oferecem expressi-vidade em um domínio de problema particular. Em muitos casos o programa étraduzido para chamadas de uma biblioteca comum e a DSL pode ser vista comouma maneira de esconder os detalhes dessa biblioteca.

2.2 Definição

Linguagem Específica de Domínio, ou DSL (Domain-Specific Language), comomuitos outros termos em computação, tem uma definição um pouco confusa e ampla,mas existe um entendimento razoável do que elas são pela observação de exemplosque aparecem de diferentes maneiras em diversas comunidades.

A definição adotada para DSL é: uma linguagem de programação que ofe-rece, através de notações e abstrações apropriadas, poder de expressão enfá-tica e restrita a um domínio de problema particular.

Uma comunidade particular em que as DSLs são notadas é a comunidadeUNIX, que tem como tradição chamá-las de linguagens pequenas ou mini-linguagens.Como exemplo, existem os arquivos de configuração utilizados em sistemas UNIX(e.g. Makefile), que podem ser vistos como uma DSL para descrever o processo deconstrução (compilação, bibliotecas, diretórios, etc.) de um sistema.

2http://www.quicksilverweb.net/sbucks/sbcharts.htm

23

Um bom exemplo é expressão regular, usada para reconhecimento de pa-drões de textos disponível em praticamente qualquer plataforma de desenvolvimento(e.g. Java, C#, Ruby).

Outra comunidade que se destaca por utilizar essa técnica desde o inicio é acomunidade LISP, que há muito tempo tem o hábito de criar DSLs utilizando a própriasintaxe da linguagem. Por ter uma característica metacircular (Abelson & Sussman,1996), na qual os dados e o programa-usuário estão no mesmo espaço de memória,então o interpretador age como uma ponte entre os objetos de dados que são mani-pulados pela linguagem de programação e a própria linguagem de programação. Aforma na qual as pessoas desenvolvem sistemas em LISP se inicia com a concepçãode uma linguagem personalizada para descrever o sistema, obtendo um novo “dialeto”de LISP e, a partir dele, descreve-se a solução do problema por meio dessa extensãofuncional (i.e. Emacs Lisp, Auto Lisp).

Essa idéia de construir uma linguagem embutida em outra também é bastanteutilizada pela comunidade Ruby, que utiliza de recursos de metaprogramação da lin-guagem (apresentado inicialmente por Kiczales & Rivieres (1991)) para alcançar omesmo objetivo.

De certa forma, bibliotecas de aplicações (APIs) são competidoras de DSLs(Mernik et al., 2005). Na maioria das vezes a linguagem utilizada para solucionar umproblema é construída na forma de bibliotecas, utilizando classes, atributos e métodosna sua implementação (no caso de linguagens orientadas a objetos) ou composiçãode funções (em linguagens funcionais). Desta forma, a linguagem da GPL é obri-gatoriamente usada (i.e. notação de “ponto” em Java para acessar os membros deuma classe/objeto). Isto pode não ser muito adequado a um especialista de domínio,porque ele precisará conhecer as várias construções que pertencem a GPL, e quenão são necessariamente úteis ao entendimento do programa (i.e. declaração de umavariável de controle para construir uma iteração em um loop).

Freeman & Pryce (2006) apresentam um estudo de caso no qual uma lingua-gem explícita é embutida em um framework por meio de uma API fluente (traduçãolivre do termo fluent interfaces3). Apesar de construída em uma linguagem com sin-taxe grande e rígida (nesse caso a linguagem Java), os autores preocupam-se com alegibilidade do código e seu resultado, e assim tornam a programação sobre essa APImais natural e contextualizada. O framework JMock usa interfaces encadeadas paradefinir uma sintaxe concisa e auto-explicativa, que facilita a leitura do código e seuuso por parte de um programador. Um exemplo deste framework é apresentado noapêndice A.1. Esse framework permite criar objetos mock, que são muito utilizadosem desenvolvimento orientado a testes.

3Termo criado por Martin Fowler sobre um estilo de programação que objetiva criar um código defácil leitura. Veja mais em: http://martinfowler.com/bliki/FluentInterface.html

24

A experiência demonstrou que a partir do momento em que a API se tornouuma DSL, o desenvolvimento ficou mais simples e direto por dois motivos destacadospor Freeman & Pryce (2006): Primeiro, com uma clara separação da sintaxe e inter-pretação em camadas. Segundo, mudou o estilo de programação comum em Javaquando apropriado, criando novas convenções, onde o estilo chamada em cadeia(call chain) faz com que a leitura do código seja mais uma especificação declarativado que o uso de uma API imperativa (pode-se ver um exemplo de API fluente no apên-dice A.2).

A DSL contrasta com uma GPL no sentido em que seus recursos sintáticos esemânticos são limitados para implementar apenas algumas funcionalidades especí-ficas. Sua aplicação ocorre dentro de um domínio de problema não precisando serTuring-completa 4. Seu valor está no fato dela representar muito melhor o vocabulá-rio desse domínio, o que torna mais fácil sua programação e entendimento por umespecialista no domínio.

Uma GPL (e.g. C, C#, VB, Java, Ruby, Python, LISP), por sua vez, implementauma linguagem equivalente ao modelo de máquina de Turing, e permite desenvolversoluções para quaisquer domínios.

A interface de programação de uma aplicação (API) constitui um vocabulárioespecífico de domínio, com nomes de classes, métodos e funções disponíveis paracriação de um programa em uma GPL. Contudo, uma DSL oferece especificidade dedomínio de uma maneira melhor, como é destacado por Mernik et al. (2005):

• A notação específica de domínio estabelecida ou apropriada vai além dos opera-dores disponíveis na GPL. Essa nova notação comumente é associada a maiorprodutividade de desenvolvimento;

• Construções e abstrações específicas de domínio nem sempre podem ser ma-peadas para funções e/ou objetos de uma biblioteca;

• Uso de uma DSL oferece possibilidade de análise, verificação, otimização, pa-ralelização e transformação; no caso de uma GPL, devido à padronização docódigo-fonte torna-se muito complexo ou não é bem definido;

• Uma DSL não precisa ser executável — apesar de não existir acordo sobre issona literatura segundo Wile (2001) e van Deursen et al. (2000).

Outro aspecto importante no que tange às DSLs é que também são conside-radas como uma forma de reuso de artefatos de software (Biggerstaff, 1998). Osartefatos nesse caso são: a gramática, o código fonte e as abstrações modeladas. Apartir desse modelo, também é possível gerar aplicações completas segundo Krueger(1992) apud Mernik et al. (2005).

4http://en.wikipedia.org/wiki/Turing_completeness

25

Freeman & Pryce (2006) descrevem uma DSL para o domínio de teste de soft-ware, que começou sua história na forma de uma biblioteca de classes (API), queimplementava as funções do framework e depois evoluiu para uma linguagem embu-tida, a qual é explicada na seção 2.3.2. É essa evolução postulada como nível maismaduro desse framework o que facilita seu uso e disseminação.

2.3 Classificação

A maior parte das DSLs encontradas atualmente é textual, mas também exis-tem na forma gráfica. As DSLs gráficas necessitam de uma ferramenta e símbolospara representar sua notação, como também um gerador de artefatos (e.g. código,dados, arquivos de configuração) e são chamadas de linguagens de modelagem es-pecífica de domínio.

Uma importante forma de classificar os tipos de DSLs encontrados pode serfeita de acordo com sua forma de construção, que as divide entre DSLs externas einternas.

2.3.1 DSL Externa

Uma DSL externa é uma linguagem que pode ser compilada, interpretada ouexecutada, e tem uma sintaxe própria ou usa alguma representação pré-definida comoYAML Ain’t Markup Language (YAML) ou Extensible Markup Language XML — comopor exemplo Extensible Application Markup Language (XAML) e XML User InterfaceLanguage (XUL) — entre outras, mas precisa de um parser para processá-las, um ge-rador de código objeto, ligação de bibliotecas, etc. Trata-se de uma linguagem cons-truída muitas vezes da mesma forma que linguagens tradicionais completas. Tem-setotal liberdade para criar sua estrutura sintática e semântica. Existem ferramentas taiscomo analisadores léxicos e sintáticos (e.g. lex, yacc) e geradores de parser (e.g.ANTLR Parr (2007)) que são utilizados na construção, compilação e interpretação dalinguagem.

São exemplos de DSLs externas: arquivos de configuração de ferramentaspara compilação em Java (ANT5), em .NET (NANT6), em C/C++ (Make7) e em Ruby(Rake8). Todos estes utilizam uma linguagem personalizada que descreve as depen-dências entre as partes do sistema no processo de compilação e ligação. Outrosexemplos citados por Fowler (2008) incluem: CSS, expressões regulares, SQL, HQL,linguagem gráfica de pontos graphviz, FIT, arquivo de configuração que utilizam nota-ção XML como do Struts, Spring, Java Server Faces (JSF) e Enterprise Java Beans

5http://ant.apache.org/6http://nant.sourceforge.net/7http://www.gnu.org/software/make/8http://rake.rubyforge.org/

26

(EJB) 2.x. Como exemplo histórico, a NASA utiliza DSLs desde a década de 60 paracomputação vetorial no projeto Apollo 9.

2.3.2 DSL Interna

Também chamada embutida (embedded language), é uma linguagem expressadentro de uma GPL. Essa modalidade requer uma linguagem “hospedeira” e sua sin-taxe é valida dentro da linguagem de propósito geral que a contém. A partir dessaextensão da linguagem base podem-se personalizar os símbolos e mecanismos decontrole de uma maneira especial, de acordo com a necessidade do domínio ao de-senvolver essa nova linguagem.

Quando uma DSL não vai além do nível de uma biblioteca da aplicação, isto é,não tem um compilador que a transforma em código de máquina, é chamada tambémde DSEL (Domain Specific Embedded Language) segundo Hudak (1996). Usa-se otermo DSL Interna no lugar de DSL Embutida para não confundir com linguagens descripting (e.g. JavaScript), utilizadas na construção de aplicações. Embora o segundotermo tenha sido mais utilizado historicamente pela academia, atualmente a mesmatécnica tem sido chamada pelos praticantes de linguagem específica de domíniointerna (Fowler, 2008).

São exemplos de DSLs internas: parte do framework Ruby on Rails (e.g. Ac-tiveRecords para mapeamento objeto-relacional), dialeto LISP para programação doeditor Emacs, expectativas com JMock em Java, entre outras (Fowler, 2008).

2.4 Método de Desenvolvimento

Não é fácil de determinar quando e como construir DSLs. Vantagens comoaumento de produtividade, facilidade de manutenção, rápido processo de aprendi-zado, possibilidade de reutilizar artefatos de software, não são obtidas sem grandesesforços.

Contudo, devem-se considerar ainda os seguintes itens:

• Existe dificuldade no desenvolvimento da DSL pois se requer especialistas nalinguagem e no domínio;

• Diversas técnicas de desenvolvimento são encontradas, portanto requer consi-deração cuidadosa dos fatores envolvidos;

• Dependendo do tamanho da comunidade de usuários, demanda alto custo nacriação de material de treinamento, suporte, padronização e manutenção.

9http://www.ibiblio.org/apollo/assembly_language_manual.html

27

Seu desenvolvimento também pode vir posteriormente na forma de reengenharia desoftware ou evolução do software (Bennett & Rajlich, 2000).

Na literatura encontram-se importantes contribuições, como o trabalho de vanDeursen et al. (2000), que é uma bibliografia anotada e serve de referência históricasobre o assunto.

O trabalho de Mernik et al. (2005) trata de um survey que objetiva responderas perguntas: quando e como construir DSLs, sendo esse um dos poucos trabalhosque oferecem um guia ou método para criação de DSLs, apresentando uma revisãosistemática dos vários fatores envolvidos, por meio da identificação de padrões emcada uma das fases de desenvolvimento: decisão, análise, projeto e implementação.

Grande parte da metodologia descrita nas seções 2.4.1, 2.4.2 e 2.4.3 foi ex-traída deste trabalho Mernik et al. (2005), sendo que algumas técnicas de implemen-tação consideradas na seção 2.4.4 podem ser encontradas em Fowler (2008), Fernan-dez (2007), Kilmer (2008), Ford (2008), Subramaniam (2008) e Parr (2007).

A seguir serão apresentadas as fases no desenvolvimento de uma DSL e ospadrões destacados no que tange a este trabalho em particular. Na prática, o desen-volvimento de uma DSL não é um processo seqüencial, no qual o processo decisóriopode ser influenciado por uma análise preliminar, e o projeto é muitas vezes influenci-ado por restrições ou diretivas de implementação.

2.4.1 Decisão

Para determinar quando o desenvolvimento de uma DSL deve ser aplicado,usam-se os padrões de decisão conforme destacados na Tabela 2.1, extraído de Mer-nik et al. (2005). Pode-se observar que esses padrões ajudam no processo decisóriosobre a devida aplicação de uma DSL.

Tabela 2.1: Padrões de Decisão [Fonte: Mernik et. al. (2005)]

28

O padrão Interaction, por exemplo, objetiva tornar a interação programável.Esse padrão é definido da seguinte forma: interações baseadas em menu ou textofreqüentemente devem ser suportadas por uma DSL apropriada para especificar en-tradas complicadas ou repetitivas de dados. A linguagem de macro do Excel suportasua manipulação interativa o que a torna programável.

Seguem alguns exemplos de linguagens criadas nas quais observou-se a utili-zação do padrão Interaction: CHEM, FPIC, Fran, Mawl, Service Combinators. Outraslinguagens associadas a outros padrões, bem como suas referências, podem ser vis-tas na Tabela 2.2, encontrado em Mernik et al. (2005). Um exemplo de DSL que não éapresentado na tabela, mas foi possível notar que segue o mesmo padrão de decisãoé a WebDSL. A WebDSL é utilizada para implementação de aplicações web dinâmicas(Groenewegen et al., 2008).

Também é fácil evidenciar o padrão GUI construction, já que normalmente aconstrução de interface gráfica é feita por meio de DSLs (e.g. XUL, XAML, JavaFX).

Tabela 2.2: Exemplos para os Padrões de Decisão [Fonte: Mernik et. al. (2005)]

2.4.2 Análise

Para a fase de Análise: o domínio do problema é identificado e o conhecimentosobre esse domínio é adquirido. Para isso várias fontes de informações sobre o do-mínio (implícitas e explícitas) são necessárias, como documentos técnicos, conheci-mento fornecido por um especialista de domínio, código pré-existente e questionárioscom clientes e usuários.

O resultado da análise de domínio consiste basicamente de terminologia e se-mântica da linguagem. Existe uma forte relação entre a “Análise de Domínio” e “En-genharia de Informação” para capturar conhecimento, representar conhecimento edesenvolvimento de ontologias (Denny (2003) apud Mernik et al. (2005)), que tambémpode ser útil nessa fase de análise.

29

Padrões de análise são destacados na Tabela 2.3, extraído de Mernik et al.(2005), sendo que muitas vezes essa análise de domínio é feita de maneira informal.

Tabela 2.3: Padrões de Análise [Fonte: Mernik et. al. (2005)]

A partir da análise pode-se construir um modelo de domínio. Esse modelo éconstituído da seguinte forma:

• definição do domínio e especificação do escopo;

• terminologia do domínio (vocabulário, ontologia);

• descrição dos conceitos do domínio;

• modelo de requisitos que descreve o que é constante e variável no domínio,conceitos e suas interdependências.

Note que o modelo de execução de uma DSL é muito mais rico do que parauma GPL, pois, com base em uma única análise de domínio muitas DSLs diferentespodem ser desenvolvidas sendo que todas compartilham características importantesencontradas nos requisitos.

2.4.3 Projeto

Abordagens para projetar uma DSL podem ser caracterizadas por duas dimen-sões ortogonais: (1) a relação da DSL com linguagens existentes, e (2) a naturezaformal da descrição do projeto. Pode-se observar os padrões de projeto na Tabela 2.4e exemplos de linguagens que seguem esses padrões na Tabela 2.5 — ambas extraí-das de Mernik et al. (2005).

Tabela 2.4: Padrões de Projeto [Fonte: Mernik et. al. (2005)]

30

Tabela 2.5: Exemplos de linguagens para os Padrões de Projeto [Fonte: Mernik et. al.(2005)]

Uma das formas mais utilizadas para se projetar uma nova linguagem é fazeruma extensão funcional ou sintática em uma linguagem já existente, com o benefíciode ter usuários já familiarizados com a sintaxe da linguagem original. Dessa maneiraadicionam-se novos recursos de acordo com os conceitos do domínio, e aproveitam-serecursos que já existem na linguagem base. O desafio é integrar recursos específicosdo domínio com o resto da linguagem de uma maneira que não haja conflitos.

Como exemplo, as comunidades de LISP e Ruby utilizam com freqüência opadrão de exploração de uma linguagem por meio de extensão, onde uma linguagempré-existente é estendida para acomodar DSLs.

Em um projeto informal, a especificação é normalmente feita por meio de umalinguagem natural, e provavelmente inclui um conjunto de programas para ilustrar ouso da DSL. Já o desenvolvimento de uma descrição formal possibilita a aplicaçãode ferramentas de desenvolvimento de linguagens que são capazes de gerar umaimplementação automática de parsers e analisadores sintáticos.

A indústria também tem investido na criação de ferramentas desse tipo, comopor exemplo, o Eclipse Modeling Project (EclipseFoundation, 2009), Xtext (OpenAr-chitectureWare, 2009), Netbeans Generic Languages Framework (Netbeans, 2009),Microsoft OSLO (Microsoft, 2009), e outras. A Tabela 2.6 apresenta outras ferramen-tas observadas no survey de Mernik et al. (2005).

31

Tabela 2.6: Sistemas e Ferramentas de Desenvolvimento de Linguagem [Fonte: Mer-nik et. al. (2005)]

2.4.4 Implementação

Quando uma DSL executável é projetada é preciso escolher sob qual ótica elaé implementada: na forma de um interpretador, um compilador/gerador de aplicações,um pré-processador, uma linguagem embutida ou híbrida sendo que esta última serefere a combinação de mais de uma forma. Pode-se observar padrões de implemen-tação na Tabela 2.7, encontrado em Mernik et al. (2005), que auxiliam no processo deescolha.

Tabela 2.7: Padrões de Implementação para DSLs executáveis [Fonte: Mernik et. al.(2005)]

2.5 Considerações

Em virtude das dificuldades que surgem ao se criar uma nova linguagem, comodefinir seus símbolos e sua sintaxe, comumente se adota o uso de mecanismos en-contrados nas linguagens padrão, porém estes podem não suportar devidamente asabstrações exigidas pela aplicação e consequentemente perderem expressividade,

32

com a intercalação sem critério da sintaxe da própria linguagem de programação comas abstrações do modelo de domínio.

Portanto, a opção pelas DSLs justifica-se pelo fato destas permitirem que so-luções sejam expressas no idioma e nível de abstração do problema de domínio, edesta forma, possibilitam à especialistas de domínio (não programadores) poderementender, validar, modificar e até mesmo criar programas por meio dessas linguagensespecíficas.

33

3 MÍDIA CRUZADA E GOVERNO ELETRÔNICO

“As sociedades sempre foram moldadas mais pela natureza dos meios do que peloconteúdo da comunicação.” (Marshall McLuhan)

Este capítulo introduz o domínio de aplicação no qual este trabalho está inse-rido. Primeiramente apresenta o conceito de mídia e mídia cruzada, seguido pela suaaplicação em governo eletrônico. Os termos mídia cruzada, crossmedia, crossmedia etransmedia serão utilizados de forma intercambiada para se referir a mesma coisa deacordo com os autores e contextos apresentados — diferentes autores utilizam essestermos em conformidade apenas com sua área de aplicação.

3.1 Mídia Cruzada

Para se entender mídia cruzada é necessário analisar o conceito de mídia em-pregado em comunicação e posteriormente como esse conceito é expandido paramúltiplas mídias.

3.1.1 Definição de Mídia

Para esse trabalho entende-se como mídia os meios pelos quais as mensa-gens chegam até o público. A própria palavra mídia deriva do latim media, que querdizer meio. Na mídia tradicional o público era mero receptor da mensagem, sem apossibilidade de interagir com esta pelo meio na qual ela foi produzida, porém issomudou. Atualmente existem muitos meios para a difusão de mensagens que permi-tem a interação do receptor, por exemplo web, e-mail, twitter, sms, mms, portal de voz,entre outros.

Segundo Cunha (2006):

“É esta mesma recepção que, em momento de expansão tecnológica maispropício, assume o papel da narração antes delegado a outros centrosemissores e busca construir um conteúdo cada vez mais individualizado.Para tanto, a recepção se apropria das linguagens que estão na base dequalquer narração midiática e passa a produzir para si e para os públicosque se auto-organizam na rede.”

34

Ainda no que se refere ao conceito de mídia, Lima (2001) consegue articularuma definição mais precisa do que mídia significa hoje e esclarece um pouco mais aíntima conexão entre comunicação e mídia. Segundo ele, mídia pode ser entendidacomo o conjunto de instituições que utilizam tecnologias específicas para realizar acomunicação humana. Vale dizer que a mídia implica a existência de um intermediá-rio tecnológico para que a comunicação se realize. A comunicação passa, portanto,a ser uma comunicação mediatizada. Dessa forma, aparece um tipo específico decomunicação que constitui um dos importantes símbolos da modernidade.

Em outras palavras, se assim como afirmou Lima é imprescindível a existênciade um intermediário tecnológico para que a comunicação se realize, quando se fala emmídia cruzada, esta mesma comunicação só se tornará possível a partir da interaçãode múltiplos dispositivos que necessitam de alguma rede para distribuição dessasmídias, como por exemplo a Internet.

A Internet é um dos intermediários tecnológicos que torna possível as pessoasse comunicarem sobre diversas mídias. Padrões mantidos pelo Internet EngineeringTask Force (IETF) foram criados para definir os tipos de mídias suportadas na rede— o tipo de mídia da internet foi derivado do Multipurpose Internet Mail Extensions(Mime), criado para que diversos tipos de conteúdos fossem incluídos em e-mail, eexpandiu para outros protocolos (e.g. Hypertext Transfer Protocol, Real-time Trans-port Protocol, Session Initiation Protocol). Por meio do Mime Type, o tipo de mídiatransportado é definido a partir de um tipo e subtipo, como por exemplo: text/html(para transporte de hypertexto), image/gif (para transporte de imagem no formato gif),application/pdf (para transporte de um documento no formato pdf), entre outros. Pode-se consultar tipos de mídias suportados para imagem, audio, vídeo e aplicações naRFC2046 (Freed & Borenstein, 1996).

3.1.2 Mídia Cruzada

O termo mídia cruzada (crossmedia) é recente e tem significados diferentes deacordo com a disciplina em que é aplicado. Contudo, segundo Boumans (2004), existeum significado comum que se traduz como o uso de múltiplos meios para propagaruma mesma mensagem com o objetivo de tornar o conteúdo mais acessível. Quandose fala em Web, o termo é associado com o uso eficiente de mais de uma plataformatécnica, que torna o conteúdo disponível para um grande número de pessoas sobrediferentes dispositivos. Em marketing, significa usar múltiplos canais de distribuição. Oconceito de crossmedia vai adquirindo novas características à medida que é exploradopor áreas distintas como e-learning, turismo, propaganda, etc.

De acordo com Boumans (2004) podem-se observar diversos sinônimos aotermo crossmedia, criados ao longo dos anos e por diferentes disciplinas, como mul-timídia, multiplas mídias, mídia interativa e integrada, multiplataforma, mídia conver-

35

gente e híbrida. Embora o termo seja recente, o seu conceito de utilização já eraempregado na década de 70, quando o conteúdo de enciclopédias eram distribuídostambém em fita cassete, e posteriormente em CD-ROM quando o termo multimídiapassou a ser utilizado. Até meados da década de 90, a idéia de crossmedia (emboranão com este nome) esteve ligado com o slogan “Create Once, Publish Everywhere”usado por Paul Zazzera, CEO da Time Inc. em 1996 (hoje, pertence ao grupo TimeWarner e é uma das maiores companhias de conteúdo do mundo distribuídos em re-vistas, web, rádio e televisão).

Quando o termo começou a ser usado no final dos anos 90, principalmentedevido à popularização da Internet, significava obter mais informações sobre um pro-grama na Web. Somente em 1999, com o lançamento do programa de televisãoBig Brother, criado pela produtora Endemol na Holanda, e seu respectivo sucesso,o termo crossmedia bem como seu uso em áreas diversas, nesse caso entreteni-mento, popularizou-se. O programa de TV tornou-se um significativo exemplo de umbem sucedido uso de mídia cruzada, uma vez que sua imensa repercussão deveu-seao fato que em sua veiculação foram usadas além da TV analógica, a TV interativa,telefone, celular e Internet, sendo ainda apoiado pela mídia impressa (jornal e revista)para produzir diálogos únicos sobre múltiplas mídias. Ainda, entre os exemplos deutilização de múltiplas mídias (com diálogos diferenciados em cada mídia) na indus-tria de entretenimento, pode-se citar a trilogia Matrix que teve, além dos filmes, umaversão em quadrinhos e jogos, e a série Lost da ABC, que tem sites na web em que ousuário pode continuar a explorar o universo criado pela série.

O conceito de mídia cruzada utilizado neste trabalho é semelhante àquele em-pregado pelo programa Big Brother, onde são utilizados diversos meios para produzirdiálogos únicos sobre múltiplas mídias. Em outras palavras, para este trabalho, mídiacruzada (crossmedia) é uma forma de comunicação na qual o receptor é convidadoa utilizar diferentes mídias para acessar um conteúdo que pode levá-lo para outrasmídias.

A mídia cruzada possui cinco características que a distinguem, listadas porBoumans (2004): (1) a mídia cruzada envolve mais de uma mídia; (2) a mídia cruzadaobjetiva uma produção integrada; (3) o conteúdo é entregue em múltiplas mídias; (4)mais de uma mídia é necessária para apoiar uma única mensagem/narrativa/meta;(5) a mensagem/narrativa/meta é distribuída em múltiplas plataformas e a interaçãoapoiada pode acontecer nestas diferentes plataformas.

No cenário atual existe uma mistura de aplicações, plataformas, dispositivos,que possibilitam o acesso de conteúdo sobre um meio, são exemplos as redes soci-ais e organizacionais que suportam muitas atividades humanas como jogos, compras,comunicação, até serviços públicos. Por meio destes exemplos, percebe-se o quãofundamental a Internet tornou-se, mesmo para ações corriqueiras de nosso cotidiano,

36

Figura 3.1: Big Brother Brasil 9 [Fonte: Rede Globo (2009)]

e que como disse Bolter & Grusin (2000) apud Wiberg et al. (2007) a Internet segueum rumo de alto grau de convergência entre diferentes tipos de mídia e conteúdo.Um fenômeno similar a este de acordo com Wiberg et al. (2007) está sendo estudadopelas áreas de IHC e novas mídias. Esse fenômeno visto como uma mensagem con-tada em mais de uma mídia também é chamado de crossmedia (conceito observadoprincipalmente pelas áreas de comunicação e novas mídias).

Quando uma história ou diálogo de interação é contada sobre mais de umamídia, e o receptor é convidado para mudar de uma mídia para outra, pode-se dizerque ocorre um diálogo crossmedia e segundo Dena (2007), esse convite é chamado“call-to-action” (CTA). O “call-to-action” é um termo criado pela área de marketing queobjetiva levar a pessoa a tomar uma ação diante de uma propaganda. Neste trabalho,o mesmo conceito pode ser aplicado a outros domínios, como serviços de governo.

Dena propõe um processo constituído por três fases que resultarão neste con-vite à ação (CTA): (1) Preparar e motivar o ator a agir; (2) Fornecer o meio e as ins-truções de como e quando agir e (3) Reconhecer e recompensar a ação. O sucessode um projeto de interação sobre mídia cruzada é evidente quando a pessoa migrade uma plataforma para outra, e quando esse movimento tem um impacto positivo naexperiência do próprio usuário. Essa experiência é muito diferente daquela com ape-nas uma mídia (forma tradicional e dominante), porque a pessoa tem que tomar umaação muitas vezes de forma ativa, embora também possam ocorrer transições auto-máticas (passivas) . Existem mecanismos que podem facilitar uma transição, comopor exemplo o QR-CODE1 que permite um telefone celular capturar uma imagem em

1QR-CODE é um tipo de código de barras de duas dimensões contendo um conjunto limitado dedados que pode ser por exemplo um endereço na internet ou uma imagem

37

uma mídia impressa (jornal, revista) e levar o usuário para uma página na web quecontinua a narrativa, por exemplo, apresentando um mapa (Dena, 2007).

Ainda hoje no Brasil, o principal meio pelo qual as pessoas buscam se infor-mar é a televisão, sendo seu número em domicílios muito mais representativo do queo de computadores, estejam estes conectados ou não à internet, seguidos apenaspela quantidade de telefones usados principalmente para serviços de voz 2. Assim,tendo em vista este contexto sócio-cultural, este conceito de comunicação (crossme-dia) torna-se mais atrativo aos olhos do cidadão, uma vez que o conteúdo chega atéele pela TV, telefone fixo, celular, além da mídia impressa e do computador. Este é umfator chave para explicar a necessidade do governo de se comunicar com o cidadãopor diversas mídias, ampliando sua presença em todos os extratos sociais. No futuro,usuários estarão tão acostumados à crossmedia que não irão notar sua presença,mas irão perceber sua falta, Boumans (2004).

3.2 Governo Eletrônico em Mídia Cruzada

Com base nos conceitos anteriormente expostos de mídia e mídia cruzada,nesse ponto faz-se necessário mostrar como podem ser aplicados em governo eletrô-nico. A seguir são apresentadas as formas de comunicação utilizadas pelo governo,o que são esses serviços e como eles podem ser mapeados para o desenvolvimentode uma solução tecnológica.

3.2.1 e-gov, m-gov, t-gov, x-gov

Atualmente o governo se relaciona com os cidadãos tanto fisica quanto vir-tualmente. Cada vez mais conta com o auxílio de dispositivos computacionais quepermitem a interação do governo com o cidadão, e a mídia cruzada é uma forma deampliar ambas as formas de relacionamento.

Os acrônimos e-gov, m-gov, t-gov apresentam meios pelos quais o governointerage com o cidadão, e-gov sendo pelo meio eletrônico (usualmente pela web3), m-gov é normalmente quando o usuário interage por meio de um telefone celular, e t-gové a interação do cidadão com o governo pela tv (em um futuro próximo com a tv digitalessa interação também será bidirecional). O termo x-gov, mais recente, determina ouso das diversas mídias (daí o “x”, que se refere a cross em inglês), para interação dogoverno com o cidadão.

Para Filgueiras (2007), x-gov é definido como sendo a entrega de serviçosde governo em mídia cruzada, na qual a comunicação G2C é apoiada por diversos

2O CGI.BR faz uma pesquisa anual sobre o uso das Tecnologias da Informação e da Comunicaçãono Brasil que pode ser vista em http://cetic.br/usuarios/index.htm

3pode-se ver um exemplo de diversos serviços oferecidos pelo governo do estado de São Paulo emhttp://www.cidadao.sp.gov.br/

38

meios alternativos, cada qual direcionando o cidadão ao próximo passo no processode interação e ao meio mais adequado a este passo . . . x-gov difere das demaisaplicações de mídia cruzada porque no x-gov a narrativa principal deve ser apoiadapor mídias alternativas. Nas demais aplicações, há uma mídia principal (em geral, aTV) que apóia o tema central.

Apesar dos esforços do governo e das entidades civis o acesso à Internet aindaé restrito a um pequeno número de pessoas (comparando esse número com todapopulação do país), assim, o governo eletrônico brasileiro não pode se apoiar apenasnesse meio, mas deve explorar outros meios de comunicação. Alguns benefícios dométodo x-gov, segundo o relatório de Filgueiras (2007) são:

• aumentar o número de alternativas pelas quais o cidadão alcança o governo,bem como a possibilidade de obter esse acesso a qualquer momento, de qual-quer lugar;

• mover a interação eletrônica para além do ponto em que ela se interrompe hoje:transações eletrônicas são substituídas por interações presenciais;

• favorecimento de uma diversidade de usuário, pessoas com algum tipo de defi-ciência podem se comunicar com o governo pelo canal mais adequado a elas;

• a vida moderna exige a linguagem de mídia cruzada: envia-se um e-mail aomesmo tempo em que se conversa ao telefone e acompanha o noticiário na TV.

3.2.2 Serviços de Governo

Como dito anteriormente, o conceito de crossmedia tornou-se popular em dife-rentes contextos, como no meio artístico, de jogos, filmes, rádio e TV. Com a tecnolo-gia digital e uma gama cada vez maior de dispositivos, o conteúdo pode ser acessado,transmitido e armazenado facilmente em diversas plataformas. Apesar do aspecto deentretenimento, este conceito é facilmente extrapolado para outras aplicações, comoneste trabalho para serviços de governo.

O dicionário Oxford (2a edição) define serviço como “(1) a ação de ajudar ou fa-zer trabalho para alguém; (2) um sistema que fornece uma necessidade pública comotransporte, comunicação, ou utilidades como elétrica e de saneamento”. É necessárioestreitar essa definição para serviços públicos que são executados por uma unida-de/departamento/organização do governo para atender seus cidadãos. Usando esteconceito entende-se como serviço de governo: serviços executados por uma unida-de/departamento/organização do governo com objetivo de fornecer um bem público.

Para ser melhor compreendido, um determinado serviço de governo deve serdecomposto em um conjunto de atividades que serão executadas por um ator, po-

39

dendo ser este uma unidade/departamento/organização/representante do governo ouum cidadão (pessoa física ou jurídica) que precise desempenhar essas atividades.

Normalmente o ator deverá executar vários passos para atingir seu objetivo,e existem vários recursos como informação, dinheiro, dcumentos entre outros quedevem ser trocados durante o processo. Dentro de cada passo existe um diálogo entreo ator e a ação que precisa ser executada, um conceito popularmente conhecido comoround ou rodada de acordo com Filgueiras (2007).

Ainda, é importante ressaltar a escolha de mídias ideais para um serviço, par-tindo, por um lado, das características de apresentação, geração ou recebimento decada mídia e, por outro, das necessidade de recursos (informação, transação finan-ceira, documento) de cada etapa do serviço.

A produção de conteúdo sobre as diferentes mídias deve ser complementarpara que a pessoa possa (1) em alguns casos, escolher qual quer usar; (2) usar amídia mais adequada para uma certa situação como por exemplo, ter disponível ape-nas o telefone celular quando estiver em trânsito; e (3) usá-las simultaneamente paraapoiar uma narrativa/atividade/meta. Dessa forma surgem tres conceitos que podemser benéficos para serviços de governo (Miyamaru et al., 2008a), abaixo descritos:

1. Corroboração

2. Concomitância

3. Completude

Corroboração indica que as mídias carreguem o mesmo conteúdo, o que reforça amensagem para o receptor. O conceito de Concomitância determina que uma mídiaesteja conectada com outra mídia (normalmente sobre outro dispositivo) e essa cone-xão permite criar um sincronismo entre as mídias. O conceito de Complementação éaplicado quando uma determinada informação não é adequada para ser entregue emuma mídia, então o dialogo prossegue em outra.

3.2.3 Padrões de Tarefas para Serviços de Governo

Em virtude das questões apresentadas em 3.1.2 e em 3.2.2, compreendeu-se que um projeto de interação integrado de múltiplas mídias/plataformas/dispositivosdeve contemplar toda a cadeia de produção de conteúdo digital (apresentado na fi-gura 3.2) desde a criação até o consumo desse conteúdo (Boumans, 2004, p 6).

O propósito de um projeto de interação em mídia cruzada, ou crossmedia In-teraction Design (CMID), é mostrar o conteúdo que deve estar disponível em cadamídia, levando em consideração as características do conteúdo e da mídia, do dispo-sitivo, e do meio de distribuição. CMID é uma particularização da multimodalidade, jáque contempla um projeto de movimento sobre diferentes modalidades de interação.

40

Figura 3.2: Cadeia de Conteúdo Digital [Fonte: Boumans (2004) - traduzido pelo autor]

Um projeto de interação sobre mídia cruzada preocupa-se com aspectos que possi-bilitem transitar sobre as diferentes modalidades, no qual o ator dessa transição é ousuário que segue dicas migratórias criadas pelo projetista como caminhos de umanarrativa. Ainda no projeto deve ser definido como implementar uma narrativa (doinglês storytelling), e quais metáforas são mais adequadas para a interação com ousuário.

Assim, segundo Miyamaru et al. (2008b), padrões de tarefas são boas soluçõespara projeto de interação com serviços de governo e são convenientes para aplicaçõesdisponíveis em múltiplos dispositivos, uma vez que padrões de tarefa capturam a di-mensão humana da interação, sendo capazes de expressar intenções humanas quedevem ser atendidas pela interface de usuário.

A etapa inicial deste trabalho foi desenvolver, junto com outros pesquisadores,18 padrões de tarefa para expressar o uso de serviços de governo em ambiente demídia cruzada. Para isso foram analisados 30 serviços públicos, dos quais 27 estavamdisponíveis pela internet, 6 foram serviços que requerem a presença do cidadão emalguma etapa e 2 foram serviços disponíveis para celulares. 4

Os 18 padrões de tarefa para governo eletrônico em mídia cruzada foram divi-didos em 4 categorias da seguinte forma:

• Informação: (1) Obter informações a respeito de um serviço; (2) Enviar informa-ções para o governo; (3) Enviar informações pessoais; (4) Encontrar informaçõespúblicas; (5) Encontrar informações sobre alguma entidade e (6) Encontrar infor-mação privada.

• Documento: (7) Obter documento com assinatura digital; (8) Criar uma fatura;4A lista completa dos padrões de tarefa e outros detalhes pode ser obtida no site http://lts-i.

pcs.usp.br/index.php/projetos/xgov/63.

41

(9) Verificar validade de um documento; (10) Imprimir documento e (11) Salvarcomo arquivo.

• Transação: (12) Autenticação; (13) Obter identificador do processo; (14) Pagartaxa/imposto e (15) Agendamento.

• Relacionamento: (16) Falar com ombudsman; (17) Receber uma mensagem e(18) Acompanhar um processo.

42

4 FRAMEWORK X-GOV

“Para visão exigem-se três coisas, o objeto, o orgão e o meio.” (Raymond Williams)

O desenvolvimento do arcabouço tecnológico chamado de Framework X-Govtem o objetivo de projetar e desenvolver uma arquitetura reutilizável de componentescomputacionais para a criação de serviços de governo em mídia cruzada. Fez partedeste trabalho elaborar a arquitetura do Framework que é descrito nessa seção, as-sim como uma forma alternativa de programar aplicações geradas a partir dele, pormeio de uma linguagem específica de domínio. A seguir é apresentada a arquiteturadefinida, seu conceito e propósito, assim como um detalhamento de suas partes in-tegrantes. Essa arquitetura oferece uma visão de alto nível do projeto, que pode seraplicado a outros domínios com requisitos semelhantes, como: utilização de compo-nentes para criar aplicações em ambiente de mídia cruzada.

O termo x-gov ou X-Gov representa um serviço de governo sobre mídia cru-zada arbitrário, enquanto Framework X-Gov (FXG) será usado para se referenciar aoarcabouço de software criado para apoiar o desenvolvimento desse tipo de sistema.

4.1 Conceito

Governo eletrônico em mídia cruzada, ou simplesmente X-Gov, corresponde aum sistema complexo que busca integrar diversas plataformas computacionais, dispo-sitivos e mídias para permitir a interação do cidadão com o governo por esses múltiplosmeios. Visto desta forma, é um sistema complexo, distribuído, no qual um arcabouçotecnológico se faz necessário para permitir que sejam construídas aplicações dessetipo.

O conceito de framework pode ser entendido como uma arquitetura (design)reutilizável em seu todo ou como parte de um sistema, que é representado por umconjunto de classes e a forma pela qual suas instâncias interagem. Outra definiçãocomum para framework é compará-lo ao esqueleto de uma aplicação que pode serpersonalizado por um desenvolvedor. Enquanto a primeira definição descreve a estru-tura de um framework, a segunda descreve seu propósito (Johnson, 1997).

O propósito do Framework X-Gov é permitir que gestores públicos1 definam1generalização de um funcionário público que pode ser a equipe técnica de uma unidade/departa-

43

um ou mais serviços de governo em um ambiente de mídia cruzada. O processo paradefinir um serviço de governo (de maneira macroscópica) significa planejar quais asatividades de um serviço, o padrão de tarefa e as mídias a serem utilizadas em cadaatividade, além das transições que ocorrem entre as mídias — a composição desseprocesso pode ser analisado na figura 4.1, onde um portal de governo eletrônico érepresentado por um conjunto de serviços, que por sua vez possui um conjunto deatividades e associado a cada atividade uma ou mais mídias.

Figura 4.1: Composição de um X-Gov [Fonte: Elaborado pelo autor]

4.2 Arquitetura

O diagrama de implantação de alto-nível apresentado na figura 4.2 apresentaas partes do FXG, como elas são distribuídas nos seus respectivos nós de hardwaree os protocolos de comunicação. A decisão por utilizar Web Services na comuni-cação dos componentes com o servidor X-Gov oferece um baixo acoplamento entreos componentes distribuídos nos diferentes dispositivos e o servidor. Essa decisãotambém é apoiada pela proposta de que um serviço ou cliente de Web Service po-dem ser construídos em diferentes plataformas de desenvolvimento, o que garante ainteroperabilidade necessária a esta arquitetura.

mento/organização do governo

44

Figura 4.2: Arquitetura X-Gov [Fonte: Elaborado pelo autor]

4.2.1 Modelo de Domínio

O modelo de domínio apresentado na figura 4.3 detalha os principais objetoscriados para descrevem a estrutura de classe dos componentes do Framework X-Gov2. Outros diagramas com classes criadas até o momento podem ser vistos noapêndice 4. Os padrões de tarefa foram obtidos pela equipe do projeto X-Gov emum trabalho (do qual o autor deste trabalho participou) em que 32 sites de governoeletrônico foram analisados para se obterem as tarefas humanas recorrentes. Estastarefas foram modeladas usando o conceito de design patterns3.

2Por convenção determinada no projeto, os módulos, as classes, as propriedades, e operações,foram nomeados em inglês e são trazidos aqui dessa forma por tratar-se de um projeto de cunhointernacional.

3verificar no endereço http://lts-i.pcs.usp.br/ onde está o trabalho de task patterns.

45

Figura 4.3: ComponentModel [Fonte: Elaborado pelo autor]

No modelo, observe que existe uma classe que representa todos os componen-tes, chamada ‘Component’, especializada para cada tipo de padrão de tarefa, identifi-cado como ‘FindEntityInfoComponent’, ‘AuthenticationComponent’ e ‘PayFeeTaxCom-ponent’. Por sua vez, os padrões de tarefa são implementados para cada uma dasmídias alvo do projeto (tv, web e mobile). Existe uma classe que representa todas astransições ‘Transition’ e outra que representa navegações ‘ComponentConnection’.

Essas classes servem para embutir dados e comportamentos, necessáriospara implementação de cada componente em cada mídia. Todas compartilham umaestrutura básica de propriedades (identificação do componente, seu nome, seu tipo)para o correto funcionamento das partes integrantes do FXG. Cada especializaçãodessa classe corresponde a um padrão de tarefa, identificado na análise de serviçosde governo realizada anteriormente (3.2.3).

Por exemplo, o componente que implementa o padrão de tarefa ‘Obtain pre-service information’ é definido pela classe ‘GetPreServiceInfoComponent’ depositadana camada de domínio da aplicação, e cada versão específica para uma mídia cor-responde a uma especialização dessa classe. Assim, as classes relacionadas com aimplementação de um componente herdam operações e atributos determinados pelopadrão de tarefa.

46

Foi feita uma análise de vários padrões de tarefa para encontrar todos os ele-mentos necessários à sua implementação. Esses elementos foram capturados naforma de classes, atributos e métodos. Este processo é semelhante ao processo de“sedimentação” (Fach, 2001) no qual os elementos analisados são colocados em ca-madas, e os elementos de camadas superiores utilizam os elementos das camadasinferiores.

No desenvolvimento do Framework foram criados componentes para atendercada um dos padrões de tarefa estudados. O conjunto dessas classes corresponde aum módulo chamado FrameworkLibrary. Para atender a um novo padrão de tarefa, énecessário apenas adicionar ao FrameworkLibrary novas classes que a partir dessemomento, podem ser utilizadas em um serviço de governo — o conjunto de classesdo FrameworkLibrary corresponde aos objetos de domínio da aplicação. Cada novamídia incluída também necessita de especializações das classes correspondentes aospadrões de tarefa em que essa mídia pode ser aplicada.

4.2.2 Componentes

A idéia de reuso de software sempre esteve associada à componentes os quaispodem ser facilmente conectados para montagem de um sistema. Inclusive, assim,surgiram ambientes de programação orientados a componentes (e.g. Visual Basic,Delphi). A mesma idéia é aplicada ao Framework X-Gov. Um determinado tipo decomponente foi criado para atender um padrão de tarefa, e especializado para cadauma das mídias suportadas: tv, mobile e web. A biblioteca de componentes tem oimportante papel de fornecer soluções padronizadas para o projeto de um serviço degoverno elaborado pelo gestor público.

Do ponto de vista técnico, por ser construído com linguagens orientadas a ob-jeto, o Framework X-Gov é uma coleção de classes das quais originam seus obje-tos, que trabalham em cooperação, formando assim uma biblioteca de componentes.Cada componente foi originado a partir de um padrão de tarefa. Por exemplo, o pa-drão ‘Get track id’, que corresponde à tarefa de obter um número de processo para serfuturamente acompanhado, originou um componente representado pela classe ‘Get-TrackIdComponent’. Como cada mídia tem necessidades específicas, essa classe foiespecializada gerando outras 3 classes: ‘WebGetTrackIdComponent’, ‘TVGetTrackId-Component’ e ‘MobGetTrackIdComponent’ — veja na figura 4.4.

47

Figura 4.4: Componente GetTrackIdComponent [Fonte: Elaborado pelo autor]

Os componentes de interface são as peças que representam as soluções paraas tarefas de interação do cidadão em cada mídia. O componente oferece os ele-mentos de interface com o usuário, como uma página web, uma mensagem SMS, ume-mail, ou um programa interativo da TVDi, etc. O objetivo de passar um componentepelo processo de sedimentação é torná-lo menor e mais flexível, uma vez que umcomponente novo realiza uma tarefa macro, com pouca flexibilidade. A tendência éque a tarefa realizada por um componente seja dividida em tarefas menores e commaiores opções de configurações, permitindo uma composição de componentes maisflexível.

Os padrões de tarefa apresentados, e resumidos pela figura 4.5, estão conec-tados aos componentes de interface de usuário. Dessa forma, faz parte do FrameworkX-Gov uma biblioteca de componentes composta pelos 18 padrões de tarefa com su-porte para 3 mídias, totalizando 54 tipos diferentes de componentes.

48

Figura 4.5: Padrões de Tarefas [Fonte: Elaborado pelo autor]

No entanto, é impossível criar uma biblioteca com extensão suficiente para co-brir todas as necessidades atuais e futuras. A arquitetura do FXG permite a extensãodesses componentes para aplicação em outros serviços que necessitem de novoscomponentes ou versões modificadas dos mesmos.

Conforme exposto, deve existir a possibilidade de se criar e adicionar novoscomponentes. As novas classes criadas devem seguir a mesma estrutura definidapelas outras classes, ou reutilizar classes que existam em camadas inferiores. Omecanismo para criar novos componentes, considerando que os componentes podemser feitos em diferentes plataformas de desenvolvimento como Java, .NET, Symbian,Android, etc., é seguir uma interface de programação pré-definida com métodos deretorno utilizados na integração com o FXG.

O desenvolvimento dos componentes do framework X-Gov seguiu um modeloiterativo com entregas determinadas por três provas de conceito. Cada prova de con-ceito adicionou novas características à arquitetura, o que levou a uma nova etapa desedimentação. Note que o conjunto de padrões de tarefa permite criar serviços degoverno além daqueles implementados nas provas de conceito.

4.3 Partes Integrantes do Framework

Quando um novo serviço de governo ou a atualização de um existente é pro-posta por gestores públicos, eles deverão projetar como desejam que o cidadão inte-raja com o serviço. É necessário, portanto, um processo de modelagem que forneça

49

o ferramental para que esse serviço seja produzido, concentrando-se o projetista naescolha das tarefas a serem realizadas pelo cidadão, utilizando múltiplas mídias deforma integrada.

Podem-se ver os elementos gerais que compõem o FXG na figura 4.6 notando-se a existência de:

• uma ferramenta capaz de modelar um serviço e suas mídias utilizada pelo gestorpara descrever um serviço;

• uma linguagem que descreva o que foi modelado e sirva como dados de confi-guração para o FXG;

• um repositório de componentes que contém implementações na forma de clas-ses para cada tipo de componente;

• um repositório de transições que contém a implementação na forma de classese acionam outras aplicações externas (e.g. um servidor de e-mail) para cada tipode transição;

• um gerenciador de componentes capaz de processar os dados de configuração,instanciar componentes e transições para criar uma aplicação X-Gov.

Figura 4.6: Modelo X-Gov [Fonte: Elaborado pelo autor]

50

4.3.1 Gerenciador de Componentes

O Gerenciador de Componentes (Component Manager ) é uma peça centraldo Framework X-Gov responsável por instanciar os componentes utilizados por umserviço de governo. Ele mantém uma lista de componentes em memória para que asdiversas aplicações que fazem parte de um serviço possam acessar, e disponibilizaos dados destes componentes por meio de Web Services.

4.3.2 Gerenciador de Transições

Essa parte do Framework X-Gov reúne uma série de mecanismos e funciona-lidades para a navegação cross-media. Objetiva integrar componentes utilizados emmúltiplos meios de comunicação. Oferece serviços para controle de navegação dousuário, controlar dados compartilhados entre várias mídias, semelhante a idéia desessão web, chamada de X-Session, e possui ainda adaptadores para comunicaçãocom servidores de e-mail, gateways de SMS, portais de voz e envio de mensagensinstantâneas (e.g. MSN).

4.3.3 Linguagem de Configuração

O FXG necessita de uma linguagem de modelagem para descrever um serviçoque sirva para alimentar o gerenciador de componentes na hora de configurar umanova aplicação X-Gov. A Cross-Media Language (CroMeL) é uma linguagem especí-fica de domínio definida neste trabalho, usada para modelar um serviço de governosobre mídia cruzada, ou simplesmente, para modelar um serviço X-Gov. Ela é capazde descrever quais as atividades que fazem parte de um serviço, quais as mídias utili-zadas em cada atividade (determinando assim os componentes), além de especificaras transições que ocorrem entre elas.

Um serviço X-Gov pode ser especificado por meio de uma ferramenta gráficachamada de X-Builder (veja figura 4.7), que gera um código XML com as informaçõesnecessárias para criar uma aplicação pelo FXG. Uma desvantagem dessa alternativaatualmente, é a falta de meios para inserir código embutido, mas que poderia serimplementada com uso de elementos XML tipo CDATA e a inclusão de outros editoresno X-Builder. Outro ponto a se considerar é a necessidade de o gestor utilizar essaferramenta na hora de criar um novo serviço. Seria difícil criar esse código XML semo auxílio da ferramenta.

51

Figura 4.7: Ferramenta gráfica para descrição de um serviço [Fonte: Elaborado peloautor]

A CroMeL visa facilitar a foram de descrever a conexão entre as mídias, oscomponentes e seus parâmetros, assim como os demais elementos de um modeloX-Gov no que diz respeito à criação de uma aplicação como o FXG. Na sua versãoem XML, os dados de configuração são gerados pela ferramenta supracitada, e ogerenciador de componentes interpreta esses dados para gerar uma aplicação X-Gov.Na versão da CroMeL, os dados de configuração são inseridos em um tipo de scripte o gerenciador de componentes torna-se o interpretador desse script. A figura 4.8destaca as partes afetadas dos elementos que compõem o FXG.

52

Figura 4.8: Configuração através do X-Builder e através da CroMeL [Fonte: Elaboradopelo autor]

4.4 Conclusão

O Framework X-Gov é apoiado pelo reuso de seus componente (o que contem-pla seus dados, interfaces e controles), e por isso garante a consistência do modelo deinteração por todos os componentes em diversas instâncias de aplicações com o FXG.Do ponto de vista de IHC, devido ao reuso dos componentes, caso seja necessáriorealizar alterações de interface ou do modelo de interação após uma análise de usa-bilidade, com a simples alteração de um componente todos os serviços construídosque o utilizam serão atualizados.

De acordo com Fach (2001), o processo de sedimentação funciona bemquando aplicado para uma indústria tradicional, como o setor bancário, onde o domí-nio é conhecido e apresenta-se estável por muitos anos. Contudo, em novos camposde negócio onde o domínio da aplicação está sendo explorado ou elaborado, como éeste caso, existe uma dificuldade maior para aplicar este processo na definição do seumodelo de domínio.

O processo para modelar, e consequentemente, criar um novo serviço de go-verno com o FXG depende primeiramente da competência de um usuário conhecer ospadrões de tarefa suportados pelo FXG, bem como conhecer os serviços de transiçãoe as mídias disponíveis na hora de se modelar um serviço X-Gov. A partir daí, elepode criar uma descrição do serviço por meio da linguagem de configuração do FXG(CroMeL) e quando a descrição é carregada pelo FXG automaticamente uma novaaplicação X-Gov é disponibilizada. É da competência dos programadores do governoampliar os componentes, transições e mídias conforme novas necessidades de umserviço, podendo para isso reutilizar os elementos disponíveis inicialmente nos repo-

53

sitórios do FXG. Eles também devem criar integrações com os sistemas legados paraque sejam utilizados por uma aplicação X-Gov.

54

5 A LINGUAGEM CroMeL

“Aquele que não conhece outras línguas não conhece a sua própria.” (GOETHE)

Esse capítulo introduz a linguagem CroMeL, detalha sua sintaxe e semânticacom todos os elementos necessários para modelar serviços de governo no FrameworkX-Gov. A sintaxe é definida por meio da notação Extended Backus–Naur Form (EBNF)e para implementação foi utilizada uma ferramenta chamada ANother Tool for Lan-guage Recognition (ANTLR)1.

5.1 Introdução a CroMeL

CroMeL significa Cross-Media Language, e seu nome já indica uma linguagemaplicada ao domínio de mídia cruzada. Por uma feliz coincidência CroMeL também éum termopar do tipo K ou E 2, e a título de curiosidade, um termopar é a junção dedois metais utilizado para medição de temperatura. Neste caso também trata-se deuma linguagem criada com objetivo de unificar componentes presentes em diferentesmídias, particularizado para serviços de governo.

CroMeL é uma linguagem específica de domínio, declarativa, que permite es-pecificar um serviço de governo em mídia cruzada. Para entender melhor o conceitoda linguagem, veja a figura 5.1 que apresenta seu contexto. Nessa figura pode-seobservar que a CroMeL é uma linguagem utilizada no mapeamento de conceitos dodomínio X-Gov com o Framework X-Gov, que corresponde aos conceitos de serviço,atividades, padrões de tarefa, transições e navegações com as classes que implemen-tam esses conceitos.

1http://www.antlr.org/2http://pt.wikipedia.org/wiki/Termopar

55

Figura 5.1: Contexto da linguagem CroMeL [Fonte: Elaborado pelo autor]

Os conceitos de domínio podem ser observados da seguinte forma:

• Dentro do contexto de um serviço, pode existir diversas atividades, transições enavegações;

• Uma atividade depende da determinação explícita de um padrão de tarefa, e écomposta por uma ou mais declarações de mídias;

• A mídia junto com o padrão de tarefa define qual implementação de componentedeve ser utilizado;

• As navegações permitem definir uma migração na mesma mídia;

• As transições permitem definir uma maneira de migrar de uma mídia para outra.

O conceito de mídia cruzada é visível na linguagem quando se observa quea partir da declaração de uma mídia, dentro de uma atividade, pode declarar umatransição que leva para outra mídia da mesma ou de outra atividade.

5.1.1 Elementos da linguagem CroMeL

O mapeamento dos elementos de domínio feitos pela CroMeL podem ser ob-servados na figura 5.2. A seguir é feito um detalhamento desses elementos que fize-ram parte dos requisitos para construção da gramática da linguagem.

Um serviço de governo é a instância de um sistema com objetivo de suprir umanecessidade pública (veja na sessão 3.2.2 mais informações sobre essa definição). Na

56

CroMeL, um serviço é definido por um nome e um contexto formado por um conjuntode atividades, transições e navegações.

Uma atividade é uma tarefa executada por um cidadão em um serviço de go-verno, e é definida por um nome e por um padrão de tarefa (veja na sessão 3.2.3 ospadrões de tarefa disponíveis). Dentro do contexto de uma atividade, contém a de-claração de uma mídia, e de acordo com o padrão de tarefa selecionado e a mídia,um tipo de componente é definido. Para cada tipo de componente, deve-se passarparâmetros utilizados na sua configuração. Por exemplo, se for declarada para a ati-vidade ObterSenhaParaAtendimento o padrão de tarefa GetTrackId, e a mídia mobile,o tipo de componente definido será MobGetTrackIdComponent que contém uma sériede propriedades chamadas parâmetros desse componente.

Uma transição é uma maneira de migrar de uma mídia para outra, e dependeda definição do seu tipo — o tipo da transição, assim como o tipo do componente,determina quais os parâmetros devem ser passados, para consultar as transições dis-poníveis, veja a figura B.4 no apêndice B.1) — e qual é a mídia de origem e destinoque deverá ocorrer uma transição. Para declarar tanto a mídia de origem quanto amídia de destino deve-se usar o nome da atividade e o tipo de mídia declarado naatividade. Por exemplo, pode-se declarar uma transição da atividade/mídia ObterSe-nhaParaAtendimento.mobile para a atividade/mídia PreencherCadastro.web por umatransição do tipo PushTransitionData.

Uma navegação é mais simples que uma transição, e permite declarar um ca-minho de uma atividade para outra dentro da mesma mídia. Necessita apenas de umidentificador dessa navegação chamado label e qual a atividade/mídia de origem edestino. Veja que uma navegação não tem tipo e nem parâmetros de configuração esuas informações são obtidas pelos componentes de uma mídia para indicar que elepode levar o usuário para um outro componente da mesma mídia.

57

Figura 5.2: Mapeamento de contexto na linguagem CroMeL [Fonte: Elaborado peloautor]

Além dos elementos de domínio, outros elementos foram incorporados na Cro-MeL para incrementar a linguagem:

58

• Uma forma de declarar variáveis utilizadas internamente na hora de atribuir va-lores aos parâmetros dos componentes e das transições;

• Uma forma de fazer referência a uma atividade/mídia por meio do nome da ativi-dade e o tipo da mídia na hora de declarar uma navegação ou transição;

• Incluir código embutido para ser executado na inicialização de cada atividade;

• Comentários que não são processados pelo interpretador.

Para a declaração de variáveis utilizadas internamente foi usada a forma maiscomum encontrada em linguagens de programação: um identificador para a variável,o símbolo de atribuição (=) e seu valor (não sendo necessário definir o tipo). Pode-se recuperar o valor de uma variável, na hora de atribuir o valor de um parâmetro,adicionando-se $ antes de seu identificador.

Para declarar a referência de uma atividade/mídia na determinação da origem edestino de uma navegação ou transição, foi utilizado o mesmo símbolo de passagemde parâmetro por referência da linguagem C (&), dessa forma, a referência de umaatividade/mídia deve ser escrita como &NomeAtividade.mídia.

A inclusão de código embutido permite ampliar o uso de um script CroMeLna declaração das atividades, podendo conter códigos que são executados na inici-alização do serviço3. A inspiração na forma utilizada para incluir regras de negóciocomo código embutido veio do conceito de literate programming (Knuth, 1984), quepermite que cada trecho de código seja associado com uma pequena descrição deseu significado.

Comentários em múltiplas linhas foram influenciados pela notação clássica deC e outras linguagens (\* ... *\), e comentário em linha foi inspirado pela sintaxe deRuby, onde o símbolo # indica para o interpretador ignorar qualquer coisa até o finalda linha.

Em resumo, na definição da linguagem CroMeL foram utilizados:

• elementos para indicar o tipo de mídia (web, mobile, tv)

• o tipo de transição (nome da classe de transição)

• o nome e o tipo da atividade (definido pelo padrão de tarefa)

• o tipo do componente (definido pelo padrão de tarefa + mídia)

• uma forma de passar parâmetros de configuração para os componentes e paraas transições

3O código embutido poderia ser executado em outras etapas do ciclo de vida do serviço além dainicialização, como por exemplo, na hora em que uma atividade é iniciada por um usuário, no momentoque uma transição ocorre, ou quando uma atividade é finalizada, no entanto, essa lógica ainda não foiespecificada no FXG, e portanto, não foi incluído suporte a esses outros estados na linguagem CroMeL.

59

Foram também acrescentados símbolos que permitem declarar variáveis, co-mentários e referência aos componentes. Além disso, com intuito de ampliar suacapacidade, foi criado uma maneira de embutir código de uma linguagem GPL.

5.1.2 Implementação

Desenvolver uma linguagem de programação depende da implementação deum programa capaz de analisar e processar dados de entrada, e dessa forma, sig-nifica construir uma aplicação que executa determinadas ações de acordo com assentenças definidas para essa nova linguagem. Desenvolver uma linguagem de pro-gramação pode ser bastante complicado, portanto, essa tarefa deve ser decompostaem etapas que incluem a criação de um reconhecedor capaz de realizar a análiseléxica e sintática e a criação de um interpretador capaz de executar ações de acordocom a semântica definida. Um reconhecedor, conhecido também como dispositivocognitivo, é um sistema formal capaz de aceitar todas as sentenças que pertençam auma determinada linguagem (Neto et al., 2009).

Depois de aceita a cadeia de entrada, um parser é capaz criar uma represen-tação intermediária das informações encontradas nos dados de entrada, enquanto ointerpretador utiliza as informações coletadas para executar ações e produzir dados desaída. A figura 5.3 representa as partes que compõem a implementação da CroMeL.

Figura 5.3: Etapas de implementação do interpretador CroMeL [Fonte: Elaborado peloautor]

O objetivo principal na criação de uma linguagem específica de domínio é au-mentar a produtividade de um Engenheiro de Software por meio da definição de no-tações melhores em um determinado domínio, e assim, aumentando o nível de abs-tração do problema (como consequência também facilita a leitura do código escritonessa linguagem).

60

Diversos frameworks como Ruby on Rails 4, JBOSS Seam 5, ROMA 6, utilizamtécnicas consideradas por muitos como aplicação de DSLs para realizar mapeamentoobjeto-relacional, especificar templates de páginas e declarar componentes de intera-ção, e por meio dessas técnicas, conseguem elevar o nível do desenvolvimento paracamadas mais altas de abstração, simplificando o criação de sistemas com esses fra-meworks (Como exemplo da aceleração propiciada por estas ferramentas, sugere-seque o leitor veja um vídeo em que um sistema de blog é construído em apenas 15minutos, incluindo a definição do schema do banco de dados e interface web comrecursos AJAX http://media.rubyonrails.org/video/rails_blog_2.mov.).

Para o Framework X-Gov atingir todo seu potencial de utilização, existe a ne-cessidade de facilitar a modelagem de um serviço de governo em mídia cruzada. Parasimplificar o desenvolvimento de um sistema com o Framework X-Gov foram conside-radas diferentes alternativas na implementação de sua DSL:

• Representação da linguagem em notação XML;

• Uma DSL Interna feita em Ruby;

• Uma DSL Externa.

A vantagem em se criar uma representação da linguagem em notação XMLfoi não ser necessário construir o reconhecedor — existem inúmeros reconhecedoresde XML disponíveis nas mais diversas linguagens de programação — no entanto, anotação em XML não atende o objetivo principal para o qual se define uma DSL, queé aumentar a produtividade através de um nível de abstração mais alto. E apesar deo uso da notação em XML ser adequado para comunicação entre programas, ela nãose apresentou adequada para servir para comunicação com outros seres humanosencarregados de escrever e ler esse código.

Essa foi a primeira alternativa implementada completamente e serviu para defi-nir muitos dos elementos necessários para a construção do interpretador que envolvea execução de ações a partir das informações coletadas do XML. Essa versão foichamada de CromelXML. Como modelar um serviço em CromelXML não é muito ade-quado para ser escrita por pessoas, foi criado uma ferramenta gráfica7 que gera ocódigo em XML a partir de um diagrama, em que são declarados os elementos apre-sentados na sessão 5.1.1.

Embora alguns autores também considerem arquivos de configuração em XMLuma DSL Externa, acredita-se que a XML se diferencia de uma verdadeira DSL Ex-terna pois sua notação ainda ficam restrita às regras de criação de um XML bem

4http://rubyonrails.org/5http://seamframework.org/6http://www.romaframework.org/7trabalho de iniciação científica associado ao projeto X-Gov, desenvolvido pelos alunos Daniel Inter-

liche de Oliveira, com bolsa da FUSP e André Martini Diniz.

61

formado, ou seja, com marcações de um prólogo e de um elemento raiz, e com res-trições sintáticas e de conteúdo. Já uma DSL Externa autêntica pode-se definir anotação que quiser, permitindo criar uma linguagem mais adequada para um domínio.

A implementação da CroMeL como uma DSL Interna em Ruby pareceu promis-sora no inicio pelas razões identificadas a seguir:

• Ruby tem uma sintaxe flexível. Nela é possível definir sobrecarga de operadores,parêntesis são opcionais, e existem classes abertas como Number e String quepermitem incluir novas funções nos objetos principais da linguagem;

• Ruby oferece recursos de meta-programação (e.g. method missing, aliasmethod) ou MOP (meta-object protocol) que de acordo com Kiczales & Rivie-res (1991), trata-se de uma interface orientada a objeto para especificação deextensão de linguagem e transformação e ainda conta com alguns recursos delinguagens funcionais como closures e lambdas;

• Existe implementação de Ruby em C8, e nas plataformas Java (JRuby9) e .NET(IronRuby10) sendo assim, portável para diversas plataformas de desenvolvi-mento.

Não foram consideradas outras linguagens inicialmente por não atenderem aos trêsrequisitos apresentados acima — Python atendia bem o segundo e terceiro, enquantoGroovy atendia bem o primeiro e o segundo.

Essa estratégia de criar uma DSL embutida (ou interna) possui como vanta-gem: (a) Menor esforço de desenvolvimento já que a implementação atual pode serutilizada; (b) Normalmente produz uma linguagem mais poderosa do que os outrosmétodos, já que muitos recursos da LP hospedeira estão disponíveis ou pré-existem;(c) a infra-estrutura da linguagem hospedeira pode ser reutilizada (ambiente de de-senvolvimento, editores, debuggers, profilers, etc.) e (d) caso o usuário conheça alinguagem hospedeira, a compreensão da nova DSL torna-se para este mais fácil.

Embora essa alternativa parecesse promissora no início, foi descartada poisnão era possível atender o objetivo principal que é ter uma notação adequada. Estedetalhe tornava obrigatório que o usuário da CroMeL soubesse primeiramente progra-mar em Ruby para conseguir utilizá-la. Uma vez que Ruby não é uma linguagem muitopopular11, isso pode causar um impacto negativo na adoção da Cromel. Pode-se dizerque a alternativa de criar uma DSL Interna é uma forma mais simples de implementaruma DSL (comparando com uma DSL Externa), pois aproveita o reconhecedor e o

8http://www.ruby-lang.org/en/9http://jruby.codehaus.org/

10http://www.ironruby.net/11a popularidade de uma linguagem de programação pode ser vista no índice TIOBE http://www.

tiobe.com/index.php/content/paperinfo/tpci/index.html.

62

interpretador da linguagem hospedeira; embora, isso facilite sua construção (pode serpor isso que se observa tantas DSLs internas atualmente), pode não ser uma alterna-tiva adequada a determinados tipos de aplicações como foi neste caso. Um ponto quepesou fortemente para que essa alternativa fosse descartada foi a falta de capacidadede retornar informações de erro relativos à sintaxe do script, e não à sintaxe do Ruby,o que por si só apresenta um grande desafio para o uso de DSLs internas.

A escolha por criar uma DSL Externa veio do amadurecimento obtido sobreos conceitos apresentados, e o desejo de criar notações mais adequadas ao domíniopara a linguagem, conseguindo assim aproximar-se do objetivo principal de definirum nível mais alto de abstração e permitir que especialistas de domínio entendamseu código, e inclusive, auxiliem os programadores na modelagem de um serviço degoverno eletrônico com o Framework X-Gov.

Para sua implementação existiam diversas ferramentas disponíveis, desde ge-radores de parsers como os clássicos lex, yacc, bison, até ferramentas chamadas delanguage workBenches que se tratam de verdadeiras IDEs para construção de lin-guagens como o Meta Programming System (http://www.jetbrains.com/mps/) daJetBrains ou o xText (http://www.eclipse.org/Xtext/) doado para fundação eclipse.A escolha da ferramenta não foi sistemática, por não ser foco deste trabalho, no en-tanto, apesar das diversas opções, foi escolhida a ferramenta chamada ANTLR, queatendeu a uma simples premissa: gerar o código do parser em Java e C#. Essa é umaferramenta que pode ser utilizada para construção de reconhecedores, interpretado-res, compiladores e tradutores a partir de ações contidas na descrição da gramática.Seguem algumas outras vantagens encontradas:

• Gera código que pode ser modificado posteriormente, e é facilmente integradoem outras aplicações;

• Gera um reconhecedor descendente-recursivo utilizando uma extensão do LL(k)chamada de LL(*) capaz de utilizar lookahead arbitrário;

• Integrado com um engine de template chamado StringTemplate projetado paragerar código estruturado;

• Possui um ambiente de desenvolvimento de gramática chamado ANTLRWorks;

• Open-source liberado sob a licença BSD;

• Suporta diversas linguagens destino como: Java, C#, Python, Ruby, Objective-C,C/C++

O desenvolvimento da CroMeL pode ser visto sob a ótica de um método inte-rativo/incremental, já que seus elementos foram determinados a partir da construção

63

de provas de conceito que tornaram possível refinar a linguagem, para atender aoscenários planejados.

Um primeiro cenário trata de uma simulação de matrícula escolar com múltiplosdispositivos e mídias e pode ser visto pelo vídeo disponível em http://lts-i.pcs.

usp.br/index.php/projetos/xgov/61. A seguir é descrito o cenário:

O usuário inicia sua interação do caso de uso pela TV digital que contém infor-mações sobre o serviço de matrícula. Após obter algumas informações básicas sobreo serviço, ele seleciona onde quer continuar o diálogo: no celular ou na internet. A im-possibilidade de continuar a interação sobre uma determinada mídia ilustra a situaçãona qual aquela mídia pode não ser adequada para a atividade em questão, e indicaum call-to-action sobre qual mídia o usuário pode continuar a interação. O usuárioseleciona continuar pelo celular, e para facilitar a transição, aparece uma imagem QRCode 12 que um aplicativo instalado no celular é capaz de capturar e interpretar.

No celular, o QR Code é decodificado em uma URL, e pergunta se o usuárioquer navegar na Web. Ao acessar a página do serviço de matrícula pelo celular sãoapresentadas opções na página inicial. O usuário seleciona a opção buscar escolaspelo nome, entra com parte do nome e executa a busca. Após o sistema apresentaros resultados, o usuário seleciona uma das escolas encontradas e o sistema retornacom informações da escola e opções para continuar o diálogo na TV. Pode-se ver afoto da escola na TV ou ver o mapa da escola na TV, que pelo fato de ter uma telagrande, é uma mídia mais adequada para apresentar esse conteúdo.

O usuário pode entrar também no celular com seu endereço de e-mail parareceber o formulário de matrícula. Em seguida, já no desktop, ao selecionar um linkno e-mail recebido, o usuário é levado ao portal web para preencher seu cadastro.Nesse momento ocorreu uma transição de dispositivos do celular para o desktop, e nodesktop ocorreu uma transição de mídias do e-mail para a web — preencher um for-mulário na web pelo desktop é muito mais adequado do que por exemplo na web pelocelular. Ao terminar o cadastro, o sistema conhece o número do celular do usuário,e envia um SMS notificando que a matricula foi recebida e informa um número paraacompanhamento do processo.

A partir deste cenário a maior parte dos elementos da CroMeL foram definidoscomo a necessidade de se declarar atividades, e no seu contexto, as mídias. Tam-bém ficou fácil notar a necessidade de existir alguma construção na linguagem paradeclarar uma transição.

A partir de outro cenário para construção de um agendamento médico, foipossível perceber a necessidade de declarar uma navegação entre componentes na

12Para saber mais sobre QR Code ver http://en.wikipedia.org/wiki/QR_Code

64

mesma mídia.O script CroMeL é um arquivo texto que pode ser criado com qualquer editor

de texto simples. Depois de esse código ter sido escrito, ele é implantado no servidorque contém o interpretador da linguagem — fase conhecida como deployment. Aimplantação é feita a partir de qualquer desktop com auxílio de um browser web. Paraisso, o desenvolvedor acessa uma página do servidor e seleciona a opção de implantarum novo serviço em CroMeL.

A figura 5.4 ilustra o processo de implantação representado por um diagramade atividade. Após o script ser carregado, ocorre a validação sintática e semântica. Senão ocorrerem erros de validação, ele é interpretado, o que disponibiliza um serviçopara ser acessado pelos cidadãos. A validação sintática visa verificar se os símbolosencontrados no script pertencem à gramática da linguagem. E a validação semân-tica verifica se os componentes utilizados de fato existem, se as mídias utilizadasnas transições foram declaradas no serviço e se os parâmetros apontados para cadacomponente estão corretos e em acordo com seu tipo. Caso ocorram erros, eles se-rão apresentados ao usuário na interface web de deployment e a implantação serácancelada, permitindo ao deployer ou desenvolvedor corrigir erros do script.

Figura 5.4: Implantação de um script CroMeL [Fonte: Elaborado pelo autor]

O final da implantação do script consiste no seu armazenamento no servidore posterior interpretação. A figura 5.5 ilustra o interpretador criado para CroMeL eas classes utilizadas pelo interpretador para realizar as funções necessárias durante

65

a interpretação de um script no Framework X-Gov. A interpretação do script acionaa classe CromelService, que implica em criar uma série de objetos para alimentara estrutura de dados interna necessária, e preparar as transições (e.g. gerador deQRCode, envio de e-mail, envio de sms). Cada componente tem uma estrutura dedados específica, mas compartilham o modelo de transição descrito no script e asregras de negócio executadas na inicialização de cada atividade.

Figura 5.5: Interpretação de um script CroMeL [Fonte: Elaborado pelo autor]

5.2 Gramática

A sintaxe da linguagem foi criada em inglês, de acordo com as convenções ado-tadas pelo projeto. Pensando-se que o objetivo é facilitar o trabalho do gestor público,é importante que seja fácil criar uma versão traduzida para português, o que pode-ria facilitar seu aprendizado por programadores brasileiros. Para fazer isso bastariatraduzir as palavras reservadas que forem necessárias no código do ANTLR.

Uma gramática pode ser considerada uma DSL projetada especificamente paradescrever outras linguagens. Ela é formada por um conjunto de regras que descrevemas frases de um linguagem, e o ANTLR é capaz de converter essas regras em umprograma reconhecedor. Os requisitos para construção da gramática da linguagemCroMeL determinam que ela deve suportar as construções a seguir (ilustradas pelosseus respectivos diagramas de sintaxe). O leitor poderá consultar os diagramas de

66

sintaxe para verificar a maioria dessas regras no apêndice C.3 (alguns diagramas desintaxe foram omitidos por serem extremamente simples).

1. Declaração de um ou mais serviços (Figura C.1);

2. Declaração de variáveis (Figura C.1);

3. Descrição das atividades que pertencem a um serviço (Figura C.4);

4. Descrição das mídias aplicadas a uma atividade e seus parâmetros (Figura C.4);

5. Declaração de transições entre mídias que pertencem a um serviço (Figura C.6);

6. Declaração de parâmetros para navegação dos componentes web que perten-cem a um serviço (Figura C.7).

Segundo Neto et al. (2009), existem muitas notações (metalinguagens) utiliza-das na definição gramatical das linguagens formais. Entre elas, as Expressões Regu-lares, o Backus-Naur Form (BNF), a Notação de Wirth e os Diagramas de Sintaxe sãobastante populares.

Os próximos parágrafos explicam em detalhes cada uma das regras léxicase sintáticas da linguagem CroMeL utilizando a Notação de Backus-Naur estendida(EBNF) e alguns exemplos. Para ver a gramática completa, o leitor deve consultar oapêndice C.1. Neste apêndice, as regras ainda estão sem as ações semânticas queserão apresentadas na seção 5.3).

Regras léxicas começam com uma letra maiúscula (para CroMeL essas regrasforam escritas todas em maiúsculo o que facilita sua identificação), e as regras sintá-ticas começam em minúsculo. Ambos os tipos de regras foram definidos no mesmoarquivo. A linguagem começa pela declaração do nome de sua gramática e esse nomefaz parte do nome da classe do código gerado (primeira linha da listagem 5.1).

A primeira regra sintática contém a raiz da linguagem que permite declarar zeroou mais variáveis e um ou mais serviços — o leitor pode ver que, na linha 2 da lista-gem 5.1, existe uma declaração da regra prog que contém zero ou muitas variáveis(var*) e um ou muitos serviços (service+). As variáveis podem ser utilizadas para ar-mazenar um valor de tipos diferentes e esse valor pode ser recuperado posteriormentedurante a interpretação do script.

Note que service é uma palavra-chave obrigatória e por isso aparece entre as-pas simples na regra gramatical service na linha 4 da listagem 5.1. Cada serviço, porsua vez, possui um nome opcional (service_name?) (atualmente o nome do serviçonão é utilizado para nada, porém no futuro poderá servir para identificar diferentesserviços criados em um mesmo script CroMeL), e a declaração de suas partes, quecorrespondem a uma ou mais atividades (task+), zero ou mais transições (transition*),

67

e navegação entre componentes web (web_navigation*) — sendo a primeira obrigató-ria e as outras duas opcionais, pois pode existir um serviço com apenas uma atividadee sem nenhuma transição.

1 grammar CroMeL;

2 prog : var* service+ ;

3 var : assign ;

4 service : ’service ’ service_name? ’{’ decl ’}’ ;

5 decl : task+

6 transition*

7 web_navigation*

8 ;

9 assign : ID ’=’ expr

Listagem 5.1: Raiz da linguagem

Quando uma variável for encontrada é executada a regra de atribuição (assign),que o leitor pode ver na linha 3 da listagem 5.1 e, de acordo com essa regra, recebe otoken ID (do analisador léxico) e seu respectivo valor, que inicia a execução de outraregra (expr ), que é apresentada posteriormente. O valor de uma variável pode conteruma seqüência de caracteres colocados entre aspas simples ou duplas, um númerointeiro ou um valor booleano. A entrada presente na listagem 5.2 é reconhecida pelasregras da listagem 5.1.

1 var1=’texto ’

2 var2 =123

3 var3=true

4 var4=’Detalhes do seu CPF ’

56 service ’Consulta CPF ’ { ... }

7 service ’Matricula Escolar ’ { ... }

Listagem 5.2: Sentenças de entrada para um serviço e declaração de variáveis

Na declaração de uma atividade (task ) — primeira linha da listagem 5.3 — éobrigatória a definição do seu nome (usado posteriormente para identificar um com-ponente em uma transição/navegação), e o padrão de tarefa dessa atividade colocadoapós a palavra-chave ‘of’ (usado posteriormente para definir a classe do componenteque será instanciada de acordo com a mídia). O conteúdo de uma atividade é colo-cado dentro de chaves ({ }) e contém a declaração do tipo de mídia e seus parâmetros.

Os parâmetros de cada mídia (params) contêm instruções para atribuição devalores aos parâmetros do componente. A entrada presente na listagem 5.4 é reco-nhecida pelas listadas em 5.3. Observe que para a atribuição dos valores nos pa-

68

râmetros de uma mídia podem-se usar as variáveis declaradas anteriormente, desdeque colocadas com o símbolo $ na frente, por exemplo, o leitor pode ver na linha 3das sentenças de entrada de uma atividade o uso da variável $var4 que deve ter sidodeclarada anteriormente.

1 task : ’task ’ task_name ’of ’ pattern_name ’{’ media+ ’}’ ;

2 media : MEDIA params ;

3 params : ’(’ assign (’,’ assign)* ’)’;

4 assign : ID ’=’ expr

5 task_name : ID ;

6 pattern_name : ID ;

7 expr : STRING

8 | INT

9 | BOOLEAN

10 | QID // substituir ID por valor em memoria

11 | REF // substituir ID por numero gerado pela Task.media

12 ;

Listagem 5.3: Gramática para descrição das ativadades de um serviço

A regra dos parâmetros (params) chama de maneira recursiva a regra de atri-buição (assign), e pode ser usada quando tiver apenas um parâmetro, ou para muitosparâmetros separados por vírgula, sendo que todos eles devem estar entre parênte-ses — veja o exemplo nas linhas 2,3 e 4 da listagem 5.4 dos parâmetros passadospara a mídia web, ou nas linhas 6,7 e 8 da mesma listagem os parâmetros passadospara a mídia mobile.

1 task ConsultaCpf of GetPreServiceInfo {

2 web(componentName=’Informacoes sobre como consultar seu CPF ’,

3 description=$var4 ,

4 urlCalled=’webCpfInfo ’

5 )

6 mobile(componentName=$var4 ,

7 uriCalled=’mobCpfInfo ’,

8 welcomeMessage=’Bem vindo a consulta de CPF ’

9 )

10 }

Listagem 5.4: Sentenças de entrada para uma atividade

A regra de atribuição (assign) de um valor utiliza um identificador (ID) de umavariável e uma expressão (expr ). A regra de expressão determina o tipo de dado porinferência de acordo com o token enviado pelo reconhecedor léxico. Os tipos podemser:

69

• STRING, que corresponde a um valor entre aspas simples ou duplas;

• INT, que corresponde a um valor numérico inteiro;

• BOOLEAN, que corresponde a um dos literais ‘true’ ou ‘false’;

• QID, que corresponde ao valor de uma variável declarada anteriormente e co-meça com ‘$’ seguido pelo nome da variável;

• REF, que corresponde à referência de um componente, deve começar por ‘&’seguido pelo componente identificado pelo nome ‘tarefa.mídia’ em que ele foideclarado.

Os outros elementos que fazem parte de um serviço (além das atividades) são:transições (transition) e navegações (navigation), que ocorrem entre mídias e compo-nentes (Listagem 5.5). Estes elementos são opcionais. Embora seja difícil imaginarum serviço em mídia cruzada sem nenhuma transição entre mídias, podem existirserviços de governo tão simples que não necessitam de transições, e neste caso oFramework X-Gov poderia ser usado com intuito de aproveitar os seus componentes.

Uma transição começa pela palavra reservada ‘transition’, seguida de qual tipode transição será utilizada (o tipo determina a classe a ser utilizada pelo FXG). Umatransição deve levar à ação de um componente para outro, o que fica explícito na regrade navegação (navigation). Para determinar uma navegação, utiliza-se a referência deum componente declarado em alguma atividade precedido pelo caractere ‘&’ — vejaum exemplo de entrada reconhecida por esse gramática na listagem 5.6, onde deveobservar a linha 1, que contém a declaração de uma transição do tipo BarCode, quedeve ser realizada entre o componente web declarado na atividade ConsultaCpf e ocomponente mobile declarado na mesma atividade.

1 transition : ’transition ’ transition_type navigation params ;

2 web_navigation : ’navigation ’ label navigation;

3 navigation : ’[’ begin ’->’ end ’]’ ;

4 begin : REF;

5 end : REF;

6 transition_type : ID ;

7 label : STRING ;

Listagem 5.5: Gramática para declaração de transições e navegações

Além da declaração da navegação entre os componentes, uma transição ge-ralmente necessitará de parâmetros, utilizados pela sua implementação, pois acionaoutros recursos como envio de um e-mail ou geração de uma imagem — a regra paraatribuição de parâmetros é a mesma apresentada anteriormente na listagem 5.3.

70

A regra de navegação (web_navigation) é mais simples do que uma transição.Ela contém um label usado na apresentação de um link e a declaração de navega-ção entre os componentes — da mesma maneira que ocorre em uma transição, oscomponentes são identificados pela atividade e pela mídia, como pode ser observadona listagem 5.6 na linha 9, onde foi declarada uma navegação do componente webda atividade InfoSobreMatricula para o componente web da atividade SelecaoEscola.Atualmente o recurso de navegação tem sido utilizado apenas pelos componentesweb, mas a CroMeL não tem nenhuma limitação na sua construção que a impeça deser utilizada para declarar navegação entre componentes de mídias diferentes.

1 transition BarCode [ &ConsultaCpf.web -> &ConsultaCpf.mobile ]

2 (BaseUrl=’http ://www.receita.fazenda.gov.br/WS/consultaCpf ’,

3 ErrorCorrection=’M’,

4 ImageSize=5,

5 LabelMessage=’Use esse QRCode para acessar o proximo passo do

servico.’,

6 TransitionId =7,

7 TransitionName=’QRCODE teste web ->mob ’)

89 navigation ’Veja os dados de sua matricula ’ [ &InfoSobreMatricula.

web -> &SelecaoEscola.web ]

Listagem 5.6: Sentenças de entrada para transição e navegação

As regras léxicas são mais simples que as sintáticas e servem para determinaros token utilizados pelas regras sintáticas. Esses tokens são formados pela cadeia decaracteres lidos e selecionados de acordo com as seguintes regras apresentadas nalistagem 5.7.

1 MEDIA : (’mobile ’ | ’web ’ | ’tv ’) ;

2 BOOLEAN : (’true ’|’false ’) ;

3 INT : ’0’..’9’+ ;

4 ID : (’a’..’z’|’A’..’Z’|’_’) (’a’..’z’|’A’..’Z’|’0’..’9’|’_

’)* ;

5 // referencia de uma variavel (usada para recuperar seu valor)

6 QID : ’$’ID ;

7 // uma referencia do tipo Task.media (usado para identificar

componentes)

8 REF : ’\&’ ID (’.’ MEDIA);

9 STRING : ’"’ .* ’"’ | ’\’’ ~(’\\’|’\’’|’\*’)* ’\’’ ;

10 // espacos em branco

11 WS : (’ ’|’\t’|’\r’|’\n’) {$channel=HIDDEN ;} ;

12 // comentarios

13 CMT : ’#’ ~(’\n’|’\r’)* ’\r’? ’\n’ {$channel=HIDDEN ;};

71

14 COMMENT : ’/*’ .* ’*/’ {$channel=HIDDEN ;} ;

Listagem 5.7: Regras léxicas

MEDIA identifica o tipo de mídia podendo ser apenas um dos literais ‘mobile’,‘web’ ou ‘tv’. Os tipos de dados reconhecidos são STRING, BOOLEAN e INT, e são di-ferentes da referência de uma variável QID que começa com ‘$’ e da referência de umcomponente REF que começa com ‘&’. Espaços em branco (que incluem tabs e saltode linhas), assim como comentários, não são enviados para o analisador sintático,pois é escolhido um canal de comunicação diferente (HIDDEN) 13.

O estudo da dependência entre as regras — que pode ser viso na figura 5.6 —pode ajudar a otimizar a construção do reconhecedor, permitindo identificar situaçõesde reuso e, dessa forma, criar um reconhecedor equivalente mais eficiente.

Figura 5.6: Grafo de dependência entre as regras sintáticas [Fonte: Elaborado peloautor]

O autômato finito deterministico (DFA) gerado para reconhecer todos os tokens13O ANTLR permite que cada token seja emitido por canais diferentes de comunicação entre o ana-

lisador léxico e sintático, assim como freqüências de rádio, o parser pode ‘sintonizar’ em um canal eignorar os tokens emitidos pelos outros

72

definidos tem 72 estados, o diagrama completo é encontrado no apêndice C.8. O re-sultado da geração de um reconhecedor a partir da gramática apresentada permiteresponder apenas SIM ou NÃO à pergunta, se as sentenças de entrada são válidas.Porém, para construir algo útil, como um interpretador, a gramática precisa ser ampli-ada com ações semânticas.

5.3 Semântica

Ações semânticas são blocos de código escritos na linguagem de programaçãodo programa reconhecedor gerado e inseridas em diversos pontos dentro da gramá-tica (como pode ser observado nos exemplos a seguir). O ANTLR realiza substituiçõesde símbolos relativos aos atributos declarados, parâmetros e retorno das regras sin-táticas, mas não interpreta nenhuma instrução inserida nesses blocos de código quepertence à linguagem destino do programa reconhecedor gerado.

Para interpretar o código da CroMeL uma série de ações semânticas foramcolocadas em sua gramática para extrair as informações necessárias na execução deum script. Essas ações devem ser capazes de atender os seguintes requisitos paraintegração da CroMeL com o Framework X-Gov :

• Para cada componente (definido pelo par atividade/mídia) deve ser atribuído umidentificador numérico único que pode ser utilizado em transições e navegaçõesentre os componentes;

• Para cada par padrão/mídia é determinado o tipo de componente a ser instan-ciado (o nome da classe que implementa o componente é encontrado em umarquivo de configuração externo, o que permite adicionar novos tipos de compo-nentes sem alteração na linguagem);

• A declaração de um tipo de transição determina a classe a ser instanciada (essetipo corresponde a uma classe que também fica em um arquivo de configuraçãoexterno);

• Os parâmetros dos componentes e das transições devem corresponder às pro-priedades de suas classes conforme foram declarados, para serem atribuídosaos objetos criados por meio de reflexão;

• As variáveis podem ser utilizadas para atribuir valores para qualquer parâmetrofacilitando reutilizar esses valores em parâmetros repetidos, assim como isolarparâmetros que mudam com freqüência;

• O nome do componente definido por um par atividade/mídia precedido pelo sinalde ‘&’ pode ser utilizado para fazer referência ao identificador numérico criado.

73

Declarações tanto de transição quanto navegação necessitam de identificadornumérico e o programador pode usar o seu nome.

• Identificar e extrair código embutido em uma atividade a ser executado quandouma atividade for inicializada.

Para ilustrar todas as regras semânticas adicionadas, a listagem 5.8 permiteacompanhar um exemplo de script de entrada que alimenta o interpretador da Cro-MeL com um serviço de agendamento médico. O leitor pode comparar essa entradacom a versão em XML do apêndice C.6, e poderá observar algumas vantagens no usoda CroMeL em comparação com a representação em XML, como por exemplo: o usode variáveis para atribuição de valores aos parâmetros, a declaração de componen-tes por meio de seu identificador (atividade/mídia) quando realizar uma transição ounavegação, e a inclusão de código executado no inicio de uma atividade.

1 GWSFindPrivateInformation=’http ://143.107.102.15/ govside/

GWSFindPrivateInformation/GWSFindPrivateInfo.asmx ’

23 service ’Exams Schedule ’ {

45 task BasicInfoAboutSchedule of GetPreServiceInfo {

6 web(componentName=’Basic information ’,

7 description=’For more information use the menu ’,

8 urlCalled=’webExamInfo ’

9 )

10 mobile(componentName=’informations ’,

11 uriCalled=’mobExamInfo ’,

12 welcomeMessage=’Welcome to the X-Media Service ’

13 )

14 tv(componentName=’My Exams List ’,

15 uriCalled=’tvExamInfo ’,

16 first=true

17 )

1819 <<Test if database is online >>=

20 unless databale_online? update_site ’come back later.’

21 @

22 <<Pre -notify health center >>=

23 var now = Time.now

24 schedule_new_exam(now)

25 @

26 }

2728 task ExamsList of FindPrivateInfo {

29 web(componentName=’My Exams List ’,

74

30 authenticationCompId =& Authentication.web ,

31 uriCalled=’webExamList ’,

32 dataUrl=$GWSFindPrivateInformation ,

33 getFullEntitiesListWebMethod=’GWSGetPermittedExams ’,

34 getEntityInformationWebMethod=’GWSGetExamInformation ’,

35 scheduleCompId =& Schedule.web

36 )

37 mobile(componentName=’My Exams List ’,

38 authenticationCompId =& Authentication.mobile ,

39 uriCalled=’mobExamList ’,

40 instructionText=’Select an exam:’,

41 listName=’Exams Requested ’,



44 getEntityInformationWebMethod=’GWSGetExamInformation ’

45 )

46 tv(componentName=’My Exams List ’,

47 entityType=’Exam ’,

48 compAuthId =& Authentication.tv,

49 compAuthId =& BasicInfoAboutSchedule.tv,

50 uriCalled=’tvExamList ’,



53 getEntityInformationWebMethod=’GWSGetExamInformation ’

54 )

55 }

5657 transition BarCode [ &BasicInfoAboutSchedule.tv -> &ExamsList.mobile ]

58 (BaseUrl=’http ://143.107.102.15/ poc3xgov/Mobile_Comp/mobile/

mobFindPrivExam ’,

59 ErrorCorrection=’M’,

60 ImageSize=5,

61 LabelMessage=’Use this QRCode to access next service step.’,

62 TransitionId =7,

63 TransitionName=’QRCODE teste web ->mob ’

64 )

6566 navigation ’See your exam list ’ [ &BasicInfoAboutSchedule.web -> &

ExamsList.web ]

6768 }

Listagem 5.8: Script CroMeL de entrada

Toda ação semântica embutida na gramática fica entre { }. Por exemplo, paraguardar o valor de uma variável quando executada a regra ‘var’ é recuperado os valo-res de ‘ID’ e ‘expr’ obtidos pela chamada da regra ‘assign’ por meio de uma instrução

75

de retorno dos valores ‘n’ e ‘v’. A chamada de uma regra é bem semelhante a cha-mada de uma função em uma linguagem de programação, e permite passar e retornarparâmetros. Pode-se observar pela regra ‘assign’ na listagem 5.13 que ela é capaz deretornar dois valores simultaneamente para a regra ‘var’, que armazena o nome e ovalor da variável na memória, que é um HashTable no escopo global. Esta ação seráutilizada para satisfazer o requisito de substituir os valores de variáveis na declaraçãode parâmetros. A declaração de uma variável pode ser visto no código de entrada 5.8na linha 1.

1 var : assign

2 {

3 System.out.println (" Declaracao de variavel: "+ $assign.n

+"="+ $assign.v);

4 memory.put($assign.n, $assign.v);

5 };

6 assign returns[String n, Object v]

7 : ID ’=’ expr

8 {

9 $n = $ID.text;

10 $v = $expr.value;

11 };

Listagem 5.9: Semântica de declaração de variável

A semântica de uma atividade (task ) apresentada na listagem 5.10 é um poucomais complexa pois envolve a passagem de parâmetros, apelidos para regras e usode variáveis com escopo dinâmico. Em resumo, ela cria os objetos correspondentesaos componentes declarados na atividade, determina o tipo de cada componente ecoleta seus parâmetros. Depois guarda a representação do componente criado emuma lista de componentes de escopo global, e por fim, executa um ou mais códigosembutidos no início de cada atividade.

Para realizar isso, observe primeiramente a regra ‘media’: Ela recebe como pa-râmetro o nome da atividade (taskName) em que foi declarada, e o padrão de projetoassociado a essa atividade (patternName), — linha 12 da listagem 5.10 — obtém umidentificador para o componente por meio de uma variável contadora que pertenceao escopo de um serviço (assim nenhum componente do mesmo serviço receberá omesmo identificador) e guarda o identificador em uma tabela de símbolos global, paraser usado posteriormente quando fizer referência a este componente pelo par (nomeda atividade, mídia) na linha 17. Em seguida, o tipo do componente é determinadode acordo com o padrão de tarefa e o tipo de mídia (linha 20), obtém sua lista deparâmetros (linha 23) e por fim é criado um objeto que contém os dados do compo-nente e serve para representar o componente reconhecido, armazenando na lista de

76

componentes criado na etapa final do interpretador (linha 28).Ao final da regra ‘task’ é executado o código embutido no início de uma ativi-

dade que pode ser visto nas linhas 7-8. Esse código escrito em Ruby14 é passadopara o IronRuby da versão em .NET ou JRuby da versão em Java dentro do FXG.Para que o código seja processado pelo interpretador na versão em C#, é chamadaa função RunCromelScript da classe CromelService listado no apêndice C.7 — o lei-tor pode ver como um código Ruby é executado pelo Dynamic Language Runtime do.NET nas linhas 23-33.

1 task

2 : ’task ’ task_name { System.out.println (" Declaracao da atividade

:"+ $task_name.text); }

3 ’of’ pattern_name ’{’ media[$task_name.text , $pattern_name.

text]+

4 (lc=literate_code

5 {

6 // Executa as regras definidas em um servico

7 System.out.println (" Executa codigo embutido: "+

$lc.comment);

8 System.out.println($lc.code);

9 }

10 )* ’}’ ;

1112 media [String taskName , String patternName]

13 : m=MEDIA params

14 {

15 int componentId = $service :: componentId ++;

16 String media = $m.text;

17 String componentName = $taskName +"."+ media;

18 componentIds.put(componentName , componentId);

1920 String componentType = $patternName +"."+ media;

21 System.out.println ("Novo componente do tipo "+

componentType +" [id="+ componentId +"]");

2223 System.out.println (" parametros ="+ $params.p);

2425 ComponentDTO dto = new ComponentDTO ();

26 dto.type = componentType;

27 dto.parameters = $params.p;

28 components.add(dto);

29 };

14Outras linguagens como JavaScript ou Python poderiam ser suportadas desde que incluído algumparâmetro na CroMeL para indicar em qual linguagem o código embutido foi escrito.

77

Listagem 5.10: Semântica de uma atividade

A semântica de navegação (listagem 5.11) é bem mais simples e se resumea armazenar o label (linha 6), e obter o identificador dos componentes de navegaçãoreferenciados na entrada (linhas 7 e 8). Finalmente guarda um objeto que representaa navegação na lista global de objetos de navegação (linha 9). Para obter o ID do com-ponente de navegação referenciado, as regras ‘begin’ e ‘end’ executam uma funçãoembutida no interpretador (linhas 19 e 22)15.

1 web_navigation

2 : ’navigation ’ label

3 navigation

4 {

5 NavigationDTO dto = new NavigationDTO ();

6 dto.label = $label.text;

7 dto.begin = $navigation.b;

8 dto.end = $navigation.e;

9 navigations.add(dto);

10 };

11 navigation returns[int b, int e]

12 : ’[’ begin ’->’ end ’]’

13 {

14 $b = $begin.id;

15 $e = $end.id;

16 System.out.println (" Navegacao do componente ["+ $begin.id

+"] -> ["+ $end.id+"]");

17 };

18 begin returns[Integer id]

19 : REF { $id = getComponentId($REF.text); };

2021 end returns[Integer id]


Listagem 5.11: Semântica de navegação

Uma transição tem ações bem parecidas com uma navegação, no que se referea navegação entre componentes (linhas 11 e 12 da listagem 5.12), acrescentando sualista de parâmetros obtidos pela chamada da regra ‘params’, armazenados em umobjeto na linha 10 e depois guardado na lista global de transições na linha 13.

15O código completo que contém essa função embutida pode ser visto no apêndice C.2 declarado nalinha 48.

78

1 transition

2 : ’transition ’ transition_type

3 navigation

4 params

5 {

6 System.out.println ("Nova transicao do tipo "+

$transition_type.text);

7 System.out.println (" parametros ="+ $params.p);

8 TransitionDTO dto = new TransitionDTO ();

9 dto.type = $transition_type.text;




13 transitions.add(dto);

14 };

Listagem 5.12: Semântica de uma transição

A regra ‘params’ apresentada na listagem 5.13 tem alguns elementos novos:tem uma rotina inicial para criar um objeto do tipo HashMap (linha 3) que implementauma estrutura de dados do tipo nome-valor para guardar os parâmetros obtidos naentrada. Como um componente ou transição pode conter um ou mais parâmetros, elatem uma função para guardar o parâmetro do primeiro caso (linha 5) e um loop paraguardar os outros parâmetros quando fornecidos (linha 6); como existe mais de umachamada à mesma regra ‘assign’, para cada chamada foi atribuído um label ‘a1’ e ‘a2’para que possam ser utilizados de maneira independente nas suas respectivas regrassemânticas. Por fim, esse HashMap é retornado para que quem chamou essa regrapossa recuperar seus parâmetros. Esses parâmetros são utilizados na inicializaçãodos componentes e das transições, como visto anteriormente no código semântico daslistagens 5.12 e 5.10 — se o leitor quiser, pode ver exemplo dos parâmetros passadosaos componentes nas linhas 6-8, 10-12, 14-16, 29-35, 37-44, 46-53 e exemplo dosparâmetros passados a uma transição nas linhas 58-63 do script de entrada 5.8

1 params returns[Map p]

2 @init {

3 p = new HashMap ();

4 }

5 : ’(’ a1=assign { p.put($a1.n, $a1.v); }

6 (’,’ a2=assign { p.put($a2.n, $a2.v); } )*

7 ’)’;

Listagem 5.13: Semântica dos parâmetros de componentes e transições

Toda atribuição de um valor apresentado pela regra ‘assign’ (listagem 5.13)

79

chama a regra ‘expr’ (listagem 5.14) que é capaz de determinar o tipo de dado por in-ferência (de acordo com o TOKEN emitido), e fazer a conversão necessária. Quandoo valor identificado começar com $ (TOKEN QID) o valor da variável armazenada érecuperado na memória. Quando o valor identificado começar com & (TOKEN REF),que corresponde a referência de um componente, seu identificador é buscado na ta-bela de símbolos global. Observe que o tipo REF é utilizado também nas regras denavegação. Para não reiterar o código da ação de consultar a tabela de símbolos, foideclarado um método membro do parser.

1 expr returns[Object value]

2 : STRING { $value = $STRING.text; }

3 | INT { $value = Integer.parseInt($INT.text); }

4 | BOOLEAN { $value = Boolean.parseBoolean($BOOLEAN.text); }


7 {

8 // busca valor na memoria (eliminando o $ que nao foi

colocado na tabela)

9 Object v = memory.get($QID.text.substring (1));

10 // se encontrado seta o valor de retorno , caso contrario

imprime erro

11 if ( v!=null ) {

12 $value = v;

13 System.out.println (" resolucao da variavel "+$QID

.text +"="+v);

14 }

15 else System.err.println (" undefined variable "+$QID.text)

;

16 }


20 {

21 $value = getComponentId($REF.text);

22 }

23 ;

Listagem 5.14: Semântica de expressões

Para finalizar a apresentação das ações semânticas implementadas, veja ocódigo da regra ‘service’ na listagem 5.15. Elas são responsáveis por acionar asfunções do interpretador que criam os objetos dos componentes (linha 9), os objetosde transição (linha 15) e navegação (linha 22) guardados nas listas globais. Note quetodas essas ações são executadas após todos os elementos de um serviço declarado

80

em um script terem sido reconhecidos. O leitor deve se lembrar que código semânticopode ser inserido em diversos pontos da gramática, esse código é transplantado parao parser gerado pelo ANTLR. Para executar um código ao final da execução de umaregra ele é inserido na instrução ‘@after’ (linha 6).

1 service

2 scope {

3 // contador usado para atribuir um ID para cada

componente em um servico

4 int componentId;

5 }

6 @after {

7 System.out.println (" Execucao apos processamento da

entrada !");

89 // Cria os componentes da CroMeL e seta seus parametros

por reflexao

10 for(ComponentDTO component : components) {

11 System.out.println (" Criando componente "+

component.type);

12 System.out.println (" Setando "+ component.

parameters.size()+" parametros ");

13 }

1415 // Cria os objetos de transicao e seta seus parametros

por reflexao

16 for(TransitionDTO transition : transitions) {

17 System.out.println (" Criando transicao "+

transition.type);

18 System.out.println (" Setando "+ transition.

parameters.size()+" parametros ");

19 System.out.println (" Transicao entre componente

"+ transition.begin+" e "+ transition.end);

20 }

2122 // Cria os objetos de navegacao

23 for(NavigationDTO navigation : navigations) {

24 System.out.println (" Criando navegacao "+

navigation.label);

25 System.out.println (" Navegacao entre "+ navigation

.begin+" e "+ navigation.end);

26 }

27 }

28 : { $service :: componentId =1; } // inicializacao do contador

29 ’service ’ service_name? ’{’ decl ’}’ ;

81

Listagem 5.15: Semântica de um Serviço

A maior parte do código semântico da CroMeL foi apresentada nas seções an-teriores. Algumas partes foram omitidas por tratarem de instruções para resolução donome de classes, da definição de classes internas, inicialização das listas globais decomponentes, transições e navegação. O leitor, pode consultar o código da gramáticacompleta no apêndice C.2.

Quando este código é alimentado com a entrada apresentada na listagem 5.8,obtêm-se a saída apresentada na listagem 5.16, que serve para acompanhar a execu-ção do interpretador quando alimentado com o script CroMeL de entrada supracitado.Essa versão apresentada corresponde à depuração da implementação da CroMeL econtém uma série de instruções de log (println) que foram colocadas para permitir oacompanhamento da execução de um script em cada uma de suas regras, e dessaforma, pode-se observar que todos os elementos necessários para executar o scriptestão presentes.

Para que os componentes, transições e navegações sejam processados pelointerpretador na sua versão em C#, são chamadas respectivamente as funções Cre-ateComponents (linha 86), CreateTransitions (linha 125) e CreateNavigations (linha36) da classe CromelService listado no apêndice C.7. Essa classe serve como umacamada de serviço usada pelo código do interpretador para processamento das ins-truções reconhecidas no script. Ela por sua vez utiliza outras classes auxiliares comoo ComponentFactory, listado no apêndice C.8, para processar o script e acionar fun-ções do FXG. A classe ServiceComponent serve como uma interface simplificada paragrande quantidade de código executado pelo FXG. Ela implementa o padrão de pro-jeto Façade (Gamma et al., 1995). Para construção das classes que transmitem osdados entre a camada do interpretador e o ServiceComponent foi aplicado o padrãode projeto Data Transfer Object (Alur et al., 2001), e para a criação dos componen-tes, transições e navegações foi aplicado o padrão de projeto Factory (Gamma et al.,1995).

1 - declarac~ao da variavel: GWSFindPrivateInformation=’http

://143.107.102.15/ govside/GWSFindPrivateInformation/GWSFindPrivateInfo

.asmx ’

2 Declarac~ao da atividade:BasicInfoAboutSchedule

3 Novo componente do tipo GetPreServiceInfo.web [id=1]

4 parametros ={ componentName=’Basic information ’, description=’For

more information use the menu ’, urlCalled=’webExamInfo ’}

5 Novo componente do tipo GetPreServiceInfo.mobile [id=2]

6 parametros ={ componentName=’informations ’, uriCalled=’mobExamInfo

’, welcomeMessage=’Welcome to the X-Media Service ’}

82

7 Novo componente do tipo GetPreServiceInfo.tv [id=3]

8 parametros ={ componentName=’My Exams List ’, uriCalled=’tvExamInfo

’, first=true}

9 Executa codigo embutido: Pre -notify health center

10 var now = Time.now

11 schedule_new_exam(now)

12 Executa codigo embutido: Test if database is online

13 unless databale_online? update_site ’come back later.’

14 Declarac~ao da atividade:ExamsList

15 Erro: referencia indefinida &Authentication.web

16 - resoluc~ao da variavel $GWSFindPrivateInformation=’http


.asmx ’

17 Erro: referencia indefinida &Schedule.web

18 Novo componente do tipo FindPrivateInfo.web [id=4]

19 parametros ={ getFullEntitiesListWebMethod=’GWSGetPermittedExams ’,

componentName=’My Exams List ’, uriCalled=’webExamList ’,

authenticationCompId=null , scheduleCompId=null ,

getEntityInformationWebMethod=’GWSGetExamInformation ’, dataUrl

=’http ://143.107.102.15/ govside/GWSFindPrivateInformation/

GWSFindPrivateInfo.asmx ’}

20 Erro: referencia indefinida &Authentication.mobile



.asmx ’

22 Novo componente do tipo FindPrivateInfo.mobile [id=5]


componentName=’My Exams List ’, uriCalled=’mobExamList ’,

authenticationCompId=null , instructionText=’Select an exam:’,

getEntityInformationWebMethod=’GWSGetExamInformation ’, dataUrl

=’http ://143.107.102.15/ govside/GWSFindPrivateInformation/

GWSFindPrivateInfo.asmx ’, listName=’Exams Requested ’}

24 Erro: referencia indefinida &Authentication.tv

25 - resoluc~ao da referencia id = 3



.asmx ’

27 Novo componente do tipo FindPrivateInfo.tv [id=6]


componentName=’My Exams List ’, uriCalled=’tvExamList ’,

compAuthId =3, getEntityInformationWebMethod=’

GWSGetExamInformation ’, entityType=’Exam ’, dataUrl=’http

://143.107.102.15/ govside/GWSFindPrivateInformation/

GWSFindPrivateInfo.asmx ’}



31 Navegac~ao do componente [3] -> [5]

83

32 Nova transic~ao do tipo BarCode

33 parametros ={ BaseUrl=’http ://143.107.102.15/ poc3xgov/Mobile_Comp/

mobile/mobFindPrivExam ’, ImageSize=5, TransitionName=’QRCODE

teste web ->mob ’, ErrorCorrection=’M’, LabelMessage=’Use

this QRCode to access next service step.’, TransitionId =7}



36 Navegac~ao do componente [1] -> [4]

37 Execuc~ao apos processamento da entrada!

38 Criando componente GetPreServiceInfo.web

39 armazenamento de 3 parametros

40 Criando componente GetPreServiceInfo.mobile


42 Criando componente GetPreServiceInfo.tv


44 Criando componente FindPrivateInfo.web


46 Criando componente FindPrivateInfo.mobile


48 Criando componente FindPrivateInfo.tv


50 Criando transic~ao BarCode


52 transic~ao entre os componentes 3 e 5

53 Criando navegac~ao ’See your exam list ’

54 navegac~ao entre os componentes 1 e 4

Listagem 5.16: Codigo de Saida

5.4 Discussão dos Resultados

Essa seção apresentou as técnicas utilizadas para criar o interpretador da Cro-MeL utilizado no Framework X-Gov. Toda sua sintática e semântica foi definida nassessões 5.2 e 5.3, e mostrou-se como uma entrada é processada internamente pelointerpretador.

Provou-se que por meio da CroMeL é possível declarar um serviço, suas ati-vidades, transições e navegações, além de outras construções mais específicas paramapear os conceitos do domínio de governo em mídia cruzada na implementaçãodo Framework X-Gov. Da maneira como a linguagem foi construída, ela permite in-cluir novos tipos componentes e tipos de transições, o que a torna extensível para ocontínuo aperfeiçoamento do FXG.

Uma limitação observada refere-se a possibilidade de declarar apenas um tipode componente de cada mídia dentro de uma atividade. Como não foram criadoscenários que necessitassem de mais de um tipo de componente da mesma mídia

84

na mesma atividade, essa limitação não foi percebida inicialmente, porém ela podeser contornada com a declaração de outra atividade com o mesmo padrão de tarefa,onde um novo componente do mesmo tipo e para mesma mídia daquele declaradoanteriormente pode ser definido.

Ficou claro pelas propostas de implementação as vantagens de construir umaDSL Externa, e embora a alternativa adotada seja mais trabalhosa pois necessitacriar um reconhecedor e um interpretador, e as outras alternativas (notação em XMLou DSL Interna) já fornecem uma ou as duas etapas prontas, ela se mostrou a maisversátil para definição das notações e da semântica desejada.

85

6 CONCLUSÕES

“O verdadeiro prazer está em descobrir ao invés de saber.” (Isaac Asimov)

Esta seção apresenta uma discussão dos resultados obtidos tanto no desen-volvimento da linguagem quanto na sua aplicação. Ainda, resume as principais contri-buições desta pesquisa e propõe recomendações para trabalhos futuros.

Diante das necessidades de configuração do Framework X-Gov e dos resulta-dos obtidos na implementação da CroMeL constatou-se que, para muitos problemasespecíficos, linguagens mais próximas de linguagens naturais oferecem um alto graude expressividade. Infelizmente linguagens naturais são ambíguas e difíceis de seremreconhecidas e interpretadas por um computador, mas com um pouco de trabalho épossível definir um subconjunto dessa linguagem, sem ambiguidade, e ainda assimexpressiva o bastante para se aplicar a um domínio de problema.

Abstração é um conceito chave no progresso da engenharia de software. En-capsulando detalhes de operações de baixo nível em abstrações de alto nível, desen-volvedores são mais produtivos e utilizam de um vocabulário determinado por umalinguagem para comunicar-se com especialistas de domínio nos mesmos termos. De-pois de trabalhar por um certo tempo com as abstrações do nível ‘n’, padrões emergeme permitem identificar novas abstrações no nível ‘n+1’. Assim o conceito continuaráa ser desenvolvido. O principal objetivo de uma DSL é aumentar a produtividade deEngenheiros de Software abstraindo código boilerplate e de níveis mais baixos deabstração.

Os mecanismos usados nas linguagens de programação tradicionais para de-finir abstrações, como métodos, atributos e classes, não serão suficientes para criarnovas camadas de abstração no futuro. Mesmo que as bibliotecas e frameworks se-jam boas formas de implementar funcionalidades, as linguagens que o desenvolvedorprecisa utilizar para acessar essas funcionalidades são muitas vezes inadequadas.Atualmente, diversos enfoques têm sido dados à questão de buscar novos mecanis-mos de abstração para o desenvolvimento de software, incluindo arquitetura dirigidaa modelo (model-driven-architecture) (Ivkovic & Kontogiannis, 2004), engenharia di-rigida a modelo (model-driven-engineering) (Schmidt, 2006), modelagem específicade domínio (domain-specific modeling) (Kelly & Tolvanen, 2008), fabricas de software(software-factories) (Greenfield & Short, 2003) e software intencional (intentional soft-

86

ware) (Laird & Barrett, 2009).Existem dois caminhos para se projetar uma DSL: um caminho descendente,

que observa as palavras do domínio de problema e foca em uma boa linguagem paracapturar os requisitos funcionais de forma não ambígua sem se preocupar como a lin-guagem será interpretada; e o caminho ascendente, que observa padrões de código,repetições, e busca maneiras de descrever as variações encontradas para que pos-sam ser substituídas por abstrações, as quais são interpretadas nessa nova linguagemmais concisa.

O caminho seguido para a definição da CroMeL foi intermediário (tanto descen-dente quanto ascendente), alguns elementos necessários na linguagem foram obtidosdos requisitos do Framework X-Gov, o que inclui a definição de serviços de governo,atividades e transições entre mídias, e outros elementos foram determinados pelopróprio código implementado no Gerenciador de Componentes e no arquivo de confi-guração em XML utilizado por ele.

6.1 Análise dos Resultados

O desenvolvimento da CroMeL apresentou resultados específicos para cadauma de suas fases:

• Na fase de análise foi possível identificar que cada padrão de tarefa possui umtipo de componente específico para cada uma das mídias utilizadas no projeto(web, tv e mobile), em outras palavras, um componente está relacionado a umpadrão de tarefa e a uma mídia, identificados por uma classe especializada quecontém atributos e comportamentos específicos para as necessidades de cadamídia. Desta forma, foi possível determinar que um dos elementos da linguagemdeve identificar o tipo do componente, e para isso necessita reconhecer qual opadrão de tarefa e a mídia associada, para ser possível determinar qual objetodeve ser criado — os padrões utilizados nessa fase foram ‘Informal ’ e ‘Extractfrom code’ apresentados na tabela 2.3 da sessão 2.4.2.

• Na fase de projeto, observou-se que a CroMeL necessitaria permitir adicionarnovos componentes e realizar uma busca pelo nome de suas classes. Para su-prir essa necessidade foi desenvolvido um dicionário externo à linguagem, queindica para cada tipo de componente a classe que o implementa (determinadopelo padrão de tarefa x mídia). Constatou-se que a linguagem também deveriapermitir a definição de parâmetros para os componentes enquanto eles estavamsendo desenvolvidos e alterados, portanto sua gramática foi construída para serflexível nesse ponto, tanto em relação ao número de parâmetros quanto aosseus nomes e valores. Também foi decidido acrescentar recursos semânticos

87

para facilitar sua utilização por um programador na hora de fazer referência aoscomponentes declarados. Assim, outros elementos da linguagem surgiram parareferenciar componentes durante a declaração de uma transição ou navegação— dentre as opções de padrões encontrados nessa fase de acordo com a ta-bela 2.4 da sessão 2.4.3 foi aplicado o padrão ‘Formal ’.

• Durante a implementação ocorreram as maiores mudanças. A primeira versãoimplementada foi na forma de uma DSL Interna em Ruby. Embora o Ruby, assimcomo outras linguagens como Groovy, Scala e Boo, ofereçam ótimos recursospara definir extensões funcionais, como classes abertas, captura de mensagenspara métodos que não existem e outros “truques” de meta-programação, o quefaz delas boas candidata para a construção de uma DSL interna, essa alternativatrouxe algumas desvantagens: não existe separação entre a sintaxe da DSL eda GPL; dificuldade em mapear erros relativos a DSL; dificuldade em balancearespecificidade do domínio dentro dos limites de construção sintática da GPL; ousuário (programador) deve conhecer a linguagem hospedeira e as novas cons-truções da DSL para usar esta solução. Assim, inicialmente foi aplicado o padrão‘Embedding’ encontrado na tabela 2.7 para construção de uma linguagem em-butida na linguagem Ruby.

• A nova implementação como uma DSL Externa permitiu um controle total desua sintaxe. Para o desenvolvimento dessa solução foi especificada a gramáticaformalmente em EBNF e utilizada a ferramenta ANTLR para geração do reconhe-cedor e do interpretador da CroMeL (apresentados na sessão 5). Nesse caso,o usuário da CroMeL (programador) utiliza uma nova notação para declarar oselementos de configuração de um serviço (i.e. atividades, transições e nave-gações) utilizado pelo Framework X-Gov. Uma das principais vantagens dessaferramenta em comparação com outras (e.g. lex/yacc, bison, tree-top) é que elaé capaz de gerar o código do reconhecedor em diversas linguagens de progra-mação, sendo Java e C# importantes para essa solução. Dessa forma foi criadoo interpretador da CroMeL, que substitui o Gerenciador de Componentes de-senvolvido anteriormente que trabalhava com XML1. O interpretador conta comclasses auxiliares para implementar as ações determinadas na fase de análise eprojeto — Na implementação final apresentada foi utilizado o padrão ‘Interpreter ’encontrado na tabela 2.7 da sessão 2.4.4.

• Após a fase de implementação foi necessário criar um mecanismo de deploy-ment para um arquivo CroMeL ser instalado no servidor do Framework X-Gov.

1XML não é uma interface de programação adequada para o ser humano, veja http://www.ibm.com/developerworks/xml/library/x-sbxml.html

88

6.2 Reflexões

Estudos demonstram que a maioria dos projetos de software falha, seja porquenão cumprem o orçamento, ou não cumprem o cronograma, ou as funcionalidades nãoatendem às necessidades dos usuários ou porque todos estes fatores estão presentesem conjunto. Alguns deles ocorrem devido a problemas de comunicação nas diversasfases de projeto conhecidas pela engenharia de software 2.

Em inúmeros casos, devido à perda de informações, simplificações, generali-zações na fase de análise, a diferença entre o resultado obtido e o esperado é muitogrande. Essa distância do resultado é um fator de risco para qualquer projeto de soft-ware, no qual regras de negócio devem ser definidas pelos especialistas e praticantese os programadores precisam compreender e implementar essas regras — usar umalinguagem mais próxima do domínio do problema pode ser uma forma de minimizarproblemas dessa natureza.

O desenvolvimento de uma DSL é difícil pois requer conhecimento de domí-nio e na linguagem de desenvolvimento, mas poucas pessoas têm os dois (Merniket al., 2005). Embora já seja possível criar ambientes de mídia cruzada, essa nãoé uma tarefa fácil, recorre-se na maioria das vezes à soluções ad-hoc que utilizamapenas uma tecnologia/plataforma específica. Seria ideal a utilização combinada dediversas tecnologias e dispositivos para emergir sistemas dessa natureza. Esse foi oobjetivo da construção do Framework X-Gov e consequentemente de sua linguagemde modelagem, a CroMeL.

A construção de linguagens pequenas (declarativas) com alto poder de expres-são dentro de um domínio de problema não é uma prática nova da Engenharia deSoftware, mas encontra-se em um momento de renaissance e não se trata de umaarte perdida, aplicável apenas para construção de compiladores ou protocolos de co-municação, como pode ser ser observado nesta pesquisa, portanto deve(ria) tornar-semais popular no desenvolvimento das mais diversas soluções.

Criar uma DSL Interna foi a idéia inicial deste trabalho, no entanto, durantea implementação, notou-se não se tratar da criação de uma “nova” linguagem, masapenas uma lapidação de uma linguagem pré-existente para incluir algumas expres-sões idiomáticas específicas do domínio. Essa pseudo-linguagem ainda estaria presaa todas construções sintáticas da linguagem hospedeira, como por exemplo, o usoda notação de ponto (.) para acesso de métodos e atributos. Ainda, a validade desua implementação seria questionável, pois era aplicável apenas a uma única lingua-gem hospedeira. No entanto, uma vantagem dessa forma de implementação é quenão precisa especificar a gramática formalmente — o que deve facilitar a entrada de

2Veja figura popular que ilustra esses problemas na Engenharia de Software http://www.openplans.org/projects/opencore/iteration-tracker/software_engineering_explained.gif

89

muitos programadores a este universo.A decisão em usar o ANTLR foi acertada, pois além de contar com um arse-

nal de recursos como livros, sites, e exemplos, também disponibiliza uma excelenteferramenta de desenvolvimento chamada ANTLRWorks, que pode ser verificada noapêndice C.9, e plug-ins para trabalhar com sua gramática no Netbeans, Eclipse e Vi-sual Studio. O uso dessa ferramenta tornou mais simples o trabalho de construção daCroMeL como pode ser observado pelas seguintes métrica: 198 linhas de código naCroMeL.g geraram 1214 linhas de código do analisador léxico e 1600 linhas de códigodo analisador sintático, totalizando 2814 linhas de código geradas automaticamente.Isso corresponde a cerca de 7% do trabalho de programar o mesmo reconhecedormanualmente.

As ações semânticas foram inseridas diretamente nas regras do parser tor-nando a gramática complexa, o que dificulta sua manutenção. Poderia ser criada umarepresentação intermediária na forma de uma Abstract Syntax Tree (AST), por meiode regras de tradução da gramática, e incluir uma nova fase no processo que recebea AST criada e executa as ações semânticas da mesma forma sobre uma estruturade dados mais conveniente. Uma sugestão de melhoria para implementação é refato-rar a gramática para utilizar essa representação intermediária, facilitaria a inclusão denovas ações semânticas.

Com algumas soluções “engenhosas” para construir uma DSL Externa pode-sedespender menos tempo do que a princípio aparentava, por meio da construção deuma sintaxe simplificada, padrões de projeto, e o uso de uma linguagem hospedeiracom recursos de reflexão. A mesma técnica poderia ser aplicada a outras partes doFramework X-Gov, como por exemplo, na integração de um componente com as APIsdo governo ou com o gerenciador de transições. No entanto a principal dificuldade nodesenvolvimento da CroMeL foi em criar uma linguagem para servir a um frameworkque não estava pronto e não havia uma versão estável ou especificada.

6.3 Trabalhos Futuros

Esta pesquisa é o início de um trabalho que pretende criar uma linguagemdeclarativa para especificar serviços de governo em mídia cruzada, pautado pela im-portante questão de inserir cross-media na interação do governo com os cidadãos, e apotencialidade para sua continuidade. Existe uma série de possíveis trabalhos futurosa serem desenvolvidos:

1. Validação dos estudos sobre métodos de desenvolvimento de linguagem espe-cífica de domínio;

2. Estudo sobre um processo de desenvolvimento interativo e incremental paraconstrução de DSLs;

90

3. Estudo de novas alternativas para construção de linguagens e os limites de cadatécnica. A determinação desses limites ainda é um desafio para os Engenheirosde Software;

4. Estudo destinado a solucionar o problema da análise de um domínio com basena Engenharia de Informação;

5. Estudo de alternativas sintáticas para construção da linguagem CroMeL.

6. Tradução das palavras reservadas da sintaxe da CroMeL para o idioma portu-guês, o que pode ser um atrativo para desenvolvedores brasileiros;

7. Desenvolvimento de plug-ins para o Eclipse, Netbeans e/ou Visual Studio paraoferecer suporte a linguagem CroMeL com realce de sintaxe, recurso de auto-completar, refactoring, entre outros;

8. Melhorar o suporte a informações sobre erros do reconhecedor para facilitar autilização da linguagem;

9. Criação de um editor que permita modificar uma configuração já instalada noservidor (semelhante aqueles disponíveis pelas ferramentas do tipo wiki).

91

REFERÊNCIAS

Abelson, H. e Sussman, G. J. (1996). Structure and Interpretation of Computer Pro-grams. MIT Press, Cambridge, MA, USA.

Alur, D., Malks, D., e Crupi, J. (2001). Core J2EE Patterns: Best Practices and DesignStrategies. Prentice Hall PTR, Upper Saddle River, NJ, USA.

Bennett, K. H. e Rajlich, V. T. (2000). Software maintenance and evolution: a roadmap.In ICSE ’00: Proceedings of the Conference on The Future of Software Engineering,pp. 73–87, New York, NY, USA. ACM.

Bentley, J. (1986). Programming pearls: little languages. Commun. ACM, 29(8):711–721.

Bergin, Jr., T. J. e Gibson, Jr., R. G., editors (1996). History of programminglanguages—II. ACM, New York, NY, USA.

Biggerstaff, T. J. (1998). A perspective of generative reuse. Ann. Softw. Eng., 5:169–226.

Bolter, J. D. e Grusin, R. (2000). Remediation: Understanding New Media. The MITPress, 1st edition.

Boumans, J. (2004). Cross media: E-content report 8. Disponível em<http://www.acten.net>. Acesso em: 10 abr. 2008.

Brooks, Jr., F. P. (1975). The mythical man-month. In Proceedings of the internationalconference on Reliable software 193, p., New York, NY, USA. ACM.

Cunha, M. R. (2006). Possibilidades tecnológicas apontam para mudanças em con-ceitos da comunicação. Razón y Palabra, v. 53, p. 1.

Dena, C. (2007). Patterns in Cross-Media interaction design: It’s much more thana URL. In Proceedings of 1st International Conference on Crossmedia InteractionDesign, pp. 4–10, Hemavan, Sweden.

Denny, M. (2003). Ontology building: A survey of editing tools.

92

http://www.xml.com/lpt/a/2002/11/06/ontologies.html.

EclipseFoundation (2009). Eclipse modeling project. http://www.eclipse.org/modeling/.

Fach, P. W. (2001). Design reuse through frameworks and patterns. IEEE Softw.,18(5):71–76.

Fernandez, O. (2007). Agile dsl development in ruby.http://www.infoq.com/presentations/agile-dsl-development-in-ruby.

Filgueiras, L. (2007). X-gov: mídia cruzada em serviços de governo. Plano de Tra-balho LTS2007.PR.029.00, PCS: Departamento de Engenharia de Computação eSistemas digitais – Escola Politécnica da USP.

Filgueiras, L. V. L., Correa, D. O., Neto, J. S. O., e Facis, R. P. (2008). X-gov planning:How to apply cross media to government services. In ICDS, pp. 140–145. IEEEComputer Society.

Ford, N. (2008). Advanced dsls in ruby. http://rubyconf2008.confreaks.com/advanced-dsls-in-ruby.html.

Fowler, M. (2008). Domain specific languages. http://martinfowler.com/dslwip/.

Freed, N. e Borenstein, N. (1996). RFC2046: Multipurpose Internet Mail Extensions(MIME) Part Two: Media Types. RFC Editor United States.

Freeman, S. e Pryce, N. (2006). Evolving an embedded domain-specific languagein java. In OOPSLA ’06: Companion to the 21st ACM SIGPLAN symposium onObject-oriented programming systems, languages, and applications, pp. 855–865,New York, NY, USA. ACM.

Gamma, E., Helm, R., Johnson, R., e Vlissides, J. (1995). Design patterns: elementsof reusable object-oriented software. Addison-Wesley Professional.

Greenfield, J. e Short, K. (2003). Software factories: assembling applications withpatterns, models, frameworks and tools. In OOPSLA ’03: Companion of the 18thannual ACM SIGPLAN conference on Object-oriented programming, systems, lan-guages, and applications, pp. 16–27, New York, NY, USA. ACM.

Groenewegen, D. M., Hemel, Z., Kats, L. C., e Visser, E. (2008). Webdsl: a domain-specific language for dynamic web applications. In OOPSLA Companion ’08: Com-panion to the 23rd ACM SIGPLAN conference on Object-oriented programming sys-tems languages and applications, pp. 779–780, New York, NY, USA. ACM.

Hudak, P. (1996). Building domain-specific embedded languages. ACM Comput. Surv.

93

196, p.

Ivkovic, I. e Kontogiannis, K. (2004). Model synchronization as a problem of maxi-mizing model dependencies. In OOPSLA ’04: Companion to the 19th annual ACMSIGPLAN conference on Object-oriented programming systems, languages, and ap-plications, pp. 222–223, New York, NY, USA. ACM.

Johnson, R. E. (1997). How frameworks compare to other object-oriented reuse tech-niques. frameworks = (components + patterns. In in ’Communications of the ACM,pp. 39–42.

Jones, C. (1996). Spr programming languages table release 8.2.http://www.theadvisors.com/langcomparison.htm.

Kelly, S. e Tolvanen, J.-P. (2008). Domain-Specific Modeling: Enabling Full Code Ge-neration. Wiley-IEEE Computer Society Pr.

Kiczales, G. e Rivieres, J. D. (1991). The Art of the Metaobject Protocol. MIT Press,Cambridge, MA, USA.

Kilmer, R. (2008). Ruby and the art of domain specific languages.http://www.infoq.com/presentations/kilmer-ruby-dsls.

Knuth, D. E. (1984). Literate programming. 27(2):97–111.

Krueger, C. W. (1992). Software reuse. ACM Comput. Surv., 24(2):131–183.

Laird, P. e Barrett, S. (2009). Towards context sensitive domain specific languages. InCAMS ’09: Proceedings of the 1st International Workshop on Context-Aware Mid-dleware and Services, pp. 31–36, New York, NY, USA. ACM.

Lima, V. A. (2001). Mídia: Teoria e Política. Number 8586469602. Fundação PerseuAbramo.

Martin, J. (1985). Fourth-generation languages. Volume I: principles. Prentice-Hall,Inc., Upper Saddle River, NJ, USA.

Mernik, M., Heering, J., e Sloane, A. M. (2005). When and how to develop domain-specific languages. ACM Comput. Surv., 37(4):316–344.

Microsoft (2009). code name for microsoft’s next generation application developmentplatform. http://msdn.microsoft.com/en-us/oslo/default.aspx.

Miyamaru, F., Leite, L., Bertuzzi, A., e Filgueiras, L. (2008a). Mídia cruzada em servi-ços de governo: conceito e aplicaç ao. In IHC ’08: Proceedings of the VIII Brazilian

94

Symposium on Human Factors in Computing Systems, pp. 330–331, Porto Alegre,Brazil, Brazil. Sociedade Brasileira de Computaç ao.

Miyamaru, F., Leite, L., Bertuzzi, A., e Filgueiras, L. (2008b). Task patterns for e-government services. In IHC ’08: Proceedings of the VIII Brazilian Symposium onHuman Factors in Computing Systems, pp. 276–279, Porto Alegre, Brazil, Brazil.Sociedade Brasileira de Computaç ao.

Nardi, B. A. (1993). A small matter of programming: perspectives on end user compu-ting. MIT Press, Cambridge, MA, USA.

Netbeans (2009). Generic languages framework. http://languages.netbeans.org/.

Neto, J. J., Ramos, M. V. M., e Ítalo Santiago Veja (2009). Linguagens Formais: Teoria,Modelagem e Implementação. bookman, 1 edition.

OpenArchitectureWare (2009). Xtext. http://wiki.eclipse.org/Xtext.

Parr, T. (2007). The Complete Antlr Reference Guide. Pragmatic Bookshelf.

Sammet, J. E. (1969). Programming Languages: History and Fundamentals. Prentice-Hall, Inc., Upper Saddle River, NJ, USA.

Schmidt, D. C. (2006). Guest editor’s introduction: Model-driven engineering. Compu-ter, 39(2):25–31.

Sharp, H., Rogers, Y., e Preece, J. (2007). Interaction Design: Beyond Human-Computer Interaction. John Wiley & Sons Ltd, 2 edition.

Steele, Jr., G. L. (1998). Growing a language. In OOPSLA ’98 Addendum: Adden-dum to the 1998 proceedings of the conference on Object-oriented programming,systems, languages, and applications (Addendum), New York, NY, USA. ACM.

Subramaniam, V. (2008). Programming Groovy: Dynamic Productivity for the JavaDeveloper. Pragmatic Bookshelf.

van Deursen, A., Klint, P., e Visser, J. (2000). Domain-specific languages: an annotatedbibliography. SIGPLAN Not., 35(6):26–36.

Wexelblat, R. L. (1981). History of Programming Languages. Academic Press, Inc.,Orlando, FL.

Wiberg, C., Bodén, J., e Jegers, K. (2007). Cross-Media interaction design. In HCI andNew Media Arts: Methodology andEvaluation, San Jose, CA, USA.

95

Wile, D. S. (2001). Supporting the dsl spectrum. J. Comput. Inform.

96

Apêndice A Exemplos de DSLs

Apêndice A.1 jMock

Exemplo sem pontuação e parênteses da sintaxe java:

1 mainframe expects once method ‘‘buy’’

2 with eq QUANTITY will return value TICKET

De volta com a notação da linguagem Java:

1 Mock mainframe = mock(Mainframe.class);

2 Mock auditing = mock(Auditing.class);

3 Agent agent = new Agent( QUANTITY, (Mainframe)mainframe.proxy(), (Auditing)auditing.proxy() );

4 public void testBuysWhenPriceEqualsThreshold() {

5 mainframe.expects(once())

6 .method(‘‘buy’’).with(eq(QUANTITY))

7 .will(returnValue(TICKET));

8 ,auditing.expects(once())

9 .method(‘‘bought’’).with(same(TICKET));

10 ,agent.onPriceChange(THRESHOLD);

11 }

12

13 public void testDoesNotBuyIfMainframeUnavailable() {

14 mainframe.stubs().method(‘‘buy’’)

15 .will(throwException(new NotAvailableException());

16 auditing.expects(never()).method(‘‘bought’’);

17 agent.onPriceChange(THRESHOLD);

18 }

Apêndice A.2 API Fluente

Implementação de uma API usada de forma imperativa:

1 Processor p = new Processor(2, Processor.Type.i386);

2 Disk d1 = new Disk(150, Disk.UNKNOWN_SIZE, null);

3 Disk d2 = new Disk(75, 7200, Disk.Interface.SATA);

4 return new Computer(p, d1, d2);

Usando encadeamento de métodos:

1 computer()

2 .processor()

97

3 .cores(2)

4 .i386()

5 .disk()

6 .size(150)

7 .disk()

8 .size(75)

9 .speed(7200)

10 .sata()

11 .end();

Sequenciamento de funções:

1 computer();

2 processor();

3 cores(2);

4 processorType(i386);

5 disk();

6 diskSize(150);

7 disk();

8 diskSize(75);

9 diskSpeed(7200);

10 diskInterface(SATA);

Funções aninhadas:

1 computer(

2 processor(

3 cores(2),

4 Processor.Type.i386

5 ),

6 disk(

7 size(150)

8 ),

9 disk(

10 size(75),

11 speed(7200),

12 Disk.Interface.SATA

13 )

14 );

98

Apêndice B Framework X-Gov

Apêndice B.1 Diagrama de Classes do FrameworkLibrary

99

Figu

raB

.1:

Exe

mpl

ode

clas

ses

deco

mpo

nent

es

100

Figura B.2: Componentes FindEntityInfo para TV, Mobile e Web

101

Figura B.3: Componente GetPreServiceInfo para TV, Mobile e Web

Figura B.4: Classes de Transição

102

Apêndice C Implementação da CroMeL

Apêndice C.1 Regras Léxicas e Sintáticas da CroMeL

1 grammar CroMeL;

23 /************************************************

4 * PARSER RULES *

5 ************************************************/


89 service : ’service ’ service_name? ’{’ decl ’}’ ;

1011 decl : task+

12 transition*

13 web_navigation*

14 ;

1516 task : ’task ’ task_name ’of’ pattern_name ’{’ media+ ’}’ ;

1718 media : MEDIA params ;

1920 transition : ’transition ’ transition_type navigation params ;

2122 web_navigation : ’navigation ’ label navigation;

2324 navigation : ’[’ begin ’->’ end ’]’ ;

2526 params : ’(’ assign ’)’ ;

2728 assign : ID ’=’ expr (’,’ ID ’=’ expr)* ;

2930 var : assign ;

3132 begin : REF;

3334 end : REF;

3536 expr : STRING

103

37 | INT

38 | BOOLEAN



41 ;

4243 // parametro opcional n~ao utilizado

44 service_name : STRING ;

4546 // pode restringir aos nomes de padr~oes de tarefas conhecidos


4849 // pode restringir aos tipos de transic~oes conhecidos


5152 // label da navegacao

53 label : STRING ;

5455 // nome do servico serve como chave para navegac~ao/transic~ao

56 task_name : ID ;

5758 /************************************************

59 * LEXER RULES

*

60 ************************************************/



6465 INT : ’0’..’9’+ ;

6667 ID : (’a’..’z’|’A’..’Z’|’_’) (’a’..’z’|’A’..’Z’|’0’..’9’|’_’)* ;

6869 // uma referencia de uma variavel (usada para recuperar seu valor)

70 QID : ’$’ID ;

7172 // uma referencia do tipo Task.media (usado para identificar componentes

)

73 REF : ’\&’ ID (’.’ MEDIA);

7475 STRING : ’"’ .* ’"’ | ’\’’ ~(’\\’|’\’’|’\*’)* ’\’’ ;

7677 // espacos em branco


7980 // comentarios

104



Listagem C.1: Gramatica

Apêndice C.2 Regras Semânticas da CroMeL

1 grammar CroMeL;

23 @header {

4 import java.util.Map;

5 import java.util.HashMap;

6 import java.util.List;

7 import java.util.ArrayList;

8 import java.util.regex.Matcher;

9 import java.util.regex.Pattern;

10 }

1112 @members {

13 // Classe que armazena os dados de um componente

14 class ComponentDTO {

15 public String type;

16 public Map parameters;

17 }

18 class TransitionDTO {

19 public String type;

20 public Map parameters;

21 public Integer begin , end;

22 }

23 class NavigationDTO {

24 public String label;

25 public Integer begin , end;

26 }

27 class CodeDTO {

28 public CodeDTO(String comment , String code) {

29 this.comment = comment;

30 this.code = code;

31 }

32 public String comment;

33 public String code;

34 }

3536 // lista de componentes ,transicoes e navegacoes declaradas

37 List <ComponentDTO > components = new ArrayList <ComponentDTO >();

38 List <TransitionDTO > transitions = new ArrayList <TransitionDTO >();

39 List <NavigationDTO > navigations = new ArrayList <NavigationDTO >();

105

4041 // memoria para as variaveis locais

42 Map memory = new HashMap ();

4344 // lista com todos identificadores de componentes

45 Map componentIds = new HashMap ();

4647 // metodo para buscar o id de um componente (usado na definicao de

parametros e navegacao)

48 public Integer getComponentId(String componentName) {

49 // busca valor na memoria (eliminando o & que nao foi colocado

na tabela)

50 Object v = componentIds.get(componentName.substring (1));

51 // se encontrado seta o valor de retorno , caso contrario imprime

erro

52 if ( v!=null ) {

53 System.out.println("- resoluc~ao da referencia id = "+v);

54 return new Integer(v.toString ());

55 }

56 else {

57 System.err.println ("Erro: referencia indefinida "+

componentName);

58 return null;

59 }

60 }

61 }

6263 /************************************************

64 * PARSER RULES *

65 ************************************************/


686970 // declarac~ao de variaveis para usar como valor nas propriedades

71 var : assign

72 {

73 System.out.println("- declarac~ao da variavel: "+ $assign.

n+"="+ $assign.v);

74 memory.put($assign.n, $assign.v);

75 };

7677 service

78 scope {

79 // contador usado para atribuir um ID para cada

componente em um servico

80 int componentId;

106

81 }

82 @after {

83 System.out.println (" Execuc~ao apos processamento da

entrada !");

8485 // Cria os componentes da CroMeL e seta seus parametros

por reflexao

86 for(ComponentDTO component : components) {

87 System.out.println (" Criando componente "+

component.type);

88 System.out.println ("\ tarmazenamento de "+

component.parameters.size()+" parametros ");

89 }

9091 // Cria os objetos de transicao e seta seus parametros

por reflexao

92 for(TransitionDTO transition : transitions) {

93 System.out.println (" Criando transic~ao "+

transition.type);

94 System.out.println ("\ tarmazenamento de "+

transition.parameters.size()+" parametros ");

95 System.out.println ("\ ttransic~ao entre os

componentes "+ transition.begin+" e "+

transition.end);

96 }

9798 // Cria os objetos de navegacao

99 for(NavigationDTO navigation : navigations) {

100 System.out.println (" Criando navegac~ao "+

navigation.label);

101 System.out.println ("\ tnavegac~ao entre os

componentes "+ navigation.begin+" e "+

navigation.end);

102 }

103 }

104 : { $service :: componentId =1; } // inicializacao do contador

105 ’service ’ service_name? ’{’ decl ’}’ ;

106107 decl : task+

108 transition*

109 web_navigation*

110 ;

111112 // criar objetos para cada midia e setar os parametros (chamada da API

de reflexao)

113 task

107

114 : ’task ’ task_name { System.out.println (" Declarac~ao da atividade

:"+ $task_name.text); }

115 ’of’ pattern_name ’{’ media[$task_name.text , $pattern_name.

text]+

116 (lc=literate_code

117 {

118 // Executa as regras definidas em um servico

119 System.out.println (" Executa codigo embutido: "+

$lc.comment);

120 System.out.println ("\t"+$lc.code);

121 }

122 )* ’}’ ;

123124 // retornar o componente com os parametros para a task

125 media [String taskName , String patternName]

126 : m=MEDIA params

127 {

128 // atribui um id (setar na propriedade da superclasse) e

guarda para referencia

129 int componentId = $service :: componentId ++;

130 String media = $m.text;

131 String componentName = $taskName +"."+ media;

132 componentIds.put(componentName , componentId);

133134 // define o tipo do componente

135 String componentType = $patternName +"."+ media;

136 System.out.println ("Novo componente do tipo "+

componentType +" [id="+ componentId +"]");

137138 // parametros do componente

139 System.out.println ("\ tparametros ="+ $params.p);

140141 // guarda o componente na lista

142 // TODO: incluir ID na lista de parametros

143 ComponentDTO dto = new ComponentDTO ();

144 dto.type = componentType;


146 components.add(dto);

147 };

148149 // criar objeto de transicao e setar os parametros

150 transition

151 : ’transition ’ transition_type

152 navigation

153 params

154 {

108

155 System.out.println ("Nova transic~ao do tipo "+

$transition_type.text);

156 System.out.println ("\ tparametros ="+ $params.p);

157 TransitionDTO dto = new TransitionDTO ();

158 dto.type = $transition_type.text;




162 transitions.add(dto);

163 };

164165 // criar objeto de navegacao web e seta o label

166 web_navigation

167 : ’navigation ’ label

168 navigation

169 {

170 NavigationDTO dto = new NavigationDTO ();

171 dto.label = $label.text;



174 navigations.add(dto);

175 };

176177 // recupera o ID do begin e do end

178 navigation returns[int b, int e]

179 : ’[’ begin ’->’ end ’]’

180 {

181 $b = $begin.id;

182 $e = $end.id;

183 System.out.println (" Navegac~ao do componente ["+ $begin.id

+"] -> ["+ $end.id+"]");

184 };

185186 // guardar os parametros em um HashMap(nome , valor) passado pela regra

187 params returns[Map p]

188 @init {

189 p = new HashMap ();

190 }

191 : ’(’ a1=assign { p.put($a1.n, $a1.v); }

192 (’,’ a2=assign { p.put($a2.n, $a2.v); } )*

193 ’)’;

194195196 // retorna um par nome -valor

197 assign returns[String n, Object v]

198 : ID ’=’ expr

199 {

109

200 $n = $ID.text;

201 $v = $expr.value;

202 };

203204 begin returns[Integer id]


206207 end returns[Integer id]


209210 // regra que determina o tipo de dado por inferencia

211 expr returns[Object value]

212 : STRING { $value = $STRING.text; }

213 | INT { $value = Integer.parseInt($INT.text); }

214 | BOOLEAN { $value = Boolean.parseBoolean($BOOLEAN.text); }


217 {

218 // busca valor na memoria (eliminando o $ que nao foi

colocado na tabela)

219 Object v = memory.get($QID.text.substring (1));

220 // se encontrado seta o valor de retorno , caso contrario

imprime erro

221 if ( v!=null ) {

222 $value = v;

223 System.out.println("- resoluc~ao da variavel "+

$QID.text +"="+v);

224 }

225 else System.err.println ("Erro: variavel indefinida "+

$QID.text);

226 }


230 {

231 $value = getComponentId($REF.text);

232 }

233 ;

234235 // parametro opcional nao utilizado

236 service_name : STRING ;

237238 // pode restringir aos nomes de padr~oes de tarefas conhecidos


240241 // pode restringir aos tipos de transicoes conhecidos


110

243244 // label da navegacao

245 label : STRING ;

246247 // nome do servico serve como chave para navegacao/transicao

248 task_name : ID ;

249250 literate_code returns[String comment , String code]

251 : CODE

252 {

253 String pattern = "<<(\\w+) >>=(.*)@";

254255 Pattern p = Pattern.compile(pattern , Pattern.

MULTILINE);

256 Matcher m = p.matcher($CODE.text);

257 if(m.find()) {

258 $comment = m.group (1);

259 $code = m.group (2);

260 System.out.println($comment);

261 System.out.println($code);

262 } else {

263 System.out.println ("Erro: codigo

invalido ");

264 }

265 };

266267268 /************************************************

269 * LEXER RULES *

270 ************************************************/

271272 CODE : ’<<’ .* ’@’;



277278 INT : ’0’..’9’+ ;

279280 ID : (’a’..’z’|’A’..’Z’|’_’) (’a’..’z’|’A’..’Z’|’0’..’9’|’_’)* ;

281282 // uma referencia de uma variavel (usada para recuperar seu valor)

283 QID : ’$’ID ;

284285 // uma referencia do tipo Task.media (usado para identificar componentes

)

286 REF : ’\&’ ID (’.’ MEDIA);

111

287288 STRING : ’"’ .* ’"’ | ’\’’ ~(’\\’|’\’’|’\*’)* ’\’’ ;

289290 // NEWLINE : ’\r’? ’\n’ ;

291292 // espaco em branco


294295 // comentarios



Listagem C.2: Semantica

Apêndice C.3 Diagramas de Sintaxe da Linguagem CroMeL

Figura C.1: Diagrama de sintaxe da raiz da gramática

Figura C.2: Diagrama da sintaxe de declaração de um serviço

Figura C.3: Diagrama da sintaxe dos elementos que pertencem a um serviço

Figura C.4: Diagrama da sintaxe de uma atividade

Figura C.5: Diagrama da sintaxe de declaração de parametros

112

Figura C.6: Diagrama de sintaxe de transições

Figura C.7: Diagrama de sintaxe de navegação

113

Apêndice C.4 Autômato Finito Determinístico da Linguagem CroMeL

Figura C.8: DFA reconhecedor dos Tokens da linguagem CroMeL

114

Apêndice C.5 ANTLRWorks

Figura C.9: Ferramenta ANTLRWorks no desenvolvimento da CroMeL

Apêndice C.6 CroMeL XML

1 <?xml version ="1.0" encoding ="utf -8"?>

2 <service >

3 

4 <task taskId ="1" pattern =" GetPreServiceInfo">

5 <name >Basic Information about exams schedule.</name >

6 <executedBy >Citizen </executedBy >

7 <web >

8 <componentId >11</ componentId >

9 <componentName >Basic Information </ componentName >

10 <description >For more information about the medical examination

service use the menu on the side </ description >

11 <uriCalled >webExameInfo </uriCalled >

12 </web >

13 <mobile >


15 <componentName >Informations </ componentName >

16 <uriCalled >mobExamInfo </uriCalled >

17 <welcomeMessage >Welcome to the X-Media Service </ welcomeMessage >

18 </mobile >

19 <tv >

115


21 <componentName >Basic Information about exams schedule.</

componentName >

22 <uriCalled >tvExamInfo </uriCalled >

23 <first >true </first >

24 </tv>

25 </task >

26 

27 <task taskId ="2" pattern =" FindPrivateInfo">

28 <name >Exams List </name >

29 <executedBy >Citizen </executedBy >

30 <web >


32 <componentName >My Exams List </ componentName >

33 <authenticationCompId >71</ authenticationCompId >

34 <uriCalled >webExamList </uriCalled >

35 <dataUrl >http ://143.107.102.15/ govside/GWSFindPrivateInformation/

GWSFindPrivateInfo.asmx </dataUrl >

36 <getFullEntitiesListWebMethod >GWSGetPermittedExams </

getFullEntitiesListWebMethod >

37 <getEntityInformationWebMethod >GWSGetExamInformation </

getEntityInformationWebMethod >

38 <scheduleCompId >31</ scheduleCompId >

39 </web >

40 <mobile type=" SearchByOptionList">



43 <authenticationCompId >72</ authenticationCompId >

44 <uriCalled >mobExamList </uriCalled >

45 <instructionText >Select an exam:</instructionText >

46 <listName >Exams Requested </listName >







50 </mobile >

51 <tv >



54 <entityType >Exam </entityType >

55 <compAuthId >73</ compAuthId >

56 <uriCalled >tvExamList </uriCalled >



116





60 </tv>

61 </task >

62 <transition class=" BarCode">

63 <BarCodeType >QRCode </ BarCodeType >

64 <OriginComponentId >13</ OriginComponentId >

65 <DestinationComponentId >22</ DestinationComponentId >

66 <BaseUrl >http ://143.107.102.15/ poc3xgov/Mobile_Comp/mobile/

mobFindPrivExam </BaseUrl >

67 <ErrorCorrection >M</ ErrorCorrection >

68 <ImageSize >5</ImageSize >

69 <LabelMessage >Use this QRCode to access next service step.</

LabelMessage >

70 <TransitionId >7</ TransitionId >

71 <TransitionName >QRCODE teste web ->mob </ TransitionName >

72 </transition >

73 <navigation >

74 <originComponent >11</ originComponent >

75 <endComponent >21</ endComponent >

76 <label >See your exam list </label >

77 </navigation >

78 <navigation >

79 <originComponent >21</ originComponent >

80 <endComponent >31</ endComponent >

81 <label >Schedule an exam </label >

82 </navigation >

83 </service >

Listagem C.3: XML

Apêndice C.7 CromelService para Interpretador na versão C#

1 using System;

2 using System.Collections.Generic;

3 using System.Linq;

4 using System.Text;

5 using System.Xml.Linq;

6 using System.IO;

7 using log4net;

8 using FrameworkLibrary;

9 using System.Xml;

10 using System.Net;

11 using System.Configuration;

117

12 using XTransitionLibrary;

13 using Newtonsoft.Json;

14 using System.Reflection;

15 using System.Web.Hosting;

1617 namespace XWSComponentManager

18 {

19 public class CromelService

20 {

21 private static readonly ILog log = LogManager.GetLogger(typeof(

CromelService));

2223 public static void RunCromelScript(string scriptComment , string

scriptCode)

24 {

25 var runtime = IronRuby.Ruby.CreateRuntime ();

26 var engine = runtime.GetEngine ("rb");

2728 // Run embedded code in CroMeL script

29 var result = engine.Execute(cromelScript);

3031 log.Info(String.Format (" Running {0} with result: {1}.",

scriptComment , result));

3233 return result.ToString ();

34 }

3536 public static void CreateNavigations(List <NavigationDTO >

navigations) {

37 log.Info(String.Format ("{0} navigations found.", navigations

.Count()));

3839 // component list to add in the configuration manager

40 List <ComponentConnection > list = new List <

ComponentConnection >();

4142 // this constructor because mappings of the classes and

properties are known for ComponentConnection

43 ComponentFactory cf = new ComponentFactory ();

4445 foreach(NavigationDTO nav in navigations) {

46 ComponentConnection cc = (ComponentConnection)cf.

createObject (" FrameworkLibrary", "ComponentConnection

");

47 cf.setProperty(cc, "originComponent", nav.Begin);

48 cf.setProperty(cc, "endComponent", nav.End);

49 cf.setProperty(cc, "label", nav.Label);

118

50 }

5152 int i = 0;

53 foreach (ComponentConnection cc in list)

54 {

55 // Verify if connected components exist

56 if (Global.ComponentList.Exists(c => c.ComponentId == cc

.OriginComponentId))

57 {

58 if (Global.ComponentList.Exists(c => c.ComponentId

== cc.ComponentConnectedId))

59 {

60 if (Global.ComponentList.Single(c => c.

ComponentId == cc.OriginComponentId).Medium

61 == Global.ComponentList.Single(c => c.

ComponentId == cc.ComponentConnectedId).

Medium)

62 {

63 // Insert connection to component.

64 Global.ComponentList.Single(c => c.

ComponentId == cc.OriginComponentId).

InsertComponentConnection(cc);

65 i++;

66 }

67 else

68 {

69 log.Error(" Components " + cc.

OriginComponentId.ToString () + " and " +

cc.ComponentConnectedId.ToString () + " are

not from the same medium !");

70 }

71 }

72 else

73 {

74 log.Error("There is no component with id: " + cc

.ComponentConnectedId.ToString () + " to end a

connection .");

75 }

76 }

77 else

78 {

79 log.Error("There is no component with id: " + cc.

OriginComponentId.ToString () + " to start a

connection .");

80 }

81 }

82 log.Info(i.ToString () + " connections created .");

119

8384 }

8586 public static void CreateComponents(List <ComponentDTO >

components) {

87 log.Info(String.Format ("{0} components found.", components.

Count()));

8889 // component list to add in the configuration manager

90 List <Component > componentsCreated = new List <Component >();

9192 Dictionary <String , String > mappingClasses =

loadMappingClasses (" classNames.mapping ");

93 Dictionary <String , String > mappingProperties =

loadMappingProperties (" propertyNames.mapping ");

9495 // mapping null because the names of the classes are known

96 ComponentFactory cf = new ComponentFactory(mappingClasses ,

mappingProperties);

9798 foreach(ComponentDTO component in components) {

99100 String type = component.Type;

101 Hashtable params = component.parameters;

102103 // create a new component and add to the list

104 Component component = (Component)cf.createComponent(type

);

105 if (component != null) {

106 componentsCreated.Add(component);

107 foreach (DictionaryEntry de in parameters)

108 {

109 cf.setProperty(component , de.Key(), de.Value());

110 }

111 } else {

112 log.Warn(" Component not found , please verify the

component mapping .");

113 }

114 log.Info(String.Format ("{0} components created.",

componentsCreated.Count()));

115116 // Atualiza o Global Component List (TODO: poderia

utilizar o AddRange(componentsCreated) mas necessita

testar primeiro)

117 foreach (var comp in componentsCreated)

118 {

119 Global.ComponentList.Add(comp);

120

120 }

121 }

122123 }

124125 public static void CreateTransitions(List <TransitionDTO >

transitions) {

126 log.Info(String.Format ("{0} transitions found.", transitions

.Count()));

127128 TransitionFactory tf = new TransitionFactory ();

129 tf.LoadTransitionAssembly ();

130131 foreach (TransitionDTO transitionElement in transitions)

132 {

133 String transitionClass = transitionElement.Type;

134 Hashtable parameters = transitionElement.parameters;

135136 log.Info("New transition element found: " +

transitionClass);

137138 Object transitionObject = null;

139 try

140 {

141 transitionObject = tf.CreateTransitionObject(

transitionClass);

142 }

143 catch (Exception)

144 {

145 log.Error("Could not instantiate class: " +

transitionClass + ".");

146 log.Info(" Skipping this transition element ..");

147 continue;

148 }

149150 log.Debug(" Configuring transition parameters: " +

transitionClass);

151 foreach (DictionaryEntry de in parameters)

152 {

153 try {

154 cf.setProperty(transitionObject , de.Key(), de.

Value());

155 } catch (Exception e) {

156 log.Error(e);

157 log.Info(" Skipping this transition property ..");

158 continue;

159 }

121

160 }

161162 Int32 originTaskId = 0;

163 Int32 destinationTaskId = 0;

164 Int32 transitionId = 0;

165 try {

166 originTaskId = transitionElment.Begin;

167 destinationTaskId = transitionElement.End;

168169 if (tf.TransitionExists(originTaskId ,

destinationTaskId , transitionClass)) {

170 try {

171 tf.SetTransitionObjectProperty(

transitionObject , "TransitionId", tf.

GetTransitionId(originTaskId ,

destinationTaskId , transitionClass).

ToString ());

172 tf.EditExistingTransition(transitionObject ,

transitionClass);

173 transitionId = tf.GetTransitionId(

originTaskId , destinationTaskId ,

transitionClass);

174 log.Info(" Existent transition id was caught

.");


176 log.Error("Error while editing existent

transition .", e);

177 log.Error(" Skipping this transition element

..");

178 continue;

179 }

180 } else {

181 try {

182 transitionId = tf.

CreateNewTransitionThroughWebService(

transitionObject , transitionClass ,

originTaskId , destinationTaskId);

183 log.Info("New transition id was received .");


185 log.Error("Error while creating new

transition: " + transitionClass , e);

186 log.Error(" Skipping this transition element

..");

187 continue;

188 }

189 }


122

191 log.Error("Could not verify if the transition

already exists.", e);

192 log.Error(" Skipping this transition element ..");

193 continue;

194 }

195 // Edit object with new transition id

196 try {

197 tf.SetTransitionObjectProperty(transitionObject , "

TransitionId", transitionId.ToString ());

198 log.Debug(" TransitionId property was sucessfully

setted. (" + transitionId.ToString () + ").");


200 log.Error("Could not set value: " + transitionId + "

to TransitionId property.", e);

201 log.Error(" Skipping this transition element ..");

202 continue;

203 }

204 // Sending object to memory

205 try {

206 tf.SaveComponentInMemory(transitionClass ,

transitionId , originTaskId);

207 log.Debug(" Transition successfully added to

component .");


209 log.Error("Error when adding transition to component

.", e);

210 continue;

211 }

212 }

213 }

214 ....

215 }

Listagem C.4: Cromel Service

Apêndice C.8 ComponentFactory para Interpretador na versão C#

1 using System;

2 using System.Collections.Generic;

3 using System.Linq;

4 using System.Text;

5 using System.Reflection;

6 using FrameworkLibrary;

7 using log4net;

8 using System.Web.Hosting;

9

123

10 namespace XWSComponentManager

11 {

12 /// <summary >

13 /// This class uses reflection to instantiate dynamically the

components from FrameworkLibrary

14 /// </summary >

15 class ComponentFactory

16 {

17 private static readonly ILog log = LogManager.GetLogger(typeof(

ComponentFactory));

18 private Assembly assembly;

19 private Dictionary <String , String > mappingClasses;

20 private Dictionary <String , String > mappingProperties;

2122 /// <summary >

23 /// Used to create a ComponentFactory for FrameworkLibrary

assembly without a dictionary to bind the properties

24 /// </summary >

25 public ComponentFactory () : this(" FrameworkLibrary.dll") {}

2627 /// <summary >

28 /// Create a ComponentFactory for FrameworkLibrary with a

dictionary used to bind the properties to names

29 /// </summary >

30 /// <param name=" mappingClasses">Dictionary to lookup the name

of the classes </param >

31 /// <param name=" mappingProperties">Dictionary to lookup the

name of the properties </param >

32 public ComponentFactory(Dictionary <String , String >

mappingClasses , Dictionary <String , String > mappingProperties)

: this(" FrameworkLibrary.dll")

33 {

34 this.mappingProperties = mappingProperties;

35 this.mappingClasses = mappingClasses;

36 }

3738 /// <summary >

39 /// Used to create a ComponentFactory for an assembly without a

dictionary to bind the properties

40 /// </summary >

41 /// <param name=" assembly">The name of the assembly (e.g.

FrameworkLibrary.dll)</param >

42 public ComponentFactory(String assembly)

43 {

44 try

45 {

124

46 String assemblyWithPath = HostingEnvironment.

ApplicationPhysicalPath + @"bin\"+ assembly;

47 log.Debug(" FrameworkLibrary path: " + assemblyWithPath);

48 this.assembly = Assembly.LoadFrom(assemblyWithPath);

49 //this.assembly = AppDomain.CurrentDomain.Load(assembly)

;

50 }

51 catch (Exception e)

52 {

53 log.Error("Could not load assembly (dll or exe), verify

path: " + assembly , e);

54 }

55 }

5657 /// <summary >

58 /// Creates a new object from a namespace of the assembly

59 /// </summary >

60 /// <param name=" namespaceName">Name of the namespace or

namespace.subnamespace </param >

61 /// <param name=" className">Name of the class that belongs to

the namespace </param >

62 /// <returns ></returns >

63 public Object createObject(String namespaceName , String

className)

64 {

65 // Create component by parametrized constructor

66 // MyClass myObj = (MyClass)myAssembly.CreateInstance ("

ReflectionTestAssembly.MyClass",

67 // false , BindingFlags.Default , null ,

68 // new object [] { 5 }, null , null);

69 Object newObject = null;

7071 // Lookup in the dictionary for class names

72 if (( mappingClasses != null) && mappingClasses.ContainsKey(

className))

73 {

74 className = mappingClasses[className ];

75 }

7677 try

78 {

79 newObject = (Object)assembly.CreateInstance(

namespaceName + "." + className);

80 if (newObject == null) throw new

ComponentFactoryException (" Creating class "+ className)

;

81 }

125


83 {

84 log.Warn("Can ’t instantiate the component: " + className

, e);

85 }

86 return newObject;

87 }

8889 /// <summary >

90 /// Creates a new object from FrameworkLibrary namespace

91 /// </summary >

92 /// <param name=" objectName">Name of the class </param >

93 /// <returns >New Object instance </returns >

94 public Object createObject(String objectName)

95 {

96 return this.createObject (" FrameworkLibrary", objectName);

97 }

9899 /// <summary >

100 /// Creates a new component from FrameworkLibrary namespace

101 /// </summary >

102 /// <param name=" componentName">Name of the class </param >

103 /// <returns >New Component instance </returns >

104 public Component createComponent(String componentName)

105 {

106 return (Component) this.createObject (" FrameworkLibrary",

componentName);

107 }

108109 /// <summary >

110 /// Set the property of a object. If you have a ComponentFactory

created with a dictionary

111 /// it will try to avoid the MissingMethodException using the

key of the dictionary for lookup

112 /// </summary >

113 /// <param name=" target">The object that will be set a property

value </param >

114 /// <param name=" property">The name of the property </param >

115 /// <param name="value">The value of the property (any datatype

as Object)</param >

116 public void setProperty(Object target , String property , Object

value)

117 {

118 try

119 {

120121 // Lookup in the dictionary for property names

126

122 if (( mappingProperties != null) && mappingProperties.

ContainsKey(property))

123 {

124 property = mappingProperties[property ];

125 }

126127 // transfor 1st char in upcase (convention in C#)

128 property = StringExtension.ToUpperFirstLetter (( String)

property);

129130 Type componentType = target.GetType ();

131132 // if int datatype is passed as string will have a

MethodMissingException because it should be converted

133 int iValue = 0;

134 bool bValue = false;

135 if (value is String && Int32.TryParse(value.ToString (),

out iValue))

136 {

137 // int value

138 componentType.InvokeMember(property , BindingFlags.

SetProperty , null , target , new object [] { iValue

});

139 }

140 else

141 {

142 // if bool datatype is passed as string , will have a

MethodMissingException because it should be

converted

143 if(value is String && Boolean.TryParse(value.

ToString (), out bValue))

144 {

145 //bool value

146 componentType.InvokeMember(property ,

BindingFlags.SetProperty , null , target , new

object [] { bValue });

147 }

148 else

149 {

150 // string or object value

151 componentType.InvokeMember(property ,

BindingFlags.SetProperty , null , target , new

object [] { value });

152 }

153 }

154 }


127

156 {

157 log.Warn(String.Format ("Can ’t setProperty: {0} = {1}

({2})", property , value , value.GetType ()), e);

158 }

159160 }

161162 /// <summary >

163 /// Call a method on the target object with parameters

164 /// </summary >

165 /// <param name=" target">The object to call the method </param >

166 /// <param name=" methodName">The name of the method </param >

167 /// <param name=" parameters">list of parameters </param >

168 public void callMethod(Object target , String methodName , Object

parameters)

169 {

170 try

171 {

172173 // Lookup in the dictionary for property names

174 if (( mappingProperties != null) && mappingProperties.

ContainsKey(methodName))

175 {

176 methodName = mappingProperties[methodName ];

177 }

178179 // transfor 1st char in upcase (convention in C#)

180 methodName = StringExtension.ToUpperFirstLetter (( String)

methodName);

181182 Type componentType = target.GetType ();

183184 // call the method

185 componentType.InvokeMember(methodName , BindingFlags.

InvokeMethod , null , target , new object [] {parameters}

);

186187 }


189 {

190 log.Warn(String.Format ("Can ’t call the method {0} with

parameter {1}", methodName , parameters), e);

191 }

192 }

193194 /// <summary >

128

195 /// Ainda nao foi usado para nada , mas serve para inspecionar um

assembly.

196 /// </summary >

197 /// <param name=" assembly">nome completo do assembly </param >

198 public static void printTypes(String assembly) {

199 if (assembly == null)

200 {

201 assembly = "FrameworkLibrary.dll";

202 }

203204 // Load an assembly from file

205 Assembly myAssembly = Assembly.LoadFrom(assembly);

206 // Get the types contained in the assembly and print their

names

207 Type[] types = myAssembly.GetTypes ();

208 foreach (Type type in types)

209 {

210 log.Debug(type.FullName);

211 }

212 }

213 }

214215 /// <summary >

216 /// Utiity class for string manipulation

217 /// </summary >

218 public static class StringExtension

219 {

220 // string extension method ToUpperFirstLetter

221 public static string ToUpperFirstLetter(this string source)

222 {

223 if (string.IsNullOrEmpty(source))

224 return string.Empty;

225 // convert to char array of the string

226 char[] letters = source.ToCharArray ();

227 // upper case the first char

228 letters [0] = char.ToUpper(letters [0]);

229 // return the array made of the new char array

230 return new string(letters);

231 }

232 }

233234 /// <summary >

235 /// Used to show that something is wrong in the factory

236 /// </summary >

237 class ComponentFactoryException : Exception

238 {

239 public ComponentFactoryException(String msg) : base(msg) { }

129

240 }

241 }

Listagem C.5: Component Factory

Este documento foi preparado com o formatador de textos LATEX .

Documents

Wladimir Braguini Domingues - IPTcassiopea.ipt.br/teses/2009_EC_Wladimir_Braguini.pdf · 2010-09-11 · Wladimir Braguini Domingues Linguagem Especíﬁca de Domínio para Governo