Uma solução de linha de produtos de software baseada em componentes e aspectos para o domínio de E-commerce

(1)

Universidade Estadual de Campinas Instituto de Computação

INSTITUTO DE COMPUTAÇÃO

Raphael Porreca Azzolini

Uma Solução de Linha de Produtos de Software

Baseada em Componentes e Aspectos para o Domínio

de E-commerce

CAMPINAS

2015

(2)

Raphael Porreca Azzolini

Uma Solução de Linha de Produtos de Software Baseada em

Componentes e Aspectos para o Domínio de E-commerce

Dissertação apresentada ao Instituto de Computação da Universidade Estadual de Campinas como parte dos requisitos para a obtenção do título de Mestre em Ciência da Computação.

Orientadora: Profa. Dra. Cecília Mary Fischer Rubira

Este exemplar corresponde à versão nal da Dissertação defendida por Raphael Porreca Azzolini e orientada pela Profa. Dra. Cecília Mary Fischer Rubira.

CAMPINAS

2015

(3)

Agência(s) de fomento e nº(s) de processo(s): Não se aplica.

Ficha catalográfica

Universidade Estadual de Campinas

Biblioteca do Instituto de Matemática, Estatística e Computação Científica Maria Fabiana Bezerra Muller - CRB 8/6162

Azzolini, Raphael Porreca,

Az98s AzzUma solução de linha de produtos de software baseada em componentes e aspectos para o domínio de E-commerce / Raphael Porreca Azzolini. –

Campinas, SP : [s.n.], 2015.

AzzOrientador: Cecília Mary Fischer Rubira.

AzzDissertação (mestrado) – Universidade Estadual de Campinas, Instituto de Computação.

Azz1. Engenharia de software. 2. Linhas de produto de software. 3. Comércio eletrônico. 4. Software - Arquitetura. I. Rubira, Cecília Mary Fischer,1964-. II. Universidade Estadual de Campinas. Instituto de Computação. III. Título. Informações para Biblioteca Digital

Título em outro idioma: A software products line solution based in components and

aspects for the E-commerce domain

Palavras-chave em inglês:

Software engineering Software product lines E-commerce

Software - Architecture

Área de concentração: Ciência da Computação Titulação: Mestre em Ciência da Computação Banca examinadora:

Cecília Mary Fischer Rubira [Orientador] Heiko Horst Hornung

Daniel Lucrédio

Data de defesa: 12-11-2015

Programa de Pós-Graduação: Ciência da Computação

(4)

Universidade Estadual de Campinas Instituto de Computação

INSTITUTO DE COMPUTAÇÃO

Raphael Porreca Azzolini

Uma Solução de Linha de Produtos de Software Baseada em

Componentes e Aspectos para o Domínio de E-commerce

Banca Examinadora:

• Profa. Dra. Cecília Mary Fischer Rubira Instituto de Computação - UNICAMP • Prof. Dr. Heiko Horst Hornung

Instituto de Computação - UNICAMP • Prof. Dr. Daniel Lucrédio

Departamento de Computação - UFSCar

A ata da defesa com as respectivas assinaturas dos membros da banca encontra-se no processo de vida acadêmica do aluno.

(5)

Abstract

Software Product Line engineering is a technique that explores systematic reuse of soft-ware artifacts in large scale to implement applications that share a common domain and have some customized features. For improving Product Line Architecture evolution, it is advisable to develop Software Product Lines using a modular structure. This demand can be satised by a method that integrates components, aspects and variation point connectors. This approach allows minimization of feature scattering in the architectural model and supports modular modelling of crosscutting features. In this work, a case study mapping major features of signicant e-commerce systems operating in Brazil and other countries was performed to evaluate this approach. The assessment of this solution was performed comparing its stability and modularity with other two approaches. The results indicate that change impact in the architectural model is reduced when using the proposed solution in the context of Software Product Lines evolution.

(6)

Resumo

Linha de Produto de Software é uma técnica que explora sistematicamente o reúso de artefatos de software em larga escala para implementar aplicações que compartilham um domínio comum e possuem algumas características customizáveis. Para aperfeiçoar a evolução da Arquitetura da Linha de produto, é aconselhável desenvolver Linhas de Produto de Software utilizando uma estrutura modular. Esta demanda pode ser realizada por um método que integra componentes, aspectos e conectores de pontos de variação. Esta abordagem permite a minimização do espalhamento de características no modelo arquitetural e suporta de maneira modular a modelagem de características entrecortantes. Neste trabalho, um estudo de caso mapeando as principais características de importantes sistemas de e-commerce operando no Brasil e em outros países foi realizado para avaliar esta abordagem. A análise desta solução foi realizada comparando-se sua estabilidade e modularidade com as de outras duas abordagens. Os resultados indicam que o impacto no modelo arquitetural é reduzido quando utilizando a solução proposta no contexto da evolução de Linhas de Produto de Software.

(7)

Lista de Figuras

2.1 Representação de um componente em UML 2.4 . . . 18

2.2 Interesses de um sistema de e-commerce . . . 18

2.3 Módulos com espalhamento . . . 19

2.4 Módulos sem espalhamento, devido a utilização de aspecto . . . 19

2.5 Representação de dois componentes sendo interligados por um connector-VP 21 2.6 Modelo de componentes do COSMOS*-VP detalhado . . . 22

2.7 O modelo de característica para um pedido de um sistema de e-commerce . 23 2.8 Transformações do método AO-FArM . . . 25

2.9 Renamento da arquitetura no método AO-FArM . . . 26

2.10 Como os relacionamentos entre componentes são representados na arquite-tura da LPS [48] . . . 27

2.11 Diagrama da solução para implementação de LPSs com componentes, as-pectos e VP-connectors . . . 31

2.12 Diagrama de atividades do processo tradicional de compra no sistema de e-commerce . . . 32

2.13 Protocolo de pagamento com cartão de crédito . . . 33

2.14 Protocolo de pagamento com cartão de crédito com análise de risco . . . . 34

3.1 Relação da LPS com o container EJB . . . 36

3.2 Modelo de acesso direto ao servidor de aplicação . . . 37

3.3 Modelo de arquitetura de multi-camadas . . . 38

3.4 Modelo de arquitetura de multi-camadas com múltiplos bancos de dados . 39 4.1 Execução do estudo de caso . . . 42

4.2 Modelo de características inicial . . . 43

4.3 (a) Modelo de características parcial após a primeira transformação do AO-FArM, em azul as características que foram transformadas; (b) Modelo de características parcial após a segunda transformação do AO-FArM, em vermelho as características que foram adicionadas . . . 52

4.4 Modelo de relacionamento entre as características . . . 53

4.5 Modelo de relacionamento hierárquico entre as características . . . 54

4.6 Componente de pedido conectado a pagamento e forma de envio . . . 55

4.7 Componente de pedido detalhado . . . 55

4.8 Os componentes de produto e promoção sendo conectados por um VP-connector . . . 56

4.9 Os componentes de produto e promoção sendo conectados por um VP-connector . . . 57

4.10 Modelo de características com tratamento de exceções . . . 58

(8)

4.12 Módulos adicionados e modicados . . . 59

4.13 Operações adicionadas e modicadas . . . 60

4.14 O acoplamento médio dos módulos após as alterações na LPS . . . 60

4.15 O espalhamento das características após as alterações na LPS . . . 61

4.16 O entrelaçamento das características após as alterações na LPS . . . 61

A.1 Página inicial . . . 70

A.2 Resultado da busca de texto . . . 71

A.3 Detalhes do produto . . . 72

A.4 Carrinho de compras . . . 73

(9)

Lista de Tabelas

4.1 Implementações do Estudo de Caso . . . 45 4.2 Resumo dos cenários de evolução da Mercurius-SPL . . . 46

(10)

Sumário

1 Introdução 12

1.1 Problema . . . 13

1.2 Solução Proposta . . . 14

1.3 Trabalhos Relacionados . . . 15

1.4 Organização deste Trabalho . . . 16

2 Fundamentos Teóricos 17 2.1 Desenvolvimento Baseado em Componentes . . . 17

2.2 Desenvolvimento Orientado a Aspectos . . . 18

2.3 Uso Integrado de Componentes e Aspectos . . . 20

2.4 Linha de Produtos de Software . . . 20

2.4.1 Variabilidade de Software . . . 22

