Universidade Federal de Pernambuco - CIn UFPEtg/2019-1/TG_CC/tg_ehammo.pdf · 2019. 7. 14. ·...

Universidade Federal de Pernambuco

Curso de Ciência da Computação

ANÁLISE DE ALGORITMOS DE APRENDIZAGEM DE

MÁQUINA EM UM AMBIENTE DINÂMICO DE MOBILE

CLOUD COMPUTING

Trabalho de Conclusão de Curso de Graduação

por

Eduardo Henrique Alves Maia Mattos Oliveira

Orientador: Prof. Kelvin Dias

Recife, Julho/ 2019

Eduardo Henrique Alves Maia Mattos Oliveira

ANÁLISE DE ALGORITMOS DE APRENDIZAGEM DE MÁQUINA EM

UM AMBIENTE DINÂMICO DE MOBILE CLOUD COMPUTING

Trabalho apresentado ao Programa deGraduação em Ciência da Computaçãodo Departamento de Informática daUniversidade Federal de Pernambuco comorequisito parcial para a obtenção do grau deBacharel em Ciência da Computação.

Orientador: Prof. Kelvin Dias

Recife

2019

Agradecimentos

Esta fase da minha vida é muito especial e não posso deixar de agradecer a Deus por

toda bênção, força e coragem que me ofereceu para ter alcançado minha meta.

Quero agradecer à minha famı́lia, especialmente aos meus pais Eduardo e Uiára por

serem essenciais na minha vida e pelo amor, incentivo e apoio incondicional.

Aos meus amigos deixo aqui minha gratidão por torcerem e vibrarem com a minha

conquista. Foram eles que me ajudaram a seguir sempre de cabeça erguida.

Meu muito obrigado à instituição UFPE, que me proporcionou a chance de expandir os

meus horizontes. Obrigado pelo ambiente criativo e amigável nesses anos de formação.

Agradeço à professora Renata Maria Rodrigues por todos os conselhos e por sempre

estar disposta a me ajudar. Ao meu orientador professor Kelvin Dias que me orientou

no decorrer desse semestre e por todo apoio à elaboração do meu projeto final.

Gostaria de agradecer também aos meus amigos do Centro de Informática e ao CESAR,

que me acolheu e tem me proporcionado experiências construtivas para minha carreira

profissional, especialmente a todos da equipe Motorola CBS.

Agradeço a todos que fizeram parte desta caminhada ao meu lado.

Que venha o futuro!

A satisfação está no esforço

e não apenas na realização final.

Mahatma Gandhi

RESUMO

Offloading computacional em computação em nuvem móvel, ou Mobile Cloud Compu-

ting (MCC), tem atráıdo muita atenção pelos seus benef́ıcios em economia de energia

e melhorias de desempenho. No entanto, esta técnica apresenta um baixo desempenho

quando é executada ignorando informações contextuais. Estudos recentes destacam o

uso de informações contextuais para o melhoramento da decisão de offloading, porém

ainda há desafios sobre o ambiente dinâmico de MCC. Então, esse trabalho oferece uma

análise entre vários algoritmos de classificação binária (J48, JRIP, NAIVE BAYES, IBk,

RandomForest, SMO, MLP) para tomar decisões sobre a realização do offloading com-

putacional, utilizando o banco de dados contextual adquirido em um trabalho anterior.

Além disso, este documento também apresenta um programa que automatiza o ajuste,

treinamento, teste e comparação dos algoritmos. Também foi modificado o BenchFace

(aplicativo benchmarking de reconhecimento facial) capacitando-o para um posśıvel re-

treinamento automático.

Palavras-chave: Mobile cloud computing, senśıvel ao contexto, sistema de offloading, of-

floading computacional, aprendizagem de máquina, algoritmos de classificação

ABSTRACT

Computational offloading in Mobile Cloud Computing (MCC) has attracted attention due

its benefits in energy saving and improved mobile application performance. Nevertheless,

this technique underperforms if the offloading decision ignores contextual informations.

While recent studies have highlighted the use of contextual information to improve the

computational offloading decision, challenges still remain regarding the dynamic nature

of MCC environment. Thus, this work offers an analysis between several binary classifica-

tion algorithms (J48, JRIP, NAIVE BAYES, IBk, RandomForest, SMO, MLP), to make

the decision if a device should do the computational offloading, utilizing the contextual

database acquired in a previous work. Furthermore, a program to automate the tuning,

training, testing and comparing of the algorithms was made. Besides that, the BenchFace

application (Facial recognition app for benchmarking) was also modified to be ready for

a possible automatic retraining.

Keywords: Mobile cloud computing, offloading system, context-sensitive, machine-learning,

classification algorithms.

LISTA DE FIGURAS

Figura 1 Arquitetura de offloading computacional adaptada de [1] . . . . . . . . . . . . . . . . . . 13

Figura 2 BenchFace.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

LISTA DE TABELAS

Tabela 1 Comparação qualitativa de soluções senśıveis ao contexto . . . . . . . . . . . . . . . . . . 20

Tabela 2 Atributos e valores contextuais. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Tabela 3 Resultados Friedman. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Tabela 4 Resultados Nemenyi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

LISTA DE SIGLAS

ARC AnyRun Computing

D2D Device to Device

FN False Negative

FNR False Negative Rate

FP False Positive

FPR False Positive Rate

IBk Instance-based K-nearest neighbours

javaNPST Non Parametric Statistical Tests in java

KNN K — Nearest Neighbors

MCC Mobile Cloud Computing

MLP Multi-Layered Perceptron

ML Machine Learning

MSN Mobile Social Network

OC Offloading Candidate

RF Random Forest

RSU Roadside Unit

SVM Support Vector Machine

SMO Sequential minimal optimization

TOPSIS Technique for Order of Preference by Similarity to ideal Solution

TN True Negative

TNR True Negative Rate

TP True Positive

TPR True Positive Rate

UFPE Universidade Federal de Pernambuco

V2I Vehicle to Infrastructure

V2V Vehicle to Vehicule

VANETS Vehicular Ad-hoc Network

SUMÁRIO

1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2 FUNDAMENTOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.1 Sistema de offloading senśıvel ao contexto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.2 Algoritmos de classificação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3 TRABALHOS RELACIONADOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4 SOLUÇÃO PROPOSTA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.1 BenchFace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.2 AlgorithmCompare. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.2.1 Tuning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

5 EXPERIMENTOS E ANÁLISE DE RESULTADOS . . . . . . . . . . . . . . . . . 29

5.1 Base de dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

5.2 Treinamento e teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

5.3 Comparação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

6 CONCLUSÃO E TRABALHOS FUTUROS . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

10

1 INTRODUÇÃO

Computação em nuvem móvel, ou Mobile cloud computing (MCC), oferece serviços

de nuvem no ecossistema móvel [2]. Esse paradigma surge da cooperação entre a com-

putação móvel e a computação em nuvem, permitindo a migração do armazenamento e

da computação de dispositivos móveis, que têm recursos limitados, para servidores na nu-

vem, diminuindo a carga computacional e o consumo de bateria desses dispositivos. Essa

migração deve ser feita de forma a considerar recursos como disponibilidade, velocidade e

confiabilidade sem reduzir o desempenho da aplicação [3]. Isso pode ser alcançado através

de operações de offloading, i.e., a transferência de informações e códigos de dispositivos

móveis para uma nuvem local (cloudlet) ou pública (Amazon EC2). [4]

De acordo com Huber Flores em [5], offloading computacional é o processo em que

um dispositivo com poucos recursos delega uma tarefa para outro com mais recursos, e

em seu outro trabalho [1], ele afirma que o offloading computacional só é produtivo se

economiza energia sem degradar o desempenho da aplicação. Para que essa migração

ocorra como o esperado é importante que tomemos notas de algumas caracteŕısticas do

contexto envolvido, tais como: largura de banda, a força do sinal, o tamanho dos dados,

as capacidades dos dispositivo. Já que esses parâmetros podem mudar com frequência, os

momentos oportuńısticos para fazer a migração para um servidor remoto de nuvem são

esporádicos. Por este motivo, a efetividade de uma operação de offloading é determinada

pela sua habilidade de inferir onde a execução daquele código terá um menor esforço

computacional, localmente ou na nuvem [1].

O offloading poderá ser feito para três tipos de nuvem: nuvem pública, um servidor

cloudlet, ou uma cloudlet ad-hoc. Uma nuvem pública é criada por recursos computaci-

onais localizados em data centers e mantidos por provedores de serviços de nuvem. Um

servidor cloudlet é um conjunto de baixo custo de computadores multicore, localizado

na mesma rede Wireless Local Area Network (WLAN) que os dispositivos móveis. Ele

pode prover serviços de nuvem numa escala pequena e é comumente encontrado em am-

bientes domésticos, corporativos e públicos. Por fim, uma cloudlet ad-hoc é formada por

um grupo de dispositivos móveis com alto poder de processamento que compartilha seus

recursos com seus vizinhos locais com menos recursos [2].

