DSL Encoder: Uma ferramenta web para desenvolvimento

de linguagens especficas de domnio

Bruno F. Leo Maia1, Vinicius Cardoso Garcia1,2, Leandro M. Nascimento1,3
1

Centro de Estudos Avanados do Recife (C.E.S.A.R.)

Recife Pernambuco Brasil

Centro de Informtica (CIn) Universidade Federal de Pernambuco - UFPE

Recife Pernambuco Brasil

Departamento de Estatstica e Informtica (DEINFO) - Universidade Federal Rural de

Pernambuco - UFRPE
Recife Pernambuco Brasil
brunoleaomaia@gmail.com, [lmn2,vcg]@cin.ufpe.br

Resumo. Adotar uma abordagem DSL aumenta o nvel de abstrao para o

nvel do problema do domnio, melhorando a produtividade e habilitando o
reuso. O desenvolvimento e implementao de DSLs requer a utilizao de
ferramentas especializadas. Este artigo apresenta um IDE baseado na web,
para o desenvolvimento de linguagens especficas de domnio e apresenta um
estudo de caso da utilizao desta ferramenta com foco no reuso e gerao de
cdigo.
Abstract. Adopting a DSL approach raises the level of abstraction to the level
of problem domain, improving productivity and enabling reuse. The
development and implementation of DSLs requires the use of specialized tools.
This paper presents a web based IDE for developing domain-specific
languages and presents a case study of the use of this tool with a focus on
reuse and code generation.
Palavras-chave: web programvel, DSL, ferramenta, reuso, gerao de
cdigo.

1. Introduo
Um dos objetivos da Engenharia de Software aumentar a produtividade, seja pela
adoo de uma arquitetura que possibilite o reuso, seja pela utilizao de tcnicas que
permitam um especificao mais abstrata, sem detalhes de implementao, e que
possibilitem a gerao de cdigo consistente, de qualidade e que permita responder as
necessidades de mudana com facilidade [1][2]. O uso de linguagens especficas de
domnio, ou do ingls domain-specific language (DSL), tem possibilitado aumentar a
abstrao [3], criando solues voltadas para resolver problemas especficos do
domnio. Os geradores de aplicao, por exemplo, so uma categoria de suma
importncia para o reuso de software, e muitos deles utilizam DSLs como idioma de
entrada [4].

No entanto, o desenvolvimento de linguagens especficas de domnio requer o uso de

ferramentas especializadas, que geralmente possuem verses especficas para cada
sistema operacional, que muitas vezes dependem de outro software ou mquina virtual e
que precisam ser instaladas para que possam ser executadas, dificultando o uso em
ambientes de rede controlados, em que o usurio no possui autonomia para instalar
programas.
O advento da web 2.0 [5] revolucionou a forma como o software distribudo. Hoje
grandes aplicaes utilizam a web como plataforma. Novas tcnicas de programao
e a evoluo dos navegadores e do poder computacional dos dispositivos possibilitaram
que as aplicaes baseadas na web tivessem um comportamento semelhante ao das
aplicaes desktop [6]. Hoje, as aplicaes baseadas na web esto passando por uma
nova fase e a web agora vista como uma plataforma programvel [7]. Esta nova
abordagem tornou possvel utilizar recursos de outras aplicaes ao redor do mundo e
tornou as aplicaes baseadas na web ainda mais poderosas [8].
Este artigo apresenta uma ferramenta para o desenvolvimento de DSL, extensvel, com
foco na gerao de cdigo e no reuso de software, que utiliza a web como plataforma e
que pode ser integrada a outros servios da web, como uma alternativa de fcil acesso, e
que necessita apenas do navegador para ser executada. A Seo 2.1 apresenta os
conceitos de DSL, as motivaes para o seu uso, suas fases de desenvolvimento e a
necessidade da utilizao de ferramentas especializadas. A Seo 2.2 apresenta os
princpios da web 2.0 e apresenta uma nova fase que est surgindo, a web
programvel. A Seo 3 apresenta a proposta de construo da ferramenta, suas
premissas e como estas foram atendidas e a Seo 4 mostra como utilizar a ferramenta.
A Seo 5 apresenta um estudo de caso da utilizao da ferramenta e os ganhos de
produtividade obtidos. Na Seo 6 so apresentadas as concluses e os trabalhos futuros
relacionados.

2. Background
2.1. Domain-Specific Languages
Ao longo da histria de desenvolvimento de software, os engenheiros de software
procuraram melhorar a produtividade aumentando a abstrao [9]. Linguagem
especfica de domnio uma linguagem pequena, usualmente declarativa, que oferece
poder expressivo focado em um domnio de um problema particular [3]. Uma DSL
pode aumentar o nvel de abstrao muito alm das linguagens de programao atuais,
criando solues especficas baseadas no domnio do problema.
Linguagem especfica de domnio no um conceito novo e foi observado pela primeira
vez no final da dcada de 50 com a linguagem automatically programmed tools (APT),
que era uma DSL para programao de ferramentas controladas numericamente [10].
Atualmente, linguagens como SQL (utilizada em bancos de dados), HTML (utilizada
em pginas da web) e LaTeX (utilizada na produo de textos matemticos e
cientficos) so exemplos de DSL amplamente utilizadas.
Por outro lado, as linguagens de programao de propsito geral, do ingls generalpurpose programming languages (GPLs), combinadas com bibliotecas de aplicao,
podem ter um comportamento parecido com uma DSL, no entanto, ganhos notveis e
substanciais em expressividade e facilidades de uso so obtidos quando uma DSL
2

desenvolvida. O desenvolvimento de uma linguagem especfica melhora a

produtividade por oferecer notaes e construtores mais adequados e especficos para o
domnio do problema, tornando a construo e escrita mais leve e direta. Alm da
produtividade, as DSLs so importantes por possibilitar o reuso. Os geradores de
aplicao so uma categoria de suma importncia em reuso por utilizar DSL como
idioma de entrada, reutilizando a semntica do domnio [4].
No entanto, decidir por desenvolver uma nova DSL uma atividade complexa e deve
levar em considerao alguns fatores como reduzir custos futuros com desenvolvimento
de software e habilitar o desenvolvimento por usurios sem experincia em
programao mas com conhecimento sobre o domnio, ou o inverso, usurios com
experincia em programao e pouco conhecimento sobre o domnio [4].
Riscos e oportunidades devem ser avaliados antes de se decidir pela adoo do
desenvolvimento de uma nova DSL. Apesar dos custos de desenvolvimento,
manuteno e de aprendizado do usurio, adotar uma abordagem DSL propicia uma
srie de benefcios, uma vez que programas DSL so concisos e em sua maioria autodocumentados, escritos no idioma e no nvel de abstrao do domnio do problema. O
uso de DSLs aumenta a produtividade, a confiabilidade, a manutenabilidade, a
portabilidade e o reuso j que os programas de DSL podem ser validados e modificados
e at criados pelos prprios especialistas do domnio, com ou sem experincia em
programao [3].
De acordo com Mernik et al. [4] alguns padres do sustentabilidade s motivaes para
o desenvolvimento de DSL como notao (transformando visual para textual ou
adicionando notaes amigveis a APIs existentes), automao de tarefas, linhas de
produto, representao de estrutura de dados, intercmbio de estrutura de dados,
interao de sistemas front-end, construo de interfaces grficas do usurio e AVOPT
(Anlise, Verificao, Otimizao, Paralelizao e Transformao do domnio
especfico). Uma vez decidido por uma nova DSL, o processo de desenvolvimento
geralmente envolve as etapas de anlise, projeto e implementao.
Na etapa de anlise, o domnio do problema identificado, o conhecimento relevante do
domnio coletado e agrupado e o resultado um conjunto de noes semnticas e
operaes deste domnio. Na maioria das vezes, a anlise do domnio feita
informalmente, sobretudo, metodologias formais de anlise de domnio podem ser
utilizadas e o resultado dessa anlise formal so: um modelo de domnio (domainmodel), que formado por uma definio do escopo do domnio; uma terminologia do
domnio (vocabulrio, ontologia), descries dos conceitos do domnio; e modelos de
caractersticas (feature-models), que descreve os pontos comuns e variaes do domnio
e suas interdependncias [4].
Deursen et al. [3] destaca as seguintes metodologias de engenharia de domnio como as
mais conhecidas:

ODM Organization Domain Modeling

FODA Feature-Oriented Domain Analysis
DSSA Domain-Specific Software Architectures

Mernik et al. [4] identifica duas dimenses ortogonais nas abordagens de projetos de
DSL: Uma onde h uma relao com linguagens j existentes e outra onde uma nova
linguagem criada sem nenhuma relao com outra existente. Basear uma DSL em uma
3

linguagem existente pode acelerar o processo de desenvolvimento e torn-lo mais fcil e

trs padres so identificados por ele: o primeiro pegar carona nas caractersticas do
domnio especfico em uma linguagem existente (piggyback), o segundo estender uma
linguagem existente para atender as caractersticas do domnio (extension) e o terceiro
especializar uma linguagem existente para atender um problema especfico dentro do
domnio (specialization). No entanto a criao de novas linguagens sem relao com
outra existente um processo mais complexo, difcil de caracterizar, podendo ser
descrito de maneira informal, onde a especificao geralmente baseada em alguma
linguagem natural, ou formal, no qual a especificao utiliza um dos mtodos de
definies semnticas disponveis.
Fowler [12] afirma que no h uma forma ideal para projetar uma DSL, que o objetivo
geral de uma DSL, como com em qualquer escrita, a clareza para o leitor, e que a
linguagem dever ser de fcil utilizao tanto para programadores quanto para
especialistas do domnio.
Aps a etapa de projeto de uma DSL (executvel), necessrio definir uma abordagem
de implementao. Mernik et al. [4] e Deursen [3] destacam a abordagem de
interpretao ou compilao como clssica para a implementao de novos idiomas,
sendo amplamente utilizada na prtica. Embora a construo de um compilador ou
interpretador traga algumas vantagens, como total adaptao as notaes da DSL, o
custo da construo elevado, e geralmente so utilizadas ferramentas especialmente
projetadas para este propsito.
Caso a abordagem do projeto da DSL seja baseada em outra linguagem (piggyback,
extension ou specialization) a abordagem de implementao da linguagem base poder
ser reutilizada das seguintes formas:

Incorporao: onde uma DSL implementada ao estender uma GPL existente e

os mecanismos existentes, tais como definies de funes ou operadores com
sintaxe definida pelo usurio so utilizados para construir uma biblioteca de
operaes do domnio especfico[3].

Processamento e Macro-processamento:
onde novas construes so
traduzidas para declaraes na linguagem base por um pr-processamento[3].

Compilador ou Interpretador Extensvel: semelhante a abordagem anterior

porm a fase de processamento agora integrada no compilador [3] e traz
como vantagem a possibilidade de uma melhor otimizao e checagem de tipos.

Mernik et al. [4] afirma que o desenvolvimento de DSL difcil, exigindo tanto
conhecimento do domnio quanto experincia no desenvolvimento de linguagens e que
este processo pode ser facilitado com a adoo de ferramentas de desenvolvimento de
DSL. As ferramentas podem variar de um simples verificador de consistncia e
interpretador at um ambiente integrado de desenvolvimento, do ingls integrated
development environment (IDE), formado por um editor de texto syntax-directed
(dirigido pela sintaxe), um prettyprinter (exibindo o texto em diferentes cores baseado
na sintaxe), um verificador de inconsistncia (incremental), ferramentas de anlise, um
interpretador ou compilador/gerador de aplicaes e um depurador.
Geralmente, a entrada para estas ferramentas so metalinguagens com informaes
sobre os vrios aspectos da DSL entre eles sintaxe, prettyprinting, verificao de
4

consistncia, anlise, execuo, traduo, transformao e depurao[4]. comum a

sintaxe de uma DSL ser descrita com algo semelhante a BNF[11], no entanto, Fowler
[12] faz meno a linguagens de estruturao de dados como XML[13], JSON[14] e
YAML[15] como forma de descrever DSL, e que muitas vezes arquivos de
configurao ou que especificam interfaces grficas do usurios no formato XML so
efetivamente DSLs.
Kelly e Tolvanen [9] e Fowler [16] destacam algumas ferramentas para o
desenvolvimento de DSL. Uma listagem com a principal dependncia, gratuidade e
sistemas operacionais suportados por estas ferramentas pode ser observado na Tabela 1.
Tabela 1. Ferramentas para Desenvolvimento de DSL
Gratuita

Sistemas Operacionais
Suportados

MetaEdit+ (MetaCase)

No

Windows, Linux e
Mac OS X

GME (Vanderbilt
University)

Sim

Windows

Ferramenta

Dependncias

DSL Tools (Microsoft)

Visual Studio 2005

Professional Edition

No

Windows

MPS (JetBrains)

Java Virtual Machine (JVM)

Sim

Windows, Linux e
Mac OS X

Eclipse Modeling
Project (Eclipse)

Java Virtual Machine (JVM)

Sim

Windows, Linux e
Mac OS X

Xtext

Eclipse Modeling Project

(Eclipse)

Sim

Windows, Linux e
Mac OS X

