UMA ABORDAGEM PARA A CRIAO DE ARQUITETURAS DE REFERNCIA DE DOMNIO A PARTIR DA COMPARAO DE MODELOS ARQUITETURAIS DE APLICAES

Guilherme Zanetti Kmmel

DISSERTAO SUBMETIDA AO CORPO DOCENTE DA COORDENAO DOS PROGRAMAS DE PS-GRADUAO DE ENGENHARIA DA UNIVERSIDADE FEDERAL DO RIO DE JANEIRO COMO PARTE DOS REQUISITOS

NECESSRIOS PARA A OBTENO DO GRAU DE MESTRE EM CINCIAS EM ENGENHARIA DE SISTEMAS E COMPUTAO.

Aprovada por: ________________________________________________ Profa. Cludia Maria Lima Werner, D.Sc.

________________________________________________ Profa. Aline Pires Vieira de Vasconcelos, D.Sc.

________________________________________________ Prof. Geraldo Bonorino Xexo, D.Sc.

________________________________________________ Profa. Rosngela Aparecida Dellosso Penteado, D.Sc.

RIO DE JANEIRO, RJ BRASIL JULHO DE 2007

KMMEL, GUILHERME ZANETTI Uma Abordagem para a Criao de

Arquiteturas de Referncia de Domnio a partir da Comparao de de Modelos [Rio de

Arquiteturais Janeiro] 2007 XII, M.Sc., 128

Aplicaes

p.,

29,7

cm de

(COPPE/UFRJ, Sistemas e

Engenharia

Computao, 2007) Dissertao Universidade Federal do Rio de Janeiro, COPPE 1. 2. 3. 4. Arquitetura de Referncia Domnio Opcionalidade Variabilidade

I. COPPE/UFRJ II. Ttulo (srie)

ii

A todos que, de alguma forma, me ajudaram a chegar at aqui, e que certamente estaro comigo. iii

Agradecimentos

Agradeo sinceramente professora Claudia Werner pela grande oportunidade de fazer o mestrado. Sua orientao, pacincia, seriedade, competncia e exigncia foram fundamentais para a realizao deste trabalho. Levarei sempre comigo esta gratido.

Aline Vasconcelos que me incentivou e orientou em todos os momentos, sempre solcita, pronta para ajudar, praticamente incansvel. Sua participao foi, e continua sendo, muito importante.

Ao Leonardo Murta que, com sua competncia, humildade e profundos conhecimentos sobre diversos assuntos, guiou meu aprendizado nas diversas tecnologias usadas.

Ao professor Guilherme Travassos com quem muito aprendi sobre Engenharia de Software. Seus ensinamentos determinaram como deveriam ser feitos os estudos experimentais deste trabalho.

Aos colegas da COPPE que apoiaram o estudo experimental da abordagem: Marco Lopes, Eldanae Teixeira, Paula Fernandes e Anderson Marinho.

Aos colaboradores da Prolink que apoiaram o estudo experimental da ferramenta: Daniel Schmitz, Filipe Manganelli, Andr Pena e Marcelo Furtado.

Aos colegas da COPPE que de alguma forma colaboraram para a realizao dos trabalhos: Ana Maria Moura, Ana Paula Blois, dentre outros.

A todos da rea da produo da Prolink, em especial Adriano Mendes, Hlcio Maciel e Carlos Eduardo Dellagarza pelo apoio e compreenso.

Ao amigo Marco Antonio Arajo pela indicao durante meu processo de seleo na COPPE.

iv

Aos amigos e companheiros de viagem: Wagner Arbex e Jos Fortuna.

Segundo o Dalai Lama, o valor que damos a algo, proporcional a tudo aquilo que tivemos de abrir mo para conquist-lo. Desta forma, posso afirmar, no somente atravs de sentimentos, mas tambm em funo de tudo aquilo que tive que deixar de fazer durante este perodo, o grande valor que este mestrado representa para mim.

Portanto gostaria de fazer um agradecimento a todos aqueles que deixaram de estar comigo em vrios momentos, por estar dedicado este trabalho, em especial minha esposa Juliana, minha famlia e os amigos Marcelo Castanha e Carlos Cavalari.

Agradecimento especial tambm aos professores Geraldo Xexo e Rosngela Dellosso Penteado por terem aceitado participar da minha banca de mestrado, e por dispensarem seu tempo e conhecimento dedicados esta leitura.

Resumo da Dissertao apresentada COPPE/UFRJ como parte dos requisitos necessrios para a obteno do grau de Mestre em Cincias (M.Sc.)

UMA ABORDAGEM PARA A CRIAO DE ARQUITETURAS DE REFERNCIA DE DOMNIO A PARTIR DA COMPARAO DE MODELOS ARQUITETURAIS DE APLICAES Guilherme Zanetti Kmmel Julho / 2007 Orientadoras: Cludia Maria Lima Werner Aline Pires Vieira Vasconcelos Programa: Engenharia de Sistemas e Computao O aumento em tamanho e complexidade do software, somado a uma maior demanda pela construo de software em menor tempo e com mais qualidade, so desafios enfrentados pelas empresas atualmente. Alm disso, em geral, empresas tendem a desenvolver sistemas de software similares (i.e. no mesmo domnio), o que vem motivando cada vez mais a construo de sistemas com abordagens de reutilizao, como Engenharia de Domnio (ED) e Linha de Produtos (LP). Em um dado domnio, arquiteturas de referncia de domnio (DSSA Domain Specific Software Architecture) representam um papel fundamental para seu entendimento e para a instanciao de aplicaes similares. Nesse contexto, proposta, nesta dissertao, uma abordagem para a comparao de arquiteturas de aplicaes, visando deteco de suas similaridades, diferenas e variabilidades, para que, com base nestas informaes, seja possvel apoiar o Engenheiro de Domnio na criao de uma DSSA. A abordagem, denominada ArchToDDSA, e sua ferramenta de apoio, ArchToDSSATool, apresentam diferenciais em relao a outras abordagens, como um dicionrio de sinnimos, deteco semiautomtica de variabilidades, e apoio definio dos elementos para compor a DSSA. O trabalho foi desenvolvido no contexto do ambiente Odyssey, que visa apoiar a reutilizao de software por meio de abordagens como ED, LP e DBC (Desenvolvimento Baseado em Componentes). Assim, ArchToDSSATool, est integrada com ferramentas que permitem a extrao de arquiteturas de sistemas legados e a modelagem da DSSA criada, diferenciando-a em relao s outras abordagens e implementaes estudadas. vi

Abstract of Dissertation presented to COPPE/UFRJ as a partial fulfillment of the requirements for the degree of Master of Science (M.Sc.)

AN APPROACH FOR THE CREATION OF DOMAIN REFERENCE ARCHITECTURES BYCOMPARING APPLICATION ARCHITECTURAL MODELS Guilherme Zanetti Kummel July / 2007 Advisors: Cludia Maria Lima Werner Aline Pires Vieira Vasconcelos Department: Computer and Systems Engineering The increase in software size and complexity, added to a bigger demand for the software construction in less time and higher quality, are challenges currently faced for the companies. Moreover, in general, companies tend to develop similar systems (i.e., software in a specific domain). This fact increases the development of systems using some kind of reuse approach, such as Domain Engineering (DE) and Product Lines (PL). In a specific domain, a DSSA (Domain Specific Architecture Software) represents a basic role for its agreement and for instantiation of similar applications. In this context, it is proposed, in this dissertation, an approach for the comparison of application architectures, aiming at the detection of its commonality and variability. Thus based on this information, it can be possible to support the Domain Engineer in the DSSA creation process. The approach, named ArchToDDSA, and its tool support, ArchToDSSATool, present some differential in relation to other approaches, such as a synonymous dictionary, a semi-automatic process of variability detection, and support to the selection of elements to compose the DSSA. The presented work was developed in the context of Odyssey SDE, which aims to support the software reuse by using approaches such as DE, PL and CBD (Component-Based Development). As a result, ArchToDSSATool is integrated with tools that allow the extraction of legacy systems architectures and the modeling of the created DSSA, which make this approach different from the other approaches and implementations that have been studied.

vii

Edited by Foxit Reader Copyright(C) by Foxit Software Company,2005-2006 For Evaluation Only.

ndice
Captulo 1: Introduo...................................................................................................1 1.1 - Motivao .............................................................................................................2 1.2 - Objetivos...............................................................................................................4 1.3 - Organizao da Dissertao...................................................................................5 Captulo 2: Arquiteturas de Software.............................................................................6 2.1 - Definio ..............................................................................................................7 2.2 - Vises Arquiteturais..............................................................................................8 2.3 - Representao Arquitetural .................................................................................10 2.3.1 - Representando Arquiteturas atravs de ADLs ...................................................11 2.3.2 - Representando Arquiteturas atravs de UML....................................................12 2.4 - Evoluo e Comparao de Arquiteturas .............................................................14 2.4.1 - Comparando Arquiteturas na Gerncia de Configurao...................................15 2.4.2 - Comparando Arquiteturas em UML .................................................................16 2.4.3 Comparando Arquiteturas em XML....................................................................17 2.4.4 Comparando Arquiteturas em xADL ..................................................................17 2.5 - Consideraes Finais...........................................................................................20 Captulo 3: Engenharia de Domnio, Linha de Produtos e suas Abordagens para Apoiar a Especificao de Arquiteturas de Referncia.............................................................22 3.1 - Engenharia de Domnio.......................................................................................24 3.2 - Linhas de Produto ...............................................................................................27 3.3 - Abordagens de Engenharia de Domnio e o seu apoio Especificao de Arquiteturas de Referncia de Domnio (DSSAs) ........................................................31 3.4 - Abordagens de Linha de Produtos de Software e o seu apoio Arquitetura .........32 3.5 - Consideraes Finais...........................................................................................34 Captulo 4: ArchToDSSA: Uma Abordagem para a Criao de Arquiteturas de Referncia de Domnio a partir da Comparao de Modelos Arquiteturais de Aplicaes.........................................................................................36 4.1 - A abordagem ArchToDSSA .................................................................................37 4.2 Descrio do Domnio de Telefonia Mvel.........................................................40 4.3 - Fase 1: Deteco de Equivalncias e Opcionalidades...........................................42 4.3.1 - Critrios para Deteco de Equivalncias .........................................................44

viii

Edited by Foxit Reader Copyright(C) by Foxit Software Company,2005-2006 For Evaluation Only.

4.3.2 - Descrio do Algoritmo de Deteco de Equivalncias ....................................47 4.3.3 - Confirmao de Equivalncias .........................................................................49 4.3.4 - Deteco da Opcionalidades atravs das Equivalncias identificadas................49 4.4 - Fase 2: Deteco das Variabilidades....................................................................50 4.4.1 - Deteco de Pontos de Variao (VPs) e suas Variantes ...................................52 4.4.1.1 - Descrio do algoritmo de Deteco de Pontos de Variao (VPs) e Variantes ..................................................................................................................52 4.5 - Fase 3: Criao de uma Arquitetura de Referncia..............................................54 4.5.1 - Critrios de Seleo de Elementos para a Arquitetura de Referncia.................56 4.6 - Consideraes Finais sobre a Abordagem ArchToDSSA ......................................57 Captulo 5: ArchToDSSATool: Uma Ferramenta de Apoio para a Abordagem ArchToDSSA..............................................................................................................60 5.1 - O ambiente Odyssey ...........................................................................................60 5.2 - Arquitetura da Ferramenta ArchToDSSATool ......................................................61 5.3 - Utilizao da ArchToDSSATool...........................................................................68 5.3.1 - Primeira Fase ...................................................................................................71 5.3.2 Segunda Fase...................................................................................................74 5.3.3 - Terceira Fase....................................................................................................77 5.4 - Consideraes Finais...........................................................................................80 Captulo 6: Avaliao da abordagem ArchToDSSA......................................................81 6.1 - Primeiro Estudo de Observao: Abordagem.......................................................82 6.1.1 - Descrio do Primeiro Estudo ..........................................................................83 6.1.2 - Resultados do Primeiro Estudo.........................................................................87 6.2 - Segundo Estudo de Observao : Ferramenta ......................................................90 6.2.1 - Descrio do Segundo Estudo ..........................................................................90 6.2.2 Resultados do Segundo Estudo ........................................................................92 6.3 - Consideraes Sobre os Estudos de Observao ..................................................96 Captulo 7: Concluses e Trabalhos Futuros ................................................................98 7.1 - Contribuies ......................................................................................................98 7.2 - Limitaes ........................................................................................................ 100 7.3 - Perspectivas Futuras.......................................................................................... 101 Referncias Bibliogrficas......................................................................................... 102 Anexo I: Formulrio de Consentimento..................................................................... 110 Anexo II: Leitura Introdutria ................................................................................... 111 ix

Anexo III: Instrues para Execuo dos Estudos de Observao .............................. 115 Anexo IV: Formulrios de Registro de Resultados .................................................... 117 Anexo V: Representao das Arquiteturas de Sistemas Legados................................ 119 Anexo VI: Dicionrio de Sinnimos do Domnio ...................................................... 125 Anexo VII: Formulrio de Caracterizao dos Participantes ...................................... 127 Anexo VIII: Avaliao Subjetiva............................................................................... 128

ndice de Figuras
Figura 2.1 - Vises do modelo 4+1................................................................................9 Figura 2.2 - Comparao de arquiteturas em xADL. ....................................................19 Figura 3.3- Ciclo de Vida da Engenharia de Domnio..................................................25 Figura 3.4 Principais Atividades da Linha de Produtos de Software...........................29 Figura 3.5 Desenvolvimento do Produto..................................................................30 Figura 4.6 Abordagem ArchToDSSA .......................................................................39 Figura 4.7 Arquiteturas do domnio de Telefonia Mvel...........................................40 Figura 4.8 ArchToDSSA Fase 1 .............................................................................42 Figura 4.9 Critrio de Comparao entre nomes .......................................................46 Figura 4.10 Identificao de candidatos equivalncia..............................................48 Figura 4.11 ArchToDSSA Fase 2 ...........................................................................50 Figura 4.12 Identificao de Pontos de Variao ......................................................53 Figura 4.13 Identificao de Variantes......................................................................53 Figura 4.14 - ArchToDSSA Fase 3 ..........................................................................55 Figura 5.15 Arquitetura da ArchToDSSATool..........................................................62 Figura 5.16 - Pacote Matches ......................................................................................62 Figura 5.17 Pacote MatchList ...................................................................................63 Figura 5.18 Pacote MatchTrees ................................................................................63 Figura 5.19 Pacote VP..............................................................................................64 Figura 5.20 Pacote VPList........................................................................................64 Figura 5.21 Pacote VariantTrees...............................................................................65 Figura 5.22 - Pacote Export .........................................................................................65 Figura 5.23 - Pacote ExportTree..................................................................................66 Figura 5.24 Pacote ExportItemsInfo .........................................................................66 Figura 5.25 Ponto de entrada da arquitetura da ArchToDSSATool ...........................67 Figura 5.26 - Acesso ferramenta ArchToDSSATool atravs de arquivo executvel...68 Figura 5.27 Acesso ferramenta ArchToDSSATool atravs do Odyssey...................69 Figura 5.28 - Fases da abordagem ArchToDSSA........................................................70 Figura 5.29 - Definio do Conjunto de trabalho .........................................................70 Figura 5.30 - ArchToDSSA - Primeira Fase ................................................................71 Figura 5.31 - Configurao de critrios para deteco de equivalncias .......................72 Figura 5.32 - Equivalncias geradas automaticamente pela ferramenta ........................73

xi

Figura 5.33 - ArchToDSSA - Segunda Fase ................................................................74 Figura 5.34 - Configurao de critrios para VPs.........................................................75 Figura 5.35 - Definio manual de pontos de variao.................................................76 Figura 5.36 - ArchToDSSA - Terceira Fase.................................................................77 Figura 5.37 - DSSA exportada para a ferramenta Poseidon..........................................78 Figura 5.38 - DSSA exportada para o ambiente Odyssey.............................................79

xii

ndice de Tabelas
Tabela 4.1 Heursticas de mapeamento de Variabilidades e Opcionalidades da notao Odyssey-FEX (Adaptado de (OLIVEIRA, 2006))...............................................51 Tabela 6.2 Distribuio das atividades aos participantes do primeiro estudo de observao...........................................................................................................85 Tabela 6.3 Mdia de acertos dos participantes na primeira fase da abordagem..........87 Tabela 6.4 - Mdia de acertos dos participantes na segunda fase da abordagem VP. ......................................................................................................................88 Tabela 6.5 - Mdia de acertos dos participantes na segunda fase da abordagem Variantes .............................................................................................................88 Tabela 6.6 - Distribuio das atividades aos participantes do segundo estudo de observao...........................................................................................................92 Tabela 6.7 Mdia de acertos dos participantes na primeira fase da abordagem com o uso da ferramenta ................................................................................................92 Tabela 6.8 - Mdia de acertos dos participantes na segunda fase da abordagem com o uso da ferramenta ................................................................................................93 Tabela 6.9- Mdia de acertos dos participantes na segunda fase da abordagem com o uso da ferramenta ................................................................................................93 Tabela 6.10 Comparao dos resultados dos dois estudos de observao ..................95

xiii

Edited by Foxit Reader Copyright(C) by Foxit Software Company,2005-2006 For Evaluation Only.

