Daniel Lucrdio

Uma Abordagem Orientada a Modelos para Reutilizao de Software

USP So Carlos SP Julho 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 Julho de 2009

Agradecimentos
Agradeo minha orientadora, Renata, que me acolheu e orientou durante todos estes anos. Alm dos diversos papis que lhe cabem ocialmente, sendo uma orientadora dedicada, interessada e competente, ela me ajudou muito dentro e fora do doutorado. Obrigado tambm aos membros da banca examinadora, Alessandro Fabricio Garcia, Claudia Maria Lima Werner, Ivan Luiz Marques Ricarte e Rosana Teresinha Vaccare Braga, que com seus valiosos comentrios durante a defesa ajudaram a enriquecer muito este trabalho. Agradeo tambm s instituies que zeram 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 nanceiramente. 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 signicado 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 car 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 nalmente 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 ocial entre o que z na empresa e o que z na universidade, mas a vivncia prtica na indstria foi sem dvida relevante para esta tese, e agradeo empresa e aos amigos que nela z: 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 m, agradeo minha amada esposa Alessandra e minha lha 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 el 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 dicultam 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 nal por meio de tcnicas de modelagem e gerao de cdigo. Com isto, parte da complexidade do software ca 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 ele deve ser tratado de forma consistente dentro de um processo de engenharia de domnio. Em particular, ele deve reconhecer que no possvel automatizar o domnio todo. Deve identicar os mltiplos subdomnios com diferentes graus de automao e gerenciar a sua integrao desde a anlise at a implementao. 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 congurao de produtos. Palavras-chave: Reutilizao de software, Desenvolvimento Orientado a Modelos, Engenharia de Domnio, Linhas de Produtos de Software, Linguagens Especcas de Domnio, Programao Generativa.

Abstract
Software reuse aims at increasing quality and productivity in software development, avoiding effort duplication and reusing all that is possible from past experiences. 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 make the reuse adoption difcult. Among these factors are 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 nal 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. This dissertation presents 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. Particularly, it must acknowledge that it is not possible to fully automate a domain. It must identify the multiple subdomains with different automation degrees and manage their integration from the analysis to the implementation. 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 benets that can be achieved with the combination of model-driven development and software reuse techniques. The results showed that the approach can bring different benets to software organizations, such as software reuse quantity and quality improvements, and complexity reduction in product development and conguration tasks. Keywords: Software Reuse, Model-Driven Development, Domain Engineering, Software Product Lines, Domain-Specic Languages, Generative Programming.

Lista de Figuras
1 2 Modelo de maturidade em reutilizao . . . . . . . . . . . . . . . . . . . . . . Ilustrao do processo de criao de software no desenvolvimento orientado a modelos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4 5 6 7 8 9 10 Principais elementos do MDD . . . . . . . . . . . . . . . . . . . . . . . . . . Arquitetura clssica de metamodelagem . . . . . . . . . . . . . . . . . . . . . Funcionamento do MDR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Comparao entre MDR e EMF . . . . . . . . . . . . . . . . . . . . . . . . . Modelo de maturidade em MDD . . . . . . . . . . . . . . . . . . . . . . . . . Gerao de cdigo baseada em templates . . . . . . . . . . . . . . . . . . . . Sugesto de modelo de processo para utilizao da abordagem . . . . . . . . . Abrangncia da abordagem, em relao aos modelos de maturidade em reutilizao e MDD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 12 13 Modelo de features do domnio web de autoria de contedo . . . . . . . . . . . 81 93 41 44 45 49 50 53 66 75 35

Candidatos a subdomnio do domnio web de autoria de contedo . . . . . . . 102 Possvel evoluo dos nveis de deciso para o domnio de aplicaes de autoria de contedo para Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

14 15 16 17 18 19

Modelo de features do domnio web de autoria de contedo . . . . . . . . . . . 116 Uso do padro Abstract Factory para features alternativas . . . . . . . . . . . . 126 Uso do padro Prototype para features alternativas . . . . . . . . . . . . . . . . 127 Uso do padro Template method para features alternativas . . . . . . . . . . . . 128 Uso do padro Chain of Responsibility para or features . . . . . . . . . . . . . 129 Uso do padro Decorator para or features . . . . . . . . . . . . . . . . . . . . 130

20

Padro visitante sendo aplicado implementao de variabilidade baseada em features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

21 22 23 24 25 26 27 28

Abordagem template sendo aplicada gerao de cdigo baseada em features . 132 Padro camada na de dados . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 Merging de geradores envolvendo modelos estruturais e comportamentais . . 136 Estratgia de caracterizao de subdomnios . . . . . . . . . . . . . . . . . . . 147 Modelo de features do domnio web de autoria de contedo . . . . . . . . . . . 148 Denio do metamodelo da DSL de autoria Web . . . . . . . . . . . . . . . . 151 Manuteno da consistncia da implementao de referncia . . . . . . . . . . 161 Comparao entre as mtricas de reutilizao para o estudo do domnio de autoria de contedo para a web . . . . . . . . . . . . . . . . . . . . . . . . . . 189

29

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

30

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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190

31

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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190

32

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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191

33

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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191

34

Comparao entre as mtricas de reutilizao para o estudo do domnio de aplicaes distribudas baseadas em computao em nuvem . . . . . . . . . . . 193

35

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

36

Distribuies de instabilidade de mdulo nos diferentes tipos de artefatos produzidos com a abordagem, no domnio de aplicaes distribudas baseadas em computao em nuvem . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195

37

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

38

Distribuies do ndice de manutenibilidade nos diferentes tipos de artefatos produzidos com a abordagem, no domnio de aplicaes distribudas baseadas em computao em nuvem . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196

39

Distribuies de nmeros de atributos e relacionamentos nos modelos utilizados com a abordagem, no domnio de aplicaes distribudas baseadas em computao em nuvem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196

40

Comparao entre as mtricas de reutilizao para o estudo do domnio de eventos cientcos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197

41

Comparao entre as mtricas de reusabilidade dos estudos dos domnios de eventos cientcos (EC), Web e Computao em Nuvem (CN) . . . . . . . . . 198

42 43 44 45

Efeito da abordagem na reusabilidade dos artefatos produzidos . . . . . . . . . 202 Uma possvel hiptese alternativa elaborada a partir dos resultados da avaliao 203 Processo de renamentos sucessivos na abordagem Draco . . . . . . . . . . . . 210 Situao clssica da anlise de sistemas . . . . . . . . . . . . . . . . . . . . . 257

Lista de Quadros
1 Identicao inicial das features de duas aplicaes do domnio de autoria de contedo para Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Compilao das features de quatro aplicaes do domnio de autoria de contedo para Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4 5 6 7 8 9 10 11 12 13 14 15 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 avanada . . . 92 94 94 95 91

Documentao do subdomnio de navegao . . . . . . . . . . . . . . . . . . . 106 Documentao do nvel de conana dos subdomnios identicados . . . . . . 107 Resumo das atividades para anlise de domnio orientada a modelos . . . . . . 112 Descrio dos produtos de trabalho da fase de anlise de domnio . . . . . . . . 113 Resumo das atividades para projeto de domnio orientado a modelos . . . . . . 141 Descrio dos produtos de trabalho da fase de projeto de domnio . . . . . . . 142 Resumo das atividades para implementao do domnio orientada a modelos . . 167 Descrio dos produtos de trabalho da fase de implementao do domnio . . . 168 Dados sobre o estudo envolvendo o domnio de autoria de contedo para Web . 183 Dados sobre o estudo envolvendo o domnio de aplicaes distribudas baseadas em computao em nuvem . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185

16 17

Dados sobre o estudo envolvendo o domnio de eventos cientcos . . . . . . . 186 Resumo das principais tcnicas relacionadas aos conceitos bsicos da reutilizao de software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270

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 CIM Computation Independent Model / Modelo Independente de Computao CVS Concurrent Versions System / Sistema de Verses Concorrentes 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-Specic Language / Linguagem Especca de Domnio ED Engenharia de Domnio EJB Enterprise JavaBeans 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 Grca 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 Grca 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 / Infraestrutura 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
1 acrnimo

recursivo

POSA Pattern-Oriented Software Architecture / Arquitetura de Software Orientada a Padres PIM Platform Independent Model / Modelo Independente de Plataforma PSM Platform Specic Model / Modelo Especco de Plataforma PuLSE ProdUct-Line Software Engineering / Engenharia de Software de Linha de Produtos QVT Queries/Views/Transformations / Consultas/Vises/Transformaes RAS Reusable Asset Specications / Especicaes de Artefatos Reutilizveis 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 Unied Process / Processo Unicado 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 SVN Acrnimo normalmente utilizado como referncia ao sistema SubVersioN para controle de verses UML Unied Modeling Language / Linguagem de Modelagem Unicada XMI XML Metadata Interchange / Intercmbio de Metadados em XML

Sumrio

Introduo 1.1 1.2 1.3 A tese . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Denio do escopo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Estrutura da dissertao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

19 23 25 26 29 29 36 55 57 57 62 67 69 69 71 72 74 81 84 85

Conceitos envolvidos 2.1 2.2 2.3 Reutilizao de software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Desenvolvimento orientado a modelos . . . . . . . . . . . . . . . . . . . . . . Consideraes nais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Reutilizao de software e desenvolvimento orientado a modelos 3.1 3.2 3.3 Anlise SCV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Implementao da variabilidade . . . . . . . . . . . . . . . . . . . . . . . . . Consideraes nais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Viso geral da abordagem 4.1 4.2 4.3 4.4 4.5 4.6 Objetivo da abordagem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Denio da abordagem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Estrutura da abordagem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Modelo de processo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Abrangncia da abordagem . . . . . . . . . . . . . . . . . . . . . . . . . . . . Consideraes nais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Anlise de domnio orientada a modelos

5.1 5.2 5.3 6

Objetivos da anlise de domnio . . . . . . . . . . . . . . . . . . . . . . . . . Atividades da anlise de domnio . . . . . . . . . . . . . . . . . . . . . . . . .

86 87

Consideraes nais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 115

Projeto de domnio orientado a modelos 6.1 6.2 6.3

Objetivos do projeto de domnio . . . . . . . . . . . . . . . . . . . . . . . . . 118 Atividades do projeto de domnio . . . . . . . . . . . . . . . . . . . . . . . . . 119 Consideraes nais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 143

Implementao de domnio orientada a modelos 7.1 7.2 7.3

Objetivos da implementao do domnio . . . . . . . . . . . . . . . . . . . . . 144 Atividades da implementao do domnio . . . . . . . . . . . . . . . . . . . . 146 Consideraes nais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 169

Avaliao 8.1 8.2 8.3 8.4 8.5 8.6 8.7

Denio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 Descrio dos projetos utilizados nos estudos empricos e sua execuo . . . . 181 Coleta dos dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186 Resultados e discusso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188 Anlise das hipteses e concluses . . . . . . . . . . . . . . . . . . . . . . . . 201 Ameaas validade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202 Consideraes nais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204 207

Trabalhos relacionados 9.1 9.2 9.3

Abordagens orientadas a modelos para reutilizao de software . . . . . . . . . 207 Trabalhos relacionados com o uso de mtricas para MDD e reutilizao . . . . 222 Consideraes nais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226 227

10 Concluses

10.1 Principais contribuies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227 10.2 Lies aprendidas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228 10.3 Limitaes e Trabalhos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . 229 10.4 Consideraes nais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232 Referncias Apndice A -- Tcnicas para reutilizao de software Apndice B -- Relao entre a abordagem e modelos de maturidade Apndice C -- Reproduo na ntegra da entrevista referente ao estudo emprico envolvendo o domnio de eventos cientcos 283 235 253 271

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 . Desde ento, a pesquisa na rea evoluiu, produzindo uma diversidade de trabalhos envolvendo reutilizao de software. Os esforos que 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). Porm, mesmo aps dcadas de pesquisa, ainda no possvel armar que existe uma abordagem voltada para reutilizao de software que seja amplamente utilizada e que permita
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 conveis de uma maneira controlvel e eciente.
1O

20

que uma organizao alcance os benefcios de qualidade e produtividade almejados por McIlroy e muitos outros desde ento. Um estudo recente (ALMEIDA, 2007) identicou 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 especcos, no sendo genricos o bastante para serem aplicveis fora de seu contexto original. Deve car 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 ecientes de trabalho disseminadas facilmente entre os indivduos de uma organizao, sem depender de talentos individuais. A necessidade de um processo sistemtico de reutilizao Em termos de reutilizao de software, faz-se necessrio um mtodo exvel, que possa ser adaptado para diferentes situaes, que possua diretivas e suporte sucientes, 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 (ENDRES, 1993; BAUER, 1993; GRISS, 1994, 1995;
JOOS,

1994), pesquisas informais (FRAKES; ISODA, 1994) e estudos empricos (RINE, 1997; 2002; ROTHENBERGER et al., 2003). Todos esses trabalhos mostraram

MORISIO; EZRAN; TULLY,

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 especcas (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,

21

sadas e artefatos produzidos) e requisitos um processo efetivo de reutilizao deve possuir (ALMEIDA et al., 2005). Este fato tambm pode ser vericado no cenrio brasileiro, onde um estudo de levantamento realizado em empresas (LUCRDIO et al., 2008) vericou 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: faz-se necessrio um processo sistemtico e completo de reutilizao, que complemente as idias para resolver partes mais especcas do problema. Neste sentido, a combinao de conceitos e tcnicas existentes em uma forma nova e inexplorada pode oferecer 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. 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 operao destas mquinas vitais precisa sobreviver em tal cenrio de mudanas drsticas e constantes. A histria mostrou que cientistas e prossionais 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 deve ser no apenas convel, 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 signicativamente 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

22

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 signicativas complexidades acidentais que surgem do uso de tecnologias inadequadas. A proposta do MDD (Model-Driven Development ou Desenvolvimento Orientado a Modelos) justamente resolver 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 implementao automaticamente, de forma a reetir a soluo expressa nos modelos (SCHMIDT, 2006). O MDD pode levar 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). Wile (2004) cita uma reduo de 50 para 1, em termos de linhas de especicao/cdigo, que pode ser alcanada atravs de tcnicas orientadas a modelos. 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 diculdades tcnicas e complexidade adicional para se construir o suporte necessrio para o desenvolvimento orientado a modelos, no nal 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 signica que hoje um artefato

23

precisa ser 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 beneciar com o MDD. Os principais pesquisadores da rea, como Neighbors (1980), Krueger (1992), Griss (1995), Frakes e Isoda (1994), Jacobson, Griss e Jonsson (1997), defendem 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 suciente. 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 modelos que focam em 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 - h uma necessidade de processos sistemticos para MDD. Mais especicamente, existe a questo sobre exatamente onde o MDD pode ser aplicado para automatizar a implementao de um domnio. Na prtica, sabe-se que muito difcil obter automao completa, isto , ser capaz de completamente gerar uma aplicao sem a necessidade de modic-la e/ou complet-la com cdigo manualmente escrito. Porm, existem reas de um domnio ou subdomnios onde o MDD pode efetivamente elevar a produtividade e reutilizao. Identicar quais so esses subdomnios, e gerenciar seu ciclo de vida de forma que a implementao nal possa integrar tanto o cdigo que gerado como o cdigo no-gerado que escrito manualmente de forma adequada, o foco principal desta tese.

1.1

A tese

A tese est contextualizada na premissa da literatura 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,

24

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. Neste contexto, o foco desta tese est na identicao de como aplicar o MDD durante a engenharia de domnio, considerando-se que no possvel automatiz-lo completamente. A pergunta a ser respondida : durante o ciclo de vida da engenharia de domnio, como identicar e gerenciar os subdomnios automatizveis e produzir uma arquitetura e implementao nais onde o potencial de automao destes subdomnios possa ser explorado e integrado com os demais subdomnios? A abordagem est centrada no conceito de subdomnios, e envolve a explorao dos seguintes pontos referentes unio entre MDD e reutilizao de software: Como identicar, em um domnio, subdomnios que possam ser automatizados por meio de tcnicas do MDD? Como lidar com o fato de que, para a identicao do potencial de automao de um subdomnio, pode ser necessrio um esforo investigativo que envolve tempo e custos para uma organizao? Como gerenciar os diferentes subdomnios e diferentes nveis de automao, considerando-se que a arquitetura e os componentes produzidos para o domnio devem ser capazes de promover a integrao entre eles? Como gerenciar a variabilidade no domnio, considerando-se que o resultado da engenharia de domnio inclui no somente uma arquitetura e componentes reutilizveis, mas tambm artefatos especcos do MDD, incluindo linguagens, transformaes e geradores de cdigo? Como gerenciar a existncia de cdigo gerado com cdigo no-gerado, nos diferentes nveis de abstrao em que so realizadas as atividades de anlise, projeto e implementao? Em quais aspectos o MDD pode inuenciar na reutilizao de software? O MDD promove aumento e/ou melhoria na reutilizao? Quais so os custos/benefcios de utilizao do MDD, em um processo de engenharia de domnio? Para validar esta tese, foi denida uma abordagem sistemtica para reutilizao de software, utilizando tcnicas do desenvolvimento orientado a modelos, e que cobre

25

as etapas de anlise, projeto e implementao de um domnio reutilizvel. o impacto do MDD na reutilizao de software.

Foram

tambm realizados estudos empricos visando avaliar a abordagem denida e determinar

1.2

Denio 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 denio de uma abordagem prtica, sem lacunas e usvel, em vez de 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 nal, que consistiu em colocar a abordagem em prtica em cenrios reais, pudesse ser realizada sem muitas diculdades. Caso a abordagem apresentasse pontos indenidos, ela 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 denidas 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 denir um processo completo para MDD, e sim em estender um processo voltado reutilizao com os conceitos do MDD. Assim, foram denidas 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. Atividades de testes no so explicitamente tratadas nesta abordagem. Apesar de existirem vrios aspectos a serem explorados com relao ao planejamento e realizao de testes num contexto de reutilizao e MDD, optou-se por no entrar neste mrito por uma questo de foco de pesquisa. Outro ponto que d margem a muitas possibilidades o ambiente de suporte ao MDD. Ferramentas so parte essencial do MDD, e existem diversas opes para o desenvolvimento

26

orientado a modelos. Nesta pesquisa, trabalhou-se com ferramentas j existentes, tais como aquelas apresentadas na Seo 2.2.2, em vez 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. Em resumo, est fora do escopo desta pesquisa: A denio detalhada das atividades do desenvolvimento com reutilizao; Atividades de manuteno dos artefatos, tais como aquelas relacionadas ao gerenciamento de congurao, por exemplo; Atividades para planejamento e execuo de testes; e 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. Mais detalhes sobre o escopo da pesquisa, em termos das prticas que esto includas e excludas da abordagem denida nesta tese, encontram-se no Captulo 4.

1.3

Estrutura da dissertao

Neste primeiro captulo apresentou-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 so apresentados resultados da avaliao da abordagem;

27

No Captulo 9 so apresentados os trabalhos relacionados; e No Captulo 10 so apresentadas as consideraes nais, contribuies e trabalhos futuros.

29

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 relacionados a 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 desaos 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 a 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,

30

casos de teste, modelos, interfaces para usurio, e at mesmo planos e estratgias, entre outros. 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, so extremamente dependentes da ecincia com que geram, assimilam e reutilizam seu conhecimento (DESOUZA; AWAZU; TIWANA, 2006). Estas armaes 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 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 intrnseca 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 amplicando problemas e defeitos ao invs de reduzi-los (EZRAN; MORISIO; TULLY, 2002).

31

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 denio 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 suciente.
ISODA,

Existe uma srie de fatores envolvidos: gerenciais,

organizacionais, econmicos, conceituais, legais e tcnicos (SAMETINGER, 1997; FRAKES; 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 especicamente 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);

32

Adaptao: a princpio, qualquer artefato pode ser reutilizado em um contexto diferente daquele em que foi projetado inicialmente, uma vez que se saiba que ele 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 suciente para atenderem s necessidades de diversas aplicaes possveis. Esses artefatos so ento adaptados para o novo contexto, por meio de parmetros, arquivos de congurao, ou mesmo pequenas modicaes; e Integrao: uma das diculdades inerentes reutilizao diz respeito arquitetura do software nal, 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 desaos e diculdades, como por exemplo tentar manter a consistncia e padronizao das interfaces, prever possveis necessidades de adaptao ou modicao, 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 especcas 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 suciente para que os benefcios da reutilizao sejam alcanados em sua mxima extenso, sendo necessrios outros fatores, como um bom gerenciamento organizacional e infraestrutura 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 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.

33

maior em determinada parte do processo, procurando solucionar parte do problema. Em termos gerais, um processo de reutilizao de software deve denir 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 deniu 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 denido 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 renamento por etapas (stepwise renement), que produzia um programa no qual alguns tipos de operandos e operadores eram deixados sem implementao; e o mtodo de especicao dos mdulos, que baseava-se na especicao 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 especicados. 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

34

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. Denio arquitetural: uma arquitetura de referncia tem papel chave na linha de produtos, oferecendo meios concretos para que diferentes produtos possam ser instanciados. Equivale denio de quais pontos de um programa devem ser deixados sem implementao, de acordo com as variabilidades identicadas; e 3. Abordagem em dois ciclos: consiste na diviso entre engenharia de domnio

e engenharia de aplicaes, de forma equivalente ao renamento por etapas ou especicao dos mdulos e criao dos programas. O grande diferencial das abordagens atuais a preocupao em denir o escopo da famlia de produtos de acordo com objetivos de negcio e estratgias de mercado, visando vantagens a longo prazo. Em outras palavras, dene-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 preliminar (GARCIA et al., 2007, 2008) analisou diversos trabalhos e modelos descritos na literatura, buscando identicar quais elementos de
2 http://www.sei.cmu.edu/productlines/plp_hof.html

35

processo so 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 nalmente 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 denido um modelo que rene as prticas comumente relacionadas reutilizao de software. O modelo inicial deste estudo (Figura 1) 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 1: 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 denio dos objetivos da reutilizao (AP3) e a implementao do domnio (AP4), porm ainda sem a preocupao com anlise e projeto voltados reutilizao;

36

Nvel 3 - Denido: 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). 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 busca identicar as prticas essenciais sem entrar em detalhes sobre como as mesmas so realizadas. O modelo tambm no dene 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 se relaciona com a presente abordagem so apresentados no Captulo 4. tambm neste nvel que se encontram as prticas ligadas engenharia de aplicaes (AP14), foco do

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 desaos at os dias atuais (FRANCE; RUMPE, 2007). Conforme discutido brevemente no Captulo 1, esses problemas derivam do fato de o software

37

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 (Unied Modeling Language ou Linguagem de Modelagem Unicada) (OMG, 2007) 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, esses 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 codicada. 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 codicada, de

38

forma que difcil identicar, 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 modicaes no software. Produtividade: o desenvolvimento de software normalmente constitudo de projeto de baixo nvel e codicao. Artefatos de alto nvel (modelos, diagramas) so produzidos antes da codicao, 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 codicao comeam, pois quaisquer eventuais mudanas que o software sofra so realizadas somente no cdigo e no so reetidas 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 modicar um estado, 50 linhas de cdigo precisam ser inseridas ou modicadas. 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

39

apreciada por desenvolvedores. possvel obter a documentao diretamente a partir do cdigo, usando tcnicas automatizadas de engenharia reversa. Porm, essa documentao seria apenas um reexo 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, modicar 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 identicar os trechos de cdigo a serem modicados. Sem esta informao de rastreabilidade, esta tarefa dicultada, exigindo uma busca cuidadosa no cdigo. Tambm pode levar a erros de inconsistncia entre os diversos artefatos relacionados. Por exemplo, a modicao de cdigo Java sem a modicao 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. Identicar, olhando apenas para o cdigo, a existncia de estados inalcanveis, transies innitas 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. de mais alto nvel associado.
3 http://jakarta.apache.org/struts/

Por exemplo, a remoo de estados

redundantes em uma mquina de estados seria facilitada caso houvesse algum tipo de artefato

40

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 carem 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 especcas 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 torna-se um requisito do software, trazendo consigo vrios outros, como a necessidade de equipes distintas, com prossionais e especialistas dedicados s diferentes partes do software. Tambm exige formas de comunicao mais ecientes 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: o MDD surgiu como uma maneira de se resolver estes problemas, utilizando uma abordagem altamente automatizada e com promessas de ganhos signicativos em termos de qualidade e produtividadeA seguir apresenta-se os principais conceitos e tcnicas envolvidas com o MDD.

41

2.2.1

Conceitos do desenvolvimento orientado a modelos

