Desenvolvimento da Infraestrutura

3.7.1

Aplicação do Método AO-FArM

Aplicando o método Aspect-Oriented Feature Architecture Mapping (AO-FArM), usando o feature model da Figura 3.1 e a aspect-feature view da Figura 3.2, uma arquitetura para a (LPS), que pode ser vista na Figura 3.3, foi criada com ajuda de Waku [51]. Para obter a arquitetura, o modelo de features foi transformado de acordo com as quatro transformações propostas pelo método AO-FArM descrito na seção 2.6.4.

As duas primeiras transformações quase não afetaram o feature model e a aspect-

feature view, apenas removeram da arquitetura a feature não arquitetural Mobile Number

e a feature de nível básico que representa o sistema.

Na terceira transformação, as relações de interação entre as features foram checadas e notou-se que o grupo de features de base login, loading, data collection, dispatching e

visualization of collected data, que representam a hierarquia abaixo delas, utilizavam a

hierarquia de features representadas por data storage. Por sua vez, data storage e data

sinchronization utilizavam a feature replicada data storage type. Por final, a feature data collection utilizava a feature data validation.

Em relação a aspect-feature view, da Figura 3.2, a terceira transformação checou a relação entrecortada dos crosscutting concerns. Essa checagem verificou que: Block Usage entrecorta Loading, Data Collection e Dispatching; e Battery Monitor entrecorta Loading,

Data Collection, Dispatchin e Visualization of Collected Data.

Na quarta transformação, cada feature de base foi identificada, e aquelas que não eram

crosscutting concerns se refletiram como componentes abrigando todas as features que

features de base, as quais não foram englobadas por outras features depois do mapeamento

da arquitetura, transformam-se em conectores que ligam componentes relacionados. Estes conectores são exibidos através das interfaces providas e requeridas: por exemplo, a feature

Login gera um componente de Login que tem uma interface requerida para utilizar a

interface provida do componente Data Storage, que foi gerado a partir da feature Data

Storage, como pode ser visto na Figura 3.1.

As crosscutting concerns foram mapeadas como componentes que oferecem interfaces do tipo AbstractAspect para outros componentes. Os componentes gerados a partir das

features entrecortadas oferecem interfaces XPIs.

3.7.2

R-SPL-DC

Figura 3.3: Robust SPL Architecture for Data Collection - R-SPL-DC

A Figura 3.3 mostra a arquitetura baseada em componentes para linha de produto de software proposta para coletar dados de campo. Cada componente tem uma responsa- bilidade específica a qual admite uma forte relação com o feature model, isto é, todas as

features de base produzem componentes. Somente a feature Mobile Number não tem um

componente específico na arquitetura, isto porque esta feature representa uma escolha do número de dispositivos móveis que serão usados na coleta de dados, ou seja, não é uma

feature que se reflete na arquitetura de software.

A feature Data Collection foi mapeada para o componente Data Collection, que é o componente responsável por prover todos os serviços referentes a coleta de dados. A fea-

ture Data Collection usa a feature Data Validation, a qual foi mapeada para o componente Data Validation, que é responsável por oferecer os serviços para checagem e verificação de

valores da coleta de dados. Note que a feature Data Validation é opcional no modelo, ou seja, o componente relativo a esta feature é um ponto de variação da arquitetura, sendo que seu uso é opcional na criação de sistemas desenvolvidos a partir da R-SPL-DC.

As features Data Storage, Internal Phone Memory, SQLite, Storage Redundancy, e

SDCard foram mapeadas para o componente Data Storage, que define onde armazenar

as informações e como elas serão armazenadas. Data Storage usa Storage Format e, por isso, os componentes, com os respectivos nomes, têm uma interface de interação entre si. A feature Dispatching, junto com as outras features de sua hierarquia, foi mapeada para Dispatching Data, que é o componente responsável por prover os serviços de envio dos dados para um ou mais servidores.

As features Data Synchronization, WI-FI, Bluetooth e Storage Redundancy foram ma- peadas para o componente Data Synchronization, responsável por oferecer os serviços de importação, exportação e envio dos dados de um dispositivo móvel para o outro.

Loading e as features abaixo de sua hierarquia foram mapeadas para o componente Loading Data, o qual é responsável por oferecer os serviços de interação com o servidor,

antes da coleta, para carregar os dados que serão utilizados na validação e auxílio da coleta de dados.

A feature Visualization of Collected Data foi mapeada para o componente Visualization

of Collected Data, que tem como objetivo oferecer os serviços de visualização de mapa e

configurações da forma como os dados serão visualizados.

A feature Login foi mapeada para o componente Login, que oferece o serviço de iden- tificação do usuário dentro da aplicação.

O componente Block Usage, que foi mapeado a partir da crosscutting concern chamada

Block Usage, é responsável por bloquear algumas operações como carregar dados, coletar

dados e descarregar dados. O componente Battery Monitor, que foi carregado a partir da crosscutting concern Battery Monitor, faz os logs do nível atual de bateria quando algumas operações entrecortadas por ela são ativadas. Battery Monitor também deve ter a responsabilidade de fazer previsões sobre o tempo restante do uso da bateria.

Na R-SPL-DC, o componente Data Storage prevê a opção de escolha entre dois ca- minhos distintos dentro dos conectores: a primeira opção é a do uso de redundância no armazenamento de dados e a segunda opção é a de armazenar os dados sem redundân- cia. Entretanto, a opção de usar ou não tolerância a falhas depende dos componentes do cliente, isto é, o cliente é quem decide se quer ou não usar redundância. Existem situa- ções em que a coleta de dados ocorre dentro da área urbana das cidades, onde a Internet está disponível, fazendo com que seja desnecessário o uso de armazenamento com redun- dância. Nessas situações, a arquitetura dá a opção de gerar uma aplicação que envie os dados automaticamente para o servidor e que armazene os dados apenas localmente, por precaução.