Captulo 1: Introduo
A reutilizao de software, isto , o processo pelo qual sistemas so criados a partir de software preexistente, ao invs de serem criados do zero (KRUEGER, 1992) vem, cada vez mais, se mostrando uma realidade. A busca pelo aumento da qualidade e reduo do esforo no desenvolvimento de software atravs da reutilizao crescente na comunidade de desenvolvedores. No entanto, para alcanar tal objetivo, a simples reutilizao de cdigo-fonte no suficiente, fazendo-se necessrio reutilizar elementos que esto implcitos a essa reutilizao, como os elementos de anlise e projeto. Faz-se necessrio reutilizar todo o conhecimento envolvido no desenvolvimento de software. (BARROCA et al., 2005; WERNER & BRAGA, 2005) Um dos fatores importantes para a reutilizao, juntamente com o processo e a organizao, a arquitetura de software (JACOBSON et al., 1997; BARROCA et al., 2005). A arquitetura de software, estrutura global de um sistema, pode ser definida como: a descrio dos elementos a partir dos quais os sistemas so construdos (componentes), as interaes entre estes elementos (conectores), os padres que guiam sua composio e as restries sobre estes padres (SHAW & GARLAN, 1996). A montagem da arquitetura deve permanecer independente de qualquer implementao ou tecnologia, utilizando apenas especificaes de componentes (ou, mais genericamente, de elementos arquiteturais) para representar os servios existentes na arquitetura (D'SOUZA & WILLS, 1999), (MENDES, 2002). Entretanto, identificar a melhor forma de realizar a decomposio de um sistema em elementos arquiteturais, definindo como eles devem interagir, uma tarefa difcil. No contexto da reutilizao de software, devemos ainda eleger estes elementos de tal forma que possam ser reaproveitados em outros sistemas de mesma natureza. PRIETO DIAZ (1987) define esta coleo de sistemas de mesma natureza, ou melhor, de aplicaes que compartilham problemas comuns, como um domnio, e o processo de identificao e organizao do conhecimento sobre um domnio de problema para suportar sua descrio e soluo, como anlise de domnio. A anlise de domnio, onde o conhecimento existente sobre o domnio estudado e um modelo de domnio gerado; o projeto de domnio, onde criada uma arquitetura que suporte os requisitos identificados na fase de anlise; e, a implementao do domnio, onde artefatos reutilizveis so implementados ou adquiridos para compor a arquitetura 1

criada, constituem as trs fases distintas da engenharia de domnio (ED). A ED, bem como sua vertente industrial, denominada linha de produtos de software (LPS), so mtodos de sistematizao para a reutilizao em um domnio especfico. A arquitetura resultante da fase de projeto da engenharia de domnio, especificada atravs de elementos especializados no domnio, generalizados para uso efetivo dentro do domnio e compostos em um padro de estrutura eficaz para a construo de uma famlia de aplicaes, definida como a arquitetura de referncia do domnio, ou DSSA (Domain Specific Software Architecture) (HAYES, 1994). A criao de uma arquitetura de referncia importante na engenharia de domnio, pois ela a base para a instanciao de aplicaes em um domnio de aplicao especfico.

1.1 - Motivao
Os mtodos de engenharia de domnio, em geral, possuem maior nfase na fase de anlise, dando pouco apoio s atividades relacionadas criao de arquiteturas de referncia (KANG et al., 1990; GRISS et al., 1998; BRAGA, 2000). O processo de criao de uma arquitetura de referncia requer grande esforo do engenheiro de domnio devido sua caracterstica de generalizao, devendo este recorrer a vrias fontes de informao, tal como especialistas no domnio, usurios, livros, documentao do domnio e, principalmente, as aplicaes existentes no domnio (i.e., sistemas legados1) (BRAGA, 2000). Segundo KANG et al. (1990), sistemas legados representam uma fonte de conhecimento essencial para a engenharia de domnio. Quando as arquiteturas dos sistemas legados compartilham caractersticas comuns, elas podem ser abstradas para uma arquitetura de referncia (BRAGA, 2000), que ser composta de elementos arquiteturais. Os elementos arquiteturais podem ser definidos como abstraes responsveis por representar as entidades que implementam as funcionalidades especificadas (ex. mdulo ou componente de software) (DIAS & VIEIRA, 2000) A anlise e comparao das arquiteturas de sistemas legados ajudam na tarefa de identificao dos principais conceitos e elementos do domnio. Pode-se dizer que os elementos arquiteturais que aparecem em todas as aplicaes so considerados mandatrios no domnio. Por outro lado, os elementos arquiteturais que aparecem

O termo "sistemas legados" um eufemismo para sistemas existentes nas empresas, geralmente antigos, mal documentados e mal projetados que devem ser mantidos por muitos anos, por serem crticos para o negcio de uma organizao (PRESSMAN, 2001).

somente em algumas aplicaes podem ser tidos como opcionais. Existem ainda determinados elementos arquiteturais que refletem a parametrizao da arquitetura em relao ocorrncia, ou no, de determinados componentes internos em sua configurao. Estes so chamados de pontos de variao. A caracterizao de elementos como "mandatrios", "opcionais ou "pontos de variao" reflete as variabilidades do domnio em questo (KANG et al., 1990). Mesmo sabendo que as aplicaes de um mesmo domnio apresentam elementos comuns, a identificao destas similaridades e diferenas no trivial. Para ilustrar estas dificuldades, tomemos como exemplo o domnio escolar. Podemos encontrar trs diferentes aplicaes que apresentam o mesmo elemento semntico, ex: Aluno, com diferentes nomenclaturas, a saber: Aluno, Estudante e Matrcula. Precisaramos, ento, de um glossrio de termos e relaes entre termos do domnio para identificar que Aluno, Estudante e Matrcula so sinnimos. Alm do problema de nomenclatura, existe ainda o problema de organizao e composio dos elementos arquiteturais nas diferentes arquiteturas. O mesmo elemento pode estar em diferentes locais nas arquiteturas e apresentar diferentes conexes. Na medida em que a complexidade e o nmero de aplicaes comparadas crescem, maiores so as dificuldades para se obter estas informaes de forma precisa. Trabalhos existentes na literatura, tais como os que apresentam processos de engenharia de domnio, algoritmos e ferramentas que identificam diferenas entre elementos descritos em arquivos XML (eXtensible Markup Language) (XML, 2007), conhecidos como algoritmos de "Diff", modelos UML (Unified Modeling Language) (OMG, 2007) e arquiteturas descritas em ADL (Architecture Description Language) foram inicialmente analisados. Os algoritmos de Diff para XML (KEIENBURG & RAUSCH, 2001; JIANG & SYST, 2003 ) tendem a fazer uma comparao puramente sinttica de elementos (tags) XML, gerando resultados sem nenhuma semntica para a criao de arquiteturas de referncia. Outra limitao encontrada que estes esto voltados para detectar as diferenas entre verses de modelos de uma mesma aplicao. As ferramentas analisadas que comparam modelos UML (KELTER et al., 2005; FUJABA, 2007) e as que comparam arquiteturas descritas em ADL, como por exemplo a xADL (DASHOFY et al., 2002) tambm apresentam o mesmo problema descrito anteriormente, pois comparam verses diferentes de um mesmo modelo e/ou arquitetura, ao invs de comparar modelos e arquiteturas que representam diferentes

aplicaes. Dessa forma, h uma tendncia em se apontar como diferentes, elementos arquiteturais que so semanticamente equivalentes.

1.2 - Objetivos
Tendo em vista os problemas citados anteriormente, essa dissertao tem como objetivo propor uma abordagem baseada na comparao de arquiteturas existentes em um domnio, tais como as recuperadas a partir dos sistemas legados, alm de um ferramental automatizado para tal abordagem, visando apoiar o engenheiro de domnio na criao de uma arquitetura de referncia (DSSA). A abordagem proposta neste trabalho, denominada ArchToDSSA, visa identificao de elementos arquiteturais "mandatrios", "opcionais" e "pontos de

variao" no domnio, procurando oferecer solues aos problemas mencionados referentes comparao de arquiteturas. O apoio automatizado obtido atravs da ferramenta ArchToDSSATool, implementada no contexto do ambiente de

desenvolvimento e reutilizao Odyssey (ODYSSEY, 2007). A abordagem proposta utiliza como fonte de informao modelos arquiteturais de sistemas existentes no domnio, sendo estes legados ou no. A categorizao de sistemas legados por domnio e a reconstruo de seus modelos arquiteturais, caso estes no estejam disponveis, no so objetivos desta dissertao em particular. No entanto, este trabalho est inserido em uma proposta mais ampla, denominada LegaToDSSA. Tal abordagem trata da recuperao de arquiteturas de sistemas legados, atravs de engenharia reversa esttica e dinmica, com o objetivo de criar arquiteturas de referncia em um domnio especfico. Maiores detalhes sobre esta abordagem completa podem ser encontrados em (VASCONCELOS, 2007). O presente trabalho assume como pr-requisito a existncia dos modelos arquiteturais dos sistemas do domnio, os quais devem ser orientados a objetos. Assume-se que as arquiteturas estejam descritas atravs de diagramas de pacotes e de classes da UML, linguagem esta escolhida pela sua grande aceitao e utilizao na comunidade de engenharia de software. Alm disso, tais arquiteturas podem ser representadas por arquivos XMI (XML Metadata Interchange), uma especificao adotada como mecanismo para possibilitar o compartilhamento de modelos UML criados em diversas ferramentas CASE (OMG, 2002b). XMI o formato padro de arquivo usado na importao/exportao de modelos baseados em MOF (Meta-Object Facility) (OMG, 2002a). Dessa forma, visando a possibilidade de tornar a ferramenta de 4

apoio genrica em relao a ambientes de desenvolvimento, adotou-se o XMI como forma de representao, ficando a ferramenta vinculada apenas verso do XMI utilizado. Com base nos arquivos XMI, as arquiteturas so ento comparadas e as informaes obtidas servem como base para a criao da arquitetura de referncia.

1.3 - Organizao da Dissertao

Esta dissertao est organizada em seis captulos. Neste primeiro captulo, de introduo, so apresentados o referencial terico bsico, bem como a motivao, os objetivos e a organizao do trabalho. No segundo captulo, so apresentados os conceitos sobre Arquitetura de Software, sua representao e mtodos de comparao entre seus elementos. No terceiro captulo, so descritos mtodos de Engenharia de Domnio e Linha de Produtos de Software, bem como suas abordagens para a especificao de uma arquitetura de referncia no domnio. A abordagem ArchToDSSA, proposta deste trabalho, apresentada no quarto captulo. No quinto captulo, detalhada toda a implementao da proposta, no contexto do ambiente de reutilizao Odyssey (ODYSSEY, 2007). A fim de caracterizar a eficincia da abordagem e sua implementao, foram realizados dois estudos de observao, apresentados no sexto captulo. No stimo e ltimo captulo, as contribuies e limitaes deste trabalho so listadas, bem como apontados os trabalhos futuros.

Captulo 2: Arquiteturas de Software

A complexidade e o tamanho de sistemas de software vm crescendo de forma acentuada nos ltimos tempos. A popularizao da Internet, a necessidade de competir em um mercado cada vez mais globalizado e a disponibilidade de hardware mais potente com preos mais acessveis esto dentre os fatores que impulsionam cada vez mais a demanda por software com maior nmero de recursos. Hoje em dia, comum que sistemas, at mesmo de pequeno porte, sejam capazes de acessar informaes e/ou servios disponveis de forma distribuda em diferentes pontos da rede mundial. Como exemplo, qualquer aplicao que precise disponibilizar a lista de CEPs e endereos do Brasil para seus usurios no precisa ter em seu projeto a implementao desta caracterstica, pois pode facilmente acessar tais servios atravs dos servidores dos correios, disponveis na Internet. Para facilitar o entendimento e construo de aplicaes complexas, pode-se dividi-las em partes. Alm disso, tecnologias disponveis, dentre elas CORBA (CORBA, 2007), j permitem a diviso de uma aplicao desta forma. Entretanto, definir exatamente quais sero as partes que devero compor cada diviso de um dado sistema, como elas devero interagir entre si, que funcionalidades devero fornecer e quais servios devero usar, no uma tarefa trivial. Para tentar responder s questes que surgem durante este processo de composio destes sistemas complexos e distribudos, uma nova disciplina vem ganhando cada vez mais importncia: a arquitetura de software. O objetivo deste captulo discutir alguns aspectos sobre arquitetura de software, considerados relevantes para o entendimento deste trabalho, mais especificamente a comparao entre arquiteturas de software. Para tal, o captulo est organizado da seguinte forma: na seo 2.1, definido o termo arquitetura de software e o seu papel atual na construo de sistemas; na seo 2.2, so apresentadas as vises arquiteturais e seus modelos; na seo 2.3, so mostradas formas de se descrever arquiteturas atravs de notaes formais, como ADLs; na seo 2.4, so discutidas as evolues e adaptaes pelas quais uma arquitetura passa ao longo da vida til do software e mecanismos que podem apoiar o acompanhamento dessas mudanas; finalmente, na seo 2.5, so feitas as consideraes finais do captulo.

2.1 - Definio
A especificao da arquitetura representa os primeiros passos para o projeto de qualquer sistema e produz entradas para a maioria dos passos subseqentes. Segundo a literatura, existem vrias definies para arquitetura de software, dentre elas podemos destacar: Descrio dos elementos a partir dos quais os sistemas so construdos (componentes), interaes entre estes elementos (conectores), padres que guiam sua composio, e restries sobre estes padres (SHAW & GARLAN, 1996). A estrutura de componentes de um programa/sistema, seus relacionamentos, princpios e diretrizes que governam seu projeto e evoluo ao longo do tempo (GARLAN & PERRY, 1995). A arquitetura de um sistema consiste da(s) estrutura(s) de suas partes (incluindo as partes de software e hardware envolvidas no tempo de execuo, projeto e teste), da natureza e das propriedades relevantes que so externamente visveis destas partes (mdulos com interfaces, unidades de hardware, objetos), e dos relacionamentos e restries entre elas (D'SOUZA & WILLS, 1999). Conforme descrito na seo anterior, os sistemas tm se tornado cada vez mais complexos. A representao destes sistemas como arquiteturas de software permite a abstrao dos detalhes internos das partes que os compem, permitindo um melhor entendimento de como se d a interao entre elas em um nvel mais abstrato. Em (WALLNAU et al., 2002), os autores ressaltam ainda que todos os aspectos estruturais de um sistema so definidos por sua arquitetura, incluindo como o software dividido em componentes, quais funcionalidades so mapeadas para estes componentes e como os componentes interagem entre si. A montagem da arquitetura deve permanecer independente de qualquer implementao ou tecnologia, utilizando apenas especificaes de componentes (ou, mais genericamente, de elementos arquiteturais) para representar os servios existentes na arquitetura (D'SOUZA & WILLS, 1999) (MENDES, 2002). A estrutura da

arquitetura define como montaremos ou encaixaremos as peas (componentes) do sistema. Muito embora possam existir diferenas na forma como a arquitetura de software definida, existe um consenso de que a nfase est na estrutura e relao entre os elementos de um sistema, ao invs de questes implementacionais como a estrutura de dados e algoritmos. 7

Em uma arquitetura, os componentes representam as unidades computacionais do sistema, e suas funcionalidades so acessadas atravs de suas interfaces, que definem um conjunto de assinaturas, isto , uma descrio sinttica de cada mtodo, seus parmetros, tipo, valores de retorno e possveis excees, que indicam como estes servios podero ser invocados. As interfaces, desta forma, definem a maneira como os componentes podero interagir com outros elementos arquiteturais. Os conectores definem as interaes entre os elementos da arquitetura. As possveis configuraes de uma arquitetura so criadas atravs das diferentes combinaes de componentes, interfaces e conectores.

2.2 - Vises Arquiteturais

Conforme pde ser observado, existe uma grande nfase na descrio de arquiteturas, destacando-se principalmente caractersticas estruturais como:

componentes, suas interconexes (conectores), configuraes e funcionalidades de cada componente. Muito embora a estrutura receba sempre maior destaque, existem outros aspectos que devem ser considerados durante a tarefa de se obter uma descrio arquitetural completa e compreensvel. Para o completo entendimento da arquitetura de um software, necessrio considerar no apenas a perspectiva estrutural, mas tambm aspectos como distribuio fsica, processo de comunicao e sincronizao, entre outros (CLEMENTS, 1994). Cada um destes aspectos deve ser tratado em uma diferente viso arquitetural. Em (PENEDO & RIDDLE, 1993), os autores afirmam que, uma arquitetura de software deve ser vista e descrita sob diferentes perspectivas (ou vises) e deve identificar seus componentes, relacionamento esttico, interaes dinmicas,

propriedades, caractersticas e restries. Uma viso consiste em um conjunto de modelos focados em um determinado aspecto da arquitetura, omitindo outros detalhes que so menos importantes neste contexto e serve como insumo para cada passo do processo de construo do software. Alguns autores definiram diferentes modelos de vises. O modelo de KRUCHTEN (1995), conhecido como modelo de vises arquiteturais 4+1 (The 4+1 View Model), organiza o modelo de vises em cinco vises concorrentes. Cada viso

mostra um conjunto especfico de informaes de acordo com o interesse dos diferentes stakeholders2.

Figura 2.1 - Vises do modelo 4+1

As cinco vises definidas por KRUCHTEN (1995) so: viso lgica (descreve aspectos estticos: componentes, conectores, interfaces), viso de processo (descreve aspectos de processo, incluindo concorrncia e sincronizao), viso fsica (descreve o mapeamento dos componentes e processos para o hardware e sua distribuio), viso de desenvolvimento (descreve a organizao esttica do software no ambiente de implementao) e viso de cenrios (descreve os casos de uso do sistema em sua arquitetura). As decises de projeto so capturadas em quatro vises, usando a quinta viso com objetivo de ilustrar e validar as demais. Tais vises so ilustradas na Figura
2.1

HOFMEISTER et al. (1999), por sua vez, dividem a descrio da arquitetura em quatro vises: viso conceitual (descreve componentes e conectores, mapeando caractersticas funcionais para a arquitetura), viso de mdulo (decompe o software em subsistemas - mdulos), viso de execuo (descreve os processos mapeados a partir dos mdulos, sua distribuio e taxa de uso), viso de cdigo (descreve como os mdulos da viso de mdulos so mapeados para arquivos de cdigo fonte e como os processos da viso de processos so mapeados para arquivos executveis).

Pessoas envolvidas ou interessadas em diferentes aspectos do software de acordo com seu papel exercido, exemplo: programadores, engenheiros de domnio, etc.

Conforme observado, tanto KRUCHTEN (1995), quanto HOFMEISTER et al. (1999), prevem a separao dos aspectos estticos e dinmicos do sistema em diferentes vises arquiteturais. Enquanto as perspectivas estticas descrevem os componentes e suas inter-relaes, perspectivas dinmicas tratam de aspectos como comportamento do sistema em sua arquitetura, sincronizao e concorrncia. A nfase deste trabalho so os aspectos estticos, i.e., a Viso Lgica proposta por KRUCHTEN.

2.3 - Representao Arquitetural

Para representar as diferentes perspectivas das arquiteturas, tanto no tocante s suas vises estticas, quanto s suas vises dinmicas, diagramas que fazem uso de diversos smbolos grficos costumam ser utilizados. De uma forma geral, a notao informal, onde comumente caixas descrevem componentes do sistema sendo representado, e linhas indicam a ocorrncia de alguma forma de comunicao, controle ou relacionamento entre estes componentes. Descries informais como estas, so ambguas e levam o leitor a interpretaes pessoais e conflitantes (PERRY & WOLF, 1992). O uso de formalizao para representar arquiteturas traz vrias vantagens para o processo de desenvolvimento de software. Algumas destas vantagens esto descritas em (PERRY & WOLF, 1992), (ABOWD et al., 1993),(CLEMENTS, 1996): o Compreenso: Como a arquitetura de software permite o entendimento de problemas complexos de uma forma mais abstrata, a diminuio das ambigidades leva reduo da distncia semntica existente entre as diferentes fases do processo, como por exemplo, requisitos levantados e projeto concebido. o Reutilizao: Alm do fato de que os conceitos representados pelas arquiteturas podem ser mais facilmente compreendidos por diferentes stakeholders, arquiteturas podem servir de base de conhecimento reutilizvel acerca de problemas e/ou requisitos especficos. o Evoluo: Permite um melhor entendimento das dimenses em que uma aplicao pode ser expandida, sem que ocorram problemas de violao e instabilidade de sua arquitetura.

A necessidade de se estabelecer essa formalidade na representao das arquiteturas fomentou a pesquisa nessa rea e culminou com a criao de linguagens 10

especializadas que permitem suas descries sem as ambigidades e os equvocos produzidos pela descrio informal. Dentre as abordagens propostas para representar arquiteturas, destacamos duas de interesse para os estudos deste trabalho: as linguagens de descrio da arquitetura (ADLs Architecture Description Languages), como a xADL (DASHOFY et al., 2001), e a utilizao da UML (Unified Modeling Language). As subsees a seguir detalham cada uma dessas abordagens.

2.3.1 - Representando Arquiteturas atravs de ADLs Alternativamente aos diagramas informais descritos anteriormente, uma variedade de linguagens de descrio de arquiteturas (ADLs) capazes de represent-las de uma maneira formal, vm sendo propostas. Essas linguagens tm por objetivo prover os arquitetos de software de notaes para a especificao e anlise das arquiteturas (MONROE et al., 1997). Embora as ADLs paream vir a resolver os problemas relacionados representao arquitetural, seu uso no vem sendo difundido de forma expressiva no projeto de software. Este problema se deve a uma srie de fatores, dentre eles: a complexidade das ADLs, a falta da compreenso da comunidade de engenharia de software acerca das abstraes arquiteturais, a indefinio do que de fato representa uma ADL e a no existncia de uma linguagem padro para a descrio de arquitetura de software (VASCONCELOS, 2004). Os principais elementos descritos em uma ADL so os componentes e conectores. Segundo (SHAW & GARLAN, 1996), esses elementos devem ser tratados de forma independente e considerados como sendo de primeira grandeza na descrio da arquitetura. Eles definem ainda seis reas que descrevem as principais caractersticas de uma ADL: 1. Composio: deve permitir que uma arquitetura possa ser descrita atravs da composio de componentes e conectores. Sistemas complexos devem poder ser divididos em partes menores para melhor entendimento ou devem poder ser construdos a partir da composio de elementos menores e mais gerenciveis. 2. Abstrao: deve ser possvel descrever em um alto nvel de abstrao as propriedades dos componentes e conectores, identificando seus comportamentos

11

sem que, para isto, haja a necessidade de se saber como estes elementos sero implementados. 3. Configurao: deve permitir a descrio da estrutura do sistema (sua topologia), independentemente dos elementos sendo estruturados. A configurao define como ser feita a correspondncia entre os componentes e os papis definidos pelos conectores. A conexo entre os componentes s pode ser estabelecida quando o protocolo de comunicao e os papis estabelecidos pelos conectores so compatveis com as expectativas dos componentes. 4. Reusabilidade: deve ser possvel a reutilizao de componentes, conectores e padres de relacionamento componente-conector (ex: configurao de topologia), em outras descries arquiteturais diferentes daquela para a qual os elementos foram originalmente especificados. 5. Heterogeneidade: deve permitir a combinao de diferentes configuraes arquiteturais em uma mesma descrio arquitetural e ainda deve permitir que seja possvel a combinao de componentes descritos em diferentes linguagens de programao. 6. Anlise: deve ser possvel a realizao de diversas anlises da arquitetura com base em suas descries, como por exemplo, simulao da arquitetura para anlise de seus atributos de qualidade ou anlise da evoluo de diferentes verses de uma mesma arquitetura.

Diferentes ADLs foram identificadas em (SHAW & GARLAN, 1996) e (MEDVIDOVIC & TAYLOR, 2000), dentre elas se encontram: Unicom, Aesop, Wright e Rapide. Recentemente uma nova ADL, que foi criada na universidade da Califrnia (Irvine), para a modelagem da arquitetura de sistemas de software, vem merecendo ateno: a xADL (DASHOFY et al., 2001). Esta ADL difere das demais por ser flexvel e extensvel suportando o uso de ferramentas comerciais para manipulao das arquiteturas (ex: visualizao de arquiteturas dentro do Microsoft Visio, atravs de plugins especficos).

2.3.2 - Representando Arquiteturas atravs de UML Muito embora as ADLs tenham sido criadas para descrever arquiteturas, vrios trabalhos na literatura vm fazendo o uso da UML (OMG, 2007) para este fim. A UML 12

representa a notao padro para sistemas orientados a objetos e seu uso em larga escala, tanto a nvel acadmico quanto industrial, um dos fatores que impulsionaram seu uso na descrio arquitetural. HOFMEISTER et al. (1999) demonstram um exemplo de uso da UML como notao para a representao da arquitetura. Para cada uma das vises definidas em seu modelo de vises, foi associado um tipo de diagrama ou elementos da modelagem UML: na viso conceitual, os componentes e conectores so representados por classes estereotipadas e os papis dos conectores so mapeados para os papis das associaes, as configuraes estticas do sistema so representadas pelos diagramas de classe, e os diagramas de seqncia demonstram as interaes entre grupos de componentes; na viso de mdulo, os mdulos so representados como classes estereotipadas e subsistemas como pacotes estereotipados, a decomposio dos sistemas em mdulos e suas dependncias so representadas por diagramas de pacotes e classes; na viso de execuo, classes estereotipadas representam a imagem run-time do sistema, a configurao esttica do sistema e suas comunicaes so representadas por diagramas de classes, e o comportamento dinmico de uma configurao pelo diagrama de seqncia; na viso de cdigo, executveis, arquivos binrios e de cdigo fonte, so representadas por classes estereotipadas, e tabelas so utilizadas para descrever o mapeamento entre elementos das vises de mdulo e de execuo para os elementos da viso de cdigo. Assim como em (HOFMEISTER et al., 1999), em (KRUCHTEN, 2000), a UML tambm utilizada para representar os elementos das vises arquiteturais, propondo um modelo orientado pelo seguinte mapeamento: para a viso lgica, ele utiliza os diagramas de pacotes e de classes da UML, onde componentes so representados atravs de pacotes e de classes e os conectores atravs dos relacionamentos de associao, composio, dependncia e generalizao; a viso de desenvolvimento representada atravs do elemento de modelagem componente e de pacotes da UML, onde cada componente da UML representa um mdulo do software (arquivo fonte, binrio, executvel etc.), e os subsistemas, que definem um conjunto de componentes, so mapeados para pacotes; a viso fsica representada pelo diagrama de implantao da UML, o qual capaz de retratar os processadores e suas respectivas cargas de processo; a viso de cenrios representada pelos modelos de casos de uso.

13

2.4 - Evoluo e Comparao de Arquiteturas

Na medida em que ocorrem mudanas no ambiente e que demandas por novas funcionalidades so geradas ao longo do ciclo de vida do software, revises nos seus requisitos se fazem necessrias. Recorrentes alteraes em requisitos, por sua vez, muitas vezes implicam em mudanas nas descries arquiteturais que os representam. Compreender o comportamento dessas mudanas intrnsecas ao processo de desenvolvimento de software pode ser muito til para a manuteno e o entendimento da evoluo dos sistemas. Como um exemplo, considere um caso em que o engenheiro A, responsvel por um dado projeto, acompanha sua evoluo e mantm sua descrio arquitetural atualizada. Por um dado motivo, o engenheiro A no pode mais trabalhar no projeto. Felizmente, possvel deslocar um outro engenheiro B, que trabalhava h alguns meses atrs, neste mesmo projeto, para a funo. O engenheiro B necessita de uma forma rpida e precisa para entender todas as mudanas ocorridas na arquitetura do projeto ao longo do tempo em que esteve ausente, no intuito de dar continuidade aos trabalhos. Muito embora seja possvel para o engenheiro B manualmente descobrir todas essas mudanas, esta tarefa acaba se tornando custosa, principalmente quando se trata de arquiteturas complexas, compostas por inmeros elementos arquiteturais. Automatizar a deteco de mudanas em arquiteturas pode, a princpio, sugerir a utilizao de algoritmos disponveis em larga escala na rea de gerncia de configurao3. Neste campo de pesquisa, algoritmos de Diff (comparao e deteco de diferenas) e Merge (fuso dos diferentes arquivos em um nico arquivo consolidado), capazes de detectar e propagar mudanas em diferentes verses de arquivos, tm estado em uso ao longo de anos (BUFFENBARGER, 1995). Entretanto, suas aplicaes diretas em arquivos que representam arquiteturas podem levar a resultados pouco satisfatrios (WESTHUIZEN & HOEK, 2002). Um dos motivos levantados por WESTHUIZEN e

HOEK (2002) o fato desses algoritmos operarem em arquivos texto, baseados numa comparao linha a linha. Desta forma, eles no esto a par da semntica especfica referente a arquiteturas e, portanto, oferecem pouca ajuda no tocante deteco de suas mudanas.
3

Disciplina que aplica procedimentos tcnicos e administrativos para identificar e documentar as

caractersticas fsicas e funcionais de um Item de Configurao, controlar as alteraes nessas caractersticas, armazenar e relatar o processamento das modificaes e o estgio da implementao e verificar a compatibilidade com os requisitos especificados. (IEEE, 1990)

14

A seguir, sero analisados algoritmos capazes de comparar arquiteturas descritas em diferentes formas: na seo 2.4.1, ser apresentada a comparao de arquiteturas atravs da gerncia de configurao; em 2.4.2 sero mostrados exemplos do funcionamento de algoritmos que detectam diferenas em diagramas UML (ferramenta Fujaba Tool Suite (FUJABA, 2007)); a seo 2.4.3 trata de algoritmos que usam o formato XML (ferramenta XML Diff and Merge Tool (IBM, 2007)) e, finalmente em 2.4.4, apresentada xADL Diff Tool ferramenta de comparao de arquiteturas da linguagem de descrio de arquiteturas xADL (DASHOFY et al., 2001) .

2.4.1 - Comparando Arquiteturas na Gerncia de Configurao Tradicionalmente, os algoritmos de diff e merge (BUFFENBARGER, 1995) existentes na rea de Gerncia de Configurao so baseados na comparao linha a linha de arquivos texto. Neste tipo de abordagem, mais tradicional, a linha

considerada a menor unidade de comparao. O algoritmo aceita dois arquivos como entrada e atravs da comparao linha a linha entre os dois arquivos, gera um arquivo de sada diff contendo uma lista ordenada das linhas que foram removidas, adicionadas ou substitudas. Este arquivo de sada, normalmente, um arquivo texto e pode ser visualizado atravs de uma ferramenta especfica. A ferramenta capaz de visualizar as diferenas entre os dois arquivos comparados e fundi-las, criando um terceiro arquivo que incorpore todas as mudanas detectadas, normalmente chamada de ferramenta de merge. Ela pode, por exemplo, receber como entrada os dois arquivos comparados mais o arquivo de diff resultante da comparao anterior e, atravs de interaes com o usurio, gerar um arquivo de sada que representa a fuso dos dois arquivos originais. Os conflitos detectados durante o processo de merge, por exemplo, quando existirem alteraes em uma mesma linha nos dois arquivos originais, so tidos como falhas ou so expostos para o usurio decidir e/ou alterar como dever ficar a linha resultante no arquivo a ser gerado. Estes algoritmos de Gerencia de Configurao tendem a ser independentes em relao s informaes contidas nos arquivos sendo comparados e, portanto, no fazem anlises na forma e significado de seus contedos. Muito embora eles sejam capazes de funcionar com arquivos texto que representem arquiteturas, o resultado no uma descrio arquitetural e no so capazes de lidar bem com as substituies de elementos arquiteturais neste nvel de abstrao (WESTHUIZEN & HOEK, 2002). 15

2.4.2 - Comparando Arquiteturas em UML A abordagem apresentada por KELTER et al, (2005) no ambiente FUJABA, prope a deteco das diferenas entre arquiteturas representadas atravs de diagramas UML. A motivao usada para o desenvolvimento do algoritmo est baseada na filosofia de desenvolvimento de software proposta pela OMG (Object Management Group): o MDA (Model Driven Architecture). Segundo KELTER et al (2005), o foco central do MDA o modelo do sistema de software que passa a assumir um papel fundamental no processo de desenvolvimento. No MDA, modelos podem ser transformados assumindo diferentes nveis de abstrao. Por exemplo: um modelo PIM (Platform Independent Model) pode ser transformado em um modelo PDM (Platform Dependent Model), para a gerao de cdigo fonte e posterior obteno de um modelo executvel (i.e., a aplicao). Seguindo esta filosofia, a representao de sistemas pode ser feita atravs de modelos UML, e as alteraes no software podem ser realizadas neste nvel mais alto de abstrao, para posterior transformao em modelos menos abstratos, como explicado. Em geral, o desenvolvimento de sistemas realizado em times, e no caso de se usar uma abordagem MDA, ser necessrio suporte deteco de diffs e merge de partes dos modelos UML modificados por diferentes membros destas equipes. O ambiente FUJABA prope no somente a comparao de arquiteturas, mas tambm a representao visual das diferenas detectadas entre os modelos atravs de diagramas UML. Nestes diagramas de diferenas, so mostrados todos os elementos resultantes da fuso dos modelos originais, sendo que cores so utilizadas para distino entre estes elementos. Exemplo: partes similares so apresentadas em preto, os elementos pintados de vermelho representam elementos existentes apenas no primeiro modelo e os verdes existem apenas do segundo modelo. Os modelos suportados so representados atravs de arquivos XMI (XML Metadata Interchange), conforme definido na seo 1.2, que so interpretados como rvores para a computao das diferenas. O arquivo de sada tambm no formato XMI, que contm informaes dos dois modelos comparados alm de informaes adicionais, calculadas atravs do seu algoritmo de Diff . O algoritmo de Diff de FUJABA foi dividido em duas fases. Na primeira fase, elementos similares so detectados entre os dois modelos comparados e, na segunda e ltima fase, as diferenas entre os dois modelos so calculadas e os arquivos de sada so gerados. Na escolha de elementos equivalentes, um dado elemento s pode ter 16

apenas um equivalente no outro diagrama. A abordagem permite que apenas dois modelos sejam comparados por vez e espera, preferencialmente, que os diagramas de entrada sejam provenientes da evoluo de modelos em uma abordagem MDA, ou seja, oriundos de uma abordagem de desenvolvimento top-down, com um certo nvel de similaridade. Como observado, esta soluo apresenta algumas limitaes que impedem o seu uso para a comparao de sistemas diferentes de um mesmo domnio, visto que nestes tipos de sistemas, natural a existncia de elementos equivalentes que possuem sintaxe e disposio totalmente distintas dentro das arquiteturas comparadas.

2.4.3 Comparando Arquiteturas em XML A ferramenta de Diff and Merge Tool, criada pela IBM (IBM, 2007), tambm permitem a deteco de diferenas entre arquivos em uma abordagem que no baseada na comparao linha a linha. Elas operam em arquivos baseados em tags XML e recebem como entrada um arquivo base e uma verso modificada do mesmo arquivo e produzem um terceiro arquivo XML, representando a juno dos dois arquivos processados. As diferenas so apresentadas atravs de uma ferramenta visual e o objetivo fazer o usurio resolver todos os conflitos. Os ns identificados como modificados, inseridos ou removidos so apresentados ao usurio, que deve escolher qual deles deve prevalecer: se o n procedente do arquivo base ou do arquivo modificado. A escolha feita pelo usurio em um n propagada para os ns descendentes. A comparao realizada atravs de uma identificao existente em cada n, baseada em seus atributos do tipo ID ou em seu contedo. No permitido que o usurio adapte ou modifique o algoritmo comparao. Esta caracterstica apresenta srias limitaes para a comparao de arquiteturas de software legado, visto que os IDs dos elementos de uma arquitetura dificilmente so iguais aos IDs dos elementos de uma outra arquitetura completamente diferente, o que inviabiliza uma tentativa de usar este algoritmo para este tipo de comparao.

2.4.4 Comparando Arquiteturas em xADL As deteces de mudanas em representaes arquiteturais atravs da xADL foram implementadas atravs de dois algoritmos (WESTHUIZEN & HOEK, 2002). O 17

primeiro descobre as diferenas entre duas arquiteturas em termos de adies e remoes de elementos, e o segundo algoritmo complementa o primeiro, calculando quais adies e remoes representam substituies, a fim de aumentar o grau de entendimento destas mudanas. O algoritmo de Diff recebe como entrada duas arquiteturas no formato xADL e gera um arquivo tambm no formato xADL (XML seguindo os esquemas da xADL). Este arquivo de sada contm elementos que representam as adies e remoes como descrito a seguir. Primeiramente, as inseres so calculadas da seguinte forma: cada elemento (componentes, conector...) da primeira arquitetura tem seu identificador nico comparado com cada elemento da segunda arquitetura. Caso o elemento na primeira arquitetura no seja encontrado na segunda, o mesmo adicionado ao arquivo diff de sada como uma insero. Em seguida, necessrio identificar os elementos que esto presentes somente na segunda arquitetura. Para tanto, verifica-se para cada elemento da segunda arquitetura se o mesmo existe tambm na primeira arquitetura. Caso no exista, o mesmo adicionado como uma remoo no arquivo diff . Caso exista, nada precisa ser feito. O arquivo diff resultante, gerado ao final deste processo, pode ser visualizado atravs de qualquer ferramenta capaz de visualizar XMLs. A visualizao deste arquivo permite identificar as diferenas entre as duas arquiteturas comparadas, em termos de inseres e remoes. Segundo WESTHUIZEN et. al (2002), simplesmente representar as diferenas entre duas arquiteturas em termos de inseres e remoes muitas vezes no suficiente para entender mudanas arquiteturais. Existem alteraes, por exemplo, que esto relacionadas com a substituio de um conjunto de componentes por outros componentes que devem ser entendidas. Estas substituies representam um conceito de mais alto nvel que uma lista de inseres e remoes e ajudam na obteno de uma maior compreenso das evolues arquiteturais. O algoritmo de deteco de substituies, implementado na xADL, recebe como entrada uma arquitetura e um arquivo diff e calcula os elementos e conjuntos de elementos substitudos. Ele opera, procurando por diferentes conjuntos de elementos que so cercados pelos mesmos elementos comuns. Baseado no fato de que, na substituio de um componente ou conector, um link teve que ser rompido e substitudo 18

por um novo link, o algoritmo usa links comuns entre elementos como potenciais pontos de partida para detectar substituies. Estes pontos de partida so usados para tentar identificar possveis substituies simples de elementos (um nico elemento) e tambm percorre as vizinhanas destes elementos identificando outros links comuns, a fim de determinar os limites (vizinhana), da possvel substituio sendo analisada. Desta forma, o algoritmo detecta no somente substituies simples de elementos isolados, mas tambm substituies de um conjunto de elementos de uma s vez. A Figura 2.2 mostra a remoo em insero de elementos arquiteturais.

Figura 2.2 - Comparao de arquiteturas em xADL. (Adaptado da documentao de Pladiff (DASHOFY et al., 2002))

A arquitetura da esquerda considerada a arquitetura original, ao passo que a da direita considerada sua evoluo. As mudanas na nova arquitetura so marcadas em vermelho. Para complementar o entendimento das mudanas arquiteturais na xADL, o algoritmo de merge recebe como entrada uma arquitetura e o arquivo diff e gera uma arquitetura resultante da fuso dos dois arquivos de entrada. Este processo feito atravs da iterao de cada elemento do arquivo diff. Elementos marcados como inseres so inseridos na arquitetura original, elementos marcados como remoes so removidos. Assim como no ambiente Fujaba, a comparao sempre realizada entre duas arquiteturas. Espera-se que as arquiteturas sendo comparadas possuam um mnimo de 19

elementos comuns para que bons resultados sejam alcanados. Para que o merge, em particular, possa ser executado entre um arquivo de diff e uma arquitetura, necessrio que existam elementos comuns entre esta arquitetura e as outras duas arquiteturas que originaram o arquivo de diff usado (WESTHUIZEN, et. al, 2002). Muito embora, os algoritmos de comparao da xADL possuam as funcionalidades apresentadas, para que possam ser usados na comparao de arquiteturas de sistemas legados, seria necessria que a comparao pudesse contemplar as diferenas arquiteturais existentes nestes tipos de sistemas. A implementao de um dicionrio de sinnimos, a ser usado na comparao, a possibilidade de se comparar mais de uma arquitetura ao mesmo tempo, estariam dentre as adaptaes necessrias para tratar estas diferenas. Neste sentido, para a comparao eficaz de arquiteturas de sistemas legados, faz-se necessria a criao de uma abordagem que atendam as estes requisitos.

2.5 - Consideraes Finais

Como pde ser observado, a representao de sistemas atravs de arquiteturas de software permite a abstrao dos detalhes internos das partes que os compem, e fornece um melhor entendimento de como se d a interao entre elas em um nvel mais abstrato. As descries dos elementos arquiteturais devem ser feitas atravs de notaes que imponham algum tipo de formalismo. Descries informais so ambguas e levam o leitor a interpretaes pessoais e conflitantes (PERRY & WOLF, 1992). Neste sentido, abordagens mais formais para descrever arquiteturas vm sendo criadas e usadas como, por exemplo: as ADLs e a UML. Alm da necessidade de se descrever arquiteturas de uma maneira mais formal, importante perceber que as arquiteturas de software representam requisitos em constante mutao. Soma-se, ainda, o fato de que o nmero de elementos arquiteturais e suas relaes podem atingir determinada escala em funo da complexidade do sistema e de suas evolues. Desta forma, necessrio que existam mecanismos capazes de ajudar o engenheiro na identificao e entendimento destas mudanas. Conforme mostrado, algoritmos foram desenvolvidos, nos contextos das diferentes notaes arquiteturais, com o intuito de descobrir e propagar estas mudanas. Os algoritmos de diff, de uma forma geral, foram implementados com o objetivo de descobrir as diferenas existentes entre duas verses de uma mesma arquitetura. E, 20

muito embora alguns destes algoritmos sejam capazes de perceber a substituio de um conjunto de elementos de uma verso arquitetural para outra, a forma de determinar se dois elementos so equivalentes , na maioria das vezes, feita atravs da comparao da similaridade entre os identificadores nicos que representam cada componente e/ou seus descendentes. Estas abordagens podem levar a resultados pouco eficazes, no contexto em que os nomes dos elementos arquiteturais (e/ou seus identificadores) apresentem diferenas significativas nas duas arquiteturas sendo comparadas. importante ressaltar que dependendo da origem das arquiteturas comparadas, ou da forma como foram evoludas, pode existir um nmero grande de elementos arquiteturais com nomenclaturas diferentes que possuam o mesmo papel semntico (elementos que representam o mesmo conceito ou caracterstica, sendo equivalentes, porm possuindo sintaxes completamente distintas). Para resolver este problema, este trabalho de mestrado prope uma abordagem que leva em considerao estas diferenas, tornando possvel no somente a comparao destes tipos de arquiteturas, mas a identificao de elementos que devero compor uma arquitetura de referncia do domnio.

21

Captulo 3: Engenharia de Domnio, Linha de Produtos e suas Abordagens para Apoiar a Especificao de Arquiteturas de Referncia
O conceito de reutilizao conhecido e empregado h muito tempo pela humanidade em diversas reas. O processo de criao de uma nova inveno ou tecnologia envolve muitas vezes a reutilizao e composio de diferentes partes previamente criadas. O automvel, por exemplo, criado atravs da composio de partes existentes como rodas, motor, cmbio etc. Analogamente, na Engenharia de Software, a reutilizao uma abordagem importante na criao de sistemas com maior qualidade e despendendo um menor esforo de desenvolvimento. Pode-se definir a reutilizao de software como sendo o processo de criao de sistemas de software a partir de software existente, ao invs de cri-lo do zero (SAMETINGER, 1997). Em (SAMETINGER, 1997), encontramos alguns benefcios trazidos pelo emprego da reutilizao no processo de criao de software: o Qualidade: o uso e reutilizao tende a eliminar erros em componentes4 de uma forma muito mais rpida do que em componentes usados somente uma vez; o Produtividade: menos cdigo necessrio ser implementado e ainda a curva de aprendizado suavizada na medida em que os mesmos componentes vo sendo reutilizados pelas equipes; o Desempenho: os custos com otimizaes passam a ser viveis, pois estaro sendo compartilhados com todos os projetos onde os componentes so reutilizados; o Robustez: na medida em que componentes so reutilizados vrias vezes, livres de bugs, maior a probabilidade de construo de produtos mais robustos; o Interoperabilidade: atravs do uso de componentes com interfaces bem definidas, testadas e conhecidas, pode-se construir mais facilmente

4 Um componente pode ser definido como uma unidade de software independente, que encapsula, dentro de si, seu projeto e implementao, e oferece servios, por meio de interfaces bem definidas para o meio externo (BARROCA et al., 2005).

22

sistemas que se comunicam de forma mais eficaz entre si; o Reduo de tempo de desenvolvimento e time-to-market: empregar a reutilizao de artefatos para construo do software reduz o tempo de criao de produtos e entrada no mercado; o Reduo da Documentao: reduo do volume de documentao a ser gerada atravs da reutilizao da documentao dos componentes reutilizados; o Reduo dos custos de manuteno: o nmero de partes do software que precisam ser mantidas diminui, pois o uso de componentes reutilizados e re-testados tendem a no apresentar defeitos. Alm disso, ainda que necessria, a manuteno de componentes reutilizveis pode ter seus custos distribudos entre os projetos que o usam; o Reduo dos tamanhos das equipes: existem muitos problemas de comunicao e produtividade associados com o crescimento das equipes de desenvolvimento; sabe-se que no verdade que ao se dobrar o tamanho da equipe, dobra-se a produtividade. Desta forma, manter as equipes menores atravs da reutilizao de cdigo pode atenuar estas falhas;

De acordo com WERNER E BRAGA (2005), para que a reutilizao de software seja efetiva, esta deve ser sistematicamente considerada em todas as fases do desenvolvimento, desde a anlise at a implementao. Abordagens como engenharia de domnio e linha de produtos de software visam esta sistematizao e fazem uso de arquiteturas de software como base para a reutilizao de artefatos que, de uma forma geral, devem estar compatveis com a estrutura estabelecida para o sistema. Neste contexto, o objetivo deste captulo apresentar conceitos de engenharia de domnio (ED) e linha de produtos de software (LPS), mostrando como estas abordagens podem ajudar na criao de arquiteturas reutilizveis em um domnio. Para tal, o mesmo est organizado da seguinte forma: na seo 3.1, definido o que um domnio, como ele pode ser organizado atravs da engenharia de domnio, quais fases devem ser contempladas para esta engenharia; na seo 3.2, so apresentados os conceitos sobre linha de produtos de software e suas principais atividades; na seo 3.3 e 3.4, so descritas, respectivamente, abordagens de engenharia de domnio e linha de produtos de 23

software, e seu apoio especificao de arquiteturas de referncia. Consideraes Finais so apresetnadas na seo 3.5.

3.1 - Engenharia de Domnio

Criar componentes de software que possam ser utilizados em outras aplicaes, alm daquelas para as quais eles foram originalmente definidos, um dos principais problemas na reutilizao de software (PRIETO-DIAZ & ARANGO, 1991) (BRAGA, 2000). Segundo PRIETO-DIAZ et al (1991), fundamental para a criao destes componentes reutilizveis, que exista, a priori, um processo de coleta de informaes sistemtico e confivel. O autor define este processo como sendo a anlise de domnio, cujo objetivo identificar e organizar o conhecimento a respeito de uma classe de problemas, de maneira a apoiar a descrio e soluo de tais problemas. O termo domnio utilizado para referenciar ou agrupar uma coleo de aplicaes, existentes ou futuras, que compartilhem caractersticas comuns, i.e., uma classe de sistemas que apresentam funcionalidades similares (WERNER & BRAGA, 2005; SEI/CMU, 2007). As informaes coletadas na anlise de domnio podem ser obtidas atravs de diferentes fontes de conhecimento como especialistas no domnio, livros, usurios no domnio e sistemas legados, e servem como subsdio para a criao de um modelo genrico, capaz de descrever as caractersticas, similaridades e diferenas dos sistemas analisados, o modelo de domnio. Estas diferenas e similaridades so conhecidas como variabilidade do domnio (OLIVEIRA, 2006). Refinamentos no modelo de domnio permitem a criao de componentes reutilizveis, que podem fazer parte de uma infra-estrutura de reutilizao. Todas estas atividades fazem parte de um processo denominado engenharia de domnio (WERNER & BRAGA, 2005) (ARANGO, 1994) Os artefatos reutilizveis gerados na ED formam a base para que a reutilizao ocorra. Sistemas especficos podem ser criados a partir destes artefatos e instanciados de acordo com os requisitos da aplicao sendo construda. Este processo denominado engenharia de aplicao (GRISS et al., 1998) (MILER, 2000). A engenharia de domnio e a engenharia de aplicao so processos complementares. Enquanto a engenharia de domnio tem por objetivo prover artefatos que sero reutilizveis, a engenharia de aplicao tem por objetivo a construo de aplicaes fazendo uso destes artefatos. Desta forma, a engenharia de domnio representa o desenvolvimento para reutilizao 24

enquanto a engenharia de aplicao representa o desenvolvimento com reutilizao. A

Figura 3.3

ilustra este ciclo complementar.

Figura 3.3- Ciclo de Vida da Engenharia de Domnio (Adaptado de (ATKINSON et al., 2002))

Em (BLOIS, 2006), mencionada uma seqncia de atividades que devem ser executadas na modelagem de um domnio. Tais atividades visam construo de artefatos que sero reutilizados por aplicaes derivadas do domnio: 1) a identificao de um domnio e seu escopo, bem como a captura de requisitos do domnio em que so representadas suas variabilidades; 2) a construo de um projeto adaptvel do domnio, atravs da especificao de uma arquitetura que represente os requisitos funcionais e no-funcionais do domnio, devidamente estruturados; 3) a definio de mecanismos para a traduo dos requisitos do domnio em sistemas criados a partir de artefatos reutilizveis. De uma forma geral, existe um consenso da comunidade a respeito das etapas da engenharia de domnio, a saber: anlise de domnio, projeto de domnio e implementao do domnio. (KANG et al., 1990), (GRISS et al., 1998), (SIMOS & ANTHONY, 1998), (BRAGA, 2000). 25