Este problema introduz a necessidade da adaptabilidade ao contexto. Os sistemas

11

capazes de offloading computacional precisam se adaptar baseados na informação sobre

os recursos que estão sendo oferecidos, inferindo informações de contexto dos dispositivos,

para decidir onde e quando se deve fazer o offloading. Em outras palavras, um sistema

senśıvel ao ambiente em que está inserido, capaz de monitorar, coletar, selecionar, pro-

cessar e compartilhar essa informação contextual [3] envolvida na tomada de decisão e na

execução da migração da tarefa computacional. Informação contextual é qualquer tipo

de informação que caracterize uma entidade de um domı́nio espećıfico; Alguns exemplos

de posśıveis entidades são; uma pessoa, um celular, uma aplicação, um servidor (nuvem),

um elemento de rede [6] [7].

Tradicionalmente, os sistemas de offloading dinâmico já existentes propõem no-

vos frameworks [8], middlewares que usem algoritmos de aprendizagem de máquina ou

modelos de classificação utilizando informações contextuais para a tomada de decisão.

Máquinas de vetores de suporte [9], Naive Bayes [10], Árvores de decisão [11] constituem

alguns dos algoritmos de aprendizagem de máquina que operam construindo um modelo

a partir de de uma amostra de dados, objetivando realizar previsões ou decisões. Porém,

caso a amostra seja pequena ou não cubra alguns casos importantes, esses algoritmos

podem tomar decisões erradas quando colocados no mundo real. Em [3] foi feita uma

comparação com alguns algoritmos, para determinar quais deles seriam mais adequados

para o contexto de MCC. Os algoritmos foram escolhidos com o objetivo de minimizar

o custo computacional, isto é, escolher aqueles que demoram menos para treinar e tes-

tar. Porém, muitos algoritmos importantes foram deixados de fora, inclusive alguns cujo

alto custo computacional se encontrava no treinamento (que poderia ser feito na nuvem)

e não na inferência (que seria feito no cliente). Portanto, nesse trabalho fazemos uma

análise, usando a mesma base de dados de [3], incluindo diversos importantes algoritmos

de classificação binária não mencionados por [3], buscando esclarecer diferenças entre os

algoritmos e porque eles se encaixam ou não no contexto desses experimentos.

O resto deste documento é organizado da seguinte forma: Seção 2 descreve a

informação de background. Seção 3 discute os trabalhos relacionados. Seção 4 apresenta

os passos feitos para a análise e a comparação dos algoritmos, e os testes feitos para

avaliá-los. Por fim a Seção 6 conclui o documento e apresenta os trabalhos futuros.

12

2 FUNDAMENTOS

Nessa Seção, descrevemos a arquitetura de um sistema de offloading senśıvel ao

contexto e alguns exemplos de aplicações no mundo real (seção 2.1). Em seguida descreve-

mos os algoritmos de classificação de aprendizagem de máquina utilizados nesse trabalho

(seção 2.2).

2.1 Sistema de offloading senśıvel ao contexto

A arquitetura de offloading computacional adaptada de [1] é mostrada na Figura

1. A arquitetura consiste em duas partes: um conjunto de clientes e outro de servidores.

Nessa abordagem, qualquer entidade móvel, seja ela um carro conectado, um smartphone,

um drone, ou um dispositivo IoT qualquer, pode delegar uma tarefa computacional para

qualquer modelo de nuvem, seja ela uma cloudlet, uma nuvem remota ou até uma cloudlet

ad-hoc, também chamada de dispositivo a dispositivo, Device-to-Device (D2D), em outros

estudos. Candidatos para migração (Offloading Candidates - OCs), podem ser porções de

código (C) como métodos, threads, ou classes inteiras, e esses candidatos são identificados

pelo programador do software. [3]

A sensibilidade ao contexto refere-se a capacidade do sistema de se adaptar às

mudanças do ambiente em que ele está inserido [6]. Em MCC, um sistema de offloading

senśıvel ao contexto é capaz de monitorar, coletar, selecionar, processar e compartilhar

a informação contextual de uma entidade. É altamente utilizado em ambientes onde a

fonte energética ou o poder computacional é escasso. O objetivo deste tipo de sistema é

ser ciente de toda informação contextual para migrar apenas quando processar na nuvem

for melhor que processar localmente [7].

O processo de offloading pode ser melhorado usando informação contextual para

dinamicamente tomar decisões, e apenas começar o processo de migração quando o con-

texto for vantajoso [3], já que o offloading estático não traz benef́ıcios em todos os contex-

tos [12]. Em MCC, um contexto vantajoso é aquele cujas informações fazem o processo

de offloading ter um custo computacional menor do que a execução local da tarefa [1].

13

C

OC

C

public class image {

void method1(){

//...

}

void method2(){

// Offloading Candidate

}

void method3(){

//...

}

main(){

method1();

method2();

method3();

}

}

Synchronizaon

point

Synchronizaon

point

Local

processing

Transfer

rao

Invocaon

Execuon

flow

Cloudlet

D2D

Remote cloud

Transfer

rao

Remote

processing

External processingLocal processing

Vanets

Healthcare

Augmented

reality

OC

Figura 1 Arquitetura de offloading computacional adaptada de [1]

Um exemplo no ambiente de Saúde é a tecnologia de smart-band [13], que tem

vários sensores cuja função é monitorar batimentos card́ıacos, ńıvel de insulina no san-

gue, temperatura corporal, além de outras métricas. Essas smart-bands não têm bateria

suficiente ou poder computacional para lidar com todas essa tarefas, considerando que

existem tarefas que necessitam de um alto poder computacional. Muitos dos sistemas

que usam smart-bands fazem um offloading estático para um aparelho celular via blue-

tooth. Nos casos onde o dispositivo e o paciente estão muito distantes, outros meios de

transmissão devem ser considerados para economizar energia. Após a transferência de

dados brutos dos sensores para o celular, o sistema então migra a tarefa de processá-los

para a nuvem estaticamente [13]. Porém, em algumas situações é mais vantajoso que essa

execução não seja migrada para um nuvem pública e seja executada localmente no celu-

lar do paciente, inclusive em [13] algumas funcionalidades foram escolhidas para serem

executadas localmente e outras para serem migradas para a nuvem. Essas decisões de

14

quais métodos devem sempre executar locais e quais devem sempre executar na nuvem

são pasśıveis de erro à medida que o contexto muda. Em um dia que não há internet na

casa do paciente é melhor que as execuções de algumas features sejam feitas localmente

ao invés de funcionarem apenas com o sistema online. Então, um sistema de offloading

ciente de contexto conhece o número de sensores, o tamanho da informação a ser trans-

ferida, o quão rápida está a latência da rede, como está a capacidade da nuvem, qual é

a capacidade de processamento local e usa todas essas informações para decidir onde os

dados coletados nos sensores podem ser melhor processados. Portanto, essa smart-band

só vai processar na nuvem quando o contexto for vantajoso para isso.

Este tipo de sistema também pode ser usado em redes veiculares Ad-Hoc (VA-

NETs), que tem como objetivo prover assistência de viagem, informação dos véıculos e

entretenimento no geral, trazendo facilidade, conforto e uma viagem prazerosa como um

todo [14] [15]. Carros e Roadside Units (RSUs) podem compartilhar o recurso do poder de

processamento, seja de véıculo para véıculo (V2V) ou de véıculo para infraestrutura (V2I),

processando vários tipos de informações diferentes. Isso significa que todo conteúdo, seja

ele áudio, imagens ou v́ıdeos requisitados por passageiros, ou dados coletados por senso-

res, têm que ser processados localmente ou em VANETs de acordo com o tamanho dos

dados, a largura da banda, a distância entre os carros, a velocidade dos carros, etc. Essa

mudança frequente de contexto torna um sistema senśıvel ao contexto necessário para

decidir qual o melhor lugar para processar a informação.

Outro exemplo é a Rede social móvel ou MSN, do inglês Mobile Social Networ-

king. MSN envolve a interação entre usuários que têm os mesmos interesses e/ou obje-

tivos através dos seus dispositivos dentro de redes sociais virtuais [16]. Os dispositivos

desses usuários podem compartilhar os seus recursos para processar dados juntos. Seja

um processamento de imagem ou tradução de texto, toda tarefa poderia ser dividida e

compartilhada entre dispositivos. Porém, dependendo do tamanho dos arquivos a serem

transmitidos, não vale a pena compartilhar a tarefa.

2.2 Algoritmos de classificação

Para melhorar a decisão sobre o melhor lugar para processar as tarefas (No disposi-

tivo ou na nuvem), algoritmos de classificação de aprendizagem de máquina são necessários

em sistemas de offload senśıveis ao contexto. Aprendizagem de Máquina, ou ML, do inglês,

15

Machine learning é definida por [17] [18] como um sistema ou algoritmo capaz de apren-

der baseado em experiências passadas, gerando regras a partir de instâncias (exemplos em

um conjunto de treinamento) [19], sem nenhuma assistência de um ser humano [20]. Um