O desenvolvimento de software orientado a modelos (MDD - Model-Driven Development surgiu com o objetivo de ajudar a resolver os problemas citados na seo anterior (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 esses 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 2) 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, cando 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.

Figura 2: Ilustrao do processo de criao de software no desenvolvimento orientado a modelos

42

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; 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 modicaes diretamente no cdigo, fazendo com que a documentao que 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 prossionais 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 identicar mais facilmente os conceitos do negcio, enquanto especialistas em computao podem identicar os elementos tcnicos; Reutilizao: Diversos autores, tais como Krueger (1992), Griss (1995), Frakes e Isoda (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

43

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; Vericaes e otimizaes: os modelos oferecem mais munio para vericadores semnticos e otimizaes automticas especcas de domnio poderem ser executados. Isto pode reduzir a ocorrncia de erros semnticos e prover implementaes mais ecientes; Corretude: alm do fato de geradores no introduzirem erros acidentais, como erros de digitao, geradores permitem que a identicao 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 nal 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, signicativamente 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 ca 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; Curva de aprendizado: o desenvolvimento dos artefatos especcos do MDD exigem prossionais 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

44

Alto investimento inicial: assim como a reutilizao de software, o MDD depende de maior investimento inicial, uma vez que a construo de uma infraestrutura de reutilizao orientada a modelos requer mais tempo e esforo. Porm, os ganhos posteriores so signicativos, 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 3 mostra os principais elementos necessrios para essa abordagem, e como eles so combinados.

Figura 3: 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 especca de domnio, ou DSL (Domain-Specic Language), descrito no prximo captulo. Os modelos servem de entrada para transformaes que iro gerar outros modelos ou o cdigo-fonte. Para denir 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

45

tarefa complexa. Finalmente, necessrio um mecanismo que efetivamente aplique as transformaes denidas 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 denir 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 denio e execuo de transformaes genricas, as principais abordagens existentes na indstria para MDD se baseiam no conceito de metamodelagem (OMG, 2006b), apresentado na Figura 4.

Figura 4: Arquitetura clssica de metamodelagem O primeiro nvel (M0) corresponde aos dados propriamente ditos. O segundo nvel (M1) corresponde aos metadados, ou modelo. So os dados que descrevem os dados. O terceiro nvel (M2) o metamodelo, utilizado para a denio de modelos. A especicao UML um exemplo de metamodelo. O quarto nvel (M3) utilizado para denir metamodelos, ou seja, um meta-metamodelo dene linguagens de modelagem, como a UML, por exemplo. Um exemplo de meta-metamodelo o padro MOF, apresentado na prxima seo. No existe um quinto

46

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 MDA introduz os conceitos de CIM (Computation Independent Model ou Modelo Independente de Computao), PIM (Platform Independent Model ou Modelo Independente de Plataforma) e PSM (Platform-Specic Model ou Modelo Especco de Plataforma). Um CIM uma viso do sistema de um ponto de vista que no depende de computao. Um CIM no mostra detalhes da estrutura dos sistemas. tambm conhecido como modelo do domnio, e utiliza um vocabulrio familiar aos prossionais e especialistas no domnio em questo (OMG, 2003). Um PIM uma viso do sistema de forma independente da plataforma de implementao. Essa independncia de plataforma, no entanto, chega at um certo nvel, de forma que o mesmo modelo possa ser reaproveitado em diferentes plataformas do mesmo tipo (OMG, 2003). Um PSM uma viso do sistema do ponto de vista de uma plataforma especca. Um PSM combina as especicaes de um PIM com detalhes sobre como o sistema utiliza aquele tipo particular de plataforma (OMG, 2003). Na MDA, transformaes so utilizadas para transformar um modelo em outro, sucessivamente, at o cdigo-fonte. A transformao entre CIM e PIM menos passvel de automao, pois envolve mais decises e maiores possibilidades de interpretao dos requisitos. J a transformao entre PSM e cdigo-fonte mais passvel de automao, j que o PSM est intimamente ligado com a plataforma de implementao. A base da MDA o MOF (Meta-Object Facility) (OMG, 2006b), o meta-metamodelo que serve de base para a denio de todas as linguagens de modelagem. devido ao MOF que as ferramentas de modelagem e transformao podem trabalhar em conjunto.

47

O MOF consiste em um padro orientado a objetos que permite a denio de classes com atributos e relacionamentos, sendo bastante semelhante ao diagrama de classes da UML. Tambm dene 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 dene regras para a criao de interfaces especcas 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 dene o XMI (XML Metadata Interchange) (OMG, 2006c), um formato para representar modelos em XML. Este formato dene uma estrutura de documento que considera a relao entre os dados e seus correspondentes metadados. Assim, possvel para uma ferramenta, ao interpretar este formato, identicar quais os metadados que descrevem os dados sendo lidos. o M3 (Figura 4). Diferentes metanveis podem ser representados, desde o M0 at 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 nalizao, o QVT dene uma linguagem textual e uma notao para denir consultas e transformaes baseadas no MOF. Por meio dessa linguagem, possvel denir 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 (Unied Modeling Language) (OMG, 2007). Por exemplo, pers UML (OMG, 2006a) so o mecanismo preferido para representao de conceitos especcos de plataforma em um PSM. Mas sendo tambm instncia do MOF, a UML apenas uma das possveis linguagens de modelagem que podem ser usadas no MDD.

48

2.2.2.2

Abordagem Sun Microsystems

Devido ao presente cenrio competitivo vivido pelos fabricantes de ferramentas e ambientes de apoio ao desenvolvimento, a Sun Microsystems, principal responsvel pela tecnologia Java, tem especial interesse no desenvolvimento baseado em modelos. Como a maioria de seus competidores, a Sun, por meio de sua plataforma NetBeans, busca oferecer ao desenvolvedor a opo de se trabalhar simultaneamente no modelo e cdigo-fonte, seguindo as idias do MDD. Com essa motivao, a Sun concentra seus esforos em oferecer ferramentas que sigam os padres OMG, principalmente com duas iniciativas:

JMI (Java Metadata Interface4 ): trata-se de um mapeamento das interfaces MOF para a linguagem Java, de forma a possibilitar a manipulao de modelos compatveis com o MOF utilizando programao Java; e MDR (MetaData Repository5 ): um subprojeto NetBeans, e consiste em um mecanismo genrico de manipulao de modelos, como o discutido no incio deste captulo. Com base no padro MOF, capaz de importar/exportar modelos segundo o padro XMI, e disponibiliza interfaces no padro JMI para que os modelos sejam manipulados.

O funcionamento do MDR ilustrado na Figura 5. Uma ferramenta baseada no MDR pode implementar diferentes funcionalidades, tais como edio visual de modelos, gerao de cdigo, entre outras, beneciando-se das interfaces padro JMI. Parte dessas funcionalidades genrica, permanecendo a mesma para qualquer metamodelo, enquanto outra parte criada de forma especca para cada metamodelo, conforme as regras do MOF. O MDR implementa diretamente a parte genrica, enquanto a parte especca automaticamente gerada a partir da descrio do metamodelo em um arquivo no formato XMI. Desta forma, o MDR capaz de criar e manipular modelos em qualquer linguagem de modelagem, desde que seu metamodelo seja instncia do MOF. Internamente, os modelos podem ser mantidos em memria RAM, em um banco de dados, ou no sistema de arquivos do sistema operacional, em uma estrutura de rvore B. O MDR tambm persiste os modelos no formato XMI, possibilitando o intercmbio de modelos entre ferramentas e desenvolvedores.
4 http://java.sun.com/products/jmi/ 5 http://mdr.netbeans.org/

49

Figura 5: Funcionamento do MDR 2.2.2.3 Abordagem Eclipse

A abordagem liderada pela IBM baseada na plataforma Eclipse. Uma das bases dessa abordagem o EMF (Eclipse Modeling Framework6 ). 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 uma implementao do MOF, mas evoluiu para uma forma mais eciente, a partir da experincia obtida aps alguns anos na construo de ferramentas (ECLIPSE, 2005). Pelo mesmo motivo de ecincia, o EMF no segue elmente o padro JMI, mais voltado para repositrios persistentes. O EMF utiliza um subconjunto de mapeamentos de metamodelo para Java otimizados para manipulao em memria (ECLIPSE, 2006), o que o torna, alm de mais eciente, mais simples de ser utilizado, porm menos abrangente do que o conjunto mais completo formado pela combinao JMI/MOF (MOORE et al., 2004). Alm do metamodelo, existem outras duas diferenas principais entre o EMF e o MDR da Sun, conforme mostra a Figura 6. A primeira delas diz respeito natureza de cada abordagem. Com a proposta de ser um repositrio de metadados, o MDR oferece diferentes formas de armazenamento, tais como a representao em memria, banco de dados ou no sistema de arquivos, em estrutura de rvore B. J o EMF tem foco na manipulao eciente dos metamodelos, permitindo somente a representao em memria. Outra diferena que, no MDR, somente as interfaces de manipulao do metamodelo so geradas. O cdigo que as implementa um s para qualquer metamodelo. Estando embutido no MDR, esse cdigo utiliza programao reexiva para possibilitar o acesso s informaes do metamodelo. J no
6 http://www.eclipse.org/emf/

50

EMF, todo o cdigo de acesso ao metamodelo gerado, outra razo pela qual ele mais rpido do que o MDR.

Figura 6: Comparao entre MDR e EMF Outro projeto relacionado ao desenvolvimento orientado a modelos voltado plataforma Eclipse denominado GMT (Generative Modeling Tools7 ). Trata-se de uma iniciativa bastante recente, que se baseia nas idias do padres OMG, porm com algumas modicaes. 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 Language8 ): trata-se de uma linguagem para denio de 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 Script9 : esse projeto envolve o desenvolvimento de ferramentas e frameworks para transformao de modelos para texto, com base em uma linguagem para denio dessas transformaes; e TCS - Textual Concrete Syntax: esse projeto visa desenvolver ferramentas para a denio de DSLs textuais (JOUAULT; BZIVIN; KURTEV, 2006)10 .
7 http://www.eclipse.org/gmt/ 8 http://www.eclipse.org/gmt/atl/ 10 DSLs

9 http://www.eclipse.org/gmt/mofscript/

sero abordadas mais adiante, no Captulo 3.

51

Outro projeto, que fazia parte do GMT mas que se desvinculou por no mais se tratar de projeto incubado, o openArchitectureWare11 . 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 Framework12 ). Esse projeto permite a denio completa de um ambiente de modelagem para uma linguagem visual especca para um determinado domnio. A partir da denio do metamodelo da linguagem, da aparncia grca 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 denidos. 2.2.2.4 Outras abordagens

A Vanderbilt University abriga o projeto MIC (Model Integrated Computing), que pesquisa trs elementos principais relacionados ao MDD: tecnologias para modelagem especca de domnio, um conjunto de ferramentas para modelagem, e um framework para anlise formal, vericao e transformao de modelos. O principal produto desta pesquisa o GME (Generic Modeling Environment)13 , um ambiente de metamodelagem que permite a criao de ferramentas de modelagem especca 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 dene 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
11 http://www.openarchitectureware.org 12 http://www.eclipse.org/gmf/ 13 http://www.isis.vanderbilt.edu/projects/gme/

52

de ferramentas utilizadas para a produo, conguradas 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 denio de linguagens especcas de domnio, gerao de cdigo, entre outras funes. O UMT-QVT14
15

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 diculdade em se construir transformadores dessa forma, principalmente para transformar modelos. Neste sentido, as abordagens que utilizam linguagens visuais para denio de transformadores, como QVT e ATL, so mais apropriadas. O MTF (Model Transformation Framework16 ), 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 denio 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 openMDX17 foca na implementao dos conceitos da MDA, ou seja, o modelo a implementao. Porm, a insero de informaes especcas da plataforma de execuo deixada para a etapa de implantao somente, no ocorrendo na etapa de projeto, 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 especca 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.

14 Apesar

de constar no nome desse projeto, essa ferramenta no baseada na linguagem QVT do OMG.

15 http://umt-qvt.sourceforge.net

16 http://www.alphaworks.ibm.com/tech/mtf 17 http://www.openmdx.org/index.html

53

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, 2006d). Este modelo foi denido 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 no Captulo 9. Esse modelo dene as principais prticas e elementos de processo relacionados ao MDD, classicados em cinco nveis, conforme mostra a Figura 7.

Figura 7: Modelo de maturidade em MDD (MODELWARE, 2006d) Cada prtica identicada por um conjunto de caracteres que indica sua rea e um nmero sequencial, sendo que ENG = Engenharia, PJM = Gerenciamento de projeto e SUP = Suporte. As prticas 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

54

utilizados, incluindo todos os aspectos de um sistema, sem distino entre aspectos de negcio ou aspectos especcos 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 especcos de plataforma. O objetivo manter os aspectos de implementao independentes dos aspectos de negcio, de modo a melhorar a ecincia 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 vericao 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 denio, 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 especcos de plataforma (ENG8 e ENG9), modelos de negcio (ENG10) e transformaes modelo-para-modelo (ENG11) so denidos 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 Denitivo: neste ltimo nvel, todo o conhecimento da organizao mantido na forma de modelos e transformaes, que so o foco do processo de desenvolvimento. Prticas para o desenvolvimento de linguagens especcas de domnio (ENG15) e a vericao 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;

Algumas dessas prticas esto intimamente relacionadas com a abordagem desta tese, conforme descrito no Captulo 4.

55

2.3

Consideraes nais

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 da reutilizao e do MDD sejam alcanados. Porm, sem a existncia de um processo bem denido, 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 signicativo 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 identicar como as caractersticas de cada abordagem pode inuenciar a outra de forma a proporcionar um melhor resultado nal.

57

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. Nesta tese, foram identicados dois pontos importantes de interseco entre a reutilizao e o MDD: (i) a anlise de escopo, comunalidade e variabilidade (anlise SCV); e (ii) 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 variabilidade). Ela oferece aos engenheiros de software uma maneira sistemtica de pensar sobre e identicar a famlia de produtos que esto criando, ajudando, entre outras coisas (COPLIEN; HOFFMAN; WEISS, 1998):

58

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 identicao de oportunidades para automatizar a criao dos membros da famlia. Em outras palavras, identicando-se os pontos comuns e variveis de um domnio, pode-se construir artefatos reutilizveis que representam os pontos comuns, e projetar mecanismos congurveis 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 apresenta-se 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 por meio de features (LEE; MUTHIG, 2006). A modelagem de features identica os pontos comuns e variveis de um domnio em termos das features. Esta tcnica est descrita da seguinte forma por Kang et al. (1998): Features so identicadas e classicadas 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 identicadas como servios, operaes e caractersticas no-funcionais. Features de tecnologia do
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.
1 Nesta

59

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 grca 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 exibilidade 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]; 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 simplica o modelo; Relacionamentos: diferentes relacionamentos podem ser utilizados para relacionar features, tais como parte-de ou generalizao;

60

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 xa, 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 exvel para a anlise SCV, conforme descrito a seguir.

3.1.2

SCV no desenvolvimento orientado a modelos

Uma das formas para se realizar a anlise SCV no desenvolvimento orientado a modelos envolve a utilizao de linguagens especcas de domnio (DSL - Domain-Specic Language) para representao da variabilidade do domnio (VISSER, 2007). Uma DSL pode ser to simples como um wizard, ou uma linguagem completa, desenvolvida especialmente para representar a variabilidade (CZARNECKI, 2005). 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 especicao 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 . Uma linguagem especca de domnio pode ser textual (permitindo especicar programas) ou visual (permitindo especicar modelos ou diagramas), e normalmente possui trs elementos: a sintaxe abstrata, a sintaxe concreta e a semntica. A sintaxe abstrata dene os conceitos do domnio, e as relaes e restries que se aplicam a estes conceitos. Em linguagens textuais, representada por uma rvore (chamada
2 Uma

discusso mais aprofundada sobre DSLs e seu papel na reutilizao apresentada no Apndice A.

61

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 dene a estrutura dos modelos que podem ser criados (GUIZZARDI; PIRES;
SINDEREN, 2002).

Uma vez que este metamodelo uma especicao 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 denida (linguagem textual), ou cones grcos com caractersticas visuais que representam diferentes atributos, como cor, posio, tamanho e forma (linguagem visual) (GUIZZARDI; PIRES; SINDEREN, 2002). Trata-se de uma representao supercial, 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 dene o signicado 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 dene o que cada frase ou modelo signica 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 signicado a determinada palavra ou cone. No entanto, no contexto do MDD, a semntica denida 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 signicado do programa ou modelo; 2. Operacional: tambm conhecida como execuo cannica (CLEENEWERCK; KURTEV, 2007), consiste na interpretao do programa ou modelo como uma sequncia 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 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 especicadas de forma visual, em uma

62

linguagem especca para o domnio GUI (Graphical User Interface ou Interface Grca com o Usurio). Nesta linguagem, especica-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 denio 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 nal (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 xa.

3.2

Implementao da variabilidade

Conforme j identicado por Parnas (1976) h dcadas atrs, alm de muitos outros desde ento (MILI; MILI; MILI, 1995; EZRAN; MORISIO; TULLY, 2002), sistemas de software raramente

63

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 signica apenas as diferenas entre sistemas de software, mas tambm sua capacidade em ser estendido, modicado, customizado ou congurado de forma eciente 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, ela 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 identicao e modelagem da variabilidade. Em seguida, as atividades de projeto e implementao devem cuidar para que esta variabilidade identicada seja devidamente implementada, em forma de mecanismos congurveis 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 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,

64

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 especicado; Programao orientada a aspectos (AOP - Aspect-Oriented Programming): com AOP (KICZALES et al., 1997), 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 execuo, um programa instancia uma congurao do seu cdigo executvel selecionando as alternativas de aspectos que sejam adequadas ao seu estado atual; Arquivos de congurao: 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 congurao. 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 congurao (MUTHIG et al., 2002). Nesta abordagem, variantes alternativas de um mesmo artefato so includas ou excludas atravs de mecanismos de controle de verses, selecionando-se a verso que possui a variante desejada, por exemplo. Esta abordagem utilizada por muitos prossionais, mas frequentemente leva a problemas graves quando as variaes so muito complexas (MUTHIG; PATZKE, 2004). Isto porque, em geral, dependem de

65

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 especicaes 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 construir 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 especicao 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 especique 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. Bibliotecas com suporte a linguagens como XPATH (W3C, 1999a) facilitam o trabalho de se consultar as informaes.

66

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 8 ilustra esse processo, onde cada trecho do template processado, por meio do JET (Ver Seo 2.2.2.3), para consultar o arquivo de entrada e produzir o cdigo correspondente.

Figura 8: 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 especicao, ao invs de copiar um formulrio existente e modicar 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 problemas comuns envolvendo o desenvolvimento de software baseado em gerao de cdigo. Vlter (2003), Vlter e Bettin (2004) apresentam uma lista com estes padres.

67

3.3

Consideraes nais

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 identicada 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 denida 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.

69

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 nal feita uma anlise com os 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...
JOOS,

Para alcanar esta reutilizao

sistemtica, alm do foco no processo (ENDRES, 1993; BAUER, 1993; GRISS, 1994, 1995; 1994), deve-se promover uma mudana de paradigma, do desenvolvimento de 1994). Dessa forma, a reutilizao ocorre de forma mais ampla, aproveitando o sistemas nicos para a preocupao com uma famlia de sistemas similares (FRAKES;
ISODA,

potencial de similaridade entre as aplicaes (EZRAN; MORISIO; TULLY, 2002; MILI; MILI;
MILI,

1995);

70

Centrada em um domnio e seus subdomnios... Um domnio compreende um conjunto de aplicaes similares, que atendem a uma determinada rea de problema do mundo real (NEIGHBORS, 1980). Desta forma, focando-se em um domnio, tem-se um escopo bem denido para se planejar a reutilizao. O desenvolvimento centrado no domnio inclui a identicao 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. Alm disso, um domnio pode conter subdomnios distintos, cada um com maior ou menor potencial de automao. A abordagem busca identicar esses subdomnios e prover meios para gerenciar seu ciclo de vida e sua integrao, considerando a arquitetura nal composta por diferentes artefatos de software, tais como modelos, componentes, transformaes e geradores de cdigo; Com foco em aplicaes concretas... Identicar 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 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 infraestrutura de reutilizao que produzida pela abordagem inclui no somente componentes de cdigo, mas tambm artefatos do MDD: 1. Linguagens e ferramentas de modelagem especcas de domnio: consistem de linguagens com poder expressivo capaz de representar os conceitos do domnio, e

71

ferramentas capazes de criar modelos segundo estas linguagens, de forma a facilitar o entendimento de requisitos e a comunicao entre clientes/desenvolvedores; e 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 congurao, alm de outros artefatos que fazem parte do produto nal. 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, dene-se o objetivo desta abordagem da seguinte forma. Reutilizar software de forma sistemtica, considerando-se uma famlia de sistemas similares, seguindo uma abordagem centrada em um domnio e seus subdomnios, 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 especcas de domnio e transformaes de software.

4.2

Denio da abordagem

A abordagem foi denida aps estudos da literatura e desenvolvimento de estudos de caso de carter exploratrio. Foram estudados artigos cientcos e relatrios de empresas na rea de reutilizao e desenvolvimento orientado a modelos. Os resultados do estudo da rea de reutilizao foram publicados e podem ser encontrados na literatura (ALMEIDA et al., 2005;
ALMEIDA,

2007), enquanto os resultados do estudo da rea de desenvolvimento orientado a

modelos encontram-se no Captulo 9. Cada fase da abordagem foi denida separadamente e seguindo sua ordem natural. Buscou-se incorporar os pontos fortes das outras abordagens da literatura, por meio de atividades j bem estabelecidas, como aquelas do projeto e avaliao arquiteturais desenvolvidas pelo SEI (Software Engineering Institute) (BASS; CLEMENTS; KAZMAN, 2003; CLEMENTS;
KAZMAN; KLEIN,

2004). Buscou-se tambm preencher as lacunas e melhorar os pontos fracos

das abordagens descritas na literatura, atravs de novas tcnicas, como as atividades para identicao e gerenciamento dos subdomnios, descritas no Captulo 5. Nos pontos onde a literatura apresenta solues que no so diretamente aplicveis ao contexto do MDD, o objetivo foi adaptar as tcnicas existentes para o contexto desta tese. Por exemplo, no Captulo 6, que descreve o uso de padres de projeto normalmente utilizados para o gerenciamento da variabilidade (ALMEIDA et al., 2007b; KEEPENCE; MANNION, 1999; LEE; KANG, 2004), foram

72

incorporados detalhes referentes sua utilizao em conjunto com transformaes e geradores de cdigo. Da mesma forma, no Captulo 7 so descritas diretrizes de apoio s atividades de implementao de DSLs e geradores no contexto da Engenharia de Domnio. Outros exemplos so descritos durante os prximos captulos, no prprio texto que descreve a abordagem. Durante a denio das fases, foram desenvolvidos estudos de caso de carter exploratrio visando testar e renar cada atividade e artefato produzido. Estes estudos envolveram o domnio de aplicaes Web e posteriormente evoluram para o primeiro dos estudos de caso utilizados na avaliao, conforme descrito no Captulo 8. Reunies com o grupo de pesquisa e outros especialistas com os quais o autor tem colaborado tambm ajudaram a testar e renar a abordagem.

4.3

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 identicar o escopo do domnio, identicar pontos comuns e variveis do domnio, identicar possveis subdomnios automatizveis, e produzir documentao sobre estas informaes. O projeto do domnio tem como objetivo principal projetar uma arquitetura especca de domnio. Esta arquitetura deve contemplar as variabilidades identicadas durante a anlise, e oferecer suporte ao seu gerenciamento, considerando a existncia de diferentes tipos de variabilidades em cada subdomnio identicado e artefatos do MDD, como DSLs, ferramentas de modelagem e transformadores/geradores de cdigo. Por m, na implementao do domnio, so produzidos os artefatos de implementao, como componentes, DSLs, ferramentas de modelagem, 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 denem de forma sistemtica a sua execuo. Para cada atividade, so identicados 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 modicado ou no por uma atividade, e portanto ele possui diferentes estados em diferentes momentos da abordagem. Por exemplo, um modelo arquitetural pode estar

73

em estado inicial antes de uma determinada atividade, e passar para o estado renado 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 dene diretrizes que podem ajudar ou guiar a sua execuo.

Cada atividade identicada por uma sigla, no formato AD.X, PD.X ou ID.X, onde X um nmero sequencial, e AD, PD e ID representam Anlise de Domnio, Projeto do Domnio e Implementao do Domnio, respectivamente. Sub-atividades so identicadas incluindo-se outro nmero sequencial, como por exemplo AD.1.3, que identica a terceira sub-atividade da primeira atividade da fase de anlise de domnio. Da mesma forma, cada produto de trabalho identicado por uma sigla, no formato PT.X, onde X um nmero sequencial. Caso um produto de trabalho tenha diferentes estados, os mesmos so indicados aps a sigla, como por exemplo PT.2.Inicial, que representa o produto de trabalho 2, no estado Inicial. Os produtos de trabalho representam o conhecimento explcito, porm existe tambm o conhecimento tcito que utilizado nas atividades da abordagem. Estes so includos na entrada das atividades para indicar que aquele conhecimento necessrio para aquela atividade em questo. O conhecimento tcito representado junto com os produtos de trabalho, porm sem o prexo PT. Ao longo dos prximos captulos, exemplos do domnio de aplicaes de autoria de contedo para a Web so utilizados para melhor ilustrar as atividades da abordagem. Este domnio 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.

74

4.4

Modelo de processo

As atividades das fases de anlise, projeto e implementao do domnio sero descritas, nos prximos captulos, de forma sequencial, 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. Nesta seo apresenta-se o modelo de processo de desenvolvimento de software sugerido 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 frequentemente utilizados em conjunto, especialmente no desenvolvimento de grandes sistemas. 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 renando artefatos j existentes. A Figura 9 mostra o modelo de processo sugerido 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 9) que marca um momento de deciso sobre continuar ou no a execuo daquele ciclo especco. Cada ciclo detalhado a seguir.

4.4.1

Ciclo principal do modelo de processo: evoluo dos subdomnios

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 renamentos 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

75

Figura 9: Sugesto de modelo de processo para utilizao da abordagem de implementao. Estes renamentos 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 incluso/excluso de subdomnios. Conforme ser discutido no Captulo 5, a identicao de subdomnios pautada por uma incerteza que somente pode ser resolvida atravs de maiores investigaes envolvendo as linguagens, transformaes e geradores de cdigo para cada subdomnio. Assim, o ciclo principal gira em torno deste processo investigativo, que culmina com esta atividade, e a deciso nela tomada inuencia todas as demais atividades. O ciclo principal evolui da seguinte forma, a cada iterao; 1. Atividade AD.1. Planejamento do domnio: esta atividade consiste da preparao

76

e planejamento.

necessrio determinar se vale a pena investir na construo da Para isso, so levantadas e

infraestrutura reutilizvel para o domnio em questo.

registradas todas as informaes referentes ao domnio, so identicadas as features do domnio, que servem de base para a elaborao de um plano de desenvolvimento. A cada nova iterao, o plano inicial revisto, incluindo novas consideraes que possam ter sido elicitadas na iterao anterior, 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: esta atividade cuida da criao de modelos do domnio, agrupando as features identicadas na atividade anterior. Tambm so desenvolvidos cenrios do domnio, com foco na variabilidade. A cada iterao, o analista do domnio rena os modelos de features e cenrios, considerando-se a eventual incluso de novos artefatos ou mesmo novos subdomnios; 3. Atividade AD.3. Identicao de subdomnios: nesta atividade o objetivo tentar

identicar subdomnios com potencial para automao, com base em diferentes tipos de indcios, como a existncia de linguagens, ferramentas e documentao, que resultam em um determinado nvel de conana para cada subdomnio. A cada iterao, o analista do domnio revisita a lista de subdomnios, aps a experincia obtida com as implementaes e investigaes realizadas na iterao anterior. Novos nveis de conana podem ser atribudos aos subdomnios identicados, o que pode levar a novas decises posteriormente. Novos candidatos a subdomnio tambm podem ser identicados; 4. Atividade AD.4. Validao e documentao do domnio: esta atividade consiste na reviso da informao e criao de documentos que descrevem as features e modelos construdos nas atividades anteriores. A cada iterao, os documentos existentes so atualizados para reetir eventuais mudanas. Gerncia de congurao e controle de verses devem ser utilizados para manter estes documentos organizados; 5. Atividade AD.5. Deciso sobre incluso/excluso de subdomnios: nesta atividade, o analista do domnio, junto com o especialista e os demais stakeholders, analisam os subdomnios identicados com o objetivo de determinar se os mesmos sero includos nas fases subsequentes de projeto e implementao. A cada iterao, toda nova informao sobre os candidatos a subdomnio revista, e novas decises podem ser tomadas sobre eles; 6. Fase de projeto de domnio: na primeira iterao, esta fase cuida da criao de uma arquitetura para o domnio, com base nos requisitos mais relevantes conforme percebidos

77

pelos stakeholders e a existncia dos subdomnios. A cada nova iterao do ciclo principal, a fase de projeto produz renamentos na arquitetura, considerando-se os novos modelos do domnio, novos nveis de deciso sobre os subdomnios ou mais detalhes sobre as diretrizes arquiteturais que possam ter sido percebidos na iterao anterior. Estes renamentos podem inclusive resultar no surgimento de novos mdulos; e 7. Fase de implementao do domnio: na primeira iterao, esta fase cuida da

implementao das principais partes do domnio, conforme identicado na anlise, com a produo de componentes de software, DSLs, transformaes e geradores de cdigo. A cada iterao do ciclo principal, so introduzidos renamentos e mudanas na implementao, para reetir 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 os componentes. O resultado de sucessivas iteraes no ciclo principal um crescimento contnuo no nmero de artefatos do domnio e tambm no nvel de conana dos subdomnios a serem automatizados. Alm disso, cada vez mais subdomnios so descartados, medida que a experincia demonstra que eles so muito difceis ou impossveis de automatizar. Idealmente, no nal de vrias iteraes todos os subdomnios 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 subdomnios 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 subdomnios 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.

4.4.2

Ciclo de projeto do modelo de processo: evoluo arquitetural

Dentro do ciclo principal, a fase de projeto tambm ocorre de forma iterativa. A cada iterao no ciclo de projeto, novos mdulos so identicados, formando a arquitetura do

78

domnio.

Trata-se de um processo de renamento 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 identicao das camadas do domnio. Se for adotado o padro MVC (Model-View-Controller) (BUSCHMANN et al., 1996), a primeira diviso resulta na identicao dos elementos de modelo, de viso e de controle, e assim por diante. As iteraes seguintes renam cada mdulo de acordo com o padro escolhido. Por exemplo, ao se aplicar o padro Observer (GAMMA et al., 1995) em um mdulo, sero identicados 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 identicar novos mdulos, adicionar o suporte variabilidade prevista durante a anlise. Alm disso, tendo foco tambm no MDD, cada renamento identica 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 renados: a cada iterao, esta atividade escolhe novos mdulos para serem renados. Obviamente, na primeira iterao ainda no existem mdulos, e a escolha o domnio todo. As demais atividades so executadas individualmente para cada mdulo aqui escolhido; 2. Atividade PD.2. Seleo das diretrizes arquiteturais: esta atividade identica, para cada mdulo sendo renado nesta iterao, os principais requisitos de software que podem inuenciar 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 renado, e com base nas diretrizes

79

selecionadas para aquele mdulo, tticas e padres arquiteturais a serem aplicados no renamento do mdulo; 4. Atividade PD.4. Aplicao dos padres arquiteturais e renamento dos mdulos: esta a atividade onde efetivamente realizado o renamento dos mdulos. A cada iterao, com a aplicao das tticas e padres escolhidos, os mdulos so renados, possivelmente resultando na identicao de novos mdulos e relacionamentos; e 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 identicadas durante a anlise. Dependendo do nmero de mdulos identicados, 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 renados.

4.4.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 codicao, exigindo re-trabalho medida que a implementao avana. No caso desta abordagem, a iteratividade visa coletar informaes durante a codicao, realimentando a atividade de denio das linguagens especcas 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 suciente 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 codicao. Alm disso, a implementao envolve diferentes subdomnios. Cada iterao cuida do desenvolvimento dos artefatos de implementao para um nico subdomnio. Assim, caso existam dez subdomnios, por exemplo, sero necessrias dez iteraes neste ciclo. A fase de implementao evolui da seguinte maneira:

80

1. Atividade ID.1. Caracterizao da variabilidade dos subdomnios: esta atividade, que est fora do ciclo iterativo da fase de implementao, identica o tipo de variabilidade inerente a cada subdomnio. executada uma nica vez a cada iterao do ciclo principal, e seu objetivo denir o tipo de suporte em termos de DSL e ferramentas que ser necessrio para cada subdomnio. importante ressaltar que nem todos os subdomnios identicados na anlise iro passar pela fase de implementao. Somente so considerados os subdomnios 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. Denio das DSLs e do suporte ferramental: esta atividade cuida do desenvolvimento de uma DSL para um subdomnio, assim como o seu suporte ferramental (ferramentas de modelagem e editores). A cada iterao, mais subdomnios so implementados, at que todos aqueles selecionados na atividade AD.5 estejam implementados ou devidamente investigados; 3. Atividade ID.3. Desenvolvimento das transformaes e renamento das DSLs: nesta atividade, so desenvolvidas transformaes de software e geradores de cdigo para os subdomnios, e as DSLs denidas na atividade ID.2 so renadas a partir da experincia com a implementao. A cada iterao, novas transformaes e geradores so desenvolvidos, at que todos os subdomnios selecionados na atividade AD.5 tenham transformaes e geradores, ou foram devidamente investigados. Este desenvolvimento baseado em uma implementao de referncia, que serve como exemplo para a construo dos geradores de cdigo; 4. Atividade ID.4. Desenvolvimento do framework do domnio: esta atividade cuida do renamento 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 subdomnios; 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 denida no projeto.

81

importante ressaltar que nem sempre as iteraes dos ciclos da fase de implementao produzem artefatos que faro parte do domnio. Como o suporte automatizado a subdomnios incerto e exige investigao, o resultado da implementao pode ser insatisfatrio, de modo que alguns subdomnios podem no ser includos no processo. Esta deciso ir ocorrer na prxima iterao do ciclo principal, no nal da fase de anlise, subsidiada pelas experincias obtidas com a fase de implementao.

4.5

Abrangncia da abordagem

A abordagem denida 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. A Figura 10 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 10: 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 denio de seu modelo do ciclo de vida;
1 Uma discusso mais detalhada sobre cada prtica dos modelos de maturidade e a sua relao com a abordagem

aqui proposta apresentada no Apndice B.

82

AP3 - Denio dos objetivos da reutilizao: a abordagem contm uma atividade para denio 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 denio 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; 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 especco 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 especco 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;

83

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 especco 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 especco 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; ENG13 - Integrar desenvolvimento de produto com desenvolvimento de infraestrutura para uma famlia de produtos: esta a preocupao central da abordagem; ENG15 - Desenvolver linguagens especcas de domnio: a abordagem possui uma atividade especca 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 denio 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 dena 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. A comparao com estes modelos de maturidade visa somente deixar clara a abrangncia da abordagem com relao ao que existe, em termos de processo de software, conforme identicado pelos autores destes modelos. Estes modelos no foram utilizados como base para a denio da abordagem, mesmo porque apesar de representarem iniciativas promissoras, lideradas por importantes instituies de todo o mundo, ainda no so consolidados.

84

A deciso sobre quais prticas atender e quais no atender foi portanto baseada na literatura e nos estudos de caso, conforme descrito na Seo 4.2. Desta maneira, pode-se obter uma cobertura mais completa do ciclo de vida, desde a anlise at a implementao, ainda que isto signique que nenhum dos primeiros nveis de maturidade destes modelos seja alcanado.

4.6

Consideraes nais

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. Foi tambm apresentado 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 subdomnios. Porm, este modelo pode ser adaptado para reetir 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. A seguir as trs fases da abordagem so apresentadas em maiores detalhes, em captulos separados, e com cada atividade sendo descrita de modo sequencial, visando facilitar seu entendimento.

85

Anlise de domnio orientada a modelos

A anlise de domnio envolve a identicao 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 identicar 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 desaos 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 nal. 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 suciente 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 especca, 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

86

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 especcas de domnio (LEDECZI et al., 2001). Em um cenrio ideal, tudo o que um desenvolvedor precisa fazer escolher quais features estaro presentes, especicar 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 identicar 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 identicar 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; Denir o escopo do domnio a ser desenvolvido: um domnio pode alcanar uma vasta gama de aplicaes, cada uma com foco especco em determinada parte. Alm disso, a prpria denio 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 denir

87

com exatido o escopo a ser desenvolvido. Para tal denio, ao invs de buscar atender a artefatos genricos do domnio, de acordo com a percepo/intuio de especialistas, esta abordagem foca em um conjunto nito 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 Identicar os subdomnios 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 nal que, aps a engenharia de domnio, um desenvolvedor possa simplesmente congurar o produto desejado e acionar as transformaes que automaticamente geram uma implementao vlida. Assim, esta fase de anlise tambm tem como objetivo identicar subdomnios onde a automao possvel. A abordagem aqui proposta uma evoluo do mtodo descrito por Almeida et al. (2006). A diferena que aqui existe a preocupao com a identicao dos subdomnios 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 denir 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 identicao de possveis subdomnios (Atividade AD.3),

88

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 m, ocorre uma deciso sobre quais possveis subdomnios identicados 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: Informaes sobre sistemas do domnio, Conhecimento do especialista, Informaes sobre stakeholders Sadas: PT.1.Inicial. Planejamento do domnio, PT.2.Inicial. Mapa de aplicaes. Descrio: a primeira etapa cuida da preparao e planejamento. necessrio determinar se vale a pena investir na construo da infraestrutura 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 identicao dos stakeholders, anlise do mercado, coleta de informaes, e denio de objetivos e restries, de acordo com as anlises e informaes coletadas. Em seguida, realizada a denio do escopo (Sub-atividade AD.1.2), onde as aplicaes existentes, futuras e potenciais so identicadas, e o escopo do domnio denido.

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 identicao dos diferentes stakeholders, seus papis e interesses dentro do processo. Denio dos objetivos: corresponde denio dos objetivos, de acordo com os interesses dos stakeholders para o projeto. Denio de restries: compreende a denio das restries impostas pela organizao

89

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 xa para esta tarefa, que depende de condies especcas 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: Denir 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. Denio do escopo O objetivo desta sub-atividade identicar 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, identica 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

90

esto bem claros, porm o desenvolvimento ainda no foi iniciado) e aplicaes potenciais (aplicaes para as quais ainda no existem requisitos denidos, mas que so vistas como relevantes). Aps a identicao das aplicaes, a lista de features desenvolvida. A identicao 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 identicar 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 identicao de features, pode-se acelerar a comunicao entre o analista do domnio e os provedores de informao (especialista do domnio e usurios nais). 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 identicar as partes em comum: aplicaes de um mesmo domnio compartilham um alto 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, identicar as aplicaes existentes, e listar as features que caracterizam cada uma. Encontradas as diferenas, mais fcil identicar as features comuns. D4 . No identicar 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 identic-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. Por m, as aplicaes e suas features so organizadas na forma de um mapa de

