UNIVERSIDADE FEDERAL DE SANTA CATARINA
DEPARTAMENTO DE INFORMÁTICA E ESTATÍSTICA
CURSO DE BACHARELADO EM SISTEMAS DE INFORMAÇÃO
FRANÇOIS JUMES
LUIZ CLAUDIO ROSSAFA HONDA
LINGUAGEM ESPECÍFICA DE DOMÍNIO PARA
PROGRAMAÇÃO DE ROBÔS
Florianópolis, 2007
UNIVERSIDADE FEDERAL DE SANTA CATARINA
FRANÇOIS JUMES
LUIZ CLAUDIO ROSSAFA HONDA
LINGUAGEM ESPECÍFICA DE DOMÍNIO PARA
PROGRAMAÇÃO DE ROBÔS
Trabalho de conclusão de curso apresentado como requisito parcial para a obtenção do título de Bacharel em Sistemas de Informação pela Universidade Federal de Santa Catarina.
Florianópolis, 2007
UNIVERSIDADE FEDERAL DE SANTA CATARINA
DEPARTAMENTO DE INFORMÁTICA E ESTATÍSTICA
CURSO DE BACHARELADO EM SISTEMAS DE INFORMAÇÃO
ORIENTADOR:
João Bosco da Mota Alves
BANCA EXAMINADORA:
Paula Marien Albrecht Lopes
Karina de Brito Gamba
AGRADECIMENTOS
A Deus, que permitiu a conclusão desta importante etapa de nossas vidas.
Ao nosso orientador, Professor João Bosco da Mota Alves, por ter
contribuído com o direcionamento deste trabalho.
A Karina e Paula por terem aceitado prontamente o convite de fazerem
parte da banca examinadora.
Ao grande amigo Teodoro F. Holmes, por sua paciência e seus inúmeros
auxílios.
RESUMO
Este trabalho tem por objetivo explicar os conceitos básicos ligados ao
desenvolvimento de Linguagens Específicas de Domínio através de um exemplo
prático onde é criada a Linguagem RoboX para um
kit fictício de montagem de
robôs.
Estas linguagens – conhecidas como DSL (
Domain Specific Language),
além de tornarem as programações mais ágeis, simples e diminuírem a chance
de erros, também trazem o usuário final para perto do desenvolvimento,
permitindo que os dois, programador e usuário, conversem no mesmo idioma.
São apresentados também outras linguagens com o objetivo de demonstrar
que o conceito ligado à Linguagens Específicas de Domínio não é novo, mas
que a concepção destas linguagens vem se tornando cada vez mais simples e
acessíveis.
PALAVRAS-CHAVE: DSL, Domain Specific Language, Visual Studio SDK,
LISTA DE FIGURAS
Figura 1 - Interface do VS ... 23
Figura 2 - New Project ... 27
Figura 3 - Padrões pré-definidos ... 28
Figura 4 - Configuração dos arquivos ... 29
Figura 5 - Minimal Language... 30
Figura 6 - Domain Model ... 33
Figura 7 - Interface da DSL RoboX ... 35
Figura 8 - Fluxo Principal... 36
Figura 9 - Saída Som ... 36
Figura 10 - Saída Vídeo... 37
Figura 11 - Saída Motor ... 37
Figura 12 - Reinício... 37
Figura 13 - Loop Temperatura ... 38
Figura 14 - Loop Luz... 38
Figura 15 - Loop Som... 38
Figura 16 - Loop Número de Vezes ... 39
Figura 17 - Senão... 39
Figura 18 - SeEntão Temperatura... 39
Figura 19 - SeEntão Luz... 40
Figura 20 - SeEntão Som... 40
Figura 21 - Esperar Temperatura... 40
Figura 22 - Esperar Luz ... 41
Figura 23 - Esperar Som... 41
Figura 24 - Programa HelloWorld... 42
Figura 25 - Programa Geladeira ... 43
Figura 26 - Layout do Robô Separador ... 44
SUMÁRIO
RESUMO ...5
PALAVRAS-CHAVE ...Erro! Indicador não definido. LISTA DE FIGURAS ...6 1 INTRODUÇÃO...9 1.1 MOTIVAÇÃO ...9 1.2 OBJETIVOS ...9 1.2.1 Objetivo Geral ...9 1.2.2 Objetivo Específico...10 1.3 ESTRUTURA DO TRABALHO...10
2 LINGUAGEM ESPECÍFICA DE DOMÍNIO – DSL (DOMAIN-SPECIFIC LANGUAGE) ...11
2.1 CONCEITO...11
2.2 EXEMPLOS...12
2.2.1 SQL...14
2.2.1.1 Linguagem de Definição de Dados ...14
2.2.1.2 Linguagem de Manipulação de Dados ...15
2.2.1.3 Linguagem de Controle de Dados ...15
2.2.1.4 Linguagem de Consulta de Dados...16
2.2.2 HTML...17
2.2.2.1 Etiquetas...18
2.2.3 Wizard UIP...Erro! Indicador não definido. 2.3 VANTAGENS ...19
2.4 DESVANTAGENS...20
2.5 IMPLEMENTAÇÃO ...20
3 VISUAL STUDIO 2005 SDK 4.0 ...22
3.1 DSL TOOLS ...23
4 DSL PARA PROGRAMAÇÃO DE ROBÔS – ROBOX...26
4.1 ANÁLISE...26
4.2.2 Modelo de Domínio ...31
4.3 UTILIZAÇÃO...35
4.3.1 Interface ...35
4.3.2 Componentes ...35
4.3.2.1 Componente Fluxo Principal...36
4.3.2.2 Componentes de Saída ...36 4.3.2.2.1 Saída Som...36 4.3.2.2.2 Saída Vídeo ...36 4.3.2.2.3 Saída Motor ...37 4.3.2.3 Componentes de Loop...37 4.3.2.3.1 Reinício ...37 4.3.2.3.2 Loop Temperatura ...37 4.3.2.3.3 Loop Luz ...38 4.3.2.3.4 Loop Som ...38
4.3.2.3.5 Loop Número de Vezes...38
4.3.2.4 Componentes SeEntão...39 4.3.2.4.1 Senão ...39 4.3.2.4.2 SeEntão Temperatura ...39 4.3.2.4.3 SeEntão Luz ...39 4.3.2.4.4 SeEntão Som ...40 4.3.2.5 Componentes Esperar...40 4.3.2.5.1 Esperar Temperatura ...40 4.3.2.5.2 Esperar Luz ...41 4.3.2.5.3 Esperar Som ...41 4.4 EXEMPLOS DE PROGRAMAS...41 4.4.1 Programa HelloWorld.rob ...41 4.4.2 Programa Geladeira.rob...42 4.4.3 Programa SeparadorDeBolinhas.rob...43 5 CONCLUSÃO ...46 REFERÊNCIAS BIBLIOGRÁFICAS ...47
1 INTRODUÇÃO
1.1 MOTIVAÇÃO
Um dos fatores mais importantes para o sucesso de um software é a facilidade de automação de tarefas pelo usuário final, ou seja, a flexibilidade para definir rotinas personalizadas para a execução de determinadas tarefas. Porém, na maioria dos casos, as mudanças acabam passando pela equipe de análise e desenvolvimento, o que torna o processo de alteração difícil e demorado.
Para contornar esta deficiência, têm surgido vários exemplos de abordagens baseadas na incorporação de novas linguagens mais simples em outras já existentes. A idéia é permitir que o usuário possa intervir no processo de adequação do software às suas necessidades sem passar pela equipa original que o desenvolveu. Basicamente, é dar possibilidades ao utilizador final (usuário da DSL, que poderá criar programas para o usuário final) para que ele possa adaptar a aplicação à evolução das suas necessidades. Como a aplicação é desenvolvida para resolver um determinado problema, o usuário pode adaptar a aplicação apenas dentro daquele contexto, daí a designação de linguagem específica de domínio.
Apesar de ser uma área recente, alguns dos princípios das DSL já têm uma longa história. Embora os princípios sejam promissores, algumas questões ainda devem ser consideradas na adoção das DSL, como: a dificuldade em encontrar o âmbito correto de uma DSL; o custo do desenho, implementação e manutenção da DSL; a dificuldade no balanceamento entre as construções específicas de domínio e as de programação genérica da linguagem.
1.2 OBJETIVOS
1.2.1 Objetivo Geral
O trabalho proposto neste projeto consistirá em desenvolver, utilizando a ferramenta Visual Studio DSL Tools, uma linguagem específica de domínio para programação de robôs, que seja de fácil utilização, independente do grau de complexidade com o qual o robô foi construído fisicamente.
1.2.2 Objetivo Específico
Pretende-se demonstrar que a utilização de DSL pode melhorar o grau de flexibilidade, manutenção e evolução das aplicações. Espera-se alcançar este objetivo através do:
• Estudo dos fundamentos de DSL presente em linguagens conhecidas • Construção de uma DSL básica para um kit hipotético de robótica. • Criação de programas na DSL criada.
Justamente por ser uma DSL a linguagem criada oferece uma interface intuitiva e fácil de aprender, abstraindo tudo o que não é relevante para o objetivo final: “Como o robô deve agir”. Sendo assim, o usuário desta linguagem não precisa se preocupar em criar classes, objetos, protocolos de comunicação, etc. tornando a programação muito mais rápida, prazerosa e menos suscetível a erros.
1.3 ESTRUTURA DO TRABALHO
No capítulo 2 deste documento apresenta-se um levantamento sobre o estado atual das linguagens específicas de domínio. No capítulo 3 é apresentada a ferramenta e as etapas utilizadas para o desenvolvimento. Por fim, dedica-se um capítulo para esclarecer a linguagem e mostrar aplicações criadas com ela.
2 LINGUAGEM ESPECÍFICA DE DOMÍNIO – DSL (DOMAIN-SPECIFIC LANGUAGE)
2.1 CONCEITO
Uma linguagem específica de domínio, ou DSL (Domain-Specific Language), é uma linguagem de programação, ou uma linguagem de especificação executável, que fornece através de notações e de abstrações apropriadas, um poder de expressividade focado, e geralmente restrito em um determinado domínio de problema [Deursen, 2000]. As DSL surgiram naturalmente, como uma forma de simplificar a programação em determinados casos.
A visão de especialização das linguagens específicas de domínio normalmente implica que sejam declarativas e sejam vistas como linguagens de especificação, assim como linguagens de programação [Deursen, 2000]. Particularmente, esta característica de ser específica é normalmente conseguida através de notações e abstrações apropriadas a um particular domínio de problema. Alguns autores defendem que as DSL são linguagens que permitem especificar estereótipos de tarefas computacionais seja em domínios de aplicação especializados ou em terminologia familiar aos especialistas do domínio [Kieburtz, 2001].
Segundo [Thibault, 1998] e [Hudak, 1998] uma linguagem específica de domínio é uma linguagem de programação adequada para um domínio de aplicação particular. Uma DSL deve possuir a capacidade de desenvolver aplicações completas para um domínio específico. Deve buscar a semântica de um determinado domínio de aplicação, ou seja, uma DSL não é necessariamente genérica. As linguagens específicas de domínio são linguagens de programação com detrimento da generalidade em favor da aproximação a uma determinada área de problemas.
Embora necessite um investimento inicial de análise e desenho do domínio, logo que uma DSL é criada, esta pode ser usada e reutilizada pra uma diversidade de problemas no domínio. Dependendo do ponto de vista, uma DSL é um meio para capturar, representar e reforçar o desenho, em um formato que encoraje a reutilização [Bragança, 2002].
Um compilador de linguagem específica, que gera as aplicações com base nestas linguagens, suporta muitas DSL. Neste caso, o ‘compilador de DSL’ é tido como o gerador de aplicações [Cleveland, 1988], e a DSL como a linguagem específica da aplicação. Outras linguagens específicas de domínio, como o ASDL [Wang, 1997] ou o YACC [Bentley, 1986],
componentes ou bibliotecas. Uma terminologia comum para DSL orientada à construção de sistemas para processamento de dados de negócios é o de linguagem de 4ª geração. O exemplo mais conhecido deste tipo de linguagem é o SQL [Pressman, 1994].
A programação do utilizador final (end-user programming) está relacionada com a programação específica de domínio, porque ocorre quando o usuário final desta DSL executa tarefas simples de programação, utilizando scripting ou linguagem de macros. Um exemplo é a linguagem de macro Excel para programação de folhas de cálculo.
2.2 EXEMPLOS
De modo geral, a DSL é especializada para um determinado conjunto de problemas que compartilham características que compensem ser tratadas como um todo. Como exemplo temos linguagens para:
• Geração de compiladores: o LEXX o YACC • Gráficos 3D: o VRML o OpenGL • Computação simbólica: o Mathematica o Maple • Processamento de textos: o PERL o AWK
• Desenho assistido por computador: o AutoLisp
• Desenho de figuras: o PIC
• Controle de robôs:
o Yampa
• Controle de banco de dados:
• Descrição de hardware:
o VHDL
• Documentos com ligações:
o HTML
o SGML
• Preparação de documentos:
o TeX
o Látex
• Scripting de interface gráfica o Tcl/Tk
Algumas linguagens mais genéricas também podem ser classificadas como DSL, por exemplo, o Prolog e as linguagens funcionais como o Haskell e o ML.
Pelo fato das DSL serem bastante específicas, é bastante provável que tenhamos um conhecimento limitado das DSL existentes, visto que grande parte destas linguagens encontram-se escondidas do público, isso ocorre devido à sua especificidade as tornar propriedade das aplicações ou empresas que as desenvolveram. Segundo [Deursen, 2000], existem centenas de DSL em utilização.
As DSL são agrupadas nas seguintes áreas [Deursen, 2000]: • Sistemas de Software
Especialização de sistemas operacionais [Pu, 1987], descrição e análise de árvores de sintaxe abstratas [Crew, 1997], protocolos de coerência de cache [Chandra, 1999], especificação de drivers de dispositivos de vídeo [Thibault, 1999] e estruturas de dados em C [Smaragdakis e Batory, 1997].
• Engenharia de Software
Produtos financeiros [Deursen, 1997], bases de dados [Horowitz, 1985], controle e coordenação de comportamento [Bertrand e Augeraud, 1999] e arquiteturas de software [Medvidovic e Rosenblum, 1997].
• Multimídia
Manipulação de imagem [Stevenson e Fleck, 1997], computação para a Internet [Cardelli e Davies, 1999], desenho [Kamin e Hyatt, 1997] e animação 3D [Elliott, 1999].
Protocolos de comunicação [Basu, 1997], linguagens para verificação de modelos [Klarlund e Schwartzbach, 1999], switches de telecomunicação [Ladd e Ramming, 1994], esignature computing [Bonachea, 1999].
• Diversos
Controle de autômatos [Peterson, 1999], simulação [Bruce, 1997], agentes móveis [Gray, 1995], resolução de equações diferenciais [Dinesh, 1998] e desenho de hardware digital [Jennings e Beuscher, 1999].
2.2.1 SQL
SQL (Structured Query Language), ou Linguagem Estruturada para Consulta, é uma linguagem declarativa, inspiradas na álgebra relacional, utilizada para se fazer pesquisa em banco de dados.
A linguagem SQL acabou tornando-se um padrão para banco de dados. Isto foi possível graças a sua simplicidade de uso. Ela difere de outras linguagens para consulta a banco de dados por especificar a forma do resultado e não o caminho a ser utilizado para se chegar a ele. É por tanto uma linguagem declarativa, ou seja, não procedural. Isto facilita o aprendizado aos que iniciam na linguagem, uma das características das DSL.
O SQL, mesmo padronizado pela ANSI e ISO, possui muitas variações e extensões criadas pelos diferentes fabricantes de sistemas que gerenciam bases de dados. Normalmente a linguagem pode ser migrada de uma plataforma para outra sem grandes mudanças estruturais.
A linguagem SQL pode ser subdividida nos seguintes elementos de linguagem: definição de dados, manipulação de dados, controle de dados e consultas. Sendo que as definições abaixo e também as definições relacionadas a HTML, que são expostas na seqüência, são traduções livres feitas da própria padronização ANSI/ISO.
2.2.1.1 Linguagem de Definição de Dados
Como primeiro grupo de comandos temos a Linguagem de Definição de Dados, ou DDL (Data Definition Language). Uma DDL permite ao usuário definir esquemas de banco de dados, tabelas ou índices. A maioria dos bancos de dados de SQL comerciais tem extensões proprietárias no DDL.
Os comandos básicos da DDL são:
Create database nome_BD
Create [unique] index nome_índice on [nome_tabela | nome_visão] (nome_atributo
1 [{, nome_atributo n }])
• DROP – Apaga um objeto do banco de dados.
Drop table nome_tabela
Drop index nome_índice on nome_tabela
Para as tabelas, ainda é possível fazer alterações. Alguns sistemas de banco de dados usam o comando ALTER, que permite ao usuário alterar um objeto, por exemplo, adicionando uma coluna a uma tabela existente.
Alter table nome_tabela
add [column] nome_atributo 1 tipo 1 [{, nome_atributo n tipo n }]
2.2.1.2 Linguagem de Manipulação de Dados
Os elementos da Linguagem de Manipulação de Dados, ou DML (Data Manipulation Language), são utilizados para inclusão, exclusão e alteração de tuplas. E é uma linguagem não-procedural, especificandoo que fazer e não o como fazer.
• SELECT – É o comando mais usado do DML, comanda e permite ao usuário especificar uma consulta como uma descrição do resultado desejado. A questão não especifica como os resultados deveriam ser localizados.
select lista_atributos from lista_tabelas [where condição]
• INSERT – Usada para inclusão de tuplas em uma tabela existente.
insert into nome_tabela [(lista_atributos)] values (lista_valores)
• UPDATE – Para alteração de tuplas de tabela existente.
update nome_tabela
set nome_atributo 1 = Valor [{, nome_atributo n = Valor}]
[where condição]
• DELETE – Permite exclusão de tuplas existentes de uma tabela.
delete from nome_tabela [where condição]
O terceiro grupo é o DCL (Data Control Language), ou Linguagem de Controle de Dados, que controla os aspectos de autorização de dados e licenças de usuários para controlar quem tem acesso para ver ou manipular dados dentro do banco de dados.
• GRANT – Autoriza ao usuário diferentes níveis de operações.
• REVOKE – Remove ou restringe a capacidade de um usuário de executar operações. • COMMIT – Salva os dados das mudanças permanentemente.
• ROLLBACK – Desfaz as mudanças nos dados feitas após o último COMMIT.
COMMIT e ROLLBACK interagem com áreas de controle como transação e locação. Ambos terminam qualquer transação aberta e liberam qualquer cadeado ligado a dados.
2.2.1.4 Linguagem de Consulta de Dados
É a parte mais utilizada. O comando SELECT é composto de várias cláusulas e opções, possibilitando elaborar consultas das mais simples as mais elaboradas.
As cláusulas são condições de modificação utilizadas para definir os dados que deseja selecionar ou modificar em uma consulta.
• FROM – Utilizada para especificar a tabela da qual se vai selecionar os registros. • DISTINCT – Elimina duplicatas no resultado da consulta (tabela ?…coleção)
• WHERE – Utilizada para especificar as condições que devem reunir os registros que serão selecionados.
• [NOT] LIKE – Utilizado na comparação de um modelo e para especificar registros de um banco de dados.
• IS [NOT] NULL – Testam valores nulos de atributos
• [NOT] BETWEEN valor1 AND valor2 – Busca de atributos cujo valor encontra-se em um intervalo desejado. Válido para atributos com domínios ordinais.
• UNION – Permite a união de duas tabelas (compatíveis).
• [NOT] EXISTS – Processa a subconsulta na avaliação de cada tupla da consulta externa. Atributos do resultado da subconsulta são irrelevantes. Importa apenas saber se existem tuplas na resposta da subconsulta. A cláusula exists implementa o quantificador existencial do cálculo relacional.
• ORDER BY – Ordena o resultado da consulta. A ordem de declaração dos atributos na lista de atributos indica a precedência de ordenação.
• GROUP BY – Organiza o resultado de uma consulta em grupos (por um ou mais valores de atributos), a partir do qual é possível utilizarfunções de agregação.
• HAVING – Especifica condições para a formação de um grupo. Esta cláusula só existe associada à cláusula group by.
Cláusulas para tratamento de subconsultas:
• [NOT] IN – Relação de pertinência entre ?Yelemento e ?Yconjunto. • ANY – Permite outras formas de comparação elemento-conjunto.
• ALL – Condição a ser satisfeita para todos os elementos de um conjunto. Funções de agregação:
• AVG – Utiliza para calcular a media aritmética dos valores de atributos.
• COUNT – Contador de ocorrências. Utilizada para devolver o número de registros da seleção.
• SUM – Somador de valores de atributos.
• MAX – Utilizada para devolver o valor mais alto de um dos atributos. • MIN – Utilizada para devolver o valor mais baixo de um dos atributos.
Aplicam-se sobre uma coleção de tuplas, tendo como parâmetro um nome de atributo da tabela, para obter um único valor como resultado. Com exceção da função Count, todas as demais funções exigem domínios numéricos para o atributo utilizado como parâmetro.
Operadores Lógicos:
• AND – Avalia as condições e devolve um valor verdadeiro caso ambos seja corretos. • OR – Avalia as condições e devolve um valor verdadeiro se algum seja correto. • NOT – Negação lógica. Devolve o valor contrário da expressão.
2.2.2 HTML
O HTML (HyperText Markup Language) é uma linguagem utilizada para se definir as páginas web. Trata-se basicamente de um conjunto detags (etiquetas) que servem para definir a forma com que o texto e outros elementos da página serão apresentados. Podemos dizer que
o HTML é a linguagem que os navegadores usam para mostrar as páginas ao usuário, sendo hoje em dia a interface mais usada na internet.
Por ser uma linguagem de programação de fácil aprendizagem, possibilita que qualquer pessoa, mesmo que não tenha experiência com programação, consiga criar um website, sendo possível, em pouco tempo, dominar sua linguagem. Com o HTML é possível incluir textos, imagens e áudios, combinando-os de diversas maneiras, e também é possível a introdução de apontamentos para outras páginas por meio doslinks.
A primeira versão do HTML foi definida com regras sintáticas flexíveis, o que ajudou aqueles sem muita familiaridade com publicação na internet. Atualmente a sintaxe do HTML é bem mais rígida, resultando em um código muito mais preciso. Apesar disso, os navegadores atuais ainda conseguem interpretar estas páginas web que possuem um código HTML inválido.
2.2.2.1 Etiquetas
O HTML é uma linguagem que tem como base da sua sintaxe um elemento chamado etiqueta (tag). Estes são apresentados entre sinais de menor, <, e maior, >, e são os comandos de formatação da linguagem. As etiquetas apresentam frequentemente duas partes:
• Abertura <tag> • Fechamento </tag>
Tudo que estiver incluído entre estas tags sofrerá as modificações que são caracterizadas por ela. As tags servem para definir a formatação de uma parte deste documento, e desta forma é feita a marcação de onde começa e termina o texto com esta formatação específica.
Umatag é formada por valores, atributos e comandos. O atributo modifica o resultado padrão do comando e o valor serve para caracterizar essa mudança.
Além disto, um documento HTML tem que estar delimitado pela tag <html> e </html>. As tags não são case-sensitive podendo então serem escritas com qualquer tipo de combinação entre letras minúsculas e maiúsculas. Ou seja, <HTml> ou <HtMl> são consideradas como sendo a mesma etiqueta.
2.3 VANTAGENS
Umas das vantagens da DSL é o fato de serem menos obscuras e mais facilmente compreendidas pelos especialistas do domínio. Evidentemente, o projeto dessas linguagens exige um maior conhecimento do domínio do problema. Um bom projeto de DSL demanda muito mais conhecimento do que é preciso num desenvolvimento tradicional de software utilizando linguagem de propósito geral, neste caso procura-se resolver um simples problema em um domínio, enquanto que numa DSL é preciso criar uma abstração sobre um domínio completo [Bragança, 2002].
A vantagem de uma DSL com relação a uma linguagem de propósito geral, ou GPL (General Purpose Language), é que a mesma fornece abstrações e notações apropriadas já prontas (built-in). DSL são usadas em vários domínios de aplicações, apesar de não serem reconhecidas, como por exemplo, os arquivos de inicialização em Shell do Unix (.bashrc,
.cshrc).
Através da redução da distância conceitual entre o espaço do problema e a linguagem utilizada para exprimir o problema, a programação torna-se mais fácil, simples e de maior confiança [UTCAT]. A necessidade de escrever grandes quantidades de código é reduzida, resultando em um aumento de produtividade e reduzindo os gastos com manutenção. As DSL permitem que as soluções sejam expressas no nível de abstração do problema de domínio. Por conseqüência, os especialistas de domínio podem compreender, alterar, validar e até desenvolver programas em DSL.
A seguir, algumas das vantagens mais significativas creditadas às DSL:
• Os programas em DSL são comumente concisos, auto-documentados e podem ser reutilizados para vários propósitos [Ladd e Ramming, 1994];
• As DSL podem melhorar a produtividade, manutenção, clareza e portabilidade [Deursen e Klint, 1998];
• Permitem a conservação e reutilização do conhecimento de domínio incorporado na DSL [Deursen, 2000];
• As DSL melhoram o grau de testabilidade [Sirer e Bershad, 1999];
• Possibilitam a otimização e a validação em nível de domínio e não de programação genérica [Bruce, 1997];
• A reutilização do desenho de software, através da reutilização de geração automática de programas [Kieburtz, 2001].
2.4 DESVANTAGENS
Para além dos pontos fortes e vantagens da adoção das DSL, é possível identificar alguns aspectos que devem ser considerados. Os maiores problemas das DSL encontram-se na sua criação [UTCAT]. De fato, a criação de uma DSL envolve um investimento em compreensão da área do problema: – Quais as características compartilhadas mais importantes dos problemas no domínio? Como fazer para abstrair estas características? Quais as características que mudam conforme os problemas? Estas questões devem ser muito bem respondidas sob o risco de se desenvolver uma DSL que não corresponda claramente ao domínio do problema.
Outros autores também defendem que as grandes questões relativas às DSL se encontram na sua fase de concepção. As DSL podem apresentar as seguintes desvantagens [Deursen, 2000]:
• Dificuldade para identificar o âmbito correto de uma DSL; • Custo do desenho, de implementação e manutenção das DSL;
• A dificuldade em balancear entre as construções específicas de domínio e as de programação genérica da linguagem;
• Diminuição da eficiência se comparada com software escrito manualmente numa linguagem de programação genérica.
Alguns autores também se referem aos problemas no nível da utilização das DSL, sobretudo a limitada disponibilidade das DSL [Krueger, 1992]. O custo na educação dos utilizadores das DSL pode ser um fator significativo quando requer que os utilizadores mudem para uma sintaxe não muito familiar em suas especificações [Deursen, 2000].
2.5 IMPLEMENTAÇÃO
Em geral, o uso de DSL implica que uma grande quantidade de conhecimento sobre um dado domínio é movida do programa para o compilador e para o sistema run-time da linguagem de implementação. Portanto, o projeto de uma DSL exige uma maior compreensão sobre o domínio do problema. DSL só fazem sentido se elas contiverem uma abstração útil para uma classe completa de problemas que ocorrem no domínio correspondente. Assim, é
necessário que os especialistas de domínio sejam envolvidos no projeto de uma DSL, de modo que a linguagem resultante seja um veículo útil para a especificação realista de soluções de problemas no domínio correspondente [Bragança, 2002].
Segundo [Teixeira, 2003], a forma de se definir a semântica de uma DSL determina para quais propósitos ela poderá ser utilizada durante o processo de desenvolvimento. Se a semântica é definida informalmente, a DSL pode ser considerada boa para propósitos de documentação, de modo que facilite a comunicação entre desenvolvedores e clientes. Porém, não será considerada apropriada para ser usada como uma linguagem de especificação, pois a falta de uma semântica não ambígua a desqualifica para esse propósito. O uso de uma linguagem de propósito geral definida formalmente representará uma escolha mais apropriada para este caso (UML, por exemplo). Se a semântica da DSL for definida formalmente, através de uma notação matemática, então poderá ser utilizada como uma linguagem de especificação, já que existirá uma descrição não ambígua da semântica. Se ainda for fornecido suporte através de ferramentas, o programa na DSL poderá ser utilizado como parte da implementação do produto resultante, ou pelo menos em uma versão de protótipo.
Mesmo o conceito DSL já estando bastante definido, o seu papel no desenho, arquitetura e implementação de sistemas de software tem sido apenas reconhecido recentemente [Ramming, 1997]. Algumas DSL têm sido desenhadas como sendo linguagens de programação genéricas, e implementadas como sendo compiladores ou interpretadores usando as técnicas tradicionais para implementação de linguagem de programação. No entanto, o processo e economia para a realização de uma DSL é, de maneira mais comum que se imagina, muito diferente daquele que leva a implementação de linguagens tradicionais de programação. Em particular, as DSL são, por definição, parte de uma sistema mais abrangente e, muitas vezes, implementadas para um domínio de aplicação muito restrito. Os recursos disponíveis para o seu projeto e concepção são, por isso, limitados a uma pequena porcentagem daqueles que estão disponíveis para o sistema no qual estão inseridas. O esforço e talento que é atribuído ao desenho e implementação de uma DSL fazem surgir várias estratégias diferentes de reutilização. Estas estratégias de DSL resolvem um problema específico daquele desenho, mas pode ser aplicada em outros problemas parecidos.
Ciclo de vida para uma DSL [Deursen, 2000] • Análise
1 - Identificar o domínio do problema.
3 - Agregar este conhecimento num grupo de noções semânticas e operações sobre estas.
4 - Desenhar uma DSL que descreva com precisão aplicações nesse domínio. • Implementação
5 - Construir uma biblioteca que implemente as noções semânticas.
6 - Desenhar e implementar um compilador que traduza programas DSL numa seqüência de chamadas à biblioteca.
• Utilização
7 - Escrever programas DSL para todas as aplicações desejadas e compilá-los.
Os passos de implementação cinco e seis podem ser executados através das seguintes maneiras:
• Interpretação ou compilação, forma clássica de desenvolvimento de linguagens específicas de domínio. Para isto, pode-se utilizar ferramentas comuns para implementação de compiladores ou dedicadas à concepção de DSLs, como o Kephera, Kodiyak ou InfoWiz, entre outras. Neste caso, de se construir um compilador ou interpretador, a vantagem principal está no fato de que a implementação vai ser feita totalmente nos moldes da DSL e portanto não vai ser preciso adaptar-se as notações da linguagem, que é o que ocorre quando se encaixa uma DSL numa linguagem de programação existente. Outra vantagem seria que a detecção de erros e otimizações podem ser feitas no nível do domínio. A principal desvantagem é, sem dúvida, o custo para a construção de um compilador ou interpretador.
• Uma outra maneira seria a implementação baseada na extensão de uma linguagem de propósito geral, mantendo-se assim todas as características desta linguagem base.
3 VISUAL STUDIO 2005 SDK 4.0
O Visual Studio 2005 Software Development Kit (SDK) versão 4.0 contém ferramentas, documentação e exemplos para que desenvolvedores possam escrever e testar extensões para o Visual Studio. Uma destas ferramentas é o DSL Tools. A Interface principal do Visual Studio, já com o SDK instalado, pode ser visto abaixo, na figura 1.
Figura 1 - Interface do Visual Studio
3.1 DSL TOOLS
O Domain-Specific Language Tools possibilita aos desenvolvedores do Visual Studio criar seus próprios designers gráficos e geradores de código como os encontrados no próprio VS ou em qualquer outro ambiente de desenvolvimento gráfico,
Domain-Specific Language Tools consiste de:
• Um questionário de projeto que cria uma solução inteiramente configurada. Nesta solução, é possível definir um modelo de domínio que consiste em um designer e em um gerador de saída de texto. Se o projeto for compilado, uma solução teste abre em outra instância do Visual Studio de modo que se possa testar o design e o gerador da saída do texto.
• Um designer gráfico para definir e editar modelos de domínio.
• Definições do design em XML. O código para executar modelo é gerado destas definições, sendo possível definir um design sem escrever nenhum código.
• Um conjunto de geradores de código, que pegam as definição do modelo como entrada e produzem o código como a saída. Os geradores de código validam também o modelo de domínio e a definição do designer, mostrando erros e avisos.
• Um framework para definir geradores de saída de texto. Estes geradores pegam dados (modelos) que usam um modelo de domínio como entrada e geram o texto como saída que é baseado neste molde. Os parâmetros no molde são substituídos usando os resultados da execução de um script do Visual C# que está encaixado no molde.
Para projetar uma linguagem, começa-se usando o Domain-Specific Language Designer Wizard, que apresenta um questionário com os seguintes modelos de solução (que serão melhor explicados adiante):
• Diagramas de classe
• Diagramas de fluxo da tarefa • Linguagem Mínima
• Diagramas componentes
Como resultado da execução do questionário, o Visual Studio gera uma solução. A solução contem os seguintes projetos:
• Dsl
O projeto do Dsl define a linguagem específica de domínio e suas ferramentas de edição e processamento.
• DslPackage
O projeto DslPackage determina como as ferramentas da linguagem integraram com o Visual Studio.
É possível usar a linguagem do modelo ou modificá-la de acordo com suas próprias necessidades. Quase todo o código da solução é gerado dos arquivos da definição da linguagem, atualmente em DomainModel.tt. Conseqüentemente, a maioria das mudanças na linguagem é feita modificando-se estes arquivos.
O código é gerado dos modelos do texto (chamados tipicamente *.tt), que lêem a definição da linguagem e saída de código apropriado. Por este motivo, sempre que for modificado os arquivos de definição da linguagem, é preciso gerar novamente (“transformar”) todos os modelos.
Também é possível fornecer código adicional para refinar o comportamento do designer e para definir constraints sobre a linguagem; é possível fazer mudanças significativas modificando os modelos de texto.
Para testar a linguagem específica de domínio, basta dar um build e uma nova instância do Visual Studio (experimental build) se abre. É possível construir modelos de texto diretamente nesta instância debugadora, que irá ler o modelo e gerar arquivos a partir dele. Assim que for verificado que tudo está funcionando corretamente, pode-se criar um pacote de distribuição (arquivo .msi) para distribuir a linguagem.
4 DSL PARA PROGRAMAÇÃO DE ROBÔS – ROBOX
Um dos efeitos de se usar uma DSL é fazer com que a implementação fique muito mais perto do domínio do problema do que do domínio de programação. Uma DSL é expressa em termos de idéias que fazem sentido no contexto ao qual ela se encontra. Nesta DSL, por exemplo, são encontrados termos como “Sensor de Temperatura” ou “Motor” ao invés de “Classes”, “Variáveis” ou “Linha da Tabela”.
A DSL aqui criada tem por objetivo gerar código que será interpretado por um robô hipotético chamado RoboX que possui, além de peças para a montagem (engrenagens, parafusos, roldanas, rodas, placas de metal, peças de sustentação), três sensores (de temperatura, de luz e de som) e três motores. Este kit pode ser montado de várias formas e para várias finalidades. Com o uso desta DSL os proprietários do RoboX poderão programá-lo mesmo sem possuir qualquer conhecimento em programação; variáveis, tabelas, inicializações, notações, estrutura de dados, entre outros, não são sequer mencionados, fazendo com que o usuário da DSL se preocupe apenas com a lógica do programa, o que o robô deve fazer. Por exemplo: “esperar a ausência de luz para então medir a temperatura, que deve ser informada no display” – para isto basta informar exatamente esta seqüência de passos utilizando componentes que fazem sentido neste problema a ser resolvido.
4.1 ANÁLISE
Para a criação da linguagem foi feito um levantamento de quais seriam os componentes gerados. Num primeiro momento seria criado um componente para cada sensor e motor do robô, mas para facilitar a programação e tornar a linguagem mais dinâmica foram incluídos os componentes ‘se então’, ‘loop’ e ‘espera’, associados a cada um dos sensores. A função e utilização de cada um dos componentes serão explicadas mais adiante.
4.2 CONCEPÇÃO
4.2.1 Configurações Iniciais
Após a instalação do Visual Studio e do SDK 4.0 é criado um novo projeto do tipo Domain-Specific Language Designer como demonstrado na figura 3.
Figura 2 - New Project
São apresentadas então, figura 4, opções para a criação de uma DSL a partir de padrões pré-definidos:
• Class Diagrams – similar ao diagrama de classes da UML, são caixas com linhas de textos representando atributos.
• Component Models – Modelo de componentes, representados através de caixas com portas, das quais saem ligações com outros componentes.
• Minimal Language – layout mínimo, suficiente para mostrar um tipo de caixa e um tipo de linha de conexão; é a opção utilizada para esta DSL, por ser a que melhor se enquadra nos objetivos propostos.
• Task Flow – similar ao diagrama de atividades do UML, caixas situadas entre separadores.
Figura 3 - Padrões pré-definidos
O próximo passo é definir a extensão dos arquivos e o ícone, como pode ser visto na figura 5. O próprio Visual Studio se encarrega de verificar se a extensão é única ou se é utilizada por outro programa no computador.
Figura 4 - Configuração dos arquivos
A partir de então o Visual Studio já pode gerar uma base sobre a qual será construída a linguagem. O resultado pode ser visto na figura 6.
Figura 5 - Minimal Language
À esquerda localiza-se a caixa de ferramentas, onde ficam os componentes que podem ser arrastados para a Superfície de Design (área central maior) onde irão compor o Modelo do Domínio. Já do lado direito, na parte superior, ficam os arquivos do projeto e, na parte inferior, as propriedades para configuração do elemento selecionado.
Dos arquivos gerados automaticamente destacam-se:
• DslDefinition.dsl – Arquivo do qual é derivado todo o código gerado. É o centro da DSL.
• DslDefinition.dsl.diagram – Cada exemplo da DSL é armazenado em um par de arquivos: um que contém a informação essencial sobre as instâncias da classe de domínio e relacionamentos, e o outro que contem o layout do diagrama. Se o arquivo do diagrama for perdido, o usuário precisa rearranjar o material na tela, mas nenhuma informação importante é perdida. A definição do DSL é como qualquer outro DSL neste respeito.
• Resources folder – As imagens usadas na caixa de ferramentas para cursores e em algumas formas. As imagens podem estar em diversos formatos, incluindo o bitmap (bmp) e o JPEG. Os arquivos que irão aparecer aqui são determinados pelo índice de
definição da DSL. Por exemplo, se for definido uma nova ferramenta na definição da DSL, deverá ter um ícone para representá-lo na caixa de ferramentas. Será fornecido um nome para o arquivo e o colocará no Resources folder.
• Properties \AssemblyInfo.cs – Informação da versão que mostra o caminho do código compilado para sua DSL. As entradas são derivadas dos valores que foram fornecidos no questionário quando se criou a DSL.
• Dsl.csproj – O arquivo do projeto não é mostrado explicitamente na pasta, mas seu índice é acessível clicando com o botão direito no projeto do Dsl e escolhendo “propriedades.” O nome assembly e o local padrão são derivados dos valores fornecidos no questionário de criação do DSL.
4.2.2 Modelo de Domínio
Após Identificar e analisar o domínio do problema deve-se partir para a criação do Modelo do Domínio que é a parte central da definição de qualquer DSL. É onde são definidos as propriedades e os conceitos representados pela linguagem e a relação entre eles. Como se fosse à gramática da linguagem, definindo os elementos que a constitui e as regras para a junção destes elementos. Alem disto ainda fornece fundamentos para outros aspectos da linguagem como a definição de notações, caixa de ferramentas, janela de propriedades, validações e serializações. A figura 7 mostra o Modelo de Domínio (Domain Model) da DSL RoboX.
As entidades presentes no “Classes and Relationship” são as que definem o modelo da linguagem, já as presentes no “Diagram Elements” são as que darão origem aos componentes visuais da linguagem.
4.3 UTILIZAÇÃO
4.3.1 Interface
Apresentando interface (figura 8) semelhante a do próprio Visual Studio, a DSL RoboX possui à esquerda uma paleta com os componentes que serão arrastados para a parte central (área de trabalho) que formarão o código. No canto direito os arquivos, e abaixo as propriedades dos componentes selecionados.
Figura 7 - Interface da DSL RoboX
Foram criados diversos componentes com o objetivo de tornar a linguagem o mais intuitiva possível, sendo que cada componente é identificado por uma figura e possuí campos de configuração específicos.
4.3.2.1 Componente Fluxo Principal
Utilizado para ligar um componente a outro, determinando assim o caminho que o programa deve percorrer. É representado por uma linha preta direcional, conforme a figura 9. Para poder utilizar o Fluxo Principal é preciso ter no mínimo dois componentes, um de onde partirá o fluxo e outro que será o destino, não podendo um componente ser origem para dois fluxos principais.
Figura 8 - Fluxo Principal
4.3.2.2 Componentes de Saída
São os componentes que causam alguma reação do robô, esta reação pode ser a emissão de som, o acionamento de motores ou a renderização de alguma imagem no display.
Estes componentes são representados por retângulos azuis e são delimitados por uma linha preta contínua, variando apenas a figura central.
4.3.2.2.1 Saída Som
Faz com que o arquivo de som definido nas propriedades seja emitido pelos auto-falantes do robô a um volume determinado pelo programador.
Figura 9 - Saída Som
4.3.2.2.2 Saída Vídeo
Figura 10 - Saída Vídeo
4.3.2.2.3 Saída Motor
Faz com que o motor seja acionado por um determinado numero de voltas à uma certa velocidade, conforme definido nas propriedades do componente.
Figura 11 - Saída Motor
4.3.2.3 Componentes de Loop
Componentes que permitem a utilização de um fluxo alternativo chamado “Reinício” que direciona para o ponto em que se inicia o laço. Determina o trecho de código que será repetido até que a condição configurada no componente de loop seja satisfeita.
Estes componentes são representados por retângulos verdes com bordas tracejadas e com uma figura central que varia de acordo com o componente.
4.3.2.3.1 Reinício
Representado por uma linha verde tracejada, conforme pode ser visto na figura 13, tem comportamento similar ao Fluxo Principal, mas pode ter como origem apenas componentes de loop.
Figura 12 - Reinício
4.3.2.3.2 Loop Temperatura
Possui como propriedades, além do nome, o sinal usado para a comparação (>,<,>=, <=, = ou <>) e a temperatura usada como parâmetro para definir se o programa continuará no Fluxo Principal ou irá voltar para o local apontado pelo fluxo alternativo “Reinício”. Cada vez
do robô e este valor será então comparado com o definido na propriedade do componente, se a condição for satisfeita, segue pelo Fluxo Principal, caso contrário retorna pelo fluxo alternativo “Reinício”.
Figura 13 - Loop Temperatura
4.3.2.3.3 Loop Luz
De funcionamento similar ao componente de loop de temperatura, este componente faz comparação com o valor lido do sensor de luz encontrado no robô.
Figura 14 - Loop Luz
4.3.2.3.4 Loop Som
Também de funcionamento similar ao componente de loop de temperatura, este componente faz comparação com o valor lido do sensor de som encontrado no robô.
Figura 15 - Loop Som
4.3.2.3.5 Loop Número de Vezes
Este componente faz com que determinado trecho de código seja repetido por um certo número de vezes conforme definido na propriedade.
Figura 16 - Loop Número de Vezes
4.3.2.4 Componentes SeEntão
Com este componente é possível criar cláusulas de condição no programa, esse componente abre dois fluxos de programa, um fluxo alternativo chamado “Senão” que será utilizado caso a condição definida não seja satisfeita, se for satisfeita o programa segue normalmente pelo Fluxo Principal.
Estes componentes são representados por retângulos vermelhos com bordas pontilhadas e contém uma figura central que varia de acordo com o componente.
4.3.2.4.1 Senão
Representado por uma linha vermelha pontilhada, conforme pode ser visto na figura 18, tem comportamento similar ao “Reinício” dos componentes de loop, mas pode ter como origem apenas componentes do tipo “SeEntão”.
Figura 17 - Senão
4.3.2.4.2 SeEntão Temperatura
Assim que o fluxo do programa atingir este ponto, será lido o valor atual do sensor de temperatura que será então comparada de acordo com os critérios definidos nas propriedades do componente – valor da temperatura e sinal de comparação, caso a condição não seja satisfeita o programa segue para o ponto indicado pelo fluxo alternativo “Senão”.
Figura 18 - SeEntão Temperatura
De comportamento similar ao componente de temperatura, este componente faz a leitura do sensor de luz do robô e então decide por qual fluxo seguir.
Figura 19 - SeEntão Luz
4.3.2.4.4 SeEntão Som
Também de comportamento similar ao componente de temperatura, este componente faz a leitura do sensor de som para então poder decidir por qual fluxo seguir.
Figura 20 - SeEntão Som
4.3.2.5 Componentes Esperar
São componentes que seguram o fluxo até que uma determinada condição seja satisfeita, esta condição pode estar relacionada aos sensores de som, temperatura e luz, ou pode ser um tempo fixo em milesegundos.
Estes componentes são representados por retângulos amarelos com uma figura central que varia de acordo com o componente.
4.3.2.5.1 Esperar Temperatura
Retém o fluxo do programa até que o valor lido pelo sensor de temperatura satisfaça as condições definidas nas propriedades do componente. Assim que a condição for satisfeita o programa continua sua execução pelo Fluxo Principal.
4.3.2.5.2 Esperar Luz
Com comportamento similar ao de temperatura, este componente lê o valor do sensor de luz até que sejam satisfeitas as condições definidas nas propriedades.
Figura 22 - Esperar Luz
4.3.2.5.3 Esperar Som
Também com comportamento similar ao componente de temperatura, este componente lê o valor do sensor de som até que o valor do volume lido satisfaça as condições definidas nas propriedades.
Figura 23 - Esperar Som
4.4 EXEMPLOS DE PROGRAMAS
Com a utilização desta DSL, mesmo uma pessoa sem conhecimentos de programação é capaz de determinar o que o robô deve fazer, para qualquer que seja a forma com que ele foi construído.
4.4.1 Programa HelloWorld.rob
A execução deste programa faz com que seja emitido através dos auto-falantes do robô o som: “hello world!” que se encontra no arquivo “helloworld.wav”. Como pode ser visto nas figuras abaixo, fazer um programa deste tipo na DSL RoboX é extremamente simples.
Figura 24 - Programa HelloWorld
A programação do HelloWorld na DSL RoboX será arrastar o componente Saída Som para o fluxo principal e nas propriedades do componente selecionar o arquivo de saída e o volume desejado.
4.4.2 Programa Geladeira.rob
Um programa que, colocando o robô dentro de uma geladeira: espera a porta se fechar (e conseqüentemente a luz se apagar) aguarda 1 minuto e então mede a temperatura, informa no display se a temperatura é maior ou menor que zero e emitir um sinal informando o encerramento do programa.
Figura 25 - Programa Geladeira
Para fazer este programa, primeiro é colocado um componente Esperar Luz que vai estar configurado para aguardar a falta de luz, seguido de um componente Esperar Tempo com o tempo de espera definido em suas propriedades, e logo após o componente SeEntão Temperatura que terá uma condição relacionada a temperatura e de onde sairá dois fluxos de execução, um fluxo principal para quando a condição for satisfeita e um fluxo alternativo, o fluxo Senão, para quando a condição não for satisfeita. Na saída dos dois fluxos seguirá um componente Saída Vídeo, cada qual especificando o arquivo de imagem que será exibido, e depois de cada um desses componentes saíra um fluxo principal para um único componente, componente Saída Som que vai selecionar um arquivo de áudio, de onde não saíra nenhum fluxo e será encerrado o programa.
4.4.3 Programa SeparadorDeBolinhas.rob
Nesta situação existe um robô, que segue o layout mostrado na figura 27, que deve separar bolas de ping-pong brancas e pretas. Se for branca, o motor deve girar no sentido horário para que os braços encaminhem a bola para o buraco 1, se preta, no sentido anti-horário, para o buraco 2.
Figura 26 - Layout do Robô Separador
Para diferenciar as cores das bolas, é utilizado o sensor de luz: se sobre ele estiver a bola preta, ele retornará o valor próximo a zero, se for a branca irá retornar um valor próximo a cinqüenta, se não tiver bola retornará um valor próximo a cem.
O programa inicia com o componente SeEntão Luz que dependendo da intensidade de luz lida pelo sensor seguirá o fluxo principal ou o fluxo alternativo, os dois fluxos seguirão para um componente Saída Motor, onde o componente que sairá do fluxo principal estará configurado para girar no sentido horário, e o outro que sairá do fluxo alternativo vai girar sentido anti-horário. De ambos os componentes Saída Motor seguirá um fluxo principal para um componente Esperar Tempo, que será utilizado para aguardar que a próxima bolinha chegue no sensor de luz. Após aguardar, segue o componente Loop Luz, que irá voltar ao início do programa caso haja outra bolinha, ou irá para o componente Saída Som caso tenha acabado as bolinhas, neste caso será emitido um som e encerrará o programa.
5 CONCLUSÃO
Este trabalho apresenta uma linguagem específica para programação de robôs. Desde a modelagem e em todas as etapas seguintes o foco foi à criação de uma linguagem de fácil utilização e de programação intuitiva, para que qualquer usuário, do mais leigo em programação ao mais avançado, conseguisse fazer um programa. A melhor forma encontrada para criar uma linguagem com essas características foi fazer uma linguagem gráfica, que foi possível de desenvolver com a ferramenta SDK do Visual Studio.
A primeira dificuldade encontrada foi na modelagem da linguagem, na definição de suas funcionalidades. Pelo fato de não termos experiência no desenvolvimento de Linguagens Específicas de Domínio tivemos que remodelar nossa DSL algumas vezes para que atendesse nossos objetivos.
Após a definição do modelo passamos para o desenvolvimento da linguagem, onde surgiu outra dificuldade, o uso da ferramenta utilizada. Entre os softwares disponíveis para essa finalidade, optamos pelo Visual Studio SDK por possuir mais material de apoio e exemplos documentados. Para um primeiro uso no desenvolvimento de uma DSL, o Visual Studio se mostrou de fácil utilização, com um assistente de criação que nos auxiliou na definição de todas as etapas.
Com a linguagem criada e o ambiente de programação pronto, fizemos alguns programas testes e conseguimos atingir nosso objetivo, fazer programas sem escrever uma linha de código sequer, onde qualquer pessoa que nunca tenha programado compreenda a lógica e crie um programa.
Para trabalhos futuros, ficaram a documentação da linguagem e o seu aperfeiçoamento. Como a adição de mais funcionalidades, como por exemplo, funções matemáticas. Inserção de constraints para que possa impedir erros de programação antes mesmo da compilação do programa. E geração de código compatível com um robô comercial, Lego MindStorms por exemplo.
REFERÊNCIAS BIBLIOGRÁFICAS
[Basu, 1997] A. Basu, M. Hayden, G. Morrisett e T. von Eicken. A language-based approach to protocol construction. DSL '97 - First ACM SIGPLAN Workshop on Domain- Specific Languages, in Association with POPL '97, Paris, França, Janeiro 1997. University of Illinois Computer Science Report., páginas 1-15.
[Bentley, 1986] J. L. Bentley, “Programming pearls: Little languages.”,Communications of the ACM, 29(8):711-721, Agosto 1986.
[Bertrand e Augeraud, 1999] F. Bertrand, M. Augeraud. BDL: A specialized language for per-object reactive control. In Special issue on domain-specific languages. IEEE Transactions on Software Engineering, 25(3), Maio/Junho 1999., páginas 347-362.
[Bonachea, 1999] D. Bonachea, K. Fisher, A. Rogers e F. Smith. Hancock: A language for processing very large-scale data. Proceedings of the second USENIX Conference on Domain-Specific Languages. USENIX Association, Outubro 3-5 1999, páginas 163-176.
[Bragança, 2002] Alexandre Manuel Tavares Bragança. Linguagens Específicas de Domínio no
Desenvolvimento de Software de Gestão. 2:5-10, Julho 2002.
[Bruce, 1997] D. Bruce. What makes a good domain-specific language? APOSTLE, and its approach to parallel discrete event simulation. DSL '97 - First ACM SIGPLAN Workshop on Domain-Specific Languages, in Association with POPL '97, Paris, França, Janeiro 1997. University of Illinois Computer Science Report., páginas 17-35.
[Cardelli e Davies, 1999] L. Cardelli e R. Davies, Service combinators for web computing. Special issue on domain-specific languages.IEEE Transactions on Software Engineering, 25(3), Maio/Junho 1999., páginas 309-316.
[Chandra, 1999] S. Chandra, B. Richards e J. R. Larus. Teapot: A domain-specific language for writing cache coherence protocols. Special issue on domain-specific languages.IEEE Transactions on Software Engineering, 25(3), Maio/Junho 1999., páginas 317-333.
[Cleveland, 1988] J. C. Cleaveland, “Building application generators”,IEEE Software, pp. 25-33, Julho 1988. [Crew, 1997] R. F. Crew. ASTLOG: A language for examining abstract syntax trees. Proceedings of the USENIX Conference on Domain-Specific Languages, Berkeley, CA, Outubro 15-17 1997. USENIX Association., páginas 229-242.
[Deursen, 1996] A. van Deursen, J. Heering e P. Klint, editors. Language Prototyping: An Algebraic Specification Approach, volume 5 of AMAST Series in Computing. World Scientific Publishing Co., 1996. [Deursen, 1997] A. Deursen, “Domain-specific languages versus object-oriented frameworks: A financial engineering case study”, Smalltalk and Java in Industry and Academia, TJA'97, pp 35-39. Ilmenau Technical University, 1997.
[Deursen e Klint, 1998] A. Deursen, P. Klint, “Little languages: Little maintenance?“, Journal of Software Maintenance, 10:75-92, 1998.
[Deursen, 2000] A. van Deursen, P. Klint e J. Visser, “Domain-Specific Languages: An Annotated
Bibliography”, ACM SIGPLAN Notices 35(6):26-36, Junho 2000. On line em
www.program-transformation.org/.
[Dinesh, 1998] T. B. Dinesh, M. Haveraaen e J. Heering. An algebraic programming style for numerical software and its optimization. Technical Report SEN-R9844, CWI, 1998. ACM CoRR Preprint Server cs.SE/9903002 (Março 1999). Submitted toScientific Programming.
[Elliott, 1999] C. Elliott. An embedded modeling language approach to interactive 3D and multimedia animation. Special issue on domain-specific languages. IEEE Transactions on Software Engineering, 25(3), Maio/Junho 1999., páginas 291-308.
[Engler, 1999] D. R. Engler. Interface compilation: Steps toward compiling program interfaces as languages. Special issue on domain-specific languages. IEEE Transactions on Software Engineering, 25(3), Maio/Junho 1999., páginas 387-400.
[Faithet al., 1997] R. E. Faith, L. S. Nyland e J. F. Prins. Khepera: A system for rapid implementation of domain specific languages. Proceedings of the USENIX Conference on Domain-Specific Languages, Berkeley, CA, Outubro 15-17 1997. USENIX Association., páginas 243-55.
[Gray, 1995] R. Gray. Agent Tcl: A transportable agent system. In J. Mayfield and T. Finnin, editors, Proceedings of the CIKM Workshop on Intelligent Information Agents, Fourth International Conference on Information and Knowledge Management (CIKM'95), Dezembro 1995.
[Herndon e Berzins, 1988] R. M. Herndon e V. A. Berzins. The realizable benefits of a language prototyping language.IEEE Transactions on Software Engineering, SE-14:803- 809, 1988.
[Horowitz, 1985] E. Horowitz, A. Kemper e B. Narasimhan. A survey of application generators.IEEE Software, páginas 40-54, Janeiro 1985.
[Hudak, 1996] P. Hudak. Building domain-specific embedded languages. ACM Computing Surveys, 28(4es), December 1996.
[Hudak, 1998] P. Hudak. "Modular Domain Specific Languages and Tools". In Fifth International Conference on Software Reuse, páginas 134--142, Victoria, Canada, Junho 1998.
[Jennings e Beuscher, 1999] J. Jennings e E. Beuscher. Verischemelog: Verilog embedded in Scheme. Proceedings of the second USENIX Conference on Domain-Specific Languages. USENIX Association, Outubro 3-5 1999., páginas 123-134.
[Kamin e Hyatt, 1997] S. Kamin e D. Hyatt. A special-purpose language for picturedrawing.Proceedings of the USENIX Conference on Domain-Specific Languages, Berkeley, CA, Outubro 15-17 1997. USENIX Association., páginas 297-310.
[Kieburtz, 2001] Dick Kieburtz, “Retrospective on Formal Methods” OGI/2020, OGI School of Science and Engineering, OHSU, Setembro 2001.
[Klarlund e Schwartzbach, 1999] N. Klarlund e M. I. Schwartzbach. A domain-specific language for regular sets of strings and trees. Special issue on domain-specific languages. IEEE Transactions on Software Engineering, 25(3), Maio/Junho 1999., páginas 378-386.
[Krueger, 1992] C. W. Krueger. Software reuse.ACM Computing Surveys, 24(2):131-183, Junho 1992.
[Ladd e Ramming, 1994] D. A. Ladd e J. C. Ramming. Two application languages in software production. In USENIX Very High Level Languages Symposium Proceedings, páginas 169-178, Outubro 1994.
[Medvidovic e Rosenblum, 1997] N. Medvidovic e D. S. Rosenblum. Domains of concern in software architectures and architecture description languages. Proceedings of the USENIX Conference on Domain-Specific Languages, Berkeley, CA, Outubro 1997. USENIX Association., páginas 199-212.
[Nakatani e Jones, 1997] L. Nakatani e M. Jones. Jargons and infocentrism. DSL '97 – First ACM SIGPLAN Workshop on Domain-Specific Languages, in Association with POPL '97, Paris, França, Janeiro 1997. University of Illinois Computer Science Report., páginas 59- 74.
[Neighbors, 1984] J. M. Neighbors. The Draco approach to constructing software from reusable components. IEEE Transactions on Software Engineering, SE-10(5):564-74, Setembro 1984.
[Ousterhout, 1998] J. K. Ousterhout. Scripting: Higher level programming for the 21stcentury.IEEE Computer, Março 1998.
[Peterson, 1999] J. Peterson, P. Hudak e C. Elliott. Lambda in motion: Controlling robots with Haskell. In PADL'99, volume 1551 of LNCS, páginas 91-105, 1999.
[Pressman, 1994] Roger S. Pressman. “Software Engineering A Practitioner’s Approach”. McGraw Hill, 1994
[Pu, 1987] C. Pu, A. Black, C. Cowan, J. Walpole e C. Consel. Microlanguages for operating system specialization. DSL '97 - First ACM SIGPLAN Workshop on Domain- Specific Languages, in Association with POPL '97, Paris, França, Janeiro 1997. University of Illinois Computer Science Report., páginas 49-57.
[Ramming, 1997] J. Christopher Ramming, editor. USENIX Conference on Domain- Specific Languages, Santa Monica, CA, USA, Outubro 1997. USENIX.
[Sirer e Bershad, 1999] E. G. Sirer e B. N. Bershad. Using production grammars in software testing.Proceedings of the second USENIX Conference on Domain-Specific Languages. USENIX Association, Outubro 1999, páginas 1-14.
[Smaragdakis e Batory, 1997] Y. Smaragdakis e D. Batory. DiSTiL: A transformation library for data structures. Proceedings of the USENIX Conference on Domain-Specific Languages, Berkeley, CA, Outubro 1997. USENIX Association., páginas 257-270.
[Stevenson e Fleck, 1997] D. E. Stevenson e M. M. Fleck. Programming language support for digitized images or, the monsters in the closet.Proceedings of the USENIX Conference on Domain-Specific Languages, Berkeley, CA, Outubro 1997. USENIX Association., páginas 271-284.
[Stichnoth e Gross, 1997] J. M. Stichnoth e T. Gross. Code composition as an implementation language for compilers. Proceedings of the USENIX Conference on Domain-Specific Languages, Berkeley, CA, Outubro 1997. USENIX Association., páginas 119-132.
[Teixeira, 2003] José Helvécio Teixeira Jr. Considerações Iniciais sobre o Projeto de Protocolos para Redes de Computadores baseado em Linguagens Específicas de Domínio. 2:7-11, Agosto 2003.
[Thibault, 1998] S. Thibault, “Domain Specific Languages: Conception, Implementation and Application”, PhD Thesis, Université de Rennes 1, 1998
[Thibault, 1999] S. A. Thibault, R. Marlet e C. Consel. Domain-specific languages: From design to implementation application to video device drivers generation. Special issue on domain-specific languages. IEEE Transactions on Software Engineering, 25(3), Maio/Junho 1999, páginas 363-377.
[Wang, 1997] D. C. Wang, A. W. Appel, J. L. Korn, C. S. Serra, “The Zephyr abstract syntax description language”, Proceedings of the USENIX Conference on Domain- Specific Languages, Berkeley, CA, USENIX Association, pp 213-28, Outubro 1997
Linguagem Específica de Domínio para Programação de Robôs
François Jumes, Luiz Claudio Rossafa Honda
Curso de Bacharelado em Sistemas de Informação Departamento de Informática e Estatística
Universidade Federal de Santa Catarina – UFSC, Brasil, 88040-900 {eek,honda}@inf.ufsc.br
ABSTRACT. This meta-paper describes the bases of a Domain Specific Language for a hypothetic robotic
kit.
RESUMO. Este trabalho tem por objetivo explicar os conceitos básicos ligados ao desenvolvimento de
Linguagens Específicas de Domínio através de um exemplo prático onde é criada a Linguagem RoboX para um kit fictício de montagem de robôs. Estas linguagens – conhecidas como DSL (Domain Specific
Language), além de tornarem as programações mais ágeis, simples e diminuírem a chance de erros,
também trazem o usuário final para perto do desenvolvimento, permitindo que os dois, programador e usuário, conversem no mesmo idioma. São apresentados também outras linguagens com o objetivo de demonstrar que o conceito ligado à Linguagens Específicas de Domínio não é novo, mas que a concepção destas linguagens vem se tornando cada vez mais simples e acessíveis.
PALAVRAS-CHAVE: DSL, Domain Specific Language, Visual Studio SDK, Linguagem Específica de
Domínio, Robôs.
1 INTRODUÇÃO
Um dos fatores mais importantes para o sucesso de um software é a facilidade de automação de tarefas pelo usuário final, ou seja, a flexibilidade para definir rotinas personalizadas para a execução de determinadas tarefas. Porém, na maioria dos casos, as mudanças acabam passando pela equipe de análise e desenvolvimento, o que torna o processo de alteração difícil e demorado. A idéia é permitir que o usuário possa intervir no processo de adequação do software às suas necessidades sem passar pela equipa original que o desenvolveu. Como a aplicação é desenvolvida para resolver um determinado problema, o usuário pode adaptar a aplicação apenas dentro daquele contexto, daí a designação de linguagem específica de um domínio.
Apesar de ser uma área recente, alguns dos princípios das DSL já têm uma longa história e embora os princípios sejam promissores, algumas questões ainda devem ser consideradas
na adoção das DSL, como: a dificuldade em encontrar o âmbito correto de uma DSL; o custo do desenho, implementação e manutenção da DSL; a dificuldade no balanceamento entre as construções específicas de domínio e as de programação genérica da linguagem.
Este trabalho consistirá em desenvolver, utilizando a ferramenta Visual Studio DSL Tools, uma linguagem específica de domínio para programação de robôs, que seja de fácil utilização, independente do grau de complexidade com o qual o robô foi construído fisicamente. Além de demonstrar que a utilização de DSL pode melhorar o grau de flexibilidade, manutenção e evolução das aplicações.
Justamente por ser uma DSL está linguagem oferece uma interface intuitiva e fácil de aprender, abstraindo tudo o que não é relevante para o objetivo final: “Como o robô deve agir”. Sendo assim, o usuário desta linguagem não precisa se preocupar em criar classes, objetos, protocolos de comunicação, etc.
tornando a programação muito mais rápida, prazerosa e menos suscetível a erros.
2 PROJETO
O projeto de uma DSL exige uma maior compreensão sobre o domínio do problema. DSL só fazem sentido se elas contiverem uma abstração útil para uma classe completa de problemas que ocorrem no domínio correspondente. Assim, é necessário que os especialistas de domínio sejam envolvidos no projeto de uma DSL, de modo que a linguagem resultante seja um veículo útil para a especificação realista de soluções de problemas no domínio correspondente [Bragança, 2002]. Segundo [Teixeira, 2003], a forma de se definir a semântica de uma DSL determina para quais propósitos ela poderá ser utilizada durante o processo de desenvolvimento.
3 DSL PARA PROGRAMAÇÃO DE ROBÔS – ROBOX
Um dos efeitos de se usar uma DSL é fazer com que a implementação fique muito mais perto do domínio do problema do que do domínio de programação. Uma DSL é expressa em termos de idéias que fazem sentido no contexto ao qual ela se encontra. Nesta DSL, por exemplo, são encontrados termos como “Sensor de Temperatura” ou “Motor” ao invés de “Classes”, “Variáveis” ou “Linha da Tabela”.
A DSL aqui criada tem por objetivo gerar código que será interpretado por um robô hipotético chamado RoboX que possui, além de peças para a montagem (engrenagens, parafusos, roldanas, rodas, placas de metal, peças de
sustentação), três sensores (de temperatura, de luz e de som) e três motores. Este kit pode ser montado de várias formas e para várias finalidades. Com o uso desta DSL os proprietários do RoboX poderão programá-lo mesmo sem possuir qualquer conhecimento em programação; variáveis, tabelas, inicializações, notações, estrutura de dados, entre outros, não são sequer mencionados, fazendo com que o usuário da DSL se preocupe apenas com a lógica do programa, o que o robô deve fazer. Por exemplo: “esperar a ausência de luz para então medir a temperatura, que deve ser informada no display” – para isto basta informar exatamente esta seqüência de passos utilizando componentes que fazem sentido neste problema a ser resolvido.
4.1 ANÁLISE
Para a criação da linguagem foi feito um levantamento de quais seriam os componentes gerados. Num primeiro momento seria criado um componente para cada sensor e motor do robô, mas para facilitar a programação e tornar a linguagem mais dinâmica foram incluídos os componentes ‘se então’, ‘loop’ e ‘espera’, associados a cada um dos sensores. A função e utilização de cada um dos componentes serão explicadas mais adiante.
4.2 CONCEPÇÃO
Após a instalação do Visual Studio e do SDK 4.0 é criado um novo projeto do tipo Domain-Specific Language Designer onde são apresentadas as opções para a criação de uma DSL a partir de padrões pré-definidos:
