A Model-Driven Software Reuse Approach (in portuguese)
A Model-Driven Software Reuse Approach (in portuguese)
A Model-Driven Software Reuse Approach (in portuguese)
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
150<br />
ser realizado exclusivamente de forma top-down. Porém, a DSL deve também ser capaz de<br />
produzir modelos que sirvam de entrada para transformadores e geradores, o que <strong>in</strong>clui muitos<br />
detalhes que são específicos à plataforma e arquitetura escolhidas. É muito difícil perceber<br />
tais detalhes sem <strong>in</strong>vestigação mais aprofundada na implementação, e portanto uma abordagem<br />
bottom-up é utilizada para ref<strong>in</strong>ar esta DSL <strong>in</strong>icial. Esta atividade corresponde à parte top-down<br />
do desenvolvimento da DSL.<br />
Conforme discutido na Seção 3.1.2, uma DSL pode ser textual (programas) ou visual<br />
(diagramas), e é normalmente composta de três elementos: a s<strong>in</strong>taxe abstrata, a s<strong>in</strong>taxe concreta<br />
e a semântica. Esta atividade cuida do desenvolvimento das s<strong>in</strong>taxes abstrata e concreta da DSL,<br />
além de ferramentas que permitam a criação de <strong>in</strong>stâncias (programas ou diagramas) da DSL.<br />
Em DSLs textuais, as s<strong>in</strong>taxes abstrata e concreta são normalmente representadas através de<br />
regras léxicas e gramaticais. Em DSLs visuais, a s<strong>in</strong>taxe abstrata corresponde ao metamodelo<br />
(GUIZZARDI; PIRES; SINDEREN, 2002) e a s<strong>in</strong>taxe concreta corresponde aos aspectos visuais dos<br />
elementos, normalmente utilizando figuras, ícones, l<strong>in</strong>has, setas, entre outras representações<br />
gráficas.<br />
Para representar corretamente sua variabilidade, um subdomínio pode exigir um sistema<br />
de conceitos (s<strong>in</strong>taxes abstrata e concreta) totalmente diferente da modelagem de features,<br />
possivelmente exig<strong>in</strong>do também uma ferramenta de modelagem mais complexa. Mas mesmo<br />
não sendo suficiente para identificar conceitos de uma DSL (TOLVANEN; KELLY, 2005), um<br />
modelo de features pode servir de ponto de partida (CZARNECKI, 2005), sendo posteriormente<br />
complementado com <strong>in</strong>formações de outros artefatos, como a arquitetura do domínio e o<br />
conhecimento do especialista (TOLVANEN; KELLY, 2005).<br />
O desenvolvimento de DSLs é considerado uma ciência à parte (CZARNECKI; EISENECKER,<br />
2000), dada sua complexidade. Além disso, não é um processo muito previsível, pois exige<br />
criatividade (VISSER, 2007). Esta abordagem busca prover alguma orientação, através de c<strong>in</strong>co<br />
sub-atividades, apresentadas a seguir.<br />
Sub-atividade ID.2.1. Identificação das features <strong>in</strong>iciais da DSL<br />
O primeiro passo é identificar as features que irão dar <strong>in</strong>ício à formação da s<strong>in</strong>taxe abstrata<br />
da DSL. Como descrito na atividade ID.1, os serviços e funções do domínio são normalmente<br />
descritos em termos de features de tecnologia do domínio, e portanto estas são boas candidatas<br />
a fazer parte de uma DSL. Considere por exemplo o domínio web de autoria de conteúdo<br />
mostrado na Figura 26A. Neste domínio, dois subdomínios podem ser identificados: navegação<br />
(Conteúdo, Busca, Busca simples, Busca avançada, Conteúdo de usuário, Pág<strong>in</strong>a, Formulário,