100

subdomnios deve ser guiada por este prossional; Dividir para conquistar: o conceito bsico de diviso de um problema grande em partes menores tambm til no processo de desenvolvimento para reutilizao. Diferentes tcnicas podem ser utilizadas, dependendo do contexto. Relacionamentos do tipo ParteDe e Um podem ser utilizados como tcnica de decomposio, onde cada subdomnio ou parte de um subdomnio maior, ou uma instncia. Alm disso, a maioria dos autores concorda que a diviso deve seguir a categorizao natural do domnio, o que mais uma vez ressalta a importncia do especialista nesta tarefa; Relacionamento features/sub-features: features so divididas em sub-features para ajudar na tarefa de compreenso do domnio e sua variabilidade, e a anlise destes relacionamentos (LEE; KANG, 2003) leva a uma sub-diviso natural do domnio. Features muito prximas so normalmente boas candidatas a pertencerem a um mesmo subdomnio. A ateno s features que aparentam estar separadas das demais pode tambm levar identicao de um subdomnio distinto; Domnios atmicos: idealmente, o subdomnio identicado deve ser atmico, ou seja, no pode ser substancialmente decomposto sem alterar suas propriedades primrias (HADDAD; TESSER, 2002). Isto importante para manter o subdomnio simples e gerencivel, e portanto mais fcil de automatizar; e Repetio: uma boa indicao sobre o que pode ser automatizado o nvel de repetio que ocorre com um projeto, estrutura ou trecho de cdigo. Se algum trecho de cdigo aparece repetidamente em diferentes partes do produto, mesmo que no de forma idntica, provvel que uma mquina consiga fazer o trabalho de cpia parametrizada. Pode valer a pena tentar procurar um subdomnio associado a este trecho. Outra tcnica para encontrar repeties a busca por padres recorrentes (KNODEL et al., 2005).

Alm dessas diretrizes, a experincia prtica com modelagem de domnio (TOLVANEN, 2005) mostra que um aumento incremental do escopo a melhor forma de se chegar ao tamanho ideal do subdomnio, comeando-se com um escopo pequeno, desenvolvendo partes da linguagem e transformaes, e incrementando-o sucessivamente. As seguintes sub-atividades so responsveis pela identicao dos subdomnios. Inicialmente, feita uma seleo inicial de candidatos a subdomnio (Sub-atividade AD.3.1). Em seguida, so identicadas linguagens de modelagem (Sub-atividade AD.3.2) e ferramentas (Sub-atividade AD.3.3). Para cada subdomnio candidato, feita a atribuio

101