91

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 identicar quais as features estaro presentes no domnio, e quais no estaro. Este um processo iterativo, e no precisa ser denido em denitivo logo na primeira iterao, sendo renado sucessivamente (GRISS; FAVARO; DALESSANDRO, 1998). Os Quadros 1 e 2 mostram um exemplo de como elaborar o mapa de aplicaes. No Quadro 1 so mostradas duas aplicaes do domnio de autoria de contedo para Web e suas features. Nota-se que neste nvel as features so identicadas de modo bastante informal, pois o objetivo fazer o levantamento inicial. Aps o levantamento ter sido feito com todas as aplicaes denidas para o escopo (existentes, futuras e potenciais), feita uma compilao das features, de forma a identicar aquelas mais ou menos comuns do domnio. Nesta compilao, algumas features podem ter seus nomes alterados, enquanto outras podem ser generalizadas ou suprimidas, para representar de forma mais correta os conceitos do domnio. O Quadro 2 mostra um exemplo de compilao envolvendo quatro aplicaes deste domnio.

Quadro 1: Identicao inicial das features de duas aplicaes do domnio de autoria de contedo para Web

92

Quadro 2: Compilao das features de quatro aplicaes do domnio de autoria de contedo para Web

O mapa de aplicaes e a lista de features, que extrada diretamente do mapa de aplicaes, 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: Informaes sobre sistemas do domnio, Conhecimento do especialista, Informaes sobre stakeholders, PT.1.Inicial. Planejamento do domnio, PT.2.Inicial. Mapa de aplicaes. Sadas: PT.3.Inicial. Modelagem do domnio. Descrio: esta atividade cuida da criao de modelos do domnio, agrupando as features identicadas 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. Nesta abordagem, a tcnica de modelagem de features utilizada (Seo 3.1.1). O analista do domnio agrupa as features identicadas na atividade anterior em uma hierarquia grca que captura relacionamentos estruturais lgicos entre as features. 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 especicam os procedimentos que mapeiam as abstraes em nvel de domnio.

93

A Figura 11 mostra o modelo de features criado para o domnio de aplicaes de autoria de contedo para a Web. Nota-se que as features identicadas na atividade anterior foram includas, alm dos relacionamentos entre elas e novas features, como link, Formulrio e Relatrio.

Figura 11: Modelo de features do domnio web de autoria de contedo, segundo a notao da ferramenta ToolDay (LISBOA, 2007)

Sub-atividade AD.2.1. Mapeamento da variabilidade em cenrios O objetivo desta sub-atividade mapear os pontos de variao, identicados na modelagem de features, para cenrios do domnio. A modelagem de features identica os pontos de variabilidade em termos estticos. Porm, o impacto destas variabilidades nas funes (comportamento) realizadas pelas aplicaes do domnio no ca 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)

94

(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 11, e o caso de uso referente feature de navegao, ilustrado no Quadro 3.

Quadro 3: Exemplo de caso de uso do domnio web Conforme mostra a Figura 11, o domnio contempla uma feature opcional de busca (crculo branco no nal do conector). Um caso de mudana que descreve essa feature opcional apresentado no Quadro 4.

Quadro 4: Exemplo de caso de mudana para a feature opcional de busca Neste exemplo, o caso de mudana CM001. Realizar busca simples descreve um cenrio de uso considerando-se a presena desta feature opcional. So tambm indicadas as features relacionadas, e os casos de uso afetados.

95

Mesmo um caso de mudana pode sofrer o impacto de algum outro ponto de variao. Neste exemplo, a busca pode ser simples ou avanada (features alternativas, indicadas pelos losangos nos conectores, no diagrama da Figura 11). O caso de mudana CM001. Realizar busca simples descreve o cenrio correspondente feature Busca simples. O Quadro 5 descreve a variante Busca avanada.

Quadro 5: Exemplo de caso de mudana para a feature alternativa de busca avanada 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 terceiro que contenha as interaes em comum, para facilitar o entendimento (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 uxo normal dos cenrios anteriores, assim como os uxos 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 denio 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

96

premissas, enquanto novos comportamentos so adicionados ou renados; 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 avanada (Quadro 5) introduz uma variabilidade positiva no passo 1, pois este um renamento que acrescenta um comportamento adicional, no violando as premissas do cenrio original. Tambm introduz uma combinao de variabilidades negativa e positiva no passo 2, pois neste cenrio, no mais ocorre uma busca no contedo todo, apenas no contedo especicado pelo usurio. Os uxos alternativos introduzem apenas variabilidades positivas, pois eles renam 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 nal. Assim, o uso de variabilidades positivas preferido (COPLIEN; HOFFMAN; WEISS, 1998; COPLIEN, 2000). Nesta tese, foram denidos 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 simples est presente em mais produtos do que a busca avanada, esta seria escolhida para incluso como um caso de uso. A busca avanada 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, pois esta prefervel (COPLIEN; HOFFMAN; WEISS, 1998; COPLIEN, 2000).

Para realizao do ltimo passo, o seguinte mtodo pode ser utilizado.

97

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 suciente, 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 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. No exemplo da busca avanada (Quadro 5), pode-se aplicar este mtodo para remover a variabilidade negativa, resultando em 3 cenrios: 1. Cenrio 1: Busca (a) Usurio informa parmetros de busca (b) Aplicao realiza busca no contedo conforme especicado pelos parmetros (c) Aplicao exibe lista com o contedo que corresponde aos parmetros especicados (d) Usurio clica sobre um resultado e continua navegando 2. Cenrio 2: Busca simples (a) Usurio informa string de busca (b) Aplicao realiza busca em todo contedo (c) Aplicao exibe lista com o contedo que corresponde string especicada (d) Usurio clica sobre um resultado e continua navegando 3. Cenrio 3: Busca avanada (a) Usurio informa string de busca e local a ser buscado

98

(b) Aplicao realiza busca no local especicado (c) Aplicao exibe lista com o contedo que corresponde string e locais especicados (d) Usurio clica sobre um resultado e continua navegando

Neste exemplo, as mudanas introduzidas pelos cenrios 2 e 3 no invalidam o cenrio 1, apenas acrescentam ou renam comportamento, e portanto s introduzem variabilidades positivas. A remoo forada de uma variabilidade negativa, porm, pode interferir com o real signicado dos modelos da base comum, produzindo impactos indesejados no projeto do domnio (COPLIEN, 2000). Por exemplo, em resposta aos cenrios acima, um projetista pode projetar uma soluo genrica onde o local a ser buscado um parmetro para o mecanismo de busca, que ir conter o nome deste local, ou a palavra tudo, caso se trate de uma busca simples. Em uma aplicao onde a busca avanada existe, esta soluo elegante e simples. Mas em uma aplicao onde a busca avanada no est presente, este parmetro no faz sentido algum, e acrescenta uma sobrecarga tanto no processamento (para ler e interpretar o valor de entrada deste parmetro), como na semntica dos modelos gerados. Assim, antes de se aplicar este mtodo, necessrio avaliar alguns fatores para determinar a sua real necessidade:

Peso da variabilidade negativa: caso a variabilidade negativa ocorra com pouca frequncia, pode no valer a pena gerar outros cenrios apenas para remov-la. Por exemplo, caso apenas 1% das aplicaes do domnio web possuam suporte para busca avanada, a soluo descrita acima pode no valer a pena; Tamanho da variabilidade negativa: variabilidades negativas pequenas so mais facilmente implementadas, utilizando-se, por exemplo compilao condicional (COPLIEN, 2000; ANASTASOPOULOS; GACEK, 2001). J a existncia de variabilidades negativas grandes (envolvendo, por exemplo diversas classes ou cenrios) pode indicar uma necessidade de reavaliao.

Atividade AD.3. Identicao de subdomnios

Papis: analista do domnio, especialista do domnio

99

Entradas: Informaes sobre sistemas do domnio, Conhecimento do especialista, Informaes sobre stakeholders, PT.1.Inicial. Planejamento do domnio, PT.2.Inicial. Mapa de aplicaes, PT.3.Inicial. Modelagem do domnio. Sadas: PT.4.Inicial. Candidatos a subdomnio. Descrio: a complexidade da maioria dos domnios torna virtualmente impossvel a tarefa de se formalmente especicar 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 dicilmente 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 identicao dos subdomnios uma tarefa crucial, pois permite ao engenheiro de domnio projetar e implementar ferramentas de modelagem, transformaes e geradores especcos para os subdomnios que possuem maior capacidade de automao, de forma mais controlvel. Esta atividade lida com esta identicao dos subdomnios 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 subdomnios (JARZABEK, 1997; HADDAD; TESSER, 2002; MAIDEN; SUTCLIFFE, 1996; LEE;
KANG,

2003). Apesar de no almejarem a criao de DSLs voltadas para o desenvolvimento

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 denidas 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 subdomnio 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 identicao de

100

subdomnios deve ser guiada por este prossional; 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 subdomnio ou parte de um subdomnio 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 subdomnio. A ateno s features que aparentam estar separadas das demais pode tambm levar identicao de um subdomnio distinto; Domnios atmicos: idealmente, o subdomnio identicado deve ser atmico, ou seja, no pode ser substancialmente decomposto sem alterar suas propriedades primrias (HADDAD; TESSER, 2002). Isto importante para manter o subdomnio 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 de forma idntica, provvel que uma mquina consiga fazer o trabalho de cpia parametrizada. Pode valer a pena tentar procurar um subdomnio 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 subdomnio, comeando-se com um escopo pequeno, desenvolvendo partes da linguagem e transformaes, e incrementando-o sucessivamente. As seguintes sub-atividades so responsveis pela identicao dos subdomnios. Inicialmente, feita uma seleo inicial de candidatos a subdomnio (Sub-atividade AD.3.1). Em seguida, so identicadas linguagens de modelagem (Sub-atividade AD.3.2) e ferramentas (Sub-atividade AD.3.3). Para cada subdomnio candidato, feita a atribuio

101

de nvel de conana (Sub-atividade AD.3.4), onde so avaliadas a maturidade e o estado de cada subdomnio identicado at o momento. Por m, os subdomnios so documentados (Sub-atividade AD.3.5). Sub-atividade AD.3.1. Seleo de candidatos a subdomnio O objetivo desta sub-atividade identicar potenciais subdomnios dentro do domnio. O analista do domnio tenta identicar, com base nas informaes coletadas e com o auxlio das diretrizes descritas anteriormente, possveis subdomnios. 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 identicar palavras-chave que representam um subdomnio. Conforme destacado por (MAIDEN;
SUTCLIFFE,

1996), a categorizao natural do domnio a melhor indicao de onde encontrar

um subdomnio. 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 identicao 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 nal. Esta tcnica tem o objetivo de auxiliar no processo de congurao dos produtos, determinando quais conjuntos de features estaro presentes dependendo da congurao desejada. O processo de anlise das FBUs inicia-se com a identicao das features de capacitao que representam servios independentemente congurveis, ou seja, as macro funcionalidades principais do domnio que podem ser adicionadas ou removidas de um produto como unidades 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 identicada, 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 congurveis. Cada FBU potencialmente um candidato a subdomnio, porm esta no necessariamente a melhor escolha. Pode-se, por exemplo, unir duas ou mais FBUs em um nico subdomnio, incluir ou remover features individualmente, ou mesmo sub-dividir uma FBU em mais de um subdomnio. Estas escolhas, porm, devem ser feitas somente mais adiante no processo, quando

102

mais maturidade sobre os subdomnios adquirida. Para cada candidato a subdomnio, as features correspondentes so identicadas. Isto pode ser realizado em uma matriz, relacionando cada feature ao seu subdomnio correspondente. Opcionalmente, pode ser produzida uma representao grca do subdomnio, em um diagrama que contm somente as features a ele pertencentes. A Figura 12 mostra quatro candidatos a subdomnio obtidos atravs da anlise de FBUs do domnio de aplicaes de autoria de contedo para Web.

Figura 12: Candidatos a subdomnio do domnio web de autoria de contedo Neste ponto, a sobreposio de subdomnios, caso ocorra, no um problema, uma vez que pode ser que alguns dos subdomnios sejam descartados. Posteriormente, com a evoluo do processo e os renamentos que se seguem, este problema ser analisado.

Sub-atividade AD.3.2. Identicao de linguagens de modelagem O objetivo da identicao de subdomnios possibilitar a denio 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 denio 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

103

consultado, alm das documentaes existentes, tais como manuais e documentao das aplicaes existentes, caso disponvel. A existncia de uma linguagem especca de domnio um dos indicativos de que este domnio est consideravelmente maduro e, portanto, os benefcios do desenvolvimento orientado a modelos sero maiores (TOLVANEN; KELLY, 2005). Caso exista cdigo-fonte disponvel, h a possibilidade de existirem exemplos de modelos ou linguagens especcas para o domnio ou algum subdomnio. importante ressaltar que modelos nem sempre possuem uma representao grca que segue alguma linguagem conhecida, como a UML, por exemplo. Outras linguagens, incluindo arquivos de congurao 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 identicadas, associando-as com os subdomnios correspondentes.

Sub-atividade AD.3.3. Identicao de ferramentas

A exemplo das linguagens especcas de domnio, a existncia de uma ferramenta de congurao ou modelagem um indicativo de que o subdomnio 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 identicadas 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 subdomnio ainda no identicado, acrescenta-se uma observao para posterior re-anlise.

104

Sub-atividade AD.3.4. Atribuio de nvel de conana Os subdomnios identicados 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 pode ser muito alto. A automao de um subdomnio tambm pode requerer alteraes e renamentos no modelo de features, o que obviamente causa grande impacto no desenvolvimento. Finalmente, dependendo de qual subdomnio implementado primeiro, outros subdomnios sobrepostos ou relacionados podem precisar ser revistos. Por este motivo, todos os subdomnios identicados so tratados como candidatos at serem completamente realizados. Alm disso, deve existir um certo nvel de conana de que um subdomnio 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 conana 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 conana de um subdomnio altamente subjetiva e dependente do conhecimento do especialista do domnio e da experincia dos engenheiros do domnio. Nesta tese, as seguintes questes foram identicadas por possuir impacto na deciso, e devem ser consideradas:

Existe uma linguagem de modelagem para o subdomnio? 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 especca para o subdomnio? 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?

105

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 subdomnio, utilizando-se uma linguagem de modelagem e ferramenta para gerao de cdigo? Para determinar o nvel de conana 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 conana. O analista do domnio deve consultar todos os stakeholders quando denir 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 subdomnios, 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 subdomnio Nesta atividade, o analista do domnio documenta os subdomnios identicados, incluindo toda informao coletada nos passos anteriores: as features envolvidas, linguagens e ferramentas, e o nvel de conana. Na prtica, a maior parte da documentao vai sendo construda durante o processo, e portanto esta atividade realizada em paralelo com as anteriores. Os Quadros 6 e 7 ilustram exemplos de documentao obtida nesta atividade. O Quadro 6 mostra a documentao do subdomnio de navegao, onde so informadas a descrio, as features envolvidas, linguagens e ferramentas identicadas. O Quadro 7 mostra a documentao do nvel de conana dos subdomnios identicados. Neste exemplo, somente quatro perguntas foram utilizadas, com peso atribudo conforme indicado no quadro. Aqui o analista tambm descreve a interao entre o candidato a subdomnio 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 subdomnio ou no. Em estgios posteriores, caso seja decidido que este subdomnio ser automatizado, esta

106

Quadro 6: Documentao do subdomnio de navegao interao dever ser renada, incluindo uma denio mais detalhada da interface entre os artefatos gerados para este subdomnio e outros artefatos.

Atividade AD.4. Validao e documentao do domnio

Papis: analista do domnio, especialista do domnio Entradas: Informaes sobre sistemas do domnio, Conhecimento do especialista, Informaes sobre stakeholders, PT.1.Inicial. Planejamento do domnio, PT.2.Inicial. Mapa de aplicaes, PT.3.Inicial. Modelagem do domnio, PT.3.Inicial. Candidatos a subdomnio. Sadas: PT.1.Validado. Planejamento do domnio, PT.2.Validado. Mapa de aplicaes, PT.3.Validado. Modelagem do domnio e PT.4.Validado. Candidatos a subdomnio. 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 por Czarnecki e 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 verica homnimos e sinnimos, com o objetivo de reduzir a ambiguidade. Em seguida, o domnio validado

107

Quadro 7: Documentao do nvel de conana dos subdomnios identicados com relao s informaes dos stakeholders, os requisitos iniciais e demais documentos relacionados.

Atividade AD.5. Deciso sobre incluso/excluso de subdomnios

Papis: analista do domnio, especialista do domnio Entradas: Informaes sobre sistemas do domnio, Conhecimento do especialista, Informaes sobre stakeholders, PT.1.Validado. Planejamento do domnio, PT.2.Validado. Mapa de aplicaes, PT.3.Validado. Modelagem do domnio, PT.4.Validado. Candidatos a subdomnio. Sadas: PT.5. Histrico de decises sobre incluso/excluso de subdomnios. Descrio: nesta atividade, o analista do domnio, junto com o especialista e os demais stakeholders, analisam os subdomnios identicados com o objetivo de determinar se os mesmos sero includos nas fases subsequentes de projeto e implementao. Essa deciso deve levar em considerao o nvel de conana dos subdomnios candidatos, e portanto a existncia de linguagens, ferramentas e outros indcios de sua maturidade, 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 subdomnios podem estar mais

108

maduros, enquanto outros necessitam de mais desenvolvimento. Neste sentido, ao invs de simplesmente incluir ou excluir um subdomnio, existem diferentes nveis de decises (D) a serem tomadas: D1 . Excluso imediata: signica que o candidato a subdomnio no passvel de automao, e deve ser descartado imediatamente. Tipicamente, este subdomnio tem um baixo nvel de conana, no existem linguagens de modelagem ou ferramentas que do suporte; D2 . Manter para avaliao posterior: signica que este subdomnio tem chance de ser automatizado, mas no existe evidncia concreta de que isto pode ser feito. Tipicamente, tem um baixo nvel de conana, 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 subdomnio 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 subdomnio pode se enquadrar no prximo nvel de deciso (D3 ); D3 . Iniciar investigao: se um subdomnio possui potencial para ser automatizado, mas as ferramentas para isso no esto disponveis, ele pode ser investigado, por meio do desenvolvimento de prottipos de linguagens de modelagem e/ou ferramentas de modelagem e transformaes. 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 subdomnio. Neste nvel de deciso, a organizao compromete-se a incluir o subdomnio no processo de desenvolvimento, diferentemente do nvel D3 , onde ainda existe a possibilidade de se descartar o subdomnio. Um subdomnio neste nvel deve possuir um alto nvel de conana, mas no necessariamente precisa possuir as ferramentas para ser automatizado. Esta uma deciso crtica, uma vez que signica empregar esforos e recursos de forma mais intensa, para automatizar o subdomnio e gerenciar o seu impacto no restante do domnio; D5 . Iniciar um projeto piloto: antes de incluir um subdomnio no processo nal, boa prtica executar um projeto piloto, para reduzir os riscos da introduo de uma nova

109

tecnologia no desenvolvimento, e reduzir as barreiras transferncia tecnolgica que ir ocorrer. Este projeto piloto tambm serve para se vericar os benefcios reais da nova tecnologia, e planejar a melhor maneira de aplic-la a projetos reais; e D6 . Incluso imediata: signica que o subdomnio est maduro o suciente, possui ferramentas e uma ou mais linguagens de modelagem estveis e validadas. O nvel de conana alto, e o subdomnio j pode ser includo nas fases de projeto e implementao. Tambm signica que o desenvolvimento dos artefatos deste subdomnio guiado pelas linguagens e/ou ferramentas denidas. Enquanto a maioria dos subdomnios somente ir alcanar este nvel aps passar pelos nveis 2, 3, 4 e 5, alguns subdomnios 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 subdomnio, pode ser vantajoso focar neste subdomnio, para que seus benefcios possam ser alcanados sem muito esforo de entendimento e aprendizado; Tamanho do subdomnio: sempre que possvel, deve-se comear com subdomnios 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, eles tendem a evoluir; Nvel de abstrao: subdomnios 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, em termos de facilidade de gerao de cdigo (TOLVANEN; KELLY, 2005). Em contrapartida, so em geral menos reaproveitveis; 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.

110

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 conana, denindo-se intervalos de valores para cada deciso. Por exemplo, em uma escala de 0 a 60, subdomnios com nvel de conana entre 0 e 10 levam a deciso D1 . Entre 11 e 20, deciso D2 , e assim por diante. Porm, esta tcnica serve apenas como referncia. A deciso nal deve ser tomada levando-se em conta outros fatores, e no somente os includos na mtrica. Os nveis de deciso so alterados medida que o domnio evolui durante as diversas iteraes do seu ciclo de vida, conforme descrito na Seo 4.4. medida que novos desenvolvimentos acontecem, novas informaes surgem como resultado e passam a ser consideradas durante a atividade de deciso. A Figura 13 mostra uma possvel evoluo dos nveis de deciso referentes a quatro candidatos a subdomnios do domnio de aplicaes de autoria de contedo para Web.

Figura 13: Possvel evoluo dos nveis de deciso para o domnio de aplicaes de autoria de contedo para Web

Inicialmente, toma-se uma deciso com base nas informaes disponveis inicialmente.

111

Neste caso, o subdomnio de cadastros apresentou um alto grau de conana, por j existirem linguagens e ferramentas disponveis, e que geram cdigo conforme requerido pelo projeto. Por isso foi colocado no nvel D4 , onde inicia-se o desenvolvimento dos artefatos de produo. Nas iteraes seguintes, esse subdomnio passou para o nvel D5 , onde iniciou-se um projeto piloto, e nalmente D6 , onde o mesmo passou a fazer parte do domnio. Os subdomnios de navegao e busca foram inicialmente colocados no nvel D3 , cando sob investigao, pois a conana sobre seu sucesso dentro do domnio no era suciente. Aps algumas iteraes, porm, o subdomnio de navegao foi considerado convel o suciente para iniciar a produo, que culminou com sua passagem para o nvel D6 . J o subdomnio de busca, aps investigao, foi considerado excludo, passando para o nvel D1 . O subdomnio de contedo de usurio apresentou um baixo nvel de conana inicial, e portanto permaneceu no nvel D2 para investigao posterior. Assim que todos os outros subdomnios terem sido investigados e terem sua situao denida, este subdomnio entrou em investigao, no nvel D3 . Mas aps investigao, concluiu-se que o mesmo tambm deveria ser excludo, terminando no nvel D1 . Ao nal dessa evoluo, o domnio passa a contar com os subdomnios de cadastros e navegao. Aps a tomada de deciso para todos os candidatos a subdomnio, o analista do domnio deve lidar com a sobreposio entre eles. Neste ponto, s possvel determinar se dois subdomnios iro interferir um com o outro analisando se eles possuem features em comum. Mesmo que no existam features em comum, pode ser que os artefatos gerados para um subdomnio interram ou tenham impacto nos artefatos de outro subdomnio. E no possvel determinar isto sem aprofundar-se no projeto e implementao. Alm disso, mesmo que no exista sobreposio de subdomnios em nenhum nvel, ainda assim a automao de um subdomnio pode afetar outros. Por exemplo, a automao de um determinado subdomnio pode levar a mudanas/renamentos nos requisitos, features ou casos de uso, para dar suporte a uma nova linguagem de modelagem ou ferramenta. Dessa forma, outros subdomnios 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 subdomnio pode estar em desenvolvimento a cada vez. Isto signica que as decises D4 , D5 e D6 so mutuamente exclusivas. Se j existir um subdomnio 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 subdomnio junto com o desenvolvimento de outro. Podem inclusive existir mltiplos

112

subdomnios 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 subdomnios sendo colocados em produo ao mesmo tempo. Na prtica, em geral, esta situao no ocorrer com muita frequncia, j que no comum a existncia de muitos subdomnios sendo automatizados.

5.3

Consideraes nais

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 algumas diretrizes para identicao dos subdomnios para automao. Tambm apresenta uma forma para lidar com os riscos da incerteza sobre a automao dos subdomnios. O Quadro 8 resume as atividades da anlise de domnio.
Atividades e sub-atividades AD.1. Planejamento do domnio AD.1.1. Preparao AD.1.2. Denio do escopo AD.2. Modelagem do domnio AD.2.1. Mapeamento da variabilidade em cenrios Entradas Informaes sobre sistemas do domnio Conhecimento do especialista Informaes sobre stakeholders Informaes sobre sistemas do domnio Conhecimento do especialista Informaes sobre stakeholders PT.1.Inicial. Planejamento do domnio PT.2.Inicial. Mapa de aplicaes Informaes sobre sistemas do domnio Conhecimento do especialista Informaes sobre stakeholders PT.1.Inicial. Planejamento do domnio PT.2.Inicial. Mapa de aplicaes PT.3.Inicial. Modelagem do domnio Sadas PT.1.Inicial. Planejamento do domnio PT.2.Inicial. Mapa de aplicaes PT.3.Inicial. Modelagem do domnio

AD.3. Identicao de subdomnios AD.3.1. Seleo de candidatos a subdomnio AD.3.2. Identicao de linguagens de modelagem AD.3.3. Identicao de ferramentas AD.3.4. Atribuio de nvel de conana AD.3.5. Documentao dos subdomnios candidatos AD.4. Validao e documentao do domnio

PT.4.Inicial. subdomnio

Candidatos

AD.5. Deciso sobre incluso/excluso de subdomnios

Informaes sobre sistemas do domnio Conhecimento do especialista Informaes sobre stakeholders PT.1.Inicial. Planejamento do domnio PT.2.Inicial. Mapa de aplicaes PT.3.Inicial. Modelagem do domnio PT.4.Inicial. Candidatos a subdomnio Informaes sobre sistemas do domnio Conhecimento do especialista Informaes sobre stakeholders PT.1.Validado. Planejamento do domnio PT.2.Validado. Mapa de aplicaes PT.3.Validado. Modelagem do domnio PT.4.Validado. Candidatos a subdomnio

PT.1.Validado. Planejamento do domnio PT.2.Validado. Mapa de aplicaes PT.3.Validado. Modelagem do domnio PT.4.Validado. Candidatos a subdomnio PT.5. Histrico de decises sobre incluso/excluso de subdomnios

Quadro 8: Resumo das atividades para anlise de domnio orientada a modelos O Quadro 9 descreve os produtos de trabalho da fase da anlise de domnio. O produto da anlise de domnio a denio completa do escopo, e a modelagem das

113
Produto de trabalho PT.1. Planejamento do domnio Descrio Documento que descreve o domnio, seus objetivos e restries, alm de listar os stakeholders e as aplicaes de exemplo Documento que mapeia todas as aplicaes do domnio e suas respectivas features Estado 1. Inicial: verso inicial do planejamento, pode conter inconsistncias. 2. Validado: planejamento vericado em busca de inconsistncias e erros. 1. Inicial: verso inicial do mapa, pode conter inconsistncias. 2. Validado: mapa vericado em busca de inconsistncias e erros. 1. Inicial: verso inicial da modelagem, pode conter inconsistncias. 2. Validado: modelagem vericada em busca de inconsistncias e erros. 1. Inicial: verso inicial do documento, pode conter inconsistncias. 2. Validado: documento vericado em busca de inconsistncias e erros. Nenhum

PT.2. Mapa de aplicaes

PT.3. Modelagem do domnio

PT.4. Candidatos a subdomnio

PT.5. Histrico de decises sobre incluso/excluso de subdomnios

Documento que detalha as features do domnio, especicando seus tipos e relacionamentos. Tambm contm os casos de uso do domnio, e informaes sobre os subdomnios Documento listando os subdomnios, as features correspondentes, e as listas de linguagens de modelagens e ferramentas especcas para os subdomnios Documento que registra as decises sobre incluso/excluso dos subdomnios nas diferentes iteraes do processo

Quadro 9: Descrio dos produtos de trabalho da fase de anlise de domnio 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 denidos nesta fase os candidatos a subdomnios automatizveis.

115

Projeto de domnio orientado a modelos

O projeto do domnio uma fase essencial da engenharia de domnio (BOSCH, 2000). Seu objetivo denir uma arquitetura de software especca de domnio, e um conjunto de artefatos reutilizveis que podem ser combinados para desenvolver aplicativos mais rapidamente e com maior qualidade. Uma arquitetura de software especca de domnio uma combinao de componentes de software, especializada para um tipo de tarefa em particular (domnio), generalizada para uso efetivo neste domnio e composta em uma estrutura padronizada efetiva para a construo de aplicaes bem sucedidas (TRACZ, 1995). 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 denio da arquitetura do domnio a reutilizao de software, e a capacidade de se desenvolver produtos de software similares rapidamente, sem muitas modicaes 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):

Congurao de rotina: tipo de variabilidade em que estruturas simples, como uma lista de propriedades ou uma rvore, podem ser utilizados para congurao 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

116

completamente. Diferentes mecanismos de representao de variabilidade podem estar em diferentes locais de um espectro que vai desde a congurao de rotina at a construo criativa. Por exemplo, wizards so mecanismos simples, onde a cada passo um parmetro especicado, e portanto localizam-se prximo congurao 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 especcas de domnio (DSL) (CZARNECKI, 2005). O modelo de features do domnio de autoria de contedo para Web, j utilizado no captulo anterior e replicado aqui na Figura 14, contm 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 14: 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

117

e links). Para representar esta variabilidade, no lado inferior da gura esto as features de 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 ca prxima do lado da congurao de rotina no espectro de variabilidade. Desta forma, grande parte do suporte variabilidade pode ser conseguido somente atravs de congurao, 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 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 escolhida normalmente uma linguagem especca 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 nal 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 como variabilidade baseada em DSLs. Tambm deve ter preocupaes sobre a existncia, alm dos componentes do domnio, de artefatos especcos do MDD, como DSLs, transformaes de software e geradores de cdigo. Um problema que a maioria das abordagens de engenharia de domnio existentes no dene como projetar uma arquitetura de software especca 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