subdomı́nio do campo de ML é o aprendizado supervisionado. Nele, o treinamento é feito

com dados categorizados com as entradas e as sáıdas desejadas [17] [21]. A função desses

algoritmos é classificar uma instância baseada em seu conjunto de treinamento, decidindo

assim qual a classe mais adequada.

Os algoritmos de classificação usados nesse documento foram: Árvore de decisão,

RandomForest, Aprendizagem baseada em regras, Máquina de vetores de suporte (SVM

do inglês, Support Vector Machine), Perceptron de Multi Camadas (MLP do inglês Multi

Layer Perceptron), O vizinho K mais próximo (KNN, do inglês k-Nearest Neighbor) e

Naive-Bayes. A árvore de decisão, o KNN, o aprendizado baseado em regras, e o Naive-

Bayes são algoritmos bastante usados em computação ub́ıqua pela sua alta acurácia e

baixo custo computacional. Já que em [3] o J48 apresentou um dos melhores desempe-

nhos dentre os algoritmos comparados, decidiu-se incluir o RandomForest, que também é

baseado em Árvore de decisão, na análise estat́ıstica comparativa deste trabalho. A SVM

foi introduzida pela sua robustez e flexibilidade. Acredita-se que ela pode ser uma boa

opção para este problema e o MLP também foi considerado devido ao seu relacionamento

com SVMs [22] e com Deep Learning.

O KNN é um algoritmo de classificação que identifica a instância baseado no K-

vizinho mais próximo cuja classe já se conhece [23]. A escolha do melhor K vai variar

de acordo com o conjunto de dados. O vizinho mais próximo é calculado com base no

valor desse K, que significa quantos vizinhos devem ser considerados. A similaridade é

medida de acordo com a distância das instâncias mais próximas. Esse algoritmo requer

um pouco mais de memória, e esta é a principal desvantagem. Além disso, KNN pode

se confundir caso a instância tenha muitos atributos irrelevantes [23]. A versão do KNN

utilizada neste trabalho foi o IBk [24], implementada pela biblioteca do Weka.1

Um classificador Naive-Bayes usa uma função de probabilidade para definir a qual

classe uma dada instância pertence [25]. A probabilidade é calculada de acordo com suas

caracteŕısticas e a distribuição condicional de dada instância. Então, a probabilidade final

é calculada usando essas probabilidades e funções distribúıdas entre as classes objetivo.

1Weka é coleção de algoritmos de aprendizagem de máquina. Permite a exportação dos modelos declassificação para o uso em código java. http://www.cs.waikato.ac.nz/ml/weka/downloading.html

16

As principais vantagens de usar Naive-Bayes são a rapidez do treinamento e teste. Esse

algoritmo é bom com valores numéricos e nominais, requer pouca memória e tem um baixo

custo computacional [26] [27]. A maior desvantagem está em supor a forte independência

entre as funcionalidades causando uma perda de acurácia e no fato de funcionar melhor

em um grande conjunto de dados.

A Árvore de decisão é uma técnica de aprendizado supervisionado que constrói, a

partir de um conjunto de informações, uma árvore capaz de classificar dados. O algoritmo

de árvore de decisão usado neste trabalho foi o J48 - implementação em Java da árvore de

decisão C4.5 que é um conjunto de algoritmos usado para criar árvores de decisão para ML

e mineração de dados [25]. A árvore é constrúıda usando uma estratégia top-down, onde

a raiz é a feature, ou caracteŕıstica, que tem o maior ganho de informação e o processo

continua recursivamente até que todas as instâncias sejam particionadas em subconjuntos

pertencentes a mesma classe. O ganho de informação de uma feature indica o quão

importante ela é. Os atributos mais próximos a raiz são os atributos mais importantes.

Desta forma a árvore vai ter menos regras. C4.5 tem muitas vantagens, como a facilidade

de visualização e entendimento, possibilidade de conversão em um conjunto de regras,

capacidade lidar com dados nominais, numéricos e valores vazios no conjunto de dados.

Porém tem um baixo desempenho caso muitas interações complexas causem o problema

da replicação, isto é, muitas sub-árvores sejam iguais [28].

Random forest (RF) é um classificador que combina árvores de decisão onde o

resultado da classificação é a classe mais votada entre as árvores. Breiman em [29] define

esse classificador como uma coleção de classificadores com a estrutura de árvores {h(x,

k), k = 1,...} onde k são vetores aleatórios distribúıdos independentemente, e cada árvore

tem um único voto para a classe mais popular de uma dada entrada x. O fato que esse

classificador é uma combinação de outros classificadores entrega algumas caracteŕısticas

especiais para o Random Forest que o diferencia substancialmente das tradicionais árvores

de decisão [30]. Como já foi mencionado, há uma limitação do quão complexa uma árvore

de decisão pode se tornar [28], pois, caso se torne muito complexa, podemos sofrer com

sobre-ajuste, i.e. o modelo se ajusta muito bem ao conjunto de dados anteriormente ob-

servado, mas se mostra ineficaz para prever novos resultados. RF aumenta a diversidade

das árvores crescendo-as a partir de diferentes subconjuntos do banco de dado de trei-

17

namento [30]. Assim, as árvores em diferentes sub-espaços generalizam sua classificação

de forma complementar [31]. Então, RF é uma ferramenta efetiva em predição. É um

classificador bastante acurado e não sofre do problema de sobre-ajuste [29].

Máquinas de vetores de suporte, ou SVM, do inglês Support Vector Machines, é

uma estratégia de classificação baseada no prinćıpio de minimização de risco estrutural. A

ideia é encontrar a hipótese h que aproximadamente minimiza o erro verdadeiro, contro-

lando eficientemente e efetivamente as dimensões do espaço que contém h, classificando

as instâncias e separando-as em um hiper-espaço [32]. SVMs também podem ser con-

sideradas, como uma entidade matemática ou um algoritmo que maximiza uma função

matemática particular, de acordo com uma base de dados, rotulando instâncias a partir

de exemplos [33]. As SVMs, em sua forma mais básica, aprendem uma função de limiar

linear. Porém, integrando um kernel apropriado [32], as SVMs podem usar classificado-

res polinomiais, redes de funções de base radial, redes neurais sigmoidais, dentre outros.

Cada kernel da SVM têm hiper parâmetros desconhecidos que devem ser escolhidos antes

do treinamento. E cada problema tem um valor diferente para estes hiper parâmetros.

Por isso, para esse algoritmo é necessário fazer uma busca pelos melhores parâmetros, ou

tuning, antes do treinamento [34]. Por fim, SVMs conseguem ser robustas mesmo quando

a base de treinamento é tendenciosa (por nossa base ser pequena essa caracteŕıstica é

interessante) e são flex́ıveis, sendo boas soluções para diversos problemas já que podemos

introduzir diferentes kernels [35]. Um classificador SVM nem sempre supera a solução

mais simples [36], como uma árvore de decisão por exemplo. SVMs são mais dif́ıceis de

se interpretar, quando o kernel não é linear, e, quando misturamos atributos nominais

e numéricos, Random Forests tem melhores resultados em diversos casos [37]. Ou seja,

apesar do SVM ser uma ótima e flex́ıvel ferramenta, é necessário escolher o kernel apro-

priado e seus hiper parâmetros cuidadosamente para cada problema e para cada base de

dados de forma a obter bons resultados.

O perceptron multi camadas ou, MLP, do inglês Multi Layer Perceptron, também

chamado de Feed-forward network é um tipo de rede neural formada por uma função de

ativação em uma camada escondida, provendo um mapeamento de um vetor de entrada

e um de sáıda. Normalmente uma MLP tem 3 camadas: uma de entrada, uma escondida

e uma de sáıda. Cada camada é cheia de neurônios, e cada neurônio possui uma função

matemática, chamada de função de ativação. Esses neurônios são interconectados entre si

18

através de pesos [38]. MLP é um algoritmo muito utilizado para problemas de regressão,

porém também é usado em problemas de classificação, como o apresentado nesse trabalho,

pela sua capacidade de aprender e modelar relações complexas e não lineares entre as

caracteŕısticas dos dados. Porém, além de ter um alto custo de treinamento e teste, o

MLP muitas vezes cai no erro mı́nimo local ao invés do global, ou seja, por vezes ele não

encontra a melhor solução.

Por último, um algoritmo de classificação baseado em regras é o meio mais simples

e mais direto de todos. Normalmente o algoritmo forma uma estrutura no formato de IF-

THEN-ELSE. JRip (RIPPER) [39] é um algoritmo que funciona baseado em um conjunto

de regras. Usa um método de ”dividir e conquistar”com o objetivo de reduzir o erro. A

construção desse conjunto de regras é feito adicionando regras, adicionando condições até

as instâncias convergirem na mesma classe [40]. Suas vantagens são a flexibilidade, fácil

implementação de novas regras que podem ser criadas ou modificadas para novos dados,

fácil interpretação, pouca exigência de recursos de memória e processamento [41]. Sua