2.4.2 Modelo de Características . . . 23

2.4.3 Mapeamento de Características para Elementos Arquiteturais . . . 24

2.5 Domínio de E-commerce . . . 28

2.5.1 Fluxo de Compra . . . 29

2.5.2 Protocolos de Pagamento . . . 29

3 Implementação de Sistemas de E-commerce 35 3.1 Ferramentas de Implementação . . . 35

3.2 Servidor de Aplicação . . . 37

4 Estudo de Caso: Mercurius SPL 40 4.1 Apresentação . . . 40

4.2 Contexto do Estudo de Caso . . . 41

4.3 Planejamento do Estudo de Caso . . . 41

4.4 Execução do Estudo de caso . . . 42

4.4.1 Implementação do Código . . . 45

4.5 Análise e Interpretação de Dados . . . 47

4.5.1 Impacto de Mudanças . . . 48

4.5.2 Modularidade com a evolução da arquitetura . . . 49

4.6 Discussão . . . 50

4.7 Resumo . . . 51

5 Conclusões e Trabalhos Futuros 62 5.1 Ameaças à Validade . . . 63

5.2 Contribuições . . . 63

5.3 Publicações . . . 64

(11)

Referências Bibliográcas 65

(12)

Capítulo 1

Introdução

Atualmente existe uma grande demanda por produtos de software, cujos prazos de senvolvimento são curtos, exigem alta qualidade e possuem grande complexidade de de-senvolvimento. A engenharia de software baseada em reúso foi proposta para atender a essas necessidades, ela proporciona diminuição dos custos de produção e manutenção de software, entregas rápidas do produto nal e crescimento da qualidade de software [45].

Engenharia de software baseada em reúso é uma estratégia onde o processo de de-senvolvimento é realizado utilizando software já existente. Embora esta estratégia de desenvolvimento tenha sido proposta em 1968, apenas nos anos 2000 o desenvolvimento com reúso se tornou uma norma para novos sistemas de negócio [45]. Hoje, cada vez mais companhias estão promovendo o reúso para trazer crescimento aos seus investimentos em software.

A linha de produtos de software (LPS) é uma das abordagens da engenharia de software baseada em reúso. Ela proporciona, por meio de um conjunto de aplicações com uma arquitetura em comum, o desenvolvimento de aplicações com diferentes requisitos de sistemas. Apesar de a LPS possuir uma estrutura modular, a inecácia dos mecanismos de variabilidade para acomodar alterações pode levar a várias consequências indesejáveis à sua estabilidade [16].

Entre os diversos paradigmas que podem ser utilizados para apoiar a evolução de uma LPS, podemos destacar o desenvolvimento de software baseado em componentes [46] e o desenvolvimento de software orientado a aspectos [30]. O primeiro desenvolve os sistemas por meio de componentes de software, oferecendo maior separação entre especicação e implementação do componente, o que favorece a reutilização através da redução de aco-plamento. O segundo permite a separação de interesses nas fases de análise de requisitos, projeto arquitetural e implementação de sistemas [48], oferecendo suporte a variabilidade de características1 _{e prolongando a estabilidade da LPS [16].}

A separação de interesses pode conduzir a uma melhor modularização de requisitos com objetivos semelhantes, oferecendo maior coesão nas diferentes partes do sistema de software, pois cada parte irá encapsular funcionalidades associadas a uma característica especíca do sistema. Característica é uma propriedade do domínio ou uma qualidade

1_{do inglês, features}

(13)

CAPÍTULO 1. INTRODUÇÃO 13

visível ao usuário. A estabilidade de um projeto de software sustenta a modularidade de uma LPS na presença de alterações de seu núcleo e características.

Características transversais representam os interesses2 _{que afetam diversos outros} in-teresses do sistema, podendo provocar um impacto amplo no sistema quando forem al-teradas. Devido a esse impacto, a remoção, inclusão ou alteração desses interesses pode trazer consequências indesejadas a várias partes do sistema. Portanto, visando diminuir os impactos destas mudanças, é importante a implementação modular de características transversais.

A evolução da arquitetura de uma linha de produtos pode ser dicultada pela vari-abilidade arquitetural, que difere arquiteturas de linhas de produtos de arquiteturas de sistemas únicos por reetir a existência de alternativas de projeto arquitetural [48]. Caso a variabilidade arquitetural seja mal modularizada, haverá um espalhamento de caracte-rísticas na arquitetura, o que pode complicar o desenvolvimento, evolução e manutenção do sistema.

No trabalho de Tizzei [48] é proposta uma solução que apoia o desenvolvimento de LPSs com o uso integrado de componentes, aspectos e conectores de pontos de varia-ção, chamados de VP-connectors. Uma das contribuições desse trabalho foi o modelo COSMOS*-VP que tem como objetivo apoiar a evolução de arquiteturas de LPSs usando duas estratégias: modularizando a variabilidade arquitetural para minimizar seu espa-lhamento na arquitetura e apoiando a modelagem e implementação de características transversais de forma modular.

Este trabalho apresenta o desenvolvimento de uma LPS para o domínio de e-commerce utilizando uma arquitetura composta de componentes, aspectos e conectores de pontos de variação. Este domínio foi escolhido pelo fato de ser um domínio representativo da Web onde suas aplicações requerem variantes a serem implementadas que são similares, porém customizáveis de acordo com as necessidades das companhias que o implementam, o que torna natural a adoção da estratégia de LPS para este domínio [31].

O domínio de e-commerce está em forte ascensão no mercado global. Em 2014, as expectativas do crescimento mundial de vendas em sistemas de e-commerce era de aproxi-madamente 20%, chegando a $1.471 trilhões de vendas de Businnes-to-Consumer (B2C) [13].

No Brasil, o crescimento de seu mercado nos últimos 10 anos foi de 1400% [15]. As aplicações desse domínio possuem diversas características em comum que, com a neces-sidade de aumento da qualidade e diminuição dos custos de desenvolvimento devido ao crescimento da área, justica a necessidade de se explorar soluções de LPS para este domínio.

1.1 Problema

Clements e Northrop [7] denem uma LPS como um conjunto de sistemas que comparti-lham características em comum, mas que possuem características distintas entre si para satisfazer um determinado segmento do mercado. Usando esse conjunto de sistemas e

(14)

aplicando o reúso de software é possível desenvolver produtos customizados por um custo baixo [38]. Porém, apesar dessas vantagens, a evolução de uma LPS pode ser prejudicada pela ineciência dos mecanismos de variabilidade para tratar as alterações do sistemas, podendo levar a consequências de estabilidade indesejáveis [16].

Um exemplo dos problemas de evolução de uma LPS é a adição de características opcionais, que podem ou não estar nos produtos de software da LPS. No domínio de e-commerce, por exemplo, a adição de uma nova funcionalidade de promoção de produtos, que é opcional, afeta diversas outras funcionalidades que calculam os preços de produtos e o valor total do pedido. Caso não sejam utilizadas técnicas ecientes de variabildiade, essa nova funcionalidade pode ser implementada de uma forma em que é impossível removê-la de algum produto da linha, mesmo ela sendo opcional, ou pior, a sua ausência nos produtos da LPS pode afetar o cálculo do valor total do pedido, causando graves consequências para o sistema.

No trabalho de Tizzei [48] é proposta uma solução que apoia o desenvolvimento de LPSs com o uso integrado de componentes, aspectos e conectores de pontos de variação, chamados de VP-connectors. Esta solução apoia a estabilidade da arquitetura da linha de produto (ALP), modularizando os interesses transversais. Esta solução foi avaliada em um pequeno estudo de caso, onde foram comparados dois tipos de implementação: uma utilizando os conceitos dos VP-connectors, aspectos e componentes; outra usando uma abordagem de componentes puros. Como consequência, o estudo não pôde identicar os benefícios individuais do uso dos VP-connectors quando comparados com uma imple-mentação que utiliza apenas componentes e aspectos. Outra contribuição deste trabalho foi o AO-FArM (Aspect Oriented Feature Architecture Method), criado para mapear as características de uma LPS para o modelo arquitetural de componentes, aspectos e VP-connectors [48]. Este modelo é uma extensão do FArM (Feature Architecture Method) [43].