118

de produtos (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), 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 identicao da variabilidade somente em termos de features. Como j discutido anteriormente, h outros tipos de variao, como aquelas presentes em modelos entidade-relacionamento, 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 especca 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 denio da arquitetura do domnio. Alm da variabilidade mais complexa discutida anteriormente, nesta abordagem a arquitetura e seus componentes contam com a existncia de DSLs e transformaes, que por sua vez devem ser capazes de produzir artefatos de implementao voltados quela arquitetura especca. A fase de projeto do domnio tem os seguintes objetivos:

Identicar 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/denir tticas e padres: o projeto arquitetural deve cobrir as diretrizes arquiteturais, em forma de tticas e padres que contemplem solues para cada requisito. Um padro consiste em uma soluo comprovadamente bem sucedida para determinados tipos de problema, com um contexto bem denido. Por trs de um padro existem

119

uma ou mais tticas, que representam as maneiras utilizadas pelo padro para resolver o problema; Denir a arquitetura e componentes: o projeto do domnio deve incluir uma denio da arquitetura do domnio. Junto com a arquitetura, devem ser especicados os 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 especcas 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 especcos para as diferentes formas de variabilidade, a exemplo de outras abordagens da literatura (ALMEIDA et al., 2007b; KEEPENCE; MANNION, 1999; LEE;
KANG,

2004).

6.2

Atividades do projeto de domnio

O projeto do domnio um processo iterativo de renamento. Inicia-se com o domnio todo, e a cada iterao feito um renamento que identica novos mdulos, que sero renados 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 renados (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 renamento dos mdulos (Atividade

120

PD.4), de forma a identicar novos mdulos e dar forma arquitetura. Por m, uma atividade avalia a arquitetura ou arquiteturas projetadas, caso sejam denidas diferentes opes arquiteturais (Atividade PD.5). Estas atividades so detalhadas a seguir.

Atividade PD.1. Escolha dos mdulos a serem renados

Papis: projetista do domnio Entradas: PT.3.Validado. Modelagem do domnio, PT.4.Validado. Candidatos a

subdomnio e PT.5. Histrico de decises sobre incluso/excluso de subdomnios Sadas: PT.6. Mdulos a serem renados Descrio: o projeto arquitetural desta abordagem baseia-se no mtodo ADD

(Attribute-Driven Design ou projeto orientado a atributos (BASS; CLEMENTS; KAZMAN, 2003)). O ADD promove o renamento sucessivo de mdulos, iniciando-se com o domnio todo, e realizando divises at serem obtidos os mdulos que iro formar a arquitetural nal. Assim, esta primeira atividade consiste na escolha dos mdulos a serem renados. O renamento pode ocorrer em duas dimenses: Dos pontos comuns para os variveis: um ponto de variao no projeto; e De mdulos para sub-mdulos: neste renamento, 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 renamento a cada iterao. No existe uma ordem especca, ou seja, pode-se iniciar com um renamento de mdulo para sub-mdulo, em seguida acrescentar um ponto varivel, depois novamente renar 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, identica se existem mdulos que ainda precisam ser renados, e os lista. Para cada um destes, executa as atividades seguintes, renando o mdulo novamente. neste renamento, inicia-se o projeto

considerando-se apenas os pontos comuns. Em seguida, a cada iterao, acrescenta-se

121

O renamento 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. Bass, Clements e Kazman (2003), aps anos de experincia em projetos envolvendo projeto arquitetural, observaram que trs nveis de diviso so normalmente sucientes, pois permitem detalhar de forma satisfatria as informaes essenciais para que o processo possa seguir adiante. importante lembrar que nesta abordagem j existe uma primeira diviso do domnio em subdomnios, 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 identicar 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.6. Mdulos a serem renados Sadas: PT.7. 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 identicar as diretrizes, os objetivos de negcio mais importantes so identicados 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). 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;

122

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 subdomnios: o projeto arquitetural precisa considerar os pontos onde diferentes subdomnios iro interagir. Isto envolve, por exemplo, a integrao entre 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 identicados, 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 renado 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 especcas de domnio para formalizar o espao de variao em reas particulares do domnio (subdomnios), denindo os conceitos e introduzindo restries e regras relacionadas variabilidade neste subdomnio. 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 subdomnio relacionado ao mdulo sendo renado. Caso seja necessrio desenvolver uma nova DSL, esta deve ser realizada posteriormente, na fase de implementao do domnio.

123

Sub-atividade PD.2.3. Seleo das diretrizes arquiteturais de integrao entre subdomnios importante ressaltar que subdomnios quase nunca esto isolados entre si. Por exemplo, com relao ao domnio web de autoria de contedo mostrado na Figura 11, o subdomnio de navegao pode conter referncias para o subdomnio de autoria (por exemplo, um formulrio que aponta para um tipo especco de documento). Assim, a arquitetura precisa estar preparada no s para a existncia de mltiplos subdomnios e possivelmente mltiplas DSLs (WARMER; KLEPPE, 2006; HESSELLUND;
CZARNECKI; WASOWSKI,

2007), mas tambm para a interao entre eles. Pode ser necessrio,

por exemplo, desenvolver um nico metamodelo para os mltiplos subdomnios, e ento desenvolver diferentes sintaxes concretas, de forma que estes subdomnios estejam integrados mas ainda assim possuir diferentes vises. Essa questo de integrao de domnios um assunto ainda no dominado. Nesta atividade, estas interdependncias entre subdomnios so explicitadas, pois podem ter impacto nas decises de projeto. Para isso, cada elemento em cada subdomnio deve ser inspecionado, e cada elemento que depende de um elemento em um subdomnio 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 identicao dos subdomnios deve acontecer de forma evolutiva e investigativa, desde a anlise (Atividade AD.5). A cada iterao, os subdomnios devem evoluir, com o avano da implementao, aumentando a conana em sua validade e identicando novas relaes entre os subdomnios. Na Seo 4.4 apresentado um modelo de ciclo de vida que discute este aspecto interativo e iterativo da abordagem proposta. Alm das relaes entre os subdomnios, o relacionamento entre cada subdomnio 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.7. Diretrizes arquiteturais

124

Sadas: PT.8. Tticas e padres arquiteturais Descrio: o objetivo desta atividade selecionar ou denir 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 o escopo de um domnio ou sistema. Alm disso, padres arquiteturais normalmente so escolhidos e utilizados conforme requisitos no-funcionais, como desempenho ou conabilidade. Normalmente, inicia-se com padres arquiteturais que denem a macro-estrutura do domnio, at chegar em padres menores que resolvem problemas mais especcos de partes do domnio. Alm disso, um padro arquitetural implementa uma ou mais tticas, 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 apresentada por Bass, Clements e Kazman (2003), porm esta no inclui tticas para lidar com variabilidade em um domnio, nem com a integrao entre subdomnios automatizados, como o caso desta abordagem (Sub-atividade PD3.3). Para implementar as tticas, existe uma grande quantidade de fontes de padres e estilos arquiteturais. Vale destacar a srie de cinco 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 (GAMMA

et al.,

1995) tambm pode ser til nesta atividade, 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

125

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 subdomnios. Para esta abordagem, foram selecionados alguns padres que auxiliam na implementao das tticas especcas para variabilidade e integrao entre subdomnios, 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 padro que sirva para um cenrio especco, pode-se modicar 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. 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 subdomnios. Alguns dos padres identicados nesta tese so baseados nos trabalhos de Vlter (2003), Vlter e Bettin (2004), que so muito teis para projetos de MDD, mas no so especcos 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 especca 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 so integrados com cada padro, j que partes do software so automaticamente geradas e precisam interagir com o restante do software. 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.

126

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.

Figura 15: Uso do padro Abstract Factory para features alternativas A Figura 15 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 (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.

127

Figura 16: Uso do padro Prototype para features alternativas A Figura 16 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 16, 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 Sub-feature A1. Para o comportamento associado s features, uma soluo a utilizao do Template method. A especicao do comportamento comum denida em mtodos abstratos de uma classe abstrata. O comportamento de cada alternativa implementado em classes concretas, com implementaes dos mtodos correspondentes. A Figura 17 ilustra o uso deste padro. O gerador apenas precisa gerar a criao do objeto concreto de acordo com a alternativa

128

selecionada (linha 3). Opcionalmente, a criao pode ser feita com o padro Abstract Factory.

Figura 17: Uso do padro Template method para features alternativas 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 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 denio 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

129

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.

Figura 18: Uso do padro Chain of Responsibility para or features A Figura 18 ilustra o uso do padro Chain of Responsibility na implementao de or 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 especco 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 especcos de cada sub-feature so chamados. O Chain of Responsibility permite a combinao de comportamentos sequenciais, ou seja, um executado aps o outro. Em interaes mais complexas, onde a ordem de chamada dos comportamentos especcos no sequencial, exigindo um cdigo especco para isso, o padro Decorator pode ser utilizado. Neste padro, cria-se um decorator para cada variante.

130

Em cada decorator implementa-se uma verso dos mtodos principais, considerando-se como esta variante modica o comportamento normal. O gerador apenas precisa fazer a concatenao dos decorators, de forma a reproduzir as variantes selecionadas.

Figura 19: Uso do padro Decorator para or features

A Figura 19 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 especcos 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.

131

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 (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 20 ilustra este padro.

Figura 20: 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,

132

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 exvel, sendo particularmente til para implementar or features, como ilustra a Figura 21.

Figura 21: Abordagem template sendo aplicada gerao de cdigo baseada em features O template principal responsvel por analisar os modelos de features e decidir quais templates sero chamados, quando sero chamados, e em qual ordem. No exemplo da Figura 21, 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 especica 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 denido 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 nal, eles podem ter impacto no sucesso do domnio. Anal, 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 na de dados, que facilita a

133

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 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 22 ilustra este padro.

Figura 22: Padro camada na de dados

Um segundo padro que pode ser utilizado, que deriva da camada na 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 na 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 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.

134

Sub-atividade PD.3.3. Padres de integrao entre subdomnios

Estes padres buscam promover uma boa integrao entre cdigo gerado e no-gerado, particularmente nas reas que envolvem os limites de um subdomnio. Os padres descritos nesta seo dividem-se em quatro categorias, dependendo da dependncia entre cdigo gerado e no-gerado, conforme descrito a seguir. 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 simplicar 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 modicar 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 simplicar o gerador, o padro Adapter (GAMMA et al., 1995) pode ser utilizado, para coletar, ltrar 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 diculdade 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.

135

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, 2004). 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 congurao programtica ou textual (normalmente XML). As dependncias devem ainda ser denidas em algum lugar, mas uma vez que isto s ocorre em uma entidade separada, estas so explcitas, sendo tambm mais facilmente denidas, o que acaba melhorando o entendimento do cdigo nal. O cdigo original pode ser compilado independentemente, facilitando testes e manuteno. Alm disso, o cdigo de congurao poderia ser gerado, de forma que at o processo de injeo seja automatizado. Por exemplo, possvel gerar arquivos de congurao para frameworks de injeo de dependncia como o Spring1 . Estes padres assumem que h um elemento xo 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 reexo podem ser a nica soluo para remover dependncias em tempo de compilao. Atravs da reexo, possvel transformar todas as chamadas de mtodos de cdigo no-gerado para cdigo gerado em chamadas reexivas, de forma que o mtodo sendo chamado desconhecido pelo compilador. Cdigo gerado depende de cdigo gerado: isto normalmente acontece quando h dois subdomnios que dependem um do outro. Um problema que surge do relacionamento entre mltiplos subdomnios 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 simplica 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.
1 http://www.springsource.org

No exemplo do domnio web de autoria de contedo,

136

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 vericador 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. Seja qual for a tcnica sendo utilizada, uma recomendao importante a de que a modicao 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 modicaes 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 especicao das partes faltantes, e ento combinar estes modelos utilizando um gerador especco. A Figura 23 ilustra a idia.

Figura 23: 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

137

comportamento pode ser especicado por modelos especcos, como mquinas de estados, ou mesmo diretamente em cdigo-fonte na linguagem de destino. Um gerador especco (merger) ento traduz e/ou copia estes trechos para os locais designados das estruturas geradas.

Atividade PD.4. Aplicao dos padres arquiteturais e renamento dos mdulos

Papis: projetista do domnio, especialista do domnio Entradas: PT.6. Mdulos a serem renados, PT.7. Diretrizes arquiteturais e PT.8. Tticas e padres arquiteturais Sadas: PT.9.Inicial. Projeto do domnio Descrio: nesta atividade, os padres so aplicados de acordo com as diretrizes selecionadas, e guiam o renamento 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 denio deste template. Esta atividade cuida do preenchimento do template. Como descrito na atividade PD.1, o renamento ocorre em duas dimenses: de ponto comum para ponto varivel e de mdulo para sub-mdulo. No caso de um renamento na dimenso de incluso de ponto de variao, denem-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 renamento da dimenso de diviso mdulo/sub-mdulo, denem-se quais novos sub-mdulos iro realizar os papis do padro. Este renamento guiado pelo padro sendo aplicado. Por exemplo, caso o padro Abstract Factory seja aplicado em um mdulo, iro surgir novos mdulos que correspondem s diferentes fbricas e produtos concretos. O mesmo ocorre no nvel arquitetural. Caso seja aplicado o padro em camadas, o renamento produz novos mdulos, um para cada camada, por exemplo. O resultado uma decomposio plausvel, guiada por um padro que tem por objetivo atender s necessidades arquiteturais especcas daquele mdulo (diretrizes) (BASS;
CLEMENTS; KAZMAN,

2003).

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

138

aquele mdulo especco, 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. 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. Assim, a denio da interface deste mdulo deve conter uma descrio desta varivel, do seu

Atividade PD.5. Avaliao arquitetural

Papis: Projetista do domnio, especialista do domnio, demais stakeholders Entradas: PT.7. Diretrizes arquiteturais e PT.8.Inicial. Projeto do domnio Sadas: PT.9.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 subdomnios, 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

139

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 denidos 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 reduzir o nmero de cenrios para aqueles que possuem impacto na arquitetura, e tentar incluir o ponto de vista de outros stakeholders, tais como usurios nais, gerentes, testadores, etc. Pode-se utilizar sesses de brainstorming para capturar o mximo de informao possvel; 2. Avaliar cenrios individualmente: neste passo, a exemplo do mtodo SAAM

citeClements:2004:book:evaluating, 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 reetem 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 interagem entre si, isto , exigem mudanas no mesmo local ou grupo de mdulos/componentes. reas onde existe grande interao entre cenrios podem signicar 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;

140

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 modicados 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 inuencia a implementao das DSLs e transformadores, que por sua vez podem inuenciar a arquitetura, resultando em mudanas que melhor acomodem a presena destes novos artefatos.

6.3

Consideraes nais

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 denio das diretrizes e padres arquiteturais especcos para o uso do MDD na reutilizao de software: variabilidade baseada em features, variabilidade baseada em DSLs e integrao entre subdomnios. Tambm apresenta uma atividade de avaliao arquitetural visando melhorar o resultado do projeto antes da implementao ter iniciado. O Quadro 10 resume as atividades do projeto de domnio. O Quadro 11 descreve os produtos de trabalho da fase da projeto de domnio. O produto do projeto de domnio a denio da arquitetura e seus componentes. Nesta

141
Atividades e sub-atividades PD.1. Escolha dos mdulos a serem renados Entradas PT.3.Validado. Modelagem do domnio PT.4.Validado. Candidatos a subdomnio PT.5. Histrico de decises incluso/excluso de subdomnios PT.6. Mdulos a serem renados Sadas PT.6. Mdulos a serem renados sobre PT.7. Diretrizes arquiteturais

PD.2. Seleo das diretrizes arquiteturais PD.2.1. Seleo das diretrizes arquiteturais de variabilidade baseada em features PD.2.2. Seleo das diretrizes arquiteturais de variabilidade baseada em DSLs PD.2.3. Seleo das diretrizes arquiteturais de integrao entre subdomnios 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 subdomnios PD.4. Aplicao dos padres arquiteturais e renamento dos mdulos PD.5. Avaliao arquitetural

PT.7. Diretrizes arquiteturais

PT.8. Tticas arquiteturais

padres

PT.6. Mdulos a serem renados PT.7. Diretrizes arquiteturais PT.8. Tticas e padres arquiteturais PT.7. Diretrizes arquiteturais PT.9.Inicial. Projeto do domnio

PT.9.Inicial. Projeto do domnio

PT.9.Avaliado. Projeto do domnio

Quadro 10: 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.

142

Produto de trabalho PT.6. Mdulos a serem renados

PT.7. Diretrizes arquiteturais

PT.8. Tticas e padres arquiteturais PT.9. Projeto do domnio

Descrio Consiste na denio dos mdulos a serem renados em uma determinada iterao do projeto do domnio. Iniciando com o domnio todo, a cada etapa um ou mais mdulos so renados e produzem uma nova verso da arquitetura do domnio Conjunto de requisitos importantes para a denio 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 subdomnios Descrevem solues para problemas comuns no projeto arquitetural orientado a modelos Resultado da fase de projeto, este produto de trabalho engloba a denio da arquitetura, com os mdulos e sub-mdulos, e a especicao das interfaces, considerando a existncia de componentes tradicionais, e artefatos do MDD, como DSLs, ferramentas, transformaes e geradores de cdigo

Estado 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 especca, que considera o ponto de vista de diversos stakeholders

Quadro 11: Descrio dos produtos de trabalho da fase de projeto de domnio

143

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 renamento 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 nais quanto ao projeto detalhado. Alm disso, sendo esta uma abordagem orientada a modelos, necessrio tambm implementar os artefatos especcos do MDD. Assim, a implementao deve tambm produzir linguagens especcas de domnio, transformaes e geradores de cdigo. Nesta tese, entende-se por gerador de cdigo qualquer artefato capaz de produzir automaticamente, com base em uma especicao de entrada, um trecho de cdigo como sada. Este trecho de cdigo pode ser qualquer tipo de elemento textual, mas normalmente corresponde a um programa escrito em uma linguagem de programao. Segundo esta denio, um processador automtico de templates, como o JET, um gerador de cdigo. Mas um arquivo contendo um template tambm considerado um gerador de cdigo, uma vez que este possui instrues especcas que inuenciam diretamente no cdigo gerado. Enquanto as fases de anlise (ARANGO, 1999; PRIETO-DAZ, 1990; KANG et al., 1990;
FRAKES; PRIETO-DAZ; FOX, MEI; ZHANG; GU,

1998; BAYER; MUTHIG; WIDEN, 1999; KIM; YANG; PARK, 2003;

2003; MOON; YEOM, 2005; ALMEIDA et al., 2006, 2005) e projeto

(ALMEIDA et al., 2005; BOSCH, 2000; BASS; CLEMENTS; KAZMAN, 2003; TRACZ, 1995) de

144

domnio para reutilizao so amplamente discutidas pela comunidade cientca, 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 denir um processo genrico, deve ser possvel generalizar detalhes especcos de plataforma e linguagem, de forma que o processo possa ser utilizado 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 congurao, 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 desao mais notvel na implementao de um domnio reutilizvel. A dimenso de gerenciamento de congurao, 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 baseia-se na idia de componentes de software. Um componente , por denio, 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). 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 xas 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 denido na fase anterior.

145