Existem poucas ferramentas de desenvolvimento de DSL, quando comparamos ao

nmero de ferramentas de desenvolvimento de linguagens de programao de propsito
geral. Geralmente, essas ferramentas so distribudas em verses especficas para cada
sistema operacional, possuem dependncias e necessitam ser instaladas para que possam
ser executadas, o que dificulta a sua utilizao em ambientes de rede controlados, onde
os usurios no tem autonomia para instalar programas.
Muitas so as motivaes para o desenvolvimento de linguagens especficas de
domnio, no entanto, decidir por uma abordagem DSL envolve custos e riscos que
podem sem minimizados pela adoo de ferramentas especializadas nas fases de
desenvolvimento e implementao de uma nova DSL. Sobretudo, essa ferramentas so
escassas, precisam ser instaladas e muitas vezes possuem dependncias. Para resolver
este problema este artigo apresenta na Seo 3 uma ferramenta alternativa, gratuita,
multiplataforma para o desenvolvimento e implementao de DSL.
2.2. Web Programvel
OReilly [5] define que Web 2.0 a mudana para uma internet como plataforma, e
que a regra mais importante desenvolver aplicativos que aproveitem os efeitos de
rede para se tornarem melhores quanto mais so usados pelas pessoas, aproveitando a
inteligncia coletiva e acredita que os servios tornam-se melhor a medida que mais
pessoas o utilizam e que a colaborao dos usurios, definido por ele como rede de
5

contribuies, o fator chave para a melhoria contnua destes servios e a forma de

garantir sua continuidade.
Ao assumir uma postura colaborativa, os usurios assumiram o papel de codesenvolvedores dos servios que utilizam, o que fez com que o
ditado do cdigo aberto libere cedo e libere frequentemente de fato se
transformasse numa posio ainda mais radical, o beta perptuo, onde
produtos so desenvolvidos em aberto, com novas funcionalidades sendo
transmitidas em base mensal, semanal ou mesmo dirio[5].
Nas aplicaes web, novas funcionalidades so disponibilizadas aos usurios
constantemente e o monitoramento das atividades do usurio fundamental para decidir
se um novo recurso na aplicao dever ser explorado ou deixado de lado, tornando seu
ciclo de desenvolvimento diferente da era PC ou cliente-servidor [5].
A experincia do usurio tambm melhorou, inicialmente com as aplicaes multimdia
e interfaces do usurio mais bem elaboradas em Flash, onde a Macromedia cunhou o
termo Rich Internet Applications, e posteriormente com o lanamento do Gmail pelo
Google, um aplicativo baseado na web, com interface rica do usurio e com
interatividade semelhante a um software desktop. O conjunto de tecnologias utilizada
pelo Google foi batizado de AJAX e que se tornou um componente chave para as
aplicaes web 2.0. Jesse James Garret citado por OReilly [5] define Ajax como:
Ajax no uma tecnologia. o conjunto de vrias tecnologias, cada uma
florescendo em seu prprio direito, juntando-se em maneiras novas e
poderosas. Ajax incorpora:
-

Apresentao baseada em padres usando XHTML e CSS,

Exibio dinmica e interao com o Document Object Model,

Intercmbio de dados usando XML e XSLT,

Recuperao de dados assncrona usando XMLHttpRequest,

e JavaScript mantendo tudo isso junto.

Hoje as aplicaes e servios web deixaram de ser exclusividade dos computadores

pessoais esto nos smartphones, tablets e internet das coisas. As aplicaes agora
atendem ao princpio defendido por OReilly [5] para software acima do nvel de um
nico dispositivo. Agora, o teclado e o mouse no so mais os principais dispositivos
de entrada. Telas sensveis ao toque e sensores enriqueceram ainda mais a experincia
do usurio adicionando recursos como geolocalizao, reconhecimento de voz,
reconhecimento de imagem, deteco facial, sensores de proximidade e movimento.
Meira et al. [7] acredita que uma nova fase est surgindo, onde a web vista como uma
plataforma de programao, onde a inovao reside no poder de desenvolver para web,
na prpria web, ou seja, usar a web como plataforma de desenvolvimento e execuo.
Um subconjunto de tecnologias da web 2.0 que estiveram em profunda transformao
nos ltimos anos permitiu que os usurios passassem de consumidores, a criadores de
poderosas aplicaes web utilizando recursos de terceiros, aplicaes estas
denominadas mashups [8]. De acordo com Maximilien et al. [17], mashups so a
principal manifestao da web programvel, e combinam visualizaes, dados e lgica
6

de sites ou aplicaes existentes para criar novas aplicaes com foco em situaes e
problemas efmeros.
Os maiores provedores de servio da internet como Google, Amazon e eBay tem
provido application programming interfaces (APIs) como servios da web (do ingls
web services) para que usurios e desenvolvedores possam criar novas aplicaes a
baixo custo ou gratuitamente [8]. O nmero de empresas provendo APIs para uso
pblico vem crescendo exponencialmente. Segundo DuVander [18] o diretrio de APIs
Programmable Web registrou o marco de 8000 APIs em novembro de 2012,
principalmente impulsionado pela adoo de APIs abertas por grandes empresas.
Outro acelerador do crescimento do nmero de APIs foi a evoluo dos smartphones e
dispositivos conectados a internet. Existe uma grande chance que qualquer aplicativo
no seu telefone faa alguma coisa interessante usando uma API[19].
O Rich Site Summary (RSS), tecnologia que permitiu que o usurio se inscrevesse para
receber o contedo que quer ler, apresentou novas formas de consumir informaes e
servios da web [5]. A popularizao do RSS fez com que servios web antes somente
disponibilizados atravs do formalismo do Simple Object Access Protocol (SOAP), que
transporta XML atravs do protocolo HTTP, passassem a ser oferecidos de formas
alternativas, mais leves e diretas, como os servios REST (Representational State
Transfer) tambm conhecidos com RESTful services [20]. Uma outra mudana que
veio com a adoo de servios REST foi a adoo de um formato leve de intercmbio
de dados chamado JSON como alternativa ao formato XML, utilizado nos servios
SOAP e XML-RPC.
DuVander [21] aponta que como atualmente existem mais servios REST que SOAP,
XML-RPC ou outros protocolos, o formato JSON vem crescendo e ganhando espao
em utilizao frente ao formato XML (Figura 1). Segundo DuVander [21] o formato
JSON o formato preferido pelos desenvolvedores atualmente e com isso est se
tornando tambm a escolha dos provedores de API. O formato JSON pode ser
facilmente analisado pela maioria das linguagens de programao, principalmente em
JavaScript por ser nativo e quando a API oferece suporte a JSONP (JSON with padding,
tcnica de programao JavaScript que permite solicitar dados em um domnio
diferente), esta pode ser consumida diretamente do navegador. O formato JSON, sem
abrir e fechar tags, mais leve sendo apreciado por desenvolvedores e provedores de
servios [21].
Porcentagem+de+novas+APIs++
com+suporte+somente+a+JSON+

Porcentagem de APIs
com suporte a XML
95%$

25%#

90%$

20%#

85%$

15%#
10%#

80%$

5%#

75%$

0%#

70%$
2006#

2007#

2008#

2009#

2010#

2011#

2009$

2010$

2011$

Fonte: Programmable Web[21]

Figura 1. Estatsticas sobre Utilizao de JSON e XML em APIs

Muita coisa mudou desde que o eBay lanou sua primeira API no ano 2000. A
utilizao de APIs se tornou a principal forma de conectar dados e funcionalidades entre
aplicaes. Hoje as APIs so o centro da estratgia do Google (que conta com mais de
90 APIs) e aceleradores de crescimento de servios com Twitter e Facebook [22].
Pense na web de 1995. Havia uma abundncia de empresas sem sites.
Muito rapidamente, todas essas empresas perceberam que precisavam para
ter um site para competir. Vimos a mesma coisa com as mdias sociais e
este o caminho que as APIs esto seguindo. Uma srie de grandes
empresas acrescentado APIs em 2011, incluindo as trs principais
empresas norte-americanas de carto de crdito[22].
O universo das APIs ainda muito novo, muita coisa ainda est em evoluo e no
existem padres definidos. O caos de um universo de APIs em expanso vai levar
algum para procurar por ordem. E um pouco de ordem provavelmente necessria
[22]. As APIs SOAP so mais ordenadas, auto documentas e fceis de serem
desenvolvidas, uma vez que existem ferramentas de apoio. No entanto, a leveza e a
simplicidade do REST tem facilitado a implementao de APIs por provedores de
servios e o consumo por parte dos desenvolvedores, levando o nmero de APIs REST
crescer e cada vez mais e se sobrepor percentualmente em relao as APIs SOAP
(Figura 2).
Protocolos usados por Web APIs
SOAP
23%
OUTROS
2%
JavaScript
5%
XML-RPC
2%

REST
68%

Fonte: Programmable Web [23]

Figura 2. Protocolos usados por APIs

A utilizao de APIs uma tendncia, que se popularizou pelo uso em redes sociais,
posteriormente com o crescimento do mercado de aplicaes mveis, e agora com a
adoo de APIs abertas pelas Enterprises. A utilizao de APIs no mais um
diferencial tcnico, uma necessidade. Recentemente, um novo modelo de negcio
emergiu, backend-as-service [24], provendo a desenvolvedores recursos como
armazenamento na nuvem, gerenciamento de usurios, operaes de CRUD,
notificaes push, integrao com redes sociais, entre outros.
Independente da tecnologia, protocolo ou formato de intercmbio utilizado (Figura 3), o
mais importante do que API que est exposta so os dados que ela acessa. A facilidade
de uso, uma boa documentao de seus recursos e utilizao, funcionalidades
exclusivas, a qualidade e confiabilidade dos dados gerenciados, so os verdadeiros
diferenciais, que se transformam em vantagem competitiva [25].

Que tecnologia voc usou em 2012?

REST
JSONP
OAuth 2
SOAP
RSS/Atom feeds
WebSockets
CORS
WS-*
Webhooks
OAuth 1.0a
PubSubHubbub

35,40%
34,60%
29,20%
13,10%
12,30%
11,50%
10,00%
8,50%
6,90%
2,30%

85,40%

Fonte: Programmable Web [25]

Figura 3. Tecnologias e Protocolos usados em APIs

A evoluo do poder computacional dos dispositivos conectados a internet e a evoluo

dos navegadores e dos padres que estes utilizam, possibilitaram que aplicaes mais
robustas, antes exclusividade de ambientes desktop, fossem disponibilizadas na web. A
evoluo das tecnologias de integrao das aplicaes e o surgimento das APIs
possibilitou a criao de novas aplicaes, integradas a vrios servios da web, que
trazem mais recursos e poder colaborativo aos usurios que as aplicaes da era PC. O
formato JSON de intercmbio de dados vem se popularizando entre os desenvolvedores
cada vez mais e hoje o formato base para intercmbio em APIs que utilizam os
princpios REST. A Seo 3 apresenta uma ferramenta que se baseia nos princpios da
Web 2.0, que disponibiliza recursos para que seus usurios a estendam atravs da
utilizao de APIs de terceiros e que utiliza JSON como meta linguagem de entrada
para o desenvolvimento de DSLs.

3. Proposta de Construo da Ferramenta

Este artigo tem por objetivo apresentar uma ferramenta para o desenvolvimento de
linguagens especficas de domnio [3], utilizando a web como plataforma [5]. A
ferramenta, DSL Encoder (DSLE), um ambiente de desenvolvimento integrado [4], de
cdigo aberto, de fcil utilizao, que pode ser conectada a outros servios da web
atravs de APIs [8], e que oferece recursos para sua melhoria contnua por meio da
inteligncia colaborativa [5].
A ferramenta DSLE possui um gerenciador de projetos e arquivos interno, um editor de
texto integrado com syntax highlighter, e um console que apresenta informaes ao
usurio, as sadas impressas do processamento dos programas DSL e em caso de
apresenta a posio do cdigo fonte original onde o erro foi encontrado.
Em seu ncleo existe um framework DSL [26], escrito em JavaScript, que permite a
criao de DSLs descritivas e programas baseados nessas DSLs, utilizando o formato
leve de intercmbio de dados JavaScript Object Notation (JSON) [14]. A ferramenta
tambm permite a criao de templates para processamento dos programas DSL e/ou
gerao de cdigo [9].
DSLE se prope a ser um ambiente extensvel, onde os usurios podem criar seus
prprios plug-ins, utilizando a linguagem JavaScript, na prpria ferramenta. Estes plugins tanto podem adicionar novas funcionalidades a ferramenta como conect-la a outros
servios da web atravs do consumo de APIs de terceiros.
9

Os plug-ins, templates, DSLs e programas DSL podem ser escritos, validados e