Apesar de apresentar resultados promissores, essa solução foi aplicada apenas em pe-quenos domínios que não possuem características de produtos com relevância fora do contexto acadêmico. Portanto, ela ainda precisa ser avaliada em sistemas maiores, que possuem características de sistemas de software reais, que são utilizados no mercado e apresentam maior complexidade de implementação.

1.2 Solução Proposta

O domínio de e-commerce possibilita este tipo de avaliação, pois ele representa um im-portante papel no crescimento econômico da Tecnologia de Informação (TI). Em 2014, as expectativas de crescimento das vendas mundiais de e-commerce, ou vendas Business-to-consumer (B2C), eram de aproximadamente 20%, alcançando $1.471 trilhões de dólares [13]. Outro fator que torna interessante a avaliação da solução com o domínio de e-commerce é esse sistema normalmente ser integrado com outros sistemas, como sistemas de logística e pagamento, o que torna importante um alto nível de segurança. Outro ponto de segurança a ser tratado nesta família de sistemas é a proteção contra acesso

(15)

não autorizado a dados pessoais dos clientes. Além disso, este domínio necessita de uma experiencia de usuário eciente para aumentar a conabilidade dos clientes no sistema [8]. A solução proposta deste trabalho é avaliar a estabilidade arquitetural do COSMOS*-VP no domínio de e-commerce, para isso foi desenvolvida uma LPS open-source, chamada de Mercurius-SPL3 _{[3], disponível em repositório público [19]. Foram extraídas 84} carac-terísticas de sistemas reais disponíveis na Web e de experiência que o autor deste obteve trabalhando durante 3 anos com sistemas de e-commerce.

O estudo de caso desse trabalho consiste na comparação de três diferentes implemen-tações desta LPS: uma implementação baseada em componentes, chamada CBImpl; uma implementação com componentes e aspectos, chamada AO-CBImpl; e uma implementa-ção baseada em componentes, aspectos e VP-connectors, chamada VP-AO-CBImpl e que resultou no Mercurius-SPL. Cada implementação possui quatro releases, num total de 12 releases. Cada release possui cenários de evolução para incluir características obrigató-rias e não-obrigatóobrigató-rias (opcionais e alternativas) na LPS. Foram utilizadas métricas para avaliar o impacto das mudanças (linhas de código, operações adicionadas, operações mo-dicadas, módulos adicionados e módulos modicados) [54] e modularidade (acoplamento médio, espalhamento e entrelaçamento de características) [6] para medir a estabilidade da arquitetura em cada implementação.

A implementação do código das três LPSs durou cerca de 6 meses e foi feita por apenas uma pessoa. Foram implementadas 25 das 84 características extraídas no início do estudo. Os resultados apontam que a VP-AO-CBImpl tende a promover melhor estabilidade da ALP quando comparada com as outras duas implementações avaliadas no estudo, assim como mostram os estudos de Tizzei [48]. Porém, indo além do estudo anterior, este trabalho mostrou também quais são os impactos individuais de aspectos e dos VP-connectors para a estabilidade da ALP, uma vez que foi avaliada a implementação AO-CBImpl, que é uma LPS intermediária entre uma solução com componentes puros e a solução com VP-connectors.

Apesar de ter sido desenvolvida uma LPS para um domínio importante no mercado de TI, ainda não foi possível aplicar o Mercurius-SPL na indústria.

1.3 Trabalhos Relacionados

Laguna e Hernandez [31] apresentam uma LPS de e-commerce desenvolvida na plataforma .NET [34]. Ao contrário deste trabalho de Mestrado, não foram utilizadas nem técnicas de componentes e nem técnicas de aspectos para a implementação da LPS. Além disso, neste trabalho de Mestrado o desenvolvimento foi feito na linguagem Java [36].

Figueiredo et al. [16] fazem uma análise do uso de desenvolvimento orientado a as-pectos (OA) em relação à evolução de LPS. Os autores mostram que o uso de OA pode aumentar a estabilidade da LPS quando mudanças acontecem, com características opci-onais ou alternativas.

Tizzei [48] estende o trabalho de Figueiredo et al. [16] ao analisar também o uso integrado de componentes e aspectos. Uma das contribuições deste trabalho é o

(16)

delo COSMOS*-VP, onde os elementos arquiteturais podem desempenhar dois papéis: transversal ou base. Neste modelo, os componentes transversais utilizam aspectos para modularizar características transversais e os conectores transversais, chamados de VP-connectors, usam mecanismos de aspectos para modularizar as decisões relacionadas a escolhas de produtos.

Este trabalho de Mestrado se relaciona ao de Laguna [31] por também desenvolver uma LPS para o domínio de e-commerce. A diferença entre os trabalhos é o uso de componentes integrados com aspectos, o que não é abordado por Laguna. O trabalho de Figueiredo et al. descreve formas de análise de resultados que são utilizadas neste trabalho. Por m, o trabalho de Tizzei [48] descreve as técnicas de evolução de arquitetura de linhas de produto que foram utilizadas para o desenvolvimento da LPS proposta.

1.4 Organização deste Trabalho

O restante deste trabalho está organizado em quatro capítulos.

O Capítulo 2 apresenta os fundamentos teóricos utilizados para a contextualização do trabalho, são descritos fundamentos de LPS, variabilidade de software, modelo de carac-terísticas, desenvolvimento baseado em componentes, programação orientada a aspectos e do uso integrado de componentes e aspectos; o Capítulo 3 descreve detalhes da imple-mentação das LPS deste trabalho, como ferramentas e técnicas utilizadas; o Capítulo 4 descreve o estudo de caso realizado neste trabalho, é apresentado desde o planejamento até o a execução do estudo, mostrando os resultados obtidos ao nal do estudo; por m, o Capítulo 5 apresenta as conclusões deste estudo.

(17)

Capítulo 2

Fundamentos Teóricos

Este capítulo descreve todos os fundamentos teóricos utilizados nesse trabalho. A Seção 2.1 apresenta os fundamentos do desenvolvimento baseado em componentes. A Seção 2.2 descreve os fundamentos do desenvolvimento orientado a aspectos. A Seção 2.3 apresenta os fundamentos do uso integrado de componentes e aspectos. A Seção 2.4 apresenta os fundamentos de linha de produtos de software, os conceitos básicos sobre o modelo de características e o método que provê diretrizes para especicar arquiteturas de linhas de produtos de software utilizados neste trabalho. Por m, a Seção 2.5 apresenta o domínio de e-commerce.

2.1 Desenvolvimento Baseado em Componentes

O Desenvolvimento Baseado em Componentes (DBC) é uma técnica de desenvolvimento de software que utiliza componentes pré-fabricados para a construção de software. Essa técnica tem como uma das principais metas reduzir o tempo e custo de desenvolvimento de software [46].

No DBC, um sistema pode ser construído por componentes que já foram previamente especicados, construídos, testados e empregados; essa reutilização garante o aumento da qualidade do software construído e o aumento da produtividade na construção de novos sistemas.

Um componente de software é uma unidade composta por interfaces e dependências de contexto explicitamente especicadas. Ele pode ser fornecido isoladamente e interagir com software de terceiros. Um componente é composto por interfaces providas, onde são declarados os serviços oferecidos pelo componente, e interfaces requeridas, onde são declarados os serviços que o componente necessita para funcionar [49]. Na Figura 2.1 é apresentado um exemplo de representação de um componente.

Existe um tipo especial de componente chamado conector, ele pode intermediar o relacionamento entre dois componentes, realizando as adaptações necessárias para adequar a implementação da interface provida de um componente para a interface requerida do outro componente.

(18)

CAPÍTULO 2. FUNDAMENTOS TEÓRICOS 18

Figura 2.1: Representação de um componente em UML 2.4

2.2 Desenvolvimento Orientado a Aspectos

Figura 2.2: Interesses de um sistema de e-commerce

Figura 2.3: Módulos com espalhamento

O desenvolvimento orientado a aspectos é feito a partir da separação de interesses em módulos chamados de aspectos. Interesse é um foco considerado importante por um dos stakeholders num sistema [41]. Interesses podem ser transversais, ou seja, eles podem estar presentes em diversos módulos do software. São exemplos de interesses transversais: persistência de objetos, segurança de acesso, acesso concorrente, entre outros tipos de interesses que não podem ser encapsulados em uma única classe, devendo ser separados em aspectos. A Figura 2.2 apresenta alguns interesses de um sistema de e-commerce, os interesses Persistência, Logging e Segurança são interesses transversais pois estão

