INSTITUTO DE COMPUTAÇÃO
Edson Riberto Bollis
e-Phenology Collector: Uma solução robusta para
coleta de dados de campo usando plataformas móveis.
CAMPINAS
2016
e-Phenology Collector: Uma solução robusta para coleta de
dados de campo usando plataformas móveis.
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: Prof. Dra. Cecília Mary Fischer Rubira
Este exemplar corresponde à versão final da Dissertação defendida por Edson Riberto Bollis e orientada pela Prof. Dra. Cecília Mary Fischer Rubira.
CAMPINAS
2016
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
Bollis, Edson Riberto,
B638e Bole-Phenology Collector : uma solução robusta para coleta de dados de campo usando plataformas móveis / Edson Riberto Bollis. – Campinas, SP : [s.n.], 2016.
BolOrientador: Cecília Mary Fischer Rubira.
BolDissertação (mestrado) – Universidade Estadual de Campinas, Instituto de Computação.
Bol1. Engenharia de software. 2. Sistemas de computação - Confiabilidade. 3. Tolerância à falha (Computação). 4. Engenharia de linha de produto de
software. 5. Software - Confiabilidade. 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: e-Phonology Collector : a robust solution for data collection using
mobile plataforms
Palavras-chave em inglês:
Software engineering
Computer systems - Reability Fault-tolerant computing
Software product line engineering software - Reability
Á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] Leonardo Pondian Tizzei
Eliane Martins
Data de defesa: 26-02-2016
Programa de Pós-Graduação: Ciência da Computação
INSTITUTO DE COMPUTAÇÃO
Edson Riberto Bollis
e-Phenology Collector: Uma solução robusta para coleta de
dados de campo usando plataformas móveis.
Banca Examinadora:
• Prof. Dra. Eliane Martins
Instituto de Computação - UNICAMP
• Prof. Dr. Leonardo Pondian Tizzei IBM Research - IBM
• Prof. Dra. Cecília Mary Fischer Rubira Instituto de Computação - UNICAMP
A ata da defesa com as respectivas assinaturas dos membros da banca encontra-se no processo de vida acadêmica do aluno.
Agradeço à minha orientadora, Professora Cecília Rubira e, ao Professor Ricardo Torres, à Professora Patrícia Morellato, aos professores e colegas do IC, bem como aos meus pais Riberto e Silvia, minhas irmãs Vanessa e Bianca, meus cunhados João e Felipe, amigos que moraram comigo e principalmente minha namorada Ana Paula. Agradeço também aos colaboradores Gustavo Waku, Bruna Albertoni, ao projeto DEVASSES e às agências CAPES, financiadora de minha bolsa, Fapesp e Instituto Virtual FAPESP-Microsoft (Processo 2013/50155-0), financiadores do projeto e-phenology.
O uso de dispositivos móveis e suas plataformas para coleta de dados de campo em ambientes incertos, como florestas e plantações, traz desafios importantes para o estudo de requisitos não funcionais voltados a estes domínios. Problemas como deficiência no acesso a redes de telecomunicações, hostilidade que a localização de coleta proporciona aos dispositivos, defeitos de software sem possibilidade de manutenção, tempo limitado de uso devido ao tempo de bateria e demora ao efetuar o processamento de operações são comuns ao se trabalhar com a coleta de dados de campo. Estes problemas, que podem ser resumidos como perda de dados, indisponibilidade do sistema, erro nos serviços providos e demora no processamento ou retorno das operações, estão ligados a propriedades de qualidade da dependability relativa a plataformas e dispositivos móveis, respectivamente expressas como availability, reliability, data integrity e performance. Então, para resolver estes problemas, propõe-se o uso de uma infraestrutura que utilize técnicas de tolerância a falhas como redundância para lidar com a dependability em plataformas móveis para coleta de dados de campo. Essa infraestrutura, chamada R-SPL-DC, provê suporte à criação de sistemas de coleta de dados para subdomínios da coleta de dados de campo e suporte à proteção dos dados coletados, produzindo um software chamado e-Phenology Collector para o domínio de coleta de dados fenológicos. O e-Phenology Collector e, consequentemente, a R-SPL-DC foram avaliados por meio de seu uso em campo em uma pesquisa no domínio da fenologia que serviu para validar os principais objetivos ligados a este trabalho: exercitar a solução proposta; validar técnicas de tolerância a falhas em dispositivos móveis; e validar a infraestrutura criada para plataformas móveis.
The use of mobile devices and their platforms to field data collection in uncertain en-vironments such as forests and plantations bring significant challenges for the study of non-functional requirements aimed to these domains. Issues like deficit of access to telecommunication networks, hostility that collection location provides to devices, soft-ware failures with no maintainability, time-limited use due to battery life and delay in effecting processing operations are common when working with the field data collection. These problems, which can be summarized as loss of data, system downtime, error in the provided services and delay in processing or return of the operations, are linked to qual-ity properties of dependabilqual-ity on mobile platforms and devices, respectively expressed as availability, reliability, data integrity and performance. So, to solve these problems, it proposes the use of an infrastructure that uses fault tolerance techniques as redundancy to deal with the dependability on mobile platforms to collect field data. This infrastructure, called R-SPL-DC, provides support to the creation of data collection for sub-domains of field data collection and supports the protection of the collected data systems, produc-ing a software called e-Phenology Collector for field collection of phenological data. The e-Phenology Collector and, therefore, the R-SPL-DC were assessed by means of their use in field research in the field of phenology which served to validate the main objectives linked to this work: exercise the proposed solution; validate techniques for fault tolerance on mobile devices; and validate the infrastructure created for mobile platforms.
2.1 Transectos do Projeto e-phenology [2]. . . 23 2.2 Brotamento [11] . . . 24 2.3 Botão [11] . . . 24 2.4 Antese [11] . . . 24 2.5 Fruto Verde/Maduro [11] . . . 24 2.6 Queda Foliar [11] . . . 24
2.7 Classificação do conceito de Dependability [42] . . . . 25
2.8 Exemplo de Componente [50] . . . 29
2.9 Exemplo de Arquitetura Utilizando Componentes. . . 30
2.10 Exemplo de um feature model. . . . 32
2.11 Exemplo de uma aspect-feature view. . . . 33
2.12 Diagrama de Classes COSMOS*-VP. . . 34
2.13 Diagrama de Classes do Conector do COSMOS*. . . 35
2.14 Diagrama de Classes do Conector do COSMOS*-VP. . . 36
3.1 Feature Model parcial para o Domínio de Coleta de Dados de Campo . . . 39
3.2 Aspect-Feature View para o Domínio de Coleta de Dados de Campo. . . . . 40
3.3 Robust SPL Architecture for Data Collection - R-SPL-DC . . . 43
3.4 Arquitetura Detalhada do e-Phenology Collector. . . 45
3.5 Diagrama de classes do componente DataStorageMgr. . . . 46
3.6 Diagrama de classes do componente StorageFormatMgr. . . . 47
3.7 Diagrama de classes do componente Loading. . . . 48
3.8 Diagrama de classes do componente Dispatching. . . . 48
3.9 Tela de Login e Tela de Carga Inicial de Dados. . . 54
3.10 Tela de Menu, Tela de Limpeza/Importação e Tela de Envio de Dados. . . 55
3.11 Tela de Coleta de Dados e Tela de Coleta Adicional de Dados. . . 56
4.1 Localização GPS dos Transectos . . . 62
4.2 Gráfico de Decaimento da Bateria por Tempo em Campo . . . 64
4.3 Comparação entre salvar indivíduos com redundância e sem redundância. . 67
C.1 Modelo de Casos de Uso Geral para o Servidor . . . 99
C.2 Modelo de Casos de Uso Geral para o Dispositivo Móvel . . . 100
AO-Analysis Aspect-Oriented Analysis. 29, 36 XPIs Crosscutting Program Interfaces. 30–32, 38
AO-FArM Aspect-Oriented Feature Architecture Mapping. 29, 33, 38, 40 AOSD Aspect-Oriented Software Development. 16, 27, 30, 52, 53, 64 CBD Component-Based Development. 16, 25, 30, 53, 64
CDU cenários de uso. 18, 37, 59 DR Data Redundancy. 23
DSR Data Storage Redundancy. 23, 37, 61
GPS Global Positioning System’s. 13, 18, 52, 55, 56 HR Hardware Redundancy. 23, 37
PLA Product Line Architecture. 27
R-SPL-DC Robust Software Product Line Architecture for Data Collection. 13–16, 33,
39, 40, 62–64
RDS Redundancy in Data Structure. 23, 37, 61 RF requisitos funcionais. 17, 35
RNF requisitos não funcionais. 18, 35–37, 60
SPL Software Product Line. 11, 14, 16, 27, 39, 52, 53 SSDD Sistema de Suporte a Decisão da Dengue. 17
Siglas 10 1 Introdução 14 1.1 Problema . . . 15 1.2 Solução Proposta . . . 17 1.3 Contribuições . . . 17 1.4 Organização da Dissertação . . . 18 2 Fundamentação Teórica 19 2.1 O Domínio de Dispositivos e Plataformas Móveis . . . 19
2.2 O Domínio de Coleta de Dados de Campo . . . 20
2.2.1 A coleta de dados . . . 20
2.2.2 Requisitos da Coleta de Dados de Campo . . . 21
2.2.3 O Projeto e-phenology . . . 22
2.3 Dependability, Tolerância a Falhas e Modelo de Falhas para Plataformas Móveis . . . 25
2.3.1 Conceitos de Dependability . . . . 25
2.3.2 Tolerância a Falhas . . . 27
2.3.3 Modelo de Falhas para Plataformas Móveis . . . 27
2.4 Arquitetura de Software e Padrões Arquiteturais . . . 28
2.5 Component-Based Development - CBD . . . . 29
2.5.1 Conceito de CBD . . . 29
2.5.2 Arquitetura Baseada em Componentes . . . 30
2.5.3 Aspect-Oriented Software Development -AOSD . . . . 30
2.6 Software Product Line Development . . . . 31
2.6.1 Terminologia . . . 31 2.6.2 Análise de Domínio . . . 32 2.6.3 Aspect-Oriented Analysis . . . . 33 2.6.4 Projeto Arquitetural . . . 33 2.6.5 Implementação da Arquitetura . . . 34 3 e-Phenology Collector 37 3.1 Metodologia de Pesquisa . . . 37 3.2 Elicitação de Requisitos . . . 37
3.3 Criação do Modelo de Falhas . . . 38
3.4 Criação do Feature Model . . . 39
3.5 Criação da Aspect-Feature View . . . . 40
3.6 Mapeamento dos Requisitos Não-Funcionais . . . 41
3.8 Implementação do e-Phenology Collector . . . 44
3.8.1 Arquitetura Detalhada . . . 45
3.8.2 Detalhes de Implementação . . . 48
3.9 Aplicativo para Android: e-Phenology Collector . . . 54
3.9.1 Tela de Login . . . 54
3.9.2 Tela de Carga Inicial de Dados . . . 55
3.9.3 Tela de Menu . . . 55
3.9.4 Tela de Limpeza e Importação dos Dados . . . 56
3.9.5 Tela de Envio de Dados . . . 56
3.9.6 Tela de Coleta de Dados . . . 56
3.9.7 Tela de Coleta Adicional de Dados . . . 57
3.10 Trabalhos Relacionados . . . 57
4 e-Phenology Collector: Trabalhos de Campo 59 4.1 Objetivos . . . 59
4.1.1 Exercitar a Solução Proposta . . . 59
4.1.2 Avaliar Técnicas de Tolerância a Falhas em Dispositivos Móveis . . 60
4.1.3 Validar a Infraestrutura Criada para Plataformas Móveis . . . 60
4.2 Questões de Pesquisa . . . 60
4.3 Condições e Histórico do Trabalho de Campo . . . 61
4.4 Primeira Expedição de Campo . . . 62
4.4.1 Relato da Primeira Expedição . . . 62
4.4.2 Conclusões da Primeira Expedição . . . 63
4.5 Segunda Expedição de Campo . . . 63
4.5.1 Relato da Segunda Expedição . . . 63
4.5.2 Conclusões da Segunda Expedição . . . 64
4.6 Terceira expedição de Campo . . . 64
4.6.1 Relato da Terceira Expedição . . . 64
4.6.2 Conclusões da Terceira Expedição . . . 65
4.7 Quarta Expedição de Campo . . . 65
4.7.1 Relato da Quarta Expedição . . . 65
4.7.2 Conclusões da Quarta Expedição . . . 66
4.8 Resultados do e-Phenology Collector . . . 66
4.8.1 Ameaças à validade do e-Phenology Collector . . . 68
5 Conclusões e Trabalhos Futuros 69 5.1 Conclusões . . . 69
5.2 Contribuições . . . 70
5.3 Publicação . . . 70
5.4 Trabalhos Futuros . . . 71
Referências Bibliográficas 72
A Documento de Requisitos Geral 77
C.2 Sistema Mobile . . . 100
Introdução
O crescimento mundial do número de dispositivos móveis e suas plataformas, como celu-lares, tablets e smartphones com diferentes sistemas operacionais, vem provendo maior capacidade de processamento e armazenamento portátil de informações. Esses dispositi-vos têm se popularizado e, com o investimento e trabalho de diversas empresas do ramo de tecnologia, sua qualidade, sua disponibilidade no mercado e seu poder de processamento têm atingido níveis excepcionais. Segundo Pereira et al. [35], seu uso em pesquisas de campo é totalmente justificável, pois, com o advento da qualidade e da disponibilidade, os dispositivos tornaram-se acessíveis e qualificados para uso neste domínio.
Hoje, sistemas de coleta de dados, utilizando dispositivos móveis são comuns a vários subdomínios do domínio de coleta de dados de campo. Dentre estes, podemos citar as ciências físicas e sociais, a história, os negócios, as pesquisas demográficas, a agricultura, a biologia e a geologia. Esses subdomínios têm um conjunto similar de requisitos funcionais e não-funcionais provindos do domínio da coleta de dados de campo, o que torna este trabalho propenso a utilização de Software Product Line (Linha de Produto de Software - SPL) como ferramenta para desenvolver o estudo da variabilidade de software, ou seja, propenso ao estudo das mudanças e configurações de software a partir de um contexto de um subdomínio [37].
Porém, segundo Oliveira e Nascimento [34], existem desafios em relação a telecomuni-cações e Internet em áreas geograficamente remotas do Brasil, o que atrapalha o uso de sistemas online gerados para coleta de dados. Um exemplo desta situação é apresentado pelo trabalho da pesquisadora de Santana [8], que promoveu um estudo de caso para le-vantar as deficiências de comunicação no interior da Bahia e concluiu que áreas distantes de grandes centros urbanos têm acesso restrito à infraestrutura de telecomunicações. Com isto, os sistemas de coleta de dados de campo ficam impossibilitados de fazer o tráfego online de dados do campo para as bases de pesquisa.
Em campo, se não há conexão com a Internet, grandes desafios devem ser contornados, como a hostilidade que o campo proporciona aos dispositivos móveis, a possibilidade de perda de dados e defeitos de software sem possibilidade de manutenção. O campo é um ambiente no qual existe maior probabilidade de acontecer imprevistos devido às variáveis ambientais, como o risco de derrubar o aparelho, a possibilidade de bater em árvores ou até mesmo a possiblidade de encharcar o dispositivo devido à chuva, colocando em risco os dados de coleta sem que existam técnicos especializados para contornar tais problemas.
Adicionalmente aos desafios relacionados às falhas de comunicação em campo, cabe ressaltar que dispositivos móveis têm tempo limitado de uso. Isso geralmente acontece por causa da luz de plano de fundo ligada constantemente, o que aumenta o consumo de bateria [43]. Essa sobrecarga de consumo normalmente não ocorre no dia a dia, quando o celular é utilizado apenas de tempos em tempos, sem a constância exigida pela coleta de dados.
Existem também, desafios relativos à experiência que o usuário tem ao utilizar o sistema e ao tempo fixo das expedições de pesquisa. Por exemplo, se o usuário tem um dia para coletar todos os dados de uma localização e o sistema tem um comportamento lento e ineficaz, isso incomoda o usuário e faz com que a coleta de dados dure mais tempo do que o estimado, tornando-a, por vezes, inviável.
Por final, os estudos sobre robustez, entrega de serviço correto mesmo sob situações adversas decorrentes do uso de sistemas em ambientes incertos [30], relacionado a disposi-tivos e plataformas móveis são escassos e não oferecem argumentos para que pesquisadores confiem totalmente em seu uso em campo. Então, para satisfazer essa lacuna, este tra-balho propõe-se a responder: se é possível integrar técnicas de engenharia de software para produzir sistemas robustos para dispositivos e plataformas móveis; se técnicas de engenharia de software podem contornar os desafios existentes em campo; se é possivel criar uma infraestrutura que consiga beneficiar todos os subdomínios da coleta de dados de campo a partir do uso de variabilidade; e se o uso correto de técnicas de engenharia de software afeta a coleta de dados.
1.1
Problema
O cenário de desenvolvimento, para plataformas móveis, traz, intrinsecamente, vários desafios como tempo limitado do uso de bateria, limitações relativas à velocidade e à disponibilidade do acesso à Internet, fragilidade do equipamento eletrônico e menor pro-cessamento relativo a computadores convencionais. Quando o cenário é estendido para o domínio da coleta de dados de campo, surgem limitações como não flexibilidade relaci-onada ao tempo das expedições de coleta, impossibilidade de acesso à energia elétrica e necessidade de coletar dados em áreas geograficamente remotas de pesquisa. Assim, as aplicações, para coleta de dados utilizando plataformas móveis, devem lidar com ambien-tes hostis, sem comunicação com as bases de dados e tempo restrito de duração da coleta de dados, tanto pelo tempo das expedições quanto pelo tempo de duração da bateria dos dispositivos móveis.
Problemas relativos a plataformas móveis, como falta de conexão com Internet, nível limitado de bateria, fragilidade dos dispositivos móveis e menor poder de processamento, geram, no processo de desenvolvimento dos sistemas, requisitos não-funcionais, respecti-vamente expressos como data integrity, availability, reliability e performance.
Data Integrity é uma propriedade, que o sistema deve proporcionar, relativa à não
ocorrência de alterações de dados indevida [42] ou como o sistema deve armazenar da-dos corretamente para que se tenha confiança de que informações não serão perdidas ou armazenadas erroneamente. Availability é uma propriedade a qual significa que o
sis-tema, quando em campo, deve estar pronto para o uso [42], ou seja, o sistema deve estar operando enquanto o usuário estiver coletando dados. Reliability é a propriedade que o sistema tem de entregar o serviço correto [42], ou seja, se em campo ocorrer uma falha no banco de dados, o sistema deve se recuperar e ainda deve coletar os dados correta-mente. Performance é definido como o comportamento do sistema durante o tempo de processamento [4]. Quando técnicas complexas de engenharia de software, que aumentam o processamento do software, são aplicadas, o dispositivo móvel muda seu comportamento temporal, tendo um comportamento mais lento e ineficiente para coletar dados.
As propriedades do sistema chamadas Data Integrity, Availability, Reliability e
Perfor-mance podem ser resumidas como problemas relativos a perda de dados, indisponibilidade
do sistema, erro nos serviços providos e demora no processamento ou retorno de serviços. Esses problemas devem ser levados em consideração na construção de quaisquer sistemas que sejam desenvolvidos para plataformas móveis.
Atualmente, existem trabalhos relacionados ao desenvolvimento de softwares para co-leta de dados de campo utilizando dispositivos móveis, como o de Hartung et al. [20] e o de Dos Santos et al. [10], que lidam com a coleta de dados, entretanto, sem abordar requisitos não-funcionais relacionados ao uso de plataformas móveis.
O trabalho de Hartung et al. [20] descreve um sistema para coleta de dados de campo que é um rápido meio para construir aplicações. Este software é geral e pode usar um conjunto de operações do dispositivo móvel dando suporte a várias linguagens de comuni-cação para importar e exportar dados. O referido trabalho expõe um método para gerar aplicações de coleta de dados.
Dos Santos et al. [10] descreve o Projeto Maritaca, que é uma ferramenta web para criação de diferentes aplicações móveis para coleta de dados baseados em questionários. O usuário cria questionários customizados que automaticamente geram uma aplicação para que estes questionários possam ser aplicados. Isto permite a coleta de dados relacionada a uma grande quantidade de subdomínios, podendo reunir dados como som, localização GPS, texto e imagens, sendo que este projeto utiliza uma arquitetura baseada em cliente servidor para enviar e receber dados de coleta.
Acker et al. [1] não têm o objetivo de gerar uma aplicação para coleta de dados, mas leva em consideração requisitos não-funcionais para pesquisar o uso de injeção de falhas em sistemas de software baseados em plataformas móveis utilizando o modelo de falhas proposto por Cristian [7]. Este modelo especifica falhas de comunicação para sistemas distribuídos e Acker et al. [1] utiliza-o para recebimento e interferência de mensagens para causar falhas na comunicação entre servidores e dispositivos móveis.
O trabalho de Acker et al. [1] não leva em consideração a impossibilidade do uso de Internet, pois tem outros objetivos; porém, propõe, como trabalho futuro, a geração de um modelo de falhas para dispositivos móveis e o estudo de seu comportamento baseado na implementação de técnicas de tolerância a falhas, o que mostra a necessidade de discussões sobre problemas e inadequações relacionados a dispositivos móveis.
1.2
Solução Proposta
Este trabalho propõe a criação de uma infraestrutura para resolver problemas existentes em plataformas móveis atuais utilizando técnicas de tolerância a falhas. Essa infraestru-tura, chamada Robust Software Product Line Architecture for Data Collection (R-SPL-DC), provê suporte à criação de sistemas de coleta de dados para subdomínios da coleta de dados e suporte à proteção dos dados coletados, em particular foi desenvolvida uma aplicação chamada e-Phenology Collector para o domínio de coleta de elementos fenoló-gicos.
A infraestrutura foi denominada com o adjetivo de robusta, por causa do uso de técnicas de tolerância a falhas aplicadas para minimizar os problemas decorrentes de situações adversas que o campo proporciona. A R-SPL-DC lida com propriedades de
dependability, tais como a reliability, data integrity e availability, mantendo a performance
do sistema aceitável. Esta infraestrutura apoia:
1. o uso de um ou mais dispositivos para lidar com a coleta de dados de campo de longa duração;
2. a sincronização de dados para trocar informações entre dispositivos;
3. a redundância de armazenamento para evitar a perda de dados no dispositivo;
4. o uso de formatos de armazenamento distintos para compartilhar o banco de dados com aplicativos de terceiros;
5. e o monitoramento das operações básicas, tais como o carregamento e envio de informações para o servidor, a fim de evitar perda e corrupção de dados durante o processamento.
A R-SPL-DC foi validada por meio do uso do e-Phenology Collector para pesquisa do domínio da fenologia, ou seja, um sistema de software para o estudo dos eventos periódicos do ciclo de vida dos animais e das plantas ligados à influência das variações sazonais do clima[32]. Este sistema serviu para aplicar e avaliar os principais objetivos relativos a este trabalho: exercitar a solução proposta; validar técnicas de tolerância a falhas em dispositivos móveis; e validar a infraestrutura criada para plataformas móveis.
1.3
Contribuições
Este trabalho contribuiu para o estudo e resolução dos principais problemas existentes em plataformas móveis; isto ocorreu por meio da criação da infraestrutura R-SPL-DC sendo aplicada ao e-Phenology Collector que é uma aplicação robusta para dispositivos móveis utilizando o domínio de coleta de dados de campo voltado a fenologia. Como consequência deste desenvolvimento, também foram gerados um modelo de falhas para dispositivos móveis, um modelo de requisitos funcionais e não-funcionais para coleta de dados e um estudo das principais técnicas de tolerância a falhas que podem ser utilizadas em dispositivos móveis.
Contribuiu também para avançar os trabalhos de Tizzei [47] e Waku [51]: integrando técnicas de tolerância a falhas no desenvolvimento de SPL com componentes e aspectos; e utilizando aspectos em dispositivos móveis como forma de promover o uso de técnicas de tolerância a falhas.
A partir deste trabalho, foi publicado um artigo no Simpósio Brasileiro de Componen-tes, Arquiteturas e Reutilização de Software (SBCARS) para divulgar os estudos desen-volvidos:
• Gustavo M. Waku, Edson R. Bollis, Cecilia M.F. Rubira, and Ricardo da S. Torres. A Robust Software Product Line Architecture for Data Collection in Android Plat-form. In Software Components, Architectures and Reuse (SBCARS), 2015 Ninth Brazilian Symposium on, pages 31–39. IEEE, 2015
Além disso, durante o desenvolvimento do projeto, foram discutidos e analisados os principais requisitos funcionais e não-funcionais do domínio da coleta de dados de campo, provendo, assim, uma base sólida para pesquisadores que desejam efetuar o desenvolvi-mento de sistemas de software voltados a plataformas móveis.
1.4
Organização da Dissertação
Esta dissertação está organizada em capítulos referentes aos estudos desenvolvidos du-rante o trabalho de mestrado: O Capítulo 2 traz a fundamentação teórica relativa aos conceitos utilizados neste trabalho; o Capítulo 3 mostra a proposta de desenvolvimento da infraestrutura R-SPL-DC e o aplicativo e-Phenology Collector; o Capítulo 4 expõe o trabalho de desenvolvimento da aplicação e-Phenology Collector, sua validação e descreve as sucessivas visitas a campo; e o Capítulo 5 traz as conclusões e trabalhos futuros.
Fundamentação Teórica
Este capítulo descreve os principais conteúdos, métodos e técnicas utilizados para criação da infraestrutura chamada Robust Software Product Line Architecture for Data
Collec-tion (R-SPL-DC) e para o desenvolvimento do software para coleta de dados de campo
chamado e-Phenology Collector, os quais serão apresentados no Capítulo 3.
As seções 2.1 e 2.2 são responsáveis por descrever os domínios escolhidos para o desen-volvimento deste trabalho, mostrando o ambiente de desendesen-volvimento, os requisitos fun-cionais e não-funfun-cionais dos domínios, os cenários de uso e o local de uso do e-Phenology Collector.
A seção 2.3 apresenta os conceitos de dependability, os conceitos de tolerância a falhas e elenca, em um modelo de falhas, os principais problemas existentes no domínio de plataformas móveis. Estes conceitos são responsáveis por embasar teoricamente os motivos pelos quais a infraestrutura gerada tem a característica de ser robusta.
As seções 2.4, 2.5 e 2.6 são responsáveis por mostrar os conceitos do modelo de arqui-tetura responsáveis por descrever a infraestrutura R-SPL-DC. O uso de Software Product
Line (SPL) para desenvolvimento da arquitetura foi motivada pela necessidade de
desen-volver uma infraestrutura que permitisse derivar aplicações distintas relativas à subdo-mínios da coleta de dados de campo. O uso de Component-Based Development (CBD) e
Aspect-Oriented Software Development (AOSD) foram escolhidos para melhorar a
capaci-dade de manutenção dos sistemas de software a serem instanciados a partir da R-SPL-DC. Ao final do capítulo, a seção 2.6.5 ainda descreve o modelo de componentes COSMOS*-VP que expõe como a R-SPL-DC pôde ser traduzida no e-Phenology Collector.
2.1
O Domínio de Dispositivos e Plataformas Móveis
Dispositivos móveis são dispositivos eletrônicos e portáteis que proveem importante poder de processamento, memória, comunicação e sensores para coleta de dados. Exemplos desses dispositivos são celulares, tablets, computadores de bordo e GPS.
Plataformas móveis, segundo Kortuem [26], são middlewares para dispositivos móveis que proveem modelos de aplicações e paradigmas de programação para propiciar suporte à colaboração, à mobilidade, à heterogeneidade e à rapidez de mudanças. Exemplos de plataformas móveis estão presentes na maioria dos dispositivos móveis como os sistemas
operacionais Android [39], IOS [22] e Windows Phone [31].
Hoje, as plataformas e dispositivos móveis são utilizados para múltiplos fins, como reprodução de música, acesso à Internet, rodar jogos e propiciar a comunicação entre as pessoas. Seu futuro é promissor, pois trabalhos, como os de Lane et al. [27], Gehlen
et al. [18] e Knutsen [25], descrevem que, atualmente, vê-se uma facilidade de acesso
e aumento considerável de seu uso pela população, mas existem desafios importantes a serem ultrapassados, como fragilidade de suas telas, tempo limitado de bateria e menor poder de processamento relativo aos computadores portáteis.
Esse ambiente proporciona um domínio ótimo para o desenvolvimento e teste de apli-cações, mas extremamente dependente de eletricidade por causa do tempo de duração da bateria e dependente de Internet para comunicação e acesso a dados.
2.2
O Domínio de Coleta de Dados de Campo
Esta seção foi separada em três subseções, sendo que a subseção 2.2.1 faz uma descrição geral do que é coleta de dados de campo, a subseção 2.2.2 expõe os Requisitos da coleta de dados de campo e a subseção 2.2.3 expõe as informações do subdomínio da coleta de dados de campo chamado domínio fenológico. A subseção 2.2.2 foi criada através da análise de projetos como Projeto Maritaca [10], Sistema de Suporte a Decisão da Dengue (SSDD)1, Design Software for field data collection [20] e Projeto e-phenology2[52]
utilizando a engenharia reversa, que é o processo de análise de um sistema para identificar seus componentes e suas relações. A subseção 2.2.3 baseou-se apenas nos conceitos de fenologia e no Projeto e-phenology[52].
2.2.1
A coleta de dados
A coleta de dados de campo é comum a vários domínios como ciências físicas e sociais, a história, os negócios, as pesquisas demográficas, a agricultura, a biologia e a geologia, tendo como característica principal os trabalhos efetuados em ambientes não controlados como ruas, plantações, florestas, desertos, rios, entre outros. Tradicionalmente os pesqui-sadores, que efetuam a coleta de dados, vão aos locais de coleta e através de observações ou entrevistas descrevem os dados coletados em esquemas ou planilhas de papel.
Os pesquisadores nem sempre tem liberdade e disponibilidade relacionada ao tempo para anotar os dados e ao tempo total para coletar os dados. A duração de eventos naturais como dia e noite, chuva, vento e queimada podem influenciar na coleta, atrapalhando ou melhorando significativamente as condições de trabalho e tempo. Também as condições naturais podem oferecer riscos ao pesquisador e aos métodos de armazenamento como cavernas podem oferecer riscos de desmoronamento e chuvas podem oferecer perigos a planilhas de papel.
Em resumo, os pesquisadores tradicionalmente vão a ambientes hostis com o objetivo de obter dados utilizando folhas de papel, sendo que normalmente têm tempo determinado e problemas como chuva e luminosidade para se conseguir efetuar os trabalhos de campo.
1http://www.cs.colostate.edu/ddss/index.html (Julho de 2015). 2
2.2.2
Requisitos da Coleta de Dados de Campo
Os principais requisitos funcionais (RF) do domínio de coleta de dados de campo, ne-cessários para o entendimento deste trabalho, são elencados a partir da necessidade de construção de um sistema para plataformas móveis:
[RF1] : O sistema precisa permitir a coleta e o armazenamento de dados
correta-mente;
[RF2] : O sistema deve permitir a utilização da localização dada por Global Positi-oning System’s (GPS) para saber onde a coleta de dados ocorreu;
[RF3] : O sistema precisa identificar o usuário da coleta;
[RF4] : O sistema precisa armazenar o dia e o horário em que foi feita a coleta; [RF5] : O sistema deve permitir o carregamento de informações externas sobre o
que se deve coletar;
[RF6] : O sistema deve persistir às informações coletadas, enviando-as para um
servidor;
[RF7] : O sistema deve permitir a exportação de dados para outros sistemas, criando
uma representação externa, como planilhas ou arquivos em outros formatos;
[RF8] : O sistema deve possibilitar a validação dos dados de coleta;
[RF9] : O sistema deve permitir a visualização dos dados coletados em algum
sistema de representação de dados como mapas ou esquemas de representação.
Os requisitos não funcionais (RNF) da coleta de dados de campo estão relacionados a atributos de qualidade como reliability, availability, data integrity e performance para permitir que o sistema rode normalmente em missões destinadas a acontecer em ambientes críticos. Os requisitos não-funcionais são:
[RNF1] : O sistema precisa prevenir-se para que não exista perda de dados e evitar
falhas no serviço de coleta de dados para que não afetem o banco, pois se o banco de dados da aplicação for perdido ou corrompido, a maior meta do sistema será afetada e o sistema não garantirá a data integrity;
[RNF2] : O sistema não pode ser afetado pelo baixo nível de bateria dos dispositivos
móveis, pois uma coleta de dados pode demorar várias horas, levando a bateria à atingir seu nível crítico e fazendo com que o sistema fique indisponível, o que prejudicaria sua availability;
[RNF3] : O sistema deve garantir que não existam falhas no serviço de coleta de
dados, pois se isto acontecer, o sistema não poderá armazenar e recuperar dados corretamente, fazendo com que sua reliability seja afetada. Se as falhas prejudica-rem, a ponto de os serviços de coleta de dados pararem de funcionar, a availability do sistema será afetada;
[RNF4] : O sistema deve garantir que o tempo de operações básicas de coleta
de dados, como armazenar e recuperar informações, seja menor que um segundo, pois, se isso não ocorrer, os usuários não conseguirão coletar dados de modo rápido o suficiente para que a coleta seja satisfatória e a performance do sistema será comprometida.
Os requisitos funcionais e não-funcionais descritos foram retirados do documento de requisitos para coleta de dados de campo que pode ser observado no Apêndice A. Diante destes requisitos, foram imaginados cenários de uso (CDU) considerados pertinentes para validar a solução exposta neste trabalho. Estes cenários são:
[CDU1] : Se o nível de bateria estiver baixo, as funções de armazenamento serão
bloqueadas para evitar perda de dados. Caso isso ocorra, uma exceção de bateria deve ser lançada (- ver seção 2.3.2);
[CDU2] : Se a coleta de dados estiver indisponível por acidentes devido a causas
ambientais ou por nível baixo de bateria, os dados coletados em campo devem ser transferidos para outro dispositivo móvel, usando um Chip ou Bluetooth, e importados na aplicação do outro dispositivo. Depois, deve-se continuar a coleta de dados normalmente;
[CDU3] : Se a aplicação passar por uma falha na coleta de dados e parar de
funci-onar, os dados coletados, que foram anteriormente armazenados em outro formato, devem ser exportados para um software de terceiros que possa continuar o auxílio à coleta de dados;
[CDU4] : Se a aplicação passar por uma falha no serviço de coleta de dados e seu
banco de dados original começar a prover dados errados, os dados armazenados em outro banco devem ser importados para que a aplicação consiga prover, outra vez, dados corretos para o usuário.
2.2.3
O Projeto e-phenology
O e-Phenology é um projeto multidisciplinar que combina pesquisas nos campos da Ciência da Computação e da Fenologia, que é o estudo dos eventos periódicos do ciclo de vida de plantas e animais influenciados pelas variações sazonais do clima. Sendo assim, o intuito do projeto é utilizar tecnologias para o estudo das mudanças nas condições do meio ambiente. O projeto propõe três objetivos: usar novas tecnologias para monitorar a fenologia; criar um protocolo para monitorar a fenologia no Brasil; e promover estudos sobre os dados fenológicos coletados [32].
Biólogos, ecólogos vão a campo e dispendem aproximadamente oito horas de seu tempo para coletar informações sobre as fases fenológicas de cada indivíduo (planta) previamente identificado. Os dados coletados têm observações referentes a propriedades fenológicas de mais de dois mil indivíduos observados mensalmente desde 1994. Esses dados são coletados em uma floresta de cerrado em Itirapina, no interior do estado de São Paulo, lugar onde a Internet é praticamente inacessível.
Uma imagem do local de coleta pode ser vista na Figura 2.1, retirada do trabalho de Alberton et al. [2]. As coletas são realizadas em quatro transectos diferentes, sendo que são divididas, como é possível visualizar na imagem, em quatro traçados distintos: Borda Leste, Interior Leste, Borda Sul e Interior Sul. Cada transecto é subdividido em parcelas, que são conjuntos, as quais contêm aproximadamente cem indivíduos, sendo que existem de 8 a 10 parcelas para cada transecto. As parcelas do transecto de borda, chamadas parcelas de borda, encontram-se entre o limite da mata e a estrada para chegar ao local. As parcelas dos transectos de interior, chamadas parcelas de interior, são formadas por trilhas dentro da mata fechada.
Figura 2.1: Transectos do Projeto e-phenology [2].
Cada indivíduo recebe uma placa de identificação referente ao número do indivíduo na parcela. Algumas vezes a placa do indivíduo cai ou perde-se e os pesquisadores mais experientes têm de encontrar e remarcar este indivíduo. Normalmente, a coleta de dados é feita por um pesquisador mais experiente que efetua sozinho a coleta, ou por dois pesquisadores menos experientes que percorrem as parcelas ao mesmo tempo. Quando a coleta é efetuada por dois pesquisadores, um vai atrás com a prancheta fazendo anotações e o outro vai na frente fazendo as observações fenológicas e falando-as em voz alta para que o pesquisador detrás anote os dados.
As informações fenológicas são essencialmente as fases:
1. Broto: se existem novas folhas nascendo nas plantas, por exemplo, a Figura 2.2;
2. Botão: se existe a fase anterior à flor presente nas plantas, por exemplo, a Figura 2.3;
4. Fruto Verde: se existem frutos recentemente nascidos, por exemplo, a Figura 2.5;
5. Fruto Maduro: se existem frutos já maduros, por exemplo, a Figura 2.5;
6. Queda Foliar: se existe queda foliar nas plantas, por exemplo, a Figura 2.6.
Figura 2.2: Brotamento [11] Figura 2.3: Botão [11]
Figura 2.4: Antese [11] Figura 2.5: Fruto Verde/Maduro [11]
Figura 2.6: Queda Foliar [11]
As fases fenológicas ou fenofases são dados quantitativos que recebem os valores de 0 a 2, sendo que: 0 representa a ausência da fase fenológica; 1, a presença da fenofase; e 2, a presença da fenofase na maior parte da planta. Também são adicionados, aos dados da coleta, informações textuais contendo observações sobre a localização dos indivíduos em relação a outros indivíduos e observações como “cem por cento de queda foliar”, “indivíduo perdido” ou “indivíduo morto”.
Com o uso de dispositivos móveis, outros dados de coleta e requisitos de tela foram extraídos com a ajuda do trabalho de Nicastro [33], como imagem atual do indivíduo, lo-calização do indivíduo via GPS e simplicidade da interface de software, foram adicionados como requisitos específicos do projeto e-phenology.
2.3
Dependability, Tolerância a Falhas e Modelo de
Falhas para Plataformas Móveis
Esta seção expõe, na subseção 2.3.1, os conceitos de dependability; na subseção 2.3.2, os conceitos de tolerância a falhas que são fortemente ligados com o conceito de dependability; e na subseção 2.3.3, o modelo de falhas para plataformas móveis, mostrando a ligação entre suas falhas e as propriedades de dependability.
2.3.1
Conceitos de Dependability
No trabalho de Laprie [28], dependability é um conjunto de propriedades que um sistema computacional tem para justificar a dependência colocada sobre seus serviços, ou melhor, um conjunto de propriedades que garante a possibilidade de depender destes serviços. A árvore de conceitos de dependability, retirada do trabalho de Pullum [42], pode ser visualizada na Figura 2.7.
Figura 2.7: Classificação do conceito de Dependability [42]
Os attributes (atributos) de dependability são complementares em um sistema, porém, dependendo do enfoque e da área de atuação de um software, um atributo torna-se mais ou menos importante.
Os atributos de dependability são descritos como:
1. Availability: propriedade relativa à prontidão para o uso, quando um sistema pode ser utilizado;
3. Safety: propriedade relativa a não existência de catástrofes operacionais;
4. Confidentiality: propriedade relativa a não divulgação de informações protegidas;
5. Data Integrity3: propriedade relativa a não ocorrência de alterações indevidas de informação;
6. Maintainability: propriedade relativa à capacidade de sofrer reparos e manutenção.
Os means (meios) para se melhorar a dependability de um sistema são divididos em dois grupos: construction (construção), que é um meio utilizado durante a fase de desenvol-vimento dos sistemas; e validation (validação), que é empregado após o desenvoldesenvol-vimento do software. Os meios para a fase de construção são:
1. Fault avoidance (prevenção de falhas): meio para evitar ou prevenir a introdução de falhas e ocorrências;
2. Fault tolerance (tolerância a falhas) : meio para prestar um serviço em conformidade com a especificação, apesar das falhas de programação e de hardware existentes (seção 2.3.2).
Para a fase de validação, os meios existentes, são:
1. Fault removal (remoção de falhas): meio para detectar a existência de falhas e eliminá-las;
2. Fault forecasting (previsão de falhas): meio para estimar a presença de falhas, suas ocorrências e suas consequências;
As impairments (deficiências) existentes na árvore de dependability são indesejadas, po-rém, sua exposição está diretamente relacionada com a falta de confiança de um sistema. Então, são também o centro das atenções quando se deseja construir sistemas tolerantes a falhas. O trabalho da Pullum [42] define as deficiências como:
1. Fault (falha) é o motivo de um erro. Pode ser vista como um bug ou consequência da insuficiência de um sistema externo ou de um programador;
2. Error (erro) é parte do estado de um sistema e pode propagar-se ou ficar latente por qualquer intervalo de tempo. Falhas sempre estão presentes quando erros são detectados;
3. Failure (defeito) ocorre quando um serviço ou processamento desvia-se do especifi-cado, produzindo um resultado incorreto ou diferente do desejado.
2.3.2
Tolerância a Falhas
A tolerância a falhas é um meio para se melhorar a dependability dos sistemas, como visto na seção 2.3.1 e, segundo o trabalho de Lee e Anderson [29], é definida como a habilidade de uma aplicação entregar o serviço desejado mesmo na presença de falhas. Então, para reduzir os riscos de defeitos provindos do desenvolvimento de software e hardware, são utilizadas técnicas de tolerância a falhas, ou seja, técnicas que permitem que um sistema continue operando mesmo após a ocorrência de um erro. Métodos de tolerância a falhas são estudados há muitos anos e, segundo o trabalho da Pullum [42], são bem conhecidos. Isso possibilitou a existência de diversas técnicas que implementam tolerância a falhas, as quais são baseadas, na maioria dos casos, em redundância.
Redundância é a utilização de recursos adicionais que não seriam necessários se técnicas de tolerância a falhas não fossem implementadas. A redundância pode existir em diversas formas, como redundância de hardware, de informações, de software e de tempo [42].
Hardware Redundancy (Redundância de Hardware - HR) é a inclusão de hardware
replicado ou suplementar no sistema. Um exemplo do uso de HR com dispositivos móveis, para coleta de dados de campo, acontece quando é necessário utilizar mais do que um dispositivo para que, quando um dispositivo atingir um nível crítico de bateria, os usuários possam transferir dados do dispositivo com baixo nível de bateria para o dispositivo reserva e continuar coletando dados. Data Redundancy (redundância de dados - DR) é o uso de duplicação dos dados em dois ou mais bancos de dados distintos e pode ser dividido em dois casos: Data Storage Redundancy (Redundância de Armazenamento de Dados -DSR) e Redundancy in Data Structure (Redundância na Estrutura de Armazenamento de Dados - RDS). DSR armazena a mesma informação em locais distintos e RDS usa diferentes formatos de dados para armazenar dados [42] como XML, CSV, JSON com o mesmo conteúdo.
Outra maneira de prover tolerância a falhas é com o uso de técnicas de tratamento de falhas ou de situações excepcionais chamado Exception Handling. Exception Handling é a habilidade de detectar erros e retornar ao comportamento normal da aplicação. Exemplos de exceções que requerem manuseamento correto no domínio de coleta de dados de campo são save data exception (acontece quando existe um erro enquanto os dados estão sendo salvos), battery exception (exceção lançada quando a aplicação não tem bateria suficiente para executar uma operação) e load data exception (ocorre quando os dados carregados do servidor não foram corretamente carregados).
2.3.3
Modelo de Falhas para Plataformas Móveis
Para que técnicas de tolerância a falhas sejam adequadamente aplicadas, é necessário mapear quais falhas têm maior impacto no domínio requerido e quais falhas interferem nas propriedades de dependability. Gärtner [16] descreve que falhas são descritas para avaliar o comportamento resultante do sistema e podem ser agrupadas em uma estrutura hierárquica de classe de falhas chamada modelo de falhas. Haves [21] descreve que falhas podem ser encontradas e mapeadas de duas formas diferentes: mudando os parâmetros de uma aplicação para encontrar os erros resultantes ou estendendo o sistema de falhas para lidar com falhas específicas.
No caso deste trabalho, os requisitos não-funcionais e as sucessivas visitas a campo mostraram as principais classes de falhas e as principais falhas, as quais foram agregadas ao modelo voltado a plataformas móveis:
1. Low Battery Level (Baixo Nível de Bateria) - Reduz a availability do sistema quando não provê os serviços desejados. No caso da coleta de dados de campo, o baixo nível de bateria é um problema quando não permite que o usuário utilize algumas funcionalidades do sistema, como salvar os dados. As falhas que participam dessa classe de falhas são as seguintes: os dados não podem ser coletados, e operações como sincronização dos dados, envio e recebimento de dados do servidor não podem ser realizadas.
2. Data Collection Service Failure (Falha nos Serviços de Coleta de Dados) - Operações podem conter erros que paralisam os sistemas, reduzindo a availability, ou erros que processem os dados incorretamente, reduzindo sua reliability. Isso atrapalha a coleta de dados e pode inutilizar o sistema. Neste caso, as falhas são parte do sistema e podem aparecer em algumas condições específicas. As falhas que participam dessa classe de falhas são: o sistema gera uma base de dados em um estado inválido por falha de software e o sistema não se comporta como o especificado gerando dados incorretos.
3. Data Loss (Perda de Dados) - A perda de dados pode ocorrer por um erro de software ou por acidentes no campo, prejudicando a data integrity. Dispositivos móveis, como tablets e telefones celulares, têm propensão a perder dados, pois são usados em ambientes hostis. As falhas que participam dessa classe de falhas são: a quebra do dispositivo móvel (o dispositivo móvel pode cair no chão e quebrar a tela) e a base de dados pode ser corrompida.
2.4
Arquitetura de Software e Padrões Arquiteturais
Segundo Perry e Wolf [36], existem várias visões de arquitetura de software para vários usos e usuários. Segundo eles, a arquitetura de software provê uma estrutura coesa e unificada para um modelo de software. Pressman [38] afirma que arquitetura de software é uma representação que permite ao engenheiro de software analisar a efetividade de um projeto em satisfazer seus requisitos, considerar alternativas arquiteturais em um estágio no qual modificações são relativamente fáceis e reduzir os riscos de desenvolvimento. Bass
et al. [4], define arquitetura de software como a estrutura ou as estruturas de sistemas que
abrangem componentes de software, as propriedades externamente visíveis e as relações entre elas.
Pressman [38] enuncia uma definição relativa ao papel da arquitetura de software em um projeto, enquanto que Bass et al. [4] prende-se a uma definição voltada à contribuição da arquitetura de software relativa à estrutura organizacional do software. A definição de Pressman [38] e de Bass et al. [4] têm enfoques diferentes, como Perry e Wolf [36] enunciam em sua definição baseada nos interesses da arquitetura. Assim, ao juntar-se as definições de Pressman e de Bass et al., tem-se uma definição que evidencia a importância da
arquitetura, tanto por parte do desenvolvedor do software quanto por parte da estrutura e das várias visões arquiteturais.
Cada arquitetura de software pode ser criada com base em estilos arquiteturais especí-ficos ou uma junção deles. Estilo arquitetural, segundo Garlan e Shaw [15], é um padrão de organização de um sistema, como uma arquitetura cliente-servidor ou arquitetura em camadas. Existem diversos estilos arquiteturais que podem ser usados em conjunto para atender às necessidades de um domínio específico de um dado problema.
O uso desses estilos, segundo o trabalho de Pressman [38], pode ser complementado por padrões arquiteturais para estabelecer a estrutura global de um sistema. Tais padrões são mais específicos e têm enfoque em um aspecto pontual da arquitetura. Um padrão é uma imposição de uma regra na arquitetura e tende a atender tópicos comportamentais pontuais no contexto da arquitetura.
2.5
Component-Based Development - CBD
Esta seção descreve o desenvolvimento baseado em componentes mostrando, na subseção 2.5.1, o conceito de Component-Based Development (CBD); na subseção 2.5.2, como de-senvolver uma arquitetura baseada em componentes; e na subseção 2.5.3, como utilizar aspectos em uma arquitetura baseada em componentes.
2.5.1
Conceito de CBD
Segundo Szyperski et al., [46] Component-Based Development (CBD) é uma técnica de desenvolvimento de sistemas baseada na construção rápida de componentes anteriormente especificados. Um componente de software, Figura 2.8, tem três características bem definidas: é uma unidade de desenvolvimento independente; é uma unidade de composição que terceiriza serviços; e é uma unidade que não tem estado externo observável. Isso quer dizer que um componente tem baixo acoplamento, seus serviços são bem separados dos serviços de outros componentes e é uma caixa preta para os componentes que o utilizam.
Figura 2.8: Exemplo de Componente [50]
Para comunicação externa de um componente, são previstos o uso de interfaces. As interfaces providas oferecem os serviços internos de um componente; as interfaces reque-ridas permitem o uso de serviços externos, ou seja, permite que utilize serviços de outros componentes.
O reúso de componentes, em um processo de desenvolvimento, diminui os gastos e ajuda a melhorar a qualidade dos sistemas, pois a reutilização dos componentes, previa-mente verificados e validados, diminui o tempo de desenvolvimento e leva uma quantidade menor de falhas para o novo sistema em que será utilizado.
2.5.2
Arquitetura Baseada em Componentes
Figura 2.9: Exemplo de Arquitetura Utilizando Componentes.
A arquitetura de software, segundo a definição de Bass et al., da seção 2.4, leva em consideração as estruturas de alto nível do sistema em termos de elementos arquiteturais, abstraindo detalhes de sua implementação. Ela é um modelo para representar interações entre componentes e utiliza-se de conectores para sua comunicação [14]. A saber, conec-tores são a ligação entre dois ou mais componentes, e uma organização de componentes e conectores específica é chamada de configuração arquitetural [47].
A Figura 2.9 mostra um exemplo simples de uma arquitetura baseada em componen-tes. Essa arquitetura mostra um componente chamado Componente1Mgr, que contém uma interface requerida chamada IConector, utilizando um conector ConectorMgr para acessar funcionalidades providas por dois outros componentes Componente2Mgr e
Com-ponente3Mgr, via suas interfaces providas IComponente1 e IComponente2. Nota-se que
os conectores também são componentes e, muitas vezes, para oferecer a funcionalidade requerida, consomem serviços de vários outros componentes.
2.5.3
Aspect-Oriented Software Development -AOSD
O trabalho de Filman et al. [13] descreve que a AOSD oferece métodos, técnicas, notações e extensões de linguagem para permitir a separação de interesses em módulos tipicamente chamados de aspectos. A AOSD trabalha com crosscutting concerns (interesses trans-versais), que são propriedades com escopo abrangente e que estão presentes em diversos
módulos do sistema, o que os tornam ótimos candidatos para separação em módulos de aspectos. Os aspectos têm três mecanismos principais que os determinam:
1. Joinpoints (pontos de junção): pontos onde a execução é identificável;
2. Pointcuts (pontos de corte): seleciona os join points e coleta o contexto neste ponto;
3. Advice (adendo): código a ser executado em um pointcut;
Para o desenvolvimento deste projeto, foram utilizadas as análises de casos de uso transversais e casos de uso base propostos por Jacobson e Ng [23]. Os casos de uso, chamados de transversais, são os casos de uso que representam crosscutting concerns, e os casos de uso base são os casos de uso comuns. O critério utilizado para decidir se um caso de uso é transversal, é o número de relações com outros casos de uso. Por exemplo, se um caso de uso é estendido por vários outros casos de uso, ele pode, mais tardiamente, na fase de implementação de projeto, ser gerado como um aspecto.
2.6
Software Product Line Development
Esta seção explica os métodos e passos lógicos utilizados para criação da infraestrutura proposta por este trabalho. A subseção 2.6.1 apresenta o conceito de Software Product
Line (SPL). A subseção 2.6.2 explica o que é a análise de domínio e como a análise
de domínio ajuda a desenvolver um feature model. A subseção 2.6.3 é responsável por completar a subseção 2.6.2 descrevendo como criar uma aspect-feature view responsável por complementar o feature models. A subseção 2.6.4 apresenta o método AO-FArM, o qual é responsável por transformar o feature models em uma arquitetura baseada em componentes para SPL. A subseção 2.6.5 descreve o COSMOS*-VP, que é um modelo de componentes responsável pela tradução do modelo de arquitetura em código.
2.6.1
Terminologia
Uma Software Product Line (Linha de Produto de Software - SPL) é um conjunto de sistemas que compartilham características em comum, satisfazendo as necessidades espe-cíficas de um segmento de mercado ou domínio. A SPL é desenvolvida utilizando um conjunto de core assets (bens essenciais) que preenchem requisitos específicos de domínio [6], e seu reúso, em larga escala, é alcançado através de uma Product Line Architecture (Arquitetura de Linha de Produtos - PLA), a qual é comum para uma variante de pro-dutos similares em termos de elementos arquiteturais [6]. O ciclo de vida de uma SPL é dividido de acordo com as suas maiores atividades que são: engenharia de domínio e engenharia de aplicação.
A engenharia de domínio foca na criação de um conjunto de core assets, que serão reutilizados em todos os produtos da linha. A engenharia de aplicação é responsável por adaptar o conjunto de core assets criado na engenharia de domínio, e por derivar aplicações para este domínio.
2.6.2
Análise de Domínio
Na engenharia de domínio, a tarefa mais crítica é a identificação dos core assets e, para obtê-los, Kang et al. [24] propuseram o uso de feature model (modelo de características) para identificar semelhanças e variabilidades em família de sistemas feitos a partir de domínios específicos. O feature model é um modelo com estruturas hierárquicas que apresenta features (características) de um domínio, sendo que estas são reconhecidas por representarem entes do domínio (como funcionalidades), ou seja, aquilo que é relevante para os interessados no sistema.
Figura 2.10: Exemplo de um feature model.
Um feature model, como pode ser visto na Figura 2.10, traz as características descritas como retângulos e quatro relações distintas: mandatory (obrigatória), optional (opcional),
aternative (alternativa), or (ou). A relação mandatory, representada por um segmento
de reta, tem o significado de obrigatoriedade relacionado a uma sub-feature. A relação
optional, representada por um segmento de reta com uma circunferência do lado da sub-feature, significa que uma sub-feature não precisa ser implementanda no desenvolvimento
do sistema, isso representa um ponto de variability. A relação alternative, representada por um ângulo sem preenchimento, significa que duas ou mais sub-features não devem ser utilizadas ao mesmo tempo no sistema, ou seja, representa o conceito de ou exclusivo. A relação or, representada por um ângulo preenchido, significa que uma ou mais das
sub-features podem ser implementadas ao mesmo tempo, ou seja, representam o conceito de
“um ou mais”.
Para gerar um feature model, Kang et al. [24] propuseram um processo usando os seguintes passos:
1. Coletar documentação e requisitos;
2. Identificar as features;
3. Agrupar as features e construir o modelo;
5. Validar o modelo.
Em 1, todos as fontes de documentos do projeto e projetos análogos, incluindo páginas da Internet, modelos, documentação e manuais, são consultados. No passo 2, todas as características do sistema são identificadas a partir dos documentos levantados. Em 3, conflitos de nome são resolvidos, e features são agrupadas hierarquicamente e, de acordo com suas relações, o feature model é construído para o domínio requerido. Em 4, as
features são classificadas de acordo com o tempo de sistema que é utilizado: em tempo
de compilação, em tempo de uso ou em tempo de carregamento da aplicação. No passo 5, usuários e especialistas são consultados para validar o modelo.
2.6.3
Aspect-Oriented Analysis
AO-Analysis [49] é o método que objetiva identificar crosscutting concerns através de
casos de uso base e casos de uso transversais. A saída deste método é uma visão com-plementar do feature model, chamada aspect-feature view (visão das características de aspectos). Casos de uso “estendidos” ou “incluídos”, com frequência, por outros casos de uso são candidatos a serem crosscutting concerns. Baseando-se nesses casos de uso, uma
aspect-feature view é criada, sendo que cada característica do software é mapeada como
um retângulo e cada crosscutting concern é mapeado como um losango, e as relações
mandatory, optional, alternative e or são geradas, como pode ser visto no exemplo da
(Figura 2.11), modificada a partir do trabalho de Tizzei [47].
Figura 2.11: Exemplo de uma aspect-feature view.
2.6.4
Projeto Arquitetural
Aspect-Oriented Feature Architecture Mapping (Mapeamento da Arquitetura de
Caracte-rísticas Orientada à Aspectos - AO-FArM) [49] é um método para obter a arquitetura baseando-se no feature model e na aspect-feature view. O método descreve quatro trans-formações específicas:
1. Remoção das features que não estão ligadas à arquitetura e que não estão ligadas à qualidade;
2. Transformação das features em requisitos arquiteturais;
3. Transformação baseada nas relações de interação das features;
4. Transformação baseadas em relações hierárquicas.
Na transformação 1, todas as features que não estão ligadas a arquitetura são remo-vidas. Em 2, os requisitos arquiteturais, como segurança e qualidade, são aderidos às
features. Em 3, o feature model é analisado considerando as dependências entre features,
isto é, as relações de interação entre as features. Uma relação de interação pode expressar como uma certa feature A usa, modifica, contradiz, entrecorta ou precede outra feature B. Se A contradiz B, elas precisam ser implementadas juntas. Se C usa outra feature D, então, isso será refletido na arquitetura com o componente C necessitando uma interface com o componente D. Se uma feature C entrecorta uma feature D, na arquitetura, o com-ponente C proverá uma interface orientada a aspectos, e o comcom-ponente D proverá uma interface especificando quais métodos serão entrecortados. Em 4, todas as relações hierár-quicas são analisadas e verificadas. Para preservar o mapeamento de granularidade fina, o número de features implementadas em um componente deve ser baixo. Neste ponto, todos os maiores componentes e aspectos são identificados e as feature relativas a eles são denominadas de feature de base; então, todas as interfaces de cada componente são especificadas.
2.6.5
Implementação da Arquitetura
Figura 2.12: Diagrama de Classes COSMOS*-VP.
COSMOS*-VP [48] [9] é um modelo de componentes para geração do design arqui-tetural que combina AOSD e CBD, deixando as informações protegidas, isto é, cada
componente é utilizado como uma caixa preta, definindo apenas alguns tipos de interfa-ces para interação: interfainterfa-ces providas, interfainterfa-ces requeridas, abstract aspects (aspectos abstratos - AbstractAspects) e Crosscutting Program Interfaces (interfaces transversais de programas - XPIs).
Figura 2.13: Diagrama de Classes do Conector do COSMOS*.
As interfaces providas são utilizadas por componentes sem aspectos para disponibi-lizar as funcionalidades internas do componente e as interfaces requeridas são utilizadas para o componente acessar funcionalidades externas. Como pode-se ver na Figura 2.12, que mostra o projeto detalhado dos componentes, tem-se, para interação normal entre os componentes, uma estrutura dividida em duas partes: a especificação e a implementação (ComponenteMgr.spec e ComponenteMgr.impl). A especificação também é dividida em duas partes que apresentam um pacote de interfaces providas (ComponenteMgr.spec.prov), o qual contém as interfaces IComponenteMgr e IManager, e um pacote de interfaces re-querida (ComponentMgr.spec.req), que contém as interfaces dos componentes externos, os quais serão utilizados pelo ComponenteMgr. A implementação possui uma estrutura para prover, instanciar e acessar os serviços, sendo que a classe ComponentFactory é res-ponsável por instanciar os componentes, a classe Manager oferece operações para listar e oferecer as interfaces do componente, a classe Facade ajuda a implementar outras interfa-ces, com exceção de IManager, e ObjectFactory é responsável por criar os objetos internos do componente, minimizando o acoplamento entre estes objetos.
Para a conexão entre componentes, que não são aspectos, foi utilizado o conector do modelo de componentes do COSMOS*, descrito no relatório técnico do Instituto de Computação, desenvolvido por Gayard et al. [17], como pode-se ver na Figura 2.13. O conector ABConector é responsável por armazenar os nomes e as classes das interfaces providas e requeridas do conector, que instancia a classe Adapter, a qual serve como uma ligação entre as interfaces RequeridaB e ProvidaB dos componentes CompAMgr e
Figura 2.14: Diagrama de Classes do Conector do COSMOS*-VP.
mesmas funcionalidades das classes com este mesmo nome do componente representado na Figura 2.12.
AbstractAspects (advices) são aspectos que têm implementação, isto é, o
comporta-mento deles pode ser ativado, enquanto que XPIs marcam pontos de interação dentro dos componentes (mistura entre pointcuts e joinpoints), em que será inserido o código quando
AbstractAspects for ativado. Em outras palavras, as XPIs agem como uma interface,
per-mitindo a execução de AbstractAspects em pontos específicos do código e ambas podem aparecem como interfaces no módulo interno Componente.aspects na arquitetura da Fi-gura 2.12. Para amarrar as especificações de AbstractAspect (comportamento) com as
XPIs (pointcuts), o modelo usa Connector-VPs, que são conectores arquiteturais
utiliza-dos para especificar quais comportamentos (AbstractAspect) serão ligautiliza-dos a quais pointcuts (XPIs), como pode-se ver na Figura 2.14, modificada do trabalho de Tizzei [47]. A XPI-Comp1 é a XPI de XPI-Comp1Mgr, as interfaces DIComp2 e DIComp3 são as interfaces do conector que delegam o trabalho à classe de AbstractAspect criada a partir da interface AAComp1Mgr e, quando os componentes a serem utilizados não são aspectos, delegam para a interface provida dos componentes representados pelo componente IComp3Mgt.
Conectores arquiteturais servem para amarrar as interfaces entre dois componentes, trabalhando como um padrão Adapter. É importante notar que AbstractAspects e XPIs são padrões para estruturar o código para uma linguagem orientada a aspectos quaisquer.
e-Phenology Collector
O desenvolvimento da solução proposta seguiu uma metodologia de pesquisa utilizada para gerar uma infraestrutura genérica para o domínio de coleta de dados de campo chamada Robust Software Product Line Architecture for Data Collection (R-SPL-DC), que foi aplicada no desenvolvimento de um sistema de software chamado e-Phenology
Collector para a coleta de dados no domínio da fenologia. Essa metodologia de pesquisa é
apresentada na seção 3.1 e, subsequentemente, seus passos lógicos são descritos nas seções subsequentes.
3.1
Metodologia de Pesquisa
A metodologia de pesquisa seguiu a seguinte sequência de passos lógicos: o primeiro passo foi a extração de requisitos funcionais e não-funcionais através da utilização da engenharia reversa e testes em protótipos; o segundo passo foi a criação de um modelo de falhas utilizando os requisitos não-funcionais; no terceiro passo foram criados o feature model e a aspect-feature view com ajuda do trabalho de Waku [51], que aplicou para dispositivos e plataformas móveis o trabalho de Tizzei [47] sobre uso e evolução de SPL utilizando CBD e AOSD; no quarto passo, o feature model e a aspect-feature view foram utilizados para gerar um mapeamento dos requisitos não-funcionais para estabelecer quais features e
crosscutting-concerns alocariam as exception handlers e técnicas de tolerância a falhas; no
quinto passo, Waku [51] ajudou a aplicar a Aspect-Oriented Feature Architecture Mapping (AO-FArM), gerando a arquitetura; no passo final, o COSMOS*-VP foi utilizado para implementar a arquitetura em um protótipo final para Android, que foi levado a campo e validado a partir dos cenários de uso definidos para o projeto.
3.2
Elicitação de Requisitos
A engenharia reversa, extração de requisitos e a prototipagem foram utilizadas para ana-lisar, capturar o conhecimento do domínio e identificar os conceitos de aplicações de pesquisa como o projeto maritaca [10], o projeto Open Data Kit [20] e outros projetos de mercado existentes.
Os requisitos, a priori, foram levantados por alunos da disciplina de Engenharia de