principal desvantagem é que ele não apresenta bons resultados quando alguns exemplos

do banco de dados de treinamento apresentam caracteŕısticas faltantes, isto é, exemplos

incompletos [42].

19

3 TRABALHOS RELACIONADOS

A migração de qualquer tarefa para a nuvem é senśıvel a múltiplos parâmetros do

sistema, como o contexto do dispositivo, o tipo da aplicação, o estado da rede, e com

tantos parâmetros torna-se dif́ıcil saber qual o momento mais oportuńıstico para fazer o

offload [5]. Consequentemente, para lidar com esses desafios, os trabalhos mais recentes

trazem propostas de novos frameworks, algoritmos, modelos, middlewares, que dependem

do monitoramento periódico de várias métricas para inferir onde a execução do código

exigirá menos esforço computacional.

As soluções mais recentes, como Thinkair [8], Mobibyte [43], Anyrun [10], CADA

[44], Kwon et al. [45], OMMC [46], mCloud [47], Majeed et al. [9] e CSOS [3], implemen-

tam um sistema de monitoramento, modelos energéticos, modelos de decisão, e sistemas

que gerenciam a comunicação entre a nuvem e o dispositivo. Esses sistemas são implemen-

tados em smartphones, ou seja, os dispositivos monitoram e decidem onde a tarefa será

executada. Outros estudos como o MAUI [48], EMCO [49] e Rego et al. [11], executam

operações complexas para a tomada de decisão fora do dispositivo móvel.

A Tabela 1 apresenta um resumo das soluções existentes e suas caracteŕısticas.

Provê informação sobre as fontes contextuais adotadas por cada solução, quais técnicas

foram usadas para a tomada de decisão de onde executar o OC, de forma a melhorar o

desempenho da aplicação, ou economizar o máximo a energia do dispositivo. A tabela

também informa se o estudo avalia o desempenho do algoritmo que toma as decisões,

analisando a acurácia por exemplo.

20

Tabela 1 Comparação qualitativa de soluções senśıveis ao contexto

Nome das

soluções

Fontes contextuais Caracteŕısticas

App DispositivoRede sem

Fio

Nuvem/

CloudletDecisão

Acurácia

(%)

MAUI x x x - Programação linear None

ThinkAir x x x - Modelo energético NA

Mobibyte x x x - Modelo energético NA

ARC - x x - Naive Bayes NA

Kwon et al. x x - - Regressão polinomial NA

OMMC x x x -TOPSIS e

Modelo energéticoNA

mCloud x x x -TOPSIS e

Modelo de custoNA

EMCO x x x - Lógica Fuzzy NA

Rego et al. x x x - Árvore de decisão NA

CADA - x x - Modelo energético 90

Majeed et al. x x x - SVM 92

CSOS x x x x

(K-NN, Regras,

Naive Bayes,

e Árvore de decisão)

95

Este trabalho x x x x

(K-NN, Regras,

Naive Bayes,

SVM, MLP

Árvore de decisão

Random Forest)

95

Quanto à decisão de onde a tarefa deverá ser executada, ThinkAir, MobiByte,

CADA, e OMMC fazem essas decisões considerando a energia envolvida tanto na com-

putação da tarefa quanto na comunicação entre o dispositivo e a nuvem. As medições de

energia usam modelos de estimação energéticas. A solução do MAUI no entanto resolve

um problema de programação linear no servidor remoto granularizando que métodos de-

vem ser executados remotamente e quais devem ser executados localmente. Depois, essa

informação é enviada e atualizada nos dispositivos.

Outras soluções como EMCO e Majeed et al., lidam com decisões de offloading

baseado em modelos de decisão baseado em contexto, como lógica fuzzy e Support Vector

21

Machine (SVM), respectivamente. EMCO propõe o uso de lógica fuzzy para agregar as

informações contextuais, que em conjunto com os dados históricos constroem um sistema

de inferência que classifica onde cada tarefa deve ser executada, local ou remotamente. Já

o sistema proposto por Majeed et al. usa SVM para esse mesmo propósito. O classificador

SVM adapta sua decisão de acordo com os dados contextuais internos e externos providos

pelo modulo de profiling que monitora e armazena essas informações.

Tanto o CSOS quanto o Rego et al. utilizam abordagens baseadas em Árvore

de decisão para a tomada de decisão de onde executar determinada tarefa, levando em

conta tanto a informação contextual atual quanto os dados históricos. Já o sistema ARC,

ou AnyRun Computing, escolheu usar o modelo de decisão Naive Bayes para analisar a

probabilidade que o processo de offloading é vantajoso quando o compara a execução local

do OC. Knwon et al. e mCloud usam outras técnicas para essa previsão de onde a execução

é mais benéfica. mCloud, framework de offloading proposto por [47], contém um algoritmo

para tomar decisões de onde executar tarefas computacionais em tempo de execução, além

de selecionar o tipo de rede sem fio (Wifi, 4G, bluetooth, etc) e para qual nuvem o offload

deve ocorrer. Os autores aplicam a técnica de ordenação de preferência por similaridade,

do inglês Technique for Order of Preference by Similarity to Ideal Solution (TOPSIS) [50].

Para o tipo de rede sem fio vários critérios são analisados como: disponibilidade da

tecnologia escolhida, congestionamento da rede, custo energético da migração por este

canal); e aplicam um modelo de estimação de custo para calcular o custo de cada pedido

de offloading. Já o Knwon et al. propõe uma técnica de predição para superar o problema

da sensibilidade da entrada do desempenho da aplicação móvel. Esta técnica foi nomeada

de fMantis, e ela gera uma predição do desempenho da aplicação, analisando métricas

como: tempo de execução, consumo energético e uso de memória.

O trabalho CSOS [3] não aborda nem compara algumas técnicas de decisão, pre-

sentes em vários dos trabalhos relacionados, como o Support Vector Machine por exemplo.

Além disso, outra técnica importante que não foi abordada é o Random Forest, que é ex-

tremamente relevante quando se analisa que as melhores técnicas em [3] e [11] foram as

baseadas em regras e de árvore de decisão. Nosso trabalho visa complementar o trabalho

feito em [3], analisando e comparando esses outros algoritmos, utilizando a mesma base

de dados.

22

4 SOLUÇÃO PROPOSTA

Nesta Seção, descrevemos os detalhes de implementação das mudanças feitas na

aplicação BenchFace1 desenvolvida para a produção de [3] (4.1) e do AlgorithmCompare2

para automatizar o treinamento e teste dos algoritmos de machine learning (4.2).

4.1 BenchFace

BenchFace é um aplicativo de detecção de face que usa Haar features baseado

em classificadores em cascata, um método proposto pelos pesquisadores Michael Jones

e Paul Viola [51]. O algoritmo de detecção de face usa uma abordagem baseada em

aprendizagem de máquina, onde funções em cascata são treinadas com um conjunto de

imagens positivas (imagens que contêm faces) e negativas (imagens que não possuem

faces). Para a detecção facial, o aplicativo usa o openCV, biblioteca em c/c++ voltada

para o desenvolvimento de aplicativos na área de Visão computacional, que nos entrega

classificadores pre-treinados em formato de xml para uso. O classificador escolhido foi

o ”haarcascade frontalface default.xml”. Além disso, o aplicativo também possui uma

única imagem com diferentes resoluções contendo 77 faces para detecção. Sua execução

pode ocorrer na nuvem, local e dinamicamente. Ao final da execução é exibida na tela a

quantidade de faces detectadas e o tempo decorrido para detectá-las.

1Aplicação de benchmarking para detecção facial: https://github.com/ehammo/BenchFace2Programa de automação para o ajuste, treinamento e teste, usando validação cruzada, dispońıvel

para a comunidade no site: https://github.com/ehammo/algorithmCompare

23

A Figura 2 representa o aplicativo após a execução local da detecção facial.

Figura 2 BenchFace.

No sistema do CSOS [3], o desenvolvedor precisa anotar cada método que ele de-

seje classificar como OC, Offloading Candidate, estabelecendo se a migração deve sempre

acontecer, offloading estático, ou se uma decisão deve ser tomada, offloading dinâmico.

No caso de offloading dinâmico há a necessidade de determinar qual classificador será

usado para tomar a decisão. O Listing 4.1 ilustra justamente este passo

public interface DynamicDetectFacesJ48 extends DetectFaces {

@Remotable ( va lue=Remotable . Of f load .DYNAMIC, s t a tu s=true ,

c l a s s i f i e r=Remotable . C l a s s i f i e r . J48 )

Proper t i e sFace detec tFaces ( S t r ing c a s c a d e C l a s s i f i e r , byte [ ]

o r i g ina l Image ) ;

[ . . . ]

}

24

Listing 4.1 Anotação para especificar o classificador

Durante esse trabalho foi feita a portabilidade da aplicação para o Android P.

Essa tarefa foi extremamente necessária para que a aplicação funcione como esperado nos

dispositivos Android mais recentes. Para migrar a aplicação também foi necessário migrar