Os modelos de domnio produzidos durante a anlise de domnio devem refletir sua variabilidade, ou seja, as similaridades e diferenas entre as aplicaes do domnio. Mtodos de engenharia de domnio (ex. FODA e FeatuRSEB) buscam criar estes modelos para a representao das caractersticas comuns e variveis dentre estas aplicaes. Caractersticas, tambm conhecidas pelo seu nome em ingls features, so artefatos propostos por KANG et al. (1990) no contexto de reutilizao de software, mais especificamente em ED. Caractersticas representam as capacidades/abstraes do domnio obtidas por especialistas, usurios e a partir de sistemas j existentes, durante a fase de anlise do domnio (BLOIS, 2006). Do ponto de vista da variabilidade, um elemento no domnio pode ser classificado da seguinte forma (CLAUSS, 2001), (BOSCH, 2004), (OLIVEIRA, 2006): o Ponto de Variao: reflete a parametrizao no domnio de uma maneira abstrata e deve ser configurvel atravs de suas variantes; o Variantes: funes/conceitos disponveis que devem necessariamente estar ligados a um ponto de variao, atuando como alternativas de configurao de seu respectivo ponto de variao; o Invariante: elementos fixos, que no so configurveis no domnio;

Ortogonalmente, do ponto de vista da opcionalidade, um elemento do domnio pode ser classificado como: o Opcional: elemento que pode ou no pertencer a uma aplicao derivada de um domnio. o Mandatria: elemento que obrigatoriamente deve ser instanciado por todas as aplicaes derivadas de um domnio. O projeto de domnio tem como principal objetivo a construo de arquiteturas de software capazes de descrever os requisitos identificados durante a engenharia de domnio e representados atravs do modelo de domnio. Quando estas arquiteturas so especificadas atravs de elementos especializados no domnio, generalizados para uso efetivo dentro do domnio e compostos em um padro de estrutura eficaz para a construo de uma famlia de aplicaes, elas so definidas como a arquitetura de referncia de domnio, ou DSSA (Domain Specific Software Architecture) (HAYES, 1994). 26

A criao de uma arquitetura de referncia importante na engenharia de domnio, pois ela a base para a instanciao de aplicaes em um domnio de aplicao especfico. Um de seus principais objetivos propor uma soluo estruturada para a construo de uma famlia de aplicaes capazes de atender aos requisitos de um determinado domnio. Atravs da reutilizao de arquiteturas, o compartilhamento de idias, mtodos, componentes e conhecimento dentro de um conjunto de aplicaes similares, tornam-se mais efetivos para se obter nveis superiores de qualidade e produtividade durante o processo de construo de sistemas (XAVIER, 2001). Um dos motivos para que isto ocorra, segundo XAVIER, que as organizaes tm considerado suas arquiteturas como recursos que devem ser mantidos e reutilizados tanto quanto for possvel. Cada arquitetura criada representa uma grande quantidade de tempo e esforo especializado e as organizaes vem, como uma forma de maximizar estes investimentos, a reutilizao destas arquiteturas na construo de aplicaes similares. importante salientar a distino entre uma arquitetura de referncia de domnio e a arquitetura de uma aplicao. Enquanto a arquitetura de referncia de domnio criada na fase de projeto de engenharia de domnio para atender a toda uma famlia de aplicaes em um domnio, a arquitetura de uma aplicao a instncia (ou refinamento) de uma arquitetura de referncia de domnio, representando uma nica aplicao. Na etapa de implementao do domnio, os requisitos levantados durante as fases de anlise e projeto de domnio so transformados em um modelo implementacional, envolvendo a identificao, construo ou extrao de componentes reutilizveis no domnio.

3.2 - Linhas de Produto

O termo linha de produtos de software (LPS) vem sendo utilizado para definir um novo paradigma em engenharia de software, cujo propsito guiar organizaes no desenvolvimento para e com reutilizao. De fato, uma vertente da engenharia de domnio, cujo foco foi transferido para o mbito empresarial (LEE et al., 2002). Segundo o SEI (Software Engineering Institute) (2007), uma linha de produtos de software um conjunto de sistemas de software que compartilham um conjunto de caractersticas comuns e controladas, que satisfazem necessidades de um segmento de

27

mercado em particular, e so desenvolvidos a partir de artefatos (core assets), de forma predefinida. Os sistemas que integram uma LPS possuem, normalmente, caractersticas peculiares a um determinado domnio e so criados a partir de uma base de componentes comuns, moldados de acordo com as regras definidas pela arquitetura. A linha de produtos de software apresenta muitas semelhanas em relao ED . Ambas usam uma arquitetura como a base para seus artefatos reutilizveis. Ao passo que na engenharia de domnio, os componentes so organizados na arquitetura de referncia (DSSA), na linha de produtos de software, existe a arquitetura de linha de produtos (PLA-Product Line Architectures) que desempenha papel semelhante. A variabilidade tambm considerada na linha de produtos, e representa os pontos onde as caractersticas dos produtos que a compem podem se diferenciar. Os princpios de construo so os mesmos, uma vez que ambas representam arquiteturas de referncia ou frameworks para uma famlia de aplicaes, construdas com base nos requisitos de um domnio ou linha de produtos. O ncleo de artefatos forma a base do paradigma da linha de produtos de software (NORTHROP, 2002) e pode ser definido como o conjunto de elementos que sero reutilizados pelos sistemas a serem desenvolvidos. Nele esto inseridos artefatos como a arquitetura do software, componentes de software reutilizveis, modelos de domnio, requisitos, modelos de desempenho, cronogramas, oramentos, planos e casos de testes, planejamentos e descrio de processos (OLIVEIRA, 2006). As trs principais atividades envolvidas em uma linha de produtos de software so: o desenvolvimento do ncleo de artefatos, o desenvolvimento de produtos e o gerenciamento da linha de produtos, como ilustrado na Figura 3.4. No desenvolvimento do ncleo de artefatos, o principal objetivo desenvolver os artefatos necessrios envolvidos na linha de produtos de software. Entede-se por desenvolver um artefato, desde sua construo do zero, at a compra de terceiros. Os tipos de artefatos desenvolvidos tambm so variados, podendo

abranger desde componentes reutilizveis, arquiteturas de software, documentao de componentes at frameworks. De acordo com NORTHROP (2002), a arquitetura a pea chave de uma linha de produtos de software e deve ser comum a todos seus produtos relacionados. Em (CLEMENTS, 1999), o autor define os trs principais produtos resultantes das atividades desta fase como sendo: escopo da linha de produo, cujo objetivo definir o escopo da linha de produtos de software e os 28

produtos que a constituiro; artefatos

do ncleo, envolve todos os artefatos que

formam a base da linha de produtos de software: componentes reutilizveis (criados ou adquiridos de terceiros), arquiteturas de software, documentao de componentes, casos de teste, dentre outros; plano de produo, define como os produtos devero ser produzidos com os artefatos do ncleo.

Figura 3.4 Principais Atividades da Linha de Produtos de Software (Adaptado de (NORTHROP, 2002))

Durante o desenvolvimento de produtos, produtos so desenvolvidos a partir dos artefatos do ncleo, como ilustrado na Figura 3.5. Os artefatos mais comuns presentes no ncleo so (GIMENES & TRAVASSOS, 2002):

1. modelo do domnio; 2. framework de arquitetura de linha de produtos, que especifica a arquitetura genrica para todos os produtos; 3. componentes reutilizveis que sero integrados arquitetura para gerar um produto.

29

Figura 3.5 Desenvolvimento do Produto (Adaptado de (NORTHROP, 2002))

Em (OLIVEIRA, 2006), so citadas as principais atividades durante esta fase: anlise baseada no modelo de domnio, cujo objetivo analisar o modelo de domnio para determinar at que ponto os componentes disponveis na arquitetura genrica atendem as necessidades do cliente, e verificar se ser necessrio a criao de novos componentes no ncleo; instanciao da arquitetura do produto, objetivando a tomada de decises acerca de quais elementos do ncelo devero ser selecionados a partir da arquitetura genrica, para se chegar na arquitetura especfica do produto a ser desenvolvido; povoamento da arquitetura, cuja finalidade preencher a arquitetura especfica do produto com os componentes selecionado do ncleo; O gerenciamento da linha de produtos responsvel pelo sincronismo entre as equipes que criam os artefatos do ncleo e os que geram os produtos. O sucesso e viabilidade da linha de produtos de software depende muito das atividades realizadas nesta fase. Dentre estas atividades, pode-se destacar a organizao, superviso, integrao e documentao tanto do desenvolvimento do ncleo quanto do desenvolvimento de produtos.

30

3.3 - Abordagens de Engenharia de Domnio e o seu apoio Especificao de Arquiteturas de Referncia de Domnio (DSSAs)
O mtodo mais conhecido e considerado como precursor dos demais o FODA (KANG et al., 1990). Este mtodo est focado mais nas atividades relacionadas fase de anlise de domnio, contemplando atividades de anlise de contexto e a modelagem do domnio. No entanto, no existe ferramental apropriado para o desenvolvimento das atividades desta fase. O apoio construo de arquitetura de referncias previsto apenas de forma conceitual e a literatura disponvel trata desta questo de maneira superficial (BLOIS, 2006). Em (BRAGA, 2000), proposto um processo de engenharia de domnio cujo propsito unir os aspectos de reutilizao e entendimento do domnio que so providos pelos processos de engenharia de domnio existentes e o detalhamento do desenvolvimento de componentes, provido pelos processos de desenvolvimento baseados em componentes. Ainda que aborde o ciclo de vida completo de engenharia de domnio, observa-se que o foco do processo ainda na anlise de domnio (BLOIS, 2006). TRACZ et al (1994) descreveram os processos de criao e instanciao de arquitetura de referncias resultantes do projeto de pesquisa ARPA (METTALA & GRAHAM, 1992). Para a criao da arquitetura de referncia, so considerados trs elementos de informao principais: o modelo do domnio, os requisitos de referncia e a arquitetura de referncia. Os requisitos de referncia so utilizados pelo engenheiro de domnio para a criao da arquitetura de referncia, sendo divididos em requisitos funcionais, que definem o espao do problema, e no-funcionais, que restringem o espao-soluo. Neste mtodo, deve existir pelo menos uma arquitetura de referncia capaz de atender aos requisitos funcionais e no funcionais do domnio, muito embora, segundo os autores, nem todos os requisitos sejam satisfeitos por uma nica arquitetura, o que pode levar a existncia de mais de uma arquitetura de referncia para um dado domnio. O CBD-Arch-DE, mtodo de engenharia de domnio proposto por BLOIS (2006), busca oferecer um maior apoio etapa de projeto do domnio do que os outros mtodos de engenharia de domnio pesquisados (i.e. FODA (KANG et al., 1990), FORM (KANG et al., 2002), FODAcom (VICI & ARGENTIERI, 1998), FeatuRSEB (GRISS et al., 1998), ODM (SIMOS & ANTHONY, 1998) e Odyssey-DE (BRAGA,

31

2000)). Em sua abordagem, o CBD-Arch-DE mapeia o modelo de caractersticas do domnio para modelos de mais baixo nvel como casos de uso e modelos de tipos de negcio, o que permite a gerao de componentes de negcio, utilitrios e infraestrutura do domnio. A abordagem CBD-Arch-DE visa apoiar a criao de arquiteturas de referncia do domnio atravs de um processo de engenharia de domnio com suporte a DBC (Desenvolvimento Baseado em Componentes). A abordagem proposta por XAVIER (2001) visa a criao e instanciao de

arquiteturas de referncia em infra-estruturas de reutilizao, atravs da seleo de determinado padro arquitetural. Esta seleo realizada atravs da avaliao do relacionamento existente entre os requisitos de referncia e os padres arquiteturais existentes, que calculada pela ferramenta MENTOR, integrada ao ambiente do Odyssey. Como resultado, obtm-se um espao vetorial com os requisitos do domnio e os requisitos priorizados pelos padres arquiteturais. Com base nesse clculo, a ferramenta MENTOR indica os padres, em ordem de prioridade, mais adequados para guiar a soluo computacional para o domnio. Conforme pode ser observado, nem todas as abordagens pesquisadas de engenharia de domnio suportam a criao de arquitetura de referncias e, quando suportadas, todas tratam este problema atravs de um direcionamento top-down (i.e. da anlise para o projeto e implementao). Por outro lado, de acordo com KANG et al (1990), uma das fontes de informao essenciais para a engenharia de domnio so os sistemas legados disponveis no domnio. Sistemas legados so ricos em conhecimento sobre o negcio, e comum ser a nica fonte de informao disponvel para modelar o domnio. Desta forma, seria de grande utilidade para as empresas que desenvolvem software, a existncia de um maior apoio ao engenheiro de domnio na anlise, de forma sistemtica e, se possvel, com um certo grau de automao, das informaes destes sistemas legados. Estes sistemas representam grande esforo investido e so uma importante fonte de conhecimento para a construo de um modelo de domnio que possa servir como base para a criao de uma arquitetura de referncia.

3.4 - Abordagens de Linha de Produtos de Software e o seu apoio Arquitetura

O mtodo MAP (Mining Architectures for Product Line Evaluation), proposto em (STOERMER & OBRIEN, 2001), visa extrair e analisar variabilidades de 32

arquiteturas de sistemas de um mesmo domnio para gerar uma linha de produtos de software. Sua abordagem bottom-up para as tarefas de minerao das arquiteturas dos produtos e top-down para definir estilos arquiteturais e atributos para as arquiteturas extradas. Para suportar a criao de linha de produtos de software, STOERMER e OBRIEN ressaltam o quo importante que as tomadas de decises sejam baseadas em critrios tcnicos em detrimento de critrios no-tcnicos. Desta forma, dividiram as atividades do MAP em seis fases: preparao, extrao, composio, qualificao, avaliao e ps-avaliao. Na preparao, so considerados aspectos tcnicos e organizacionais, dentre eles, a avaliao da disponibilidade de recursos na empresa (ex.. desenvolvedores, engenheiros) e a seleo dos produtos mais representativos. Em seguida, na fase de extrao, so extraidos modelos de implementao a partir dos sistemas candidatos. Tais modelos so na verdade elementos dos cdigos-fonte (classes, arquivos,etc) e suas relaes. Alm do modelo esttico, aspectos dinmicos como tempo de execuo de funes e inter-relao entre os processos tambm so obtidos nesta fase. Os modelos da fase de extrao servem como entrada para a fase de composio, onde vises de componentes so criadas em um nvel de abstrao arquitetural. nesta fase que so identificadas estruturas para posterior deteco das variabilidades. Na fase de qualificao, os componentes e suas relaes, obtidas na fase de composio, so mapeados para estilos arquiteturais e atributos. Este mapeamento realizado atravs da consulta arquitetos e desenvolvedores, onde so avaliados os atributos de qualidade que motivaram a escolha de determinados estilos. A comparao entre as arquiteturas candidatas realizada durante a fase de avaliao. So identificadas as variabilidades entre os produtos que devero compor a linha de produtos, levando-se em considerao os componentes, suas relaes, funcionalidades especficas de clientes, protocolos, sistemas operacionais e plataforma de hardware dos produtos. Os autores argumentam que comparaes em nveis inferiores ao nvel de componentes no so adequadas devido ao fato de que os produtos candidatos terem sido desenvolvidos por diferentes equipes e, portanto, no possuem a mesma conveno de nomes e segmentao de componentes. Com base nas variabilidades identificadas durante a fase anterior, finalmente so realizadas as atividades de ps-avaliao. O objetivo desta fase decidir sobre a implantao ou no de uma linha de produtos na empresa, lembrando que os resultados obtidos na fase de avaliao podem ser usados como subsdios para sua concepo. 33

GOMAA prope um processo de desenvolvimento de linha de produtos, denominado PLUS (GOMAA, 2004). Este processo se inicia a partir da especificao dos casos de uso de uma linha de produtos de software, englobando o modelo de caractersticas, a modelagem dinmica por meio de mquinas de estado e de diagramas de interao, e tambm a, modelagem de classes, modelagem de contexto (i.e. objetos externos ao sistema e a sua comunicao com objetos da linha de produtos) e modelagem dos componentes de software na arquitetura, na qual um padro arquitetural deve ser adotado. A definio das variabilidades no mtodo PLUS se inicia no modelo de casos de uso, sendo disseminada para os demais modelos. Segundo o autor, o desenvolvimento iterativo e evolutivo, permitindo a adoo de uma abordagem de engenharia progressiva ou reversa. Entretanto, no que diz respeito engenharia reversa, e ao mtodo que seria utilizado na comparao de sistemas legados, ainda que o autor mencione algumas diretrizes que podem ser adotadas, no intuito de realizar a consistncia entre os modelos e deteco de variabilidades, fica clara a necessidade de um apoio mais efetivo. Uma desvantagem que pode ser observada no mtodo , por exemplo, a no-indicao sobre o modo como os modelos podem ser extrados dos sistemas existentes e noconsiderao de algumas questes, tais como diferenas de nomenclaturas entre os diferentes sistemas ou diferenas estruturais entre os modelos.

3.5 - Consideraes Finais

Neste captulo foram apresentados conceitos de Engenharia de Domnio (ED) e Linha de Produtos (LPS), bem como abordagens tanto de ED como LPS e seus respectivos suportes criao de DSSAs. A maioria das abordagens de ED e LP estudadas apiam a especificao de DSSAs no sentido da engenharia progressiva, i.e., de cima para baixo. Elas esperam que o modelo de domnio esteja definido para que a arquitetura de referncia seja criada. Entretanto, quando o modelo de domnio no est disponvel, como no caso de sistemas legados, necessrio que existam formas de se obter as arquiteturas destes sistemas (ex: engenharia reversa) e mtodos para que as mesmas sejam comparadas. Nestes casos, a DSSA pode ser criada a partir da identificao das similaridades e diferenas entre os elementos destas arquiteturas. Dentre as abordagens estudadas, que suportam a comparao de arquiteturas de software, no foram identificadas claramente, como so 34

tratados os problemas inerentes comparao de arquiteturas de sistemas diferentes, pertencentes a um mesmo domnio. Como mencionado anteriormente, tais arquiteturas tendem a apresentar um nmero grande de elementos arquiteturais com sintaxe distintas que possuem o mesmo significado. Neste contexto, proposta, neste trabalho, uma abordagem que visa a comparao de arquiteturas de sistemas pertencentes a um dado domnio, identificando suas similaridades, opcionalidades e variabilidades, com o propsito de auxiliar o Engenheiro de Domnio na criao de DSSAs.

35

Captulo 4: ArchToDSSA: Uma Abordagem para a Criao de Arquiteturas de Referncia de Domnio a partir da Comparao de Modelos Arquiteturais de Aplicaes
Nos captulos anteriores foram abordadas as vantagens da criao de arquiteturas de referncia no contexto da reutilizao de software. Foram ainda apresentados alguns requisitos desejveis para a criao destas arquiteturas de referncia, entre eles a necessidade da representao dos elementos arquiteturais sem ambigidades. Alm disso, foi mostrada a necessidade da criao de mecanismos que auxiliem o engenheiro de domnio na identificao, compreenso e propagao das mudanas que se refletem na arquitetura do software, sejam estas mudanas de requisitos ou diferenas entre diversas verses de uma mesma arquitetura, como diferenas de nomenclatura, por exemplo. Algumas abordagens foram descritas, mostrando que tais abordagens apresentam falhas na tarefa de comparar arquiteturas de sistemas legados em um domnio e, ainda, que muitas delas no possuem como objetivo final apoiar o engenheiro de domnio na construo de arquiteturas de referncia a partir dos resultados obtidos nestas comparaes. Neste sentido, o presente captulo vem apresentar a abordagem denominada ArchToDSSA, cujo objetivo apoiar o engenheiro de domnio na tarefa de criao de uma arquitetura de referncia, a partir da anlise das informaes disponveis em arquiteturas existentes em um domnio. Tais arquiteturas podem ou no ser provenientes de sistemas legados. Segundo KANG et al (2002), sistemas legados disponveis no domnio so uma das principais fontes de informao que podem ser usadas na criao de uma arquitetura de referncia em um domnio especfico (DSSA - Domain Specific Software Architecture). No entanto, a adoo da abordagem ArchToDSSA independe do fato de as arquiteturas serem provenientes de sistemas legados. O captulo est organizado da seguinte maneira: a seo 4.1 apresenta uma viso geral da abordagem proposta, ArchToDSSA; na seo 4.2, apresentada a primeira fase, i.e., a Deteco de Equivalncias e Opcionalidades. A segunda fase, Deteco de Variabilidades, apresentada na seo 4.3. Em seguida, na seo 4.4, apresentada a fase de Seleo de Elementos. Finalmente, na seo 4.5, so feitas algumas consideraes sobre a abordagem ArchToDSSA. 36

4.1 - A abordagem ArchToDSSA

