Uma Abordagem Orientada A Modelos

Daniel Lucrdio
Uma Abordagem Orientada a Modelos para

Reutilizao de Software
USP So Carlos SP
Junho de 2009
Daniel Lucrdio
Uma Abordagem Orientada a Modelos para

Reutilizao de Software
Tese apresentada ao Instituto de Cincias
Matemticas e de Computao - ICMC-USP,
como parte dos requisitos para obteno do
ttulo de Doutor em Cincias - Cincias de
Computao e Matemtica Computacional.
Orientadora:
Profa
Dra
Renata Pontin de Mattos Fortes
I NSTITUTO DE C INCIAS M ATEMTICAS E DE C OMPUTAO

U NIVERSIDADE DE S O PAULO
USP So Carlos SP
Junho de 2009
Agradecimentos
Agradeo minha orientadora, Renata, que me acolheu e orientou durante todos estes
anos. Alm dos diversos papis que lhe cabem oficialmente, sendo uma orientadora dedicada,
interessada e competente, ela me ajudou muito dentro e fora do doutorado.
Agradeo tambm s instituies que fizeram com que esta trajetria fosse possvel. Estas
incluem o ICMC-USP, por ter sido a minha casa durante estes anos. Tambm agradeo
FAPESP, CAPES e CNPq, que em diversos momentos me ajudaram financeiramente. Espero
ter correspondido e continuar correspondendo altura este investimento em mim realizado.
Agradeo ao grupo RiSE (Reuse in Software Engineering), e as suas instituies de apoio,
UFPE e C.E.S.A.R. em Recife-PE. Tenho orgulho em ter participado do comeo desta iniciativa,
junto com Eduardo Santana de Almeida, Vinicius Cardoso Garcia e Alexandre Alvaro, sob a
orientao de Silvio Meira. Se hoje o RiSE est entre os principais grupos de reutilizao do
mundo, porque realmente compreendemos o verdadeiro significado da palavra colaborao.
Durante o doutorado, passei seis meses na George Mason University, em Fairfax, VA,
Estados Unidos, sob a orientao de Jon Whittle, onde aprendi muitas coisas, somente algumas
delas contidas nesta tese de uma forma ou de outra. Foram tambm trs meses em Redmond,
WA, Estados Unidos, na Microsoft Research, sob a orientao de Ethan Jackson e Wolfram
Schulte, em outro grupo RiSE, esse chamado Research in Software Engineering. Este estgio
foi parte de um prmio que recebi, o Latin American Fellowship Award 2008-2009, oferecido
pela Microsoft Research. Posso seguramente dizer que essa experincia deixou marcas e
aprendizados que foram alm de todas as minhas expectativas, e impossvel no ficar grato
pelo reconhecimento de meu trabalho. Agradeo tambm a Jaime Puente, Juliana Salles, e toda
a equipe da Microsoft responsvel por essa tima iniciativa.
Obrigado Aptor Software, por acreditar neste projeto, cedendo parte de seu tempo e seus
funcionrios para a realizao de um dos estudos empricos.
Agradeo tambm aos colegas e amigos que encontrei pelo caminho, pois foram muito
importantes durante essa trajetria: no ICMC, Dbora, Daniel, Thiago, Andr, Silvana,
Amrico, Adalberto, Willian, David, Eduardo e Prazeres; em Recife-PE, Eduardo, Vinicius,
Alexandre, Fred, Bart, Liana, Vanilson, Kellyton, e demais membros do RiSE; Em Fairfax,
EUA, Marcos, Rodrigo, William, Aline e Cristiane; e finalmente Leo, Renan, Alexandre,
Alexandro, Matko, e os outros estagirios da MSR.
Durante o doutorado, foi tambm importante o perodo de dois anos e meio trabalhando em
tempo parcial na 3WT, empresa aqui de So Carlos. No existe um vnculo oficial entre o que
fiz na empresa e o que fiz na universidade, mas a vivncia prtica na indstria foi sem dvida
relevante para esta tese, e agradeo empresa e aos amigos que nela fiz: Dugnani, Evandro,
Cristiano, Escovar, Danilo, Vital, Ricardo, Rodrigo, Mateus, Renan, Cris, Maria e muitos outros
com quem convivi neste perodo.
Agradeo tambm aos amigos Cassandra, Marcelo, Bianca, Amandinha, Ivan e Amanda,
pela amizade e pelas noites de descontrao.
Por fim, agradeo minha amada esposa Alessandra e minha filha Julia, por todo o amor
e carinho que me fazem lembrar que a vida no podia ser melhor. E tambm pelo apoio, fora
e compreenso nos (muitos) momentos difceis. A todos interessados em iniciar uma jornada
como a de um doutorado, recomendo fortemente a presena da famlia. Tambm agradeo a
meus pais Horcio e Dalila, meus irmos e cunhados, Rafael e Amanda, Maurcio e Andra,
Fbio e Andra, meus sogros Vivaldo e Ivani e meus sobrinhos, Gabriel, Leo, Dudu e Giovanna.
E tambm a Guiza, minha companheira fiel durante grande parte do desenvolvimento e escrita
da tese.
E obrigado DEUS, pela minha vida.
Academic organizations in computer science seem to prefer to work on new theories.

However, some of the most successful academic work is a fusion and formalization of
successful techniques.
James M. Neighbors
Resumo
A reutilizao de software busca aumentar a qualidade e produtividade no desenvolvimento
de software, evitando a duplicao do esforo e reaproveitando o mximo possvel das
experincias de projetos passados. Apesar de simples, esta idia no facilmente colocada em
prtica, principalmente de maneira sistemtica e controlada. Tcnicas de engenharia de domnio
e linhas de produtos de software buscam facilitar esta tarefa, porm ainda existem outros fatores
que dificultam a adoo da prtica da reutilizao. Entre estes, destacam-se os problemas
inerentes ao desenvolvimento de software da maneira como conduzido atualmente, baseado
em cdigo-fonte. Estes problemas tm suas origens na crescente demanda por software cada vez
mais complexo e afetam negativamente a capacidade de reutilizar software. O desenvolvimento
orientado a modelos surge como uma alternativa atraente neste cenrio, elevando a importncia
de modelos dentro do ciclo de vida do software, incorporando-os como parte integrante do
produto final por meio de tcnicas de modelagem e gerao de cdigo. Com isto, parte da
complexidade do software fica escondida dentro dos geradores, protegendo os desenvolvedores,
reduzindo a incidncia de erros, aumentando a produtividade, qualidade, interoperabilidade
e manutenibilidade dos artefatos produzidos. Nesta dissertao defende-se a tese de que o
desenvolvimento orientado a modelos pode efetivamente aumentar e/ou melhorar a reutilizao
de software, e que para isso ela deve ser tratada de forma consistente dentro de um processo
de engenharia de domnio. Para demonstrar esta tese, apresentada uma abordagem orientada
a modelos para reutilizao de software, com atividades que guiam o desenvolvedor durante a
anlise, projeto e implementao do domnio. So tambm apresentados os resultados de uma
avaliao envolvendo trs estudos empricos, realizados em ambiente acadmico e industrial,
que buscou determinar a viabilidade da abordagem e os benefcios que podem ser alcanados
com a combinao de tcnicas do desenvolvimento orientado a modelos e da reutilizao de
software. Os resultados mostram que a abordagem pode trazer diferentes benefcios para
organizaes de software, incluindo aumento da quantidade e qualidade da reutilizao, e
reduzindo a complexidade de desenvolvimento e configurao de produtos.
Palavras-chave: Reutilizao de software, Desenvolvimento Orientado a Modelos,
Engenharia de Domnio, Linhas de Produtos de Software, Linguagens Especficas de Domnio,
Programao Generativa.
Abstract
Software reuse aims at increasing quality and productivity in software development,
avoiding effort duplication and reusing all past experiences possible. Although it is a simple
idea, it is not easy to put reuse in practice, especially in a systematic and controlled way.
Domain engineering and software product lines techniques try to make this task easier, but
there are many other factors that difficult the reuse adoption. Among these factors are the
problems that are inherent to software development in the way it is conducted today, based on
source code. These problems arise from the growing demand for increasingly complex software,
negatively affecting the ability to reuse. Model-driven development is an attractive alternative
in this scenario, leveraging the importance of models in the software life cycle, incorporating
them as part of the final product through modeling and code generation techniques. As a result,
part of the software complexity becomes hidden inside the generators, shielding the developers,
reducing errors, increasing the productivity, quality, interoperability and maintainability of the
produced assets. In this dissertation is presented the thesis that model-driven development can
effectively increase and/or improve software reuse, and that to achieve this goal it must be
treated in a consistent way inside a domain engineering process. To demonstrate this thesis,
a model-driven software reuse approach is presented, with activities that guide the developer
during domain analysis, design and implementation. The results of an evaluation involving
three empirical studies are also presented. The studies were performed in both academic and
industrial environments, and aimed at determining the viability of the approach and the benefits
that can be achieved with the combination of model-driven development and software reuse
techniques. The results showed that the approach can bring different benefits to software
organizations, such as software reuse quantity and quality improvements, and complexity
reduction in product development and configuration tasks.
Keywords: Software Reuse, Model-Driven Development, Domain Engineering, Software
Product Lines, Domain-Specific Languages, Generative Programming.
Lista de Figuras
1
Foto da palestra de M.D. McIlroy na conferncia da OTAN em 1968 . . . . . .
20
Modelo de maturidade em reutilizao (GARCIA et al., 2007, 2008) . . . . . . .
33
Ilustrao do processo de criao de software no desenvolvimento orientado a

modelos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
Principais elementos do MDD . . . . . . . . . . . . . . . . . . . . . . . . . .
42
Arquitetura clssica de metamodelagem . . . . . . . . . . . . . . . . . . . . .
43
Modelo de maturidade em MDD (MODELWARE, 2006b) . . . . . . . . . . . . .
48
Gerao de cdigo baseada em templates . . . . . . . . . . . . . . . . . . . .
60
Abrangncia da abordagem, em relao aos modelos de maturidade em

reutilizao e MDD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
67
Exemplo de modelo de features para o domnio web . . . . . . . . . . . . . . .
78
10
Modelo de features do domnio web de autoria de contedo . . . . . . . . . . .
96
11
Uso do padro Abstract Factory para features alternativas . . . . . . . . . . . . 106
12
Uso do padro Prototype para features alternativas . . . . . . . . . . . . . . . . 107
13
Uso do padro Template method para features alternativas . . . . . . . . . . . . 108
14
Uso do padro Chain of Responsibility para or features . . . . . . . . . . . . . 109
15
Uso do padro Decorator para or features . . . . . . . . . . . . . . . . . . . . 110
16
Padro visitante sendo aplicado implementao de variabilidade baseada em

features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
17
Abordagem template sendo aplicada gerao de cdigo baseada em features . 112
18
Padro camada fina de dados . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
19
Merging de geradores envolvendo modelos estruturais e comportamentais . . 116
20
Estratgia de caracterizao de sub-domnios . . . . . . . . . . . . . . . . . . 127
21
Modelo de features do domnio web de autoria de contedo . . . . . . . . . . . 129
22
Definio do metamodelo da DSL de autoria Web . . . . . . . . . . . . . . . . 131
23
Manuteno da consistncia da implementao de referncia . . . . . . . . . . 141
24
Sugesto de modelo de processo para utilizao da abordagem . . . . . . . . . 150
25
Comparao entre as mtricas de reutilizao para o estudo do domnio de

autoria de contedo para a web . . . . . . . . . . . . . . . . . . . . . . . . . . 177
26
Comparao entre as mtricas indiretas de reusabilidade para o estudo do

domnio de autoria de contedo para a web . . . . . . . . . . . . . . . . . . . 178
27
Distribuies de instabilidade de mdulo nos diferentes tipos de artefatos

produzidos com a abordagem, no estudo de caso do domnio de autoria de
contedo para web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
28
Distribuies de complexidade ciclomtica nos diferentes tipos de artefatos

contedo para web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
29
Distribuies do ndice de manutenibilidade nos diferentes tipos de artefatos

contedo para web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
30
Distribuies do nmero de atributos e do nmero de relacionamentos nos

modelos utilizados com a abordagem, no estudo de caso do domnio de autoria
de contedo para web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
31

aplicaes distribudas baseadas em computao em nuvem . . . . . . . . . . . 182
32
Comparao entre as mtricas indiretas de reusabilidade para o estudo do

domnio de aplicaes distribudas baseadas em computao em nuvem . . . . 182
33
Distribuies de instabilidade de mdulo nos diferentes tipos de artefatos

produzidos com a abordagem, no domnio de aplicaes distribudas baseadas
em computao em nuvem . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
34
Distribuies de complexidade ciclomtica nos diferentes tipos de artefatos

35
Distribuies do ndice de manutenibilidade nos diferentes tipos de artefatos

36
Distribuies de nmeros de atributos e relacionamentos nos modelos utilizados

com a abordagem, no domnio de aplicaes distribudas baseadas em
computao em nuvem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
37

eventos cientficos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
38
Comparao entre as mtricas de reusabilidade dos estudos dos domnios de

eventos cientficos (EC), Web e Computao em Nuvem (CN) . . . . . . . . . 186
39
Efeito da abordagem na reusabilidade dos artefatos produzidos . . . . . . . . . 190
40
Hiptese alternativa mais realista . . . . . . . . . . . . . . . . . . . . . . . . . 190
41
Situao clssica da anlise de sistemas . . . . . . . . . . . . . . . . . . . . . 242
Lista de Quadros
1
Exemplo de caso de uso do domnio web . . . . . . . . . . . . . . . . . . . . .
79
Exemplo de caso de mudana para a feature opcional de busca . . . . . . . . .
79
Exemplo de caso de mudana para a feature alternativa de busca parcial . . . .
80
Resumo das atividades para anlise de domnio orientada a modelos . . . . . .
93
Descrio dos produtos de trabalho da fase de anlise de domnio . . . . . . . .
94
Resumo das atividades para projeto de domnio orientado a modelos . . . . . . 121
Descrio dos produtos de trabalho da fase de projeto de domnio . . . . . . . 122
Resumo das atividades para implementao do domnio orientada a modelos . . 147
Descrio dos produtos de trabalho da fase de implementao do domnio . . . 148
10
Dados sobre o estudo envolvendo o domnio de autoria de contedo para Web . 171
11
Dados sobre o estudo envolvendo o domnio de aplicaes distribudas baseadas

12
Dados sobre o estudo envolvendo o domnio de eventos cientficos . . . . . . . 174
13
Resumo das principais tcnicas relacionadas aos conceitos bsicos da

reutilizao de software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
Lista de Acrnimos
ADD Attribute-Driven Design / Projeto Orientado a Atributos
AOP Aspect-Oriented Programming / Programao Orientada a Aspectos
AST Abstract Syntax Tree / rvore de Sintaxe Abstrata
ATL Atlas Transformation Language / Linguagem de Transformao Atlas
BNF Backus-Naur Form / Forma de Backus-Naur
DAO Data Access Object / Objeto de Acesso a Dados
DBC Desenvolvimento Baseado em Componentes
DBML DataBase Modeling Language / Linguagem de Modelagem de Banco de Dados
DSL Domain-Specific Language / Linguagem Especfica de Domnio
EMF Eclipse Modeling Framework / Framework de Modelagem do Eclipse
FBU Feature Binding Unit / Unidade de Agrupamento de Features
GME Generic Modeling Environment / Ambiente de Modelagem Genrico
GMF Graphical Modeling Framework / Framework de Modelagem Grfica
GMT Generative Modeling Tools / Ferramentas de Modelagem Generativas
GPL General Purpose Language / Linguagem de Propsito Geral
GQM Goal-Question Metric / Mtrica Objetivo-Questo
GUI Graphical User Interface / Interface Grfica com o Usurio
IDE Integrated Development Environment / Ambiente de Desenvolvimento Integrado
JET Java Emitter Templates / Modelos Emissores de Java
JMI Java Metadata Interface / Interface para Metadados em Java
JSP Java Server Pages / Pginas Servidoras Java

LOC Lines Of Code / Linhas De Cdigo
MDA Model-Driven Architecture / Arquitetura Orientada a Modelos
MDD Model-Driven Development / Desenvolvimento Orientado a Modelos
MDE Model-Driven Engineering / Engenharia Orientada a Modelos
MDR MetaData Repository / Repositrio de MetaDados
MDSD Model-Driven Software Development / Desenvolvimento de Software Orientado a
Modelos
MD* Acrnimo que abrange todas as abordagens de desenvolvimento de software orientadas
a modelos
MIC Model Integrated Computing / Computao Integrada por Modelos
MOF Meta-Object Facility / Infra-estrutura de MetaObjetos
MTF Model Transformation Framework / Framework de Transformao de Modelos
MVC Model-View-Controller / Modelo-Viso-Controlador
oAW openArchitectureWare - conjunto de ferramentas para desenvolvimento orientado a
modelos
OMG Object Management Group / Grupo de Gerenciamento de Objetos
OTAN Organizao do Tratado do Atlntico Norte
PHP PHP: Hypertext Preprocessor / PHP: Pr-processador de Hipertexto1
PNRP Peer Name Resolution Protocol / Protocolo de Resoluo de Nomes de Pares
POSA Pattern-Oriented Software Architecture / Arquitetura de Software Orientada a Padres
PuLSE ProdUct-Line Software Engineering / Engenharia de Software de Linha de Produtos
QVT Queries/Views/Transformations / Consultas/Vises/Transformaes
RAS Reusable Asset Specifications / Especificaes de Artefatos Reutilizveis
1 acrnimo
recursivo
RMM Reuse Maturity Model / Modelo de Maturidade em Reutilizao

RPC Reuse Capability Model / Modelo de Capacitao em Reutilizao
RRM Reuse Reference Model / Modelo de Referncia em Reutilizao
RUP Rational Unified Process / Processo Unificado da Rational
SAAM Software Architecture Analysis Method / Mtodo de Avaliao de Arquitetura de
Software
SCV Scope, Commonality, and Variability / Escopo, Comunalidade e Variabilidade
SPC Software Productivity Consortium / Consrcio de Produtividade de Software
UML Unified Modeling Language / Linguagem de Modelagem Unificada
XMI XML Metadata Interchange / Intercmbio de Metadados em XML
Sumrio
Introduo
19
1.1
A tese . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
1.2
Definio do escopo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
1.3
Estrutura da dissertao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
Conceitos envolvidos
27
2.1
Reutilizao de software . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
2.2
Desenvolvimento orientado a modelos . . . . . . . . . . . . . . . . . . . . . .
34
2.3
Consideraes finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
50
Reutilizao de software e desenvolvimento orientado a modelos
51
3.1
Anlise SCV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
51
3.2
Implementao da variabilidade . . . . . . . . . . . . . . . . . . . . . . . . .
57
3.3
61
Viso geral da abordagem
63
4.1
Objetivo da abordagem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
63
4.2
Estrutura da abordagem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
65
4.3
Abrangncia da abordagem . . . . . . . . . . . . . . . . . . . . . . . . . . . .
66
4.4
69
Anlise de domnio orientada a modelos
71
5.1
Objetivos da anlise de domnio . . . . . . . . . . . . . . . . . . . . . . . . .
72
5.2
Atividades da anlise de domnio . . . . . . . . . . . . . . . . . . . . . . . . .
73
5.3
92
Projeto de domnio orientado a modelos
95
6.1
Objetivos do projeto de domnio . . . . . . . . . . . . . . . . . . . . . . . . .
98
6.2
Atividades do projeto de domnio . . . . . . . . . . . . . . . . . . . . . . . . .
99
6.3
Consideraes finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Implementao de domnio orientada a modelos
123
7.1
Objetivos da implementao do domnio . . . . . . . . . . . . . . . . . . . . . 124
7.2
Atividades da implementao do domnio . . . . . . . . . . . . . . . . . . . . 126
7.3
Modelo de processo
149
8.1
Ciclo principal do modelo de processo: evoluo dos sub-domnios . . . . . . . 150
8.2
Ciclo de projeto do modelo de processo: evoluo arquitetural . . . . . . . . . 152
8.3
Ciclo de implementao do modelo de processo: produo dos artefatos

reutilizveis e documentao . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
8.4
Avaliao
157
9.1
Definio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
9.2
Descrio dos projetos utilizados nos estudos empricos e sua execuo . . . . 170
9.3
Coleta dos dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
9.4
Resultados e discusso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
9.5
Anlise das hipteses e concluses . . . . . . . . . . . . . . . . . . . . . . . . 189
9.6
Ameaas validade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
9.7
10 Trabalhos relacionados
195
10.1 Trabalhos acadmicos sobre desenvolvimento orientado a modelos . . . . . . . 195

10.2 Trabalhos relacionados abordagem desta tese . . . . . . . . . . . . . . . . . 197
10.3 Trabalhos relacionados com o uso de mtricas para MDD e reutilizao . . . . 203
10.4 Consideraes finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
11 Concluses
209
11.1 Principais contribuies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209

11.2 Publicaes resultantes da tese . . . . . . . . . . . . . . . . . . . . . . . . . . 211
11.3 Lies aprendidas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
11.4 Trabalhos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
11.5 Consideraes finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
Referncias
219
Apndice A -- Tcnicas para reutilizao de software
237
Apndice B -- MDD: mito ou realidade?
257
Apndice C -- Relao entre a abordagem e modelos de maturidade
261
Apndice D -- Reproduo na ntegra da entrevista referente ao estudo emprico

envolvendo o domnio de eventos cientficos
273
19
Introduo
H duas dcadas, Krueger (1992) colocou a reutilizao de software como uma

preocupao constante para organizaes que buscam aumento na qualidade e produtividade
em seu processo de desenvolvimento. A qualidade pode ser melhorada por meio da reutilizao
de experincias comprovadas, incluindo artefatos em diferentes nveis de abstrao, produtos
e processos. Neste sentido, tambm ocorre um aumento na produtividade, uma vez que essas
experincias so reaproveitadas, evitando-se a necessidade de constru-las novamente (BASILI;
BRIAND; MELO,
1996).
No entanto, a idia de reutilizar ao invs de construir ainda mais antiga, remetendo

s origens da prpria engenharia de software. Em 1968, na conferncia da OTAN que
considerada como o bero da engenharia de software1 , McIlroy (1968) apresentava idias
referentes reutilizao de componentes de software produzidos em massa e os possveis
benefcios que tal abordagem traria chamada crise do software2 . A Figura 1 ilustra esse
momento histrico, que levou a uma extensa pesquisa em busca do ideal da reutilizao em
larga escala.
Desde ento, a pesquisa na rea evoluiu, produzindo uma diversidade de trabalhos
envolvendo reutilizao de software. Os esforos que hoje podem ser encontrados na literatura
incluem as idias de engenharia de domnio (NEIGHBORS, 1980; STARS, 1993; SIMOS et al., 1996;
JACOBSON; GRISS; JONSSON,
1997; GRISS; FAVARO; DALESSANDRO, 1998; KANG et al., 1998),
desenvolvimento baseado em componentes (DBC) (SZYPERSKI, 1999; SAMETINGER, 1997),

e mais recentemente, as idias de linhas de produto (CLEMENTS; NORTHROP, 2002). Existe
tambm uma vasta literatura na rea de repositrios e busca de artefatos (LUCRDIO; ALMEIDA;
PRADO,
2004). Fora da academia, diferentes relatos sobre fatores e prticas de sucesso podem
ser encontrados, em empresas como Motorola (JOOS, 1994) e Hewlett-Packard (GRISS, 1995).
1O
termo Engenharia de Software foi criado nesta conferncia como uma provocao, para ressaltar as
necessidades de se empregar, no desenvolvimento de software, os conceitos j consagrados em outras engenharias
(NAUR; RANDELL, 1968)
2 Famoso termo que tambm se originou nesta mesma conferncia, referente ao problema de se construir
sistemas de software grandes e confiveis de uma maneira controlvel e eficiente
20
Figura 1:
Foto do momento em que o mundo conhecia as primeiras
idias sobre desenvolvimento baseado em componentes,
durante palestra
de M.D. McIlroy em uma conferncia de 1968 organizada pela OTAN.
(http://homepages.cs.ncl.ac.uk/brian.randell/NATO/N1968/index.html)
Porm, mesmo aps dcadas de pesquisa, ainda no possvel afirmar que existe uma
abordagem voltada para reutilizao de software que seja amplamente utilizada e que permita
que uma organizao alcance os benefcios de qualidade e produtividade almejados por McIlroy
e muitos outros desde ento. Um estudo recente (ALMEIDA, 2007) identificou que a maioria das
abordagens originadas na academia focada em partes isoladas do problema, sem considerar a
relao existente entre elas, e que os casos de sucesso relatados por empresas se devem a fatores
muito especficos, no sendo genricos o bastante para serem aplicveis fora de seu contexto
original.
Deve ficar claro que reutilizao de software no envolve somente fatores tcnicos, como
a utilizao de mtodos, ferramentas ou mtricas. Envolve tambm fatores no-tcnicos, tais
como educao, treinamento, motivao, incentivos e comprometimento organizacional, alm
de um bom planejamento e o apoio gerencial (ALMEIDA et al., 2004).
Dentre os fatores tcnicos, destaca-se o papel do processo de software, que ajuda a incluir
no desenvolvimento uma maior capacidade de se lidar com as restries de tempo e esforo,
tornando-o mais parecido com engenharia e menos com arte (ROMBACH, 2000). Um processo
que possa ser observado, controlado e constantemente melhorado pode contribuir para que
os benefcios da reutilizao sejam alcanados, por meio de prticas eficientes de trabalho
disseminadas facilmente entre os indivduos de uma organizao, sem depender de talentos
individuais.
21
A necessidade de um processo sistemtico de reuso

Em termos de reutilizao de software, faz-se necessrio um mtodo flexvel, que possa ser
adaptado para diferentes situaes, que possua diretivas e suporte suficientes, e que no seja
muito vago, caso contrrio o mesmo no ir atender s necessidades de variadas situaes da
indstria sem uma forte interpretao e suporte adicionais (BAYER et al., 1999).
Essa opinio compartilhada por muitos autores da rea de reutilizao, podendo ser
encontrada em relatrios de empresas, tais como (ENDRES, 1993; BAUER, 1993; GRISS,
1994, 1995; JOOS, 1994), pesquisas informais (FRAKES; ISODA, 1994) e estudos empricos
(RINE, 1997; MORISIO; EZRAN; TULLY, 2002; ROTHENBERGER et al., 2003).
Todos esses
trabalhos mostraram que adotar um processo pode ser uma maneira efetiva de se alcanar os
benefcios da reutilizao de software.
Porm, os processos existentes atualmente apresentam algumas falhas e falta de
detalhes em atividades importantes, tais como o desenvolvimento para reutilizao e o
desenvolvimento com reutilizao, alm de nfase em atividades especficas (anlise, projeto
ou implementao), e no no processo todo. Mesmo as recentes idias de linhas de produto de
software ainda no produziram consenso com relao a quais atividades (incluindo entradas,
sadas e artefatos produzidos) e requisitos um processo efetivo de reutilizao deve possuir
(ALMEIDA et al., 2005). Este fato tambm pode ser verificado no cenrio brasileiro, onde
um estudo de levantamento realizado em empresas (LUCRDIO et al., 2008) verificou que a
maioria das organizaes investigadas (cerca de 65%) no se preocupa com reutilizao em
seus processos de software.
Neste ponto chega-se a uma primeira motivao importante: ns estamos precisando mais
de um processo sistemtico e mais completo de reutilizao, do que idias para resolver
partes mais especficas do problema. Neste sentido, a combinao de conceitos e tcnicas
existentes em uma forma nova e inexplorada pode oferecer melhores contribuies, tanto para
o mundo acadmico como para a indstria. Esta opinio j foi expressa por Jim Neighbors,
um dos pioneiros em reutilizao de software, dcadas atrs: organizaes acadmicas em
cincia da computao parecem preferir o trabalho em novas teorias. Porm, alguns dos mais
bem-sucedidos trabalhos acadmicos so uma fuso e formalizao de tcnicas de sucesso.
(NEIGHBORS, 1989).
Os problemas com o desenvolvimento de software como realizado atualmente
Talvez a maior mudana que se pode testemunhar desde o nascimento da cincia da
computao foi o grau com o qual computadores se tornaram essenciais em nossas vidas.
22
Apenas imagine como sua rotina diria seria afetada se voc no tivesse acesso a nenhum
tipo de dispositivo computacional, e voc poder perceber o quo incrivelmente pervasiva esta
tecnologia se tornou.
Neste sentido, o software - a alma de um computador, responsvel pela a operao destas
mquinas vitais - precisa sobreviver em tal cenrio de mudanas drsticas e constantes. A
histria mostrou que cientistas e profissionais da rea da computao, especialmente aqueles
envolvidos com desenvolvimento de software, so especialistas na arte da mudana. Novas
linguagens de programao e ambientes de desenvolvimento integrados sempre buscaram seguir
os avanos do hardware, e foram razoavelmente bem sucedidos at ento.
Mas chegou-se a um ponto onde o software no deve ser apenas confivel, mas tambm
operar em ambientes computacionais embarcados e distribudos, comunicar-se utilizando uma
grande variedade de paradigmas de comunicao, e se adaptar dinamicamente a mudanas
nos ambientes operacionais (FRANCE; RUMPE, 2007). Isto se deve no apenas s tecnologias
utilizadas, que se tornaram significativamente mais complexas nos ltimos anos, mas tambm
porque estas tecnologias mudam mais rapidamente do que os negcios para os quais as mesmas
procuram dar suporte (UHL, 2003).
O fato : software se tornou um artefato muito complexo. Ainda no to complexo
ao ponto de no sermos mais capazes de constru-lo, mas o esforo necessrio para tanto,
utilizando tecnologias centradas em cdigo-fonte, muito grande (KLEPPE; WARMER; BAST,
2003; FRANCE; RUMPE, 2007).
Nas palavras de France e Rumpe (2007), este esforo chega a ser hercleo: construir
sistemas de software complexos de forma manual pode ser equiparado a construir pirmides
no antigo Egito. Ns nos maravilhamos com tais implementaes de software de forma
bastante parecida com a qual arquelogos se maravilham com as pirmides: essa admirao
principalmente baseada na apreciao do esforo requerido para se lidar com as significativas
complexidades acidentais que surgem do uso de tecnologias inadequadas .
A proposta do MDD (Model-Driven Development ou Desenvolvimento Orientado a
Modelos) justamente resolver todos esses problemas, enfatizando a importncia de modelos
no processo de desenvolvimento de software (MELLOR; CLARK; FUTAGAMI, 2003). No MDD, os
modelos no so apenas papel que auxiliam nas tarefas de desenvolvimento. Ao invs disso,
eles so parte constituinte do software, assim como o cdigo. A proposta reduzir a distncia
semntica entre o domnio do problema e o domnio da implementao/soluo, atravs de
modelos de alto nvel que protegem os desenvolvedores de software das complexidades da
plataforma de implementao (FRANCE; RUMPE, 2007), e transformaes que geram artefatos de
23
implementao automaticamente, de forma a refletir a soluo expressa nos modelos (SCHMIDT,

2006).
O MDD efetivamente utilizado atualmente, levando a considerveis benefcios em termos
de ganhos de produtividade e qualidade. Por exemplo, a Nokia relata conseguir desenvolver
novos telefones celulares at dez vezes mais rpido e a Lucent reporta ganhos de produtividade
de trs a dez vezes, dependendo do produto (TOLVANEN, 2004). Alguns autores citam uma
reduo de 50 para 1 em termos de linhas de especificao/cdigo, que pode ser alcanada
atravs de tcnicas orientadas a modelos (WILE, 2004).
Conclui-se que o MDD no pode ser ignorado como uma forma efetiva de se melhorar
as atuais prticas de desenvolvimento de software.
Apesar das dificuldades tcnicas e
complexidade adicional para se construir o suporte necessrio para o desenvolvimento orientado

a modelos, no final pode ser vantajoso gastar esforos extras em busca de suas promessas.
Reutilizao de software orientada a modelos
Os problemas levantados na seo anterior se tornam ainda mais crticos quando se fala
em reutilizao de software, uma vez que o princpio de se construir uma vez para reutilizar
vrias vezes requer que o software reutilizvel - cdigo-fonte e outros artefatos - seja facilmente
adaptvel a diferentes contextos, plataformas e ambientes. Isto significa que hoje, um artefato
precisa ser duas vezes mais reutilizvel do que antes, porque no apenas ele precisa ser
reutilizvel em uma aplicao diferente na mesma plataforma e ambiente, mas tambm em
uma aplicao diferente que roda em plataformas e ambientes diferentes.
Assim, a reutilizao de software uma das reas que pode mais se beneficiar com o MDD.
Os principais pesquisadores da rea, como Neighbors (1980), Krueger (1992), Griss (1995),
Frakes e Isoda (1994), Jacobson, Griss e Jonsson (1997), sempre defenderam a idia de que
os verdadeiros benefcios da reutilizao de software somente podem ser atingidos quando
artefatos de alto nvel so reutilizados, alm do cdigo-fonte. Com o MDD, onde modelos
so artefatos de primeira classe, isto exatamente o que acontece.
Mas apesar de parecerem uma combinao natural (OMG, 2003), reutilizao de software
e desenvolvimento orientado a modelos so reas bastante distintas. H trabalhos que tentam
combinar estes dois paradigmas, mas a extenso com a qual MDD utilizado para incrementar
reutilizao - ou a reutilizao utilizada para incrementar o MDD - ainda no suficiente.
Existem abordagens de reutilizao que utilizam MDD para automatizar partes do processo,
mas elas ignoram outras partes importantes, como o projeto arquitetural visando o MDD,
por exemplo. Da mesma forma, existem abordagens orientadas a modelo que focam em
24
reutilizao, mas geralmente elas enfatizam a implementao e o suporte a uma linguagem.

O que se constata que o mesmo que acontece com processos de reutilizao em geral se
repete com relao a processos de reutilizao orientados a modelos.
1.1
A tese
Dados: (i) os benefcios que o desenvolvimento orientado a modelos podem acrescentar s

prticas atuais de desenvolvimento de software; (ii) o potencial de desenvolvimento orientado a
modelos para resolver alguns dos problemas da reutilizao; e (iii) a necessidade de um processo
completo e sistemtico de reutilizao de software; uma importante questo levantada:
podem estes trs elementos serem combinados de forma a aumentar ou melhorar os nveis
de reutilizao alcanados por uma organizao de software, quando comparado com um
processo no orientado a modelos?
A tese sendo defendida a de que a combinao entre o desenvolvimento orientado a
modelos e reutilizao de software em um processo sistemtico pode elevar e/ou melhorar
os nveis de reutilizao alcanados por uma organizao de software, quando comparado
com um processo no orientado a modelos. Para isso, a preocupao com o MDD
deve estar presente em todas as etapas do processo, incluindo a anlise, o projeto e a
implementao.
Para validar esta tese, foi portanto definida de uma abordagem sistemtica para
reutilizao de software, utilizando tcnicas do desenvolvimento orientado a modelos, e
que cobre as etapas de anlise, projeto e implementao de um domnio reutilizvel.
Na busca por este objetivo, os seguintes pontos foram explorados:
Quais elementos so necessrios para que o processo de software de uma organizao
seja capaz de promover os objetivos da reutilizao?
Quais elementos so necessrios para que o processo de software de uma organizao
seja capaz de promover os objetivos do desenvolvimento orientado a modelos?
Quais tcnicas do MDD podem ser utilizadas para se efetivamente elevar e/ou melhorar
o nvel de reutilizao de software?
Quais partes do processo de reutilizao podem se beneficiar das tcnicas do MDD
identificadas?
Como combinar MDD e reutilizao em um nico processo de software?
25
Alm desses pontos, para avaliar se os nveis de reutilizao so de fato maiores ou

melhores quando estes elementos so combinados, trs estudos empricos foram desenvolvidos.
Estes estudos propiciaram destacar as principais contribuies e resultados desta pesquisa.
1.2
Definio do escopo
importante ressaltar que o foco deste trabalho no foi pesquisar cada uma das linhas de
pesquisa, reutilizao e MDD, de forma individual e em profundidade. Isso seria um trabalho
extremamente complexo que excederia o tempo estipulado para uma pesquisa em nvel de
doutorado. Ao invs disso, buscou-se combinar as tcnicas j estabelecidas em um processo
novo, de maneira a agregar os benefcios de ambas abordagens.
Alm disso, foi priorizada a definio de uma abordagem prtica, sem lacunas e usvel, em
detrimento a uma cobertura demasiadamente extensa do ciclo de vida do software. Esta no
apenas foi uma das motivaes desta pesquisa, mas tambm foi importante para que a avaliao
final, que consistiu em colocar a abordagem em prtica em cenrios reais, pudesse ser realizada
sem muitas dificuldades. Caso a abordagem apresentasse pontos indefinidos, a mesma no
poderia ser utilizada nos estudos empricos sem esforos adicionais.
Com base nestes critrios, um primeiro ponto a ser ressaltado a cobertura do processo de
reutilizao. Trabalhou-se com o foco principal no desenvolvimento para a reutilizao, pois
sem este o desenvolvimento com reutilizao no faz sentido. Foram definidas as atividades
para construir os artefatos reutilizveis (modelos, transformadores, geradores, etc.) de forma
clara, podendo ser seguidas passo-a-passo em uma organizao de software. O desenvolvimento
com reutilizao de uma maneira sistemtica no foi abordado.
Com relao aos aspectos relacionados ao desenvolvimento orientado a modelos, o foco
no est em definir um processo completo para MDD, e sim em estender um processo voltado
reutilizao com os conceitos do MDD. Assim, foram definidas atividades para construo
de modelos, transformadores e geradores a serem reutilizados no desenvolvimento de software.
Est fora do escopo, portanto, tratar de atividades como manuteno e evoluo destes artefatos.
Outro ponto que d margem a infinitas possibilidades o ambiente de suporte ao
MDD. Ferramentas so parte essencial do MDD, e existem em inmeras opes para o
desenvolvimento orientado a modelos.
Nesta pesquisa, trabalhou-se com ferramentas j
existentes, tais como aquelas apresentadas na Seo 2.2.2, ao invs de contruir o ambiente
ou ferramentas a partir do zero. Isto foi possvel devido ao atual cenrio de MDD, que j conta
com diversas opes concretas e que so efetivamente utilizadas na prtica.
26
Em resumo, est fora do escopo desta pesquisa:

A definio detalhada das atividades do desenvolvimento com reutilizao;
Atividades de manuteno dos artefatos, tais como aquelas relacionadas ao
gerenciamento de configurao, por exemplo;
Desenvolvimento de ferramentas para o desenvolvimento orientado a modelos, tais como
ferramentas para transformao ida-e-volta, ou ferramentas para validao de modelos e
de transformaes, que so importantes, porm no essenciais para que o processo possa
ser executado.
Mais detalhes sobre o escopo da pesquisa, em termos das prticas que esto includas e
excludas da abordagem definida nesta tese, encontram-se no Captulo 4.
1.3
Estrutura da dissertao
Neste primeiro captulo apresenta-se a motivao e objetivos da pesquisa. O restante da

dissertao est estruturado da seguinte maneira:
No Captulo 2 discutem-se os fundamentos sobre a reutilizao de software e o
desenvolvimento orientado a modelos, incluindo os principais conceitos, tcnicas e
abordagens existentes;
No Captulo 3 so discutidos alguns pontos referentes interseco entre os conceitos da
reutilizao de software e do desenvolvimento orientado a modelos;
No Captulo 4 apresentada uma viso geral da abordagem orientada a modelos para
reutilizao de software;
Nos Captulos 5, 6 e 7 so apresentadas as trs fases da abordagem: anlise, projeto e
implementao do domnio;
No Captulo 8 discute-se um possvel modelo de processo para a utilizao da abordagem;
No Captulo 9 so apresentados resultados da avaliao da abordagem;
No Captulo 10 so apresentados os trabalhos relacionados; e
No Captulo 11 so apresentadas as consideraes finais, contribuies e trabalhos
futuros.
27
Conceitos envolvidos
Esta tese envolveu duas abrangentes linhas de pesquisa: reutilizao de software e

desenvolvimento orientado a modelos. Com o objetivo de esclarecer melhor cada linha e seus
pontos relevantes a esta tese, neste captulo so apresentados os principais conceitos e tcnicas
relacionadas essas duas linhas.
2.1
Reutilizao de software
A reutilizao de software j foi considerada como uma bala de prata para resolver os
problemas da crise do software. A realidade, porm, mostrou que forjar tal bala muito mais
difcil do que se supunha, e que os desafios a serem enfrentados so mais abrangentes do que
os meros aspectos tcnicos normalmente tidos como os nicos relevantes.
Nesta seo apresentam-se os principais conceitos relacionados reutilizao de software,
as principais tcnicas existentes, e uma discusso mais detalhada sobre a relao entre estes
pontos e o processo de software.
2.1.1
Conceitos da reutilizao de software
De acordo com Krueger (1992), reutilizao de software o processo de criao de software

a partir de software j existente, ao invs de construir do incio. O termo reutilizao de
software comumente confundido com o reutilizao de cdigo, talvez por ser esta a forma
mais simples e melhor compreendida de reutilizao (POULIN; CARUSO; HANCOCK, 1993).
Porm, a reutilizao de cdigo no representa o maior benefcio em potencial, pois descarta
conhecimento importante que se encontra em outros artefatos, como aqueles produzidos durante
anlise e projeto.
De fato, qualquer artefato pode ser reutilizado. Segundo DSouza e Wills (1999), um
artefato reutilizvel uma parte do trabalho que pode ser utilizado em mais de um projeto.
Nesse sentido, podem ser reutilizados, alm do cdigo-fonte, artefatos como cdigo compilado,
28
casos de teste, modelos, interfaces para usurio, e at mesmo planos e estratgias.

Algumas motivaes para se reutilizar software so a reduo de tempo e esforo no
desenvolvimento. Pode-se tambm aumentar a qualidade do software, reutilizando-se artefatos
com qualidade assegurada, o que tambm acaba por reduzir tempo e esforos na manuteno
(KRUEGER, 1992; LIM, 1994).
Mas a principal motivao que reutilizao mais do
que apenas uma vantagem que pode ser completamente descartada. Muitas organizaes de
desenvolvimento de software, mesmo aquelas que alegam no ter preocupao explcita com
reutilizao, vivem ou morrem com base em quo eficientemente elas geram, assimilam e
reutilizam seu conhecimento (DESOUZA; AWAZU; TIWANA, 2006).
Estas afirmaes levam seguinte discusso, normalmente associada reutilizao de
software: sendo relativamente antiga, com pelo menos quatro dcadas, por que a reutilizao
ainda no uma prtica consagrada, disseminada e bem-sucedida dentro da Engenharia de
Software? Indo alm, sendo uma prtica considerada vital para o sucesso (DESOUZA; AWAZU;
TIWANA,
2006), como as organizaes vm sobrevivendo sem empreg-la?
Na verdade, essa discusso ignora um aspecto importante: a reutilizao existe desde

o surgimento do software em forma armazenada, em 1947, quando Wheeler e Wilkes
desenvolveram o conceito de jump, um precursor do comando goto, para o computador
EDSAC na universidade de Cambridge (OMG, 2003). Desta forma, podiam reutilizar subrotinas
pre-construdas para a soluo de problemas numricos comuns. Desde ento, programadores
efetivamente reutilizam software, seja procurando em seus registros pessoais, projetos antigos,
repositrios pblicos ou mesmo sua prpria memria (DESOUZA; AWAZU; TIWANA, 2006).
Alm disso, projetos de software raramente ou mesmo nunca envolvem somente elementos
completamente novos. A literatura mostra que entre 40% e 60% do cdigo de uma aplicao
pode ser reutilizado em outra aplicao, 60% dos artefatos de projeto so reutilizveis, 75% das
funes so comuns a mais de um programa, e apenas 15% do cdigo de um sistema nico e
novo (EZRAN; MORISIO; TULLY, 2002). Outros autores citam taxas de potencial de reutilizao
que variam entre 15% e 85% (MILI; MILI; MILI, 1995). Ou seja, reutilizao algo natural e
intrnseco ao desenvolvimento de software.
A grande questo, que vem motivando dcadas de pesquisa, que a reutilizao
no-sistemtica, que realizada de forma ad hoc, dependente de iniciativa, conhecimento e
talento individuais, no implantada de forma consistente na organizao, e sujeita a pouco
ou nenhum tipo de controle e planejamento gerenciais. Muitas vezes tem efeitos caticos,
alimentando a cultura do herosmo individual e apagamento de incndios e amplificando
problemas e defeitos ao invs de reduzi-los (EZRAN; MORISIO; TULLY, 2002).
29
Dessa forma, o que necessrio a reutilizao sistemtica (FRAKES; ISODA, 1994). A

reutilizao sistemtica consiste no entendimento sobre como possvel contribuir para os
objetivos de negcio, na definio de estratgias tcnicas e gerenciais para se extrair o mximo
da reutilizao, na integrao com processos de software e de melhoria, entre outros aspectos
(EZRAN; MORISIO; TULLY, 2002) que fazem com que a reutilizao ocorra de forma controlada
e repetvel.
Porm, colocar essas idias em prtica uma tarefa complexa, pois apenas agrupar
um conjunto de artefatos reutilizveis em um repositrio, disponibilizando-os para os
desenvolvedores, no suficiente.
Existe uma srie de fatores envolvidos: gerenciais,
organizacionais, econmicos, conceituais, legais e tcnicos (SAMETINGER, 1997; FRAKES;

ISODA,
1994; MORISIO; EZRAN; TULLY, 2002; LUCRDIO et al., 2008). Estes fatores tornam
muitos casos de sucesso em reutilizao, como por exemplo os descritos por Bauer (1993),
Endres (1993), Griss (1994, 1995), Joos (1994) mais a exceo do que a regra, e fazem com
que a pesquisa na rea ainda tenha muitos pontos em aberto.
Esta tese trata da perspectiva tcnica da reutilizao, mais especificamente os pontos
relacionados ao processo de software. Nesse contexto, existem vrias abordagens que visam
promover a reutilizao de software. Apesar de serem distintas, todas elas compartilham quatro
conceitos bsicos (BIGGERSTAFF; RICHTER, 1989), conforme citados por Krueger (1992):
Abstrao : o princpio essencial da reutilizao.
Para que um determinado artefato
de software possa ser reutilizado, ele precisa antes ser compreendido, de forma que
o reutilizador consiga saber se ele ir atender s suas necessidades, se necessrio
fazer alguma adaptao, quanto esforo ser necessrio para essa adaptao, ou se
no possvel reutiliz-lo.
Sem abstrair os detalhes, o reutilizador gastaria muito
tempo examinando cada artefato em busca dessas respostas. Pode-se tambm pensar
na abstrao como sendo uma separao entre uma parte visvel ou abstrata, que contm
as informaes mais conceituais necessrias reutilizao, e uma parte escondida, que
contm as informaes mais detalhadas, normalmente ligadas implementao;
Seleo : bibliotecas de software, principalmente em grandes organizaes, tendem a ser
imensas, envolvendo um grande nmero e diversos tipos de artefatos que podem ser
reutilizados. Encontrar algo de til em tal cenrio uma tarefa difcil, e uma busca manual
pode levar mais tempo do que construir o artefato novamente. Por isso, a maioria das
abordagens para reutilizao emprega algum tipo de tcnica para agilizar a seleo, tais
como ndices, catlogos, busca automtica, entre outras (LUCRDIO; ALMEIDA; PRADO,
2004);
30
Adaptao : a princpio, qualquer artefato pode ser reutilizado em um contexto diferente

daquele em que foi projetado inicialmente, uma vez que se saiba que o mesmo ir atender
s necessidades do reutilizador. O fator determinante a quantidade de esforo necessrio
para adaptar esse artefato para seu novo contexto. Para diminuir esse esforo, o principal
foco da maioria das abordagens voltadas reutilizao tentar criar artefatos genricos
o suficiente para atenderem s necessidades de diversas aplicaes possveis. Esses
artefatos so ento adaptados para o novo contexto, por meio de parmetros, arquivos
de configurao, ou mesmo pequenas modificaes; e
Integrao : uma das dificuldades inerentes reutilizao diz respeito arquitetura do
software final, uma vez que ele ir conter pedaos de outros sistemas de software. Quando
necessrio integrar artefatos de software que no foram originalmente projetados para
operar de forma conjunta, surge uma srie de desafios e dificuldades, como por exemplo
tentar manter a consistncia e padronizao das interfaces, prever possveis necessidades
de adaptao ou modificao, e realizar testes de forma a validar a funcionalidade em
nvel de sistema. O desastre com o foguete europeu Ariane 5 (JEZEQUEL; MEYER, 1997)
e os enormes prejuzos decorrentes alertam para a importncia deste aspecto.
Estes quatro conceitos bsicos esto presentes nas diferentes formas de reutilizao,
desde o simples processo de se copiar um trecho de cdigo de um local para outro, at
as abordagens comumente descritas na literatura, como o desenvolvimento baseado em
componentes (SAMETINGER, 1997; SZYPERSKI, 1999), linguagens especficas de domnio
(DEURSEN; KLINT; VISSER, 2000), programao generativa (CZARNECKI; EISENECKER, 2000),
frameworks (JOHNSON, 1997b), padres (BUSCHMANN et al., 1996) e reengenharia de software
(JACOBSON; LINDSTROM, 1991)1 .
2.1.2
O processo de reutilizao de software
A simples adoo de uma ferramenta ou tcnica no suficiente para que os benefcios

das reutilizao sejam alcanados em sua mxima extenso, sendo necessrios outros fatores,
como um bom gerenciamento organizacional e infra-estrutura voltados reutilizao (RINE;
SONNEMANN,
1998). Alm desses, conforme j discutido no Captulo 1, o foco no processo
de extrema importncia para uma organizao em busca da reutilizao de software.

Ainda no existe um consenso sobre quais as atividades so necessrias para um processo
sistemtico de reutilizao. Existem diversas abordagens distintas, cada uma com um foco
1O
apndice A apresenta uma anlise mais aprofundada destas abordagens.
31
maior em determinada parte do processo, procurando solucionar parte do problema. Em

termos gerais, um processo de reutilizao de software deve definir ao menos duas atividades
essenciais: o desenvolvimento para reutilizao, que consiste no desenvolvimento dos artefatos
de software que sero posteriormente reutilizados, e o desenvolvimento com reutilizao,
que consiste no desenvolvimento de aplicaes que reutilizam os artefatos previamente
desenvolvidos.
Esta distino entre desenvolvimento para/com reutilizao o ponto fundamental da
abordagem de engenharia de software conhecida como Linha de Produtos de Software
(CLEMENTS; NORTHROP, 2002; LINDEN; SCHMID; ROMMES, 2007), descrita a seguir.
2.1.2.1
Linhas de produtos de software
A origem desta abordagem pode ser rastreada at um trabalho da dcada de 1970, de

Parnas (1976), o mesmo autor que definiu os conceitos de encapsulamento da informao, um
dos fundamentos da orientao a objetos. Neste trabalho descrito o conceito de famlias de
programas, e apesar de inicialmente ter focado na variabilidade em termos das caractersticas
no funcionais, Parnas estabelece a base para as linhas de produto de software (LINDEN;
SCHMID; ROMMES,
2007).
O princpio definido era o de estudar primeiro o que os programas de uma mesma

famlia tinham em comum, para depois tentar entender o que os diferenciava. Em seguida,
duas alternativas de mtodo produziam programas incompletos que implementavam as partes
comum da famlia, e deixavam as partes variveis para serem instanciadas posteriormente: o
mtodo de refinamento por etapas (stepwise refinement), que produzia um programa no qual
alguns tipos de operandos e operadores eram deixados sem implementao; e o mtodo de
especificao dos mdulos, que baseava-se na especificao em alto nvel de unidades de
comportamento de programas e no encapsulamento da informao para que o restante do cdigo
pudesse ser idealizado e construdo. Para construir um novo programa, um desenvolvedor
reutilizava este programa incompleto e o completava de acordo com as variabilidades desejadas,
seja providenciando os operadores e operandos, ou efetivamente implementando os mdulos
especificados.
Ou seja, h uma mudana de foco. Ao invs de desenvolver software considerando os
requisitos de um nico sistema, tenta-se desenvolver software que consiga atender aos requisitos
de um conjunto de sistemas similares, de forma que possvel reaproveitar as partes comuns e
apenas desenvolver o que completamente novo. Na nomenclatura tpica da rea de linhas de
produtos de software, este conjunto de sistemas similares chamado de famlia de produtos, ou
32
domnio de aplicaes. As partes reutilizveis so a arquitetura de referncia e os artefatos do

ncleo (core assets). O desenvolvimento das partes comuns (desenvolvimento para reutilizao)
chamado de Engenharia de Domnio e o desenvolvimento de um produto (desenvolvimento
com reutilizao), de Engenharia de Aplicaes (CLEMENTS; NORTHROP, 2002; MILI et al., 2002;
LINDEN; SCHMID; ROMMES,
2007).
Com exceo de uma preocupao maior com aspectos de negcio e alguns avanos em
termos de mtodos, os conceitos apresentados por Parnas so praticamente os mesmos que
fundamentam as linhas de produtos (LINDEN; SCHMID; ROMMES, 2007):
1. Gerenciamento da variabilidade:
consiste na determinao,
modelagem e
implementao das comunalidades e variabilidades de uma famlia de produtos

(programas). Equivale anlise das semelhanas e diferenas entre programas de uma
mesma famlia;
2. Definio arquitetural: uma arquitetura de referncia tem papel chave na linha
de produtos, oferecendo meios concretos para que diferentes produtos possam ser
instanciados. Equivale definio de quais pontos de um programa devem ser deixados
sem implementao, de acordo com as variabilidades identificadas; e
3. Abordagem em dois ciclos:
consiste na diviso entre engenharia de domnio
e engenharia de aplicaes, de forma equivalente ao refinamento por etapas ou

especificao dos mdulos e criao dos programas.
O grande diferencial das abordagens atuais a preocupao em definir o escopo da famlia
de produtos de acordo com objetivos de negcio e estratgias de mercado, visando vantagens
a longo prazo. Em outras palavras, define-se quais produtos devem ser desenvolvidos, quais
as caractersticas mais importantes a serem implementadas, entre outras questes (LINDEN;
SCHMID; ROMMES,
2007). Esta preocupao faz com que as linhas de produtos sejam atrativas
para a indstria, que j acumula diversos relatos de sucesso, conforme pode ser constatado no
Hall da Fama em linhas de produto2 , que conta com empresas como Philips, Boeing, Lucent,
entre outras que conseguiram adotar esta prtica com sucesso.
2.1.2.2
Elementos de um processo de reutilizao
Apesar da falta de consenso, um estudo recente (GARCIA et al., 2007, 2008) analisou diversos
trabalhos e modelos descritos na literatura, buscando identificar quais elementos de processo so
2 http://www.sei.cmu.edu/productlines/plp_hof.html
33
necessrios para que a reutilizao possa ser bem sucedida. Este estudo incluiu os esforos do
SEI/CMU (Software Engineering Institute / Carnegie Mellon University) (DOE; BERSOFF, 1986;
PYSTER; BARNES, 1988; HOLIBAUGH et al., 1989), mais focados na rea de custos relacionados
reutilizao; do SPC (Software Productivity Consortium, primeiro com o RMM (Reuse Maturity
Model) (KOLTUN; HUDSON, 1991), depois com o RPC (Reuse Capability Model) (DAVIS, 1993) e
finalmente com o RRM (Reuse Reference Model) (RINE; NADA, 2000), modelos que descrevem
as principais prticas de reutilizao em uma organizao de software; e de outros importantes
autores da rea, como Prieto-Daz (1991, 1993), Sherif, Appan e Lin (2006) e Morillo et al.
(2006). No estudo de Garcia et al. (2007, 2008) foi definido um modelo bastante completo, que
rene as prticas recentes relacionadas reutilizao de software.
O modelo (Figura 2) baseado em 18 reas de processo (AP) que descrevem as atividades
essenciais para uma organizao que deseja incorporar a reutilizao sistemtica em seu
processo.
Figura 2: Modelo de maturidade em reutilizao (GARCIA et al., 2007, 2008)

As reas de processo esto agrupadas em quatro nveis, descritos a seguir:
Nvel 1 - Incompleto: neste nvel, apenas o desenvolvimento de software tradicional

realizado. Prticas de reutilizao so usadas esporadicamente ou mesmo ignoradas e
desencorajadas pela gerncia. Reutilizao fruto de esforo individual, e os custos da
reutilizao so desconhecidos;
Nvel 2 - Bsico: este nvel caracterizado pela utilizao bsica de artefatos com
potencial de reutilizao. Engloba algumas atividades iniciais orientadas reutilizao,
como a manuteno de mtodos e tcnicas bsicas de reutilizao (AP1), o planejamento
da reutilizao (AP2), a definio dos objetivos da reutilizao (AP3) e a implementao
do domnio (AP4), porm ainda sem a preocupao com anlise e projeto voltados
reutilizao;
34
Nvel 3 - Definido: neste nvel o principal foco de engenharia o suporte variabilidade.

Enquanto no nvel 2 a preocupao era aumentar o nvel de reutilizao de artefatos
individuais, aqui o foco oferecer um suporte global variabilidade do domnio,
principalmente com as prticas de controle e monitoramento do processo de reutilizao
(AP5), integrao com o ciclo de vida do software (AP6), anlise e projeto do
domnio (AP7 e AP8). Tambm neste nvel introduz-se a preocupao com a rea
de qualidade, incluindo o treinamento em reutilizao (AP9), gerenciamento de uma
unidade de reutilizao (AP10), programas de mtricas e de avaliao organizacional
(AP11 e AP12) e avaliao da qualidade dos artefatos (AP13).
tambm neste
nvel que se encontram as prticas ligadas engenharia de aplicaes (AP14), foco do

desenvolvimento com reutilizao.
Nvel 4 - Sistemtico: este o nvel mais avanado que uma organizao pode chegar em
termos de reutilizao de software. Neste nvel, o processo est em constante otimizao
(AP15), de acordo com resultados de projetos anteriores. Tambm aqui a qualidade dos
artefatos reutilizveis sujeita a um processo mais rigoroso de controle de qualidade
(AP16). Outras prticas interessantes deste nvel 4 incluem a tentativa de se prever e
suprir necessidades futuras em termos de artefatos reutilizveis (AP17), e uma anlise
de mercado para se avaliar as questes de investimento em reutilizao (AP18);
Este modelo bastante abrangente, buscando identificar as prticas essenciais sem entrar
em detalhes sobre como as mesmas so realizadas. O modelo tambm no define quais
prticas so obrigatrias, quais so opcionais, quais so apenas desejveis, etc. Fica a cargo
da organizao decidir quais prticas adotar, de acordo com seu contexto, e a melhor maneira
de realizar cada prtica.
Nesta tese foram realizadas somente as prticas relacionadas ao desenvolvimento para
reutilizao, aqui descritos como anlise, projeto e implementao do domnio. O objetivo foi
dar suporte s atividades essenciais, relacionando cada uma com o desenvolvimento orientado a
modelos e como o mesmo pode ajudar na obteno dos objetivos de cada prtica. Mais detalhes
sobre como este modelo influenciou a presente abordagem so apresentados no Captulo 4.
2.2
Desenvolvimento orientado a modelos
Apesar dos inmeros avanos na rea da Engenharia de Software, ainda existem problemas
(KLEPPE; WARMER; BAST, 2003) com a maneira com que o software desenvolvido na maioria
das organizaes, que permanecem como desafios at os dias atuais (FRANCE; RUMPE, 2007).
35
Conforme discutido brevemente no Captulo 1, esses problemas derivam do fato de o software

ser atualmente um artefato extremamente complexo. Dentre esses problemas, destacam-se os
sete descritos a seguir.
O fardo da modelagem: arquitetos de software (algumas vezes) usam UML para criar
modelos de alto nvel, que so teis em um primeiro momento, para facilitar a anlise de
um problema. Atravs de modelos, facilita-se a realizao de discusses, trocas de idias e
comunicao entre as equipes envolvidas com o processo de software.
Porm, estes modelos logo se tornam inteis, medida que o desenvolvimento avana.
Isto porque programadores, que criam cdigo manualmente, tambm realizam mudanas e
manutenes diretamente no cdigo. Desta forma, sem um trabalho extra para atualiz-los,
os modelos logo perdem a consistncia, se tornando incapazes de representar a realidade.
Mesmo com tcnicas de engenharia reversa, que facilitam a extrao automtica de modelos
a partir do cdigo, a verdade que os modelos so artefatos desnecessrios, no sentido em que
no fazem parte do software propriamente dito. So apenas parte da documentao, que precisa
ser atualizada com esforo no diretamente produtivo, tornando-se literalmente um fardo a ser
carregado pela equipe.
Alm disso, modelos so mais teis para membros novos de uma equipe. Nos projetos em
que uma mesma equipe segue trabalhando por um longo tempo, as informaes nos modelos
j so bem conhecidas pelos membros da equipe, e portanto nem valor de documentao os
mesmos possuem. bastante comum, na chegada de um novo membro a uma equipe, o mesmo
perguntar pela documentao e modelagem do sistema. E tambm comum este membro obter
como resposta o fato de que os documentos esto antigos e desatualizados.
Reutilizao de conhecimento: alm de ser um conjunto de linhas ordenadas de instrues
e comandos que expressam um algoritmo para um computador, o cdigo-fonte encapsula
conhecimento de uma forma concreta. Algoritmos, estruturas de dados, classes e funes
representam meses ou anos de evoluo de um software, e ali esto contidas as experincias
da equipe, uma traduo dos requisitos do software em uma forma executvel e altamente
codificada.
Este conhecimento muitas vezes representa apenas instrues de baixo nvel, que servem
para operao do computador, manipulao de variveis, truques de otimizao, entre outros.
Mas ele tambm um retrato das regras de negcio do software, sendo importante, e s vezes
vital para o sucesso da organizao.
O problema que a linguagem do cdigo-fonte demasiadamente densa e codificada, de
36
forma que difcil identificar, extrair e reutilizar este conhecimento apenas lendo este cdigo.
Alm disso, este conhecimento est impregnado por trechos altamente associados a detalhes
de plataforma, de modo que a reutilizao de uma determinada lgica de negcio em uma
plataforma ou linguagem diferentes requer um trabalho cuidadoso de reengenharia.
So necessrias formas mais intuitivas de representao do conhecimento, que sejam menos
dependentes do cdigo-fonte. Uma alternativa o uso de documentao apropriada, mas como
j foi discutido na seo anterior, existe o problema da inconsistncia causada por modificaes
no software.
Produtividade: o desenvolvimento de software normalmente constitudo de projeto de
baixo nvel e codificao. Artefatos de alto nvel (modelos, diagramas) so produzidos antes
da codificao, e servem de auxlio s tarefas de desenvolvimento e manuteno, mas no
constituem o software propriamente dito.
Alm disso, esses artefatos logo perdem seu valor e se tornam retratos irreais do software
assim que as fases de codificao comeam, pois quaisquer eventuais mudanas que o software
sofra so realizadas somente no cdigo e no so refletidas nos artefatos de alto nvel, devido
principalmente s restries de tempo. Sendo assim, o tempo gasto na construo desses
artefatos, assim como o tempo gasto em esforos de manuteno devido a essa inconsistncia
com o cdigo, no so diretamente aproveitados na produo do software.
Outro ponto referente produtividade diz respeito multiplicidade entre elementos mais
conceituais e as linhas de cdigo. A um nico elemento conceitual podem corresponder
inmeras linhas de cdigo. Por exemplo, considere uma mquina de estados. Um nico
estado pode estar representado no cdigo em diferentes locais, incluindo tabelas de transies,
variveis locais e mtodos. Suponha que cada estado possui 50 linhas de cdigo associadas.
Dessa forma, para se inserir ou modificar um estado, 50 linhas de cdigo precisam ser inseridas
ou modificadas.
Alm disso, essa multiplicidade no uma funo objetiva, ou seja, no se pode garantir
que a todos os estados correspondam sempre 50 linhas. A variao disso torna o mapeamento
entre elementos de alto nvel nos seus respectivos cdigos um trabalho mais exaustivo.
Como resultado, muitas tarefas de implementao so repetitivas e exaustivas, gastando
esforo que poderia ser melhor aproveitado em trabalho conceitual.
Manuteno e documentao: Criar documentao correta e atualizada uma das tarefas
mais essenciais para que um sistema de software sobreviva e evolua de maneira efetiva.
Porm, criar e manter a documentao atualizada normalmente uma tarefa manual no muito
37
apreciada por desenvolvedores.

possvel obter a documentao diretamente a partir do cdigo, usando tcnicas
automatizadas de engenharia reversa. Porm, essa documentao seria apenas um reflexo do
cdigo, e no uma documentao de alto nvel, que muitas vezes crucial para as tarefas de
manuteno em sistemas muito complexos. Nesses casos, o trabalho manual se mostra como a
nica soluo.
Alm disso, os mesmos problemas relacionados produtividade citados na seo anterior
possuem impacto na manuteno. Por exemplo, modificar um nico campo de uma aplicao
baseada em Struts3 pode requerer:
alterao das tabelas, ndices, vises, consultas e
procedimentos armazenados que possuem relao com o campo; alterao das classes Java
correspondentes s aes de consulta, insero e atualizao que envolvem o campo em
questo; alterao do mapeamento de entidades (beans) que contm referncias para este
campo, normalmente um arquivo XML; alterao dos arquivos de descrio dos formulrios
que contm referncias para este campo, normalmente arquivos XML; entre outras.
Ou seja, o mesmo trabalho braal e repetitivo que foi necessrio para a construo do
software necessrio tambm na manuteno.
Outro problema causado na manuteno diz respeito rastreabilidade entre elementos
conceituais e elementos de implementao. Ao se planejar uma mudana, primeiro pensa-se
em termos conceituais, para apenas em seguida identificar os trechos de cdigo a serem
modificados. Sem esta informao de rastreabilidade, esta tarefa dificultada, exigindo uma
busca cuidadosa no cdigo.
Tambm pode levar a erros de inconsistncia entre os diversos artefatos relacionados. Por
exemplo, a modificao de cdigo Java sem a modificao correspondente dos comandos SQL
pode causar erros de execuo.
Validao e otimizao: encontrar erros conceituais diretamente no cdigo-fonte uma
tarefa mais difcil e trabalhosa do que se fossem utilizados modelos mais conceituais. Por
exemplo, considere uma mquina de estados com centenas de estados. Identificar, olhando
apenas para o cdigo, a existncia de estados inalcanveis, transies infinitas ou estados
mortos (estados sem transies para fora) pode ser extremamente trabalhoso.
Da mesma forma, otimizaes mais conceituais podem no ser to simples de serem
executadas olhando-se diretamente para o cdigo.
Por exemplo, a remoo de estados
redundantes em uma mquina de estados seria facilitada caso houvesse algum tipo de artefato
3 http://jakarta.apache.org/struts/
38
de mais alto nvel associado.

Enquanto documentos de alto nvel poderiam ser utilizados nestas tarefas, os mesmos
problemas descritos anteriormente como fardos da modelagem teriam de ser enfrentados.
Alm disso, a validao e otimizao automticas, que em muitos casos so superiores a um
processo manual, requerem modelos formais consistentes com a implementao, caso contrrio
os resultados seriam inexatos ou mesmo equivocados.
Portabilidade: a indstria de software extremamente dinmica, e novas tecnologias e
plataformas surgem muito rapidamente, oferecendo vantagens que foram as organizaes a se
adaptarem rapidamente para no ficarem desatualizadas em relao aos principais concorrentes.
O processo de reengenharia necessrio para portar o software para essas plataformas
dispendioso e muitas vezes demorado.
Por outro lado, o surgimento de novas tecnologias pode aumentar a presso existente para a
migrao, e a estagnao pode ser prejudicial para a organizao, que se v obrigada a realizar
a migrao ou permanecer defasada em relao aos concorrentes.
O problema da portabilidade surge da quantidade de esforo despendido em tarefas
especficas da plataforma, esforo este que no pode ser reaproveitado em outras plataformas.
Idealmente, o desenvolvimento de software deveria ser mais conceitual e menos focado em
esforo repetitivo.
Interoperabilidade:
sistemas de software raramente funcionam isoladamente.
Normalmente eles precisam se comunicar entre si, para trocar informaes ou realizar
tarefas em conjunto. Alm disso, com as atuais idias de componentes de software, um mesmo
sistema pode ser composto de partes que utilizam tecnologias diferentes, e que ainda assim
precisam se comunicar, normalmente em ambientes heterogneos, como a Internet.
Neste contexto, a interoperabilidade se torna um requisito do software, trazendo consigo
vrios outros, como a necessidade de equipes distintas, com profissionais e especialistas
dedicados s diferentes partes do software. Tambm exige formas de comunicao mais
eficientes entre as diferentes equipes e a gerncia, j que cada pessoa envolvida nestes projetos
multidisciplinares tem conhecimentos e interesses em diferentes partes do problema.
Uma possvel soluo: dados estes problemas, o desenvolvimento orientado a modelos
um exemplo tpico do ditado popular:
a necessidade a me da inveno.
MDD surgiu como uma maneira de se resolver estes problemas, utilizando uma abordagem
altamente automatizada e com promessas de ganhos significativos em termos de qualidade
39
e produtividade4 . A seguir apresenta-se os principais conceitos e tcnicas envolvidas com o

MDD.
2.2.1
Conceitos do desenvolvimento orientado a modelos
O desenvolvimento de software baseado em modelos (MDD - Model-Driven Development

surgiu com o objetivo de ajudar a resolver todos os problemas citados anteriormente (KLEPPE;
WARMER; BAST, 2003).
O MDD tambm conhecido como MDE (Model-Driven Engineering)
(SCHMIDT, 2006), MDSD (Model-Driven Software Development) (VLTER; GROHER, 2007) ou,
para aqueles cansados de tantos acrnimos, MD* (VLTER, 2008). Todos estes acrnimos dizem
respeito mesma abordagem, cuja idia principal reconhecer a importncia dos modelos
no processo de software, no apenas como um guia para tarefas de desenvolvimento e
manuteno, mas como parte integrante do software.
A proposta do MDD (Figura 3) fazer com que o engenheiro de software no precise
interagir manualmente com todo o cdigo-fonte, podendo se concentrar em modelos de mais
alto nvel, ficando protegido das complexidades requeridas para implementao nas diferentes
plataformas. Um mecanismo automtico responsvel por gerar automaticamente o cdigo a
partir dos modelos. Neste cenrio, modelos no so apenas um guia, ou uma referncia. Eles
fazem parte do software, assim como o cdigo-fonte.
2.2.1.1
Principais vantagens e desvantagens
As principais vantagens da abordagem MDD relacionam-se com os sete problemas

destacados anteriormente. As vantagens, apresentadas por Kleppe, Warmer e Bast (2003),
Deursen e Klint (1998), Bahnot et al. (2005), Mernik, Heering e Sloane (2005), so:
Produtividade: o tempo de desenvolvimento ser melhor aproveitado, pois ser gasto na

produo de modelos de mais alto nvel. Tarefas repetitivas podem ser implementadas
nas transformaes, poupando tempo e esforo que podem ser despendidos em tarefas
mais importantes. Alm disso, um nico modelo pode gerar uma grande quantidade e
diversidade de cdigo;
Portabilidade: um mesmo modelo pode ser transformado em cdigo para diferentes
plataformas;
4 Para
uma discusso envolvendo os diferentes pontos de vista que marcam as origens do MDD, consulte o
Apndice B
40
Figura 3: Ilustrao do processo de criao de software no desenvolvimento orientado a

modelos
Interoperabilidade: cada parte do modelo pode ser transformado em cdigo para
uma plataforma diferente, resultando em um software que executa em um ambiente
heterogneo, porm mantendo a funcionalidade global. Tambm podem ser gerados
adaptadores e conectores utilizando tecnologias independentes de plataforma, para que
esses cdigos de diferentes plataformas possam se comunicar;
Manuteno e documentao: no desenvolvimento convencional, a urgncia inerente
s atividades de manuteno faz com que os desenvolvedores insiram modificaes
diretamente no cdigo, fazendo com que a documentao fique logo desatualizada. No
MDD os modelos no so abandonados. Eles fazem parte do software, e as alteraes
so realizadas diretamente neles, mantendo-os consistentes com o cdigo. Desta forma, a
documentao mantm-se atualizada, o que acaba por facilitar as tarefas de manuteno;
Comunicao: no MDD, os diferentes profissionais possuem meios mais efetivos para
comunicao, uma vez que modelos geralmente so mais abstratos que o cdigo, no
exigindo conhecimento tcnico relativo plataforma. Especialistas do domnio tm um
papel mais ativo no processo, podendo utilizar diretamente os modelos para identificar
mais facilmente os conceitos do negcio, enquanto especialistas em TI podem identificar
os elementos tcnicos;
Reutilizao: Diversos autores, tais como Krueger (1992), Griss (1995), Frakes e Isoda
41
(1994), Jacobson, Griss e Jonsson (1997), ressaltam que a reutilizao de artefatos de

alto nvel proporciona maiores benefcios do que a reutilizao de cdigo-fonte. No
desenvolvimento convencional, reutilizar um modelo requer a transformao manual para
reutilizar tambm o cdigo a ele associado. No MDD, isto mais facilmente alcanado,
pois o cdigo pode ser automaticamente re-gerado para o novo contexto;
Verificaes e otimizaes: os modelos oferecem mais munio para verificadores
semnticos e otimizaes automticas especficas de domnio poderem ser executados.
Isto pode reduzir a ocorrncia de erros semnticos e prover implementaes mais
eficientes;
Corretude: alm do fato de geradores no introduzirem erros acidentais, como erros de
digitao, geradores permitem que a identificao de erros conceituais acontea em um
nvel mais alto de abstrao.
Em resumo, as vantagens do MDD derivam da capacidade de evitar que o desenvolvedor

precise executar as tarefas repetitivas necessrias para a transformao de modelos para o cdigo
final executvel. Isto alcanado por meio da automao dessas transformaes. O tempo
gasto nessas tarefas, que no desenvolvimento convencional (no orientado a modelos) inibe a
execuo do ciclo completo dos requisitos aos testes, significativamente reduzido, fazendo
com que mesmo atividades de urgncia, como correo de erros, possam ser executadas sem
produzir inconsistncia com os modelos, mantendo-os sempre atualizados.
Entre as desvantagens causadas pelo MDD, alguns autores, como Ambler (2003), Thomas
(2004), citam as seguintes:
Rigidez: o MDD causa maior rigidez no software produzido, uma vez que grande parte
do cdigo gerado e fica alm do alcance do desenvolvedor;
Complexidade: os artefatos necessrios para uma abordagem baseada em modelos,
como por exemplo ferramentas de modelagem, transformaes e geradores de
cdigo, introduzem complexidade adicional ao processo, pois tratam-se de artefatos
inerentemente mais difceis de construir e manter;
Desempenho: apesar de algumas otimizaes poderem ser realizadas em nvel mais alto
de abstrao, a regra geral que geradores acabam incluindo muito cdigo desnecessrio,
e portanto o resultado pode no apresentar desempenho timo, quando comparado com
cdigo escrito mo;
42
Curva de aprendizado: o desenvolvimento dos artefatos especficos do MDD exigem

profissionais com habilidades na construo de linguagens, ferramentas de modelagem,
transformaes e geradores de cdigo. O aprendizado destas tcnicas, apesar de no ser
extremamente difcil, requer um treinamento dedicado; e
Alto investimento inicial: assim como a reutilizao de software, o MDD depende
de maior investimento inicial, uma vez que a construo de uma infra-estrutura de
reutilizao orientada a modelos requer mais tempo e esforo.
Porm, os ganhos
posteriores so significativos, fazendo com que este investimento tenha retorno em poucas
interaes.
2.2.1.2
Principais elementos do MDD
Obviamente, automatizar as transformaes no uma tarefa simples. A Figura 4 mostra

os principais elementos necessrios para essa abordagem, e como eles so combinados.
Figura 4: Principais elementos do MDD

Para possibilitar a criao de modelos, necessria uma ferramenta de modelagem.
Utilizando essa ferramenta, o engenheiro de software produz modelos que descrevem os
conceitos do domnio. Para isto, a ferramenta deve ser intuitiva e de fcil utilizao. Ao mesmo
tempo, os modelos por ela criados precisam ser semanticamente completos e corretos, uma
vez que devem poder ser compreendidos por um computador, e no um ser humano, capaz de
corrigir pequenos enganos ou preencher lacunas por si s. O elemento que implementa estas
caractersticas normalmente uma linguagem especfica de domnio, ou DSL (Domain-Specific
Language), descrito no prximo captulo.
43
Os modelos servem de entrada para transformaes que iro gerar outros modelos ou o
cdigo-fonte. Para definir as transformaes, necessria uma ferramenta que permita que o
engenheiro de software construa regras de mapeamento de modelo para modelo, ou de modelo
para cdigo. Idealmente, essa ferramenta deve possibilitar que as regras de mapeamento sejam
construdas da forma mais natural possvel, uma vez que a construo de transformadores uma
tarefa complexa.
Finalmente, necessrio um mecanismo que efetivamente aplique as transformaes
definidas pelo engenheiro de software. Esse mecanismo deve no s executar as transformaes,
mas tambm manter informaes de rastreabilidade, possibilitando saber a origem de cada
elemento gerado, seja no modelo ou no cdigo-fonte.
Atualmente existem diversos trabalhos que buscam melhor definir o papel de todos esses
elementos. A seguir so apresentadas as principais abordagens existentes na indstria para
possibilitar o desenvolvimento orientado a modelos.
2.2.2
Principais abordagens da indstria para MDD
Para dar suporte a diferentes linguagens de modelagem, ajudar a garantir que os modelos
construdos estejam semanticamente corretos e completos, e possibilitar a definio e execuo
de transformaes genricas, as principais abordagens existentes na indstria para MDD se
baseiam no conceito de metamodelagem (OMG, 2006b), apresentado na Figura 5.
Figura 5: Arquitetura clssica de metamodelagem

O primeiro nvel (M0) corresponde aos dados propriamente ditos. O segundo nvel (M1)
44
corresponde aos metadados, ou modelo. So os dados que descrevem os dados. O terceiro

nvel (M2) o metamodelo, utilizado para a definio de modelos. A especificao UML um
exemplo de metamodelo. O quarto nvel (M3) utilizado para definir metamodelos, ou seja, um
meta-metamodelo define linguagens de modelagem, como a UML, por exemplo. Um exemplo
de meta-metamodelo o padro MOF, apresentado na prxima seo. No existe um quinto
nvel, pois o meta-metamodelo normalmente instncia de si mesmo.
Existem diferentes meta-metamodelos utilizados na indstria, utilizados nas diferentes
ferramentas de modelagem e transformao, para uniformizar a manipulao de modelos e
cdigo em diferentes linguagens.
Nas sees seguintes so apresentadas as principais abordagens da indstria para o MDD.
2.2.2.1
Abordagem OMG: MDA (Model-Driven Architecture)
O OMG (Object Management Group) um dos responsveis pelo atual aumento de

interesse nas idias do MDD, devido principalmente MDA. A MDA surgiu como um conjunto
de padres voltados para fabricantes de ferramentas interessados em manter a interoperabilidade
com outros fabricantes (OMG, 2003).
A base da MDA o MOF (Meta-Object Facility) (OMG, 2006b), o meta-metamodelo que
serve de base para a definio de todas as linguagens de modelagem. devido ao MOF que as
ferramentas de modelagem e transformao podem trabalhar em conjunto.
O MOF consiste em um padro orientado a objetos que permite a definio de classes
com atributos e relacionamentos, sendo bastante semelhante ao diagrama de classes da UML.
Tambm define uma interface padro de acesso aos dados dos modelos, oferecendo mtodos
para manipulao dos dados e dos metadados. Alm dessa interface padro, que nica para
qualquer metamodelo, o MOF define regras para a criao de interfaces especficas para cada
metamodelo. Por exemplo, para cada atributo monovalorado de uma classe do metamodelo,
deve existir um mtodo do tipo set e um mtodo do tipo get. Essas regras se estendem para
nomes de classes, relacionamentos, e assim por diante.
Atualmente, o MOF encontra-se na verso 2.0 (OMG, 2006b). Assim como a UML, um
padro elaborado e mantido por diversas empresas associadas ao OMG.
A MDA tambm define o XMI (XML Metadata Interchange) (OMG, 2006c), um formato
para representar modelos em XML. Este formato define uma estrutura de documento que
considera a relao entre os dados e seus correspondentes metadados. Assim, possvel para
uma ferramenta, ao interpretar este formato, identificar quais os metadados que descrevem os
45
dados sendo lidos. Diferentes metanveis podem ser representados, desde o M0 at o M3 (Figura
5). Por exemplo, possvel representar modelos UML (com referncia para o metamodelo
UML) ou modelos E-R (com referncia para o metamodelo E-R). O metamodelo UML tambm
pode ser descrito em XMI, e neste caso teria uma referncia para o meta-metamodelo MOF. Por
ser baseado em XML, traz consigo vrias vantagens, tais como a facilidade de ser interpretado e
a possibilidade de se aplicar transformaes. Atualmente, o padro XMI encontra-se na verso
2.1 (OMG, 2006c).
Outro padro da MDA o QVT (Queries/Views/Transformations) (OMG, 2005). Ainda em
fase de finalizao, o QVT define uma linguagem textual e uma notao para definir consultas
e transformaes baseadas no MOF. Por meio dessa linguagem, possvel definir regras de
mapeamento entre modelos escritos em qualquer linguagem de modelagem, desde que essa
seja uma instncia do MOF.
Apesar de ter a proposta de ser genrica, podendo trabalhar com qualquer linguagem de
modelagem, a MDA tem grande foco na UML (Unified Modeling Language) (OMG, 2007).
Sendo tambm instncia do MOF, a UML apenas uma das possveis linguagens de modelagem
que podem ser usadas no MDD.
2.2.2.2
Abordagem Eclipse
A abordagem liderada pela IBM baseada na plataforma Eclipse. Uma das bases dessa
abordagem o EMF (Eclipse Modeling Framework5 ). O EMF permite a manipulao de
modelos segundo seu correspondente metamodelo.
O EMF segue um meta-metamodelo
denominado Ecore, ao invs do MOF, padro estabelecido pelo OMG. O Ecore surgiu como
um implementao do MOF, mas evoluiu para uma forma mais eficiente, a partir da experincia
obtida aps alguns anos na construo de ferramentas (ECLIPSE, 2005).
Outro projeto relacionado ao desenvolvimento orientado a modelos voltado plataforma
Eclipse denominado GMT (Generative Modeling Tools6 ). Trata-se de uma iniciativa bastante
recente, que se baseia nas idias do padres OMG, porm com algumas modificaes.
Seu principal objetivo servir de incubadora para projetos de ferramentas, linguagens e
frameworks para dar suporte s tecnologias de transformao e gerao de cdigo. Dentre os
sub-projetos do GMT, destacam-se:
ATL (Atlas Transformation Language7 ): trata-se de uma linguagem para definio de
5 http://www.eclipse.org/emf/
6 http://www.eclipse.org/gmt/
7 http://www.eclipse.org/gmt/atl/
46
transformaes entre modelos. Originalmente projetada para ser compatvel com o MOF,
sua verso atual j baseada no Ecore. equivalente linguagem QVT, do OMG,
possuindo algumas diferenas (JOUAULT; KURTEV, 2006);
MOF Script8 : esse projeto envolve o desenvolvimento de ferramentas e frameworks para
transformao de modelos para texto, com base em uma linguagem para definio dessas
transformaes; e
TCS - Textual Concrete Syntax: esse projeto visa desenvolver ferramentas para a
definio de DSLs textuais (JOUAULT; BZIVIN; KURTEV, 2006)9 .
Outro projeto, que fazia parte do GMT mas que se desvinculou por no mais se tratar
de projeto incubado, o openArchitectureWare10 . Este projeto engloba ferramentas de
modelagem textual, transformaes de software e gerao de cdigo baseada em templates,
alm de outra funes pertinentes ao MDD.
O JET (Java Emitter Templates) (POPMA, 2004) consiste de um mecanismo de gerao
de cdigo baseado em templates(CLEAVELAND, 1988). Atravs da incluso de cdigo Java
dentro dos templates, permite a metaprogramao, ou seja, a criao de programas que criam
programas. Qualquer comando Java pode ser utilizado, alm de uma srie de marcaes (tags)
que implementam comandos condicionais, de laos, formatao, entre outras funes teis. O
JET pode ser acoplado a arquivos XML ou modelos EMF, sendo portanto possvel utiliz-lo
como gerador de cdigo para uma DSL.
Finalmente, um projeto que merece ateno nessa linha o GMF (Graphical Modeling
Framework11 ). Esse projeto permite a definio completa de um ambiente de modelagem
para uma linguagem visual especfica para um determinado domnio. A partir da definio
do metamodelo da linguagem, da aparncia grfica dos elementos visuais dessa linguagem
(notao), e das ferramentas necessrias para a criao dos elementos, gerado um ambiente
completo, que permite que o engenheiro de software construa modelos segundo a linguagem e
notao definidos.
2.2.2.3
Outras abordagens
A Vanderbilt University abriga o projeto MIC (Model Integrated Computing), que pesquisa
trs elementos principais relacionados ao MDD: tecnologias para modelagem especfica de
8 http://www.eclipse.org/gmt/mofscript/
9 DSLs
sero abordadas mais adiante, no Captulo 3.
10 http://www.openarchitectureware.org
11 http://www.eclipse.org/gmf/
47
domnio, um conjunto de ferramentas para modelagem, e um framework para anlise formal,

verificao e transformao de modelos.
(Generic Modeling
Environment)12 ,
O principal produto desta pesquisa o GME
um ambiente de metamodelagem que permite a criao
de ferramentas de modelagem especfica de domnio de forma simples e rpida.

A Microsoft, atravs do conceito de fbrica de software (GREENFIELD et al., 2004), tambm
prope uma abordagem para desenvolvimento de software baseada na reutilizao sistemtica
e MDD. Esta abordagem busca imitar o funcionamento de uma fbrica tradicional, aplicando
os conceitos no desenvolvimento de software. Ela define trs elementos: (i) o esquema da
fbrica de software, que descreve o que necessrio para construir os produtos da fbrica, (ii) o
template da fbrica, que uma instncia do esquema, e (iii) um ambiente extensvel, consistindo
de ferramentas utilizadas para a produo, configuradas atravs do template da fbrica. As
ferramentas desta abordagem esto focadas no Microsoft Visual Studio, principalmente com
as DSL Tools (COOK et al., 2007), um conjunto de ferramentas para definio de linguagens
especficas de domnio, gerao de cdigo, entre outras funes.
O UMT-QVT13
14
uma ferramenta de cdigo aberto que permite realizar transformaes
conforme exige o MDD. Um modelo serve de entrada para a ferramenta no formato XMI, que
ento convertido para um formato intermedirio. As transformaes so baseadas em XSLT
(W3C, 1999b), ou mesmo implementadas manualmente em linguagem de programao. O
principal problema dessa abordagem est na dificuldade em se construir transformadores dessa
forma, principalmente para transformar modelos. Neste sentido, as abordagens que utilizam
linguagens visuais para definio de transformadores, como QVT e ATL, so mais apropriadas.
O MTF (Model Transformation Framework15 ), da IBM, contm um conjunto
de ferramentas que auxiliam desenvolvedores em comparaes, validaes e criao
de transformaes entre modelos EMF. Tambm mantm um registro dos elementos
transformados, permitindo rastreamento entre elementos gerados e a gerao de relatrios para
o usurio. baseado em uma linguagem para definio dos mapeamentos entre os modelos, em
um mecanismo de transformao capaz de interpretar esses mapeamentos, em um editor para
as transformaes, e no suporte para gerao de texto a partir de modelos.
Finalmente, o projeto openMDX16 foca na implementao dos conceitos da MDA, ou seja,
o modelo a implementao. Porm, a insero de informaes especficas da plataforma de
execuo deixada para a etapa de implantao somente, no ocorrendo na etapa de projeto,
12 http://www.isis.vanderbilt.edu/projects/gme/
13 Apesar
de constar no nome desse projeto, essa ferramenta no baseada na linguagem QVT do OMG.
14 http://umt-qvt.sourceforge.net
15 http://www.alphaworks.ibm.com/tech/mtf
16 http://www.openmdx.org/index.html
48
como previsto pela MDA. Segundo os autores, isto traz uma srie de benefcios, tais como a
facilidade de portar modelos independentes de plataforma, e evita a necessidade de modelagem
especfica de plataforma, complexa e passvel de erros, alm de tornar a lgica da aplicao
realmente independente da plataforma.
Todas estas abordagens e ferramentas tm alto potencial para auxiliar no MDD, mas da
mesma maneira que no caso da reutilizao, o papel do processo fundamental para que as
tentativas no sejam fadadas ao fracasso. Este o assunto da prxima seo.
2.2.3
O processo de desenvolvimento orientado a modelos
No existe um consenso com relao s atividades de um processo de desenvolvimento

orientado a modelos. O mais prximo disto um modelo de maturidade denominado MDD
Maturity Model (MODELWARE, 2006b). Este modelo foi definido com base na experincia das
diversas empresas e instituies de pesquisa envolvidas com o ModelWare, uma iniciativa na
rea do MDD, descrita de forma mais detalhada na Seo 10.1. Esse modelo define as principais
prticas e elementos de processo relacionados ao MDD, classificados em cinco nveis, conforme
mostra a Figura 6.
Figura 6: Modelo de maturidade em MDD (MODELWARE, 2006b)

Cada prtica identificada por um conjunto de caracteres que indica a rea da mesma e um
nmero seqencial, sendo que ENG = Engenharia, PJM = Gerenciamento de projeto e SUP =
49
Suporte. As mesmas esto agrupadas nos cinco nveis conforme descrito a seguir:
Nvel 1 - Modelagem ad hoc: neste nvel, apenas o desenvolvimento tradicional
realizado. Prticas de modelagem so utilizadas apenas esporadicamente ou nunca;
Nvel 2 - MDD Bsico: este nvel caracterizado pela utilizao bsica de modelos,
cobrindo atividades simples do MDD, como a deciso sobre as ferramentas e convenes
de modelagem (ENG1 e PJM1).
Modelos so utilizados apenas para guiar a
implementao e documentao. Tipicamente, apenas modelos tcnicos (ENG2) so

utilizados, incluindo todos os aspectos de um sistema, sem distino entre aspectos de
negcio ou aspectos especficos de plataforma. A gerao de cdigo e de documentao
(ENG3 e ENG4) feita diretamente a partir do modelo tcnico.
Nvel 3 - MDD Inicial: neste nvel introduz-se uma separao entre modelos de
negcio independentes de plataforma (ENG5) e modelos especficos de plataforma. O
objetivo manter os aspectos de implementao independentes dos aspectos de negcio,
de modo a melhorar a eficincia do processo de desenvolvimento. Neste nvel, as
prticas e artefatos do MDD so institucionalizadas, incluindo o desenvolvimento de
transformaes modelo-para-texto (ENG6) e a verificao de modelos (ENG7). Na rea
de gerenciamento, este nvel prev atividades para modelagem e aplicao do processo
de MDD no projeto (PJM2 e PJM3), assim como a definio, coleta e anlise de mtricas
do projeto (PJM4). Neste nvel tambm existe a preocupao com a padronizao das
ferramentas e convenes de modelagem, dos procedimentos para coleta e anlise das
mtricas e o estabelecimento de um repositrio de modelos (SUP1, SUP2, SUP3 e SUP4);
Nvel 4 - MDD Integrado: o nvel 4 caracterizado por uma melhor integrao
entre os nveis de abstrao de modelagem. Metamodelos independentes e especficos
de plataforma (ENG8 e ENG9), modelos de negcio (ENG10) e transformaes
modelo-para-modelo (ENG11) so definidos neste nvel.
Aqui tambm aparece a
preocupao com a rastreabilidade entre modelos (ENG12), com as famlias de produtos

(ENG13), caso seja este o foco da organizao e com a simulao de modelos (ENG14),
visando detectar erros de maneira precoce. A modelagem do processo nesse nvel passa a
incluir os processos automticos do MDD (PJM5). Limites de desempenho de modelagem
da organizao so estabelecidos (SUP5), visando adequar os esforos de acordo com as
caractersticas de cada projeto;
Nvel 5 - MDD Definitivo: neste ltimo e derradeiro nvel, todo o conhecimento da
organizao mantido na forma de modelos e transformaes, que so o foco do processo
50
de desenvolvimento.
Prticas para o desenvolvimento de linguagens especficas de
domnio (ENG15) e a verificao e validao de produtos (ENG16) so complementadas

com prticas para estabelecer e manter artefatos de modelagem de software estratgicos
para o MDD (PJM6) e promulgar o modelo de processo do projeto (PJM8), tornando o
desenvolvimento mais controlvel;
Estas prticas foram essenciais para a definio da abordagem desta tese, conforme descrito
no Captulo 4.
2.3
Consideraes finais
Neste captulo foram discutidos os principais conceitos e tcnicas da reutilizao de

software e do desenvolvimento orientado a modelos. Enquanto as tcnicas para reutilizao
buscam aproveitar ao mximo o que j existe em termos de artefatos de software produzidos
anteriormente, o desenvolvimento orientado a modelos busca elevar o nvel de abstrao no qual
o desenvolvedor trabalha, escondendo detalhes da plataforma de implementao e empregando
as habilidades de automao do computador para ajudar nas tarefas de traduo entre problema
e soluo e nas tarefas repetitivas.
Estas tcnicas formam um conjunto de ferramentas com potencial para fazer com que os
objetivos sejam alcanados, sejam eles da reutilizao ou do MDD. Porm, sem a existncia
de um processo bem definido, que d suporte institucionalizao de prticas comprovadas e
sistemticas, este potencial pode no atingir seu ponto mximo, e como resultado os benefcios
associados reutilizao e ao MDD podem se perder durante as tentativas. Assim, o papel do
processo o de coordenar esforos de maneira que o sucesso passa a depender de fatores mais
controlveis, como planejamento, gerenciamento e treinamento, ao invs de ser o resultado de
talento e experincias individuais isoladas. A literatura apresenta importantes contribuies
nas reas de processos para reutilizao de software e MDD, porm a combinao de ambas
permanece relativamente inexplorada.
Existem alguns pontos de interseco, com impacto significativo no processo, que precisam
ser devidamente analisados antes de se tentar uma combinao entre reutilizao e MDD. No
prximo captulo esta interseco analisada de forma mais aprofundada, buscando identificar
como as caractersticas de cada abordagem pode influenciar a outra de forma a proporcionar um
melhor resultado final.
51
Reutilizao de software e
desenvolvimento orientado a modelos
Reutilizao de software e desenvolvimento orientado a modelos so duas reas distintas,

mas com muitos objetivos em comum. Ambas procuram mais qualidade e produtividade no
desenvolvimento de software por meio da reduo de esforo repetitivo e da adoo de solues
que agregam conhecimento prvio. No caso da reutilizao, busca-se encapsular, em forma de
artefatos de software diversos, informaes e conceitos reutilizveis de um domnio, incluindo
algoritmos, estruturas de dados, funes, etc. No caso do desenvolvimento orientado a modelos,
busca-se encapsular tambm o conhecimento necessrio para se produzir esses artefatos, em
forma de transformaes que mapeiam conceitos de mais alto nvel at o cdigo.
particularmente interessante o fato de que o desenvolvimento orientado a modelos pode
promover a reutilizao em mais alto nvel, conforme sempre defendido e idealizado por
inmeros autores (NEIGHBORS, 1980; KRUEGER, 1992; GRISS, 1995; FRAKES; ISODA, 1994;
JACOBSON; GRISS; JONSSON,
1997). Este fato evidencia o potencial que o MDD possui para
elevar os nveis de reutilizao.

Mas o que est envolvido na combinao entre MDD e reutilizao? Quais so os conceitos
exclusivos de uma ou outra abordagem, e quais so os conceitos em comum? Como utilizar
estas informaes para chegar a um processo para reutilizao orientada a modelos? Responder
a estas perguntas um dos objetivos desta tese. Porm, existem dois pontos cruciais de
interseco entre a reutilizao e o MDD: a anlise de escopo, comunalidade e variabilidade
(anlise SCV), e a implementao da variabilidade. Estes pontos tomam formas distintas em
cada abordagem, conforme descreve-se a seguir.
3.1
Anlise SCV
Uma das principais atividades necessrias para projetos de reutilizao em grande escala
chamada de anlise SCV (Scope, commonality, and variability ou escopo, comunalidade e
52
variabilidade). Ela oferece aos engenheiros de software uma maneira sistemtica de pensar
sobre e identificar a famlia de produtos que esto criando, ajudando, entre outras coisas
(COPLIEN; HOFFMAN; WEISS, 1998):
Na criao de um projeto que contribui para a reutilizao e facilita as mudanas;

Na previso de como um projeto pode falhar ou ter sucesso, medida que evolui; e
Na identificao de oportunidades para automatizar a criao dos membros da famlia.
Em outras palavras, identificando-se os pontos comuns e variveis de um domnio, pode-se

construir artefatos reutilizveis que representam os pontos comuns, e projetar mecanismos
configurveis ou adaptveis para representar os pontos variveis (LEE; KANG, 2004). Desta
forma, a reutilizao antecipada e pode ser efetivamente includa como requisito durante a
anlise, projeto e implementao do domnio.
A SCV realizada em ambas as reas, de reutilizao de software e desenvolvimento
orientado a modelos, conforme apresentada nas sees a seguir.
3.1.1
SCV na reutilizao de software
Na rea de reutilizao de software, a modelagem de features1 (KANG et al., 1990; LEE;

KANG; LEE,
2002) amplamente utilizada como mecanismo de representao da variabilidade
(LEE; MUTHIG, 2006).

Features so quaisquer conceitos ou caractersticas distintas e proeminentes de um domnio,
e que so externamente visveis a um usurio ou outros stakeholders (por exemplo, analistas,
projetistas, desenvolvedores, etc) (LEE; KANG; LEE, 2002). Trata-se de um conceito simples
e orientado ao domnio do problema, e por isso a modelagem de features constitui um meio
natural de comunicao entre os diferentes stakeholders, sendo intuitivo para as pessoas
expressarem a comunalidade e variabilidade de um domnio atravs de features (LEE; MUTHIG,
2006).
A modelagem de features identifica os pontos comuns e variveis de um domnio em termos
das features. Esta tcnica est descrita da seguinte forma por Kang et al. (1998):
1 Nesta
tese utilizado o termo original em ingls feature para se referir a uma caracterstica de um domnio
conforme a tcnica proposta originalmente por Kang et al., ao invs de sua traduo para o portugus, pois o
termo em ingls remete de forma mais direta e menos ambgua tcnica, enquanto o termo em portugus pode ser
utilizado em outros contextos.
53
Features so identificadas e classificadas em termos de features de capacitao, de

tecnologia do domnio, de tcnicas de implementao e de ambientes de operao.
Features de capacitao so caractersticas visveis ao usurio que podem ser identificadas
como servios, operaes e caractersticas no-funcionais. Features de tecnologia do
domnio representam maneiras para se implementar os servios ou operaes. Features de
tcnicas de implementao so funes ou tcnicas genricas utilizadas para implementar
servios, operaes e funes do domnio. Features de ambiente de operao representam
o ambiente no qual as aplicaes so executadas;
Features comuns a todos os produtos do domnio so modeladas como mandatrias,
enquanto features que diferem entre os produtos podem ser opcionais ou alternativas.
Features opcionais representam features selecionveis dentro do domnio, e features
alternativas indicam que apenas uma feature pode ser selecionada para um produto; e
Um diagrama de features uma hierarquia grfica que captura relaes estruturais e
conceituais entre as features. H trs tipos de relaes: composio, generalizao
e implementao.
Regras adicionais complementam o modelo com relaes de
dependncia ou excluso mtua entre as features.
Este modelo fundamentado na presena ou ausncia das features, e capaz de cobrir

grande parte da variabilidade presente na maioria dos domnios. Porm, em alguns casos
necessrio maior poder expressivo e detalhes que no podem ser expressos atravs destas regras.
Por este motivo, Czarnecki, Helsen e Eisenecker (2004b) apresentam algumas extenses
propostas na literatura para o modelo de features, visando dar mais flexibilidade e capacidade
para representar uma maior variedade de casos. As seguintes extenses foram propostas:
Cardinalidade de features: features podem ser anotadas com cardinalidades, como [1..*]
ou [3..3]. Desta forma, features mandatrias e opcionais podem ser consideradas casos
especiais das cardinalidades [1..1] e [0..1], respectivamente;
Grupos e cardinalidade de grupos: features alternativas podem ser vistas como um
mecanismo de agrupamento. Esta extenso prope o uso de cardinalidades tambm nos
grupos. Por exemplo, um grupo de alternativas, onde pelo menos uma e no mximo uma
feature deve ser selecionada, anotado com a cardinalidade [1..1]. Em outro exemplo,
caso entre duas ou quatro opes do grupo devam ser selecionadas, a cardinalidade
utilizada [2..4];
54
Atributos: em alguns casos a relao de uma feature com uma subfeature to simples
que o uso de atributos associados a um tipo (como inteiro ou caractere) mais elegante e
simplifica o modelo;
Relacionamentos: diferentes relacionamentos podem ser utilizados para relacionar
features, tais como parte-de ou generalizao;
Categorias de features e anotaes: existem diversas categorias de features que
estendem aquelas propostas originalmente por Kang et al. (1990), incluindo: features
funcionais, arquiteturais, entre outras; e
Modularizao: um diagrama de features pode conter um ou mais ns especiais, cada um
representando um diagrama de features separado. Este mecanismo permite a quebra de
diagramas grandes em diagramas menores, assim como a reutilizao de partes comuns
em diferentes locais.
Existem diferentes notaes propostas para a modelagem de features, com algumas
diferenas em relao notao original proposta por Kang et al. (1990).
Porm, uma
caracterstica desta tcnica que a notao fixa, ou seja, pode no ser a forma mais intuitiva
para representar os conceitos de um domnio. Por este motivo, no MDD utiliza-se uma maneira
mais flexvel para a anlise SCV, conforme descrito a seguir.
3.1.2
SCV no desenvolvimento orientado a modelos
No desenvolvimento orientado a modelos, as comunalidades de um domnio so

implementadas diretamente na forma de artefatos reutilizveis (VISSER, 2007; LEE; KANG; LEE,
2002) enquanto as variabilidades so encapsuladas em uma linguagem especfica (VISSER,
2007). Essa linguagem pode ser to simples como um wizard, ou uma linguagem completa,
desenvolvida especialmente para representar a variabilidade (CZARNECKI, 2005).
Essa
linguagem chamada de linguagem especfica de domnio (DSL - Domain-Specific Language).

Uma DSL uma linguagem pequena, normalmente declarativa, focada em um domnio
de problema em particular (DEURSEN; KLINT; VISSER, 2000). DSLs existem h um longo
tempo. Mernik, Heering e Sloane (2005) citam os exemplos da linguagem APT para controle
numrico, que data de 1957-58, e da mais famosa BNF, ou Backus-Naur Form, linguagem
para especificao de gramticas criada em 1959. Desde ento, diversas linguagens vm sendo
desenvolvidas e utilizadas, e a literatura nesta rea bastante rica (DEURSEN; KLINT; VISSER,
2000; MERNIK; HEERING; SLOANE, 2005)2 .
2 Uma
discusso mais aprofundada sobre DSLs e seu papel na reutilizao apresentada no apndice A
55
Uma linguagem especfica de domnio pode ser textual (permitindo especificar programas)
ou visual (permitindo especificar modelos ou diagramas), e normalmente possui trs elementos:
a sintaxe abstrata, a sintaxe concreta e a semntica.
A sintaxe abstrata define os conceitos do domnio, e as relaes e restries que se
aplicam a estes conceitos. Em linguagens textuais, representada por uma rvore (chamada
de AST ou Abstract Syntax Tree), que armazena as palavras do vocabulrio da linguagem e
seu agrupamento vlido em forma de sentenas. Em linguagens de modelagem, corresponde
ao metamodelo que define a estrutura dos modelos que podem ser criados (GUIZZARDI; PIRES;
SINDEREN, 2002).
Uma vez que este metamodelo uma especificao de uma conceitualizao
do domnio, pode ser considerado uma ontologia (KURTEV et al., 2006).

A sintaxe concreta prov um sistema para representar os conceitos do domnio de forma
concreta. Consiste de smbolos, que podem ser caracteres organizados em palavras segundo
uma gramtica bem definida (linguagem textual), ou cones grficos com caractersticas visuais
que representam diferentes atributos, como cor, posio, tamanho e forma (linguagem visual)
(GUIZZARDI; PIRES; SINDEREN, 2002). Trata-se de uma representao superficial, que pode ser
diferente da representao interna que obtida com a sintaxe abstrata. De fato, uma DSL pode
possuir mltiplas sintaxes concretas (KLEPPE, 2007).
A semntica define o significado dos elementos da sintaxe abstrata, e pode variar de acordo
com o objetivo desejado. Por exemplo, se o objetivo da linguagem facilitar a comunicao
interpessoal, a semntica define o que cada frase ou modelo significa para um leitor humano.
Neste sentido, pode-se considerar a semntica como sendo um elemento passvel de diversas
interpretaes, uma vez que qualquer pessoa pode atribuir um significado a determinada palavra
ou cone. No entanto, no contexto do MDD, a semntica definida em forma de aes a serem
executadas por um interpretador automtico. As abordagens para o tratamento da semntica no
MDD podem se enquadrar em ao menos quatro categorias (KLEPPE, 2007):
1. Denotativa: descries matemticas que representam o significado do programa ou

modelo;
2. Operacional: tambm conhecida como execuo cannica (CLEENEWERCK; KURTEV,
2007), consiste na interpretao do programa ou modelo como uma seqncia de passos
a serem executados. Normalmente resulta em uma mquina de estados;
3. Tradutiva: consiste na traduo do programa ou modelo em outra linguagem conhecida;
e
56
4. Pragmtica:
uma ferramenta, normalmente conhecida como implementao de
referncia, executa o programa ou modelo.
A abordagem tradutiva uma das mais indicadas (KLEPPE, 2007), e tambm uma das mais
empregadas. Por exemplo, em um gerenciador de interfaces visuais, como aqueles presentes em
IDEs como NetBeans ou Visual Studio, as interfaces so especificadas de forma visual, em uma
linguagem especfica para o domnio GUI (Graphical User Interface ou Interface Grfica com
o Usurio). Nesta linguagem, especifica-se os atributos de cada componente, como posio
e tamanho, assim como os eventos e aes associados. Como resultado, gerado cdigo que
traduz a semntica da linguagem (posio, tamanho, atributos, eventos de cada componente) em
uma GPL (General Purpose Language ou Linguagem de Propsito Geral, como por exemplo
UML, Java, C#, C++, VB, entre outras).
A definio da linguagem normalmente requer um metamodelo que seja capaz de capturar
os pontos comuns e variveis do domnio, e no a mais comumente utilizada BNF. Um
metamodelo uma estrutura similar a um diagrama de classes, e possui elementos como classes,
atributos, associaes e agregaes. Seja qual for a representao visual final (diagrama visual
ou representao textual), a existncia de um metamodelo como esquema conceitual em geral
indica que uma maior quantidade de instncias pode ser expressa. Isto ocorre pelo simples fato
de que regras gramaticais BNF descrevem uma rvore, enquanto um metamodelo descreve um
grafo, e rvores so subconjuntos de grafos (KLEPPE, 2007).
Com relao sintaxe concreta, ambas as possibilidades (linguagens visuais ou textuais)
devem ser consideradas, e a escolha depende de uma anlise mais aprofundada (PETRE,
1995). Entre os fatores a serem analisados, pode-se citar o fato de que a implementao
de interpretadores textuais (parsers) uma tarefa reconhecidamente difcil (FEILKAS, 2006;
CLEAVELAND,
1988). Alm disso, impossvel expressar todas as informaes necessrias em
gramticas livres de contexto (FEILKAS, 2006). Linguagens visuais tambm so mais intuitivas
(ESSER; JANNECK, 2001), e portanto resultam em maior facilidade de utilizao por especialistas
no experientes com tecnologia da informao. Muitas vezes, porm, uma combinao de
mltiplos formatos de entrada, ou mesmo mltiplas linguagens, necessria (WILE, 2004;
TOLVANEN; KELLY,
2001).
As extenses do modelo de features descritas na seo anterior se aproximam bastante da

capacidade de representao de variabilidade que pode ser alcanada atravs de uma DSL. A
diferena que com uma DSL tem-se um maior poder expressivo, pois o foco na linguagem
visa oferecer uma sintaxe concreta que seja familiar e intuitiva para os especialistas do domnio,
enquanto a modelagem estendida de features ainda est atrelada a uma notao fixa.
57
3.2
Implementao da variabilidade
Conforme j identificado por Parnas (1976) h dcadas atrs, alm de muitos outros desde
ento (MILI; MILI; MILI, 1995; EZRAN; MORISIO; TULLY, 2002), sistemas de software raramente
so compostos exclusivamente por elementos novos. Muitos compartilham uma base comum,
diferindo apenas em pontos isolados. Estes expressam as variaes, ou variabilidade de
software.
Para alguns autores, como Svahnberg, Gurp e Bosch (2005), o termo variabilidade de
software no significa apenas as diferenas entre sistemas de software, mas tambm sua
capacidade em ser estendido, modificado, customizado ou configurado de forma eficiente para
uso em um contexto particular. Trata-se portanto de um atributo de qualidade, assim como
manutenibilidade ou usabilidade. Nesta tese, porm, utiliza-se o termo variabilidade como
referncia s possveis variaes de um conjunto de produtos de software.
Para garantir que um sistema possua um suporte adequado variabilidade, a mesma deve
ser gerenciada durante todo o seu ciclo de vida, desde a anlise at o projeto e implementao.
A anlise SCV, descrita na seo anterior, corresponde identificao e modelagem da
variabilidade. Em seguida, as atividades de projeto e implementao devem cuidar para
que esta variabilidade identificada seja devidamente implementada, em forma de mecanismos
configurveis e adaptveis (LEE; KANG; LEE, 2002).
O suporte variabilidade ocorre de forma distinta nas reas de reutilizao e MDD.
3.2.1
Implementao da variabilidade na reutilizao de software
Existem inmeras maneiras de se implementar variabilidade. Normalmente, a literatura na

rea de reutilizao apresenta solues baseadas em cdigo-fonte. Neste contexto, dentre as
principais tcnicas para implementao da variabilidade, destacam-se as seguintes, conforme
citam Matos Jr (2008), Anastasopoulos e Gacek (2001), Muthig e Patzke (2003):
Compilao condicional:
consiste na marcao de cdigo com diretrizes de
pr-processamento, para incluir ou excluir trechos de cdigo de acordo com a presena

ou ausncia de uma variante. um mecanismo simples, porm muito poderoso e robusto,
presente em grande parte das linguagens de programao atuais;
Herana: um mecanismo de linguagens orientadas a objetos, consistindo na criao de
um tipo abstrato que representa o ponto de variao, e diversos tipos concretos, cada um
sendo uma alternativa. Porm, utilizando-se herana simples, somente uma alternativa
58
pode estar presente em um determinado produto. Nestes casos, o uso de Mixins, herana
mltipla ou herana parametrizada pode ajudar;
Agregao/delegao: esta tcnica consiste em repassar requisies entre objetos,
caso um deles no seja capaz de atender a uma requisio. A variabilidade pode ser
implementada desta forma, incluindo uma funcionalidade padro ou mandatria em um
objeto, e uma funcionalidade variante em outro objeto, a ser delegado. Esta tcnica
funciona com features opcionais, mas apresenta problemas para alternativas, j que
necessrio decidir para quais objetos deve ser feita a delegao;
Parametrizao: consiste na insero de parmetros em componentes e interfaces, para
seleo das variantes. O componente ento responsvel por executar um comportamento
diferente de acordo com o parmetro especificado;
Programao orientada a aspectos (AOP - Aspect-Oriented Programming): com
AOP, funcionalidades mandatrias podem ser implementadas de modo padro, enquanto
funcionalidades alternativas so implementadas em forma de aspectos, a serem
combinados posteriormente, num processo conhecido como aspect weaving. Ou seja,
antes da execuco, um programa instancia uma configurao do seu cdigo executvel
selecionando as alternativas de aspectos que sejam adequadas ao seu estado atual;
Arquivos de configurao: consiste na criao de arquivos separados que contm as
informaes variantes, a serem selecionadas e includas no produto;
Carregamento dinmico de classes: permite que um produto solicite uma classe
dinamicamente, em tempo de execuo. Esta classe ento carregada na memria e
executada. Esta tcnica permite a incluso dinmica de alternativas, de acordo, por
exemplo, com parmetros ou arquivos de configurao.
Outra tcnica tambm bastante utilizada no suporte variabilidade o uso de padres

de projeto (KEEPENCE; MANNION, 1999; ANASTASOPOULOS; GACEK, 2001; LEE; KANG, 2004;
ALMEIDA et al.,
2007b).
Padres como o Abstract Factory, Singleton, Factory Method,
Prototype, Strategy, Template Method, Builder, Director, Observer, Decorator, Composite,

Adapter, Bridge, Chain of Responsibility e Command (GAMMA et al., 1995), entre outros, podem
potencializar o uso das tcnicas para implementao da variabilidade descritas.
Finalmente, pode-se implementar variabilidade utilizando tcnicas de gerncia de
configurao (MUTHIG et al., 2002).
Nesta abordagem, variantes alternativas de um
mesmo artefato so includas ou excludas atravs de mecanismos de controle de verses,
59
selecionando-se a verso que possui a variante desejada, por exemplo. Esta abordagem
utilizada por muitos profissionais, mas freqentemente leva a problemas graves quando as
variaes so muito complexas (MUTHIG; PATZKE, 2004). Isto porque, em geral, dependem de
um profundo conhecimento do sistema em diferentes nveis de detalhes, por parte do engenheiro
de software.
3.2.2
Implementao da variabilidade no desenvolvimento orientado a

modelos
No desenvolvimento orientado a modelos, a gerao de cdigo normalmente empregada

com o intuito de se implementar a variabilidade do domnio. Utilizando esta tcnica, as tarefas
repetitivas relacionadas implementao da variabilidade so automatizadas, e o desenvolvedor
pode obter solues completas atravs de especificaes em alto nvel, normalmente uma DSL
oriunda da anlise SCV (Seo 3.1.2).
Um gerador pode ser aplicado em conjunto com as tcnicas descritas na seo anterior. A
diferena que um gerador possui um grau a mais de liberdade, podendo introduzir variaes
tambm no momento da gerao. Com isto, a granularidade das partes variantes est abaixo do
nvel de componentes, ou seja, o prprio cdigo dentro do componente pode ser feito genrico.
Isto alcanado atravs de fragmentos de cdigo variantes que podem ser sistematicamente
arranjados para produzir a implementao de um componente (MUTHIG; PATZKE, 2004).
Para produzir geradores, normalmente o uso de templates preferido. Um template um
arquivo de texto qualquer instrumentado com construes de seleo e expanso de cdigo
(CZARNECKI; EISENECKER, 2000). Estas construes so responsveis por realizar consultas
em uma entrada, que pode ser um programa ou especificao textual, um conjunto de janelas e
dilogos, no estilo wizard, ou mesmo diagramas (CLEAVELAND, 1988). A informao resultante
destas consultas ento utilizada como parmetro para produzir cdigo personalizado, em
qualquer linguagem textual.
Para ilustrar este processo, considere o seguinte cenrio: uma empresa deseja agilizar a
produo de formulrios HTML para incluir em sua aplicao Web. Existem centenas de
formulrios distintos, e os campos de cada formulrio mudam constantemente, de forma que
a manuteno deste conjunto de pginas normalmente trabalhosa.
Uma soluo baseada em DSL e templates composta de pelo menos trs elementos
principais. O primeiro um formato de entrada, que permite que um desenvolvedor especifique
o contedo de cada formulrio, tais como os campos, tipo de dados, tamanho, etc. Dentre os
possveis formatos, o XML apresenta vantagens pela facilidade de se processar as informaes.
60
Bibliotecas com suporte a linguagens como XPATH (W3C, 1999a) facilitam o trabalho de se
consultar as informaes.
O segundo elemento o template, neste caso uma pgina HTML anotada, segundo o
formato JET, com cdigo JAVA que consulta a entrada do gerador. O terceiro elemento o
processador de templates, responsvel por instanciar o template com base na entrada. A Figura
7 ilustra esse processo, onde cada trecho do template processado para consultar o arquivo de
entrada e produzir o cdigo correspondente.
Figura 7: Gerao de cdigo baseada em templates
Apesar de simples, este exemplo demonstra os possveis benefcios da abordagem. A

manuteno facilitada, pois no necessrio inspecionar trechos obscuros de cdigo HTML
para realizar mudanas. possvel produzir novos formulrios simplesmente adicionando um
novo elemento <formulario> na especificao, ao invs de copiar um formulrio existente e
modificar o cdigo.
Destaca-se tambm a facilidade de adoo por parte de desenvolvedores, uma vez que esta
abordagem permite gerar cdigo em qualquer linguagem ou formato (CZARNECKI; EISENECKER,
2000). Alm disso, enquanto outras abordagens produzem cdigo-fonte que normalmente no
seria escrito mo (CLEAVELAND, 1988), o uso de templates propicia a gerao de cdigo mais
legvel, o que desejvel (VLTER, 2008) ou mesmo crtico em muitos casos (CZARNECKI;
EISENECKER,
2000). Isto porque o template parecido com a sada desejada, acrescido
de anotaes e instrues que realizam a consulta na entrada e produzem a sada desejada

(CLEAVELAND, 2001).
Existem tambm padres de projeto que podem ser utilizados com geradores de cdigo. A
exemplo dos padres de projeto de software tradicionais, estes buscam oferecer solues para
61
problemas comuns envolvendo o desenvolvimento de software baseado em gerao de cdigo.

Vlter (2003), Vlter e Bettin (2004) apresentam uma lista com estes padres.
3.3
Consideraes finais
Neste captulo foram apresentados detalhes sobre algumas caractersticas importantes

relacionadas reutilizao de software e ao desenvolvimento orientado a modelos que tm
sido adotadas de maneira prtica, em funo dos conceitos e objetivos inerentes a cada uma
dessas duas abordagens. De fato, cada rea possui objetivos em comum, mas emprega tcnicas
distintas, sendo necessrio cuidado especial ao combin-las em uma nica abordagem.
Em especial, destaca-se o fato de que a combinao de reutilizao e MDD no ocorre
somente em pontos isolados do processo, mas deve ser iniciada na anlise, passando pelo
projeto, at a implementao, e deve incluir um gerenciamento adequado da variabilidade.
Nesta tese, a engenharia de domnio foi identificada como a estratgia de processo a ser utilizada
e complementada com tcnicas do MDD, de forma que a preocupao com a modelagem se faz
presente em todo o processo de reutilizao, efetivamente elevando o nvel de abstrao do
desenvolvimento.
Nos prximos captulos so apresentadas uma viso geral e descries detalhadas sobre
as atividades da abordagem definida nesta tese, com especial ateno em como os pontos
discutidos neste captulo so combinados de forma a oferecer um melhor suporte reutilizao
em alto nvel, utilizando MDD.
63
Viso geral da abordagem
Neste captulo apresentada uma viso geral da abordagem orientada a modelos para
reutilizao de software proposta nesta tese. So apresentados o seu objetivo, sua estrutura
e uma breve descrio de suas atividades. No final feita uma anlise frente aos modelos de
maturidade de reutilizao e MDD, visando melhor ilustrar seu escopo e cobertura no processo
de software.
4.1
Objetivo da abordagem
A abordagem orientada a modelos para reutilizao de software tem como objetivo:
Reutilizar... Sendo uma abordagem para reutilizao de software, o objetivo possibilitar

que o desenvolvimento de software possa reutilizar artefatos pr-existentes ao invs de
construir tudo a partir do incio (KRUEGER, 1992). Idealmente, nenhuma oportunidade de
reutilizao deveria ser perdida, ou seja, deve-se tentar reaproveitar o mximo possvel
de software existente durante um novo desenvolvimento;
De forma sistemtica... Esta reutilizao, em contraste com uma abordagem ad hoc, que
altamente dependente de iniciativa, conhecimento e competncia individual, deve ser
sistemtica. Deve se basear em conceitos da engenharia, de forma a ser um processo
controlvel, gerencivel e repetvel (ROMBACH, 2000);
Considerando-se uma famlia de sistemas similares...
Para alcanar esta reutilizao
sistemtica, alm do foco no processo (ENDRES, 1993; BAUER, 1993; GRISS, 1994, 1995;
JOOS,
1994), deve-se promover uma mudana de paradigma, do desenvolvimento de
sistemas nicos para a preocupao com uma famlia de sistemas similares (FRAKES;
ISODA,
1994). Dessa forma, a reutilizao ocorre de forma mais ampla, aproveitando o
potencial de similaridade entre as aplicaes que inerente maioria das organizaes

(EZRAN; MORISIO; TULLY, 2002; MILI; MILI; MILI, 1995);
64
Centrada no domnio... Neste sentido, a idia de domnio assume grande importncia.

Um domnio compreende um conjunto de aplicaes similares, que atendem a uma
determinada rea de problema do mundo real (CZARNECKI; EISENECKER, 2000). Desta
forma, focando-se em um domnio, tem-se um escopo bem definido para se planejar
a reutilizao.
O desenvolvimento centrado no domnio inclui a identificao das
caractersticas comuns do domnio, a criao de modelos do domnio, o projeto

arquitetural centrado no domnio, e a implementao de artefatos que sejam reutilizveis
no contexto do domnio;
Com foco em aplicaes concretas... Identificar o nmero e o tamanho dos sistemas que
fazem parte do domnio uma tarefa que, se realizada sem critrio, pode levar a alguns
problemas. Uma anlise livre tende a incluir diversos requisitos e sistemas que, apesar
de serem relacionados e pertinentes ao domnio em questo, podem nunca fazer parte
de uma aplicao desenvolvida pela organizao. Assim, o escopo do domnio deve ser
restrito a aplicaes e produtos de software concretos, e no idias e conceitos gerais do
domnio. A anlise deve focar em aplicaes existentes, futuras e potenciais (CLEMENTS;
NORTHROP,
2002; ALMEIDA et al., 2007b), buscando coletar, organizar, armazenar e
analisar as experincias em sua construo, conforme prev a engenharia de domnio

(CZARNECKI; EISENECKER, 2000);
Elevando a importncia dos modelos...
Os artefatos reutilizveis desenvolvidos no
devem se restringir a cdigo-fonte apenas, uma vez que o desenvolvimento centrado

no cdigo-fonte apresenta diversos problemas, como discutido na Seo 2.2. Assim,
a abordagem deve elevar o nvel de importncia dos modelos no processo (MELLOR;
CLARK; FUTAGAMI,
2003), de forma que os mesmos possam no somente ser utilizados
como mecanismos de comunicao entre as equipes e guias para o desenvolvimento

de software, mas tambm sirvam como entradas para mecanismos automatizados de
transformao de software e gerao de cdigo (SCHMIDT, 2006); e
Encapsulando o conhecimento em diferentes formas... Como resultado, a infra-estrutura de
reutilizao que produzida pela abordagem inclui no somente componentes de cdigo,
mas tambm artefatos do MDD:
1. Linguagens e ferramentas de modelagem especficas de domnio: consistem de
linguagens com poder expressivo capaz de representar os conceitos do domnio, e
ferramentas capazes de criar modelos segundo estas linguagens, de forma a facilitar
o entendimento de requisitos e a comunicao entre clientes/desenvolvedores; e
65
2. Transformaes de software: consistem de mecanismos que automaticamente

transformam um artefato de software em outro. Por exemplo, transformam modelos
em cdigo executvel, scripts de banco de dados, arquivos de configurao, alm
de outros artefatos que fazem parte do produto final. As transformaes podem
ser do tipo modelo-para-texto, ou seja, transformaes que geram cdigo, ou
modelo-para-modelo, que transformam um modelo em outro.
Em resumo, define-se o objetivo desta abordagem da seguinte forma.
Reutilizar software de forma sistemtica, considerando-se uma famlia de sistemas
similares, seguindo uma abordagem centrada no domnio, com foco em aplicaes concretas,
em um processo que eleva a importncia dos modelos e que encapsula o conhecimento em
diferentes formas: componentes de software, linguagens e ferramentas especficas de domnio
e transformaes de software.
4.2
Estrutura da abordagem
A abordagem est dividida em trs fases, que seguem a diviso de fases da engenharia de
domnio: anlise, projeto e implementao. A anlise de domnio tem como objetivo identificar
o escopo do domnio, identificar pontos comuns e variveis do domnio, identificar possveis
subdomnios automatizveis, e produzir documentao sobre estas informaes. O projeto do
domnio tem como objetivo principal projetar uma arquitetura especfica de domnio. Esta
arquitetura deve contemplar as variabilidades identificadas durante a anlise, e oferecer suporte
ao seu gerenciamento, considerando a existncia de diferentes tipos de variabilidades em
cada subdomnio identificado e artefatos do MDD, como DSLs, ferramentas de modelagem e
transformadores/geradores de cdigo. Por fim, na implementao do domnio, so produzidos
os artefatos de implementao, como componentes, DSLs, ferramentas, transformaes e
geradores de cdigo, de forma a implementar a variabilidade conforme prevista e planejada
nas fases de anlise e projeto.
A abordagem apresentada por meio de diferentes elementos:
Atividades: so os elementos principais da abordagem. Elas representam uma instncia
concreta de uma determinada prtica, e definem de forma sistemtica a sua execuo.
Para cada atividade, so identificados os papis, entradas e sadas associados;
Produtos de trabalho: so os artefatos produzidos ou utilizados durante a abordagem,
tais como documentos, modelos, cdigo, etc.
Cada produto de trabalho pode ser
66
modificado ou no por uma atividade, e portanto ele possui diferentes status em diferentes
momentos da abordagem. Por exemplo, um modelo arquitetural pode estar em status
inicial antes de uma determinada atividade, e passar para o status refinado aps esta
atividade;
Papis: representam as pessoas que executam ou auxiliam na execuo das atividades.
Um papel descreve caractersticas do indivduo, e no o indivduo em si, de forma que
uma mesma pessoa pode desempenhar vrios papis, e um papel pode ser desempenhado
por vrias pessoas. Por exemplo, no papel de especialista do domnio podem estar vrias
pessoas, cada uma com conhecimentos em pequenas partes do domnio; e
Diretrizes: em alguns casos onde no possvel estabelecer passos explcitos para a
execuo de uma atividade, a abordagem define diretrizes que podem ajudar ou guiar a
execuo da mesma.
As atividades da abordagem so apresentadas de forma seqencial, para facilitar seu

entendimento e ilustrar a seqncia lgica entre as mesmas. Porm, isto no significa um
modelo de ciclo de vida em cascata. As atividades podem (e devem) ser executadas de forma
paralela e iterativa. O Captulo 8 contm um possvel modelo de ciclo de vida para a abordagem,
visando ilustrar esta caracterstica iterativa da abordagem.
Cada atividade identificada por uma sigla, no formato AD.X, PD.X ou ID.X, onde X
um nmero seqencial, e AD, PD e ID representam Anlise de Domnio, Projeto do Domnio
e Implementao do Domnio, respectivamente. Sub-atividades so identificadas incluindo-se
outro nmero seqencial, como por exemplo AD.1.3, que identifica a terceira sub-atividade da
primeira atividade da fase de anlise de domnio.
Da mesma forma, cada produto de trabalho identificado por uma sigla, no formato PT.X,
onde X um nmero seqencial. Caso um produto de trabalho tenha diferentes status, o mesmo
identificado aps a sigla, como por exemplo PT.2.Inicial, que representa o produto de trabalho
2, no status Inicial.
4.3
Abrangncia da abordagem
A abordagem definida nesta tese no cobre todo o ciclo de vida do software, pois so
includas somente prticas de engenharia, que dizem respeito utilizao do MDD como
meio de aumentar a reutilizao de software, e algumas prticas referentes ao gerenciamento.
67
A Figura 8 ilustra a abrangncia da abordagem, em relao aos modelos de maturidade em

reutilizao e MDD, apresentados nas Sees 2.1.2 e 2.2.3.
Figura 8: Abrangncia da abordagem, em relao aos modelos de maturidade em reutilizao e

MDD
No total, as atividades da abordagem aderem a 6 prticas do modelo de maturidade em
reutilizao e 13 prticas do modelo de maturidade em MDD, conforme descrito a seguir1 :
Reutilizao
AP2 - Planejamento de reutilizao: uma das atividades iniciais da abordagem
consiste no planejamento da reutilizao, incluindo possveis riscos, e a adoo
desta abordagem pode ser considerada como uma deciso de planejamento, assim
como a definio de seu modelo do ciclo de vida;
AP3 - Definio dos objetivos da reutilizao: a abordagem contm uma atividade
para definio dos objetivos da reutilizao;
AP4 - Implementao do domnio: uma das fases da abordagem, que visa
implementar um domnio utilizando tcnicas do MDD;
AP6 - Integrao com o ciclo de vida do software: esta prtica consiste justamente
na definio desta abordagem e seus elementos;
AP7 - Anlise de domnio: a abordagem realiza a anlise de domnio voltada para
o MDD;
AP8 - Projeto de domnio: a abordagem engloba as prticas relacionadas ao projeto
de domnio, incluindo projeto arquitetural e suporte variabilidade;
1 Uma discusso mais detalhada sobre cada prtica dos modelos de maturidade, e a sua relao com a abordagem
aqui proposta, apresentada no Apndice C.
68
MDD
ENG1 - Decidir sobre convenes de modelagem: a abordagem possui uma
atividade na qual so analisadas as possibilidades de linguagens a serem utilizadas
na modelagem;
PJM1 - Decidir sobre ferramentas de modelagem: assim como na atividade
ENG1, a abordagem tambm busca analisar ferramentas existentes para serem
utilizadas;
ENG2 - Desenvolver modelo tcnico: a abordagem no est focada em um tipo
especfico de modelo, e portanto pode ser utilizada para desenvolver modelos
tcnicos;
ENG3 - Gerar cdigo a partir do modelo tcnico: a gerao de cdigo
um dos principais itens da abordagem, e portanto esta prtica est plenamente
implementada;
ENG5 - Desenvolver modelo independente de plataforma: a abordagem no
est focada em um tipo especfico de modelo, e portanto pode ser utilizada para
desenvolver modelos independentes de plataforma;
ENG6 - Desenvolver transformaes tcnicas modelo-para-texto: a abordagem
tem atividades para transformaes modelo-para-texto, visando dar suporte
variabilidade do domnio;
PJM2 - Modelar o processo de MDD do projeto:
a abordagem est
completamente modelada, e portanto pode ser utilizada como modelo do processo;

ENG8 - Desenvolver metamodelo centrado na arquitetura: o projeto arquitetural
voltado ao MDD est presente na abordagem, que tem atividades para que o
metamodelo seja centrado na arquitetura;
ENG9 - Desenvolver metamodelo independente de plataforma: a abordagem
no est focada em um tipo especfico de modelo, e portanto pode ser utilizada para
desenvolver metamodelos independentes de plataforma;
ENG10 - Desenvolver modelo de negcios: a abordagem no est focada em um
tipo especfico de modelo, e portanto pode ser utilizada para desenvolver modelos
de negcio;
ENG11 - Desenvolver transformaes modelo-para-modelo: as transformaes
modelo-para-modelo esto previstas na abordagem, como uma forma de
organizao e estruturao dos geradores de cdigo;
69
ENG13 - Integrar desenvolvimento de produto com desenvolvimento de

infraestrutura para uma famlia de produtos: esta a preocupao central da
abordagem;
ENG15 - Desenvolver linguagens especficas de domnio: a abordagem possui
uma atividade especfica para o desenvolvimento de DSLs no contexto da
reutilizao;
Conforme pode ser constatado, em termos de reutilizao a abordagem cobre
principalmente as prticas de engenharia, incluindo anlise, projeto e implementao do
domnio, alm de algumas prticas de gerenciamento isoladas, como planejamento e definio
de objetivos. Considerando-se este modelo, a presente abordagem no garante que uma
organizao atinja um nvel maior do que o nvel 1 de maturidade.
Em termos de MDD, a abordagem implementa quase todas as prticas de engenharia, com
exceo de quatro prticas. Como na reutilizao, poucas prticas de gerenciamento e suporte
do MDD foram includas. Considerando-se este modelo, a abordagem no garante que uma
organizao atinja um nvel maior do que o nvel 1 de maturidade. Porm, caso a organizao
defina uma atividade para gerao automtica de documentao (prtica ENG4), ela passa ao
nvel 2, pois esta a nica prtica do nvel 2 no implementada pela abordagem.
4.4
Consideraes finais
Neste captulo apresentou-se uma viso geral da abordagem, seus objetivos, sua estrutura e
seu escopo. Em particular, nota-se que a abordagem est mais focada nas prticas relacionadas
engenharia, deixando de lado a maioria das atividades de suporte e planejamento, que so
importantes, mas que esto fora do escopo desta tese.
A seguir as trs fases da abordagem so apresentadas em maiores detalhes, em captulos
separados, e com cada atividade sendo descrita de modo seqencial, visando facilitar seu
entendimento.
71
Anlise de domnio orientada a

modelos
A anlise de domnio envolve a identificao dos principais conceitos e elementos de um

domnio, e a determinao de seu escopo, isto , o que ser includo e o que ser excludo do
conjunto dos artefatos a serem desenvolvidos para o domnio. Alm disso, visa identificar as
comunalidades e variabilidades, ou seja, os pontos que so comuns a todas as aplicaes do
domnio, e os pontos que variam. Como discutido na Seo 3.1.1, uma das abordagens mais
comuns para esta tarefa a modelagem de features (KANG et al., 1990; KANG; LEE; DONOHOE,
2002).
Um dos principais desafios em projetar e implementar um domnio descrito em termos de
suas features est em como mapear estas features para a arquitetura e o cdigo, considerando
todos os relacionamentos e restries envolvendo as mesmas.
A existncia de uma feature pode levar a diferentes tipos de impacto no produto final. Em
casos mais simples, possvel ligar ou desligar uma feature atravs de um parmetro em um
componente, de forma que atribuindo um valor para este parmetro, a feature estar presente
ou ausente. Por exemplo, considere um domnio de automveis, onde existem trs tipos de
motores: Diesel, Gasolina e lcool.
Em um sistema mais simples, como por exemplo um sistema de uma companhia de aluguel
de automveis, o tipo do motor pode ser simplesmente representado com um atributo do tipo
inteiro, onde 0=Diesel, 1=Gasolina e 2=lcool. Escolher um valor apropriado para este atributo
o suficiente para que a feature seja includa na aplicao.
Em um sistema mais complexo, porm, como por exemplo um sistema de uma companhia
de transportes, a existncia de motores a Diesel, mais caros, pode requerer a presena
de um dispositivo GPS para aumentar a segurana.
Outro exemplo seria o dispositivo
de freios com atuao eletrnica precisar ser calibrado de uma maneira especfica, para
funcionar adequadamente com um motor a Diesel. A implementao destas restries no
to imediata quanto no exemplo do sistema de aluguel de automveis, e normalmente no
72
pode ser encapsulada dentro de um nico componente, necessitando ser realizada durante o
desenvolvimento da aplicao.
neste ponto que as tcnicas do MDD podem ser utilizadas. Ao invs de deixar que
estas tarefas sejam executadas pelo desenvolvedor da aplicao, o conhecimento sobre como
implementar estas restries encapsulado em transformaes MDD e linguagens especficas
de domnio (LEDECZI et al., 2001). Em um cenrio ideal, tudo o que um desenvolvedor
precisa fazer escolher quais features estaro presentes, especificar alguns parmetros, e uma
implementao automaticamente gerada.
Obviamente, este cenrio ainda est longe da realidade, j que nem todo cdigo pode ser
completamente gerado. Porm, normalmente h partes do domnio onde isto no somente
possvel, mas pode levar a enormes ganhos de produtividade, aumentando o nvel de
reutilizao. Porm, como identificar que partes do domnio podem ser automatizadas?
O argumento desta tese que esta atividade deve ser parte da anlise de domnio. Enquanto
analisando as features do domnio, devem existir maneiras para identificar o potencial para
automao em alguns subdomnios, numa preparao para o desenvolvimento de linguagens e
transformaes, que ir acontecer nas fases seguintes (LUCRDIO et al., 2008).
5.1
Objetivos da anlise de domnio
A fase de anlise de domnio faz parte da engenharia de domnio, e responsvel por

coletar informaes do domnio para as fases seguintes de projeto e implementao. Nesta fase,
os seguintes objetivos so almejados:
Coletar, registrar e documentar todas as informaes disponveis sobre o domnio:
estas informaes so coletadas de diversas fontes, incluindo o conhecimento de
especialistas e desenvolvedores experientes com o domnio, documentaes e padres
sobre o domnio, e tambm aplicaes pertencentes ao domnio. Neste ltimo caso,
utiliza-se toda informao disponvel, desde os prprios executveis at manuais e
cdigo-fonte, caso possvel;
Definir o escopo do domnio a ser desenvolvido: um domnio pode alcanar uma vasta
gama de aplicaes, cada uma com foco especfico em determinada parte. Alm disso, a
prpria definio do que est dentro ou fora de um domnio pode variar de acordo com
a viso dos especialistas, desenvolvedores, ou demais envolvidos, pois cada um destes
stakeholders possui seus prprios interesses distintos. Dessa forma, necessrio definir
73
com exatido o escopo a ser desenvolvido. Para tal definio, ao invs de buscar atender
a artefatos genricos do domnio, esta abordagem foca apenas um conjunto finito de
aplicaes ou produtos que sejam de interesse da organizao (CLEMENTS; NORTHROP,
2002). Dessa forma, so menores as chances de um artefato poder ser reutilizado em
aplicaes no previstas, mas aumenta-se consideravelmente o seu nvel de reutilizao
dentro deste escopo;
Criar modelos do domnio: modelos expressam os conceitos do domnio de forma a
facilitar o seu entendimento por parte dos projetistas e desenvolvedores. Alm disso, os
modelos devem explicitar as variabilidades e comunalidades dentro do domnio (KANG
et al.,
1990; JACOBSON; GRISS; JONSSON, 1997; GRISS; FAVARO; DALESSANDRO, 1998;
KANG et al., 1998; KANG; LEE; DONOHOE, 2002), de forma a facilitar o projeto de software
reutilizvel; e
Identificar os sub-domnios onde a automao possvel: nesta abordagem, o
desenvolvimento orientado a modelos utilizado para aumentar o nvel de reutilizao,
principalmente na implementao das variabilidades. Ao invs de deixar esta tarefa para
ser realizada pelos desenvolvedores de aplicaes, o conhecimento de como implementar
as variabilidades encapsulado em ferramentas de modelagem e transformaes
automticas de software (LEDECZI et al., 2001). O objetivo final que, aps a engenharia
de domnio, um desenvolvedor possa simplesmente configurar o produto desejado e
acionar as transformaes que automaticamente geram uma implementao vlida.
Assim, esta fase de anlise tambm tem como objetivo identificar sub-domnios onde
a automao possvel.
A abordagem aqui proposta uma evoluo do mtodo descrito em (ALMEIDA et al., 2006).
A diferena que aqui existe a preocupao com a identificao dos sub-domnios onde a
automao possvel, e portanto a anlise e tratamento das variabilidades realizada de forma
diferenciada, com este objetivo em mente.
5.2
Atividades da anlise de domnio
A anlise de domnio comea com uma atividade de planejamento (Atividade AD.1) que
visa coletar informaes para decidir se vale a pena investir no domnio e definir o escopo do
domnio a ser construdo. Em seguida, a modelagem do domnio (Atividade AD.2) cuida da
criao de modelos do domnio, que descrevem as funes, as comunalidades e variabilidades
do mesmo. A seguir, feita a identificao de possveis sub-domnios (Atividade AD.3),
74
visando determinar os locais onde possvel a automao atravs das tcnicas do MDD. A
prxima atividade cuida da validao e documentao do domnio (Atividade AD.4), reunindo
as informaes disponveis at o momento. Por fim, ocorre uma deciso sobre quais possveis
sub-domnios identificados devem ser includos ou excludos do processo, e quais precisam ser
investigados de maneira mais aprofundada (Atividade AD.5).
A seguir estas cinco atividades so descritas em maiores detalhes.
Atividade AD.1. Planejamento do domnio

Papis: analista do domnio, especialista do domnio, especialista de mercado
Entradas: PT.1.
Informaes sobre sistemas do domnio, PT.2.
Conhecimento do
especialista, PT.3. Informaes sobre stakeholders

Sadas: PT.4.Inicial. Planejamento do domnio, PT.5.Inicial. Mapa de aplicaes.
Descrio: a primeira etapa cuida da preparao e planejamento. necessrio determinar
se vale a pena investir na construo da infra-estrutura reutilizvel para o domnio em questo.
Para isso, nesta atividade so levantadas e registradas todas as informaes referentes ao
domnio.
Inicialmente, realizada uma tarefa de preparao (Sub-atividade AD.1.1), onde so
realizadas diversas anlises, tais como identificao dos stakeholders, anlise do mercado,
coleta de informaes, e definio de objetivos e restries, de acordo com as anlises e
informaes coletadas. Em seguida, realizada a definio do escopo (Sub-atividade AD.1.2),
onde as aplicaes existentes, futuras e potenciais so identificadas, e o escopo do domnio
definido.
Sub-atividade AD.1.1. Preparao

O objetivo da preparao levantar e registrar todas as informaes necessrias para o
planejamento. Para isso, o analista do domnio realiza as seguintes tarefas.
Anlise dos stakeholders: compreende a identificao dos diferentes stakeholders, seus
papis e interesses dentro do processo.
Definio dos objetivos: corresponde definio dos objetivos, de acordo com os
interesses dos stakeholders para o projeto.
Definio de restries: compreende a definio das restries impostas pela organizao
75
e pelas condies de mercado, deixando claro o que est alm do escopo do processo.
Anlise de mercado (se aplicvel): esta tarefa no-trivial - que pode ser realizada ou
no, dependendo dos custos, complexidade e maturidade da organizao com relao ao
domnio - consiste na pesquisa e anlise sistemticas dos fatores que determinam o sucesso
do domnio no mercado. Junto com um especialista de mercado, o analista do domnio coleta
informaes sobre o negcio, estudos e anlises da competio, segmentao de mercado,
planos de negcios, e a integrao desta informao em um plano estratgico de negcios coeso
(CLEMENTS; NORTHROP, 2002).
Coleta de dados: a tarefa realizada pelo analista do domnio, junto com o especialista
do domnio, responsvel por elicitar e examinar todo tipo de conhecimento sobre o domnio
em foco. Inclui a anlise de toda a documentao existente (planos de projetos, manuais de
usurio, modelos, dicionrios de dados), aplicaes existentes e o conhecimento do especialista
do domnio.
Toda a informao deve ser organizada de forma a facilitar sua posterior consulta. No
existe uma estrutura fixa para esta tarefa, que depende de condies especficas do projeto.
Enquanto organizaes que possuam sistemas de repositrio possam utilizar um mtodo
automtico de armazenamento e busca, simples pastas e arquivos podem tambm ser utilizados.
De qualquer forma, as seguintes diretrizes podem ser teis:
Definir e manter uma estrutura no muito detalhada dos dados coletados, mas que seja
consistente. Deve ser possvel ao menos descartar grandes quantidades de informao
durante uma busca;
Sempre que possvel, incluir referncias para as fontes originais; e
Manter uma lista sobre as pessoas envolvidas e consultadas durante o processo, com suas
informaes de contato, para eventuais consultas.
Sub-atividade AD.1.2. Definio do escopo
O objetivo desta sub-atividade identificar as features que estaro presentes na futura
arquitetura do domnio.
Inicialmente, o analista do domnio, com base nas informaes sobre sistemas do domnio
e stakeholders, identifica as aplicaes a serem contempladas no domnio. Existem trs tipos de
aplicaes distintas: aplicaes existentes (aplicaes que foram desenvolvidas antes do incio
do processo de anlise de domnio), aplicaes futuras (aplicaes para as quais os requisitos
76
esto bem claros, porm o desenvolvimento ainda no foi iniciado) e aplicaes potenciais
(aplicaes para as quais ainda no existem requisitos definidos, mas que so vistas como
relevantes).
Aps compreender as aplicaes relevantes, a lista de features desenvolvida.
identificao de features envolve abstrair o conhecimento obtido com os especialistas do

domnio e outros documentos, tais como livros, manuais de usurio, documentos de projeto
e cdigo-fonte (LEE; KANG; LEE, 2002). Porm, o volume de informao de um domnio tende
a ser muito grande. Neste sentido, quatro diretrizes (ALMEIDA et al., 2006) podem ser teis:
D1 . Analisar as terminologias usadas no domnio para identificar features: em alguns
domnios mais maduros, especialistas normalmente utilizam terminologia padronizada para
comunicar suas idias, necessidades e problemas. Assim, utilizando-se os mesmos termos
padres na identificao de features pode-se acelerar a comunicao entre o analista do domnio
e os provedores de informao (especialista do domnio e usurios finais).
D2 . Categorizar as features: as features devem ser categorizadas, utilizando, por exemplo
as quatro categorias descritas na Seo 3.1.1: features de capacitao, features de tecnologia do
domnio, features de tcnicas de implementao e features do ambiente operacional.
Para organizaes com pouca experincia na anlise de domnio, ou que esto trabalhando
com domnios instveis e pouco amadurecidos, aconselhvel concentrar-se nas features de
capacitao. Aps certa maturidade com o domnio ser alcanada, pode-se passar para as
demais features.
D3 . Tentar primeiro encontrar diferenas entre as aplicaes de um domnio, para s
ento tentar identificar as partes em comum: aplicaes de um mesmo domnio compartilham
um algo grau de funes em comum (COPLIEN; HOFFMAN; WEISS, 1998). Portanto, o espao
em comum deve ser consideravelmente maior do que as diferenas, e por consequncia mais
fcil encontrar as diferenas primeiro. A estratgia , inicialmente, identificar as aplicaes
existentes, e listar as features que caracterizam cada uma. Encontradas as diferenas, mais
fcil identificar as features comuns.
D4 . No identificar todos os detalhes de implementao que no se distinguem entre as
aplicaes do domnio: os desenvolvedores tendem a listar todos os detalhes de implementao
e identific-los como features, mesmo que no haja variaes entre eles. Mas importante notar
que um modelo de features no um modelo de requisitos, que expressa os detalhes de funes
internas. Por essa razo, esta atividade deve ser realizada pelo analista do domnio, que tende a
abstrair detalhes de implementao.
77
Por fim, as aplicaes e suas features so organizadas na forma de um mapa de

aplicaes. Neste mapa, colunas e linhas so utilizadas para representar features e aplicaes,
respectivamente. Algumas vezes, comum dividir uma feature em um conjunto de sub-features,
com um relacionamento entre eles, para facilitar seu entendimento.
Com base neste mapa de aplicaes, realizada uma anlise para identificar quais as
features estaro presentes no domnio, e quais no estaro. Este um processo iterativo, e
no precisa ser definido em definitivo logo na primeira iterao, sendo refinado sucessivamente
(GRISS; FAVARO; DALESSANDRO, 1998).
Como auxlio a esta atividade, podem ser empregadas funes que capturam a importncia
de uma determinada feature para o domnio, a exemplo da abordagem descrita em (ALMEIDA et
al.,
2006).
O mapa de aplicaes e a lista de features servem de guia para a prxima atividade, de
modelagem do domnio.
Atividade AD.2. Modelagem do domnio

Papis: analista do domnio, especialista do domnio
Entradas: PT.1.
Conhecimento do
especialista, PT.3. Informaes sobre stakeholders, PT.4.Inicial. Planejamento do domnio,

PT.5.Inicial. Mapa de aplicaes.
Sadas: PT.6.Inicial. Modelagem do domnio.
Descrio: esta atividade cuida da criao de modelos do domnio, agrupando as features
identificadas na atividade anterior. Tambm so desenvolvidos cenrios do domnio, com foco
na variabilidade.
Esta atividade responsvel por criar modelos expressivos do domnio, atravs da descrio
de suas features e seus relacionamentos, com foco nas variabilidades do domnio. Enquanto a
atividade anterior se preocupou com o escopo, aqui a preocupao com a estrutura interna do
domnio.
Existe na literatura um conjunto de diretrizes que podem auxiliar nesta atividade (ALMEIDA
et al.,
2006; LEE; KANG; LEE, 2002). No contexto do desenvolvimento orientado a modelos,
a modelagem das features e seus relacionamentos de grande importncia, pois ela indicam
pontos de especial interesse para os transformadores e ferramentas de modelagem, pois
especificam os procedimentos que mapeiam as abstraes em nvel de domnio.
78
Sub-atividade AD.2.1. Mapeamento da variabilidade em cenrios

O objetivo desta sub-atividade mapear os pontos de variao, identificados na modelagem
de features, para cenrios do domnio.
A modelagem de features identifica os pontos de variabilidade em termos estticos. Porm,
o impacto destas variabilidades nas funes (comportamento) realizadas pelas aplicaes
do domnio no fica explcito nos diagramas de features.
Assim, esta atividade cuida
do mapeamento entre a variabilidade no nvel de features e os cenrios que descrevem a

funcionalidade, de forma que possvel determinar o que muda no comportamento do domnio.
Para tanto, utiliza-se o conceito de casos de mudana (ECKLUND JR; DELCAMBRE; FREILING,
1996), uma tcnica similar aos casos de uso e que busca prever possveis mudanas de
requisitos durante a anlise. Aqui, utilizada para representar a variabilidade em termos de
possveis cenrios, cobrindo tanto requisitos funcionais como no-funcionais. Essencialmente,
um processo similar ao seguido pelo mtodo PuLSE (ProdUct-Line Software Engineering
(DEBAUD; FLEGE; KNAUBER, 1998)), com a diferena de que aqui so providos mais detalhes
sobre sua execuo.
Um caso de mudana um cenrio que descreve um ponto de variao no domnio, com
foco nas mudanas trazidas pela presena de uma ou mais variantes. Para cada caso de mudana,
so registradas as features relacionadas e os cenrios (casos de uso ou mudana) que so
afetados. Por exemplo, considere o modelo de features da Figura 9, e o caso de uso referente
feature de navegao, ilustrado no Quadro 1.
Figura 9: Exemplo de modelo de features para o domnio web

Conforme mostra a Figura 9, o domnio contempla uma feature opcional de busca (crculo
branco no final do conector). Um caso de mudana que descreve essa feature opcional
79
Quadro 1: Exemplo de caso de uso do domnio web

apresentado no Quadro 2.
Quadro 2: Exemplo de caso de mudana para a feature opcional de busca

Neste exemplo, o caso de mudana CM001. Realizar busca total descreve um cenrio
de uso considerando-se a presena desta feature opcional. So tambm indicadas as features
relacionadas, e os casos de uso afetados.
Mesmo um caso de mudana pode sofrer o impacto de algum outro ponto de variao.
Neste exemplo, a busca pode ser total ou parcial (features alternativas, indicadas pelos losangos
no final dos conectores, no diagrama da Figura 9). O caso de mudana CM001. Realizar busca
total descreve o cenrio correspondente feature Busca total. O Quadro 3 descreve a variante
Busca parcial.
Neste exemplo, diferentemente do exemplo anterior, a interseco entre os dois cenrios
maior, pois este cenrio descreve uma alternativa ao outro, e quase todos os mesmos passos
so seguidos. Neste caso, recomenda-se fatorar os dois cenrios, levando criao de um
80
Quadro 3: Exemplo de caso de mudana para a feature alternativa de busca parcial

terceiro que contenha as interaes em comum. O resultado a obteno de modelos mais
robustos que facilitam o entendimento e reduzem a redundncia (ECKLUND JR; DELCAMBRE;
FREILING, 1996).
Neste exemplo, isto poderia ser atingido com a criao de um terceiro cenrio
CM003. Exibir resultados da busca, que condensa os passos 3 e 4 descritos no fluxo normal
dos cenrios anteriores, assim como os fluxos alternativos.
Em termos de formato, tanto casos de uso como casos de mudana so praticamente
idnticos. A diferena que, conforme descrito no prprio nome, um caso de mudana
introduz uma alterao em um cenrio que considerado normal, tambm chamado de base
comum (COPLIEN, 2000). A definio do que um comportamento normal em um domnio
altamente subjetiva, e escolhas diferentes podem levar a diferentes decises posteriormente,
durante o projeto do domnio.
Existem basicamente dois tipos de variabilidade em relao base comum (COPLIEN,
2000):
Variabilidade positiva: mantm a base comum intacta, no violando nenhuma de suas
premissas, enquanto novos comportamentos so adicionados ou refinados; e
Variabilidade negativa: remove comportamento da base comum, no sentido em que uma
ou mais premissas que eram vlidas na base comum passam a ser violadas.
No exemplo do domnio web citado anteriormente, a busca parcial (Quadro 3) introduz uma
variabilidade positiva no passo 1, pois este um refinamento que acrescenta um comportamento
adicional, no violando as premissas do cenrio original. Tambm introduz uma combinao
81
de variabilidades negativa e positiva no passo 2, pois neste cenrio, no mais ocorre uma
busca no contedo todo, apenas no contedo especificado pelo usurio). Os fluxos alternativos
introduzem apenas variabilidades positivas, pois eles refinam o comportamento normal.
Em essncia, e principalmente na fase de anlise, ambos os tipos so vlidos e ocorrem
naturalmente dentro de um domnio. Porm, podem levar a decises de projeto diferentes.
Enquanto variabilidades positivas podem ser implementadas de maneira mais simples, as
variabilidades negativas exigem mecanismos para suprimir comportamento da base comum
(COPLIEN, 2000), o que pode levar a uma maior complexidade da arquitetura final. Assim, o
uso de variabilidades positivas preferido (COPLIEN; HOFFMAN; WEISS, 1998; COPLIEN, 2000).
Nesta tese, foram definidos os seguintes passos, numa forma sistemtica, de se tomar a
deciso sobre quais cenrios fazem parte da base comum e quais introduzem variabilidades:
1. Comear com as features mandatrias, pois estas estaro presentes no domnio. Estas iro
fazer parte dos casos de uso - os cenrios que descrevem o comportamento normal;
2. Para cada feature opcional, criar um caso de mudana;
3. Para as features alternativas onde obrigatria a existncia de ao menos uma variante,
escolher aquela que representa a maioria dos casos para fazer parte da base comum. No
exemplo acima, se a busca total est presente em mais produtos do que a busca parcial,
esta seria escolhida para incluso como um caso de uso. A busca parcial seria modelada
como caso de mudana; e
4. Caso o processo resulte em casos de mudana que apresentam variabilidade negativa,
avaliar a possibilidade de transformao em variabilidade positiva.
Para realizao do ltimo passo, o seguinte mtodo pode ser utilizado.

Supondo que um caso de uso UC001 possua 5 passos - p1, p2, p3, p4 e p5: aps anlise da
variabilidade, descoberto um caso de mudana CM001, que possui 4 passos: p1, p2, p4 e p5.
CM001 introduz uma variabilidade negativa em UC001, pois ele remove p3 do comportamento
normal, ou base comum. Neste caso, no existe variabilidade positiva introduzida por
CM001, e portanto basta inverter os cenrios, transformando CM001 no cenrio normal, e
UC001 no caso de mudana.
Porm, caso CM001 possua os passos p1, p2, p4, p5 e p6, a simples inverso no
suficiente, pois sempre existir uma variabilidade negativa, no importando qual destes cenrios
faz parte da base comum. Neste caso, pode-se criar um terceiro cenrio, que possui os passos
82
em comum, por exemplo UC001: p1, p2, p4 e p5, e dois casos de mudana CM001: p1, p2,
p3, p4 e p5 (antigo UC001), e CM002: p1, p2, p4, p5 e p6 (antigo CM001). Como resultado,
somente variabilidades positivas so introduzidas.
O mesmo pode ser feito quando dois cenrios diferem em um determinado passo. Neste
caso, ocorre a combinao de variabilidade negativa e positiva (removendo um comportamento
comum, e adicionando outro em substituio), e o mesmo mtodo pode ser aplicado para
remover a parte negativa.
Atividade AD.3. Identificao de sub-domnios

Entradas: PT.1.
Conhecimento do

PT.5.Inicial. Mapa de aplicaes, PT.6.Inicial. Modelagem do domnio.
Sadas: PT.7.Inicial. Candidatos a sub-domnio.
Descrio: a complexidade da maioria dos domnios torna virtualmente impossvel a tarefa
de se formalmente especificar o comportamento de um domnio completo (HADDAD; TESSER,
2002). Tambm prejudica a sua reusabilidade, uma vez que o escopo exato dos elementos do
domnio e seus relacionamentos difcil de compreender e gerenciar. Por estes motivos alguns
autores, como Jarzabek (1997), defendem a idia de que um domnio deve ser decomposto para
facilitar o processo de desenvolvimento para reutilizao.
Alm disso, grandes sistemas dificilmente podem ser automatizados por um nico gerador.
Normalmente so necessrios diferentes geradores trabalhando em conjunto para possibilitar a
automao de um domnio completo (CZARNECKI; EISENECKER, 2000). Por estes motivos, na
engenharia de domnio com a utilizao de tcnicas do MDD, a identificao dos sub-domnios
uma tarefa crucial, pois permite ao engenheiro de domnio projetar e implementar ferramentas
de modelagem, transformaes e geradores especficos para os sub-domnios que possuem
maior capacidade de automao, de forma mais controlvel.
Esta atividade lida com esta identificao dos sub-domnios que podem ser automatizados
utilizando tcnicas do MDD, com foco no aumento da reusabilidade dos artefatos do domnio.
Existem na literatura poucos trabalhos que tratam da decomposio de um domnio em
sub-domnios (JARZABEK, 1997; HADDAD; TESSER, 2002; MAIDEN; SUTCLIFFE, 1996; LEE;
KANG,
2003). Apesar de no almejarem a criao de DSLs voltadas para o desenvolvimento
83
orientado a modelos, estes trabalhos descrevem problemas similares no contexto de reutilizao,

e oferecem algumas contribuies que podem auxiliar na execuo desta atividade. Com base
nesta literatura disponvel, e nas experincias com estudos de casos, nesta tese as seguintes
diretrizes foram definidas para esta atividade:
Foco na automao: enquanto a maioria dos autores no apresenta critrios claros para
decompor um domnio, no desenvolvimento orientado a modelos isto muito claro:
o sub-domnio deve poder ser automatizado, atravs de ferramentas de modelagem e
transformaes;
Importncia do especialista do domnio: muitos autores concordam que o conhecimento
do especialista do domnio extremamente valioso nesta atividade (JARZABEK, 1997;
HADDAD; TESSER,
2002; MAIDEN; SUTCLIFFE, 1996). Desta forma, a identificao de
sub-domnios deve ser guiada por este profissional;

Dividir para conquistar: o conceito bsico de diviso de um problema grande em partes
menores tambm til no processo de desenvolvimento para reutilizao. Diferentes
tcnicas podem ser utilizadas, dependendo do contexto.
Relacionamentos do tipo
ParteDe e Um podem ser utilizados como tcnica de decomposio, onde cada

sub-domnio ou parte de um sub-domnio maior, ou uma instncia. Alm disso,
a maioria dos autores concorda que a diviso deve seguir a categorizao natural do
domnio, o que mais uma vez ressalta a importncia do especialista nesta tarefa;
Relacionamento features/sub-features: features so divididas em sub-features para
ajudar na tarefa de compreenso do domnio e sua variabilidade, e a anlise destes
relacionamentos (LEE; KANG, 2003) leva a uma sub-diviso natural do domnio.
Features muito prximas so normalmente boas candidatas a pertencerem a um mesmo
sub-domnio.
Ateno s features que aparentam estar separadas das demais pode
tambm levar identificao de um sub-domnio distinto;

Domnios atmicos: idealmente, o sub-domnio identificado deve ser atmico, ou seja,
no pode ser substancialmente decomposto sem alterar suas propriedades primrias
(HADDAD; TESSER, 2002). Isto importante para manter o sub-domnio simples e
gerencivel, e portanto mais fcil de automatizar; e
Repetio: uma boa indicao sobre o que pode ser automatizado o nvel de repetio
que ocorre com um projeto, estrutura ou trecho de cdigo. Se algum trecho de cdigo
aparece repetidamente em diferentes partes do produto, mesmo que no exatamente,
provvel que uma mquina consiga fazer o trabalho de cpia parametrizada. Pode
84
valer a pena tentar procurar um sub-domnio associado a este trecho. Outra tcnica para
encontrar repeties a busca por padres recorrentes (KNODEL et al., 2005).
Alm dessas diretrizes, a experincia prtica com modelagem de domnio (TOLVANEN,
2005) mostra que um aumento incremental do escopo a melhor forma de se chegar ao
tamanho ideal do sub-domnio, comeando-se com um escopo pequeno, desenvolvendo partes
da linguagem e transformaes, e incrementando-o sucessivamente.
As seguintes sub-atividades so responsveis pela identificao dos sub-domnios.
Inicialmente, feita uma seleo inicial de candidatos a sub-domnio (Sub-atividade
AD.3.1). Em seguida, so identificadas linguagens de modelagem (Sub-atividade AD.3.2) e
ferramentas (Sub-atividade AD.3.3). Para cada sub-domnio candidato, feita a atribuio
de nvel de confiana (Sub-atividade AD.3.4), onde so avaliadas a maturidade e o estado de
cada sub-domnio identificado at o momento. Por fim, os sub-domnios so documentados
(Sub-atividade AD.3.5).
Sub-atividade AD.3.1. Seleo de candidatos a sub-domnio
O objetivo desta sub-atividade identificar potenciais sub-domnios dentro do domnio.
O analista do domnio tenta identificar, com base nas informaes coletadas e com o auxlio
das diretrizes descritas anteriormente, possveis sub-domnios.
Apesar do conhecimento
do especialista do domnio ser a principal fonte de informao para execuo desta tarefa,
o modelo de features pode ser til.
Observando-se o modelo de features, o analista
pode identificar palavras-chave que representam um sub-domnio. Conforme destacado por

(MAIDEN; SUTCLIFFE, 1996), a categorizao natural do domnio a melhor indicao de onde
encontrar um sub-domnio.
Lee & Kang apresentam a tcnica de anlise de agrupamento de features (LEE; KANG, 2003),
que pode ser utilizada nesta atividade. A tcnica se baseia na identificao das unidades de
agrupamento de features (FBU - Feature Binding Units). Uma FBU um conjunto de features
relacionadas que juntas executam um servio ou operao dentro do domnio, ou seja, devem
coexistir para que este servio esteja presente no produto final. Esta tcnica tem o objetivo de
auxiliar no processo de configurao dos produtos, determinando quais conjuntos de features
estaro presentes dependendo da configurao desejada.
O processo de anlise das FBUs inicia-se com a identificao das features de capacitao
que representam servios independentemente configurveis, ou seja, as macro funcionalidades
principais do domnio que podem ser adicionadas ou removidas de um produto como unidades
85
independentes. Normalmente, estas so as features localizadas no topo do diagrama. A partir

destas features principais, percorre-se o modelo, incluindo as demais features relacionadas que
so necessrias para que esta macro funo possa ser executada.
Dentro de uma FBU identificada, podem existir features que so opcionais ou alternativas,
podendo ser selecionadas de acordo com a necessidade do produto. Estes sub-conjuntos de
features devem ser separados em FBUs diferentes, pois a exemplo das features de capacitao,
tambm representam pontos de variao que podem ser independemente configurveis.
Cada FBU potencialmente um candidato a sub-domnio, porm esta no
necessariamente a melhor escolha. Pode-se, por exemplo, unir duas ou mais FBUs em um nico
sub-domnio, incluir ou remover features individualmente, ou mesmo sub-dividir uma FBU em
mais de um sub-domnio. Estas escolhas, porm, devem ser feitas somente mais adiante no
processo, quando mais maturidade sobre os sub-domnios adquirida.
Para cada candidato a sub-domnio, as features correspondentes so identificadas. Isto pode
ser realizado em uma matriz, relacionando cada feature ao seu sub-domnio correspondente.
Opcionalmente, pode ser produzida uma representao grfica do sub-domnio, em um
diagrama que contm somente as features a ele pertencentes.
Neste ponto, a sobreposio de sub-domnios no um problema, uma vez que pode ser
que alguns dos sub-domnios sejam descartados. Posteriormente, com a evoluo do processo
e os refinamentos que se seguem, este problema ser analisado.
Sub-atividade AD.3.2. Identificao de linguagens de modelagem

O objetivo da identificao de sub-domnios possibilitar a definio de uma DSL que
consiga representar a variabilidade no capturada nas features e nos cenrios. Em domnios
mais maduros, porm, podem j existir linguagens sendo utilizadas, como por exemplo a
modelagem entidade-relacionamento, bastante comum. Mesmo que por algum motivo no
possam ser diretamente utilizadas, essas linguagens podem oferecer pistas e informaes
importantes na definio de uma nova DSL. Nesta atividade, o analista do domnio tenta
determinar se existe uma ou mais linguagens para o domnio. O especialista do domnio
consultado, alm das documentaes existentes, tais como manuais e documentao das
aplicaes existentes, caso disponvel.
A existncia de uma linguagem especfica de domnio indica que este domnio est
consideravelmente maduro e, portanto, os benefcios do desenvolvimento orientado a modelos
sero maiores (TOLVANEN; KELLY, 2005).
86
Caso exista cdigo-fonte disponvel, h a possibilidade de existirem exemplos de modelos

ou linguagens especficas para o domnio ou algum sub-domnio.
importante ressaltar que modelos nem sempre possuem uma representao grfica que
segue alguma linguagem conhecida, como a UML, por exemplo. Outras linguagens, incluindo
arquivos de configurao e modelos textuais, devem tambm ser consideradas.
O modelo de features tambm pode oferecer dicas sobre o que procurar. Palavras-chave
presentes no modelo de features, tais como nomes de features, podem ocorrer dentro da
documentao ou cdigo-fonte.
Aps esta anlise, criada uma lista com as linguagens identificadas, associando-as com
os sub-domnios correspondentes. Caso nesta etapa seja encontrada uma linguagem referente
a um sub-domnio ainda no identificado, acrescenta-se uma observao para uma re-anlise a
ser realizada mais adiante no processo.
Sub-atividade AD.3.3. Identificao de ferramentas
A exemplo das linguagens especficas de domnio, a existncia de uma ferramenta de
configurao ou modelagem um indicativo de que o sub-domnio em questo apresenta alto
grau de maturidade, e portanto as chances da reutilizao de software orientada a modelos ter
sucesso so maiores. Em domnios extremamente maduros, podem existir at geradores de
cdigo que podem ser reaproveitados.
Novamente, o conhecimento do especialista do domnio essencial, mas manuais e
documentao tambm devem ser consultados, uma vez que eles podem referenciar ferramentas
usadas para criar modelos ou gerar partes da aplicao. O cdigo-fonte tambm deve ser
inspecionado, pois comum a existncia, no cdigo gerado, de dados sobre a ferramenta que o
gerou, data da gerao, entre outras informaes teis.
As ferramentas identificadas so ento listadas e descritas, incluindo toda informao
possvel, uma descrio de suas funcionalidades, os artefatos que podem ser gerados por ela
e referncias para fontes externas. Novamente, caso seja encontrada uma ferramenta referente a
um sub-domnio ainda no identificado, acrescenta-se uma observao para posterior re-anlise.
Sub-atividade AD.3.4. Atribuio de nvel de confiana
Os sub-domnios identificados nem sempre podem ser representados em uma DSL e
automatizados utilizando tcnicas do desenvolvimento orientado a modelos. Mesmo para
aqueles que podem, o custo de se desenvolver linguagens, ferramentas e transformaes
87
pode ser muito alto. A automao de um sub-domnio tambm pode requerer alteraes
e refinamentos no modelo de features, o que obviamente causa grande impacto no
desenvolvimento. Finalmente, dependendo de qual sub-domnio implementado primeiro,
outros sub-domnios sobrepostos ou relacionados podem precisar ser revistos.
Por este motivo, todos os sub-domnios identificados so tratados como candidatos at
serem completamente realizados. Alm disso, deve existir um certo nvel de confiana de que
um sub-domnio ir render os resultados esperados quando realizado em forma de artefatos
para MDD, antes de se iniciar o projeto e implementao. Nesse sentido, a medida de nvel de
confiana serve como uma ferramenta de gerenciamento de riscos, ajudando a garantir que
mudanas crticas na arquitetura e nos modelos de anlise levem aos resultados esperados.
Tambm serve como um mecanismo de suporte tomada de deciso, auxiliando na coordenao
dos esforos durante o processo iterativo desta abordagem.
A determinao de um nvel de confiana de um sub-domnio altamente subjetiva e
dependente do conhecimento do especialista do domnio e da experincia dos engenheiros do
domnio. Nesta tese, as seguintes questes foram identificadas por possuir impacto na deciso,
e devem ser consideradas:
Existe uma linguagem de modelagem para o sub-domnio?
Caso exista, qual a maturidade desta linguagem: uma linguagem bem conhecida,
utilizada por especialistas em diferentes organizaes? Existe somente na organizao
em questo? Foi desenvolvida somente para este projeto?
A linguagem de modelagem foi validada, atravs de estudos de caso, para este projeto?
Existe uma ferramenta especfica para o sub-domnio?
Caso exista, qual a maturidade desta ferramenta: uma ferramenta bem conhecida,
utilizada por especialistas em diferentes organizaes? Existe somente na organizao
em questo? Foi desenvolvida somente para este projeto?
A ferramenta foi validada, atravs de estudos de caso, para este projeto?
Como a ferramenta se enquadra no projeto? Ela gera cdigo executvel? Se no, pode
ser adaptada para gerar cdigo? Quanto esforo necessrio para se utilizar a ferramenta
neste projeto?
Foi conduzido um projeto piloto para este sub-domnio, utilizando-se uma linguagem de
modelagem e ferramenta para gerao de cdigo?
88
Para determinar o nvel de confiana de forma mais sistemtica, o analista do domnio pode
desenvolver uma mtrica envolvendo estas e outras possveis questes que possam surgir. Uma
maneira simples desenvolver um questionrio com estas questes, atribuindo um peso para
cada resposta. A soma de todos os valores o nvel de confiana.
O analista do domnio deve consultar todos os stakeholders quando definir esta mtrica,
uma vez que existem diferentes fatores a serem considerados.
Dependendo do cenrio,
diferentes situaes podem requerer valores diferentes. Por exemplo, para sistemas crticos,
razovel utilizar somente linguagens e ferramentas bem conhecidas, e portanto maiores pesos
podem ser atribudos para estas questes. Em projetos com prazos mais curtos de entrega, esta
tambm pode ser a nica opo. Porm, em projetos com mais tempo disponvel, os valores
podem ser ajustados para incluir mais sub-domnios, j que h mais tempo para desenvolver
ferramentas e linguagens de modelagem. Este tambm o caso de domnios mais abrangentes.
Sub-atividade AD.3.5. Documentao dos candidatos a sub-domnio

Nesta atividade, o analista do domnio documenta os sub-domnios identificados, incluindo
toda informao coletada nos passos anteriores:
as features envolvidas, linguagens e
ferramentas, e o nvel de confiana.

Aqui o analista tambm descreve a interao entre o candidato a sub-domnio e o restante
do domnio. Neste ponto, esta descrio deve ser focada na cooperao em alto nvel entre
as features, com o objetivo de ajudar na deciso de investir na automao do sub-domnio ou
no. Em estgios posteriores, caso seja decidido que este sub-domnio ser automatizado, esta
interao dever ser refinada, incluindo uma definio mais detalhada da interface entre os
artefatos gerados para este sub-domnio e outros artefatos.
Atividade AD.4. Validao e documentao do domnio

Entradas: PT.1.
Conhecimento do

PT.5.Inicial.
Mapa de aplicaes, PT.6.Inicial.
Modelagem do domnio, PT.7.Inicial.
Candidatos a sub-domnio.
Sadas: PT.4.Validado. Planejamento do domnio, PT.5.Validado. Mapa de aplicaes,
PT.6.Validado. Modelagem do domnio e PT.7.Validado. Candidatos a sub-domnio.
89
Descrio: antes do modelo do domnio ser utilizado, ele precisa ser validado e
documentado.
A documentao j foi iniciada durante as atividades anteriores.
Nesta
abordagem, as features so documentadas segundo o formato descrito em (CZARNECKI;

EISENECKER,
2000), que inclui a sua descrio semntica, o raciocnio, exemplo de aplicao,
restries, e outras informaes (ALMEIDA et al., 2006).

Em seguida, feita a validao do domnio. O analista de domnio verifica homnimos
e sinnimos, com o objetivo de reduzir a ambigidade. Em seguida, o domnio validado
com relao s informaes dos stakeholders, os requisitos iniciais e demais documentos
relacionados.
Atividade AD.5. Deciso sobre incluso/excluso de sub-domnios

Entradas: PT.1.
Conhecimento do
especialista, PT.3. Informaes sobre stakeholders, PT.4.Validado. Planejamento do domnio,

PT.5.Validado. Mapa de aplicaes, PT.6.Validado. Modelagem do domnio, PT.7.Validado.
Candidatos a sub-domnio.
Sadas: PT.8. Histrico de decises sobre incluso/excluso de sub-domnios.
Descrio: nesta atividade, o analista do domnio, junto com o especialista e os demais
stakeholders, analisam os sub-domnios identificados com o objetivo de determinar se os
mesmos sero includos nas fases subseqentes de projeto e implementao.
Essa deciso leva em considerao o nvel de confiana dos sub-domnios candidatos, seus
relacionamentos com os demais elementos do domnio, e outros fatores externos, incluindo os
objetivos de negcio e condies de mercado.
A abordagem baseia-se num processo iterativo, e alguns sub-domnios podem estar mais
maduros, enquanto outros necessitam de mais desenvolvimento. Neste sentido, ao invs de
simplesmente incluir ou excluir um sub-domnio, existem diferentes nveis de decises (D) a
serem tomadas:
D1 . Excluso imediata: significa que o candidato a sub-domnio no passvel de
automao, e deve ser descartado imediatamente. Tipicamente, este sub-domnio tem
um baixo nvel de confiana, no existem linguagens de modelagem ou ferramentas que
do suporte;
D2 . Manter para avaliao posterior: significa que este sub-domnio tem chance de ser
90
automatizado, mas no existe evidncia concreta de que isto pode ser feito. Tipicamente,
tem um baixo nvel de confiana, nenhuma linguagem de modelagem ou ferramenta,
mas o especialista do domnio, ou a experincia com o desenvolvimento, indicam que
ele pode ser til aps algum desenvolvimento. No existe maneira de se estimar o
esforo para torn-lo um sub-domnio concreto, ou seja, muito arriscado iniciar algum
desenvolvimento neste sentido. Portanto, essa deciso indica que nenhuma ao ser
tomada nesta iterao. No entanto, caso os stakeholders aceitem o risco, este mesmo
candidato a sub-domnio pode se enquadrar no prximo nvel de deciso (D3 );
D3 . Iniciar investigao: se um sub-domnio possui alguma chance se ser automatizado,
mas as ferramentas para isso no esto disponveis, o mesmo pode ser investigado, por
meio do desenvolvimento de prottipos de linguagens de modelagem e/ou ferramentas de
modelagem e transformaes. Tipicamente, para se iniciar uma investigao, deve existir
alguma forma de se estimar o esforo necessrio, para reduo dos riscos. Alm disso,
apesar de esta deciso levar alocao de recursos e esforos, estes so mais limitados,
uma vez que no h impacto nos demais artefatos do domnio, e sempre possvel parar a
investigao sempre que necessrio, pois o sucesso do negcio no depende diretamente
desse desenvolvimento;
D4 . Iniciar o desenvolvimento de artefatos de produo: este o ponto sem retorno
para um sub-domnio. Neste nvel de deciso, a organizao compromete-se a incluir o
sub-domnio no processo de desenvolvimento, diferentemente do nvel D3 , onde ainda
existe a possibilidade de se descartar o sub-domnio. Um sub-domnio neste nvel
deve possuir um alto nvel de confiana, mas no necessariamente precisa possuir as
ferramentas para ser automatizado. Esta uma deciso crtica, uma vez que significa
empregar esforos e recursos de forma mais intensa, para automatizar o sub-domnio e
gerenciar o seu impacto no restante do domnio;
D5 . Iniciar um projeto piloto: antes de incluir um sub-domnio no processo final,
boa prtica executar um projeto piloto, para reduzir os riscos da introduo de uma nova
tecnologia no desenvolvimento, e reduzir as barreiras transferncia tecnolgica que ir
ocorrer. Este projeto piloto tambm serve para se verificar os benefcios reais da nova
tecnologia, e planejar a melhor maneira de aplic-la a projetos reais; e
D6 .
Incluso imediata: significa que o sub-domnio est maduro o suficiente,
possui ferramentas e uma ou mais linguagens de modelagem estveis e validados.

O nvel de confiana alto, e o sub-domnio j pode ser includo nas fases de
projeto e implementao. Tambm significa que o desenvolvimento dos artefatos deste
91
sub-domnio guiado pelas linguagens e/ou ferramentas definidas. Enquanto a maioria

dos sub-domnios somente ir alcanar este nvel aps passar pelos nveis 2, 3, 4
e 5, alguns sub-domnios bem conhecidos podem comear diretamente no nvel 5.
Alguns podem at comear diretamente no nvel 6, se a organizao sentir que possui
a experincia necessria para lidar com esta tecnologia.
Para tomar a deciso correta, o analista do domnio deve considerar toda informao
disponvel, e a deciso deve ser acordada com todos os stakeholders. Alm da informao
j mencionada, alguns outros critrios podem ajudar:
Experincia da equipe de desenvolvimento: se a equipe de desenvolvimento possui
experincia com algum sub-domnio, pode ser vantajoso focar neste sub-domnio, para
que seus benefcios possam ser alcanados sem muito esforo de entendimento e
aprendizado;
Tamanho do sub-domnio: sempre que possvel, deve-se comear com sub-domnios
menores e aument-los gradativamente (TOLVANEN, 2005). Apesar de domnios menores
levarem a menos benefcios em termos de reutilizao, so mais fceis de gerenciar e
implementar. Com o tempo, os mesmos tendem a evoluir;
Nvel de abstrao: sub-domnios que se encontram em um nvel de abstrao prximo
ao cdigo-fonte so mais simples de implementar, e esto entre os exemplos de maior
sucesso no desenvolvimento orientado a modelos (TOLVANEN; KELLY, 2005); e
Existncia de cdigo-exemplo: a existncia de exemplos de como o cdigo ou outros
artefatos devem ser gerados um fator importante. A abordagem de desenvolvimento
atravs de exemplos (WIMMER et al., 2007) facilita o processo de construo de
transformadores e geradores de cdigo.
Estes so apenas exemplos de critrios que podem ser considerados durante a tomada de
deciso. Cada domnio pode introduzir seus prprios conjuntos de critrios e particularidades a
serem considerados.
Como referncia, pode-se tambm utilizar a mtrica de nvel de confiana, definido-se
intervalos de valores para cada deciso. Por exemplo, sub-domnios com nvel de confiana
entre 0 e 5 levam a deciso D1 . Entre 6 e 10, deciso D2 , e assim por diante. Porm, esta
tcnica serve apenas como referncia. A deciso final deve ser tomada levando-se em conta
outros fatores, e no somente os includos na mtrica.
92
Aps a tomada de deciso para todos os candidatos a sub-domnio, o analista do domnio

deve lidar com a sobreposio entre eles. Neste ponto, s possvel determinar se dois
sub-domnios iro interferir um com o outro analisando se os mesmos possuem features em
comum. Mesmo que no existam features em comum, pode ser que os artefatos gerados para
um sub-domnio interfiram ou tenham impacto nos artefatos de outro sub-domnio. E no
possvel determinar isto sem aprofundar-se no projeto e implementao.
Alm disso, mesmo que no exista sobreposio de sub-domnios em nenhum nvel, ainda
assim a automao de um sub-domnio pode afetar outros. Por exemplo, a automao de
um determinado sub-domnio pode levar a mudanas/refinamentos nos requisitos, features ou
casos de uso, para dar suporte a uma nova linguagem de modelagem ou ferramenta. Dessa
forma, outros sub-domnios dependentes dos mesmos requisitos, features ou casos de uso sero
afetados.
Para evitar este problema, a seguinte restrio pode ser aplicada durante a tomada de
decises: somente um sub-domnio pode estar em desenvolvimento a cada vez. Isto significa
que as decises D4 , D5 e D6 so mutuamente exclusivas. Se j existir um sub-domnio sendo
desenvolvido ou testado em um projeto piloto, outros no podero estar na mesma situao.
Isto no vale para a deciso D3 , uma vez que no h problemas em se investigar um
sub-domnio junto com o desenvolvimento de outro.
Podem inclusive existir mltiplos
sub-domnios sendo investigados ao mesmo tempo.

Se uma organizao considerar esta restrio muito rgida, pode optar por ignor-la. Porm,
ela deve estar atenta s possveis sobreposies ou interferncias entre dois sub-domnios
sendo colocados em produo ao mesmo tempo. Na prtica, em geral, esta situao no
ocorrer com muita freqncia, j que no comum a existncia de muitos sub-domnios sendo
automatizados.
5.3
Consideraes finais
Neste captulo foi apresentada a fase de anlise de domnio, com atividades para promover a
reutilizao atravs do desenvolvimento orientado a modelos. As principais contribuies deste
captulo so as atividades sistemticas e as diretrizes para identificao dos sub-domnios para
automao. Tambm apresenta um modelo de decises para lidar com os riscos da incerteza
sobre a automao dos sub-domnios.
O Quadro 4 resume as atividades da anlise de domnio.
93
Atividades e sub-atividades
AD.1. Planejamento do domnio
AD.1.1. Preparao
AD.1.2. Definio do escopo
AD.2. Modelagem do domnio
AD.2.1. Mapeamento da variabilidade em
cenrios
AD.3. Identificao de sub-domnios

AD.3.1.
Seleo de candidatos a
sub-domnio
AD.3.2. Identificao de linguagens de
modelagem
AD.3.3. Identificao de ferramentas
AD.3.4. Atribuio de nvel de confiana
AD.3.5. Documentao dos sub-domnios
candidatos
AD.4.
Validao e documentao do
domnio
AD.5. Deciso sobre incluso/excluso de

sub-domnios
Entradas
PT.1. Informaes sobre sistemas do domnio
PT.2. Conhecimento do especialista
PT.3. Informaes sobre stakeholders
PT.4.Inicial. Planejamento do domnio
PT.5.Inicial. Mapa de aplicaes
PT.6.Inicial. Modelagem do domnio
Sadas
PT.4.Inicial.
Planejamento do
domnio
PT.6.Inicial.
Modelagem do
domnio

PT.6.Inicial. Modelagem do domnio
PT.7.Inicial. Candidatos a sub-domnio
PT.4.Validado. Planejamento do domnio
PT.5.Validado. Mapa de aplicaes
PT.6.Validado. Modelagem do domnio
PT.7.Validado. Candidatos a sub-domnio
PT.4.Validado. Planejamento do
domnio
PT.5.Validado. Mapa de aplicaes
PT.6.Validado.
Modelagem do
domnio
PT.7.Validado.
Candidatos a
sub-domnio
PT.8. Histrico de decises sobre
incluso/excluso de sub-domnios
PT.7.Inicial.
sub-domnio
Candidatos
Quadro 4: Resumo das atividades para anlise de domnio orientada a modelos

O Quadro 5 descreve os produtos de trabalho da fase da anlise de domnio.
O produto da anlise de domnio a definio completa do escopo, e a modelagem das
variabilidades e comunalidades, tanto em termos de features, que descrevem as variabilidades
estticas, como em termos de cenrios, que descrevem as variaes no comportamento.
Tambm so definidos nesta fase os candidatos a sub-domnios automatizveis.
94
Produto de trabalho
PT.1. Informaes sobre sistemas
do domnio
PT.3.
Informaes
stakeholders
sobre
PT.4. Planejamento do domnio
Descrio
Consiste de todas as informaes disponveis
sobre aplicaes daquele domnio, incluindo
documentos,
manuais,
executveis,
especificaes ou mesmo cdigo-fonte
Envolve todo o conhecimento dos
especialistas do domnio, que pode estar
documentado, ou somente na percepo do
especialista
Inclui toda informao referente aos
stakeholders
envolvidos,
desde
a
identificao de cada um deles at seus
interesses e necessidades relacionadas ao
projeto
Documento que descreve o domnio, seus
objetivos e restries, alm de listar os
stakeholders e as aplicaes de exemplo
PT.5. Mapa de aplicaes
Documento que mapeia todas as aplicaes

do domnio e suas respectivas features
PT.6. Modelagem do domnio
Documento que detalha as features do

domnio, especificando seus tipos e
relacionamentos.
Tambm contm os
casos de uso do domnio, e informaes
sobre os sub-domnios
Documento listando os sub-domnios, as
features correspondentes, e as listas de
linguagens de modelagens e ferramentas
especficas para os sub-domnios
Documento que registra as decises sobre
incluso/excluso dos sub-domnios nas
diferentes iteraes do processo
PT.7. Candidatos a sub-domnio
PT.8. Histrico de decises sobre

Status
Nenhum
Nenhum
Nenhum
1. Inicial: verso inicial do planejamento,

pode conter inconsistncias.
2. Validado: planejamento verificado em
busca de inconsistncias e erros.
1. Inicial: verso inicial do mapa, pode
conter inconsistncias.
2. Validado: mapa verificado em busca de
inconsistncias e erros.
1. Inicial: verso inicial da modelagem,
pode conter inconsistncias.
2. Validado: modelagem verificada em
busca de inconsistncias e erros.
1. Inicial: verso inicial do documento, pode
conter inconsistncias.
2. Validado: documento verificado em busca
de inconsistncias e erros.
Nenhum
Quadro 5: Descrio dos produtos de trabalho da fase de anlise de domnio
95
Projeto de domnio orientado a

modelos
O projeto do domnio uma fase essencial da engenharia de domnio (BOSCH, 2000). Seu
objetivo definir uma arquitetura de software especfica de domnio, e um conjunto de artefatos
reutilizveis que podem ser combinados para desenvolver aplicativos mais rapidamente e com
maior qualidade.
Em geral, a arquitetura deve ser projetada para atender aos principais
requisitos conforme percebidos pelos stakeholders, de forma a alcanar os principais atributos

de qualidade que so importantes para uma situao em particular (BASS; CLEMENTS; KAZMAN,
2003).
Em termos de engenharia de domnio, um dos pontos principais na definio da arquitetura
do domnio a reutilizao de software, e a capacidade de se desenvolver produtos de software
similares rapidamente, sem muitas modificaes ou adaptaes nessa arquitetura. Isto pode
ser alcanado por meio de um bom suporte comunalidade e variabilidade do domnio
(MOON; YEOM, 2006; CZARNECKI, 2005; WEISS; LAI, 1999; CLEMENTS; NORTHROP, 2002). A
arquitetura projetada deve no somente prever os pontos de variao, mas tambm efetivamente
providenciar o suporte requerido para sua implementao (BASS; CLEMENTS; KAZMAN, 2003).
H dois tipos fundamentalmente diferentes de complexidade relativa variabilidade
(VLTER; GROHER, 2007; CZARNECKI, 2005):
Configurao de rotina: tipo de variabilidade em que estruturas simples, como uma lista
de propriedades ou uma rvore, podem ser utilizados para configurao do produto; e
Construo criativa: tipo de variabilidade em que so necessrios modelos complexos,
como estruturas do tipo grafo ou linguagens textuais completas, para descrev-la
completamente.
Diferentes mecanismos de representao de variabilidade podem estar em diferentes locais
de um espectro que vai desde a configurao de rotina at a construo criativa. Por exemplo,
wizards so mecanismos simples, onde a cada passo um parmetro especificado, e portanto
96
localizam-se prximo configurao de rotina. O modelo de features (Seo 3.1.1) um

pouco mais complexo, mas ainda relativamente simples, localizando-se aproximadamente
na metade do espectro. Do lado criativo, encontram-se as linguagens especficas de domnio
(DSL) (CZARNECKI, 2005).
Para ilustrar este conceito, ser utilizado um exemplo envolvendo o domnio web de autoria
de contedo, que representa aplicaes web que permitem a publicao de contedo e sua
visualizao. Nestas aplicaes, um autor publica a informao, como notcias e mensagens,
que pode ser acessada e visualizada pelos usurios. Portais de notcias, fruns e blogs so
alguns exemplos de aplicaes deste domnio.
O modelo de features da Figura 10 se refere a este domnio. H duas features principais:
navegao e administrao. A navegao (feature mandatria) consiste no contedo visvel ao
usurio e busca automtica, que pode ser simples e/ou avanada (features alternativas do tipo
or, onde mais de uma alternativa pode estar presente). A submisso de contedo de usurio
opcional. No lado da administrao, a feature de autoria (mandatria) representa as funes de
publicao do contedo. Se existir contedo de usurio, este pode ou no ser moderado (a seta
curva indica uma dependncia entre moderao e contedo de usurio). Estas so features de
capacitao (Seo 3.1.1).
Figura 10: Modelo de features do domnio web de autoria de contedo

O que tambm varia de aplicao para aplicao deste domnio a estrutura da informao
(tipos de documento e seus relacionamentos) e como a mesma apresentada ao usurio (pginas
e links). Para representar esta variabilidade, no lado inferior da figura esto as features de
97
tecnologia do domnio (Seo 3.1.1): pginas (formulrios ou relatrios) e links so utilizados

para exibir a informao em um navegador, e tipos de documentos e relacionamentos descrevem
a estrutura da informao.
A maioria das features, como a busca, contedo de usurio e moderao, representa a
variabilidade do tipo presente/ausente, que fica prxima do lado da configurao de rotina
no espectro de variabilidade. Desta forma, grande parte do suporte variabilidade pode ser
conseguido somente atravs de configurao, com a ajuda de uma arquitetura bem projetada e
um conjunto de componentes reutilizveis.
Porm, features como tipos de documentos e relacionamentos contm variabilidades mais
complexas, para as quais todos os detalhes no podem ser capturados somente com modelos de
features, pois estes so muito genricos (TOLVANEN; KELLY, 2005). Estruturas ou mecanismos
mais ricos so necessrios, com mais poder expressivo capaz de capturar detalhes sobre os
conceitos do domnio, seus relacionamentos e restries.
Nestes casos, possvel simplesmente implementar manualmente o suporte a esta variao,
que o que acontece no desenvolvimento tradicional. Para isso, um desenvolvedor humano
utiliza suas habilidades de programador e uma linguagem de programao, possivelmente com
a ajuda de uma biblioteca ou framework que facilite este trabalho criativo.
Mas no caso do MDD, onde se deseja automatizar o suporte variabilidade, a tecnologia
de escolha normalmente uma linguagem especfica de domnio (DSL), pois ela pode
complementar o modelo de features com detalhes sobre variabilidades mais complexas em
partes do domnio (TOLVANEN; KELLY, 2005; CZARNECKI, 2005).
Adicionalmente, uma
DSL pode ser utilizada junto com transformaes para automaticamente gerar artefatos de
implementao, que o objetivo final do desenvolvimento orientado a modelos (CZARNECKI,
2005).
O elemento que une estes artefatos a arquitetura do domnio, que deve ser projetada
para dar suporte tanto variabilidade baseada em features quanto variabilidade baseada em
DSLs. Tambm deve ter preocupaes sobre a existncia, alm dos componentes do domnio, de
artefatos especficos do MDD, como DSLs, transformaes de software e geradores de cdigo.
Um problema que a maioria das abordagens de engenharia de domnio existentes no
define como projetar uma arquitetura de software especfica de domnio com este objetivo. A
literatura possui muitos trabalhos que discutem detalhes sobre como produzir uma arquitetura
para reutilizao (BASS; CLEMENTS; KAZMAN, 2003; BOSCH, 2000), mas estes no consideram o
MDD. E aqueles que consideram so normalmente focados no processo de derivao automtica
de produtos (WEISS et al., 2008; VLTER; GROHER, 2007; BOTTERWECK; OBRIEN; THIEL,
98
2007; ARBOLEDA; CASALLAS; ROYER, 2007; TRASK et al., 2006; TOLVANEN; KELLY, 2005;
CZARNECKI; HELSEN; EISENECKER,
2004b), e no na tarefa de produzir uma arquitetura de
domnio que adequada para o MDD, ou seja, que contemple elementos capazes de integrar
DSLs, transformaes e geradores de cdigo.
Alm disso, a maioria destas abordagens, como as descritas por Almeida et al. (2007b),
Keepence e Mannion (1999), Lee e Kang (2004), baseia-se na identificao da variabilidade
somente em termos de features. Como j discutido anteriormente, h outros tipos de variao,
como aquelas presentes em modelos de entidades, por exemplo (BARTHOLDT; OBERHAUSER;
RYTINA,
2008), que so mais complexas do que possvel capturar em um modelo de
features (RABISER; GRNBACHER; DHUNGANA, 2007), sendo necessria uma DSL especfica
para representar a variabilidade de modo adequado ao MDD.
6.1
Objetivos do projeto de domnio
Existem conceitos relacionados ao MDD que devem ser considerados durante o projeto do
domnio, especialmente durante a definio da arquitetura do domnio. Alm da variabilidade
mais complexa discutida anteriormente, a arquitetura e seus componentes devem contar com a
existncia de DSLs e transformaes, que por sua vez devem ser capazes de produzir artefatos
de implementao voltados quela arquitetura especfica.
A fase de projeto do domnio tem os seguintes objetivos:
Identificar as diretrizes arquiteturais: o projeto arquitetural deve ser direcionado pelos

objetivos de negcio e requisitos mais importantes, considerando-se o ponto de vista
de diferentes stakeholders. Estes so chamados de diretrizes arquiteturais (BASS;
CLEMENTS; KAZMAN,
2003), e so responsveis por moldar a arquitetura de forma a
atender a todos os requisitos da melhor forma possvel. Nos contextos de reutilizao

e MDD, as diretrizes devem incluir, obrigatoriamente, as variabilidades em forma de
features e DSLs, e a existncia de artefatos do MDD, como DSLs e transformaes de
software;
Selecionar/definir tticas e padres: o projeto arquitetural deve cobrir as diretrizes
arquiteturais, em forma de tticas e padres que contemplem solues para cada requisito;
Definir a arquitetura e componentes: o projeto do domnio deve incluir uma definio
da arquitetura do domnio.
Junto com a arquitetura, devem ser especificados os
99
componentes do domnio, incluindo componentes de software tradicionais, servios, e

tambm artefatos do MDD, como DSLs, transformaes e geradores de cdigo; e
Documentar a arquitetura: como objetivo desta fase, deve ser produzida toda a
documentao referente arquitetura projetada, visando servir de guia para a fase de
implementao.
Esta fase de projeto inspirada nos mtodos descritos por Almeida et al. (2007b), deBaud
e Schmid (1999), Bass, Clements e Kazman (2003), Clements, Kazman e Klein (2004), com
duas diferenas principais:
1. So oferecidos meios mais concretos para se elicitar diretrizes arquiteturais explcitas para
o suporte aos diferentes tipos de variabilidade, na forma de features, cenrios e linguagens
especficas de domnio, o que no descrito nos mtodos citados; e
2. Juntamente com as diretrizes, so providenciadas tticas para atend-las, utilizando
padres de projeto especficos para as diferentes formas de variabilidade, a exemplo de
outras abordagens da literatura (ALMEIDA et al., 2007b; KEEPENCE; MANNION, 1999; LEE;
KANG,
6.2
2004).
Atividades do projeto de domnio
O projeto do domnio um processo iterativo de refinamento. Inicia-se com o domnio todo,

e a cada iterao feito um refinamento que identifica novos mdulos, que sero refinados na
prxima iterao, e assim por diante, at que o projeto esteja concludo, em funo de um
entendimento satisfatrio sobre o que dever ser implementado. A primeira atividade cuida da
escolha dos mdulos a serem refinados (Atividade PD.1), sendo executada no incio de cada
iterao. Em seguida, so selecionadas as diretrizes arquiteturais (Atividade PD.2), que so os
requisitos mais importantes a serem atendidos pelo projeto da arquitetura. Para cada diretriz,
escolhe-se um ou mais padres arquiteturais (Atividade PD.3), responsveis por resolver cada
requisito individualmente, ajudando na obteno dos atributos de qualidade desejados para a
arquitetura. Os padres so ento aplicados durante o refinamento dos mdulos (Atividade
PD.4), de forma a identificar novos mdulos e dar forma arquitetura. Por fim, uma
atividade avalia a arquitetura ou arquiteturas projetadas, caso sejam definidas diferentes opes
arquiteturais (Atividade PD.5).
Estas atividades so detalhadas a seguir.
100
Atividade PD.1. Escolha dos mdulos a serem refinados

Papis: projetista do domnio
Entradas: PT.6.Validado.
Modelagem do domnio, PT.7.Validado.
Candidatos a
sub-domnio e PT.8. Histrico de decises sobre incluso/excluso de sub-domnios

Sadas: PT.9. Mdulos a serem refinados
Descrio:
o projeto arquitetural desta abordagem se baseia no mtodo ADD
(Attribute-Driven Design ou projeto orientado a atributos (BASS; CLEMENTS; KAZMAN, 2003)).

O ADD promove o refinamento sucessivo de mdulos, iniciando-se com o domnio todo, e
realizando divises at serem obtidos os mdulos que iro formar a arquitetural final.
Assim, esta primeira atividade consiste na escolha dos mdulos a serem refinados. O
refinamento pode ocorrer em duas dimenses:
Dos pontos comuns para os variveis:
neste refinamento, inicia-se o projeto
considerando-se apenas os pontos comuns. Em seguida, a cada iterao, acrescenta-se

um ponto de variao no projeto; e
De mdulos para sub-mdulos: neste refinamento, inicia-se dividindo-se o domnio
todo em mdulos, e em seguida os mdulos so subdivididos sucessivamente.
Estas dimenses normalmente so ortogonais, ou seja, um mdulo pode incluir diversos

pontos variveis. Da mesma forma, um ponto varivel pode incluir diversos mdulos. Portanto,
recomenda-se realizar apenas um desses tipos de refinamento a cada iterao.
No existe uma ordem especfica, ou seja, pode-se iniciar com um refinamento de mdulo
para sub-mdulo, em seguida acrescentar um ponto varivel, depois novamente refinar um
mdulo. Porm, sugere-se iniciar com uma primeira diviso do domnio em mdulos, o que
permite uma viso geral da arquitetura desejada.
Aps uma primeira diviso, o projetista do domnio avalia a arquitetura existente at o
momento, identifica se existem mdulos que ainda precisam ser refinados, e os lista. Para cada
um destes, executa as atividades seguintes, refinando o mdulo novamente.
O refinamento segue at o projetista decidir que no necessrio acrescentar mais detalhes.
A arquitetura deve capturar apenas as informaes mais importantes do projeto, e portanto
no so necessrios muitos detalhes. Normalmente, 3 nveis de diviso so suficientes (BASS;
CLEMENTS; KAZMAN,
2003).
101
importante lembrar que nesta abordagem j existe uma primeira diviso do domnio em
sub-domnios, feita na atividade de anlise. Porm, esta uma diviso conceitual que pode no
coincidir com a diviso em mdulos que realizada nesta fase de projeto (BUSCHMANN et al.,
1996). Enquanto a primeira tem como objetivo identificar partes do domnio onde a automao
possvel, separando conjuntos de features relacionadas, aqui a diviso tem como objetivo
implementar padres arquiteturais que iro atender a requisitos para o domnio - as diretrizes
arquiteturais.
Atividade PD.2. Seleo das diretrizes arquiteturais

Papis: projetista do domnio, especialista do domnio, demais stakeholders.
Entradas: PT.9. Mdulos a serem refinados
Sadas: PT.10. Diretrizes arquiteturais
Descrio: as diretrizes arquiteturais so uma combinao de requisitos funcionais e de
qualidade que do forma arquitetura de um domnio ou mdulo em particular (BASS;
CLEMENTS; KAZMAN,
2003). As diretrizes so normalmente representadas atravs de cenrios
que testam a capacidade da arquitetura em satisfazer um ou mais atributos de qualidade.

Para identificar as diretrizes, os objetivos de negcio mais importantes so identificados
e transformados em cenrios ou casos de uso. Desta lista, aqueles com maior impacto na
arquitetura so escolhidos. Estas so as diretrizes arquiteturais (BASS; CLEMENTS; KAZMAN,
2003). Para a identificao destas diretrizes, tcnicas como a rvore de utilidade (CLEMENTS;
KAZMAN; KLEIN,
2004), ou sesses de brainstorming podem ser utilizadas.
Nesta abordagem, ao menos trs tipos de diretrizes devem estar presentes com maior
prioridade:
Variabilidade em termos de features: como discutido anteriormente, a maior parte
da variabilidade pode ser descrita atravs de features. Para o projeto arquitetural, a
variabilidade descrita tambm na forma de cenrios, visando facilitar seu entendimento
e futura avaliao;
Variabilidade em forma de DSLs: casos mais complexos de variabilidade exigem
um mecanismo mais expressivo para express-la apropriadamente.
Para o projeto
arquitetural, so utilizadas DSLs para descrever esta variabilidade mais complexa; e

Integrao entre sub-domnios: o projeto arquitetural precisa considerar os pontos onde
diferentes sub-domnios iro interagir. Isto envolve, por exemplo, a integrao entre
102
cdigo gerado e no-gerado. Estes pontos de interao devem ser explcitos para que
a arquitetura possa dar suporte adequado gerao de cdigo.
Sub-atividade PD.2.1. Seleo das diretrizes arquiteturais de variabilidade baseada em

features
Nesta atividade, o objetivo descrever cenrios que ilustrem as variabilidades que ocorrem
em termos da presena ou ausncia de features. Tais cenrios j foram identificados, durante a
anlise, na atividade de mapeamento das features em forma de cenrios (Sub-atividade AD.2.1).
Portanto, aqui necessrio somente selecionar, dentre os cenrios descritos na anlise,
aqueles que descrevem a variabilidade que diz respeito ao mdulo sendo refinado na iterao
atual. Caso seja necessrio, pode-se enriquecer estes cenrios com mais informaes, tais como
atributos de qualidade a serem atendidos pela arquitetura.
Sub-atividade PD.2.2. Seleo das diretrizes arquiteturais de variabilidade baseada em

DSLs
Como discutido no incio deste captulo, variabilidades mais complexas requerem uma
descrio mais rica. Esta abordagem prope o uso de linguagens especficas de domnio para
formalizar o espao de variao em reas particulares do domnio (sub-domnios), definindo
os conceitos e introduzindo restries e regras relacionadas variabilidade neste sub-domnio.
DSLs tambm so utilizadas para guiar o desenvolvimento de transformaes de software e
gerao de cdigo, nas atividades de implementao.
Esta atividade cuida apenas da seleo de DSLs que descrevem o sub-domnio relacionado
ao mdulo sendo refinado. Caso seja necessrio desenvolver uma nova DSL, esta deve ser
realizada posteriormente, em uma atividade dedicada para tal tarefa, descrita mais adiante.
Sub-atividade PD.2.3. Seleo das diretrizes arquiteturais de integrao entre

sub-domnios
importante ressaltar que sub-domnios quase nunca esto isolados entre si. Por exemplo,
com relao ao domnio web de autoria de contedo mostrado na Figura 10, o sub-domnio de
navegao pode conter referncias para o sub-domnio de autoria (por exemplo, um formulrio
que aponta para um tipo especfico de documento).
Assim, a arquitetura precisa estar preparada no s para a existncia de mltiplos
sub-domnios e possivelmente mltiplas DSLs (WARMER; KLEPPE, 2006; HESSELLUND;
103
CZARNECKI; WASOWSKI,
2007), mas tambm para a interao entre eles. Pode ser necessrio,
por exemplo, desenvolver um nico metamodelo para os mltiplos sub-domnios, e ento

desenvolver diferentes sintaxes concretas, de forma que estes sub-domnios estejam integrados
mas ainda assim possuir diferentes vises.
Nesta atividade, estas interdependncias entre sub-domnios so explicitadas, pois podem
ter impacto nas decises de projeto. Para isso, cada elemento em cada sub-domnio deve ser
inspecionado, e cada elemento que depende de um elemento em um sub-domnio diferente deve
ser documentado.
As restries de incluso e excluso mtua entre as features indicam algumas destas
dependncias, porm outras podem se tornar aparentes somente aps a implementao estar
avanada. Por este motivo, esta tese defende a idia de que a identificao dos sub-domnios
deve acontecer de forma evolutiva e investigativa, desde a anlise (Atividade AD.5). A cada
iterao, os sub-domnios devem evoluir, com o avano da implementao, aumentando a
confiana em sua validade e identificando novas relaes entre os sub-domnios. No Captulo
8 apresentado um modelo de ciclo de vida que discute este aspecto interativo e iterativo da
abordagem proposta.
Alm das relaes entre os sub-domnios, o relacionamento entre cada sub-domnio e as
outras partes do domnio tambm precisam ser documentadas, de forma que possvel projetar
uma arquitetura que acomode tanto artefatos gerados como no-gerados.
Atividade PD.3. Escolha de tticas e padres arquiteturais

Papis: projetista do domnio, especialista do domnio
Entradas: PT.10. Diretrizes arquiteturais
Sadas: PT.11. Tticas e padres arquiteturais
Descrio: o objetivo desta atividade selecionar ou definir tticas e padres para
satisfazer s diretrizes arquiteturais. O uso de padres considerado uma das mais tcnicas
mais teis durante a fase de projeto de software. Atravs desta tcnica, pode-se reaproveitar
solues recorrentes e j comprovadamente bem sucedidas, poupando-se esforo e riscos nesta
atividade. Em termos de projeto arquitetural, so conhecidos como padres, estilos (BASS;
CLEMENTS; KAZMAN,
2003) ou abordagens (CLEMENTS; KAZMAN; KLEIN, 2004) arquiteturais.
A diferena entre um padro arquitetural e um padro de projeto est na abrangncia e impacto

da soluo. Enquanto padres de projeto normalmente so utilizados para resolver problemas
mais detalhados, padres arquiteturais descrevem solues mais abrangentes que envolvem todo
104
o escopo de um domnio ou sistema. Normalmente, inicia-se com padres arquiteturais que

definem a macro-estrutura do domnio, at chegar em padres menores que resolvem problemas
mais especficos de partes do domnio.
Alm disso, um padro arquitetural implementa uma ttica, que por sua vez tem o objetivo
de alcanar um ou mais atributos de qualidade (BASS; CLEMENTS; KAZMAN, 2003). Uma ttica
descreve uma estratgia a ser utilizada para se alcanar um determinado atributo de qualidade.
Assim, para cada diretriz arquitetural, seleciona-se uma ou mais tticas, e em seguida so
selecionados os padres para implementar estas tticas. Uma lista de tticas bem conhecidas
e utilizadas em diversos cenrios apresentada em (BASS; CLEMENTS; KAZMAN, 2003), porm
esta no inclui tticas para lidar com variabilidade em um domnio, nem com a integrao entre
sub-domnios automatizados, como o caso desta abordagem.
Para implementar as tticas, existe uma grande quantidade de fontes de padres e estilos
arquiteturais. Vale destacar a srie de 5 volumes conhecida como POSA (Pattern-Oriented
Software Architecture) (BUSCHMANN et al., 1996; SCHMIDT et al., 2000; KIRCHER; JAIN, 2003;
BUSCHMANN; HENNEY; SCHMIDT, 2007a, 2007b), que apresenta diversos padres voltados para
diferentes tipos de problemas arquiteturais. O catlogo clssico de padres de projeto do GoF

tambm pode ser til nesta atividade (GAMMA et al., 1995), alm de outras fontes citadas por
Bass, Clements e Kazman (2003).
Com relao ao problema da variabilidade, existem alguns trabalhos que propem o uso
de alguns padres de projeto com este objetivo (ALMEIDA et al., 2007b; KEEPENCE; MANNION,
1999; LEE; KANG, 2004). Existem tambm diversos trabalhos que apresentam formas de se
implementar variabilidade em uma linha de produtos, que podem ser adaptadas para o nvel
de projeto arquitetural (ANASTASOPOULOS; GACEK, 2001; MUTHIG; PATZKE, 2003; RIBEIRO;
MATOS; BORBA,
2008; SVANHBERG; GURP; BOSCH, 2002). Porm, estes no cobrem o aspecto
de integrao entre diferentes sub-domnios. Para esta abordagem, foram selecionados alguns
padres que auxiliam na implementao das tticas especficas para variabilidade e integrao
entre sub-domnios, apresentados mais adiante nesta seo.
A escolha das tticas e padres a serem utilizados guiada por dois fatores: o requisito
em si, explicitado pela diretriz arquitetural, e os efeitos colaterais que o emprego de uma ttica
ou padro provoca nas demais diretrizes (BASS; CLEMENTS; KAZMAN, 2003). Caso no seja
possvel encontrar alguma ttica e/ou ou padro que sirva para um cenrio especfico, pode-se
modificar ou adaptar tticas e padres existentes, ou mesmo criar novos especialmente para
este domnio. Estes passam ento a fazer parte do catlogo da organizao, e podem ser
reaproveitados em projetos futuros.
105
Da mesma forma que as diretrizes arquiteturais, nesta abordagem so necessrias tticas

e padres para pelo menos trs aspectos principais: variabilidade baseada em features,
variabilidade baseada em DSLs e integrao entre sub-domnios.
Alguns dos padres
identificados nesta tese so baseados nos trabalhos de Vlter (2003), Vlter e Bettin (2004),
que so muito teis para projetos de MDD, mas no so especficos para o projeto arquitetural
ou para a engenharia de domnio, e portanto so acrescentadas discusses sobre como alguns
desses padres podem ser incorporados ao contexto de reutilizao.
Sub-atividade PD.3.1. Padres arquiteturais para variabilidade baseada em features

Existe uma srie de padres que podem ser utilizados para ajudar a tornar uma arquitetura
de software especfica de domnio preparada para os diferentes tipos de variabilidade baseada
em features.
Em particular, os padres do GoF (GAMMA et al., 1995) podem facilitar
a representao da variabilidade no projeto arquitetural, resolvendo alguns dos problemas

relacionados implementao das features (ALMEIDA et al., 2007b).
No caso do desenvolvimento orientado a modelos, necessrio considerar tambm
como os geradores de cdigo se integram com cada padro, j que partes do software so
automaticamente geradas, e precisam ser integradas ao restante do software. Neste sentido,
o uso de padres facilita o trabalho dos geradores, pois menos cdigo precisa ser gerado para
que as variantes sejam includas.
O cenrio o seguinte: um modelo de features descreve os pontos comuns e variveis.
Um gerador de cdigo usa como entrada uma seleo de features/subfeatures que faz parte da
aplicao gerada, e precisa produzir o cdigo correspondente. Para cada tipo de feature, um ou
mais padres do GoF (GAMMA et al., 1995) utilizado.
Features alternativas: estas so as features onde somente uma alternativa pode estar
presente em uma aplicao.
Quando uma feature pode ser mapeada diretamente em uma nica classe, o padro Abstract
Factory indicado. Neste padro, um elemento que realiza o papel de fbrica abstrata e um
elemento que realiza o papel de produto abstrato representam um ponto de variao, uma
feature. Fbricas e produtos concretos representam variantes alternativas. O gerador somente
precisa gerar o cdigo de instanciao da fbrica concreta correspondente, e o restante do cdigo
permanece independente.
A Figura 11 ilustra o uso deste padro com um gerador de cdigo para implementar features
alternativas. Para cada ponto de variao, cria-se uma fbrica abstrata e um produto abstrato
106
Figura 11: Uso do padro Abstract Factory para features alternativas
(AbstractFactoryFeatureA e FeatureA). Para cada variante alternativa, so criadas as fbricas

e produtos concretos. O gerador, ao criar um produto, s precisa declarar a fbrica abstrata
correspondente ao ponto de variao selecionado, neste caso a featureA, gerando as linhas 2 e
6, e instanciar a fbrica correspondente alternativa selecionada (linha 3). O resto do cdigo
pode utilizar a feature normalmente.
O padro Prototype pode ser utilizado com o mesmo propsito, nos casos onde se deseja
evitar a criao de subclasses para os objetos construtores. Neste padro, cada alternativa
implementada como uma classe diferente de um prottipo comum. O gerador de cdigo
responsvel por gerar cdigo que instancia somente a alternativa selecionada.
A Figura 12 ilustra o uso do padro Prototype com um gerador de cdigo para implementar
features alternativas. Para cada ponto de variao, neste caso a featureA, cria-se um prottipo,
que implementa uma interface (Cloneable) com um mtodo para criar uma cpia de si mesmo
(clone()). Cada variante alternativa (Sub-features A1, A2 e A3) transformada em uma instncia
concreta do prottipo, mediante a implementao do mtodo clone(), responsvel por criar uma
instncia da variante.
O gerador de cdigo, ao produzir o cdigo do produto, s precisa criar as chamadas
correspondentes criao do ponto de variao e da alternativa selecionada. No exemplo da
Figura 12, mediante a seleo do ponto de variao featureA, o gerador gera as linhas 2-9 e
13. A linha 12 contm o cdigo que instancia a alternativa selecionada, no caso a variante
107
Figura 12: Uso do padro Prototype para features alternativas

Sub-feature A1.
Uma soluo mais simples a utilizao do Template method com o objetivo de criar a
instncia correta. Este padro pode ser utilizado de forma similar ao Abstract factory, com a
diferena de que apenas um mtodo responsvel pela criao de um objeto, de acordo com
um ou mais parmetros passados a ele. Ou seja, a seleo da alternativa acontece via parmetro,
e no herana, como no caso do Abstract factory. Para implementar features alternativas,
basta criar um mtodo que aceita como parmetro a alternativa a ser criada, e o mtodo cria
uma instncia correspondente, atravs, por exemplo, de um bloco switch ou um conjunto de
comandos if que faz a seleo. A Figura 13 ilustra o uso deste padro. O gerador apenas
precisa gerar a chamada passando o parmetro correspondente alternativa selecionada (linha
16).
Caso uma feature precise ser implementada por diferentes classes, sugere-se o uso do
padro Facade em conjunto com um dos trs acima: Abstract Factory, Prototype ou Template
method. O Facade permite a reunio de diversas classes em uma nica fachada. Neste caso,
os mtodos construtores (o construtor da classe, o mtodo clone() ou o mtodo template, nos
padres citados), precisam ser estendidos para instanciar todas as classes que implementam
108
Figura 13: Uso do padro Template method para features alternativas

cada feature, com uma classe facade servindo para reuni-las em um nico ponto.
Quando as features alternativas correspondem a comportamentos alternativos, que devem
ser mapeados em um nico mtodo ao invs de toda uma classe, os padres Strategy ou Template
method podem ser utilizados. O padro Strategy consiste na definio de uma interface,
com um nico mtodo, que corresponde ao ponto de variao. Para cada alternativa deve-se
providenciar uma implementao desta interface, onde o mtodo contm o comportamento
referente alternativa selecionada. O Template method similar, mas normalmente no exige
uma interface dedicada a um nico mtodo. Em ambos os casos, o gerador produz as chamadas
dos mtodos correspondentes s alternativas selecionadas.
Or features: estas so similares s features alternativas, porm mais de uma feature pode
estar presente em uma aplicao.
O padro Chain of Responsibility pode ser utilizado quando as diferentes features
introduzem funcionalidades complementares, que so executadas uma aps a outra. Neste
padro, cria-se uma classe abstrata para o ponto de variao, com um mtodo principal e um
mtodo para adicionar comportamentos adicionais. Dentro do mtodo principal, adiciona-se
uma chamada para um comportamento abstrato, a ser implementado por cada instncia concreta
que corresponde s variantes.
A Figura 14 ilustra o uso do padro Chain of Responsibility na implementao de or
109
Figura 14: Uso do padro Chain of Responsibility para or features
features. Para cada ponto de variao, no caso featureA, cria-se uma classe abstrata, contendo
um mtodo principal (metodo()), a ser chamado no produto. Tambm criado um mtodo
(setNext()) que permite encadear outras instncias a esta. Para cada variante (featureA
sozinha e sub-features A1, A2 e A3), cria-se uma subclasse que implementa o comportamento
especfico da variante. O gerador, para combinar as features selecionadas, cria uma instncia
da feature principal (linha 3), cria instncias das sub-features selecionadas (linhas 4 e 5), e faz
o encadeamento (linhas 6 e 7). Dessa forma, ao se chamar o mtodo principal (linha 9), os
comportamentos especficos de cada sub-feature so chamados.
O Chain of Responsibility permite a combinao de comportamentos seqenciais, ou seja,
um executado aps o outro. Em interaes mais complexas, onde a ordem de chamada
dos comportamentos especficos no seqencial, exigindo um cdigo especfico para isso,
o padro Decorator pode ser utilizado. Neste padro, cria-se um decorator para cada variante.
Em cada decorator implementa-se uma verso dos mtodos principais, considerando-se como
esta variante modifica o comportamento normal. O gerador apenas precisa fazer a concatenao
dos decorators, de forma a reproduzir as variantes selecionadas.
A Figura 15 ilustra o uso do padro Decorator para implementar or features.
Para
cada ponto de variao, no caso featureA, cria-se uma classe abstrata que contm mtodos
110
Figura 15: Uso do padro Decorator para or features
especficos desta feature (metodo1() e metodo2()). Cria-se tambm um decorator abstrato, com
um construtor responsvel por incluir o comportamento deste decorator a outro. Para cada
variante (no caso, featureA sozinha, e as sub-features A1, A2 e A3), cria-se uma instncia
da classe abstrata principal (FeatureASozinha), e dos decorators (SubFeatureA1Decorator,
SubFeatureA2Decorator e SubFeatureA3Decorator).
O gerador apenas precisa fazer a chamada que cria instncias dos decorators que
correspondem s variantes selecionadas (linhas 3,4 e 5).
Da mesma forma que com as features alternativas, caso uma or feature precise ser
implementada em vrias classes, pode-se combinar o padro Facade para reunir mais de uma
classe em um nico ponto.
Features opcionais: para features opcionais, o mesmo conjunto de padres utilizados para
as or features podem ser utilizados, com a diferena de que neste caso no necessrio garantir
que ao menos uma feature esteja presente na aplicao.
Para a implementao de variabilidade baseada em features, podem tambm ser utilizados
dois padres baseados em prticas bem conhecidas para a escrita de geradores de cdigo
111
(CZARNECKI et al., 2002).

O primeiro padro conhecido como a abordagem visitante (CZARNECKI; HELSEN, 2006;
JOUAULT; BZIVIN; KURTEV,
2006; FEILKAS, 2006). Neste padro, o modelo de entrada
percorrido e cada elemento visitado. Para cada elemento, um template correspondente

chamado, de acordo com o tipo do elemento. No cenrio de engenharia de domnio, este padro
particularmente til para diferentes tipos de features mandatrias e opcionais. A Figura 16
ilustra este padro.
Figura 16: Padro visitante sendo aplicado implementao de variabilidade baseada em

features
Neste exemplo, um visitante percorre o modelo de features e, para cada feature selecionada,
chama o template correspondente, que gera cdigo para ela. Normalmente, cada template
produz uma nica classe que implementa a feature, que se encaixa na arquitetura atravs de
padres de projeto como os descritos anteriormente nesta seo.
O padro visitante uma boa opo quando possvel encapsular a funcionalidade de
uma feature em uma nica classe. Caso no seja possvel, a abordagem template (CZARNECKI;
HELSEN,
2006) pode ser utilizada. Consiste em um nico template que o ponto de entrada,
responsvel por consultar os modelos e chamar outros templates. Esta abordagem difere
da abordagem visitante no sentido em que a ordem e lgica por trs das chamadas dos
templates explicitamente programada pelo desenvolvedor, no dependendo de alguma poltica
pr-estabelecida. Alm disso, um template no necessariamente produz uma unidade distinta
como uma classe. Um template pode introduzir apenas um nico mtodo, um pedao de texto,
que pode ser inserido em outros artefatos. Tambm pode produzir hierarquias completas de
classes.
Esta abordagem pode ser utilizada em diferentes tipos de variabilidade, por ser mais
flexvel, sendo particularmente til para implementar or features, como ilustra a Figura 17.
O template principal responsvel por analisar os modelos de features e decidir quais
112
Figura 17: Abordagem template sendo aplicada gerao de cdigo baseada em features
templates sero chamados, quando sero chamados, e em qual ordem. No exemplo da Figura
17, a featureA selecionada, e implementada por uma nica classe, enquanto as sub-features
A1 e A3 (que esto selecionadas), so implementadas como os mtodos A1() e A3().
Sub-atividade PD.3.2. Padres arquiteturais para variabilidade baseada em DSLs

Este tipo de variabilidade expresso em termos de uma DSL. O desenvolvedor especifica
um programa/modelo que segue a sintaxe de uma DSL, e um gerador produz cdigo-fonte
automaticamente. A variabilidade em uma DSL pode ser virtualmente tudo que pode ser
definido em um metamodelo: atributos verdadeiro/falso ou strings, listas tipadas e colees,
enumeraes e outros conceitos da orientao a objetos podem ser utilizados para descrever o
espao de variabilidade. Para consultar estas estruturas em um gerador, construes comuns
maioria das linguagem de programao, como condies e laos, podem ser utilizadas.
Devido grande variedade destes tipos de variabilidade, aqui no se prope nenhum tipo
de padro associado a um tipo particular de variao (como na seo anterior). Ao invs disso,
os padres nesta categoria so focados em como as ferramentas baseadas em DSL e geradores
de cdigo podem ser integrados arquitetura e aos geradores de cdigo baseados em features.
Apesar destes padres no aparecerem na arquitetura da aplicao final, eles podem ter impacto
no sucesso do domnio. Afinal, no MDD estes artefatos tambm fazem parte da arquitetura do
domnio (VLTER; GROHER, 2007), e devem ser considerados durante o seu ciclo de vida.
Um primeiro padro proposto denomina-se camada fina de dados, que facilita a
integrao entre o gerador e a ferramenta de modelagem DSL. Normalmente, geradores
de cdigo consultam informaes diretamente de uma ferramenta de DSL, que pode
ser criada manualmente ou atravs de algum framework de construo de linguagens,
como GME (Generic Modeling Environment), GMF (Graphical Modeling Framework) ou
openArchitectureWare (Seo 2.2.2). Este padro defende o uso de uma camada separada de
113
dados, construda em uma tecnologia independente da ferramenta DSL, e que contm apenas as
informaes essenciais para o gerador, e nada mais.
Desta maneira, a informao necessria para o funcionamento do gerador explicitada,
facilitando a evoluo independente do gerador e da ferramenta DSL. Tambm permite o
desenvolvimento dos trabalhos de ambas as equipes: a que est trabalhando no gerador e
outra equipe trabalhando na linguagem e suporte ferramental. Finalmente, este padro libera o
gerador de uma tecnologia de modelagem em particular, alm de restringir as necessidades de
aprendizado das particularidades das ferramentas de modelagem a uma nica equipe. A equipe
trabalhando com gerao de cdigo pode focar em suas prprias tarefas. A Figura 18 ilustra
este padro.
Figura 18: Padro camada fina de dados

Um segundo padro que pode ser utilizado, que deriva da camada fina de dados,
chamado camada de dados das features, e consiste numa especializao do padro anterior.
Normalmente, o modelo de features o ponto central de informaes para os geradores, mesmo
aqueles exclusivamente dedicados variabilidade baseada em DSLs. Neste padro, que
uma instncia do padro camada fina de dados, prope-se o uso de uma camada de dados
que armazena todas as informaes relacionadas s features. Esta camada de dados deve
ser projetada para ser acessvel a todos os geradores, permitindo que os mesmos consultem
informaes das features enquanto geram cdigo.
Se existir uma ferramenta dedicada
atividade de modelagem de features, esta camada pode ser utilizada para fazer com que os
geradores no dependam desta ferramenta em particular.
Sub-atividade PD.3.3. Padres de integrao entre sub-domnios

Estes padres buscam promover uma boa integrao entre cdigo gerado e no-gerado,
particularmente nas reas que envolvem os limites de um sub-domnio. Os padres descritos
nesta seo dividem-se em quatro categorias, dependendo da dependncia entre cdigo gerado
e no-gerado, conforme descrito a seguir.
114
Cdigo gerado depende de cdigo no-gerado: este o tipo mais simples de interao,
e consiste em fazer o gerador produzir cdigo que usa cdigo existente, no-gerado, como um
framework ou biblioteca.
O padro Facade (GAMMA et al., 1995) pode ser utilizado para simplificar a interao
entre cdigo gerado e no-gerado. Ao invs de gerar cdigo que usa mltiplas classes e
mltiplos mtodos, uma nica classe Facade agrupa todas as classes e mtodos em um nico
ponto. Isto no somente torna as dependncias mais explcitas, mas tambm promove alguma
proteo contra mudanas no cdigo no-gerado. Dependendo do grau das mudanas, pode
no ser necessrio modificar o gerador, o que uma tarefa mais complexa e propensa a erros.
Adaptaes menores podem ser feitas diretamente na classe Facade.
Para proteger o gerador de mudanas maiores no cdigo gerado, e algumas vezes simplificar
o gerador, o padro Adapter (GAMMA et al., 1995) pode ser utilizado, para coletar, filtrar e/ou
preparar a informao necessria para o cdigo gerado. Mudanas mais simples como no
formato de dados ou na assinatura dos mtodos no se propagam para o gerador.
Cdigo no-gerado depende de cdigo gerado: Isto acontece quando cdigo no-gerado
espera que um comportamento ou estrutura seja gerado.
completamente possvel e algumas vezes necessrio esse tipo de padro de integrao,
mas fazer com que um cdigo no-gerado dependa diretamente de cdigo gerado pode levar
a problemas. O programa pode no compilar antes da gerao completa de cdigo. Objetos
de exemplo podem ser manualmente criados temporariamente, mas em geral isto adiciona um
nvel a mais de dificuldade para testes/manuteno. Alm disso, erros no previstos so mais
provveis de acontecer dependendo de como o cdigo gerado varia, pois difcil prever todas
as possibilidades. Estes padres visam reduzir estes problemas.
Na maioria dos casos, padres como o Template method ou Factory (GAMMA et al., 1995)
podem ser utilizados, de forma que o cdigo no-gerado no precise saber detalhes sobre
como as classes e mtodos que o mesmo utiliza so implementados, se so gerados ou
construdos manualmente. Porm, em algum momento, uma implementao concreta precisa
ser providenciada, pois de outra forma o cdigo no ir compilar e executar completamente.
Nesses casos, possvel remover a dependncia entre cdigo no-gerado e gerado por meio
dos padres de Injeo de dependncia ou Localizador de servio (FOWLER, 2004a). Estes
padres removem as dependncias do cdigo (neste caso, do cdigo no-gerado) e as colocam
em agentes externos, responsveis pela injeo das dependncias atravs de configurao
programtica ou textual (normalmente XML). As dependncias devem ainda ser definidas
em algum lugar, mas uma vez que isto s ocorre em uma entidade separada, estas so
115
explcitas, sendo tambm mais facilmente definidas, o que acaba melhorando o entendimento
do cdigo final. O cdigo original pode ser compilado independentemente, facilitando testes
e manuteno. Alm disso, o cdigo de configurao poderia ser gerado, de forma que at o
processo de injeo seja automatizado. Por exemplo, possvel gerar arquivos de configurao
para frameworks de injeo de dependncia como o Spring1 .
Estes padres assumem que h um elemento fixo entre os dois lados da dependncia:
uma interface, uma classe abstrata ou uma assinatura de mtodo. Porm, h casos onde at
mesmo as assinaturas dos mtodos so geradas, como por exemplo um gerador que produz
objetos de acesso a dados (Data Access objects - DAO), com mtodos para realizar operaes
bsicas de insero, remoo e consulta. Cada DAO possui seus prprios conjuntos de mtodos
com diferentes assinaturas dependendo dos nomes e atributos das entidades. Nestes casos,
tcnicas de reflexo podem ser a nica soluo para remover dependncias em tempo de
compilao. Atravs da reflexo, possvel transformar todas as chamadas de mtodos de
cdigo no-gerado para cdigo gerado em chamadas reflexivas, de forma que o mtodo sendo
chamado desconhecido pelo compilador.
Cdigo gerado depende de cdigo gerado: isto normalmente acontece quando h dois
sub-domnios que dependem um do outro.
Um problema que surge do relacionamento entre mltiplos sub-domnios como garantir a
integridade deste relacionamento. Uma possibilidade utilizar os nomes dos elementos como
referncias, isto , o nome de uma referncia em um modelo deve ser idntico ao nome do
elemento referenciado, em outro modelo. Apesar de no ser ideal, esta abordagem simplifica
o processo de se implementar referncias entre modelos. efetivamente utilizada devido
sua praticidade, sendo encontrada em exemplos como Apache OFBiz e algumas Microsoft DSL
Software Factories (HESSELLUND; CZARNECKI; WASOWSKI, 2007).
Outra opo so as pontes entre modelos, que consistem na criao de duplicatas
de elementos, no metamodelo que contm a referncia, que correspondem a elementos
do metamodelo referenciado.
No exemplo do domnio web de autoria de contedo,
isto corresponde criao, no metamodelo de navegao, de um elemento chamado

ReferenciaParaTipoDeDocumento, que pode ser utilizado para estabelecer referncias para o
elemento TipoDeDocumento do metamodelo de autoria. Um verificador separado pode ento
ajudar a garantir que estas referncias sejam vlidas (WARMER; KLEPPE, 2006).
Cdigo gerado precisa ser estendido: um exemplo tpico a gerao de esqueletos de
classes que precisam ser manualmente implementados aps a gerao.
1 http://www.springsource.org
116
Seja qual for a tcnica sendo utilizada, uma recomendao importante a de que a
modificao manual do cdigo gerado no deveria ser necessria (TOLVANEN, 2004; VLTER;
BETTIN,
2004). Mesmo com tcnicas de merging (mesclagem), como os blocos de usurio
do JET (Java Emitter Templates (POPMA, 2004), esta no uma boa prtica porque depende da
existncia de cdigo que marca os locais onde o cdigo manual comea e onde termina. Se este
cdigo for removido por alguma razo, o cdigo manual pode ser perdido aps a regenerao.
Assim, tcnicas de merging somente devem ser utilizadas quando estritamente necessrias,
e de preferncia com mecanismos que protegem o cdigo manual de modificaes acidentais
(WARMER; KLEPPE, 2006).
As melhores tticas para evitar esta situao incluem a gerao de classes abstratas ou
interfaces, e a utilizao de subclasses para implementar as partes faltantes. Tcnicas como
as receitas (recipes) do openArchitectureWare, que consistem na exibio de avisos sobre os
passos a serem seguidos para completar o cdigo, podem ajudar a garantir uma implementao
manual correta.
Um padro til nestas situaes chamado merging de geradores. A ttica por trs deste
padro criar um modelo separado para a especificao das partes faltantes, e ento combinar
estes modelos utilizando um gerador especfico. A Figura 19 ilustra a idia.
Figura 19: Merging de geradores envolvendo modelos estruturais e comportamentais
Neste exemplo, dois tipos de geradores - para modelos estruturais e de comportamento

- so combinados para produzir cdigo que no precisa ser manualmente completado. O
comportamento pode ser especificado por modelos especficos, como mquinas de estados,
ou mesmo diretamente em cdigo-fonte na linguagem de destino. Um gerador especfico
(merger) ento traduz e/ou copia estes trechos para os locais designados das estruturas
geradas.
117
Atividade PD.4. Aplicao dos padres arquiteturais e refinamento dos

mdulos
Papis: projetista do domnio, especialista do domnio

Entradas: PT.9. Mdulos a serem refinados, PT.10. Diretrizes arquiteturais e PT.11.
Tticas e padres arquiteturais
Sadas: PT.12.Inicial. Projeto do domnio
Descrio: nesta atividade, os padres so aplicados de acordo com as diretrizes
selecionadas, e guiam o refinamento do domnio em mdulos e sub-mdulos. Por analogia,
um padro como um template, onde seus elementos so papis abstratos que precisam ser
preenchidos por elementos concretos. A atividade anterior cuidou da definio deste template.
Esta atividade cuida do preenchimento do template.
Como descrito na atividade PD.1, o refinamento ocorre em duas dimenses: de ponto
comum para ponto varivel e de mdulo para sub-mdulo.
No caso de um refinamento na dimenso de incluso de ponto de variao, definem-se
quais novos elementos sero necessrios para implementar este ponto de variao. O resultado
o surgimento de novos mdulos que implementam o ponto de variao de acordo com tticas
e padres j testados e comprovados.
No caso de um refinamento da dimenso de diviso mdulo/sub-mdulo, definem-se
quais novos sub-mdulos iro realizar os papis do padro. O resultado uma decomposio
plausvel, guiada por um padro que tem por objetivo atender s necessidades arquiteturais
especficas daquele mdulo (diretrizes) (BASS; CLEMENTS; KAZMAN, 2003).
Para auxiliar a garantir que esta diviso plausvel realmente atende aos requisitos,
so criados diferentes modelos, ou vises, que detalham a interao entre os elementos
recm-criados. Pode-se, por exemplo usar a viso de decomposio modular, que ilustra os
mdulos e os principais fluxos de dados. A viso de concorrncia, que ilustra os aspectos
dinmicos da interao entre os elementos, importante caso existam atividades paralelas e
de sincronizao neste domnio. Porm, estes so apenas exemplos. Deve-se utilizar qualquer
viso que esteja envolvida no padro sendo aplicado, e que seja capaz de transmitir a informao
de forma consistente e completa.
Nesta atividade, so tambm descritas as interfaces dos mdulos recm criados. Alm
das informaes requeridas/providas para que cada mdulo seja capaz de executar sua
responsabilidade, so descritos tambm os requisitos e funes que devem ser atendidos por
118
aquele mdulo especfico, considerando-se a diviso que foi realizada.

Por exemplo, para satisfazer a um determinado cenrio de variabilidade onde uma feature
pode ou no estar presente (feature opcional), pode-se criar um mdulo que aceita como
parmetro uma varivel booleana que indica se a feature est ou no presente.
Assim,
a definio da interface deste mdulo deve conter uma descrio desta varivel, do seu
funcionamento, e dos requisitos que levaram sua criao.
Todos os requisitos e funes associados com o mdulo pai devem possuir um mdulo
correspondente que assuma a responsabilidade. Estas responsabilidades devem estar claramente
descritas e indicadas nas interfaces.
Atividade PD.5. Avaliao arquitetural

Papis: Projetista do domnio, especialista do domnio, demais stakeholders
Entradas: PT.10. Diretrizes arquiteturais e PT.12.Inicial. Projeto do domnio
Sadas: PT.12.Avaliado. Projeto do domnio
Descrio: a abordagem segue o raciocnio do mtodo PuLSE-DSSA (DEBAUD; FLEGE;
KNAUBER, 1998), no sentido em que o projeto arquitetural pode produzir mltiplas arquiteturas,
cada uma oferecendo uma alternativa para se atender s diferentes diretrizes. Uma atividade
ento responsvel por avaliar as alternativas e selecionar qual delas segue adiante no processo.
A avaliao arquitetural deve ser iniciada quando a equipe de desenvolvimento comear
a tomar decises que dependem da arquitetura, e o custo de se desfazer tais decises
maior do que o custo de se realizar a avaliao (CLEMENTS; KAZMAN; KLEIN, 2004). Nesta
abordagem, estas decises so referentes automao dos sub-domnios, utilizando ferramentas
de modelagem e transformadores, que depende desta estrutura em comum para possibilitar a
reutilizao.
Assim, esta atividade busca avaliar as alternativas de arquiteturas projetadas anteriormente.
O objetivo selecionar aquela que melhor atende aos requisitos para o domnio, com foco na
variabilidade. Este pode parecer um passo desnecessrio, uma vez que na atividade anterior o
projeto arquitetural foi realizado com base em um conjunto de diretrizes que representam os
mesmos requisitos. A diferena, no entanto, que agora sero includos os pontos de vista
dos outros interessados no domnio, para serem confrontados com os requisitos iniciais, o que
potencialmente ir revelar alguns aspectos que foram ignorados pelo projetista.
Este confronto ir no somente facilitar a seleo de uma arquitetura adequada por meio
119
de consenso entre todos os envolvidos, como tambm ir resultar em possveis sugestes de

alterao na arquitetura, visando atender os cenrios no originalmente previstos. Assim, esta
atividade tambm pode ser vista como uma atividade de melhoria e evoluo da arquitetura.
Esta atividade inspirada no SAAM (Software Architecture Analysis Method ou Mtodo
de Avaliao de Arquitetura de Software) (CLEMENTS; KAZMAN; KLEIN, 2004), com 3 passos:
1. Desenvolver cenrios:
cenrios, conforme discutido anteriormente, capturam os
principais requisitos e funcionalidades que devem ser atingidos pela arquitetura. Alguns
j foram definidos anteriormente, incluindo os casos de uso, de mudana e os principais
requisitos de qualidade.
Estes foram elaborados principalmente pelo projetista e
especialista do domnio.
Aqui, o foco tentar incluir o ponto de vista de outros
stakeholders, tais como usurios finais, gerentes, testadores, etc, e pode-se utilizar sesses
de brainstorming para capturar o mximo de informao possvel. A cada cenrio,
associa-se um peso que mede a sua importncia frente aos objetivos do domnio. Nesta
abordagem, sugere-se priorizar os cenrios que focam a variabilidade;
2. Avaliar cenrios individualmente: neste passo, cada cenrio avaliado de forma
individual, por meio de workshops mediados pelo projetista, onde se discute como
o cenrio est ou no sendo atendido pelas diferentes arquiteturas.
Pode-se
tambm desenvolver prottipos (DEBAUD; FLEGE; KNAUBER, 1998) com funcionalidades

simuladas que refletem o cenrio sendo avaliado. Para cada cenrio o projetista descreve
como a arquitetura oferece o suporte, ou descreve as mudanas necessrias; e
3. Avaliar interao entre os cenrios:
uma vez que se tenha as descries de
mudanas referentes ao suporte aos cenrios, este passo tem como objetivo destacar
quais cenrios se interagem, isto , exigem mudanas no mesmo local ou grupo
de mdulos/componentes. reas onde existe grande interao entre cenrios podem
significar pontos onde o projetista falhou em corretamente implementar a separao de
interesses, e portanto pode ser necessria maior ateno nesta rea, ou mesmo uma nova
passagem pelas atividades de projeto (CLEMENTS; KAZMAN; KLEIN, 2004).
O resultado destes passos uma lista que descreve como cada arquitetura atende aos
requisitos conforme expressos pelos stakeholders. Para cada arquitetura, pode-se calcular:
Nmero de cenrios diretamente suportados: para cada arquitetura, conta-se o nmero
de cenrios que foram avaliados como possuindo suporte direto da arquitetura, sem
necessidade de alteraes. Este nmero deve considerar o peso de cada cenrio, conforme
estipulado no passo 1 descrito anteriormente;
120
Nmero de cenrios indiretamente suportados: para cada arquitetura, conta-se o

nmero de cenrios que requerem alguma alterao para passarem a possuir o suporte
adequado pela arquitetura. Este nmero deve considerar o peso de cada cenrio, conforme
estipulado no passo 1 descrito anteriormente; e
Quantidade de mudanas: para cada arquitetura, estima-se a quantidade de mudanas
necessrias para que a mesma passe a oferecer suporte a todos os cenrios indiretos. Esta
quantidade pode ser medida em termos de nmero de mdulos/componentes modificados
ou, caso j existam mais detalhes sobre a arquitetura, at mesmo o nmero de classes
envolvidas nas mudanas.
De posse destes nmeros, possvel determinar qual das alternativas oferece o melhor
suporte global para os requisitos. A alternativa que apresentar o melhor suporte aos cenrios, e
menor quantidade de mudanas, ser selecionada para seguir adiante. Uma vez selecionada a
arquitetura, retorna-se s atividades PD.2 e PD.3, buscando novas tticas/padres arquiteturais
para implementar as mudanas sugeridas nesta avaliao. Este ciclo se repete at no serem
necessrias mais mudanas para atender aos cenrios.
Aps esta atividade, tem-se a arquitetura projetada e avaliada com base nas informaes
disponveis at o momento. No entanto, conforme j mencionado anteriormente, este um
processo iterativo, e a arquitetura pode vir a sofrer alteraes posteriormente. Na realidade, o
que acontece uma iterao em duas vias: a arquitetura influencia a implementao das DSLs
e transformadores, que por sua vez podem influenciar a arquitetura, resultando em mudanas
que melhor acomodem a presena destes novos artefatos.
6.3
Consideraes finais
Neste captulo foi apresentada a fase de projeto de domnio, com atividades para promover
a reutilizao atravs do MDD. As principais contribuies deste captulo so as atividades para
definio das diretrizes e padres arquiteturais especficos para o uso do MDD na reutilizao de
software: variabilidade baseada em features, variabilidade baseada em DSLs e integrao entre
sub-domnios. Tambm apresenta uma atividade de avaliao arquitetural visando melhorar o
resultado do projeto antes da implementao ter iniciado.
O Quadro 6 resume as atividades do projeto de domnio.
O Quadro 7 descreve os produtos de trabalho da fase da projeto de domnio.
O produto do projeto de domnio a definio da arquitetura e seus componentes. Nesta
121
PD.1.
Escolha dos mdulos a serem
refinados
PD.2. Seleo das diretrizes arquiteturais

PD.2.1. Seleo das diretrizes arquiteturais
de variabilidade baseada em features
de variabilidade baseada em DSLs
de integrao entre sub-domnios
PD.3.
Escolha de tticas e padres
arquiteturais
PD.3.1.
Padres arquiteturais para
variabilidade baseada em features
PD.3.2.
Padres arquiteturais para
variabilidade baseada em DSLs
PD.3.3.
Padres de integrao entre
sub-domnios
PD.4. Aplicao dos padres arquiteturais e
refinamento dos mdulos
PD.5. Avaliao arquitetural
Entradas
PT.8.
Histrico de decises sobre
PT.9. Mdulos a serem refinados
Sadas
PT.10. Diretrizes arquiteturais
PT.11.
Tticas
arquiteturais

PT.11. Tticas e padres arquiteturais
PT.12.Inicial. Projeto do domnio
PT.12.Inicial. Projeto do domnio
PT.12.Avaliado.
domnio
padres
Projeto
do
Quadro 6: Resumo das atividades para projeto de domnio orientado a modelos

abordagem, alm de componentes de software tradicionais, a arquitetura comporta a existncia
de artefatos como DSLs, transformaes e geradores de cdigo.
122
Produto de trabalho
PT.11.
Tticas e padres
arquiteturais
PT.12. Projeto do domnio
Descrio
Consiste na definio dos mdulos a serem
refinados em uma determinada iterao do
projeto do domnio.
Iniciando com o
domnio todo, a cada etapa um ou mais
mdulos so refinados e produzem uma nova
verso da arquitetura do domnio
Conjunto de requisitos importantes para
a definio da arquitetura. Consiste em
objetivos de negcio, casos de uso, cenrios
e linguagens que descrevem a variabilidade,
alm de uma lista de dependncias entre os
sub-domnios
Descrevem solues para problemas comuns
no projeto arquitetural orientado a modelos
Resultado da fase de projeto, este produto de
trabalho engloba a definio da arquitetura,
com os mdulos e sub-mdulos, e a
especificao das interfaces, considerando
a existncia de componentes tradicionais, e
artefatos do MDD, como DSLs, ferramentas,
transformaes e geradores de cdigo
Status
Nenhum
Nenhum
Nenhum
1. Inicial: verso inicial do documento,
gerada somente pelo projetista com o
auxlio do especialista.
Pode conter
inconsistncias ou no cumprir cenrios que
sejam importantes a algum outro stakeholder
2. Avaliado: projeto avaliado por uma
atividade especfica, que considera o ponto
de vista de diversos stakeholders
Quadro 7: Descrio dos produtos de trabalho da fase de projeto de domnio
123
Implementao de domnio orientada

a modelos
A anlise de domnio e projeto arquitetural, realizados em fase anterior, lidam com questes
como qual a melhor maneira de dividir o domnio em sub-sistemas ou como os mdulos devem
interagir entre si de forma a maximizar o desempenho na execuo de determinada tarefa
crtica. Porm, questes de mais baixo nvel ainda permanecem no-resolvidas, tais como: qual
tecnologia de comunicao deve ser utilizada em um domnio distribudo? Como ser o acesso
base de dados? Como a internacionalizao ser alcanada? Qual algoritmo de busca deve
ser utilizado? Estas so o foco da etapa de implementao do domnio, que nesta abordagem
tambm engloba o refinamento do projeto de alto nvel em um projeto detalhado.
Entre as questes a serem respondidas, destaca-se o suporte variabilidade. Como os
componentes do domnio iro dar suporte aos diferentes pontos de variao? Esta questo
comeou a ser respondida durante o projeto, e agora necessrio tomar as decises finais quanto
ao projeto detalhado. Alm disso, sendo esta uma abordagem orientada a modelos, necessrio
tambm implementar os artefatos especficos do MDD. Assim, a implementao deve tambm
produzir linguagens especficas de domnio, transformaes e geradores de cdigo.
Enquanto as fases de anlise (ARANGO, 1999; PRIETO-DAZ, 1990; KANG et al., 1990;
FRAKES; PRIETO-DAZ; FOX, 1998; BAYER; MUTHIG; WIDEN, 1999; KIM; YANG; PARK, 2003; MEI;
ZHANG; GU,
2003; MOON; YEOM, 2005; ALMEIDA et al., 2006, 2005) e projeto (ALMEIDA et al.,
2005; BOSCH, 2000; BASS; CLEMENTS; KAZMAN, 2003; TRACZ, 1995) de domnio para reuso so
amplamente discutidas pela comunidade cientfica, a rea de implementao apresenta algumas
lacunas que precisam ser preenchidas (ALMEIDA et al., 2008; ANASTASOPOULOS; GACEK, 2001).
Uma das razes que a engenharia de domnio tem suas razes na comunidade de reutilizao de
software, que favorece uma abordagem top-down (PATZKE; MUTHIG, 2002), dando mais nfase
anlise e projeto.
Outra razo o fato de que, para definir um processo genrico, deve ser possvel generalizar
detalhes especficos de plataforma e linguagem, de forma que o processo possa ser utilizado
124
independentemente da tecnologia de implementao. Ao mesmo tempo, a implementao

extremamente dependente da tecnologia (ALMEIDA et al., 2008), fazendo com que esta
generalizao seja uma luta entre foras opostas. Como resultado, observa-se uma falta de
orientao com relao s atividades para implementao de um domnio para reutilizao
(PATZKE; MUTHIG, 2002).
H inmeras tcnicas para se implementar domnios reutilizveis, como aquelas descritas
na Seo 3.2.1. Estas podem ser divididas em trs dimenses: gerenciamento de configurao,
tecnologias de componente e as caractersticas generativas das linguagens de programao
(MUTHIG et al., 2002). Cada dimenso tem sua maneira particular para lidar com a variabilidade,
que o desafio mais notvel na implementao de um domnio reutilizvel. A dimenso de
gerenciamento de configurao, por exemplo, gerencia as variantes alternativas de um mesmo
artefato em um mesmo ponto no tempo (MUTHIG; PATZKE, 2004).
A dimenso de tecnologia de componentes se baseia na idia de componentes de software.
Um componente , por definio, uma unidade de composio (MUTHIG et al., 2002), e portanto
esta dimenso lida com a variabilidade atravs da composio das variantes requeridas na
forma de componentes (KETTEMANN; MUTHIG; ANASTASOPOLOUS, 2003; MUTHIG; PATZKE,
2004). Por exemplo, em um trabalho anterior, propusemos a utilizao de OSGi para facilitar a
implementao de linhas de produtos de software (ALMEIDA et al., 2008).
A tecnologia generativa (CZARNECKI; EISENECKER, 2000), foco desta tese, pode introduzir
um controle mais poderoso sobre a variabilidade no domnio. Enquanto variaes dentro de
um componente tradicional limitam-se a estruturas fixas e interfaces previamente projetadas,
a tecnologia generativa possibilita variao em menor granularidade, mesmo dentro de
componentes. Fragmentos de cdigo variante podem ser sistematicamente arranjados para
formar a implementao de um componente (MUTHIG; PATZKE, 2004).
7.1
Objetivos da implementao do domnio
O objetivo desta fase implementar o domnio, ou seja, implementar componentes,

DSLs, transformaes e geradores de cdigo, seguindo o projeto definido na fase anterior.
Alm disso, existe uma srie de critrios que precisam ser atendidos pela implementao
(ANASTASOPOULOS; GACEK, 2001; MATOS JR, 2008; MUTHIG; PATZKE, 2003, 2004):
1. Minimizar duplicao de cdigo: deve-se provocar pouca ou nenhuma duplicao de

cdigo ao implementar a variabilidade;
125
2. Esforo de implementao: deve-se introduzir pouca ou nenhuma sobrecarga no

trabalho de implementao, de forma a oferecer poucas barreiras para sua adoo;
3. Esforo de reutilizao: a implementao deve permitir a reutilizao de forma simples
e com pouco esforo, seguindo o princpio de que se for mais trabalhoso reutilizar do que
construir, a reutilizao no ir acontecer;
4. Esforo de manuteno: diz respeito ao esforo necessrio para se realizar manuteno
nos artefatos de implementao da variabilidade;
5. Escopo: extenso com que a implementao d suporte aos diferentes tipos de
variabilidade;
6. Flexibilidade: a implementao deve dar suporte aos diferentes tempos de associao de
variabilidade (variabilidade em tempo de compilao, em tempo de execuo, etc);
7. Compatibilidade binria: a implementao deve ser compatvel com bibliotecas
pr-compiladas de software;
8. Separao de interesses: separao das variantes do cdigo comum, de forma que
mudanas em ambos os lados possam ser feitas de forma efetiva;
9. Escalabilidade:
a implementao deve ser escalvel, podendo produzir grandes
extenses de cdigo sem um impacto muito grave nas demais propriedades;

10. Desempenho: a implementao deve proporcionar desempenho do produto final de
acordo com os requisitos.
11. Diferentes tipos de cdigo-fonte: os mecanismos normalmente citados na literatura so
fortemente atrelados a uma linguagem de programao, e normalmente utilizam conceitos
de orientao a objetos. Porm, padres de projeto, herana, polimorfismo e orientao a
aspectos, entre outros exemplos, fazem pouco sentido em artefatos como pginas HTML,
scripts de criao de banco de dados, arquivos de configurao, stored procedures, entre
outros tipos de artefatos de implementao que no so baseados em uma linguagem de
programao. Obviamente, ainda possvel algum tipo de controle como, por exemplo, a
extenso de uma pgina HTML com scriptlets que implementam a incluso condicional
de partes de texto correspondentes a variantes especficas. Porm, esta opo mais
indicada para variaes em tempo de execuo, no sendo adequada para as variaes
em tempo de compilao, que o foco desta tese. Como resultado, nestes casos faz-se
necessrio o gerenciamento manual da variabilidade; e
126
12. Variabilidades complexas: conforme discutido no Captulo 6, podem existir alguns

casos de variabilidades mais complexas do que a modelagem de features capaz de
representar. Normalmente, so pontos de variao abertos, nas quais no possvel
determinar um limite para a presena ou ausncia de features, a sua implementao requer
um esforo criativo composicional manual durante o desenvolvimento das aplicaes.
Apesar de ser possvel facilitar este esforo atravs de padres como factories (GAMMA
et al.,
1995) ou outras tcnicas similares, o mesmo no pode ser completamente
automatizado utilizando somente tais mecanismos.

A fase de implementao segue a mesma estrutura do mtodo utilizado por Muthig e Patzke
(2004). Inicialmente, so desenvolvidas as comunalidades, ou as features comuns a todos os
produtos do domnio. Em seguida, as variabilidades so introduzidas, uma a uma, de forma
que ao final tem-se uma implementao que cubra todas as possibilidades. Todo o processo
baseado em desenvolvimento atravs de exemplos (WIMMER et al., 2007), o que facilita a tarefa
do desenvolvedor.
7.2
Atividades da implementao do domnio
Inicialmente, cada sub-domnio identificado durante a anlise de domnio caracterizado

em termos de sua variabilidade (Atividade ID.1). Em seguida so definidas as DSLs e o
suporte ferramental (ferramentas de modelagem e editores especficos de domnio) (Atividade
ID.2), por meio de uma abordagem top-down que utiliza os modelos de features para definir
as DSLs para cada sub-domnio. A seguir as DSLs so refinadas, e as transformaes so
construdas (Atividade ID.3), utilizando uma abordagem bottom-up e uma implementao de
referncia como ponto de partida. Esta implementao de referncia ento transformada
em um framework de domnio (Atividade ID.4), contendo classes e componentes reutilizveis
que do suporte para algumas das variabilidades.
Finalmente, os artefatos construdos
so documentados (Atividade ID.5) de forma a facilitar seu entendimento, manuteno e

reutilizao.
A seguir estas atividades so descritas de forma detalhada.
Atividade ID.1. Caracterizao da variabilidade dos sub-domnios

Papis: implementador do domnio, Especialista do domnio
Entradas:
PT.6.Validado.
Candidatos
127
a sub-domnio, PT.8.
Histrico de decises sobre incluso/excluso de sub-domnios,
PT.12.Avaliado. Projeto do domnio

Sadas: PT.13. Sub-domnios caracterizados
Descrio: um domnio divide-se em vrios sub-domnios, cada um com um potencial
de automao. Durante a anlise, esta diviso se inicia, com a identificao de candidatos a
sub-domnio (Atividade AD.3). Durante o projeto, so identificadas as diretrizes arquiteturais
que apresentam mais detalhes sobre o tipo de variabilidade de cada sub-domnio (Atividade
PD.2). Nesta atividade, cada sub-domnio efetivamente caracterizado com relao sua
variabilidade, visando dar subsdios implementao do suporte em termos de modelagem,
transformaes e geradores de cdigo para sua automao.
Conforme discutido no Captulo 6, existem diferentes tipos de variabilidade, que so
caracterizados de acordo com um espectro entre configurao de rotina e construo criativa.
Nesta atividade, cada sub-domnio analisado e inserido em um determinado local deste
espectro.
A Figura 20 ilustra esta estratgia. Para todo o domnio, uma ferramenta de features
normalmente utilizada, junto com uma ferramenta de configurao automtica. Alguns
sub-domnios podem exigir uma soluo baseada em uma DSL completa, incluindo uma
ferramenta de modelagem e geradores dedicados. Em outros, um simples wizard pode ser
suficiente.
Figura 20: Estratgia de caracterizao de sub-domnios
128
Para inserir cada sub-domnio em algum lugar do espectro de variabilidade, o papel do

especialista do domnio muito importante, mas as seguintes diretrizes podem ser teis:
D1 . Procurar por configuraes de features que no mudam entre as aplicaes: se
uma feature representa um ponto de variao, sua configurao deve mudar de alguma forma
quando as diferentes aplicaes variam com relao a este ponto. Por exemplo, se uma aplicao
web prov busca avanada, e uma segunda aplicao prov busca simples, as configuraes
das features para estas aplicaes sero diferentes. Isto indica que a variabilidade pode ser
representada como features. Porm, se duas aplicaes diferem em algum ponto, mas as
configuraes das features que descrevem aquele ponto so as mesmas, isto pode indicar que
h alguma variabilidade que no pode ser representada como features, e talvez seja necessria
uma DSL.
D2 . Explorar o espao de variabilidade: se no existirem aplicaes para analisar atravs
da diretriz D1 , pode-se tentar esboar configuraes de produto que introduzem variaes
diferentes, para determinar se o modelo de features pode representar todas as possibilidades. Se
todas as combinaes puderem ser completamente identificadas em termos de uma sub-rvore
de features, ou mesmo um caminho dentro do modelo de features (CZARNECKI, 2005), isto
significa que a variabilidade deste sub-domnio coberta pelo modelo de features. Por outro
lado, se houver algum tipo de variabilidade que no pode ser representado atravs de features,
esta pode ser mais complexa, exigindo uma DSL dedicada.
D3 . Analisar as features de tecnologia do domnio: features de tecnologia do domnio
representam as maneiras de se implementar os servios ou operaes do domnio (LEE; KANG;
LEE,
2002). Eles so alguns dos blocos de construo sobre os quais a implementao
realizada, e normalmente necessrio um processo de construo criativa para combin-los de

forma a satisfazer os requisitos da aplicao. Portanto, h uma chance de que a variabilidade
associada seja aberta. Por exemplo, as seis features de tecnologias de domnio localizadas
no lado inferior da Figura 21 no podem ser meramente selecionadas ou de-selecionadas. Ao
contrrio, elas precisam ser combinadas de forma criativa ao se configurar um produto.
D4 . Procurar por mquinas de estados: muitos sub-domnios podem ser representados
por mquinas de estados, como as telas de um jogo ou o comportamento de uma entidade. Se
for este o caso, este sub-domnio ir provavelmente requerer uma DSL (mquina de estados)
para sua variabilidade.
D5 . Procurar por estruturas hierrquicas e de conteno: relacionamentos do tipo
parte-de so comuns em um domnio. Apesar de normalmente poderem ser representados no
modelo de features, alguns relacionamentos parte-de exigem informaes extras. Por exemplo,
129
Figura 21: Modelo de features do domnio web de autoria de contedo

no sub-domnio GUI, um painel pode conter um ou mais botes. Mas onde estes botes esto
localizados? Quais so seus tamanhos, cores e eventos associados? Em tais casos, uma DSL
dedicada provavelmente necessria.
D6 . Tentar o caminho mais fcil primeiro: quanto mais prximo um sub-domnio estiver
do lado da configurao de rotina do espectro de variabilidade, mais fcil ser a implementao
de uma linguagem e transformaes para o mesmo. Sempre que houver dvida com relao
caracterizao da variabilidade no sub-domnio, o caminho mais fcil deve ser preferido, isto
, com um wizard ou configurao de features. Se estes se mostrarem insuficientes, ento uma
DSL mais complexa pode ser desenvolvida.
A sada desta atividade a caracterizao do tipo de variabilidade inerente a cada
sub-domnio. Mais importante, comea-se a identificar quais sub-domnios iro requerer uma
DSL dedicada.
Atividade ID.2. Definio das DSLs e do suporte ferramental (top-down)

Entradas: PT.6.Validado.
sub-domnio e PT.8.
Candidatos a
PT.12.Avaliado. Projeto do domnio, PT.13. Sub-domnios caracterizados
130
Sadas: PT.14.Inicial.
Linguagens especficas de domnio, PT.15.Inicial.
Suporte
ferramental para DSLs

Descrio: dependendo do tipo de variabilidade para cada sub-domnio, a DSL associada
ser mais ou menos complexa. Em casos de variabilidade mais simples, baseada em features, a
DSL pode ser composta por smbolos que representam features individuais, para indicar sua
presena ou ausncia. Czarnecki, Helsen e Eisenecker (2004a) propem um mtodo para
derivar uma gramtica livre de contexto para um modelo de features. Este mtodo pode ser
utilizado para criar uma DSL capaz de descrever todos os tipos de variabilidade caracterstica a
um modelo de features. Um gerador de parsers ou um framework de DSLs pode ser utilizado
para criar o suporte linguagem mais facilmente, suprindo a necessidade de ferramentas.
Em casos de variabilidade mais complexa, a DSL deve definir quais conceitos podem ser
utilizados, como eles se relacionam entre si, e possveis restries que possam existir. Isto pode
ser realizado exclusivamente de forma top-down. Porm, a DSL deve tambm ser capaz de
produzir modelos que sirvam de entrada para transformadores e geradores, o que inclui muitos
detalhes que so especficos plataforma e arquitetura escolhidas. muito difcil perceber
tais detalhes sem investigao mais aprofundada na implementao, e portanto uma abordagem
bottom-up utilizada para refinar esta DSL inicial. Esta atividade corresponde parte top-down
do desenvolvimento da DSL.
Conforme discutido na Seo 3.1.2, uma DSL pode ser textual (programas) ou visual
(diagramas), e normalmente composta de trs elementos: a sintaxe abstrata, a sintaxe concreta
e a semntica. Esta atividade cuida do desenvolvimento das sintaxes abstrata e concreta da DSL,
alm de ferramentas que permitam a criao de instncias (programas ou diagramas) da DSL.
Em DSLs textuais, as sintaxes abstrata e concreta so normalmente representadas atravs de
regras lxicas e gramaticais. Em DSLs visuais, a sintaxe abstrata corresponde ao metamodelo
(GUIZZARDI; PIRES; SINDEREN, 2002) e a sintaxe concreta corresponde aos aspectos visuais dos
elementos, normalmente utilizando figuras, cones, linhas, setas, entre outras representaes
grficas.
Para representar corretamente sua variabilidade, um sub-domnio pode exigir um sistema
de conceitos (sintaxes abstrata e concreta) totalmente diferente da modelagem de features,
possivelmente exigindo tambm uma ferramenta de modelagem mais complexa. Mas mesmo
no sendo suficiente para identificar conceitos de uma DSL (TOLVANEN; KELLY, 2005), um
modelo de features pode servir de ponto de partida (CZARNECKI, 2005), sendo posteriormente
complementado com informaes de outros artefatos, como a arquitetura do domnio e o
conhecimento do especialista (TOLVANEN; KELLY, 2005).
131
O desenvolvimento de DSLs considerado uma cincia parte (CZARNECKI; EISENECKER,

2000), dada sua complexidade. Alm disso, no um processo muito previsvel, pois exige
um algo grau de criatividade (VISSER, 2007). Esta abordagem busca prover alguma orientao,
atravs de cinco sub-atividades, apresentadas a seguir.
Sub-atividade ID.2.1. Identificao das features iniciais da DSL

O primeiro passo identificar as features que iro dar incio formao da sintaxe abstrata
da DSL. Como descrito na atividade ID.1, os servios e funes do domnio so normalmente
descritos em termos de features de tecnologia do domnio, e portanto estas so boas candidatas
a fazer parte de uma DSL. Considere por exemplo o domnio web de autoria de contedo
mostrado na Figura 22A. Neste domnio, dois sub-domnios podem ser identificados: navegao
(Contedo, Busca, Busca simples, Busca avanada, Contedo de usurio, Pgina, Formulrio,
Relatrio e Link) e autoria (Autoria, Tipo de documento e Relacionamento). As features de
tecnologia do domnio do sub-domnio de navegao iro fazer parte da DSL de navegao
(Pginas, Links, Formulrios e Relatrios). Similarmente, a DSL do sub-domnio de autoria ir
incluir tipos de documentos e relacionamentos.
Figura 22: Definio do metamodelo da DSL de autoria Web
Sub-atividade ID.2.2. Definio da sintaxe abstrata

No segundo passo, as features identificadas so analisadas de forma mais aprofundada,
para determinar como elas se relacionam entre si, e se conceitos adicionais so necessrios.
Estes conceitos adicionais so descritos em um metamodelo, que corresponde sintaxe abstrata
da DSL. Por exemplo, a Figura 22B mostra o metamodelo obtido para o sub-domnio de
autoria web. Elementos sombreados so derivados diretamente do modelo de features. Alm
132
das features Autoria, Tipo de documento e Relacionamento, este metamodelo contm os

relacionamentos entre elas, e novos conceitos, como Autor e Campo.
Para auxiliar na definio do metamodelo, as seguintes regras podem ser utilizadas como
guia:
Uma feature (normalmente, uma feature de tecnologia de domnio) mapeada em um
conceito da DSL. Um conceito pode ser uma metaclasse em um metamodelo, caso se
trate de uma DSL visual, ou uma regra de produo em uma gramtica, caso se trate de
uma DSL textual;
Sub-features podem ser mapeadas como propriedades do conceito que as contm. Podem
ser metaatributos em um metamodelo ou uma regra de produo ou atributo gramatical;
Sub-features podem tambm ser mapeadas como conceitos separados, com relaes
parte-de adicionais sendo utilizadas para representar a conteno. Um relacionamento
em um metamodelo corresponde a uma associao ou agregao, enquanto em linguagens
textuais pode ser representado como uma regra de produo;
Propriedades de conceitos podem precisar de tipos especiais do domnio, ao invs dos
tipos tradicionais como inteiro ou string. Por exemplo, sub-features opcionais ou do tipo
or podem ser mapeadas como enumeraes do domnio. Por outro lado, uma propriedade
pode pertencer a tipos personalizados, como Ponto e Tamanho; e
Features relacionadas podem ser conectadas por um conceito novo que descreve a relao,
as cardinalidades, os conceitos participantes e seus papis na relao. A anlise de
dependncia de features (LEE; KANG, 2004) pode ser usada para identificar tais relaes
inicialmente, mas novas podem aparecer posteriormente.
Sub-atividade ID.2.3. Definio da sintaxe concreta
O terceiro passo corresponde definio da sintaxe concreta, o que no uma tarefa
muito complexa. Em DSLs textuais externas (FOWLER, 2005), a sintaxe concreta fortemente
acoplada sintaxe abstrata, aparecendo na forma de palavras reservadas e tokens descritos na
gramtica da linguagem. Se uma DSL interna (FOWLER, 2005) utilizada, ento as construes
da linguagem que contm a DSL devem ser analisadas para determinar se as mesmas podem
representar os conceitos do domnio de forma adequada.
Em DSLs visuais, blocos decorados e linhas so a notao padro. Formas geomtricas
especficas, como retngulos e elipses, ou imagens, podem tambm ser utilizadas para
133
representar os conceitos da DSL de forma mais intuitiva e natural.

As seguintes regras podem ser utilizadas na criao desta notao:
Features que so mapeadas para os conceitos do domnios podem ser representadas como
blocos;
Relacionamentos entre features podem ser representados como linhas;
Sub-features que so mapeadas a valores booleanos podem ser representadas como
decoraes nos blocos (como uma borda diferenciada), atributos (como um cone na
frente de um elemento) ou linhas (como um losango em uma das terminaes);
Sub-features que so mapeadas a valores do tipo string podem ser representadas como
decoradores textuais, como um texto dentro de um bloco ou sobre uma linha; e
Sub-features que representam listas de itens podem ser representados como
compartimentos em blocos (como os mtodos e atributos da UML, por exemplo).
Sub-atividade ID.2.4. Definio da integrao inter-DSL
O quarto passo lida com a integrao entre diferentes DSLs, o que um problema que
surge quando se lida com mltiplos sub-domnios. A integrao inter-DSL deve ser gerenciada
de forma que o desenvolvedor possa especificar modelos em ambas as linguagens utilizando
conceitos que se relacionam. Por exemplo, no domnio web de autoria de contedo, um pgina
de formulrio (do sub-domnio de navegao) pode se referir a um tipo de documento (do
sub-domnio de autoria).
Referncias baseadas em nome ou pontes entre modelos (WARMER; KLEPPE, 2006) so
mecanismos simples que resolvem estes problemas. Referncias baseadas em nome consistem
em um simples atributo do tipo string, na DSL que contm a referncia, que aponta para
o nome de um elemento na DSL sendo referenciada. As checagens de tipo e integridade
referencial devem ser feitas manualmente. Pontes entre modelos no so muito mais poderosas,
consistindo na criao de um elemento, na DSL que contm a referncia, que uma cpia exata
de um elemento na DSL sendo referenciada. Esta tcnica propicia a checagem de tipos, mas a
checagem de integridade referencial ainda precisa ser realizada manualmente.
Caso necessrio, uma soluo mais poderosa apresentada por Hessellund, Czarnecki e
Wasowski (2007), que propem o uso de regras lgicas baseadas em Prolog para estabelecer
relaes inter-DSL. Desta forma, consultas de mais alto nvel podem ser realizadas, facilitando
a checagem da consistncia.
134
Sub-atividade ID.2.5. Construo da ferramenta de modelagem especfica de domnio

Uma vez que as sintaxes abstratas e concretas estejam definidas, uma ferramenta de
modelagem especfica para a DSL construda.
Frameworks de DSLs, como GMF ou
openArchitectureWare, entre outros, so a tecnologia de escolha para a implementao da

ferramenta, uma vez que eles exigem pouco conhecimento na construo de linguagens para
se alcanar resultados prticos rapidamente. Porm, DSLs mais complexas podem exigir uma
participao mais ativa de um especialista em linguagens.
Esta ltima sub-atividade tambm inclui a definio de validaes para capturar erros
semnticos durante a modelagem, orientando o desenvolvedor na criao de diagramas ou
programas segundo a DSL em questo (VLTER, 2008). Por exemplo, uma validao semntica
pode garantir que o comportamento de uma entidade em um jogo, modelada atravs de uma
DSL visual, sempre tenha um comportamento padro definido.
Aps este quinto passo, obtm-se um conjunto de DSLs e ferramentas que permitem que um
desenvolvedor represente diferentes tipos de variabilidade em cada sub-domnio identificado,
desde casos mais simples, baseada em features, at a variabilidade mais complexa. Mas as
DSLs ainda no esto completas, pois at agora somente uma abordagem top-down foi utilizada.
Podem existir detalhes adicionais que precisam ser includos antes que a DSL sirva de entrada
para transformaes e gerao de cdigo. aqui que uma abordagem bottom-up entra em cena.
Atividade ID.3. Desenvolvimento das transformaes e refinamento das

DSLs (bottom-up)
Entradas:
PT.6.Validado.
a sub-domnio, PT.8.
Candidatos
PT.12.Avaliado. Projeto do domnio, PT.13. Sub-domnios caracterizados, PT.14.Inicial.

Linguagens especficas de domnio, PT.15.Inicial. Suporte ferramental para DSLs
Sadas: PT.14.Refinado. Linguagens especficas de domnio, PT.15.Refinado. Suporte
ferramental para DSLs, PT.16.
Transformaes do domnio, PT.17.
Implementao de
referncia
Descrio: considerando-se somente seu poder representativo, uma DSL composta
somente pela sintaxe (abstrata e concreta). A sintaxe abstrata voltada para interpretadores
automticos, enquanto a sintaxe concreta projetada para ser usada por seres humanos, na
135
criao de instncias da DSL (diagramas ou programas).

Mas para ser til no cenrio do MDD, um terceiro elemento deve estar presente: a
semntica, que define o significado dos elementos da linguagem. No contexto do MDD, a
semntica definida em forma de aes a serem executadas por um interpretador automtico,
que traduz o modelo (programa ou diagrama) em outra linguagem bem conhecida (KLEPPE,
2007).
No contexto da engenharia de domnio, a semntica adquire ainda outra importncia,
associada variabilidade do domnio. Transformaes de software so responsveis por traduzir
a variabilidade expressa em uma DSL em cdigo concreto, de forma que o software gerado
implemente as variantes selecionadas corretamente.
At o momento, uma abordagem top-down foi seguida, utilizando modelos de alto nvel,
como o modelo de features, para produzir um conjunto inicial de DSLs. Estas DSLs so capazes
de representar diferentes tipos de variabilidade em diferentes sub-domnios identificados
durante a anlise.
Agora, uma abordagem bottom-up adotada, utilizando o projeto atravs de exemplos
(VARR, 2006; WIMMER et al., 2007; ROBBES; LANZA, 2008) para produzir transformaes e
possivelmente refinar as DSLs iniciais. Partir de uma instncia concreta de como o cdigo deve
ser mais fcil do que identificar todos os detalhes a partir de uma perspectiva de mais alto
nvel (ROBBES; LANZA, 2008).
Esta atividade realizada em quatro passos, apresentados a seguir.
Sub-atividade ID.3.1. Desenvolvimento da implementao de referncia

O primeiro passo consiste no desenvolvimento de uma implementao de referncia
(MUSZYNSKI, 2005). Esta implementao de referncia ir assumir dois papis: primeiro, ir
servir como um framework do domnio, encapsulando parte das comunalidades e oferecendo
suporte a parte das variabilidades no nvel de implementao, atravs de mecanismos como
aqueles apresentados na Seo 3.2.1 e padres como aqueles discutidos na atividade PD.3,
da fase de projeto. A existncia de um framework facilita a gerao de cdigo, uma vez
que o gerador no precisa gerar todo o cdigo, mas somente o cdigo necessrio para
completar o framework. Para essa tarefa, o implementador do domnio, com a ajuda do
especialista do domnio, segue a arquitetura definida na fase de projeto, utilizando as tticas e
padres associados para produzir uma implementao que ir dar suporte ao desenvolvimento
subseqente.
136
Porm, nem toda comunalidade/variabilidade estar contida no framework. Assim, o

segundo papel da implementao de referncia prover exemplos concretos das variabilidades
restantes, servindo como um retrato do cdigo que as transformaes e geradores de cdigo
devem produzir, completando assim o suporte automatizado variabilidade no domnio.
Para isso, a implementao de referncia deve incluir exemplos de todos os pontos comuns
e variveis do domnio. Isto mais fcil de ser alcanado para a variabilidade baseada em
features, que finita. As seguintes diretrizes podem ser utilizadas com este objetivo:
D1 .
Comear implementando um exemplo completo que contm todas as features
mandatrias, e uma seleo arbitrria de uma feature em cada grupo de or features. Deixar
todas as features opcionais no-implementadas.
D2 . Para cada feature opcional, modificar o exemplo, criando uma nova verso do mesmo,
de forma que a feature esteja presente.
D3 . Para features alternativas, modificar o exemplo para considerar a presena de cada
alternativa separadamente, e em diferentes combinaes.
D4 . Prestar ateno s dependncias entre as features. Por exemplo, se uma feature A
depende de outra feature B, no faz sentido implementar A sem a presena de B.
D5 .
Adotar uma abordagem de configurao em estgios (CZARNECKI; HELSEN;
EISENECKER,
2004b), tentando eliminar as variabilidades em uma seqncia lgica,
considerando primeiro as features mais comuns, para reduzir o nmero de possibilidades e

o nmero de verses produzidas a cada refinamento.
D6 . Dar maior ateno s variabilidades que possuem maior impacto na arquitetura, aquelas
que so mais freqentes, e aquelas que exigem mais esforo para implementar manualmente.
D7 .
Para reduzir o nmero de verses da implementao de referncia e facilitar o
seu gerenciamento, pode-se implementar mltiplas variantes simultaneamente, desde que as

mesmas no interfiram uma com a outra.
D8 . Nem todas as possibilidades precisam ser exploradas e implementadas no incio.
Algumas podem ser postergadas para quando a implementao do domnio estiver mais
avanada, ou mesmo aps o domnio estar em produo h algum tempo.
D9 . Nem toda variabilidade precisa ser includa na implementao de referncia, para fazer
parte de uma DSL. Algumas variabilidades podem ser deixadas de fora, sendo necessria a
sua implementao manual, por ocorrerem muito raramente ou exigirem muito esforo para
automatiz-las.
137
D10 . Se existirem um ou mais aplicaes do domnio disponveis, estas podem (e devem)

ser consultadas durante o desenvolvimento da implementao de referncia. Pode-se inclusive
reutilizar trechos de cdigo ou o suporte a alguma variabilidade que venha a estar j presente
em alguma aplicao.
Para variabilidades baseadas em DSL, mais complexas, esta tarefa mais difcil, j que o
nmero de possibilidades infinito. necessrio muito mais conhecimento do especialista para
se produzir exemplos representativos. As seguintes diretrizes podem ajudar:
D11 . Tentar explorar o espao de variabilidade de duas maneiras: utilizando aplicaes
reais para derivar exemplos concretos da variabilidade, e tambm com extremos, como escolhas
e combinaes incomuns dos elementos da DSL.
D12 . Procurar popular atributos multivalorados e listas com mais de uma instncia, caso
contrrio pode-se no perceber a existncia deste tipo de atributo mais tarde, durante a atividade
de mapeamento. Por exemplo, se uma DSL prev a especificao de vrias entidades de dados,
deve-se criar duas ou trs entidades de exemplo, e no somente uma.
D13 . Explorar as diferentes dimenses e tipos de atributos. Deve-se usar tanto valores
pequenos e grandes como exemplos de atributos.
D14 . Resgatar produtos e aplicaes analisados durante a anlise de domnio, de modo
a explorar a maneira como estes lidam com a variabilidade aberta. Deve-se utilizar este
conhecimento como instncias a serem cobertas pela implementao de referncia.
D15 . Caso algum tipo de variabilidade seja muito complexa para ser automatizada atravs
do MDD, deve-se ento ao menos garantir que o cdigo gerado d suporte a algum tipo de
mecanismo que permita a sua implementao manual. Deve-se experimentar estes mecanismos
na implementao de referncia.
Sub-atividade ID.3.2. Inspeo de cdigo e mapeamento para elementos das DSLs
O segundo passo consiste na inspeo do cdigo da implementao de referncia em busca
de trechos que correspondam a elementos de alguma DSL do domnio. O objetivo identificar
principalmente a presena de variantes no cdigo, e mape-las para as DSLs correspondentes.
A incluso de uma variante no cdigo normalmente resulta em modificaes em
diferentes artefatos. H quatro tipos de modificaes que podem co-existir em um domnio
(ANASTASOPOULOS; GACEK, 2001):
Adio de novas funcionalidades: se refere incluso de novos componentes, classes,
138
funes, estruturas de dados ou trechos de cdigo. Esta a chamada variabilidade

positiva. Por exemplo, no domnio web, a incluso da feature de busca pode resultar
em um novo componente, uma caixa de texto na pgina principal e novas estruturas no
banco de dados;
Remoo de funcionalidades: se refere remoo de componentes, classes, funes,
estruturas de dados ou trechos de cdigo. a chamada variabilidade negativa. Por
exemplo, no domnio web, a incluso da feature de busca pode resultar na remoo de
um banner de propaganda do site, por falta de espao;
Substituio de funcionalidades: se refere substituio de componentes, classes,
funes, estruturas de dados ou trechos de cdigo.
Pode-se considerar como uma
combinao de variabilidades negativa e positiva. Por exemplo, a incluso da variante

de busca avanada requer a substituio do componente de busca simples por um outro
que implementa um algoritmo avanado; e
Plataforma/ambiente: quando a incluso da variante requer modificaes na plataforma
ou ambiente de execuo. Por exemplo, no domnio web, a incluso da feature de busca
pode requerer a incluso de uma biblioteca especfica, uma verso diferente do banco de
dados, ou mesmo uma mquina virtual diferente.
Esta atividade cuida da identificao exata destas alteraes. Essencialmente, esta uma
atividade semelhante ao processo de comparao entre duas verses de um software que
acontece em sistemas de controle de verses como CVS ou SVN. Compara-se cada exemplo que
introduz uma variao com o exemplo original, registrando-se todas as alteraes, obtendo-se
um delta que representa a incluso da variante.
Na prtica, porm, a busca por tais alteraes exige um conhecimento aprofundado
do cdigo e do domnio.
A melhor maneira de encontr-las manter o registro das
mudanas (ROBBES; LANZA, 2008) medida que so feitas nos exemplos construdos durante
o desenvolvimento da implementao de referncia, por meio de um documento separado, ou
mesmo com comentrios e anotaes no prprio cdigo.
Cada trecho modificado do cdigo precisa ser mapeado em pelo menos uma variante
descrita em uma DSL ou modelo de features. Se existir uma modificao, mas no existirem
elementos em uma DSL que a descrevam, ento a DSL provavelmente precisa ser refinada
(sub-atividade ID.3.3).
Em alguns casos, uma modificao pode aparentemente ser mapeada para diferentes
elementos de uma ou mais DSLs, o que significa que esta modificao pode ser causada por
139
diferentes variantes simultaneamente. Se for este o caso, deve-se tomar cuidado especial na
implementao do suporte a estes pontos de variao quando ambos forem selecionados ao
mesmo tempo.
Finalmente, pode acontecer de muitas modificaes, em vrias partes da implementao de
referncia, serem mapeadas a um mesmo ponto de variao, o que significa que este elemento
da DSL est espalhado em diferentes partes do cdigo. Caso existam muitas modificaes deste
tipo, pode ser que a atividade de projeto no tenha produzido uma arquitetura adequada, e o uso
de padres de projeto pode reduzir este espalhamento. Ou ento, este pode se tratar de uma
preocupao ortogonal, caso em que tcnicas da orientao a aspectos podem ajudar (VLTER;
GROHER,
2007).
Sub-atividade ID.3.3. Refinamento das DSLs
Durante a inspeo de cdigo, o implementador do domnio pode descobrir que mais

detalhes ou informaes precisam ser includos em uma DSL original antes que a mesma possa
servir de entrada para transformaes e geradores de cdigo. Por exemplo, uma instncia
concreta de uma pgina web pode revelar detalhes como a disposio visual dos elementos,
diferentes escolhas de elementos de entrada, que podem ter passado despercebidos durante
o desenvolvimento da DSL inicial. Alm disso, a inspeo pode identificar novos pontos
de variao que no foram previstos durante a anlise inicial. Finalmente, a inspeo pode
encontrar erros e inconsistncias com os conceitos iniciais e as variabilidades definidas na
abordagem top-down.
Nestes casos, uma ou mais DSLs precisam ser refinadas, para introduzir novos elementos,
modificar ou remover elementos existentes.
Podem ser necessrias alteraes na sintaxe
abstrata, quando o refinamento for mais conceitual, alteraes na sintaxe concreta, quando o
refinamento envolver a representao fsica dos conceitos, ou alteraes no suporte ferramental
produzido. Deve-se tambm tomar cuidado para que no sejam introduzidas inconsistncias,
principalmente quando a DSL sendo refinada possui interaes com outras DSLs e outros
artefatos do domnio. Por isso, deve-se retornar atividade ID.2 e refazer seus passos, visando
manter o refinamento consistente.
Sub-atividade ID.3.4. Desenvolvimento das transformaes e geradores de cdigo
Com o refinamento das DSLs, o implementador produz geradores de cdigo baseados em
templates (Seo 3.2.2). Para isso, ele realiza um processo conhecido como migrao de
cdigo, onde o cdigo da implementao de referncia anotado com marcaes especiais,
140
como tags e scriptlets, que fazem a associao entre o cdigo e a DSL. Cada trecho de cdigo
correspondente a alguma variabilidade, identificado na sub-atividade ID.3.2, recebe algum tipo
de anotao.
Tags normalmente do suporte a comandos mais simples do tipo condicional ou iterativo.
Por exemplo, pode-se embutir o cdigo referente a uma feature opcional dentro de uma tag
do tipo condicional, que aceita como parmetro um tipo booleano em uma DSL que indica a
presena ou ausncia da feature. Especificando-se este parmetro com o valor VERDADEIRO
faz com que o gerador inclua aquele trecho de cdigo, enquanto o valor FALSO faz com que o
gerador no o inclua. Exemplos de tags so aquelas includas pelo projeto JET (Java Emitter
Templates), descrito na Seo 2.2.2.
Variabilidades mais complexas podem precisar de mecanismos mais flexveis do que as tags
para serem implementadas e parametrizadas. Neste caso, pode-se utilizar scriptlets, trechos
de metacdigo que fazem um trabalho mais elaborado de cpia/colagem, produzindo uma
sada que une fragmentos de cdigo de forma a implementar a variabilidade exatamente como
originalmente idealizada.
Geradores baseados em templates representam transformaes modelo-para-texto, em um
nico passo. Porm, transformaes modelo-para-modelo devem ser utilizadas para produzir
geradores mais bem organizados.
Nestes casos, cuidado especial deve ser tomado para
que no seja necessrio modificar os modelos intermedirios, visando evitar problemas de

inconsistncia. Pode-se evitar este tipo de problema atravs de alguns padres e prticas de
sucesso na construo de geradores (VLTER, 2008; VLTER; BETTIN, 2004).
O processo de migrao de cdigo deve sempre manter a implementao de referncia
consistente com o cdigo gerado, ou seja, deve ser possvel gerar uma nova implementao
de referncia sempre que desejado, utilizando os geradores construdos. A princpio, no
existe nenhum problema, desde que a migrao de cdigo no modifique a implementao
de referncia. Mas esta situao pode acontecer, j que durante a migrao de cdigo pode-se
identificar oportunidades para melhorar o suporte variabilidade.
Por exemplo, a implementao de referncia pode implementar alternativas diferentes para
um ponto de variao atravs de trechos de cdigo distintos. Aps a migrao de cdigo para
o template, o implementador pode perceber que a criao de funes separadas, uma para
cada alternativa, uma soluo melhor. Assim, ele modifica o template para implementar esta
soluo, fazendo com que a implementao de referncia se torne inconsistente.
Mesmo que a migrao de cdigo no modifique a implementao de referncia, a prpria
evoluo do domnio normalmente causa este tipo de inconsistncia. Sempre que for necessrio
141
corrigir algum erro, seja no gerador ou em outro lugar, deve-se idealmente realizar a manuteno
primeiro na implementao de referncia, test-la e valid-la, e somente ento repetir o processo
de migrao, de forma que a inconsistncia no exista. Mas na prtica, principalmente correes
menores ou de erros do prprio gerador, modifica-se diretamente os templates, causando
inconsistncia.
Para lidar com estes problemas, o seguinte processo aplicado quando necessrio realizar
alguma alterao (Figura 23).
Figura 23: Manuteno da consistncia da implementao de referncia

Sempre que for necessria uma mudana, faz-se uma anlise para decidir onde realiz-la:
Se a mudana for realizada na implementao de referncia, a migrao de cdigo
repetida, propagando as mudanas at os templates. Se a migrao de cdigo no
introduzir ainda mais modificaes, nada precisa ser realizado.
Caso contrrio, a
implementao de referncia precisa ser substituda, e a maneira recomendada gerar

uma nova implementao e utiliz-la como substituta; e
Se a mudana for realizada direta nos templates, a implementao de referncia precisa
ser substituda, gerando-a novamente.
Atividade ID.4. Desenvolvimento do framework do domnio

Entradas: PT.17. Implementao de referncia
142
Sadas: PT.18. Framework do domnio

Descrio: as atividades anteriores desenvolveram as DSLs, ferramentas e transformaes
do domnio.
Para isso, utilizou-se uma implementao de referncia como base da
identificao das variabilidades no cdigo final. Porm, conforme discutido na atividade

ID.3, a implementao de referncia tambm serve como base para o desenvolvimento de
um framework do domnio. Nesta atividade, portanto, o objetivo transformar o restante da
implementao de referncia em um framework reutilizvel.
De acordo com as caractersticas essenciais de um framework1 , a implementao de
referncia est relativamente prxima de se tornar um framework de domnio, pois:
As classes da implementao de referncia encapsulam conhecimento sobre um domnio
de problema;
Ela foi desenvolvida com base em uma arquitetura bem definida a partir de um processo
centrado no suporte variabilidade e com o objetivo de implementar diferentes diretrizes
arquiteturais;
A implementao de referncia no define somente as classes de forma isolada, mas
tambm as interfaces e conexes entre as mesmas, em uma estrutura que representa parte
do conhecimento daquele domnio; e
A implementao de referncia possui suporte para pontos fixos e pontos variveis,
a exemplo de um framework, que podem ser estendidos e instanciados por um
desenvolvedor de aplicaes;
Portanto, para transformar a implementao de referncia em um framework de domnio, a
princpio s necessrio tornar explcito os pontos variveis, em termos de cdigo no-gerado,
uma vez que o restante das variabilidades ser implementada somente pelos transformadores e
geradores de cdigo.
O cdigo no-gerado, idealmente, j foi estruturado utilizando padres de software que
facilitam a seleo e implementao de algumas variabilidades, na atividade PD.3. Desta forma,
aqui necessrio especificar as interfaces resultantes da aplicao dos padres. Por exemplo,
caso tenha sido utilizado o padro Decorator para features alternativas complementares,
aqui so definidas as interfaces de cada alternativa, com seus mtodos sendo descritos
individualmente.
1 Uma
discusso mais aprofundada sobre frameworks e seu papel na reutilizao de software apresentada no
Apndice A
143
Pode ser necessrio o desenvolvimento de algum mecanismo para facilitar a instanciao

dos pontos variveis.
Por exemplo, pode-se criar um objeto Singleton para facilitar a
instanciao das features implementadas utilizando-se o padro Abstract Factory. Pode-se

inclusive criar um mtodo separado para cada sub-feature alternativa, de forma que para
escolher uma destas, basta chamar o mtodo correspondente, ao invs de instanciar a fbrica
desejada.
Finalmente, a implementao de referncia pode ser complementada com componentes no
includos originalmente, por no terem sido serem necessrios no momento ou por uma deciso
estratgica.
A sada desta atividade uma verso revisada e completada da implementao de
referncia, preparada para ser mais reutilizvel e passvel de instanciao no desenvolvimento
de aplicaes. Uma vez pronto, o framework do domnio toma o lugar da implementao de
referncia.
Atividade ID.5. Documentao do domnio

Entradas: PT.14.Refinado. Linguagens especficas de domnio, PT.15.Refinado. Suporte
ferramental para DSLs, PT.16. Transformaes do domnio, PT.18. Framework do domnio
Sadas: PT.19. Documentao do domnio
Descrio: documentao de software pode reduzir tempo e esforo no desenvolvimento de
novos projetos, facilitar o porte de aplicaes para outras plataformas, alm de ajudar usurios
a compreender um software mais facilmente (PHOHA, 1997). No contexto da reutilizao de
software, a documentao ainda mais importante (SILVA; WERNER, 1996; KOTULA, 1998;
TAULAVUORI; NIEMELA; KALLIO,
2004), uma vez que um reutilizador precisa identificar,
compreender, adaptar e integrar componentes de software em suas aplicaes. Alm disso,

normalmente componentes de software so reutilizados por equipes que no conhecem nem
possuem contato com os desenvolvedores (SZYPERSKI; GRUNTZ; MURER, 2002).
Porm, no existe um padro universalmente reconhecido para documentao de software,
em parte porque estilos e contedo de documentao diferem entre programadores, e alguma
vezes diferem para um mesmo programador em circunstncias diferentes. Adicionalmente, a
escolha da linguagem de programao e a natureza de um programa podem ditar um estilo
particular de documentao que pode no ser facilmente aplicvel a outro ambiente (VOTH,
2004).
144
Existem alguns padres e formatos voltados documentao de software em geral (PHOHA,

1997), como o padro ANSI/ANS 10-3-1995 para documentao de software e o RAS (Reusable
Asset Specifications ou Especificaes de Artefatos Reutilizveis) (VOTH, 2004). Estes podem
ser teis para a documentao de diferentes tipos de software. Com base nestes e em outros
trabalhos relacionados documentao de componentes (SILVA; WERNER, 1996; KOTULA, 1998;
TAULAVUORI; NIEMELA; KALLIO,
2004; BASILI; ABD-EL-HAFIZ, 1996), a presente abordagem
prope um formato especfico para a documentao, alm de alguns princpios:

P1 . Hipertexto. O hipertexto mostrou-se uma tcnica eficiente para a documentao. Por
exemplo, ajuda a aumentar o conhecimento que engenheiros de software adquirem ao percorrer
repositrios de componentes de software (ISAKOWITZ; KAUFFMAN, 1996). Tambm facilita o
processo de navegao atravs da informao, alm de ser um formato j familiar maioria dos
usurios. Assim, sempre que possvel, a documentao deve ser apresentada como hipertexto.
P2 .
Comentrios embutidos no cdigo-fonte.
A documentao deve estar sempre
consistente e atualizada com relao ao cdigo-fonte. Embutindo-se a documentao no

cdigo-fonte, mais fcil atualiz-la sempre que forem feitas mudanas no cdigo, j que
ambos esto no mesmo lugar;
P3 . Automao. No contexto do MDD, possvel gerar, junto com cdigo, diferentes
tipos de artefatos, incluindo documentao. Assim, sempre que possvel, deve-se automatizar a
gerao de documentao para livrar o desenvolvedor deste tipo de trabalho manual;
P4 . Utilize a semntica da linguagem. Muitas construes da prpria linguagem de
programao contm informao til reutilizao de software. Por exemplo, a comparao de
assinatura (ZAREMSKI; WING, 1995) analisa a prpria definio das interfaces para determinar
se um componente pode ser reutilizado em um determinado contexto. Tambm possvel, por
exemplo, determinar algumas caractersticas de um componente examinando-se o cdigo-fonte,
at mesmo de forma automtica. Assim, a documentao deve utilizar todo tipo de informao
semntica disponvel no prprio cdigo-fonte.
P5 . Diagramas e figuras. A documentao deve incluir diagramas e figuras sempre que
possvel. No MDD, muitas das informaes visuais esto disponveis na prpria linguagem
especfica do domnio. Assim, um artefato que serve de entrada para um gerador o prprio
documento visual do software a ser gerado.
Para a documentao de artefatos de cdigo, pode-se utilizar um formato como o
descrito em (ALMEIDA et al., 2008), que contempla cinco sees e seus campos relacionados:
informaes bsicas, contendo descries gerais sobre o componente, como seu nome,
propsito e palavras-chave; descrio detalhada, contendo a definio das interfaces
145
e informaes sobre a linguagem de implementao, versionamento, etc; informaes

de qualidade, descrevendo as informaes necessrias para a garantia de qualidade do
componente, tais como o pacote de testes; informaes sobre implantao, tais como as
dependncias necessrias para compilar e implantar o componente; e informaes de suporte,
com um guia de instalao e contatos que ajudam na identificao das pessoas responsveis
pelo suporte tcnico do componente.
Para outros artefatos especficos do MDD, sugere-se os seguintes formatos:
Para DSLs, deve-se incluir informaes sobre:
1. O sub-domnio com o qual a DSL se relaciona;
2. A gramtica ou metamodelo utilizado;
3. Detalhes sobre a sintaxe concreta, tais como o significado das figuras, linhas, cones,
decoraes;
4. Ferramentas de modelagem que podem ser utilizadas;
5. Outras DSLs que interagem com esta;
6. Transformaes/geradores com os quais a DSL se relaciona (isto , serve de
entrada); e
7. Exemplos de sua utilizao.
Para ferramentas de modelagem, deve-se incluir informaes sobre:
1. O sub-domnio com o qual a ferramenta se relaciona;
2. A DSL para a qual a ferramenta oferece suporte;
3. Detalhes sobre o seu desenvolvimento, tais como as tecnologias ou frameworks
utilizados;
4. Manual de instalao e utilizao; e
5. Contatos para suporte tcnico.
Para transformaes de software, deve-se incluir informaes sobre:
1. O raciocnio por trs das regras de transformao, uma vez que as linguagens de
transformao nem sempre so intuitivas o suficiente para serem compreendidas
sem informao adicional;
2. Metamodelos ou DSLs de origem e destino;
146
3. Detalhes sobre o seu desenvolvimento, tais como as linguagens, tecnologias ou

frameworks utilizados; e
4. Especificao dos parmetros necessrios para a transformao.
Para geradores de cdigo, deve-se incluir informaes sobre:
1. Comentrios, no prprio cdigo dos geradores, sobre os mapeamentos com as DSLs
de entrada;
2. Metamodelos ou DSLs de origem;
3. Linguagens de destino;
4. Descrio e raciocnio do cdigo gerado;
5. Detalhes sobre o seu desenvolvimento, tais como as linguagens, tecnologias ou
frameworks utilizados;
6. Especificao dos parmetros necessrios para a gerao de cdigo.
importante ressaltar que a maioria das informaes necessrias para esta documentao
foi sendo produzida ao longo do processo de engenharia de domnio.
Por exemplo, os
metamodelos das DSLs, o mapeamento entre DSLs e cdigo, cruzamento entre diferentes
DSLs, entre outras informaes, foram produzidos durante o processo de anlise, projeto e
implementao. Neste caso, trata-se somente de um processo de empacotamento da informao,
e possivelmente algum refinamento. Em outros casos, como a descrio e raciocnio do
cdigo gerado, especificao dos parmetros para as transformaes e geradores de cdigo,
as informaes precisam se definidas e detalhadas somente aps sua concluso.
7.3
Consideraes finais
A fase de implementao do domnio quando as informaes coletadas sobre o

domnio e modeladas durante a anlise e projeto so concretizadas em forma de artefatos de
implementao. Assim, ao final desta atividade, tem-se um conjunto de artefatos reutilizveis,
ou componentes, que implementam parte da arquitetura do domnio, linguagens especficas
para os sub-domnios, ferramentas que permitem criar modelos para estes sub-domnios e
transformaes modelo-modelo e modelo-texto capazes de gerar cdigo especfico para a
arquitetura do domnio.
O Quadro 8 resume as atividades de implementao do domnio.
O Quadro 9 descreve os produtos de trabalho da fase de implementao do domnio.
147
ID.1. Caracterizao da variabilidade dos
sub-domnios
ID.2. Definio das DSLs e do suporte

ferramental (top-down)
ID.2.1. Identificao das features iniciais
da DSL
ID.2.2. Definio da sintaxe abstrata
ID.2.3. Definio da sintaxe concreta
ID.2.4. Definio da integrao inter-DSL
ID.2.5. Construo da ferramenta de
modelagem especfica de domnio
ID.3. Desenvolvimento das transformaes
e refinamento das DSLs (bottom-up)
ID.3.1.
Desenvolvimento da
implementao de referncia
ID.3.2. Inspeo de cdigo e mapeamento
para elementos das DSLs
ID.3.3. Refinamento das DSLs
ID.3.4.
Desenvolvimento das
ID.4. Desenvolvimento do framework do
domnio
ID.5. Documentao do domnio
Entradas
PT.8.
PT.8.
PT.13. Sub-domnios caracterizados
Sadas
PT.13.
caracterizados

PT.8.
PT.13. Sub-domnios caracterizados
PT.14.Inicial. Linguagens especficas de domnio
PT.15.Inicial. Suporte ferramental para DSLs
PT.14.Refinado.
Linguagens
especficas de domnio
PT.15.Refinado.
Suporte
ferramental para DSLs
PT.16. Transformaes do domnio
PT.17.
Implementao de
referncia
PT.17. Implementao de referncia
PT.18. Framework do domnio
PT.14.Refinado.
Linguagens especficas de
domnio
PT.15.Refinado. Suporte ferramental para DSLs
PT.19. Documentao do domnio
Sub-domnios
PT.14.Inicial.
Linguagens
especficas de domnio
PT.15.Inicial. Suporte ferramental
para DSLs
Quadro 8: Resumo das atividades para implementao do domnio orientada a modelos

No prximo captulo apresentado um possvel modelo de ciclo de vida para a utilizao
da abordagem, considerando-se um processo evolutivo e interativo, com caractersticas mais
prximas realidade das organizaes.
148
Produto de trabalho
PT.13.
Sub-domnios
caracterizados
PT.14. Linguagens especficas de
domnio
PT.15.
DSLs
Suporte ferramental para
PT.17.
referncia
Implementao
de
PT.19. Documentao do domnio
Descrio
Definio do tipo de variabilidade
caracterstico de cada sub-domnio: baseada
em features ou baseada em DSLs
Definio das sintaxes abstrata e concreta
das linguagens especficas de domnio para
os sub-domnios identificados durante o
processo. A sintaxe abstrata das DSL visuais
normalmente um metamodelo, enquanto
a sintaxe abstrata das DSLs textuais uma
gramtica
Ferramentas de modelagem para as DSLs.
Podem ser ferramentas visuais, para a
criao de diagramas segundo uma DSL
visual, ou ferramentas textuais, para a
criao de programas segundo uma DSL
textual
Transformaes modelo-para-modelo e
modelo-para-cdigo para serem utilizadas
em conjunto com as DSLs do domnio
Uma implementao do domnio contendo
exemplos das diferentes variabilidades
identificadas durante o processo
Conjunto de classes reutilizveis de um
domnio, estruturadas de modo a formar
um esqueleto de uma aplicao do domnio,
com os pontos variveis bem definidos
e mecanismos que possibilitam a sua
instanciao
Documentao dos diferentes artefatos de
implementao do domnio, incluindo
componentes,
DSLs,
ferramentas,
Status
Nenhum
1.
Inicial: verso da DSL produzida
somente atravs de uma abordagem
top-down. Normalmente faltam detalhes que
s sero identificados aps a implementao
2. Refinado: verso inicial da DSL refinada
aps uma abordagem bottom-up, que
identifica mais detalhes para a linguagem
1.
Inicial:
verso das ferramentas
produzidas somente atravs de uma
abordagem top-down. Normalmente faltam
detalhes que s sero identificados aps a
implementao
2. Refinado: verso inicial das ferramentas
aps uma abordagem bottom-up, que
identifica mais detalhes para a linguagem
Nenhum
Nenhum
Nenhum
Nenhum
Quadro 9: Descrio dos produtos de trabalho da fase de implementao do domnio
149
Modelo de processo
As atividades das fases de anlise, projeto e implementao do domnio foram descritas, nos
captulos anteriores, de forma seqencial, para facilitar o seu entendimento. Porm, na prtica
estas atividades acontecem de forma iterativa e interativa, e a sua ordem pode ser alterada para se
adequar realidade de uma organizao de software. Neste captulo apresenta-se uma sugesto
sobre um modelo de processo de desenvolvimento de software para a utilizao da abordagem.
Um modelo de processo uma representao abstrata de um processo de software
(SOMMERVILLE, 2006). Cada modelo de processo representa um processo sob o ponto de
vista de uma perspectiva em particular, e portanto contm apenas informaes parciais sobre
esse processo. Existem diferentes modelos de processo conhecidos na literatura da Engenharia
de Software, como o modelo em cascata, modelo evolutivo, baseado em componentes,
incremental, espiral, entre outros (PRESSMAN, 2005). Estes modelos de processo no so
mutuamente exclusivos, sendo freqentemente utilizados em conjunto, especialmente no
desenvolvimento de grandes sistemas.
O RUP (Rational Unified Process), por exemplo,
combina elementos de vrios destes modelos.

A abordagem desta tese baseada no modelo espiral, proposto originalmente por Boehm
(1988). O modelo espiral representa um processo de software em uma espiral, onde todas as
atividades so executadas repetidamente a cada iterao. Cada nova volta na espiral acrescenta
um desenvolvimento novo, produzindo, por exemplo, novos artefatos de software, ou refinando
artefatos j existentes.
A Figura 24 mostra um possvel modelo de processo para utilizao da abordagem para
reutilizao de software orientada a modelos.
Existem trs ciclos bsicos neste modelo: o ciclo principal, o ciclo de projeto e o ciclo
de implementao. Em cada ciclo, existe uma atividade (AD.1, PD.5 e ID.4, destacadas na
Figura 24) que marca um momento de deciso sobre continuar ou no a execuo daquele ciclo
especfico. Cada ciclo detalhado a seguir.
150
Figura 24: Sugesto de modelo de processo para utilizao da abordagem
8.1
Ciclo principal do modelo de processo: evoluo dos

sub-domnios
O ciclo principal comea na primeira atividade da anlise de domnio (Atividade AD.1.

Planejamento do domnio) e termina na ltima atividade da implementao do domnio
(Atividade ID.5. Documentao do domnio). Cada iterao neste ciclo principal introduz
refinamentos em diferentes artefatos, como nos modelos do domnio (modelo de features,
modelos de casos de uso e de mudana), na arquitetura e seus componentes, e nos artefatos
de implementao. Estes refinamentos consistem de melhorias ou correes percebidas durante
o desenvolvimento e evoluo do domnio.
Mas a atividade mais notvel do ciclo principal a Atividade AD.5. Deciso sobre
151
incluso/excluso de sub-domnios. Conforme discutido no Captulo 5, a identificao de

sub-domnios pautada por uma incerteza que somente pode ser resolvida atravs de maiores
investigaes envolvendo as linguagens, transformaes e geradores de cdigo para cada
sub-domnio. Assim, o ciclo principal gira em torno deste processo investigativo, que culmina
com esta atividade, e a deciso nela tomada influencia todas as demais atividades.
O ciclo principal evolui da seguinte forma, a cada iterao;
1. Atividade AD.1. Planejamento do domnio: no comeo de cada nova iterao, esta

atividade revisita o plano inicial, incluindo novas consideraes que possam ser elicitadas
durante o projeto e implementao. tambm nesta atividade que uma anlise de risco
realizada, para determinar se vale a pena continuar investindo no domnio e se novas
iteraes so necessrias;
2. Atividade AD.2. Modelagem do domnio: nesta atividade, a cada iterao, o analista
do domnio refina os modelos de features, de casos de uso e de casos de mudana,
considerando-se a eventual incluso de novos artefatos ou mesmo novos sub-domnios;
3. Atividade AD.3. Identificao de sub-domnios: a cada iterao, o analista do domnio,
revisita a lista de sub-domnios, aps a experincia obtida com as implementaes
e investigaes realizadas na iterao anterior.
Novos nveis de confiana podem
ser atribudos aos sub-domnios identificados, o que pode levar a novas decises
posteriormente. Novos candidatos a sub-domnio tambm podem ser identificados;
4. Atividade AD.4. Validao e documentao do domnio: nesta atividade, os documentos
existentes so atualizados para refletir eventuais mudanas. Gerncia de configurao e
controle de verses devem ser utilizados para manter estes documentos organizados;
5. Atividade AD.5. Deciso sobre incluso/excluso de sub-domnios: nesta atividade, toda
nova informao sobre os candidatos a sub-domnio revista, e novas decises podem
ser tomadas sobre eles. Por exemplo, candidatos em investigao podem passar para
produo, ou serem excludos permanentemente, ou pode-se iniciar um projeto piloto
com um candidato j exaustivamente investigado e testado;
6. Fase de projeto de domnio: a cada iterao do ciclo principal, a fase de projeto produz
refinamentos na arquitetura, considerando-se os novos modelos do domnio, novos nveis
de deciso sobre os sub-domnios ou mais detalhes sobre as diretrizes arquiteturais que
possam ter sido percebidos na iterao anterior. Estes refinamentos podem inclusive
resultar no surgimento de novos mdulos; e
152
7. Fase de implementao do domnio: a cada iterao do ciclo principal, so introduzidos

refinamentos e mudanas na implementao, para refletir novas decises de projeto
tomadas nesta iterao. Deve-se tomar cuidado especial para que as mudanas no
causem inconsistncias entre as DSLs, transformaes, geradores de cdigo, e a
implementao de referncia, conforme discutido no Captulo 7.
O resultado de sucessivas iteraes no ciclo principal um crescimento contnuo no
nmero de artefatos do domnio e tambm no nvel de confiana dos sub-domnios a serem
automatizados. Alm disso, cada vez mais sub-domnios so descartados, medida que
a experincia demonstra que os mesmos so muito difceis ou impossveis de automatizar.
Idealmente, no final de vrias iteraes todos os sub-domnios so includos ou excludos do
processo, ou seja, a tendncia no existirem candidatos nos nveis intermedirios de deciso.
Dependendo do domnio, esta evoluo pode apresentar algumas caractersticas distintas.
Por exemplo, em sistemas crticos, onde prefervel o uso somente de linguagens e
ferramentas bem conhecidas, as iteraes podem parar aps estas terem sido includas, sem
que haja investigao ou desenvolvimento extra para desenvolver linguagens e ferramentas
personalizadas. Em projetos com pouco prazo para entrega, uma nica iterao pode ser vivel,
resultando em vrios sub-domnios sendo deixados para trs.
Uma sugesto sobre a evoluo do domnio, visando reduzir os riscos e problemas
associados adoo do MDD, incluir, nas primeiras iteraes, apenas sub-domnios mais
conhecidos, com ferramentas e linguagens de modelagem disponveis. Desta forma, pode-se
perceber os benefcios do MDD sem a necessidade de um investimento inicial maior, alm de
proporcionar uma evoluo mais rpida nestas primeiras iteraes.
8.2
Ciclo de projeto do modelo de processo:

arquitetural
evoluo
Dentro do ciclo principal, a fase de projeto tambm ocorre de forma iterativa. A cada
iterao no ciclo de projeto, novos mdulos so identificados, formando a arquitetura do
domnio.
Trata-se de um processo de refinamento dirigido por padres.
A diviso em
mdulos ocorre de acordo com a instanciao de um ou mais padres que atendem s diretrizes
arquiteturais.
O projeto se inicia com uma diviso principal, envolvendo todo o domnio. Esta diviso
produz os mdulos principais do sistema. Por exemplo, se for adotado o padro em camadas
(BUSCHMANN et al., 1996), a primeira diviso resulta na identificao das camadas do domnio.
153
Se for adotado o padro MVC (Model-View-Controller) (BUSCHMANN et al., 1996), a primeira

diviso resulta na identificao dos elementos de modelo, de viso e de controle, e assim por
diante.
As iteraes seguintes refinam cada mdulo de acordo com o padro escolhido. Por
exemplo, ao se aplicar o padro Observer (GAMMA et al., 1995) em um mdulo, sero
identificados novos mdulos (ou classes), como o Sujeito, Sujeito Concreto, Observador e
Observador Concreto.
No caso desta abordagem focada em reutilizao, os padres visam, alm de identificar
novos mdulos, adicionar o suporte variabilidade prevista durante a anlise. Alm disso,
tendo foco tambm no MDD, cada refinamento identifica no somente mdulos de software
convencional, como classes e mtodos, mas tambm elementos como transformaes e
geradores de cdigo, alm de DSLs e ferramentas de modelagem. Todos estes tambm fazem
parte da arquitetura.
Assim, a evoluo do ciclo de projeto ocorre da seguinte maneira, para cada atividade:
1. Atividade PD.1. Escolha dos mdulos a serem refinados: a cada iterao, esta atividade
escolhe novos mdulos para serem refinados. Obviamente, na primeira iterao ainda
no existem mdulos, e a escolha fatalmente o domnio todo. As demais atividades so
executadas individualmente para cada mdulo aqui escolhido;
2. Atividade PD.2. Seleo das diretrizes arquiteturais: esta atividade identifica, para cada
mdulo sendo refinado nesta iterao, os principais requisitos de software que podem
influenciar a arquitetura naquele exato local referente ao mdulo. Para cada mdulo
seleciona-se, dentre todos os requisitos e objetivos de negcio do domnio, aqueles
que dizem respeito somente ao mdulo em questo, e que possuem impacto em sua
arquitetura. Estas so as chamadas diretrizes arquiteturais;
3. Atividade PD.3. Escolha de tticas e padres arquiteturais: nesta atividade o projetista
do domnio escolhe, para cada mdulo sendo refinado, e com base nas diretrizes
selecionadas para aquele mdulo, tticas e padres arquiteturais a serem aplicados no
refinamento do mdulo;
4. Atividade PD.4. Aplicao dos padres arquiteturais e refinamento dos mdulos: esta
a atividade onde efetivamente realizado o refinamento dos mdulos. A cada iterao,
com a aplicao das tticas e padres escolhidos, os mdulos so refinados, possivelmente
resultando na identificao de novos mdulos e relacionamentos; e
154
5. Atividade PD.5.
Avaliao arquitetural: esta atividade busca avaliar a arquitetura
projetada frente aos seus requisitos. A cada iterao, novas arquiteturas produzidas so
avaliadas, e o resultado da avaliao serve de entrada para uma nova iterao no ciclo de
projeto.
O resultado das sucessivas iteraes no ciclo de projeto a produo de uma arquitetura

para o domnio, capaz de dar suporte s variabilidades identificadas durante a anlise.
Dependendo do nmero de mdulos identificados, so necessrias mais ou menos iteraes.
A tendncia que o nmero de iteraes no ciclo de projeto diminua a cada iterao do ciclo
principal, uma vez que restam cada vez menos mdulos para serem refinados.
8.3
Ciclo de implementao do modelo de processo:

produo dos artefatos reutilizveis e documentao
A fase de implementao tambm possui iteratividade, que ocorre em um ciclo menor,

composto pelas atividades ID.2, ID.3 e ID.4. As iteraes desta fase so intrnsecas a qualquer
atividade de codificao, exigindo re-trabalho medida que a implementao avana.
No caso desta abordagem, a iteratividade visa coletar informaes durante a codificao,
realimentando a atividade de definio das linguagens especficas de domnio. Isto porque no
contexto do MDD, uma DSL no somente um mecanismo de comunicao de idias. Ela deve
ser no-ambgua e rica o suficiente para servir de entrada para transformaes e geradores de
cdigo. Para isso, so necessrios detalhes e ajustes que s so percebidos aps a experincia
de codificao.
Alm disso, a implementao envolve diferentes sub-domnios. Cada iterao cuida do
desenvolvimento dos artefatos de implementao para um nico sub-domnio. Assim, caso
existam dez sub-domnios, por exemplo, sero necessrias dez iteraes neste ciclo.
A fase de implementao evolui da seguinte maneira:
1. Atividade ID.1. Caracterizao da variabilidade dos sub-domnios: esta atividade, que

est fora do ciclo iterativo da fase de implementao, identifica o tipo de variabilidade
inerente a cada sub-domnio. executada uma nica vez a cada iterao do ciclo
principal, e seu objetivo definir o tipo de suporte em termos de DSL e ferramentas
que ser necessrio para cada sub-domnio. importante ressaltar que nem todos os
sub-domnios identificados na anlise iro passar pela fase de implementao. Somente
155
so considerados os sub-domnios selecionados para investigao ou produo durante

esta iterao do ciclo principal, conforme decidido na atividade AD.5 da fase de anlise;
2. Atividade ID.2. Definio das DSLs e do suporte ferramental: esta atividade cuida
do desenvolvimento de uma DSL para um sub-domnio, assim como o seu suporte
ferramental (ferramentas de modelagem e editores). A cada iterao, mais sub-domnios
so implementados, at que todos aqueles selecionados na atividade AD.5 estejam
implementados ou devidamente investigados;
3. Atividade ID.3. Desenvolvimento das transformaes e refinamento das DSLs: nesta
atividade, so desenvolvidas transformaes de software e geradores de cdigo para
os sub-domnios, e as DSLs definidas na atividade ID.2 so refinadas a partir da
experincia com a implementao. A cada iterao, novas transformaes e geradores
so desenvolvidos, at que todos os sub-domnios selecionados na atividade AD.5 tenham
transformaes e geradores, ou foram devidamente investigados;
4. Atividade ID.4. Desenvolvimento do framework do domnio: esta atividade cuida do
refinamento da implementao de referncia produzida na atividade ID.3, produzindo
um framework do domnio. A cada iterao, o framework evolui com o suporte
variabilidade de mais sub-domnios; e
5. Atividade ID.5. Documentao do domnio: esta atividade, que a exemplo da atividade
ID.1 est fora do ciclo iterativo da fase de implementao, cuida da documentao dos
artefatos desenvolvidos nesta iterao do ciclo principal.
Aps a fase de implementao, tem-se como resultado um conjunto de artefatos de

implementao que atendem ao projeto realizado na fase anterior. Estes artefatos incluem
DSLs, transformaes, geradores de cdigo e um framework do domnio, e seguem a arquitetura
definida no projeto.
importante ressaltar que nem sempre as iteraes dos ciclo da fase de implementao
produzem artefatos que faro parte do domnio. Como o suporte automatizado a sub-domnios
incerto e exige investigao, o resultado da implementao pode ser insatisfatrio, de modo
que alguns sub-domnios podem no ser includos no processo. Esta deciso ir ocorrer na
prxima iterao do ciclo principal, no final da fase de anlise, subsidiada pelas experincias
obtidas com a fase de implementao.
156
8.4
Consideraes finais
Neste captulo apresentou-se um possvel modelo de processo para a utilizao da

abordagem de reutilizao orientada a modelos. Esta apenas uma sugesto, que busca
combinar as atividades de forma natural. O foco deste modelo a iteratividade, forada
pelo aspecto investigativo que deriva da incerteza sobre as possibilidades de automao dos
sub-domnios.
Porm, este modelo pode ser adaptado para refletir outras necessidades da organizao,
de forma a reforar aspectos que aqui foram ignorados. Por exemplo, como esta tese tem
foco mais tcnico, foram omitidos mais detalhes sobre gerenciamento de riscos, atividades
de gerenciamento e controle, melhoria do processo, uso de mtricas, entre outros pontos
igualmente importantes em um projeto de software.
157
Avaliao
A combinao entre desenvolvimento orientado a modelos e reutilizao de software tem

como promessa a reutilizao em alto nvel, como defendido pelos pesquisadores (NEIGHBORS,
1980; KRUEGER, 1992; GRISS, 1995; FRAKES; ISODA, 1994; JACOBSON; GRISS; JONSSON, 1997)
desde as primeiras discusses sobre reutilizao de software. Diversos pesquisadores, entre
eles Czarnecki et al. (2005), concordam que MDD e reutilizao so esforos complementares.
As prprias origens destas duas linhas de pesquisa esto interligadas, conforme discutido no
Captulo 10.
A presente tese buscou investigar de forma mais aprofundada esta idia: defende-se que
a combinao entre o desenvolvimento orientado a modelos e reutilizao de software em um
processo sistemtico pode melhorar a reutilizao alcanada por uma organizao de software,
quando comparada com um processo no orientado a modelos. Para isso, a preocupao com
o MDD deve estar presente em todas as etapas do processo, incluindo a anlise, o projeto e a
implementao do domnio.
Assim, esta tese pode ser vista a partir da perspectiva de duas preocupaes principais:
1. A primeira e principal preocupao diz respeito aos benefcios trazidos pelo MDD
reutilizao de software. Os benefcios associados com o MDD no seriam outros manutenibilidade, produtividade, documentao? Esta tese defende que NO: o MDD
oferece meios concretos para que a reutilizao de conhecimento possa ocorrer em
maior grau e de forma mais adequada, quando comparada com um processo no
orientado a modelos; e
2. A segunda diz respeito ao papel do MDD dentro do processo de reutilizao. No seria
o MDD apenas uma tcnica aplicvel isoladamente na implementao ou no projeto de
artefatos de um domnio, a exemplo de muitas abordagens para reutilizao orientada
a modelos (Ver Seo 10.2.2)? Esta tese defende que NO: a utilizao do MDD
exige uma preocupao que deve estar presente em todo o ciclo de vida, devendo
ser tratada de forma consistente desde a anlise at a implementao.
158
Estes so os dois pontos principais a serem avaliados. Para tanto, foram realizados estudos
empricos envolvendo a aplicao da abordagem em projetos de engenharia de domnio, com
o objetivo de fornecer evidncias ou indcios sobre a validade desta tese.
A seguir so
apresentados os detalhes sobre a avaliao realizada.
9.1
Definio
Para a definio dos estudos desta avaliao, foi utilizado o paradigma GQM
(Goal-Question Metric) (BASILI; CALDIERA; ROMBACH, 1994). Neste paradigma, devem ser
definidos os objetivos da avaliao, que devem ser rastreados a um conjunto de dados que
definem estes objetivos de forma operacional, e a interpretao destes dados com respeito aos
objetivos definidos. O rastreamento entre os objetivos e os dados feito atravs de questes que
caracterizam os objetivos de forma mais especfica.
Assim, seguindo o formato sugerido no GQM, so definidos dois objetivos para esta
avaliao, assim descritos e detalhados por meio das respectivas questes especficas:
G1 . Analisar a abordagem orientada a modelos para reutilizao de software com o objetivo
de determinar se ela promove aumento e/ou melhoria na reutilizao de software, quando
comparada com o desenvolvimento no orientado a modelos, com respeito aos artefatos
do domnio produzidos do ponto de vista do pesquisador no contexto de projetos de
engenharia de domnio.
Q1 . Analisando-se um mesmo projeto desenvolvido com e sem a abordagem, possvel
observar um aumento e/ou melhoria na reutilizao de software no projeto que
utilizou a abordagem?
Q2 . Os artefatos de software produzidos com a abordagem so mais reutilizveis do que
aqueles produzidos em uma abordagem no orientada a modelos?
G2 . Analisar a abordagem orientada a modelos para reutilizao de software com o objetivo
de determinar a sua importncia em todo o ciclo de vida com respeito aos benefcios
obtidos e dificuldades de utilizao do ponto de vista do pesquisador no contexto de
projetos de engenharia de domnio.
Q3 . Os sujeitos que utilizaram a abordagem perceberam, durante as atividades da
abordagem referentes preocupao com MDD desde o incio do desenvolvimento
(fase de anlise), algum benefcio para a implementao dos artefatos do MDD
(DSLs, transformaes e geradores de cdigo)?
159
Q4 . Os sujeitos que utilizaram a abordagem tiveram dificuldades que causaram prejuzo

ao desenvolvimento, em termos de atrasos e curva de aprendizado?
O objetivo G1 diz respeito tese de que o MDD oferece meios concretos para que a
reutilizao de conhecimento possa ocorrer em maior grau e de forma mais adequada, quando
comparada com um processo no orientado a modelos. Assim, a questo Q1 busca observar
este aumento e/ou melhora na reutilizao comparando-se dois projetos: um desenvolvido
sem a abordagem e outro desenvolvido com a abordagem. Contudo, mesmo que no seja
observado efetivamente um aumento conforme as mtricas especificadas, isto no significa
que a abordagem no favorea mais reutilizao. Existe a possibilidade de os artefatos serem
mais reutilizveis quando desenvolvidos com a abordagem, mesmo que no tenham sido
efetivamente reutilizados no seu maior potencial nestes estudos. Assim, a questo Q2 busca
avaliar este aspecto.
O objetivo G2 diz respeito tese de que a utilizao do MDD exige uma preocupao que
deve estar presente em todo o ciclo de vida, devendo ser tratada de forma consistente desde
a anlise at a implementao. Assim, a questo Q3 se refere obteno de algum benefcio
observvel com a aplicao da abordagem desde o incio. A questo Q4 busca identificar se a
utilizao do MDD desde o incio traz mais problemas do que benefcios.
9.1.1
Coleta de dados
Para a obteno de dados que possam conter indcios ou evidncias sobre estas questes,
foram definidas formas qualitativas e quantitativas de coleta de dados, combinando a percepo
subjetiva dos envolvidos nos estudos empricos com medidas referentes estrutura do software
produzido e outros atributos de qualidade.
Foram definidas formas de coleta de dados
especficas para cada questo relacionada aos objetivos da avaliao, conforme apresentado
a seguir.
Questo Q1 . Analisando-se um mesmo projeto desenvolvido com e sem a abordagem,
possvel observar um aumento e/ou melhoria na reutilizao de software no projeto que
utilizou a abordagem?
difcil definir o que significa aumento e/ou melhoria na reutilizao. A reutilizao
ocorre de diversas maneiras, e dependendo do contexto, pode significar diferentes benefcios.
Por exemplo, a reutilizao obtida por meio de herana completamente diferente da
reutilizao obtida com um gerador de cdigo, sendo difcil determinar qual das duas oferece
maiores benefcios, pois no h mtricas consistentes capazes de medir ambos os aspectos de
160
forma normalizada.
Existem diferentes mtricas voltadas reutilizao1 , focando em aspectos econmicos e
estruturais de artefatos de software. No contexto desta questo destacam-se apenas os aspectos
estruturais, pois esta tese trata de uma abordagem voltada para a engenharia para reutilizao.
A literatura apresenta algumas mtricas simples para medir a reutilizao no nvel estrutural dos
artefatos, mas nenhuma delas capaz de oferecer uma imagem completa do nvel de reutilizao
em um sistema (MASCENA; ALMEIDA; MEIRA, 2005). Assim, faz-se necessria uma anlise mais
cuidadosa, combinando-se diferentes mtricas que avaliem os aspectos importantes para este
estudo especfico.
Assim, as seguintes mtricas foram definidas para a questo Q1 :
M1 . Porcentagem de reutilizao (RP - Reuse Percent). Esta a mtrica mais bsica de
reutilizao, sendo definida como a razo entre o nmero de linhas de cdigo reutilizadas e
o nmero total de linhas de cdigo (POULIN; CARUSO, 1993). Um cuidado especial deve ser
tomado com esta mtrica, pois pode levar a concluses incorretas. Por exemplo, caso seja
reutilizado um nico mtodo, pequeno, de uma classe com milhares de linhas de cdigo, esta
porcentagem seria alta mas no refletiria a realidade de que apenas uma poro da classe
foi reutilizada. A coleta desta mtrica envolve a identificao dos mdulos reutilizados e a
contagem das linhas de cdigo dos mdulos reutilizados e no-reutilizados.
M2 . Razo de reutilizao (RR - Reuse Ratio). Esta mtrica calculada da mesma forma
que a M1 , porm tambm considerando-se a reutilizao do tipo caixa-branca (DEVANBU et al.,
1996): artefatos modificados at um certo nvel so considerados como reutilizados. Devanbu
et al. (1996) sugerem o valor de 25% como margem de tolerncia: artefatos que tiveram mais
de 25% de seu cdigo modificado no so considerados como reutilizados.
M3 . Porcentagem de reutilizao no desejada. Conforme destacado na mtrica M1 , a
reutilizao de grandes trechos de cdigo que no so efetivamente utilizados pode distorcer
a mtrica de porcentagem de reutilizao. O uso desta mtrica permite determinar se este
efeito est ocorrendo. Alm disso, reutilizar cdigo que no efetivamente aproveitado pode
ser prejudicial, agregando informaes descartveis que podem confundir a equipe durante a
manuteno do software. Portanto, esta mtrica tambm ajuda a caracterizar a reutilizao. Esta
mtrica consiste no clculo da porcentagem, para cada artefato reutilizado, das linhas de cdigo
que no so efetivamente utilizadas em relao ao nmero total de linhas de cdigo reutilizadas.
Para a coleta desta mtrica pode-se utilizar funcionalidades das IDEs que permitem determinar
quais mtodos no so chamados, por exemplo.
1 Uma
discusso sobre mtricas para MDD e reutilizao apresentada no Captulo 10
161
M4 . Porcentagem de reutilizao gerada. Esta mtrica calcula a porcentagem de artefatos

produzidos por gerao automtica e que foram reutilizados, em relao ao total de reutilizao.
calculada como sendo a porcentagem entre o nmero de linhas de cdigo geradas e o nmero
de linhas de cdigo reutilizadas. Permite caracterizar a reutilizao que est ocorrendo em
domnios implementados atravs do MDD.
M5 . Razo entre especificao e cdigo. Esta mtrica complementar anterior, e permite
determinar a relao entre um elemento de especificao e o cdigo gerado correspondente. Por
exemplo, se a especificao de uma classe, com atributos e relacionamentos, produz 1000 linhas
de cdigo, tem-se um maior nmero de linhas de cdigo reutilizadas do que a especificao de
um arquivo de configurao com 10 linhas que produz somente 20 linhas de cdigo. Esta
mtrica calculada da seguinte forma:
REC = LOC(modulosgerados)
: NEE(modelos)
onde NEE(modelo) corresponde ao nmero de elementos de especificao do modelo.
Um elemento de especificao pode ser uma linha de texto (em uma DSL textual) ou um
elemento grfico de um diagrama, seja ele uma caixa, atributo, linha ou outro elemento grfico
similar. Para efeito de comparao, considera-se que uma linha textual aproximadamente
equivalente a um elemento grfico, pois apesar de o elemento grfico ser mais simples de criar
e editar do que uma linha de texto, ele normalmente possui propriedades que precisam ser
configuradas individualmente.
As mtricas M4 e M5 presumem a existncia de gerao de cdigo, e portanto no podem
ser utilizadas para comparar um projeto desenvolvido sem a abordagem (que no possui gerao
de cdigo) com um projeto desenvolvido com a abordagem. Porm, elas so teis para ajudar a
caracterizar a reutilizao que est ocorrendo com a abordagem.
Dois pontos de discusso sobre estas mtricas precisam ser destacados:
1. No contexto envolvendo gerao de cdigo, pode-se argumentar que o uso do tamanho

em linhas de cdigo nas mtricas pode distorcer os resultados, uma vez que geradores de
cdigo normalmente produzem cdigo mais denso (MODELWARE, 2006a). No entanto,
vale ressaltar que nesta abordagem a construo dos geradores feita a partir de uma
implementao de referncia, ou seja, o cdigo gerado segue os mesmos padres,
convenes e formato utilizados pelos programadores humanos.
comparao vlida (MODELWARE, 2006a);
Neste contexto, a
162
2. Estas mtricas so aplicadas somente a cdigo-fonte, no sendo teis para elementos

de modelagem. Como o objetivo comparar a quantidade de conhecimento que foi
reutilizada na construo do software final, a comparao dos cdigos razovel, uma
vez que o tamanho de um mdulo reflete de forma indireta a quantidade de conhecimento
ali encapsulado.
Esse segundo ponto s vlido para a questo Q1 . Na questo Q2 , discutida a seguir,
os artefatos do MDD, como modelos, transformaes e geradores de cdigo precisam ser
avaliados quanto aos seus atributos de qualidade relacionados reutilizao, e portanto devem
ser includos nas medies.
Questo Q2 . Os artefatos de software produzidos com a abordagem so mais reutilizveis
do que aqueles produzidos em uma abordagem no orientada a modelos?
Conforme discutido anteriormente, as mtricas para reutilizao M1 , M2 e M3 referentes
questo Q1 apresentam problemas por no considerar a natureza dos artefatos reutilizveis e
nem a maneira com que estes so reutilizados, penalizando, por exemplo, grandes sistemas e
sistemas pouco modularizados (monolticos) (MASCENA; ALMEIDA; MEIRA, 2005; MASCENA,
2007; ALMEIDA et al., 2007a).
Por este motivo, existe outra vertente que defende a idia de que melhor tentar medir a
reutilizao atravs da avaliao de atributos de qualidade que influenciam na reusabilidade de
um determinado artefato de software. Neste sentido, so sugeridas mtricas indiretas, como
manutenibilidade e complexidade (POULIN, 1994). Estas medidas talvez ofeream uma viso
melhor sobre os reais benefcios da abordagem, j tendo sido utilizadas com sucesso em outros
estudos relacionados reutilizao de software, como por exemplo o trabalho de Almeida et al.
(2007a). Assim, as seguintes mtricas foram definidas para esta questo:
M6 . Instabilidade de mdulo. De acordo com Martin (1994), o que torna um software
rgido, frgil e difcil de ser reutilizado a interdependncia entre seus mdulos. Um software
rgido se ele no puder ser facilmente modificado, isto , uma nica mudana iniciaria uma
cascata de mudanas em mdulos independentes. Alm disso, quando a extenso da mudana
no pode ser prevista pelo projetista, seu impacto no pode ser estimado, o que dificulta a
estimativa de custos, tornando o software rgido. A mtrica de instabilidade de um mdulo (I)
busca avaliar esta caracterstica do software, sendo definida da seguinte maneira:
I=
AE
AA + AE
Onde AA significa Acoplamento Aferente, ou seja, o nmero de classes fora deste mdulo
163
que dependem de classes neste mdulo, e AE significa Acoplamento Eferente, ou seja, o nmero
de classes dentro deste mdulo que dependem de classes fora deste mdulo.
A mtrica de instabilidade varia entre 0 e 1, onde I prximo a 0 indica um mdulo estvel
e I prximo a 1 indica um mdulo instvel. Como no existem muitos dados prvios para
serem utilizados como base para esta medida, neste estudo, considerou-se que mdulos com
instabilidade < 0,5 so considerados mais estveis do que a mdia, a exemplo do estudo de
Almeida et al. (2007a).
Esta mtrica pode ser utilizada tanto em artefatos de cdigo-fonte como em artefatos do
MDD, como DSLs, modelos especficos de domnio, transformaes e geradores, j que se
baseia no conceito de dependncias. Porm, enquanto existem ferramentas automatizadas para
extrair tais valores diretamente do cdigo-fonte, a coleta com relao aos demais artefatos deve
ser manual.
M7 Complexidade ciclomtica. Um aspecto crtico na Engenharia de Software se relaciona
separao de interesses e a modularizao de um sistema de software com o objetivo de
se obter mdulos bem definidos, testveis e de fcil manuteno. Durante a dcada de 70,
McCabe (1976) desenvolveu uma tcnica matemtica que prov uma base quantitativa para
modularizao e identificao de mdulos de software difceis de testar ou manter. Nesta
tcnica, uma medida de complexidade apresentada, tendo como objetivo medir e controlar o
nmero de caminhos em um programa. No contexto da reutilizao, a complexidade tem papel
fundamental, pois artefatos mais complexos possuem menor facilidade de serem reutilizados
(MASCENA, 2007; POULIN, 1994). A complexidade ciclomtica calculada a partir de um grafo
conectado que representa o fluxo de execuo de um mdulo, da seguinte maneira:
CC(G) = E N + p
onde E = nmero de arcos de um grafo, N = nmero de ns de um grafo e p = nmero de
componentes conectados.
Para esta mtrica, valores entre 1 e 10 indicam que se trata de um mdulo simples, sem
muito risco. Valores entre 11 e 20 representam mdulos moderadamente complexos. Valores
entre 21 e 50 representam alta complexidade, e valores maiores que 50 representam mdulos
completamente no-testveis e com alto risco.
Por ser aplicvel a grafos, esta mtrica pode ser utilizada diretamente em modelos visuais
do tipo grafo. Modelos textuais tambm podem ser transformados em grafos, analisando-se o
metamodelo correspondente.
164
M8 . ndice de Manutenibilidade. A manutenibilidade um atributo desejvel tanto como

uma medida instantnea como uma previso da manutenibilidade com o tempo. Esforos
para medir e rastrear a manutenibilidade tm por objetivo reduzir ou reverter a tendncia de
degradao de integridade de um sistema, e indicar quando pode ser mais barato ou menos
arriscado reconstruir do que modificar (VANDOREN, 1997). No contexto da engenharia de
domnio, ela um indicador importante da reusabilidade de um artefato (MASCENA; ALMEIDA;
MEIRA,
2005), uma vez que um domnio est constantemente em evoluo, com novas features
ou produtos sendo desenvolvidos (ALMEIDA et al., 2007a). O ndice de Manutenibilidade

(IM) busca medir a manutenibilidade de um mdulo, sendo definido da seguinte maneira
(VANDOREN, 1997):
p
IM = 171 5.2 ln(aveV ) 0.23 aveV (g0 ) 16.2 ln(aveLOC) + 50 sin( 2.4 perCM)
onde: aveV = mdia do volume Halstead V por mdulo, aveV(g) = mdia da complexidade
ciclomtica estendida por mdulo, aveLOC = mdia de linhas de cdigo por mdulo, e perCM
= mdia da porcentagem de linhas de comentrio por mdulo.
A complexidade ciclomtica discutida na mtrica M7 . O volume Halstead V de um
mdulo calculado da seguinte maneira:
V = N log2 n
onde N = nmero total de operadores + nmero total de operandos do mdulo e n = nmero
total de operadores distintos + nmero total de operandos distintos do mdulo.
Segundo esta mtrica, mdulos com IM menor do que 65 so difceis de serem mantidos,
mdulos entre 65 e 85 possuem manutenibilidade razovel e mdulos com IM maior do que 85
possuem boa manutenibilidade.
Esta mtrica normalmente utilizada em artefatos de cdigo-fonte, mas tambm pode
ser aplicada a geradores de cdigo, uma vez que os mesmos tambm possuem operadores e
operandos. Geradores baseados em templates, que so um dos focos desta abordagem, possuem
cdigo embutido e marcaes especiais que representam operaes simples, como condies e
laos. As seguintes regras so utilizadas para clculo do volume Halstead V de um gerador
baseado em template:
Variveis, trechos de cdigo contnuo e constantes so consideradas operandos;
Marcaes responsveis por uma consulta, como uma seleo de elementos de um
165
modelo, ou impresso de um determinado valor, so consideradas operadores;

Marcaes condicionais e de laos so considerados operadores; e
Trechos de cdigo embutido so analisados da mesma forma que cdigo-fonte tradicional.
Esta mtrica no pode ser aplicada a modelos, uma vez que estes no necessariamente
contm elementos que podem ser associados com operandos e operadores. Nestes casos, devem
ser utilizadas mtricas especficas para modelos.
Conforme demonstrado por Genero, Poels e Piattini (2008), Genero et al. (2007), a
manutenibilidade de um modelo determinada principalmente por sua compreensibilidade.
Neste sentido, os autores identificaram, no contexto da modelagem Entidade-Relacionamento
e diagramas de classes, que as propriedades estruturais de um modelo que so relevantes para
que um ser humano possa compreend-lo facilmente so os atributos e relacionamentos 1:N.
O tamanho de um modelo em termos do nmero de entidades no parece ser relevante para
compreensibilidade. Assim, duas mtricas foram definidas para avaliar a manutenibilidade dos
modelos nesta abordagem. Apesar de originalmente terem sido desenvolvidas para modelos
E-R e diagramas de classes, o conceito de atributos e relacionamentos est presente em vrias
linguagens do tipo grafo, e portanto podem ser aplicadas em outros tipos de modelos similares.
M9 . Nmero de Atributos. Nesta mtrica, so contados os atributos em um modelo. Em
modelos visuais (diagramas), um atributo uma propriedade textual de um elemento visual (um
cone, uma caixa ou um n de um grafo). Em modelos textuais, um atributo uma propriedade
textual de um conceito de primeira classe, conforme definido na gramtica da linguagem.
M10 . Nmero de Relacionamentos. Nesta mtrica, so contados os relacionamentos em um
modelo. Em modelos visuais (diagramas), um relacionamento representado por uma linha
entre dois elementos, ou outra representao relacional entre dois ou mais elementos, como por
exemplo a representao de conjuntos no GME (Generic Modeling Environment - Seo 2.2.2).
Em modelos textuais, um relacionamento consiste em uma referncia entre dois conceitos de
primeira classe, conforme definido na gramtica da linguagem.
Estas duas mtricas so absolutas, ou seja, sabe-se que quanto mais atributos e
relacionamentos, menos compreensvel ser um modelo, mas no se tem uma medida para
ser utilizada como parmetro para determinar se um modelo ou no compreensvel, e por
conseqncia possui alta manutenibilidade. Como valor de referncia, foi utilizada nesta tese
a mdia obtida em experimentos envolvendo diagramas E-R e UML, conforme descrito por
Genero et al. (2007), Genero, Poels e Piattini (2008):
166
NA =
NR =
42, 63 + 40, 22
= 41, 425
2
13, 13 + 8, 88 + 8 + 8, 2
= 9, 595
4
Portanto, considerou-se neste estudo que modelos com menos de 42 atributos e menos do
que 9 relacionamentos possuem maior manutenibilidade do que a mdia.
As mtricas M9 e M10 permitem a avaliao tanto de modelos visuais e textuais, como
tambm seus metamodelos, permitindo tambm avaliar a manutenibilidade das DSLs.
Questo Q3 . Os sujeitos que utilizaram a abordagem perceberam, durante as atividades
da abordagem referentes preocupao com MDD desde o incio do desenvolvimento,
algum benefcio para a implementao dos artefatos do MDD (DSLs, transformaes e
geradores de cdigo)?
Para avaliar se o uso da abordagem desde o incio do desenvolvimento produz algum
benefcio, foi realizada uma entrevista com os sujeitos que utilizaram a abordagem, com
perguntas que avaliaram se os benefcios almejados foram efetivamente percebidos e
observados pelos sujeitos. Decidiu-se por uma entrevista ao invs de um questionrio, pois
os estudos no envolveram um nmero muito grande de sujeitos, e desta forma houve mais
flexibilidade na observao dos resultados da aplicao da abordagem. A entrevista consistiu
das perguntas a seguir, com respostas em aberto:
O modelo de features ajudou na definio das linguagens especficas de domnio,

transformaes e geradores de cdigo?
A descrio da variabilidade em cenrios (casos de mudana) facilitou a definio das
linguagens especficas de domnio, transformaes e geradores de cdigo?
A identificao de candidatos a sub-domnio facilitou a identificao das reas do domnio
a serem automatizadas?
A identificao de candidatos a sub-domnio facilitou a definio das linguagens
especficas de domnio, transformaes e geradores de cdigo?
O processo investigativo baseado em decises para incluso/excluso de sub-domnios foi
utilizado? Se sim, ele facilitou o processo de desenvolvimento dos artefatos do MDD?
167
O uso das diretrizes e padres arquiteturais especficos para reutilizao e MDD facilitou
o desenvolvimento dos artefatos do MDD e da arquitetura do domnio?
A etapa de avaliao arquitetural ajudou a identificar falhas antes de a implementao ser
iniciada?
As diretrizes de implementao de DSLs, transformaes e geradores de cdigo
facilitaram a implementao dos artefatos do MDD?
O formato de documentao proposto foi adequado, auxiliando na descrio dos artefatos
reutilizveis desenvolvidos?
Quais foram as vantagens de se utilizar a abordagem de MDD no desenvolvimento?
Quais foram as desvantagens de se utilizar a abordagem de MDD no desenvolvimento?
Questo Q4 . Os sujeitos que utilizaram a abordagem tiveram dificuldades que causaram
prejuzo ao desenvolvimento, em termos de atrasos e curva de aprendizado?
Para avaliar as dificuldades de utilizao da abordagem, foram includas as seguintes
perguntas, na entrevista realizada na questo Q3 , referente s dificuldades percebidas pelos
sujeitos da abordagem:
Quais foram as dificuldades para o aprendizado da abordagem?
Quais foram as dificuldades para definio do modelo de features?
Quais foram as dificuldades para descrio da variabilidade em cenrios (casos de
mudana)?
Quais foram as dificuldades para a identificao de candidatos a sub-domnio?
Quais foram as dificuldades para realizar o processo investigativo baseado em decises
para incluso/excluso de sub-domnios?
Cite outras dificuldades percebidas durante a utilizao da abordagem de MDD desde o
incio do desenvolvimento.
9.1.2
Hipteses
Como ensina Albert Einstein, fsico alemo que viveu entre 1879 e 1955: Nenhuma
quantidade de experimentao pode provar que estou certo; um nico experimento pode provar
168
que estou errado. Com base nesta premissa cientfica, comum trabalhar-se com a idia de
uma hiptese nula, ou seja, define-se como hiptese algo que o experimentador deseja rejeitar,
e projeta-se um ou mais experimentos que tm como objetivo testar esta hiptese (WOHLIN et
al.,
2000).
Assim, a hiptese nula para esta avaliao pode ser descrita com base nas questes e
mtricas definidas anteriormente:

H0a : analisando-se um mesmo projeto desenvolvido com e sem a abordagem, as mtricas
de porcentagem de reutilizao (M1 ), razo de reutilizao (M2 ), porcentagem de
reutilizao no-desejada (M3 ), porcentagem de reutilizao gerada (M4 ) e razo entre
especificao e cdigo (M5 ), analisadas conjuntamente, no evidenciam nenhum aumento
ou melhoria na reutilizao de software no projeto que utilizou a abordagem.
H0b : os artefatos de software produzidos com a abordagem no so mais reutilizveis do que
aqueles produzidos em uma abordagem no orientada a modelos
(M6 ) Instabilidade de mdulo: IcomAbordagem IsemAbordagem
(M7 ) Complexidade Ciclomtica: CCcomAbordagem CCsemAbordagem
(M8 ) ndice de Manutenibilidade: IMcomAbordagem IMsemAbordagem
(M9 ) Nmero de Atributos: NA 21
(M10 ) Nmero de Relacionamentos: NR 9
H0c : os sujeitos que utilizaram a abordagem no perceberam, com as atividades da abordagem
referentes preocupao com MDD desde o incio do desenvolvimento, nenhum
benefcio para a implementao dos artefatos do MDD (DSLs, transformaes e
geradores de cdigo).
H0d : os sujeitos que utilizaram a abordagem tiveram dificuldades que causaram prejuzo ao
desenvolvimento, em termos de atrasos e curva de aprendizado.
Para a parte H0a desta hiptese no foram definidos itens individuais para cada mtrica, pois
as mesmas no podem ser avaliadas de forma isolada para determinar se houve de fato aumento
na reutilizao. Portanto, foi feita uma anlise descritiva considerando-se todas as mtricas
em conjunto, buscando rejeitar a hiptese nula. Com relao parte H0b , foram definidas
comparaes contrrias ao que se deseja demonstrar, com exceo das mtricas M9 e M10 , pois
no desenvolvimento tradicional (sem abordagem), no foram produzidos modelos, e portanto
apenas a mtrica M8 foi considerada suficiente para avaliar a manutenibilidade. Assim, as
169
comparaes de M9 e M10 foram feitas com os valores estabelecidos como referncia. Para as
partes H0c e H0d no foi definida nenhuma mtrica, pois a anlise foi qualitativa.
A rejeio da hiptese nula deve ser feita em favor de uma hiptese alternativa, que
normalmente representa a negao da hiptese nula. Neste cenrio, as seguintes alternativas
so definidas:
H1a : analisando-se um mesmo projeto desenvolvido com e sem a abordagem, as mtricas

de porcentagem de reutilizao (M1 ), razo de reutilizao (M2 ), porcentagem de
reutilizao no-desejada (M3 ), porcentagem de reutilizao gerada (M4 ) e razo entre
especificao e cdigo (M5 ), analisadas conjuntamente, possuem evidncia ou indcios
sobre o aumento e/ou melhoria no nvel de reutilizao de software no projeto que utilizou
a abordagem.
H1b : os artefatos de software produzidos com a abordagem so mais reutilizveis do que
aqueles produzidos em uma abordagem no orientada a modelos
(M6 ) Instabilidade de mdulo: IcomAbordagem < IsemAbordagem
(M7 ) Complexidade Ciclomtica: CCcomAbordagem < CCsemAbordagem
(M8 ) ndice de Manutenibilidade: IMcomAbordagem > IMsemAbordagem
(M9 ) Nmero de Atributos: NA < 21
(M10 ) Nmero de Relacionamentos: NR < 9
H1c : os sujeitos que utilizaram a abordagem perceberam, com as atividades da abordagem
referentes preocupao com MDD desde o incio do desenvolvimento, algum benefcio
para a implementao dos artefatos do MDD (DSLs, transformaes e geradores de
cdigo).
H1d : os sujeitos que utilizaram a abordagem no tiveram dificuldades que causaram prejuzo
ao desenvolvimento, em termos de atrasos e curva de aprendizado.
Estritamente falando, apenas as partes HXa e HXb so hipteses nulas/alternativas vlidas,

pois pode-se teoricamente aplicar as mtricas e tcnicas estatsticas para determinar a rejeio
da hiptese nula ou no. Porm, as partes HXc e HXd foram mantidas como indicativo sobre o
que est sendo avaliado.
170
9.2
Descrio dos projetos utilizados nos estudos empricos e

sua execuo
Foram realizados trs estudos envolvendo a aplicao da abordagem em projetos de

engenharia de domnio. Para o primeiro estudo, foi escolhido o domnio de aplicaes de
autoria de contedo para a Web, por se tratar de um domnio relativamente simples de ser
implementado manualmente e pela disponibilidade de especialistas para eventuais consultas.
O segundo estudo foi realizado na indstria, durante um estgio de doutorado, e a escolha do
domnio envolvido, de aplicaes distribudas baseadas em computao em nuvem, no foi feita
pelo autor desta tese, mas sim pelos lderes do grupo no qual o estgio foi realizado. O terceiro
estudo, tambm realizado na indstria, envolveu o domnio de eventos cientficos, e a escolha
se deu por convenincia e proximidade da empresa ao grupo de pesquisa.
Os estudos so comparativos, ou seja, visam comparar os resultados do desenvolvimento
realizado sem a abordagem com o desenvolvimento realizado com a abordagem. Para essa
comparao, foram utilizadas implementaes de exemplo desenvolvidas antes do uso da
abordagem, que no contemplavam modelos ou qualquer tipo de artefato relacionado ao MDD,
e as implementaes desenvolvidas com a abordagem, que incluem uma arquitetura preparada
para o MDD, alm dos artefatos especficos para este contexto, como DSLs, transformaes e
geradores de cdigo.
A ordem de execuo dos estudos a mesma ordem em que os mesmos so apresentados
neste captulo. Essa ordem pouco influenciou os resultados, pois cada estudo foi realizado
aps a concluso da definio da abordagem, ou seja, no foram feitas modificaes em suas
atividades durante os estudos. Tambm foram realizados em domnios diferentes, utilizando
tecnologias diferentes de implementao e MDD, de modo que foi possvel reaproveitar pouco
conhecimento diretamente de um estudo para outro, seja com relao ao domnio ou com
relao s tecnologias empregadas.
A seguir so apresentados mais detalhes sobre cada estudo.
9.2.1
Autoria de contedo para a Web
O primeiro estudo foi realizado em ambiente acadmico, e envolveu o domnio de

aplicaes de autoria de contedo para a Web. So aplicaes onde um administrador publica
contedo a ser visualizado por muitos usurios, como por exemplo portais de notcias, pginas
pessoais, fruns e blogs.
Trata-se de um domnio tcnico, envolvendo os requisitos de
persistncia e navegao na Web.
171
Neste estudo, as linguagens especficas de domnio, geradores, a arquitetura e a

implementao de referncia foram desenvolvidos a partir do zero, utilizando a abordagem
definida nesta tese. Foi executado pelo autor desta tese, com a ajuda de especialistas de domnio.
Inicialmente, foram realizados estudos sobre as tecnologias de implementao necessrias, e em
seguida a abordagem foi aplicada no desenvolvimento dos artefatos do domnio.
Foi desenvolvida uma infra-estrutura composta de artefatos de software gerados e
no-gerados, em uma arquitetura em trs camadas. Foram desenvolvidas quatro linguagens
especficas de domnio: uma linguagem visual para persistncia, uma linguagem textual para
navegao, uma linguagem textual para a produo de relatrios e uma linguagem visual para
configurao das features presentes no produto. Tambm foram desenvolvidas transformaes
e geradores de cdigo que produzem aplicaes completas, segundo as especificaes dos
modelos.
O Quadro 10 mostra um resumo dos dados relevantes sobre este estudo.
Domnio
Local
Participantes
Tempo total
Nmero de DSLs
Nmero de artefatos de gerao
(transformaes e geradores)
Tamanho total (LOC)
artefatos de gerao
Tamanho total (LOC)
Nmero de features
do domnio
Tecnologias de implementao
Tecnologias MDD
Autoria de contedo para Web

ICMC/USP - So Carlos/SP
1 (autor)
3 meses (dedicao integral)
4 (persistncia, navegao, relatrios e features)
38
1610
5941
15
Apache Tomcat, MySQL, Java,
JSP, JSTL, Servlets, XML, SQL,
Eclipse (verso Ganymede) + WebTools plug-in
Eclipse (verso Ganymede)
EMF (Eclipse Modeling Framework)
GMF (Graphical Modeling Framework)
JET (Java Emitter Templates)
openArchitectureWare
Quadro 10: Dados sobre o estudo envolvendo o domnio de autoria de contedo para Web
9.2.2
Aplicaes distribudas baseadas em computao em nuvem
O segundo estudo foi realizado em ambiente industrial, envolvendo o domnio de aplicaes

distribudas baseadas em computao em nuvem. As principais caractersticas deste domnio
so o alto grau de incerteza sobre a topologia da aplicao, a heterogeneidade dos ambientes
e infra-estrutura e o alto grau de cooperao entre os componentes distribudos. Este estudo
172
foi realizado durante um estgio de doutorado realizado pelo autor da tese nos laboratrios da
Microsoft Research, em Redmond, Estados Unidos (LUCRDIO; JACKSON; SCHULTE, 2008).
Este domnio j vinha sendo explorado pelos pesquisadores da Microsoft Research, que
desenvolveram uma teoria baseada em modelagem de negcios e um conjunto de trs linguagens
especficas para este objetivo (JACKSON; SCHULTE, 2008): uma linguagem visual para descrever
os dados do sistema, uma linguagem visual para descrever as caractersticas dos tipos de
elementos distribudos, sua conectividade e quais dados os mesmos possuem, e uma linguagem
visual para descrever a semntica das operaes de manipulao dos dados. O aspecto mais
interessante desta especificao que os modelos de dados e operaes no precisam se
preocupar com a localizao dos dados e nem que tipo de elemento distribudo responsvel por
sua manuteno. A teoria diz que possvel gerar cdigo responsvel pela execuo distribuda
das operaes e verificao de integridade global do sistema, de acordo com regras especficas
definidas nos modelos.
Trata-se de um domnio predominantemente tcnico, envolvendo os aspectos de execuo
distribuda e computao em nuvem, mas com um componente de negcios, uma vez que as
regras de negcio podem ser definidas utilizando a linguagem de modelagem de operaes.
Neste estudo, realizado pelo autor da tese junto com um pesquisador da Microsoft Research,
foi utilizada a abordagem definida nesta tese, porm com menor foco na anlise, uma vez que j
existiam verses iniciais das linguagens especficas de domnio. Aps o estudo das tecnologias
de implementao envolvidas, estas verses iniciais das linguagens foram refinadas, e passou-se
para as fases de projeto e implementao do domnio, onde foram desenvolvidos, a partir do
zero:
A arquitetura para o domnio;
Uma implementao de referncia baseada em uma infra-estrutura responsvel por
algumas das funes bsicas de comunicao e distribuio; e
Um conjunto de transformaes e geradores que produzem uma aplicao completa no
topo da infra-estrutura.
O Quadro 11 resume alguns dados relevantes sobre este estudo.
9.2.3
Eventos cientficos
O terceiro estudo foi realizado tambm em ambiente industrial, e envolveu o domnio

de eventos cientficos. Este domnio engloba sistemas de submisso e inscrio em eventos,
173
Domnio
Local
Participantes
Tempo total
Nmero de DSLs
Tamanho total (LOC)
artefatos de gerao
Tamanho total (LOC)
Nmero de features
do domnio
Tecnologias MDD

Microsoft Research - Redmond/WA - USA
2 (incluindo o autor)
3 meses (dedicao integral)
3 (dados, conectividade e operaes)
29
2847
12127
Microsoft Visual Studio 2008, Microsoft SQL Server, C#, .NET,
.NET Remoting, Microsoft Volta, PNRP (Peer Name Resolution Protocol)
DBML (DataBase Modeling Language), Microsoft LINQ to SQL
Microsoft Visual Studio 2008
Microsoft Text Templates
GME (Generic Modeling Environment)
Quadro 11: Dados sobre o estudo envolvendo o domnio de aplicaes distribudas baseadas
em computao em nuvem
mala direta, gerenciamento de secretaria e gerenciamento de feiras. Trata-se de um domnio
de negcios, e a reutilizao envolve principalmente regras de negcio relacionadas ao
gerenciamento de eventos cientficos.
Este estudo foi feito em uma empresa situada em So Carlos que trabalha com uma linha de
produtos deste domnio, realizando desenvolvimento e customizao dos produtos do domnio,
muitas vezes vendendo os mesmos de forma integrada. O gerenciamento da variabilidade
nesta linha realizado com a ajuda de alguns componentes reutilizveis, mas principalmente
utilizando tcnicas de gerenciamento de configurao. Assim, cada sistema vendido produz
diferentes verses que implementam as diferentes variabilidades do domnio. A reutilizao
ocorre recuperando-se uma determinada verso que seja prxima dos requisitos do cliente, e
modificando-a para satisfazer aos requisitos.
Aps o contato inicial, foi estabelecido que o estudo seria realizado como um projeto
paralelo na empresa, por uma equipe composta de dois funcionrios com dedicao parcial,
com o auxlio e orientao do autor desta tese. Como neste estudo o autor no participaria do
desenvolvimento, foi necessrio um perodo de treinamento, realizado da seguinte forma:
Em um primeiro momento, um dos participantes do projeto realizou um curso de 20
horas sobre desenvolvimento orientado a modelos, oferecido no ICMC/USP So Carlos
e ministrado pelo autor desta tese2 ;
material deste curso encontra-se disponvel no endereo http://www.icmc.usp.br/~lucredio/
downloads/files/cursoMDD/
2O
174
Em seguida, o autor da tese realizou um treinamento interno de 4 horas com os

participantes, apresentando as atividades e detalhes da abordagem; e
O autor da tese disponibilizou como exemplo os documentos e artefatos produzidos

durante o estudo do domnio Web, que ficou disposio da equipe para consulta.
Aps este perodo, o autor desta tese permaneceu disponvel para sanar dvidas e responder
questionamentos durante todo o projeto, uma vez que se tratam de conceitos novos para a
empresa e os participantes.
Aps o treinamento, a equipe utilizou a abordagem para realizar a anlise, projeto e
implementao do domnio. Uma vez que j existia a linha de produtos implantada na empresa,
o projeto arquitetural se resumiu principalmente organizao da infra-estrutura de gerao de
cdigo de forma integrada aos artefatos existentes na linha de produtos. E na implementao
do domnio, foi utilizado um produto concreto como implementao de referncia.
Como resultado, foram definidas duas linguagens especficas de domnio: uma linguagem
textual para a definio das features, e a sua configurao atravs de atributos especficos para
a linha de produtos, e uma linguagem textual para a definio de formatos de certificados,
um sub-domnio identificado pela equipe durante a anlise. Foram tambm construdos os
geradores responsveis por configurar novos produtos e produzir cdigo customizado.
O Quadro 12 resume alguns dados relevantes sobre este estudo.
Domnio
Local
Participantes
Tempo total
Nmero de DSLs
Tamanho total (LOC)
artefatos de gerao
Tamanho total (LOC)
Nmero de features
do domnio
Tecnologias MDD
Eventos cientficos
Aptor Consultoria e Desenvolvimento de Software Ltda.
2
2 meses (dedicao parcial)
2 (configurao e certificados)
8
1375
71873
29
Adobe DreamWeaver, PHP, MySQL
Eclipse (verso Ganymede)
EMF (Eclipse Modeling Framework)
JET (Java Emitter Templates)
Quadro 12: Dados sobre o estudo envolvendo o domnio de eventos cientficos
175
9.3
Coleta dos dados
A coleta das mtricas foi realizada com o auxlio de diferentes ferramentas. Para os projetos
baseados em cdigo Java, foram utilizadas as ferramentas Eclipse Metrics3 (Instabilidade
e Complexidade Ciclomtica) e JHawk4 (ndice de Manutenibilidade). Estas ferramentas
trabalham com cdigo-fonte em Java. Para arquivos JSP, foi utilizado o cdigo Java de seus
Servlets correspondentes. Os templates do JET so convertidos em Java, e portanto estas
ferramentas tambm puderam ser utilizadas.
Para cdigo C#, no foi encontrada nenhuma ferramenta disponvel capaz de calcular
estas mtricas. Porm, foi utilizada a ferramenta Net2Java5 , um plug-in do NetBeans capaz
de converter cdigo escrito em C# para Java. Como so linguagens bastante similares, a
converso realizada de forma quase direta. Alm disso, no foi necessrio executar o cdigo
convertido. As mtricas so estruturais, e se baseiam em dependncia entre classes, operadores,
operandos, estruturas de laos e condies, e outros elementos do cdigo que so comuns a
ambas linguagens. Assim, o nico trabalho foi corrigir alguns erros da converso, visando
deixar o cdigo Java compilvel, requisito das ferramentas Eclipse Metrics e JHawk, e estas
foram utilizadas para extrair as mtricas.
O cdigo PHP utilizado no terceiro estudo no orientado a objetos, e no foi encontrada
nenhuma ferramenta capaz de extrair estas mtricas para este tipo de cdigo, e nem ferramentas
automatizadas de converso. Uma vez que a quantidade de cdigo deste projeto muito
grande, a coleta manual das mtricas de Instabilidade, Complexidade Ciclomtica e ndice de
Manutenibilidade, que exigem uma inspeo detalhada do cdigo, no foi realizada no terceiro
estudo.
Para os demais artefatos, como metamodelos, modelos e geradores baseados em templates
interpretados, como os templates do openArchitectureWare, foi necessrio realizar o clculo
manual, como por exemplo a contagem de acoplamento aferente e eferente, anlise de grafos
dos programas e a contagem do nmero de atributos e relacionamentos em modelos. Como
o nmero e tamanho destes artefatos consideravelmente reduzido, este trabalho foi realizado
sem dificuldades.
As anlises qualitativas, atravs de entrevista, somente foram realizadas no terceiro estudo,
uma vez que nos dois primeiros estudos o autor da tese participou do desenvolvimento.
Aps a coleta dos dados, os mesmos foram analisados utilizando estatstica descritiva
3 http://metrics.sourceforge.net/
4 http://www.virtualmachinery.com/jhawkprod.htm
5 https://net2java.dev.java.net/
176
atravs de grficos do tipo box plot (FENTON; PFLEEGER, 1998), que permitem visualizar a
disperso e balanceamento das amostras. Box plots podem ser utilizados de diferentes formas
(WOHLIN et al., 2000). Nesta tese, foi utilizada a abordagem definida por Fenton e Pfleeger
(1998), que propem a utilizao do seguinte clculo para anlise das extremidades:
Lin f erior = q1 (q3 q1 ) 1.5
Lsuperior = q3 + (q3 q1 ) 1.5
onde q1 e q3 so o primeiro (25%) e terceiro (75%) quartis, respectivamente.
Dado um conjunto de dados seguindo uma distribuio normal, teoricamente no deveriam
ser encontrados elementos abaixo do limite inferior e acima do limite superior. Caso existam,
estes devem ser analisados e deve-se decidir se os mesmos sero includos ou excludos da
anlise. Por exemplo, quando o elemento fora dos limites se tratar de cdigo-fonte, deve-se
analisar se o mesmo segue os mesmos padres e formatos utilizados na maioria do cdigo. Se
este elemento possuir muitas linhas de comentrio ou se for um cdigo reutilizado de outro
projeto sem uma reformatao, ele pode no representar a realidade do cdigo produzido, e
deve ser excludo da anlise. Por outro lado, podem existir elementos de cdigo extremamente
complexos ou extremamente simples, devido prpria natureza do prprio domnio. Nestes
casos, o elemento deve ser mantido.
Para cada estudo, foram analisados somente os artefatos efetivamente utilizados pelo
desenvolvedor. Ou seja, artefatos de cdigo completamente gerados e que no precisam ser
modificados ou manipulados pelo desenvolvedor no foram includos nas mtricas. Porm, em
alguns grficos, o cdigo gerado foi tambm analisado para propiciar melhor caracterizao da
reutilizao que est ocorrendo.
A seguir so apresentados os resultados para cada estudo, de forma individual, junto com
uma discusso geral sobre os resultados.
9.4
9.4.1
Resultados e discusso
Autoria de contedo para a Web
A Figura 25 mostra os valores das mtricas de reutilizao de software obtidas dos artefatos
produzidos com e sem a abordagem. Nota-se um aumento significativo tanto na porcentagem
de reutilizao como na razo de reutilizao.
Tambm pode-se observar a reduo da
177
porcentagem de reutilizao no desejada para zero.
Figura 25: Comparao entre as mtricas de reutilizao para o estudo do domnio de autoria
de contedo para a web
Analisando-se os dados, verificou-se que a porcentagem de reutilizao obtida
exclusivamente com gerao de cdigo foi de 47,03%, ou seja, quase metade do cdigo
reutilizado provm de um gerador. Foi verificada uma razo entre especificao e cdigo de
1:16,34, ou seja, para cada elemento de especificao so geradas, em mdia, pouco mais de 16
linhas de cdigo.
A Figura 26 mostra os valores das mtricas indiretas de reusabilidade: instabilidade,
complexidade e manutenibilidade obtidas dos artefatos produzidos com e sem a abordagem.
Pode-se verificar que no houve alterao significativa nas distribuies da mtrica de
instabilidade. A complexidade, por sua vez, aumentou de forma perceptvel, com muitos
artefatos desenvolvidos com a abordagem sendo mais complexos do que o mximo obtido sem
a abordagem. Os ndices de manutenibilidade tambm sofreram uma reduo com o uso da
abordagem.
A Figura 27 analisa de forma mais aprofundada as medidas de instabilidade obtidas com a
abordagem6 . Pode-se notar que o cdigo gerado mais instvel do que o cdigo no-gerado, em
alguns casos chegando ao limite mximo desta mtrica (1). Os artefatos de gerao de cdigo
(transformaes e geradores) apresentam uma distribuio intermediria s dos cdigos gerado
e no gerado, porm de forma mais concentrada em torno do valor central da mtrica (0,5).
Os modelos utilizados na abordagem tiveram sua instabilidade abaixo de 0,5, sendo em geral
menos instveis do que os demais artefatos.
6 Observao:
neste grfico, o cdigo gerado foi includo, apesar se ser um artefato no utilizado diretamente
pelo desenvolvedor. Isto foi feito para ajudar na caracterizao da reutilizao apenas. O mesmo acontece em
outros grficos deste captulo.
178
Figura 26: Comparao entre as mtricas indiretas de reusabilidade para o estudo do domnio
de autoria de contedo para a web
Figura 27: Distribuies de instabilidade de mdulo nos diferentes tipos de artefatos produzidos
com a abordagem, no estudo de caso do domnio de autoria de contedo para web
A Figura 28 analisa de forma mais aprofundada as medidas de complexidade ciclomtica

obtidas com a abordagem. Pode-se notar que o cdigo gerado semelhante, na mdia, ao
cdigo no gerado, porm a distribuio do cdigo no gerado est um pouco mais concentrada.
Os demais artefatos, incluindo transformaes, geradores e modelos, so consideravelmente
mais complexos do que o cdigo, com alguns valores acima do limite considerado como o de
mdulos simples (10).
A Figura 29 analisa de forma mais aprofundada os ndices de manutenibilidade obtidos
com a abordagem. Pode-se notar que os elementos de gerao de cdigo (transformaes e
geradores) possuem menor ndice de manutenibilidade do que o cdigo, tanto gerado como
no-gerado, que apresentaram distribuies prximas destas mtricas. O cdigo gerado, porm,
apresenta valores ligeiramente maiores do ndice de manutenibilidade.
Para os modelos, a manutenibilidade foi analisada atravs do nmero de atributos e de
179
Figura 28: Distribuies de complexidade ciclomtica nos diferentes tipos de artefatos

produzidos com a abordagem, no estudo de caso do domnio de autoria de contedo para web
Figura 29: Distribuies do ndice de manutenibilidade nos diferentes tipos de artefatos

produzidos com a abordagem, no estudo de caso do domnio de autoria de contedo para web
relacionamentos. Conforme mostra a Figura 30, os modelos utilizados para gerao de cdigo
(metamodelos e modelos auxiliares) possuem poucos atributos, permanecendo completamente
abaixo do limite considerado (42). Tambm possuem poucos relacionamentos, com o terceiro
quartil sendo similar ao limite considerado (9). J os modelos utilizados como especificao
possuem mais atributos e relacionamentos. A mdia do nmero de atributos coincide com o
limite considerado (42), enquanto o nmero de relacionamentos tem distribuio bastante acima
do limite considerado (9).
Discusso
O primeiro e mais evidente resultado observado o maior nmero de linhas de cdigo
reutilizadas com a abordagem, alm de uma baixa taxa de reutilizao no desejada. Uma
primeira explicao a de que geradores produzem bastante cdigo redundante, e por isso o
nmero de linhas naturalmente maior. Esta afirmao est prxima da realidade deste estudo,
j que um dos itens importantes na identificao de candidatos a sub-domnio a existncia de
180
Figura 30: Distribuies do nmero de atributos e do nmero de relacionamentos nos modelos

utilizados com a abordagem, no estudo de caso do domnio de autoria de contedo para web
trechos repetidos de cdigo, como ressaltado por Knodel et al. (2005) e discutido na atividade
AD.3 desta abordagem (Captulo 5). Neste estudo de caso, observa-se a existncia de diversos
arquivos e trechos de cdigo parecidos sendo produzidos por geradores.
Vale ressaltar que esta repetio no poderia ser facilmente resolvida atravs de
componentes ou outras estruturas de cdigo, uma vez que apesar de serem basicamente
repetidos, os trechos diferem em muitos pontos, e so resultados de inmeros parmetros e
informaes sobre o domnio. Como resultado, a tentativa de se implementar componentes
genricos que realizam estas variabilidades iria resultar em software extremamente complexo
e difcil de ser mantido. A nica opo, portanto, copiar os trechos parecidos e modific-los
manualmente, abordagem seguida no desenvolvimento tradicional.
Analisando os artefatos produzidos, nota-se que, na maioria deles, exatamente esta tarefa
de cpia e modificao manual que est sendo automatizada neste caso. A diferena entre os
nveis de reutilizao com e sem a abordagem (cerca de 50%) corresponde aproximadamente
porcentagem de reutilizao obtida por gerao (47,03%). Ou seja, o que est sendo gerado o
cdigo que implementa a variabilidade que no pode ser automatizada em componentes, e foi
construdo manualmente sem a abordagem.
Outro dado que refora este indcio o aumento da complexidade e a reduo da
manutenibilidade observados quando a abordagem utilizada. Estas diferenas podem ser
vistas de forma geral (Figura 26), mas so particularmente ntidas quando se avalia os diferentes
tipos de artefatos do MDD individualmente (Figuras 27, 28 e 29). Os artefatos de gerao
de cdigo e modelos de domnio so consideravelmente mais complexos e difceis de manter
do que o restante do cdigo. Observando-se os artefatos, nota-se que isto se deve ao grande
nmero de instrues condicionais, laos, e a existncia de repetidas consultas aos modelos
181
que so feitas nas transformaes e geradores. Ou seja, o grande nmero de parmetros

citados anteriormente como necessrios para realizar a variabilidade em um componente foram
migrados para os artefatos do MDD, tornando-os complexos e difceis de manter. No entanto,
estes artefatos so modificados muito raramente, pois uma vez testados e validados, somente
precisam ser alterados para efetuar correes de erros ou evoluo no domnio.
Alm disso, e esta a principal diferena entre um gerador e um componente, um gerador
no efetivamente reutilizado no software final, e sim o produto de sua gerao de cdigo, com
caractersticas de reusabilidade prximas ao cdigo no gerado. J os modelos, apesar de no
geral serem mais complexos e difceis de manter do que o cdigo, so relativamente pequenos
e em nmero reduzido, o que compensa sua complexidade.
Enfim, o que se observa neste estudo que ocorreu um aumento da reutilizao, em
detrimento da simplicidade e facilidade de manuteno de alguns de seus artefatos.
Em sistemas mais simples, pode no valer a pena o trabalho extra de se desenvolver
uma infra-estrutura deste tipo. Em outras palavras, mais fcil e simples codificar do que
especificar e gerar cdigo. Porm, em sistemas grandes os benefcios do volume de reutilizao
podem ser muito grandes para serem ignorados. Considere por exemplo construir um sistema
envolvendo milhares de telas de cadastros, todas parecidas e similares, muitas delas com
detalhes e customizaes necessrias. A complexidade extra neste caso pode ser um preo
baixo a ser pago.
9.4.2
A Figura 31 mostra os valores das mtricas de reutilizao de software obtidas dos artefatos
produzidos com e sem a abordagem.
A exemplo do domnio web, porm em menor grau, observa-se um aumento significativo
na porcentagem de reutilizao e na razo de reutilizao. Nota-se tambm que a porcentagem
de reutilizao no desejada caiu alguns pontos percentuais quando a abordagem foi utilizada.
A porcentagem de reutilizao obtida com gerao de cdigo neste estudo foi similar ao
estudo anterior, atingindo 42,71%. A razo entre especificao e cdigo foi um pouco maior,
atingindo 1:26,35, ou seja, os geradores deste estudo produzem mais cdigo para cada elemento
de especificao do que os do estudo anterior.
A Figura 32 mostra os valores das mtricas indiretas de reusabilidade: instabilidade,
complexidade e manutenibilidade obtidas dos artefatos produzidos com e sem a abordagem.
Pode-se verificar que no houve alterao significativa nas distribuies das mtricas de
182
Figura 31: Comparao entre as mtricas de reutilizao para o estudo do domnio de aplicaes
distribudas baseadas em computao em nuvem
instabilidade e ndice de manutenibilidade. A complexidade, por sua vez, apresentou uma
discreta reduo.
Figura 32: Comparao entre as mtricas indiretas de reusabilidade para o estudo do domnio
de aplicaes distribudas baseadas em computao em nuvem
A Figura 33 analisa de forma mais aprofundada as medidas de instabilidade obtidas com
a abordagem. Pode-se notar que o cdigo gerado similar, na mdia, ao cdigo no gerado.
Porm a distribuio referente ao cdigo gerado est mais concentrada ao redor do valor mdio
desta mtrica (0,5). Os artefatos de gerao, por sua vez, esto concentrados em um ponto que
representa baixa instabilidade. Com relao aos modelos, neste caso somente um modelo foi
utilizado, e portanto a mtrica de instabilidade permaneceu no valor intermedirio (0,5).
A Figura 34 analisa de forma mais aprofundada as medidas de complexidade ciclomtica
183
Figura 33: Distribuies de instabilidade de mdulo nos diferentes tipos de artefatos produzidos
com a abordagem, no domnio de aplicaes distribudas baseadas em computao em nuvem
obtidas com a abordagem. Pode-se notar que o cdigo gerado apresenta maior complexidade
em relao ao cdigo no gerado. Os artefatos de gerao so ligeiramente mais complexos
do que o cdigo no gerado, e os modelos apresentam complexidade baixa. Com exceo do
cdigo gerado, todos os artefatos permaneceram dentro do limite que indica simplicidade (10).
Figura 34: Distribuies de complexidade ciclomtica nos diferentes tipos de artefatos

produzidos com a abordagem, no domnio de aplicaes distribudas baseadas em computao
em nuvem
A Figura 35 analisa de forma mais aprofundada os ndices de manutenibilidade obtidos

com a abordagem. No existem diferenas notveis na distribuio, porm h uma leve queda
na manutenibilidade do cdigo gerado e nos artefatos de gerao, com relao ao cdigo gerado.
A Figura 36 mostra que as quantidades de atributos de ambos os tipos de modelo (gerao e
especificao) permaneceram abaixo do limite estipulado (42). O nmero de relacionamentos,
porm, excedeu consideravelmente o limite (9) nos modelos de gerao, e de forma moderada
no caso dos modelos de especificao.
184
Figura 35: Distribuies do ndice de manutenibilidade nos diferentes tipos de artefatos

produzidos com a abordagem, no domnio de aplicaes distribudas baseadas em computao
em nuvem
Figura 36: Distribuies de nmeros de atributos e relacionamentos nos modelos utilizados com
a abordagem, no domnio de aplicaes distribudas baseadas em computao em nuvem
Discusso
Neste domnio, a exemplo do domnio Web mas de forma menos acentuada, tambm foram
observados aumentos no nvel e na razo de reutilizao de linhas de cdigo, e uma baixa taxa
de reutilizao no desejada. Os mesmos motivos discutidos no estudo do domnio Web se
aplicam a este caso, sendo observados diversos artefatos com alto grau de similaridade. Esta
parece ser uma tendncia de domnios tcnicos, onde a tnica est em resolver problemas de
mais baixo nvel de forma repetida e constante, como a persistncia e navegao, no caso do
domnio Web, e distribuio, no caso deste domnio. Neste caso, inclusive, foi observada uma
razo ainda maior entre especificao e cdigo (1:26,35), o que indica que os geradores esto
sendo mais produtivos.
Porm, enquanto no estudo anterior os artefatos de gerao de cdigo e os modelos so
mais complexos do que o cdigo, aqui foi observado o efeito inverso. O cdigo, tanto o
gerado como o no gerado, mais instvel, complexo e difcil de manter do que os artefatos de
185
gerao. Isto se explica pela complexidade natural do domnio, uma vez que a computao em
nuvem traz muitos desafios no triviais, como o clculo distribudo de invariantes do sistema,
determinao de cliques maximais, descoberta dinmica de servios e execuo distribuda
(LUCRDIO; JACKSON; SCHULTE, 2008). Detalhes sobre estes assuntos ficam encapsulados no
somente em componentes, mas tambm nos geradores, de forma que um desenvolvedor pode
produzir aplicaes complexas mesmo sem conhecer a fundo todas as tecnologias envolvidas.
Em outras palavras, em contraste com o estudo anterior, neste domnio mais fcil e simples
especificar do que codificar.
Assim, o que se observou neste estudo foi, alm do aumento na reutilizao, um aumento
na reusabilidade dos artefatos do domnio, percebido de forma indireta com a reduo da
instabilidade, complexidade e dificuldade de manuteno.
Assim, enquanto no estudo anterior verificou-se que o uso da abordagem pode trazer
benefcios em termos de volume de reutilizao, aqui observa-se que a abordagem pode
simplificar o desenvolvimento, abstraindo detalhes e complexidades inerentes a este domnio
complexo.
9.4.3
Eventos cientficos
A Figura 37 ilustra uma comparao entre os nveis de reutilizao obtidos com e sem
a abordagem, para o estudo envolvendo o domnio de eventos cientficos.
Nota-se que,
ao contrrio dos estudos anteriores, com a abordagem tem-se menores taxas e razes de
reutilizao. Porm, a taxa de reutilizao no desejada foi reduzida para menos da metade.
Alm disso, neste domnio nota-se uma maior diferena entre a porcentagem de reutilizao e
a razo de reutilizao, do que nos domnios anteriores. Isto porque h um grande nmero de
artefatos que so reutilizados e modificados minimamente (reutilizao do tipo caixa-branca),
como resultado do processo de customizao.
A porcentagem de reutilizao obtida com gerao de cdigo neste estudo foi bastante
reduzida, sendo medida como 3,99%. A razo entre especificao e cdigo tambm foi
significativamente menor, atingindo 1:8,14, ou seja, os geradores deste estudo produzem menos
cdigo para cada elemento de especificao do que os dos estudos anteriores.
Conforme discutido anteriormente, neste estudo no foram coletadas mtricas para os
artefatos de cdigo, por motivos de falta de ferramentas adequadas. Porm, foram analisados
os atributos dos artefatos de gerao, para efeitos de comparao com os outros estudos. Esta
comparao apresentada na Figura 38. Pode-se notar que, em termos de instabilidade, os
186
Figura 37: Comparao entre as mtricas de reutilizao para o estudo do domnio de eventos
cientficos
artefatos deste estudo esto mais prximos aos do estudo envolvendo o domnio Web, porm
ligeiramente menos instveis. Em termos de complexidade ciclomtica, a distribuio ficou
mais concentrada e ligeiramente superior que os outros estudos. E o ndice de manutenibilidade
se mostrou notavelmente inferior aos outros estudos.
Figura 38: Comparao entre as mtricas de reusabilidade dos estudos dos domnios de eventos
cientficos (EC), Web e Computao em Nuvem (CN)
Foram utilizados somente dois modelos baseados em XML, e estes apresentaram uma
mdia de 36,33 atributos e nenhum relacionamento.
Com relao aos dados qualitativos, foram coletadas algumas impresses passadas pela
187
equipe aps a execuo do estudo. Entre as impresses obtidas com a entrevista7 , destacam-se:
Segundo a equipe, a abordagem permitiu atacar problemas recorrentemente enfrentados

pela equipe, tais como o alto nvel de retrabalho procurando cdigos e testando cada
mudana no domnio, a existncia de arquivos que nunca so utilizados mas que so
includos nos produtos por convenincia, o que acaba por confundir os desenvolvedores
e causando problemas de manuteno, e a necessidade de busca por links que precisam
removidos dependendo da configurao de produtos adquiridos pelo cliente;
Neste estudo, a automao conseguida com o MDD permitiu reduzir alguns problemas de
forma que no vinha sendo conseguida, por falta de tempo e dificuldades em desenvolver
uma soluo que atendesse a mltiplos clientes ao mesmo tempo;
A equipe relatou dificuldades no aprendizado das tecnologias de modelagem e gerao
de cdigo, porm com relao abordagem citaram apenas que tiveram dificuldades em
compreender as funes especficas dos casos de mudana na abordagem. Segundo eles,
no ficou clara a necessidade de se criar mltiplos cenrios para descrever pequenas partes
do problema;
A equipe teve tambm bastantes dificuldades na identificao correta das features,
sendo necessria a presena constante do autor desta tese para orientar e corrigir as
identificaes equivocadas. No geral, os participantes compreenderam os conceitos, mas
tinham dificuldade em reproduzi-los no domnio em questo, inserindo constantemente e
de maneira equivocada, mdulos e funes como sendo features; e
A equipe no soube responder de forma apropriada com relao ao processo investigativo
de identificao de sub-domnios, atividade de avaliao arquitetural, e atividade de
documentao do domnio, pois no chegou a realizar estas atividades durante o estudo.
Discusso
Neste estudo, ao contrrio dos dois anteriores, ocorreu uma reduo da porcentagem
e da razo de reutilizao, quando a abordagem foi utilizada. Porm, conforme discutido
anteriormente, a mtrica de reutilizao em termos de LOC no pode ser lida literalmente, de
forma isolada, pois pode ser distorcida por alguns fatores. Conforme a prpria equipe relatou
em entrevista, h muitos artefatos que so reutilizados desnecessariamente. Alm de causar
7O
contedo integral da entrevista encontra-se no Apndice D
188
prejuzos manuteno, ocupar espao de forma desnecessria e confundir os desenvolvedores,

este fato distorce a mtrica de reutilizao.
Analisando-se tambm a quantidade de reutilizao no desejada, nota-se que houve
reduo significativa, ou seja, na realidade a quantidade de LOC reutilizadas foi menor, porm
a reutilizao ocorreu de forma melhor, com menos cdigo desnecessrio poluindo a aplicao.
Isto foi alcanado de forma simples, atravs de geradores que fazem a cpia seletiva dos
arquivos de acordo com as configuraes do produto.
Os artefatos produzidos pela equipe apresentaram qualidade inferior, em termos de
instabilidade, complexidade e manutenibilidade, do que os artefatos desenvolvidos nos outros
estudos. Isto se deve principalmente s dificuldades com o aprendizado e treinamento, conforme
citado pela prpria equipe. Alm disso, foram desenvolvidos poucos artefatos e uma baixa taxa
de reutilizao com gerao de cdigo (3,99%), devido principalmente falta de tempo e
dedicao parcial dos participantes.
Existe tambm uma ocorrncia que foi brevemente citada pela equipe e que merece uma
avaliao mais aprofundada. Na entrevista, os participantes citaram que com a abordagem
puderam resolver problemas que no conseguiam resolver anteriormente, no somente pela
falta de tempo, mas tambm pela dificuldade em se obter solues genricas que possam ser
utilizadas por mltiplos clientes. Em muitos casos, as modificaes exigidas por um cliente
no podem ser generalizadas e parametrizadas, pois a natureza das mudanas profunda,
como por exemplo as diferentes formas de certificado, citadas como exemplo pela equipe.
possvel criar um componente genrico capaz de gerar certificados para eventos com diferentes
textos, tamanhos de fontes, de papel, entre outros parmetros. Porm, comum a existncia de
chamados solicitando a presena de informaes extras, como um determinado texto em negrito,
orientaes de texto diferentes, e dados no-convencionais, como por exemplo certificados de
responsveis por sesses (chair de sesso). Nestes casos, a nica soluo encontrada era criar
uma cpia do componente anterior e modific-la para o novo requisito. Com o MDD e a
abordagem, a equipe conseguiu criar um suporte mais flexvel para estas modificaes, sem
perder a generalidade do componente original e sem causar a duplicao de verses.
Outro problema citado o espalhamento da informao, o que exige um grande trabalho de
inspeo, modificao e testes a cada configurao de um novo produto. Este espalhamento
visvel nos dados coletados: no estudo realizado, em torno de 70 artefatos foram modificados
em menos de 25%. Estas modificaes envolvem configuraes e customizaes, muitas delas
duplicadas. Com a abordagem, foi possvel reunir grande parte dos parmetros de configurao
em um nico modelo, e as modificaes pontuais e repetitivas so realizadas por geradores.
189
Neste estudo, o modelo serve de entrada para configuraes em seis tabelas diferentes do banco,
e quatro arquivos de configurao, que antes precisavam ser feitas individualmente. Alm disso,
os geradores so mais confiveis nesta tarefa, reduzindo a necessidade de testes mais exaustivos.
As mtricas de nmero de atributos e relacionamentos para os modelos utilizados neste
estudo mostram que existem muitos atributos (mdia de 36,33) e nenhum relacionamento, o
que indica que se tratam de modelos que servem basicamente de configurao apenas.
9.5
Anlise das hipteses e concluses
Os dados e resultados obtidos com os estudos possuem indcios sobre a rejeio de algumas
das hipteses nulas. Esta rejeio feita com base em anlise descritiva apenas, no sendo
embasada por dados estatsticos rigorosos.
Com relao hiptese H0a , conclui-se que a mesma rejeitada, pois nos trs estudos
foram verificados aumento e/ou melhoria na reutilizao de software nos projetos utilizando a
abordagem, contrariando a premissa original.
Com relao hiptese H0b , no foi possvel alcanar a rejeio, uma vez que os resultados
indicaram que a reusabilidade dos artefatos pode ser maior ou menor utilizando-se a abordagem.
Com relao s hipteses H0c e H0d , os dados obtidos possuem indcios que apiam a
rejeio, uma vez que os sujeitos dos estudos perceberam benefcios com a abordagem, e no
tiveram dificuldades significativas no aprendizado.
Mesmo para as hipteses nulas com indcios de rejeio, no se pode afirmar que as
hipteses alternativas apresentadas na Seo 9.1.2 so verdadeiras. Ou seja, a abordagem
aparentemente favorece a reutilizao, mas pode ser que existam projetos onde ela no
acrescente benefcios ou mesmo cause dificuldades significativas de aprendizado e utilizao.
O que parece ser uma concluso mais razovel que a abordagem pode aumentar
a quantidade, em termos de LOC. Mas ela no aumenta, de forma absoluta, os valores
das mtricas de complexidade e dificuldade de manuteno, conforme percebido no estudo
do domnio Web.
Tampouco ela as reduz, conforme percebido no estudo do domnio
de computao em nuvem.
Aparentemente, h uma tendncia a produzir artefatos com
instabilidade, complexidade e dificuldade de manuteno acimas da mdia, mas seguindo uma

constante, e dependendo das caractersticas do domnio, isto pode ser vantajoso ou no. Este
efeito ilustrado na Figura 39.
Assim, uma hiptese alternativa mais realista deve considerar as diferentes condies e
190
Figura 39: Efeito da abordagem na reusabilidade dos artefatos produzidos

cenrios dos domnios, conforme ilustra a Figura 40. Em domnios tcnicos mais simples,
a abordagem proporciona maior quantidade de reutilizao mas menor reusabilidade dos
artefatos, sendo mais indicada para quando h a necessidade de geral de grande volume de
cdigo. Em domnios tcnicos mais complexos, a abordagem simplifica o desenvolvimento
quando a codificao extremamente complexa. Em domnios de negcio, ela pode facilitar o
processo de configurao e reduzir os problemas causados com a proliferao de verses.
Figura 40: Hiptese alternativa mais realista

Esta hiptese alternativa resume muitas das experincias vivenciadas nesses trs estudos,
191
e explica de forma plausvel os efeitos observados.
Porm, ela foi extrapolada, no
sendo embasada por evidncias mais slidas. Estudos mais rigorosos podem e devem ser
realizados para complementar estes resultados e o conhecimento adquiridos nesta tese, para
que generalizaes estatisticamente comprovadas possam ser formuladas.
9.6
Ameaas validade
Os dados obtidos com esta avaliao so bastante informativos e abrangentes. Porm, h

muitas questes que sequer chegaram a ser exploradas, tais como o impacto da abordagem nos
nveis de reutilizao internos, como aqueles alcanados com herana, por exemplo. Alm
disso, algumas etapas da abordagem no puderam ser avaliadas, como a atividade de avaliao
arquitetural e a documentao dos artefatos.
Deve-se citar que a participao do autor da tese em dois dos estudos pode ter influenciado
negativamente os resultados, sendo uma ameaa sua validade, uma vez que tendo ele prprio
desenvolvido a abordagem, no passou por dificuldades em seu aprendizado, e provavelmente
falhou em identificar pontos fracos da mesma, dois aspectos importantes da avaliao. Ainda
assim considerou-se que os resultados obtidos so vlidos, pois muitos deles foram obtidos a
partir de mtricas objetivas, que no sofrem a influncia do pesquisador. As mtricas subjetivas
foram coletadas diretamente dos participantes do terceiro estudo, e portanto tambm no foram
influenciadas.
Vale mencionar tambm o fato de que a realizao dos estudos em ambiente industrial
apresenta um menor grau de controle, uma vez que o desenvolvimento sofre influncias e
presses constantes, naturais deste tipo de ambiente. Como resultado, a qualidade e rigor
dos dados menor do que em um estudo controlado. Por ser esta uma tese na rea de
Engenharia de Software, no se pode descartar este tipo de estudo, afinal, a indstria deve
ser o destino imediato ou a longo prazo de toda e qualquer pesquisa relevante nesta rea.
As lies aprendidas, ainda que em forma de comentrios e impresses subjetivas, devem ser
consideradas como sendo relevantes e valiosas.
O tamanho dos projetos envolvidos nos estudos, que se caracterizam entre pequeno e mdio
portes, razovel para este tipo de avaliao, e no foi considerado como uma ameaa
validade. Dado o tamanho das equipes ser muito reduzido, no foi possvel avaliar aspectos
referentes ao trabalho colaborativo, nem a capacidade da abordagem em atender aos requisitos
deste tipo de desenvolvimento.
A comparao de implementaes obtidas com e sem a abordagem pode tambm ter
192
sofrido influncia pelo fato de que a abordagem foi utilizada aps o desenvolvimento de uma
implementao de exemplo. Nos dois primeiros estudos, essa implementao consistiu de
prottipos executveis desenvolvidos para praticar o desenvolvimento no domnio, e no terceiro
estudo, consistiu de um produto real existente na empresa. Com isso, o desenvolvimento com
a abordagem pode ter se beneficiado de uma maior experincia no domnio. Porm, a prpria
abordagem utiliza uma estratgia de desenvolvimento atravs de exemplos para proporcionar
justamente este ganho de experincia antes da implementao efetiva dos artefatos do MDD,
e portanto este efeito parcialmente o que seria obtido com a abordagem de qualquer forma.
Mas uma avaliao mais justa deveria envolver equipes diferentes partindo de um mesmo nvel
de conhecimento sobre o domnio. Isto no foi possvel realizar pela dificuldade em encontrar
participantes para estes estudos.
Finalmente, destacam-se as ameaas s validades interna, externa e de construo
(WOHLIN et al., 2000). Os estudos foram planejados, definidos e executados de forma mais
exploratria, sem a definio de variveis dependentes e independentes voltadas a uma anlise
de correlao mais rgida. Isto prejudica a sua capacidade de replicao, tanto no mesmo
grupo como em grupos de pesquisa externos. Assim, necessrio um maior detalhamento das
variveis e aspectos envolvidos para transformar estes estudos em um experimento de carter
exclusivamente cientfico.
9.7
Consideraes finais
Neste captulo foi apresentada uma avaliao realizada para verificar a validade da tese
sendo defendida nesta dissertao. Foram realizados trs estudos empricos, um em ambiente
acadmico e dois em ambiente industrial, visando caracterizar os efeitos da utilizao da
abordagem na reutilizao de software. Com exceo das ameaas validade citadas na
seo anterior, os estudos contm resultados e indcios que permitiram a anlise de algumas
concluses relevantes ao contexto desta tese.
A avaliao permitiu determinar os principais benefcios, mas tambm algumas falhas da
abordagem, como por exemplo o fato de que os participantes do terceiro estudo no perceberam
utilidade na identificao de cenrios para descrever as variabilidades nos comportamentos do
domnio, alegando ser esta uma tarefa desnecessria. Esta limitao indica que talvez seja
preciso uma reestruturao da abordagem, visando aumentar sua agilidade, ou mesmo um
melhor treinamento visando reforar a importncia desta atividade. A escolha de qual direo
a ser tomada depende de uma anlise mais aprofundada do problema.
193
Tambm foram identificadas falhas na prpria avaliao, principalmente no terceiro

estudo, como por exemplo a no utilizao do formato de documentao sugerido e nem dos
processos investigativos para identificao dos sub-domnios e de anlise arquitetural. Estas so
decorrentes principalmente de restries execuo do estudo impostas pelo prprio cenrio
industrial em que foi realizado.
Vale a pena ressaltar que os estudos foram realizados em diferentes ambientes, utilizando
diferentes tecnologias para o MDD, como EMF, GMF, openArchitectureWare, Microsoft Text
Templates, GME, e em diferentes plataformas e linguagens de programao, como Java, C# e
PHP. Isto refora a validade dos resultados e a sua independncia com relao s tecnologias
envolvidas.
195
10 Trabalhos relacionados
Neste captulo so apresentados diversos trabalhos que se relacionam de alguma maneira

com a pesquisa apresentada nesta dissertao. Os trabalhos so divididos de acordo com cada
rea. Com relao aos trabalhos referentes aos processos relacionados engenharia de domnio
e linhas de produtos de software, existem excelentes estudos e revises da literatura disponveis,
como por exemplo (MILI et al., 2002; ALMEIDA et al., 2005; ALMEIDA, 2007).
Assim, neste captulo so focadas as outras reas de interesse: na Seo 10.1 apresentam-se
trabalhos acadmicos sobre a rea de desenvolvimento orientado a modelos; na Seo 10.2 so
discutidos os trabalhos que se relacionam com as fases de anlise, projeto e implementao
desta abordagem; e na Seo 10.3 so apresentados alguns trabalhos envolvendo mtricas e
avaliao de abordagens focadas em MDD e reutilizao.
10.1
Trabalhos acadmicos sobre desenvolvimento orientado

a modelos
As idias do MDD esto fortemente ligadas com o uso de ferramentas de auxlio ao

desenvolvimento de software. Por esse motivo, no estranho o fato de que a indstria
esteja voltando seus olhos para esse paradigma, uma vez que fabricantes de ferramentas
vem um forte indcio de vantagem competitiva caso consigam oferecer a seus clientes uma
maneira de alcanar os benefcios de qualidade e produtividade associados a esse paradigma de
desenvolvimento. Na Seo 2.2.2 so apresentadas as principais abordagens da indstria para o
MDD.
Mas com a academia no diferente, sempre existindo o interesse cientfico nessa rea,
com trabalhos que discutem os conceitos tericos e a viabilidade dessa abordagem.
Um dos primeiros trabalhos a propor a uma abordagem similar ao que se busca hoje com
MDD data de 1980 (NEIGHBORS, 1980). Pioneiro na rea de reutilizao de software, James
Neighbors, com sua abordagem Draco para desenvolvimento de software, tambm investigou a
196
viabilidade de se utilizar modelos como a base para a construo de aplicativos.

Nas palavras de Neighbors, a abordagem Draco se baseia na sensao frustrante de que a
maior parte do sistema que voc est construindo atualmente a mesma que voc j construiu
em alguns sistemas anteriores (NEIGHBORS, 1989). Sua proposta que seja feita uma anlise
sobre um domnio de aplicaes similares, a exemplo do que props Parnas (1976), e que o
conhecimento obtido seja representado por meio de linguagens especficas para este domnio
(DSL) e para os domnios relacionados, de forma a facilitar sua reutilizao ao se construir um
novo sistema. Essa proposta muito similar s idias do MDD.
Na abordagem Draco, um analista do domnio, normalmente uma pessoa com experincia
na construo de diferentes aplicaes similares, cria a descrio desse domnio segundo uma
DSL. Um domnio no Draco inclui um interpretador semntico (parser), que incorpora as regras
gramaticais da linguagem. Desta forma, ao se construir um sistema para esse domnio, um
engenheiro de software pode utiliza essa DSL.
No Draco, o analista do domnio tambm pode construir transformaes que permitem
que os elementos criados pelo analista do sistema sejam automaticamente transformados em
domnios intermedirios, at eventualmente chegar em linguagem executvel1 .
O projeto ModelWare faz parte do IST (Information Society Technologies), uma das
prioridades do planejamento estratgico envolvendo a pesquisa tecnolgica realizada pela
comunidade europia. Envolvendo instituies de pesquisa e empresas de toda a Europa,
o projeto ModelWare est dividido em seis frentes de trabalho, incluindo tecnologias de
modelagem, processos e metodologias, infra-estrutura ferramental, adoo bem sucedida, MDD
na indstria e o gerenciamento do projeto.
Entre os resultados alcanados por esta iniciativa, destacam-se o modelo de maturidade
em MDD (MODELWARE, 2006b), um conjunto de padres para adoo das prticas do MDD na
indstria (MODELWARE, 2006c), e outros resultados prticos na forma de projetos e ferramentas,
tais como o MOFScript e ATL, descritos na Seo 2.2.2.
Em (WEIS; ULBRICH; GEIHS, 2003), os autores apresentam uma proposta de um mecanismo
para modelagem, denominado Kase, e uma linguagem para transformao de modelos,
denominada Kafka. Eles apresentam os requisitos a serem atendidos por transformaes no
desenvolvimento orientado a modelos. O primeiro deles que as transformaes devem ser
automticas, pois de outra forma os desenvolvedores considerariam a criao de modelos
uma tarefa improdutiva. Outro requisito que as transformaes no podem ser universais e
1 Uma
discusso mais detalhada sobre o conceito de domnios intermedirios, de modelagem e domnios

executveis, apresentada no Apndice A
197
genricas, mas sim especficas para cada caso, podendo ser adaptadas facilmente e reutilizadas.
Finalmente, os autores ressaltam a necessidade de se utilizar linguagens visuais para a
construo das transformaes, uma vez que o uso de linguagens textuais, tais como linguagens
de programao e linguagens de transformao baseadas em XML, possuem uma distncia
conceitual em relao aos modelos, dificultando a tarefa de construo de transformadores.
As transformaes representadas na linguagem Kafka so baseadas em regras de mapeamento,
facilitando a chamada engenharia ida e volta, ou seja, modelo para cdigo e cdigo para
modelo.
Outros exemplos de trabalhos baseados no MDD incluem os trabalhos de Yuefeng Zhang,
que investiga o teste baseado em modelos (ZHANG, 2004), e um mtodo para auxiliar no controle
do processo de desenvolvimento orientado a modelos (ZHANG; SHETH, 2006).
Com relao rea de reutilizao de software, foco deste trabalho, existem poucas
referncias. Dois trabalhos acadmicos podem ser citados:
Em (FRANCE; GHOSH; TURK, 2001), os autores propem uma abordagem de reutilizao
baseada em modelos. Nessa abordagem, que apoiada por um framework, uma organizao
pode encapsular seu conhecimento em linguagens de modelagem especficas de domnio,
medida que vai adquirindo experincia sobre ele, de forma similar abordagem Draco (Seo
10.1). Porm, os autores no apresentam muitos detalhes de como isto ser feito.
Em (CZARNECKI et al., 2005), os autores discutem a combinao das idias de linhas de
produto (Seo 2.1.2) e desenvolvimento orientado a modelos, ressaltando que essas duas
linhas so complementares. Neste sentido, os autores propem a combinao da modelagem
de caractersticas, ou features, com o uso de templates de caractersticas, responsveis pelo
mapeamento automtico das caractersticas para modelos que as implementam, com base em
transformaes de modelos. Esse trabalho, apesar de interessante, foca apenas na modelagem
de caractersticas e sua representao em modelos, deixando de lado outras etapas do processo.
Em resumo, a academia tem apresentado grande preocupao com essa rea, como pode
ser constatado principalmente pela iniciativa europia com o projeto ModelWare.
10.2
Trabalhos relacionados abordagem desta tese
Nesta seo so discutidos trabalhos que possuem algum ponto de interseo com pontos
isolados da abordagem pesquisada nesta tese. A seo est dividida de acordo com a fase com
a qual os trabalhos se relacionam: anlise, projeto e implementao.
198
10.2.1
Anlise de domnio orientada a modelos
H diversos trabalhos com atividades similares s aqui definidas para a anlise de domnio,
como (FRAKES; PRIETO-DAZ; FOX, 1998; BAYER; MUTHIG; WIDEN, 1999; KIM; YANG; PARK,
2003; MEI; ZHANG; GU, 2003; MOON; YEOM, 2005). Por exemplo, o trabalho de deBaud
e Schmid (1999) similar definio de escopo presente na atividade de planejamento da
abordagem desta tese. A principal diferena que nenhum destes trabalhos possui preocupao
com a preparao de um domnio para o desenvolvimento orientado a modelos, como por
exemplo o problema da determinao dos sub-domnios a serem automatizados.
Knodel et al. (2005) apresentam uma abordagem para a utilizao de desenvolvimento
orientado a modelos em linhas de produtos de software, chamada Pulse-MDD. Esta abordagem
possui muitas similaridades com a abordagem desta tese, tambm sendo iterativa, mas
especialmente com relao ao fato de que o desenvolvimento de transformaes e ferramentas
de modelagem altamente ligado arquitetura da linha de produto, e no em conceitos gerais
das tecnologias de implementao. Os resultados so portanto mais prximos s necessidades
organizacionais. Porm, no Pulse-MDD esta preocupao comea somente na fase de projeto,
enquanto nesta abordagem argumenta-se que a mesma deve comear antes, durante a anlise,
uma vez que os modelos de features possuem papel importante nesta definio, e normalmente
precisam ser adaptados para refletir a existncia dos artefatos MDD.
Czarnecki et al. (2005) descrevem duas tcnicas para dar suporte a linhas de produtos
orientadas a modelos: modelagem de features e templates, para representar a variabilidade
e comunalidade do domnio. Estas tcnicas so as mesmas utilizadas nesta tese. Porm, os
autores no descrevem mais detalhes sobre as atividades que levam das features ao templates,
como por exemplo os padres descritos nesta tese.
Deelstra et al. (2003) descrevem uma abordagem para o desenvolvimento de linhas de
produtos orientadas a modelos. Os autores argumentam que o MDD pode levar a vrios
benefcios, e apresentam como o mesmo pode ser utilizado para representao da variabilidade e
derivao automtica de produtos. O suporte variabilidade com o MDD atravs de modelos
do domnio, a exemplo da abordagem desta tese. Porm, os autores passam diretamente da
representao da variabilidade derivao de produtos, sem entrar em detalhes sobre, por
exemplo, a construo de uma arquitetura adequada para este cenrio.
199
10.2.2
Projeto de domnio orientado a modelos
A maioria das abordagens que combina o MDD com engenharia de domnio (ou linhas
de produtos de software) tem foco maior no estgio de derivao automtica de produtos,
dando pouca ou nenhuma nfase ao projeto do domnio de acordo com os princpios do
MDD. Exemplos destas abordagens incluem (WEISS et al., 2008; VLTER; GROHER, 2007;
BOTTERWECK; OBRIEN; THIEL, 2007; ARBOLEDA; CASALLAS; ROYER, 2007; TRASK et al., 2006;
TOLVANEN; KELLY,
2005; CZARNECKI; HELSEN; EISENECKER, 2004b).
Uma das excees o mtodo Kobra (ANASTASOPOULOS; ATKINSON; MUTHIG, 2002),

que integra engenharia de linhas de produtos de software, desenvolvimento baseado em
componentes e o desenvolvimento orientado a modelos. Porm, preocupaes arquiteturais
no esto previstas no mtodo, que mais focado na idia de frameworks de componentes. O
paradigma do MDD tambm somente parcialmente suportado, porque o mtodo s lida com
a atividade de modelagem, com poucos detalhes sobre o desenvolvimento de transformaes e
geradores.
Alferez et al. (2008) apresentam uma abordagem orientada a modelos para a engenharia
de requisitos em um contexto de linha de produtos. Assim como na abordagem desta tese, os
autores defendem a idia de que as features devem ser complementadas com modelos adicionais
(casos de uso e atividades) para melhor representar a variabilidade. Estes so utilizados para
representar o comportamento varivel associado com diferentes features. Regras de composio
entre os casos de uso so utilizados para identificar os pontos de variao, de maneira similar ao
conceito de casos de mudanas utilizado nesta tese. A diferena neste caso que os casos
de mudanas constituem cenrios isolados, o que facilita a sua utilizao como diretrizes
arquiteturais e a avaliao arquitetural, enquanto que mltiplos casos de uso precisam ser
combinados de forma a ilustrar uma nica variabilidade. Os autores tambm descrevem uma
ferramenta que ajuda no processo de derivao de requisitos vlidos durante a engenharia de
aplicaes. Porm, seu trabalho no descreve detalhes sobre como a arquitetura pode ser obtida.
O trabalho de Prez-Martnez e Sierra-Alonso (2006) descreve uma abordagem para a
derivao automtica de uma arquitetura de software a partir de modelos de anlise, utilizando
transformaes modelo-para-modelo semi-automatizadas. Porm, assume-se que os modelos
de anlise so ricos o suficiente para serem automaticamente transformados em uma arquitetura.
Alm disso, um nico estilo arquitetural (C2 (PREZ-MARTNEZ; SIERRA-ALONSO, 2006))
suportado. E finalmente, a abordagem focada no desenvolvimento de produtos nicos, no
cobrindo aspectos relativos reutilizao, como suporte variabilidade e derivao de produtos.
200
10.2.3
Implementao de domnio orientada a modelos
Vlter e Groher (2007) descrevem um conjunto de tcnicas para combinar MDD e linhas
de produtos de software. Suas idias sobre a combinao de tcnicas esto de acordo com a
filosofia da abordagem desta tese, tais como o suporte aos dois tipos principais de variabilidade:
baseada em features (configurao) e DSLs (construo criativa). Adicionalmente, os autores
utilizam tcnicas orientadas a aspectos para facilitar a modelagem e implementao das
variabilidades ortogonais, o que no tratado nesta tese. A principal diferena desta tese em
relao ao trabalho de Voelter e Groher que aqui proposta uma abordagem sistemtica, com
atividades e diretrizes concretas para desenvolver a infra-estrutura de reutilizao orientada a
modelos para o domnio. Alm disto, a abordagem desta tese tambm identifica a necessidade
do suporte simultneo a mltiplos sub-domnios, o que no mencionado por Voelter e Groher.
Robbes e Lanza (2008) descrevem um sistema de suporte transformao de programas
baseada em exemplos.
Neste sistema, o programador realiza um exemplo de mudana
manualmente, que ento submetido ao sistema e posteriormente generalizado para outros

contextos, se tornando uma transformao reutilizvel. O sistema se baseia no monitoramento
do ambiente de programao para detectar automaticamente as modificaes feitas pelo
desenvolvedor em algum artefato de cdigo. Estas so ento registradas como operaes de
mudanas, sendo posteriormente convertidas em entidades de primeira classe que descrevem
como os elementos da AST (rvore de sintaxe abstrata) de um programa (como as classes,
atributos, mtodos e outras construes da linguagem) so modificados pelo desenvolvedor.
No passo de generalizao, o sistema tenta identificar automaticamente o papel de
cada mudana na transformao.
Por exemplo, se uma mudana modifica um pedao
de cdigo envolvendo-o com comandos try-catch, o trecho de cdigo a ser envolvido

um parmetro da transformao, enquanto os comandos try-catch so constantes a serem
inseridas. O desenvolvedor da transformao pode ento refinar esta generalizao em um editor
personalizado, renomeando parmetros, especificando detalhes no detectados pelo sistema
automtico, entre outras tarefas.
O trabalho de Robbes e Lanza focado principalmente na transformao de programas e
refactorings. Porm, a abordagem poderia ser aplicada para linguagens de modelagem tambm.
Como os prprios autores destacam, pode ser ainda mais simples nestes casos, j que os passos
automticos seriam realizados em estruturas mais simples do que uma AST de um programa.
A abordagem desta tese similar ao raciocnio de desenvolvimento de transformaes atravs
de exemplos seguido pelos autores, com a diferena de que a deteco e generalizao das
mudanas no automatizada, sendo realizada completamente pelo desenvolvedor. Alm disso,
201
esta tese foca na engenharia de domnio, com o objetivo de produzir transformaes projetadas
especificamente para dar suporte variabilidade no domnio.
Varr (2006) tambm prope o desenvolvimento de transformaes orientada a exemplos,
porm com foco em transformaes de modelos. Um processo iterativo e interativo utiliza
derivao semi-automtica das transformaes, a partir de pares de modelos origem e destino.
O desenvolvedor da transformao refina um conjunto de regras inicialmente derivadas at que
as mesmas cheguem a um ponto satisfatrio. Diferentemente do trabalho de Robbes e Lanza
(2008) e da abordagem desta tese, o processo de Varr no depende do registro das modificaes
que levam da origem ao destino. Ao invs disso, o processo tenta estabelecer mapeamentos
analisando exemplos de modelo origem e destino.
A abordagem desta tese (assim como a de Robbes e Lanza (2008)) mais voltada para
os estgios iniciais do desenvolvimento, uma vez que tenta capturar o esforo manual para
transformar modelos ou programas, medida que os exemplos de destino so construdos,
de forma incremental e gradual. Em contraste, o trabalho de Varr comea somente aps
exemplos de modelos de origem e destino j existirem, sendo portanto mais apropriado para
estgios posteriores, quando o desenvolvedor j possui uma idia concreta de como o destino
da transformao deve ser.
Bierhoff, Liongosari e Swaminathan (2006) utilizam exemplos no somente para derivar
as transformaes, mas tambm as DSLs. Os autores propem uma abordagem incremental:
comeando com uma aplicao, constri-se uma DSL para ela, contendo os elementos e
conceitos da aplicao, e os parmetros necessrios para configur-la. Em seguida, novas
aplicaes so adicionadas incrementalmente, e suas diferenas introduzem novas variaes
na DSL, aumentando sua generalidade. Porm, os autores destacam que esta abordagem
puramente bottom-up precisa ser orientada por decises de projeto tomadas cuidadosamente
de antemo, caso contrrio corre-se o risco de se produzir DSLs extremamente complexas e
difceis de se manter. Este exatamente o caminho tomado pela abordagem desta tese, que
busca mesclar uma etapa top-down para preparar o domnio para automao, com uma etapa
bottom-up que introduz detalhes e refinamentos necessrios para o funcionamento prtico das
DSLs e das transformaes.
Santos, Koskimies e Lopes (2008) propem a extenso de frameworks com uma camada
adicional baseada em programao orientada a aspectos que codifica uma DSL, buscando
alavancar a reutilizao de software atravs de tcnicas generativas. Um modelo conceitual
de um framework manualmente extrado pelo desenvolvedor, que descreve seus elementos e
conceitos em termos de um metamodelo especfico. Este modelo ento utilizado em conjunto
202
com um framework de linguagem para produzir ferramentas concretas para a nova linguagem.
Utilizando estas ferramentas, o desenvolvedor de aplicaes pode especificar uma aplicao e
gerar cdigo em termos dos elementos do framework. O trabalho de Muszynski (2005) tambm
prope a derivao de uma DSL a partir de uma implementao de referncia, tornando a DSL
extrada o ponto central para especificao de produtos e gerao de cdigo.
Estes trabalhos so similares abordagem desta tese, pois utilizam uma DSL, geradores
e um processo bottom-up para derivar os mapeamentos entre a linguagem e a implementao
de referncia (ou framework). Eles tambm possuem um elemento top-down implcito, que
corresponde ao processo de desenvolvimento da implementao de referncia ou do framework,
o que envolve tarefas como gerenciamento de variabilidade na engenharia de domnio. A
principal diferena que na abordagem desta tese o elemento top-down explcito e focado
no problema da reutilizao, indo mais alm no processo, at o desenvolvimento de uma
primeira verso da DSL de forma exclusivamente top-down. O resultado que nesta tese
as DSLs so mais prximas do domnio do problema, permitindo tarefas mais criativas,
facilitando o desenvolvimento de aplicaes e oferecendo mais flexibilidade ao desenvolvedor.
Em contrapartida, o desenvolvimento de geradores mais complexo devido a esta maior
proximidade com o domnio do problema.
As extenses ao modelo de features descritas por Czarnecki, Helsen e Eisenecker (2004b),
com cardinalidades de features e atributos, entre outras (Seo 3.1.1), permitem a especificao
de variabilidades mais complexas, de forma similar variabilidade baseada em DSLs descrita
na abordagem desta tese. Atravs destas extenses possvel representar praticamente o mesmo
tipo de variabilidade que possvel representar utilizando-se, por exemplo, um metamodelo. A
principal diferena que com uma DSL tem-se um poder expressivo mais focado no problema,
sendo portanto uma soluo mais intuitiva, podendo inclusive ser utilizada e compreendida por
especialistas. Mas nada impede que um modelo estendido de features seja convertido em um
metamodelo, dando origem a uma DSL.
Mas alm disso, a abordagem desta tese tem outras contribuies, como um conjunto
de diretrizes e regras para ajudar no processo de identificao destas variabilidades, no
desenvolvimento das sintaxes abstrata e concreta. Alm disso, nesta tese o metamodelo
complementado com informaes originadas em uma implementao concreta, o que facilita
a identificao de variabilidades mais detalhadas e a construo de transformaes e geradores
de cdigo mais precisos no suporte variabilidade.
203
10.3
Trabalhos relacionados com o uso de mtricas para

MDD e reutilizao
O estado da prtica na avaliao de qualidade de modelos contm evidncias de que a

modelagem ainda tida como uma atividade artesanal. Apesar de existirem alguns padres
e regras baseadas no bom senso (como minimizar o acoplamento, aumentar a coeso, manter
uma hierarquia de classes pequena), os desenvolvedores ainda dependem muito da opinio de
especialistas para determinar quando um modelo bom ou no (FRANCE; RUMPE, 2007). Porm,
existem diversos trabalhos que investigam a avaliao de modelos e o uso de mtricas para
aumentar a confiabilidade dos resultados da avaliao.
Mohagheghi e Aagedal (2007) apresentam os principais aspectos relacionados avaliao
de qualidade de um processo de MDD. Entre estes, destacam-se os aspectos de qualidade da
linguagem de modelagem utilizada, tais como sua complexidade e adequao ao domnio, a
qualidade das ferramentas utilizadas no processo, o conhecimento dos especialistas com relao
ao uso das linguagens e ferramentas, a qualidade do processo utilizado e o uso de tcnicas
para identificar falhas e defeitos em projetos MDD. Nesta tese, foram utilizadas mtricas
para avaliao da linguagem de modelagem, como parte dos estudos de caso. Alm disso, a
qualidade do processo tambm foi uma preocupao importante, e a cobertura das atividades
essenciais foi discutida na Seo 4.3, onde compara-se a abordagem desta tese com um modelo
de maturidade em MDD.
Monperrus et al. (2008) argumentam que o custo para se coletar mtricas em um projeto
orientado a modelos extremamente alto, devido especificidade a um domnio, o que
impede que sejam utilizadas mtricas genricas. Como consequncia, necessrio desenvolver
ferramentas especficas para medir software cada vez que um novo domnio implementado.
Para resolver este problema, os autores desenvolveram uma abordagem orientada a modelos
para a gerao de sistemas coletores de mtricas especficas de domnio, com base em
especificaes formais das mtricas a serem utilizadas. Especialistas do domnio especificam
quais mtricas so necessrias, seguindo um metamodelo definido pela abordagem, e so
automaticamente geradas ferramentas capazes de coletar estas mtricas.
Uma abordagem parecida apresentada por Guerra, Lara e Daz (2008). Neste trabalho,
os autores descrevem uma linguagem especfica de domnio para a definio de mtricas.
Esta linguagem pode servir de entrada para a coleta automtica destas mtricas. Porm,
diferentemente do trabalho de Monperrus et al. (2008), aqui os autores acrescentam a
preocupao com reprojeto e refatorao de modelos, visando a sua melhoria. A linguagem
para definio de mtricas tambm inclui aes que representam modificaes nos modelos, de
204
forma a implementar o reprojeto.

Nos estudos de caso desta tese, o objetivo foi avaliar a abordagem e suas vantagens
com relao ao desenvolvimento para reutilizao tradicional, e portanto no foi necessria
a definio de nenhuma mtrica especfica para um domnio.
Genero, Poels e Piattini (2008) apresentam doze mtricas para avaliao estrutural de
modelos entidade-relacionamento, com o objetivo de determinar sua manutenibilidade atravs
de sua compreensibilidade. A premissa deste trabalho a de que quanto mais compreensvel
for um diagrama, maior ser a sua facilidade de manuteno. Foi realizado um estudo emprico,
que demonstrou que a compreensibilidade de um diagrama E-R afetada por sua complexidade
estrutural, ditada pela quantidade de atributos e relacionamentos, em particular relacionamentos
1:1 e 1:N. Quanto mais atributos e relacionamentos (1:1 e 1:N) um diagrama possuir, menos
compreensvel ele ser. interessante notar que no foi identificada evidncia que relaciona
o tamanho de um diagrama em termos de nmero de entidades com a compreensibilidade, a
no ser atravs de sua relao bvia com o nmero de relacionamentos. Igualmente, no foi
evidenciada relao com o nmero de relacionamentos N:M. Assim, entre as doze mtricas
originalmente propostas, apenas estas trs foram comprovadamente verificadas como sendo
relevantes para a manutenibilidade. Em outro trabalho (GENERO et al., 2007), alguns destes
mesmos autores demonstram que as mesmas propriedades estruturais de diagramas E-R tambm
possuem influncia na manutenibilidade de diagramas de classes UML, particularmente os
relacionamentos de associao e generalizao. Estas mtricas foram adaptadas e utilizadas
nesta tese, durante os estudos de caso, conforme descrito no Captulo 9.
Pilgrim (2008) apresenta algumas mtricas para determinar o nvel de abstrao de um
modelo. O objetivo avaliar a eficincia das transformaes entre modelos, argumentando que
transformaes devem inicialmente ser focadas em transformaes na semntica, e somente
posteriormente devem ser includos detalhes da plataforma. As mtricas se baseiam no nmero
de atributos, a exemplo do trabalho de Genero, Poels e Piattini (2008), mas tambm no
tamanho do diagrama. Nesta tese, no foram utilizadas estas mtricas, pois a eficincia das
transformaes no foi o foco dos estudos de caso.
Chidamber e Kemerer (1994) apresentam algumas mtricas clssicas da orientao a
objetos baseadas em conceitos como acoplamento, coeso, complexidade de objeto, escopo de
propriedades, conjunto de respostas e combinao de classes. Os autores definem as seguintes
mtricas: mtodos ponderados por classe (WMC - Weighted Methods per Class); profundidade
da rvore de herana (DIT - Depth of Inheritance Tree); nmero de filhos (NOC - Number
Of Children); acoplamento entre classes (CBO - Coupling Between Object classes); resposta
205
para uma classe (RFC - Response For a Class); e falta de coeso em mtodos (LCOM Lack of Cohesion in Methods). Estas mtricas focam em diferentes aspectos de um projeto,
tais como complexidade, dificuldade de desenvolvimento e manuteno. Os autores tambm
destacam o papel do acoplamento na reutilizao. Quanto menor o acoplamento, mais fcil ser
a reutilizao de uma determinada classe. Outras mtricas clssicas para projetos orientados
a objetos incluem a estabilidade (MARTIN, 1994), manutenibilidade (VANDOREN, 1997) e
complexidade (MCCABE, 1976).
Algumas destas mtricas foram utilizadas nos estudos de caso, nas partes do domnio onde
no houve aplicao do MDD e para comparao com o software construdo manualmente,
conforme descrito no Captulo 9.
Muskens, Chaudron e Lange (2004) propem a coleta de mtricas clssicas da orientao
a objetos diretamente em modelos UML, ou seja, antes que exista cdigo-fonte. Os resultados
mostraram que possvel detectar os mesmos problemas utilizando esta abordagem, porm no
incio do desenvolvimento. Portanto, aes corretivas so menos dispendiosas, uma vez que
no exigem a modificao extensa do cdigo. Os autores tambm propem mtricas adicionais
baseadas em modelos arquiteturais descritos segundo a viso 4 + 1 (KRUCHTEN, 1995). O
argumento que as mtricas clssicas, mesmo sendo coletadas a partir dos modelos UML, no
consideram as interaes entre as diferentes vises, como por exemplo a referncia a classes
e mtodos a partir de um diagrama de seqncia. Porm, a validade destas mtricas no
apresentada neste trabalho. Nesta tese, no foi possvel aplicar estas mtricas, uma vez que as
mesmas esto fixadas na UML e na viso 4 + 1, no sendo adequadas para DSLs.
Lange e Chaudron (2004) apresentam algumas regras e mtricas para avaliao de modelos
UML, considerando a sua completude e consistncia. Exemplos destas regras incluem: objetos
sem nome, classes sem mtodos, interfaces sem mtodos, classes abstratas em diagramas de
seqncia, classes no chamadas em diagramas de seqncia, mensagens entre classes no
relacionadas, entre outras que ajudam na avaliao e garantia da qualidade de modelos UML.
Para esta tese estas mtricas no so teis, uma vez que no podem ser usadas para comparao
dos nveis de reutilizao com e sem a aplicao de MDD conforme proposto na abordagem.
Em outro artigo, Lange e Chaudron (2005) apresentam um modelo de qualidade para
desenvolvimento de software baseado em UML. Alm dos atributos de qualidade a serem
avaliados, como complexidade, rastreabilidade, modularidade, comunicabilidade e esttica,
entre outros, os autores apresentam uma lista sobre quais mtricas podem ser utilizadas para
avaliar estes atributos. Por exemplo, para avaliar a complexidade, os autores citam as mtricas
de profundidade da rvore de herana (DIT), coeso, nmero de casos de uso por classe e
206
nmero de classes por caso de uso. Nesta tese no foi feita avaliao de qualidade do software
baseado em UML, porm algumas das mtricas foram utilizadas nos estudos de caso, com o
objetivo de avaliar os benefcios da abordagem proposta.
A iniciativa Modelware tambm investigou mtricas para o desenvolvimento orientado a
modelos (MODELWARE, 2006a). Foram definidas mtricas para diversos aspectos de engenharia,
incluindo mtricas de qualidade do produto, incluindo qualidade dos modelos e demais
artefatos, mtricas de processo, incluindo transformaes e geradores de cdigo, e mtricas
de projeto, teis para estimativas e outras tarefas de gerenciamento. interessante notar que
as mtricas sugeridas para a qualidade da arquitetura so as mesmas da orientao a objetos
descritas por Chidamber e Kemerer (1994): WMC, RFC, LCOM, CBO, entre outras. A exemplo
do trabalho de Muskens, Chaudron e Lange (2004), estas levam identificao dos mesmos
problemas do que quando coletadas diretamente do cdigo-fonte, com a diferena de que isto
ocorre durante o projeto.
Mascena, Almeida e Meira (2005) e Mascena (2007) apresentam uma anlise sobre
mtricas relacionadas reutilizao de software, incluindo trs categorias: mtricas orientadas
a fatores econmicos, estruturais e de repositrio. Entre estas, as mtricas estruturais so a base
para analisar de forma mais aprofundada o que est sendo reutilizado. So elas: porcentagem
de reutilizao (RP - Reuse Percent) (POULIN; CARUSO, 1993); nvel de reutilizao (RL Reuse Level) (FRAKES; TERRY, 1994); freqncia de reutilizao (RF - Reuse Frequency)
(FRAKES; TERRY, 1994); tamanho e freqncia de reutilizao (RSF - Reuse Size and Frequency)
(DEVANBU et al., 1996); razo de reutilizao (RR - Reuse Ratio) (DEVANBU et al., 1996); e
densidade de reutilizao (RD - Reuse Density) (CURRY et al., 1999). Estas so mtricas simples,
porm no podem ser consideradas como indicadores isolados, uma vez que possuem problemas
por no considerar a natureza dos artefatos reutilizveis e nem a maneira com que estes so
reutilizados, penalizando, por exemplo, grandes sistemas e sistemas pouco modularizados
(monolticos). Por este motivo, existe outra vertente que defende a idia de que melhor
tentar medir a reutilizao atravs da avaliao de atributos de qualidade que medem o quo
reutilizvel um determinado artefato de software. Neste sentido, so sugeridas mtricas
indiretas, como manutenibilidade e complexidade (POULIN, 1994). Estas j foram utilizadas
com sucesso em outros estudos relacionados reutilizao de software, como por exemplo
o trabalho de Almeida et al. (2007a). Nesta tese, foram utilizadas algumas das mtricas de
reutilizao, alm das mtricas indiretas, na avaliao dos estudos de caso.
207
10.4
Consideraes finais
A literatura nas reas de reutilizao de software e desenvolvimento orientado a modelos

relativamente rica em trabalhos que exploram os aspectos processuais destes dois paradigmas.
Porm, a investigao conjunta das duas linhas de pesquisa ainda recente, e normalmente
os trabalhos focam em partes isoladas do problema. interessante notar que as duas reas,
aparentemente distintas, tiveram um nico pesquisador que investigou de forma pioneira
diversos conceitos que posteriormente formaram a base de cada rea separadamente.
James Neighbors, em sua abordagem Draco (NEIGHBORS, 1980), combinou os conceitos de
domnio (tendo cunhado o termo Anlise de domnio) e transformaes de software de forma
inovadora. Esta unio entre reutilizao e MDD permaneceu relativamente ignorada por vrios
anos, sendo atualmente resgatada principalmente aps o surgimento da MDA (LUCRDIO et al.,
2006).
Neste captulo foram apresentados os principais trabalhos acadmicos na rea de
desenvolvimento orientado a modelos, contando parte da histria de sua evoluo. Tambm
foram apresentados trabalhos que possuem alguma interseo com a abordagem desta tese, em
pontos isolados das fases de anlise, projeto e implementao do domnio, alm da avaliao,
juntamente com uma discusso sobre as principais similaridades e diferenas.
209
11 Concluses
Reutilizao de software um objetivo constantemente procurado por pesquisadores e

profissionais envolvidos com desenvolvimento de software. A percepo comum a de que esta
uma idia bastante simples de se colocar em prtica, que apresenta benefcios considerveis e
praticamente no requer investimento em tecnologias ou profissionais altamente qualificados.
Dcadas de pesquisa evidenciaram que apesar de ser uma idia simples, a sua aplicao
na prtica algo extremamente complexo, principalmente de forma sistemtica e gerencivel.
Muitos fatores fogem da rea tcnica, e portanto mais difcil para profissionais desta rea
perceberem os erros e dificuldades na sua aplicao. Como resultado, a reutilizao vem
ocorrendo, porm de forma isolada e herica, quando deveria ser uma prtica mais disseminada
na comunidade.
Mesmo no mbito tcnico, a reutilizao ainda esbarra em problemas do desenvolvimento
de software baseado em cdigo-fonte. cada vez mais difcil construir software atualmente,
dada a sua complexidade e ubiquidade, ambas causadas pelo progresso tecnolgico. Enquanto
atualmente possvel resolver problemas atravs de frameworks, padres, e outras tcnicas,
eventualmente chegar o dia em que nossa capacidade de construir software no ser capaz
de atender demanda. Assim como em outras indstrias, a automao pode aumentar esta
nossa capacidade, suprindo nossas deficincias e limitaes relacionadas ao desenvolvimento
de software.
11.1
Principais contribuies
Nesta dissertao so discutidas idias para resolver parte do problema da reutilizao

atravs do desenvolvimento orientado a modelos.
Aps estudos e pesquisas nas reas
relacionadas, foi definida uma abordagem orientada a modelos para reutilizao de software,
visando guiar o engenheiro de software desde as atividades iniciais de anlise at a
implementao de artefatos reutilizveis de um domnio, utilizando o desenvolvimento
orientado a modelos para elevar e melhorar a reutilizao.
Neste sentido, as seguintes
210
contribuies foram feitas nesta rea:
Uma abordagem sistemtica e bem definida, contendo atividades, entradas e sadas que
detalham as tarefas necessrias para que a engenharia de domnio possa integrar de forma
concreta as tcnicas do desenvolvimento orientado a modelos;
Definio de um mtodo concreto para identificao de mltiplos sub-domnios,
incluindo diretrizes de apoio e um processo investigativo, interativo e iterativo, adequado
natureza incerta e evolutiva desta rea;
Realizao de estudos empricos com resultados relevantes.
A literatura apresenta
pouca evidncia quantitativa sobre os benefcios do MDD s organizaes de software

(MOHAGHEGHI; DEHLEN, 2008). Assim, os resultados deste estudo so importantes no
somente para avaliar a abordagem definida nesta tese, mas tambm para a comunidade
cientfica e industrial interessada em aplicar o MDD;
Identificao de um conjunto de diretrizes arquiteturais focadas especificamente nos
problemas da reutilizao e desenvolvimento orientado a modelos. Estas diretrizes
permitem a identificao de requisitos referentes aos diferentes tipos de variabilidade que
podem ser encontrados em um domnio;
Identificao de um conjunto de padres especficos para as diretrizes arquiteturais
referentes variabilidade no domnio e a integrao de artefatos de software no
gerados com uma infra-estrutura de MDD baseada em linguagens especficas de domnio,
transformaes e geradores de cdigo;
Definio de um processo de mapeamento entre um modelo de features e uma ou mais
linguagens especficas de domnio, com regras para a criao de elementos de sintaxe
abstrata e concreta da linguagem;
Diretrizes para a implementao do suporte baseado no MDD para um domnio, incluindo
diretrizes para desenvolvimento de DSLs e para o suporte variabilidade por meio de
gerao de cdigo; e
Elaborao de um material de treinamento em MDD, utilizado nos estudos de caso, mas
que pode ser reaproveitado em cursos de extenso, mini-cursos e tutoriais em eventos
relacionados.
211
11.2
Publicaes resultantes da tese
Alm das contribuies citadas na seo anterior, as seguintes publicaes diretamente

relacionadas tese foram obtidas:
1. Lucrdio, D.; Fortes, R.P.M.; Alvaro, A.; Almeida, E.S.; Meira, S.R.L. Towards a
Model-Driven Reuse Process, In: 31st IEEE EUROMICRO Conference on Software
Engineering and Advanced Applications (SEAA), Work in Progress Session, Porto,
Portugal, 2005.
2. Almeida, E.S.; Alvaro, A.; Lucrdio, D.; Garcia, V.C.; Meira, S.R.L. A Survey on
Software Reuse Processes, In: the IEEE International Conference on Information Reuse
and Integration (IRI), Las Vegas, Nevada, USA, 2005.
3. Almeida, E.S.; Mascena, J.C.C.P.; Cavalcanti, A.P.C.; Alvaro, A.; Garcia, V.C.; Lucrdio,
D.; Meira, S.R.L. The Domain Analysis Concept Revisited: A Practical Approach, In:
The 9th International Conference on Software Reuse (ICSR), Lecture Notes in Computer
Science, Springer-Verlag, Torino, Italy, 2006.
4. Brito, K. S.; Alvaro, A.; Lucrdio, D.; Almeida, E.S.; Meira, S.R.L. Software Reuse:
A Brief Overview of the Brazilian Industrys Case, In: 5th ACM-IEEE International
Symposium on Empirical Software Engineering (ISESE), Short Paper, Rio de Janeiro,
Brazil, 2006
5. Lucrdio, D.; Fortes, R.P.M; Almeida, E.S.; Meira, S.R.L. The Draco Approach
Revisited:
Model-Driven Software Reuse,
In:
the Sixth Workshop on
Component-Based Development (WDBC), Recife, Brazil, 2006

6. Almeida, E.S.; Alvaro, A.; Garcia, V.C.; Nascimento, L.M.; Lucrdio, D.; Meira,
S.R.L. Designing Domain-Specific Software Architecture (DSSA): Towards a New
Approach, In: 6th Working IEEE/IFIP Conference on Software Architecture (WICSA),
Mumbai, India, 2007.
7. Almeida, E.S.; Alvaro, A.; Garcia, V.C.; Lucrdio, D.; Fortes, R.P.M.; Meira, S.R.L. An
Experimental Study in Domain Engineering, In: 33rd IEEE EUROMICRO Conference
on Software Engineering and Advanced Applications (SEAA), Component-Based
Software Engineering Track, Lbeck, Germany, 2007.
212
8. Almeida, E.S.; Alvaro, A.; Garcia, V.C.; Nascimento, L.M.; Lucrdio, D.; Meira, S.R. A
Systematic Approach to Design Domain-Specific Software Architectures, Journal of
Software, Vol 2, No. 2, pp. 38-51, August, 2007.
9. Almeida, E.S.; Santos, E.C.R.; Alvaro, A.; Garcia, V.C.; Lucrdio, D.; Fortes, R.P.M.;
Meira, S.R.L. Domain Implementation in Software Product Lines Using OSGi, In:
7th IEEE International Conference on Composition-Based Software Systems (ICCBSS)
February, 25-29, Madrid, Spain, 2008
10. Almeida, E.S.; Alvaro, A.; Garcia, V.C.; Lucrdio, D.; Fortes, R.P.M.; Meira, S.R.L. A
Systematic Process for Domain Engineering, In: The 20th Internatioal Conference on
Software Engineering and Knowledge Engineering (SEKE), San Francisco, EUA, 2008.
11. Lucrdio, D; Jackson, E.K.; Schulte, W. Playing with Fire: Harnessing the Hottest
Technologies for Ultra-Large-Scale Systems, In: Monterey Workshop, Budapest,
September 2008.
12. Lucrdio, D; Fortes, R.P.M.; Almeida, E.S.; Meira, S.R.L. Performing Domain Analysis
for Model-Driven Software Reuse, In: The 10th International Conference on Software
Reuse (ICSR), Lecture Notes in Computer Science, Springer-Verlag, Beijing, China,
2008.
13. Lucrdio, D.; Brito, K.S. ; Alvaro, A. ; Garcia, V.C. ; Almeida, E.S. ; Fortes, R.P.M. ;
Meira, S.R. Software Reuse: The Brazilian Industry Scenario, Journal of Systems and
Software, Vol 81, No. 6, pp. 996-1013, Elsevier Inc, 2008
Alm destas, foram obtidas outras publicaes relacionadas s linhas de pesquisa da tese,
mas no diretamente relacionadas ao seu assunto principal. Estas tambm so importantes como
parte da experincia de uma pesquisa em nvel de doutorado.
14. Alvaro, A.; Almeida, E.S.; Lucrdio, D.; Garcia, V.C., Prado, A.P., Meira, S.R.L..
ASPECT IPM: Towards an Incremental Process Model Based on AOP for
Component-Based Systems, In: The 7th International Conference on Enterprise
Information Systems (ICEIS2005), Miami, USA, 2005.
15. Garcia, V.C.; Lucrdio, D.; Prado, A.P.; Almeida, E.S.; Alvaro, A.; Meira, S.R.L.
Towards an Approach for Aspect-Oriented Software Reengineering, In:
7th
International Conference on Enterprise Information Systems (ICEIS2005), Miami, USA,

2005.
213
16. Paiva, D.M.B.; Lucrdio, D.; Fortes, R.P.M. MVCASE - including design rationale
to help modeling in research projects (in portuguese), In: The XX SBES - Brazilian
Symposium on Software Engineering (SBES 2006) Tools Session, Florianpolis, SC,
Brazil, 2006.
17. Garcia, V.C.; Lucrdio, D.; Duro, F.A.; Santos, E.C.R.; Almeida, E.S.; Fortes,
R.P.M.; Meira, S.R.L. From Specification to the Experimentation: A Software
Component Search Engine Architecture, In: The 9th International Symposium on
Component-Based Software Engineering (CBSE), Lecture Notes in Computer Science,
Springer-Verlag, Sweden, 2006.
18. Garcia, V.C.; Almeida, E.S.; Meira, S.R.L.; Lucrdio, D.; Fortes, R.P.M. Toward a Code
Search Engine Based on the State-of-the-art and Practice, In: The 13th Asia Pacific
Software Engineering Conference (APSEC06), Bangalore, India, 2006.
19. Burgio, V.A.A.; Almeida, E.S.; Lucrdio, D; Meira, S.R.L. Specification, Design and
Implementation of a Reuse Repository, In: 31st IEEE Annual International Computer
Software and Applications (COMPSAC) Conference, Short Paper, Beijing, China, 2007.
20. Garcia, V.C.; Lucrdio, D.; Alvaro, A.; Almeida, E.S.; Fortes, R.P.M.; Meira,
S.R.L. Towards a Maturity Model for a Reuse Incremental Adoption, In: 1st
Brazilian Symposium on Software Components, Architecture and Reuse (SBCARS),
2007, Campinas - SP.
21. Brito, K.S.; Garcia, V.C.; Lucrdio, D.; Almeida, E.S.; Meira, S.R.L. LIFT:
Reusing Knowledge from Legacy Systems, In: 1st Brazilian Symposium on Software
Components, Architectures and Reuse (SBCARS), 2007, Campinas - SP.
22. Pereira, M.A.; Prado, A.F.; Biajiz, M.; Fontanette, V.; Lucrdio, D. Transformando
Modelos da MDA com o apoio de Componentes de Software, In: 1st Brazilian
Symposium on Software Components, Architectures and Reuse (SBCARS), 2007,
Campinas - SP.
23. Paiva, D.M.B.; Freire, A.P.; Lucrdio, D.; Braga, R.T.V.; Fortes, R.P.M. Reinforcing
Design Rationale in Software Projects Developed in Academic Environment,
International Transactions on Systems Science and Applications, v. 3, p. 238-248, 2007.
24. Almeida, E.S.; Alvaro, A.; Garcia, V.C.; Mascena, J.C.C.P.; Burgio, V.A.A.;
Nascimento, L.M.; Lucrdio, D; Meira, S. R.L. C.R.U.I.S.E: Component Reuse in
Software Engineering, C.E.S.A.R e-book, Brazil, 2007.
214
25. Burgio, V.A.A.; Almeida, E.S.; Lucrdio, D.; Meira, S.R.L. A Reuse Repository
System: From Specification to Deployment, In: The 10th International Conference on
Software Reuse (ICSR), Lecture Notes in Computer Science, Springer-Verlag, Beijing,
China, 2008.
26. Garcia, V.C.; Lisboa, L.B.; Meira, S.R.L.; Almeida, E.S.; Lucrdio, D.; Fortes,
R.P.M. Towards an Assessment Method for Software Reuse Capability, In: The 8th
International Conference on Quality Software (QSIC), Oxford, UK,2008.
27. Lucrdio, D.; Fortes, R.P.M.; Whittle, J. MOOGLE: a Model Search Engine, In: The
11th ACM/IEEE International Conference on Model Driven Engineering Languages and
Systems (MODELS), Toulouse, France, 2008.
28. Lisboa, L.B; Garcia, V.C.; Lucrdio, D.; Almeida, E.S.; Meira, S.R.L.; Fortes, R.P.M.
A Systematic Review of Domain Analysis Tools, Journal of Information and Software
Technology, Article In Press, Accepted Manuscritp, 2009.
Finalmente, ainda existem trabalhos que durante a escrita desta dissertao encontravam-se
em avaliao:
29. Cavalcanti, Y.K.; Cunha, C.E.A.; Garcia, V.C.G.; Lucrdio, D.; Almeida, E.S.; Meira,
S.R.L. The Bug Report Duplication Problem: A Characterization Study.
Em
avaliao: IET Software journal. Submetido em abril de 2009.

30. Lucrdio, D.; Fortes, R.P.M.; Whittle, J. MOOGLE: A Metamodel-Based Model
Search Engine. Artigo selecionado entre os melhores da conferncia MODELS 2008
para uma edio especial do Software and Systems Modeling (SoSyM) journal. Verso
estendida submetida em junho de 2009.
31. Lucrdio, D.; Fortes, R.P.M.; Furtado, A.W.B.; Santos, A.L.M.; Almeida, E.S.; Meira,
S.R.L. Systematic Domain Implementation Using Model-Driven Development. Em
avaliao: ASE 2009 - IEEE/ACM International Conference on Automated Software
Engineering, Auckland, New Zealand, 16 a 20 de novembro de 2009. Submetido em
maio de 2009.
32. Lucrdio, D.; Fortes, R.P.M.; Almeida, E.S.; Meira, S.R.L. Designing Domain
Architectures for Model-Driven Development.
Em avaliao: 11th International
Conference on Software Reuse, Falls Church, Virginia, USA, 27 a 30 de setembro de

2009. Submetido em maio de 2009.
215
33. Lucrdio, D.; Fortes, R.P.M.; Furtado, A.W.B.; Santos, A.L.M.; Almeida, E.S.;
Meira, S.R.L. Implementing Domain-Specific Languages for Model-Driven Domain
Engineering. Em avaliao: 11th International Conference on Software Reuse, Falls
Church, Virginia, USA, 27 a 30 de setembro de 2009. Submetido em maio de 2009.
34. Lucrdio, D.; Fortes, R.P.M.; Furtado, A.W.B.; Santos, A.L.M.; Almeida, E.S.; Meira,
S.R.L. Implementing Code Generators for Model-Driven Domain Engineering. Em
avaliao: 11th International Conference on Software Reuse, Falls Church, Virginia,
USA, 27 a 30 de setembro de 2009. Submetido em maio de 2009.
11.3
Lies aprendidas
As contribuies citadas so de carter cientfico e acadmico, apresentando melhorias e

aspectos ainda pouco explorados na literatura. Porm, com o desenvolvimento deste trabalho,
diversas lies importantes foram aprendidas.
Durante esta pesquisa, foram estudadas diferentes tecnologias relacionadas ao MDD. Neste
perodo, pode-se perceber a evoluo do estado-da-arte e da prtica nesta rea. H poucos
anos atrs, a falta de ferramentas e suporte para este tipo de desenvolvimento era uma forte
preocupao. A proposta inicial deste trabalho, inclusive, previa o desenvolvimento de parte
das ferramentas necessrias para a aplicao do MDD. Hoje, no s existem ferramentas
disponveis, mas tambm existem diversas opes, todas elas sendo efetivamente utilizadas na
prtica pela indstria. Nesta tese, foram utilizadas trs alternativas diferentes, e ainda existem
muitas outras igualmente capacitadas. Isto demonstra a tendncia de que o MDD est cada vez
mais presente na realidade do desenvolvimento de software.
A realizao dos estudos empricos tambm proporcionou o aprendizado de importantes
lies. A primeira delas foi a importncia da experincia em ambiente industrial. Em ambas
as experincias, percebeu-se que apesar do crescimento em importncia, o MDD ainda uma
tecnologia muito distante da realidade da grande maioria das empresas. Este fato pode ser
percebido no terceiro estudo, onde a empresa envolvida sequer conhecia a maioria dos conceitos
envolvidos.
E este no parece ser um retrato somente do cenrio brasileiro. Por exemplo, o segundo
estudo emprico, realizado durante o estgio de doutorado na Microsoft Research, foi uma
das primeiras iniciativas deste importante instituto de pesquisa na rea do MDD. Durante as
apresentaes e seminrios no final do estgio, realizadas pelo autor desta tese, muitos dos
participantes ali presentes estavam vislumbrando os conceitos do MDD pela primeira vez,
216
inclusive importantes pesquisadores e funcionrios desta gigante da rea de TI. O fato de que
a prpria Microsoft possui uma soluo voltada para o desenvolvimento de DSLs e geradores
de cdigo apenas refora esta observao. Claro que no se pode generalizar estas observaes
com base em fatos isolados, mas a experincia destes anos de doutorado, aps participaes
em diversos eventos cientficos e contatos com empresas, ainda no produziram evidncia do
contrrio.
Outra importante lio aprendida diz respeito grande variedade de trabalhos similares
existentes na literatura. muito comum encontrar trabalhos bastante parecidos com os temas
aqui investigados. Porm, h tambm grande diversidade no foco, com cada trabalho sendo
bastante direcionado a uma determinada linha de pesquisa caracterstica do grupo de pesquisa
que o realiza. No existem muitos trabalhos derivados destas iniciativas isoladas e que buscam
englobar e unificar os diversos aspectos do problema, caminho este que foi seguido nesta tese.
As contribuies alcanadas comprovam que h espao tambm para este tipo de pesquisa.
Neste quesito, cabe tambm uma observao: a despeito da grande quantidade e variedade
de trabalhos na rea, raro encontrar estudos empricos buscando sua validao, a exemplo
do que se tentou realizar nesta pesquisa. difcil encontrar mtricas e valores para serem
utilizados como base para este tipo de estudo, sendo freqentemente necessrias adaptaes ou
interpretaes indiretas para se extrair concluses relevantes.
11.4
Trabalhos futuros
Foram tambm identificadas, como subproduto desta pesquisa, oportunidades para

trabalhos futuros, seja para complementar esta pesquisa explorando aspectos que no puderam
ser investigados nesta tese, ou para iniciar novas investigaes em reas identificadas como
sendo deficitrias de contribuies.
Assim, os seguintes pontos podem ser investigados
futuramente:
Replicao dos estudos empricos: os dados obtidos com a avaliao realizada possuem
algumas deficincias, tais como a falta de rigor estatstico, e a existncia de possveis
ameaas sua validade, como a participao do autor da tese durante parte dos estudos.
Assim, visando melhorar a validade das concluses, pode-se realizar novos experimentos
envolvendo a definio mais precisa dos seus elementos e operacionalizando-os, por
exemplo, com equipes maiores;
Reutilizao de outros tipos de artefatos: nesta tese no foi feita distino com respeito
ao tipo de artefatos sendo gerados. No h atividades ou diretrizes especficas para o
217
desenvolvimento de transformaes que geram outras coisas alm do cdigo-fonte, como

outros modelos, arquivos de configurao, documentao, entre outros. Este um ponto
interessante, pois neste tipo de artefato no h a possibilidade de utilizao, por exemplo,
de padres de projeto e outras tcnicas que se baseiam em conceitos da orientao a
objetos, em particular, a herana;
Assistncia contextualizada automatizada: esta outra possibilidade de trabalhos
futuros.
A partir de sugestes sobre quais atividades a serem realizadas em um
contexto particular, como por exemplo a exibio automtica de ajuda especfica de

contexto, desenvolvedores de produtos podem ser ativamente guiados durante tarefas
de soluo de problemas.
No contexto do MDD, ela pode ajudar com as tarefas
complexas envolvidas com o desenvolvimento das linguagens e ferramentas especficas

de domnio, transformaes, e adaptao manual de cdigo gerado.
Tecnologias
como o quadro de tarefas do GMF (Generic Modeling Framework), as receitas do

openArchitectureWare (Seo 2.2.2) e as Microsoft Blueprints1 so exemplos dessa
assistncia sendo aplicada ao MDD. Trabalhos futuros podem explorar as atividades
necessrias para o desenvolvimento deste tipo de assistncia no contexto do MDD e da
engenharia de domnio;
Colaborao no MDD: o desenvolvimento orientado a modelos possui diferentes tarefas
que envolvem a participao de mltiplos membros de uma equipe, tais como a anlise de
features e a definio de mltiplas DSLs para diferentes domnios. Tambm pode-se citar
a existncia de equipes distintas para trabalhar com a implementao de referncia, com
as tecnologias de modelagem e os geradores de cdigo. Porm, a determinao exata de
onde a colaborao no MDD ocorre de maneira mais intensa, visando esclarecer os pontos
de flexibilizao na comunicao e atividades da equipe que podem ser alcanados,
ainda se mostram incipientes, como indicado por (STEFFEN et al., 2007).
Assim,
trabalhos futuros podem investigar a natureza desta colaborao, incluindo possivelmente

a considerao sobre desenvolvimento distribudo, ou at mesmo os aspectos ferramentais
envolvidos na colaborao; e
Migrao automtica de cdigo: o uso da implementao de referncia como ponto
de partida para o desenvolvimento de geradores traz uma srie de benefcios. Porm,
o processo de migrao de cdigo, necessrio neste mapeamento para os geradores,
apresenta dois problemas (MUSZYNSKI, 2005): (i) trata-se de um processo que consome
cerca de 20-25% do tempo de desenvolvimento da implementao de referncia; e
1 http://msdn.microsoft.com/en-us/architecture/blueprints.aspx
218
(ii) causa duplicao de cdigo, pois apesar de aps a primeira migrao ser possvel
descartar completamente a implementao de referncia, na prtica isto no ocorre devido
s dificuldades de se trabalhar no nvel do gerador. Como resultado, so mantidas tanto
a implementao de referncia como o gerador, e continua-se trabalhando com os dois
artefatos. Apesar de no-trivial, a automao, mesmo que parcial, seria a soluo para
estes problemas. Ainda no existe uma soluo automtica para migrao de cdigo nas
principais ferramentas do mercado, e este um interessante tema para trabalhos futuros.
11.5
Consideraes finais
Nesta dissertao apresentou-se a tese de que o MDD pode aumentar a reutilizao

de software em projetos de engenharia de domnio, descrevendo uma abordagem para esta
finalidade e sua avaliao atravs de estudos empricos. A abordagem combina elementos de
processo, como atividades, tarefas, entradas e sadas, com diretrizes e tcnicas auxiliares que
guiam o desenvolvedor durante a engenharia de domnio orientada a modelos.
Esta abordagem um passo inicial em direo a um framework de processo completo para
a utilizao efetiva do MDD como facilitador da reutilizao. Trata-se de um ponto central, ao
redor do qual necessrio definir atividades de suporte e de gerncia, alm de outras prticas
de engenharia no cobertas pela abordagem.
Esta dissertao um exemplo de pesquisa aplicada, que busca unificar diferentes tcnicas
relacionadas reutilizao de software e MDD de uma forma original, oferecendo um suporte
combinado que melhor do que a aplicao das tcnicas de forma isolada. Os resultados foram
interessantes e esclarecedores, principalmente em termos da utilizao prtica em ambiente
industrial. Comparando-se com o estado-da-arte, nota-se que as contribuies deste tipo de
pesquisa so relevantes, tendo em vista a escassez de trabalhos que visam somente solidificar
e formalizar contribuies que ainda apresentam falhas e falta de detalhes sobre as diversas
formas de desenvolvimento produtivo de software.
219
Referncias
ALFEREZ, M. et al. A Model-driven Approach for Software Product Lines Requirements
Engineering. In: SEKE. [S.l.]: Knowledge Systems Institute Graduate School, 2008. p.
779784. ISBN 1-891706-22-5.
ALLILAIRE, F. et al. Global model management in Eclipse GMT/AM3. In: Eclipse Technology
eXchange Workshop (eTX) at the ECOOP 2006 conference. Nantes, France: [s.n.], 2006.
. [S.l.]:
ALMEIDA, E. S. C.R.U.I.S.E - Component Reuse In Software Engineering. In:
C.E.S.A.R. e-books, 2007. cap. 4 - Software Reuse Processes: The State-of-The-Art, p. 81100.
ALMEIDA, E. S. et al. An experimental study in domain engineering. In: 33rd IEEE
EUROMICRO Conference on Software Engineering and Advanced Applications (SEAA),
Component-Based Software Engineering Track. [S.l.: s.n.], 2007.
ALMEIDA, E. S. et al. A systematic approach to design domain-specific software architectures.
Journal of Software - Academy Publisher, v. 02, n. 2, p. 3851, 2007.
ALMEIDA, E. S. et al. RiSE project: Towards a robust framework for software reuse. In:
IEEE International Conference on Information Reuse and Integration (IRI). Las Vegas, USA:
IEEE/CMS, 2004. p. 4853.
ALMEIDA, E. S. et al. A survey on software reuse processes. In: IEEE International
Conference on Information Reuse and Integration (IRI 2005). Las Vegas, USA: IEEE/CS Press,
2005.
ALMEIDA, E. S. et al. The domain analysis concept revisited: A practical approach. In: 9th
International Conference on Software Reuse (ICSR). Torino, Italy: Lecture Notes in Computer
Science, Springer-Verlag, 2006.
ALMEIDA, E. S. et al. Domain implementation in software product lines using OSGi. In: 7th
International Conference on Composition-Based Software Systems (ICCBSS). Madrid, Spain:
[s.n.], 2008.
AMBLER, S. W. Agile model driven development is good enough. IEEE Software, v. 20, n. 5,
p. 7173, 2003.
AMBLER, S. W. Examining the Model Driven Architecture (MDA). [S.l.]: Agile Modeling
Essay, 2004. Disponvel em: <http://www.agilemodeling.com/essays/mda.htm>. Acesso em:
14 jun 2009.
ANASTASOPOULOS, M.; ATKINSON, C.; MUTHIG, D. A concrete method for developing
and applying product line architectures. In: AKSIT, M.; MEZINI, M.; UNLAND, R. (Ed.).
NetObjectDays. [S.l.]: Springer, 2002. (Lecture Notes in Computer Science, v. 2591), p.
294312. ISBN 3-540-00737-7.
220
ANASTASOPOULOS, M.; GACEK, C. Implementing product line variabilities. In: Symposium

on Software Reusability (SSR). Toronto, Canada: [s.n.], 2001. p. 109117.
ANTKIEWICZ, M.; CZARNECKI, K. Framework-specific modeling languages with
round-trip engineering. In: NIERSTRASZ, O. et al. (Ed.). Model Driven Engineering
Languages and Systems (MoDELS 2006). [S.l.]: Springer Berlin / Heidelberg, 2006. (Lecture
Notes in Computer Science, v. 4199/2006), p. 692706.
ARANGO, G. Domain analysis - from art form to engineering discipline. In: International
Workshop on Software Specifications & Design. Pittsburgh, Pennsylvania, United States: [s.n.],
1999. p. 152159.
ARBOLEDA, H.; CASALLAS, R.; ROYER, J.-C. Dealing with constraints during a feature
configuration process in a model-driven software product line. In: SPRINKLE, J. et al. (Ed.).
Proceedings of the 7th OOPSLA Workshop on Domain-Specific Modeling (DSM07) - Montral,
Canada. [S.l.]: University of Jyvskyl, Finland 2007, ISBN 978-951-39-2915-2., 2007.
(Computer Science and Information System Reports, Technical Reports, TR-38).
ATKINSON, C.; BAYER, J.; MUTHIG, D. Component-based product line development: The
kobra approach. In: First Product Line Conference (SPLC), Kluwer International Series in
Software Engineering and Computer Science. Denver, Colorado, USA: [s.n.], 2000. p. 19.
ATKINSON, C.; KHNE, T. Model-driven development: A metamodeling foundation. IEEE
Software, v. 20, n. 5, p. 3641, 2003.
BAHNOT, V. et al. Using domain-specific modeling to develop software defined radio
components and applications. In: The 5th OOPSLA Workshop on Domain-Specific Modeling,
San Diego USA. [S.l.: s.n.], 2005.
BARTHOLDT, J.; OBERHAUSER, R.; RYTINA, A. An approach to addressing entity model
variability within software product lines. In: ICSEA. [S.l.]: IEEE Computer Society, 2008.
p. 465471. Disponvel em: <http://dx.doi.org/10.1109/ICSEA.2008.30>. Acesso em: 14 jun
2009.
BASILI, V.; ABD-EL-HAFIZ, S. K. A method for documenting code components. Journal of
Systems and Software (JSS), v. 34, n. 2, p. 89104, 1996.
BASILI, V. R.; BRIAND, L.; MELO, W. How reuse influences productivity in object-oriented
systems. Communications of the ACM, v. 39, n. 10, p. 104116, 1996.
BASILI, V. R.; CALDIERA, G.; ROMBACH, H. D. The goal question metric approach. In:
Encyclopedia of Software Engineering, Vol. II. [S.l.: s.n.], 1994. v. 2, p. 528532.
BASS, L. et al. Volume I - Market Assessment of Component-Based Software Engineering. [S.l.],
2000.
BASS, L.; CLEMENTS, P.; KAZMAN, R. Software Architecture in Practice, 2nd Edition.
[S.l.]: Addison-Wesley, 2003.
BAUER, D. A reusable parts center. IBM Systems Journal, v. 32, n. 04, p. 620624, 1993.
BAYER, J. et al. PuLSE: A methodology to develop software product lines. In: Symposium on
Software Reusability (SSR). Los Angeles, USA: ACM Press, 1999. p. 122131.
221
BAYER, J.; MUTHIG, D.; WIDEN, T. Customizable domain analysis. In: First International
Symposium on Generative and Component-Based Software Engineering (GPCE). Germany:
[s.n.], 1999. p. 178194.
BETTIN, J. Measuring the potential of domain-specific modelling techniques. In: In:
Proceedings of the 2nd Workshop on Domain-Specific Visual Languages, 17th ACM Conference
on Object Oriented Programming, Systems, Languages and Applications (OOPSLA 2002). [S.l.:
s.n.], 2002.
BIERHOFF, K.; LIONGOSARI, E. S.; SWAMINATHAN, K. S. Incremental development of a
domain-specific language that supports multiple application styles. In: GRAY, J.; TOLVANEN,
J.-P.; SPRINKLE, J. (Ed.). 6th OOPSLA Workshop on Domain-Specific Modeling (DSM06),
Portland, Oregon USA. [S.l.]: Jyvskyl University Printing House, Jyvskyl , Finland, ISBN:
951-39-2631-1, ISSN: 1239-291X, 2006.
BIGGERSTAFF, T. J.; RICHTER, C. Reusability framework, assessment, and directions. In:
BIGGERSTAFF, T. J.; PERLIS, A. J. (Ed.). Frontier Series: Software Reusability: Volume I Concepts and Models. New York: ACM Press, 1989. p. 117.
BOEHM, B. A spiral model of software development and enhancement. IEEE Computer, v. 21,
n. 5, p. 6172, May 1988.
BOSCH, J. Design and Use of Software Architectures. [S.l.]: Addison Wesley, 2000.
BOTTERWECK, G.; OBRIEN, L.; THIEL, S. Model-driven derivation of product
architectures. In:
STIREWALT, R. E. K.; EGYED, A.; FISCHER, B. (Ed.).
ASE. [S.l.]: ACM, 2007. p. 469472. ISBN 978-1-59593-882-4. Disponvel em:
<http://doi.acm.org/10.1145/1321631.1321711>. Acesso em 14 jun 2009.
BRAGA, R. T. V. Um Processo para Construo e Instanciao de Frameworks baseados
em uma Linguagem de Padres para um Domnio Especfico. Tese (Doutorado) USP Universidade de So Paulo, 2002.
BUSCHMANN, F.; HENNEY, K.; SCHMIDT, D. C. Pattern-Oriented Software Architecture,
Volume 4: A Pattern Language for Distributed Computing. [S.l.]: John Wiley & Sons, 2007.
BUSCHMANN, F.; HENNEY, K.; SCHMIDT, D. C. Pattern-Oriented Software Architecture,
Volume 5: On Patterns and Pattern Languages. [S.l.]: John Wiley & Sons, 2007.
BUSCHMANN, F. et al. Pattern-Oriented Software Architecture, Volume 1: A System of
Patterns. [S.l.]: John Wiley & Sons, 1996. TY - BOOK.
CHIDAMBER, S. R.; KEMERER, C. F. A metrics suite for object oriented design. IEEE Trans.
Softw. Eng., IEEE Press, Piscataway, NJ, USA, v. 20, n. 6, p. 476493, 1994. ISSN 0098-5589.
CLEAVELAND, J. C. Building application generators. IEEE Software, v. 7, n. 1, p. 2533,
1988.
CLEAVELAND, J. C. Separating concerns of modeling from artifact generation using XML. In:
Proceedings of the 1st OOPSLA Workshop on Domain-Specific Visual Languages - Tampa Bay,
USA. [S.l.]: Jyvskyl University Printing House, Jyvskyl , Finland, ISBN: 951-39-1056-3,
ISSN: 0359-8470, 2001.
222
CLEENEWERCK, T.; KURTEV, I. Separation of concerns in translational semantics for DSLs

in model engineering. In: CHO, Y. et al. (Ed.). 22nd Annual ACM Symposium on Applied
Computing (SAC 2007). [S.l.]: ACM, 2007. p. 985992. ISBN 1-59593-480-4.
CLEMENTS, P.; KAZMAN, R.; KLEIN, M. Evaluating Software Architectures: Methods and
Case Studies. [S.l.]: Addison-Wesley, 2004.
CLEMENTS, P.; NORTHROP, L. Software Product Lines: Practices and Patterns. [S.l.]:
Addison-Wesley, 2002.
COOK, S. et al. Domain-Specific Development with Visual Studio DSL Tools. [S.l.]:
Addison-Wesley Professional, 2007.
COPLIEN, J.; HOFFMAN, D.; WEISS, D. Commonality and variability in software
engineering. IEEE Software, v. 15, n. 6, p. 3745, 1998.
COPLIEN, J. O. Multi-Paradigm Design. Tese (Doutorado) Vrije Universiteit Brussel, 2000.
COPLIEN, J. O. A Pattern Definition (http://hillside.net/patterns/definition.html). [S.l.]:
hillside.net, 2006.
CURRY, W. et al. Empirical analysis of the correlation between amount-of-reuse metrics in
the c programming language. In: SSR 99: Proceedings of the 1999 symposium on Software
reusability. New York, NY, USA: ACM, 1999. p. 135140. ISBN 1-58113-101-1.
CZARNECKI, K. Overview of generative software development. In: BANTRE, J.-P. et
al. (Ed.). Unconventional Programming Paradigms, International Workshop UPP 2004, Le
Mont Saint Michel, France, September 15-17, 2004, Revised Selected and Invited Papers.
[S.l.]: Springer, 2005. (Lecture Notes in Computer Science, v. 3566), p. 326341. ISBN
3-540-27884-2.
CZARNECKI, K. et al. Model-driven software product lines. In: 20th Annual ACM SIGPLAN
Conference on Object-Oriented Programming, Systems, Languages, and Applications
(OOPSLA 2005). San Diego, CA, USA: ACM, 2005. p. 126127.
CZARNECKI, K. et al. Generative programming for embedded software: An industrial
experience report. In: BATORY, D.; CONSEL, C.; TAHA, W. (Ed.). Generative Programming
and Component Engineering. [S.l.]: Springer Berlin / Heidelberg, 2002. (Lecture Notes in
Computer Science, v. 2487), p. 156172.
CZARNECKI, K.; EISENECKER, U. W. Generative Programming: Methods, Tools, and
Applications. [S.l.]: Addison-Wesley, 2000.
CZARNECKI, K.; HELSEN, S. Feature-based survey of model transformation approaches.
IBM Systems Journal, v. 45, n. 3, p. 621645, 2006. ISSN 0018-8670. Disponvel em:
<http://www.research.ibm.com/journal/sj/453/czarnecki.html>. Acesso em: 14 jun 2009.
CZARNECKI, K.; HELSEN, S.; EISENECKER, U. Formalizing Cardinality-based
Feature Models and their Staged Configuration. [S.l.], 2004. Disponvel em:
<http://www.ece.uwaterloo.ca/ kczarnec/TR04-11.pdf>.
CZARNECKI, K.; HELSEN, S.; EISENECKER, U. Staged configuration using feature models.
In: NORD, R. L. (Ed.). Proceedings of the Third Software Product Line Conference. Boston,
MA: Springer, 2004. (LNCS 3154), p. 266283.
223
DAVIS, T. The reuse capability model: A basis for improving an organizations reuse capability.
In: Proceedings of 2nd ACM/IEEE International Workshop on Software Reusability. [S.l.]:
IEEE Computer Society Press / ACM Press, 1993. p. 126133.
DEBAUD, J.; SCHMID, K. A systematic approach to derive the scope of software product
lines. In: 21st International Conference on Software Engineering (ICSE 99). Los Angeles, CA,
USA: [s.n.], 1999. p. 3443.
DEBAUD, J.-M.; FLEGE, O.; KNAUBER, P. PuLSE-DSSA: A method for the development of
software reference architectures. In: ISAW 98: Proceedings of the third international workshop
on Software architecture. New York, NY, USA: ACM, 1998. p. 2528. ISBN 1-58113-081-3.
DEELSTRA, M. et al. Model driven architecture as approach to manage variability in software
product families. In: Workshop on Model Driven Architecture: Foundations and Applications
(MDAFA 2003). Enschede, The Netherlands: [s.n.], 2003. p. 109114.
DESOUZA, K. C.; AWAZU, Y.; TIWANA, A. Four dynamics for bringing use back into
software reuse. Communications of the ACM, v. 49, n. 01, p. 97100, 2006.
DEURSEN, A. v.; KLINT, P.; VISSER, J. Domain-specific languages: An annotated
bibliography. SIGPLAN Notices - ACM Press, v. 35, n. 6, p. 2636, 2000.
DEURSEN, A. van; KLINT, P. Little languages: little maintenance. Journal of Software
Maintenance, John Wiley & Sons, Inc., New York, NY, USA, v. 10, n. 2, p. 7592, 1998.
ISSN 1040-550X.
DEVANBU, P. et al. Analytical and empirical evaluation of software reuse metrics. In: ICSE
96: Proceedings of the 18th international conference on Software engineering. Washington,
DC, USA: IEEE Computer Society, 1996. p. 189199. ISBN 0-8186-7246-3.
DOE, D. D.; BERSOFF, E. H. The software productivity consortium (SPC): An industry
initiative to improve the productivity and quality of mission-critical software. Journal of
Systems and Software, v. 6, n. 4, p. 367378, 1986. Elsevier Science Inc., New York, NY,
USA.
DSOUZA, D.; WILLS, A. Objects, Components and Frameworks with UML: The Catalysis
Approach. [S.l.]: Addison-Wesley, 1999. (Object Technology Series).
ECKLUND JR, E. F.; DELCAMBRE, L. M. L.; FREILING, M. J. Change cases: Use cases
that identify future requirements. In: Conference Proceedings of the OOPSLA 96, San Jose, CA,
USA. [S.l.]: ACM Press, 1996.
ECLIPSE. The Eclipse Modeling Framework (EMF) Overview. [S.l.]: Eclipse website, 2005.
ENDRES, A. Lessons learned in an industrial software lab. IEEE Software, v. 10, n. 05, p.
5861, 1993.
ESSER, R.; JANNECK, J. W. A framework for defining domain-specific visual languages. In:
Proceedings of the 1st OOPSLA Workshop on Domain-Specific Visual Languages - Tampa Bay,
USA. [S.l.]: Jyvskyl University Printing House, Jyvskyl , Finland, ISBN: 951-39-1056-3,
ISSN: 0359-8470, 2001.
EZRAN, M.; MORISIO, M.; TULLY, C. Practical Software Reuse. [S.l.]: Springer, 2002.
224
FEILKAS, M. How to represent models, languages and transformations? In: GRAY, J.;
TOLVANEN, J.-P.; SPRINKLE, J. (Ed.). 6th OOPSLA Workshop on Domain-Specific Modeling
(DSM06), Portland, Oregon USA. [S.l.]: Jyvskyl University Printing House, Jyvskyl ,
Finland, ISBN: 951-39-2631-1, ISSN: 1239-291X, 2006.
FENTON, N.; PFLEEGER, S. L. Software Metrics: A Rigorous and Practical Approach. 2nd.
ed. [S.l.]: Course Technology, 1998.
FLORIJN, G.; MEIJERS, M.; WINSEN, P. v. Tool support for object-oriented patterns. In:
European Conference on Object-Oriented Programming (ECOOP97). Jyvskyl, Finland:
Springer-Verlag, 1997. p. 472495.
FOWLER, M. Inversion of Control Containers and the Dependency Injection pattern. 2004.
Disponvel em: <http://martinfowler.com/articles/injection.html>. Acesso em: 14 jun 2009.
FOWLER,
M.
Model
Driven
Architecture.
2004.
Disponvel
em:
<http://martinfowler.com/bliki/ModelDrivenArchitecture.html>. Acesso em: 14 jun 2009.
FOWLER,
M.
Language
Workbenches:
The
Killer-App
for
Domain
Specific Languages?
[S.l.]:
martinfowler.com,
2005. Disponvel em:
<http://www.martinfowler.com/articles/languageWorkbench.html>. Acesso em:
14 jun
2009.
FRAKES, W. B.; ISODA, S. Success factors of systematic software reuse. IEEE Software, v. 11,
n. 01, p. 1419, 1994.
FRAKES, W. B.; PRIETO-DAZ, R.; FOX, C. DARE: Domain Analysis and Reuse
Environment. Annals of Software Engineering, v. 05, 1998.
FRAKES, W. B.; TERRY, C. Reuse level metrics. In: Proceedings of the 3rd IEEE International
Conference on Software Reuse (ICSR): Advances in Software Reusability, Rio de Janeiro,
Brazil. [S.l.: s.n.], 1994.
FRANCE, R.; RUMPE, B. Model-driven development of complex software: A research
roadmap. In: 29th International Conference on Software Engineering 2007 - Future of Software
Engineering. Minneapolis, MN, USA: IEEE Computer Society, 2007. p. 3754.
FRANCE, R. B.; GHOSH, S.; TURK, D. E. Towards a model-driven approach to reuse. In: 7th
International Conference on Object Oriented Information Systems (OOIS). Calgary, Canada:
Springer, 2001. p. 181190.
GAMMA, E. et al. Design Patterns: Elements of Reusable Object-Oriented Software. Reading,
MA: Addison-Wesley, 1995.
GARCIA, V. C. et al. Towards an assessment method for software reuse capability. In: 8th
International Conference on Quality Software (QSIC), Oxford, UK. [S.l.: s.n.], 2008.
GARCIA, V. C. et al. Towards a maturity model for a reuse incremental adoption. In: Brazilian
Symposium on Software Components, Architectures and Reuse (SBCARS 2007). Campinas, SP,
Brazil: [s.n.], 2007.
GENERO, M. et al. Building measure-based prediction models for uml class diagram
maintainability. Empirical Softw. Engg., Kluwer Academic Publishers, Hingham, MA, USA,
v. 12, n. 5, p. 517549, 2007. ISSN 1382-3256.
225
GENERO, M.; POELS, G.; PIATTINI, M. Defining and validating metrics for assessing
the understandability of entity-relationship diagrams. Data Knowl. Eng., Elsevier Science
Publishers B. V., Amsterdam, The Netherlands, The Netherlands, v. 64, n. 3, p. 534557, 2008.
ISSN 0169-023X.
GREENFIELD, J. et al. Software Factories: Assembling Applications with Patterns, Models,
Frameworks and Tools. [S.l.]: Wiley, 2004.
GRISS, M. Software reuse experience at Hewlett-Packard. In: 16th International Conference
on Software Engineering (ICSE). Sorrento, Italy: IEEE/CS Press, 1994. p. 270.
GRISS, M. Making software reuse work at hewlett-packard. IEEE Software, v. 12, n. 01, p.
105107, 1995.
GRISS, M.; FAVARO, J.; DALESSANDRO, M. Integrating feature modeling with the RSEB.
In: The Fifty International Conference on Software Reuse (ICSR). Victoria, Canada: IEEE/CS
Press, 1998. p. 7685.
GUERRA, E.; LARA, J. de; DAZ, P. Visual specification of measurements and redesigns for
domain specific visual languages. J. Vis. Lang. Comput., Academic Press, Inc., Orlando, FL,
USA, v. 19, n. 3, p. 399425, 2008. ISSN 1045-926X.
GUIZZARDI, G.; PIRES, L. F.; SINDEREN, M. J. V. On the role of domain ontologies in
the design of domain-specific visual modeling languages. In: In: Proceedings of the 2nd
Workshop on Domain-Specific Visual Languages, 17th ACM Conference on Object Oriented
Programming, Systems, Languages and Applications (OOPSLA 2002). [S.l.: s.n.], 2002.
HADDAD, H.; TESSER, H. Reusable subsystems: Domain-based approach. In: 2002 ACM
Symposium on Applied Computing (SAC2002). Madrid, Spain: ACM, 2002. p. 971975.
HEINEMAN, G.; COUNCILL, W. Component-Based Software Engineering: Putting the
Pieces Together. USA: Addison-Wesley, 2001.
HENRIKSSON, A.; LARSSON, H. A Definition of Round-Trip Engineerin. [S.l.], 2003.
HESSELLUND, A.; CZARNECKI, K.; WASOWSKI, A. Guided development with multiple
domain-specific languages. In: ENGELS, G. et al. (Ed.). Model Driven Engineering Languages
and Systems (MoDELS 2007). [S.l.]: Springer, 2007. (Lecture Notes in Computer Science,
v. 4735), p. 4660. ISBN 978-3-540-75208-0.
HETTEL, T.; LAWLEY, M. J.; RAYMOND, K. Model synchronisation: Definitions for
round-trip engineering. In: VALLECILLO, A.; GRAY, J.; PIERANTONIO, A. (Ed.). Theory
and Practice of Model Transformations (ICMT 2008). [S.l.]: Springer Berlin / Heidelberg, 2008.
(Lecture Notes in Computer Science, v. 5063/2008), p. 3145.
HOLIBAUGH, R. et al. Reuse: where to begin and why. In: TRI-Ada 89: Proceedings of the
conference on Tri-Ada 89. Pittsburgh, Pennsylvania, United States: ACM Press, 1989. p. 266
277.
ISAKOWITZ, T.; KAUFFMAN, R. J. Supporting search for reusable software objects. IEEE
Transactions on Software Engineering, v. 22, n. 6, 1996.
226
JACKSON, E. K.; SCHULTE, W. Compositional modeling for data-centric business

applications. In: PAUTASSO, C.; TANTER ric (Ed.). Software Composition. [S.l.]: Springer,
2008. (Lecture Notes in Computer Science, v. 4954), p. 190205. ISBN 978-3-540-78788-4.
JACOBSON, I.; GRISS, M.; JONSSON, P. Reuse-driven Software Engineering Business
(RSEB). [S.l.]: Addison-Wesley, 1997.
JACOBSON, I.; LINDSTROM, F. Re-engineering of old systems to an object-oriented
architecture. In: OOPSLA 91: Conference proceedings on Object-oriented programming
systems, languages, and applications. Phoenix, Arizona, United States: ACM Press, 1991. p.
340350.
JARZABEK, S. Modeling multiple domains in software reuse. In: The 1997 Symposium on
Software Reusability. Boston, Massachusetts, United States: ACM, 1997. p. 6574.
JEZEQUEL, J. M.; MEYER, B. Design by contract: The lessons of Ariane. IEEE Computer,
v. 30, n. 01, p. 129130, 1997.
JOHNSON, R.; FOOTE, B. Designing reusable classes. Journal of Object Oriented
Programming, v. 1, n. 2, p. 2235, 1988.
JOHNSON, R. E. Components, frameworks, patterns. In: SSR 97: Proceedings of the 1997
symposium on Software reusability. Boston, Massachusetts, United States: ACM Press, 1997.
p. 1017.
JOHNSON, R. E. Frameworks = (components + patterns). Communications of the ACM, v. 40,
n. 10, p. 3942, 1997.
JOOS, R. Software reuse at Motorola. IEEE Software, v. 11, n. 05, p. 4247, 1994.
JOUAULT, F.; BZIVIN, J.; KURTEV, I. TCS: a DSL for the specification of textual concrete
syntaxes in model engineering. In: JARZABEK, S.; SCHMIDT, D. C.; VELDHUIZEN,
T. L. (Ed.). Fifth International Conference on Generative Programming and Component
Engineering (GPCE06). [S.l.]: ACM, 2006. p. 249254. ISBN 1-59593-237-2. Disponvel
em: <http://doi.acm.org/10.1145/1173706.1173744>. Acesso em: 14 jun 2009.
JOUAULT, F.; KURTEV, I. On the architectural alignment of ATL and QVT. In: ACM
Symposium on Applied Computing (SAC 06), model transformation track. Dijon, Bourgogne,
France: [s.n.], 2006.
KANG, K. et al. Feature-Oriented Domain Analysis (FODA) Feasibility Study. [S.l.], 1990.
KANG, K. et al. FORM: A Feature-Oriented Reuse Method with domain-specific reference
architectures. Annals of Software Engineering Notes, v. 05, p. 143168, 1998.
KANG, K.; LEE, J.; DONOHOE, P. Feature-oriented product line engineering. IEEE Software,
v. 19, n. 04, p. 5865, 2002.
KEEPENCE, B.; MANNION, M. Using patterns to model variability in product families. IEEE
Software, v. 16, n. 4, p. 102108, 1999.
KETTEMANN, S.; MUTHIG, D.; ANASTASOPOLOUS, M. Product Line Implementation
Technologies - Component Technology View. [S.l.], March 2003.
227
KIM, M.; YANG, H.; PARK, S. A domain analysis method for software product lines based
on scenarios, goals and features. In: Tenth Asia-Pacific Software Engineering Conference
(APSEC). Thailand: [s.n.], 2003. p. 126136.
KIRCHER, M.; JAIN, P. Pattern-Oriented Software Architecture, Volume 3: Patterns for
Resource Management. [S.l.]: John Wiley & Sons, 2003.
KLEPPE, A.; WARMER, J.; BAST, W. MDA Explained - The Model Driven Architecture:
Practice and Promise. [S.l.]: Addison-Wesley, 2003. (Object Technology Series).
KLEPPE, A. G. A language description is more than a metamodel. In: Fourth
International Workshop on Software Language Engineering, Nashville, USA. Grenoble, France:
megaplanet.org, 2007. ISBN not assigned.
KNODEL, J. et al. An efficient migration to model-driven development (mdd). Electronic Notes
in Theoretical Computer Science, v. 137, n. 3, p. 1727, 2005.
KOLTUN, P.; HUDSON, A. A reuse maturity model. In: 4th Annual Workshop on Software
Reuse. Hemdon, Virginia: Center for Innovative Technology: [s.n.], 1991.
KOTULA, J. Using patterns to create component documentation. IEEE Software, v. 15, n. 2, p.
8492, 1998.
KRUCHTEN, P. The 4+1 view model of architecture. IEEE Softw., IEEE Computer Society
Press, Los Alamitos, CA, USA, v. 12, n. 6, p. 4250, 1995. ISSN 0740-7459.
KRUEGER, C. Software reuse. ACM Computing Surveys, v. 24, n. 02, p. 131183, 1992.
KHNE, T. Making modeling languages fit for model-driven development. In: Fourth
International Workshop on Software Language Engineering, Nashville, USA. Grenoble, France:
megaplanet.org, 2007. ISBN not assigned.
KURTEV, I. et al. Model-based DSL frameworks. In: TARR, P. L.; COOK, W. R. (Ed.).
OOPSLA Companion. [S.l.]: ACM, 2006. p. 602616. ISBN 1-59593-491-X. Disponvel em:
<http://doi.acm.org/10.1145/1176617.1176632>. Acesso em: 14 jun 2009.
LANGE, C.; CHAUDRON, M. An empirical assessment of completeness in uml designs.
In: Proceedings of the 8th Conference on Empirical Assessment in Software Engineering
(EASE04). [S.l.: s.n.], 2004. p. 111121.
LANGE, C. F. J.; CHAUDRON, M. R. V. Managing model quality in uml-based software
development. In: STEP 05: Proceedings of the 13th IEEE International Workshop on Software
Technology and Engineering Practice. Washington, DC, USA: IEEE Computer Society, 2005.
p. 716. ISBN 0-7695-2639-X.
LEDECZI, A. et al. Composing domain-specific design environments. IEEE Computer, v. 34,
n. 11, p. 4451, 2001.
LEE, J.; KANG, K. C. Feature binding analysis for product line component development. In:
LINDEN, F. van der (Ed.). Software Product-Family Engineering, 5th International Workshop,
PFE 2003, Siena, Italy, November 4-6, 2003, Revised Papers. [S.l.]: Springer, 2003. (Lecture
Notes in Computer Science, v. 3014), p. 250260. ISBN 3-540-21941-2.
228
LEE, J.; MUTHIG, D. Feature-oriented variability management in product line engineering.

Communications of the ACM, v. 49, n. 12, p. 5559, December 2006.
LEE, K.; KANG, K. C. Feature dependency analysis for product line component design. In: 8th
International Conference on Software Reuse (ICSR). Madrid, Spain: [s.n.], 2004. p. 6985.
LEE, K.; KANG, K. C.; LEE, J. Concepts and guidelines of feature modeling for product line
software engineering. In: 7th International Conference on Software Reuse (ICSR): Methods,
Techniques, and Tools. Austin, Texas: [s.n.], 2002. p. 6277.
LIM, W. C. Effects of reuse on quality, productivity and economics. IEEE Software, v. 11, n. 5,
p. 2330, 1994.
LINDEN, F. V. D.; SCHMID, K.; ROMMES, E. Software Product Lines In Action: The Best
Industrial Practice In Product Line Engineering. [S.l.]: Springer, 2007.
LUCRDIO, D.; ALMEIDA, E. S. d.; PRADO, A. F. d. A survey on software components
search and retrieval. In: STEINMETZ, R.; MAUTHE, A. (Ed.). 30th IEEE EUROMICRO
Conference, Component-Based Software Engineering Track. Rennes - France: IEEE/CS Press,
2004. p. 152159.
LUCRDIO, D. et al. Software reuse: The Brazilian industry scenario. J. Syst. Softw., Elsevier
Science Inc., New York, NY, USA, v. 81, n. 6, p. 9961013, 2008. ISSN 0164-1212.
LUCRDIO, D. et al. The Draco approach revisited: Model-driven software reuse. In: VI
WDBC - Workshop de Desenvolvimento Baseado em Componentes. Recife - PE - Brazil: [s.n.],
2006.
LUCRDIO, D. et al. Performing domain analysis for model-driven software reuse. In: 10th
International Conference on Software Reuse. Beijing, China: [s.n.], 2008.
LUCRDIO, D.; JACKSON, E. K.; SCHULTE, W. Playing with fire: Harnessing the hottest
technologies for ultra-large-scale systems. In: Monterey workshop, Budapest. [S.l.: s.n.], 2008.
MAIDEN, N.; SUTCLIFFE, A. A computational mechanism for parallel problem
decomposition during requirements engineering. In: 8th International Workshop on Software
Specification and Design. Germany: [s.n.], 1996. p. 159163.
MARTIN, R. OO Design Quality Metrics: An Analysis of Dependencies. 1994. Disponvel em:
<http://www.objectmentor.com/resources/articles/oodmetrc.pdf>. Acesso em: 14 jun 2009.
MASCENA, J. C. C. P. C.R.U.I.S.E - Component Reuse In Software Engineering. In:
[S.l.]: C.E.S.A.R. e-books, 2007. cap. 6 - Software Reuse Metrics, p. 125136.
MASCENA, J. C. C. P.; ALMEIDA, E. S. d.; MEIRA, S. R. d. L. A comparative study

on software reuse metrics and economic models from a traceability perspective. In: IEEE
International Conference on Information Reuse and Integration (IRI). Las Vegas, Nevada, USA:
IEEE/CS Press, 2005.
MATOS JR, P. O. A. Analysis of techniques for implementing software product lines
variabilities. Dissertao (M.Sc. Dissertation) Universidade Federal de Pernambuco - Centro
de Informtica, Recife, PE, Brazil, August 2008.
229
MCCABE, T. J. A complexity measure. IEEE Transactions on Software Engineering, v. 2, n. 4,

p. 308320, 1976.
MCILROY, M. D. Mass produced software components. In: NATO Software Engineering
Conference. [S.l.: s.n.], 1968. p. 138155.
MEI, H.; ZHANG, W.; GU, F. A feature oriented approach to modeling and reusing
requirements of software product lines. In: 27th IEEE International Computer Software and
Applications Conference (COMPSAC). USA: [s.n.], 2003. p. 250256.
MELLOR, S. J.; CLARK, A. N.; FUTAGAMI, T. Model-driven development. IEEE Software,
v. 20, n. 5, p. 1418, 2003.
MERNIK, M.; HEERING, J.; SLOANE, A. M. When and how to develop domain-specific
languages. ACM Computing Surveys, v. 37, n. 4, p. 316344, dez. 2005. ISSN 0360-0300.
MILI, H. et al. Reuse-Based Software Engineering: Techniques, Organization, and Controls.
[S.l.]: John Wiley & Sons, 2002.
MILI, H.; MILI, F.; MILI, A. Reusing software: Issues and research directions. IEEE
Transactions on Software Engineering, v. 21, n. 6, p. 528562, 1995.
MILLER, G. et al. Panel - Model Driven Architecture: The realities, a year later. In: 19th
annual ACM SIGPLAN conference on Object-oriented programming systems, languages, and
applications (OOPSLA04). Vancouver, BC, Canada: ACM Press, 2004. p. 138140.
MODELWARE. Engineering Metrics Definition. [S.l.],
<http://www.modelware-ist.org/)>. Acesso em: 14 jun 2009.
MODELWARE.
MDD
Maturity
Model.
[S.l.],
MODELWARE. Standards Proposals Submitted. [S.l.],
2006.
2006.
2006.
Disponvel
Disponvel
Disponvel
em:
em:
em:
MOHAGHEGHI, P.; AAGEDAL, J. Evaluating quality in model-driven engineering. In:

MISE 07: Proceedings of the International Workshop on Modeling in Software Engineering.
Washington, DC, USA: IEEE Computer Society, 2007. p. 6. ISBN 0-7695-2953-4.
MOHAGHEGHI, P.; DEHLEN, V. Where is the proof? - a review of experiences from
applying MDE in industry. In: ECMDA-FA 08: Proceedings of the 4th European conference
on Model Driven Architecture. Berlin, Heidelberg: Springer-Verlag, 2008. p. 432443. ISBN
978-3-540-69095-5.
MONPERRUS, M. et al. A model-driven measurement approach. In: MoDELS 08:
Proceedings of the 11th international conference on Model Driven Engineering Languages and
Systems. Berlin, Heidelberg: Springer-Verlag, 2008. p. 505519. ISBN 978-3-540-87874-2.
MOON, M.; YEOM, K. An approach to developing domain requirements as a core asset based
on commonality and variability analysis in a product line. IEEE Transactions on Software
Engineering, v. 31, n. 07, p. 551569, 2005.
230
MOON, M.; YEOM, K. An approach to developing domain architectures based on variability

analysis. In: Computational Science and Its Applications - ICCSA 2006. [S.l.]: Springer Berlin
/ Heidelberg, 2006. (Lecture Notes in Computer Science, v. 3981/2006), p. 441450.
MORILLO, J. L. et al. Incremental software reuse. In: MORISIO, M. (Ed.). Reuse of
Off-the-Shelf Components, 9th International Conference on Software Reuse. Turin, Italy:
Springer, 2006. (Lecture Notes in Computer Science, v. 4039), p. 386389.
MORISIO, M.; EZRAN, M.; TULLY, C. Success and failure factors in software reuse. IEEE
Transactions on Software Engineering, v. 28, n. 04, p. 340357, 2002.
MUSKENS, J.; CHAUDRON, M.; LANGE, C. Investigations in applying metrics to multi-view
architecture models. In: EUROMICRO 04: Proceedings of the 30th EUROMICRO Conference.
Washington, DC, USA: IEEE Computer Society, 2004. p. 372379. ISBN 0-7695-2199-1.
MUSZYNSKI, M. Implementing a domain-specific modeling environment for a family of
thick-client gui components. In: The 5th OOPSLA Workshop on Domain-Specific Modeling,
San Diego USA. [S.l.: s.n.], 2005.
MUTHIG, D. et al. Technology Dimensions of Product Line Implementation Approaches State-of-the-art and State-of-the-practice Survey. [S.l.], September 2002.
MUTHIG, D.; PATZKE, T. Generic implementation of product line components. In: Objects,
Components, Architectures, Services and Applications for a Networked World. International
Conference NetObjectDays, NODe 2002, Erfurt, Germany, October 7-10, 2002. [S.l.]:
Springer-Verlag, 2003. (Lecture Notes in Computer Science, v. 2591).
MUTHIG, D.; PATZKE, T. Implementing software product lines - enhancing reusability
by systematically selecting and applying variability mechanisms. In: Multikonferenz
Wirtschaftsinformatik (MKWI) 2004. Band 1 : E-Learning: Modelle, Instrumente und
Erfahrungen. Software-Produktlinien. Communities in E-Business. Berlin: Akademische
Verlagsgesellschaft, 2004.
NAUR, P.; RANDELL, B. Report on NATO Software Engineering Conference. [S.l.], 1968.
NEIGHBORS, J. M. Software Construction Using Components. Tese (Ph.D. Thesis)
University of California at Irvine, 1980.
NEIGHBORS, J. M. Draco: A method for engineering reusable software systems. In:
BIGGERSTAFF, T. J.; PERLIS, A. J. (Ed.). Software Reusability, Volume 1 : Concepts and
Models. [S.l.]: Addison-Wesley, 1989. p. 295319.
OMG. MDA Guide Version 1.0.1. [S.l.], 2003. Disponvel em: <http://www.omg.org>. Acesso
em: 14 jun 2009.
OMG. MOF 2.0 Query / Views / Transformations Final Adopted Specification. [S.l.], 2005.
Disponvel em: <http://www.omg.org>. Acesso em: 14 jun 2009.
OMG. Catalog of UML Profiles Specifications. 2006. Disponvel em: <http://www.omg.org>.
Acesso em: 14 jun 2009.
OMG. Meta Object Facility Core Specification Version 2.0. [S.l.], 2006. Disponvel em:
<http://www.omg.org>. Acesso em: 14 jun 2009.
231
OMG. XML Metadata Interchange (XMI) Specification. [S.l.], 2006. Disponvel em:
OMG. Unified Modeling Language (OMG UML) Infrastructure. [S.l.], 2007. Disponvel em:
PARNAS, D. L. On the design and development of program families. IEEE Transactions on
Software Engineering, v. 2, n. 1, p. 19, mar. 1976.
PATZKE, T.; MUTHIG, D. Product Line Implementation Technologies - Programming
Language View. [S.l.], October 2002.
PREZ-MARTNEZ, J. E.; SIERRA-ALONSO, A. From analysis model to software
architecture: A PIM2PIM mapping. In: RENSINK, A.; WARMER, J. (Ed.). ECMDA-FA. [S.l.]:
Springer, 2006. (Lecture Notes in Computer Science, v. 4066), p. 2539. ISBN 3-540-35909-5.
PETRE, M. Why looking isnt always seeing: readership skills and graphical programming.
Commun. ACM, ACM, New York, NY, USA, v. 38, n. 6, p. 3344, 1995. ISSN 0001-0782.
PHOHA, V. A standard for software documentation. IEEE Computer, v. 30, n. 10, p. 9798,
1997.
PILGRIM, J. Measuring the level of abstraction and detail of models in the context of MDD.
In: Models in Software Engineering: Workshops and Symposia at MoDELS 2007, Nashville,
TN, USA, September 30 - October 5, 2007, revised selected papers. Berlin, Heidelberg:
Springer-Verlag, 2008. p. 105114. ISBN 978-3-540-69069-6.
POPMA, R. JET Tutorial Part 1 (Introduction to JET). May 2004. Eclipse Corner Article.
Disponvel em: <http://www.eclipse.org/articles/Article-JET/jet_tutorial1.html>. Acesso em:
14 jun 2009.
POULIN, J. Measuring software reusability. In: Proceedings of the 3rd IEEE International
Conference on Software Reuse (ICSR): Advances in Software Reusability, Rio de Janeiro,
Brazil. [S.l.: s.n.], 1994.
POULIN, J.; CARUSO, J.; HANCOCK, D. The business case for software reuse. IBM Systems
Journal, v. 32, n. 4, p. 567594, 1993.
POULIN, J. S.; CARUSO, J. M. A reuse metrics and return on investment model. In:
PRIETO-DIAZ, R.; FRAKES, W. B. (Ed.). Proceedings of 2nd ACM/IEEE International
Workshop on Software Reusability. [S.l.]: IEEE Computer Society Press / ACM Press, 1993. p.
152167. ISBN 0-8186-3130-9, 0-8186-3132-5, 0-8186-3131-7.
PRESSMAN, R. S. Software Engineering: A Practitioners Approach. [S.l.]: McGraw-Hill,
2005.
PRIETO-DAZ, R. Domain analysis: An introduction. ACM SIGSOFT Software Engineering
Notes, v. 15, n. 2, p. 4754, 1990.
PRIETO-DAZ, R. Making software reuse work: An implementation model. ACM SIGSOFT
Software Engineering Notes, v. 16, n. 3, p. 6168, 1991.
PRIETO-DAZ, R. Status report: Software reusability. IEEE Software, v. 10, n. 3, p. 6166,
1993. IEEE Computer Society Press. Los Alamitos, CA, USA.
232
PYSTER, A. B.; BARNES, B. H. The software productivity consortium reuse program.

In: COMPCON88, Digest of Papers, Thirty-Third IEEE Computer Society International
Conference. San Francisco, California, USA: IEEE Computer Society, 1988. p. 242249.
RABISER, R.; GRNBACHER, P.; DHUNGANA, D. Supporting product derivation by
adapting and augmenting variability models. In: SPLC. [S.l.]: IEEE Computer Society, 2007.
p. 141150. Disponvel em: <http://doi.ieeecomputersociety.org/10.1109/SPLINE.2007.22>.
RIBEIRO, M. de M.; MATOS, J. P.; BORBA, P. A decision model for implementing product
lines variabilities. In: SAC 08: Proceedings of the 2008 ACM symposium on Applied
computing. New York, NY, USA: ACM, 2008. p. 276277. ISBN 978-1-59593-753-7.
RINE, D. Success factors for software reuse that are applicable across domains and businesses.
In: ACM Symposium on Applied Computing. San Jose, California, USA: ACM Press, 1997. p.
182186.
RINE, D.; SONNEMANN, R. Investment in reusable software. a study on software reuse
investment success factors. The Journal of Systems and Software, v. 41, p. 1732, 1998.
RINE, D. C.; NADA, N. An empirical study of a software reuse reference model. Information
and Software Technology, v. 42, n. 1, p. 4765, 2000.
ROBBES, R.; LANZA, M. Example-based program transformation. In: CZARNECKI, K. et
al. (Ed.). MoDELS. [S.l.]: Springer, 2008. (Lecture Notes in Computer Science, v. 5301), p.
174188. ISBN 978-3-540-87874-2.
ROMBACH, D. Fraunhofer: The german model for applied research and technology transfer.
In: 22nd International Conference on Software Engineering (ICSE). Limerick, Ireland: ACM
Press, 2000. p. 2534.
ROTHENBERGER, M. A. et al. Strategies for software reuse: A principal component analysis
of reuse practices. IEEE Transactions on Software Engineering, v. 29, n. 09, p. 825837, 2003.
SAMETINGER, J. Software Engineering with Reusable Components. Berlin Heidelberg:
Springer-Verlag, 1997.
SANTOS, A. L.; KOSKIMIES, K.; LOPES, A. Automated domain-specific modeling
languages for generating framework-based applications. In:
SPLC. [S.l.]:
IEEE
Computer Society, 2008. p. 149158. ISBN 978-0-7695-3303-2. Disponvel em:
<http://dx.doi.org/10.1109/SPLC.2008.17>. Acesso em 14 jun 2009.
SCHMIDT, D. C. Guest editors introduction: Model-driven engineering. IEEE Computer,
v. 39, n. 2, p. 2531, 2006.
SCHMIDT, D. C. et al. Pattern-Oriented Software Architecture, Volume 2: Patterns for
Concurrent and Networked Objects. [S.l.]: John Wiley & Sons, 2000.
SEACORD, R.; PLAKOSH, D.; LEWIS, A. Modernizing Legacy Systems - Software
Technologies, Engineering Processes, and Business Practices. [S.l.]: Addison-Wesley, 2003.
SELIC, B. The pragmatics of model-driven development. IEEE Software, v. 20, n. 5, p. 1925,
2003.
233
SHERIF, K.; APPAN, R.; LIN, Z. Resources and incentives for the adoption of systematic
software reuse. International Journal of Information Management, v. 26, n. 1, p. 7080, 2006.
Available online 10 October 2005.
SILVA, M. F.; WERNER, C. M. L. Packaging reusable components using patterns and
hypermedia. In: 4th International Conference on Software Reuse. USA: [s.n.], 1996. p.
146155.
SIMOS, M. et al. Organization Domain Modeling (ODM) Guidebook Version 2.0. [S.l.], 1996.
SOMMERVILLE, I. Software Engineering. 8. ed. [S.l.]: Addison Wesley, 2006.
STARS. Software Technology for Adaptable Reliable Systems (STARS). The Reuse-Oriented
Software Evolution (ROSE). [S.l.], 1993.
STEFFEN, B. et al. Model-Driven Development with the jABC. In: Hardware and Software,
Verification and Testing. Berlin / Heidelberg: Springer-Verlag, 2007. (Lecture Notes in
Computer Science, v. 4383/2007), p. 92108.
SVAHNBERG, M.; GURP, J. van; BOSCH, J. A taxonomy of variability realization techniques:
Research articles. Softw. Pract. Exper., John Wiley & Sons, Inc., New York, NY, USA, v. 35,
n. 8, p. 705754, 2005. ISSN 0038-0644.
SVANHBERG, M.; GURP, J. van; BOSCH, J. A Taxonomy of Variability Realization
Techniques. [S.l.], 2002.
SZYPERSKI, C. Component Software: Beyond Object-Oriented Programming. [S.l.]: Addison
Wesley, 1999.
SZYPERSKI, C.; GRUNTZ, D.; MURER, S. Component Software: Beyond Object-Oriented
Programming - Second Edition. [S.l.]: Addison Wesley / ACM Press, 2002.
TAULAVUORI, A.; NIEMELA, E.; KALLIO, P. Component documentation-a key issue in
software product lines. Journal of Information and Software Technology, v. 46, n. 8, p. 535546,
2004.
THOMAS, D. MDA: Revenge of the modelers or uml utopia? IEEE Software, v. 21, n. 3, p.
1517, 2004.
TOLVANEN, J.-P. Making model-based code generation work. Embedded Systems Europe, v. 8,
n. 60, p. 3638, Aug/Sept 2004.
TOLVANEN, J.-P. Domain-Specific Modeling: How to Start Defining Your Own Language.
Feb 2005. Disponvel em: <http://www.devx.com/enterprise/Article/30550>. Acesso em: 14
jun 2009.
TOLVANEN, J.-P.; KELLY, S. Modelling languages for product families: A method
engineering approach. In: Proceedings of the 1st OOPSLA Workshop on Domain-Specific Visual
Languages - Tampa Bay, USA. [S.l.]: Jyvskyl University Printing House, Jyvskyl , Finland,
ISBN: 951-39-1056-3, ISSN: 0359-8470, 2001.
234
TOLVANEN, J.-P.; KELLY, S. Defining domain-specific modeling languages to automate

product derivation: Collected experiences. In: OBBINK, J. H.; POHL, K. (Ed.). 9th
International Software Product Line Conference (SPLC-Europe 2005). [S.l.]: Springer, 2005.
(Lecture Notes in Computer Science, v. 3714), p. 198209. ISBN 3-540-28936-4.
TRACZ, W. Domain-Specific Software Architecture (DSSA) pedagogical example. ACM
SIGSOFT Software Engineering Notes, v. 20, n. 3, p. 4962, 1995.
TRASK, B. et al. Using model-driven engineering to complement software product line
engineering in developing software defined radio components and applications. In: SPLC. [S.l.]:
IEEE Computer Society, 2006. p. 192202. ISBN 0-7695-2599-7.
UHL, A. Model Driven Architecture is ready for prime time. IEEE Software, v. 20, n. 5, p.
7071, 2003.
VANDOREN, E. Maintainability Index Technique for Measuring Program
Maintainability. [S.l.]: Software Engineering Institute (SEI), 1997. Disponvel em:
<http://www.sei.cmu.edu/str/>. Acesso em: 14 jun 2009.
VARR, D. Model transformation by example. In: NIERSTRASZ, O. et al. (Ed.). MoDELS.
[S.l.]: Springer, 2006. (Lecture Notes in Computer Science, v. 4199), p. 410424. ISBN
3-540-45772-0.
VISSER, E. WebDSL: A case study in domain-specific language engineering. In: LMMEL,
R.; VISSER, J.; SARAIVA, J. (Ed.). Generative and Transformational Techniques in Software
Engineering (GTTSE 2007). [S.l.]: Springer, 2007. (Lecture Notes in Computer Science,
v. 5235), p. 291373. ISBN 978-3-540-88642-6.
VLTER, M. A catalog of patterns for program generation. In: Eight European Conference on
Pattern Languages of Programs (EuroPLoP 2003), Irsee, Germany. [S.l.: s.n.], 2003.
VLTER, M. MD* Best Practices. December 2008. Disponvel em: <http://www.voelter.de>.
VLTER, M.; BETTIN, J. Patterns for model-driven software development. In: Ninth European
Conference on Pattern Languages of Programs (EuroPLoP 2004), Irsee, Germany. [S.l.: s.n.],
2004.
VLTER, M.; GROHER, I. Product line implementation using aspect-oriented and
model-driven software development. In: SPLC. [S.l.]: IEEE Computer Society, 2007.
p. 233242. Disponvel em: <http://doi.ieeecomputersociety.org/10.1109/SPLINE.2007.23>.
VOTH, D. Packaging reusable software assets. IEEE Software, v. 21, n. 3, p. 107110, 2004.
W3C. XML Path Language (XPath) Version 1.0 - W3C Recommendation 16 November 1999.
[S.l.], 1999.
W3C. XSL Transformations (XSLT) Version 1.0 - W3C Recommendation 16 November 1999.
[S.l.], 1999.
WARMER, J.; KLEPPE, A. Building a flexible software factory using partial domain specific
models. In: Proc. of The 6th OOPSLA Workshop on Domain-Specific Modeling. [S.l.: s.n.],
2006.
235
WEIS, T.; ULBRICH, A.; GEIHS, K. Model metamorphosis. IEEE Software, v. 20, n. 5, p.
4651, 2003.
WEISS, D.; LAI, C. T. R. Software Product-Line Engineering: A Family-Based Software
Development Process. [S.l.]: Addison Wesley, 1999.
WEISS, D. M. et al. Decision-model-based code generation for SPLE. In: SPLC. [S.l.]:
IEEE Computer Society, 2008. p. 129138. ISBN 978-0-7695-3303-2. Disponvel em:
<http://dx.doi.org/10.1109/SPLC.2008.42>. Acesso em: 14 jun 2009.
WILE, D. Lessons learned from real DSL experiments. Sci. Comput. Program., Elsevier
North-Holland, Inc., Amsterdam, The Netherlands, The Netherlands, v. 51, n. 3, p. 265290,
2004. ISSN 0167-6423.
WIMMER, M. et al. Towards model transformation generation by-example. In: 40th Hawaii
International Conference on System Sciences (HICSS07). Hawaii: [s.n.], 2007.
WOHLIN, C. et al. Experimentation in Software Engineering: An Introduction. [S.l.]: Kluwer
Academic Publishers, 2000.
ZAREMSKI, A. M.; WING, J. M. Signature matching: A tool for using software libraries. ACM
Transactions on Software Engineering and Methodology, v. 4, n. 2, p. 146170, 1995.
ZHANG, Y. Test-driven modeling for model-driven development. IEEE Software, v. 21, n. 5, p.
8086, 2004.
ZHANG, Y.; SHETH, D. Mining software repositories for model-driven development. IEEE
Software, v. 23, n. 1, 2006.
237
APNDICE A -- Tcnicas para reutilizao de

software
O mtodo mais simples de reutilizao conhecido e utilizado por praticamente todo

desenvolvedor, sob o nome informal de copiar e colar. A funo que permite realizar
a cpia ou duplicao do objeto de trabalho est presente em quase todas as aplicaes e
sistemas operacionais existentes na atualidade. Por exemplo, possvel copiar texto de um
local para outro, permitindo assim que um desenvolvedor reutilize trechos de cdigo. Outras
ferramentas de auxlio Engenharia de Software, tais como as ferramentas de modelagem,
tambm permitem que sejam duplicados desenhos e outros elementos de modelagem.
Esse tipo de reutilizao acontece quando um desenvolvedor est trabalhando em alguma
atividade do processo de software, e se depara com uma situao na qual ele se lembra de um
artefato (cdigo ou no), que ele j construiu, utilizou, ou que de alguma maneira saiba existir.
Ele ento localiza este artefato, identifica as partes que lhe sero teis, e copia para o local onde
est trabalhando, realizando as modificaes necessrias para integr-lo ao novo contexto.
Analisando-se esse processo cotidiano, pode-se identificar os quatro conceitos citados por
Krueger (1992):
Abstrao: a abstrao existe na mente do desenvolvedor, de maneira informal, e formada
durante a sua experincia pessoal como Engenheiro de Software. Ele no se lembra
exatamente de todos os detalhes dos artefatos com os quais j se deparou. Porm, ele
capaz de abstrair os detalhes, relevando somente o que essencial, formando uma espcie
de biblioteca reutilizvel indexada em sua memria;
Seleo: da mesma forma com que consegue abstrair os detalhes, o desenvolvedor tambm
capaz de utilizar a sua memria seletiva para determinar se o artefato satisfaz suas
necessidades, e fornecer pistas de onde encontr-lo. Este momento corresponde seleo,
quando o desenvolvedor, utilizando essas pistas, se lembra, primeiro, do software ou
biblioteca onde o artefato se encontra localizado. Em seguida, ele percorre a estrutura e
238
documentao do software, navegando, por exemplo, por meio da diviso em pacotes ou

bibliotecas, em busca do artefato lembrado por sua memria;
Adaptao: encontrado, o artefato copiado para seu novo local. A adaptao ocorre somente
se necessrio, configurando-o por meio de parmetros ou de mecanismos de extenso ou
mesmo modificando seu cdigo manualmente; e
Integrao: a integrao normalmente consiste em modificar o artefato, o contexto, ou ambos,
para que possam compor a funcionalidade desejada (KRUEGER, 1992).
Essa abordagem, apesar de proporcionar ganhos de produtividade, apresenta alguns
problemas, tais como:
Uma vez que o artefato normalmente modificado, necessrio test-lo novamente
para garantir que as modificaes no introduziram nenhum erro novo;
Os processos de abstrao e seleo dependem muito do talento individual e da
experincia do desenvolvedor, pois se baseiam muito na memria humana; e
Caso o desenvolvedor no conhea o artefato sendo reutilizado, ele precisa gastar algum
tempo compreendendo-o antes de copi-lo para o novo contexto. Desta forma, caso esse
tempo seja muito grande, o que ocorre na maioria dos casos envolvendo cdigo-fonte
que ele acaba optando por desenvolver um novo artefato a partir do zero (DESOUZA;
AWAZU; TIWANA,
2006).
Por esses e outros motivos, a pesquisa vem evoluindo na busca por novos mtodos e tcnicas
que evitem tais tipos de problemas. A seguir, so apresentadas as principais abordagens voltadas
para reutilizao de software existentes na literatura, destacando-se o desenvolvimento baseado
em componentes (SAMETINGER, 1997; SZYPERSKI; GRUNTZ; MURER, 2002), linguagens
especficas de domnio (DEURSEN; KLINT; VISSER, 2000), programao generativa (CZARNECKI;
EISENECKER,
2000), e outras tcnicas, tais como frameworks (JOHNSON, 1997b), padres
(BUSCHMANN et al., 1996) e reengenharia de software (JACOBSON; LINDSTROM, 1991).

Desenvolvimento Baseado em Componentes
Dentre as tcnicas utilizadas para se alcanar os benefcios da reutilizao, destaca-se o
desenvolvimento baseado em componentes (DBC). At alguns anos atrs, o desenvolvimento
da maioria dos produtos de software era baseado em blocos monolticos, formados por um
239
grande nmero de partes inter-relacionadas e, na maioria das vezes, essa relao entre as partes
era implcita. O DBC surgiu como uma nova perspectiva para desenvolvimento de software,
na qual a analogia de quebrar esses blocos monolticos em componentes intercambiveis,
diminuindo a complexidade e explicitando a relao entre as partes que compem o software.
A idia de componentes de software no nova. Em 1968, durante uma conferncia da
OTAN sobre Engenharia de Software, o foco era a crise do software - o problema de se construir
sistemas de software grandes e confiveis de uma maneira controlvel e eficiente. Desde o
incio, a reutilizao foi considerada como uma maneira de solucionar a crise do software.
Um artigo apresentado na conferncia, intitulado Componentes de Software Produzidos em
Massa, por McIlroy (MCILROY, 1968), se tornou um dos mais revolucionrios da rea de
reutilizao. Nas palavras de McIlroy: a indstria de software fracamente fundada e um dos
motivos dessa fraqueza a ausncia de uma indstria de sub-componentes.
Apesar de serem antigas, as idias de McIlroy ainda no foram concretizadas. O prprio
conceito de componentes ainda no bem definido, sendo que desde o primeiro workshop
de DBC, em 1998 em Kyoto, vrias definies foram apresentadas, cada uma evidenciando
um aspecto especfico do componente. Um conceito bastante satisfatrio apresentado por
Szyperski (1999): um componente de software uma unidade de composio com interfaces
bem especificadas em contrato e dependncias explcitas do contexto. Um componente de
software pode ser independentemente implantado e pode ser composto por terceiros.
As interfaces bem especificadas so importantes para formar uma camada comum entre
o reutilizador (uma pessoa que utiliza o componente) e o desenvolvedor do componente. As
dependncias explcitas definem o que o ambiente deve fornecer para que o componente possa
executar sua funo. Uma vez satisfeitas estas dependncias explcitas, o componente deve
poder ser implantado sem a necessidade de resolver dependncias adicionais. Finalmente, para
que ele possa ser composto por terceiros, ele deve ser suficientemente auto-contido, ou seja, a
funo por ele desempenhada deve ser totalmente implementada dentro dele.
Um componente no totalmente independente dos outros componentes e do ambiente.
As suas interfaces so importantes justamente para explicitar quais so esses pontos de
dependncia. Szyperski (1999) define uma interface como um conjunto de assinaturas de
operaes que podem ser chamadas por uma aplicao. De acordo com Heineman e Councill
(2001), h dois tipos de interfaces: interfaces providas, que descrevem as funcionalidades que
o componente fornece, e as interfaces requeridas, que descrevem as funcionalidades das quais
o componente depende para funcionar.
Os quatro conceitos identificados por Krueger (1992) tambm esto presentes nessa
240
abordagem, conforme descritos a seguir:
Abstrao: a abstrao alcanada por meio do encapsulamento das funes desempenhadas

pelo componente, de forma que o desenvolvedor no tome conhecimento dos detalhes
de implementao. Em outras palavras, a parte visvel corresponde interface do
componente, enquanto que a parte escondida corresponde sua implementao. Para se
conseguir essa separao, podem ser utilizados, por exemplo, os conceitos da orientao
a objetos, como herana e polimorfismo. Tambm podem ser criadas descries em
linguagem natural que permitam ao desenvolvedor identificar as funes desempenhadas
pelo componente sem a necessidade de conhecer sua estrutura interna;
Seleo: para o processo de seleo, normalmente os catlogos de componentes dispem de
uma estrutura organizada de forma a facilitar a sua navegao. Tambm comum o
uso de mecanismos automticos de busca, que reduzem o tempo necessrio para que o
desenvolvedor encontre aquilo que est procurando. Existe uma vasta literatura em torno
desse assunto, conforme pode ser visto em (LUCRDIO; ALMEIDA; PRADO, 2004);
Adaptao: a adaptao do componente normalmente feita por meio de sua parametrizao,
na qual o reutilizador especifica parmetros para que o componente possa executar sua
funo no contexto em que est sendo reutilizado. Porm, normalmente a parametrizao
s possvel nos casos previstos durante o projeto do componente.
Adaptar um
componente para que ele execute em um cenrio imprevisto pode exigir que o mesmo
seja modificado internamente. Neste caso, se o esforo necessrio para essa modificao
for muito grande, pode ser mais vantajoso tentar renegociar com o cliente os requisitos
da aplicao do que modificar o prprio componente; e
Integrao: a integrao consiste no acoplamento das interfaces requeridas pelo componente
com as interfaces providas pelo restante da aplicao. Normalmente esse acoplamento
exige alguma modificao na aplicao.
Diferentemente da abordagem copiar e colar, um componente, ao ser reutilizado, no

precisa ser novamente testado caso no tenha sido modificado. Alm disso, a existncia de
uma interface bem definida, assim como os mecanismos de classificao e busca, fazem com
que o desenvolvedor no precise confiar tanto em sua memria para encontrar um componente
candidato reutilizao.
Apesar dessas vantagens, o desenvolvimento baseado em componentes apresenta alguns
problemas que tornam sua adoo difcil por parte das organizaes de software. Uma pesquisa
241
realizada pelo Instituto de Engenharia de Software da Carnegie Mellon University (CMU/SEI)

identificou os principais problemas, sendo que os quatro mais relevantes so (BASS et al., 2000):
Falta de componentes disponveis;
Falta de padres estveis para as tecnologias de componentes;
Falta de componentes certificados; e
Falta de um mtodo de engenharia para produzir sistemas com componentes
(desenvolvimento com reutilizao), de maneira consistente e com qualidade.

Observando inicialmente esses problemas, pode-se concluir que o ltimo (falta de um
mtodo de engenharia) um ponto fundamental, pois sem um mtodo o qual as organizaes
de software possam seguir, no possvel suprir a falta de componentes, e menos ainda a falta
de componentes certificados, uma vez que esse desenvolvimento ir depender exclusivamente
da experincia e competncia individual dos desenvolvedores.
Linguagens especficas de domnio
O termo Linguagem Especfica de Domnio (DSL - Domain-Specific Language) exige
ateno especial, pois se baseia em uma noo muito vaga, que a palavra Domnio,
utilizada com diferentes significados em diferentes reas. Para esclarecer o conceito de domnio
considerado nesta pesquisa, a Figura 41 apresenta um exemplo da situao clssica vivida
durante o processo de anlise de sistemas.
O desenvolvimento de sistemas envolve normalmente a captura do conhecimento de um
especialista de alguma rea (no exemplo, um especialista financeiro), e sua representao em
uma forma que facilite o desenvolvimento de uma soluo computacional. papel do analista
de sistemas traduzir os termos e conceitos familiares ao especialista para termos e conceitos de
computao, familiares ao desenvolvedor.
Neste contexto, a palavra domnio refere-se a uma determinada rea de competncia e
conhecimento, que possui terminologia e conceitos particulares. No exemplo, os termos
e conceitos financeiros, isto , Aes, ndices e Cotaes, esto dentro da rea de
competncia e conhecimento do especialista financeiro. Este , portanto, o domnio financeiro.
Os termos e conceitos do desenvolvimento de software, isto , Casos de uso, Classes,
Objetos, Mtodos, as palavras-chave if, while, entre outras, esto dentro da rea de
competncia e conhecimento do desenvolvedor. Alguns desses termos fazem parte do domnio
242
Figura 41: Situao clssica da anlise de sistemas
de modelagem. Outros fazem parte do domnio executvel, enquanto outros fazem parte de
ambos.
Uma outra possvel distino feita no momento em que o analista realiza essa traduo
dos termos do domnio financeiro para os termos dos domnios de modelagem e executvel. No
contexto de desenvolvimento de sistemas, o domnio para o qual se est construindo um sistema
chamado de domnio do problema, pois trata-se do problema que se pretende resolver. O
domnio no qual se est construindo o sistema chamado de domnio da soluo, pois ele
representa a soluo computacional que est sendo desenvolvida.
Em reutilizao de software, a palavra domnio normalmente utilizada como um sinnimo
de Domnio do Problema. Ou seja, quando se fala em aplicaes de um domnio, ou um
domnio de aplicaes, se fala em um conjunto de aplicaes que compartilham os mesmos
termos e conceitos, e que so especficas para uma mesma rea de conhecimento. Assim, o
domnio financeiro, por exemplo, no contexto da reutilizao de software, compreende todas as
aplicaes financeiras.
A partir dessa definio, uma linguagem especfica de domnio uma linguagem qualquer
que representa os termos e conceitos do domnio. Por exemplo, Java uma linguagem de um
domnio executvel, UML uma linguagem de um domnio de modelagem, e assim por diante.
Mas atualmente, quando se fala em linguagens especficas de um domnio, normalmente se
est querendo dizer linguagens especficas de um domnio de problema. Dessa forma, chega-se
seguinte definio (DEURSEN; KLINT; VISSER, 2000).
Uma linguagem especfica de domnio uma linguagem de programao ou uma
243
linguagem de especificao executvel que oferece, por meio de notaes e abstraes

apropriadas, poder expressivo focado em, e normalmente restrito a, um domnio de um
problema particular.
De acordo com essa definio, uma linguagem do domnio financeiro tida como uma
DSL, enquanto Java e UML no o so.
Uma DSL no necessariamente utilizada com objetivo de gerar um programa executvel
(FOWLER, 2005). Em muitos casos, pode-se utilizar uma DSL com fins de configurao, por
exemplo. Um arquivo XML de configurao de acesso a banco pode ser visto como uma
especificao em uma DSL, pois ele contm termos e conceitos associados ao problema de
acesso a banco de dados. Outro exemplo so os processadores de texto do tipo LATEX, que usam
uma linguagem prpria com o propsito de produzir documentos formatados.
Porm, no caso da reutilizao de software, DSLs normalmente so utilizadas com o
propsito de se produzir um programa executvel (WARMER; KLEPPE, 2006), reaproveitando
o conhecimento especfico daquele domnio. A seguir discute-se esse tipo de uso para DSLs.
Linguagens especficas de domnio so mais uma expresso da dicotomia entre abordagens
genricas (que oferecem solues para mltiplas reas, porm de forma no otimizada), e
abordagens especficas (que oferecem solues melhores, porm apenas para um subconjunto
de problemas), presente na maioria dos ramos da cincia e da engenharia (DEURSEN; KLINT;
VISSER,
2000).
As atuais linguagens de programao, como Java, C++, e C#, so exemplos de linguagens

de propsito genrico, ou seja, ao criar sistemas para diferentes domnios de problema, pode-se
utilizar a mesma linguagem. O mesmo acontece para linguagens de modelagem, como a UML,
por exemplo, que pode ser utilizada em diferentes cenrios.
No entanto, essas linguagens apresentam o problema de exigirem um certo esforo de
traduo para expressar solues ou modelos especficos para um determinado problema
utilizando construes genricas. Alm disso, esse esforo de traduo precisa ser praticamente
repetido toda vez que se for construir uma aplicao diferente para aquele mesmo domnio. Para
resolver esse problema, trs abordagens tm sido adotadas (DEURSEN; KLINT; VISSER, 2000):
1. Bibliotecas de subrotinas: consistem em subrotinas que realizam tarefas especficas
para um domnio de problema, de forma que o desenvolvedor, ao reutilizar essas
subrotinas, tambm reutiliza conhecimento especfico para esse domnio;
2. Frameworks orientados a objetos e frameworks de componentes: estendem a idia de
bibliotecas de subrotinas. Enquanto bibliotecas possuem uma estrutura simples, com as
244
subrotinas sendo chamadas pela aplicao, os frameworks normalmente esto no controle,

sendo os responsveis por chamar o cdigo especfico da aplicao; e
3. Linguagens especficas de domnio (DSL): so linguagens pequenas, normalmente
declarativas, com poder expressivo focado em um domnio de problema. Normalmente,
programas em DSL so convertidos para programas em linguagens comuns, utilizando
frameworks ou bibliotecas de subrotinas. Dessa forma, pode-se pensar em uma DSL
como uma maneira de esconder os detalhes da biblioteca ou framework.
Do ponto de vista da reutilizao, todas essas abordagens so similares, apresentando um
nico propsito: reutilizar o conhecimento do domnio na construo de aplicaes daquele
domnio. Seja na forma de chamadas de rotinas de uma biblioteca ou utilizando uma linguagem,
o resultado final praticamente o mesmo, com diferenas apenas na forma de expresso da
soluo. De fato, Martin Fowler, um conceituado pesquisador na rea de reutilizao, destaca
que sempre considerou o fato de definir funes e bibliotecas como uma forma de se construir
uma DSL para um problema (FOWLER, 2005).
Independentemente da abordagem adotada, a principal caracterstica de uma DSL o
fato de ela ter seu poder expressivo focado em um domnio do problema, o que reduz o
esforo de traduo necessrio para construir programas, pois os termos da linguagem esto
prximos dos termos reais conhecidos pelo especialista daquele domnio. Portanto, DSLs
so normalmente pequenas, consistindo de um conjunto de abstraes e notaes restritos a
um domnio, de forma que especialistas daquele domnio possam trabalhar nessa linguagem
facilmente. Por este motivo, so tambm conhecidas como micro-linguagens ou linguagens
pequenas, principalmente pelos usurios do Sistema Operacional Unix (FOWLER, 2005).
A utilizao de DSLs apresenta vantagens e desvantagens.
Dentre as vantagens,
destacam-se (DEURSEN; KLINT; VISSER, 2000):

DSLs permitem que solues sejam expressas nos termos e no nvel de abstrao do
domnio do problema. Consequentemente, especialistas do domnio podem compreender,
validar, modificar, ou mesmo desenvolver seus prprios programas;
Programas DSLs so concisos, auto-documentados, e podem ser reutilizados com
diferentes propsitos;
DSLs aumentam a produtividade, confiabilidade, manutenibilidade e portabilidade;
DSLs incorporam conhecimento sobre o domnio, e portanto possibilitam sua

conservao e reutilizao;
245
DSLs possibilitam validao e otimizao no nvel do domnio; e

DSLs facilitam a testabilidade das aplicaes.
As desvantagens de se utilizar DSL so (DEURSEN; KLINT; VISSER, 2000):

O custo para se projetar, implementar e manter uma DSL;
O custo de treinamento para usurios da DSL;
A pouca disponibilidade de DSLs;
A dificuldade de se definir um escopo adequado para uma DSL;
A dificuldade de se balancear entre especificidade ao domnio e linguagens de
programao genricas; e
Para os casos de DSLs executveis, a perda potencial de desempenho quando
comparado com cdigo construdo mo.
Alguns dos benefcios das DSLs, como aumento da produtividade, confiabilidade,

manutenibilidade, portabilidade, a reutilizao de conhecimento sobre o domnio, entre outros,
podem ser igualmente alcanados por meio da utilizao de frameworks, descritos mais adiante
neste apndice, ou outras tcnicas de reutilizao. Dessa forma, frente s suas desvantagens,
pode-se argumentar que em alguns casos o uso de DSLs desnecessrio. J outros benefcios,
como a possibilidade de se trabalhar nos termos e no nvel de abstrao do domnio do problema,
s podem ser obtidos por meio de DSLs. Neste sentido, a deciso de se utilizar ou no essa
tcnica se resume anlise dos benefcios obtidos versus o custo necessrio para construir as
ferramentas necessrias para oferecer um suporte eficiente para DSLs (FOWLER, 2005).
Esse custo depende da forma escolhida para se implementar o suporte para a DSL. Aps a
anlise do domnio e projeto da DSL, existem duas alternativas principais para se implementar
esse suporte:
1. Compilador/interpretador: a forma mais comum de se implementar uma DSL

envolve construir uma biblioteca que implementa as noes semnticas, e projetar e
implementar um compilador que traduza programas na DSL para chamadas a essa
biblioteca (DEURSEN; KLINT; VISSER, 2000). Esse tipo de abordagem tambm conhecido
como DSL externa (FOWLER, 2005); e
246
2. Linguagem embutida: nesse tipo de DSL, tambm conhecida como DSL interna
(FOWLER, 2005), uma linguagem de programao genrica estendida com conceitos e
operaes do domnio. A principal vantagem que o prprio compilador da linguagem
base pode ser utilizado. Em contrapartida, a expressividade da linguagem estendida
limitada ao poder expressivo da linguagem base (DEURSEN; KLINT; VISSER, 2000). Por
exemplo, a UML (OMG, 2007), com seu mecanismo de extenso, possibilita a criao
de linguagens de modelagens especficas de forma bastante razovel. Os perfis UML
(OMG, 2006a) so um exemplo desse poder. A linguagem LISP, ou outras linguagens
adaptveis, tambm so exemplos dessa possibilidade. J a linguagem Java no possui
um mecanismo simples de extenso, dificultando o uso de linguagens embutidas.
Enquanto a primeira abordagem resulta em uma DSL mais limpa e fcil de ser utilizada, ela
requer maior trabalho para implementar o compilador. J a segunda abordagem mais rpida
e simples de ser implementada, pois no requer a construo de um compilador. Porm, os
resultados no so to satisfatrios como na primeira abordagem.
Com relao a linguagens visuais, at pouco tempo o uso do mecanismo de extenso da
UML era uma das nicas possibilidades. Recentemente, com as idias do desenvolvimento
orientado a modelos, novas tecnologias surgiram para facilitar esse trabalho. So os chamados
frameworks de linguagens, que implementam diversas funes necessrias para a modelagem
visual, como a representao, criao e edio de diagramas, e o processamento automtico de
suas informaes internas. Exemplos incluem o GME (Generic Modeling Environment)1 e o
GMF (Graphical Modeling Framework)2 .
Analisando a abordagem de DSLs como uma forma de reutilizao de software, pode-se
notar que os quatro conceitos da reutilizao tambm esto presentes:
Abstrao: o processo de anlise de um domnio de problema, levantamento de informaes
relacionadas, e seu encapsulamento em forma de uma linguagem e uma biblioteca
contendo as noes semnticas, corresponde abstrao. O conhecimento reutilizvel
do domnio abstrado e expresso em uma linguagem, de forma que um desenvolvedor
pode facilmente reconhec-lo e reutiliz-lo. Essa a parte visvel da abstrao. O
detalhamento e a implementao das noes semnticas associadas a cada conceito
correspondem parte escondida da abstrao;
Seleo: uma vez que a DSL esteja construda, o desenvolvedor precisa conhecer a sintaxe e a
semntica por trs de cada construo da linguagem. A seleo dos artefatos reutilizveis
1 http://www.isis.vanderbilt.edu/projects/gme/
2 http://www.eclipse.org/gmf/
247
ento feita pelo desenvolvedor, que escolhe mentalmente os termos e conceitos da

linguagem a serem utilizados durante a construo de um programa ou criao de um
modelo. Ele pode tambm consultar a gramtica ou manual da linguagem, para ajud-lo
a determinar o que precisa utilizar;
Adaptao: a adaptao ocorre normalmente por meio de parmetros definidos na prpria
linguagem, com os quais o desenvolvedor adiciona detalhes especficos da situao; e
Integrao: por fim, a integrao normalmente realizada de forma automtica por um
compilador ou interpretador, que ir executar as aes semnticas associadas aos termos
da DSL, integrando os elementos sendo reutilizados em um aplicativo executvel.
Quando o aplicativo gerado a partir de um compilador DSL, pode-se tambm dizer
que se trata de um gerador de aplicaes, assunto da prxima seo.
Programao generativa
Programao generativa (generative programming) a automao da manufatura de
produtos intermedirios e finais (i.e., componentes e aplicaes.) (CZARNECKI; EISENECKER,
2000).
Essa definio resume o conceito de programao generativa, que vem sendo utilizado
desde os primrdios da computao. Significa que parte ou a totalidade dos artefatos produzidos
durante o ciclo de vida do software gerada automaticamente. Por exemplo, compiladores
que utilizam como entrada um programa em uma linguagem de programao, e geram como
sada o cdigo executvel para uma plataforma, esto entre os primeiros exemplos de uso da
programao generativa.
Outro exemplo so os construtores de interface, tais como aqueles presentes em softwares
como Microsoft Visual Studio3 e NetBeans4 .
O desenvolvedor especifica a interface
visualmente, e todo o cdigo que a implementa automaticamente gerado. Caso precise realizar
alguma modificao, o desenvolvedor a realiza diretamente no editor visual, e o cdigo que
reflete essa mudana gerado novamente.
A programao generativa pode ser utilizada em outras etapas do ciclo de vida do software.
Pode-se gerar casos de teste, esquemas de banco de dados, ou mesmo programas completos. Os
benefcios dessa abordagem so bvios: poupa-se o tempo gasto em atividades repetitivas, como
tarefas de implementao de infra-estrutura, aproveitando-o em atividades mais importantes,
como anlise e projeto.
3 http://msdn.microsoft.com/vstudio/
4 http://www.netbeans.org/
248
Alm de proporcionar os ganhos diretos em termos de tempo de desenvolvimento, a

abordagem generativa tambm promove a reutilizao. Um gerador encapsula o conhecimento
do domnio necessrio para que sejam produzidos artefatos ou mesmo aplicaes completas
daquele domnio. Em outras palavras, a reutilizao desse conhecimento ocorre quando se
reutiliza o processo de gerao, e no os componentes (SAMETINGER, 1997).
Um elemento necessrio para a abordagem generativa o formato da entrada fornecida
a um gerador. Normalmente, utiliza-se uma DSL, ou seja, uma linguagem especializada e
orientada ao problema (CZARNECKI; EISENECKER, 2000). Desta forma, o desenvolvedor pode
criar as especificaes de forma mais prxima ao problema, o que exige um menor esforo de
especificao.
Essa DSL pode ser to especializada quanto o necessrio para o problema sendo modelado.
Por exemplo, para modelar um produto matemtico, a DSL precisa ser bem especfica, com
elementos formais que permitam representar conceitos matemticos. Outro exemplo o caso
de um editor de interfaces, onde a DSL visual, sendo composta dos elementos bsicos de uma
interface, como botes, caixas de texto, barras de rolagem, entre outros.
Pode-se tambm utilizar templates como entrada para um gerador. Um template consiste
em uma estrutura pr-definida que representa o artefato final semi-concludo, com pontos em
aberto que podem ser preenchidos atravs de variveis especificadas pelo desenvolvedor.
Um dos problemas da programao generativa ocorre quando se deseja modificar os
artefatos gerados. Por mais genrico e flexvel que seja o gerador, o artefato gerado pode no
corresponder exatamente s necessidades do desenvolvedor. Neste caso, o desenvolvedor pode
modificar o gerador, para atender s suas necessidades, ou modificar o artefato gerado.
Modificar o gerador pode ser uma tarefa custosa.
Normalmente os geradores so
ferramentas especficas para um determinado domnio de problema, de forma que introduzir

modificaes sem a perda de compatibilidade com esse domnio exige uma anlise demorada.
Alm disso, deve-se realizar essas mudanas de forma genrica, pensando-se no somente no
artefato que se deseja modificar, mas em todos os artefatos que sero gerados a partir de ento.
Por outro lado, modificar o produto do gerador muito mais fcil, pois pode-se trabalhar
diretamente no artefato que se deseja modificar. Porm, essas mudanas podem se perder caso
o artefato seja re-gerado. Para resolver esse problema, normalmente so utilizadas tcnicas
associadas ao conceito de round-trip engineering (HENRIKSSON; LARSSON, 2003; ANTKIEWICZ;
CZARNECKI,
2006; HETTEL; LAWLEY; RAYMOND, 2008). Essas tcnicas so baseadas em
engenharia reversa (HENRIKSSON; LARSSON, 2003), e visam abstrair as mudanas realizadas

diretamente nos artefatos gerados, duplicando-as nas especificaes de origem. Dessa forma,
249
as mudanas no se perdem, estando presentes nas prximas geraes de artefatos.

Uma abordagem mais simples consiste em no permitir que certas mudanas sejam
realizadas. Um exemplo de ferramenta que utiliza essa abordagem a plataforma NetBeans:
o editor textual de cdigo de interface desta plataforma bloqueia certos trechos de cdigo,
associados com caractersticas estruturais da interface, de forma que o desenvolvedor s pode
inserir essas modificaes por meio do editor visual. Essa abordagem, porm, restrita aos
casos onde se pode bloquear modificaes sem perder a flexibilidade necessria para se resolver
os problemas daquele domnio.
A abordagem generativa tambm pode ser analisada frente aos quatro conceitos da
reutilizao descritos por Krueger (1992):
Abstrao: conforme j discutido anteriormente, o que est sendo reutilizado o processo de
construo dos artefatos, e no os artefatos em si. A abstrao desse processo consiste na
definio do formato de entrada do gerador, seja ele uma DSL visual, textual, ou mesmo
parmetros que preenchem um ou mais templates. Essa definio corresponde parte
visvel da abstrao, com a qual o desenvolvedor trabalha. A parte escondida fica dentro
gerador, e responsvel pelos detalhes de implementao;
Seleo: a seleo consiste em escolher um gerador apropriado para o problema em questo.
Diferentes geradores correspondem a diferentes processos para se produzir os artefatos
do domnio, e pode-se decidir por um deles, dependendo do problema. Neste cenrio, a
situao ideal seria manter uma biblioteca de geradores de aplicao, e utilizar tcnicas
de classificao e busca para facilitar a seleo, de forma similar s bibliotecas de
componentes reutilizveis. Porm, essa situao requer a existncia de um grande nmero
de geradores para um mesmo domnio de problema. Em 1992, Krueger destacava a
escassez de geradores, que alm de poucos eram normalmente restritos a um nmero
reduzido de domnios (KRUEGER, 1992). Atualmente, com a evoluo das tecnologias
necessrias para a programao generativa, principalmente a transformao de software,
o nmero de geradores vem crescendo. Em (ALLILAIRE et al., 2006), os autores exploram
o gerenciamento de repositrios de modelos e transformaes de software, utilizando
tcnicas similares s utilizadas em repositrios de componentes;
Adaptao: a adaptao a tarefa primria realizada por um desenvolvedor de software
utilizando um gerador de aplicaes (KRUEGER, 1992).
Corresponde tarefa de
especificao que produz a entrada requerida pelo gerador, normalmente um programa em

uma DSL. O desenvolvedor utiliza essa DSL para informar ao gerador como especializar
os conceitos do domnio e produzir uma soluo para o seu problema; e
250
Integrao: a integrao no um problema quando um gerador produz um programa

completo (KRUEGER, 1992). Porm, nos casos onde apenas parte dos artefatos gerada,
necessrio que os mesmos sejam integrados com outras partes, sejam estas geradas
automaticamente ou manualmente. Para que essa integrao seja automtica, os geradores
precisam estar preparados e cientes do ambiente ao qual os artefatos gerados sero
integrados. Desta forma, os desenvolvedores podem trabalhar somente no nvel de
abstrao da entrada do gerador, especificando o que for necessrio para que o gerador
possa realizar essa integrao sozinho. Porm, essa a situao ideal. Em outros casos,
a nica soluo modificar manualmente os artefatos gerados de forma a promover sua
integrao.
Vale a pena ressaltar que os conceitos de programao generativa, principalmente quando

se pensa em reutilizao de software, muitas vezes se confundem com os conceitos ligados s
linguagens especficas de domnio. Czarnecki e Eisenecker (2000), autores de um dos principais
livros sobre programao generativa, destacam a importncia das DSLs nessa abordagem.
Cleaveland (1988) utiliza os termos Linguagem de quarta gerao e Linguagem orientada
aplicao ao invs de DSL, mas os conceitos de geradores de aplicaes que ele apresenta
correspondem a um compilador DSL (DEURSEN; KLINT; VISSER, 2000).
A proximidade destas duas reas tambm se reflete na evoluo das tecnologias envolvidas e
da pesquisa acadmica e industrial. O desenvolvimento orientado a modelos, foco deste trabalho
de pesquisa, um exemplo recente que rene os conceitos de DSL e programao generativa.
Frameworks Orientados a Objetos
Frameworks orientados a objetos ou frameworks de componentes estendem as idias de

bibliotecas de subrotinas e de componentes. A principal diferena, e uma das principais
caractersticas dos frameworks, a inverso de controle: enquanto com bibliotecas comuns a
aplicao responsvel por realizar chamadas aos artefatos sendo reutilizados, um framework
responsvel por realizar chamadas aplicao, detendo o fluxo de controle (DEURSEN; KLINT;
VISSER,
2000), (JOHNSON, 1997a) apud (BRAGA, 2002).
Estruturalmente, pode-se definir um framework como um conjunto de classes que contm

o projeto abstrato de solues para uma famlia de problemas relacionados (JOHNSON; FOOTE,
1988) apud (BRAGA, 2002). Essas classes encapsulam conhecimento sobre essa famlia de
problemas, ou sobre esse domnio de problema, que pode ser reutilizado da mesma forma com
que se reutilizam componentes de software.
251
Do ponto de vista de seu propsito, pode-se definir um framework como o esqueleto

de uma aplicao, que pode ser instanciado por um desenvolvedor de aplicaes (JOHNSON,
1997b) apud (BRAGA, 2002). Sendo um esqueleto, um framework no define somente as
classes de forma isolada, mas tambm as interfaces e conexes entre as mesmas, assim
como a estrutura geral da aplicao instanciada. Dessa forma, ao utilizar um framework,
um desenvolvedor no est reutilizando somente classes ou componentes isoladamente, que
precisam ser posteriormente integrados em uma aplicao, mas sim toda a estrutura interna.
Essa estrutura tambm representa parte do conhecimento daquele domnio, e assim pode-se
dizer que o nvel de reutilizao alcanado com um framework maior do que o nvel de
reutilizao alcanado com componentes isolados, representando um avano significativo em
reutilizao (KRUEGER, 1992).
A utilizao de um framework normalmente feita por meio de seus pontos variveis
(hotspots), que so os pontos que definem o que varivel em um domnio de aplicao
(BUSCHMANN et al., 1996) apud (BRAGA, 2002). Junto com os ganchos (hook), que so os
pontos do framework passveis de serem adaptados, os pontos variveis so a forma com que
o desenvolvedor normalmente instancia sua aplicao.
Sendo uma tcnica de reutilizao, o uso de frameworks compartilha com as demais
abordagens apresentas os quatro conceitos bsicos da reutilizao:
Abstrao: a abstrao, como na maior parte das abordagens, se resume a representar o
conhecimento do domnio abstraindo-se os detalhes de implementao em uma parte
escondida, e descrevendo os conceitos de mais alto nvel na parte visvel. No caso dos
frameworks, a parte visvel corresponde aos pontos que o desenvolvedor utiliza para
instanciar a aplicao, no caso, os pontos variveis e os ganchos. A parte escondida
se refere ao restante da estrutura, que normalmente reutilizada sem modificao,
tambm conhecidos como frozen spots;
Seleo: a seleo se resume escolha de um framework adequado para a aplicao que se
deseja construir. Neste caso, tcnicas de classificao e busca podem ser utilizadas para
facilitar a seleo;
Adaptao: a adaptao consiste na instanciao da aplicao, em que o desenvolvedor utiliza
os pontos variveis e ganchos para criar uma aplicao que atenda aos requisitos; e
Integrao: a integrao normalmente no um problema, pois um framework j uma
aplicao semi-pronta que, uma vez instanciada, pode ser executada diretamente. Porm,
pode ser necessrio realizar a integrao da aplicao com o ambiente, por exemplo, com
252
o sistema operacional ou um banco de dados especfico. Neste caso, essa integrao ser
to simples quanto for a possibilidade de parametrizao do framework.
Padres de software
Uma forma bastante conhecida de reutilizao so os padres de software (COPLIEN, 2006).
Sejam de anlise, de processo ou de projeto, os padres tm um nico objetivo: representar
solues bem sucedidas para problemas recorrentes, de forma que, ao se deparar com uma
situao similar vivida originalmente, um desenvolvedor possa aplicar a mesma soluo,
obtendo os mesmos resultados que o criador do padro. Neste sentido, o objeto da reutilizao
o conhecimento obtido na soluo desse problema recorrente. Os quatro conceitos bsicos da
reutilizao esto tambm presentes nessa tcnica:
Abstrao: a abstrao ocorre quando as solues recorrentes so generalizadas e
representadas segundo um formato especfico. Existem alguns formatos para descrio de
padro que so mais comumente utilizados, destacando-se aquele utilizado em (GAMMA
et al.,
1995). Normalmente essa descrio contm uma descrio do problema, de forma
que um desenvolvedor possa decidir se esse padro adequado ao seu problema ou no;
Seleo: a seleo ocorre quando o desenvolvedor procura por um padro por meio da
comparao do problema descrito no padro e o problema sendo vivenciado por ele no
momento. Esse processo normalmente manual, exigindo uma consulta a catlogos de
padres, tal como o catlogo online hillside.net5 ;
Adaptao: a adaptao consiste na instanciao do padro, adaptando-o para a situao atual.
Os elementos do padro so normalmente genricos, precisando ser renomeados ou
mesmo modificados; e
Integrao: a integrao exige a adaptao do restante do sistema, ou do projeto, para
acomodar os elementos inseridos pelo padro.
Existem basicamente trs abordagens para os processos de adaptao e integrao de um
padro (FLORIJN; MEIJERS; WINSEN, 1997): a abordagem top-down, na qual os elementos do
padro so criados e ento integrados ao restante do sistema; a abordagem bottom-up, na
qual os elementos j existentes no sistema so transformados nos elementos do padro, e
a abordagem hbrida, que uma combinao das outras duas, com parte dos elementos do
padro sendo criados a partir do zero e parte sendo adaptada a partir de elementos j existentes
no sistema.
5 http://hillside.net/patterns/onlinepatterncatalog.htm
253
Reengenharia de Software
Outra tcnica que promove a reutilizao de software a reengenharia de software.

Tambm conhecida como renovao ou recuperao, tem como objetivo principal a
reconstruo de sistemas legados para aumentar sua qualidade e manutenibilidade. Porm,
sistemas legados normalmente encapsulam um conhecimento que evoluiu durante anos, e que
no pode ser desperdiado. Dessa forma, a reengenharia de software tambm uma forma de
reutilizar software, fazendo com que esse conhecimento seja reaproveitado. A reengenharia de
software no somente recupera as informaes de um projeto existente, mas tambm as reutiliza
para alterar ou reconstruir o sistema, adicionando novos requisitos ou introduzindo novas
tecnologias. As principais atividades da reengenharia de software so: engenharia reversa,
seguida por mudanas no sistema (de funcionalidade ou de implementao), e seguida pela
engenharia avante. Em outras palavras, reengenharia o processo de se criar uma descrio
abstrata do sistema, elaborar mudanas em alto nvel de abstrao, e ento reimplementar o
sistema (JACOBSON; LINDSTROM, 1991).
Esse processo de engenharia reversa, modificaes e engenharia avante, tambm contempla
os quatro conceitos da reutilizao de software. A fase de engenharia reversa corresponde ao
conceito de abstrao, enquanto que as fases de modificaes e engenharia avante correspondem
aos demais conceitos:
Abstrao: a abstrao corresponde engenharia reversa, onde o conhecimento existente

no sistema legado recuperado, e toda informao relevante organizada de forma a
possibilitar sua futura utilizao durante a reconstruo;
Seleo: a seleo ocorre quando o desenvolvedor precisa realizar mudanas no sistema, sejam
elas de funcionalidade ou implementao. Ele precisa conhecer cada artefato recuperado
durante a engenharia reversa, e selecionar aquele onde sero feitas as modificaes;
Adaptao: a adaptao corresponde s mudanas sendo efetuadas nos artefatos recuperados.
Os mesmos so modificados para atender a novos requisitos ou incorporar novas
tecnologias; e
Integrao: a integrao ocorre de forma gradual. Normalmente, as organizaes preferem
utilizar processos de reengenharia gradativos, onde apenas um mdulo reconstrudo a
cada vez. Isso possibilita que o sistema legado possa continuar sendo utilizado durante a
reconstruo (SEACORD; PLAKOSH; LEWIS, 2003).
254
O Quadro 13 resume as principais tcnicas para reutilizao de software apresentadas neste

apndice, apresentando as idias-chave de cada tcnica, de acordo com os quatro conceitos da
reutilizao.
Reengenharia
software
Padres
Frameworks
framework
Busca por um padro para

um determinado problema
Seleo dos artefatos a
serem modificados
Escolha do
adequado
Escolha de um gerador
apropriado
Definio do formato de
entrada
Representao do domnio,
destacando os pontos
variveis e ganchos
Generalizao de solues
recorrentes
Engenharia Reversa
Consulta gramtica ou
manual da linguagem
busca
Anlise de um domnio de
problema
Seleo
Navegao
automtica
Abstrao
Encapsulamento e utilizao
de interfaces bem definidas
definidos
na
ou
Instanciao,
atravs
dos pontos variveis e
ganchos
Adaptao do padro para a
situao
Mudanas nos artefatos
recuperados, para atender a
novos requisitos ou novas
tecnologias
Produo da entrada do
gerador
Parmetros
linguagem
Adaptao
Parametrizao
modificao interna
De forma gradual, o sistema reconstrudo

aos poucos, com cada mdulo sendo
integrado separadamente
Adaptao do restante do sistema
No existe quando gerado um programa

completo. Porm, podem ser necessrias
modificaes, quando gerada apenas
parte de um programa
Normalmente no um problema, pois o
framework uma aplicao semi-pronta
Automatizada atravs de um compilador
Integrao
Acoplamento de interfaces providas com
requeridas
Quadro 13: Resumo das principais tcnicas relacionadas aos conceitos bsicos da reutilizao de software
de
Desenvolvimento
Baseado
em
Componentes
(DBC)
Linguagens
Especficas
de
Domnio (DSL)
Programao
Generativa
255
257
APNDICE B -- MDD: mito ou realidade?
De fato, observa-se que o MDD um termo novo para conceitos no to novos. a

combinao de programao generativa, linguagens especficas de domnio e transformaes de
software, conceitos que j vinham sendo explorados por Jim Neighbors na abordagem Draco,
na dcada de 1980 (NEIGHBORS, 1980).
Desde o trabalho de Neighbors, pesquisadores e profissionais esperam por uma
oportunidade para dar vida aos seus modelos, e assim aumentar o nvel de abstrao do
processo de desenvolvimento de software (ATKINSON; KHNE, 2003). Os desafios a serem
vencidos para se aplicar o MDD deixam alguns autores ainda cticos com relao validade
de suas idias. H alguns anos, diversos autores (AMBLER, 2003; MILLER et al., 2004; AMBLER,
2004) argumentavam que, entre outros problemas, as bases da abordagem no so slidas o
bastante, principalmente porque:
No existia uma linguagem de modelagem suficientemente poderosa o bastante para ser
capaz de representar as necessidades de aplicaes do mundo real;
As pessoas no possuam as habilidades de modelagem necessrias para criar modelos
que sirvam como base da abordagem; e
No existiam ferramentas disponveis para dar suporte MDD.
Mesmo a UML, um padro de fato para modelagem de software, apresenta srios problemas
quando se trata do MDD. O principal deles o fato de a UML ser genrica, enquanto no MDD
a linguagem de modelagem deve ser o mais prximo do domnio possvel, para facilitar as
tarefas de transformao e gerao de cdigo (KHNE, 2007). Alm disso, muito esforo
pode ser necessrio para se definir como os conceitos especficos de um domnio poderiam
se encaixar em uma linguagem genrica como a UML (VLTER, 2008). Por exemplo, tente
descrever semnticas de operaes (THOMAS, 2004), ou aspectos fundamentais de modelagem
de interfaces e de banco de dados (AMBLER, 2003) utilizando UML. Fowler (2004b) tambm
258
questiona a validade da UML na abordagem generativa como base do desenvolvimento de

software.
Entre as dificuldades, pode-se citar o fato de que o metamodelo da UML
extremamente complexo, exigindo trabalho considervel para compreend-lo, e ainda mais para
se construir transformadores com base nele.
Essas limitaes da UML frente s perspectivas do MDD foram observadas em um estudo
(BETTIN, 2002) comparativo entre o desenvolvimento completamente manual e o MDD com
modelagem UML, gerao de esqueletos de classes completados com cdigo manual. Os
resultados mostram que o MDD com modelagem UML apresenta poucas vantagens em relao
ao desenvolvimento manual.
O mesmo estudo tambm analisou o desenvolvimento com modelagem especfica de
domnio e gerao de cdigo1 com pouca necessidade de cdigo manual. Nesse caso, foram
observadas vantagens significativas em relao ao desenvolvimento manual (BETTIN, 2002).
H alguns anos, alguns autores tambm questionavam se o MDD no seria apenas uma
reedio do fracasso das ferramentas CASE dos anos 80, que prometiam basicamente a mesma
coisa que o MDD promete (AMBLER, 2003; MILLER et al., 2004; AMBLER, 2004). Entre os
argumentos, Selic (2003) destacava que tcnicas de modelagem e gerao de cdigo j foram
tentadas antes, com relativamente pouco sucesso. Por que ento seria diferente com o MDD?
O prprio Selic (2003) responde ainda que h dois fatores evolucionrios que pesam a
favor do MDD: as tecnologias de automao necessrias tornaram-se mais maduras, e surgiram
vrios padres industriais para essa tecnologia. Estes so os padres MDA (Model-Driven
Architecture), propostos pelo OMG (Object Management Group) (OMG, 2003), que ofereceram
aos fabricantes de ferramentas novas maneiras para explorar os benefcios do desenvolvimento
orientado a modelos em larga escala.
Isto porque o MDD altamente dependente do uso de ferramentas: para modelagem,
transformao de software e gerao de cdigo.
Com os padres MDA: UML (Unified
Modeling Language), MOF (Meta-Object Facility), XMI (XML Metadata Interchange) e QVT
(Queries/Views/Transformations)2 , diferentes fabricantes podem integrar suas ferramentas de
maneira mais simples e fcil, alavancando esta tecnologia de forma indita.
Os avanos tecnolgicos parecem mesmo ter sido o ponto decisivo no sucesso do MDD.
Existem diversos casos onde ele foi aplicado com sucesso nas organizaes (MILLER et al.,
2004; MELLOR; CLARK; FUTAGAMI, 2003; MILLER et al., 2004; TOLVANEN, 2004; WILE, 2004;
MOHAGHEGHI; DEHLEN,
1 Linguagens
2 Todos
2008).
especficas de domnio e programao generativa so discutidas no Apndice A.

os padres MDA esto disponveis em http://www.omg.org/mda/specs.htm
259
Colin Atkinson, um dos criadores do processo KobrA (ATKINSON; BAYER; MUTHIG, 2000),
e Thomas Khne, tambm se manifestam a favor do MDD, porm ressaltando o problema da
maneira como o OMG trata os modelos (ATKINSON; KHNE, 2003). Em sua viso, o poder
representativo do MOF limitado e deveria ser revisto. Atkinson e Khne tambm listam seis
requisitos para o desenvolvimento orientado a modelos, e concluem que, salvo pela restrio da
maneira como a modelagem tratada, o MDD um passo significativo em direo ao objetivo
final de integrar modelagem ao desenvolvimento.
Uhl (2003) tambm se mostra otimista com relao ao MDD e MDA. Segundo sua viso,
porm, o MOF e a UML so suficientes para modelar sistemas, e seus mecanismos de extenso
eliminam a necessidade de uma linguagem especfica para um domnio. Seus argumentos se
baseiam na observao dos benefcios obtidos com sua aplicao em projetos reais.
Apesar das discusses, existe um consenso geral, partilhado pela maioria dos autores,
de que o desenvolvimento orientado a modelos, seja ele baseado na MDA ou no, pode
oferecer grandes benefcios, ainda que no cause uma revoluo na maneira como se desenvolve
software. No se sabe se a MDA vai ser ou no a tecnologia de suporte para o MDD. De acordo
com Thomas (2004), primeiro necessria uma anlise mais profunda por parte da comunidade
de software.
Finalmente, o crescente nmero de projetos dedicados a alcanar os benefcios do MDD na
academia, mas principalmente da indstria, mostra que provavelmente essa abordagem est se
estabelecendo de fato.
261
APNDICE C -- Relao entre a abordagem e

modelos de maturidade
Neste apndice so descritos em detalhes as prticas do modelo de maturidade em

reutilizao proposto por Garcia et al. (2007, 2008) e do modelo de maturidade em MDD
definido pela iniciativa ModelWare (MODELWARE, 2006b).
Tambm discute-se a relao entre esses modelos de maturidade e a abordagem definida
nesta tese. Em cada prtica indicado um smbolo, sendo que o smbolo 2
indica que a prtica
est presente na abordagem, e o smbolo 2indica que a prtica est ausente da abordagem. Uma
breve explicao, destacada em negrito, descreve o raciocnio por trs da presena ou ausncia
da prtica na abordagem.
importante ressaltar que no foi feita uma anlise rigorosa de aderncia aos modelos de
maturidade, analisando-se por exemplo as caractersticas principais dos produtos de trabalho
e atividades da abordagem e comparando-se com os elementos de processo descritos nos
modelos. O foco aqui foi oferecer uma viso mais ampla sobre o escopo e abrangncia da
abordagem, frente ao que existe na literatura com relao s atividades e prticas relacionadas
reutilizao e MDD, alm de oferecer uma descrio mais detalhada dos modelos de
maturidade.
Modelo de maturidade em reutilizao de software (GARCIA et al., 2007, 2008)
Nvel 1 - Incompleto: neste nvel, apenas o desenvolvimento de software tradicional
realizado. Prticas de reutilizao so usadas esporadicamente ou mesmo ignoradas e
desencorajadas pela gerncia. Reutilizao fruto de esforo individual, e os custos da
reutilizao so desconhecidos. No existem prticas definidas para este nvel;
Nvel 2 - Bsico: este nvel caracterizado pela utilizao bsica de artefatos com
potencial de reutilizao. Engloba algumas atividades bsicas orientadas reutilizao,
e a implementao do domnio de forma direta, sem uma preocupao com anlise e
projeto mais voltados reutilizao;
262
2 AP1 - Manuteno de mtodos e tcnicas bsicas de reutilizao: estes
devem ser documentados, analisados e mantidos sempre atualizados, atravs de

revises peridicas envolvendo a equipe e a gerncia. A abordagem no prev
o gerenciamento e manuteno de mtodos e tcnicas para reutilizao;
2
AP2 - Planejamento de reutilizao: deve ser realizado de acordo com um
procedimento pr-definido e documentado. O planejamento deve incluir anlise

de riscos e determinao das abordagens de reutilizao a serem utilizadas. O
ciclo de vida do processo de reutilizao deve tambm ser identificado durante
o planejamento.
Uma das atividades iniciais da abordagem consiste no
planejamento da reutilizao, incluindo possveis riscos, e a adoo desta

abordagem pode ser considerada como uma deciso de planejamento, assim
como a definio de seu modelo do ciclo de vida;
2
AP3 - Definio dos objetivos da reutilizao: assim como a estratgia adotada,
a definio dos objetivos deve ser realizada por um grupo com autoridade e
conhecimento para esta tarefa. Os objetivos e estratgia devem ser documentados.

Tambm devem ser definidos, documentados e implantados os indicadores de
desempenho a serem utilizados para determinar se os objetivos esto sendo
alcanados no processo. A abordagem contm uma atividade para definio
dos objetivos da reutilizao;
2

AP4 - Implementao do domnio:
visa produzir artefatos de software
reutilizveis para o domnio, atravs de codificao, testes, documentao e

empacotamento destes artefatos. Envolve basicamente a definio das interfaces
providas e requeridas dos artefatos reutilizveis, testes de unidade com os artefatos,
documentao e empacotamento desses artefatos. Essa justamente uma das fases
da abordagem, que visa implementar um domnio utilizando tcnicas do MDD;
Nvel 3 - Definido: neste nvel o principal foco de engenharia o suporte variabilidade.

Enquanto no nvel 2 a preocupao era aumentar o nvel de reutilizao de artefatos
individuais, aqui o foco oferecer um suporte global variabilidade do domnio,
principalmente com as prticas de anlise e projeto do domnio. Tambm neste nvel
introduz-se a preocupao com o processo de desenvolvimento de uma organizao,
treinamento e a introduo de uma unidade dedicada reutilizao. Preocupaes com a
qualidade dos artefatos tambm comeam a aparecer neste nvel;
2
AP5 - Controle e monitoramento do processo de reutilizao: deve ser

realizado atravs de um conjunto de mecanismos e mtricas que determinam o status
263
das atividades, e um conjunto de polticas e um plano de aes, responsveis pelo

controle do processo. A abordagem no define nenhum mecanismo ou atividade
para controle e monitoramento do processo;
2
AP6 - Integrao com o ciclo de vida do software: so definidas atividades,
sub-atividades e produtos de trabalho institucionalizados para a organizao,

com base em um modelo de referncia. Tambm importante a definio de
um procedimento para a cooperao entre os desenvolvedores e a equipe de
reutilizao. Esta prtica consiste justamente na definio desta abordagem
e seus elementos;
2
AP7 - Anlise de domnio: envolve a seleo e definio do domnio, anlise das
aplicaes existentes para identificao das caractersticas do domnio, definio
dos requisitos e escopo do domnio, identificao e documentao dos pontos
variveis e comuns, e a identificao e documentao de restries adicionais entre
as caractersticas do domnio. A abordagem possui uma fase especfica para a
anlise de domnio voltada para o MDD;
2
AP8 - Projeto de domnio: envolve a definio de uma arquitetura de referncia
para o domnio, que define a maneira com que os sistemas do domnio sero
construdos. Os requisitos, incluindo a variabilidade, devem ser mapeados para
solues tcnicas. Padres de projeto devem oferecer suporte estrutura varivel
que serve de base para os aplicativos do domnio. O arquiteto deve reduzir a
complexidade do projeto atravs de abstraes que consigam separar os principais
aspectos do domnio. O arquiteto deve modelar as abstraes de forma a permitir
o raciocnio sobre elas. Esta rea tambm envolve a avaliao arquitetural, visando
detectar falhas e erros antes da implementao comear. A abordagem engloba as
prticas relacionadas ao projeto de domnio, incluindo projeto arquitetural e

suporte variabilidade;
2 AP9 - Treinamento em reutilizao: envolve um programa organizacional
de treinamento com suporte adequado, um planejamento do treinamento, e o

estabelecimento de um comit de treinamento interno. A abordagem no prev
atividades para treinamento;
2 AP10 - Gerenciamento da unidade de reutilizao: inclui principalmente
o estabelecimento de um comit de reutilizao, com um lder, e suporte e

financiamentos providos por uma alta gerncia comprometida. Este comit deve
possuir regras e responsabilidades bem definidas, ser composto de membros bem
treinados e motivados, e possuir canais de comunicao com a organizao. A
264
abordagem no define uma unidade dedicada reutilizao;

2 AP11 - Programa de mtricas: definio de polticas e objetivos para medio
da reutilizao em toda organizao. Um plano de medio de reutilizao deve ser

desenvolvido, com mecanismos para coleta, anlise e aplicao de dados. Planos de
aes para melhoria de processo com base nos resultados das medies tambm so
importantes. A abordagem no define nenhum tipo de mtrica de controle de
andamento do processo, ou controle de qualidade;
2 AP12 - Programa de avaliao organizacional: envolve a definio, por parte
da alta gerncia, de polticas de avaliao, alm do suporte e integrao do processo

de avaliao na cultura organizacional. O comit de reutilizao, possivelmente
junto com o grupo de controle de qualidade da organizao, devem desenvolver
e documentar os objetivos, planos e procedimentos de avaliao durante o ciclo
de vida.
Finalmente, o pessoal envolvido deve ser apropriadamente treinado
nas polticas, prticas e procedimentos de avaliao. A abordagem no define

nenhuma atividade com este objetivo;
2 AP13 - Avaliao da qualidade dos artefatos: envolve a definio de um modelo
de qualidade, que define polticas, objetivos e atributos relacionados qualidade
dos artefatos reutilizveis, assim como um processo de avaliao dos mesmos.
Avaliao de qualidade no faz parte da abordagem;
2 AP14 - Engenharia de Aplicaes: engloba as prticas de desenvolvimento
com a reutilizao de artefatos previamente construdos. Envolve a busca, seleo,
adaptao e integrao dos artefatos reutilizveis. Assume-se que estes artefatos
tenham sido previamente testados, e portanto nesta rea esto somente as prticas
de testes de integrao e testes de sistema. Tambm envolve a estimativa de
esforo de reutilizao, uma vez que pode ser mais vantajoso construir um artefato
do zero do que reutilizar um artefato que exige grande esforo de adaptao.
O desenvolvimento com reutilizao est fora do escopo desta pesquisa, e
portanto a abordagem no possui nenhuma atividade relacionada a esta
prtica;
Nvel 4 - Sistemtico: este o nvel mais avanado que uma organizao pode chegar
em termos de reutilizao de software. Neste nvel, o processo est em constante
otimizao, de acordo com resultados de projetos anteriores. Tambm aqui a qualidade
dos artefatos reutilizveis sujeita a um processo mais rigoroso de controle de qualidade.
Outras prticas interessantes deste nvel 4 incluem a tentativa de se prever e suprir
265
necessidades futuras em termos de artefatos reutilizveis, e uma anlise de mercado para

se avaliaram questes de investimento em reutilizao;
2 AP15 - Otimizao do processo de reutilizao: envolve a identificao das
prticas que precisam ser melhoradas, seguida da implementao das melhorias,
e medio do progresso de melhoria. A contnua avaliao de novas ferramentas e

tecnologias relacionadas reutilizao tambm precisa ser realizada. A abordagem
no prev atividades para melhoria e evoluo do processo;
2 AP16 - Controle de qualidade dos artefatos: um passo alm da avaliao
da qualidade, com objetivos especficos para os produtos de software sendo

incorporados no planejamento da reutilizao. O comit de reutilizao tambm
precisa ser treinado em mtodos estatsticos para poder melhor avaliar os artefatos
frente a seus modelos de qualidade. A abordagem no trata do controle de
qualidade dos artefatos reutilizveis;
2 AP17 - Previsibilidade dos artefatos reutilizveis: consiste na identificao de

necessidades futuras em termos de artefatos potencialmente reutilizveis, visando
reduzir o tempo de desenvolvimento em projetos envolvendo estes artefatos. No
h nenhuma atividade com este objetivo;
2 AP18 - Anlise de condies de mercado e retorno de investimento: busca
analisar o nvel de retorno dos investimentos em reutilizao, de acordo com as

condies do mercado e oportunidades para novos negcios. Tambm envolve
a aquisio de artefatos do domnio, caso necessrio. A anlise de mercado
realizada superficial, e se resume a uma pesquisa com base em conhecimento
dos especialistas, sem atividades especficas para determinao de custos e
retorno de investimento.
Modelo de maturidade em MDD (MODELWARE, 2006b)
Nvel 1 - Modelagem ad hoc: neste nvel, apenas o desenvolvimento tradicional

realizado. Prticas de modelagem so utilizadas apenas esporadicamente ou nunca. No
existem prticas definidas para este nvel;
Nvel 2 - MDD Bsico: este nvel caracterizado pela utilizao bsica de modelos,
cobrindo atividades simples do MDD. Modelos so utilizados apenas para guiar a
implementao e documentao. Tipicamente, apenas modelos tcnicos so utilizados,
incluindo todos os aspectos de um sistema, sem distino entre aspectos de negcio ou
aspectos especficos de plataforma;
266
2
ENG1 - Decidir sobre convenes de modelagem: consiste na identificao
e seleo das convenes de modelagem a ser utilizadas pela equipe de
desenvolvimento. Para isso, definido o escopo do modelo: quais requisitos
podem/devem ser modelados. Tambm envolve a deciso sobre quais partes do
software sero feitas mo, e quais sero automaticamente geradas. So definidos
quais tipos de diagramas sero construdos e utilizados e com quais tcnicas de
modelagem. A abordagem possui uma atividade na qual so analisadas as
possibilidades de linguagens a serem utilizadas na modelagem;
2
PJM1 - Decidir sobre ferramentas de modelagem: envolve a seleo de
ferramentas que possam satisfazer s necessidades do projeto, de gerao de cdigo
e documentao. Deve levar em conta objetivos e restries do projeto, tais como
custos e durao. Assim como na atividade acima ENG1, a abordagem tambm
busca analisar ferramentas existentes para serem utilizadas;
2

ENG2 - Desenvolver modelo tcnico:
o modelo tcnico descreve os
principais mdulos do software, incluindo elementos independentes e especficos

de plataforma. O modelo tcnico representa a diviso em camadas, a comunicao
entre as camadas, os componentes a serem utilizados ou desenvolvidos, as interfaces
entre os componentes, a plataforma destino e persistncia, entre outros aspectos
de negcio e tcnicos do sistema. A abordagem no est focada em um tipo
especfico de modelo, e portanto pode ser utilizada para desenvolver modelos
tcnicos;
2
ENG3 - Gerar cdigo a partir do modelo tcnico: ferramentas simples de
gerao automtica de cdigo produzem cdigo que corresponde ao modelo tcnico.

A sada desta atividade o esqueleto do produto de software. Envolve tambm
a separao entre cdigo gerado e cdigo no gerado, e a complementao com
cdigo manual para satisfazer aos requisitos, caso a gerao no produza todo o
cdigo necessrio. A gerao de cdigo um dos principais itens da abordagem,
e portanto esta prtica est plenamente implementada;
2 ENG4 - Gerar documentao a partir do modelo tcnico: similar gerao
de cdigo, a documentao de projeto do sistema pode ser gerada a partir do

modelo tcnico, ou pelo menos parcialmente. Envolve a gerao da documentao
e a complementao manual, caso a documentao gerada no seja completa.
Apesar de ser possvel gerar qualquer tipo de artefato, a abordagem no define
atividades especficas para gerao de documentao;
Nvel 3 - MDD Inicial: neste nvel introduz-se uma separao entre modelos de negcio
267
(independentes de plataforma) e especficos de plataforma. O objetivo manter os

aspectos de implementao independentes dos aspectos de negcio, de modo a melhorar
a eficincia do processo de desenvolvimento. Neste nvel, as prticas e artefatos do MDD
so institucionalizadas, e um processo definido para o MDD utilizado pela organizao;
2

ENG5 - Desenvolver modelo independente de plataforma: um modelo
independente de plataforma reflete os requisitos do sistema sem utilizar conceitos

especficos da plataforma. Os requisitos so documentados de acordo com as
tcnicas de modelagem estabelecidas na organizao. A abordagem no est
focada em um tipo especfico de modelo, e portanto pode ser utilizada para
desenvolver modelos independentes de plataforma;
2

ENG6 - Desenvolver transformaes tcnicas modelo-para-texto:
as
transformaes devem ser desenvolvidas com base nos metamodelos de origem

e destino. A definio das transformaes com base na sintaxe concreta (por
exemplo, XMI) so insuficientes pois elas limitam a transformao a apenas uma
sintaxe concreta. Para isso, decide-se sobre qual linguagem de transformao
utilizar, so identificados os metamodelos de origem e destino, so definidas as
regras de transformao, que so compiladas e executadas por uma ferramenta,
e opcionalmente, completa-se o cdigo gerado, caso necessrio, para completar
a transformao.
A abordagem tem atividades para transformaes de
modelo-para-texto, visando dar suporte variabilidade do domnio;

2 ENG7 - Verificar modelos: a verificao de modelos inclui a checagem dos
requisitos, para determinar se esto completamente e adequadamente refletidos nos

modelos. A abordagem no define atividades para verificao de modelos;
2

PJM2 - Modelar o processo de MDD do projeto: normalmente, cada
organizao tem um processo de desenvolvimento implantado, que modificado

ou adaptado para atender s necessidades de cada projeto. No caso do MDD,
essa adaptao deve considerar que: (i) os requisitos devem ser modelados nas
ferramentas selecionadas para a organizao, e utilizando os padres de modelagem
pr-estabelecidos; (ii) o foco das tarefas do projeto deve se concentrado nas
atividades de modelagem e na definio de transformaes entre modelos; e (iii)
a maioria dos resultados as atividades de engenharia so modelos e transformaes
entre modelos. A abordagem est completamente modelada, e portanto pode
ser utilizada como modelo do processo;
2 PJM3 - Aplicar o processo estabelecido: consiste na utilizao do processo
definido, e obteno de mtricas para controle de sua execuo. Uma organizao
268
pode aplicar a abordagem, mas no foram definidas mtricas para gerenciar

e controlar sua execuo, e portanto esta prtica no est completamente
satisfeita;
2 PJM4 - Definir, coletar e analisar mtricas do projeto: as mtricas devem estar
ligadas aos objetivos do projeto. O foco deve ser nas atividades especficas do MDD,
como qualidade arquitetural, corretude dos modelos, etc. A abordagem no define
nenhuma atividade referente definio, coleta e anlise de mtricas;
2 SUP1 - Estabelecer e manter repositrios para modelos e transformaes:
com o objetivo de promover a reutilizao dos modelos e transformaes na

organizao, repositrios devem ser desenvolvidos e mantidos, de forma que
modelos e transformaes produzidos em um projeto podem ser reaproveitados em
outros projetos. A abordagem no define nenhum tipo de repositrio para o
MDD;
2 SUP2 - Definir tcnicas padronizadas de modelagem e critrios de qualidade:
envolve a definio de um padro de modelagem para a organizao, que representa

a evoluo das convenes de modelagem definidas no nvel 2. Tambm envolve
a definio de critrios de qualidade de modelos, como completude de modelo,
consistncia inter-diagramas, legibilidade, etc. A abordagem apenas contm
atividades, passos e diretrizes, sem definir tcnicas padronizadas ou critrios
de qualidade;
2 SUP3 - Checar aplicao das prticas: consiste em verificar se as prticas de
modelagem e artefatos produzidos esto de acordo com as tcnicas de modelagem

e critrios de qualidade pr-estabelecidos. A abordagem no define maneiras de
controle sobre a aplicao de suas prticas;
2 SUP4 - Definir mtricas padronizadas e procedimentos de coleta e anlise de
dados: envolve a definio de mtricas para as atividades de modelagem, para os
modelos, como coletar as mtricas e como analisar os dados. A abordagem no

define nenhum tipo de mtricas para controle;
Nvel 4 - MDD Integrado: o nvel 4 caracterizado por uma melhor integrao
entre os nveis de abstrao de modelagem. Aspectos de negcio, independentes de
plataforma e especficos de plataforma so separados em elementos do MDD, atividades
de modelagem so integradas, e garante-se um desempenho de modelagem eficiente;
2

ENG8 - Desenvolver metamodelo centrado na arquitetura:
envolve
a identificao das principais entidades que fazem parte da arquitetura, os
269
relacionamentos entre estas entidades, e a linguagem de metamodelagem a ser

utilizada. Por fim, o metamodelo desenvolvido em uma ferramenta que d suporte
linguagem estabelecida. O projeto arquitetural voltado ao MDD est presente
na abordagem, que tem atividades para que o metamodelo seja centrado na
arquitetura;
2
ENG9 - Desenvolver metamodelo independente de plataforma: de forma
similar ao desenvolvimento do metamodelo centrado na arquitetura, o modelo

independente de plataforma desenvolvido modelando-se as principais entidades do
sistema e seus relacionamentos, mas sem referncias a uma plataforma especfica.
A abordagem no est focada em um tipo especfico de modelo, e portanto pode
ser utilizada para desenvolver metamodelos independentes de plataforma;
2
ENG10 - Desenvolver modelo de negcios: consiste na anlise dos requisitos de
negcio e criao de um modelo que representa como o sistema funciona, utilizando
entidades de negcio e relacionamento entre elas. A abordagem no est focada
em um tipo especfico de modelo, e portanto pode ser utilizada para desenvolver
modelos de negcio;
2

ENG11 - Desenvolver transformaes modelo-para-modelo: consiste na
identificao dos metamodelos de origem e destino, padres de transformao

entre os modelos de origem e destino, definio da linguagem de transformaes
a ser utilizada, e implementao da transformao. A sintaxe concreta deve ser
ignorada neste caso. As transformaes modelo-para-modelo esto previstas na
abordagem, como uma forma de organizao e estruturao dos geradores de
cdigo;
2 ENG12 - Manter rastreabilidade entre modelos: significa manter ligaes ou

mapeamentos explcitos entre modelos, aps o resultado de uma transformao.
Envolve a definio de um framework de rastreabilidade, com componentes e
modelos a serem rastreados, tipos de ligaes, direo, etc. Os requisitos de
rastreabilidade devem ser integrados ao processo de modelagem, que tambm
responsvel por realizar a gerncia de configurao e controle de verses das
ligaes de rastreabilidade. A abordagem prev rastreabilidade entre artefatos
de anlise, projeto e implementao, mas no inclui o rastreamento entre
elementos antes e aps uma transformao, e portanto esta prtica no est
completamente satisfeita;
2
ENG13 - Integrar desenvolvimento de produto com desenvolvimento de
infraestrutura para uma famlia de produtos: esta prtica s aplicvel nos
270
casos onde o desenvolvimento de uma famlia de produtos realizado. O objetivo

desta prtica separar os modelos tcnicos dos produtos daqueles da infraestrutura
da famlia, de forma que ambos sejam mais reutilizveis. Esta a preocupao
central da abordagem;
2 ENG14 - Simular modelos: o objetivo desta prtica avanada de controle de
qualidade garantir a qualidade dos elementos do MDD o mais rpido possvel

no ciclo de vida. Simulao de modelos permite a verificao do comportamento
modelado de um sistema. Requer a existncia de uma especificao formal das
aes, em uma linguagem semntica de aes. No existem atividades especficas
para simulao de modelos;
SUP5 - Estabelecer e manter limites de desempenho de modelagem da

organizao: a organizao deve definir e manter os objetivos das atividades de
modelagem, e elementos de MDD utilizados, de acordo com cada tipo particular
de projeto. Esta prtica visa atender necessidade de alinhamento dos objetivos
de negcio da organizao com os objetivos do projeto.
A abordagem no
tem nenhuma atividade similar a esta prtica, que exige um conhecimento

sobre diferentes opes de processo para cada projeto, cada um com um grau
especfico de automao, visando dosar o nvel de automao em cada projeto;
2 PJM5 - Modelar os processos automticos de MDD do projeto: esta prtica
estende a prtica do nvel 3, de modelagem do processo, introduzindo limites de
desempenho de modelagem, estabelecidos pela organizao quando desenvolvendo

o modelo do processo. A modelagem da abordagem se limita descrio das
atividades, no contemplando todos os requisitos desta prtica, que exige um
conhecimento sobre diferentes opes de processo para cada projeto, cada um
com um grau especfico de automao, visando dosar o nvel de automao em
cada projeto;
Nvel 5 - MDD Definitivo: neste ltimo e derradeiro nvel, todo o conhecimento da
organizao mantido na forma de modelos e transformaes, que so o foco do processo
de desenvolvimento. Prticas de engenharia de domnio e linguagens especficas de
domnio so criadas e continuamente atualizadas;
2

ENG15 - Desenvolver linguagens especficas de domnio:
linguagens
especficas de domnio capturam o conhecimento do domnio utilizando abstraes

do domnio, permitindo que os desenvolvedores criem produtos com base em
termos familiares do domnio. Consiste na identificao dos principais conceitos
271
do domnio, definio do glossrio do domnio, seleo da linguagem e definio da

DSL, atravs de uma ferramenta. A abordagem possui uma atividade especfica
para o desenvolvimento de DSLs no contexto da reutilizao;
2 ENG16 - Verificar e validar produtos com base nos modelos: a verificao
e validao realizada atravs de modelos para teste e validao. Estes modelos

(e seus metamodelos correspondentes) capturam os requisitos do sistema, e a
verificao ocorre diretamente nos modelos. Desta forma, erros so detectados e
corrigidos diretamente nos modelos. Verificao e validao de modelos esto
fora do escopo da abordagem;
2 PJM6 - Estabelecer e manter artefatos de modelagem de software estratgicos
para o MDD: consiste na identificao dos artefatos de modelagem (modelos,

transformaes, etc) que so relacionados com a estratgia de MDD organizacional,
na priorizao destes artefatos com relao sua importncia frente aos objetivos
estratgicos, no agrupamento destes artefatos em diferentes categorias e na criao,
armazenamento e monitoramento destes artefatos estratgicos. A abordagem no
contm nenhuma atividade neste sentido;
2 PJM7 - Promulgar o modelo de processo do projeto: consiste na criao de

uma instncia de um processo para um projeto em particular, no sentido de atribuir
recursos para os papis das tarefas do projeto, estabelecer a durao das tarefas, etc.
As decises so feitas pelo gerente de projeto, seguindo diretrizes organizacionais.
Ferramentas de modelagem e suporte tambm podem ser integradas em um
ambiente de execuo capaz de orquestrar a execuo da instncia do processo. O
suporte execuo do projeto limita-se descrio da abordagem, em termos
de suas atividades, papis, entradas, sadas, etc. No existe um controle maior
sobre sua execuo, controle e melhoria, conforme previsto nesta prtica.
273
APNDICE D -- Reproduo na ntegra da

entrevista referente ao estudo
emprico envolvendo o domnio de
eventos cientficos
A seguir apresentada, na ntegra, a entrevista realizada como parte do estudo emprico

envolvendo o domnio de eventos cientficos:
P:O modelo de features ajudou na definio das linguagens especficas de domnio,

transformaes e geradores de cdigo?
R:A equipe reportou que algumas features foram utilizadas diretamente na
definio inicial do modelo de configurao, pois descreviam diferentes opes de
configurao automtica, como quais subsistemas devem estar presentes, e algumas
de suas caractersticas. Mas principalmente, foi relatado que o modelo de features
ajudou na obteno de uma viso geral do domnio, til para as atividades de
customizao e vendas, uma vez que permite que o cliente visualize as caractersticas
do produto de forma facilitada e possa escolher entre as opes de maneira mais
rpida. A equipe, que desconhecia a notao empregada nesse modelo, considerou
fcil o aprendizado e entendimento, inclusive podendo ser usada comercialmente ou
estendida futuramente.
P:A descrio da variabilidade em cenrios (casos de mudana) facilitou a definio das
linguagens especficas de domnio, transformaes e geradores de cdigo?
R:Os participantes responderam que estes artefatos ajudaram principalmente na
formalizao de algumas variabilidades que eram compreendidas de forma implcita
pela equipe. Atravs dos casos de uso e de mudana, as diferentes opes de
comportamento ficaram mais claras, porm a equipe relatou que no conseguiu
274
identificar uma relao direta entre os casos de mudana e um modelo ou um

gerador, como aconteceu para o modelo de features. A equipe ficou um tanto
surpresa em notar tantas modificaes que eram feitas em seus produtos (de
forma ad hoc) que foram desenvolvidos para atender o domnio cientfico, mas
cada cliente exige mudanas prprias e usando diferentes funcionalidades, sendo
que todas essas alteraes tm que ser controladas e todo auxlio nesse sentido
importante, seja gerencialmente (pelos coordenadores da equipe) ou tecnicamente
(pelos responsveis pelos casos de mudana.
P:A identificao de candidatos a sub-domnio facilitou a identificao das reas do domnio
a serem automatizadas?
R:Sim, os participantes enfatizaram que conseguiram identificar pelo menos oito
sub-domnios onde a automao iria ajudar em suas tarefas:
configurao
dos arquivos de cdigo-fonte (incluindo instalao), banco de dados, relatrios,

gerao de crachs, gerao de certificados, configurao de boleto bancrio,
configurao de idiomas suportados (incluindo idioma padro) e processamento
de arquivos de pagamento do banco (retornos financeiros). Estes sub-domnios
consistem principalmente de pontos particularmente problemticos e trabalhosos
para configurao manual, j conhecidos pela equipe aps sua experincia com
atendimento a seus clientes. Segundo a equipe, o uso do modelo de features facilitou
na identificao destes pontos.
P:A identificao de candidatos a sub-domnio facilitou a definio das linguagens
especficas de domnio, transformaes e geradores de cdigo?
R:Com relao a esta questo, a equipe salientou que a diviso em sub-domnios
facilitou na definio do escopo dos artefatos de gerao de cdigo, que podem
ser focados em partes pequenas do problema, tornando seu desenvolvimento
mais simples. Porm, eles apontaram a falha de que a existncia de mltiplos
sub-domnios exige tambm mltiplas etapas na gerao de cdigo, j que cada
gerador precisa ser executado separadamente para cada sub-domnio, o que
dificulta quando necessrio gerar cdigo repetidas vezes.
P:O processo investigativo baseado em decises para incluso/excluso de sub-domnios foi
utilizado? Se sim, ele facilitou o processo de desenvolvimento dos artefatos do MDD?
R:A equipe no soube responder esta questo de forma apropriada, pois reportou que
apenas foi feita uma deciso inicial de investigao de dois sub-domnios, sem que os
275
demais pudessem ser investigados.

P:O uso das diretrizes e padres arquiteturais especficos para reutilizao e MDD facilitou
o desenvolvimento dos artefatos do MDD e da arquitetura do domnio?
R:A equipe reportou dificuldades na construo de geradores de cdigo e sua
integrao ao restante da arquitetura. Porm, eles citaram que os padres de
camada de dados de features e a abordagem de visita baseada em templates
foram muito teis nesta tarefa. A equipe tambm reportou que a identificao
das diretrizes de variabilidade baseada em features de forma isolada para cada
sub-domnio facilitou o desenvolvimento da camada de dados de features utilizada
pelos geradores especficos.
A unificao de arquivos de configurao para
instalao em um modelo inicial que prev inclusive usurios iniciais para a

aplicao foi relatado como grande facilitador para gerenciar a instalao do pacote,
que agora pode ser feita por integrantes da equipe menos experientes que vero no
modelo reutilizvel uma forma de trabalho mais fcil. Antes a instalao dependia
de engenheiros experientes no domnio e anlise de trechos de cdigo em vrios
arquivos com busca e alterao dos mesmos (que quando no era feita de forma
ideal trazia problemas aos clientes).
P:A etapa de avaliao arquitetural ajudou a identificar falhas antes de a implementao ser
iniciada?
R:A equipe no chegou a realizar a avaliao arquitetural, argumentando que como o
tamanho da equipe era pequeno e no havia a disponibilidade de consultar outros
profissionais, considerou que no seria necessrio ou produtivo.
P:As diretrizes de implementao de DSLs, transformaes e geradores de cdigo
facilitaram a implementao dos artefatos do MDD?
R:Este foi o ponto mais elogiado pela equipe. Por no terem muito conhecimento
sobre o desenvolvimento orientado a modelos, os participantes relataram que as
diretrizes de implementao ofereceram dicas importantes na implementao. Em
particular, foram citadas as diretrizes para mapeamento das features em linguagens,
o que segundo a equipe foi um ponto crucial no desenvolvimento dos modelos
de configurao da linha. Eles tambm reportaram que mesmo que nem todas
tenham sido usadas neste estudo, elas foram teis para uma melhor compreenso
do potencial desta abordagem e das facilidades que podem ser alcanadas no futuro
com o MDD.
276
P:O formato de documentao proposto foi adequado, auxiliando na descrio dos artefatos
reutilizveis desenvolvidos?
R:A equipe no chegou a documentar os artefatos produzidos, alegando que os mesmos
foram desenvolvidos apenas como prottipos experimentais, e consideraram mais
prioritria a sua concluso e evoluo antes da documentao.
P:Quais foram as vantagens de se utilizar a abordagem de MDD no desenvolvimento?
R:Segundo a equipe, a abordagem permitiu atacar problemas recorrentemente
enfrentados pela equipe, tais como o alto nvel de retrabalho procurando cdigos
e testando cada mudana no domnio, a existncia de arquivos que nunca so
utilizados mas que so includos nos produtos por convenincia, o que acaba por
confundir os desenvolvedores e causando problemas de manuteno, e a necessidade
de busca por links que precisam removidos dependendo da configurao de produtos
adquiridos pelo cliente. A automao conseguida com o MDD permitiu reduzir
estes problemas de forma que no vinha sendo conseguida, por falta de tempo
e dificuldades em desenvolver uma soluo que atendesse a mltiplos clientes ao
mesmo tempo. Por exemplo, a equipe citou alguns chamados recentes enviados
por clientes via helpdesk, referentes alterao urgente de dados dos certificados
emitidos nos eventos, por no estarem de acordo com o exigido ou desejado. Sem o
MDD, era necessrio criar novo cdigo toda vez que um chamado deste tipo era feito.
Aps este projeto, que envolveu a implementao do sub-domnios de certificados,
este trabalho feito diretamente no modelo.
P:Quais foram as desvantagens de se utilizar a abordagem de MDD no desenvolvimento?
R:A equipe citou principalmente as dificuldades de implementao dos geradores de
cdigo, pois os mesmos misturam cdigo PHP (dos produtos) com cdigo JAVA
e marcaes do JET, em um mesmo arquivo. Porm, os participantes acreditam se
tratar de uma limitao imposta pela dificuldade no aprendizado destas tecnologias
P:Quais foram as dificuldades para o aprendizado da abordagem?
R:A equipe relatou dificuldades no aprendizado das tecnologias de modelagem e
gerao de cdigo, porm com relao abordagem citaram apenas que tiveram
dificuldades em compreender as funes especficas dos casos de mudana na
abordagem. Segundo eles, no ficou clara a necessidade de se criar mltiplos
cenrios para descrever pequenas partes do problema.
277
P:Quais foram as dificuldades para definio do modelo de features?

R:A equipe teve dificuldades na identificao correta das features, sendo necessria
a presena constante do autor desta tese para orientar e corrigir as identificaes
equivocadas. No geral, os participantes compreenderam os conceitos, mas tinham
dificuldade em reproduzi-los no domnio em questo, inserindo constantemente e de
maneira equivocada, mdulos e funes como sendo features.
P:Quais foram as dificuldades para descrio da variabilidade em cenrios (casos de
mudana)?
R:A equipe identificou que a principal dificuldade foi a necessidade de se descrever
de forma exaustiva diferentes opes de variantes, em cenrios que pouco serviram
para o desenvolvimento dos demais artefatos. Segundo a equipe, seria mais fcil
descrever apenas as variaes mais complexas, utilizando texto e referncias ao
modelo de features.
P:Quais foram as dificuldades para a identificao de candidatos a sub-domnio?
R:Uma vez que o modelo de features estava finalizado, a equipe rapidamente
identificou candidatos a sub-domnio com base em sua experincia de atendimento
a chamados dos clientes.
Essa base histrica de uso dos sistemas, incluindo
experincias e chamados tcnicos registrados com detalhes de interao com cliente,

foi importante para essa identificao. Assim, no foram relatadas dificuldades
nesta etapa.
P:Quais foram as dificuldades para realizar o processo investigativo baseado em decises
para incluso/excluso de sub-domnios?
R:A equipe no chegou a realizar mais de uma iterao neste processo, tendo
optado por incluir dois sub-domnios em uma nica iterao. Portanto, no soube
responder esta questo de forma adequada.
P:Cite outras dificuldades percebidas durante a utilizao da abordagem de MDD desde o
incio do desenvolvimento.
R:A equipe tambm citou as dificuldades referentes operao do ambiente de
desenvolvimento, uma vez que no existe muita documentao a respeito destas
tecnologias.

Uma Abordagem Orientada A Modelos

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Uma Abordagem Orientada A Modelos

Încărcat de

Drepturi de autor:

Formate disponibile

Daniel Lucrdio

Uma Abordagem Orientada a Modelos para

Uma Abordagem Orientada a Modelos para

Renata Pontin de Mattos Fortes

I NSTITUTO DE C INCIAS M ATEMTICAS E DE C OMPUTAO

Academic organizations in computer science seem to prefer to work on new theories.

Foto da palestra de M.D. McIlroy na conferncia da OTAN em 1968 . . . . . .

Modelo de maturidade em reutilizao (GARCIA et al., 2007, 2008) . . . . . . .

Ilustrao do processo de criao de software no desenvolvimento orientado a

Principais elementos do MDD . . . . . . . . . . . . . . . . . . . . . . . . . .

Arquitetura clssica de metamodelagem . . . . . . . . . . . . . . . . . . . . .

Modelo de maturidade em MDD (MODELWARE, 2006b) . . . . . . . . . . . . .

Gerao de cdigo baseada em templates . . . . . . . . . . . . . . . . . . . .

Abrangncia da abordagem, em relao aos modelos de maturidade em

Exemplo de modelo de features para o domnio web . . . . . . . . . . . . . . .

Modelo de features do domnio web de autoria de contedo . . . . . . . . . . .

Uso do padro Abstract Factory para features alternativas . . . . . . . . . . . . 106

Uso do padro Prototype para features alternativas . . . . . . . . . . . . . . . . 107

Uso do padro Template method para features alternativas . . . . . . . . . . . . 108

Uso do padro Chain of Responsibility para or features . . . . . . . . . . . . . 109

Uso do padro Decorator para or features . . . . . . . . . . . . . . . . . . . . 110

Padro visitante sendo aplicado implementao de variabilidade baseada em

Abordagem template sendo aplicada gerao de cdigo baseada em features . 112

Padro camada fina de dados . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

Merging de geradores envolvendo modelos estruturais e comportamentais . . 116

Estratgia de caracterizao de sub-domnios . . . . . . . . . . . . . . . . . . 127

Modelo de features do domnio web de autoria de contedo . . . . . . . . . . . 129

Definio do metamodelo da DSL de autoria Web . . . . . . . . . . . . . . . . 131

Manuteno da consistncia da implementao de referncia . . . . . . . . . . 141

Sugesto de modelo de processo para utilizao da abordagem . . . . . . . . . 150

Comparao entre as mtricas de reutilizao para o estudo do domnio de

Comparao entre as mtricas indiretas de reusabilidade para o estudo do

Distribuies de instabilidade de mdulo nos diferentes tipos de artefatos

Distribuies de complexidade ciclomtica nos diferentes tipos de artefatos

Distribuies do ndice de manutenibilidade nos diferentes tipos de artefatos

Distribuies do nmero de atributos e do nmero de relacionamentos nos

Comparao entre as mtricas de reutilizao para o estudo do domnio de

Comparao entre as mtricas indiretas de reusabilidade para o estudo do

Distribuies de instabilidade de mdulo nos diferentes tipos de artefatos

Distribuies de complexidade ciclomtica nos diferentes tipos de artefatos

Distribuies do ndice de manutenibilidade nos diferentes tipos de artefatos

Distribuies de nmeros de atributos e relacionamentos nos modelos utilizados

Comparao entre as mtricas de reutilizao para o estudo do domnio de

Comparao entre as mtricas de reusabilidade dos estudos dos domnios de

Efeito da abordagem na reusabilidade dos artefatos produzidos . . . . . . . . . 190

Hiptese alternativa mais realista . . . . . . . . . . . . . . . . . . . . . . . . . 190

Situao clssica da anlise de sistemas . . . . . . . . . . . . . . . . . . . . . 242

Exemplo de caso de uso do domnio web . . . . . . . . . . . . . . . . . . . . .

Exemplo de caso de mudana para a feature opcional de busca . . . . . . . . .

Exemplo de caso de mudana para a feature alternativa de busca parcial . . . .

Resumo das atividades para anlise de domnio orientada a modelos . . . . . .

Descrio dos produtos de trabalho da fase de anlise de domnio . . . . . . . .

Resumo das atividades para projeto de domnio orientado a modelos . . . . . . 121

Descrio dos produtos de trabalho da fase de projeto de domnio . . . . . . . 122

Resumo das atividades para implementao do domnio orientada a modelos . . 147

Descrio dos produtos de trabalho da fase de implementao do domnio . . . 148

Dados sobre o estudo envolvendo o domnio de aplicaes distribudas baseadas

Dados sobre o estudo envolvendo o domnio de eventos cientficos . . . . . . . 174

Resumo das principais tcnicas relacionadas aos conceitos bsicos da

JSP Java Server Pages / Pginas Servidoras Java

RMM Reuse Maturity Model / Modelo de Maturidade em Reutilizao

Desenvolvimento orientado a modelos . . . . . . . . . . . . . . . . . . . . . .

Reutilizao de software e desenvolvimento orientado a modelos