de nvel de conana (Sub-atividade AD.3.4), onde so avaliadas a maturidade e o estado de cada subdomnio identicado at o momento. Por m, os subdomnios so documentados (Sub-atividade AD.3.5). Sub-atividade AD.3.1. Seleo de candidatos a subdomnio O objetivo desta sub-atividade identicar potenciais subdomnios dentro do domnio. O analista do domnio tenta identicar, com base nas informaes coletadas e com o auxlio das diretrizes descritas anteriormente, possveis subdomnios. Apesar do conhecimento do especialista do domnio ser a principal fonte de informao para execuo desta tarefa, o modelo de features pode ser til. Observando-se o modelo de features, o analista pode identicar palavras-chave que representam um subdomnio. Conforme destacado por (MAIDEN;
SUTCLIFFE,

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

um subdomnio. Lee & Kang apresentam a tcnica de anlise de agrupamento de features (LEE; KANG, 2003), que pode ser utilizada nesta atividade. A tcnica se baseia na identicao das unidades de agrupamento de features (FBU - Feature Binding Units). Uma FBU um conjunto de features relacionadas que juntas executam um servio ou operao dentro do domnio, ou seja, devem coexistir para que este servio esteja presente no produto nal. Esta tcnica tem o objetivo de auxiliar no processo de congurao dos produtos, determinando quais conjuntos de features estaro presentes dependendo da congurao desejada. O processo de anlise das FBUs inicia-se com a identicao das features de capacitao que representam servios independentemente congurveis, ou seja, as macro funcionalidades principais do domnio que podem ser adicionadas ou removidas de um produto como unidades independentes. Normalmente, estas so as features localizadas no topo do diagrama. A partir destas features principais, percorre-se o modelo, incluindo as demais features relacionadas que so necessrias para que esta macro funo possa ser executada. Dentro de uma FBU identicada, podem existir features que so opcionais ou alternativas, podendo ser selecionadas de acordo com a necessidade do produto. Estes sub-conjuntos de features devem ser separados em FBUs diferentes, pois a exemplo das features de capacitao, tambm representam pontos de variao que podem ser independemente congurveis. Cada FBU potencialmente um candidato a subdomnio, porm esta no necessariamente a melhor escolha. Pode-se, por exemplo, unir duas ou mais FBUs em um nico subdomnio, incluir ou remover features individualmente, ou mesmo sub-dividir uma FBU em mais de um subdomnio. Estas escolhas, porm, devem ser feitas somente mais adiante no processo, quando

102

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

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

Sub-atividade AD.3.2. Identicao de linguagens de modelagem O objetivo da identicao de subdomnios possibilitar a denio de uma DSL que consiga representar a variabilidade no capturada nas features e nos cenrios. Em domnios mais maduros, porm, podem j existir linguagens sendo utilizadas, como por exemplo a modelagem entidade-relacionamento, bastante comum. Mesmo que por algum motivo no possam ser diretamente utilizadas, essas linguagens podem oferecer pistas e informaes importantes na denio de uma nova DSL. Nesta atividade, o analista do domnio tenta determinar se existe uma ou mais linguagens para o domnio. O especialista do domnio

103

consultado, alm das documentaes existentes, tais como manuais e documentao das aplicaes existentes, caso disponvel. A existncia de uma linguagem especca de domnio um dos indicativos de que este domnio est consideravelmente maduro e, portanto, os benefcios do desenvolvimento orientado a modelos sero maiores (TOLVANEN; KELLY, 2005). Caso exista cdigo-fonte disponvel, h a possibilidade de existirem exemplos de modelos ou linguagens especcas para o domnio ou algum subdomnio. importante ressaltar que modelos nem sempre possuem uma representao grca que segue alguma linguagem conhecida, como a UML, por exemplo. Outras linguagens, incluindo arquivos de congurao e modelos textuais, devem tambm ser consideradas. O modelo de features tambm pode oferecer dicas sobre o que procurar. Palavras-chave presentes no modelo de features, tais como nomes de features, podem ocorrer dentro da documentao ou cdigo-fonte. Aps esta anlise, criada uma lista com as linguagens identicadas, associando-as com os subdomnios correspondentes.

Sub-atividade AD.3.3. Identicao de ferramentas A exemplo das linguagens especcas de domnio, a existncia de uma ferramenta de congurao ou modelagem um indicativo de que o subdomnio em questo apresenta alto grau de maturidade, e portanto as chances da reutilizao de software orientada a modelos ter sucesso so maiores. Em domnios extremamente maduros, podem existir at geradores de cdigo que podem ser reaproveitados. Novamente, o conhecimento do especialista do domnio essencial, mas manuais e documentao tambm devem ser consultados, uma vez que eles podem referenciar ferramentas usadas para criar modelos ou gerar partes da aplicao. O cdigo-fonte tambm deve ser inspecionado, pois comum a existncia, no cdigo gerado, de dados sobre a ferramenta que o gerou, data da gerao, entre outras informaes teis. As ferramentas identicadas so ento listadas e descritas, incluindo toda informao possvel, uma descrio de suas funcionalidades, os artefatos que podem ser gerados por ela e referncias para fontes externas. Novamente, caso seja encontrada uma ferramenta referente a um subdomnio ainda no identicado, acrescenta-se uma observao para posterior re-anlise.

104

Sub-atividade AD.3.4. Atribuio de nvel de conana Os subdomnios identicados nem sempre podem ser representados em uma DSL e automatizados utilizando tcnicas do desenvolvimento orientado a modelos. Mesmo para aqueles que podem, o custo de se desenvolver linguagens, ferramentas e transformaes pode ser muito alto. A automao de um subdomnio tambm pode requerer alteraes e renamentos no modelo de features, o que obviamente causa grande impacto no desenvolvimento. Finalmente, dependendo de qual subdomnio implementado primeiro, outros subdomnios sobrepostos ou relacionados podem precisar ser revistos. Por este motivo, todos os subdomnios identicados so tratados como candidatos at serem completamente realizados. Alm disso, deve existir um certo nvel de conana de que um subdomnio ir render os resultados esperados quando realizado em forma de artefatos para MDD, antes de se iniciar o projeto e implementao. Nesse sentido, a medida de nvel de conana serve como uma ferramenta de gerenciamento de riscos, ajudando a garantir que mudanas crticas na arquitetura e nos modelos de anlise levem aos resultados esperados. Tambm serve como um mecanismo de suporte tomada de deciso, auxiliando na coordenao dos esforos durante o processo iterativo desta abordagem. A determinao de um nvel de conana de um subdomnio altamente subjetiva e dependente do conhecimento do especialista do domnio e da experincia dos engenheiros do domnio. Nesta tese, as seguintes questes foram identicadas por possuir impacto na deciso, e devem ser consideradas:

Existe uma linguagem de modelagem para o subdomnio? Caso exista, qual a maturidade desta linguagem: uma linguagem bem conhecida, utilizada por especialistas em diferentes organizaes? Existe somente na organizao em questo? Foi desenvolvida somente para este projeto? A linguagem de modelagem foi validada, atravs de estudos de caso, para este projeto? Existe uma ferramenta especca para o subdomnio? Caso exista, qual a maturidade desta ferramenta: uma ferramenta bem conhecida, utilizada por especialistas em diferentes organizaes? Existe somente na organizao em questo? Foi desenvolvida somente para este projeto? A ferramenta foi validada, atravs de estudos de caso, para este projeto?

105

Como a ferramenta se enquadra no projeto? Ela gera cdigo executvel? Se no, pode ser adaptada para gerar cdigo? Quanto esforo necessrio para se utilizar a ferramenta neste projeto? Foi conduzido um projeto piloto para este subdomnio, utilizando-se uma linguagem de modelagem e ferramenta para gerao de cdigo? Para determinar o nvel de conana de forma mais sistemtica, o analista do domnio pode desenvolver uma mtrica envolvendo estas e outras possveis questes que possam surgir. Uma maneira simples desenvolver um questionrio com estas questes, atribuindo um peso para cada resposta. A soma de todos os valores o nvel de conana. O analista do domnio deve consultar todos os stakeholders quando denir esta mtrica, uma vez que existem diferentes fatores a serem considerados. Dependendo do cenrio, diferentes situaes podem requerer valores diferentes. Por exemplo, para sistemas crticos, razovel utilizar somente linguagens e ferramentas bem conhecidas, e portanto maiores pesos podem ser atribudos para estas questes. Em projetos com prazos mais curtos de entrega, esta tambm pode ser a nica opo. Porm, em projetos com mais tempo disponvel, os valores podem ser ajustados para incluir mais subdomnios, j que h mais tempo para desenvolver ferramentas e linguagens de modelagem. Este tambm o caso de domnios mais abrangentes. Sub-atividade AD.3.5. Documentao dos candidatos a subdomnio Nesta atividade, o analista do domnio documenta os subdomnios identicados, incluindo toda informao coletada nos passos anteriores: as features envolvidas, linguagens e ferramentas, e o nvel de conana. Na prtica, a maior parte da documentao vai sendo construda durante o processo, e portanto esta atividade realizada em paralelo com as anteriores. Os Quadros 6 e 7 ilustram exemplos de documentao obtida nesta atividade. O Quadro 6 mostra a documentao do subdomnio de navegao, onde so informadas a descrio, as features envolvidas, linguagens e ferramentas identicadas. O Quadro 7 mostra a documentao do nvel de conana dos subdomnios identicados. Neste exemplo, somente quatro perguntas foram utilizadas, com peso atribudo conforme indicado no quadro. Aqui o analista tambm descreve a interao entre o candidato a subdomnio e o restante do domnio. Neste ponto, esta descrio deve ser focada na cooperao em alto nvel entre as features, com o objetivo de ajudar na deciso de investir na automao do subdomnio ou no. Em estgios posteriores, caso seja decidido que este subdomnio ser automatizado, esta

106

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

Atividade AD.4. Validao e documentao do domnio

Papis: analista do domnio, especialista do domnio Entradas: Informaes sobre sistemas do domnio, Conhecimento do especialista, Informaes sobre stakeholders, PT.1.Inicial. Planejamento do domnio, PT.2.Inicial. Mapa de aplicaes, PT.3.Inicial. Modelagem do domnio, PT.3.Inicial. Candidatos a subdomnio. Sadas: PT.1.Validado. Planejamento do domnio, PT.2.Validado. Mapa de aplicaes, PT.3.Validado. Modelagem do domnio e PT.4.Validado. Candidatos a subdomnio. Descrio: antes do modelo do domnio ser utilizado, ele precisa ser validado e documentado. A documentao j foi iniciada durante as atividades anteriores. Nesta abordagem, as features so documentadas segundo o formato descrito por Czarnecki e Eisenecker (2000), que inclui a sua descrio semntica, o raciocnio, exemplo de aplicao, restries, e outras informaes (ALMEIDA et al., 2006). Em seguida, feita a validao do domnio. O analista de domnio verica homnimos e sinnimos, com o objetivo de reduzir a ambiguidade. Em seguida, o domnio validado

107

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

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

Papis: analista do domnio, especialista do domnio Entradas: Informaes sobre sistemas do domnio, Conhecimento do especialista, Informaes sobre stakeholders, PT.1.Validado. Planejamento do domnio, PT.2.Validado. Mapa de aplicaes, PT.3.Validado. Modelagem do domnio, PT.4.Validado. Candidatos a subdomnio. Sadas: PT.5. Histrico de decises sobre incluso/excluso de subdomnios. Descrio: nesta atividade, o analista do domnio, junto com o especialista e os demais stakeholders, analisam os subdomnios identicados com o objetivo de determinar se os mesmos sero includos nas fases subsequentes de projeto e implementao. Essa deciso deve levar em considerao o nvel de conana dos subdomnios candidatos, e portanto a existncia de linguagens, ferramentas e outros indcios de sua maturidade, seus relacionamentos com os demais elementos do domnio, e outros fatores externos, incluindo os objetivos de negcio e condies de mercado. A abordagem baseia-se num processo iterativo, e alguns subdomnios podem estar mais

108

maduros, enquanto outros necessitam de mais desenvolvimento. Neste sentido, ao invs de simplesmente incluir ou excluir um subdomnio, existem diferentes nveis de decises (D) a serem tomadas: D1 . Excluso imediata: signica que o candidato a subdomnio no passvel de automao, e deve ser descartado imediatamente. Tipicamente, este subdomnio tem um baixo nvel de conana, no existem linguagens de modelagem ou ferramentas que do suporte; D2 . Manter para avaliao posterior: signica que este subdomnio tem chance de ser automatizado, mas no existe evidncia concreta de que isto pode ser feito. Tipicamente, tem um baixo nvel de conana, nenhuma linguagem de modelagem ou ferramenta, mas o especialista do domnio, ou a experincia com o desenvolvimento, indicam que ele pode ser til aps algum desenvolvimento. No existe maneira de se estimar o esforo para torn-lo um subdomnio concreto, ou seja, muito arriscado iniciar algum desenvolvimento neste sentido. Portanto, essa deciso indica que nenhuma ao ser tomada nesta iterao. No entanto, caso os stakeholders aceitem o risco, este mesmo candidato a subdomnio pode se enquadrar no prximo nvel de deciso (D3 ); D3 . Iniciar investigao: se um subdomnio possui potencial para ser automatizado, mas as ferramentas para isso no esto disponveis, ele pode ser investigado, por meio do desenvolvimento de prottipos de linguagens de modelagem e/ou ferramentas de modelagem e transformaes. Apesar de esta deciso levar alocao de recursos e esforos, estes so mais limitados, uma vez que no h impacto nos demais artefatos do domnio, e sempre possvel parar a investigao sempre que necessrio, pois o sucesso do negcio no depende diretamente desse desenvolvimento; D4 . Iniciar o desenvolvimento de artefatos de produo: este o ponto sem retorno para um subdomnio. Neste nvel de deciso, a organizao compromete-se a incluir o subdomnio no processo de desenvolvimento, diferentemente do nvel D3 , onde ainda existe a possibilidade de se descartar o subdomnio. Um subdomnio neste nvel deve possuir um alto nvel de conana, mas no necessariamente precisa possuir as ferramentas para ser automatizado. Esta uma deciso crtica, uma vez que signica empregar esforos e recursos de forma mais intensa, para automatizar o subdomnio e gerenciar o seu impacto no restante do domnio; D5 . Iniciar um projeto piloto: antes de incluir um subdomnio no processo nal, boa prtica executar um projeto piloto, para reduzir os riscos da introduo de uma nova

109

tecnologia no desenvolvimento, e reduzir as barreiras transferncia tecnolgica que ir ocorrer. Este projeto piloto tambm serve para se vericar os benefcios reais da nova tecnologia, e planejar a melhor maneira de aplic-la a projetos reais; e D6 . Incluso imediata: signica que o subdomnio est maduro o suciente, possui ferramentas e uma ou mais linguagens de modelagem estveis e validadas. O nvel de conana alto, e o subdomnio j pode ser includo nas fases de projeto e implementao. Tambm signica que o desenvolvimento dos artefatos deste subdomnio guiado pelas linguagens e/ou ferramentas denidas. Enquanto a maioria dos subdomnios somente ir alcanar este nvel aps passar pelos nveis 2, 3, 4 e 5, alguns subdomnios bem conhecidos podem comear diretamente no nvel 5. Alguns podem at comear diretamente no nvel 6, se a organizao sentir que possui a experincia necessria para lidar com esta tecnologia.

Para tomar a deciso correta, o analista do domnio deve considerar toda informao disponvel, e a deciso deve ser acordada com todos os stakeholders. Alm da informao j mencionada, alguns outros critrios podem ajudar:

Experincia da equipe de desenvolvimento: se a equipe de desenvolvimento possui experincia com algum subdomnio, pode ser vantajoso focar neste subdomnio, para que seus benefcios possam ser alcanados sem muito esforo de entendimento e aprendizado; Tamanho do subdomnio: sempre que possvel, deve-se comear com subdomnios menores e aument-los gradativamente (TOLVANEN, 2005). Apesar de domnios menores levarem a menos benefcios em termos de reutilizao, so mais fceis de gerenciar e implementar. Com o tempo, eles tendem a evoluir; Nvel de abstrao: subdomnios que se encontram em um nvel de abstrao prximo ao cdigo-fonte so mais simples de implementar, e esto entre os exemplos de maior sucesso no desenvolvimento orientado a modelos, em termos de facilidade de gerao de cdigo (TOLVANEN; KELLY, 2005). Em contrapartida, so em geral menos reaproveitveis; e Existncia de cdigo-exemplo: a existncia de exemplos de como o cdigo ou outros artefatos devem ser gerados um fator importante. A abordagem de desenvolvimento atravs de exemplos (WIMMER et al., 2007) facilita o processo de construo de transformadores e geradores de cdigo.

110

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

Figura 13: Possvel evoluo dos nveis de deciso para o domnio de aplicaes de autoria de contedo para Web Inicialmente, toma-se uma deciso com base nas informaes disponveis inicialmente.

111

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

112

subdomnios sendo investigados ao mesmo tempo. Se uma organizao considerar esta restrio muito rgida, pode optar por ignor-la. Porm, ela deve estar atenta s possveis sobreposies ou interferncias entre dois subdomnios sendo colocados em produo ao mesmo tempo. Na prtica, em geral, esta situao no ocorrer com muita frequncia, j que no comum a existncia de muitos subdomnios sendo automatizados.

5.3 Consideraes nais

Neste captulo foi apresentada a fase de anlise de domnio, com atividades para promover a reutilizao atravs do desenvolvimento orientado a modelos. As principais contribuies deste captulo so as atividades sistemticas e algumas diretrizes para identicao dos subdomnios para automao. Tambm apresenta uma forma para lidar com os riscos da incerteza sobre a automao dos subdomnios. O Quadro 8 resume as atividades da anlise de domnio.
Atividades e sub-atividades AD.1. Planejamento do domnio AD.1.1. Preparao AD.1.2. Denio do escopo AD.2. Modelagem do domnio AD.2.1. Mapeamento da variabilidade em cenrios Entradas Informaes sobre sistemas do domnio Conhecimento do especialista Informaes sobre stakeholders Informaes sobre sistemas do domnio Conhecimento do especialista Informaes sobre stakeholders PT.1.Inicial. Planejamento do domnio PT.2.Inicial. Mapa de aplicaes Informaes sobre sistemas do domnio Conhecimento do especialista Informaes sobre stakeholders PT.1.Inicial. Planejamento do domnio PT.2.Inicial. Mapa de aplicaes PT.3.Inicial. Modelagem do domnio Sadas PT.1.Inicial. Planejamento do domnio PT.2.Inicial. Mapa de aplicaes PT.3.Inicial. Modelagem do domnio

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

PT.4.Inicial. subdomnio

Candidatos

AD.5. Deciso sobre incluso/excluso de subdomnios

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

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

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

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

PT.2. Mapa de aplicaes

PT.3. Modelagem do domnio

PT.4. Candidatos a subdomnio

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

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

Quadro 9: Descrio dos produtos de trabalho da fase de anlise de domnio variabilidades e comunalidades, tanto em termos de features, que descrevem as variabilidades estticas, como em termos de cenrios, que descrevem as variaes no comportamento. Tambm so denidos nesta fase os candidatos a subdomnios automatizveis.

115

Projeto de domnio orientado a modelos

O projeto do domnio uma fase essencial da engenharia de domnio (BOSCH, 2000). Seu objetivo denir uma arquitetura de software especca de domnio, e um conjunto de artefatos reutilizveis que podem ser combinados para desenvolver aplicativos mais rapidamente e com maior qualidade. Uma arquitetura de software especca de domnio uma combinao de componentes de software, especializada para um tipo de tarefa em particular (domnio), generalizada para uso efetivo neste domnio e composta em uma estrutura padronizada efetiva para a construo de aplicaes bem sucedidas (TRACZ, 1995). Em geral, a arquitetura deve ser projetada para atender aos principais requisitos conforme percebidos pelos stakeholders, de forma a alcanar os principais atributos de qualidade que so importantes para uma situao em particular (BASS;
CLEMENTS; KAZMAN,

2003).

Em termos de engenharia de domnio, um dos pontos principais na denio da arquitetura do domnio a reutilizao de software, e a capacidade de se desenvolver produtos de software similares rapidamente, sem muitas modicaes ou adaptaes nessa arquitetura. Isto pode ser alcanado por meio de um bom suporte comunalidade e variabilidade do domnio (MOON; YEOM, 2006; CZARNECKI, 2005; WEISS; LAI, 1999; CLEMENTS; NORTHROP, 2002). A arquitetura projetada deve no somente prever os pontos de variao, mas tambm efetivamente providenciar o suporte requerido para sua implementao (BASS; CLEMENTS; KAZMAN, 2003). H dois tipos fundamentalmente diferentes de complexidade relativa variabilidade (VLTER; GROHER, 2007; CZARNECKI, 2005): Congurao de rotina: tipo de variabilidade em que estruturas simples, como uma lista de propriedades ou uma rvore, podem ser utilizados para congurao do produto; e Construo criativa: tipo de variabilidade em que so necessrios modelos complexos, como estruturas do tipo grafo ou linguagens textuais completas, para descrev-la

116

completamente. Diferentes mecanismos de representao de variabilidade podem estar em diferentes locais de um espectro que vai desde a congurao de rotina at a construo criativa. Por exemplo, wizards so mecanismos simples, onde a cada passo um parmetro especicado, e portanto localizam-se prximo congurao de rotina. O modelo de features (Seo 3.1.1) um pouco mais complexo, mas ainda relativamente simples, localizando-se aproximadamente na metade do espectro. Do lado criativo, encontram-se as linguagens especcas de domnio (DSL) (CZARNECKI, 2005). O modelo de features do domnio de autoria de contedo para Web, j utilizado no captulo anterior e replicado aqui na Figura 14, contm duas features principais: navegao e administrao. A navegao (feature mandatria) consiste no contedo visvel ao usurio e busca automtica, que pode ser simples e/ou avanada (features alternativas do tipo or, onde mais de uma alternativa pode estar presente). A submisso de contedo de usurio opcional. No lado da administrao, a feature de autoria (mandatria) representa as funes de publicao do contedo. Se existir contedo de usurio, este pode ou no ser moderado (a seta curva indica uma dependncia entre moderao e contedo de usurio). Estas so features de capacitao (Seo 3.1.1).

Figura 14: Modelo de features do domnio web de autoria de contedo O que tambm varia de aplicao para aplicao deste domnio a estrutura da informao (tipos de documento e seus relacionamentos) e como a mesma apresentada ao usurio (pginas

117

e links). Para representar esta variabilidade, no lado inferior da gura esto as features de tecnologia do domnio (Seo 3.1.1): pginas (formulrios ou relatrios) e links so utilizados para exibir a informao em um navegador, e tipos de documentos e relacionamentos descrevem a estrutura da informao. A maioria das features, como a busca, contedo de usurio e moderao, representa a variabilidade do tipo presente/ausente, que ca prxima do lado da congurao de rotina no espectro de variabilidade. Desta forma, grande parte do suporte variabilidade pode ser conseguido somente atravs de congurao, com a ajuda de uma arquitetura bem projetada e um conjunto de componentes reutilizveis. Porm, features como tipos de documentos e relacionamentos contm variabilidades mais complexas, para as quais todos os detalhes no podem ser capturados somente com modelos de features, pois estes so muito genricos (TOLVANEN; KELLY, 2005). Estruturas ou mecanismos mais ricos so necessrios, com mais poder expressivo capaz de capturar detalhes sobre os conceitos do domnio, seus relacionamentos e restries. Nestes casos, possvel simplesmente implementar manualmente o suporte a esta variao, que o que acontece no desenvolvimento tradicional. Para isso, um desenvolvedor utiliza suas habilidades de programador e uma linguagem de programao, possivelmente com a ajuda de uma biblioteca ou framework que facilite este trabalho criativo. Mas no caso do MDD, onde se deseja automatizar o suporte variabilidade, a tecnologia escolhida normalmente uma linguagem especca de domnio (DSL), pois ela pode complementar o modelo de features com detalhes sobre variabilidades mais complexas em partes do domnio (TOLVANEN; KELLY, 2005; CZARNECKI, 2005). Adicionalmente, uma DSL pode ser utilizada junto com transformaes para automaticamente gerar artefatos de implementao, que o objetivo nal do desenvolvimento orientado a modelos (CZARNECKI, 2005). O elemento que une estes artefatos a arquitetura do domnio, que deve ser projetada para dar suporte tanto variabilidade baseada em features como variabilidade baseada em DSLs. Tambm deve ter preocupaes sobre a existncia, alm dos componentes do domnio, de artefatos especcos do MDD, como DSLs, transformaes de software e geradores de cdigo. Um problema que a maioria das abordagens de engenharia de domnio existentes no dene como projetar uma arquitetura de software especca de domnio com este objetivo. A literatura possui muitos trabalhos que discutem detalhes sobre como produzir uma arquitetura para reutilizao (BASS; CLEMENTS; KAZMAN, 2003; BOSCH, 2000), mas estes no consideram o MDD. E aqueles que consideram so normalmente focados no processo de derivao automtica

118

de produtos (WEISS et al., 2008; VLTER; GROHER, 2007; BOTTERWECK; OBRIEN; THIEL, 2007; ARBOLEDA; CASALLAS; ROYER, 2007; TRASK et al., 2006; TOLVANEN; KELLY, 2005;
CZARNECKI; HELSEN; EISENECKER,

2004b), e no na tarefa de produzir uma arquitetura de

domnio que adequada para o MDD, ou seja, que contemple elementos capazes de integrar DSLs, transformaes e geradores de cdigo. Alm disso, a maioria destas abordagens, como as descritas por Almeida et al. (2007b), Keepence e Mannion (1999), Lee e Kang (2004), baseia-se na identicao da variabilidade somente em termos de features. Como j discutido anteriormente, h outros tipos de variao, como aquelas presentes em modelos entidade-relacionamento, por exemplo (BARTHOLDT;
OBERHAUSER; RYTINA,

2008), que so mais complexas do que possvel capturar em um

modelo de features (RABISER; GRNBACHER; DHUNGANA, 2007), sendo necessria uma DSL especca para representar a variabilidade de modo adequado ao MDD.

6.1 Objetivos do projeto de domnio

Existem conceitos relacionados ao MDD que devem ser considerados durante o projeto do domnio, especialmente durante a denio da arquitetura do domnio. Alm da variabilidade mais complexa discutida anteriormente, nesta abordagem a arquitetura e seus componentes contam com a existncia de DSLs e transformaes, que por sua vez devem ser capazes de produzir artefatos de implementao voltados quela arquitetura especca. A fase de projeto do domnio tem os seguintes objetivos:

Identicar as diretrizes arquiteturais: o projeto arquitetural deve ser direcionado pelos objetivos de negcio e requisitos mais importantes, considerando-se o ponto de vista de diferentes stakeholders. Estes so chamados de diretrizes arquiteturais (BASS;
CLEMENTS; KAZMAN,

2003), e so responsveis por moldar a arquitetura de forma a

atender a todos os requisitos da melhor forma possvel. Nos contextos de reutilizao e MDD, as diretrizes devem incluir, obrigatoriamente, as variabilidades em forma de features e DSLs, e a existncia de artefatos do MDD, como DSLs e transformaes de software; Selecionar/denir tticas e padres: o projeto arquitetural deve cobrir as diretrizes arquiteturais, em forma de tticas e padres que contemplem solues para cada requisito. Um padro consiste em uma soluo comprovadamente bem sucedida para determinados tipos de problema, com um contexto bem denido. Por trs de um padro existem

119

uma ou mais tticas, que representam as maneiras utilizadas pelo padro para resolver o problema; Denir a arquitetura e componentes: o projeto do domnio deve incluir uma denio da arquitetura do domnio. Junto com a arquitetura, devem ser especicados os componentes do domnio, incluindo componentes de software tradicionais, servios, e tambm artefatos do MDD, como DSLs, transformaes e geradores de cdigo; e Documentar a arquitetura: como objetivo desta fase, deve ser produzida toda a documentao referente arquitetura projetada, visando servir de guia para a fase de implementao. Esta fase de projeto inspirada nos mtodos descritos por Almeida et al. (2007b), deBaud e Schmid (1999), Bass, Clements e Kazman (2003), Clements, Kazman e Klein (2004), com duas diferenas principais: 1. So oferecidos meios mais concretos para se elicitar diretrizes arquiteturais explcitas para o suporte aos diferentes tipos de variabilidade, na forma de features, cenrios e linguagens especcas de domnio, o que no descrito nos mtodos citados; e 2. Juntamente com as diretrizes, so providenciadas tticas para atend-las, utilizando padres de projeto especcos para as diferentes formas de variabilidade, a exemplo de outras abordagens da literatura (ALMEIDA et al., 2007b; KEEPENCE; MANNION, 1999; LEE;
KANG,

2004).

6.2 Atividades do projeto de domnio

O projeto do domnio um processo iterativo de renamento. Inicia-se com o domnio todo, e a cada iterao feito um renamento que identica novos mdulos, que sero renados na prxima iterao, e assim por diante, at que o projeto esteja concludo, em funo de um entendimento satisfatrio sobre o que dever ser implementado. A primeira atividade cuida da escolha dos mdulos a serem renados (Atividade PD.1), sendo executada no incio de cada iterao. Em seguida, so selecionadas as diretrizes arquiteturais (Atividade PD.2), que so os requisitos mais importantes a serem atendidos pelo projeto da arquitetura. Para cada diretriz, escolhe-se um ou mais padres arquiteturais (Atividade PD.3), responsveis por resolver cada requisito individualmente, ajudando na obteno dos atributos de qualidade desejados para a arquitetura. Os padres so ento aplicados durante o renamento dos mdulos (Atividade

120

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

Atividade PD.1. Escolha dos mdulos a serem renados

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

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

(Attribute-Driven Design ou projeto orientado a atributos (BASS; CLEMENTS; KAZMAN, 2003)). O ADD promove o renamento sucessivo de mdulos, iniciando-se com o domnio todo, e realizando divises at serem obtidos os mdulos que iro formar a arquitetural nal. Assim, esta primeira atividade consiste na escolha dos mdulos a serem renados. O renamento pode ocorrer em duas dimenses: Dos pontos comuns para os variveis: um ponto de variao no projeto; e De mdulos para sub-mdulos: neste renamento, inicia-se dividindo-se o domnio todo em mdulos, e em seguida os mdulos so subdivididos sucessivamente. Estas dimenses normalmente so ortogonais, ou seja, um mdulo pode incluir diversos pontos variveis. Da mesma forma, um ponto varivel pode incluir diversos mdulos. Portanto, recomenda-se realizar apenas um desses tipos de renamento a cada iterao. No existe uma ordem especca, ou seja, pode-se iniciar com um renamento de mdulo para sub-mdulo, em seguida acrescentar um ponto varivel, depois novamente renar um mdulo. Porm, sugere-se iniciar com uma primeira diviso do domnio em mdulos, o que permite uma viso geral da arquitetura desejada. Aps uma primeira diviso, o projetista do domnio avalia a arquitetura existente at o momento, identica se existem mdulos que ainda precisam ser renados, e os lista. Para cada um destes, executa as atividades seguintes, renando o mdulo novamente. neste renamento, inicia-se o projeto

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

121

O renamento segue at o projetista decidir que no necessrio acrescentar mais detalhes. A arquitetura deve capturar apenas as informaes mais importantes do projeto, e portanto no so necessrios muitos detalhes. Bass, Clements e Kazman (2003), aps anos de experincia em projetos envolvendo projeto arquitetural, observaram que trs nveis de diviso so normalmente sucientes, pois permitem detalhar de forma satisfatria as informaes essenciais para que o processo possa seguir adiante. importante lembrar que nesta abordagem j existe uma primeira diviso do domnio em subdomnios, feita na atividade de anlise. Porm, esta uma diviso conceitual que pode no coincidir com a diviso em mdulos que realizada nesta fase de projeto (BUSCHMANN et al., 1996). Enquanto a primeira tem como objetivo identicar partes do domnio onde a automao possvel, separando conjuntos de features relacionadas, aqui a diviso tem como objetivo implementar padres arquiteturais que iro atender a requisitos para o domnio as diretrizes arquiteturais.

Atividade PD.2. Seleo das diretrizes arquiteturais

Papis: projetista do domnio, especialista do domnio, demais stakeholders. Entradas: PT.6. Mdulos a serem renados Sadas: PT.7. Diretrizes arquiteturais Descrio: as diretrizes arquiteturais so uma combinao de requisitos funcionais e de qualidade que do forma arquitetura de um domnio ou mdulo em particular (BASS;
CLEMENTS; KAZMAN,

2003). As diretrizes so normalmente representadas atravs de cenrios

que testam a capacidade da arquitetura em satisfazer um ou mais atributos de qualidade. Para identicar as diretrizes, os objetivos de negcio mais importantes so identicados e transformados em cenrios ou casos de uso. Desta lista, aqueles com maior impacto na arquitetura so escolhidos. Estas so as diretrizes arquiteturais (BASS; CLEMENTS; KAZMAN, 2003). Nesta abordagem, ao menos trs tipos de diretrizes devem estar presentes com maior prioridade: Variabilidade em termos de features: como discutido anteriormente, a maior parte da variabilidade pode ser descrita atravs de features. Para o projeto arquitetural, a variabilidade descrita tambm na forma de cenrios, visando facilitar seu entendimento e futura avaliao;

122

Variabilidade em forma de DSLs: casos mais complexos de variabilidade exigem um mecanismo mais expressivo para express-la apropriadamente. Para o projeto arquitetural, so utilizadas DSLs para descrever esta variabilidade mais complexa; e

Integrao entre subdomnios: o projeto arquitetural precisa considerar os pontos onde diferentes subdomnios iro interagir. Isto envolve, por exemplo, a integrao entre cdigo gerado e no-gerado. Estes pontos de interao devem ser explcitos para que a arquitetura possa dar suporte adequado gerao de cdigo.

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

Sub-atividade PD.2.2. Seleo das diretrizes arquiteturais de variabilidade baseada em DSLs Como discutido no incio deste captulo, variabilidades mais complexas requerem uma descrio mais rica. Esta abordagem prope o uso de linguagens especcas de domnio para formalizar o espao de variao em reas particulares do domnio (subdomnios), denindo os conceitos e introduzindo restries e regras relacionadas variabilidade neste subdomnio. DSLs tambm so utilizadas para guiar o desenvolvimento de transformaes de software e gerao de cdigo, nas atividades de implementao. Esta atividade cuida apenas da seleo de DSLs que descrevem o subdomnio relacionado ao mdulo sendo renado. Caso seja necessrio desenvolver uma nova DSL, esta deve ser realizada posteriormente, na fase de implementao do domnio.

123

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

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

por exemplo, desenvolver um nico metamodelo para os mltiplos subdomnios, e ento desenvolver diferentes sintaxes concretas, de forma que estes subdomnios estejam integrados mas ainda assim possuir diferentes vises. Essa questo de integrao de domnios um assunto ainda no dominado. Nesta atividade, estas interdependncias entre subdomnios so explicitadas, pois podem ter impacto nas decises de projeto. Para isso, cada elemento em cada subdomnio deve ser inspecionado, e cada elemento que depende de um elemento em um subdomnio diferente deve ser documentado. As restries de incluso e excluso mtua entre as features indicam algumas destas dependncias, porm outras podem se tornar aparentes somente aps a implementao estar avanada. Por este motivo, esta tese defende a idia de que a identicao dos subdomnios deve acontecer de forma evolutiva e investigativa, desde a anlise (Atividade AD.5). A cada iterao, os subdomnios devem evoluir, com o avano da implementao, aumentando a conana em sua validade e identicando novas relaes entre os subdomnios. Na Seo 4.4 apresentado um modelo de ciclo de vida que discute este aspecto interativo e iterativo da abordagem proposta. Alm das relaes entre os subdomnios, o relacionamento entre cada subdomnio e as outras partes do domnio tambm precisam ser documentadas, de forma que possvel projetar uma arquitetura que acomode tanto artefatos gerados como no-gerados.

Atividade PD.3. Escolha de tticas e padres arquiteturais

Papis: projetista do domnio, especialista do domnio Entradas: PT.7. Diretrizes arquiteturais

124

Sadas: PT.8. Tticas e padres arquiteturais Descrio: o objetivo desta atividade selecionar ou denir tticas e padres para satisfazer s diretrizes arquiteturais. O uso de padres considerado uma das mais tcnicas mais teis durante a fase de projeto de software. Atravs desta tcnica, pode-se reaproveitar solues recorrentes e j comprovadamente bem sucedidas, poupando-se esforo e riscos nesta atividade. Em termos de projeto arquitetural, so conhecidos como padres, estilos (BASS; CLEMENTS; KAZMAN, 2003) ou abordagens (CLEMENTS; KAZMAN; KLEIN, 2004) arquiteturais. A diferena entre um padro arquitetural e um padro de projeto est na abrangncia e impacto da soluo. Enquanto padres de projeto normalmente so utilizados para resolver problemas mais detalhados, padres arquiteturais descrevem solues mais abrangentes que envolvem todo o escopo de um domnio ou sistema. Alm disso, padres arquiteturais normalmente so escolhidos e utilizados conforme requisitos no-funcionais, como desempenho ou conabilidade. Normalmente, inicia-se com padres arquiteturais que denem a macro-estrutura do domnio, at chegar em padres menores que resolvem problemas mais especcos de partes do domnio. Alm disso, um padro arquitetural implementa uma ou mais tticas, que por sua vez tem o objetivo de alcanar um ou mais atributos de qualidade (BASS; CLEMENTS; KAZMAN, 2003). Uma ttica descreve uma estratgia a ser utilizada para se alcanar um determinado atributo de qualidade. Assim, para cada diretriz arquitetural, seleciona-se uma ou mais tticas, e em seguida so selecionados os padres para implementar estas tticas. Uma lista de tticas apresentada por Bass, Clements e Kazman (2003), porm esta no inclui tticas para lidar com variabilidade em um domnio, nem com a integrao entre subdomnios automatizados, como o caso desta abordagem (Sub-atividade PD3.3). Para implementar as tticas, existe uma grande quantidade de fontes de padres e estilos arquiteturais. Vale destacar a srie de cinco volumes conhecida como POSA (Pattern-Oriented Software Architecture) (BUSCHMANN et al., 1996; SCHMIDT et al., 2000; KIRCHER; JAIN, 2003;
BUSCHMANN; HENNEY; SCHMIDT, 2007a, 2007b), que apresenta diversos padres voltados para

diferentes tipos de problemas arquiteturais. O catlogo clssico de padres de projeto (GAMMA

et al.,

1995) tambm pode ser til nesta atividade, alm de outras fontes citadas por Bass,

Clements e Kazman (2003). Com relao ao problema da variabilidade, existem alguns trabalhos que propem o uso de alguns padres de projeto com este objetivo (ALMEIDA et al., 2007b; KEEPENCE; MANNION, 1999; LEE; KANG, 2004). Existem tambm diversos trabalhos que apresentam formas de se implementar variabilidade em uma linha de produtos, que podem ser adaptadas para o nvel

125

de projeto arquitetural (ANASTASOPOULOS; GACEK, 2001; MUTHIG; PATZKE, 2003; RIBEIRO;

MATOS; BORBA,

2008; SVANHBERG; GURP; BOSCH, 2002). Porm, estes no cobrem o aspecto

de integrao entre diferentes subdomnios. Para esta abordagem, foram selecionados alguns padres que auxiliam na implementao das tticas especcas para variabilidade e integrao entre subdomnios, apresentados mais adiante nesta seo. A escolha das tticas e padres a serem utilizados guiada por dois fatores: o requisito em si, explicitado pela diretriz arquitetural, e os efeitos colaterais que o emprego de uma ttica ou padro provoca nas demais diretrizes (BASS; CLEMENTS; KAZMAN, 2003). Caso no seja possvel encontrar alguma ttica e/ou padro que sirva para um cenrio especco, pode-se modicar ou adaptar tticas e padres existentes, ou mesmo criar novos especialmente para este domnio. Estes passam ento a fazer parte do catlogo da organizao e podem ser reaproveitados em projetos futuros. Da mesma forma que as diretrizes arquiteturais, nesta abordagem so necessrias tticas e padres para pelo menos trs aspectos principais: variabilidade baseada em features, variabilidade baseada em DSLs e integrao entre subdomnios. Alguns dos padres identicados nesta tese so baseados nos trabalhos de Vlter (2003), Vlter e Bettin (2004), que so muito teis para projetos de MDD, mas no so especcos para o projeto arquitetural ou para a engenharia de domnio, e portanto so acrescentadas discusses sobre como alguns desses padres podem ser incorporados ao contexto de reutilizao.

Sub-atividade PD.3.1. Padres arquiteturais para variabilidade baseada em features Existe uma srie de padres que podem ser utilizados para ajudar a tornar uma arquitetura de software especca de domnio preparada para os diferentes tipos de variabilidade baseada em features. Em particular, os padres do GoF (GAMMA et al., 1995) podem facilitar a representao da variabilidade no projeto arquitetural, resolvendo alguns dos problemas relacionados implementao das features (ALMEIDA et al., 2007b). No caso do desenvolvimento orientado a modelos, necessrio considerar tambm como os geradores de cdigo so integrados com cada padro, j que partes do software so automaticamente geradas e precisam interagir com o restante do software. O cenrio o seguinte: um modelo de features descreve os pontos comuns e variveis. Um gerador de cdigo usa como entrada uma seleo de features/subfeatures que faz parte da aplicao gerada, e precisa produzir o cdigo correspondente. Para cada tipo de feature, um ou mais padres do GoF (GAMMA et al., 1995) utilizado.

126

Features alternativas: estas so as features onde somente uma alternativa pode estar presente em uma aplicao. Quando uma feature pode ser mapeada diretamente em uma nica classe, o padro Abstract Factory indicado. Neste padro, um elemento que realiza o papel de fbrica abstrata e um elemento que realiza o papel de produto abstrato representam um ponto de variao, uma feature. Fbricas e produtos concretos representam variantes alternativas. O gerador somente precisa gerar o cdigo de instanciao da fbrica concreta correspondente, e o restante do cdigo permanece independente.

Figura 15: Uso do padro Abstract Factory para features alternativas A Figura 15 ilustra o uso deste padro com um gerador de cdigo para implementar features alternativas. Para cada ponto de variao, cria-se uma fbrica abstrata e um produto abstrato (AbstractFactoryFeatureA e FeatureA). Para cada variante alternativa, so criadas as fbricas e produtos concretos. O gerador, ao criar um produto, s precisa declarar a fbrica abstrata correspondente ao ponto de variao selecionado, neste caso a featureA, gerando as linhas 2 e 6, e instanciar a fbrica correspondente alternativa selecionada (linha 3). O resto do cdigo pode utilizar a feature normalmente. O padro Prototype pode ser utilizado com o mesmo propsito, nos casos onde se deseja evitar a criao de subclasses para os objetos construtores. Neste padro, cada alternativa implementada como uma classe diferente de um prottipo comum. O gerador de cdigo responsvel por gerar cdigo que instancia somente a alternativa selecionada.

127

Figura 16: Uso do padro Prototype para features alternativas A Figura 16 ilustra o uso do padro Prototype com um gerador de cdigo para implementar features alternativas. Para cada ponto de variao, neste caso a featureA, cria-se um prottipo, que implementa uma interface (Cloneable) com um mtodo para criar uma cpia de si mesmo (clone()). Cada variante alternativa (Sub-features A1, A2 e A3) transformada em uma instncia concreta do prottipo, mediante a implementao do mtodo clone(), responsvel por criar uma instncia da variante. O gerador de cdigo, ao produzir o cdigo do produto, s precisa criar as chamadas correspondentes criao do ponto de variao e da alternativa selecionada. No exemplo da Figura 16, mediante a seleo do ponto de variao featureA, o gerador gera as linhas 2-9 e 13. A linha 12 contm o cdigo que instancia a alternativa selecionada, no caso a variante Sub-feature A1. Para o comportamento associado s features, uma soluo a utilizao do Template method. A especicao do comportamento comum denida em mtodos abstratos de uma classe abstrata. O comportamento de cada alternativa implementado em classes concretas, com implementaes dos mtodos correspondentes. A Figura 17 ilustra o uso deste padro. O gerador apenas precisa gerar a criao do objeto concreto de acordo com a alternativa

128

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

Figura 17: Uso do padro Template method para features alternativas Caso uma feature precise ser implementada por diferentes classes, sugere-se o uso do padro Facade em conjunto com um dos trs acima: Abstract Factory, Prototype ou Template method. O Facade permite a reunio de diversas classes em uma nica fachada. Neste caso, os mtodos construtores (o construtor da classe, o mtodo clone() ou o mtodo template, nos padres citados), precisam ser estendidos para instanciar todas as classes que implementam cada feature, com uma classe facade servindo para reuni-las em um nico ponto. Quando as features alternativas correspondem a comportamentos alternativos, que devem ser mapeados em um nico mtodo ao invs de toda uma classe, os padres Strategy ou Template method podem ser utilizados. O padro Strategy consiste na denio de uma interface, com um nico mtodo, que corresponde ao ponto de variao. Para cada alternativa deve-se providenciar uma implementao desta interface, onde o mtodo contm o comportamento referente alternativa selecionada. O Template method similar, mas normalmente no exige uma interface dedicada a um nico mtodo. Em ambos os casos, o gerador produz as chamadas dos mtodos correspondentes s alternativas selecionadas. Or features: estas so similares s features alternativas, porm mais de uma feature pode estar presente em uma aplicao. O padro Chain of Responsibility pode ser utilizado quando as diferentes features introduzem funcionalidades complementares, que so executadas uma aps a outra. Neste

129

padro, cria-se uma classe abstrata para o ponto de variao, com um mtodo principal e um mtodo para adicionar comportamentos adicionais. Dentro do mtodo principal, adiciona-se uma chamada para um comportamento abstrato, a ser implementado por cada instncia concreta que corresponde s variantes.

Figura 18: Uso do padro Chain of Responsibility para or features A Figura 18 ilustra o uso do padro Chain of Responsibility na implementao de or features. Para cada ponto de variao, no caso featureA, cria-se uma classe abstrata, contendo um mtodo principal (metodo()), a ser chamado no produto. Tambm criado um mtodo (setNext()) que permite encadear outras instncias a esta. Para cada variante (featureA sozinha e sub-features A1, A2 e A3), cria-se uma subclasse que implementa o comportamento especco da variante. O gerador, para combinar as features selecionadas, cria uma instncia da feature principal (linha 3), cria instncias das sub-features selecionadas (linhas 4 e 5), e faz o encadeamento (linhas 6 e 7). Dessa forma, ao se chamar o mtodo principal (linha 9), os comportamentos especcos de cada sub-feature so chamados. O Chain of Responsibility permite a combinao de comportamentos sequenciais, ou seja, um executado aps o outro. Em interaes mais complexas, onde a ordem de chamada dos comportamentos especcos no sequencial, exigindo um cdigo especco para isso, o padro Decorator pode ser utilizado. Neste padro, cria-se um decorator para cada variante.

130

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

Figura 19: Uso do padro Decorator para or features

A Figura 19 ilustra o uso do padro Decorator para implementar or features.

Para

cada ponto de variao, no caso featureA, cria-se uma classe abstrata que contm mtodos especcos desta feature (metodo1() e metodo2()). Cria-se tambm um decorator abstrato, com um construtor responsvel por incluir o comportamento deste decorator a outro. Para cada variante (no caso, featureA sozinha, e as sub-features A1, A2 e A3), cria-se uma instncia da classe abstrata principal (FeatureASozinha), e dos decorators (SubFeatureA1Decorator, SubFeatureA2Decorator e SubFeatureA3Decorator). O gerador apenas precisa fazer a chamada que cria instncias dos decorators que correspondem s variantes selecionadas (linhas 3, 4 e 5). Da mesma forma que com as features alternativas, caso uma or feature precise ser implementada em vrias classes, pode-se combinar o padro Facade para reunir mais de uma classe em um nico ponto.

131

Features opcionais: para features opcionais, o mesmo conjunto de padres utilizados para as or features podem ser utilizados, com a diferena de que neste caso no necessrio garantir que ao menos uma feature esteja presente na aplicao. Para a implementao de variabilidade baseada em features, podem tambm ser utilizados dois padres baseados em prticas bem conhecidas para a escrita de geradores de cdigo (CZARNECKI et al., 2002). O primeiro padro conhecido como a abordagem visitante (CZARNECKI; HELSEN, 2006;
JOUAULT; BZIVIN; KURTEV,

2006; FEILKAS, 2006). Neste padro, o modelo de entrada

percorrido e cada elemento visitado. Para cada elemento, um template correspondente chamado, de acordo com o tipo do elemento. No cenrio de engenharia de domnio, este padro particularmente til para diferentes tipos de features mandatrias e opcionais. A Figura 20 ilustra este padro.

Figura 20: Padro visitante sendo aplicado implementao de variabilidade baseada em features Neste exemplo, um visitante percorre o modelo de features e, para cada feature selecionada, chama o template correspondente, que gera cdigo para ela. Normalmente, cada template produz uma nica classe que implementa a feature, que se encaixa na arquitetura atravs de padres de projeto como os descritos anteriormente nesta seo. O padro visitante uma boa opo quando possvel encapsular a funcionalidade de uma feature em uma nica classe. Caso no seja possvel, a abordagem template (CZARNECKI;
HELSEN,

2006) pode ser utilizada. Consiste em um nico template que o ponto de entrada,

responsvel por consultar os modelos e chamar outros templates. Esta abordagem difere da abordagem visitante no sentido em que a ordem e lgica por trs das chamadas dos templates explicitamente programada pelo desenvolvedor, no dependendo de alguma poltica pr-estabelecida. Alm disso, um template no necessariamente produz uma unidade distinta como uma classe. Um template pode introduzir apenas um nico mtodo, um pedao de texto,

132

que pode ser inserido em outros artefatos. Tambm pode produzir hierarquias completas de classes. Esta abordagem pode ser utilizada em diferentes tipos de variabilidade, por ser mais exvel, sendo particularmente til para implementar or features, como ilustra a Figura 21.

Figura 21: Abordagem template sendo aplicada gerao de cdigo baseada em features O template principal responsvel por analisar os modelos de features e decidir quais templates sero chamados, quando sero chamados, e em qual ordem. No exemplo da Figura 21, a featureA selecionada, e implementada por uma nica classe, enquanto as sub-features A1 e A3 (que esto selecionadas), so implementadas como os mtodos A1() e A3(). Sub-atividade PD.3.2. Padres arquiteturais para variabilidade baseada em DSLs Este tipo de variabilidade expresso em termos de uma DSL. O desenvolvedor especica um programa/modelo que segue a sintaxe de uma DSL, e um gerador produz cdigo-fonte automaticamente. A variabilidade em uma DSL pode ser virtualmente tudo que pode ser denido em um metamodelo: atributos verdadeiro/falso ou strings, listas tipadas e colees, enumeraes e outros conceitos da orientao a objetos podem ser utilizados para descrever o espao de variabilidade. Para consultar estas estruturas em um gerador, construes comuns maioria das linguagem de programao, como condies e laos, podem ser utilizadas. Devido grande variedade destes tipos de variabilidade, aqui no se prope nenhum tipo de padro associado a um tipo particular de variao (como na seo anterior). Ao invs disso, os padres nesta categoria so focados em como as ferramentas baseadas em DSL e geradores de cdigo podem ser integrados arquitetura e aos geradores de cdigo baseados em features. Apesar destes padres no aparecerem na arquitetura da aplicao nal, eles podem ter impacto no sucesso do domnio. Anal, no MDD estes artefatos tambm fazem parte da arquitetura do domnio (VLTER; GROHER, 2007), e devem ser considerados durante o seu ciclo de vida. Um primeiro padro proposto denomina-se camada na de dados, que facilita a

133

integrao entre o gerador e a ferramenta de modelagem DSL. Normalmente, geradores de cdigo consultam informaes diretamente de uma ferramenta de DSL, que pode ser criada manualmente ou atravs de algum framework de construo de linguagens, como GME (Generic Modeling Environment), GMF (Graphical Modeling Framework) ou openArchitectureWare (Seo 2.2.2). Este padro defende o uso de uma camada separada de dados, construda em uma tecnologia independente da ferramenta DSL, e que contm apenas as informaes essenciais para o gerador, e nada mais. Desta maneira, a informao necessria para o funcionamento do gerador explicitada, facilitando a evoluo independente do gerador e da ferramenta DSL. Tambm permite o desenvolvimento dos trabalhos de ambas as equipes: a que est trabalhando no gerador e outra equipe trabalhando na linguagem e suporte ferramental. Finalmente, este padro libera o gerador de uma tecnologia de modelagem em particular, alm de restringir as necessidades de aprendizado das particularidades das ferramentas de modelagem a uma nica equipe. A equipe trabalhando com gerao de cdigo pode focar em suas prprias tarefas. A Figura 22 ilustra este padro.

Figura 22: Padro camada na de dados

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

134

Sub-atividade PD.3.3. Padres de integrao entre subdomnios Estes padres buscam promover uma boa integrao entre cdigo gerado e no-gerado, particularmente nas reas que envolvem os limites de um subdomnio. Os padres descritos nesta seo dividem-se em quatro categorias, dependendo da dependncia entre cdigo gerado e no-gerado, conforme descrito a seguir. Cdigo gerado depende de cdigo no-gerado: este o tipo mais simples de interao, e consiste em fazer o gerador produzir cdigo que usa cdigo existente, no-gerado, como um framework ou biblioteca. O padro Facade (GAMMA et al., 1995) pode ser utilizado para simplicar a interao entre cdigo gerado e no-gerado. Ao invs de gerar cdigo que usa mltiplas classes e mltiplos mtodos, uma nica classe Facade agrupa todas as classes e mtodos em um nico ponto. Isto no somente torna as dependncias mais explcitas, mas tambm promove alguma proteo contra mudanas no cdigo no-gerado. Dependendo do grau das mudanas, pode no ser necessrio modicar o gerador, o que uma tarefa mais complexa e propensa a erros. Adaptaes menores podem ser feitas diretamente na classe Facade. Para proteger o gerador de mudanas maiores no cdigo gerado, e algumas vezes simplicar o gerador, o padro Adapter (GAMMA et al., 1995) pode ser utilizado, para coletar, ltrar e/ou preparar a informao necessria para o cdigo gerado. Mudanas mais simples como no formato de dados ou na assinatura dos mtodos no se propagam para o gerador. Cdigo no-gerado depende de cdigo gerado: Isto acontece quando cdigo no-gerado espera que um comportamento ou estrutura seja gerado. completamente possvel e algumas vezes necessrio esse tipo de padro de integrao, mas fazer com que um cdigo no-gerado dependa diretamente de cdigo gerado pode levar a problemas. O programa pode no compilar antes da gerao completa de cdigo. Objetos de exemplo podem ser manualmente criados temporariamente, mas em geral isto adiciona um nvel a mais de diculdade para testes/manuteno. Alm disso, erros no previstos so mais provveis de acontecer dependendo de como o cdigo gerado varia, pois difcil prever todas as possibilidades. Estes padres visam reduzir estes problemas. Na maioria dos casos, padres como o Template method ou Factory (GAMMA et al., 1995) podem ser utilizados, de forma que o cdigo no-gerado no precise saber detalhes sobre como as classes e mtodos que o mesmo utiliza so implementados, se so gerados ou construdos manualmente. Porm, em algum momento, uma implementao concreta precisa ser providenciada, pois de outra forma o cdigo no ir compilar e executar completamente.

135

Nesses casos, possvel remover a dependncia entre cdigo no-gerado e gerado por meio dos padres de Injeo de dependncia ou Localizador de servio (FOWLER, 2004). Estes padres removem as dependncias do cdigo (neste caso, do cdigo no-gerado) e as colocam em agentes externos, responsveis pela injeo das dependncias atravs de congurao programtica ou textual (normalmente XML). As dependncias devem ainda ser denidas em algum lugar, mas uma vez que isto s ocorre em uma entidade separada, estas so explcitas, sendo tambm mais facilmente denidas, o que acaba melhorando o entendimento do cdigo nal. O cdigo original pode ser compilado independentemente, facilitando testes e manuteno. Alm disso, o cdigo de congurao poderia ser gerado, de forma que at o processo de injeo seja automatizado. Por exemplo, possvel gerar arquivos de congurao para frameworks de injeo de dependncia como o Spring1 . Estes padres assumem que h um elemento xo entre os dois lados da dependncia: uma interface, uma classe abstrata ou uma assinatura de mtodo. Porm, h casos onde at mesmo as assinaturas dos mtodos so geradas, como por exemplo um gerador que produz objetos de acesso a dados (Data Access objects - DAO), com mtodos para realizar operaes bsicas de insero, remoo e consulta. Cada DAO possui seus prprios conjuntos de mtodos com diferentes assinaturas dependendo dos nomes e atributos das entidades. Nestes casos, tcnicas de reexo podem ser a nica soluo para remover dependncias em tempo de compilao. Atravs da reexo, possvel transformar todas as chamadas de mtodos de cdigo no-gerado para cdigo gerado em chamadas reexivas, de forma que o mtodo sendo chamado desconhecido pelo compilador. Cdigo gerado depende de cdigo gerado: isto normalmente acontece quando h dois subdomnios que dependem um do outro. Um problema que surge do relacionamento entre mltiplos subdomnios como garantir a integridade deste relacionamento. Uma possibilidade utilizar os nomes dos elementos como referncias, isto , o nome de uma referncia em um modelo deve ser idntico ao nome do elemento referenciado, em outro modelo. Apesar de no ser ideal, esta abordagem simplica o processo de se implementar referncias entre modelos. efetivamente utilizada devido sua praticidade, sendo encontrada em exemplos como Apache OFBiz e algumas Microsoft DSL Software Factories (HESSELLUND; CZARNECKI; WASOWSKI, 2007). Outra opo so as pontes entre modelos, que consistem na criao de duplicatas de elementos, no metamodelo que contm a referncia, que correspondem a elementos do metamodelo referenciado.
1 ttsrsrr

No exemplo do domnio web de autoria de contedo,

136

isto corresponde criao, no metamodelo de navegao, de um elemento chamado ReferenciaParaTipoDeDocumento, que pode ser utilizado para estabelecer referncias para o elemento TipoDeDocumento do metamodelo de autoria. Um vericador separado pode ento ajudar a garantir que estas referncias sejam vlidas (WARMER; KLEPPE, 2006). Cdigo gerado precisa ser estendido: um exemplo tpico a gerao de esqueletos de classes que precisam ser manualmente implementados aps a gerao. Seja qual for a tcnica sendo utilizada, uma recomendao importante a de que a modicao manual do cdigo gerado no deveria ser necessria (TOLVANEN, 2004; VLTER;
BETTIN, 2004).

Mesmo com tcnicas de merging (mesclagem), como os blocos de usurio do

JET (Java Emitter Templates (POPMA, 2004)), esta no uma boa prtica porque depende da existncia de cdigo que marca os locais onde o cdigo manual comea e onde termina. Se este cdigo for removido por alguma razo, o cdigo manual pode ser perdido aps a regenerao. Assim, tcnicas de merging somente devem ser utilizadas quando estritamente necessrias, e de preferncia com mecanismos que protegem o cdigo manual de modicaes acidentais (WARMER; KLEPPE, 2006). As melhores tticas para evitar esta situao incluem a gerao de classes abstratas ou interfaces, e a utilizao de subclasses para implementar as partes faltantes. Tcnicas como as receitas (recipes) do openArchitectureWare, que consistem na exibio de avisos sobre os passos a serem seguidos para completar o cdigo, podem ajudar a garantir uma implementao manual correta. Um padro til nestas situaes chamado merging de geradores. A ttica por trs deste padro criar um modelo separado para a especicao das partes faltantes, e ento combinar estes modelos utilizando um gerador especco. A Figura 23 ilustra a idia.

Figura 23: Merging de geradores envolvendo modelos estruturais e comportamentais Neste exemplo, dois tipos de geradores para modelos estruturais e de comportamento so combinados para produzir cdigo que no precisa ser manualmente completado. O

137

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

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

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

2003).

Nesta atividade, so tambm descritas as interfaces dos mdulos recm criados. Alm das informaes requeridas/providas para que cada mdulo seja capaz de executar sua responsabilidade, so descritos tambm os requisitos e funes que devem ser atendidos por

138

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

Atividade PD.5. Avaliao arquitetural

Papis: Projetista do domnio, especialista do domnio, demais stakeholders Entradas: PT.7. Diretrizes arquiteturais e PT.8.Inicial. Projeto do domnio Sadas: PT.9.Avaliado. Projeto do domnio Descrio: a abordagem segue o raciocnio do mtodo PuLSE-DSSA (DEBAUD; FLEGE;
KNAUBER, 1998), no sentido em que o projeto arquitetural pode produzir mltiplas arquiteturas,

cada uma oferecendo uma alternativa para se atender s diferentes diretrizes. Uma atividade ento responsvel por avaliar as alternativas e selecionar qual delas segue adiante no processo. A avaliao arquitetural deve ser iniciada quando a equipe de desenvolvimento comear a tomar decises que dependem da arquitetura, e o custo de se desfazer tais decises maior do que o custo de se realizar a avaliao (CLEMENTS; KAZMAN; KLEIN, 2004). Nesta abordagem, estas decises so referentes automao dos subdomnios, utilizando ferramentas de modelagem e transformadores, que depende desta estrutura em comum para possibilitar a reutilizao. Assim, esta atividade busca avaliar as alternativas de arquiteturas projetadas anteriormente. O objetivo selecionar aquela que melhor atende aos requisitos para o domnio, com foco na variabilidade. Este pode parecer um passo desnecessrio, uma vez que na atividade anterior o projeto arquitetural foi realizado com base em um conjunto de diretrizes que representam os mesmos requisitos. A diferena, no entanto, que agora sero includos os pontos de vista dos outros interessados no domnio, para serem confrontados com os requisitos iniciais, o que potencialmente ir revelar alguns aspectos que foram ignorados pelo projetista. Este confronto ir no somente facilitar a seleo de uma arquitetura adequada por meio

139

de consenso entre todos os envolvidos, como tambm ir resultar em possveis sugestes de alterao na arquitetura, visando atender os cenrios no originalmente previstos. Assim, esta atividade tambm pode ser vista como uma atividade de melhoria e evoluo da arquitetura. Esta atividade inspirada no SAAM (Software Architecture Analysis Method ou Mtodo de Avaliao de Arquitetura de Software) (CLEMENTS; KAZMAN; KLEIN, 2004), com 3 passos: 1. Desenvolver cenrios: cenrios, conforme discutido anteriormente, capturam os

principais requisitos e funcionalidades que devem ser atingidos pela arquitetura. Alguns j foram denidos anteriormente, incluindo os casos de uso, de mudana e os principais requisitos de qualidade. Estes foram elaborados principalmente pelo projetista e especialista do domnio. Aqui, o foco tentar reduzir o nmero de cenrios para aqueles que possuem impacto na arquitetura, e tentar incluir o ponto de vista de outros stakeholders, tais como usurios nais, gerentes, testadores, etc. Pode-se utilizar sesses de brainstorming para capturar o mximo de informao possvel; 2. Avaliar cenrios individualmente: neste passo, a exemplo do mtodo SAAM

citeClements:2004:book:evaluating, cada cenrio avaliado de forma individual, por meio de workshops mediados pelo projetista, onde se discute como o cenrio est ou no sendo atendido pelas diferentes arquiteturas. Pode-se tambm desenvolver prottipos (DEBAUD; FLEGE; KNAUBER, 1998) com funcionalidades simuladas que reetem o cenrio sendo avaliado. Para cada cenrio o projetista descreve como a arquitetura oferece o suporte, ou descreve as mudanas necessrias; e 3. Avaliar interao entre os cenrios: uma vez que se tenha as descries de mudanas referentes ao suporte aos cenrios, este passo tem como objetivo destacar quais cenrios interagem entre si, isto , exigem mudanas no mesmo local ou grupo de mdulos/componentes. reas onde existe grande interao entre cenrios podem signicar pontos onde o projetista falhou em corretamente implementar a separao de interesses, e portanto pode ser necessria maior ateno nesta rea, ou mesmo uma nova passagem pelas atividades de projeto (CLEMENTS; KAZMAN; KLEIN, 2004). O resultado destes passos uma lista que descreve como cada arquitetura atende aos requisitos conforme expressos pelos stakeholders. Para cada arquitetura, pode-se calcular: Nmero de cenrios diretamente suportados: para cada arquitetura, conta-se o nmero de cenrios que foram avaliados como possuindo suporte direto da arquitetura, sem necessidade de alteraes. Este nmero deve considerar o peso de cada cenrio, conforme estipulado no passo 1 descrito anteriormente;

140

Nmero de cenrios indiretamente suportados: para cada arquitetura, conta-se o nmero de cenrios que requerem alguma alterao para passarem a possuir o suporte adequado pela arquitetura. Este nmero deve considerar o peso de cada cenrio, conforme estipulado no passo 1 descrito anteriormente; e Quantidade de mudanas: para cada arquitetura, estima-se a quantidade de mudanas necessrias para que a mesma passe a oferecer suporte a todos os cenrios indiretos. Esta quantidade pode ser medida em termos de nmero de mdulos/componentes modicados ou, caso j existam mais detalhes sobre a arquitetura, at mesmo o nmero de classes envolvidas nas mudanas. De posse destes nmeros, possvel determinar qual das alternativas oferece o melhor suporte global para os requisitos. A alternativa que apresentar o melhor suporte aos cenrios, e menor quantidade de mudanas, ser selecionada para seguir adiante. Uma vez selecionada a arquitetura, retorna-se s atividades PD.2 e PD.3, buscando novas tticas/padres arquiteturais para implementar as mudanas sugeridas nesta avaliao. Este ciclo se repete at no serem necessrias mais mudanas para atender aos cenrios. Aps esta atividade, tem-se a arquitetura projetada e avaliada com base nas informaes disponveis at o momento. No entanto, conforme j mencionado anteriormente, este um processo iterativo, e a arquitetura pode vir a sofrer alteraes posteriormente. Na realidade, o que acontece uma iterao em duas vias: a arquitetura inuencia a implementao das DSLs e transformadores, que por sua vez podem inuenciar a arquitetura, resultando em mudanas que melhor acomodem a presena destes novos artefatos.

6.3 Consideraes nais

Neste captulo foi apresentada a fase de projeto de domnio, com atividades para promover a reutilizao atravs do MDD. As principais contribuies deste captulo so as atividades para denio das diretrizes e padres arquiteturais especcos para o uso do MDD na reutilizao de software: variabilidade baseada em features, variabilidade baseada em DSLs e integrao entre subdomnios. Tambm apresenta uma atividade de avaliao arquitetural visando melhorar o resultado do projeto antes da implementao ter iniciado. O Quadro 10 resume as atividades do projeto de domnio. O Quadro 11 descreve os produtos de trabalho da fase da projeto de domnio. O produto do projeto de domnio a denio da arquitetura e seus componentes. Nesta

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

PD.2. Seleo das diretrizes arquiteturais PD.2.1. Seleo das diretrizes arquiteturais de variabilidade baseada em features PD.2.2. Seleo das diretrizes arquiteturais de variabilidade baseada em DSLs PD.2.3. Seleo das diretrizes arquiteturais de integrao entre subdomnios PD.3. Escolha de tticas e padres arquiteturais PD.3.1. Padres arquiteturais para variabilidade baseada em features PD.3.2. Padres arquiteturais para variabilidade baseada em DSLs PD.3.3. Padres de integrao entre subdomnios PD.4. Aplicao dos padres arquiteturais e renamento dos mdulos PD.5. Avaliao arquitetural

PT.7. Diretrizes arquiteturais

PT.8. Tticas arquiteturais

padres

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

PT.9.Inicial. Projeto do domnio

PT.9.Avaliado. Projeto do domnio

Quadro 10: Resumo das atividades para projeto de domnio orientado a modelos abordagem, alm de componentes de software tradicionais, a arquitetura comporta a existncia de artefatos como DSLs, transformaes e geradores de cdigo.

142

Produto de trabalho PT.6. Mdulos a serem renados

PT.7. Diretrizes arquiteturais

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

Descrio Consiste na denio dos mdulos a serem renados em uma determinada iterao do projeto do domnio. Iniciando com o domnio todo, a cada etapa um ou mais mdulos so renados e produzem uma nova verso da arquitetura do domnio Conjunto de requisitos importantes para a denio da arquitetura. Consiste em objetivos de negcio, casos de uso, cenrios e linguagens que descrevem a variabilidade, alm de uma lista de dependncias entre os subdomnios Descrevem solues para problemas comuns no projeto arquitetural orientado a modelos Resultado da fase de projeto, este produto de trabalho engloba a denio da arquitetura, com os mdulos e sub-mdulos, e a especicao das interfaces, considerando a existncia de componentes tradicionais, e artefatos do MDD, como DSLs, ferramentas, transformaes e geradores de cdigo

Estado Nenhum

Nenhum

Nenhum 1. Inicial: verso inicial do documento, gerada somente pelo projetista com o auxlio do especialista. Pode conter inconsistncias ou no cumprir cenrios que sejam importantes a algum outro stakeholder 2. Avaliado: projeto avaliado por uma atividade especca, que considera o ponto de vista de diversos stakeholders

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

143

Implementao de domnio orientada a modelos

A anlise de domnio e projeto arquitetural, realizados em fase anterior, lidam com questes como qual a melhor maneira de dividir o domnio em sub-sistemas ou como os mdulos devem interagir entre si de forma a maximizar o desempenho na execuo de determinada tarefa crtica. Porm, questes de mais baixo nvel ainda permanecem no-resolvidas, tais como: qual tecnologia de comunicao deve ser utilizada em um domnio distribudo? Como ser o acesso base de dados? Como a internacionalizao ser alcanada? Qual algoritmo de busca deve ser utilizado? Estas so o foco da etapa de implementao do domnio, que nesta abordagem tambm engloba o renamento do projeto de alto nvel em um projeto detalhado. Entre as questes a serem respondidas, destaca-se o suporte variabilidade. Como os componentes do domnio iro dar suporte aos diferentes pontos de variao? Esta questo comeou a ser respondida durante o projeto, e agora necessrio tomar as decises nais quanto ao projeto detalhado. Alm disso, sendo esta uma abordagem orientada a modelos, necessrio tambm implementar os artefatos especcos do MDD. Assim, a implementao deve tambm produzir linguagens especcas de domnio, transformaes e geradores de cdigo. Nesta tese, entende-se por gerador de cdigo qualquer artefato capaz de produzir automaticamente, com base em uma especicao de entrada, um trecho de cdigo como sada. Este trecho de cdigo pode ser qualquer tipo de elemento textual, mas normalmente corresponde a um programa escrito em uma linguagem de programao. Segundo esta denio, um processador automtico de templates, como o JET, um gerador de cdigo. Mas um arquivo contendo um template tambm considerado um gerador de cdigo, uma vez que este possui instrues especcas que inuenciam diretamente no cdigo gerado. Enquanto as fases de anlise (ARANGO, 1999; PRIETO-DAZ, 1990; KANG et al., 1990;
FRAKES; PRIETO-DAZ; FOX, MEI; ZHANG; GU,

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

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

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

144

domnio para reutilizao so amplamente discutidas pela comunidade cientca, a rea de implementao apresenta algumas lacunas que precisam ser preenchidas (ALMEIDA et al., 2008;
ANASTASOPOULOS; GACEK,

2001). Uma das razes que a engenharia de domnio tem suas

razes na comunidade de reutilizao de software, que favorece uma abordagem top-down (PATZKE; MUTHIG, 2002), dando mais nfase anlise e projeto. Outra razo o fato de que, para denir um processo genrico, deve ser possvel generalizar detalhes especcos de plataforma e linguagem, de forma que o processo possa ser utilizado independentemente da tecnologia de implementao. Ao mesmo tempo, a implementao extremamente dependente da tecnologia (ALMEIDA et al., 2008), fazendo com que esta generalizao seja uma luta entre foras opostas. Como resultado, observa-se uma falta de orientao com relao s atividades para implementao de um domnio para reutilizao (PATZKE; MUTHIG, 2002). H inmeras tcnicas para se implementar domnios reutilizveis, como aquelas descritas na Seo 3.2.1. Estas podem ser divididas em trs dimenses: gerenciamento de congurao, tecnologias de componente e as caractersticas generativas das linguagens de programao (MUTHIG et al., 2002). Cada dimenso tem sua maneira particular para lidar com a variabilidade, que o desao mais notvel na implementao de um domnio reutilizvel. A dimenso de gerenciamento de congurao, por exemplo, gerencia as variantes alternativas de um mesmo artefato em um mesmo ponto no tempo (MUTHIG; PATZKE, 2004). A dimenso de tecnologia de componentes baseia-se na idia de componentes de software. Um componente , por denio, uma unidade de composio (MUTHIG et al., 2002), e portanto esta dimenso lida com a variabilidade atravs da composio das variantes requeridas na forma de componentes (KETTEMANN; MUTHIG; ANASTASOPOLOUS, 2003; MUTHIG; PATZKE, 2004). A tecnologia generativa (CZARNECKI; EISENECKER, 2000), foco desta tese, pode introduzir um controle mais poderoso sobre a variabilidade no domnio. Enquanto variaes dentro de um componente tradicional limitam-se a estruturas xas e interfaces previamente projetadas, a tecnologia generativa possibilita variao em menor granularidade, mesmo dentro de componentes. Fragmentos de cdigo variante podem ser sistematicamente arranjados para formar a implementao de um componente (MUTHIG; PATZKE, 2004).

7.1 Objetivos da implementao do domnio

O objetivo desta fase implementar o domnio, ou seja, implementar componentes, DSLs, transformaes e geradores de cdigo, seguindo o projeto denido na fase anterior.

145

Alm disso, existe uma srie de critrios que precisam ser atendidos pela implementao de um domnio, dos quais se destacam aqueles que resultam da necessidade de um bom gerenciamento da variabilidade (ANASTASOPOULOS; GACEK, 2001; MATOS JR, 2008; MUTHIG;
PATZKE,

2003, 2004):

1. Minimizar duplicao de cdigo: deve-se provocar pouca ou nenhuma duplicao de cdigo ao implementar a variabilidade; 2. Esforo de reutilizao: a implementao deve permitir a reutilizao de forma simples e com pouco esforo, seguindo o princpio de que se for mais trabalhoso reutilizar do que construir, a reutilizao no ir acontecer; 3. Separao de interesses: separao entre variantes e cdigo comum, de forma que mudanas podem ser feitas separadamente em ambos os cdigos; 4. Desempenho: a implementao deve proporcionar desempenho do produto nal de acordo com os requisitos. 5. Diferentes tipos de cdigo-fonte: os mecanismos normalmente citados na literatura so fortemente atrelados a uma linguagem de programao, e normalmente utilizam conceitos de orientao a objetos. Porm, padres de projeto, herana, polimorsmo e orientao a aspectos, entre outros exemplos, fazem pouco sentido em artefatos como pginas HTML, scripts de criao de banco de dados, arquivos de congurao, stored procedures, entre outros tipos de artefatos de implementao que no so baseados em uma linguagem de programao. Obviamente, ainda possvel algum tipo de controle como, por exemplo, a extenso de uma pgina HTML com scriptlets que implementam a incluso condicional de partes de texto correspondentes a variantes especcas. Porm, esta opo mais indicada para variaes em tempo de execuo, no sendo adequada para as variaes em tempo de compilao, que o foco desta tese. Como resultado, nestes casos faz-se necessrio o gerenciamento manual da variabilidade; e 6. Variabilidades complexas: conforme discutido no Captulo 6, podem existir alguns casos de variabilidades mais complexas do que a modelagem de features capaz de representar. Normalmente, so pontos de variao abertos, nas quais no possvel determinar um limite para a presena ou ausncia de features, a sua implementao requer um esforo criativo composicional manual durante o desenvolvimento das aplicaes. Apesar de ser possvel facilitar este esforo atravs de padres como factories (GAMMA
et al.,

1995) ou outras tcnicas similares, o mesmo no pode ser completamente

automatizado utilizando somente tais mecanismos.

146

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

7.2 Atividades da implementao do domnio

Inicialmente, cada subdomnio identicado durante a anlise de domnio caracterizado em termos de sua variabilidade (Atividade ID.1). Em seguida so denidas as DSLs e o suporte ferramental (ferramentas de modelagem e editores especcos de domnio) (Atividade ID.2), por meio de uma abordagem top-down que utiliza os modelos de features para denir as DSLs para cada subdomnio. A seguir as DSLs so renadas, e as transformaes so construdas (Atividade ID.3), utilizando uma abordagem bottom-up e uma implementao de referncia como ponto de partida. Esta implementao de referncia ento transformada em um framework de domnio (Atividade ID.4), contendo classes e componentes reutilizveis que do suporte para algumas das variabilidades. reutilizao. A seguir estas atividades so descritas de forma detalhada. Finalmente, os artefatos construdos so documentados (Atividade ID.5) de forma a facilitar seu entendimento, manuteno e

Atividade ID.1. Caracterizao da variabilidade dos subdomnios

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

a subdomnio, PT.5.

Histrico de decises sobre incluso/excluso de subdomnios,

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

147

sua variabilidade, visando dar subsdios implementao do suporte em termos de modelagem, transformaes e geradores de cdigo para sua automao. Conforme discutido no Captulo 6, existem diferentes tipos de variabilidade, que so caracterizados de acordo com um espectro entre congurao de rotina e construo criativa. Nesta atividade, cada subdomnio analisado e inserido em um determinado local deste espectro. A Figura 24 ilustra esta estratgia. Para todo o domnio, uma ferramenta de features normalmente utilizada, junto com uma ferramenta de congurao automtica. Alguns subdomnios podem exigir uma soluo baseada em uma DSL completa, incluindo uma ferramenta de modelagem e geradores dedicados. Em outros, um simples wizard pode ser suciente.

Figura 24: Estratgia de caracterizao de subdomnios Para inserir cada subdomnio em algum lugar do espectro de variabilidade, o papel do especialista do domnio muito importante, mas as seguintes diretrizes podem ser teis: D1 . Procurar por conguraes de features que no mudam entre as aplicaes: se uma feature representa um ponto de variao, sua congurao deve mudar de alguma forma quando as diferentes aplicaes variam com relao a este ponto. Por exemplo, se uma aplicao web prov busca avanada, e uma segunda aplicao prov busca simples, as conguraes das features para estas aplicaes sero diferentes. Isto indica que a variabilidade pode ser representada como features. Porm, se duas aplicaes diferem em algum ponto, mas as conguraes das features que descrevem aquele ponto so as mesmas, isto pode indicar que

148

h alguma variabilidade que no pode ser representada como features, e talvez seja necessria uma DSL. Por exemplo, considere duas aplicaes web com suporte para busca avanada. Na primeira, possvel buscar por contedo de usurio pelo autor, data e palavras-chave. Na segunda, possvel buscar pelo autor, tipo do contedo, palavras-chave e outros metadados especcos desta aplicao. Neste exemplo, ambas as conguraes iro apresentar a feature Busca avanada, apesar de possurem detalhes distintos. D2 . Analisar as features de tecnologia do domnio: features de tecnologia do domnio representam as maneiras de se implementar os servios ou operaes do domnio (LEE; KANG;
LEE,

2002). Eles so alguns dos blocos de construo sobre os quais a implementao

realizada, e normalmente necessrio um processo de construo criativa para combin-los de forma a satisfazer os requisitos da aplicao. Portanto, h uma chance de que a variabilidade associada seja aberta. Por exemplo, as seis features de tecnologias de domnio localizadas no lado inferior da Figura 25 no podem ser meramente selecionadas ou de-selecionadas. Ao contrrio, elas precisam ser combinadas de forma criativa ao se congurar um produto.

Figura 25: Modelo de features do domnio web de autoria de contedo D3 . Procurar por mquinas de estados: muitos subdomnios podem ser representados por mquinas de estados, como as telas de um jogo ou o comportamento de uma entidade. Se for este o caso, este subdomnio ir provavelmente requerer uma DSL (mquina de estados) para sua variabilidade. D4 . Procurar por estruturas hierrquicas e de conteno: relacionamentos do tipo parte-de so comuns em um domnio. Apesar de normalmente poderem ser representados no

149

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

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

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

a subdomnio e PT.5.

Histrico de decises sobre incluso/excluso de subdomnios,

PT.9.Avaliado. Projeto do domnio, PT.10. Subdomnios caracterizados Sadas: PT.11.Inicial. ferramental para DSLs Descrio: dependendo do tipo de variabilidade para cada subdomnio, a DSL associada ser mais ou menos complexa. Em casos de variabilidade mais simples, baseada em features, a DSL pode ser composta por smbolos que representam features individuais, para indicar sua presena ou ausncia. Czarnecki, Helsen e Eisenecker (2004a) propem um mtodo para derivar uma gramtica livre de contexto para um modelo de features. Este mtodo pode ser utilizado para criar uma DSL capaz de descrever todos os tipos de variabilidade caracterstica a um modelo de features. Um gerador de parsers ou um framework de DSLs pode ser utilizado para criar o suporte linguagem mais facilmente, suprindo a necessidade de ferramentas. Em casos de variabilidade mais complexa, a DSL deve denir quais conceitos podem ser utilizados, como eles se relacionam entre si, e possveis restries que possam existir. Isto pode Linguagens especcas de domnio, PT.12.Inicial. Suporte

150

ser realizado exclusivamente de forma top-down. Porm, a DSL deve tambm ser capaz de produzir modelos que sirvam de entrada para transformadores e geradores, o que inclui muitos detalhes que so especcos plataforma e arquitetura escolhidas. muito difcil perceber tais detalhes sem investigao mais aprofundada na implementao, e portanto uma abordagem bottom-up utilizada para renar esta DSL inicial. Esta atividade corresponde parte top-down do desenvolvimento da DSL. Conforme discutido na Seo 3.1.2, uma DSL pode ser textual (programas) ou visual (diagramas), e normalmente composta de trs elementos: a sintaxe abstrata, a sintaxe concreta e a semntica. Esta atividade cuida do desenvolvimento das sintaxes abstrata e concreta da DSL, alm de ferramentas que permitam a criao de instncias (programas ou diagramas) da DSL. Em DSLs textuais, as sintaxes abstrata e concreta so normalmente representadas atravs de regras lxicas e gramaticais. Em DSLs visuais, a sintaxe abstrata corresponde ao metamodelo (GUIZZARDI; PIRES; SINDEREN, 2002) e a sintaxe concreta corresponde aos aspectos visuais dos elementos, normalmente utilizando guras, cones, linhas, setas, entre outras representaes grcas. Para representar corretamente sua variabilidade, um subdomnio pode exigir um sistema de conceitos (sintaxes abstrata e concreta) totalmente diferente da modelagem de features, possivelmente exigindo tambm uma ferramenta de modelagem mais complexa. Mas mesmo no sendo suciente para identicar conceitos de uma DSL (TOLVANEN; KELLY, 2005), um modelo de features pode servir de ponto de partida (CZARNECKI, 2005), sendo posteriormente complementado com informaes de outros artefatos, como a arquitetura do domnio e o conhecimento do especialista (TOLVANEN; KELLY, 2005). O desenvolvimento de DSLs considerado uma cincia parte (CZARNECKI; EISENECKER, 2000), dada sua complexidade. Alm disso, no um processo muito previsvel, pois exige criatividade (VISSER, 2007). Esta abordagem busca prover alguma orientao, atravs de cinco sub-atividades, apresentadas a seguir. Sub-atividade ID.2.1. Identicao das features iniciais da DSL O primeiro passo identicar as features que iro dar incio formao da sintaxe abstrata da DSL. Como descrito na atividade ID.1, os servios e funes do domnio so normalmente descritos em termos de features de tecnologia do domnio, e portanto estas so boas candidatas a fazer parte de uma DSL. Considere por exemplo o domnio web de autoria de contedo mostrado na Figura 26A. Neste domnio, dois subdomnios podem ser identicados: navegao (Contedo, Busca, Busca simples, Busca avanada, Contedo de usurio, Pgina, Formulrio,

151

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

Figura 26: Denio do metamodelo da DSL de autoria Web

Sub-atividade ID.2.2. Denio da sintaxe abstrata No segundo passo, as features identicadas so analisadas de forma mais aprofundada, para determinar como elas se relacionam entre si, e se conceitos adicionais so necessrios. Estes conceitos adicionais so descritos em um metamodelo, que corresponde sintaxe abstrata da DSL. Por exemplo, a Figura 26B mostra o metamodelo obtido para o subdomnio de autoria web. Elementos sombreados so derivados diretamente do modelo de features. Alm das features Autoria, Tipo de documento e Relacionamento, este metamodelo contm os relacionamentos entre elas, e novos conceitos, como Autor e Campo. Para auxiliar na denio do metamodelo, as seguintes regras podem ser utilizadas como guia:

Uma feature (normalmente, uma feature de tecnologia de domnio) mapeada em um conceito da DSL. Um conceito pode ser uma metaclasse em um metamodelo, caso se trate de uma DSL visual, ou uma regra de produo em uma gramtica, caso se trate de uma DSL textual; Sub-features podem ser mapeadas como propriedades do conceito que as contm. Podem ser metaatributos em um metamodelo ou uma regra de produo ou atributo gramatical;

152

Sub-features podem tambm ser mapeadas como conceitos separados, com relaes parte-de adicionais sendo utilizadas para representar a conteno. Um relacionamento em um metamodelo corresponde a uma associao ou agregao, enquanto em linguagens textuais pode ser representado como uma regra de produo; Propriedades de conceitos podem precisar de tipos especiais do domnio, em vez dos tipos tradicionais como inteiro ou string. Por exemplo, sub-features opcionais ou do tipo or podem ser mapeadas como enumeraes do domnio. Por outro lado, uma propriedade pode pertencer a tipos personalizados, como Ponto e Tamanho; e Features relacionadas podem ser conectadas por um conceito novo que descreve a relao, as cardinalidades, os conceitos participantes e seus papis na relao. A anlise de dependncia de features (LEE; KANG, 2004) pode ser usada para identicar tais relaes inicialmente, mas novas podem aparecer posteriormente. Sub-atividade ID.2.3. Denio da sintaxe concreta O terceiro passo corresponde denio da sintaxe concreta, o que no uma tarefa muito complexa. Em DSLs textuais externas (FOWLER, 2005), a sintaxe concreta fortemente acoplada sintaxe abstrata, aparecendo na forma de palavras reservadas e tokens descritos na gramtica da linguagem. Se uma DSL interna (FOWLER, 2005) utilizada, ento as construes da linguagem que contm a DSL devem ser analisadas para determinar se podem representar os conceitos do domnio de forma adequada. Em DSLs visuais, blocos decorados e linhas so a notao padro. Formas geomtricas especcas, como retngulos e elipses, ou imagens, podem tambm ser utilizadas para representar os conceitos da DSL de forma mais intuitiva e natural. As seguintes regras podem ser utilizadas na criao desta notao: Features que so mapeadas para os conceitos do domnios podem ser representadas como blocos; Relacionamentos entre features podem ser representados como linhas; Sub-features que so mapeadas a valores booleanos podem ser representadas como decoraes nos blocos (como uma borda diferenciada), atributos (como um cone na frente de um elemento) ou linhas (como um losango em uma das terminaes); Sub-features que so mapeadas a valores do tipo string podem ser representadas como decoradores textuais, como um texto dentro de um bloco ou sobre uma linha; e

153

Sub-features que representam listas de itens podem ser representados como compartimentos em blocos (como os mtodos e atributos da UML, por exemplo).

Sub-atividade ID.2.4. Denio da integrao inter-DSL O quarto passo lida com a integrao entre diferentes DSLs, o que um problema que surge quando se lida com mltiplos subdomnios. A integrao inter-DSL deve ser gerenciada de forma que o desenvolvedor possa especicar modelos em ambas as linguagens utilizando conceitos que se relacionam. Por exemplo, no domnio web de autoria de contedo, uma pgina de formulrio (do subdomnio de navegao) pode se referir a um tipo de documento (do subdomnio de autoria). Referncias baseadas em nome ou pontes entre modelos (WARMER; KLEPPE, 2006) so mecanismos simples que resolvem estes problemas. Referncias baseadas em nome consistem em um simples atributo do tipo string, na DSL que contm a referncia, que aponta para o nome de um elemento na DSL sendo referenciada. As checagens de tipo e integridade referencial devem ser feitas manualmente. Pontes entre modelos no so muito mais poderosas, consistindo na criao de um elemento, na DSL que contm a referncia, que uma cpia exata de um elemento na DSL sendo referenciada. Esta tcnica propicia a checagem de tipos, mas a checagem de integridade referencial ainda precisa ser realizada manualmente. Caso necessrio, uma soluo mais poderosa apresentada por Hessellund, Czarnecki e Wasowski (2007), que propem o uso de regras lgicas para estabelecer relaes inter-DSL. Desta forma, consultas de mais alto nvel podem ser realizadas, facilitando a checagem da consistncia.

Sub-atividade ID.2.5. Construo da ferramenta de modelagem especca de domnio Uma vez que as sintaxes abstratas e concretas estejam denidas, uma ferramenta de modelagem especca para a DSL construda. Frameworks de DSLs, como GMF ou openArchitectureWare, entre outros, so a tecnologia mais apropriada para a implementao da ferramenta, uma vez que eles exigem pouco conhecimento na construo de linguagens para se alcanar resultados prticos rapidamente. Porm, DSLs mais complexas podem exigir uma participao mais ativa de um especialista em linguagens. Esta ltima sub-atividade tambm inclui a denio de validaes para capturar erros semnticos durante a modelagem, orientando o desenvolvedor na criao de diagramas ou programas segundo a DSL em questo (VLTER, 2008). Por exemplo, uma validao semntica

154

pode garantir que o comportamento de uma entidade em um jogo, modelada atravs de uma DSL visual, sempre tenha um comportamento padro denido. Aps este quinto passo, obtm-se um conjunto de DSLs e ferramentas que permitem que um desenvolvedor represente diferentes tipos de variabilidade em cada subdomnio identicado, desde casos mais simples, baseada em features, at a variabilidade mais complexa. Mas as DSLs ainda no esto completas, pois at agora somente uma abordagem top-down foi utilizada. Podem existir detalhes adicionais que precisam ser includos antes que a DSL sirva de entrada para transformaes e gerao de cdigo. aqui que uma abordagem bottom-up entra em cena.

Atividade ID.3. Desenvolvimento das transformaes e renamento das DSLs (bottom-up)

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

a subdomnio, PT.5.

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

Projeto do domnio, PT.10.

Linguagens especcas de domnio, PT.12.Inicial. Suporte ferramental para DSLs Sadas: PT.11.Renado. Linguagens especcas de domnio, PT.12.Renado. Suporte ferramental para DSLs, PT.13. referncia Descrio: considerando-se somente seu poder representativo, uma DSL composta somente pela sintaxe (abstrata e concreta). A sintaxe abstrata voltada para interpretadores automticos, enquanto a sintaxe concreta projetada para ser usada por seres humanos, na criao de instncias da DSL (diagramas ou programas). Mas para ser til no cenrio do MDD, um terceiro elemento deve estar presente: a semntica, que dene o signicado dos elementos da linguagem. No contexto do MDD, a semntica denida em forma de aes a serem executadas por um interpretador automtico, que traduz o modelo (programa ou diagrama) em outra linguagem bem conhecida (KLEPPE, 2007). No contexto da engenharia de domnio, a semntica adquire ainda outra importncia, associada variabilidade do domnio. Transformaes de software so responsveis por traduzir a variabilidade expressa em uma DSL em cdigo concreto, de forma que o software gerado implemente as variantes selecionadas corretamente. Transformaes do domnio, PT.14. Implementao de

155

At o momento, uma abordagem top-down foi seguida, utilizando modelos de alto nvel, como o modelo de features, para produzir um conjunto inicial de DSLs. Estas DSLs so capazes de representar diferentes tipos de variabilidade em diferentes subdomnios identicados durante a anlise. Agora, uma abordagem bottom-up adotada, utilizando o projeto atravs de exemplos (VARR, 2006; WIMMER et al., 2007; ROBBES; LANZA, 2008) para produzir transformaes e possivelmente renar as DSLs iniciais. Partir de uma instncia concreta de como o cdigo deve ser mais fcil do que identicar todos os detalhes a partir de uma perspectiva de mais alto nvel (ROBBES; LANZA, 2008). Esta atividade realizada em quatro passos, apresentados a seguir.

Sub-atividade ID.3.1. Desenvolvimento da implementao de referncia O primeiro passo consiste no desenvolvimento de uma implementao de referncia (MUSZYNSKI, 2005). Esta implementao de referncia ir assumir dois papis: primeiro, ir servir como um framework do domnio, encapsulando parte das comunalidades e oferecendo suporte a parte das variabilidades no nvel de implementao, atravs de mecanismos como aqueles apresentados na Seo 3.2.1 e padres como aqueles discutidos na atividade PD.3, da fase de projeto. A existncia de um framework facilita a gerao de cdigo, uma vez que o gerador no precisa gerar todo o cdigo, mas somente o cdigo necessrio para completar o framework. Para essa tarefa, o implementador do domnio, com a ajuda do especialista do domnio, segue a arquitetura denida na fase de projeto, utilizando as tticas e padres associados para produzir uma implementao que ir dar suporte ao desenvolvimento subsequente. Porm, nem toda comunalidade/variabilidade estar contida no framework. Assim, o segundo papel da implementao de referncia prover exemplos concretos das variabilidades restantes, servindo como um retrato do cdigo que as transformaes e geradores de cdigo devem produzir, completando assim o suporte automatizado variabilidade no domnio. Para isso, a implementao de referncia deve incluir exemplos de todos os pontos comuns e variveis do domnio. Isto mais fcil de ser alcanado para a variabilidade baseada em features, que nita. As seguintes diretrizes podem ser utilizadas com este objetivo: D1 . Comear implementando um exemplo completo que contm todas as features

mandatrias, e uma seleo arbitrria de uma feature em cada grupo de or features. Deixar todas as features opcionais no-implementadas.

156

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

EISENECKER,

considerando primeiro as features mais comuns, para reduzir o nmero de possibilidades e o nmero de verses produzidas a cada renamento. D6 . Dar maior ateno s variabilidades que possuem maior impacto na arquitetura, aquelas que so mais frequentes, e aquelas que exigem mais esforo para implementar manualmente. D7 . Para reduzir o nmero de verses da implementao de referncia e facilitar o

seu gerenciamento, pode-se implementar mltiplas variantes simultaneamente, desde que no interram uma com a outra. D8 . Nem todas as possibilidades precisam ser exploradas e implementadas no incio. Algumas podem ser postergadas para quando a implementao do domnio estiver mais avanada, ou mesmo aps o domnio estar em produo h algum tempo. D9 . Nem toda variabilidade precisa ser includa na implementao de referncia, para fazer parte de uma DSL. Algumas variabilidades podem ser deixadas de fora, sendo necessria a sua implementao manual, por ocorrerem muito raramente ou exigirem muito esforo para automatiz-las. D10 . Se existirem uma ou mais aplicaes do domnio disponveis, estas podem (e devem) ser consultadas durante o desenvolvimento da implementao de referncia. Pode-se inclusive reutilizar trechos de cdigo ou o suporte a alguma variabilidade que venha a estar j presente em alguma aplicao. Para variabilidades baseadas em DSL, mais complexas, esta tarefa mais difcil, j que

157

o nmero de combinaes de elementos do domnio literalmente innito. necessrio mais conhecimento do especialista para se produzir exemplos representativos. As seguintes diretrizes podem ajudar: D11 . Tentar explorar o espao de variabilidade de duas maneiras: utilizando aplicaes reais para derivar exemplos concretos da variabilidade, e tambm com extremos, como escolhas e combinaes incomuns dos elementos da DSL. D12 . Procurar popular atributos multivalorados e listas com mais de uma instncia, caso contrrio pode-se no perceber a existncia deste tipo de atributo mais tarde, durante a atividade de mapeamento. Por exemplo, se uma DSL prev a especicao de vrias entidades de dados, deve-se criar duas ou trs entidades de exemplo, e no somente uma. D13 . Explorar as diferentes dimenses e tipos de atributos. Deve-se usar tanto valores pequenos e grandes como exemplos de atributos. D14 . Resgatar produtos e aplicaes analisados durante a anlise de domnio, de modo a explorar a maneira como estes lidam com a variabilidade aberta. Deve-se utilizar este conhecimento como instncias a serem cobertas pela implementao de referncia. D15 . Caso algum tipo de variabilidade seja muito complexa para ser automatizada atravs do MDD, deve-se ento ao menos garantir que o cdigo gerado d suporte a algum tipo de mecanismo que permita a sua implementao manual. Deve-se experimentar estes mecanismos na implementao de referncia.

Sub-atividade ID.3.2. Inspeo de cdigo e mapeamento para elementos das DSLs O segundo passo consiste na inspeo do cdigo da implementao de referncia em busca de trechos que correspondam a elementos de alguma DSL do domnio. O objetivo identicar principalmente a presena de variantes no cdigo, e mape-las para as DSLs correspondentes. A incluso de uma variante no cdigo normalmente resulta em modicaes em diferentes artefatos. H quatro tipos de modicaes que podem co-existir em um domnio (ANASTASOPOULOS; GACEK, 2001):

Adio de novas funcionalidades: refere-se incluso de novos componentes, classes, funes, estruturas de dados ou trechos de cdigo. Esta a chamada variabilidade positiva. Por exemplo, no domnio web, a incluso da feature de busca pode resultar em um novo componente, uma caixa de texto na pgina principal e novas estruturas no banco de dados;

158

Remoo de funcionalidades: se refere remoo de componentes, classes, funes, estruturas de dados ou trechos de cdigo. a chamada variabilidade negativa. Por exemplo, no domnio web, a incluso da feature de busca pode resultar na remoo de um banner de propaganda do site, por falta de espao; Substituio de funcionalidades: se refere substituio de componentes, classes, funes, estruturas de dados ou trechos de cdigo. Pode-se considerar como uma combinao de variabilidades negativa e positiva. Por exemplo, a incluso da variante de busca avanada requer a substituio do componente de busca simples por um outro que implementa um algoritmo avanado; e Plataforma/ambiente: quando a incluso da variante requer modicaes na plataforma ou ambiente de execuo. Por exemplo, no domnio web, a incluso da feature de busca pode requerer a incluso de uma biblioteca especca, uma verso diferente do banco de dados, ou mesmo uma mquina virtual diferente. Esta atividade cuida da identicao exata destas alteraes. Essencialmente, esta uma atividade semelhante ao processo de comparao entre duas verses de um software que acontece em sistemas de controle de verses como CVS ou SVN. Compara-se cada exemplo que introduz uma variao com o exemplo original, registrando-se todas as alteraes, obtendo-se um delta que representa a incluso da variante. Na prtica, porm, a busca por tais alteraes exige um conhecimento aprofundado do cdigo e do domnio. A melhor maneira de encontr-las manter o registro das mudanas (ROBBES; LANZA, 2008) medida que so feitas nos exemplos construdos durante o desenvolvimento da implementao de referncia, por meio de um documento separado, ou mesmo com comentrios e anotaes no prprio cdigo. Cada trecho modicado do cdigo precisa ser mapeado em pelo menos uma variante descrita em uma DSL ou modelo de features. Se existir uma modicao, mas no existirem elementos em uma DSL que a descrevam, ento a DSL provavelmente precisa ser renada (sub-atividade ID.3.3). Em alguns casos, uma modicao pode aparentemente ser mapeada para diferentes elementos de uma ou mais DSLs, o que signica que esta modicao pode ser causada por diferentes variantes simultaneamente. Se for este o caso, deve-se tomar cuidado especial na implementao do suporte a estes pontos de variao quando ambos forem selecionados ao mesmo tempo. Finalmente, pode acontecer de muitas modicaes, em vrias partes da implementao de

159

referncia, serem mapeadas a um mesmo ponto de variao, o que signica que este elemento da DSL est espalhado em diferentes partes do cdigo. Caso existam muitas modicaes deste tipo, pode ser que a atividade de projeto no tenha produzido uma arquitetura adequada, e o uso de padres de projeto pode reduzir este espalhamento. Ou ento, este pode se tratar de uma preocupao ortogonal, caso em que tcnicas da orientao a aspectos podem ajudar (VLTER;
GROHER,

2007). Sub-atividade ID.3.3. Renamento das DSLs

Durante a inspeo de cdigo, o implementador do domnio pode descobrir que mais detalhes ou informaes precisam ser includos em uma DSL original antes que a mesma possa servir de entrada para transformaes e geradores de cdigo. Por exemplo, uma instncia concreta de uma pgina web pode revelar detalhes como a disposio visual dos elementos, diferentes escolhas de elementos de entrada, que podem ter passado despercebidos durante o desenvolvimento da DSL inicial. Alm disso, a inspeo pode identicar novos pontos de variao que no foram previstos durante a anlise inicial. Finalmente, a inspeo pode encontrar erros e inconsistncias com os conceitos iniciais e as variabilidades denidas na abordagem top-down. Nestes casos, uma ou mais DSLs precisam ser renadas, para introduzir novos elementos, modicar ou remover elementos existentes. Podem ser necessrias alteraes na sintaxe abstrata, quando o renamento for mais conceitual, alteraes na sintaxe concreta, quando o renamento envolver a representao fsica dos conceitos, ou alteraes no suporte ferramental produzido. Deve-se tambm tomar cuidado para que no sejam introduzidas inconsistncias, principalmente quando a DSL sendo renada possui interaes com outras DSLs e outros artefatos do domnio. Por isso, deve-se retornar atividade ID.2 e refazer seus passos, visando manter o renamento consistente. Sub-atividade ID.3.4. Desenvolvimento das transformaes e geradores de cdigo Com o renamento das DSLs, o implementador constri geradores de cdigo baseados em templates (Seo 3.2.2). Para isso, ele realiza um processo conhecido como migrao de cdigo, onde o cdigo da implementao de referncia anotado com marcaes especiais, como tags e scriptlets, que fazem a associao entre o cdigo e a DSL. Cada trecho de cdigo correspondente a alguma variabilidade, identicado na sub-atividade ID.3.2, recebe algum tipo de anotao. Tags normalmente do suporte a comandos mais simples do tipo condicional ou iterativo.

160

Por exemplo, pode-se embutir o cdigo referente a uma feature opcional dentro de uma tag do tipo condicional, que aceita como parmetro um tipo booleano em uma DSL que indica a presena ou ausncia da feature. Especicando-se este parmetro com o valor VERDADEIRO faz com que o gerador inclua aquele trecho de cdigo, enquanto o valor FALSO faz com que o gerador no o inclua. Exemplos de tags so aquelas includas pelo projeto JET (Java Emitter Templates), descrito na Seo 2.2.2. Variabilidades mais complexas podem precisar de mecanismos mais exveis do que as tags para serem implementadas e parametrizadas. Neste caso, pode-se utilizar scriptlets, trechos de metacdigo que fazem um trabalho mais elaborado de cpia/colagem, produzindo uma sada que une fragmentos de cdigo de forma a implementar a variabilidade exatamente como originalmente idealizada. Geradores baseados em templates representam transformaes modelo-para-texto, em um nico passo. Porm, transformaes modelo-para-modelo devem ser utilizadas para produzir geradores mais bem organizados. Nestes casos, cuidado especial deve ser tomado para que no seja necessrio modicar os modelos intermedirios, visando evitar problemas de inconsistncia. Pode-se evitar este tipo de problema atravs de alguns padres e prticas de sucesso na construo de geradores (VLTER, 2008; VLTER; BETTIN, 2004). O processo de migrao de cdigo deve sempre manter a implementao de referncia consistente com o cdigo gerado, ou seja, deve ser possvel gerar uma nova implementao de referncia sempre que desejado, utilizando os geradores construdos. A princpio, no existe nenhum problema, desde que a migrao de cdigo no modique a implementao de referncia. Mas esta situao pode acontecer, j que durante a migrao de cdigo pode-se identicar oportunidades para melhorar o suporte variabilidade. Por exemplo, a implementao de referncia pode implementar alternativas diferentes para um ponto de variao atravs de trechos de cdigo distintos. Aps a migrao de cdigo para o template, o implementador pode perceber que a criao de funes separadas, uma para cada alternativa, uma soluo melhor. Assim, ele modica o template para implementar esta soluo, fazendo com que a implementao de referncia se torne inconsistente. Mesmo que a migrao de cdigo no modique a implementao de referncia, a prpria evoluo do domnio normalmente causa este tipo de inconsistncia. Sempre que for necessrio corrigir algum erro, seja no gerador ou em outro lugar, deve-se idealmente realizar a manuteno primeiro na implementao de referncia, test-la e valid-la, e somente ento repetir o processo de migrao, de forma que a inconsistncia no exista. Mas na prtica, principalmente correes menores ou de erros do prprio gerador, modica-se diretamente os templates, causando

161

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

Figura 27: Manuteno da consistncia da implementao de referncia Sempre que for necessria uma mudana, faz-se uma anlise para decidir onde realiz-la:

Se a mudana for realizada na implementao de referncia, a migrao de cdigo repetida, propagando as mudanas at os templates. Se a migrao de cdigo no introduzir ainda mais modicaes, nada precisa ser realizado. uma nova implementao e utiliz-la como substituta; e Se a mudana for realizada direta nos templates, a implementao de referncia precisa ser substituda, gerando-a novamente. Caso contrrio, a implementao de referncia precisa ser substituda, e a maneira recomendada gerar

Atividade ID.4. Desenvolvimento do framework do domnio

Papis: implementador do domnio, Especialista do domnio Entradas: PT.14. Implementao de referncia Sadas: PT.15. Framework do domnio Descrio: as atividades anteriores desenvolveram as DSLs, ferramentas e transformaes do domnio. Para isso, utilizou-se uma implementao de referncia como base da

162

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

163

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

Atividade ID.5. Documentao do domnio

Papis: implementador do domnio, Especialista do domnio Entradas: PT.11.Renado. Linguagens especcas de domnio, PT.12.Renado. Suporte ferramental para DSLs, PT.13. Transformaes do domnio, PT.15. Framework do domnio Sadas: PT.16. Documentao do domnio Descrio: documentao de software pode reduzir tempo e esforo no desenvolvimento de novos projetos, facilitar o porte de aplicaes para outras plataformas, alm de ajudar usurios a compreender um software mais facilmente (PHOHA, 1997). No contexto da reutilizao de software, a documentao ainda mais importante (SILVA; WERNER, 1996; KOTULA, 1998;
TAULAVUORI; NIEMELA; KALLIO,

2004), uma vez que um reutilizador precisa identicar,

compreender, adaptar e integrar componentes de software em suas aplicaes. Alm disso, normalmente componentes de software so reutilizados por equipes que no conhecem nem possuem contato com os desenvolvedores (SZYPERSKI; GRUNTZ; MURER, 2002). Porm, no existe um padro universalmente reconhecido para documentao de software, em parte porque estilos e contedo de documentao diferem entre programadores, e alguma vezes diferem para um mesmo programador em circunstncias diferentes. Adicionalmente, a escolha da linguagem de programao e a natureza de um programa podem ditar um estilo particular de documentao que pode no ser facilmente aplicvel a outro ambiente (VOTH, 2004). Existem alguns padres e formatos voltados documentao de software em geral (PHOHA, 1997), como o padro ANSI/ANS 10-3-1995 para documentao de software e o RAS (Reusable

164

Asset Specications ou Especicaes de Artefatos Reutilizveis) (VOTH, 2004). Estes podem ser teis para a documentao de diferentes tipos de software. Com base nestes e em outros trabalhos relacionados documentao de componentes (SILVA; WERNER, 1996; KOTULA, 1998;
TAULAVUORI; NIEMELA; KALLIO,

2004; BASILI; ABD-EL-HAFIZ, 1996), a presente abordagem

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

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

165

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

166

4. Especicao dos parmetros necessrios para a transformao. Para geradores de cdigo, deve-se incluir informaes sobre: 1. Comentrios, no prprio cdigo dos geradores, sobre os mapeamentos com as DSLs de entrada; 2. Metamodelos ou DSLs de origem; 3. Linguagens de destino; 4. Descrio e raciocnio do cdigo gerado; 5. Detalhes sobre o seu desenvolvimento, tais como as linguagens, tecnologias ou frameworks utilizados; 6. Especicao dos parmetros necessrios para a gerao de cdigo.

importante ressaltar que a maioria das informaes necessrias para esta documentao foi sendo produzida ao longo do processo de engenharia de domnio. Por exemplo, os metamodelos das DSLs, o mapeamento entre DSLs e cdigo, cruzamento entre diferentes DSLs, entre outras informaes, foram produzidos durante o processo de anlise, projeto e implementao. Neste caso, trata-se somente de um processo de empacotamento da informao, e possivelmente algum renamento. Em outros casos, como a descrio e raciocnio do cdigo gerado, especicao dos parmetros para as transformaes e geradores de cdigo, as informaes precisam se denidas e detalhadas somente aps sua concluso.

7.3 Consideraes nais

A fase de implementao do domnio quando as informaes coletadas sobre o domnio e modeladas durante a anlise e projeto so concretizadas em forma de artefatos de implementao. Assim, ao nal desta atividade, tem-se um conjunto de artefatos reutilizveis, ou componentes, que implementam parte da arquitetura do domnio, linguagens especcas para os subdomnios, ferramentas que permitem criar modelos para estes subdomnios e transformaes modelo-modelo e modelo-texto capazes de gerar cdigo especco para a arquitetura do domnio. O Quadro 12 resume as atividades de implementao do domnio. O Quadro 13 descreve os produtos de trabalho da fase de implementao do domnio.

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

ID.2. Denio das DSLs e do suporte ferramental (top-down) ID.2.1. Identicao das features iniciais da DSL ID.2.2. Denio da sintaxe abstrata ID.2.3. Denio da sintaxe concreta ID.2.4. Denio da integrao inter-DSL ID.2.5. Construo da ferramenta de modelagem especca de domnio ID.3. Desenvolvimento das transformaes e renamento das DSLs (bottom-up) ID.3.1. Desenvolvimento da implementao de referncia ID.3.2. Inspeo de cdigo e mapeamento para elementos das DSLs ID.3.3. Renamento das DSLs ID.3.4. Desenvolvimento das transformaes e geradores de cdigo ID.4. Desenvolvimento do framework do domnio ID.5. Documentao do domnio

sobre

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

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

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

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

Quadro 12: Resumo das atividades para implementao do domnio orientada a modelos No prximo captulo apresentado um possvel modelo de ciclo de vida para a utilizao da abordagem, considerando-se um processo evolutivo e interativo, com caractersticas mais prximas realidade das organizaes.

168

Produto de trabalho PT.10. Subdomnios caracterizados

PT.11. Linguagens especcas de domnio

PT.12. DSLs

Suporte ferramental para

Descrio Denio do tipo de variabilidade caracterstico de cada subdomnio: baseada em features ou baseada em DSLs Denio das sintaxes abstrata e concreta das linguagens especcas de domnio para os subdomnios identicados durante o processo. A sintaxe abstrata das DSL visuais normalmente um metamodelo, enquanto a sintaxe abstrata das DSLs textuais uma gramtica Ferramentas de modelagem para as DSLs. Podem ser ferramentas visuais, para a criao de diagramas segundo uma DSL visual, ou ferramentas textuais, para a criao de programas segundo uma DSL textual

Estado Nenhum

PT.13. Transformaes do domnio

PT.14. referncia

Implementao

de

PT.15. Framework do domnio

PT.16. Documentao do domnio

Transformaes modelo-para-modelo e modelo-para-cdigo para serem utilizadas em conjunto com as DSLs do domnio Uma implementao do domnio contendo exemplos das diferentes variabilidades identicadas durante o processo Conjunto de classes reutilizveis de um domnio, estruturadas de modo a formar um esqueleto de uma aplicao do domnio, com os pontos variveis bem denidos e mecanismos que possibilitam a sua instanciao Documentao dos diferentes artefatos de implementao do domnio, incluindo componentes, DSLs, ferramentas, transformaes e geradores de cdigo

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

Nenhum

Nenhum

Nenhum

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

169

Avaliao

A combinao entre desenvolvimento orientado a modelos e reutilizao de software tem como promessa a reutilizao em alto nvel, como defendido pelos pesquisadores (NEIGHBORS, 1980; KRUEGER, 1992; GRISS, 1995; FRAKES; ISODA, 1994; JACOBSON; GRISS; JONSSON, 1997) desde as primeiras discusses sobre reutilizao de software. Diversos pesquisadores, entre eles Czarnecki et al. (2005), concordam que MDD e reutilizao so esforos complementares. As prprias origens destas duas linhas de pesquisa esto interligadas, conforme discutido no Captulo 9. A presente tese buscou investigar de forma mais aprofundada esta idia: defende-se que a combinao entre o desenvolvimento orientado a modelos e reutilizao de software em um processo sistemtico exige o gerenciamento dos mltiplos subdomnios que podem existir em um domnio, de modo a oferecer um grau de automao adequado. Para isso, a preocupao com o MDD deve estar presente em todas as etapas do processo, incluindo a anlise, o projeto e a implementao do domnio. A avaliao desta tese consistiu na realizao de estudos empricos envolvendo a aplicao da abordagem em projetos de engenharia de domnio, com o objetivo de fornecer evidncias ou indcios sobre sua validade. importante ressaltar que a avaliao realizada tem carter mais exploratrio, com alguns pontos que ainda precisam ser melhorados para que os resultados possam ser mais conveis, conforme discutido na Seo 8.6. Mas de qualquer forma, puderam ser extradas algumas concluses, como apresentado no nal deste captulo. A seguir so apresentados os detalhes sobre a avaliao realizada.

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

170

denidos os objetivos da avaliao, que devem ser rastreados a um conjunto de dados que denem estes objetivos de forma operacional, e a interpretao destes dados com respeito aos objetivos denidos. O rastreamento entre os objetivos e os dados feito atravs de questes que caracterizam os objetivos de forma mais especca. Assim, seguindo o formato sugerido no GQM, so denidos dois objetivos para esta avaliao, assim descritos e detalhados por meio das respectivas questes especcas: G1 . Analisar a abordagem orientada a modelos para reutilizao de software com o objetivo de determinar se ela promove aumento e/ou melhoria na reutilizao de software, quando comparada com o desenvolvimento no orientado a modelos, com respeito aos artefatos do domnio produzidos do ponto de vista do pesquisador no contexto de projetos de engenharia de domnio. Q1 . Analisando-se um mesmo projeto desenvolvido com e sem a abordagem, possvel observar um aumento e/ou melhoria na reutilizao de software no projeto que utilizou a abordagem? Q2 . Os artefatos de software produzidos com a abordagem so mais reutilizveis do que aqueles produzidos em uma abordagem no orientada a modelos? G2 . Analisar a abordagem orientada a modelos para reutilizao de software com o objetivo de determinar a sua importncia em todo o ciclo de vida com respeito aos benefcios obtidos e diculdades de utilizao do ponto de vista do pesquisador no contexto de projetos de engenharia de domnio. Q3 . Os participantes que utilizaram a abordagem perceberam, durante as atividades da abordagem referentes preocupao com MDD desde o incio do desenvolvimento (fase de anlise), algum benefcio para a implementao dos artefatos do MDD (DSLs, transformaes e geradores de cdigo)? Q4 . Os participantes que utilizaram a abordagem tiveram diculdades que causaram prejuzo ao desenvolvimento, em termos de atrasos e curva de aprendizado? O objetivo G1 diz respeito tese de que o MDD oferece meios concretos para que a reutilizao de conhecimento possa ocorrer em maior grau e de forma mais adequada, quando comparada com um processo no orientado a modelos. Assim, a questo Q1 busca observar este aumento e/ou melhora na reutilizao comparando-se dois projetos: um desenvolvido sem a abordagem e outro desenvolvido com a abordagem. Contudo, mesmo que no seja observado efetivamente um aumento conforme as mtricas especicadas, isto no signica

171

que a abordagem no favorea mais reutilizao. Existe a possibilidade de os artefatos serem mais reutilizveis quando desenvolvidos com a abordagem, mesmo que no tenham sido efetivamente reutilizados no seu maior potencial nestes estudos. Assim, a questo Q2 busca avaliar este aspecto. O objetivo G2 diz respeito tese de que a utilizao do MDD exige uma preocupao que deve estar presente em todo o ciclo de vida, devendo ser tratada de forma consistente desde a anlise at a implementao. Assim, a questo Q3 se refere obteno de algum benefcio observvel com a aplicao da abordagem desde o incio. A questo Q4 busca identicar se a utilizao do MDD desde o incio traz mais problemas do que benefcios. Nesta avaliao, o projeto desenvolvido sem a abordagem consistiu na aplicao dos conceitos de reutilizao de software de forma ad hoc. Foram produzidos componentes de software reutilizveis e uma arquitetura de referncia para o domnio, porm sem a execuo de atividades especcas de um mtodo voltado reutilizao. Nos trs casos, a implementao obtida pelo desenvolvimento sem a abordagem foi aproveitada durante a atividade de desenvolvimento da implementao de referncia. Desta forma, o cdigo nal obtido com e sem a abordagem foi praticamente o mesmo.

8.1.1

Coleta de dados

Para a obteno de dados que possam conter indcios ou evidncias sobre estas questes, foram denidas formas qualitativas e quantitativas de coleta de dados, combinando a percepo subjetiva dos envolvidos nos estudos empricos com medidas referentes estrutura do software produzido e outros atributos de qualidade. a seguir. Questo Q1 . Analisando-se um mesmo projeto desenvolvido com e sem a abordagem, possvel observar um aumento e/ou melhoria na reutilizao de software no projeto que utilizou a abordagem? difcil denir o que signica aumento e/ou melhoria na reutilizao. A reutilizao ocorre de diversas maneiras, e dependendo do contexto, pode signicar diferentes benefcios. Por exemplo, a reutilizao obtida por meio de herana completamente diferente da reutilizao obtida com um gerador de cdigo, sendo difcil determinar qual das duas oferece maiores benefcios, pois no h mtricas consistentes capazes de medir ambos os aspectos de forma normalizada. Foram denidas formas de coleta de dados especcas para cada questo relacionada aos objetivos da avaliao, conforme apresentado

172

Existem diferentes mtricas voltadas reutilizao1 , que focam em aspectos econmicos e estruturais de artefatos de software. No contexto desta questo destacam-se apenas os aspectos estruturais, pois esta tese trata de uma abordagem voltada para a engenharia para reutilizao. A literatura apresenta algumas mtricas simples para medir a reutilizao no nvel estrutural dos artefatos, mas nenhuma delas capaz de oferecer uma imagem completa do nvel de reutilizao em um sistema (MASCENA; ALMEIDA; MEIRA, 2005). Assim, faz-se necessria uma anlise mais cuidadosa, combinando-se diferentes mtricas que avaliem os aspectos importantes para este estudo especco. Assim, as seguintes mtricas foram denidas para a questo Q1 : M1 . Porcentagem de reutilizao (RP - Reuse Percent). Esta a mtrica mais bsica de reutilizao, sendo denida como a razo entre o nmero de linhas de cdigo reutilizadas e o nmero total de linhas de cdigo (POULIN; CARUSO, 1993). Um cuidado especial deve ser tomado com esta mtrica, pois pode levar a concluses incorretas. Por exemplo, caso seja reutilizado um nico mtodo, pequeno, de uma classe com milhares de linhas de cdigo, esta porcentagem seria alta mas no reetiria a realidade de que apenas uma poro da classe foi reutilizada. A coleta desta mtrica envolve a identicao dos mdulos reutilizados e a contagem das linhas de cdigo dos mdulos reutilizados e no-reutilizados. M2 . Razo de reutilizao (RR - Reuse Ratio). Esta mtrica calculada da mesma forma que a M1 , porm tambm considerando-se a reutilizao do tipo caixa-branca (DEVANBU et al., 1996): artefatos modicados at um certo nvel so considerados como reutilizados. Devanbu et al. (1996) sugerem o valor de 25% como margem de tolerncia: artefatos que tiveram mais de 25% de seu cdigo modicado no so considerados como reutilizados. M3 . Porcentagem de reutilizao no desejada. Conforme destacado na mtrica M1 , a reutilizao de grandes trechos de cdigo que no so efetivamente utilizados pode distorcer a mtrica de porcentagem de reutilizao. O uso desta mtrica permite determinar se este efeito est ocorrendo. Alm disso, reutilizar cdigo que no efetivamente aproveitado pode ser prejudicial, agregando informaes descartveis que podem confundir a equipe durante a manuteno do software. Portanto, esta mtrica tambm ajuda a caracterizar a reutilizao. Esta mtrica consiste no clculo da porcentagem, para cada artefato reutilizado, das linhas de cdigo que no so efetivamente utilizadas em relao ao nmero total de linhas de cdigo reutilizadas. Para a coleta desta mtrica pode-se utilizar funcionalidades das IDEs que permitem determinar quais mtodos no so chamados, por exemplo. M4 . Porcentagem de reutilizao gerada. Esta mtrica calcula a porcentagem de artefatos
1 Uma

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

173

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

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

174

de modelagem. Como o objetivo comparar a quantidade de conhecimento que foi reutilizado na construo do software nal, a comparao dos cdigos razovel, uma vez que o tamanho de um mdulo reete de forma indireta a quantidade de conhecimento ali encapsulado. Esse segundo ponto s vlido para a questo Q1 . Na questo Q2 , discutida a seguir, os artefatos do MDD, como modelos, transformaes e geradores de cdigo precisam ser avaliados quanto aos seus atributos de qualidade relacionados reutilizao, e portanto devem ser includos nas medies. Questo Q2 . Os artefatos de software produzidos com a abordagem so mais reutilizveis do que aqueles produzidos em uma abordagem no orientada a modelos? Conforme discutido anteriormente, as mtricas para reutilizao M1 , M2 e M3 referentes questo Q1 apresentam problemas por no considerar a natureza dos artefatos reutilizveis e nem a maneira com que estes so reutilizados, penalizando, por exemplo, grandes sistemas e sistemas pouco modularizados (monolticos) (MASCENA; ALMEIDA; MEIRA, 2005; MASCENA, 2007; ALMEIDA et al., 2007a). Por este motivo, existe outra vertente que defende a idia de que melhor tentar medir a reutilizao atravs da avaliao de atributos de qualidade que inuenciam a reusabilidade de um determinado artefato de software. Neste sentido, so sugeridas mtricas indiretas, como manutenibilidade e complexidade (POULIN, 1994). Estas medidas talvez ofeream uma viso melhor sobre os reais benefcios da abordagem, j tendo sido utilizadas com sucesso em outros estudos relacionados reutilizao de software, como por exemplo o trabalho de Almeida et al. (2007a). Assim, as seguintes mtricas foram denidas para esta questo: M6 . Instabilidade de mdulo. De acordo com Martin (1994), o que torna um software rgido, frgil e difcil de ser reutilizado a interdependncia entre seus mdulos. Um software rgido se ele no puder ser facilmente modicado, isto , uma nica mudana inicia uma cascata de mudanas em diferentes mdulos. Alm disso, quando a extenso da mudana no pode ser prevista pelo projetista, seu impacto no pode ser estimado, o que diculta a estimativa de custos, tornando o software rgido. A mtrica de instabilidade de um mdulo (I) busca avaliar esta caracterstica do software, sendo denida da seguinte maneira: I= AE AA + AE

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

175

de classes dentro deste mdulo que dependem de classes fora deste mdulo. A mtrica de instabilidade varia entre 0 e 1, onde I prximo a 0 indica um mdulo estvel e I prximo a 1 indica um mdulo instvel. Como no existem muitos dados prvios para serem utilizados como base para esta medida, neste estudo, considerou-se que mdulos com instabilidade < 0,5 so considerados mais estveis do que a mdia, a exemplo do estudo de Almeida et al. (2007a). Esta mtrica pode ser utilizada tanto em artefatos de cdigo-fonte como em artefatos do MDD, como DSLs, modelos especcos de domnio, transformaes e geradores, j que se baseia no conceito de dependncias. Porm, enquanto existem ferramentas automatizadas para extrair tais valores diretamente do cdigo-fonte, a coleta com relao aos demais artefatos deve ser manual. M7 Complexidade ciclomtica. Um aspecto crtico na Engenharia de Software se relaciona separao de interesses e modularizao de um sistema de software com o objetivo de se obter mdulos bem denidos, testveis e de fcil manuteno. Durante a dcada de 70, McCabe (1976) desenvolveu uma tcnica matemtica que prov uma base quantitativa para modularizao e identicao de mdulos de software difceis de testar ou manter. Nesta tcnica, uma medida de complexidade apresentada, tendo como objetivo medir e controlar o nmero de caminhos em um programa. No contexto da reutilizao, a complexidade tem papel fundamental, pois artefatos mais complexos possuem menor facilidade de serem reutilizados (MASCENA, 2007; POULIN, 1994). A complexidade ciclomtica calculada a partir de um grafo conectado que representa o uxo de execuo de um mdulo, da seguinte maneira: CC(G) = E N + p onde E = nmero de arcos de um grafo, N = nmero de ns de um grafo e p = nmero de componentes conectados. Para esta mtrica, valores entre 1 e 10 indicam que se trata de um mdulo simples, sem muito risco. Valores entre 11 e 20 representam mdulos moderadamente complexos. Valores entre 21 e 50 representam alta complexidade, e valores maiores que 50 representam mdulos completamente no-testveis e com alto risco. Por ser aplicvel a grafos, esta mtrica pode ser utilizada diretamente em modelos visuais do tipo grafo. Modelos textuais tambm podem ser transformados em grafos, analisando-se o metamodelo correspondente. M8 . ndice de Manutenibilidade. A manutenibilidade um atributo desejvel tanto como

176

uma medida instantnea como uma previso da manutenibilidade com o tempo. Esforos para medir e rastrear a manutenibilidade tm por objetivo reduzir ou reverter a tendncia de degradao de integridade de um sistema, e indicar quando pode ser mais barato ou menos arriscado reconstruir do que modicar (VANDOREN, 1997). No contexto da engenharia de domnio, ela um indicador importante da reusabilidade de um artefato (MASCENA; ALMEIDA;
MEIRA,

2005), uma vez que um domnio est constantemente em evoluo, com novas features

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

177

Marcaes condicionais e de laos so considerados operadores; e Trechos de cdigo embutido so analisados da mesma forma que cdigo-fonte tradicional. Esta mtrica no pode ser aplicada a modelos, uma vez que estes no necessariamente contm elementos que podem ser associados com operandos e operadores. Nestes casos, devem ser utilizadas mtricas especcas para modelos. Conforme demonstrado por Genero et al. (2007) e por Genero, Poels e Piattini (2008), a manutenibilidade de um modelo determinada principalmente por sua compreensibilidade. Neste sentido, os autores identicaram, no contexto da modelagem Entidade-Relacionamento e diagramas de classes, que as propriedades estruturais de um modelo que so relevantes para que um ser humano possa compreend-lo facilmente so os atributos e relacionamentos 1:N. O tamanho de um modelo em termos do nmero de entidades no parece ser relevante para compreensibilidade. Assim, duas mtricas foram denidas para avaliar a manutenibilidade dos modelos nesta abordagem. Apesar de originalmente terem sido desenvolvidas para modelos E-R e diagramas de classes, o conceito de atributos e relacionamentos est presente em vrias linguagens do tipo grafo, e portanto podem ser aplicadas em outros tipos de modelos similares. M9 . Nmero de Atributos. Nesta mtrica, so contados os atributos em um modelo. Em modelos visuais (diagramas), um atributo uma propriedade textual de um elemento visual (um cone, uma caixa ou um n de um grafo). Em modelos textuais, um atributo uma propriedade textual de um conceito de primeira classe, conforme denido na gramtica da linguagem. M10 . Nmero de Relacionamentos. Nesta mtrica, so contados os relacionamentos em um modelo. Em modelos visuais (diagramas), um relacionamento representado por uma linha entre dois elementos, ou outra representao relacional entre dois ou mais elementos, como por exemplo a representao de conjuntos no GME (Generic Modeling Environment - Seo 2.2.2). Em modelos textuais, um relacionamento consiste em uma referncia entre dois conceitos de primeira classe, conforme denido na gramtica da linguagem. Essas duas mtricas so absolutas, ou seja, sabe-se que quanto mais atributos e relacionamentos, menos compreensvel ser um modelo, mas no se tem uma medida para ser utilizada como parmetro para determinar se um modelo ou no compreensvel, e por consequncia possui alta manutenibilidade. Como valor de referncia, foi utilizada nesta tese a mdia obtida em experimentos envolvendo diagramas E-R e UML, conforme descrito por Genero et al. (2007) e por Genero, Poels e Piattini (2008): NA = 42, 63 + 40, 22 = 41, 425 2

178

NR =

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

Portanto, truncando-se estes valores, considerou-se neste estudo que modelos com menos de 41 atributos e menos do que 9 relacionamentos possuem maior manutenibilidade do que a mdia. As mtricas M9 e M10 permitem a avaliao tanto de modelos visuais e textuais, como tambm seus metamodelos, permitindo tambm avaliar a manutenibilidade das DSLs. Questo Q3 . Os participantes que utilizaram a abordagem perceberam, durante

as atividades da abordagem referentes preocupao com MDD desde o incio do desenvolvimento, algum benefcio para a implementao dos artefatos do MDD (DSLs, transformaes e geradores de cdigo)? Para avaliar se o uso da abordagem desde o incio do desenvolvimento produz algum benefcio, foi realizada uma entrevista com os participantes que utilizaram a abordagem, com perguntas que avaliaram se os benefcios almejados foram efetivamente percebidos e observados. Decidiu-se por uma entrevista ao invs de um questionrio, pois os estudos no envolveram um nmero muito grande de participantes, e desta forma houve mais exibilidade na observao dos resultados da aplicao da abordagem. A entrevista consistiu das perguntas a seguir, com respostas em aberto: O modelo de features ajudou na denio das linguagens especcas de domnio, transformaes e geradores de cdigo? A descrio da variabilidade em cenrios (casos de mudana) facilitou a denio das linguagens especcas de domnio, transformaes e geradores de cdigo? A identicao de candidatos a subdomnio facilitou a identicao das reas do domnio a serem automatizadas? A identicao de candidatos a subdomnio facilitou a denio das linguagens especcas de domnio, transformaes e geradores de cdigo? O processo investigativo baseado em decises para incluso/excluso de subdomnios foi utilizado? Se sim, ele facilitou o processo de desenvolvimento dos artefatos do MDD? O uso das diretrizes e padres arquiteturais especcos para reutilizao e MDD facilitou o desenvolvimento dos artefatos do MDD e da arquitetura do domnio?

179

A etapa de avaliao arquitetural ajudou a identicar falhas antes de a implementao ser iniciada? As diretrizes de implementao de DSLs, transformaes e geradores de cdigo facilitaram a implementao dos artefatos do MDD? O formato de documentao proposto foi adequado, auxiliando na descrio dos artefatos reutilizveis desenvolvidos? Quais foram as vantagens de se utilizar a abordagem de MDD no desenvolvimento? Quais foram as desvantagens de se utilizar a abordagem de MDD no desenvolvimento? Questo Q4 . Os participantes que utilizaram a abordagem tiveram diculdades que causaram prejuzo ao desenvolvimento, em termos de atrasos e curva de aprendizado? Para avaliar as diculdades de utilizao da abordagem, foram includas as seguintes perguntas, na entrevista realizada na questo Q3 , referente s diculdades percebidas pelos participantes: Quais foram as diculdades para o aprendizado da abordagem? Quais foram as diculdades para denio do modelo de features? Quais foram as diculdades para descrio da variabilidade em cenrios (casos de mudana)? Quais foram as diculdades para a identicao de candidatos a subdomnio? Quais foram as diculdades para realizar o processo investigativo baseado em decises para incluso/excluso de subdomnios? Cite outras diculdades percebidas durante a utilizao da abordagem de MDD desde o incio do desenvolvimento.

8.1.2

Hipteses

Como ensina Albert Einstein, fsico alemo que viveu entre 1879 e 1955: Nenhuma quantidade de experimentao pode provar que estou certo; um nico experimento pode provar que estou errado. Com base nesta premissa cientca, comum trabalhar-se com a idia de uma hiptese nula, ou seja, dene-se como hiptese algo que o experimentador deseja rejeitar,

180

e projeta-se um ou mais experimentos que tm como objetivo testar esta hiptese (WOHLIN et
al.,

2000). Assim, a hiptese nula para esta avaliao pode ser descrita com base nas questes e

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

181

A rejeio da hiptese nula deve ser feita em favor de uma hiptese alternativa, que normalmente representa a negao da hiptese nula. Neste cenrio, as seguintes alternativas so denidas:

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

8.2 Descrio dos projetos utilizados nos estudos empricos e sua execuo
Foram realizados trs estudos envolvendo a aplicao da abordagem em projetos de engenharia de domnio. Para o primeiro estudo, foi escolhido o domnio de aplicaes de autoria de contedo para a Web, por se tratar de um domnio relativamente simples de ser implementado manualmente e pela disponibilidade de especialistas para eventuais consultas. Este primeiro estudo foi completamente desenvolvido a partir do zero para a avaliao, mas foi

182

o resultado da evoluo dos estudos utilizados como base para testar e renar as atividades da abordagem, conforme descrito na Seo 4.3. O segundo estudo foi realizado na indstria, durante um estgio de doutorado, e a escolha do domnio envolvido, de aplicaes distribudas baseadas em computao em nuvem, no foi feita pelo autor desta tese, mas sim pelos lderes do grupo no qual o estgio foi realizado. O terceiro estudo, tambm realizado na indstria, envolveu o domnio de eventos cientcos, e a escolha se deu por convenincia e proximidade da empresa ao grupo de pesquisa. Os estudos so comparativos, ou seja, visam comparar os resultados do desenvolvimento realizado sem a abordagem com o desenvolvimento realizado com a abordagem. Para essa comparao, foram utilizadas implementaes de exemplo desenvolvidas antes do uso da abordagem, que no contemplavam modelos ou qualquer tipo de artefato relacionado ao MDD, e as implementaes desenvolvidas com a abordagem, que incluem uma arquitetura preparada para o MDD, alm dos artefatos especcos para este contexto, como DSLs, transformaes e geradores de cdigo. A seguir so apresentados mais detalhes sobre cada estudo.

8.2.1 Autoria de contedo para a Web

O primeiro estudo foi realizado em ambiente acadmico, e envolveu o domnio de aplicaes de autoria de contedo para a Web. So aplicaes onde um administrador publica contedo a ser visualizado por muitos usurios, como por exemplo portais de notcias, pginas pessoais, fruns e blogs. Trata-se de um domnio tcnico, envolvendo os requisitos de persistncia e navegao na Web. Neste estudo, as linguagens especcas de domnio, geradores, a arquitetura e a implementao de referncia foram desenvolvidos a partir do zero, utilizando a abordagem denida nesta tese. Foi executado pelo autor desta tese, com a ajuda de especialistas de domnio. Inicialmente, foram realizados estudos sobre as tecnologias de implementao necessrias, e em seguida a abordagem foi aplicada no desenvolvimento dos artefatos do domnio. Foi desenvolvida uma infraestrutura composta de artefatos de software gerados e no-gerados, em uma arquitetura em trs camadas. Foram desenvolvidas quatro linguagens especcas de domnio: uma linguagem visual para persistncia, uma linguagem textual para navegao, uma linguagem textual para a produo de relatrios e uma linguagem visual para congurao das features presentes no produto. Tambm foram desenvolvidas transformaes e geradores de cdigo que produzem aplicaes completas, segundo as especicaes dos

183

modelos. O Quadro 14 mostra um resumo dos dados relevantes sobre este estudo.
Domnio Local Participantes Tempo total Nmero de DSLs Nmero de artefatos de gerao (transformaes e geradores) Tamanho total (LOC) artefatos de gerao Tamanho total (LOC) implementao de referncia Nmero de features do domnio Tecnologias de implementao Autoria de contedo para Web ICMC/USP - So Carlos/SP 1 (autor) 3 meses (dedicao integral) 4 (persistncia, navegao, relatrios e features) 38 1610 5941 15 Apache Tomcat, MySQL, Java, JSP, JSTL, Servlets, XML, SQL, Eclipse (verso Ganymede) + WebTools plug-in Eclipse (verso Ganymede) EMF (Eclipse Modeling Framework) GMF (Graphical Modeling Framework) JET (Java Emitter Templates) openArchitectureWare

Tecnologias MDD

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

8.2.2

Aplicaes distribudas baseadas em computao em nuvem

O segundo estudo foi realizado em ambiente industrial, envolvendo o domnio de aplicaes distribudas baseadas em computao em nuvem (LUCRDIO; JACKSON; SCHULTE, 2008). As principais caractersticas deste domnio so o alto grau de incerteza sobre a topologia da aplicao, a heterogeneidade dos ambientes e infraestrutura e o alto grau de cooperao entre os componentes distribudos. Este estudo foi realizado durante um estgio de doutorado realizado pelo autor da tese nos laboratrios da Microsoft Research, em Redmond, Estados Unidos (LUCRDIO; JACKSON; SCHULTE, 2008). Este domnio j vinha sendo explorado pelos pesquisadores da Microsoft Research, que desenvolveram uma teoria baseada em modelagem de negcios e um conjunto de trs linguagens especcas para este objetivo (JACKSON; SCHULTE, 2008): uma linguagem visual para descrever os dados do sistema, uma linguagem visual para descrever as caractersticas dos tipos de elementos distribudos, sua conectividade e quais dados possuem, e uma linguagem visual para descrever a semntica das operaes de manipulao dos dados. O aspecto mais interessante desta especicao que os modelos de dados e operaes no precisam se preocupar com a localizao dos dados e nem que tipo de elemento distribudo responsvel por sua manuteno.

184

A teoria diz que possvel gerar cdigo responsvel pela execuo distribuda das operaes e vericao de integridade global do sistema, de acordo com regras especcas denidas nos modelos. Trata-se de um domnio predominantemente tcnico, envolvendo os aspectos de execuo distribuda e computao em nuvem, mas com um componente de negcios, uma vez que as regras de negcio podem ser denidas utilizando a linguagem de modelagem de operaes. Neste estudo, realizado pelo autor da tese junto com um pesquisador da Microsoft Research, foi utilizada a abordagem denida nesta tese, porm com menor foco na anlise, uma vez que j existiam verses iniciais das linguagens especcas de domnio. Aps o estudo das tecnologias de implementao envolvidas, estas verses iniciais das linguagens foram renadas, e passou-se para as fases de projeto e implementao do domnio, onde foram desenvolvidos, a partir do zero: A arquitetura para o domnio; Uma implementao de referncia baseada em uma infraestrutura responsvel por algumas das funes bsicas de comunicao e distribuio; e Um conjunto de transformaes e geradores que produzem uma aplicao completa no topo da infraestrutura. O Quadro 15 resume alguns dados relevantes sobre este estudo.

8.2.3

Eventos cientcos

O terceiro estudo foi realizado tambm em ambiente industrial, e envolveu o domnio de eventos cientcos. Este domnio engloba sistemas de submisso e inscrio em eventos, mala direta, gerenciamento de secretaria e gerenciamento de feiras. Trata-se de um domnio de negcios, e a reutilizao envolve principalmente regras de negcio relacionadas ao gerenciamento de eventos cientcos. Este estudo foi feito em uma empresa situada em So Carlos que trabalha com uma linha de produtos deste domnio, realizando desenvolvimento e customizao dos produtos do domnio, muitas vezes vendendo os mesmos de forma integrada. O gerenciamento da variabilidade nesta linha realizado com a ajuda de alguns componentes reutilizveis, mas principalmente utilizando tcnicas de gerenciamento de congurao. Assim, cada sistema vendido produz diferentes verses que implementam as diferentes variabilidades do domnio. A reutilizao

185
Domnio Local Participantes Tempo total Nmero de DSLs Nmero de artefatos de gerao (transformaes e geradores) Tamanho total (LOC) artefatos de gerao Tamanho total (LOC) implementao de referncia Nmero de features do domnio Tecnologias de implementao Aplicaes distribudas baseadas em computao em nuvem Microsoft Research - Redmond/WA - USA 2 (incluindo o autor) 3 meses (dedicao integral) 3 (dados, conectividade e operaes) 29 2847 12127 Microsoft Visual Studio 2008, Microsoft SQL Server, C#, .NET, .NET Remoting, Microsoft Volta, PNRP (Peer Name Resolution Protocol) DBML (DataBase Modeling Language), Microsoft LINQ to SQL Microsoft Visual Studio 2008 Microsoft Text Templates GME (Generic Modeling Environment)

Tecnologias MDD

Quadro 15: Dados sobre o estudo envolvendo o domnio de aplicaes distribudas baseadas em computao em nuvem ocorre recuperando-se uma determinada verso que seja prxima dos requisitos do cliente, e modicando-a para satisfazer aos requisitos. Aps o contato inicial, foi estabelecido que o estudo seria realizado como um projeto paralelo na empresa, por uma equipe composta de dois funcionrios com dedicao parcial, com o auxlio e orientao do autor desta tese. Como neste estudo o autor no participaria do desenvolvimento, foi necessrio um perodo de treinamento, realizado da seguinte forma: Em um primeiro momento, um dos participantes do projeto realizou um curso de 20 horas sobre desenvolvimento orientado a modelos, oferecido no ICMC/USP So Carlos e ministrado pelo autor desta tese2 ; Em seguida, o autor da tese realizou um treinamento interno de 4 horas com os participantes, apresentando as atividades e detalhes da abordagem; e O autor da tese disponibilizou como exemplo os documentos e artefatos produzidos durante o estudo do domnio Web, que cou disposio da equipe para consulta. Aps este perodo, o autor desta tese permaneceu disponvel para sanar dvidas e responder questionamentos durante todo o projeto, uma vez que se tratam de conceitos novos para a empresa e os participantes.
material deste curso encontra-se disponvel no endereo ttsrr ssrs .
2O

186

Aps o treinamento, a equipe utilizou a abordagem para realizar a anlise, projeto e implementao do domnio. Uma vez que j existia a linha de produtos implantada na empresa, o projeto arquitetural se resumiu principalmente organizao da infraestrutura de gerao de cdigo de forma integrada aos artefatos existentes na linha de produtos. E na implementao do domnio, foi utilizado um produto concreto como implementao de referncia. Como resultado, foram denidas duas linguagens especcas de domnio: uma linguagem textual para a denio das features, e a sua congurao atravs de atributos especcos para a linha de produtos, e uma linguagem textual para a denio de formatos de certicados, um subdomnio identicado pela equipe durante a anlise. Foram tambm construdos os geradores responsveis por congurar novos produtos e produzir cdigo customizado. O Quadro 16 resume alguns dados relevantes sobre este estudo.
Domnio Local Participantes Tempo total Nmero de DSLs Nmero de artefatos de gerao (transformaes e geradores) Tamanho total (LOC) artefatos de gerao Tamanho total (LOC) implementao de referncia Nmero de features do domnio Tecnologias de implementao Tecnologias MDD Eventos cientcos Aptor Consultoria e Desenvolvimento de Software Ltda. 2 2 meses (dedicao parcial) 2 (congurao e certicados) 8 1375 71873 29 Adobe DreamWeaver, PHP, MySQL Eclipse (verso Ganymede) EMF (Eclipse Modeling Framework) JET (Java Emitter Templates)

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

8.3 Coleta dos dados

A coleta das mtricas foi realizada com o auxlio de diferentes ferramentas. Para os projetos baseados em cdigo Java, foram utilizadas as ferramentas Eclipse Metrics3 (Instabilidade e Complexidade Ciclomtica) e JHawk4 (ndice de Manutenibilidade). Estas ferramentas trabalham com cdigo-fonte em Java. Para arquivos JSP, foi utilizado o cdigo Java de seus Servlets correspondentes. Os templates do JET so convertidos em Java, e portanto estas ferramentas tambm puderam ser utilizadas.
3 tttrssrrt 4 ttrtrrt

187

Para cdigo C#, no foi encontrada nenhuma ferramenta disponvel capaz de calcular estas mtricas. Porm, foi utilizada a ferramenta Net2Java5 , um plug-in do NetBeans capaz de converter cdigo escrito em C# para Java. Como so linguagens bastante similares, a converso realizada de forma quase direta. Alm disso, no foi necessrio executar o cdigo convertido. As mtricas so estruturais, e se baseiam em dependncia entre classes, operadores, operandos, estruturas de laos e condies, e outros elementos do cdigo que so comuns a ambas linguagens. Assim, o nico trabalho foi corrigir alguns erros da converso, visando deixar o cdigo Java compilvel, requisito das ferramentas Eclipse Metrics e JHawk, e estas foram utilizadas para extrair as mtricas. O cdigo PHP utilizado no terceiro estudo no orientado a objetos, e no foi encontrada nenhuma ferramenta capaz de extrair estas mtricas para este tipo de cdigo, e nem ferramentas automatizadas de converso. Uma vez que a quantidade de cdigo deste projeto muito grande, a coleta manual das mtricas de Instabilidade, Complexidade Ciclomtica e ndice de Manutenibilidade, que exigem uma inspeo detalhada do cdigo, no foi realizada no terceiro estudo. Para os demais artefatos, como metamodelos, modelos e geradores baseados em templates interpretados, como os templates do openArchitectureWare, foi necessrio realizar o clculo manual, como por exemplo a contagem de acoplamento aferente e eferente, anlise de grafos dos programas e a contagem do nmero de atributos e relacionamentos em modelos. Como o nmero e tamanho destes artefatos consideravelmente reduzido, este trabalho foi realizado sem diculdades. As anlises qualitativas, atravs de entrevista, somente foram realizadas no terceiro estudo, uma vez que nos dois primeiros estudos o autor da tese participou do desenvolvimento. Aps a coleta dos dados, os mesmos foram analisados utilizando estatstica descritiva atravs de grcos do tipo box plot (FENTON; PFLEEGER, 1998), que permitem visualizar a disperso e balanceamento das amostras. Box plots podem ser utilizados de diferentes formas (WOHLIN et al., 2000). Nesta tese, foi utilizada a abordagem denida por Fenton e Peeger (1998), que propem a utilizao do seguinte clculo para anlise das extremidades: Lin f erior = q1 (q3 q1 ) 1.5 Lsuperior = q3 + (q3 q1 ) 1.5 onde q1 e q3 so o primeiro (25%) e terceiro (75%) quartis, respectivamente.
5 ttstt

188

Dado um conjunto de dados seguindo uma distribuio normal, teoricamente no deveriam ser encontrados elementos abaixo do limite inferior e acima do limite superior. Caso existam, estes devem ser analisados e deve-se decidir se sero includos ou excludos da anlise. Por exemplo, quando o elemento fora dos limites se tratar de cdigo-fonte, deve-se analisar se ele segue os mesmos padres e formatos utilizados na maioria do cdigo. Se este elemento possuir muitas linhas de comentrio ou se for um cdigo reutilizado de outro projeto sem uma reformatao, ele pode no representar a realidade do cdigo produzido, e deve ser excludo da anlise. Por outro lado, podem existir elementos de cdigo extremamente complexos ou extremamente simples, devido natureza do prprio domnio. Nestes casos, o elemento deve ser mantido. Para cada estudo, foram analisados somente os artefatos efetivamente utilizados pelo desenvolvedor. Ou seja, artefatos de cdigo completamente gerados e que no precisam ser modicados ou manipulados pelo desenvolvedor no foram includos nas mtricas. Porm, em alguns grcos, o cdigo gerado foi tambm analisado para propiciar melhor caracterizao da reutilizao que est ocorrendo. A seguir so apresentados os resultados para cada estudo, de forma individual, junto com uma discusso geral sobre os resultados.

8.4 Resultados e discusso

8.4.1 Autoria de contedo para a Web
A Figura 28 mostra os valores das mtricas de reutilizao de software obtidas dos artefatos produzidos com e sem a abordagem. Nota-se um aumento signicativo tanto na porcentagem de reutilizao como na razo de reutilizao. porcentagem de reutilizao no desejada para zero. Analisando-se os dados, vericou-se que a porcentagem de reutilizao obtida exclusivamente com gerao de cdigo foi de 47,03%, ou seja, quase metade do cdigo reutilizado provm de um gerador. Foi vericada uma razo entre especicao e cdigo de 1:16,34, ou seja, para cada elemento de especicao so geradas, em mdia, pouco mais de 16 linhas de cdigo. A Figura 29 mostra os valores das mtricas indiretas de reusabilidade: instabilidade, complexidade e manutenibilidade obtidas dos artefatos produzidos com e sem a abordagem. Pode-se vericar que no houve alterao signicativa nas distribuies da mtrica de Tambm pode-se observar a reduo da

189

Figura 28: Comparao entre as mtricas de reutilizao para o estudo do domnio de autoria de contedo para a web instabilidade. A complexidade, por sua vez, aumentou de forma perceptvel, com muitos artefatos desenvolvidos com a abordagem sendo mais complexos do que o mximo obtido sem a abordagem. Os ndices de manutenibilidade tambm sofreram uma reduo com o uso da abordagem.

Figura 29: Comparao entre as mtricas indiretas de reusabilidade para o estudo do domnio de autoria de contedo para a web A Figura 30 analisa de forma mais aprofundada as medidas de instabilidade obtidas com a abordagem6 . Pode-se notar que o cdigo gerado mais instvel do que o cdigo no-gerado, em alguns casos chegando ao limite mximo desta mtrica (1). Os artefatos de gerao de cdigo (transformaes e geradores) apresentam uma distribuio intermediria s dos cdigos
neste grco, o cdigo gerado foi includo, apesar se ser um artefato no utilizado diretamente pelo desenvolvedor. Isto foi feito para ajudar na caracterizao da reutilizao apenas. O mesmo acontece em outros grcos deste captulo.
6 Observao:

190

gerado e no-gerado, porm de forma mais concentrada em torno do valor central da mtrica (0,5). Os modelos utilizados na abordagem tiveram sua instabilidade abaixo de 0,5, sendo em geral menos instveis do que os demais artefatos.

Figura 30: Distribuies de instabilidade de mdulo nos diferentes tipos de artefatos produzidos com a abordagem, no estudo de caso do domnio de autoria de contedo para web A Figura 31 analisa de forma mais aprofundada as medidas de complexidade ciclomtica obtidas com a abordagem. Pode-se notar que o cdigo gerado semelhante, na mdia, ao cdigo no-gerado, porm a distribuio do cdigo no-gerado est um pouco mais concentrada. Os demais artefatos, incluindo transformaes, geradores e modelos, so consideravelmente mais complexos do que o cdigo, com alguns valores acima do limite considerado como o de mdulos simples (10).

Figura 31: Distribuies de complexidade ciclomtica nos diferentes tipos de artefatos produzidos com a abordagem, no estudo de caso do domnio de autoria de contedo para web A Figura 32 analisa de forma mais aprofundada os ndices de manutenibilidade obtidos com a abordagem. Pode-se notar que os elementos de gerao de cdigo (transformaes e geradores) possuem menor ndice de manutenibilidade do que o cdigo, tanto gerado como no-gerado, que apresentaram distribuies prximas destas mtricas. O cdigo gerado, porm, apresenta valores ligeiramente maiores do ndice de manutenibilidade.

191

Figura 32: Distribuies do ndice de manutenibilidade nos diferentes tipos de artefatos produzidos com a abordagem, no estudo de caso do domnio de autoria de contedo para web Para os modelos, a manutenibilidade foi analisada atravs do nmero de atributos e de relacionamentos. Conforme mostra a Figura 33, os modelos utilizados para gerao de cdigo (metamodelos e modelos auxiliares) possuem poucos atributos, permanecendo completamente abaixo do limite considerado (41). Tambm possuem poucos relacionamentos, com o terceiro quartil sendo similar ao limite considerado (9). J os modelos utilizados como especicao possuem mais atributos e relacionamentos. A mdia do nmero de atributos coincide com o limite considerado (41), enquanto o nmero de relacionamentos tem distribuio bastante acima do limite considerado (9).

Figura 33: Distribuies do nmero de atributos e do nmero de relacionamentos nos modelos utilizados com a abordagem, no estudo de caso do domnio de autoria de contedo para web

Discusso O primeiro e mais evidente resultado observado o maior nmero de linhas de cdigo reutilizadas com a abordagem, alm de uma baixa taxa de reutilizao no desejada. Uma

192

primeira explicao a de que geradores produzem bastante cdigo redundante, e por isso o nmero de linhas naturalmente maior. Esta armao est prxima da realidade deste estudo, j que um dos itens importantes na identicao de candidatos a subdomnio a existncia de trechos repetidos de cdigo, como ressaltado por Knodel et al. (2005) e discutido na atividade AD.3 desta abordagem (Captulo 5). Neste estudo de caso, observa-se a existncia de diversos arquivos e trechos de cdigo parecidos sendo produzidos por geradores. Vale ressaltar que esta repetio no poderia ser facilmente resolvida atravs de componentes ou outras estruturas de cdigo, uma vez que apesar de serem basicamente repetidos, os trechos diferem em muitos pontos, e so resultados de inmeros parmetros e informaes sobre o domnio. Como resultado, a tentativa de se implementar componentes genricos que realizam estas variabilidades iria resultar em software mais complexo e difcil de ser mantido. A nica opo, portanto, seria copiar os trechos parecidos e modic-los manualmente, abordagem seguida no desenvolvimento tradicional. Em alguns casos, pode-se tentar aplicar tcnicas de refatorao de cdigo (FOWLER et al., 1999), mas estas so limitadas a somente alguns tipos de modicaes no cdigo. Analisando os artefatos produzidos, nota-se que, na maioria deles, exatamente esta tarefa de cpia e modicao manual que est sendo automatizada neste caso. A diferena entre os nveis de reutilizao com e sem a abordagem (cerca de 50%) corresponde aproximadamente porcentagem de reutilizao obtida por gerao (47,03%). Ou seja, o que est sendo gerado o cdigo que implementa a variabilidade que no pode ser automatizada em componentes, e foi construdo manualmente sem a abordagem. Outro dado que refora este indcio o aumento da complexidade e a reduo da manutenibilidade observados quando a abordagem utilizada. Estas diferenas podem ser vistas de forma geral (Figura 29), mas so particularmente ntidas quando se avalia os diferentes tipos de artefatos do MDD individualmente (Figuras 30, 31 e 32). Os artefatos de gerao de cdigo e modelos de domnio so consideravelmente mais complexos e difceis de manter do que o restante do cdigo. Observando-se os artefatos, nota-se que isto se deve ao grande nmero de instrues condicionais, laos, e a existncia de repetidas consultas aos modelos que so feitas nas transformaes e geradores. Ou seja, o grande nmero de parmetros citados anteriormente como necessrios para realizar a variabilidade em um componente foram migrados para os artefatos do MDD, tornando-os complexos e difceis de manter. No entanto, estes artefatos so modicados muito raramente, pois uma vez testados e validados, somente precisam ser alterados para efetuar correes de erros ou evoluo no domnio. Alm disso, e esta a principal diferena entre um gerador e um componente, um gerador

193

no efetivamente reutilizado no software nal, e sim o produto de sua gerao de cdigo, com caractersticas de reusabilidade prximas ao cdigo no-gerado. J os modelos, apesar de no geral serem mais complexos e difceis de manter do que o cdigo, so relativamente pequenos e em nmero reduzido, o que compensa sua complexidade. Enm, o que se observa neste estudo que ocorreu um aumento da reutilizao, em detrimento da simplicidade e facilidade de manuteno de alguns de seus artefatos. Em sistemas mais simples, pode no valer a pena o trabalho extra de se desenvolver uma infraestrutura deste tipo. Em outras palavras, mais fcil e simples codicar do que especicar e gerar cdigo. Porm, em sistemas grandes os benefcios do volume de reutilizao podem ser muito grandes para serem ignorados. Considere por exemplo construir um sistema envolvendo milhares de telas de cadastros, todas parecidas e similares, muitas delas com detalhes e customizaes necessrias. A complexidade extra neste caso pode ser um preo baixo a ser pago.

8.4.2

Aplicaes distribudas baseadas em computao em nuvem

A Figura 34 mostra os valores das mtricas de reutilizao de software obtidas dos artefatos produzidos com e sem a abordagem. A exemplo do domnio web, porm em menor grau, observa-se um aumento signicativo na porcentagem de reutilizao e na razo de reutilizao. Nota-se tambm que a porcentagem de reutilizao no desejada caiu alguns pontos percentuais quando a abordagem foi utilizada.

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

194

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

Figura 35: Comparao entre as mtricas indiretas de reusabilidade para o estudo do domnio de aplicaes distribudas baseadas em computao em nuvem A Figura 36 analisa de forma mais aprofundada as medidas de instabilidade obtidas com a abordagem. Pode-se notar que o cdigo gerado similar, na mdia, ao cdigo no-gerado. Porm, a distribuio referente ao cdigo gerado est mais concentrada ao redor do valor mdio desta mtrica (0,5). Os artefatos de gerao, por sua vez, esto concentrados em um ponto que representa baixa instabilidade. Com relao aos modelos, neste caso somente um modelo foi utilizado, e portanto a mtrica de instabilidade permaneceu no valor intermedirio (0,5). A Figura 37 analisa de forma mais aprofundada as medidas de complexidade ciclomtica obtidas com a abordagem. Pode-se notar que o cdigo gerado apresenta maior complexidade em relao ao cdigo no-gerado. Os artefatos de gerao so ligeiramente mais complexos do que o cdigo no-gerado, e os modelos apresentam complexidade baixa. Com exceo do cdigo gerado, todos os artefatos permaneceram dentro do limite que indica simplicidade (10). A Figura 38 analisa de forma mais aprofundada os ndices de manutenibilidade obtidos com a abordagem. No existem diferenas notveis na distribuio, porm h uma leve queda

195

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

Figura 37: Distribuies de complexidade ciclomtica nos diferentes tipos de artefatos produzidos com a abordagem, no domnio de aplicaes distribudas baseadas em computao em nuvem na manutenibilidade do cdigo gerado e nos artefatos de gerao, com relao ao cdigo gerado. A Figura 39 mostra que as quantidades de atributos de ambos os tipos de modelo (gerao e especicao) permaneceram abaixo do limite estipulado (41). O nmero de relacionamentos, porm, excedeu consideravelmente o limite (9) nos modelos de gerao, e de forma moderada no caso dos modelos de especicao. Discusso Neste domnio, a exemplo do domnio Web mas de forma menos acentuada, tambm foram observados aumentos no nvel e na razo de reutilizao de linhas de cdigo, e uma baixa taxa de reutilizao no desejada. Os mesmos motivos discutidos no estudo do domnio Web se aplicam a este caso, sendo observados diversos artefatos com alto grau de similaridade. Esta parece ser uma tendncia de domnios tcnicos, onde a tnica est em resolver problemas de mais baixo nvel de forma repetida e constante, como a persistncia e navegao, no caso do domnio Web, e distribuio, no caso deste domnio. Neste caso, inclusive, foi observada uma

196

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

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

razo ainda maior entre especicao e cdigo (1:26,35), o que indica que os geradores esto sendo mais produtivos. Porm, enquanto no estudo anterior os artefatos de gerao de cdigo e os modelos so mais complexos do que o cdigo, aqui foi observado o efeito inverso. O cdigo, tanto o gerado como o no-gerado, mais instvel, complexo e difcil de manter do que os artefatos de gerao. Isto se explica pela complexidade natural do domnio, uma vez que a computao em nuvem traz muitos desaos no triviais, como o clculo distribudo de invariantes do sistema, determinao de cliques maximais, descoberta dinmica de servios e execuo distribuda (LUCRDIO; JACKSON; SCHULTE, 2008). Detalhes sobre estes assuntos cam encapsulados no somente em componentes, mas tambm nos geradores, de forma que um desenvolvedor pode produzir aplicaes complexas mesmo sem conhecer a fundo todas as tecnologias envolvidas. Em outras palavras, em contraste com o estudo anterior, neste domnio mais fcil e simples especicar do que codicar.

197

Assim, o que se observou neste estudo foi, alm do aumento na reutilizao, um aumento na reusabilidade dos artefatos do domnio, percebido de forma indireta com a reduo da instabilidade, complexidade e diculdade de manuteno. Assim, enquanto no estudo anterior vericou-se que o uso da abordagem pode trazer benefcios em termos de volume de reutilizao, aqui observa-se que a abordagem pode simplicar o desenvolvimento, abstraindo detalhes e complexidades inerentes a este domnio complexo.

8.4.3

Eventos cientcos

A Figura 40 ilustra uma comparao entre os nveis de reutilizao obtidos com e sem a abordagem, para o estudo envolvendo o domnio de eventos cientcos. Nota-se que, ao contrrio dos estudos anteriores, com a abordagem tem-se menores taxas e razes de reutilizao. Porm, a taxa de reutilizao no desejada foi reduzida para menos da metade. Alm disso, neste domnio nota-se uma maior diferena entre a porcentagem de reutilizao e a razo de reutilizao, do que nos domnios anteriores. Isto porque h um grande nmero de artefatos que so reutilizados e modicados minimamente (reutilizao do tipo caixa-branca), como resultado do processo de customizao.

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

198

cdigo para cada elemento de especicao do que os dos estudos anteriores. Conforme discutido anteriormente, neste estudo no foram coletadas mtricas para os artefatos de cdigo, por motivos de falta de ferramentas adequadas. Porm, foram analisados os atributos dos artefatos de gerao, para efeitos de comparao com os outros estudos. Esta comparao apresentada na Figura 41. Pode-se notar que, em termos de instabilidade, os artefatos deste estudo esto mais prximos aos do estudo envolvendo o domnio Web, porm ligeiramente menos instveis. Em termos de complexidade ciclomtica, a distribuio cou mais concentrada e ligeiramente superior que os outros estudos. O ndice de manutenibilidade se mostrou notavelmente inferior aos outros estudos.

Figura 41: Comparao entre as mtricas de reusabilidade dos estudos dos domnios de eventos cientcos (EC), Web e Computao em Nuvem (CN) Foram utilizados somente dois modelos baseados em XML, e estes apresentaram uma mdia de 36,33 atributos e nenhum relacionamento. Com relao aos dados qualitativos, foram coletadas algumas impresses passadas pela equipe aps a execuo do estudo. Entre as impresses obtidas com a entrevista7 , destacam-se: Segundo a equipe, a abordagem permitiu atacar problemas recorrentemente enfrentados pela equipe, tais como o alto nvel de retrabalho procurando cdigos e testando cada mudana no domnio, a existncia de arquivos que nunca so utilizados mas que so includos nos produtos por convenincia, o que acaba por confundir os desenvolvedores e causando problemas de manuteno, e a necessidade de busca por links que precisam removidos dependendo da congurao de produtos adquiridos pelo cliente; Neste estudo, a automao conseguida com o MDD permitiu reduzir alguns problemas de
7O

contedo integral da entrevista encontra-se no Apndice C.

199

forma que no vinha sendo conseguida, por falta de tempo e diculdades em desenvolver uma soluo que atendesse a mltiplos clientes ao mesmo tempo; A equipe relatou diculdades no aprendizado das tecnologias de modelagem e gerao de cdigo, porm com relao abordagem citaram apenas que tiveram diculdades em compreender as funes especcas dos casos de mudana na abordagem. Segundo eles, no cou clara a necessidade de se criar mltiplos cenrios para descrever pequenas partes do problema; A equipe teve tambm diculdades na identicao correta das features, sendo necessria a presena constante do autor desta tese para orientar e corrigir as identicaes equivocadas. No geral, os participantes compreenderam os conceitos, mas tinham diculdade em reproduzi-los no domnio em questo, inserindo constantemente e de maneira equivocada, mdulos e funes como sendo features; e A equipe no soube responder de forma apropriada com relao ao processo investigativo de identicao de subdomnios, atividade de avaliao arquitetural, e atividade de documentao do domnio, pois no chegou a realizar estas atividades durante o estudo. Discusso Neste estudo, ao contrrio dos dois anteriores, ocorreu uma reduo da porcentagem e da razo de reutilizao, quando a abordagem foi utilizada. Porm, conforme discutido anteriormente, a mtrica de reutilizao em termos de LOC no pode ser lida literalmente, de forma isolada, pois pode ser distorcida por alguns fatores. Conforme a prpria equipe relatou em entrevista, h muitos artefatos que so reutilizados desnecessariamente. Alm de causar prejuzos manuteno, ocupar espao de forma desnecessria e confundir os desenvolvedores, este fato distorce a mtrica de reutilizao. Analisando-se tambm a quantidade de reutilizao no desejada, nota-se que houve reduo signicativa, ou seja, na realidade a quantidade de LOC reutilizadas foi menor, porm a reutilizao ocorreu de forma melhor, com menos cdigo desnecessrio poluindo a aplicao. Isto foi alcanado de forma simples, atravs de geradores que fazem a cpia seletiva dos arquivos de acordo com as conguraes do produto. Os artefatos produzidos pela equipe apresentaram qualidade inferior, em termos de instabilidade, complexidade e manutenibilidade, do que os artefatos desenvolvidos nos outros estudos. Isto se deve principalmente s diculdades com o aprendizado e treinamento, conforme citado pela prpria equipe. Alm disso, foram desenvolvidos poucos artefatos e uma baixa taxa

200

de reutilizao com gerao de cdigo (3,99%), devido principalmente falta de tempo e dedicao parcial dos participantes. Estes resultados so particularmente interessantes, pois representam a utilizao da abordagem em um cenrio mais tpico e prximo da realidade de uma organizao de software. Existe tambm uma ocorrncia que foi brevemente citada pela equipe e que merece uma avaliao mais aprofundada. Na entrevista, os participantes citaram que com a abordagem puderam resolver problemas que no conseguiam resolver anteriormente, no somente pela falta de tempo, mas tambm pela diculdade em se obter solues genricas que possam ser utilizadas por mltiplos clientes. Em muitos casos, as modicaes exigidas por um cliente no podem ser generalizadas e parametrizadas, pois a natureza das mudanas profunda, como por exemplo as diferentes formas de certicado, citadas como exemplo pela equipe. possvel criar um componente genrico capaz de gerar certicados para eventos com diferentes textos, tamanhos de fontes, de papel, entre outros parmetros. Porm, comum a existncia de chamados solicitando a presena de informaes extras, como um determinado texto em negrito, orientaes de texto diferentes, e dados no-convencionais, como por exemplo certicados de responsveis por sesses (chair de sesso). Nestes casos, a nica soluo encontrada era criar uma cpia do componente anterior e modic-la para o novo requisito. Com o MDD e a abordagem, a equipe conseguiu criar um suporte mais exvel para estas modicaes, sem perder a generalidade do componente original e sem causar a duplicao de verses. Outro problema citado o espalhamento da informao, o que exige um grande trabalho de inspeo, modicao e testes a cada congurao de um novo produto. Este espalhamento visvel nos dados coletados: no estudo realizado, em torno de 70 artefatos foram modicados em menos de 25%. Estas modicaes envolvem conguraes e customizaes, muitas delas duplicadas. Com a abordagem, foi possvel reunir grande parte dos parmetros de congurao em um nico modelo, e as modicaes pontuais e repetitivas so realizadas por geradores. Neste estudo, o modelo serve de entrada para conguraes em seis tabelas diferentes do banco, e quatro arquivos de congurao, que antes precisavam ser feitas individualmente. Alm disso, os geradores so mais conveis nesta tarefa, reduzindo a necessidade de testes mais exaustivos. As mtricas de nmero de atributos e relacionamentos para os modelos utilizados neste estudo mostram que existem muitos atributos (mdia de 36,33) e nenhum relacionamento, o que indica que se tratam de modelos que servem basicamente de congurao apenas.

201

8.5 Anlise das hipteses e concluses

Os dados e resultados obtidos com os estudos possuem indcios sobre a rejeio de algumas das hipteses nulas. Esta rejeio feita com base em anlise descritiva apenas, no sendo embasada por dados estatsticos rigorosos. Com relao hiptese H0a , conclui-se que ela rejeitada, pois nos trs estudos foram vericados aumento e/ou melhoria na reutilizao de software nos projetos utilizando a abordagem. Com relao hiptese H0b , no foi possvel alcanar a rejeio, uma vez que os resultados indicaram que a reusabilidade dos artefatos pode ser maior ou menor utilizando-se a abordagem. Com relao s hipteses H0c e H0d , os dados obtidos possuem indcios que apiam a rejeio, uma vez que os participantes dos estudos perceberam benefcios com a abordagem, e no tiveram diculdades signicativas no aprendizado. Mesmo para as hipteses nulas com indcios de rejeio, no se pode armar que as hipteses alternativas apresentadas na Seo 8.1.2 so verdadeiras. Ou seja, a abordagem aparentemente favorece a reutilizao, mas pode ser que existam projetos onde ela no acrescente benefcios ou mesmo cause diculdades signicativas de aprendizado e utilizao. O que parece ser uma concluso mais razovel que a abordagem pode aumentar a quantidade, em termos de LOC. Mas ela no aumenta, de forma absoluta, os valores das mtricas de complexidade e diculdade de manuteno, conforme percebido no estudo do domnio Web. Tampouco ela as reduz, conforme percebido no estudo do domnio Aparentemente, h uma tendncia a produzir artefatos com de computao em nuvem.

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

202

Figura 42: Efeito da abordagem na reusabilidade dos artefatos produzidos e explica de forma plausvel os efeitos observados. Porm, ela foi extrapolada, no

sendo embasada por evidncias mais slidas. Estudos mais rigorosos podem e devem ser realizados para complementar estes resultados e o conhecimento adquiridos nesta tese, para que generalizaes estatisticamente comprovadas possam ser formuladas.

8.6 Ameaas validade

Os dados obtidos com esta avaliao so bastante informativos e abrangentes. Porm, h muitas questes que sequer chegaram a ser exploradas, tais como o impacto da abordagem nos nveis de reutilizao internos, como aqueles alcanados com herana, por exemplo. Alm disso, algumas etapas da abordagem no puderam ser avaliadas, como a atividade de avaliao arquitetural e a documentao dos artefatos. Deve-se citar que a participao do autor da tese em dois dos estudos pode ter inuenciado negativamente os resultados, sendo uma ameaa sua validade, uma vez que tendo ele prprio desenvolvido a abordagem, no passou por diculdades em seu aprendizado, e provavelmente falhou em identicar pontos fracos da mesma, dois aspectos importantes da avaliao. Ainda assim considerou-se que os resultados obtidos so vlidos, pois muitos deles foram obtidos a partir de mtricas objetivas, que no sofrem a inuncia do pesquisador. As mtricas subjetivas foram coletadas diretamente dos participantes do terceiro estudo, e portanto tambm no foram inuenciadas. Vale mencionar tambm o fato de que a realizao dos estudos em ambiente industrial

203

Figura 43: Uma possvel hiptese alternativa elaborada a partir dos resultados da avaliao apresenta um menor grau de controle, uma vez que o desenvolvimento sofre inuncias e presses constantes, naturais deste tipo de ambiente. Como resultado, a qualidade e rigor dos dados menor do que em um estudo controlado. Por ser esta uma tese na rea de Engenharia de Software, no se pode descartar este tipo de estudo, anal, a indstria deve ser o destino imediato ou a longo prazo de toda e qualquer pesquisa relevante nesta rea. As lies aprendidas, ainda que em forma de comentrios e impresses subjetivas, devem ser consideradas como sendo relevantes e valiosas. O tamanho dos projetos envolvidos nos estudos, que se caracterizam entre pequeno e mdio portes, razovel para este tipo de avaliao, e no foi considerado como uma ameaa validade. Dado o tamanho das equipes ser muito reduzido, no foi possvel avaliar aspectos referentes ao trabalho colaborativo, nem a capacidade da abordagem em atender aos requisitos deste tipo de desenvolvimento. Devido tambm ao tamanho dos projetos, pode-se citar o fato de que a anlise de disperso e balanceamento das amostras permitiu identicar alguns poucos elementos fora da distribuio normal. Estes, porm, pouco inuenciaram os resultados. Em futuras replicaes deste experimento, pode-se optar por ignorar esta anlise sem muitos prejuzos aos resultados, caso os tamanhos dos projetos sejam similares aos aqui apresentados. A comparao de implementaes obtidas com e sem a abordagem pode tambm ter sofrido inuncia pelo fato de que a abordagem foi utilizada aps o desenvolvimento de uma implementao de exemplo. Nos dois primeiros estudos, essa implementao consistiu de

204

prottipos executveis desenvolvidos para praticar o desenvolvimento no domnio, e no terceiro estudo, consistiu de um produto real existente na empresa. Com isso, o desenvolvimento com a abordagem pode ter se beneciado de uma maior experincia no domnio. Porm, a prpria abordagem utiliza uma estratgia de desenvolvimento atravs de exemplos para proporcionar justamente este ganho de experincia antes da implementao efetiva dos artefatos do MDD e, portanto, este efeito parcialmente o que seria obtido com a abordagem de qualquer forma. Mas uma avaliao mais justa deveria envolver equipes diferentes partindo de um mesmo nvel de conhecimento sobre o domnio. Isto no foi possvel realizar pela diculdade em encontrar participantes para estes estudos. Finalmente, destacam-se as ameaas s validades interna, externa e de construo (WOHLIN
et al.,

2000). Os estudos foram planejados, denidos e executados de forma mais exploratria,

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

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

8.7 Consideraes nais

Neste captulo foi apresentada uma avaliao da tese sendo defendida nesta dissertao. Foram realizados trs estudos empricos, um em ambiente acadmico e dois em ambiente industrial, visando caracterizar os efeitos da utilizao da abordagem na reutilizao de software. Com exceo das ameaas validade citadas na seo anterior, os estudos contm resultados e indcios que permitiram a anlise de algumas concluses relevantes ao contexto

205

desta tese. A avaliao permitiu determinar os principais benefcios, mas tambm algumas falhas da abordagem, como por exemplo o fato de que os participantes do terceiro estudo no perceberam utilidade na identicao de cenrios para descrever as variabilidades nos comportamentos do domnio, alegando ser esta uma tarefa desnecessria. Esta limitao indica que talvez seja preciso uma reestruturao da abordagem, visando aumentar sua agilidade, ou mesmo um melhor treinamento visando reforar a importncia desta atividade. A escolha de qual direo a ser tomada depende de uma anlise mais aprofundada do problema. Tambm foram identicadas falhas na prpria avaliao, principalmente no terceiro estudo, como por exemplo a no utilizao do formato de documentao sugerido e nem dos processos investigativos para identicao dos subdomnios e de anlise arquitetural. Estas so decorrentes principalmente de restries execuo do estudo impostas pelo prprio cenrio industrial em que foi realizado. Vale a pena ressaltar que os estudos foram realizados em diferentes ambientes, utilizando diferentes tecnologias para o MDD, como EMF, GMF, openArchitectureWare, Microsoft Text Templates, GME, e em diferentes plataformas e linguagens de programao, como Java, C# e PHP. Isto refora a validade dos resultados e a sua independncia com relao s tecnologias envolvidas.

207

Trabalhos relacionados

As idias do MDD esto fortemente ligadas com o uso de ferramentas de auxlio ao desenvolvimento de software. Por esse motivo, no estranho o fato de que a indstria esteja voltando seus olhos para esse paradigma, uma vez que fabricantes de ferramentas vem um forte indcio de vantagem competitiva caso consigam oferecer a seus clientes uma maneira de alcanar os benefcios de qualidade e produtividade associados a esse paradigma de desenvolvimento. Na Seo 2.2.2 foram apresentadas as principais abordagens da indstria para o MDD. Mas com a academia no diferente, sempre existindo o interesse cientco nessa rea, com trabalhos que discutem os conceitos tericos e a viabilidade dessa abordagem.

9.1 Abordagens orientadas a modelos para reutilizao de software

Um dos primeiros trabalhos a propor a uma abordagem similar ao que se busca hoje com MDD data de 1980 (NEIGHBORS, 1980). Pioneiro na rea de reutilizao de software, James Neighbors, com sua abordagem Draco para desenvolvimento de software, tambm investigou a viabilidade de se utilizar modelos como a base para a construo de aplicativos. Nas palavras de Neighbors, a abordagem Draco se baseia na sensao frustrante de que a maior parte do sistema que voc est construindo atualmente a mesma que voc j construiu em alguns sistemas anteriores (NEIGHBORS, 1989). Sua proposta que seja feita uma anlise sobre um domnio de aplicaes similares, a exemplo do que props Parnas (1976), e que o conhecimento obtido seja representado por meio de linguagens especcas para este domnio (DSL) e para os domnios relacionados, de forma a facilitar sua reutilizao ao se construir um novo sistema. Essa proposta muito similar s idias do MDD. Na abordagem Draco, um analista do domnio, normalmente uma pessoa com experincia na construo de diferentes aplicaes similares, cria a descrio desse domnio segundo uma

208

DSL. Um domnio no Draco inclui um interpretador semntico (parser), que incorpora as regras gramaticais da linguagem. Desta forma, ao se construir um sistema para esse domnio, um engenheiro de software pode utilizar essa DSL. Por exemplo, considere um analista do domnio de jogos eletrnicos. Ele dene elementos como placar, comando, fase, jogador, entre outros, e os descreve utilizando regras gramaticais, que servem para a criao de um interpretador (parser). O analista de um sistema utiliza esses elementos para construir seu prprio jogo, criando elementos como Jogador 1, Jogador 2, comandoDireita, comandoEsquerda, etc. Uma possvel gramtica para essa DSL, onde um jogo envolve vrios jogadores, seria:

r r

rs r r r rrrt

rs r

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

s r r r r r rt
No Draco, o analista do domnio tambm pode construir transformaes que permitem que os elementos criados pelo analista do sistema sejam automaticamente transformados em domnios intermedirios, at eventualmente chegar em linguagem executvel. o que acontece quando, por exemplo, se deseja obter um modelo orientado a objetos deste jogo, para posteriormente implement-lo utilizando uma linguagem de programao orientada a objetos. No Draco, as transformaes se baseiam nas regras gramaticais das linguagem dos domnios, interpretadas pelo seu prprio parser. Por isso necessrio existir uma gramtica para a linguagem de origem e uma gramtica para a linguagem destino. Neste caso, seria necessria uma gramtica para esse modelo orientado a objetos intermedirio, que poderia ser parecida com:

ss t

209

ss trt t t rtr

ss trt t trtt t rtr rtr

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

ss r tr r tr t rr t rrt
De forma similar, com base na denio do domnio para uma linguagem executvel, como por exemplo Java, poderia ser denida uma transformao que gerasse o seguinte cdigo para este jogo:

ss r rt tr rt tr r rtr tr r ts tsr r ss stt tr rs

210

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

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

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

211

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

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

2003).

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

212

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

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

213

Weis, Ulbrich e Geihs (2003) apresentam uma proposta de um mecanismo para modelagem, denominado Kase, e uma linguagem para transformao de modelos, denominada Kafka. Eles apresentam os requisitos a serem atendidos por transformaes no desenvolvimento orientado a modelos. O primeiro deles que as transformaes devem ser automticas, pois de outra forma os desenvolvedores considerariam a criao de modelos uma tarefa improdutiva. Outro requisito que as transformaes no podem ser universais e genricas, mas sim especcas para cada caso, podendo ser adaptadas facilmente e reutilizadas. Finalmente, os autores ressaltam a necessidade de se utilizar linguagens visuais para a construo das transformaes, uma vez que o uso de linguagens textuais, tais como linguagens de programao e linguagens de transformao baseadas em XML, possuem uma distncia conceitual em relao aos modelos, dicultando a tarefa de construo de transformadores. As transformaes representadas na linguagem Kafka so baseadas em regras de mapeamento, facilitando a chamada engenharia ida e volta, ou seja, modelo para cdigo e cdigo para modelo. A abordagem desta tese tambm busca automatizar completamente as transformaes, de modo que no necessrio trabalho manual, o que poderia inibir o uso dos transformadores. Outro aspecto similar que tanto no trabalho de Weis, Ulbrich e Geihs (2003) como nesta tese, as transformaes devem ser especcas para cada caso. A idia aqui defendida que os transformadores devem ser customizados de acordo com os requisitos e com o contexto do domnio sendo construdo, da mesma forma que no mecanismo Kase. Existem dois pontos, no entanto, nos quais a presente abordagem difere do Kase: 1. Esta abordagem no est restrita a linguagens visuais, por entender que h subdomnios onde o nvel de abstrao da especicao deve ser mais baixo, aproximando-se das caractersticas e poder expressivo de uma linguagem textual; e 2. Nesta tese, as transformaes no se baseiam somente em regras de mapeamento, por dois motivos: (i) transformadores baseados em templates so mais simples de se construir e manter; e (ii) a necessidade da engenharia ida e volta reduzida com o uso de uma implementao de referncia e um processo de migrao de cdigo. Apesar de mais trabalhoso, esse caminho foi preferido por ser mais prtico. Czarnecki et al. (2005) discutem a combinao das idias de linhas de produto (Seo 2.1.2) e desenvolvimento orientado a modelos, ressaltando que essas duas linhas so complementares. Neste sentido, os autores propem a combinao da modelagem de caractersticas, ou features, com o uso de templates de caractersticas, responsveis pelo mapeamento automtico das caractersticas para modelos que as implementam, com base em transformaes de modelos.

214

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

215

base em exemplos do cdigo a ser gerado, com a diferena de que no Pulse-MDD ele guiado pela identicao de padres e critrios econmicos, enquanto nesta tese o processo est centrado nos diferentes tipos de variabilidade. A principal diferena desta tese com relao ao Pulse-MDD que neste ltimo a preocupao com o MDD comea somente na fase de projeto, enquanto nesta abordagem argumenta-se que ela deve comear antes, durante a anlise, uma vez que os modelos de features possuem papel importante nesta denio, e normalmente precisam ser adaptados para reetir a existncia dos artefatos MDD. Alm disso, iniciando-se na anlise, a preocupao com o MDD pode incluir a identicao e diviso de subdomnios automatizveis. Segundo defende-se nesta tese, reconhecer esta diviso natural do domnio um requisito importante para possibilitar o uso do MDD em cenrios prticos. Deelstra et al. (2003) discutem como uma abordagem para o desenvolvimento de linhas de produtos pode se beneciar do desenvolvimento orientado a modelos. Os autores argumentam que o MDD pode levar a vrios benefcios, e apresentam como ele pode ser utilizado para representao da variabilidade e derivao automtica de produtos. O suporte variabilidade com o MDD atravs de modelos do domnio, a exemplo da abordagem desta tese. Porm, os autores passam diretamente da representao da variabilidade derivao de produtos, sem entrar em detalhes sobre, por exemplo, a construo de uma arquitetura adequada para este cenrio, como o caso desta tese. O mesmo acontece com outros trabalhos encontrados na literatura. Muitas abordagens que combinam o MDD com engenharia de domnio (ou linhas de produtos de software) possuem foco maior no estgio de derivao automtica de produtos, dando pouca ou nenhuma nfase ao projeto do domnio de acordo com os princpios do MDD. Exemplos destas abordagens incluem (WEISS et al., 2008; VLTER; GROHER, 2007; BOTTERWECK; OBRIEN; THIEL, 2007; ARBOLEDA;
CASALLAS; ROYER, EISENECKER,

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

2004b).

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

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

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

216

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

217

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

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

218

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

219

(PREZ-MARTNEZ; SIERRA-ALONSO, 2006). A exemplo dos geradores baseados em templates utilizados nesta tese, o mapeamento proposto por Prez-Martnez e Sierra-Alonso (2006) utiliza regras imperativas, mais simples de implementar, mas mais complicadas quando se deseja promover rastreamento e realizar a transformao ida-e-volta. Os modelos de destino so descritos utilizando um perl UML2 desenvolvido exclusivamente para o C2, uma vez que a UML sozinha no capaz de representar todos os elementos deste estilo, como por exemplo conectores, portas, mensagens, etc. Diferentemente desta tese, porm, o trabalho de Prez-Martnez e Sierra-Alonso (2006) assume que os modelos de anlise so ricos o suciente para serem automaticamente transformados em uma arquitetura. A abordagem desta tese defende a idia de que necessrio trabalho manual e criativo considervel entre anlise e projeto arquitetural, de forma a incluir as preocupaes de todos os stakeholders. Assumindo-se um nico e pr-denido mapeamento, corre-se o risco de se projetar uma arquitetura incapaz de atender a todos os requisitos de forma adequada. Alm disso, um nico estilo arquitetural (C2) suportado. Finalmente, a abordagem de Prez-Martnez e Sierra-Alonso (2006) focada no desenvolvimento de produtos nicos, no cobrindo aspectos relativos reutilizao, como suporte variabilidade e derivao de produtos, como o caso desta tese. Vlter e Groher (2007) descrevem um conjunto de tcnicas para combinar MDD e linhas de produtos de software. Suas idias sobre a combinao de tcnicas esto de acordo com a losoa da abordagem desta tese, tais como o suporte aos dois tipos principais de variabilidade: baseada em features (congurao) e DSLs (construo criativa). Adicionalmente, os autores utilizam tcnicas orientadas a aspectos para facilitar a modelagem e implementao das variabilidades ortogonais, o que no tratado nesta tese. A principal diferena desta tese em relao ao trabalho de Vlter e Groher que aqui proposta uma abordagem sistemtica, com atividades e diretrizes concretas para desenvolver a infraestrutura de reutilizao orientada a modelos para o domnio. Alm disto, a abordagem desta tese tambm identica a necessidade do suporte simultneo a mltiplos subdomnios, o que no mencionado por Vlter e Groher. Robbes e Lanza (2008) descrevem um sistema de suporte transformao de programas baseada em exemplos. Neste sistema, o programador realiza um exemplo de mudana manualmente, que ento submetido ao sistema e posteriormente generalizado para outros contextos, tornando-se uma transformao reutilizvel. O sistema baseia-se no monitoramento do ambiente de programao para detectar automaticamente as modicaes feitas pelo desenvolvedor em algum artefato de cdigo. Estas so ento registradas como operaes de

220

mudanas, sendo posteriormente convertidas em entidades de primeira classe que descrevem como os elementos da AST (Abstract Syntax Tree ou rvore de Sintaxe Abstrata) de um programa (como as classes, atributos, mtodos e outras construes da linguagem) so modicados pelo desenvolvedor. No passo de generalizao, o sistema tenta identicar automaticamente o papel de cada mudana na transformao. Por exemplo, se uma mudana modica um pedao de cdigo envolvendo-o com comandos try-catch, o trecho de cdigo a ser envolvido um parmetro da transformao, enquanto os comandos try-catch so constantes a serem inseridas. O desenvolvedor da transformao pode ento renar esta generalizao em um editor personalizado, renomeando parmetros, especicando detalhes no detectados pelo sistema automtico, entre outras tarefas. O trabalho de Robbes e Lanza focado principalmente na transformao de programas e refactorings. Porm, a abordagem poderia ser aplicada para linguagens de modelagem tambm. Como os prprios autores destacam, pode ser ainda mais simples nestes casos, j que os passos automticos seriam realizados em estruturas mais simples do que uma AST de um programa. A abordagem desta tese similar ao raciocnio de desenvolvimento de transformaes atravs de exemplos seguido pelos autores, com a diferena de que a identicao das mudanas no automatizada, sendo realizada completamente pelo desenvolvedor. Alm disso, esta tese foca na engenharia de domnio, com o objetivo de produzir transformaes projetadas especicamente para dar suporte variabilidade no domnio. Varr (2006) tambm prope o desenvolvimento de transformaes orientada a exemplos, porm com foco em transformaes de modelos. Um processo iterativo e interativo utiliza derivao semi-automtica das transformaes, a partir de pares de modelos origem e destino. O desenvolvedor da transformao rena um conjunto de regras inicialmente derivadas at que as mesmas cheguem a um ponto satisfatrio. Diferentemente do trabalho de Robbes e Lanza (2008) e da abordagem desta tese, o processo de Varr no depende do registro das modicaes que levam da origem ao destino. Ao invs disso, o processo tenta estabelecer mapeamentos analisando exemplos de modelo origem e destino. A abordagem desta tese (assim como a de Robbes e Lanza (2008)) mais voltada para os estgios iniciais do desenvolvimento, uma vez que tenta capturar o esforo manual para transformar modelos ou programas, medida que os exemplos de destino so construdos, de forma incremental e gradual. Em contraste, o trabalho de Varr comea somente aps exemplos de modelos de origem e destino j existirem, sendo portanto mais apropriado para estgios posteriores, quando o desenvolvedor j possui uma idia concreta de como o destino da transformao deve ser.

221

Bierhoff, Liongosari e Swaminathan (2006) utilizam exemplos no somente para derivar as transformaes, mas tambm as DSLs. Os autores propem uma abordagem incremental: comeando com uma aplicao, constri-se uma DSL para ela, contendo os elementos e conceitos da aplicao, e os parmetros necessrios para congur-la. Em seguida, novas aplicaes so adicionadas incrementalmente, e suas diferenas introduzem novas variaes na DSL, aumentando sua generalidade. Porm, os autores destacam que esta abordagem puramente bottom-up precisa ser orientada por decises de projeto tomadas cuidadosamente de antemo, caso contrrio corre-se o risco de se produzir DSLs extremamente complexas e difceis de se manter. Este exatamente o caminho tomado pela abordagem desta tese, que busca mesclar uma etapa top-down para preparar o domnio para automao, com uma etapa bottom-up que introduz detalhes e renamentos necessrios para o funcionamento prtico das DSLs e das transformaes. Santos, Koskimies e Lopes (2008) propem a extenso de frameworks com uma camada adicional baseada em programao orientada a aspectos que codica uma DSL, buscando alavancar a reutilizao de software atravs de tcnicas generativas. Um modelo conceitual de um framework manualmente extrado pelo desenvolvedor, que descreve seus elementos e conceitos em termos de um metamodelo especco. Este modelo ento utilizado em conjunto com um framework de linguagem para produzir ferramentas concretas para a nova linguagem. Utilizando estas ferramentas, o desenvolvedor de aplicaes pode especicar uma aplicao e gerar cdigo em termos dos elementos do framework. O trabalho de Muszynski (2005) tambm prope a derivao de uma DSL a partir de uma implementao de referncia, tornando a DSL extrada o ponto central para especicao de produtos e gerao de cdigo. Estes trabalhos so similares abordagem desta tese, pois utilizam uma DSL, geradores e um processo bottom-up para derivar os mapeamentos entre a linguagem e a implementao de referncia (ou framework). Eles tambm possuem um elemento top-down implcito, que corresponde ao processo de desenvolvimento da implementao de referncia ou do framework, o que envolve tarefas como gerenciamento de variabilidade na engenharia de domnio. A principal diferena que na abordagem desta tese o elemento top-down explcito e focado no problema da reutilizao, indo mais alm no processo, at o desenvolvimento de uma primeira verso da DSL de forma exclusivamente top-down. O resultado que nesta tese as DSLs so mais prximas do domnio do problema, permitindo tarefas mais criativas, facilitando o desenvolvimento de aplicaes e oferecendo mais exibilidade ao desenvolvedor. Em contrapartida, o desenvolvimento de geradores mais complexo devido a esta maior proximidade com o domnio do problema. As extenses ao modelo de features descritas por Czarnecki, Helsen e Eisenecker (2004b),

222

com cardinalidades de features e atributos, entre outras (Seo 3.1.1), permitem a especicao de variabilidades mais complexas, de forma similar variabilidade baseada em DSLs descrita na abordagem desta tese. Atravs destas extenses possvel representar praticamente o mesmo tipo de variabilidade que possvel representar utilizando-se, por exemplo, um metamodelo. A principal diferena que com uma DSL tem-se um poder expressivo mais focado no problema, sendo portanto uma soluo mais intuitiva, podendo inclusive ser utilizada e compreendida por especialistas. Mas nada impede que um modelo estendido de features seja convertido em um metamodelo, dando origem a uma DSL. Mas alm disso, a abordagem desta tese tem outras contribuies, como um conjunto de diretrizes e regras para ajudar no processo de identicao destas variabilidades, no desenvolvimento das sintaxes abstrata e concreta. Alm disso, nesta tese o metamodelo complementado com informaes originadas em uma implementao concreta, o que facilita a identicao de variabilidades mais detalhadas e a construo de transformaes e geradores de cdigo mais precisos no suporte variabilidade.

9.2 Trabalhos relacionados com o uso de mtricas para MDD e reutilizao

O estado da prtica na avaliao de qualidade de modelos contm evidncias de que a modelagem ainda tida como uma atividade artesanal. Apesar de existirem alguns padres e regras baseadas no bom senso (como minimizar o acoplamento, aumentar a coeso, manter uma hierarquia de classes pequena), os desenvolvedores ainda dependem muito da opinio de especialistas para determinar quando um modelo bom ou no (FRANCE; RUMPE, 2007). Porm, existem diversos trabalhos que investigam a avaliao de modelos e o uso de mtricas para aumentar a conabilidade dos resultados da avaliao. Mohagheghi e Aagedal (2007) apresentam os principais aspectos relacionados avaliao de qualidade de um processo de MDD. Entre estes, destacam-se os aspectos de qualidade da linguagem de modelagem utilizada, tais como sua complexidade e adequao ao domnio, a qualidade das ferramentas utilizadas no processo, o conhecimento dos especialistas com relao ao uso das linguagens e ferramentas, a qualidade do processo utilizado e o uso de tcnicas para identicar falhas e defeitos em projetos MDD. Nesta tese, foram utilizadas mtricas para avaliao da linguagem de modelagem, como parte dos estudos de caso. Alm disso, a qualidade do processo tambm foi uma preocupao importante, e a cobertura das atividades essenciais foi discutida na Seo 4.5, onde compara-se a abordagem desta tese com um modelo de maturidade em MDD.

223

Monperrus et al. (2008) argumentam que o custo para se coletar mtricas em um projeto orientado a modelos extremamente alto, devido especicidade a um domnio, o que impede que sejam utilizadas mtricas genricas. Como consequncia, necessrio desenvolver ferramentas especcas para medir software cada vez que um novo domnio implementado. Para resolver este problema, os autores desenvolveram uma abordagem orientada a modelos para a gerao de sistemas coletores de mtricas especcas de domnio, com base em especicaes formais das mtricas a serem utilizadas. Especialistas do domnio especicam quais mtricas so necessrias, seguindo um metamodelo denido pela abordagem, e so automaticamente geradas ferramentas capazes de coletar estas mtricas. Uma abordagem parecida apresentada por Guerra, Lara e Daz (2008). Neste trabalho, os autores descrevem uma linguagem especca de domnio para a denio de mtricas. Esta linguagem pode servir de entrada para a coleta automtica destas mtricas. Porm, diferentemente do trabalho de Monperrus et al. (2008), aqui os autores acrescentam a preocupao com reprojeto e refatorao de modelos, visando a sua melhoria. A linguagem para denio de mtricas tambm inclui aes que representam modicaes nos modelos, de forma a implementar o reprojeto. Nos estudos de caso desta tese, o objetivo foi avaliar a abordagem e suas vantagens com relao ao desenvolvimento para reutilizao tradicional, e portanto no foi necessria a denio de nenhuma mtrica especca para um domnio. Genero, Poels e Piattini (2008) apresentam doze mtricas para avaliao estrutural de modelos entidade-relacionamento, com o objetivo de determinar sua manutenibilidade atravs de sua compreensibilidade. A premissa de seu trabalho a de que quanto mais compreensvel for um diagrama, maior ser a sua facilidade de manuteno. Foi realizado um estudo emprico, que demonstrou que a compreensibilidade de um diagrama E-R afetada por sua complexidade estrutural, ditada pela quantidade de atributos e relacionamentos, em particular relacionamentos 1:1 e 1:N. Quanto mais atributos e relacionamentos (1:1 e 1:N) um diagrama possuir, menos compreensvel ele ser. interessante notar que no foi identicada evidncia que relaciona o tamanho de um diagrama em termos de nmero de entidades com a compreensibilidade, a no ser atravs de sua relao bvia com o nmero de relacionamentos. Igualmente, no foi evidenciada relao com o nmero de relacionamentos N:M. Assim, entre as doze mtricas originalmente propostas, apenas estas trs foram comprovadamente vericadas como sendo relevantes para a manutenibilidade. Em outro trabalho (GENERO et al., 2007), alguns destes mesmos autores demonstram que as mesmas propriedades estruturais de diagramas E-R tambm possuem inuncia na manutenibilidade de diagramas de classes UML, particularmente os relacionamentos de associao e generalizao. Estas mtricas foram adaptadas e utilizadas

224

nesta tese, durante os estudos de caso, conforme descrito no Captulo 8. Pilgrim (2008) apresenta algumas mtricas para determinar o nvel de abstrao de um modelo. O objetivo avaliar a ecincia das transformaes entre modelos, argumentando que transformaes devem inicialmente ser focadas em transformaes na semntica, e somente posteriormente devem ser includos detalhes da plataforma. As mtricas se baseiam no nmero de atributos, a exemplo do trabalho de Genero, Poels e Piattini (2008), mas tambm no tamanho do diagrama. Nesta tese, no foram utilizadas estas mtricas, pois a ecincia das transformaes no foi o foco dos estudos de caso. Chidamber e Kemerer (1994) apresentam algumas mtricas clssicas da orientao a objetos baseadas em conceitos como acoplamento, coeso, complexidade de objeto, escopo de propriedades, conjunto de respostas e combinao de classes. Os autores denem as seguintes mtricas: mtodos ponderados por classe (WMC - Weighted Methods per Class); profundidade da rvore de herana (DIT - Depth of Inheritance Tree); nmero de lhos (NOC - Number Of Children); acoplamento entre classes (CBO - Coupling Between Object classes); resposta para uma classe (RFC - Response For a Class); e falta de coeso em mtodos (LCOM Lack of Cohesion in Methods). Estas mtricas focam em diferentes aspectos de um projeto, tais como complexidade, diculdade de desenvolvimento e manuteno. Os autores tambm destacam o papel do acoplamento na reutilizao. Quanto menor o acoplamento, mais fcil ser a reutilizao de uma determinada classe. Outras mtricas clssicas para projetos orientados a objetos incluem a estabilidade (MARTIN, 1994), manutenibilidade (VANDOREN, 1997) e complexidade (MCCABE, 1976). Algumas destas mtricas foram utilizadas nos estudos de caso, nas partes do domnio onde no houve aplicao do MDD e para comparao com o software construdo manualmente, conforme descrito no Captulo 8. Muskens, Chaudron e Lange (2004) propem a coleta de mtricas clssicas da orientao a objetos diretamente em modelos UML, ou seja, antes que exista cdigo-fonte. Os resultados mostraram que possvel detectar os mesmos problemas utilizando esta abordagem, porm no incio do desenvolvimento. Portanto, aes corretivas so menos dispendiosas, uma vez que no exigem a modicao extensa do cdigo. Os autores tambm propem mtricas adicionais baseadas em modelos arquiteturais descritos segundo a viso 4 + 1 (KRUCHTEN, 1995). O argumento que as mtricas clssicas, mesmo sendo coletadas a partir dos modelos UML, no consideram as interaes entre as diferentes vises, como por exemplo a referncia a classes e mtodos a partir de um diagrama de sequncia. Porm, a validade destas mtricas no apresentada neste trabalho. Nesta tese, no foi possvel aplicar estas mtricas, uma vez que elas

225

esto xadas na UML e na viso 4 + 1, no sendo adequadas para DSLs. Lange e Chaudron (2004) apresentam algumas regras e mtricas para avaliao de modelos UML, considerando a sua completude e consistncia. Exemplos destas regras incluem: objetos sem nome, classes sem mtodos, interfaces sem mtodos, classes abstratas em diagramas de sequncia, classes no chamadas em diagramas de sequncia, mensagens entre classes no relacionadas, entre outras que ajudam na avaliao e garantia da qualidade de modelos UML. Para esta tese estas mtricas no so teis, uma vez que no podem ser usadas para comparao dos nveis de reutilizao com e sem a aplicao de MDD conforme proposto na abordagem. Em outro artigo, Lange e Chaudron (2005) apresentam um modelo de qualidade para desenvolvimento de software baseado em UML. Alm dos atributos de qualidade a serem avaliados, como complexidade, rastreabilidade, modularidade, comunicabilidade e esttica, entre outros, os autores apresentam uma lista sobre quais mtricas podem ser utilizadas para avaliar estes atributos. Por exemplo, para avaliar a complexidade, os autores citam as mtricas de profundidade da rvore de herana (DIT), coeso, nmero de casos de uso por classe e nmero de classes por caso de uso. Nesta tese no foi feita avaliao de qualidade do software baseado em UML, porm algumas das mtricas foram utilizadas nos estudos de caso, com o objetivo de avaliar os benefcios da abordagem proposta. A iniciativa Modelware tambm investigou mtricas para o desenvolvimento orientado a modelos (MODELWARE, 2006c). Foram denidas mtricas para diversos aspectos de engenharia, incluindo mtricas de qualidade do produto, incluindo qualidade dos modelos e demais artefatos, mtricas de processo, incluindo transformaes e geradores de cdigo, e mtricas de projeto, teis para estimativas e outras tarefas de gerenciamento. interessante notar que as mtricas sugeridas para a qualidade da arquitetura so as mesmas da orientao a objetos descritas por Chidamber e Kemerer (1994): WMC, RFC, LCOM, CBO, entre outras. A exemplo do trabalho de Muskens, Chaudron e Lange (2004), estas levam identicao dos mesmos problemas do que quando coletadas diretamente do cdigo-fonte, com a diferena de que isto ocorre durante o projeto. Mascena, Almeida e Meira (2005) e Mascena (2007) apresentam uma anlise sobre mtricas relacionadas reutilizao de software, incluindo trs categorias: mtricas orientadas a fatores econmicos, estruturais e de repositrio. Entre estas, as mtricas estruturais so a base para analisar de forma mais aprofundada o que est sendo reutilizado. So elas: porcentagem de reutilizao (RP - Reuse Percent) (POULIN; CARUSO, 1993); nvel de reutilizao (RL Reuse Level) (FRAKES; TERRY, 1994); frequncia de reutilizao (RF - Reuse Frequency) (FRAKES; TERRY, 1994); tamanho e frequncia de reutilizao (RSF - Reuse Size and Frequency)

226

(DEVANBU et al., 1996); razo de reutilizao (RR - Reuse Ratio) (DEVANBU et al., 1996); e densidade de reutilizao (RD - Reuse Density) (CURRY et al., 1999). Estas so mtricas simples, porm no podem ser consideradas como indicadores isolados, uma vez que possuem problemas por no considerar a natureza dos artefatos reutilizveis e nem a maneira com que estes so reutilizados, penalizando, por exemplo, grandes sistemas e sistemas pouco modularizados (monolticos). Por este motivo, existe outra vertente que defende a idia de que melhor tentar medir a reutilizao atravs da avaliao de atributos de qualidade que medem o quo reutilizvel um determinado artefato de software. Neste sentido, so sugeridas mtricas indiretas, como manutenibilidade e complexidade (POULIN, 1994). Estas j foram utilizadas com sucesso em outros estudos relacionados reutilizao de software, como por exemplo o trabalho de Almeida et al. (2007a). Nesta tese, foram utilizadas algumas das mtricas de reutilizao, alm das mtricas indiretas, na avaliao dos estudos de caso.

9.3 Consideraes nais

A literatura nas reas de reutilizao de software e desenvolvimento orientado a modelos relativamente rica em trabalhos que exploram os aspectos processuais destes dois paradigmas. Porm, a investigao conjunta das duas linhas de pesquisa ainda recente, e normalmente os trabalhos focam em partes isoladas do problema. Apesar de esta tendncia ser natural e, academicamente, mais seguro, ainda existem espaos para contribuies que resultem da investigao conjunta das duas linhas. interessante notar que as duas reas, aparentemente distintas, tiveram um nico pesquisador que investigou de forma pioneira diversos conceitos que posteriormente formaram a base de cada rea separadamente. James Neighbors, em sua abordagem Draco (NEIGHBORS, 1980), combinou os conceitos de domnio (tendo cunhado o termo Anlise de domnio) e transformaes de software de forma inovadora. Esta unio entre reutilizao e MDD permaneceu relativamente ignorada por vrios anos, sendo atualmente resgatada principalmente aps o surgimento da MDA (LUCRDIO et al., 2006). Neste captulo foram apresentados trabalhos acadmicos na rea de desenvolvimento orientado a modelos e reutilizao de software, e que possuem alguma interseo com a abordagem desta tese. Tambm foram discutidos trabalhos relacionados com a avaliao realizada, e que serviram de base para a denio das mtricas utilizadas nesta tese.

227

10 Concluses

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

10.1 Principais contribuies

Nesta dissertao busca-se resolver parte do problema da reutilizao atravs do desenvolvimento orientado a modelos. Aps estudos e pesquisas nas reas relacionadas, foi denida uma abordagem orientada a modelos para reutilizao de software, visando guiar o engenheiro de software desde as atividades iniciais de anlise at a implementao de artefatos reutilizveis de um domnio, utilizando o desenvolvimento orientado a modelos para elevar e melhorar a reutilizao. Neste sentido, as seguintes contribuies foram feitas nesta rea:

228

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

10.2 Lies aprendidas

As contribuies citadas so de carter cientco e acadmico, apresentando melhorias e aspectos ainda pouco explorados na literatura. Porm, com o desenvolvimento deste trabalho, diversas lies importantes foram aprendidas. Durante esta pesquisa, foram estudadas diferentes tecnologias relacionadas ao MDD. Neste perodo, pode-se perceber a evoluo do estado-da-arte e da prtica nesta rea. H poucos anos atrs, a falta de ferramentas e suporte para este tipo de desenvolvimento era uma forte preocupao. A proposta inicial deste trabalho, apresentada em 2005, previa o desenvolvimento de parte das ferramentas necessrias para a aplicao do MDD. Na poca em que esta dissertao foi escrita, em 2009, no s existem ferramentas disponveis, mas tambm existem diversas opes, todas elas sendo efetivamente utilizadas na prtica pela indstria. Nesta tese, foram utilizadas trs alternativas diferentes, e ainda existem muitas outras igualmente capacitadas. Isto demonstra a tendncia de que o MDD est e ser cada vez mais presente na realidade do desenvolvimento de software.

229

A realizao dos estudos empricos tambm proporcionou o aprendizado de importantes lies. A primeira delas foi a importncia da experincia em ambiente industrial. Em ambas as experincias, percebeu-se que apesar do crescimento em importncia, o MDD ainda uma tecnologia muito distante da realidade da grande maioria das empresas. Este fato pode ser percebido no terceiro estudo, onde a empresa envolvida sequer conhecia a maioria dos conceitos envolvidos. E este no parece ser um retrato somente do cenrio brasileiro. Por exemplo, o segundo estudo emprico, realizado durante o estgio de doutorado na Microsoft Research, foi uma das primeiras iniciativas em MDD deste importante instituto de pesquisa. Durante as apresentaes e seminrios no nal do estgio, realizadas pelo autor desta tese, muitos dos participantes ali presentes estavam vislumbrando os conceitos do MDD pela primeira vez, inclusive importantes pesquisadores e funcionrios desta grande empresa da rea de TI. O fato de que a prpria Microsoft possui uma soluo voltada para o desenvolvimento de DSLs e geradores de cdigo apenas refora esta observao. Claro que no se pode generalizar estas observaes com base em fatos isolados, mas a experincia destes anos de doutorado, aps participaes em diversos eventos cientcos e contatos com empresas, ainda no produziram evidncia do contrrio. Outra importante lio aprendida diz respeito grande variedade de trabalhos similares existentes na literatura. muito comum encontrar trabalhos bastante parecidos com os temas aqui investigados. Porm, h tambm grande diversidade no foco, com cada trabalho sendo bastante direcionado a uma determinada linha de pesquisa caracterstica do grupo de pesquisa que o realiza. No existem muitos trabalhos derivados destas iniciativas isoladas e que buscam englobar e unicar os diversos aspectos do problema, caminho este que foi seguido nesta tese. As contribuies alcanadas comprovam que h espao tambm para este tipo de pesquisa. Neste quesito, cabe tambm uma observao: a despeito da grande quantidade e variedade de trabalhos na rea, raro encontrar estudos empricos buscando sua validao, a exemplo do que se tentou realizar nesta pesquisa. difcil encontrar mtricas e valores para serem utilizados como base para este tipo de estudo, sendo frequentemente necessrias adaptaes ou interpretaes indiretas para se extrair concluses relevantes.

10.3 Limitaes e Trabalhos futuros

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

230

identicadas como sendo decitrias de contribuies. Assim, os seguintes pontos podem ser investigados futuramente:

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

231

desenvolvimento de transformaes que geram outras coisas alm do cdigo-fonte, como outros modelos, arquivos de congurao, documentao, entre outros. Este um ponto interessante, pois neste tipo de artefato no h a possibilidade de utilizao, por exemplo, de padres de projeto e outras tcnicas que se baseiam em conceitos da orientao a objetos, em particular, a herana. Este poderia ser o tema de um trabalho de mestrado; Especializao da abordagem para domnios especcos: outra limitao desta tese que a abordagem um pouco vaga em algumas atividades, como aquelas para a denio das DSLs, por exemplo. Idealmente, deveria-se buscar um processo mais sistemtico, de forma a reduzir as possibilidades de erros e interpretaes erradas. Porm, em alguns casos no foi possvel denir mais detalhes pela prpria natureza criativa do processo de criao de software. Trabalhos futuros, principalmente de mestrado, poderiam explorar a aplicao da abordagem em diferentes domnios, visando detalhar mais algumas atividades conforme as caractersticas destes domnios. Durante esta aplicao, poderiam ser identicadas heursticas que facilitem principalmente as atividades de projeto arquitetural voltado para o MDD, construo de DSLs, transformaes e geradores de cdigo especializados para um determinado domnio; Assistncia contextualizada automatizada: esta outra possibilidade de trabalhos futuros. A abordagem no oferece nenhum tipo de ajuda no sentido de acompanhamento de processo, com base no contexto da tarefa atual ou de outras informaes relevantes, como por exemplo a necessidade de aplicao de um padro ou estilo arquitetural. Neste possvel trabalho futuro, a partir de sugestes sobre quais atividades a serem realizadas em um contexto particular, como por exemplo a exibio automtica de ajuda especca de contexto, desenvolvedores de produtos podem ser ativamente guiados durante tarefas de soluo de problemas. No contexto do MDD, ela pode ajudar com as tarefas Tecnologias complexas envolvidas com o desenvolvimento das linguagens e ferramentas especcas de domnio, transformaes e adaptao manual de cdigo gerado. como o quadro de tarefas do GMF (Generic Modeling Framework), as receitas do openArchitectureWare (Seo 2.2.2) e as Microsoft Blueprints1 so exemplos dessa assistncia sendo aplicada ao MDD. Trabalhos futuros podem explorar as atividades necessrias para o desenvolvimento deste tipo de assistncia no contexto do MDD e da engenharia de domnio. Este poderia ser o tema de um trabalho de mestrado e/ou doutorado, dependendo da sua abrangncia; Colaborao no MDD: o desenvolvimento orientado a modelos possui diferentes tarefas
1 ttsrstsrttrrtss

232

que envolvem a participao de mltiplos membros de uma equipe, tais como a anlise de features e a denio de mltiplas DSLs para diferentes domnios. Tambm pode-se citar a existncia de equipes distintas para trabalhar com a implementao de referncia, com as tecnologias de modelagem e os geradores de cdigo. Porm, a determinao exata de onde a colaborao no MDD ocorre de maneira mais intensa, visando esclarecer os pontos de exibilizao na comunicao e atividades da equipe que podem ser alcanados, ainda se mostram incipientes, como indicado por Steffen et al. (2007). Assim, trabalhos futuros podem investigar a natureza desta colaborao, incluindo possivelmente a considerao sobre desenvolvimento distribudo, ou at mesmo os aspectos ferramentais envolvidos na colaborao. Este poderia ser o tema de um trabalho de mestrado e/ou doutorado, dependendo da sua abrangncia; e Migrao automtica de cdigo: o uso da implementao de referncia como ponto de partida para o desenvolvimento de geradores traz uma srie de benefcios. Porm, o processo de migrao de cdigo, necessrio neste mapeamento para os geradores, apresenta dois problemas (MUSZYNSKI, 2005): (i) trata-se de um processo que consome cerca de 20-25% do tempo de desenvolvimento da implementao de referncia; e (ii) causa duplicao de cdigo, pois apesar de aps a primeira migrao ser possvel descartar completamente a implementao de referncia, na prtica isto no ocorre devido s diculdades de se trabalhar no nvel do gerador. Como resultado, so mantidas tanto a implementao de referncia como o gerador, e continua-se trabalhando com os dois artefatos. Apesar de no-trivial, a automao, mesmo que parcial, seria a soluo para estes problemas. Ainda no existe uma soluo automtica para migrao de cdigo nas principais ferramentas do mercado, e este um interessante tema para trabalhos futuros, podendo ser realizados como um ps-doutoramento na rea.

10.4 Consideraes nais

Nesta dissertao apresentou-se a tese de que o MDD pode aumentar e/ou melhorar a reutilizao de software em projetos de engenharia de domnio, descrevendo uma abordagem para esta nalidade e sua avaliao atravs de estudos empricos. A abordagem combina elementos de processo, como atividades, tarefas, entradas e sadas, com diretrizes e tcnicas auxiliares que guiam o desenvolvedor durante a engenharia de domnio orientada a modelos. A principal contribuio est em reconhecer a existncia de mltiplos subdomnios, cada um com seu potencial de automao, e em oferecer um mtodo concreto para que o engenheiro de software possa lidar com eles.

233

Esta abordagem um passo inicial em direo a um framework de processo completo para a utilizao efetiva do MDD como facilitador da reutilizao. Trata-se de um ponto central, ao redor do qual necessrio denir atividades de suporte e de gerncia, alm de outras prticas de engenharia no cobertas pela abordagem. Esta dissertao apresenta os resultados de uma pesquisa aplicada, que busca unicar diferentes tcnicas relacionadas reutilizao de software e MDD de uma forma original, oferecendo um suporte combinado que melhor do que a aplicao das tcnicas de forma isolada. Os resultados foram interessantes e esclarecedores, principalmente em termos da utilizao prtica em ambiente industrial. Comparando-se com o estado-da-arte, nota-se que as contribuies deste tipo de pesquisa so relevantes, tendo em vista a escassez de trabalhos que visam somente solidicar e formalizar contribuies que ainda apresentam falhas e falta de detalhes sobre as diversas formas de desenvolvimento produtivo de software.

235

Referncias
ALFEREZ, M. et al. A model-driven approach for software product lines requirements engineering. In: SEKE. [S.l.]: Knowledge Systems Institute Graduate School, 2008. p. 779784. ISBN 1-891706-22-5. ALLILAIRE, F. et al. Global model management in Eclipse GMT/AM3. In: Eclipse Technology eXchange Workshop (eTX) at the ECOOP 2006 conference. Nantes, France: [s.n.], 2006. . [S.l.]: ALMEIDA, E. S. C.R.U.I.S.E - Component Reuse In Software Engineering. In: C.E.S.A.R. e-books, 2007. cap. 4 - Software Reuse Processes: The State-of-The-Art, p. 81100. ALMEIDA, E. S. et al. An experimental study in domain engineering. In: 33rd IEEE EUROMICRO Conference on Software Engineering and Advanced Applications (SEAA), Component-Based Software Engineering Track. [S.l.: s.n.], 2007. p. 93100. ALMEIDA, E. S. et al. A systematic approach to design domain-specic software architectures. Journal of Software - Academy Publisher, v. 02, n. 2, p. 3851, 2007. ALMEIDA, E. S. et al. RiSE project: Towards a robust framework for software reuse. In: IEEE International Conference on Information Reuse and Integration (IRI). Las Vegas, USA: IEEE/CMS, 2004. p. 4853. ALMEIDA, E. S. et al. A survey on software reuse processes. In: IEEE International Conference on Information Reuse and Integration (IRI 2005). Las Vegas, USA: IEEE/CS Press, 2005. p. 6671. ALMEIDA, E. S. et al. The domain analysis concept revisited: A practical approach. In: 9th International Conference on Software Reuse (ICSR). Torino, Italy: Lecture Notes in Computer Science, Springer-Verlag, 2006. v. 4039, p. 4357. ALMEIDA, E. S. et al. Domain implementation in software product lines using OSGi. In: 7th International Conference on Composition-Based Software Systems (ICCBSS). Madrid, Spain: [s.n.], 2008. p. 7281. AMBLER, S. W. Agile model driven development is good enough. IEEE Software, v. 20, n. 5, p. 7173, 2003. ANASTASOPOULOS, M.; ATKINSON, C.; MUTHIG, D. A concrete method for developing and applying product line architectures. In: AKSIT, M.; MEZINI, M.; UNLAND, R. (Ed.). NetObjectDays. [S.l.]: Springer, 2002. (Lecture Notes in Computer Science, v. 2591), p. 294312. ISBN 3-540-00737-7. ANASTASOPOULOS, M.; GACEK, C. Implementing product line variabilities. In: Symposium on Software Reusability (SSR). Toronto, Canada: [s.n.], 2001. p. 109117.

236

ANTKIEWICZ, M.; CZARNECKI, K. Framework-specic modeling languages with round-trip engineering. In: NIERSTRASZ, O. et al. (Ed.). Model Driven Engineering Languages and Systems (MoDELS 2006). [S.l.]: Springer Berlin / Heidelberg, 2006. (Lecture Notes in Computer Science, v. 4199/2006), p. 692706. ARANGO, G. Domain analysis - from art form to engineering discipline. In: International Workshop on Software Specications & Design. Pittsburgh, Pennsylvania, United States: [s.n.], 1999. p. 152159. ARBOLEDA, H.; CASALLAS, R.; ROYER, J.-C. Dealing with constraints during a feature conguration process in a model-driven software product line. In: SPRINKLE, J. et al. (Ed.). Proceedings of the 7th OOPSLA Workshop on Domain-Specic Modeling (DSM07) - Montral, Canada. [S.l.]: University of Jyvskyl, Finland 2007, ISBN 978-951-39-2915-2., 2007. (Computer Science and Information System Reports, Technical Reports, TR-38), p. 178183. BAHNOT, V. et al. Using domain-specic modeling to develop software dened radio components and applications. In: The 5th OOPSLA Workshop on Domain-Specic Modeling, San Diego USA. [S.l.: s.n.], 2005. p. 3342. BARTHOLDT, J.; OBERHAUSER, R.; RYTINA, A. An approach to addressing entity model variability within software product lines. In: ICSEA. [S.l.]: IEEE Computer Society, 2008. p. 465471. Disponvel em: <http://dx.doi.org/10.1109/ICSEA.2008.30>. Acesso em: 14 jun 2009. BASILI, V.; ABD-EL-HAFIZ, S. K. A method for documenting code components. Journal of Systems and Software (JSS), v. 34, n. 2, p. 89104, 1996. BASILI, V. R.; BRIAND, L.; MELO, W. How reuse inuences productivity in object-oriented systems. Communications of the ACM, v. 39, n. 10, p. 104116, 1996. BASILI, V. R.; CALDIERA, G.; ROMBACH, H. D. The goal question metric approach. In: Encyclopedia of Software Engineering, Vol. II. [S.l.: s.n.], 1994. v. 2, p. 528532. BASS, L.; CLEMENTS, P.; KAZMAN, R. Software Architecture in Practice, 2nd Edition. [S.l.]: Addison-Wesley, 2003. BAUER, D. A reusable parts center. IBM Systems Journal, v. 32, n. 04, p. 620624, 1993. BAYER, J. et al. PuLSE: A methodology to develop software product lines. In: Symposium on Software Reusability (SSR). Los Angeles, USA: ACM Press, 1999. p. 122131. BAYER, J.; MUTHIG, D.; WIDEN, T. Customizable domain analysis. In: First International Symposium on Generative and Component-Based Software Engineering (GPCE). Germany: [s.n.], 1999. p. 178194. BIERHOFF, K.; LIONGOSARI, E. S.; SWAMINATHAN, K. S. Incremental development of a domain-specic language that supports multiple application styles. In: GRAY, J.; TOLVANEN, J.-P.; SPRINKLE, J. (Ed.). 6th OOPSLA Workshop on Domain-Specic Modeling (DSM06), Portland, Oregon USA. [S.l.]: Jyvskyl University Printing House, Jyvskyl , Finland, ISBN: 951-39-2631-1, ISSN: 1239-291X, 2006. p. 6778.

237

BIGGERSTAFF, T. J.; RICHTER, C. Reusability framework, assessment, and directions. In: BIGGERSTAFF, T. J.; PERLIS, A. J. (Ed.). Frontier Series: Software Reusability: Volume I Concepts and Models. New York: ACM Press, 1989. p. 117. BLOIS, A. P. T. B. Uma Abordagem de Projeto Arquitetural Baseado em Componentes no Contexto de Engenharia de Domnio. Tese (Tese de Doutorado) Universidade Federal do Rio de Janeiro, 2006. BOEHM, B. A spiral model of software development and enhancement. IEEE Computer, v. 21, n. 5, p. 6172, May 1988. BOSCH, J. Design and Use of Software Architectures. [S.l.]: Addison Wesley, 2000. BOTTERWECK, G.; OBRIEN, L.; THIEL, S. Model-driven derivation of product architectures. In: STIREWALT, R. E. K.; EGYED, A.; FISCHER, B. (Ed.). Proceedings of the twenty-second IEEE/ACM international conference on Automated software engineering. [S.l.]: ACM, 2007. p. 469472. ISBN 978-1-59593-882-4. Disponvel em: <http://doi.acm.org/10.1145/1321631.1321711>. Acesso em 14 jun 2009. BRAGA, R. T. V. Um Processo para Construo e Instanciao de Frameworks baseados em uma Linguagem de Padres para um Domnio Especco. Tese (Doutorado) USP Universidade de So Paulo, So Carlos - SP, 2002. BUSCHMANN, F.; HENNEY, K.; SCHMIDT, D. C. Pattern-Oriented Software Architecture, Volume 4: A Pattern Language for Distributed Computing. [S.l.]: John Wiley & Sons, 2007. BUSCHMANN, F.; HENNEY, K.; SCHMIDT, D. C. Pattern-Oriented Software Architecture, Volume 5: On Patterns and Pattern Languages. [S.l.]: John Wiley & Sons, 2007. BUSCHMANN, F. et al. Pattern-Oriented Software Architecture, Volume 1: A System of Patterns. [S.l.]: John Wiley & Sons, 1996. CHIDAMBER, S. R.; KEMERER, C. F. A metrics suite for object oriented design. IEEE Trans. Softw. Eng., IEEE Press, Piscataway, NJ, USA, v. 20, n. 6, p. 476493, 1994. ISSN 0098-5589. CLEAVELAND, J. C. Building application generators. IEEE Software, v. 7, n. 1, p. 2533, 1988. CLEAVELAND, J. C. Separating concerns of modeling from artifact generation using XML. In: Proceedings of the 1st OOPSLA Workshop on Domain-Specic Visual Languages - Tampa Bay, USA. [S.l.]: Jyvskyl University Printing House, Jyvskyl , Finland, ISBN: 951-39-1056-3, ISSN: 0359-8470, 2001. p. 8386. CLEENEWERCK, T.; KURTEV, I. Separation of concerns in translational semantics for DSLs in model engineering. In: CHO, Y. et al. (Ed.). 22nd Annual ACM Symposium on Applied Computing (SAC 2007). [S.l.]: ACM, 2007. p. 985992. ISBN 1-59593-480-4. CLEMENTS, P.; KAZMAN, R.; KLEIN, M. Evaluating Software Architectures: Methods and Case Studies. [S.l.]: Addison-Wesley, 2004. CLEMENTS, P.; NORTHROP, L. Software Product Lines: Practices and Patterns. [S.l.]: Addison-Wesley, 2002.

238

COOK, S. et al. Domain-Specic Development with Visual Studio DSL Tools. [S.l.]: Addison-Wesley Professional, 2007. COPLIEN, J.; HOFFMAN, D.; WEISS, D. Commonality and variability in software engineering. IEEE Software, v. 15, n. 6, p. 3745, 1998. COPLIEN, J. O. Multi-Paradigm Design. Tese (Doutorado) Vrije Universiteit Brussel, 2000. COPLIEN, J. O. A Pattern Denition (http://hillside.net/patterns/denition.html). [S.l.]: hillside.net, 2006. CURRY, W. et al. Empirical analysis of the correlation between amount-of-reuse metrics in the c programming language. In: SSR 99: Proceedings of the 1999 symposium on Software reusability. New York, NY, USA: ACM, 1999. p. 135140. ISBN 1-58113-101-1. CZARNECKI, K. Overview of generative software development. In: BANTRE, J.-P. et al. (Ed.). Unconventional Programming Paradigms, International Workshop UPP 2004, Le Mont Saint Michel, France, September 15-17, 2004, Revised Selected and Invited Papers. [S.l.]: Springer, 2005. (Lecture Notes in Computer Science, v. 3566), p. 326341. ISBN 3-540-27884-2. CZARNECKI, K. et al. Model-driven software product lines. In: 20th Annual ACM SIGPLAN Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA 2005). San Diego, CA, USA: ACM, 2005. p. 126127. CZARNECKI, K. et al. Generative programming for embedded software: An industrial experience report. In: BATORY, D.; CONSEL, C.; TAHA, W. (Ed.). Generative Programming and Component Engineering. [S.l.]: Springer Berlin / Heidelberg, 2002. (Lecture Notes in Computer Science, v. 2487), p. 156172. CZARNECKI, K.; EISENECKER, U. W. Generative Programming: Methods, Tools, and Applications. [S.l.]: Addison-Wesley, 2000. CZARNECKI, K.; HELSEN, S. Feature-based survey of model transformation approaches. IBM Systems Journal, v. 45, n. 3, p. 621645, 2006. ISSN 0018-8670. Disponvel em: <http://www.research.ibm.com/journal/sj/453/czarnecki.html>. Acesso em: 14 jun 2009. CZARNECKI, K.; HELSEN, S.; EISENECKER, U. Formalizing Cardinality-based Feature Models and their Staged Conguration. [S.l.], 2004. Disponvel em: <http://www.ece.uwaterloo.ca/ kczarnec/TR04-11.pdf>. CZARNECKI, K.; HELSEN, S.; EISENECKER, U. Staged conguration using feature models. In: NORD, R. L. (Ed.). Proceedings of the Third Software Product Line Conference. Boston, MA: Springer, 2004. (LNCS 3154), p. 266283. DAVIS, T. The reuse capability model: A basis for improving an organizations reuse capability. In: Proceedings of 2nd ACM/IEEE International Workshop on Software Reusability. [S.l.]: IEEE Computer Society Press / ACM Press, 1993. p. 126133. DEBAUD, J.; SCHMID, K. A systematic approach to derive the scope of software product lines. In: 21st International Conference on Software Engineering (ICSE 99). Los Angeles, CA, USA: [s.n.], 1999. p. 3443.

239

DEBAUD, J.-M.; FLEGE, O.; KNAUBER, P. PuLSE-DSSA: A method for the development of software reference architectures. In: ISAW 98: Proceedings of the third international workshop on Software architecture. New York, NY, USA: ACM, 1998. p. 2528. ISBN 1-58113-081-3. DEELSTRA, M. et al. Model driven architecture as approach to manage variability in software product families. In: Workshop on Model Driven Architecture: Foundations and Applications (MDAFA 2003). Enschede, The Netherlands: [s.n.], 2003. p. 109114. DESOUZA, K. C.; AWAZU, Y.; TIWANA, A. Four dynamics for bringing use back into software reuse. Communications of the ACM, v. 49, n. 01, p. 97100, 2006. DEURSEN, A. v.; KLINT, P.; VISSER, J. Domain-specic languages: An annotated bibliography. SIGPLAN Notices - ACM Press, v. 35, n. 6, p. 2636, 2000. DEURSEN, A. van; KLINT, P. Little languages: little maintenance. Journal of Software Maintenance, John Wiley & Sons, Inc., New York, NY, USA, v. 10, n. 2, p. 7592, 1998. ISSN 1040-550X. DEVANBU, P. et al. Analytical and empirical evaluation of software reuse metrics. In: ICSE 96: Proceedings of the 18th international conference on Software engineering. Washington, DC, USA: IEEE Computer Society, 1996. p. 189199. ISBN 0-8186-7246-3. DOE, D. D.; BERSOFF, E. H. The software productivity consortium (SPC): An industry initiative to improve the productivity and quality of mission-critical software. Journal of Systems and Software, v. 6, n. 4, p. 367378, 1986. Elsevier Science Inc., New York, NY, USA. DSOUZA, D.; WILLS, A. Objects, Components and Frameworks with UML: The Catalysis Approach. [S.l.]: Addison-Wesley, 1999. (Object Technology Series). ECKLUND JR, E. F.; DELCAMBRE, L. M. L.; FREILING, M. J. Change cases: Use cases that identify future requirements. In: Conference Proceedings of the OOPSLA 96, San Jose, CA, USA. [S.l.]: ACM Press, 1996. p. 342358. ECLIPSE. The Eclipse Modeling Framework (EMF) Overview. [S.l.]: Eclipse website, 2005. ECLIPSE. Eclipse Modeling Framework FAQ. 2006. ENDRES, A. Lessons learned in an industrial software lab. IEEE Software, v. 10, n. 05, p. 5861, 1993. ESSER, R.; JANNECK, J. W. A framework for dening domain-specic visual languages. In: Proceedings of the 1st OOPSLA Workshop on Domain-Specic Visual Languages - Tampa Bay, USA. [S.l.]: Jyvskyl University Printing House, Jyvskyl , Finland, ISBN: 951-39-1056-3, ISSN: 0359-8470, 2001. p. 111124. EZRAN, M.; MORISIO, M.; TULLY, C. Practical Software Reuse. [S.l.]: Springer, 2002. FEILKAS, M. How to represent models, languages and transformations? In: GRAY, J.; TOLVANEN, J.-P.; SPRINKLE, J. (Ed.). 6th OOPSLA Workshop on Domain-Specic Modeling (DSM06), Portland, Oregon USA. [S.l.]: Jyvskyl University Printing House, Jyvskyl , Finland, ISBN: 951-39-2631-1, ISSN: 1239-291X, 2006. p. 169176.

240

FENTON, N.; PFLEEGER, S. L. Software Metrics: A Rigorous and Practical Approach. 2nd. ed. [S.l.]: Course Technology, 1998. FLORIJN, G.; MEIJERS, M.; WINSEN, P. v. Tool support for object-oriented patterns. In: European Conference on Object-Oriented Programming (ECOOP97). Jyvskyl, Finland: Springer-Verlag, 1997. p. 472495. FOWLER, M. Inversion of Control Containers and the Dependency Injection pattern. 2004. Disponvel em: <http://martinfowler.com/articles/injection.html>. Acesso em: 14 jun 2009. FOWLER, M. Language Workbenches: The Killer-App for Domain Specic Languages? [S.l.]: martinfowler.com, 2005. Disponvel em: <http://www.martinfowler.com/articles/languageWorkbench.html>. Acesso em: 14 jun 2009. FOWLER, M. et al. Refactoring: Improving the Design of Existing Code. [S.l.]: Addison Wesley, 1999. FRAKES, W. B.; ISODA, S. Success factors of systematic software reuse. IEEE Software, v. 11, n. 01, p. 1419, 1994. FRAKES, W. B.; PRIETO-DAZ, R.; FOX, C. DARE: Domain Analysis and Reuse Environment. Annals of Software Engineering, v. 05, p. 125141, 1998. FRAKES, W. B.; TERRY, C. Reuse level metrics. In: Proceedings of the 3rd IEEE International Conference on Software Reuse (ICSR): Advances in Software Reusability, Rio de Janeiro, Brazil. [S.l.: s.n.], 1994. p. 139148. FRANCE, R.; RUMPE, B. Model-driven development of complex software: A research roadmap. In: 29th International Conference on Software Engineering 2007 - Future of Software Engineering. Minneapolis, MN, USA: IEEE Computer Society, 2007. p. 3754. GAMMA, E. et al. Design Patterns: Elements of Reusable Object-Oriented Software. Reading, MA: Addison-Wesley, 1995. GARCIA, V. C. et al. Towards an assessment method for software reuse capability. In: 8th International Conference on Quality Software (QSIC), Oxford, UK. [S.l.: s.n.], 2008. p. 294299. GARCIA, V. C. et al. Towards a maturity model for a reuse incremental adoption. In: Brazilian Symposium on Software Components, Architectures and Reuse (SBCARS 2007). Campinas, SP, Brazil: [s.n.], 2007. p. 6174. GENERO, M. et al. Building measure-based prediction models for uml class diagram maintainability. Empirical Softw. Engg., Kluwer Academic Publishers, Hingham, MA, USA, v. 12, n. 5, p. 517549, 2007. ISSN 1382-3256. GENERO, M.; POELS, G.; PIATTINI, M. Dening and validating metrics for assessing the understandability of entity-relationship diagrams. Data Knowl. Eng., Elsevier Science Publishers B. V., Amsterdam, The Netherlands, The Netherlands, v. 64, n. 3, p. 534557, 2008. ISSN 0169-023X.

241

GREENFIELD, J. et al. Software Factories: Assembling Applications with Patterns, Models, Frameworks and Tools. [S.l.]: Wiley, 2004. GRISS, M. Software reuse experience at Hewlett-Packard. In: 16th International Conference on Software Engineering (ICSE). Sorrento, Italy: IEEE/CS Press, 1994. p. 270. GRISS, M. Making software reuse work at hewlett-packard. IEEE Software, v. 12, n. 01, p. 105107, 1995. GRISS, M.; FAVARO, J.; DALESSANDRO, M. Integrating feature modeling with the RSEB. In: The Fifty International Conference on Software Reuse (ICSR). Victoria, Canada: IEEE/CS Press, 1998. p. 7685. GUERRA, E.; LARA, J. de; DAZ, P. Visual specication of measurements and redesigns for domain specic visual languages. J. Vis. Lang. Comput., Academic Press, Inc., Orlando, FL, USA, v. 19, n. 3, p. 399425, 2008. ISSN 1045-926X. GUIZZARDI, G.; PIRES, L. F.; SINDEREN, M. J. V. On the role of domain ontologies in the design of domain-specic visual modeling languages. In: In: Proceedings of the 2nd Workshop on Domain-Specic Visual Languages, 17th ACM Conference on Object Oriented Programming, Systems, Languages and Applications (OOPSLA 2002). [S.l.: s.n.], 2002. HADDAD, H.; TESSER, H. Reusable subsystems: Domain-based approach. In: 2002 ACM Symposium on Applied Computing (SAC2002). Madrid, Spain: ACM, 2002. p. 971975. HEINEMAN, G.; COUNCILL, W. Component-Based Software Engineering: Putting the Pieces Together. USA: Addison-Wesley, 2001. HENRIKSSON, A.; LARSSON, H. A Denition of Round-Trip Engineering. [S.l.], 2003. Department of Computer and Information Science, Linkpings Universitet, SE-581 83, Linkping, Sweden. HESSELLUND, A.; CZARNECKI, K.; WASOWSKI, A. Guided development with multiple domain-specic languages. In: ENGELS, G. et al. (Ed.). Model Driven Engineering Languages and Systems (MoDELS 2007). [S.l.]: Springer, 2007. (Lecture Notes in Computer Science, v. 4735), p. 4660. ISBN 978-3-540-75208-0. HETTEL, T.; LAWLEY, M. J.; RAYMOND, K. Model synchronisation: Denitions for round-trip engineering. In: VALLECILLO, A.; GRAY, J.; PIERANTONIO, A. (Ed.). Theory and Practice of Model Transformations (ICMT 2008). [S.l.]: Springer Berlin / Heidelberg, 2008. (Lecture Notes in Computer Science, v. 5063/2008), p. 3145. HOLIBAUGH, R. et al. Reuse: where to begin and why. In: TRI-Ada 89: Proceedings of the conference on Tri-Ada 89. Pittsburgh, Pennsylvania, United States: ACM Press, 1989. p. 266 277. ISAKOWITZ, T.; KAUFFMAN, R. J. Supporting search for reusable software objects. IEEE Transactions on Software Engineering, v. 22, n. 6, p. 407423, 1996. JACKSON, E. K.; SCHULTE, W. Compositional modeling for data-centric business applications. In: PAUTASSO, C.; TANTER ric (Ed.). Software Composition. [S.l.]: Springer, 2008. (Lecture Notes in Computer Science, v. 4954), p. 190205. ISBN 978-3-540-78788-4.

242

JACOBSON, I.; GRISS, M.; JONSSON, P. Reuse-driven Software Engineering Business (RSEB). [S.l.]: Addison-Wesley, 1997. JACOBSON, I.; LINDSTROM, F. Re-engineering of old systems to an object-oriented architecture. In: OOPSLA 91: Conference proceedings on Object-oriented programming systems, languages, and applications. Phoenix, Arizona, United States: ACM Press, 1991. p. 340350. JARZABEK, S. Modeling multiple domains in software reuse. In: The 1997 Symposium on Software Reusability. Boston, Massachusetts, United States: ACM, 1997. p. 6574. JEZEQUEL, J. M.; MEYER, B. Design by contract: The lessons of Ariane. IEEE Computer, v. 30, n. 01, p. 129130, 1997. JOHNSON, R.; FOOTE, B. Designing reusable classes. Journal of Object Oriented Programming, v. 1, n. 2, p. 2235, 1988. JOHNSON, R. E. Components, frameworks, patterns. In: SSR 97: Proceedings of the 1997 symposium on Software reusability. Boston, Massachusetts, United States: ACM Press, 1997. p. 1017. JOHNSON, R. E. Frameworks = (components + patterns). Communications of the ACM, v. 40, n. 10, p. 3942, 1997. JOOS, R. Software reuse at Motorola. IEEE Software, v. 11, n. 05, p. 4247, 1994. JOUAULT, F.; BZIVIN, J.; KURTEV, I. TCS: a DSL for the specication of textual concrete syntaxes in model engineering. In: JARZABEK, S.; SCHMIDT, D. C.; VELDHUIZEN, T. L. (Ed.). Fifth International Conference on Generative Programming and Component Engineering (GPCE06). [S.l.]: ACM, 2006. p. 249254. ISBN 1-59593-237-2. Disponvel em: <http://doi.acm.org/10.1145/1173706.1173744>. Acesso em: 14 jun 2009. JOUAULT, F.; KURTEV, I. On the architectural alignment of ATL and QVT. In: ACM Symposium on Applied Computing (SAC 06), model transformation track. Dijon, Bourgogne, France: [s.n.], 2006. p. 11881195. KANG, K. et al. Feature-Oriented Domain Analysis (FODA) Feasibility Study. [S.l.], 1990. Technical Report CMU/SEI-90-TR-21 - Carnegie Mellon University/Software Engineering Institute. KANG, K. et al. FORM: A Feature-Oriented Reuse Method with domain-specic reference architectures. Annals of Software Engineering Notes, v. 05, p. 143168, 1998. KANG, K.; LEE, J.; DONOHOE, P. Feature-oriented product line engineering. IEEE Software, v. 19, n. 04, p. 5865, 2002. KEEPENCE, B.; MANNION, M. Using patterns to model variability in product families. IEEE Software, v. 16, n. 4, p. 102108, 1999. KETTEMANN, S.; MUTHIG, D.; ANASTASOPOLOUS, M. Product Line Implementation Technologies - Component Technology View. [S.l.], March 2003. Fraunhofer IESE Tech Report 015.03/E.

243

KICZALES, G. et al. Aspect-oriented programming. In: 11st European Conference Object-Oriented Programming (ECOOP97). Finland: Springer Verlag, 1997. (LNCS, v. 1241), p. 220242. KIM, M.; YANG, H.; PARK, S. A domain analysis method for software product lines based on scenarios, goals and features. In: Tenth Asia-Pacic Software Engineering Conference (APSEC). Thailand: [s.n.], 2003. p. 126136. KIRCHER, M.; JAIN, P. Pattern-Oriented Software Architecture, Volume 3: Patterns for Resource Management. [S.l.]: John Wiley & Sons, 2003. KLEPPE, A.; WARMER, J.; BAST, W. MDA Explained - The Model Driven Architecture: Practice and Promise. [S.l.]: Addison-Wesley, 2003. (Object Technology Series). KLEPPE, A. G. A language description is more than a metamodel. In: Fourth International Workshop on Software Language Engineering, Nashville, USA. [S.l.: s.n.], 2007. ISBN not assigned. KNODEL, J. et al. An efcient migration to model-driven development (MDD). Electronic Notes in Theoretical Computer Science, v. 137, n. 3, p. 1727, 2005. KOLTUN, P.; HUDSON, A. A reuse maturity model. In: 4th Annual Workshop on Software Reuse. Hemdon, Virginia: Center for Innovative Technology: [s.n.], 1991. KOTULA, J. Using patterns to create component documentation. IEEE Software, v. 15, n. 2, p. 8492, 1998. KRUCHTEN, P. The 4+1 view model of architecture. IEEE Softw., IEEE Computer Society Press, Los Alamitos, CA, USA, v. 12, n. 6, p. 4250, 1995. ISSN 0740-7459. KRUEGER, C. Software reuse. ACM Computing Surveys, v. 24, n. 02, p. 131183, 1992. KURTEV, I. et al. Model-based DSL frameworks. In: TARR, P. L.; COOK, W. R. (Ed.). OOPSLA Companion. [S.l.]: ACM, 2006. p. 602616. ISBN 1-59593-491-X. Disponvel em: <http://doi.acm.org/10.1145/1176617.1176632>. Acesso em: 14 jun 2009. LANGE, C.; CHAUDRON, M. An empirical assessment of completeness in uml designs. In: Proceedings of the 8th Conference on Empirical Assessment in Software Engineering (EASE04). [S.l.: s.n.], 2004. p. 111121. LANGE, C. F. J.; CHAUDRON, M. R. V. Managing model quality in UML-based software development. In: STEP 05: Proceedings of the 13th IEEE International Workshop on Software Technology and Engineering Practice. Washington, DC, USA: IEEE Computer Society, 2005. p. 716. ISBN 0-7695-2639-X. LEDECZI, A. et al. Composing domain-specic design environments. IEEE Computer, v. 34, n. 11, p. 4451, 2001. LEE, J.; KANG, K. C. Feature binding analysis for product line component development. In: LINDEN, F. van der (Ed.). Software Product-Family Engineering, 5th International Workshop, PFE 2003, Siena, Italy, November 4-6, 2003, Revised Papers. [S.l.]: Springer, 2003. (Lecture Notes in Computer Science, v. 3014), p. 250260. ISBN 3-540-21941-2.

244

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

MASCENA, J. C. C. P.; ALMEIDA, E. S. d.; MEIRA, S. R. d. L. A comparative study on software reuse metrics and economic models from a traceability perspective. In: IEEE International Conference on Information Reuse and Integration (IRI). Las Vegas, Nevada, USA: IEEE/CS Press, 2005. p. 7277.

245

MATOS JR, P. O. A. Analysis of techniques for implementing software product lines variabilities. Dissertao (M.Sc. Dissertation) Universidade Federal de Pernambuco - Centro de Informtica, Recife, PE, Brazil, August 2008. MCCABE, T. J. A complexity measure. IEEE Transactions on Software Engineering, v. 2, n. 4, p. 308320, 1976. MCILROY, M. D. Mass produced software components. In: NATO Software Engineering Conference. [S.l.: s.n.], 1968. p. 138155. MEI, H.; ZHANG, W.; GU, F. A feature oriented approach to modeling and reusing requirements of software product lines. In: 27th IEEE International Computer Software and Applications Conference (COMPSAC). USA: [s.n.], 2003. p. 250256. MELLOR, S. J.; CLARK, A. N.; FUTAGAMI, T. Model-driven development. IEEE Software, v. 20, n. 5, p. 1418, 2003. MERNIK, M.; HEERING, J.; SLOANE, A. M. When and how to develop domain-specic languages. ACM Computing Surveys, v. 37, n. 4, p. 316344, dez. 2005. ISSN 0360-0300. MILI, H. et al. Reuse-Based Software Engineering: Techniques, Organization, and Controls. [S.l.]: John Wiley & Sons, 2002. MILI, H.; MILI, F.; MILI, A. Reusing software: Issues and research directions. IEEE Transactions on Software Engineering, v. 21, n. 6, p. 528562, 1995. MODELWARE. Architecture and Platform Modelling Proles. [S.l.], 2006. MODELWARE. Denition of Reusable Transformations. [S.l.], 2006. Disponvel em: <http://www.modelware-ist.org/)>. Acesso em: 14 jun 2009. MODELWARE. Engineering Metrics Denition. [S.l.], <http://www.modelware-ist.org/)>. Acesso em: 14 jun 2009. MODELWARE. MDD Maturity Model. [S.l.], <http://www.modelware-ist.org/)>. Acesso em: 14 jun 2009. MODELWARE. MDD Process Framework. [S.l.], <http://www.modelware-ist.org/)>. Acesso em: 14 jun 2009. 2006. 2006. 2006. Disponvel Disponvel Disponvel em: em: em:

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

MOHAGHEGHI, P.; AAGEDAL, J. Evaluating quality in model-driven engineering. In: MISE 07: Proceedings of the International Workshop on Modeling in Software Engineering. Washington, DC, USA: IEEE Computer Society, 2007. p. 6. ISBN 0-7695-2953-4.

246

MOHAGHEGHI, P.; DEHLEN, V. Where is the proof? - a review of experiences from applying MDE in industry. In: ECMDA-FA 08: Proceedings of the 4th European conference on Model Driven Architecture. Berlin, Heidelberg: Springer-Verlag, 2008. p. 432443. ISBN 978-3-540-69095-5. MONPERRUS, M. et al. A model-driven measurement approach. In: MoDELS 08: Proceedings of the 11th international conference on Model Driven Engineering Languages and Systems. Berlin, Heidelberg: Springer-Verlag, 2008. p. 505519. ISBN 978-3-540-87874-2. MOON, M.; YEOM, K. An approach to developing domain requirements as a core asset based on commonality and variability analysis in a product line. IEEE Transactions on Software Engineering, v. 31, n. 07, p. 551569, 2005. MOON, M.; YEOM, K. An approach to developing domain architectures based on variability analysis. In: Computational Science and Its Applications - ICCSA 2006. [S.l.]: Springer Berlin / Heidelberg, 2006. (Lecture Notes in Computer Science, v. 3981/2006), p. 441450. MOORE, B. et al. Eclipse Development using the Graphical Editing Framework and the Eclipse Modeling Framework. [S.l.]: ibm.com/redbooks, 2004. MORILLO, J. L. et al. Incremental software reuse. In: MORISIO, M. (Ed.). Reuse of Off-the-Shelf Components, 9th International Conference on Software Reuse. Turin, Italy: Springer, 2006. (Lecture Notes in Computer Science, v. 4039), p. 386389. MORISIO, M.; EZRAN, M.; TULLY, C. Success and failure factors in software reuse. IEEE Transactions on Software Engineering, v. 28, n. 04, p. 340357, 2002. MUSKENS, J.; CHAUDRON, M.; LANGE, C. Investigations in applying metrics to multi-view architecture models. In: EUROMICRO 04: Proceedings of the 30th EUROMICRO Conference. Washington, DC, USA: IEEE Computer Society, 2004. p. 372379. ISBN 0-7695-2199-1. MUSZYNSKI, M. Implementing a domain-specic modeling environment for a family of thick-client gui components. In: The 5th OOPSLA Workshop on Domain-Specic Modeling, San Diego USA. [S.l.: s.n.], 2005. p. 514. MUTHIG, D. et al. Technology Dimensions of Product Line Implementation Approaches State-of-the-art and State-of-the-practice Survey. [S.l.], September 2002. Tech Report 051.02/E - Fraunhofer IESE. MUTHIG, D.; PATZKE, T. Generic implementation of product line components. In: Objects, Components, Architectures, Services and Applications for a Networked World. International Conference NetObjectDays, NODe 2002, Erfurt, Germany, October 7-10, 2002. [S.l.]: Springer-Verlag, 2003. (Lecture Notes in Computer Science, v. 2591), p. 313329. MUTHIG, D.; PATZKE, T. Implementing software product lines - enhancing reusability by systematically selecting and applying variability mechanisms. In: Multikonferenz Wirtschaftsinformatik (MKWI) 2004. Band 1 : E-Learning: Modelle, Instrumente und Erfahrungen. Software-Produktlinien. Communities in E-Business. Berlin: Akademische Verlagsgesellschaft, 2004. NAUR, P.; RANDELL, B. Report on NATO Software Engineering Conference. [S.l.], 1968.

247

NEIGHBORS, J. M. Software Construction Using Components. Tese (Ph.D. Thesis) University of California at Irvine, 1980. NEIGHBORS, J. M. Draco: A method for engineering reusable software systems. In: BIGGERSTAFF, T. J.; PERLIS, A. J. (Ed.). Software Reusability, Volume 1 : Concepts and Models. [S.l.]: Addison-Wesley, 1989. p. 295319. OMG. MDA Guide Version 1.0.1. [S.l.], 2003. Disponvel em: <http://www.omg.org>. Acesso em: 14 jun 2009. OMG. MOF 2.0 Query / Views / Transformations Final Adopted Specication. [S.l.], 2005. Disponvel em: <http://www.omg.org>. Acesso em: 14 jun 2009. OMG. Catalog of UML Proles Specications. 2006. Disponvel em: <http://www.omg.org>. Acesso em: 14 jun 2009. OMG. Meta Object Facility Core Specication Version 2.0. [S.l.], 2006. Disponvel em: <http://www.omg.org>. Acesso em: 14 jun 2009. OMG. XML Metadata Interchange (XMI) Specication. [S.l.], 2006. Disponvel em: <http://www.omg.org>. Acesso em: 14 jun 2009. OMG. Unied Modeling Language (OMG UML) Infrastructure. [S.l.], 2007. Disponvel em: <http://www.omg.org>. Acesso em: 14 jun 2009. PARNAS, D. L. On the design and development of program families. IEEE Transactions on Software Engineering, v. 2, n. 1, p. 19, mar. 1976. PATZKE, T.; MUTHIG, D. Product Line Implementation Technologies - Programming Language View. [S.l.], October 2002. Tech Report 057.02/E - Fraunhofer IESE. PREZ-MARTNEZ, J. E.; SIERRA-ALONSO, A. From analysis model to software architecture: A PIM2PIM mapping. In: RENSINK, A.; WARMER, J. (Ed.). ECMDA-FA. [S.l.]: Springer, 2006. (Lecture Notes in Computer Science, v. 4066), p. 2539. ISBN 3-540-35909-5. PETRE, M. Why looking isnt always seeing: readership skills and graphical programming. Commun. ACM, ACM, New York, NY, USA, v. 38, n. 6, p. 3344, 1995. ISSN 0001-0782. PHOHA, V. A standard for software documentation. IEEE Computer, v. 30, n. 10, p. 9798, 1997. PILGRIM, J. Measuring the level of abstraction and detail of models in the context of MDD. In: Models in Software Engineering: Workshops and Symposia at MoDELS 2007, Nashville, TN, USA, September 30 - October 5, 2007, revised selected papers. Berlin, Heidelberg: Springer-Verlag, 2008. p. 105114. ISBN 978-3-540-69069-6. POPMA, R. JET Tutorial Part 1 (Introduction to JET). May 2004. Eclipse Corner Article. Disponvel em: <http://www.eclipse.org/articles/Article-JET/jet_tutorial1.html>. Acesso em: 14 jun 2009. POULIN, J. Measuring software reusability. In: Proceedings of the 3rd IEEE International Conference on Software Reuse (ICSR): Advances in Software Reusability, Rio de Janeiro, Brazil. [S.l.: s.n.], 1994. p. 126138.

248

POULIN, J.; CARUSO, J.; HANCOCK, D. The business case for software reuse. IBM Systems Journal, v. 32, n. 4, p. 567594, 1993. POULIN, J. S.; CARUSO, J. M. A reuse metrics and return on investment model. In: PRIETO-DIAZ, R.; FRAKES, W. B. (Ed.). Proceedings of 2nd ACM/IEEE International Workshop on Software Reusability. [S.l.]: IEEE Computer Society Press / ACM Press, 1993. p. 152167. ISBN 0-8186-3130-9, 0-8186-3132-5, 0-8186-3131-7. PRESSMAN, R. S. Software Engineering: A Practitioners Approach. [S.l.]: McGraw-Hill, 2005. PRIETO-DAZ, R. Domain analysis: An introduction. ACM SIGSOFT Software Engineering Notes, v. 15, n. 2, p. 4754, 1990. PRIETO-DAZ, R. Making software reuse work: An implementation model. ACM SIGSOFT Software Engineering Notes, v. 16, n. 3, p. 6168, 1991. PRIETO-DAZ, R. Status report: Software reusability. IEEE Software, v. 10, n. 3, p. 6166, 1993. IEEE Computer Society Press. Los Alamitos, CA, USA. PYSTER, A. B.; BARNES, B. H. The software productivity consortium reuse program. In: COMPCON88, Digest of Papers, Thirty-Third IEEE Computer Society International Conference. San Francisco, California, USA: IEEE Computer Society, 1988. p. 242249. RABISER, R.; GRNBACHER, P.; DHUNGANA, D. Supporting product derivation by adapting and augmenting variability models. In: SPLC. [S.l.]: IEEE Computer Society, 2007. p. 141150. Disponvel em: <http://doi.ieeecomputersociety.org/10.1109/SPLINE.2007.22>. Acesso em: 14 jun 2009. RIBEIRO, M. de M.; MATOS, J. P.; BORBA, P. A decision model for implementing product lines variabilities. In: SAC 08: Proceedings of the 2008 ACM symposium on Applied computing. New York, NY, USA: ACM, 2008. p. 276277. ISBN 978-1-59593-753-7. RINE, D. Success factors for software reuse that are applicable across domains and businesses. In: ACM Symposium on Applied Computing. San Jose, California, USA: ACM Press, 1997. p. 182186. RINE, D.; SONNEMANN, R. Investment in reusable software. a study on software reuse investment success factors. The Journal of Systems and Software, v. 41, p. 1732, 1998. RINE, D. C.; NADA, N. An empirical study of a software reuse reference model. Information and Software Technology, v. 42, n. 1, p. 4765, 2000. ROBBES, R.; LANZA, M. Example-based program transformation. In: CZARNECKI, K. et al. (Ed.). MoDELS. [S.l.]: Springer, 2008. (Lecture Notes in Computer Science, v. 5301), p. 174188. ISBN 978-3-540-87874-2. ROMBACH, D. Fraunhofer: The german model for applied research and technology transfer. In: 22nd International Conference on Software Engineering (ICSE). Limerick, Ireland: ACM Press, 2000. p. 2534. ROTHENBERGER, M. A. et al. Strategies for software reuse: A principal component analysis of reuse practices. IEEE Transactions on Software Engineering, v. 29, n. 09, p. 825837, 2003.

249

SAMETINGER, J. Software Engineering with Reusable Components. Berlin Heidelberg: Springer-Verlag, 1997. SANTOS, A. L.; KOSKIMIES, K.; LOPES, A. Automated domain-specic modeling languages for generating framework-based applications. In: SPLC. [S.l.]: IEEE Computer Society, 2008. p. 149158. ISBN 978-0-7695-3303-2. Disponvel em: <http://dx.doi.org/10.1109/SPLC.2008.17>. Acesso em 14 jun 2009. SCHMIDT, D. C. Guest editors introduction: Model-driven engineering. IEEE Computer, v. 39, n. 2, p. 2531, 2006. SCHMIDT, D. C. et al. Pattern-Oriented Software Architecture, Volume 2: Patterns for Concurrent and Networked Objects. [S.l.]: John Wiley & Sons, 2000. SEACORD, R.; PLAKOSH, D.; LEWIS, A. Modernizing Legacy Systems - Software Technologies, Engineering Processes, and Business Practices. [S.l.]: Addison-Wesley, 2003. SHERIF, K.; APPAN, R.; LIN, Z. Resources and incentives for the adoption of systematic software reuse. International Journal of Information Management, v. 26, n. 1, p. 7080, 2006. Available online 10 October 2005. SILVA, M. F.; WERNER, C. M. L. Packaging reusable components using patterns and hypermedia. In: 4th International Conference on Software Reuse. USA: [s.n.], 1996. p. 146155. SIMOS, M. et al. Organization Domain Modeling (ODM) Guidebook Version 2.0. [S.l.], 1996. STARS Technical Report STARS-VC-A025/001/00, Lockheed Martin Tactical Defense Systems, Manassas VA. SOMMERVILLE, I. Software Engineering. 8. ed. [S.l.]: Addison Wesley, 2006. STARS. Software Technology for Adaptable Reliable Systems (STARS). The Reuse-Oriented Software Evolution (ROSE). [S.l.], 1993. Unisys STARS Technical Report,Advanced Research Projects Agency (ARPA) STARS Technology Center, 801 N. Randolph St. Suite 400, Arlington VA 22203. STEFFEN, B. et al. Model-Driven Development with the jABC. In: Hardware and Software, Verication and Testing. Berlin / Heidelberg: Springer-Verlag, 2007. (Lecture Notes in Computer Science, v. 4383/2007), p. 92108. SVAHNBERG, M.; GURP, J. van; BOSCH, J. A taxonomy of variability realization techniques: Research articles. Softw. Pract. Exper., John Wiley & Sons, Inc., New York, NY, USA, v. 35, n. 8, p. 705754, 2005. ISSN 0038-0644. SVANHBERG, M.; GURP, J. van; BOSCH, J. A Taxonomy of Variability Realization Techniques. [S.l.], 2002. Technical paper ISSN:1103-1581, Blekinge Institute of Technology, Sweden, 2002. SZYPERSKI, C. Component Software: Beyond Object-Oriented Programming. [S.l.]: Addison Wesley, 1999. SZYPERSKI, C.; GRUNTZ, D.; MURER, S. Component Software: Beyond Object-Oriented Programming - Second Edition. [S.l.]: Addison Wesley / ACM Press, 2002.

250

TAULAVUORI, A.; NIEMELA, E.; KALLIO, P. Component documentation-a key issue in software product lines. Journal of Information and Software Technology, v. 46, n. 8, p. 535546, 2004. THOMAS, D. MDA: Revenge of the modelers or uml utopia? IEEE Software, v. 21, n. 3, p. 1517, 2004. TOLVANEN, J.-P. Making model-based code generation work. Embedded Systems Europe, v. 8, n. 60, p. 3638, Aug/Sept 2004. TOLVANEN, J.-P. Domain-Specic Modeling: How to Start Dening Your Own Language. Feb 2005. Disponvel em: <http://www.devx.com/enterprise/Article/30550>. Acesso em: 14 jun 2009. TOLVANEN, J.-P.; KELLY, S. Modelling languages for product families: A method engineering approach. In: Proceedings of the 1st OOPSLA Workshop on Domain-Specic Visual Languages - Tampa Bay, USA. [S.l.]: Jyvskyl University Printing House, Jyvskyl , Finland, ISBN: 951-39-1056-3, ISSN: 0359-8470, 2001. p. 135140. TOLVANEN, J.-P.; KELLY, S. Dening domain-specic modeling languages to automate product derivation: Collected experiences. In: OBBINK, J. H.; POHL, K. (Ed.). 9th International Software Product Line Conference (SPLC-Europe 2005). [S.l.]: Springer, 2005. (Lecture Notes in Computer Science, v. 3714), p. 198209. ISBN 3-540-28936-4. TRACZ, W. Domain-Specic Software Architecture (DSSA) pedagogical example. ACM SIGSOFT Software Engineering Notes, v. 20, n. 3, p. 4962, 1995. TRASK, B. et al. Using model-driven engineering to complement software product line engineering in developing software dened radio components and applications. In: SPLC. [S.l.]: IEEE Computer Society, 2006. p. 192202. ISBN 0-7695-2599-7. UHL, A. Model Driven Architecture is ready for prime time. IEEE Software, v. 20, n. 5, p. 7071, 2003. VANDOREN, E. Maintainability Index Technique for Measuring Program Maintainability. [S.l.]: Software Engineering Institute (SEI), 1997. Disponvel em: <http://www.sei.cmu.edu/str/>. Acesso em: 14 jun 2009. VARR, D. Model transformation by example. In: NIERSTRASZ, O. et al. (Ed.). MoDELS. [S.l.]: Springer, 2006. (Lecture Notes in Computer Science, v. 4199), p. 410424. ISBN 3-540-45772-0. VISSER, E. WebDSL: A case study in domain-specic language engineering. In: LMMEL, R.; VISSER, J.; SARAIVA, J. (Ed.). Generative and Transformational Techniques in Software Engineering (GTTSE 2007). [S.l.]: Springer, 2007. (Lecture Notes in Computer Science, v. 5235), p. 291373. ISBN 978-3-540-88642-6. VLTER, M. A catalog of patterns for program generation. In: Eight European Conference on Pattern Languages of Programs (EuroPLoP 2003), Irsee, Germany. [S.l.: s.n.], 2003. p. B61B634. VLTER, M. MD* Best Practices. December 2008. Disponvel em: <http://www.voelter.de>. Acesso em: 14 jun 2009.

251

VLTER, M.; BETTIN, J. Patterns for model-driven software development. In: Ninth European Conference on Pattern Languages of Programs (EuroPLoP 2004), Irsee, Germany. [S.l.: s.n.], 2004. p. D31D354. VLTER, M.; GROHER, I. Product line implementation using aspect-oriented and model-driven software development. In: SPLC. [S.l.]: IEEE Computer Society, 2007. p. 233242. Disponvel em: <http://doi.ieeecomputersociety.org/10.1109/SPLINE.2007.23>. Acesso em: 14 jun 2009. VOTH, D. Packaging reusable software assets. IEEE Software, v. 21, n. 3, p. 107110, 2004. W3C. XML Path Language (XPath) Version 1.0 - W3C Recommendation 16 November 1999. [S.l.], 1999. W3C. XSL Transformations (XSLT) Version 1.0 - W3C Recommendation 16 November 1999. [S.l.], 1999. WARMER, J.; KLEPPE, A. Building a exible software factory using partial domain specic models. In: Proc. of The 6th OOPSLA Workshop on Domain-Specic Modeling. [S.l.: s.n.], 2006. p. 1522. WEIS, T.; ULBRICH, A.; GEIHS, K. Model metamorphosis. IEEE Software, v. 20, n. 5, p. 4651, 2003. WEISS, D.; LAI, C. T. R. Software Product-Line Engineering: A Family-Based Software Development Process. [S.l.]: Addison Wesley, 1999. WEISS, D. M. et al. Decision-model-based code generation for SPLE. In: SPLC. [S.l.]: IEEE Computer Society, 2008. p. 129138. ISBN 978-0-7695-3303-2. Disponvel em: <http://dx.doi.org/10.1109/SPLC.2008.42>. Acesso em: 14 jun 2009. WILE, D. Lessons learned from real DSL experiments. Sci. Comput. Program., Elsevier North-Holland, Inc., Amsterdam, The Netherlands, The Netherlands, v. 51, n. 3, p. 265290, 2004. ISSN 0167-6423. WIMMER, M. et al. Towards model transformation generation by-example. In: 40th Hawaii International Conference on System Sciences (HICSS07). Hawaii: [s.n.], 2007. p. 285294. WOHLIN, C. et al. Experimentation in Software Engineering: An Introduction. [S.l.]: Kluwer Academic Publishers, 2000. ZAREMSKI, A. M.; WING, J. M. Signature matching: A tool for using software libraries. ACM Transactions on Software Engineering and Methodology, v. 4, n. 2, p. 146170, 1995.

253

APNDICE A -- Tcnicas para reutilizao de software

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

254

documentao do software, navegando, por exemplo, por meio da diviso em pacotes ou bibliotecas, em busca do artefato lembrado por sua memria; Adaptao: encontrado, o artefato copiado para seu novo local. A adaptao ocorre somente se necessrio, congurando-o por meio de parmetros ou de mecanismos de extenso ou mesmo modicando seu cdigo manualmente; e Integrao: a integrao normalmente consiste em modicar o artefato, o contexto, ou ambos, para que possam compor a funcionalidade desejada (KRUEGER, 1992). Essa abordagem, apesar de proporcionar ganhos de produtividade, apresenta alguns problemas, tais como: Uma vez que o artefato normalmente modicado, necessrio test-lo novamente para garantir que as modicaes no introduziram nenhum erro novo; Os processos de abstrao e seleo dependem muito do talento individual e da experincia do desenvolvedor, pois se baseiam muito na memria humana; e Caso o desenvolvedor no conhea o artefato sendo reutilizado, ele precisa gastar algum tempo compreendendo-o antes de copi-lo para o novo contexto. Desta forma, caso esse tempo seja muito grande, o que ocorre na maioria dos casos envolvendo cdigo-fonte que ele acaba optando por desenvolver um novo artefato a partir do zero (DESOUZA;
AWAZU; TIWANA,

2006).

Por esses e outros motivos, a pesquisa vem evoluindo na busca por novos mtodos e tcnicas que evitem tais tipos de problemas. A seguir, so apresentadas as principais abordagens voltadas para reutilizao de software existentes na literatura, destacando-se o desenvolvimento baseado em componentes (SAMETINGER, 1997; SZYPERSKI; GRUNTZ; MURER, 2002), linguagens especcas de domnio (DEURSEN; KLINT; VISSER, 2000), programao generativa (CZARNECKI;
EISENECKER,

2000), e outras tcnicas, tais como frameworks (JOHNSON, 1997b), padres

(BUSCHMANN et al., 1996) e reengenharia de software (JACOBSON; LINDSTROM, 1991). Desenvolvimento Baseado em Componentes Dentre as tcnicas utilizadas para se alcanar os benefcios da reutilizao, destaca-se o desenvolvimento baseado em componentes (DBC). At alguns anos atrs, o desenvolvimento da maioria dos produtos de software era baseado em blocos monolticos, formados por um

255

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

256

abordagem, conforme descritos a seguir:

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

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

257

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

Figura 45: Situao clssica da anlise de sistemas O desenvolvimento de sistemas envolve normalmente a captura do conhecimento de um especialista de alguma rea (no exemplo, um especialista nanceiro) e sua representao em uma forma que facilite o desenvolvimento de uma soluo computacional. papel do analista de sistemas traduzir os termos e conceitos familiares ao especialista para termos e conceitos de computao, familiares ao desenvolvedor. Neste contexto, a palavra domnio refere-se a uma determinada rea de competncia e conhecimento, que possui terminologia e conceitos particulares. No exemplo, os termos e conceitos nanceiros, isto , Aes, ndices e Cotaes, esto dentro da rea de competncia e conhecimento do especialista nanceiro. Este , portanto, o domnio nanceiro. Os termos e conceitos do desenvolvimento de software, isto , Casos de uso, Classes, Objetos, Mtodos, as palavras-chave if, while, entre outras, esto dentro da rea de competncia e conhecimento do desenvolvedor. Alguns desses termos fazem parte do domnio de modelagem. Outros fazem parte do domnio executvel, enquanto outros fazem parte de ambos. Uma outra possvel distino feita no momento em que o analista realiza essa traduo

258

dos termos do domnio nanceiro para os termos dos domnios de modelagem e executvel. No contexto de desenvolvimento de sistemas, o domnio para o qual se est construindo um sistema chamado de domnio do problema, pois trata-se do problema que se pretende resolver. O domnio no qual se est construindo o sistema chamado de domnio da soluo, pois ele representa a soluo computacional que est sendo desenvolvida. Em reutilizao de software, a palavra domnio normalmente utilizada como um sinnimo de Domnio do Problema. Ou seja, quando se fala em aplicaes de um domnio, ou um domnio de aplicaes, se fala em um conjunto de aplicaes que compartilham os mesmos termos e conceitos, e que so especcas para uma mesma rea de conhecimento. Assim, o domnio nanceiro, por exemplo, no contexto da reutilizao de software, compreende todas as aplicaes nanceiras. A partir dessa denio, uma linguagem especca de domnio uma linguagem qualquer que representa os termos e conceitos do domnio. Por exemplo, Java uma linguagem de um domnio executvel, UML uma linguagem de um domnio de modelagem, e assim por diante. Mas atualmente, quando se fala em linguagens especcas de um domnio, normalmente se est querendo dizer linguagens especcas de um domnio de problema. Dessa forma, chega-se seguinte denio (DEURSEN; KLINT; VISSER, 2000). Uma linguagem especca de domnio uma linguagem de programao ou uma linguagem de especicao executvel que oferece, por meio de notaes e abstraes apropriadas, poder expressivo focado em, e normalmente restrito a, um domnio de um problema particular. De acordo com essa denio, uma linguagem do domnio nanceiro tida como uma DSL, enquanto Java e UML no o so. Uma DSL no necessariamente utilizada com objetivo de gerar um programa executvel (FOWLER, 2005). Em muitos casos, pode-se utilizar uma DSL com ns de congurao, por exemplo. Um arquivo XML de congurao de acesso a banco pode ser visto como uma especicao em uma DSL, pois ele contm termos e conceitos associados ao problema de
A acesso a banco de dados. Outro exemplo so os processadores de texto do tipo L TEX, que usam

uma linguagem prpria com o propsito de produzir documentos formatados. Porm, no caso da reutilizao de software, DSLs normalmente so utilizadas com o propsito de se produzir um programa executvel (WARMER; KLEPPE, 2006), reaproveitando o conhecimento especco daquele domnio. A seguir discute-se esse tipo de uso para DSLs. Linguagens especcas de domnio so mais uma expresso da dicotomia entre abordagens

259

genricas (que oferecem solues para mltiplas reas, porm de forma no otimizada), e abordagens especcas (que oferecem solues melhores, porm apenas para um subconjunto de problemas), presente na maioria dos ramos da cincia e da engenharia (DEURSEN; KLINT;
VISSER,

2000).

As atuais linguagens de programao, como Java, C++, e C#, so exemplos de linguagens de propsito genrico, ou seja, ao criar sistemas para diferentes domnios de problema, pode-se utilizar a mesma linguagem. O mesmo acontece para linguagens de modelagem, como a UML, por exemplo, que pode ser utilizada em diferentes cenrios. No entanto, essas linguagens apresentam o problema de exigirem um certo esforo de traduo para expressar solues ou modelos especcos para um determinado problema utilizando construes genricas. Alm disso, esse esforo de traduo precisa ser praticamente repetido toda vez que se for construir uma aplicao diferente para aquele mesmo domnio. Para resolver esse problema, trs abordagens tm sido adotadas (DEURSEN; KLINT; VISSER, 2000): 1. Bibliotecas de subrotinas: consistem em subrotinas que realizam tarefas especcas para um domnio de problema, de forma que o desenvolvedor, ao reutilizar essas subrotinas, tambm reutiliza conhecimento especco para esse domnio; 2. Frameworks orientados a objetos e frameworks de componentes: estendem a idia de bibliotecas de subrotinas. Enquanto bibliotecas possuem uma estrutura simples, com as subrotinas sendo chamadas pela aplicao, os frameworks normalmente esto no controle, sendo os responsveis por chamar o cdigo especco da aplicao; e 3. Linguagens especcas de domnio (DSL): so linguagens pequenas, normalmente declarativas, com poder expressivo focado em um domnio de problema. Normalmente, programas em DSL so convertidos para programas em linguagens comuns, utilizando frameworks ou bibliotecas de subrotinas. Dessa forma, pode-se pensar em uma DSL como uma maneira de esconder os detalhes da biblioteca ou framework. Do ponto de vista da reutilizao, todas essas abordagens so similares, apresentando um nico propsito: reutilizar o conhecimento do domnio na construo de aplicaes daquele domnio. Seja na forma de chamadas de rotinas de uma biblioteca ou utilizando uma linguagem, o resultado nal praticamente o mesmo, com diferenas apenas na forma de expresso da soluo. De fato, Martin Fowler, um conceituado pesquisador na rea de reutilizao, destaca que sempre considerou o fato de denir funes e bibliotecas como uma forma de se construir uma DSL para um problema (FOWLER, 2005).

260

Independentemente da abordagem adotada, a principal caracterstica de uma DSL o fato de ela ter seu poder expressivo focado em um domnio do problema, o que reduz o esforo de traduo necessrio para construir programas, pois os termos da linguagem esto prximos dos termos reais conhecidos pelo especialista daquele domnio. Portanto, DSLs so normalmente pequenas, consistindo de um conjunto de abstraes e notaes restritos a um domnio, de forma que especialistas daquele domnio possam trabalhar nessa linguagem facilmente. Por este motivo, so tambm conhecidas como micro-linguagens ou linguagens pequenas, principalmente pelos usurios do Sistema Operacional Unix (FOWLER, 2005). A utilizao de DSLs apresenta vantagens e desvantagens. destacam-se (DEURSEN; KLINT; VISSER, 2000): DSLs permitem que solues sejam expressas nos termos e no nvel de abstrao do domnio do problema. Consequentemente, especialistas do domnio podem compreender, validar, modicar, ou mesmo desenvolver seus prprios programas; Programas DSLs so concisos, auto-documentados, e podem ser reutilizados com diferentes propsitos; DSLs aumentam a produtividade, conabilidade, manutenibilidade e portabilidade; DSLs incorporam conhecimento sobre o domnio, e portanto possibilitam sua conservao e reutilizao; DSLs possibilitam validao e otimizao no nvel do domnio; e DSLs facilitam a testabilidade das aplicaes. As desvantagens de se utilizar DSL so (DEURSEN; KLINT; VISSER, 2000): O custo para se projetar, implementar e manter uma DSL; O custo de treinamento para usurios da DSL; A pouca disponibilidade de DSLs; A diculdade de se denir um escopo adequado para uma DSL; A diculdade de se balancear entre especicidade ao domnio e linguagens de programao genricas; e Dentre as vantagens,

261

Para os casos de DSLs executveis, a perda potencial de desempenho quando

comparado com cdigo construdo mo. Alguns dos benefcios das DSLs, como aumento da produtividade, conabilidade, manutenibilidade, portabilidade, a reutilizao de conhecimento sobre o domnio, entre outros, podem ser igualmente alcanados por meio da utilizao de frameworks, descritos mais adiante neste apndice, ou outras tcnicas de reutilizao. Dessa forma, frente s suas desvantagens, pode-se argumentar que em alguns casos o uso de DSLs desnecessrio. J outros benefcios, como a possibilidade de se trabalhar nos termos e no nvel de abstrao do domnio do problema, s podem ser obtidos por meio de DSLs. Neste sentido, a deciso de se utilizar ou no essa tcnica se resume anlise dos benefcios obtidos versus o custo necessrio para construir as ferramentas necessrias para oferecer um suporte eciente para DSLs (FOWLER, 2005). Esse custo depende da forma escolhida para se implementar o suporte para a DSL. Aps a anlise do domnio e projeto da DSL, existem duas alternativas principais para se implementar esse suporte: 1. Compilador/interpretador: a forma mais comum de se implementar uma DSL envolve construir uma biblioteca que implementa as noes semnticas, e projetar e implementar um compilador que traduza programas na DSL para chamadas a essa biblioteca (DEURSEN; KLINT; VISSER, 2000). Esse tipo de abordagem tambm conhecido como DSL externa (FOWLER, 2005); e 2. Linguagem embutida: nesse tipo de DSL, tambm conhecida como DSL interna (FOWLER, 2005), uma linguagem de programao genrica estendida com conceitos e operaes do domnio. A principal vantagem que o prprio compilador da linguagem base pode ser utilizado. Em contrapartida, a expressividade da linguagem estendida limitada ao poder expressivo da linguagem base (DEURSEN; KLINT; VISSER, 2000). Por exemplo, a UML (OMG, 2007), com seu mecanismo de extenso, possibilita a criao de linguagens de modelagens especcas de forma bastante razovel. Os pers UML (OMG, 2006a) so um exemplo desse poder. A linguagem LISP, ou outras linguagens adaptveis, tambm so exemplos dessa possibilidade. J a linguagem Java no possui um mecanismo simples de extenso, dicultando o uso de linguagens embutidas. Enquanto a primeira abordagem resulta em uma DSL mais limpa e fcil de ser utilizada, ela requer maior trabalho para implementar o compilador. J a segunda abordagem mais rpida e simples de ser implementada, pois no requer a construo de um compilador. Porm, os resultados no so to satisfatrios como na primeira abordagem.

262

Com relao a linguagens visuais, at pouco tempo o uso do mecanismo de extenso da UML era uma das nicas possibilidades. Recentemente, com as idias do desenvolvimento orientado a modelos, novas tecnologias surgiram para facilitar esse trabalho. So os chamados frameworks de linguagens, que implementam diversas funes necessrias para a modelagem visual, como a representao, criao e edio de diagramas, e o processamento automtico de suas informaes internas. Exemplos incluem o GME (Generic Modeling Environment)1 e o GMF (Graphical Modeling Framework)2 . Analisando a abordagem de DSLs como uma forma de reutilizao de software, pode-se notar que os quatro conceitos da reutilizao tambm esto presentes:

Abstrao: o processo de anlise de um domnio de problema, levantamento de informaes relacionadas, e seu encapsulamento em forma de uma linguagem e uma biblioteca contendo as noes semnticas, corresponde abstrao. O conhecimento reutilizvel do domnio abstrado e expresso em uma linguagem, de forma que um desenvolvedor pode facilmente reconhec-lo e reutiliz-lo. Essa a parte visvel da abstrao. O detalhamento e a implementao das noes semnticas associadas a cada conceito correspondem parte escondida da abstrao; Seleo: uma vez que a DSL esteja construda, o desenvolvedor precisa conhecer a sintaxe e a semntica por trs de cada construo da linguagem. A seleo dos artefatos reutilizveis ento feita pelo desenvolvedor, que escolhe mentalmente os termos e conceitos da linguagem a serem utilizados durante a construo de um programa ou criao de um modelo. Ele pode tambm consultar a gramtica ou manual da linguagem, para ajud-lo a determinar o que precisa utilizar; Adaptao: a adaptao ocorre normalmente por meio de parmetros denidos na prpria linguagem, com os quais o desenvolvedor adiciona detalhes especcos da situao; e Integrao: por m, a integrao normalmente realizada de forma automtica por um compilador ou interpretador, que ir executar as aes semnticas associadas aos termos da DSL, integrando os elementos sendo reutilizados em um aplicativo executvel. Quando o aplicativo gerado a partir de um compilador DSL, pode-se tambm dizer que se trata de um gerador de aplicaes, assunto da prxima seo.

1 ttssrtrts 2 ttsr

263

Programao generativa

Programao generativa (generative programming) a automao da manufatura de produtos intermedirios e nais (i.e., componentes e aplicaes.) (CZARNECKI; EISENECKER, 2000). Essa denio resume o conceito de programao generativa, que vem sendo utilizado desde os primrdios da computao. Signica que parte ou a totalidade dos artefatos produzidos durante o ciclo de vida do software gerada automaticamente. Por exemplo, compiladores que utilizam como entrada um programa em uma linguagem de programao, e geram como sada o cdigo executvel para uma plataforma, esto entre os primeiros exemplos de uso da programao generativa. Outro exemplo so os construtores de interface, tais como aqueles presentes em softwares como Microsoft Visual Studio3 e NetBeans4 . O desenvolvedor especica a interface visualmente, e todo o cdigo que a implementa automaticamente gerado. Caso precise realizar alguma modicao, o desenvolvedor a realiza diretamente no editor visual, e o cdigo que reete essa mudana gerado novamente. A programao generativa pode ser utilizada em outras etapas do ciclo de vida do software. Pode-se gerar casos de teste, esquemas de banco de dados, ou mesmo programas completos. Os benefcios dessa abordagem so bvios: poupa-se o tempo gasto em atividades repetitivas, como tarefas de implementao de infraestrutura, aproveitando-o em atividades mais importantes, como anlise e projeto. Alm de proporcionar os ganhos diretos em termos de tempo de desenvolvimento, a abordagem generativa tambm promove a reutilizao. Um gerador encapsula o conhecimento do domnio necessrio para que sejam produzidos artefatos ou mesmo aplicaes completas daquele domnio. Em outras palavras, a reutilizao desse conhecimento ocorre quando se reutiliza o processo de gerao, e no os componentes (SAMETINGER, 1997). Um elemento necessrio para a abordagem generativa o formato da entrada fornecida a um gerador. Normalmente, utiliza-se uma DSL, ou seja, uma linguagem especializada e orientada ao problema (CZARNECKI; EISENECKER, 2000). Desta forma, o desenvolvedor pode criar as especicaes de forma mais prxima ao problema, o que exige um menor esforo de especicao. Essa DSL pode ser to especializada quanto o necessrio para o problema sendo modelado.
3 ttsrstst 4 tttsr

264

Por exemplo, para modelar um produto matemtico, a DSL precisa ser bem especca, com elementos formais que permitam representar conceitos matemticos. Outro exemplo o caso de um editor de interfaces, onde a DSL visual, sendo composta dos elementos bsicos de uma interface, como botes, caixas de texto, barras de rolagem, entre outros. Pode-se tambm utilizar templates como entrada para um gerador. Um template consiste em uma estrutura pr-denida que representa o artefato nal semi-concludo, com pontos em aberto que podem ser preenchidos atravs de variveis especicadas pelo desenvolvedor. Um dos problemas da programao generativa ocorre quando se deseja modicar os artefatos gerados. Por mais genrico e exvel que seja o gerador, o artefato gerado pode no corresponder exatamente s necessidades do desenvolvedor. Neste caso, o desenvolvedor pode modicar o gerador, para atender s suas necessidades, ou modicar o artefato gerado. Modicar o gerador pode ser uma tarefa custosa. Normalmente os geradores so

ferramentas especcas para um determinado domnio de problema, de forma que introduzir modicaes sem a perda de compatibilidade com esse domnio exige uma anlise demorada. Alm disso, deve-se realizar essas mudanas de forma genrica, pensando-se no somente no artefato que se deseja modicar, mas em todos os artefatos que sero gerados a partir de ento. Por outro lado, modicar o produto do gerador muito mais fcil, pois pode-se trabalhar diretamente no artefato que se deseja modicar. Porm, essas mudanas podem se perder caso o artefato seja re-gerado. Para resolver esse problema, normalmente so utilizadas tcnicas associadas ao conceito de round-trip engineering (HENRIKSSON; LARSSON, 2003; ANTKIEWICZ;
CZARNECKI,

2006; HETTEL; LAWLEY; RAYMOND, 2008). Essas tcnicas so baseadas em

engenharia reversa (HENRIKSSON; LARSSON, 2003), e visam abstrair as mudanas realizadas diretamente nos artefatos gerados, duplicando-as nas especicaes de origem. Dessa forma, as mudanas no se perdem, estando presentes nas prximas geraes de artefatos. Uma abordagem mais simples consiste em no permitir que certas mudanas sejam realizadas. Um exemplo de ferramenta que utiliza essa abordagem a plataforma NetBeans: o editor textual de cdigo de interface desta plataforma bloqueia certos trechos de cdigo, associados com caractersticas estruturais da interface, de forma que o desenvolvedor s pode inserir essas modicaes por meio do editor visual. Essa abordagem, porm, restrita aos casos onde se pode bloquear modicaes sem perder a exibilidade necessria para se resolver os problemas daquele domnio. A abordagem generativa tambm pode ser analisada frente aos quatro conceitos da reutilizao descritos por Krueger (1992):

265

Abstrao: conforme j discutido anteriormente, o que est sendo reutilizado o processo de construo dos artefatos, e no os artefatos em si. A abstrao desse processo consiste na denio do formato de entrada do gerador, seja ele uma DSL visual, textual, ou mesmo parmetros que preenchem um ou mais templates. Essa denio corresponde parte visvel da abstrao, com a qual o desenvolvedor trabalha. A parte escondida ca dentro gerador, e responsvel pelos detalhes de implementao; Seleo: a seleo consiste em escolher um gerador apropriado para o problema em questo. Diferentes geradores correspondem a diferentes processos para se produzir os artefatos do domnio, e pode-se decidir por um deles, dependendo do problema. Neste cenrio, a situao ideal seria manter uma biblioteca de geradores de aplicao, e utilizar tcnicas de classicao e busca para facilitar a seleo, de forma similar s bibliotecas de componentes reutilizveis. Porm, essa situao requer a existncia de um grande nmero de geradores para um mesmo domnio de problema. Em 1992, Krueger destacava a escassez de geradores, que alm de poucos eram normalmente restritos a um nmero reduzido de domnios (KRUEGER, 1992). Atualmente, com a evoluo das tecnologias necessrias para a programao generativa, principalmente a transformao de software, o nmero de geradores vem crescendo, conforme demonstram Allilaire et al. (2006), que exploram o gerenciamento de repositrios de modelos e transformaes de software, utilizando tcnicas similares s utilizadas em repositrios de componentes; Adaptao: a adaptao a tarefa primria realizada por um desenvolvedor de software utilizando um gerador de aplicaes (KRUEGER, 1992). Corresponde tarefa de especicao que produz a entrada requerida pelo gerador, normalmente um programa em uma DSL. O desenvolvedor utiliza essa DSL para informar ao gerador como especializar os conceitos do domnio e produzir uma soluo para o seu problema; e Integrao: a integrao no um problema quando um gerador produz um programa completo (KRUEGER, 1992). Porm, nos casos onde apenas parte dos artefatos gerada, necessrio que os mesmos sejam integrados com outras partes, sejam estas geradas automaticamente ou manualmente. Para que essa integrao seja automtica, os geradores precisam estar preparados e cientes do ambiente ao qual os artefatos gerados sero integrados. Desta forma, os desenvolvedores podem trabalhar somente no nvel de abstrao da entrada do gerador, especicando o que for necessrio para que o gerador possa realizar essa integrao sozinho. Porm, essa a situao ideal. Em outros casos, a nica soluo modicar manualmente os artefatos gerados de forma a promover sua integrao.

266

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

Frameworks orientados a objetos ou frameworks de componentes estendem as idias de bibliotecas de subrotinas e de componentes. A principal diferena, e uma das principais caractersticas dos frameworks, a inverso de controle: enquanto com bibliotecas comuns a aplicao responsvel por realizar chamadas aos artefatos sendo reutilizados, um framework responsvel por realizar chamadas aplicao, detendo o uxo de controle (DEURSEN; KLINT;
VISSER,

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

Estruturalmente, pode-se denir um framework como um conjunto de classes que contm o projeto abstrato de solues para uma famlia de problemas relacionados (JOHNSON; FOOTE, 1988) apud (BRAGA, 2002). Essas classes encapsulam conhecimento sobre essa famlia de problemas, ou sobre esse domnio de problema, que pode ser reutilizado da mesma forma com que se reutilizam componentes de software. Do ponto de vista de seu propsito, pode-se denir um framework como o esqueleto de uma aplicao, que pode ser instanciado por um desenvolvedor de aplicaes (JOHNSON, 1997b) apud (BRAGA, 2002). Sendo um esqueleto, um framework no dene somente as classes de forma isolada, mas tambm as interfaces e conexes entre as mesmas, assim como a estrutura geral da aplicao instanciada. Dessa forma, ao utilizar um framework, um desenvolvedor no est reutilizando somente classes ou componentes isoladamente, que precisam ser posteriormente integrados em uma aplicao, mas sim toda a estrutura interna. Essa estrutura tambm representa parte do conhecimento daquele domnio, e assim pode-se dizer que o nvel de reutilizao alcanado com um framework maior do que o nvel de reutilizao alcanado com componentes isolados, representando um avano signicativo em reutilizao (KRUEGER, 1992).

267

A utilizao de um framework normalmente feita por meio de seus pontos variveis (hotspots), que so os pontos que denem o que varivel em um domnio de aplicao (BUSCHMANN et al., 1996) apud (BRAGA, 2002). Junto com os ganchos (hook), que so os pontos do framework passveis de serem adaptados, os pontos variveis so a forma com que o desenvolvedor normalmente instancia sua aplicao. Sendo uma tcnica de reutilizao, o uso de frameworks compartilha com as demais abordagens apresentas os quatro conceitos bsicos da reutilizao: Abstrao: a abstrao, como na maior parte das abordagens, se resume a representar o conhecimento do domnio abstraindo-se os detalhes de implementao em uma parte escondida, e descrevendo os conceitos de mais alto nvel na parte visvel. No caso dos frameworks, a parte visvel corresponde aos pontos que o desenvolvedor utiliza para instanciar a aplicao, no caso, os pontos variveis e os ganchos. A parte escondida se refere ao restante da estrutura, que normalmente reutilizada sem modicao, tambm conhecidos como frozen spots; Seleo: a seleo se resume escolha de um framework adequado para a aplicao que se deseja construir. Neste caso, tcnicas de classicao e busca podem ser utilizadas para facilitar a seleo; Adaptao: a adaptao consiste na instanciao da aplicao, em que o desenvolvedor utiliza os pontos variveis e ganchos para criar uma aplicao que atenda aos requisitos; e Integrao: a integrao normalmente no um problema, pois um framework j uma aplicao semi-pronta que, uma vez instanciada, pode ser executada diretamente. Porm, pode ser necessrio realizar a integrao da aplicao com o ambiente, por exemplo, com o sistema operacional ou um banco de dados especco. Neste caso, essa integrao ser to simples quanto for a possibilidade de parametrizao do framework. Padres de software Uma forma bastante conhecida de reutilizao so os padres de software (COPLIEN, 2006). Sejam de anlise, de processo ou de projeto, os padres tm um nico objetivo: representar solues bem sucedidas para problemas recorrentes, de forma que, ao se deparar com uma situao similar vivida originalmente, um desenvolvedor possa aplicar a mesma soluo, obtendo os mesmos resultados que o criador do padro. Neste sentido, o objeto da reutilizao o conhecimento obtido na soluo desse problema recorrente. Os quatro conceitos bsicos da reutilizao esto tambm presentes nessa tcnica:

268

Abstrao: a abstrao ocorre quando as solues recorrentes so generalizadas e representadas segundo um formato especco. Existem alguns formatos para descrio de padro que so mais comumente utilizados, destacando-se aquele utilizado em (GAMMA
et al.,

1995). Normalmente essa descrio contm uma descrio do problema, de forma

que um desenvolvedor possa decidir se esse padro adequado ao seu problema ou no; Seleo: a seleo ocorre quando o desenvolvedor procura por um padro por meio da comparao do problema descrito no padro e o problema sendo vivenciado por ele no momento. Esse processo normalmente manual, exigindo uma consulta a catlogos de padres, tal como o catlogo online hillside.net5 ; Adaptao: a adaptao consiste na instanciao do padro, adaptando-o para a situao atual. Os elementos do padro so normalmente genricos, precisando ser renomeados ou mesmo modicados; e Integrao: a integrao exige a adaptao do restante do sistema, ou do projeto, para acomodar os elementos inseridos pelo padro.

Existem basicamente trs abordagens para os processos de adaptao e integrao de um padro (FLORIJN; MEIJERS; WINSEN, 1997): a abordagem top-down, na qual os elementos do padro so criados e ento integrados ao restante do sistema; a abordagem bottom-up, na qual os elementos j existentes no sistema so transformados nos elementos do padro, e a abordagem hbrida, que uma combinao das outras duas, com parte dos elementos do padro sendo criados a partir do zero e parte sendo adaptada a partir de elementos j existentes no sistema.

Reengenharia de Software

Outra tcnica que promove a reutilizao de software a reengenharia de software. Tambm conhecida como renovao ou recuperao, tem como objetivo principal a reconstruo de sistemas legados para aumentar sua qualidade e manutenibilidade. Porm, sistemas legados normalmente encapsulam um conhecimento que evoluiu durante anos, e que no pode ser desperdiado. Dessa forma, a reengenharia de software tambm uma forma de reutilizar software, fazendo com que esse conhecimento seja reaproveitado. A reengenharia de software no somente recupera as informaes de um projeto existente, mas tambm as reutiliza para alterar ou reconstruir o sistema, adicionando novos requisitos ou introduzindo novas
5 ttstttrsttrtt

269

tecnologias. As principais atividades da reengenharia de software so: engenharia reversa, seguida por mudanas no sistema (de funcionalidade ou de implementao), e seguida pela engenharia avante. Em outras palavras, reengenharia o processo de se criar uma descrio abstrata do sistema, elaborar mudanas em alto nvel de abstrao, e ento reimplementar o sistema (JACOBSON; LINDSTROM, 1991). Esse processo de engenharia reversa, modicaes e engenharia avante, tambm contempla os quatro conceitos da reutilizao de software. A fase de engenharia reversa corresponde ao conceito de abstrao, enquanto que as fases de modicaes e engenharia avante correspondem aos demais conceitos: Abstrao: a abstrao corresponde engenharia reversa, onde o conhecimento existente no sistema legado recuperado, e toda informao relevante organizada de forma a possibilitar sua futura utilizao durante a reconstruo; Seleo: a seleo ocorre quando o desenvolvedor precisa realizar mudanas no sistema, sejam elas de funcionalidade ou implementao. Ele precisa conhecer cada artefato recuperado durante a engenharia reversa, e selecionar aquele onde sero feitas as modicaes; Adaptao: a adaptao corresponde s mudanas sendo efetuadas nos artefatos recuperados. Os mesmos so modicados para atender a novos requisitos ou incorporar novas tecnologias; e Integrao: a integrao ocorre de forma gradual. Normalmente, as organizaes preferem utilizar processos de reengenharia gradativos, onde apenas um mdulo reconstrudo a cada vez. Isso possibilita que o sistema legado possa continuar sendo utilizado durante a reconstruo (SEACORD; PLAKOSH; LEWIS, 2003). O Quadro 17 resume as principais tcnicas para reutilizao de software apresentadas neste apndice, apresentando as idias-chave de cada tcnica, de acordo com os quatro conceitos da reutilizao.

270

Desenvolvimento Baseado em Componentes (DBC) Linguagens Especcas de Domnio (DSL) Programao Generativa

Abstrao Encapsulamento e utilizao de interfaces bem denidas

Seleo Navegao automtica

busca

Adaptao Parametrizao modicao interna

ou

Integrao Acoplamento de interfaces providas com requeridas

Anlise de um domnio de problema Denio do formato de entrada

Consulta gramtica ou manual da linguagem Escolha de um gerador apropriado

Parmetros linguagem

denidos

na

Automatizada atravs de um compilador

Produo da entrada do gerador

Frameworks

Padres Reengenharia software de

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

Escolha do adequado

framework

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

Instanciao, atravs dos pontos variveis e ganchos Adaptao do padro para a situao Mudanas nos artefatos recuperados, para atender a novos requisitos ou novas tecnologias

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

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

271

APNDICE B -- Relao entre a abordagem e modelos de maturidade

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

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

272

AP1 - Manuteno de mtodos e tcnicas bsicas de reutilizao: estes devem ser documentados, analisados e mantidos sempre atualizados, atravs de revises peridicas envolvendo a equipe e a gerncia. A abordagem no prev o gerenciamento e manuteno de mtodos e tcnicas para reutilizao; AP2 - Planejamento de reutilizao: deve ser realizado de acordo com um procedimento pr-denido e documentado. O planejamento deve incluir anlise de riscos e determinao das abordagens de reutilizao a serem utilizadas. O ciclo de vida do processo de reutilizao deve tambm ser identicado durante o planejamento. Uma das atividades iniciais da abordagem consiste no planejamento da reutilizao, incluindo possveis riscos, e a adoo desta abordagem pode ser considerada como uma deciso de planejamento, assim como a denio de seu modelo do ciclo de vida; AP3 - Denio dos objetivos da reutilizao: assim como a estratgia adotada, a denio dos objetivos deve ser realizada por um grupo com autoridade e conhecimento para esta tarefa. Os objetivos e estratgia devem ser documentados. Tambm devem ser denidos, documentados e implantados os indicadores de desempenho a serem utilizados para determinar se os objetivos esto sendo alcanados no processo. A abordagem contm uma atividade para denio dos objetivos da reutilizao; AP4 - Implementao do domnio: visa produzir artefatos de software

reutilizveis para o domnio, atravs de codicao, testes, documentao e empacotamento destes artefatos. Envolve basicamente a denio das interfaces providas e requeridas dos artefatos reutilizveis, testes de unidade com os artefatos, documentao e empacotamento desses artefatos. Essa justamente uma das fases da abordagem, que visa implementar um domnio utilizando tcnicas do MDD; Nvel 3 - Denido: neste nvel o principal foco de engenharia o suporte variabilidade. Enquanto no nvel 2 a preocupao era aumentar o nvel de reutilizao de artefatos individuais, aqui o foco oferecer um suporte global variabilidade do domnio, principalmente com as prticas de anlise e projeto do domnio. Tambm neste nvel introduz-se a preocupao com o processo de desenvolvimento de uma organizao, treinamento e a introduo de uma unidade dedicada reutilizao. Preocupaes com a qualidade dos artefatos tambm comeam a aparecer neste nvel; AP5 - Controle e monitoramento do processo de reutilizao: deve ser realizado atravs de um conjunto de mecanismos e mtricas que determinam o status

273

das atividades, e um conjunto de polticas e um plano de aes, responsveis pelo controle do processo. A abordagem no dene nenhum mecanismo ou atividade para controle e monitoramento do processo; AP6 - Integrao com o ciclo de vida do software: so denidas atividades, sub-atividades e produtos de trabalho institucionalizados para a organizao, com base em um modelo de referncia. Tambm importante a denio de um procedimento para a cooperao entre os desenvolvedores e a equipe de reutilizao. Esta prtica consiste justamente na denio desta abordagem e seus elementos; AP7 - Anlise de domnio: envolve a seleo e denio do domnio, anlise das aplicaes existentes para identicao das caractersticas do domnio, denio dos requisitos e escopo do domnio, identicao e documentao dos pontos variveis e comuns, e a identicao e documentao de restries adicionais entre as caractersticas do domnio. A abordagem possui uma fase especca para a anlise de domnio voltada para o MDD; AP8 - Projeto de domnio: envolve a denio de uma arquitetura de referncia para o domnio, que dene a maneira com que os sistemas do domnio sero construdos. Os requisitos, incluindo a variabilidade, devem ser mapeados para solues tcnicas. Padres de projeto devem oferecer suporte estrutura varivel que serve de base para os aplicativos do domnio. O arquiteto deve reduzir a complexidade do projeto atravs de abstraes que consigam separar os principais aspectos do domnio. O arquiteto deve modelar as abstraes de forma a permitir o raciocnio sobre elas. Esta rea tambm envolve a avaliao arquitetural, visando detectar falhas e erros antes da implementao comear. A abordagem engloba as prticas relacionadas ao projeto de domnio, incluindo projeto arquitetural e suporte variabilidade; AP9 - Treinamento em reutilizao: envolve um programa organizacional de treinamento com suporte adequado, um planejamento do treinamento, e o estabelecimento de um comit de treinamento interno. A abordagem no prev atividades para treinamento; AP10 - Gerenciamento da unidade de reutilizao: inclui principalmente o estabelecimento de um comit de reutilizao, com um lder, e suporte e nanciamentos providos por uma alta gerncia comprometida. Este comit deve possuir regras e responsabilidades bem denidas, ser composto de membros bem treinados e motivados, e possuir canais de comunicao com a organizao. A

274

abordagem no dene uma unidade dedicada reutilizao; AP11 - Programa de mtricas: denio de polticas e objetivos para medio da reutilizao em toda organizao. Um plano de medio de reutilizao deve ser desenvolvido, com mecanismos para coleta, anlise e aplicao de dados. Planos de aes para melhoria de processo com base nos resultados das medies tambm so importantes. A abordagem no dene nenhum tipo de mtrica de controle de andamento do processo, ou controle de qualidade; AP12 - Programa de avaliao organizacional: envolve a denio, por parte da alta gerncia, de polticas de avaliao, alm do suporte e integrao do processo de avaliao na cultura organizacional. O comit de reutilizao, possivelmente junto com o grupo de controle de qualidade da organizao, devem desenvolver e documentar os objetivos, planos e procedimentos de avaliao durante o ciclo de vida. Finalmente, o pessoal envolvido deve ser apropriadamente treinado nas polticas, prticas e procedimentos de avaliao. A abordagem no dene nenhuma atividade com este objetivo; AP13 - Avaliao da qualidade dos artefatos: envolve a denio de um modelo de qualidade, que dene polticas, objetivos e atributos relacionados qualidade dos artefatos reutilizveis, assim como um processo de avaliao dos mesmos. Avaliao de qualidade no faz parte da abordagem; AP14 - Engenharia de Aplicaes: engloba as prticas de desenvolvimento com a reutilizao de artefatos previamente construdos. Envolve a busca, seleo, adaptao e integrao dos artefatos reutilizveis. Assume-se que estes artefatos tenham sido previamente testados, e portanto nesta rea esto somente as prticas de testes de integrao e testes de sistema. Tambm envolve a estimativa de esforo de reutilizao, uma vez que pode ser mais vantajoso construir um artefato do zero do que reutilizar um artefato que exige grande esforo de adaptao. O desenvolvimento com reutilizao est fora do escopo desta pesquisa, e portanto a abordagem no possui nenhuma atividade relacionada a esta prtica; Nvel 4 - Sistemtico: este o nvel mais avanado que uma organizao pode chegar em termos de reutilizao de software. Neste nvel, o processo est em constante otimizao, de acordo com resultados de projetos anteriores. Tambm aqui a qualidade dos artefatos reutilizveis sujeita a um processo mais rigoroso de controle de qualidade. Outras prticas interessantes deste nvel 4 incluem a tentativa de se prever e suprir

275

necessidades futuras em termos de artefatos reutilizveis, e uma anlise de mercado para se avaliaram questes de investimento em reutilizao; AP15 - Otimizao do processo de reutilizao: envolve a identicao das prticas que precisam ser melhoradas, seguida da implementao das melhorias, e medio do progresso de melhoria. A contnua avaliao de novas ferramentas e tecnologias relacionadas reutilizao tambm precisa ser realizada. A abordagem no prev atividades para melhoria e evoluo do processo; AP16 - Controle de qualidade dos artefatos: um passo alm da avaliao da qualidade, com objetivos especcos para os produtos de software sendo incorporados no planejamento da reutilizao. O comit de reutilizao tambm precisa ser treinado em mtodos estatsticos para poder melhor avaliar os artefatos frente a seus modelos de qualidade. A abordagem no trata do controle de qualidade dos artefatos reutilizveis; AP17 - Previsibilidade dos artefatos reutilizveis: consiste na identicao de necessidades futuras em termos de artefatos potencialmente reutilizveis, visando reduzir o tempo de desenvolvimento em projetos envolvendo estes artefatos. No h nenhuma atividade com este objetivo; AP18 - Anlise de condies de mercado e retorno de investimento: busca analisar o nvel de retorno dos investimentos em reutilizao, de acordo com as condies do mercado e oportunidades para novos negcios. Tambm envolve a aquisio de artefatos do domnio, caso necessrio. A anlise de mercado realizada supercial, e se resume a uma pesquisa com base em conhecimento dos especialistas, sem atividades especcas para determinao de custos e retorno de investimento. Modelo de maturidade em MDD (MODELWARE, 2006d) Nvel 1 - Modelagem ad hoc: neste nvel, apenas o desenvolvimento tradicional realizado. Prticas de modelagem so utilizadas apenas esporadicamente ou nunca. No existem prticas denidas para este nvel; Nvel 2 - MDD Bsico: este nvel caracterizado pela utilizao bsica de modelos, cobrindo atividades simples do MDD. Modelos so utilizados apenas para guiar a implementao e documentao. Tipicamente, apenas modelos tcnicos so utilizados, incluindo todos os aspectos de um sistema, sem distino entre aspectos de negcio ou aspectos especcos de plataforma;

276

ENG1 - Decidir sobre convenes de modelagem: consiste na identicao e seleo das convenes de modelagem a ser utilizadas pela equipe de desenvolvimento. Para isso, denido o escopo do modelo: quais requisitos podem/devem ser modelados. Tambm envolve a deciso sobre quais partes do software sero feitas mo, e quais sero automaticamente geradas. So denidos quais tipos de diagramas sero construdos e utilizados e com quais tcnicas de modelagem. A abordagem possui uma atividade na qual so analisadas as possibilidades de linguagens a serem utilizadas na modelagem; PJM1 - Decidir sobre ferramentas de modelagem: envolve a seleo de ferramentas que possam satisfazer s necessidades do projeto, de gerao de cdigo e documentao. Deve levar em conta objetivos e restries do projeto, tais como custos e durao. Assim como na atividade acima ENG1, a abordagem tambm busca analisar ferramentas existentes para serem utilizadas; ENG2 - Desenvolver modelo tcnico: o modelo tcnico descreve os

principais mdulos do software, incluindo elementos independentes e especcos de plataforma. O modelo tcnico representa a diviso em camadas, a comunicao entre as camadas, os componentes a serem utilizados ou desenvolvidos, as interfaces entre os componentes, a plataforma destino e persistncia, entre outros aspectos de negcio e tcnicos do sistema. A abordagem no est focada em um tipo especco de modelo, e portanto pode ser utilizada para desenvolver modelos tcnicos; ENG3 - Gerar cdigo a partir do modelo tcnico: ferramentas simples de gerao automtica de cdigo produzem cdigo que corresponde ao modelo tcnico. A sada desta atividade o esqueleto do produto de software. Envolve tambm a separao entre cdigo gerado e cdigo no-gerado, e a complementao com cdigo manual para satisfazer aos requisitos, caso a gerao no produza todo o cdigo necessrio. A gerao de cdigo um dos principais itens da abordagem, e portanto esta prtica est plenamente implementada; ENG4 - Gerar documentao a partir do modelo tcnico: similar gerao de cdigo, a documentao de projeto do sistema pode ser gerada a partir do modelo tcnico, ou pelo menos parcialmente. Envolve a gerao da documentao e a complementao manual, caso a documentao gerada no seja completa. Apesar de ser possvel gerar qualquer tipo de artefato, a abordagem no dene atividades especcas para gerao de documentao; Nvel 3 - MDD Inicial: neste nvel introduz-se uma separao entre modelos de negcio

277

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

transformaes devem ser desenvolvidas com base nos metamodelos de origem e destino. A denio das transformaes com base na sintaxe concreta (por exemplo, XMI) so insucientes pois elas limitam a transformao a apenas uma sintaxe concreta. Para isso, decide-se sobre qual linguagem de transformao utilizar, so identicados os metamodelos de origem e destino, so denidas as regras de transformao, que so compiladas e executadas por uma ferramenta, e opcionalmente, completa-se o cdigo gerado, caso necessrio, para completar a transformao. A abordagem tem atividades para transformaes de modelo-para-texto, visando dar suporte variabilidade do domnio; ENG7 - Vericar modelos: a vericao de modelos inclui a checagem dos requisitos, para determinar se esto completamente e adequadamente reetidos nos modelos. A abordagem no dene atividades para vericao de modelos; PJM2 - Modelar o processo de MDD do projeto: normalmente, cada organizao tem um processo de desenvolvimento implantado, que modicado ou adaptado para atender s necessidades de cada projeto. No caso do MDD, essa adaptao deve considerar que: (i) os requisitos devem ser modelados nas ferramentas selecionadas para a organizao, e utilizando os padres de modelagem pr-estabelecidos; (ii) o foco das tarefas do projeto deve se concentrado nas atividades de modelagem e na denio de transformaes entre modelos; e (iii) a maioria dos resultados as atividades de engenharia so modelos e transformaes entre modelos. A abordagem est completamente modelada, e portanto pode ser utilizada como modelo do processo; PJM3 - Aplicar o processo estabelecido: consiste na utilizao do processo denido, e obteno de mtricas para controle de sua execuo. Uma organizao

278

pode aplicar a abordagem, mas no foram denidas mtricas para gerenciar e controlar sua execuo, e portanto esta prtica no est completamente satisfeita; PJM4 - Denir, coletar e analisar mtricas do projeto: as mtricas devem estar ligadas aos objetivos do projeto. O foco deve ser nas atividades especcas do MDD, como qualidade arquitetural, corretude dos modelos, etc. A abordagem no dene nenhuma atividade referente denio, coleta e anlise de mtricas; SUP1 - Estabelecer e manter repositrios para modelos e transformaes: com o objetivo de promover a reutilizao dos modelos e transformaes na organizao, repositrios devem ser desenvolvidos e mantidos, de forma que modelos e transformaes produzidos em um projeto podem ser reaproveitados em outros projetos. A abordagem no dene nenhum tipo de repositrio para o MDD; SUP2 - Denir tcnicas padronizadas de modelagem e critrios de qualidade: envolve a denio de um padro de modelagem para a organizao, que representa a evoluo das convenes de modelagem denidas no nvel 2. Tambm envolve a denio de critrios de qualidade de modelos, como completude de modelo, consistncia inter-diagramas, legibilidade, etc. A abordagem apenas contm atividades, passos e diretrizes, sem denir tcnicas padronizadas ou critrios de qualidade; SUP3 - Checar aplicao das prticas: consiste em vericar se as prticas de modelagem e artefatos produzidos esto de acordo com as tcnicas de modelagem e critrios de qualidade pr-estabelecidos. A abordagem no dene maneiras de controle sobre a aplicao de suas prticas; SUP4 - Denir mtricas padronizadas e procedimentos de coleta e anlise de dados: envolve a denio de mtricas para as atividades de modelagem, para os modelos, como coletar as mtricas e como analisar os dados. A abordagem no dene nenhum tipo de mtricas para controle; Nvel 4 - MDD Integrado: o nvel 4 caracterizado por uma melhor integrao entre os nveis de abstrao de modelagem. Aspectos de negcio, independentes de plataforma e especcos de plataforma so separados em elementos do MDD, atividades de modelagem so integradas, e garante-se um desempenho de modelagem eciente; ENG8 - Desenvolver metamodelo centrado na arquitetura: envolve

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

279

relacionamentos entre estas entidades, e a linguagem de metamodelagem a ser utilizada. Por m, o metamodelo desenvolvido em uma ferramenta que d suporte linguagem estabelecida. O projeto arquitetural voltado ao MDD est presente na abordagem, que tem atividades para que o metamodelo seja centrado na arquitetura; ENG9 - Desenvolver metamodelo independente de plataforma: de forma similar ao desenvolvimento do metamodelo centrado na arquitetura, o modelo independente de plataforma desenvolvido modelando-se as principais entidades do sistema e seus relacionamentos, mas sem referncias a uma plataforma especca. A abordagem no est focada em um tipo especco de modelo, e portanto pode ser utilizada para desenvolver metamodelos independentes de plataforma; ENG10 - Desenvolver modelo de negcios: consiste na anlise dos requisitos de negcio e criao de um modelo que representa como o sistema funciona, utilizando entidades de negcio e relacionamento entre elas. A abordagem no est focada em um tipo especco de modelo, e portanto pode ser utilizada para desenvolver modelos de negcio; ENG11 - Desenvolver transformaes modelo-para-modelo: consiste na identicao dos metamodelos de origem e destino, padres de transformao entre os modelos de origem e destino, denio da linguagem de transformaes a ser utilizada, e implementao da transformao. A sintaxe concreta deve ser ignorada neste caso. As transformaes modelo-para-modelo esto previstas na abordagem, como uma forma de organizao e estruturao dos geradores de cdigo; ENG12 - Manter rastreabilidade entre modelos: signica manter ligaes ou mapeamentos explcitos entre modelos, aps o resultado de uma transformao. Envolve a denio de um framework de rastreabilidade, com componentes e modelos a serem rastreados, tipos de ligaes, direo, etc. Os requisitos de rastreabilidade devem ser integrados ao processo de modelagem, que tambm responsvel por realizar a gerncia de congurao e controle de verses das ligaes de rastreabilidade. A abordagem prev rastreabilidade entre artefatos de anlise, projeto e implementao, mas no inclui o rastreamento entre elementos antes e aps uma transformao, e portanto esta prtica no est completamente satisfeita; ENG13 - Integrar desenvolvimento de produto com desenvolvimento de infraestrutura para uma famlia de produtos: esta prtica s aplicvel nos

280

casos onde o desenvolvimento de uma famlia de produtos realizado. O objetivo desta prtica separar os modelos tcnicos dos produtos daqueles da infraestrutura da famlia, de forma que ambos sejam mais reutilizveis. Esta a preocupao central da abordagem; ENG14 - Simular modelos: o objetivo desta prtica avanada de controle de qualidade garantir a qualidade dos elementos do MDD o mais rpido possvel no ciclo de vida. Simulao de modelos permite a vericao do comportamento modelado de um sistema. Requer a existncia de uma especicao formal das aes, em uma linguagem semntica de aes. No existem atividades especcas para simulao de modelos; SUP5 - Estabelecer e manter limites de desempenho de modelagem da organizao: a organizao deve denir e manter os objetivos das atividades de modelagem, e elementos de MDD utilizados, de acordo com cada tipo particular de projeto. Esta prtica visa atender necessidade de alinhamento dos objetivos de negcio da organizao com os objetivos do projeto. A abordagem no tem nenhuma atividade similar a esta prtica, que exige um conhecimento sobre diferentes opes de processo para cada projeto, cada um com um grau especco de automao, visando dosar o nvel de automao em cada projeto; PJM5 - Modelar os processos automticos de MDD do projeto: esta prtica estende a prtica do nvel 3, de modelagem do processo, introduzindo limites de desempenho de modelagem, estabelecidos pela organizao quando desenvolvendo o modelo do processo. A modelagem da abordagem se limita descrio das atividades, no contemplando todos os requisitos desta prtica, que exige um conhecimento sobre diferentes opes de processo para cada projeto, cada um com um grau especco de automao, visando dosar o nvel de automao em cada projeto; Nvel 5 - MDD Denitivo: neste ltimo e derradeiro nvel, todo o conhecimento da organizao mantido na forma de modelos e transformaes, que so o foco do processo de desenvolvimento. Prticas de engenharia de domnio e linguagens especcas de domnio so criadas e continuamente atualizadas; ENG15 - Desenvolver linguagens especcas de domnio: linguagens

especcas de domnio capturam o conhecimento do domnio utilizando abstraes do domnio, permitindo que os desenvolvedores criem produtos com base em termos familiares do domnio. Consiste na identicao dos principais conceitos