(19)

presentes nos outros interesses (Checkout, Login, Cadastro), e podem ser tratados com aspectos.

Figura 2.4: Módulos sem espalhamento, devido a utilização de aspecto

Interesses transversais causam espalhamento na arquitetura, a Figura 2.3 mostra um exemplo desse espalhamento, onde os módulos de Checkout, Login e Cadastro possuem em seu código partes do módulo de Segurança, afetando a estabilidade da LPS, dicul-tando a modicação, adição e remoção de características. O problema de espalhamento pode ser evitado modularizando interesses transversais em aspectos, como mostrado na Figura 2.4, onde as partes do módulo de Segurança que devem ser utilizadas não estão mais nos módulos de Checkout, Login e Cadastro, sendo agora interceptadas pelos outros módulos.

O desenvolvimento orientado a aspectos pode ser feito com AspectJ [47], que é uma extensão orientada a aspectos para Java; ela utiliza todos os recursos da linguagem e acrescenta recursos de Programação Orientada a Aspectos (POA).

2.3 Uso Integrado de Componentes e Aspectos

Com o objetivo de conceber arquiteturas de linha de produto estáveis, minimizando o espalhamento da variabilidade arquitetural e apoiando a modelagem de características transversais de forma modular, Tizzei [48] propôs um modelo de evolução de LPSs com o uso integrado de componentes e aspectos. Esse modelo foi chamado de COSMOS*-VP e é uma evolução do modelo COSMOS* [18] que suporta o desenvolvimento orientado a aspectos, fornecendo diretrizes para especicar connectors-VP e materializar os pontos de variação no código fonte.

O connector-VP é um modelo de conector que tem como objetivo minimizar o espalha-mento dos pontos de variação arquiteturais provendo diretrizes de como implementá-los. Sem ele, o desenvolvedor tem a liberdade de implementar os pontos de variação arquite-turais de forma ad hoc, podendo resultar no espalhamento desses. Outra vantagem do connector-VP é a redução do problema da característica opcional [29]. Esse problema ocorre quando existem características que são ortogonais durante a análise de requisi-tos, mas não no nível da implementação. Um exemplo deste problema é quando duas

(20)

características são opcionais no modelo de características, mas a implementação das ca-racterísticas não é independente.

Um connector-VP tem pelo menos duas interfaces transversais: uma interface de requi-sição e uma de delegação. Uma interface de requirequi-sição requisita serviços de adaptadores do connector-VP, ela é usada pelos componentes base para que componentes transversais os modiquem. Uma interface de delegação é responsável por delegar aos componentes transversais as requisições feitas pelos componentes base, realizando chamadas aos adap-tadores como se estivessem disponibilizando seus serviços para as interfaces de requisição.

Figura 2.5: Representação de dois componentes sendo interligados por um connector-VP Na Figura 2.5, o componente transversal LoggingMgr entrecorta o componente base BasketMgr por intermédio do conector BasketLoggingConnector. A interface trans-versal do componente BasketMgr explicita os pontos de junção que podem ser intercep-tados por outros componentes, permitindo que os componentes transversais utilizem esses pontos para modicar o comportamento do componente base sem quebra de encapsula-mento, já que eles não têm acesso direto às classes de implementação.

A Figura 2.6 apresenta o projeto detalhado da Figura 2.5, nela é possível identicar que a interface transversal do conector entrecorta um aspecto especíco no componente de carrinho de compras, o XPIBasket. O conceito desta interface é baseada na ideia de XPI, proposta por Griswold et al. [21], que funciona de forma análoga ao conceito de API, separando a especicação da implementação. Em outras palavras, os adendos do conector não têm conhecimento dos pontos de junção que serão entrecortados no componente, que são denidos pelo aspecto XPI, promovendo desacoplamento entre o conector e o componente.

2.4 Linha de Produtos de Software

Linha de produtos de software (LPS) é uma das abordagens de reúso de software denida por um conjunto de aplicações com uma arquitetura em comum e componentes compar-tilhados; cada uma dessas aplicações é responsável por realizar diferentes requisitos [45]. O conjunto de produtos de software de uma LPS possui alto grau de similaridade entre si, sendo construídos a partir de ativos centrais1 _[7].

O processo de engenharia de uma LPS possui dois subprocessos: engenharia de domínio e engenharia de aplicação. O primeiro analisa as funcionalidades em comum e variáveis

(21)

Figura 2.6: Modelo de componentes do COSMOS*-VP detalhado

dos produtos que irão compor a LPS. O segundo deriva os produtos reusando os artefatos presentes na engenharia de domínio.

Seu desenvolvimento é feito identicando-se características comuns em uma família de software, que são implementadas em uma aplicação base. Esta aplicação base é intencio-nalmente construída para simplicar o reúso e reconguração [45].

A reconguração é feita por meio de adição, remoção ou modicação de seus com-ponentes para atender uma característica desejada pelo stakeholder do produto a ser desenvolvido. Kang et al. [28] denem características como atributos de um sistema que afetam diretamente o usuário nal. Dependendo das características selecionadas, são gerados diferentes produtos de software.

As próximas seções apresentam características importantes para o desenvolvimento de uma LPS. Na Seção 2.4.1 são descritos os fundamentos de variabilidade de software e na Seção 2.4.2 é feita uma introdução sobre o modelo de características.

(22)

2.4.1 Variabilidade de Software

A LPS é capaz de gerar produtos diferentes devido a variabilidade de software [51]. Va-riabilidade de software é a capacidade de um sistema de software ser modicado para ser utilizado em um contexto especíco. A variabilidade é implementada por meio de um conjunto de pontos de variação, onde são associadas as variantes que são as alternativas de decisão do produto. Quanto maior o grau de variabilidade de um artefato de software, maior será sua utilização em um amplo contexto, o que o torna mais reutilizável.

A variabilidade de software ocorre nos pontos de variação, os locais nos artefatos de software em que uma decisão de escolha de um produto pode ser tomada. Associadas a esse ponto estão as variantes, que são alternativas para o produto nal. Em um processo chamado de conguração do produto, os pontos de variação são resolvidos de maneira a decidir quais variações arquiteturais irão fazer parte de um produto de software [51].

2.4.2 Modelo de Características

Kang et al. [28] denem características como atributos de um sistema que afetam di-retamente o usuário nal. Elas são documentadas em um modelo de característica que apresenta a hierarquia, regras de composição e análise relacional das características. O modelo de características é amplamente utilizado para representar a variabilidade de LPSs [27].

Figura 2.7: O modelo de característica para um pedido de um sistema de e-commerce A Figura 2.7 apresenta um exemplo de um modelo de característica para um pedido de um sistema de e-commerce. Nessa gura é possível identicar os quatro tipos possíveis para uma característica: características obrigatórias, que devem ser sempre seleciona-das para um produto; características opcionais, que podem ou não ser selecionaseleciona-das para um produto; características alternativas, um conjunto de características do qual deve ser selecionada uma característica para o produto; características-OU, um conjunto de características de onde são selecionadas uma ou mais características [9].

(23)

2.4.3 Mapeamento de Características para Elementos

Arquitetu-rais

Visando evitar o espalhamento de características, quando múltiplos elementos arquite-turais implementam uma mesma característica, e o entrelaçamento de características, quando um elemento arquitetural implementa múltiplas características, foi criado o mé-todo de mapeamento Aspect Oriented Feature-Architecture Mapping (AO-FArM) [48], uma evolução do método Feature-Architecture Mapping (FArM) [44] para suportar a im-plementação de elementos arquiteturais com a integração de componentes e aspectos.

O AO-FArM dene quatro transformações a serem aplicadas no modelo de caracterís-ticas que resultam na arquitetura inicial da LPS e cinco atividades de renamento para se obter a arquitetura nal, composta por componentes e aspectos.

Figura 2.8: Transformações do método AO-FArM

O diagrama da Figura 2.8 apresenta as quatro transformações do método, descritas a seguir.

Remover as características não relacionadas à arquitetura e resolver as carac-terísticas de qualidade

Os requisitos importantes para uma arquitetura podem ser de dois tipos: requisitos fun-cionais e requisitos de qualidade [50]. Requisitos funfun-cionais determinam o que será im-plementado e requisitos de qualidade determinam como será imim-plementado. O método AO-FArM dene que características não relacionadas à arquitetura não fazem parte do conjunto de requisitos importantes e, portanto, devem ser removidas.

