universidade tecnolÓgica federal do paranÁ...

UNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁ

UTFPR CAMPUS CORNÉLIO PROCÓPIO

DIRETORIA DE GRADUAÇÃO E EDUCAÇÃO PROFISSIONAL

CURSO SUPERIOR DE TECNOLOGIA EM ANÁLISE EDESENVOLVIMENTO DE SISTEMAS

DIOGO HIDEKI MATSUMOTO

VÍDERE 2: UMA PLATAFORMA DE JOGOS PARA ESTIMULAÇÃOVISUAL

CORNÉLIO PROCÓPIO

OUTUBRO - 2012


VÍDERE 2: UMA PLATAFORMA DE JOGOSPARA ESTIMULAÇÃO VISUAL

Trabalho de Diplomação apresentado como re-quisito parcial a obtenção do grau de Tecnó-logo em Análise e Desenvolvimento de Sis-temas pela Universidade Tecnológica Federaldo Paraná - Câmpus Cornélio Procópio

Orientador:

Fabrício Martins Lopes

CORNÉLIO PROCÓPIO

OUTUBRO - 2012

Agradecimentos

A meus pais Wanderley e Vera pela oportunidade na formação acadêmica que obtive.

A meus irmãos Hugo e Douglas pelas ideias e forças para concluir o trabalho.

Ao meu orientador Fabrício pela confiaça, sugestões e esforço depositado neste trabalho.

Aos professores da Universidade Tecnológica Federal do Paraná pelo ensino que obtivedurante o curso.

Aos membros da empresa Calibre Games pelo conhecimento compartilhado e iniciativadeste trabalho.

Aos demais amigos e colegas de curso pelo respeito e pela ajuda durante o curso.

Aos que não foram citados, porém contribuíram para a conclusão deste trabalho.

Resumo

A deficiência visual é caracterizada por uma alteração ou diminuição da eficiência visual.Esse resíduo visual pode ser estimulado de forma que as pessoas aprendam a usá-lo e recuperemparcialmente sua acuidade visual. Nesse contexto, esse trabalho apresenta uma plataforma con-tendo doze jogos destinados ao estímulo visual de pessoas com visão subnormal. Entre osestímulos disponibilizados aos usuários estão a visão para detalhes em cores, percepção de con-trastes, estímulos luminosos, interpretação de imagens e cenas, entre outros. Além dos jogos,é disponibilizado na plataforma a integração a um sistema de acompanhamento da evoluçãodos usuários, tal como escores e estatísticas que permitem identificar o comportamento indi-vidual ou coletivo dos usuários, quantidade de vezes que o usuário jogou o mesmo jogo, seusacertos e erros, entre outros, de forma gráfica e intuitiva. O desenvolvimento da plataforma foirealizado com a tecnologia Java, de forma que os jogos possam ser executados independentesdo sistema operacional utilizado pelo usuário. Os resultados ilustrativos dos jogos aplicados aum usuário demonstram o potencial dessa plataforma de jogos, os quais apontam a adequaçãodessa proposta aos objetivos propostos. O Vídere é livremente disponibilizado a partir da urlhttp://code.google.com/p/viderejogos/.

Abstract

The visual impairment is characterized by a change or reduction of visual efficiency. Thisresidual vision can be stimulated so that people learn to use it and partially recover their eye-sight. This paper presents a platform containing twelve games for visual stimulus of peoplewith low vision. Among the visual stimulus available to users, there are games to detect colordetails, contrast perception, light stimuli, interpretation of images and scenes, among others.In addition to games, it is also available on the platform a system for monitoring the evolu-tion of its users, such as scores and statistics that identify their individual or collective be-havior, number of times played by user and the respective game, their successes and errors.This monitoring is presented by using graphics in an intuitive way. The software was deve-loped with the Java technology, so it can be run independent of the operational system. Theresults of the games applied to a user demonstrate the potential of this game platform, whichindicates its suitability to the purposes of this work. The Videre is freely available from thehttp://code.google.com/p/viderejogos/.

Lista de Figuras

3.1 Detalhe do Jogo Só Soprando. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 19

3.2 Interface do mini-jogo Matriz de Formas Geométricas. . . . . . . . . . . . . . . . . . . . . . . . p. 22

3.3 Tela de Parabenização ao concluir todas as fases. . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 23

5.1 Diagrama de Classes - Jogos Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 31

5.2 Diagrama de Classes - Jogos 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 32




5.6 A Classe FaseSombra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 37

5.7 Área de clique das imagens, antes e atual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 39

5.8 Menu Inicial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 40

5.9 Diagrama de Casos de Uso - Gerenciar Usuário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 42

5.10 Diagrama de Casos de Uso - Gerar Gráficos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 45

5.11 Diagrama de Atividades - Criar Usuário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 48

5.12 Diagrama de Atividades - Exibir Gráficos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 49

5.13 Diagrama de Atividades - Gerenciamento de Jogadas . . . . . . . . . . . . . . . . . . . . . . . . p. 50

5.14 Diagrama de Sequência - Gerar Gráficos sem filtros adicionais . . . . . . . . . . . . . . . p. 51

5.15 Diagrama de Sequência - Gerar Gráficos com filtros adicionais . . . . . . . . . . . . . . . p. 51

5.16 Diagrama de Classes - Módulo Estatístico (simples). . . . . . . . . . . . . . . . . . . . . . . . . . p. 53

5.17 Diagrama de Classes - Módulo Estatístico (detalhado). . . . . . . . . . . . . . . . . . . . . . . . p. 53

5.18 Arquivo de Configuração de Builds do Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 54

5.19 Menu de Seleção de Gráficos a Gerar. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 55

5.20 Exemplo de Gráfico Gerado - Linha de Aprendizado . . . . . . . . . . . . . . . . . . . . . . . . p. 56

5.21 Tela de Seleção de Filtros Adicionais para Linha de Aprendizado . . . . . . . . . . . . p. 56

5.22 Tela de Seleção de Filtros Adicionais para Desempenho em Jogos . . . . . . . . . . . . p. 57

5.23 Exemplo de Gráfico Gerado - Desempenho em Jogos . . . . . . . . . . . . . . . . . . . . . . . . p. 58

5.24 Tela de Seleção de Filtros Adicionais para Uso de Jogo . . . . . . . . . . . . . . . . . . . . . . p. 59

5.25 Exemplo de Gráfico Gerado - Uso de Jogo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 59

5.26 Exemplo de Gráfico Gerado - Desempenho Coletivo . . . . . . . . . . . . . . . . . . . . . . . . . p. 60

5.27 Exemplo de Gráfico Gerado - Boxplot de Jogos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 61

5.28 Exemplo de Gráfico Gerado - Boxplot de Datas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 62

5.29 Exemplo de Gráfico Gerado - Boxplot de Jogadores . . . . . . . . . . . . . . . . . . . . . . . . . p. 63

5.30 Diagrama de Atividades - Execução de Jogo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 65

5.31 Diagrama de Classes - Novos Jogos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 66

5.32 Tela do Jogo Identifique as Formas! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 68

5.33 Tela do Jogo de Contraste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 70

5.34 Tela do Jogo de Movimento. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 72

6.1 Cronograma planejado sobre a execução do trabalho . . . . . . . . . . . . . . . . . . . . . . . . . p. 73

6.2 Cronograma executado do trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 73

6.3 Descrição dos ciclos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 74

Lista de Tabelas

3.1 Classificação da Perda de Visão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 18

5.1 Alteração dos nomes de imagens no mini-jogo Números . . . . . . . . . . . . . . . . . . . . . p. 37

5.2 Alteração dos nomes de imagens no mini-jogo Matriz de Formas Geométricas p. 38

5.3 Alteração dos nomes de imagens no mini-jogo Matriz de Figuras . . . . . . . . . . . . . p. 39

5.4 Alteração dos nomes de imagens no mini-jogo Ache as Figuras . . . . . . . . . . . . . . . p. 39

5.5 Requisitos Funcionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 41

5.6 Requisitos Não-Funcionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 41

5.7 Caso de Uso Criar Usuário. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 43

5.8 Caso de Uso Alterar Usuário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 43

5.9 Caso de Uso Listar Usuário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 44

5.10 Caso de Uso Escolher Usuário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 44

5.11 Caso de Uso Buscar Usuários . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 46

5.12 Caso de Uso Buscar Jogadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 46

5.13 Caso de Uso Gerar Gráfico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 47

5.14 Caso de Uso Exibir Gráfico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 47

5.15 Atributos da Classe GameData . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 52

5.16 Gráfico de Linha de Aprendizado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 55

5.17 Gráfico de Desempenho em Jogos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 57

5.18 Gráfico de Uso de Jogo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 58

5.19 Gráfico de Desempenhos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 60

5.20 Gráfico de Boxplot de Jogos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 61

5.21 Gráfico de Boxplot de Datas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 62

5.22 Gráfico de Boxplot de Jogadores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 63

5.23 Requisitos Funcionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 64

5.24 Requisitos Não-Funcionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 64

5.25 Tabela de Pontuação do Jogo de Formas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 67

5.26 Formas Geométricas do Jogo de Formas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 67

5.27 Tabela de Pontuação do Jogo de Contraste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 69

5.28 Tabela de Pontuação do Jogo de Movimento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 71

5.29 Tragetórias do Jogo de Movimento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 71

Sumário

1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 13

1.1 Apresentação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 13

1.2 Organização do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 13

2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 15

2.1 Reorganização da estrutura do sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 15

2.2 Acompanhamento da evolução do usuário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 16

2.3 Implementação de novos jogos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 16

3 Revisão Bibliográfica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 17

3.1 Deficiência Visual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 17

3.2 Trabalhos Relacionados. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 18

3.2.1 EACH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 18

3.2.2 Só Soprando . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 18

3.2.3 LookTel Recognizer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 19

3.2.4 DOSVOX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 19

3.2.5 JogaVOX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 20

3.2.6 CityVOX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 20

3.2.7 AudioGames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 20

3.2.8 Smart Audio City . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 20

3.2.9 Boxplot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 21

3.3 Jogo Vídere . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 21

3.4 Tecnologias Utilizadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 23

3.4.1 API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 23

3.4.1.1 JSE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 23

3.4.1.2 JFreeChart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 24

3.4.2 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 24

3.4.2.1 Sistema Operacional Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 24

3.4.2.2 Netbeans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 25

3.4.2.3 Tortoise Subversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 25

3.4.2.4 Kile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 25

3.4.2.5 Astah UML e Argo UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 25

4 Modelo Espiral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 26

4.1 Estudo das tecnologias usadas no projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 26

4.2 Desenvolvimento de novos módulos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 27

4.2.1 Concepção do Jogo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 27

4.2.2 Análise de Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 27

4.2.3 Desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 27

4.2.4 Testes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 28

4.3 Redação do Trabalho de Diplomação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 28

5 Desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 29

5.1 Reestruturação do Código. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 29

5.1.1 Fragmentação de Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 29

5.1.1.1 Lógica de Jogo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 29

5.1.1.2 Recursos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 29

5.1.1.3 Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 30

5.1.1.4 Fases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 30

5.1.2 Diagrama de Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 30

5.1.3 Mudanças Gerais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 36

5.1.3.1 Fluxo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 36

5.1.3.2 Fases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 36

5.1.4 Mudanças Específicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 36

5.1.4.1 Sombras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 36

5.1.4.2 Números . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 37

5.1.4.3 Matriz de Formas Geométricas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 38

5.1.4.4 Matriz de Figuras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 38

5.1.4.5 Ache as Figuras! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 39

5.2 Módulo Estatístico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 40

5.2.1 Definição de Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 41

5.2.1.1 Requisitos Funcionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 41

5.2.1.2 Requisitos Não-Funcionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 41

5.2.2 Casos de Uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 41

5.2.3 Diagrama de Atividades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 47

5.2.4 Diagrama de Sequência . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 51


5.2.6 Inclusão do JFreeChart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 54

5.2.7 Gráficos Desenvolvidos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 54

5.2.7.1 Linha de Aprendizado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 54

5.2.7.2 Desempenho em Jogos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 57

5.2.7.3 Uso de Jogo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 58

5.2.7.4 Desempenhos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 60

5.2.7.5 Boxplots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 61

5.3 Novos Jogos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 64

5.3.1 Definição de Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 64

5.3.1.1 Requisitos Funcionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 64

5.3.1.2 Requisitos Não-Funcionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 64

