Extensão do App Inventor
5.2. Preparação do Ambiente de Desenvolvimento
5.3.2 Desenvolvimento do Servidor
Para facilitar a implementação do servidor, os modelos e turmas, foi decidido salvá-los em arquivo nas pastas “models” e “turmas” respectivamente, seguindo a hierarquia de arquivos apresentada no Quadro 17.
Dentro da pasta de cada modelo, além do arquivo de serialização de objetos Python da biblioteca pickle (https://docs.python.org/3/library/pickle.html), usado para salvar o modelo já treinado. Nesta mesma pasta existe um arquivo chamado “classes.txt”, que contém um dicionário de dados usado na tradução das classes de cada modelo. Na aplicação ainda não existe uma interface gráfica para a adição de novos modelos, mas pode ser feita incluindo esses arquivos em uma nova pasta com o nome do modelo.
A pasta ‘static’ contém os arquivos CSS, Javascript e imagens do formato gif, todos dentro de suas respectivas pastas, que são utilizados nas páginas HTML do servidor, que ficam dentro da pasta templates, seguindo o padrão de hierarquia de arquivos do Flask.
} }); }
// Disparo do evento upload @SimpleEvent
public void Upload(String status, String error) {
EventDispatcher.dispatchEvent(this, "Upload", status, error); }
Quadro 17: Hierarquia de arquivos
Fonte: elaborado pelo autor.
A pasta ‘turma’, contém uma cópia do arquivo pkl do modelo, o arquivo ‘descricao.txt’ contendo a descrição da turma criada durante o cadastro da turma e as imagens enviadas pela extensão, dentro da subpasta da classe a que foi submetida.
Para finalizar a parte de arquivos do servidor, sua implementação foi dividida em quatro arquivos:
● application.py que contém as configurações da aplicação Flask e sua execução inicia o servidor Web,
● server.py que contém as rotas do servidor,
● model_service.py que contém os métodos de modelos e, ● turma_service.py que contém os métodos de turmas.
Dentro do server.py, possui as principais chamadas de métodos do servidor, como o upload do arquivo (Quadro 18), onde é obtido o formato do arquivo e o código da turma do header da requisição, verifica-se se o código e o formato da extensão são válidos, caso não haja erro, é chamado o método upload do turma_server.py, onde é salvo o array de bytes no formato enviado dentro da pasta da turma. A classificação é feita de forma similar, executando o método predict no lugar do upload, onde é carregado o modelo da turma, chamada a classificação deste modelo para o array de bytes da imagem e retorna a classificação recebida do modelo.
Quadro 18: Método de upload ../servidor /models /<nome_do_modelo> classes.txt <nome_do_modelo>.pkl /static /css /gif /js /templates /turmas /<codigo_da_turma> /upload/train /<classe> descricao.txt <nome_do_modelo>.pkl application.py model_service.py server.py turma_service.py
Fonte: elaborado pelo autor.
Outro método importante é o de retreinar o modelo, onde após carregar o modelo, é criado um novo dataset (Quadro 19) a partir da pasta de imagens da turma, utilizando o nome das pastas para categorizar as imagens e 20% das imagens são utilizadas para validação do treino. Em seguida, é definido esse dataset para o modelo e é efetuado o treinamento usando o comando fit(n) do Fast.ai realizando n ciclos de treino, sendo n, o valor do epoch enviado pelo usuário.
Quadro 19: Criação do novo dataset
Fonte: elaborado pelo autor.
Durante a implementação, a utilização de diversas tecnologias que nunca havia utilizado, como Fast.ai, Flask, Bootstrap, tornaram mais lento o progresso da implementação, isso foi amenizado devido a grande quantidade de tutoriais disponíveis na internet das tecnologias utilizadas.
Como a ferramenta utiliza o conceito de Transfer Learning (TORREY & SHAVLIK, 2010), ou seja, modelos pré-treinados são utilizados para serem re-treinados com novas imagens fornecidas pelo usuário, é necessário re-treinar o modelo após a inclusão de novas imagens. Isso gerou outro problema em relação ao tempo necessário para treinar o modelo, pois a proposta inicial era utilizar as imagens do dataset do modelo e acrescentar mais imagens para o re-treino, mas isso gerou um grande tempo execução, já que realizar um ciclo do fit com apenas as imagens do modelo demorava em torno de 25 minutos no computador do autor (Intel® Core™ i7-3770 CPU @ 3.40GHz × 4, 16GB de memória ram), tornando inviável para ser usado em sala de aula. Sendo assim, a proposta foi substituída pelo apresentado acima, onde o treinamento acrescenta mais camadas no modelo utilizando as imagens enviadas. Usando 60 imagens o tempo de execução diminuiu para próximo de 1 minuto por ciclo. O problema dessa abordagem, é que devido à baixa quantidade de imagens do cenário proposto de uso, provavelmente irá resultar
if request.method == 'POST':
extension = request.headers .get('extension') tag = request.headers .get('tagImagem')
error = verify( token, extension) if error == None :
ts.upload(token, tag , request.get_data(), extension) return jsonify({"status":"ok"})
else :
return jsonify(error)
return jsonify({"error": "Not POST method"})
data : ImageDataBunch = (ImageList .from_folder(path) .split_by_rand_pct().label_from_folder() .transform(tfms)
em uma taxa de acurácia menor do que o modelo inicial, dependendo da qualidade das imagens e da categorização fornecidas pelos usuários.
5.3.2.1 Serviços implementados no servdor
Nesta seção são apresentados os serviços implementados no servidor para manutenção de turmas, envio de imagens e para classificação de imagens.
O Quadro 20 apresenta os endpoints relacionados à extensão, com uma breve descrição, parâmetros, possíveis JSONs de saída e um exemplo da requisição em Curl.
Quadro 20: Tabela de endpoints para a extensão
Fonte: elaborado pelo autor.
O Quadro 21 apresenta todos os outros endpoints disponíveis, utilizados no funcionamento do sistema web.
Endpoint Descrição Parâmetros JSONs de saída
Exemplo da requisição em Curl POST
/upload/<token>
Realiza o upload de uma imagem com uma classe (tagImagem) para uma turma
URI: token (código da turma) header: extension (formato do arquivo)
header: tagImagem (Classe da imagem)
data-binary: <caminho do arquivo> (Imagem em binário)
{"status": "ok"} {"error":<descrição erro>}
curl --location --request POST 'http://192.168.0.10:5000/upload/a434fd' \ --header 'extension: jpg' \
--header 'Content-Type: text/plain' \ --data-binary '<path>/plastic14.jpg' POST /predict/<token> Obtém a classificação da imagem pelo modelo da turma.
URI: token (código da turma) header: extension (formato do arquivo)
data-binary: <caminho do arquivo> (Imagem em binário)
{"result": <classe>} {"error":<descrição erro>}
curl --location --request POST 'http://0.0.0.0:5000/predict/087aae \ --header 'extension: jpg' \
--header 'Content-Type: text/plain' \ --data-binary '<path>/ferro.jpg' GET /classificacoes/<t oken> Obtém as classes do modelo de turma
URI: token (código da turma) {"classes": <String das classes>}
{"error": "invalid token."}
Quadro 21: Tabela de endpoints para a servidor
Fonte: elaborado pelo autor.
5.4. Operação do servidor
Nesta seção é descrito o funcionamento da aplicação, apresentando as funcionalidades implementadas no Servidor conforme seus casos de uso.
Ao iniciar a aplicação, a tela de login é apresentada (Figura 11), o usuário pode então informar o seu login e senha para poder se autenticar no sistema (UC02.01). Ao tentar acessar qualquer outra rota sem estar autenticado, o usuário é redirecionado a tela de login.
Figura 11: Tela de login
Fonte: elaborado pelo autor.
Endpoint Descrição
/ redireciona o usuário para /turmas ou página de login /login usado para realizar o login do usuário
/logout usado para realizar o logout do usuário /cadastro_turma usado para cadastrar uma turma
/editar_turma/<token> usado para salvar a edição de uma turma
/turma/<token>/<tag>/<name> retorna a imagem <name> de classe <tag> e turma <token> /delete/<token> usado para deletar uma imagem de uma turma
/turma/<token> página da turma
/move_picture_to_tag usado para mover imagens de uma turma entre classes /turmas página da listagem de turmas
/cadastrar página de cadastro de turma
/editar página da edição de turma
/excluir usado para deletar uma turma
/clean usado para deletar todas as imagens de uma turma /train/<token> usado para treinar o modelo de uma turma
Após autenticação, o usuário é redirecionado a tela de turmas (Figura 12), a qual possui uma lista de turmas cadastradas (UC02.02A), um botão para cadastrar novas turmas e para cada turma apresenta um botão para visualizar, editar e excluir (UC02.03A).
Figura 12: Tela de listagem de turmas
Fonte: elaborado pelo autor.
Ao acessar o botão cadastrar, o usuário é redirecionado para tela de cadastro de turma (Figura 13). Esta tela permite o cadastro de uma nova turma, ela apresenta um campo texto descrição e um campo para selecionar o modelo, onde seus valores são obtidos automaticamente a partir dos modelos pré-cadastrados disponíveis na pasta ‘model’. Ao efetuar o cadastro, o código da turma é gerado e o usuário é redirecionado a tela de turmas.
FIgura 13: Tela de cadastro de turma
Fonte: elaborado pelo autor.
A tela de edição de turma (Figura 14), é similar a de cadastro, apenas trocando o título, onde é apresentado “Editar” no lugar de “Cadastrar” e o código da turma e o botão “Cadastrar” virá “Salvar”.
Figura 14: Tela de edição de turma
Fonte: elaborado pelo autor.
A tela de visualização de turma (Figura 15), apresenta ao usuário as configurações de treino (Epoch), a opção de treinar, a opção de excluir todas as imagens, e as imagens separadas por classe. Cada imagem possui as opções de exclusão e de mover para outra classe, caso uma imagem esteja em uma classe errada. As imagens apresentadas na tela de visualização, são as imagens obtidas das requisições de upload para cada turma. Ao clicar no botão “Treinar”, o sistema mostra ao usuário “aguarde o treinando” enquanto a função de treino ocorre, utilizando as imagens categorizadas nas classes apresentadas nesta tela para o re-treinar o modelo de turma.
FIgura 15: Tela de visualização de turma
Após o (re)treinamento do modelo, a tela de visualização de turma mostra a matriz de confusão gerada pelo treino realizado, como mostra a Figura 16. Como uma das funcionalidades a serem desenvolvidas, a representação visual matriz de confusão ainda está incompleta, não mostrando as classes nos eixos X e Y e não apresentando a legenda das cores.
Em qualquer página da aplicação, o menu superior é apresentado possibilitando ao usuário retornar a página de listagem das turmas ou deslogar.
Figura 16: Tela de visualização de turma após treino
Fonte: elaborado pelo autor.
5.5. Discussão
Durante a implementação, alguns requisitos funcionais já não estavam coerentes devido ao rumo que o projeto tomou. Em reuniões com os stakeholders, foi constatado que era mais relevante para o usuário cadastrar as turmas de alunos que iriam utilizar o sistema do que manter o cadastro dos modelos de ML que estava inicialmente previsto. Então, a partir disso, algumas mudanças nos requisitos iniciais foram realizadas conforme o Quadro 22. Um ponto importante de ser levantado, para não precisar alterar todos os requisitos, é que ao citar ‘modelo’
refere-se ao modelo da turma, sendo a única exceção o RF02.07 (Inserir novos modelos Manter modelos pré-treinados).
Assim, os requisitos RF01.03, RF01.04 e RF02.02 foram removidos por não fazerem mais sentido quando analisado o objetivo do usuário, que deseja enviar as requisições para o modelo de uma turma específica de alunos, logo ele deve ter o código da turma para efetuar as requisições, não sendo necessário realizar uma requisição para tal. O RF01.01 foi simplificado e o RF02.07 não foi desenvolvido, por causa do curto período de desenvolvimento. E para contemplar as outras alterações, foram criados outros requisitos.
Considerando essas alterações nos requisitos, todos os requisitos foram alcançados, com exceção do RF02.07 e RNF1.2 que não foi avaliado (complementado no capítulo 6).
Quadro 22: Alterações requisitos
ID Requisito Descrição Mudança
RF 01. 01 Enviar requisição de classificação
Enviar ao servidor a requisição de classificação de uma entrada para um modelo enviando uma imagem ou texto.
Alterado para apenas imagens.
RF 01. 03 Enviar requisição de lista de modelos.
Enviar ao servidor a requisição de lista de modelos treinados do servidor e responder ao cliente o que foi solicitado. Requisito removido. RF 01. 04 Receber requisição de lista de modelos.
Receber resposta do servidor da requisição de lista de modelos enviada.
Requisito removido. RF 02. 02 Receber lista de modelos.
Receber a requisição de lista de modelos treinados do servidor e responder ao cliente o que foi solicitado. Requisito removido. RF 01. 08 Enviar requisição de upload
Enviar ao servidor a requisição de
upload de imagem para uma turma. Novo requisito
RF 02. 08
Inserir novas turmas
Manter turmas. Novo requisito
RF 02. 09
Treinar turmas
Possibilitar o re-treinamento do modelo da turma. Novo requisito RF 02. 10 Apresentar resultado do treinamento
Apresentar feedback ao usuário após término do treinamento
Fonte: elaborado pelo autor.
Com os novos requisitos funcionais fez-se necessário refazer o diagrama de casos de uso, como mostrado na Figura 17.
Figura 17: Novo diagrama de casos de uso
Fonte: elaborado pelo autor.
Juntamente com a descrição dos casos de uso atualizados. Caso de Uso 1 – UC02.01 - Login
Caso de Uso 2 – UC02.02A - Exibir Turmas Atores:
● Usuário Fluxo base:
1. Usuário acessa o site do servidor. 2. Usuário digita suas credenciais.
3. O sistema autentica o usuário e é redirecionado à página principal; Fluxo de Exceção:
FE01 – Sistema não encontra credenciais ou credenciais inválidas. Sistema informa com a mensagem de erro: “Usuário e senha não identificados pelo sistema”.
Atores:
Caso de Uso 3 – UC02.03A - Manter turmas
Caso de Uso 5 – UC02.05 - Receber requisição de classificação Pré-condição:
● UC02.01 Fluxo base :
1. Sistema exibe lista de turmas disponíveis, exibindo nome, descrição, labels e as opções de excluir e editar cada modelo.
Fluxo de Exceção:
FE01 – Nenhum modelo previamente cadastrado. Sistema informa uma mensagem: “Nenhuma turma cadastrada.”.
Atores:
● Usuário Pré-condição:
● UC02.01
Fluxo base - Cadastrar :
1. Usuário clica no botão cadastrar.
2. Sistema redireciona usuário para página de cadastro.
3. Usuário informa nome. descrição e seleciona um modelo disponível. 4. Usuário clica em salvar.
5. Sistema redireciona usuário para página principal. Fluxo base - Excluir:
1. Usuário clica no botão excluir. 2. Usuário confirma a exclusão. 3. Sistema atualiza a tela principal. Fluxo base - Editar:
1. Usuário clica no botão editar.
2. Sistema redireciona usuário para página de edição. 3. Usuário altera as informações.
4. Usuário clica em salvar / cancelar.
5. Sistema redireciona usuário para página principal.
Atores:
● App Mobile Fluxo base:
Caso de Uso 5 – UC02.05 - Treinar o Modelo
Caso de Uso 6 – UC02.06 - Receber requisição de upload
2. Sistema executa classificação de acordo com o modelo solicitado.
3. Sistema envia ao App Mobile a requisição com a resposta da classificação. Fluxo de Exceção:
FE01 – Tipo de arquivo incorreto: Sistema envia ao App Mobile, uma resposta de erro.
FE02 – Modelo inexistente: Sistema envia ao App Mobile, uma resposta de erro.
FE03 – Erro na classificação: Sistema envia ao App Mobile, uma resposta de erro. Atores: ● Usuário Pré-condição: ● UC02.01 Fluxo base:
1. Usuário clica no botão treinar.
2. Sistema re-treina o modelo da turma, usando as imagens da turma. Enquanto o processo ocorre é apresentado: Aguarde o treinamento. 3. Sistema salva o modelo re-treinado.
4. Sistema apresenta ao usuário o feedback do treinamento.
Atores:
● App Mobile Fluxo base:
1. App Mobile envia requisição de upload ao servidor.
2. Sistema executa o upload para a turma solicitada para a classe solicitada. 3. Sistema envia ao App Mobile a requisição com a resposta da requisição. Fluxo de Exceção:
FE01 – Sem classe ou classe inválida: Sistema faz o upload da imagem para a primeira classe do modelo.
FE02 – Tipo de arquivo incorreto: Sistema envia ao App Mobile, uma resposta de erro.
FE03 – Turma inexistente: Sistema envia ao App Mobile, uma resposta de erro.
Caso de Uso 7 – UC02.07 - Receber requisição de classificações
Caso de Uso 8 – UC02.08 - Logout
Atualmente a construção do dataset para o treino é feito de maneira específica (Quadro 19), sendo assim modelos que na construção do seu dataset não se encaixarem nessa maneira, provavelmente vão dar erro ao serem retreinados. Uma solução seria salvar o modo como esse dataset é construído para cada modelo, por exemplo, salvando o nome do método que constrói o dataset e os valores de parâmetros. Assim, teríamos uma maneira genérica para construção de diferentes tipos de datasets com suas devidas configurações.
Outro ponto relevante é que a arquitetura do servidor é flexível, sendo assim é possível implementar outros tipos de aprendizado, ou realizar regressão no lugar de classificação, mas isso traz complexidade à generalização do sistema, tanto backend quanto frontend. A integração com outras APIs, como o Tensorflow, são pontos a serem analisados individualmente.
Atores:
● App Mobile Fluxo base:
1. App Mobile envia requisição de classificações ao servidor.
2. Sistema envia ao App Mobile a requisição com a resposta contendo as classes do modelo de turma.
Fluxo de Exceção:
FE01 – Turma inexistente: Sistema envia ao App Mobile, uma resposta de erro. Atores: ● Usuário Pré-condição: ● UC02.01 Fluxo base:
1. Usuário clica em logout no menu superior.
2. Sistema encerra a sessão do usuário e o redireciona a tela de login. Fluxo de Exceção:
FE01 – Usuário sem sessão: Sistema redireciona usuário para página de login.
6. Avaliação
Neste capítulo é apresentado a avaliação da solução desenvolvida com o objetivo de verificar a adequação funcional e operabilidade da ferramenta e suas funcionalidades. Inicialmente tinha-se o objetivo de realizar uma avaliação prática em sala de aula durante algum projeto da Computação na Escola, onde os alunos seguiriam um tutorial para construir uma aplicação mobile utilizando recursos de ML, enviando diversas fotos ou imagens de diferentes tipos de lixo reciclável, separando essas imagens nas classes , realizando o treino. No entanto, devido à pandemia da COVID-19, não foi possível efetuar a avaliação com os usuários, sendo assim, a avaliação foi reduzida para testes de funcionamento de sistema com base nos casos de uso e fluxos de exceção. Pelo mesmo motivo, o RNF1.2, que fala sobre usabilidade, também não pode ser avaliado.