Linha de produto de software para coleta de dados utilizando Android

tem como objetivo a proposta de uma arquitetura de linha de produto de software (LPS) ou Software Product Line (SPL) que seja robusta e genérica chamada R-SPL-DC, voltada para o domínio de coleta de dados móveis. Como é explicado por Waku et al (2015) a características de robustez de um sistema é basicamente a capacidade de entrega de um serviço, dentro de um ambiente repleto de condições adversas.

A arquitetura proposta apresenta estratégias para prover requisitos como disponibilidade, confiabilidade, performance e integridade dos dados. Dentre os seus requisitos a R-SPL-DC propõe os seguintes:

Tabela 16 - Requisitos arquiteturais do trabalho de Waku et al., (2015)

(Continua) Requisito

Arquitetural

Descrição

RA- 01 O uso de múltiplos dispositivos para lidar com coletas de dados de longa duração.

RA- 02 Sincronização de dados para aproveitar as informações entre dispositivos. RA- 03 Redundância de armazenamento para evitar a perda de dados.

RA- 04 Diferentes tipos de formato de armazenamento para compartilhar com aplicativos de terceiros o mesmo banco de dados.

RA- 05 Monitoramento e bloqueio de operações básicas como importação e exportação de dados do servidor, utilizando técnicas de desenvolvimento de software orientadas a aspecto,para evitara perda de dados.

RA- 06 O sistema deve armazenar dados coletados no campo.

RA- 07 A localização do GPS deve ser usadapara mostrar o local onde ocorreu a coleta de dados.

RA- 08 O sistema deve identificar o usuário.

RA- 09 O sistema deve registrar a data e a hora da coleta de dados.

RA- 10 O sistema deve permitir a possibilidade de carregar informações sobre quais dados seriam coletados.

Tabela 16 - Requisitos arquiteturais do trabalho de Waku et al., (2015)

(Conclusão) Requisito

Arquitetural

Descrição

RA- 12 O sistema deve exportar dados para outros sistemas ou criar uma representação de banco de dados externa, como planilhas.

RA- 13 O sistema deve permitir a validação dos dados coletados.

RA- 14 O sistema deve permitir visualização do mapa atual da área de coleta de dados

RA- 15 O sistema precisa prevenir a perda de dados e falha do serviço de coleta de dados, porque

se a base de dados da aplicação foi perdida ou corrompida, o principal objetivo do sistema será afetado, e o sistema não irá garantir a integridade e disponibilidade dos dados.

RA- 16 O sistema pode não ser afetado pelo baixo nível de bateria do dispositivo móvel, porque a coleta de dados pode levar várias horas, e enquanto o nível da bateria estiver baixo, o sistema não estará disponível.

RA- 17 O sistema deve garantir que falha nos serviços de coleta de dados não ocorreram porque se o sistema não puder armazenar e recuperar os dados corretamente, o sistema não será confiável e, se o serviço não estiver sendo executado, o sistema não estará disponível

RA- 18 O sistema deve garantir que operações básicas de coleta de dados tais como armazenar e recuperar informações são executadas em menos de um segundo, porque se isso não ocorrer, os usuários podem não coletar dados mais rapidamente e o desempenho geral seria comprometida. Fonte: Waku et al., 2015.

Utilizando o desenvolvimento orientado a aspecto o trabalho pretende dividir sua solução em duas partes um modelo de recursos juntamente com uma view de aspecto- recurso e a elaboração de uma arquitetura de linha de produto de software utilizando o método AO-FarM, abaixo segue a imagem do modelo de recursos e a descrição dos recursos.

Figura 24 - Modelo de recursos parcial para a arquitetura. Fonte: Waku et al., 2015. • Mobile number: Quantidade de dispositivos necessários para a realização da coleta

móveis levados para o campo. De acordo com o número de horas e a configuração do aparelho, pode haver a necessidade de utilização de mais de um dispositivo.

• Loading: Carregador de informações de coletas anteriores. Existem três tipos de carregamento de dados Indivíduo com História Prévia, Missão (uma coleção de indivíduos identificados) ou Expedição (coleção de missões).

• Data edition: Recurso opcional de edição dos dados.