5.3.2 Diagrama de Atividades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 65


5.3.4 Jogos desenvolvidos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 67

5.3.4.1 Identifique a Forma! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 67

5.3.4.2 Jogo de Contraste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 69

5.3.4.3 Jogo do Movimento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 71

6 Cronograma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 73

7 Recursos necessários . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 75

7.1 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 75

7.2 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 75

8 Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 76

8.1 Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 76

8.2 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 76

Referências Bibliográficas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 78

Apêndice A -- Proposta do Trabalho de Diplomação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 80

13

1 Introdução

O uso da tecnologia no dia a dia tornou-se uma atividade indispensável. Há vários recursosoferecidos aos usuários realizados com o apoio da informática utilizando-se um software paraatender as necessidades de uma pessoa.

Dentre as diversas áreas de aplicações, a área educacional foca o estímulo ao desenvolvi-mento de uma determinada habilidade humana, a qual é chamada de software educacional queoferece ao usuário, muitas vezes, recursos da multimídia para tornar o aprendizado mais intera-tivo e eficiente.

Com ênfase na área de desenvolvimento de software educacional é proposta a continuaçãode um projeto com as mesmas características de uma aplicação educacional focada na área deestímulo à visão para portadores de deficiência visual.

1.1 Apresentação

Esta monografia apresenta o Trabalho de Diplomação do Curso Superior de Tecnologiaem Análise e Desenvolvimento de Sistemas da Universidade Tecnológica Federal do Paraná -Câmpus Cornélio Procópio.

Neste trabalho é descrita a aplicação de uma metodologia comumente utilizada em desen-volvimento de jogos, relatando todos os procedimentos utilizados durante o desenvolvimentodo aplicativo.

Trata-se de um jogo educacional focado no estímulo à visão de crianças e que também geraestatísticas de aprendizado e uso tanto individual quanto coletivo.

1.2 Organização do Trabalho

A organização do Trabalho de Diplomação apresentado está divido da seguinte forma:

No Capítulo 2 são apresentados os objetivos deste trabalho.

1.2 Organização do Trabalho 14

No Capítulo 3 são abordados as pesquisas efetuadas durante o trabalho.

No Capítulo 4 é apresentado o modelo de desenvolvimento utilizado.

No Capítulo 5 é descrito como foi o processo de desenvolvimento do trabalho.

No Capítulo 6 são apresentados os cronogramas de desenvolvimento.

No Capítulo 7 são descritos os recursos utilizados.

No Capítulo 8 são apresentadas as considerações finais deste trabalho.

15

2 Objetivos

Uma abordagem inicial para o estímulo visual de crianças com baixo índice de visão ouvisão subnormal, desenvolvido por Graziela Cristina do Vale Pascoal Rodrigues em seu Tra-balho de Diplomação do Curso de Tecnologia em Informática da UTFPR Câmpus CornélioProcópio foi considerado no desenvolvimento deste trabalho com objetivo de expandir o soft-ware.

Esse software possui nove diferentes mini-jogos que “abordam meios de estimulação visualtais como, visão para detalhes em cores, visão de detalhes em imagens, percepção de contrastes,estímulos luminosos, interpretação de imagens e cenas, visualização de contornos e melhoriada memória visual.” (RODRIGUES, 2005).

A nova versão do projeto foi dividida em três etapas:

1. Reorganização da estrutura do sistema;

2. Acompanhamento da evolução do usuário;

3. Implementação de novos mini-jogos.

2.1 Reorganização da estrutura do sistema

A reorganização da estrutura do sistema foi feita com o objetivo de garantir a estabilidadedo sistema. Muitos sistemas sofrem contínuas mudanças. Uma pequena mudança em uma partedo sistema pode durar mais do que se esperava ou até mudar o comportamento de outra parte.Para reduzir a frequência com que esses riscos ocorram, manter um código limpo e organizadoé uma opção para o desenvolvedor (MARTIN, 2008).

Com a reorganização do sistema, utilizando recursos do paradigma de orientação a objetos,novas funcionalidades foram adicionadas ao sistema sem afetar a rotina de um jogo, e a inclusãode novos mini-jogos foi feita de forma mais direta, sem ter que se preocupar como o sistemafunciona como um todo, apenas sabendo o básico que uma classe deve implementar.

Nesse módulo, parte do tempo foi dedicado a revisão de aspectos gerais do jogo, como

2.2 Acompanhamento da evolução do usuário 16

desempenho, que trata o tempo de carregamento e processamento da aplicação em memória, edocumentação do código.

2.2 Acompanhamento da evolução do usuário

Foi implementado um módulo para acompanhamento da evolução do usuário baseado emum histórico de dados de cada jogo que são coletados durante sua execução. Os dados sãocoletados de forma transparente ao usuário: a cada novo jogo que é praticado, informaçõessobre acertos, erros, pontuações e data são salvos automaticamente.

Está presente neste módulo oito diferentes gráficos divididos em duas partes: estatísticasindividuais e estatísticas coletivas. Em estatísticas individuais, são gerados gráficos relaciona-dos apenas a um usuário. Um dos resultados indicados por esses gráficos é a possibilidade deacompanhar, indivualmente, qual o desempenho e evolução na aprendizagem de cada jogo. Emestatísticas coletivas, são gerados gráficos relacionados a todos os usuários. É possível notar,nesses gráficos, qual o comportamento coletivo diante a algumas variantes como: data jogada,tipo de jogo, pontuações obtidas e frequência de jogo.

Para se fazer a coleta de dados de forma coletiva, foi necessário desenvolver um gerenciadorde jogadores para que se possa diferenciar mais de um perfil de jogador. Tal diferença é feitaatravés do nome do usuário.

2.3 Implementação de novos jogos

A implementação de novos jogos ao pacote atual oferece mais alternativas de jogos. Ofoco está em deficientes com um nível de visão um pouco menor do que o requerido nos jogosencontrados no pacote atual.

Esses novos jogos envolvem trabalhar: a área de reconhecimento de formas geométricasbaseado em um nivel de detalhamento de uma imagem redimensionada; o nível de percepçãode uma forma geométrica baseado em níveis de contraste entre o fundo e a imagem; o reconhe-cimento de sentido de movimento de um objeto baseado na velocidade em que o objeto seencontra.

17

3 Revisão Bibliográfica

3.1 Deficiência Visual

A deficiência visual é caracterizada por uma alteração ou diminuição da eficiência visual.As causas mais comuns para que essa alteração ocorra incluem a forma inata na qual a pessoajá nasce com a deficiência, podendo até perder a visão totalmente com o tempo e de formaadquirida, quando a mesma ocorre por sofrer acidentes que comprometam a visão (BRAGA;SEI, 1997).

A deficiência visual pode ser dividida em dois grupos: cegueira e visão subnormal. Apessoa considerada cega pode possuir apenas a percepção da luz ou não ter nenhuma visão. Amaior parte do conhecimento adquirido por essas pessoas ocorre por meio de outros sentidos,sendo que os mais utilizados são o tato e a audição, que acontecem, por exemplo, através dagrafia braille e leitores de telas. Por outro lado, uma pessoa com visão subnormal consegueutilizar a visão para o aprendizado de alguma atividade até o limite que apresenta seja atingido.

A perda de visão possui alguns graus de acordo com a escala optométrica de Snellen, quemensura a acuidade visual para longe. Para obter a escala de Snellen é necessário fazer a relaçãoentre a qualidade da visão subnormal a certa distância (em metros ou pés) comparado à quali-dade da visão normal. De acordo com essa escala, o primeiro grau é considerado visão normal,os graus 1 e 2 são considerados visão subnormal, enquanto os demais graus são consideradoscomo cegueira (OMS, 2003).

A Tabela 3.1 exibe a classificação da perda de visão de acordo com dados retirados de umapesquisa feita pela Organização Mundial de Saúde - OMS que apresenta o grau da perda devisão e a respectiva acuidade visual máxima para o grau.

Existem várias soluções propostas para ajudar o cotidiano de um deficiente visual. Paraa leitura, pode ser utilizando tanto o sistema de leitura através do tato, o Braille, ou atravésda audição, por meio de livros falados ou sintetizadores de voz. Na escrita, existem sistemasque escrevem em Braille e também impressoras Braille. Na locomoção, pessoas com cegueirapodem usar bengalas ou cães-guia.

Para algumas alterações visuais, como miopia, hipermetropia, astigmatismo, entre outras,

3.2 Trabalhos Relacionados 18

Tabela 3.1: Classificação da Perda de Visão

Grau de Perda de Visão Acuidade Máxima (Snellen)0 1,01 0,32 0,13 0,054 0,025 0

Fonte: adaptado de OMS.

pode ser feito o uso de lentes (óculos ou lentes de contato) ou cirurgias oculares.

3.2 Trabalhos Relacionados

Existe uma série de condições que podem limitar uma pessoa a utilizar um jogo eletrônicoda forma para a qual ele foi projetado. Tratam-se das deficiências, que podem ser visuais,auditivas, motoras e relacionadas à cognição ou ao aprendizado (FAVA, 2010).

Porém, de outro lado, existem várias formas de estimular a visão e vários projetos concluí-dos relacionados ao desenvolvimento de alguma deficiência humana ou diminuição da barreirade limites, utilizando a tecnologia como meio de interação com o usuário. A seguir são resumi-damente descritos alguns deles.

3.2.1 EACH

A Escola de Artes, Ciências e Humanidades (EACH) da Universidade de São Paulo (USP)realizou uma pesquisa para analisar o desempenho de pessoas com deficiência ao jogar jogoseletrônicos que exigem movimentação física do jogador.

Um dos jogos utilizados na pesquisa foi o de boliche, para o console Nintendo Wii, que re-cebe as orientações do jogador a partir de movimentos com o controle e pressionando um botãoao mesmo tempo. Em um grupo de doze pessoas, sendo cinco crianças com paralisia cerebrale sete jovens com síndrome de Down, observou-se “que após 20 tentativas os deficientes seadaptam bem à tarefa, com bom desempenho nos escores do jogo virtual” (FERREIRA, 2011).

3.2.2 Só Soprando

Só Soprando é um jogo cuja interação com usuário é feita apenas por meio de um micro-fone. Não há botões no jogo, portanto o uso de teclado e/ou mouse são desprezíveis, visto que


toda ação no jogo é feita apenas por um sopro. Esse jogo foi desenvolvido por um grupo com-posto de um designer, um programador e um artista gráfico. A ferramenta utilizada foi o AdobeFlash.

O jogo possui um mecanismo bem simples: enquanto o jogador estiver assoprando o mi-crofone, o balão irá subir, caso constrário, tende a descer. O objetivo é chegar até o final da fasesem que o balão encoste em algum obstáculo como montanhas, árvores, casas, aves e avião.

“O jogo é um símbolo de luta contra o próprio homem. Acredita-se que ao impulsionar obalão com o sopro, como o vento, o usuário transporta suas limitações para o jogo, mostrandoque está vivo e que é capaz de vencer frente às suas dificuldades” (FAVA, 2010).

Figura 3.1: Detalhe do Jogo Só Soprando.Fonte: (FAVA, 2010)

3.2.3 LookTel Recognizer

O LookTel Recognizer é um aplicativo que utiliza a câmera digital de um celular para re-conhecer objetos reais e descrevê-los na tela ou pronunciá-los em forma de áudio. O programapossui uma biblioteca pré-definida de objetos reais e descrição, porém, é possível adicionar no-vas entradas pelo próprio usuário ou por alguma pessoa de preferência. Além disso, atualmente,está em desenvolvimento uma versão que reconhece vários textos, usado por exemplo, para lerjornais, revistas, livros. (LOOKTEL, 2009).

LookTel é uma empresa americana que desenvolve aplicações que visam melhorar a quali-dade de vida de cegos ou pesoas com visão subnormal. Atualmente, o foco está no desenvolvi-mento para smartphones.

3.2.4 DOSVOX

DOSVOX é um sistema operacional desenvolvido especificamente para deficientes visuais,que utiliza a síntese de voz como principal meio de interação com o usuário. Nele vem in-


cluso: aplicativos de manipulação de textos, impressores e formatadores para braile, programasdidáticos para auxílio a deficientes visuais, programas para acesso à internet (BORGES, 2002).

3.2.5 JogaVOX