(24)

Outra transformação desse passo é resolver as características de qualidade, juntando elas a características funcionais, de maneira que elas possam ser mapeadas para os compo-nentes que implementarão a LPS. Por exemplo, um modelo de características pode possuir um requisito de qualidade de availability que pode ser resolvido para a característica de tratamento de exceções.

Transformar baseando-se nos requisitos da arquitetura

O modelo inicial de características é criado sob inuência do usuário nal e muitas vezes pode ocorrer de não haver nele requisitos que exercem forte inuência no modelo arquite-tural, como persistência e logging, por exemplo. O método AO-FArM sugere representar explicitamente esses requisitos no modelo, integrando-os em características já existentes ou criando novas características.

Transformar baseando-se nas relações de interação entre as características Nessa transformação, relações entre as características são adicionadas para representar a comunicação entre elas [43]. São denidas cinco tipos de relação entre as características: (i) uma característica usa outra característica; (ii) uma característica modica outra ca-racterística; (iii) uma característica contradiz outra caca-racterística; (iv) uma característica entrecorta outra característica; (v) uma característica é procedida por outra caracterís-tica. As três primeiras relações contemplam a visão de componentes e as duas últimas contemplam a visão orientada a aspectos.

Transformar baseando-se nas relações de hierarquia entre as características Essa transformação mapeia as características para componentes arquiteturais de acordo com três tipos de relação: (i) uma subcaracterística especializa uma supercaracterística; (ii) uma subcaracterística é parte de uma supercaracterística; (iii) uma subcaracterística apresenta uma alternativa para uma supercaracterística.

Nessa transformação cabe ao desenvolvedor decidir como as características irão se transformar nos componentes, uma característica pode gerar um componente ou um com-ponente pode ser formado por diversas características. Separar características em dife-rentes componentes aumenta o acoplamento entre os componentes e a complexidade de gerenciamento. Por outro lado, juntar características em um único componente aumenta o entrelaçamento de características, podendo prejudicar a evolução da arquitetura. Por-tanto, cabe ao desenvolvedor decidir quais conjuntos de características podem ser juntadas em um único componente e quais devem formar diferentes componentes.

O diagrama da Figura 2.9 apresenta as cinco atividades de renamento para a imple-mentação da LPS a partir da arquitetura inicial gerada nas transformações do diagrama da Figura 2.8.

Identicar as interfaces base e transversais

Nessa atividade as relações entre os componentes modeladas na arquitetura inicial da LPS devem ser substituídas por relacionamentos adequados para o modelo de arquiteturas.

(25)

Figura 2.9: Renamento da arquitetura no método AO-FArM

Existem dois tipos de possíveis relacionamentos entre componentes: por meio de interfaces base ou interfaces transversais. Interfaces base são implementadas por classes e interfaces transversais são implementadas por aspectos.

A Figura 2.10 [48] mostra como são representadas essas relações. Do lado esquerdo da imagem estão representados os tipos de relações entre os componentes e, do lado direito da imagem, estão representadas essas relações na arquitetura de LPS.

Especicar as operações das interfaces base e transversais

Nessa atividade são especicadas, por meio de diagramas de comunicação UML 2.4 [35], as interações entre os componentes. Devem ser especicadas, inicialmente, as interações entre as interfaces providas e requeridas, os métodos das interfaces base e suas assinaturas. Em seguida, devem ser especicadas as interfaces transversais.

Avaliar componentes legados

LPSs podem ser criadas a partir de componentes legados, criando artefatos a partir do zero ou evoluindo uma LPS já existente. Essa atividade é aplicada para a abordagem de criar LPSs a partir de componentes legados, seu objetivo é promover o reúso desses

(26)

Figura 2.10: Como os relacionamentos entre componentes são representados na arquite-tura da LPS [48]

componentes, analisando os componentes mais adequados e de melhor qualidade para compor a LPS.

Implementar/refatorar componentes base e transversais

Nessa atividade as especicações de componentes que não possuírem legado compatível são implementadas e os componentes legados aproveitados na atividade anterior são adaptados para a especicação do componente da LPS.

Especicar e implementar conectores base e transversais

Conectores são utilizados para intermediar a comunicação entre componentes, modulari-zar os pontos de variação arquiteturais e resolver conitos entre componentes transversais. Nessa atividade esses conectores são especicados e implementados resultando, junto com as atividades anteriores, na implementação de uma LPS baseada em componentes e as-pectos.

O AO-FArM e o COSMOS*-VP juntos oferecem uma solução completa para a im-plementação de LPSs com componentes, aspectos e VP-connectors. A ilustração dessa solução é mostrada na Figura 2.11, que mostra desde a solução desde a transformação das características até a implementação da LPS.

2.5 Domínio de E-commerce

Segundo o e-bit, em 2012 houve um crescimento de 20% do e-commerce no Brasil, havendo um faturamento de mais de R$22 bilhões [22], para 2013 era esperado um crescimento de 24% [24]. Esse forte crescimento da área pode ser justicado por uma maior conança do

(27)

Figura 2.11: Diagrama da solução para implementação de LPSs com componentes, as-pectos e VP-connectors

consumidor em realizar compras on-line e exige uma maior preocupação de segurança no desenvolvimento dos sistemas.

Junto com o crescimento da área há também maior exigência do consumidor em relação ao uso do serviço. Segundo o estudo divulgado pela Computerware, 38% dos consumidores abandonam uma loja virtual caso o tempo de carregamento seja maior que 4 segundos [11]. Essa exigência levanta a necessidade de escalabilidade do sistema oferecido, o que pode proporcionar um desempenho estável de navegação mesmo com um alto número de acessos simultâneos em uma aplicação de e-commerce.

2.5.1 Fluxo de Compra

O modelo clássico de sistemas de e-commerce possui seis passos básicos para a realização de uma compra que vão desde a busca dos produtos desejados até a informação dos dados de entrega e pagamento para nalizar o processo de compra, esses passos são apresentados no uxograma da Figura 2.12. Apesar de alguns sistemas não seguirem mais o modelo clássico, esse uxo ainda é utilizado pela maioria dos sistemas.

Após acessar a loja, o cliente deve encontrar os produtos desejados. Quando um produto é encontrado, ele deve ser adicionado ao carrinho de compras, para isso o cliente deve informar a quantidade de produtos e, se houver, as opções desejadas do produto (cor, tamanho, peso, etc), após isso ele informa que deseja inserir o produto no carrinho. Esse processo de busca e adição do produto ao carrinho de compras é feito até o cliente ter encontrado os produtos desejados, após isso ele pode dar início ao processo de nalizar a compra.

Para nalizar a compra, é necessário que o cliente possua cadastro na loja, caso não possuir, ele deve realizar esse cadastro antes de continuar o processo de nalização da

(28)

Figura 2.12: Diagrama de atividades do processo tradicional de compra no sistema de e-commerce

compra. Para preservar os dados pessoais do cliente, no momento de realização do ca-dastro e do login no sistema, obrigatoriamente deve ser oferecido um ambiente seguro ao cliente, onde os dados que ele informar serão criptografados com chaves públicas e privadas [10][40], evitando que, caso interceptados, os dados informados sejam lidos por pessoas indesejadas.

O processo de nalização da compra exige os mesmos requisitos de segurança que o cadastro e login do cliente, pois nele o cliente informa seu endereço e dados de pagamento, portanto também deve ser executado em um ambiente seguro. Não havendo nenhum pro-blema, após informar o endereço de entrega, endereço de cobrança e dados de pagamento do pedido o sistema informa que o pedido foi nalizado com sucesso e o cliente naliza a compra.

Após esse uxo, o sistema aguarda a conrmação do pagamento, e geralmente informa o cliente por e-mail quando há sucesso ou reprovação. Somente após essa conrmação os produtos do pedido são enviados ao cliente, nalizando efetivamente o processo da compra.

2.5.2 Protocolos de Pagamento

Nessa Seção serão apresentados dois exemplos de protocolos de pagamento utilizados para o pagamento com cartão de crédito, que podem ser utilizados de base para a implementa-ção da característica de pagamento do modelo de características da LPS de e-commerce. O primeiro, o mais comum, realiza o pagamento através de trocas de mensagens entre o serviço do sistema e-commerce, o gateway de pagamentos e os bancos do cliente e do

