3° Entregável: Monografia - DIMAp

Universidade Federal do Rio Grande do NorteCentro de Ciências Exatas e da TerraDepartamento de Informática e Matemática AplicadaPROGRAMA CTICREDE NACIONAL DE ENSINO E PESQUISAGingaForAll - Arquitetura e Ferramenta para Concepção de Linhas deProdutos do GingaCC para MultiredesEntregável do Terceiro Trimestre – Outubro de 2009Monografia – Processo de Desenvolvimento para Linha de Produtos GingaEquipe Técnica:Prof° Dra Thaís Vasconcelos Batista (Coordenadora)Profª Drª Flávia Coimbra DelicatoProf° Dr Paulo de Figueiredo PiresProfª Drª Roberta de Souza CoelhoProf° Dr Uirá KuleszaAna Liz Souto OliveiraErick Odlanier do Nascimento Xavier CortezHeitor Mariano de Aquino CâmaraMsc. José Diego Saraiva da SilvaLucas Silva PereiraRodrigo Pinheiro Marques de AraújoMsc. Sindolfo Luiz de Miranda Freire FilhoMsc. Tássia Aparecida Vieira de Freitas

Visão Geral do DocumentoO projeto GingaForAll tem como objetivo central refatorar a arquitetura do middleware Gingacom o objetivo de gerar uma Linha de Produto de Software (LPS) através da definição de umaabordagem baseada em engenharia dirigida por modelos [1] em conjunto com orientação a aspectos[2]. A partir dessa arquitetura refatorada será possível gerar personalizações do middleware Gingacontemplando diferentes segmentos e requisitos do mercado.Este documento está dividido em três partes: (i) a primeira parte apresenta uma visão geral dasabordagens empregadas para realizar a integração das seguintes técnicas de desenvolvimento desoftware: linhas de produto de software, desenvolvimento dirigido a modelos e o desenvolvimentoorientado a aspectos. Em seguida é proposto um processo para construção da família de produtosGinga e para derivação dos produtos individuais, que unifica as técnicas citadas anteriormente; (ii) asegunda parte do documento destina-se à apresentação do processo de avaliação da arquitetura eda implementação do Ginga Common Core. Essa parte descreve o sistema de avaliaçãoselecionado para realizar a análise da arquitetura do Ginga Common Core e apresenta osresultados obtidos pela aplicação desse sistema; (iii) a terceira parte do documento é focadaem apresentar, com detalhes, os diversos meios de transmissão de conteúdo televisivo via ainternet. O objetivo dessa parte do documento é identificar as principais variações esimilaridades entre os meios de transmissão apresentados, de modo a complementar o modelode variabilidades da família de software proposta.2

SumárioPARTE I ......................................................................................................................................... 61 Introdução ................................................................................................................................. 61.1 Objetivos ............................................................................................................... 81.2 Organização do Documento .................................................................................. 92 Estado da Arte na Integração de LPS com outras técnicas de Engenharia de Software ... 92.1 Vantagens de Integração ....................................................................................... 92.2 Abordagens de Integração entre LPS E DSOA .................................................. 112.3 Abordagens de Integração Entre LPS E DDM ................................................... 202.4 Abordagens de Integração entre LPS, DSOA E MDD ....................................... 393 Abordagem Dirigida por Modelos para Desenvolvimento do GINGA .............................. 423.1 Detalhamento da Abordagem .............................................................................. 433.2 Descrição dos Metamodelos ............................................................................... 533.3 Modelagem dos Aspectos ................................................................................... 614 Ferramentas, Tecnologias e Linguagens Utilizadas ............................................................. 634.1 CrossMDA .......................................................................................................... 644.2 Eclipse Galileo .................................................................................................... 684.3 UML e MOF ....................................................................................................... 694.4 Profile UML ........................................................................................................ 714.5 EMF e Ecore ....................................................................................................... 724.6 Acceleo ................................................................................................................ 723

Referências ............................................................................................................................... 75PARTE II ..................................................................................................................................... 795 Introdução ............................................................................................................................... 795.1 Visão Geral da Avaliação do Ginga CC ............................................................. 806 Sistema de Avaliação .............................................................................................................. 817 Tarefas no Contexto desse Projeto ........................................................................................ 848 Métricas de Acomplamento para Implementação ............................................................... 878.1 Pacote GingaCC-Player ...................................................................................... 898.2 Pacote gingacc-contextmanager ......................................................................... 938.3 Pacote Gingacc-ic ............................................................................................... 948.4 Pacote Gingacc-cm ............................................................................................. 948.5 gingacc-um .......................................................................................................... 958.6 Pacote gingacc-dataprocessing ........................................................................... 968.7 Pacote gingacc-system ...................................................................................... 1028.8 Pacote gingacc-tsparser ..................................................................................... 1058.9 Pacote gingacc-tuner ......................................................................................... 1089 Métricas de Tamanho para Implementação ...................................................................... 11010 Discussão dos Resultados ..................................................................................................... 11110.1 Relação entre Variabilidades do Modelo de Features e Acoplamento presenteno GingaCC 112Referências ............................................................................................................................. 114PARTE III .................................................................................................................................. 1154

11 IPTV, InternetTV e P2PTV ................................................................................................. 11511.1 IPTV .................................................................................................................. 11511.2 InternetTV ......................................................................................................... 12111.3 P2PTV ............................................................................................................... 12212 Modelo de Features ............................................................................................................... 124Referências ............................................................................................................................. 126Apêndice A ................................................................................................................................. 1281. Aplicando Conejero ........................................................................................................... 1281.1 Análise orientada a features ......................................................................................... 1281.2 Elicitação dos requisitos não funcionais ...................................................................... 1301.3 Modelagem dos requisitos ............................................................................................ 1301.4 Identificando os conceitos transversais ........................................................................ 1311.4.1 Construção de uma matriz de dependência .................................................................. 1311.4.2 Construção de uma matriz de transversalidade ............................................................ 1355

PARTE I1 IntroduçãoA abordagem de desenvolvimento baseado em linha de produtos de software – LPS (ou eminglês Software Product Line - SPL) consiste em uma estratégia de construção de software quefocaliza um domínio específico, usando como base uma infra-estrutura comum de artefatos de código.Uma linha de produtos é formada por uma família de produtos, pertencentes a um determinadodomínio de aplicação, e que possuem como base uma arquitetura comum. Uma LPS compartilhafuncionalidades comuns e define funcionalidades específicas, as quais variam de acordo com cadaproduto em particular [3].A efetividade de uma abordagem de LPS depende diretamente de como a variabilidade dascaracterísticas dos produtos é gerenciada, desde a análise até a implementação, englobando também osestágios de derivação, manutenção e evolução. As características comuns e variáveis, relativas aosrequisitos dos produtos, são modeladas e implementadas pelos ativos base (core assets) erepresentadas em um modelo de features, ou seja, em um modelo que representa as característicascomuns e variáveis do domínio em questão. Essa captura de características é realizada durante a etapade engenharia de domínio. Na etapa seguinte, a engenharia de aplicação, produtos sãoautomaticamente, semi-automaticamente ou manualmente sintetizados e gerados, usando os ativosbase criados durante o processo de engenharia de domínio, podendo ser complementados comartefatos específicos do produto [5]. Os produtos são geralmente diferenciados pelo conjunto decaracterísticas que eles incluem a fim de completar os requisitos necessários para implementá-los.O gerenciamento de variabilidades consiste nas atividades de identificação, projeto eimplementação das características variáveis, assim como no rastreamento dessas características aolongo dessas atividades em uma linha de produtos de software. A variabilidade das características,freqüentemente, gera um impacto em vários artefatos em diversos estágios do ciclo de vida doproduto, tornando-se um desafio para a Engenharia de Linhas de Produto de Software. Nas abordagenstradicionais de LPS, a variabilidade é principalmente manipulada usando mecanismos das própriaslinguagens de implementação, tais como padrões, frameworks, polimorfismo, reflexão e précompilação,no intuito de selecionar as características variantes presentes nos ativos base [6].6

Entretanto, novas formas de gerenciamento de variabilidades podem ser criadas, através dasinergia entre abordagens de LPS e outras técnicas modernas da engenharia de software. Asabordagens de desenvolvimento de software dirigido por modelo - DDM (do inglês, Model DrivenDevelopment MDD [7]) e de desenvolvimento orientado a aspectos (DSOA) [8] emergem como duastécnicas promissoras para serem integradas a LPS, podendo-se obter grandes benefícios com essaintegração. DDM em particular tem se mostrado como uma técnica promissora para auxiliar ogerenciamento de variabilidades em LPSs. A abordagem de desenvolvimento dirigido por modelosapresenta-se como uma forma de desenvolvimento de software na qual modelos são criados emdiferentes níveis de abstração. Esses modelos são refinados por processos de transformações,reduzindo a abstração até o nível de dependência da plataforma computacional onde o sistema seráimplementado. A principal proposta do DDM não consiste na criação de famílias de produtos, todavia,a separação de domínios e sua natureza generativa tornam essa metodologia uma abordagem útil paraa criação de LPSs. Resultados de pesquisas recentes mostram como o uso do DDM em conjunto com aengenharia da linha de produtos de software (MD-LPS) facilita a definição do processo de criação dalinha de produto [37] [38].O desenvolvimento orientado a aspectos (DSOA) [8] trata da aplicação do Paradigma deOrientação a Aspectos (POA) na construção de sistemas de software, empregando a idéia de separaçãode conceitos transversais em todas as fases do ciclo de vida de um software, desde a elicitação derequisitos até a implementação. O DSOA visa melhorar a modularização dos sistemas de softwareatravés da separação dos vários conceitos envolvidos em sua construção em dois tipos distintos deelementos: os componentes e os aspectos. Os componentes são elementos responsáveis por encapsularconceitos que podem ser modularizados por procedimentos generalizados (objeto, método,procedimento ou API). Por sua vez, os aspectos são elementos que encapsulam conceitos transversais[8]. Os conceitos transversais caracterizam-se por estarem espalhados (scattered) e entrelaçados(tangled) com outros requisitos pelo código do sistema, o que dificulta a programação, a compreensão,a legibilidade e a manutenibilidade dos softwares [10]. Neste contexto, o termo código espalhadorefere-se à implementação de um conceito em múltiplos módulos e o termo código entrelaçado refereseà implementação de um componente em um sistema que interage simultaneamente com váriosconceitos. A principal motivação para DSOA surge do fato de que as técnicas de programação atualconseguem expressar muito bem o comportamento das entidades principais do sistema, mas falhamem capturar interesses transversais. O uso de OA tende a gerar sistemas flexíveis e bemmodularizados, contribuindo para a manutenção, extensibilidade, compreensão, dentre outrasqualidades desejáveis do software.7

No contexto das linhas de produto de software, DSOA pode ser aplicado como umaabordagem para ajudar na identificação e no gerenciamento das variabilidades de uma LPS. Dentre asvantagens obtidas com o uso de DSOA em LPS pode-se citar a promoção da separação clara entrefeatures identificadas como transversais e as não transversais, contribuindo para sua modularização e oconseqüente reuso dos artefatos de software produzidos. Além disso, o uso de mecanismos OA facilitaa configuração e customização de produtos específicos. O processo proposto no presente projetoenvolve a identificação dos casos de usos, a elaboração do modelo de features, a realização de umrastreamento entre os conceitos transversais e as features para a identificação de conceitos transversaise o encapsulamento desses conceitos em aspectos.Baseado nessas constatações, o projeto GingaForAll tem como objetivo utilizar os potenciaisbenefícios que podem advir do uso das abordagens de desenvolvimento dirigido por modelos e dedesenvolvimento orientado a aspectos em conjunto com a abordagem de linhas de produto desoftware, para apresentar uma solução de criação de uma família de produtos do middleware de TVDigital brasileiro, o Ginga. Este trabalho apresenta uma solução preliminar que se encontra emdesenvolvimento para o gerenciamento das características (features) inerentes ao Ginga e ainstanciação de uma família de produtos Ginga que unifica as três abordagens citadas.1.1 ObjetivosO presente trabalho visa apresentar: (i) a solução inicial do processo de desenvolvimento que estásendo elaborado no projeto GingaForAll, que tem por objetivo central gerar o middleware Ginga naforma de uma Linha de Produto de Software (LPS), através da definição de uma abordagem baseadaem engenharia dirigida por modelos [7] e orientada a aspectos [8]. A idéia é definir uma arquiteturaflexível para o Ginga, através de uma reestruturação da sua arquitetura atual. A partir dessa novaarquitetura, será possível gerar customizações específicas do middleware Ginga contemplandodiferentes necessidades e demandas do mercado e de clientes específicos. (ii) a proposta inicial para oprocesso de avaliação da refatoração do GingaCC. Esse processo é baseado na comparaçãoentre a versão original do GingaCC orientada a objetos e sua orientada a aspectos propostanesse trabalho através do uso de métricas associadas a propriedades relevantes ao contexto desistemas de middleware. O intuito da avaliação é verificar quais foram os possíveisbenefícios e prejuízos resultantes da refatoração do sistema usando a abordagem dedesenvolvimento de software orientado a aspectos. Nesse entregável é apresentado o processode avaliação e os resultados parciais coletados na versão orientada a objetos do GingaCC. (iii)8

os principais meios de transmissão de conteúdos multimídia via IP como IPTV, InternetTV eP2PTV. O objetivo do projeto é identificar as principais variabilidades e similaridadesexistentes entre as formas de comunicação citadas.1.2 Organização do DocumentoEsta parte I do documento está organizada da seguinte maneira: inicialmente, na Seção 2 éapresentada uma análise da sinergia entre as técnicas LPS e DSOA; LPS e DDM; e, a seguir, dasinergia entre as três técnicas. Na Seção 3 é apresentada a abordagem dirigida por modelos utilizadapara geração da família de produtos do Ginga. A Seção 4 apresenta as ferramentas, tecnologias elinguagens utilizadas para a execução da abordagem dirigida por modelos apresentada na seção 3.2 Estado da Arte na Integração de LPS comoutras técnicas de Engenharia de Software2.1 Vantagens de IntegraçãoEsta seção busca apresentar as vantagens obtidas com a integração das abordagens de linha deprodutos de software [3] com as técnicas de desenvolvimento de software orientadas a modelos[7][27] e orientadas a aspectos [2].As LPSs têm se comprovado como uma técnica eficiente para aumentar a produtividade e aqualidade de softwares produzidos quando se pode aplicar essa técnica a um domínio específico.Apesar do sucesso obtido pela indústria, as etapas de Engenharia de Domínio e Engenharia deAplicação esbarram em algumas dificuldades de como tratar, implementar ou gerenciar as atividadespeculiares a cada etapa e que transpassam para as etapas posteriores. Exemplos disso são as técnicasatuais de tratar as etapas de especificação, projeto, implementação e gerenciamento de variabilidadesdas features desde o modelo de features até a implementação do produto.Na abordagem tradicional da engenharia de linhas de produto de software, as variabilidadessão principalmente manipuladas usando mecanismos providos pela (ou associados à) próprialinguagem de programação, tais como padrões de projetos, frameworks, polimorfismo, reflexão e précompilação.Além desses mecanismos, pode-se usar a configuração e o desenvolvimento de9

ferramentas para definição de variabilidades em tempo de compilação e selecioná-las a partir doconjunto de ativos base [6].Entretanto, essa abordagem tradicional de desenvolvimento de LPS encontra-se limitada, porexemplo, à expressividade da linguagem de programação ou a técnicas de configuração em tempo decompilação. Uma forma de facilitar a implementação de variabilidades pode ser obtida através do usoda abordagem de desenvolvimento dirigido a modelos. Utilizando essa solução, as atividades degerenciamento e rastreamento das features para o código são facilitadas, além de as característicaspoderem ser separadas em modelos, diminuindo a complexidade de se adicionarem novascaracterísticas ao ativo base.A principal vantagem de integração de LPS com DDM reside no fato de que os artefatosgerados ao longo das etapas de desenvolvimento da LPS podem ser representados como modelos,passíveis de transformação, o que sugere altos índices de automação entre as fases, característicadesejável em uma LPS. Modelos definem detalhes particulares do projeto e podem ser derivados apartir de outros modelos, aumentando o reuso. Neste contexto, o conceito de transformações demodelos é fundamental para a realização dos benefícios decorrentes da abordagem, tais como aumentode produtividade, portabilidade e interoperabilidade. Os modelos gerados em cada fase da LPS sãoutilizados como parâmetros para geração de modelos nas fases posteriores e finalmente geração doproduto final, ou seja, do código executável (que também pode ser considerado um modelo),preservando, conseqüentemente, a conformidade entre os artefatos das diferentes fases da LPS. Essascaracterísticas tornam o DDM uma abordagem útil para a criação de LPS.Diversos trabalhos [6][37][38] apontam que o uso de DDM em conjunto com a engenharia deLPS facilita a definição dos processos de criação e o gerenciamento de produtos em uma linha deproduto de software. Outras vantagens observadas [6] apontam que o uso de LPS com MDD facilita omapeamento do domínio do problema para o domínio de solução, podendo o mesmo ser formalmentedescrito automaticamente usando transformações modelo para modelos. Adicionalmente, a integraçãode tais abordagens permite descrever as variabilidades de forma mais concisa no nível de modelo.Além da abordagem de desenvolvimento dirigido por modelos, novas técnicas de modelageme programação estão sendo propostas com o objetivo de melhorar a modularização de features emLPSs. Um exemplo dessas novas técnicas consiste nos princípios e mecanismos de composição doparadigma de Desenvolvimento de Software Orientado a Aspectos (DSOA). Algumas vantagens já sãoobservadas a partir de trabalhos que relatam a experiência do uso de técnicas de DSOA nodesenvolvimento de LPSs [9][14][15][5][16], como se pode citar: (i) separação clara de featurestransversais e não transversais já desde estágios preliminares de desenvolvimento; (ii) mapeamentodireto de features transversais em aspectos; (iii) aumento da capacidade de reuso de artefatos de10

software (core assets) relacionados a features transversais; e (iv) facilidade para configuração ecustomização de produtos específicos da LPS.2.2 Abordagens de Integração entre LPS E DSOALinhas de Produtos de Software (LPS) possuem como principal objetivo a geração de produtosespecíficos com base na reutilização de uma infra-estrutura comum dentro de um domínio específicode aplicação, definindo os pontos comuns e variabilidades dentro do sistema. Os pontos comunsformam o núcleo base para desenvolvimento de um sistema, e as variabilidades são usadas paraderivação dos produtos finais. Essa seção apresenta uma análise crítica das abordagenstradicionalmente usadas em LPS visando levantar os seus problemas e/ou pontos de fragilidade (Seção2.2.1), a aplicação de DSOA no contexto de LPS (Seção 2.2.2) e os benefícios do uso de aspectos emLPS (Seção 2.2.3).2.2.1 Análise critica das abordagens tradicionalmente usadas em LPSAlgumas das abordagens tradicionais utilizadas para gerenciamento das variabilidades emlinhas de produtos de software, tais como agregação/delegação e herança, podem trazer problemascomo o aumento da complexidade do sistema a partir de inclusão de novas funcionalidades e tambéma dificuldade para expressar conceitos transversais. O aumento da complexidade do sistema devido àinclusão de novas funcionalidades dificulta a derivação de novos produtos e a evolução dos produtosjá existentes. A dificuldade para expressar conceitos transversais (crosscutting concerns), que nãofazem parte dos conceitos básicos do sistema, deixa o código entrelaçado (tangled) e espalhado(spread) em vários pontos do sistema.Outro aspecto problemático de algumas abordagens tradicionais, segundo Pacios [17], consisteno fato de que o esforço (e o custo) no início do desenvolvimento de uma linha de produto é alto,devido à necessidade de uma análise de domínio e da criação de um projeto muito extenso, o que podetrazer prejuízos se essa linha de produto não trouxer o retorno esperado do investimento.Desta forma, estudos [9][14] mostram abordagens de implementação utilizandoDesenvolvimento de Software Orientado a Aspectos (DSOA) em LPS para separar e compor conceitostransversais, em termos de features, permitindo conectar ou desconectar essas features do núcleo daarquitetura da LPS, simplificando a complexidade de desenvolvimento da mesma.A aplicação de aspectos em LPS serve para modularizar as features e acrescentar novasfeatures sem a necessidade de um projeto inicial extenso, permitindo que a linha de produtos seja11

desenvolvida de forma incremental e a partir de ciclos iterativos, para prover flexibilidade eadaptabilidade de seus produtos.Nas linguagens/plataformas existentes há vários mecanismos para modularização dos conceitostransversais para LPS, como definição de aspectos, pontos de junção e métodos abstratos usandoAspectJ [12] ou AspectC++ [18], e definição de pontos de corte diretamente em arquivos deconfiguração do Spring [19].2.2.2 Aplicando DSOA no contexto de LPSSegundo Conejero [15], em um modelo de LPS em que as características comuns e asvariabilidades são analisadas em termos de features, a adição de aspectos, nas features transversais dosistema, provê considerável redução das dependências entre elas, principalmente se os aspectos foremaplicados sobre as variabilidades do produto. Porém, aspectos também podem ser aplicados sobre asfeatures comuns do sistema.A seguir será apresentada uma forma de identificar as features transversais de uma LPS a partirde uma matriz de dependência, e também serão mostradas duas abordagens que usam DSOA emlinhas de produtos: a abordagem de Mezini [5] e a abordagem de Braga [16].2.2.2.1 Identificação de Conceitos Transversais em LPSConejero [15] explica que usar técnicas de orientação a aspectos provê modularização dascaracterísticas transversais da LPS, mas que antes é necessária a identificação das featurestransversais. Dessa forma sua abordagem propõe uma forma de identificar essas features transversais.Segundo Conejero [15] as features transversais podem ser identificadas a partir da construçãode uma matriz de dependência que mostra o relacionamento entre os casos de uso e as features dosistema, e a partir de simples operações matriciais sobre essa matriz de dependência, pode-se obteruma matriz de transversalidade que mostrará as features candidatas a serem implementadas poraspectos.Em sua abordagem Conejero mostra como fazer uma análise em LPS para identificar asfeatures transversais. Sua análise está dividida em cinco fases descritas a seguir: (i) análise orientada afeatures, (ii) elicitação dos requisitos não funcionais, (iii) modelagem dos requisitos, (iv) construçãode uma matriz de dependência, e (v) construção de uma matriz de transversalidade.1. Análise orientada a features: Nessa fase é feita uma análise de domínio orientada afeatures, para permitir um melhor entendimento dos requisitos do software. Podem-seutilizar várias abordagens para esta análise, sendo uma delas a FODA (Feature-Oriented12

Domain Analysis) [20]. Para a abordagem proposta é necessária a criação de um modelode features para expressar as features comuns e variabilidades do sistema.2. Elicitação dos requisitos não-funcionais: Esta fase visa identificar os requisitos nãofuncionais envolvidos na LPS. Os requisitos não funcionais são aqueles que expressamcomo deve se comportar o sistema e, em geral, estão relacionados com padrões dequalidade como confiabilidade, desempenho, robustez, etc.3. Modelagem dos requisitos: Nesta fase, é feita a engenharia de requisitos para montar aprimeira representação do sistema usando os requisitos do sistema. Pode-se usar odiagrama de casos de uso da UML [21] para representar esses requisitos.4. Construção de uma matriz de dependência: Uma vez identificadas as features doproduto (incluindo os requisitos não funcionais) e modelados os requisitos, pode-se usaressas informações para construir uma matriz de dependência. A matriz de dependênciarepresenta a relação dos casos de uso (colunas) que influenciam nas features representadasno modelo de features (linhas). A Figura 1 mostra a matriz de dependência criada porConejero a partir de uma linha de produtos para criação de jogos Arcade. Observa-se namatriz, por exemplo, que a feature Play tem dependência com os casos de uso PlayBrickles, Play Bowling e Play Pong.13

7Figura 1: Matriz de dependência de uma linha de produtos para criação de jogos Arcade5. Construção de uma matriz de transversalidade: A partir da criação da matriz dedependência entre as features e os casos de uso, duas matrizes denominadas matriz deespalhamento e matriz de entrelaçamento são criadas como mostrado a seguir:A matriz de espalhamento é formada pela relação de dependência dos features erequisitos não funcionais com os casos de uso. Se uma feature é espalhada ela estámapeada em vários elementos. Na Figura 1 exemplos de features espalhadas são play,save, Rules_Brickles e Rules Bowling, já exemplos de features não espalhadas sãopause, exit e install.A matriz de entrelaçamento é formada pela relação de dependência dos casos de usocom as features e os requisitos não funcionais. Se um caso de uso é entrelaçado, ele érepresentado por várias features e/ou requisitos não funcionais. Na Figura 1, exemplos14

de casos de uso entrelaçados são save game e exit game, já exemplo de caso de usonão entrelaçado é o Check previous Best score.Após a criação das matrizes de entrelaçamento e espalhamento, é construída a matriz detransversalidade a partir da multiplicação entre essas matrizes, ou seja, mTrans [i][k] = mEsp [i][j] *mEntr [j][k], onde mTrans é a matriz de transversalidade, mEsp é a matriz de espalhamento e mEntr éa matriz de entrelaçamento. A Figura 2 representa uma matriz de transversalidade com as featurescandidatas a serem representadas por aspectos. Essa matriz foi criada a partir da matriz de dependênciamostrada na Figura 1.Figura 2: Matriz que representa as características transversais de um sistema de criação dejogosNa Figura 2, as células representadas pelo numero 1 indicam que a feature ou requisito nãofuncionaldessa linha é transversal à feature ou requisito não-funcional da coluna referente.15

2.2.2.2 Abordagem de Mezini et al 2004Mezini [5] apresenta uma análise sobre as abordagens orientadas a features e sobre as soluçõesorientadas a aspectos, utilizando AspectJ, com relação ao gerenciamento das variabilidades de umafamília de produtos, e propõe a utilização da linguagem Caesar [22], como uma solução intermediáriaentre essas duas.O referido trabalho de Mezini mostra os problemas das duas soluções supracitadas quandoaplicadas de forma isolada em LPS. Em abordagens orientadas a features ocorrem problemas deescalabilidade quando características transversais estão presentes, devido ao esforço requerido paracodificar uma característica transversal crescer linearmente de acordo com o tamanho do programa, ouseja, quanto mais um programa cresce maior o esforço para codificar uma característica transversal. Jáa utilização de abordagens orientadas a aspectos, como AspectJ, que permitem expressar ascaracterísticas transversais do sistema com a utilização de pontos de corte e advices, não consegue, emgeral, prover um suporte a variabilidade, ou seja não é possível ter diferentes variantes da aplicaçãoem um único sistema.Mezini não mostra como identificar as características transversais de um sistema, masapresenta uma forma para alcançar benefícios tanto das abordagens orientadas a features, como aseparação das características do sistema para prover variação do produto, quanto de abordagensorientadas a aspectos, para expressar características transversais do sistema, com a utilização dalinguagem Caesar.Em Caesar o conceito de classe é generalizado para servir como camada capaz de encapsular adefinição de múltiplos tipos interdependentes (classes aninhadas), contribuindo para utilização defeatures. Além disso, são utilizados pontos de corte e advices para definir a interação entre as featurese o sistema base. A Figura 3 mostra um exemplo de código na linguagem Caesar.16

Figura 3: Exemplo de código da linguagem CaesarNa Figura 3 pode-se observar a utilização do conceito de generalização de classes, em duasclasses aninhadas ClientCustomer e StockInfoRequestProduct e a utilização de pontos de corte eadvices. As construções de pontos de corte são semelhantes a sua construção na linguagem AspectJ, jáos advices utilizam associações por objetos no caso ClientCustomer(c), permitindo que o aspecto fiqueassociado ao objeto durante toda a sua vida, e seja usado sempre que algum dos pontos de junção doobjeto for interceptado.O Caesar utiliza o conceito de deployment como um mecanismo que permite definir em quecontextos as definições dos advices serão ativadas e com relação a qual instância de classe. Autilização de deployment permite compor as features para a derivação do produto final de forma aprover uma configurabilidade dinâmica, ou seja, pode-se escolher a variante de um produto, em tempode carga, e utilizá-la de uma forma distinta, em tempo de execução.2.2.2.3 Abordagem de Braga et al 2007Braga [16] propõe o Aspect-Based Incremental Product Line Engineering for InformationSystems (AIPLE-IS) para desenvolvimento de LSP com aspectos. Essa estratégia permite odesenvolvimento incremental de LPS usando aspectos e é composta por um conjunto de fases e17

atividades. A Figura 4 mostra uma visão geral do AIPLE-IS, mostrando suas fases (desenvolvimentodo núcleo e criação do produto) e as atividades das fases.Figura 4: Visão geral do AIPLE-ISO AIPLE-IS é constituído de duas fases: desenvolvimento do núcleo e criação do produto.Tais fases são descritas a seguir.Desenvolvimento do núcleo: Essa fase tem como objetivos identificar e implementar os ativos donúcleo (core assets) da LPS. Ela é constituída de duas atividades:• A análise de domínio, que visa capturar conhecimentos do domínio, podendo ser utilizadaqualquer metodologia de análise de domínio, como FODA (Feature Oriented DomainAnalysis) [20].• O desenvolvimento das features do núcleo, que visa implementar todas as features comuns, apartir de atividades como a de definição a arquitetura núcleo do sistema, modelagem dosistema, implementação e teste.Criação do produto: Esta fase tem como objetivo a criação de produtos concretos e está constituídaem duas atividades: Desenvolvimento das features e composição das features.O Desenvolvimento das features é a atividade responsável por adicionar, de formaincremental, novas features para a linha de produtos, usando técnicas de orientação aaspectos quando necessário, até que todas as variabilidades identificadas na análise dedomínio sejam desenvolvidas. Esta atividade pode ser prorrogada, conforme necessário,para adicionar novas features identificadas após análise do domínio, como parte da18

evolução da linha de produtos. Para implementação de uma nova feature, de forma geral,Braga propõe a utilização de um guia proposto por Pacios [17] contendo cinco passoscomo mostrado a seguir:1. Novas Classes: Se uma feature implica a criação de uma ou mais classes, essasdevem ser implementadas usando classes convencionais, ou seja, sem aspectos.2. Novos atributos e/ou métodos: Se uma feature implica a criação de novosatributos e/ou métodos em classes existentes, esses podem ser escritos a partir dedeclarações de inter-tipos. As declarações inter-tipos especificam novos atributosou métodos nas classes que um aspecto entrecorta, ou modificam orelacionamento entre classes e entre classes e interfaces. Ao contrário de advices,que operam de forma dinâmica, as declarações inter-tipos operam estaticamente,em tempo de compilação.3. Mudança de comportamento dos métodos existentes: Se a existência dafeature implica a mudança do comportamento de métodos existentes, isto tem queser feito com aspectos através dos advices.4. Novas associações: Se a feature implicar a criação de novas associações entreclasses existentes, ou entre uma nova classe e uma já existente, elas devem serimplementadas com aspectos, para garantir a conectividade com a feature epermitir sua remoção se necessário. Uma associação N para 1 geralmente éimplementada através da inclusão de um atributo em uma classe (lado N) pararepresentar a referência da outra classe (lado 1). Neste caso, a orientação 2 éaplicável.5. Remoção de associações existentes: Se a presença de uma feature requer aremoção de uma ou mais associações entre classes existentes, para permitir a suaremoção as associações devem ter sido incluídas utilizando aspectos, fazendo comque, ao omitir o aspecto que a incluiu, seja direta e facilmente feita a remoção darespectiva associação.A composição das features é a atividade que visa a montagem dos produtos, nessaatividade, o engenheiro de software deve escolher as features de um determinado produtoa partir das features representadas no modelo de features, para formar uma derivação doproduto final.19