ArchToDSSA uma abordagem que visa analisar arquiteturas j existentes - de sistemas legados ou no - de maneira comparativa, no intuito de identificar elementoschave que possam compor uma arquitetura de referncia em um domnio. No contexto desta dissertao, tais elementos so denominados elementos arquiteturais. Como mencionado na seo 1.1, elementos arquiteturais so, abstraes responsveis por representar as entidades que implementam as funcionalidades especificadas em um software. A abordagem direcionada para arquiteturas orientadas a objeto, descritas atravs de diagramas de pacotes e de classes da UML. A partir da anlise de abordagens da literatura, e de experincias prticas, podese definir alguns requisitos desejveis em uma abordagem para a especificao de uma arquitetura de referncia a partir de comparao de arquiteturas existentes, tais como: A comparao entre elementos arquiteturais deve levar em considerao o fato de que elementos diferentes, em diferentes arquiteturas, podem ter sido criados com sintaxes diferentes e mesma semntica, isto , dois ou mais elementos que tenham o mesmo significado podem ter sido criados com nomenclaturas diferentes. Para tanto, mecanismos como dicionrio e sinnimos, diviso das palavras em partes menores, e listas de partes de palavras a serem ignoradas, podem ser utilizados como recurso, para auxiliar no processo de comparao; Devem ser permitidas ao engenheiro de domnio certas escolhas, tais como: o nmero mnimo de arquiteturas envolvidas para se considerar equivalncia entre elementos, sua opcionalidade, pontos de variao e suas variantes; Pode ser definido se todos os elementos podero ser comparados entre si ou se somente elementos do mesmo tipo sero comparados (ex. comparao apenas entre classes, ou entre classes e pacotes); A arquitetura de referncia deve ser especificada de forma inteligvel, em uma representao que seja familiar ao engenheiro de domnio, onde possam ser identificados com clareza tanto os elementos arquiteturais que compem a arquitetura de referncia, quanto seus atributos de opcionalidade e variabilidade; Deve ser previsto um apoio ferramental, no intuito de melhorar a produtividade do engenheiro de domnio e reduzir o esforo humano.

37

Os requisitos mencionados acima sero abordados neste captulo, com exceo do ltimo, que trata do apoio ferramental, que ser explorado no prximo captulo. As arquiteturas dos sistemas legados podem ser extradas atravs de um processo de engenharia reversa aplicado sobre sistemas disponveis para anlise

(VASCONCELOS, 2007),(RICHNER & DUCASSE, 1999), (RIVA & RODRIGUEZ, 2002). Embora ArchToDSSA no contemple a extrao destas arquiteturas, ela est inserida em um contexto maior de abordagem de recuperao de arquiteturas de sistema legados para a criao de uma arquitetura de referencia, denominada LegaToDSSA (VASCONCELOS, 2007), onde esta etapa de extrao das arquiteturas contemplada. Assim, a extrao e comparao de arquiteturas para a criao de uma DSSA so abordadas de forma complementar, oferecendo um maior apoio ao engenheiro de domnio. Na ArchToDSSA, o conjunto de arquiteturas que sero analisadas recebe o nome de conjunto de trabalho (working set). importante ressaltar que o conjunto de trabalho no tem por objetivo representar todo o conjunto de aplicaes de um determinado domnio. Entretanto, espera-se que o engenheiro possa trabalhar com um conjunto o mais completo possvel. O processo sugerido contempla vrias tarefas divididas em trs fases distintas, a saber: 1. Deteco de Equivalncias e Opcionalidades; 2. Deteco de Variabilidades; 3. Criao da Arquitetura de Referncia. O resultado obtido em cada fase serve de entrada para a fase seguinte, como ilustra a Figura 4.6. Na primeira fase (Fase 1 Deteco de Equivalncias e Opcionalidades), o objetivo identificar as similaridades (equivalncias) e diferenas entre os elementos das arquiteturas analisadas, isto , as arquiteturas constantes do conjunto de trabalho. Dessa forma, possvel identificar elementos mandatrios e/ou opcionais no domnio, ou seja, as Opcionalidades dos elementos do domnio, conforme definido na seo 3.1. Na segunda fase (Fase 2 Deteco das Variabilidades), as equivalncias obtidas na Fase 1 so analisadas para que se possa definir as Variabilidades do domnio, isto , pontos de variao e suas respectivas variantes, (ver seo 3.1).

38

Figura 4.6 Abordagem ArchToDSSA

Finalmente, na ltima fase (Fase 3 Criao da Arquitetura de Referncia), so definidos elementos arquiteturais, oriundos de arquiteturas disponveis no conjunto de trabalho, que devero compor uma possvel arquitetura de referncia para o domnio. Vale ressaltar que possvel a criao de mais de uma arquitetura de referncia para o domnio, a partir da comparao de arquiteturas existentes. Alm disso, a arquitetura de referncia resultante da abordagem parcialmente especificada. Uma vez que a ArchToDSSA est inserida no contexto do ambiente Odyssey, optou-se por adotar a notao Odyssey-FEX (OLIVEIRA, 2006). A notao OdysseyFEX foi proposta mediante a identificao de falhas existentes, em diversas notaes da literatura, no que dizia respeito definio e representao de conceitos como elementos mandatrios e opcionais, pontos de variao, variantes e invariantes em um domnio. Ao longo das fases da abordagem ArchToDSSA, faz-se necessrio identificar tais elementos.

39

Para facilitar o entendimento da abordagem, so utilizadas como exemplo, ao longo de todo o captulo, arquiteturas do domnio de Telefonia Mvel, que ser brevemente explicado na seo 4.2. Cada uma das fases de ArchToDSSA discutida separadamente, nas sees 4.3, 4.4 e 4.5, respectivamente.

4.2 Descrio do Domnio de Telefonia Mvel

O domnio de Telefonia Mvel abrange conceitos e funcionalidades que podem estar presentes em um software desenvolvido para um telefone celular5. As trs arquiteturas do domnio de Telefonia Mvel, utilizadas como exemplo, so apresentadas na figura 4.7.

Arquitetura A

Arquitetura B

Arquitetura C

Figura 4.7 Arquiteturas do domnio de Telefonia Mvel

Os conceitos do domnio de Telefonia Mvel utilizados podem ser encontrados em (NOKIA, 2007)

40

Atualmente, pode ser encontrada uma grande diversidade de telefones celulares, que apresentam as mais variadas funcionalidades. No entanto, alguns conceitos e funcionalidades so intrnsecos e esto presentes a todos os tipos de software. Dentre estes podem ser citados: Campainha, que representa o toque do telefone, Agenda, onde so armazenados nmeros de telefone, e Caixa Postal, onde mensagens de voz so deixadas para o usurio. De acordo com as definies apresentadas em (OLIVEIRA, 2006), tais conceitos e funcionalidades so denominados mandatrios, isto presentes em todos os tipos de software para telefone celular. Alm disso, alguns conceitos, embora sejam mandatrios, apresentam alternativas, dando ao usurio a opo de escolha na hora da compra. A estes conceitos denomina-se ponto de variao, e a suas alternativas, denomina-se variantes. Como exemplo, tem-se o conceito de Caixa Postal. Este conceito representa um ponto de variao do tipo de caixa postal do aparelho celular, que tem como variantes as opes simplificada ou completa. Outros conceitos e funcionalidades so oferecidos no domnio de telefonia celular, mas podem ser encontrados em apenas alguns aparelhos, constituindo um diferencial. Tais conceitos so denominados opcionais. Dentre estes podem ser citados: Bluetooth, que uma tecnologia que permite que uma conexo sem fio de curto alcance seja estabelecida com outro dispositivo compatvel (celulares, laptops, cmeras digitais), Acesso Internet, Envio de mensagens de texto, como e-mails e recados, Jogos e Recebimento de toques musicais, que representa a funcionalidade de alterao do tipo de campainha, reproduzindo-se um toque especial, como uma msica conhecida, geralmente oferecido pela operadora de telefonia mvel. Alguns destes conceitos tambm podem apresentar alternativas, i. e., os conceitos opcionais tambm podem ser pontos de variao e/ou variantes. Como exemplo de pontos de variao, tem-se Recebimento de toques musicais e Jogos. Os toques musicais recebidos podem possuir variantes, i. e., podem ser do tipo monofnicos ou polifnicos. Toques monofnicos so toques musicais que a maioria dos aparelhos celulares pode reproduzir. O celular s precisa executar uma nota por vez para reproduzir um toque monofnico. Toques polifnicos so toques musicais que podem consistir em vrias notas de uma vez, reproduzidas por meio de um alto-falante em vez de uma campainha. So toques mais elaborados, com som muito prximo das msicas reais. No caso dos jogos, existe uma variedade deles que pode estar presente em um ou outro aparelho de telefone celular. Como exemplo, tem-se Car Racer, que

41

um jogo de corrida de carros, Snake, jogo cujo objetivo guiar uma cobra para que seja alimentada, jogos de Tnis, e outros.

4.3 - Fase 1: Deteco de Equivalncias e Opcionalidades

As atividades descritas na Fase 1 so retratadas na Figura 4.8, a seguir.

Figura 4.8 ArchToDSSA Fase 1

De acordo com a Figura 4.8, nesta fase, arquiteturas existentes so comparadas, e, seguindo alguns critrios de comparao descritos nesta seo, equivalncias so identificadas. Em seguida, mediante parmetros de opcionalidade aplicados sobre as equivalncias identificadas, so determinados os elementos opcionais e mandatrios que podero compor uma arquitetura de referncia de domnio. Para a realizao da primeira atividade, a deteco de equivalncias, necessrio introduzir primeiramente o conceito de equivalncia (match) e definir um algoritmo para sua identificao. O conceito de equivalncia, bem como a forma como as equivalncias e Opcionalidades so definidas, so explicados a seguir. Uma equivalncia um elemento identificado unicamente, que representa um elo de ligao entre elementos arquiteturais equivalentes, pertencentes a uma mesma arquitetura ou a arquiteturas diferentes. Neste contexto, o termo equivalente usado com a finalidade de identificar elementos arquiteturais distintos que possuam o mesmo significado. Em relao a uma equivalncia, assume-se, ainda que: a) o nmero de elementos pertencentes a uma equivalncia est compreendido no intervalo (2,...,n);

42

b) uma vez pertencente a uma equivalncia, um elemento no pode pertencer a outra. c) uma equivalncia possui reciprocidade, isto , se a1 equivalente a b1, ento b1 equivalente a a1, d) uma equivalncia possui transitividade, isto , se a1 equivalente a b1, e b1 equivalente a c1, ento a1 equivalente a c1. Na busca por elementos equivalentes, comparar aplicaes distintas em um mesmo domnio pode vir a ser uma tarefa mais rdua do que comparar verses diferentes de uma mesma aplicao. Isso porque, embora um conjunto de trabalho contenha aplicaes de um mesmo domnio, podem existir casos onde elementos arquiteturais equivalentes estejam descritos de forma diferente. Tal fato ocorre porque, apesar das aplicaes analisadas fazerem parte de um mesmo domnio, elas podem no ter sido necessariamente implementadas por uma mesma equipe, em um mesmo perodo, ou dentro de uma mesma empresa. Isso pode ocasionar uma grande variedade de elementos equivalentes, porm com nomes distintos, nas diferentes aplicaes analisadas. Alm disso, medida que cresce o nmero de aplicaes a serem comparadas e/ou o tamanho das arquiteturas extradas, cresce tambm o trabalho envolvido na atividade de comparao dessas arquiteturas. A identificao de equivalncias deve ser realizada analisando-se elementos arquiteturais nas diferentes arquiteturas, e para tanto, assume-se a utilizao da comparao dos nomes dos elementos arquiteturais. Dois ou mais elementos arquiteturais de mesmo nome seriam fortes candidatos a originar uma equivalncia. No entanto, quando os nomes no so idnticos, determinar a equivalncia de elementos arquiteturais passa a depender muito do conhecimento de um engenheiro de domnio. Sendo assim, assume-se na abordagem, alm da equivalncia por nomes idnticos, a utilizao de alguns critrios de comparao, como indicado na Figura 4.8, tais como: utilizao de um dicionrio de sinnimos, para nomes no-idnticos; diviso dos nomes a serem comparados em partes; utilizao de lista de palavras ou parte de palavras que podem ser ignoradas na comparao; comparao entre elementos do mesmo tipo; e nmero mnimo de arquiteturas equivalentes. Cada um desses critrios explicado na prxima seo.

43

4.3.1 - Critrios para Deteco de Equivalncias Os critrios para deteco de equivalncias na ArchToDSSA so provenientes da observao das diferenas que ocorrem nas diversas arquiteturas. Sendo assim, assumiu-se a utilizao de cinco critrios, a saber: 1. Utilizao do Dicionrio de Sinnimos; 2. Utilizao de Lista de Palavras Ignoradas; 3. Diviso de Nomes em Partes; 4. Comparao de Elementos do Mesmo Tipo; e 5. Nmero Mnimo de Arquiteturas Equivalentes. Cada um desses critrios explicado a seguir.

Critrio 1 Utilizao do Dicionrio de Sinnimos Na abordagem ArchToDSSA, o dicionrio de sinnimos consiste de uma lista ligando palavras com um mesmo significado, tal como em um dicionrio comum. Essa lista pode ser criada e alimentada pelo engenheiro de domnio com base em seu conhecimento sobre o domnio. As palavras do dicionrio podem no representar necessariamente o nome de elementos arquiteturais, mas assim como em qualquer dicionrio, ligar cadeia de caracteres equivalentes. Tomando como exemplo as Arquiteturas A e C da figura 4.7Error! Reference source not found., um engenheiro de domnio poderia, em seu dicionrio de sinnimos, afirmar que, no domnio de Telefonia Mvel, o nome Alarme seria equivalente ao nome Despertador.

Critrio 2 Utilizao de Lista de Palavras Ignoradas Assim como no dicionrio de sinnimos, o conhecimento do engenheiro de domnio usado para detectar a existncia de palavras a serem ignoradas no contexto da comparao de nomes. Cria-se, portanto, uma lista de palavras a serem ignoradas. Tomando como exemplo as Arquiteturas A e B da Figura 4.7, no caso de a palavra Gerente constar da lista de palavras ignoradas, os nomes GerenteJogos (Arquitetura A) e Jogos (Arquitetura B) passam a ser considerados equivalentes.

Critrio 3 - Diviso de Nomes em Partes Quando dois nomes (nome1 e nome2) so comparados, o primeiro passo decidir se cada nome ser tratado como um todo, ou se ser dividido em partes. Caso o 44

nome seja tratado como um todo, cada nome ser comparado integralmente. Tomandose como exemplo as Arquiteturas A e C da Figura 4.7 tem-se respectivamente, nome1 = GerenteAgenda, e nome2 = Agenda. Assim, ao se comparar os dois nomes

integralmente, tem-se uma situao de no-equivalncia. Do contrrio, se for decidido dividir os nomes em partes para efetuar a comparao, o nome ser dividido em partes. Seguindo esse critrio, um nome dividido em partes de tal forma que, quando uma letra maiscula, hfen, ou underscore for encontrado no meio da palavra, uma nova parte definida. Assim, no exemplo da Figura 4.7, no nome CaixaPostal podero existir duas partes - Caixa e Postal - e no nome GerenteCaixaPostal, trs partes -Gerente, Caixa e Postal. Dessa forma, aps dividir nome1 e nome2 em partes, deve ser verificado para cada parte, em cada nome, se a referida parte encontra-se na lista de palavras a serem ignoradas. Em caso afirmativo, tal parte deve ser retirada da lista de partes da palavra. Uma vez decidido se cada nome ter uma ou mais partes, o prximo passo comparar cada parte da lista de partes da palavra nome1 com cada parte da lista de palavras do nome2. Nesta comparao, uma parte ser considerada igual outra se sua cadeia de caracteres forem exatamente iguais, ou se suas partes tiverem sido consideradas equivalentes por meio do dicionrio de sinnimos. Assim, se o engenheiro criou uma entrada no dicionrio de sinnimos em que Idioma = Lngua, embora as cadeias de caracteres sejam completamente diferentes, tais elementos arquiteturais sero considerados equivalentes na comparao. Assume-se, no algoritmo utilizado, que, uma vez encontradas partes iguais em dois nomes, estas duas partes so marcadas e no podem mais ser envolvidas na comparao das partes seguintes dos mesmos nomes. Este critrio visa reduzir o nmero de falsos positivos durante a comparao. A Figura 4.9 exemplifica a idia. No primeiro exemplo, as cadeias de caracteres so consideradas iguais, pois cada parte da primeira palavra encontrou seu correspondente em uma parte disponvel da segunda palavra, isto , uma parte que ainda no tinha sido usada em uma comparao. No segundo exemplo, as cadeias de caracteres so consideradas diferentes porque, embora a ltima parte da primeira palavra (Ba) tivesse como correspondente a primeira parte da segunda palavra (Ba), esta j havia sido usada em uma comparao.

45

Critrio 4 - Comparao de Elementos do Mesmo Tipo Na comparao entre elementos arquiteturais, o engenheiro pode decidir se um elemento de uma arquitetura poder ser comparado com qualquer elemento de outra arquitetura (ex: classes com pacotes), ou se devero ser comparados somente elementos do mesmo tipo (ex: pacotes com pacotes, classes com classes).

Figura 4.9 Critrio de Comparao entre nomes

Assim, tomando-se como exemplo as arquiteturas da Figura 4.7, caso o engenheiro decida que somente elementos do mesmo tipo podem ser comparadas, ainda que existisse a palavra Gerente na lista de palavras a serem ignoradas, o pacote GerenteJogos, na Arquitetura A, no poderia ser considerado equivalente classe Jogos na Arquitetura B, pois a comparao no poderia ser feita entre pacotes e classes.

Critrio 5 - Nmero Mnimo de Arquiteturas Equivalentes Neste critrio, o engenheiro de domnio pode determinar qual o nmero mnimo de arquiteturas s quais elementos equivalentes devem pertencer para ser considerada realmente uma equivalncia.

46

Assim, tomando-se como exemplo as arquiteturas da Figura 4.7 caso o engenheiro tenha determinado que uma equivalncia existir realmente somente se forem encontrados elementos equivalentes nas trs arquiteturas, o elemento Alarme no seria considerado uma equivalncia, pois ele no consta na Arquitetura C, apenas nas Arquiteturas A e B. Do contrrio, se o nmero mnimo de arquiteturas determinado pelo engenheiro fosse 2, o elemento Alarme seria considerado realmente uma equivalncia. Levando em conta esses critrios, um algoritmo sugerido para a identificao de equivalncias, como descrito a seguir.

4.3.2 - Descrio do Algoritmo de Deteco de Equivalncias Sejam A, B, e C. arquiteturas que esto sendo comparadas, isto , participantes do conjunto de trabalho. Sejam a1, a2, ...an, b1, b2, ...bn e c1, c2, ..., cn elementos arquiteturais das arquiteturas A, B e C, respectivamente. Sejam ce1, ce2,...cen, elementos candidatos a equivalncias. Para detectar equivalncias, realizada uma comparao entre elementos das arquiteturas da seguinte forma: Escolhe-se o primeiro elemento disponvel, isto , que no faa parte de alguma outra equivalncia, em qualquer uma das arquiteturas do conjunto de trabalho. Define-se este elemento como a1 (primeiro elemento disponvel da arquitetura A). Percorrem-se todos os outros elementos da arquitetura A (a2, a3,..., an) e tambm cada elemento das outras arquiteturas do conjunto de trabalho que no estejam envolvidas em alguma equivalncia (b1, b2, b3, c1, c2, c3...). Para cada um destes itens percorridos, compara-se seu nome com o nome de a1. Esta comparao realizada seguindo os critrios explicados anteriormente. Caso a comparao indique que os dois elementos arquiteturais so equivalentes, e ainda no exista um candidato equivalncia ligado a esses elementos, criado ento ce1 candidato equivalncia 1. Esse candidato recebe o nome de um dos elementos comparados. importante perceber que o nome da equivalncia usado 47

apenas para identific-lo unicamente, permanecendo inalterados os nomes dos elementos arquiteturais conectados a ele. Assim que ce1 criado, o mesmo conectado a1 e ao outro elemento que foi considerado equivalente. O processo de procura por equivalentes de a1 continua e, ao final, tem-se ce1 conectado a todos os elementos equivalentes a1. A Figura 4.3 abaixo ilustra a idia:

Arquitetura A

Arquitetura B

Arquitetura C

Figura 4.10 Identificao de candidatos equivalncia

Seguindo o exemplo da Figura 4.10, a Arquitetura A foi percorrida, e foi encontrado o elemento Jogos como sendo a2. Assim, percorre-se os outros elementos da Arquitetura A, B e C, procura de elementos com o nome Jogos. Uma vez encontrados elementos arquiteturais equivalentes nas arquiteturas B e C, um candidato a equivalncia com o nome Jogos criado. Assim, no exemplo, ce1 = Jogos. Uma vez detectado ce1, necessrio saber ainda se ce1 pode ou no ser considerado uma equivalncia. Isto determinado pelo critrio Nmero mnimo de arquiteturas equivalentes, determinado pelo engenheiro de domnio. Por exemplo, se este nmero for igual a 2, para que ce1 seja considerado uma equivalncia, seria necessrio que ele ligasse elementos arquiteturais de pelo menos duas arquiteturas distintas. Como j mencionado na seo 4.3, na busca por elementos que podem ser equivalentes a um dado elemento, o elemento a ser procurado no pode ser participante de uma outra equivalncia. No entanto, seguindo-se apenas esta regra, elementos de diferentes tipos, como pacotes e classes, podero ser considerados equivalentes, a menos que o engenheiro de domnio tenha determinado o contrrio, na utilizao do critrio Comparar elementos do mesmo tipo, como explicado na seo 4.3.1

48

4.3.3 - Confirmao de Equivalncias Na descrio do algoritmo de deteco de equivalncias, foi tratado o processo de identificao das mesmas, No entanto, as equivalncias detectadas, so, na verdade, candidatos a equivalncias, isto , aps a deteco de tais candidatos, o engenheiro de domnio deve confirmar a validade da equivalncia. Dessa forma, proposta uma interao maior do engenheiro no processo, onde cada equivalncia deve ser confirmada antes de ser considerada vlida. Alm disso, a confirmao de uma equivalncia pelo engenheiro pode possibilitar que este alimente, caso julgue necessrio, o dicionrio de sinnimos. As equivalncias identificadas nesta atividade sero usadas na fase de deteco de Variabilidades (seo 4.4), portanto, quanto mais preciso for o resultado desta etapa, melhor ser o resultado na fase subseqente.

4.3.4 - Deteco da Opcionalidades atravs das Equivalncias identificadas Uma vez identificadas as equivalncias e, conseqentemente, os elementos equivalentes do conjunto de trabalho, previsto, nesta fase, que um elemento seja classificado quanto sua existncia na arquitetura de referncia a ser criada, como um elemento mandatrio ou opcional. Para tanto, o critrio Nmero mnimo de arquiteturas equivalentes volta a ser considerado, indicando que um elemento mandatrio no domnio, quando ele estiver presente em um certo nmero de arquiteturas distintas, igual ou maior, ao critrio estabelecido pelo engenheiro. Caso contrrio, o elemento ser considerado opcional. Dessa forma, para se chegar concluso de que um elemento mandatrio ou opcional, deve-se analisar se o elemento est conectado a alguma equivalncia. Em caso afirmativo, verifica-se se esta equivalncia abrange elementos de pelo menos N arquiteturas, sendo N igual ou maior que o nmero especificado no critrio Nmero mnimo de arquiteturas equivalentes. Caso abranja, ser considerado mandatrio, caso contrrio ser considerado opcional. importante ressaltar que, uma vez que a classificao de um elemento como mandatrio ou opcional depende do critrio Nmero mnimo de arquiteturas equivalentes, o fato de se identificar uma equivalncia no significa que foi necessariamente identificado se o elemento mandatrio ou opcional. Isto porque, o engenheiro pode, por exemplo, julgar necessrio ser mais criterioso, e decidir modificar 49

o critrio acima mencionado, determinando para ele um nmero maior de arquiteturas. Neste caso, a opcionalidade de cada elemento dever tambm ser redefinida pelo engenheiro, em funo das novas equivalncias identificadas.

4.4 - Fase 2: Deteco das Variabilidades

Como mencionado anteriormente, cada fase da abordagem ArchToDSSA fornece subsdios para a fase seguinte. De posse das equivalncias identificadas na Fase 1 da abordagem, d-se incio segunda fase, i.e. a de Deteco das Variabilidades, como exemplificado na Figura 4.11.

Figura 4.11 ArchToDSSA Fase 2

O objetivo desta fase identificar Pontos de Variao (VP Variation Points) e suas respectivas variantes. Para tanto, definido um algoritmo para essa identificao. So utilizadas, na abordagem, arquiteturas descritas atravs de diagramas de pacotes e de classes da UML, conforme j mencionado. Levando-se em considerao um dos requisitos apresentados na seo 4.1, que menciona a necessidade da representao de uma arquitetura de referncia de maneira clara quanto ao entendimento e identificao dos seus elementos, escolheu-se representar a arquitetura de referncia no formato XMI (XML Metadata Interchange). Uma vez que, ainda de acordo com os requisitos da seo 4.1, seria necessrio um ferramental de apoio, a escolha do XMI foi feita pensando-se na possibilidade de facilitar a intercomunicao entre diversas ferramentas, por meio desse formato de arquivo. Alm disso, a UML e o XMI possibilitam a identificao dos relacionamentos entre as classes.

50

No trabalho de OLIVEIRA (2006), foi definido um mapeamento da representao da opcionalidade e variabilidade entre modelos de caractersticas e modelos de classe. Desse mapeamento, foram definidas heursticas, obtidas atravs de estudos de caso, que estabelecem a relao de pontos de variao e suas variantes com interfaces e classes que participam de um relacionamento de herana, como apresentado na Tabela 4.1. Com base nestas heursticas, nesta fase da abordagem os relacionamentos de herana e implementao, especificamente, so de grande interesse para a descoberta de possveis pontos de variao e suas respectivas variantes. Isto porque, se uma dada interface ou superclasse possui equivalncia em um nmero mnimo de arquiteturas, ela pode ser considerada um ponto de variao, que pode estar presente na arquitetura de referncia.
Tabela 4.1 Heursticas de mapeamento de Variabilidades e Opcionalidades da notao OdysseyFEX (Adaptado de (OLIVEIRA, 2006))

Elemento Ponto de Variao (VP)

Heurstica Se existir, no modelo de caractersticas, um ponto de variao, pode existir no diagrama de classes uma classe ou interface que suporte tal elemento, utilizando-se do esteretipo <<vp>>. Se existir, no modelo de caractersticas, um ponto de variao, pode existir no diagrama de classes uma classe ou interface que suporte tal elemento, utilizando-se do esteretipo <<vp>>. Se existir, no modelo de caractersticas, um relacionamento do tipo Alternativo entre um ponto de variao e suas variantes, ento, deve existir no diagrama de classes um relacionamento de herana entre as classes que suportam tais caractersticas, se o ponto de variao estiver mapeado para uma classe. No caso de o ponto de variao estar mapeado para uma interface, deve existir no diagrama de classes um relacionamento de realizao entre as classes que suportam as variantes e a interface que suporta o ponto de variao.

Variante

Relacionamento entre VP e Variantes

Segundo a abordagem, medida que interfaces ou superclasses so consideradas como pontos de variao, suas respectivas subclasses ou implementaes definem possveis configuraes nestes pontos especficos e representam as variantes associadas a esses pontos especficos. Naturalmente, esta afirmao no vlida para todos os casos, nem to pouco significa que no possam ser encontrados pontos de variao e variantes em outras 51

estruturas das arquiteturas presentes no conjunto de trabalho. No entanto, um ponto de partida para a definio de um algoritmo capaz de sugerir pontos de variao e suas respectivas variantes. 4.4.1 - Deteco de Pontos de Variao (VPs) e suas Variantes Assim como na identificao de equivalncias, para nortear o processo de identificao de pontos de variao, foram definidos alguns critrios, descritos a seguir: Critrio 1: Nmero mnimo de arquiteturas equivalentes para se considerar uma superclasse como um ponto de variao. Indica em quantas arquiteturas uma dada superclasse deve possuir equivalncia para que seja considerada como um ponto de variao. Critrio 2: Nmero mnimo de arquiteturas equivalentes para se considerar uma interface como um ponto de variao. Indica em quantas arquiteturas uma dada interface deve possuir equivalncia para que seja considerada como um ponto de variao. A seguir descrito o algoritmo sugerido para a identificao de pontos de variao na abordagem ArchToDSSA. 4.4.1.1 - Descrio do algoritmo de Deteco de Pontos de Variao (VPs) e Variantes Sejam A, B, e C arquiteturas que esto sendo comparadas, isto , participantes do conjunto de trabalho. Sejam a1, a2, ...an; b1, b2, ...bn; e c1, c2, ..., cn elementos arquiteturais das arquiteturas A, B e C, respectivamente. Para a deteco de pontos de variao, deve-se proceder da seguinte forma: Em uma arquitetura A, escolhe-se a primeira superclasse ou interface disponvel, isto , uma superclasse ou interface que no seja ponto de variao nem equivalente a um elemento que j seja ponto de variao. Como utilizada a notao Odyssey-FEX, o elemento escolhido tambm no poder ser variante nem equivalente de um variante, uma vez que um elemento no pode, pela notao, ser simultaneamente VP e variante. Define-se este elemento como a1 (primeiro elemento disponvel da arquitetura A). Percorrem-se todos os outros elementos da arquitetura A (a2, a3,..., an) e tambm cada elemento das outras arquiteturas do conjunto de trabalho que sejam interfaces ou superclasses e estejam disponveis (b1, b2, b3, c1, c2, c3...).