o middleware do lado do cliente. Dentre as maiores modificações destacamos:

• A compilação da biblioteca do OpenCV, que é em C++, não poderia usar mais o

NDK e deveria ser compilada usando CMake.

• Várias APIs públicas mudaram do Android N para o P. Foi necessário adaptá-las

ou trocá-las. Um exemplo foi a API que verifica a conexão com a internet.

• Também adicionamos várias permissões para a aplicação e as solicitamos para o

usuário.

Além disso adicionamos a funcionalidade de baixar os modelos de aprendizagem

de máquina do servidor sempre que o usuário desejar, automatizando a implantação dos

modelos. Esse passo também passa pelo middleware e deve ser anotado como um método

que exige um offloading estático. Isso se deve ao fato de que o treinamento e teste

dos modelos sempre é feito no servidor, que contém os dados e tem mais recursos. O

Listing 4.2 representa a interface para essa nova tarefa. O Objetivo é facilitar um posśıvel

retreinamento, onde o dispositivo enviaria novas informações para o servidor, que treinaria

diversos algoritmos de aprendizagem de máquina e os melhores seriam enviados de volta

logo em seguida.

public interface CloudletUpdateServ ice {

@Remotable ( va lue = Remotable . Of f load .STATIC, s t a tu s = true )

HashMap u p d a t e C l a s s i f i c a t o r s ( S t r ing [ ]

newInstances ) ;

}

Listing 4.2 Atualizar classificadores

O Retreinamento em si não foi implementado nesse trabalho. Como já foi men-

cionado, o objetivo era enviar novas informações das últimas execuções para o servidor

25

para retreinar os algoritmos. Porém, os algoritmos utilizados no estudo anterior [3] são

supervisionados, i.e. para treiná-los é necessário rotular os dados para a classe ”Sim”ou

”Nao”. No entanto, não se sabe se o algoritmo acertou ou errou em sua classificação, e

portanto não podemos rotular a execução para usá-la como novo dado de treinamento

para os algoritmos supervisionados.

4.2 AlgorithmCompare

O programa AlgorithmCompare foi desenvolvido para automatizar o ajuste, treina-

mento, teste e comparação dos algoritmos de decisão. Este programa funciona da seguinte

forma: inicialmente os parâmetros de cada modelo de ML são ajustados. Em seguida cada

classificador é treinado medindo o seu desempenho pela sua acurácia e outras métricas.

O teste é feito com 30 repetições de validação cruzada (10-fold) variando a semente (seed)

do Weka que distribui o banco em teste e treinamento de 1 a 30. Os resultados devem

então ser analisados e comparados usando técnicas estat́ısticas como matriz de confusão

e métricas de desempenho como especificidade, sensitividade, precisão e acurácia. Mais

detalhes sobre o teste foram descritos no caṕıtulo 5

O desenvolvimento do programa começou em [3], porém, muito dos passos ainda

eram manuais como a comparação entre os algoritmos. Os testes estat́ısticos eram feitos

em outros scripts não integrados, e, por fim, a implantação dos modelos da biblioteca Weka

para a aplicação também era feito de forma manual. Com o objetivo de posteriormente

trabalharmos com retreinamento, a aplicação do AlgorithmCompare e o BenchFace foram

integrados em um único arquivo ”.jar”, para que, desta forma, possamos acessar o código

de retreinamento pelo middleware da aplicação.

Outra grande mudança foi a inserção dos novos algoritmos de classificação no sis-

tema, como o SVM, MLP e RandomForest. E com eles, surgiu a necessidade de descobrir

quais eram os melhores valores para seus hiper parâmetros, aqueles que são escolhidos an-

tes de começar o treinamento. Anteriormente em [3], a escolha desses hiper parâmetros era

feita de forma manual, rodando o programa para obter os resultados para cada mudança e

posteriormente compará-los usando outras ferramentas. Apenas algumas alterações eram

feitas no programa em tempo de execução, como a podagem da árvore. Como agora

temos o objetivo de um posśıvel retreinamento e aumento da quantidade de dados em

mente, e com a inserção de algoritmos como SVM, a aplicação precisava ser capaz de

26

fazer um tuning automatizado de seus algoritmos. Então, inserimos o Grid Search, que é

uma das abordagens mais utilizadas para a otimização dos hiper parâmetros de um dado

modelo, isto é, encontrar os valores que entregam o melhor resultado. No caso do Algo-

rithmCompare, o Grid Search1 utilizado foi o da biblioteca do Weka, que foi configurado

para buscar pelo classificador com melhor acurácia. É necessário também configurar, para

cada algoritmo, quais dois hiper parâmetros serão otimizados.

4.2.1 Tuning

O algoritmo 1 mostra a configuração do grid search para cada algoritmo de clas-

sificação usado no programa. No MLP no entanto, o número de camadas escondidas não

pode ser escolhido como hiper parâmetro. Isso se deve ao fato que a implementação do

MLP do Weka recebe esse parâmetro em formato de texto, e a variação do GridSearch só

funciona com números e booleanos. É por este motivo que a variação da quantidade de ca-

madas escondidas do MLP é considerada como uma variação do algoritmo, ou seja, MLP

com uma camada escondida e MLP com 3 camadas escondidas são considerados como

dois algoritmos distintos. Isso também ocorre com o SMO, o algoritmo de otimização

mı́nima sequencial de John Platt usado para treinar uma SVM comum. Quando o kernel

do SMO muda, os seus hiper parâmetros também mudam. Então, SMO com um kernel

polinomial (SMO poly) é considerado um algoritmo diferente do SMO com um kernel de

função de base radial (SMO rbf).

1 http://weka.sourceforge.net/doc.stable/weka/classifiers/meta/GridSearch.html

27

Algorithm 1 Algoritmo que decide quais hiper parâmetros serão otimizados

1: gs← GridSearch()

2: gs.Evaluation← Acuracy

3: if classifierType = IBK then

4: gs.X ← KNN

5: gs.Y ←MeanSquare

6: else if classifierType = J48 then

7: gs.X ← Unpruned

8: gs.Y ← ConfidenceFactor

9: else if classifierType = JRIP then

10: gs.X ← UsePruning

11: gs.Y ← Optimizations

12: else if classifierType = SMO poly then

13: gs.X ← kernel.Exponent

14: gs.Y ← C

15: else if classifierType = SMO rbf then

16: gs.X ← kernel.gamma

17: gs.Y ← C

18: else if classifierType = MLP 1hidden or classifierType = MLP 3hidden then

19: gs.X ← LearningRate

20: gs.Y ←Momentum

21: else if classifierType = NAIVE BAYES then

22: gs.X ← UseKernelEstimator

23: gs.Y ← UseSupervisedDiscretization

24: else if classifierType = RANDOMFOREST then

25: gs.X ← Seed

26: gs.Y ← NumIterations // Number of trees

27: end if

No Algoritmo 1, podemos ver quais foram os hiper parâmetros escolhidos de cada

algoritmo para otimização. Para o algoritmo IBk (K-NN), alteramos o número K de vi-

zinhos que o algoritmo deve usar (KNN) e se usamos o erro médio quadrado ou absoluto

quando estamos fazendo a validação cruzada (MeanSquare). Para o J48, a árvore de

28

decisão, alteramos se vamos podá-la ou não (Unpruned) e o fator de confiança (Confi-

denceFactor), que também é intrinsecamente ligado com o quanto a árvore será podada.

Para o JRIP os parâmetros foram similares aos do J48: um sobre podagem das regras

(UsePruning) e o outro, ’Optimization’, refere-se a quantidade de vezes que o JRIP po-

dará a lista de regras. Para os dois SMOs temos um parâmetro geral, o C, que determina

a influência da classificação errada na função objetivo, e um espećıfico por kernel. Para o

SMO com kernel polinomial, alteramos o expoente (kernel.Exponent) do polinômio e para

o com kernel de função de base radial alteramos o gamma (kernel.gamma) que determina

a influência de um único exemplo de treinamento no todo. Para MLP, alteramos a taxa

de aprendizado (LearningRate) que controla o quanto o modelo muda em resposta ao erro

estimado a cada atualização de pesos, e o momento (Momentum) que é o parâmetro res-

ponsável por mudar o tamanho dos passos para tentar escapar dos erros mı́nimos locais.

Para Naive Bayes se escolhe se ele vai ou não usar um estimador de kernel (UseKerne-

lEstimator), ao invés de tentar normalizar os atributos, e se ele vai ou não discretizar

os dados não nominais (UseSupervisedDiscretization). E, por fim, para o RandomForest,

mudamos a quantidade de árvores (NumIterations), e a semente (Seed) para a geração

aleatória das árvores. Os demais hiper parâmetros foram mantidos com valores fixos.

29

5 EXPERIMENTOS E ANÁLISE DE RESULTADOS

5.1 Base de dados

A base de dados utilizada, foi a preenchida no trabalho [3]. Para a alimentação

dela foi necessário controlar os elementos contextuais, tais como: largura de banda, CPU

