Home

A Model-Driven Software Reuse Approach (in portuguese)

1. de reutiliza o Raz o de reutiliza o E Sem abordagem E Com abordagem 0 00 Figura 28 Compara o entre as m tricas de reutiliza o para o estudo do dom nio de autoria de conte do para a web instabilidade A complexidade por sua vez aumentou de forma percept vel com muitos artefatos desenvolvidos com a abordagem sendo mais complexos do que o m ximo obtido sem a abordagem Os ndices de manutenibilidade tamb m sofreram uma redu o com o uso da abordagem Instabilidade de M dulo Complexidade Ciclom tica ndice de Manutenibilidade 1 200 16 000 x 200 000 14 000 TUN 150 000 T i 12 000 it 0 800 q 10 000 100 000 0 600 t 8 000 E ad i 6 000 50 000 0 400 A 4 000 a m X 0 000 2 000 0 000 A 0 000 ba 50 000 Sem Com Sem Com dabord Com abordagem abordagem abordagem abordagem 8 abordagem Hal 0 256 0 223 Mql 1 458 1 000 Hai 81 208 49 018 Amin 0 000 0 000 Amin 1 000 0 000 Amin 38 910 22 550 mediana 0 646 0 667 mediana 2 500 2 500 4 mediana 107 725 87 245 m dia 0 558 0 488 m dia 2 267 3 916 m dia 114 891 82 329 max 1 000 0 909 max 3 667 15 000 X m x 171 000 168 560 eg3 0 854 0 750 eq3 2 805 5 000 3 142 155 116 493 Figura 29 Compara o entre as m tricas indiretas de reusabilidade para o
2. Substituir implementa o de refer ncia S Migra o de c digo introduziu novas mudan as na IR Mudan a conclu da Figura 27 Manuten o da consist ncia da implementa o de refer ncia Sempre que for necess ria uma mudan a faz se uma an lise para decidir onde realiz la e Se a mudan a for realizada na implementa o de refer ncia a migra o de c digo repetida propagando as mudan as at os templates Se a migra o de c digo n o introduzir ainda mais modifica es nada precisa ser realizado Caso contr rio a implementa o de refer ncia precisa ser substitu da e a maneira recomendada gerar uma nova implementa o e utiliz la como substituta e e Se a mudan a for realizada direta nos templates a implementa o de refer ncia precisa ser substitu da gerando a novamente Atividade ID 4 Desenvolvimento do framework do dom nio Pap is implementador do dom nio Especialista do dom nio Entradas PT 14 Implementa o de refer ncia Sa das PT 15 Framework do dom nio Descri o as atividades anteriores desenvolveram as DSLs ferramentas e transforma es do dom nio Para isso utilizou se uma implementa o de refer ncia como base da 162 identifica o das variabilidades no c digo final Por m conforme discutido na atividade ID 3 a implementa o de refer ncia tamb m serve como base para o desenvolvimento de um framework do dom nio Nesta ativid
3. parametro parametro parametro 2 a zA z0 9 Uma transforma o autom tica deste jogo para este modelo orientado a objetos poderia gerar algo como modelo classe Jogador nome String cor String objeto objJ1 Jogador J1 branco objeto objJ2 Jogador J2 preto De forma similar com base na defini o do dom nio para uma linguagem execut vel como por exemplo Java poderia ser definida uma transforma o que gerasse o seguinte c digo para este jogo public class Jogador private String nome private String cor public Jogador String nome String cor this nome nome this cor cor public class Main 1 public static void main String args 210 Jogador objJ1 new Jogador J1 branco Jogador objJ2 new Jogador J1 preto Esse processo chamado no Draco de ciclo de refinamento b sico e resumido na Figura 44 Experi ncia com t cnicas de modelagem e programa o Experi ncia com sistemas similares Analista do dom nio Projetista do dom nio GSE ds Descri o dos Descri o dos robl ma dom nios de dom nios aei modelagem execut veis 9 T f E gram tica gram tica ransforma es intra e inter pe neo Fem ae i De dominios acordo f acordo a com com D i qual i N E VAR NE H N N Descri o do eo go Megelos do C di
4. O termo Engenharia de Software foi criado nesta confer ncia como uma provoca o para ressaltar as necessidades de se empregar no desenvolvimento de software os conceitos j consagrados em outras engenharias NAUR RANDELL 1968 Famoso termo que tamb m se originou nesta mesma confer ncia referente ao problema de se construir sistemas de software grandes e confi veis de uma maneira control vel e eficiente 20 que uma organiza o alcance os benef cios de qualidade e produtividade almejados por Mcllroy e muitos outros desde ent o Um estudo recente ALMEIDA 2007 identificou que a maioria das abordagens originadas na academia focada em partes isoladas do problema sem considerar a rela o existente entre elas e que os casos de sucesso relatados por empresas se devem a fatores muito espec ficos n o sendo gen ricos o bastante para serem aplic veis fora de seu contexto original Deve ficar claro que reutiliza o de software n o envolve somente fatores t cnicos como a utiliza o de m todos ferramentas ou m tricas Envolve tamb m fatores n o t cnicos tais como educa o treinamento motiva o incentivos e comprometimento organizacional al m de um bom planejamento e o apoio gerencial ALMEIDA et al 2004 Dentre os fatores t cnicos destaca se o papel do processo de software que ajuda a incluir no desenvolvimento uma maior capacidade de se lidar com as restri es de tempo e esfor o tornan
5. 31 Dessa forma o que necess rio a reutiliza o sistem tica FRAKES ISODA 1994 A reutiliza o sistem tica consiste no entendimento sobre como poss vel contribuir para os objetivos de neg cio na defini o de estrat gias t cnicas e gerenciais para se extrair o m ximo da reutiliza o na integra o com processos de software e de melhoria entre outros aspectos EZRAN MORISIO TULLY 2002 que fazem com que a reutiliza o ocorra de forma controlada e repet vel 2 Por m colocar essas id ias em pr tica uma tarefa complexa pois apenas agrupar um conjunto de artefatos reutiliz veis em um reposit rio disponibilizando os para os desenvolvedores n o suficiente Existe uma s rie de fatores envolvidos gerenciais organizacionais econ micos conceituais legais e t cnicos SAMETINGER 1997 FRAKES ISODA 1994 MORISIO EZRAN TULLY 2002 LUCR DIO et al 2008 Estes fatores tornam muitos casos de sucesso em reutiliza o como por exemplo os descritos por Bauer 1993 Endres 1993 Griss 1994 1995 Joos 1994 mais a exce o do que a regra e fazem com que a pesquisa na rea ainda tenha muitos pontos em aberto Esta tese trata da perspectiva t cnica da reutiliza o mais especificamente os pontos relacionados ao processo de software Nesse contexto existem v rias abordagens que visam promover a reutiliza o de software Apesar de serem distintas todas elas compartilham quatro
6. 2 Uma solu o baseada em DSL e templates composta de pelo menos tr s elementos principais O primeiro um formato de entrada que permite que um desenvolvedor especifique o conte do de cada formul rio tais como os campos tipo de dados tamanho etc Dentre os poss veis formatos o XML apresenta vantagens pela facilidade de se processar as informa es Bibliotecas com suporte a linguagens como XPATH w3c 1999a facilitam o trabalho de se consultar as informa es 66 O segundo elemento o template neste caso uma p gina HTML anotada segundo o formato JET com c digo JAVA que consulta a entrada do gerador O terceiro elemento o processador de templates respons vel por instanciar o template com base na entrada A Figura 8 ilustra esse processo onde cada trecho do template processado por meio do JET Ver Se o 2 2 2 3 para consultar o arquivo de entrada e produzir o c digo correspondente lt c legenda gt Arquivo de entrada XML anne C digo gerado HTML d E lt html gt lt body gt we E mail roy lt tipostextee eipes T al A lt tamanho gt 30 lt tamanhos m ao ae eee lt input type text sizes 50 gt lt br gt lt campo gt Senha lt campo gt lt input type password size 30 gt lt legenda gt Nome lt legenda gt lt br gt lt tipo gt texto lt tipo gt Template JET lt body gt lt html gt lt tamanho gt 50 lt tamanho gt HTML JAVA lt campo gt lt ht
7. Santos Koskimies e Lopes 2008 prop em a extens o de frameworks com uma camada adicional baseada em programa o orientada a aspectos que codifica uma DSL buscando alavancar a reutiliza o de software atrav s de t cnicas generativas Um modelo conceitual de um framework manualmente extra do pelo desenvolvedor que descreve seus elementos e conceitos em termos de um metamodelo espec fico Este modelo ent o utilizado em conjunto com um framework de linguagem para produzir ferramentas concretas para a nova linguagem Utilizando estas ferramentas o desenvolvedor de aplica es pode especificar uma aplica o e gerar c digo em termos dos elementos do framework O trabalho de Muszynski 2005 tamb m prop e a deriva o de uma DSL a partir de uma implementa o de refer ncia tornando a DSL extra da o ponto central para especifica o de produtos e gera o de c digo Estes trabalhos s o similares abordagem desta tese pois utilizam uma DSL geradores e um processo bottom up para derivar os mapeamentos entre a linguagem e a implementa o de refer ncia ou framework Eles tamb m possuem um elemento top down impl cito que corresponde ao processo de desenvolvimento da implementa o de refer ncia ou do framework o que envolve tarefas como gerenciamento de variabilidade na engenharia de dom nio A principal diferen a que na abordagem desta tese o elemento top down expl cito e focado no problema da reutiliza
8. Linguagens especificas de dominio O termo Linguagem Espec fica de Dominio DSL Domain Specific Language exige aten o especial pois se baseia em uma no o muito vaga que a palavra Dom nio utilizada com diferentes significados em diferentes reas Para esclarecer o conceito de dom nio considerado nesta pesquisa a Figura 45 apresenta um exemplo da situa o cl ssica vivida durante o processo de an lise de sistemas Dominio do Dominio da Problema solu o Dom nio Dom nio de Dom nio financeiro modelagem execut vel A es Classes M todos Cota es Bolsa de valores Empresas ndices Especialista Desenvolvedor Financeiro Figura 45 Situa o cl ssica da an lise de sistemas O desenvolvimento de sistemas envolve normalmente a captura do conhecimento de um especialista de alguma rea no exemplo um especialista financeiro e sua representa o em uma forma que facilite o desenvolvimento de uma solu o computacional papel do analista de sistemas traduzir os termos e conceitos familiares ao especialista para termos e conceitos de computa o familiares ao desenvolvedor Neste contexto a palavra dom nio refere se a uma determinada rea de compet ncia e conhecimento que possui terminologia e conceitos particulares No exemplo os termos e conceitos financeiros isto A es Indices e Cota es est o dentro da rea de
9. compet ncia e conhecimento do especialista financeiro Este portanto o dom nio financeiro Os termos e conceitos do desenvolvimento de software isto Casos de uso Classes Objetos M todos as palavras chave if while entre outras est o dentro da rea de compet ncia e conhecimento do desenvolvedor Alguns desses termos fazem parte do dom nio de modelagem Outros fazem parte do dom nio execut vel enquanto outros fazem parte de ambos Uma outra poss vel distin o feita no momento em que o analista realiza essa tradu o 258 dos termos do dom nio financeiro para os termos dos dom nios de modelagem e execut vel No contexto de desenvolvimento de sistemas o dom nio para o qual se est construindo um sistema chamado de dom nio do problema pois trata se do problema que se pretende resolver O dom nio no qual se est construindo o sistema chamado de dom nio da solu o pois ele representa a solu o computacional que est sendo desenvolvida Em reutiliza o de software a palavra dom nio normalmente utilizada como um sin nimo de Dom nio do Problema Ou seja quando se fala em aplica es de um dom nio ou um dom nio de aplica es se fala em um conjunto de aplica es que compartilham os mesmos termos e conceitos e que s o espec ficas para uma mesma rea de conhecimento Assim o dom nio financeiro por exemplo no contexto da reutiliza o de s
10. engenharia de dom nio com apoio ao DBC vi Gera o de c digo fonte na linguagem de 217 programa o empregada por uma tecnologia de DBC e vii Modelagem e reutiliza o de artefatos e modelos atrav s de ferramental apropriado Segundo essa pesquisa os principais m todos de ED e DBC n o atendem a todos estes requisitos Assim como o Kobra o trabalho de Blois 2006 fortemente baseado no conceito de componentes de software ou seja visa produzir artefatos reutiliz veis que segundo a defini o de Sametinger 1997 utilizada s o autocontidos claramente identific veis que descrevem ou realizam uma fun o espec fica e t m interfaces claras documenta o apropriada e um grau de reutiliza o definido Como resultado deste foco a implementa o obtida com a abordagem est tamb m fortemente associada a uma tecnologia de componentes como EJB Enterprise JavaBeans por exemplo A autora prop e al m de um processo de ED com foco em DBC uma nota o similar UML para representa o da variabilidade no dom nio que vai al m da mais comumente utilizada nota o de features podendo tamb m ser utilizada em outros modelos como modelos de classes casos de uso e componentes Tamb m estabelece heur sticas de apoio atividade de mapeamento entre as caracter sticas do dom nio e os demais artefatos de an lise e projeto al m de crit rios para agrupamento de componentes visando a gera o de elemento
11. o a fe gt Busca Modera o DO tipo de busca tipo de busca Busca es gt Busca avan ada TESE S ESSES ii en tipo de pagina Conte do de usu rio tipo de p gina gt Formul rio Figura 11 Modelo de features do dom nio web de autoria de conte do segundo a nota o da ferramenta ToolDay LISBOA 2007 Sub atividade AD 2 1 Mapeamento da variabilidade em cen rios O objetivo desta sub atividade mapear os pontos de varia o identificados na modelagem de features para cen rios do dom nio A modelagem de features identifica os pontos de variabilidade em termos est ticos Por m o impacto destas variabilidades nas fun es comportamento realizadas pelas aplica es do dom nio n o fica expl cito nos diagramas de features Assim esta atividade cuida do mapeamento entre a variabilidade no n vel de features e os cen rios que descrevem a funcionalidade de forma que poss vel determinar o que muda no comportamento do dom nio Para tanto utiliza se o conceito de casos de mudan a ECKLUND JR DELCAMBRE FREILING 1996 uma t cnica similar aos casos de uso e que busca prever poss veis mudan as de requisitos durante a an lise Aqui utilizada para representar a variabilidade em termos de poss veis cen rios cobrindo tanto requisitos funcionais como n o funcionais Essencialmente um processo similar ao seguido pelo m todo PuLSE ProdUct
12. ou modificadas Al m disso essa multiplicidade n o uma fun o objetiva ou seja n o se pode garantir que a todos os estados correspondam sempre 50 linhas A varia o disso torna o mapeamento entre elementos de alto n vel nos seus respectivos c digos um trabalho mais exaustivo Como resultado muitas tarefas de implementa o s o repetitivas e exaustivas gastando esfor o que poderia ser melhor aproveitado em trabalho conceitual Manuten o e documenta o criar documenta o correta e atualizada uma das tarefas mais essenciais para que um sistema de software sobreviva e evolua de maneira efetiva Por m criar e manter a documenta o atualizada normalmente uma tarefa manual n o muito 39 apreciada por desenvolvedores poss vel obter a documenta o diretamente a partir do c digo usando t cnicas automatizadas de engenharia reversa Por m essa documenta o seria apenas um reflexo do c digo e n o uma documenta o de alto n vel que muitas vezes crucial para as tarefas de manuten o em sistemas muito complexos Nesses casos o trabalho manual se mostra como a nica solu o Al m disso os mesmos problemas relacionados produtividade citados na se o anterior possuem impacto na manuten o Por exemplo modificar um nico campo de uma aplica o baseada em Struts pode requerer altera o das tabelas ndices vis es consultas e procedimentos armazenados que possuem re
13. 2006 Dispon vel em lt http www omg org gt Acesso em 14 jun 2009 OMG Unified Modeling Language OMG UML Infrastructure S 1 2007 Disponivel em lt http www omg org gt Acesso em 14 jun 2009 PARNAS D L On the design and development of program families JEEE Transactions on Software Engineering v 2 n 1 p 1 9 mar 1976 PATZKE T MUTHIG D Product Line Implementation Technologies Programming Language View S 1 October 2002 Tech Report 057 02 E Fraunhofer IESE PEREZ MARTINEZ J E SIERRA ALONSO A From analysis model to software architecture A PIM2PIM mapping In RENSINK A WARMER J Ed ECMDA FA S 1 Springer 2006 Lecture Notes in Computer Science v 4066 p 25 39 ISBN 3 540 35909 5 PETRE M Why looking isn t always seeing readership skills and graphical programming Commun ACM ACM New York NY USA v 38 n 6 p 33 44 1995 ISSN 0001 0782 PHOHA V A standard for software documentation JEEE Computer v 30 n 10 p 97 98 1997 PILGRIM J Measuring the level of abstraction and detail of models in the context of MDD In Models in Software Engineering Workshops and Symposia at MoDELS 2007 Nashville TN USA September 30 October 5 2007 revised selected papers Berlin Heidelberg Springer Verlag 2008 p 105 114 ISBN 978 3 540 69069 6 POPMA R JET Tutorial Part 1 Introduction to JET May 2004 Eclipse Corner Article Dispon vel em lt http ww
14. 450 MOORE B et al Eclipse Development using the Graphical Editing Framework and the Eclipse Modeling Framework S 1 ibm com redbooks 2004 MORILLO J L et al Incremental software reuse In MORISIO M Ed Reuse of Off the Shelf Components 9th International Conference on Software Reuse Turin Italy Springer 2006 Lecture Notes in Computer Science v 4039 p 386 389 MORISIO M EZRAN M TULLY C Success and failure factors in software reuse IEEE Transactions on Software Engineering v 28 n 04 p 340 357 2002 MUSKENS J CHAUDRON M LANGE C Investigations in applying metrics to multi view architecture models In EUROMICRO 04 Proceedings of the 30th EUROMICRO Conference Washington DC USA IEEE Computer Society 2004 p 372 379 ISBN 0 7695 2199 1 MUSZYNSKI M Implementing a domain specific modeling environment for a family of thick client gui components In The 5th OOPSLA Workshop on Domain Specific Modeling San Diego USA S 1 s n 2005 p 5 14 MUTHIG D et al Technology Dimensions of Product Line Implementation Approaches State of the art and State of the practice Survey S 1 September 2002 Tech Report 051 02 E Fraunhofer IESE MUTHIG D PATZKE T Generic implementation of product line components In Objects Components Architectures Services and Applications for a Networked World International Conference NetObjectDays NODe 2002 Erfurt Germany October 7 10 200
15. Acesso em 14 jun 2009 BRAGA R T V Um Processo para Constru o e Instancia o de Frameworks baseados em uma Linguagem de Padr es para um Dom nio Espec fico Tese Doutorado USP Universidade de S o Paulo S o Carlos SP 2002 BUSCHMANN F HENNEY K SCHMIDT D C Pattern Oriented Software Architecture Volume 4 A Pattern Language for Distributed Computing S 1 John Wiley amp Sons 2007 BUSCHMANN F HENNEY K SCHMIDT D C Pattern Oriented Software Architecture Volume 5 On Patterns and Pattern Languages S 1 John Wiley amp Sons 2007 BUSCHMANN F et al Pattern Oriented Software Architecture Volume 1 A System of Patterns S 1 John Wiley amp Sons 1996 CHIDAMBER S R KEMERER C F A metrics suite for object oriented design IEEE Trans Softw Eng IEEE Press Piscataway NJ USA v 20 n 6 p 476 493 1994 ISSN 0098 5589 CLEAVELAND J C Building application generators IEEE Software v 7 n 1 p 25 33 1988 CLEAVELAND J C Separating concerns of modeling from artifact generation using XML In Proceedings of the 1st OOPSLA Workshop on Domain Specific Visual Languages Tampa Bay USA S 1 Jyv skyl University Printing House Jyvaskyla Finland ISBN 951 39 1056 3 ISSN 0359 8470 2001 p 83 86 CLEENEWERCK T KURTEV I Separation of concerns in translational semantics for DSLs in model engineering In CHO Y et al Ed 22nd Annual ACM Symposium on A
16. como o modelo de features para produzir um conjunto inicial de DSLs Estas DSLs s o capazes de representar diferentes tipos de variabilidade em diferentes subdom nios identificados durante a an lise Agora uma abordagem bottom up adotada utilizando o projeto atrav s de exemplos VARR 2006 WIMMER et al 2007 ROBBES LANZA 2008 para produzir transforma es e possivelmente refinar as DSLs iniciais Partir de uma inst ncia concreta de como o c digo deve ser mais f cil do que identificar todos os detalhes a partir de uma perspectiva de mais alto nivel ROBBES LANZA 2008 Esta atividade realizada em quatro passos apresentados a seguir Sub atividade ID 3 1 Desenvolvimento da implementa o de refer ncia O primeiro passo consiste no desenvolvimento de uma implementa o de refer ncia MUSZYNSKI 2005 Esta implementa o de refer ncia ir assumir dois pap is primeiro ir servir como um framework do dom nio encapsulando parte das comunalidades e oferecendo suporte a parte das variabilidades no n vel de implementa o atrav s de mecanismos como aqueles apresentados na Se o 3 2 1 e padr es como aqueles discutidos na atividade PD 3 da fase de projeto A exist ncia de um framework facilita a gera o de c digo uma vez que o gerador n o precisa gerar todo o c digo mas somente o c digo necess rio para completar o framework Para essa tarefa o implementador do dom nio com a ajuda do e
17. o destaca que sempre considerou o fato de definir fun es e bibliotecas como uma forma de se construir uma DSL para um problema FOWLER 2005 260 Independentemente da abordagem adotada a principal caracter stica de uma DSL o fato de ela ter seu poder expressivo focado em um dom nio do problema o que reduz o esfor o de tradu o necess rio para construir programas pois os termos da linguagem est o pr ximos dos termos reais conhecidos pelo especialista daquele dom nio Portanto DSLs s o normalmente pequenas consistindo de um conjunto de abstra es e nota es restritos a um dom nio de forma que especialistas daquele dom nio possam trabalhar nessa linguagem facilmente Por este motivo s o tamb m conhecidas como micro linguagens ou linguagens pequenas principalmente pelos usu rios do Sistema Operacional Unix FOWLER 2005 A utiliza o de DSLs apresenta vantagens e desvantagens Dentre as vantagens destacam se DEURSEN KLINT VISSER 2000 e DSLs permitem que solu es sejam expressas nos termos e no n vel de abstra o do dom nio do problema Consequentemente especialistas do dom nio podem compreender validar modificar ou mesmo desenvolver seus pr prios programas e Programas DSLs s o concisos auto documentados e podem ser reutilizados com diferentes prop sitos e DSLs aumentam a produtividade confiabilidade manutenibilidade e portabilidade e DSLs incorporam conhecimento sobre o
18. o indo mais al m no processo at o desenvolvimento de uma primeira vers o da DSL de forma exclusivamente top down O resultado que nesta tese as DSLs s o mais pr ximas do dom nio do problema permitindo tarefas mais criativas facilitando o desenvolvimento de aplica es e oferecendo mais flexibilidade ao desenvolvedor Em contrapartida o desenvolvimento de geradores mais complexo devido a esta maior proximidade com o dom nio do problema As extens es ao modelo de features descritas por Czarnecki Helsen e Eisenecker 2004b 222 com cardinalidades de features e atributos entre outras Se o 3 1 1 permitem a especifica o de variabilidades mais complexas de forma similar variabilidade baseada em DSLs descrita na abordagem desta tese Atrav s destas extens es poss vel representar praticamente o mesmo tipo de variabilidade que poss vel representar utilizando se por exemplo um metamodelo A principal diferen a que com uma DSL tem se um poder expressivo mais focado no problema sendo portanto uma solu o mais intuitiva podendo inclusive ser utilizada e compreendida por especialistas Mas nada impede que um modelo estendido de features seja convertido em um metamodelo dando origem a uma DSL Mas al m disso a abordagem desta tese tem outras contribui es como um conjunto de diretrizes e regras para ajudar no processo de identifica o destas variabilidades no desenvolvimento das sintaxes abstra
19. o projeto arquitetural se resumiu principalmente organiza o da infraestrutura de gera o de c digo de forma integrada aos artefatos existentes na linha de produtos E na implementa o do dom nio foi utilizado um produto concreto como implementa o de refer ncia Como resultado foram definidas duas linguagens espec ficas de dom nio uma linguagem textual para a defini o das features e a sua configura o atrav s de atributos espec ficos para a linha de produtos e uma linguagem textual para a defini o de formatos de certificados um subdom nio identificado pela equipe durante a an lise Foram tamb m constru dos os geradores respons veis por configurar novos produtos e produzir c digo customizado O Quadro 16 resume alguns dados relevantes sobre este estudo Dom nio Eventos cient ficos Local Aptor Consultoria e Desenvolvimento de Software Ltda Participantes 2 Tempo total 2 meses dedica o parcial N mero de DSLs 2 configura o e certificados N mero de artefatos de gera o transforma es e geradores Tamanho total LOC 1375 artefatos de gera o l Tamanho total LOC 71873 implementa o de refer ncia N mero de features 29 do dom nio Tecnologias de implementa o Adobe DreamWeaver PHP MySQL Eclipse vers o Ganymede Tecnologias MDD EMF Eclipse Modeling Framework JET Java Emitter Templates Quadro 16 Dados sob
20. p 178 183 BAHNOT V et al Using domain specific modeling to develop software defined radio components and applications In The 5th OOPSLA Workshop on Domain Specific Modeling San Diego USA S 1 s n 2005 p 33 42 BARTHOLDT J OBERHAUSER R RYTINA A An approach to addressing entity model variability within software product lines In ICSEA S 1 IEEE Computer Society 2008 p 465 471 Disponivel em lt http dx doi org 10 1109 ICSEA 2008 30 gt Acesso em 14 jun 2009 BASILI V ABD EL HAFIZ S K A method for documenting code components Journal of Systems and Software JSS v 34 n 2 p 89 104 1996 BASILI V R BRIAND L MELO W How reuse influences productivity in object oriented systems Communications of the ACM v 39 n 10 p 104 116 1996 BASILI V R CALDIERA G ROMBACH H D The goal question metric approach In Encyclopedia of Software Engineering Vol IT S 1 s n 1994 v 2 p 528 532 BASS L CLEMENTS P KAZMAN R Software Architecture in Practice 2nd Edition S 1 Addison Wesley 2003 BAUER D A reusable parts center IBM Systems Journal v 32 n 04 p 620 624 1993 BAYER J et al PuLSE A methodology to develop software product lines In Symposium on Software Reusability SSR Los Angeles USA ACM Press 1999 p 122 131 BAYER J MUTHIG D WIDEN T Customizable domain analysis In First International Symposium on Generative and Component Ba
21. s o compostos exclusivamente por elementos novos Muitos compartilham uma base comum diferindo apenas em pontos isolados Estes expressam as varia es ou variabilidade de software Para alguns autores como Svahnberg Gurp e Bosch 2005 o termo variabilidade de software n o significa apenas as diferen as entre sistemas de software mas tamb m sua capacidade em ser estendido modificado customizado ou configurado de forma eficiente para uso em um contexto particular Trata se portanto de um atributo de qualidade assim como manutenibilidade ou usabilidade Nesta tese por m utiliza se o termo variabilidade como refer ncia s poss veis varia es de um conjunto de produtos de software Para garantir que um sistema possua um suporte adequado variabilidade ela deve ser gerenciada durante todo o seu ciclo de vida desde a an lise at o projeto e implementa o A an lise SCV descrita na se o anterior corresponde identifica o e modelagem da variabilidade Em seguida as atividades de projeto e implementa o devem cuidar para que esta variabilidade identificada seja devidamente implementada em forma de mecanismos configur veis e adapt veis LEE KANG LEE 2002 O suporte variabilidade ocorre de forma distinta nas reas de reutiliza o e MDD 3 2 1 Implementa o da variabilidade na reutiliza o de software Existem in meras maneiras de se implementar variabilidade Normalmente a literatura na
22. 06 Portland Oregon USA S 1 Jyv skyl University Printing House Jyvaskyla Finland ISBN 951 39 2631 1 ISSN 1239 291X 2006 p 169 176 240 FENTON N PFLEEGER S L Software Metrics A Rigorous and Practical Approach 2nd ed S 1 Course Technology 1998 FLORIJN G MEIJERS M WINSEN P v Tool support for object oriented patterns In European Conference on Object Oriented Programming ECOOP 97 Jyvaskyla Finland Springer Verlag 1997 p 472 495 FOWLER M Inversion of Control Containers and the Dependency Injection pattern 2004 Disponivel em lt http martinfowler com articles injection html gt Acesso em 14 jun 2009 FOWLER M Language Workbenches The Killer App for Domain Specific Languages S 1 martinfowler com 2005 Dispon vel em lt http www martinfowler com articles languageWorkbench html gt Acesso em 14 jun 2009 FOWLER M et al Refactoring Improving the Design of Existing Code S 1 Addison Wesley 1999 FRAKES W B ISODA S Success factors of systematic software reuse EEE Software v 11 n 01 p 14 19 1994 FRAKES W B PRIETO D AZ R FOX C DARE Domain Analysis and Reuse Environment Annals of Software Engineering v 05 p 125 141 1998 FRAKES W B TERRY C Reuse level metrics In Proceedings of the 3rd IEEE International Conference on Software Reuse ICSR Advances in Software Reusability Rio de Janeiro Brazil S 1 s n 1994 p
23. 139 148 FRANCE R RUMPE B Model driven development of complex software A research roadmap In 29th International Conference on Software Engineering 2007 Future of Software Engineering Minneapolis MN USA IEEE Computer Society 2007 p 37 54 GAMMA E et al Design Patterns Elements of Reusable Object Oriented Software Reading MA Addison Wesley 1995 GARCIA V C et al Towards an assessment method for software reuse capability In 8th International Conference on Quality Software QSIC Oxford UK S 1 s n 2008 p 294 299 GARCIA V C et al Towards a maturity model for a reuse incremental adoption In Brazilian Symposium on Software Components Architectures and Reuse SBCARS 2007 Campinas SP Brazil s n 2007 p 61 74 GENERO M et al Building measure based prediction models for uml class diagram maintainability Empirical Softw Engg Kluwer Academic Publishers Hingham MA USA v 12 n 5 p 517 549 2007 ISSN 1382 3256 GENERO M POELS G PIATTINI M Defining and validating metrics for assessing the understandability of entity relationship diagrams Data Knowl Eng Elsevier Science Publishers B V Amsterdam The Netherlands The Netherlands v 64 n 3 p 534 557 2008 ISSN 0169 023X 241 GREENFIELD J et al Software Factories Assembling Applications with Patterns Models Frameworks and Tools S 1 Wiley 2004 GRISS M Software reuse experience at Hewlett Packard
24. Agile model driven development is good enough IEEE Software v 20 n 5 p 71 73 2003 ANASTASOPOULOS M ATKINSON C MUTHIG D A concrete method for developing and applying product line architectures In AKSIT M MEZINI M UNLAND R Ed NetObjectDays S 1 Springer 2002 Lecture Notes in Computer Science v 2591 p 294 312 ISBN 3 540 00737 7 ANASTASOPOULOS M GACEK C Implementing product line variabilities In Symposium on Software Reusability SSR Toronto Canada s n 2001 p 109 117 236 ANTKIEWICZ M CZARNECKI K Framework specific modeling languages with round trip engineering In NIERSTRASZ O et al Ed Model Driven Engineering Languages and Systems MoDELS 2006 S 1 Springer Berlin Heidelberg 2006 Lecture Notes in Computer Science v 4199 2006 p 692 706 ARANGO G Domain analysis from art form to engineering discipline In International Workshop on Software Specifications amp Design Pittsburgh Pennsylvania United States s n 1999 p 152 159 ARBOLEDA H CASALLAS R ROYER J C Dealing with constraints during a feature configuration process in a model driven software product line In SPRINKLE J et al Ed Proceedings of the 7th OOPSLA Workshop on Domain Specific Modeling DSMO7 Montr al Canada S 1 University of Jyv skyl Finland 2007 ISBN 978 951 39 2915 2 2007 Computer Science and Information System Reports Technical Reports TR 38
25. Desta forma o MDR capaz de criar e manipular modelos em qualquer linguagem de modelagem desde que seu metamodelo seja inst ncia do MOF Internamente os modelos podem ser mantidos em mem ria RAM em um banco de dados ou no sistema de arquivos do sistema operacional em uma estrutura de rvore B O MDR tamb m persiste os modelos no formato XMI possibilitando o interc mbio de modelos entre ferramentas e desenvolvedores nttp java sun com products jmi Shttp mdr netbeans org 49 De e RE ESSES SS A raen T Ferramenta baseada no MDR Edi o Gera o Outras visual dos E de c digo funcionalidades modelos Inst ncia de IN gera JMI parte JMI parte especifica gen rica metamodelo xmi peop a Instancia de i C O q persiste EA MDR BTree modelo xmi l 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 Framework O EMF permite a manipula o de modelos segundo seu correspondente metamodelo O EMF segue um meta metamodelo denominado Ecore ao inv s do MOF padr o estabelecido pelo OMG O Ecore surgiu como uma implementa o do MOF mas evoluiu para uma forma mais eficiente a partir da experi ncia obtida ap s alguns anos na constru o de ferramentas ECLIPSE 2005 Pelo mesmo motivo de efici
26. O metamodelo UML tamb m pode ser descrito em XMI e neste caso teria uma refer ncia para o meta metamodelo MOF Por ser baseado em XML traz consigo v rias vantagens tais como a facilidade de ser interpretado e a possibilidade de se aplicar transforma es Atualmente o padr o XMI encontra se na vers o 2 1 OMG 2006c Outro padr o da MDA o QVT Queries Views Transformations OMG 2005 Ainda em fase de finaliza o o QVT define uma linguagem textual e uma nota o para definir consultas e transforma es baseadas no MOF Por meio dessa linguagem poss vel definir regras de mapeamento entre modelos escritos em qualquer linguagem de modelagem desde que essa seja uma inst ncia do MOF Apesar de ter a proposta de ser gen rica podendo trabalhar com qualquer linguagem de modelagem a MDA tem grande foco na UML Unified Modeling Language OMG 2007 Por exemplo perfis UML OMG 2006a s o o mecanismo preferido para representa o de conceitos espec ficos de plataforma em um PSM Mas sendo tamb m inst ncia do MOF a UML apenas uma das poss veis linguagens de modelagem que podem ser usadas no MDD 48 2 2 2 2 Abordagem Sun Microsystems Devido ao presente cen rio competitivo vivido pelos fabricantes de ferramentas e ambientes de apoio ao desenvolvimento a Sun Microsystems principal respons vel pela tecnologia Java tem especial interesse no desenvolvimento baseado em modelos Como a maioria de seus competi
27. a reutiliza o de grandes trechos de c digo que n o s o efetivamente utilizados pode distorcer a m trica de porcentagem de reutiliza o O uso desta m trica permite determinar se este efeito est ocorrendo Al m disso reutilizar c digo que n o efetivamente aproveitado pode ser prejudicial agregando informa es descart veis que podem confundir a equipe durante a manuten o do software Portanto esta m trica tamb m ajuda a caracterizar a reutiliza o Esta m trica consiste no c lculo da porcentagem para cada artefato reutilizado das linhas de c digo que n o s o efetivamente utilizadas em rela o ao n mero total de linhas de c digo reutilizadas Para a coleta desta m trica pode se utilizar funcionalidades das IDEs que permitem determinar quais m todos n o s o chamados por exemplo Ma Porcentagem de reutiliza o gerada Esta m trica calcula a porcentagem de artefatos Uma revis o sobre m tricas para MDD e reutiliza o apresentada no Cap tulo 9 173 produzidos por gera o autom tica e que foram reutilizados em rela o ao total de reutiliza o E calculada como sendo a porcentagem entre o n mero de linhas de c digo geradas e o n mero de linhas de c digo reutilizadas Permite caracterizar a reutiliza o que est ocorrendo em dom nios implementados atrav s do MDD Ms Raz o entre especifica o e c digo Esta m trica complementar anterior e permite determinar a rel
28. como DSLs transforma es e geradores de c digo A seguir s o apresentados mais detalhes sobre cada estudo 8 2 1 Autoria de conte do para a Web O primeiro estudo foi realizado em ambiente acad mico e envolveu o dom nio de aplica es de autoria de conte do para a Web S o aplica es onde um administrador publica conte do a ser visualizado por muitos usu rios como por exemplo portais de not cias p ginas pessoais f runs e blogs Trata se de um dom nio t cnico envolvendo os requisitos de persist ncia e navega o na Web Neste estudo as linguagens espec ficas de dom nio geradores a arquitetura e a implementa o de refer ncia foram desenvolvidos a partir do zero utilizando a abordagem definida nesta tese Foi executado pelo autor desta tese com a ajuda de especialistas de dom nio Inicialmente foram realizados estudos sobre as tecnologias de implementa o necess rias e em seguida a abordagem foi aplicada no desenvolvimento dos artefatos do dom nio Foi desenvolvida uma infraestrutura composta de artefatos de software gerados e n o gerados em uma arquitetura em tr s camadas Foram desenvolvidas quatro linguagens espec ficas de dom nio uma linguagem visual para persist ncia uma linguagem textual para navega o uma linguagem textual para a produ o de relat rios e uma linguagem visual para configura o das features presentes no produto Tamb m foram desenvolvidas transforma es e ge
29. digo PHP utilizado no terceiro estudo n o orientado a objetos e n o foi encontrada nenhuma ferramenta capaz de extrair estas m tricas para este tipo de c digo e nem ferramentas automatizadas de convers o Uma vez que a quantidade de c digo deste projeto muito grande a coleta manual das m tricas de Instabilidade Complexidade Ciclom tica e ndice de Manutenibilidade que exigem uma inspe o detalhada do c digo n o foi realizada no terceiro estudo Para os demais artefatos como metamodelos modelos e geradores baseados em templates interpretados como os templates do openArchitectureWare foi necess rio realizar o c lculo manual como por exemplo a contagem de acoplamento aferente e eferente an lise de grafos dos programas e a contagem do n mero de atributos e relacionamentos em modelos Como o n mero e tamanho destes artefatos consideravelmente reduzido este trabalho foi realizado sem dificuldades As an lises qualitativas atrav s de entrevista somente foram realizadas no terceiro estudo uma vez que nos dois primeiros estudos o autor da tese participou do desenvolvimento Ap s a coleta dos dados os mesmos foram analisados utilizando estat stica descritiva atrav s de gr ficos do tipo box plot FENTON PFLEEGER 1998 que permitem visualizar a dispers o e balanceamento das amostras Box plots podem ser utilizados de diferentes formas WOHLIN et al 2000 Nesta tese foi utilizada a abordagem definida
30. e sele o das conven es de modelagem a ser utilizadas pela equipe de desenvolvimento Para isso definido o escopo do modelo quais requisitos podem devem ser modelados Tamb m envolve a decis o sobre quais partes do software ser o feitas m o e quais ser o automaticamente geradas S o definidos quais tipos de diagramas ser o constru dos e utilizados e com quais t cnicas de modelagem A abordagem possui uma atividade na qual s o analisadas as possibilidades de linguagens a serem utilizadas na modelagem Z PJM1 Decidir sobre ferramentas de modelagem envolve a sele o de ferramentas que possam satisfazer s necessidades do projeto de gera o de c digo e documenta o Deve levar em conta objetivos e restri es do projeto tais como custos e dura o Assim como na atividade acima ENG1 a abordagem tamb m busca analisar ferramentas existentes para serem utilizadas 7 ENG2 Desenvolver modelo t cnico o modelo t cnico descreve os principais m dulos do software incluindo elementos independentes e espec ficos de plataforma O modelo t cnico representa a divis o em camadas a comunica o entre as camadas os componentes a serem utilizados ou desenvolvidos as interfaces entre os componentes a plataforma destino e persist ncia entre outros aspectos de neg cio e t cnicos do sistema A abordagem n o est focada em um tipo espec fico de modelo e portanto pode ser utilizada para desenvolver modelos t cni
31. equipe relatou dificuldades no aprendizado das tecnologias de modelagem e gera o de c digo por m com rela o abordagem citaram apenas que tiveram dificuldades em compreender as fun es espec ficas dos casos de mudan a na abordagem Segundo eles n o ficou clara a necessidade de se criar m ltiplos cen rios para descrever pequenas partes do problema e A equipe teve tamb m dificuldades na identifica o correta das features sendo necess ria a presen a constante do autor desta tese para orientar e corrigir as identifica es equivocadas No geral os participantes compreenderam os conceitos mas tinham dificuldade em reproduzi los no dom nio em quest o inserindo constantemente e de maneira equivocada m dulos e fun es como sendo features e e A equipe n o soube responder de forma apropriada com rela o ao processo investigativo de identifica o de subdom nios atividade de avalia o arquitetural e atividade de documenta o do dom nio pois n o chegou a realizar estas atividades durante o estudo Discuss o Neste estudo ao contr rio dos dois anteriores ocorreu uma redu o da porcentagem e da raz o de reutiliza o quando a abordagem foi utilizada Por m conforme discutido anteriormente a m trica de reutiliza o em termos de LOC n o pode ser lida literalmente de forma isolada pois pode ser distorcida por alguns fatores Conforme a pr pria equipe relatou em entrevista h muitos a
32. o de DSLs transforma es e geradores de c digo facilitaram a implementa o dos artefatos do MDD O formato de documenta o proposto foi adequado auxiliando na descri o dos artefatos reutiliz veis desenvolvidos Quais foram as vantagens de se utilizar a abordagem de MDD no desenvolvimento Quais foram as desvantagens de se utilizar a abordagem de MDD no desenvolvimento Quest o Q4 Os participantes que utilizaram a abordagem tiveram dificuldades que causaram preju zo ao desenvolvimento em termos de atrasos e curva de aprendizado Para avaliar as dificuldades de utiliza o da abordagem foram inclu das as seguintes perguntas na entrevista realizada na quest o Q3 referente s dificuldades percebidas pelos participantes Quais foram as dificuldades para o aprendizado da abordagem Quais foram as dificuldades para defini o do modelo de features Quais foram as dificuldades para descri o da variabilidade em cen rios casos de mudan a Quais foram as dificuldades para a identifica o de candidatos a subdom nio Quais foram as dificuldades para realizar o processo investigativo baseado em decis es para inclus o exclus o de subdom nios e Cite outras dificuldades percebidas durante a utiliza o da abordagem de MDD desde o in cio do desenvolvimento 8 1 2 Hip teses Como ensina Albert Einstein f sico alem o que viveu entre 1879 e 1955 Nenhuma quantidade de experimenta
33. o de implementa es obtidas com e sem a abordagem pode tamb m ter sofrido influ ncia pelo fato de que a abordagem foi utilizada ap s o desenvolvimento de uma implementa o de exemplo Nos dois primeiros estudos essa implementa o consistiu de 204 prot tipos execut veis desenvolvidos para praticar o desenvolvimento no dom nio e no terceiro estudo consistiu de um produto real existente na empresa Com isso o desenvolvimento com a abordagem pode ter se beneficiado de uma maior experi ncia no dom nio Por m a pr pria abordagem utiliza uma estrat gia de desenvolvimento atrav s de exemplos para proporcionar justamente este ganho de experi ncia antes da implementa o efetiva dos artefatos do MDD e portanto este efeito parcialmente o que seria obtido com a abordagem de qualquer forma Mas uma avalia o mais justa deveria envolver equipes diferentes partindo de um mesmo n vel de conhecimento sobre o dom nio Isto n o foi poss vel realizar pela dificuldade em encontrar participantes para estes estudos Finalmente destacam se as amea as s validades interna externa e de constru o WOHLIN etal 2000 Os estudos foram planejados definidos e executados de forma mais explorat ria sem a defini o de vari veis dependentes e independentes voltadas a uma an lise de correla o mais r gida Por exemplo os valores de refer ncia e margens de toler ncia citados servem mais como guia e n o como um indicador efet
34. o define somente as classes de forma isolada mas tamb m as interfaces e conex es entre as mesmas assim como a estrutura geral da aplica o instanciada Dessa forma ao utilizar um framework um desenvolvedor n o est reutilizando somente classes ou componentes isoladamente que precisam ser posteriormente integrados em uma aplica o mas sim toda a estrutura interna Essa estrutura tamb m representa parte do conhecimento daquele dom nio e assim pode se dizer que o n vel de reutiliza o alcan ado com um framework maior do que o n vel de reutiliza o alcan ado com componentes isolados representando um avan o significativo em reutiliza o KRUEGER 1992 267 A utiliza o de um framework normalmente feita por meio de seus pontos vari veis hotspots que s o os pontos que definem o que vari vel em um dom nio de aplica o BUSCHMANN et al 1996 apud BRAGA 2002 Junto com os ganchos hook que s o os pontos do framework pass veis de serem adaptados os pontos vari veis s o a forma com que o desenvolvedor normalmente instancia sua aplica o Sendo uma t cnica de reutiliza o o uso de frameworks compartilha com as demais abordagens apresentas os quatro conceitos b sicos da reutiliza o Abstra o a abstra o como na maior parte das abordagens se resume a representar o conhecimento do dom nio abstraindo se os detalhes de implementa o em uma parte escondida e descrev
35. os participantes citaram que com a abordagem puderam resolver problemas que n o conseguiam resolver anteriormente n o somente pela falta de tempo mas tamb m pela dificuldade em se obter solu es gen ricas que possam ser utilizadas por m ltiplos clientes Em muitos casos as modifica es exigidas por um cliente n o podem ser generalizadas e parametrizadas pois a natureza das mudan as profunda como por exemplo as diferentes formas de certificado citadas como exemplo pela equipe poss vel criar um componente gen rico capaz de gerar certificados para eventos com diferentes textos tamanhos de fontes de papel entre outros par metros Por m comum a exist ncia de chamados solicitando a presen a de informa es extras como um determinado texto em negrito orienta es de texto diferentes e dados n o convencionais como por exemplo certificados de respons veis por sess es chair de sess o Nestes casos a nica solu o encontrada era criar uma c pia do componente anterior e modific la para o novo requisito Com o MDD e a abordagem a equipe conseguiu criar um suporte mais flex vel para estas modifica es sem perder a generalidade do componente original e sem causar a duplica o de vers es Outro problema citado o espalhamento da informa o o que exige um grande trabalho de inspe o modifica o e testes a cada configura o de um novo produto Este espalhamento vis vel nos dados coletados no
36. presente em todo o processo de reutiliza o efetivamente elevando o n vel de abstra o do desenvolvimento Nos pr ximos cap tulos s o apresentadas uma vis o geral e descri es detalhadas sobre as atividades da abordagem definida nesta tese com especial aten o em como os pontos discutidos neste cap tulo s o combinados de forma a oferecer um melhor suporte reutiliza o em alto n vel utilizando MDD 69 4 Vis o geral da abordagem 2 Neste cap tulo apresentada uma vis o geral da abordagem orientada a modelos para reutiliza o de software proposta nesta tese S o apresentados o seu objetivo sua estrutura e uma breve descri o de suas atividades No final feita uma an lise com os modelos de maturidade de reutiliza o e MDD visando melhor ilustrar seu escopo e cobertura no processo de software 4 1 Objetivo da abordagem A abordagem orientada a modelos para reutiliza o de software tem como objetivo Reutilizar Sendo uma abordagem para reutiliza o de software o objetivo possibilitar que o desenvolvimento de software possa reutilizar artefatos pr existentes ao inv s de construir tudo a partir do in cio KRUEGER 1992 Idealmente nenhuma oportunidade de reutiliza o deveria ser perdida ou seja deve se tentar reaproveitar o m ximo poss vel de software existente durante um novo desenvolvimento De forma sistem tica Esta reutiliza o em contraste com uma abordagem ad h
37. qi 0 286 0 286 Bgl 1 121 1 000 ql 86 010 84 165 Amin 0 000 0 000 Amin 0 000 1 000 Amin 32 510 17 210 mediana 0 466 0 333 mediana 2 100 1 449 4mediana 121 230 121 230 m dia 0 496 0 479 m dia 3 252 2 054 m dia 120 333 118 063 max 1 000 1 000 max 21 412 6 845 max 223 120 223 120 q3 0 636 0 625 q3 4 124 3 000 q3 153 210 152 665 Figura 35 Compara o entre as m tricas indiretas de reusabilidade para o estudo do dom nio de aplica es distribu das baseadas em computa o em nuvem A Figura 36 analisa de forma mais aprofundada as medidas de instabilidade obtidas com a abordagem Pode se notar que o c digo gerado similar na m dia ao c digo n o gerado Por m a distribui o referente ao c digo gerado est mais concentrada ao redor do valor m dio desta m trica 0 5 Os artefatos de gera o por sua vez est o concentrados em um ponto que representa baixa instabilidade Com rela o aos modelos neste caso somente um modelo foi utilizado e portanto a m trica de instabilidade permaneceu no valor intermedi rio 0 5 A Figura 37 analisa de forma mais aprofundada as medidas de complexidade ciclom tica obtidas com a abordagem Pode se notar que o c digo gerado apresenta maior complexidade em rela o ao c digo n o gerado Os artefatos de gera o s o ligeiramente mais complexos do que o c digo n o gerado e os modelos apresentam complexidade baixa Com exce o do c digo
38. todo principal linha 9 os comportamentos espec ficos de cada sub feature s o chamados O Chain of Responsibility permite a combina o de comportamentos sequenciais ou seja um executado ap s o outro Em intera es mais complexas onde a ordem de chamada dos comportamentos espec ficos n o sequencial exigindo um c digo espec fico para isso o padr o Decorator pode ser utilizado Neste padr o cria se um decorator para cada variante 130 Em cada decorator implementa se uma vers o dos m todos principais considerando se como esta variante modifica o comportamento normal O gerador apenas precisa fazer a concatena o dos decorators de forma a reproduzir as variantes selecionadas metodo1 metodo2 A FeatureADecorator Se FeatureADecorator FeatureA A SubFeatureA3Decorator EEE FeatureASozinha SubFeatureA3Decorator FeatureA metodo1 metodo1 metodo2 metodo2 SubFeatureA2Decorator Ea SS ee Se ee SubFeatureA2Decorator FeatureA metodo1 metodo2 Sub feature A2 SubFeatureA1Decorator E ee SubFeatureA1Decorator FeatureA metodo1 metodo2 public class UmProduto public static void main String args FeatureA featureA new SubFeatureAlDecorator new SubFeatureA3Decorator new FeatureASozinha Utilizar featureA normalmente OAHU PWN EH es we Gerador Figura 19 Uso do padr o De
39. veis ao contexto do MDD o objetivo foi adaptar as t cnicas existentes para o contexto desta tese Por exemplo no Cap tulo 6 que descreve o uso de padr es de projeto normalmente utilizados para o gerenciamento da variabilidade ALMEIDA et al 2007b KEEPENCE MANNION 1999 LEE KANG 2004 foram 72 incorporados detalhes referentes sua utiliza o em conjunto com transforma es e geradores de c digo Da mesma forma no Cap tulo 7 s o descritas diretrizes de apoio s atividades de implementa o de DSLs e geradores no contexto da Engenharia de Dom nio Outros exemplos s o descritos durante os pr ximos cap tulos no pr prio texto que descreve a abordagem Durante a defini o das fases foram desenvolvidos estudos de caso de car ter explorat rio visando testar e refinar cada atividade e artefato produzido Estes estudos envolveram o dom nio de aplica es Web e posteriormente evolu ram para o primeiro dos estudos de caso utilizados na avalia o conforme descrito no Cap tulo 8 Reuni es com o grupo de pesquisa e outros especialistas com os quais o autor tem colaborado tamb m ajudaram a testar e refinar a abordagem 4 3 Estrutura da abordagem A abordagem est dividida em tr s fases que seguem a divis o de fases da engenharia de dom nio an lise projeto e implementa o A an lise de dom nio tem como objetivo identificar o escopo do dom nio identificar pontos comuns e vari veis do dom nio identif
40. 104 490 168 560 172 050 0qg3 0 700 0 708 0 333 q3 8 250 8 000 5 000 q3 61 260 98 000 125 510 Figura 41 Compara o entre as m tricas de reusabilidade dos estudos dos dom nios de eventos cient ficos EC Web e Computa o em Nuvem CN Foram utilizados somente dois modelos baseados em XML e estes apresentaram uma m dia de 36 33 atributos e nenhum relacionamento Com rela o aos dados qualitativos foram coletadas algumas impress es passadas pela equipe ap s a execu o do estudo Entre as impress es obtidas com a entrevista destacam se e Segundo a equipe a abordagem permitiu atacar problemas recorrentemente enfrentados pela equipe tais como o alto n vel de retrabalho procurando c digos e testando cada mudan a no dom nio a exist ncia de arquivos que nunca s o utilizados mas que s o inclu dos nos produtos por conveni ncia o que acaba por confundir os desenvolvedores e causando problemas de manuten o e a necessidade de busca por links que precisam removidos dependendo da configura o de produtos adquiridos pelo cliente e Neste estudo a automa o conseguida com o MDD permitiu reduzir alguns problemas de 70 conte do integral da entrevista encontra se no Ap ndice C 199 forma que n o vinha sendo conseguida por falta de tempo e dificuldades em desenvolver uma solu o que atendesse a m ltiplos clientes ao mesmo tempo e
41. 34 ROTHENBERGER M A et al Strategies for software reuse A principal component analysis of reuse practices IEEE Transactions on Software Engineering v 29 n 09 p 825 837 2003 249 SAMETINGER J Software Engineering with Reusable Components Berlin Heidelberg Springer Verlag 1997 SANTOS A L KOSKIMIES K LOPES A Automated domain specific modeling languages for generating framework based applications In SPLC SI IEEE Computer Society 2008 p 149 158 ISBN 978 0 7695 3303 2 Dispon vel em lt http dx doi org 10 1109 SPLC 2008 17 gt Acesso em 14 jun 2009 SCHMIDT D C Guest editor s introduction Model driven engineering IEEE Computer v 39 n 2 p 25 31 2006 SCHMIDT D C et al Pattern Oriented Software Architecture Volume 2 Patterns for Concurrent and Networked Objects S 1 John Wiley amp Sons 2000 SEACORD R PLAKOSH D LEWIS A Modernizing Legacy Systems Software Technologies Engineering Processes and Business Practices S 1 Addison Wesley 2003 SHERIF K APPAN R LIN Z Resources and incentives for the adoption of systematic software reuse International Journal of Information Management v 26 n 1 p 70 80 2006 Available online 10 October 2005 SILVA M F WERNER C M L Packaging reusable components using patterns and hypermedia In 4th International Conference on Software Reuse USA s n 1996 p 146 155 SIMOS M et al Organization Domain Mo
42. B sico n N vel 1 Modelagem N vel 1 Incompleto ad hoc Modelo de maturidade em reutiliza o Modelo de maturidade em MDD Figura 10 Abrang ncia da abordagem em rela o aos modelos de maturidade em reutiliza o e MDD No total as atividades da abordagem aderem a 6 pr ticas do modelo de maturidade em reutiliza o e 13 pr ticas do modelo de maturidade em MDD conforme descrito a seguir e Reutiliza o AP2 Planejamento de reutiliza o uma das atividades iniciais da abordagem consiste no planejamento da reutiliza o incluindo poss veis riscos e a ado o desta abordagem pode ser considerada como uma decis o de planejamento assim como a defini o de seu modelo do ciclo de vida Uma discuss o mais detalhada sobre cada pr tica dos modelos de maturidade e a sua rela o com a abordagem aqui proposta apresentada no Ap ndice B AP3 Defini o dos objetivos da reutiliza o a abordagem cont m uma atividade para defini o dos objetivos da reutiliza o AP4 Implementa o do dom nio uma das fases da abordagem que visa implementar um dom nio utilizando t cnicas do MDD AP6 Integra o com o ciclo de vida do software esta pr tica consiste justamente na defini o desta abordagem e seus elementos AP7 An lise de dom nio a abordagem realiza a an lise de dom nio voltada para o MDD AP8 Projeto de dom nio a abordagem engloba as pr tic
43. DSL prev a especifica o de v rias entidades de dados deve se criar duas ou tr s entidades de exemplo e n o somente uma Di3 Explorar as diferentes dimens es e tipos de atributos Deve se usar tanto valores pequenos e grandes como exemplos de atributos Dis Resgatar produtos e aplica es analisados durante a an lise de dom nio de modo a explorar a maneira como estes lidam com a variabilidade aberta Deve se utilizar este conhecimento como inst ncias a serem cobertas pela implementa o de refer ncia Dis Caso algum tipo de variabilidade seja muito complexa para ser automatizada atrav s do MDD deve se ent o ao menos garantir que o c digo gerado d suporte a algum tipo de mecanismo que permita a sua implementa o manual Deve se experimentar estes mecanismos na implementa o de refer ncia Sub atividade ID 3 2 Inspe o de c digo e mapeamento para elementos das DSLs O segundo passo consiste na inspe o do c digo da implementa o de refer ncia em busca de trechos que correspondam a elementos de alguma DSL do dom nio O objetivo identificar principalmente a presen a de variantes no c digo e mape las para as DSLs correspondentes A inclus o de uma variante no c digo normalmente resulta em modifica es em diferentes artefatos H quatro tipos de modifica es que podem co existir em um dom nio ANASTASOPOULOS GACEK 2001 e Adi o de novas funcionalidades refere se inclus o
44. Domain Engineering Software Product Lines Domain Specific Languages Generative Programming 10 11 12 13 14 15 16 17 18 19 Lista de Figuras Modelo de maturidade em reutiliza o o o aa 35 Ilustra o do processo de cria o de software no desenvolvimento orientado a Modelos arama el me ee ap E E E eek Bee Bees EX 41 Principais elementos do MDD aan als ars a ie es ADE CR ae a 44 Arquitetura cl ssica de metamodelagem 04 45 Funcionamentodo MPDR sata ieee age Sata Saga Rigs Ge kG et E A 49 Compara o entre MDR e EMF cccccll 50 Modelo de maturidade em MDD ccccccccl a 53 Gera o de c digo baseada em templates oono 66 Sugest o de modelo de processo para utiliza o da abordagem 15 Abrang ncia da abordagem em rela o aos modelos de maturidade em reutiliza o e MDD ss sueste ee eS ES E EE RE BS 81 Modelo de features do dominio web de autoria de conteido 93 Candidatos a subdom nio do dominio web de autoria de conte do 102 Poss vel evolu o dos n veis de decis o para o dom nio de aplica es de autoria d conteudo para WC hqs ni Bing E DS RL AE OR E E 110 Modelo de features do dominio web de autoria de conteido 116 Uso do padr o Abstract Factory para features alternativas 126 Uso do padr o Prototype para features alternativas 127 Uso do padr o Template method para features al
45. In 16th International Conference on Software Engineering ICSE Sorrento Italy IEEE CS Press 1994 p 270 GRISS M Making software reuse work at hewlett packard IEEE Software v 12 n 01 p 105 107 1995 GRISS M FAVARO J D ALESSANDRO M Integrating feature modeling with the RSEB In The Fifty International Conference on Software Reuse ICSR Victoria Canada IEEE CS Press 1998 p 76 85 GUERRA E LARA J de DIAZ P Visual specification of measurements and redesigns for domain specific visual languages J Vis Lang Comput Academic Press Inc Orlando FL USA v 19 n 3 p 399 425 2008 ISSN 1045 926X GUIZZARDI G PIRES L F SINDEREN M J V On the role of domain ontologies in the design of domain specific visual modeling languages In In Proceedings of the 2nd Workshop on Domain Specific Visual Languages 17th ACM Conference on Object Oriented Programming Systems Languages and Applications OOPSLA 2002 S 1 s n 2002 HADDAD H TESSER H Reusable subsystems Domain based approach In 2002 ACM Symposium on Applied Computing SAC 2002 Madrid Spain ACM 2002 p 971 975 HEINEMAN G COUNCILL W Component Based Software Engineering Putting the Pieces Together USA Addison Wesley 2001 HENRIKSSON A LARSSON H A Definition of Round Trip Engineering S 1 2003 Department of Computer and Information Science Link pings Universitet SE 581 83 Link ping Sweden HESS
46. Line Software Engineering 94 DEBAUD FLEGE KNAUBER 1998 com a diferen a de que aqui s o providos mais detalhes sobre sua execu o Um caso de mudan a um cen rio que descreve um ponto de varia o no dom nio com foco nas mudan as trazidas pela presen a de uma ou mais variantes Para cada caso de mudan a s o registradas as features relacionadas e os cen rios casos de uso ou mudan a que s o afetados Por exemplo considere o modelo de features da Figura 11 e o caso de uso referente feature de navega o ilustrado no Quadro 3 Nome UC002 Navega o Atores Usu rio final Fluxo normal 1 Usu rio acessa p gina da aplica o 2 Aplica o exibe conte do da p gina caso necess rio realiza consulta nos cadastros para exibir o conte do 3 Usu rio clica em links para navegar para outra p gina Fluxos alternativos N o h Features relacionadas Navega o Conte do P gina Link Conte do de Usu rio Quadro 3 Exemplo de caso de uso do dom nio web Conforme mostra a Figura 11 o dom nio contempla uma feature opcional de busca c rculo branco no final do conector Um caso de mudan a que descreve essa feature opcional apresentado no Quadro 4 Nome CM001 Realizar busca simples Atores Usu rio final Fluxo normal 1 Usu rio informa string de busca 2 Aplica o realiza busca sobre todo o conte do cadastrado 3 Aplica o exibe lista com o conte do que
47. Procurar por configura es de features que n o mudam entre as aplica es se uma feature representa um ponto de varia o sua configura o deve mudar de alguma forma quando as diferentes aplica es variam com rela o a este ponto Por exemplo se uma aplica o web prov busca avan ada e uma segunda aplica o prov busca simples as configura es das features para estas aplica es ser o diferentes Isto indica que a variabilidade pode ser representada como features Por m se duas aplica es diferem em algum ponto mas as configura es das features que descrevem aquele ponto s o as mesmas isto pode indicar que 148 h alguma variabilidade que n o pode ser representada como features e talvez seja necess ria uma DSL Por exemplo considere duas aplica es web com suporte para busca avan ada Na primeira poss vel buscar por conte do de usu rio pelo autor data e palavras chave Na segunda poss vel buscar pelo autor tipo do conte do palavras chave e outros metadados espec ficos desta aplica o Neste exemplo ambas as configura es ir o apresentar a feature Busca avan ada apesar de possu rem detalhes distintos D2 Analisar as features de tecnologia do dominio features de tecnologia do dominio representam as maneiras de se implementar os servi os ou opera es do dom nio LEE KANG LEE 2002 Eles s o alguns dos blocos de constru o sobre os quais a implementa o re
48. a abordagem no dom nio de aplica es distribu das baseadas em computa o em nuvem na manutenibilidade do c digo gerado e nos artefatos de gera o com rela o ao c digo gerado A Figura 39 mostra que as quantidades de atributos de ambos os tipos de modelo gera o e especifica o permaneceram abaixo do limite estipulado 41 O n mero de relacionamentos por m excedeu consideravelmente o limite 9 nos modelos de gera o e de forma moderada no caso dos modelos de especifica o Discuss o Neste dom nio a exemplo do dom nio Web mas de forma menos acentuada tamb m foram observados aumentos no n vel e na raz o de reutiliza o de linhas de c digo e uma baixa taxa de reutiliza o n o desejada Os mesmos motivos discutidos no estudo do dom nio Web se aplicam a este caso sendo observados diversos artefatos com alto grau de similaridade Esta parece ser uma tend ncia de dom nios t cnicos onde a t nica est em resolver problemas de mais baixo n vel de forma repetida e constante como a persist ncia e navega o no caso do dom nio Web e distribui o no caso deste dom nio Neste caso inclusive foi observada uma 196 250 000 ndice de Manutenibilidade com Abordagem 200 000 150 000 100 000 50 000 I 0 000 C digo n o gerado C digo gerado Artefatos gera o Eql 91 515 70 750 77 210 Amin 32 510
49. al 2008 aqui os autores acrescentam a preocupa o com reprojeto e refatora o de modelos visando a sua melhoria A linguagem para defini o de m tricas tamb m inclui a es que representam modifica es nos modelos de forma a implementar o reprojeto Nos estudos de caso desta tese o objetivo foi avaliar a abordagem e suas vantagens com rela o ao desenvolvimento para reutiliza o tradicional e portanto n o foi necess ria a defini o de nenhuma m trica espec fica para um dom nio Genero Poels e Piattini 2008 apresentam doze m tricas para avalia o estrutural de modelos entidade relacionamento com o objetivo de determinar sua manutenibilidade atrav s de sua compreensibilidade A premissa de seu trabalho a de que quanto mais compreens vel for um diagrama maior ser a sua facilidade de manuten o Foi realizado um estudo emp rico que demonstrou que a compreensibilidade de um diagrama E R afetada por sua complexidade estrutural ditada pela quantidade de atributos e relacionamentos em particular relacionamentos 1 1 e 1 N Quanto mais atributos e relacionamentos 1 1 e 1 N um diagrama possuir menos compreens vel ele ser interessante notar que n o foi identificada evid ncia que relaciona o tamanho de um diagrama em termos de n mero de entidades com a compreensibilidade a n o ser atrav s de sua rela o bvia com o n mero de relacionamentos Igualmente n o foi evidenciada rela o com o
50. artefatos gerados duplicando as nas especifica es de origem Dessa forma as mudan as n o se perdem estando presentes nas pr ximas gera es de artefatos Uma abordagem mais simples consiste em n o permitir que certas mudan as sejam realizadas Um exemplo de ferramenta que utiliza essa abordagem a plataforma NetBeans o editor textual de c digo de interface desta plataforma bloqueia certos trechos de c digo associados com caracter sticas estruturais da interface de forma que o desenvolvedor s pode inserir essas modifica es por meio do editor visual Essa abordagem por m restrita aos casos onde se pode bloquear modifica es sem perder a flexibilidade necess ria para se resolver os problemas daquele dom nio A abordagem generativa tamb m pode ser analisada frente aos quatro conceitos da reutiliza o descritos por Krueger 1992 265 Abstra o conforme j discutido anteriormente o que est sendo reutilizado o processo de constru o dos artefatos e n o os artefatos em si A abstra o desse processo consiste na defini o do formato de entrada do gerador seja ele uma DSL visual textual ou mesmo par metros que preenchem um ou mais templates Essa defini o corresponde parte vis vel da abstra o com a qual o desenvolvedor trabalha A parte escondida fica dentro gerador e respons vel pelos detalhes de implementa o Sele o a sele o consiste em escolher um gerador aprop
51. as features identificadas na atividade anterior Tamb m s o desenvolvidos cen rios do dom nio com foco na variabilidade Esta atividade respons vel por criar modelos expressivos do dom nio atrav s da descri o de suas features e seus relacionamentos com foco nas variabilidades do dom nio Enquanto a atividade anterior se preocupou com o escopo aqui a preocupa o com a estrutura interna do dom nio Nesta abordagem a t cnica de modelagem de features utilizada Se o 3 1 1 O analista do dom nio agrupa as features identificadas na atividade anterior em uma hierarquia gr fica que captura relacionamentos estruturais l gicos entre as features Existe na literatura um conjunto de diretrizes que podem auxiliar nesta atividade ALMEIDA et al 2006 LEE KANG LEE 2002 No contexto do desenvolvimento orientado a modelos a modelagem das features e seus relacionamentos de grande import ncia pois ela indicam pontos de especial interesse para os transformadores e ferramentas de modelagem pois especificam os procedimentos que mapeiam as abstra es em n vel de dom nio 93 A Figura 11 mostra o modelo de features criado para o dom nio de aplica es de autoria de conte do para a Web Nota se que as features identificadas na atividade anterior foram inclu das al m dos relacionamentos entre elas e novas features como link Formul rio e Relat rio Dominio autoria web Navega o Administra
52. atrav s do desenvolvimento orientado a modelos As principais contribui es deste cap tulo s o as atividades sistem ticas e algumas diretrizes para identifica o dos subdom nios para automa o Tamb m apresenta uma forma para lidar com os riscos da incerteza sobre a automa o dos subdom nios O Quadro 8 resume as atividades da an lise de dom nio AD 1 2 Defini o do escopo Atividades e sub atividades Entradas Sa das AD 1 Planejamento do dom nio Informa es sobre sistemas do dom nio PT 1 Inicial Planejamento do AD 1 1 Prepara o Conhecimento do especialista dom nio Informa es sobre stakeholders PT 2 Inicial Mapa de aplica es AD 2 Modelagem do dom nio AD 2 1 Mapeamento da variabilidade em cen rios Informa es sobre sistemas do dom nio Conhecimento do especialista Informa es sobre stakeholders PT 1 Inicial Planejamento do dom nio PT 2 Inicial Mapa de aplica es PT 3 Inicial Modelagem do dom nio AD 3 Identifica o de subdom nios AD 3 1 Sele o de candidatos a subdominio AD 3 2 Identifica o de linguagens de modelagem AD 3 3 Identifica o de ferramentas AD 3 4 Atribui o de n vel de confian a AD 3 5 Documenta o dos subdom nios candidatos Informa es sobre sistemas do dom nio Conhecimento do especialista Informa es sobre stakeholders PT 1 Inicial Planejamento do dom nio PT 2 Inicial Mapa de aplica es PT 3 Inicia
53. based software development In STEP 05 Proceedings of the 13th IEEE International Workshop on Software Technology and Engineering Practice Washington DC USA IEEE Computer Society 2005 p 7 16 ISBN 0 7695 2639 X LEDECZI A et al Composing domain specific design environments IEEE Computer v 34 n 11 p 44 51 2001 LEE J KANG K C Feature binding analysis for product line component development In LINDEN F van der Ed Software Product Family Engineering 5th International Workshop PFE 2003 Siena Italy November 4 6 2003 Revised Papers S 1 Springer 2003 Lecture Notes in Computer Science v 3014 p 250 260 ISBN 3 540 21941 2 244 LEE J MUTHIG D Feature oriented variability management in product line engineering Communications of the ACM v 49 n 12 p 55 59 December 2006 LEE K KANG K C Feature dependency analysis for product line component design In 8th International Conference on Software Reuse ICSR Madrid Spain s n 2004 p 69 85 LEE K KANG K C LEE J Concepts and guidelines of feature modeling for product line software engineering In 7th International Conference on Software Reuse ICSR Methods Techniques and Tools Austin Texas s n 2002 p 62 77 LIM W C Effects of reuse on quality productivity and economics IEEE Software v 11 n 5 p 23 30 1994 LINDEN F V D SCHMID K ROMMES E Software Product Lines In Action The Best Indu
54. c digo tanto o gerado como o n o gerado mais inst vel complexo e dif cil de manter do que os artefatos de gera o Isto se explica pela complexidade natural do dom nio uma vez que a computa o em nuvem traz muitos desafios n o triviais como o c lculo distribu do de invariantes do sistema determina o de cliques maximais descoberta din mica de servi os e execu o distribu da LUCR DIO JACKSON SCHULTE 2008 Detalhes sobre estes assuntos ficam encapsulados n o somente em componentes mas tamb m nos geradores de forma que um desenvolvedor pode produzir aplica es complexas mesmo sem conhecer a fundo todas as tecnologias envolvidas Em outras palavras em contraste com o estudo anterior neste dom nio mais f cil e simples especificar do que codificar 197 Assim o que se observou neste estudo foi al m do aumento na reutiliza o um aumento na reusabilidade dos artefatos do dom nio percebido de forma indireta com a redu o da instabilidade complexidade e dificuldade de manuten o Assim enquanto no estudo anterior verificou se que o uso da abordagem pode trazer benef cios em termos de volume de reutiliza o aqui observa se que a abordagem pode simplificar o desenvolvimento abstraindo detalhes e complexidades inerentes a este dom nio complexo 8 4 3 Eventos cient ficos A Figura 40 ilustra uma compara o entre os n veis de reutiliza o obtidos com e sem a abordagem para o estudo
55. caracter sticas respons veis pelo mapeamento autom tico das caracter sticas para modelos que as implementam com base em transforma es de modelos 214 Um template de modelo baseado em features consiste em modelos de features e modelos anotados que implementam as features Cada anota o enriquece um modelo com informa es referentes s features e podem ser na forma de condi es de presen a aus ncia itera es para expans o de templates ou express es mais complexas para c lculo de elementos de modelagem Os modelos anotados ent o representam como as configura es de um produto de uma linha influenciam na implementa o da variabilidade correspondente Uma variante consiste na instancia o das anota es e desta forma poss vel gerenci la individualmente de forma isolada A abordagem desta tese utiliza o mesmo tipo de constru es para implementa o das variabilidades por m ao inv s de templates de modelos aqui s o utilizados principalmente templates de c digo pois o objetivo produzir implementa es de forma mais direta e n o atrav s de modelos intermedi rios Al m disso nesta tese s o definidas atividades para a constru o dos templates e liga o n o somente com modelos de features mas tamb m DSLs que representam variabilidades mais complexas em partes do dom nio e ou subdom nios Knodel et al 2005 apresentam uma abordagem para a utiliza o de desenvolvimento orientado a
56. conjunto dos artefatos a serem desenvolvidos para o dom nio Al m disso visa identificar as comunalidades e variabilidades ou seja os pontos que s o comuns a todas as aplica es do dom nio e os pontos que variam Como discutido na Se o 3 1 1 uma das abordagens mais comuns para esta tarefa a modelagem de features KANG et al 1990 KANG LEE DONOHOE 2002 Um dos principais desafios em projetar e implementar um dom nio descrito em termos de suas features est em como mapear estas features para a arquitetura e o c digo considerando todos os relacionamentos e restri es envolvendo as mesmas A exist ncia de uma feature pode levar a diferentes tipos de impacto no produto final Em casos mais simples poss vel ligar ou desligar uma feature atrav s de um par metro em um componente de forma que atribuindo um valor para este par metro a feature estar presente ou ausente Por exemplo considere um dom nio de autom veis onde existem tr s tipos de motores Diesel Gasolina e lcool Em um sistema mais simples como por exemplo um sistema de uma companhia de aluguel de autom veis o tipo do motor pode ser simplesmente representado com um atributo do tipo inteiro onde 0 Diesel 1 Gasolina e 2 lcool Escolher um valor apropriado para este atributo o suficiente para que a feature seja inclu da na aplica o Em um sistema mais complexo por m como por exemplo um sistema de uma companhia de tran
57. considerado 9 N mero de Atributos N mero de Relacionamentos 70 000 40 000 60 000 35 000 X 50 000 30 000 a 25 000 40 000 e 20 000 30 000 p 15 000 gt 20 000 10 000 10 000 5 000 ee 0 000 0 000 Gera o Especifica o Gera o Especifica o Eqi 8 000 32 500 qi 3 750 9 500 Amin 2 000 23 000 Amin 0 000 3 000 4 mediana 12 500 42 000 4 mediana 6 000 16 000 m dia 12 250 41 000 m dia 7 000 17 667 max 22 000 58 000 X max 16 000 34 000 q3 16 750 50 000 q3 9 250 25 000 Figura 33 Distribui es do n mero de atributos e do n mero de relacionamentos nos modelos utilizados com a abordagem no estudo de caso do dom nio de autoria de conte do para web Discuss o O primeiro e mais evidente resultado observado o maior n mero de linhas de c digo reutilizadas com a abordagem al m de uma baixa taxa de reutiliza o n o desejada Uma 192 primeira explica o a de que geradores produzem bastante c digo redundante e por isso o n mero de linhas naturalmente maior Esta afirma o est pr xima da realidade deste estudo ja que um dos itens importantes na identifica o de candidatos a subdom nio a exist ncia de trechos repetidos de c digo como ressaltado por Knodel et al 2005 e discutido na atividade AD 3 desta abordagem Cap tulo 5 Neste estudo de caso obser
58. corresponde string informada 4 Usu rio clica sobre um resultado e continua navega o Fluxos alternativos 3 N o existe conte do associado a string informada 3 1 Aplica o exibe mensagem informando que n o foi encontrado nenhum conte do Featuresrelacionadas Navega o Busca Busca simples Cen riosafetados UC002 Navega o Quadro 4 Exemplo de caso de mudan a para a feature opcional de busca Neste exemplo o caso de mudan a CM001 Realizar busca simples descreve um cen rio de uso considerando se a presen a desta feature opcional S o tamb m indicadas as features relacionadas e os casos de uso afetados 95 Mesmo um caso de mudan a pode sofrer o impacto de algum outro ponto de varia o Neste exemplo a busca pode ser simples ou avan ada features alternativas indicadas pelos losangos nos conectores no diagrama da Figura 11 O caso de mudan a CM001 Realizar busca simples descreve o cen rio correspondente feature Busca simples O Quadro 5 descreve a variante Busca avan ada Nome CM002 Realizar busca avan ada Atores Usu rio final Fluxo normal 1 Usu rio informa string de busca e local onde deseja realizara busca 2 Aplica o realiza busca no local especificado pelo usu rio 3 Aplica o exibe lista com o conte do que corresponde string informada 4 Usu rio clica sobre um resultado e continua navega o Fluxosalterna
59. de linguagens para se alcan ar resultados pr ticos rapidamente Por m DSLs mais complexas podem exigir uma participa o mais ativa de um especialista em linguagens Esta ltima sub atividade tamb m inclui a defini o de valida es para capturar erros sem nticos durante a modelagem orientando o desenvolvedor na cria o de diagramas ou programas segundo a DSL em quest o VOLTER 2008 Por exemplo uma valida o sem ntica 154 pode garantir que o comportamento de uma entidade em um jogo modelada atrav s de uma DSL visual sempre tenha um comportamento padr o definido Ap s este quinto passo obt m se um conjunto de DSLs e ferramentas que permitem que um desenvolvedor represente diferentes tipos de variabilidade em cada subdominio identificado desde casos mais simples baseada em features at a variabilidade mais complexa Mas as DSLs ainda n o est o completas pois at agora somente uma abordagem top down foi utilizada Podem existir detalhes adicionais que precisam ser inclu dos antes que a DSL sirva de entrada para transforma es e gera o de c digo aqui que uma abordagem bottom up entra em cena Atividade ID 3 Desenvolvimento das transforma es e refinamento das DSLs bottom up Pap is implementador do dom nio Especialista do dom nio Entradas PT 3 Validado Modelagem do dom nio PT4 Validado Candidatos a subdom nio PT 5 Hist rico de decis es sobre inclus o exclus o de subdom
60. de modelagem e ou ferramentas de modelagem e transforma es Apesar de esta decis o levar aloca o de recursos e esfor os estes s o mais limitados uma vez que n o h impacto nos demais artefatos do dom nio e sempre poss vel parar a investiga o sempre que necess rio pois o sucesso do neg cio n o depende diretamente desse desenvolvimento e D4 Iniciar o desenvolvimento de artefatos de produ o este o ponto sem retorno para um subdom nio Neste n vel de decis o a organiza o compromete se a incluir o subdom nio no processo de desenvolvimento diferentemente do nivel D3 onde ainda existe a possibilidade de se descartar o subdom nio Um subdom nio neste n vel deve possuir um alto n vel de confian a mas n o necessariamente precisa possuir as ferramentas para ser automatizado Esta uma decis o cr tica uma vez que significa empregar esfor os e recursos de forma mais intensa para automatizar o subdom nio e gerenciar o seu impacto no restante do dom nio e Ds Iniciar um projeto piloto antes de incluir um subdom nio no processo final boa pr tica executar um projeto piloto para reduzir os riscos da introdu o de uma nova 109 tecnologia no desenvolvimento e reduzir as barreiras transfer ncia tecnol gica que ir ocorrer Este projeto piloto tamb m serve para se verificar os benef cios reais da nova tecnologia e planejar a melhor maneira de aplic la a projetos reais e e D
61. de novos componentes classes fun es estruturas de dados ou trechos de c digo Esta a chamada variabilidade positiva Por exemplo no dom nio web a inclus o da feature de busca pode resultar em um novo componente uma caixa de texto na p gina principal e novas estruturas no banco de dados 158 e Remo o de funcionalidades se refere remo o de componentes classes fun es estruturas de dados ou trechos de c digo E a chamada variabilidade negativa Por exemplo no dom nio web a inclus o da feature de busca pode resultar na remo o de um banner de propaganda do site por falta de espa o e Substitui o de funcionalidades se refere substitui o de componentes classes fun es estruturas de dados ou trechos de c digo Pode se considerar como uma combina o de variabilidades negativa e positiva Por exemplo a inclus o da variante de busca avan ada requer a substitui o do componente de busca simples por um outro que implementa um algoritmo avan ado e e Plataforma ambiente quando a inclus o da variante requer modifica es na plataforma ou ambiente de execu o Por exemplo no dom nio web a inclus o da feature de busca pode requerer a inclus o de uma biblioteca espec fica uma vers o diferente do banco de dados ou mesmo uma m quina virtual diferente Esta atividade cuida da identifica o exata destas altera es Essencialmente esta uma atividade semelhante ao processo d
62. de problemas arquiteturais O cat logo cl ssico de padr es de projeto GAMMA et al 1995 tamb m pode ser til nesta atividade al m de outras fontes citadas por Bass Clements e Kazman 2003 Com rela o ao problema da variabilidade existem alguns trabalhos que prop em o uso de alguns padr es de projeto com este objetivo ALMEIDA et al 2007b KEEPENCE MANNION 1999 LEE KANG 2004 Existem tamb m diversos trabalhos que apresentam formas de se implementar variabilidade em uma linha de produtos que podem ser adaptadas para o n vel 125 de projeto arquitetural ANASTASOPOULOS GACEK 2001 MUTHIG PATZKE 2003 RIBEIRO MATOS BORBA 2008 SVANHBERG GURP BOSCH 2002 Por m estes n o cobrem o aspecto de integra o entre diferentes subdom nios Para esta abordagem foram selecionados alguns padr es que auxiliam na implementa o das t ticas espec ficas para variabilidade e integra o entre subdom nios apresentados mais adiante nesta se o A escolha das t ticas e padr es a serem utilizados guiada por dois fatores o requisito em si explicitado pela diretriz arquitetural e os efeitos colaterais que o emprego de uma t tica ou padr o provoca nas demais diretrizes BASS CLEMENTS KAZMAN 2003 Caso n o seja poss vel encontrar alguma t tica e ou padr o que sirva para um cen rio espec fico pode se modificar ou adaptar t ticas e padr es existentes ou mesmo criar novos especialmente para este dom n
63. desenvolvimento de infraestrutura para uma fam lia de produtos esta pr tica s aplic vel nos 280 casos onde o desenvolvimento de uma fam lia de produtos realizado O objetivo desta pr tica separar os modelos t cnicos dos produtos daqueles da infraestrutura da fam lia de forma que ambos sejam mais reutiliz veis Esta a preocupa o central da abordagem ENG14 Simular modelos o objetivo desta pr tica avan ada de controle de qualidade garantir a qualidade dos elementos do MDD o mais r pido poss vel no ciclo de vida Simula o de modelos permite a verifica o do comportamento modelado de um sistema Requer a exist ncia de uma especifica o formal das a es em uma linguagem sem ntica de a es N o existem atividades espec ficas para simula o de modelos SUP5 Estabelecer e manter limites de desempenho de modelagem da organiza o a organiza o deve definir e manter os objetivos das atividades de modelagem e elementos de MDD utilizados de acordo com cada tipo particular de projeto Esta pr tica visa atender necessidade de alinhamento dos objetivos de neg cio da organiza o com os objetivos do projeto A abordagem n o tem nenhuma atividade similar a esta pr tica que exige um conhecimento sobre diferentes op es de processo para cada projeto cada um com um grau espec fico de automa o visando dosar o n vel de automa o em cada projeto PJ
64. digo Os autores tamb m prop em m tricas adicionais baseadas em modelos arquiteturais descritos segundo a vis o 4 1 KRUCHTEN 1995 O argumento que as m tricas cl ssicas mesmo sendo coletadas a partir dos modelos UML n o consideram as intera es entre as diferentes vis es como por exemplo a refer ncia a classes e m todos a partir de um diagrama de sequ ncia Por m a validade destas m tricas n o apresentada neste trabalho Nesta tese n o foi poss vel aplicar estas m tricas uma vez que elas 225 est o fixadas na UML e na vis o 4 1 n o sendo adequadas para DSLs Lange e Chaudron 2004 apresentam algumas regras e m tricas para avalia o de modelos UML considerando a sua completude e consist ncia Exemplos destas regras incluem objetos sem nome classes sem m todos interfaces sem m todos classes abstratas em diagramas de sequ ncia classes n o chamadas em diagramas de sequ ncia mensagens entre classes n o relacionadas entre outras que ajudam na avalia o e garantia da qualidade de modelos UML Para esta tese estas m tricas n o s o teis uma vez que n o podem ser usadas para compara o dos n veis de reutiliza o com e sem a aplica o de MDD conforme proposto na abordagem Em outro artigo Lange e Chaudron 2005 apresentam um modelo de qualidade para desenvolvimento de software baseado em UML Al m dos atributos de qualidade a serem avaliados como complexidade rastreabilidade m
65. do desenvolvimento da DSL Conforme discutido na Se o 3 1 2 uma DSL pode ser textual programas ou visual diagramas e normalmente composta de tr s elementos a sintaxe abstrata a sintaxe concreta e a sem ntica Esta atividade cuida do desenvolvimento das sintaxes abstrata e concreta da DSL al m de ferramentas que permitam a cria o de inst ncias programas ou diagramas da DSL Em DSLs textuais as sintaxes abstrata e concreta s o normalmente representadas atrav s de regras l xicas e gramaticais Em DSLs visuais a sintaxe abstrata corresponde ao metamodelo GUIZZARDI PIRES SINDEREN 2002 e a sintaxe concreta corresponde aos aspectos visuais dos elementos normalmente utilizando figuras cones linhas setas entre outras representa es gr ficas Para representar corretamente sua variabilidade um subdom nio pode exigir um sistema de conceitos sintaxes abstrata e concreta totalmente diferente da modelagem de features possivelmente exigindo tamb m uma ferramenta de modelagem mais complexa Mas mesmo n o sendo suficiente para identificar conceitos de uma DSL TOLVANEN KELLY 2005 um modelo de features pode servir de ponto de partida CZARNECKI 2005 sendo posteriormente complementado com informa es de outros artefatos como a arquitetura do dom nio e o conhecimento do especialista TOLVANEN KELLY 2005 O desenvolvimento de DSLs considerado uma ci ncia parte CZARNECKI EISENECKER 2000 dad
66. eles s o combinados Obviamente automatizar as transforma es n o uma tarefa simples A Figura 3 mostra Outros modelos Ferramenta de Modelo modelagem S os D 4 4 i i a i i i i i 4 Mecanismo para d executar transforma es C digo Transforma o fonte Ferramenta para definir transforma es Figura 3 Principais elementos do MDD Para possibilitar a cria o de modelos necess ria uma ferramenta de modelagem Utilizando essa ferramenta o engenheiro de software produz modelos que descrevem os conceitos do dom nio Para isto a ferramenta deve ser intuitiva e de f cil utiliza o 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 n o um ser humano capaz de corrigir pequenos enganos ou preencher lacunas por si s O elemento que implementa estas caracter sticas normalmente uma linguagem espec fica de dom nio ou DSL Domain Specific Language descrito no pr ximo cap tulo Os modelos servem de entrada para transforma es que ir o gerar outros modelos ou o c digo fonte Para definir as transforma es necess ria uma ferramenta que permita que o engenheiro de software construa regras de mapeamento de modelo para modelo ou de modelo para c digo Idealmente essa ferramenta deve possibilitar
67. es espec ficas da plataforma de execu o deixada para a etapa de implanta o somente n o ocorrendo na etapa de projeto como previsto pela MDA Segundo os autores isto traz uma s rie de benef cios tais como a facilidade de portar modelos independentes de plataforma e evita a necessidade de modelagem espec fica de plataforma complexa e pass vel de erros al m de tornar a l gica da aplica o realmente independente da plataforma Todas estas abordagens e ferramentas t m alto potencial para auxiliar no MDD mas da mesma maneira que no caso da reutiliza o o papel do processo fundamental para que as tentativas n o sejam fadadas ao fracasso Este o assunto da pr xima se o 14 Apesar de constar no nome desse projeto essa ferramenta n o baseada na linguagem QVT do OMG Onhttp umt qvt sourceforge net Onttp www alphaworks ibm com tech mtf http www openmdx org index html 53 2 2 3 O processo de desenvolvimento orientado a modelos N o existe um consenso com rela o s atividades de um processo de desenvolvimento orientado a modelos O mais pr ximo disto um modelo de maturidade denominado MDD Maturity Model MODELWARE 2006d Este modelo foi definido com base na experi ncia das diversas empresas e institui es de pesquisa envolvidas com o ModelWare uma iniciativa na rea do MDD descrita de forma mais detalhada no Cap tulo 9 Esse modelo define as principais pr ticas e elementos de proces
68. estes bot es est o localizados Quais s o seus tamanhos cores e eventos associados poss vel incluir atributos em modelos de features CZARNECKI HELSEN EISENECKER 2004b para expressar estas informa es Mas em termos do poder expressivo e facilidade de compreens o por parte dos especialistas uma DSL seria mais adequada neste caso Ds Tentar o caminho mais f cil primeiro quanto mais pr ximo um subdom nio estiver do lado da configura o de rotina do espectro de variabilidade mais f cil ser a implementa o de uma linguagem e transforma es para o mesmo Sempre que houver d vida com rela o caracteriza o da variabilidade no subdom nio o caminho mais f cil deve ser preferido isto com um wizard ou configura o de features Se estes se mostrarem insuficientes ent o uma DSL mais complexa pode ser desenvolvida 2 A sa da desta atividade a caracteriza o do tipo de variabilidade inerente a cada subdom nio Mais importante come a se a identificar quais subdom nios ir o requerer uma DSL dedicada Atividade ID 2 Defini o das DSLs e do suporte ferramental top down Pap is implementador do dom nio Especialista do dom nio Entradas PT 3 Validado Modelagem do dom nio PT 4 Validado Candidatos a subdom nio e PT 5 Hist rico de decis es sobre inclus o exclus o de subdom nios PT 9 Avaliado Projeto do dom nio PT 10 Subdom nios caracterizados Sa das PT JlInicial Lingu
69. fica de dom nio pode ser textual permitindo especificar programas ou visual permitindo especificar modelos ou diagramas e normalmente possui tr s elementos a sintaxe abstrata a sintaxe concreta e a sem ntica A sintaxe abstrata define os conceitos do dom nio e as rela es e restri es que se aplicam a estes conceitos Em linguagens textuais representada por uma rvore chamada Uma discuss o mais aprofundada sobre DSLs e seu papel na reutiliza o apresentada no Ap ndice A 61 de AST ou Abstract Syntax Tree que armazena as palavras do vocabul rio da linguagem e seu agrupamento v lido em forma de senten as Em linguagens de modelagem corresponde ao metamodelo que define a estrutura dos modelos que podem ser criados GUIZZARDI PIRES SINDEREN 2002 Uma vez que este metamodelo uma especifica o de uma conceitualiza o do dom nio pode ser considerado uma ontologia KURTEV et al 2006 A sintaxe concreta prov um sistema para representar os conceitos do dom nio de forma concreta Consiste de s mbolos que podem ser caracteres organizados em palavras segundo uma gram tica bem definida linguagem textual ou cones gr ficos com caracter sticas visuais que representam diferentes atributos como cor posi o tamanho e forma linguagem visual GUIZZARDI PIRES SINDEREN 2002 Trata se de uma representa o superficial que pode ser diferente da representa o interna que obtida com a
70. forma simples e com pouco esfor o seguindo o princ pio de que se for mais trabalhoso reutilizar do que construir a reutiliza o n o ir acontecer 3 Separa o de interesses separa o entre variantes e c digo comum de forma que mudan as podem ser feitas separadamente em ambos os c digos 4 Desempenho a implementa o deve proporcionar desempenho do produto final de acordo com os requisitos 5 Diferentes tipos de c digo fonte os mecanismos normalmente citados na literatura s o fortemente atrelados a uma linguagem de programa o e normalmente utilizam conceitos de orienta o a objetos Por m padr es de projeto heran a polimorfismo e orienta o a aspectos entre outros exemplos fazem pouco sentido em artefatos como p ginas HTML scripts de cria o de banco de dados arquivos de configura o stored procedures entre outros tipos de artefatos de implementa o que n o s o baseados em uma linguagem de programa o Obviamente ainda poss vel algum tipo de controle como por exemplo a extens o de uma p gina HTML com scriptlets que implementam a inclus o condicional de partes de texto correspondentes a variantes espec ficas Por m esta op o mais indicada para varia es em tempo de execu o n o sendo adequada para as varia es em tempo de compila o que o foco desta tese Como resultado nestes casos faz se necess rio o gerenciamento manual da variabilidade e 6 Variabi
71. ganhos diretos em termos de tempo de desenvolvimento a abordagem generativa tamb m promove a reutiliza o Um gerador encapsula o conhecimento do dom nio necess rio para que sejam produzidos artefatos ou mesmo aplica es completas daquele dom nio Em outras palavras a reutiliza o desse conhecimento ocorre quando se reutiliza o processo de gera o e n o os componentes SAMETINGER 1997 Um elemento necess rio para a abordagem generativa o formato da entrada fornecida a um gerador Normalmente utiliza se uma DSL ou seja uma linguagem especializada e orientada ao problema CZARNECKI EISENECKER 2000 Desta forma o desenvolvedor pode criar as especifica es de forma mais pr xima ao problema o que exige um menor esfor o de especifica o Essa DSL pode ser t o especializada quanto o necess rio para o problema sendo modelado nttp msdn microsoft com vstudio http www netbeans org 264 Por exemplo para modelar um produto matem tico a DSL precisa ser bem espec fica com elementos formais que permitam representar conceitos matem ticos Outro exemplo o caso de um editor de interfaces onde a DSL visual sendo composta dos elementos b sicos de uma interface como bot es caixas de texto barras de rolagem entre outros Pode se tamb m utilizar templates como entrada para um gerador Um template consiste em uma estrutura pr definida que representa o artefato final semi conclu do com p
72. gerado todos os artefatos permaneceram dentro do limite que indica simplicidade 10 A Figura 38 analisa de forma mais aprofundada os ndices de manutenibilidade obtidos com a abordagem N o existem diferen as not veis na distribui o por m h uma leve queda 195 Instabilidade de M dulo com Abordagem 1 200 1 000 0 800 fi 0 600 0 400 0 200 0 000 C digo nao gerado C digo gerado Artefatos gera o Modelos ql 0 286 0 500 0 333 0 500 Amin 0 000 0 375 0 000 0 500 4 mediana 0 432 0 500 0 333 0 500 m dia 0 522 0 590 0 373 0 500 x max 1 000 1 000 0 944 0 500 LE 0 750 0 625 0 333 0 500 Figura 36 Distribui es de instabilidade de m dulo nos diferentes tipos de artefatos produzidos com a abordagem no dom nio de aplica es distribu das baseadas em computa o em nuvem 14 000 Complexidade Ciclom tica com Abordagem 12 000 A 10 000 8 000 6 000 lt 4 000 i 2 000 Z 0 000 z z f 2 000 x s m C digo n o gerado C digo gerado Artefatos gera o Modelos Hai 1 113 1 200 1 000 0 000 Amin 1 000 1 000 1 000 0 000 mediana 1 600 3 644 3 000 0 000 m dia 2 128 4 673 2 524 0 357 max 6 845 12 714 6 000 2 000 3 2 800 7 420 4 000 0 750 Figura 37 Distribui es de complexidade ciclom tica nos diferentes tipos de artefatos produzidos com
73. gerenciamento dessa diversidade dentro de um dom nio Na realidade ambas as abordagens s o de certa forma complementares Uma vez identificados os subdom nios pode se analisar onde o DBC deve ser utilizado e ent o aplicar as t cnicas propostas por Blois 2006 para mapear as suas caracter sticas e projetar esta parte 218 da arquitetura do dom nio utilizando uma tecnologia de componentes A integra o desses componentes com o restante do dom nio pode ent o ser realizada conforme definido nesta tese Alferez et al 2008 apresentam uma abordagem orientada a modelos para a engenharia de requisitos em um contexto de linha de produtos Assim como na abordagem desta tese os autores defendem a id ia de que as features devem ser complementadas com modelos adicionais casos de uso e atividades para melhor representar a variabilidade Estes s o utilizados para representar o comportamento vari vel associado com diferentes features Em particular busca se refinar os modelos de caso de uso de forma que cada um esteja associado a somente uma feature visando facilitar e automatizar as tarefas de engenharia de requisitos durante a configura o de produtos Adicionalmente a rastreabilidade entre as features e os demais modelos de requisitos armazenada de acordo com um metamodelo dedicado Regras de composi o entre os casos de uso s o utilizadas para identificar os pontos de varia o de maneira similar ao conceito de casos de
74. inicial antes de uma determinada atividade e passar para o estado refinado ap s esta atividade e Pap is representam as pessoas que executam ou auxiliam na execu o das atividades Um papel descreve caracter sticas do indiv duo e n o o indiv duo em si de forma que uma mesma pessoa pode desempenhar v rios pap is e um papel pode ser desempenhado por v rias pessoas Por exemplo no papel de especialista do dom nio podem estar v rias pessoas cada uma com conhecimentos em pequenas partes do dom nio e e Diretrizes em alguns casos onde n o poss vel estabelecer passos expl citos para a execu o de uma atividade a abordagem define diretrizes que podem ajudar ou guiar a sua execu o Cada atividade identificada por uma sigla no formato AD X PD X ou ID X onde X um n mero sequencial e AD PD e ID representam An lise de Dom nio Projeto do Dom nio e Implementa o do Dom nio respectivamente Sub atividades s o identificadas incluindo se outro n mero sequencial como por exemplo AD 1 3 que identifica a terceira sub atividade da primeira atividade da fase de an lise de dom nio Da mesma forma cada produto de trabalho identificado por uma sigla no formato PT X onde X um n mero sequencial Caso um produto de trabalho tenha diferentes estados os mesmos s o indicados ap s a sigla como por exemplo PT 2 Inicial que representa o produto de trabalho 2 no estado Inicial Os produtos d
75. m analisado para propiciar melhor caracteriza o da reutiliza o que est ocorrendo A seguir s o apresentados os resultados para cada estudo de forma individual junto com uma discuss o geral sobre os resultados 8 4 Resultados e discuss o 8 4 1 Autoria de conte do para a Web A Figura 28 mostra os valores das m tricas de reutiliza o de software obtidas dos artefatos produzidos com e sem a abordagem Nota se um aumento significativo tanto na porcentagem de reutiliza o como na raz o de reutiliza o Tamb m pode se observar a redu o da porcentagem de reutiliza o n o desejada para zero Analisando se os dados verificou se que a porcentagem de reutiliza o obtida exclusivamente com gera o de c digo foi de 47 03 ou seja quase metade do c digo reutilizado prov m de um gerador Foi verificada uma raz o entre especifica o e c digo de 1 16 34 ou seja para cada elemento de especifica o s o geradas em m dia pouco mais de 16 linhas de c digo A Figura 29 mostra os valores das m tricas indiretas de reusabilidade instabilidade complexidade e manutenibilidade obtidas dos artefatos produzidos com e sem a abordagem Pode se verificar que n o houve altera o significativa nas distribui es da m trica de 189 Compara o das m tricas de reutiliza o 100 00 90 00 80 00 70 00 Porcentagem de reutiliza o n o desejada
76. mas que se desvinculou por n o mais se tratar de projeto incubado o openArchitectureWare Este projeto engloba ferramentas de modelagem textual transforma es de software e gera o de c digo baseada em templates al m de outra fun es pertinentes ao MDD O JET Java Emitter Templates POPMA 2004 consiste de um mecanismo de gera o de c digo baseado em templates CLEAVELAND 1988 Atrav s da inclus o de c digo Java dentro dos templates permite a metaprograma o ou seja a cria o de programas que criam programas Qualquer comando Java pode ser utilizado al m de uma s rie de marca es tags que implementam comandos condicionais de la os formata o entre outras fun es teis O JET pode ser acoplado a arquivos XML ou modelos EMF sendo portanto poss vel utiliz lo como gerador de c digo para uma DSL Finalmente um projeto que merece aten o nessa linha o GMF Graphical Modeling Framework Esse projeto permite a defini o completa de um ambiente de modelagem para uma linguagem visual espec fica para um determinado dom nio A partir da defini o do metamodelo da linguagem da apar ncia gr fica dos elementos visuais dessa linguagem nota o e das ferramentas necess rias para a cria o dos elementos gerado um ambiente completo que permite que o engenheiro de software construa modelos segundo a linguagem e nota o definidos 2 2 2 4 Outras abordagens A Vanderbilt Un
77. mesmo que n o tenham sido efetivamente reutilizados no seu maior potencial nestes estudos Assim a quest o Q2 busca avaliar este aspecto O objetivo G2 diz respeito tese de que a utiliza o do MDD exige uma preocupa o que deve estar presente em todo o ciclo de vida devendo ser tratada de forma consistente desde a an lise at a implementa o Assim a quest o Q3 se refere obten o de algum benef cio observ vel com a aplica o da abordagem desde o in cio A quest o Q4 busca identificar se a utiliza o do MDD desde o in cio traz mais problemas do que benef cios Nesta avalia o o projeto desenvolvido sem a abordagem consistiu na aplica o dos conceitos de reutiliza o de software de forma ad hoc Foram produzidos componentes de software reutiliz veis e uma arquitetura de refer ncia para o dom nio por m sem a execu o de atividades espec ficas de um m todo voltado reutiliza o Nos tr s casos a implementa o obtida pelo desenvolvimento sem a abordagem foi aproveitada durante a atividade de desenvolvimento da implementa o de refer ncia Desta forma o c digo final obtido com e sem a abordagem foi praticamente o mesmo 8 1 1 Coleta de dados Para a obten o de dados que possam conter ind cios ou evid ncias sobre estas quest es foram definidas formas qualitativas e quantitativas de coleta de dados combinando a percep o subjetiva dos envolvidos nos estudos emp ricos com medidas re
78. modificando a para satisfazer aos requisitos Ap s o contato inicial foi estabelecido que o estudo seria realizado como um projeto paralelo na empresa por uma equipe composta de dois funcion rios com dedica o parcial com o aux lio e orienta o do autor desta tese Como neste estudo o autor n o participaria do desenvolvimento foi necess rio um per odo de treinamento realizado da seguinte forma e Em um primeiro momento um dos participantes do projeto realizou um curso de 20 horas sobre desenvolvimento orientado a modelos oferecido no ICMC USP S o Carlos e ministrado pelo autor desta tese e Em seguida o autor da tese realizou um treinamento interno de 4 horas com os participantes apresentando as atividades e detalhes da abordagem e e O autor da tese disponibilizou como exemplo os documentos e artefatos produzidos durante o estudo do dom nio Web que ficou disposi o da equipe para consulta Ap s este per odo o autor desta tese permaneceu dispon vel para sanar d vidas e responder questionamentos durante todo o projeto uma vez que se tratam de conceitos novos para a empresa e os participantes 2O material deste curso encontra se dispon vel no endere o http www icmc usp br lucredio downloads files cursoMDD 186 Ap s o treinamento a equipe utilizou a abordagem para realizar a an lise projeto e implementa o do dom nio Uma vez que j existia a linha de produtos implantada na empresa
79. momento da implementa o seja identificado um detalhe n o previsto durante o projeto Assim deve se tamb m avaliar a aplica o de um novo padr o neste ponto para facilitar sua sele o no futuro D3 Para features alternativas modificar o exemplo para considerar a presen a de cada alternativa separadamente e em diferentes combina es O uso de padr es destacado pela diretriz D2 tamb m deve ser considerado para este tipo de feature D4 Prestar aten o s depend ncias entre as features Por exemplo se uma feature A depende de outra feature B n o faz sentido implementar A sem a presen a de B Ds Adotar uma abordagem de configura o em est gios CZARNECKI HELSEN EISENECKER 2004b tentando eliminar as variabilidades em uma sequ ncia l gica considerando primeiro as features mais comuns para reduzir o n mero de possibilidades e o n mero de vers es produzidas a cada refinamento Dg Dar maior aten o s variabilidades que possuem maior impacto na arquitetura aquelas que s o mais frequentes e aquelas que exigem mais esfor o para implementar manualmente D7 Para reduzir o n mero de vers es da implementa o de refer ncia e facilitar o seu gerenciamento pode se implementar m ltiplas variantes simultaneamente desde que n o interfiram uma com a outra Dg Nem todas as possibilidades precisam ser exploradas e implementadas no in cio Algumas podem ser postergadas para quando a implementa
80. mudan as utilizado nesta tese Uma regra de composi o identifica o que muda em termos de comportamento de um caso de uso para outro Como cada caso de uso est associado a uma feature e as features s o rastre veis aos casos de uso e modelos derivados estas regras permitem a gera o autom tica dos modelos de requisitos de acordo com as features selecionadas para um determinado produto Nesta tese a variabilidade dos cen rios representada por meio de casos de mudan a que constituem cen rios isolados e n o informa es sobre o que muda de um cen rio para outro Apesar de n o possibilitar a automa o como no caso da abordagem de Alferez et al 2008 o uso de cen rios individuais facilita a sua utiliza o como diretrizes arquiteturais e a avalia o arquitetural Foi por este motivo para facilitar o projeto arquitetural que a abordagem de casos de mudan a foi adotada nesta tese Outra diferen a que a abordagem de Alferez et al 2008 busca aplicar MDD para gera o de modelos de requisitos para serem utilizados na fase de desenvolvimento de aplica es sendo portanto mais completa no contexto de linhas de produtos Nesta tese o foco somente na engenharia de dom nio sendo que a fase de desenvolvimento de aplica es n o abordada Por este motivo o uso do MDD se restringe somente gera o de implementa o n o passando pelos passos anteriores de an lise e projeto das aplica es O trab
81. na abordagem que tem atividades para que o metamodelo seja centrado na arquitetura ENG Desenvolver metamodelo independente de plataforma a abordagem n o est focada em um tipo espec fico de modelo e portanto pode ser utilizada para desenvolver metamodelos independentes de plataforma ENG10 Desenvolver modelo de neg cios a abordagem n o est focada em um tipo espec fico de modelo e portanto pode ser utilizada para desenvolver modelos de neg cio ENGI1 Desenvolver transforma es modelo para modelo as transforma es modelo para modelo est o previstas na abordagem como uma forma de organiza o e estrutura o dos geradores de c digo ENG13 Integrar desenvolvimento de produto com desenvolvimento de infraestrutura para uma fam lia de produtos esta a preocupa o central da abordagem ENGIS5 Desenvolver linguagens espec ficas de dominio a abordagem possui uma atividade espec fica para o desenvolvimento de DSLs no contexto da reutiliza o Conforme pode ser constatado em termos de reutiliza o a abordagem cobre principalmente as pr ticas de engenharia incluindo an lise projeto e implementa o do dom nio al m de algumas pr ticas de gerenciamento isoladas como planejamento e defini o de objetivos Considerando se este modelo a presente abordagem n o garante que uma organiza o atinja um n vel maior do que o n vel 1 de maturidade Em termos de MDD a
82. ncias ao modelo de features P Quais foram as dificuldades para a identifica o de candidatos a subdominio R Uma vez que o modelo de features estava finalizado a equipe rapidamente identificou candidatos a subdom nio com base em sua experi ncia de atendimento a chamados dos clientes Essa base hist rica de uso dos sistemas incluindo experi ncias e chamados t cnicos registrados com detalhes de intera o com cliente foi importante para essa identifica o Assim n o foram relatadas dificuldades nesta etapa P Quais foram as dificuldades para realizar o processo investigativo baseado em decis es para inclus o exclus o de subdom nios R A equipe n o chegou a realizar mais de uma itera o neste processo tendo optado por incluir dois subdom nios em uma nica itera o Portanto n o soube responder esta quest o de forma adequada P Cite outras dificuldades percebidas durante a utiliza o da abordagem de MDD desde o in cio do desenvolvimento R A equipe tamb m citou as dificuldades referentes opera o do ambiente de desenvolvimento uma vez que n o existe muita documenta o a respeito destas tecnologias
83. nio n o era suficiente Ap s algumas itera es por m o subdom nio de navega o foi considerado confi vel o suficiente para iniciar a produ o que culminou com sua passagem para o n vel Dg J o subdom nio de busca ap s investiga o foi considerado exclu do passando para o n vel D4 O subdom nio de conte do de usu rio apresentou um baixo n vel de confian a inicial e portanto permaneceu no n vel D2 para investiga o posterior Assim que todos os outros subdom nios terem sido investigados e terem sua situa o definida este subdom nio entrou em investiga o no n vel D3 Mas ap s investiga o concluiu se que o mesmo tamb m deveria ser exclu do terminando no n vel Dj Ao final dessa evolu o o dominio passa a contar com os subdom nios de cadastros e navega o Ap s a tomada de decis o para todos os candidatos a subdom nio o analista do dom nio deve lidar com a sobreposi o entre eles Neste ponto s poss vel determinar se dois subdom nios ir o interferir um com o outro analisando se eles possuem features em comum Mesmo que n o existam features em comum pode ser que os artefatos gerados para um subdom nio interfiram ou tenham impacto nos artefatos de outro subdom nio E n o poss vel determinar isto sem aprofundar se no projeto e implementa o Al m disso mesmo que n o exista sobreposi o de subdom nios em nenhum n vel ainda assim a automa o de um subdom nio p
84. o inicial de investiga o de dois subdom nios sem que os 285 demais pudessem ser investigados P O uso das diretrizes e padr es arquiteturais espec ficos para reutiliza o e MDD facilitou o desenvolvimento dos artefatos do MDD e da arquitetura do dom nio R A equipe reportou dificuldades na constru o de geradores de c digo e sua integra o ao restante da arquitetura Por m eles citaram que os padr es de camada de dados de features e a abordagem de visita baseada em templates foram muito teis nesta tarefa A equipe tamb m reportou que a identifica o das diretrizes de variabilidade baseada em features de forma isolada para cada subdom nio facilitou o desenvolvimento da camada de dados de features utilizada pelos geradores espec ficos A unifica o de arquivos de configura o para instala o em um modelo inicial que prev inclusive usu rios iniciais para a aplica o foi relatado como grande facilitador para gerenciar a instala o do pacote que agora pode ser feita por integrantes da equipe menos experientes que ver o no modelo reutiliz vel uma forma de trabalho mais f cil Antes a instala o dependia de engenheiros experientes no dom nio e an lise de trechos de c digo em v rios arquivos com busca e altera o dos mesmos que quando n o era feita de forma ideal trazia problemas aos clientes P A etapa de avalia o arquitetural ajudou a identificar falhas antes de a implementa o ser inicia
85. o refinamento for mais conceitual altera es na sintaxe concreta quando o refinamento envolver a representa o f sica dos conceitos ou altera es no suporte ferramental produzido Deve se tamb m tomar cuidado para que n o sejam introduzidas inconsist ncias principalmente quando a DSL sendo refinada possui intera es com outras DSLs e outros artefatos do dom nio Por isso deve se retornar atividade ID 2 e refazer seus passos visando manter o refinamento consistente Sub atividade ID 3 4 Desenvolvimento das transforma es e geradores de c digo Com o refinamento das DSLs o implementador constr i geradores de c digo baseados em templates Se o 3 2 2 Para isso ele realiza um processo conhecido como migra o de c digo onde o c digo da implementa o de refer ncia anotado com marca es especiais como tags e scriptlets que fazem a associa o entre o c digo e a DSL Cada trecho de c digo correspondente a alguma variabilidade identificado na sub atividade ID 3 2 recebe algum tipo de anota o Tags normalmente d o suporte a comandos mais simples do tipo condicional ou iterativo 160 Por exemplo pode se embutir o c digo referente a uma feature opcional dentro de uma tag do tipo condicional que aceita como par metro um tipo booleano em uma DSL que indica a presen a ou aus ncia da feature Especificando se este par metro com o valor VERDADEIRO faz com que o gerador inclua aquele trecho de c d
86. o s o estabelecidos SUP5 visando adequar os esfor os de acordo com as caracter sticas de cada projeto N vel 5 MDD Definitivo neste ltimo n vel todo o conhecimento da organiza o mantido na forma de modelos e transforma es que s o o foco do processo de desenvolvimento Pr ticas para o desenvolvimento de linguagens espec ficas de dom nio ENGI5 e a verifica o e valida o de produtos ENG16 s o complementadas com pr ticas para estabelecer e manter artefatos de modelagem de software estrat gicos para o MDD PJM6 e promulgar o modelo de processo do projeto PJMB8 tornando o desenvolvimento mais control vel Algumas dessas pr ticas est o intimamente relacionadas com a abordagem desta tese conforme descrito no Cap tulo 4 55 2 3 Considera es finais Neste cap tulo foram discutidos os principais conceitos e t cnicas da reutiliza o de software e do desenvolvimento orientado a modelos Enquanto as t cnicas para reutiliza o buscam aproveitar ao m ximo o que j existe em termos de artefatos de software produzidos anteriormente o desenvolvimento orientado a modelos busca elevar o n vel de abstra o no qual o desenvolvedor trabalha escondendo detalhes da plataforma de implementa o e empregando as habilidades de automa o do computador para ajudar nas tarefas de tradu o entre problema e solu o e nas tarefas repetitivas Estas t cnicas formam um conjunto de ferramentas com pot
87. para o seu problema e Integra o a integra o n o um problema quando um gerador produz um programa completo KRUEGER 1992 Por m nos casos onde apenas parte dos artefatos gerada necess rio que os mesmos sejam integrados com outras partes sejam estas geradas automaticamente ou manualmente Para que essa integra o seja autom tica os geradores precisam estar preparados e cientes do ambiente ao qual os artefatos gerados ser o integrados Desta forma os desenvolvedores podem trabalhar somente no n vel de abstra o da entrada do gerador especificando o que for necess rio para que o gerador possa realizar essa integra o sozinho Por m essa a situa o ideal Em outros casos a nica solu o modificar manualmente os artefatos gerados de forma a promover sua integra o 266 Vale a pena ressaltar que os conceitos de programa o generativa principalmente quando se pensa em reutiliza o de software muitas vezes se confundem com os conceitos ligados s linguagens espec ficas de dom nio Czarnecki e Eisenecker 2000 autores de um dos principais livros sobre programa o generativa destacam a import ncia das DSLs nessa abordagem Cleaveland 1988 utiliza os termos Linguagem de quarta gera o e Linguagem orientada aplica o ao inv s de DSL mas os conceitos de geradores de aplica es que ele apresenta correspondem a um compilador DSL DEURSEN KLINT VISSER 2000 A proxi
88. para problemas recorrentes de forma que ao se deparar com uma situa o similar vivida originalmente um desenvolvedor possa aplicar a mesma solu o obtendo os mesmos resultados que o criador do padr o Neste sentido o objeto da reutiliza o o conhecimento obtido na solu o desse problema recorrente Os quatro conceitos b sicos da reutiliza o est o tamb m presentes nessa t cnica 268 Abstra o a abstra o ocorre quando as solu es recorrentes s o generalizadas e representadas segundo um formato espec fico Existem alguns formatos para descri o de padr o que s o mais comumente utilizados destacando se aquele utilizado em GAMMA et al 1995 Normalmente essa descri o cont m uma descri o do problema de forma que um desenvolvedor possa decidir se esse padr o adequado ao seu problema ou n o Sele o a sele o ocorre quando o desenvolvedor procura por um padr o por meio da compara o do problema descrito no padr o e o problema sendo vivenciado por ele no momento Esse processo normalmente manual exigindo uma consulta a cat logos de padr es tal como o cat logo online hillside net Adapta o a adapta o consiste na instancia o do padr o adaptando o para a situa o atual Os elementos do padr o s o normalmente gen ricos precisando ser renomeados ou mesmo modificados e Integra o a integra o exige a adapta o do restante do sistema ou do projeto par
89. pode conter inconsist ncias 2 Validado planejamento verificado em busca de inconsist ncias e erros PT 2 Mapa de aplica es Documento que mapeia todas as aplica es do dom nio e suas respectivas features 1 Inicial vers o inicial do mapa pode conter inconsist ncias 2 Validado mapa verificado em busca de inconsist ncias e erros PT 3 Modelagem do dom nio Documento que detalha as features do dom nio especificando tipos e relacionamentos Tamb m cont m os casos de uso do dom nio e informa es sobre os subdom nios seus 1 Inicial vers o inicial da modelagem pode conter inconsist ncias 2 Validado modelagem verificada em busca de inconsist ncias e erros PT 4 Candidatos a subdominio Documento listando os subdom nios as features correspondentes e as listas de linguagens de modelagens e ferramentas espec ficas para os subdom nios 1 Inicial vers o inicial do documento pode conter inconsist ncias 2 Validado documento verificado em busca de inconsist ncias e erros PT 5 Hist rico de decis es sobre inclus o exclus o de subdom nios Documento que registra as decis es sobre inclus o exclus o dos subdom nios nas diferentes itera es do processo Nenhum Quadro 9 Descri o dos produtos de trabalho da fase de an lise de dom nio variabilidades e comunalidades tanto em termos de features que descrevem as variabilidades est tic
90. por m o desenvolvimento ainda n o foi iniciado e aplica es potenciais aplica es para as quais ainda n o existem requisitos definidos mas que s o vistas como relevantes Ap s a identifica o das aplica es a lista de features desenvolvida A identifica o de features envolve abstrair o conhecimento obtido com os especialistas do dom nio e outros documentos tais como livros manuais de usu rio documentos de projeto e c digo fonte LEE KANG LEE 2002 Por m o volume de informa o de um dom nio tende a ser muito grande Neste sentido quatro diretrizes ALMEIDA et al 2006 podem ser teis D Analisar as terminologias usadas no dom nio para identificar features em alguns dom nios mais maduros especialistas normalmente utilizam terminologia padronizada para comunicar suas id ias necessidades e problemas Assim utilizando se os mesmos termos padr es na identifica o de features pode se acelerar a comunica o entre o analista do dom nio e os provedores de informa o especialista do dom nio e usu rios finais D2 Categorizar as features as features devem ser categorizadas utilizando por exemplo as quatro categorias descritas na Se o 3 1 1 features de capacita o features de tecnologia do dom nio features de t cnicas de implementa o e features do ambiente operacional Para organiza es com pouca experi ncia na an lise de dom nio ou que est o trabalhando com dom nios ins
91. porque depende da exist ncia de c digo que marca os locais onde o c digo manual come a e onde termina Se este c digo for removido por alguma raz o o c digo manual pode ser perdido ap s a regenera o Assim t cnicas de merging somente devem ser utilizadas quando estritamente necess rias e de prefer ncia com mecanismos que protegem o c digo manual de modifica es acidentais WARMER KLEPPE 2006 As melhores t ticas para evitar esta situa o incluem a gera o de classes abstratas ou interfaces e a utiliza o de subclasses para implementar as partes faltantes T cnicas como as receitas recipes do openArchitectureWare que consistem na exibi o de avisos sobre os passos a serem seguidos para completar o c digo podem ajudar a garantir uma implementa o manual correta Um padr o til nestas situa es chamado merging de geradores A t tica por tr s deste padr o criar um modelo separado para a especifica o das partes faltantes e ent o combinar estes modelos utilizando um gerador espec fico A Figura 23 ilustra a id ia Modelos estruturais Classes completamente geradas q estes p p comportamento Modelos de comportamento ou trechos de c digo fonte Figura 23 Merging de geradores envolvendo modelos estruturais e comportamentais Neste exemplo dois tipos de geradores para modelos estruturais e de comportamento s o combinados para produ
92. quais as mesmas procuram dar suporte UHL 2003 O fato software se tornou um artefato muito complexo Ainda n o t o complexo 22 ao ponto de n o sermos mais capazes de constru lo mas o esfor o necess rio para tanto utilizando tecnologias centradas em c digo fonte muito grande KLEPPE WARMER BAST 2003 FRANCE RUMPE 2007 Nas palavras de France e Rumpe 2007 este esfor o chega a ser herc leo construir sistemas de software complexos de forma manual pode ser equiparado a construir pir mides no antigo Egito N s nos maravilhamos com tais implementa es de software de forma bastante parecida com a qual arque logos se maravilham com as pir mides essa admira o principalmente baseada na aprecia o do esfor o requerido para se lidar com as significativas complexidades acidentais que surgem do uso de tecnologias inadequadas A proposta do MDD Model Driven Development ou Desenvolvimento Orientado a Modelos justamente resolver esses problemas enfatizando a import ncia de modelos no processo de desenvolvimento de software MELLOR CLARK FUTAGAMI 2003 No MDD os modelos n o s o apenas papel que auxiliam nas tarefas de desenvolvimento Ao inv s disso eles s o parte constituinte do software assim como o c digo A proposta reduzir a dist ncia sem ntica entre o dom nio do problema e o dom nio da implementa o solu o atrav s de modelos de alto n vel que protegem os desenvo
93. que as regras de mapeamento sejam constru das da forma mais natural poss vel uma vez que a constru o de transformadores uma 45 tarefa complexa 2 Finalmente necess rio um mecanismo que efetivamente aplique as transforma es definidas pelo engenheiro de software Esse mecanismo deve n o s executar as transforma es mas tamb m manter informa es de rastreabilidade possibilitando saber a origem de cada elemento gerado seja no modelo ou no c digo fonte Atualmente existem diversos trabalhos que buscam melhor definir o papel de todos esses elementos A seguir s o apresentadas as principais abordagens existentes na ind stria para possibilitar o desenvolvimento orientado a modelos 2 2 2 Principais abordagens da ind stria para MDD Para dar suporte a diferentes linguagens de modelagem ajudar a garantir que os modelos constru dos estejam semanticamente corretos e completos e possibilitar a defini o e execu o de transforma es gen ricas as principais abordagens existentes na ind stria para MDD se baseiam no conceito de metamodelagem OMG 2006b apresentado na Figura 4 M3 r Meta metamodelo Legenda MOF lt lt metametaclasse gt gt lt inst ncia de MetaClasse ESSES CA E SA M2 Metamodelo lt lt metaclasse gt gt UML Classe es a a M Metadados ou Produto Cliente modelo 1 1 MO Figura 4 Arquitetura cl ssica de metamodelagem O primeiro nivel MO corr
94. que envolvem todo o escopo de um dom nio ou sistema Al m disso padr es arquiteturais normalmente s o escolhidos e utilizados conforme requisitos n o funcionais como desempenho ou confiabilidade Normalmente inicia se com padr es arquiteturais que definem a macro estrutura do dom nio at chegar em padr es menores que resolvem problemas mais espec ficos de partes do dom nio Al m disso um padr o arquitetural implementa uma ou mais t ticas que por sua vez tem o objetivo de alcan ar um ou mais atributos de qualidade BASS CLEMENTS KAZMAN 2003 Uma t tica descreve uma estrat gia a ser utilizada para se alcan ar um determinado atributo de qualidade Assim para cada diretriz arquitetural seleciona se uma ou mais t ticas e em seguida s o selecionados os padr es para implementar estas t ticas Uma lista de t ticas apresentada por Bass Clements e Kazman 2003 por m esta n o inclui t ticas para lidar com variabilidade em um dom nio nem com a integra o entre subdom nios automatizados como o caso desta abordagem Sub atividade PD3 3 Para implementar as t ticas existe uma grande quantidade de fontes de padr es e estilos arquiteturais Vale destacar a s rie de cinco volumes conhecida como POSA Pattern Oriented Software Architecture BUSCHMANN et al 1996 SCHMIDT et al 2000 KIRCHER JAIN 2003 BUSCHMANN HENNEY SCHMIDT 2007a 2007b que apresenta diversos padr es voltados para diferentes tipos
95. rea de reutiliza o apresenta solu es baseadas em c digo fonte Neste contexto dentre as principais t cnicas para implementa o da variabilidade destacam se as seguintes conforme citam Matos Jr 2008 Anastasopoulos e Gacek 2001 Muthig e Patzke 2003 e Compila o condicional consiste na marca o de c digo com diretrizes de pr processamento para incluir ou excluir trechos de c digo de acordo com a presen a ou aus ncia de uma variante E um mecanismo simples por m muito poderoso e robusto presente em grande parte das linguagens de programa o atuais e Heran a um mecanismo de linguagens orientadas a objetos consistindo na cria o de um tipo abstrato que representa o ponto de varia o e diversos tipos concretos cada um sendo uma alternativa Por m utilizando se heran a simples somente uma alternativa pode estar presente em um determinado produto Nestes casos o uso de Mixins heran a m ltipla ou heran a parametrizada pode ajudar e Agrega o delega o esta t cnica consiste em repassar requisi es entre objetos 64 caso um deles n o seja capaz de atender a uma requisi o A variabilidade pode ser implementada desta forma incluindo uma funcionalidade padr o ou mandat ria em um objeto e uma funcionalidade variante em outro objeto a ser delegado Esta t cnica funciona com features opcionais mas apresenta problemas para alternativas j que necess rio decidir para quais ob
96. replicado aqui na Figura 14 cont m duas features principais navega o e administra o A navega o feature mandat ria consiste no conte do vis vel ao usu rio e busca autom tica que pode ser simples e ou avan ada features alternativas do tipo or onde mais de uma alternativa pode estar presente A submiss o de conte do de usu rio opcional No lado da administra o a feature de autoria mandat ria representa as fun es de publica o do conte do Se existir conte do de usu rio este pode ou n o ser moderado a seta curva indica uma depend ncia entre modera o e conte do de usu rio Estas s o features de capacita o Se o 3 1 1 Dominio autoria web Navega o gt Administra o gt Busca Modera o ae tipo de busca Conte do de usu rio tipo de busca gt Busca Busca avan ada q E E con tipo de pagina g sp tipo de p gina gt Formul rio Figura 14 Modelo de features do dom nio web de autoria de conte do O que tamb m varia de aplica o para aplica o deste dom nio a estrutura da informa o tipos de documento e seus relacionamentos e como a mesma apresentada ao usu rio p ginas 117 e links Para representar esta variabilidade no lado inferior da figura est o as features de tecnologia do dom nio Se o 3 1 1 p ginas formul rios ou relat rios e links s o utilizados para exibir a informa o em
97. reposit rios para modelos e transforma es com o objetivo de promover a reutiliza o dos modelos e transforma es na organiza o reposit rios devem ser desenvolvidos e mantidos de forma que modelos e transforma es produzidos em um projeto podem ser reaproveitados em outros projetos A abordagem n o define nenhum tipo de reposit rio para o MDD SUP2 Definir t cnicas padronizadas de modelagem e crit rios de qualidade envolve a defini o de um padr o de modelagem para a organiza o que representa a evolu o das conven es de modelagem definidas no n vel 2 Tamb m envolve a defini o de crit rios de qualidade de modelos como completude de modelo consist ncia inter diagramas legibilidade etc A abordagem apenas cont m atividades passos e diretrizes sem definir t cnicas padronizadas ou crit rios de qualidade SUP3 Checar aplica o das pr ticas consiste em verificar se as pr ticas de modelagem e artefatos produzidos est o de acordo com as t cnicas de modelagem e crit rios de qualidade pr estabelecidos A abordagem n o define maneiras de controle sobre a aplica o de suas pr ticas SUP4 Definir m tricas padronizadas e procedimentos de coleta e an lise de dados envolve a defini o de m tricas para as atividades de modelagem para os modelos como coletar as m tricas e como analisar os dados A abordagem n o define nenhum tipo de m trica
98. rio de MetaDados MDSD Model Driven Software Development Desenvolvimento de Software Orientado a Modelos MD Acr nimo que abrange todas as abordagens de desenvolvimento de software orientadas a modelos MIC Model Integrated Computing Computa o Integrada por Modelos MOF Meta Object Facility Infraestrutura de MetaObjetos MTF Model Transformation Framework Framework de Transforma o de Modelos MVC Model View Controller Modelo Vis o Controlador oAW openArchitectureWare conjunto de ferramentas para desenvolvimento orientado a modelos OMG Object Management Group Grupo de Gerenciamento de Objetos OTAN Organiza o do Tratado do Atl ntico Norte PHP PHP Hypertext Preprocessor PHP Pr processador de Hipertexto PNRP Peer Name Resolution Protocol Protocolo de Resolu o de Nomes de Pares lacr nimo recursivo POSA Pattern Oriented Software Architecture Arquitetura de Software Orientada a Padr es PIM Platform Independent Model Modelo Independente de Plataforma PSM Platform Specific Model Modelo Espec fico de Plataforma PuLSE ProdUct Line Software Engineering Engenharia de Software de Linha de Produtos QVT Queries Views Transformations Consultas Vis es Transforma es RAS Reusable Asset Specifications Especifica es de Artefatos Reutiliz veis RMM Reuse Maturity Model Modelo de Maturidade em Reutiliza o RPC Reuse Capability Model Modelo de Capacita o em Reutiliza o RRM Re
99. software product lines Journal of Information and Software Technology v 46 n 8 p 535 546 2004 THOMAS D MDA Revenge of the modelers or uml utopia IEEE Software v 21 n 3 p 15 17 2004 TOLVANEN J P Making model based code generation work Embedded Systems Europe v 8 n 60 p 36 38 Aug Sept 2004 TOLVANEN J P Domain Specific Modeling How to Start Defining Your Own Language Feb 2005 Disponivel em lt http www devx com enterprise Article 30550 gt Acesso em 14 jun 2009 TOLVANEN J P KELLY S Modelling languages for product families A method engineering approach In Proceedings of the 1st OOPSLA Workshop on Domain Specific Visual Languages Tampa Bay USA S 1 Jyv skyl University Printing House Jyvaskyla Finland ISBN 951 39 1056 3 ISSN 0359 8470 2001 p 135 140 TOLVANEN J P KELLY S Defining domain specific modeling languages to automate product derivation Collected experiences In OBBINK J H POHL K Ed 9th International Software Product Line Conference SPLC Europe 2005 S 1 Springer 2005 Lecture Notes in Computer Science v 3714 p 198 209 ISBN 3 540 28936 4 TRACZ W Domain Specific Software Architecture DSSA pedagogical example ACM SIGSOFT Software Engineering Notes v 20 n 3 p 49 62 1995 TRASK B et al Using model driven engineering to complement software product line engineering in developing software defined radio components and applicati
100. trata se de um processo que consome cerca de 20 25 do tempo de desenvolvimento da implementa o de refer ncia e 11 causa duplica o de c digo pois apesar de ap s a primeira migra o ser poss vel descartar completamente a implementa o de refer ncia na pr tica isto n o ocorre devido s dificuldades de se trabalhar no n vel do gerador Como resultado s o mantidas tanto a implementa o de refer ncia como o gerador e continua se trabalhando com os dois artefatos Apesar de n o trivial a automa o mesmo que parcial seria a solu o para estes problemas Ainda n o existe uma solu o autom tica para migra o de c digo nas principais ferramentas do mercado e este um interessante tema para trabalhos futuros podendo ser realizados como um p s doutoramento na rea 10 4 Considera es finais Nesta disserta o apresentou se a tese de que o MDD pode aumentar e ou melhorar a reutiliza o de software em projetos de engenharia de dom nio descrevendo uma abordagem para esta finalidade e sua avalia o atrav s de estudos emp ricos A abordagem combina elementos de processo como atividades tarefas entradas e sa das com diretrizes e t cnicas auxiliares que guiam o desenvolvedor durante a engenharia de dom nio orientada a modelos A principal contribui o est em reconhecer a exist ncia de m ltiplos subdom nios cada um com seu potencial de automa o e em oferecer um m todo concreto pa
101. um navegador e tipos de documentos e relacionamentos descrevem a estrutura da informa o A maioria das features como a busca conte do de usu rio e modera o representa a variabilidade do tipo presente ausente que fica pr xima do lado da configura o de rotina no espectro de variabilidade Desta forma grande parte do suporte variabilidade pode ser conseguido somente atrav s de configura o com a ajuda de uma arquitetura bem projetada e um conjunto de componentes reutiliz veis Por m features como tipos de documentos e relacionamentos cont m variabilidades mais complexas para as quais todos os detalhes n o podem ser capturados somente com modelos de features pois estes s o muito gen ricos TOLVANEN KELLY 2005 Estruturas ou mecanismos mais ricos s o necess rios com mais poder expressivo capaz de capturar detalhes sobre os conceitos do dom nio seus relacionamentos e restri es Nestes casos poss vel simplesmente implementar manualmente o suporte a esta varia o que o que acontece no desenvolvimento tradicional Para isso um desenvolvedor utiliza suas habilidades de programador e uma linguagem de programa o possivelmente com a ajuda de uma biblioteca ou framework que facilite este trabalho criativo Mas no caso do MDD onde se deseja automatizar o suporte variabilidade a tecnologia escolhida normalmente uma linguagem espec fica de dom nio DSL pois ela pode complementar o model
102. um trabalho de mestrado e ou doutorado dependendo da sua abrang ncia e Colabora o no MDD o desenvolvimento orientado a modelos possui diferentes tarefas Inttp msdn microsoft com en us architecture blueprints aspx 232 que envolvem a participa o de m ltiplos membros de uma equipe tais como a an lise de features e a defini o de m ltiplas DSLs para diferentes dom nios Tamb m pode se citar a exist ncia de equipes distintas para trabalhar com a implementa o de refer ncia com as tecnologias de modelagem e os geradores de c digo Por m a determina o exata de onde a colabora o no MDD ocorre de maneira mais intensa visando esclarecer os pontos de flexibiliza o na comunica o e atividades da equipe que podem ser alcan ados ainda se mostram incipientes como indicado por Steffen et al 2007 Assim trabalhos futuros podem investigar a natureza desta colabora o incluindo possivelmente a considera o sobre desenvolvimento distribu do ou at mesmo os aspectos ferramentais envolvidos na colabora o Este poderia ser o tema de um trabalho de mestrado e ou doutorado dependendo da sua abrang ncia e Migra o autom tica de c digo o uso da implementa o de refer ncia como ponto de partida para o desenvolvimento de geradores traz uma s rie de benef cios Por m o processo de migra o de c digo necess rio neste mapeamento para os geradores apresenta dois problemas MUSZYNSKI 2005 i
103. uri jsp jstl core gt lt html gt lt head gt lt struts config gt lt form bean gt CREATE TABLE Map id INTEGER PK include demoextension h int AEECIsCreateInstance void ppObj ppObj NULL if Clsid AEECLSID jnz Rx 00 add b OF addc 0E mova 00 Figura 2 Ilustra o do processo de cria o 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 s o e Produtividade o tempo de desenvolvimento ser melhor aproveitado pois ser gasto na produ o de modelos de mais alto n vel Tarefas repetitivas podem ser implementadas nas transforma es poupando tempo e esfor o que podem ser despendidos em tarefas mais importantes Al m disso um nico modelo pode gerar uma grande quantidade e diversidade de c digo e Portabilidade um mesmo modelo pode ser transformado em c digo para diferentes plataformas e Interoperabilidade cada parte do modelo pode ser transformado em c digo para uma plataforma diferente resultando em um software que executa em um ambiente heterog neo por m mantendo a funcionalidade global Tamb m podem ser gerados adaptadores e conectores util
104. utilizado para simplificar a intera o entre c digo gerado e n o gerado Ao inv s de gerar c digo que usa m ltiplas classes e m ltiplos m todos uma nica classe Facade agrupa todas as classes e m todos em um nico ponto Isto n o somente torna as depend ncias mais expl citas mas tamb m promove alguma prote o contra mudan as no c digo n o gerado Dependendo do grau das mudan as pode n o ser necess rio modificar o gerador o que uma tarefa mais complexa e propensa a erros Adapta es menores podem ser feitas diretamente na classe Facade Para proteger o gerador de mudan as maiores no c digo gerado e algumas vezes simplificar o gerador o padr o Adapter GAMMA et al 1995 pode ser utilizado para coletar filtrar e ou preparar a informa o necess ria para o c digo gerado Mudan as mais simples como no formato de dados ou na assinatura dos m todos n o se propagam para o gerador C digo n o gerado depende de c digo gerado Isto acontece quando c digo n o gerado espera que um comportamento ou estrutura seja gerado completamente poss vel e algumas vezes necess rio esse tipo de padr o de integra o mas fazer com que um c digo n o gerado dependa diretamente de c digo gerado pode levar a problemas O programa pode n o compilar antes da gera o completa de c digo Objetos de exemplo podem ser manualmente criados temporariamente mas em geral isto adiciona um n vel a mais de dificuldade par
105. 02 8 7 C nsidera es MAIS hk Si RR SD Sig eae See a Re ta 204 9 Trabalhos relacionados 207 9 1 Abordagens orientadas a modelos para reutiliza o de software 207 9 2 Trabalhos relacionados com o uso de m tricas para MDD e reutiliza o 222 9 3 Co nsiderac es finais siirsin nce wr seule sedi oe Bday ego E cado Bade aa eR 226 10 Conclus es 227 10 1 Principais contribui es rs pe OO E E RR RR DA EES 221 10 2 a es aprendidas 6 20 eel ae GA pd ae po AR A ed Ah RO o e aa 228 10 3 Limita es e Trabalhos futuros c cccccccccclc ee 229 10 4 Considera es finais lccccccccccl ee 232 Refer ncias 235 Ap ndice A T cnicas para reutiliza o de software 253 Ap ndice B Rela o entre a abordagem e modelos de maturidade 271 Ap ndice C Reprodu o na integra da entrevista referente ao estudo emp rico envolvendo o dom nio de eventos cient ficos 283 19 1 Introdu o H duas d cadas Krueger 1992 colocou a reutiliza o de software como uma preocupa o constante para organiza es que buscam aumento na qualidade e produtividade em seu processo de desenvolvimento A qualidade pode ser melhorada por meio da reutiliza o de experi ncias comprovadas incluindo artefatos em diferentes n veis de abstra o produtos e processos Neste sentido tamb m ocorre um aumento na produtividade uma vez que essas experi ncias s o reaproveitadas evitando se a necessidade de constru las n
106. 189 199 ISBN 0 8186 7246 3 DOE D D BERSOFF E H The software productivity consortium SPC An industry initiative to improve the productivity and quality of mission critical software Journal of Systems and Software v 6 n 4 p 367 378 1986 Elsevier Science Inc New York NY USA D SOUZA D WILLS A Objects Components and Frameworks with UML The Catalysis Approach S 1 Addison Wesley 1999 Object Technology Series ECKLUND JR E F DELCAMBRE L M L FREILING M J Change cases Use cases that identify future requirements In Conference Proceedings of the OOPSLA 96 San Jose CA USA S 1 ACM Press 1996 p 342 358 ECLIPSE The Eclipse Modeling Framework EMF Overview S 1 Eclipse website 2005 ECLIPSE Eclipse Modeling Framework FAQ 2006 ENDRES A Lessons learned in an industrial software lab JEEE Software v 10 n 05 p 58 61 1993 ESSER R JANNECK J W A framework for defining domain specific visual languages In Proceedings of the 1st OOPSLA Workshop on Domain Specific Visual Languages Tampa Bay USA S 1 Jyvaskyla University Printing House Jyvaskyla Finland ISBN 951 39 1056 3 ISSN 0359 8470 2001 p 111 124 EZRAN M MORISIO M TULLY C Practical Software Reuse S 1 Springer 2002 FEILKAS M How to represent models languages and transformations In GRAY J TOLVANEN J P SPRINKLE J Ed 6th OOPSLA Workshop on Domain Specific Modeling DSM
107. 2 S 1 Springer Verlag 2003 Lecture Notes in Computer Science v 2591 p 313 329 MUTHIG D PATZKE T Implementing software product lines enhancing reusability by systematically selecting and applying variability mechanisms In Multikonferenz Wirtschaftsinformatik MKWI 2004 Band 1 E Learning Modelle Instrumente und Erfahrungen Software Produktlinien Communities in E Business Berlin Akademische Verlagsgesellschaft 2004 NAUR P RANDELL B Report on NATO Software Engineering Conference S 1 1968 247 NEIGHBORS J M Software Construction Using Components Tese Ph D Thesis University of California at Irvine 1980 NEIGHBORS J M Draco A method for engineering reusable software systems In BIGGERSTAFF T J PERLIS A J Ed Software Reusability Volume I Concepts and Models S 1 Addison Wesley 1989 p 295 319 OMG MDA Guide Version 1 0 1 S 1 2003 Disponivel em lt http www omg org gt Acesso em 14 jun 2009 OMG MOF 2 0 Query Views Transformations Final Adopted Specification S 1 2005 Disponivel em lt http www omg org gt Acesso em 14 jun 2009 OMG Catalog of UML Profiles Specifications 2006 Disponivel em lt http www omg org gt Acesso em 14 jun 2009 OMG Meta Object Facility Core Specification Version 2 0 S 1 2006 Disponivel em lt http www omg org gt Acesso em 14 jun 2009 OMG XML Metadata Interchange XMI Specification S 1
108. 2001 O objetivo final que ap s a engenharia de dom nio um desenvolvedor possa simplesmente configurar o produto desejado e acionar as transforma es que automaticamente geram uma implementa o v lida Assim esta fase de an lise tamb m tem como objetivo identificar subdom nios onde a automa o poss vel A abordagem aqui proposta uma evolu o do m todo descrito por Almeida et al 2006 A diferen a que aqui existe a preocupa o com a identifica o dos subdom nios onde a automa o poss vel e portanto a an lise e tratamento das variabilidades realizada de forma diferenciada com este objetivo em mente 5 2 Atividades da an lise de dom nio A an lise de dom nio come a com uma atividade de planejamento Atividade AD 1 que visa coletar informa es para decidir se vale a pena investir no dom nio e definir o escopo do dom nio a ser constru do Em seguida a modelagem do dom nio Atividade AD 2 cuida da cria o de modelos do dom nio que descrevem as fun es as comunalidades e variabilidades do mesmo A seguir feita a identifica o de poss veis subdom nios Atividade AD 3 88 visando determinar os locais onde poss vel a automa o atrav s das t cnicas do MDD A pr xima atividade cuida da valida o e documenta o do dom nio Atividade AD 4 reunindo as informa es dispon veis at o momento Por fim ocorre uma decis o sobre quais poss veis subdom nios i
109. 33 260 17 210 4 mediana 133 355 106 250 89 510 m dia 127 499 100 101 96 589 x m x 223 120 171 000 172 050 0q3 160 908 121 140 125 510 Figura 38 Distribui es do ndice de manutenibilidade nos diferentes tipos de artefatos produzidos com a abordagem no dom nio de aplica es distribu das baseadas em computa o em nuvem N mero de Atributos 45 000 N mero de Relacionamentos 30 000 40 000 xe 25 000 35 000 30 000 20 000 25 000 Cc O A 10 000 E 10 000 4 3 000 5 000 0 000 0 000 a Gera o Especifica o Gera o Especifica o Bgl 1 000 6 250 qi 11 500 1 250 Amin 0 000 0 000 Amin 2 000 0 000 4 mediana 3 000 8 500 4 mediana 15 000 4 000 m dia 3 500 9 357 m dia 16 188 4 643 max 13 000 25 000 X m x 41 000 12 000 q3 5 000 11 500 q3 20 000 6 000 Figura 39 Distribui es de n meros de atributos e relacionamentos nos modelos utilizados com a abordagem no dom nio de aplica es distribu das baseadas em computa o em nuvem raz o ainda maior entre especifica o e c digo 1 26 35 o que indica que os geradores est o sendo mais produtivos Por m enquanto no estudo anterior os artefatos de gera o de c digo e os modelos s o mais complexos do que o c digo aqui foi observado o efeito inverso O
110. 6 conference Nantes France s n 2006 ALMEIDA E S C R U I S E Component Reuse In Software Engineering In SL C E S A R e books 2007 cap 4 Software Reuse Processes The State of The Art p 81 100 ALMEIDA E S et al An experimental study in domain engineering In 33rd IEEE EUROMICRO Conference on Software Engineering and Advanced Applications SEAA Component Based Software Engineering Track S 1 s n 2007 p 93 100 ALMEIDA E S et al A systematic approach to design domain specific software architectures Journal of Software Academy Publisher v 02 n 2 p 38 51 2007 ALMEIDA E S et al RiSE project Towards a robust framework for software reuse In IEEE International Conference on Information Reuse and Integration IRI Las Vegas USA TEEE CMS 2004 p 48 53 ALMEIDA E S et al A survey on software reuse processes In IEEE International Conference on Information Reuse and Integration IRI 2005 Las Vegas USA IEEE CS Press 2005 p 66 71 ALMEIDA E S et al The domain analysis concept revisited A practical approach In 9th International Conference on Software Reuse ICSR Torino Italy Lecture Notes in Computer Science Springer Verlag 2006 v 4039 p 43 57 ALMEIDA E S et al Domain implementation in software product lines using OSGi In 7th International Conference on Composition Based Software Systems ICCBSS Madrid Spain s n 2008 p 72 81 AMBLER S W
111. A3 Sub atividade PD 3 2 Padr es arquiteturais para variabilidade baseada em DSLs Este tipo de variabilidade expresso em termos de uma DSL O desenvolvedor especifica um programa modelo que segue a sintaxe de uma DSL e um gerador produz c digo fonte automaticamente A variabilidade em uma DSL pode ser virtualmente tudo que pode ser definido em um metamodelo atributos verdadeiro falso ou strings listas tipadas e cole es enumera es e outros conceitos da orienta o a objetos podem ser utilizados para descrever o espa o de variabilidade Para consultar estas estruturas em um gerador constru es comuns maioria das linguagem de programa o como condi es e la os podem ser utilizadas Devido grande variedade destes tipos de variabilidade aqui n o se prop e nenhum tipo de padr o associado a um tipo particular de varia o como na se o anterior Ao inv s disso os padr es nesta categoria s o focados em como as ferramentas baseadas em DSL e geradores de c digo podem ser integrados arquitetura e aos geradores de c digo baseados em features Apesar destes padr es n o aparecerem na arquitetura da aplica o final eles podem ter impacto no sucesso do dom nio Afinal no MDD estes artefatos tamb m fazem parte da arquitetura do dom nio VOLTER GROHER 2007 e devem ser considerados durante o seu ciclo de vida Um primeiro padr o proposto denomina se camada fina de dados que facilita a 133 inte
112. Backus Naur CIM Computation Independent Model Modelo Independente de Computa o CVS Concurrent Versions System Sistema de Vers es 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 Specific Language Linguagem Especifica de Dominio ED Engenharia de Dominio 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 Gen rico GMF Graphical Modeling Framework Framework de Modelagem Gr fica GMT Generative Modeling Tools Ferramentas de Modelagem Generativas GPL General Purpose Language Linguagem de Prop sito Geral GQM Goal Question Metric M trica Objetivo Quest o GUI Graphical User Interface Interface Gr fica com o Usu rio 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 P ginas Servidoras Java LOC Lines Of Code Linhas De C digo 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 Reposit
113. Daniel Lucr dio Uma Abordagem Orientada a Modelos para Reutiliza o de Software USP S o Carlos SP Julho de 2009 Daniel Lucr dio Uma Abordagem Orientada a Modelos para Reutiliza o de Software Tese apresentada ao Instituto de Ci ncias Matem ticas e de Computa o ICMC USP como parte dos requisitos para obten o do t tulo de Doutor em Ci ncias Ci ncias de Computa o e Matem tica Computacional Orientadora Prof Dr Renata Pontin de Mattos Fortes INSTITUTO DE CI NCIAS MATEM TICAS E DE COMPUTA O UNIVERSIDADE DE S O PAULO USP S o Carlos SP Julho de 2009 Agradecimentos Agrade o minha orientadora Renata que me acolheu e orientou durante todos estes anos Al m dos diversos pap is que lhe cabem oficialmente sendo uma orientadora dedicada interessada e competente ela me ajudou muito dentro e fora do doutorado Obrigado tamb m 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 coment rios durante a defesa ajudaram a enriquecer muito este trabalho Agrade o tamb m s institui es que fizeram com que esta trajet ria fosse poss vel Estas incluem o ICMC USP por ter sido a minha casa durante estes anos Tamb m agrade o FAPESP CAPES e CNPq que em diversos momentos me ajudaram financeiramente Espero ter correspondido e continuar correspon
114. ELLUND A CZARNECKI K WASOWSKI A Guided development with multiple domain specific languages In ENGELS G et al Ed Model Driven Engineering Languages and Systems MoDELS 2007 S 1 Springer 2007 Lecture Notes in Computer Science v 4735 p 46 60 ISBN 978 3 540 75208 0 HETTEL T LAWLEY M J RAYMOND K Model synchronisation Definitions for round trip engineering In VALLECILLO A GRAY J PIERANTONIO A Ed Theory and Practice of Model Transformations ICMT 2008 S 1 Springer Berlin Heidelberg 2008 Lecture Notes in Computer Science v 5063 2008 p 31 45 HOLIBAUGH R et al Reuse where to begin and why In TRI Ada 89 Proceedings of the conference on Tri Ada 89 Pittsburgh Pennsylvania United States ACM Press 1989 p 266 277 ISAKOWITZ T KAUFFMAN R J Supporting search for reusable software objects IEEE Transactions on Software Engineering v 22 n 6 p 407 423 1996 JACKSON E K SCHULTE W Compositional modeling for data centric business applications In PAUTASSO C TANTER Eric Ed Software Composition S 1 Springer 2008 Lecture Notes in Computer Science v 4954 p 190 205 ISBN 978 3 540 78788 4 242 JACOBSON I GRISS M JONSSON P Reuse driven Software Engineering Business RSEB S 1 Addison Wesley 1997 JACOBSON I LINDSTROM F Re engineering of old systems to an object oriented architecture In OOPSLA 91 Conference pro
115. Esta pr tica consiste justamente na defini o desta abordagem e seus elementos AP7 An lise de dom nio envolve a sele o e defini o do dom nio an lise das aplica es existentes para identifica o das caracter sticas do dom nio defini o dos requisitos e escopo do dom nio identifica o e documenta o dos pontos vari veis e comuns e a identifica o e documenta o de restri es adicionais entre as caracter sticas do dom nio A abordagem possui uma fase espec fica para a an lise de dom nio voltada para o MDD Z AP8 Projeto de dom nio envolve a defini o de uma arquitetura de refer ncia para o dom nio que define a maneira com que os sistemas do dom nio ser o constru dos Os requisitos incluindo a variabilidade devem ser mapeados para solu es t cnicas Padr es de projeto devem oferecer suporte estrutura vari vel que serve de base para os aplicativos do dom nio O arquiteto deve reduzir a complexidade do projeto atrav s de abstra es que consigam separar os principais aspectos do dom nio O arquiteto deve modelar as abstra es de forma a permitir o racioc nio sobre elas Esta rea tamb m envolve a avalia o arquitetural visando detectar falhas e erros antes da implementa o come ar A abordagem engloba as pr ticas relacionadas ao projeto de dom nio incluindo projeto arquitetural e suporte variabilidade AP9 Treinamento em reutiliza o envolve um pr
116. ILLE 2006 Cada modelo de processo representa um processo sob o ponto de vista de uma perspectiva em particular e portanto cont m apenas informa es parciais sobre esse processo Existem diferentes modelos de processo conhecidos na literatura da Engenharia de Software como o modelo em cascata modelo evolutivo baseado em componentes incremental espiral entre outros PRESSMAN 2005 Estes modelos de processo n o s o mutuamente exclusivos sendo frequentemente utilizados em conjunto especialmente no desenvolvimento de grandes sistemas A abordagem desta tese baseada no modelo espiral proposto originalmente por Boehm 1988 O modelo espiral representa um processo de software em uma espiral onde todas as atividades s o executadas repetidamente a cada itera o Cada nova volta na espiral acrescenta um desenvolvimento novo produzindo por exemplo novos artefatos de software ou refinando artefatos j existentes A Figura 9 mostra o modelo de processo sugerido para utiliza o da abordagem para reutiliza o de software orientada a modelos Existem tr s ciclos b sicos neste modelo o ciclo principal o ciclo de projeto e o ciclo de implementa o Em cada ciclo existe uma atividade AD 1 PD 5 e ID 4 destacadas na Figura 9 que marca um momento de decis o sobre continuar ou n o a execu o daquele ciclo espec fico Cada ciclo detalhado a seguir 4 4 1 Ciclo principal do modelo de processo evolu o dos subd
117. JM2 Modelar o processo de MDD do projeto normalmente cada organiza o tem um processo de desenvolvimento implantado que modificado ou adaptado para atender s necessidades de cada projeto No caso do MDD essa adapta o deve considerar que i os requisitos devem ser modelados nas ferramentas selecionadas para a organiza o e utilizando os padr es de modelagem pr estabelecidos 11 o foco das tarefas do projeto deve se concentrado nas atividades de modelagem e na defini o de transforma es entre modelos e iii a maioria dos resultados as atividades de engenharia s o modelos e transforma es entre modelos A abordagem est completamente modelada e portanto pode ser utilizada como modelo do processo PJM3 Aplicar o processo estabelecido consiste na utiliza o do processo definido e obten o de m tricas para controle de sua execu o Uma organiza o 278 pode aplicar a abordagem mas n o foram definidas m tricas para gerenciar e controlar sua execu o e portanto esta pr tica n o est completamente satisfeita PJM4 Definir coletar e analisar m tricas do projeto as m tricas devem estar ligadas aos objetivos do projeto O foco deve ser nas atividades espec ficas do MDD como qualidade arquitetural corretude dos modelos etc A abordagem n o define nenhuma atividade referente defini o coleta e an lise de m tricas SUP1 Estabelecer e manter
118. KLEIN 2004 2 O resultado destes passos uma lista que descreve como cada arquitetura atende aos requisitos conforme expressos pelos stakeholders Para cada arquitetura pode se calcular e N mero de cen rios diretamente suportados para cada arquitetura conta se o n mero de cen rios que foram avaliados como possuindo suporte direto da arquitetura sem necessidade de altera es Este n mero deve considerar o peso de cada cen rio conforme estipulado no passo 1 descrito anteriormente 140 e N mero de cen rios indiretamente suportados para cada arquitetura conta se o n mero de cen rios que requerem alguma altera o para passarem a possuir o suporte adequado pela arquitetura Este n mero deve considerar o peso de cada cen rio conforme estipulado no passo 1 descrito anteriormente e e Quantidade de mudan as para cada arquitetura estima se a quantidade de mudan as necess rias para que a mesma passe a oferecer suporte a todos os cen rios indiretos Esta quantidade pode ser medida em termos de n mero de m dulos componentes modificados ou caso j existam mais detalhes sobre a arquitetura at mesmo o n mero de classes envolvidas nas mudan as De posse destes n meros poss vel determinar qual das alternativas oferece o melhor suporte global para os requisitos A alternativa que apresentar o melhor suporte aos cen rios e menor quantidade de mudan as ser selecionada para seguir adiante Uma vez sel
119. Kobra utiliza cen rios para viabilizar a cria o 216 e avalia o de uma arquitetura para uma linha de produtos de software Um diferencial do Kobra que ele apresenta crit rios para prioriza o de cen rios tais como o seu valor econ mico esfor o necess rio entre outros Nesta tese a prioriza o aberta ficando a cargo dos stakeholders definirem aqueles mais importantes a serem utilizados como diretrizes arquiteturais No Kobra s o utilizados modelos UML principalmente modelos de classes e de atividades para especifica o dos componentes em diversos n veis de refinamento Os autores sugerem a utiliza o de diagramas organizados de forma hier rquica onde cada diagrama descreve um nico componente A hierarquia define o relacionamento entre eles mostrando o dom nio em diversos n veis desde o contexto de sistema at os componentes individuais Regras de relacionamento entre os diagramas definem de forma n o amb gua como a rela o entre os componentes deve ser implementada Esta abordagem reflete o fato de que o Kobra fortemente centrado no conceito de componentes de software e como resultado a arquitetura e implementa o est o descritos primariamente em termos dos seus componentes 2 Diferentemente do Kobra nesta tese o uso de componentes n o necessariamente obrigat rio como mecanismo de encapsulamento de conhecimento e implementa o da variabilidade Unidades de implementa o de mais b
120. Linguagens de modelagem Diagrama de Uso de diagramas de estado para navega o onde as p ginas correspondem aos estados da UML estados e as transi es correspondem aos links UWE Uso da UML e seus diagramas para modelagem dos diversos aspectos de uma aplica o Web http www pst ifi lImu de projekte uwe WebML Modelo hipertexto para especifica o da navega o de uma aplica o web WebML Modelo para descrever as paginas de uma aplica o web www webml org Presentation model Ferramentas MagicDraw Ferramentas de modelagem UML que podem ser usadas para criar modelos UWE ArgoUML Jude Microsoft Visio Ferramenta de cria o de diagramas que pode ser estendida com formas espec ficas para WebML www webml org MagicUWE Plug in UWE para a ferramenta MagicDraw http www pst ifiimu de projekte uwe tooIMagicUWE html ArgoUWE Extens o da ferramenta ArgoUML para suporte ao UWE http www pst ifi lmu de projekte uwe toolargoUWE html Quadro 6 Documenta o do subdom nio de navega o intera o dever ser refinada incluindo uma defini o mais detalhada da interface entre os artefatos gerados para este subdom nio e outros artefatos Atividade AD 4 Valida o e documenta o do dom nio Pap is analista do dom nio especialista do dom nio Entradas Informa es sobre sistemas do dom nio Conhecimento do especialista Informa es sobre stakeholders PT 1 lnicial Planejamento do do
121. MOON YEOM 2006 CZARNECKI 2005 WEISS LAI 1999 CLEMENTS NORTHROP 2002 A arquitetura projetada deve n o somente prever os pontos de varia o mas tamb m efetivamente providenciar o suporte requerido para sua implementa o BASS CLEMENTS KAZMAN 2003 H dois tipos fundamentalmente diferentes de complexidade relativa variabilidade V LTER GROHER 2007 CZARNECKI 2005 e Configura o de rotina tipo de variabilidade em que estruturas simples como uma lista de propriedades ou uma rvore podem ser utilizados para configura o do produto e e Constru o criativa tipo de variabilidade em que s o necess rios modelos complexos como estruturas do tipo grafo ou linguagens textuais completas para descrev la 116 completamente Diferentes mecanismos de representa o de variabilidade podem estar em diferentes locais de um espectro que vai desde a configura o de rotina at a constru o criativa Por exemplo wizards s o mecanismos simples onde a cada passo um par metro especificado e portanto localizam se pr ximo configura o de rotina O modelo de features Se o 3 1 1 um pouco mais complexo mas ainda relativamente simples localizando se aproximadamente na metade do espectro Do lado criativo encontram se as linguagens espec ficas de dom nio DSL CZARNECKI 2005 O modelo de features do dom nio de autoria de conte do para Web j utilizado no cap tulo anterior e
122. MS Modelar os processos autom ticos de MDD do projeto esta pr tica estende a pr tica do n vel 3 de modelagem do processo introduzindo limites de desempenho de modelagem estabelecidos pela organiza o quando desenvolvendo o modelo do processo A modelagem da abordagem se limita descri o das atividades n o contemplando todos os requisitos desta pr tica que exige um conhecimento sobre diferentes op es de processo para cada projeto cada um com um grau espec fico de automa o visando dosar o n vel de automa o em cada projeto e N vel 5 MDD Definitivo neste ltimo e derradeiro n vel todo o conhecimento da organiza o mantido na forma de modelos e transforma es que s o o foco do processo de desenvolvimento Pr ticas de engenharia de dom nio e linguagens espec ficas de dom nio s o criadas e continuamente atualizadas gi ENG15 Desenvolver linguagens espec ficas de dom nio linguagens espec ficas de dom nio capturam o conhecimento do dom nio utilizando abstra es do dom nio permitindo que os desenvolvedores criem produtos com base em termos familiares do dom nio Consiste na identifica o dos principais conceitos 281 do dom nio defini o do gloss rio do dom nio sele o da linguagem e defini o da DSL atrav s de uma ferramenta A abordagem possui uma atividade espec fica para o desenvolvimento de DSLs no contexto da reutili
123. Mas esta situa o pode acontecer j que durante a migra o de c digo pode se identificar oportunidades para melhorar o suporte variabilidade Por exemplo a implementa o de refer ncia pode implementar alternativas diferentes para um ponto de varia o atrav s de trechos de c digo distintos Ap s a migra o de c digo para o template o implementador pode perceber que a cria o de fun es separadas uma para cada alternativa uma solu o melhor Assim ele modifica o template para implementar esta solu o fazendo com que a implementa o de refer ncia se torne inconsistente Mesmo que a migra o de c digo n o modifique a implementa o de refer ncia a pr pria evolu o do dom nio normalmente causa este tipo de inconsist ncia Sempre que for necess rio corrigir algum erro seja no gerador ou em outro lugar deve se idealmente realizar a manuten o primeiro na implementa o de refer ncia test la e valid la e somente ent o repetir o processo de migra o de forma que a inconsist ncia n o exista Mas na pr tica principalmente corre es menores ou de erros do pr prio gerador modifica se diretamente os templates causando 161 inconsist ncia Para lidar com estes problemas o seguinte processo aplicado quando necess rio realizar alguma altera o Figura 27 Mudan a necess ria Decidir onde mudar Modificar Modificar implementa o templates de refer ncia
124. PLAN Conference on Object Oriented Programming Systems Languages and Applications OOPSLA 2005 San Diego CA USA ACM 2005 p 126 127 CZARNECKI K et al Generative programming for embedded software An industrial experience report In BATORY D CONSEL C TAHA W Ed Generative Programming and Component Engineering S 1 Springer Berlin Heidelberg 2002 Lecture Notes in Computer Science v 2487 p 156 172 CZARNECKI K EISENECKER U W Generative Programming Methods Tools and Applications S 1 Addison Wesley 2000 CZARNECKI K HELSEN S Feature based survey of model transformation approaches IBM Systems Journal v 45 n 3 p 621 645 2006 ISSN 0018 8670 Dispon vel em lt http www research ibm com journal sj 453 czarnecki html gt Acesso em 14 jun 2009 CZARNECKI K HELSEN S EISENECKER U Formalizing Cardinality based Feature Models and their Staged Configuration SI 2004 Dispon vel em lt http www ece uwaterloo ca kczarnec TR04 11 pdf gt CZARNECKI K HELSEN S EISENECKER U Staged configuration using feature models In NORD R L Ed Proceedings of the Third Software Product Line Conference Boston MA Springer 2004 LNCS 3154 p 266 283 DAVIS T The reuse capability model A basis for improving an organization s reuse capability In Proceedings of 2nd ACM IEEE International Workshop on Software Reusability S 1 IEEE Computer Society Press ACM Pres
125. Projeto do dom nio Quadro 10 Resumo das atividades para projeto de dom nio orientado a modelos abordagem al m de componentes de software tradicionais a arquitetura comporta a exist ncia de artefatos como DSLs transforma es e geradores de c digo 142 Produto de trabalho Descri o Estado PT 6 M dulos a serem refinados Consiste na defini o dos m dulos a serem refinados em uma determinada itera o do projeto do dom nio Iniciando com o dom nio todo a cada etapa um ou mais m dulos s o refinados e produzem uma nova vers o da arquitetura do dom nio Nenhum PT 7 Diretrizes arquiteturais Conjunto de requisitos importantes para a defini o da arquitetura Consiste em objetivos de neg cio casos de uso cen rios e linguagens que descrevem a variabilidade al m de uma lista de depend ncias entre os subdom nios Nenhum PT 8 arquiteturais T ticas e padr es Descrevem solu es para problemas comuns no projeto arquitetural orientado a modelos Nenhum PT 9 Projeto do dom nio Resultado da fase de projeto este produto de trabalho engloba a defini o da arquitetura com os m dulos e sub m dulos e a especifica o das interfaces considerando a exist ncia de componentes tradicionais e artefatos do MDD como DSLs ferramentas transforma es e geradores de c digo 1 Inicial vers o inicial do documento gerada somente pelo projetista com
126. R EMF qr P89 on Ty XMI XMI Figura 6 Compara o entre MDR e EMF Outro projeto relacionado ao desenvolvimento orientado a modelos voltado a plataforma Eclipse denominado GMT Generative Modeling Tools Trata se de uma iniciativa bastante recente que se baseia nas id ias do padr es OMG por m com algumas modifica es Seu principal objetivo servir de incubadora para projetos de ferramentas linguagens e frameworks para dar suporte s tecnologias de transforma o e gera o de c digo Dentre os sub projetos do GMT destacam se e ATL Atlas Transformation Language trata se de uma linguagem para defini o de transforma es entre modelos Originalmente projetada para ser compat vel com o MOF sua vers o atual j baseada no Ecore equivalente linguagem QVT do OMG possuindo algumas diferen as JOUAULT KURTEV 2006 e MOF Script esse projeto envolve o desenvolvimento de ferramentas e frameworks para transforma o de modelos para texto com base em uma linguagem para defini o dessas transforma es e e TCS Textual Concrete Syntax esse projeto visa desenvolver ferramentas para a defini o de DSLs textuais IOUAULT BEZIVIN KURTEV 2006 http www eclipse org gmt Shttp www eclipse org gmt at1 nttp www eclipse org gmt mofscript ODSLs ser o abordadas mais adiante no Capitulo 3 51 Outro projeto que fazia parte do GMT
127. SON 1997b padr es BUSCHMANN et al 1996 e reengenharia de software JACOBSON LINDSTROM 1991 Desenvolvimento Baseado em Componentes Dentre as t cnicas utilizadas para se alcan ar os benef cios da reutiliza o destaca se o desenvolvimento baseado em componentes DBC At alguns anos atr s o desenvolvimento da maioria dos produtos de software era baseado em blocos monol ticos formados por um 255 grande n mero de partes inter relacionadas e na maioria das vezes essa rela o entre as partes era impl cita O DBC surgiu como uma nova perspectiva para desenvolvimento de software na qual a analogia de quebrar esses blocos monol ticos em componentes intercambi veis diminuindo a complexidade e explicitando a rela o entre as partes que comp em o software A id ia de componentes de software n o nova Em 1968 durante uma confer ncia da OTAN sobre Engenharia de Software o foco era a crise do software o problema de se construir sistemas de software grandes e confi veis de uma maneira control vel e eficiente Desde o in cio a reutiliza o foi considerada como uma maneira de solucionar a crise do software Um artigo apresentado na confer ncia intitulado Componentes de Software Produzidos em Massa por Mcllroy MCILROY 1968 se tornou um dos mais revolucion rios da rea de reutiliza o Nas palavras de Mcllroy a ind stria de software fracamente fundada e um dos motivos dessa fraquez
128. SS CLEMENTS KAZMAN 2003 Nesta abordagem ao menos tr s tipos de diretrizes devem estar presentes com maior prioridade e Variabilidade em termos de features como discutido anteriormente a maior parte da variabilidade pode ser descrita atrav s de features Para o projeto arquitetural a variabilidade descrita tamb m na forma de cen rios visando facilitar seu entendimento e futura avalia o 122 e Variabilidade em forma de DSLs casos mais complexos de variabilidade exigem um mecanismo mais expressivo para express la apropriadamente Para o projeto arquitetural s o utilizadas DSLs para descrever esta variabilidade mais complexa e e Integra o entre subdom nios o projeto arquitetural precisa considerar os pontos onde diferentes subdom nios ir o interagir Isto envolve por exemplo a integra o entre c digo gerado e n o gerado Estes pontos de intera o devem ser expl citos para que a arquitetura possa dar suporte adequado gera o de c digo Sub atividade PD 2 1 Sele o das diretrizes arquiteturais de variabilidade baseada em features Nesta atividade o objetivo descrever cen rios que ilustrem as variabilidades que ocorrem em termos da presen a ou aus ncia de features Tais cen rios j foram identificados durante a an lise na atividade de mapeamento das features em forma de cen rios Sub atividade AD 2 1 Portanto aqui necess rio somente selecionar dentre os cen rios de
129. Society 1988 p 242 249 RABISER R GRUNBACHER P DHUNGANA D Supporting product derivation by adapting and augmenting variability models In SPLC S 1 IEEE Computer Society 2007 p 141 150 Dispon vel em lt http doi ieeecomputersociety org 10 1109 SPLINE 2007 22 gt Acesso em 14 jun 2009 RIBEIRO M de M MATOS J P BORBA P A decision model for implementing product lines variabilities In SAC 08 Proceedings of the 2008 ACM symposium on Applied computing New York NY USA ACM 2008 p 276 277 ISBN 978 1 59593 753 7 RINE D Success factors for software reuse that are applicable across domains and businesses In ACM Symposium on Applied Computing San Jose California USA ACM Press 1997 p 182 186 RINE D SONNEMANN R Investment in reusable software a study on software reuse investment success factors The Journal of Systems and Software v 41 p 17 32 1998 RINE D C NADA N An empirical study of a software reuse reference model Information and Software Technology v 42 n 1 p 47 65 2000 ROBBES R LANZA M Example based program transformation In CZARNECKI K et al Ed MoDELS S 1 Springer 2008 Lecture Notes in Computer Science v 5301 p 174 188 ISBN 978 3 540 87874 2 ROMBACH D Fraunhofer The german model for applied research and technology transfer In 22nd International Conference on Software Engineering ICSE Limerick Ireland ACM Press 2000 p 25
130. String args FeatureA featureA theFactory createFeatureA Utilizar featureA normalmente Gerador OO JIN WIN Figura 15 Uso do padr o Abstract Factory para features alternativas A Figura 15 ilustra o uso deste padr o com um gerador de c digo para implementar features alternativas Para cada ponto de varia o cria se uma f brica abstrata e um produto abstrato AbstractFactoryFeatureA e FeatureA Para cada variante alternativa s o criadas as f bricas e produtos concretos O gerador ao criar um produto s precisa declarar a f brica abstrata correspondente ao ponto de varia o selecionado neste caso a featureA gerando as linhas 2 e 6 e instanciar a f brica correspondente alternativa selecionada linha 3 O resto do c digo pode utilizar a feature normalmente O padr o Prototype pode ser utilizado com o mesmo prop sito nos casos onde se deseja evitar a cria o de subclasses para os objetos construtores Neste padr o cada alternativa implementada como uma classe diferente de um prot tipo comum O gerador de c digo respons vel por gerar c digo que instancia somente a alternativa selecionada 127 TA FeatureA clone FeatureA TA Sub feature A2 SubFeatureA3 SubFeatureA1 clone SubFeatureA1 clone SubFeatureA3 SubFeatureA2 clone SubFeatureA2 1 public class UmProduto 2 private FeatureA prototype d
131. UCOO1 pois ele remove p3 do comportamento normal ou base comum Neste caso n o existe variabilidade positiva introduzida por CMO001 e portanto basta inverter os cen rios transformando CMO01 no cen rio normal e UCO01 no caso de mudan a Por m caso CM001 possua os passos pl p2 p4 p5 e p6 a simples invers o n o suficiente pois sempre existir uma variabilidade negativa n o importando qual destes cen rios faz parte da base comum Neste caso pode se criar um terceiro cen rio que possui os passos em comum por exemplo UC001 pl p2 p4 e p5 e dois casos de mudan a CMO01 pl p2 p3 p4 e p5 antigo UCO01 e CM002 pl p2 p4 p5 e p6 antigo CM001 Como resultado somente variabilidades positivas s o introduzidas O mesmo pode ser feito quando dois cen rios diferem em um determinado passo Neste caso ocorre a combina o de variabilidade negativa e positiva removendo um comportamento comum e adicionando outro em substitui o e o mesmo m todo pode ser aplicado para remover a parte negativa No exemplo da busca avan ada Quadro 5 pode se aplicar este m todo para remover a variabilidade negativa resultando em 3 cen rios 1 Cen rio 1 Busca a Usu rio informa par metros de busca b Aplica o realiza busca no conte do conforme especificado pelos par metros c Aplica o exibe lista com o conte do que corresponde aos par metros especificados d Usu rio clica sobre um resu
132. UDL eureisoid wn oprios 9 opuenb ajsixo ogy Op epenUa ep ovdsnpolg Jopeios um op tyjoosg op ojeulos op ordiumad Og BURISOI TS otumog wosensuly wosensuly ep jenueur ewojqoIrd ap svoypodsy Jopeyiduios um op saene epeznewomy eu sOpluUysp sonowgeg no vongueis g ensuoo op OTUTWOpP um op asmeuy suogensurT 290 Sajusuoduios sepLionhor RUIOJUL ORSROYIPOU eongwone Seprugop Log SoorjIojur op Wa opeaseg woo SeprAOId soovjsoyuT op ojusurejdooy no ovseziouleieg vosnq og egoaeN ogdezi un o ojuowepnsdeoug OJUIWITA OAUISIG 0vdB 139 UT ovseidepy ogis og ensqy 271 AP NDICE B Rela o entre a abordagem e modelos de maturidade Neste ap ndice s o descritos em detalhes as pr ticas do modelo de maturidade em reutiliza o proposto por Garcia et al 2007 2008 e do modelo de maturidade em MDD definido pela iniciativa ModelWare MODELWARE 2006d Tamb m discute se a rela o entre esses modelos de maturidade e a abordagem definida nesta tese Em cada pr tica indicado um s mbolo sendo que o s mbolo indica que a pr tica est presente na abordagem e o s mbolo 0 indica que a pr tica est ausente da abordagem Uma breve explica o destacada em negrito descreve o racioc nio por tr s da presen a ou aus ncia da pr tica na abordagem importante ressaltar que n o foi feita uma an lise rigorosa de ader ncia aos modelos de maturidade analisando se por exemplo as
133. a Navega o 1 2 0 0 3 Busca 0 2 2 Cadastros 1 2 2 5 Conte do de usu rio 0 0 0 0 0 Quadro 7 Documenta o do n vel de confian a dos subdom nios identificados com rela o s informa es dos stakeholders os requisitos iniciais e demais documentos relacionados Atividade AD 5 Decis o sobre inclus o exclus o de subdom nios Pap is analista do dom nio especialista do dom nio Entradas Informa es sobre sistemas do dom nio Conhecimento do especialista Informa es sobre stakeholders PT 1 Validado Planejamento do dominio PT 2 Validado Mapa de aplica es PT 3 Validado Modelagem do dom nio PT4 Validado Candidatos a subdom nio Sa das PT 5 Hist rico de decis es sobre inclus o exclus o de subdom nios Descri o nesta atividade o analista do dom nio junto com o especialista e os demais stakeholders analisam os subdom nios identificados com o objetivo de determinar se os mesmos ser o inclu dos nas fases subsequentes de projeto e implementa o Essa decis o deve levar em considera o o n vel de confian a dos subdom nios candidatos e portanto a exist ncia de linguagens ferramentas e outros ind cios de sua maturidade seus relacionamentos com os demais elementos do dom nio e outros fatores externos incluindo os objetivos de neg cio e condi es de mercado A abordagem baseia se num processo iterativo e alguns subdom nios podem estar mais 108
134. a a aus ncia de uma ind stria de sub componentes Apesar de serem antigas as id ias de Mcllroy ainda n o foram concretizadas O pr prio conceito de componentes ainda n o bem definido sendo que desde o primeiro workshop de DBC em 1998 em Kyoto v rias defini es foram apresentadas cada uma evidenciando um aspecto espec fico do componente Um conceito bastante satisfat rio apresentado por Szyperski 1999 um componente de software uma unidade de composi o com interfaces bem especificadas em contrato e depend ncias expl citas do contexto Um componente de software pode ser independentemente implantado e pode ser composto por terceiros As interfaces bem especificadas s o importantes para formar uma camada comum entre o reutilizador uma pessoa que utiliza o componente e o desenvolvedor do componente As depend ncias expl citas definem o que o ambiente deve fornecer para que o componente possa executar sua fun o Uma vez satisfeitas estas depend ncias expl citas o componente deve poder ser implantado sem a necessidade de resolver depend ncias adicionais Finalmente para que ele possa ser composto por terceiros ele deve ser suficientemente auto contido ou seja a fun o por ele desempenhada deve ser totalmente implementada dentro dele Um componente n o totalmente independente dos outros componentes e do ambiente As suas interfaces s o importantes justamente para explicitar quais s o esses p
135. a acomodar os elementos inseridos pelo padr o Existem basicamente tr s abordagens para os processos de adapta o e integra o de um padr o FLORIN MEIJERS WINSEN 1997 a abordagem top down na qual os elementos do padr o s o criados e ent o integrados ao restante do sistema a abordagem bottom up na qual os elementos j existentes no sistema s o transformados nos elementos do padr o e a abordagem h brida que uma combina o das outras duas com parte dos elementos do padr o sendo criados a partir do zero e parte sendo adaptada a partir de elementos j existentes no sistema Reengenharia de Software Outra t cnica que promove a reutiliza o de software a reengenharia de software Tamb m conhecida como renova o ou recupera o tem como objetivo principal a reconstru o de sistemas legados para aumentar sua qualidade e manutenibilidade Por m sistemas legados normalmente encapsulam um conhecimento que evoluiu durante anos e que n o pode ser desperdi ado Dessa forma a reengenharia de software tamb m uma forma de reutilizar software fazendo com que esse conhecimento seja reaproveitado A reengenharia de software n o somente recupera as informa es de um projeto existente mas tamb m as reutiliza para alterar ou reconstruir o sistema adicionando novos requisitos ou introduzindo novas Shttp hillside net patterns onlinepatterncatalog htm 269 tecnologias As principais atividade
136. a o n o desejada 16 68 10 01 de reutiliza o E Sem abordagem 64 47 E Com abordagem 82 66 Figura 34 Compara o entre as m tricas de reutiliza o para o estudo do dom nio de aplica es distribu das baseadas em computa o em nuvem 194 A porcentagem de reutiliza o obtida com gera o de c digo neste estudo foi similar ao estudo anterior atingindo 42 71 A raz o entre especifica o e c digo foi um pouco maior atingindo 1 26 35 ou seja os geradores deste estudo produzem mais c digo para cada elemento de especifica o do que os do estudo anterior A Figura 35 mostra os valores das m tricas indiretas de reusabilidade instabilidade complexidade e manutenibilidade obtidas dos artefatos produzidos com e sem a abordagem Pode se verificar que n o houve altera o significativa nas distribui es das m tricas de instabilidade e ndice de manutenibilidade A complexidade por sua vez apresentou uma discreta redu o ili Complexidade ciclom tica ndi ibili 1 200 Instabilidade de M dulo 25 000 p 250 000 ndice de Manutenibilidade 1 000 20 000 200 000 0 800 15 000 150 000 0 600 e 10 000 afk x 100 000 0 400 5 000 0 200 i 0 000 i 30000 0 000 5 000 0 000 Sem Com Sem Com Sem Com abordagem abordagem abordagem abordagem abordagem abordagem
137. a o entre um elemento de especifica o e o c digo gerado correspondente Por exemplo se a especifica o de uma classe com atributos e relacionamentos produz 1000 linhas de c digo tem se um maior n mero de linhas de c digo reutilizadas do que a especifica o de um arquivo de configura o com 10 linhas que produz somente 20 linhas de c digo Esta m trica calculada da seguinte forma REC 3 LOC m dulosgerados Y NEE modelos onde NEE modelo corresponde ao n mero de elementos de especifica o do modelo Um elemento de especifica o pode ser uma linha de texto em uma DSL textual ou um elemento gr fico de um diagrama seja ele uma caixa atributo linha ou outro elemento gr fico similar Para efeito de compara o considera se que uma linha textual aproximadamente equivalente a um elemento gr fico pois apesar de o elemento gr fico ser mais simples de criar e editar do que uma linha de texto ele normalmente possui propriedades que precisam ser configuradas individualmente As m tricas My e Ms presumem a exist ncia de gera o de c digo e portanto n o podem ser utilizadas para comparar um projeto desenvolvido sem a abordagem que n o possui gera o de c digo com um projeto desenvolvido com a abordagem Por m elas s o teis para ajudar a caracterizar a reutiliza o que est ocorrendo com a abordagem Dois pontos de discuss o sobre estas m tricas precisam ser destacados 1 No conte
138. a para resolver os problemas da crise do software A realidade por m mostrou que forjar tal bala muito mais dif cil do que se supunha e que os desafios a serem enfrentados s o mais abrangentes do que os meros aspectos t cnicos normalmente tidos como os nicos relevantes Nesta se o apresentam se os principais conceitos relacionados reutiliza o de software as principais t cnicas existentes e uma discuss o mais detalhada sobre a rela o entre estes pontos e o processo de software 2 1 1 Conceitos da reutiliza o de software De acordo com Krueger 1992 reutiliza o de software o processo de cria o de software a partir de software j existente ao inv s de construir do in cio O termo reutiliza o de software comumente confundido com a reutiliza o de c digo talvez por ser esta a forma mais simples e melhor compreendida de reutiliza o POULIN CARUSO HANCOCK 1993 Por m a reutiliza o de c digo n o representa o maior benef cio em potencial pois descarta conhecimento importante que se encontra em outros artefatos como aqueles produzidos durante an lise e projeto De fato qualquer artefato pode ser reutilizado Segundo D Souza e Wills 1999 um artefato reutiliz vel uma parte do trabalho que pode ser utilizado em mais de um projeto Nesse sentido podem ser reutilizados al m do c digo fonte artefatos como c digo compilado 30 casos de teste modelos interfaces pa
139. a serem mapeadas a um mesmo ponto de varia o o que significa que este elemento da DSL est espalhado em diferentes partes do c digo Caso existam muitas modifica es deste tipo pode ser que a atividade de projeto n o tenha produzido uma arquitetura adequada e o uso de padr es de projeto pode reduzir este espalhamento Ou ent o este pode se tratar de uma preocupa o ortogonal caso em que t cnicas da orienta o a aspectos podem ajudar VOLTER GROHER 2007 Sub atividade ID 3 3 Refinamento das DSLs Durante a inspe o de c digo o implementador do dom nio pode descobrir que mais detalhes ou informa es precisam ser inclu dos em uma DSL original antes que a mesma possa servir de entrada para transforma es e geradores de c digo Por exemplo uma inst ncia concreta de uma p gina web pode revelar detalhes como a disposi o visual dos elementos diferentes escolhas de elementos de entrada que podem ter passado despercebidos durante o desenvolvimento da DSL inicial Al m disso a inspe o pode identificar novos pontos de varia o que n o foram previstos durante a an lise inicial Finalmente a inspe o pode encontrar erros e inconsist ncias com os conceitos iniciais e as variabilidades definidas na abordagem top down Nestes casos uma ou mais DSLs precisam ser refinadas para introduzir novos elementos modificar ou remover elementos existentes Podem ser necess rias altera es na sintaxe abstrata quando
140. a arquitetura Assim a evolu o do ciclo de projeto ocorre da seguinte maneira para cada atividade 1 Atividade PD 1 Escolha dos m dulos a serem refinados a cada itera o esta atividade escolhe novos m dulos para serem refinados Obviamente na primeira itera o ainda n o existem m dulos e a escolha o dom nio todo As demais atividades s o executadas individualmente para cada m dulo aqui escolhido 2 Atividade PD 2 Sele o das diretrizes arquiteturais esta atividade identifica para cada m dulo sendo refinado nesta itera o os principais requisitos de software que podem influenciar a arquitetura naquele exato local referente ao m dulo Para cada m dulo seleciona se dentre todos os requisitos e objetivos de neg cio do dom nio aqueles que dizem respeito somente ao m dulo em quest o e que possuem impacto em sua arquitetura Estas s o as chamadas diretrizes arquiteturais 3 Atividade PD 3 Escolha de t ticas e padr es arquiteturais nesta atividade o projetista do dom nio escolhe para cada m dulo sendo refinado e com base nas diretrizes 79 selecionadas para aquele m dulo t ticas e padr es arquiteturais a serem aplicados no refinamento do m dulo 4 Atividade PD 4 Aplica o dos padr es arquiteturais e refinamento dos m dulos esta a atividade onde efetivamente realizado o refinamento dos m dulos A cada itera o com a aplica o das t ticas e padr es escolhidos os m d
141. a do especialista nesta tarefa e Relacionamento features sub features features s o divididas em sub features para ajudar na tarefa de compreens o do dom nio e sua variabilidade e a an lise destes relacionamentos LEE KANG 2003 leva a uma sub divis o natural do dom nio Features muito pr ximas s o normalmente boas candidatas a pertencerem a um mesmo subdom nio A aten o s features que aparentam estar separadas das demais pode tamb m levar identifica o de um subdom nio distinto e Dom nios at micos idealmente o subdom nio identificado deve ser at mico ou seja n o pode ser substancialmente decomposto sem alterar suas propriedades prim rias HADDAD TESSER 2002 Isto importante para manter o subdom nio simples e gerenci vel e portanto mais f cil de automatizar e e Repeti o uma boa indica o sobre o que pode ser automatizado o n vel de repeti o que ocorre com um projeto estrutura ou trecho de c digo Se algum trecho de c digo aparece repetidamente em diferentes partes do produto mesmo que n o de forma id ntica prov vel que uma m quina consiga fazer o trabalho de c pia parametrizada Pode valer a pena tentar procurar um subdom nio associado a este trecho Outra t cnica para encontrar repeti es a busca por padr es recorrentes KNODEL etal 2005 Al m dessas diretrizes a experi ncia pr tica com modelagem de dom nio TOLVANEN 2005 mostra que um aumento incrementa
142. a o primeiro estudo foi escolhido o dom nio de aplica es de autoria de conte do para a Web por se tratar de um dom nio relativamente simples de ser implementado manualmente e pela disponibilidade de especialistas para eventuais consultas Este primeiro estudo foi completamente desenvolvido a partir do zero para a avalia o mas foi 182 o resultado da evolu o dos estudos utilizados como base para testar e refinar as atividades da abordagem conforme descrito na Se o 4 3 O segundo estudo foi realizado na ind stria durante um est gio de doutorado e a escolha do dom nio envolvido de aplica es distribu das baseadas em computa o em nuvem n o foi feita pelo autor desta tese mas sim pelos l deres do grupo no qual o est gio foi realizado O terceiro estudo tamb m realizado na ind stria envolveu o dom nio de eventos cient ficos e a escolha se deu por conveni ncia e proximidade da empresa ao grupo de pesquisa Os estudos s o comparativos ou seja visam comparar os resultados do desenvolvimento realizado sem a abordagem com o desenvolvimento realizado com a abordagem Para essa compara o foram utilizadas implementa es de exemplo desenvolvidas antes do uso da abordagem que n o contemplavam modelos ou qualquer tipo de artefato relacionado ao MDD e as implementa es desenvolvidas com a abordagem que incluem uma arquitetura preparada para o MDD al m dos artefatos espec ficos para este contexto
143. a pr pria Microsoft possui uma solu o voltada para o desenvolvimento de DSLs e geradores de c digo apenas refor a esta observa o Claro que n o se pode generalizar estas observa es com base em fatos isolados mas a experi ncia destes anos de doutorado ap s participa es em diversos eventos cient ficos e contatos com empresas ainda n o produziram evid ncia do contr rio Outra importante li o aprendida diz respeito grande variedade de trabalhos similares existentes na literatura muito comum encontrar trabalhos bastante parecidos com os temas aqui investigados Por m h tamb m grande diversidade no foco com cada trabalho sendo bastante direcionado a uma determinada linha de pesquisa caracter stica do grupo de pesquisa que o realiza N o existem muitos trabalhos derivados destas iniciativas isoladas e que buscam englobar e unificar os diversos aspectos do problema caminho este que foi seguido nesta tese As contribui es alcan adas comprovam que h espa o tamb m para este tipo de pesquisa Neste quesito cabe tamb m uma observa o a despeito da grande quantidade e variedade de trabalhos na rea raro encontrar estudos emp ricos buscando sua valida o a exemplo do que se tentou realizar nesta pesquisa dif cil encontrar m tricas e valores para serem utilizados como base para este tipo de estudo sendo frequentemente necess rias adapta es ou interpreta es indiretas para se extrair concl
144. a sua complexidade Al m disso n o um processo muito previs vel pois exige criatividade VISSER 2007 Esta abordagem busca prover alguma orienta o atrav s de cinco sub atividades apresentadas a seguir Sub atividade ID 2 1 Identifica o das features iniciais da DSL O primeiro passo identificar as features que ir o dar in cio forma o da sintaxe abstrata da DSL Como descrito na atividade ID 1 os servi os e fun es do dom nio s o normalmente descritos em termos de features de tecnologia do dom nio e portanto estas s o boas candidatas a fazer parte de uma DSL Considere por exemplo o dom nio web de autoria de conte do mostrado na Figura 26A Neste dom nio dois subdom nios podem ser identificados navega o Conte do Busca Busca simples Busca avan ada Conte do de usu rio P gina Formul rio 151 Relat rio e Link e autoria Autoria Tipo de documento e Relacionamento As features de tecnologia do dom nio do subdom nio de navega o ir o fazer parte da DSL de navega o P ginas Links Formul rios e Relat rios Similarmente a DSL do subdom nio de autoria ir incluir tipos de documentos e relacionamentos Doo EH Autoria E Rave tL 4 tL SI Sub dominio Deena de autoria tipo de busca Lo e mm mm tipo de busca Busca ae Busca avan ada 1 1 tT teed O Ene 1 ENC ee 1 tipo de p gina Conte do Modera o de usu rio i tamanho
145. a testes manuten o Al m disso erros n o previstos s o mais prov veis de acontecer dependendo de como o c digo gerado varia pois dif cil prever todas as possibilidades Estes padr es visam reduzir estes problemas Na maioria dos casos padr es como o Template method ou Factory GAMMA et al 1995 podem ser utilizados de forma que o c digo n o gerado n o precise saber detalhes sobre como as classes e m todos que o mesmo utiliza s o implementados se s o gerados ou constru dos manualmente Por m em algum momento uma implementa o concreta precisa ser providenciada pois de outra forma o c digo n o ir compilar e executar completamente 135 Nesses casos poss vel remover a depend ncia entre c digo n o gerado e gerado por meio dos padr es de Inje o de depend ncia ou Localizador de servi o FOWLER 2004 Estes padr es removem as depend ncias do c digo neste caso do c digo n o gerado e as colocam em agentes externos respons veis pela inje o das depend ncias atrav s de configura o program tica ou textual normalmente XML As depend ncias devem ainda ser definidas em algum lugar mas uma vez que isto s ocorre em uma entidade separada estas s o expl citas sendo tamb m mais facilmente definidas o que acaba melhorando o entendimento do c digo final O c digo original pode ser compilado independentemente facilitando testes e manuten o Al m disso o c digo de configura o pode
146. abordagem implementa quase todas as pr ticas de engenharia com exce o de quatro pr ticas Como na reutiliza o poucas pr ticas de gerenciamento e suporte do MDD foram inclu das Considerando se este modelo a abordagem n o garante que uma organiza o atinja um n vel maior do que o n vel 1 de maturidade Por m caso a organiza o defina uma atividade para gera o autom tica de documenta o pr tica ENG4 ela passa ao n vel 2 pois esta a nica pr tica do n vel 2 n o implementada pela abordagem A compara o com estes modelos de maturidade visa somente deixar clara a abrang ncia da abordagem com rela o ao que existe em termos de processo de software conforme identificado pelos autores destes modelos Estes modelos n o foram utilizados como base para a defini o da abordagem mesmo porque apesar de representarem iniciativas promissoras lideradas por importantes institui es de todo o mundo ainda n o s o consolidados 84 A decis o sobre quais pr ticas atender e quais n o atender foi portanto baseada na literatura e nos estudos de caso conforme descrito na Se o 4 2 Desta maneira pode se obter uma cobertura mais completa do ciclo de vida desde a an lise at a implementa o ainda que isto signifique que nenhum dos primeiros n veis de maturidade destes modelos seja alcan ado 4 6 Considera es finais Neste cap tulo apresentou se uma vis o geral da abordagem seus objetivos sua es
147. ada para linguagens de modelagem tamb m Como os pr prios autores destacam pode ser ainda mais simples nestes casos j que os passos autom ticos seriam realizados em estruturas mais simples do que uma AST de um programa A abordagem desta tese similar ao racioc nio de desenvolvimento de transforma es atrav s de exemplos seguido pelos autores com a diferen a de que a identifica o das mudan as n o automatizada sendo realizada completamente pelo desenvolvedor Al m disso esta tese foca na engenharia de dom nio com o objetivo de produzir transforma es projetadas especificamente para dar suporte variabilidade no dom nio Varr 2006 tamb m prop e o desenvolvimento de transforma es orientada a exemplos por m com foco em transforma es de modelos Um processo iterativo e interativo utiliza deriva o semi autom tica das transforma es a partir de pares de modelos origem e destino O desenvolvedor da transforma o refina um conjunto de regras inicialmente derivadas at que as mesmas cheguem a um ponto satisfat rio Diferentemente do trabalho de Robbes e Lanza 2008 e da abordagem desta tese o processo de Varr n o depende do registro das modifica es que levam da origem ao destino Ao inv s disso o processo tenta estabelecer mapeamentos analisando exemplos de modelo origem e destino A abordagem desta tese assim como a de Robbes e Lanza 2008 mais voltada para os est gios iniciais do desenvolvi
148. ada subdom nio efetivamente caracterizado com rela o 147 sua variabilidade visando dar subs dios implementa o do suporte em termos de modelagem transforma es e geradores de c digo para sua automa o Conforme discutido no Cap tulo 6 existem diferentes tipos de variabilidade que s o caracterizados de acordo com um espectro entre configura o de rotina e constru o criativa Nesta atividade cada subdom nio analisado e inserido em um determinado local deste espectro A Figura 24 ilustra esta estrat gia Para todo o dom nio uma ferramenta de features normalmente utilizada junto com uma ferramenta de configura o autom tica Alguns subdom nios podem exigir uma solu o baseada em uma DSL completa incluindo uma ferramenta de modelagem e geradores dedicados Em outros um simples wizard pode ser suficiente Dom nio Sub o0 oP o a No Po Po amp gQ Gs 25 amp gQ w sx KG af e o SY NS Ox A SS lg OO AL So By to Ly 6 e5 to x amp a gt So se fe o R gt o oo Ferramentas DSL modela Wizard de features geradores geradores configurador EEF Componentes servi os Implementa o do dom nio Figura 24 Estrat gia de caracteriza o de subdom nios Para inserir cada subdom nio em algum lugar do espectro de variabilidade o papel do especialista do dom nio muito importante mas as seguintes diretrizes podem ser teis D
149. adas anteriormente O objetivo selecionar aquela que melhor atende aos requisitos para o dom nio com foco na variabilidade Este pode parecer um passo desnecess rio uma vez que na atividade anterior o projeto arquitetural foi realizado com base em um conjunto de diretrizes que representam os mesmos requisitos A diferen a no entanto que agora ser o inclu dos os pontos de vista dos outros interessados no dom nio para serem confrontados com os requisitos iniciais o que potencialmente ir revelar alguns aspectos que foram ignorados pelo projetista Este confronto ir n o somente facilitar a sele o de uma arquitetura adequada por meio 139 de consenso entre todos os envolvidos como tamb m ir resultar em poss veis sugest es de altera o na arquitetura visando atender os cen rios n o originalmente previstos Assim esta atividade tamb m pode ser vista como uma atividade de melhoria e evolu o da arquitetura Esta atividade inspirada no SAAM Software Architecture Analysis Method ou M todo de Avalia o de Arquitetura de Software CLEMENTS KAZMAN KLEIN 2004 com 3 passos 1 Desenvolver cen rios cen rios conforme discutido anteriormente capturam os principais requisitos e funcionalidades que devem ser atingidos pela arquitetura Alguns ja foram definidos anteriormente incluindo os casos de uso de mudan a e os principais requisitos de qualidade Estes foram elaborados principalmente pelo projetista
150. ade portanto o objetivo transformar o restante da implementa o de refer ncia em um framework reutiliz vel De acordo com as caracter sticas essenciais de um framework a implementa o de refer ncia est relativamente pr xima de se tornar um framework de dom nio pois e As classes da implementa o de refer ncia encapsulam conhecimento sobre um dom nio de problema e Ela foi desenvolvida com base em uma arquitetura bem definida a partir de um processo centrado no suporte variabilidade e com o objetivo de implementar diferentes diretrizes arquiteturais e A implementa o de refer ncia n o define somente as classes de forma isolada mas tamb m as interfaces e conex es entre as mesmas em uma estrutura que representa parte do conhecimento daquele dom nio e e A implementa o de refer ncia possui suporte para pontos fixos e pontos vari veis a exemplo de um framework que podem ser estendidos e instanciados por um desenvolvedor de aplica es Portanto para transformar a implementa o de refer ncia em um framework de dom nio a princ pio s necess rio tornar expl cito os pontos vari veis em termos de c digo n o gerado uma vez que o restante das variabilidades ser implementada somente pelos transformadores e geradores de c digo O c digo n o gerado idealmente j foi estruturado utilizando padr es de software que facilitam a sele o e implementa o de algumas variabilid
151. ades na atividade PD 3 Desta forma aqui necess rio especificar as interfaces resultantes da aplica o dos padr es Por exemplo caso tenha sido utilizado o padr o Decorator para features alternativas complementares aqui s o definidas as interfaces de cada alternativa com seus m todos sendo descritos individualmente Pode ser necess rio o desenvolvimento de algum mecanismo para facilitar a instancia o dos pontos vari veis Por exemplo pode se criar um objeto Singleton para facilitar a instancia o das features implementadas utilizando se o padr o Abstract Factory Pode se Uma discuss o mais aprofundada sobre frameworks e seu papel na reutiliza o de software apresentada no Ap ndice A 163 inclusive criar um m todo separado para cada sub feature alternativa de forma que para escolher uma destas basta chamar o m todo correspondente ao inv s de instanciar a f brica desejada Finalmente a implementa o de refer ncia pode ser complementada com componentes n o inclu dos originalmente por n o terem sido serem necess rios no momento ou por uma decis o estrat gica 2 A sa da desta atividade uma vers o revisada e completada da implementa o de refer ncia preparada para ser mais reutiliz vel e pass vel de instancia o no desenvolvimento de aplica es Uma vez pronto o framework do dom nio toma o lugar da implementa o de refer ncia Atividade ID 5 Documenta o do do
152. ades de neg cio e relacionamento entre elas A abordagem n o est focada em um tipo espec fico de modelo e portanto pode ser utilizada para desenvolver modelos de neg cio Z ENG11 Desenvolver transforma es modelo para modelo consiste na identifica o dos metamodelos de origem e destino padr es de transforma o entre os modelos de origem e destino defini o da linguagem de transforma es a ser utilizada e implementa o da transforma o A sintaxe concreta deve ser ignorada neste caso As transforma es modelo para modelo est o previstas na abordagem como uma forma de organiza o e estrutura o dos geradores de c digo ENG12 Manter rastreabilidade entre modelos significa manter liga es ou mapeamentos expl citos entre modelos ap s o resultado de uma transforma o Envolve a defini o de um framework de rastreabilidade com componentes e modelos a serem rastreados tipos de liga es dire o etc Os requisitos de rastreabilidade devem ser integrados ao processo de modelagem que tamb m respons vel por realizar a ger ncia de configura o e controle de vers es das liga es de rastreabilidade A abordagem prev rastreabilidade entre artefatos de an lise projeto e implementa o mas n o inclui o rastreamento entre elementos antes e ap s uma transforma o e portanto esta pr tica n o est completamente satisfeita Z ENG13 Integrar desenvolvimento de produto com
153. ado em 18 reas de processo AP que descrevem as atividades essenciais para uma organiza o que deseja incorporar a reutiliza o sistem tica em seu processo N vel 4 Sistem tico N vel 3 Definido N vel 2 B sico N vel 1 Incompleto Figura 1 Modelo de maturidade em reutiliza o GARCIA et al 2007 2008 As reas de processo est o agrupadas em quatro n veis descritos a seguir e N vel 1 Incompleto neste n vel apenas o desenvolvimento de software tradicional realizado Pr ticas de reutiliza o s o usadas esporadicamente ou mesmo ignoradas e desencorajadas pela ger ncia Reutiliza o fruto de esfor o individual e os custos da reutiliza o s o desconhecidos e N vel 2 B sico este n vel caracterizado pela utiliza o b sica de artefatos com potencial de reutiliza o Engloba algumas atividades iniciais orientadas reutiliza o como a manuten o de m todos e t cnicas b sicas de reutiliza o AP1 o planejamento da reutiliza o AP2 a defini o dos objetivos da reutiliza o AP3 e a implementa o do dom nio AP4 por m ainda sem a preocupa o com an lise e projeto voltados reutiliza o 36 e N vel 3 Definido neste n vel o principal foco de engenharia o suporte variabilidade Enquanto no n vel 2 a preocupa o era aumentar o n vel de reutiliza o de artefatos individuais aqui o foco oferecer um sup
154. agem referentes preocupa o com MDD desde o in cio do desenvolvimento nenhum benef cio para a implementa o dos artefatos do MDD DSLs transforma es e geradores de c digo Hoa Os participantes que utilizaram a abordagem tiveram dificuldades que causaram preju zo ao desenvolvimento em termos de atrasos e curva de aprendizado Para a parte Ho desta hip tese n o foram definidos itens individuais para cada m trica pois as mesmas n o podem ser avaliadas de forma isolada para determinar se houve de fato aumento na reutiliza o Portanto foi feita uma an lise descritiva considerando se todas as m tricas em conjunto buscando rejeitar a hip tese nula Com rela o parte Hop foram definidas compara es contr rias ao que se deseja demonstrar com exce o das m tricas Mo e Mjo pois no desenvolvimento tradicional sem abordagem n o foram produzidos modelos e portanto apenas a m trica Mg foi considerada suficiente para avaliar a manutenibilidade Assim as compara es de My e M foram feitas com os valores estabelecidos como refer ncia Para as partes Hoc e Hog n o foi definida nenhuma m trica pois a an lise foi qualitativa 181 A rejei o da hip tese nula deve ser feita em favor de uma hip tese alternativa que normalmente representa a nega o da hip tese nula Neste cen rio as seguintes alternativas s o definidas Mia Hic analisando se um mesmo projeto desenvolvido com e se
155. agens espec ficas de dominio PT 12 Inicial Suporte ferramental para DSLs Descri o dependendo do tipo de variabilidade para cada subdominio a DSL associada ser mais ou menos complexa Em casos de variabilidade mais simples baseada em features a DSL pode ser composta por s mbolos que representam features individuais para indicar sua presen a ou aus ncia Czarnecki Helsen e Eisenecker 2004a prop em um m todo para derivar uma gram tica livre de contexto para um modelo de features Este m todo pode ser utilizado para criar uma DSL capaz de descrever todos os tipos de variabilidade caracter stica a um modelo de features Um gerador de parsers ou um framework de DSLs pode ser utilizado para criar o suporte linguagem mais facilmente suprindo a necessidade de ferramentas Em casos de variabilidade mais complexa a DSL deve definir quais conceitos podem ser utilizados como eles se relacionam entre si e poss veis restri es que possam existir Isto pode 150 ser realizado exclusivamente de forma top down Por m a DSL deve tamb m ser capaz de produzir modelos que sirvam de entrada para transformadores e geradores o que inclui muitos detalhes que s o espec ficos plataforma e arquitetura escolhidas muito dif cil perceber tais detalhes sem investiga o mais aprofundada na implementa o e portanto uma abordagem bottom up utilizada para refinar esta DSL inicial Esta atividade corresponde parte top down
156. aixo n vel como classes podem existir tanto no n vel arquitetural como de implementa o Desta forma acredita se que poss vel oferecer suporte mais flex vel e detalhado variabilidade do dom nio para os casos onde componentes apresentam n vel de granularidade muito alto Outra diferen a entre esta tese e o m todo Kobra que neste ltimo o paradigma do MDD somente parcialmente suportado porque o m todo s lida com a atividade de modelagem n o cobrindo as atividades de desenvolvimento de transforma es e geradores automatizados Em contraste o desenvolvimento de tais artefatos explicitamente definido na abordagem desta tese por meio de princ pios diretrizes e atividades espec ficas Blois 2006 desenvolveu uma abordagem de projeto arquitetural baseada em componentes no contexto de engenharia de dom nio cujo objetivo atender aos principais requisitos para possibilitar um processo adequado para a reutiliza o de software Segundo a autora uma abordagem para engenharia de dom nio baseada em componentes deve obedecer aos seguintes crit rios 1 Modelagem de variabilidades e opcionalidades em diferentes n veis de abstra o 11 Manuten o da liga o e consist ncia entre os artefatos do dom nio de diferentes n veis de abstra o iii Organiza o dos artefatos para a composi o de elementos arquiteturais iv Uso de princ pios de DBC na modelagem de dom nio v Necessidade de processos de
157. alguns avan os em termos de m todos os conceitos apresentados por Parnas s o praticamente os mesmos que fundamentam as linhas de produtos LINDEN SCHMID ROMMES 2007 1 Gerenciamento da variabilidade consiste na determina o modelagem e implementa o das comunalidades e variabilidades de uma fam lia de produtos programas Equivale an lise das semelhan as e diferen as entre programas de uma mesma fam lia 2 Defini o arquitetural uma arquitetura de refer ncia tem papel chave na linha de produtos oferecendo meios concretos para que diferentes produtos possam ser instanciados Equivale defini o de quais pontos de um programa devem ser deixados sem implementa o de acordo com as variabilidades identificadas e 3 Abordagem em dois ciclos consiste na divis o entre engenharia de dom nio e engenharia de aplica es de forma equivalente ao refinamento por etapas ou especifica o dos m dulos e cria o dos programas O grande diferencial das abordagens atuais a preocupa o em definir o escopo da fam lia de produtos de acordo com objetivos de neg cio e estrat gias de mercado visando vantagens a longo prazo Em outras palavras define se quais produtos devem ser desenvolvidos quais as caracter sticas mais importantes a serem implementadas entre outras quest es LINDEN SCHMID ROMMES 2007 Esta preocupa o faz com que as linhas de produtos sejam atrativas para a ind stria que j acu
158. alho de P rez Mart nez e Sierra Alonso 2006 descreve uma abordagem para a deriva o autom tica de uma arquitetura de software a partir de modelos de an lise utilizando transforma es modelo para modelo semi automatizadas S o definidas 32 regras de mapeamento que transformam casos de uso classes atributos e relacionamentos de modelos de an lise em modelos arquiteturais seguindo o estilo arquitetural conhecido como C2 219 PEREZ MARTINEZ SIERRA ALONSO 2006 A exemplo dos geradores baseados em templates utilizados nesta tese o mapeamento proposto por P rez Mart nez e Sierra Alonso 2006 utiliza regras imperativas mais simples de implementar mas mais complicadas quando se deseja promover rastreamento e realizar a transforma o ida e volta Os modelos de destino s o descritos utilizando um perfil UML2 desenvolvido exclusivamente para o C2 uma vez que a UML sozinha n o capaz de representar todos os elementos deste estilo como por exemplo conectores portas mensagens etc Diferentemente desta tese por m o trabalho de P rez Mart nez e Sierra Alonso 2006 assume que os modelos de an lise s o ricos o suficiente para serem automaticamente transformados em uma arquitetura A abordagem desta tese defende a id ia de que necess rio trabalho manual e criativo consider vel entre an lise e projeto arquitetural de forma a incluir as preocupa es de todos os stakeholders Assumindo se um nico e pr defini
159. alizada e normalmente necess rio um processo de constru o criativa para combin los de forma a satisfazer os requisitos da aplica o Portanto h uma chance de que a variabilidade associada seja aberta Por exemplo as seis features de tecnologias de dom nio localizadas no lado inferior da Figura 25 n o podem ser meramente selecionadas ou de selecionadas Ao contr rio elas precisam ser combinadas de forma criativa ao se configurar um produto Dominio autoria web Navega o gt Administra o gt Busca Modera o E tipo de busca Conte do de usu rio Es tipo de busca gt Busca gt Busca avan ada Tode Es ri tipo de p gina E Re tipo de p gina gt Formul rio Figura 25 Modelo de features do dominio web de autoria de conte do D3 Procurar por m quinas de estados muitos subdom nios podem ser representados por m quinas de estados como as telas de um jogo ou o comportamento de uma entidade Se for este o caso este subdom nio ir provavelmente requerer uma DSL m quina de estados para sua variabilidade D4 Procurar por estruturas hier rquicas e de conten o relacionamentos do tipo parte de s o comuns em um dom nio Apesar de normalmente poderem ser representados no 149 modelo de features alguns relacionamentos parte de exigem informa es extras Por exemplo no subdom nio GUI um painel pode conter um ou mais bot es Mas onde
160. am interagir com o restante do software O cen rio o seguinte um modelo de features descreve os pontos comuns e vari veis Um gerador de c digo usa como entrada uma sele o de features subfeatures que faz parte da aplica o gerada e precisa produzir o c digo correspondente Para cada tipo de feature um ou mais padr es do GoF GAMMA etal 1995 utilizado 126 Features alternativas estas s o as features onde somente uma alternativa pode estar presente em uma aplica o Quando uma feature pode ser mapeada diretamente em uma nica classe o padr o Abstract Factory indicado Neste padr o um elemento que realiza o papel de f brica abstrata e um elemento que realiza o papel de produto abstrato representam um ponto de varia o uma feature F bricas e produtos concretos representam variantes alternativas O gerador somente precisa gerar o c digo de instancia o da f brica concreta correspondente e o restante do c digo permanece independente AbstractFactoryFeatureA createFeatureA FeatureA mra SubFeatureA1 SubFeatureA1Factory e RO o Sub feature Sub feature gt l Y createFeatureA FeatureA Sub feature SubFeatureA2 _ SubFeatureA2Factory EA SubFeatureA3 A E D SubFeatureA3Factory eee createFeatureA FeatureA public class UmProduto static AbstractFactoryFeatureA theFactory new SubFeatureAlFactory public static void main
161. amente extensa do ciclo de vida do software Esta n o apenas foi uma das motiva es desta pesquisa mas tamb m foi importante para que a avalia o final que consistiu em colocar a abordagem em pr tica em cen rios reais pudesse ser realizada sem muitas dificuldades Caso a abordagem apresentasse pontos indefinidos ela n o poderia ser utilizada nos estudos emp ricos sem esfor os adicionais Com base nestes crit rios um primeiro ponto a ser ressaltado a cobertura do processo de reutiliza o Trabalhou se com o foco principal no desenvolvimento para a reutiliza o pois sem este o desenvolvimento com reutiliza o n o faz sentido Foram definidas as atividades para construir os artefatos reutiliz veis modelos transformadores geradores etc de forma clara podendo ser seguidas passo a passo em uma organiza o de software O desenvolvimento com reutiliza o de uma maneira sistem tica n o foi abordado Com rela o aos aspectos relacionados ao desenvolvimento orientado a modelos o foco n o est em definir um processo completo para MDD e sim em estender um processo voltado reutiliza o com os conceitos do MDD Assim foram definidas atividades para constru o de modelos transformadores e geradores a serem reutilizados no desenvolvimento de software Est fora do escopo portanto tratar de atividades como manuten o e evolu o destes artefatos Atividades de testes n o s o explicitamente tratadas nes
162. ar features e aplica es respectivamente Algumas vezes comum dividir uma feature em um conjunto de sub features com um relacionamento entre eles para facilitar seu entendimento Com base neste mapa de aplica es realizada uma an lise para identificar quais as features estar o presentes no dom nio e quais n o estar o Este um processo iterativo e n o precisa ser definido em definitivo logo na primeira itera o sendo refinado sucessivamente GRISS FAVARO D ALESSANDRO 1998 Os Quadros 1 e 2 mostram um exemplo de como elaborar o mapa de aplica es No Quadro 1 s o mostradas duas aplica es do dom nio de autoria de conte do para Web e suas features Nota se que neste n vel as features s o identificadas de modo bastante informal pois o objetivo fazer o levantamento inicial Ap s o levantamento ter sido feito com todas as aplica es definidas para o escopo existentes futuras e potenciais feita uma compila o das features de forma a identificar aquelas mais ou menos comuns do dom nio Nesta compila o algumas features podem ter seus nomes alterados enquanto outras podem ser generalizadas ou suprimidas para representar de forma mais correta os conceitos do dom nio O Quadro 2 mostra um exemplo de compila o envolvendo quatro aplica es deste dom nio Aplica o http www americanas com br Descri o Portal web de e commerce para compra de produtos pela Internet Features De
163. ara 43 reutilizar tamb m o c digo a ele associado No MDD isto mais facilmente alcan ado pois o c digo pode ser automaticamente re gerado para o novo contexto e Verifica es e otimiza es os modelos oferecem mais muni o para verificadores sem nticos e otimiza es autom ticas espec ficas de dom nio poderem ser executados Isto pode reduzir a ocorr ncia de erros sem nticos e prover implementa es mais eficientes e Corretude al m do fato de geradores n o introduzirem erros acidentais como erros de digita o geradores permitem que a identifica o de erros conceituais aconte a em um n vel mais alto de abstra o Em resumo as vantagens do MDD derivam da capacidade de evitar que o desenvolvedor precise executar as tarefas repetitivas necess rias para a transforma o de modelos para o c digo final execut vel Isto alcan ado por meio da automa o dessas transforma es O tempo gasto nessas tarefas que no desenvolvimento convencional n o orientado a modelos inibe a execu o do ciclo completo dos requisitos aos testes significativamente reduzido fazendo com que mesmo atividades de urg ncia como corre o de erros possam ser executadas sem produzir inconsist ncia com os modelos mantendo os sempre atualizados Entre as desvantagens causadas pelo MDD alguns autores como Ambler 2003 Thomas 2004 citam as seguintes e Rigidez o MDD causa maior rigidez no software produ
164. as como em termos de cen rios que descrevem as varia es no comportamento Tamb m s o definidos nesta fase os candidatos a subdom nios automatiz veis 115 6 Projeto de dom nio orientado a modelos O projeto do dom nio uma fase essencial da engenharia de dom nio BOSCH 2000 Seu objetivo definir uma arquitetura de software espec fica de dom nio e um conjunto de artefatos reutiliz veis que podem ser combinados para desenvolver aplicativos mais rapidamente e com maior qualidade Uma arquitetura de software espec fica de dom nio uma combina o de componentes de software especializada para um tipo de tarefa em particular dom nio generalizada para uso efetivo neste dom nio e composta em uma estrutura padronizada efetiva para a constru o de aplica es bem sucedidas TRACZ 1995 Em geral a arquitetura deve ser projetada para atender aos principais requisitos conforme percebidos pelos stakeholders de forma a alcan ar os principais atributos de qualidade que s o importantes para uma situa o em particular BASS CLEMENTS KAZMAN 2003 Em termos de engenharia de dom nio um dos pontos principais na defini o da arquitetura do dom nio a reutiliza o de software e a capacidade de se desenvolver produtos de software similares rapidamente sem muitas modifica es ou adapta es nessa arquitetura Isto pode ser alcan ado por meio de um bom suporte comunalidade e variabilidade do dom nio
165. as amea as validade citadas na se o anterior os estudos cont m resultados e ind cios que permitiram a an lise de algumas conclus es relevantes ao contexto 205 desta tese A avalia o permitiu determinar os principais benef cios mas tamb m algumas falhas da abordagem como por exemplo o fato de que os participantes do terceiro estudo n o perceberam utilidade na identifica o de cen rios para descrever as variabilidades nos comportamentos do dom nio alegando ser esta uma tarefa desnecess ria Esta limita o indica que talvez seja preciso uma reestrutura o da abordagem visando aumentar sua agilidade ou mesmo um melhor treinamento visando refor ar a import ncia desta atividade A escolha de qual dire o a ser tomada depende de uma an lise mais aprofundada do problema Tamb m foram identificadas falhas na pr pria avalia o principalmente no terceiro estudo como por exemplo a n o utiliza o do formato de documenta o sugerido e nem dos processos investigativos para identifica o dos subdom nios e de an lise arquitetural Estas s o decorrentes principalmente de restri es execu o do estudo impostas pelo pr prio cen rio industrial em que foi realizado Vale a pena ressaltar que os estudos foram realizados em diferentes ambientes utilizando diferentes tecnologias para o MDD como EMF GMF openArchitectureWare Microsoft Text Templates GME e em diferentes plataformas e linguagens de prog
166. as diversas itera es do seu ciclo de vida conforme descrito na Se o 4 4 medida que novos desenvolvimentos acontecem novas informa es surgem como resultado e passam a ser consideradas durante a atividade de decis o A Figura 13 mostra uma poss vel evolu o dos n veis de decis o referentes a quatro candidatos a subdom nios do dom nio de aplica es de autoria de conte do para Web N veis de decis o Cadastros Cadastros De Cadastros A Ds D D gt Cse O de Usu rio D 2 de Usu rio de Usu rio de Usu rio Ne Er Conte do D de Usuario gt Itera es Figura 13 Poss vel evolu o dos n veis de decis o para o dom nio de aplica es de autoria de conte do para Web Inicialmente toma se uma decis o com base nas informa es dispon veis inicialmente 111 Neste caso o subdom nio de cadastros apresentou um alto grau de confian a por j existirem linguagens e ferramentas dispon veis e que geram c digo conforme requerido pelo projeto Por isso foi colocado no n vel D4 onde inicia se o desenvolvimento dos artefatos de produ o Nas itera es seguintes esse subdom nio passou para o n vel Ds onde iniciou se um projeto piloto e finalmente Ds onde o mesmo passou a fazer parte do dom nio Os subdom nios de navega o e busca foram inicialmente colocados no n vel D3 ficando sob investiga o pois a confian a sobre seu sucesso dentro do dom
167. as enfatizam a implementa o e o suporte a uma linguagem O que se constata que o mesmo que acontece com processos de reutiliza o em geral se repete com rela o a processos de reutiliza o orientados a modelos h uma necessidade de processos sistem ticos para MDD Mais especificamente existe a quest o sobre exatamente onde o MDD pode ser aplicado para automatizar a implementa o de um dom nio Na pr tica sabe se que muito dif cil obter automa o completa isto ser capaz de completamente gerar uma aplica o sem a necessidade de modific la e ou complet la com c digo manualmente escrito Por m existem reas de um dom nio ou subdom nios onde o MDD pode efetivamente elevar a produtividade e reutiliza o Identificar quais s o esses subdom nios e gerenciar seu ciclo de vida de forma que a implementa o final possa integrar tanto o c digo que gerado como o c digo n o gerado que escrito manualmente de forma adequada o foco principal desta tese 1 1 Atese A tese est contextualizada na premissa da literatura de que a combina o entre o desenvolvimento orientado a modelos e reutiliza o de software em um processo sistem tico pode elevar e ou melhorar os n veis de reutiliza o alcan ados por uma organiza o de software 24 quando comparado com um processo n o orientado a modelos Para isso a preocupa o com o MDD deve estar presente em todas as etapas do pro
168. as rela es entre os subdom nios Na Se o 4 4 apresentado um modelo de ciclo de vida que discute este aspecto interativo e iterativo da abordagem proposta Al m das rela es entre os subdom nios o relacionamento entre cada subdom nio e as outras partes do dom nio tamb m precisam ser documentadas de forma que poss vel projetar uma arquitetura que acomode tanto artefatos gerados como n o gerados Atividade PD 3 Escolha de t ticas e padr es arquiteturais Pap is projetista do dom nio especialista do dom nio Entradas PT 7 Diretrizes arquiteturais 124 Sa das PT 8 T ticas e padr es arquiteturais Descri o o objetivo desta atividade selecionar ou definir t ticas e padr es para satisfazer s diretrizes arquiteturais O uso de padr es considerado uma das mais t cnicas mais teis durante a fase de projeto de software Atrav s desta t cnica pode se reaproveitar solu es recorrentes e j comprovadamente bem sucedidas poupando se esfor o e riscos nesta atividade Em termos de projeto arquitetural s o conhecidos como padr es estilos BASS CLEMENTS KAZMAN 2003 ou abordagens CLEMENTS KAZMAN KLEIN 2004 arquiteturais A diferen a entre um padr o arquitetural e um padr o de projeto est na abrang ncia e impacto da solu o Enquanto padr es de projeto normalmente s o utilizados para resolver problemas mais detalhados padr es arquiteturais descrevem solu es mais abrangentes
169. as relacionadas ao projeto de dom nio incluindo projeto arquitetural e suporte variabilidade e MDD ENGI Decidir sobre conven es de modelagem a abordagem possui uma atividade na qual s o analisadas as possibilidades de linguagens a serem utilizadas na modelagem PJM1 Decidir sobre ferramentas de modelagem assim como na atividade ENGI a abordagem tamb m busca analisar ferramentas existentes para serem utilizadas ENG2 Desenvolver modelo t cnico a abordagem n o est focada em um tipo espec fico de modelo e portanto pode ser utilizada para desenvolver modelos t cnicos ENG3 Gerar c digo a partir do modelo t cnico a gera o de c digo um dos principais itens da abordagem e portanto esta pr tica est plenamente implementada ENG5 Desenvolver modelo independente de plataforma a abordagem n o est focada em um tipo espec fico de modelo e portanto pode ser utilizada para desenvolver modelos independentes de plataforma ENG6 Desenvolver transforma es t cnicas modelo para texto a abordagem tem atividades para transforma es modelo para texto visando dar suporte variabilidade do dom nio PJM2 Modelar o processo de MDD do projeto a abordagem est completamente modelada e portanto pode ser utilizada como modelo do processo 83 ENG8 Desenvolver metamodelo centrado na arquitetura o projeto arquitetural voltado ao MDD est presente
170. ase da projeto de dom nio O produto do projeto de dom nio a defini o da arquitetura e seus componentes Nesta 141 Atividades e sub atividades Entradas Sa das PD 1 Escolha dos m dulos a serem refinados PT 3 Validado Modelagem do dom nio PT 4 Validado Candidatos a subdom nio PT 5 Hist rico de decis es inclus o exclus o de subdom nios sobre PT 6 M dulos a serem refinados PD 2 Sele o das diretrizes arquiteturais PD 2 1 Sele o das diretrizes arquiteturais de variabilidade baseada em features PD 2 2 Sele o das diretrizes arquiteturais de variabilidade baseada em DSLs PD 2 3 Sele o das diretrizes arquiteturais de integra o entre subdom nios PT 6 M dulos a serem refinados PT 7 Diretrizes arquiteturais PD 3 Escolha de t ticas e padr es arquiteturais PD 3 1 Padr es arquiteturais para variabilidade baseada em features PD 3 2 Padr es arquiteturais para variabilidade baseada em DSLs PD 3 3 Padr es de integra o entre subdom nios PT 7 Diretrizes arquiteturais PT 8 arquiteturais T ticas e padr es PD 4 Aplica o dos padr es arquiteturais e refinamento dos m dulos PT 6 M dulos a serem refinados PT 7 Diretrizes arquiteturais PT 8 T ticas e padr es arquiteturais PT 9 Inicial Projeto do dominio PD 5 Avalia o arquitetural PT 7 Diretrizes arquiteturais PT 9 Inicial Projeto do dom nio PT 9 Avaliado
171. asos de mudan a facilitou a defini o das linguagens espec ficas de dom nio transforma es e geradores de c digo R Os participantes responderam que estes artefatos ajudaram principalmente na formaliza o de algumas variabilidades que eram compreendidas de forma impl cita pela equipe Atrav s dos casos de uso e de mudan a as diferentes op es de comportamento ficaram mais claras por m a equipe relatou que n o conseguiu 284 identificar uma rela o direta entre os casos de mudan a e um modelo ou um gerador como aconteceu para o modelo de features A equipe ficou um tanto surpresa em notar tantas modifica es que eram feitas em seus produtos de forma ad hoc que foram desenvolvidos para atender o dom nio cient fico mas cada cliente exige mudan as pr prias e usando diferentes funcionalidades sendo que todas essas altera es t m que ser controladas e todo aux lio nesse sentido importante seja gerencialmente pelos coordenadores da equipe ou tecnicamente pelos respons veis pelos casos de mudan a P A identifica o de candidatos a subdom nio facilitou a identifica o das reas do dom nio a serem automatizadas R Sim os participantes enfatizaram que conseguiram identificar pelo menos oito subdom nios onde a automa o iria ajudar em suas tarefas configura o dos arquivos de c digo fonte incluindo instala o banco de dados relat rios gera o de crach s gera o de certifica
172. asse conforme definido na gram tica da linguagem Essas duas m tricas s o absolutas ou seja sabe se que quanto mais atributos e relacionamentos menos compreens vel ser um modelo mas n o se tem uma medida para ser utilizada como par metro para determinar se um modelo ou n o compreens vel e por consequ ncia possui alta manutenibilidade Como valor de refer ncia foi utilizada nesta tese a m dia obtida em experimentos envolvendo diagramas E R e UML conforme descrito por Genero et al 2007 e por Genero Poels e Piattini 2008 _ 42 63 40 22 NA 2 41 425 178 _ 13 13 8 88 8 8 2 A 4 NR 9 595 Portanto truncando se estes valores considerou se neste estudo que modelos com menos de 41 atributos e menos do que 9 relacionamentos possuem maior manutenibilidade do que a m dia As m tricas Mg e Mio permitem a avalia o tanto de modelos visuais e textuais como tamb m seus metamodelos permitindo tamb m avaliar a manutenibilidade das DSLs Quest o Q3 Os participantes que utilizaram a abordagem perceberam durante as atividades da abordagem referentes preocupa o com MDD desde o in cio do desenvolvimento algum benef cio para a implementa o dos artefatos do MDD DSLs transforma es e geradores de c digo Para avaliar se o uso da abordagem desde o in cio do desenvolvimento produz algum benef cio foi realizada uma entrevista com os participantes que utilizaram a abordagem com perguntas
173. aticamente o mesmo para as abordagens de desenvolvimento orientado a modelos utilizadas atualmente como por exemplo a abordagem definida nesta tese A diferen a est principalmente nas ferramentas para modelagem cria o e execu o das transforma es ja que atualmente essas s o baseadas nos conceitos de metamodelagem e n o no uso de gram ticas Este inclusive pode ser um dos motivos pelos quais a abordagem Draco n o se estabeleceu de fato como uma abordagem para o desenvolvimento de software orientado a modelos uma vez que a constru o de gram ticas e transformadores baseados em regras gramaticais e compiladores mostrou se muito complexa para ser aplicada na pr tica WEIS ULBRICH GEIHS 2003 Al m disso as abordagens atuais possuem t cnicas mais apuradas para captura e representa o da variabilidade al m de mecanismos de implementa o mais consolidados A abordagem definida nesta tese define por exemplo padr es de projeto com o objetivo de facilitar o gerenciamento da variabilidade no contexto do MDD Outro diferencial desta tese com rela o ao trabalho de Neighbors uma preocupa o maior com as atividades necess rias para o gerenciamento de m ltiplos subdom nios automatizados No Draco a id ia de m ltiplos dom nios est mais intrinsecamente ligada a conceitos de linguagens de programa o e de modelagem e n o com a divis o natural de um dom nio de aplica es como nesta abordagem Assim a ide
174. atrav s de uma cria o de diagramas segundo uma DSL visual ou ferramentas textuais para a cria o de programas segundo uma DSL textual abordagem top down Normalmente faltam detalhes que s ser o identificados ap s a implementa o 2 Refinado vers o inicial das ferramentas ap s uma abordagem bottom up que identifica mais detalhes para a linguagem PT 13 Transforma es do dom nio Transforma es modelo para modelo e modelo para c digo para serem utilizadas em conjunto com as DSLs do dom nio Nenhum PT 14 refer ncia Implementa o de Uma implementa o do dom nio contendo exemplos das diferentes variabilidades identificadas durante o processo Nenhum PT 15 Framework do dom nio Conjunto de classes reutiliz veis de um dom nio estruturadas de modo a formar um esqueleto de uma aplica o do dom nio com os pontos vari veis bem definidos e mecanismos que possibilitam a sua instancia o Nenhum PT 16 Documenta o do dom nio Documenta o dos diferentes artefatos de implementa o do dom nio incluindo componentes DSLs ferramentas transforma es e geradores de c digo Nenhum Quadro 13 Descri o dos produtos de trabalho da fase de implementa o do dom nio 169 8 Avalia o A combina o entre desenvolvimento orientado a modelos e reutiliza o de software tem como promessa a reutiliza o em alto n vel como defendido pelos
175. bilidade Ela oferece aos engenheiros de software uma maneira sistem tica de pensar sobre e identificar a fam lia de produtos que est o criando ajudando entre outras coisas COPLIEN HOFFMAN WEISS 1998 58 e Na cria o de um projeto que contribui para a reutiliza o e facilita as mudan as e Na previs o de como um projeto pode falhar ou ter sucesso medida que evolui e e Na identifica o de oportunidades para automatizar a cria o dos membros da fam lia Em outras palavras identificando se os pontos comuns e vari veis de um dom nio pode se construir artefatos reutiliz veis que representam os pontos comuns e projetar mecanismos configur veis ou adapt veis para representar os pontos vari veis LEE KANG 2004 Desta forma a reutiliza o antecipada e pode ser efetivamente inclu da como requisito durante a an lise projeto e implementa o do dom nio A SCV realizada em ambas as reas de reutiliza o de software e desenvolvimento orientado a modelos conforme apresenta se nas se es a seguir 3 1 1 SCV na reutiliza o de software Na rea de reutiliza o de software a modelagem de features KANG et al 1990 LEE KANG LEE 2002 amplamente utilizada como mecanismo de representa o da variabilidade LEE MUTHIG 2006 Features s o quaisquer conceitos ou caracter sticas distintas e proeminentes de um dom nio e que s o externamente vis veis a um usu rio ou outros stak
176. cados especificamente nos problemas da reutiliza o e desenvolvimento orientado a modelos visando possibilitar o gerenciamento de m ltiplos subdom nios durante o projeto arquitetural e Realiza o de estudos emp ricos A literatura apresenta pouca evid ncia quantitativa sobre os benef cios do MDD s organiza es de software MOHAGHEGHI DEHLEN 2008 Assim os resultados deste estudo s o relevantes n o somente para avaliar a abordagem definida nesta tese mas tamb m para a comunidade cient fica e industrial interessada em aplicar o MDD e e Elabora o de um material de treinamento em MDD utilizado nos estudos de caso mas que pode ser reaproveitado em cursos de extens o minicursos e tutoriais em eventos relacionados 10 2 Li es aprendidas As contribui es citadas s o de car ter cient fico e acad mico apresentando melhorias e aspectos ainda pouco explorados na literatura Por m com o desenvolvimento deste trabalho diversas li es importantes foram aprendidas Durante esta pesquisa foram estudadas diferentes tecnologias relacionadas ao MDD Neste per odo pode se perceber a evolu o do estado da arte e da pr tica nesta rea H poucos anos atr s a falta de ferramentas e suporte para este tipo de desenvolvimento era uma forte preocupa o A proposta inicial deste trabalho apresentada em 2005 previa o desenvolvimento de parte das ferramentas necess rias para a aplica o do MDD Na poca
177. car esses subdom nios e prover meios para gerenciar seu ciclo de vida e sua integra o considerando a arquitetura final composta por diferentes artefatos de software tais como modelos componentes transforma es e geradores de c digo Com foco em aplica es concretas Identificar o n mero e o tamanho dos sistemas que fazem parte do dom nio uma tarefa que se realizada sem crit rio pode levar a alguns problemas Uma an lise livre tende a incluir diversos requisitos e sistemas que apesar de serem relacionados e pertinentes ao dom nio em quest o podem nunca fazer parte de uma aplica o desenvolvida pela organiza o Assim o escopo do dom nio deve ser restrito a aplica es e produtos de software concretos e n o id ias e conceitos gerais do dom nio A an lise deve focar em aplica es existentes futuras e potenciais CLEMENTS NORTHROP 2002 ALMEIDA et al 2007b buscando coletar organizar armazenar e analisar as experi ncias em sua constru o conforme prev a engenharia de dom nio CZARNECKI EISENECKER 2000 Elevando a import ncia dos modelos Os artefatos reutiliz veis desenvolvidos n o devem se restringir a c digo fonte apenas uma vez que o desenvolvimento centrado no c digo fonte apresenta diversos problemas como discutido na Se o 2 2 Assim a abordagem deve elevar o n vel de import ncia dos modelos no processo MELLOR CLARK FUTAGAMI 2003 de forma que possam n o somente ser util
178. caracter sticas principais dos produtos de trabalho e atividades da abordagem e comparando se com os elementos de processo descritos nos modelos O foco aqui foi oferecer uma vis o mais ampla sobre o escopo e abrang ncia da abordagem frente ao que existe na literatura com rela o s atividades e pr ticas relacionadas reutiliza o e MDD al m de oferecer uma descri o mais detalhada dos modelos de maturidade Modelo de maturidade em reutiliza o de software GARCIA et al 2007 2008 e N vel 1 Incompleto neste n vel apenas o desenvolvimento de software tradicional realizado Pr ticas de reutiliza o s o usadas esporadicamente ou mesmo ignoradas e desencorajadas pela ger ncia Reutiliza o fruto de esfor o individual e os custos da reutiliza o s o desconhecidos N o existem pr ticas definidas para este n vel e N vel 2 B sico este n vel caracterizado pela utiliza o b sica de artefatos com potencial de reutiliza o Engloba algumas atividades b sicas orientadas reutiliza o e a implementa o do dom nio de forma direta sem uma preocupa o com an lise e projeto mais voltados reutiliza o 272 AP1 Manuten o de m todos e t cnicas b sicas de reutiliza o estes devem ser documentados analisados e mantidos sempre atualizados atrav s de revis es peri dicas envolvendo a equipe e a ger ncia A abordagem n o prev o gerenciamento e manuten o
179. ceedings on Object oriented programming systems languages and applications Phoenix Arizona United States ACM Press 1991 p 340 350 JARZABEK S Modeling multiple domains in software reuse In The 1997 Symposium on Software Reusability Boston Massachusetts United States ACM 1997 p 65 74 JEZEQUEL J M MEYER B Design by contract The lessons of Ariane IEEE Computer v 30 n 01 p 129 130 1997 JOHNSON R FOOTE B Designing reusable classes Journal of Object Oriented Programming v 1 n 2 p 22 35 1988 JOHNSON R E Components frameworks patterns In SSR 97 Proceedings of the 1997 symposium on Software reusability Boston Massachusetts United States ACM Press 1997 p 10 17 JOHNSON R E Frameworks components patterns Communications of the ACM v 40 n 10 p 39 42 1997 JOOS R Software reuse at Motorola IEEE Software v 11 n 05 p 42 47 1994 JOUAULT F BEZIVIN J KURTEV I TCS a DSL for the specification of textual concrete syntaxes in model engineering In JARZABEK S SCHMIDT D C VELDHUIZEN T L Ed Fifth International Conference on Generative Programming and Component Engineering GPCE 06 S 1 ACM 2006 p 249 254 ISBN 1 59593 237 2 Dispon vel em lt http doi acm org 10 1145 1173706 1173744 gt Acesso em 14 jun 2009 JOUAULT F KURTEV I On the architectural alignment of ATL and QVT In ACM Symposium on Applied Computing SAC 06 model
180. cesso incluindo a an lise o projeto e a implementa o Neste contexto o foco desta tese est na identifica o de como aplicar o MDD durante a engenharia de dom nio considerando se que n o poss vel automatiz lo completamente A pergunta a ser respondida durante o ciclo de vida da engenharia de dom nio como identificar e gerenciar os subdom nios automatiz veis e produzir uma arquitetura e implementa o finais onde o potencial de automa o destes subdom nios possa ser explorado e integrado com os demais subdom nios A abordagem est centrada no conceito de subdom nios e envolve a explora o dos seguintes pontos referentes uni o entre MDD e reutiliza o de software Como identificar em um dom nio subdom nios que possam ser automatizados por meio de t cnicas do MDD e Como lidar com o fato de que para a identifica o do potencial de automa o de um subdom nio pode ser necess rio um esfor o investigativo que envolve tempo e custos para uma organiza o e Como gerenciar os diferentes subdom nios e diferentes n veis de automa o considerando se que a arquitetura e os componentes produzidos para o dom nio devem ser capazes de promover a integra o entre eles e Como gerenciar a variabilidade no dom nio considerando se que o resultado da engenharia de dom nio inclui n o somente uma arquitetura e componentes reutiliz veis mas tamb m artefatos espec ficos do MDD incluin
181. comportamento de um dom nio completo HADDAD TESSER 2002 Tamb m prejudica a sua reusabilidade uma vez que o escopo exato dos elementos do dom nio e seus relacionamentos dif cil de compreender e gerenciar Por estes motivos alguns autores como Jarzabek 1997 defendem a id ia de que um dom nio deve ser decomposto para facilitar o processo de desenvolvimento para reutiliza o Al m disso grandes sistemas dificilmente podem ser automatizados por um nico gerador Normalmente s o necess rios diferentes geradores trabalhando em conjunto para possibilitar a automa o de um dom nio completo CZARNECKI EISENECKER 2000 Por estes motivos na engenharia de dom nio com a utiliza o de t cnicas do MDD a identifica o dos subdom nios uma tarefa crucial pois permite ao engenheiro de dom nio projetar e implementar ferramentas de modelagem transforma es e geradores espec ficos para os subdom nios que possuem maior capacidade de automa o de forma mais control vel Esta atividade lida com esta identifica o dos subdom nios que podem ser automatizados utilizando t cnicas do MDD com foco no aumento da reusabilidade dos artefatos do dom nio Existem na literatura poucos trabalhos que tratam da decomposi o de um dom nio em subdom nios JARZABEK 1997 HADDAD TESSER 2002 MAIDEN SUTCLIFFE 1996 LEE KANG 2003 Apesar de n o almejarem a cria o de DSLs voltadas para o desenvolvimento orientado a mod
182. conceitos b sicos BIGGERSTAFF RICHTER 1989 conforme citados por Krueger 1992 Abstra o o princ pio essencial da reutiliza o 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 necess rio fazer alguma adapta o quanto esfor o ser necess rio para essa adapta o ou se n o poss vel reutiliz lo Sem abstrair os detalhes o reutilizador gastaria muito tempo examinando cada artefato em busca dessas respostas Pode se tamb m pensar na abstra o como sendo uma separa o entre uma parte vis vel ou abstrata que cont m as informa es mais conceituais necess rias reutiliza o e uma parte escondida que cont m as informa es mais detalhadas normalmente ligadas implementa o Sele o bibliotecas de software principalmente em grandes organiza es tendem a ser imensas envolvendo um grande n mero e diversos tipos de artefatos que podem ser reutilizados Encontrar algo de til em tal cen rio uma tarefa dif cil e uma busca manual pode levar mais tempo do que construir o artefato novamente Por isso a maioria das abordagens para reutiliza o emprega algum tipo de t cnica para agilizar a sele o tais como ndices cat logos busca autom tica entre outras LUCR DIO ALMEIDA PRADO 2004 32 Adapta o a princ pio qualquer artefato pode
183. corator para or features A Figura 19 ilustra o uso do padr o Decorator para implementar or features Para cada ponto de varia o no caso featureA cria se uma classe abstrata que cont m m todos espec ficos desta feature metodol e metodo2 Cria se tamb m um decorator abstrato com um construtor respons vel por incluir o comportamento deste decorator a outro Para cada variante no caso featureA sozinha e as sub features Al A2 e A3 cria se uma inst ncia da classe abstrata principal FeatureASozinha e dos decorators SubFeatureAl Decorator SubFeatureA2Decorator e SubFeatureA3 Decorator O gerador apenas precisa fazer a chamada que cria inst ncias dos decorators que correspondem s variantes selecionadas linhas 3 4 e 5 Da mesma forma que com as features alternativas caso uma or feature precise ser implementada em v rias classes pode se combinar o padr o Facade para reunir mais de uma classe em um nico ponto 131 Features opcionais para features opcionais o mesmo conjunto de padr es utilizados para as or features podem ser utilizados com a diferen a de que neste caso n o necess rio garantir que ao menos uma feature esteja presente na aplica o Para a implementa o de variabilidade baseada em features podem tamb m ser utilizados dois padr es baseados em pr ticas bem conhecidas para a escrita de geradores de c digo CZARNECKI et al 2002 O primeiro padr o conhecido como a abor
184. cos ENG3 Gerar c digo a partir do modelo t cnico ferramentas simples de gera o autom tica de c digo produzem c digo que corresponde ao modelo t cnico A sa da desta atividade o esqueleto do produto de software Envolve tamb m a separa o entre c digo gerado e c digo n o gerado e a complementa o com c digo manual para satisfazer aos requisitos caso a gera o n o produza todo o c digo necess rio A gera o de c digo um dos principais itens da abordagem e portanto esta pr tica est plenamente implementada ENG4 Gerar documenta o a partir do modelo t cnico similar gera o de c digo a documenta o de projeto do sistema pode ser gerada a partir do modelo t cnico ou pelo menos parcialmente Envolve a gera o da documenta o e a complementa o manual caso a documenta o gerada n o seja completa Apesar de ser poss vel gerar qualquer tipo de artefato a abordagem n o define atividades espec ficas para gera o de documenta o e N vel 3 MDD Inicial neste n vel introduz se uma separa o entre modelos de neg cio 271 independentes de plataforma e espec ficos de plataforma O objetivo manter os aspectos de implementa o independentes dos aspectos de neg cio de modo a melhorar a efici ncia do processo de desenvolvimento Neste n vel as pr ticas e artefatos do MDD s o institucionalizadas e um processo definido para o MDD utilizado pela o
185. crescenta uma sobrecarga tanto no processamento para ler e interpretar o valor de entrada deste par metro como na sem ntica dos modelos gerados Assim antes de se aplicar este m todo necess rio avaliar alguns fatores para determinar a sua real necessidade e Peso da variabilidade negativa caso a variabilidade negativa ocorra com pouca frequ ncia pode n o valer a pena gerar outros cen rios apenas para remov la Por exemplo caso apenas 1 das aplica es do dom nio web possuam suporte para busca avan ada a solu o descrita acima pode n o valer a pena e Tamanho da variabilidade negativa variabilidades negativas pequenas s o mais facilmente implementadas utilizando se por exemplo compila o condicional COPLIEN 2000 ANASTASOPOULOS GACEK 2001 J a exist ncia de variabilidades negativas grandes envolvendo por exemplo diversas classes ou cen rios pode indicar uma necessidade de reavalia o Atividade AD 3 Identifica o de subdom nios Pap is analista do dom nio especialista do dom nio 99 Entradas Informa es sobre sistemas do dom nio Conhecimento do especialista Informa es sobre stakeholders PT 1 Inicial Planejamento do dom nio PT 2 Inicial Mapa de aplica es PT 3 Inicial Modelagem do dominio Sa das PT 4 Inicial Candidatos a subdominio Descri o a complexidade da maioria dos dom nios torna virtualmente imposs vel a tarefa de se formalmente especificar o
186. d cada de 70 McCabe 1976 desenvolveu uma t cnica matem tica que prov uma base quantitativa para modulariza o e identifica o de m dulos de software dif ceis de testar ou manter Nesta t cnica uma medida de complexidade apresentada tendo como objetivo medir e controlar o n mero de caminhos em um programa No contexto da reutiliza o a complexidade tem papel fundamental pois artefatos mais complexos possuem menor facilidade de serem reutilizados MASCENA 2007 POULIN 1994 A complexidade ciclom tica calculada a partir de um grafo conectado que representa o fluxo de execu o de um m dulo da seguinte maneira CG E N p onde E n mero de arcos de um grafo N n mero de n s de um grafo e p n mero de componentes conectados Para esta m trica valores entre 1 e 10 indicam que se trata de um m dulo simples sem muito risco Valores entre 11 e 20 representam m dulos moderadamente complexos Valores entre 21 e 50 representam alta complexidade e valores maiores que 50 representam m dulos completamente n o test veis e com alto risco Por ser aplic vel a grafos esta m trica pode ser utilizada diretamente em modelos visuais do tipo grafo Modelos textuais tamb m podem ser transformados em grafos analisando se o metamodelo correspondente Mg ndice de Manutenibilidade A manutenibilidade um atributo desej vel tanto como 176 uma medida instant nea como uma previs o da manutenibilidade co
187. da R A equipe n o chegou a realizar a avalia o arquitetural argumentando que como o tamanho da equipe era pequeno e n o havia a disponibilidade de consultar outros profissionais considerou que n o seria necess rio ou produtivo P As diretrizes de implementa o de DSLs transforma es e geradores de c digo facilitaram a implementa o dos artefatos do MDD R Este foi o ponto mais elogiado pela equipe Por n o terem muito conhecimento sobre o desenvolvimento orientado a modelos os participantes relataram que as diretrizes de implementa o ofereceram dicas importantes na implementa o Em particular foram citadas as diretrizes para mapeamento das features em linguagens o que segundo a equipe foi um ponto crucial no desenvolvimento dos modelos de configura o da linha Eles tamb m reportaram que mesmo que nem todas tenham sido usadas neste estudo elas foram teis para uma melhor compreens o do potencial desta abordagem e das facilidades que podem ser alcan adas no futuro com o MDD 286 P O formato de documenta o proposto foi adequado auxiliando na descri o dos artefatos reutiliz veis desenvolvidos R A equipe n o chegou a documentar os artefatos produzidos alegando que os mesmos foram desenvolvidos apenas como prot tipos experimentais e consideraram mais priorit ria a sua conclus o e evolu o antes da documenta o P Quais foram as vantagens de se utilizar a abordagem de MDD no desenvolvimen
188. dade Enfim o que se observa neste estudo que ocorreu um aumento da reutiliza o em detrimento da simplicidade e facilidade de manuten o de alguns de seus artefatos Em sistemas mais simples pode n o valer a pena o trabalho extra de se desenvolver uma infraestrutura deste tipo Em outras palavras mais f cil e simples codificar do que especificar e gerar c digo Por m em sistemas grandes os benef cios do volume de reutiliza o podem ser muito grandes para serem ignorados Considere por exemplo construir um sistema envolvendo milhares de telas de cadastros todas parecidas e similares muitas delas com detalhes e customiza es necess rias A complexidade extra neste caso pode ser um pre o baixo a ser pago 8 4 2 Aplica es distribu das baseadas em computa o em nuvem A Figura 34 mostra os valores das m tricas de reutiliza o de software obtidas dos artefatos produzidos com e sem a abordagem A exemplo do dom nio web por m em menor grau observa se um aumento significativo na porcentagem de reutiliza o e na raz o de reutiliza o Nota se tamb m que a porcentagem de reutiliza o n o desejada caiu alguns pontos percentuais quando a abordagem foi utilizada Compara o das m tricas de reutiliza o 90 00 80 00 70 00 60 00 50 00 40 00 30 00 20 00 10 00 0 00 Porcentagem Raz o de reutiliza o 65 66 82 66 de reutiliz
189. dagem visitante CZARNECKI HELSEN 2006 O JOUAULT B ZIVIN KURTEV 2006 FEILKAS 2006 Neste padr o o modelo de entrada Ov percorrido e cada elemento visitado Para cada elemento um template correspondente chamado de acordo com o tipo do elemento No cen rio de engenharia de dom nio este padr o particularmente til para diferentes tipos de features mandat rias e opcionais A Figura 20 ilustra este padr o Outras classes EEE E e ote arma 4 oo te GD atte tre NO ea nda gt OE ee ii Ng A ae oe ME a Ma e tua A Classe on O toa tunas e Q Template t te S B feature Al A3 E Template Template ua E A Template A3 Classes geradas A2 Figura 20 Padr o visitante sendo aplicado implementa o de variabilidade baseada em features Neste exemplo um visitante percorre o modelo de features e para cada feature selecionada chama o template correspondente que gera c digo para ela Normalmente cada template produz uma nica classe que implementa a feature que se encaixa na arquitetura atrav s de padr es de projeto como os descritos anteriormente nesta se o O padr o visitante uma boa op o quando poss vel encapsular a funcionalidade de uma feature em uma nica classe Caso n o seja poss vel a abordagem template CZARNECKI HELSEN 2006 pode ser ut
190. de deve ser parte da an lise de dom nio Enquanto analisando as features do dom nio devem existir maneiras para identificar o potencial para automa o em alguns subdom nios numa prepara o para o desenvolvimento de linguagens e transforma es que ir acontecer nas fases seguintes LUCREDIO et al 2008 5 1 Objetivos da an lise de dom nio A fase de an lise de dom nio faz parte da engenharia de dom nio e respons vel por coletar informa es do dom nio para as fases seguintes de projeto e implementa o Nesta fase os seguintes objetivos s o almejados e Coletar registrar e documentar todas as informa es dispon veis sobre o dom nio estas informa es s o coletadas de diversas fontes incluindo o conhecimento de especialistas e desenvolvedores experientes com o dom nio documenta es e padr es sobre o dom nio e tamb m aplica es pertencentes ao dom nio Neste ltimo caso utiliza se toda informa o dispon vel desde os pr prios execut veis at manuais e c digo fonte caso poss vel e Definir o escopo do dom nio a ser desenvolvido um dom nio pode alcan ar uma vasta gama de aplica es cada uma com foco espec fico em determinada parte Al m disso a pr pria defini o do que est dentro ou fora de um dom nio pode variar de acordo com a vis o dos especialistas desenvolvedores ou demais envolvidos pois cada um destes stakeholders possui seus pr prios interesses distintos Des
191. de estados inalcan veis transi es infinitas ou estados mortos estados sem transi es para fora pode ser extremamente trabalhoso Da mesma forma otimiza es mais conceituais podem n o ser t o simples de serem executadas olhando se diretamente para o c digo Por exemplo a remo o de estados redundantes em uma m quina de estados seria facilitada caso houvesse algum tipo de artefato de mais alto n vel associado nttp jakarta apache org struts 40 Enquanto documentos de alto n vel poderiam ser utilizados nestas tarefas os mesmos problemas descritos anteriormente como fardos da modelagem teriam de ser enfrentados Al m disso a valida o e otimiza o autom ticas que em muitos casos s o superiores a um processo manual requerem modelos formais consistentes com a implementa o caso contr rio os resultados seriam inexatos ou mesmo equivocados Portabilidade a ind stria de software extremamente din mica e novas tecnologias e plataformas surgem muito rapidamente oferecendo vantagens que for am as organiza es a se adaptarem rapidamente para n o ficarem desatualizadas em rela o aos principais concorrentes O processo de reengenharia necess rio para portar o software para essas plataformas dispendioso e muitas vezes demorado Por outro lado o surgimento de novas tecnologias pode aumentar a press o existente para a migra o e a estagna o pode ser prejudicial para a organiza
192. de existirem exemplos de modelos ou linguagens espec ficas para o dom nio ou algum subdom nio importante ressaltar que modelos nem sempre possuem uma representa o gr fica que segue alguma linguagem conhecida como a UML por exemplo Outras linguagens incluindo arquivos de configura o e modelos textuais devem tamb m ser consideradas O modelo de features tamb m pode oferecer dicas sobre o que procurar Palavras chave presentes no modelo de features tais como nomes de features podem ocorrer dentro da documenta o ou c digo fonte Ap s esta an lise criada uma lista com as linguagens identificadas associando as com os subdom nios correspondentes Sub atividade AD 3 3 Identifica o de ferramentas A exemplo das linguagens espec ficas de dom nio a exist ncia de uma ferramenta de configura o ou modelagem um indicativo de que o subdom nio em quest o apresenta alto grau de maturidade e portanto as chances da reutiliza o de software orientada a modelos ter sucesso s o maiores Em dom nios extremamente maduros podem existir at geradores de c digo que podem ser reaproveitados Novamente o conhecimento do especialista do dom nio essencial mas manuais e documenta o tamb m devem ser consultados uma vez que eles podem referenciar ferramentas usadas para criar modelos ou gerar partes da aplica o O c digo fonte tamb m deve ser inspecionado pois comum a exist ncia no c digo g
193. de frameworks padr es e outras t cnicas eventualmente chegar o dia em que nossa capacidade de construir software n o ser capaz de atender demanda Assim como em outras ind strias a automa o pode aumentar esta nossa capacidade suprindo nossas defici ncias e limita es relacionadas ao desenvolvimento de software 10 1 Principais contribui es Nesta disserta o busca se resolver parte do problema da reutiliza o atrav s do desenvolvimento orientado a modelos Ap s estudos e pesquisas nas reas relacionadas foi definida uma abordagem orientada a modelos para reutiliza o de software visando guiar o engenheiro de software desde as atividades iniciais de an lise at a implementa o de artefatos reutiliz veis de um dom nio utilizando o desenvolvimento orientado a modelos para elevar e melhorar a reutiliza o Neste sentido as seguintes contribui es foram feitas nesta rea 228 e Uma abordagem sistem tica e bem definida contendo atividades entradas e sa das que detalham as tarefas necess rias para que a engenharia de dom nio possa incorporar as t cnicas do desenvolvimento orientado a modelos Em particular foi definido um m todo concreto para identifica o de m ltiplos subdom nios incluindo diretrizes de apoio e um processo investigativo interativo e iterativo adequado natureza incerta e evolutiva desta rea e Identifica o de um conjunto de diretrizes e padr es arquiteturais fo
194. de linguagens espec ficas de dom nio gera o de c digo entre outras fun es O UMT QVT 4 5 uma ferramenta de c digo aberto que permite realizar transforma es conforme exige o MDD Um modelo serve de entrada para a ferramenta no formato XMI que ent o convertido para um formato intermedi rio As transforma es s o baseadas em XSLT W3C 1999b ou mesmo implementadas manualmente em linguagem de programa o O principal problema dessa abordagem est na dificuldade em se construir transformadores dessa forma principalmente para transformar modelos Neste sentido as abordagens que utilizam linguagens visuais para defini o de transformadores como QVT e ATL s o mais apropriadas O MTF Model Transformation Framework da IBM cont m um conjunto de ferramentas que auxiliam desenvolvedores em compara es valida es e cria o de transforma es entre modelos EMF Tamb m mant m um registro dos elementos transformados permitindo rastreamento entre elementos gerados e a gera o de relat rios para o usu rio baseado em uma linguagem para defini o dos mapeamentos entre os modelos em um mecanismo de transforma o capaz de interpretar esses mapeamentos em um editor para as transforma es e no suporte para gera o de texto a partir de modelos Finalmente o projeto openMDX foca na implementa o dos conceitos da MDA ou seja o modelo a implementa o Por m a inser o de informa
195. de m todos e t cnicas para reutiliza o Z AP2 Planejamento de reutiliza o deve ser realizado de acordo com um procedimento pr definido e documentado O planejamento deve incluir an lise de riscos e determina o das abordagens de reutiliza o a serem utilizadas O ciclo de vida do processo de reutiliza o deve tamb m ser identificado durante o planejamento Uma das atividades iniciais da abordagem consiste no planejamento da reutiliza o incluindo poss veis riscos e a ado o desta abordagem pode ser considerada como uma decis o de planejamento assim como a defini o de seu modelo do ciclo de vida Z AP3 Defini o dos objetivos da reutiliza o assim como a estrat gia adotada a defini o dos objetivos deve ser realizada por um grupo com autoridade e conhecimento para esta tarefa Os objetivos e estrat gia devem ser documentados Tamb m devem ser definidos documentados e implantados os indicadores de desempenho a serem utilizados para determinar se os objetivos est o sendo alcan ados no processo A abordagem cont m uma atividade para defini o dos objetivos da reutiliza o AP4 Implementa o do dominio visa produzir artefatos de software reutiliz veis para o dom nio atrav s de codifica o testes documenta o e empacotamento destes artefatos Envolve basicamente a defini o das interfaces providas e requeridas dos artefatos reutiliz veis testes de unidade com os artefatos doc
196. de nos diferentes tipos de artefatos produzidos com a abordagem no dom nio de aplica es distribu das baseadas em computa o em NUVEM fb eee be RA PELES DE RE ES Distribui es de n meros de atributos e relacionamentos nos modelos utilizados com a abordagem no dom nio de aplica es distribu das baseadas em c mp ta o em TV OTN s ss e a MP hig ED og e ab MP e Mig Bat DE DR ah rts Compara o entre as m tricas de reutiliza o para o estudo do dominio de eventos cientificos s ses r ekeen ne Kaena ano a ko aG Compara o entre as m tricas de reusabilidade dos estudos dos dom nios de eventos cient ficos EC Web e Computa o em Nuvem CN Efeito da abordagem na reusabilidade dos artefatos produzidos Uma poss vel hip tese alternativa elaborada a partir dos resultados da avalia o Processo de refinamentos sucessivos na abordagem Draco Situa o cl ssica da an lise de sistemas 000 10 11 12 13 14 15 16 17 Lista de Quadros Identifica o inicial das features de duas aplica es do dom nio de autoria de conte do para Web atas oe a Ee E A OER DS a Compila o das features de quatro aplica es do dom nio de autoria de cont udo para Web oa tao tat a eS be a E EN ES E Exemplo de caso de uso do dom nio web a oaa Exemplo de caso de mudan a para a feature opcional de busca Exemplo de caso d
197. deling ODM Guidebook Version 2 0 S 1 1996 STARS Technical Report STARS VC A025 001 00 Lockheed Martin Tactical Defense Systems Manassas VA SOMMERVILLE I Software Engineering 8 ed S 1 Addison Wesley 2006 STARS Software Technology for Adaptable Reliable Systems STARS The Reuse Oriented Software Evolution ROSE S 1 1993 Unisys STARS Technical Report Advanced Research Projects Agency ARPA STARS Technology Center 801 N Randolph St Suite 400 Arlington VA 22203 STEFFEN B et al Model Driven Development with the jABC In Hardware and Software Verification and Testing Berlin Heidelberg Springer Verlag 2007 Lecture Notes in Computer Science v 4383 2007 p 92 108 SVAHNBERG M GURP J van BOSCH J A taxonomy of variability realization techniques Research articles Softw Pract Exper John Wiley amp Sons Inc New York NY USA v 35 n 8 p 705 754 2005 ISSN 0038 0644 SVANHBERG M GURP J van BOSCH J A Taxonomy of Variability Realization Techniques S 1 2002 Technical paper ISSN 1103 1581 Blekinge Institute of Technology Sweden 2002 SZYPERSKI C Component Software Beyond Object Oriented Programming S 1 Addison Wesley 1999 SZYPERSKI C GRUNTZ D MURER S Component Software Beyond Object Oriented Programming Second Edition S 1 Addison Wesley ACM Press 2002 250 TAULAVUORI A NIEMELA E KALLIO P Component documentation a key issue in
198. delo Espec fico de Plataforma Um CIM uma vis o do sistema de um ponto de vista que n o depende de computa o Um CIM n o mostra detalhes da estrutura dos sistemas E tamb m conhecido como modelo do dom nio e utiliza um vocabul rio familiar aos profissionais e especialistas no dom nio em quest o OMG 2003 Um PIM uma vis o do sistema de forma independente da plataforma de implementa o Essa independ ncia de plataforma no entanto chega at um certo n vel de forma que o mesmo modelo possa ser reaproveitado em diferentes plataformas do mesmo tipo OMG 2003 Um PSM uma vis o do sistema do ponto de vista de uma plataforma espec fica Um PSM combina as especifica es de um PIM com detalhes sobre como o sistema utiliza aquele tipo particular de plataforma OMG 2003 Na MDA transforma es s o utilizadas para transformar um modelo em outro sucessivamente at o c digo fonte A transforma o entre CIM e PIM menos pass vel de automa o pois envolve mais decis es e maiores possibilidades de interpreta o dos requisitos J a transforma o entre PSM e c digo fonte mais pass vel de automa o j que o PSM est intimamente ligado com a plataforma de implementa o A base da MDA o MOF Meta Object Facility OMG 2006b o meta metamodelo que serve de base para a defini o de todas as linguagens de modelagem devido ao MOF que as ferramentas de modelagem e transforma o
199. dendo altura este investimento em mim realizado Agrade o ao grupo RiSE Reuse in Software Engineering e as suas institui es de apoio UFPE e C E S A R em Recife PE Tenho orgulho em ter participado do come o desta iniciativa junto com Eduardo Santana de Almeida Vinicius Cardoso Garcia e Alexandre Alvaro sob a orienta o de Silvio Meira Se hoje o RiSE est entre os principais grupos de reutiliza o do mundo porque realmente compreendemos o verdadeiro significado da palavra colabora o Durante o doutorado passei seis meses na George Mason University em Fairfax VA Estados Unidos sob a orienta o de Jon Whittle onde aprendi muitas coisas somente algumas delas contidas nesta tese de uma forma ou de outra Foram tamb m tr s meses em Redmond WA Estados Unidos na Microsoft Research sob a orienta o de Ethan Jackson e Wolfram Schulte em outro grupo RiSE esse chamado Research in Software Engineering Este est gio foi parte de um pr mio que recebi o Latin American Fellowship Award 2008 2009 oferecido pela Microsoft Research Posso seguramente dizer que essa experi ncia deixou marcas e aprendizados que foram al m de todas as minhas expectativas e imposs vel n o ficar grato pelo reconhecimento de meu trabalho Agrade o tamb m a Jaime Puente Juliana Salles e toda a equipe da Microsoft respons vel por essa tima iniciativa Obrigado Aptor Software por acreditar neste projeto cedendo parte d
200. dentificados devem ser inclu dos ou exclu dos do processo e quais precisam ser investigados de maneira mais aprofundada Atividade AD 5 A seguir estas cinco atividades s o descritas em maiores detalhes Atividade AD 1 Planejamento do dominio Pap is analista do dom nio especialista do dom nio especialista de mercado Entradas Informa es sobre sistemas do dom nio Conhecimento do especialista Informa es sobre stakeholders Sa das PT 1 Inicial Planejamento do dominio PT 2 Inicial Mapa de aplica es Descri o a primeira etapa cuida da prepara o e planejamento E necess rio determinar se vale a pena investir na constru o da infraestrutura reutiliz vel para o dom nio em quest o Para isso nesta atividade s o levantadas e registradas todas as informa es referentes ao dom nio Inicialmente realizada uma tarefa de prepara o Sub atividade AD 1 1 onde s o realizadas diversas an lises tais como identifica o dos stakeholders an lise do mercado coleta de informa es e defini o de objetivos e restri es de acordo com as an lises e informa es coletadas Em seguida realizada a defini o do escopo Sub atividade AD 1 2 onde as aplica es existentes futuras e potenciais s o identificadas e o escopo do dom nio definido Sub atividade AD 1 1 Prepara o O objetivo da prepara o levantar e registrar todas as informa es necess rias para o planejame
201. do linguagens transforma es e geradores de c digo e Como gerenciar a exist ncia de c digo gerado com c digo n o gerado nos diferentes n veis de abstra o em que s o realizadas as atividades de an lise projeto e implementa o e Em quais aspectos o MDD pode influenciar na reutiliza o de software O MDD promove aumento e ou melhoria na reutiliza o Quais s o os custos benef cios de utiliza o do MDD em um processo de engenharia de dom nio Para validar esta tese foi definida uma abordagem sistem tica para reutiliza o de software utilizando t cnicas do desenvolvimento orientado a modelos e que cobre 25 as etapas de an lise projeto e implementa o de um dom nio reutiliz vel Foram tamb m realizados estudos emp ricos visando avaliar a abordagem definida e determinar o impacto do MDD na reutiliza o de software 1 2 Defini o do escopo importante ressaltar que o foco deste trabalho n o foi pesquisar cada uma das linhas de pesquisa reutiliza o e MDD de forma individual e em profundidade Isso seria um trabalho extremamente complexo que excederia o tempo estipulado para uma pesquisa em n vel de doutorado Ao inv s disso buscou se combinar as t cnicas j estabelecidas em um processo novo de maneira a agregar os benef cios de ambas abordagens Al m disso foi priorizada a defini o de uma abordagem pr tica sem lacunas e us vel em vez de uma cobertura demasiad
202. do mapeamento corre se o risco de se projetar uma arquitetura incapaz de atender a todos os requisitos de forma adequada Al m disso um nico estilo arquitetural C2 suportado 2 Finalmente a abordagem de P rez Mart nez e Sierra Alonso 2006 focada no desenvolvimento de produtos nicos n o cobrindo aspectos relativos reutiliza o como suporte variabilidade e deriva o de produtos como o caso desta tese V lter e Groher 2007 descrevem um conjunto de t cnicas para combinar MDD e linhas de produtos de software Suas id ias sobre a combina o de t cnicas est o de acordo com a filosofia da abordagem desta tese tais como o suporte aos dois tipos principais de variabilidade baseada em features configura o e DSLs constru o criativa Adicionalmente os autores utilizam t cnicas orientadas a aspectos para facilitar a modelagem e implementa o das variabilidades ortogonais o que n o tratado nesta tese A principal diferen a desta tese em rela o ao trabalho de V lter e Groher que aqui proposta uma abordagem sistem tica com atividades e diretrizes concretas para desenvolver a infraestrutura de reutiliza o orientada a modelos para o dom nio Al m disto a abordagem desta tese tamb m identifica a necessidade do suporte simult neo a m ltiplos subdom nios o que n o mencionado por V lter e Groher Robbes e Lanza 2008 descrevem um sistema de suporte transforma o de
203. do 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 benef cios da reutiliza o sejam alcan ados por meio de pr ticas eficientes de trabalho disseminadas facilmente entre os indiv duos de uma organiza o sem depender de talentos individuais A necessidade de um processo sistem tico de reutiliza o Em termos de reutiliza o de software faz se necess rio um m todo flex vel que possa ser adaptado para diferentes situa es que possua diretivas e suporte suficientes e que n o seja muito vago caso contr rio o mesmo n o ir atender s necessidades de variadas situa es da ind stria sem uma forte interpreta o e suporte adicionais BAYER et al 1999 Essa opini o compartilhada por muitos autores da rea de reutiliza o podendo ser encontrada em relat rios de empresas ENDRES 1993 BAUER 1993 GRISS 1994 1995 JOOS 1994 pesquisas informais FRAKES ISODA 1994 e estudos emp ricos RINE 1997 MORISIO EZRAN TULLY 2002 ROTHENBERGER et al 2003 Todos esses trabalhos mostraram que adotar um processo pode ser uma maneira efetiva de se alcan ar os benef cios da reutiliza o de software Por m os processos existentes atualmente apresentam algumas falhas e falta de detalhes em atividades importantes tais como o desenvolvimento para reutiliza o e o desenvolvimento com
204. dom nio e portanto possibilitam sua conserva o e reutiliza o e DSLs possibilitam valida o e otimiza o no n vel do dom nio e e DSLs facilitam a testabilidade das aplica es As desvantagens de se utilizar DSL s o DEURSEN KLINT VISSER 2000 e O custo para se projetar implementar e manter uma DSL e O custo de treinamento para usu rios da DSL e A pouca disponibilidade de DSLs e A dificuldade de se definir um escopo adequado para uma DSL e A dificuldade de se balancear entre especificidade ao dom nio e linguagens de programa o gen ricas e 261 e Para os casos de DSLs execut veis a perda potencial de desempenho quando comparado com c digo constru do m o Alguns dos benef cios das DSLs como aumento da produtividade confiabilidade manutenibilidade portabilidade a reutiliza o de conhecimento sobre o dom nio entre outros podem ser igualmente alcan ados por meio da utiliza o de frameworks descritos mais adiante neste ap ndice ou outras t cnicas de reutiliza o Dessa forma frente s suas desvantagens pode se argumentar que em alguns casos o uso de DSLs desnecess rio J outros benef cios como a possibilidade de se trabalhar nos termos e no n vel de abstra o do dom nio do problema s podem ser obtidos por meio de DSLs Neste sentido a decis o de se utilizar ou n o essa t cnica se resume an lise dos benef cios obtidos versus o custo necess rio para cons
205. dor pode ser aplicado em conjunto com as t cnicas descritas na se o anterior A diferen a que um gerador possui um grau a mais de liberdade podendo introduzir varia es tamb m no momento da gera o Com isto a granularidade das partes variantes est abaixo do n vel de componentes ou seja o pr prio c digo dentro do componente pode ser feito gen rico Isto alcan ado atrav s de fragmentos de c digo variantes que podem ser sistematicamente arranjados para produzir a implementa o de um componente MUTHIG PATZKE 2004 Para construir geradores normalmente o uso de templates preferido Um template um arquivo de texto qualquer instrumentado com constru es de sele o e expans o de c digo CZARNECKI EISENECKER 2000 Estas constru es s o respons veis por realizar consultas em uma entrada que pode ser um programa ou especifica o textual um conjunto de janelas e di logos no estilo wizard ou mesmo diagramas CLEAVELAND 1988 A informa o resultante destas consultas ent o utilizada como par metro para produzir c digo personalizado em qualquer linguagem textual Para ilustrar este processo considere o seguinte cen rio uma empresa deseja agilizar a produ o de formul rios HTML para incluir em sua aplica o Web Existem centenas de formul rios distintos e os campos de cada formul rio mudam constantemente de forma que a manuten o deste conjunto de p ginas normalmente trabalhosa
206. dores a Sun por meio de sua plataforma NetBeans busca oferecer ao desenvolvedor a op o de se trabalhar simultaneamente no modelo e c digo fonte seguindo as id ias do MDD Com essa motiva o a Sun concentra seus esfor os em oferecer ferramentas que sigam os padr es OMG principalmente com duas iniciativas e JMI Java Metadata Interface trata se de um mapeamento das interfaces MOF para a linguagem Java de forma a possibilitar a manipula o de modelos compat veis com o MOF utilizando programa o Java e e MDR MetaData Repository um subprojeto NetBeans e consiste em um mecanismo gen rico de manipula o de modelos como o discutido no in cio deste cap tulo Com base no padr o MOF capaz de importar exportar modelos segundo o padr o XMI e disponibiliza interfaces no padr o 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 edi o visual de modelos gera o de c digo entre outras beneficiando se das interfaces padr o JMI Parte dessas funcionalidades gen rica permanecendo a mesma para qualquer metamodelo enquanto outra parte criada de forma espec fica para cada metamodelo conforme as regras do MOF O MDR implementa diretamente a parte gen rica enquanto a parte espec fica automaticamente gerada a partir da descri o do metamodelo em um arquivo no formato XMI
207. dos configura o de boleto banc rio configura o de idiomas suportados incluindo idioma padr o e processamento de arquivos de pagamento do banco retornos financeiros Estes subdom nios consistem principalmente de pontos particularmente problem ticos e trabalhosos para configura o manual j conhecidos pela equipe ap s sua experi ncia com atendimento a seus clientes Segundo a equipe o uso do modelo de features facilitou na identifica o destes pontos P A identifica o de candidatos a subdominio facilitou a defini o das linguagens espec ficas de dom nio transforma es e geradores de c digo R Com rela o a esta quest o a equipe salientou que a divis o em subdom nios facilitou na defini o do escopo dos artefatos de gera o de c digo que podem ser focados em partes pequenas do problema tornando seu desenvolvimento mais simples Por m eles apontaram a falha de que a exist ncia de m ltiplos subdom nios exige tamb m m ltiplas etapas na gera o de c digo j que cada gerador precisa ser executado separadamente para cada subdom nio o que dificulta quando necess rio gerar c digo repetidas vezes P O processo investigativo baseado em decis es para inclus o exclus o de subdom nios foi utilizado Se sim ele facilitou o processo de desenvolvimento dos artefatos do MDD R A equipe n o soube responder esta quest o de forma apropriada pois reportou que apenas foi feita uma decis
208. e COMPSAC USA s n 2003 p 250 256 MELLOR S J CLARK A N FUTAGAMI T Model driven development IEEE Software v 20 n 5 p 14 18 2003 MERNIK M HEERING J SLOANE A M When and how to develop domain specific languages ACM Computing Surveys v 37 n 4 p 316 344 dez 2005 ISSN 0360 0300 MILI H et al Reuse Based Software Engineering Techniques Organization and Controls S 1 John Wiley amp Sons 2002 MILI H MILI F MILI A Reusing software Issues and research directions EEE Transactions on Software Engineering v 21 n 6 p 528 562 1995 MODELWARE Architecture and Platform Modelling Profiles S 1 2006 MODELWARE Definition of Reusable Transformations S 1 2006 Dispon vel em lt http www modelware ist org gt Acesso em 14 jun 2009 MODELWARE Engineering Metrics Definition Sl 2006 Dispon vel em lt http www modelware ist org gt Acesso em 14 jun 2009 MODELWARE MDD Maturity Model SI 2006 Dispon vel em lt http www modelware ist org gt Acesso em 14 jun 2009 MODELWARE MDD Process Framework SI 2006 Dispon vel em lt http www modelware ist org gt Acesso em 14 jun 2009 MODELWARE Model Transformation Tool Suite Prototype S 1 2006 Dispon vel em lt http www modelware ist org gt Acesso em 14 jun 2009 MODELWARE ModelBus Functional amp Technical architecture document Vols I and II S 1 2006 Dispo
209. e especialista do dom nio Aqui o foco tentar reduzir o n mero de cen rios para aqueles que possuem impacto na arquitetura e tentar incluir o ponto de vista de outros stakeholders tais como usu rios finais gerentes testadores etc Pode se utilizar sess es de brainstorming para capturar o m ximo de informa o poss vel 2 Avaliar cen rios individualmente neste passo a exemplo do m todo SAAM citeClements 2004 book evaluating cada cen rio avaliado de forma individual por meio de workshops mediados pelo projetista onde se discute como o cen rio est ou n o sendo atendido pelas diferentes arquiteturas Pode se tamb m desenvolver prot tipos DEBAUD FLEGE KNAUBER 1998 com funcionalidades simuladas que refletem o cen rio sendo avaliado Para cada cen rio o projetista descreve como a arquitetura oferece o suporte ou descreve as mudan as necess rias e 3 Avaliar intera o entre os cen rios uma vez que se tenha as descri es de mudan as referentes ao suporte aos cen rios este passo tem como objetivo destacar quais cen rios interagem entre si isto exigem mudan as no mesmo local ou grupo de m dulos componentes reas onde existe grande intera o entre cen rios podem significar pontos onde o projetista falhou em corretamente implementar a separa o de interesses e portanto pode ser necess ria maior aten o nesta rea ou mesmo uma nova passagem pelas atividades de projeto CLEMENTS KAZMAN
210. e M3 referentes quest o Q apresentam problemas por n o considerar a natureza dos artefatos reutiliz veis e nem a maneira com que estes s o reutilizados penalizando por exemplo grandes sistemas e sistemas pouco modularizados monol ticos MASCENA ALMEIDA MEIRA 2005 MASCENA 2007 ALMEIDA et al 20074 Por este motivo existe outra vertente que defende a id ia de que melhor tentar medir a reutiliza o atrav s da avalia o de atributos de qualidade que influenciam a reusabilidade de um determinado artefato de software Neste sentido s o sugeridas m tricas indiretas como manutenibilidade e complexidade POULIN 1994 Estas medidas talvez ofere am uma vis o melhor sobre os reais benef cios da abordagem j tendo sido utilizadas com sucesso em outros estudos relacionados reutiliza o de software como por exemplo o trabalho de Almeida et al 2007a Assim as seguintes m tricas foram definidas para esta quest o Me Instabilidade de m dulo De acordo com Martin 1994 o que torna um software r gido fr gil e dif cil de ser reutilizado a interdepend ncia entre seus m dulos Um software r gido se ele n o puder ser facilmente modificado isto uma nica mudan a inicia uma cascata de mudan as em diferentes m dulos Al m disso quando a extens o da mudan a n o pode ser prevista pelo projetista seu impacto n o pode ser estimado o que dificulta a estimativa de custos tornando o software r g
211. e cen rios dos dom nios conforme ilustra a Figura 43 Em dom nios t cnicos mais simples a abordagem proporciona maior quantidade de reutiliza o mas menor reusabilidade dos artefatos sendo mais indicada para quando h a necessidade de gera o de grande volume de c digo Em dom nios t cnicos mais complexos a abordagem simplifica o desenvolvimento quando a codifica o extremamente complexa Em dom nios de neg cio ela pode facilitar o processo de configura o e reduzir os problemas causados com a prolifera o de vers es Esta hip tese alternativa resume muitas das experi ncias vivenciadas nesses tr s estudos 202 Instabilidade Complexidade Dificuldade de manuten o Constante 0 Sem abordagem Com abordagem Figura 42 Efeito da abordagem na reusabilidade dos artefatos produzidos e explica de forma plaus vel os efeitos observados Por m ela foi extrapolada n o sendo embasada por evid ncias mais s lidas Estudos mais rigorosos podem e devem ser realizados para complementar estes resultados e o conhecimento adquiridos nesta tese para que generaliza es estatisticamente comprovadas possam ser formuladas 8 6 Amea as validade Os dados obtidos com esta avalia o s o bastante informativos e abrangentes Por m h muitas quest es que sequer chegaram a ser exploradas tais como o impacto da abordagem nos n veis de reutiliza o internos como aqueles alcan ados com heran a por exemplo A
212. e como realizado atualmente Talvez a maior mudan a que se pode testemunhar desde o nascimento da ci ncia da computa o foi o grau com o qual computadores se tornaram essenciais em nossas vidas Apenas imagine como sua rotina di ria seria afetada se voc n o tivesse acesso a nenhum tipo de dispositivo computacional e voc poder perceber o qu o incrivelmente pervasiva esta tecnologia se tornou Neste sentido o software a alma de um computador respons vel pela opera o destas m quinas vitais precisa sobreviver em tal cen rio de mudan as dr sticas e constantes A hist ria mostrou que cientistas e profissionais da rea da computa o especialmente aqueles envolvidos com desenvolvimento de software s o especialistas na arte da mudan a Novas linguagens de programa o e ambientes de desenvolvimento integrados sempre buscaram seguir os avan os do hardware e foram razoavelmente bem sucedidos at ent o Mas chegou se a um ponto onde o software deve ser n o apenas confi vel mas tamb m operar em ambientes computacionais embarcados e distribu dos comunicar se utilizando uma grande variedade de paradigmas de comunica o e se adaptar dinamicamente a mudan as nos ambientes operacionais FRANCE RUMPE 2007 Isto se deve n o apenas s tecnologias utilizadas que se tornaram significativamente mais complexas nos ltimos anos mas tamb m porque estas tecnologias mudam mais rapidamente do que os neg cios para os
213. e compara o entre duas vers es de um software que acontece em sistemas de controle de vers es como CVS ou SVN Compara se cada exemplo que introduz uma varia o com o exemplo original registrando se todas as altera es obtendo se um delta que representa a inclus o da variante Na pr tica por m a busca por tais altera es exige um conhecimento aprofundado do c digo e do dom nio A melhor maneira de encontr las manter o registro das mudan as ROBBES LANZA 2008 medida que s o feitas nos exemplos constru dos durante o desenvolvimento da implementa o de refer ncia por meio de um documento separado ou mesmo com coment rios e anota es no pr prio c digo Cada trecho modificado do c digo precisa ser mapeado em pelo menos uma variante descrita em uma DSL ou modelo de features Se existir uma modifica o mas n o existirem elementos em uma DSL que a descrevam ent o a DSL provavelmente precisa ser refinada sub atividade ID 3 3 Em alguns casos uma modifica o pode aparentemente ser mapeada para diferentes elementos de uma ou mais DSLs o que significa que esta modifica o pode ser causada por diferentes variantes simultaneamente Se for este o caso deve se tomar cuidado especial na implementa o do suporte a estes pontos de varia o quando ambos forem selecionados ao mesmo tempo Finalmente pode acontecer de muitas modifica es em v rias partes da implementa o de 159 refer nci
214. e e a redu o da manutenibilidade observados quando a abordagem utilizada Estas diferen as podem ser vistas de forma geral Figura 29 mas s o particularmente n tidas quando se avalia os diferentes tipos de artefatos do MDD individualmente Figuras 30 31 e 32 Os artefatos de gera o de c digo e modelos de dom nio s o consideravelmente mais complexos e dif ceis de manter do que o restante do c digo Observando se os artefatos nota se que isto se deve ao grande n mero de instru es condicionais la os e a exist ncia de repetidas consultas aos modelos que s o feitas nas transforma es e geradores Ou seja o grande n mero de par metros citados anteriormente como necess rios para realizar a variabilidade em um componente foram migrados para os artefatos do MDD tornando os complexos e dif ceis de manter No entanto estes artefatos s o modificados muito raramente pois uma vez testados e validados somente precisam ser alterados para efetuar corre es de erros ou evolu o no dom nio Al m disso e esta a principal diferen a entre um gerador e um componente um gerador 193 n o efetivamente reutilizado no software final e sim o produto de sua gera o de c digo com caracter sticas de reusabilidade pr ximas ao c digo n o gerado J os modelos apesar de no geral serem mais complexos e dif ceis de manter do que o c digo s o relativamente pequenos e em n mero reduzido o que compensa sua complexi
215. e mudan a para a feature alternativa de busca avan ada Documenta o do subdom nio de navegagao 2 2 006 Documenta o do n vel de confian a dos subdom nios identificados Resumo das atividades para an lise de dom nio orientada a modelos Descri o dos produtos de trabalho da fase de an lise de dom nio Resumo das atividades para projeto de dom nio orientado a modelos Descri o dos produtos de trabalho da fase de projeto de dom nio Resumo das atividades para implementa o do dom nio orientada a modelos Descri o dos produtos de trabalho da fase de implementa o do dom nio Dados sobre o estudo envolvendo o dominio de autoria de conte do para Web Dados sobre o estudo envolvendo o dom nio de aplica es distribu das baseadas em computa o em nuvem ma Ss Ake Vs ae Ata A CA A Dados sobre o estudo envolvendo o dom nio de eventos cient ficos Resumo das principais t cnicas relacionadas aos conceitos b sicos da reutiliza o d SoftWare 2 pa spa pa Dee E ee OSE a Be 95 106 107 112 113 141 142 167 168 183 Lista de Acr nimos ADD Attribute Driven Design Projeto Orientado a Atributos AOP Aspect Oriented Programming Programa o Orientada a Aspectos AST Abstract Syntax Tree rvore de Sintaxe Abstrata ATL Atlas Transformation Language Linguagem de Transforma o Atlas BNF Backus Naur Form Forma de
216. e o alto grau de coopera o entre os componentes distribu dos Este estudo foi realizado durante um est gio de doutorado realizado pelo autor da tese nos laborat rios da Microsoft Research em Redmond Estados Unidos LUCR DIO JACKSON SCHULTE 2008 Este dom nio j vinha sendo explorado pelos pesquisadores da Microsoft Research que desenvolveram uma teoria baseada em modelagem de neg cios e um conjunto de tr s linguagens espec ficas para este objetivo JACKSON SCHULTE 2008 uma linguagem visual para descrever os dados do sistema uma linguagem visual para descrever as caracter sticas dos tipos de elementos distribu dos sua conectividade e quais dados possuem e uma linguagem visual para descrever a sem ntica das opera es de manipula o dos dados O aspecto mais interessante desta especifica o que os modelos de dados e opera es n o precisam se preocupar com a localiza o dos dados e nem que tipo de elemento distribu do respons vel por sua manuten o 184 A teoria diz que poss vel gerar c digo respons vel pela execu o distribu da das opera es e verifica o de integridade global do sistema de acordo com regras espec ficas definidas nos modelos Trata se de um dom nio predominantemente t cnico envolvendo os aspectos de execu o distribu da e computa o em nuvem mas com um componente de neg cios uma vez que as regras de neg cio podem ser definidas utilizando a linguagem de
217. e produtividadeA seguir apresenta se os principais conceitos e t cnicas 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 se o anterior KLEPPE WARMER BAST 2003 O MDD tamb m conhecido como MDE Model Driven Engineering SCHMIDT 2006 MDSD Model Driven Software Development VOLTER GROHER 2007 ou para aqueles cansados de tantos acr nimos MD VOLTER 2008 Todos esses acr nimos dizem respeito 4 mesma abordagem cuja id ia principal reconhecer a importancia dos modelos no processo de software n o apenas como um guia para tarefas de desenvolvimento e manuten o mas como parte integrante do software A proposta do MDD Figura 2 fazer com que o engenheiro de software n o precise interagir manualmente com todo o c digo fonte podendo se concentrar em modelos de mais alto n vel ficando protegido das complexidades requeridas para implementa o nas diferentes plataformas Um mecanismo autom tico respons vel por gerar automaticamente o c digo a partir dos modelos Neste cen rio modelos n o s o apenas um guia ou uma refer ncia Eles fazem parte do software assim como o c digo fonte importjava util public synchronized replicateData lt page language java gt lt taglib prefix c
218. e public UmProduto FeatureA prototype 4 this prototype prototype 5 6 T7 public FeatureA makeFeatureA 8 return prototype clone g EO iE public static void main String args 12 UmProduto up new UmProduto new SubFeatureAl TS FeatureA featureA up makeFeaturea 14 Utilizar featureA normalmente 15 16 Figura 16 Uso do padr o Prototype para features alternativas A Figura 16 ilustra o uso do padr o Prototype com um gerador de c digo para implementar features alternativas Para cada ponto de varia o neste caso a featureA cria se um prot tipo que implementa uma interface Cloneable com um m todo para criar uma c pia de si mesmo clone Cada variante alternativa Sub features Al A2 e A3 transformada em uma inst ncia concreta do prot tipo mediante a implementa o do m todo clone respons vel por criar uma inst ncia da variante O gerador de c digo ao produzir o c digo do produto s precisa criar as chamadas correspondentes cria o do ponto de varia o e da alternativa selecionada No exemplo da Figura 16 mediante a sele o do ponto de varia o featureA o gerador gera as linhas 2 9 e 13 A linha 12 cont m o c digo que instancia a alternativa selecionada no caso a variante Sub feature Al Para o comportamento associado s features uma solu o a utiliza o do Template method A especifica o do comportamento comum definida
219. e seu tempo e seus funcion rios para a realiza o de um dos estudos emp ricos Agrade o tamb m aos colegas e amigos que encontrei pelo caminho pois foram muito importantes durante essa trajet ria no ICMC D bora Daniel Thiago Andr Silvana Am rico Adalberto Willian David Eduardo e Prazeres em Recife PE Eduardo Vinicius Alexandre Fred Bart Liana Vanilson Kellyton e demais membros do RiSE Em Fairfax EUA Marcos Rodrigo William Aline e Cristiane e finalmente Leo Renan Alexandre Alexandro Matko e os outros estagi rios da MSR Durante o doutorado foi tamb m importante o per odo de dois anos e meio trabalhando em tempo parcial na 3WT empresa aqui de S o Carlos N o existe um v nculo oficial entre o que fiz na empresa e o que fiz na universidade mas a viv ncia pr tica na ind stria foi sem d vida relevante para esta tese e agrade o empresa e aos amigos que nela fiz Dugnani Evandro Cristiano Escovar Danilo Vital Ricardo Rodrigo Mateus Renan Cris Maria e muitos outros com quem convivi neste per odo Agrade o tamb m aos amigos Cassandra Marcelo Bianca Amandinha Ivan e Amanda pela amizade e pelas noites de descontra o Por fim agrade o minha amada esposa Alessandra e minha filha Julia por todo o amor e carinho que me fazem lembrar que a vida n o podia ser melhor E tamb m pelo apoio for a e compreens o nos muitos momentos dif ceis A todos interessados em i
220. e trabalho representam o conhecimento expl cito por m existe tamb m o conhecimento t cito que utilizado nas atividades da abordagem Estes s o inclu dos na entrada das atividades para indicar que aquele conhecimento necess rio para aquela atividade em quest o O conhecimento t cito representado junto com os produtos de trabalho por m sem o prefixo PT Ao longo dos pr ximos cap tulos exemplos do dom nio de aplica es de autoria de conte do para a Web s o utilizados para melhor ilustrar as atividades da abordagem Este dom nio representa aplica es Web que permitem a publica o de conte do e sua visualiza o Nestas aplica es um autor publica a informa o como not cias e mensagens que pode ser acessada e visualizada pelos usu rios Portais de not cias f runs e blogs s o alguns exemplos de aplica es deste dom nio 74 4 4 Modelo de processo As atividades das fases de an lise projeto e implementa o do dom nio ser o descritas nos pr ximos cap tulos de forma sequencial para facilitar o seu entendimento Por m na pr tica estas atividades acontecem de forma iterativa e interativa e a sua ordem pode ser alterada para se adequar realidade de uma organiza o de software Nesta se o apresenta se o modelo de processo de desenvolvimento de software sugerido para a utiliza o da abordagem Um modelo de processo uma representa o abstrata de um processo de software SOMMERV
221. ecanismo de comunica o de id ias Ela deve ser n o amb gua e rica o suficiente para servir de entrada para transforma es e geradores de c digo Para isso s o necess rios detalhes e ajustes que s s o percebidos ap s a experi ncia de codifica o Al m disso a implementa o envolve diferentes subdom nios Cada itera o cuida do desenvolvimento dos artefatos de implementa o para um nico subdom nio Assim caso existam dez subdom nios por exemplo ser o necess rias dez itera es neste ciclo A fase de implementa o evolui da seguinte maneira 80 1 Atividade ID 1 Caracteriza o da variabilidade dos subdom nios esta atividade que est fora do ciclo iterativo da fase de implementa o identifica o tipo de variabilidade inerente a cada subdom nio executada uma nica vez a cada itera o do ciclo principal e seu objetivo definir o tipo de suporte em termos de DSL e ferramentas que ser necess rio para cada subdom nio importante ressaltar que nem todos os subdom nios identificados na an lise ir o passar pela fase de implementa o Somente s o considerados os subdom nios selecionados para investiga o ou produ o durante esta itera o do ciclo principal conforme decidido na atividade AD 5 da fase de an lise 2 Atividade ID 2 Defini o das DSLs e do suporte ferramental esta atividade cuida do desenvolvimento de uma DSL para um subdom nio assim como o seu suporte fe
222. ecionada a arquitetura retorna se s atividades PD 2 e PD 3 buscando novas t ticas padr es arquiteturais para implementar as mudan as sugeridas nesta avalia o Este ciclo se repete at n o serem necess rias mais mudan as para atender aos cen rios Ap s esta atividade tem se a arquitetura projetada e avaliada com base nas informa es dispon veis at o momento No entanto conforme j mencionado anteriormente este um processo iterativo e a arquitetura pode vir a sofrer altera es posteriormente Na realidade o que acontece uma itera o em duas vias a arquitetura influencia a implementa o das DSLs e transformadores que por sua vez podem influenciar a arquitetura resultando em mudan as que melhor acomodem a presen a destes novos artefatos 6 3 Considera es finais Neste cap tulo foi apresentada a fase de projeto de dom nio com atividades para promover a reutiliza o atrav s do MDD As principais contribui es deste cap tulo s o as atividades para defini o das diretrizes e padr es arquiteturais espec ficos para o uso do MDD na reutiliza o de software variabilidade baseada em features variabilidade baseada em DSLs e integra o entre subdom nios Tamb m apresenta uma atividade de avalia o arquitetural visando melhorar o resultado do projeto antes da implementa o ter iniciado O Quadro 10 resume as atividades do projeto de dom nio O Quadro 11 descreve os produtos de trabalho da f
223. eferenciado em outro modelo Apesar de n o ser ideal esta abordagem simplifica o processo de se implementar refer ncias entre modelos efetivamente utilizada devido sua praticidade sendo encontrada em exemplos como Apache OFBiz e algumas Microsoft DSL Software Factories HESSELLUND CZARNECKI WASOWSKI 2007 Outra op o s o as pontes entre modelos que consistem na cria o de duplicatas de elementos no metamodelo que cont m a refer ncia que correspondem a elementos do metamodelo referenciado No exemplo do dom nio web de autoria de conte do Inttp www springsource org 136 isto corresponde cria o no metamodelo de navega o de um elemento chamado ReferenciaParaTipoDeDocumento que pode ser utilizado para estabelecer refer ncias para o elemento TipoDeDocumento do metamodelo de autoria Um verificador separado pode ent o ajudar a garantir que estas refer ncias sejam v lidas WARMER KLEPPE 2006 C digo gerado precisa ser estendido um exemplo t pico a gera o de esqueletos de classes que precisam ser manualmente implementados ap s a gera o 2 Seja qual for a t cnica sendo utilizada uma recomenda o importante a de que a modifica o manual do c digo gerado n o deveria ser necess ria TOLVANEN 2004 V LTER BETTIN 2004 Mesmo com t cnicas de merging mesclagem como os blocos de usu rio do JET Java Emitter Templates POPMA 2004 esta n o uma boa pr tica
224. eholders por exemplo analistas projetistas desenvolvedores etc LEE KANG LEE 2002 Trata se de um conceito simples e orientado ao dom nio do problema e por isso a modelagem de features constitui um meio natural de comunica o entre os diferentes stakeholders sendo intuitivo para as pessoas expressarem a comunalidade e variabilidade de um dom nio por meio de features LEE MUTHIG 2006 A modelagem de features identifica os pontos comuns e vari veis de um dom nio em termos das features Esta t cnica est descrita da seguinte forma por Kang et al 1998 e Features s o identificadas e classificadas em termos de features de capacita o de tecnologia do dom nio de t cnicas de implementa o e de ambientes de opera o Features de capacita o s o caracter sticas vis veis ao usu rio que podem ser identificadas como servi os opera es e caracter sticas n o funcionais Features de tecnologia do Nesta tese utilizado o termo original em ingl s feature para se referir a uma caracter stica de um dom nio conforme a t cnica proposta originalmente por Kang et al ao inv s de sua tradu o para o portugu s pois o termo em ingl s remete de forma mais direta e menos amb gua t cnica enquanto o termo em portugu s pode ser utilizado em outros contextos 59 dom nio representam maneiras para se implementar os servi os ou opera es Features de t cnicas de implementa o s o fun es ou
225. eja que contemple elementos capazes de integrar DSLs transforma es e geradores de c digo Al m disso a maioria destas abordagens como as descritas por Almeida et al 2007b Keepence e Mannion 1999 Lee e Kang 2004 baseia se na identifica o da variabilidade somente em termos de features Como j discutido anteriormente h outros tipos de varia o como aquelas presentes em modelos entidade relacionamento por exemplo BARTHOLDT OBERHAUSER RYTINA 2008 que s o mais complexas do que poss vel capturar em um modelo de features RABISER GRUNBACHER DHUNGANA 2007 sendo necess ria uma DSL espec fica para representar a variabilidade de modo adequado ao MDD 6 1 Objetivos do projeto de dom nio Existem conceitos relacionados ao MDD que devem ser considerados durante o projeto do dom nio especialmente durante a defini o da arquitetura do dom nio Al m da variabilidade mais complexa discutida anteriormente nesta abordagem a arquitetura e seus componentes contam com a exist ncia de DSLs e transforma es que por sua vez devem ser capazes de produzir artefatos de implementa o voltados quela arquitetura espec fica A fase de projeto do dom nio tem os seguintes objetivos e Identificar as diretrizes arquiteturais o projeto arquitetural deve ser direcionado pelos objetivos de neg cio e requisitos mais importantes considerando se o ponto de vista de diferentes stakeholders Estes s o chamados de dire
226. elos estes trabalhos descrevem problemas similares no contexto de reutiliza o e oferecem algumas contribui es que podem auxiliar na execu o desta atividade Com base nesta literatura dispon vel e nas experi ncias com estudos de casos nesta tese as seguintes diretrizes foram definidas para esta atividade e Foco na automa o enquanto a maioria dos autores n o apresenta crit rios claros para decompor um dom nio no desenvolvimento orientado a modelos isto muito claro o subdominio deve poder ser automatizado atrav s de ferramentas de modelagem e transforma es e Import ncia do especialista do dom nio muitos autores concordam que o conhecimento do especialista do dom nio extremamente valioso nesta atividade JARZABEK 1997 HADDAD TESSER 2002 MAIDEN SUTCLIFFE 1996 Desta forma a identifica o de 100 subdom nios deve ser guiada por este profissional e Dividir para conquistar o conceito b sico de divis o de um problema grande em partes menores tamb m til no processo de desenvolvimento para reutiliza o Diferentes t cnicas podem ser utilizadas dependendo do contexto Relacionamentos do tipo ParteDe e Um podem ser utilizados como t cnica de decomposi o onde cada subdom nio ou parte de um subdom nio maior ou uma inst ncia Al m disso a maioria dos autores concorda que a divis o deve seguir a categoriza o natural do dom nio o que mais uma vez ressalta a import nci
227. elos e reutiliza o de software e que possuem alguma interse o com a abordagem desta tese Tamb m foram discutidos trabalhos relacionados com a avalia o realizada e que serviram de base para a defini o das m tricas utilizadas nesta tese 221 10 Conclus es Reutiliza o de software um objetivo constantemente procurado por pesquisadores e profissionais envolvidos com desenvolvimento de software A percep o comum a de que esta uma id ia bastante simples de se colocar em pr tica que apresenta benef cios consider veis e praticamente n o requer investimento em tecnologias ou profissionais altamente qualificados D cadas de pesquisa evidenciaram que apesar de ser uma id ia simples a sua aplica o na pr tica algo extremamente complexo principalmente de forma sistem tica e gerenci vel Muitos fatores fogem da rea t cnica e portanto mais dif cil para profissionais desta rea perceberem os erros e dificuldades na sua aplica o Como resultado a reutiliza o vem ocorrendo por m de forma isolada e her ica quando deveria ser uma pr tica mais disseminada na comunidade Mesmo no mbito t cnico a reutiliza o ainda esbarra em problemas do desenvolvimento de software baseado em c digo fonte cada vez mais dif cil construir software atualmente dada a sua complexidade e ubiquidade ambas causadas pelo progresso tecnol gico Enquanto atualmente poss vel resolver problemas atrav s
228. em m todos abstratos de uma classe abstrata O comportamento de cada alternativa implementado em classes concretas com implementa es dos m todos correspondentes A Figura 17 ilustra o uso deste padr o O gerador apenas precisa gerar a cria o do objeto concreto de acordo com a alternativa 128 selecionada linha 3 Opcionalmente a cria o pode ser feita com o padr o Abstract Factor FeatureA comportamentoParte1 comportamentoParte2 comportamentoParte3 SubFeatureA1 SubFeatureA3 comportamentoParte1 SubFeatureA2 comportamentoParte2 comportamentoParte3 comportamentoParte1 comportamentoParte2 comportamentoParte3 Sub feature A2 comportamentoParte1 comportamentoParte2 comportamentoParte3 public class UmProduto 2 public static void main String args 3 FeatureA featureA new SubFeatureAl 4 featureA comportamentoPartel Ea for int i 0 i lt 10 i 6 featureA comportamentoParte2 7 8 if lt alguma_condicao gt 9 featureA comportamentoParte3 10 Gerador Figura 17 Uso do padrao Template method para features alternativas Caso uma feature precise ser implementada por diferentes classes sugere se 0 uso do padrao Facade em conjunto com um dos tr s acima Abstract Factory Prototype ou Template method O Facade permite a reuni o de diversas classes em uma nica fachada Neste caso os m todos construtor
229. em projetos MDD Nesta tese foram utilizadas m tricas para avalia o da linguagem de modelagem como parte dos estudos de caso Al m disso a qualidade do processo tamb m foi uma preocupa o importante e a cobertura das atividades essenciais foi discutida na Se o 4 5 onde compara se a abordagem desta tese com um modelo de maturidade em MDD 223 Monperrus et al 2008 argumentam que o custo para se coletar m tricas em um projeto orientado a modelos extremamente alto devido especificidade a um dom nio o que impede que sejam utilizadas m tricas gen ricas Como consequ ncia necess rio desenvolver ferramentas espec ficas para medir software cada vez que um novo dom nio implementado Para resolver este problema os autores desenvolveram uma abordagem orientada a modelos para a gera o de sistemas coletores de m tricas espec ficas de dom nio com base em especifica es formais das m tricas a serem utilizadas Especialistas do dom nio especificam quais m tricas s o necess rias seguindo um metamodelo definido pela abordagem e s o automaticamente geradas ferramentas capazes de coletar estas m tricas Uma abordagem parecida apresentada por Guerra Lara e D az 2008 Neste trabalho os autores descrevem uma linguagem espec fica de dom nio para a defini o de m tricas Esta linguagem pode servir de entrada para a coleta autom tica destas m tricas Por m diferentemente do trabalho de Monperrus et
230. em que esta disserta o foi escrita em 2009 n o s existem ferramentas dispon veis mas tamb m existem diversas op es todas elas sendo efetivamente utilizadas na pr tica pela ind stria Nesta tese foram utilizadas tr s alternativas diferentes e ainda existem muitas outras igualmente capacitadas Isto demonstra a tend ncia de que o MDD est e ser cada vez mais presente na realidade do desenvolvimento de software 229 A realiza o dos estudos emp ricos tamb m proporcionou o aprendizado de importantes li es A primeira delas foi a import ncia da experi ncia em ambiente industrial Em ambas as experi ncias percebeu se que apesar do crescimento em import ncia o MDD ainda uma tecnologia muito distante da realidade da grande maioria das empresas Este fato pode ser percebido no terceiro estudo onde a empresa envolvida sequer conhecia a maioria dos conceitos envolvidos E este n o parece ser um retrato somente do cen rio brasileiro Por exemplo o segundo estudo emp rico realizado durante o est gio de doutorado na Microsoft Research foi uma das primeiras iniciativas em MDD deste importante instituto de pesquisa Durante as apresenta es e semin rios no final do est gio realizadas pelo autor desta tese muitos dos participantes ali presentes estavam vislumbrando os conceitos do MDD pela primeira vez inclusive importantes pesquisadores e funcion rios desta grande empresa da rea de TI O fato de que
231. em ser tomadas sobre eles Fase de projeto de dom nio na primeira itera o esta fase cuida da cria o de uma arquitetura para o dom nio com base nos requisitos mais relevantes conforme percebidos 77 pelos stakeholders e a exist ncia dos subdom nios A cada nova itera o do ciclo principal a fase de projeto produz refinamentos na arquitetura considerando se os novos modelos do dom nio novos n veis de decis o sobre os subdom nios ou mais detalhes sobre as diretrizes arquiteturais que possam ter sido percebidos na itera o anterior Estes refinamentos podem inclusive resultar no surgimento de novos m dulos e 7 Fase de implementa o do dom nio na primeira itera o esta fase cuida da implementa o das principais partes do dom nio conforme identificado na an lise com a produ o de componentes de software DSLs transforma es e geradores de c digo A cada itera o do ciclo principal s o introduzidos refinamentos e mudan as na implementa o para refletir novas decis es de projeto tomadas nesta itera o Deve se tomar cuidado especial para que as mudan as n o causem inconsist ncias entre as DSLs transforma es geradores de c digo e os componentes O resultado de sucessivas itera es no ciclo principal um crescimento cont nuo no n mero de artefatos do dom nio e tamb m no n vel de confian a dos subdom nios a serem automatizados Al m disso cada vez mais subdom nios s o d
232. en o Um relacionamento em um metamodelo corresponde a uma associa o ou agrega o enquanto em linguagens textuais pode ser representado como uma regra de produ o e Propriedades de conceitos podem precisar de tipos especiais do dom nio em vez dos tipos tradicionais como inteiro ou string Por exemplo sub features opcionais ou do tipo or podem ser mapeadas como enumera es do dom nio Por outro lado uma propriedade pode pertencer a tipos personalizados como Ponto e Tamanho e e Features relacionadas podem ser conectadas por um conceito novo que descreve a rela o as cardinalidades os conceitos participantes e seus pap is na rela o A an lise de depend ncia de features LEE KANG 2004 pode ser usada para identificar tais rela es inicialmente mas novas podem aparecer posteriormente Sub atividade ID 2 3 Defini o da sintaxe concreta O terceiro passo corresponde defini o da sintaxe concreta o que n o uma tarefa muito complexa Em DSLs textuais externas FOWLER 2005 a sintaxe concreta fortemente acoplada sintaxe abstrata aparecendo na forma de palavras reservadas e tokens descritos na gram tica da linguagem Se uma DSL interna FOWLER 2005 utilizada ent o as constru es da linguagem que cont m a DSL devem ser analisadas para determinar se podem representar os conceitos do dom nio de forma adequada Em DSLs visuais blocos decorados e linhas s o a nota o padr o Formas g
233. encial para fazer com que os objetivos da reutiliza o e do MDD sejam alcan ados Por m sem a exist ncia de um processo bem definido que d suporte institucionaliza o de pr ticas comprovadas e sistem ticas este potencial pode n o atingir seu ponto m ximo e como resultado os benef cios associados reutiliza o e ao MDD podem se perder durante as tentativas Assim o papel do processo o de coordenar esfor os de maneira que o sucesso passa a depender de fatores mais control veis como planejamento gerenciamento e treinamento ao inv s de ser o resultado de talento e experi ncias individuais isoladas A literatura apresenta importantes contribui es nas reas de processos para reutiliza o de software e MDD por m a combina o de ambas permanece relativamente inexplorada Existem alguns pontos de intersec o com impacto significativo no processo que precisam ser devidamente analisados antes de se tentar uma combina o entre reutiliza o e MDD No pr ximo cap tulo esta intersec o analisada de forma mais aprofundada buscando identificar como as caracter sticas de cada abordagem pode influenciar a outra de forma a proporcionar um melhor resultado final 57 3 Reutiliza o de software e desenvolvimento orientado a modelos Reutiliza o de software e desenvolvimento orientado a modelos s o duas reas distintas mas com muitos objetivos em comum Ambas procuram mais qualidade e produtividade
234. endo os conceitos de mais alto n vel na parte vis vel No caso dos frameworks a parte vis vel corresponde aos pontos que o desenvolvedor utiliza para instanciar a aplica o no caso os pontos vari veis e os ganchos A parte escondida se refere ao restante da estrutura que normalmente reutilizada sem modifica o tamb m conhecidos como frozen spots Sele o a sele o se resume escolha de um framework adequado para a aplica o que se deseja construir Neste caso t cnicas de classifica o e busca podem ser utilizadas para facilitar a sele o Adapta o a adapta o consiste na instancia o da aplica o em que o desenvolvedor utiliza os pontos vari veis e ganchos para criar uma aplica o que atenda aos requisitos e Integra o a integra o normalmente n o um problema pois um framework j uma aplica o semi pronta que uma vez instanciada pode ser executada diretamente Por m pode ser necess rio realizar a integra o da aplica o com o ambiente por exemplo com o sistema operacional ou um banco de dados espec fico Neste caso essa integra o ser t o simples quanto for a possibilidade de parametriza o do framework Padr es de software Uma forma bastante conhecida de reutiliza o s o os padr es de software COPLIEN 2006 Sejam de an lise de processo ou de projeto os padr es t m um nico objetivo representar solu es bem sucedidas
235. ente a mesma que voc j construiu em alguns sistemas anteriores NEIGHBORS 1989 Sua proposta que seja feita uma an lise sobre um dom nio de aplica es similares a exemplo do que prop s Parnas 1976 e que o conhecimento obtido seja representado por meio de linguagens espec ficas para este dom nio DSL e para os dom nios relacionados de forma a facilitar sua reutiliza o ao se construir um novo sistema Essa proposta muito similar s id ias do MDD Na abordagem Draco um analista do dom nio normalmente uma pessoa com experi ncia na constru o de diferentes aplica es similares cria a descri o desse dom nio segundo uma 208 DSL Um dom nio no Draco inclui um interpretador sem ntico parser que incorpora as regras gramaticais da linguagem Desta forma ao se construir um sistema para esse dom nio um engenheiro de software pode utilizar essa DSL Por exemplo considere um analista do dom nio de jogos eletr nicos Ele define elementos como placar comando fase jogador entre outros e os descreve utilizando regras gramaticais que servem para a cria o de um interpretador parser O analista de um sistema utiliza esses elementos para construir seu pr prio jogo criando elementos como Jogador 1 39 66 Jogador 2 comandoDireita comandoEsquerda etc Uma poss vel gram tica para essa DSL onde um jogo envolve v rios jogadores seria j
236. envolvendo o dom nio de eventos cient ficos Nota se que ao contr rio dos estudos anteriores com a abordagem tem se menores taxas e raz es de reutiliza o Por m a taxa de reutiliza o n o desejada foi reduzida para menos da metade Al m disso neste dom nio nota se uma maior diferen a entre a porcentagem de reutiliza o e a raz o de reutiliza o do que nos dom nios anteriores Isto porque h um grande n mero de artefatos que s o reutilizados e modificados minimamente reutiliza o do tipo caixa branca como resultado do processo de customiza o Compara o das m tricas de reutiliza o 120 00 100 00 80 00 60 00 40 00 20 00 0 00 Raz o de de reutiliza o reutiliza o n o desejada E Sem abordagem 82 15 96 11 51 43 E Com abordagem 74 45 94 69 21 88 Figura 40 Compara o entre as m tricas de reutiliza o para o estudo do dom nio de eventos cient ficos de reutiliza o A porcentagem de reutiliza o obtida com gera o de c digo neste estudo foi bastante reduzida sendo medida como 3 99 A raz o entre especifica o e c digo tamb m foi significativamente menor atingindo 1 8 14 ou seja os geradores deste estudo produzem menos 198 c digo para cada elemento de especifica o do que os dos estudos anteriores Conforme discutido anteriormente neste estudo n o foram coletadas m tricas para os artefatos de c digo por motivos de
237. eom tricas espec ficas como ret ngulos e elipses ou imagens podem tamb m ser utilizadas para representar os conceitos da DSL de forma mais intuitiva e natural As seguintes regras podem ser utilizadas na cria o desta nota o e Features que s o mapeadas para os conceitos do dom nios podem ser representadas como blocos e Relacionamentos entre features podem ser representados como linhas e Sub features que s o mapeadas a valores booleanos podem ser representadas como decora es nos blocos como uma borda diferenciada atributos como um cone na frente de um elemento ou linhas como um losango em uma das termina es e Sub features que s o mapeadas a valores do tipo string podem ser representadas como decoradores textuais como um texto dentro de um bloco ou sobre uma linha e 153 e Sub features que representam listas de itens podem ser representados como compartimentos em blocos como os m todos e atributos da UML por exemplo Sub atividade ID 2 4 Defini o da integra o inter DSL O quarto passo lida com a integra o entre diferentes DSLs o que um problema que surge quando se lida com m ltiplos subdom nios A integra o inter DSL deve ser gerenciada de forma que o desenvolvedor possa especificar modelos em ambas as linguagens utilizando conceitos que se relacionam Por exemplo no dom nio web de autoria de conte do uma p gina de formul rio do subdom nio de navega o pode se refe
238. erado de dados sobre a ferramenta que o gerou data da gera o entre outras informa es teis As ferramentas identificadas s o ent o listadas e descritas incluindo toda informa o poss vel uma descri o de suas funcionalidades os artefatos que podem ser gerados por ela e refer ncias para fontes externas Novamente caso seja encontrada uma ferramenta referente a um subdom nio ainda n o identificado acrescenta se uma observa o para posterior re an lise 104 Sub atividade AD 3 4 Atribui o de n vel de confian a Os subdom nios identificados nem sempre podem ser representados em uma DSL e automatizados utilizando t cnicas do desenvolvimento orientado a modelos Mesmo para aqueles que podem o custo de se desenvolver linguagens ferramentas e transforma es pode ser muito alto A automa o de um subdom nio tamb m pode requerer altera es e refinamentos no modelo de features o que obviamente causa grande impacto no desenvolvimento Finalmente dependendo de qual subdom nio implementado primeiro outros subdom nios sobrepostos ou relacionados podem precisar ser revistos Por este motivo todos os subdom nios identificados s o tratados como candidatos at serem completamente realizados Al m disso deve existir um certo n vel de confian a de que um subdom nio ir render os resultados esperados quando realizado em forma de artefatos para MDD antes de se iniciar o projeto e implementa o Nesse
239. erenciar e implementar Com o tempo eles tendem a evoluir e N vel de abstra o subdom nios que se encontram em um n vel de abstra o pr ximo ao c digo fonte s o mais simples de implementar e est o entre os exemplos de maior sucesso no desenvolvimento orientado a modelos em termos de facilidade de gera o de c digo TOLVANEN KELLY 2005 Em contrapartida s o em geral menos reaproveit veis e e Exist ncia de c digo exemplo a exist ncia de exemplos de como o c digo ou outros artefatos devem ser gerados um fator importante A abordagem de desenvolvimento atrav s de exemplos WIMMER et al 2007 facilita o processo de constru o de transformadores e geradores de c digo 110 Estes s o apenas exemplos de crit rios que podem ser considerados durante a tomada de decis o Cada dom nio pode introduzir seus pr prios conjuntos de crit rios e particularidades a serem considerados Como refer ncia pode se tamb m utilizar a m trica de n vel de confian a definindo se intervalos de valores para cada decis o Por exemplo em uma escala de O a 60 subdom nios com n vel de confian a entre O e 10 levam a decis o D Entre 11 e 20 decis o D2 e assim por diante Por m esta t cnica serve apenas como refer ncia A decis o final deve ser tomada levando se em conta outros fatores e n o somente os inclu dos na m trica Os n veis de decis o s o alterados medida que o dom nio evolui durante
240. erentes tipos de artefatos incluindo documenta o Assim sempre que poss vel deve se automatizar a gera o de documenta o para livrar o desenvolvedor deste tipo de trabalho manual P Utilize a sem ntica da linguagem Muitas constru es da pr pria linguagem de programa o cont m informa o til reutiliza o de software Por exemplo a compara o de assinatura ZAREMSKI WING 1995 analisa a pr pria defini o das interfaces para determinar se um componente pode ser reutilizado em um determinado contexto Tamb m poss vel por exemplo determinar algumas caracter sticas de um componente examinando se o c digo fonte at mesmo de forma autom tica Assim a documenta o deve utilizar todo tipo de informa o sem ntica dispon vel no pr prio c digo fonte Ps Diagramas e figuras A documenta o deve incluir diagramas e figuras sempre que poss vel No MDD muitas das informa es visuais est o dispon veis na pr pria linguagem espec fica do dom nio Assim um artefato que serve de entrada para um gerador o pr prio documento visual do software a ser gerado Para a documenta o de artefatos de c digo pode se utilizar um formato como o descrito por Almeida et al 2008 que contempla cinco se es e seus campos relacionados informa es b sicas contendo descri es gerais sobre o componente como seu nome prop sito e palavras chave descri o detalhada contendo a defini o das int
241. erentes decis es posteriormente durante o projeto do dom nio Existem basicamente dois tipos de variabilidade em rela o base comum COPLIEN 2000 e Variabilidade positiva mant m a base comum intacta n o violando nenhuma de suas 96 premissas enquanto novos comportamentos s o adicionados ou refinados e e Variabilidade negativa remove comportamento da base comum no sentido em que uma ou mais premissas que eram v lidas na base comum passam a ser violadas No exemplo do dom nio web citado anteriormente a busca avan ada Quadro 5 introduz uma variabilidade positiva no passo 1 pois este um refinamento que acrescenta um comportamento adicional n o violando as premissas do cen rio original Tamb m introduz uma combina o de variabilidades negativa e positiva no passo 2 pois neste cen rio n o mais ocorre uma busca no conte do todo apenas no conte do especificado pelo usu rio Os fluxos alternativos introduzem apenas variabilidades positivas pois eles refinam o comportamento normal Em ess ncia e principalmente na fase de an lise ambos os tipos s o v lidos e ocorrem naturalmente dentro de um dom nio Por m podem levar a decis es de projeto diferentes Enquanto variabilidades positivas podem ser implementadas de maneira mais simples as variabilidades negativas exigem mecanismos para suprimir comportamento da base comum COPLIEN 2000 o que pode levar a uma maior complexidade da arquitetura fi
242. erfaces e informa es sobre a linguagem de implementa o versionamento etc informa es de qualidade descrevendo as informa es necess rias para a garantia de qualidade do 165 componente tais como o pacote de testes informa es sobre implanta o tais como as depend ncias necess rias para compilar e implantar o componente e informa es de suporte com um guia de instala o e contatos que ajudam na identifica o das pessoas respons veis pelo suporte t cnico do componente Para outros artefatos espec ficos do MDD os seguintes formatos podem ser utilizados e Para DSLs deve se incluir informa es sobre 1 O subdom nio com o qual a DSL se relaciona 2 A gram tica ou metamodelo utilizado 3 Detalhes sobre a sintaxe concreta tais como o significado das figuras linhas cones decora es 4 Ferramentas de modelagem que podem ser utilizadas 5 Outras DSLs que interagem com esta 6 Transforma es geradores com os quais a DSL se relaciona isto serve de entrada e 7 Exemplos de sua utiliza o e Para ferramentas de modelagem deve se incluir informa es sobre 1 O subdom nio com o qual a ferramenta se relaciona 2 A DSL para a qual a ferramenta oferece suporte 3 Detalhes sobre o seu desenvolvimento tais como as tecnologias ou frameworks utilizados 4 Manual de instala o e utiliza o e 5 Contatos para suporte t cnico e Para transforma es de software de
243. ernational Conference on System Sciences HICSS 07 Hawaii s n 2007 p 285 294 WOHLIN C et al Experimentation in Software Engineering An Introduction S 1 Kluwer Academic Publishers 2000 ZAREMSKI A M WING J M Signature matching A tool for using software libraries ACM Transactions on Software Engineering and Methodology v 4 n 2 p 146 170 1995 253 AP NDICE A T cnicas para reutiliza o de software O m todo mais simples de reutiliza o conhecido e utilizado por praticamente todo desenvolvedor sob o nome informal de copiar e colar A fun o que permite realizar a c pia ou duplica o do objeto de trabalho est presente em quase todas as aplica es e sistemas operacionais existentes na atualidade Por exemplo poss vel copiar texto de um local para outro permitindo assim que um desenvolvedor reutilize trechos de c digo Outras ferramentas de aux lio Engenharia de Software tais como as ferramentas de modelagem tamb m permitem que sejam duplicados desenhos e outros elementos de modelagem Esse tipo de reutiliza o acontece quando um desenvolvedor est trabalhando em alguma atividade do processo de software e se depara com uma situa o na qual ele se lembra de um artefato c digo ou n o que ele j construiu utilizou ou que de alguma maneira saiba existir Ele ent o localiza este artefato identifica as partes que lhe ser o teis e copia para o local onde es
244. es o construtor da classe o m todo clone ou o m todo template nos padr es citados precisam ser estendidos para instanciar todas as classes que implementam cada feature com uma classe facade servindo para reuni las em um nico ponto Quando as features alternativas correspondem a comportamentos alternativos que devem ser mapeados em um nico m todo ao inv s de toda uma classe os padr es Strategy ou Template method podem ser utilizados O padr o Strategy consiste na defini o de uma interface com um nico m todo que corresponde ao ponto de varia o Para cada alternativa deve se providenciar uma implementa o desta interface onde o m todo cont m o comportamento referente alternativa selecionada O Template method similar mas normalmente n o exige uma interface dedicada a um nico m todo Em ambos os casos o gerador produz as chamadas dos m todos correspondentes s alternativas selecionadas Or features estas s o similares s features alternativas por m mais de uma feature pode estar presente em uma aplica o O padr o Chain of Responsibility pode ser utilizado quando as diferentes features introduzem funcionalidades complementares que s o executadas uma ap s a outra Neste 129 padr o cria se uma classe abstrata para o ponto de varia o com um m todo principal e um m todo para adicionar comportamentos adicionais Dentro do m todo principal adiciona se uma chamada para um compor
245. escartados medida que a experi ncia demonstra que eles s o muito dif ceis ou imposs veis de automatizar Idealmente no final de v rias itera es todos os subdom nios s o inclu dos ou exclu dos do processo ou seja a tend ncia n o existirem candidatos nos n veis intermedi rios de decis o Dependendo do dom nio esta evolu o pode apresentar algumas caracter sticas distintas Por exemplo em sistemas cr ticos onde prefer vel o uso somente de linguagens e ferramentas bem conhecidas as itera es podem parar ap s estas terem sido inclu das sem que haja investiga o ou desenvolvimento extra para desenvolver linguagens e ferramentas personalizadas Em projetos com pouco prazo para entrega uma nica itera o pode ser vi vel resultando em v rios subdom nios sendo deixados para tr s Uma sugest o sobre a evolu o do dom nio visando reduzir os riscos e problemas associados ado o do MDD incluir nas primeiras itera es apenas subdom nios mais conhecidos com ferramentas e linguagens de modelagem dispon veis Desta forma pode se perceber os benef cios do MDD sem a necessidade de um investimento inicial maior al m de proporcionar uma evolu o mais r pida nestas primeiras itera es 4 4 2 Ciclo de projeto do modelo de processo evolu o arquitetural Dentro do ciclo principal a fase de projeto tamb m ocorre de forma iterativa A cada itera o no ciclo de projeto novos m d
246. esponde aos dados propriamente ditos O segundo nivel M1 corresponde aos metadados ou modelo S o os dados que descrevem os dados O terceiro n vel M2 o metamodelo utilizado para a defini o de modelos A especifica o UML um exemplo de metamodelo O quarto n vel M3 utilizado para definir metamodelos ou seja um meta metamodelo define linguagens de modelagem como a UML por exemplo Um exemplo de meta metamodelo o padr o MOF apresentado na pr xima se o N o existe um quinto 46 n vel pois o meta metamodelo normalmente inst ncia de si mesmo Existem diferentes meta metamodelos utilizados na ind stria utilizados nas diferentes ferramentas de modelagem e transforma o para uniformizar a manipula o de modelos e c digo em diferentes linguagens Nas se es seguintes s o apresentadas as principais abordagens da ind stria para o MDD 2 2 2 1 Abordagem OMG MDA Model Driven Architecture O OMG Object Management Group um dos respons veis pelo atual aumento de interesse nas id ias do MDD devido principalmente MDA A MDA surgiu como um conjunto de padr es 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 Computa o PIM Platform Independent Model ou Modelo Independente de Plataforma e PSM Platform Specific Model ou Mo
247. ess rio para que o desenvolvedor encontre aquilo que est procurando Existe uma vasta literatura em torno desse assunto LUCR DIO ALMEIDA PRADO 2004 Adapta o a adapta o do componente normalmente feita por meio de sua parametriza o na qual o reutilizador especifica par metros para que o componente possa executar sua fun o no contexto em que est sendo reutilizado Por m normalmente a parametriza o s poss vel nos casos previstos durante o projeto do componente Adaptar um componente para que ele execute em um cen rio imprevisto pode exigir que o mesmo seja modificado internamente Neste caso se o esfor o necess rio para essa modifica o for muito grande pode ser mais vantajoso tentar renegociar com o cliente os requisitos da aplica o do que modificar o pr prio componente e Integra o a integra o consiste no acoplamento das interfaces requeridas pelo componente com as interfaces providas pelo restante da aplica o Normalmente esse acoplamento exige alguma modifica o na aplica o Diferentemente da abordagem copiar e colar um componente ao ser reutilizado n o precisa ser novamente testado caso n o tenha sido modificado Al m disso a exist ncia de uma interface bem definida assim como os mecanismos de classifica o e busca fazem com que o desenvolvedor n o precise confiar tanto em sua mem ria para encontrar um componente candidato reutiliza o 257
248. estudo do dominio de autoria de conte do para a web A Figura 30 analisa de forma mais aprofundada as medidas de instabilidade obtidas com a abordagem Pode se notar que o c digo gerado mais inst vel do que o c digo n o gerado em alguns casos chegando ao limite m ximo desta m trica 1 Os artefatos de gera o de c digo transforma es e geradores apresentam uma distribui o intermedi ria s dos c digos Observa o neste gr fico o c digo gerado foi inclu do apesar se ser um artefato n o utilizado diretamente pelo desenvolvedor Isto foi feito para ajudar na caracteriza o da reutiliza o apenas O mesmo acontece em outros gr ficos deste cap tulo 190 gerado e n o gerado por m de forma mais concentrada em torno do valor central da m trica 0 5 Os modelos utilizados na abordagem tiveram sua instabilidade abaixo de 0 5 sendo em geral menos inst veis do que os demais artefatos 1200 Instabilidade de M dulo com Abordagem 1 000 x 0 800 a x 0 600 0 400 hs i m 0 200 l i 0 000 E C digo n o gerado C digo gerado Artefatos de gera o Modelos Hal 0 000 0 341 0 500 0 250 Amin 0 000 0 000 0 000 0 000 mediana 0 467 0 750 0 667 0 500 m dia 0 393 0 614 0 537 0 333 x m x 0 889 1 000 0 909 0 500 03 0 683 0 907 0 750 0 500 Figura 30 Distribui es de instabilidade de m dulo nos difere
249. estudo realizado em torno de 70 artefatos foram modificados em menos de 25 Estas modifica es envolvem configura es e customiza es muitas delas duplicadas Com a abordagem foi poss vel reunir grande parte dos par metros de configura o em um nico modelo e as modifica es pontuais e repetitivas s o realizadas por geradores Neste estudo o modelo serve de entrada para configura es em seis tabelas diferentes do banco e quatro arquivos de configura o que antes precisavam ser feitas individualmente Al m disso os geradores s o mais confi veis nesta tarefa reduzindo a necessidade de testes mais exaustivos As m tricas de n mero de atributos e relacionamentos para os modelos utilizados neste estudo mostram que existem muitos atributos m dia de 36 33 e nenhum relacionamento o que indica que se tratam de modelos que servem basicamente de configura o apenas 201 8 5 An lise das hip teses e conclus es Os dados e resultados obtidos com os estudos possuem ind cios sobre a rejei o de algumas das hip teses nulas Esta rejei o feita com base em an lise descritiva apenas n o sendo embasada por dados estat sticos rigorosos Com rela o hip tese Hog conclui se que ela rejeitada pois nos tr s estudos foram verificados aumento e ou melhoria na reutiliza o de software nos projetos utilizando a abordagem Com rela o hip tese Hop n o foi poss vel alcan ar a rejei o uma
250. estudos relacionados reutiliza o de software como por exemplo o trabalho de Almeida et al 2007a Nesta tese foram utilizadas algumas das m tricas de reutiliza o al m das m tricas indiretas na avalia o dos estudos de caso 9 3 Considera es finais A literatura nas reas de reutiliza o de software e desenvolvimento orientado a modelos relativamente rica em trabalhos que exploram os aspectos processuais destes dois paradigmas Por m a investiga o conjunta das duas linhas de pesquisa ainda recente e normalmente os trabalhos focam em partes isoladas do problema Apesar de esta tend ncia ser natural e academicamente mais seguro ainda existem espa os para contribui es que resultem da investiga o conjunta das duas linhas interessante notar que as duas reas aparentemente distintas tiveram um nico pesquisador que investigou de forma pioneira diversos conceitos que posteriormente formaram a base de cada rea separadamente James Neighbors em sua abordagem Draco NEIGHBORS 1980 combinou os conceitos de dom nio tendo cunhado o termo An lise de dom nio e transforma es de software de forma inovadora Esta uni o entre reutiliza o e MDD permaneceu relativamente ignorada por v rios anos sendo atualmente resgatada principalmente ap s o surgimento da MDA LUCR DIO et al 2006 Neste cap tulo foram apresentados trabalhos acad micos na rea de desenvolvimento orientado a mod
251. esultados da avalia o apresenta um menor grau de controle uma vez que o desenvolvimento sofre influ ncias e press es constantes naturais deste tipo de ambiente Como resultado a qualidade e rigor dos dados menor do que em um estudo controlado Por ser esta uma tese na rea de Engenharia de Software n o se pode descartar este tipo de estudo afinal a ind stria deve ser o destino imediato ou a longo prazo de toda e qualquer pesquisa relevante nesta rea As li es aprendidas ainda que em forma de coment rios e impress es subjetivas devem ser consideradas como sendo relevantes e valiosas O tamanho dos projetos envolvidos nos estudos que se caracterizam entre pequeno e m dio portes razo vel para este tipo de avalia o e n o foi considerado como uma amea a validade Dado o tamanho das equipes ser muito reduzido n o foi poss vel avaliar aspectos referentes ao trabalho colaborativo nem a capacidade da abordagem em atender aos requisitos deste tipo de desenvolvimento Devido tamb m ao tamanho dos projetos pode se citar o fato de que a an lise de dispers o e balanceamento das amostras permitiu identificar alguns poucos elementos fora da distribui o normal Estes por m pouco influenciaram os resultados Em futuras replica es deste experimento pode se optar por ignorar esta an lise sem muitos preju zos aos resultados caso os tamanhos dos projetos sejam similares aos aqui apresentados A compara
252. falta de ferramentas adequadas Por m foram analisados os atributos dos artefatos de gera o para efeitos de compara o com os outros estudos Esta compara o apresentada na Figura 41 Pode se notar que em termos de instabilidade os artefatos deste estudo est o mais pr ximos aos do estudo envolvendo o dom nio Web por m ligeiramente menos inst veis Em termos de complexidade ciclom tica a distribui o ficou mais concentrada e ligeiramente superior que os outros estudos O ndice de manutenibilidade se mostrou notavelmente inferior aos outros estudos Instabilidade de M dulo Complexidade Ciclom tica ndice de Manutenibilidade 1 000 j 200 000 0 900 X x 0 800 X m 25 000 150 000 0700 e 20 000 0 600 gt as 100 000 9899 Lt 15 000 j l 0 400 10 000 9 50 000 E 0 300 Es E ni 5 000 Lg e 0 200 0 000 0 100 t 0 000 a q 0 000 r 5 000 50 000 EC Web CN EC Web CN EC Web CN Egl 0 375 0 500 0 333 mq1 3 000 1 000 1 000 mqi 17 793 44 990 77 210 Amin 0 000 0 000 0 000 Amin 2 000 0 000 1 000 Amin 1 470 22 550 17 210 emediana 0 583 0 667 0 333 4mediana 3 500 4 000 3 000 mediana 37 915 82 990 89 510 m dia 0 492 0 515 0 373 m dia 6 500 6 146 3 411 m dia 43 448 74 885 96 589 X m x 0 800 0 750 0 944 X m x 16 000 28 000 18 000 X m x
253. ferentes estrutura do software produzido e outros atributos de qualidade Foram definidas formas de coleta de dados espec ficas para cada quest o relacionada aos objetivos da avalia o conforme apresentado a seguir Quest o Q Analisando se um mesmo projeto desenvolvido com e sem a abordagem poss vel observar um aumento e ou melhoria na reutiliza o de software no projeto que utilizou a abordagem dif cil definir o que significa aumento e ou melhoria na reutiliza o A reutiliza o ocorre de diversas maneiras e dependendo do contexto pode significar diferentes benef cios Por exemplo a reutiliza o obtida por meio de heran a completamente diferente da reutiliza o obtida com um gerador de c digo sendo dif cil determinar qual das duas oferece maiores benef cios pois n o h m tricas consistentes capazes de medir ambos os aspectos de forma normalizada 172 Existem diferentes m tricas voltadas reutiliza o que focam em aspectos econ micos e estruturais de artefatos de software No contexto desta quest o destacam se apenas os aspectos estruturais pois esta tese trata de uma abordagem voltada para a engenharia para reutiliza o A literatura apresenta algumas m tricas simples para medir a reutiliza o no n vel estrutural dos artefatos mas nenhuma delas capaz de oferecer uma imagem completa do n vel de reutiliza o em um sistema MASCENA ALMEIDA MEIRA 2005 Assim faz se
254. go N sistema SS Oma SS ema execut vel E alto n vel baixo n vel y A Requisitos do sistema Analista do sistema Projetista do sistema Figura 44 Processo de refinamentos sucessivos na abordagem Draco O processo dividido em duas fases distintas 1 Na primeira fase o analista do dom nio junto com o projetista do dominio com base na experi ncia em sistemas similares e nas t cnicas existentes para modelagem e programa o constr em um conjunto de dom nios O dom nio mais abstrato ou seja aquele mais pr ximo da linguagem do especialista chamado de dom nio do problema ou dom nio da aplica o Os dom nios intermedi rios respons veis pelos refinamentos at o n vel execut vel s o chamados de dom nios de modelagem No n vel mais baixo 211 correspondente as linguagens de programa o est o os dominios execut veis Nessa primeira fase tamb m s o definidas as transforma es de um dom nio para outro e 2 Na segunda fase o analista de sistemas com base nos requisitos de um sistema cria uma descri o do sistema de acordo com a linguagem do dom nio do problema ao qual o sistema pertence Essa descri o automaticamente transformada para descri es nas linguagens de modelagem intermedi rias refinando os modelos os quais o projetista pode modificar para inserir requisitos n o funcionais Os refinamentos se sucedem at produzir o sistema execut vel Esse processo pr
255. gra o entre o gerador e a ferramenta de modelagem DSL Normalmente geradores de c digo consultam informa es diretamente de uma ferramenta de DSL que pode ser criada manualmente ou atrav s de algum framework de constru o de linguagens como GME Generic Modeling Environment GMF Graphical Modeling Framework ou openArchitectureWare Se o 2 2 2 Este padr o defende o uso de uma camada separada de dados constru da em uma tecnologia independente da ferramenta DSL e que cont m apenas as informa es essenciais para o gerador e nada mais Desta maneira a informa o necess ria para o funcionamento do gerador explicitada facilitando a evolu o independente do gerador e da ferramenta DSL Tamb m permite o desenvolvimento dos trabalhos de ambas as equipes a que est trabalhando no gerador e outra equipe trabalhando na linguagem e suporte ferramental Finalmente este padr o libera o gerador de uma tecnologia de modelagem em particular al m de restringir as necessidades de aprendizado das particularidades das ferramentas de modelagem a uma nica equipe A equipe trabalhando com gera o de c digo pode focar em suas pr prias tarefas A Figura 22 ilustra este padr o Ferramenta de modelagem 2 E E O O g Alle 3 eames gt E ES Reposit rio o Geradorde r igs E ar Software especifico da o c digo O gerado ferramenta Figura 22 Padr o camada fina de dados Um segundo padr o que pode se
256. guagens embutidas Enquanto a primeira abordagem resulta em uma DSL mais limpa e f cil de ser utilizada ela requer maior trabalho para implementar o compilador J a segunda abordagem mais r pida e simples de ser implementada pois n o requer a constru o de um compilador Por m os resultados n o s o t o satisfat rios como na primeira abordagem 262 Com rela o a linguagens visuais at pouco tempo o uso do mecanismo de extens o da UML era uma das nicas possibilidades Recentemente com as id ias do desenvolvimento orientado a modelos novas tecnologias surgiram para facilitar esse trabalho S o os chamados frameworks de linguagens que implementam diversas fun es necess rias para a modelagem visual como a representa o cria o e edi o de diagramas e o processamento autom tico de suas informa es internas Exemplos incluem o GME Generic Modeling Environment e o GME Graphical Modeling Framework Analisando a abordagem de DSLs como uma forma de reutiliza o de software pode se notar que os quatro conceitos da reutiliza o tamb m est o presentes Abstra o o processo de an lise de um dom nio de problema levantamento de informa es relacionadas e seu encapsulamento em forma de uma linguagem e uma biblioteca contendo as no es sem nticas corresponde abstra o O conhecimento reutiliz vel do dom nio abstra do e expresso em uma linguagem de forma que um desenvolvedor p
257. guir s o apresentados os detalhes sobre a avalia o realizada 8 1 Defini o Para a defini o dos estudos desta avalia o foi utilizado o paradigma GQM Goal Question Metric BASILI CALDIERA ROMBACH 1994 Neste paradigma devem ser 170 definidos os objetivos da avalia o que devem ser rastreados a um conjunto de dados que definem estes objetivos de forma operacional e a interpreta o destes dados com respeito aos objetivos definidos O rastreamento entre os objetivos e os dados feito atrav s de quest es que caracterizam os objetivos de forma mais espec fica Assim seguindo o formato sugerido no GQM s o definidos dois objetivos para esta avalia o assim descritos e detalhados por meio das respectivas quest es espec ficas G Analisar a abordagem orientada a modelos para reutiliza o de software com o objetivo de determinar se ela promove aumento e ou melhoria na reutiliza o de software quando comparada com o desenvolvimento n o orientado a modelos com respeito aos artefatos do dom nio produzidos do ponto de vista do pesquisador no contexto de projetos de engenharia de dom nio Q Analisando se um mesmo projeto desenvolvido com e sem a abordagem poss vel observar um aumento e ou melhoria na reutiliza o de software no projeto que utilizou a abordagem Q2 Os artefatos de software produzidos com a abordagem s o mais reutiliz veis do que aqueles produzidos em uma abordagem n
258. hegar em termos de reutiliza o de software Neste n vel o processo est em constante otimiza o de acordo com resultados de projetos anteriores Tamb m aqui a qualidade dos artefatos reutiliz veis sujeita a um processo mais rigoroso de controle de qualidade Outras pr ticas interessantes deste n vel 4 incluem a tentativa de se prever e suprir 275 necessidades futuras em termos de artefatos reutiliz veis e uma an lise de mercado para se avaliaram quest es de investimento em reutiliza o AP15 Otimiza o do processo de reutiliza o envolve a identifica o das pr ticas que precisam ser melhoradas seguida da implementa o das melhorias e medi o do progresso de melhoria A cont nua avalia o de novas ferramentas e tecnologias relacionadas reutiliza o tamb m precisa ser realizada A abordagem n o prev atividades para melhoria e evolu o do processo AP16 Controle de qualidade dos artefatos um passo al m da avalia o da qualidade com objetivos espec ficos para os produtos de software sendo incorporados no planejamento da reutiliza o O comit de reutiliza o tamb m precisa ser treinado em m todos estat sticos para poder melhor avaliar os artefatos frente a seus modelos de qualidade A abordagem n o trata do controle de qualidade dos artefatos reutiliz veis AP17 Previsibilidade dos artefatos reutiliz veis consiste na identifica
259. hmid 1999 Bass Clements e Kazman 2003 Clements Kazman e Klein 2004 com duas diferen as principais 1 S o oferecidos meios mais concretos para se elicitar diretrizes arquiteturais expl citas para o suporte aos diferentes tipos de variabilidade na forma de features cen rios e linguagens espec ficas de dom nio o que n o descrito nos m todos citados e 2 Juntamente com as diretrizes s o providenciadas t ticas para atend las utilizando padr es de projeto espec ficos para as diferentes formas de variabilidade a exemplo de outras abordagens da literatura ALMEIDA et al 2007b KEEPENCE MANNION 1999 LEE KANG 2004 6 2 Atividades do projeto de dom nio O projeto do dom nio um processo iterativo de refinamento Inicia se com o dom nio todo e a cada itera o feito um refinamento que identifica novos m dulos que ser o refinados na pr xima itera o e assim por diante at que o projeto esteja conclu do em fun o de um entendimento satisfat rio sobre o que dever ser implementado A primeira atividade cuida da escolha dos m dulos a serem refinados Atividade PD 1 sendo executada no in cio de cada itera o Em seguida s o selecionadas as diretrizes arquiteturais Atividade PD 2 que s o os requisitos mais importantes a serem atendidos pelo projeto da arquitetura Para cada diretriz escolhe se um ou mais padr es arquiteturais Atividade PD 3 respons veis por resolver cada requisit
260. i Figura 12 Candidatos a subdominio do dominio web de autoria de conte do Neste ponto a sobreposi o de subdom nios caso ocorra n o um problema uma vez que pode ser que alguns dos subdom nios sejam descartados Posteriormente com a evolu o do processo e os refinamentos que se seguem este problema ser analisado Sub atividade AD 3 2 Identifica o de linguagens de modelagem O objetivo da identifica o de subdom nios possibilitar a defini o de uma DSL que consiga representar a variabilidade n o capturada nas features e nos cen rios Em dom nios mais maduros por m podem j existir linguagens sendo utilizadas como por exemplo a modelagem entidade relacionamento bastante comum Mesmo que por algum motivo n o possam ser diretamente utilizadas essas linguagens podem oferecer pistas e informa es importantes na defini o de uma nova DSL Nesta atividade o analista do dom nio tenta determinar se existe uma ou mais linguagens para o dom nio O especialista do dom nio 103 consultado al m das documenta es existentes tais como manuais e documenta o das aplica es existentes caso dispon vel A exist ncia de uma linguagem espec fica de dom nio um dos indicativos de que este dom nio est consideravelmente maduro e portanto os benef cios do desenvolvimento orientado a modelos ser o maiores TOLVANEN KELLY 2005 Caso exista c digo fonte dispon vel h a possibilidade
261. ia causada por modifica es no software Produtividade o desenvolvimento de software normalmente constitu do de projeto de baixo n vel e codifica o Artefatos de alto n vel modelos diagramas s o produzidos antes da codifica o e servem de aux lio s tarefas de desenvolvimento e manuten o mas n o constituem o software propriamente dito Al m disso esses artefatos logo perdem seu valor e se tornam retratos irreais do software assim que as fases de codifica o come am pois quaisquer eventuais mudan as que o software sofra s o realizadas somente no c digo e n o s o refletidas nos artefatos de alto n vel devido principalmente s restri es de tempo Sendo assim o tempo gasto na constru o desses artefatos assim como o tempo gasto em esfor os de manuten o devido a essa inconsist ncia com o c digo n o s o diretamente aproveitados na produ o do software Outro ponto referente produtividade diz respeito multiplicidade entre elementos mais conceituais e as linhas de c digo A um nico elemento conceitual podem corresponder in meras linhas de c digo Por exemplo considere uma m quina de estados Um nico estado pode estar representado no c digo em diferentes locais incluindo tabelas de transi es vari veis locais e m todos Suponha que cada estado possui 50 linhas de c digo associadas Dessa forma para se inserir ou modificar um estado 50 linhas de c digo precisam ser inseridas
262. iagramas de classes que as propriedades estruturais de um modelo que s o relevantes para que um ser humano possa compreend lo facilmente s o os atributos e relacionamentos 1 N O tamanho de um modelo em termos do n mero de entidades n o parece ser relevante para compreensibilidade Assim duas m tricas foram definidas para avaliar a manutenibilidade dos modelos nesta abordagem Apesar de originalmente terem sido desenvolvidas para modelos E R e diagramas de classes o conceito de atributos e relacionamentos est presente em v rias linguagens do tipo grafo e portanto podem ser aplicadas em outros tipos de modelos similares Mo N mero de Atributos Nesta m trica s o contados os atributos em um modelo Em modelos visuais diagramas um atributo uma propriedade textual de um elemento visual um cone uma caixa ou um n de um grafo Em modelos textuais um atributo uma propriedade textual de um conceito de primeira classe conforme definido na gram tica da linguagem Mio N mero de Relacionamentos Nesta m trica s o contados os relacionamentos em um modelo Em modelos visuais diagramas um relacionamento representado por uma linha entre dois elementos ou outra representa o relacional entre dois ou mais elementos como por exemplo a representa o de conjuntos no GME Generic Modeling Environment Se o 2 2 2 Em modelos textuais um relacionamento consiste em uma refer ncia entre dois conceitos de primeira cl
263. ibilidade do que o c digo tanto gerado como n o gerado que apresentaram distribui es pr ximas destas m tricas O c digo gerado por m apresenta valores ligeiramente maiores do ndice de manutenibilidade ndice de Manutenibilidade com Abordagem 200 000 150 000 X 100 000 50 000 0 000 50 000 C digo n o gerado C digo gerado Artefatos de gera o Eqi 97 723 100 470 43 835 Amin 38 910 73 640 22 550 4 mediana 110 865 132 285 80 500 m dia 112 645 125 118 72 756 X m x 152 130 171 000 168 560 0q3 141 388 152 458 97 785 191 Figura 32 Distribui es do ndice de manutenibilidade nos diferentes tipos de artefatos produzidos com a abordagem no estudo de caso do dom nio de autoria de conte do para web Para os modelos a manutenibilidade foi analisada atrav s do n mero de atributos e de relacionamentos Conforme mostra a Figura 33 os modelos utilizados para gera o de c digo metamodelos e modelos auxiliares possuem poucos atributos permanecendo completamente abaixo do limite considerado 41 Tamb m possuem poucos relacionamentos com o terceiro quartil sendo similar ao limite considerado 9 J os modelos utilizados como especifica o possuem mais atributos e relacionamentos A m dia do n mero de atributos coincide com o limite considerado 41 enquanto o n mero de relacionamentos tem distribui o bastante acima do limite
264. ica nos diferentes tipos de artefatos produzidos com a abordagem no estudo de caso do dom nio de autoria de conte do para web we sing e Ee ES EOE PERS EES EMS OS EES 190 Distribui es do ndice de manutenibilidade nos diferentes tipos de artefatos produzidos com a abordagem no estudo de caso do dom nio de autoria de conte do para web ss sas da Ala ABLE A dal AA ALE Pee SA 191 Distribui es do n mero de atributos e do n mero de relacionamentos nos modelos utilizados com a abordagem no estudo de caso do dom nio de autoria de conteudo para MED ss a aka ee whe GS US A E Se pn Gn ci im 191 Compara o entre as m tricas de reutiliza o para o estudo do dom nio de aplica es distribu das baseadas em computa o em nuvem 193 Compara o entre as m tricas indiretas de reusabilidade para o estudo do dominio de aplica es distribu das baseadas em computa o em nuvem 194 36 37 38 39 40 41 42 43 44 45 Distribui es de instabilidade de m dulo nos diferentes tipos de artefatos produzidos com a abordagem no dom nio de aplica es distribu das baseadas em computa o em nuvem 0 0 2 ee ee Distribui es de complexidade ciclom tica nos diferentes tipos de artefatos produzidos com a abordagem no dom nio de aplica es distribu das baseadas em computa o em NUVEM ae 3d PD MEDO ad AESA TS A ARO a Distribui es do ndice de manutenibilida
265. icar poss veis subdom nios automatiz veis e produzir documenta o sobre estas informa es O projeto do dom nio tem como objetivo principal projetar uma arquitetura espec fica de dom nio Esta arquitetura deve contemplar as variabilidades identificadas durante a an lise e oferecer suporte ao seu gerenciamento considerando a exist ncia de diferentes tipos de variabilidades em cada subdom nio identificado e artefatos do MDD como DSLs ferramentas de modelagem e transformadores geradores de c digo Por fim na implementa o do dom nio s o produzidos os artefatos de implementa o como componentes DSLs ferramentas de modelagem transforma es e geradores de c digo de forma a implementar a variabilidade conforme prevista e planejada nas fases de an lise e projeto A abordagem apresentada por meio de diferentes elementos e Atividades s o os elementos principais da abordagem Elas representam uma inst ncia concreta de uma determinada pr tica e definem de forma sistem tica a sua execu o Para cada atividade s o identificados os pap is entradas e sa das associados e Produtos de trabalho s o os artefatos produzidos ou utilizados durante a abordagem tais como documentos modelos c digo etc Cada produto de trabalho pode ser modificado ou n o por uma atividade e portanto ele possui diferentes estados em diferentes momentos da abordagem Por exemplo um modelo arquitetural pode estar 13 em estado
266. ido A m trica de instabilidade de um m dulo I busca avaliar esta caracter stica do software sendo definida da seguinte maneira AE ja AA AE Onde AA significa Acoplamento Aferente ou seja o n mero de classes fora deste m dulo que dependem de classes neste m dulo e AE significa Acoplamento Eferente ou seja o n mero 175 de classes dentro deste m dulo que dependem de classes fora deste m dulo A m trica de instabilidade varia entre O e 1 onde I pr ximo a O indica um m dulo est vel e I pr ximo a 1 indica um m dulo inst vel Como n o existem muitos dados pr vios para serem utilizados como base para esta medida neste estudo considerou se que m dulos com instabilidade lt 0 5 s o considerados mais est veis do que a m dia a exemplo do estudo de Almeida et al 20074 Esta m trica pode ser utilizada tanto em artefatos de c digo fonte como em artefatos do MDD como DSLs modelos espec ficos de dom nio transforma es e geradores j que se baseia no conceito de depend ncias Por m enquanto existem ferramentas automatizadas para extrair tais valores diretamente do c digo fonte a coleta com rela o aos demais artefatos deve ser manual M Complexidade ciclom tica Um aspecto cr tico na Engenharia de Software se relaciona separa o de interesses e modulariza o de um sistema de software com o objetivo de se obter m dulos bem definidos test veis e de f cil manuten o Durante a
267. iferentes nota es propostas para a modelagem de features com algumas diferen as em rela o nota o original proposta por Kang et al 1990 Por m uma caracter stica desta t cnica que a nota o fixa ou seja pode n o ser a forma mais intuitiva para representar os conceitos de um dom nio Por este motivo no MDD utiliza se uma maneira mais flex vel para a an lise SCV conforme descrito a seguir 3 1 2 SCV no desenvolvimento orientado a modelos Uma das formas para se realizar a an lise SCV no desenvolvimento orientado a modelos envolve a utiliza o de linguagens espec ficas de dom nio DSL Domain Specific Language para representa o da variabilidade do dom nio VISSER 2007 Uma DSL pode ser t o simples como um wizard ou uma linguagem completa desenvolvida especialmente para representar a variabilidade CZARNECKI 2005 Uma DSL uma linguagem pequena normalmente declarativa focada em um dom nio de problema em particular DEURSEN KLINT VISSER 2000 DSLs existem h um longo tempo Mernik Heering e Sloane 2005 citam os exemplos da linguagem APT para controle num rico que data de 1957 58 e da mais famosa BNF ou Backus Naur Form linguagem para especifica o de gram ticas criada em 1959 Desde ent o diversas linguagens v m sendo desenvolvidas e utilizadas e a literatura nesta rea bastante rica DEURSEN KLINT VISSER 2000 MERNIK HEERING SLOANE 2005 Uma linguagem espec
268. ignifica que hoje um artefato 23 precisa ser mais reutiliz vel do que antes porque n o apenas ele precisa ser reutiliz vel em uma aplica o diferente na mesma plataforma e ambiente mas tamb m em uma aplica o diferente que roda em plataformas e ambientes diferentes Assim a reutiliza o de software uma das reas que pode mais se beneficiar com o MDD Os principais pesquisadores da rea como Neighbors 1980 Krueger 1992 Griss 1995 Frakes e Isoda 1994 Jacobson Griss e Jonsson 1997 defendem a id ia de que os verdadeiros benef cios da reutiliza o de software somente podem ser atingidos quando artefatos de alto n vel s o reutilizados al m do c digo fonte Com o MDD onde modelos s o artefatos de primeira classe isto exatamente o que acontece Mas apesar de parecerem uma combina o natural OMG 2003 reutiliza o de software e desenvolvimento orientado a modelos s o reas bastante distintas H trabalhos que tentam combinar estes dois paradigmas mas a extens o com a qual MDD utilizado para incrementar reutiliza o ou a reutiliza o utilizada para incrementar o MDD ainda n o suficiente Existem abordagens de reutiliza o 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 reutiliza o mas geralmente el
269. igo enquanto o valor FALSO faz com que o gerador n o o inclua Exemplos de tags s o aquelas inclu das pelo projeto JET Java Emitter Templates descrito na Se o 2 2 2 Variabilidades mais complexas podem precisar de mecanismos mais flex veis do que as tags para serem implementadas e parametrizadas Neste caso pode se utilizar scriptlets trechos de metac digo que fazem um trabalho mais elaborado de c pia colagem produzindo uma sa da que une fragmentos de c digo de forma a implementar a variabilidade exatamente como originalmente idealizada Geradores baseados em templates representam transforma es modelo para texto em um nico passo Por m transforma es modelo para modelo devem ser utilizadas para produzir geradores mais bem organizados Nestes casos cuidado especial deve ser tomado para que n o seja necess rio modificar os modelos intermedi rios visando evitar problemas de inconsist ncia Pode se evitar este tipo de problema atrav s de alguns padr es e pr ticas de sucesso na constru o de geradores VOLTER 2008 VOLTER BETTIN 2004 O processo de migra o de c digo deve sempre manter a implementa o de refer ncia consistente com o c digo gerado ou seja deve ser poss vel gerar uma nova implementa o de refer ncia sempre que desejado utilizando os geradores constru dos A princ pio n o existe nenhum problema desde que a migra o de c digo n o modifique a implementa o de refer ncia
270. ilizada Consiste em um nico template que o ponto de entrada respons vel por consultar os modelos e chamar outros templates Esta abordagem difere da abordagem visitante no sentido em que a ordem e l gica por tr s das chamadas dos templates explicitamente programada pelo desenvolvedor n o dependendo de alguma pol tica pr estabelecida Al m disso um template n o necessariamente produz uma unidade distinta como uma classe Um template pode introduzir apenas um nico m todo um peda o de texto 132 que pode ser inserido em outros artefatos Tamb m pode produzir hierarquias completas de classes Esta abordagem pode ser utilizada em diferentes tipos de variabilidade por ser mais flex vel sendo particularmente til para implementar or features como ilustra a Figura 21 Template principal Template N A1 A2 Classe A ese a ai g A Sub feature Sub feature a MY a3 y Sub feature A2 void A1 void A3 C digo gerado Figura 21 Abordagem template sendo aplicada gera o de c digo baseada em features O template principal respons vel por analisar os modelos de features e decidir quais templates ser o chamados quando ser o chamados e em qual ordem No exemplo da Figura 21 a featureA selecionada e implementada por uma nica classe enquanto as sub features Al e A3 que est o selecionadas s o implementadas como os m todos A e
271. imento do especialista do dom nio Toda a informa o deve ser organizada de forma a facilitar sua posterior consulta N o existe uma estrutura fixa para esta tarefa que depende de condi es espec ficas do projeto Enquanto organiza es que possuam sistemas de reposit rio possam utilizar um m todo autom tico de armazenamento e busca simples pastas e arquivos podem tamb m ser utilizados De qualquer forma as seguintes diretrizes podem ser teis e Definir e manter uma estrutura n o muito detalhada dos dados coletados mas que seja consistente Deve ser poss vel ao menos descartar grandes quantidades de informa o durante uma busca e Sempre que poss vel incluir refer ncias para as fontes originais e e Manter uma lista sobre as pessoas envolvidas e consultadas durante o processo com suas informa es de contato para eventuais consultas Sub atividade AD 1 2 Defini o do escopo O objetivo desta sub atividade identificar as features que estar o presentes na futura arquitetura do dom nio Inicialmente o analista do dom nio com base nas informa es sobre sistemas do dom nio e stakeholders identifica as aplica es a serem contempladas no dom nio Existem tr s tipos de aplica es distintas aplica es existentes aplica es que foram desenvolvidas antes do in cio do processo de an lise de dom nio aplica es futuras aplica es para as quais os requisitos 90 est o bem claros
272. io Estes passam ent o a fazer parte do cat logo da organiza o e podem ser reaproveitados em projetos futuros Da mesma forma que as diretrizes arquiteturais nesta abordagem s o necess rias t ticas e padr es para pelo menos tr s aspectos principais variabilidade baseada em features variabilidade baseada em DSLs e integra o entre subdom nios Alguns dos padr es identificados nesta tese s o baseados nos trabalhos de Volter 2003 V lter e Bettin 2004 que s o muito teis para projetos de MDD mas n o s o espec ficos para o projeto arquitetural ou para a engenharia de dom nio e portanto s o acrescentadas discuss es sobre como alguns desses padr es podem ser incorporados ao contexto de reutiliza o Sub atividade PD 3 1 Padr es arquiteturais para variabilidade baseada em features Existe uma s rie de padr es que podem ser utilizados para ajudar a tornar uma arquitetura de software espec fica de dom nio preparada para os diferentes tipos de variabilidade baseada em features Em particular os padr es do GoF GAMMA et al 1995 podem facilitar a representa o da variabilidade no projeto arquitetural resolvendo alguns dos problemas relacionados implementa o das features ALMEIDA et al 2007b No caso do desenvolvimento orientado a modelos necess rio considerar tamb m como os geradores de c digo s o integrados com cada padr o j que partes do software s o automaticamente geradas e precis
273. io trabalho manual o que poderia inibir o uso dos transformadores Outro aspecto similar que tanto no trabalho de Weis Ulbrich e Geihs 2003 como nesta tese as transforma es devem ser espec ficas para cada caso A id ia aqui defendida que os transformadores devem ser customizados de acordo com os requisitos e com o contexto do dom nio sendo constru do da mesma forma que no mecanismo Kase Existem dois pontos no entanto nos quais a presente abordagem difere do Kase 1 Esta abordagem n o est restrita a linguagens visuais por entender que h subdom nios onde o n vel de abstra o da especifica o deve ser mais baixo aproximando se das caracter sticas e poder expressivo de uma linguagem textual e 2 Nesta tese as transforma es n o se baseiam somente em regras de mapeamento por dois motivos 1 transformadores baseados em templates s o mais simples de se construir e manter e 11 a necessidade da engenharia ida e volta reduzida com o uso de uma implementa o de refer ncia e um processo de migra o de c digo Apesar de mais trabalhoso esse caminho foi preferido por ser mais pr tico Czarnecki et al 2005 discutem a combina o das id ias de linhas de produto Se o 2 1 2 e desenvolvimento orientado a modelos ressaltando que essas duas linhas s o complementares Neste sentido os autores prop em a combina o da modelagem de caracter sticas ou features com o uso de templates de
274. ios com foco em aplica es concretas em um processo que eleva a import ncia dos modelos e que encapsula o conhecimento em diferentes formas componentes de software linguagens e ferramentas espec ficas de dom nio e transforma es de software 4 2 Defini o da abordagem A abordagem foi definida ap s estudos da literatura e desenvolvimento de estudos de caso de car ter explorat rio Foram estudados artigos cient ficos e relat rios de empresas na rea de reutiliza o e desenvolvimento orientado a modelos Os resultados do estudo da rea de reutiliza o foram publicados e podem ser encontrados na literatura ALMEIDA et al 2005 ALMEIDA 2007 enquanto os resultados do estudo da rea de desenvolvimento orientado a modelos encontram se no Cap tulo 9 Cada fase da abordagem foi definida separadamente e seguindo sua ordem natural Buscou se incorporar os pontos fortes das outras abordagens da literatura por meio de atividades j bem estabelecidas como aquelas do projeto e avalia o arquiteturais desenvolvidas pelo SEI Software Engineering Institute BASS CLEMENTS KAZMAN 2003 CLEMENTS KAZMAN KLEIN 2004 Buscou se tamb m preencher as lacunas e melhorar os pontos fracos das abordagens descritas na literatura atrav s de novas t cnicas como as atividades para identifica o e gerenciamento dos subdom nios descritas no Cap tulo 5 Nos pontos onde a literatura apresenta solu es que n o s o diretamente aplic
275. isserta o Neste primeiro cap tulo apresentou se a motiva o e objetivos da pesquisa O restante da disserta o est estruturado da seguinte maneira e No Cap tulo 2 discutem se os fundamentos sobre a reutiliza o de software e o desenvolvimento orientado a modelos incluindo os principais conceitos t cnicas e abordagens existentes e No Cap tulo 3 s o discutidos alguns pontos referentes intersec o entre os conceitos da reutiliza o de software e do desenvolvimento orientado a modelos e No Cap tulo 4 apresentada uma vis o geral da abordagem orientada a modelos para reutiliza o de software e Nos Cap tulos 5 6 e 7 s o apresentadas as tr s fases da abordagem an lise projeto e implementa o do dom nio e No Cap tulo 8 s o apresentados resultados da avalia o da abordagem 27 e No Cap tulo 9 s o apresentados os trabalhos relacionados e e No Cap tulo 10 s o apresentadas as considera es finais contribui es e trabalhos futuros 29 2 Conceitos envolvidos Esta tese envolveu duas abrangentes linhas de pesquisa reutiliza o de software e desenvolvimento orientado a modelos Com o objetivo de esclarecer melhor cada linha e seus pontos relevantes a esta tese neste cap tulo s o apresentados os principais conceitos e t cnicas relacionados a essas duas linhas 2 1 Reutiliza o de software A reutiliza o de software j foi considerada como uma bala de prat
276. ito de produzir documentos formatados Por m no caso da reutiliza o de software DSLs normalmente s o utilizadas com o prop sito de se produzir um programa execut vel WARMER KLEPPE 2006 reaproveitando o conhecimento espec fico daquele dom nio A seguir discute se esse tipo de uso para DSLs Linguagens espec ficas de dom nio s o mais uma express o da dicotomia entre abordagens 259 gen ricas que oferecem solu es para m ltiplas reas por m de forma n o otimizada e abordagens espec ficas que oferecem solu es melhores por m apenas para um subconjunto de problemas presente na maioria dos ramos da ci ncia e da engenharia DEURSEN KLINT VISSER 2000 As atuais linguagens de programa o como Java C e C s o exemplos de linguagens de prop sito gen rico ou seja ao criar sistemas para diferentes dom nios de problema pode se utilizar a mesma linguagem O mesmo acontece para linguagens de modelagem como a UML por exemplo que pode ser utilizada em diferentes cen rios No entanto essas linguagens apresentam o problema de exigirem um certo esfor o de tradu o para expressar solu es ou modelos espec ficos para um determinado problema utilizando constru es gen ricas Al m disso esse esfor o de tradu o precisa ser praticamente repetido toda vez que se for construir uma aplica o diferente para aquele mesmo dom nio Para resolver esse problema tr s abordagens t m sido adotada
277. iversity abriga o projeto MIC Model Integrated Computing que pesquisa tr s elementos principais relacionados ao MDD tecnologias para modelagem espec fica de dom nio um conjunto de ferramentas para modelagem e um framework para an lise formal 2 verifica o e transforma o de modelos O principal produto desta pesquisa o GME Generic Modeling Environment um ambiente de metamodelagem que permite a cria o de ferramentas de modelagem espec fica de dom nio de forma simples e r pida A Microsoft atrav s do conceito de f brica de software GREENFIELD et al 2004 tamb m prop e uma abordagem para desenvolvimento de software baseada na reutiliza o sistem tica e MDD Esta abordagem busca imitar o funcionamento de uma f brica tradicional aplicando os conceitos no desenvolvimento de software Ela define tr s elementos 1 o esquema da f brica de software que descreve o que necess rio para construir os produtos da f brica ii o template da f brica que uma inst ncia do esquema e iii um ambiente extens vel consistindo Hnttp www openarchitectureware org Lnttp www eclipse org gmf Bnttp www isis vanderbilt edu projects gme 52 de ferramentas utilizadas para a produ o configuradas atrav s do template da f brica As ferramentas desta abordagem est o focadas no Microsoft Visual Studio principalmente com as DSL Tools COOK et al 2007 um conjunto de ferramentas para defini o
278. ivo Por m os participantes acreditam se tratar de uma limita o imposta pela dificuldade no aprendizado destas tecnologias P Quais foram as dificuldades para o aprendizado da abordagem R A equipe relatou dificuldades no aprendizado das tecnologias de modelagem e gera o de c digo por m com rela o abordagem citaram apenas que tiveram dificuldades em compreender as fun es espec ficas dos casos de mudan a na abordagem Segundo eles n o ficou clara a necessidade de se criar m ltiplos cen rios para descrever pequenas partes do problema 287 P Quais foram as dificuldades para defini o do modelo de features R A equipe teve dificuldades na identifica o correta das features sendo necess ria a presen a constante do autor desta tese para orientar e corrigir as identifica es equivocadas No geral os participantes compreenderam os conceitos mas tinham dificuldade em reproduzi los no dom nio em quest o inserindo constantemente e de maneira equivocada m dulos e fun es como sendo features P Quais foram as dificuldades para descri o da variabilidade em cen rios casos de mudan a R A equipe identificou que a principal dificuldade foi a necessidade de se descrever de forma exaustiva diferentes op es de variantes em cen rios que pouco serviram para o desenvolvimento dos demais artefatos Segundo a equipe seria mais f cil descrever apenas as varia es mais complexas utilizando texto e refer
279. ivo do efeito observado Isto prejudica a sua capacidade de replica o tanto no mesmo grupo como em grupos de pesquisa externos mas tamb m prejudica a rela o causa efeito uma vez que n o se pode afirmar que os efeitos observados s o devidos utiliza o da abordagem ou ocorreram por outros fatores n o previstos Assim necess rio um maior detalhamento das vari veis e aspectos envolvidos para transformar estes estudos em um experimento de car ter exclusivamente cient fico Tamb m n o foi realizada nenhuma avalia o direta do processo Somente foram analisados os produtos artefatos de software desenvolvidos Apesar destes sofrerem influ ncia direta do processo n o se pode afirmar que os resultados observados s o efetivamente causados pela abordagem sem uma an lise mais dedicada de suas atividades e da execu o realizada Ressalta se tamb m o fato de que o processo de identifica o de c digo reutilizado mas n o referenciado descrito na Se o 8 1 1 pode levar a falsos negativos Por exemplo podem existir m todos sendo chamados dentro de blocos condicionais que nunca s o acessados 8 7 Considera es finais Neste cap tulo foi apresentada uma avalia o da tese sendo defendida nesta disserta o Foram realizados tr s estudos emp ricos um em ambiente acad mico e dois em ambiente industrial visando caracterizar os efeitos da utiliza o da abordagem na reutiliza o de software Com exce o d
280. iza o de software que favorece uma abordagem top down PATZKE MUTHIG 2002 dando mais nfase an lise e projeto Outra raz o o fato de que para definir um processo gen rico deve ser poss vel generalizar detalhes espec ficos de plataforma e linguagem de forma que o processo possa ser utilizado independentemente da tecnologia de implementa o Ao mesmo tempo a implementa o extremamente dependente da tecnologia ALMEIDA et al 2008 fazendo com que esta generaliza o seja uma luta entre for as opostas Como resultado observa se uma falta de orienta o com rela o s atividades para implementa o de um dom nio para reutiliza o PATZKE MUTHIG 2002 H in meras t cnicas para se implementar dom nios reutiliz veis como aquelas descritas na Se o 3 2 1 Estas podem ser divididas em tr s dimens es gerenciamento de configura o tecnologias de componente e as caracter sticas generativas das linguagens de programa o MUTHIG et al 2002 Cada dimens o tem sua maneira particular para lidar com a variabilidade que o desafio mais not vel na implementa o de um dom nio reutiliz vel A dimens o de gerenciamento de configura o por exemplo gerencia as variantes alternativas de um mesmo artefato em um mesmo ponto no tempo MUTHIG PATZKE 2004 A dimens o de tecnologia de componentes baseia se na id ia de componentes de software Um componente por defini o uma unidade de co
281. izados como mecanismos de comunica o entre as equipes e guias para o desenvolvimento de software mas tamb m sirvam como entradas para mecanismos automatizados de transforma o de software e gera o de c digo SCHMIDT 2006 e Encapsulando o conhecimento em diferentes formas Como resultado a infraestrutura de reutiliza o que produzida pela abordagem inclui n o somente componentes de c digo mas tamb m artefatos do MDD 1 Linguagens e ferramentas de modelagem espec ficas de dom nio consistem de linguagens com poder expressivo capaz de representar os conceitos do dom nio e 71 ferramentas capazes de criar modelos segundo estas linguagens de forma a facilitar o entendimento de requisitos e a comunica o entre clientes desenvolvedores e 2 Transforma es de software consistem de mecanismos que automaticamente transformam um artefato de software em outro Por exemplo transformam modelos em c digo execut vel scripts de banco de dados arquivos de configura o al m de outros artefatos que fazem parte do produto final As transforma es podem ser do tipo modelo para texto ou seja transforma es que geram c digo ou modelo para modelo que transformam um modelo em outro Em resumo define se o objetivo desta abordagem da seguinte forma Reutilizar software de forma sistem tica considerando se uma fam lia de sistemas similares seguindo uma abordagem centrada em um dom nio e seus subdom n
282. izando tecnologias independentes de plataforma para que esses c digos de diferentes plataformas possam se comunicar e Manuten o e documenta o no desenvolvimento convencional a urg ncia inerente s atividades de manuten o faz com que os desenvolvedores insiram modifica es diretamente no c digo fazendo com que a documenta o fique logo desatualizada No MDD os modelos n o s o abandonados Eles fazem parte do software e as altera es s o realizadas diretamente neles mantendo os consistentes com o c digo Desta forma a documenta o mant m se atualizada o que acaba por facilitar as tarefas de manuten o e Comunica o no MDD os diferentes profissionais possuem meios mais efetivos para comunica o uma vez que modelos geralmente s o mais abstratos que o c digo n o exigindo conhecimento t cnico relativo plataforma Especialistas do dom nio t m um papel mais ativo no processo podendo utilizar diretamente os modelos para identificar mais facilmente os conceitos do neg cio enquanto especialistas em computa o podem identificar os elementos t cnicos e Reutiliza o Diversos autores tais como Krueger 1992 Griss 1995 Frakes e Isoda 1994 Jacobson Griss e Jonsson 1997 ressaltam que a reutiliza o de artefatos de alto n vel proporciona maiores benef cios do que a reutiliza o de c digo fonte No desenvolvimento convencional reutilizar um modelo requer a transforma o manual p
283. jetos deve ser feita a delega o e Parametriza o consiste na inser o de par metros em componentes e interfaces para sele o das variantes O componente ent o respons vel por executar um comportamento diferente de acordo com o par metro especificado e Programa o orientada a aspectos AOP Aspect Oriented Programming com AOP KICZALES et al 1997 funcionalidades mandat rias podem ser implementadas de modo padr o enquanto funcionalidades alternativas s o implementadas em forma de aspectos a serem combinados posteriormente num processo conhecido como aspect weaving Ou seja antes da execu o um programa instancia uma configura o do seu c digo execut vel selecionando as alternativas de aspectos que sejam adequadas ao seu estado atual e Arquivos de configura o consiste na cria o de arquivos separados que cont m as informa es variantes a serem selecionadas e inclu das no produto e Carregamento din mico de classes permite que um produto solicite uma classe dinamicamente em tempo de execu o Esta classe ent o carregada na mem ria e executada Esta t cnica permite a inclus o din mica de alternativas de acordo por exemplo com par metros ou arquivos de configura o Outra t cnica tamb m bastante utilizada no suporte variabilidade o uso de padr es de projeto KEEPENCE MANNION 1999 ANASTASOPOULOS GACEK 2001 LEE KANG 2004 ALMEIDA et al 2007b Padr es com
284. l Modelagem do dom nio PT 4 Inicial subdom nio Candidatos a ADA Valida o e documenta o do dom nio Informa es sobre sistemas do dom nio Conhecimento do especialista Informa es sobre stakeholders PT 1 Inicial Planejamento do dom nio PT 2 Inicial Mapa de aplica es PT 3 Inicial Modelagem do dom nio PT 4 Inicial Candidatos a subdom nio PT 1 Validado Planejamento do dominio PT 2 Validado Mapa de aplica es PT 3 Validado Modelagem do dom nio PT 4 Validado subdom nio Candidatos a AD 5 Decis o sobre inclus o exclus o de subdom nios Informa es sobre sistemas do dom nio Conhecimento do especialista Informa es sobre stakeholders PT 1 Validado Planejamento do dom nio PT 2 Validado Mapa de aplica es PT 3 Validado Modelagem do dom nio PT 4 Validado Candidatos a subdom nio PT 5 Hist rico de decis es sobre inclus o exclus o de subdom nios Quadro 8 Resumo das atividades para an lise de dom nio orientada a modelos O Quadro 9 descreve os produtos de trabalho da fase da an lise de dom nio O produto da an lise de dom nio a defini o completa do escopo e a modelagem das 113 Produto de trabalho Descri o Estado PT 1 Planejamento do dom nio Documento que descreve o dom nio seus objetivos e restri es al m de listar os stakeholders e as aplica es de exemplo 1 Inicial vers o inicial do planejamento
285. l m disso algumas etapas da abordagem n o puderam ser avaliadas como a atividade de avalia o arquitetural e a documenta o dos artefatos Deve se citar que a participa o do autor da tese em dois dos estudos pode ter influenciado negativamente os resultados sendo uma amea a sua validade uma vez que tendo ele pr prio desenvolvido a abordagem n o passou por dificuldades em seu aprendizado e provavelmente falhou em identificar pontos fracos da mesma dois aspectos importantes da avalia o Ainda assim considerou se que os resultados obtidos s o v lidos pois muitos deles foram obtidos a partir de m tricas objetivas que n o sofrem a influ ncia do pesquisador As m tricas subjetivas foram coletadas diretamente dos participantes do terceiro estudo e portanto tamb m n o foram influenciadas Vale mencionar tamb m o fato de que a realiza o dos estudos em ambiente industrial 203 lt Reutiliza o Facilita configura o Reduz os problemas de m ltiplas vers es Dominios de negocios Dominios t cnicos Abordagem simples Orientadaa Modelos para Reutiliza o de Software gt Reutilizagao lt Reusabilidade Mais facil codificar Precisa compensar na escalabilidade do gerador gt Reutiliza o gt Reusabilidade Dificil codificar Esconde as complexidades Dominios t cnicos complexos Figura 43 Uma poss vel hip tese alternativa elaborada a partir dos r
286. l do escopo a melhor forma de se chegar ao tamanho ideal do subdom nio come ando se com um escopo pequeno desenvolvendo partes da linguagem e transforma es e incrementando o sucessivamente As seguintes sub atividades s o respons veis pela identifica o dos subdom nios Inicialmente feita uma sele o inicial de candidatos a subdom nio Sub atividade AD 3 1 Em seguida s o identificadas linguagens de modelagem Sub atividade AD 3 2 e ferramentas Sub atividade AD 3 3 Para cada subdom nio candidato feita a atribui o 101 de n vel de confian a Sub atividade AD 3 4 onde s o avaliadas a maturidade e o estado de cada subdom nio identificado at o momento Por fim os subdom nios s o documentados Sub atividade AD 3 5 Sub atividade AD 3 1 Sele o de candidatos a subdom nio O objetivo desta sub atividade identificar potenciais subdom nios dentro do dom nio O analista do dom nio tenta identificar com base nas informa es coletadas e com o aux lio das diretrizes descritas anteriormente poss veis subdom nios Apesar do conhecimento do especialista do dom nio ser a principal fonte de informa o para execu o desta tarefa o modelo de features pode ser til Observando se o modelo de features o analista pode identificar palavras chave que representam um subdom nio Conforme destacado por MAIDEN SUTCLIFFE 1996 a categoriza o natural do dom nio a melhor indica o de onde e
287. la o com o campo altera o das classes Java correspondentes s a es de consulta inser o e atualiza o que envolvem o campo em quest o altera o do mapeamento de entidades beans que cont m refer ncias para este campo normalmente um arquivo XML altera o dos arquivos de descri o dos formul rios que cont m refer ncias para este campo normalmente arquivos XML entre outras Ou seja o mesmo trabalho bra al e repetitivo que foi necess rio para a constru o do software necess rio tamb m na manuten o Outro problema causado na manuten o diz respeito rastreabilidade entre elementos conceituais e elementos de implementa o Ao se planejar uma mudan a primeiro pensa se em termos conceituais para apenas em seguida identificar os trechos de c digo a serem modificados Sem esta informa o de rastreabilidade esta tarefa dificultada exigindo uma busca cuidadosa no c digo Tamb m pode levar a erros de inconsist ncia entre os diversos artefatos relacionados Por exemplo a modifica o de c digo Java sem a modifica o correspondente dos comandos SQL pode causar erros de execu o Valida o e otimiza o encontrar erros conceituais diretamente no c digo fonte uma tarefa mais dif cil e trabalhosa do que se fossem utilizados modelos mais conceituais Por exemplo considere uma m quina de estados com centenas de estados Identificar olhando apenas para o c digo a exist ncia
288. lidades como 1 ou 3 3 Desta forma features mandat rias e opcionais podem ser consideradas casos especiais das cardinalidades 1 1 e 0 1 respectivamente e Grupos e cardinalidade de grupos features alternativas podem ser vistas como um mecanismo de agrupamento Esta extens o prop e o uso de cardinalidades tamb m nos grupos Por exemplo um grupo de alternativas onde pelo menos uma e no m ximo uma feature deve ser selecionada anotado com a cardinalidade 1 1 Em outro exemplo caso entre duas ou quatro op es do grupo devam ser selecionadas a cardinalidade utilizada 2 4 e Atributos em alguns casos a rela o de uma feature com uma subfeature t o simples que o uso de atributos associados a um tipo como inteiro ou caractere mais elegante e simplifica o modelo e Relacionamentos diferentes relacionamentos podem ser utilizados para relacionar features tais como parte de ou generaliza o 60 e Categorias de features e anota es existem diversas categorias de features que estendem aquelas propostas originalmente por Kang et al 1990 incluindo features funcionais arquiteturais entre outras e e Modulariza o um diagrama de features pode conter um ou mais n s especiais cada um representando um diagrama de features separado Este mecanismo permite a quebra de diagramas grandes em diagramas menores assim como a reutiliza o de partes comuns em diferentes locais Existem d
289. lidades complexas conforme discutido no Cap tulo 6 podem existir alguns casos de variabilidades mais complexas do que a modelagem de features capaz de representar Normalmente s o pontos de varia o abertos nas quais n o poss vel determinar um limite para a presen a ou aus ncia de features a sua implementa o requer um esfor o criativo composicional manual durante o desenvolvimento das aplica es Apesar de ser poss vel facilitar este esfor o atrav s de padr es como factories GAMMA et al 1995 ou outras t cnicas similares o mesmo n o pode ser completamente automatizado utilizando somente tais mecanismos 146 A fase de implementa o segue a mesma estrutura do m todo utilizado por Muthig e Patzke 2004 Inicialmente s o desenvolvidas as comunalidades ou as features comuns a todos os produtos do dom nio Em seguida as variabilidades s o introduzidas uma a uma de forma que ao final tem se uma implementa o que cubra todas as possibilidades Todo o processo baseado em desenvolvimento atrav s de exemplos WIMMER et al 2007 o que facilita a tarefa do desenvolvedor 7 2 Atividades da implementa o do dom nio Inicialmente cada subdom nio identificado durante a an lise de dom nio caracterizado em termos de sua variabilidade Atividade ID 1 Em seguida s o definidas as DSLs e o suporte ferramental ferramentas de modelagem e editores espec ficos de dom nio Atividade ID 2 por meio de
290. ltado e continua navegando 2 Cen rio 2 Busca simples a Usu rio informa string de busca b Aplica o realiza busca em todo conte do c Aplica o exibe lista com o conte do que corresponde string especificada d Usu rio clica sobre um resultado e continua navegando 3 Cen rio 3 Busca avan ada a Usu rio informa string de busca e local a ser buscado 98 b Aplica o realiza busca no local especificado c Aplica o exibe lista com o conte do que corresponde string e locais especificados d Usu rio clica sobre um resultado e continua navegando Neste exemplo as mudan as introduzidas pelos cen rios 2 e 3 n o invalidam o cen rio 1 apenas acrescentam ou refinam comportamento e portanto s introduzem variabilidades positivas A remo o for ada de uma variabilidade negativa por m pode interferir com o real significado dos modelos da base comum produzindo impactos indesejados no projeto do dom nio COPLIEN 2000 Por exemplo em resposta aos cen rios acima um projetista pode projetar uma solu o gen rica onde o local a ser buscado um par metro para o mecanismo de busca que ir conter o nome deste local ou a palavra tudo caso se trate de uma busca simples Em uma aplica o onde a busca avan ada existe esta solu o elegante e simples Mas em uma aplica o onde a busca avan ada n o est presente este par metro n o faz sentido algum e a
291. lvedores de software das complexidades da plataforma de implementa o FRANCE RUMPE 2007 e transforma es que geram artefatos de implementa o automaticamente de forma a refletir a solu o expressa nos modelos SCHMIDT 2006 O MDD pode levar a consider veis benef cios em termos de ganhos de produtividade e qualidade Por exemplo a Nokia relata conseguir desenvolver novos telefones celulares at dez vezes mais r pido e a Lucent reporta ganhos de produtividade de tr s a dez vezes dependendo do produto TOLVANEN 2004 Wile 2004 cita uma redu o de 50 para 1 em termos de linhas de especifica o c digo que pode ser alcan ada atrav s de t cnicas orientadas a modelos Conclui se que o MDD n o pode ser ignorado como uma forma efetiva de se melhorar as atuais pr ticas de desenvolvimento de software Apesar das dificuldades t cnicas e complexidade adicional para se construir o suporte necess rio para o desenvolvimento orientado a modelos no final pode ser vantajoso gastar esfor os extras em busca de suas promessas Reutiliza o de software orientada a modelos Os problemas levantados na se o anterior se tornam ainda mais cr ticos quando se fala em reutiliza o de software uma vez que o princ pio de se construir uma vez para reutilizar v rias vezes requer que o software reutiliz vel c digo fonte e outros artefatos seja facilmente adapt vel a diferentes contextos plataformas e ambientes Isto s
292. m nio Pap is implementador do dom nio Especialista do dom nio Entradas PT 11 Refinado Linguagens espec ficas de dom nio PT 12 Refinado Suporte ferramental para DSLs PT 13 Transforma es do dom nio PT 15 Framework do dom nio Sa das PT 16 Documenta o do dom nio Descri o documenta o de software pode reduzir tempo e esfor o no desenvolvimento de novos projetos facilitar o porte de aplica es para outras plataformas al m de ajudar usu rios a compreender um software mais facilmente PHOHA 1997 No contexto da reutiliza o de software a documenta o ainda mais importante SILVA WERNER 1996 KOTULA 1998 TAULAVUORI NIEMELA KALLIO 2004 uma vez que um reutilizador precisa identificar compreender adaptar e integrar componentes de software em suas aplica es Al m disso normalmente componentes de software s o reutilizados por equipes que n o conhecem nem possuem contato com os desenvolvedores SZYPERSKI GRUNTZ MURER 2002 Por m n o existe um padr o universalmente reconhecido para documenta o de software em parte porque estilos e conte do de documenta o diferem entre programadores e alguma vezes diferem para um mesmo programador em circunst ncias diferentes Adicionalmente a escolha da linguagem de programa o e a natureza de um programa podem ditar um estilo particular de documenta o que pode n o ser facilmente aplic vel a outro ambiente VOTH 2004 Existem alg
293. m nio PT 2 Inicial Mapa de aplica es PT 3 Inicial Modelagem do dom nio PT 3 Inicial Candidatos a subdominio Sa das PT 1 Validado Planejamento do dominio PT 2 Validado Mapa de aplica es PT 3 Validado Modelagem do dom nio e PT 4 Validado Candidatos a subdom nio Descri o antes do modelo do dom nio ser utilizado ele precisa ser validado e documentado A documenta o j foi iniciada durante as atividades anteriores Nesta abordagem as features s o documentadas segundo o formato descrito por Czarnecki e Eisenecker 2000 que inclui a sua descri o sem ntica o racioc nio exemplo de aplica o restri es e outras informa es ALMEIDA et al 2006 Em seguida feita a valida o do dom nio O analista de dom nio verifica hom nimos e sin nimos com o objetivo de reduzir a ambiguidade Em seguida o dom nio validado 107 Atribui o de n vel de confian a Foi definida uma m trica de confian a para avaliar os candidatos a sub dom nio com base no seguinte question rio Quest o Peso Q1 Existe uma linguagem de modelagem para o sub 1 dom nio Q2 Existe uma ferramenta espec fica para o sub dom nio 2 Q3 Caso exista a ferramenta gera c digo conforme 2 requerido pelo projeto Q4 Caso exista a ferramenta extens vel sendo poss vel 3 modificar o suporte para linguagem e ou gera o de c digo Resultado Sub dominio Qi Q2 Q3 N vel de confian
294. m a abordagem as m tricas de porcentagem de reutiliza o M raz o de reutiliza o M2 porcentagem de reutiliza o n o desejada M3 porcentagem de reutiliza o gerada M4 e raz o entre especifica o e c digo M5 analisadas conjuntamente possuem evid ncia ou ind cios sobre o aumento e ou melhoria no n vel de reutiliza o de software no projeto que utilizou a abordagem os artefatos de software produzidos com a abordagem s o mais reutiliz veis do que aqueles produzidos em uma abordagem n o orientada a modelos Mo Instabilidade de m dulo LomAbordagem lt I semAbordagem M7 Complexidade Ciclom tica CCcomabordagem lt CCsemAbordagem Mg Indice de Manutenibilidade IM omabordagem gt IMsemAbordagem My Numero de Atributos NA lt 41 Mio N mero de Relacionamentos NR lt 9 os participantes que utilizaram a abordagem perceberam com as atividades da abordagem referentes preocupa o com MDD desde o in cio do desenvolvimento algum benef cio para a implementa o dos artefatos do MDD DSLs transforma es e geradores de c digo OS participantes que utilizaram a abordagem n o tiveram dificuldades que causaram preju zo ao desenvolvimento em termos de atrasos e curva de aprendizado 8 2 Descri o dos projetos utilizados nos estudos emp ricos e sua execu o Foram realizados tr s estudos envolvendo a aplica o da abordagem em projetos de engenharia de dom nio Par
295. m de ser um conjunto de linhas ordenadas de instru es e comandos que expressam um algoritmo para um computador o c digo fonte encapsula conhecimento de uma forma concreta Algoritmos estruturas de dados classes e fun es representam meses ou anos de evolu o de um software e ali est o contidas as experi ncias da equipe uma tradu o dos requisitos do software em uma forma execut vel e altamente codificada Este conhecimento muitas vezes representa apenas instru es de baixo n vel que servem para opera o do computador manipula o de vari veis truques de otimiza o entre outros Mas ele tamb m um retrato das regras de neg cio do software sendo importante e s vezes vital para o sucesso da organiza o O problema que a linguagem do c digo fonte demasiadamente densa e codificada de 38 forma que dif cil identificar extrair e reutilizar este conhecimento apenas lendo este c digo Al m disso este conhecimento est impregnado por trechos altamente associados a detalhes de plataforma de modo que a reutiliza o de uma determinada l gica de neg cio em uma plataforma ou linguagem diferentes requer um trabalho cuidadoso de reengenharia S o necess rias formas mais intuitivas de representa o do conhecimento que sejam menos dependentes do c digo fonte Uma alternativa o uso de documenta o apropriada mas como J foi discutido na se o anterior existe o problema da inconsist nc
296. m o tempo Esfor os para medir e rastrear a manutenibilidade t m por objetivo reduzir ou reverter a tend ncia de degrada o de integridade de um sistema e indicar quando pode ser mais barato ou menos arriscado reconstruir do que modificar VANDOREN 1997 No contexto da engenharia de dom nio ela um indicador importante da reusabilidade de um artefato MASCENA ALMEIDA MEIRA 2005 uma vez que um dom nio est constantemente em evolu o com novas features ou produtos sendo desenvolvidos ALMEIDA et al 20073 O Indice de Manutenibilidade IM busca medir a manutenibilidade de um m dulo sendo definido da seguinte maneira VANDOREN 1997 IM 171 5 2 x In aveV 0 23 x aveV g 16 2 x In aveLOC 50 sin 2 4x perCM onde aveV m dia do volume Halstead V por m dulo aveV g m dia da complexidade ciclom tica estendida por m dulo aveLOC m dia de linhas de c digo por m dulo e perCM m dia da porcentagem de linhas de coment rio por m dulo A complexidade ciclom tica discutida na m trica M7 O volume Halstead V de um m dulo calculado da seguinte maneira V N xlogn onde N n mero total de operadores n mero total de operandos do m dulo e n n mero total de operadores distintos n mero total de operandos distintos do m dulo Segundo esta m trica m dulos com IM menor do que 65 s o dif ceis de serem mantidos m dulos entre 65 e 85 possuem manutenibilidade razo
297. m orientada a modelos necess rio tamb m implementar os artefatos espec ficos do MDD Assim a implementa o deve tamb m produzir linguagens espec ficas de dom nio transforma es e geradores de c digo Nesta tese entende se por gerador de c digo qualquer artefato capaz de produzir automaticamente com base em uma especifica o de entrada um trecho de c digo como sa da Este trecho de c digo pode ser qualquer tipo de elemento textual mas normalmente corresponde a um programa escrito em uma linguagem de programa o Segundo esta defini o um processador autom tico de templates como o JET um gerador de c digo Mas um arquivo contendo um template tamb m considerado um gerador de c digo uma vez que este possui instru es espec ficas que influenciam diretamente no c digo gerado Enquanto as fases de an lise ARANGO 1999 PRIETO D AZ 1990 KANG et al 1990 FRAKES PRIETO D AZ FOX 1998 BAYER MUTHIG WIDEN 1999 KIM YANG PARK 2003 MEI ZHANG GU 2003 MOON YEOM 2005 ALMEIDA et al 2006 2005 e projeto ALMEIDA et al 2005 BOSCH 2000 BASS CLEMENTS KAZMAN 2003 TRACZ 1995 de 144 dom nio para reutiliza o s o amplamente discutidas pela comunidade cient fica a rea de implementa o apresenta algumas lacunas que precisam ser preenchidas ALMEIDA et al 2008 ANASTASOPOULOS GACEK 2001 Uma das raz es que a engenharia de dom nio tem suas ra zes na comunidade de reutil
298. ma O objetivo manter os aspectos de implementa o independentes dos aspectos de neg cio de modo a melhorar a efici ncia do processo de desenvolvimento Neste n vel as pr ticas e artefatos do MDD s o institucionalizadas incluindo o desenvolvimento de transforma es modelo para texto ENG6 e a verifica o de modelos ENG7 Na rea de gerenciamento este n vel prev atividades para modelagem e aplica o do processo de MDD no projeto PJM2 e PJM3 assim como a defini o coleta e an lise de m tricas do projeto PJM4 Neste n vel tamb m existe a preocupa o com a padroniza o das ferramentas e conven es de modelagem dos procedimentos para coleta e an lise das m tricas e o estabelecimento de um reposit rio de modelos SUP1 SUP2 SUP3 e SUP4 N vel 4 MDD Integrado o n vel 4 caracterizado por uma melhor integra o entre os n veis de abstra o de modelagem Metamodelos independentes e espec ficos de plataforma ENG8 e ENG9 modelos de neg cio ENGIO e transforma es modelo para modelo ENGI1 s o definidos neste n vel Aqui tamb m aparece a preocupa o com a rastreabilidade entre modelos ENG12 com as fam lias de produtos ENG13 caso seja este o foco da organiza o e com a simula o de modelos ENGI4 visando detectar erros de maneira precoce A modelagem do processo nesse n vel passa a incluir os processos autom ticos do MDD PJMS Limites de desempenho de modelagem da organiza
299. maduros enquanto outros necessitam de mais desenvolvimento Neste sentido ao inv s de simplesmente incluir ou excluir um subdom nio existem diferentes n veis de decis es D a serem tomadas e D Exclus o imediata significa que o candidato a subdominio n o pass vel de automa o e deve ser descartado imediatamente Tipicamente este subdom nio tem um baixo n vel de confian a n o existem linguagens de modelagem ou ferramentas que d o suporte e D gt Manter para avalia o posterior significa que este subdom nio tem chance de ser automatizado mas n o existe evid ncia concreta de que isto pode ser feito Tipicamente tem um baixo n vel de confian a nenhuma linguagem de modelagem ou ferramenta mas o especialista do dom nio ou a experi ncia com o desenvolvimento indicam que ele pode ser til ap s algum desenvolvimento N o existe maneira de se estimar o esfor o para torn lo um subdom nio concreto ou seja muito arriscado iniciar algum desenvolvimento neste sentido Portanto essa decis o indica que nenhuma a o ser tomada nesta itera o No entanto caso os stakeholders aceitem o risco este mesmo candidato a subdominio pode se enquadrar no pr ximo n vel de decis o D3 e D3 Iniciar investiga o se um subdominio possui potencial para ser automatizado mas as ferramentas para isso n o est o dispon veis ele pode ser investigado por meio do desenvolvimento de prot tipos de linguagens
300. mento uma vez que tenta capturar o esfor o manual para transformar modelos ou programas medida que os exemplos de destino s o constru dos de forma incremental e gradual Em contraste o trabalho de Varr come a somente ap s exemplos de modelos de origem e destino j existirem sendo portanto mais apropriado para est gios posteriores quando o desenvolvedor j possui uma id ia concreta de como o destino da transforma o deve ser 221 Bierhoff Liongosari e Swaminathan 2006 utilizam exemplos n o somente para derivar as transforma es mas tamb m as DSLs Os autores prop em uma abordagem incremental come ando com uma aplica o constr i se uma DSL para ela contendo os elementos e conceitos da aplica o e os par metros necess rios para configur la Em seguida novas aplica es s o adicionadas incrementalmente e suas diferen as introduzem novas varia es na DSL aumentando sua generalidade Por m os autores destacam que esta abordagem puramente bottom up precisa ser orientada por decis es de projeto tomadas cuidadosamente de antem o caso contr rio corre se o risco de se produzir DSLs extremamente complexas e dif ceis de se manter Este exatamente o caminho tomado pela abordagem desta tese que busca mesclar uma etapa top down para preparar o dom nio para automa o com uma etapa bottom up que introduz detalhes e refinamentos necess rios para o funcionamento pr tico das DSLs e das transforma es
301. midade destas duas reas tamb m se reflete na evolu o das tecnologias envolvidas e da pesquisa acad mica e industrial O desenvolvimento orientado a modelos foco deste trabalho de pesquisa um exemplo recente que re ne os conceitos de DSL e programa o generativa Frameworks Orientados a Objetos Frameworks orientados a objetos ou frameworks de componentes estendem as id ias de bibliotecas de subrotinas e de componentes A principal diferen a e uma das principais caracter sticas dos frameworks a invers o de controle enquanto com bibliotecas comuns a aplica o respons vel por realizar chamadas aos artefatos sendo reutilizados um framework respons vel por realizar chamadas aplica o detendo o fluxo de controle DEURSEN KLINT VISSER 2000 JOHNSON 1997a apud BRAGA 2002 Estruturalmente pode se definir um framework como um conjunto de classes que cont m o projeto abstrato de solu es para uma fam lia de problemas relacionados JOHNSON FOOTE 1988 apud BRAGA 2002 Essas classes encapsulam conhecimento sobre essa fam lia de problemas ou sobre esse dom nio de problema que pode ser reutilizado da mesma forma com que se reutilizam componentes de software Do ponto de vista de seu prop sito pode se definir um framework como o esqueleto de uma aplica o que pode ser instanciado por um desenvolvedor de aplica es JOHNSON 1997b apud BRAGA 2002 Sendo um esqueleto um framework n
302. ml gt lt body gt lt campo gt lt legenda gt Senha lt legenda gt lt tipo gt senha lt tipo gt lt tamanho gt 50 lt tamanho gt lt df citipolequals texto gt lt input type text lt lt campo gt else if c tipo equals senha gt lt input type password lt formulario gt gt lt Campo campos EntradaGerador recuperaTodosCampos foreach Campo c campos gt lt c legenda gt size lt c tamanhot gt gt lt br gt 3 gt lt body gt lt html gt Figura 8 Gera o de c digo baseada em templates Apesar de simples este exemplo demonstra os poss veis benef cios da abordagem A manuten o facilitada pois n o necess rio inspecionar trechos obscuros de c digo HTML para realizar mudan as poss vel produzir novos formul rios simplesmente adicionando um novo elemento lt formulario gt na especifica o ao inv s de copiar um formul rio existente e modificar o c digo Destaca se tamb m a facilidade de ado o por parte de desenvolvedores uma vez que esta abordagem permite gerar c digo em qualquer linguagem ou formato CZARNECKI EISENECKER 2000 Al m disso enquanto outras abordagens produzem c digo fonte que normalmente n o seria escrito m o CLEAVELAND 1988 o uso de templates propicia a gera o de c digo mais leg vel o que desej vel VOLTER 2008 ou mesmo cr tico em muitos casos CZARNECKI EISENECKER 2000 Isto porque o te
303. modelagem de opera es Neste estudo realizado pelo autor da tese junto com um pesquisador da Microsoft Research foi utilizada a abordagem definida nesta tese por m com menor foco na an lise uma vez que j existiam vers es iniciais das linguagens espec ficas de dom nio Ap s o estudo das tecnologias de implementa o envolvidas estas vers es iniciais das linguagens foram refinadas e passou se para as fases de projeto e implementa o do dom nio onde foram desenvolvidos a partir do Zero A arquitetura para o dom nio Uma implementa o de refer ncia baseada em uma infraestrutura respons vel por algumas das fun es b sicas de comunica o e distribui o e Um conjunto de transforma es e geradores que produzem uma aplica o completa no topo da infraestrutura O Quadro 15 resume alguns dados relevantes sobre este estudo 8 2 3 Eventos cient ficos O terceiro estudo foi realizado tamb m em ambiente industrial e envolveu o dom nio de eventos cient ficos Este dom nio engloba sistemas de submiss o e inscri o em eventos mala direta gerenciamento de secretaria e gerenciamento de feiras Trata se de um dom nio de neg cios e a reutiliza o envolve principalmente regras de neg cio relacionadas ao gerenciamento de eventos cient ficos Este estudo foi feito em uma empresa situada em S o Carlos que trabalha com uma linha de produtos deste dom nio realizando desenvolvimento e customiza o d
304. modelos em linhas de produtos de software chamada Pulse MDD O ponto central desta abordagem o foco na arquitetura da linha de produtos como objetivo do processo de MDD e n o na plataforma de destino como J2EE por exemplo A diferen a que com foco na arquitetura e nos produtos da linha obt m se maior grau de adequa o ao dom nio desejado evita se a ocorr ncia de problemas relacionados com a necessidade de se oferecer suporte a possibilidades mais gen ricas que podem nunca ser necess rias organiza o facilitando o desenvolvimento O Pulse MDD define atividades realizadas como parte do projeto arquitetural para a constru o de geradores Estas atividades buscam identificar padr es recorrentes no dom nio para serem utilizados como base para os geradores Visando obter um conjunto economicamente otimizado de padr es um processo iterativo identifica um conjunto de padr es e avalia a porcentagem de c digo gerado alcan ado a cada itera o Em um certo momento torna se muito complexo identificar e implementar um padr o na forma de geradores e portanto o processo termina Esta abordagem possui muitas similaridades com a abordagem desta tese que tamb m iterativa mas especialmente com rela o ao fato de que o desenvolvimento de transforma es e ferramentas de modelagem altamente ligado arquitetura da linha de produto e n o em conceitos gerais das tecnologias de implementa o Os resultados s o por
305. mplate parecido com a sa da desejada acrescido de anota es e instru es que realizam a consulta na entrada e produzem a sa da desejada CLEAVELAND 2001 Existem tamb m padr es de projeto que podem ser utilizados com geradores de c digo A exemplo dos padr es de projeto de software tradicionais estes buscam oferecer solu es para problemas comuns envolvendo o desenvolvimento de software baseado em gera o de c digo Volter 2003 V lter e Bettin 2004 apresentam uma lista com estes padr es 67 3 3 Considera es finais Neste cap tulo foram apresentados detalhes sobre algumas caracter sticas importantes relacionadas reutiliza o de software e ao desenvolvimento orientado a modelos que t m sido adotadas de maneira pr tica em fun o dos conceitos e objetivos inerentes a cada uma dessas duas abordagens De fato cada rea possui objetivos em comum mas emprega t cnicas distintas sendo necess rio cuidado especial ao combin las em uma nica abordagem Em especial destaca se o fato de que a combina o de reutiliza o e MDD n o ocorre somente em pontos isolados do processo mas deve ser iniciada na an lise passando pelo projeto at a implementa o e deve incluir um gerenciamento adequado da variabilidade Nesta tese a engenharia de dom nio foi identificada como a estrat gia de processo a ser utilizada e complementada com t cnicas do MDD de forma que a preocupa o com a modelagem se faz
306. mplementa o que atendem ao projeto realizado na fase anterior Estes artefatos incluem DSLs transforma es geradores de c digo e um framework do dom nio e seguem a arquitetura definida no projeto 81 importante ressaltar que nem sempre as itera es dos ciclos da fase de implementa o produzem artefatos que far o parte do dom nio Como o suporte automatizado a subdom nios incerto e exige investiga o o resultado da implementa o pode ser insatisfat rio de modo que alguns subdom nios podem n o ser inclu dos no processo Esta decis o ir ocorrer na pr xima itera o do ciclo principal no final da fase de an lise subsidiada pelas experi ncias obtidas com a fase de implementa o 4 5 Abrang ncia da abordagem A abordagem definida nesta tese n o cobre todo o ciclo de vida do software pois s o inclu das somente pr ticas de engenharia que dizem respeito utiliza o do MDD como meio de aumentar a reutiliza o de software e algumas pr ticas referentes ao gerenciamento A Figura 10 ilustra a abrang ncia da abordagem em rela o aos modelos de maturidade em reutiliza o e MDD apresentados nas Se es 2 1 2 e 2 2 3 Legenda Pr tica ausente na abordagem CJ Pr tica presente na abordagem N vel 5 MDD Definitivo N vel 4 MDD Integrado e ii EEE e ENGS ENG6 ENG7 PJM2 x Nivel 3 MDD Inicial PJM3 SUP1 SUP2 Nivel 3 Definido ete a i N vel 2 MDD B sico N vel 2
307. mposi o MUTHIG et al 2002 e portanto esta dimens o lida com a variabilidade atrav s da composi o das variantes requeridas na forma de componentes KETTEMANN MUTHIG ANASTASOPOLOUS 2003 MUTHIG PATZKE 2004 A tecnologia generativa CZARNECKI EISENECKER 2000 foco desta tese pode introduzir um controle mais poderoso sobre a variabilidade no dom nio Enquanto varia es dentro de um componente tradicional limitam se a estruturas fixas e interfaces previamente projetadas a tecnologia generativa possibilita varia o em menor granularidade mesmo dentro de componentes Fragmentos de c digo variante podem ser sistematicamente arranjados para formar a implementa o de um componente MUTHIG PATZKE 2004 7 1 Objetivos da implementa o do dominio 2 O objetivo desta fase implementar o dom nio ou seja implementar componentes DSLs transforma es e geradores de c digo seguindo o projeto definido na fase anterior 145 Al m disso existe uma s rie de crit rios que precisam ser atendidos pela implementa o de um dom nio dos quais se destacam aqueles que resultam da necessidade de um bom gerenciamento da variabilidade ANASTASOPOULOS GACEK 2001 MATOS JR 2008 MUTHIG PATZKE 2003 2004 1 Minimizar duplica o de c digo deve se provocar pouca ou nenhuma duplica o de c digo ao implementar a variabilidade 2 Esfor o de reutiliza o a implementa o deve permitir a reutiliza o de
308. mula diversos relatos de sucesso conforme pode ser constatado no Hall da Fama em linhas de produto que conta com empresas como Philips Boeing Lucent entre outras que conseguiram adotar esta pr tica com sucesso 2 1 2 2 Elementos de um processo de reutiliza o Apesar da falta de consenso um estudo preliminar GARCIA et al 2007 2008 analisou diversos trabalhos e modelos descritos na literatura buscando identificar quais elementos de nttp www sei cmu edu productlines plp hof html 35 processo s o necess rios para que a reutiliza o possa ser bem sucedida Este estudo incluiu os esfor os 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 reutiliza o do SPC Software Productivity Consortium primeiro com o RMM Reuse Maturity Model KOLTUN HUDSON 1991 depois com o RPC Reuse Capability Model DAVIS 1993 e finalmente com o RRM Reuse Reference Model RINE NADA 2000 modelos que descrevem as principais pr ticas de reutiliza o em uma organiza o de software e de outros importantes autores da rea como Prieto Diaz 1991 1993 Sherif Appan e Lin 2006 e Morillo et al 2006 No estudo de Garcia et al 2007 2008 foi definido um modelo que re ne as pr ticas comumente relacionadas reutiliza o de software O modelo inicial deste estudo Figura 1 base
309. n mero de relacionamentos N M Assim entre as doze m tricas originalmente propostas apenas estas tr s foram comprovadamente verificadas como sendo relevantes para a manutenibilidade Em outro trabalho GENERO et al 2007 alguns destes mesmos autores demonstram que as mesmas propriedades estruturais de diagramas E R tamb m possuem influ ncia na manutenibilidade de diagramas de classes UML particularmente os relacionamentos de associa o e generaliza o Estas m tricas foram adaptadas e utilizadas 224 nesta tese durante os estudos de caso conforme descrito no Cap tulo 8 Pilgrim 2008 apresenta algumas m tricas para determinar o n vel de abstra o de um modelo O objetivo avaliar a efici ncia das transforma es entre modelos argumentando que transforma es devem inicialmente ser focadas em transforma es na sem ntica e somente posteriormente devem ser inclu dos detalhes da plataforma As m tricas se baseiam no n mero de atributos a exemplo do trabalho de Genero Poels e Piattini 2008 mas tamb m no tamanho do diagrama Nesta tese n o foram utilizadas estas m tricas pois a efici ncia das transforma es n o foi o foco dos estudos de caso Chidamber e Kemerer 1994 apresentam algumas m tricas cl ssicas da orienta o a objetos baseadas em conceitos como acoplamento coes o complexidade de objeto escopo de propriedades conjunto de respostas e combina o de classes Os autores definem as segui
310. n vel em lt http www modelware ist org gt Acesso em 14 jun 2009 MODELWARE Standards Proposals Submitted SI 2006 Dispon vel em lt http www modelware ist org gt Acesso em 14 jun 2009 MOHAGHEGHI P AAGEDAL J Evaluating quality in model driven engineering In MISE 07 Proceedings of the International Workshop on Modeling in Software Engineering Washington DC USA IEEE Computer Society 2007 p 6 ISBN 0 7695 2953 4 246 MOHAGHEGHI P DEHLEN V Where is the proof a review of experiences from applying MDE in industry In ECMDA FA 08 Proceedings of the 4th European conference on Model Driven Architecture Berlin Heidelberg Springer Verlag 2008 p 432 443 ISBN 978 3 540 69095 5 MONPERRUS M et al A model driven measurement approach In MoDELS 08 Proceedings of the 11th international conference on Model Driven Engineering Languages and Systems Berlin Heidelberg Springer Verlag 2008 p 505 519 ISBN 978 3 540 87874 2 MOON M YEOM K An approach to developing domain requirements as a core asset based on commonality and variability analysis in a product line IEEE Transactions on Software Engineering v 31 n 07 p 551 569 2005 MOON M YEOM K An approach to developing domain architectures based on variability analysis In Computational Science and Its Applications ICCSA 2006 S 1 Springer Berlin Heidelberg 2006 Lecture Notes in Computer Science v 3981 2006 p 441
311. nal Assim o uso de variabilidades positivas preferido COPLIEN HOFFMAN WEISS 1998 COPLIEN 2000 Nesta tese foram definidos os seguintes passos numa forma sistem tica de se tomar a decis o sobre quais cen rios fazem parte da base comum e quais introduzem variabilidades 1 Come ar com as features mandat rias pois estas estar o presentes no dom nio Estas ir o fazer parte dos casos de uso os cen rios que descrevem o comportamento normal 2 Para cada feature opcional criar um caso de mudan a 3 Para as features alternativas onde obrigat ria a exist ncia de ao menos uma variante escolher aquela que representa a maioria dos casos para fazer parte da base comum No exemplo acima se a busca simples est presente em mais produtos do que a busca avan ada esta seria escolhida para inclus o como um caso de uso A busca avan ada seria modelada como caso de mudan a e 4 Caso o processo resulte em casos de mudan a que apresentam variabilidade negativa avaliar a possibilidade de transforma o em variabilidade positiva pois esta prefer vel COPLIEN HOFFMAN WEISS 1998 COPLIEN 2000 Para realiza o do ltimo passo o seguinte m todo pode ser utilizado 97 Supondo que um caso de uso UCO01 possua 5 passos p1 p2 p3 p4 e p5 ap s an lise da variabilidade descoberto um caso de mudan a CM001 que possui 4 passos pl p2 p4 e p5 CMO001 introduz uma variabilidade negativa em
312. ncia o EMF n o segue fielmente o padr o JMI mais voltado para reposit rios persistentes O EMF utiliza um subconjunto de mapeamentos de metamodelo para Java otimizados para manipula o em mem ria ECLIPSE 2006 o que o torna al m de mais eficiente mais simples de ser utilizado por m menos abrangente do que o conjunto mais completo formado pela combina o JMI MOF MOORE et al 2004 Al m do metamodelo existem outras duas diferen as 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 reposit rio de metadados o MDR oferece diferentes formas de armazenamento tais como a representa o em mem ria banco de dados ou no sistema de arquivos em estrutura de rvore B J o EMF tem foco na manipula o eficiente dos metamodelos permitindo somente a representa o em mem ria Outra diferen a que no MDR somente as interfaces de manipula o do metamodelo s o geradas O c digo que as implementa um s para qualquer metamodelo Estando embutido no MDR esse c digo utiliza programa o reflexiva para possibilitar o acesso s informa es do metamodelo J no Snttp www eclipse org emf 50 EMF todo o c digo de acesso ao metamodelo gerado outra raz o pela qual ele mais rapido do que o MDR Metamodelo Epiit Basses Gerado automaticamente Ny Abordagem DO Abordagem MD
313. ncontrar um subdom nio Lee amp Kang apresentam a t cnica de an lise de agrupamento de features LEE KANG 2003 que pode ser utilizada nesta atividade A t cnica se baseia na identifica o das unidades de agrupamento de features FBU Feature Binding Units Uma FBU um conjunto de features relacionadas que juntas executam um servi o ou opera o dentro do dom nio ou seja devem coexistir para que este servi o esteja presente no produto final Esta t cnica tem o objetivo de auxiliar no processo de configura o dos produtos determinando quais conjuntos de features estar o presentes dependendo da configura o desejada O processo de an lise das FBUs inicia se com a identifica o das features de capacita o que representam servi os independentemente configur veis ou seja as macro funcionalidades principais do dom nio que podem ser adicionadas ou removidas de um produto como unidades independentes Normalmente estas s o as features localizadas no topo do diagrama A partir destas features principais percorre se o modelo incluindo as demais features relacionadas que s o necess rias para que esta macro fun o possa ser executada Dentro de uma FBU identificada podem existir features que s o opcionais ou alternativas podendo ser selecionadas de acordo com a necessidade do produto Estes sub conjuntos de features devem ser separados em FBUs diferentes pois a exemplo das features de capacita o tamb m
314. necess ria uma an lise mais cuidadosa combinando se diferentes m tricas que avaliem os aspectos importantes para este estudo espec fico Assim as seguintes m tricas foram definidas para a quest o Q4 M Porcentagem de reutiliza o RP Reuse Percent Esta a m trica mais b sica de reutiliza o sendo definida como a raz o entre o n mero de linhas de c digo reutilizadas e o n mero total de linhas de c digo POULIN CARUSO 1993 Um cuidado especial deve ser tomado com esta m trica pois pode levar a conclus es incorretas Por exemplo caso seja reutilizado um nico m todo pequeno de uma classe com milhares de linhas de c digo esta porcentagem seria alta mas n o refletiria a realidade de que apenas uma por o da classe foi reutilizada A coleta desta m trica envolve a identifica o dos m dulos reutilizados e a contagem das linhas de c digo dos m dulos reutilizados e n o reutilizados M Raz o de reutiliza o RR Reuse Ratio Esta m trica calculada da mesma forma que a M1 por m tamb m considerando se a reutiliza o do tipo caixa branca DEVANBU et al 1996 artefatos modificados at um certo n vel s o considerados como reutilizados Devanbu et al 1996 sugerem o valor de 25 como margem de toler ncia artefatos que tiveram mais de 25 de seu c digo modificado n o s o considerados como reutilizados M3 Porcentagem de reutiliza o n o desejada Conforme destacado na m trica Mj
315. ng aspect oriented and model driven software development In SPLC Sl IEEE Computer Society 2007 p 233 242 Dispon vel em lt http doi ieeecomputersociety org 10 1109 SPLINE 2007 23 gt Acesso em 14 jun 2009 VOTH D Packaging reusable software assets IEEE Software v 21 n 3 p 107 110 2004 W3C XML Path Language XPath Version 1 0 W3C Recommendation 16 November 1999 S 1 1999 W3C XSL Transformations XSLT Version 1 0 W3C Recommendation 16 November 1999 S 1 1999 WARMER J KLEPPE A Building a flexible software factory using partial domain specific models In Proc of The 6th OOPSLA Workshop on Domain Specific Modeling S 1 s n 2006 p 15 22 WEIS T ULBRICH A GEIHS K Model metamorphosis IEEE Software v 20 n 5 p 46 51 2003 WEISS D LAI C T R Software Product Line Engineering A Family Based Software Development Process S 1 Addison Wesley 1999 WEISS D M et al Decision model based code generation for SPLE In SPLC S 1 IEEE Computer Society 2008 p 129 138 ISBN 978 0 7695 3303 2 Dispon vel em lt http dx doi org 10 1109 SPLC 2008 42 gt Acesso em 14 jun 2009 WILE D Lessons learned from real DSL experiments Sci Comput Program Elsevier North Holland Inc Amsterdam The Netherlands The Netherlands v 51 n 3 p 265 290 2004 ISSN 0167 6423 WIMMER M et al Towards model transformation generation by example In 40th Hawaii Int
316. niciar uma jornada como a de um doutorado recomendo fortemente a presen a da fam lia Tamb m agrade o a meus pais Hor cio e Dalila meus irm os e cunhados Rafael e Amanda Maur cio e Andr a F bio e Andr a meus sogros Vivaldo e Ivani e meus sobrinhos Gabriel Leo Dudu e Giovanna E tamb m a Guiza minha companheira fiel durante grande parte do desenvolvimento e escrita da tese E obrigado DEUS pela minha vida Academic organizations in computer science seem to prefer to work on new theories However some of the most successful academic work is a fusion and formalization of successful techniques James M Neighbors Resumo A reutiliza o de software busca aumentar a qualidade e produtividade no desenvolvimento de software evitando a duplica o do esfor o e reaproveitando o m ximo poss vel das experi ncias de projetos passados Apesar de simples esta id ia n o facilmente colocada em pr tica principalmente de maneira sistem tica e controlada T cnicas de engenharia de dom nio e linhas de produtos de software buscam facilitar esta tarefa por m ainda existem outros fatores que dificultam a ado o da pr tica da reutiliza o Entre estes destacam se os problemas inerentes ao desenvolvimento de software da maneira como conduzido atualmente baseado em c digo fonte Estes problemas t m suas origens na crescente demanda por software cada vez mais complexo e afetam negativamente a capacidade de reu
317. nios PT 9 Avaliado Projeto do dom nio PTIO Subdom nios caracterizados PT 11 Inicial Linguagens espec ficas de dom nio PT 12 lnicial Suporte ferramental para DSLs Sa das PT Il Refinado Linguagens espec ficas de dom nio PT 12 Refinado Suporte ferramental para DSLs PT 13 Transforma es do dom nio PTI4 Implementa o de refer ncia Descri o considerando se somente seu poder representativo uma DSL composta somente pela sintaxe abstrata e concreta A sintaxe abstrata voltada para interpretadores autom ticos enquanto a sintaxe concreta projetada para ser usada por seres humanos na cria o de inst ncias da DSL diagramas ou programas Mas para ser til no cen rio do MDD um terceiro elemento deve estar presente a sem ntica que define o significado dos elementos da linguagem No contexto do MDD a sem ntica definida em forma de a es a serem executadas por um interpretador autom tico que traduz o modelo programa ou diagrama em outra linguagem bem conhecida KLEPPE 2007 No contexto da engenharia de dom nio a sem ntica adquire ainda outra import ncia associada variabilidade do dom nio Transforma es de software s o respons veis por traduzir a variabilidade expressa em uma DSL em c digo concreto de forma que o software gerado implemente as variantes selecionadas corretamente 155 At o momento uma abordagem top down foi seguida utilizando modelos de alto n vel
318. niversidade de Cambridge OMG 2003 Desta forma podiam reutilizar subrotinas pre constru das para a solu o de problemas num ricos comuns Desde ent o programadores efetivamente reutilizam software seja procurando em seus registros pessoais projetos antigos reposit rios p blicos ou mesmo sua pr pria mem ria DESOUZA AWAZU TIWANA 2006 Al m disso projetos de software raramente envolvem somente elementos completamente novos literatura mostra que entre 40 e 60 do c digo de uma aplica o pode ser reutilizado em outra aplica o 60 dos artefatos de projeto s o reutiliz veis 75 das fun es s o comuns a mais de um programa e apenas 15 do c digo de um sistema nico e novo EZRAN MORISIO TULLY 2002 Outros autores citam taxas de potencial de reutiliza o que variam entre 15 e 85 MILI MILI MILI 1995 Ou seja reutiliza o intr nseca ao desenvolvimento de software A grande quest o que vem motivando d cadas de pesquisa que a reutiliza o n o sistem tica que realizada de forma ad hoc dependente de iniciativa conhecimento e talento individuais n o implantada de forma consistente na organiza o e sujeita a pouco ou nenhum tipo de controle e planejamento gerenciais Muitas vezes tem efeitos ca ticos alimentando a cultura do hero smo individual e apagamento de inc ndios e amplificando problemas e defeitos ao inv s de reduzi los EZRAN MORISIO TULLY 2002
319. njunto de pr ticas para engenharia e gerenciamento de um processo de desenvolvimento orientado a modelos Dentre os resultados dessa frente destaca se um framework de processo para o MDD MODELWARE 2006e e um modelo de maturidade MDD MODELWARE 2006d e Infraestrutura ferramental nessa frente de trabalho foram desenvolvidas ferramentas e ambientes para uma abordagem de desenvolvimento orientado a modelos lt A infraestrutura baseada em c digo aberto contemplando as quest es de integra o de ferramentas MODELWARE 2006g e mecanismos de transforma o MODELWARE 2006f e Ado o bem sucedida uma das preocupa es desse projeto garantir que as tecnologias desenvolvidas sejam disseminadas e utilizadas na pr tica pela ind stria Neste sentido foram realizadas como parte dessa frente de trabalho demonstra es e propostas para padroniza o MODELWARE 2006h e MDD industrial essa frente de trabalho tem como objetivo validar os resultados obtidos pelas outras frentes de trabalho na ind stria e e Gerenciamento diz respeito manuten o da estrat gia do projeto em conformidade com o contrato inicial e com os objetivos inicialmente previstos O projeto ModelWare grande e abrangente com resultados expressivos tais como o MOF Script e ATL descritos na Se o 2 2 1 Esta tese se relaciona principalmente com a frente de processos e metodologias O framework de processo e modelo de maturidade MDD
320. no desenvolvimento de software por meio da redu o de esfor o repetitivo e da ado o de solu es que agregam conhecimento pr vio No caso da reutiliza o busca se encapsular em forma de artefatos de software diversos informa es e conceitos reutiliz veis de um dom nio incluindo algoritmos estruturas de dados fun es etc No caso do desenvolvimento orientado a modelos busca se encapsular tamb m o conhecimento necess rio para se produzir esses artefatos em forma de transforma es que mapeiam conceitos de mais alto n vel at o c digo particularmente interessante o fato de que o desenvolvimento orientado a modelos pode promover a reutiliza o em mais alto n vel conforme sempre defendido e idealizado por in meros autores NEIGHBORS 1980 KRUEGER 1992 GRISS 1995 FRAKES ISODA 1994 JACOBSON GRISS JONSSON 1997 Este fato evidencia o potencial que o MDD possui para elevar os n veis de reutiliza o Nesta tese foram identificados dois pontos importantes de intersec o entre a reutiliza o e o MDD i a an lise de escopo comunalidade e variabilidade an lise SCV e ii a implementa o da variabilidade Estes pontos tomam formas distintas em cada abordagem conforme descreve se a seguir 3 1 An lise SCV Uma das principais atividades necess rias para projetos de reutiliza o em grande escala chamada de an lise SCV Scope commonality and variability ou escopo comunalidade e varia
321. no deste processo investigativo que culmina com esta atividade e a decis o nela tomada influencia todas as demais atividades O ciclo principal evolui da seguinte forma a cada itera o 1 Atividade AD 1 Planejamento do dom nio esta atividade consiste da prepara o 76 e planejamento necess rio determinar se vale a pena investir na constru o da infraestrutura reutiliz vel para o dom nio em quest o Para isso s o levantadas e registradas todas as informa es referentes ao dom nio s o identificadas as features do dom nio que servem de base para a elabora o de um plano de desenvolvimento A cada nova itera o o plano inicial revisto incluindo novas considera es que possam ter sido elicitadas na itera o anterior durante o projeto e implementa o tamb m nesta atividade que uma an lise de risco realizada para determinar se vale a pena continuar investindo no dom nio e se novas itera es s o necess rias Atividade AD 2 Modelagem do dominio esta atividade cuida da cria o de modelos do dom nio agrupando as features identificadas na atividade anterior Tamb m s o desenvolvidos cen rios do dom nio com foco na variabilidade A cada itera o o analista do dom nio refina os modelos de features e cen rios considerando se a eventual inclus o de novos artefatos ou mesmo novos subdom nios Atividade AD 3 Identifica o de subdom nios nesta atividade o objetivo te
322. ntar identificar subdom nios com potencial para automa o com base em diferentes tipos de ind cios como a exist ncia de linguagens ferramentas e documenta o que resultam em um determinado n vel de confian a para cada subdom nio A cada itera o o analista do dom nio revisita a lista de subdom nios ap s a experi ncia obtida com as implementa es e investiga es realizadas na itera o anterior Novos n veis de confian a podem ser atribu dos aos subdom nios identificados o que pode levar a novas decis es posteriormente Novos candidatos a subdom nio tamb m podem ser identificados Atividade AD 4 Valida o e documenta o do dom nio esta atividade consiste na revis o da informa o e cria o de documentos que descrevem as features e modelos constru dos nas atividades anteriores A cada itera o os documentos existentes s o atualizados para refletir eventuais mudan as Ger ncia de configura o e controle de vers es devem ser utilizados para manter estes documentos organizados Atividade AD 5 Decis o sobre inclus o exclus o de subdom nios nesta atividade o analista do dom nio junto com o especialista e os demais stakeholders analisam os subdom nios identificados com o objetivo de determinar se os mesmos ser o inclu dos nas fases subsequentes de projeto e implementa o A cada itera o toda nova informa o sobre os candidatos a subdom nio revista e novas decis es pod
323. ntegra o normalmente consiste em modificar o artefato o contexto ou ambos para que possam compor a funcionalidade desejada KRUEGER 1992 Essa abordagem apesar de proporcionar ganhos de produtividade apresenta alguns problemas tais como e Uma vez que o artefato normalmente modificado necess rio test lo novamente para garantir que as modifica es n o introduziram nenhum erro novo e Os processos de abstra o e sele o dependem muito do talento individual e da experi ncia do desenvolvedor pois se baseiam muito na mem ria humana e e Caso o desenvolvedor n o conhe a o artefato sendo reutilizado ele precisa gastar algum tempo compreendendo o antes de copi lo para o novo contexto Desta forma caso esse tempo seja muito grande o que ocorre na maioria dos casos envolvendo c digo fonte que ele acaba optando por desenvolver um novo artefato a partir do zero DESOUZA AWAZU TIWANA 2006 Por esses e outros motivos a pesquisa vem evoluindo na busca por novos m todos e t cnicas que evitem tais tipos de problemas A seguir s o apresentadas as principais abordagens voltadas para reutiliza o de software existentes na literatura destacando se o desenvolvimento baseado em componentes SAMETINGER 1997 SZYPERSKI GRUNTZ MURER 2002 linguagens espec ficas de dom nio DEURSEN KLINT VISSER 2000 programa o generativa CZARNECKI EISENECKER 2000 e outras t cnicas tais como frameworks JOHN
324. ntes m tricas m todos ponderados por classe WMC Weighted Methods per Class profundidade da rvore de heran a DIT Depth of Inheritance Tree n mero de filhos NOC Number Of Children acoplamento entre classes CBO Coupling Between Object classes resposta para uma classe RFC Response For a Class e falta de coes o em m todos LCOM Lack of Cohesion in Methods Estas m tricas focam em diferentes aspectos de um projeto tais como complexidade dificuldade de desenvolvimento e manuten o Os autores tamb m destacam o papel do acoplamento na reutiliza o Quanto menor o acoplamento mais f cil ser a reutiliza o de uma determinada classe Outras m tricas cl ssicas para projetos orientados a objetos incluem a estabilidade MARTIN 1994 manutenibilidade VANDOREN 1997 e complexidade MCCABE 1976 Algumas destas m tricas foram utilizadas nos estudos de caso nas partes do dom nio onde n o houve aplica o do MDD e para compara o com o software constru do manualmente conforme descrito no Cap tulo 8 Muskens Chaudron e Lange 2004 prop em a coleta de m tricas cl ssicas da orienta o a objetos diretamente em modelos UML ou seja antes que exista c digo fonte Os resultados mostraram que poss vel detectar os mesmos problemas utilizando esta abordagem por m no in cio do desenvolvimento Portanto a es corretivas s o menos dispendiosas uma vez que n o exigem a modifica o extensa do c
325. ntes tipos de artefatos produzidos com a abordagem no estudo de caso do dom nio de autoria de conte do para web A Figura 31 analisa de forma mais aprofundada as medidas de complexidade ciclom tica obtidas com a abordagem Pode se notar que o c digo gerado semelhante na m dia ao c digo n o gerado por m a distribui o do c digo n o gerado est um pouco mais concentrada Os demais artefatos incluindo transforma es geradores e modelos s o consideravelmente mais complexos do que o c digo com alguns valores acima do limite considerado como o de m dulos simples 10 Complexidade Ciclom tica com Abordagem 16 000 14 000 12 000 10 000 i 8 000 5 6 000 4 000 2 000 0 000 g C digo n o gerado C digo gerado Artefatos de gera o Modelos qi 1 500 1 000 1 000 1 000 Amin 1 000 1 000 0 000 1 000 mediana 2 500 2 500 3 000 1 000 m dia 2 734 2 219 4 189 5 667 X m x 7 500 3 667 14 000 15 000 q3 2 667 2 839 5 000 8 000 Figura 31 Distribui es de complexidade ciclom tica nos diferentes tipos de artefatos produzidos com a abordagem no estudo de caso do dom nio de autoria de conte do para web A Figura 32 analisa de forma mais aprofundada os ndices de manutenibilidade obtidos com a abordagem Pode se notar que os elementos de gera o de c digo transforma es e geradores possuem menor ndice de manuten
326. ntifica o de reas de interesse espec ficas para cada especialidade no dom nio fica mais restrita exist ncia de linguagens espec ficas daquele dom nio J nesta abordagem um subdom nio pode ser identificado mesmo sem a exist ncia de linguagens e ou ferramentas dedicadas Ap s o trabalho de Neighbors diversos esfor os foram gastos em busca de uma melhor utiliza o dos conceitos do MDD Recentemente foi desenvolvido o projeto ModelWare como parte do IST Information Society Technologies uma das prioridades do planejamento estrat gico envolvendo a pesquisa tecnol gica realizada pela comunidade europ ia Envolvendo 212 institui es de pesquisa e empresas de toda a Europa o projeto ModelWare foi dividido em seis frentes de trabalho descritas a seguir e Tecnologias de modelagem o objetivo dessa frente prover a base te rica e tecnol gica de suporte para os desafios do MDD na ind stria Envolve a defini o de mecanismos para descrever arquiteturas e plataformas transforma es de modelos simula o de execu o de modelos assim como mecanismos para especificar e empacotar componentes MDD Dentre os principais resultados alcan ados por essa frente de trabalho destacam se os perfis para modelagem de arquiteturas e plataformas MODELWARE 2006a e a defini o do que seriam transforma es reutiliz veis MODELWARE 2006b e Processos e metodologias o objetivo dessa frente de trabalho prover um co
327. nto Para isso o analista do dom nio realiza as seguintes tarefas An lise dos stakeholders compreende a identifica o dos diferentes stakeholders seus pap is e interesses dentro do processo Defini o dos objetivos corresponde defini o dos objetivos de acordo com os interesses dos stakeholders para o projeto Defini o de restri es compreende a defini o das restri es impostas pela organiza o 89 e pelas condi es de mercado deixando claro o que est al m do escopo do processo An lise de mercado se aplic vel esta tarefa n o trivial que pode ser realizada ou n o dependendo dos custos complexidade e maturidade da organiza o com rela o ao dom nio consiste na pesquisa e an lise sistem ticas dos fatores que determinam o sucesso do dom nio no mercado Junto com um especialista de mercado o analista do dom nio coleta informa es sobre o neg cio estudos e an lises da competi o segmenta o de mercado planos de neg cios e a integra o desta informa o em um plano estrat gico de neg cios coeso CLEMENTS NORTHROP 2002 Coleta de dados a tarefa realizada pelo analista do dom nio junto com o especialista do dom nio respons vel por elicitar e examinar todo tipo de conhecimento sobre o dom nio em foco Inclui a an lise de toda a documenta o existente planos de projetos manuais de usu rio modelos dicion rios de dados aplica es existentes e o conhec
328. o aux lio do especialista Pode conter inconsist ncias ou n o cumprir cen rios que sejam importantes a algum outro stakeholder 2 Avaliado projeto avaliado por uma atividade espec fica que considera o ponto de vista de diversos stakeholders Quadro 11 Descri o dos produtos de trabalho da fase de projeto de dom nio 143 7 Implementa o de dom nio orientada a modelos A an lise de dom nio e projeto arquitetural realizados em fase anterior lidam com quest es como qual a melhor maneira de dividir o dom nio em sub sistemas ou como os m dulos devem interagir entre si de forma a maximizar o desempenho na execu o de determinada tarefa cr tica Por m quest es de mais baixo n vel ainda permanecem n o resolvidas tais como qual tecnologia de comunica o deve ser utilizada em um dom nio distribu do Como ser o acesso base de dados Como a internacionaliza o ser alcan ada Qual algoritmo de busca deve ser utilizado Estas s o o foco da etapa de implementa o do dom nio que nesta abordagem tamb m engloba o refinamento do projeto de alto n vel em um projeto detalhado Entre as quest es a serem respondidas destaca se o suporte variabilidade Como os componentes do dom nio ir o dar suporte aos diferentes pontos de varia o Esta quest o come ou a ser respondida durante o projeto e agora necess rio tomar as decis es finais quanto ao projeto detalhado Al m disso sendo esta uma abordage
329. o que se v obrigada a realizar a migra o ou permanecer defasada em rela o aos concorrentes O problema da portabilidade surge da quantidade de esfor o despendido em tarefas espec ficas da plataforma esfor o este que n o pode ser reaproveitado em outras plataformas Idealmente o desenvolvimento de software deveria ser mais conceitual e menos focado em esfor o repetitivo Interoperabilidade sistemas de software raramente funcionam isoladamente Normalmente eles precisam se comunicar entre si para trocar informa es ou realizar tarefas em conjunto Al m disso com as atuais id ias 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 heterog neos como a Internet Neste contexto a interoperabilidade torna se um requisito do software trazendo consigo v rios outros como a necessidade de equipes distintas com profissionais e especialistas dedicados s diferentes partes do software Tamb m exige formas de comunica o mais eficientes entre as diferentes equipes e a ger ncia j que cada pessoa envolvida nestes projetos multidisciplinares tem conhecimentos e interesses em diferentes partes do problema Uma poss vel solu o o MDD surgiu como uma maneira de se resolver estes problemas utilizando uma abordagem altamente automatizada e com promessas de ganhos significativos em termos de qualidade
330. o Ee Se ee ee A ata 4 5 Abrang nciadaabordagem 2 0000 4 6 Considera es finials sea E ER BA ed RR R An lise de dom nio orientada a modelos 19 23 25 26 29 29 36 55 57 57 62 67 69 69 71 12 74 81 84 85 5 1 Objetivos da an lise de dom nio ccccccccll e 86 5 2 Atividades da an lise de dom nio ass EEE EE E E E ES RS 87 5 3 Considera es THAIS que care Sie nese GRE ud ewe SUR ad ES SRS RS 112 6 Projeto de dominio orientado a modelos 115 6 1 Objetivos do projeto de dom nio 0 002 0000 118 6 2 Atividades do projeto de dom nio 2 seres asia a saca ee Be prado E 119 6 3 Considera es MAIS 4 ss 4 Bd SU dee ee ete eee eRe G 140 7 Implementa o de dom nio orientada a modelos 143 7 1 Objetivos da implementa o do dom nio 204 144 7 2 Atividades da implementa o do dom nio 04 146 7 3 Considera es finais 4 5 24 oq 6d ee APSA DAE ALE LU RA 166 8 Avalia o 169 Bak STAG AO o ca a Pensa PR ro a Rae q a Meas aged gee 169 8 2 Descri o dos projetos utilizados nos estudos emp ricos e sua execu o 181 8 3 Coleta dos dados agr aaa Beek oti ERA Ear SS ETR CE os E 186 8 4 Resultados e dISCUSS O sugere aa Ea a rg Re a 0 U TE 188 8 5 An lise das hip teses e conclus es 0 202 ee ee eee 201 6 OF GRIME AGUS AVA Gade stam gears irc r Lg Ue UR ek a ES 2
331. o de necessidades futuras em termos de artefatos potencialmente reutiliz veis visando reduzir o tempo de desenvolvimento em projetos envolvendo estes artefatos N o h nenhuma atividade com este objetivo AP18 An lise de condi es de mercado e retorno de investimento busca analisar o n vel de retorno dos investimentos em reutiliza o de acordo com as condi es do mercado e oportunidades para novos neg cios Tamb m envolve a aquisi o de artefatos do dom nio caso necess rio A an lise de mercado realizada superficial e se resume a uma pesquisa com base em conhecimento dos especialistas sem atividades espec ficas para determina o de custos e retorno de investimento Modelo de maturidade em MDD MODELWARE 2006d e N vel 1 Modelagem ad hoc neste n vel apenas o desenvolvimento tradicional realizado Pr ticas de modelagem s o utilizadas apenas esporadicamente ou nunca N o existem pr ticas definidas para este n vel e N vel 2 MDD Basico este n vel caracterizado pela utiliza o b sica de modelos cobrindo atividades simples do MDD Modelos s o utilizados apenas para guiar a implementa o e documenta o Tipicamente apenas modelos t cnicos s o utilizados incluindo todos os aspectos de um sistema sem distin o entre aspectos de neg cio ou aspectos espec ficos de plataforma 276 Z ENGI Decidir sobre conven es de modelagem consiste na identifica o
332. o de features com detalhes sobre variabilidades mais complexas em partes do dom nio TOLVANEN KELLY 2005 CZARNECKI 2005 Adicionalmente uma DSL pode ser utilizada junto com transforma es para automaticamente gerar artefatos de implementa o que o objetivo final do desenvolvimento orientado a modelos CZARNECKI 2005 O elemento que une estes artefatos a arquitetura do dom nio que deve ser projetada para dar suporte tanto variabilidade baseada em features como variabilidade baseada em DSLs Tamb m deve ter preocupa es sobre a exist ncia al m dos componentes do dom nio de artefatos espec ficos do MDD como DSLs transforma es de software e geradores de c digo Um problema que a maioria das abordagens de engenharia de dom nio existentes n o define como projetar uma arquitetura de software espec fica de dom nio com este objetivo A literatura possui muitos trabalhos que discutem detalhes sobre como produzir uma arquitetura para reutiliza o BASS CLEMENTS KAZMAN 2003 BOSCH 2000 mas estes n o consideram o MDD E aqueles que consideram s o normalmente focados no processo de deriva o autom tica 118 de produtos WEISS et al 2008 VOLTER GROHER 2007 BOTTERWECK O BRIEN THIEL 2007 ARBOLEDA CASALLAS ROYER 2007 TRASK et al 2006 TOLVANEN KELLY 2005 CZARNECKI HELSEN EISENECKER 2004b e n o na tarefa de produzir uma arquitetura de dom nio que adequada para o MDD ou s
333. o do dom nio estiver mais avan ada ou mesmo ap s o dom nio estar em produ o h algum tempo Do Nem toda variabilidade precisa ser inclu da na implementa o de refer ncia para fazer parte de uma DSL Algumas variabilidades podem ser deixadas de fora sendo necess ria a sua implementa o manual por ocorrerem muito raramente ou exigirem muito esfor o para automatiz las Dio Se existirem uma ou mais aplica es do dom nio dispon veis estas podem e devem ser consultadas durante o desenvolvimento da implementa o de refer ncia Pode se inclusive reutilizar trechos de c digo ou o suporte a alguma variabilidade que venha a estar j presente em alguma aplica o Para variabilidades baseadas em DSL mais complexas esta tarefa mais dif cil j que 157 o n mero de combina es de elementos do dom nio literalmente infinito E necess rio mais conhecimento do especialista para se produzir exemplos representativos As seguintes diretrizes podem ajudar Di Tentar explorar o espa o de variabilidade de duas maneiras utilizando aplica es reais para derivar exemplos concretos da variabilidade e tamb m com extremos como escolhas e combina es incomuns dos elementos da DSL Di Procurar popular atributos multivalorados e listas com mais de uma inst ncia caso contr rio pode se n o perceber a exist ncia deste tipo de atributo mais tarde durante a atividade de mapeamento Por exemplo se uma
334. o gerado especifica o dos par metros para as transforma es e geradores de c digo as informa es precisam se definidas e detalhadas somente ap s sua conclus o 7 3 Considera es finais A fase de implementa o do dom nio quando as informa es coletadas sobre o dom nio e modeladas durante a an lise e projeto s o concretizadas em forma de artefatos de implementa o Assim ao final desta atividade tem se um conjunto de artefatos reutiliz veis ou componentes que implementam parte da arquitetura do dom nio linguagens espec ficas para os subdom nios ferramentas que permitem criar modelos para estes subdom nios e transforma es modelo modelo e modelo texto capazes de gerar c digo espec fico para a arquitetura do dom nio O Quadro 12 resume as atividades de implementa o do dom nio O Quadro 13 descreve os produtos de trabalho da fase de implementa o do dom nio 167 Atividades e sub atividades Entradas Sa das ID 1 Caracteriza o da variabilidade dos subdom nios PT 3 Validado Modelagem do dom nio PT 4 Validado Candidatos a subdom nio PT 10 Subdominios caracterizados implementa o de refer ncia ID 3 2 Inspe o de c digo e mapeamento para elementos das DSLs ID 3 3 Refinamento das DSLs ID 3 4 Desenvolvimento das transforma es e geradores de c digo inclus o exclus o de subdom nios PT 9 Avaliado Projeto do dom nio PT 10 Subdominios caracteri
335. o individualmente ajudando na obten o dos atributos de qualidade desejados para a arquitetura Os padr es s o ent o aplicados durante o refinamento dos m dulos Atividade 120 PD 4 de forma a identificar novos m dulos e dar forma arquitetura Por fim uma atividade avalia a arquitetura ou arquiteturas projetadas caso sejam definidas diferentes op es arquiteturais Atividade PD 5 Estas atividades s o detalhadas a seguir Atividade PD 1 Escolha dos m dulos a serem refinados Pap is projetista do dom nio Entradas PT 3 Validado Modelagem do dom nio PT4 Validado Candidatos a subdom nio e PT 5 Hist rico de decis es sobre inclus o exclus o de subdom nios Sa das PT 6 M dulos a serem refinados Descri o o projeto arquitetural desta abordagem baseia se no m todo ADD Attribute Driven Design ou projeto orientado a atributos BASS CLEMENTS KAZMAN 2003 O ADD promove o refinamento sucessivo de m dulos iniciando se com o dom nio todo e realizando divis es at serem obtidos os m dulos que ir o formar a arquitetural final Assim esta primeira atividade consiste na escolha dos m dulos a serem refinados O refinamento pode ocorrer em duas dimens es e Dos pontos comuns para os vari veis neste refinamento inicia se o projeto considerando se apenas os pontos comuns Em seguida a cada itera o acrescenta se um ponto de varia o no projeto e e De m dulos para sub m dul
336. o o Abstract Factory Singleton Factory Method Prototype Strategy Template Method Builder Director Observer Decorator Composite Adapter Bridge Chain of Responsibility e Command GAMMA etal 1995 entre outros podem potencializar o uso das t cnicas para implementa o da variabilidade descritas Finalmente pode se implementar variabilidade utilizando t cnicas de ger ncia de configura o MUTHIG et al 2002 Nesta abordagem variantes alternativas de um mesmo artefato s o inclu das ou exclu das atrav s de mecanismos de controle de vers es selecionando se a vers o que possui a variante desejada por exemplo Esta abordagem utilizada por muitos profissionais mas frequentemente leva a problemas graves quando as varia es s o muito complexas MUTHIG PATZKE 2004 Isto porque em geral dependem de 65 um profundo conhecimento do sistema em diferentes n veis de detalhes por parte do engenheiro de software 3 2 2 Implementa o da variabilidade no desenvolvimento orientado a modelos No desenvolvimento orientado a modelos a gera o de c digo normalmente empregada com o intuito de se implementar a variabilidade do dom nio Utilizando esta t cnica as tarefas repetitivas relacionadas implementa o da variabilidade s o automatizadas e o desenvolvedor pode obter solu es completas atrav s de especifica es em alto n vel normalmente uma DSL oriunda da an lise SCV Se o 3 1 2 Um gera
337. o orientada a modelos G2 Analisar a abordagem orientada a modelos para reutiliza o de software com o objetivo de determinar a sua import ncia em todo o ciclo de vida com respeito aos benef cios obtidos e dificuldades de utiliza o do ponto de vista do pesquisador no contexto de projetos de engenharia de dom nio Q3 Os participantes que utilizaram a abordagem perceberam durante as atividades da abordagem referentes preocupa o com MDD desde o in cio do desenvolvimento fase de an lise algum benef cio para a implementa o dos artefatos do MDD DSLs transforma es e geradores de c digo Q4 Os participantes que utilizaram a abordagem tiveram dificuldades que causaram preju zo ao desenvolvimento em termos de atrasos e curva de aprendizado O objetivo G diz respeito tese de que o MDD oferece meios concretos para que a reutiliza o de conhecimento possa ocorrer em maior grau e de forma mais adequada quando comparada com um processo n o orientado a modelos Assim a quest o Q busca observar este aumento e ou melhora na reutiliza o comparando se dois projetos um desenvolvido sem a abordagem e outro desenvolvido com a abordagem Contudo mesmo que n o seja observado efetivamente um aumento conforme as m tricas especificadas isto n o significa 171 que a abordagem n o favore a mais reutiliza o Existe a possibilidade de os artefatos serem mais reutiliz veis quando desenvolvidos com a abordagem
338. o pode provar que estou certo um nico experimento pode provar que estou errado Com base nesta premissa cient fica comum trabalhar se com a id ia de uma hip tese nula ou seja define se como hip tese algo que o experimentador deseja rejeitar 180 e projeta se um ou mais experimentos que t m como objetivo testar esta hip tese WOHLIN et al 2000 Assim a hip tese nula para esta avalia o pode ser descrita com base nas quest es e m tricas definidas anteriormente Hoa analisando se um mesmo projeto desenvolvido com e sem a abordagem as m tricas de porcentagem de reutiliza o M raz o de reutiliza o M2 porcentagem de reutiliza o n o desejada M3 porcentagem de reutiliza o gerada M4 e raz o entre especifica o e c digo Ms analisadas conjuntamente n o evidenciam nenhum aumento ou melhoria na reutiliza o de software no projeto que utilizou a abordagem Hop os artefatos de software produzidos com a abordagem n o s o mais reutiliz veis do que aqueles produzidos em uma abordagem n o orientada a modelos Mo Instabilidade de m dulo IcomAbordagem gt IsemAbordagem M7 Complexidade Ciclom tica CCcomabordagem CCsemAbordagem Mg Indice de Manutenibilidade IMcomabordagem lt IMsemAbordagem My N mero de Atributos NA gt 41 Mio N mero de Relacionamentos NR gt 9 Hoc os participantes que utilizaram a abordagem n o perceberam com as atividades da abord
339. oc que altamente dependente de iniciativa conhecimento e compet ncia individual deve ser sistem tica Deve se basear em conceitos da engenharia de forma a ser um processo control vel gerenci vel e repet vel ROMBACH 2000 Considerando se uma fam lia de sistemas similares Para alcan ar esta reutiliza o sistem tica al m do foco no processo ENDRES 1993 BAUER 1993 GRISS 1994 1995 JOOS 1994 deve se promover uma mudan a de paradigma do desenvolvimento de sistemas nicos para a preocupa o com uma fam lia de sistemas similares FRAKES ISODA 1994 Dessa forma a reutiliza o ocorre de forma mais ampla aproveitando o potencial de similaridade entre as aplica es EZRAN MORISIO TULLY 2002 MILI MILI MILI 1995 70 Centrada em um dominio e seus subdominios Um dominio compreende um conjunto de aplica es similares que atendem a uma determinada rea de problema do mundo real NEIGHBORS 1980 Desta forma focando se em um dom nio tem se um escopo bem definido para se planejar a reutiliza o O desenvolvimento centrado no dom nio inclui a identifica o das caracter sticas comuns do dom nio a cria o de modelos do dom nio o projeto arquitetural centrado no dom nio e a implementa o de artefatos que sejam reutiliz veis no contexto do dom nio Al m disso um dom nio pode conter subdom nios distintos cada um com maior ou menor potencial de automa o A abordagem busca identifi
340. ode afetar outros Por exemplo a automa o de um determinado subdom nio pode levar a mudan as refinamentos nos requisitos features ou casos de uso para dar suporte a uma nova linguagem de modelagem ou ferramenta Dessa forma outros subdom nios dependentes dos mesmos requisitos features ou casos de uso ser o afetados Para evitar este problema a seguinte restri o pode ser aplicada durante a tomada de decis es somente um subdom nio pode estar em desenvolvimento a cada vez Isto significa que as decis es D4 Ds e Do s o mutuamente exclusivas Se j existir um subdom nio sendo desenvolvido ou testado em um projeto piloto outros n o poder o estar na mesma situa o Isto n o vale para a decis o D3 uma vez que n o h problemas em se investigar um subdom nio junto com o desenvolvimento de outro Podem inclusive existir m ltiplos 112 subdom nios sendo investigados ao mesmo tempo Se uma organiza o considerar esta restri o muito r gida pode optar por ignor la Por m ela deve estar atenta s poss veis sobreposi es ou interfer ncias entre dois subdom nios sendo colocados em produ o ao mesmo tempo Na pr tica em geral esta situa o n o ocorrer com muita frequ ncia j que n o comum a exist ncia de muitos subdom nios sendo automatizados 5 3 Considera es finais Neste cap tulo foi apresentada a fase de an lise de dom nio com atividades para promover a reutiliza o
341. ode facilmente reconhec lo e reutiliz lo Essa a parte vis vel da abstra o O detalhamento e a implementa o das no es sem nticas associadas a cada conceito correspondem parte escondida da abstra o Sele o uma vez que a DSL esteja constru da o desenvolvedor precisa conhecer a sintaxe e a sem ntica por tr s de cada constru o da linguagem A sele o dos artefatos reutiliz veis ent o feita pelo desenvolvedor que escolhe mentalmente os termos e conceitos da linguagem a serem utilizados durante a constru o de um programa ou cria o de um modelo Ele pode tamb m consultar a gram tica ou manual da linguagem para ajud lo a determinar o que precisa utilizar Adapta o a adapta o ocorre normalmente por meio de par metros definidos na pr pria linguagem com os quais o desenvolvedor adiciona detalhes espec ficos da situa o e Integra o por fim a integra o normalmente realizada de forma autom tica por um compilador ou interpretador que ir executar as a es sem nticas associadas aos termos da DSL integrando os elementos sendo reutilizados em um aplicativo execut vel Quando o aplicativo gerado a partir de um compilador DSL pode se tamb m dizer que se trata de um gerador de aplica es assunto da pr xima se o nttp www isis vanderbilt edu projects gme http www eclipse org gmf 263 Programa o generativa Programa o generativa generati
342. odularidade comunicabilidade e est tica entre outros os autores apresentam uma lista sobre quais m tricas podem ser utilizadas para avaliar estes atributos Por exemplo para avaliar a complexidade os autores citam as m tricas de profundidade da rvore de heran a DIT coes o n mero de casos de uso por classe e n mero de classes por caso de uso Nesta tese n o foi feita avalia o de qualidade do software baseado em UML por m algumas das m tricas foram utilizadas nos estudos de caso com o objetivo de avaliar os benef cios da abordagem proposta A iniciativa Modelware tamb m investigou m tricas para o desenvolvimento orientado a modelos MODELWARE 2006c Foram definidas m tricas para diversos aspectos de engenharia incluindo m tricas de qualidade do produto incluindo qualidade dos modelos e demais artefatos m tricas de processo incluindo transforma es e geradores de c digo e m tricas de projeto teis para estimativas e outras tarefas de gerenciamento interessante notar que as m tricas sugeridas para a qualidade da arquitetura s o as mesmas da orienta o a objetos descritas por Chidamber e Kemerer 1994 WMC RFC LCOM CBO entre outras A exemplo do trabalho de Muskens Chaudron e Lange 2004 estas levam identifica o dos mesmos problemas do que quando coletadas diretamente do c digo fonte com a diferen a de que isto ocorre durante o projeto Mascena Almeida e Meira 2005 e Mascena 2007 ap
343. oftware compreende todas as aplica es financeiras A partir dessa defini o uma linguagem espec fica de dom nio uma linguagem qualquer que representa os termos e conceitos do dom nio Por exemplo Java uma linguagem de um dom nio execut vel UML uma linguagem de um dom nio de modelagem e assim por diante Mas atualmente quando se fala em linguagens espec ficas de um dom nio normalmente se est querendo dizer linguagens espec ficas de um dom nio de problema Dessa forma chega se seguinte defini o DEURSEN KLINT VISSER 2000 Uma linguagem espec fica de dom nio uma linguagem de programa o ou uma linguagem de especifica o execut vel que oferece por meio de nota es e abstra es apropriadas poder expressivo focado em e normalmente restrito a um dom nio de um problema particular De acordo com essa defini o uma linguagem do dom nio financeiro tida como uma DSL enquanto Java e UML n o o s o Uma DSL n o necessariamente utilizada com objetivo de gerar um programa execut vel FOWLER 2005 Em muitos casos pode se utilizar uma DSL com fins de configura o por exemplo Um arquivo XML de configura o de acesso a banco pode ser visto como uma especifica o em uma DSL pois ele cont m termos e conceitos associados ao problema de acesso a banco de dados Outro exemplo s o os processadores de texto do tipo IAIEX que usam uma linguagem pr pria com o prop s
344. ogo Jogo nome jogadores Fim jogadores jogador jogador Jogador nome Cor cor cor verde azul branco preto nome a zA z a zA z0 9 212 Dessa forma um novo jogo poderia ser definido por meio dessa linguagem por exemplo Jogo Damas Jogador Ji Cor branco Jogador J2 Cor preto Fim No Draco o analista do dom nio tamb m pode construir transforma es que permitem que os elementos criados pelo analista do sistema sejam automaticamente transformados em dom nios intermedi rios at eventualmente chegar em linguagem execut vel o que acontece quando por exemplo se deseja obter um modelo orientado a objetos deste Jogo para posteriormente implement lo utilizando uma linguagem de programa o orientada a objetos No Draco as transforma es se baseiam nas regras gramaticais das linguagem dos dom nios interpretadas pelo seu pr prio parser Por isso necess rio existir uma gram tica para a linguagem de origem e uma gram tica para a linguagem destino Neste caso seria necess ria uma gram tica para esse modelo orientado a objetos intermedi rio que poderia ser parecida com modelo modelo classe objeto 209 classe classe nome atributo atributo nome tipo tipo String int float Inome nome a zA z a zA z0 9 objeto objeto nome nome
345. ograma organizacional de treinamento com suporte adequado um planejamento do treinamento e o estabelecimento de um comit de treinamento interno A abordagem n o prev atividades para treinamento AP10 Gerenciamento da unidade de reutiliza o inclui principalmente o estabelecimento de um comit de reutiliza o com um l der e suporte e financiamentos providos por uma alta ger ncia comprometida Este comit deve possuir regras e responsabilidades bem definidas ser composto de membros bem treinados e motivados e possuir canais de comunica o com a organiza o A 274 abordagem n o define uma unidade dedicada reutiliza o AP11 Programa de m tricas defini o de pol ticas e objetivos para medi o da reutiliza o em toda organiza o Um plano de medi o de reutiliza o deve ser desenvolvido com mecanismos para coleta an lise e aplica o de dados Planos de a es para melhoria de processo com base nos resultados das medi es tamb m s o importantes A abordagem n o define nenhum tipo de m trica de controle de andamento do processo ou controle de qualidade AP12 Programa de avalia o organizacional envolve a defini o por parte da alta ger ncia de pol ticas de avalia o al m do suporte e integra o do processo de avalia o na cultura organizacional O comit de reutiliza o possivelmente junto com o grupo de controle de q
346. om nios O ciclo principal come a na primeira atividade da an lise de dom nio Atividade AD 1 Planejamento do dom nio e termina na ltima atividade da implementa o do dom nio Atividade ID 5 Documenta o do dom nio Cada itera o neste ciclo principal introduz refinamentos em diferentes artefatos como nos modelos do dom nio modelo de features modelos de casos de uso e de mudan a na arquitetura e seus componentes e nos artefatos 15 AD 3 Identifica o de subdom nios Na AD 4 Valida o e AD 2 Modelagem do o Dominio wn AD 5 Decis o sobre a ae inclus o exclus o de 4D 1 Planejamento do subdominios diretrizes arquiteturais gt PD 1 Escolha dos m dulos a PD 3 Escolha de t ticas serem refinados e padr es arquiteturais do suporte ferramental Figura 9 Sugest o de modelo de processo para utiliza o da abordagem de implementa o Estes refinamentos consistem de melhorias ou corre es percebidas durante o desenvolvimento e evolu o do dom nio Mas a atividade mais not vel do ciclo principal a Atividade AD 5 Decis o sobre inclus o exclus o de subdom nios Conforme ser discutido no Cap tulo 5 a identifica o de subdom nios pautada por uma incerteza que somente pode ser resolvida atrav s de maiores investiga es envolvendo as linguagens transforma es e geradores de c digo para cada subdom nio Assim o ciclo principal gira em tor
347. ons In SPLC S 1 IEEE Computer Society 2006 p 192 202 ISBN 0 7695 2599 7 UHL A Model Driven Architecture is ready for prime time JEEE Software v 20 n 5 p 70 71 2003 VANDOREN E Maintainability Index Technique for Measuring Program Maintainability S l Software Engineering Institute SED 1997 Dispon vel em lt http www sei cmu edu str gt Acesso em 14 jun 2009 VARR D Model transformation by example In NIERSTRASZ O et al Ed MODELS S l Springer 2006 Lecture Notes in Computer Science v 4199 p 410 424 ISBN 3 540 45772 0 VISSER E WebDSL A case study in domain specific language engineering In LAMMEL R VISSER J SARAIVA J Ed Generative and Transformational Techniques in Software Engineering GTTSE 2007 S 1 Springer 2007 Lecture Notes in Computer Science v 5235 p 291 373 ISBN 978 3 540 88642 6 VOLTER M A catalog of patterns for program generation In Eight European Conference on Pattern Languages of Programs EuroPLoP 2003 Irsee Germany S 1 s n 2003 p B6 1 B6 34 VOLTER M MD Best Practices December 2008 Dispon vel em lt http www voelter de gt Acesso em 14 jun 2009 251 VOLTER M BETTIN J Patterns for model driven software development In Ninth European Conference on Pattern Languages of Programs EuroPLoP 2004 Irsee Germany S 1 s n 2004 p D3 1 D3 54 VOLTER M GROHER I Product line implementation usi
348. ontos de depend ncia Szyperski 1999 define uma interface como um conjunto de assinaturas de opera es que podem ser chamadas por uma aplica o De acordo com Heineman e Councill 2001 h dois tipos de interfaces interfaces providas que descrevem as funcionalidades que o componente fornece e as interfaces requeridas que descrevem as funcionalidades das quais o componente depende para funcionar Os quatro conceitos identificados por Krueger 1992 tamb m est o presentes nessa 256 abordagem conforme descritos a seguir Abstra o a abstra o alcan ada por meio do encapsulamento das fun es desempenhadas pelo componente de forma que o desenvolvedor n o tome conhecimento dos detalhes de implementa o Em outras palavras a parte vis vel corresponde interface do componente enquanto que a parte escondida corresponde sua implementa o Para se conseguir essa separa o podem ser utilizados por exemplo os conceitos da orienta o a objetos como heran a e polimorfismo Tamb m podem ser criadas descri es em linguagem natural que permitam ao desenvolvedor identificar as fun es desempenhadas pelo componente sem a necessidade de conhecer sua estrutura interna Sele o para o processo de sele o normalmente os cat logos de componentes disp em de uma estrutura organizada de forma a facilitar a sua navega o Tamb m comum o uso de mecanismos autom ticos de busca que reduzem o tempo nec
349. ontos em aberto que podem ser preenchidos atrav s de vari veis especificadas pelo desenvolvedor Um dos problemas da programa o generativa ocorre quando se deseja modificar os artefatos gerados Por mais gen rico e flex vel que seja o gerador o artefato gerado pode n o corresponder exatamente s necessidades do desenvolvedor Neste caso o desenvolvedor pode modificar o gerador para atender s suas necessidades ou modificar o artefato gerado Modificar o gerador pode ser uma tarefa custosa Normalmente os geradores s o ferramentas espec ficas para um determinado dom nio de problema de forma que introduzir modifica es sem a perda de compatibilidade com esse dom nio exige uma an lise demorada Al m disso deve se realizar essas mudan as de forma gen rica pensando se n o somente no artefato que se deseja modificar mas em todos os artefatos que ser o gerados a partir de ent o Por outro lado modificar o produto do gerador muito mais f cil pois pode se trabalhar diretamente no artefato que se deseja modificar Por m essas mudan as podem se perder caso o artefato seja re gerado Para resolver esse problema normalmente s o utilizadas t cnicas associadas ao conceito de round trip engineering HENRIKSSON LARSSON 2003 ANTKIEWICZ CZARNECKI 2006 HETTEL LAWLEY RAYMOND 2008 Essas t cnicas s o baseadas em engenharia reversa HENRIKSSON LARSSON 2003 e visam abstrair as mudan as realizadas diretamente nos
350. ordo com t ticas e padr es j testados e comprovados No caso de um refinamento da dimens o de divis o m dulo sub m dulo definem se quais novos sub m dulos ir o realizar os pap is do padr o Este refinamento guiado pelo padr o sendo aplicado Por exemplo caso o padr o Abstract Factory seja aplicado em um m dulo ir o surgir novos m dulos que correspondem s diferentes f bricas e produtos concretos O mesmo ocorre no n vel arquitetural Caso seja aplicado o padr o em camadas o refinamento produz novos m dulos um para cada camada por exemplo O resultado uma decomposi o plaus vel guiada por um padr o que tem por objetivo atender s necessidades arquiteturais espec ficas daquele m dulo diretrizes BASS CLEMENTS KAZMAN 2003 Nesta atividade s o tamb m descritas as interfaces dos m dulos rec m criados Al m das informa es requeridas providas para que cada m dulo seja capaz de executar sua responsabilidade s o descritos tamb m os requisitos e fun es que devem ser atendidos por 138 aquele m dulo espec fico considerando se a divis o que foi realizada Por exemplo para satisfazer a um determinado cen rio de variabilidade onde uma feature pode ou n o estar presente feature opcional pode se criar um m dulo que aceita como par metro uma vari vel booleana que indica se a feature est ou n o presente Assim a defini o da interface deste m dulo deve conter uma descri o des
351. orte global variabilidade do dom nio principalmente com as pr ticas de controle e monitoramento do processo de reutiliza o APS integra o com o ciclo de vida do software AP6 an lise e projeto do dom nio AP7 e AP8 Tamb m neste n vel introduz se a preocupa o com a rea de qualidade incluindo o treinamento em reutiliza o AP9 gerenciamento de uma unidade de reutiliza o AP10 programas de m tricas e de avalia o organizacional APII e AP12 e avalia o da qualidade dos artefatos AP13 tamb m neste n vel que se encontram as pr ticas ligadas engenharia de aplica es AP14 foco do desenvolvimento com reutiliza o e N vel 4 Sistem tico este o n vel mais avan ado que uma organiza o pode chegar em termos de reutiliza o de software Neste n vel o processo est em constante otimiza o AP15 de acordo com resultados de projetos anteriores Tamb m aqui a qualidade dos artefatos reutiliz veis sujeita a um processo mais rigoroso de controle de qualidade AP16 Outras pr ticas interessantes deste nivel 4 incluem a tentativa de se prever e suprir necessidades futuras em termos de artefatos reutiliz veis AP17 e uma an lise de mercado para se avaliar as quest es de investimento em reutiliza o AP18 Este modelo busca identificar as pr ticas essenciais sem entrar em detalhes sobre como as mesmas s o realizadas O modelo tamb m n o define quais pr ticas s o obrigat
352. os neste refinamento inicia se dividindo se o dom nio todo em m dulos e em seguida os m dulos s o subdivididos sucessivamente Estas dimens es normalmente s o ortogonais ou seja um m dulo pode incluir diversos pontos vari veis Da mesma forma um ponto vari vel pode incluir diversos m dulos Portanto recomenda se realizar apenas um desses tipos de refinamento a cada itera o N o existe uma ordem espec fica ou seja pode se iniciar com um refinamento de m dulo para sub m dulo em seguida acrescentar um ponto vari vel depois novamente refinar um m dulo Por m sugere se iniciar com uma primeira divis o do dom nio em m dulos o que permite uma vis o geral da arquitetura desejada Ap s uma primeira divis o o projetista do dom nio avalia a arquitetura existente at o momento identifica se existem m dulos que ainda precisam ser refinados e os lista Para cada um destes executa as atividades seguintes refinando o m dulo novamente 121 O refinamento segue at o projetista decidir que n o necess rio acrescentar mais detalhes A arquitetura deve capturar apenas as informa es mais importantes do projeto e portanto n o s o necess rios muitos detalhes Bass Clements e Kazman 2003 ap s anos de experi ncia em projetos envolvendo projeto arquitetural observaram que tr s n veis de divis o s o normalmente suficientes pois permitem detalhar de forma satisfat ria as informa es essenciais pa
353. os com a combina o de t cnicas do desenvolvimento orientado a modelos e da reutiliza o de software Os resultados mostram que a abordagem pode trazer diferentes benef cios para organiza es de software incluindo aumento da quantidade e qualidade da reutiliza o e reduzindo a complexidade de desenvolvimento e configura o de produtos Palavras chave Reutiliza o de software Desenvolvimento Orientado a Modelos Engenharia de Dom nio Linhas de Produtos de Software Linguagens Espec ficas de Dom nio Programa o 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 difficult 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 final product through modeling and code gene
354. os produtos do dom nio muitas vezes vendendo os mesmos de forma integrada O gerenciamento da variabilidade nesta linha realizado com a ajuda de alguns componentes reutiliz veis mas principalmente utilizando t cnicas de gerenciamento de configura o Assim cada sistema vendido produz diferentes vers es que implementam as diferentes variabilidades do dom nio A reutiliza o 185 Dom nio Aplica es distribu das baseadas em computa o em nuvem Local Microsoft Research Redmond WA USA Participantes 2 incluindo o autor Tempo total 3 meses dedica o integral N mero de DSLs 3 dados conectividade e opera es N mero de artefatos de gera o transforma es e geradores ao Tamanho total LOC 2847 artefatos de gera o Tamanho total LOC 12127 implementa o de refer ncia N mero de features do dom nio Microsoft Visual Studio 2008 Microsoft SQL Server CH NET Tecnologias de implementa o NET Remoting Microsoft Volta PNRP Peer Name Resolution Protocol DBML DataBase Modeling Language Microsoft LINQ to SQL Microsoft Visual Studio 2008 Tecnologias MDD Microsoft Text Templates GME Generic Modeling Environment Quadro 15 Dados sobre o estudo envolvendo o dominio de aplica es distribu das baseadas em computa o em nuvem ocorre recuperando se uma determinada vers o que seja pr xima dos requisitos do cliente e
355. ovamente BASILI BRIAND MELO 1996 2 No entanto a id ia de reutilizar ao inv s de construir ainda mais antiga remetendo s origens da pr pria engenharia de software Em 1968 na confer ncia da OTAN que considerada como o ber o da engenharia de software McIlroy 1968 apresentava id ias referentes reutiliza o de componentes de software produzidos em massa e os poss veis benef cios que tal abordagem traria chamada crise do software Desde ent o a pesquisa na rea evoluiu produzindo uma diversidade de trabalhos envolvendo reutiliza o de software Os esfor os que podem ser encontrados na literatura incluem as id ias de engenharia de dom nio NEIGHBORS 1980 STARS 1993 SIMOS etal 1996 JACOBSON GRISS JONSSON 1997 GRISS FAVARO D ALESSANDRO 1998 KANG et al 1998 desenvolvimento baseado em componentes DBC SZYPERSKI 1999 SAMETINGER 1997 e mais recentemente as id ias de linhas de produto CLEMENTS NORTHROP 2002 Existe tamb m uma vasta literatura na rea de reposit rios e busca de artefatos LUCR DIO ALMEIDA PRADO 2004 Fora da academia diferentes relatos sobre fatores e pr ticas de sucesso podem ser encontrados em empresas como Motorola JOOS 1994 e Hewlett Packard GRISS 1995 Por m mesmo ap s d cadas de pesquisa ainda n o poss vel afirmar que existe uma abordagem voltada para reutiliza o de software que seja amplamente utilizada e que permita
356. partamentos J Categorias 1 or 1 Texto Produtos P gina imagens links Todooste I J Departamentos Meuspedidos J J farinho deconpra C 4 pondo 11 Aplica o http forum clubedohardware com br Descri o F rum para troca de experi ncias com hardware exto Links cadastro d To S simples oo To Avan ada TT Administra o Cadastrodef runs do Quadro 1 Identifica o inicial das features de duas aplica es do dom nio de autoria de conte do para Web 92 Aplica es Features P gina Busca Carrinho Administra o Total Parcial Cadastros Modera o http www americanas com br http forum clubedohardware com br http smeira blog terra com br Quadro 2 Compila o das features de quatro aplica es do dominio de autoria de conte do para Web http www submarino com br O mapa de aplica es e a lista de features que extra da diretamente do mapa de aplica es servem de guia para a pr xima atividade de modelagem do dom nio Atividade AD 2 Modelagem do dom nio Pap is analista do dom nio especialista do dom nio Entradas Informa es sobre sistemas do dom nio Conhecimento do especialista Informa es sobre stakeholders PT 1 lnicial Planejamento do dom nio PT 2 Inicial Mapa de aplica es Sa das PT 3 Inicial Modelagem do dom nio Descri o esta atividade cuida da cria o de modelos do dom nio agrupando
357. pesquisadores NEIGHBORS 1980 KRUEGER 1992 GRISS 1995 FRAKES ISODA 1994 JACOBSON GRISS JONSSON 1997 desde as primeiras discuss es sobre reutiliza o de software Diversos pesquisadores entre eles Czarnecki et al 2005 concordam que MDD e reutiliza o s o esfor os complementares As pr prias origens destas duas linhas de pesquisa est o interligadas conforme discutido no Cap tulo 9 A presente tese buscou investigar de forma mais aprofundada esta id ia defende se que a combina o entre o desenvolvimento orientado a modelos e reutiliza o de software em um processo sistem tico exige o gerenciamento dos m ltiplos subdom nios que podem existir em um dom nio de modo a oferecer um grau de automa o adequado Para isso a preocupa o com o MDD deve estar presente em todas as etapas do processo incluindo a an lise o projeto e a implementa o do dom nio A avalia o desta tese consistiu na realiza o de estudos emp ricos envolvendo a aplica o da abordagem em projetos de engenharia de dom nio com o objetivo de fornecer evid ncias ou ind cios sobre sua validade E importante ressaltar que a avalia o realizada tem car ter mais explorat rio com alguns pontos que ainda precisam ser melhorados para que os resultados possam ser mais confi veis conforme discutido na Se o 8 6 Mas de qualquer forma puderam ser extra das algumas conclus es como apresentado no final deste cap tulo A se
358. piar um trecho de c digo de um local para outro at as abordagens comumente descritas na literatura como o desenvolvimento baseado em componentes SAMETINGER 1997 SZYPERSKI 1999 linguagens espec ficas de dom nio DEURSEN KLINT VISSER 2000 programa o generativa CZARNECKI EISENECKER 2000 frameworks JOHNSON 1997b padr es BUSCHMANN et al 1996 e reengenharia de software JACOBSON LINDSTROM 1991 2 1 2 O processo de reutiliza o de software A simples ado o de uma ferramenta ou t cnica n o suficiente para que os benef cios da reutiliza o sejam alcan ados em sua m xima extens o sendo necess rios outros fatores como um bom gerenciamento organizacional e infraestrutura voltados reutiliza o RINE SONNEMANN 1998 Al m desses conforme j discutido no Cap tulo 1 o foco no processo de extrema import ncia para uma organiza o em busca da reutiliza o de software Ainda n o existe um consenso sobre quais atividades s o necess rias para um processo sistem tico de reutiliza o Existem diversas abordagens distintas cada uma com um foco lO ap ndice A apresenta uma an lise mais aprofundada destas abordagens 33 maior em determinada parte do processo procurando solucionar parte do problema Em termos gerais um processo de reutiliza o de software deve definir ao menos duas atividades essenciais o desenvolvimento para reutiliza o que consiste no desenvolvimento dos a
359. plo da abordagem desta tese Por m os autores passam diretamente da representa o da variabilidade deriva o de produtos sem entrar em detalhes sobre por exemplo a constru o de uma arquitetura adequada para este cen rio como o caso desta tese O mesmo acontece com outros trabalhos encontrados na literatura Muitas abordagens que combinam o MDD com engenharia de dom nio ou linhas de produtos de software possuem foco maior no est gio de deriva o autom tica de produtos dando pouca ou nenhuma nfase ao projeto do dom nio de acordo com os princ pios do MDD Exemplos destas abordagens incluem WEISS et al 2008 VOLTER GROHER 2007 BOTTERWECK O BRIEN THIEL 2007 ARBOLEDA CASALLAS ROYER 2007 TRASK et al 2006 TOLVANEN KELLY 2005 CZARNECKI HELSEN EISENECKER 2004b 2 Uma das exce es o m todo Kobra ANASTASOPOULOS ATKINSON MUTHIG 2002 Originalmente projetado para desenvolvimento de sistemas individuais o Kobra se integra bem a um m todo voltado para linhas de produtos como o Pulse DSSA ANASTASOPOULOS ATKINSON MUTHIG 2002 O Kobra possui atividades espec ficas para o projeto arquitetural orientado a modelos Os autores argumentam que dessa forma poss vel obter independ ncia de plataforma pois o Kobra se baseia em modelos UML para especifica o realiza o e implementa o de componentes de software no contexto de uma linha de produtos Assim como a abordagem desta tese o
360. podem trabalhar em conjunto 47 O MOF consiste em um padr o orientado a objetos que permite a defini o de classes com atributos e relacionamentos sendo bastante semelhante ao diagrama de classes da UML Tamb m define uma interface padr o de acesso aos dados dos modelos oferecendo m todos para manipula o dos dados e dos metadados Al m dessa interface padr o que nica para qualquer metamodelo o MOF define regras para a cria o de interfaces espec ficas para cada metamodelo Por exemplo para cada atributo monovalorado de uma classe do metamodelo deve existir um m todo do tipo set e um m todo do tipo get Essas regras se estendem para nomes de classes relacionamentos e assim por diante Atualmente o MOF encontra se na vers o 2 0 OMG 2006b Assim como a UML um padr o elaborado e mantido por diversas empresas associadas ao OMG A MDA tamb m define o XMI XML Metadata Interchange OMG 2006c um formato para representar modelos em XML Este formato define uma estrutura de documento que considera a rela o entre os dados e seus correspondentes metadados Assim poss vel para uma ferramenta ao interpretar este formato identificar quais os metadados que descrevem os dados sendo lidos Diferentes metan veis podem ser representados desde o MO at o M3 Figura 4 Por exemplo poss vel representar modelos UML com refer ncia para o metamodelo UML ou modelos E R com refer ncia para o metamodelo E R
361. por Fenton e Pfleeger 1998 que prop em a utiliza o do seguinte c lculo para an lise das extremidades Linferior q q3 q1 1 5 Lsuperior q3 43 q 1 5 onde q e q3 s o o primeiro 25 e terceiro 75 quartis respectivamente https net2java dev java net 188 Dado um conjunto de dados seguindo uma distribui o normal teoricamente n o deveriam ser encontrados elementos abaixo do limite inferior e acima do limite superior Caso existam estes devem ser analisados e deve se decidir se ser o inclu dos ou exclu dos da an lise Por exemplo quando o elemento fora dos limites se tratar de c digo fonte deve se analisar se ele segue os mesmos padr es e formatos utilizados na maioria do c digo Se este elemento possuir muitas linhas de coment rio ou se for um c digo reutilizado de outro projeto sem uma reformata o ele pode n o representar a realidade do c digo produzido e deve ser exclu do da an lise Por outro lado podem existir elementos de c digo extremamente complexos ou extremamente simples devido natureza do pr prio dom nio Nestes casos o elemento deve ser mantido Para cada estudo foram analisados somente os artefatos efetivamente utilizados pelo desenvolvedor Ou seja artefatos de c digo completamente gerados e que n o precisam ser modificados ou manipulados pelo desenvolvedor n o foram inclu dos nas m tricas Por m em alguns gr ficos o c digo gerado foi tamb
362. possuem grande correla o com algumas atividades da abordagem definida nesta tese Uma compara o mais detalhada com o modelo de maturidade encontra se no Ap ndice B 213 Weis Ulbrich e Geihs 2003 apresentam uma proposta de um mecanismo para modelagem denominado Kase e uma linguagem para transforma o de modelos denominada Kafka Eles apresentam os requisitos a serem atendidos por transforma es no desenvolvimento orientado a modelos O primeiro deles que as transforma es devem ser autom ticas pois de outra forma os desenvolvedores considerariam a cria o de modelos uma tarefa improdutiva Outro requisito que as transforma es n o podem ser universais e gen ricas mas sim espec ficas para cada caso podendo ser adaptadas facilmente e reutilizadas Finalmente os autores ressaltam a necessidade de se utilizar linguagens visuais para a constru o das transforma es uma vez que o uso de linguagens textuais tais como linguagens de programa o e linguagens de transforma o baseadas em XML possuem uma dist ncia conceitual em rela o aos modelos dificultando a tarefa de constru o de transformadores As transforma es representadas na linguagem Kafka s o baseadas em regras de mapeamento facilitando a chamada engenharia ida e volta ou seja modelo para c digo e c digo para modelo A abordagem desta tese tamb m busca automatizar completamente as transforma es de modo que n o necess r
363. pplied Computing SAC 2007 S 1 ACM 2007 p 985 992 ISBN 1 59593 480 4 CLEMENTS P KAZMAN R KLEIN M Evaluating Software Architectures Methods and Case Studies S 1 Addison Wesley 2004 CLEMENTS P NORTHROP L Software Product Lines Practices and Patterns S 1 Addison Wesley 2002 238 COOK S et al Domain Specific Development with Visual Studio DSL Tools SJ Addison Wesley Professional 2007 COPLIEN J HOFFMAN D WEISS D Commonality and variability in software engineering IEEE Software v 15 n 6 p 37 45 1998 COPLIEN J O Multi Paradigm Design Tese Doutorado Vrije Universiteit Brussel 2000 COPLIEN J O A Pattern Definition http hillside net patterns definition html S 1 hillside net 2006 CURRY W et al Empirical analysis of the correlation between amount of reuse metrics in the c programming language In SSR 99 Proceedings of the 1999 symposium on Software reusability New York NY USA ACM 1999 p 135 140 ISBN 1 58113 101 1 CZARNECKI K Overview of generative software development In BANATRE J P et al Ed Unconventional Programming Paradigms International Workshop UPP 2004 Le Mont Saint Michel France September 15 17 2004 Revised Selected and Invited Papers S l Springer 2005 Lecture Notes in Computer Science v 3566 p 326 341 ISBN 3 540 27884 2 CZARNECKI K et al Model driven software product lines In 20th Annual ACM SIG
364. programas baseada em exemplos Neste sistema o programador realiza um exemplo de mudan a manualmente que ent o submetido ao sistema e posteriormente generalizado para outros contextos tornando se uma transforma o reutiliz vel O sistema baseia se no monitoramento do ambiente de programa o para detectar automaticamente as modifica es feitas pelo desenvolvedor em algum artefato de c digo Estas s o ent o registradas como opera es de 220 mudan as sendo posteriormente convertidas em entidades de primeira classe que descrevem como os elementos da AST Abstract Syntax Tree ou rvore de Sintaxe Abstrata de um programa como as classes atributos m todos e outras constru es da linguagem s o modificados pelo desenvolvedor No passo de generaliza o o sistema tenta identificar automaticamente o papel de cada mudan a na transforma o Por exemplo se uma mudan a modifica um peda o de c digo envolvendo o com comandos try catch o trecho de c digo a ser envolvido um par metro da transforma o enquanto os comandos try catch s o constantes a serem inseridas O desenvolvedor da transforma o pode ent o refinar esta generaliza o em um editor personalizado renomeando par metros especificando detalhes n o detectados pelo sistema autom tico entre outras tarefas O trabalho de Robbes e Lanza focado principalmente na transforma o de programas e refactorings Por m a abordagem poderia ser aplic
365. que avaliaram se os benef cios almejados foram efetivamente percebidos e observados Decidiu se por uma entrevista ao inv s de um question rio pois os estudos n o envolveram um n mero muito grande de participantes e desta forma houve mais flexibilidade na observa o dos resultados da aplica o da abordagem A entrevista consistiu das perguntas a seguir com respostas em aberto O modelo de features ajudou na defini o das linguagens espec ficas de dom nio transforma es e geradores de c digo e A descri o da variabilidade em cen rios casos de mudan a facilitou a defini o das linguagens espec ficas de dom nio transforma es e geradores de c digo e A identifica o de candidatos a subdom nio facilitou a identifica o das reas do dominio a serem automatizadas e A identifica o de candidatos a subdom nio facilitou a defini o das linguagens espec ficas de dom nio transforma es e geradores de c digo e O processo investigativo baseado em decis es para inclus o exclus o de subdom nios foi utilizado Se sim ele facilitou o processo de desenvolvimento dos artefatos do MDD e O uso das diretrizes e padr es arquiteturais espec ficos para reutiliza o e MDD facilitou o desenvolvimento dos artefatos do MDD e da arquitetura do dom nio 179 A etapa de avalia o arquitetural ajudou a identificar falhas antes de a implementa o ser iniciada As diretrizes de implementa
366. r parallel problem decomposition during requirements engineering In 8th International Workshop on Software Specification and Design Germany s n 1996 p 159 163 MARTIN R OO Design Quality Metrics An Analysis of Dependencies 1994 Disponivel em lt http www objectmentor com resources articles oodmetre pdf gt Acesso em 14 jun 2009 MASCENA J C C P C R U I S E Component Reuse In Software Engineering In S 1 CLE S A R e books 2007 cap 6 Software Reuse Metrics p 125 136 MASCENA J C C P ALMEIDA E S d MEIRA S R d L A comparative study on software reuse metrics and economic models from a traceability perspective In JEEE International Conference on Information Reuse and Integration IRI Las Vegas Nevada USA TEEE CS Press 2005 p 72 77 245 MATOS JR P O A Analysis of techniques for implementing software product lines variabilities Disserta o M Sc Dissertation Universidade Federal de Pernambuco Centro de Inform tica Recife PE Brazil August 2008 MCCABE T J A complexity measure IEEE Transactions on Software Engineering v 2 n 4 p 308 320 1976 MCILROY M D Mass produced software components In NATO Software Engineering Conference S 1 s n 1968 p 138 155 MEI H ZHANG W GU F A feature oriented approach to modeling and reusing requirements of software product lines In 27th IEEE International Computer Software and Applications Conferenc
367. r utilizado que deriva da camada fina de dados chamado camada de dados das features e consiste numa especializa o do padr o anterior Normalmente o modelo de features o ponto central de informa es para os geradores mesmo aqueles exclusivamente dedicados variabilidade baseada em DSLs Neste padr o que uma inst ncia do padr o camada fina de dados prop e se o uso de uma camada de dados que armazena todas as informa es relacionadas s features Esta camada de dados deve ser projetada para ser acess vel a todos os geradores permitindo que consultem informa es das features enquanto geram c digo Se existir uma ferramenta dedicada atividade de modelagem de features esta camada pode ser utilizada para fazer com que os geradores n o dependam desta ferramenta em particular 134 Sub atividade PD 3 3 Padr es de integra o entre subdom nios Estes padr es buscam promover uma boa integra o entre c digo gerado e n o gerado particularmente nas reas que envolvem os limites de um subdom nio Os padr es descritos nesta se o dividem se em quatro categorias dependendo da depend ncia entre c digo gerado e n o gerado conforme descrito a seguir C digo gerado depende de c digo n o gerado este o tipo mais simples de intera o e consiste em fazer o gerador produzir c digo que usa c digo existente n o gerado como um framework ou biblioteca O padr o Facade GAMMA et al 1995 pode ser
368. ra o subdom nio de autoria por exemplo um formul rio que aponta para um tipo espec fico de documento Assim a arquitetura precisa estar preparada n o s para a exist ncia de m ltiplos subdom nios e possivelmente m ltiplas DSLs WARMER KLEPPE 2006 HESSELLUND CZARNECKI WASOWSKI 2007 mas tamb m para a intera o entre eles Pode ser necess rio por exemplo desenvolver um nico metamodelo para os m ltiplos subdom nios e ent o desenvolver diferentes sintaxes concretas de forma que estes subdom nios estejam integrados mas ainda assim possuir diferentes vis es Essa quest o de integra o de dom nios um assunto ainda n o dominado Nesta atividade estas interdepend ncias entre subdom nios s o explicitadas pois podem ter impacto nas decis es de projeto Para isso cada elemento em cada subdom nio deve ser inspecionado e cada elemento que depende de um elemento em um subdom nio diferente deve ser documentado As restri es de inclus o e exclus o m tua entre as features indicam algumas destas depend ncias por m outras podem se tornar aparentes somente ap s a implementa o estar avan ada Por este motivo esta tese defende a id ia de que a identifica o dos subdom nios deve acontecer de forma evolutiva e investigativa desde a an lise Atividade AD 5 A cada itera o os subdom nios devem evoluir com o avan o da implementa o aumentando a confian a em sua validade e identificando nov
369. ra que o processo possa seguir adiante importante lembrar que nesta abordagem j existe uma primeira divis o do dom nio em subdom nios feita na atividade de an lise Por m esta uma divis o conceitual que pode n o coincidir com a divis o em m dulos que realizada nesta fase de projeto BUSCHMANN et al 1996 Enquanto a primeira tem como objetivo identificar partes do dom nio onde a automa o poss vel separando conjuntos de features relacionadas aqui a divis o tem como objetivo implementar padr es arquiteturais que ir o atender a requisitos para o dom nio as diretrizes arquiteturais Atividade PD 2 Sele o das diretrizes arquiteturais Pap is projetista do dom nio especialista do dom nio demais stakeholders Entradas PT 6 M dulos a serem refinados Sa das PT 7 Diretrizes arquiteturais Descri o as diretrizes arquiteturais s o uma combina o de requisitos funcionais e de qualidade que d o forma arquitetura de um dom nio ou m dulo em particular BASS CLEMENTS KAZMAN 2003 As diretrizes s o normalmente representadas atrav s de cen rios que testam a capacidade da arquitetura em satisfazer um ou mais atributos de qualidade Para identificar as diretrizes os objetivos de neg cio mais importantes s o identificados e transformados em cen rios ou casos de uso Desta lista aqueles com maior impacto na arquitetura s o escolhidos Estas s o as diretrizes arquiteturais BA
370. ra que o engenheiro de software possa lidar com eles 233 Esta abordagem um passo inicial em dire o a um framework de processo completo para a utiliza o efetiva do MDD como facilitador da reutiliza o Trata se de um ponto central ao redor do qual necess rio definir atividades de suporte e de ger ncia al m de outras pr ticas de engenharia n o cobertas pela abordagem Esta disserta o apresenta os resultados de uma pesquisa aplicada que busca unificar diferentes t cnicas relacionadas reutiliza o de software e MDD de uma forma original oferecendo um suporte combinado que melhor do que a aplica o das t cnicas de forma isolada Os resultados foram interessantes e esclarecedores principalmente em termos da utiliza o pr tica em ambiente industrial Comparando se com o estado da arte nota se que as contribui es deste tipo de pesquisa s o relevantes tendo em vista a escassez de trabalhos que visam somente solidificar e formalizar contribui es que ainda apresentam falhas e falta de detalhes sobre as diversas formas de desenvolvimento produtivo de software 235 Refer ncias ALFEREZ M et al A model driven approach for software product lines requirements engineering In SEKE S 1 Knowledge Systems Institute Graduate School 2008 p 779 784 ISBN 1 891706 22 5 ALLILAIRE F et al Global model management in Eclipse GMT AM3 In Eclipse Technology eXchange Workshop eTX at the ECOOP 200
371. ra usu rio e at mesmo planos e estrat gias entre outros Algumas motiva es para se reutilizar software s o a redu o de tempo e esfor o no desenvolvimento Pode se tamb m aumentar a qualidade do software reutilizando se artefatos com qualidade assegurada o que tamb m acaba por reduzir tempo e esfor os na manuten o KRUEGER 1992 LIM 1994 Mas a principal motiva o que reutiliza o mais do que apenas uma vantagem que pode ser completamente descartada Muitas organiza es de desenvolvimento de software mesmo aquelas que alegam n o ter preocupa o expl cita com reutiliza o s o extremamente dependentes da efici ncia com que geram assimilam e reutilizam seu conhecimento DESOUZA AWAZU TIWANA 2006 Estas afirma es levam seguinte discuss o normalmente associada reutiliza o de software sendo relativamente antiga com pelo menos quatro d cadas por que a reutiliza o ainda n o uma pr tica consagrada disseminada e bem sucedida dentro da Engenharia de Software Indo al m sendo uma pr tica considerada vital para o sucesso DESOUZA AWAZU TIWANA 2006 como as organiza es v m sobrevivendo sem empreg la Na verdade essa discuss o ignora um aspecto importante a reutiliza o 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 u
372. radores de c digo que produzem aplica es completas segundo as especifica es dos 183 modelos O Quadro 14 mostra um resumo dos dados relevantes sobre este estudo Dom nio Autoria de conte do para Web Local ICMC USP S o Carlos SP Participantes 1 autor Tempo total 3 meses dedica o integral N mero de DSLs 4 persist ncia navega o relat rios e features N mero de artefatos de gera o transforma es e geradores 28 Tamanho total LOC 1610 artefatos de gera o Tamanho total LOC cs 5941 implementa o de refer ncia N mero de features 15 do dom nio Apache Tomcat MySQL Java Tecnologias de implementa o JSP JSTL Servlets XML SQL Eclipse vers o Ganymede WebTools plug in Eclipse vers o Ganymede EMF Eclipse Modeling Framework Tecnologias MDD GMF Graphical Modeling Framework JET Java Emitter Templates openArchitectureWare Quadro 14 Dados sobre o estudo envolvendo o dom nio de autoria de conte do para Web 8 2 2 Aplica es distribu das baseadas em computa o em nuvem O segundo estudo foi realizado em ambiente industrial envolvendo o dom nio de aplica es distribu das baseadas em computa o em nuvem LUCR DIO JACKSON SCHULTE 2008 As principais caracter sticas deste dom nio s o o alto grau de incerteza sobre a topologia da aplica o a heterogeneidade dos ambientes e infraestrutura
373. rama o como Java Cf e PHP Isto refor a a validade dos resultados e a sua independ ncia com rela o s tecnologias envolvidas 207 9 Trabalhos relacionados As id ias do MDD est o fortemente ligadas com o uso de ferramentas de aux lio ao desenvolvimento de software Por esse motivo n o estranho o fato de que a ind stria esteja voltando seus olhos para esse paradigma uma vez que fabricantes de ferramentas v em um forte ind cio de vantagem competitiva caso consigam oferecer a seus clientes uma maneira de alcan ar os benef cios de qualidade e produtividade associados a esse paradigma de desenvolvimento Na Se o 2 2 2 foram apresentadas as principais abordagens da ind stria para o MDD Mas com a academia n o diferente sempre existindo o interesse cient fico nessa rea com trabalhos que discutem os conceitos te ricos e a viabilidade dessa abordagem 9 1 Abordagens orientadas a modelos para reutiliza o de software Um dos primeiros trabalhos a propor a uma abordagem similar ao que se busca hoje com MDD data de 1980 NEIGHBORS 1980 Pioneiro na rea de reutiliza o de software James Neighbors com sua abordagem Draco para desenvolvimento de software tamb m investigou a viabilidade de se utilizar modelos como a base para a constru o de aplicativos Nas palavras de Neighbors a abordagem Draco se baseia na sensa o frustrante de que a maior parte do sistema que voc est construindo atualm
374. ration 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 benefits that can be achieved with the combination of model driven development and software reuse techniques The results showed that the approach can bring different benefits to software organizations such as software reuse quantity and quality improvements and complexity reduction in product development and configuration tasks Keywords Software Reuse Model Driven Development
375. re o estudo envolvendo o dom nio de eventos cient ficos 8 3 Coleta dos dados A coleta das m tricas foi realizada com o aux lio de diferentes ferramentas Para os projetos baseados em c digo Java foram utilizadas as ferramentas Eclipse Metrics Instabilidade e Complexidade Ciclom tica e JHawk ndice de Manutenibilidade Estas ferramentas trabalham com c digo fonte em Java Para arquivos JSP foi utilizado o c digo Java de seus Servlets correspondentes Os templates do JET s o convertidos em Java e portanto estas ferramentas tamb m puderam ser utilizadas 3http metrics sourceforge net http www virtualmachinery com jhawkprod htm 187 Para c digo C n o foi encontrada nenhuma ferramenta dispon vel capaz de calcular estas m tricas Por m foi utilizada a ferramenta Net2Java um plug in do NetBeans capaz de converter c digo escrito em CH para Java Como s o linguagens bastante similares a convers o realizada de forma quase direta Al m disso n o foi necess rio executar o c digo convertido As m tricas s o estruturais e se baseiam em depend ncia entre classes operadores operandos estruturas de la os e condi es e outros elementos do c digo que s o comuns a ambas linguagens Assim o nico trabalho foi corrigir alguns erros da convers o visando deixar o c digo Java compil vel requisito das ferramentas Eclipse Metrics e JHawk e estas foram utilizadas para extrair as m tricas O c
376. regadas Por exemplo em um gerenciador de interfaces visuais como aqueles presentes em IDEs como NetBeans ou Visual Studio as interfaces s o especificadas de forma visual em uma 62 linguagem espec fica para o dom nio GUI Graphical User Interface ou Interface Gr fica com o Usu rio Nesta linguagem especifica se os atributos de cada componente como posi o e tamanho assim como os eventos e a es associados Como resultado gerado c digo que traduz a sem ntica da linguagem posi o tamanho atributos eventos de cada componente em uma GPL General Purpose Language ou Linguagem de Prop sito Geral como por exemplo UML Java C C VB entre outras A defini o da linguagem normalmente requer um metamodelo que seja capaz de capturar os pontos comuns e vari veis do dom nio e n o a mais comumente utilizada BNF Um metamodelo uma estrutura similar a um diagrama de classes e possui elementos como classes atributos associa es e agrega es Seja qual for a representa o visual final diagrama visual ou representa o textual a exist ncia de um metamodelo como esquema conceitual em geral indica que uma maior quantidade de inst ncias pode ser expressa Isto ocorre pelo simples fato de que regras gramaticais BNF descrevem uma rvore enquanto um metamodelo descreve um grafo e rvores s o subconjuntos de grafos KLEPPE 2007 Com rela o sintaxe concreta ambas as possibilidades linguagens visuai
377. representam pontos de varia o que podem ser independemente configur veis Cada FBU potencialmente um candidato a subdom nio por m esta n o necessariamente a melhor escolha Pode se por exemplo unir duas ou mais FBUs em um nico subdom nio incluir ou remover features individualmente ou mesmo sub dividir uma FBU em mais de um subdom nio Estas escolhas por m devem ser feitas somente mais adiante no processo quando 102 mais maturidade sobre os subdom nios adquirida Para cada candidato a subdom nio as features correspondentes s o identificadas Isto pode ser realizado em uma matriz relacionando cada feature ao seu subdom nio correspondente Opcionalmente pode ser produzida uma representa o gr fica do subdom nio em um diagrama que cont m somente as features a ele pertencentes A Figura 12 mostra quatro candidatos a subdom nio obtidos atrav s da an lise de FBUs do dom nio de aplica es de autoria de conte do para Web Dom nio autoria web Administra o Conte do Modera o Conte do gt de usu rio TA Seeasaes tipo de busca eee tes tipodebusca te Busca e Busca avan ada kT EEEE EE TTET PER To l io 4 Autoria rs DR E is e lt a K Sign Sum if o Tpede E tipo de p gina pi Pe so o tipo de p gina una eenenneeenenaneentene i em
378. resentam uma an lise sobre m tricas relacionadas reutiliza o de software incluindo tr s categorias m tricas orientadas a fatores econ micos estruturais e de reposit rio Entre estas as m tricas estruturais s o a base para analisar de forma mais aprofundada o que est sendo reutilizado S o elas porcentagem de reutiliza o RP Reuse Percent POULIN CARUSO 1993 n vel de reutiliza o RL Reuse Level FRAKES TERRY 1994 frequ ncia de reutiliza o RF Reuse Frequency FRAKES TERRY 1994 tamanho e frequ ncia de reutiliza o RSF Reuse Size and Frequency 226 DEVANBU et al 1996 raz o de reutiliza o RR Reuse Ratio DEVANBU et al 1996 e densidade de reutiliza o RD Reuse Density CURRY etal 1999 Estas s o m tricas simples por m n o podem ser consideradas como indicadores isolados uma vez que possuem problemas por n o considerar a natureza dos artefatos reutiliz veis e nem a maneira com que estes s o reutilizados penalizando por exemplo grandes sistemas e sistemas pouco modularizados monol ticos Por este motivo existe outra vertente que defende a id ia de que melhor tentar medir a reutiliza o atrav s da avalia o de atributos de qualidade que medem o qu o reutiliz vel um determinado artefato de software Neste sentido s o sugeridas m tricas indiretas como manutenibilidade e complexidade POULIN 1994 Estas j foram utilizadas com sucesso em outros
379. reutiliza o al m de nfase em atividades espec ficas an lise projeto ou implementa o e n o no processo todo Mesmo as recentes id ias de linhas de produto de software ainda n o produziram consenso com rela o a quais atividades incluindo entradas 21 sa das e artefatos produzidos e requisitos um processo efetivo de reutiliza o deve possuir ALMEIDA et al 2005 Este fato tamb m pode ser verificado no cen rio brasileiro onde um estudo de levantamento realizado em empresas LUCR DIO et al 2008 verificou que a maioria das organiza es investigadas cerca de 65 n o se preocupa com reutiliza o em seus processos de software Neste ponto chega se a uma primeira motiva o importante faz se necess rio um processo sistem tico e completo de reutiliza o que complemente as id ias para resolver partes mais espec ficas do problema Neste sentido a combina o de conceitos e t cnicas existentes em uma forma nova e inexplorada pode oferecer contribui es tanto para o mundo acad mico como para a ind stria Esta opini o j foi expressa por Jim Neighbors um dos pioneiros em reutiliza o de software d cadas atr s organiza es acad micas em ci ncia da computa o parecem preferir o trabalho em novas teorias Por m alguns dos mais bem sucedidos trabalhos acad micos s o uma fus o e formaliza o de t cnicas de sucesso NEIGHBORS 1989 Os problemas com o desenvolvimento de softwar
380. rganiza o gi ENGS5 Desenvolver modelo independente de plataforma um modelo independente de plataforma reflete os requisitos do sistema sem utilizar conceitos espec ficos da plataforma Os requisitos s o documentados de acordo com as t cnicas de modelagem estabelecidas na organiza o A abordagem n o est focada em um tipo espec fico de modelo e portanto pode ser utilizada para desenvolver modelos independentes de plataforma ENG6 Desenvolver transforma es t cnicas modelo para texto as transforma es devem ser desenvolvidas com base nos metamodelos de origem e destino A defini o das transforma es com base na sintaxe concreta por exemplo XMI s o insuficientes pois elas limitam a transforma o a apenas uma sintaxe concreta Para isso decide se sobre qual linguagem de transforma o utilizar s o identificados os metamodelos de origem e destino s o definidas as regras de transforma o que s o compiladas e executadas por uma ferramenta e opcionalmente completa se o c digo gerado caso necess rio para completar a transforma o A abordagem tem atividades para transforma es de modelo para texto visando dar suporte variabilidade do dom nio ENG7 Verificar modelos a verifica o de modelos inclui a checagem dos requisitos para determinar se est o completamente e adequadamente refletidos nos modelos A abordagem n o define atividades para verifica o de modelos Zi P
381. ria ser gerado de forma que at o processo de inje o seja automatizado Por exemplo poss vel gerar arquivos de configura o para frameworks de inje o de depend ncia como o Spring Estes padr es assumem que h um elemento fixo entre os dois lados da depend ncia uma interface uma classe abstrata ou uma assinatura de m todo Por m h casos onde at mesmo as assinaturas dos m todos s o geradas como por exemplo um gerador que produz objetos de acesso a dados Data Access objects DAO com m todos para realizar opera es b sicas de inser o remo o e consulta Cada DAO possui seus pr prios conjuntos de m todos com diferentes assinaturas dependendo dos nomes e atributos das entidades Nestes casos t cnicas de reflex o podem ser a nica solu o para remover depend ncias em tempo de compila o Atrav s da reflex o poss vel transformar todas as chamadas de m todos de c digo n o gerado para c digo gerado em chamadas reflexivas de forma que o m todo sendo chamado desconhecido pelo compilador C digo gerado depende de c digo gerado isto normalmente acontece quando h dois subdom nios que dependem um do outro Um problema que surge do relacionamento entre m ltiplos subdom nios como garantir a integridade deste relacionamento Uma possibilidade utilizar os nomes dos elementos como refer ncias isto o nome de uma refer ncia em um modelo deve ser id ntico ao nome do elemento r
382. riado para o problema em quest o Diferentes geradores correspondem a diferentes processos para se produzir os artefatos do dom nio e pode se decidir por um deles dependendo do problema Neste cen rio a situa o ideal seria manter uma biblioteca de geradores de aplica o e utilizar t cnicas de classifica o e busca para facilitar a sele o de forma similar s bibliotecas de componentes reutiliz veis Por m essa situa o requer a exist ncia de um grande n mero de geradores para um mesmo dom nio de problema Em 1992 Krueger destacava a escassez de geradores que al m de poucos eram normalmente restritos a um n mero reduzido de dom nios KRUEGER 1992 Atualmente com a evolu o das tecnologias necess rias para a programa o generativa principalmente a transforma o de software o n mero de geradores vem crescendo conforme demonstram Allilaire et al 2006 que exploram o gerenciamento de reposit rios de modelos e transforma es de software utilizando t cnicas similares s utilizadas em reposit rios de componentes Adapta o a adapta o a tarefa prim ria realizada por um desenvolvedor de software utilizando um gerador de aplica es KRUEGER 1992 Corresponde tarefa de especifica o que produz a entrada requerida pelo gerador normalmente um programa em uma DSL O desenvolvedor utiliza essa DSL para informar ao gerador como especializar os conceitos do dom nio e produzir uma solu o
383. riam ser identificadas heur sticas que facilitem principalmente as atividades de projeto arquitetural voltado para o MDD constru o de DSLs transforma es e geradores de c digo especializados para um determinado dom nio Z e Assist ncia contextualizada automatizada esta outra possibilidade de trabalhos futuros A abordagem n o oferece nenhum tipo de ajuda no sentido de acompanhamento de processo com base no contexto da tarefa atual ou de outras informa es relevantes como por exemplo a necessidade de aplica o de um padr o ou estilo arquitetural Neste poss vel trabalho futuro a partir de sugest es sobre quais atividades a serem realizadas em um contexto particular como por exemplo a exibi o autom tica de ajuda espec fica de contexto desenvolvedores de produtos podem ser ativamente guiados durante tarefas de solu o de problemas No contexto do MDD ela pode ajudar com as tarefas complexas envolvidas com o desenvolvimento das linguagens e ferramentas espec ficas de dom nio transforma es e adapta o manual de c digo gerado Tecnologias como o quadro de tarefas do GMF Generic Modeling Framework as receitas do openArchitectureWare Se o 2 2 2 e as Microsoft Blueprints s o exemplos dessa assist ncia sendo aplicada ao MDD Trabalhos futuros podem explorar as atividades necess rias para o desenvolvimento deste tipo de assist ncia no contexto do MDD e da engenharia de dom nio Este poderia ser o tema de
384. rias quais s o opcionais quais s o apenas desej veis etc Fica a cargo da organiza o decidir quais pr ticas adotar de acordo com seu contexto e a melhor maneira de realizar cada pr tica Nesta tese foram realizadas somente as pr ticas relacionadas ao desenvolvimento para reutiliza o aqui descritos como an lise projeto e implementa o do dom nio O objetivo foi dar suporte s atividades essenciais relacionando cada uma com o desenvolvimento orientado a modelos e como o mesmo pode ajudar na obten o dos objetivos de cada pr tica Mais detalhes sobre como este modelo se relaciona com a presente abordagem s o apresentados no Cap tulo 4 2 2 Desenvolvimento orientado a modelos Apesar dos in meros avan os na rea da Engenharia de Software ainda existem problemas KLEPPE WARMER BAST 2003 com a maneira com que o software desenvolvido na maioria das organiza es que permanecem como desafios at os dias atuais FRANCE RUMPE 2007 Conforme discutido brevemente no Cap tulo 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 Unified Modeling Language ou Linguagem de Modelagem Unificada OMG 2007 para criar modelos de alto n vel que s o teis em um primeiro momento para facilitar a an lise de um problema Atrav
385. riormente evoluindo para um mestrado visando incluir melhorias e corre es na abordagem com base nos resultados e Reutiliza o de outros tipos de artefatos nesta tese n o foi feita distin o com respeito ao tipo de artefato sendo gerado N o h atividades ou diretrizes espec ficas para o 231 desenvolvimento de transforma es que geram outras coisas al m do c digo fonte como outros modelos arquivos de configura o documenta o entre outros Este um ponto interessante pois neste tipo de artefato n o h a possibilidade de utiliza o por exemplo de padr es de projeto e outras t cnicas que se baseiam em conceitos da orienta o a objetos em particular a heran a Este poderia ser o tema de um trabalho de mestrado e Especializa o da abordagem para dom nios espec ficos outra limita o desta tese que a abordagem um pouco vaga em algumas atividades como aquelas para a defini o das DSLs por exemplo Idealmente deveria se buscar um processo mais sistem tico de forma a reduzir as possibilidades de erros e interpreta es erradas Por m em alguns casos n o foi poss vel definir mais detalhes pela pr pria natureza criativa do processo de cria o de software Trabalhos futuros principalmente de mestrado poderiam explorar a aplica o da abordagem em diferentes dom nios visando detalhar mais algumas atividades conforme as caracter sticas destes dom nios Durante esta aplica o pode
386. rir a um tipo de documento do subdom nio de autoria Refer ncias baseadas em nome ou pontes entre modelos WARMER KLEPPE 2006 s o mecanismos simples que resolvem estes problemas Refer ncias baseadas em nome consistem em um simples atributo do tipo string na DSL que cont m a refer ncia que aponta para o nome de um elemento na DSL sendo referenciada As checagens de tipo e integridade referencial devem ser feitas manualmente Pontes entre modelos n o s o muito mais poderosas consistindo na cria o de um elemento na DSL que cont m a refer ncia que uma c pia exata de um elemento na DSL sendo referenciada Esta t cnica propicia a checagem de tipos mas a checagem de integridade referencial ainda precisa ser realizada manualmente Caso necess rio uma solu o mais poderosa apresentada por Hessellund Czarnecki e Wasowski 2007 que prop em o uso de regras l gicas para estabelecer rela es inter DSL Desta forma consultas de mais alto n vel podem ser realizadas facilitando a checagem da consist ncia Sub atividade ID 2 5 Constru o da ferramenta de modelagem espec fica de dom nio Uma vez que as sintaxes abstratas e concretas estejam definidas uma ferramenta de modelagem espec fica para a DSL constru da Frameworks de DSLs como GMF ou openArchitectureWare entre outros s o a tecnologia mais apropriada para a implementa o da ferramenta uma vez que eles exigem pouco conhecimento na constru o
387. rramental ferramentas de modelagem e editores A cada itera o mais subdom nios s o implementados at que todos aqueles selecionados na atividade AD 5 estejam implementados ou devidamente investigados 3 Atividade ID 3 Desenvolvimento das transforma es e refinamento das DSLs nesta atividade s o desenvolvidas transforma es de software e geradores de c digo para os subdom nios e as DSLs definidas na atividade ID 2 s o refinadas a partir da experi ncia com a implementa o A cada itera o novas transforma es e geradores s o desenvolvidos at que todos os subdom nios selecionados na atividade AD 5 tenham transforma es e geradores ou foram devidamente investigados Este desenvolvimento baseado em uma implementa o de refer ncia que serve como exemplo para a constru o dos geradores de c digo 4 Atividade ID 4 Desenvolvimento do framework do dom nio esta atividade cuida do refinamento da implementa o de refer ncia produzida na atividade ID 3 produzindo um framework do dom nio A cada itera o o framework evolui com o suporte variabilidade de mais subdom nios e 5 Atividade ID 5 Documenta o do dominio esta atividade que a exemplo da atividade ID 1 est fora do ciclo iterativo da fase de implementa o cuida da documenta o dos artefatos desenvolvidos nesta itera o do ciclo principal Ap s a fase de implementa o tem se como resultado um conjunto de artefatos de i
388. rtefatos de software que ser o posteriormente reutilizados e o desenvolvimento com reutiliza o que consiste no desenvolvimento de aplica es que reutilizam os artefatos previamente desenvolvidos 2 Esta distin o entre desenvolvimento para com reutiliza o 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 d cada de 1970 de Parnas 1976 o mesmo autor que definiu os conceitos de encapsulamento da informa o um dos fundamentos da orienta o a objetos Neste trabalho descrito o conceito de fam lias de programas e apesar de inicialmente ter focado na variabilidade em termos das caracter sticas n o funcionais Parnas estabelece a base para as linhas de produto de software LINDEN SCHMID ROMMES 2007 O princ pio definido era o de estudar primeiro o que os programas de uma mesma fam lia tinham em comum para depois tentar entender o que os diferenciava Em seguida duas alternativas de m todo produziam programas incompletos que implementavam as partes comum da fam lia e deixavam as partes vari veis para serem instanciadas posteriormente o m todo de refinamento por etapas stepwise refinement que produzia um programa no qual alguns tipos de operandos e operadores eram deixado
389. rtefatos que s o reutilizados desnecessariamente Al m de causar preju zos manuten o ocupar espa o de forma desnecess ria e confundir os desenvolvedores este fato distorce a m trica de reutiliza o Analisando se tamb m a quantidade de reutiliza o n o desejada nota se que houve redu o significativa ou seja na realidade a quantidade de LOC reutilizadas foi menor por m a reutiliza o ocorreu de forma melhor com menos c digo desnecess rio poluindo a aplica o Isto foi alcan ado de forma simples atrav s de geradores que fazem a c pia seletiva dos arquivos de acordo com as configura es do produto Os artefatos produzidos pela equipe apresentaram qualidade inferior em termos de instabilidade complexidade e manutenibilidade do que os artefatos desenvolvidos nos outros estudos Isto se deve principalmente s dificuldades com o aprendizado e treinamento conforme citado pela pr pria equipe Al m disso foram desenvolvidos poucos artefatos e uma baixa taxa 200 de reutiliza o com gera o de c digo 3 99 devido principalmente falta de tempo e dedica o parcial dos participantes Estes resultados s o particularmente interessantes pois representam a utiliza o da abordagem em um cen rio mais t pico e pr ximo da realidade de uma organiza o de software Existe tamb m uma ocorr ncia que foi brevemente citada pela equipe e que merece uma avalia o mais aprofundada Na entrevista
390. s 1993 p 126 133 DEBAUD J SCHMID K A systematic approach to derive the scope of software product lines In 2 st International Conference on Software Engineering ICSE 99 Los Angeles CA USA s n 1999 p 34 43 239 DEBAUD J M FLEGE O KNAUBER P PuLSE DSSA A method for the development of software reference architectures In SAW 98 Proceedings of the third international workshop on Software architecture New York NY USA ACM 1998 p 25 28 ISBN 1 58113 081 3 DEELSTRA M et al Model driven architecture as approach to manage variability in software product families In Workshop on Model Driven Architecture Foundations and Applications MDAFA 2003 Enschede The Netherlands s n 2003 p 109 114 DESOUZA K C AWAZU Y TIWANA A Four dynamics for bringing use back into software reuse Communications of the ACM v 49 n 01 p 97 100 2006 DEURSEN A v KLINT P VISSER J Domain specific languages An annotated bibliography SIGPLAN Notices ACM Press v 35 n 6 p 26 36 2000 DEURSEN A van KLINT P Little languages little maintenance Journal of Software Maintenance John Wiley amp Sons Inc New York NY USA v 10 n 2 p 75 92 1998 ISSN 1040 550X DEVANBU P et al Analytical and empirical evaluation of software reuse metrics In CSE 96 Proceedings of the 18th international conference on Software engineering Washington DC USA IEEE Computer Society 1996 p
391. s DEURSEN KLINT VISSER 2000 1 Bibliotecas de subrotinas consistem em subrotinas que realizam tarefas espec ficas para um dom nio de problema de forma que o desenvolvedor ao reutilizar essas subrotinas tamb m reutiliza conhecimento espec fico para esse dom nio 2 Frameworks orientados a objetos e frameworks de componentes estendem a id ia de bibliotecas de subrotinas Enquanto bibliotecas possuem uma estrutura simples com as subrotinas sendo chamadas pela aplica o os frameworks normalmente est o no controle sendo os respons veis por chamar o c digo espec fico da aplica o e 3 Linguagens espec ficas de dom nio DSL s o linguagens pequenas normalmente declarativas com poder expressivo focado em um dom nio de problema Normalmente programas em DSL s o convertidos para programas em linguagens comuns utilizando frameworks ou bibliotecas de subrotinas Dessa forma pode se pensar em uma DSL como uma maneira de esconder os detalhes da biblioteca ou framework Do ponto de vista da reutiliza o todas essas abordagens s o similares apresentando um nico prop sito reutilizar o conhecimento do dom nio na constru o de aplica es daquele dom nio Seja na forma de chamadas de rotinas de uma biblioteca ou utilizando uma linguagem o resultado final praticamente o mesmo com diferen as apenas na forma de express o da solu o De fato Martin Fowler um conceituado pesquisador na rea de reutiliza
392. s Inclus o imediata significa que o subdom nio est maduro o suficiente possui ferramentas e uma ou mais linguagens de modelagem est veis e validadas O n vel de confian a alto e o subdom nio j pode ser inclu do nas fases de projeto e implementa o Tamb m significa que o desenvolvimento dos artefatos deste subdom nio guiado pelas linguagens e ou ferramentas definidas Enquanto a maioria dos subdom nios somente ir alcan ar este n vel ap s passar pelos n veis 2 3 4 e 5 alguns subdom nios bem conhecidos podem come ar diretamente no n vel 5 Alguns podem at come ar diretamente no n vel 6 se a organiza o sentir que possui a experi ncia necess ria para lidar com esta tecnologia Para tomar a decis o correta o analista do dom nio deve considerar toda informa o dispon vel e a decis o deve ser acordada com todos os stakeholders Al m da informa o ja mencionada alguns outros crit rios podem ajudar e Experi ncia da equipe de desenvolvimento se a equipe de desenvolvimento possui experi ncia com algum subdominio pode ser vantajoso focar neste subdom nio para que seus benef cios possam ser alcan ados sem muito esfor o de entendimento e aprendizado e Tamanho do subdom nio sempre que poss vel deve se come ar com subdom nios menores e aument los gradativamente TOLVANEN 2005 Apesar de dom nios menores levarem a menos benef cios em termos de reutiliza o s o mais f ceis de g
393. s arquiteturais O processo apoiado por ferramentas que auxiliam sua execu o e aplicam t cnicas da MDA para gera o autom tica de c digo A abordagem desta tese tem os mesmos objetivos de reutiliza o que o trabalho de Blois 2006 por m n o se restringe a uma tecnologia de componentes Aqui o foco reconhecer uma maior diversidade de tecnologias de implementa o e subdom nios buscando oferecer suporte do MDD para produzir uma implementa o que aproveite os diferentes potenciais de automa o de cada subdom nio Por estar direcionado a uma plataforma de implementa o mais homog nea o trabalho de Blois 2006 possui a vantagem de definir de forma mais sistem tica suas atividades principalmente com rela o ao projeto da arquitetura de refer ncia e a gera o de c digo J nesta tese as atividades s o mais vagas exigindo maior trabalho de adapta o por parte do engenheiro de software Por exemplo n o h heur sticas para o mapeamento entre artefatos de an lise e projeto e nem para auxiliar na identifica o dos elementos arquiteturais Al m disso s o necess rias diversas atividades exclusivamente dedicadas ao projeto de DSLs transforma es e geradores pois aqui a plataforma de implementa o pode ser qualquer uma e n o necessariamente uma plataforma de componentes Em contrapartida a abordagem desta tese possui maior potencial de automa o com uma s rie de atividades dedicadas exclusivamente ao
394. s da reengenharia de software s o engenharia reversa seguida por mudan as no sistema de funcionalidade ou de implementa o e seguida pela engenharia avante Em outras palavras reengenharia o processo de se criar uma descri o abstrata do sistema elaborar mudan as em alto n vel de abstra o e ent o reimplementar o sistema JACOBSON LINDSTROM 1991 Esse processo de engenharia reversa modifica es e engenharia avante tamb m contempla os quatro conceitos da reutiliza o de software A fase de engenharia reversa corresponde ao conceito de abstra o enquanto que as fases de modifica es e engenharia avante correspondem aos demais conceitos Abstra o a abstra o corresponde engenharia reversa onde o conhecimento existente no sistema legado recuperado e toda informa o relevante organizada de forma a possibilitar sua futura utiliza o durante a reconstru o Sele o a sele o ocorre quando o desenvolvedor precisa realizar mudan as no sistema sejam elas de funcionalidade ou implementa o Ele precisa conhecer cada artefato recuperado durante a engenharia reversa e selecionar aquele onde ser o feitas as modifica es Adapta o a adapta o corresponde s mudan as sendo efetuadas nos artefatos recuperados Os mesmos s o modificados para atender a novos requisitos ou incorporar novas tecnologias e Integra o a integra o ocorre de forma gradual Normalmente a
395. s de modelos facilita se a realiza o de discuss es trocas de id ias e comunica o entre as equipes envolvidas com o processo de software Por m esses modelos logo se tornam in teis medida que o desenvolvimento avan a Isto porque programadores que criam c digo manualmente tamb m realizam mudan as e manuten es diretamente no c digo Desta forma sem um trabalho extra para atualiz los os modelos logo perdem a consist ncia se tornando incapazes de representar a realidade Mesmo com t cnicas de engenharia reversa que facilitam a extra o autom tica de modelos a partir do c digo a verdade que os modelos s o artefatos desnecess rios no sentido em que n o fazem parte do software propriamente dito S o apenas parte da documenta o que precisa ser atualizada com esfor o n o diretamente produtivo tornando se literalmente um fardo a ser carregado pela equipe Al m disso modelos s o mais teis para membros novos de uma equipe Nos projetos em que uma mesma equipe segue trabalhando por um longo tempo as informa es nos modelos ja s o bem conhecidas pelos membros da equipe e portanto nem valor de documenta o os mesmos possuem bastante comum na chegada de um novo membro a uma equipe o mesmo perguntar pela documenta o e modelagem do sistema E tamb m comum este membro obter como resposta o fato de que os documentos est o antigos e desatualizados Reutiliza o de conhecimento al
396. s organiza es preferem utilizar processos de reengenharia gradativos onde apenas um m dulo reconstru do a cada vez Isso possibilita que o sistema legado possa continuar sendo utilizado durante a reconstru o SEACORD PLAKOSH LEWIS 2003 O Quadro 17 resume as principais t cnicas para reutiliza o de software apresentadas neste ap ndice apresentando as id ias chave de cada t cnica de acordo com os quatro conceitos da reutiliza o 270 SIP MITOS IP OBSEZTINII LP SOVISPQ SO TIIDUOD SOL SePRUOTORTAI SLOTUD9 sTedround sep oUINsSeY OIpENd ajuoueperedos oprisajur opuos ojmpou epeo woo soonod sor SvISO OUD9 seaou no soystnbor soaou g Jopuoje vied sopriadnoos SOPROYIPOW Wares JIBMJOS OpIN sUOdaI 9 BUID SIS O eNpeIs PULIOJ oq sojejogre sou seduepny e sora sop op aps esL CLIRqUoSUA sp BLABYUaSUIaYy opsentis ewojqord opeuruiajop um SQUaLIODOI BUID SIS OP YUVISAI op og ridepy e vied ogiped op og eidepy vied ovsped um Jod vosng sog nios op ovdezifelauan sao i1ped SOYOURS SOYOURS SIOABLIBA vyuoid tures og eorjde eum 9 yromaupsf 3 SIDAPLIRA sojuod sop openbape sojuod so opurorisop o stod ewojqoid um 9 ogu ojuauieunoN soaemp ovserourisuy yomaupsf op tujoosg orurop op ovdejosoiday SY4OMIUIDA eurigold um op aed seuode epeios 9 opuenb sagsvoyipour seliessooou Jas wapod uieiog ojojduioo JOpLIos operidoide epeguo BALIO
397. s ou textuais devem ser consideradas e a escolha depende de uma an lise mais aprofundada PETRE 1995 Entre os fatores a serem analisados pode se citar o fato de que a implementa o de interpretadores textuais parsers uma tarefa reconhecidamente dif cil FEILKAS 2006 CLEAVELAND 1988 Al m disso imposs vel expressar todas as informa es necess rias em gram ticas livres de contexto FEILKAS 2006 Linguagens visuais tamb m s o mais intuitivas ESSER JANNECK 2001 e portanto resultam em maior facilidade de utiliza o por especialistas n o experientes com tecnologia da informa o Muitas vezes por m uma combina o de m ltiplos formatos de entrada ou mesmo m ltiplas linguagens necess ria WILE 2004 TOLVANEN KELLY 2001 As extens es do modelo de features descritas na se o anterior se aproximam bastante da capacidade de representa o de variabilidade que pode ser alcan ada atrav s de uma DSL A diferen a que com uma DSL tem se um maior poder expressivo pois o foco na linguagem visa oferecer uma sintaxe concreta que seja familiar e intuitiva para os especialistas do dom nio enquanto a modelagem estendida de features ainda est atrelada a uma nota o fixa 3 2 Implementa o da variabilidade Conforme j identificado por Parnas 1976 h d cadas atr s al m de muitos outros desde ent o MILI MILI MILI 1995 EZRAN MORISIO TULLY 2002 sistemas de software raramente 63
398. s para controle e N vel 4 MDD Integrado o n vel 4 caracterizado por uma melhor integra o entre os n veis de abstra o de modelagem Aspectos de neg cio independentes de plataforma e espec ficos de plataforma s o separados em elementos do MDD atividades de modelagem s o integradas e garante se um desempenho de modelagem eficiente Z ENG8 Desenvolver metamodelo centrado na arquitetura envolve a identifica o das principais entidades que fazem parte da arquitetura os 279 relacionamentos entre estas entidades e a linguagem de metamodelagem a ser utilizada Por fim o metamodelo desenvolvido em uma ferramenta que d suporte linguagem estabelecida O projeto arquitetural voltado ao MDD est presente na abordagem que tem atividades para que o metamodelo seja centrado na arquitetura Z ENG Desenvolver metamodelo independente de plataforma de forma similar ao desenvolvimento do metamodelo centrado na arquitetura o modelo independente de plataforma desenvolvido modelando se as principais entidades do sistema e seus relacionamentos mas sem refer ncias a uma plataforma espec fica A abordagem n o est focada em um tipo espec fico de modelo e portanto pode ser utilizada para desenvolver metamodelos independentes de plataforma 7 ENG10 Desenvolver modelo de neg cios consiste na an lise dos requisitos de neg cio e cria o de um modelo que representa como o sistema funciona utilizando entid
399. s sem implementa o e o m todo de especifica o dos m dulos que baseava se na especifica o em alto n vel de unidades de comportamento de programas e no encapsulamento da informa o para que o restante do c digo pudesse ser idealizado e constru do 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 m dulos especificados Ou seja h uma mudan a de foco Ao inv s 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 poss vel reaproveitar as partes comuns e apenas desenvolver o que completamente novo Na nomenclatura t pica da rea de linhas de produtos de software este conjunto de sistemas similares chamado de fam lia de produtos ou 34 dom nio de aplica es As partes reutiliz veis s o a arquitetura de refer ncia e os artefatos do n cleo core assets O desenvolvimento das partes comuns desenvolvimento para reutiliza o chamado de Engenharia de Dom nio e o desenvolvimento de um produto desenvolvimento com reutiliza o de Engenharia de Aplica es CLEMENTS NORTHROP 2002 MILI et al 2002 LINDEN SCHMID ROMMES 2007 Com exce o de uma preocupa o maior com aspectos de neg cio e
400. sa forma necess rio definir 87 com exatid o o escopo a ser desenvolvido Para tal defini o ao inv s de buscar atender a artefatos gen ricos do dom nio de acordo com a percep o intui o de especialistas esta abordagem foca em um conjunto finito de aplica es ou produtos que sejam de interesse da organiza o CLEMENTS NORTHROP 2002 Dessa forma s o menores as chances de um artefato poder ser reutilizado em aplica es n o previstas mas aumenta se consideravelmente o seu n vel de reutiliza o dentro deste escopo e Criar modelos do dom nio modelos expressam os conceitos do dom nio de forma a facilitar o seu entendimento por parte dos projetistas e desenvolvedores Al m disso os modelos devem explicitar as variabilidades e comunalidades dentro do dom nio KANG et al 1990 JACOBSON GRISS JONSSON 1997 GRISS FAVARO D ALESSANDRO 1998 KANG etal 1998 KANG LEE DONOHOE 2002 de forma a facilitar o projeto de software reutiliz vel e e Identificar os subdom nios onde a automa o poss vel nesta abordagem o desenvolvimento orientado a modelos utilizado para aumentar o n vel de reutiliza o principalmente na implementa o das variabilidades Ao inv s de deixar esta tarefa para ser realizada pelos desenvolvedores de aplica es o conhecimento de como implementar as variabilidades encapsulado em ferramentas de modelagem e transforma es autom ticas de software LEDECZI et al
401. scritos na an lise aqueles que descrevem a variabilidade que diz respeito ao m dulo sendo refinado na itera o atual Caso seja necess rio pode se enriquecer estes cen rios com mais informa es tais como atributos de qualidade a serem atendidos pela arquitetura Sub atividade PD 2 2 Sele o das diretrizes arquiteturais de variabilidade baseada em DSLs Como discutido no in cio deste cap tulo variabilidades mais complexas requerem uma descri o mais rica Esta abordagem prop e o uso de linguagens espec ficas de dom nio para formalizar o espa o de varia o em reas particulares do dom nio subdom nios definindo os conceitos e introduzindo restri es e regras relacionadas variabilidade neste subdom nio DSLs tamb m s o utilizadas para guiar o desenvolvimento de transforma es de software e gera o de c digo nas atividades de implementa o Esta atividade cuida apenas da sele o de DSLs que descrevem o subdom nio relacionado ao m dulo sendo refinado Caso seja necess rio desenvolver uma nova DSL esta deve ser realizada posteriormente na fase de implementa o do dom nio 123 Sub atividade PD 2 3 Sele o das diretrizes arquiteturais de integra o entre subdom nios E importante ressaltar que subdom nios quase nunca est o isolados entre si Por exemplo com rela o ao dom nio web de autoria de conte do mostrado na Figura 11 o subdom nio de navega o pode conter refer ncias pa
402. sed Software Engineering GPCE Germany s n 1999 p 178 194 BIERHOFF K LIONGOSARI E S SWAMINATHAN K S Incremental development of a domain specific language that supports multiple application styles In GRAY J TOLVANEN J P SPRINKLE J Ed 6th OOPSLA Workshop on Domain Specific Modeling DSM 06 Portland Oregon USA S 1 Jyvaskyla University Printing House Jyvaskyla Finland ISBN 951 39 2631 1 ISSN 1239 291X 2006 p 67 78 237 BIGGERSTAFF T J RICHTER C Reusability framework assessment and directions In BIGGERSTAFF T J PERLIS A J Ed Frontier Series Software Reusability Volume I Concepts and Models New York ACM Press 1989 p 1 17 BLOIS A P T B Uma Abordagem de Projeto Arquitetural Baseado em Componentes no Contexto de Engenharia de Dominio Tese Tese de Doutorado Universidade Federal do Rio de Janeiro 2006 BOEHM B A spiral model of software development and enhancement IEEE Computer v 21 n 5 p 61 72 May 1988 BOSCH J Design and Use of Software Architectures S 1 Addison Wesley 2000 BOTTERWECK G O BRIEN L THIEL S Model driven derivation of product architectures In STIREWALT R E K EGYED A FISCHER B Ed Proceedings of the twenty second IEEE ACM international conference on Automated software engineering S ACM 2007 p 469 472 ISBN 978 1 59593 882 4 Dispon vel em lt http doi acm org 10 1145 1321631 1321711 gt
403. sentido a medida de n vel de confian a serve como uma ferramenta de gerenciamento de riscos ajudando a garantir que mudan as cr ticas na arquitetura e nos modelos de an lise levem aos resultados esperados Tamb m serve como um mecanismo de suporte tomada de decis o auxiliando na coordena o dos esfor os durante o processo iterativo desta abordagem A determina o de um n vel de confian a de um subdom nio altamente subjetiva e dependente do conhecimento do especialista do dom nio e da experi ncia dos engenheiros do dom nio Nesta tese as seguintes quest es foram identificadas por possuir impacto na decis o e devem ser consideradas e Existe uma linguagem de modelagem para o subdom nio e Caso exista qual a maturidade desta linguagem uma linguagem bem conhecida utilizada por especialistas em diferentes organiza es Existe somente na organiza o em quest o Foi desenvolvida somente para este projeto e A linguagem de modelagem foi validada atrav s de estudos de caso para este projeto e Existe uma ferramenta espec fica para o subdom nio e Caso exista qual a maturidade desta ferramenta uma ferramenta bem conhecida utilizada por especialistas em diferentes organiza es Existe somente na organiza o em quest o Foi desenvolvida somente para este projeto e A ferramenta foi validada atrav s de estudos de caso para este projeto 105 e Como a ferramenta se enquadra no proje
404. 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 esfor o necess rio para adaptar esse artefato para seu novo contexto Para diminuir esse esfor o o principal foco da maioria das abordagens voltadas reutiliza o tentar criar artefatos gen ricos o suficiente para atenderem s necessidades de diversas aplica es poss veis Esses artefatos s o ent o adaptados para o novo contexto por meio de par metros arquivos de configura o ou mesmo pequenas modifica es e Integra o uma das dificuldades inerentes reutiliza o diz respeito arquitetura do software final uma vez que ele ir conter peda os de outros sistemas de software Quando necess rio integrar artefatos de software que n o foram originalmente projetados para operar de forma conjunta surge uma s rie de desafios e dificuldades como por exemplo tentar manter a consist ncia e padroniza o das interfaces prever poss veis necessidades de adapta o ou modifica o e realizar testes de forma a validar a funcionalidade em n vel de sistema O desastre com o foguete europeu Ariane 5 JEZEQUEL MEYER 1997 e os enormes preju zos decorrentes alertam para a import ncia deste aspecto Estes quatro conceitos b sicos est o presentes nas diferentes formas de reutiliza o desde o simples processo de se co
405. sintaxe abstrata De fato uma DSL pode possuir m ltiplas sintaxes concretas KLEPPE 2007 A sem ntica define o significado dos elementos da sintaxe abstrata e pode variar de acordo com o objetivo desejado Por exemplo se o objetivo da linguagem facilitar a comunica o interpessoal a sem ntica define o que cada frase ou modelo significa para um leitor humano Neste sentido pode se considerar a sem ntica como sendo um elemento pass vel de diversas interpreta es uma vez que qualquer pessoa pode atribuir um significado a determinada palavra ou cone No entanto no contexto do MDD a sem ntica definida em forma de a es a serem executadas por um interpretador autom tico As abordagens para o tratamento da sem ntica no MDD podem se enquadrar em ao menos quatro categorias KLEPPE 2007 1 Denotativa descri es matem ticas que representam o significado do programa ou modelo 2 Operacional tamb m conhecida como execu o can nica CLEENEWERCK KURTEV 2007 consiste na interpreta o do programa ou modelo como uma sequ ncia de passos a serem executados Normalmente resulta em uma m quina de estados 3 Tradutiva consiste na tradu o do programa ou modelo em outra linguagem conhecida e 4 Pragm tica uma ferramenta normalmente conhecida como implementa o de refer ncia executa o programa ou modelo A abordagem tradutiva uma das mais indicadas KLEPPE 2007 e tamb m uma das mais emp
406. so relacionados ao MDD classificados em cinco n veis conforme mostra a Figura 7 N vel 5 MDD Definitivo Ee N vel 4 MDD Integrado N vel 3 MDD Inicial A N vel 2 MDD B sico N vel 1 Modelagem ad hoc Figura 7 Modelo de maturidade em MDD MODELWARE 2006d Cada pr tica identificada por um conjunto de caracteres que indica sua rea e um n mero sequencial sendo que ENG Engenharia PJM Gerenciamento de projeto e SUP Suporte As pr ticas est o agrupadas nos cinco n veis conforme descrito a seguir e N vel 1 Modelagem ad hoc neste n vel apenas o desenvolvimento tradicional realizado Pr ticas de modelagem s o utilizadas apenas esporadicamente ou nunca e N vel 2 MDD B sico este n vel caracterizado pela utiliza o b sica de modelos cobrindo atividades simples do MDD como a decis o sobre as ferramentas e conven es de modelagem ENGI e PJMI Modelos s o utilizados apenas para guiar a implementa o e documenta o Tipicamente apenas modelos t cnicos ENG2 s o 54 utilizados incluindo todos os aspectos de um sistema sem distin o entre aspectos de neg cio ou aspectos espec ficos de plataforma A gera o de c digo e de documenta o ENG3 e ENG4 feita diretamente a partir do modelo t cnico N vel 3 MDD Inicial neste n vel introduz se uma separa o entre modelos de neg cio independentes de plataforma ENGS5 e modelos espec ficos de platafor
407. specialista do dom nio segue a arquitetura definida na fase de projeto utilizando as t ticas e padr es associados para produzir uma implementa o que ir dar suporte ao desenvolvimento subsequente Por m nem toda comunalidade variabilidade estar contida no framework Assim o segundo papel da implementa o de refer ncia prover exemplos concretos das variabilidades restantes servindo como um retrato do c digo que as transforma es e geradores de c digo devem produzir completando assim o suporte automatizado variabilidade no dom nio Para isso a implementa o de refer ncia deve incluir exemplos de todos os pontos comuns e vari veis do dom nio Isto mais f cil de ser alcan ado para a variabilidade baseada em features que finita As seguintes diretrizes podem ser utilizadas com este objetivo Di Come ar implementando um exemplo completo que cont m todas as features mandat rias e uma sele o arbitr ria de uma feature em cada grupo de or features Deixar todas as features opcionais n o implementadas 156 D2 Para cada feature opcional modificar o exemplo criando uma nova vers o do mesmo de forma que a feature esteja presente Caso algum dos padr es de projeto descritos no cap tulo anterior tenha sido utilizado neste ponto do projeto para implementar esta variante em particular basta realizar uma simples sele o da variante conforme previsto pelo padr o Por m pode ser que neste
408. sportes a exist ncia de motores a Diesel mais caros pode requerer a presen a de um dispositivo GPS para aumentar a seguran a Outro exemplo seria o dispositivo de freios com atua o eletr nica precisar ser calibrado de uma maneira espec fica para funcionar adequadamente com um motor a Diesel A implementa o destas restri es n o t o imediata quanto no exemplo do sistema de aluguel de autom veis e normalmente n o 86 pode ser encapsulada dentro de um nico componente necessitando ser realizada durante o desenvolvimento da aplica o neste ponto que as t cnicas do MDD podem ser utilizadas Ao inv s de deixar que estas tarefas sejam executadas pelo desenvolvedor da aplica o o conhecimento sobre como implementar estas restri es encapsulado em transforma es MDD e linguagens espec ficas de dom nio LEDECZI et al 2001 Em um cen rio ideal tudo o que um desenvolvedor precisa fazer escolher quais features estar o presentes especificar alguns par metros e uma implementa o automaticamente gerada Obviamente este cen rio ainda est longe da realidade j que nem todo c digo pode ser completamente gerado Por m normalmente h partes do dom nio onde isto n o somente poss vel mas pode levar a enormes ganhos de produtividade aumentando o n vel de reutiliza o Por m como identificar que partes do dom nio podem ser automatizadas O argumento desta tese que esta ativida
409. strial Practice In Product Line Engineering S 1 Springer 2007 LISBOA L B ToolDAy A Tool for Domain Analysis Disserta o Mestrado Federal University of Pernambuco Recife Pernambuco Brazil 2007 LUCREDIO D ALMEIDA E S d PRADO A F d A survey on software components search and retrieval In STEINMETZ R MAUTHE A Ed 30th IEEE EUROMICRO Conference Component Based Software Engineering Track Rennes France IEEE CS Press 2004 p 152 159 LUCR DIO D et al Software reuse The Brazilian industry scenario J Syst Softw Elsevier Science Inc New York NY USA v 81 n 6 p 996 1013 2008 ISSN 0164 1212 LUCR DIO D et al The Draco approach revisited Model driven software reuse In VI WDBC Workshop de Desenvolvimento Baseado em Componentes Recife PE Brazil s n 2006 p 72 79 LUCR DIO D et al Performing domain analysis for model driven software reuse In 10th International Conference on Software Reuse Beijing China Springer Verlag 2008 Lecture Notes in Computer Science v 5030 p 200 211 LUCREDIO D JACKSON E K SCHULTE W Playing with fire Harnessing the hottest technologies for ultra large scale systems In 15th Monterey Workshop Foundations of Computer Software Future Trends and Techniques for Development September 24 26 2008 Budapest University of Technology and Economics S 1 s n 2008 MAIDEN N SUTCLIFFE A A computational mechanism fo
410. suporte execu o do projeto limita se descri o da abordagem em termos de suas atividades pap is entradas sa das etc N o existe um controle maior sobre sua execu o controle e melhoria conforme previsto nesta pr tica 283 AP NDICE C Reprodu o na integra da entrevista referente ao estudo emp rico envolvendo o dom nio de eventos cient ficos A seguir apresentada na ntegra a entrevista realizada como parte do estudo emp rico envolvendo o dom nio de eventos cient ficos P O modelo de features ajudou na defini o das linguagens espec ficas de dom nio transforma es e geradores de c digo R A equipe reportou que algumas features foram utilizadas diretamente na defini o inicial do modelo de configura o pois descreviam diferentes op es de configura o autom tica como quais subsistemas devem estar presentes e algumas de suas caracter sticas Mas principalmente foi relatado que o modelo de features ajudou na obten o de uma vis o geral do dom nio til para as atividades de customiza o e vendas uma vez que permite que o cliente visualize as caracter sticas do produto de forma facilitada e possa escolher entre as op es de maneira mais r pida A equipe que desconhecia a nota o empregada nesse modelo considerou f cil o aprendizado e entendimento inclusive podendo ser usada comercialmente ou estendida futuramente P A descri o da variabilidade em cen rios c
411. t trabalhando realizando as modifica es necess rias para integr lo ao novo contexto Analisando se esse processo cotidiano pode se identificar os quatro conceitos citados por Krueger 1992 Abstra o a abstra o existe na mente do desenvolvedor de maneira informal e formada durante a sua experi ncia pessoal como Engenheiro de Software Ele n o se lembra exatamente de todos os detalhes dos artefatos com os quais j se deparou Por m ele capaz de abstrair os detalhes relevando somente o que essencial formando uma esp cie de biblioteca reutiliz vel indexada em sua mem ria Sele o da mesma forma com que consegue abstrair os detalhes o desenvolvedor tamb m capaz de utilizar a sua mem ria seletiva para determinar se o artefato satisfaz suas necessidades e fornecer pistas de onde encontr lo Este momento corresponde sele o quando o desenvolvedor utilizando essas pistas se lembra primeiro do software ou biblioteca onde o artefato se encontra localizado Em seguida ele percorre a estrutura e 254 documenta o do software navegando por exemplo por meio da divis o em pacotes ou bibliotecas em busca do artefato lembrado por sua mem ria Adapta o encontrado o artefato copiado para seu novo local A adapta o ocorre somente se necess rio configurando o por meio de par metros ou de mecanismos de extens o ou mesmo modificando seu c digo manualmente e Integra o a i
412. t cnicas gen ricas utilizadas para implementar servi os opera es e fun es do dom nio Features de ambiente de opera o representam o ambiente no qual as aplica es s o executadas e Features comuns a todos os produtos do dom nio s o modeladas como mandat rias enquanto features que diferem entre os produtos podem ser opcionais ou alternativas Features opcionais representam features selecion veis dentro do dom nio e features alternativas indicam que apenas uma feature pode ser selecionada para um produto e e Um diagrama de features uma hierarquia gr fica que captura rela es estruturais e conceituais entre as features H tr s tipos de rela es composi o generaliza o e implementa o Regras adicionais complementam o modelo com rela es de depend ncia ou exclus o m tua entre as features Este modelo fundamentado na presen a ou aus ncia das features e capaz de cobrir grande parte da variabilidade presente na maioria dos dom nios Por m em alguns casos necess rio maior poder expressivo e detalhes que n o podem ser expressos atrav s destas regras Por este motivo Czarnecki Helsen e Eisenecker 2004b apresentam algumas extens es propostas na literatura para o modelo de features visando dar mais flexibilidade e capacidade para representar uma maior variedade de casos As seguintes extens es foram propostas e Cardinalidade de features features podem ser anotadas com cardina
413. t veis e pouco amadurecidos aconselh vel concentrar se nas features de capacita o Ap s certa maturidade com o dom nio ser alcan ada pode se passar para as demais features D3 Tentar primeiro encontrar diferen as entre as aplica es de um dominio para s ent o tentar identificar as partes em comum aplica es de um mesmo dom nio compartilham um alto grau de fun es em comum COPLIEN HOFFMAN WEISS 1998 Portanto o espa o em comum deve ser consideravelmente maior do que as diferen as e por consequ ncia mais f cil encontrar as diferen as primeiro A estrat gia inicialmente identificar as aplica es existentes e listar as features que caracterizam cada uma Encontradas as diferen as mais f cil identificar as features comuns Da N o identificar todos os detalhes de implementa o que n o se distinguem entre as aplica es do dom nio os desenvolvedores tendem a listar todos os detalhes de implementa o e identific los como features mesmo que n o haja varia es entre eles Mas importante notar que um modelo de features n o um modelo de requisitos que expressa os detalhes de fun es internas Por essa raz o esta atividade deve ser realizada pelo analista do dom nio que tende a abstrair detalhes de implementa o Por fim as aplica es e suas features s o organizadas na forma de um mapa de 91 aplica es Neste mapa colunas e linhas s o utilizadas para represent
414. ta abordagem Apesar de existirem v rios aspectos a serem explorados com rela o ao planejamento e realiza o de testes num contexto de reutiliza o e MDD optou se por n o entrar neste m rito por uma quest o de foco de pesquisa Outro ponto que d margem a muitas possibilidades o ambiente de suporte ao MDD Ferramentas s o parte essencial do MDD e existem diversas op es para o desenvolvimento 26 orientado a modelos Nesta pesquisa trabalhou se com ferramentas j existentes tais como aquelas apresentadas na Se o 2 2 2 em vez de contruir o ambiente ou ferramentas a partir do zero Isto foi poss vel devido ao atual cen rio de MDD que j conta com diversas op es concretas e que s o efetivamente utilizadas na pr tica Em resumo est fora do escopo desta pesquisa e A defini o detalhada das atividades do desenvolvimento com reutiliza o e Atividades de manuten o dos artefatos tais como aquelas relacionadas ao gerenciamento de configura o por exemplo e Atividades para planejamento e execu o de testes e e Desenvolvimento de ferramentas para o desenvolvimento orientado a modelos tais como ferramentas para transforma o ida e volta ou ferramentas para valida o de modelos e de transforma es Mais detalhes sobre o escopo da pesquisa em termos das pr ticas que est o inclu das e exclu das da abordagem definida nesta tese encontram se no Cap tulo 4 1 3 Estrutura da d
415. ta e concreta Al m disso nesta tese o metamodelo complementado com informa es originadas em uma implementa o concreta o que facilita a identifica o de variabilidades mais detalhadas e a constru o de transforma es e geradores de c digo mais precisos no suporte variabilidade 9 2 Trabalhos relacionados com o uso de m tricas para MDD e reutiliza o O estado da pr tica na avalia o de qualidade de modelos cont m evid ncias de que a modelagem ainda tida como uma atividade artesanal Apesar de existirem alguns padr es e regras baseadas no bom senso como minimizar o acoplamento aumentar a coes o manter uma hierarquia de classes pequena os desenvolvedores ainda dependem muito da opini o de especialistas para determinar quando um modelo bom ou n o FRANCE RUMPE 2007 Por m existem diversos trabalhos que investigam a avalia o de modelos e o uso de m tricas para aumentar a confiabilidade dos resultados da avalia o Mohagheghi e Aagedal 2007 apresentam os principais aspectos relacionados avalia o de qualidade de um processo de MDD Entre estes destacam se os aspectos de qualidade da linguagem de modelagem utilizada tais como sua complexidade e adequa o ao dom nio a qualidade das ferramentas utilizadas no processo o conhecimento dos especialistas com rela o ao uso das linguagens e ferramentas a qualidade do processo utilizado e o uso de t cnicas para identificar falhas e defeitos
416. ta vari vel do seu funcionamento e dos requisitos que levaram sua cria o Todos os requisitos e fun es associados com o m dulo pai devem possuir um m dulo correspondente que assuma a responsabilidade Estas responsabilidades devem estar claramente descritas e indicadas nas interfaces Atividade PD 5 Avalia o arquitetural Pap is Projetista do dom nio especialista do dom nio demais stakeholders Entradas PT 7 Diretrizes arquiteturais e PT 8 Inicial Projeto do dom nio Sa das PT 9 Avaliado Projeto do dom nio Descri o a abordagem segue o racioc nio do m todo PuLSE DSSA DEBAUD FLEGE KNAUBER 1998 no sentido em que o projeto arquitetural pode produzir m ltiplas arquiteturas cada uma oferecendo uma alternativa para se atender s diferentes diretrizes Uma atividade ent o respons vel por avaliar as alternativas e selecionar qual delas segue adiante no processo A avalia o arquitetural deve ser iniciada quando a equipe de desenvolvimento come ar a tomar decis es que dependem da arquitetura e o custo de se desfazer tais decis es maior do que o custo de se realizar a avalia o CLEMENTS KAZMAN KLEIN 2004 Nesta abordagem estas decis es s o referentes automa o dos subdom nios utilizando ferramentas de modelagem e transformadores que depende desta estrutura em comum para possibilitar a reutiliza o Assim esta atividade busca avaliar as alternativas de arquiteturas projet
417. tal para DSLs PT 13 Transforma es do dom nio PT 15 Framework do dom nio Linguagens espec ficas de PT 16 Documenta o do dom nio Quadro 12 Resumo das atividades para implementa o do dom nio orientada a modelos No pr ximo cap tulo apresentado um poss vel modelo de ciclo de vida para a utiliza o da abordagem considerando se um processo evolutivo e interativo com caracter sticas mais pr ximas realidade das organiza es 168 Produto de trabalho Descri o Estado PT 10 Subdom nios caracterizados Defini o do tipo de variabilidade Nenhum caracter stico de cada subdom nio baseada em features ou baseada em DSLs PT 11 Linguagens espec ficas de Defini o das sintaxes abstrata e concreta 1 Inicial vers o da DSL produzida dom nio das linguagens espec ficas de dom nio para somente atrav s de uma abordagem os subdom nios identificados durante o top down Normalmente faltam detalhes que processo A sintaxe abstrata das DSL visuais s ser o identificados ap s a implementa o normalmente um metamodelo enquanto 2 Refinado vers o inicial da DSL refinada a sintaxe abstrata das DSLs textuais uma ap s uma abordagem bottom up que gram tica identifica mais detalhes para a linguagem PT 12 Suporte ferramental para Ferramentas de modelagem para as DSLs 1 Inicial vers o das ferramentas DSLs Podem ser ferramentas visuais para a produzidas somente
418. tamento abstrato a ser implementado por cada inst ncia concreta que corresponde s variantes metodo setNext FeatureA comportamento FeatureASozinha SubFeatureA3 Se See SubFeatureA1 SubFeatureA2 E T R comportamento comportamento Sub feature A2 public class UmProduto public static void main String args FeatureA featureA new FeatureASozinha FeatureA subFeatureAl new SubFeatureAl FeatureA subFeatureA3 new SubFeatureA3 featureA setNext subFeatureAl subFeatureAl setNext subFeatureA3 Utilizar featureA normalmente featureA metodo Gerador PRO ODOANAHAOBPWNHEH c f fe c HO Figura 18 Uso do padr o Chain of Responsibility para or features A Figura 18 ilustra o uso do padr o Chain of Responsibility na implementa o de or features Para cada ponto de varia o no caso featureA cria se uma classe abstrata contendo um m todo principal metodo a ser chamado no produto Tamb m criado um m todo setNext que permite encadear outras inst ncias a esta Para cada variante featureA sozinha e sub features Al A2 e A3 cria se uma subclasse que implementa o comportamento espec fico da variante O gerador para combinar as features selecionadas cria uma inst ncia da feature principal linha 3 cria inst ncias das sub features selecionadas linhas 4 e 5 e faz o encadeamento linhas 6 e 7 Dessa forma ao se chamar o m
419. tanto mais pr ximos s necessidades organizacionais O processo de cria o dos geradores tamb m similar com 215 base em exemplos do c digo a ser gerado com a diferen a de que no Pulse MDD ele guiado pela identifica o de padr es e crit rios econ micos enquanto nesta tese o processo est centrado nos diferentes tipos de variabilidade A principal diferen a desta tese com rela o ao Pulse MDD que neste ltimo a preocupa o com o MDD come a somente na fase de projeto enquanto nesta abordagem argumenta se que ela deve come ar antes durante a an lise uma vez que os modelos de features possuem papel importante nesta defini o e normalmente precisam ser adaptados para refletir a exist ncia dos artefatos MDD Al m disso iniciando se na an lise a preocupa o com o MDD pode incluir a identifica o e divis o de subdom nios automatiz veis Segundo defende se nesta tese reconhecer esta divis o natural do dom nio um requisito importante para possibilitar o uso do MDD em cen rios pr ticos Deelstra et al 2003 discutem como uma abordagem para o desenvolvimento de linhas de produtos pode se beneficiar do desenvolvimento orientado a modelos Os autores argumentam que o MDD pode levar a v rios benef cios e apresentam como ele pode ser utilizado para representa o da variabilidade e deriva o autom tica de produtos O suporte variabilidade com o MDD atrav s de modelos do dom nio a exem
420. ternativas 128 Uso do padr o Chain of Responsibility para or features 129 Uso do padr o Decorator para or features 2 ee 130 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 Padr o visitante sendo aplicado implementa o de variabilidade baseada em feat res ce irea t T o E SD A DS a EE O OE we O a 131 Abordagem template sendo aplicada gera o de c digo baseada em features 132 Padr o camada fina de dados Ja 405 4 um he BS Le OY PE GES 133 Merging de geradores envolvendo modelos estruturais e comportamentais 136 Estrat gia de caracteriza o de subdom nios 147 Modelo de features do dom nio web de autoria de conteido 148 Defini o do metamodelo da DSL de autoria Web 2 151 Manuten o da consist ncia da implementa o de refer ncia 161 Compara o entre as m tricas de reutiliza o para o estudo do dom nio de autoria de conte do para a web acess ars pps pps PISA Ble So 189 Compara o entre as m tricas indiretas de reusabilidade para o estudo do dom nio de autoria de conte do para a web 0 189 Distribui es de instabilidade de m dulo nos diferentes tipos de artefatos produzidos com a abordagem no estudo de caso do dom nio de autoria de conte do para web ams sus he ae S ANSA o pd ee AD 190 Distribui es de complexidade ciclom t
421. tilizar software O desenvolvimento orientado a modelos surge como uma alternativa atraente neste cen rio elevando a import ncia de modelos dentro do ciclo de vida do software incorporando os como parte integrante do produto final por meio de t cnicas de modelagem e gera o de c digo Com isto parte da complexidade do software fica escondida dentro dos geradores protegendo os desenvolvedores reduzindo a incid ncia de erros aumentando a produtividade qualidade interoperabilidade e manutenibilidade dos artefatos produzidos Nesta disserta o defende se a tese de que o desenvolvimento orientado a modelos pode efetivamente aumentar e ou melhorar a reutiliza o de software e que para isso ele deve ser tratado de forma consistente dentro de um processo de engenharia de dom nio Em particular ele deve reconhecer que n o poss vel automatizar o dom nio todo Deve identificar os m ltiplos subdom nios com diferentes graus de automa o e gerenciar a sua integra o desde a an lise at a implementa o Para demonstrar esta tese apresentada uma abordagem orientada a modelos para reutiliza o de software com atividades que guiam o desenvolvedor durante a an lise projeto e implementa o do dom nio S o tamb m apresentados os resultados de uma avalia o envolvendo tr s estudos emp ricos realizados em ambiente acad mico e industrial que buscou determinar a viabilidade da abordagem e os benef cios que podem ser alcan ad
422. tipo de p gina Ina a a qq q a a e mm e ren n Figura 26 Defini o do metamodelo da DSL de autoria Web Sub atividade ID 2 2 Defini o da sintaxe abstrata No segundo passo as features identificadas s o analisadas de forma mais aprofundada para determinar como elas se relacionam entre si e se conceitos adicionais s o necess rios Estes conceitos adicionais s o descritos em um metamodelo que corresponde sintaxe abstrata da DSL Por exemplo a Figura 26B mostra o metamodelo obtido para o subdom nio de autoria web Elementos sombreados s o derivados diretamente do modelo de features Al m das features Autoria Tipo de documento e Relacionamento este metamodelo cont m os relacionamentos entre elas e novos conceitos como Autor e Campo Para auxiliar na defini o do metamodelo as seguintes regras podem ser utilizadas como guia e Uma feature normalmente uma feature de tecnologia de dom nio mapeada em um conceito da DSL Um conceito pode ser uma metaclasse em um metamodelo caso se trate de uma DSL visual ou uma regra de produ o em uma gram tica caso se trate de uma DSL textual e Sub features podem ser mapeadas como propriedades do conceito que as cont m Podem ser metaatributos em um metamodelo ou uma regra de produ o ou atributo gramatical 152 e Sub features podem tamb m ser mapeadas como conceitos separados com rela es parte de adicionais sendo utilizadas para representar a cont
423. tivos 3 N o existe conte do no local solicitado que seja associado string informada 3 1 Aplica o exibe mensagem informando que n o foi encontrado nenhum conte do no local especificado Featuresrelacionadas Navega o Busca Busca avan ada Cen riosafetados CMO001 Realizar busca simples Quadro 5 Exemplo de caso de mudan a para a feature alternativa de busca avan ada Neste exemplo diferentemente do exemplo anterior a intersec o entre os dois cen rios maior pois este cen rio descreve uma alternativa ao outro e quase todos os mesmos passos s o seguidos Neste caso recomenda se fatorar os dois cen rios levando cria o de um terceiro que contenha as intera es em comum para facilitar o entendimento ECKLUND JR DELCAMBRE FREILING 1996 Neste exemplo isto poderia ser atingido com a cria o de um terceiro cen rio CM003 Exibir resultados da busca que condensa os passos 3 e 4 descritos no fluxo normal dos cen rios anteriores assim como os fluxos alternativos Em termos de formato tanto casos de uso como casos de mudan a s o praticamente id nticos A diferen a que conforme descrito no pr prio nome um caso de mudan a introduz uma altera o em um cen rio que considerado normal tamb m chamado de base comum COPLIEN 2000 A defini o do que um comportamento normal em um dom nio altamente subjetiva e escolhas diferentes podem levar a dif
424. to R Segundo a equipe a abordagem permitiu atacar problemas recorrentemente enfrentados pela equipe tais como o alto n vel de retrabalho procurando c digos e testando cada mudan a no dom nio a exist ncia de arquivos que nunca s o utilizados mas que s o inclu dos nos produtos por conveni ncia o que acaba por confundir os desenvolvedores e causando problemas de manuten o e a necessidade de busca por links que precisam removidos dependendo da configura o de produtos adquiridos pelo cliente A automa o conseguida com o MDD permitiu reduzir estes problemas de forma que n o vinha sendo conseguida por falta de tempo e dificuldades em desenvolver uma solu o que atendesse a m ltiplos clientes ao mesmo tempo Por exemplo a equipe citou alguns chamados recentes enviados por clientes via helpdesk referentes altera o urgente de dados dos certificados emitidos nos eventos por n o estarem de acordo com o exigido ou desejado Sem o MDD era necess rio criar novo c digo toda vez que um chamado deste tipo era feito Ap s este projeto que envolveu a implementa o do subdom nios de certificados este trabalho feito diretamente no modelo P Quais foram as desvantagens de se utilizar a abordagem de MDD no desenvolvimento R A equipe citou principalmente as dificuldades de implementa o dos geradores de c digo pois os mesmos misturam c digo PHP dos produtos com c digo JAVA e marca es do JET em um mesmo arqu
425. to Ela gera c digo execut vel Se n o pode ser adaptada para gerar c digo Quanto esfor o necess rio para se utilizar a ferramenta neste projeto e Foi conduzido um projeto piloto para este subdom nio utilizando se uma linguagem de modelagem e ferramenta para gera o de c digo Para determinar o n vel de confian a de forma mais sistem tica o analista do dom nio pode desenvolver uma m trica envolvendo estas e outras poss veis quest es que possam surgir Uma maneira simples desenvolver um question rio com estas quest es atribuindo um peso para cada resposta A soma de todos os valores o n vel de confian a O analista do dom nio deve consultar todos os stakeholders quando definir esta m trica uma vez que existem diferentes fatores a serem considerados Dependendo do cen rio diferentes situa es podem requerer valores diferentes Por exemplo para sistemas cr ticos razo vel utilizar somente linguagens e ferramentas bem conhecidas e portanto maiores pesos podem ser atribu dos para estas quest es Em projetos com prazos mais curtos de entrega esta tamb m pode ser a nica op o Por m em projetos com mais tempo dispon vel os valores podem ser ajustados para incluir mais subdom nios j que h mais tempo para desenvolver ferramentas e linguagens de modelagem Este tamb m o caso de dom nios mais abrangentes Sub atividade AD 3 5 Documenta o dos candidatos a subdom nio Nesta ati
426. transformation track Dijon Bourgogne France s n 2006 p 1188 1195 KANG K et al Feature Oriented Domain Analysis FODA Feasibility Study S1 1990 Technical Report CMU SEI 90 TR 21 Carnegie Mellon University Software Engineering Institute KANG K et al FORM A Feature Oriented Reuse Method with domain specific reference architectures Annals of Software Engineering Notes v 05 p 143 168 1998 KANG K LEE J DONOHOE P Feature oriented product line engineering JEEE Software v 19 n 04 p 58 65 2002 KEEPENCE B MANNION M Using patterns to model variability in product families JEEE Software v 16 n 4 p 102 108 1999 KETTEMANN S MUTHIG D ANASTASOPOLOUS M Product Line Implementation Technologies Component Technology View S 1 March 2003 Fraunhofer IESE Tech Report 015 03 E 243 KICZALES G et al Aspect oriented programming In J st European Conference Object Oriented Programming ECOOP 97 Finland Springer Verlag 1997 LNCS v 1241 p 220 242 KIM M YANG H PARK S A domain analysis method for software product lines based on scenarios goals and features In Tenth Asia Pacific Software Engineering Conference APSEC Thailand s n 2003 p 126 136 KIRCHER M JAIN P Pattern Oriented Software Architecture Volume 3 Patterns for Resource Management S 1 John Wiley amp Sons 2003 KLEPPE A WARMER J BAST W MDA Explained The Model Dri
427. trizes arquiteturais BASS CLEMENTS KAZMAN 2003 e s o respons veis por moldar a arquitetura de forma a atender a todos os requisitos da melhor forma poss vel Nos contextos de reutiliza o e MDD as diretrizes devem incluir obrigatoriamente as variabilidades em forma de features e DSLs e a exist ncia de artefatos do MDD como DSLs e transforma es de software e Selecionar definir t ticas e padr es o projeto arquitetural deve cobrir as diretrizes arquiteturais em forma de t ticas e padr es que contemplem solu es para cada requisito Um padr o consiste em uma solu o comprovadamente bem sucedida para determinados tipos de problema com um contexto bem definido Por tr s de um padr o existem 119 uma ou mais t ticas que representam as maneiras utilizadas pelo padr o para resolver o problema e Definir a arquitetura e componentes o projeto do dom nio deve incluir uma defini o da arquitetura do dom nio Junto com a arquitetura devem ser especificados os componentes do dom nio incluindo componentes de software tradicionais servi os e tamb m artefatos do MDD como DSLs transforma es e geradores de c digo e e Documentar a arquitetura como objetivo desta fase deve ser produzida toda a documenta o referente arquitetura projetada visando servir de guia para a fase de implementa o Esta fase de projeto inspirada nos m todos descritos por Almeida et al 2007b deBaud e Sc
428. truir as ferramentas necess rias para oferecer um suporte eficiente para DSLs FOWLER 2005 Esse custo depende da forma escolhida para se implementar o suporte para a DSL Ap s a an lise do dom nio e projeto da DSL existem duas alternativas principais para se implementar esse suporte 1 Compilador interpretador a forma mais comum de se implementar uma DSL envolve construir uma biblioteca que implementa as no es sem nticas e projetar e implementar um compilador que traduza programas na DSL para chamadas a essa biblioteca DEURSEN KLINT VISSER 2000 Esse tipo de abordagem tamb m conhecido como DSL externa FOWLER 2005 e 2 Linguagem embutida nesse tipo de DSL tamb m conhecida como DSL interna FOWLER 2005 uma linguagem de programa o gen rica estendida com conceitos e opera es do dom nio A principal vantagem que o pr prio compilador da linguagem base pode ser utilizado Em contrapartida a expressividade da linguagem estendida limitada ao poder expressivo da linguagem base DEURSEN KLINT VISSER 2000 Por exemplo a UML OMG 2007 com seu mecanismo de extens o possibilita a cria o de linguagens de modelagens espec ficas de forma bastante razo vel Os perfis UML OMG 2006a s o um exemplo desse poder A linguagem LISP ou outras linguagens adapt veis tamb m s o exemplos dessa possibilidade J a linguagem Java n o possui um mecanismo simples de extens o dificultando o uso de lin
429. trutura e seu escopo Em particular nota se que a abordagem est mais focada nas pr ticas relacionadas engenharia deixando de lado a maioria das atividades de suporte e planejamento que s o importantes mas que est o fora do escopo desta tese Foi tamb m apresentado um poss vel modelo de processo para a utiliza o da abordagem de reutiliza o orientada a modelos Esta apenas uma sugest o que busca combinar as atividades de forma natural O foco deste modelo a iteratividade for ada pelo aspecto investigativo que deriva da incerteza sobre as possibilidades de automa o dos subdom nios Por m este modelo pode ser adaptado para refletir outras necessidades da organiza o de forma a refor ar aspectos que aqui foram ignorados Por exemplo como esta tese tem foco mais t cnico foram omitidos mais detalhes sobre gerenciamento de riscos atividades de gerenciamento e controle melhoria do processo uso de m tricas entre outros pontos igualmente importantes em um projeto de software A seguir as tr s fases da abordagem s o apresentadas em maiores detalhes em cap tulos separados e com cada atividade sendo descrita de modo sequencial visando facilitar seu entendimento 85 5 An lise de dom nio orientada a modelos A an lise de dom nio envolve a identifica o dos principais conceitos e elementos de um dom nio e a determina o de seu escopo isto o que ser inclu do e o que ser exclu do do
430. ualidade da organiza o devem desenvolver e documentar os objetivos planos e procedimentos de avalia o durante o ciclo de vida Finalmente o pessoal envolvido deve ser apropriadamente treinado nas pol ticas pr ticas e procedimentos de avalia o A abordagem n o define nenhuma atividade com este objetivo AP13 Avalia o da qualidade dos artefatos envolve a defini o de um modelo de qualidade que define pol ticas objetivos e atributos relacionados qualidade dos artefatos reutiliz veis assim como um processo de avalia o dos mesmos Avalia o de qualidade n o faz parte da abordagem AP14 Engenharia de Aplica es engloba as pr ticas de desenvolvimento com a reutiliza o de artefatos previamente constru dos Envolve a busca sele o adapta o e integra o dos artefatos reutiliz veis Assume se que estes artefatos tenham sido previamente testados e portanto nesta rea est o somente as pr ticas de testes de integra o e testes de sistema Tamb m envolve a estimativa de esfor o de reutiliza o uma vez que pode ser mais vantajoso construir um artefato do zero do que reutilizar um artefato que exige grande esfor o de adapta o O desenvolvimento com reutiliza o est fora do escopo desta pesquisa e portanto a abordagem n o possui nenhuma atividade relacionada a esta pr tica e N vel 4 Sistem tico este o n vel mais avan ado que uma organiza o pode c
431. ulos s o identificados formando a arquitetura do 78 dom nio Trata se de um processo de refinamento dirigido por padr es A divis o em m dulos ocorre de acordo com a instancia o de um ou mais padr es que atendem s diretrizes arquiteturais O projeto se inicia com uma divis o principal envolvendo todo o dom nio Esta divis o produz os m dulos principais do sistema Por exemplo se for adotado o padr o em camadas BUSCHMANN etal 1996 a primeira divis o resulta na identifica o das camadas do dom nio Se for adotado o padr o MVC Model View Controller BUSCHMANN etal 1996 a primeira divis o resulta na identifica o dos elementos de modelo de vis o e de controle e assim por diante As itera es seguintes refinam cada m dulo de acordo com o padr o escolhido Por exemplo ao se aplicar o padr o Observer GAMMA et al 1995 em um m dulo ser o identificados novos m dulos ou classes como o Sujeito Sujeito Concreto Observador e Observador Concreto No caso desta abordagem focada em reutiliza o os padr es visam al m de identificar novos m dulos adicionar o suporte variabilidade prevista durante a an lise Al m disso tendo foco tamb m no MDD cada refinamento identifica n o somente m dulos de software convencional como classes e m todos mas tamb m elementos como transforma es e geradores de c digo al m de DSLs e ferramentas de modelagem Todos estes tamb m fazem parte d
432. ulos s o refinados possivelmente resultando na identifica o de novos m dulos e relacionamentos e 5 Atividade PD 5 Avalia o arquitetural esta atividade busca avaliar a arquitetura projetada frente aos seus requisitos A cada itera o novas arquiteturas produzidas s o avaliadas e o resultado da avalia o serve de entrada para uma nova itera o no ciclo de projeto O resultado das sucessivas itera es no ciclo de projeto a produ o de uma arquitetura para o dom nio capaz de dar suporte s variabilidades identificadas durante a an lise Dependendo do n mero de m dulos identificados s o necess rias mais ou menos itera es A tend ncia que o n mero de itera es no ciclo de projeto diminua a cada itera o do ciclo principal uma vez que restam cada vez menos m dulos para serem refinados 4 4 3 Ciclo de implementa o do modelo de processo produ o dos artefatos reutiliz veis e documenta o A fase de implementa o tamb m possui iteratividade que ocorre em um ciclo menor composto pelas atividades ID 2 ID 3 e ID 4 As itera es desta fase s o intr nsecas a qualquer atividade de codifica o exigindo re trabalho medida que a implementa o avan a No caso desta abordagem a iteratividade visa coletar informa es durante a codifica o realimentando a atividade de defini o das linguagens espec ficas de dom nio Isto porque no contexto do MDD uma DSL n o somente um m
433. uma abordagem top down que utiliza os modelos de features para definir as DSLs para cada subdom nio A seguir as DSLs s o refinadas e as transforma es s o constru das Atividade ID 3 utilizando uma abordagem bottom up e uma implementa o de refer ncia como ponto de partida Esta implementa o de refer ncia ent o transformada em um framework de dom nio Atividade ID 4 contendo classes e componentes reutiliz veis que d o suporte para algumas das variabilidades Finalmente os artefatos constru dos s o documentados Atividade ID 5 de forma a facilitar seu entendimento manuten o e reutiliza o A seguir estas atividades s o descritas de forma detalhada Atividade ID 1 Caracteriza o da variabilidade dos subdom nios Pap is implementador do dom nio Especialista do dom nio Entradas PT 3 Validado Modelagem do dom nio PT4 Validado Candidatos a subdom nio PT 5 Hist rico de decis es sobre inclus o exclus o de subdom nios PT 9 Avaliado Projeto do dom nio Sa das PT 10 subdom nios caracterizados Descri o um dom nio pode ser dividido em v rios subdom nios cada um com um potencial de automa o Durante a an lise esta divis o se inicia com a identifica o de candidatos a subdom nio Atividade AD 3 Durante o projeto s o identificadas as diretrizes arquiteturais que apresentam mais detalhes sobre o tipo de variabilidade de cada subdom nio Atividade PD 2 Nesta atividade c
434. umenta o e empacotamento desses artefatos Essa justamente uma das fases da abordagem que visa implementar um dom nio utilizando t cnicas do MDD e Nivel 3 Definido neste n vel o principal foco de engenharia o suporte variabilidade Enquanto no n vel 2 a preocupa o era aumentar o n vel de reutiliza o de artefatos individuais aqui o foco oferecer um suporte global variabilidade do dom nio principalmente com as pr ticas de an lise e projeto do dom nio Tamb m neste n vel introduz se a preocupa o com o processo de desenvolvimento de uma organiza o treinamento e a introdu o de uma unidade dedicada reutiliza o Preocupa es com a qualidade dos artefatos tamb m come am a aparecer neste n vel AP5 Controle e monitoramento do processo de reutiliza o deve ser realizado atrav s de um conjunto de mecanismos e m tricas que determinam o status 273 das atividades e um conjunto de pol ticas e um plano de a es respons veis pelo controle do processo A abordagem n o define nenhum mecanismo ou atividade para controle e monitoramento do processo 7 AP6 Integra o com o ciclo de vida do software s o definidas atividades sub atividades e produtos de trabalho institucionalizados para a organiza o com base em um modelo de refer ncia Tamb m importante a defini o de um procedimento para a coopera o entre os desenvolvedores e a equipe de reutiliza o
435. uns padr es e formatos voltados documenta o de software em geral PHOHA 1997 como o padr o ANSI ANS 10 3 1995 para documenta o de software e o RAS Reusable 164 Asset Specifications ou Especifica es de Artefatos Reutiliz veis VOTH 2004 Estes podem ser teis para a documenta o de diferentes tipos de software Com base nestes e em outros trabalhos relacionados documenta o de componentes SILVA WERNER 1996 KOTULA 1998 TAULAVUORI NIEMELA KALLIO 2004 BASILI ABD EL HAFIZ 1996 a presente abordagem prop e um formato espec fico para a documenta o al m de alguns princ pios P Hipertexto O hipertexto mostrou se uma t cnica eficiente para a documenta o Por exemplo ajuda a aumentar o conhecimento que engenheiros de software adquirem ao percorrer reposit rios de componentes de software ISAKOWITZ KAUFFMAN 1996 Tamb m facilita o processo de navega o atrav s da informa o al m de ser um formato j familiar maioria dos usu rios Assim sempre que poss vel a documenta o deve ser apresentada como hipertexto P Coment rios embutidos no c digo fonte A documenta o deve estar sempre consistente e atualizada com rela o ao c digo fonte Embutindo se a documenta o no c digo fonte mais f cil atualiz la sempre que forem feitas mudan as no c digo j que ambos est o no mesmo lugar P3 Automa o No contexto do MDD poss vel gerar junto com c digo dif
436. us es relevantes 10 3 Limita es e Trabalhos futuros Foram tamb m identificadas como subproduto desta pesquisa oportunidades para trabalhos futuros seja para complementar esta pesquisa explorando limita es e ou aspectos que n o puderam ser investigados nesta tese ou para iniciar novas investiga es em reas 230 identificadas como sendo deficit rias de contribui es Assim os seguintes pontos podem ser investigados futuramente e Desenvolvimento com reutiliza o a presente abordagem n o prev atividades para o desenvolvimento com reutiliza o Apesar de os resultados da engenharia de dom nio poderem beneficiar o desenvolvimento de software h uma s rie de desafios envolvidos na reutiliza o dos produtos da ED Assim a sequ ncia mais direta deste trabalho a investiga o do processo de desenvolvimento com reutiliza o ou seja como produzir aplica es que reutilizam os artefatos desenvolvidos com a abordagem desta tese de forma a maximizar a reutiliza o e fazer uso efetivo das linguagens transforma es e geradores de c digo produzidos Neste cen rio um processo semelhante envolvendo an lise projeto e implementa o deve ser realizado Por m este trabalho deve definir exatamente os passos e atividades necess rios para que os esfor os realizados durante a engenharia do dom nio possam ser reutilizados como por exemplo ao realizar a an lise dos requisitos deve se considerar que j e
437. use Reference Model Modelo de Refer ncia em Reutiliza o RUP Rational Unified Process Processo Unificado da Rational SAAM Software Architecture Analysis Method M todo de Avalia o de Arquitetura de Software SCV Scope Commonality and Variability Escopo Comunalidade e Variabilidade SPC Software Productivity Consortium Cons rcio de Produtividade de Software SVN Acr nimo normalmente utilizado como refer ncia ao sistema SubVersioN para controle de vers es UML Unified Modeling Language Linguagem de Modelagem Unificada XMI XML Metadata Interchange Interc mbio de Metadados em XML Sum rio Introdu o 1 2 Defini o do EsCOpO 2 22 bee Hee PR ag R EEE E ROE E CA 1 3 Estrutura da disserta o es si eai E e e ID E OR Conceitos envolvidos 2 1 Reutiliza o de software essas a a8 ale a wd ADEUS wae eS ahs 2 2 Desenvolvimento orientado a modelos 00 4 2 3 Considera es finais suas E a E RISE e RS RR Reutiliza o de software e desenvolvimento orientado a modelos ZL An lise SOV os So ates ok gusta toe a pega geo pu dra Go alee ue es 3 2 Implementa o da variabilidade 04 3 3 Copsiderac es PAIS sei don a E Bee He etn ES Vis o geral da abordagem 4 1 Objetivo da abordagem 0 2000 000 4 2 Defini o da abordagem vs ses ace ete we wa be Yea es 43 Estrutura da abordagem 23 4 4 4 os a eee ae aa ew gra ee ah 4A MIGdElG de Processo usage
438. va se a exist ncia de diversos arquivos e trechos de c digo parecidos sendo produzidos por geradores Vale ressaltar que esta repeti o n o poderia ser facilmente resolvida atrav s de componentes ou outras estruturas de c digo uma vez que apesar de serem basicamente repetidos os trechos diferem em muitos pontos e s o resultados de in meros par metros e informa es sobre o dom nio Como resultado a tentativa de se implementar componentes gen ricos que realizam estas variabilidades iria resultar em software mais complexo e dif cil de ser mantido A nica op o portanto seria copiar os trechos parecidos e modific los manualmente abordagem seguida no desenvolvimento tradicional Em alguns casos pode se tentar aplicar t cnicas de refatora o de c digo FOWLER et al 1999 mas estas s o limitadas a somente alguns tipos de modifica es no c digo Analisando os artefatos produzidos nota se que na maioria deles exatamente esta tarefa de c pia e modifica o manual que est sendo automatizada neste caso A diferen a entre os n veis de reutiliza o com e sem a abordagem cerca de 50 corresponde aproximadamente porcentagem de reutiliza o obtida por gera o 47 03 Ou seja o que est sendo gerado o c digo que implementa a variabilidade que n o pode ser automatizada em componentes e foi constru do manualmente sem a abordagem Outro dado que refor a este ind cio o aumento da complexidad
439. ve programming a automa o da manufatura de produtos intermedi rios e finais i e componentes e aplica es CZARNECKI EISENECKER 2000 Essa defini o resume o conceito de programa o generativa que vem sendo utilizado desde os prim rdios da computa o Significa que parte ou a totalidade dos artefatos produzidos durante o ciclo de vida do software gerada automaticamente Por exemplo compiladores que utilizam como entrada um programa em uma linguagem de programa o e geram como sa da o c digo execut vel para uma plataforma est o entre os primeiros exemplos de uso da programa o generativa Outro exemplo s o os construtores de interface tais como aqueles presentes em softwares como Microsoft Visual Studio e NetBeans O desenvolvedor especifica a interface visualmente e todo o c digo que a implementa automaticamente gerado Caso precise realizar alguma modifica o o desenvolvedor a realiza diretamente no editor visual e o c digo que reflete essa mudan a gerado novamente A programa o generativa pode ser utilizada em outras etapas do ciclo de vida do software Pode se gerar casos de teste esquemas de banco de dados ou mesmo programas completos Os benef cios dessa abordagem s o bvios poupa se o tempo gasto em atividades repetitivas como tarefas de implementa o de infraestrutura aproveitando o em atividades mais importantes como an lise e projeto Al m de proporcionar os
440. ve se incluir informa es sobre 1 O racioc nio por tr s das regras de transforma o uma vez que as linguagens de transforma o nem sempre s o intuitivas o suficiente para serem compreendidas sem informa o adicional 2 Metamodelos ou DSLs de origem e destino 3 Detalhes sobre o seu desenvolvimento tais como as linguagens tecnologias ou frameworks utilizados e 166 4 Especifica o dos par metros necess rios para a transforma o e Para geradores de c digo deve se incluir informa es sobre 1 Coment rios no pr prio c digo dos geradores sobre os mapeamentos com as DSLs de entrada 2 Metamodelos ou DSLs de origem 3 Linguagens de destino 4 Descri o e racioc nio do c digo gerado 5 Detalhes sobre o seu desenvolvimento tais como as linguagens tecnologias ou frameworks utilizados 6 Especifica o dos par metros necess rios para a gera o de c digo importante ressaltar que a maioria das informa es necess rias para esta documenta o foi sendo produzida ao longo do processo de engenharia de dom nio Por exemplo os metamodelos das DSLs o mapeamento entre DSLs e c digo cruzamento entre diferentes DSLs entre outras informa es foram produzidos durante o processo de an lise projeto e implementa o Neste caso trata se somente de um processo de empacotamento da informa o e possivelmente algum refinamento Em outros casos como a descri o e racioc nio do c dig
441. vel e m dulos com IM maior do que 85 possuem boa manutenibilidade Esta m trica normalmente utilizada em artefatos de c digo fonte mas tamb m pode ser aplicada a geradores de c digo uma vez que os mesmos tamb m possuem operadores e operandos Geradores baseados em templates que s o um dos focos desta abordagem possuem c digo embutido e marca es especiais que representam opera es simples como condi es e la os As seguintes regras s o utilizadas para c lculo do volume Halstead V de um gerador baseado em template e Vari veis trechos de c digo cont nuo e constantes s o consideradas operandos e Marca es respons veis por uma consulta como uma sele o de elementos de um modelo ou impress o de um determinado valor s o consideradas operadores 177 e Marca es condicionais e de la os s o considerados operadores e e Trechos de c digo embutido s o analisados da mesma forma que c digo fonte tradicional Esta m trica n o pode ser aplicada a modelos uma vez que estes n o necessariamente cont m elementos que podem ser associados com operandos e operadores Nestes casos devem ser utilizadas m tricas espec ficas para modelos Conforme demonstrado por Genero et al 2007 e por Genero Poels e Piattini 2008 a manutenibilidade de um modelo determinada principalmente por sua compreensibilidade Neste sentido os autores identificaram no contexto da modelagem Entidade Relacionamento e d
442. ven Architecture Practice and Promise S 1 Addison Wesley 2003 Object Technology Series KLEPPE A G A language description is more than a metamodel In Fourth International Workshop on Software Language Engineering Nashville USA S 1 s n 2007 ISBN not assigned KNODEL J et al An efficient migration to model driven development MDD Electronic Notes in Theoretical Computer Science v 137 n 3 p 17 27 2005 KOLTUN P HUDSON A A reuse maturity model In 4th Annual Workshop on Software Reuse Hemdon Virginia Center for Innovative Technology s n 1991 KOTULA J Using patterns to create component documentation IEEE Software v 15 n 2 p 84 92 1998 KRUCHTEN P The 4 1 view model of architecture JEEE Softw IEEE Computer Society Press Los Alamitos CA USA v 12 n 6 p 42 50 1995 ISSN 0740 7459 KRUEGER C Software reuse ACM Computing Surveys v 24 n 02 p 131 183 1992 KURTEYV I et al Model based DSL frameworks In TARR P L COOK W R Ed OOPSLA Companion S 1 ACM 2006 p 602 616 ISBN 1 59593 491 X Dispon vel em lt http doi acm org 10 1145 1176617 1176632 gt Acesso em 14 jun 2009 LANGE C CHAUDRON M An empirical assessment of completeness in uml designs In Proceedings of the 8th Conference on Empirical Assessment in Software Engineering EASE04 S 1 s n 2004 p 111 121 LANGE C F J CHAUDRON M R V Managing model quality in UML
443. vez que os resultados indicaram que a reusabilidade dos artefatos pode ser maior ou menor utilizando se a abordagem Com rela o s hip teses Hoc e Hog os dados obtidos possuem ind cios que ap iam a rejei o uma vez que os participantes dos estudos perceberam benef cios com a abordagem e n o tiveram dificuldades significativas no aprendizado Mesmo para as hip teses nulas com ind cios de rejei o n o se pode afirmar que as hip teses alternativas apresentadas na Se o 8 1 2 s o verdadeiras Ou seja a abordagem aparentemente favorece a reutiliza o mas pode ser que existam projetos onde ela n o acrescente benef cios ou mesmo cause dificuldades significativas de aprendizado e utiliza o O que parece ser uma conclus o mais razo vel que a abordagem pode aumentar a quantidade em termos de LOC Mas ela n o aumenta de forma absoluta os valores das m tricas de complexidade e dificuldade de manuten o conforme percebido no estudo do dom nio Web Tampouco ela as reduz conforme percebido no estudo do dom nio de computa o em nuvem Aparentemente h uma tend ncia a produzir artefatos com instabilidade complexidade e dificuldade de manuten o acima da m dia mas seguindo uma constante e dependendo das caracter sticas do dom nio isto pode ser vantajoso ou n o Este efeito ilustrado na Figura 42 Assim uma poss vel hip tese alternativa mais realista deve considerar as diferentes condi es
444. vidade o analista do dom nio documenta os subdom nios identificados incluindo toda informa o coletada nos passos anteriores as features envolvidas linguagens e ferramentas e o n vel de confian a Na pr tica a maior parte da documenta o vai sendo constru da durante o processo e portanto esta atividade realizada em paralelo com as anteriores Os Quadros 6 e 7 ilustram exemplos de documenta o obtida nesta atividade O Quadro 6 mostra a documenta o do subdom nio de navega o onde s o informadas a descri o as features envolvidas linguagens e ferramentas identificadas O Quadro 7 mostra a documenta o do n vel de confian a dos subdom nios identificados Neste exemplo somente quatro perguntas foram utilizadas com peso atribu do conforme indicado no quadro Aqui o analista tamb m descreve a intera o entre o candidato a subdom nio e o restante do dom nio Neste ponto esta descri o deve ser focada na coopera o em alto n vel entre as features com o objetivo de ajudar na decis o de investir na automa o do subdom nio ou n o Em est gios posteriores caso seja decidido que este subdom nio ser automatizado esta 106 Candidato a subdom nio Navega o Descri o Este sub dom nio envolve a navega o de uma aplica o web com as p ginas e links e todo conte do vis vel ao usu rio final Features Navega o Conte do P gina Link Formul rio Relat rio
445. w eclipse org articles Article JET jet tutoriall html gt Acesso em 14 jun 2009 POULIN J Measuring software reusability In Proceedings of the 3rd IEEE International Conference on Software Reuse ICSR Advances in Software Reusability Rio de Janeiro Brazil S 1 s n 1994 p 126 138 248 POULIN J CARUSO J HANCOCK D The business case for software reuse IBM Systems Journal v 32 n 4 p 567 594 1993 POULIN J S CARUSO J M A reuse metrics and return on investment model In PRIETO DIAZ R FRAKES W B Ed Proceedings of 2nd ACM IEEE International Workshop on Software Reusability S 1 IEEE Computer Society Press ACM Press 1993 p 152 167 ISBN 0 8186 3130 9 0 8186 3132 5 0 8186 3131 7 PRESSMAN R S Software Engineering A Practitioner s Approach S1 McGraw Hill 2005 PRIETO DIAZ R Domain analysis An introduction ACM SIGSOFT Software Engineering Notes v 15 n 2 p 47 54 1990 PRIETO DIAZ R Making software reuse work An implementation model ACM SIGSOFT Software Engineering Notes v 16 n 3 p 61 68 1991 PRIETO DIAZ R Status report Software reusability IEEE Software v 10 n 3 p 61 66 1993 IEEE Computer Society Press Los Alamitos CA USA PYSTER A B BARNES B H The software productivity consortium reuse program In COMPCON 88 Digest of Papers Thirty Third IEEE Computer Society International Conference San Francisco California USA IEEE Computer
446. xistem modelos de features casos de uso e de mudan a para o dom nio Como identificar quais modelos do dom nio se adequam aos requisitos da aplica o Qual o procedimento a ser realizado caso exista um requisito que n o foi inclu do na an lise do dom nio Vale a pena tentar renegociar com o cliente os requisitos da aplica o de forma a promover maior reutiliza o Al m disso tanto o projeto como a implementa o das aplica es devem considerar poss veis adapta es e ou inser es de novos artefatos Neste contexto o controle de configura o deve ser uma atividade indispens vel e Replica o dos estudos emp ricos outra limita o desta tese a avalia o Sabe se que dif cil realizar experimentos em engenharia de software visto que h uma s rie de fatores a serem controlados Por exemplo as m tricas utilizadas n o s o uma medida precisa da reutiliza o e reusabilidade dos artefatos produzidos Al m disso foi realizada somente uma avalia o dos produtos artefatos da abordagem n o havendo preocupa o com a avalia o do processo Todos estes fatores contribuem para que a validade dos resultados seja questionada Assim visando melhorar a validade das conclus es pode se realizar novos experimentos envolvendo a defini o mais precisa dos seus elementos e operacionalizando os por exemplo com equipes maiores Estes trabalhos poderiam ser realizados inicialmente como inicia o cient fica poste
447. xto envolvendo gera o de c digo pode se argumentar que o uso do tamanho em linhas de c digo nas m tricas pode distorcer os resultados uma vez que geradores de c digo normalmente produzem c digo mais denso MODELWARE 2006c No entanto vale ressaltar que nesta abordagem a constru o dos geradores feita a partir de uma implementa o de refer ncia ou seja o c digo gerado segue os mesmos padr es conven es e formato utilizados pelos programadores humanos Neste contexto a compara o v lida MODELWARE 2006c e 2 Estas m tricas s o aplicadas somente ao c digo fonte n o sendo teis para elementos 174 de modelagem Como o objetivo comparar a quantidade de conhecimento que foi reutilizado na constru o do software final a compara o dos c digos razo vel uma vez que o tamanho de um m dulo reflete de forma indireta a quantidade de conhecimento ali encapsulado Esse segundo ponto s v lido para a quest o Q Na quest o Q2 discutida a seguir os artefatos do MDD como modelos transforma es e geradores de c digo precisam ser avaliados quanto aos seus atributos de qualidade relacionados reutiliza o e portanto devem ser inclu dos nas medi es Quest o Q2 Os artefatos de software produzidos com a abordagem s o mais reutiliz veis do que aqueles produzidos em uma abordagem n o orientada a modelos Conforme discutido anteriormente as m tricas para reutiliza o M1 M2
448. za o ENG16 Verificar e validar produtos com base nos modelos a verifica o e valida o realizada atrav s de modelos para teste e valida o Estes modelos e seus metamodelos correspondentes capturam os requisitos do sistema e a verifica o ocorre diretamente nos modelos Desta forma erros s o detectados e corrigidos diretamente nos modelos Verifica o e valida o de modelos est o fora do escopo da abordagem PJM6 Estabelecer e manter artefatos de modelagem de software estrat gicos para o MDD consiste na identifica o dos artefatos de modelagem modelos transforma es etc que s o relacionados com a estrat gia de MDD organizacional na prioriza o destes artefatos com rela o sua import ncia frente aos objetivos estrat gicos no agrupamento destes artefatos em diferentes categorias e na cria o armazenamento e monitoramento destes artefatos estrat gicos A abordagem n o cont m nenhuma atividade neste sentido PJM7 Promulgar o modelo de processo do projeto consiste na cria o de uma inst ncia de um processo para um projeto em particular no sentido de atribuir recursos para os pap is das tarefas do projeto estabelecer a dura o das tarefas etc As decis es s o feitas pelo gerente de projeto seguindo diretrizes organizacionais Ferramentas de modelagem e suporte tamb m podem ser integradas em um ambiente de execu o capaz de orquestrar a execu o da inst ncia do processo O
449. zados PT 11 Inicial Linguagens espec ficas de dom nio PT 12 Inicial Suporte ferramental para DSLs PT 5 Hist rico de decis es sobre inclus o exclus o de subdom nios PT 9 Avaliado Projeto do dom nio ID 2 Defini o das DSLs e do suporte PT 3 Validado Modelagem do dom nio PT 11 Inicial Linguagens ferramental top down PT 4 Validado Candidatos a subdom nio espec ficas de dom nio ID 2 1 Identifica o das features iniciais PT 5 Hist rico de decis es sobre PT 12 Inicial Suporte ferramental da DSL inclus o exclus o de subdom nios para DSLs ID 2 2 Defini o da sintaxe abstrata PT 9 Avaliado Projeto do dom nio ID 2 3 Defini o da sintaxe concreta PT 10 Subdominios caracterizados ID 2 4 Defini o da integra o inter DSL ID 2 5 Constru o da ferramenta de modelagem espec fica de dom nio ID 3 Desenvolvimento das transforma es PT 3 Validado Modelagem do dom nio PT 11 Refinado Linguagens e refinamento das DSLs bottom up PT 4 Validado Candidatos a subdom nio espec ficas de dom nio ID 3 1 Desenvolvimento da PT 5 Hist rico de decis es sobre PT 12 Refinado Suporte ferramental para DSLs PT 13 Transforma es do dom nio PT 14 Implementa o de refer ncia ID 4 Desenvolvimento do framework do dominio PT 14 Implementa o de refer ncia PT 15 Framework do dom nio ID 5 Documenta o do dom nio PT 11 Refinado dominio PT 12 Refinado Suporte ferramen
450. zido uma vez que grande parte do c digo gerado e fica al m do alcance do desenvolvedor e Complexidade os artefatos necess rios para uma abordagem baseada em modelos como por exemplo ferramentas de modelagem transforma es e geradores de c digo introduzem complexidade adicional ao processo pois tratam se de artefatos inerentemente mais dif ceis de construir e manter e Desempenho apesar de algumas otimiza es poderem ser realizadas em n vel mais alto de abstra o a regra geral que geradores acabam incluindo muito c digo desnecess rio e portanto o resultado pode n o apresentar desempenho timo quando comparado com c digo escrito m o e Curva de aprendizado o desenvolvimento dos artefatos espec ficos do MDD exigem profissionais com habilidades na constru o de linguagens ferramentas de modelagem transforma es e geradores de c digo O aprendizado destas t cnicas apesar de n o ser extremamente dif cil requer um treinamento dedicado e 44 e Alto investimento inicial assim como a reutiliza o de software o MDD depende de maior investimento inicial uma vez que a constru o de uma infraestrutura de reutiliza o orientada a modelos requer mais tempo e esfor o Por m os ganhos posteriores s o significativos fazendo com que este investimento tenha retorno em poucas intera es 2 2 1 2 Principais elementos do MDD os principais elementos necess rios para essa abordagem e como
451. zir c digo que n o precisa ser manualmente completado O 137 comportamento pode ser especificado por modelos espec ficos como m quinas de estados ou mesmo diretamente em c digo fonte na linguagem de destino Um gerador espec fico merger ent o traduz e ou copia estes trechos para os locais designados das estruturas geradas Atividade PD 4 Aplica o dos padr es arquiteturais e refinamento dos m dulos Pap is projetista do dom nio especialista do dom nio Entradas PT 6 M dulos a serem refinados PT 7 Diretrizes arquiteturais e PT 8 T ticas e padr es arquiteturais Sa das PT 9 Inicial Projeto do dom nio Descri o nesta atividade os padr es s o aplicados de acordo com as diretrizes selecionadas e guiam o refinamento do dom nio em m dulos e sub m dulos Por analogia um padr o como um template onde seus elementos s o pap is abstratos que precisam ser preenchidos por elementos concretos A atividade anterior cuidou da defini o deste template Esta atividade cuida do preenchimento do template Como descrito na atividade PD 1 o refinamento ocorre em duas dimens es de ponto comum para ponto vari vel e de m dulo para sub m dulo No caso de um refinamento na dimens o de inclus o de ponto de varia o definem se quais novos elementos ser o necess rios para implementar este ponto de varia o O resultado o surgimento de novos m dulos que implementam o ponto de varia o de ac

A Model-Driven Software Reuse Approach (in portuguese)

Contents

Download Pdf Manuals

Related Search

Related Contents