(29)

vendedor. O segundo protocolo realiza os mesmos passos do primeiro, porém possui um serviço de análise de risco antes de realizar a cobrança do cartão de crédito do cliente.

O primeiro protocolo, apresentado na Figura 2.13 tem início na nalização da compra descrita no uxograma da Seção anterior, onde o cliente informa os dados de pagamento (dados do cartão de crédito) e realiza o pedido. Se os dados estiverem corretos, o sistema retorna uma mensagem de sucesso ao cliente.

Figura 2.13: Protocolo de pagamento com cartão de crédito

Após a nalização da compra, os seguintes passos são realizados para a realização do pagamento:

1. O cliente informa os dados de pagamento para o sistema e conrma a compra; 2. O sistema de e-commerce envia os dados do cartão de crédito do cliente e valor

da compra para o gateway de pagamento, responsável pela transação entre a loja e a operadora de cartão de crédito. O gateway de pagamento retorna à loja a autorização ou recusa da cobrança;

3. A loja informa o cliente se o pagamento foi autorizado ou não;

4. O gateway de pagamento notica o banco do cliente sobre a cobrança; 5. O gateway de pagamento notica o banco da loja sobre o pagamento;

(30)

6. O banco da loja atualiza o relatório de transações de seu cliente com o novo paga-mento;

7. O banco do cliente faz a cobrança e o cliente realiza o pagamento.

A diferença do segundo protocolo, apresentado na Figura 2.14, para o primeiro é a existência de um sistema de análise de risco, que analisa a possibilidade da transação ser uma fraude e trazer prejuízos para a loja. A ocorrência de fraudes é algo frequente nos sistemas de e-commerce, um tipo de comum dessa prática é o cliente realizar o estorno do pagamento da compra após receber o pedido, cando com os produtos sem pagar a compra.

Figura 2.14: Protocolo de pagamento com cartão de crédito com análise de risco A análise de risco é feita após o gateway de pagamento autorizar a cobrança no cartão de crédito do cliente. Após a aprovação do pagamento, o valor ca reservado até que o sistema de e-commerce seja informado pelo sistema de análise de risco se a venda é conável.

Se a venda for conável, o sistema de e-commerce informa o gateway de pagamento para efetivar a cobrança. Caso haja risco de fraude na cobrança, o gateway de pagamento cancela a cobrança, desfazendo a reserva do valor que seria pago, e o pedido é recusado.

(31)

Capítulo 3

Implementação de Sistemas de

E-commerce

3.1 Ferramentas de Implementação

Para estudar a aplicação das técnicas do COSMOS*-VP no domínio de e-commerce, foi necessária a implementação de três LPSs. Estas implementações foram realizadas na linguagem Java 7 [36], pois ela apresenta estruturas que melhor representam o desenvolvi-mento dos componentes COSMOS*-VP, como interfaces e módulos divididos em pacotes. Também foi utilizada a linguagem AspectJ [47], que estende a linguagem Java para su-portar programação orientada a aspectos.

O gerenciamento do projeto foi feito com a ferramenta Apache Maven [32]. Apache Maven é uma ferramenta de automação de compilação de software que se baseia no con-ceito modelo de objeto de projeto (POM1_{). Nesta ferramenta, o projeto de software a} ser construído é descrito em um arquivo XML (chamado de pom.xml), onde são dadas informações sobre o software, além de dependências e plugins que ele utiliza, o que facilita bastante o desenvolvimento, pois as bibliotecas das dependências e plugins são baixados automaticamente de repositórios públicos que a ferramenta tem acesso e importados no projeto Java.

Nas LPSs implementadas, o código foi centralizado em um projeto Maven principal onde foi realizado o gerenciamento de dependências, este projeto foi composto por diversos módulos que implementam os componentes denidos na arquitetura. Cada componente foi implementado em dois módulos: um módulo spec, onde cam as interfaces públicas do componente; um módulo impl, onde cam as classes que implementam essas interfaces. Um componente só possui como dependência o módulo spec de outro componente. O modulo impl só é utilizado como dependência pelo código que dene os conectores. Essa relação entre os componentes permitiu a separação entre especicação e implementação proposta pelo modelo COSMOS*-VP, garantindo que o módulo impl de um componente possa ser modicado, ou até mesmo substituído por outro módulo, sem afetar os compo-nentes que utilizam sua especicação.

Também foi criado um módulo datatype, comum para todos os componentes da im-1_{do inglês Project Object Model}

(32)

CAPÍTULO 3. IMPLEMENTAÇÃO DE SISTEMAS DE E-COMMERCE 32

Figura 3.1: Relação da LPS com o container EJB

plementação, onde são especicadas as interfaces com os tipos da LPS. As interfaces do datatype são implementadas pelo componente de persistência, responsável por mapear, através da especicação do Java Persistence API (JPA) [25], os tipos com as tabelas do banco de dados e realizar as queries necessárias pelas operações dos componentes. As entidades de persistência são gerenciadas pela especicação do Enterprise Java Beans 3.1 (EJB 3.1) [14][37], conforme mostrado na Figura 3.1.

Na Figura 3.1 (a) é possível visualizar o container do EJB entre os componentes do COSMOS*-VP e o banco de dados. Dentro do container há o Hibernate implementando a especicação JPA. Os componentes do COSMOS*-VP utilizam as interfaces do datatype e as interfaces de DAO, ambas implementadas pelo PersistenceObjects. Na Figura 3.1 (b) a arquitetura é mostrada em detalhes, as classes que implementam a interface Manager obtêm as instanciações de persistência do container que implementa a especicação EJB, utilizadas pelos componentes da LPS.

Os sistemas criados a partir das LPSs tiveram sua interface web implementada com JavaServer Faces (JSF) [26]. JSF é uma especicação Java para a criação de interfaces de usuário para aplicações Web. Ela é baseada em componentes visuais pré-prontos, permitindo a criação de aplicações Web sem a necessidade de se preocupar com HTML, Javascript e CSS.

(33)

3.2 Servidor de Aplicação

O servidor utilizado para executar os sistemas de e-commerce implementado foi o WildFly[52]. WildFly é o nome dado para o JBoss Application Server a partir da versão 8, ele é um servidor de aplicação que implementa as especicação do JavaEE, que inclui JPA, EJB e JSF.

Uma das características não funcionais dos sistemas de e-commerce é scalability, que representa a capacidade do sistema lidar com o aumento de tráfego [33], o que pode ser feito adicionando mais servidores para tratar o acesso dos clientes.

Figura 3.2: Modelo de acesso direto ao servidor de aplicação

No desenvolvimento desse trabalho, foi utilizado apenas um servidor de aplicação, acessado diretamente pelos clientes. Na Figura 3.2 é apresentada a arquitetura de servidor utilizada, nela o Banco de Dados pode estar ou não no mesmo servidor. Para testes e lojas de baixo acesso esse modelo é suciente, porém o número de sessões ativas deve ser limitado para evitar problemas de performance no sistema.

Normalmente, esse tipo de sistema possui uma arquitetura de multi-camadas [33]. Um possível modelo dessa arquitetura é o de três camadas: na primeira o cliente acessa um servidor que realiza o balanceamento de carga, denindo qual servidor da segunda camada será acessado; a segunda camada é composta pelos servidores de aplicação, com a implementação do sistema; a terceira camada é composta pelo banco de dados. Esse modelo foi utilizado pelo autor desse trabalho durante o tempo que trabalhou com sistemas de e-commerce.

A Figura 3.3 ilustra o modelo de multi-camadas, sua principal vantagem é a escalabi-lidade de servidores, onde o número de servidores pode aumentar para suportar grandes quantidades de acesso e diminuir quando os acessos são baixos. Pelo fato de todos servi-dores da segunda camada serem iguais, outra vantagem desse modelo é que essa replicação favorece a tolerância a falhas, já que, caso um dos servidores da segunda camada tenha pane, o servidor da primeira camada irá direcionar seus acessos para outros servidores.

A desvantagem do modelo da Figura 3.3 é a sobrecarga que pode ocorrer no banco de dados, já que todos os servidores irão ler e escrever dados nele. Esse problema pode ser resolvido com o uso de cache de dados, que diminui a quantidade de acesso de leituras.