do smartphone, CPU da nuvem, o próprio smartphone, o tamanho dos dados a serem

transmitidos e a aplicação. A cada faixa de dados numéricos (contexto de baixo ńıvel)

desses elementos associou-se um dado nominal (contexto de alto ńıvel), a Tabela 2 mostra

este mapeamento. Foram feitos diversos testes emṕıricos para definir a faixa de valores

dos atributos 1, 3 e 5 [3]; Para os atributos 2 e 4 as faixas foram escolhidas de acordo

com os resultados de pesquisas feitas pelos autores de [3]. Por exemplo, para definir os

limites de memória RAM e velocidade de clock, utilizou-se uma biblioteca que analisa as

especificações do dispositivo.

Por fim, para cada variação contextual, i.e. para cada combinação de valores con-

textuais comparou-se o QoS da aplicação executada localmente ou utilizando a técnica de

offloading computacional. O QoS da aplicação foi medido através do tempo de execução.

Caso o tempo de execução na nuvem fosse igual ou menor ao tempo local, classifica-se

aquele contexto com o rótulo ’SIM’ - é melhor fazer offloading neste contexto. Caso

contrário, com ’NAO’ - indicando que é melhor executar essa tarefa localmente nesta

situação.

30

Tabela 2 Atributos e valores contextuais.

Núm Nome do atributo Contexto baixo ńıvel Contexto de alto ńıvel

1 Largura de Banda

[up/down>20] Livre