52

Para cada um destes itens, verifica-se se existe equivalncia com a1. Convm ressaltar que tal informao est disponvel como resultado da Fase 1. Se houver equivalncia, ento o total de arquiteturas que possuem elementos equivalentes a a1 contabilizado. Ao final das iteraes, possvel identificar em quantas arquiteturas distintas a referida superclasse ou interface possui equivalentes. Levando-se em considerao o tipo do elemento, isto , uma interface ou superclasse, e os critrios Nmero mnimo de arquiteturas equivalentes para se considerar uma superclasse como um ponto de variao ou Nmero mnimo de arquiteturas equivalentes para se considerar uma interface como um ponto de variao, possvel determinar se o elemento vai ou no ser considerado um ponto de variao. Repete-se o processo para outros elementos disponveis. Ao final, tem-se uma lista de pontos de variao e seus respectivos elementos (superclasses ou interfaces) equivalentes nas arquiteturas analisadas. Passa-se agora deteco de variantes. Para tanto, percorre-se os elementos identificados como ponto de variao. Para cada interface identificada como VP, seleciona-se suas implementaes como variantes associadas. Para cada superclasse identificada, seleciona-se suas subclasses como variantes associadas A Figura 4.12 e Figura 4.13 ilustram, respectivamente, a idia da deteco de VPs e de variantes.

Arquitetura A

Arquitetura B Figura 4.12 Identificao de Pontos de Variao

Arquitetura C

Arquitetura A

Arquitetura B Figura 4.13 Identificao de Variantes

Arquitetura C

53

No exemplo da Figura 4.12, a Arquitetura A foi percorrida e encontrada a superclasse Jogos como sendo a2. Percorreu-se ainda as arquiteturas B e C, encontrando em ambas a superclasse Jogos como sendo elementos equivalentes a a2. Assim, no exemplo, definido o elemento Jogos como um ponto de variao. No exemplo da Figura 4.13, so percorridas as arquiteturas A, B e C em busca das superclasses que foram selecionadas como ponto de variao. Em cada arquitetura, e para cada ponto de variao, foram selecionadas suas subclasses como variantes. Assim, os elementos Snake, Car Racer, Pacincia, PinBall e Black Jack so selecionados como variantes na arquitetura de referncia. Alm de definir procedimentos e um algoritmo para esta atividade, permitido que o engenheiro de domnio defina os pontos de variao como melhor lhe convier, no fazendo restries quanto s suas escolhas. Na prtica, isto significa que o engenheiro pode determinar os pontos de variao com base unicamente no seu conhecimento do domnio, sem seguir qualquer critrio sugerido pela abordagem proposta. Isto se deve ao fato de que o principal objetivo da abordagem auxiliar e em alguns casos sugerir ao engenheiro opes para a criao de uma arquitetura de referncia, e no impor restries ao seu trabalho.

4.5 - Fase 3: Criao de uma Arquitetura de Referncia

A terceira e ltima fase da abordagem tem como objetivo selecionar elementos para a criao de uma arquitetura de referncia de domnio (DSSA). Ao final das duas primeiras fases da abordagem ArchToDSSA, tem-se como resultado informaes sobre que elementos arquiteturais, pertencentes s arquiteturas do conjunto de trabalho, so relevantes para esta fase de criao. A Fase 3 apresentada pela Figura 4.14, a seguir. Na Fase 1, foram identificadas as equivalncias e, conseqentemente, as Opcionalidades dos elementos no domnio. Na Fase 2, as equivalncias identificadas na Fase 1 foram utilizadas para a determinao da Variabilidades dos elementos. importante ressaltar a interao do engenheiro em ambas as fases, de forma que, ao entrar na fase de criao, os elementos identificados, bem como suas Opcionalidades e Variabilidades, estejam de acordo com seu entendimento sobre o domnio.

54

Figura 4.14 - ArchToDSSA Fase 3

Na Fase 3, os elementos selecionados so, como j mencionado, os elementos que vo compor a arquitetura de referncia sugerida. Porm, no s os elementos so selecionados, mas tambm os relacionamentos entre eles. Para evitar a existncia de relacionamentos incompletos na arquitetura de referncia, isto , a inexistncia de algum dos elementos envolvidos em uma relao, prope-se a determinao de uma arquitetura-base. A arquitetura-base nada mais do que uma das arquiteturas presentes no conjunto de trabalho que, uma vez escolhida pelo engenheiro, ter todos os seus elementos e relacionamentos incondicionalmente presentes na arquitetura de referncia. Uma vez selecionada a arquitetura-base, a idia que o engenheiro possa ter fcil acesso a cada elemento arquitetural das outras arquiteturas do conjunto de trabalho, principalmente aos identificados na fase anterior. Tal acesso deve permitir que se selecione, ou se deixe de selecionar, elementos para a criao da arquitetura de referncia (elementos da arquitetura-base devem estar permanentemente selecionados) bem como a identificao imediata de cada propriedade identificada nas fases anteriores. No caso da Opcionalidade, deve ser possvel ao engenheiro modificar a propriedade mandatrio/opcional, caso necessrio. Os elementos de outras arquiteturas, que no so a arquitetura-base, quando selecionados, no carregam seus relacionamentos, cabendo ao engenheiro especificar os relacionamentos existentes entre esses elementos na arquitetura de referncia. A exceo a essa regra so os elementos que foram classificados como variantes, na Fase 2, que devem ser includos em seus respectivos ponto de variao, quando estes so selecionados para compor a arquitetura de referncia. Todos elementos que no fazem parte da arquitetura-base so classificados como No-Definidos. 55

Depois de selecionados os elementos arquiteturais e seus relacionamentos, importante que a arquitetura de referncia gerada seja acessvel de alguma forma ao engenheiro de domnio. Optou-se por sua representao no formato XMI, visando permitir que a arquitetura de referncia criada possa ser manipulada por ferramentas externas. Para auxiliar o engenheiro na atividade de seleo de elementos, so previstos alguns critrios, como descritos na prxima seo. 4.5.1 - Critrios de Seleo de Elementos para a Arquitetura de Referncia Alguns critrios devem ser observados pelo engenheiro, quando da seleo dos elementos: o Caso o elemento selecionado j possua um elemento equivalente na arquitetura-base, o engenheiro no deve inclu-lo na arquitetura de referncia uma vez que j possui equivalente na mesma; o Caso o elemento esteja contido em algum espao de nomes6 (i. e. elemento que contm outro elemento, ex: pacote contendo classes) tambm marcado para seleo, ento, o mesmo pertencer ao mesmo elemento na arquitetura de referncia; o Caso o elemento no esteja contido em um espao de nomes selecionados, mas este espao de nomes possua um equivalente que esteja sendo selecionado, o referido elemento passar a ser contido pelo espao de nomes equivalente; o Caso o elemento no esteja contido em espao de nomes selecionado, nem exista equivalente ao referido espao de nomes, o elemento dever estar em um pacote situado na raiz da arquitetura de referncia; o Caso a relao entre o espao de nomes e o elemento nele contido seja do tipo herana ou implementao, esta mesma relao dever ser mantida na arquitetura de referncia; o As variantes das arquiteturas no pertencentes arquitetura-base, identificadas na Fase 2, devem ser selecionadas. Estas variantes devero ser inseridas no ponto de variao equivalente ao seu ponto de variao na arquitetura-base e devero manter o mesmo tipo de relacionamento existente com o seu ponto de variao (i.e. herana ou implementao).
6

Do ingls Namespace, conforme definido na UML (OMG, 2001).

56

o Todo elemento que no pertena arquitetura-base classificado como no definido, os demais so classificados como definidos. o Na representao da arquitetura de referncia criada, no formato XMI, as propriedades de Opcionalidade e Variabilidade so expressas por meio de etiquetas, que possuem um nome e um valor (i.e., tagged values), da seguinte forma: o Opcionalidades (determinada por meio de equivalncias identificadas na Fase 1): nome = "Opcionalidade"; valor = "opcional" ou "mandatrio" o Variabilidades (definidas na Fase 2): nome = "Variabilidade"; valor = "Invariante" ou "Variante" ou "Ponto de Variao" o Elementos no pertencentes arquitetura-base (definidos na Fase 3): nome = "No Definido"; valor = "verdadeiro" ou "falso"

4.6 - Consideraes Finais sobre a Abordagem ArchToDSSA

Este captulo apresentou a abordagem ArchToDSSA, cujo objetivo apoiar a criao de arquiteturas de referncia em um determinado domnio. Foram apresentadas as trs fases da abordagem, que utiliza os conceitos da notao Odyssey-FEX (OLIVEIRA, 2006), identificando opcionalidades e variabilidades. Na primeira fase da abordagem, foi visto que deteco das Opcionalidades pode ser obtida atravs da identificao de equivalncias e da anlise da abrangncia das mesmas nas arquiteturas do conjunto de trabalho. Os resultados obtidos nesta fase so usados nas fases seguintes. Esta fase pode ainda ser incrementada atravs da modificao ou adoo de novos critrios para o algoritmo de deteco de equivalncias. Como exemplo, poderia ser proposta a definio do percentual de arquiteturas em que um elemento deve estar como equivalente para ser considerado mandatrio. Outra caracterstica interessante que pode ser introduzida no algoritmo o clculo de equivalncia entre elementos, tomando-se como base elementos relacionados (vizinhana). Por exemplo, verificar se um pacote equivalente a outro pacote com base

57

no percentual de equivalncia entre suas respectivas classes.

Neste ltimo caso,

critrios de pesos e proporcionalidade de equivalncia poderiam ser estabelecidos. Na Fase 2, a qualidade da deteco da Variabilidades, conforme observado, depende muito da preciso com que a identificao das equivalncias e, conseqentemente, das Opcionalidades realizada. O conjunto de heursticas estabelecidos na fase 2 (e em todas as fases da abordagem) no pretende ser completo. O conjunto inicial de heursticas derivado da notao Odyssey-FEX, porm, diferentes heursticas podem ser incorporadas medida que estudos forem realizados e o devido feedback for obtido, por meio de interaes com o engenheiro. Na Fase 3, apesar do processo de seleo ser flexvel, interessante que o engenheiro manipule os elementos selecionados em algum ambiente de modelagem antes de se obter a arquitetura de referncia final. Isto porque, nesta definio inicial, a abordagem no contempla a seleo de relacionamentos entre elementos no pertencentes arquitetura-base, e nem sugere a remoo de elementos da arquiteturabase, deixando a cargo do engenheiro tais decises. Isto se fez necessrio para que no existam relacionamentos incompletos na arquitetura de referncia. Assim como em um framework, onde uma arquitetura bsica estabelecida e componentes vo sendo introduzidos e aprimorados em sua arquitetura, foi estabelecida uma seqncia de fases, com o objetivo de direcionar o engenheiro na criao de uma arquitetura de referncia. Uma vez que, em todas as fases, todas as atividades sugeridas requerem uma interao do engenheiro, pode-se inferir que tal interao acaba por exercer grande influncia sobre os resultados obtidos. Estas fases podem sofrer evolues na medida em que estudos so realizados, a abordagem utilizada, e novas heursticas so consideradas em cada fase. um trabalho extenso e iterativo. Ao longo das evolues, o processo vai ganhando maturidade. Muito embora exista espao para evolues, a abordagem trata os problemas levantados, que no foram resolvidos pelas abordagens estudadas no captulo anterior. Ela trata, por exemplo, da comparao de arquiteturas de sistemas legados, onde elementos sintaticamente diferentes representam o mesmo conceito, introduzindo para isto conceitos com dicionrio de sinnimos e lista de palavras ignoradas. Alm disto, define um mtodo claro para identificao da variabilidade e apoiar o engenheiro na seleo de elementos que devero compor a DSSA.

58

Ainda no contexto desta dissertao, foi realizada a implementao de uma ferramenta de apoio abordagem, denominada ArchToDSSATool, conforme descrito no prximo captulo.

59

Captulo 5: ArchToDSSATool: Uma Ferramenta de Apoio para a Abordagem ArchToDSSA

No Captulo 4 foi apresentada a abordagem ArchToDSSA, cujo objetivo apoiar o engenheiro de domnio na criao de arquiteturas de referncia a partir de arquiteturas j existentes, como as de sistemas legados. A ferramenta ArchToDSSATool foi implementada no sentido de automatizar o apoio abordagem proposta, viabilizando a sua prtica, em sistemas existentes, como os sistemas legados de um domnio. Ela foi desenvolvida no contexto do projeto Odyssey (ODYSSEY, 2007), que visa o desenvolvimento do ambiente de reutilizao de mesmo nome. A ferramenta ArchToDSSATool pode ser utilizada de forma isolada ou integrada ao ambiente Odyssey, sendo que, neste ltimo caso, os resultados gerados pela mesma contribuem ao apoio engenharia de domnio atualmente provido pelo ambiente. A ArchToDSSATool apresentada neste captulo. Assim, partindo desta introduo, o restante do captulo est organizado da seguinte forma: a seo 5.1 d uma idia geral do ambiente de reutilizao Odyssey, ao qual a ferramenta ArchToDSSATool pode ser integrada; a seo 5.2 descreve a arquitetura da ferramenta desenvolvida; a seo 5.3 explica sua utilizao; e as consideraes finais so apresentadas na seo 5.4.

5.1 - O ambiente Odyssey

O ambiente Odyssey (ODYSSEY, 2007) representa uma infra-estrutura de reutilizao baseada em modelos de domnio que engloba tanto o apoio linha de produtos (LPS) e engenharia de domnio (ED) quanto engenharia de aplicao (EA). O Odyssey apresenta uma srie de ferramentas e caractersticas que podem apoiar a utilizao da abordagem proposta, como por exemplo as ferramentas de modelagem, que envolvem tanto os modelos da UML, necessrios para contemplar a modelagem da arquitetura de referncia gerada pela abordagem ArchToDSSA, bem como a implementao da notao Odyssey-FEX (OLIVEIRA, 2006), que suporta os atributos de opcionalidade e variabilidade no domnio. Alm disso, outras funcionalidades do ambiente Odyssey podem ser acessadas por meio de plugins, i.e., ferramentas que podem ser acopladas ao ambiente atravs de um mecanismo de carga dinmica, como descrito em (MURTA et al., 2004). Nesse 60

mecanismo, uma lista de plugins fica armazenado no servidor da COPPE, e as ferramentas so baixadas e acopladas ao ambiente sob demanda. Muito embora possa funcionar como um plugin do ambiente Odyssey, a ferramenta ArchToDSSATool tambm pode ser executada de forma independente. As arquiteturas de referncia criadas partir da ferramenta, so exportadas para arquivos no formato XMI. Mecanismos internos detectam automaticamente caso a ferramenta tenha sido executada como plugin. Neste caso, possvel uma maior interao com o ambiente Odyssey e opcionalmente pode-se optar por visualizar os elementos exportados diretamente no ambiente de modelagem do Odyssey. Conforme j mencionado na seo 4.1, a ferramenta ArchToDSSATool se insere na proposta mais ampla descrita em (VASCONCELOS, 2007), servindo de apoio ao processo proposto, cuja nfase a recuperao de arquiteturas baseada em engenharia reversa dinmica. No entanto, implementada de maneira a permitir a avaliao de arquiteturas de forma independente da proposta de VASCONCELOS (2007). Detalhes da implementao da ferramenta so explorados nas prximas sees.

5.2 - Arquitetura da Ferramenta ArchToDSSATool

Seguindo a diviso da abordagem em fases, a ferramenta, em sua arquitetura, tambm foi dividida em pacotes distintos. Uma viso geral da sua arquitetura apresentada na Figura 5.15 A ferramenta representada pelo pacote Phases, que contm trs pacotes principais, representando as trs fases: Matches, VP e Export. Cada um destes pacotes contm classes que implementam as funcionalidades de cada fase. Em cada pacote, classes foram nomeadas com os prefixos BUS e GUI. O termo BUS indica que a classe est relacionada com as regras de negcio (business) explicadas no captulo anterior (regras de comparao...), enquanto o termo GUI (Graphical User Interface) representa a interface grfica com a qual o usurio interage. Esse artifcio foi utilizado no intuito de facilitar a identificao das implementaes relacionadas com cada tipo de funcionalidade e interao.

61

Figura 5.15 Arquitetura da ArchToDSSATool

A Figura 5.16 apresenta o pacote Matches. O pacote Matches contm classes que contemplam toda a funcionalidade relacionada deteco de equivalncias. Na interface grfica da ferramenta, foi efetuada uma diviso em duas grandes reas: uma lista com as equivalncias sugeridas e rvores para exibir as arquiteturas analisadas. De acordo com esta diviso de interface, foram criados dois conjuntos de classes dentro do pacote, as classes MatchLists e as classes MatchTrees. O primeiro conjunto usado na manipulao da lista de equivalncias e o segundo trata das arquiteturas exibidas em forma de rvore.

Figura 5.16 - Pacote Matches

Dentro do conjunto de classes MatchList, temos a classe BUSMatchList, e a classe GUIPnlMatchList. O pacote MatchList apresentado na Figura 5.17.

62

Figura 5.17 Pacote MatchList

O conjunto MatchTrees, apresentado na Figura 5.18, possui, analogamente, duas classes: BUSMAtchTrees, que trata das regras de negcio deste conjunto (regras de comparao, alimentao do dicionrio,...), e GUIPnlMatchTree que trata da interface e interao com o usurio. As duas classes implementam funcionalidades que permitem que o usurio selecione manualmente elementos arquiteturais equivalentes, a deteco automtica de equivalncias, dentre outras atividades.

Figura 5.18 Pacote MatchTrees

O segundo pacote, VP, segue a mesma lgica de diviso existente no pacote Matches, ou seja, a interface tambm foi dividida em duas grandes reas: a lista de pontos de variao (VPs) e as rvores contendo elementos arquiteturais candidatos a variantes do VP selecionado. As classes deste pacote tambm foram divididas em dois conjuntos VPList e VariantTrees, como mostra a Figura 5.19.

63

Figura 5.19 Pacote VP

O conjunto VPList, mostrado na Figura 5.20, representado pelas classes BUSVPList e GUIPnlVPList. A classe GUIPnlVPList trata das funcionalidades referentes a interao com o usurio no que diz respeito lista de pontos de variao e a BUSVPList implementa a maioria das regras de negcio envolvidas nesta interao (regras para a deteco de pontos de variao, variantes, etc, conforme explicado no captulo anterior).

Figura 5.20 Pacote VPList

No segundo conjunto de classes do pacote, o conjunto VariantTrees, mostrado na Figura 5.21, a classe GUIPnlVariantTrees trata das interaes do usurio no que diz respeito a seleo de variantes, enquanto a classe BUSVariantTrees implementa as suas respectivas regras de negcio. Neste pacote existem, ainda, duas classes auxiliares: BUSCheckVPListItem e BUSCheckVPListItems que so usadas em BUSVPList para permitir a seleo e confirmao de pontos de variao (VPs).

64

Figura 5.21 Pacote VariantTrees

O terceiro pacote, Export, representando a terceira e ltima fase da abordagem, da mesma forma que nas outras fases, contm dois conjuntos de classes que se referem s duas principais partes da interface desta fase, como mostra a Figura 5.22.

Figura 5.22 - Pacote Export

No primeiro conjunto, o ExportTree, a classe GUIPnlExportTrees trata da iterao com o usurio, no que diz respeito seleo da arquitetura-base, bem como seleo de elementos arquiteturais fora da arquitetura-base, que devero compor a arquitetura de referncia. A classe BUSExportTrees trata das regras de negcios definidas no captulo anterior, que dizem respeito a seleo de itens para a composio da arquitetura de referncia, como mostra a Figura 5.23.

65

Figura 5.23 - Pacote ExportTree

No segundo conjunto, o ExportItemsInfo, mostrado na Figura 5.24, a classe GUIPnlExportItemsInfo implementa funcionalidades que permitem ao usurio visualizar e/ou redefinir a opcionalidade de cada elemento arquitetural, e visualizar a variabilidade detectada na Fase 2. As classes BUSExportItemsInfo e

BUSExportItemInfo auxiliam GUIPnlExportItemsInfo em suas atribuies. Nelas so encontrados por exemplos os algoritmos que exportam os elementos que iro compor a arquitetura de referncia para o formato XMI ou diretamente dentro do Odyssey.

Figura 5.24 Pacote ExportItemsInfo

Alm dos pacotes principais, envolvendo as fases da abordagem, foram criados outros pacotes contendo classes e estruturas auxiliares, como as classes GuiSupport, Components e Utils, que permitem o encapsulamento de determinadas tecnologias e a reutilizao de componentes bsicos e de interface. O pacote denominado Componentes, por exemplo, define uma srie de componentes usados na interface, tais como listas com checkbox, rvores com checkbox, grupo de radiobuttons, etc.

66

O pacote GUISupport, por sua vez, implementa partes da interface de uso geral, que no necessariamente esto atreladas a uma determinada fase. Como exemplo, tem-se as telas de configurao dos parmetros da ferramenta, o dicionrio de sinnimos e a lista de palavras a serem ignoradas. As classes deste pacote so de uso menos genrico que as classes encontradas no pacote Componentes e, muito embora sejam utilizados de uma forma geral na aplicao, esto voltadas especificamente para atender s funcionalidades desta ferramenta especfica. Finalmente, no pacote Utils, foram implementadas classes que representam estruturas de dados, suporte manipulao genrica de janelas da interface e o encapsulamento de repositrios MOF. A ferramenta ArchToDSSATool possui ainda uma classe que representa seu ponto de entrada, isto , a classe que permite o acesso s funcionalidades da ferramenta, que a ArchToDSSAFacade. Esta classe contm uma instncia da classe FormMain, que, por sua vez, contm as instncias das classes contidas nos pacotes que implementam as trs fases. A classe FormMain representa a interface principal da ferramenta. Alm desta, existe a classe FormStandAlone, que usada apenas para instanciar ArchToDSSAFacade e permitir que a ferramenta seja executada de forma independente do ambiente Odyssey. A Figura 5.25 ilustra a idia:

Figura 5.25 Ponto de entrada da arquitetura da ArchToDSSATool

67

A integrao com o Odyssey feita atravs da classe ArchToDSSATool. Uma vez acionada, esta classe cria uma instncia de ArchToDSSAFacade para executar a ferramenta como um plugin do Odyssey. A exemplo dos outros plugins do Odyssey, a classe ArchToDSSAFacade implementa a interface Tool, apresentada tambm na Figura
5.25,

a fim de que suas opes de menu sejam disponibilizadas no Odyssey. Essa

interface especifica servios que disponibilizam opes de menu e menu popup, por exemplo, alm de fornecer os servios para o acesso do Odyssey s ferramentas baixadas. A interface grfica, bem como o processo de utilizao da abordagem atravs da ferramenta ArchToDSSATool, so apresentados a seguir.

5.3 - Utilizao da ArchToDSSATool

No captulo 4 foi apresentado como requisito para uma abordagem de apoio criao de uma arquitetura de referncia um apoio ferramental, a fim de viabilizar sua prtica. Como requisito desejvel para este ferramental, pode-se destacar a possibilidade de se ter uma ferramenta que seja executada integrada a um ambiente de modelagem, porm no dependente desta. Nesse sentido, a ferramenta ArchToDSSATool pode ser acessada das duas formas: internamente ao ambiente Odyssey, ou de forma independente. Sua execuo de forma stand alone, isto , independente do ambiente Odyssey, se d atravs de um arquivo executvel, como mostra a Figura 5.26 a seguir.

Figura 5.26 - Acesso ferramenta ArchToDSSATool atravs de arquivo executvel

68

Para a sua execuo integrada ao ambiente, deve-se executar o Odyssey e acessar o menu File

New Domain

Na tela de modelagem de domnio, Model

Environment, do Odyssey, tem-se acesso ferramenta atravs do Menu Tools ArchToDSSATool, como mostra a Figura 5.27 abaixo.

Como pode ser visto na Figura 5.27, o ambiente de modelagem do Odyssey possui, do lado esquerdo da tela, as diversas vises complementares pelas quais um domnio pode ser modelado. Cada elemento criado na rvore da esquerda apresenta suas caractersticas detalhadas no lado direito da tela. Na Figura 5.27 mostrado, do lado direito da tela, parte do diagrama de classes do domnio de Telefonia Mvel.

Figura 5.27 Acesso ferramenta ArchToDSSATool atravs do Odyssey

Ao ser acionada, pode-se observar as trs fases da ferramenta, representadas por abas, como ilustra a Figura 5.28

69

Fase 1 Deteco de Opcionalidade Fase 2 Deteco de Variabilidade

Fase 3 Seleo e Exportao de Elementos

Figura 5.28 - Fases da abordagem ArchToDSSA

Assume-se, ainda, que as arquiteturas existam em arquivos no formato XMI e que elas sejam carregadas para o funcionamento da ferramenta. Dessa maneira, o primeiro passo carregar as arquiteturas que se deseja analisar, isto , montar o conjunto de trabalho. Isso pode ser feito a travs do menu File Select Architectures, como mostra a Figura 5.29. A tela de seleo permite que sejam escolhidas arquiteturas existentes, no formato XMI, para que sejam comparadas na ferramenta.
Arquiteturas que sero analisadas Seleciona as arquiteturas listadas para anlise Renomear Conjunto de trabalho

Figura 5.29 - Definio do Conjunto de trabalho

70

Uma vez selecionadas as arquiteturas, iniciada a execuo de cada fase prevista na abordagem, como detalhado nas subsees a seguir. 5.3.1 - Primeira Fase A aba Matching Arch Elements da tela principal da ferramenta ArchToDSSATool representa a primeira fase da abordagem, como mostra a Figura 5.30. As arquiteturas selecionadas e seus respectivos elementos arquiteturais so apresentados no formato de rvore. Uma das configuraes da ferramenta permitir que as arquiteturas sejam exibidas duas a duas, lado a lado, no intuito de facilitar a comparao entre seus elementos, ou, caso o engenheiro prefira, as arquiteturas podem ser exibidas em uma coluna nica. Tal configurao pode ser acessada pelo menu View

Archs in Two Columns. Todas as arquiteturas ficam disponveis em cada uma das

colunas para seleo.

Elementos Seleci Arquiteturais a ona as serem arquiteturas comparados

.
Figura 5.30 - ArchToDSSA - Primeira Fase

Conforme descrito no captulo anterior, a primeira atividade a ser realizada a identificao e criao de equivalncias (matches). Uma vez que o objetivo da ferramenta oferecer apoio automatizado ao engenheiro de domnio, o algoritmo de deteco de equivalncias foi implementado de forma a sugerir tais equivalncias ao 71

engenheiro automaticamente. Essa gerao automtica leva em considerao os critrios citados no captulo anterior, como o uso de dicionrio de sinnimos e da lista de palavras ignoradas, bem como o critrio para comparao de nomes atravs da diviso em partes, comparao de elementos do mesmo tipo e nmero mnimo de arquiteturas equivalentes, conforme descrito na seo 4.2.1. Tais critrios podem ser configurados acessando-se o menu Tools Options , como mostra a Figura 5.31.
Alimentao do dicionrio de sinnimos a partir de equivalncias vlidas

Sugerir equivalncias a partir do dicionrio de sinnimos

Forar comparao somente de elementos do mesmo tipo

Nmero mnimo de arquiteturas equivalentes

Dividir palavras em partes para comparar nomes

Figura 5.31 - Configurao de critrios para deteco de equivalncias

Acessando o menu Actions

Generate

All Suggested Matches, a lista de

equivalncias candidatas gerada, conforme o algoritmo sugerido na seo 4.2.2, como mostra a Figura 5.32. importante ressaltar que os menus da ArchToDSSATool so sensveis ao contexto, isto , nesta fase do processo, o menu Actions reflete a ao da gerao automtica de equivalncias, porm, o menu Actions pode refletir outros tipos de aes, em funo da fase em que o usurio se encontra. Embora automatize a deteco das equivalncias, a ferramenta permite que o engenheiro defina uma equivalncia manualmente. Os passos so os seguintes: 1. O engenheiro deve primeiro criar uma equivalncia, acessando o boto Adicionar novo match - na barra de botes; 2. Deve ento escolher um elemento de uma arquitetura e buscar por elementos equivalentes ao elemento escolhido. Os elementos encontrados devem ser -

72

selecionados atravs da caixa de seleo do item (checkbox do item na rvore); 3. Repete-se este procedimento at que todas as equivalncias sejam identificadas. A diferena que os critrios a serem seguidos para determinar se um elemento ou no equivalente a outro so determinados exclusivamente pelo engenheiro.

Validar ou Invalidar Equivalncias Sugeridas

Equivalncias sugeridas automaticamente

Figura 5.32 - Equivalncias geradas automaticamente pela ferramenta

Se configurado na ferramenta, conforme apresentado na Figura 5.31, a escolha manual de equivalncias pode alimentar o dicionrio de sinnimos, que ser utilizado para determinar outras equivalncias em uma nova iterao com a ferramenta. A partir da, tanto no procedimento automtico quanto no manual, o prximo passo a validao das equivalncias, como previsto na abordagem. Para tanto, clica-se na equivalncia sugerida e atravs do boto - Validar/Invalidar Match, executa-se a

ao de validar ou invalidar tal equivalncia, como mostrado na Figura 5.32. Uma vez identificadas as equivalncias, possvel detectar os elementos opcionais e mandatrios no domnio, que o objetivo final desta primeira fase.

73