Alm disso, existe uma srie de critrios que precisam ser atendidos pela implementao de um domnio, dos quais se destacam aqueles que resultam da necessidade de um bom gerenciamento da variabilidade (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; 2. 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; 3. Separao de interesses: separao entre variantes e cdigo comum, de forma que mudanas podem ser feitas separadamente em ambos os cdigos; 4. Desempenho: a implementao deve proporcionar desempenho do produto nal de acordo com os requisitos. 5. 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, polimorsmo e orientao a aspectos, entre outros exemplos, fazem pouco sentido em artefatos como pginas HTML, scripts de criao de banco de dados, arquivos de congurao, 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 especcas. 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 6. 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.

146

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 nal 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 subdomnio identicado durante a anlise de domnio caracterizado em termos de sua variabilidade (Atividade ID.1). Em seguida so denidas as DSLs e o suporte ferramental (ferramentas de modelagem e editores especcos de domnio) (Atividade ID.2), por meio de uma abordagem top-down que utiliza os modelos de features para denir as DSLs para cada subdomnio. A seguir as DSLs so renadas, 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. reutilizao. A seguir estas atividades so descritas de forma detalhada. Finalmente, os artefatos construdos so documentados (Atividade ID.5) de forma a facilitar seu entendimento, manuteno e

Atividade ID.1. Caracterizao da variabilidade dos subdomnios

Papis: implementador do domnio, Especialista do domnio Entradas: PT.3.Validado. Modelagem do domnio, PT.4.Validado. Candidatos

a subdomnio, PT.5.

Histrico de decises sobre incluso/excluso de subdomnios,

PT.9.Avaliado. Projeto do domnio Sadas: PT.10. subdomnios caracterizados Descrio: um domnio pode ser dividido em vrios subdomnios, cada um com um potencial de automao. Durante a anlise, esta diviso se inicia, com a identicao de candidatos a subdomnio (Atividade AD.3). Durante o projeto, so identicadas as diretrizes arquiteturais que apresentam mais detalhes sobre o tipo de variabilidade de cada subdomnio (Atividade PD.2). Nesta atividade, cada subdomnio efetivamente caracterizado com relao

147

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 congurao de rotina e construo criativa. Nesta atividade, cada subdomnio analisado e inserido em um determinado local deste espectro. A Figura 24 ilustra esta estratgia. Para todo o domnio, uma ferramenta de features normalmente utilizada, junto com uma ferramenta de congurao automtica. Alguns subdomnios podem exigir uma soluo baseada em uma DSL completa, incluindo uma ferramenta de modelagem e geradores dedicados. Em outros, um simples wizard pode ser suciente.

Figura 24: Estratgia de caracterizao de subdomnios Para inserir cada subdomnio 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 conguraes de features que no mudam entre as aplicaes: se uma feature representa um ponto de variao, sua congurao 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 conguraes 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 conguraes das features que descrevem aquele ponto so as mesmas, isto pode indicar que

148

h alguma variabilidade que no pode ser representada como features, e talvez seja necessria uma DSL. Por exemplo, considere duas aplicaes web com suporte para busca avanada. Na primeira, possvel buscar por contedo de usurio pelo autor, data e palavras-chave. Na segunda, possvel buscar pelo autor, tipo do contedo, palavras-chave e outros metadados especcos desta aplicao. Neste exemplo, ambas as conguraes iro apresentar a feature Busca avanada, apesar de possurem detalhes distintos. D2 . 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 25 no podem ser meramente selecionadas ou de-selecionadas. Ao contrrio, elas precisam ser combinadas de forma criativa ao se congurar um produto.

Figura 25: Modelo de features do domnio web de autoria de contedo D3 . Procurar por mquinas de estados: muitos subdomnios 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 subdomnio ir provavelmente requerer uma DSL (mquina de estados) para sua variabilidade. D4 . Procurar por estruturas hierrquicas e de conteno: relacionamentos do tipo parte-de so comuns em um domnio. Apesar de normalmente poderem ser representados no

149

modelo de features, alguns relacionamentos parte-de exigem informaes extras. Por exemplo, no subdomnio GUI, um painel pode conter um ou mais botes. Mas onde estes botes esto localizados? Quais so seus tamanhos, cores e eventos associados? possvel incluir atributos em modelos de features (CZARNECKI; HELSEN; EISENECKER, 2004b) para expressar estas informaes. Mas em termos do poder expressivo e facilidade de compreenso por parte dos especialistas, uma DSL seria mais adequada neste caso. D5 . Tentar o caminho mais fcil primeiro: quanto mais prximo um subdomnio estiver do lado da congurao 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 subdomnio, o caminho mais fcil deve ser preferido, isto , com um wizard ou congurao de features. Se estes se mostrarem insucientes, ento uma DSL mais complexa pode ser desenvolvida. A sada desta atividade a caracterizao do tipo de variabilidade inerente a cada subdomnio. Mais importante, comea-se a identicar quais subdomnios iro requerer uma DSL dedicada.

Atividade ID.2. Denio das DSLs e do suporte ferramental (top-down)

Papis: implementador do domnio, Especialista do domnio Entradas: PT.3.Validado. Modelagem do domnio, PT.4.Validado. Candidatos

a subdomnio e PT.5.

Histrico de decises sobre incluso/excluso de subdomnios,

PT.9.Avaliado. Projeto do domnio, PT.10. Subdomnios caracterizados Sadas: PT.11.Inicial. ferramental para DSLs Descrio: dependendo do tipo de variabilidade para cada subdomnio, 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 denir quais conceitos podem ser utilizados, como eles se relacionam entre si, e possveis restries que possam existir. Isto pode Linguagens especcas de domnio, PT.12.Inicial. Suporte

150

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 especcos plataforma e arquitetura escolhidas. muito difcil perceber tais detalhes sem investigao mais aprofundada na implementao, e portanto uma abordagem bottom-up utilizada para renar 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 guras, cones, linhas, setas, entre outras representaes grcas. Para representar corretamente sua variabilidade, um subdomnio 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 suciente para identicar 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). O desenvolvimento de DSLs considerado uma cincia parte (CZARNECKI; EISENECKER, 2000), dada sua complexidade. Alm disso, no um processo muito previsvel, pois exige criatividade (VISSER, 2007). Esta abordagem busca prover alguma orientao, atravs de cinco sub-atividades, apresentadas a seguir. Sub-atividade ID.2.1. Identicao das features iniciais da DSL O primeiro passo identicar 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 26A. Neste domnio, dois subdomnios podem ser identicados: navegao (Contedo, Busca, Busca simples, Busca avanada, Contedo de usurio, Pgina, Formulrio,

151

Relatrio e Link) e autoria (Autoria, Tipo de documento e Relacionamento). As features de tecnologia do domnio do subdomnio de navegao iro fazer parte da DSL de navegao (Pginas, Links, Formulrios e Relatrios). Similarmente, a DSL do subdomnio de autoria ir incluir tipos de documentos e relacionamentos.

Figura 26: Denio do metamodelo da DSL de autoria Web

Sub-atividade ID.2.2. Denio da sintaxe abstrata No segundo passo, as features identicadas 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 26B mostra o metamodelo obtido para o subdomnio de autoria web. Elementos sombreados so derivados diretamente do modelo de features. Alm 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 denio 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;

152

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, em vez 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 identicar tais relaes inicialmente, mas novas podem aparecer posteriormente. Sub-atividade ID.2.3. Denio da sintaxe concreta O terceiro passo corresponde denio 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 podem representar os conceitos do domnio de forma adequada. Em DSLs visuais, blocos decorados e linhas so a notao padro. Formas geomtricas especcas, como retngulos e elipses, ou imagens, podem tambm ser utilizadas para 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

153

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. Denio 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 subdomnios. A integrao inter-DSL deve ser gerenciada de forma que o desenvolvedor possa especicar modelos em ambas as linguagens utilizando conceitos que se relacionam. Por exemplo, no domnio web de autoria de contedo, uma pgina de formulrio (do subdomnio de navegao) pode se referir a um tipo de documento (do subdomnio 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 para estabelecer relaes inter-DSL. Desta forma, consultas de mais alto nvel podem ser realizadas, facilitando a checagem da consistncia.

Sub-atividade ID.2.5. Construo da ferramenta de modelagem especca de domnio Uma vez que as sintaxes abstratas e concretas estejam denidas, uma ferramenta de modelagem especca para a DSL construda. Frameworks de DSLs, como GMF ou openArchitectureWare, entre outros, so a tecnologia mais apropriada 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 denio 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

154

pode garantir que o comportamento de uma entidade em um jogo, modelada atravs de uma DSL visual, sempre tenha um comportamento padro denido. Aps este quinto passo, obtm-se um conjunto de DSLs e ferramentas que permitem que um desenvolvedor represente diferentes tipos de variabilidade em cada subdomnio identicado, 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 renamento das DSLs (bottom-up)

Papis: implementador do domnio, Especialista do domnio Entradas: PT.9.Avaliado. PT.3.Validado. Modelagem do domnio, PT.4.Validado. Candidatos

a subdomnio, PT.5.

Histrico de decises sobre incluso/excluso de subdomnios, Subdomnios caracterizados, PT.11.Inicial.

Projeto do domnio, PT.10.

Linguagens especcas de domnio, PT.12.Inicial. Suporte ferramental para DSLs Sadas: PT.11.Renado. Linguagens especcas de domnio, PT.12.Renado. Suporte ferramental para DSLs, PT.13. 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 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 dene o signicado dos elementos da linguagem. No contexto do MDD, a semntica denida 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. Transformaes do domnio, PT.14. Implementao de

155

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 subdomnios identicados 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 renar as DSLs iniciais. Partir de uma instncia concreta de como o cdigo deve ser mais fcil do que identicar 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 denida na fase de projeto, utilizando as tticas e padres associados para produzir uma implementao que ir dar suporte ao desenvolvimento subsequente. 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 nita. 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.

156

D2 . Para cada feature opcional, modicar o exemplo, criando uma nova verso do mesmo, de forma que a feature esteja presente. Caso algum dos padres de projeto descritos no captulo anterior tenha sido utilizado neste ponto do projeto para implementar esta variante em particular, basta realizar uma simples seleo da variante conforme previsto pelo padro. Porm, pode ser que neste momento da implementao seja identicado um detalhe no previsto durante o projeto. Assim, deve-se tambm avaliar a aplicao de um novo padro neste ponto para facilitar sua seleo no futuro. D3 . Para features alternativas, modicar o exemplo para considerar a presena de cada alternativa separadamente, e em diferentes combinaes. O uso de padres destacado pela diretriz D2 tambm deve ser considerado para este tipo de feature. 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 congurao em estgios (CZARNECKI; HELSEN; 2004b), tentando eliminar as variabilidades em uma sequncia lgica,

EISENECKER,

considerando primeiro as features mais comuns, para reduzir o nmero de possibilidades e o nmero de verses produzidas a cada renamento. D6 . Dar maior ateno s variabilidades que possuem maior impacto na arquitetura, aquelas que so mais frequentes, 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 no interram 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. D10 . Se existirem uma 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

157

o nmero de combinaes de elementos do domnio literalmente innito. necessrio 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 especicao 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 identicar principalmente a presena de variantes no cdigo, e mape-las para as DSLs correspondentes. A incluso de uma variante no cdigo normalmente resulta em modicaes em diferentes artefatos. H quatro tipos de modicaes que podem co-existir em um domnio (ANASTASOPOULOS; GACEK, 2001):

Adio de novas funcionalidades: refere-se incluso de novos componentes, classes, 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;

158

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 modicaes na plataforma ou ambiente de execuo. Por exemplo, no domnio web, a incluso da feature de busca pode requerer a incluso de uma biblioteca especca, uma verso diferente do banco de dados, ou mesmo uma mquina virtual diferente. Esta atividade cuida da identicao 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 modicado do cdigo precisa ser mapeado em pelo menos uma variante descrita em uma DSL ou modelo de features. Se existir uma modicao, mas no existirem elementos em uma DSL que a descrevam, ento a DSL provavelmente precisa ser renada (sub-atividade ID.3.3). Em alguns casos, uma modicao pode aparentemente ser mapeada para diferentes elementos de uma ou mais DSLs, o que signica que esta modicao pode ser causada por 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 modicaes, em vrias partes da implementao de

159

referncia, serem mapeadas a um mesmo ponto de variao, o que signica que este elemento da DSL est espalhado em diferentes partes do cdigo. Caso existam muitas modicaes 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. Renamento 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 identicar 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 denidas na abordagem top-down. Nestes casos, uma ou mais DSLs precisam ser renadas, para introduzir novos elementos, modicar ou remover elementos existentes. Podem ser necessrias alteraes na sintaxe abstrata, quando o renamento for mais conceitual, alteraes na sintaxe concreta, quando o renamento 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 renada 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 renamento consistente. Sub-atividade ID.3.4. Desenvolvimento das transformaes e geradores de cdigo Com o renamento das DSLs, o implementador constri 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, como tags e scriptlets, que fazem a associao entre o cdigo e a DSL. Cada trecho de cdigo correspondente a alguma variabilidade, identicado na sub-atividade ID.3.2, recebe algum tipo de anotao. Tags normalmente do suporte a comandos mais simples do tipo condicional ou iterativo.

160

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. Especicando-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 exveis 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 modicar 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 modique a implementao de referncia. Mas esta situao pode acontecer, j que durante a migrao de cdigo pode-se identicar 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 modica o template para implementar esta soluo, fazendo com que a implementao de referncia se torne inconsistente. Mesmo que a migrao de cdigo no modique a implementao de referncia, a prpria evoluo do domnio normalmente causa este tipo de inconsistncia. Sempre que for necessrio 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, modica-se diretamente os templates, causando

161

inconsistncia. Para lidar com estes problemas, o seguinte processo aplicado quando necessrio realizar alguma alterao (Figura 27).

Figura 27: 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 modicaes, nada precisa ser realizado. 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. Caso contrrio, a implementao de referncia precisa ser substituda, e a maneira recomendada gerar

Atividade ID.4. Desenvolvimento do framework do domnio

Papis: implementador do domnio, Especialista do domnio Entradas: PT.14. Implementao de referncia Sadas: PT.15. 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

162

identicao das variabilidades no cdigo nal. 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 denida a partir de um processo centrado no suporte variabilidade e com o objetivo de implementar diferentes diretrizes arquiteturais; A implementao de referncia no dene 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 xos 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 especicar as interfaces resultantes da aplicao dos padres. Por exemplo, caso tenha sido utilizado o padro Decorator para features alternativas complementares, aqui so denidas as interfaces de cada alternativa, com seus mtodos sendo descritos individualmente. 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
discusso mais aprofundada sobre frameworks e seu papel na reutilizao de software apresentada no Apndice A.
1 Uma

163

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

Papis: implementador do domnio, Especialista do domnio Entradas: PT.11.Renado. Linguagens especcas de domnio, PT.12.Renado. Suporte ferramental para DSLs, PT.13. Transformaes do domnio, PT.15. Framework do domnio Sadas: PT.16. 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 identicar,

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). 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

164

Asset Specications ou Especicaes 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 especco para a documentao, alm de alguns princpios: P1 . Hipertexto. O hipertexto mostrou-se uma tcnica eciente 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 denio 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 guras. A documentao deve incluir diagramas e guras sempre que possvel. No MDD, muitas das informaes visuais esto disponveis na prpria linguagem especca 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 por 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 denio das interfaces e informaes sobre a linguagem de implementao, versionamento, etc; informaes de qualidade, descrevendo as informaes necessrias para a garantia de qualidade do

165

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 identicao das pessoas responsveis pelo suporte tcnico do componente. Para outros artefatos especcos do MDD, os seguintes formatos podem ser utilizados: Para DSLs, deve-se incluir informaes sobre: 1. O subdomnio com o qual a DSL se relaciona; 2. A gramtica ou metamodelo utilizado; 3. Detalhes sobre a sintaxe concreta, tais como o signicado das guras, 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 subdomnio 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 suciente para serem compreendidas sem informao adicional; 2. Metamodelos ou DSLs de origem e destino; 3. Detalhes sobre o seu desenvolvimento, tais como as linguagens, tecnologias ou frameworks utilizados; e

166

4. Especicao 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. Especicao 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 renamento. Em outros casos, como a descrio e raciocnio do cdigo gerado, especicao dos parmetros para as transformaes e geradores de cdigo, as informaes precisam se denidas e detalhadas somente aps sua concluso.

7.3

Consideraes nais

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 nal desta atividade, tem-se um conjunto de artefatos reutilizveis, ou componentes, que implementam parte da arquitetura do domnio, linguagens especcas para os subdomnios, ferramentas que permitem criar modelos para estes subdomnios e transformaes modelo-modelo e modelo-texto capazes de gerar cdigo especco para a arquitetura do domnio. O Quadro 12 resume as atividades de implementao do domnio. O Quadro 13 descreve os produtos de trabalho da fase de implementao do domnio.

167
Atividades e sub-atividades ID.1. Caracterizao da variabilidade dos subdomnios Entradas PT.3.Validado. Modelagem do domnio PT.4.Validado. Candidatos a subdomnio PT.5. Histrico de decises incluso/excluso de subdomnios PT.9.Avaliado. Projeto do domnio PT.3.Validado. Modelagem do domnio PT.4.Validado. Candidatos a subdomnio PT.5. Histrico de decises incluso/excluso de subdomnios PT.9.Avaliado. Projeto do domnio PT.10. Subdomnios caracterizados Sadas PT.10. Subdomnios caracterizados sobre

ID.2. Denio das DSLs e do suporte ferramental (top-down) ID.2.1. Identicao das features iniciais da DSL ID.2.2. Denio da sintaxe abstrata ID.2.3. Denio da sintaxe concreta ID.2.4. Denio da integrao inter-DSL ID.2.5. Construo da ferramenta de modelagem especca de domnio ID.3. Desenvolvimento das transformaes e renamento 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. Renamento das DSLs ID.3.4. Desenvolvimento das transformaes e geradores de cdigo ID.4. Desenvolvimento do framework do domnio ID.5. Documentao do domnio

sobre

PT.11.Inicial. Linguagens especcas de domnio PT.12.Inicial. Suporte ferramental para DSLs

PT.3.Validado. Modelagem do domnio PT.4.Validado. Candidatos a subdomnio PT.5. Histrico de decises sobre incluso/excluso de subdomnios PT.9.Avaliado. Projeto do domnio PT.10. Subdomnios caracterizados PT.11.Inicial. Linguagens especcas de domnio PT.12.Inicial. Suporte ferramental para DSLs PT.14. Implementao de referncia PT.11.Renado. Linguagens especcas de domnio PT.12.Renado. Suporte ferramental para DSLs PT.13. Transformaes do domnio PT.15. Framework do domnio

PT.11.Renado. Linguagens especcas de domnio PT.12.Renado. Suporte ferramental para DSLs PT.13. Transformaes do domnio PT.14. Implementao de referncia

PT.15. Framework do domnio PT.16. Documentao do domnio

Quadro 12: 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.

168

Produto de trabalho PT.10. Subdomnios caracterizados

PT.11. Linguagens especcas de domnio

PT.12. DSLs

Suporte ferramental para

Descrio Denio do tipo de variabilidade caracterstico de cada subdomnio: baseada em features ou baseada em DSLs Denio das sintaxes abstrata e concreta das linguagens especcas de domnio para os subdomnios identicados 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

Estado Nenhum

PT.13. Transformaes do domnio

PT.14. referncia

Implementao

de

PT.15. Framework do domnio

PT.16. Documentao do domnio

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 identicadas 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 denidos e mecanismos que possibilitam a sua instanciao Documentao dos diferentes artefatos de implementao do domnio, incluindo componentes, DSLs, ferramentas, transformaes e geradores de cdigo

1. Inicial: verso da DSL produzida somente atravs de uma abordagem top-down. Normalmente faltam detalhes que s sero identicados aps a implementao 2. Renado: verso inicial da DSL renada aps uma abordagem bottom-up, que identica mais detalhes para a linguagem 1. Inicial: verso das ferramentas produzidas somente atravs de uma abordagem top-down. Normalmente faltam detalhes que s sero identicados aps a implementao 2. Renado: verso inicial das ferramentas aps uma abordagem bottom-up, que identica mais detalhes para a linguagem Nenhum

Nenhum

Nenhum

Nenhum

Quadro 13: Descrio dos produtos de trabalho da fase de implementao do domnio

169

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 9. 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 exige o gerenciamento dos mltiplos subdomnios que podem existir em um domnio, de modo a oferecer um grau de automao adequado. 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. A avaliao desta tese consistiu na realizao de estudos empricos envolvendo a aplicao da abordagem em projetos de engenharia de domnio, com o objetivo de fornecer evidncias ou indcios sobre sua validade. importante ressaltar que a avaliao realizada tem carter mais exploratrio, com alguns pontos que ainda precisam ser melhorados para que os resultados possam ser mais conveis, conforme discutido na Seo 8.6. Mas de qualquer forma, puderam ser extradas algumas concluses, como apresentado no nal deste captulo. A seguir so apresentados os detalhes sobre a avaliao realizada.

8.1

Denio

Para a denio dos estudos desta avaliao, foi utilizado o paradigma GQM (Goal-Question Metric) (BASILI; CALDIERA; ROMBACH, 1994). Neste paradigma, devem ser

170

denidos os objetivos da avaliao, que devem ser rastreados a um conjunto de dados que denem estes objetivos de forma operacional, e a interpretao destes dados com respeito aos objetivos denidos. O rastreamento entre os objetivos e os dados feito atravs de questes que caracterizam os objetivos de forma mais especca. Assim, seguindo o formato sugerido no GQM, so denidos dois objetivos para esta avaliao, assim descritos e detalhados por meio das respectivas questes especcas: 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 diculdades de utilizao do ponto de vista do pesquisador no contexto de projetos de engenharia de domnio. Q3 . Os participantes 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)? Q4 . Os participantes que utilizaram a abordagem tiveram diculdades 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 especicadas, isto no signica

171

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 identicar se a utilizao do MDD desde o incio traz mais problemas do que benefcios. Nesta avaliao, o projeto desenvolvido sem a abordagem consistiu na aplicao dos conceitos de reutilizao de software de forma ad hoc. Foram produzidos componentes de software reutilizveis e uma arquitetura de referncia para o domnio, porm sem a execuo de atividades especcas de um mtodo voltado reutilizao. Nos trs casos, a implementao obtida pelo desenvolvimento sem a abordagem foi aproveitada durante a atividade de desenvolvimento da implementao de referncia. Desta forma, o cdigo nal obtido com e sem a abordagem foi praticamente o mesmo.

8.1.1

Coleta de dados

Para a obteno de dados que possam conter indcios ou evidncias sobre estas questes, foram denidas 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. 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 denir o que signica aumento e/ou melhoria na reutilizao. A reutilizao ocorre de diversas maneiras, e dependendo do contexto, pode signicar 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 forma normalizada. Foram denidas formas de coleta de dados especcas para cada questo relacionada aos objetivos da avaliao, conforme apresentado

172

Existem diferentes mtricas voltadas reutilizao1 , que focam 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 especco. Assim, as seguintes mtricas foram denidas para a questo Q1 : M1 . Porcentagem de reutilizao (RP - Reuse Percent). Esta a mtrica mais bsica de reutilizao, sendo denida 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 reetiria a realidade de que apenas uma poro da classe foi reutilizada. A coleta desta mtrica envolve a identicao 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 modicados 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 modicado 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. M4 . Porcentagem de reutilizao gerada. Esta mtrica calcula a porcentagem de artefatos
1 Uma

reviso sobre mtricas para MDD e reutilizao apresentada no Captulo 9.

173

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 especicao e cdigo. Esta mtrica complementar anterior, e permite determinar a relao entre um elemento de especicao e o cdigo gerado correspondente. Por exemplo, se a especicao 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 especicao de um arquivo de congurao 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 especicao do modelo. Um elemento de especicao pode ser uma linha de texto (em uma DSL textual) ou um elemento grco de um diagrama, seja ele uma caixa, atributo, linha ou outro elemento grco similar. Para efeito de comparao, considera-se que uma linha textual aproximadamente equivalente a um elemento grco, pois apesar de o elemento grco ser mais simples de criar e editar do que uma linha de texto, ele normalmente possui propriedades que precisam ser conguradas 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, 2006c). 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, 2006c); e 2. Estas mtricas so aplicadas somente ao cdigo-fonte, no sendo teis para elementos Neste contexto, a

174

de modelagem. Como o objetivo comparar a quantidade de conhecimento que foi reutilizado na construo do software nal, a comparao dos cdigos razovel, uma vez que o tamanho de um mdulo reete 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 inuenciam a 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 denidas 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 modicado, isto , uma nica mudana inicia uma cascata de mudanas em diferentes mdulos. Alm disso, quando a extenso da mudana no pode ser prevista pelo projetista, seu impacto no pode ser estimado, o que diculta a estimativa de custos, tornando o software rgido. A mtrica de instabilidade de um mdulo (I) busca avaliar esta caracterstica do software, sendo denida da seguinte maneira: AE AA + AE

I=

Onde AA signica Acoplamento Aferente, ou seja, o nmero de classes fora deste mdulo que dependem de classes neste mdulo, e AE signica Acoplamento Eferente, ou seja, o nmero

175

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 especcos 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 modularizao de um sistema de software com o objetivo de se obter mdulos bem denidos, testveis e de fcil manuteno. Durante a dcada de 70, McCabe (1976) desenvolveu uma tcnica matemtica que prov uma base quantitativa para modularizao e identicao 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 uxo 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. M8 . ndice de Manutenibilidade. A manutenibilidade um atributo desejvel tanto como

176

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 modicar (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 denido da seguinte maneira (VANDOREN, 1997): IM = 171 5.2 ln(aveV ) 0.23 aveV (g ) 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 modelo, ou impresso de um determinado valor, so consideradas operadores;

177

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 especcas para modelos. Conforme demonstrado por Genero et al. (2007) e por Genero, Poels e Piattini (2008), a manutenibilidade de um modelo determinada principalmente por sua compreensibilidade. Neste sentido, os autores identicaram, 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 denidas 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 denido 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 denido na gramtica da linguagem. Essas 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 consequncia 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) e por Genero, Poels e Piattini (2008): 42, 63 + 40, 22 = 41, 425 2

NA =

178

NR =

13, 13 + 8, 88 + 8 + 8, 2 = 9, 595 4

Portanto, truncando-se estes valores, considerou-se neste estudo que modelos com menos de 41 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 participantes 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 participantes que utilizaram a abordagem, com perguntas que avaliaram se os benefcios almejados foram efetivamente percebidos e observados. Decidiu-se por uma entrevista ao invs de um questionrio, pois os estudos no envolveram um nmero muito grande de participantes, e desta forma houve mais exibilidade 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 denio das linguagens especcas de domnio, transformaes e geradores de cdigo? A descrio da variabilidade em cenrios (casos de mudana) facilitou a denio das linguagens especcas de domnio, transformaes e geradores de cdigo? A identicao de candidatos a subdomnio facilitou a identicao das reas do domnio a serem automatizadas? A identicao de candidatos a subdomnio facilitou a denio das linguagens especcas de domnio, transformaes e geradores de cdigo? O processo investigativo baseado em decises para incluso/excluso de subdomnios foi utilizado? Se sim, ele facilitou o processo de desenvolvimento dos artefatos do MDD? O uso das diretrizes e padres arquiteturais especcos para reutilizao e MDD facilitou o desenvolvimento dos artefatos do MDD e da arquitetura do domnio?

179

A etapa de avaliao arquitetural ajudou a identicar 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 participantes que utilizaram a abordagem tiveram diculdades que causaram prejuzo ao desenvolvimento, em termos de atrasos e curva de aprendizado? Para avaliar as diculdades de utilizao da abordagem, foram includas as seguintes perguntas, na entrevista realizada na questo Q3 , referente s diculdades percebidas pelos participantes: Quais foram as diculdades para o aprendizado da abordagem? Quais foram as diculdades para denio do modelo de features? Quais foram as diculdades para descrio da variabilidade em cenrios (casos de mudana)? Quais foram as diculdades para a identicao de candidatos a subdomnio? Quais foram as diculdades para realizar o processo investigativo baseado em decises para incluso/excluso de subdomnios? Cite outras diculdades percebidas durante a utilizao da abordagem de MDD desde o incio do desenvolvimento.

8.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 que estou errado. Com base nesta premissa cientca, comum trabalhar-se com a idia de uma hiptese nula, ou seja, dene-se como hiptese algo que o experimentador deseja rejeitar,

180

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 denidas 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 especicao 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 41 (M10 ) Nmero de Relacionamentos: NR 9 H0c : os participantes 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 participantes que utilizaram a abordagem tiveram diculdades que causaram prejuzo ao desenvolvimento, em termos de atrasos e curva de aprendizado. Para a parte H0a desta hiptese no foram denidos 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 denidas 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 suciente para avaliar a manutenibilidade. Assim, as comparaes de M9 e M10 foram feitas com os valores estabelecidos como referncia. Para as partes H0c e H0d no foi denida nenhuma mtrica, pois a anlise foi qualitativa.

181

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 denidas:

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 especicao 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 < 41 (M10 ) Nmero de Relacionamentos: NR < 9 H1c : os participantes 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 participantes que utilizaram a abordagem no tiveram diculdades que causaram prejuzo ao desenvolvimento, em termos de atrasos e curva de aprendizado.

8.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. Este primeiro estudo foi completamente desenvolvido a partir do zero para a avaliao, mas foi

182

o resultado da evoluo dos estudos utilizados como base para testar e renar as atividades da abordagem, conforme descrito na Seo 4.3. 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 cientcos, 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 especcos para este contexto, como DSLs, transformaes e geradores de cdigo. A seguir so apresentados mais detalhes sobre cada estudo.

8.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. Neste estudo, as linguagens especcas de domnio, geradores, a arquitetura e a implementao de referncia foram desenvolvidos a partir do zero, utilizando a abordagem denida 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 infraestrutura composta de artefatos de software gerados e no-gerados, em uma arquitetura em trs camadas. Foram desenvolvidas quatro linguagens especcas 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 congurao das features presentes no produto. Tambm foram desenvolvidas transformaes e geradores de cdigo que produzem aplicaes completas, segundo as especicaes dos

183

modelos. O Quadro 14 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) implementao de referncia Nmero de features do domnio Tecnologias de implementao 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

Tecnologias MDD

Quadro 14: Dados sobre o estudo envolvendo o domnio de autoria de contedo para Web

8.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 (LUCRDIO; JACKSON; SCHULTE, 2008). As principais caractersticas deste domnio so o alto grau de incerteza sobre a topologia da aplicao, a heterogeneidade dos ambientes e infraestrutura e o alto grau de cooperao entre os componentes distribudos. Este estudo 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 especcas 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 possuem, e uma linguagem visual para descrever a semntica das operaes de manipulao dos dados. O aspecto mais interessante desta especicao 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.

184

A teoria diz que possvel gerar cdigo responsvel pela execuo distribuda das operaes e vericao de integridade global do sistema, de acordo com regras especcas denidas 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 denidas 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 denida nesta tese, porm com menor foco na anlise, uma vez que j existiam verses iniciais das linguagens especcas de domnio. Aps o estudo das tecnologias de implementao envolvidas, estas verses iniciais das linguagens foram renadas, 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 infraestrutura 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 infraestrutura. O Quadro 15 resume alguns dados relevantes sobre este estudo.

8.2.3

Eventos cientcos

