15.04.2013 Views

A Model-Driven Software Reuse Approach (in portuguese)

A Model-Driven Software Reuse Approach (in portuguese)

A Model-Driven Software Reuse Approach (in portuguese)

SHOW MORE
SHOW LESS

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,

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!