• Dispatching: Recurso que cuida do despacho de dados para o servidor, podendo ser executado de duas formas, para múltiplos servidores ou um servidor único.

• Data Storage: Recurso que agrupa o conjunto de diretrizes para registro de dados. Pode gravar dados com SQLite na memória interna e com o recurso Storage Format Type na memória externa. A utilização da memória externa é opcional, gravando os dados em diversos formatos, por exemplo, Excel, CSV, JSON ou XML).

• Login: Recurso que autentica o usuário.

• Data Synchronization: Recurso que compreende a sincronização de dados realizada em campo entre os dispositivos móveis que estão em campo. O que possibilita que o usuário possa repassar os dados de um dispositivo para outro, caso haja algum

problema com o dispositivo móvel em uso, para que a coleta possa continuar. O processo pode ocorrer utilizando Wi-Fi, Bluetooth, ou SDCARD.

• Data Collection: Recurso que simboliza a aquisição de dados. Este recurso utiliza do recurso de Armazenamento de Dados Data Storage, podendo guardar nas memórias interna ou externa. Este recurso também pode usar o recurso de Validação, validation feature.

• Data Validation: Recurso que de acordo com as regras de negócio, verifica a consistência dos dados.

• Visualization of Collected Data: Recurso que implementa diferentes formas de cisualizar os dados. Este recurso é opcional.

Waku et al., (2015) também discorre sobre o conceito de recursos transversais (Crosscutting Features), estes são características do sistema presentes e influentes em relação a outros recursos.

Os recursos transversais identificados dentro do contexto do domínio de coleta de dados foram os recursos de bloqueio de função (Block Usage) e monitor de bateria (Battery Monitor) que são responsáveis respectivamente por bloqueio de funções, como carregar, despachar e coletar dados para o servidor e o gerenciamento e estima da quantidade de energia disponível na bateria do dispositivo móvel, para que seja possível verificar se as atividades desempenhadas pela aplicação poderão ser completamente executadas sem erros oriundos do baixo nível de energia da bateria.

Figura 25 - View de aspecto-recurso exibindo os recursos transversais. Fonte: Waku et al., 2015.

A figura abaixo demonstra a arquitetura proposta por Waku et al. (2015), sendo esta uma representação em componentes das features ou recursos modelados no

modelo de recursos. É importante ressaltar que apesar do diagrama apresentar uma forte relação entre seus componentes e os recursos (features) do modelo de recursos, alguns recursos não necessitam serem representados como componentes pois são representações abstratas de um componente da arquitetura que não é nem hardware e nem software, como por exemplo, a feature Mobile Number necessita ser explicitamente definida na arquitetura, porém representa o número de dispositivos móveis que serão utilizados no processo de coleta de dados móveis.

Figura 26 - Arquitetura para o domínio de coleta de dados. Fonte: Waku et al., 2015. • Data Collection component: Mapeamento do recurso de coleta de dados. O recurso

de validação de dados (Data Validation) é utilizado pelo recurso de coleta de dados (Data Collection).

• Data Validation component: Mapeamento do recurso Validação de Dados (Data Validation). Esse componente é opcional pois o recurso também é opcional.

• Data Storage component: Mapeamento dos recursos armazenamento de dados (Data Storage), Memória interna do telefone (Internal Phone Memory), SQLite, Redundância de armazenamento (Storage Redundancy) e SDCard. Os componentes mapeados utilizam o componente formato de armazenamento (Storage Format). • Dispatching Data component: Mapeamento do recurso de Dispatching além de seus

• Data Synchronization component: Mapeamento dos recursos sincronização de dados (Data Synchronization), redundância de armazenamento (Storage Redundancy), o número do celular (Mobile Number), WI-FI e Bluetooth

• Loading Data component: Mapeamento dos recursos Loading Data e seus sub recursos.

• Visualization of Collected Data component: Mapeamento do recurso (Visualization of Collected Data).

• Login component: Mapeamento do recurso de Login.

• Block Usage component: Mapeamento do recurso transversal (Block Usage). • Battery Monitor component: Mapeamento do recurso transversal Battery Monitor. • Data Storage component: Componente que oferece duas APIs, uma com o recurso

de redundância de dados e outra sem este recurso. Dando a escolha de tolerância a falhas para o cliente.