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.