JogaVOX é uma ferramenta feita para professores poderem criar novos jogos para defi-cientes visuais com estrutura de vérices e caminhos a serem percorridos. Em cada vértice,o “usuário pode explorar seu conteúdo, obtendo informações, recolhendo ou deixando algunsobjetos.” (CUNHA, 2007). Ela é estruturada permitindo que o professor desenvolva jogos emambiente Windows e que sejam executáveis no DOSVOX. Um exemplo aplicado utilizando essaferramenta foi desenvolvido pelo próprio autor do trabalho: o exemplo permite que o usuárioviaje pelos Estados do Brasil adquirindo informações sobre os locais.

3.2.6 CityVOX

CityVOX é um jogo didático para deficientes visuais que auxilia na aprendizagem de mate-mática geométrica. Sobre o mecanismo: na tela principal de jogo há um tabuleiro com váriascasas para andar e o jogador precisa responder às perguntas para andar para a próxima casa.Caso acerte a pergunta, irá avançar uma ou mais casas, dependendo do grau de dificuldade daquestão. Caso erre, irá voltar uma casa. O objetivo é prender um suposto bandido que aterrorizaa cidade de CityVOX. Quando chegar ao final do tabuleiro receberá um som comemorativo,exibindo, também, um relatório de acertos e comentário dos erros em formato de texto (SILVA,2009).

3.2.7 AudioGames

AudioGames é um site que reune vários outros jogos acessíveis a não somente cegos, mastambém para pessoas com deficiência motora. Nesse site, apenas jogos que utilizam o áudiocomo único meio de informação ao usuário são hospedados. Esses jogos não possuem inter-face gráfica altamente produzida como a maioria dos jogos atuais. No máximo, elas possuem,quando têm, uma simples tela que mostram apenas textos (AUDIOGAMES, 2009).

3.2.8 Smart Audio City

Aplicativo desenvolvido para celulares que ajuda o usuário a se locomover dentro de cidades.Quando o deficiente visual aproximar-se de um local, ele poderá receber informações específi-cas do local por áudio. Essas informações são compartilhadas entre os usuários, possibilitando

3.3 Jogo Vídere 21

um crescimento contínuo de informações. Atualmente, há suporte apenas para celulares Win-dows Phone (SOARES, 2012).

3.2.9 Boxplot

Uma forma eficiente de exibir cinco importantes dados de um conjunto de valores: maiorvalor, menor valor, mediana, quartil superior e quartil inferior. O maior e menor valor doconjunto ficam, respectivamente, no topo e na base da representação gráfica. Os valores doquartis superior e inferior, que separam o conjunto em um quarto de valores maiores e inferioresa eles, formam as bordas de uma caixa. A mediana, que é o valor do conjunto que separa o grupoem quantidades iguais de numeros menores e maiores a ele, é a linha que se encontra no meioda caixa.

3.3 Jogo Vídere

O Vídere é um jogo que atua no estímulo à visão de crianças com visão subnormal entrequatro a oito anos de idade. Esse jogo é composto por nove diferentes mini-jogos que utilizamcores básicas, como azul, amarelo, verde, vermelho, branco e preto, para estimular, de formainterativa e atraente ao jogador sem sobrecarregar funções a um jogo, crianças que possuamalguma das seguintes patologias: albinismo, anirídia, atrofia óptica, catarata, coriorrentinitemacular, glaucoma, retinopatia da prematuridade, retinose pigmentar e sublação do cristalino.

A interação do usuário com o software é realizada basicamente pela entrada de cliques domouse. Todo mini-jogo possui uma interface de usuário parecida. No canto superior direitohá um texto que indica a quantidade de vidas que o jogador ainda possui. Quando essas vidaschegarem a zero, irá abrir um menu de fim de jogo mostrando a pontuação total. No canto su-perior esquerdo é mostrado a pontuação total atual. Toda jogada de acerto ou erro irá modificaressa pontuação, sendo que acertos incrementam positivamente e erros decrementam a pontu-ação. Na parte inferior estão localizados três botões: Ajuda, Tela Inicial e Sair. Ao clicar emAjuda, uma nova janela será aberta explicando as instruções e regras do mini-jogo atual. Aoclicar em Tela Inicial, irá fechar o mini-jogo atual voltar ao menu inicial. Ao clicar em Sair, oprocesso do jogo será encerrado. A Figura 3.2 mostra um exemplo de interface do mini-jogoMatriz de Formas Geométricas.

Todo mini-jogo possui uma certa quantidade de fases pré-definidas que será trocada quandoo jogador concluir a fase atual. Quando a última fase for concluída um novo menu de parabe-nização será aberta, mostrando a pontuação atual e com três opções: Jogar Novamente, quereiniciará o mini-jogo atual com a pontuação zerada e a quantidade de vidas inicial; Tela Ini-cial, que irá fechar o mini-jogo atual voltar ao menu inicial e, Sair, que irá encerrar o processo

3.3 Jogo Vídere 22

Figura 3.2: Interface do mini-jogo Matriz de Formas Geométricas.

do jogo. A figura 3.3 mostra a tela de parabenização que é mostrada ao concluir todas as fasesde um mini-jogo.

O trabalho Vídere foi publicado em dois principais eventos. Foi aceito no no Workshopde Jogos Digitais na Educação, evento integrante ao Simpósio Brasileiro de Informática naEducação - SBIE - do ano de 2005, que ocorreu no estado de Minas Gerais na cidade de Juizde Fora. E foi selecionado a ser apesentado no 1o Seminário Nacional de Educação, Tecnologiae Profissionalização para Pessoas com Necessidades Educacionais Especiais, promovido peloMinistério da Educação que ocorreu em Brasília.

Foi desenvolvido utilizando o modelo de ciclo de vida Espiral adaptado para o desenvolvi-mento de jogos e dividido em quatro fases: Concepção do Jogo, Análise do Projeto, Desenvolvi-mento e Teste. O programa foi inteiramente escrito utilizando a linguagem de programaçãoJava.

3.4 Tecnologias Utilizadas 23

Figura 3.3: Tela de Parabenização ao concluir todas as fases.

3.4 Tecnologias Utilizadas

3.4.1 API

Esse trabalho foi desenvolvido utilizando a linguagem de programação Java. Java é umalinguagem de programação orientada a objetos que é mantida pela Oracle, possuindo sintaxesemelhante a C++. Uma das grandes vantagens em se usar Java é pelo fato de não precisarrecompilar o código para que seja executado em outra plataforma que possua a Java Virtual

Machine (JVM) instalada. Possui vários recursos compilados e prontos a serem usados peloprogramador, porém, muitas veses, ainda será necessário a importação de outros recursos adi-cionais, conhecidos também como Application Programming Interface (APIs) para agilizar oprocesso de desenvolvimento de um software (DEITEL, 2010) .

APIs utilizadas nesse trabalho:

3.4.1.1 JSE

Java Standard Edition é a API de desenvolvimento, distribuída pela Oracle gratuitamente,para criar e executar aplicações Java. Nela está incluso: a JVM, para que se possa ler e exe-


cutar bytecodes, que são códigos de máquina não-legíveis a humanos; compilador, para geraro bytecodes recebendo como entrada o código da linguagem java; e ferramentas utilitárias paraagilizar o desenvolvimento e ganhar em performance tanto em aplicações desktop quanto emaplicações servidoras (ORACLE, 2012).

3.4.1.2 JFreeChart

JFreeChart é uma biblioteca open source escrita em Java que facilita o desenvolvedor amontar e exibir gráficos durante a execução de um aplicativo. Foi fundada em fevereiro do anode 2000, por David Gilbert, e é mantida pela empresa Object Refinery Limited que vende do-cumentação e guias para programação sobre o JFreeChart. Atualmente, David Gilbert ainda éo gerenciador do projeto, com vários outros contribuidores da comunidade de desenvolvedores.Essa API possui diversas variações de formação de gráficos, dentre elas, as usadas nesse tra-balho: gráficos de retas, gráficos de barras, gráfico de pontos, gráficos de Boxplot (VIKLUND,2012).

Não é necessário conhecimento aprofundado em matemática estatística para utilizar a API,pois a montagem dos gráficos é baseado apenas na passagem de parâmetros essenciais à cons-trução de um gráfico. Por exemplo, para montar um gráfico de retas é necessário, basicamente,o valor de um ponto X no eixo das abcissas e seu respectivo valor no eixo das ordenadas. Odesenho formado entre a ligação dos pontos das coordenadas e a escala do gráfico são tarefasdelegadas ao JFreeChart.

3.4.2 Software

Dentro do escopo de desenvolvimento do projeto, foi necessário a utilização de algunsprogramas indispensáveis e outros que aumentam a produtividade no desenvolvimento geral doprojeto.

3.4.2.1 Sistema Operacional Linux

O Linux é sistema operacional livre e de código aberto. Possui recursos úteis tanto parausuários leigos quanto para usuários avançados. Dentre as diversas distribuições, foi utilizada oUbuntu versão 10.10. Alguns dos motivos para a escolha foi a familiaridade pessoal do uso dosistema operacional, pela rapidez na execução de processos e por fornecer utilidades do kernelLinux, como o Terminal, que agilizou algumas das tarefas desse trabalho.


3.4.2.2 Netbeans

Ambiente de desenvolvimento livre e de código aberto, para ajudar a escrever códigos emJava, oferecendo: compilação de códigos em Java, suporte a plugins, edição inteligente decódigo. Esse software foi escolhido pela familiaridade adquirida antes do início do projeto, ematividades acadêmicas.

3.4.2.3 Tortoise Subversion

Sistema de controle de versão de arquivos. Apesar de atualmente ter suporte apenas aosistema operacional Windows, é possível utilizá-lo, como cliente, pelo Netbeans que possui su-porte para operações básicas como update e commit. O servidor foi providenciado pelo serviçodo GoogleCode, disponível no endereço: http://code.google.com/p/viderejogos/.

3.4.2.4 Kile

Editor e compilador de textos em latex. Utilizado comumente na criação de artigos, mono-grafias, entre outros. Apesar de ser trabalhoso em aprender a utilizá-lo, a grande vantagemestá na facilidade de organização de documentos textuais extensos sem se preocupar com aformatação do documento final.

3.4.2.5 Astah UML e Argo UML

Editores de diagramas da Unified Modeling Language, com interface gráfica simples. Fa-cilita a organização geral de componentes do sistema. Possuem suporte a importação de códigofonte para gerar relação entre classes. Apesar de serem dois softwares com funcionalidadesconcorrentes, o primeiro foi o mais utilizado, sendo que o segundo foi utilizado apenas paraagilizar o processo de modelagem de diagrama de classes simples.

26

4 Modelo Espiral

Este Trabalho de Diplomação foi desenvolvido realizando as seguintes atividades:

1. Estudo das tecnologias usadas no projeto;

2. Desenvolvimento de novos módulos;

3. Redação do Trabalho de Diplomação.

4.1 Estudo das tecnologias usadas no projeto

Essa atividade foi realizada durante grande parte do Trabalho de Diplomação, em paralelocom a atividade de desenvolvimento. A aquisição de conhecimento sobre assuntos relacionadosao entendimento do projeto desenvolvido e também à implementação dos novos módulos foramrealizadas nessa atividade.

O aplicativo da ex-aluna foi desenvolvido utilizando a linguagem de programação orien-tada a objetos Java e compilado no ambiente de desenvolvimento Netbeans. Para alcançar osobjetivos do projeto (citados na seção 2), foi necessário a aquisição do código fonte, produzidopela ex-aluna, que foi providenciado por Fabrício Lopes. Em seguida o código foi estudadoa fim de entender as relações entre as classes e objetos para que fosse possível a remodelaçãodo sistema sem haver modificações no fluxo atual do jogo e sem alterar a saída de dados nasinterfaces gráficas.

Os princípios de orientação a objetos SOLID introduzidos por Robert Martin foram as refe-rências para a remodelação do sistema. Os cinco princípios, sendo eles: Single Responsability,Open/Closed, Liskov substitution, Interface segregation e Dependency inversion, visam umamelhor organização e maior limpeza de código, tornado-o fácil de ser entendido e ser mantidonão apenas pelo autor, mas também por outros colaboradores (MARTIN, 2008).

Com isso, o módulo de acompanhamento da evolução do usuário foi introduzido no sistemae implementado para cada mini-jogo. Esse módulo serve para que o aluno e o professor possamter estatísticas de resultados baseado em dados coletados durante cada mini-jogo, sendo eles:

4.2 Desenvolvimento de novos módulos 27