(34)

Figura 3.3: Modelo de arquitetura de multi-camadas

Outra possível solução é a arquitetura da Figura 3.4, baseada na arquitetura que a Amazon Web Services [2] propõe para sistemas de e-commerce [1]. Nessa arquitetura cada servidor da segunda camada possui um banco de dados de leitura, cujos dados são os catálogos de produtos e categorias da loja.

Os registros de usuários e compras são realizados em uma nova camada, que iremos chamar de camada de compras, onde há um servidor conectado a um banco de dados de leitura e escrita. Os servidores da segunda camada enviam mensagens de registro de usuários e realização de compras para o servidor da camada de compras, que irá realizar as operações de escrita no banco de dados de escrita e leitura, retornando uma mensagem de sucesso ou falha. Outra função do servidor da camada de compras é realizar atualizações periódicas nos catálogos dos bancos de dados de leitura.

(35)

(36)

Capítulo 4

Estudo de Caso: Mercurius SPL

4.1 Apresentação

O estudo de caso realizado neste trabalho teve como objetivo responder as seguintes questões de pesquisa:

Questão de Pesquisa 1 (QP1) O método AO-FArM e o modelo COSMOS*-VP podem ser aplicados para uma aplicação maiores e com relevância fora do contexto aca-dêmico, como o domínio de e-commerce?

Em trabalhos anteriores, foram desenvolvidas LPSs fora do contexto de mercado e de menor complexidade que sistemas de e-commerce. Portanto, essas técnicas ainda precisam ser avaliadas em diferentes contextos para avaliar se os resultados obtidos são os mesmos de estudos anteriores. Além disso, a replicação de uma metodologia pode aumentar sua validade interna de um estudo [42].

Questão de Pesquisa 2 (QP2) A implementação de uma LPS utilizando as técnicas propostas é melhor para a estabilidade da ALP em comparação a implementações de outras metodologias?

Estabilidade arquitetural refere-se a capacidade da arquitetura ser exível o suci-ente para suportar mudanças evolutivas, permanecendo-se intacta e adicionando novas funcionalidades ao sistema [4]. Para avaliar a implementação do modelo COSMOS*-VP quanto a estabilidade da sua arquitetura, é necessário comparar ela com implementações realizadas com outras técnicas.

Questão de Pesquisa 3 (QP3) Em comparação a uma implementação baseada em componentes, quais são as contribuições individuais da programação orientada a aspectos e dos VP-connectors para a evolução e estabilidade da ALP?

Caso a resposta da QP2 seja que a implementação do COMOS*-VP seja melhor do que uma implementação baseada em componentes, deve-se avaliar as contribuições individuais de cada uma das técnicas utilizadas para estabilidade da ALP.

Para responder a QP1, as características do domínio de e-commerce foram identicadas e transformadas no modelo arquitetural do COSMOS*-VP seguindo a metodologia do AO-FArM. Para responder a QP2, foram geradas outras implementações utilizando técnicas

(37)

CAPÍTULO 4. ESTUDO DE CASO: MERCURIUS SPL 37

diferentes e para cada uma foram gerados quatro releases diferentes que foram comparados entre si, para avaliar qual deles apresenta melhores resultados para a evolução da ALP. A hipótese deste estudo é que a solução do modelo COSMOS*-VP contribui para reduzir o impacto das mudanças na arquitetura e possui maior modularidade do que as outras soluções. A diferença entre as implementações propostas irá responder a QP3.

Na Seção 4.2 será discutido o contexto desse estudo, justicando as necessidades de uma LPS para sistemas de e-commerce; Na Seção 4.3 são descritos a preparação e planeja-mento do desenvolviplaneja-mento da LPS; Por m, na Seção 4.4 é descrita a execução do estudo, nela é explicada a aplicação da teoria para a implementação da LPS de e-commerce.

4.2 Contexto do Estudo de Caso

A necessidade do desenvolvimento de uma LPS para e-commerce pode ser justicada por dois fatores: seu crescimento no mercado, já que compras online trazem mais auto-ecácia, benefícios nanceiros e conveniência ao consumidor [12]; ser um domínio da Web que requer aplicações com variantes similares, porém customizáveis de acordo com as necessidades das companhias que o implementam [31].

Assim, com o aumento desse tipo de sistema no mercado e a similaridades entre eles, o desenvolvimento de uma LPS para esse tipo de sistema pode garantir maior qualidade e segurança para os consumidores que realizarão compras nesses sistemas.

Além disso, sistemas de e-commerce lidam com dados pessoais dos consumidores e várias transações nanceiras, como o dinheiro pago pelo consumidor e o valor dos produtos disponibilizados pelo vendedor, exigindo integração com sistemas de terceiros e um elevado número de características para satisfazer todas as regras de negócio e estar de acordo com a legislação, o que torna esse tipo sistemas complexo. Essa complexidade põe o modelo COSMOS*-VP a uma avaliação ainda não realizada, pois nos outros trabalhos em que foi utilizado, não houve um caso complexo e que representa um problema de relevância fora do contexto acadêmico, como pode ser feito com sistemas de e-commerce.

4.3 Planejamento do Estudo de Caso

O planejamento do estudo foi feito a partir da análise de quatro sistemas de e-commerce do mercado: uma loja brasileira que vende diversos tipos de produtos; uma loja brasileira especializada em roupa de moda feminina; uma loja americana que vende diversos tipos de produtos; uma loja americana especializada em suplementos alimentares.

Na Figura 4.1 é apresentado o planejamento de execução do estudo de caso. É possível notar que, a partir dos quatro sistemas analisados foi feita a análise de requisitos, de onde surgiram as características iniciais da LPS, e o mapeamento das características para o levantamento da arquitetura da LPS.

A partir dessa análise e da experiência prévia com sistemas de e-commerce, foram identicadas 84 características nesses sistemas, podendo elas serem comuns entre os sis-temas ou variáveis dependendo do tipo de produto vendido, como atributos como peso e tamanho; e do país da loja virtual, como método de pagamento e regras de devolução. A

(38)

Figura 4.1: Execução do estudo de caso

Figura 4.2 apresenta o modelo com as características iniciais levantadas, utilizadas como ponto inicial para o desenvolvimento da LPS proposta.

4.4 Execução do Estudo de caso

Foi aplicado o método AO-FArM nos elementos do modelo de características inicial. Na primeira transformação do método (remover as características não relacionadas à arqui-tetura e resolver as características de qualidade), onde a característica de qualidade de-pendability e suas sub-características foram resolvidas nas características criptograa de senha, análise de risco, SSL e load balance, conforme ilustrado na Figura 4.3 (a).

As características logging, persistência e tratamento de exceções foram adicionadas na segunda transformação (transformar baseando-se nos requisitos da arquitetura), resul-tando no modelo parcial ilustrado na Figura 4.3 (b).

A terceira transformação (transformar baseando-se nas relações de interação entre as características) é feita para denir a maneira como as características irão se relacionar. As possíveis relações são: uma característica usa outra característica e uma característica entrecorta outra característica. Na Figura 4.4 é ilustrado o modelo de relacionamentos

(39)

Figura 4.2: Modelo de características inicial

da LPS deste trabalho. Um exemplo de relação onde uma característica usa a outra é a característica pedido que usa a característica produto, essa relação é denida desta maneira pois um pedido é composto de produtos e usa as informações deles para compor a compra. Um exemplo de relação de uma característica entrecortar outra característica é a característica cache de dados entrecortando a característica persistência, essa relação é denida porque, quando implementada, a característica cache de dados, quando possuir um determinado valor a ser buscado da característica persistência, entrecorta o acesso ao banco de dados antes dele ocorrer, retornando o valor sem a necessidade de acesso a disco. Relações de uso entre característica são transformadas em interfaces base no modelo arquitetural e relações de entrecortamento entre características são transformadas em interfaces transversais.

A quarta transformação (transformar baseando-se nas relações de hierarquia entre as características) dene a relação hierárquica entre uma característica e suas sub-características. As possíveis relações de hierarquia são: uma característica genera-liza/especializa outra característica; uma característica é composta por uma ou mais características; uma característica implementa outra característica. Na Figura 4.5 é ilus-trado o modelo de relacionamento hierárquico da LPS deste trabalho. Um exemplo de composição/especialização são as sub-características de busca de produto, que são especia-lizações de busca de produto, esta uma característica abstrata. Um exemplo de composição é a característica pedido composta por operações que podem ser realizadas com ela, as suas formas de pagamento, os seus métodos de envio e a possibilidade dela ser realizada