processados na prpria ferramenta, no entanto, os usurios podem instalar recursos
desenvolvidos por terceiros atravs da Extensions Marketplace, um diretrio de
extenses integrado a ferramenta.
A seo 3.1 aborda as premissas para construo da ferramenta e apresenta as
abordagens tomadas para que estas fossem atendidas.
3.1. Premissas para a Construo da Ferramenta
3.1.1. Cdigo Aberto
Um dos objetivos da ferramenta que ela seja melhorada constantemente, seja pela
adio de novos recursos atravs de plug-ins, seja pela prpria evoluo em seu cdigo
fonte. Como citado por Raymond [27] dados olhos suficientes, todos os erros so
triviais, dessa forma, para que ferramenta seja evoluda pela colaborao de vrios
desenvolvedores e/ou usurios, a opo de licenciamento da ferramenta e de seu cdigo
fonte foi o cdigo aberto, e a licena escolhida foi a New BSD [28] por ser uma licena
mais permissiva quanto a utilizao do cdigo fonte comercialmente.
OReilly [29] cita que dar aos usurios de um produto acesso ao seu cdigo fonte e
direitos para criar trabalhos derivados, permite se auto-ajudarem, e encoraja a
evoluo natural do produto, bem como o projeto inicial do produto.
Ao liberar o cdigo fonte em uma licena de cdigo aberto esperado que seus usurios
se tornem tambm co-desenvolvedores, com isso a deteco e correo de erros seja
acelerada e a qualidade do software seja melhorada, a medida que mais codesenvolvedores participem da sua evoluo.
O ncleo da ferramenta oferece vrios pontos de extenso tratados no item 3.1.9, codesenvolvedores podem estender o cdigo para atender uma necessidade especfica e se
desejarem, podem compartilhar as novas funcionalidades especializadas.
De fato, muitos projetos open-source de sucesso tem uma arquitetura
modular, que permite aos usurios estender a funcionalidade do sistema,
sem ter que alterar a funcionalidade do ncleo existente. Isso permite um
projeto open-source ganhe escalabilidade com sua comunidade, enquanto o
original visionrio (ou time) retm o controle sobre o produto ncleo[29].
Ao atender a premissa de cdigo aberto espera-se fomentar o crescimento da
ferramenta, por meio da criatividade de seus co-desenvolvedores, com o
desenvolvimento de novas funcionalidades, de forma modular, e que os erros e
problemas sejam detectados e corrigidos mais rapidamente.
3.1.2. Web como plataforma
Uma dificuldade encontrada nas ferramentas de desenvolvimento de DSLs atuais que
elas possuem verses especficas para cada sistema operacional, possuem dependncias,
precisam ser instaladas e muitas vezes no oferecem uma verso gratuita.
Um das premissas do DSL Encoder usar a web como plataforma, e que seja
desenvolvida acima do nvel de um nico dispositivo por meio de uma aplicao leve,
multiplataforma e de fcil acesso [5]. Taivalsaari e Mikkonen [6] apontam que
10

aplicaes binrias convencionais esto em maior desvantagem comparadas a

software baseado na web porque este pode ser implantado instantaneamente ao redor
do mundo.
O uso de tcnicas com programao JavaScript como AJAX, e JSONP, aliados aos
novos padres emergentes como HTML5, CSS3 e WebGL esto possibilitando a
criao de aplicaes ricas, com funcionalidades e comportamento semelhante ao das
aplicaes desktop e transformando a web numa verdadeira plataforma de
software[6]. Para atender essa premissa a ferramenta foi desenvolvida utilizando
JavaScript acessando alguns recursos essenciais disponveis em HTML5.
A linguagem JavaScript foi introduzida pela Netscape em 1995 com o objetivo de
permitir que os desenvolvedores criassem aplicaes com interao com o usurio no
lado do cliente. Atualmente a principal linguagem de programao no lado do cliente
em navegadores web, e segundo uma pesquisa realizada pela RedMonk [30], est se
tornando uma das linguagens mais populares na atualidade.
O DSL Encoder executado no lado do cliente, no havendo necessidade de interao
com um servidor para usufruir de suas funcionalidades. Aps o programa ser carregado
no navegador, sua execuo local.
O emergente padro HTML5 veio para complementar algumas deficincias existentes
nos padres HTML anteriores, trazendo vrias novas funcionalidades, das quais
podemos destacar Offline Applications e Local Storage [31] como essenciais ao
desenvolvimento da ferramenta.
A funcionalidade Offline Applications permite que aplicaes web sejam executadas
mesmo quando uma conexo de rede no est ativa. Depois que a ferramenta
carregada pela primeira vez, o navegador s carrega novamente os arquivos que
sofreram atualizaes. Alm de habilitar o uso off-line, evita o carregamento de
arquivos estticos toda vez que a ferramenta acessada, tornando mais rpida a sua
inicializao.
O recurso Local Storage o responsvel pelo armazenamento das informaes do
usurio. O Local Storage oferece um mecanismo de armazenamento local que se
comporta como um banco de dados de chave-valor, permitindo o armazenar localmente
dados textuais.
As tecnologias utilizadas para o desenvolvimento da ferramenta so nativas dos
navegadores que esto de acordo com as especificaes do World Wide Web
Consortium (W3C) [31], no exigindo nenhum recurso adicional, atendendo assim a
premissa web como plataforma.
3.1.3. Sistema de Arquivos
Sistema de arquivos, do ingls filesystem, um tipo de armazenamento de dados que
permite manipular uma coleo de arquivos. O sistema de arquivos responsvel por
executar as operaes de localizao, criao, atualizao e excluso de arquivos e
diretrios.
O DSL Encoder uma ferramenta onde vrios tipos de arquivo so criados pelos
usurios. Alm disso, uma das funcionalidades da ferramenta, tratado no item 3.1.7 a

11

gerao de cdigo, onde um ou mais arquivos podem ser gerados a partir de um

programa DSL.
Alguns tipos de arquivos so suportados por padro pela ferramenta: arquivos com a
extenso .dsl representam linguagens especficas de domnio, arquivos com a
extenso .tpl representam os templates, arquivos com a extenso .js os plug-ins e os
arquivos com a extenso .json representam os programas DSL.
Arquivos que representam linguagens, templates e plug-ins ficam agrupados em
diretrios especficos para cada um deles dentro do diretrio core, localizado na raiz
do sistema de arquivos. Ao criar um projeto na ferramenta, um diretrio criado dentro
do diretrio projects, tambm localizado na raiz do sistema de arquivos. Cada projeto
possui pelo menos dois diretrios, src onde ficam localizados os programas DSL e
gen onde sero armazenados os arquivos gerados automaticamente pela aplicao.
Dessa forma, a presena de um sistema de arquivos indispensvel ao funcionamento
pleno da ferramenta. As polticas de segurana do navegador impedem que aplicaes
web nativas tenham acesso ao sistema de arquivos do computador ou dispositivo que
est as executando. O padro HTML5 proposto pela W3C [31] prev uma API chamada
Filesystem, que d acesso a um sistema de arquivos em uma sandbox. No entanto, esta
API no est implementada em todos os maiores navegadores web atuais, o que impede
sua utilizao como sistema de arquivos da ferramenta.
Para atender essa premissa foi desenvolvida uma implementao de um sistema de
arquivos, que atende as necessidades da ferramenta, utilizando a funcionalidade
HTML5 Local Storage para a persistncia dos dados.
O acesso a esse sistema de arquivos feito atravs de uma API chamada
Dsle.FileStorage. Esta API abstrai o mecanismo de armazenamento e um dos pontos
de extenso da ferramenta. No futuro, quando a API nativa HTML5 Filesystem estiver
implementada pelos maiores navegadores, o mecanismo de armazenamento poder ser
substitudo de forma transparente.
Aps o carregamento da aplicao no navegador, esta pode ser executada sem a
necessidade de conexo com a internet, e como o sistema de arquivos local, dentro da
estrutura de armazenamento de dados do navegador, tudo que o usurio necessita j est
em execuo, dispensando chamadas ao servidor.
Para evitar a perda de dados, ou para que o usurio possa levar seus arquivos para outra
mquina e/ou outro navegador, duas funcionalidades de backup foram implantadas na
ferramenta: uma que compacta o sistema de arquivos em um arquivo zip e faz o
download, e outra onde o usurio faz o backup para uma conta de servio de
armazenamento na nuvem. Atualmente a ferramenta est integrada ao servio Dropbox,
mas outros servios podem ser adicionados atravs de plug-ins.
3.1.4. Editor de Texto
O editor de texto o principal componente de interao com o usurio da ferramenta,
nele so especificadas as DSLs, so codificados os programas DSL, so criados os
templates e plug-ins. Alm disso, os arquivos gerados pelo processamento dos
programas DSL tambm pode ser modificado no editor de texto. Apesar do interesse
crescente em interfaces icnicas e mtodos de programao visual, o texto
onipresente no ambiente de computador e sua importncia no diminui[32].
12

Algumas funcionalidades em um editor de texto so essenciais para tornar mais gil a

escrita de cdigo fonte. Entre as funcionalidades de um editor de texto de cdigo fonte
podemos elencar:

Syntax highlighting: exibe o texto em cores diferentes de acordo com a sintaxe, e

possibilita ao usurio identificar visualmente erros de escrita, executando a
correo enquanto escreve;
Indentao Automtica: faz com que o texto seja recuado automaticamente a
cada nova linha inserida, acompanhando a hierarquia do texto que est sendo
escrito. A indentao possibilita uma melhor compreenso do texto facilitando
sua modificao, correo ou otimizao.
Live syntax checker: verifica a sintaxe do cdigo fonte que est sendo escrito
baseado na linguagem do arquivo e faz crticas em tempo real caso algum
problema seja encontrado.

Essa funcionalidades possibilitam ao usurio antecipar-se aos erros de interpretao

e/ou compilao e aceleram o desenvolvimento. Para atender a essa premissa foi
adicionado a ferramenta o componente de cdigo aberto Ace [33].
O Ace um editor de cdigo fonte escrito em JavaScript que poder ser incorporado a
outras aplicaes. Ele possui as funcionalidades supra citadas e outras como localizar e
substituir, destaque de parnteses e chaves correspondentes, alterna entre soft tabs e real
tabs, exibe caracteres ocultos, mltiplos cursores de seleo e drag and drop de texto
com o mouse. Essas funcionalidades fazem com que seu comportamento e performance
seja semelhante ao de editores nativos como Sublime, Vim e TextMate [33] tornando a
experincia do usurio na ferramenta agradvel, oferecendo recursos que aceleram o
desenvolvimento.
3.1.5. DSL Processor
Para tornar possvel o desenvolvimento de DSL na ferramenta, foi desenvolvido um
componente escrito em JavaScript orientado a objeto, totalmente desacoplado. Este
componente foi chamado de DSL.JS[26] e liberado sob a licena de cdigo aberto New
BSD.
As motivaes para o cdigo aberto foram tratadas no item 3.1.1. Criar um componente
para o desenvolvimento de DSL desacoplado, sem dependncias e liber-lo
individualmente aumenta ainda mais a possibilidade da sua evoluo por codesenvolvedores, uma vez que o torna mais simples e permite que seja utilizado por
outras aplicaes [29]. DSouza e Will [34] definem componente como:
Um pacote coerente de artefatos de software que podem ser
independentemente desenvolvidos e entregues como uma unidade e que
pode ser composto, sem modificao, com outros componentes para
construir algo maior.
A motivao para transformar essa funcionalidade ncleo em um componente foi
habilitar o reuso. O DSL.JS responsvel por duas funcionalidades principais: Analisar
a especificao da DSL e Validar o programa DSL.

13

Analisar a especificao da DSL

O componente responsvel por analisar o arquivo no formato JSON que contm a
especificao da DSL, verificar se est bem formado e se contm todos os atributos
necessrios criao de uma DSL pela ferramenta. No arquivo de especificao de DSL
so informadas as propriedades que identificam a linguagem, os templates que sero
usados pela linguagem para processamento, os tipos que compe essa linguagem
chamados de DslType e o tipo principal que corresponde a objeto descrito pela DSL.
Validar o programa DSL
O programa DSL tambm escrito no formato JSON e possui duas propriedades
principais, uma que identifica qual DSL ele utiliza e outra que representa o objeto
descrito por essa linguagem. O componente verifica se o objeto est descrito de acordo
com as especificaes. Analisa se os valores das propriedades esto de acordo com o
DslType definido e se todos os tipos obrigatrios esto presentes.
Ao encontrar qualquer inconsistncia, seja na anlise da linguagem, seja na validao do
programa DSL, o componente encerra o processamento e levanta uma exceo, que
dever ser tratada pela aplicao, informando o que est errado. O DSL Encoder possui
um console tratado no item 3.1.8, nele so apresentados ao usurio todas as
inconsistncias encontradas.
3.1.6. Template Engine
Um template engine responsvel por transformar templates em contedo, substituindo
as marcaes contidas nos mesmos por dados variveis. O objetivo principal da
ferramenta a criao de linguagens especficas de domnio e de programas baseados
nessa linguagem. Uma das formas de executar os programas DSL atravs da
utilizao de template engines.
Para atender a essa premissa foram adicionados dois componentes template engine a
ferramenta: json-templates [35] e JavaScript Template [36].
Os templates suportados pelo engine json-templates possuem marcaes mais simples e
legveis por pessoas que no so necessariamente programadores. Suas marcaes
simplificadas permitem fazer declaraes de condio e repetio sem a necessidade de
um conhecimento mais aprofundado de programao.
A engine JavaScript Template permite inserir trechos de programao escritos em
JavaScript nas marcaes do template e trs para o processamento todas as
funcionalidades da linguagem, no entanto, conhecimento em programao necessrio
para o desenvolvimentos de templates suportados por essa engine.
Os arquivos de template que sero utilizados para o processamento de um programa
DSL so definidos no arquivo JSON de especificao da linguagem. Cada linguagem
pode conter um ou mais arquivos de template em sua especificao e para cada arquivo
de template deve ser especificado a engine em que ser processado.