identificador do mini-jogo, pontuação de acertos, pontuação de erros, data jogada e estado finaldo mini-jogo. Os dados são gravados no computador local e é possível criar mais de um perfilde usuário, usando como atributo diferencial o nome do aluno. A exibição das estatísticas érealizado através de gráficos que são gerados e exibidos pelo próprio aplicativo.

4.2 Desenvolvimento de novos módulos

O desenvolvimento dos novos módulos foi realizado baseando-se no modelo de processode ciclo de vida espiral. A escolha do modelo espiral se deu principalmente por ser um modeloque,

atualmente, é o mais utilizado para o desenvolvimento de jogos, pois cada iteração é con-siderada como uma melhoria do jogo como um todo ou parcialmente. Diferente de outrossistemas, um jogo precisa ser, além de funcional e de fácil usagem para o usuário, atrativo semque haja um sinal de frustação por parte do jogador. Por isso, quanto mais iterações forem reali-zadas, acredita-se que a qualidade do produto irá aumentar gradativamente (SCHELL, 2008).

As fases seguidas no modelo foram: Concepção do Jogo, Análise de Projeto, Desenvolvi-mento e Testes.

4.2.1 Concepção do Jogo

A fase de concepção do jogo é o ponto inicial da criação de um jogo. É feito um brainstorm

(chuva de ideias) para decidir como será o jogo, incluindo planejamento de regras de jogo, dejogabilidade e de abstração interfaces gráficas.

4.2.2 Análise de Projeto

Nessa fase, a ideia abstrata da fase anterior é mais concretizada, gerando documentos paradescrever o problema e como este será resolvido. A pesquisa por jogos que se assemelhem àideia também pode ser feita, a fim de encontrar melhores soluções para o jogo.

4.2.3 Desenvolvimento

Com o documento gerado na fase anterior, é dado início ao desenvolvimento do jogo. Oprincipal foco nessa fase é a produção do jogo, incluindo a programação das interfaces e regras.O código produzido nessa fase não deve ser final, deve ser feito pensando que haverá possíveisreajustes na fase seguinte.

4.3 Redação do Trabalho de Diplomação 28

4.2.4 Testes

O módulo gerado na fase anterior é revisado para verificar se os principais pontos do docu-mento gerado na análise foram cumpridos. Não se limitando apenas à revisão, é realizado umteste a fim de encontrar possíveis defeitos nas rotinas do jogo para corrigi-los para a versãofinal; avaliar a qualidade, no que se refere à atmosfera do jogo (sensação de estar jogando eidentificar-se no ambiente), feedbacks (exercer uma ação e receber um sinal que identifique quea ação realmente foi executada) e jogabilidade (usuário exercer uma ação sem ser atrapalhadopelo próprio jogo).

Quando detectada uma nova ideia que possa melhorar o jogo ela é avaliada e um novo cicloé iniciado, começando da Concepção.

4.3 Redação do Trabalho de Diplomação

A redação do Trabalho de Diplomação foi realizada com maior ênfase no final do crono-grama planejado, estendendo-se até a um mês após a apresentação do trabalho. Foi consideradona escrita da redação as bibliografias estudadas durante o desenvolvimento do projeto e conver-sas com o orientador.

29

5 Desenvolvimento

5.1 Reestruturação do Código

A reestruturação do código foi realizado na primeira iteração do projeto. A seguir, na seção5.1.1 é explicado como foi feito a divisão das classes; na seção 5.1.2 é mostrada o diagrama declasses da nova organização geral das classes relacionadas aos mini-jogos e da mesma organiza-ção mais detalhada, dividida em três imagens; e nas próximas seções será descrito as mudançasespecíficas realizadas em cada mini-jogo.

5.1.1 Fragmentação de Classes

Todos os nove mini-jogos necessitaram serem reestruturados para que a implementaçãodos próximos módulos fosse feita de forma transparente e direta. A reestruturação do códigofoi realizada tendo em mente a melhor maneira de escrever um código simples e dividido emvários pequenos módulos que são responsáveis por uma função bastante específica no jogo.

As partes do código que definem a lógica de um mini-jogo, recursos a serem carregados,dados de interface de usuário, e configuração de fases foram separadas, dando origem à novasclasses que realizam os papéis citados.

5.1.1.1 Lógica de Jogo

A lógica de jogo básica foi transferida para a classe abstrata FaseControladorBase. Todosos mini-jogos atuais extendem essa nova classe que é responsável por controlar: inicializaçãodo mini-jogo; eventos de acerto ou erro do jogador; carregar dados de pontuação, vida, e faseatual; controlar dados de jogadas realizadas pelo jogador; e finalização do mini-jogo.

5.1.1.2 Recursos

Os recursos a serem carregados durante os mini-jogos foi delegado à classe Recursos queé um Singleton, ou seja, existe apenas uma única instância no programa todo. Os recursos de

5.1 Reestruturação do Código 30

multimídia, como imagens e sons, podem ser obtidos a partir dessa classe.

5.1.1.3 Interface

Os dados de interface de usuário permaneceu na mesma classe que representava um mini-jogo como um todo, removendo-se os códigos de lógica de jogo, recursos e configuração defases.

5.1.1.4 Fases

A configuração de fases foi transferida para a classe abstrata Fase. Ela apenas guardainformações variáveis de uma fase de um mini-jogo, bem como um identificador único, que éo nome. Apesar de não estar sempre ativa, é útil para separar as váriáveis de configurações decada fase.

Uma mesma classe de configuração de fases pôde ser usada em mais de um tipo diferentede mini-jogo, como acontece no caso dos mini-jogos Esconder Letras e Esconder Números,que utilizam a classe FaseEsconder para criar as fases (Figura 5.2), já que possuem a mesmaestrutura de configuração de fases. O mesmo acontece nos mini-jogos Matriz de Figuras eMatriz de Geométrica, que reutilizam a classe FaseMatriz (Figura 5.4).

5.1.2 Diagrama de Classes

Na Figura 5.1 é apresentada a relação geral das classes de mini-jogo. Na Figura 5.2 éapresentada, com detalhes, a relação de classes para os mini-jogos: Cores, Esconder Letras eEsconder Números. Em seguida, na Figura 5.3, os mini-jogos: Esconder Figuras e Luzes. Emseguida, na Figura 5.4, os mini-jogos: Números, Matriz de Figuras e Matriz de Geométrica. Emfim, na Figura 5.5, o mini-jogo Sombras.


Figura 5.1: Diagrama de Classes - Jogos Geral

.


Figura 5.2: Diagrama de Classes - Jogos 1


5.1.3 Mudanças Gerais

5.1.3.1 Fluxo

O fluxo de jogo foi modificado levemente. Nessa nova versão, ao entrar na tela de ajuda evoltar ao mini-jogo, os dados não serão reiniciados. Isso foi modificado para melhorar a expe-riência de usuário, pois dessa forma o jogador poderá ler a ajuda de um mini-jogo e continuarde onde tinha parado, sem perder dados de jogadas.

5.1.3.2 Fases

As fases não possuem um grau de dificuldade notável, pois são apenas variações de obje-tivos. Por isso, todas as fases são carregadas de forma aleatória não-repetida. Sempre que seiniciar um jogo, as fases estarão embaralhadas. Dessa forma o usuário não ficará preso ape-nas a uma sequência pré-definida de fases, o que poderia tornar cansativo caso jogue o mesmomini-jogo várias vezes.

5.1.4 Mudanças Específicas

Serão descritas, nas seguintes subseções, as mudanças realizadas específicamente em umdeterminado mini-jogo.

5.1.4.1 Sombras

Foi realizado uma padronização no formato das imagens utilizadas no jogo, de forma comque todas imagens relacionadas à sombras mantivessem o formato .gif e os desenhos a se procu-rar mantivessem o formato .jpg. Tal padronização foi feita para facilitar o acesso aos recursosde imagens sem que haja repetição excessiva de parâmetros para localizar uma imagem. Porexemplo, na fase com identificador “macaco”, a figura central da tela será carregada pelo ar-quivo “macaco.jpg”, e a opção correta será “macaco.gif”.

No código a seguir (Figura 5.6) é mostrado como foi reescrito a nova forma de acesso àsimagens, destacanto-se as linhas referentes a esse acesso.


Figura 5.6: A Classe FaseSombra

5.1.4.2 Números

Foi realizada a renomeação geral de imagens relacionadas ao mini-jogo. O principal motivofoi para facilitar a identificação das imagens e também para acesso mais fácil via programação.Os arquivos foram renomeados utilizando comandos específicos providenciados pelo própriosistema operacional Linux, sendo ele o comando rename que fornece uma maneira fácil derenomear arquivos em conjunto, utilizando expressão regular.

A Tabela 5.1 mostra o novo formato do nome das imagens, baseando-se como exemplotodas as figuras relacionadas à imagem de identificador 1.

Tabela 5.1: Alteração dos nomes de imagens no mini-jogo Números

Nome Original Nome Modificado1gd.jpg 1_desenho_grande.jpg1gf.jpg 1_figura_grande.jpg1d.jpg 1_desenho.jpg1f.jpg 1_figura.jpg1g.jpg 1_numero.jpg


5.1.4.3 Matriz de Formas Geométricas

Foi implementado uma nova funcionalidade que permite ao jogador refazer as jogadas,assim será possível corrigir uma opção caso estivesse errada. Para isso, basta clicar em algumadas imagens já selecionadas e, então, a última jogada realizada será desfeita. Não há limitespara refazer uma ação e também não há penalidades. Só é possível refazer a ação caso esteja naprimeira ou na segunda ou na terceira peça escolhida.

A nomenclatura das imagens estava despadronizadas dificultando o acesso direto via pro-gramação, portanto houve a necessidade de renomeá-las para que imagens com nomes do tipo“estrela vermelha” coincidissem o tipo de cor vermelho com outras imagens to tipo “hexágonovermelho”. Para tal finalidade, foi feito uma simples tradução para o inglês, visto que não possuidiferenciação de cores pelo gênero de um substantivo.

A Tabela 5.2 lista os novos sufixos e prefixos das imagens.

Tabela 5.2: Alteração dos nomes de imagens no mini-jogo Matriz de Formas Geométricas

Nome Original Nome Modificadoamarelo, amarela yellowazul blueverde greenvermelho, vermelha redelipse ellipsetriângulo trianglequadrado squareestrela starhexágono hexagon

5.1.4.4 Matriz de Figuras

Assim como no mini-jogo anterior, Matriz de Formas Geométricas, a funcionalidade derefazer uma ação foi implementada nesse mini-jogo também. As condições para refazer a açãosão as mesmas, ou seja, só é possível refazer caso tenha pelo menos uma imagem escolhida.Penalidades e limites de execução também não foram consideradas.

A nomenclatura das imagens estava com um identificador fora de ordem. Isso dificultariao acesso direto e transparente via programção. Além disso, a formatação das imagens estavamdistribuídas entre .gif e .jpg. Dentre os arquivos de imagens renomeados, pode-se citar umexemplo: imagens do grupo “sapo”. A Tabela 5.3 lista como eram os nomes e como foramrenomeados.


Tabela 5.3: Alteração dos nomes de imagens no mini-jogo Matriz de Figuras

Nome Original Nome Modificadosapo.gif sapo1.jpgsapo.jpg sapo2.jpgsapo1 sapo3.jpgsapo3 sapo4.jpg

5.1.4.5 Ache as Figuras!

Devido à área de clique de cada uma das imagens serem relativamente pequenas compara-das à imagem que aparece na tela, as chances de realizar um clique errado eram altas. Por essemotivo, foi aumentado a área de clique de todas as imagens em uma escala que pode-se consi-derar mais que o dobro da antiga área (Figura 5.7). A aresta da novo quadrado que representa aárea de clique foi aumentado de 50 pixels para 80 pixels.

Figura 5.7: Área de clique das imagens, antes e atual

Foi realizado, também, uma renomeação dos nomes para ficar de mais fácil leitura, sepa-rando objetos de fundos. Além disso, foi padronizado a formatação de imagens, sendo: gif paraobjetos e jpg para fundos. Na Tabela 5.4 é listado o nome antigo e o novo nome do “fundoboneca” e do “objeto boneca”, que são apenas um exemplo de vários que foram modificados.

Tabela 5.4: Alteração dos nomes de imagens no mini-jogo Ache as Figuras

Nome Original Nome Modificadofboneca.gif background_boneca.jpgboneca.gif object_boneca.gif