O terceiro estudo foi realizado tambm em ambiente industrial, e envolveu o domnio de eventos cientcos. Este domnio engloba sistemas de submisso e inscrio em eventos, 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 cientcos. 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 congurao. Assim, cada sistema vendido produz diferentes verses que implementam as diferentes variabilidades do domnio. A reutilizao

185
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) implementao de referncia Nmero de features do domnio Tecnologias de implementao Aplicaes distribudas baseadas em computao em nuvem 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)

Tecnologias MDD

Quadro 15: Dados sobre o estudo envolvendo o domnio de aplicaes distribudas baseadas em computao em nuvem ocorre recuperando-se uma determinada verso que seja prxima dos requisitos do cliente, e modicando-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 ; 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 cou 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.
material deste curso encontra-se disponvel no endereo http://www.icmc.usp.br/~lucredio/ downloads/files/cursoMDD/.
2O

186

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 infraestrutura 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 denidas duas linguagens especcas de domnio: uma linguagem textual para a denio das features, e a sua congurao atravs de atributos especcos para a linha de produtos, e uma linguagem textual para a denio de formatos de certicados, um subdomnio identicado pela equipe durante a anlise. Foram tambm construdos os geradores responsveis por congurar novos produtos e produzir cdigo customizado. O Quadro 16 resume alguns 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) implementao de referncia Nmero de features do domnio Tecnologias de implementao Tecnologias MDD Eventos cientcos Aptor Consultoria e Desenvolvimento de Software Ltda. 2 2 meses (dedicao parcial) 2 (congurao e certicados) 8 1375 71873 29 Adobe DreamWeaver, PHP, MySQL Eclipse (verso Ganymede) EMF (Eclipse Modeling Framework) JET (Java Emitter Templates)

Quadro 16: Dados sobre o estudo envolvendo o domnio de eventos cientcos

8.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.
3 http://metrics.sourceforge.net/ 4 http://www.virtualmachinery.com/jhawkprod.htm

187

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 diculdades. 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 atravs de grcos 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 denida por Fenton e Peeger (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.
5 https://net2java.dev.java.net/

188

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 sero includos ou excludos da anlise. Por exemplo, quando o elemento fora dos limites se tratar de cdigo-fonte, deve-se analisar se ele 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 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 modicados ou manipulados pelo desenvolvedor no foram includos nas mtricas. Porm, em alguns grcos, 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.

8.4
8.4.1

Resultados e discusso
Autoria de contedo para a Web

A Figura 28 mostra os valores das mtricas de reutilizao de software obtidas dos artefatos produzidos com e sem a abordagem. Nota-se um aumento signicativo tanto na porcentagem de reutilizao como na razo de reutilizao. porcentagem de reutilizao no desejada para zero. Analisando-se os dados, vericou-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 vericada uma razo entre especicao e cdigo de 1:16,34, ou seja, para cada elemento de especicao so geradas, em mdia, pouco mais de 16 linhas de cdigo. A Figura 29 mostra os valores das mtricas indiretas de reusabilidade: instabilidade, complexidade e manutenibilidade obtidas dos artefatos produzidos com e sem a abordagem. Pode-se vericar que no houve alterao signicativa nas distribuies da mtrica de Tambm pode-se observar a reduo da

189

Figura 28: Comparao entre as mtricas de reutilizao para o estudo do domnio de autoria de contedo para a web 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.

Figura 29: Comparao entre as mtricas indiretas de reusabilidade para o estudo do domnio de autoria de contedo para a web A Figura 30 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
neste grco, 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 grcos deste captulo.
6 Observao:

190

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.

Figura 30: 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 31 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).

Figura 31: 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 A Figura 32 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.

191

Figura 32: 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 Para os modelos, a manutenibilidade foi analisada atravs do nmero de atributos e de relacionamentos. Conforme mostra a Figura 33, os modelos utilizados para gerao de cdigo (metamodelos e modelos auxiliares) possuem poucos atributos, permanecendo completamente abaixo do limite considerado (41). Tambm possuem poucos relacionamentos, com o terceiro quartil sendo similar ao limite considerado (9). J os modelos utilizados como especicao possuem mais atributos e relacionamentos. A mdia do nmero de atributos coincide com o limite considerado (41), enquanto o nmero de relacionamentos tem distribuio bastante acima do limite considerado (9).

Figura 33: 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

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

192

primeira explicao a de que geradores produzem bastante cdigo redundante, e por isso o nmero de linhas naturalmente maior. Esta armao est prxima da realidade deste estudo, j que um dos itens importantes na identicao de candidatos a subdomnio a existncia de 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 mais complexo e difcil de ser mantido. A nica opo, portanto, seria copiar os trechos parecidos e modic-los manualmente, abordagem seguida no desenvolvimento tradicional. Em alguns casos, pode-se tentar aplicar tcnicas de refatorao de cdigo (FOWLER et al., 1999), mas estas so limitadas a somente alguns tipos de modicaes no cdigo. Analisando os artefatos produzidos, nota-se que, na maioria deles, exatamente esta tarefa de cpia e modicao 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 29), mas so particularmente ntidas quando se avalia os diferentes tipos de artefatos do MDD individualmente (Figuras 30, 31 e 32). 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 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 modicados 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

193

no efetivamente reutilizado no software nal, 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. Enm, 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 infraestrutura deste tipo. Em outras palavras, mais fcil e simples codicar do que especicar 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.

8.4.2

Aplicaes distribudas baseadas em computao em nuvem

A Figura 34 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 signicativo 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.

Figura 34: Comparao entre as mtricas de reutilizao para o estudo do domnio de aplicaes distribudas baseadas em computao em nuvem

194

A porcentagem de reutilizao obtida com gerao de cdigo neste estudo foi similar ao estudo anterior, atingindo 42,71%. A razo entre especicao e cdigo foi um pouco maior, atingindo 1:26,35, ou seja, os geradores deste estudo produzem mais cdigo para cada elemento de especicao do que os do estudo anterior. A Figura 35 mostra os valores das mtricas indiretas de reusabilidade: instabilidade, complexidade e manutenibilidade obtidas dos artefatos produzidos com e sem a abordagem. Pode-se vericar que no houve alterao signicativa nas distribuies das mtricas de instabilidade e ndice de manutenibilidade. A complexidade, por sua vez, apresentou uma discreta reduo.

Figura 35: Comparao entre as mtricas indiretas de reusabilidade para o estudo do domnio de aplicaes distribudas baseadas em computao em nuvem A Figura 36 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 37 analisa de forma mais aprofundada as medidas de complexidade ciclomtica 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). A Figura 38 analisa de forma mais aprofundada os ndices de manutenibilidade obtidos com a abordagem. No existem diferenas notveis na distribuio, porm h uma leve queda

195

Figura 36: Distribuies de instabilidade de mdulo nos diferentes tipos de artefatos produzidos com a abordagem, no domnio de aplicaes distribudas baseadas em computao em nuvem

Figura 37: Distribuies de complexidade ciclomtica nos diferentes tipos de artefatos produzidos com a abordagem, no domnio de aplicaes distribudas baseadas em computao em nuvem na manutenibilidade do cdigo gerado e nos artefatos de gerao, com relao ao cdigo gerado. A Figura 39 mostra que as quantidades de atributos de ambos os tipos de modelo (gerao e especicao) permaneceram abaixo do limite estipulado (41). O nmero de relacionamentos, porm, excedeu consideravelmente o limite (9) nos modelos de gerao, e de forma moderada no caso dos modelos de especicao. 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

196

Figura 38: 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 39: Distribuies de nmeros de atributos e relacionamentos nos modelos utilizados com a abordagem, no domnio de aplicaes distribudas baseadas em computao em nuvem

razo ainda maior entre especicao 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 gerao. Isto se explica pela complexidade natural do domnio, uma vez que a computao em nuvem traz muitos desaos 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 cam 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 especicar do que codicar.

197

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 diculdade de manuteno. Assim, enquanto no estudo anterior vericou-se que o uso da abordagem pode trazer benefcios em termos de volume de reutilizao, aqui observa-se que a abordagem pode simplicar o desenvolvimento, abstraindo detalhes e complexidades inerentes a este domnio complexo.

8.4.3

Eventos cientcos

A Figura 40 ilustra uma comparao entre os nveis de reutilizao obtidos com e sem a abordagem, para o estudo envolvendo o domnio de eventos cientcos. 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 modicados minimamente (reutilizao do tipo caixa-branca), como resultado do processo de customizao.

Figura 40: Comparao entre as mtricas de reutilizao para o estudo do domnio de eventos cientcos A porcentagem de reutilizao obtida com gerao de cdigo neste estudo foi bastante reduzida, sendo medida como 3,99%. A razo entre especicao e cdigo tambm foi signicativamente menor, atingindo 1:8,14, ou seja, os geradores deste estudo produzem menos

198

cdigo para cada elemento de especicao 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 41. Pode-se notar que, em termos de instabilidade, os artefatos deste estudo esto mais prximos aos do estudo envolvendo o domnio Web, porm ligeiramente menos instveis. Em termos de complexidade ciclomtica, a distribuio cou mais concentrada e ligeiramente superior que os outros estudos. O ndice de manutenibilidade se mostrou notavelmente inferior aos outros estudos.

Figura 41: Comparao entre as mtricas de reusabilidade dos estudos dos domnios de eventos cientcos (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 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 congurao de produtos adquiridos pelo cliente; Neste estudo, a automao conseguida com o MDD permitiu reduzir alguns problemas de
7O

contedo integral da entrevista encontra-se no Apndice C.

199

forma que no vinha sendo conseguida, por falta de tempo e diculdades em desenvolver uma soluo que atendesse a mltiplos clientes ao mesmo tempo; A equipe relatou diculdades no aprendizado das tecnologias de modelagem e gerao de cdigo, porm com relao abordagem citaram apenas que tiveram diculdades em compreender as funes especcas dos casos de mudana na abordagem. Segundo eles, no cou clara a necessidade de se criar mltiplos cenrios para descrever pequenas partes do problema; A equipe teve tambm diculdades na identicao correta das features, sendo necessria a presena constante do autor desta tese para orientar e corrigir as identicaes equivocadas. No geral, os participantes compreenderam os conceitos, mas tinham diculdade 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 identicao de subdomnios, 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 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 signicativa, 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 conguraes 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 diculdades com o aprendizado e treinamento, conforme citado pela prpria equipe. Alm disso, foram desenvolvidos poucos artefatos e uma baixa taxa

200

de reutilizao com gerao de cdigo (3,99%), devido principalmente falta de tempo e dedicao parcial dos participantes. Estes resultados so particularmente interessantes, pois representam a utilizao da abordagem em um cenrio mais tpico e prximo da realidade de uma organizao de software. 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 diculdade em se obter solues genricas que possam ser utilizadas por mltiplos clientes. Em muitos casos, as modicaes exigidas por um cliente no podem ser generalizadas e parametrizadas, pois a natureza das mudanas profunda, como por exemplo as diferentes formas de certicado, citadas como exemplo pela equipe. possvel criar um componente genrico capaz de gerar certicados 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 certicados de responsveis por sesses (chair de sesso). Nestes casos, a nica soluo encontrada era criar uma cpia do componente anterior e modic-la para o novo requisito. Com o MDD e a abordagem, a equipe conseguiu criar um suporte mais exvel para estas modicaes, 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, modicao e testes a cada congurao de um novo produto. Este espalhamento visvel nos dados coletados: no estudo realizado, em torno de 70 artefatos foram modicados em menos de 25%. Estas modicaes envolvem conguraes e customizaes, muitas delas duplicadas. Com a abordagem, foi possvel reunir grande parte dos parmetros de congurao em um nico modelo, e as modicaes pontuais e repetitivas so realizadas por geradores. Neste estudo, o modelo serve de entrada para conguraes em seis tabelas diferentes do banco, e quatro arquivos de congurao, que antes precisavam ser feitas individualmente. Alm disso, os geradores so mais conveis 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 congurao apenas.

201

8.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 ela rejeitada, pois nos trs estudos foram vericados aumento e/ou melhoria na reutilizao de software nos projetos utilizando a abordagem. 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 participantes dos estudos perceberam benefcios com a abordagem, e no tiveram diculdades signicativas no aprendizado. Mesmo para as hipteses nulas com indcios de rejeio, no se pode armar que as hipteses alternativas apresentadas na Seo 8.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 diculdades signicativas 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 diculdade de manuteno, conforme percebido no estudo do domnio Web. Tampouco ela as reduz, conforme percebido no estudo do domnio Aparentemente, h uma tendncia a produzir artefatos com de computao em nuvem.

instabilidade, complexidade e diculdade de manuteno acima da mdia, mas seguindo uma constante, e dependendo das caractersticas do domnio, isto pode ser vantajoso ou no. Este efeito ilustrado na Figura 42. Assim, uma possvel hiptese alternativa mais realista deve considerar as diferentes condies e cenrios dos domnios, conforme ilustra a Figura 43. 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 gerao de grande volume de cdigo. Em domnios tcnicos mais complexos, a abordagem simplica o desenvolvimento quando a codicao extremamente complexa. Em domnios de negcio, ela pode facilitar o processo de congurao e reduzir os problemas causados com a proliferao de verses. Esta hiptese alternativa resume muitas das experincias vivenciadas nesses trs estudos,

202

Figura 42: Efeito da abordagem na reusabilidade dos artefatos produzidos 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.

8.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 inuenciado negativamente os resultados, sendo uma ameaa sua validade, uma vez que tendo ele prprio desenvolvido a abordagem, no passou por diculdades em seu aprendizado, e provavelmente falhou em identicar 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 inuncia do pesquisador. As mtricas subjetivas foram coletadas diretamente dos participantes do terceiro estudo, e portanto tambm no foram inuenciadas. Vale mencionar tambm o fato de que a realizao dos estudos em ambiente industrial

203

Figura 43: Uma possvel hiptese alternativa elaborada a partir dos resultados da avaliao apresenta um menor grau de controle, uma vez que o desenvolvimento sofre inuncias 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, anal, 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. Devido tambm ao tamanho dos projetos, pode-se citar o fato de que a anlise de disperso e balanceamento das amostras permitiu identicar alguns poucos elementos fora da distribuio normal. Estes, porm, pouco inuenciaram os resultados. Em futuras replicaes deste experimento, pode-se optar por ignorar esta anlise sem muitos prejuzos aos resultados, caso os tamanhos dos projetos sejam similares aos aqui apresentados. A comparao de implementaes obtidas com e sem a abordagem pode tambm ter sofrido inuncia pelo fato de que a abordagem foi utilizada aps o desenvolvimento de uma implementao de exemplo. Nos dois primeiros estudos, essa implementao consistiu de

204

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 beneciado 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 diculdade 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, denidos e executados de forma mais exploratria,

sem a denio de variveis dependentes e independentes voltadas a uma anlise de correlao mais rgida. Por exemplo, os valores de referncia e margens de tolerncia citados servem mais como guia, e no como um indicador efetivo do efeito observado. Isto prejudica a sua capacidade de replicao, tanto no mesmo grupo como em grupos de pesquisa externos, mas tambm prejudica a relao causa-efeito, uma vez que no se pode armar que os efeitos observados so devidos utilizao da abordagem ou ocorreram por outros fatores no previstos. Assim, necessrio um maior detalhamento das variveis e aspectos envolvidos para transformar estes estudos em um experimento de carter exclusivamente cientco. Tambm no foi realizada nenhuma avaliao direta do processo. Somente foram

analisados os produtos (artefatos de software) desenvolvidos. Apesar destes sofrerem inuncia direta do processo, no se pode armar que os resultados observados so efetivamente causados pela abordagem, sem uma anlise mais dedicada de suas atividades e da execuo realizada. Ressalta-se tambm o fato de que o processo de identicao de cdigo reutilizado mas no referenciado, descrito na Seo 8.1.1, pode levar a falsos negativos. Por exemplo, podem existir mtodos sendo chamados dentro de blocos condicionais que nunca so acessados.

8.7

Consideraes nais

Neste captulo foi apresentada uma avaliao 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

205

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 identicao 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. Tambm foram identicadas 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 identicao dos subdomnios 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.

207

Trabalhos relacionados

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 foram apresentadas as principais abordagens da indstria para o MDD. Mas com a academia no diferente, sempre existindo o interesse cientco nessa rea, com trabalhos que discutem os conceitos tericos e a viabilidade dessa abordagem.

9.1

Abordagens orientadas a modelos para reutilizao de software

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 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 especcas 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

208

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 utilizar essa DSL. Por exemplo, considere um analista do domnio de jogos eletrnicos. Ele dene elementos como placar, comando, fase, jogador, entre outros, e os descreve utilizando regras gramaticais, que servem para a criao de um interpretador (parser). O analista de um sistema utiliza esses elementos para construir seu prprio jogo, criando elementos como Jogador 1, Jogador 2, comandoDireita, comandoEsquerda, etc. Uma possvel gramtica para essa DSL, onde um jogo envolve vrios jogadores, seria:

jogo jogador cor nome

: 'Jogo' nome ':' jogadores 'Fim'; : 'Jogador' nome 'Cor' cor; : 'verde'|'azul'|'branco'|'preto'; : '"' (a-zA-z)(a-zA-z0-9)* '"';

jogadores : (jogador)*;

Dessa forma, um novo jogo poderia ser denido por meio dessa linguagem, por exemplo:

Jogo "Damas" : Jogador "J1" Cor branco Jogador "J2" Cor preto Fim
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 executvel. o que acontece quando, por exemplo, se deseja obter um modelo orientado a objetos deste jogo, para posteriormente implement-lo utilizando uma linguagem de programao orientada a objetos. No Draco, as transformaes se baseiam nas regras gramaticais das linguagem dos domnios, interpretadas pelo seu prprio parser. Por isso necessrio existir uma gramtica para a linguagem de origem e uma gramtica para a linguagem destino. Neste caso, seria necessria uma gramtica para esse modelo orientado a objetos intermedirio, que poderia ser parecida com:

modelo

: 'modelo' '{' (classe)* (objeto)* '}';

209

classe atributo tipo nome objeto parametro

: 'classe' nome '{' (atributo)* '}'; : nome ':' tipo; : 'String'|'int'|'float'|nome; : (a-zA-z)(a-zA-z0-9)*; : 'objeto' nome ':' nome '(' ((parametro)(',' parametro)*)? ')'; : '"' (a-zA-z0-9)* '"';

Uma transformao automtica deste jogo para este modelo orientado a objetos poderia gerar algo como:

modelo { classe Jogador { nome: String cor: String } objeto objJ1:Jogador("J1","branco") objeto objJ2:Jogador("J2","preto") }
De forma similar, com base na denio do domnio para uma linguagem executvel, como por exemplo Java, poderia ser denida uma transformao que gerasse o seguinte cdigo para este jogo:

public class Jogador { private String nome; private String cor; public Jogador(String nome, String cor) { this.nome = nome; this.cor = cor; } } public class Main { public static void main (String args[]) {

210

Jogador objJ1 = new Jogador("J1","branco"); Jogador objJ2 = new Jogador("J1","preto"); } }

Esse processo chamado no Draco de ciclo de renamento bsico, e resumido na Figura 44.

Figura 44: Processo de renamentos sucessivos na abordagem Draco O processo dividido em duas fases distintas:

1. Na primeira fase, o analista do domnio, junto com o projetista do domnio, com base na experincia em sistemas similares e nas tcnicas existentes para modelagem e programao, constrem um conjunto de domnios. O domnio mais abstrato, ou seja, aquele mais prximo da linguagem do especialista, chamado de domnio do problema, ou domnio da aplicao. Os domnios intermedirios, responsveis pelos renamentos at o nvel executvel, so chamados de domnios de modelagem. No nvel mais baixo,

211

correspondente s linguagens de programao, esto os domnios executveis. Nessa primeira fase, tambm so denidas as transformaes de um domnio para outro; e 2. Na segunda fase, o analista de sistemas, com base nos requisitos de um sistema, cria uma descrio do sistema, de acordo com a linguagem do domnio do problema ao qual o sistema pertence. Essa descrio automaticamente transformada para descries nas linguagens de modelagem intermedirias, renando os modelos, os quais o projetista pode modicar para inserir requisitos no funcionais. Os renamentos se sucedem at produzir o sistema executvel.

Esse processo praticamente o mesmo para as abordagens de desenvolvimento orientado a modelos utilizadas atualmente, como por exemplo a abordagem denida nesta tese. A diferena est principalmente nas ferramentas para modelagem, criao e execuo das transformaes, j que atualmente essas so baseadas nos conceitos de metamodelagem, e no no uso de gramticas. Este, inclusive, pode ser um dos motivos pelos quais a abordagem Draco no se estabeleceu de fato como uma abordagem para o desenvolvimento de software orientado a modelos, uma vez que a construo de gramticas e transformadores baseados em regras gramaticais e compiladores mostrou-se muito complexa para ser aplicada na prtica (WEIS;
ULBRICH; GEIHS,

2003).

Alm disso, as abordagens atuais possuem tcnicas mais apuradas para captura e representao da variabilidade, alm de mecanismos de implementao mais consolidados. A abordagem denida nesta tese dene, por exemplo, padres de projeto com o objetivo de facilitar o gerenciamento da variabilidade no contexto do MDD. Outro diferencial desta tese com relao ao trabalho de Neighbors uma preocupao maior com as atividades necessrias para o gerenciamento de mltiplos subdomnios automatizados. No Draco, a idia de mltiplos domnios est mais intrinsecamente ligada a conceitos de linguagens de programao e de modelagem, e no com a diviso natural de um domnio de aplicaes, como nesta abordagem. Assim, a identicao de reas de interesse especcas para cada especialidade no domnio ca mais restrita existncia de linguagens especcas daquele domnio. J nesta abordagem, um subdomnio pode ser identicado mesmo sem a existncia de linguagens e/ou ferramentas dedicadas. Aps o trabalho de Neighbors, diversos esforos foram gastos em busca de uma melhor utilizao dos conceitos do MDD. Recentemente foi desenvolvido o projeto ModelWare, como parte do IST (Information Society Technologies), uma das prioridades do planejamento estratgico envolvendo a pesquisa tecnolgica realizada pela comunidade europia. Envolvendo

212

instituies de pesquisa e empresas de toda a Europa, o projeto ModelWare foi dividido em seis frentes de trabalho, descritas a seguir: Tecnologias de modelagem: o objetivo dessa frente prover a base terica e tecnolgica de suporte para os desaos do MDD na indstria. Envolve a denio de mecanismos para descrever arquiteturas e plataformas, transformaes de modelos, simulao de execuo de modelos, assim como mecanismos para especicar e empacotar componentes MDD. Dentre os principais resultados alcanados por essa frente de trabalho, destacam-se os pers para modelagem de arquiteturas e plataformas (MODELWARE, 2006a), e a denio do que seriam transformaes reutilizveis (MODELWARE, 2006b); Processos e metodologias: o objetivo dessa frente de trabalho prover um conjunto de prticas para engenharia e gerenciamento de um processo de desenvolvimento orientado a modelos. Dentre os resultados dessa frente, destaca-se um framework de processo para o MDD (MODELWARE, 2006e) e um modelo de maturidade MDD (MODELWARE, 2006d); Infraestrutura ferramental: nessa frente de trabalho, foram desenvolvidas ferramentas e ambientes para uma abordagem de desenvolvimento orientado a modelos. A infraestrutura baseada em cdigo aberto, contemplando as questes de integrao de ferramentas (MODELWARE, 2006g) e mecanismos de transformao (MODELWARE, 2006f); Adoo bem sucedida: uma das preocupaes desse projeto garantir que as tecnologias desenvolvidas sejam disseminadas e utilizadas na prtica pela indstria. Neste sentido, foram realizadas, como parte dessa frente de trabalho, demonstraes e propostas para padronizao (MODELWARE, 2006h); MDD industrial: essa frente de trabalho tem como objetivo validar os resultados obtidos pelas outras frentes de trabalho, na indstria; e Gerenciamento: diz respeito manuteno da estratgia do projeto em conformidade com o contrato inicial e com os objetivos inicialmente previstos. O projeto ModelWare grande e abrangente, com resultados expressivos, tais como o MOFScript e ATL, descritos na Seo 2.2.1. Esta tese se relaciona principalmente com a frente de processos e metodologias. O

framework de processo e modelo de maturidade MDD possuem grande correlao com algumas atividades da abordagem denida nesta tese. Uma comparao mais detalhada com o modelo de maturidade encontra-se no Apndice B.

213

Weis, Ulbrich e Geihs (2003) 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 genricas, mas sim especcas 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, dicultando 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. A abordagem desta tese tambm busca automatizar completamente as transformaes, de modo que no necessrio trabalho manual, o que poderia inibir o uso dos transformadores. Outro aspecto similar que tanto no trabalho de Weis, Ulbrich e Geihs (2003) como nesta tese, as transformaes devem ser especcas para cada caso. A idia aqui defendida que os transformadores devem ser customizados de acordo com os requisitos e com o contexto do domnio sendo construdo, da mesma forma que no mecanismo Kase. Existem dois pontos, no entanto, nos quais a presente abordagem difere do Kase: 1. Esta abordagem no est restrita a linguagens visuais, por entender que h subdomnios onde o nvel de abstrao da especicao deve ser mais baixo, aproximando-se das caractersticas e poder expressivo de uma linguagem textual; e 2. Nesta tese, as transformaes no se baseiam somente em regras de mapeamento, por dois motivos: (i) transformadores baseados em templates so mais simples de se construir e manter; e (ii) a necessidade da engenharia ida e volta reduzida com o uso de uma implementao de referncia e um processo de migrao de cdigo. Apesar de mais trabalhoso, esse caminho foi preferido por ser mais prtico. Czarnecki et al. (2005) 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.

214

Um template de modelo baseado em features consiste em modelos de features e modelos anotados que implementam as features. Cada anotao enriquece um modelo com informaes referentes s features, e podem ser na forma de condies de presena/ausncia, iteraes para expanso de templates ou expresses mais complexas para clculo de elementos de modelagem. Os modelos anotados ento representam como as conguraes de um produto de uma linha inuenciam na implementao da variabilidade correspondente. Uma variante consiste na instanciao das anotaes, e desta forma, possvel gerenci-la individualmente, de forma isolada. A abordagem desta tese utiliza o mesmo tipo de construes para implementao das variabilidades, porm, ao invs de templates de modelos, aqui so utilizados principalmente templates de cdigo, pois o objetivo produzir implementaes de forma mais direta, e no atravs de modelos intermedirios. Alm disso, nesta tese so denidas atividades para a construo dos templates e ligao no somente com modelos de features, mas tambm DSLs que representam variabilidades mais complexas em partes do domnio e/ou subdomnios. Knodel et al. (2005) apresentam uma abordagem para a utilizao de desenvolvimento orientado a modelos em linhas de produtos de software, chamada Pulse-MDD. O ponto central desta abordagem o foco na arquitetura da linha de produtos como objetivo do processo de MDD, e no na plataforma de destino (como J2EE, por exemplo). A diferena que com foco na arquitetura e nos produtos da linha, obtm-se maior grau de adequao ao domnio desejado, evita-se a ocorrncia de problemas relacionados com a necessidade de se oferecer suporte a possibilidades mais genricas que podem nunca ser necessrias organizao, facilitando o desenvolvimento. O Pulse-MDD dene atividades, realizadas como parte do projeto arquitetural, para a construo de geradores. Estas atividades buscam identicar padres recorrentes no domnio, para serem utilizados como base para os geradores. Visando obter um conjunto economicamente otimizado de padres, um processo iterativo identica um conjunto de padres e avalia a porcentagem de cdigo gerado alcanado a cada iterao. Em um certo momento, torna-se muito complexo identicar e implementar um padro na forma de geradores, e portanto o processo termina. Esta abordagem possui muitas similaridades com a abordagem desta tese, que tambm 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. O processo de criao dos geradores tambm similar, com

215

base em exemplos do cdigo a ser gerado, com a diferena de que no Pulse-MDD ele guiado pela identicao de padres e critrios econmicos, enquanto nesta tese o processo est centrado nos diferentes tipos de variabilidade. A principal diferena desta tese com relao ao Pulse-MDD que neste ltimo a preocupao com o MDD comea somente na fase de projeto, enquanto nesta abordagem argumenta-se que ela deve comear antes, durante a anlise, uma vez que os modelos de features possuem papel importante nesta denio, e normalmente precisam ser adaptados para reetir a existncia dos artefatos MDD. Alm disso, iniciando-se na anlise, a preocupao com o MDD pode incluir a identicao e diviso de subdomnios automatizveis. Segundo defende-se nesta tese, reconhecer esta diviso natural do domnio um requisito importante para possibilitar o uso do MDD em cenrios prticos. Deelstra et al. (2003) discutem como uma abordagem para o desenvolvimento de linhas de produtos pode se beneciar do desenvolvimento orientado a modelos. Os autores argumentam que o MDD pode levar a vrios benefcios, e apresentam como ele 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, como o caso desta tese. O mesmo acontece com outros trabalhos encontrados na literatura. Muitas abordagens que combinam o MDD com engenharia de domnio (ou linhas de produtos de software) possuem 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, EISENECKER,

2007; TRASK et al., 2006; TOLVANEN; KELLY, 2005; CZARNECKI; HELSEN;

2004b).