(40)

Figura 4.3: (a) Modelo de características parcial após a primeira transformação do AO-FArM, em azul as características que foram transformadas; (b) Modelo de características parcial após a segunda transformação do AO-FArM, em vermelho as características que foram adicionadas

Figura 4.4: Modelo de relacionamento entre as características

apenas com um clique. Por m, um exemplo de implementação é a característica tipo produto que pode ser implementada por tipos especícos de produto.

As características do modelo foram transformadas em componentes, classes ou mé-todos. Um exemplo é a característica pedido, transformada no componente OrderMgr da Figura 4.6, que mostra a característica pedido e suas sub-características pagamento e forma de envio transformados para o modelo arquitetural após as seguintes fases de re-nação: identicar as interfaces base e transversais; especicar as operações das interfaces base e transversais.

Na primeira fase de renamento (identicar as interfaces base e transversais), as in-terfaces providas e requeridas são especicadas. No exemplo da Figura 4.6, as inin-terfaces providas identicadas para a característica pedido foram: IOrderMgt; IManager, esta in-terface é provida por todos os componente pois é nela que são denidas as implementações de cada interface provida e requerida do componente; XPIOrder, esta, diferente das ou-tras duas, sendo uma interface transversal onde são providos os pontos de junção das classes do componente OrderMgr. Todas as interfaces requeridas identicadas são inter-faces base, elas são: IPaymentMgt, onde são implementados os métodos de pagamento;

(41)

Figura 4.5: Modelo de relacionamento hierárquico entre as características

IShippingMgt, onde são implementados os métodos de frete; IBasketMgt, de onde são extraídos os produtos e informações de pagamento da compra; IProductMgt, que fornece uma conexão com os produtos da compra.

O componente OrderMgr possui a interface transversal provida XPIOrder pois é en-trecortado por três componentes: o componente de tratamento de exceções; o componente de segurança; o componente de logging.

Na segunda fase de renamento (especicar as operações das interfaces base e trans-versais), os métodos das interfaces foram denidos, conforme mostrado na Figura 4.7. Nessa gura é possível notar que as sub-características de operações foram transformadas em métodos (getInvoice e cancelOrder) da interface IOrderMgt.

O modelo arquitetural da Figura 4.6 permite que seja adicionada à LPS qualquer tipo de módulos de pagamento e forma de envio, que irão prover uma interface para o componente transformado de sua super-característica, esta última sendo transformada em um conector entre o componente de pedido e o componente na última fase de renamento (especicação e implementação dos conectores base e transversais). Os conectores são responsáveis por implementar a conexão entre as interfaces providas e requeridas. Eles são componentes simples do COSMOS*-VP que não podem denir novas interfaces.

No COSMOS*-VP, os conectores podem ser base, como os conectores OrderPayment-Connector e OrderShippingOrderPayment-Connector na Figura 4.6, ou transversais (VP-connector), como o PromotionProductConnector na Figura 4.8. Os conectores base realizam a

(42)

co-CAPÍTULO 4. ESTUDO DE CASO: MERCURIUS SPL 42

Figura 4.6: Componente de pedido conectado a pagamento e forma de envio nexão entre interfaces base, sem aspecto, e os VP-connectors realizam a conexão entre interfaces transversais, com aspectos. Todas as interfaces providas e requeridas da arqui-tetura são conectadas por conectores de um desses tipos.

O projeto detalhado da Figura 4.8 está ilustrado na Figura 4.9. Os aspectos DI-PromotionDiscount e DIPromotionCoupon estendem os aspectos abstratos que re-querem pontos de junção nos componentes PromotionDiscountMgr e Promotion-CouponMgr. As classes Adapter fazem as adaptações necessárias para adaptar os componentes de promoção ao componente de produto. Por m, o aspecto RIPromo-tion trata os pontos de variação dos componentes de promoção e entrecorta o aspecto XPIProduct, onde são denidos os pontos de junção do componente ProductMgr que serão entrecortados.

4.4.1 Implementação do Código

O processo de transformação das características e renamento do modelo arquitetural do AO-FArM tem como resultado a arquitetura da LPS de acordo com o modelo COSMOS*-VP, a partir da arquitetura resultante deste trabalho, foi feita a implementação do código. Foram implementadas três LPS, descritas na Tabela 4.1: uma implementação utili-zando o modelo COSMOS*-VP, que será chamada de VP-AO-CBImpl; uma implementa-ção utilizando o COSMOS*, que será chamada de CBImpl; e uma implementaimplementa-ção utilizado um modelo intermediário entre o COMOS* e o COSMOS*-VP, onde há a utilização de aspectos para entrecortar módulos, porém não há presença do conector-VP; sua imple-mentação será chamada de AO-CBImpl. O modelo intermediário foi implementado para analisar a evolução do modelo COSMOS* em duas fases: a fase de inserção de módulos que utilizam aspectos e a fase de inserção de módulos que utilizam aspectos e o conector-VP. Para cada uma das três LPS implementadas foram geradas quatro releases, descritos na Tabela 4.2. O primeiro release foi composto dos componentes mínimos necessários para se realizar o uxo de compra apresentado na Figura 2.12; no segundo release foi

(43)

Figura 4.7: Componente de pedido detalhado

Figura 4.8: Os componentes de produto e promoção sendo conectados por um VP-connector

adicionado a característica de tratamento de exceções; no terceiro release foi adicionada a característica de promoção de desconto (promoção de-por); por m, no quarto release foi adicionada a característica de cache de dados.

Release 1

O principal objetivo deste release foi possibilitar que sejam criados, a partir da LPS, siste-mas de e-commerce onde é possível realizar o uxo básico de um sistema de e-commerce, como apresentado na Figura 2.12, ou seja, um sistema onde é possível se registrar, bus-car um produto e comprá-lo. Portanto foram implementadas as bus-características: produto; atributos; descrição do produto; tipo físico de produto; categoria; carrinho de compras; pedido; pagamento por cartão de crédito; cliente; endereço do cliente; cadastro e login; encriptação de senha; busca de produtos por texto; e logging.

A diferença entre as três implementações é que nas VP-AO-CBImpl e AO-CBImpl as características encriptação de senha e logging foram implementadas com aspectos, enquanto que na CBImpl todas características foram implementados apenas com compo-nentes.

(44)

Figura 4.9: Os componentes de produto e promoção sendo conectados por um VP-connector

Implementação Tipo Técnicas

I1 implementação baseada em

componentes (CBImpl) desenvolvimento baseado emcomponentes I2 implementação orientada a

as-pectos (AO-CBImpl) programação orientada a aspec-tos, desenvolvimento baseado em componentes

I3 implementação orientada a aspectos com VP-connectors (VP-AO-CBImpl)

VP-connector, programação orientada a aspectos, de-senvolvimento baseado em componentes

Tabela 4.1: Implementações do Estudo de Caso Release 2

Neste release foi implementada a característica de tratamento de exceções. foram denidas três exceções importantes a serem tratadas: produto fora de estoque; e-mail ou documento duplicado; produto não encontrado. Na VP-AO-CBImpl foi implementada de acordo com o método MVTE (Método de Variabilidade de Tratamento de Exceções) [23], na Figura 4.10 é mostrado o modelo de características com o tratamento de exceções conforme especicado neste método.

Na AO-CBImpl o tratamento de exceções também foi implementado com aspectos, porém sem os pontos de variação no connector-VP e a utilização do aspecto XPI no módulo entrecortado. Na CBImpl o tratamento de exceções foi feito diretamente nas classes, não havendo um módulo especíco para esta função.

Release 3

Neste release foi adicionada a característica de promoção de desconto. Esta característica opcional foi escolhida por ser um tipo padrão de promoção utilizada em todos os siste-mas de e-commerce analisados. Além disso, esta característica entrecorta características importantes do domínio, como produtos, busca de produtos e pedido.

Com esta característica, os produtos podem ter descontos promocionais, de uma por-centagem do valor do produto ou de um valor xo. Na VP-AO-CBimpl, foi implementado um VP-connector onde será possível conectar outros tipos de promoção. Os componentes

(45)