Tendo em consideração os objetivos e funcionalidades anteriormente enunciados, bem como o processo típico de reconhecimento de atividades e as necessidades específicas deste projeto abordadas no capítulo anterior, procedeu-se à recolha dos requisitos através de uma descrição de alto nível para a biblioteca a desenvolver. Esta descrição contempla fases distintas da utilização da biblioteca. Em primeiro lugar, a criação do sistema e subsistemas adicionais através de construtores apropriados. Depois a utilização do sistema, contemplando as suas diferenças de utilização no modo de treino e no modo de teste. Para além disto, foram também identificados requisitos não funcionais importantes para atingir os objetivos da biblioteca.
4.1.1 Construtor de um sistema
O construtor do sistema é a estrutura responsável pela criação coerente de um sistema de reconhecimento de atividades. Tem os seguintes requisitos:
1. Recetor de dados. Este tipo de objeto é responsável por receber e guardar os dados em bruto vindos dos sensores. Contempla os seguintes parâmetros:
a. Nome identificador do recetor. Por exemplo: “acelerómetro”.
b. Nomes identificadores das dimensões do recetor. Por exemplo: “x”, “y”, “z”. c. Comprimento da janela de dados.
d. Quantidade de sobreposição entre novas janelas de dados.
2. Extrator de características. Este tipo de objeto é responsável por processar os dados e extrair os valores que formarão a instância final de características do sistema. A ordem pela qual os extratores são adicionados ao sistema é a ordem pela qual serão executados. Contempla os seguintes parâmetros:
a. Nome do extrator e a respetiva classe.
b. Objeto(s) com os dados que se pretende serem processados pelo extrator de características. Um extrator pode receber dados de dimensões e/ou resultados de outros extratores de características anteriores a ele.
c. Opção de adicionar o extrator de características sem que o seu resultado seja adicionado à instância de características finais.
Restrições:
d. Um extrator de características só pode implementar um construtor.
e. Os objetos passados para o extrator de características devem ser coerentes com os esperados pelo seu construtor.
3. Seletor de características. Este tipo de objeto é responsável por diminuir o número de características do sistema a utilizar na classificação, selecionando para isso as mais relevantes. Esta funcionalidade tem como objetivo tornar clara a etapa de seleção de
31 caraterísticas no construtor do sistema, no entanto deverá ser possível adicionar um classificador do Weka que já possua seleção de atributos integrada. Nesse caso esta funcionalidade não deve ser utilizada. Contempla o seguinte parâmetro:
a. Objeto adaptador que permite integração com algoritmos de seleção de características do Weka.
4. Classificador. Este tipo de objeto é responsável por fazer a classificação dos dados devolvendo como resultado uma das atividades definidas no sistema.
a. Objeto adaptador que permite integração com algoritmos de classificação do Weka. 5. Categorias ou classes das atividades a classificar pelo sistema. São identificadores das atividades que o sistema deve determinar como sendo a atividade que está a ser executada. Cada classe deve ser única para um dado sistema. Exemplo: “standing”, “side”, “squat”,
“jump”.
6. Subsistema. O construtor do sistema pode receber um construtor de um subsistema, ficando responsável pela criação deste. O nome identificador do construtor de um subsistema deverá ser igual ao de uma das atividades existentes no sistema que recebe esse subsistema. 7. Delimitador de categorias. É possível definir como o sistema deve delimitar nomes de subactividades. No caso de uma classificação devolver um resultado que engloba um subsistema, as categorias e subcategorias são concatenadas através de um delimitador
como por exemplo “_”. Assim, se um sistema é classificado com “side” e o seu subsistema com “left” a classificação final é “side_left”. Este delimitador pode também ser utilizado
pelo sistema sempre que este necessite de delimitar algum nome. Por exemplo, quando é extraído mais do que um valor para determinado extrator de características ou em nomes de ficheiros para subsistemas.
8. Reutilização de instâncias. É possível definir se se pretende reutilizar a mesma instância ou ir guardando em memória as instâncias de características que vão sendo criadas/utilizadas pelo sistema.
9. Criar sistema. O sistema descrito é verificado e criado bem como os seus subsistemas. 4.1.2 Construtor de um subsistema
A construção de um sistema e de um subsistema deverá ser diferenciada. Isto porque apesar de semelhantes, o construtor de um subsistema deverá ter algumas restrições:
1. Não deverá permitir a criação do subsistema delegando essa tarefa para o sistema que recebe o construtor.
2. Não deve permitir adicionar um recetor de dados, uma vez que os recetores dos subsistemas serão os mesmos do sistema principal.
3. A opção de definir o delimitador de categorias apenas deve estar disponível no sistema principal.
32
4.1.3 Utilização do sistema
Após criação de um sistema este pode ser utilizado essencialmente para dois fins: treinar atividades e testar atividades. Inclui por isso os seguintes requisitos:
1. Adicionar dados. Permite adicionar dados vindos dos sensores ao sistema. Contempla os seguintes parâmetros:
a. Identificar o recetor de dados. Pode ser através do seu índice ou nome.
b. Adicionar os dados respetivos a cada dimensão. O número de dados introduzidos deve ser igual ao número de dimensões do recetor indicado.
Restrições:
c. Um recetor assim que atinja a sua capacidade máxima (janela de amostragem) não pode receber mais dados até que o sistema o reinicie. Esse reinício é feito após a extração de características no modo de treino do sistema ou após uma classificação no modo de teste.
2. Obter informação de sistema cheio. Permite determinar se todos os recetores do sistema atingiram a sua capacidade máxima (dados preenchidos para uma instância).
3. Mudar valor da sobreposição da janela de amostragem de dados para um recetor. 4. Mudar modo atual do sistema. Os modos disponíveis são:
a. Modo de treino. Este modo permite treinar o sistema com os dados vindos dos sensores.
b. Modo de teste. Este modo permite classificar dados vindos dos sensores após o sistema ter sido treinado.
5. Carregar instâncias para o sistema a partir de ficheiro. Permite ler instâncias guardadas num ficheiro ARFF ou CSV. Contempla as seguintes possibilidades de parâmetros:
a. Nome do ficheiro. Deve conter o seu caminho e a sua extensão. Caso exista um subsistema e na mesma diretoria esteja um ficheiro cujo nome esteja delimitado corretamente carrega automaticamente esse ficheiro para o subsistema.
b. Nome do ficheiro e nome do sistema/subsistema. Idêntico ao anterior, mas apenas carrega as instâncias para o sistema/subsistema especificado.
c. Nome da diretoria e tipo de ficheiro. Em alternativa aos parâmetros anteriores, é possível definir um nome da pasta onde estão os ficheiros do sistema e subsistemas. Se estes corresponderem aos nomes dados ao sistema e subsistemas serão automaticamente carregados.
d. Anexar. Cada opção anterior permite definir se se pretende anexar as instancias a carregar às existentes no sistema.
6. Guardar instâncias do sistema para um ou mais ficheiros. Permite guardar as instâncias criadas pelo sistema num ficheiro ARFF ou CSV. Contempla as seguintes possibilidades de parâmetros:
33 a. Nome do ficheiro. Deve conter o seu caminho e a sua extensão. As instâncias do sistema principal são guardadas no ficheiro especificado. Caso existam subsistemas são automaticamente criados ficheiros com o nome delimitado de acordo com delimitador do sistema e os nomes dos subsistemas.
b. Nome do ficheiro e nome do sistema/subsistema. Idêntico ao anterior mas apenas guarda as instâncias do sistema/subsistema especificado.
c. Nome da diretoria e tipo de ficheiro. Em alternativa aos parâmetros anteriores, é possível definir o nome da pasta onde se pretende guardar as instâncias. O sistema encarrega-se de criar os ficheiros com os respetivos nomes.
d. Anexar. Cada opção anterior permite definir se se pretende anexar as instancias a guardar às existentes num ficheiro.
7. Guardar instância atual do sistema para ficheiro. Permite guardar uma instância de cada
vez. Este modo de escrita de instâncias requer que o utilizador abra um “escritor” de
instâncias e depois o feche assim que não seja necessário escrever mais.
Apenas em modo de treino:
8. Extrair características. Extrai as características que formam uma instância através da execução dos extratores anteriormente adicionados ao sistema, responsáveis pela transformação dos dados recolhidos.
a. Categoria ou classe a extrair. Elemento textual que representa a atividade que se pretende associar aos dados que se acabou de recolher após extração de características. Caso se refira a uma atividade com subactividades, deve-se indicar cada categoria separada por vírgulas ou apenas utilizando o delimitador definido no construtor do sistema para efetuar a separação.
Restrições:
b. Só pode ser efetuado após todos os recetores de dados do sistema terem atingido a sua capacidade máxima para uma instância.
c. O nome da classe a extrair tem de corresponder a uma das categorias existentes no sistema.
9. Treinar classificador. Treina o classificador com as instâncias de características presentes no sistema.
Apenas em modo de teste:
10.Classificação. A classificação produz um elemento textual que representa a classe ou atividade a que os dados recolhidos melhor se associam. Inicialmente faz a extração de características, gerando a instância de valores que depois é classificada através do algoritmo de classificação escolhido para o sistema. A instância classificada recebe como
34
resultado dessa classificação o nome da categoria a que pertence. Existem duas possibilidades para a classificação:
a. Classificação simples. Apenas devolve a atividade mais provável, resultante da classificação.
b. Classificação com probabilidades. Para além de devolver a atividade mais provável, o sistema cria as probabilidades para as diferentes classes envolvidas.
Restrições:
c. Só pode ser efetuado após todos os recetores de dados do sistema terem atingido a sua capacidade máxima para uma instância
d. O classificador do sistema tem de estar treinado. 4.1.4 Requisitos não funcionais
Para além do comportamento específico é necessário determinar de que forma deve operar a biblioteca. Isto é especialmente importante no que toca à tomada de decisões relativamente à arquitetura a seguir. Assim, existem essencialmente três elementos importantes a ter em consideração:
1. Facilidade de utilização. A API a desenvolver deve ser simples e intuitiva mesmo para utilizadores que não estão familiarizados com o processo de reconhecimento de atividades ou com a aplicação de machine learning. Isto significa que após apresentação dos métodos e um exemplo prático de utilização, um programador deve ser capaz de criar treinar e testar um determinado sistema de reconhecimento de atividades que deseje.
2. Rapidez. Uma vez que uma possível utilização da biblioteca poderá ser em jogos em tempo real, esta tem de ser capaz de processar e classificar os dados recolhidos em paralelo com o processamento do jogo sem diminuir a performance deste. Isto significa não diminuir o número de frames por segundo do jogo em causa quando se aplicar o sistema de reconhecimento de atividades desejado neste projeto.
3. Java e open source. Uma vez que existe uma dependência nos algoritmos do Weka e o jogo a desenvolver tem como objetivo o sistema operativo Android, a linguagem de programação a escolher é o Java. Pretende-se também que a biblioteca seja disponibilizada como um projeto open source.