Uma das excees o mtodo Kobra (ANASTASOPOULOS; ATKINSON; MUTHIG, 2002). Originalmente projetado para desenvolvimento de sistemas individuais, o Kobra se integra bem a um mtodo voltado para linhas de produtos, como o Pulse-DSSA (ANASTASOPOULOS;
ATKINSON; MUTHIG,

2002). O Kobra possui atividades especcas para o projeto arquitetural

orientado a modelos. Os autores argumentam que dessa forma possvel obter independncia de plataforma, pois o Kobra se baseia em modelos UML para especicao, realizao e implementao de componentes de software no contexto de uma linha de produtos. Assim como a abordagem desta tese, o Kobra utiliza cenrios para viabilizar a criao

216

e avaliao de uma arquitetura para uma linha de produtos de software. Um diferencial do Kobra que ele apresenta critrios para priorizao de cenrios, tais como o seu valor econmico, esforo necessrio, entre outros. Nesta tese, a priorizao aberta, cando a cargo dos stakeholders denirem aqueles mais importantes a serem utilizados como diretrizes arquiteturais. No Kobra, so utilizados modelos UML, principalmente modelos de classes e de atividades, para especicao dos componentes, em diversos nveis de renamento. Os autores sugerem a utilizao de diagramas organizados de forma hierrquica, onde cada diagrama descreve um nico componente. A hierarquia dene o relacionamento entre eles, mostrando o domnio em diversos nveis, desde o contexto de sistema at os componentes individuais. Regras de relacionamento entre os diagramas denem de forma no ambgua como a relao entre os componentes deve ser implementada. Esta abordagem reete o fato de que o Kobra fortemente centrado no conceito de componentes de software, e como resultado a arquitetura e implementao esto descritos primariamente em termos dos seus componentes. Diferentemente do Kobra, nesta tese o uso de componentes no necessariamente obrigatrio como mecanismo de encapsulamento de conhecimento e implementao da variabilidade. Unidades de implementao de mais baixo nvel, como classes, podem existir tanto no nvel arquitetural como de implementao. Desta forma, acredita-se que possvel oferecer suporte mais exvel e detalhado variabilidade do domnio, para os casos onde componentes apresentam nvel de granularidade muito alto. Outra diferena entre esta tese e o mtodo Kobra que neste ltimo o paradigma do MDD somente parcialmente suportado, porque o mtodo s lida com a atividade de modelagem, no cobrindo as atividades de desenvolvimento de transformaes e geradores automatizados. Em contraste, o desenvolvimento de tais artefatos explicitamente denido na abordagem desta tese, por meio de princpios, diretrizes e atividades especcas. Blois (2006) desenvolveu uma abordagem de projeto arquitetural baseada em componentes no contexto de engenharia de domnio, cujo objetivo atender aos principais requisitos para possibilitar um processo adequado para a reutilizao de software. Segundo a autora, uma abordagem para engenharia de domnio baseada em componentes deve obedecer aos seguintes critrios: (i) Modelagem de variabilidades e opcionalidades em diferentes nveis de abstrao; (ii) Manuteno da ligao e consistncia entre os artefatos do domnio de diferentes nveis de abstrao; (iii) Organizao dos artefatos para a composio de elementos arquiteturais; (iv) Uso de princpios de DBC na modelagem de domnio; (v) Necessidade de processos de engenharia de domnio com apoio ao DBC; (vi) Gerao de cdigo fonte na linguagem de

217

programao empregada por uma tecnologia de DBC; e (vii) Modelagem e reutilizao de artefatos e modelos atravs de ferramental apropriado. Segundo essa pesquisa, os principais mtodos de ED e DBC no atendem a todos estes requisitos. Assim como o Kobra, o trabalho de Blois (2006) fortemente baseado no conceito de componentes de software, ou seja, visa produzir artefatos reutilizveis que, segundo a denio de Sametinger (1997) utilizada, so autocontidos, claramente identicveis, que descrevem ou realizam uma funo especca e tm interfaces claras, documentao apropriada e um grau de reutilizao denido. Como resultado deste foco, a implementao obtida com a abordagem est tambm fortemente associada a uma tecnologia de componentes, como EJB (Enterprise JavaBeans), por exemplo. A autora prope, alm de um processo de ED com foco em DBC, uma notao similar UML para representao da variabilidade no domnio, que vai alm da mais comumente utilizada notao de features, podendo tambm ser utilizada em outros modelos, como modelos de classes, casos de uso e componentes. Tambm estabelece heursticas de apoio atividade de mapeamento entre as caractersticas do domnio e os demais artefatos de anlise e projeto, alm de critrios para agrupamento de componentes, visando a gerao de elementos arquiteturais. O processo apoiado por ferramentas que auxiliam sua execuo e aplicam tcnicas da MDA para gerao automtica de cdigo. A abordagem desta tese tem os mesmos objetivos de reutilizao que o trabalho de Blois (2006), porm no se restringe a uma tecnologia de componentes. Aqui o foco reconhecer uma maior diversidade de tecnologias de implementao e subdomnios, buscando oferecer suporte do MDD para produzir uma implementao que aproveite os diferentes potenciais de automao de cada subdomnio. Por estar direcionado a uma plataforma de implementao mais homognea, o trabalho de Blois (2006) possui a vantagem de denir de forma mais sistemtica suas atividades, principalmente com relao ao projeto da arquitetura de referncia e a gerao de cdigo. J nesta tese, as atividades so mais vagas, exigindo maior trabalho de adaptao por parte do engenheiro de software. Por exemplo, no h heursticas para o mapeamento entre artefatos de anlise e projeto e nem para auxiliar na identicao dos elementos arquiteturais. Alm disso, so necessrias diversas atividades exclusivamente dedicadas ao projeto de DSLs, transformaes e geradores, pois aqui a plataforma de implementao pode ser qualquer uma, e no necessariamente uma plataforma de componentes. Em contrapartida, a abordagem desta tese possui maior potencial de automao, com uma srie de atividades dedicadas exclusivamente ao gerenciamento dessa diversidade dentro de um domnio. Na realidade, ambas as abordagens so de certa forma complementares. Uma vez

identicados os subdomnios, pode-se analisar onde o DBC deve ser utilizado, e ento aplicar as tcnicas propostas por Blois (2006) para mapear as suas caractersticas e projetar esta parte

218

da arquitetura do domnio utilizando uma tecnologia de componentes. A integrao desses componentes com o restante do domnio pode ento ser realizada conforme denido nesta tese. 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. Em particular, busca-se renar os modelos de caso de uso de forma que cada um esteja associado a somente uma feature, visando facilitar e automatizar as tarefas de engenharia de requisitos durante a congurao de produtos. Adicionalmente, a rastreabilidade entre as features e os demais modelos de requisitos armazenada de acordo com um metamodelo dedicado. Regras de composio entre os casos de uso so utilizadas para identicar os pontos de variao, de maneira similar ao conceito de casos de mudanas utilizado nesta tese. Uma regra de composio identica o que muda, em termos de comportamento, de um caso de uso para outro. Como cada caso de uso est associado a uma feature, e as features so rastreveis aos casos de uso e modelos derivados, estas regras permitem a gerao automtica dos modelos de requisitos de acordo com as features selecionadas para um determinado produto. Nesta tese, a variabilidade dos cenrios representada por meio de casos de mudana, que constituem cenrios isolados, e no informaes sobre o que muda de um cenrio para outro. Apesar de no possibilitar a automao, como no caso da abordagem de Alferez et al. (2008), o uso de cenrios individuais facilita a sua utilizao como diretrizes arquiteturais e a avaliao arquitetural. Foi por este motivo, para facilitar o projeto arquitetural, que a abordagem de casos de mudana foi adotada nesta tese. Outra diferena que a abordagem de Alferez et al. (2008) busca aplicar MDD para gerao de modelos de requisitos para serem utilizados na fase de desenvolvimento de aplicaes, sendo portanto mais completa no contexto de linhas de produtos. Nesta tese, o foco somente na engenharia de domnio, sendo que a fase de desenvolvimento de aplicaes no abordada. Por este motivo, o uso do MDD se restringe somente gerao de implementao, no passando pelos passos anteriores de anlise e projeto das aplicaes. 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. So denidas 32 regras de mapeamento que transformam casos de uso, classes, atributos e relacionamentos de modelos de anlise, em modelos arquiteturais seguindo o estilo arquitetural conhecido como C2

219

(PREZ-MARTNEZ; SIERRA-ALONSO, 2006). A exemplo dos geradores baseados em templates utilizados nesta tese, o mapeamento proposto por Prez-Martnez e Sierra-Alonso (2006) utiliza regras imperativas, mais simples de implementar, mas mais complicadas quando se deseja promover rastreamento e realizar a transformao ida-e-volta. Os modelos de destino so descritos utilizando um perl UML2 desenvolvido exclusivamente para o C2, uma vez que a UML sozinha no capaz de representar todos os elementos deste estilo, como por exemplo conectores, portas, mensagens, etc. Diferentemente desta tese, porm, o trabalho de Prez-Martnez e Sierra-Alonso (2006) assume que os modelos de anlise so ricos o suciente para serem automaticamente transformados em uma arquitetura. A abordagem desta tese defende a idia de que necessrio trabalho manual e criativo considervel entre anlise e projeto arquitetural, de forma a incluir as preocupaes de todos os stakeholders. Assumindo-se um nico e pr-denido mapeamento, corre-se o risco de se projetar uma arquitetura incapaz de atender a todos os requisitos de forma adequada. Alm disso, um nico estilo arquitetural (C2) suportado. Finalmente, a abordagem de Prez-Martnez e Sierra-Alonso (2006) focada no desenvolvimento de produtos nicos, no cobrindo aspectos relativos reutilizao, como suporte variabilidade e derivao de produtos, como o caso desta tese. 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 losoa da abordagem desta tese, tais como o suporte aos dois tipos principais de variabilidade: baseada em features (congurao) 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 Vlter e Groher que aqui proposta uma abordagem sistemtica, com atividades e diretrizes concretas para desenvolver a infraestrutura de reutilizao orientada a modelos para o domnio. Alm disto, a abordagem desta tese tambm identica a necessidade do suporte simultneo a mltiplos subdomnios, o que no mencionado por Vlter 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, tornando-se uma transformao reutilizvel. O sistema baseia-se no monitoramento do ambiente de programao para detectar automaticamente as modicaes feitas pelo desenvolvedor em algum artefato de cdigo. Estas so ento registradas como operaes de

220

mudanas, sendo posteriormente convertidas em entidades de primeira classe que descrevem como os elementos da AST (Abstract Syntax Tree ou rvore de Sintaxe Abstrata) de um programa (como as classes, atributos, mtodos e outras construes da linguagem) so modicados pelo desenvolvedor. No passo de generalizao, o sistema tenta identicar automaticamente o papel de cada mudana na transformao. Por exemplo, se uma mudana modica 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 renar esta generalizao em um editor personalizado, renomeando parmetros, especicando 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 identicao das mudanas no automatizada, sendo realizada completamente pelo desenvolvedor. Alm disso, esta tese foca na engenharia de domnio, com o objetivo de produzir transformaes projetadas especicamente 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 rena 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 modicaes 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.

221

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 congur-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 renamentos 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 codica 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 especco. Este modelo ento utilizado em conjunto com um framework de linguagem para produzir ferramentas concretas para a nova linguagem. Utilizando estas ferramentas, o desenvolvedor de aplicaes pode especicar 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 especicao 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 exibilidade 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),

222

com cardinalidades de features e atributos, entre outras (Seo 3.1.1), permitem a especicao 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 identicao 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 identicao de variabilidades mais detalhadas e a construo de transformaes e geradores de cdigo mais precisos no suporte variabilidade.

9.2

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 conabilidade 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 identicar 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.5, onde compara-se a abordagem desta tese com um modelo de maturidade em MDD.

223

Monperrus et al. (2008) argumentam que o custo para se coletar mtricas em um projeto orientado a modelos extremamente alto, devido especicidade a um domnio, o que impede que sejam utilizadas mtricas genricas. Como consequncia, necessrio desenvolver ferramentas especcas 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 especcas de domnio, com base em especicaes formais das mtricas a serem utilizadas. Especialistas do domnio especicam quais mtricas so necessrias, seguindo um metamodelo denido 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 especca de domnio para a denio 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 denio de mtricas tambm inclui aes que representam modicaes nos modelos, de 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 denio de nenhuma mtrica especca 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 de seu 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 identicada 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 vericadas 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 inuncia na manutenibilidade de diagramas de classes UML, particularmente os relacionamentos de associao e generalizao. Estas mtricas foram adaptadas e utilizadas

224

nesta tese, durante os estudos de caso, conforme descrito no Captulo 8. Pilgrim (2008) apresenta algumas mtricas para determinar o nvel de abstrao de um modelo. O objetivo avaliar a ecincia 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 ecincia 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 denem as seguintes mtricas: mtodos ponderados por classe (WMC - Weighted Methods per Class); profundidade da rvore de herana (DIT - Depth of Inheritance Tree); nmero de lhos (NOC - Number Of Children); acoplamento entre classes (CBO - Coupling Between Object classes); resposta 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, diculdade 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 8. 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 modicao 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 sequncia. Porm, a validade destas mtricas no apresentada neste trabalho. Nesta tese, no foi possvel aplicar estas mtricas, uma vez que elas

225

esto xadas 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 sequncia, classes no chamadas em diagramas de sequncia, 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 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, 2006c). Foram denidas 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 identicao 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); frequncia de reutilizao (RF - Reuse Frequency) (FRAKES; TERRY, 1994); tamanho e frequncia de reutilizao (RSF - Reuse Size and Frequency)

226

(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.

9.3

Consideraes nais

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. Apesar de esta tendncia ser natural e, academicamente, mais seguro, ainda existem espaos para contribuies que resultem da investigao conjunta das duas linhas. 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 trabalhos acadmicos na rea de desenvolvimento orientado a modelos e reutilizao de software, e que possuem alguma interseo com a abordagem desta tese. Tambm foram discutidos trabalhos relacionados com a avaliao realizada, e que serviram de base para a denio das mtricas utilizadas nesta tese.

227

10 Concluses

Reutilizao de software um objetivo constantemente procurado por pesquisadores e prossionais 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 prossionais altamente qualicados. 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 prossionais desta rea perceberem os erros e diculdades 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 decincias e limitaes relacionadas ao desenvolvimento de software.

10.1

Principais contribuies

Nesta dissertao busca-se resolver parte do problema da reutilizao atravs do desenvolvimento orientado a modelos. Aps estudos e pesquisas nas reas relacionadas, foi denida 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 contribuies foram feitas nesta rea:

228

Uma abordagem sistemtica e bem denida, contendo atividades, entradas e sadas que detalham as tarefas necessrias para que a engenharia de domnio possa incorporar as tcnicas do desenvolvimento orientado a modelos. Em particular, foi denido um mtodo concreto para identicao de mltiplos subdomnios, incluindo diretrizes de apoio e um processo investigativo, interativo e iterativo, adequado natureza incerta e evolutiva desta rea; Identicao de um conjunto de diretrizes e padres arquiteturais focados especicamente nos problemas da reutilizao e desenvolvimento orientado a modelos, visando possibilitar o gerenciamento de mltiplos subdomnios durante o projeto arquitetural; Realizao de estudos empricos. A literatura apresenta pouca evidncia quantitativa sobre os benefcios do MDD s organizaes de software (MOHAGHEGHI; DEHLEN, 2008). Assim, os resultados deste estudo so relevantes no somente para avaliar a abordagem denida nesta tese, mas tambm para a comunidade cientca e industrial interessada em aplicar o MDD; e Elaborao de um material de treinamento em MDD, utilizado nos estudos de caso, mas que pode ser reaproveitado em cursos de extenso, minicursos e tutoriais em eventos relacionados.

10.2

Lies aprendidas

As contribuies citadas so de carter cientco 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, apresentada em 2005, previa o desenvolvimento de parte das ferramentas necessrias para a aplicao do MDD. Na poca em que esta dissertao foi escrita, em 2009, 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 e ser cada vez mais presente na realidade do desenvolvimento de software.

229

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 em MDD deste importante instituto de pesquisa. Durante as apresentaes e seminrios no nal do estgio, realizadas pelo autor desta tese, muitos dos participantes ali presentes estavam vislumbrando os conceitos do MDD pela primeira vez, inclusive importantes pesquisadores e funcionrios desta grande empresa 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 cientcos 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 unicar 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 frequentemente necessrias adaptaes ou interpretaes indiretas para se extrair concluses relevantes.

10.3

Limitaes e Trabalhos futuros

Foram tambm identicadas, como subproduto desta pesquisa, oportunidades para trabalhos futuros, seja para complementar esta pesquisa explorando limitaes e/ou aspectos que no puderam ser investigados nesta tese, ou para iniciar novas investigaes em reas

230

identicadas como sendo decitrias de contribuies. Assim, os seguintes pontos podem ser investigados futuramente: Desenvolvimento com reutilizao: a presente abordagem no prev atividades para o desenvolvimento com reutilizao. Apesar de os resultados da engenharia de domnio poderem beneciar o desenvolvimento de software, h uma srie de desaos envolvidos na reutilizao dos produtos da ED. Assim, a sequncia mais direta deste trabalho a investigao do processo de desenvolvimento com reutilizao, ou seja, como produzir aplicaes que reutilizam os artefatos desenvolvidos com a abordagem desta tese de forma a maximizar a reutilizao e fazer uso efetivo das linguagens, transformaes e geradores de cdigo produzidos. Neste cenrio, um processo semelhante, envolvendo anlise, projeto e implementao, deve ser realizado. Porm, este trabalho deve denir exatamente os passos e atividades necessrios para que os esforos realizados durante a engenharia do domnio possam ser reutilizados, como por exemplo: ao realizar a anlise dos requisitos, deve-se considerar que j existem modelos de features, casos de uso e de mudana para o domnio. Como identicar quais modelos do domnio se adequam aos requisitos da aplicao? Qual o procedimento a ser realizado caso exista um requisito que no foi includo na anlise do domnio? Vale a pena tentar renegociar com o cliente os requisitos da aplicao de forma a promover maior reutilizao? Alm disso, tanto o projeto como a implementao das aplicaes devem considerar possveis adaptaes e/ou inseres de novos artefatos. Neste contexto, o controle de congurao deve ser uma atividade indispensvel; Replicao dos estudos empricos: outra limitao desta tese a avaliao. Sabe-se que difcil realizar experimentos em engenharia de software, visto que h uma srie de fatores a serem controlados. Por exemplo, as mtricas utilizadas no so uma medida precisa da reutilizao e reusabilidade dos artefatos produzidos. Alm disso, foi realizada somente uma avaliao dos produtos (artefatos) da abordagem, no havendo preocupao com a avaliao do processo. Todos estes fatores contribuem para que a validade dos resultados seja questionada. Assim, visando melhorar a validade das concluses, pode-se realizar novos experimentos envolvendo a denio mais precisa dos seus elementos e operacionalizando-os, por exemplo, com equipes maiores. Estes trabalhos poderiam ser realizados, inicialmente, como iniciao cientca, posteriormente evoluindo para um mestrado, visando incluir melhorias e correes na abordagem, com base nos resultados; Reutilizao de outros tipos de artefatos: nesta tese no foi feita distino com respeito ao tipo de artefato sendo gerado. No h atividades ou diretrizes especcas para o

231

desenvolvimento de transformaes que geram outras coisas alm do cdigo-fonte, como outros modelos, arquivos de congurao, 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. Este poderia ser o tema de um trabalho de mestrado; Especializao da abordagem para domnios especcos: outra limitao desta tese que a abordagem um pouco vaga em algumas atividades, como aquelas para a denio das DSLs, por exemplo. Idealmente, deveria-se buscar um processo mais sistemtico, de forma a reduzir as possibilidades de erros e interpretaes erradas. Porm, em alguns casos no foi possvel denir mais detalhes pela prpria natureza criativa do processo de criao de software. Trabalhos futuros, principalmente de mestrado, poderiam explorar a aplicao da abordagem em diferentes domnios, visando detalhar mais algumas atividades conforme as caractersticas destes domnios. Durante esta aplicao, poderiam ser identicadas heursticas que facilitem principalmente as atividades de projeto arquitetural voltado para o MDD, construo de DSLs, transformaes e geradores de cdigo especializados para um determinado domnio; Assistncia contextualizada automatizada: esta outra possibilidade de trabalhos futuros. A abordagem no oferece nenhum tipo de ajuda no sentido de acompanhamento de processo, com base no contexto da tarefa atual ou de outras informaes relevantes, como por exemplo a necessidade de aplicao de um padro ou estilo arquitetural. Neste possvel trabalho futuro, a partir de sugestes sobre quais atividades a serem realizadas em um contexto particular, como por exemplo a exibio automtica de ajuda especca 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 Tecnologias complexas envolvidas com o desenvolvimento das linguagens e ferramentas especcas de domnio, transformaes e adaptao manual de cdigo gerado. 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. Este poderia ser o tema de um trabalho de mestrado e/ou doutorado, dependendo da sua abrangncia; Colaborao no MDD: o desenvolvimento orientado a modelos possui diferentes tarefas
1 http://msdn.microsoft.com/en-us/architecture/blueprints.aspx

232

que envolvem a participao de mltiplos membros de uma equipe, tais como a anlise de features e a denio 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 exibilizao 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. Este poderia ser o tema de um trabalho de mestrado e/ou doutorado, dependendo da sua abrangncia; 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 (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 diculdades 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, podendo ser realizados como um ps-doutoramento na rea.

10.4

Consideraes nais

Nesta dissertao apresentou-se a tese de que o MDD pode aumentar e/ou melhorar a reutilizao de software em projetos de engenharia de domnio, descrevendo uma abordagem para esta nalidade 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. A principal contribuio est em reconhecer a existncia de mltiplos subdomnios, cada um com seu potencial de automao, e em oferecer um mtodo concreto para que o engenheiro de software possa lidar com eles.

233

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 denir atividades de suporte e de gerncia, alm de outras prticas de engenharia no cobertas pela abordagem. Esta dissertao apresenta os resultados de uma pesquisa aplicada, que busca unicar 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 solidicar e formalizar contribuies que ainda apresentam falhas e falta de detalhes sobre as diversas formas de desenvolvimento produtivo de software.

235

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. ALMEIDA, E. S. C.R.U.I.S.E - Component Reuse In Software Engineering. In: . [S.l.]: 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. p. 93100. ALMEIDA, E. S. et al. A systematic approach to design domain-specic 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. p. 6671. 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. v. 4039, p. 4357. 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. p. 7281. AMBLER, S. W. Agile model driven development is good enough. IEEE Software, v. 20, n. 5, p. 7173, 2003. 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. ANASTASOPOULOS, M.; GACEK, C. Implementing product line variabilities. In: Symposium on Software Reusability (SSR). Toronto, Canada: [s.n.], 2001. p. 109117.

236

ANTKIEWICZ, M.; CZARNECKI, K. Framework-specic 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 Specications & Design. Pittsburgh, Pennsylvania, United States: [s.n.], 1999. p. 152159. ARBOLEDA, H.; CASALLAS, R.; ROYER, J.-C. Dealing with constraints during a feature conguration process in a model-driven software product line. In: SPRINKLE, J. et al. (Ed.). Proceedings of the 7th OOPSLA Workshop on Domain-Specic 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), p. 178183. BAHNOT, V. et al. Using domain-specic modeling to develop software dened radio components and applications. In: The 5th OOPSLA Workshop on Domain-Specic Modeling, San Diego USA. [S.l.: s.n.], 2005. p. 3342. 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 inuences 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.; 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. 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. BIERHOFF, K.; LIONGOSARI, E. S.; SWAMINATHAN, K. S. Incremental development of a domain-specic language that supports multiple application styles. In: GRAY, J.; TOLVANEN, J.-P.; SPRINKLE, J. (Ed.). 6th OOPSLA Workshop on Domain-Specic Modeling (DSM06), Portland, Oregon USA. [S.l.]: Jyvskyl University Printing House, Jyvskyl , Finland, ISBN: 951-39-2631-1, ISSN: 1239-291X, 2006. p. 6778.

237

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. BLOIS, A. P. T. B. Uma Abordagem de Projeto Arquitetural Baseado em Componentes no Contexto de Engenharia de Domnio. Tese (Tese de Doutorado) Universidade Federal do Rio de Janeiro, 2006. 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.). Proceedings of the twenty-second IEEE/ACM international conference on Automated software engineering. [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 Especco. Tese (Doutorado) USP Universidade de So Paulo, So Carlos - SP, 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. 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-Specic Visual Languages - Tampa Bay, USA. [S.l.]: Jyvskyl University Printing House, Jyvskyl , Finland, ISBN: 951-39-1056-3, ISSN: 0359-8470, 2001. p. 8386. 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.

238

COOK, S. et al. Domain-Specic 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 Denition (http://hillside.net/patterns/denition.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 Conguration. [S.l.], 2004. Disponvel em: <http://www.ece.uwaterloo.ca/ kczarnec/TR04-11.pdf>. CZARNECKI, K.; HELSEN, S.; EISENECKER, U. Staged conguration using feature models. In: NORD, R. L. (Ed.). Proceedings of the Third Software Product Line Conference. Boston, MA: Springer, 2004. (LNCS 3154), p. 266283. 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.

239

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-specic 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. p. 342358. ECLIPSE. The Eclipse Modeling Framework (EMF) Overview. [S.l.]: Eclipse website, 2005. ECLIPSE. Eclipse Modeling Framework FAQ. 2006. 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 dening domain-specic visual languages. In: Proceedings of the 1st OOPSLA Workshop on Domain-Specic Visual Languages - Tampa Bay, USA. [S.l.]: Jyvskyl University Printing House, Jyvskyl , Finland, ISBN: 951-39-1056-3, ISSN: 0359-8470, 2001. p. 111124. EZRAN, M.; MORISIO, M.; TULLY, C. Practical Software Reuse. [S.l.]: Springer, 2002. FEILKAS, M. How to represent models, languages and transformations? In: GRAY, J.; TOLVANEN, J.-P.; SPRINKLE, J. (Ed.). 6th OOPSLA Workshop on Domain-Specic Modeling (DSM06), Portland, Oregon USA. [S.l.]: Jyvskyl University Printing House, Jyvskyl , Finland, ISBN: 951-39-2631-1, ISSN: 1239-291X, 2006. p. 169176.

240

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. Language Workbenches: The Killer-App for Domain Specic Languages? [S.l.]: martinfowler.com, 2005. Disponvel em: <http://www.martinfowler.com/articles/languageWorkbench.html>. Acesso em: 14 jun 2009. FOWLER, M. et al. Refactoring: Improving the Design of Existing Code. [S.l.]: Addison Wesley, 1999. 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, p. 125141, 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. p. 139148. 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. 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. p. 294299. 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. p. 6174. 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. GENERO, M.; POELS, G.; PIATTINI, M. Dening 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.

241

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 specication of measurements and redesigns for domain specic 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-specic visual modeling languages. In: In: Proceedings of the 2nd Workshop on Domain-Specic 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 Denition of Round-Trip Engineering. [S.l.], 2003. Department of Computer and Information Science, Linkpings Universitet, SE-581 83, Linkping, Sweden. HESSELLUND, A.; CZARNECKI, K.; WASOWSKI, A. Guided development with multiple domain-specic 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: Denitions 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, p. 407423, 1996. 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.

242

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 specication 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. p. 11881195. KANG, K. et al. Feature-Oriented Domain Analysis (FODA) Feasibility Study. [S.l.], 1990. Technical Report CMU/SEI-90-TR-21 - Carnegie Mellon University/Software Engineering Institute. KANG, K. et al. FORM: A Feature-Oriented Reuse Method with domain-specic 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. Fraunhofer IESE Tech Report 015.03/E.

243

KICZALES, G. et al. Aspect-oriented programming. In: 11st European Conference Object-Oriented Programming (ECOOP97). Finland: Springer Verlag, 1997. (LNCS, v. 1241), p. 220242. KIM, M.; YANG, H.; PARK, S. A domain analysis method for software product lines based on scenarios, goals and features. In: Tenth Asia-Pacic 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. [S.l.: s.n.], 2007. ISBN not assigned. KNODEL, J. et al. An efcient 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. 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-specic 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.

244

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. LISBOA, L. B. ToolDAy - A Tool for Domain Analysis. Dissertao (Mestrado) Federal University of Pernambuco, Recife, Pernambuco, Brazil, 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. p. 7279. LUCRDIO, D. et al. Performing domain analysis for model-driven software reuse. In: 10th International Conference on Software Reuse. Beijing, China: Springer-Verlag, 2008. (Lecture Notes in Computer Science, v. 5030), p. 200211. LUCRDIO, D.; JACKSON, E. K.; SCHULTE, W. Playing with re: Harnessing the hottest technologies for ultra-large-scale systems. In: 15th Monterey Workshop - Foundations of Computer Software, Future Trends and Techniques for Development, September 24-26, 2008, Budapest University of Technology and Economics. [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 Specication 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. p. 7277.

245

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. 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-specic 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. MODELWARE. Architecture and Platform Modelling Proles. [S.l.], 2006. MODELWARE. Denition of Reusable Transformations. [S.l.], 2006. Disponvel em: <http://www.modelware-ist.org/)>. Acesso em: 14 jun 2009. MODELWARE. Engineering Metrics Denition. [S.l.], <http://www.modelware-ist.org/)>. Acesso em: 14 jun 2009. MODELWARE. MDD Maturity Model. [S.l.], <http://www.modelware-ist.org/)>. Acesso em: 14 jun 2009. MODELWARE. MDD Process Framework. [S.l.], <http://www.modelware-ist.org/)>. Acesso em: 14 jun 2009. 2006. 2006. 2006. Disponvel Disponvel Disponvel em: em: em:

MODELWARE. Model Transformation Tool Suite - Prototype. [S.l.], 2006. Disponvel em: <http://www.modelware-ist.org/)>. Acesso em: 14 jun 2009. MODELWARE. ModelBus: Functional & Technical architecture document (Vols I and II). [S.l.], 2006. Disponvel em: <http://www.modelware-ist.org/)>. Acesso em: 14 jun 2009. MODELWARE. Standards Proposals Submitted. [S.l.], <http://www.modelware-ist.org/)>. Acesso em: 14 jun 2009. 2006. Disponvel 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.

246

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. 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. MOORE, B. et al. Eclipse Development using the Graphical Editing Framework and the Eclipse Modeling Framework. [S.l.]: ibm.com/redbooks, 2004. 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-specic modeling environment for a family of thick-client gui components. In: The 5th OOPSLA Workshop on Domain-Specic Modeling, San Diego USA. [S.l.: s.n.], 2005. p. 514. 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. Tech Report 051.02/E - Fraunhofer IESE. 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), p. 313329. 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.

247

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 Specication. [S.l.], 2005. Disponvel em: <http://www.omg.org>. Acesso em: 14 jun 2009. OMG. Catalog of UML Proles Specications. 2006. Disponvel em: <http://www.omg.org>. Acesso em: 14 jun 2009. OMG. Meta Object Facility Core Specication Version 2.0. [S.l.], 2006. Disponvel em: <http://www.omg.org>. Acesso em: 14 jun 2009. OMG. XML Metadata Interchange (XMI) Specication. [S.l.], 2006. Disponvel em: <http://www.omg.org>. Acesso em: 14 jun 2009. OMG. Unied Modeling Language (OMG UML) Infrastructure. [S.l.], 2007. Disponvel em: <http://www.omg.org>. Acesso em: 14 jun 2009. 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. Tech Report 057.02/E - Fraunhofer IESE. 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. p. 126138.

248

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. 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>. Acesso em: 14 jun 2009. 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.

249

SAMETINGER, J. Software Engineering with Reusable Components. Berlin Heidelberg: Springer-Verlag, 1997. SANTOS, A. L.; KOSKIMIES, K.; LOPES, A. Automated domain-specic 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. 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. STARS Technical Report STARS-VC-A025/001/00, Lockheed Martin Tactical Defense Systems, Manassas VA. 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. Unisys STARS Technical Report,Advanced Research Projects Agency (ARPA) STARS Technology Center, 801 N. Randolph St. Suite 400, Arlington VA 22203. STEFFEN, B. et al. Model-Driven Development with the jABC. In: Hardware and Software, Verication 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. Technical paper ISSN:1103-1581, Blekinge Institute of Technology, Sweden, 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.

250

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-Specic Modeling: How to Start Dening 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-Specic Visual Languages - Tampa Bay, USA. [S.l.]: Jyvskyl University Printing House, Jyvskyl , Finland, ISBN: 951-39-1056-3, ISSN: 0359-8470, 2001. p. 135140. TOLVANEN, J.-P.; KELLY, S. Dening domain-specic 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-Specic 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 dened 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-specic 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. p. B61B634. VLTER, M. MD* Best Practices. December 2008. Disponvel em: <http://www.voelter.de>. Acesso em: 14 jun 2009.

251

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. p. D31D354. 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>. Acesso em: 14 jun 2009. 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 exible software factory using partial domain specic models. In: Proc. of The 6th OOPSLA Workshop on Domain-Specic Modeling. [S.l.: s.n.], 2006. p. 1522. 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. p. 285294. 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.

253

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, identica as partes que lhe sero teis, e copia para o local onde est trabalhando, realizando as modicaes necessrias para integr-lo ao novo contexto. Analisando-se esse processo cotidiano, pode-se identicar 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

254

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, congurando-o por meio de parmetros ou de mecanismos de extenso ou mesmo modicando seu cdigo manualmente; e Integrao: a integrao normalmente consiste em modicar 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 modicado, necessrio test-lo novamente para garantir que as modicaes 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 especcas 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

255

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 conveis de uma maneira controlvel e eciente. 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 denido, sendo que desde o primeiro workshop de DBC, em 1998 em Kyoto, vrias denies foram apresentadas, cada uma evidenciando um aspecto especco do componente. Um conceito bastante satisfatrio apresentado por Szyperski (1999): um componente de software uma unidade de composio com interfaces bem especicadas em contrato e dependncias explcitas do contexto. Um componente de software pode ser independentemente implantado e pode ser composto por terceiros. As interfaces bem especicadas so importantes para formar uma camada comum entre o reutilizador (uma pessoa que utiliza o componente) e o desenvolvedor do componente. As dependncias explcitas denem 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 sucientemente 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) dene 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 identicados por Krueger (1992) tambm esto presentes nessa

256

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 polimorsmo. Tambm podem ser criadas descries em linguagem natural que permitam ao desenvolvedor identicar 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 (LUCRDIO; ALMEIDA; PRADO, 2004); Adaptao: a adaptao do componente normalmente feita por meio de sua parametrizao, na qual o reutilizador especica 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 modicado internamente. Neste caso, se o esforo necessrio para essa modicao for muito grande, pode ser mais vantajoso tentar renegociar com o cliente os requisitos da aplicao do que modicar 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 modicao na aplicao.

Diferentemente da abordagem copiar e colar, um componente, ao ser reutilizado, no precisa ser novamente testado caso no tenha sido modicado. Alm disso, a existncia de uma interface bem denida, assim como os mecanismos de classicao e busca, fazem com que o desenvolvedor no precise conar tanto em sua memria para encontrar um componente candidato reutilizao.

257

Linguagens especcas de domnio O termo Linguagem Especca de Domnio (DSL Domain-Specic Language) exige ateno especial, pois se baseia em uma noo muito vaga, que a palavra Domnio, utilizada com diferentes signicados em diferentes reas. Para esclarecer o conceito de domnio considerado nesta pesquisa, a Figura 45 apresenta um exemplo da situao clssica vivida durante o processo de anlise de sistemas.

Figura 45: Situao clssica da anlise de sistemas O desenvolvimento de sistemas envolve normalmente a captura do conhecimento de um especialista de alguma rea (no exemplo, um especialista nanceiro) 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 nanceiros, isto , Aes, ndices e Cotaes, esto dentro da rea de competncia e conhecimento do especialista nanceiro. Este , portanto, o domnio nanceiro. 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 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

258

dos termos do domnio nanceiro 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 especcas para uma mesma rea de conhecimento. Assim, o domnio nanceiro, por exemplo, no contexto da reutilizao de software, compreende todas as aplicaes nanceiras. A partir dessa denio, uma linguagem especca 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 especcas de um domnio, normalmente se est querendo dizer linguagens especcas de um domnio de problema. Dessa forma, chega-se seguinte denio (DEURSEN; KLINT; VISSER, 2000). Uma linguagem especca de domnio uma linguagem de programao ou uma linguagem de especicao 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 denio, uma linguagem do domnio nanceiro 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 ns de congurao, por exemplo. Um arquivo XML de congurao de acesso a banco pode ser visto como uma especicao em uma DSL, pois ele contm termos e conceitos associados ao problema de
A acesso a banco de dados. Outro exemplo so os processadores de texto do tipo L TEX, 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 especco daquele domnio. A seguir discute-se esse tipo de uso para DSLs. Linguagens especcas de domnio so mais uma expresso da dicotomia entre abordagens

259

genricas (que oferecem solues para mltiplas reas, porm de forma no otimizada), e abordagens especcas (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 especcos 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 especcas para um domnio de problema, de forma que o desenvolvedor, ao reutilizar essas subrotinas, tambm reutiliza conhecimento especco 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 subrotinas sendo chamadas pela aplicao, os frameworks normalmente esto no controle, sendo os responsveis por chamar o cdigo especco da aplicao; e 3. Linguagens especcas 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 nal 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 denir funes e bibliotecas como uma forma de se construir uma DSL para um problema (FOWLER, 2005).

260

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. destacam-se (DEURSEN; KLINT; VISSER, 2000): Dentre as vantagens,

DSLs permitem que solues sejam expressas nos termos e no nvel de abstrao do domnio do problema. Consequentemente, especialistas do domnio podem compreender, validar, modicar, ou mesmo desenvolver seus prprios programas; Programas DSLs so concisos, auto-documentados, e podem ser reutilizados com diferentes propsitos; DSLs aumentam a produtividade, conabilidade, manutenibilidade e portabilidade; DSLs incorporam conhecimento sobre o domnio, e portanto possibilitam sua conservao e reutilizao; 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 diculdade de se denir um escopo adequado para uma DSL; A diculdade de se balancear entre especicidade ao domnio e linguagens de programao genricas; e

261

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, conabilidade, 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 eciente 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 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 especcas de forma bastante razovel. Os pers 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, dicultando 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.

262

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 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 denidos na prpria linguagem, com os quais o desenvolvedor adiciona detalhes especcos da situao; e Integrao: por m, 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.

1 http://www.isis.vanderbilt.edu/projects/gme/ 2 http://www.eclipse.org/gmf/

263

Programao generativa

Programao generativa (generative programming) a automao da manufatura de produtos intermedirios e nais (i.e., componentes e aplicaes.) (CZARNECKI; EISENECKER, 2000). Essa denio resume o conceito de programao generativa, que vem sendo utilizado desde os primrdios da computao. Signica 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 especica a interface visualmente, e todo o cdigo que a implementa automaticamente gerado. Caso precise realizar alguma modicao, o desenvolvedor a realiza diretamente no editor visual, e o cdigo que reete 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 infraestrutura, aproveitando-o em atividades mais importantes, como anlise e projeto. 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 especicaes de forma mais prxima ao problema, o que exige um menor esforo de especicao. Essa DSL pode ser to especializada quanto o necessrio para o problema sendo modelado.
3 http://msdn.microsoft.com/vstudio/ 4 http://www.netbeans.org/

264

Por exemplo, para modelar um produto matemtico, a DSL precisa ser bem especca, 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-denida que representa o artefato nal semi-concludo, com pontos em aberto que podem ser preenchidos atravs de variveis especicadas pelo desenvolvedor. Um dos problemas da programao generativa ocorre quando se deseja modicar os artefatos gerados. Por mais genrico e exvel que seja o gerador, o artefato gerado pode no corresponder exatamente s necessidades do desenvolvedor. Neste caso, o desenvolvedor pode modicar o gerador, para atender s suas necessidades, ou modicar o artefato gerado. Modicar o gerador pode ser uma tarefa custosa. Normalmente os geradores so

ferramentas especcas para um determinado domnio de problema, de forma que introduzir modicaes 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 modicar, mas em todos os artefatos que sero gerados a partir de ento. Por outro lado, modicar o produto do gerador muito mais fcil, pois pode-se trabalhar diretamente no artefato que se deseja modicar. 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 especicaes de origem. Dessa forma, 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 modicaes por meio do editor visual. Essa abordagem, porm, restrita aos casos onde se pode bloquear modicaes sem perder a exibilidade 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):

265

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 denio do formato de entrada do gerador, seja ele uma DSL visual, textual, ou mesmo parmetros que preenchem um ou mais templates. Essa denio corresponde parte visvel da abstrao, com a qual o desenvolvedor trabalha. A parte escondida ca 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 classicao 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, conforme demonstram Allilaire et al. (2006), que 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 especicao 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 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, especicando o que for necessrio para que o gerador possa realizar essa integrao sozinho. Porm, essa a situao ideal. Em outros casos, a nica soluo modicar manualmente os artefatos gerados de forma a promover sua integrao.

266

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 especcas 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 reete 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 uxo de controle (DEURSEN; KLINT;
VISSER,

2000), (JOHNSON, 1997a) apud (BRAGA, 2002).

Estruturalmente, pode-se denir 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. Do ponto de vista de seu propsito, pode-se denir 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 dene 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 signicativo em reutilizao (KRUEGER, 1992).

267

A utilizao de um framework normalmente feita por meio de seus pontos variveis (hotspots), que so os pontos que denem 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 modicao, 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 classicao 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 o sistema operacional ou um banco de dados especco. 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:

268

Abstrao: a abstrao ocorre quando as solues recorrentes so generalizadas e representadas segundo um formato especco. 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 modicados; 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.

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
5 http://hillside.net/patterns/onlinepatterncatalog.htm

269

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, modicaes 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 modicaes 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 modicaes; Adaptao: a adaptao corresponde s mudanas sendo efetuadas nos artefatos recuperados. Os mesmos so modicados 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). O Quadro 17 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.