Elementos sero classificados como mandatrios se estiverem relacionados a uma equivalncia que possua relao em pelo menos N arquiteturas, sendo N maior ou igual ao nmero configurado no critrio em nmero mnimo de arquiteturas equivalentes, e opcionais, caso contrrio. Essa verificao feita automaticamente pela ferramenta. Assim, pode-se passar segunda fase, cuja tela apresentada na Figura 5.33 5.3.2 Segunda Fase Seguindo a abordagem proposta, na segunda fase, devero ser detectados os pontos de variao (VPs) e suas respectivas variantes. De acordo com o algoritmo proposto na seo 4.3.1.1, interfaces e superclasses devem ser identificadas como candidatos em potencial. Neste contexto, o papel da ferramenta ArchToDSSATool simplesmente implementar esse algoritmo, possibilitando a sugesto automtica de tais pontos de variao.

Figura 5.33 - ArchToDSSA - Segunda Fase

Uma vez que as arquiteturas analisadas so arquivos no formato XMI, possvel identificar, na estrutura do arquivo, que elementos da arquitetura so interfaces ou superclasses. A ferramenta faz uso de tal facilidade para sugerir os pontos de variao automaticamente. Alm disso, facilitada ao usurio da ferramenta a identificao desses elementos por meio de cores diferenciadas: os cones dos elementos que 74

representam interfaces so coloridos de vermelho, enquanto os cones dos elementos que representam superclasses so coloridos em verde, como destacado na Figura 5.33. Por meio do menu Actions

Generate All Suggested VPs, possvel gerar

automaticamente todos os pontos de variao sugeridos com base em interfaces e superclasses. Da mesma forma, pode-se sugerir automaticamente as respectivas variantes atravs do menu Actions

Generate All Suggested Variants. Na Figura 5.33,

as variantes do ponto de variao Caixa Postal seriam Simplificada e Completa, enquanto que as variantes do ponto de variao Jogos seriam Pacincia e BlackJack. Assim como no caso das equivalncias, possvel configurar os critrios Nmero mnimo de arquiteturas equivalentes para se considerar uma superclasse como um VP e Nmero mnimo de arquiteturas equivalentes se considerar uma interface como um VP, previstos na abordagem e descritos na seo 4.3.1. Para tanto, o menu Tools
Options

deve ser acessado, e na aba VP Options as configuraes

podem ser feitas, como mostra a Figura 5.34.

Nmero mnimo de arquiteturas equivalentes para se considerar uma Interface como um VP

Nmero mnimo de arquiteturas equivalentes para se considerar uma superclasse como um VP

Figura 5.34 - Configurao de critrios para VPs

Tambm nesta fase, o engenheiro de domnio pode manipular a ferramenta, baseado em seu conhecimento, sugerindo novos pontos de variao. Para isso, basta clicar com o boto direito do mouse sobre o elemento para defini-lo como um VP, como mostra a Figura 5.35. Uma vez identificados os pontos de variao (VPs), interessante que, de alguma forma, seja facilitado ao engenheiro a escolha de suas respectivas variantes, no 75

caso do engenheiro preferir selecionar os elementos de forma no-automtica. Isto pode ser feito, por exemplo, destacando-se os pontos de variao nas diferentes arquiteturas atravs de cores, mostrando de forma hierrquica seus respectivos candidatos a variantes e permitindo que se faa a seleo ou no destes candidatos. Uma vez selecionados, os elementos variantes so automaticamente associados aos pontos de variao para a fase de exportao. Mesmo no caso de um ponto de variao ser gerado manualmente, possvel gerar automaticamente suas variantes. Tal gerao automtica se baseia na identificao de subclasses, no caso do ponto de variao ser uma superclasse, ou de classes que implementem a interface que foi definida como ponto de variao. Para essa gerao, o menu Actions Generate All Suggested Variants deve ser acessado, como mencionado anteriormente.

VPs gerados automaticamente pela ferramenta

Definio manual de VPs Figura 5.35 - Definio manual de pontos de variao

Uma vez gerados os pontos de variao e suas variantes, o engenheiro est apto a passar terceira fase do processo. A tela referente fase de exportao de elementos apresentada na Figura 5.36.

76

5.3.3 - Terceira Fase Na terceira fase da abordagem, deve-se escolher a arquitetura que vai servir de base para a arquitetura de referncia (DSSA). Como mostra a Figura 5.36, a ferramenta possibilita essa escolha e, uma vez escolhida a arquitetura, todos os seus elementos arquiteturais so selecionados automaticamente, participando incondicionalmente da arquitetura de referncia, como previsto na abordagem.
Possibilidade de exportao para o ambiente Odyssey ou para um arquivo XMI

Arquitetura escolhida como base e seus elementos

Opcionalidade pode ser redefinida pelo usurio

Elementos so marcados com a seguinte notao: Opcionalidade: M - Mandatrio O Opcional Variabilidade: VP Ponto de Variao Var Variante I - Invariante Figura 5.36 - ArchToDSSA - Terceira Fase

Esses elementos so assinalados na rvore que mostra os elementos arquiteturais. Alm deles, so assinalados ainda os elementos de outras arquiteturas, diferentes da arquitetura-base, que possuem elementos que tambm faro parte da arquitetura de referncia, conforme selecionados pelo engenheiro. Assim, seja, por exemplo, uma Arquitetura A como sendo a arquitetura-base e uma Arquitetura B diferente da arquitetura-base. Se a Arquitetura B possui um ponto de variao equivalente a um ponto de variao da arquitetura A, mas suas variantes so diferentes, tais variantes da Arquitetura B so tambm selecionadas para participar da arquitetura de referncia.

77

As propriedades dos elementos arquiteturais que se referem a sua opcionalidade e variabilidade so visveis nesta fase. Porm, para tornar a ferramenta o mais flexvel possvel, as propriedades de opcionalidade identificadas na primeira fase podem ser redefinidas pelo engenheiro na fase de exportao. No entanto, as propriedade de variabilidade so apresentadas na tela para conferncia, sem a possibilidade de sobreposio nesta fase. Alm disso, a flexibilidade da ferramenta abrange a possibilidade de exportao da arquitetura de referncia sugerida, de duas maneiras: a primeira opo est sempre presente e permite que a arquitetura exportada d origem a um arquivo no formato XMI, que poder ser acessado por outras ferramentas que trabalhem em uma verso de XMI compatvel com a verso utilizada em ArchToDSSATool.; a segunda opo esta presente somente quando a ferramenta acionada como um plugin do Odyssey. Neste caso criado um arquivo XMI e automaticamente o ambiente Odyssey comandado para que ele importe o referido arquivo, disponibilizando a DSSA gerada em seu ambiente de modelagem. A escolha da forma pela qual a exportao ser feita realizada atravs do menu Actions, que apresenta as duas opes: Export DSSA to XMI e Export DSSA to Odyssey. A Figura 5.37 mostra uma DSSA que foi exportada para XMI e pode ser manipulada atravs da ferramenta Poseidon for UML (GENTLEWARE, 2007).

DSSA resultante da exportao para XMI Atributos definidos pela ArchToDSSATool sendo apresentados por tagged values

Elemento arquitetural que est sendo detalhado

Figura 5.37 - DSSA exportada para a ferramenta Poseidon

78

A Figura 5.37 evidencia o elemento arquitetural ToquesMusicais e apresenta seus atributos de opcionalidade = mandatrio e variabilidade = invariante como valores marcados (tagged values) no arquivo XMI gerado. O valor not defined apresentado na figura indica se o referido elemento definido na arquitetura-base ou no. Sendo not defined = false, nota-se que o elemento fazia parte da arquitetura-base. No caso da exportao para o Odyssey, a arquitetura resultante pode ser lida e manipulada no ambiente, sendo representada nos moldes da notao Odyssey-FEX, como mostra a Figura 5.38 a seguir. Aps a exportao, os relacionamentos existentes na arquitetura-base so mantidos e tambm podem ser manipulados no ambiente Odyssey.

DSSA resultante da exportao para o Odyssey

Atributos definidos pela ArchToDSSATool sendo apresentados por esteretipos da notao Odyssey-FEX

Relacionamentos da arquitetura-base

Figura 5.38 - DSSA exportada para o ambiente Odyssey

79

5.4 - Consideraes Finais

Foi apresentada nesse captulo a ferramenta ArchToDSSATool, no intuito de apoiar a execuo da abordagem ArchToDSSA, proposta neste trabalho. Tal ferramenta tem por objetivo a automatizao das atividades envolvidas no processo de definio de uma arquitetura de referncia, a partir de arquiteturas existentes, oriundas de sistemas legados, ou no. Foi apresentado, ainda, o prottipo da ferramenta desenvolvida, incluindo a sua relao com o ambiente Odyssey. No entanto, importante relembrar a independncia da ferramenta em relao ao ambiente, atravs de seu mecanismo de exportao da DSSA criada para arquivos XMI. No decorrer do captulo, foi apresentada a maneira pela qual as etapas da abordagem proposta, i.e. deteco de equivalncias e opcionalidades, deteco de variabilidades e criao de uma arquitetura de referencia no domnio, so tratadas pela ferramenta e como a automatizao pode auxiliar o engenheiro de domnio no seu trabalho. Uma possvel melhoria do prottipo da ferramenta diz respeito aos critrios utilizados na escolha da arquitetura-base, que atualmente so arbitrrios, cabendo ao engenheiro identificar qual das arquiteturas disponveis mais se adequa a este papel. Uma alternativa seria a adaptao do prottipo utilizao em conjunto com a ferramenta MetricTool (MELO JR, 2005), que a ferramenta de mtricas do ambiente Odyssey, a fim de que tal definio pudesse ser guiada baseada em mtricas que assegurem uma melhor escolha. Para tal, mtricas apropriadas deveriam ser estudadas. medida que se for obtendo um maior feedback atravs da utilizao no s da ferramenta, mas tambm da abordagem como um todo, evolues podero ser identificadas e realizadas, no intuito de se aprimorar no s o prottipo desenvolvido, como tambm a abordagem proposta neste trabalho. Um primeiro passo nesse sentido foi dado com a realizao de estudos de observao para averiguar a eficincia da abordagem e de seu ferramental de apoio. Tais estudos sero descritos no prximo captulo.

80

Captulo 6: Avaliao da abordagem ArchToDSSA

A abordagem ArchToDSSA tem por objetivo apoiar o engenheiro de domnio na criao de uma arquitetura de referncia. Este apoio realizado atravs de tarefas especficas e bem definidas, como a comparao de arquiteturas, identificao de suas opcionalidades, variabilidades e, finalmente, a criao e exportao de elementos arquiteturais que iro compor a arquitetura de referncia do domnio. A especificao destas tarefas e, conseqentemente, suas implementaes atravs da ferramenta ArchToDSSATool foram realizadas com base em experincias pessoais, observaes em ambiente empresarial e acadmico, comparaes com tcnicas semelhantes e identificao de necessidades com base na anlise da literatura, dentre outras fontes. Embora a concepo da abordagem tenha sido baseada em todas estas diferentes fontes de informao, no se pode assegurar que ela obtenha os resultados esperados (BABAR et al., 2004). Para que seja possvel verificar se os objetivos propostos foram atingidos, dois estudos experimentais foram conduzidos. Estudos deste tipo consistem basicamente em uma observao sistemtica dos efeitos de uma tecnologia em aplicaes prticas (WOHLIN et al., 2000). Segundo TRAVASSOS et al (2002), a experimentao representa o centro do processo cientfico, consistindo na nica forma de se verificar uma nova teoria. Ela oferece um modo sistemtico, disciplinado, computvel e controlado para a avaliao de novos mtodos, tcnicas, linguagens e ferramentas. De acordo com WOHLIN et al (2000), existem trs diferentes estratgias de estudo experimental que podem ser adotadas, de acordo com o propsito da avaliao e das condies para o estudo emprico, tais como disponibilidade de recursos. So elas: Investigao (survey): representa uma investigao realizada em retrospectiva, quando, por exemplo, uma tcnica ou ferramenta foi utilizada por um tempo e se deseja avali-la sob algum aspecto. As principais ferramentas utilizadas para apoiar a investigao so entrevistas e questionrios. Estudos de Caso: so utilizados para monitorar projetos, atividades ou atribuies. Dados so coletados para um propsito especfico e, estudos e anlises estatsticas podem ser conduzidas com base nos dados 81

coletados. Normalmente, visa rastrear um atributo especfico ou estabelecer relacionamentos entre diferentes atributos. O nvel de controle menor do que em um experimento. Experimentos: so normalmente conduzidos em laboratrio, o que prov um alto nvel de controle sobre o processo e os fatores ou variveis que afetam o estudo. O objetivo do experimento manipular uma ou mais variveis, mantendo as demais sob controle. Experimentos so apropriados para confirmar teorias, avaliar a predio dos modelos, ou validar medidas. Apresenta maior facilidade de repetio.

A escolha a respeito do mtodo de pesquisa experimental a ser utilizado depende dos pr-requisitos da investigao, do propsito, da disponibilidade de recursos e de como se pretende analisar os dados coletados (WOHLIN et al., 2000). Neste trabalho, foi utilizado um experimento da categoria estudo de caso. Tal escolha se deve a uma srie de fatores, dentre eles: a escassez de tempo e recursos (ex: participantes) para o planejamento e execuo do estudo; o tipo de avaliao que se deseja realizar, isto , a caracterizao da viabilidade da abordagem proposta; e a impossibilidade de controle total sobre as variveis do estudo (ex: perfil dos participantes, que avaliaram os objetos do estudo de forma subjetiva). Foram realizados dois estudos de observao, onde o objetivo do primeiro estudo foi investigar a eficincia da abordagem proposta, no que diz respeito ao apoio na criao de uma arquitetura de referncia a partir da comparao de arquiteturas de software em um domnio. O segundo estudo de observao teve como objetivo investigar a eficincia do ferramental desenvolvido no apoio ao engenheiro de domnio na criao da DSSA. Os estudos realizados visaram medir a eficincia, tanto da abordagem quanto da ferramenta, em relao corretude dos resultados obtidos como descritos a seguir.

6.1 - Primeiro Estudo de Observao: Abordagem

Nesta seo apresentado o primeiro estudo de observao conduzido. Alm da descrio do estudo, so apresentados tambm os principais resultados obtidos.

82

6.1.1 - Descrio do Primeiro Estudo Como resultado da conduo desse primeiro estudo de observao, esperava-se obter, dos participantes envolvidos, informaes que contribussem para o refinamento da proposta deste trabalho. Alm disso, esperava-se tambm obter indcios de que a utilizao da ArchToDSSA atinge o objetivo proposto, i.e., apoiar a criao de uma arquitetura de referncia no domnio de forma correta. O primeiro estudo de observao foi conduzido em um ambiente acadmico, no grupo de Reutilizao de Software do Programa de Engenharia de Sistemas e Computao da Coordenao dos Programas de Ps-Graduao em Engenharia COPPE/UFRJ. O estudo empregou quatro participantes, sendo dois de Graduao, um de Mestrado e um de Doutorado, que receberam treinamento na utilizao da abordagem atravs de material distribudo previamente, conforme os Anexos II e III. O resultado das atividades propostas para esse estudo foi observado pelo pesquisador autor deste trabalho. A seguir, o primeiro estudo de observao detalhado. Objetivo: O estudo teve como objetivo analisar a abordagem ArchToDSSA; com o propsito de caracterizar; com respeito eficincia da abordagem no apoio tarefa de criao de uma DSSA; do ponto de vista de engenheiros de software; no contexto da comparao de arquiteturas de aplicaes em domnios especficos.7 Participantes: O estudo empregou quatro estudantes de Engenharia de Software com diferentes nveis de experincia em conceitos como domnio e arquitetura de software. A experincia de cada participante foi aferida segundo um formulrio de caracterizao (Anexo VII), sendo caracterizada segundo quatro aspectos: Experincia prtica no desenvolvimento de software; Experincia com requisitos; Experincia em arquiteturas de software; Experincia em projetos.

Para todos os aspectos, foi utilizada uma escala ordinal envolvendo quatro opes, a saber: (1) Nenhum, (2) Estudei em aula ou em livro, (3) Pratiquei em um projeto em sala de aula, (4) Usei em um projeto na indstria, e (5) Usei em vrios projetos na indstria. Dos quatro participantes, apenas um tinha alguma experincia avanada. Os outros trs participantes relataram possuir experincia, em mdia, nos nveis intermedirios da escala.

Objetivo definido segundo o mtodo GQM (BASILI et al., 1994).

83

Material Utilizado: Para a realizao desse estudo, primeiramente foi entregue aos engenheiros de software o formulrio de consentimento (Anexo I), juntamente com as instrues para execuo dos procedimentos e preenchimento dos formulrios (Anexo III). Foram disponibilizadas arquiteturas, objetos de estudo, nos domnios de Telefonia Celular e tambm no domnio Escolar, da seguinte forma: foram entregues, em momentos diferentes, diagramas das arquiteturas de cada domnio (Anexo V), e um formulrio para que os resultados dos procedimentos fossem anotados (Anexo IV). Alm disso, para facilitar o entendimento da abordagem, foi entregue um documento introdutrio, explicando aos participantes sobre os propsitos do estudo, bem como um exemplo de utilizao da abordagem (Anexo II). Como o objetivo avaliar a eficincia da abordagem, i.e., a corretude dos resultados obtidos com a ArchToDSSA, as arquiteturas foram criadas de forma que simulassem arquiteturas extradas de software legado, ou seja, elas contm nomes distintos para elementos arquiteturais que tm o mesmo papel semntico. Conforme dito anteriormente, isto ocorre porque muitas vezes, as diferentes aplicaes, mesmo tratando de um mesmo domnio, so criadas por equipes, departamentos, empresas ou em momentos distintos. Para evitar discrepncias nos resultados, em funo dos diferentes entendimentos que engenheiros do domnio possuem sobre um mesmo domnio, foi disponibilizado um nico dicionrio de sinnimos (Anexo VI). Descrio do Exerccio: Para a conduo do estudo foram apresentados aos participantes os conceitos de ArchToDSSA, juntamente com um exemplo ilustrando sua aplicao no domnio de MP3 Player, alm dos procedimentos a serem seguidos pelos participantes durante a conduo do estudo. Para cada participante, foi distribudo o material j citado anteriormente, como forma de possibilitar o esclarecimento de eventuais dvidas em relao aplicao da abordagem proposta. Era esperado, como produto desse exerccio, as equivalncias, opcionalidades e variabilidades dos elementos que comporiam a arquitetura de referncia em cada domnio apresentado. O exerccio consistiu do seguinte procedimento: em um primeiro momento, para a primeira execuo do exerccio, cada participante recebeu as arquiteturas de exemplo de um domnio especfico, i.e., o domnio de Telefonia Celular ou o domnio Escolar. Os domnios foram previamente explicados pelo pesquisador condutor do estudo. A tarefa de cada um dos participantes era seguir as fases propostas em ArchToDSSA, obtendo as equivalncias, os elementos arquiteturais mandatrios e opcionais no domnio, bem como os pontos de variao e suas variantes. Em seguida, os participantes 84

realizaram novamente os procedimentos em um segundo domnio, diferente do primeiro que havia sido apresentado, conforme ilustrado na Tabela 6.2.
Tabela 6.2 Distribuio das atividades aos participantes do primeiro estudo de observao.

Participante 1 2 3 4

Primeira Execuo Domnio Escolar Domnio Escolar Domnio Telefonia Celular Domnio Telefonia Celular

Segunda Execuo Domnio Telefonia Celular Domnio Telefonia Celular Domnio Escolar Domnio Escolar

A repetio do procedimento tem como objetivo atenuar a curva de aprendizado do participante, permitindo que ele se concentre mais na utilizao da abordagem do que em eventuais dificuldades nesta utilizao. A idia da utilizao de domnios distintos nesta repetio tem como objetivo evitar vcios eventualmente adquiridos no domnio, que pudessem prejudicar a avaliao do participante na utilizao da abordagem, caso ele realizasse o procedimento duas vezes com o mesmo domnio. Desta forma, espera-se avaliar a evoluo do participante no uso da abordagem, independente do domnio no qual ele estaria trabalhando. Como existiam dois domnios distintos e quatro participantes, decidiu-se alternar os domnios entre cada dois participantes nos momentos da execuo. Aps a realizao do exerccio, os resultados foram coletados e comparados com um gabarito previamente estabelecido, no intuito de avaliar o percentual de corretude, i.e, a eficincia da utilizao da abordagem em cada fase. Esse percentual foi calculado segundo as seguintes mtricas:

Mtrica Fase 1: Percentual de equivalncias identificadas de forma correta atravs da utilizao da abordagem em relao ao nmero de equivalncias existentes no gabarito. NumMatchesOk * 100 EficienciaMatches% = NumMatchesGabarito

onde:

85

EficienciaMatches%: percentual de acertos na identificao de equivalncias pelo participante; NumMatchesOk: nmero de equivalncias identificadas corretamente pelo participante; NumMatchesGabarito: nmero total de equivalncias existentes, de acordo com o gabarito existente.

Mtrica Fase 2: Percentual de pontos de variao e variantes ligadas a estes identificados de forma correta atravs da utilizao da abordagem: NumVPOk * 100 EficinciaVP% = NumVPGabarito

NumVarOk * 100 EficinciaVar% = NumVarGabarito

onde EficinciaVP%: percentual de acertos na identificao de pontos de variao pelo participante; NumVPOk: nmero de pontos de variao identificados corretamente pelo participante; NumVPGabarito: nmero total de pontos de variao existentes, de acordo com o gabarito; EficinciaVar%: percentual de acertos na identificao de variantes pelo participante; NumVarOk: nmero de variantes identificadas corretamente pelo participante; NumVarGabarito: nmero total de variantes existentes, de acordo com o gabarito.

A criao da DSSA, resultado da Fase 3 da abordagem, pode ser inferida a partir dos elementos identificados corretamente nas duas primeiras fases. Alm disso, a criao da DSSA impactada tanto pela escolha da arquitetura-base, quanto pela escolha dos elementos opcionais pelo participante. Por serem essas escolhas subjetivas, 86

a comparao do resultado final com um gabarito no faria sentido. Por essas razes,, as mtricas utilizadas contemplam apenas as Fases 1 e 2.

6.1.2 - Resultados do Primeiro Estudo A anlise do primeiro estudo foi feita da seguinte forma: para cada domnio analisado, foi criado um gabarito contendo, em funo de seus dicionrios de sinnimos e da estrutura de suas arquiteturas, as equivalncias, opcionalidades e variabilidades esperadas. Aps a execuo do estudo de observao, foram coletados os resultados de cada participante. Estes resultados foram comparados com os gabaritos, e um percentual de corretude, i.e., a eficincia, pde ser calculado para os resultados de cada fase, conforme as mtricas j apresentadas. Para cada fase da abordagem, foi calculado o percentual de acertos de cada participante em cada domnio. Em seguida foi calculada a mdia aritmtica do percentual de acerto em cada uma das fases, em relao aos dois domnios estudados. Conforme j mencionado, tal mdia calculada a fim de equilibrar eventuais discrepncias causadas pela diferena na curva de aprendizado de cada participante durante a utilizao da abordagem. Considera-se que, na segunda execuo, o participante j esteja mais familiarizado com os procedimentos do estudo e tambm com o primeiro domnio utilizado. Por isso, troca-se o domnio e calcula-se a mdia das duas execues. Os resultados obtidos na primeira e segunda fases da abordagem so apresentados, respectivamente, na tabela 6.3, tabela 6.4 e tabela 6.5.

Tabela 6.3 Mdia de acertos dos participantes na primeira fase da abordagem

Participante 1 2 3 4

EficienciaMatches% Primeira Execuo 100 44,83 100 84,62

EficienciaMatches% Segundoa Execuo 100 92,30 100 93,10 Mdia geral:

Mdia 100 68,57 100 88,86 89,35

87

Tabela 6.4 - Mdia de acertos dos participantes na segunda fase da abordagem - VP

Participante 1 2 3 4

EficinciaVP% Primeira Execuo 100 48,28 87,5 87,5

EficinciaVP% Segunda Execuo 100 100 100 86,20 Mdia geral:

Mdia 100 74,14 93,75 86,85 88,68

Tabela 6.5 - Mdia de acertos dos participantes na segunda fase da abordagem - Variantes

Participante 1 2 3 4

EficinciaVar% Primeiro Domnio 84,93 19,18 88,24 88,24

EficinciaVar% Segundo Domnio 100 100 100 73,97 Mdia geral:

Mdia 92,46 59,59 94,12 81,10 81,81

Para auxiliar na avaliao da abordagem, algumas perguntas subjetivas foram feitas aos participantes do estudo, como mostrado a seguir: 1) Os conceitos de Arquiteturas e DSSA j eram de seu conhecimento antes do estudo realizado? E depois? Um participante respondeu que j tinha conhecimento dos conceitos e os outros trs participantes responderam que melhoraram o conhecimento dos conceitos depois do estudo realizado.

2) Qual o grau de dificuldade ou facilidade em realizar as etapas sugeridas? Explique. Todos os participantes alegaram que a tarefa no tinha muitas dificuldades, porm era muito cansativa e suscetvel a erros.

3) A abordagem de alguma forma o ajudou na comparao de arquiteturas e criao da DSSA?

88

Um participante alegou que a abordagem no facilitou em nada, pelo contrrio, criou dificuldades que, no seu entender, no existiriam se o processo de comparao fosse feito de maneira ad hoc. Os outros trs participantes alegaram ter sido mais fcil identificar pontos de variao e variantes a partir das equivalncias encontradas, como sugerido na abordagem.

4) Como a abordagem poderia ser melhorada? Um participante no respondeu a essa pergunta. Um segundo no sugeriu melhorias. Outros dois sugeriram melhorias tais como automatizao do processo, ou alguma ordenao das entradas no dicionrio de sinnimos.

5) Acredita que uma ferramenta iria ajud-lo na execuo das tarefas? De que forma? Todos os participantes alegaram que uma ferramenta auxiliaria no processo, automatizando repeties excessivas e tornando a execuo da tarefa menos cansativa e suscetvel a erros.

De acordo com os resultados obtidos neste primeiro estudo, pde-se concluir que a mdia geral de acertos, i.e, a eficincia da abordagem, ultrapassou a marca de 80%. Esse valor, somado s respostas dos participantes ao formulrio de questes subjetivas, oferece indcios da viabilidade da abordagem proposta Alm disso, de um modo geral, a mdia obtida na segunda execuo foi mais alta do que a da primeira execuo. Isso leva a crer que a eficincia da abordagem cresce com sua utilizao de forma continuada. Um outro fato observado tambm neste primeiro estudo foi que grande parte dos erros cometidos pelos participantes na identificao de pontos de variao e variantes se deve dificuldade causada quando um elemento , ao mesmo tempo, variante em relao a um elemento, e ponto de variao em relao a outros. Uma vez que tal situao no havia sido prevista inicialmente, os participantes no receberam instrues para tal classificao, transformando tal limitao na principal causa de erros na execuo das tarefas do estudo realizado. Com relao automatizao da abordagem, foi constatado que os participantes, em sua totalidade, concordam que seria vlida a construo de uma ferramenta de apoio. Uma vez que tal ferramental de apoio foi implementado no contexto dessa dissertao,

89

foi realizado um segundo estudo de observao, no intuito de verificar a eficincia da ferramenta ArchToDSSAtool, como apresentado a seguir.

6.2 - Segundo Estudo de Observao : Ferramenta

Prosseguindo na avaliao da abordagem ArchToDSSA e do seu ferramental de apoio, nesta seo, apresentado o segundo estudo de observao conduzido. 6.2.1 - Descrio do Segundo Estudo O segundo estudo de observao foi conduzido com o objetivo de avaliar a eficincia do ferramental de apoio proposto, denominado neste trabalho

ArchToDSSATool. Entende-se por eficincia, o percentual de corretude que o participante do estudo obtm na criao de uma DSSA utilizando a ferramenta. Tal estudo foi realizado em um ambiente empresarial, onde os participantes so desenvolvedores de software com experincia em desenvolvimento, porm com pouca familiaridade com conceitos como domnio e arquiteturas de referncia. Como resultado desse estudo, era esperado que os participantes conseguissem identificar elementos que pudessem compor uma DSSA, da maneira mais correta possvel, com suas equivalncias, opcionalidades e variabilidades, em dois domnios distintos, com o auxlio da ferramenta, mesmo tendo pouca experincia com os conceitos envolvidos na criao de uma arquitetura de referncia. A exemplo do primeiro estudo, o desenvolvimento das atividades propostas para esse estudo tambm foi observado pelo pesquisador autor deste trabalho. A seguir, o segundo estudo de observao detalhado. Objetivo: O estudo teve como objetivo analisar a ferramenta ArchToDSSATool; com o propsito de caracterizar; com respeito eficincia da ferramenta no apoio tarefa de criao de uma DSSA; do ponto de vista de desenvolvedores de software; no contexto da comparao de arquiteturas de aplicaes em domnios especficos. Participantes: O estudo empregou quatro desenvolvedores de software com diferentes nveis de experincia em desenvolvimento de software na indstria e em conceitos como domnio e arquitetura de software. Todos os participantes possuem graduao completa, e relataram nveis de experincia em desenvolvimento de software na indstria compreendidos entre 2 anos e meio e 11 anos. Um deles trabalha na rea de desenvolvimento web, dois com desenvolvimento desktop e um com a rea de engenharia de software.

90

A exemplo do primeiro estudo, a experincia de cada participante foi aferida segundo o formulrio de caracterizao do Anexo VII, e tambm sendo caracterizada segundo os aspectos: Experincia prtica no desenvolvimento de software; Experincia com requisitos; Experincia em arquiteturas de software; Experincia em projetos.

