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

1 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

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

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

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

5 Anlise de domnio orientada a modelos

5.1 5.2 5.3

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

86 87

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

6 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

7 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

8 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

9 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 ttsrtst

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 ttrtrstrts

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 ttsrts 5 ttrtsr

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 ttsr

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 ttsrt 8 ttsrtt 10 DSLs

9 ttsrtsrt

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 ttrttrrr 12 ttsr 13 ttssrtrts

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

15 tttqtsrrt

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

16 ttrstt 17 ttrt

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