[2

31

planeja-se comparar todos os algoritmos entre si e os testes estat́ısticos utilizados exigem

2 ou mais amostras. Então cada resultado para cada semente é usado como uma amostra

daquele classificador.

Várias métricas, como a taxa de negativos verdadeiros (especificidade), taxa de

positivos verdadeiros ( sensitividade), taxa de falso positivo(FPR) e negativo(FNR), pre-

cisão e acurácia da classificação das classes de acordo com as fórmulas (5.1)-(5.7) descritas

abaixo:

Acurácia =TP + TN

TP + TN + FP + FN(5.1)

F1 =2TP

2TP + FP + FN(5.2)

Sensitividade = TPR =TP

TP + FN(5.3)

Especificidade = TNR =TN

TN + FP(5.4)

Precisão =TP

TP + FP(5.5)

FPR =FP

FP + TN= 1− TNR (5.6)

FNR =FN

FN + TP= 1− TPR (5.7)

Onde:

TP = O número de exemplos positivos classificados corretamente.

TN = O número de exemplos negativos classificados corretamente.

FP = O número de exemplos classificados erroneamente como positivos.

FN = O número de exemplos classificados erroneamente como negativos.

A acurácia de um classificador é indicado pela porcentagem do conjunto de dados

32

que foi classificado corretamente. A sensitividade mede a taxa em que os exemplos são

classificados positivamente, nos casos em que se deveria classificar positivamente. En-

quanto Especificidade mede a taxa em que os exemplos são classificados negativamente,

em caso em que se deveria classificar negativamente. Precisão é a fração dos exemplos

positivos classificados como positivos do grupo de todos os exemplos classificados como

positivos. Sensitividade e precisão são resumidas por outra métrica conhecida como

F1 (ver formula (5.2)). E FPR (5.6) e FNR (5.7) são respectivamente ’1 - Sensitivi-

dade’ e ’1 - Especificidade’, e representam a proporção de exemplos positivos e negativos

classificados erroneamente [52].

5.3 Comparação

Tendo os classificadores ajustados, treinados e testados, vamos comparar os re-

sultados de cada um deles de forma a criar um ranque entre os algoritmos, verificando

se há diferenças estat́ısticas entre cada um deles. Segundo Demsar [53], os testes mais

adequados para comparar acurácia de classificadores são os não-paramétricos. Dos testes

apresentados, podemos usar o teste de Wilcoxon ou o de Friedman. O teste de Wilcoxon

apresenta bons resultados quando se está comparando algoritmos treinados em bases di-

ferentes, que não é o nosso caso, já que as acurácias de cada fold da validação cruzada

não são completamente independentes. O teste de Friedman é um teste não-paramétrico

equivalente ao ANOVA com medidas repetidas [3,53], que ranqueia os resultados dos algo-

ritmos de forma diretamente proporcional para a acurácia do resultado de cada validação

cruzada. Após isso calcula-se a soma dos ranques e a média deles para cada algoritmo.

Usamos essa soma dos ranques para rejeitar ou não a hipótese nula de que há uma dife-

rença significativa entre esses algoritmos. Em [3], foi utilizado o teste de Friedman com o

pós teste Nemenyi para criar um ranque entre os algoritmos, e [53–55] mostram que esse

realmente é o melhor teste para nosso caso.

Sendo assim, usando a biblioteca javaNPST, Non Parametric Statistical Tests in

java [56] (Testes estat́ısticos não-paramétricos em java), podemos aplicar o teste de Fri-

edman com 95% de intervalo de confiança. Após aplicar o teste, vimos que a hipótese

nula foi rejeitada comprovando que existem diferenças significativas entre esses algorit-

mos. Na Tabela 3 podemos ver o resultados das somas e das médias dos ranques para

cada algoritmo:

33

Tabela 3 Resultados FriedmanAlgoritmo de classificação

RF MLP1 MLP3 NAIVE IBK J48 JRIP SMOpoly SMOrbf

Soma dos ranques 231,5 142,5 170 67 92,5 241,5 242 67,5 95,5

Média dos ranques 7,72 4,75 5,67 2,23 3,08 8,05 8,07 2,25 3,18

Desvio padrão dos ranks 1,60 2,69 2,02 1,79 2,19 1,57 1,24 2,28 2,59

No qual:

RF = Random Forest.

MLP1 = Perceptron multi camada, ou Multilayer Perceptron, com 1 camada escondida.

MLP3 = Perceptron multi camada, ou Multilayer Perceptron, com 3 camadas

escondida.

NAIVE = Naive Bayes.

IBk = Aprendiz baseado em instâncias, ou Instance-based learner, que usa o algoritmo

dos k vizinhos mais próximos, ou KNN do inglês k-nearest neighbors.

J48 = Implementação de código aberto em Java do algoritmo de árvore de decisão C4.5.

JRIP = Implementação em java do algoritmo de regras Podagem Incremental Repetida

para Produzir Redução do Erro, ou RIPPER do inglês, Repeated Incremental Pruning to

Produce Error Reduction.

SMOpoly = Algoritmo de otimização mı́nima sequencial de John Platt usado para

treinar uma SVM (Support Vector Machine) comum, usando um kernel polinomial.

SMOrbf = Algoritmo de otimização mı́nima sequencial de John Platt usado para

treinar uma SVM (Support Vector Machine) comum, usando um kernel de funções de

base radial.

Depois disso aplicamos o pós teste de Nemenyi usando o procedimento de múltiplas

comparações para analisar os pares dos algoritmos e montarmos um outro ranque, dessa

vez do número 1 ao 10, onde o ranque 1 é o melhor algoritmo e o 10 o pior. Para a

montagem do novo ranque, utilizamos apenas a soma dos ranques do teste de Friedman,

ordenando-o, onde os algoritmos com a maior soma são os melhores. O teste de Nemenyi

é aplicado em cada dupla de algoritmos com o objetivo de afirmar se a diferença entre os

valores da soma dos ranques são estatisticamente diferentes. Para isso, um valor cŕıtico

é calculado, apresentado na tabela a seguir como CV, critical value. Caso os valores

não sejam estatisticamente diferentes, os algoritmos podem compartilhar a mesma

34

posição no ranque. Os resultados podem ser analisados na tabela a seguir:

Tabela 4 Resultados Nemenyi

Algoritmo de classificação

J48 JRIP RF MLP3 MLP1 SMOrbf IBK SMOpoly NAIVE CV

Ranque 1 1 1 2 2 3 3 3 3 2.26

Friedman 8,07 8,05 7,72 5,67 4,75 3,18 3,08 2,25 2,24 -

Tempo treino(ms) 217 4028 4552 57929 26838 1238 597 1505 419 -

Tempo teste(ms) 9 589 1776 10026 4388 254 18 2262 3 -

Tamanho (bytes) 501 521 1471 2452 2446 1680 1278 1676 506 -

A Tabela 4, informa, além do novo ranque, da soma média do ranque de Friedman

e do valor cŕıtico utilizado nas comparações, o tempo para ajustar e treinar cada algoritmo

e o tempo médio para testar o modelo. Os tempos foram medidos em milissegundos. Além

disso, também se apresenta o tamanho em bytes que cada modelo ocuparia no cliente em

que seria implantado.

Os resultados foram similares ao trabalho passado, com os algoritmos J48, JRIP

e RandomForest empatando em primeiro lugar como os mais acurados. Já era esperado

que o Random Forest entregasse um bom resultado, pois, como explicado, esse algoritmo

é uma coletânea de árvores de decisão, e no trabalho passado a árvore de decisão (J48) foi

o algoritmo mais acurado. Porém isso não instantaneamente faz desse algoritmo a melhor

escolha sobre a árvore de decisão comum (J48). O principal diferencial do RF é suprir

o problema do sobre-ajuste, da instabilidade da árvore. Para nossos testes, como nosso

banco de dados é pequeno, a árvore de decisão se encontra estável e tem um menor custo

de recursos, já que consome em média 197 vezes menos tempo para testes, ou classificação

de instâncias (ocorrem com frequência no cliente) e ocupam 2.9 vezes menos espaço.

Acredita-se que os resultados são, em parte, consequência do tamanho da base de

dados. Tanto os MLPs quanto as SVMs tiveram um resultado ruim, se comparados com

os algoritmos baseados em árvores de decisão ou regras. Levando em conta que eles são

mais custosos para serem implementados, já que demoram milhares ou centenas de vezes

mais para treinar e testar, e seus modelos ocupam muito mais espaço que os algoritmos

mais simples, isso os torna opções inadequadas para este problema. Além disso, tanto os

MLPs quanto as SVMs, tiveram um ranque menor que as estratégias mais simples.

35

6 CONCLUSÃO E TRABALHOS FUTUROS

Este trabalho apresentou um novo comparativo de diversos algoritmos de apren-

dizagem de máquina: J48, JRIP, NAIVE BAYES, IBk, RandomForest, SMO, MLP, jun-

tamente com a aplicação AlgorithmCompare que automatizou o tuning, o treinamento,

o teste e a comparação desses algoritmos. O programa pode ser utilizado para qualquer

banco de dados, mas nesse trabalho ele foi utilizado apenas com os dados adquiridos

em [3], pois o foco aqui foi encontrar o algoritmo mais adequado para montagem de um

sistema de offloading senśıvel ao contexto.

Esse software, AlgorithmCompare, de forma robusta utiliza da biblioteca Weka

para otimizar (tuning), treinar e testar uma gama de algoritmos bem maior do que outros

frameworks similares apresentados na literatura. E é bastante simples adicionar novos

algoritmos ou diferentes versões de outros algoritmos nesse software, caso necessário. Para

comparar os algoritmos, foi estendido a classe que implementa o teste de Friedman e de

Nemenyi da biblioteca javaNPTS [56].

Os principais algoritmos introduzidos neste trabalho foram MLP, RandomForest

e SVM (SMO). O RandomForest foi introduzido pois, no trabalho passado, os melho-

res algoritmos foram os baseados em árvore de decisão e seria interessante verificar se

RandomForest teria um resultado melhor ou similar quando comparado a J48. SVM foi

introduzido pela sua robustez e flexibilidade. Acreditava-se que ela poderia ser uma boa

opção para este problema e o MLP também foi considerado devido ao seu relacionamento

com SVMs [22] e com Deep Learning.

Com a introdução desses novos algoritmos surgiu a necessidade de fazer o tuning

deles também de forma automatizada. Foi adicionado então um grid search na aplicação

do AlgorithmCompare com o intuito de escolher melhor os hiper parâmetros de cada um

dos algoritmos que estamos treinando. Para os testes, foi feita validação cruzada para cada

algoritmo, variando a semente de 1 a 30. Para a comparação automática se viu necessária

a execução de testes estat́ısticos em java. Para isso usamos a biblioteca javaNPST.

Os testes implementados em AlgorithmCompare foram os de Friedman, Wilcoxon e

Nemenyi. Mas nesse trabalho, utilizamos apenas o de Friedman seguido pelo de Nemenyi.

Com esses testes estat́ısticos foi gerado um rank dos melhores algoritmos.

Os três melhores algoritmos foram J48, JRIP e RandomForest. RandomForest foi

36

um algoritmo que entregou um bom resultado, se equiparando estatisticamente com J48

e o JRIP. Porém, por ser um algoritmo mais complexo, ele ocupa mais espaço e demora

mais para treinar e classificar instâncias. Além disso, tanto as SVMs quanto os MLPs

testados não obtiveram um bom resultado se comparados com as estratégias mais simples,

baseadas em regras e árvore de decisão. SVMs e MLPs demoram ainda mais para treinar

e classificar instâncias e seus modelos treinados são os maiores (em bytes) de todos os

algoritmos testados, ocupando mais espaço no armazenamento do cliente. E além disso

sua acurácia foi inferior aos outros algoritmos. Acredita-se que esses resultados são, em

parte, consequência do tamanho da base de dados. A base de dados adquirida em [3] é

considerada muito pequena, e possui apenas 302 exemplos devido ao fato que cada um

desses exemplos foi adquirido com testes manuais no mundo real.

Em trabalhos futuros, os dados poderão ser adquiridos de forma mais automática,

sem necessariamente controlar todos os aspectos contextuais para a alimentação desse

banco. Assim, mesmo que o banco de dados fique um pouco desbalanceado (entre as clas-

ses ’SIM’ e ’NAO’), seria posśıvel trabalhar com mais dados e obter classificadores capazes

de lidar melhor com o mundo real. Automatizando o controle contextual, também seria

posśıvel executar um determinado dado vindo do cliente para sua classe complementar e,

posteriormente, alimentar os algoritmos com os novos dados. Por exemplo, caso o cliente

enviasse um dado em que ele decidiu executar na nuvem, e enviasse dados como o QoS

da aplicação para aquela tarefa e o seu gasto energético, poderia-se executar esse dado

localmente, em um aparelho virtual simulando as caracteŕısticas no cliente, comparando

o QoS e o gasto energético para decidir se aquele contexto é adicionado a base como um

contexto da classe ”SIM”, é vantajoso fazer offloading, ou ”NAO”, não é vantajoso.

37

REFERÊNCIAS

[1] FLORES, H. et al. Mobile code offloading: from concept to practice and beyond. IEEE

Communications Magazine, v. 53, n. 3, p. 80–88, mar 2015. ISSN 0163-6804.

[2] JUNIOR, W. et al. Supporting mobility-aware computational offloading in mobile

cloud environment. Journal of Network and Computer Applications, Elsevier Ltd, v. 94,

n. July, p. 93–108, sep 2017. ISSN 10848045.

[3] JUNIOR, W. et al. A context-sensitive offloading system using machine-learning

classification algorithms for mobile cloud environment. Future Generation Com-

puter Systems, v. 90, p. 503 – 520, 2019. ISSN 0167-739X. Available at:

.

[4] FERNANDO, N.; LOKE, S. W.; RAHAYU, W. Mobile cloud computing: A survey.

Future Generation Computer Systems, Elsevier B.V., v. 29, n. 1, p. 84–106, jan 2013.

ISSN 0167739X.

[5] FLORES, H. et al. Social-aware hybrid mobile offloading. Pervasive and Mobile Com-

puting, v. 36, p. 25–43, apr 2017. ISSN 15741192.

[6] BETTINI, C. et al. A survey of context modelling and reasoning techniques. Pervasive

and Mobile Computing, Elsevier B.V., v. 6, n. 2, p. 161–180, 2010. ISSN 15741192.

[7] ABOWD, G. D. et al. Towards a better understanding of context and context-

awareness. In: Proceedings of the 1st International Symposium on Handheld and Ubi-

quitous Computing. London, UK, UK: Springer-Verlag, 1999. (HUC ’99), p. 304–307.

ISBN 3-540-66550-1.

[8] KOSTA, S. et al. ThinkAir: Dynamic resource allocation and parallel execution in the

cloud for mobile code offloading. In: 2012 Proceedings IEEE INFOCOM. [S.l.]: IEEE,

2012. p. 945–953. ISBN 978-1-4673-0775-8. ISSN 0743166X.

[9] MAJEED, A. A. et al. Code offloading using support vector machine. In: 2016

Sixth International Conference on Innovative Computing Technology (INTECH). [S.l.]:

IEEE, 2016. p. 98–103. ISBN 978-1-5090-2000-3.

38

[10] FERRARI, A.; GIORDANO, S.; PUCCINELLI, D. Reducing your local footprint

with anyrun computing. Computer Communications, Elsevier B.V., v. 81, p. 1–11, may

2016. ISSN 01403664.

[11] REGO, P. A. L. et al. Decision Tree-Based Approaches for Handling Offloading De-

cisions and Performing Adaptive Monitoring in MCC Systems. In: 2017 5th IEEE

International Conference on Mobile Cloud Computing, Services, and Engineering (Mo-

bileCloud). [S.l.]: IEEE, 2017. p. 74–81. ISBN 978-1-5090-6325-3.

[12] HUANG, D.; WANG, P.; NIYATO, D. A Dynamic Offloading Algorithm for Mobile

Computing. v. 11, n. 6, p. 1991–1995, 2012.

[13] WANG, Q. et al. Mobile Healthcare Systems with Multi-cloud Mobile Healthcare

Systems with Multi-cloud Offloading. n. June, 2013.

[14] WANG, Z. et al. Bus-Based Content Offloading for Vehicular Networks. v. 19, n. 3,

p. 250–258, 2017.

[15] MERSHAD, K. SCORE : Data Scheduling at Roadside Units in Vehicle Ad Hoc

Networks. n. Ict, p. 0–5, 2012.

[16] ARCHITECTURES, S. et al. A Survey on Mobile Social Networks : and Future

Research Directions. v. 17, n. 3, p. 1557–1581, 2015.

[17] QIU, J. et al. A survey of machine learning for big data processing. EURASIP Journal

on Advances in Signal Processing, EURASIP Journal on Advances in Signal Processing,

2016. ISSN 1687-6180.

[18] KOTSIANTIS, S. B. Supervised Machine Learning : A Review of Classification

Techniques. v. 31, p. 249–268, 2007.

[19] DOMINGOS, P. A few useful things to know about machine learning. Communica-

tions of the ACM, v. 55, n. 10, p. 78, 2012. ISSN 00010782.

[20] DAS, K.; BEHERA, R. N. A Survey on Machine Learning : Concept ,. p. 1301–1309,

2017.

39

[21] ROKACH, L.; MAIMON, O. Top-Down Induction of Decision Trees Classifiers—A

Survey. IEEE Transactions on Systems, Man and Cybernetics, Part C (Applications

and Reviews), v. 35, n. 4, p. 476–487, 2005. ISSN 1094-6977.

[22] COLLOBERT, R.; BENGIO, S. Links between perceptrons, mlps and svms. In:

ACM. Proceedings of the twenty-first international conference on Machine learning.

[S.l.], 2004. p. 23.

[23] BHATIA, N.; AUTHOR, C. Survey of Nearest Neighbor Techniques. IJCSIS) Inter-