Tambm aqui foi utilizada a escala ordinal envolvendo as quatro opes: (1) Nenhum, (2) Estudei em aula ou em livro, (3) Pratiquei em um projeto em sala de aula, (4) Usei em um projeto na indstria, e (5) Usei em vrios projetos na Indstria. Dos quatro participantes, dois deles tinham experincia no nvel 5 da escala em arquiteturas de software e projetos Os outros dois participantes relataram possuir experincia, em mdia, nos nveis 3 e 4 da escala para a maioria dos aspectos investigados.

Material Utilizado: Para a realizao desse estudo, assim como no estudo anterior, foram entregues aos desenvolvedores de software, primeiramente, o formulrio de consentimento (Anexo I), juntamente com as instrues para a execuo dos procedimentos e preenchimento dos formulrios (Anexo III). Foram entregues tambm as arquiteturas de exemplo nos domnios Escolar e de Telefonia Celular no formato XMI e o dicionrio de sinnimos do domnio com algumas entradas preenchidas. Descrio do Exerccio: A conduo do segundo estudo foi precedida por uma sesso de treinamento, onde foram apresentados aos participantes os conceitos de ArchToDSSATool, um exemplo ilustrando sua aplicao, alm dos procedimentos a serem seguidos pelos participantes durante a execuo do estudo com a utilizao da ferramenta. Este treinamento teve o intuito de esclarecer eventuais dvidas em relao aplicao da abordagem proposta ou do uso da ferramenta. Era esperado, como produto desse exerccio, as equivalncias, opcionalidades e variabilidades dos elementos que comporiam a arquitetura de referncia em cada domnio apresentado, em arquivos no formato XMI, de forma mais correta possvel, independente do grau de familiaridade dos participantes com os conceitos envolvidos em uma DSSA. O exerccio consistia do seguinte procedimento: em um primeiro momento, para a primeira execuo do estudo, cada participante recebeu as arquiteturas de exemplo de um domnio especfico. A tarefa de cada um deles era seguir as fases propostas em

91

ArchToDSSA, obtendo as equivalncias, os elementos arquiteturais mandatrios e opcionais no domnio, bem como os pontos de variao e suas variantes. Em seguida, os participantes realizaram novamente os procedimentos em um segundo domnio, diferente do primeiro que havia sido apresentado, conforme ilustrado na Tabela 6.6.
Tabela 6.6 - Distribuio das atividades aos participantes do segundo estudo de observao

Participante 1 2 3 4

Primeira Execuo Domnio Telefonia Celular Domnio Telefonia Celular Domnio Escolar Domnio Escolar

Segunda Execuo Domnio Escolar Domnio Escolar Domnio Telefonia Celular Domnio Telefonia Celular

6.2.2 Resultados do Segundo Estudo A anlise do segundo estudo foi feita de forma semelhante do primeiro estudo: os gabaritos contendo as equivalncias, opcionalidades e variabilidades esperadas, criados para o primeiro estudo, foram aqui utilizados. Uma vez que o resultado final da utilizao da ferramenta a criao de um arquivo no formato XMI, aps a execuo do segundo estudo de observao, as informaes contidas em tal arquivo foram comparadas com os gabaritos e um percentual de corretude, i.e., a eficincia, pde ser calculado para os resultados de cada fase, segundo as mesmas mtricas apresentadas na seo 6.1.1. Novamente, para cada fase da abordagem, foi calculado o percentual de acertos de cada participante em cada domnio, e calculada uma mdia aritmtica do percentual de acerto nos dois domnios distintos. Os resultados obtidos na primeira e segunda fases da abordagem so apresentados, respectivamente, nas Tabela 6.7,Tabela 6.8, e Tabela 6.9.
Tabela 6.7 Mdia de acertos dos participantes na primeira fase da abordagem com o uso da ferramenta

Participante 1 2 3 4

EficienciaMatches% Primeira Execuo 100 100 86,20 86,20

EficienciaMatches% Segunda Execuo 86,20 86,20 100 100 Mdia geral:

Mdia 93,1 93,1 93,1 93,1 93,1

92

Tabela 6.8 - Mdia de acertos dos participantes na segunda fase da abordagem com o uso da ferramenta

Participante 1 2 3 4

EficinciaVP% Primeira Execuo 100 100 48,27 48,27

EficinciaVP% Segunda Execuo 48,27 48,27 100 100 Mdia geral:

Mdia 74,13 74,13 74,13 74,13 74,13

Tabela 6.9- Mdia de acertos dos participantes na segunda fase da abordagem com o uso da ferramenta

Participante 1 2 3 4

EficinciaVar% Primeira Execuo 100 100 89,04 89,04

EficinciaVar% Segunda Execuo 89,04 89,04 100 100 Mdia geral:

Mdia 94,52 94,52 94,52 94,52 94,52

Uma observao que foi feita, durante a execuo deste estudo, foi que as mdias de acerto foram exatamente iguais em cada domnio, conforme mostram as Tabelas Tabela 6.7,Tabela 6.8, e Tabela 6.9. Isso se deve ao fato de que, embora os participantes tivessem liberdade para criar equivalncias, apontar pontos de variao e variantes manualmente, nenhum deles o fez. Todos optaram por usar as opes de sugestes automticas disponveis em ArchToDSSATool. Esse comportamento pode ter ocorrido em funo de alguma eventual insegurana, motivada pela pouca experincia dos participantes na criao de DSSAs, mesmo tendo estes recebido treinamento para a execuo do estudo Dessa forma, a ferramenta apresentou o mesmo comportamento em todas as execues, uma vez que no houve diferena de configurao entre os participantes do estudo. importante ressaltar, ainda, que, no caso da deteco de pontos de variao e variantes, a ferramenta teve um desempenho abaixo do esperado. Isso se deve ao fato de que, conforme mencionado anteriormente, a ferramenta, assim como a abordagem, no trata situaes onde um elemento , ao mesmo tempo, ponto de variao e variante. Isso ocasionou divergncias nos resultados obtidos pelo uso da ferramenta, em relao ao 93

gabarito pr-estabelecido, especificamente na deteco automtica de pontos de variao. Ainda assim, a mdia geral de cada fase ficou acima da marca de 90%, o que oferece indcios sobre a eficincia da ferramenta ArchToDSSATool. A exemplo do primeiro estudo, algumas perguntas subjetivas foram feitas aos participantes, no intuito de auxiliar na avaliao da ferramenta, como mostrado a seguir:

1) Os conceitos de Arquiteturas e DSSA j eram de seu conhecimento antes do estudo realizado? E depois? Trs participantes alegaram ter conhecimento do conceito de arquitetura de software, mas no de DSSA, e afirmaram terem assimilado seu significado aps o estudo realizado. Um dos participantes alegou ter adquirido o conhecimento sobre tais conceitos somente depois do estudo. 2) Qual o grau de dificuldade ou facilidade em realizar as etapas sugeridas? Explique. Todos os participantes alegaram no ter dificuldades com a ferramenta, classificando-a como intuitiva e de fcil utilizao. No entanto, todos eles ressaltaram que a dificuldade com a ferramenta, caso existisse, provavelmente seria proveniente de eventuais dificuldades de entendimento dos conceitos do domnio utilizado. Porm, como todos receberam treinamento a respeito do domnio, tais dificuldades no foram encontradas.

3) A Ferramenta de alguma forma o ajudou na comparao de arquiteturas e criao da DSSA? Todos os participantes responderam sim a esta pergunta, ressaltando o recurso de apresentao dos elementos arquiteturais em nveis hierrquicos e a facilidade de visualizao dos resultados obtidos.

4) Como a ferramenta poderia ser melhorada? As melhorias sugeridas pelos participantes incluem aprimoramento da deteco de equivalncias, por exemplo, com a insero de um campo de busca dentro das arquiteturas, facilitando a localizao dos seus elementos, que eram muitos, e modificaes na interface no intuito de deix-la mais bonita.

94

5) Como seria este processo sem a ferramenta? Fcil, Difcil, Rpido, Demorado? Explique Todos os participantes responderam que o processo sem a ferramenta seria muito demorado, alm de suscetvel a erros e com alto custo operacional.

6) A ferramenta apresentada pode ser utilizada em alguma etapa do desenvolvimento de software da sua rea de trabalho? Um participante no respondeu a essa pergunta. Dois participantes responderam que no vem ligao direta com sua rea de trabalho, e um dos participantes, que trabalha com engenharia de software, apontou que, no seu entender, a ferramenta poderia ser til.

Uma vez coletados os resultados do segundo estudo, as mdias de acertos obtidos neste estudo, no qual os participantes eram leigos, isto , com pouca experincia nos conceitos de domnio e arquiteturas de referncia, e dependiam do auxlio da ferramenta, foram comparados com as mdias de acertos obtidas no primeiro estudo de observao, no qual os participantes j detinham algum conhecimento sobre o assunto. Na Tabela 6.10, apresentado um comparativo destas mdias.
Tabela 6.10 Comparao dos resultados dos dois estudos de observao

Fase EficienciaMatches% EficinciaVP% EficinciaVar%

Mdia Geral Primeiro Estudo (Manual Com Experincia) 89,35 88,68 81,81

Mdia Geral Segundo Estudo (Ferramenta Sem Experincia) 93,10 74,13 94,52

De acordo com os resultados apresentados na Tabela 6.10, possvel obter indcios sobre a eficincia da abordagem, uma vez que possibilitou a identificao de equivalncias, opcionalidades e variabilidades com alto percentual de corretude em diferentes domnios. Alm disso, h indcios tambm sobre a eficincia do ferramental de apoio, uma vez que possibilitou a usurios com pouca experincia nos conceitos de domnio e arquiteturas de referncia, a identificao de tais componentes com um

95

percentual de corretude relativamente alto. Embora a mdia geral do procedimento com a utilizao da ferramenta no tenha sido to superior media do processo manual, pde-se observar o aumento de produtividade proporcionado pela ferramenta, no sentido de possibilitar a execuo das tarefas em um tempo consideravelmente menor do que o tempo gasto no processo manual. O processo manual levou, em mdia, duas horas e meia, e o processo utilizando a ferramenta levou, em mdia quinze minutos, mesmo considerando-se o fato de que os participantes que fizeram o processo manualmente estavam melhor preparados para a execuo do estudo, devido ao fato de serem acadmicos da rea de reutilizao de software. Levando-se em considerao que a ferramenta ArchToDSSATool a implementao do processo proposto na abordagem ArchToDSSA, possvel obter indcios de que a proposta deste trabalho se mostra eficiente no auxlio a engenheiros de domnio, independente de sua experincia e conhecimento em arquiteturas de referncia.

6.3 - Consideraes Sobre os Estudos de Observao

Embora os estudos conduzidos tenham conseguido avaliar a eficincia do processo proposto para a criao de uma DSSA, algumas questes sobre estes devem ser consideradas. Como exemplo, tem-se a existncia de um dicionrio de sinnimos para o domnio, previamente distribudo ao participante, o que poderia induzi-lo criao da uma DSSA correta. No entanto, tal medida foi necessria para que no houvesse discrepncia nos resultados obtidos, uma vez que o entendimento do domnio pode ser muito diferente na concepo dos diversos participantes. Outra questo a escolha do perfil dos participantes para o estudo: por um lado, para a avaliao da abordagem, foram escolhidos somente participantes do ambiente acadmico (estudantes da rea de reutilizao de software). Com isto esperava-se um senso mais crtico em relao aos procedimentos propostos, devido ao maior grau de conhecimento e familiaridade destes com os conceitos envolvidos. Por outro lado, para avaliar a ferramenta, optou-se apenas por participantes do ambiente empresarial. A idia era justamente tentar provar a corretude da ferramenta em relao abordagem, mostrando que participantes com menos conhecimento sobre os assuntos envolvidos eram capazes de executar as tarefas de forma correta usando a ferramenta. Uma vez que a relao de cada grupo com o autor do estudo (i.e., colegas de estudo no primeiro grupo e funcionrios no segundo grupo) diferente, o nvel de envolvimento de cada grupo com o autor tambm diferente, o que levou opo de usar dois grupos distintos, no 96

intuito de evitar qualquer comprometimento na conduo dos estudos, contrabalanando o conhecimento sobre o assunto e envolvimento com o autor. Limitaes foram identificadas durante os estudos. Eles apontaram a necessidade de tratamento especial aos elementos que se comportam como ponto de variao e variante. Alm disso, as arquiteturas utilizadas nos estudos, embora tenham sido realmente extradas de sistemas legados, esto longe de serem completas, do mesmo modo que os participantes de tais estudos no so especialistas no domnio. Os estudos de observao realizados no contexto dessa dissertao no tm a pretenso de serem estudos completos e com total abrangncia para a avaliao da abordagem e ferramenta propostas. necessrio que estudos mais profundos, com domnios mais complexos sejam realizados no futuro, no intuito de apurar a necessidade de outras melhorias em ArchToDSSA e/ou ArchToDSSATool.

97

Captulo 7: Concluses e Trabalhos Futuros

7.1 - Contribuies
Foi apresentada, nessa dissertao, a abordagem ArchToDSSA, cujo objetivo apoiar a criao de arquiteturas de referncia no domnio, a partir da anlise de arquiteturas de aplicaes em um domnio especfico. Alm disso, foi apresentada a ferramenta ArchToDSSATool, abordagem proposta. Tendo em vista as deficincias encontradas em trabalhos existentes na literatura, a pesquisa realizada nessa dissertao apresenta como principais contribuies: 1. Uma abordagem para a criao de uma arquitetura de referncia em um domnio a partir da comparao de arquiteturas existentes, de sistemas legados, ou no. A abordagem ArchToDSSA, proposta neste trabalho, apresenta as seguintes caractersticas que representam suas contribuies: Comparao de diferentes arquiteturas: diferentemente de algumas abordagens analisadas, cuja nfase na comparao entre verses diferentes de uma mesma arquitetura, a abordagem ArchToDSSA permite a comparao de arquiteturas diferentes em um domnio. Atravs da identificao de elementos arquiteturais semanticamente equivalentes, possibilita uma maior preciso na escolha dos elementos que faro parte da DSSA, reduzindo a ocorrncia de redundncia na arquitetura de referncia final. Criao de um dicionrio de sinnimos: a criao e alimentao de um dicionrio de sinnimos para o domnio possibilitam no s uma maior flexibilidade ao trabalho do engenheiro, como tambm do origem a uma base para um maior conhecimento do domnio. Comparao de elementos atravs da diviso de nomes: o critrio de comparao de elementos por meio da diviso de nomes representa mais uma alternativa para lidar com a diferena de nomenclatura entre tais elementos, possibilitando uma maior corretude na especificao da DSSA final. Identificao de variabilidades e opcionalidades entre os elementos arquiteturais: uma vez que a abordagem ArchToDSSA 98 prottipo desenvolvido visando a automatizao da

consegue identificar elementos mandatrios e opcionais, alm de pontos de variao com as suas variantes, em um conjunto de arquiteturas de domnio, uma grande contribuio est sendo dada reutilizao de software, tornando mais consistentes as aplicaes que sero derivadas da DSSA especificada.

2. Uma ferramenta de apoio abordagem ArchToDSSA, denominada ArchToDSSATool, que visa o aumento de produtividade do engenheiro de domnio na criao de uma DSSA. O prottipo implementado possui as seguintes caractersticas: Integrao a um ambiente concreto de desenvolvimento de software: a implementao do prottipo de modo integrado ao ambiente Odyssey possibilita etapas adjacentes comparao das arquiteturas, tais como a extrao de tais arquiteturas por meio de engenharia reversa e a modelagem e manipulao da DSSA especificada. Tais atividades, embora estejam alm do escopo desta proposta, complementam o processo de criao de uma arquitetura de referncia em um domnio. Possibilidade de execuo do prottipo de forma independente (i.e., stand alone): a alternativa de execuo da ArchToDSSATool de forma independente traz uma grande flexibilidade ao trabalho do engenheiro, que no se atm a um ou outro ambiente de desenvolvimento. Possibilidade de integrao com outras ferramentas: a utilizao do formato XMI para a comparao das arquiteturas e especificao da DSSA permite que vrias ferramentas que utilizem tal formato possam ser integradas abordagem ArchToDSSA.

3. Dois estudos de observao com o objetivo de caracterizar a eficincia da abordagem proposta e do seu ferramental de apoio. Os estudos de observao conduzidos ofereceram indcios que levam a crer que tanto a abordagem quanto o ferramental de apoio implementado so eficientes no seu propsito de auxiliar um engenheiro de domnio na criao de uma DSSA. Alm disso, atravs dos estudos conduzidos, pde-se perceber que 99

at mesmo os engenheiros menos experientes, ou com menos conhecimento do domnio, conseguem criar uma DSSA, graas ao auxlio da ferramenta ArchToDSSATool.

7.2 - Limitaes
Algumas limitaes puderam ser detectadas ao longo dessa pesquisa, como listado a seguir: Verso da UML e XMI: inserida na proposta do trabalho de (VASCONCELOS, 2007), que se iniciou em 2002, a abordagem utiliza a verso corrente da especificao da UML, poca, que era a 1.4, e verso XMI 1.1. Embora outras verses da UML e do XMI tenham surgido aps esse momento, o ambiente Odyssey ainda trabalha com tal especificao. Assim, o arquivo XMI gerado para a DSSA, bem como modelos UML resultantes de sua manipulao, somente podem ser lidos por ambientes de desenvolvimento ou ferramentas que sejam compatveis com essas mesmas verses de UML/XMI. Isso se deve principalmente ao fato do repositrio MOF utilizado, o MDR, ainda no ter evoludo para a verso atual do XMI e da UML. Definio arbitrria na escolha da arquitetura-base: atualmente, a abordagem no define nenhum critrio para a escolha da arquitetura que servir de base para a DSSA final. Uma possvel melhoria seria o estabelecimento de heursticas para a escolha dessa arquitetura-base, ou mesmo a integrao da abordagem com uma ferramenta de mtricas, a fim de que tal arquitetura-base possa ser selecionada atravs de mtricas estabelecidas; Suporte apenas aos modelos estticos: atualmente, trata-se somente a comparao de modelos estticos, i.e., diagramas de classe da UML. Em futuras pesquisas, outros modelos poderiam ser tratados, como os modelos dinmicos, como o diagrama de sequncia da UML. Tratamento de elementos que sejam apenas pontos de Variao ou Variantes: a abordagem, e por conseguinte, seu ferramental de apoio, no trata situaes em que um elemento arquitetural , ao 100

mesmo tempo, uma variante em relao a um elemento e um ponto de variao em relao a outros. Tal limitao foi revelada aps a conduo dos estudos de observao.

7.3 - Perspectivas Futuras

Diante do trabalho aqui apresentado, abre-se uma gama de perspectivas futuras, como: Granularidade: em trabalhos futuros, pode-se definir um novo mtodo de clculo para as equivalncias de um elemento em funo das equivalncias de outros elementos nele contidos. Por exemplo, a equivalncia entre pacotes poderia ser inferida em funo das equivalncias entre suas classes. Atualmente, a comparao no leva em considerao sub-elementos. Mecanismos de Avaliao: desenvolver formas de identificar e sugerir mecanismos de avaliao que possam validar a DSSA criada, tais como inspees, etc; Refinamento da abordagem e do ferramental de apoio com base nas limitaes encontradas: baseado nas limitaes j citadas anteriormente e tambm em novos estudos experimentais, a abordagem e seu ferramental de apoio podem ser refinados. Identificao de Variabilidades e Opcionalidades em termos de mtodos e atributos: mecanismos que pudessem identificar a opcionalidade e variabilidade dos mtodos e atributos das classes podem ser pesquisados, tornando a comparao e a criao da DSSA mais precisa. medida que se for obtendo um maior feedback atravs da utilizao da abordagem como um todo, outras melhorias podem ser identificadas e realizadas, contribuindo assim para o avano das pesquisas em Reutilizao de Software, especialmente no campo de arquitetura de referncia para domnios especficos.

101

Referncias Bibliogrficas

ABOWD, G., ALLEN, R., GARLAN, D., 1993, "Using style to understand descriptions of software architecture". In: Proceedings of the 1st ACM SIGSOFT symposium on Foundations of software engineering, pp. 9-20 Los Angeles, California. ARANGO, G., 1994, "A brief introduction to domain analysis". In: Proceedings of the 1994 ACM symposium on Applied computing pp. 42-46, Phoenix, Arizona, United States ATKINSON, C., BAYER, J., BUNSE, C., et al., 2002, Component-based Product Line Engineering with UML, Boston, Addison-Wesley Longman Publishing Co., Inc. BABAR, M.A., ZHU, L., JEFFERY, R., 2004, "A Framework for Classifying and Comparing Software Architecture Evaluation Methods". In: Proceedings of the Australian Software Engineering Conference, pp. 309-318, Malbourne, Australia, April. BARROCA, L., GIMENES, I.M.D.S., HUZITA, E.H.M., 2005, "Conceitos Bsicos". In: GIMENES, I.M.S., HUZITA, E.H.M. (eds), Desenvolvimento Baseado em Componentes: Conceitos e Tcnicas, Rio de Janeiro, Cincia Moderna. BASILI, V., CALDIEIRA, G., ROMBACH, H., 1994, Goal Question Metrics Paradigm, Encyclopedia of Software Engineering, John Wiley & Sons. BLOIS, A.P.B., 2006, Uma Abordagem de Projeto Arquitetural Baseado em Componentes no Contexto de Engenharia de Domnio, Tese de D.Sc., Programa de Engenharia de Sistemas e Computao - COPPE, UFRJ, Rio de Janeiro, Brasil. BOSCH, J., 2004, "Software Variability Management". In: Proceedings of the 26th International Conference on Software Engineering (ICSE04), pp. 720-721, Scotland, UK.

102

BRAGA, R., 2000, Busca e Recuperao de Componentes em Ambientes de Reutilizao de Software, Tese de D.Sc., COPPE, UFRJ, Rio de Janeiro, Brasil. BUFFENBARGER, J., 1995, "Syntactic Software Merging". In: Selected papers from the ICSE SCM-4 and SCM-5 Workshops, on Software Configuration Management pp. 153-172 Seattle, Washington, USA. CLAUSS, M., 2001, "Generic Modeling using UML Extensions for Variability". In: DSVL 2001 (OOPSLA Workshop on Domain Specific Visual Languages), Proceedings, pp. 11-18, Finland. CLEMENTS, P., 1994, "From Domain Models to Architectures". In: Workshop on Software Architecture, USC Center for Software Engineering, Los Angeles, CA, USA. CLEMENTS, P.C., 1996, "A Survey of Architecture Description Languages". In: IWSSD '96: Proceedings of the 8th International Workshop on Software Specification and Design, pp. 16-25, Los Alamitos, California. CLEMENTS, P.C., 1999, "Essential Product Line Practices". In: Proceedings of the Ninth Workshop on Institutionalizing Software Reuse - WISR9, Austin, TX, USA, January. CORBA, 2007, "Common Object Request Broker Archtecture". In:

http://www.corba.org, accessed in 21/06/2007. D'SOUZA, D.F., WILLS, A.C., 1999, Objects, components, and frameworks with UML: the catalysis approach, Addison-Wesley Longman Publishing Co., Inc. DASHOFY, E., HOEK, A., TAYLOR, R., 2002, "An Infrastructure for the Rapid Development of XML-based Architecture Description Languages". In: 24th International Conference on Software Engineering, pp. 266-276., Orlando, USA, May. DASHOFY, E.M., HOEK, A.V.D., TAYLOR, R.N., 2001, "A Highly-Extensible, XML-Based Architecture Description Language ". In: Proceedings of the

103