5.2 Módulo Estatístico 40

5.2 Módulo Estatístico

O módulo estatístico foi realizado na segunda iteração do projeto, conforme citado nosobjetivos (Seção 2). Esse módulo foi responsável por incluir, no projeto atual, um sistemade gerenciamento de usuários e exibição de gráficos estatísticos que foram elaborados parausuários adultos que possuam uma visão normal.

Com esse novo sistema, houve a necessidade de uma alteração no layout no menu inicial,bem como a adição de novas interfaces gráficas. A Figura 5.8 mostra o novo layout do menuinicial, destacando-se as mudanças: novo botão “trocar” para trocar o usuário atual e; novobotão “Sistema” que abre a tela contendo, além de gerenciamento de usuários, opções paraexibir gráficos.

Figura 5.8: Menu Inicial


5.2.1 Definição de Requisitos

5.2.1.1 Requisitos Funcionais

Tabela 5.5: Requisitos Funcionais

ID Requisito Funcional AtorRF1 Gerenciar jogadores JogadorRF2 Gravar dados de jogadas Módulo EstatísticoRF3 Gerar gráficos estatísticos Módulo EstatísticoRF4 Suporte a filtros estatísticos Módulo Estatístico

5.2.1.2 Requisitos Não-Funcionais

Tabela 5.6: Requisitos Não-Funcionais

ID Requisito Não Funcional CategoriaRNF1 O sistema deverá funcionar em multiplataforma. PortabilidadeRNF2 Serializar dados na máquina local, sem a necessidade

de camadas cliente-servidor.Usabilidade

RNF3 O aplicativo deve ser acessível a usuários meigos. UsabilidadeRNF4 O módulo estatístico deve se adaptar ao jogador atual. Usabilidade

5.2.2 Casos de Uso

Os casos de uso mostram como o sistema funciona, identificando atores e ações, com umalto nível de abstração. Foi identificado dois atores nesse módulo: Jogador (ou Usuário) eMódulo Estatístico.


Figura 5.9: Diagrama de Casos de Uso - Gerenciar Usuário


Tabela 5.7: Caso de Uso Criar Usuário

Caso de Uso Criar UsuárioFinalidade Adicionar um novo usuário jogador ao sistemaAtores JogadorPré-CondiçãoPós-CondiçãoSequência de Execução

1. O jogador entra no menu para a criação de umusuário.

2. O jogador informa o nome.

3. Caso o nome for válido, o novo usuário será adi-cionado.

4. Caso contrário, será solicitado um outro nome.

Tabela 5.8: Caso de Uso Alterar Usuário

Caso de Uso Alterar UsuárioFinalidade Trocar de perfil de usuárioAtores JogadorPré-Condição Existir pelo menos um jogador cadastradoPós-Condição Atualizar lista de usuáriosSequência de Execução

1. O jogador entra no menu para a alterar um usuário.

2. O jogador seleciona um dos usuários listados.

3. O jogador confirma a seleção.


Tabela 5.9: Caso de Uso Listar Usuário

Caso de Uso Listar UsuárioFinalidade Exibir todos os usuários existentes na máquina localAtores Módulo EstatísticoPré-CondiçãoPós-CondiçãoSequência de Execução

1. O sistema irá ler um arquivo contendo o nome de to-dos os jogadores.

2. O sistema verifica qual desses jogadores são válidos.

3. O sistema exibe a lista de usuários final.

Tabela 5.10: Caso de Uso Escolher Usuário

Caso de Uso Escolher UsuárioFinalidade Exibir todos os usuários existentes na máquina localAtores Jogador, Módulo EstatísticoPré-Condição Existir pelo menos um jogador cadastradoPós-Condição Confirmar a alteração de um usuárioSequência de Execução

1. O jogador escolhe um outro jogador dentro de umalista.

2. O sistema irá buscar o usuário solicitado.

3. Caso encontre o usuário, esse usuário será o atual.

4. Caso contrário, será solicitado ao jogador uma novaescolha.


Figura 5.10: Diagrama de Casos de Uso - Gerar Gráficos


Tabela 5.11: Caso de Uso Buscar Usuários

Caso de Uso Buscar UsuáriosFinalidade Buscar dados de um ou mais jogadores na máquina localAtores Módulo EstatísticoPré-Condição Existir pelo menos um jogador cadastradoPós-CondiçãoSequência de Execução

1. O sistema solicita o caminho dos arquivos a seremlidos no sistema de arquivos.

2. O sistema armazena esses dados de jogadores.

3. O sistema verifica quais desses jogadores são válidos.

4. Caso exista algum jogador inválido, o mesmo será re-movido.

Tabela 5.12: Caso de Uso Buscar Jogadas

Caso de Uso Buscar JogadasFinalidade Filtrar dados a serem utilizados antes de gerar um gráficoAtores Módulo EstatísticoPré-Condição Existir pelo menos um jogador cadastrado; Buscar dados de

Usuários; Especificar filtrosPós-Condição Gerar um gráficoSequência de Execução

1. O sistema busca todos os usuários.

2. O sistema filtra os dados de todas as jogadas de todosos usuários.

3. Repassa os dados ao gerador de gráficos.


Tabela 5.13: Caso de Uso Gerar Gráfico

Caso de Uso Gerar GráficoFinalidade Preparar dados gerados para a exibiçãoAtores Módulo EstatísticoPré-Condição Selecionar um tipo de gráfico a ser geradoPós-Condição Exibir um gráfico geradoSequência de Execução

1. O sistema coleta todas as jogadas relativas ao tipo degráfico.

2. O sistema gera e exibe o gráfico.

Tabela 5.14: Caso de Uso Exibir Gráfico

Caso de Uso Exibir GráficoFinalidade Exibir na tela do usuário um gráfico estatísticoAtores Jogador, Módulo EstatísticoPré-Condição Selecionar um tipo de gráfico a ser geradoPós-CondiçãoSequência de Execução

1. O Jogador seleciona qual tipo de gráfico quer gerar.

2. Caso o gráfico selecionado necessite de filtros adi-cionais, o Jogador deverá selecionar esses filtros.

3. O Sistema valida os parâmetros passados pelo Jo-gador.

4. Caso os parâmetros estejam corretos, o gráfico é ge-rado e, em seguida, exibido.

5. Caso contrário, não irá gerar gráfico.

5.2.3 Diagrama de Atividades

Os diagramas de atividades mostram como é o fluxo das atividades realizadas em algunscasos de uso com um nível de abstração menor, descrevendo as etapas com mais detalhes.


Figura 5.11: Diagrama de Atividades - Criar Usuário

.


Figura 5.12: Diagrama de Atividades - Exibir Gráficos


Figura 5.13: Diagrama de Atividades - Gerenciamento de Jogadas


5.2.4 Diagrama de Sequência

Os diagramas de sequências mostram as mensagens trocadas entre objetos do sistema,dando prioridade na ordem temporal em que as mensagens são realizadas. O nível de abstraçãonesses diagramas é inferior ao de Casos de Uso.

Figura 5.14: Diagrama de Sequência - Gerar Gráficos sem filtros adicionais

Figura 5.15: Diagrama de Sequência - Gerar Gráficos com filtros adicionais



O gerenciamento de usuários é realizado pela classe PlayerManager que implementa opadrão de Singleton. Sempre que for necessário carregar ou salvar dados de um jogador essasações devem ser delegadas à classe anterior.

Os jogadores são representados pela classe PlayerData, que possui vários dados de jogadasrealizadas, que são as instâncias da classe GameData. A classe GameData é responsável porarmazenar dados de todas as jogadas de um jogador. A Tabela 5.15 explica com detalhes qualo tipo de cada atributo e a função do atributo.

Tabela 5.15: Atributos da Classe GameData

Nome Tipo DescriçãoTipo Class<?> Identificador de mini-jogo. Esse valor é populado pelo

método getClass() de um FaseControladorBase.Score Inteiro Pontuação final atingida pelo jogador.Acertos Inteiro Quantidade de acertos conquistados pelo jogador. Começa

em zero e aumenta em um a cada vez que passar de fase.Erros Inteiro Quantidade de erros do jogador. Começa em zero e incre-

menta em um caso erre em uma fase.Estado Enumerador Estado final do jogo, podendo ser: Não Terminado, Com-

pletado (passou todas as fases) ou Fim de Jogo (perdeu to-das as vidas).

Data java.util.Date Data em que a instância foi criada.

Todos os dados serialializados estarão localizados em uma pasta chamada “videre_dados”que será criada no mesmo local em que for executado o programa. Por exemplo, caso o exe-cutável do Vídere esteja em “/home/Videre.jar” a pasta será criada em “/home/videre_dados”.

Dentro dessa pasta, será criado dois arquivos de textos sendo eles: “latest.txt” que guardao nome do último jogador, esse jogador será carregado automaticamente quando abrir o jogo,e; “players.txt” que guarda apenas os nomes de todos de jogadores, em cada linha do arquivoestará escrito o nome de um jogador.

Além dos arquivos em texto, os dados reais dos jogadores estarão em uma subpasta chamada“players” onde estará todos arquivos binários contendo os dados de todas as jogadas de um jo-gador. Cada jogador terá apenas um arquivo binário com nome coincidente ao próprio nome dojogador. Esses arquivos, por usa vez, não podem ser modificados fora do jogo.

A classe abstrata PlayerStatisticsBase implementa o básico necessário para gerar dadosde gráficos, ação que é delegada às demais classes filhas apresentadas no diagrama de classes(Figuras 5.16 e 5.17)


Figura 5.16: Diagrama de Classes - Módulo Estatístico (simples)

Figura 5.17: Diagrama de Classes - Módulo Estatístico (detalhado)


5.2.6 Inclusão do JFreeChart

A API JFreeChart utilizada está em formato .jar, que funciona como uma biblioteca pré-compilada dentro do escopo do trabalho. Por padrão, o compilador do Netbeans não inclui asbibliotecas adicionais na versão final, que é o executável em formato .jar.

Para incluí-las, foi necessário adicionar um trecho de código no arquivo “build-impl.xml”que é um arquivo de configuração de builds (gerar versão executável). No código da Figura5.18, basicamente está escrito que após o build normal (sem bibliotecas inclusas) seja geradoum outro executável de nome “Videre2.jar” incluindo as bibliotecas “jcommon-1.0.12.jar” e“jfreechart-1.0.9.jar”.

Figura 5.18: Arquivo de Configuração de Builds do Projeto

5.2.7 Gráficos Desenvolvidos

Os gráficos foram desenvolvidos com a ajuda da API JFreeChart que facilita na criação eexibição de gráficos. Para gerar um dos gráficos das subsessões a seguir, o usuário deverá clicarno menu “Sistema” e em seguida clicar em “Estatísticas” no novo menu. Em seguida, um novomenu irá aparecer, mostrando as opções correspondentes aos tipos de gráficos possíveis.

5.2.7.1 Linha de Aprendizado

A seguir, a Tabela 5.16 descreve o principal objetivo do gráfico de Linha de Aprendizado eo funcionamento do mesmo. A Figura 5.20 ilustra um exemplo de um gráfico gerado. A Figura5.21 ilustra a tela de seleção de filtro que é solicitado antes de gerar o gráfico.


Figura 5.19: Menu de Seleção de Gráficos a Gerar

Tabela 5.16: Gráfico de Linha de Aprendizado

Gráfico Linha de AprendizadoObjetivo Identificar como é a curva de aprendizagem em um determinado

jogo. O resultado esperado é que a pontuação tenda a aumentarquanto mais vezes um determinado mini-jogo for jogado.

Tipo de gráfico Gráfico de RetasValores do eixo dasabcissas (X)

Número de vezes jogado

Valores do eixo dasordenadas (Y)

Pontuação

Filtros adicionais Selecionar quais mini-jogos mostrar. Apenas os mini-jogos pratica-dos serão mostrados na lista de opções.


Figura 5.20: Exemplo de Gráfico Gerado - Linha de Aprendizado

Figura 5.21: Tela de Seleção de Filtros Adicionais para Linha de Aprendizado


5.2.7.2 Desempenho em Jogos

A seguir, a Tabela 5.17 descreve o principal objetivo do gráfico de Desempenho em Jogose o funcionamento do mesmo. A Figura 5.22 ilustra a tela de seleção de filtro que é solicitadoantes de gerar o gráfico. A Figura 5.23 ilustra um exemplo de um gráfico gerado.