270

Abstrao Encapsulamento e utilizao de interfaces bem denidas e busca ou

Seleo Navegao automtica

Adaptao Parametrizao modicao interna

Integrao Acoplamento de interfaces providas com requeridas

Desenvolvimento Baseado em Componentes (DBC) Linguagens Especcas de Domnio (DSL) Programao Generativa Consulta gramtica ou manual da linguagem Escolha de um gerador apropriado Produo da entrada do gerador Parmetros linguagem denidos na Automatizada atravs de um compilador

Anlise de um domnio de problema

Denio do formato de entrada

Frameworks Escolha do adequado framework

No existe quando gerado um programa completo. Porm, podem ser necessrias modicaes, quando gerada apenas parte de um programa Normalmente no um problema, pois o framework uma aplicao semi-pronta Adaptao do restante do sistema De forma gradual, o sistema reconstrudo aos poucos, com cada mdulo sendo integrado separadamente

Padres Busca por um padro para um determinado problema Seleo dos artefatos a serem modicados

Reengenharia software

de

Representao do domnio, destacando os pontos variveis e ganchos Generalizao de solues recorrentes Engenharia Reversa

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

Quadro 17: Resumo das principais tcnicas relacionadas aos conceitos bsicos da reutilizao de software

271

APNDICE B -- 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 denido pela iniciativa ModelWare (MODELWARE, 2006d). Tambm discute-se a relao entre esses modelos de maturidade e a abordagem denida nesta tese. Em cada prtica indicado um smbolo, sendo que o smbolo est presente na abordagem, e o smbolo 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 denidas 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; indica que a prtica indica que a prtica est ausente da abordagem. Uma

breve explicao, destacada em negrito, descreve o raciocnio por trs da presena ou ausncia

272

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; AP2 - Planejamento de reutilizao: deve ser realizado de acordo com um procedimento pr-denido 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 identicado 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 denio de seu modelo do ciclo de vida; AP3 - Denio dos objetivos da reutilizao: assim como a estratgia adotada, a denio 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 denidos, 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 denio dos objetivos da reutilizao; AP4 - Implementao do domnio: visa produzir artefatos de software

reutilizveis para o domnio, atravs de codicao, testes, documentao e empacotamento destes artefatos. Envolve basicamente a denio 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 - Denido: 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; AP5 - Controle e monitoramento do processo de reutilizao: deve ser realizado atravs de um conjunto de mecanismos e mtricas que determinam o status

273

das atividades, e um conjunto de polticas e um plano de aes, responsveis pelo controle do processo. A abordagem no dene nenhum mecanismo ou atividade para controle e monitoramento do processo; AP6 - Integrao com o ciclo de vida do software: so denidas atividades, sub-atividades e produtos de trabalho institucionalizados para a organizao, com base em um modelo de referncia. Tambm importante a denio de um procedimento para a cooperao entre os desenvolvedores e a equipe de reutilizao. Esta prtica consiste justamente na denio desta abordagem e seus elementos; AP7 - Anlise de domnio: envolve a seleo e denio do domnio, anlise das aplicaes existentes para identicao das caractersticas do domnio, denio dos requisitos e escopo do domnio, identicao e documentao dos pontos variveis e comuns, e a identicao e documentao de restries adicionais entre as caractersticas do domnio. A abordagem possui uma fase especca para a anlise de domnio voltada para o MDD; AP8 - Projeto de domnio: envolve a denio de uma arquitetura de referncia para o domnio, que dene 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; 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; AP10 - Gerenciamento da unidade de reutilizao: inclui principalmente o estabelecimento de um comit de reutilizao, com um lder, e suporte e nanciamentos providos por uma alta gerncia comprometida. Este comit deve possuir regras e responsabilidades bem denidas, ser composto de membros bem treinados e motivados, e possuir canais de comunicao com a organizao. A

274

abordagem no dene uma unidade dedicada reutilizao; AP11 - Programa de mtricas: denio 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 dene nenhum tipo de mtrica de controle de andamento do processo, ou controle de qualidade; AP12 - Programa de avaliao organizacional: envolve a denio, 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 dene nenhuma atividade com este objetivo; AP13 - Avaliao da qualidade dos artefatos: envolve a denio de um modelo de qualidade, que dene 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; 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

275

necessidades futuras em termos de artefatos reutilizveis, e uma anlise de mercado para se avaliaram questes de investimento em reutilizao; AP15 - Otimizao do processo de reutilizao: envolve a identicao 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; AP16 - Controle de qualidade dos artefatos: um passo alm da avaliao da qualidade, com objetivos especcos 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; AP17 - Previsibilidade dos artefatos reutilizveis: consiste na identicao 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; 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 supercial, e se resume a uma pesquisa com base em conhecimento dos especialistas, sem atividades especcas para determinao de custos e retorno de investimento. Modelo de maturidade em MDD (MODELWARE, 2006d) Nvel 1 - Modelagem ad hoc: neste nvel, apenas o desenvolvimento tradicional realizado. Prticas de modelagem so utilizadas apenas esporadicamente ou nunca. No existem prticas denidas 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 especcos de plataforma;

276

ENG1 - Decidir sobre convenes de modelagem: consiste na identicao e seleo das convenes de modelagem a ser utilizadas pela equipe de desenvolvimento. Para isso, denido 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 denidos 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; 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; ENG2 - Desenvolver modelo tcnico: o modelo tcnico descreve os

principais mdulos do software, incluindo elementos independentes e especcos 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 especco de modelo, e portanto pode ser utilizada para desenvolver modelos tcnicos; 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; 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 dene atividades especcas para gerao de documentao; Nvel 3 - MDD Inicial: neste nvel introduz-se uma separao entre modelos de negcio

277

(independentes de plataforma) e especcos de plataforma. O objetivo manter os aspectos de implementao independentes dos aspectos de negcio, de modo a melhorar a ecincia do processo de desenvolvimento. Neste nvel, as prticas e artefatos do MDD so institucionalizadas, e um processo denido para o MDD utilizado pela organizao; ENG5 - Desenvolver modelo independente de plataforma: um modelo independente de plataforma reete os requisitos do sistema sem utilizar conceitos especcos da plataforma. Os requisitos so documentados de acordo com as tcnicas de modelagem estabelecidas na organizao. A abordagem no est focada em um tipo especco de modelo, e portanto pode ser utilizada para desenvolver modelos independentes de plataforma; ENG6 - Desenvolver transformaes tcnicas modelo-para-texto: as

transformaes devem ser desenvolvidas com base nos metamodelos de origem e destino. A denio das transformaes com base na sintaxe concreta (por exemplo, XMI) so insucientes pois elas limitam a transformao a apenas uma sintaxe concreta. Para isso, decide-se sobre qual linguagem de transformao utilizar, so identicados os metamodelos de origem e destino, so denidas 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; ENG7 - Vericar modelos: a vericao de modelos inclui a checagem dos requisitos, para determinar se esto completamente e adequadamente reetidos nos modelos. A abordagem no dene atividades para vericao de modelos; PJM2 - Modelar o processo de MDD do projeto: normalmente, cada organizao tem um processo de desenvolvimento implantado, que modicado 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 denio 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; PJM3 - Aplicar o processo estabelecido: consiste na utilizao do processo denido, e obteno de mtricas para controle de sua execuo. Uma organizao

278

pode aplicar a abordagem, mas no foram denidas mtricas para gerenciar e controlar sua execuo, e portanto esta prtica no est completamente satisfeita; PJM4 - Denir, coletar e analisar mtricas do projeto: as mtricas devem estar ligadas aos objetivos do projeto. O foco deve ser nas atividades especcas do MDD, como qualidade arquitetural, corretude dos modelos, etc. A abordagem no dene nenhuma atividade referente denio, coleta e anlise de mtricas; 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 dene nenhum tipo de repositrio para o MDD; SUP2 - Denir tcnicas padronizadas de modelagem e critrios de qualidade: envolve a denio de um padro de modelagem para a organizao, que representa a evoluo das convenes de modelagem denidas no nvel 2. Tambm envolve a denio de critrios de qualidade de modelos, como completude de modelo, consistncia inter-diagramas, legibilidade, etc. A abordagem apenas contm atividades, passos e diretrizes, sem denir tcnicas padronizadas ou critrios de qualidade; SUP3 - Checar aplicao das prticas: consiste em vericar 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 dene maneiras de controle sobre a aplicao de suas prticas; SUP4 - Denir mtricas padronizadas e procedimentos de coleta e anlise de dados: envolve a denio de mtricas para as atividades de modelagem, para os modelos, como coletar as mtricas e como analisar os dados. A abordagem no dene 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 especcos de plataforma so separados em elementos do MDD, atividades de modelagem so integradas, e garante-se um desempenho de modelagem eciente; ENG8 - Desenvolver metamodelo centrado na arquitetura: envolve

a identicao das principais entidades que fazem parte da arquitetura, os

279

relacionamentos entre estas entidades, e a linguagem de metamodelagem a ser utilizada. Por m, 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; 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 especca. A abordagem no est focada em um tipo especco de modelo, e portanto pode ser utilizada para desenvolver metamodelos independentes de plataforma; 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 especco de modelo, e portanto pode ser utilizada para desenvolver modelos de negcio; ENG11 - Desenvolver transformaes modelo-para-modelo: consiste na identicao dos metamodelos de origem e destino, padres de transformao entre os modelos de origem e destino, denio 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; ENG12 - Manter rastreabilidade entre modelos: signica manter ligaes ou mapeamentos explcitos entre modelos, aps o resultado de uma transformao. Envolve a denio 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 congurao 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; ENG13 - Integrar desenvolvimento de produto com desenvolvimento de infraestrutura para uma famlia de produtos: esta prtica s aplicvel nos

280

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; 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 vericao do comportamento modelado de um sistema. Requer a existncia de uma especicao formal das aes, em uma linguagem semntica de aes. No existem atividades especcas para simulao de modelos; SUP5 - Estabelecer e manter limites de desempenho de modelagem da organizao: a organizao deve denir 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 especco de automao, visando dosar o nvel de automao em cada projeto; 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 especco de automao, visando dosar o nvel de automao em cada projeto; Nvel 5 - MDD Denitivo: 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 especcas de domnio so criadas e continuamente atualizadas; ENG15 - Desenvolver linguagens especcas de domnio: linguagens

especcas 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 identicao dos principais conceitos

281

do domnio, denio do glossrio do domnio, seleo da linguagem e denio da DSL, atravs de uma ferramenta. A abordagem possui uma atividade especca para o desenvolvimento de DSLs no contexto da reutilizao; ENG16 - Vericar e validar produtos com base nos modelos: a vericao e validao realizada atravs de modelos para teste e validao. Estes modelos (e seus metamodelos correspondentes) capturam os requisitos do sistema, e a vericao ocorre diretamente nos modelos. Desta forma, erros so detectados e corrigidos diretamente nos modelos. Vericao e validao de modelos esto fora do escopo da abordagem; PJM6 - Estabelecer e manter artefatos de modelagem de software estratgicos para o MDD: consiste na identicao 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; 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.

283

APNDICE C -- Reproduo na ntegra da entrevista referente ao estudo emprico envolvendo o domnio de eventos cientcos

A seguir apresentada, na ntegra, a entrevista realizada como parte do estudo emprico envolvendo o domnio de eventos cientcos:

P:O modelo de features ajudou na denio das linguagens especcas de domnio, transformaes e geradores de cdigo? R:A equipe reportou que algumas features foram utilizadas diretamente na denio inicial do modelo de congurao, pois descreviam diferentes opes de congurao 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 denio das linguagens especcas 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 caram mais claras, porm a equipe relatou que no conseguiu

284

identicar uma relao direta entre os casos de mudana e um modelo ou um gerador, como aconteceu para o modelo de features. A equipe cou um tanto surpresa em notar tantas modicaes que eram feitas em seus produtos (de forma ad hoc) que foram desenvolvidos para atender o domnio cientco, 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 identicao de candidatos a subdomnio facilitou a identicao das reas do domnio a serem automatizadas? R:Sim, os participantes enfatizaram que conseguiram identicar pelo menos oito subdomnios onde a automao iria ajudar em suas tarefas: congurao dos arquivos de cdigo-fonte (incluindo instalao), banco de dados, relatrios, gerao de crachs, gerao de certicados, congurao de boleto bancrio, congurao de idiomas suportados (incluindo idioma padro) e processamento de arquivos de pagamento do banco (retornos nanceiros). Estes subdomnios consistem principalmente de pontos particularmente problemticos e trabalhosos para congurao manual, j conhecidos pela equipe aps sua experincia com atendimento a seus clientes. Segundo a equipe, o uso do modelo de features facilitou na identicao destes pontos. P:A identicao de candidatos a subdomnio facilitou a denio das linguagens especcas de domnio, transformaes e geradores de cdigo? R:Com relao a esta questo, a equipe salientou que a diviso em subdomnios facilitou na denio 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 subdomnios exige tambm mltiplas etapas na gerao de cdigo, j que cada gerador precisa ser executado separadamente para cada subdomnio, o que diculta quando necessrio gerar cdigo repetidas vezes. P:O processo investigativo baseado em decises para incluso/excluso de subdomnios 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 subdomnios, sem que os

285

demais pudessem ser investigados. P:O uso das diretrizes e padres arquiteturais especcos para reutilizao e MDD facilitou o desenvolvimento dos artefatos do MDD e da arquitetura do domnio? R:A equipe reportou diculdades 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 identicao das diretrizes de variabilidade baseada em features de forma isolada para cada subdomnio facilitou o desenvolvimento da camada de dados de features utilizada pelos geradores especcos. A unicao de arquivos de congurao 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 identicar 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 prossionais, 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 congurao 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.

286

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 congurao 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 diculdades 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 certicados 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 subdomnios de certicados, 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 diculdades 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 diculdade no aprendizado destas tecnologias P:Quais foram as diculdades para o aprendizado da abordagem? R:A equipe relatou diculdades no aprendizado das tecnologias de modelagem e gerao de cdigo, porm com relao abordagem citaram apenas que tiveram diculdades em compreender as funes especcas dos casos de mudana na abordagem. Segundo eles, no cou clara a necessidade de se criar mltiplos cenrios para descrever pequenas partes do problema.

287

P:Quais foram as diculdades para denio do modelo de features? R:A equipe teve diculdades na identicao correta das features, sendo necessria a presena constante do autor desta tese para orientar e corrigir as identicaes equivocadas. No geral, os participantes compreenderam os conceitos, mas tinham diculdade em reproduzi-los no domnio em questo, inserindo constantemente e de maneira equivocada, mdulos e funes como sendo features. P:Quais foram as diculdades para descrio da variabilidade em cenrios (casos de mudana)? R:A equipe identicou que a principal diculdade 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 diculdades para a identicao de candidatos a subdomnio? R:Uma vez que o modelo de features estava nalizado, a equipe rapidamente identicou candidatos a subdomnio 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 identicao. Assim, no foram relatadas diculdades nesta etapa. P:Quais foram as diculdades para realizar o processo investigativo baseado em decises para incluso/excluso de subdomnios? R:A equipe no chegou a realizar mais de uma iterao neste processo, tendo optado por incluir dois subdomnios em uma nica iterao. Portanto, no soube responder esta questo de forma adequada. P:Cite outras diculdades percebidas durante a utilizao da abordagem de MDD desde o incio do desenvolvimento. R:A equipe tambm citou as diculdades referentes operao do ambiente de desenvolvimento, uma vez que no existe muita documentao a respeito destas tecnologias.