Working IEEE/IFIP Conference on Software Architecture (WICSA'01), pp. 103112, Amsterdan, The Netherlands, August. DIAS, M.S., VIEIRA, M.E.R., 2000, "Software Architecture Analysis based on Statechart Semantics". In: International Workshop on Software Specification and Design, pp. 133-137, Shelter Island, San Diego, California, USA, November. FUJABA, 2007, "Fujaba Suite Tool". In: www.fujaba.de, accessed in 29/05/2007. GARLAN, D., PERRY, D., 1995, "Introduction to the Special Issue on Software Architecture", IEEE Transactions on Software Engineering (April), pp. 269-274. GENTLEWARE. In: http://www.gentleware.com/, accessed in 17/05/2007. GIMENES, I.M.S., TRAVASSOS, G.H., 2002, "O Enfoque de Linha de Produto para Desenvolvimento de Software". In: XXI Jornada de Atualizao em Informtica (JAI) Evento Integrante do XXII Congresso da SBC, pp. 1-31, Florianpolis, Brasil, Julho. GOMAA, H., 2004, Designing Software Product Lines with UML: from Use Cases to Pattern-Based Software Architectures, Addison-Wesley Professional. GRISS, M.L., FAVARO, J., D'ALESSANDRO, M., 1998, "Integrating feature modelling with the RSEB". In: Proceedings of Fifth International Conference on Softwre Reuse - ICSR5, pp. 76-85 Victoria, British Columbia, Canada, June. HAYES, R., 1994, Architecture-Based Acquisition and Development of Software Guidelines and Recommendations from the ARPA Domain-Specific Software Architecture (DSSA) Program Tecknowledge Federal System. HOFMEISTER, C., NORD, R.L., D., S., 1999, "Describing Software Architecture with UML". In: 1st Working IFIP Conference on Software Architecture, pp. 145-160, San Antonio, Texas, USA, February. IBM, 2007, "XML Diff and Merge Tool". In:

http://www.alphaworks.ibm.com/tech/xmldiffmerge, accessed in 29/05/2007.

104

IEEE, 1990, "Std 610.12 - IEEE Standard Glossary of Software Engineering Terminology", Institute of Electrical and Electronics Engineers. JACOBSON, I., GRISS, M., JONSSON, P., 1997, Software Reuse: architecture, process and organization for business success, 1st ed., Addison-Wesley JIANG, J., SYST, T., 2003 "Exploring Differences in Exchange Formats - Tool Support and Case Studies ". In: Proceedings of the Seventh European Conference on Software Maintenance and Reengineering pp. 389-398, Benevento, Italy. KANG, K.C., COHEN, S.G., HESS, J.A., et al., 1990, Feature-Oriented Domain Analysis (FODA): Feasibility Study, Software Engineering Institute (SEI), CMU/SEI-90-TR-21, ESD-90-TR-222. KANG, K.C., LEE, J., DONOHOE, P., 2002, "Feature-Oriented Product Line Engineering", IEEE Software, v. 9, n. 4 (Jul./Aug 2002), pp. 58-65. KEIENBURG, F., RAUSCH, A., 2001, "Using XML/XMI for Tool Supported Evolution of UML Models". In: 34th Hawaii International Conference on System Sciences (HICSS), pp. 9064-9073, Island of Maui, Hawaii, USA, January. KELTER, U., WEHREN, J., NIERE, J., 2005, "A Generic Difference Algorithm for UML Models". In: Software Engineering (SE) 2005, pp. 105-116, Essen, Germany, March. KRUCHTEN, P.B., 2000, The Rational Unified Process: An Introduction, 2nd ed., Addison-Wesley. KRUEGER, C.W., 1992, "Software Reuse", ACM Computing Surveys, v. 24, n. 2 (June), pp. 131-183. LEE, K., KANG, K.C., LEE, J., 2002, "Concepts and Guidelines of Feature Modeling for Product Line Software Engineering". In: Software Reuse: Methods, Techniques, and Tools : 7th International Conference, ICSR-7, Proceedings pp. 62 - 77, Austin, TX, USA, April.

105

MEDVIDOVIC, N., TAYLOR, R., 2000, "A Classification and Comparison Framework for Software Architecture Description Languages", IEEE

Transactions on Software Engineering, v. 26, n. 1, pp. 70-93. MELO JR, C.R.S., 2005, Metrictool: Uma Ferramenta Parametrizvel para Extrao de Mtricas de Projetos Orientados a Objetos, Projeto Final de Graduao, IM, UFRJ, Rio de Janeiro, Brasil. MENDES, A., 2002, Arquitetura de Software: Desenvolvimento Orientado para Arquitetura, Rio de Janeiro, Brasil, Campus. METTALA, E., GRAHAM, M.H., 1992, The Domain-Specific Software Architecture, CMU/SEI, SEI Technical Report CMU/SEI-92-SR-009. MILER, N., 2000, A Engenharia de Aplicaes no Contexto da Reutilizao baseada em Modelos de Domnio, Dissertao de M.Sc, COPPE, UFRJ, Rio de Janeiro, Brasil. MONROE, R., KOMPANEK, A., MELTON, R., et al., 1997, "Architectural Styles, Design Patterns and Objects", IEEE Software, v. 14, n. 1 (January/February), pp. 43-52. MURTA, L.G.P., VASCONCELOS, A.P.V., BLOIS, A.P.B., et al., 2004, "Run-Time Variability through Component Dynamic Loading". In: Sesso de Ferramentas, XVIII Simpsio Brasileiro de Engenharia de Software, pp. 67-72, Braslia, Brasil, Outubro. NOKIA, 2007, "Nokia Support Glossary". In:

http://europe.nokia.com/support/glossaryCDAMaster/0,,lang_id=49&letter=0,00 .html, accessed in 19/06/2007. NORTHROP, L., 2002, "SEIs Software Product Line Tenets", IEEE Software, v. 19, n. 4 (July/August, 2002), pp. 32-40. ODYSSEY, 2007, "Projeto Odyssey". In: http://reuse.cos.ufrj.br/odyssey, accessed in 03/05/2007.

106

OLIVEIRA, R.F.D., 2006, Formalizao e Verificao de Consistncia na Representao de Variabilidades, Dissertao de M.Sc., COPPE, UFRJ, Rio de Janeiro, Brasil. OMG, 2001, Unified Modeling Language (UML) Specification, version 1.4, formal/0109-67, Object Management Group. OMG, 2005, "MetaObjectFacility (MOF) Specification - Version 1.4". In: accessed in

http://www.omg.org/technology/documents/formal/mof.htm, 08/09/2005.

OMG, 2002b, XML Metadata Interchange (XMI) Specification, version 1.2, formal/0201-01, Object Management Group. OMG, "Unified Modeling Language". In: http://www.uml.org/, accessed in 29/05/2007. PENEDO, M., RIDDLE, W., 1993, "Process-Sensitive SEE Architecture (PSEEA)", Software Engineering Notes, ACM SIGSOFT, v. 18, n. 3 (July), pp. A78-A94. PERRY, D.E., WOLF, A.L., 1992, "Foundations for the study of software architecture", SIGSOFT Softw. Eng. Notes, v. 17, n. 4 (1992), pp. 40-52. PRESSMAN, R.S., 2001, Software Engineering, a Practitioner's Approach, 5th ed., McGraw-Hill. PRIETO-DIAZ, R., ARANGO, G., 1991, "Domain Analysis Concepts and Research Directions", PRIETO-DIAZ, R., ARANGO, G. (eds), Domain Analysis and Software Systems Modeling, IEEE Computer Society Press, pp. 9-33. RICHNER, T., DUCASSE, S., 1999, "Recovering High-Level Views of ObjectOriented Applications from Static and Dynamic Information". In: International Conference on Software Maintenance (ICSM'99), pp. 13-22, Oxford, UK, September. RIVA, C., RODRIGUEZ, J.V., 2002, "Combining Static and Dynamic Views for Architecture Reconstruction". In: Sixth European Conference on Software Maintenance and Reengineering (CSMR02), pp. 47-56, Budapeste, Hungary, March. 107

SAMETINGER, J., 1997, Software Engineering with Reusable Components, SpringerVerlag New York, Inc. SEI/CMU, 2007, "A Framework for Software Product Line Practice - Version 4.2". In: http://www.sei.cmu.edu/productlines/framework.html, accessed in 21/06/2007. SHAW, M., GARLAN, D., 1996, Software Architecture: Perspectives on an Emerging Discipline, New Jersey, Prentice-Hall. SIMOS, M., ANTHONY, J., 1998, "Weaving the Model Web: A Multi-Modeling Approach to Concepts and Features in Domain Engineering". In: 5th International Conference of Software Reuse (ICSR-5), pp. 94-102, Victoria, British Columbia, Canada, June. STOERMER, C., OBRIEN, L., 2001, "MAP: Mining Architectures for Product Line Evaluations". In: 3rd Working IFIP Conference on Software Architecture (WICSA), pp. 35-44, Amsterdam, Holland, August. VASCONCELOS, A.P.V., 2004, Uma Abordagem para Recuperao de Arquitetura de Software Visando sua Reutilizao em Domnios Especficos, Exame de Qualificao, COPPE, UFRJ, Rio de Janeiro, Brasil. VASCONCELOS, A.P.V., 2007, Uma Abordagem de Apoio Criao de Arquiteturas de Referncia de Domnio Baseada na Anlise de Sistemas Legados, Tese de DSc., UFRJ, Rio de Janeiro - Brasil. VICI, A.D., ARGENTIERI, N., 1998, "FODAcom: An Experience with Domain Analysis in the Italian Telecom Industry". In: Fifth International Conference on Software Reuse (ICSR5) pp. 166-175, Victoria, British Columbia, Canada, April. WALLNAU, K.C., HISSAM, S.A., SEACORD, R.C., 2002, Building Systems from Commercial Components, 1st ed., Boston, USA, Addison-Wesley. WERNER, C.M.L., BRAGA, R.M.M., 2005, "A Engenharia de Domnio e o Desenvolvimento Baseado em Componentes". In: GIMENES, I.M.S., HUZITA, E.H.M. (eds), Desenvolvimento Baseado em Componentes: Conceitos e Tcnicas, Rio de Janeiro, Cincia Moderna.

108

WESTHUIZEN, C.V.D., HOEK, A.V.D., 2002, "Understanding and Propagating Architecutural Changes ". In: Proceedings of the IFIP 17th World Computer Congress - TC2 Stream / 3rd IEEE/IFIP Conference on Software Architecture: System Design, Development and Maintenance, pp. 95-109 Montral, Qubec, Canada, August. WOHLIN, C., RUNESON, P., HST, M., et al., 2000, Experimentation in Software Engineering: an Introduction, USA, Kluwer Academic Publishers. XAVIER, J.R., 2001, Criao e Instanciao de Arquiteturas de Software Especficas de Domnio no Contexto de uma Infra-Estrutura de Reutilizao, Dissertao de M.Sc., COPPE, UFRJ, Rio de Janeiro, Brasil. XML, 2007, "Extended Markup Language". In: http://www.xml.org, accessed in 11/06/2007.

109

Anexo I: Formulrio de Consentimento

CRIAO DE UMA ARQUITETURA DE REFERENCIA PARA UM DOMNIO
Eu declaro ter mais de 18 anos de idade e concordar em participar de um estudo conduzido por Guilherme Zanetti Kmmel, como parte das atividades para obteno do ttulo de Mestre, no Programa de Engenharia de Sistemas e Computao da COPPE/UFRJ. Este estudo visa compreender a aplicabilidade da abordagem ArchToDSSA no apoio na tarefa de criao de uma arquitetura de referencia no domnio;

PROCEDIMENTO Este estudo acontecer em duas etapas. Primeiro apresentado o aparato necessrio para a criao de uma arquitetura de referncia no domnio e as arquiteturas a serem analisadas, bem como instrues para a realizao da tarefa, documentos que sero utilizados neste estudo. Na segunda etapa os participantes devero utilizar o aparato apresentado previamente para a criao de uma arquitetura de referncia. Eu entendo que, uma vez o experimento tenha terminado, os trabalhos que desenvolvi, sero estudados visando entender a eficincia dos procedimentos e as tcnicas que me foram ensinadas. CONFIDENCIALIDADE Toda informao coletada neste estudo confidencial, e meu nome no ser identificado em momento algum. Da mesma forma, me comprometo a no comunicar os meus resultados enquanto no terminar o estudo, bem como manter sigilo das tcnicas e documentos apresentados e que fazem parte do experimento. BENEFCIOS, LIBERDADE DE DESISTNCIA Eu entendo que os benefcios que receberei deste estudo so limitados ao aprendizado do material que distribudo e ensinado, independente de participar ou no deste estudo, mas que os pesquisadores esperam aprender mais sobre quo eficiente a utilizao da abordagem ArchToDSSA para a criao de uma arquitetura de referencia no domnio. Eu entendo que sou livre para realizar perguntas a qualquer momento ou solicitar que qualquer informao relacionada a minha pessoa no seja includa no estudo. Eu entendo que participo de livre e espontnea vontade com o nico intuito de contribuir para o avano e desenvolvimento de tcnicas e processos para a Engenharia de Software. EQUIPE: PESQUISADOR RESPONSVEL Guilherme Zanetti Kummel Programa de Engenharia de Sistemas e Computao - COPPE/UFRJ PROFESSOR RESPONSVEL Profa. Cludia M.L. Werner Programa de Engenharia de Sistemas e Computao - COPPE/UFRJ

Nome (em letra de forma):________________________________________

Assinatura:

________________________________ Data:__________

110

Anexo II: Leitura Introdutria

Na atividade de projeto de qualquer sistema, a especificao de uma arquitetura de software representa um dos primeiros passos. Segundo a literatura, um das definies para arquitetura de software :
A arquitetura de um sistema consiste da(s) estrutura(s) de suas partes (incluindo as partes de software e hardware envolvidas no tempo de execuo, projeto e teste), da natureza e das propriedades relevantes que so externamente visveis destas partes (mdulos com interfaces, unidades de hardware, objetos), e dos relacionamentos e restries entre elas (D'SOUZA & WILLS, 1999).

No contexto da reutilizao de software, quando as arquiteturas so especificadas atravs de elementos especializados no Domnio, generalizados para uso efetivo dentro do domnio e compostos em um padro de estrutura eficaz para a construo de uma famlia de aplicaes, elas so definidas como a Arquitetura de Referncia do domnio ou DSSA (Domain Specific Software Architecture). A criao de uma DSSA importante nas abordagens de reutilizao como Engenharia de Domnio e Linha de Produtos de Software, pois ela a base para a instanciao de aplicaes em um domnio de aplicao especfico. Um de seus principais objetivos propor uma soluo estruturada para a construo de uma famlia de aplicaes capazes de atender aos requisitos de um determinado domnio. Atravs da reutilizao de arquiteturas, o compartilhamento de idias, mtodos, componentes e conhecimento dentro de um conjunto de aplicaes similares, tornamse mais efetivos para se obter nveis superiores de qualidade e produtividade durante o processo de construo de sistemas. Uma maneira de se especificar uma arquitetura de referncia examinando-se e comparando-se vrias arquiteturas existentes para um mesmo domnio. Para tanto, os sistemas legados constituem uma das maiores fontes. No estudo de observao que voc ir participar, utilizada uma abordagem, isto , um mtodo para a especificao de arquitetura de referncia (DSSA) a partir da comparao de arquiteturas existentes. Tal abordagem denominada ArchToDSSA e tem o objetivo de apoiar o Engenheiro de domnio na especificao da DSSA, e conseqentemente na reutilizao de software. A abordagem ArchToDSSA prope uma srie de passos para se chegar DSSA, tal com descrito a seguir:

111

1. Identificao de equivalncias e opcionalidade. O primeiro passo identificao de elementos equivalentes nas diferentes arquiteturas, aqui denominados equivalncias. Uma equivalncia identificada para se unificar as nomenclaturas de elementos arquiteturais, que na maioria das vezes no so especificados pela mesma equipe ou empresa. Assim, um match possibilita, por exemplo, que um elemento que em uma arquitetura denominado Caixa seja equivalente a um elemento que foi denominado Cx. em outra arquitetura. Identificados as equivalncias possvel detectar se cada elemento na arquitetura ser opcional ou mandatrio na DSSA. A definio de elemento opcional e mandatrio em um domnio pode ser encontrada em (OLIVEIRA, 2006), como segue: Elementos Opcionais: elementos que podem ou no estar presentes em aplicaes instanciadas a partir de um domnio. Elementos Mandatrios: elementos que devem obrigatoriamente estar presentes em aplicaes instanciadas a partir de um domnio. Se para cada elemento da arquitetura, existir um elemento equivalente em todas as outras arquiteturas, esse elemento considerado mandatrio. Caso contrrio, considerado opcional na DSSA. 2. Identificao dos Pontos de Variao e Variantes A definio de ponto de variao (VP) e variantes pode tambm ser encontrada em (OLIVEIRA, 2006). Resumindo: Pontos de Variao: pontos que refletem a parametrizao (possibilidade de configurao) no domnio de uma maneira abstrata e so configurveis atravs das variantes. Variantes: alternativas de implementao disponveis, elementos

necessariamente ligados a um ponto de variao, que atuam como alternativas para se configurar aquele ponto de variao. Para uma DSSA fundamental especificar quais elementos arquiteturais devero estar obrigatoriamente em todas as aplicaes derivadas e quais podem ser suprimidos. Para tanto, a abordagem ArchToDSSA elementos da seguinte forma: sugere a identificao de tais

Pontos de Variao Interfaces Generalizaes (Superclasses)

Variantes Elementos que implementam a Interface Especializaes (Subclasses)

112

Assim, se, por exemplo, uma Interface for selecionada como parte de uma DSSA, provavelmente ela ser um ponto de variao nesta arquitetura e as classes que a implementam devem tambm ser selecionadas como suas variantes. 1. Criao da DSSA Uma vez identificados todos os elementos opcionais e mandatrios, pontos de variao e suas variantes e os elementos equivalentes nas arquiteturas, o prximo passo especificar a DSSA. Nesse ponto, sugere-se o seguinte processo: Escolher uma das arquiteturas comparadas para servir como base. Isto necessrio para se manter os relacionamentos existentes entre os elementos arquiteturais de maneira consistente. Levar para a DSSA todos os elementos mandatrios de todas as arquiteturas comparadas. No entanto, quando os elementos possuem equivalncia com outros elementos, apenas um deles deve ser levado. Levar para a DSSA todos os pontos de variao e suas variantes. No entanto, se um ponto de variao possui pontos de variao equivalentes em outras arquiteturas, mas possui variantes diferentes, todas as variantes devem ser levadas, mantendo-se seu atributo de opcionalidade. Exemplo de Utilizao da Abordagem Como exemplo de utilizao da abordagem, sero apresentadas partes de duas arquiteturas do domnio de MP3Players, que sero comparadas no intuito de originar uma DSSA. .
Arquitetura 1 MP3Player_1 o Diversos Equalizer GerenteMemoAM/FM MemoAM MemoFM GerenteSom MegaBassDigital AVLS Microfone o Principal MP3Player o GerenteConexao ConexaoUSB HiSpeedUSB DirectUSB o GerenteReproducao Reproducao WMA Mp3 Arquitetura 2 MP3Player_2 o Diversos Equalizador GerenteMemoriaRadio MemoriaAM MemoriaFM Display I3DTag Simples o Principal MP3Player o GerenteConexao ConexaoUSB HiSpeedUSB DirectUSB o GerenteReproducao FormatoReproducao MP3 WMA Atrac3Plus

113

No caso das duas arquiteturas, pode-se identificar alguns elementos que, embora tenham nomes diferentes, possuem o mesmo significado, tais como Equalizador poderiam ser = Equalizer, = FormatoReproduo Assim, por matches, = Reproduo essas aqui e

GerenteMemoriaRadio

GerenteMemoAM/FM.

equivalncias Equalizador,

representadas

denominados

Reproduo e MemoriaRadio, por exemplo. Para identificar a opcionalidade dos elementos, deve-se observar se cada elemento possui equivalncia com todas as outras arquiteturas. Nesse caso, os elementos participantes dos matches acima citados seriam mandatrios, enquanto outros elementos, tais como Microfone e AVLS (Sistema de limitao automtica de volume), na Arquitetura 1, so elementos opcionais. Como exemplo de pontos de variao nessas arquiteturas, tem-se o FormatoReproducao, que possui as variantes MP3, WMA e ConexaoUSB, com as variantes HiSpeedUSB e DirectUSB. Tomando a Arquitetura 1 como arquitetura-base, a DSSA sugerida, segundo a abordagem seria a seguinte:
DSSA o Diversos Equalizer (M) GerenteMemoAM/FM (M) MemAM (M) MemoFM (M) GerenteSom (O) MegaBassDigital (O) AVLS (O) Microfone (O) o o Principal MP3Player (M) GerenteConexao ConexaoUSB (M) HiSpeedUSB (M) DirectUSB (M) GerenteReproducao (M) Reproducao (M) MP3 (M) WMA (M) Atrac3Plus (O) Display (O) I3Dtag (O) Simples (O)

Atrac3Plus,

GerenteMemoriaRadio, com as variantes MemoriaAM e MemoriaFM e e

No exemplo acima, os elementos em preto fazem parte da Arquitetura 1, arquitetura-base, os elementos em azul foram trazidos da Arquitetura 2. Os sinais (M) e (O) significam, respectivamente, mandatrio e opcional. Note que es elementos considerados mandatrios so aqueles que possuem equivalncias nas duas arquiteturas. Os demais so considerados opcionais.

114

Anexo III: Instrues para Execuo dos Estudos de Observao

Avaliao da Abordagem ArchToDSSA Primeiro Estudo de Observao Instrues
Voc participar de um estudo de observao que visa avaliar a utilizao da abordagem ArchToDSSA para apoio especificao de uma arquitetura de referncia no domnio. Tal estudo ser dividido em duas etapas, de acordo com as instrues contidas neste documento. Voc deve ter recebido juntamente com esta folha de instrues os seguintes documentos: Leitura Introdutria Representao da Arquitetura de Sistema Legado, Arquiteturas A, B e C. Formulrio de Registro de Equivalncias Identificadas Formulrio de Registro de Pontos de Variao Identificados Formulrio de Registro de Variantes Identificadas IMPORTANTE: Para a realizao de ambas as etapas, a leitura introdutria j deve ter sido realizada.

1 Etapa: Criao de uma DSSA em um primeiro domnio Nesta etapa do estudo, voc dever seguir os passos sugeridos pela abordagem e criar uma DSSA. Para isso, voc dever: 1. Examinar as arquiteturas A, B e C e identificar elementos equivalentes. S devero ser considerados equivalncias os elementos que tiverem equivalentes nas trs arquiteturas. Nomear as equivalncias e identificar os elementos relacionados pelo nome da arquitetura e a linha do elemento na arquitetura. Ex. Telefone = A1, B4, C25 2. Para cada arquitetura, identificar pontos de variao e anotar no formulrio apropriado. 3. Para cada arquitetura, identificar variantes e anotar no formulrio apropriado. 4. Escolher uma das arquiteturas como base e montar sobre ela a DSSA resultante, escrevendo os elementos das outras arquiteturas que voc julgar que devem compor a DSSA.

2 Etapa: Criao de uma DSSA em um segundo domnio Nesta etapa do estudo, voc dever repetir os procedimentos realizados na primeira etapa, porm trabalhando em um domnio diferente do que foi apresentado anteriormente.

Obrigado pela sua participao!

115

Avaliao da Abordagem ArchToDSSA Segundo Estudo de Observao Instrues

Voc participar de um estudo de observao que visa avaliar a utilizao da abordagem ArchToDSSA e sua ferramenta de apoio, ArchToDSSATool, para apoio

especificao de uma arquitetura de referncia no domnio. Tal estudo ser dividido em duas etapas, de acordo com as instrues contidas neste documento. Voc deve ter recebido juntamente com esta folha de instrues os seguintes documentos: Leitura Introdutria Arquivos no formato XMI, representando arquiteturas de sistemas legados.

IMPORTANTE: Para a realizao de ambas as etapas, a leitura introdutria e o treinamento na ferramenta j devem ter sido realizados.

1 Etapa: Criao de uma DSSA em um primeiro domnio Nesta etapa do estudo, voc dever seguir os passos sugeridos pela abordagem e criar uma DSSA com o auxlio da ferramenta. Para isso, voc dever: 1. Identificar e validar as equivalncias. S devero ser considerados equivalncias os elementos que tiverem equivalentes nas trs arquiteturas; 2. 3. 4. Identificar os pontos de variao; Identificar as variantes; Escolher a arquitetura base e selecionar os elementos das outras arquiteturas que voc julgar que devem compor a DSSA. 5. Exportar a DSSA criada para um arquivo XMI.

2 Etapa: Criao de uma DSSA em um segundo domnio Nesta etapa do estudo, voc dever repetir os procedimentos realizados na primeira etapa, porm trabalhando em um domnio diferente do que foi apresentado anteriormente.

Obrigado pela sua participao!

116

Anexo IV: Formulrios de Registro de Resultados

Formulrio de Registro de Equivalncias Identificadas Participante:___________________________Domnio:_________________________

Nome da equivalncia

Elementos Participantes

117

Formulrio de Registro de Pontos de Variao Identificados

Participante:__________________________Domnio:__________________________

Arquiteturas

Pontos de Variao

Arquitetura A

Arquitetura B

Arquitetura C

Formulrio de Registro de Variantes Identificadas Participante:__________________________Domnio:__________________________

Arquiteturas

Variantes

Arquitetura A

Arquitetura B

Arquitetura C

118

Anexo V: Representao das Arquiteturas de Sistemas Legados

Representao da Arquitetura de Sistema Legado Domnio: Telefonia Celular Arquitetura A
1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. o o o o Telefonia_Celular_1 o Diversos Idioma Contraste PapelPArede Mensagem CaixaPostal Principal TelefoneCelular GerenteSom ToquesMusicais Alarme GerenteJogos Jogos GerenteAgenda GrupoUsuario Usuario Agenda Snake CarRacer ToquesSimples ToquesPolifnicos Simplificada Completa

Calculadora

Campainha

Legenda: Palavras em Negrito representam Pacotes Palavras em Itlico representam Superclasses e/ou Interfaces

119

Representao da Arquitetura de Sistema Legado Domnio: Telefonia Celular Arquitetura B

1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25.

Telefonia_Celular_2 o GerentePlanoFundo PlanoFundo Lingua o GerenteCaixaPostal Mensagem CaixaPostal o GerenteAlarme Alarme o Principal TelefoneCelular o GerenteCampainha ToquesMusicais Campainha o GerenteEntretenimento MP3 Jogos o GerenteUsuario GrupoUsuario Usuario Agenda Paciencia BlackJack Texto Voz

Legenda: Palavras em Negrito representam Pacotes Palavras em Itlico representam Superclasses e/ou Interfaces

120

Representao da Arquitetura de Sistema Legado Domnio: Telefonia Celular Arquitetura C

1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. o o o Som Despertador Campainha ToquesMusicais Principal Telefone Diversos Calculadora CaixaPostal Simplificada Completa o Telefonia_Celular_3 o Agenda Agenda Usuario JogosCelular Jogos o o o Snake Pinball BlackJack UsuarioComum UsuarioEspecial

GrupoUsuario

Mensagem PapelParede Contraste Idioma Bluetooth

Legenda: Palavras em Negrito representam Pacotes Palavras em Itlico representam Superclasses e/ou Interfaces

121

Representao da Arquitetura de Sistema Legado Domnio: Escolar Arquitetura A

1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42.

Escola_1 o Pessoas Pessoa Funcionrio o o o Carreira rea o Estrutura Contedo Primeiro Grau Segundo Grau o o Cursinho o o o Turma Sala Matria o Provas Provas Abertas Provas Fechadas Modalidades de Prova Provas Convencionais o o o Matrcula Matrcula o Aulas Aula Aulas primeiro grau e segundo grau Aulas Cursinho Aulas Especiais Matrcula Primeiro Grau e Segundo Grau Matrcula Simulado Matrcula Cursinho Simulados Pism Bimestrais Extensivo Intensivo Recordao Convencional Pism Professor Coordenador Zelador

Responsvel Aluno

Legenda: Palavras em Negrito representam Pacotes Palavras em Itlico representam Superclasses e/ou Interfaces

122

Representao da Arquitetura de Sistema Legado Domnio: Escolar Arquitetura B

1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. Sala o Aulas Aula Aulas fundamental e mdio Aulas Pr-Vestibular o Matrcula Inscrio Inscrio Pr-Vestibular Inscrio Fundamental e Mdio Inscrio Simulado o o Simulado Aberto Simulado Fechado o Provas Provas Dissertativas Provas Mltipla Escolha Avaliaes Prova Padro o o Provas do Programa de Ingresso Seletivo misto Provas Bimestrais Disciplinas o Estrutura Programao Pr-Vestibular o o Reforo Intenso Carreira rea Escola_2 o Pessoas Pessoa Pessoa Fsica o o o Supervisor Docente Aluno

Pessoa Jurdica

Fundamental Mdio o o Padro Programa Ingresso seletivo Misto

Provas de Simulao

Legenda: Palavras em Negrito representam Pacotes

Representao da Arquitetura de Sistema Legado Palavras em Itlico representam Superclasses e/ou Interfaces

123

Domnio: Escolar

Arquitetura C
1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. o Aulas Aula Aulas do ensino fundamental e mdio Aulas para Vestibular Aulas recordao o Matrcula Matrcula Matrcula primeiro e segundo grau Matrcula Pr-Vestibular Matrcula Simulado Fechado Matrcula Simulado Aberto o Provas Provas Provas para fundamental e mdio o o Provas Pism Provas Bimestrais Matria o Estrutura Contedo Programtico Ensino Fundamental Ensino Mdio Vestibular o o o Completo Compacto Recordao Escola_3 o Pessoas Pessoa Funcionrio o o o Educadores Zelador Diretor

Responsvel Estudante Estudante

Cursos de Frias

Provas Pr-Vestibular o o Dissertativas Fechadas

Matrcula Prova Simulado o o

Legenda: Palavras em Negrito representam Pacotes Palavras em Itlico representam Superclasses e/ou Interfaces

124

Anexo VI: Dicionrio de Sinnimos do Domnio

Domnio Telefonia Celular Idioma = Lngua TelefoneCelular = Telefone Alarme = Despertador PapelParede = PlanoFundo Caixa = Cx Jogo = Game Tela = Display Conexo = Ligao Toque = RingTone

Palavras ignoradas Gerente View Domnio Escolar Professor = Docente = Educadores Turma = Sala Aulas primeiro grau e segundo grau = Aulas fundamental e mdio = Aulas do ensino fundamental e mdio Aulas cursinho = Aulas pr-vestibular = Aulas para vestibular Aulas especiais = Aulas de reforo = Aulas recordao Matria = Disciplinas Contedo = Programao = Contedo programtico Primeiro grau = Fundamental = Ensino fundamental Segundo grau = Mdio = Ensino mdio Convencional = Padro = Ensino Convencional Pism = Programa de ingresso seletivo misto = Ensino Pism Cursinho = Pr-vestibular = Vestibular Especial = Reforo = Recordao Extensivo = Estendido = Completo Intensivo = Intenso = Compacto

125

Matrcula = Inscrio Matrcula simulado = Inscrio simulado = Matrcula prova simulado Matricula primeiro grau e segundo grau = Inscrio fundamental e mdio = Matricula primeiro e segundo grau

Matrcula cursinho = Inscrio pr-vestibular = Matrcula pr-vestibular Funcionrio = Pessoa fsica Coordenador = Supervisor = Diretor Zelador = Servente Aluno = Estudante Responsvel = Responsvel estudante Modalidades de prova = Avaliaes = Provas Provas convencionais = Prova padro = Provas para fundamental e mdio Bimestrais = Provas bimestrais Prova Pism = Provas do Programa de ingresso seletivo misto Prova fechada = Provas mltipla escolha = Fechada Provas abertas = Provas dissertativas = Dissertativas Simulados = Prova de simulao = Prova pr-vestibular Simulado fechado = Matrcula simulado fechado Simulado aberto = Matrcula simulado aberto Prova = Provas

Palavras ignoradas Aulas

126

Anexo VII: Formulrio de Caracterizao dos Participantes

Caracterizao do Participante
Nome ________________________________________ Nvel (Graduao Mestrado, Doutorado): ____________ Formao Geral Qual sua experincia anterior com desenvolvimento de software na prtica ? (marque aqueles itens que melhor se aplicam) __ nunca desenvolvi software. __ tenho desenvolvido software para uso prprio. __ tenho desenvolvido software como parte de uma equipe, relacionado a um curso. ___tenho desenvolvido software como parte de uma equipe, na indstria. Por favor, explique sua resposta. Inclua o nmero de semestres ou nmero de anos de experincia relevante em desenvolvimento (e.g. Eu trabalhei por 10 anos como programador na indstria):

Experincia em Desenvolvimento de Software Por favor, indique o grau de sua experincia nesta seo seguindo a escala de 5 pontos abaixo: 1 = nenhum 2 = estudei em aula ou em livro 3 = pratiquei em 1 projeto em sala de aula 4 = usei em 1 projeto na indstria 5 = usei em vrios projetos na indstria Experincia com Requisitos Experincia escrevendo requisitos 1 2 3 4 5 Experincia escrevendo casos de uso 1 2 3 4 5 Experincia modificando requisitos para manuteno 1 2 3 4 5 Experincia em Arquitetura de Software Experincia em projeto de arquitetura de software 1 2 3 4 5 Experincia em leitura de documento arquitetural 1 2 3 4 5

Experincia em Projeto Experincia em projeto de sistemas 1 2 3 4 5 Experincia em desenvolver projetos a partir de requisitos e casos de uso 1 2 3 4 5 Experincia criando projetos Orientado a Objetos 1 2 3 4 5 Experincia lendo projetos Orientado a Objetos 1 2 3 4 5 Experincia com Unified Modeling Language (UML) 1 2 3 4 5 Experincia alterando projeto para manuteno 1 2 3 4 5 Para a questo a seguir, considere a seguinte escala de experincia: 1 = nenhuma 2 = j li a respeito 3 = j estudei a respeito 4 = j utilizei aplicaes 5 = j desenvolvi aplicaes Experincia no domnio de Escolas Experincia no domnio de Telefonia Celular

127

Anexo VIII: Avaliao Subjetiva

Avaliao do Primeiro Estudo de Observao
1) Os conceitos de Arquiteturas e DSSA j eram de seu conhecimento antes do estudo realizado? E depois? 2) Qual o grau de dificuldade ou facilidade em realizar as etapas sugeridas? Explique. 3) A abordagem de alguma forma o ajudou na comparao de arquiteturas e criao da DSSA? 4) Como a abordagem poderia ser melhorada? 5) Acredita que uma ferramenta iria ajud-lo na execuo das tarefas? De que forma?

Avaliao do Segundo Estudo de Observao

1) Os conceitos de Arquiteturas e DSSA j eram de seu conhecimento antes do estudo realizado? E depois?

2) Qual o grau de dificuldade ou facilidade em realizar as etapas sugeridas? Explique. 3) A Ferramenta de alguma forma o ajudou na comparao de arquiteturas e criao da DSSA? 4) Como a ferramenta poderia ser melhorada? 5) Como seria este processo sem a ferramenta? Fcil, Difcil, Rpido, Demorado... Explique

6) A ferramenta apresentada pode ser utilizada em alguma etapa do desenvolvimento de software da sua rea de trabalho?

128