Tabela 5.17: Gráfico de Desempenho em Jogos

Gráfico Desempenho em JogosObjetivo Identificar qual é o desempenho médio do jogador em um determi-

nado jogo, baseando-se nas pontuações obtidas pelo mesmo jogadore divindo-as em cinco intervalos.

Tipo de gráfico Gráfico de BarrasValores do eixo dasabcissas (X)

Intervalos de Pontuação


Frequência de Pontuação

Filtros adicionais Selecionar quais mini-jogos mostrar. Apenas os mini-jogos pratica-dos serão mostrados na lista de opções.

Figura 5.22: Tela de Seleção de Filtros Adicionais para Desempenho em Jogos


Figura 5.23: Exemplo de Gráfico Gerado - Desempenho em Jogos

5.2.7.3 Uso de Jogo

A seguir, a Tabela 5.18 descreve o principal objetivo do gráfico de Uso de Jogo e o fun-cionamento do mesmo. A Figura 5.24 ilustra a tela de seleção de filtro que é solicitado antes degerar o gráfico. A Figura 5.25 ilustra um exemplo de um gráfico gerado.

Tabela 5.18: Gráfico de Uso de Jogo

Gráfico Uso de JogoObjetivo Identificar qual é jogo mais jogado pelo jogador atual.Tipo de gráfico Gráfico de BarrasValores do eixo dasabcissas (X)

Nome dos Jogos


Frequência de Uso

Filtros adicionais Selecionar intervalo de data em dias. Por exemplo: exibir apenas osjogos mais jogados nos últimos 14 dias.


Figura 5.24: Tela de Seleção de Filtros Adicionais para Uso de Jogo

Figura 5.25: Exemplo de Gráfico Gerado - Uso de Jogo


5.2.7.4 Desempenhos

Foi desenvolvido dois tipos de gráficos: desempenho individual e desempenho coletivo. Noindividual, a pontuação registrada no eixo Y do gráfico é dado apenas pelo valor obtido pelojogador em uma jogada. Já no coletivo, é feito a média da pontuação de todos os jogadores emum jogo e em certa quantidade de jogadas. A seguir, a Tabela 5.19 descreve os detalhes dosgráficos de desempenho. Em seguida um exemplo de gráfico gerado é ilustrado na Figura 5.26.

Tabela 5.19: Gráfico de Desempenhos

Gráfico DesempenhosObjetivo Identificar qual é a tendência de aprendizagem nos jogos.Tipo de gráfico Gráfico de PontosValores do eixo dasabcissas (X)

Pontuação


Quantidade de jogadas por tipo de jogo

Filtros adicionais Nenhum.

Figura 5.26: Exemplo de Gráfico Gerado - Desempenho Coletivo


5.2.7.5 Boxplots

A seguir, é apresentado uma tabela e uma figura para cada tipo de boxplot, sendo Tabela5.20 e Figura 5.27 referentes ao tipo de jogos, Tabela 5.21 e Figura 5.28 referentes ao tipo dedata, e Tabela 5.22 e Figura 5.29 referentes ao tipo de jogadores,

Tabela 5.20: Gráfico de Boxplot de Jogos

Gráfico Boxplot de JogosObjetivo Identificar qual jogo está com um grau de dificuldade maior,

baseando-se na observação da pontuação de cada jogadorTipo de gráfico Gráfico de BoxplotValores do eixo dasabcissas (X)

Jogadores por Mini-Jogo


Pontuação


Figura 5.27: Exemplo de Gráfico Gerado - Boxplot de Jogos


Tabela 5.21: Gráfico de Boxplot de Datas

Gráfico Boxplot de DatasObjetivo Identificar se, dependendo do dia, a pontuação dos jogadores podem

sofrer uma significante alteração.Tipo de gráfico Gráfico de BoxplotValores do eixo dasabcissas (X)

Mini-Jogo por Data


Pontuação


Figura 5.28: Exemplo de Gráfico Gerado - Boxplot de Datas


Tabela 5.22: Gráfico de Boxplot de Jogadores

Gráfico Boxplot de JogadoresObjetivo Identificar em quais jogos um jogador consegue atingir mais pontos,

verificando se o tipo de jogo afeta o desempenho do jogador.Tipo de gráfico Gráfico de BoxplotValores do eixo dasabcissas (X)

Mini-Jogo por Jogadores


Pontuação


Figura 5.29: Exemplo de Gráfico Gerado - Boxplot de Jogadores

5.3 Novos Jogos 64

5.3 Novos Jogos

O desenvolvimento de novos jogos foi realizada na terceira iteração do projeto. Porém, aideia dos novos jogos foi pesquisada antes da primeira iteração com a visita ao oftalmologistaWilliam Procópio. A reunião tratou-se de orientações técnicas de como estimular a visão deuma criança e também surgiram várias ideias que serão possíveis a longo prazo.

5.3.1 Definição de Requisitos

5.3.1.1 Requisitos Funcionais

Tabela 5.23: Requisitos Funcionais

ID Requisito Funcional AtorRF5 Treinar a percepção de tamanho JogadorRF6 Avaliar o nível de contraste mínimo do jogador JogadorRF7 Reconhecer a captação de movimento do jogador Jogador

5.3.1.2 Requisitos Não-Funcionais

Tabela 5.24: Requisitos Não-Funcionais

ID Requisito Não Funcional CategoriaRNF5 O botões precisam ser de fácil identificação com a res-

posta que o jogador quer escolher.Usabilidade

RNF6 Utilizar cores e formatos de objetos simples, man-tendo o padrão atual

Usabilidade

5.3 Novos Jogos 65

5.3.2 Diagrama de Atividades

Figura 5.30: Diagrama de Atividades - Execução de Jogo

5.3 Novos Jogos 66


Figura 5.31: Diagrama de Classes - Novos Jogos

A classe FaseMutanteBase é responsável pela lógica básica dos novos mini-jogos que foramdesenvolvidos. Ela é responsável por montar a estrutura básica de elementos de interface gráficadentro de uma instância de TelaJogo e atribui à essas instâncias chamadas de métodos que serãodelegados à classes filhas.

5.3 Novos Jogos 67

5.3.4 Jogos desenvolvidos

5.3.4.1 Identifique a Forma!

O objetivo da criança nesse mini-jogo é identificar qual é a forma do desenho no centro datela. O desenho começa com um tamanho muito inferior ao tamanho original e, a cada cliqueque for dado na tela, o tamanho da figura aumentará.

Quando a forma for identificada, o jogador deverá clicar em uma das figuras situadas nocanto direito da tela. Caso acerte, irá passar de fase. Caso contrário irá perder pontos. Quantomais cedo a forma do objeto for identificada, maior será a pontuação obtida na fase. A Tabela5.25 exibe quais níveis de redimensão de imagem é possível, com a quantia de pontuação obtidaem cada nível.

Tabela 5.25: Tabela de Pontuação do Jogo de Formas

Redimensão Pontos obtidos6.25% 100012.5% 90025% 80050% 70075% 600100% (Tamanho Original) 500200% 400300% 300400% 200500% 100

Foi designado um total de doze fases, com dificuldades variadas. Existe um total de seteformas de figuras a serem identificadas, utilizando formas geométricas básicas como quadrados,triângulos, círculos. A cor preta foi utilizada para permitir um contraste maior entre o fundo e afigura. A Tabela 5.26 lista todas as formas.

Tabela 5.26: Formas Geométricas do Jogo de Formas

Nome da Forma ImagemCírculoTriânguloTriângulo InvertidoQuadradoHexágonoCruzEstrela

5.3 Novos Jogos 68

Figura 5.32: Tela do Jogo Identifique as Formas!

5.3 Novos Jogos 69

5.3.4.2 Jogo de Contraste

O objetivo desse jogo é identificar em qual nível de contraste a criança consegue identificara forma da figura no centro da tela. Para simular o contraste no jogo foi necessário utilizar umfundo branco e uma sombra que se situa em frente à figura a ser identificada. Inicialmente, essasombra possui um baixo nível de transparência, o que cria um menor contraste. Ao clicar natela, esse contraste aumenta à medida em que a transparência da sombra diminui.

Quando o jogador identificar a figura central, ele deverá clicar em uma das quatro opçõesao lado direito da tela. A pontuação é inversamente proporcional ao nível de contraste em quea figura foi identificada. A Tabela 5.27 mostra a pontuação que é obtida baseado no nível decontraste da sombra, um valor proposto de 0 a 100, sendo o menor valor o maior contraste obtidoentre o fundo e a figura. Foi elaborado oito diferentes fases utilizando formatos geométricosbásicos, como o citado na Tabela 5.26, no jogo anterior.

Tabela 5.27: Tabela de Pontuação do Jogo de Contraste

Contraste Pontos obtidos99% 127597% 124595% 120593% 115891% 110785% 105280% 99375% 93170% 86665% 79760% 72555% 64950% 57040% 48630% 39820% 30305% 20001% 83

5.3 Novos Jogos 70

Figura 5.33: Tela do Jogo de Contraste

5.3 Novos Jogos 71

5.3.4.3 Jogo do Movimento

Esse jogo tem como objetivo reconhecer a captação de movimento do jogador. Em todas asfases aparece uma pequena bola que percorre uma tragetória e o jogador deve identificar qualé a forma dessa tragetória. Uma tragetória possui ao mínimo dois pontos a serem percorridos.Inicialmente, a figura possui uma velocidade alta. Ao clicar na tela, essa velocidade é diminuida.

Ao identificar a forma, o jogador poderá clicar nas opções no canto direito da tela. A pon-tuação obtida em uma fase depende da velocidade da bola em que a tragetória foi identificada.Foi elaborado um total de oito fases, sendo uma fase para cada tipo tragetória (ver Tabela 5.29).A Tabela 5.28 mostra as possíveis pontuações que podem ser obtidas.

Tabela 5.28: Tabela de Pontuação do Jogo de Movimento

Velocidade Pontos obtidos1000 1100

500 1000250 900167 800125 700100 60067 50050 40033 30025 20020 100

Tabela 5.29: Tragetórias do Jogo de Movimento

Tragetória ImagemHorizontalVerticalDiagonal ADiagonal BQuadradoLetra ’V’Letra ’V’ InvertidaTriângulo

5.3 Novos Jogos 72

Figura 5.34: Tela do Jogo de Movimento

73

6 Cronograma

O trabalho foi concluído em seis meses, começando em Janeiro de 2012 e terminando emJunho de 2012. A maior parte do tempo teve foco na reorganização do projeto (módulo 1).

É apresentado abaixo uma figura com o cronograma planejado sobre a execução do tra-balho, o cronograma executado e, e em seguida a descrição para as atividades em ciclo, definindoas cores e os módulos respectivos;

Figura 6.1: Cronograma planejado sobre a execução do trabalho

Figura 6.2: Cronograma executado do trabalho

6 Cronograma 74

Figura 6.3: Descrição dos ciclos

O cronograma foi dividido em dois tipos de tarefas: tarefas sequenciais, que foram realiza-das em paralelo às tarefas do tipo em ciclos; tarefas em ciclos, que foram realizadas em váriasiterações, seguindo o ciclo de vida espiral.

O cronograma executado difere do planejdo por haver a necessidade de focar o trabalho nodesenvolvimento para apenas após essa etapa começar a redação do trabalho.

75

7 Recursos necessários

7.1 Software

• Sistema Operacional Linux;

• Netbeans IDE;

• JDK 7;

• Kile;

• Okular;

• Astah UML;

• Argo UML;

7.2 Hardware

• Notebook Dell Inspiron 1520, Core 2 Duo 1.8GHz, 2GB de memória RAM, 130GB dedisco rígido;

76

8 Considerações Finais

8.1 Conclusão

Este trabalho apresenta uma nova plataforma para o estímulo visual de pessoas com visãosubnormal denominada Vídere 2. São apresentados 12 mini jogos que tratam de contraste,identificação de formas, percepção de movimento, identificação de cores e contornos, análisede cenário de imagens. Além disso, o Vídere 2 oferece estatísticas e gráficos de forma integradaao aplicativo que disponibiliza que seja feito o acompanhamento de seus usuários, sua evoluçãono treinamento visual em cada jogo. Além disso, esse acompanhamento pode ocorrer de formaindividual ou coletiva.

O Vídere foi desenvolvido utilizando ferramentas livres e independentes de sistema ope-racional, de forma que pode ser usado em qualquer sistema operacional, bastando a insta-lação do Java na máquina do cliente. O Vídere é livremente disponibilizado a partir da urlhttp://code.google.com/p/viderejogos/.