Braga explica que a utilização de técnicas do DSOA facilita a implementação de features emLPS, devido à modularização provida pelo DSOA, tornando as features mais coesas, de fácilcombinação e reusáveis.2.2.3 Benefícios do uso de Aspectos em LPSO uso de aspectos, em geral, possibilita expressar conceitos transversais de um sistema para proverreusabilidade e manutenibilidade. Além desses benefícios gerais do uso de DSOA, em nossolevantamento foram identificados vários dos seus benefícios quando aplicado em linhas de produtos.Dentre eles estão:Diminuição da complexidade para gerenciamento das variabilidades em linha de produtos.Flexibilidade e adaptabilidade dos produtos finais da linha de produtos.Facilidade de implementação de features em LPS, devido à modularização provida peloDSOA, tornando as features mais coesas, de fácil combinação e reusáveis.Em suma, a utilização de DSOA em LPS provê suporte para modularização das features, o quemelhora o processo de derivação do produto final, pois facilita a ativação e desativação de umadeterminada feature, permite que a linha de produtos seja desenvolvida de forma incremental e a partirde ciclos iterativos, além de, segundo Heo e Choi [23], aumentar a adaptabilidade dos componentes dalinha de produtos.Para o middleware Ginga será utilizada uma abordagem de LPS com DSOA, visando construiruma arquitetura adaptável, manutenível e reutilizável. Essa abordagem utilizará o modelo de featurespara tornar as características comuns e as variabilidade do Ginga melhor gerenciáveis e aplicará oconceito de aspectos para melhor modularizar algumas de suas features variáveis, sobretudo aquelastransversais ao núcleo da plataforma.2.3 Abordagens de Integração Entre LPS E DDMEsta Seção apresenta propostas de trabalhos que realizam a integração de desenvolvimento delinhas de produtos de software utilizando a abordagem de desenvolvimento dirigido a modelos,principalmente na maneira de expressar as variabilidades presentes na linha de produto em nível demodelo.2.3.1 Gerência de Variabilidades20

O gerenciamento de variabilidades consiste em uma das atividades presentes na Engenhariade Linhas de Produtos de Software [3]. O gerenciamento de variabilidade em uma linha de produto desoftware está relacionado diretamente com as necessidades de gerenciamento das características doativo base, tanto para expressar as características comuns e variáveis de uma LPS, como para construiraplicações que incluem características comuns, e um subconjunto de características variáveis, as quaisdiferenciam os produtos entre si. Atualmente, os modelos de features constituem um padrão utilizadocomo mecanismo de suporte a variabilidades [5]. Os dois trabalhos apresentados a seguir, propõemduas soluções diferentes de gerência de variabilidades baseadas em MDD.2.3.1.1 Mapeamento de Features para Modelos baseado em TemplatesO trabalho descrito em [37] consiste em uma abordagem para o mapeamento de features paramodelos baseado em templates e implementado por um plugin no Eclipse [16]. Tal abordagemapresenta uma forma de representar, através de modelos, uma sobreposição de todas as variantes cujoselementos estão relacionados com as características (features) correspondentes por meio de anotações(annotations). Os autores justificam que a proposta é útil em nível de requisitos, pois possibilitavislumbrar diretamente o impacto de selecionar uma determinada característica no modelo resultante.A idéia apresentada pelos autores consiste em representar uma família de modelos através deum modelo de features e um template de modelo. O modelo de features define a hierarquia dascaracterísticas da linha de produto juntamente com suas relações de dependência e restrições deconfiguração. O template de modelo contém a união dos elementos do modelo de features em todas asinstâncias de templates válidos. Um conjunto de instâncias de templates válido corresponde à extensãode uma família de modelos. Os elementos de um template de modelo podem ser anotados usandocondições de presença (presence conditions - PCs) e meta-expressões (meta-expressions - MEs). Essasanotações são definidas em termos de features ou atributos de features de um modelo de features, epodem ser avaliadas com respeito à configuração de features. Uma anotação do tipo condição depresença (PC) anexada ao modelo de elementos indica se o elemento estaria presente ou seriaremovido de uma instância de template. As meta-expressões (MEs) são usadas para computar atributosde um modelo de elemento, tais como o nome de um elemento ou o tipo do retorno de uma operação.Uma instância de um modelo da família pode ser especificada pela criação de umaconfiguração de características (features) baseada no modelo de features. Com base na configuraçãodas características, o template de modelo é instanciado automaticamente. O processo de instanciação éuma transformação modelo para modelo, com a entrada e a saída expressas na notação alvo. Issoenvolve avaliar os PCs e MEs no que diz respeito à configuração das características, removendoelementos de modelo cujas avaliações de PCs sejam falsas e, possivelmente, realizando processamento21

adicional, como a simplificação. A simplificação consiste em remover os elementos que se tornaramredundantes após a remoção de outros elementos.Uma forma particularmente útil das PCs são fórmulas booleanas sobre o conjunto de variáveis,onde cada variável corresponde a uma característica do modelo de features. Dada uma configuração defeatures, o valor de uma variável booleana é verdadeiro se, e somente se, a característicacorrespondente estiver incluída na configuração da característica. As condições de presença marcadascomo falsas não são incluídas no template. Entretanto, as condições de presença são interpretadaslocalmente, ou seja, as PCs controlam a presença do elemento apenas no seu container (no seu espaçohierárquico). Uma vez retirado do container, todos os elementos associados à PCs também sãoremovidos. MEs podem ser usados para computar atributos de tipos básicos, bem como as referênciaspara elementos de modelos.Os autores apresentam o conceito de condições de presença implícitas (IPC - ImplicitPrecence Conditions), estendendo a classificação de PCs. Trata-se de quando um elemento não foiexplicitamente atribuído por um PC, mas que pode ser inferido implicitamente. Em outras palavras,um IPC pode ser deduzido com base nas condições de presença (PCs) de outros elementos e na sintaxee semântica das notações alvo. Por exemplo, de acordo com a sintaxe UML, uma associação bináriarequer duas classes, uma em cada extremidade. Caso um PC seja falso em uma das extremidades, épossível considerar a associação inexistente, uma vez que a associação só pode existir com duasclasses.[37] apresentam os seguintes passos a serem seguidos para utilizar asolução proposta em uma notação alvo: (i) decidir as formas de PCs e MEs, por exemplo, fórmulasbool[42]; (ii) decidir os PCs implícitos (elementos do modelo que nãosão explicitamente anotados pelo usuário terão PCs implícitos); (iii) decidir os mecanismos deanotações e opções de tradução para as anotações, ou seja, se a notação alvo é a UML, as anotaçõespodem ser realizadas com estereótipos; opções de tradução incluem labels, ícones e/ou cores; (iv)decidir sobre processamento adicional.O artigo menciona que um processo de instanciação de template envolve computar MEs eremover elementos cujos PCs forem valores falsos. Entretanto, o processo geral pode ser especializadopara uma determinada notação com alguns passos adicionais de transformação, os quais permitemexpressar templates em notações mais compactas. Os autores identificam duas categorias paratransformações: aplicações de patch (patch application) e simplificações (simplification). Uma patch éuma transformação que automaticamente corrige um problema que pode resultar de um elementoremovido. Essa categoria é aconselhada para as situações em que existe uma solução única e intuitiva22

para um problema criado pelo elemento removido. A simplificação implica remover elementos que setornaram redundantes após a remoção de outros elementos.O algoritmo completo de instanciação de template pode ser resumido do seguinte modo: (i)Avaliação do MEs e PCs explícitos: a avaliação é feita enquanto percorrem-se hierarquicamente oselementos de contenção do template em ordem de depth-first (profundidade); elementos filhos cujosvalores de PCs são falsos não são vistos porque eles serão removidos; (ii) Análise de remoção: aanálise de remoção envolve computar PCs implícitos e informações necessárias para aplicação depatch, se houver; (iii) Remoção de elemento e aplicação de patch: nesta etapa, os elementos cujos PCssão falsos são removidos e se for o caso, patches são aplicados; a aplicação de um patch depende doseu tipo e pode ser realizada antes ou após a remoção; (iv) Simplificação: A simplificação consiste emremover os elementos que se tornaram redundantes após a remoção de outros elementos e esta etapa ésempre realizada.Os autores construíram um protótipo para ilustrar na prática o trabalho proposto. O protótipo,fmp2rsm, é um plug-in do Eclipse que integra o Feature Modeling Plug-In (FMP – proposta dosmesmos autores) [43], com Rational Software Modeler (RSM), uma ferramenta de modelagem UMLda IBM. O plug-in trabalha com quatro artefatos: (i) modelo de template UML criado usando RSM,(ii) modelo de features criado utilizando FMP e dois perfis de variabilidade, (iii) profile paraanotações PC e (iv) profile ME para anotações ME.O profile PC oferece duas formas de anotações de PC: fórmulas booleanas na forma normaldisjuntiva (DNF - Disjunctive Normal Form) e expressões XPath genéricas. Cada disjunção (isto é,uma conjunção de literais) de um PC em DNF é representada como um estereótipo, por exemplo, pela fórmula booleana f1f2f3, e pode ser criada sobre uma seleção de múltiplasfeatures automaticamente através de um menu de operações em um FMP. Uma vez criado, oestereótipo, torna-se disponível ao RSM para anotações de elementos de template. As anotações maiscomuns utilizando XPath são criadas através da aplicação do estereótipo , que permite aousuário digitar a expressão XPath desejada como o valor de sua expressão: String property.O perfil ME contém vários estereótipos estruturados de forma similar ao , entretantocada um é aplicável aos elementos de um tipo específico. Por exemplo, pode seraplicado a qualquer elemento do tipo NamedElement, a fim de computar seu nome. Do mesmo modo, pode ser usado para definir o tipo da propriedade de qualquer TypedElement. Para, uma expressão precisa retornar um nome qualificado de um tipo primitivo (porexemplo, UML2:: String), uma classe, uma interface, ou uma enumeração. O perfil ME poderia serautomaticamente gerada com base no metamodelo de uma determinada notação.23

O objetivo da solução apresentada em [37] pode ser visto sob diferentes perspectivas: (i)fornecer semântica para features em modelos de features através de seu mapeamento para outrosmodelos, e (ii) utilizar modelos de features para fornecer uma representação concisa das variabilidadescontidas em outros modelos. Expressar PCs e MEs em termos de features proporciona rastreabilidadeentre as features e sua realização em modelos. Embora os autores argumentem que a abordagem éespecialmente útil em nível de requisitos, ela pode ser aplicada aos modelos de qualquer nível, porexemplo, modelos de arquitetura e implementação.Os autores argumentam que a partir da perspectiva de usabilidade, a abordagem proposta éválida, pois os templates de modelos evitam a necessidade de se aprender novas linguagensespecializadas (exceto para modelos de features simples). Condições de presença implícitas (IPCs),aplicações de patch e simplificações minimizam os esforços de anotações e diminuem a complexidadevisual, tornando os templates de modelos mais concisos. Adicionalmente, templates de modelospodem ser criados incremental e simultaneamente com o modelo de features.2.3.1.2 Gerência de Variabilidades Baseada em GME e GMF[5] apresenta uma comparação entre duas propostas de implementaçõesbaseadas em MDA para o gerenciamento de variabilidade em uma linha de produtos de software. Asimplementações foram realizadas com dois frameworks distintos no intuito de compará-los. Ambos osframeworks possuem base nos princípios da Model Driven Engineering (MDE). Esses frameworks sãoo Graphical Modeling Framework (GMF) e o Generic Model Environment (GME). Os autoresconstruíram os ativos base (core asset) da linha de produtos e geraram aplicações que utilizam os doisframeworks. Os ativos base que os autores desenvolveram consistem nos modelos de features,metamodelos, modelos de mapeamento e regras de transformação. Essas regras de transformaçãoforam construídas[21] no contexto GME.O esquema proposto permite transformar um modelo fonte inicial em modelos alvos diferentespara a obtenção de diferentes produtos da LPS. Contudo, os ativos base especificados não sãosuficientes para gerar aplicações completas. Uma vez que alguns requisitos funcionais não são geradosdurante os processos de transformação automática, os autores complementaram manualmente asaplicações no processo de engenharia da aplicação.O GMF fornece um componente generativo para o desenvolvimento de editores gráficosutilizando o Eclipse Modeling Framework (EMF) e o Graphical Editing Framework (GEF). EMFconsiste em um framework de modelagem para a construção de ferramentas e outras aplicaçõesbaseadas em modelos de dados. O EMF fornece ferramentas para produzir um conjunto de classes24

Java para o modelo, permitindo assim visualizá-lo e editá-lo. Por sua vez, o GEF permite aosdesenvolvedores criar editores gráficos de um modelo de aplicação já existente. Assim, com EMF(usando o metamodelo do Ecore) e o GEF, o GMF propõe e provê suporte a um processo para aconstrução de funcionalidades baseadas no Eclipse. Atualmente, ATL é uma solução padrão doEclipse para definir transformações e é um dos principais componentes do projeto Eclipse Model-to-Model [35].Os autores apresentam um resumo da abordagem de gerenciamento das variabilidades naconstrução de processos MD-LPSs (linhas de produto de software dirigidas a modelo) e descrevem aforma como a abordagem foi implementada utilizando GMF / ATL e GME /ECL no estudo de caso.Os autores separam os conceitos relacionados a uma LPS em domínios para gerenciar asvariabilidades. Esses domínios são a lógica de negócios (abstração de alto nível), o domínioarquitetural, bem como o domínio da plataforma tecnológica (abstração de baixo nível). A estratégiados autores segue a abordagem MDA [7][40] e baseia-se na transformação automática (refinamento)dos modelos até a obtenção de aplicações executáveis. Eles iniciam a partir de um modelo lógico denegócio, transformando-o em um modelo arquitetural, depois refinando-o em um modelo de domíniode plataforma tecnológica e finalmente gera-se o código fonte a partir dele. Para atingir esse objetivo,os autores construíram como ativos bases: (i) metamodelos para cada domínio, (ii) modelos defeatures para cada domínio alvo, (iii) modelos de mapeamento e (iv) três tipos de regras detransformação.Para a definição do metamodelo, o GMF é baseado no EMF, o qual é uma implementaçãoJava de um subconjunto do núcleo do MOF, chamado de Ecore [38]. Usando GMF, os autores criaramos modelos EMF utilizando o editor de diagramas do Eclipse Ecore, o qual permite criar modelossemelhantes aos diagramas de classe UML. A organização estrutural de Ecore inclui meta-conceitos,como por exemplo, EPackage, EClass, EAttribute, EReference, EOperation, EDataType, EEnum eEEnumLiteral entre outros. O metamodelo Ecore admite herança múltipla, portanto uma meta-classepode ter diferentes super meta-classes; e o conceito da EReference é utilizado para definir as relaçõesde associação ou agregação entre as classes.Usando esses conceitos, os autores construíram um metamodelo para cada domínio. Elescriaram os editores de plug-ins para editar os modelos conforme o metamodelo EMF, usando oframework GMF para a construção das funcionalidades baseadas no Eclipse. Esse framework separa adefinição do modelo de domínio, o modelo gráfico associado (sintaxe concreta) e as ferramentas paramanipular os conceitos do domínio com as sintaxes concretamente associadas. Como o modelo dodomínio não está associado à nenhuma sintaxe concreta, diferentes sintaxes concretas podem serassociadas.25

Os autores criaram modelos de features baseados nas características das aplicações naarquitetura e no domínio de plataforma tecnológica. Para definir os modelos de features do estudo decaso apresentado no artigo, foram utilizados os conceitos de nós de features, grupos de features ecardinalidade. Os usuários definem seus requisitos (features) por meio dos modelos de features. Elesprecisam selecionar as features antes da inicialização dos processos de transformação. A seleção éfeita por associação dos elementos de modelo (origem) e nós de features (alvo). Regras detransformação são definidas em termos de conceitos de metamodelos. Isso implica que um mesmomodelo fonte é sempre transformado no mesmo modelo alvo. Uma vez que precisa-se transformar omesmo conceito de metamodelo em diferentes conceitos alvo, de acordo com as features relacionadas,precisa-se criar regras diferentes.Os autores propõem a criação de três diferentes tipos de regras de transformação: (i) regrasbases, (ii) regras de controle e (iii) regras específicas, criadas com o objetivo de orientar a geração demodelos alvos diferentes. As regras bases consistem nas regras de transformações convencionais. Já asregras de controle usam o modelo de configuração para definir quais transformações invocar. Porúltimo, as regras específicas tratam casos específicos de configurações. Assim, as regras basespermitem a geração de características comuns (obrigatórias) na linha de produto de software e asregras de controle e específicas, as características variáveis. O modelo de mapeamento é usado, nasregras de controle, para decidir qual regra de transformação deve ser executada de acordo com acaracterística ligada ao elemento que está sendo transformado.A fim de orientar a criação e posterior execução destas regras de transformação, os autorescriaram novos modelos compostos contendo as relações entre conceitos de metamodelo e nós defeatures, e novos modelos compostos contendo relacionamentos entre elementos de modelo e nós defeatures. Os autores denominaram o primeiro de modelo de meta-mapeamento e o segundo de modelode mapeamento. O modelo de meta-mapeamento conecta conceitos de metamodelo a nós de featuresgerando um novo modelo composto. Cada conexão indica que um conceito de metamodelo fonte podeser transformado para obter o nó da feature alvo. Assim, esses modelos de meta-mapeamento sãoativos base usados como elementos de projeto para a construção de diferentes regras de transformação.Usando o modelo de meta-mapeamento, pode-se identificar: (i) o conceito de metamodelo que precisaser sempre transformado na mesma feature alvo e (ii) o conceito do metamodelo que pode sertransformado em diferentes features alvo. No primeiro caso, criam-se as regras base e para o segundo,criam-se as regras de controle e regras específicas. Assim, as regras base permitem a geração dascaracterísticas comuns da linha de produtos, bem como o controle e regras de especificação dasvariabilidades.26

Ligam-se os elementos de modelo com nós das features para a criação de novos modelos demapeamento composto no processo de engenharia da aplicação. Esses modelos são criados quando ousuário seleciona elementos do modelo, e os relaciona a seleção de features para orientar o processode geração de produto. Uma vez que esses modelos de mapeamento são entradas para os processos detransformação, é obrigatória a utilização de um metamodelo de mapeamento como ativo base noprocesso de engenharia de domínio. Os autores usam o metamodelo ATLAS Model Weaver (AMW)para a implementação GMF, e criam um metamodelo de mapeamento para a implementação GME.Para esta atividade, os autores concentram-se nas facilidades de composição de (meta) modeloprovidas pelos dois frameworks necessários para criar mapeamento de modelos, e as facilidades daslinguagens de transformação para a criação de três tipos de regras de transformação.Para a implementação GMF, foram criados (meta) modelos de mapeamento usando ometamodelo AMW e seus plug-ins. O AMW está integrado no Eclipse para o estabelecimento derelações (ou seja, ligações ou links) entre os modelos. As ligações criadas são armazenadas em umnovo modelo, denominado de modelo de weaving que está em conformidade com o metamodelo deweaving. Foram criadas regras de transformação utilizando as facilidades de implementaçãodeclarativa e imperativa oferecidas pela ATL. As regras base foram implementadas utilizando aprogramação declarativa e as regras específicas usando programação imperativa. As regras de controlesão implementadas de forma mista, em outras palavras, elas possuem uma parte declarativa e umaparte imperativa. Os módulos ATLs foram criados tendo como entrada o modelo fonte, o qual serátransformado, e um modelo de mapeamento. O modelo de mapeamento é usado, nas regras decontrole, para decidir qual regra de transformação deve ser executada de acordo com a feature ligadaao elemento que está sendo transformado.A criação de modelo de meta-mapeamento e de modelos de mapeamento são atividades decomposição de modelo. Tal composição de modelo é aplicada em três contextos: (i) na composição dametamodelos, (ii) na composição de metamodelos com modelos e (iii) na composição de modelos. Osdois primeiros são realizados no processo de engenharia de domínio. O primeiro tem lugar naatividade de definição do metamodelo e o segundo, na criação dos modelos de meta-mapeamento. Oterceiro tem lugar na criação dos modelos de mapeamento no processo de engenharia de aplicação.O processo de composição, citado no parágrafo anterior, não é suportado pelo metamodeloEcore no contexto da GMF. Todavia, é possível realizar tais composições utilizando o AMW. Além depermitir a composição de modelos e metamodelos, os autores descobriram que AMW conta comferramentas gráficas para realizar tal tarefa, permitindo relacionar os conceitos entre modelos, o queajuda a manter a coesão de cada um.27

As regras de transformação foram escritas com Embedded Constraint Language (ECL) [21],uma linguagem intuitiva para definir regras de transformação. ECL suporta o conceito deentrelaçamento de modelos de aspecto. Nota-se que a composição de modelos usando ECL implicaque os modelos fonte e modelos alvo estejam em conformidade com o mesmo metamodelo. Os autoresafirmam que, mesmo que a linguagem ECL possua um número suficiente de operadores paratransformar/compor modelos, ela não suporta definição de estratégias declarativas, implicando,portanto, que existe sempre a necessidade de definir a lógica para navegar nos modelos. Assim,estratégias para transformar modelos com ECL implicam escrever programas que naveguemmanualmente através dos modelos que serão transformados ou compostos. Outra questão consiste nofato de que ECL possui alguns problemas de manipulação de tipos booleanos e estruturas de controle.Os tipos booleanos não possuem representação simbólica para elementos booleanos definidos nosmodelos GME, e elementos booleanos não podem ser definidos em programas ECL. Além disso, asestruturas de controle não admitem uso de condições de else-if, tornando a avaliação das condiçõesagrupadas menos eficientes.[23] facilita a criação de regras imperativas e declarativas.Além disso, usando ATL também é possível criar regras que desencadeiam a execução de regrasespecíficas. Este é o caso das regras de controle. Essas podem ser utilizadas, como no ECL, paraconstruir modelos compostos; além de, usando modelos fonte ATL e modelos alvos compostos,podem estar em conformidade com diferentes metamodelos. Por fim, diferentemente da ECL, existemvários grupos de discussão ATL, exemplos e recursos disponíveis que apóiam o trabalho com ATL.Nas transformações para texto na implementação GMF, o plugin Acceleo [1] foi utilizadopelos autores. O Acceleo é especializado na geração de arquivos texto (código, XML, documentação)a partir de modelos. Usando o Acceleo, os autores utilizam os modelos EMF e os templates para ageração de código fonte. Para a implementação GME, os autores precisaram criar o próprio geradorJava para navegação no modelo GME (XML) e geração de código Java. Componentes GME podemser construídos utilizando o módulo Unified Data Model (UDM). No entanto, as ferramentas paraacessar dados GME fornecem apoio restrito às linguagens para manipular modelos que não permitema utilização de mecanismo de controle, como loops e declarações condicionais, bem como ogerenciamento de rastreabilidade entre os modelos e os textos gerados.Diferentemente das ferramentas de suporte a GME, existem várias versões de ferramentas quesuportam o processo de construção de transformação modelo para texto no contexto da GMF. Estasferramentas permitem a geração de implementação ou documentação de modelos, geração de texto demodelos baseado no MOF, mecanismos de controle, como loops e declarações condicionais, e28

gerenciamento de rastreabilidade entre os modelos e geração de texto. Uma questão importanteconsiste no suporte a essas ferramentas.A proposta apresentada no artigo em questão permite gerenciar as variabilidades no nível demodelo para construção de linhas de produtos de software dirigidas a modelos. Isto significa que foiampliado o escopo de LPS, tornando possível gerar diferentes membros de LPS, a partir do mesmomodelo da lógica de negócio inicial (independente de plataforma), guiada por uma seleção específicade features. A implementação desta abordagem usa dois dos frameworks representativos atualmente,permitindo conhecê-los e perceber qual deles é mais adequado para experimentações específicas nocampo da MDD e LPSs.Atualmente, os autores continuam a trabalhar na abordagem focando-se (i) no gerenciamentode restrições para delimitar o escopo da LPS, (ii) na inclusão de informações de requisitos funcionaisnos metamodelos e (iii) no gerenciamento de rastreabilidade, indispensáveis para a manutenção doativo base e aplicações geradas. Devido aos rumos dados na pesquisa, os autores optaram porexperimentações futuras com GMF. Eles concluíram que o GMF permite criar metamodelos coesos,compor e manipular esses modelos usando o AMW, otimizar as transformações usando umalinguagem declarativa, criar regras de transformação para transformar os mesmos modelos etransformar modelos para o código fonte suportado por ferramentas com as características necessárias.2.3.2 Derivação de ProdutosO objetivo de uma linha de produto de software consiste em criar um conjunto de ativos desoftware reutilizáveis que possibilitem a produção de uma família de sistema de software destinada aum domínio de aplicação específico. Assim, a engenharia de LPS preocupa-se em construir, o maisautomaticamente possível, produtos de software específicos após a seleção de um conjunto particularde características que devem ser incluídas. Diferentemente da engenharia tradicional de sistemas, aengenharia de LPS exige, muitas vezes lidar com três diferentes linguagens em cada estágio do ciclode vida do software: (i) uma linguagem para especificar as variabilidades de uma LPS (isto é, ummodelo de features); (ii) uma linguagem para o design de ativos base de software reutilizáveis (ex:UML 2.0); e (iii) uma linguagem que especifica como os ativos reutilizáveis devem ser compostospara construção de produtos específicos. Existem disponíveis atualmente linguagens suficientes paraespecificação de variabilidades e design de ativos de software, mas há uma carência em especificar eautomatizar a composição desses ativos. As próximas seções apresentam duas propostas de soluçãobaseada em DDM para essa questão.2.3.2.1 Linguagens Específicas para Derivação de Produtos29

Em [38] é apresentado um processo inovador para ser aplicado na derivação de produtos emuma linha de produtos de software, o qual permite a elaboração de linguagens chamadas VML4*específicas para LPSs. Essas linguagens permitem especificar o processo de derivação de produtos emLPS usando uma sintaxe e um conjunto de abstrações familiares ao engenheiro da linha de produto desoftware. Esse processo produz um editor e ―um compilador‖ os quais automatizam a composição dosativos reutilizáveis para uma determinada linguagem.Ainda que exista uma ampla gama de linguagens para especificação de variabilidades e designde variabilidade, há uma carência geral para especificar o processo de derivação do produto. Algumasferramentas, tais como pure::variantes [44] e Gear [45] existem em nível de implementação, paraespecificar a composição de artefatos nesse nível. Contudo, tais ferramentas não foram projetadas paratrabalhar com as linguagens usadas nos outros estágios de desenvolvimento, como por exemplo, aUML [21]. Com o surgimento das técnicas dirigidas a modelo, foi demonstrado que o processo dederivação de produtos pode ser especificado sem ambigüidades e automatizado, usando umalinguagem de transformação de modelos de propósito geral, tal como ATL (ATLAS TransformationLanguage) [35], MTL [46] ou xTend [25].A principal desvantagem das linguagens de transformação de propósito geral para especificaro processo de derivação de produto consiste na exigência de conhecimentos avançados nessaslinguagens por parte dos engenheiros de linha de produto de software. Tal fato obriga os engenheirosda linha de produto de software a aprenderem detalhes intrínsecos das técnicas dirigidas à modelo.Isso se deve ao fato dessas linguagens serem freqüentemente baseadas nas manipulações de sintaxesabstratas, requerendo conhecimento detalhado do metamodelo onde o modelo da linha de produto desoftware é expresso.Existem diferentes tipos de linguagem de transformações de modelos, e cada uma delasbaseia-se em um modelo de computação específica. Elas variam de linguagens baseadas em regras(ATL) [23], linguagens ba[25] e linguage[41]. Quando adota-se uma linguagem de transformação de modelos, os engenheiros da linha deproduto de software devem também entender o estilo da computação subjacente (regras bases) eaprender a sintaxe da linguagem. Como resultado, os engenheiros da linha de produto de software sãoforçados a depender das abstrações que podem não ser naturalmente parte do nível de abstração noqual eles estão trabalhando. Além disso, o desenvolvedor deve também entender alguns detalhes dalinguagem de transformação de modelo. Por exemplo, o desenvolvedor deve saber que xTend é umalinguagem baseada em expressões, onde transformações são expressas como funções, as quaisprocessam expressões. Essas expressões, por sua vez, podem ser concatenas usando o símbolo ―->‖.30