national Journal of Computer Science and Information Security, v. 8, n. 2, p. 302–305,

2010. ISSN 1098-6596.

[24] AHA, D.; KIBLER, D. Instance-based learning algorithms. Machine Learning, v. 6,

p. 37–66, 1991.

[25] WU, X. et al. Top 10 algorithms in data mining. Knowledge and information systems,

Springer, v. 14, n. 1, p. 1–37, 2008.

[26] ARCHANA, S.; ELANGOVAN, K. Survey of Classification Techniques in Data Mi-

ning. International Journal of Computer Science and Mobile Applications, v. 2, n. 2,

p. 65–71, 2014. ISSN 2321-8363.

[27] KEOGH, E. Näıve Bayes Classifier. 2006. ISSN 13652753.

[28] PAGALLO, G.; HAUSSLER, D. Boolean Feature Discovery in Empirical Learning.

Machine Learning, v. 5, n. 1, p. 71–99, 1990. ISSN 15730565.

[29] BREIMAN, L. Random forests. Machine learning, Springer, v. 45, n. 1, p. 5–32,

2001.

[30] RODRIGUEZ-GALIANO, V. F. et al. An assessment of the effectiveness of a random

forest classifier for land-cover classification. ISPRS Journal of Photogrammetry and

Remote Sensing, Elsevier, v. 67, p. 93–104, 2012.

[31] HO, T. K. Random decision forests. In: IEEE. Proceedings of 3rd international con-

ference on document analysis and recognition. [S.l.], 1995. v. 1, p. 278–282.

40

[32] JOACHIMS, T. Text categorization with support vector machines: Learning with

many relevant features. In: SPRINGER. European conference on machine learning.

[S.l.], 1998. p. 137–142.

[33] NOBLE, W. S. What is a support vector machine? Nature biotechnology, Nature

Publishing Group, v. 24, n. 12, p. 1565, 2006.

[34] HSU, C.-W. et al. A practical guide to support vector classification. Taipei, 2003.

[35] AURIA, L.; MORO, R. A. Support vector machines (svm) as a technique for solvency

analysis. 2008.

[36] LEWIS, D. P.; JEBARA, T.; NOBLE, W. S. Support vector machine learning from

heterogeneous data: an empirical analysis using protein sequence and structure. Bioin-

formatics, Oxford University Press, v. 22, n. 22, p. 2753–2760, 2006.

[37] FERNÁNDEZ-DELGADO, M. et al. Do we need hundreds of classifiers to solve real

world classification problems? The Journal of Machine Learning Research, JMLR. org,

v. 15, n. 1, p. 3133–3181, 2014.

[38] SAHOO, G.; KUMAR, Y. Analysis of parametric & non parametric classifiers for

classification technique using weka. International Journal of Information Technology

and Computer Science (IJITCS), v. 4, n. 7, p. 43, 2012.

[39] COHEN, W. Fast effective rule induction. Twelfth International Conference on Ma-

chine Learning, p. 115–123, 1995.

[40] ENGG, S.; SCIENCE, C. Survey on Classification Methods using WEKA. v. 86,

n. 18, p. 16–19, 2014.

[41] LORENA, A. C. et al. Comparing machine learning classifiers in potential distribu-

tion modelling. Expert Systems with Applications, Elsevier, v. 38, n. 5, p. 5268–5275,

2011.

[42] DUMA, M. et al. Improving the Performance of the Ripper in Insurance Risk Clas-

sification : a Comparitive Study Using Feature Selection. Electrical Engineering, 2010.

41

[43] KHAN, A. u. R. et al. MobiByte: An Application Development Model for Mobile

Cloud Computing. Journal of Grid Computing, v. 13, n. 4, p. 605–628, dec 2015. ISSN

1570-7873.

[44] Ting-Yi Lin et al. Context-aware decision engine for mobile cloud offloading. In: 2013

IEEE Wireless Communications and Networking Conference Workshops (WCNCW).

[S.l.]: IEEE, 2013. p. 111–116. ISBN 978-1-4799-0110-4.

[45] KWON, Y. et al. Precise execution offloading for applications with dynamic behavior

in mobile cloud computing. Pervasive and Mobile Computing, v. 27, p. 58–74, 2016.

ISSN 15741192.

[46] GHASEMI-FALAVARJANI, S.; NEMATBAKHSH, M.; Shahgholi Ghahfarokhi, B.

Context-aware multi-objective resource allocation in mobile cloud. Computers & Elec-

trical Engineering, Elsevier, v. 44, p. 218–240, may 2015. ISSN 00457906.

[47] ZHOU, B. et al. mCloud: A Context-aware Offloading Framework for Heterogeneous

Mobile Cloud. IEEE Transactions on Services Computing, PP, n. 99, p. 1–1, 2015. ISSN

1939-1374.

[48] CUERVO, E. et al. MAUI : Making Smartphones Last Longer with Code Offload. In:

8th international conference on Mobile systems, applications, and services. [S.l.: s.n.],

2010. p. 49–62. ISBN 9781605589855.

[49] FLORES, H.; SRIRAMA, S. Adaptive code offloading for mobile cloud applications:

Exploiting fuzzy sets and evidence-based learning. MCS ’13, p. 9–16, 2013.

[50] HWANG, C.-L.; LAI, Y.-J.; LIU, T.-Y. A new approach for multiple objective deci-

sion making. Computers & operations research, Elsevier, v. 20, n. 8, p. 889–899, 1993.

[51] VIOLA, P.; JONES, M. et al. Rapid object detection using a boosted cascade of

simple features. CVPR (1), v. 1, p. 511–518, 2001.

[52] WENG, C.-H.; HUANG, T. C.-K.; HAN, R.-P. Disease prediction with different

types of neural network classifiers. Telematics and Informatics, Elsevier, v. 33, n. 2, p.

277–292, 2016.

42

[53] DEMŠAR, J. Statistical comparisons of classifiers over multiple data sets. Journal of

Machine learning research, v. 7, n. Jan, p. 1–30, 2006.

[54] FRIEDMAN, M. The use of ranks to avoid the assumption of normality implicit in

the analysis of variance. Journal of the American Statistical Association, v. 32, n. 200,

p. 675–701, 1937.

[55] FRIEDMAN, M. A comparison of alternative tests of significance for the pro-

blem of m rankings. The Annals of Mathematical Statistics, Institute of Mathe-

matical Statistics, v. 11, n. 1, p. 86–92, 1940. ISSN 00034851. Available at:

.

[56] DERRAC, J.; GARCÍA, S.; HERRERA, F. Javanpst: Nonparametric statistical tests

in java. arXiv preprint arXiv:1501.04222, 2015.

introduçãoFundamentosSistema de offloading sensível ao contextoAlgoritmos de classificação

Trabalhos RelacionadosSOLUÇÃO PROPOSTABenchFaceAlgorithmCompareTuning

EXPERIMENTOS E ANÁLISE DE RESULTADOSBase de dadosTreinamento e testeComparação

CONCLUSÃO E TRABALHOS FUTUROS

Universidade Federal de Pernambuco - CIn UFPEtg/2019-1/TG_CC/tg_ehammo.pdf · 2019. 7. 14. ·...

Documents

Transcript of Universidade Federal de Pernambuco - CIn UFPEtg/2019-1/TG_CC/tg_ehammo.pdf · 2019. 7. 14. ·...