Os resultados apresentados ilustram o potencial dessa plataforma de jogos, os quais exibemde forma clara a adequação dessa proposta os objetivos propostos, mostrando-se uma ferramentaútil para os deficientes visuais e profissionais de saúde que podem acompanhar a evolução dosusuários de forma integrada e transparente ao usuário.

O desenvolvimento deste trabalho contribuiu altamente na aquisição de experiência profis-sional como analista e desenvolvedor de sistemas. O conhecimento adquirido e dificuldadessolucionadas na prática durante todo o trabalho esclareceram diversas dúvidas que em mo-mentos teóricos não foram identificados. É inmensurável o valor pessoal da conclusão destetrabalho.

8.2 Trabalhos Futuros

Durante o desenvolvimento do trabalho várias ideias foram surgindo para a melhoria doaplicativo:

8.2 Trabalhos Futuros 77

• Possibilitar a opção de executar o aplicativo em forma de Java Web Start, onde o usuáriosde todo o mundo poderiam contribuir com a experiência de jogo e também analisar es-tatísticas tanto locais quanto globais.

• Estender o aplicativo de forma com que o jogador possa interagir com mini-jogos atravésde hardware específico para o jogo, por exemplo: um grande tambor que substitui o cliquedo mouse em um botão. Assim, profissionais de outras áreas poderiam ser integrados aoprojeto e seu desenvolvimento.

• A inclusão de outros mini-jogos que se assemelhem com jogos utilizados na vida realpara gerar mais alternativas de mini-jogos, não limitando-se apenas ao treinamento dosentido visual, mas também ao treinamento de outros sentidos humanos como o auditivoe o tato, pois muitas vezes uma deficiência em um sentido humano não está isolada deoutros sentidos (GIL, 2001).

78

Referências Bibliográficas

AUDIOGAMES. AudioGames Frequently Asked Questions. 2009. Acesso em: 30 Abr. 2012.Disponível em: <http://audiogames.net/page.php?pagefile=faq>.

BORGES, A. Projeto DOSVOX. 2002. Acesso em: 29 Abr. 2012. Disponível em:<http://intervox.nce.ufrj.br/dosvox/intro.htm>.

BRAGA, A. P.; SEI, M. Perfil da Deficiência em Crianças e Adolescentes. 1997. Acesso em:07 Out. 2011. Disponível em: <http://www.icevi.org/publications/icevix/wshops/0348.html>.

CUNHA, E. E. JogaVOX: Ferramenta e Estratégias para Construc̃ão de Jogos Edu-cacionais para Deficientes Visuais. 2007. Acesso em: 30 Abr. 2012. Disponível em:<http://intervox.nce.ufrj.br/jogavox/textos/EricaEstevesCunha.pdf>.

DEITEL, P. Java Como Programar. [S.l.]: Pearson, 2010.

FAVA, F. Jogando com o ar: o sopro como instrumento de acessibilidadenos jogos eletrônicos. 2010. Acesso em: 27 Abr. 2012. Disponível em:<http://www.sbgames.org/papers/sbgames08/gameandculture/full/gc15_08.pdf>.

FERREIRA, V. F. Livro estuda benefícios de jogos virtuais para deficientes. 2011. Acesso em:27 Abr. 2012. Disponível em: <http://www.usp.br/agen/?p=84952>.

GIL, M. Deficiência Visual. 2001. Acesso em: 16 Maio 2012. Disponível em:<http://deficienciavisual.com.sapo.pt/txt-deficienciavisual-MartaGil.htm>.

LOOKTEL. LookTel - Instant Recognition Apps for Persons with Low Vision or Blindness.2009. Acesso em: 29 Abr. 2012. Disponível em: <http://www.looktel.com/>.

MARTIN, R. C. Clean Code - A Handbook of Agile Software Craftsmanship. [S.l.]: PrenticeHall, 2008.

OMS. Consultation on Development of Standards for Characterization of VisionLoss and Visual Functioning. 2003. Acesso em: 07 Out. 2011. Disponível em:<http://whqlibdoc.who.int/hq/2003/WHO_PBL_03.91.pdf>.

ORACLE. Java SE Overview - 6 Key Features. 2012. Acesso em: 25 Abr. 2012. Disponívelem: <http://www.oracle.com/technetwork/java/javase/overview/features-jsp-140508.html>.

RODRIGUES, G. C. d. V. P. Vídere - jogos para estimulação visual. 2005. Acesso em: 22 Ago.2011. Disponível em: <http://pessoal.utfpr.edu.br/fabricio/ensino/orientacoes/monografia-grazielapascoal.pdf>.

SCHELL, J. The Art of Game Design: A Book of Lenses. [S.l.]: Morgan Kaufman Publishers,2008. ISBN 978-0-12-369496-6.

Referências Bibliográficas 79

SILVA, L. F. da. Geometria e cegos - Um jogo computacional no processo deaprendizagem de trigonometria. 2009. Acesso em: 29 Abr. 2012. Disponível em:<http://intervox.nce.ufrj.br/dosvox/textos/monografia_lidiane.pdf>.

SOARES, N. Alunos do IME criam aplicativo para deficientes visuais. 2012. Acesso em: 06Junho 2012. Disponível em: <http://www.usp.br/agen/?p=100556>.

VIKLUND, A. JFreeChart. 2012. Acesso em: 25 Abr. 2012. Disponível em:<http://www.jfree.org/jfreechart/>.

80

APÊNDICE A -- Proposta do Trabalho deDiplomação

UNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁ

UTFPR CAMPUS CORNÉLIO PROCÓPIO

DIRETORIA DE GRADUAÇÃO E EDUCAÇÃO PROFISSIONAL

CURSO SUPERIOR DE TECNOLOGIA EM ANÁLISE EDESENVOLVIMENTO DE SISTEMAS


DESENVOLVIMENTO DE JOGOS PARA A ESTIMULAÇÃO VISUAL

CORNÉLIO PROCÓPIO

NOVEMBRO - 2011


DESENVOLVIMENTO DE JOGOS PARA AESTIMULAÇÃO VISUAL

Proposta de trabalho de conclusão de cursoapresentada como requisito parcial a obtençãodo grau de Tecnólogo em Desenvolvimento deSistemas de Informação pela Universidade Tec-nológica Federal do Paraná - Campus CornélioProcópio

Orientador:

Fabrício Martins Lopes

CORNÉLIO PROCÓPIO

NOVEMBRO - 2011

Resumo

Este trabalho propõe o desenvolvimento de uma nova versão do projeto Vídere. Os ob-jetivos são a reestruturação do código, adição de módulo para acompanhamento evolutivo dousuário e inclusão de novos jogos ao pacote atual.

O projeto seguirá o ciclo de vida do modelo espiral. Utilizará a diagramação da UnifiedModeling Language - UML para a modelagem do sistema. O desenvolvimento será feito com atecnologia Java para a programação do software e estima-se a conclusão do aplicativo em seismeses.

Sumário

Lista de Figuras

Lista de Tabelas

1 Introdução p. 7

2 Objetivos p. 8

2.1 Reorganização da estrutura do sistema . . . . . . . . . . . . . . . . . . . . . p. 8

2.2 Acompanhamento evolutivo do usuário . . . . . . . . . . . . . . . . . . . . p. 9

2.3 Implementação de novos jogos . . . . . . . . . . . . . . . . . . . . . . . . . p. 9

3 Justificativa p. 10

4 Revisão Bibliográfica p. 12

4.1 Conceitos sobre Deficiência Visual . . . . . . . . . . . . . . . . . . . . . . . p. 12

4.2 Definições para Deficiência Visual . . . . . . . . . . . . . . . . . . . . . . . p. 12

4.3 Soluções para a Deficientes Visuais . . . . . . . . . . . . . . . . . . . . . . p. 13

5 Metodologia p. 14

5.1 Estudo das tecnologias usadas no projeto . . . . . . . . . . . . . . . . . . . . p. 14

5.2 Desenvolvimento de novos módulos . . . . . . . . . . . . . . . . . . . . . . p. 15

5.2.1 Concepção do Jogo . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 15

5.2.2 Análise de Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 15

5.2.3 Desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 15

5.2.4 Testes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 16

5.3 Redação do Trabalho de Diplomação . . . . . . . . . . . . . . . . . . . . . . p. 16

6 Cronograma p. 17

7 Recursos necessários p. 18

7.1 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 18

7.2 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 18

Referências Bibliográficas p. 19

Lista de Figuras

6.1 Cronograma planejado sobre a execução do trabalho . . . . . . . . . . . . . p. 17

6.2 Descrição dos ciclos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 17

Lista de Tabelas

3.1 Índice de população deficiente no Brasil . . . . . . . . . . . . . . . . . . . . p. 11

4.1 Classificação da Perda de Visão . . . . . . . . . . . . . . . . . . . . . . . . p. 13

7

1 Introdução

O uso da tecnologia no dia a dia tornou-se uma atividade indispensável. Há vários recursos

oferecidos aos usuários realizado com o apoio da informática utilizando-se um software para

atender as necessidades de uma pessoa.

Dentre as diversas áreas de aplicações, a área educacional foca o estímulo ao desenvolvi-

mento de uma determinada habilidade humana, estes são chamados de softwares educacionais

que oferecem ao usuário, muitas vezes, recursos da multimídia para tornar o aprendizado mais

interativo e eficiente.

Com ênfase na área de desenvolvimento de softwares educacionais será proposto a conti-

nuação de um projeto com as mesmas características de uma aplicação educacional focada na

área de estímulo à visão para portadores de deficiência visual.

8

2 Objetivos

Uma abordagem inicial para o estímulo visual para crianças com baixo índice de visão ou

visão subnormal, desenvolvido por Graziela Cristina do Vale Pascoal Rodrigues em seu Tra-

balho de Diplomação do Curso de Tecnologia em Informática na UTFPR Campus Cornélio

Procópio será considerada no desenvolvimento deste trabalho com objetivo de expandir o soft-

ware.

Esse software já possui nove diferentes jogos que “abordam meios de estimulação visual

tais como, visão para detalhes em cores, visão de detalhes em imagens, percepção de contrastes,

estímulos luminosos, interpretação de imagens e cenas, visualização de contornos e melhoria

da memória visual.” (RODRIGUES, 2005).

A nova versão do projeto irá possuir três módulos:

1. Reorganização da estrutura do sistema;

2. Acompanhamento evolutivo do usuário;

3. Implementação de novos jogos.

2.1 Reorganização da estrutura do sistema

A reorganização da estrutura do sistema será feita para que possa garantir a estabilidade do

sistema. Muitos sistemas sofrem contínuas mudanças. Uma pequena mudança em uma parte

do sistema pode durar mais do que se esperava ou até mudar o comportamento de outra parte.

Para reduzir a frequência com que esses riscos ocorram, manter um código limpo e organizado

é uma opção para o desenvolvedor (MARTIN, 2008).

Com a reorganização do sistema, utilizando recursos do paradigma orientado a objetos, no-

vas funcionalidades serão adicionadas ao sistema sem afetar a rotina de um jogo, e a inclusão de

novos jogos será feita de forma mais direta, sem ter que se preocupar como o sistema funciona

como um todo, apenas sabendo o básico que uma classe para jogo deve implementar.

2.2 Acompanhamento evolutivo do usuário 9

Nesse módulo, parte do tempo será dedicado a revisão de aspectos gerais do jogo, como

desempenho, que se trata de tempo de carregamento e processamento da aplicação em memória,

e documentação do código.

2.2 Acompanhamento evolutivo do usuário

Será implementado um módulo para acompanhamento evolutivo do usuário baseado em

um histórico de dados de cada jogo que serão coletados durante o andamento do jogo. Os

dados coletados podem variar de acordo com o jogo, e para cada jogo poderá ser produzido um

relatório com índices de acertos e de erros.

Em se tratando de softwares educacionais, é extremamente necessário que se obtenha re-

sultados com o uso desse software. Esse módulo ficará responsável por exibir esses resultados

que poderão ser trabalhados como o usuário desejar.

2.3 Implementação de novos jogos

No trabalho de referência foram propostas novas ideias para o desenvolvimento de mais

alguns jogos no pacote atual. Essa tarefa será realizada depois de completado as duas atividades

anteriores.

10

3 Justificativa