14

3.1.7. Code Generator

Uma das motivaes para utilizao de DSLs a gerao de cdigo, sendo uma recurso
fundamental para qualquer ferramenta de desenvolvimento de DSL. Esta funcionalidade
atendida pela ferramenta utilizando os recursos template engines (tratado no item
3.1.6), DSL Processor (tratado no item 3.1.5) e sistema de arquivos (tratado no item
3.1.3).
Aps a validao de um programa pelo DSL processor, um boto intitulado Generate
habilitado, e ao ser acionado, o processo de gerao de cdigo iniciado. A ferramenta
tenta localizar um arquivo de template especificado na linguagem DSL, e caso seja
encontrado, aplica o objeto descrito pelo programa DSL sobre o arquivo de template,
utilizando a engine especificada para este template. O resultado um arquivo de texto,
que ser gravado no diretrio gen dentro do projeto ao qual o programa DSL
pertence.
Cada linguagem pode conter um ou mais arquivos de template, e para cada arquivo de
template, um arquivo de texto gerado pela ferramenta. Na especificao dos arquivos
de template de uma linguagem, alm de especificar qual engine ir realizar o
processamento, possvel especificar um prefixo, um sufixo e uma extenso para o
arquivo de texto gerado.
Kelly e Tolvanen [9] definem gerador de cdigo como um autmato que acessa
modelos, extrai informaes a partir deles, e transforma-os em produo em uma
sintaxe especfica. Na ferramenta, o modelo o objeto descrito pela DSL e a sintaxe
especfica definida pelo template. Herrington [2] destaca os seguintes benefcios
proporcionados por um gerador de cdigo:

Qualidade: uma vez que a abordagem de gerao de cdigo baseado em

templates constri cdigo de fcil leitura e fcil deteco de erros, e que por
causa da natureza do gerador, os erros encontrados podem ser corrigidos no
template e ento o cdigo gerado novamente, corrigindo os erros.
Consistncia: gerando cdigo que utiliza nomes de classes, mtodos e
argumentos consistentes.
Produtividade: gerando cdigo mais rpido que escrito a mo, principalmente
para atender as futuras necessidades de mudana, alterando apenas o cdigo
base.
Abstrao: uma vez que o projeto especificado de forma abstrata, sem detalhes
de implementao, o cdigo poder ser gerado para uma ou mais plataformas de
tecnologia.

Segundo Herrington [2], Gerao de cdigo outro elo na cadeia evolutiva da

crescente abstrao. Com ela, voc vai produzir rapidamente cdigo de maior
qualidade, e assim ser capaz de responder s necessidades de mudana com
facilidade.
3.1.8. Console
Ao escrever cdigo fonte, os desenvolvedores esto sujeitos a cometer erros de escrita.
Estes erros podem variar de erros de sintaxe operaes indevidas que no podem ser
executadas. Com isso, uma forma de acelerar a correo de erros mostrar ao usurio o
que est errado e sugerir correes.
15

Para atender essa premissa, foi adicionado ferramenta um console, onde os erros de
compilao podem ser exibidos, permitindo que os usurios corrijam os mesmos
rapidamente.
Na inicializao da ferramenta uma verificao realizada nos arquivos de linguagem e
plug-ins. Caso sejam encontrados erros, o console apresenta o nome do arquivo e o erro
encontrado.
O processo de validao dos plug-ins feito inicialmente pela prpria engine JavaScript
do navegador, uma vez que estes so escritos na linguagem JavaScript nativa. O
resultado dessa validao um objeto JavaScript instanciado que corresponde ao
prprio plug-in. A ferramenta ento verifica se esse objeto est de acordo com as
diretivas de definio de plug-ins da ferramenta. Caso algum erro seja encontrado
tambm ser informado no console, caso contrrio, o mtodo de inicializao do plug-in
executado.
Para os arquivos de linguagens especficas de domnio e para os programas DSL, que
so escritos no formato JSON, o processo de validao feito pelo DSL Processor,
descrito no item 3.1.5, e as excees levantadas durante este processo so exibidas no
console.
No processo de gerao de cdigo o console utilizado para informar tambm os
resultados de operaes positivas, como por exemplo o nome dos arquivos gerados pela
operao e o contedo da transformao.
3.1.9. Hot-spots
A ferramenta DSL Encoder se prope a ser um ambiente integrado de desenvolvimento
extensvel e reutilizvel, onde usurios possam estend-la, no s pela alterao de seu
cdigo fonte como tambm em tempo de execuo atravs de plug-ins. Para isso, a
ferramenta foi projetada na forma de um framework orientado a objeto.
Frameworks podem reduzir os custos de desenvolvimento de aplicaes
uma vez que estes permitem projetistas e implementadores reutilizar suas
experincias na soluo de problemas no nvel de projeto e
codificao[37].
Os hot-spots so as partes flexveis de um framework, so os pontos extensveis que os
desenvolvedores utilizam para adicionar o seu cdigo e para especificar novas
funcionalidades. A ferramenta foi projetada de forma modularizada e permite que o
usurio estenda o seu funcionamento atravs de hot-spots bem definidos. Estes pontos
de extenso so tradados no item 3.2.2.
3.1.10. Plug-ins
A utilizao de plug-ins do suporte a extensibilidade, a customizao e a evoluo da
ferramenta. Adotar um sistema de plug-ins permite que a ferramenta seja estendida,
reconfigurada e adaptada em tempo de execuo [38].
A adaptao em tempo de execuo tem recebido considervel ateno nas reas de
pesquisa, tais como arquitetura de software, engenharia de linha de produto ou sistema
auto-adaptativos [38] e requisito necessrio em ambientes de desenvolvimento como

16

computao mvel e ubqua ou sistemas orientados a servios para lidar com as

mudanas de contexto [38].
Uma abordagem de plug-in permite que os desenvolvedores criem aplicaes
personalizadas para atender s suas necessidades individuais, onde pequenos aplicativos
se conectam ao ncleo da aplicao em forma de componentes para estender as suas
funcionalidades.
Para atender a premissa de extensibilidade e personalizao em tempo de execuo foi
adicionado a ferramenta um sistema de plug-ins. Os usurios podem criar seus prprios
plug-ins utilizando a ferramenta para codifica-los, podem instalar plug-ins de terceiros e
podem modificar plug-ins de terceiros para atender as suas necessidades.
Na ferramenta, um plug-in um objeto JavaScript com algumas propriedades de
identificao (id, name, version, author e description) e pelo menos um mtodo, que o
de inicializao chamado load().
Na inicializao da ferramenta todos os arquivos de plug-ins so localizados nos
sistema de arquivos, os objetos so instanciados e o mtodo de inicializao de cada um
deles executados. Ao realizar alteraes em um plug-in necessrio reiniciar a
aplicao para poder observar as mudanas. Caso ocorram erros de instanciao ou de
execuo, estes sero apresentados no console, e caso estes erros prejudiquem o
funcionamento da ferramenta, a execuo de plug-ins na inicializao pode ser suspensa
acrescentando o parmetro #noplugins URL de acesso. Um maior detalhamento de
como criar plug-ins ser apresentado no item 4.
3.2. Arquitetura da Ferramenta
Esta seo descreve a arquitetura da ferramenta, seus principais componentes e as
interaes entre eles. O item 3.2.1 mostra uma viso de alto nvel da arquitetura da
ferramenta. O item 3.2.2 detalha os principais componentes da ferramenta que podem
ser utilizados como hot-spots (tratados no item 3.1.9). Por fim, o item 3.2.3. apresenta o
diagrama de sequncia do processo de validao e gerao de cdigo realizada pela
ferramenta.
3.2.1 Diagrama de Apresentao
A Figura 4 mostra o diagrama de apresentao da arquitetura da ferramenta, aps o seu
carregamento no navegador, esta passa a funcionar localmente, sem a necessidade de
novas requisies ao servidor. Atravs de requisies JSONP a ferramenta pode se
comunicar diretamente com API de terceiros, sem a necessidade de comunicar-se com o
servidor de aplicao, os recursos que possibilitam o funcionamento local da ferramenta
foram tratados no item 3.1.2.

17

Clientes

Servidor de Aplicao
DSL Encoder

Internet

Servidor de API
de Terceiros

Servidor de API
de Terceiros
Comunicao com a Ferramenta
Comunicao com API de terceiros

Figura 4. Diagrama de Apresentao

3.2.1. Componentes
A ferramenta possui um componente principal chamado ide que funciona como um
framework e composto por outros componentes independentes, sendo cada um deles
um hot-spot da ferramenta, podendo ser reutilizados, na criao de plug-ins ou na
alterao do cdigo do fonte, por usurios que desejam estender a ferramenta para
atender a sua necessidade. Um dos principais objetivos da engenharia de software o
reuso [1] e uma arquitetura baseada em framework habilita o reuso, diminui os
esforos de desenvolvimento e aumentam a qualidade do software. Os principais
componentes do framework so:

ide.console: fornece ao usurio controle sobre o console da ferramenta. Permite

limpar ou adicionar mensagens de log, informao, alerta, erro e sucesso.
ide.dialog: permite ao usurio iniciar caixas de dilogo na ferramenta, por tipo
(alerta, informao, erro ou questionamento) atribuindo aes para os casos de
sucesso ou cancelamento. Alm disso permite a inicializao de caixa de dilogo
de entrada de dados, janelas e barras de progresso.
ide.extensions: fornece acesso ao gerenciador de extenses e permite o usurio
fazer o download, instalar e desinstalar linguagens, templates e plug-ins
desenvolvido por terceiros.
ide.fileStorage: fornece uma interface para um implementao de um sistema
de arquivos que ser utilizado pela ferramenta. Como visto no item 3.1.3, por
padro uma implementao desta interface realizada utilizando o recurso Local
18

Storage do HTML5. Porm outras implementaes podem ser realizadas

inclusive em tempo de execuo atravs de plug-ins.
ide.fileTypes: fornece acesso ao registro dos tipos de arquivos da ferramenta. O
usurio pode registrar novos tipos de arquivo ou alterar tipos de arquivos
existentes. Para cada tipo de arquivo possvel definir um mtodo para
validao do arquivo e a linguagem em que o arquivo escrito para que o editor
de texto (tratado no item 3.14) habilite os recursos syntax highlighter e live
syntax checker.
ide.languages, ide.templates, ide.plugins: fornece acesso ao registro de
linguagens, templates e plug-ins respectivamente. Permite ao usurio localizar,
obter, validar, atualizar, adicionar e remover linguagens, templates e plug-ins
dentro da ferramenta.
ide.tabbar: permite o usurio manipular a rea central da interface grfica da
ferramenta adicionando abas que podem ter contedo HTML/JavaScript que
interage com a ferramenta ou abrir um site da web em um iframe dentro da
ferramenta. Alm de adicionar novas abas o usurio pode ter acesso as abas que
so adicionadas pela ferramenta, como por exemplo edio de arquivo.
ide.toolbar: permite o usurio manipular a barra de ferramentas, adicionando
botes, e itens de menu, informando o mtodo que ser acionado com o evento
de clique. Geralmente utilizado na inicializao de plug-ins criando um boto
que executa a funcionalidade principal dos mesmos.
ide.tree: permite o usurio manipular o componente visual que representa a
rvore de arquivos e diretrios do sistema de arquivos da ferramenta.
ide.ajax: permite o usurio realizar requisies assncronas utilizando mtodos
GET e POST, e consumir API de terceiros utilizando JSONP.
ide.dsl: fornece uma interface para o DSL Processor. Foi utilizado o
componente DSL.JS como implementao desta interface.

A Figura 5 mostra o diagrama de componentes do framework.

Figura 5. Diagrama de Componentes

19

3.2.3. Processo de Validao e Gerao de Cdigo

O processo de validao e gerao de cdigo (Figura 6) iniciado com o envio do
programa DSL para o DSL Processor (item 3.1.5). O DSL Processor verifica se o
arquivo um JSON bem formado, e busca a propriedade language, localizado no
incio do arquivo, para identificar o DSL em que ele se baseia, ao identificar, tenta
encontrar o arquivo da linguagem especfica de domnio no seu sistema de arquivos
/core/languages/{nome_da_linguagem}.dsl.
Caso esta seja encontrada, o DSL Processor ir validar a prpria linguagem, verificando
se o arquivo um JSON bem formado e se este arquivo contm todos os requisitos para
descrever uma linguagem especfica de domnio, verificar tambm se o programa DSL
enviado est de acordo com essa descrio e se o objeto na propriedade main do
arquivo est de acordo com as especificaes da DSL.
A ferramenta tentar localizar no sistema de arquivos os templates informados na
especificao da linguagem e os engines de transformao. Se estes forem encontrados,
a ferramenta ir execut-los e os arquivos gerados sero salvos no diretrio
/projects/{nome_do_projeto}/gen/.