A fim de resolver os problemas encontrados nas linguagens de transformação de modelo depropósito geral, os autores propõem a criação de linguagens dedicadas para especificar o processo dederivação de produto em cada estágio do ciclo de vida do software. Segundo os autores, essaslinguagens devem obrigatoriamente: (i) estabelecer links entre os modelos de features (espaçoproblema) e os ativos de software reutilizáveis (espaço solução), especificando quais ações devem sertomadas nos modelos de software quando uma feature é selecionada e quando ela não é selecionada;(ii) prover uma terminologia familiar para o engenheiro da LPS, usando abstrações e conceitoscomumente empregados em cada estágio de desenvolvimento do software; (iii) habilitar a automaçãodo processo de derivação de produto.A linguagem de modelagem de variabilidade (VML - Variability Modelling Language [48] éum exemplo de linguagem que os autores descrevem. A VML pode ser usada para especificarderivações de produto do modelo arquitetural. Ela é uma linguagem textual que facilita a composiçãode ativos arquiteturais de software reutilizáveis e trata-os como abstrações típicas do designarquitetural, tais como componentes ou interfaces.A VML provê mecanismos de composição para especificar explicitamente variabilidadesarquiteturais relativas aos interesses dos arquitetos das linhas de produtos de software. A realização decada interesse arquitetural contém um ou mais pontos de variação e variantes. Primitivas decomposição são definidas para permitir a conexão, adição e remoção de elementos nos modelosarquiteturais.A linguagem de modelagem de variabilidade também provê construtores para especificar aconfiguração de produtos de uma linha de produto de software, isto é, a seleção de quais variantesdevem ser incluídas em um produto específico. A seleção de variantes é descrita em um arquivo deconfiguração VML, o qual contém um conjunto de operadores ―invoke‖. Esse operador refere-seexplicitamente na especificação dos pontos de variação e suas variantes. A automatização pode seralcançada transformando uma especificação VML4* em um conjunto de transformações de modeloexpressas em uma linguagem de transformação comum, tais como ATL ou xTend.O processo de elaboração de uma linguagem VML4* demonstrado no artigo é baseado em umconjunto de transformações de modelos. Essas transformações foram implementadas com a ferramentaopenArchitectureWare (oAW). O processo de elaboração consiste em (i) definir a sintaxe dalinguagem VML4* usando notação EBNF; (ii) implementar cada operador da linguagem como umatransformação de modelo para modelo; (iii) desenvolver um conjunto de transformações de modelopara texto, cujo objetivo é converter especificações VML4* em modelos textuais para transformaçõesde modelos, as quais implementam o processo de derivação de produtos; e (iv) desenvolvertransformações de modelo para executar o processo de derivação de produtos. Tais transformações31

aceitam como entrada um arquivo de configuração VML4*, isto é, uma configuração válida devariantes, e eles geram o arquivo de script que executa o processo de derivação de produtos.Usando todo o ferramental produzido no processo de elaboração da linguagem, os engenheirosda linha de produto de software podem especificar o processo de derivação de produtos e executá-losda maneira descrita a seguir. Primeiro, os engenheiros da LPS criam uma descrição VML4* de umalinha de produto de software. Essa especificação textual VML4* é convertida em uma instância demodelo do metamodelo de VML4*. Então, VML4* é ―compilada‖ usando transformações modelopara texto. Como resultado, é obtido um processo de derivação de produtos implementado como umconjunto de transformações modelo para modelo. Segundo, uma configuração, isto é, a seleção de umconjunto válido de variantes, é criada na descrição VML4* anterior. Essa configuração é ―executada‖usando transformações de modelo, e um script é obtido e executado. Como resultado, é obtido omodelo que especifica o produto (por exemplo, um modelo arquitetural).Por fim, os autores realizaram uma comparação com os demais estudos na área e concluíramque a abordagem proposta provê melhor escalabilidade e manutenibilidade dos modelos do espaço desolução. Isto se deve a proposta apresentada suportar a especificação do processo de derivação desoftware de uma LPS, ou composição de variabilidade, usando uma sintaxe e um conjunto deabstrações familiares aos engenheiros da LPS, evitando que eles tratem de detalhes das linguagens detransformação de modelos. Além disso, a automatização do processo de derivação de produtos emLPS é preservada, transformando especificações VML4* em um conjunto de transformações demodelo especificado em um processo comum de transformação de modelos.Outro fator que aponta a proposta apresentada como uma boa solução consiste na separação deações associadas com variantes dos modelos de LPS, em vez de escrever as ações diretamente sobre osmodelos da LPS, tais como apresentado na proposta de [37]. A proposta dos autores ainda provêoperadores para variabilidades positivas e negativas e suporta sistematicamente tanto quantidadepequena como grande de variantes. As variantes podem ser opcionalmente modeladas em modelosseparados. Além disso, cada variante somente contém as ações que servem para gerir a própriavariação. Desse modo, a adição de novas variantes ou a remoção de variantes existentes não afetamoutras variantes, contribuindo para a manutenção e evolução.2.3.2.2 Modelo de Features para Arquitetura de Produtos: aplicando MDE aLinhas de Produto de SoftwareO trabalho descrito e [41] utiliza as técnicas de Engenharia Dirigida a Modelos (Model-Driven Engineering - MDE) [40] para sistematizar o estágio da Engenharia de Domínio de uma LPSde modo a permitir a automatização do estágio da Engenharia de Aplicação. Os autores utilizam as32

features contidas no modelo de features para representar características funcionais, e as decisõesarquiteturais são explicitamente registradas como um conjunto de regras de transformação de modelos,anexadas a cada features ou a um conjunto de features. Essas regras expressam como construir ofragmento da Arquitetura da Linha de Produto (Product Line Architecture – PLA), a qual fornece asáreas funcionais que cuidam das features selecionadas, e que organizam os componentes associadosàquelas features. A implementação do produto é obtida por meio de geradores. Com isso, os autoresesperam aumentar a capacidade de evolução e de incremento; e diminuir a complexidade do projeto deuma LPS.Os autores focam o trabalho em três atividades principais: Análise, Projeto e Implementação.A Análise utiliza as features para definir explicitamente funcionalidades e também as variabilidades nafase de Análise de Domínio. O Projeto é centrado na arquitetura e aborda decisões estruturais críticas.A Implementação lida com desenvolvimento do componente e do produto em questão.[41] consiste em automatizar oestágio de Engenharia de Aplicação. Particularmente, uma vez que a funcionalidade de um novoproduto é definida pelo Modelo de Configuração de Feature, a Arquitetura do Produto (ProductArchitecture - PA) é automaticamente derivada dele, e a implementação do produto que suporta taltipo de arquitetura também pode ser gerada automaticamente. Para conseguir essas transformações,são aplicadas técnicas de Engenharia Dirigia a Modelos. Os autores consideram todos os artefatoscomo modelos, obtendo assim artefatos passíveis de serem manipulados por ferramentas. Umaabordagem de metamodelagem é usada para definir as linguagens específicas de domínio necessáriaspara expressar cada artefato. Em suma, a automatização da fase de Engenharia de Aplicação érealizada por meio de transformações de modelo, as quais são criadas durante o Projeto de Domínio eaplicadas durante o estágio de Engenharia de Aplicação. Para alcançar esse objetivo, os autoresdefiniram o processo com base nas seguintes seis principais idéias, descritas a seguir:1- Features representam funcionalidades. Existem diferentes propostas para documentarmodelos de domínio, incluindo tanto requisitos funcionais como requisitos de qualidade, taiscomo [17]. Na maioria dessas propostas, características comuns e variabilidades sãocapturadas por meio de um modelo de features. Os autores restringem o modelo de features afim de incluir features que representem funcionalidade, serviços, parâmetros ouarmazenamentos de dados. Então, os autores propõem que o arquiteto da LPS organize asdecisões arquiteturais tomadas durante Projeto de Domínio (Domain Design) em termos defeatures no Modelo de Features.2- Features conduzem a construção da arquitetura de componentes. O Projeto deDomínio tradicionalmente concentra-se na construção da PLA, a qual incorpora as decisões de33

projeto que direcionam funcionalidades e qualidades, e também as características comuns evariabilidades de todos os produtos da LPS. Na abordagem dos autores, essas decisões sãoorganizadas em termos de features no Modelo de Features, que por sua vez, orienta a estruturade composição dos elementos arquiteturais. Cada feature que pode ser selecionada como partede um produto inspira um conjunto de decisões arquiteturais que orientam a construção departe da arquitetura de um produto o qual inclui essa feature. As decisões são tomadaslocalmente para cada feature em particular, considerando apenas as suas features diretamenteabaixo na árvore de features. Seguindo essa abordagem, as decisões relacionadas com aqualidade estão associadas as features próximas da raiz do Modelo de Features, enquanto asdecisões funcionais específicas estão associadas com as características das features perto dasfolhas (subfeatures). Os autores não trataram relações de dependências entre features, comopor exemplo, relações do tipo require e exclude, ou outros tipos de relacionamentos, comocomposto-por, generalização/especialização, e implementado-por entre as features. Essespontos são tratados como trabalhos futuros no artigo.3- Registrar a atividade arquitetural, não a arquitetura. Na abordagem tradicional, oProjeto de Domínio desenvolve a PLA, geralmente produzindo definições arquiteturaiscomplexas em linguagens de descrição arquiteturais não padronizadas. Durante o Projeto doProduto, todas as variabilidades na PLA são resolvidas a fim de obter uma determinadaArquitetura de Produto (Product Architecture - PA). Apesar da Análise de Produtos resolvervariabilidades no nível de features, o Projeto de Produto resolve variabilidades no nívelarquitetural; em seguida, o esforço é, de alguma forma, duplicado. Não existindo nenhumarastreabilidade direta de features para componentes arquiteturais e, principalmente, paradecisões arquiteturais, isso dificulta a assistências de ferramentas na construção de uma PA.Além disso, essa abordagem carece de uma representação de primeira classe para as decisõesde projeto. Apesar de estarem implícitos no artefato da arquitetura resultante, na abordagemtradicional os princípios e decisões arquiteturais subjacentes estão espalhados entre oscomponentes e a estrutura geral. Na abordagem dos autores, eles registram a atividadearquitetural da linha de produtos, no lugar da PLA. Para cada feature no Modelo de Feature,eles preservam o conjunto de decisões envolvidas no fornecimento desta feature pelaarquitetura. Tais decisões são explicitamente registradas como o conjunto de ações as quaisdevem ser executadas em uma PA para suportar a feature. Essas ações são descritas em termosde regras de transformação de modelo, as quais constituem a saída de um fragmento domodelo da PA quando uma feature em particular está presente no produto. Em seguida, oconjunto de regras de transformação de modelo correspondente as features selecionadas34

durante a Análise do Produto constitui o núcleo da transformação de modelo que produz umaPA em particular do Modelo de Configuração de Features.4- Componentes conduzem a implementação. Na abordagem tradicional, aImplementação de Domínio desenvolve, refatora ou obtém de terceiros as implementações decomponentes que participam de uma implementação de um determinado produto. Além disso,um programa gerador (generator program) é normalmente construído de forma a integraresses componentes. Existem dois tipos de componentes: os que não são decompostos e cujasimplementações de componente são desenvolvidas, e aqueles que são decompostos e,portanto, a descrição arquitetural define a forma como eles são projetados em termos decomponentes internos. Para cada componente composto, um componente gerador édesenvolvido durante a Implementação de Domínio que irá montá-lo, considerando asvariações em sua composição interna, tal como descrito pelas regras de transformação quedefinem o componente. Então, existe a rastreabilidade do componente arquitetural para asimplementações de um componente ou geradores de componentes. A integração de todos osgeradores de componentes pode ser considerada como o gerador geral da abordagemtradicional de MDD. Essa integração está em conformidade com a transformação de modeloque obtém uma implementação do produto para uma determinada Arquitetura do Produto.5- Desenvolver incrementalmente a linha de produtos. No processo apresentado pelosautores, a definição dos artefatos da Engenharia de Domínio pode ser construída de formaincremental. Enquanto um Modelo de Features completo é normalmente construído durante aAnálise de Domínio, os outros artefatos podem ser produzidos de forma incremental,abordando somente os recursos que são exigidos por cada produto específico emdesenvolvimento. A estratégia de modularização dos autores não só favorece odesenvolvimento incremental, mas também a evolução, como por exemplo, as mudanças noescopo da LPS passam a ter um impacto limitado sobre outros artefatos desenvolvidos. Oesforço de desenvolvimento é maior para os primeiros produtos que possuam as features maisdo topo e mais componente compostos, os quais provavelmente irão participar de todos osprodutos e, portanto, tais features e componentes deverão ser tratados no início do processo.6- Abstração da tecnologia subjacente. Como a abordagem definida baseia-se em MDE,determinadas tecnologias devem ser utilizadas para a construção dos artefatos. Por exemplo,uma linguagem de transformação de modelos é necessária para definir o conjunto de regrasque produz a Arquitetura do Produto. Além disso, uma linguagem específica é necessária paraa codificação dos geradores de componentes. Para melhorar a capacidade de evolução, os35

autores abstraem as tecnologias subjacentes nos metamodelos, permitindo a integração denovas/diferentes tecnologias MDE.O estágio de Engenharia de Domínio LPS aborda três atividades principais: Análise deDomínio, Projeto de Domínio e Implementação do Domínio, descritas a seguir.Análise de Domínio. Os Modelos de Features têm se mostrado útil e amplamente utilizadopara documentar a Análise de Domínio. Assim, o objetivo desta atividade é a produção de um Modelode Features tal que:- As features folhas incluem as features que podem ser encapsuladas em uma única unidadefuncional. Assim, os nós folha do modelo devem representar uma funcionalidade específicafornecida pelos produtos, parametrização de tais funções, interação com o usuário ou o acessoao armazenamento de dados.- As features internas (ou seja, aqueles com subfeatures) representam as áreas funcionais daLPS que podem ser fornecidas por meio da interação ou da combinação da funcionalidadefornecida pelas features de que elas dependem, ou seja, suas features filhas.O metamodelo que os autores usaram para construir o Modelo de Features é umasimplificação do metamodelo proposto por Czarnecki et al. [43]. Todas as Features no Modelo deFeatures possuem nomes diferentes e podem ser compostas de membros (members). As featuresROOT são usadas para modularizar o modelo; elas não podem ser membros de outras features, eexatamente uma delas deve ser marcada como main (principal) no modelo. Features SOLITARY(solitárias) e GROUPED (agrupadas) representam aquelas que não são agrupadas e são agrupadas,respectivamente. Membros de features compostas podem ser SOLITARY (solitária) ou REFERENCE(de referência) a uma feature ROOT em particular, ou GROUP (agrupada). A feature GROUP consisteem um conjunto de features GROUPED (agrupadas) ou REFERENCE (de referência). A variabilidadeé representada pela cardinalidade: para as features SOLITARY (solitárias), a cardinalidade indicaquantas vezes ela pode ser usada, e para as GROUPS (agrupadas), a cardinalidade indica quantosmembros podem ser realmente utilizados.Projeto de Domínio da Engenharia de Domínio. O objetivo do Projeto de Domínio érealizar as decisões críticas sobre a estrutura da arquitetura do produto e sobre a resolução de atributosde qualidade. Padrões arquiteturais são utilizados a fim de abordar os requisitos de qualidade e asexigências funcionais as quais estão documentadas em artefatos de especificação de requisitos. OModelo de Features é utilizado para organizar as tomadas de decisões durante a atividade de Projetode Domínio. Uma vez que essas features no modelo de features representam aspectos funcionais, osautores seguiram a estrutura de árvore de um modelo para modularizar as decisões arquiteturais. Talabordagem é centrada no registro explicito da atividade arquitetural, e não apenas nos produtos36

arquiteturais. O objetivo do Projeto de Domínio consiste em registrar, para cada feature, as decisõesarquiteturais que são tomadas para resolver a funcionalidade e a variabilidade representada por talfeature na arquitetura. Atributos de qualidade e recursos de implementação existentes também sãoconsiderados, principalmente durante a gravação de decisões de projeto associados a essas features,próxima da raiz do Modelo de Features.Os autores explicam que o Projeto do Produto é semelhante a uma transformação de modelodo Modelo de Configuração de Features para uma Arquitetura de Produto. Assim, as decisõesarquiteturais tomadas durante Projeto de Domínio são registradas como fragmentos dessatransformação de modelo. Cada fragmento é constituído por um conjunto de regras encapsulando aforma de como construir a Arquitetura do Produto quando a feature correspondente está presente noModelo de Configuração de Features. A Arquitetura de Produto é organizada em termos de umavisão arquitetural única, baseada na visão componente-conector [13], onde as regras definem umartefato com componentes, cujas interfaces providas e requeridas são ligadas por conectores. Featuresfolhas provavelmente produzem interfaces de componentes ou componentes que não são maisdecompostos. Features internas produzem componentes que são decompostos em termos de subcomponentesinterligados, os quais correspondem a algumas das suas subfeatures.O Projeto de Domínio produz um artefato de Regra de Transformação Feature-para-Arquitetura, expressa em termos de metamodelo. Um elemento PLA é formado por um conjunto dedeclarações e uma feature de topo. Cada Declaração corresponde a uma declaração geral que pode serusada pelas regras associadas a cada feature. Features possuem nomes distintos, e são organizadas emuma estrutura de árvore inspirada no Modelo de Features. O nome da Feature é usado para fins decorrespondência com as features de uma entrada do Modelo de Configuração de Features. CadaFeature possui um conjunto de regras que indicam como afetar uma saída da Arquitetura doProduto quando a determinada feature está presente em um Modelo de Configuração De Features.Metaclasses de Declarações e Regras são abstratos para fins de portabilidade. Especializações dometamodelo podem ser realizadas, visando tecnologias de transformação de modelos diferentes. Osautores ilustram o artigo com uma especialização contendo regras escritas em ATL [6], embora outraslinguagens possam ser utilizadas. Uma ATLDECLARATION (declaração em ATL) pode incluir umaCALLEDRULE (invocação de regra) ou HELPER (ajuda), todos metaclasses do metamodelo ATL.Uma ATLRULE (regra ATL) em particular consiste em: (i) um filtro OCLExpression (expressãoOCL) para distinguir entre diferentes casos de entrada de features (por exemplo, se feature filha emparticular está presente ou não), (ii) várias RULEVARIABLEDECLARATIONs (declarações deregras variáveis) para regras de restrições específicas, (iii) um OUTPATTERN (padrão de saída)indicando os elementos no modelo da Arquitetura do Produto que devem estar presentes, e (iv) um37

ACTIONBLOCK (ação bloqueante), uma ação imperativa para a regra. Essas metaclasses sãodefinidas no metamodelo ATL e estão em conformidade com os elementos que compõem o núcleo deuma regra geral em ATL como um metamodelo.Implementação de Domínio da Engenharia de Domínio. O objetivo da Implementação doDomínio é de construir, refatorar ou obter de terceiros as implementações de componentes para todosos componentes lógicos que participam na arquitetura dos produtos da LPS. Os autores organizam aimplementação da linha de produtos (Product Line Implementation - PLI) como um modelo expressoem termos de metamodelo.Uma PLI é modularizada em termos de Componentes, inspirado pelos componentes lógicosresultantes das regras na Regras de Transformação de Features-para-Arquitetura. Existem dois tiposde Componentes: Terminais ou Compostos. Um Componente Terminal não será mais decomposto naarquitetura, e somente suas interfaces são especificadas. Para cada componente deste tipo, uma oumais Implementações devem ser disponibilizadas, quer por implementação ou por compra. UmComponente Composto é decomposto em sub-componentes interligados. Para cada componente destetipo, a composição de componentes membros é preservado, e um ou mais Geradores devem serdesenvolvidos. Para esse fim, um script, um programa ou uma transformação é desenvolvido, o qual écapaz de gerar a implementação de componentes para o componente correspondente. Um Geradorencapsula o conhecimento de como implementar o Componente Composto, juntando asimplementações dos componentes membros e gerando qualquer código de cola necessário. Para ambosos tipos de componentes, Implementações e Geradores podem ser direcionados para diferentesplataformas, a qual é anotada em sua propriedade de implantação.O estágio de Engenharia de Aplicação aborda três atividades principais: Análise do Produto,Projeto do Produto e Implementação do Produto, descritas a seguir.Análise do Produto. O objetivo da fase de Análise do Produto consiste na seleção dasfeatures desejadas para um determinado produto. Essas features são selecionadas dentre as fornecidaspela LPS, considerando as restrições de variabilidade. Assim, um Modelo de Configuração deFeatures define qual a configuração do Modelo de Feature que representa o produto a serdesenvolvido e consiste de Features compostas por subfeatures. Um Modelo de Configuração deFeatures representa uma instância do metamodelo de configuração de features; o Modelo de Featuresrestringe quais Modelos de Configuração de Features podem ser realmente definidos.Projeto do Produto. O objetivo do Projeto do Produto consiste em definir a Arquitetura doProduto para o produto específico a ser desenvolvido, considerando suas features definidas no Modelode Configuração de Features. As decisões arquiteturais realizadas durante o Projeto de Domíniodevem ser usadas para produzir a Arquitetura do Produto. Particularmente, o subconjunto das regras38

de transformação de modelo correspondente às features incluídas no produto em desenvolvimento éutilizado para obter a arquitetura. Para este fim, uma meta-transformação é definida, a qual toma umartefato de Regra de Transformação de Feature-para-Arquitetura visando uma dada tecnologiaMDE, e produz uma Transformação de Feature-para-Arquitetura para tal tecnologia. Uma metatransformaçãoé necessária para cada tecnologia MDE utilizada para especializar a Regra deTransformação de Feature-para-Arquitetura. Embora definir essa meta-transformação exija umesforço considerável, uma vez desenvolvida, ela pode ser reutilizada em qualquer projeto dedesenvolvimento LPS que usa a mesma tecnologia MDE. A especialização ATL proposta pelosautores implementou com sucesso a meta-transformação correspondente, que transforma um artefatode Regra de Transformação de Feature-para-Arquitetura para uma transformação ATL. Estatransformação derivada é então aplicada ao Modelo de Configuração de Features para obter aArquitetura do Produto em particular. Por este meio, a atividade de Projeto de Produto é totalmenteautomatizada. A arquitetura resultante é uma instância do metamodelo da Arquitetura do Produto.Implementação do produto. O objetivo da Implementação do Produto é a construção doproduto, considerando a organização arquitetural definida na Arquitetura do Produto. Após umambiente de desenvolvimento particular ou tecnológico ter sido decidido para o produto, ocorrespondente da Implementação de Componentes e Geradores desenvolvidos durante aImplementação do Domínio devem ser utilizados para obter a implementação do produto.Para esse fim, um Gerador de Produto o qual é capaz de gerar a Implementação do Produtodeve ser construído. Procedendo analogamente ao Projeto do Produto, o Gerador do Produto pode serautomaticamente derivado do conjunto de Gerador de Componente desenvolvido durante aImplementação do Domínio, pela definição de uma meta-transformação, a qual deve estar de acordocom as implementações de componentes que precisam ser gerados. Então, um Gerador de Produtoutiliza a Arquitetura do Produto em particular e gera todas as implementações de componente doscomponentes composto que, por sua vez, dependem das Implementações de Componentes para oscomponentes terminais. Provendo essas meta-transformações e as implementações de componentespara os componentes terminais, a atividade de Implementação do Produto também é totalmenteautomatizada.Com esse processo definido pelos autores nesse trabalho, eles almejam aumentar a capacidadeevolutiva e de incremento da LPS, como também diminuir a complexidade do projeto de uma LPS.2.4 Abordagens de Integração entre LPS, DSOA E MDD39

Esta Seção apresenta o trabalho ―Product Line Implementation using Aspect-Oriented andModel-Driven Software Development” [36]. O trabalho focaliza na sinergia da abordagem de linhas deprodutos de software (LPS) com as técnicas de desenvolvimento dirigido a modelos (MDD) edesenvolvimento de software orientado a aspectos (AOSD - Aspect-oriented Software Development)[8].A proposta dos autores consiste em expressar o maior número de artefatos possíveis usandomodelos, dessa forma permitindo processar esses artefatos usando transformações de modelos. Assim,o mapeamento do domínio do problema para o domínio da solução é implementado comotransformações modelo-modelo. Isso permite descrever formalmente mapeamentos e automatizar a suaexecução. As partes variáveis do sistema resultante ou são montadas a partir de ativos pré-construídosgerados a partir de transformações entre modelos ou implementadas manualmente através deinterpretadores/compliladores.Os autores utilizam o método segundo o que as features são representadas em modelos, quesão compostos por técnicas de composição orientadas a aspectos (no nível de modelo) para geraçãodos produtos. As técnicas orientadas a aspectos possibilitam a expressão explícita e modularização devariabilidade transversal no nível de modelo, código e gerador. Sobre DDM, os autores descrevemque, em contraste com a modelagem tradicional, os modelos não apenas irão constar na documentação,mas fazer parte do processo de desenvolvimento, por meios de ferramentas automatizadas. Elessugerem uma DSL (Domain Specific Language) para formalizar a construção de modelos, para adefinição da sintaxe concreta, a qual é usada para representar os modelos. Assim, as ferramentastratam dos metamodelos, enquanto que as DSL cuidam da sintaxe concreta dos modelos.No contexto de linhas de produto de software, DSLs são usadas para ligar variabilidades. Notrabalho, os autores classificam as variabilidades de acordo com as DSL que as descrevem. As (i)variabilidades estruturais são descritas pelas DSLs de construção, geralmente empregadas no domíniodo problema, enquanto que as (ii) variabilidades não-estruturais são descritas pelas DSLs deconfiguração, freqüentemente empregadas no domínio da solução. Usando DSL em ambos osdomínios, é possível usar transformações entre modelos para automatizar esse mapeamento. O modelode domínio do problema pode não conter todas as informações necessárias para a transformação quepreencherá o modelo de domínio da solução. Assim, os autores fazem um ―mixin models‖ paraparametrizar as transformações ou provêem os dados adicionais requeridos.Na abordagem de linhas de produto de software baseada em DDM, modelos são usados pararepresentar produtos no domínio do problema e no domínio da solução. Conseqüentemente, o modelode domínio da solução geralmente necessita ser adaptado baseado na configuração do produto. Em40

outras palavras, os autores querem usar o modelo de configuração para definir variantes de um modeloconstruído com uma DSL de construção.Há duas formas diferentes de realizar essa proposta: através do uso de variabilidades negativase positivas. As variabilidades negativas baseiam-se na presença ou ausência de uma dada característica(feature) na configuração do modelo. O modelo é iniciado contendo todas as características (features)do modelo de features, retirando-se as características as quais não pertencem ao produto que se desejagerar. Já a variabilidade positiva é apresentada como sendo um conjunto mínimo de característicasiniciais no modelo, sendo posteriormente adicionadas, seletivamente, novas características(variabilidades). Para essa última proposta, é necessário especificar quando as novas característicasdevem ser adicionadas, surgindo nessa etapa o uso de DSOA, mais especificamente, a realização deweaving em nível de modelo, chamado de model weaving. O model weaving especifica onde ascaracterísticas adicionais, as quais não foram especificadas no conjunto mínimo de característicasiniciais no modelo (variabilidades positivas), devem ser anexadas. Essas características são inseridasno modelo, onde uma expressão de pointcut define os ―pontos de conexão" para essas características.O rastreamento do modelo de features para a configuração do produto (software) é outroconceito importante na área de linhas de produto de software. Os autores argumentam que, ao agregara técnica de DDM, tal tarefa é facilitada, pois os mapeamentos entre níveis de abstrações são baseadosem transformações de modelos formais. Entre essas transformações, regiões específicas de código sãoassociadas com elementos de modelos. O artigo ressalta as duas formas de passar dos modelos para ageração de código: (i) diretamente do modelo para o código, porém a geração de código necessita serprecisa e (ii) de modelo para modelo, refinando as abstrações até a linguagem alvo; porém, essa últimaatividade é classificada pelos autores como complexa. A primeira abordagem é a adotada em [6], ondesão usados templates de geração com orientação a aspectos, possibilitando assim o isolamento dostemplates em aspectos.A proposta dos autores consiste em, primeiramente, expressar os artefatos, quando possível,usando modelos. Isso permite o processamento desses artefatos usando transformações entre modelos.Em seguida, mapeamentos do domínio do problema para o domínio da solução são implementadoscomo transformações modelo para modelo. Isto possibilita descrever formalmente mapeamentos eautomatizar suas execuções. Logo após, as partes variáveis do sistema resultante são montadasoriundas da pré-construção dos ativos gerados a partir dos modelos ou implementadas através deinterpretadores. Essa atividade é mais eficiente e menos propensas a erros em comparação com acodificação manual em uma linguagem de terceira geração (3GL - Third Generation Language).Então, a modelagem orientada a aspectos (Aspect-oriented modeling - AOM) [4] é utilizada paraimplementar variabilidades nos modelos, apoiando a adaptação seletiva dos modelos. Dessa forma, a41

programação orientada a aspectos (Aspect-Oriented Programming - AOP) [8] é utilizada paraimplementar funcionalidades transversais no nível de código, as quais não podem facilmente sermodularizadas no gerador.Os autores ressaltam que certas partes do produto ainda serão implementadas manualmente,uma vez que, por razões econômicas, o desenvolvimento de um gerador customizado édemasiadamente dispendioso. O código escrito manualmente é integrado com o código gerado portransformações formais.Os autores citam que a forma de expressar variabilidade em nível de modelos ocorre atravésda associação das características presentes no modelo de features a um modelo UML via estereótipos.Esse modelo UML pode ser qualquer diagrama UML que suporte aplicação de estereótipos. Assim,dependendo da característica selecionada, o modelo UML sofre alteração. Os autores relatam queexiste um protótipo em desenvolvimento baseado em OAW [47], enquanto que soluções baseadas emEMF genéricas não encontram-se disponíveis ainda (são considerados trabalhos futuros). Os autoresmencionam compositores de modelos (model weavers) disponíveis, como por exemplo, INRIA’sAMW [29], oAW’s xWeave [22] e C-SAW [28]. Todavia, eles alertam que o termo model weavingainda não está claramente definido na comunidade, e cada uma das ferramentas citadas realiza algodiferente.3 Abordagem Dirigida por Modelos paraDesenvolvimento do GINGAEsta seção apresenta a descrição da abordagem baseada em modelos e aspectos para a geração dafamília de produtos Ginga. Cabe ressaltar que o processo aqui descrito será apoiado por um ambientede desenvolvimento baseado no framework Eclipse. Um protótipo de tal ambiente consiste noentregável final do GingaForAll.A Figura 5 mostra a visão geral do processo de desenvolvimento proposto, ilustrando as suasprincipais atividades: (i) construção do modelo de features, (ii) construção da arquiteturacompartilhada do Ginga e (iii) construção do modelo de aspectos e (iv) geração do produto. Asatividades (i) e (ii) não possuem dependência entre si e podem ser realizadas paralelamente. A seguir,apresentaremos o detalhamento do processo em questão.42

Figura 5: Visão Geral do Processo3.1 Detalhamento da AbordagemA visão geral da abordagem dirigida por modelos, ilustrada na Figura 6 contém todas as atividadesrealizadas pelo processo. Pode-se observar que o processo é dividido em oito atividades principais. Asatividades são: (i) construir modelo de features , (ii) construir arquitetura compartilhada, (iii) construirarquitetura referenciada, (iv) construir modelo de aspectos, (v) especificar PCEs compartilhados, (vi)selecionar variabilidades do produto, (vii) definir plataforma de implementação e (viii) gerar produto.43

Figura 6: Visão detalhada do processo44

Figura 7: Construir Modelo de FeaturesA primeira atividade, construir modelo de features (Figura 7), exige como entrada ometamodelo de Features do Ginga Common Core. Dessa forma, esse metamodelo deve serpreviamente construído e estar disponível no momento da execução dessa primeira atividade (talmetamodelo será um dos artefatos providos pelo ambiente de desenvolvimento a ser construído). Essaexigência se faz necessária, pois esse metamodelo servirá como base para o desenvolvimento domodelo de features a ser utilizado na atividade. Além disso, a atividade também inclui a tarefa deelaborar o profile UML com base no modelo de features desenvolvido. Um profile UML fornece ummecanismo de extensão genérica para personalização de modelos UML para domínios e plataformasespecíficas, identificando um subconjunto do metamodelo UML. Um profile consiste em uma coleçãode extensões tais que, coletivamente, personalizam a UML para um domínio específico ou plataforma.O profile UML com base no modelo de features desenvolvido é composto por diversosestereótipos, um para cada feature do Ginga, cuja finalidade é permitir posteriormente que asentidades da arquitetura do Ginga sejam diretamente anotadas com quais features estão relacionadas.Dessa forma, dois artefatos são produzidos na primeira atividade do processo: (i) o modelo de featuresdo GingaCC (Ver Apêndice A ) e (ii) o profile UML de features do GingaCC. Um pequeno trecho doprofile UML de features do GingaCC é demonstrado na Figura 8. Nessa figura observamos a definiçãode estereótipos para as features referentes ao Tuner do Ginga Common Core. Na Figura 8 encontra-sea metaclasse Class, a qual faz parte do metamodelo da UML. Pode-se visualizar também, ainda namesma Figura, o estereótipo Tuner o qual estende a metaclasse Class. Os demais estereótipos possuemuma relação de generalização com o estereótipo Tuner. Sendo assim, FileSystem ―é um‖ tipo de Tuner.Dessa forma, conclui-se que todos os estereótipos presentes na Figura são tipos diferentes de Tuners.45

Figura 8: Trecho do profile UML do modelo de featuresFigura 9: Construir Arquitetura CompartilhadaA atividade de construir a arquitetura compartilhada, mostrada na Figura 9, consiste namodelagem da arquitetura do Ginga Common Core. Nessa etapa da abordagem, os diagramas UMLreferentes a modelagem do Ginga CC são construídos. Os artefatos gerados nessa etapa são osdiagramas UML, em geral diagramas de classes, que representam a modelagem e especificação daarquitetura. Essa arquitetura foi especificada com base no modelo de componentes do GingaCC. Omodelo de componentes do GingaCC (Profile UML de componentes GingaCC na Figura 4) foidesenvolvido estendendo a UML e é provido como parte do ambiente de desenvolvimentoGingaForAll.46

Figura 10: Construir Modelo de AspectosA atividade construir arquitetura referenciada (Figura 13) consiste na criação de ummapeamento entre elementos presentes no modelo de features e os elementos do modelo de arquitetura(diagrama de classes). Através do profile UML de features e do diagrama de classes podemosrelacionar agora elementos (classes, interfaces) do modelo da arquitetura com as features, descrevendocom qual feature um determinado elemento arquitetural está relacionado. Assim, a atividade ―construirarquitetura referenciada‖ consiste em anotar nos elementos do modelo da arquitetura, através dorecurso de estereótipo da UML, indicando com quais features cada um desses elementos estárelacionado. Essa combinação de arquitetura e estereótipos do modelo de features é chamada dearquitetura referenciada, pois cada elemento arquitetural irá manter uma referência para as featurescom as quais está relacionado. A Figura 11 apresenta um diagrama de classes parcial da arquiteturareferenciada. Nessa figura é demonstrado o pacote tuning da implementação disponibilizada pelaPUC-Rio. Podemos observar as classes presentes no pacote, assim como com qual feature cada classeestá relacionada. O pacote tuning foi utilizado para demonstração uma vez que o profile UMLapresentado anteriormente abrange unicamente as features relacionadas ao Tuner. Dessa forma,podemos encontrar na arquitetura referenciada em questão exatamente os mesmos estereótiposaplicados.47

Figura 11: Arquitetura referenciada do pacote TuningA atividade construir modelo de aspectos (Figura 10) consiste em definir e modelar osaspectos (interesses transversais) encontrados no Ginga. Grande parte dos aspectos representarão asfeatures variáveis do Ginga porém, features obrigatórias que apresentem características transversaisserão modeladas como aspectos também. Para a construção do modelo de aspectos é necessária adefinição de um metamodelo que descreva a semântica das abstrações e mecanismos presentes naorientação a aspectos, para permitir que esse tipo de modelo seja manipulado por uma abordagemDDM. Portanto, para apoiar esta atividade, a ferramenta GingaForAll provê um metamodelo PIM deaspectos descrito na Subseção 3.3. Assim, os aspectos definidos nesta atividade irão seguir todas asrestrições impostas pelo metamodelo de aspectos provido. Os aspectos também podem ser anotados damesma forma que os elementos do modelo da arquitetura, através do recurso de estereótipo da UML,indicando com quais features uma aspecto está relacionado.Figura 12: Selecionar Variabilidades dos Produtos48

A fase de definição dos aspectos pode ser facilitada com o uso de abordagens que ajudem aidentificar os interesses transversais dentro de uma LPS. Uma abordagem que pode ser usada para esseobjetivo é a abordagem de Conejero [15], mostrada na seção 2.2.2. O Apêndice A deste documentomostra a aplicação desta abordagem sobre o Ginga, e essa usa como artefatos de entrada o modelo defeatures do GingaCC e os requisitos funcionais e não funcionais do Ginga.Figura 13: Construir Arquitetura ReferenciadaA atividade seguinte, especificar PCEs compartilhados, ilustrada na Figura 14, consiste emconcretizar os pontos de corte (pointcuts) dos aspectos na arquitetura do Ginga Common Core. Pararealizar tal atividade, faz-se necessário o uso do diagrama de classes que representa a arquiteturacompartilhado decorada, assim como do modelo de aspectos. Esta atividade é essencial no processo degeração do produto, pois é ela que descreve como e onde os aspectos irão interceptar classes daarquitetura do núcleo da LPS. A estratégia a ser adotada para o mapeamento entre os elementosarquiteturais do núcleo e os aspectos especificados ainda está sendo objeto de investigação da equipe,pois deve-se buscar uma abordagem de definição de PCEs que seja ao mesmo tempo expressiva osuficiente para representar diferentes tipos de elementos arquiteturais a serem interceptados e robustaem presença da evolução do sistema, evitando problemas clássicos de DSOA como a fragilidade depointcuts [50].49

Figura 14: Especificar PCEs CompartilhadosA próxima atividade, selecionar as variabilidades do produto, ilustrada na Figura 12,consiste no processo LPS de configuração de um produto. A configuração do produto é realizadaatravés da escolha/seleção das features opcionais e alternativas desejadas para o produto a ser gerado,e que são provenientes do modelo de features do Ginga Common Core produzido na primeiraatividade do processo. As tabelas Tabela 1 e Tabela 2, demonstram quais features devem serselecionadas para instanciar os produtos Ginga NCL/Lua Basic e Ginga NCL/Lua Full. Dessa forma,quando o engenheiro de LPS desejar realizar a configuração de um produto Ginga NCL/Lua Basic eledeve adicionar as features listadas na Tabela 1.A próxima atividade, construir modelos específicos de plataforma (Figura 15), começa coma escolha da plataforma de implementação para a qual será gerado o produto (por exemplo, C++ eAspectual C++ ou Java e AspectJ ). Após essa escolha os modelos PSMs, tanto de aspectos quanto decomponentes, devem ser construídos através de transformações DDM do tipo modelo para modelo.Para tanto são necessárias como entrada: o metamodelo PSM de aspectos e o metamodelo PSM decomponentes, ambos providos pela ferramenta GingaForAll, bem como a arquitetura compartilhadadecorada produzida como saída da atividade 3 e o modelo de aspectos gerado como saída da atividade4.50

Figura 15: Construir Modelos Específicos de PlataformaPor fim, a última atividade do processo, ilustrada na Figura 16, consiste da geração doproduto em questão. Esta atividade recebe como entrada os modelos PSM produzidos na atividade 7 eos mapeamentos produzidos na atividade 6 e consiste na execução de um programa de transformaçãoDDM do tipo modelo para texto.Tabela 1: Features para a construção do produto Ginga NCL/Lua BasicPonto de VariaçãoTunerDemultiplexerApplication ManagerMediaProcessingData ProcessingInput ManagerReturn channelPlataforma de execuçãoVarianteTerrestreHardwareNCL/Lua BasicTudoAtualização de software e Montagem de aplicaçõesControle remoto e/ou teclado e/ou mouseEthernet e/ou ADSLST ou Broadcom51

Tabela 2: Features para a construção do produto Ginga NCL/Lua FULLPonto de VariaçãoTunerDemultiplexerApplication ManagerMediaProcessingData ProcessingInput ManagerReturn channelPlataforma de execuçãoVarianteTerrestreHardwareNCL/Lua Basic e ComplementarTodosAtualização de software e Montagem de aplicaçõesTodosTodosST ou BroadcomAs tabelas Tabela 1 e Tabela 2 contém as features necessárias para instanciar dois produtos dafamília Ginga. Dessa forma, pode-se gerar todos os produtos citados neste documento. Assim, com oarquivo de configuração do produto, a arquitetura referenciada e o mapeamento dos PCEs, fazendouso de transformações automatizadas, o produto é construído.Figura 16: Gerar Produto52

3.2 Descrição dos MetamodelosA abordagem dirigida por modelos proposta faz uso de seis metamodelos. Os metamodelos queatuam em nível PIM são: (i) o metamodelo de features do GingaCC, (ii) o profile UML do modelo defeatures, (iii) o metamodelo PIM de aspectos, (iv) o profile UML de componentes do GingaCC. Osmetamodelos específicos de plataforma são: (v) o profile UML do sistema de componentes daimplementação Ginga disponibilizada pela PUC-Rio e o (vi) metamodelo PSM de aspectos.3.2.1 Metamodelo de features do GingaCCO metamodelo de features do GingaCC é utilizado para a definição do modelo defeatures do Ginga. Ele permite a instanciação de modelos de features onde cada qualdescreverá a configuração de um determinado produto. Nesse metamodelo encontram-setodas as features existentes no GingaCC, assim como suas restrições e seus relacionamentos.Uma visão simplificada desse metamodelo é apresentada na Figura 17.Figura 17: Metamodelo de Features do GingaA Figura 17 contém o trecho do metamodelo o qual descreve as features relacionadasao componente InputManager do GingaCC. Tal componente é encarregado de gerencionar osdispositivos de entrada instalados no hardware. Como observamos, existem 4 variabilidadesno InputManager, sendo elas: (i) keyboard, (ii) remote control, (iii) mouse e (iv) bluetooth.Assim, de acordo com o metamodelo o Ginga prevê suporte a esses 4 dispositivos de entrada.Ainda na Figura 17 observamos que a feature Keyboard é obrigatória por apresentarum relacionamento 1 para 1 com a feature InputManager. As demais features, no entanto sãoopcionais, pois contém relacionamento 0 ou 1 com a feature InputManager. As partesomitidas do metamodelo de features seguem a mesma idéia, permitindo assim modelar asrestrições existentes para as features do Ginga.53

3.2.2 Profile UML do modelo de FeaturesO profile UML do modelo de features tem como principal objetivo permitir anotar nasentidades arquiteturais (classes, interfaces) a quais features tal entidade está relacionada. Esse profileUML é produzido a partir do modelo de features do Ginga Common Core. Nesse profile podem-seencontrar todas as features do modelo sob a forma de estereótipos da UML. Os estereótipos podem serentão utilizados para anotar as entidades arquiteturais presentes no modelo arquitetural do Ginga. Talunião produz a arquitetura referenciada (diagrama de classes anotado com estereótipos que indicamfeatures relacionadas a cada elemento), a qual é utilizada no processo de geração do produto.A Figura 34 (Ver Apêndice A) apresenta todas as features do modelo de features do GingaCommon Core. Nesta figura, pode-se visualizar o metamodelo de features utilizado. Tal metamodelocontém exatamente as mesmas entidades presentes no modelo de features, no entanto, essas entidadesno profile UML são estereótipos de mesmo nome. Assim, por exemplo, a feature Tuner no modelo defeatures é representada no metamodelo de features por um estereótipo, denominado Tuner. Nessecaso, o estereótipo Tuner é aplicado a todas as entidades (classe, interfaces) do modelo arquitetural(diagrama de classes) responsável por implementar a feature Tuner.A aplicação dos estereótipos referentes as features do modelo na arquitetura base produz oartefato, denominado arquitetura referenciada. Essa arquitetura (Figura 13) é utilizada durante astransformações automatizadas no processo de geração do produto. Deste modo, durante atransformação que gera um determinado produto, através de um arquivo de configuração que indica asfeatures desejadas para o produto em questão, a transformação pode determinar quais elementos daarquitetura base estarão presentes no produto final e quais deles devem ser removidos. Assim, oprofile UML do modelo de features é crucial no processo de geração do produto, pois através dele éproduzida a arquitetura referenciada. Essa arquitetura é um dos principais artefatos de entrada naatividade de gerar produto, e o artefato que permite determinar quais entidades arquiteturais compõemo produto.3.2.3 Profile UML de componentes do GingaCCO profile UML de componentes do GingaCC é o profile responsável por identificar nodiagrama de classes da arquitetura quais classes são os componentes do sistema. Para realizar essatarefa o profile conta com um estereótipo chamado Component. Esse estereótipo é aplicado em todasas classes que representam componentes.54

O profile também apresenta um estereótipo cuja finalidade é identificar as interfaces providaspelos componentes. Denominado de Interface, o estereótipo é aplicado nas interfaces externas de umdeterminado componente. Assim, as entidades fundamentais do sistema de componentes podem serrealçados e utilizados posteriormente com maior semântica.Esse profile se faz necessário pois durante as transformações automatizadas posteriores, asentidades da arquitetura relacionadas ao sistema de componentes necessitam ser identificadas. Porexemplo, durante uma transformação automatizada um componente da arquitetura do GingaCC podeser derivado em um componente de um sistema de componentes específicos. Componentes COM ouCorba são possibilidades de plataformas de desenvolvimento baseado em componentes a seremutilizadas. No entanto, no presente trabalho, os componentes são derivados seguindo o padrão decomponentes implementados pela Puc-Rio. O profile apresentado nesse seção é independente deplataforma de componentes.3.2.4 Metamodelo da Plataforma de Componentes Puc-RioO metamodelo do sistema de componentes da implementação Ginga disponibilizada pelaPUC-Rio consiste em um profile UML contendo estereótipos das principais entidades do sistema decomponentes em questão. Esse profile é utilizado com o objetivo de permitir que as transformaçõesautomatizadas gerem a maior quantidade de código possível. O profile UML em questão tambémadiciona semântica a arquitetura do Ginga produzida e essa semântica é utilizada nas transformações,permitindo que os códigos referentes aos componentes sejam produzidos automaticamente.A Figura 18 demonstra o profile UML do sistema de componentes implementado pela PUC-Rio. Como podemos ver, o profile conta com 5 estereótipos onde 4 deles se aplicam a classes e um seaplica a interfaces. O estereótipo GingaInterface, o qual se aplica unicamente a interfaces, é utilizadonas interfaces implementadas pelos componentes do Ginga. Esse estereótipo tem por objetivo permitirque durante uma transformação automatizada, a transformação possa identificar as interfacesimplementadas por um componente e usar essa informação na geração de código.O estereótipo GingaComponent é, por sua vez, aplicado em todas as classes que implementamum componente na arquitetura de componentes do Ginga. Esse estereótipo é o mais importante doprofile, pois através dele é possível determinar quais são os componentes presentes na arquitetura eproduzir os códigos referentes às suas fábricas. Assim, o estereótipo ComponentFactory é aplicado nasfábricas de componentes produzidas automaticamente. Esse estereótipo tem como objetivo realçar naarquitetura produzida durante a transformação que aquela entidade é uma fábrica de componentes.ComponentManager refere-se ao gerenciador de componentes do Ginga Common Core. Esseestereótipo é aplicado nas entidades arquiteturais referentes à implementação do ComponentManager.55

O ComponentManager é o pacote do GingaCC responsável por gerenciar o ciclo de vida dos demaiscomponentes que integram o sistema. O objetivo desse estereótipo é adicionar semântica à arquiteturaproduzida durante as transformações e permitir a fácil visualização por parte do arquiteto das partesreferentes ao sistema de componentes do Ginga.Concluindo o profile UML do sistema de componentes, o estereótipo ComponentConfig éaplicado nas classes referentes a configuração de um dado componente. Essas classes nada mais sãodo que estruturas que contém informações aonde o componente deve ser instalado e quaisdependências em relação a outros componentes o mesmo possui. Esse estereótipo também tem comoobjetivo permitir realçar na arquitetura produzida os elementos referentes ao sistema de componentes.Durante a última etapa de transformações automatizadas, quando a arquitetura é transformada emcódigo C++, esses estereótipos que adicionam semântica ao sistema de componentes são utilizados noprocesso de geração de código. Podemos explicitar que a partir das classes estereotipadas comComponentConfig, as transformações poderão gerar os arquivos XML sobre cada componente,arquivo este que é usado pelo ComponentManager para fazer a carga sob demanda dos componentes.O profile UML do sistema de componentes da PUC-Rio apresentado na Figura 18 édependente da plataforma de componentes utilizada.Figura 18: Profile UML do sistema de componentes implementado pela PUC-Rio3.2.5 Metamodelo de Aspectos Independente de PlataformaO metamodelo de aspectos apresentado nessa seção consiste de uma extensão da UML que aespecializa para lidar com conceitos e abstrações da orientação a aspectos. Tal metamodelo descreveas principais abstrações e mecanismos de orientação a aspectos e o relacionamento entre eles. Este56

metamodelo tem como objetivo permitir a criação ou desenvolvimento de arquiteturas orientadas aaspectos de maneira independente de plataformas específicas, fornecendo os elementos básicos para amodularização dos conceitos transversais. Nossa abordagem permite a integração da orientação aaspectos ao desenvolvimento orientado a modelos tradicional. Ou seja, o metamodelo de aspectopermite a junção dos aspectos com o código base em nível de metamodelo, mantendo assim aseparação dos interesses transversais desde as primeiras fases do desenvolvimento de software. AFigura 19 apresenta o metamodelo de aspectos independente de plataforma.Figura 19: Metamodelo aspectual independente de plataformaNo metamodelo exposto na Figura 19 pode-se observar o conjunto de elementos que formamas abstrações genéricas de uma plataforma de orientação a aspectos. Como pode ser visto, o elementoAspect herda da representação do elemento Class adicionando novos atributos e relacionamentosdestinados a melhorar a modularização dos conceitos transversais. Basicamente, o elemento Aspect écomposto: (i) pelos atributos isPrivileged, que define se o aspecto pode acessar ou não atributos emétodos privados da entidade alvo, e instantiation, que define como o aspecto é associado einstanciado; e (ii) pelas associações Advice, Crosscut, DeclareParents, introduction_method,introdcution_attribute.O elemento advice encapsula um comportamento ou ação a ser executado em um conjunto depontos no fluxo do programa (join points). Dessa maneira, o referido elemento é definido pelo seu57

momento de atuação e pela ação a ser tomada quando um conjunto de pontos de junção for atingido.O metamodelo define os seguintes atributos para o elemento Advice: type, pce e body. O type define omomento de atuação do advice, ou seja, se um aspecto pode atuar durante (around), antes (before) oudepois (after) de um ponto de junção. O atributo pce especifica os pontos do fluxo de execução doprograma afetados pelo elemento advice. Finalmente, campo body descreve o comportamento a serrealizado. No metamodelo, o elemento Advice tem associação com o elemento Parameter paraespecificar os dados do contexto de execução expostos pelos join points que são expostos ao Advice.O atributo return expressa o tipo de retorno obrigatório para o tipo de advice, mas não é definido paraos tipos de advice before e after. O atributo throws define os nomes das exceções, separadas porvírgula, que podem ser dispararas pela execução do corpo de um determinado advice.O elemento pointcut modela uma expressão de ponto de corte. Uma expressão de ponto decorte é uma expressão que relaciona um conjunto de pontos de junção. O elemento pointcut écomposto pelos campos visibility, isInstanceScope, isAbstract, IsConst, name e pce. O campovisibility define a visibilidade de um ponto de corte. O campo isInstanceScope indica se o ponto decorte é estático ou não. O campo isAbstract indica se o ponto de corte é abstrato, e, se portanto, nãopossui declaração de expressão (pce). O campo name informa o nome do ponto de corte. O atributoIsConst indica se o ponto de corte em questão é constante ou não. Finalmente, o campo pce (pointcutexpression) é formado por um conjunto de operadores, designadores e wildcards. É possível ainda,observar que o elemento pointcut tem uma relação de composição com o elemento parameters. Essarelação expressa a capacidade que um ponto de corte possui de declarar nenhum ou vários parâmetrospara realizar a passagem de informações contextuais para advices.O elemento crosscut representa no nível de modelos, um conjunto de entidades que sãoafetadas por um determinado aspecto. Ou seja, o elemento crosscut representa explicitamente ligaçõesentre aspectos e componentes regulares (código base). O elemento crosscut é formado pelos seguintesatributos: targetNameSpace, target e type. O targetNameSpace define toda hierarquia de pacotes , otarget define o nome e o type define o tipo da entidade afetada pelo aspecto.O elemento DeclareParents permite mudar a estrutura hierárquica (estática) de um conjuntode classes. Logo, através de tal elemento é possível inserir relacionamentos de herança eimplementação nas classes afetadas. Esse elemento é constituído pelos atributos: isImplemented,isExtends, pattern e type. O atributo isImplemented define a inserção de relacionamento de realizaçãoentre uma classe e uma determinada interface, significando que a classe implementa a interface. Oatributo isExtend insere um relacionamento de herança entre classes. O atributo pattern define oconjunto de classes que terão sua estrutura afetada. O atributo type define os nomes das entidades,58

separados por vírgula, que serão implementadas ou estendidas por um conjunto de entidades base(pattern).Os elementos IntroductionMethod e IntroductionAttribute alteraram a estrutura de umaentidade alvo através da adição de métodos e atributos, respectivamente. Esses elementos sãocomumente chamados de declarações inter-tipos. Os outros elementos presentes na Figura 10 sãoelementos regulares das linguagens orientadas a objetos. São eles: classes, interfaces, métodos,atributos e tipos de dados definidos pelo usuário.Por ser indepentende de plataforma, o metamodelo apresentado será utilizado como umtemplate para instanciação de metamodelos específicos de plataforma. O processo de transformação domodelo independente de plataforma para o específico é simples e consiste de um mapeamento dosconceitos genéricos para elementos específicos de cada linguagem orientada a aspectos.3.2.6 Metamodelo de Aspectos Específico de PlataformaO metamodelo apresentado na seção anterior é um modelo genérico e independente deplataforma. A partir desse modelo pode-se derivar um modelo específico de plataforma que contemplaas construções válidas para uma dada plataforma de orientação a aspectos. No projeto GingaForAll alinguagem AspectC++ será adotada como plataforma de orientação a aspecto para modelar eimplementar os interesses transversais do Ginga. O metamodelo de aspectos específico da plataformaAspectC++ é apresentado na Figura 20.No metamodelo exposto na Figura 20 pode-se observar o conjunto de elementos que formamas abstrações da linguagem AspectC++ mapeados de acordo com os conceitos do metamodelo daseção anterior. Na Figura 20, é possível notar que a maioria dos conceitos foram mapeadosdiretamente do modelo independente de plataforma para o AspectC++, aparecendo apenas dois novosconceitos: slice e baseclass.59

Figura 20: Metamodelo Ecore da linguagem AspectC++

O elemento Slice é um fragmento de um elemento de linguagem C++ que define umescopo. Ele pode ser usado por um advice para estender a estrutura estática do programa. Assim,elementos de um slice podem ser combinados em uma ou mais classes alvo de um advice. Oslice tem relação com os elementos: properties e method. O relacionamento com o elementoproperties pode introduzir um ou mais atributos em uma entidade alvo, e o relacionamentocom o elemento method pode introduzir um ou mais métodos ou construtores em uma entidadealvo.O elemento baseclass permite mudar a estrutura hierárquica (estática) de um conjuntode classes. Logo, através de tal elemento é possível inserir relacionamentos de herança eimplementação nas classes afetadas. Um elemento baseclass é constituído pelos atributos:isImplemented, isExtends, pattern e type. O atributo isImplemented define a inserção derelacionamento de realização entre uma classe e uma determinada interface, significando que aclasse implementa a interface. O atributo isExtend insere um relacionamento de herança entreclasses. O atributo pattern define o conjunto de classes que terão sua estrutura afetada. Oatributo type define os nomes das entidades, separados por vírgula, que serão implementadas ouestendidas por um conjunto de entidades base (pattern).A aplicação do metamodelo de aspectos fornecido consiste em decorar as classes querepresentam aspectos de acordo com o perfil apresentado. Esse processo é apresentado emdetalhes na seção seguinte.3.3 Modelagem dos AspectosComo visto na Seção 3.1, a atividade construir modelo de aspectos engloba aespecificação e a modelagem dos aspectos encontrados no Ginga. Uma vez tendo identificadoos interesses transversais (com o auxílio de metodologias, como por exemplo, a descrita em[15]), a etapa de definição dos aspectos nada mais é do que a aplicação do profile nos conceitostransversais identificados. Basicamente, pode-se afirmar que as meta-classe que estendem umameta-classe já existente tornam-se estereótipos e os atributos de extensão de meta-classestransforma-se em tagged values. Dessa maneira, Os elementos Aspect se tornam classesmarcadas com o estereótipo e os atributos desse elemento se tormam tagged value.O atributo isPrivileged do elemento Aspect, por exemplo, se torna o atributo private doestereótipo . Os advices são operações marcadas com estereótipo .Cada elemento advice esta associado a um ponto de corte, devido ao relacionamento entre oselementos advice e poincut do metamodelo de aspectos. Tal associação é definida pelapropriedade pce do referido elemento. É possível ver na Figura 20 que o elemento pointcut está61

associado ao elemento advice, logo o elemento poincut é instanciado como um atributo doelemento Aspect com o estereótipo . Por sua vez, o elemento crosscut é instanciadocomo um relacionamento entre uma classe marcada como o estereótipo class e um conjunto declasses ordinárias. Para facilitar a identificação desse tipo especial de relacionamento, osrelacionamentos do tipo crosscut foram marcados com o estereótipo .O elemento baseclass é instanciado como um atributo do aspecto marcado com oestereótipo . Finalmente, o elemento slice também é instanciado como umrelacionamento marcado com o estereótipo e contendo as seguintes propriedades:method e property. Indicando a introdução de métodos ou propriedades em um conjunto declasses do código base.Figura 21: Exemplo de aplicação do profile de aspectos.A Figura 21 apresenta um exemplo de aplicação do profile de aspectos. O aspectoAutenticação contém: (i) três atributos, private, pointcut1 e baseclass; e (ii) um método advice,chamado de autenticação. O primeiro atributo indica se o aspecto pode interceptar ou não osatributos privados dos componentes. O segundo atributo define um ponto de corte pointcut1. Talponto de corte define que o aspecto Autenticação irá executar o advice autenticação antes(before) do método save() da classe Classe1. Por fim, o atributo baseclass indica que o aspectoAutenticação altera a estrutura hierárquica da classe classe2. A classe classe2 passa aimplementar a interface interface1. Além disso, o aspecto autenticação possui um62

elacionamento do tipo slice que altera a estrutura estática de uma classe. Esse relacionamentodefine que a classe3 ganha um atributo do tipo inteiro e dois novos métodos: get e set.4 Ferramentas, Tecnologias e LinguagensUtilizadasEsta seção descreve as ferramentas, linguagens e tecnologias utilizadas para a confecçãoda solução inicial proposta no presente trabalho. A Tabela 3 mostra onde cada ferramenta éutilizada durante o processo. Como podemos observar, duas das principais ferramentas elinguagem utilizadas na nossa abordagem são o Eclipse e a UML. No entanto, o CrossMDA tempapel fundamental na geração do produto e no mapeamento das expressões de ponto de corte.Nessa seção detalharemos cada uma dessas tecnologias.Tabela 3: Relação entre as ferramentas utilizadas e as atividades do processoCrossMDA Eclipse UMLEMF/Ecore AcceleoConstruir Modelo de Features doGinga CCX X XConstruir Arquitetura Compartilhada X X XConstruir Modelo de Aspectos X X XConstruir Arquitetura Referenciada X X XEspecificar PCEs Compartilhados X X X XSelecionar Variabilidades doProdutoConstruir Modelos Específicos dePlataformaX X X XX X X XGerar Produto X X X X X63

4.1 CrossMDAO CrossMDA [2] consiste em um framework para o desenvolvimento de softwarebaseado em desenvolvimento dirigido por modelos e orientação a aspectos. Ele dispõe de umprocesso de transformação que realiza a integração de interesses transversais em sistemasbaseados em modelo, utilizando a sinergia entre as abordagens MDA (Model DrivenArchitecture) e POA (Programação orientada a aspectos). O CrossMDA foi desenvolvido com opropósito geral de melhorar a gerência do processo de combinação (weaving) entre asabordagens MDA e POA, provendo o reuso dos artefatos gerados durante todo o seu processo.A gerência ocorre através do processo de combinação juntamente com os serviços demapeamento, que disponibilizam ao Engenheiro de Aplicação um melhor controle sobre aforma de como realizar a combinação entre os elementos do modelo de negócio com osaspectos.O CrossMDA apresenta reuso dos artefatos desenvolvidos, visto que: (i) os modelos deaspectos e negócio são criados independentes de plataforma, sendo possível realizarcomposição de aspectos, gerando novos modelos de aspectos independentemente do domíniobase;(ii) o processo de transformação utiliza templates de código de transformação emlinguagem ATL (Atlas Transformation Language) , os quais são capazes de gerar modelos emdiferentes sintaxes e facilita a manutenção, pois podem ser modificados sem a necessidade dealterar o código; e (iii) o modelo PSM gerado pelo processo CrossMDA é baseado no padrãoXMI, padrão também utilizado em outras ferramentas de transformação modelo-texto. Alinguagem ATL é uma linguagem de transformação de proposta pelo grupo Atlas, a qual seencontra de acordo com a especificação OMG (Object Management Group) MOF (Meta-ObjectFacility) QVT (Query View Transformation).O CrossMDA permite o tratamento de aspectos no nível de modelagem e fornecemecanismos que possibilitam a separação de interesses na dimensão horizontal, entre modelosde um mesmo nível de abstração, bem como a separação na dimensão vertical, entre modelos dediferentes níveis de abstração. A dimensão horizontal permite a modelagem de interessestransversais independentemente dos elementos de negócio. Para tanto, o CrossMDA sugere umprocesso que utiliza modelos de aspectos no nível de PIM (Platform Independent Model). Talmodelo de aspectos é uma representação abstrata de um determinado interesse transversal, quepermite esconder os detalhes de implementação do aspecto para o projetista de negócio,elevando assim o nível da modelagem no PIM.64

Quanto à dimensão vertical, ela é endereçada através da implementação de um processode transformação para gerar modelos das instâncias dos aspectos. Como os modelos de aspectose de negócio são independentes, é oferecido ao projetista um processo para guiar e documentaros relacionamentos entre o aspecto e o elemento de negócio, a serem utilizados na composiçãodo novo modelo. Através do uso de uma linguagem formal de transformação baseada no padrãoMOF-QVT (Query, View, Transformation), o CrossMDA oferece, ao final de seu processo decomposição de modelos, a geração automática de um programa de transformação, o qualcorresponde à implementação da especificação formal do processo de composição de modelos.Esse processo permite a edição, pelo projetista, de composições de modelos já existentes semperda dos mapeamentos entre os aspectos e elementos de negócio.O processo de uso do CrossMDA (Figura 22) está dividido em três fases. Na fase 1ocorre as atividades de seleção dos modelos PIM de negócio e aspectos que foramdesenvolvidos de forma manual pelos engenheiros de domínio, como também de carga epersistência desses modelos no repositório. A fase 2 engloba as atividades de mapeamento dosrelacionamentos entre os aspectos e os elementos do modelo de negócio. Por último, a fase 3compreende das atividades que são responsáveis pela geração do novo modelo, as quais incluemtodos os elementos do modelo de negócio e os elementos aspectuais selecionados na faseanterior, mapeados em um nível dependente de plataforma computacional (PSM).A fase 1 engloba as atividades (1) e (2) (ver Figura 22). A atividade (1) consiste emrealizar a escolha dos modelos PIM fontes a serem utilizados durante o processo detransformação e a atividade (2) é responsável pela carga e persistência dos modelos norepositório de metadados. Os modelos fontes são de dois tipos: modelo de aspectos e modelo denegócio. O modelo de aspectos consiste na representação abstrata, isto é, independente deplataforma, de interesses transversais, modelados como classes com o estereótipo eorganizados em pacotes. No CrossMDA, um pacote de aspectos é uma entidade que agrupaaspectos relacionados, ou seja, que dizem respeito a uma mesma categoria de requisito. Porexemplo, um pacote pode conter vários aspectos relacionados a autenticação, outro a logging,etc. O modelo de negócio, por sua vez, é composto pelas entidades, classes de serviços,relacionamentos, restrições, diagramas de classes e interação e demais elementos querepresentam toda a modelagem do processo de negócio. A fase 2 é responsável por mapear ostipos de relacionamentos entre os aspectos e os elementos do modelo de negócio. Essa faseinicia-se com a atividade (3) que permite ao projetista selecionar os pacotes de interessestransversais que são relevantes ao domínio da aplicação. Por exemplo, se o projetista desejaincluir no modelo funcionalidades de segurança, então ele seleciona um pacote que contém osaspectos relativos à segurança. Em seguida, é iniciado o processo repetitivo de definição de65

elacionamento que engloba as atividade (4), (5) e (6). A atividade (4) é responsável pelaseleção dos elementos aspectuais; a atividade (5) é responsável pela seleção dos elementos donegócio e; a atividade (6) realiza o mapeamento final do relacionamento, armazenando oselementos selecionados nas atividades (4) e (5) juntamente com o tipo designador do ponto dejunção (join point) e os tipos de adendo (advice) selecionados no modelo de mapeamento.A fase 3 é a responsável por realizar a composição do novo modelo, incluindo todos oselementos do modelo de negócio existentes e os novos elementos que representam as instânciasdos aspectos mapeados em um nível já dependente de plataforma computacional (PSM). Écomposta por 4 atividades que representam a combinação de modelos (weaving) e atransformação. A fase é iniciada com as atividades (7) e (8) do combinador (weaver). Aatividade (7) é responsável por gerar um modelo intermediário a partir dos relacionamentosmapeados da fase 2. Em seguida, a atividade (8) é iniciada, cuja responsabilidade é transformaro modelo intermediário em uma especificação formal através da geração de um programa detransformação baseada na especificação MOF (MetaObject Facility) QVT (Query-View-Transformation) da OMG. As atividades (9) e (10) representam as funções do transformador demodelos, e consistem respectivamente em compilar e executar o programa de transformaçãogerado pelo combinador de modelos.66

Figura 22: Processo CrossMDACom o intuito de dar suporte a essas atividades, o CrossMDA possui quatro serviçosimplementados. O serviço de persistência de modelos consiste na implementação das operaçõesbásicas que permitem a carga e persistência dos modelos, bem como, as operações de navegaçãoe recuperação dos modelos existentes. O serviço de mapeamento de elementos é responsável67

pelo mapeamento dos relacionamentos entre os aspectos e os elementos de negócio. O serviçode combinação de modelo consiste na fase que finaliza o processo de mapeamento e éresponsável por realizar a integração dos elementos do modelo de aspectos ao modelo denegócio, gerando as instâncias dos aspectos selecionados e suas respectivas associações com oselementos de negócio. O serviço de transformação de modelo é executado logo após a geraçãodo programa de transformação e é encarregado de finalizar todo o processo no CrossMDA,compilando e executando o programa de transformação, gerando o novo modelo que contém asadaptações previstas nas regras declaradas.O CrossMDA é empregado nas seguintes etapas do processo descrito na Seção 3: (i)especificar PCEs compartilhados, (ii) selecionar variabilidades do produto, (iii) definirplataforma de implementação e (vi) gerar produto.4.2 Eclipse GalileoO Eclipse é um projeto open source e seu propósito principal consiste em proveruma plataforma integrada de ferramentas para o desenvolvimento de softwares. O projetoinclui um projeto principal, que fornece um framework genérico para integração deferramentas, e um ambiente de desenvolvimento Java. Outros projetos estendem o projetoprincipal para suportar tipos específicos de ferramentas e ambientes de desenvolvimento.Todo software produzido pelo projeto é disponibilizado pelos termos de uma licençaprópria do projeto. A Eclipse Public License (EPL) [Eclipse Public License] declara ostermos legais de uso dos produtos gerados pelo projeto, permitindo que qualquer pessoause, modifique e redistribua o software sem qualquer custo. A licença permite também adistribuição do projeto ou parte dele junto com software proprietário como parte de umaferramenta comercial. A licença EPL é aprovada pelo grupo Open Source Initiative (OSI) ereconhecido pelo Free Software Foundation como uma licença de software livre. Aindapelos termos da EPL, qualquer software dado como contribuição ao projeto deve tambémser licenciado pelos termos da EPL.O trabalho em desenvolvimento no projeto Eclipse é dividido em projetos de altonível como, pode-se citar (i) o Projeto Eclipse, (ii) o Projeto de Modelagem, (iii) o Projetode Ferramentas e (iv) o Projeto de Tecnologia. O Projeto Eclipse suporta odesenvolvimento de uma plataforma para a criação de ambientes integrados dedesenvolvimento (Integrated Development Environments - IDEs) e outras aplicações. OProjeto de Ferramentas desenvolve uma série de ferramentas de desenvolvimento68

extensíveis baseadas na Plataforma Eclipse. O Projeto de Tecnologia é utilizado comoponto de entrada e repositório temporário de trabalhos novos ou experimentais depesquisadores e acadêmicos, os quais podem ser alocados em outro projeto.O Projeto de Modelagem do Eclipse é o ponto focal para a evolução e promoção detecnologias de desenvolvimento baseada em modelos em Eclipse. No seu núcleo encontra-se oFramework de Modelagem do Eclipse (Eclipse Modeling Framework - EMF), um frameworkbásico para modelagem, o qual será apresentado na seção 4.5. Outros subprojetos de modelagemsão construídos sobre o EMF, provendo integração com banco de dados, transformações demodelos e geração de editores gráficos [32]. O Eclipse Galileo [31], versão mais atual, contémum ambiente para desenvolvimento da abordagem MDA, fator determinante na escolha daferramenta no neste trabalho.O Eclipse Galileo é empregado em todas as etapas do processo descrito na Seção 3: (i)construir modelo de features , (ii) construir arquitetura compartilhada, (iii) construir arquiteturareferenciada, (iv) construir modelo de aspectos, (v) especificar PCEs compartilhados, (vi)selecionar variabilidades do produto, (vii) definir plataforma de implementação e (viii) gerarproduto.4.3 UML e MOFA UML (Unified Modeling Language) [21] consiste na especificação mais usada naOMG[11] e juntamente com o MOF (Meta Object Facility)[30], que é um padrão da OMG paraa engenharia dirigida a modelos, fornece uma base fundamental para a MDA. A OMG é umgrupo que fornece diretrizes para a indústria de software, através de especificações de padrões,cuja missão é promover a teoria e a prática da tecnologia de objetos para o desenvolvimento desistemas distribuídos. UML é uma linguagem gráfica, utilizada em Engenharia de Software paramodelar sistemas orientados a objeto, que além de definir uma notação gráfica, conjunto desímbolos padrões, especifica, em detalhes, a semântica destes símbolos de tal forma que omodelo idealizado para o sistema possa ser compreendido por todos, facilitando a comunicaçãoefetiva entre os desenvolvedores que a utilizam [21]. A UML unifica todas as etapas dedesenvolvimento e integração de modelagem de negócios, através da modelagem arquitetural emodelagem de aplicação, para o desenvolvimento, implantação, manutenção e evolução dosistema [21]. A UML 2.1 é a versão da UML adotada neste trabalho, pelo fato de ser a versãomais nova. Os diagramas utilizados no processo MDD descrito na Seção 3 são os diagramas declasse. No decorrer desse relatório, os diagramas de atividades da UML foram tambémutilizados.69

Outro padrão OMG utilizado é o MOF (Meta Object Facility) um conjunto de serviçosprojetados para suportar a administração de metadados. Exemplos de metadados são: tipos dedados nas linguagens de programação, definições de interfaces dos componentes, diagramas deanálise e projeto, esquemas SQL que descrevem a estrutura de banco de dados relacionais [30].O MOF, no contexto DDM, especifica uma linguagem abstrata para descrever outras linguagense é também conhecido como metametamodelo. As linguagens abstratas descritas a partir doMOF são chamadas de metamodelo. O metamodelo da UML, por exemplo, é descrito a partirdo MOF.A OMG criou, em novembro de 2000, o padrão XML Metadata Interchange (XMI)para representar um mecanismo padrão de troca de dados usado entre várias ferramentas,repositórios e middleware. Na época, isto deveria garantir a facilidade na troca de metadadosentre ferramentas de modelagem baseadas no padrão OMG-UML e os repositórios demetadados baseados em OMG-MOF em ambientes heterogêneos distribuídos. Maisrecentemente, o XMI tem sido usado para interpretar artefatos UML, artefatos de base de dadose data warehouse, definições de interfaces CORBA, interfaces e classes JAVA [39].A UML padrão encontra-se composta por três mecanismos de extensão. Essesmecanismos foram criados no intuito de permitir o desenvolvimento de novos conceitos quepreviamente não existam na UML ou que seja contraditório com algum conceito já presente[49]. Os mecanismos de extensão consistem dos estereótipos, das restrições e do valor atribuído.Os estereótipos permitem a classificação de um elemento de modelo estendido deacordo com um elemento de modelo base já existente na UML, definindo novas restrições eatributos. Os estereótipos também podem possuir uma nova representação gráfica. Os nomesdos estereótipos devem, obrigatoriamente, ser diferentes dos existentes no metamodelo daUML, a fim de evitar conflitos.As restrições ampliam as semânticas dos novos estereótipos, permitindo acrescentarnovas regras ou modificar regras já existentes. Elas são definidas em linguagens para construçãode restrições e regras, linguagem de programação, notação matemática ou linguagem natural.Uma restrição é adicionada diretamente ao estereótipo, sendo também, aplicada a todos oselementos estendidos por esse estereótipo [49].O valor atribuído estende as propriedades de um elemento da UML, permitindo acriação de novas informações na especificação desse elemento. Todo valor atribuído consisteem um nome e um tipo associado a um estereótipo em particular [49]. Em suma, esses trêsmecanismos de extensão possibilitam a construção de um profile UML que permite estender osmodelos da UML, conceito explorado na seção 4.4.70

A UML é empregada nas seguintes etapas do processo descrito na Seção 3: (i) construirmodelo de features , (ii) construir arquitetura compartilhada, (iii) construir arquiteturareferenciada, (iv) construir modelo de aspectos, (v) especificar PCEs compartilhados, (vi)selecionar variabilidades do produto, (vii) definir plataforma de implementação e (viii) gerarproduto.4.4 Profile UMLUm profile UML fornece um mecanismo de extensão genérica para personalização demodelos UML para domínios e plataformas específicas, identificando um subconjunto dometamodelo UML. Um profile consiste em uma coleção de extensões tais que, coletivamente,personalizam a UML para um domínio específico ou plataforma. Assim, um profile UMLespecifica ―regras bem formadas‖ adicionais as regras especificadas pelo metamodelo da UML[21]. Essas ―regras bem formadas‖ consistem em uma expressão usada na especificaçãonormativa do metamodelo UML para descrever um conjunto de restrições escritas, que contribuipara a definição de um elemento do metamodelo. Esse conjunto de restrições é escrito emlinguagem OCL (Object Constraint Language) [24], uma linguagem declarativa que descreve asregras para especificar restrições sobre modelos orientados a objetos ou outros artefatos dalinguagem UML [21]. Além disso, um profile UML especifica ―elementos padrões‖, outraexpressão usada na especificação do metamodelo UML para descrever uma instância padrão deum estereótipo UML, tagged value ou restrição. O profile UML também é responsável porespecificar semântica, expressa em linguagem natural, além dos especificados pelo subconjuntoidentificado no metamodelo UML.É importante lembrar que um profile UML define os mecanismos usados para adaptar ometamodelo da UML a novas plataformas ou a um domínio específico. A responsabilidade dometamodelo é definir uma linguagem que será utilizada para elaborar um modelo. Assim, osestereótipos de um profile UML serão instanciados a partir de um determinado elemento dometamodelo UML.Atualmente, já existem diversos profiles UML, alguns dos quais bem sucedidos evalidados pela OMG, como por exemplo: os Profiles UML para CORBA e para CCM (CORBAComponent Model), o Profile UML para EDOC (Enterprise Distributed Object Computing), oProfile UML para EAI (Enterprise Application Integrations), o Profile UML para Scheduling,Performance, and Time e o Profile UML para Web Applications Extension – WAE. Existemtambém outros vários profiles os quais ainda estão sendo validados pela OMG.71

Os Profiles UML são criados a partir da etapa de construir modelo de features doprocesso descrito na Seção 3 e utilizados na (i) construção da arquitetura referenciada, (ii) naatividade de especificar PCEs compartilhados, (iii) na seleção de variabilidades do produto e(vi) na geração do produto.4.5 EMF e EcoreO EMF (Eclipse Modeling Project) [26] consiste em um framework Java/XML demodelagem e geração de código para instalação de ferramentas de construção e outrasaplicações baseadas em um modelo de dados estruturados. EMF permite a construção deferramentas orientadas a modelos, possibilitando a geração de classes Java para criação e ediçãode modelos baseadas num dado metamodelo especificado em XML Schema ou usandodiagramas de classe UML [51]. A partir de uma especificação do modelo descrita em XMI, oEMF fornece suporte e ferramentas em tempo de execução para produzir um conjunto de classesJava para o modelo, juntamente com um conjunto de classes adaptadores que permite avisualização e edição baseada em comandos do modelo e um editor base [32].O framework EMF permite a modelagem do domínio utilizando um metamodelo próprio,relativamente mais simples do que a especificação MOF (Meta-Object Facility) da MDA(Model Driven Architecture), chamado Ecore. O Ecore [26] consiste no metamodelo usado pararepresentar modelos em EMF, em outras palavras, é uma terminologia comum para descrevermetamodelos de modelos. O Ecore, por ser independente de linguagem, não é capaz de gerarcódigo, sendo necessária a transformação em um metamodelo específico para a geração códigoJava. A plataforma Eclipse, por sua vez, permite a adição de funcionalidades por intermédio deplug-ins, onde os metamodelos adicionais podem ser implementados [33].O EMF e Ecore são empregados em todas as etapas do processo descrito na Seção 3: (i)construir modelo de features , (ii) construir arquitetura compartilhada, (iii) construir arquiteturareferenciada, (iv) construir modelo de aspectos, (v) especificar PCEs compartilhados, (vi)selecionar variabilidades do produto, (vii) definir plataforma de implementação e (viii) gerarproduto.4.6 Acceleo72

O Acceleo é um gerador de código open source concebido para implementar de formaeficaz a abordagem MDA e para melhorar a produtividade do desenvolvimento do software. OAcceleo consiste em uma ferramenta completamente integrada ao Eclipse para transformação demodelos em código, mas especificamente o do modelo PSM para texto (código gerado). Foidesenvolvido pela companhia francesa Obeo e é uma ferramenta Open Source. Para efetuar astransformações, o Acceleo usa o conceito de Módulos, os quais são coleções de templates quedescrevem a informação necessária para gerar código-fonte a partir de um metamodelo. Cadamódulo é específico para uma tecnologia (Java, C#, etc). Em cada template, scripts permitemque o usuário customize o gerador de forma precisa.Essa ferramenta é compatível com XMI 1.x e XMI 2, o que garante a compatibilidadecom outras ferramentas para a modelagem UML. O Acceleo oferece recursos da engenharia demodelos, no tocante a geração de código incremental, interoperabilidade de metamodelo,customização dirigida a modelo. Outras características importantes abrangem o cumprimentodas especificações e recomendações da OMG na implementação de QVT(Query/View/Transformation) e MOF (Meta-Object Facility), possui módulos disponíveis paraC#, JEE Hibernate/Strufs, Python e PHP, entre outros e existe a possibilidade de desenvolvermódulos para outras linguagens. A Figura 23 apresenta uma visão geral do uso do Acceleo noprocesso de geração de código baseado nos modelos. Como podemos observar na Figura 23, oAcceleo recebe como entra os modelos e o módulo que descreve a plataforma de saída, e entãoele transforma os modelos em código de acordo com o módulo fornecido. O Acceleo suportaatualmente módulos JEE, PHP, Net e etc. O plugin Acceleo é empregado no processo descritona Seção 3 na última etapa do processo, na etapa de geração de produtos.73

Figura 23: Visão geral do uso do Acceleo [34]74

Referências[1] SCHMIDT, D, Model-Driven Engineering. IEEE Computer 39(2): 25-31, 2006.[2] FILMAN, R.; et al. Aspect-Oriented Software Development. 2005: Addison-Wesley.[3] NORTHROP, L. M. , SEI`s Software Product Lines Tenets, IEEE Software, v. 19, n. 14, p.32-41, 2002[4] Frankel, D. S. Model Driven Software Development. Business Process Trends Journal inMDA, 2004.[5] MEZINI, M. and OSTERMANN, K.: Variability Management with Feature-OrientedProgramming and Aspect, pp. 127 – 136, ACM SIGSOFT, 2004[6] ARAÚJO, J.; MOREIRA, A.; BRITO, I.; RASHID, A. Aspect-oriented Requirements withUML. Workshop on Aspect-oriented Modeling with UML. 2002.[7] Miller, J., Mukerji, J. MDA Guide Version 1.0.1: Document number: omg/2003/06/01.Disponível em: .Acesso em: abr 2009.[8] KICZALES, G. et al. ASPECT-ORIENTED PROGRAMMING. In: Proceedings of the 11thEuropean Conference on Object-Oriented Programming. [S.l.]: Springer-Verlag, 1997. v. 1241,p. 220–242[9] GRISS, M.: Implementing product-line features by composing aspects. In proceedings ofFirst International Software Product Line Conference, pp. 271—288, Denver, USA, 2000.[10] SILVA, J.D.S. AO-OiL: um middleware orientado a aspectos baseado em uma arquiteturade referência. Dissertação (mestrado) – Universidade Federal do Rio Grande do Norte, 2009.[11] OMG - The Object Management Group. Disponível em: http://www.omg.org/. Acesso em:maio 2009.[12] KICZALES, G., E. HILSDALE, et al.: An Overview of AspectJ. Proceedings of the 15thEuropean Conference on Object-Oriented Programming (ECOOP'01), 2001.[13] LINDEN, L. F.; SCHMID, K.; ROMES, E.; Software Product Lines in Action: The BestIndustrial Practice in Product Line Engineering, Springer, New York, 2007[14] KÄSTNER, C. et al.: A Case Study Implementing Features using AspectJ. Proc. of Int’lSPL Conference (SPLC), 2007.[15] CONEJERO, J.,HERNANDEZ, J. Analysis of Crosscutting Features in Software ProductLines. International Conference on Software Engineering. Proceedings of the 13th internationalworkshop on Early Aspects. 2008.75

[16] BRAGA, R. T. V. et al, AIPLE-IS: An Approach To Develop Product Lines ForInformation Systems Using Aspects, SBCARS, 2007.[17] PACIOS, S. F.; MAESTRO, P. C.; BRAGA, R. T. V.: Guidelines for Using Aspects toEvolve Product Lines. In: III Workshop Brasileiro de Desenvolvimento de Software Orientado aAspectos, p.111-120 2006.[18] SPINCZYK, O; GAL, A; SCHRÖDER-PREIKSCHAT, W. AspectC++: an aspect-orientedextension to the C++ programming language. In: CRPIT '02: Proceedings of the FortiethInternational Conference on Tools Pacific. [S.l.]: Australian Computer Society, Inc. p.53-60,2002.[19] JOHNSON, R., J. HOELLER, et al.: Professional Java Development with the SpringFramework, Wrox, 2005[20] KANG, K, Feature-oriented domain analysis (FODA) - feasibility study. Technical ReportCMU/SEI-90-TR-21, SEI/CMU, 1990[21] UML - Unified Modeling Language. Disponível em: http://www.uml.org/. Acesso em:maio 2009.[22] MEZINI, M. and OSTERMANN, K.: Conquering Aspects with Caesar. Proc. of AOSD,pp. 90-99, Boston, USA, 2003.[23] HEO, S.; CHOI, E. M. Representation of Variability in Software Product Line UsingAspect-Oriented Programming, pp.66-73, Fourth International Conference on SoftwareEngineering Research, Management and Applications (SERA'06), 2006.[24] OCL - Object Management Group: UML 2.0 OCL Specification. Disponível em: Acesso em: abr 2009.[25] OAW 2 – openArchitectureWare -The leading platform for professional model-drivensoftware development http://www.openarchitectureware.org/. Acesso em: jun 2009[26] EMF - Eclipse Modeling Framework. Disponível em: http://eclipse.org/emf. Acesso em:jun 2009.[27] PathfinderMDA. Disponível em: .Acesso em: abr 2009.[28] C-SAW project. Disponível:http://www.grayarea.org/Research/C-SAW/. Acesso em: jun2009.[29] Fabro, M. Didonet del, Bézivin J. e Valduriez, P. ―Weaving Models with the EclipseAMW plugin‖, In Proceedings of the Eclipse Summit Europe (Eclipse Modeling Symposium),Esslingen, Alemanha, Out, 2006.76

[30] MOF - Object Management Group; Meta Object Facility (MOF) 2.0 CoreSpecification. Disponível em: .Acesso em: abr 2009.[31] Eclipse Galileo. Disponível em: http://download.eclipse.org/releases/galileo/. Acesso em:maio 2009.[32] Budinsky, Frank. Steinberg, David. Merks, Ed. Ellersick, Raymond. Grose, Timothy.Eclipse Modeling Framework. Addison Wesley Professional, 2003.[33] FONTANA, Márcio ; COSTA, Fabiano F. ; Ugo B. Sangiorgi ; BICHARA, Paulo A. D. ;GUIMARÃES, Diego ; LIMA, A. C. de C. . HiperionCAD: a CAD tool for design andoptimization of optical telecommunication. In: 10th International Conference on AdvancedCommunication Technology, 2008, Phoenix Park. 10th International Conference on AdvancedCommunication Technology. New Jersey : IEEE Technical Activities, 2008. v. 3. p. 2027-2032.[34] Accelo. Disponível em: http://www.acceleo.org/pages/download-acceleo-2-5-1/en. Acessoem: maio 2009.[35] ATL. ATLAS Transformation Language. Disponível em: http://www.eclipse.org/m2m/atl/.Acesso em: jun 2009.[36] Voelter, M.; Groher, I. Product Line Implementation using Aspect-Oriented and Model-Driven Software Development. Software Product Line Conference, 2007. SPLC 2007. 11ºInternational… Vol 10, Set 2007 p.233 – 242[37] Czarnecki K. e Antkiewicz M., ―Mapping features to models: A template approachbased on superimposed variants‖, In Proceedings of the 4th International Conference onGenerative Programming and Component Engineering (GPCE), Tallinn, Estonia, Set 2005p 422 - 437, Springer, 2005.[38] Sánchez, Pablo; Loughran, Neil; Fuentes, Lidia; Garcia, Alessandro. EngineeringLanguages for Specifying Product-Derivation Processes in Software Product Lines. SLE 2008:188-207[39] XMI - Object Management Group: XML Metadata Interchange (XMI) Specification.Disponível em: . Acessado em:abr 2009.[40] SCHMIDT, D, Model-Driven Engineering. IEEE Computer 39(2): 25-31, 2006.[41] Taentzer, G.: AGG: A Graph Transformation Environment for Modeling and Validation ofSoftware. In Pfaltz, J.L., Nagl, M., B¨ohlen, B., eds.: Proc. of the 2nd Int. Workshop on77

Applications of Graph Transformations with Industrial Relevance (AGTIVE). Volume 3062 ofLNCS., Charlottesville, (Virginia, USA) (September- October 2003) 446–453.[42] XPath - World Wide Web Consortium: XML Path Language 2.0. (2005) http://www.w3.org/TR/xpath20/. Acesso em: jun 2009.[43] Czarnecki K., Helsen S., e Eisenecker U. W. Staged Configuration Using Feature Models.In Third International Software Product Lines Conference Software Product Lines (SPLC2004), volume 3154 of LNCS, p. 266–283, 2004.[44] Beuche, D.: Variant Management with pure::variants. Technical report, pure-systemsGmbH, 2003.[45] Charles W. Krueger: BigLever Software Gears and the 3-tiered SPL Methodology. In:Companion to the 22nd Int. Conference on Object-Oriented Programming, Systems, Languages,and Applications (OOPSLA), Montreal (Quebec, Canada), Out, 2007. p. 844–845.[46] MTL - French National Institute for Research in Computer Science and Control (INRIA):Model Transformation Language (MTL). Disponível em:http://modelware.inria.fr/rubrique4.html. Acesso: jun 2009.[47] OAW open Architecture Ware. Disponível em: http://www.eclipse.org/gmt/oaw/. Acessoem: jun 2009.[48] Loughran, N., S´anchez, P., Garcia, A., Fuentes, L.: Language Support for ManagingVariability in Architectural Models. In Pautasso, C., Tanter, ´ E., eds.: Proc. Of the 7th Int.Symposium on Software Composition (SC). Volume 4954 of LNCS., Budapest (Hungary)(March 2008) 36–51.[49] Booch, G; Rumbaugh, J & Jacobson, I. 2000. ―UML Guia do Usuário‖. Editora Campus.[50] Cyment, A., Kicillof, N., Altman, R., Asteasuain, F.:Improving AOP Systems’ Evolvabilityby Decoupling Advices from Base Code. In: RAM-SE’06-ECOOP’06 Workshop on Reflection,AOP, and Meta-Data for Software Evolution. (2006) 9–21.[51] CIRILO, E.; KULESZA, U.; LUCENA, C.: A Product Derivation Tool Based on Model-Driven Techniques and Annotations. Journal of Universal Computer Science, vol. 14, No 8.2008.78

PARTE IIA parte II deste documento tem como propósito definir o processo de avaliação darefatoração do GingaCC. A versão original do GingaCC orientada a objetos e sua versãoorientada a aspectos serão comparadas através do uso de métricas associadas a propriedadesrelevantes ao contexto de sistemas de middleware. O intuito da avaliação é verificar quaisforam os possíveis benefícios e prejuízos resultantes da refatoração do sistema usando aabordagem de desenvolvimento de software orientado a aspectos.Nesta parte do entregável, o processo de Avaliação e parte dos resultados coletados naversão orientada a objetos do GingaCC serão apresentados. Como ainda não foram definidostodos os conceitos transversais do sistema nem sua versão refatorada, o restante dos resultadosdas métricas será apresentado nos próximos entregáveis.5 IntroduçãoSegundo Fenton [7], medição é o processo através do qual números ou símbolossão designados a atributos de entidades do mundo real de forma que as descrevam deacordo com regras bem definidas. Uma entidade pode ser um objeto, uma pessoa ouuma especificação de software. Um atributo é uma propriedade da entidade, comotamanho ou funcionalidade. A atribuição numérica deve obedecer a observaçõesintuitivas ou empíricas.No contexto deste trabalho, a entidade a ser medida é a arquitetura do GingaCommon-Core (GingaCC) e um produto da linha de produto de software (LPS)GingaForAll. O foco da avaliação é a refatoração da arquitetura do GingaCC emaspectos. Para realizar essa avaliação, definem-se atributos de qualidade relevantes aoprocesso de refatoração. Esses atributos serão avaliados através do uso de métricas paradefinir a avaliação em termos objetivos. Uma vez aplicadas as métricas ao GingaCC e aum produto do GingaForAll, pode-se comparar resultados para levantar possíveisbenefícios e prejuízos advindos da utilização da abordagem de aspectos. A avaliaçãoocorre, portanto, através da comparação entre as duas abordagens – Orientada a Objetos(OO) e Orientada a Aspectos (OA) – para um mesmo sistema. Por esse motivo, as79

versões comparadas devem ser similares, o que justifica a escolha de um produto daLPS o mais próximo possível da arquitetura original do GingaCC. No caso a versão OOé o GingaCC e a versão OA é a produzida pelo GingaForAll.O objetivo apresentado no parágrafo anterior está em desenvolvimento e seráapresentado parcialmente em mais de um entregável. Nesse entregável, será mostradauma avaliação do acoplamento do GingaCC realizada através da medição dessapropriedade usando métricas de acoplamento coletadas no código-fonte. Além deresultados, levantamos as principais fontes de acoplamento para cada entidade dosistema e, a partir disso, sugerimos possíveis conceitos transversais implementadospelas entidades que mais são fontes de acoplamento.O restante dessa seção é destinado à apresentação de uma visão geral daavaliação do GingaCC. A Seção 6 descreve o sistema de avaliação selecionado pararealizar a avaliação. A Seção 7 apresenta as tarefas que compõem a realização daavaliação do GingaCC. A apresentação dos resultados obtidos para a medição utilizandométricas de acoplamento para implementação está na Seção 8. A Seção 9 traz umadiscussão dos resultados obtidos até o momento.5.1 Visão Geral da Avaliação do Ginga CCEsta Seção descreve o estudo realizado cujo objetivo é avaliar os possíveis benefícios eprejuízos advindos da refatoração OA (orientada a aspectos) que está sendo aplicada ao GingaCC. Para realizar essa análise deve-se coletar um conjunto de métricas arquiteturais e deimplementação nas suas versões OO (orientada a objetos) e OA (orientada a aspectos) doGingaCC. A Figura 24 apresenta o diagrama de atividades que ilustra a seqüência de passos aserem realizados nesta avaliação. É importante ressaltar que o processo de avaliação ainda nãoestá finalizado, pois a versão OA do GingaCC está em elaboração.80

Figura 24: Visão geral do processo de avaliação do GingaCCInicialmente, coletamos métricas específicas para avaliação de refatoração na versãoOO do GingaCC. Com o intuito de avaliar o sistema da forma mais completa possível, asmétricas serão aplicadas primeiramente na arquitetura do sistema e, em seguida, à suaimplementação. Uma vez que a versão OA do GingaCC esteja concluída, coletamos as mesmasmétricas na arquitetura e implementação da versão OA do GingaCC. Com os dados das duasversões do mesmo sistema, passa-se à etapa de análise comparativa dos resultados e avaliaçãodas propriedades do sistema associadas às métricas. Finaliza-se, nesse ponto, a avaliaçãoestática do sistema.A última etapa refere-se à avaliação dinâmica do sistema, que consiste na avaliação dodesempenho das duas versões do GingaCC. Ela é necessária para analisar o impacto darefatoração no desempenho e consumo de memória do sistema. Depois de realizadas todas asetapas, o processo de avaliação está concluído.6 Sistema de AvaliaçãoPara avaliar a refatoração do sistema GingaCC, adotamos o sistema de avaliação baseadoem métricas proposto por Freitas [2]. Esse sistema foi selecionado por apresentar um conjuntode métricas associadas a propriedades relevantes ao contexto de sistemas de middleware.81

Apresenta-se, nas Figuras 2 e 3, o subconjunto referente à avaliação de refatoração de sistemas,ou seja, a parte que interessa no contexto deste trabalho.A Figura 25 apresenta o conjunto de métricas para avaliação estática do sistema.Segundo [2], na avaliação de refatoração, as propriedades do sistema a serem analisadas sãomodularidade e tamanho. As métricas de modularidade visam avaliar se a utilização de DSOA(Desenvolvimento de Software Orientado a Aspectos) realmente resultou na melhoria damodularidade do sistema. As métricas de tamanho objetivam analisar se a definição de aspectosnão aumentou de forma significativa o tamanho do sistema.No sistema de avaliação que adotamos, baseado em [2], a propriedade modularidadeestá associada aos atributos acoplamento, coesão e separação de interesses. A cada um dessesatributos está associada uma lista de métricas responsáveis por mensurá-los. A Tabela 4apresenta as métricas para acoplamento entidade-entidade, ou seja, acoplamento que ocorreentre qualquer par de entidades do sistema. De acordo com a terminologia adotada no trabalho,entidade refere-se a aspectos e classes e operação nomeia métodos e advices. A Tabela 5apresenta a métrica para coesão e a Tabela 6 descreve as métricas para separação de conceitos.Figura 25: conjunto de métricas – parte de avaliação estática.Tabela 4: Métricas arquiteturais de acoplamento entidade-entidade.MétricaDefiniçãoCBO (Coupling Between Número de entidades às quais uma entidade está acoplada. Uma82

Objects Classes)MPC (Messaging PassingCoupling)DAC (Data AbstractionCoupling)entidade está acoplada a outra se usa variáveis ou operações de outraentidade.Para uma entidade, número de invocações estáticas a operações nãoimplementadas nessa entidade.Número de atributos não herdados que têm uma entidade como seutipo.Tabela 5: Métrica arquitetural de coesão.MétricaLCC (Lack of Concern-basedCohesion)DefiniçãoNúmero de conceitos implementados por uma dada entidade.Tabela 6: Métricas arquiteturais de separação de conceitos.MétricaCDC (Concern Diffusion overComponentes)CDO (Concern Diffusion overOperations)CDLOC (Concern Diffusionover Lines of Code)DefiniçãoNúmero de entidade cujo principal propósito é contribuir para aimplementação de um conceito.Número de operações cujo principal propósito é contribuir para aimplementação de um conceito.Número de pontos de transição para cada conceito em todas aslinhas de código do sistema.Em relação a tamanho, a Tabela 7 apresenta as métricas propostas em [2] para aavaliação dessa propriedade. A partir dessas métricas, é possível comparar as duas soluções demiddleware, a original e a refatorada, em relação ao tamanho do sistema.Tabela 7: Métricas arquiteturais de tamanho.MétricasVS (Vocabulary Size)DefiniçãoNúmero de entidades do sistema83

NOA (Number of Attributes)WOC (Weighted Operations perComponent)LOC (Lines of Code)Número de atributos de uma entidadeSoma da complexidade de cada operação de uma entidade. Acomplexidade de uma operação é determinada pelo númerode parâmetros.Número de linhas de código do sistema.Terminada a parte de análise estática, inicia-se a avaliação dinâmica. A Figura 26mostra o subconjunto de métricas de [2] relevantes para a avaliação da refatoração. Nessa etapa,considera-se o tempo de execução dos dois sistemas de forma a analisar se a utilização deaspectos resultou em overhead aceitável ou não e também o consumo de memória, pois hárestrição desse recurso para que o sistema execute nas plataformas-alvo que tem restrição emtermos de memória.Figura 26: Conjunto de métricas – parte de avaliação dinâmica.7 Tarefas no Contexto desse ProjetoUma vez definido o processo de avaliação a ser utilizado (Seção 5) e o sistema deavaliação (Seção 6), descrevemos, nesta seção, as tarefas a serem realizadas para a realização daavaliação da refatoração do GingaCC deste projeto.84

Tarefa 1 -- coleta de métricas de acoplamento na arquitetura da versão OO: osresultados obtidos para essa tarefa foram apresentados no segundo entregável [3], assim comoos detalhes da coleta dessas métricas. Somente a métrica DAC pode ser coletada na arquiteturado GingaCC (representada em UML) e o seu resultado para a maioria das entidades foi zero.Consideramos que tais resultados não foram suficientes para avaliação do acoplamento, pois,além de serem fornecidos apenas sob a perspectiva de DAC, os resultados poderiam indicar quenão havia acoplamento para a maioria das classes ou que simplesmente as métricas nãoconseguiram capturar informações dado o nível de abstração de definição da arquitetura dosistema.Tarefa 2 – coleta de métricas de tamanho na arquitetura da versão OO: assim como atarefa 1, a tarefa 2 foi apresentada no segundo entregável [3]. Ao contrário dos resultados datarefa 1, as métricas de tamanho forneceram dados importantes sobre o tamanho do sistema,pois os resultados da medição através de VS, WOC e NOA não foram alterados pelo nível deabstração da arquitetura nos quais foram coletados. Esses valores seriam os mesmos casofossem coletados na implementação do sistema.Tarefa 3 – coleta de métricas na arquitetura de separação de conceitos e coesão naversão OO: envolve a coleta de resultados para as métricas de separação de conceitos CDC eCDO e de coesão LCC. Antes que essa tarefa seja realizada, os conceitos transversais a seremconsiderados na refatoração já devem estar definidos, pois servem de entrada na coleta dessasmétricas. Como nem todos os conceitos transversais estão definidos ainda, essa tarefa seráapresentada nos próximos entregáveis.Tarefa 4 – coleta de métricas de acoplamento na implementação da versão OO:decidimos por coletar as métricas de acoplamento da Tabela 6 na implementação do sistema,porque os resultados obtidos na tarefa 1 sobre acoplamento não foram suficientes para avaliar arefatoração. Como comentamos anteriormente, os valores zero para as métricas poderiamindicar que não havia acoplamento na maioria das classes do sistema ou que o nível deabstração de definição da arquitetura impossibilitava a identificação do acoplamento. Asmétricas coletadas nesta tarefa são CBO, DAC e MPC. Esses resultados serão apresentadosneste entregável, na Seção 4. A saída dessa tarefa também visa levantar possíveis conceitostransversais que servem de entrada para a refatoração do GingaCC em aspectos.Tarefa 5 – coleta da métrica de tamanho na implementação da versão OO: nessa tarefa,coleta-se a métrica LOC: a única métrica de tamanho que não pode ser coletada na arquiteturado GingaCC. Essa métrica fornece informações sobre o tamanho do sistema com base nonúmero de linhas de código. Os seus resultados serão apresentados neste entregável, na Seção 5.85

Tarefa 6 – coleta de métricas de separação de conceitos e coesão na implementação daversão OO: envolve a coleta de resultados para as métricas de separação de interesses CDC,CDO e CDLOC e de coesão LCC. Antes que essa tarefa seja realizada, os conceitos transversaisa serem considerados na refatoração já devem estar definidos. Eles servem de entrada na coletadessas métricas.Tarefa 7 – coleta das métricas de acoplamento na arquitetura da versão OA: coleta dasmesmas métricas de acoplamento da tarefa 1, mas na versão OA do GingaCC.Tarefa 8 – coleta das métricas de tamanho na arquitetura da versão OA: coleta dasmesmas métricas de tamanho da tarefa 2 na versão OA do GingaCC.Tarefa 9 – coleta das métricas de separação de conceitos e coesão na arquitetura daversão OA: coleta das métricas especificadas na tarefa 3 na versão OA do GingaCC.Tarefa 10 -- coleta das métricas de acoplamento da implementação da versão OA:coleta das mesmas métricas de acoplamento da tarefa 4, mas na versão OA do GingaCC.Tarefa 11 -- coleta das métricas de tamanho na implementação da versão OA: coletadas métricas VS, WOC, NOA e LOC na versão OA do GingaCC.Tarefa 12 -- coletas das métricas de separação de conceitos e coesão na implementaçãoda versão OA: coleta das mesmas métricas de acoplamento da tarefa 6 na versão OA doGingaCC.Tarefa 13 – análise comparativa: comparação dos resultados das versões OO e OA doGingaCC. Avaliação das propriedades modularidade e tamanho associadas às métricascoletadas.Tarefa 14 – análise do desempenho e do consumo de memória: comparação dos temposde execução e de consumo de memória das versões OO e OA do GingaCC para avaliação doimpacto do uso de aspectos nesse sistema.As tarefas 3 e 6 a 14 serão apresentadas nos próximos entregáveis conforme se definamos conceitos transversais e a versão OA do GingaCC torne-se disponível. A Figura 27 apresentaa relação entre o processo de avaliação e as tarefas definidas, detalhando as atividades genéricasda Figura 24.86

Figura 27: Detalhamento dos processos genéricos de avaliação.8 Métricas de Acomplamento paraImplementaçãoAs métricas coletadas na implementação do sistema fornecem informações maisdetalhadas sobre o sistema em comparação com a coleta na arquitetura do sistema. Isso porque aestrutura concisa da definição de arquitetura faz com que os resultados da medição, muitasvezes, não sejam suficientes para avaliação de algumas propriedades do sistema, como coesão eacoplamento.Conforme comentados na Seção 5, embora o processo de avaliação seja mais detalhadose aplicarmos as métricas na implementação do sistema, seria interessante realizá-lo naarquitetura do sistema de forma a poupar tempo e esforço, uma vez que não é necessário87

analisar detalhes do seu código-fonte, mas analisar apenas os diagramas de classes em UML. Orisco dessa abordagem é que as informações obtidas na arquitetura podem não ser suficientespara avaliação de todas as propriedades do sistema. Esse é o motivo pelo qual a avaliação doGingaCC iniciou-se na arquitetura do sistema. No entanto, para se ter a avaliação completa ecomplementar os resultados obtidos no nível arquitetural, também realizamos avaliação docódigo propriamente dito do middleware.Com o intuito de obter mais informações sobre o acoplamento do sistema e, assim,melhor avaliá-lo, todas as métricas da Tabela 4 foram coletadas na implementação no GingaCC.Espera-se obter as seguintes informações com cada uma dessas métricas:(i) DAC: a coleta de DAC na arquitetura do sistema considera apenas atributos daentidade sendo avaliada cujo tipo seja referente à outra entidade definida no sistema definida nosistema. Em termos de implementação, será possível coletar atributos definidos dentro dasoperações da entidade sendo avaliada;(ii) CBO: a coleta de CBO fornece o número de outras entidades às quais umadeterminada entidade está acoplada. A partir desse valor é possível afirmar se uma entidade é ounão dependente de outras entidades do sistema e, se sim, quantas são elas;(iii) MPC: a coleta da métrica MPC considera, para uma entidade, cada invocação aoperações de outras entidades definidas no sistema. Ela fornece a freqüência do acoplamentoentre as entidades. Comparando as métricas CBO e MPC, para uma entidade, a aplicação damétrica CBO fornece o número de outras entidades em relação às quais ela apresentadependência; a aplicação da métrica MPC fornece a freqüência ou intensidade dessadependência;O processo de coleta das métricas descritas na Tabela 4 foi realizado manualmente, pornão haver disponibilidade de uma ferramenta para coleta na linguagem de programação C++,que é a utilizada para a implementação do GincaCC. Por ser repetitivo e detalhista, o processode coleta é lento e propenso a erros. Em contrapartida, um ponto bastante positivo dessa formade realizar o processo é determinar não apenas a quantas entidades uma entidade está acoplada(resultados da medição), mas também nomear/identificar quais entidades estão participando darelação de acoplamento.Uma vez que se obtenham, além dos valores das métricas de acoplamento, as entidadesque participam do acoplamento, é possível apontar alguns possíveis conceitos transversais parao processo de refatoração do GingaCC. Se uma entidade está acoplada a diversas entidades dosistema, possivelmente ela (ou parte dela), implementa um conceito que entrecorta todo o88

sistema (conceito transversal). Embora essas informações não sejam suficientes para adeterminação de conceitos transversais, elas auxiliam nesse processo.Uma vez selecionados os conceitos transversais para o sistema, as métricas de separaçãode conceitos (a serem apresentadas em uma outra seção) podem quantificar o entrelaçamento decada conceito ao restante do código. Isso pode confirmar e reforçar a definição desse conceitocomo transversal ao sistema.O restante desta seção destina-se a apresentar os valores da medição na implementaçãoatravés das métricas de acoplamento expostas na Tabela 4. A apresentação está dividida porpacotes do sistema. Lembrando que no contexto desse trabalho, o termo entidade nomeia classee aspecto e o termo operações nomeia métodos e advices.8.1 Pacote GingaCC-PlayerPara cada entidade, ou seja, classe declarada dentro do pacote gingacc-player, a Tabela8 apresenta os resultados para a medição realizada a partir das métricas de acoplamento CBO,MPC e DAC na implementação do sistema. A quarta coluna dessa Tabela fornece informaçõessobre o acoplamento encontrado em cada entidade, nomeando as outras entidades com as quaisocorre o acoplamento e a forma como ele ocorre.Tabela 8: Resultados para as métricas CBO, MPC e DAC e a forma como o acoplamento ocorrenas entidades de gingacc-player.Entidade CBO MPC DAC Acoplada às entidadesAnimePlayer 1 6 0 Thread, por herançaAVPlayer 2 27 0 Thread e Player, por herançaButtonPlayer 6 35 3 Player e Thread, por herança; Window,ImagePlayer e Surface, por declaração deatributo com tipo dessa classe; OutputManager,por invocação a métodoChannelPlayer 1 6 0 Player, por herançaImagePlayer 1 4 0 Player, por herançaESPlayer 1 1 0 Player, por herança89

Player 1 1 0 Thread, por invocação a métodoLinksPlayer 2 5 0 Thread e Player, por herançaLuaPlayer 2 21 0 Thread e Player, por herançaPlainTxtPlayer 2 5 0 TextPlayer, por herança; Player, por invocaçãoa métodoTextPlayer 1 1 0 Player, por herançaPlayerListener 0 0 0ProgramAV 0 0 0ShowButton 2 19 1 Thread, por herança; ImagePlayer, porinvocação a método e declaração de atributocom tipo dessa classeSrtPlayer 4 31 1 Thread, TextPlayer e Player, por herança;Color, por declaração de atributo com tipodessa classe.O pacote gingacc-player contém classes para implementação de diversos tipos deplayers. A classe Player define operações básicas, como play(), stop(), pause() e resume(), aserem implementadas pelos players. Por isso, a maioria das classes do gingacc-player herdamde Player. Além disso, Player define também a lista de listeners para um player, ou seja, a listacom os objetos que estão interessados na execução de um determinado player. Além de Player,a maioria das classes de gingacc-player herdam também da classe Thread. A execução dosplayers ocorre através do fluxo de threads e, assim, as demais classes usam os comandos decontrole de threads definidos nessa classe. Há ainda o uso de comandos de exclusão mútua,lock() e unlock() definidos em Thread, para acesso a elementos gráficos como Surface eWindow que necessitam de sincronização.Em relação aos resultados obtidos para CBO, podemos dizer que a maior parte dasentidades do pacote gingacc_player possuem baixo acoplamento a outras entidades. Apenas asentidades ButtonPlayer e SrtPlayer apresentam um valor para CBO um pouco mais elevado. Aclasse ButtonPlayer implementa o desenho de um botão na tela. O botão é definido como umainstância de Window. Declara-se uma instância de Surface e associa-se uma imagem a essainstância através da invocação de um método da classe ImagePlayer. A instância de Surface é90

então atribuída a Window. No construtor de Window, OutputManager é chamado para fornecercomo retorno uma instância de Window. Por isso, ButtonPlayer além de estar acoplada àsclasses Player e Thread por herança, ainda possui acoplamento às classes Window, Surface,ImagePlayer, OutputManager. A classe SrtPlayer é responsável por sincronizar a apresentaçãode legendas. Ela herda de TextPlayer, por ser esta classe que desenha o texto em Window.Declara-se uma instância da classe Color para definir a cor da fonte da legenda. Logo, SrtPlayerapresenta acoplamento a Thread e Player, por herança, e a Color, por definição de tipo deatributo.Quanto à MPC, há várias entidades com valores elevados para essa métrica. Comomencionado anteriormente, a maioria das classes do pacote gingacc_player herdam das classesThread e Player e as invocações a seus métodos são o fator que mais contribui para os altosvalores de MPC. Isso significa que podem ser considerados candidatos a conceitos entrelaçados.A Tabela 9 mostra um comparativo entre os resultados obtidos para a métrica DAC naarquitetura e na implementação do sistema. Enquanto na arquitetura não havia nenhum atributode entidade definido com tipo de outra entidade do sistema, na implementação foramencontrados alguns atributos definidos dessa forma. Isso ocorre porque esses atributos estavamdefinidos dentro de operações das entidades. A quarta coluna da Tabela 9 cita, por entidade, asentidades com as quais ocorre acoplamento por DAC.Tabela 9: Comparativo dos resultados para a métrica DAC na arquitetura e na implementaçãodo pacote gingacc-player.EntidadeDAC - nívelDAC – nível deAcoplada às entidadesarquiteturalimplementaçãoAnimePlayer 0 0AVPlayer 0 0ButtonPlayer 0 3 Window, ImagePlayer eSurfaceChannelPlayer 0 0ImagePlayer 0 0ESPlayer 0 091

Player 0 0LinksPlayer 0 0LuaPlayer 0 0PlainTxtPlayer 0 0TextPlayer 0 0PlayerListener 0 0ProgramAV 0 0ShowButton 0 1 ImagePlayerSrtPlayer 0 1 ColorA maioria das classes do pacote gingacc-player apresenta baixo acoplamento de acordocom os resultados das métricas. Em relação ao acoplamento por DAC, os valores são ainda maisbaixos. A explicação para esse fato está no uso de interfaces, pois as métricas não consideramacoplamento a interfaces do sistema, apenas a classes e aspectos. Como exemplo, consideremosas classes Window e ComponentManager. Embora quase todas as classes do pacote façamreferência a essas duas, o acesso às mesmas é feito através de suas interfaces, o que nãocontribui para os valores obtidos para as métricas. Mesmo não constituindo acoplamentocapturado pelas métricas, seria interessante analisar a possibilidade de elementos gráficos (porexemplo, entidades Window e Button) e o gerenciamento de componentes (entidadeComponentManager) serem avaliados como possíveis conceitos transversais.O acoplamento em todo o GingaCC, não somente no gingacc-player, é diminuído pelouso extensivo de interfaces. Essa característica representa uma vantagem no que diz respeito atal atributo do sistema. Ao invés de invocar uma operação em uma classe, o que constituiriaacoplamento, o código do GingaCC invoca operações em uma interface.A Tabela 10 apresenta a relação entre entidades e conceitos transversais para facilitarsua visualização. É possível observar que o acoplamento entre as entidades do pacote gingaccplayere os conceitos Thread e Player é observado com freqüência.Tabela 10: Relação entre as entidades do pacote gingacc-player e os conceitos transversais aosquais apresentam acoplamento.92

Entidade\ ConceitoThread PlayerTransversalAnimePlayerXAVPlayer X XButtonPlayer X XChannelPlayerXImagePlayerXESPlayerXPlayerXLinksPlayer X XLuaPlayer X XPlainTxtPlayerXTextPlayerXPlayerListener X XProgramAVShowButtonXSrtPlayer X X8.2 Pacote gingacc-contextmanagerA Tabela 11 apresenta os resultados da medição para o pacote gingacc-contextmanager.Esse pacote, como o nome sugere, é responsável por manter informações sobre o contexto dosistema. Como exemplo, podemos citar informações sobre o usuário e dados sobre o sistema,tais como a linguagem que está sendo utilizada e o tamanho da tela.Tabela 11: resultados para as métricas CBO, MPC e DAC e a forma como oacoplamento ocorre nas entidades de gingacc-contextmanager.Entidade CBO MPC DAC Acoplada às entidadesContextManager 1 14 0 GingaUserGingaUser 0 0 0SystemInfo 0 0 0A entidade ContextManager é responsável por salvar informações de contexto sobreusuários, o que é realizado por meio de uma invocação a uma operação da entidade GingaUser.Esse procedimento contribui para o valor de MPC dessa entidade. Mesmo o valor de MPC nãosendo tão elevado, o processo de salvar informações de contexto poderia ser um conceitotransversal e, por conseguinte, ser definido como um aspecto.93

A entidade GingaUser fornece funcionalidades básicas para tratamento de dados deusuários como nome e senha. Ela é responsável por armazenar esses dados em um arquivo. Porisso, não apresenta acoplamento a outras entidades do sistema.A entidade SystemInfo trata informações básicas sobre o sistema como linguagem dosistema, linguagem da legenda e consumo de memória. Assim, como GingaUser não apresentaacoplamento a outras entidades do sistema.8.3 Pacote Gingacc-icA Tabela 12 apresenta os resultados da medição no pacote gingacc-ic. É tarefa dessepacote é tratar as conexões com o canal interativo. As entidades InteractiveChannelManager eCurlInteractiveChannel não apresentam acoplamento a outras entidades do sistema.Tabela 12: resultados para as métricas CBO, MPC e DAC e a forma como o acoplamento ocorrenas entidades de gingacc-ic.Entidade CBO MPC DAC Acoplada às entidadesInteractiveChannelManager 0 0 0CurlInteractiveChannel 0 0 0A entidade InteractiveChannelManager mantém uma lista com referências a canais deinteratividade e fornece operações para gerenciamento como criar e liberar canais. A entidadeCurlInteractiveChannel implementa um canal de interatividade usando a biblioteca cURL [9]para transferência de arquivos com sintaxe URL. Para realizar suas funcionalidades, essasentidades não utilizam serviços de outras entidades do sistema, então não há acoplamento.Como a biblioteca cURL não faz parte do sistema em avaliação, o acoplamento a ela nãocontribui para os valores das métricas.8.4 Pacote Gingacc-cmA Tabela 13 apresenta os resultados para a medição realizada no pacote gingacc-cm. Afunção das entidades desse pacote é manter informações sobre componentes: como nome,dependência, gerenciamento e descrição. Para realizar essa função, as entidades não precisam94

obter informações de outras entidades do sistema. Logo, não apresentam acoplamento a outrasentidades do sistema.Tabela 13: resultados para as métricas CBO, MPC e DAC e a forma como oacoplamento ocorre nas entidades de gingacc-cm.Entidade CBO MPC DAC Acoplada às entidadesComponentManager 0 0 0Component 0 0 0ComponentDescription 0 0 0ComponentParser 0 0 0A entidade ComponentManager mantém uma lista com referências a componentes esuas dependências. Como a referência a componentes é feita através da interface IComponent,não há acoplamento nessa entidade.A entidade Component mantém informações em seus atributos sobre um componentecomo nome, versão, tipo e dependências. As operações dessa classe definem apenas o acesso aesses atributos. Por isso não há acoplamento nessa entidade.A entidade ComponentDescriptor mantém uma lista de referências a componentes e suaprincipal operação é criar um arquivo XML com a descrição desses componentes. A entidadeComponentParser faz o processo inverso: recebe um arquivo XML e retira as descrições decomponentes dele. Para realizar essas tarefas, essas entidades não precisam requisitar serviçosde outras entidades do sistema. Assim, não há acoplamento.Embora as entidades deste pacote apresentem acoplamento as bibliotecas da linguagemde programação, não há acoplamento entre estas entidades e outras entidades do GingaCC.Outras entidades do sistema usam os serviços providos por estas entidades, mas isso não érefletido nos resultados para estas entidades e sim nos resultados das entidades que usam osserviços.8.5 gingacc-umA Tabela 14 apresenta os resultados da medição realizada no pacote gingacc-um: pacoteresponsável por gerenciar atualizações de componentes. A única entidade desse pacote nãoapresenta acoplamento a outras entidades do sistema.95

Tabela 14: resultados para as métricas CBO, MPC e DAC e a forma como oacoplamento ocorre nas entidades de gingacc-um.Entidade CBO MPC DAC Acoplada às entidadesUpdate 0 0 0A entidade Update realiza a atualização de componentes. Permite que se adicione ouremova interessados (listeners) na atualização. Não apresenta acoplamento porque não usaserviços de outras entidades do sistema para realizar sua funcionalidade.8.6 Pacote gingacc-dataprocessingAntes de apresentar os resultados para a medição realizada no pacote gingaccdataprocessing,são apresentados alguns conceitos básicos sobre o Ginga-NCL, de forma aservir de base para posterior análise do acoplamento presente nesse pacote.O Ginga-NCL utiliza como protocolo de transmissão cíclica de dados de uma aplicaçãointerativa o carrossel de objetos DSM-CC (Digital Storage Media – Command and Control). Osdados são representados por objetos – objeto de diretório, objeto de arquivo e objeto de ServiceGateway – que contêm atributos – nome, tipo e, possivelmente, conteúdo. Cada objeto deve serencapsulado em uma mensagem BIOP (Broadcast Inter ORB Protocol) a ser transmitida emmódulos. Uma mensagem BIOP deve ser transmitida em um único módulo, mas um módulopode conter mais de uma mensagem. Os módulos, por sua vez, são divididos em blocos dedados, que são encapsulados em mensagens denominadas DDB ou DownloadDataBlock. Porfim, os blocos de dados são encapsulados em seções DSM-CC[1] .Cada instância de carrossel de objetos é representada por um Service Domain , queconsiste em uma identificação única do carrossel de objetos. Todo Service Domain possui umService Gateway, que contém referências para todos os objetos dispostos na raiz do carrossel deobjetos. O padrão DSM-CC utiliza a estrutura de referências IOR (Interoperable ObjectReference), definidas nas especificações CORBA. No contexto do protocolo carrossel deobjetos, uma IOR é normalmente composta pelo identificador do carrossel, seguido doidentificador do módulo e pelo identificador do objeto. O Service Gateway é um objeto docarrossel de objetos cuja localização é transmitida em uma mensagem DownloadServerInitiate[1]. A Tabela 18 apresenta o resultado para a medição realizada no pacote gingaccdataprocessing.96

Tabela 15: resultados para as métricas CBO, MPC e DAC e a forma como oacoplamento ocorre nas entidades de gingacc-dataprocessing.Entidade CBO MPC DAC Acoplada às entidadesBinding 0 0 1 Atributo com tipo de IorBiop 5 50 11 Module, Object, ObjectProcessor,Binding, IorIor 0 0 0ObjectProcessor 3 40 2 Binding, Ior e ObjectObject 0 0 1 BindingServiceDomain 8 28 5 Module, Biop, Ior, ObjectProcessor,DownloadServerInitiate,DownloadInfoIndication,DownloadDataBlock, ThreadStreamEvent 0 0 0DownloadDataBlock 2 5 2 Module, DsmccMessageHeaderDsmccMessageReader 0 0 0DownloadInfoIndication 2 12 4 Module, DsmccMessageHeaderDownloadServerInitiate 2 9 2 Ior, DsmccMessageHeaderMessageProcessor 5 2 5 ServiceDomain,DownloadServerInitiate,DownloadDataBlock,DownloadInfoIndication,DsmccMessageHeaderModule 0 0 0EPGProcessor 0 0 0TransportSection 0 0 0FilterManager 1 2 5 SectionFilterSectionFilter 0 0 0A entidade Binding guarda informações sobre um objeto, como tipo e identificador.Dessa forma, a sua implementação consiste basicamente em um conjunto de operações get e setpara essas informações, não apresentando, portanto, valores consideráveis de acoplamento aoutras entidades. A única fonte de acoplamento é a definição de um atributo do tipo da entidadeIor, para associar essas informações à dados sobre localização do objeto em relação ao carrossele ao módulo.97

A entidade Biop apresenta valores consideráveis para as métricas de acoplamento. Poresse motivo, será analisada em mais detalhes a seguir. Biop declara um atributo do tipo daentidade Module para armazenar módulos do carrossel de objetos e informações sobre essemódulo. Ela recebe como parâmetro em seu construtor uma instância de Module a serprocessada. Dessa forma, são realizadas diversas invocações a operações da entidade Modulepara obter informações sobre a instância. O que contribui significativamente para o valor finalde MPC.Para processar a estrutura de diretórios, Biop define instâncias da entidade Object,contribuindo para o valor de DAC. Além disso, são realizadas diversas chamadas a operações daclasse Object para passar informações, contribuindo consideravelmente para o valor final deMPC. Essa entidade ainda define uma instância da entidade Ior para armazenar informações dalocalização do objeto em relação ao carrossel e ao módulo. É também fonte de acoplamento adeclaração de instâncias da entidade Binding para ter acesso a informações sobre o objeto comotipo, identificador e informações. Há acoplamento também à entidade ObjectProcessor atravésda definição de um atributo desse tipo. A entidade ObjectProcessor associa objetos aos seusinteressados (listeners) e notifica-os sobre objetos. A partir da instância desta entidade, cadaobjeto processado na entidade Biop é submetido ao ObjectProcessor para notificação de seusinteressados.Na entidade Biop, o acoplamento às entidades Module, Object e Binding é o que maiscontribui para elevar os valores registrados pelas métricas. Por isso, seria interessante verificarse essas entidades implementam conceitos transversais.A entidade Ior não apresenta acoplamento a outras entidades do sistema. Essa entidade,como dito anteriormente, armazena informações sobre localização de um objeto em relação aocarrossel e ao módulo em que está contido. Por isso, sua implementação consiste em operaçõesget e set sobre seus atributos.A entidade ObjectProcessor está acoplada às entidades Ior, Binding e Object. Essaentidade, como mencionado anteriormente, envia notificações sobre um objeto a uma lista deinteressados. Além disso, há uma operação para ―montar‖ um objeto de acordo com seu tipo: aimplementação verifica se o objeto é um Service Gateway, diretório ou arquivo. Se for umService Gateway, armazena-se a raiz da árvore de diretórios do carrossel; caso seja um diretório,cria-se um diretório respeitando a estrutura de diretórios existente e, se for um arquivo, ele éarmazenado no diretório especificado. Para realizar essas atividades, a entidadeObjectProcessor precisa obter informações das entidades Binding e Object principalmenteatravés de invocações a operações dessas duas classes. O que resulta em um resultado98

consideravelmente elevado para MPC. Assim como na entidade Biop, o acoplamento a Bindinge Object pode ser um indício de que estas entidades definem conceitos transversais.A entidade Object define um atributo cujo tipo é a entidade Binding para guardarinformações sobre objetos. Essa é a única fonte de acoplamento presente na entidade.A entidade ServiceDomain contém referências para todos os objetos dispostos na raizdo carrossel de objetos. Essa entidade processa as informações recebidas do carrossel de objetosdesmembrando mensagens Biop em módulos. Para obter informações desses módulos e tratálos,a entidade ServiceDomain precisa realizar diversas invocações a operações da entidadeModule. Além disso, a entidade ServiceDomain invoca operações da entidade Biop para queesta identifique o tipo do objeto (arquivo, diretório ou Service Gateway) presente em cadamódulo e processe-os de forma adequada. A invocação de operações de Module e Biop é o quemais contribui para o resultado de MPC. O alto valor de CBO indica que essa entidadeapresenta acoplamento a oito outras entidades do sistema: Module, Biop, Ior, ObjectProcessor,DownloadServerInitiate, DownloadInfoIndication, DownloadDataBlock e Thread. As trêsprimeiras da lista dizem respeito à obtenção de informações dos objetos do carrossel de objetos.O acoplamento a ObjectProcessor refere-se à inicialização da lista de listeners para oServiceDomain sendo tratado. Operações de DownloadServerInitiate, DownloadInfoIndication,DownloadDataBlock são invocadas pela entidade ServiceDomain para obter informações sobreos dados recebidos. Por fim, ServiceDomain usa operações da entidade Thread parasincronização. Embora haja acoplamento a todas essas entidades, ele é mais forte em relação aModule, fortalecendo a idéia de que esta entidade implementa um conceito transversal, comosugerido anteriormente.A entidade StreamEvent é responsável por guardar informações sobre eventos comotamanho, nome, tempo de referência e dados. Sua implementação consiste em um conjunto deoperações get e set sobre atributos referentes a essas informações. Por isso, StreamEvent nãoapresenta acoplamento a outras entidades do sistema.A entidade DsmccMessageHeader processa e retira informações do cabeçalho damensagem como tamanho da mensagem, identificador da mensagem, armazena-as em seusatributos e define um conjunto de operações para que outras entidades possam acessar essasinformações. Por tratar apenas as informações contidas em um arquivo, essa entidade nãoapresenta acoplamento em relação a outras entidades do sistema.A entidade DownloadDataBlock processa blocos de dados – subdivisões de um módulo.Para realizar essas tarefas, ela não define acoplamento considerável, apenas algumas invocações99

a operações das entidades Module – para obter informações sobre módulos – eDsmccMessageHeader – para acessar informações sobre o cabeçalho da mensagem.A entidade DownloadInfoIndication recebe um arquivo contendo uma mensagem edesmembra em informações (como tamanho e identificador de carrossel) dos módulosreferenciados no cabeçalho na mensagem DII. Ela invoca operações da entidade Module pararepassar a ela essas informações. De forma a manter temporariamente essas informações, aentidade DownloadInfoIndication define atributos com tipo Module. A maior parte do valor damétrica DAC se deve a declaração destes atributos. Para obter informações sobre a mensagem aser tratada, DownloadInfoIndication invoca também operações de DsmccMessageHeader.A entidade DownloadServerInitiate recebe uma mensagem e retira informações –identificador de carrossel, identificador do módulo e chave do objeto – do cabeçalho damensagem sobre um objeto Service Gateway. Essas informações são passadas à entidade Ior pormeio de invocações a operação desta entidade. Também são invocadas operações deDsmccMessageHeader para obter informações sobre o cabeçalho.A entidade MessageProcessor, ao receber uma mensagem, verifica se ela é do tipoDownloadServerInitiate, DownloadDataBlock ou DownloadInfoIndication e a processa deacordo com o seu tipo. Ela também define uma instância de ServiceDomain para quem forneceinstâncias de DownloadServerInitiate e DownloadInfoIndication.A entidade Module não apresenta acoplamento. Essa entidade é responsável apenas porarmazenar informações sobre cada módulo, como identificador do módulo, tamanho eidentificador do carrossel.A entidade EPGProcessor decodifica as tabelas SDT (Service Description Table) e EITEvent Information Table). A primeira fornece informações sobre um serviço (um tipo de fluxo,como vídeo e áudio) e a segunda, sobre eventos (um programa de TV, por exemplo) sendotransmitidos. Essa entidade invoca operações das entidades ServiceInfo e EventInfo do pacotegingacc-tsparser através de suas interfaces, não contribuindo para os valores das métricas deacoplamento.A entidade TransportSection recebe uma sessão de dados e extrai informações comotamanho, versão e número da sessão, além de sua carga útil. Não apresenta acoplamento aoutras entidades do sistema.A entidade SectionFilter recebe pacotes TSPacket por meio da interface ITSPacket dopacote gingacc-tsparser. SectionFilter processa pacotes e cria uma nova sessão por meio dainterface ITransportSection ou adiciona dados a uma sessão já existente. Não apresentaacoplamento, as invocações a outras entidades são realizadas por meio de interfaces.100

A entidade FilterManager permite definir um filtro como instância da entidadeSectionFilter e definir seus listeners. O filtro definido é passado ao Demuxer através dainterface IDemuxer. Além disso, essa entidade mantém instâncias de SectionFilters associadas aum tipo de stream. Para realizar essas funcionalidades, ela define atributos com tipo deSectionFilter e invoca operações dessa entidade para adicionar listeners aos filtros. Esseacoplamento aparece nos resultados das métricas.As entidades do pacote gingacc-dataprocessing referentes a formato de dadosDownloadDataBlock, DownloadServerInitiate, DownloadInfoIndication e MessageProcessorapresentam acoplamento considerável à entidade DsmccMessageHeader. Além disso, asentidades DownloadDataBlock e DownloadInfoIndication também apresentam acoplamentoem relação à entidade Module. Portanto, seria interessante verificar se as entidadesDsmccMessageHeader e Module implementam um conceito transversal.Considerando o pacote gingacc-dataprocessing como um todo, sugere-se analisar osconceitos transversais contidos nas seguintes entidades: Module, DsmccMessageHeader,Object, Binding e Ior. Isso por se verificar, durante a coleta de dados de acoplamento, que asoutras entidades do sistema apresentam maior força de acoplamento (valor considerável deMPC) a essas entidades. A Tabela 19 mostra as entidades que apresentam acoplamento a essesconceitos. Embora o acoplamento a Object e Binding não ocorra em muitas entidades, nas quaisocorre se apresenta com alta freqüência.Tabela 16: relação de acoplamento entre as entidades do pacote gingaccdataprocessinge os conceitos transversais.Entidade/ Conceito Module DsmccMessageHeader Object Binding IorTransversalBindingXBiop X X X XIorObjectProcessor X X XObjectXServiceDomain X XStreamEventDownloadDataBlock X XDsmccMessageReaderDownloadInfoIndication X XDownloadServerInitiate X XMessageProcessorXModule101

EPGProcessorTransportSectionSectionFilterFilterManager8.7 Pacote gingacc-systemA Tabela 17 apresenta os resultados da medição realizada no pacote gingacc-system:pacote responsável por fornecer ao middleware acesso aos recursos de hardware, comodispositivos de áudio e vídeo, entrada de dados, além de threads. Nesse pacote, ainda há umgerenciador de devices registrados no middleware e mecanismos de providers paraimplementações de áudio, vídeo, fontes e imagens. As interfaces para objetos gráficos de baixonível como windows e surfaces utilizados nas demais partes do middleware também sãodefinidos no gingacc-system[3].Tabela 17: resultados para as métricas CBO, MPC e DAC e a forma como oacoplamento ocorre nas entidades de gingacc-system.Entidade CBO MPC DAC Acoplada às entidadesIODevice 0 0 0DeviceManager 1 5 5 IODeviceDFBDeviceScreen 0 0 0DeviceCommunication 0 0 0DFBAudioProvider 1 4 0 DeviceManagerFusionSoundAudioProvider 0 0 0DFBImageProvider 1 4 0 DeviceManagerDFBFontProvider 1 2 0 DeviceManagerDFBVideoProvicer 1 4 0 DeviceManagerDeviceAudio 0 0 0CodeMap 0 0 0DFBEventBuffer 1 2 0 DeviceManagerDFBGInputEvent 1 0 0 Referencia atributo deCodeMapDFBSurface 1 8 0 DeviceManagerDFBWindow 1 6 0 DeviceManager102

GingaLocatorFactory 0 0 0InputManager 1 11 0 ThreadThread 0 0 0A entidade IODevice armazena listas com todos os devices de entrada e saída. Há listaspara devices de áudio, tela (imagem de vídeo) e comunicação (como por exemplo, conectoreswireless, HDMI, canal de retorno e canal de interatividade). Para realizar funcionalidades deadicionar novos objetos às listas que mantém, ela invoca operações das entidadesDFBDeviceAudio, DFBDeviceScreen e DeviceCommunication através das suas respectivasinterfaces IDeviceAudio, IDeviceScreen e IDeviceCommunication. Assim, essas invocações nãocontribuem para os valores das métricas de acoplamento.A entidade DeviceManager gerencia os devices de entrada e saída. Para isso, mantémuma lista com os devices. Suas operações fornecem informações de resolução de device, criaçãoe liberação de device. Para fornecer essas funcionalidades, ela precisa definir um atributo comtipo IODevice e invoca operações desta para realizar as tarefas desejadas. A isso se deve osvalores de acoplamento para DeviceManager.A entidade DFBDeviceScreen cria elementos como Window e Surface através do pacoteDirectFB[5] e mantém informações sobre eles em listas. Isso é feito através das interfacesIDirectFBWindow e IDirectFBSurface. Como são interfaces e, além disso, não pertencem aosistema em avaliação, esse acoplamento não é considerado para o resultado das métricas. Porisso, essa entidade apresenta acoplamento zero. O mesmo ocorre em relação ao uso de diretivasde sincronização da biblioteca Pthread[6]. DFBDeviceScreen também armazena informaçõessobre a resolução da tela e permite o acesso através de suas operações.A entidade DeviceCommunication define basicamente constantes estáticas sobreconectores de devices (wireless, HDMI, Bluetooth, Ethernet, Canal de Retorno). Por isso, essaentidade não apresenta acoplamento a outras entidades do sistema. O mesmo acontece com aentidade DeviceAudio, que define constantes sobre tipo de áudio como mono e stereo, nãoapresentando acoplamento a outras entidades do sistema.A entidade DFBAudioProvider provê áudio através da bibliotecaDirectFBVideoProvider. Assim, essa classe apresenta, principalmente, acoplamento ao pacoteDirectFB[5] que não pertence ao sistema em avaliação. Logo, ele não contribui para os valoresdas métricas. O acoplamento apresentado para DFBAudioProvider refere-se à invocação aoperações de DeviceManager para obter uma instância desta entidade. A partir desta instância,aquela entidade pode, por exemplo, invocar uma operação de DeviceManager para criar103

surfaces. O mesmo ocorre com as entidades DFBImageProvider (provê imagens associando-asa uma surface), DFBFontProvider (trata de fontes de arquivo), DFBVideoProvider (provê vídeoassociando-o a surface e, em seguida, a Window) e DFBEventBuffer (cria um buffer paraarmazenamento de eventos), que usam o pacote DirectFB para prover suas funcionalidadesbásicas e também precisam obter uma instância de DeviceManager para criar surfaces e/ou paraobter a interface de DirectFB associada à entidade ou device.A entidade FusionSoundAudioProvider, para realizar suas funcionalidades, utiliza abiblioteca FusionSound DirectFB[4]. Essa biblioteca provê streams e buffers para áudioestático, além de controle sobre qualquer número de execuções de áudio concorrentes. ComoFusionSound não faz parte do sistema em avaliação, esse acoplamento não é considerado nacoleta das métricas e, portanto, FusionSoundAudioProvider não apresenta acoplamento.A entidade CodeMap realiza o mapeamento entre teclas do teclado e constantesdefinidas nessa entidade. Como essa funcionalidade não requer informações de outras entidadesdo sistema, CodeMap não apresenta acoplamento.A entidade DFBGInputEvent trata informações sobre eventos como tipo e código datecla que gerou o evento. Para isso, ela referencia atributos CodeMap – constantes estáticasdefinidas nessa entidade. Por isso, o seu único acoplamento se dá por referência a atributo deuma outra entidade no sistema.A entidade DFBSurface implementa funcionalidades relacionadas a surfaces: definircor, desenhar linhas e retângulos, definir bordas dentre outras. Para realizar tais tarefas, essaentidade utiliza o pacote DirectFB. DFBSurface associa uma Window a cada surface através dainterface IWindow. Logo, esse acoplamento é desconsiderado. A única fonte de acoplamentodessa entidade é a DeviceManager. É através desta entidade que DFBSurface cria e liberasurfaces.A entidade DFBWindow armazena em seus atributos informações sobre Window comolargura, altura, se está visível ou não, o nível de transparência e uma lista com surfacesassociadas a uma instância de DFBWindow. Apresenta uma implementação similar aDFBSurface: DFBWindow fornece funcionalidades relacionadas a Window através do pacoteDirectFB e invoca operações de DeviceManager para criar e liberar instâncias de Window,sendo esta a fonte de acoplamento relativa ao resultado da métrica MPC. Embora essa entidadeutilize funcionalidades definidas para Surface, isso não constitui fonte de acoplamento porque ainvocação a operações é realizada através da interface IDirectFBSurface. DFBWindowapresenta também, em sua implementação, diretivas de sincronização de Pthread [4] que, comonão são definições do sistema, não interferem no resultado das métricas.104

A entidade GingaLocatorFactory define um conjunto de listas para armazenarreferências a objetos de clientes e provedores. Ela permite criar e obter localizadores paraobjetos através de URIs, além de permitir adicionar localização de clientes do mesmo modo.Essa classe não apresenta acoplamento. Sua principal tarefa é tratar strings para retirarinformações das URIs. Essa entidade também faz uso de diretivas de Pthreads parasincronização.A entidade InputManager gerencia eventos recebidos como entrada no sistema. Paraisso, invoca operações nas interfaces IEventBuffer e IInputEventListener, o que não contribuipara o resultado das métricas de acoplamento. O construtor dessa entidade define uma threadpara esperar e tratar eventos recebidos. Para isso, invoca operações da entidade Thread doGingaCC, contribuindo para os valores de MPC. Além da sincronização realizada através deoperações da entidade Thread, InputManager também utiliza diretivas da biblioteca Pthreadpara sincronização através de mutex.A entidade Thread define funcionalidades para o uso de threads, como bloqueio edesbloqueio de fluxos de execução. Com esse propósito, ela usa as facilidades de Pthread,fazendo com que Thread não apresente acoplamento a outras entidades do sistema.A Tabela 17 mostra que 7 das 18 entidades do pacote gingacc-system apresentamacoplamento à entidade DeviceManager. Esse acoplamento se deve à necessidade de se obteruma instância dessa entidade para criar e liberar instâncias de devices, por exemplo. Então, seriainteressante analisar a implementação dessa entidade quanto à presença de conceitos.As classes InputManager, GingaLocatorFactory, DFBWindow, DFBDeviceScreen eThread usam diretivas de Pthread para realização de sincronização. Embora ocorra em apenas 5das 18 entidades do pacote gingacc-system e não contribuam para os valores das métricas deacoplamento, a freqüência do acoplamento entre Pthread e estas entidades é considerável,indicando que este deve ser considerado um candidato a conceito transversal.Há ainda um acoplamento considerável entre as entidades de gingacc-system einterfaces relacionadas a Window e Surface. Embora não contribuam para os resultados dasmétricas de acoplamento, a definição de elementos gráficos como um conceito transversalpoderia trazer melhorias à legibilidade do código-fonte.8.8 Pacote gingacc-tsparserA Tabela 18 apresenta os resultados da medição realizada no pacote gingacc-tsparser.Esse pacote recebe, através do pacote gingacc-tuner, um determinado Transport Stream (TS).Em seguida, realiza a demultiplexação do TS, fornecendo os diversos fluxos elementares105

(elementary streams) presentes. Os fluxos elementares são streams de áudio e vídeomultiplexados juntos e codificados. Para possibilitar o processo de multiplexação, os fluxoselementares são divididos em pacotes, dando origem ao PES (Packetized Elementary Stream).Esses pacotes PES são mais uma vez divididos em pacotes menores formando os pacotes detransporte (transport packets) [5].Os fluxos elementares não carregam informações sobre o tipo de dado que transportam.Essas informações são transmitidas em tabelas adicionadas ao TS durante a multiplexação,serviço conhecido como Service Information (SI), a serem interpretadas pelo gingacc-tsparserno receptor.Em outras palavras, um fluxo de transporte é dividido em duas camadas deencapsulamento de dados. A camada inferior é formada por pacotes de transporte, onde cadapacote é encarregado de transportar um fragmento de determinado fluxo elementar da camadaimediatamente superior. As estruturas da camada superior, por sua vez, são divididas em doistipos: Seções (sections) e PES (Packetized Elementary Streams).Tabela 18: resultados para as métricas CBO, MPC e DAC e a forma como oacoplamento ocorre nas entidades de gingacc-tsparser.Entidade CBO MPC DAC Acoplada às entidadesDemuxer 3 31 5 Pmt, Pat e TSSectionPat 1 11 7 PmtPmt 1 3 0 TSSectionTSSection 0 0 0TSPacket 1 1 0 DemuxerPipeFilter 1 2 0 ThreadEventInfo 1 1 1 ShortEventDescriptorServiceInfo 1 1 1 LogoTransmissionDescriptorShortEventDescriptor 0 0 0LogoTransmissionDescriptor 0 0 0ExtendedEventDescriptor 0 0 0106

A entidade Demuxer é responsável por separar o TS em fluxos elementares. Ela defineatributos cujo tipo é as entidades Pmt e Pat e invoca operações delas para que processeminformações sobre serviços contidos no TS. Esta é a maior fonte de acoplamento que reflete nosresultados de MPC. O acoplamento à entidade TSSection é menos expressivo e se deve aoperações invocadas a partir de instâncias de Pat e de Pmt, pois estas entidades herdam deTSSection.A entidade Pat representa a tabela PAT (Program Association Table) e forneceinformações sobre quais serviços estão presentes em um TS, associando cada serviço a um PID,identificador único. Assim, ela precisa manter uma lista de instâncias de Pmt – Pmt associafluxos elementares do TS a um serviço. O acoplamento apresentado em Pat refere-se, então, aoprocessamento de instâncias de Pmt associadas a uma Pat.A entidade Pmt representa a tabela PMT (Program Map Table) e contém informaçõessobre quais fluxos elementares do TS fazem parte de um serviço. Essa entidade herda deTSSection, em quem invoca operações para obter carga útil (payload) a partir de uma sessão,por exemplo.A entidade TSSection recebe um stream de dados e processa seu cabeçalho e sua cargaútil. Do cabeçalho, extrai informações como versão, número e tamanho da sessão. A carga útil écopiada para um atributo dessa entidade relativa à sessão. Para realizar essas tarefas, TSSectionnão necessita obter informações de outras entidades do GingaCC. Por isso, ela não apresentaacoplamento.A entidade TSPacket recebe como parâmetro em seu construtor um pacote de dados eretira desse pacote informações como PID, prioridade de transporte e tamanho da carga útil. Suaúnica fonte de acoplamento é uma invocação a um método da entidade Demuxer para saber se oPID do pacote corresponde a um PID de sessão válido definido em Demuxer.A entidade PipeFilter define um pipe como uma estrutura FIFO (First In, First Out) edireciona pacotes recebidos ao pipe. Para sincronização, invoca operações da entidade Thread,implicando nos resultados da coleta para as métricas de acoplamento.A entidade EventInfo trata informações de eventos: tamanho, identificação, status etc.Seu único acoplamento ocorre com a entidade ShortEventDescriptor, da qual se define umatributo com esse tipo para obter tamanho desse tipo de evento. O mesmo se dá com a entidadeServiceInfo que trata informações sobre serviços, apresentado um baixo acoplamento aLogoTransmissionDescriptor.Em TV digital, Um canal de TV consiste em um conjunto de eventos e cada evento éum único programa de TV[8]. As entidades ShortEventDescriptor,107

LogoTransmissionDescriptor e ExtendedEventDescriptor contém descritores de eventos. Nãoapresentam acoplamento.No pacote gingacc-tsparser, não há acoplamento significativo para a maioria dasentidades. As únicas entidades com acoplamento mais expressivo são Demuxer, para obtençãode informações das tabelas PAT e PMT, e Pat, que define atributos cujo tipo é Pmt paraprocessar informações do TS.8.9 Pacote gingacc-tunerA Tabela 19 apresenta os resultados da medição realizada no pacote gingacc-tuner. Ogingacc-tuner possui como principal função a seleção e recuperação de dados. Na medida emque os dados são recuperados, o Tuner dispara eventos contendo os pacotes de dados recebidospara seus ouvintes (listeners). Atualmente, há dois tipos de recepção de dados: através desistema de arquivos (o Tuner lê um arquivo direto do sistema de arquivo local) e através de redeIP (Tuner recupera o fluxo de dados de um endereço IP) [3].Tabela 19: resultados para as métricas CBO, MPC e DAC e a forma como oacoplamento ocorre nas entidades de gingacc-tuner.Entidade CBO MPC DAC Acoplada às entidadesNetworkInterface 1 3 1 DataProviderDataProvider 0 0 0SocketProvider 0 0 0UnicastProvider 0 0 0MulticastProvider 0 0 0FileSystemProvider 0 0 0Tuner 3 8 4 NetworkInterface, DataProvider eThreadA entidade NetworkInterface representa um canal, ou seja, um provedor de dados. Essaentidade possui operações para criar um provedor de dois tipos: Ethernet, recebe dados através108

de rede IP, ou sistema de arquivos, recebe dados do sistema de arquivos local. Se for Ethernet,verifica-se ele é do tipo unicast ou multicast. Essa entidade define uma entidade do tipoDataProvider que pode receber uma instância de qualquer tipo de provedor.A entidade DataProvider é classe base implementada por SocketProvider (de quemUnicastProvider e MulticastProvider herdam e implementam operações) e FileSystemProvider.A partir daquela, a entidade NetworkInterface pode invocar operações sobre um provedor semprecisar saber se é uma instância de UnicastProvider, MulticastProvider ouFileSystemProvider. Não apresenta acoplamento a outras entidades do sistema.A entidade Tuner inicializa, cria e faz a mudança de canais. Para fazer essas tarefas,define 4 atributos cujo tipo é NetworkInterface. Quando um usuário decide sintonizar em algumcanal, ou seja, sempre que ocorre uma troca de canal, uma nova thread é iniciada. Nesse caso,Tuner obtém o provedor do canal através de uma invocação à operação de NetworkInterface e,através da instância de DataProvider recebida como resposta à invocação, recebe dadosreferentes ao canal. E seguida, notifica os interessados usando a interface ITunerListener. Aisso se deve o acoplamento de Tuner às entidades NetworkInterface, DataProvider e Thread.Como a notificação aos interessados é feita através de uma interface, esse acoplamento édesconsiderado para o resultado das métricas.A entidade SocketProvider consiste basicamente em um conjunto de métodos virtuais.Por isso, não apresenta acoplamento.A entidade UnicastProvider conecta-se a um servidor através de sockets e recebe dadospor meio deles, não necessitando de informações de outras entidades do sistema. Por isso, nãoapresenta acoplamento. O mesmo ocorre em relação à entidade MulticastProvider, com adiferença de que a conexão ocorre a um socket multicast.A entidade FileSystemProvider recebe dados do sistema de arquivos local através de umdescritor de arquivo. Para realizar essa funcionalidade, não se acopla a nenhuma outra entidadedo sistema.Poucas entidades do pacote gingacc-tuner apresentam acoplamento coletado pelasmétricas. A entidade NetworkInterface poderia abstrair o tipo de provedor de dados de umcanal, mas provavelmente isso não justifica a definição de um aspecto. Quanto a Tuner, a maiorparte do seu acoplamento está relacionado a NetworkInterface, tipo de 4 de seus atributos, masisso não constitui um conceito transversal para todo o pacote.109

9 Métricas de Tamanho paraImplementaçãoA maior parte das métricas de tamanho apresentadas na Tabela 7 já foram coletadas naarquitetura do GingaCC e apresentadas no segundo entregável deste projeto [3]. A única métricaque ainda precisa ser coleta é LOC (linhas de código), que precisa ser feita no código-fonte dosistema. As demais métricas VS, NOA e WOC não terão seus resultados alterados caso sejamcoletados em código-fonte.A Tabela 20 apresenta os resultados de LOC para o GingaCC divididos por pacote. Amétrica foi coletada nos códigos-fontes de entidades e interfaces, excluindo-se as linhas embranco e comentadas. Nós desconsideramos arquivos de configuração do sistema. As métricasVS, NOA e WOC cujos resultados aparecem no segundo entregável [3], também sãoapresentadas na Tabela 20.Os resultados da medição de tamanho realizada no GingaCC serão posteriormentecomparados aos resultados de sua versão refatorada, no intuito de avaliar o impacto do uso daabordagem orientada a aspectos no tamanho do sistema.Tabela 20: resultados obtidos as métricas de tamanho LOC, VS, NOA e WOC.Pacote LOC VS NOA WOCgingacc-player 4443 15 108 395gingacc-contextmanager 728 3 19 88Gingacc-ic 529 2 16 56Gingacc-cm 1173 4 26 149Gingacc-um 171 1 3 11Gingacc-dataprocessing 5212 17 94 235Gingacc-system 4542 18 121 743Gingacc-tsparser 2284 11 115 243Gingacc-tuner 743 7 17 74110

Total 19825 78 519 199410 Discussão dos ResultadosDos pacotes do GingaCC avaliados, o gingacc-player, o gingacc-dataprocessing e ogingacc-system são os que apresentam acoplamento considerável. É importante ressaltar que oacoplamento identificado através das métricas é diminuído principalmente pelo uso deinterfaces na implementação do sistema.Para o pacote gingacc-player, o acoplamento entre entidades deve-se basicamente àsentidades Thread e Player. A entidade Player define a funcionalidade básica que todos os tiposde players definidos no gingacc-player devem fornecer, justificando o acoplamento de tantasentidades a Player. O acoplamento a Thread deve-se à necessidade de sincronização durante aexecução dos diversos tipos de players definidos nesse pacote. Por isso, os candidatos aconceitos transversais levantados para esse pacote são os implementados em Thread e Player.O pacote gingacc-dataprocessing apresenta acoplamento principalmente a entidades dedefinição de estruturas para transmissão no carrossel de dados (entidades Module,DsmccMessageHeader e Object) e a entidades que armazenam informações sobre objetos(entidade Binding) e sobre localização do objeto no carrossel de dados (entidade Ior). Module,Binding e DsmccMessageHeader são as entidades às quais as outras entidades do pacote maisestão acopladas. Embora poucas entidades deste pacote sejam acopladas às entidades Object eIor, essas poucas são fortemente acopladas. Esse é o caso de Biop e ObjectProcessor. Por isso,também entram na lista dos candidatos a conceitos transversais.No pacote gingacc-system, o acoplamento ocorre principalmente entre as entidadesdesse pacote e a entidade DeviceManager. É o que mais contribui para os resultados dasmétricas. Há ainda acoplamento a interfaces de elementos gráficos como Window e Surface, queembora não contribuam para o resultado das métricas, podem ser candidatos a conceitostransversais. O mesmo ocorre ao uso de diretivas de Pthread[6].A avaliação do acoplamento contribuirá para a análise da modularidade do GingaCC.Além dos resultados para acoplamento, os resultados da coleta de métricas de separação deconceitos e de coesão, a serem apresentados nos próximos entregáveis, contribuem para essaavaliação. Esses dados ganham significado quando comparados aos obtidos para as mesmasmétricas, mas coletados na versão OA do GingaCC.111

Os resultados da medição de tamanho no GingaCC contribuirão para análise dapropriedade tamanho ao compararmos esses resultados aos obtidos para as mesmas métricas naversão refatorada do GingaCC. Essa comparação e a análise sobre o tamanho do sistema serãoapresentadas nos próximos entregáveis.10.1 Relação entre Variabilidades do Modelo de Features eAcoplamento presente no GingaCCComo dito anteriormente, dos pacotes avaliados através de métricas, aqueles queapresentam acoplamento considerável foram gingacc-player, gingacc-dataprocessing e gingaccsystem.A partir disso, seria interessante estabelecer uma relação entre o acoplamento presentedesses pacotes e a definição variabilidades do modelo de features, definido no segundoentregável deste projeto [3].A feature Media Processing foi mapeada para o código de gingacc-player [3]. A featureestá associada aos pontos de variação com os diversos tipos de mídia que GingaCC é capaz deprocessar. Os resultados das métricas mostraram que Player, classe base para todas as outrasimplementações de players específicos a uma mídia, era origem de grande parte deacoplamento. Temos, então, uma relação entre a medição do acoplamento e o modelo devariabilidades.Ainda quanto à feature Media Processing, ela também é mapeada ao código do pacotegingacc-system [3]. Em gingacc-system, a principal fonte de acoplamento é ao gerenciador dodispositivo que deve prover um serviço, como áudio, vídeo, imagem e fonte. Mais uma vez, háentão relação entre os pontos de variação e a medição do acoplamento. A definição de umaspecto contendo a implementação do gerenciador de dispositivo melhoraria o acoplamento dopacote além de abstrair qual dispositivo seria utilizado em cada situação.A feature Data Processing foi mapeada para o código do pacote gingaccdataprocessing.O acoplamento principal desse pacote refere-se a entidades que definem aestrutura do carrossel de objetos usado para transmissão de dados. Não há, então, nenhumarelação com os pontos de variabilidades definidos para a feature Data Processing: atualizaçãode software e montagem de aplicação.Os resultados de medição de acoplamento para gingacc-tuner, apesar de não serem tãoelevados, apresentam relação com o modelo de features. A principal fonte de acoplamento dessepacote ocorre à classe base de definição de provedor de dados que é implementada pelas outrasque são provedoras de dados oriundos da rede IP e do sistema de arquivos local. A feature112

Tuner é mapeada para o código do gingacc-tuner e dois dos seus pontos de variação sãojustamente File System e IP. Como os provedores de dados por satélite e sinal terrestre (tambémpontos de variação da feature Tuner) não estão implementados no GingaCC, não foi possívelavaliar o acoplamento em relação a entidades que os implementem.113

Referências[1] Moreno, M.F.; Soares, R.F.R.; Soares, L.F.G. Mecanismo de Identificação de Recursos paraAplicações Interativas em Redes de TV Digital por Difusão. Simpósio Brasileiro de Redes deComputadores (SBRC'07), 2007.[2] Freitas, T.A.V. Métricas para Avaliação de Sistemas de Middleware Orientado a Aspectos eAplicação em um Sistema de Monitoramento de Poços de Petróleo. Dissertação (mestrado) -Universidade Federal do Rio Grande do Norte, 2009.[3] Batista, T.V. et al. GingaForAll - Arquitetura e Ferramenta para Concepção de Linhas deProdutos do GingaCC para Multiredes. Monografia – Especificação do modelo compartilhado edo modelo de variabilidades para o GingaCC a partir da análise de sua arquitetura. ProgramaCTIC/RNP. Entregável do Segundo Trimestre – Julho de 2009.[4] Fusion Sound DirectFB. Disponível em:http://www.directfb.org/index.php?path=Platform%2FFusionSound. Acesso em 01/10/2009.[5] DirectFB. Disponível em: http://www.directfb.org. Acesso em 01/10/2009.[6] POSIX Threads Programming. Disponível em: https://computing.llnl.gov/tutorials/Pthreads.Acesso em 13/10/2009.[7] FENTON, N. Software measurement: a necessary scientific basis. IEEE Transactions onSoftware Engineering, v.20, n.3, p. 199-206, 1994.[8] An Introduction To Digital TV Technology. Disponível em:http://www.interactivetvweb.org/tutorials/dtv_intro/dtv_intro. Acesso em 19/10/2009.[9] cURL. Disponível em: http://curl.haxx.se. Acesso em 22/10/2009.114

PARTE IIINessa parte do documento serão discutidos os diversos meios de transmissão dosconteúdos televisivos via internet. O objetivo das próximas seções desse documento éidentificar as principais variabilidades e similaridades entre os seguintes meios de distribuiçãode conteúdo televisivo via internet: IPTV, InternetTV e P2PTV.11 IPTV, InternetTV e P2PTVUm dos motivadores para a construção de uma linha de produto de software a partir doGinga-CC é permitir sua especialização para diferentes plataformas, protocolos e formas detransmissão de conteúdo (tais como IPTV, InternetTV e P2PTV). O IPTV (Internet ProtocolTelevision) consiste em um conjunto de protocolos que permitem a transmissão de conteúdo deTV Digital sobre redes IP 1 . O InternetTV é o termo utilizado para designar a transmissão deconteúdo multimídia utilizando a infraestrutura da Internet. Por fim, P2PTV (peer-to-peertelevision) refere-se à transmissão de conteúdo multimídia utilizando redes peer-to-peer (P2P).Nesta seção, são apresentados os conceitos básicos relacionados a IPTV, InternetTV eP2PTV, bem como uma breve descrição de alguns protocolos empregados nestas diferentesformas de comunicação, através da avaliação destes protocolos utilizados, espera-se identificarcaracterísticas comuns, opcionais e alternativas nas implementações IPTV, InternetTV eP2PTV, permitindo o refinamento do modelo de features atual do Ginga. Por fim, apresentamoscomo podemos modelar as variações dos protocolos de rede no modelo de features e no modelode variabilidades da arquitetura.11.1 IPTV1 De acordo com um estudo realizado pelo MultiMedia Research Group [1], em 2012 osserviços de vídeo pela internet gerarão uma receita de 11 bilhões de dólares sendo 57 milhõesrelacionados com set-top box com suporte a IPTV .115

Aplicações de IPTV utilizam basicamente dois grupos de protocolos. Os protocolos darecomendação H.323, desenvolvida pelo ITU [2]; e o SIP (Session Initiation Protocol),desenvolvido pela IETF [3] e descrito na RFC 3261.11.1.1 H.323A recomendação H.323, proposta pela ITU (International Telecommunication Union),define uma série de protocolos que têm a finalidade de prover sessões de comunicaçãoaudiovisual em uma rede de pacotes que não implementam mecanismos de qualidade de serviço(QoS), como, por exemplo, a Internet. Ela tem sido empregada em várias aplicações de temporealpara a Internet como o GnuGK [4] e o NetMeeting [5].A especificaçãoo H.323 define um conjunto de elementos voltados para a realização decomunicação multimidia. Tais elementos são apresentados na Figura 28.Figura 28: Arquitetura H.323O gateway é responsável por conectar a Internet à rede de telefonia. No lado da Internet,ele faz uso do conjunto de protocolos do H.323, enquanto no lado da rede de telefonia empregaos protocolos especificados para a PSTN (Rede Telefônica Pública Comutada). Os terminais sãoelementos fundamentais de um sistem H.323. Eles são centrais comunicação multimídia comotelefones ou dispositivos IVR. O gatekeeper é o elemento responsavel por resolver osendereços, controlar a admissão de novos participantes, gerenciar a banda empregada pelosparticipantes dentre outros servidos. Por centralizar os pedidos de chamadas, os gatekeepercontrolam um certo conjunto de terminais sob sua jurisdição. Ao de conjunto de elementosgerenciados por um gatekeeper, denomina-se zona. Ou seja, uma zona é um conjunto de116

terminais, gateways e MCUs gerenciados por um único gatekeeper que contém pelo menos umterminal e pode incluir segmentos de LAN conectados usando roteadores. Uma MCU (Unidadede Controle Multiponto) é um dispositivo de hardware responsável por gerenciar conferênciasmultipontos entre os diversos terminais, sendo capaz de combinar áudio e vídeo de fontesdistintas.A recomendação H.323 faz referência a diversos protocolos específicos paracodificação e decodificação de voz e vídeo, configuração e sinalização de chamadas etransportes de dados dos fluxos de áudio e vídeo. A Figura 29, mostrada a seguir, exibe a pilhade protocolos relacionados à H.323.Figura 29: Pilha de protocolos H.323Conforme ilustra a Figura 29, existem diversos protocolos específicos para codificaçãoe decodificação de áudio e vídeo. Os diversos protocolos permitem diferentes compromissosentre qualidade e largura de banda.A flexibilidade de escolha dos protocolos de compactação é viabilizada pelo H.245 quepermite que os terminais decidam o algoritmo de compactação a ser utilizado. Esse protocolotambém permite a o estabelecimento de canais lógicos para a troca de informações de controlefim-a-fim e a negociação de outros aspectos da conexão, como a taxa de transferência. Oprotocolo RTP é empregado para o transporte dos fluxos de dados e o RTCP é necessário paracontrolar os canais do RTP. Ambos os protocolos serão discutidos na Seção 11.1.3.A recomendação H.323 precisa de um protocolo para estabelecer e encerrar conexões,fornecer tons de discagem, gerar sons de chamada e as demais atividades da telefonia padrão.Para essa função, é empregado o protocolo H.225 de Sinalização de Chamadas (que utilizamensagens ITU Q.931). Além disso, os terminais precisam de um protocolo para se comunicarcom o gatekeeper (se existir algum). Para esse propósito, é usado o H.225. O canal do terminalpara o gatekeeper gerenciado por ele é chamado canal RAS (Registration/Admission/Status).117

Esse canal permite que os terminais entrem e saiam da zona, solicitem e retornem largura debanda, e forneçam atualização de status, entre outras coisas.11.1.2 SIPO SIP (Session Initiation Protocol) foi desenvolvido pela IETF e é descrito pela RFC3261. Este protocolo define como estabelecer chamadas telefônicas pela internet,videoconferências e outras conexões multimídia, controlando sessões multimídia decomunicação entre duas partes (ligação telefônica comum), várias partes (todos podem ouvir efalar) e sessões de difusão (um transmissor e múltiplos receptores).SIP é um protocolo textual que emprega alguns aspectos similares ao modelo derequisição/resposta do HTTP, reutilizando vários campos de cabeçalho deste protocolo. Valedestacar que o SIP é utilizado basicamente para criação, configuração e encerramento desessões. Vários outros protocolos são utilizados para outros fins, por exemplo, a transmissão dofluxo de áudio e vídeo entre aplicações é realizada através de RTP/RTCP e parâmetros deconfiguração como porta, codificação, etc, são negociados e definidos através do protocolo SDP(Session Description Protocol).11.1.3 Real-time Transport Protocol (RTP)RTP (do inglês Real-Time Transport Protocol) [17] é um protocolo de nível deaplicação que oferece funções de transporte fim-a-fim destinadas a aplicações que transmitemáudio e vídeo em tempo real na Internet como streaming, vídeo conferências, voz sobre IPdentre outras. O RTP não garante qualidade de serviço, por este motivo, ele é incrementadopelo RTCP (Real-Time Control Protocol) que tem o propósito de gerenciar as informaçõessobre os participantes da sessão, estatísticas de transmissão e informações de Qos (Quality ofService).A Figura 30 a seguir apresenta uma visão geral das interações dos protocolos RTP eRTCP com protocolos de outros níveis. Nessa figura é possível ver a clara separação defuncionalidades entre os dois protocolos118

Figura 30: Visão Geral dos protocolos RTP e RTCPComo conseqüência da sua especificação, os protocolos RTP e RTCP são independentesda camada de transporte subjacente e das camadas de rede. O protocolo subjacente deve provermultiplexação adequada para os pacotes de dados e controle. Na Figura 30 é possível notar quetais protocolos podem operar sobre os protocolos UDP e ST-II (Stream Protocol version two)tanto sobre redes Ethernet quanto em redes ATM ou em outras tecnologias de redes.O protocolo RTP oferece as seguintes funcionalidades: (i) multiplexação edemutiplexação de diversos fluxos de dados (mídias) sobre um único fluxo de pacotes UDP (ouST-II), (ii) sincronização de intra-mídia e inter-mídia, (iii) adaptação do tipo de codificação emum fluxo em granularidade de pacote, (iv) seqüenciamento dos pacotes (v) identificação dofluxo ao qual o pacote pertence e (vi) fornece informações sobre a qualidade da recepção dosinal.A retransmissão de pacotes não é viável em transmissões em tempo real, sendo ainterpolação a melhor opção para contornar a perda de pacotes. Logo, o RTP não precisafornecer nenhum controle de erro, fluxo, confirmação de recebimento de pacote ou mecanismosde solicitação de retransmissão. Essas características justificam a escolha do RTP pelo UDP emdetrimento ao TCP.O protocolo RTP não oferece mecanismos para reservas de recursos, não garante otempo de entrega dos pacotes e, portanto não fornece nenhuma garantia da qualidade de serviço.Portanto, estas questões devem ser tratadas por outros mecanismos. Contudo, uma aplicaçãopode fazer ajustes locais com base nas informações de QoS fornecidas pelo RTP.Como dito anteriomente, o RTP é associado a um protocolo de controle, o RTCP (RTPControl Protocol) para permitir o monitoramento da entrega de dados de forma escalável eoferecer funcionalidades mínimas de controle e identificação. De acordo com Tanenbaum [6], o119

RTCP tem como funcionalidade básica prover feedback sobre a qualidade da transmissão taiscomo retardo, flutuação, largura de banda, congestionamento e etc. Tais informações dequalidade podem ser utilizadas pela aplicação para controlar o fluxo e o congestionamento darede.O RTCP trabalha enviando periodicamente pacotes RTCP para cada participante deuma sessão RTP. De acordo com [15], o envio desses pacotes permite: (i) mensurar o nível dequalidade da transmissão, (ii) observar o número de participantes, (iii) distribuir identificadorespara agrupar diferentes fluxos e (iv) opcionalmente disitribuir informações sobres osparticipantes da sessão.11.1.4 Real Time Streaming Protocol (RTSP)O RTSP é um protocolo de nível de aplicação utilizado por servidores de mídia paraestabelecer e controlar sessões de mídia durante a transferência em tempo real de dadosmultimídia. O objetivo desse protocolo é prover uma maior interação entre a fonte de fluxo demídia (servidor) e o usuário (cliente). O RTSP fornece funcionalidades semelhantes a um playercomum, permitindo o controle da mídia através de comandos de pausa e reinício, retrocesso,avanço e reposicionamento da reprodução. Além disso, o RTSP oferece operações para arecuperação de conteúdo armazenado em um servidor, mecanismos para notificações de novosconteúdos publicados tanto nos clientes como nos servidores e para a realização devideoconferências. A troca de mensagens do protocolo RTSP é mostrada na Figura 31.Figura 31: Troca de mensagens do RTSP120

O funcionamento do RTSP é bem simples: inicialmente, o cliente inicia a sessão RTSPcom uma requisição de SETUP. Nesse momento, o servidor atribui um identificar para cadasessão RTSP e responde ao cliente passando tal identificador (requisição RTSP SETUP). Ocliente então fornecerá esse identificador para cada requisição que fizer até que feche a sessãocom uma requisição através do comando TEARDOWN. O início da transmissão da mídiaacontece quando a aplicação cliente envia uma requisição de RTSP PLAY.O RTSP não encapsula os comandos no mesmo pacote de transmissão de mídia, ele osenvia paralelamente, em portas diferentes. A entrega dos dados deve ficar a cargo de outroprotocolo. A maioria dos servidores utilizam o RTP como protocolo para entrega dos dadostransmitidos.11.2 InternetTVComo dito anteriormente, InternetTV é um termo utilizado para designar a recuperaçãode conteúdo multimídia através da infraestrutura da Internet, diferenciando-se do IPTV namedida em que o IPTV ocorre em um ambiente altamente controlado com qualidade de serviço,boa largura de banda e normalmente com conteúdo HD. InternetTV tornou-se bastante popularnos últimos anos de forma que podem-se identificar atualmente inúmeras aplicações InternetTV,como por exemplo: BBC iplayer [7], Hulu [8], globo.com [9] dentre outras.Existem duas formas de disponibilização de conteúdo: via streaming ou download devídeo. No caso de stream, o conteúdo pode ser reproduzido simultaneamente com atransferência do mesmo, enquanto na forma de download, o vídeo deve ser completamentebaixado para que possa ser reproduzido. A transmissão de vídeo pode ser realizada através deuma rede ponto a ponto, neste caso o serviço é denominado P2PTV, conforme será melhordiscutido na Seção 11.3.Os diferentes provedores de conteúdo adotam suas diferentes soluções proprietárias,variando desde portais web (por exemplo, globo.com), até aplicações desktop (por exemplo,Miro [10]). De maneira geral, estas aplicações organizam os vídeos disponíveis em canais deforma que o usuário pode selecionar canais e acessar os vídeos associados..Algumas aplicações,por exemplo, o Miro, também permitem que o usuário se registre para receber indicações sobrenovos vídeos, desta forma o usuário é notificado quando um novo vídeo é disponibilizado emum determinado canal de interesse. Normalmente, a tecnologia utilizada para indicar que novosvídeos estão disponíveis é o RSS (Really Simple Syndication) [20].121

Dependendo da solução adotada é possível reproduzir o conteúdo em players comoVLC, MPlayer, etc ou em players embutidos em páginas web, normalmente utilizando atecnologia Adobe Flash [11]. A recuperação do vídeo é, geralmente, iniciada a partir de umarequisição HTTP (GET), desta forma, para que o middleware suporte InternetTV, ele devereceber uma determinada URL que localiza um certo vídeo de um determinado serviço deInternetTV de tal forma que ele seja capaz de reproduzir o formato de vídeo utilizado peloserviço, requisitando-o através do protocolo HTTP. Entende-se que o leitor já está familiarizadocom o protocolo HTTP, desta forma está fora do escopo deste documento examinar os detalhesde tal protocolo. Maiores informações sobre HTTP podem ser encontradas na RFC 2616 [21].11.3 P2PTVP2PTV é o termo utilizado para designar a distribuição de stream de vídeo através deredes ponto a ponto. Uma rede P2PTV típica consiste de uma fonte, provedora de conteúdo, emúltiplos clientes, usuários da programação. Os clientes podem conectar-se diretamente a fontepara receber a transmissão ou a outros clientes previamente conectados para obter o conteúdo. AFigura 32 2 ilustra uma configuração de rede P2PTV com três fontes (server) de vídeo,diferenciadas pelas cores azul, verde e laranja; e clientes que acessam diretamente o servidorfonte de conteúdo ou conectam-se a outros clientes da rede.Figura 32: Rede P2PTV2 Figura retirada de http://commons.wikimedia.org/wiki/File:P2ptv.PNG122

O vídeo é um fluxo (stream) televisivo transmitido ao vivo de forma digital ouanalógica tipicamente codificado em H.264. O fluxo pode ser transportado através dosprotocolos UDP ou TCP sobre redes IP unicast, multicast ou mesh-pull [16] entre os elementos(peers) participantes da rede.O uso de redes P2P para transmissão de áudio e vídeo transforma cada usuário dedeterminada programação em um pequeno provedor de conteúdo que ajudaria na distribuição dopróprio conteúdo recebido. Em outras palavras, cada usuário que esteja baixando uma mídia viastreaming converteria-se em um servidor do mesmo vídeo que estivesse baixando. Dessamaneira, a abordagem P2PTV tira proveito dos recursos, como capacidade de armazenamento elargura de banda entre os usuários, minimizando assim a necessidade da infraestrutura doservidor. O principal atrativo dessa abordagem é a possibilidade de criar uma arquiteturaaltamente escalável, de baixo custo e com o mínimo de infraestrutura dedicada.Existem diversas soluções proprietárias para P2PTV, por exemplo: Joost [12], PPLive[13], SopCast [14]. Desta forma, o middleware precisa suportar uma ou mais destas redes parapoder recuperar vídeo de acordo com o protocolo específico utilizado em cada uma delas.PPLive é uma aplicação P2PTV gratuita que distribui fluxo de TV ao vivo e tambémvídeos gravados, sendo atualmente a maior rede de streaming multimídia P2P existente [18].Embora PPLive não seja uma aplicação de código aberto, um pouco das suas decisões deprojeto são conhecidas. O sistema PPLive é composto por vários canais, cada um formando suaprópria rede sobreposta (rede overlay) de tal forma que o PPLive é composto por múltiplasredes sobrepostas. Os canais estam divididos em categorias, por exemplo, TV, filmes, esportes,etc.Cada nó da rede estabelecida pelo sistema PPLive executa dois protocolos, um pararegistro e coleta de nós parceiros e outro para distribuição de vídeo. Os parceiros podem ser dedois tipos: ―candidatos‖ e ―reais‖. Os parceiros reais são utilizados para a troca de fluxo devídeo, já os parceiros candidatos são utilizados para substituir parceiros reais que tenham setornado inativos. A fim de se conectar na rede, um nó PPLive executa os seguintes passos: (1)Recupera a lista de canais de um servidor de gerenciamento de canais (via HTTP), (2) para ocanal escolhido, recupera um conjunto de nós do servidor de membros, (3) utiliza esta listainicial para coletar parceiros candidatos.O SopCast nasceu como um projeto na universidade de Fundan, na China. O clienteSopCast tem múltiplas opções de canais e assim como no PPLive, cada canal forma sua própriarede P2P sobreposta e transmite vídeos no formato Windows Media Video ou Real Video.123

O processo de conexão do SopCast também é bastante semelhante ao processo deconexão do PPLive, primeiramente o cliente SopCast se conecta ao servidor de canais pararecuperar uma lista de canais disponíveis. Uma vez escolhido um canal, o cliente mandarequisições para múltiplos servidores raiz (trackers) (semelhante ao servidor de membros de umcanal no PPLive) para recuperar uma lista de nós disponíveis para o canal escolhido. Os nós darede possuem pais e filhos, sendo que o vídeo é sempre recuperado de um nó pai a partir derequisições iniciadas pelo nó filho. Desta forma, cada nó pai notifica periodicamente quaispedaços de vídeo ele possui disponível [19].12 Modelo de FeaturesCom base no estudo apresentado nas seções anteriores, é possível refinar o modelo defeatures previamente especificado como parte do presente projeto [22], de forma a representaras variações específicas relacionadas a IPTV, InternetTV e P2PTV. A Figura 33 ilustra o trechodo modelo de features que foi refinado.Figura 33: Modelo de features para a feature IPA feature IP representa um sintonizador (Tuner) IP. Abaixo da feature IP temos asfeatures opcionais IPTV, InternetTV e P2PTV. De acordo com o modelo de featuresapresentado na A Figura 33, se a feature IPTV for selecionada, tem-se a opção de escolha dasfeatures opcionais H.323 (ITU) ou de SIP (IETF). Independentemente da utilização darecomendação H.323 (ITU) ou de SIP (IETF), o protocolo RTP é sempre utilizado paratransmissão do fluxo de áudio e vídeo de tal forma que a feature RTP é obrigatória Comrelação a InternetTV, o middleware deve recuperar vídeos a partir de requisições HTTP, daí apresença da feature obrigatória HTTP. Por fim, para P2PTV, identifica-se um conjunto de124

soluções de tal forma que para prover suporte a P2PTV, o middleware deve ser capaz de secomunicar em uma ou mais redes P2P existentes atualmente, no modelo de features da Figura33 temos representadas três features opcionais: Joost, PPLive e SopCast.125

Referências[1] Multimedia Research Group. Disponível em:http://www.mrgco.com/press_releases.html#GFU_PR_100605. Acesso em: outubro 2009.[2] International Telecommunication Union, Disponível em:http://www.itu.int/en/pages/default.aspx. Acesso em: outubro 2009.[3] Internet Engineering Task Force. Disponível em: http://www.ietf.org/. Acesso em:outubro 2009.[4] GNU GateKeeper. Disponível em: http://www.gnugk.org/. Acesso em: outubro 2009[5] Microsoft NetMeeting. Disponível em:http://en.wikipedia.org/wiki/Microsoft_NetMeeting. Acesso em: outubro de 2009[6] Tanenbaum, A. Redes de Computadores. Editora Campus, 2003.[7] BBC IPlayer. Disponível em: http://www.bbc.co.uk/iplayer/. Acesso em: outubro 2009.[8] Hulu. Disponível em: http://www.hulu.com/. Acesso em: outubro 2009.[9] Globo Vídeos. Disponível em: http://video.globo.com. Acesso em: outubro 2009.[10] Miro. Disponível em: http://www.getmiro.com/. Acesso em: outubro 2009.[11] Adobe Flash Player. Disponível em: http://www.adobe.com/products/flashplayer/.Acesso em: outubro 2009.[12] Joost. Disponível em: http://www.joost.com/. Acesso em: outubro 2009.[13] PPLive. Disponível em: http://www.pplive.com/en/. Acesso em: outubro 2009.[14] SopCast. Disponível em: http://www.sopcast.com/. Acesso em: outubro 2009.[15] Liesenborgs, J.Voice over IP in Networked Virtual Environments. B.A. thesis, School forKnowledge Technology, Limburgs Universitair Centrum, Belgium, 2000. Available:http://lumumba.luc.ac.be/jori/thesis/thesis.html.[16] Xiaojun Hei, Chao Liang, Jian Liang, Yong Liu, and Keith W. Ross. A measurement studyof a large-scale p2p iptv system. Multimedia, IEEE Transactions on, 2007.[17] RTP: A Transport Protocol for Real-Time Applications. RFC 3550. Disponível em:http://tools.ietf.org/html/rfc3550. Acesso em: outubro 2009.[18] Long Vu, Indranil Gupta, Jin Liang, Klara Nahrstedt. Mapping the PPLive Network:Studying the Impacts of Media Streaming on P2P Overlays. University of Illinois at Urbana-Champaign - Technical Report, 2006.126

[19] Fallica, B.; Yue Lu; Kuipers, F.; Kooij, R.; Van Mieghem, P.; On the Quality ofExperience of SopCast. The Second International Conference on Next Generation MobileApplications, Services and Technologies, pp 501-506. 2008.[20] RSS Advisory Board. RSS 2.0 Specification. Disponível em: http://www.rssboard.org/rssspecification. Acesso em: outubro de 2009.[21] Hypertext Transfer Protocol – HTTP/1.1. RFC 2616. Disponível em:http://www.ietf.org/rfc/rfc2616.txt. Acesso em: outubro de 2009.[22] Thais Batista, et al. Relatório Técnico – Especificação do Modelo Compartilhado e doModelo de Variabilidades para o GingaCC a partir da Análise de sua Arqutietura.ProjetoGingaForAll, 2009.127

Apêndice A1. Aplicando ConejeroNesta seção apresentamos em detalhes a aplicação da abordagem de Conejero [15],explicada na Seção 2.2.2.1, do terceiro entregável denominado Processo de desenvolvimentopara Linha de Produtos Ginga, para identificação das possíveis features transversais no Ginga.De uma forma geral as features transversais do Ginga podem ser identificadas a partir daconstrução de uma matriz de dependência que mostra o relacionamento entre os casos de uso eas features do sistema, e a partir de simples operações matriciais sobre essa matriz dedependência, pode-se obter uma matriz de transversalidade que mostrará as features candidatasa serem implementadas por aspectos.A análise de Conejero [15] está dividida em cinco fases: (i) análise orientada a features,(ii) elicitação dos requisitos não funcionais, (iii) modelagem dos requisitos, (iv) construção dasmatrizes de dependência, e (v) construção de uma matriz de transversalidade. As subseçõesdetalham cada fase desta análise no contexto Ginga.1.1 Análise orientada a featuresA análise orientada a features é uma metodologia de análise de domínio, na qual seidentificam as características comuns do domínio da aplicação. Durante a essa fase, ascaracterísticas comuns e as variabilidades são representadas em termos de features. Uma featureé um conceito proeminente que é visível aos envolvidos no desenvolvimento das aplicaçõese/ou aos usuários. Para expor o conjunto de features identificadas, a análise orientada a featuresutiliza o conceito de modelo de features. Um modelo de features é um representação gráfica dascaracterísticas comuns (obrigatórias), alternativas e opcionais de forma a permitir o melhorgerenciamento das mesmas. A Figura 34 mostra o modelo de features explicado no segundoentregável denominado Especificação do modelo compartilhado e do modelo de variabilidadespara o GingaCC a partir da análise de sua arquitetura.128

Figura 34: Modelo do Features129

Use Cases1.2 Elicitação dos requisitos não funcionaisEsta fase visa identificar os requisitos não funcionais envolvidos no Ginga. Osrequisitos não funcionais são aqueles que expressam como o sistema deve se comportar e, emgeral, estão relacionados com padrões de qualidade como confiabilidade, desempenho, robustez,etc. Para o Ginga foram encontrados os requisitos não funcionais ―Segurança de Aplicação‖,―Desempenho‖ e ―Persistência‖, porém inicialmente o requisito de desempenho não serátratado.1.3 Modelagem dos requisitosNesta fase, é realizada a modelagem dos requisitos através da representação dos casosde usos de forma a montar a representação do sistema de acordo com seus requisitos. Osrequisitos encontrados no Ginga estão representados na Tabela 21. Nessa tabela é possível ver alista de casos de usos encontrados durante a análise.Tabela 21: Lista com os Casos de uso encontrados no GingaSelecionar e Receber TSSintonizar CanalMudar CanalVarrer CanaisControlar Restrições de ConteúdoSeparar TS em Fluxos ElementaresCarregar, configurar, instanciar e executar aplicaçõesControlar Falhas da aplicaçãoAutenticação de aplicaçãoControle de AcessoProcessar dados de multimídiaProcessar Streams de DadosProver Stream de Dados para outros componentesGerenciar Eventos de Entrada130

Enviar e receber Dados via Canal de IteratividadePersistir Arquivo1.4 Identificando os conceitos transversaisConejero define os conceitos de entrelaçamento, espalhamento e transversalidadeatravés de um mapeamento entre uma entidade fonte e uma entidade alvo. O espalhamentoocorre quando um elemento fonte está relacionado com vários elementos alvos. Oentrelaçamento ocorre quando um elemento alvo é relacionado a vários elementos fontes. Dessamaneira, define-se como conceito transversal todo e qualquer conceito que está entrelaçado eespalhado pelo código da aplicação.1.4.1 Construção de uma matriz de dependênciaUma vez identificadas as features do produto (incluindo os requisitos não funcionais) emodelados os requisitos, pode-se usar essas informações para construir uma matriz dedependência. Uma matriz de dependência representa a relação entre uma determinada fonte(source) que influenciam um determinado alvo (target).Para o Ginga serão construídas duas matrizes de dependência: a matriz de espalhamentoe a matriz de entrelaçamento.A matriz de espalhamento representa a relação de dependência entre asfeatures (linhas) e os casos de uso (colunas).A matriz de entrelaçamento representa a relação de dependência entre oscasos de uso (colunas) e as features representadas no modelo de features(linhas).As tabelas 22 e 23 mostram respectivamente a matriz de espalhamento e a matriz deentrelaçamento.Tabela 22: Matriz de EspalhamentoCasos de Uso131

FeaturesSelecionar e Receber DadosSintonizar CanalMudar CanalVarrer CanaisControlar Restrições de ConteúdoSeparar TS em Fluxos ElementaresCarregar, configurar, instanciar e executar aplicaçõesControlar Falhas da AplicaçãoAutenticação de aplicaçãoControle de AcessoProcessar dados de multimídiaProcessar Streams de DadosProver Stream de Dados para outros componentesGerenciar Eventos de EntradaEnviar e receber Dados via Canal de IteratividadePersistir ArquivoTuner – Terrestre 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0Tuner – Sattelite 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0Tuner - File System 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0Tuner – IPTV 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0Tuner - P2PTV 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0Tuner – InternetTV 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0Acesso Condicional 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0Demultiplexer – Hardware 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0Demultiplexer – Software 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0Application Manager -NCL_LUA Basic 0 0 0 0 0 0 1 1 0 0 0 0 0 0 0 0Application Manager -NCL_LUA_complementar 0 0 0 0 0 0 1 1 0 0 0 0 0 0 0 0Application Manager –JAVADTV 0 0 0 0 0 0 1 1 0 0 0 0 0 0 0 0Application Manager – GEM 0 0 0 0 0 0 1 1 0 0 0 0 0 0 0 0Media Processing 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0Data Processing - Atualizaçãodo Software 0 0 0 0 0 0 0 0 0 0 0 1 1 0 0 0Data Processing - MontagemAplicação 0 0 0 0 0 0 0 0 0 0 0 1 1 0 0 0Input Manager – Mouse 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0Input Manager – Teclado 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0Input Manager - ControleRemoto – IR 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0Input Manager – BlueTooth 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0Return Channel - Dial-UP 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0132

NFR´sReturn Channel – Ethernet 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0Return Channel - 3G 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0Return Channel – ISDN 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0Return Channel – ADSL 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0Persistência 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1Segurança de aplicações 0 1 1 0 0 0 0 0 1 1 0 0 0 0 1 1Na matriz de espalhamento mostrada na Tabela 22, as linhas representam arelação de dependência entre as features e requisitos não funcionais (representados pelasigla NFR´s de requisitos não funcionais) com os casos de uso.Por sua vez, a matriz de entrelaçamento as linhas representam a relação dedependência entre os casos de uso com as features e requisitos não funcionais.133

Casos de UsosTuner – TerrestreTuner - SatteliteTuner - File SystemTuner - IPTVTuner - P2PTVTuner - InternetTVAcesso CondicionalDemultiplexer - HardwareDemultiplexer - SoftwareApplication Manager - NCL_LUA BasicApplication Manager - NCL_LUA_complementarApplication Manager - JAVADTVApplication Manager -GEMMedia ProcessingData Processing - Atualização do SoftwareData Processing - Montagem AplicaçãoInput Manager - MouseInput Manager - TecladoInput Manager - Controle Remoto - IRInput Manager - BlueToothReturn Channel - Dial-UPReturn Channel - EthernetReturn Channel - 3GReturn Channel - ISDNReturn Channel - ADSLPersistenciaSeguranca de aplicaçoesTabela 23: Matriz de EntrelaçamentoFeaturesNFR´sSelecionar e Receber TS 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0Sintonizar Canal 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0Mudar Canal 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0Varrer Canais 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0Controlar Restrições de 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0ConteudoSeparar TS em Fluxos 0 0 0 0 0 0 0 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0ElementaresCarregar, configurar,instanciar e executar0 0 0 0 0 0 0 0 0 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0

aplicaçõesControlar Falhas da 0 0 0 0 0 0 0 0 0 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0aplicaçãoAutenticação de aplicação 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1Controle de Acesso 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1Processar dados de 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0multimídiaProcessar Streams de 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 0 0 0 0 0 0 0 0 0 0 0DadosProver Stream de Dados 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 0 0 0 0 0 0 0 0 0 0 0para outros componentesGerenciar Eventos de 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 0 0 0 0 0 0 0EntradaEnviar e receber Dados via 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 0 0Canal de IteratividadePersistir Arquivo 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 01.4.2 Construção de uma matriz de transversalidadeApós a criação das matrizes de entrelaçamento e espalhamento, é construída a matriz de transversalidade a partir da multiplicação entre essas matrizes,ou seja, mTrans [i][k] = mEsp [i][j] * mEntr [j][k], onde mTrans é a matriz de transversalidade, mEsp é a matriz de espalhamento e mEntr é a matriz deentrelaçamento. O resultado da multiplicação da matriz de entrelaçamento (Tabela 23) e da matriz de espalhamento (Tabela 22 ) resulta na matriz detransversalidade mostrada na Tabela 24.Tabela 24: Matriz de transversalidadeFeaturesNFR´s135

FeaturesTuner – TerrestreTuner - SatteliteTuner - File SystemTuner - IPTVTuner - P2PTVTuner – InternetTVAcesso CondicionalDemultiplexer - HardwareDemultiplexer – SoftwareApplication Manager - NCL_LUA BasicApplication Manager - NCL_LUA_complementarApplication Manager - JAVADTVApplication Manager -GEMMedia ProcessingData Processing - Atualização do SoftwareData Processing - Montagem AplicaçãoInput Manager – MouseInput Manager - TecladoInput Manager - Controle Remoto - IRInput Manager - BlueToothReturn Channel - Dial-UPReturn Channel - EthernetReturn Channel - 3GReturn Channel - ISDNReturn Channel - ADSLPersistênciaSeguranca de aplicaçõesTuner – Terrestre 0 4 4 4 4 4 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0Tuner – Sattelite 4 0 4 4 4 4 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0Tuner - File System 4 4 0 4 4 4 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0Tuner – IPTV 4 4 4 0 4 4 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0Tuner - P2PTV 4 4 4 4 0 4 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0Tuner – InternetTV 4 4 4 4 4 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0Acesso Condicional 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0Demultiplexer - Hardware 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0Demultiplexer - Software 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0Application Manager -NCL_LUA Basic 0 0 0 0 0 0 0 0 0 0 2 2 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0Application Manager - 0 0 0 0 0 0 0 0 0 2 0 2 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0136

NFR´sNCL_LUA_complementarApplication Manager -JAVADTV 0 0 0 0 0 0 0 0 0 2 2 0 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0Application Manager -GEM 0 0 0 0 0 0 0 0 0 2 2 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0Media Processing 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0Data Processing -Atualização do Software 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 2 0 0 0 0 0 0 0 0 0 0 0Data Processing -Montagem Aplicação 0 0 0 0 0 0 0 0 0 0 0 0 0 0 2 0 0 0 0 0 0 0 0 0 0 0 0Input Manager - Mouse 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 0 0 0 0 0 0 0Input Manager - Teclado 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 1 0 0 0 0 0 0 0Input Manager - ControleRemoto - IR 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 0 1 0 0 0 0 0 0 0Input Manager - BlueTooth 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 0 0 0 0 0 0 0 0Return Channel - Dial-UP 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 0 0Return Channel - Ethernet 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 1 1 0 0Return Channel - 3G 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 0 1 1 0 0Return Channel - ISDN 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 0 1 0 0Return Channel - ADSL 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 0 0 0Persistência 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0Segurança de aplicações 2 2 2 2 2 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 0137

FeaturesTunerAcesso CondicionalDemultiplexerApplication ManagerMedia ProcessingData ProcessingInput ManagerReturn ChannelPersistênciaSegurança de aplicaçõesNa matriz de transversalidade mostrada na Tabela 24, a presença de números diferente de zeroem uma célula da matriz denota a ocorrência de transversalidade da feature da linha em relação afeature da coluna. Por exemplo, o requisito Segurança de aplicações é transversal as features doTuner. Para visualização das transversalidades foram retirados os relacionamentos entre as mesmasfeatures.A partir da Tabela 24 foi possível encontrar features transversais tanto nas variabilidades doproduto, como o Tuner – InternetTV em relação ao Tuner - P2PTV, assim como em partes nãovariaveis do produto, como o requisito de segurança com relação ao Tuner – InternetTV.Com o objetivo de facilitar o entendimento dos interesses transversais do Ginga, foi criada outramatriz de transversalidade mostrando o relacionamento entre as features e os componentes do Ginga.A Tabela 25 mostra essa matriz. Nas linhas da matriz mostra-se as features e nas colunas oscomponentes. Nessa tabela a ocorrência de um número diferente de zero em uma célula indica queuma feature da linha está implementada no componente da coluna.Tabela 25: Matriz de Transversalidade features x ComponentesComponentesTuner – Terrestre 1 0 0 0 0 0 0 0 0 0Tuner – Sattelite 1 0 0 0 0 0 0 0 0 0Tuner - File System 1 0 0 0 0 0 0 0 0 0Tuner – IPTV 1 0 0 0 0 0 0 0 0 0Tuner - P2PTV 1 0 0 0 0 0 0 0 0 0Tuner – InternetTV 1 0 0 0 0 0 0 0 0 0Acesso Condicional 0 1 0 0 0 0 0 0 0 0Demultiplexer – Hardware 0 0 1 0 0 0 0 0 0 0Demultiplexer – Software 0 0 1 0 0 0 0 0 0 0Application Manager - NCL_LUA Basic 0 0 0 1 0 0 0 0 0 0Application Manager - NCL_LUA_complementar 0 0 0 1 0 0 0 0 0 0Application Manager – JAVADTV 0 0 0 1 0 0 0 0 0 0Application Manager – GEM 0 0 0 1 0 0 0 0 0 0Media Processing 0 0 0 0 1 0 0 0 0 0Data Processing - Atualização do Software 0 0 0 0 0 1 0 0 0 0Data Processing - Montagem Aplicação 0 0 0 0 0 1 0 0 0 0Input Manager – Mouse 0 0 0 0 0 0 1 0 0 0Input Manager – Teclado 0 0 0 0 0 0 1 0 0 0

NFR´sInput Manager - Controle Remoto – IR 0 0 0 0 0 0 1 0 0 0Input Manager – BlueTooth 0 0 0 0 0 0 1 0 0 0Return Channel - Dial-UP 0 0 0 0 0 0 0 1 0 0Return Channel – Ethernet 0 0 0 0 0 0 0 1 0 0Return Channel - 3G 0 0 0 0 0 0 0 1 0 0Return Channel – ISDN 0 0 0 0 0 0 0 1 0 0Return Channel – ADSL 0 0 0 0 0 0 0 1 0 0Persistência 0 0 0 0 0 0 0 0 1 0Segurança de aplicações 1 0 0 0 0 0 0 1 1 1Na Tabela 25 quando uma linha é composta por células com valor ―um‖ significa que afeature ou requisito não-funcional da linha é transversal ao componente da coluna, ou seja, estáespalhado e entrelaçado dentro do componente, e se nesta linha forem encontradas varias células comeste valor significa que esta feature ou requisito não-funcional é transversal a vários componentes.Com isso a partir dos resultados mostrados nas matrizes de transversalidade feature x feature(Tabela 24) e feature x componentes (Tabela 25), foi possível identificar interesses transversais, tantonas variabilities, quanto nas commonalities do Ginga. Nas commonalities foi encontrada afuncionalidade ―segurança de aplicações‖ espalhada e entrelaçada em várias outros features e emvários componentes. Com relação as variabilities foi mostrado que todas as features podem sermodularizadas como aspecto, porém cabe ao engenheiro de software decidir quais dessas seriammelhor modularizadas como aspectos, por exemplo a feature demultiplexer não seria bemmodularizado com aspectos devido a sua variabilidade depender de hardware ou software.139