A deficiência muitas vezes é confundida como sendo o contrário de eficiente, porém à

medida que se convive com uma pessoa com deficiência, nota-se que ela não é incapaz. Este tipo

de indivíduo pode enfrentar dificuldades para realizar atividades consideradas “do cotidiano”,

porém, em geral, possui grande habilidade em exercer outras funções, assim como todo ser

humano (GIL, 2000).

O conceito de deficiência visual abrange uma vasta área de possibilidades: desde a cegueira

total até a visão subnormal, que pode ser chamado também de baixa visão. Enxergar não é uma

habilidade humana inata, é necessário aprender a ver. Portanto, assim que aprendemos a ver

desenvolvemos muitas habilidades baseadas na visão, uma delas é para orientar-se no espaço,

que se baseia na habilidade de distinguir objetos visíveis.

A perda parcial ou total da visão adquirida na infância pode trazer alguns prejuízos à cri-

ança, como dificuldades no relacionamento social, expressão emocional, desenvolvimento edu-

cacional, que caso não for solicitada ajuda para um tratamento adequado, pode se repercutir

durante toda a vida (GIL, 2000).

Por isso, observou-se a necessidade de desenvolver um software que servirá como ferra-

menta de auxílio para o tratamento do deficiente visual. Os recursos tecnológicos e de multimí-

dia, encontrados em um computador, são ferramentas importantes para aprendizagem de forma

mais segura e eficaz (NANES; SIMÕES, 2010).

Utilizando-se o computador, pode ser criado um ambiente de aprendizado controlado, sem

riscos de bloqueios cognitivos causados por problemas de relacionamento.

A partir da análise do censo demográfico de 2000 realizado pelo IBGE, foi possível observar

que dentro da população brasileira que possui algum tipo de deficiência, quase metade possui

deficiência visual. A tabela a seguir mostra a quantidade, em milhões, de brasileiros com uma

deficiência e a frequência relativa entre essa quantidade e o número total de pessoas com algum

tipo de deficiência.

3 Justificativa 11

Tabela 3.1: Índice de população deficiente no BrasilDeficiência Quantidade (em milhões) PorcentagemVisual 16,5 48,1Motora 7,9 22,9Auditiva 5,7 16,7Mental 2,8 8,3Física 1,4 4,1

Fonte: adaptado de IBGE (IBGE, 2000)

O software produzido servirá como um recurso a mais para auxiliar o processo de apren-

dizagem. É necessário que se tenha em mente que o produto não irá resolver os problemas de

convivência entre um aluno e professor. Será necessário, também, o acompanhamento por parte

dos pais e professores no incentivo à aprendizagem e desenvolvimento da criança.

12

4 Revisão Bibliográfica

4.1 Conceitos sobre Deficiência Visual

É uma alteração ou diminuição da eficiência visual. As causas mais comuns para que essa

alteração ocorra são: de forma inata, a pessoa já nasce com a deficiência, podendo até perder a

visão totalmente com o tempo; e de forma adquirida, por sofrer acidentes que comprometam a

visão (BRAGA; SEI, 1997).

A deficiência visual pode estar dividida em dois grupos: cegueira e visão subnormal. A

pessoa cega possui apenas a percepção da luz ou não tem nenhuma visão. Maior parte do

conhecimento adquirido por essas pessoas é através de outros sentidos humanos, sendo mais

utilizados o de tato e o de audição. A pessoa com visão subnormal consegue utilizar a visão

sem que limite o próprio desempenho em exercer alguma atividade.

4.2 Definições para Deficiência Visual

A perda de visão possui alguns graus de acordo com a escala optométrica de Snellen, que

mensura a acuidade visual para longe.

Para obter a escala de Snellen é necessário fazer a relação entre a qualidade da visão sub-

normal a certa distância (em metros ou pés) comparado à qualidade da visão normal. De acordo

com essa escala, o primeiro grau é considerado visão normal, os graus 1 e 2 são considerados

visão subnormal, enquanto os demais graus são considerados como cegueira (OMS, 2003).

A tabela a seguir mostra a classificação da perda de visão de acordo com dados retirados de

uma pesquisa feita pela Organização Mundial de Saúde - OMS que mostra o grau da perda de

visão e a acuidade máxima para o grau.

4.3 Soluções para a Deficientes Visuais 13

Tabela 4.1: Classificação da Perda de VisãoGrau de Perda de Visão Acuidade Máxima (Snellen)

0 1,01 0,32 0,13 0,054 0,025 0

Fonte: adaptado de OMS.

4.3 Soluções para a Deficientes Visuais

Para a leitura, pode ser utilizando tanto o sistema de leitura através do tato, o Braille, ou

através da audição, por meio de livros falados ou sintetizadores de voz. Na escrita, existe

sistemas que escrevem em Braille e também impressoras Braille. Na locomoção, pessoas com

cegueira podem usar bengalas ou cães-guia.

Para algumas alterações visuais, como miopia, hipermetropia, astigmatismo, entre outras,

pode ser feito o uso de lentes (óculos ou lentes de contato) ou cirurgias oculares.

14

5 Metodologia

Este trabalho de diplomação será desenvolvido realizando as seguintes atividades:

1. Estudo das tecnologias usadas no projeto;

2. Desenvolvimento de novos módulos;

3. Redação do Trabalho de Diplomação.

5.1 Estudo das tecnologias usadas no projeto

Essa atividade será realizada durante grande parte do trabalho de diplomação, em paralelo

com a atividade de desenvolvimento. A aquisição de conhecimento sobre assuntos relacionados

ao entendimento do projeto desenvolvido e também à implementação dos novos módulos serão

realizados nessa atividade.

O aplicativo de Graziela foi desenvolvido utilizando a linguagem de programação orien-

tada a objetos Java e compilado no ambiente de desenvolvimento Netbeans. Para alcançar os

objetivos do projeto (citados na seção 2), será necessária a aquisição do código fonte, produ-

zido por Graziela Rodrigues, que será providenciado por Fabrício Lopes. Em seguida o código

será estudado a fim de entender as relações entre as classes e objetos para que seja possível a

remodelação do sistema sem haver modificações no fluxo atual do jogo e sem alterar a saída de

dados nas interfaces gráficas.

Os princípios de orientação a objetos SOLID introduzidos por Robert Martin são as refe-

rências para iniciar a remodelação do sistema. Os cinco princípios, sendo eles: Single Res-

ponsability, Open/Closed, Liskov substitution, Interface segregation e Dependency inversion,

visam uma melhor organização e maior limpeza de código, tornado-o fácil de ser entendido e

ser mantido não apenas pelo autor, mas também por outros colaboradores (MARTIN, 2008).

Com isso, o módulo de acompanhamento evolutivo será introduzido no sistema e imple-

mentado para cada jogo. Esse módulo servirá para que o aluno e o professor possam ter es-

5.2 Desenvolvimento de novos módulos 15

tatísticas de resultados baseado em dados coletados durante o jogo, sendo eles: pontuações de

acertos e pontuações de erros. Os dados serão gravados na máquina local e será possível criar

mais de um perfil de usuário, usando como atributo diferencial o nome do aluno. A exibição

das estatísticas será feito através de gráficos de linha que serão gerados e exibidos pelo próprio

aplicativo.

5.2 Desenvolvimento de novos módulos

O desenvolvimento dos novos módulos será realizado baseando-se no modelo de processo

de ciclo de vida espiral. A escolha do modelo espiral se deu principalmente por ser um modelo

que ajuda a estimar prazos de forma mais realista conforme for dado o andamento do projeto,

podendo, assim, focar a execução de uma atividade sem prejudicar outra.

As fases que serão seguidas no modelo serão: Concepção do Jogo, Análise de Projeto,

Desenvolvimento e Testes.

5.2.1 Concepção do Jogo

A fase de concepção do jogo é o ponto inicial da criação de um jogo. É feito um brain storm

(chuva de ideias) para decidir como será o jogo, incluindo planejamento de regras de jogo, de

jogabilidade e de abstração interfaces gráficas.

5.2.2 Análise de Projeto

Nessa fase, a ideia abstrata da fase anterior é mais concretizada, gerando documentos para

descrever o problema e como este será resolvido. A pesquisa por jogos que se assemelhem à

ideia também pode ser feita, a fim de encontrar melhores soluções para o jogo.

5.2.3 Desenvolvimento

Com o documento gerado na fase anterior, será dado início ao desenvolvimento do jogo.

O principal foco nessa fase será a produção do jogo, incluindo a programação das interfaces e

regras. O código produzido nessa fase não deve ser final, deve ser feito pensando que haverá

possíveis reajustes na fase seguinte.

5.3 Redação do Trabalho de Diplomação 16

5.2.4 Testes

O módulo gerado na fase anterior será revisado para verificar se os principais pontos do do-

cumento gerado na análise foram cumpridos. Não se limitando apenas à revisão, será realizado

um teste a fim de encontrar possíveis defeitos nas rotinas do jogo para corrigi-los para a versão

final; avaliar a qualidade, no que se refere à atmosfera do jogo (sensação de estar jogando e

identificar-se no ambiente), feedbacks (exercer uma ação e receber um sinal que identifique que

a ação realmente foi executada) e jogabilidade (usuário exercer uma ação sem ser atrapalhado

pelo próprio jogo).

Caso for detectada uma nova ideia que possa melhorar o jogo ela será avaliada e um novo

ciclo poderá ser iniciado, começando da Concepção.

5.3 Redação do Trabalho de Diplomação

A redação do trabalho de diplomação será feita com maior ênfase no final do cronograma

planejado, estendendo até a um mês após a apresentação do trabalho. Será considerado na

escrita da redação, bibliografias estudadas durante o desenvolvimento do projeto e conversas

com o orientador.

17

6 Cronograma

O trabalho será feito em seis meses, començando em Janeiro e terminando em Junho de

2012. Maior parte do tempo será focado na reorganização do projeto (módulo 1).

É apresentado abaixo uma figura mostrando o cronograma planejado sobre a execução do

trabalho e em seguida a descrição para as atividades em ciclo, definindo as cores e os módulos

respectivos;

Figura 6.1: Cronograma planejado sobre a execução do trabalho

Figura 6.2: Descrição dos ciclos

O cronograma foi dividido em dois tipos de tarefas: tarefas sequencias, que irá ser realizada

em paralelo às tarefas do tipo em ciclos; tarefas em ciclos, que será feita em várias iterações,

seguindo o ciclo de vida espiral.

18

7 Recursos necessários

7.1 Software

• Sistema Operacional Linux;

• Netbeans IDE;

• JDK 7;

• Kile;

• Okular;

7.2 Hardware

• Notebook Dell Inspiron 1520, Core 2 Duo 1.8GHz, 2GB de memória RAM, 130GB de

disco rígido;

19

Referências Bibliográficas

BRAGA, A. P.; SEI, M. Perfil da Deficiência em Crianças e Adolescentes. 1997. Acesso em:07 Out. 2011. Disponível em: <http://www.icevi.org/publications/icevix/wshops/0348.html>.

GIL, M. Deficiência visual. 2000. Acesso em: 27 Ago. 2011. Disponível em:<www.dominiopublico.gov.br/download/texto/me000344.pdf>.

IBGE. Censo Demográfico 2000. 2000. Acesso em: 18 Set. 2011. Disponível em:<http://www.ibge.gov.br/home/presidencia/noticias/27062003censo.shtm>.

MARTIN, R. C. Clean Code - A Handbook of Agile Software Craftsmanship. [S.l.]: PrenticeHall, 2008.

NANES, M. T. R. T.; SIMÕES, N. R. do P. Acesso à Mídia Com Deficiência Visual ECom Deficiência Auditiva: Quem Se Preocupa Com Nós? 2010. Acesso em: 07 Out. 2011.Disponível em: <http://tinyurl.com/acesso-a-midia-com-deficiencia>.

OMS. Consultation on Development of Standards for Characterization of VisionLoss and Visual Functioning. 2003. Acesso em: 07 Out. 2011. Disponível em:<http://whqlibdoc.who.int/hq/2003/WHO_PBL_03.91.pdf>.

RODRIGUES, G. C. d. V. P. Vídere - jogos para estimulação visual. 2005. Acesso em: 22 Ago.2011. Disponível em: <http://pessoal.utfpr.edu.br/fabricio/ensino/orientacoes/monografia-grazielapascoal.pdf>.

universidade tecnolÓgica federal do paranÁ...

Documents