IDE!

Sistema de
Arquivos!

DSL Processor!

Gerar!

Obter Linguagem!

org.dsle.Math.json!
Linguagem!

Obter Templates!

Templates!

Salvar Arquivos Gerados!

Arquivos Gerados!

Figura 6. Diagrama de Sequncia Validao e Gerao de Cdigo

20

4. Uso da Ferramenta
4.1. Especificando uma DSL com JSON
Os arquivos que representam DSL so escritos no formato JSON. Um arquivo JSON
que representa uma DSL deve conter as propriedades descritas na Tabela 2.
Tabela 2. Propriedades JSON para Linguagem Especfica de Domnio
Propriedade

Tipo

Descrio

id

string

Um identificador nico da linguagem.

Uma boa prtica usar um namespace
como Java Packages para identificar a
linguagem (Ex: org.dsle.Math).

name

string

O nome da linguagem (Ex: Math)

description

string

A descrio da linguagem.

templates

Array
<DslTemplateOptions>

Um ou mais templates que a

linguagem ir utilizar para transformar
os programas DSL, cada um com suas
opes de engine e nomenclatura dos
arquivos gerados.

types

Array <DslType>

Os tipos DslType que sero cobertos

pela linguagem.

main

DslType

O objeto
linguagem.

principal

DslType

da

A propriedade templates deve conter um array de objetos DslTemplateOptions, estas

propriedades so descritas na Tabela 3. A propriedade types deve conter um array de
objetos DslType, estas propriedades so descritas na Tabela 4.
Tabela 3. Propriedades JSON para DslTemplateOptions
Propriedade

Tipo

Descrio

id

string

Um identificador nico do template. Uma

boa prtica usar um namespace como
Java Packages para identificar a
linguagem (Ex: org.dsle.Math).

file

string

O nome do arquivo do template localizado

em
/core/templates/
(Ex:
org.dsle.Math.tpl).

prefix

string

Prefixo que ser adicionado ao nome do

arquivo do programa DSL para compor o
nome
do
arquivo
gerado
(Ex:
android.auto.).

suffix

string

Sufixo que ser adicionado ao nome do

arquivo do programa DSL para compor o
nome do arquivo gerado (Ex: .v1_00).

extension

string

Extenso do arquivo gerado (Ex: xml).

engine

string

Nome da engine que ser utilizada para

processar o template. As duas engines
padro so JSON e JAVASCRIPT.

21

Tabela 4. Propriedades JSON para DslType

Propriedade

Tipo

Descrio

name

string

O nome do tipo que poder ser usado na

linguagem (Ex: number1).

primitiveType

string

O tipo primitivo do DslType. Deve ser

OBJECT, STRING, BOOLEAN,
NUMERIC ou ARRAY.

required

boolean

Deve ser true se o tipo for obrigatrio

na linguagem.

items

Array
<DslTypeItem>

Se o tipo primitivo do DslType

OBJECT, ento deve ser especificado um
array de itens (DslTypeItem) que compe
este objeto.

Se o tipo primitivo do DslType for OBJECT, significa que este tipo formado por um
ou mais DslTypes. Para especificar este objeto necessrio preencher a propriedade
items com um array de DslTypeItem, as propriedades do objeto DslTypeItem so
descritas na Tabela 5.
Tabela 5. Propriedades JSON para DslTypeItem
Propriedade

Tipo

Descrio

type

string

O nome do DslType. (Ex: number1).

required

boolean

Deve ser true se este DslType

obrigatrio no objeto.

4.2. Criando uma linguagem especfica de domnio

Para iniciar a ferramenta o usurio deve acessar o endereo http://www.dsle.org. Ao
acessar este endereo em um navegador web compatvel com as especificaes de
suporte HTML5 do W3C, a ferramenta carregada para o computador do usurio,
podendo ser utilizada de imediato. A Figura 7 mostra a tela inicial da ferramenta.

Figura 7. Tela inicial da ferramenta

22

Um novo projeto deve ser criado para que o uso da ferramenta possa ser iniciado. O
usurio deve clicar no boto New Project na barra de tarefas e digitar um nome para o
projeto na caixa de dilogo conforme a Figura 8.

Figura 8. Novo Projeto

Uma vez que o projeto est criado, ele aparecer no painel esquerdo, chamado Project
Explorer (Figura 9). O usurio deve clicar no boto New File na barra de
ferramentas para criar um novo arquivo, no projeto selecionado ou no ncleo da
ferramenta.

Figura 9. Project Explorer

A janela New File (Figura 10) permite que o usurio escolha o tipo de arquivo que
est tentando criar. Ele poder criar um novo programa DSL para o seu projeto atual ou
estender a ferramenta criando novas linguagens, templates e plug-ins.
Para criar uma nova linguagem, o usurio deve selecionar o tipo Domain-Specific
Language e digitar um nome para o arquivo. A extenso .dsl ser adicionada
automaticamente, e o arquivo ser salvo no diretrio /core/languages/. Como
exemplo, ser utilizado o nome de arquivo org.dsle.Math.

23

Figura 10. New File

Ao clicar no boto Ok uma nova aba ser aberta para edio do arquivo
org.dsle.Math.dsl. O cdigo a seguir dever ser adicionado ao arquivo. Ao salvar o
arquivo org.dsle.Math.dsl, este representar uma nova linguagem no sistema,
identificado pela propriedade id do objeto JavaScript contido no arquivo.
{
"id": "org.dsle.Math",
"description": "",
"name": "Math",
"templates": [{
"id": "org.dsle.Math",
"file": "org.dsle.Math.tpl",
"prefix": "",
"suffix": "",
"extension": "html",
"engine": "JAVASCRIPT"
}],
"types": [{
"name":"name",
"primitiveType": "STRING",
"required": true
},{
"name":"number1",
"primitiveType": "NUMERIC",
"required": true
},{
"name":"number2",
"primitiveType": "NUMERIC",
"required": true
},{
"name":"operator",
"primitiveType": "STRING",
"required": true
},{
"name":"math",
"primitiveType": "OBJECT",
"items":[
{
"type": "name",
"required": true
},
{
"type": "number1",
"required": true
},
{
"type": "operator",
"required": true
},
{
"type": "number2",
"required": true
}
]
}],
"main":"math"
}

24

4.3. Criando um template

Para criar um template o usurio dever clicar no boto New File na barra de tarefas e
selecionar o tipo de arquivos template, e digitar um nome para o arquivo (Ex:
org.dsle.Math). A extenso .tpl ser adicionada automaticamente, e ao clicar em
Ok arquivo ser salvo no diretrio /core/templates.
O engine de processamento definido na linguagem, para este template, no item 4.2 foi
JAVASCRIPT [36], e este aceita cdigo de programao JavaScript entre as tags {%
%}. O objeto o no template o objeto principal descrito pela DSL, e a tag {%= %}
imprime o valor da varivel para o contedo do template.
O seguinte cdigo dever ser adicionado e salvo no arquivo:
{%

%}

var result;
switch (o.operator) {
case '+':
result = o.number1 +
break;
case '-':
result = o.number1 break;
case '*':
result = o.number1 *
break;
case '/':
result = o.number1 /
break;
default:
result = 'invalid';
}

o.number2;
o.number2;
o.number2;
o.number2;

<html>
{% if (result == 'invalid')

{ %}

<p style="color: red;">

Operator '{%=o.operator%}' is invalid.
</p>
{% } else { %}
<p style="color: blue;">
{%=o.number1%} {%=o.operator%} {%=o.number2%} = {%=result%}
</p>
{% } %}
</html>

4.3. Criando um plug-in

Para criar um plug-in o usurio dever clicar no boto New File na barra de tarefas e
selecionar o tipo de arquivos plug-in, e digitar um nome para o arquivo (Ex:
org.dsle.HelloWorld). A extenso .js ser adicionada automaticamente, e ao clicar
em Ok arquivo ser salvo no diretrio /core/plugins.
Um plug-in um arquivo que descreve um objeto JavaScript com algumas propriedades
obrigatrias (id, name, version, author, description) e um mtodo obrigatrio chamado
load(). Quando a ferramenta inicializada, todos os objetos JavaScript que representam
plug-ins (contidos no diretrio /core/plugins) so instanciados e o mtodo load() de
cada um deles executado, permitindo modificar, adaptar e/ou configurar a ferramenta
em tempo de execuo.
25

O seguinte cdigo dever ser adicionado e salvo no arquivo:

{

id: " org.dsle.HelloWorld",

name: "Hello World Plug-in",
version: 0.01,
author: "You",
description: "Prints Hello World in Console.",
load: function () {
ide.console.info('Hello World', 'Another Text.');
}

Este plug-in apenas imprime a mensagem Hello World no console da ferramenta.

4.4. Criando um programa DSL
Para criar um novo programa DSL que utiliza a linguagem especfica de domnio recm
criada no item 4.2 e o template criado no item 4.3. O usurio deve clicar em New File
e selecionar o tipo de arquivo DSL Script, e digitar um nome para o arquivo (Ex:
org.dsle.Math). A extenso .json ser adicionada automaticamente, e ao clicar em
Ok o arquivo ser salvo no diretrio src dentro do diretrio do projeto /projects/
{nome_projeto}/src/. O seguinte cdigo dever ser adicionado e salvo no arquivo:
{
"language":"org.dsle.Math",
"main": {
"name": "Sum",
"number1": 10,
"operator": "*",
"number2": 3
}
}

Os programas DSL so escritos no formato JSON. A propriedade language informa a

linguagem especfica de domnio em que o programa se baseia e a propriedade main
o objeto descrito pela linguagem.
Ao clicar no boto Validate a ferramenta verificar se o arquivo um JSON bem
formado, tentar localizar a linguagem especificada na propriedade language no
sistema de arquivos e ao encontrar ir verificar se o programa DSL est de acordo com
as especificaes da linguagem, e caso todos as etapas sejam concludas com sucesso
uma mensagem de sucesso ser mostrada no console da ferramenta como na Figura 11.

Figura 11. Console: Validao Completa

26

Caso haja algum problema nas etapas de validao, como por exemplo se o valor da
propriedade number2 for trocado de um valor numrico para um valor booleano (ex:
true) uma mensagem de erro ser exibida no console informando o que deve ser
corrigido como na Figura 12.

Figura 12. Console: Erro de Validao

4.5. Gerando cdigo

Uma vez que o programa DSL validado, o boto Generate na barra de tarefas
habilitado, tornando possvel o processamento dos templates que ir transformar o
objeto descrito pelo programa em contedo. Ao clicar no boto Generate os arquivos
gerados sero salvos no diretrio gen dentro do diretrio do projeto
/projects/{nome_projeto}/gen/. A Figura 13 mostra as mensagens das etapas de
validao e gerao de cdigo apresentadas no console.

Figura 13. Console: Gerao de Cdigo

Como observado na Figura 13, o nome do arquivo gerado org.dsle.Math.json.html e

seu contedo o resultado do processamento do objeto descrito no programa DSL
criado no item 4.4 e do template criado no item 4.3. O cdigo gerado o seguinte:
<html>
<p style="color: blue;">
10 * 3 = 30
</p>
</html>

27

5. Estudo de Caso
A fim de destacar o possvel ganho de produtividade com a utilizao da ferramenta, foi
realizado um estudo de caso em uma empresa que trabalha com o desenvolvimento de
aplicaes mveis. Para este estudo de caso, foi escolhido o domnio especfico de
campos de formulrios em interfaces do usurio.
A equipe de front-ends da empresa trabalha com o framework jQuery Mobile [39] para
aplicaes web mveis, e com Appcelerator Titanium [40] para o desenvolvimento de
aplicaes mveis nativas para as plataformas iOS e Android.
No primeiro momento foi realizada uma anlise do domnio para identificar quais
campos de formulrio so mais utilizados pela empresa e so comuns a todos os
frameworks, e posteriormente foi identificado qual elemento representa cada um destes
campos. A Tabela 6 mostra o resultado desta anlise.
Tabela 6. Campos de Formulrio - Mapeamento entre Frameworks
Campos

jQuery Mobile

Appcelerator Titanium

Window

<div data-role="page"/>

Titanium.UI.Window

Form

<form/>

Titanium.UI.View

Label

<label/>

Titanium,UI,Label

Textfield

<input type=text/>

Titanium.UI.TextField

Textarea

<textarea/>

Titanium.UI.TextArea

Select

<select/>

Titanium.UI.Picker

Select Option

<option/>

Titanium.UI.PickerRow

Radio Group

<fieldset datarole="controlgroup"/>
<input type="radio"/>

Titanium.UI.Picker
Titanium.UI.PickerRow

Radio Button
Check Box

<input type="checkbox"/>

Titanium.UI.Switch

Slider

<input type="range"/>

Titanium.UI.Slider

Button

<input type="button"/>

Titanium.UI.Button

Posteriormente foram levantadas as propriedades mais utilizadas pela empresa para

formatar cada um destes campos de formulrio. Aps esse levantamento, foi
identificado em cada um dos frameworks as propriedades comuns para cada um desses
campos de formulrio. A Tabela 7 apresenta as propriedades que so comuns a todos os
campos de formulrio.

28

Tabela 7. Campos de Formulrio - Propriedades Comuns

Propriedade

jQuery Mobile

Appcelerator Titanium

Background color

style="background-color:;"

backgroundColor

Background image

style="background-image:;"

backgroundImage

Background repeat

style="backgroundrepeat:;"

backgroundRepeat

Border color

style="border-color:;"

borderColor

Border radius

style="border-radius:;"

borderRadius

Border width

style="border-width:;"

borderWidth

Enabled

disabled=""

enabled

Font family

style="font-family:;"

Font.fontFamily

Font size

style="font-size:;"

Font.fontSize

Font style

style="font-style:;"

Font.fontStyle

Font weight

style="font-weight:;"

Font.fontWeight

Height

style="height:;"

height

Id

id=""

Margin bottom

style="margin-bottom:;"

bottom

Margin left

style="margin-left:;"

left

Margin right

style="margin-right:;"

right

Margin top

style="margin-top:;"

top

Opacity

style="opacity:;"

opacity

Text align

style="text-align:;"

textAlign

Text color

style="color:;"

color

Visible

style="display:;"

visible

Width

style="width:;"

width

Cada um dos elementos de formulrio possuem propriedades adicionais. A Tabela 8

apresenta as propriedades adicionais para o elemento label. A Tabela 9 para o
elemento textfield. A Tabela 10 para o elemento textarea. A Tabela 11 para o
elemento select. A Tabela 12 para o elemento selectOption. A Tabela 13 para o
elemento radioGroup. A Tabela 14 o elemento radioButton. A Tabela 15 apresenta
para o elemento checkbox. A Tabela 16 para o elemento slider. Por fim, a Tabela
17 apresenta as propriedades adicionais para o elemento button.
Tabela 8. Label - Propriedades Adicionais
Propriedade

jQuery Mobile

Appcelerator Titanium

Text

<label>{text}</label>

text

29

Tabela 9. Textfield - Propriedades Adicionais

Propriedade

jQuery Mobile

Appcelerator Titanium

Editable

readonly="

editable

Hint text

placeholder=""

hintText

Max length

maxlength=""

maxLength

Password

type="password"

passwordMask

Value

value=""

value

Tabela 10. Textarea - Propriedades Adicionais

Propriedade

jQuery Mobile

Appcelerator Titanium

Editable

readonly="

editable

Hint text

placeholder=""

hintText

Max length

maxlength=""

maxLength

Value

<textarea>{value}</textarea>

value

Tabela 11. Select - Propriedades Adicionais

Propriedade

jQuery Mobile

Appcelerator Titanium

Value

value

Tabela 12. Select Option - Propriedades Adicionais

jQuery Mobile

Appcelerator
Titanium

Text

<option>{text}</option>

title

Selected

selected=""

Value

value="

Propriedade

Tabela 13. Radio Group - Propriedades Adicionais

Propriedade

jQuery Mobile

Appcelerator Titanium

Value

value

30

Tabela 14. Radio Button - Propriedades Adicionais

Propriedade

jQuery Mobile

Appcelerator Titanium

Checked

checked=""

Text

title

Value

value=""

Tabela 15. Checkbox - Propriedades Adicionais

Propriedade

jQuery Mobile

Appcelerator Titanium

Text

title

Value

value=""

value

Tabela 16. Slider - Propriedades Adicionais

jQuery Mobile

Appcelerator Titanium

Min

min=""

min

Max

max=""

max

Value

value=""

value

Propriedade

Tabela 17. Button - Propriedades Adicionais

Propriedade
Text

jQuery Mobile

Appcelerator Titanium

value=""

title

Aps essa anlise foi criada uma linguagem especfica de domnio utilizando os jarges
utilizados pelos front-ends, abstraindo as implementaes de cada um dos frameworks.
A linguagem recebeu o nome de FormUI e o id org.dsle.FormUI. Os DslTypes
criados para a esta linguagem so apresentados na Tabela 18.

31

Tabela 18. DslTypes

DslType

PrimitiveType

DslType

PrimitiveType

align

STRING

password

BOOLEAN

background

OBJECT

radioGroup

OBJECT

border

OBJECT

radioOptions

ARRAY

bottom

STRING

radius

STRING

button

OBJECT

readOnly

BOOLEAN

checkbox

OBJECT

repeat

STRING

checked

BOOLEAN

right

STRING

color

STRING

select

OBJECT

enabled

BOOLEAN

selected

BOOLEAN

family

STRING

selectOptions

ARRAY

font

OBJECT

size

STRING

form

OBJECT

slider

OBJECT

formFields

ARRAY

style

STRING

height

STRING

text

STRING

hint

STRING

textarea

OBJECT

id

STRING

textfield

OBJECT

image

STRING

title

STRING

label

OBJECT

top

STRING

left

STRING

value

STRING

max

NUMERIC

visible

BOOLEAN

maxLength

NUMERIC

weight

STRING

min

NUMERIC

width

STRING

opacity

STRING

window

OBJECT

option

OBJECT

32

Para cada DslType do tipo primitivo OBJECT criado, foi necessrio especificar quais
DslTypeItems compe o mesmo. O trecho de cdigo abaixo faz parte do arquivo de
definio da DSL org.dsle.FormUI.dsl e mostra como exemplo a definio do tipo
formfield dos qual os demais tipos so estendidos. O arquivo completo de definio
da DSL pode ser observado no Anexo I.
{
"name": "formfield",
"primitiveType": "OBJECT",
"items": [{
"type": "align",
"required": false
}, {
"type": "background",
"required": false
}, {
"type": "border",
"required": false
}, {
"type": "bottom",
"required": false
}, {
"type": "color",
"required": false
}, {
"type": "enabled",
"required": false
}, {
"type": "font",
"required": false
}, {
"type": "height",
"required": false
}, {
"type": "id",
"required": true
}, {
"type": "left",
"required": false
}, {
"type": "opacity",
"required": false
}, {
"type": "readOnly",
"required": false
}, {
"type": "right",
"required": false
}, {
"type": "size",
"required": false
}, {
"type": "style",
"required": false
}, {
"type": "top",
"required": false
}, {
"type": "visible",
"required": false
}, {
"type": "weight",
"required": false
}, {
"type": "width",
"required": false
}]
}

O objeto main da linguagem especfica de domnio FormUI o DslType form

que tem como propriedade um identificador (propriedade id), um ttulo (propriedade
title) e um array de campos (propriedade formFields).
32

Depois da criao da DSL, foram criados dois templates para gerao de cdigo, um
que gera um arquivo de marcao HTML, para o framework jQuery Mobile e outro que
gera um arquivo JavaScript, para ser utilizado no Appcelerator Titanium. Esses
templates podem visualizados no Anexo II.
De maneira a auxiliar a gerao de cdigo pelos templates foram desenvolvidos dois
plug-ins, um que transforma os objetos (DSLType) em notaes HTML, sendo chamado
diretamente do template para jQuery Mobile, e outro que transforma os objetos
(DSLType) em notaes JavaScript, sendo chamado diretamente do template para
Appcelerator Titanium. Esses plug-ins podem visualizados no Anexo III.
Para testar o ganho de produtividade, foi solicitado a um desenvolvedor front-end,
apenas familiarizado com marcaes HTML, que utilizasse a ferramenta para escrever
um programa DSL que descrevesse um formulrio de criao de conta em um servio,
seguindo as diretrizes da DSL especificada. Foram passados ao desenvolvedor front-end
os campos necessrios e os atributos de cada um deles, definidos pelo designer de
interfaces. O programa DSL foi nomeado create_account.json e continha o seguinte
cdigo:

{
"language":"org.dsle.FormUI",
"main": {
"id":"winCreateAccount",
"title": "Create Account",
"form": {
"id": "frmCreateAccount",
"formItems": [{
"type":"label",
"id": "lblEmail",
"text":"E-mail:",
"for": "email"
},{
"type":"textfield",
"id":"email",
"hint": "enter your e-mail"
},{
"type":"label",
"id": "lblPassword",
"text":"Password:",
"for": "password"
},{
"type":"textfield",
"id":"password",
"hint": "enter your password",
"password": true
},{
"type":"checkbox",
"id":"accept",
"text": "I accept this terms.",
"checked": false
},{
"type":"button",
"id":"btCreateAccount",
"text": "create account"
}
]
}
}
}

Ao clicar no boto Generate da ferramenta, foram gerados dois arquivos:

create_account.html, contendo o arquivo HTML para o framework jQuery Mobile e
titanium_create_account.js, contendo cdigo JavaScript para criao do formulrio
33

utilizando Appcelerator Titanium. A Figura 14 mostra o resultado final dos formulrios

gerados pela execuo da DSL. O cdigo gerado pode ser observado no Anexo IV.

Figura 14. Formulrio de Criao de Conta

Posteriormente foi solicitado ao prprio designer, que olhando o programa DSL

original, inclusse um campo para o usurio digitar seu nome completo. O cdigo
abaixo foi adicionado e o resultado pode ser observado na Figura 15.

},{

"type":"label",
"id": "lblFullname",
"text":"Full Name:",
"for": "fullname"
"type":"textfield",
"id":"fullname",
"hint": "enter your full name"

34

Figura 15. Formulrio de Criao de Conta Alterado

Devido a limitaes relacionadas ao prazo de realizao do experimento, ficou fora do

escopo deste projeto a realizao de um experimento formal, a ser executado como
trabalho futuro, com um planejamento de coleta de mtricas, avaliaes de tempo e
curva de aprendizado e com ambiente configurado para a realizao do mesmo.
Sobretudo, foi possvel observar a utilidade da DSL criada uma vez que o
desenvolvedor front-end precisou escrever uma nica vez, usando menos linhas de
cdigo, e produzindo cdigo fonte para mais de uma plataforma ao mesmo tempo,
mesmo no tendo conhecimento em uma delas. Alm disso, aumentar a abstrao
permitiu que outra pessoa, que no conhecia detalhes de implementao em nenhuma
das plataformas, mas que era conhecedora do domnio, realizasse modificaes no
programa DSL sem nenhuma dificuldade e consequentemente nos cdigos fontes
gerados.

6. Consideraes finais e trabalhos futuros

Adotar uma abordagem DSL pode trazer ganhos reais de produtividade por habilitar a
gerao de cdigo e o reuso. Aumentar o nvel de abstrao para o idioma do domnio
de aplicao possibilita que usurios com conhecimento do domnio mas sem
conhecimento em programao possam escrever programas DSL, por adotar uma
linguagem mais direta e intuitiva. O processo de desenvolvimento de uma linguagem
especfica custoso, no entanto, este processo pode ser acelerado e ter seus custos
reduzidos com a utilizao de ferramentas especializadas, que podem variar de um
simples interpretador a um ambiente integrado de desenvolvimento [3][4].
Sobretudo, existem poucas ferramentas para o desenvolvimento e implementao de
linguagens especficas de domnio, quando comparadas as ferramentas para linguagens
de programao de propsito geral. Estas ferramentas geralmente possuem
35

dependncias a nvel de sistemas operacionais e precisam ser instaladas para que

possam ser executadas.
Este artigo apresentou a ferramenta DSL Encoder, um ambiente integrado de
desenvolvimento de linguagens especficas de domnio que tem a web como
plataforma[5], de cdigo aberto, que pode ser estendido e aperfeioado por seus
usurios em tempo de execuo atravs da colaborao no desenvolvimento de novas
DSLs, templates, plug-ins e atravs da integrao com outros servios da web [18].
O objetivo do DSL Encoder facilitar o acesso a este tipo de ferramenta, possibilitando
que usurios conectados a internet, possam por em prtica os conceitos de gerao de
cdigo e reuso de software sem a necessidade de instalar nenhum software adicional
alm do navegador.
Como trabalhos futuros ficam as seguintes atividades: Realizar um experimento formal
do uso da ferramenta; Realizar um estudo comparativo com outras ferramentas de
desenvolvimento de DSL; Criao de plug-ins que implementem o sistema de arquivos
da ferramenta utilizando APIs de servios de cloud storage como Dropbox [41],
SugarSync [42], Google Drive [43], entre outros, possibilitando o armazenamento dos
arquivos diretamente na nuvem; e a Criao de plug-ins que implementem
versionamento de cdigo utilizando APIs de servios de repositrio de cdigo fonte
como o GitHub [44].

7. Referncias
[1] Barreto, C. G. (2006). Agregando Frameworks de Infra-Estrutura em uma
Arquitetura Baseada em Componentes: Um Estudo de Caso no Ambiente
AulaNet. Rio de Janeiro.
[2] Herrington, Jack (2003). Code-Generation Techniques for Java. Online
http://www.onjava.com/pub/a/onjava/2003/09/03/generation.html.
[3] Van Deursen, A., Klint, P., & Visser, J. (2000). Domain-specific languages: an
annotated bibliography. ACM Sigplan Notices, 35(6), 26-36.
[4] Mernik, M., Heering, J., & Sloane, A. M. (2005). When and how to develop
domain-specific languages. ACM computing surveys (CSUR), 37(4), 316-344.
[5] Oreilly, T. (2007). What is Web 2.0: Design patterns and business models for
the next generation of software. Communications & strategies, (1), 17.
[6] Taivalsaari, A., & Mikkonen, T. (2011, August). The web as an application
platform: The saga continues. In Software Engineering and Advanced
Applications (SEAA), 2011 37th EUROMICRO Conference on (pp. 170-174).
IEEE.
[7] Meira, S. R., Buregio, V. A., Nascimento, L. M., Figueiredo, E., Neto, M.,
Encarnao, B., & Garcia, V. C. (2011, July). The Emerging Web of Social
Machines. In Computer Software and Applications Conference (COMPSAC),
2011 IEEE 35th Annual (pp. 26-27). IEEE.

36

[8] Yu, S., & Woodard, C. J. (2009, January). Innovation in the programmable web:
Characterizing the mashup ecosystem. In Service-Oriented ComputingICSOC
2008 Workshops (pp. 136-147). Springer Berlin Heidelberg.
[9] Kelly, S., & Tolvanen, J. P. (2008). Domain-specific modeling: enabling full
code generation. Wiley-IEEE Computer Society Press.
[10] Ross, D. T. (1978, June). Origins of the APT language for automatically
programmed tools. In History of programming languages I (pp. 279-338). ACM.
[11] Knuth, D. E. (1964). Backus normal form vs. backus naur form.
Communications of the ACM, 7(12), 735-736.
[12] Fowler, M. (2010). Domain-specific languages. Addison-Wesley Professional.
[13] Bray, T., Paoli, J., Sperberg-McQueen, C. M., Maler, E., & Yergeau, F. (1997).
Extensible markup language (XML). World Wide Web Journal, 2(4), 27-66.
[14] JavaScript Object Notation JSON. Online http://www.json.org/.
[15] Ben-Kiki, O., Evans, C., & Ingerson, B. (2001). YAML Ain't Markup
Language (YAML) Version 1.1. Working Draft 2008-05, 11.
[16] Fowler, M. (2005). A language workbench in action-MPS. Online
http://martinfowler.com/articles/mpsAgree.html.
[17] Maximilien, E. M., Ranabahu, A., & Gomadam, K. (2008). An online platform
for web apis and service mashups. Internet Computing, IEEE, 12(5), 32-43.
[18] Duvander, Adam (2012). 8,000 APIs: Rise of the Enterprise. Online
http://blog.programmableweb.com/2012/11/26/8000-apis-rise-of-the-enterprise/.
[19] Duvander, Adam (2012). The New API: Apps, Partners, Income. Online
http://blog.programmableweb.com/2012/06/13/the-new-api-apps-partnersincome.
[20] Fielding, R. (2000). Representational state transfer. Architectural Styles and the
Design of Netowork-based Software Architecture, 76-85.
[21] Duvander, Adam (2011). 1 in 5 APIs Say Bye XML. Online
http://blog.programmableweb.com/2011/05/25/1-in-5-apis-say-bye-xml/.
[22] Duvander, Adam (2012). 5,000 APIs: Facebook, Google and Twitter Are
Changing the Web. Online http://blog.programmableweb.com/2012/02/06/5000apis-facebook-google-and-twitter-are-changing-the-web/.
[23] Programmable
Web.
API
http://www.programmableweb.com/apis/.

Dashboard.

Online

[24] Duvander, Adam (2012). 6,000 APIs: Its Business, Its Social and Its
Happening
Quickly.
Online
http://blog.programmableweb.com/2012/05/22/6000-apis-its-business-its-socialand-its-happening-quickly.
[25] Brandon, Lorinda (2013). APIs as a Competitive Advantage. Disponvel em
http://blog.programmableweb.com/2013/01/09/apis-as-a-competitiveadvantage/.
37

[26] Maia,
Bruno.
DSL
JavaScript
https://github.com/brunoleaomaia/dsl.js.

Framework.

Online

[27] Raymond, E. (1999). The cathedral and the bazaar. Knowledge, Technology &
Policy, 12(3), 23-49.
[28] The BSD 2-Clause License. Online http://opensource.org/licenses/BSD-2Clause/.
[29] OReilly, Tim (1999). Lessons From Open-Source Software Development.
Communications of the ACM, 42(4), 32-37.
[30] The RedMonk (2012). Programming Language Rankings.
http://redmonk.com/sogrady/2012/09/12/language-rankings-9-12/.

Online

[31] World Wide Web Consortium (2011). HTML5 Specification. W3C Working
Draft. Online http://www.w3.org/TR/html5/.
[32] Raymond, D. R. (1992). Flexible text display with lector. Computer, 25(8), 4960.
[33] Ace - The High Performance Code Editor for the Web. Online
http://ace.ajax.org.
[34] D'souza, D. F., & Wills, A. C. (1998). Objects, components, and frameworks
with UML: the catalysis approach (Vol. 1). Reading: Addison-Wesley.
[35] JSON Templates. Online https://code.google.com/p/json-template/.
[36] JavaScript Template. Online https://github.com/blueimp/JavaScript-Templates/.
[37] Crespo, S., Fontoura, M., & Lucena, C. J. Using Viewpoints, Frameworks, and
Domain-Specific Languages to Enhance Software Reuse. In European Reuse
Workshop-ERW (Vol. 98).
[38] Wolfinger, R., Reiter, S., Dhungana, D., Grunbacher, P., & Prahofer, H. (2008,
February). Supporting runtime system adaptation through product line
engineering and plug-in techniques. In Composition-Based Software Systems,
2008. ICCBSS 2008. Seventh International Conference on (pp. 21-30). IEEE.
[39] jQuery Mobile: Touch-Optimized Web Framework for Smartphones & Tablets.
Online http://jquerymobile.com/.
[40] Appcelerator
Inc.
The
http://www.appcelerator.com/

Mobile

First

Platform.

Online

[41] Dropbox - File Storage Service. Online http://www.dropbox.com/.

[42] SugarSync - File Storage Service. Online http://www.sugarsync.com/.
[43] Google Drive - File Storage Service. Online http://drive.google.com/.
[44] GitHub - Online project hosting using Git. Online http://www.github.com/.

38

Anexo I Definio da DSL

org.dsle.FormUi.dsl
{
"id": "org.dsle.FormUI",
"description": "",
"name": "Forms",
"templates": [{
"id": "org.dsle.formUi.jQueryMobile",
"file": "org.dsle.formUi.jQueryMobile.tpl",
"prefix": "",
"suffix": "_mobile",
"extension": "html",
"engine": "JAVASCRIPT"
},{
"id": "org.dsle.formUi.Titanium",
"file": "org.dsle.formUi.Titanium.tpl",
"prefix": "",
"suffix": "",
"extension": "js",
"engine": "JAVASCRIPT"
}],
"types": [{
"name": "align",
"primitiveType": "STRING"
}, {
"name": "bottom",
"primitiveType": "STRING"
}, {
"name": "checked",
"primitiveType": "BOOLEAN"
}, {
"name": "color",
"primitiveType": "STRING"
}, {
"name": "enabled",
"primitiveType": "BOOLEAN"
}, {
"name": "family",
"primitiveType": "STRING"
}, {
"name": "for",
"primitiveType": "STRING"
}, {
"name": "height",
"primitiveType": "STRING"
}, {
"name": "hint",
"primitiveType": "STRING"
}, {
"name": "id",
"primitiveType": "STRING"
}, {
"name": "image",
"primitiveType": "STRING"
}, {
"name": "left",
"primitiveType": "STRING"
}, {
"name": "max",
"primitiveType": "NUMERIC"
}, {
"name": "maxLength",
"primitiveType": "NUMERIC"
}, {
"name": "min",
"primitiveType": "NUMERIC"
}, {
"name": "opacity",
"primitiveType": "STRING"
}, {

39

"name": "password",
"primitiveType": "BOOLEAN"
}, {
"name": "radius",
"primitiveType": "STRING"
}, {
"name": "readOnly",
"primitiveType": "BOOLEAN"
}, {
"name": "repeat",
"primitiveType": "STRING"
}, {
"name": "right",
"primitiveType": "STRING"
}, {
"name": "selected",
"primitiveType": "BOOLEAN"
}, {
"name": "size",
"primitiveType": "STRING"
}, {
"name": "style",
"primitiveType": "STRING"
}, {
"name": "text",
"primitiveType": "STRING"
}, {
"name": "title",
"primitiveType": "STRING"
}, {
"name": "top",
"primitiveType": "STRING"
}, {
"name": "value",
"primitiveType": "STRING"
}, {
"name": "visible",
"primitiveType": "BOOLEAN"
}, {
"name": "weight",
"primitiveType": "STRING"
}, {
"name": "width",
"primitiveType": "STRING"
}, {
"name": "background",
"primitiveType": "OBJECT",
"items": [{
"type": "color",
"required": false
}, {
"type": "image",
"required": false
}, {
"type": "repeat",
"required": false
}]
}, {
"name": "background",
"primitiveType": "OBJECT",
"items": [{
"type": "color",
"required": false
}, {
"type": "image",
"required": false
}, {
"type": "repeat",
"required": false
}]
}, {
"name": "border",
"primitiveType": "OBJECT",
"items": [{
"type": "color",
"required": false
}, {
"type": "width",
"required": false
}, {
"type": "radius",
"required": false
}]
}, {
"name": "font",

40

"primitiveType": "OBJECT",
"items": [{
"type": "family",
"required": false
}, {
"type": "size",
"required": false
}, {
"type": "style",
"required": false
}, {
"type": "weight",
"required": false
}]
}, {
"name": "formItems",
"primitiveType": "ARRAY",
"arrayType": "OBJECT",
"defaultType": "textfield"
}, {
"name": "formfield",
"primitiveType": "OBJECT",
"items": [{
"type": "align",
"required": false
}, {
"type": "background",
"required": false
}, {
"type": "border",
"required": false
}, {
"type": "bottom",
"required": false
}, {
"type": "color",
"required": false
}, {
"type": "enabled",
"required": false
}, {
"type": "font",
"required": false
}, {
"type": "height",
"required": false
}, {
"type": "id",
"required": true
}, {
"type": "left",
"required": false
}, {
"type": "opacity",
"required": false
}, {
"type": "readOnly",
"required": false
}, {
"type": "right",
"required": false
}, {
"type": "size",
"required": false
}, {
"type": "style",
"required": false
}, {
"type": "top",
"required": false
}, {
"type": "visible",
"required": false
}, {
"type": "weight",
"required": false
}, {
"type": "width",
"required": false
}]
}, {
"name": "label",
"primitiveType": "OBJECT",
"extends":"formfield",
"items": [{

41

"type": "text",
"required": true
},{
"type": "for",
"required": false
}]
}, {
"name": "textfield",
"primitiveType": "OBJECT",
"extends": "formfield",
"items": [{
"type": "hint",
"required": false
},{
"type": "maxLength",
"required": false
},{
"type": "password",
"required": false
},{
"type": "readOnly",
"required": false
},{
"type": "value",
"required": false
}]
}, {
"name": "textarea",
"primitiveType": "OBJECT",
"extends": "formfield",
"items": [{
"type": "hint",
"required": false
},{
"type": "maxLength",
"required": false
},{
"type": "readOnly",
"required": false
},{
"type": "value",
"required": false
}]
}, {
"name": "option",
"primitiveType": "OBJECT",
"extends":"formfield",
"items": [{
"type": "selected",
"required": false
},{
"type": "text",
"required": true
},{
"type": "value",
"required": false
}]
}, {
"name": "selectOptions",
"primitiveType": "ARRAY",
"arrayType": "OBJECT",
"defaultType": "option"
}, {
"name": "select",
"primitiveType": "OBJECT",
"extends":"formfield",
"items": [{
"type": "value",
"required": false
},{
"type": "selectOptions",
"required": true
}]
}, {
"name": "checkbox",
"primitiveType": "OBJECT",
"extends":"formfield",
"items": [{
"type": "text",
"required": true
},{
"type": "checked",
"required": true
},{
"type": "value",

42

"required": false
}]
}, {
"name": "slider",
"primitiveType": "OBJECT",
"extends":"formfield",
"items": [{
"type": "min",
"required": true
},{
"type": "max",
"required": true
},{
"type": "value",
"required": false
}]
}, {
"name": "button",
"primitiveType": "OBJECT",
"extends":"formfield",
"items": [{
"type": "text",
"required": true
}]
}, {
"name": "form",
"primitiveType": "OBJECT",
"extends":"formfield",
"items": [{
"type": "formItems",
"required": true
}]
}, {
"name": "window",
"primitiveType": "OBJECT",
"extends":"formfield",
"items": [{
"type": "form",
"required": true
}, {
"type": "title",
"required": true
}]
}],
"main": "window"
}

43

Anexo II Templates
org.dsle.FormUi.jQueryMobile.tpl
<!DOCTYPE html>
<html>
<head>
<title>{%=o.title%}</title>
<meta name="viewport" content="width=device-width, initial-scale=1">
<link rel="stylesheet" href="http://code.jquery.com/mobile/1.3.1/jquery.mobile1.3.1.min.css" />
<script src="http://code.jquery.com/jquery-1.9.1.min.js"></script>
<script src="http://code.jquery.com/mobile/1.3.1/jquery.mobile-1.3.1.js"></script>
</head>
<body>
<div data-role="page" id="{%=o.form.id%}">
<div data-role="header">
<h1>{%=o.title%}</h1>
</div>
<div data-role="content">
<form>
{%
for (var i = 0; i < o.form.formItems.length; i++) {
print('\t\t\t\t' + ide.formUi.getHtml(o.form.formItems[i]) + '\n',true)
}
%}
</form>
</div>
</div>
</body>
</html>

org.dsle.FformUi.Titanium.tpl
function {%=o.id%} () {
var main = Ti.UI.createWindow({
backgroundColor: '#fff'
});
var _{%=o.id%} = Ti.UI.createWindow({
backgroundColor: '#fff',
title: '{%=o.title%}'
});
var _{%=o.form.id%} = Ti.UI.createScrollView({
layout: 'vertical'
});
{%
for (var i = 0; i < o.form.formItems.length; i++) {
print('\t'+ide.formUi.getTitanium(o.form.formItems[i])+'\n', true)
print('\t_'+o.form.id+'.add(_'+o.form.formItems[i].id+');\n\n', true)
}
%}
_{%=o.id%}.add(_{%=o.form.id%});
if (Ti.Platform.osname == 'iphone') {
var navGroup = Ti.UI.iPhone.createNavigationGroup({
window:_{%=o.id%}
});
main.add(navGroup);
return main;
} else {
return _{%=o.id%};
}
}
module.exports = {%=o.id%};

44

Anexo III Plug-ins

org.dsle.FormUI.js
{
id: 'org.dsle.FormUI',
name: 'FormUI',
load: function() {
ide.formUi = ide.formUi || {};
ide.formUi.getHtmlTag = function(o) {
var html = '<'+o.tag, style='style="';
for (var i = 0; i < o.attrs.length; i++) {
html += ' '+o.attrs[i].name+'="'+o.attrs[i].value+'"';
};
for (var i = 0; i < o.style.length; i++) {
style += ' '+o.style[i].name+': '+o.style[i].value+';';
};
html += ' '+style+'"';
if (o.selfClose) {
html += '/>';
} else {
html += '>';
html += o.text || '';
html += '</'+o.tag+'>'
}
return html;
}
ide.formUi.getHtml = function(item) {
var html = '',
attrs = new Array();
style = new Array();
function _a(name, value){
attrs.push({name: name, value: value});
}
function _s(name, value){
style.push({name: name, value: value});
}
if (item.align) _s('text-align', item.align);
if (item.background && item.background.color) _s('background-color',
item.background.color);
if (item.background && item.background.image) _s('background-image', 'url(' +
item.background.image + ')');
if (item.background && item.background.repeat) _s('background-repeat',
item.background.image);
if (item.bottom) _s('margin-bottom', item.bottom);
if (item.border && item.border.color) _s('border-color', item.border.color);
if (item.border && item.border.width) _s('border-width', item.border.width);
if (item.border && item.border.radius) _s('border-radius', item.border.radius);
if (item.color) _s('color',item.color);
if (item.enabled === false) _a('disabled', 'disabled');
if (item.font && item.font.family) _s('font-family', item.font.family);
if (item.font && item.font.size) _s('font-size', item.font.size);
if (item.font && item.font.style) _s('font-style', item.font.style);
if (item.font && item.font.weight) _s('font-weight', item.font.weight);
if (item.id) _a('id',item.id);
if (item.hint) _a('placeholder', item.hint);
if (item.height) _s('height',item.height);
if (item.left) _s('margin-left', item.left);
if (item.opacity) _s('opacity', item.opacity);
if (item.readOnly) _a('readonly', 'readonly');
if (item.right) _s('margin-right', item.right);
if (item.top) _s('margin-right', item.top);
if (item.visible === false) _s('display', 'none');
if (item.width) _s('width', item.width);
switch(item.type) {
//LABEL
case 'label':
if (item.for) _a('for', item.for);
return this.getHtmlTag({
tag:'label',
attrs: attrs,
style: style,
text: (item.text) || '',
selfClose: false

45

});
break;
//TEXTFIELD
case 'textfield':
_a('type',((item.password)?'password':'text'));
if (item.value) _a('value', item.value);
if (item.maxLength) _a('maxlength', item.maxLength);
return this.getHtmlTag({
tag:'input',
attrs: attrs,
style: style,
selfClose: true
});
break;
//TEXTAREA
case 'textarea':
return 'var _'+item.id+';';
if (item.maxLength) _a('maxlength', item.maxLength);
return this.getHtmlTag({
tag:'textarea',
attrs: attrs,
style: style,
text: item.value || '',
selfClose: false
});
break;
//OPTION
case 'option':
return 'var _'+item.id+';';
if (item.value) _a('value', item.value);
if (item.selected) _a('selected', 'selected');
return this.getHtmlTag({
tag:'option',
attrs: attrs,
style: style,
text: item.text || '',
selfClose: false
});
break;
//SELECT
case 'select':
return 'var _'+item.id+';';
item.text = '';
for (var i = 0; i < item.selectOptions.length; i++) {
if (typeof item.value !== 'undefined') {
if (item.value === item.selectOptions[i].value)
item.selectOptions[i].selected = true;
}
item.selectOptions[i].type = 'option';
item.text += this.getHtml(item.selectOptions[i]);
};
return this.getHtmlTag({
tag:'select',
attrs: attrs,
style: style,
text: item.text || '',
selfClose: false
});
break;
//CHECKBOX
case 'checkbox':
_a('type', 'checkbox');
if (item.value) _a('value', item.value);
if (item.checked) _a('checked', 'checked');
return this.getHtmlTag({
tag: 'fieldset',
attrs: [],
style: [],
selfClose: false,
text: this.getHtmlTag({
tag:'input',
attrs: attrs,
style: style,
selfClose: true
}) + this.getHtmlTag({
tag:'label',
attrs:[{name: "for", value: item.id}],
style:[],
text: (item.text) || '',
selfClose: false

46

})
});
break;
//SLIDER
case 'slider':
_a('type', 'range');
if (item.value) _a('value', item.value);
if (item.max) _a('max', item.max);
if (item.min) _a('min', item.min);
return this.getHtmlTag({
tag:'input',
attrs: attrs,
style: style,
selfClose: true
});
break;
//BUTTON
case 'button':
_a('type','button');
if (item.text) _a('value', item.text);
return this.getHtmlTag({
tag:'input',
attrs: attrs,
style: style,
selfClose: true
});
break;

default:
return '<!-- TYPE ['+item.type+'] NOT FOUND -->';

}
}
}

org.dsle.FormUi.Titanium.js
{
id: 'org.dsle.FormUI.Titanium',
name: 'FormUI Titanium',
load: function() {
ide.formUi = ide.formUi || {};
ide.formUi.getTitaniumObject = function(o) {
var js = '';
js += 'var _'+o.id+' = Ti.UI.'+o.createFn+'('+JSON.stringify(o.config)+');'
return js;
}
ide.formUi.getTitanium = function(item) {
var config = {};
function _c(name, value){
config[name] = value;
}
if (item.align) _c('textAlign', item.align);
if (item.background && item.background.color) _c('backgroundColor',
item.background.color);
if (item.background && item.background.image) _c('backgroundImage',
item.background.image);
if (item.background && item.background.repeat) _c('backgroundRepeat',
item.background.repeat);
if (item.bottom) _c('bottom', item.bottom);
if (item.border && item.border.color) _c('borderColor', item.border.color);
if (item.border && item.border.width) _c('borderWidth', item.border.width);
if (item.border && item.border.radius) _c('borderRadius', item.border.radius);
if (item.color) _c('color',item.color);
if (item.enabled === false) _c('enabled', false);
if (item.font) _c('font', {});
if (item.font && item.font.family) config.font.fontFamily = item.font.family;
if (item.font && item.font.size) config.font.fontSize = item.font.size;
if (item.font && item.font.style) config.font.fontStyle, item.font.style;
if (item.font && item.font.weight) config.font.fontWeight, item.font.weight;
if (item.hint) _c('hintText', item.hint);
if (item.height) _c('height',item.height);
if (item.left) _c('left', item.left);

47

if
if
if
if
if
if

(item.opacity) _c('opacity', item.opacity);

(item.readOnly === true) _c('editable', false);
(item.right) _c('right', item.right);
(item.top) _c('top', item.top);
(item.visible === false) _c('visible', false);
(item.width) _c('width', item.width);

switch(item.type) {
//LABEL
case 'label':
_c('text', item.text || '');
return this.getTitaniumObject({
id: item.id,
createFn: 'createLabel',
config: config
});
break;
//TEXTFIELD
case 'textfield':
_c('passwordMask',(item.password));
if (item.value) _c('value', item.value);
if (item.maxLength) _c('maxlength', item.maxLength);
if (!item.border) _c('borderStyle', 'rounded');
return this.getTitaniumObject({
id: item.id,
createFn: 'createTextField',
config: config
});
break;
//TEXTAREA
case 'textarea':
if (item.value) _c('value', item.value);
if (item.maxLength) _c('maxlength', item.maxLength);
if (!item.border) _c('borderStyle', 'rounded');
return this.getTitaniumObject({
id: item.id,
createFn: 'createTextArea',
config: config
});
break;
//CHECKBOX
case 'checkbox':
var js = '';
_c('layout', 'horizontal');
_c('height', 'size');
js = this.getTitaniumObject({
id: item.id,
createFn: 'createView',
config: config
});
js += '\n\t';
js += this.getTitaniumObject({
id: '_'+item.id,
createFn: 'createSwitch',
config: { value: (item.checked) }
});
js += '\n\t';
js += this.getTitaniumObject({
id: '__'+item.id,
createFn: 'createLabel',
config: { text: item.text || '' }
});
js += '\n\t';
js += '_'+item.id+'.add(__'+item.id+');'
js += '\n\t';
js += '_'+item.id+'.add(___'+item.id+');'
return js;
break;
//SLIDER
case 'slider':
if (item.value) _c('value', item.value);
if (item.max) _c('max', item.max);
if (item.min) _c('min', item.min);
return this.getTitaniumObject({
id: item.id,
createFn: 'createSlider',
config: config
});
break;

48

//BUTTON
case 'button':
_c('title', item.text || '');
return this.getTitaniumObject({
id: item.id,
createFn: 'createButton',
config: config
});
break;

default:
return 'var _'+item.id+'; //TYPE NOT FOUND';

}
}
}

49

Anexo IV Arquivos Gerados

create_account_mobile.html
<!DOCTYPE html>
<html>
<head>
<title>Create Account</title>
<meta name="viewport" content="width=device-width, initial-scale=1">
<link rel="stylesheet" href="http://code.jquery.com/mobile/1.3.1/jquery.mobile1.3.1.min.css" />
<script src="http://code.jquery.com/jquery-1.9.1.min.js"></script>
<script src="http://code.jquery.com/mobile/1.3.1/jquery.mobile-1.3.1.js"></script>
</head>
<body>
<div data-role="page" id="frmCreateAccount">
<div data-role="header">
<h1>Create Account</h1>
</div>
<div data-role="content">
<form>
<label id="lblEmail" for="email" style="">E-mail:</label>
<input id="email" placeholder="enter your e-mail" type="text" style=""/>
<label id="lblPassword" for="password" style="">Password:</label>
<input id="password" placeholder="enter your password" type="password" style=""/>
<fieldset style=""><input id="accept" type="checkbox" style=""/><label for="accept"
style="">I accept this terms.</label></fieldset>
<input id="btCreateAccount" type="button" value="create account" style=""/>
</form>
</div>
</div>
</body>
</html>

create_account.js
function winCreateAccount () {
var main = Ti.UI.createWindow({
backgroundColor: '#fff'
});
var _winCreateAccount = Ti.UI.createWindow({
backgroundColor: '#fff',
title: 'Create Account'
});
var _frmCreateAccount = Ti.UI.createScrollView({
layout: 'vertical'
});
var _lblEmail = Ti.UI.createLabel({"text":"E-mail:"});
_frmCreateAccount.add(_lblEmail);
var _email = Ti.UI.createTextField({"hintText":"enter your email","borderStyle":"rounded"});
_frmCreateAccount.add(_email);
var _lblPassword = Ti.UI.createLabel({"text":"Password:"});
_frmCreateAccount.add(_lblPassword);
var _password = Ti.UI.createTextField({"hintText":"enter your
password","passwordMask":true,"borderStyle":"rounded"});
_frmCreateAccount.add(_password);
var _accept = Ti.UI.createView({"layout":"horizontal","height":"size"});
var __accept = Ti.UI.createSwitch({"value":false});
var ___accept = Ti.UI.createLabel({"text":"I accept this terms."});
_accept.add(__accept);
_accept.add(___accept);
_frmCreateAccount.add(_accept);

50

var _btCreateAccount = Ti.UI.createButton({"title":"create account"});

_frmCreateAccount.add(_btCreateAccount);

_winCreateAccount.add(_frmCreateAccount);
if (Ti.Platform.osname == 'iphone') {
var navGroup = Ti.UI.iPhone.createNavigationGroup({
window:_winCreateAccount
});
main.add(navGroup);
return main;
} else {
return _winCreateAccount;
}
}
module.exports = winCreateAccount;

51