UNIVERSIDADE ESTADUAL DO CEARÁ PROGRAMA DE PÓS … · Java Acessible Debugger: Uma Abordagem de Interface Metafórica para Depuração de Código Java [recurso eletrônico] / Marcos

UNIVERSIDADE ESTADUAL DO CEARÁ

CENTRO DE CIÊNCIAS E TECNOLOGIA

PROGRAMA DE PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO

MESTRADO ACADÊMICO EM CIÊNCIA DA COMPUTAÇÃO

MARCOS DEVANER DO NASCIMENTO

JAD – JAVA ACCESSIBLE DEBUGGER

UMA METÁFORA VISUAL PARA APOIAR SURDOS E DEFICIENTES AUDITIVOS

NO APRENDIZADO DE PROGRAMAÇÃO

FORTALEZA – CEARÁ

2017



UMA METÁFORA VISUAL PARA APOIAR SURDOS E DEFICIENTES AUDITIVOS NO

APRENDIZADO DE PROGRAMAÇÃO

Dissertação apresentada ao Curso de MestradoAcadêmico em Ciência da Computação doPrograma de Pós-Graduação em Ciência daComputação do Centro de Ciências e Tec-nologia da Universidade Estadual do Ceará,como requisito parcial à obtenção do título demestre em Ciência da Computação. Área deConcentração: Ciência da Computação

Orientador: Prof. PhD. Francisco C. deM. B. Oliveira

FORTALEZA – CEARÁ

2017

Dados Internacionais de Catalogação na Publicação

Universidade Estadual do Ceará

Sistema de Bibliotecas

Nascimento, Marcos Devaner do . Java Acessible Debugger: Uma Abordagem deInterface Metafórica para Depuração de Código Java[recurso eletrônico] / Marcos Devaner do Nascimento.- 2017. 1 CD-ROM: il.; 4 ¾ pol.

CD-ROM contendo o arquivo no formato PDF dotrabalho acadêmico com 104 folhas, acondicionado emcaixa de DVD Slim (19 x 14 cm x 7 mm).

Dissertação (mestrado acadêmico) - UniversidadeEstadual do Ceará, Centro de Ciências e Tecnologia,Mestrado Acadêmico em Ciência da Computação,Fortaleza, 2017. Área de concentração: Ciência da Computação. Orientação: Prof. Dr. Francisco Carlos MatosBarbosa de Oliveira .

1. Surdos . 2. Depurador. 3. Acessibilidade. 4.Usabilidade. 5. Interfaces Metafóricas. I. Título.



UMA METÁFORA VISUAL PARA APOIAR SURDOS E DEFICIENTES AUDITIVOS NO

APRENDIZADO DE PROGRAMAÇÃO

Dissertação apresentada ao Curso de MestradoAcadêmico em Ciência da Computação doPrograma de Pós-Graduação em Ciência daComputação do Centro de Ciências e Tec-nologia da Universidade Estadual do Ceará,como requisito parcial à obtenção do título demestre em Ciência da Computação. Área deConcentração: Ciência da Computação

Aprovado em: 16/03/2017

BANCA EXAMINADORA

Dedico esse trabalho aos meus avós Luiza Soa-

res e Joaquim Gervásio (in memorian), por se-

rem meus exemplos de luta e coragem, dando-

me inspiração para seguir em frente.

AGRADECIMENTOS

A Deus por estar sempre do meu lado, dando-me forças, proporcionando oportunidades e

colocando pessoas maravilhosas no meu caminho.

A meus avós Luiza Soares e Joaquim Gervásio, pelo seu exemplo de luta e dignidade e pela fé

em Deus que plantaram em meu coração.

A meus tios e pais de coração Lourdes Soares e Raimundo Ramos que me criaram, educaram e

me ensinaram a viver com dignidade superando todos as dificuldades que a vida pode oferecer.

A minha Mãe Maria Helena Soares, por me ensinar a ser forte, me apoiar em momentos tão

difíceis e pelo seu exemplo de superação e garra.

Ao meu Orientador Dr. Francisco Oliveira, que me acolheu com tanta bondade e respeito, me

guiando, ensinando, ajudando a me superar cada vez mais. Pelos momentos em que foi um

grande amigo além de orientador e pelo grande referencial que se tornou para mim.

A Lidiane Castro por toda a força que me deu para ingressar no mestrado, pelos petelecos nas

costas para que eu não dormisse na aula e sobretudo pelo grande carinho, ajuda e a confiança em

mim depositada.

A Shara Alves por me ajudar a materializar um sonho, sendo co-participante na construção do

Java Accessible Debugger, por ser uma grande companheira de trabalho tornando-se uma grande

amiga.

Aos meus amigos Fábio Lessa, José Alexandre, Solange Carneiro, Gleiciane Oliveira, Raquel

Farias, Tiago Bento, Alessandro Vieira e Wallace Franklin que sempre me deram todo apoio e

força nessa jornada.

Aos anjos que Deus colocou no meu caminho como Erivânia Queiroz, Lise Mary, Francisca

Monica Santanna, Mauro Oliveira, Eder Furtado, Bruno Queiroz, Adriano Freitas, Profa Telma e

Kassandra Ribeiro que me deram toda motivação e inspiração servindo de referência e mostrando

que seria possível.

E por fim, todos aqueles que não foram citados mas de forma direta ou indireta colaboraram para

que este sonho se tornasse realidade.

A todos vocês dedico todo meu amor, carinho e sobretudo o dever de repassar tudo de bom que

vocês investiram em mim, sempre compartilhando conhecimento, buscando proporcionar ao

próximo todas as oportunidades que me foram dadas.

“Esforça-te, faz a obra que Eu te mandei, tem

bom ânimo, não pasmes, nem te espantes, e Eu

serei contigo por onde quer que andares.”

(Livro de Josué 1:9)

RESUMO

O Laboratório de Educação a Distância para Pessoas com Deficiência - Le@d desenvolve e

aplica cursos EAD para formação de programadores, nos quais os conteúdos são adaptados para

Pessoas com Deficiência(PCD). Durante a aplicação do curso, foi possível perceber a dificuldade

que alunos surdos e deficientes auditivos (SDA) tinham para desenvolver e evoluir seus códigos.

Decidiu-se, então, analisar o desempenho de alunos SDA e ouvintes (não SDA) durante a tarefa

de depuração de um código Java. Os resultados mostraram que programadores SDA têm mais

dificuldade para desempenhar essa tarefa, sendo esta dificuldade atenuada quando utilizado um

depurador visual. Por esta razão, decidiu-se propor o Java Accessible Debugguer(JAD), um

depurador visual acessível. Ele, utiliza-se do conceito de interfaces metafóricas, apropriando-se

de simbolos e sinais do trânsito para auxiliar no processo de depuração e evolução de código.

Experimentos aplicados ao JAD, mostrou que sua utilização pode proporcionar as mesmas

oportunidades de aprendizado e evolução de código para SDA e não SDA, tornando SDA mais

competitivos para o mercado de trabalho.

Palavras-chave: Surdos. Deficientes auditivos. Depurador. Acessibilidade. Usabilidade.

Interfaces Metafóricas

ABSTRACT

The Le @ d Distance Learning Laboratory develops and applies EAD courses for training

programmers, where content is adapted for People with Disabilities (PCD). During the application

of the course, it was possible to perceive the difficulty that deaf and hearing impaired students

(SDA) had to develop and evolve their codes. It was then decided to analyze the performance

of SDA students and listeners (not SDA) during the debugging task of a Java code. The results

showed that SDA programmers have more difficulty performing this task, and this difficulty is

attenuated when using a visual debugger. For this reason, it was decided to propose the Java

Accessible Debugger (JAD), an accessible visual debugger. It uses the concept of metaphorical

interfaces, appropriating symbols and traffic signals to aid in the process of code evolution and

debugging. Experiments applied to JAD have shown that their use can provide the same learning

opportunities and code evolution for SDA rather than SDA, making SDA more competitive for

the job market.

Keywords: Deaf. Hearing impaired. Debugger. Accessibility. Usability. Metaphorical

interfaces

LISTA DE ILUSTRAÇÕES

Figura 1 – Modelo de Referência para Visualização. . . . . . . . . . . . . . . . . . 21

Figura 2 – Tabela de resultados da cobertura de código, ela mostra os resultados

da qualidade da cobertura de código disponível como uma porcenta-

gem e como uma barra de progresso. . . . . . . . . . . . . . . . . . . . 22

Figura 3 – Mapa cartográfico da distribuição dos pacotes, apresentando em verde

os resultados da qualidade da cobertura de código realizada pelo JCC. 23

Figura 4 – Visualização do Codmap para arquivos de classes visitados por progra-

madores durante o desenvolvimento de um sistema. . . . . . . . . . . . 24

Figura 5 – Perspectivas de visualização do Codmap. . . . . . . . . . . . . . . . . . 25

Figura 6 – Sublime Text. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Figura 7 – WindowBuilder é um plug-in para Eclipsee permite criar interfaces

gráficas apenas arrastando componentes para a tela de edição. . . . . . 28

Figura 8 – Paralelo entre comunicação visual e verbal. . . . . . . . . . . . . . . . . 30

Figura 9 – Questionário System Usability Scale. . . . . . . . . . . . . . . . . . . . 32

Figura 10 – Gráfico de associação de percentuais à pontuação do SUS categori-

zando os graus em letras. . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Figura 11 – Jeliot 3 Interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Figura 12 – Visualização com Diagrama de Objetos. . . . . . . . . . . . . . . . . . . 37

Figura 13 – Visualização com Diagrama de Sequência. . . . . . . . . . . . . . . . . 37

Figura 14 – JGrasp Interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Figura 15 – Web Aula com vídeo em Libras. . . . . . . . . . . . . . . . . . . . . . . 40

Figura 16 – JLoad Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Figura 17 – Interface Gráfica do Java Accessible Debugger - JAD. . . . . . . . . . 42

Figura 18 – Habilidades Relevantes. . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Figura 19 – Classes Java. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

Figura 20 – Resultados coletados. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Figura 21 – Participante do Grupo 01 Utilizando o Eclipse. . . . . . . . . . . . . . . 49

Figura 22 – Participante do Grupo 02 Utilizando o JGrasp. . . . . . . . . . . . . . . 50

Figura 23 – Sinaléticas utilizadas durante a depuração. . . . . . . . . . . . . . . . . 55

Figura 24 – Visualização de dados no JAD . . . . . . . . . . . . . . . . . . . . . . . . 56

Figura 25 – Menu de funcionalidades do JAD . . . . . . . . . . . . . . . . . . . . . . 56

Figura 26 – Erro de sintaxe em Libras. . . . . . . . . . . . . . . . . . . . . . . . . . 57

Figura 27 – Questões Adicionadas à Avaliação de Usabilidade. . . . . . . . . . . . . 62

Figura 28 – Layout e logística do experimento . . . . . . . . . . . . . . . . . . . . . 65

Figura 29 – Código 1 apresentado no JGRASP. . . . . . . . . . . . . . . . . . . . . 67

Figura 30 – Código 2 apresentado no JAD. . . . . . . . . . . . . . . . . . . . . . . . 68

Figura 31 – RM para o JAD com base nas respostas à escala likert para as questões

4 e 10. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

Figura 32 – RM para o JGrasp com base nas respostas à escala Likert para as ques-

tões 4 e 10. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

Figura 33 – Valores de RM submetidos ao teste T de Student. . . . . . . . . . . . . 76

Figura 34 – Contexto de depuração com JGrasp. . . . . . . . . . . . . . . . . . . . 77

Figura 35 – Participante utilizando o recurso de legenda no JAD. . . . . . . . . . . 78

Figura 36 – Participante surdo se beneficiando do recurso de erros em Libras. . . . 79

Figura 37 – Resultado da votação realizada pelos participantes. . . . . . . . . . . . 80

LISTA DE TABELAS

Tabela 1 – Resultados do Teste t Não Pareado . . . . . . . . . . . . . . . . . . . . . 49

Tabela 2 – Recursos de acessiblidade e conformidade com a WCAG 2.0 . . . . . . 58

Tabela 3 – Recursos de Acessibilidade - Comparativo . . . . . . . . . . . . . . . . 58

Tabela 4 – Funcionalidades - Comparativo . . . . . . . . . . . . . . . . . . . . . . 59

Tabela 5 – Resultados para questões que não se utilizou a escala Likert . . . . . . 63

Tabela 6 – Análise crítica a partir do RM para questões com escala Likert . . . . . 64

Tabela 7 – Disponibilização do Código por Turma. . . . . . . . . . . . . . . . . . . 68

Tabela 8 – Média das métricas dos participantes ao utilizar o JAD . . . . . . . . . 70

Tabela 9 – Resultados do teste Mann-Whitney U . . . . . . . . . . . . . . . . . . . 71

Tabela 10 – Sujeitos que corrigiram com sucesso os Erros 01 e 02 . . . . . . . . . . 71

Tabela 11 – Média das Métricas de Tempo e Auxílios . . . . . . . . . . . . . . . . . 72

SUMÁRIO

1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

1.1 MOTIVAÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

1.2 OBJETIVOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

1.2.1 Objetivo Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

1.2.2 Objetivos Específicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

1.3 ORGANIZAÇÃO DO TRABALHO . . . . . . . . . . . . . . . . . . . . . 17

2 FUNDAMENTAÇÃO TEÓRICA . . . . . . . . . . . . . . . . . . . . . . 19

2.1 O APRENDIZADO DE SURDOS . . . . . . . . . . . . . . . . . . . . . . 19

2.2 VISUALIZAÇÃO DA INFORMAÇÃO COMO ESTRATÉGIA PARA SUR-

DOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.3 VISUALIZAÇÃO DA INFORMAÇÃO APLICADA AMBIENTES DE DE-

SENVOLVIMENTO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.3.1 Transformação de dados . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.3.2 Mapeamento Visual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.3.3 Transformações Visuais . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.3.3.1 Testes de Localização . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.3.3.2 Controles de Ponto de Vista . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.3.3.3 Distorções da Imagem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.4 MANIPULAÇÃO DIRETA EM AMBIENTES DE DESENVOLVIMENTO 27

2.5 O USO DA SEMIÓTICA PARA CONSTRUÇÃO DE INTERFACES META-

FÓRICAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

2.6 TÉCNICAS E FERRAMENTAS PARA AVALIAÇÃO DE SOFTWARE . . 31

2.6.1 Análise de Desempenho . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

2.6.2 Avaliação de Usabilidade utilizando o System Usability Scale . . . . . . 31

2.6.3 Análise Competitiva . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3 TRABALHOS RELACIONADOS . . . . . . . . . . . . . . . . . . . . . 35

3.1 JELIOT 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.2 JAVA INTERACTIVE VISUALIZATION ENVIRONMENT - JIVE . . . . 36

3.3 JGRASP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3.4 DELL ACCESSIBLE LEARNING E SEU AMBIENTE DE DESENVOLVI-

MENTO ACESSÍVEL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4 ESTUDOS PRÉVIOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.1 COMO ALUNOS DE PROGRAMAÇÃO SDA E NÃO SDA EXECUTAM A

DEPURAÇÃO DE UM CÓDIGO . . . . . . . . . . . . . . . . . . . . . . . 43

4.1.1 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4.1.2 Perfil dos participantes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4.1.3 O procedimento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4.1.4 O procedimento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4.1.5 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.1.6 Conclusões do estudo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.2 DEPURADORES VISUAIS E PROGRAMADORES SDA . . . . . . . . . 47

4.2.1 Participantes e Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . 48

4.2.2 Resultados e discussões . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

5 JAVA ACCESSIBLE DEBUGGER -JAD . . . . . . . . . . . . . . . . . . 52

5.1 ARQUITETURA DA FERRAMENTA . . . . . . . . . . . . . . . . . . . . 52

5.2 A ENGENHARIA SEMIÓTICA APLICADA AO JAD POR MEIO DE

INTERFACES METAFÓRICAS E VISUALIZAÇÃO DA INFORMAÇÃO . 53

5.3 OS RECURSOS DE ACESSIBILIDADE DO JAD . . . . . . . . . . . . . . 57

6 EXPERIMENTOS APLICADOS AO JAD . . . . . . . . . . . . . . . . 60

6.1 TÉCNICAS E FERRAMENTAS UTILIZADAS . . . . . . . . . . . . . . . 60

6.2 PERFIL DOS PARTICIPANTES . . . . . . . . . . . . . . . . . . . . . . . 62

6.3 INFRAESTRUTURA E MÉTODO DE APLICAÇÃO . . . . . . . . . . . . 65

6.4 PROBLEMAS OCORRIDOS . . . . . . . . . . . . . . . . . . . . . . . . . 68

7 RESULTADOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

7.1 ANÁLISE QUANTITATIVA . . . . . . . . . . . . . . . . . . . . . . . . . 70

7.1.1 Comparativo de Desempenho SDA x não-SDA utilizando o JAD . . . . . 70

7.1.2 Comparativo de Desempenho JAD x JGrasp . . . . . . . . . . . . . . . . 71

7.1.3 Comparativo de Avaliação de Usabilidade JAD x JGrasp . . . . . . . . . 72

7.1.3.1 Análise das Questões 4 e 10 do Questionário SUS . . . . . . . . . . . . . . 73

7.1.3.2 Análise das Questões Acrescidas ao Questionário SUS . . . . . . . . . . . . 74

7.1.3.2.1 Resultados para o JAD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

7.1.3.2.2 Resultados para o JGrasp . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

7.1.3.2.3 Comparativo JAD x JGasp . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

7.2 CAPTURA DE TELA E ANÁLISE CRÍTICA . . . . . . . . . . . . . . . . 77

7.3 ANÁLISE QUALITATIVA . . . . . . . . . . . . . . . . . . . . . . . . . . 79

8 CONCLUSÕES E TRABALHOS FUTUROS . . . . . . . . . . . . . . . 81

REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

APÊNDICES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

APÊNDICE A – Depoimentos . . . . . . . . . . . . . . . . . . . . . . . . 89

A.1 FEEDBACK DOS PARTICIPANTES SOBRE O JAD . . . . . . . . . . . . 89

A.1.1 Participantes SDA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

A.1.2 Participantes não SDA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

A.2 FEEDBACK DOS PARTICIPANTES SOBRE O JGRASP . . . . . . . . . . 94

A.2.1 Participantes SDA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

A.2.2 Participantes não SDA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

APÊNDICE B – Formulário de Observação . . . . . . . . . . . . . . . . . 101

APÊNDICE C – Questionário de Perfil Socioeducativo . . . . . . . . . . . 102

APÊNDICE D – Termo de Consentimento Livre e Esclarecido . . . . . . . 104

15

1 INTRODUÇÃO

1.1 MOTIVAÇÃO

O Censo de 2010 realizado pelo IBGE (Instituto Brasileiro de Geografia e Estatística)

aponta que 9,7 milhões de brasileiros possuem deficiência auditiva, representando 5,1% da

população brasileira (INSTITUTO BRASILEIRO DE GEOGRAFIA E ESTATíSTICA, 2010).

Entre a população de deficientes auditivos apontada pelo IBGE, estão os grupos de sujeitos

parcialmente surdos (pessoas com surdez leve e moderada) e os grupos de surdos (pessoas com

surdez severa e profunda). Segundo Oliveira (2001), os sujeitos com surdez severa e profunda

podem apresentar dificuldades na escrita, caso não possuam uma educação adequada.

Uma das grandes dificuldades enfrentadas por Pessoas com deficiência (PCD) é

o acesso ao mercado de trabalho. A contratação deles em postos de trabalho dentro de uma

empresa tem sido motivada pela mudança na legislação. Em um primeiro momento, o processo de

incorporação de um PCD por empresas é visto como um grande desafio, repleto de dificuldades

a serem enfrentadas.

O mercado de desenvolvimento de software cresce significativamente no Brasil e

apresenta grandes oportunidades para jovens programadores. O número de vagas aumentou

44,2% em 2015 e estima-se um aumento de 30% em 2016, apesar da atual crise econômica

(ZOGBI, 2016). Esse fato, mostra uma oportunidade para que PCDs ingressem no mercado de

trabalho, porém eles ainda têm como barreira a formação profissional.

Uma das grandes dificuldades das empresas consiste em captar PCD com uma

boa formação profissional, pois alguns tipos de deficiência, como a surdez, tornam o acesso à

informação e conteúdos didáticos restrito em razão da dificuldade de compreensão da língua

utilizada.Pessoas SDA têm como sua língua nativa a Língua Brasileira de Sinais (Libras).

Toscano, Dizeu e Caporali (2005), relatam que pessoas com níveis de surdez severa e profunda

adquirem desde criança a linguagem de sinais de forma natural e espontânea para se comunicar.

Como consequência, alunos SDA têm sua formação tradicional comprometida, já que os materiais

didáticos são, via de regra, aqueles preparados para alunos ouvintes.

O programador surdo Peter (2012) relata em seu artigo que encontrou inúmeras

dificuldades ao ingressar no Instituto Rochester de Tecnologia de Nova York. Logo ao tentar

aprender uma linguagem de programação, descobriu que grande parte dos tutoriais, vídeos

entre outras ferramentas não atendiam às suas necessidades, pois não eram adaptados a sua

16

realidade, dessa forma seguir carreira de programador tornou-se uma árdua tarefa. Assim como

esse exemplo, diversos SDA possuem suas limitações para acessar a conteúdos específicos ainda

não adaptados à sua realidade.

Problemas como os apontados por Peter (2012) também foram identificados pelo

autor durante sua experiência com tutoria durante a aplicação do curso de Java Básico oferecido

pelo Laboratório de Educação a Distância para Pessoas com Deficiência (Le@d). O curso é uma

iniciativa de uma multinacional do ramo de informática e a Universidade Estadual do Ceará. Esta

parceria firmada entre instituição pública e privada tem como objetivo pesquisar e desenvolver

soluções de ensino a distância que aumentam a empregabilidade de pessoas com deficiência. O

Le@d produz e oferece cursos de Educação à Distância (EAD) acessíveis relacionados à área de

Tecnologia da Informação (TI) através de um Sistema de Gestão de Aprendizagem Acessível

(SGAA). Os cursos abrangem mais de 900 horas de formação (DELL INC., 2017). Foi percebido

que os alunos SDA apresentavam dificuldade para compreender e manipular um Ambiente de

Desenvolvimento Integrado (IDE do inglês integrated development environment), principalmente

em relação ao processo de depuração de código.

A experiência de trabalho vivida pelo autor, lhe possibilitou conhecer as barreiras

que SDA encontram para a formação profissional e o uso de tecnologias. Durante a aplicação

dos cursos de lógica de programação e Java, percebeu-se o alto grau de dificuldade no manuseio

de ferramentas e compreensão da abstração em algoritmos. Isso motivou a investigação dos

fatores críticos durante as atividades práticas de programação de durante o curso de Java.

Esta dissertação apresenta uma série de estudos experimentais, entre eles um estudo

comparativo entre SDA e não SDA, onde pode-se verificar que SDA possuem um desempenho

inferior a não SDA durante a depuração de código Java utilizando uma ferramenta tradicional

(Eclipse)(NASCIMENTO; OLIVEIRA; FREITAS, 2014). Com isto, buscou-se alternativas

para atenuar essa diferença, entre elas está o uso de depuradores visuais. A decisão de utilizar

depuradores visuais foi embasada em estudos que apontam o quanto representações visuais

causam impacto positivo no desempenho de resolução de problemas matemáticos para os alunos

SDA (BLATTO-VALLEE et al., 2007), com isto, tomamou-se como hipótese que o mesmo

poderia ocorrer na depuração de código, dada a necessidade de um raciocínio lógico, assim

como em problemas matemáticos. Foram realizadas análises situadas de grupos de alunos SDA

utilizando depurador visual e outro grupo com um depurador tradicional, identificou-se que

aqueles que utilizaram o depurador visual tiveram melhores resultados de desempenho em relação

ao grupo que utilizou o depurador tradicional. Realizou-se também uma avaliação de usabilidade,

17

apontando resultados positivos e superiores para o depurador visual (NASCIMENTO et al.,

2015).

Os resultados motivaram a propor o Java Accessible Debugger (JAD), um depurador

acessível para código Java, criado com base nas análises experimentais entre grupos de SDA e

não SDA, propondo modelos de interação e ferramentas que auxilie alunos SDA a elevar seu

desempenho durante o processo de programação e depuração de código. A ferramenta proposta é

composta por uma série de recursos visuais metafóricos, fazendo uma analogia entre a depuração

de código e o trânsito, valorizando a experiência do usuário com objetivo de aliviar a carga

cognitiva durante a evolução de um código Java.

1.2 OBJETIVOS

1.2.1 Objetivo Geral

Desenvolver um depurador visual acessível, aplicando o conceito de interfaces

metafóricas, de forma que, SDA e não SDA possam ter o mesmo nível de aprendizado e

produtividade na depuração de código.

1.2.2 Objetivos Específicos

a) Realizar um estudo comparativo do desempenho de SDA e ouvintes durante a

depuração de um código Java.

b) Estudar os impactos nos indicadores de performance dos SDA quando esses se

utilizarem de depuradores visuais

c) Propor, construir e avaliar uma ferramenta de depuração de código acessível com

base nos estudos realizados.

1.3 ORGANIZAÇÃO DO TRABALHO

No capítulo 1 apresenta-se a introdução apontando a motivação e os objetivos

buscados. No capítulo 2 aborda-se a fundamentação teórica necessária para compreensão dos

conceitos abordados nos capítulos posteriores, nele apresentamos estudos sobre o aprendizado

de SDA, visualização da informação como uma estratégia para SDA, visualização da informação

aplicada a IDE, manipulação direta e IDE, o uso da semiótica para construção de interfaces

metafóricas e técnicas e ferramentas para avaliação de software. No capítulo 3 apresentam-se

18

alguns trabalhos, mostrando técnicas e ferramentas importantes relacionadas a este trabalho.

No capítulo 4 apresentam-se os experimentos realizados durante a pesquisa, apresentando

metodologias, técnicas e resultados apontados pelos estudos. No capítulo 5 apresenta-se o JAD,

explorando sua arquitetura, funcionalidades e os recursos de acessibilidade. No capítulo 6 são

apresentadas as metodologias e técnicas utilizadas para o experimento aplicado ao JAD, e por fim

nos capítulos 7 e 8 são abordados os resultados para o experimento e conclusões deste trabalho,

respectivamente.

19

2 FUNDAMENTAÇÃO TEÓRICA

Neste capítulo são apresentados os fundamentos para a realização da pesquisa,

levantando as problemáticas e as possíveis soluções para os problemas apontados. Serão

abordados os problemas em relação ao aprendizado de SDA, além de estudos que apontam

depuradores visuais como uma possibilidade para melhorar o desempenho no aprendizado e

desempenho durante o processo de depuração e desenvolvimento de códigos Java, durante as

oficinas de aprendizagem.

Na seção 2.1, é discutida a problemática do aprendizado de SDA em relação aos não

SDA. Na seção 2.2 aponta-se o uso de representações visuais como um forte preditor para que

SDA possam compreender melhor o comportamento de programas em tempo de execução. Nas

seções 2.3 e 2.4, são apresentados respectivamente os conceitos de visualização da informação e

manipulação aplicado à IDE. Por fim, na seção 2.6 são apresentadas as técnicas e ferramentas

para avaliação das ferramentas utilizadas para os estudos experimentais.

2.1 O APRENDIZADO DE SURDOS

Pesquisas apontam que alunos SDA possuem desempenho acadêmico inferior quando

comparados com os seus homólogos auditivos (não SDA) em todos os ambientes educacionais

(NOGUEIRA; ZANQUETTA, 2009). Bull, Blatto-Vallee e Fabich (2006) mostra que alunos

SDA apresentam maior dificuldade na absorção de conceitos matemáticos, quando comparados

aos não SDA. No entanto, a perda de audição pode não estar na origem do problema. Nunes

e Moreno (1998) argumentam que o mau desempenho matemático parte de um fator de risco

relacionado com o tempo, o tipo de instrução e oportunidades de aprendizagem oferecidas para o

aluno surdo. Para corroborar essa linha de pensamento, ??) mostraram que de 3 a 4 anos de idade,

as crianças SDA têm habilidades espaciais e temporais comparáveis com os seus colegas ouvintes

com a mesma idade e ainda melhores habilidades numéricas espaciais (??). Barbosa (2013)

argumenta que nas funções cognitivas menos dependentes de estímulos linguísticos, crianças

SDA e não SDA parecem ter desempenho similar. boroditsky2011language argumenta que

pessoas bilíngues mostram divergência sobre o mesmo assunto quando é necessário discuti-lo

nos dois idiomas. Essa mudança na língua também causa impacto na memória. Finalmente, o

autor postula que “a linguagem molda mesmo as dimensões mais fundamentais da experiência

humana como espaço, tempo, causalidade e relacionamentos com os outros”.

Muitos materiais didáticos e softwares foram pensados para uma cultura ouvinte,

20

dessa forma, sujeitos SDA precisam de um esforço maior para entender um conteúdo ou até

mesmo para se adaptar ao funcionamento de um software. Para Perlin (2004), a “ cultura ouvinte

” é essencialmente composta de sinais auditivos que SDA não usam que, por sua vez, utilizam-se

de sinais visuais para compreender o mundo ao seu redor. Não é só a falta de material didático

adequado, a Língua Brasileira de Sinais (Libras) foi legalizada recentemente, e portanto algumas

expressões de áreas específicas ainda não foram convencionadas para tal língua.

2.2 VISUALIZAÇÃO DA INFORMAÇÃO COMO ESTRATÉGIA PARA SURDOS

Blatto-Vallee et al. (2007) apontam que o uso de representações esquemáticas visuais-

espaciais é um forte preditor positivo do desempenho de resolução de problemas matemáticos

para os alunos SDA. Para Pinto, Gomes e Nicot (2014), a visualização parece representar, para

o surdo, o principal canal de esquemas de pensamento e de processamento que naturalmente

permitem a aquisição, construção e expressão do conhecimento, valores e experiências que

de outra forma seria incomunicáveis. O canal visual permite a leitura do mundo surdo e é o

apoio do seu processamento mental. Os autores relatam melhora na auto estima, no interesse e

engajamento entre os SDA, quando desenhos, imagens manipuláveis e visuais foram usadas no

ensino de Ciências, Geografia, Artes e História .

Embora existam vários depuradores de Java visuais,não encontrou-se nenhum teste

realizado com os SDA. Antes de prosseguir com a discussão dos depuradores Java visuais

disponíveis, deve-se advertir que usuários SDA registram menos informação em sua memória

de curto prazo quando comparados aos não SDA (BAVELIER; DYE; HAUSER, 2006). Isso

pode ser parcialmente devido à natureza visual-espacial da informação necessária para o SDA

(WILSON; EMMOREY, 2006).

Em uma pesquisa recente, Sorva, Karavirta e Malmi (2013) apontam que nas últimas

três décadas, dezenas de sistemas de software foram desenvolvidos para programadores iniciantes

cujo objetivo é ilustrar o comportamento em tempo de execução de programas. Contudo, é

importante analisar alguns pontos quando se trata de usuários SDA: não sobrecarregar o modo

visual, oferecer ao programador a portabilidade e flexibilidade suficientes para ser usado em

diferentes configurações e locais de trabalho, além de oferecer interface intuitiva com recursos

de acessibilidade.

21

2.3 VISUALIZAÇÃO DA INFORMAÇÃO APLICADA AMBIENTES DE DESENVOLVI-

MENTO

Segundo Nascimento (2012), visualização da informação (INFOVIS) trata-se da

construção de representações visuais de dados abstratos de forma a facilitar o entendimento e/ou

ajudar na descoberta de novas informações, além de auxiliar o entendimento de determinado

assunto, o qual, sem uma visualização, exigiria maior esforço cognitivo. Card, Mackinlay e

Shneiderman (1999) apresentam um modelo de referência para construir uma visulização da

informação. Como mostra a Figura 1, esse modelo é divido em três etapas para gerar uma imagem

a partir de um conjunto de dados:transformação de dados, mapeamento Visual e transformações

visuais, tais etapas são detalhadas nas subseções 2.3.1, 2.3.2, 2.3.3.

Figura 1 – Modelo de Referência para Visualização.

Fonte: Card, Mackinlay e Shneiderman (1999).

2.3.1 Transformação de dados

A Figura 2 apresenta uma tabela de dados do Java Code Coverage (JCC), sendo

esta uma ferramenta integrada ao Eclipse para cobertura de testes caixa branca (REITZ; CAS-

TIÑEIRA; SCHUHMACHER, 2015). É possível observar como os dados estão estruturados em

uma tabela, servindo como base para representações visuais. Essa é a etapa em que os dados

são organizados de forma lógica. Deve-se atentar para eliminação de redundâncias, além de

acréscimo de informações, como no caso de resultados estatísticos, entre outras informações que

podem ser geradas a partir dos dados coletados. A ferramenta JCC, embora apresente alguns

22

Figura 2 – Tabela de resultados da cobertura de código, ela mostra os resultados da

qualidade da cobertura de código disponível como uma porcentagem e como

uma barra de progresso.

Fonte: Reitz, Castiñeira e Schuhmacher (2015).

gráficos, não da suporte para diferentes perspectivas de visualização, para isso, é necessário

utilizar outros tipos de plug-ins.

2.3.2 Mapeamento Visual

Alexandre e Tavares (2007) conceituam o mapeamento visual como a associação

entre os dados e representações gráficas adequadas, construindo uma estrutura visual que

represente os dados de uma tabela. Na Figura 3, é apresentado um exemplo desta técnica

aplicada à visualização da cobertura do JCC. Para isso é utilizado um plug-in chamado Codmap,

que tem como objetivo fornecer aos desenvolvedores um modelo mental compartilhado, espacial

e estável de projetos de software (KUHN; ERNI; NIERSTRASZ, 2010). Ele utiliza várias

técnicas para aliviar a carga cognitiva durante a visualização e navegação por pacotes e classes.

Esta fase é considerada crucial para uma visualização, pois nela são assinalados

os requisitos de percepção humana que deverão ser considerados. O grau de dificuldade do

mapeamento aumenta proporcionalmente ao número de atributos associados aos dados. A escolha

de representações gráficas que considerem adequadamente princípios de percepção humana não é

uma tarefa fácil, principalmente na visualização de dados abstratos (ALEXANDRE; TAVARES,

2007).

A visualização dos dados em forma de modelos representativos auxilia na percepção

da informação, porém, existe uma outra etapa da INFOVIS essencial para visualizar as diversas

23

Figura 3 – Mapa cartográfico da distribuição dos pacotes, apresentando em verde os

resultados da qualidade da cobertura de código realizada pelo JCC.

Fonte: Kuhn, Erni e Nierstrasz (2010).

perspectivas de resultados que os dados podem nos dar. Esta etapa é chamada de transformações

visuais e possui várias técnicas de transformações que permitem ao usuário outras perspectivas

de resultados.

2.3.3 Transformações Visuais

Nessa etapa é possível modificar e estender as estruturas visuais de forma interativa

por meio de algumas operações. Para isso são utilizadas algumas técnicas mostradas a seguir.

24

2.3.3.1 Testes de Localização

Os testes de localização possibilitam ao usuário obter informações adicionais sobre

um item. Na Figura 4, é apresentado um mapa de calor usado pelo Codmap para rastrear os

locais visitados pelo programador durante o desenvolvimento de seus códigos Java (KUHN;

ERNI; NIERSTRASZ, 2010). O arquivo atualmente ativo é indicado por um rótulo de texto

contendo o nome da classe e os arquivos abertos são marcados com um ícone que representa o

seu tipo. Ao clicar sobre a imagem de um arquivo, ele é aberto no editor de código do Eclipse.

Figura 4 – Visualização do Codmap para arquivos de classes visitados por

programadores durante o desenvolvimento de um sistema.


2.3.3.2 Controles de Ponto de Vista

Com esta técnica é possível ampliar, reduzir e deslocar uma imagem para oferecer

diferentes tipos de visão para o usuário. Na Figura 5, a paisagem gerada pelo Codemap apresenta

diferentes perspectivas de visualização. Nela o mesmo projeto é exibido de 4 formas diferentes:

25

a apresentação padrão é exibida no canto superior esquerdo; por pacotes, no canto superior

direito; mapa de calor, no canto inferior esquerdo; e por cobertura de testes, no canto inferior

direito.

Figura 5 – Perspectivas de visualização do Codmap.


2.3.3.3 Distorções da Imagem

Como é possível observar na Figura 6, essa técnica consiste em ampliar uma região

específica em detrimento de outra sem a perda do contexto. A ferramenta Sublime Text é

utilizada para edição de códigos de HyperText Markup Language (HTML) e linguagens de

programação. Sua interface possui um recurso para visão geral do código no canto direito da

26

tela permitindo ao desenvolvedor visualizar toda a estrutura de seu código sem perder o foco do

editor (SKINNER, 2013)

27

Figura 6 – Sublime Text.

Fonte: Skinner (2013).

Os exemplos citados, mostram que as técnicas de INFOVIS estão cada mais vez

presentes em ambinetes de desenvolvimento, permitindo aos usuários uma experiência de

interação intuitiva e consequentemente diminuindo a demanda cognitiva. Desta forma, o usuário

poderá focar mais na ação de interesse e não na operação do sistema. Com os exemplos

citados neste capítulo, é possível observar que a INFOVIs tem se tornado um caminho para que

programadores tenham mais produtividade no desenvolvimento de sistemas. Na próxima seção

será abordado o conceito de manipulação direta, outra técnica da interação homem-máquina que

está muito ligada a INFOVIS, pois ambas tratam de objetos visuais em uma interface que auxilia

usuários a ter uma melhor experiência de uso do sistema. Elas são amplamente utilizadas em

IDE, com o objetivo de melhorar a produtividade e prevenção ao erro de programadores.

2.4 MANIPULAÇÃO DIRETA EM AMBIENTES DE DESENVOLVIMENTO

Rose, Plaisant e Shneiderman (1995) definem manipulação direta como uma técnica

para representar interfaces que apresentam representação contínua de objetos e ações físicas

sobre eles, possibilitando operações rápidas, incrementais e reversíveis em vez de comandos e

sintaxe complexa. Dessa forma, o usuário pode visualizar e acompanhar sua ação sobre o objeto

de forma rápida e intuitiva. De acordo com Hutchins, Hollan e Norman (1985), a manipulação

28

direta consiste em interfaces visuais em que os usuários operam em uma representação de

objetos de interesse. Esse modelo usa a visibilidade e ações sobre os objetos produzindo

diferença significativa na produtividade em interação com os sistemas (ROSE; PLAISANT;

SHNEIDERMAN, 1995). Como mostrado na Figura 7, essa técnica é muito utilizada em IDE

para que programadores possam criar interfaces apenas arrastando os componentes para o campo

de edição, gerando o código automativamente, e assim, ter mais produtividade na construção de

seus código-fontes.

Figura 7 – WindowBuilder é um plug-in para Eclipsee permite criar interfaces gráficas

apenas arrastando componentes para a tela de edição.

Fonte: Skinner (2013).

Em alguns estudos realizados por Moreno e Joy (2007), os resultados mostram que

as interfaces com essas características permitem ao usuário um melhor domínio da interface,

melhor desempenho na realização de tarefas, facilidade de aprendizado em funções básicas ou

avançadas, confiança de que continuarão a dominar a interface mesmo ao parar de usá-la por um

tempo, satisfação do usuário, vontade de ensinar os outros e desejo de explorar funções mais

avançadas do sistema.

Algumas IDE têm aplicado não só o conceito de manipulação direta, mas também o

conceito de visualização da informação, fazendo com que tarefas complexas como depurar um

29

código sejam mais simples e intuitivas. Moreno e Joy (2007) dizem que por causa da facilidade

de utilização desses instrumentos, eles são destinados para as fases iniciais de um processo

de aprendizagem de programação de computadores.A estratégia é fazer com que os objetos e

valores sejam visíveis e manipuláveis graficamente.

A manipulação direta é aplicada também à lógica de programação por meio da

programação visual. As linguagens que utilizam-se deste conceito se apropriam de componentes

gráficos que representam os comandos da linguagem, construindo a lógica arrastando os compo-

nentes e ajustando conforme a execução desejada. Esse tipo de programação pode minimizar

problemas como configuração de ambiente, sintaxe e compilação, sendo estes os problemas

mais enfrentados no ensino-aprendizagem de lógica de programação (BRANDÃO; BRANDÃO;

RIBEIRO, 2012).

Cypher e Halbert (1993) mostram em seu trabalho que os conceitos de manipulação

direta aplicada a IDE podem gerar produtividade para desenvolvedores, pois ajudam no desenvol-

vimento da lógica, materializam algo abstrato, diminuem a carga cognitiva para a interpretação

da lógica matemática e também permitem a implementação da lógica computacional para o

desenvolvimento de algoritimos. SDA são muito visuais (GESUELI; MOURA, 2006), e é

razoável assumir que uma IDE com essas características trará impactos positivos para esses

indivíduos.

2.5 O USO DA SEMIÓTICA PARA CONSTRUÇÃO DE INTERFACES METAFÓRICAS

Semiótica é a ciência que estuda a comunicação e cultura, apontando que conheci-

mento e cultura são manifestados e compartilhados em uma sociedade por meio de símbolos

(LEITÃO; SILVEIRA; SOUZA, 2013). Para Leite (1998), a metáfora utiliza-se do conceito de

semiótica para representações metafóricas utilizando convenções culturais.

Segundo Oliveira (2012), o uso de analogias e metáforas é algo bem recorrente no

ensino de ciências, facilitando o compreensão de conceitos com alto grau de abstração. Como

aponta Cury et al. (2008), o uso de metáforas aplicado às interfaces gráficas surgiu, à medida que

que os computadores foram se tornando aparelhos de uso pessoal, não mais voltado apenas para

o uso acadêmico, as dificuldades de interação com sistemas por meio de linguagens nativas como

linhas de comando tiveram que ser superadas por interfaces gráficas. “Interface é um dispositivo

físico ou lógico entre duas partes de um mesmo sistema, com características apropriadas que

permitem trocas de informação entre elas” (NIUZA, 2008). A partir de então, diversas analogias

30

foram criadas com intuito de tornar a experiência de uso de sistemas interativos mais intuitiva e

mais próxima da realidade dos usuários.

Os elementos visuais possuem forte influência para comunicação entre o usuário e

máquina, sendo o processo de comunicação visual análogo à comunicação verbal. Niuza (2008)

apresenta em seu estudo os processos de comunicação visual e verbal, fazendo um paralelo entre

as duas, como é mostrado na Figura 8.

Figura 8 – Paralelo entre comunicação visual e verbal.

Fonte: Niuza (2008).

Na Figura 8 são apresentados os seguintes paralelos:

• Os ícones (imagem gráfica para representar uma função) correspondem aos vocábulos

(elementos que fazem parte de uma língua).

• O elemento visual (ícone) corresponde às palavras em um conversa.

• Ambos ícones e palavras possuem um conteúdo semântico.

• O conteúdo semântico está ligado a uma imagem metafórica, assim como o sentido

31

figurado está para palavras.

• Imagens metafóricas são utilizadas para a abstração lógica, enquanto o sentido figurado é

utilizado para comparações implícitas.

Com isso, pode-se perceber o quão importante é o uso de elementos visuais metafó-

ricos na construção de uma interface, pois os mesmos estão diretamente ligados ao processo de

comunicação entre o homem e a máquina, tornando possível substituir comandos por elementos

visuais próximos à realidade do usuário, tornando a experiência de uso mais amigável e intuitiva.

2.6 TÉCNICAS E FERRAMENTAS PARA AVALIAÇÃO DE SOFTWARE

2.6.1 Análise de Desempenho

A análise de desempenho durante o uso de um sistema interativo é realizada com base

nos resultados obtidos a partir da observação de uso do sistema para realização de determinadas

tarefas. Durante o processo de observação, podem ser coletados os seguintes dados: tarefas

realizadas, total de erros cometidos, quantificar os tipos de erros separadamente, tempo necessário

para concluir a tarefa e o número de auxílios solicitados (BARBOSA; SILVA, 2010). Um exemplo

prático da aplicação dessa técnica, é o estudo de desempenho de usuários SDA e não SDA durante

a tarefa de evolução de um código Java, comparando os resultados de desempenho de uso do

JGrasp (IDE disponível no mercado) e JAD (ferramenta proposta neste trabalho, apresentada no

capítulo 5), sendo estas ferramentas utilizadas para o desenvolvimento de códigos Java.

2.6.2 Avaliação de Usabilidade utilizando o System Usability Scale

A Escala de Usabilidade System Usability Scale (do inglês, SUS) é uma ferramenta

utilizada para medição de usabilidade. Ela consiste em um questionário composto por 10

(dez) questões com cinco opções de resposta (SAURO; LEWIS, 2012). Para cada questão é

utilizada uma escala Likert variando de 1 (discordo fortemente) a 5 ( concordo fortemente) como

apresentado na Figura 9.

Esse questionário produz um único número que representa uma medida composta da

usabilidade geral do sistema a ser estudado. Note-se que os escores de itens individuais não são

significativos por conta própria. O cálculo deve ser realizado da seguinte forma:

• Para os itens 1, 3, 5, 7 e 9 e a pontuação é a posição na escala menos 1.

• Para os itens 2, 4, 6, 8 e 10, a pontuação é de 5 menos a posição na escala.

32

Figura 9 – Questionário System Usability Scale.

Fonte: Brooke (1996).

• Você deve fazer um somatório das pontuações de cada item.

• Multiplicar a soma das pontuações por 2,5 para obter o valor global.

Pesquisas apontam que uma escala acima de 68 pode indicar que o grau de usabi-

lidade está acima da média, consequentemente números abaixo deste valor são considerados

abaixo da média (SAURO; LEWIS, 2012). É possível, por meio de normalização, dividir os

resultados em categorias, como é mostrado na Figura 10

33

Figura 10 – Gráfico de associação de percentuais à pontuação do SUS categorizando os

graus em letras.

Fonte: Sauro e Lewis (2012).

Sauro e Lewis (2012) apontam que pode-se, com os resultados, chegar às seguintes

conclusões:

• 80.3 ou superior é um A: As pessoas adoram o site e recomendam aos seus amigos.

• 68 ou aproximado é um C: Está fazendo certo, mas poderia melhorar.

• 51 ou aproximado é um F: Deve-se fazer da usabilidade uma prioridade e corrigir os

problemas.

O SUS foi concebido para medir a facilidade de uso, ou seja, uma única dimensão,

porém, pesquisas mostram que ele fornece uma medida global de satisfação do sistema e pode

também fornecer subescalas de usabilidade e capacidade de aprendizado. Os itens 4 e 10 do

questionário fornecem a dimensão da capacidade de aprendizado e os outros 8 itens fornecem

a dimensão usabilidade. Com isso, é possível acompanhar os resultados para escala global e

também para as subescalas (LEWIS; SAURO, 2009).

2.6.3 Análise Competitiva

“A análise competitiva consiste em examinar produtos com funcionalidades seme-

lhantes ou complementares” (BARBOSA; SILVA, 2010). Essa análise está entre o conjunto de

atividades propostas por Nielsen e Landauer (1993) para engenharia de usabilidade.

A análise competitiva de sistemas, se dá pela inspeção de funcionalidades e questões

34

de IHC em sistemas semelhantes com objetivo de obter um conjunto de informações sobre os

pontos fortes e fracos dos sistemas, analisando o que pode ser aperfeiçoado.

Essa técnica pode ser aplicada a protótipos, porém, segundo Barbosa e Silva (2010)

ela se torna mais eficaz quando aplicada a sistemas prontos, pois com as funcionalidades e

interface desenvolvidas será possível analisar tanto questões de interação como as questões

de designer junto ao usuário. Dessa forma será possível analisar o que funciona e o que não

funciona nos sistemas, apontando pontos importantes de aperfeiçoamento.

Para construção do JAD, realizou-se uma análise competitiva entre dois depuradores

de IDE disponíveis no mercado (Eclipse e Jgrasp). Além de validar a hipótese de que depuradores

visuais seriam uma saída para que alunos SDA pudessem depurar seus códigos com mais

produtividade,isso nos permitiu levantar requisitos para construção do JAD com base em análise

de problemas e acertos de cada ferramenta em relação à interface e à interação com o sistema

(NASCIMENTO et al., 2015).

35

3 TRABALHOS RELACIONADOS

Depuradores visuais implementam, pela sua concepção, as estratégias de manipula-

ção direta. Nessa seção, apresentamos vários depuradores visuais, além de discutir brevemente

como a implementação dessas estratégias trouxe benefícios aos alunos e programadores.

3.1 JELIOT 3

O Jeliot 3 (MORENO; JOY, 2007) é uma ferramenta concebida para o aprendizado

de programação procedural ou orientada a objetos. Sua principal característica é a visão total

ou parcial de códigos-fonte e fluxos de controle. Com essa ferramenta, os estudantes podem

desenvolver e, ao mesmo tempo, ver a representação visual de um código em execução. Durante o

processo de depuração e visualização, os estudantes adquirem um modelo mental de computação

que ajuda a compreender melhor a construção do programa. O layout da ferramenta é dividido

em quatro partes: métodos, constantes, área para avaliação de expressão e área de ocorrência,

como apresentado na Figura 11.

Figura 11 – Jeliot 3 Interface.

Fonte: Moreno e Joy (2007).

36

Esse programa procura ser o mais consistente possível, a fim de reduzir a carga

cognitiva dos alunos durante a aprendizagem (MORENO; JOY, 2007). Embora essa ferramenta

exiba uma depuração de objetos visuais, em uma avaliação crítica percebe-se que ela tem uma

série de representações e diagramas que poderiam confundir o usuário. Diagramas complexos

facilmente tornam-se confusos e difíceis de ler. Estudos mostram que as abordagens gráficas são

mais eficientes quando a tarefa requer o reconhecimento de padrões, mas não quando o campo

visual é muito cheio de objetos e a tarefa exige informação detalhada (GRACIANO, 2007).

3.2 JAVA INTERACTIVE VISUALIZATION ENVIRONMENT - JIVE

Segundo Cattaneo et al. (2004), o Jive é uma ferramenta de execução interativa,

desenvolvida pelo Departamento de Ciência e Engenharia da Computação pela Universidade

de Buffalo. Esse sistema é utilizado para a depuração de programas em Java com visualização

da estrutura do objeto e interações entre os métodos, facilitando a manutenção do software e

fornecendo informações sobre o comportamento dinâmico do programa. Ele foi originalmente

projetado como uma aplicação Java autônoma. Recentemente ele foi redesenhado para a

plataforma Eclipse e é composto por um conjunto de plug-ins e recursos. Sua distribuição é feita

por meio do gerenciador de atualização Eclipse. Ele oferece dois principais pontos de vista para

mostrar a execução de um código Java, sendo estes a exibição do diagrama de objeto e diagrama

de sequência, como apresentado nas Figuras 12 e 13.

37

Figura 12 – Visualização com Diagrama de Objetos.

Fonte: Cattaneo et al. (2004).

Figura 13 – Visualização com Diagrama de Sequência.

Fonte: Cattaneo et al. (2004).

38

A compreensão do processo de execução requer um conhecimento prévio dos dia-

gramas citados, o que pode gerar para os estudantes e programadores maior carga cognitiva e

tirar o foco da estrutura lógica para os conceitos relacionados aos diagramas.

3.3 JGRASP

JGRASP é uma IDE desenvolvida para fornecer visualizações dinâmicas e ilustrativas

de estruturas de dados e objetos em Java (CROSS; HENDRIX; UMPHRESS, 2004). Esses

pontos de vista são gerados automaticamente e sincronizados com as estruturas de dados do

código-fonte. O usuário pode percorrer o código no modo de depuração ou desenvolvimento.

Essa integração permite um único ambiente para o aprendizado. O uso dessa IDE em sala de

aula tem sido um fator importante para o ensino de alunos que lidam com programação orientada

a objetos e estruturas de dados. Estudos realizados com os alunos indicam que a ferramenta pode

ter um impacto positivo no aprendizado da lógica de programação (CROSS et al., 2007).

Os alunos foram mais produtivos e mais capazes de detectar e corrigir erros usando

JGrasp (LEAL, 2014). Ela utiliza Java Swing, que implementa partes do API Java Accessibility.

Isso permite que alguns elementos estejam disponíveis para as tecnologias assistivas. Os

elementos incluem: texto do código-fonte, texto de outros componentes de interface do usuário e

um texto alternativo para componentes gráficos. Ele também produz código-fonte e pontos de

vista em tempo de execução (CROSS; HENDRIX; UMPHRESS, 2004). Entre outros depuradores

visuais pesquisados, pode-se identificar que essa ferramenta utiliza a técnica de manipulação

direta, fazendo com que ela se destaque entre as demais citadas no presente trabalho.

A técnica de manipulação direta se aplica na forma de visualização dos objetos. Com

o mouse, é possível arrastar um objeto ou estrutura para uma tela de apresentação, ilustrando o

objeto de uma forma mais clara e próxima da realidade do usuário, como é mostrado na Figura

14. Essa ferramenta inspirou a construção do Java Accessible Degugger, proposto neste trabalho,

trazendo para o JAD os conceitos de manipulação direta e visualização da informação adotados

por ela. Os grandes diferenciais do JAD, em relação ao JGrasp são: a mobilidade da ferramenta,

pois se trata de uma aplicação web, a metáfora utilizada para o visual e processo depuração, os

recursos de acessibilidade e interatividade disponíveis para o usuário.

39

Figura 14 – JGrasp Interface.

Fonte: Cross, Hendrix e Umphress (2004).

3.4 DELL ACCESSIBLE LEARNING E SEU AMBIENTE DE DESENVOLVIMENTO

ACESSÍVEL

A DELL Accessible Learning (DAL) é uma plataforma para gestão do aprendizado

inclusivo, em que pessoas com deficiência participam efetivamente dos processos de levan-

tamento de requisitos, testes e validação de conteúdos. Ela possui uma série de recursos de

acessibilidade para pessoas com deficiência física (motor), auditiva e baixa visão. Também

foram iniciados estudos para que o sistema esteja amplamente adaptado para cegos.

Compõem a DAL diferentes tipos de objetos de aprendizagem como web aulas,

fóruns, oficinas, exercícios, avaliações, conteúdos didáticos digitais (CDDs), videoaulas e um

glossário bilíngue, onde são dispostos os conceitos de mais de 400 termos técnicos em português

traduzidos para Libras.

Os objetos de aprendizagem foram produzidos utilizando a metodologia de modela-

gem e análise por redes de Petri coloridas para produção de objetos de aprendizagem acessíveis

(JÚNIOR et al., 2014). A adaptação das vídeoaulas para SDA levou à necessidade de criar um

processo específico, pois exige uma série de recursos e cuidados para produção e edição dos

vídeos (GONÇALVES et al., 2015).

As interações entre usuários são mediadas por ferramentas como chat, fórum e

correio interno, onde os alunos SDA podem gravar vídeos em Libras. O sistema também permite

que traduções em Libras sejam agregadas ao conteúdo da web aula.

40

Recursos como comandos de voz, atalhos para acesso rápido, configuração de fonte

e modo de alto contraste são dispostos no topo da tela em um componente nomeado de barra de

acessibilidade. A Figura 15 mostra a web aula com vídeo libras, agregado com a tradução do

conteúdo.

Figura 15 – Web Aula com vídeo em Libras.

Fonte: Dell Inc. (2017)

41

Para as atividades práticas nas quais os alunos desenvolvem seus códigos (Oficina),

é utilizado o Java Learning Object to Assist the Deaf (JLoad) (SILVA et al., 2014) mostrado na

Figura 16.

Figura 16 – JLoad Interface

Fonte: Silva et al. (2014).

O JLoad foi feito para ensinar as primeiras noções de Java a estudantes. Ele permite

que os alunos criem suas oficinas e submetam para avaliação de um tutor.

Uma oficina é composta por uma lista de atividades de programação, e cada atividade

tem seu próprio conjunto de instruções (exibido em Libras e português), uma atividade no JLoad

requer alguma codificação para ser compilada e executada. O aluno pode enviar o código-fonte,

pedir e receber ajuda de um tutor, tudo feito dentro do ambiente do JLoad. Essa abordagem

tudo-em-um possibilita ao aluno um ambiente integrado de aprendizado e codificação, trazendo

maior mobilidade, pois tudo está em um ambiente web. O estudante pode enviar perguntas ao

tutor sobre a tarefa de uma oficina, podendo destacar a parte do código em que consiste sua

dúvida. O código de destaque pode estar ancorado no chat e vice-versa (SILVA et al., 2014).

42

O JAD é parte integrante dessa ferramenta. Utilizando o botão depurar, será aberta a

perspectiva de depuração do JAD, como é mostrado na Figura 17.

Figura 17 – Interface Gráfica do Java Accessible Debugger - JAD.

Fonte: Elaborada pelo autor.

Essa integração possibilita que, durante o processo de depuração, os usuários se

beneficiem de todos os recursos de interatividade disponíveis no JLoad criando um ambiente

integrado de desenvolvimento intuitivo, acessível e interativo. A arquitetura e funcionalidades

do JAD serão apresentadas no Capítulo 5 deste trabalho.

43

4 ESTUDOS PRÉVIOS

Para entender o problema que os SDA enfrentam durante o desenvolvimento de

sistemas utilizando IDEs tradicionais, foram realizados alguns estudos com alunos SDA e

não SDA, para identificar as dificuldades encontradas durante a correção de erros de código

utilizando depuradores. Os códigos utilizados para depuração possuem erros propositais, sendo

eles escolhidos com base em estudos realizados por Gomes et al. (2015) que aponta os erros

mais cometidos por estudantes iniciantes de programação, sendo eles erros de token (falta de

chave ou ponto e vírgula), erros na declaração de variáveis e erros de conversão .

Os resultados dos experimentos apresentam um série de fatores relevantes para

compreensão dos problemas de usabilidade e acessibilidade, apontando caminhos para construção

de um depurador acessível que traga em sua interface analogias com o mundo real, assim

facilitando a compreensão de comandos e auxiliando no aprendizado.

Os experimentos foram realziados objetivando validar as seguintes hipóteses:

1. Alunos SDA de um curso Java têm desempenho inferior ao de seus homólogos não SDA

durante a depuração de um código Java;

2. Depuradores visuais podem ser uma alternativa para que alunos do curso de programação

SDA tenham melhor desempenho durante a construção e depuração de código Java.

Nas seções 4.1 e 4.2, são apresentadas a metodologia e resultados dos experimentos

aplicados, com isso, é possível verificar a validação das hipóteses.

4.1 COMO ALUNOS DE PROGRAMAÇÃO SDA E NÃO SDA EXECUTAM A DEPURA-

ÇÃO DE UM CÓDIGO

Em estudos realizados por Nascimento, Oliveira e Freitas (2014), buscou-se identifi-

car quão bons são alunos SDA em relação a não-SDA de um curso de Java básico em encontrar e

corrigir erros em um programa. Para isso, realizou-se uma análise da situação atual com alunos

SDA e não - SDA com objetivo de avaliar a performance e entender as barreiras encontradas por

SDA durante o processo de depuração de código. Nesta seção são apresentadas a metodologia e

os resultados de um estudo comparativo do desempenho de SDA e não SDA durante o processo

de evolução de um código Java.

44

4.1.1 Metodologia

A técnica de análise da situação atual dá-se pelo estudo da interação usuário-sistema,

com objetivo de compreender os motivos pelos quais os usuários não utilizam como esperado os

sistemas computacionais (BARBOSA; SILVA, 2010). Utilizou-se essa técnica para compreender

as dificuldades e formas de interação dos usuários com a ferramenta utilizada.

4.1.2 Perfil dos participantes

Foram selecionados para o estudo 10 (dez) estudantes, entre eles 5 (cinco) SDA e

5 (cinco) não SDA que tinham completado o curso básico de Java com 150 horas. Eles foram

divididos em dois grupos, cada um com cinco participantes: o grupo de SDA e o outro de não

SDA. A idade dos participantes varia de 23 a 38 e foram todos do sexo masculino. Na Figura

18, resumimos as informações sociodemográficas relevantes sobre os participantes. Como se

pode observar, os participantes SDA possuem um grau de formação um pouco melhor que os

não SDA, porém, em relação à experiência com o Eclipse, o grau é semelhante nos dois grupos.

Figura 18 – Habilidades Relevantes.


45

4.1.3 O procedimento

O estudo consiste em encontrar e corrigir erros em duas classes Java como ilustrado

na Figura 19. Todos os participantes (SDA e não SDA) usaram o Eclipse para executar algumas

tarefas de depuração. A ideia principal do experimento é comparar a maneira como os dois

grupos executam cada tarefa. Basicamente foi medido o tempo gasto para completar a tarefa, o

número de pedidos de assistência e se concluiu com êxito a tarefa.

Figura 19 – Classes Java.


4.1.4 O procedimento

As sete tarefas estipuladas para os participantes no experimento são:

1. Modificar a perspectiva de depuração;

2. Corrigir os erros no código;

3. Adicionar ponto de interrupção em uma linha do código;

46

4. Verificar os valores das variáveis;

5. Usar a funcionalidade stepover;

6. Loop através de todas as linhas de código;

7. Modificar para a perspectiva Java.

Essas são atividades típicas em um processo de depuração. Não houve restrição

de tempo para os participantes terminarem as tarefas. Nenhuma das tarefas era obrigatória.

Estava disponível uma orientação em vídeo fornecendo as instruções em LIBRAS e Português.

Os participantes contavam com o auxílio de um intérprete de LIBRAS e um especialista para

os apoiarem quando fosse solicitado. Foram gravados vídeos das ações do usuário durante a

execução das tarefas para que posteriormente fossem analisados e verificadas as variáveis de

medição.

4.1.5 Resultados

A Figura 20 apresenta a tabela dos dados coletados. Apesar de terem realizado o

mesmo curso de Java Básico, não SDA e SDA tiveram diferenças significativas no desempenho.

Há evidências de correlação entre a condição de audição e capacidade para executar as tarefas

relacionadas a Java depuração no Eclipse IDE — x2 (1, N = 70) = 17.43, p < 0, 001. Existem

também evidências que SDA demoraram mais tempo para concluir (quando completaram) as

tarefas — t(44) 2.54, p = 0.0153. Aplicou-se o teste t de Student com intervalo de confiança de

90% para mitigar o risco de cometer um erro tipo II, devido ao baixo número de participantes.

Curiosamente, não foi possível encontrar qualquer diferença relevante no número

de pedidos de ajuda, apesar do fato de que havia um intérprete de Libras e um especialista

em Java disponíveis. Na análise situada, verificou-se que em muitas ocasiões, os SDA ficaram

completamente perdidos, pareciam não entender o que lhes era pedido, apesar do fato de as

instruções estarem disponíveis em LIBRAS. Parece que eles não entenderam o contexto do

que era pedido. Muitas vezes participantes SDA não conseguiram compreender as mensagens

transmitidas pelo IDE. Os não SDA facilmente encontraram os ícones apropriados e tiveram

uma melhor compreensão das mensagens passadas pelo sistema. Eles também exploraram o IDE

com mais desenvoltura (NASCIMENTO; OLIVEIRA; FREITAS, 2014).

47

Figura 20 – Resultados coletados.


4.1.6 Conclusões do estudo

Com os resultados percebe-se que existe de fato uma diferença no desempenho entre

os SDA e não SDA. Os SDA tiveram pior desempenho e alguns não foram ainda capazes de

terminar as tarefas, apesar do fato de que não havia nenhuma restrição de tempo. Este é um

achado importante, uma vez que dificulta as chances de essas pessoas competirem por uma

vaga no mercado com pessoas sem nenhuma deficiência. Essa diferença deve-se a questões

de linguagem, uma vez que os SDA pensam de forma diferente, pois seus mecanismos de

pensamento são baseados em uma língua visual-espacial. Como resposta, discuti-se o uso

de depuradores visuais, os riscos de sobrecarga, levando em consideração o fato de que eles

absorvem menos informação em sua memória de curto prazo que se comparados aos não SDA.

Na seção 4.2 será apresentado um estudo comparativo, onde um grupo de alunos SDA utiliza um

depurador visual e outro grupo o depurador do Eclipse, dessa forma será possível avaliar qual

ferramenta melhor se adapta à realidade dos SDA, podendo gerar melhor desempenho, além de

ganhos de produtividade no aprendizado e na implementação de códigos.

4.2 DEPURADORES VISUAIS E PROGRAMADORES SDA

Verificou-se que depuradores visuais resultam em impactos positivos para SDA

durante a depuração de código, reforçando assim, a teoria de que o campo visual possui influência

na compreensão do mundo real e aprendizado de SDA. Realizou-se uma análise comparativa

48

entre um grupo de SDA que utilizou o Eclipse (depurador tradicional) e outro, também de SDA,

que utilizou o JGrasp (depurador visual). Os resultados apresentaram impactos significativos,

motivando a proposta de um depurador visual integrado a um IDE que deve manter os ganhos de

um ambiente de aprendizagem Java acessível (NASCIMENTO et al., 2015).

4.2.1 Participantes e Metodologia

Foram recrutados dez participantes SDA, todos do sexo masculino, com idades

entre 25-36 anos, todos alunos do curso de Java básico. Os participantes foram aleatoriamente

distribuídos em dois grupos: o primeiro grupo realizou as tarefas usando a ferramenta Eclipse, e

o segundo grupo, usando JGrasp. Os participantes receberam um algoritmo de Java que simula

algumas transações bancárias: Sacar (Subtrair qualquer valor do saldo remanescente) e Depositar

(Adicione algum valor para o saldo existente). Foram incluídos alguns erros nos métodos para

que os participantes pudessem depurar o código, identificar os erros e corrigi-los, conforme

mostrado nas Figuras 21 e 22. Os dados foram recolhidos com base na análise dos vídeos de tela

e da reação dos utilizadores registrada durante a execução de tarefas.

Um script com quatro tarefas foi dado aos participantes para ajudá-los no processo:

1. Adicionando um ponto de interrupção nos métodos Sacar () e Depositar ();

2. Depurar para verificar se os valores de retorno são consistentes com o objetivo do método;

3. Correção dos problemas encontrados;

4. Depurar novamente para verificar se os cálculos estão corretos.

Os métodos, a análise e a avaliação foram aplicados a ambas as condições experimen-

tais. Usamos a técnica de análise situada para medir o desempenho dos participantes durante a

depuração da tarefa. Para essa análise, observamos as seguintes variáveis: tempo para completar

as tarefas (TCT), número de tarefas concluídas (NTC) e quantidade de auxílios (QA).

Além da análise, foi aplicado um questionário com base na Escala de Usabilidade

do Sistema (do inglês, SUS), de modo que os participantes pudessem avaliar a capacidade de

utilização das ferramentas. A Escala de Usabilidade do Sistema fornece uma maneira confiável

para medir a usabilidade. É um questionário com base nas Heurísticas de Nielsen com 5 (cinco)

opções de resposta, onde o usuário pode concordar fortemente ou discordar fortemente com as

declarações como uma escala de Likert (BROOKE, 1996).

49

Figura 21 – Participante do Grupo 01 Utilizando o Eclipse.


4.2.2 Resultados e discussões

Nesta seção são apresentados os resultados das variáveis observadas durante a

execução de tarefas de depuração em JGrasp e Eclipse. Para análise dos dados aplicou-se um

teste t não pareado, sendo este um teste estatístico utilizado para verificação e validação de

hipóteses. Ele foi aplicado para verificar se havia diferenças significativas nos resultados entre os

dois grupos experimentais. Comparou-se as seguintes variáveis: tempo para completar as tarefas

(TCT), número de tarefas concluidas (NTC) e quantidade de auxílios (QA), como mostradas na

Tabela 1.

Tabela 1 – Resultados do Teste t Não Pareado

t-value p-value alcanceTCT 1.011979 0.170587 Não significativo para p ≤ 0.10NTC 1.543033 0.080699 significativo para p ≤ 0.10QA 1.206045 0.131127 Não significativo para p ≤ 0.10

Fonte: Nascimento et al. (2015).

50

Figura 22 – Participante do Grupo 02 Utilizando o JGrasp.


Os resultados apresentados na tabela 1, apontam os seguintes resultados:

• Não existe diferença significativa em relação ao tempo para execução das tarefas no Eclipse

e no JGrasp.

• Existe uma diferença significativa entre Eclipse e JGrasp em relação ao número de tarefas

concluídas.

• Os participantes que utilizaram o JGrasp obtiveram mais sucessos em relação à conclusão

das tarefas.

• Não existe diferença significativa em relação à quantidade de pedidos de auxílio.

Realizou-se uma avaliação de usabilidade, aplicando o questionário System Usability

Scale - SUS, onde os grupos avaliaram os dois IDEs mencionadas. A pontuação SUS para

o JGrasp foi de 72 e 50 para Eclipse. Pesquisas indicam que uma pontuação acima de 68 é

considerada acima da média (SAURO; LEWIS, 2012). Também aplicou-se o teste t não pareado

para os escores SUS. O valor t obtido foi de 3,0291 e o valor de p foi 0,0163. O resultado é,

portanto, significativo para p 0.005. Em outras palavras, existe uma diferença significativa na

usabilidade das duas ferramentas. Sendo assim, os resultados indicam que, a ferramenta JGrasp

51

tem uma melhor usabilidade na avaliação dos usuários.

52

5 JAVA ACCESSIBLE DEBUGGER -JAD

O Java Accessible Debugger (JAD) consiste em um depurador acessível de código

Java com conceito de interfaces metafóricas aplicado, projetado com base estudos de experi-

mentação com usuário. Ele faz parte da plataforma plataforma de ensino a distância DELL

Accessible Learning, sendo o depurador atrelado ao Jload, que por sua vez , é utilizado para as

atividades práticas de programação.

5.1 ARQUITETURA DA FERRAMENTA

O JAD foi desenvolvido em linguagem Java, especificamente na versão 6, sob o

padrão arquitetural MVC (Modelo-Visão-Controle), o qual separa a aplicação em partes distintas.

A camada Modelo engloba as regras de manipulação e persistência dos dados. A camada de

Visão é a responsável por apresentar os dados ao usuário, assim como receber dados do usuário.

Por fim, a camada de Controle assume o papel de intermediadora entre as camadas de Modelo e

Visão, controlando e interpretando as solicitações realizadas entre a visão e o modelo (BARROS;

SILVA; ESPÍNOLA, 2007). Na camada de Modelo foi utilizado o padrão DAO (Data Access

Object) como o padrão que permite criar as classes de dados independentemente de a fonte

de dados ser um banco de dados relacional, um arquivo texto, um arquivo XML. Este padrão

encapsula os mecanismos de acesso a dados através de uma interface genérica que permite que

os mecanismos de acesso a dados sejam alterados independentemente do código que utiliza os

dados (CRUPI; MALKS; ALUR, 2001). Como mecanismo de acesso aos dados, foi utilizado o

Hibernate, que se trata de um framework para o mapeamento objeto-relacional. Esse framework

facilita o mapeamento dos atributos entre uma base tradicional de dados relacionais e o modelo

objeto de uma aplicação. Para realizar esse mapeamento, utilizou-se as anotações Java com a

versão 4.1.9 do Hibernate (LINHARES, 2012). Como sistema de gerenciamento de banco de

dados objeto-relacional, foi utilizado o PostgreSql 9.3.

Na camada de Visão foi utilizado JSTL, que é uma API que encapsula funcionali-

dades de controle de laços (for), controle de fluxo if else; além da tecnologia JSP (Java Server

Pages) que provê uma forma rápida e simples de criar conteúdo dinâmico para web. O Tomcat

versão 6 foi utilizado como servidor web Java e container de servlets. Outros recursos utilizados

foram Ajax, JSON, JQuery e códigos em Javascript.

Na camada de Controle, os Servlets, que são as classes capazes de tratar as requisi-

ções recebidas de clientes Web, foram utilizados para tratar as requisições do navegador, além

53

da regra de negócio da aplicação. A depuração dos códigos foi viabilizada pelo uso do JDB

(Java Debugger), que é um depurador de linha de comando para classes Java. O JDB é uma

demonstração da arquitetura de depuração da plataforma Java que disponibiliza inspeção e

depuração de uma máquina virtual Java remota ou local. Vale ressaltar que o mesmo é utilizado

na ferramenta de depuração do Eclipse. A biblioteca do JQuery e códigos em Javascript foram

utilizados para tratar das interações do usuário com os componentes da interface do JAD.

O JDB é uma biblioteca em Java que funciona em linha de comando, o que inicial-

mente inviabilizou a sua utilização em uma aplicação WEB. Para contornar essa situação, foi

adicionada uma classe, que através da herança, herda as funcionalidades de depuração, as quais

foram sobrescritas em sua maioria para que as informações de depuração fossem armazenadas

em variáveis, ao invés de apresentadas na saída padrão. A partir disto, a depuração dos códigos

foi realizada da seguinte maneira:

1. Uma requisição Ajax é enviada para o servlet de depuração com a opção de iniciar

depuração;

2. O referido servlet compila a classe indicando a opção de depuração para que seja possível

realizar a depuração da classe através do JDB;

3. A depuração total do código é realizada por completo no lado servidor;

4. Uma estrutura em JSON é criada para armazenar as informações de depuração de cada

linha do código, suas variáveis e valores, erros de compilação ou execução;

5. Essa estrutura JSON, denominada retorno_depuracao, é então enviada como resposta da

requisição Ajax do passo 1;

6. A estrutura recebida é mantida no lado do cliente através de códigos Javascript;

7. À medida que o usuário interage com a aplicação solicitando comandos para pausar,

depurar próxima linha ou linha anterior, ao invés destas solicitações serem processadas no

servidor, os componentes visuais do JAD são atualizados refletindo a linha de depuração

atual. Os dados da linha de depuração atual são carregados da estrutura retorno_depuracao.

Quando alguma alteração é realizada no código, volta-se então para o passo 1.

5.2 A ENGENHARIA SEMIÓTICA APLICADA AO JAD POR MEIO DE INTERFACES

METAFÓRICAS E VISUALIZAÇÃO DA INFORMAÇÃO

A engenharia semiótica - ES é uma teoria de IHC que aborda os processos de

significação e comunicação envolvendo designers, usuários e sistemas interativos (LEITÃO;

54

SILVEIRA; SOUZA, 2013). Leitão, Silveira e Souza (2013), apontam que a ES visa resolver

como o conhecimento que o usuário precisa adquirir pode ser melhor passado de forma mais

intuitiva, possibilitando uma melhor interpretação do modelo de interação e da funcionalidade.

O JAD se utiliza do conceito da engenharia semiótica aplicando interfaces meta-

fóricas, na analogia de depuração a situações do mundo real vividas no trânsito.Utilizou-se a

metáfora do trânsito para que durante o processo de depuração o usuário tenha a sensação de

estar no controle de um carro navegando sobre uma estrada de código, seguindo as sinalizações

de forma que estas possam lhe ajudar a alcançar seu objetivo e compreender melhor os caminhos

percorridos (linhas de código). Nos apropriamos da sinalização vertical de trânsito (CONSE-

LHO NACIONAL DE TRâNSITO, 2007) para indicar os comportamentos do código durante a

depuração. A Figura 23 apresenta os sinais utilizados para o JAD e seus significados durante a

depuração.

55

Figura 23 – Sinaléticas utilizadas durante a depuração.

Fonte: Conselho Nacional de Trânsito (2007).

56

Aliados aos símbolos, tem-se as representações de variáveis, objetos e estruturas de

dados aplicando a técnica de INFOVIS para visualização de dados abstratos como é mostrado na

Figura 24, a qual ilustra um array e seus valores em cada índice.

Figura 24 – Visualização de dados no JAD .


Com essas representações, os usuários poderão acompanhar o comportamento do

código durante a depuração, evitando problemas de mapeamento e controle. Esses problemas

são comuns em sistemas interativos. O problema de mapeamento inviabiliza o usuário de mapear

e acompanhar suas ações, enquanto o de controle impossibilita o usuário controlar os estados

do sistema (BARBOSA; SILVA, 2010). Tratou-se os problemas de mapeamento e controle,

permitindo que o usuário acompanhe o comportamento do sistema por meio de artefatos visuais,

podendo navegar pelas linhas de código com as opções de incluir ponto de parada, avançar linha,

voltar linha e parar a depuração, como é mostrado na Figura 25.

Figura 25 – Menu de funcionalidades do JAD .


À medida que os artefatos vão aparecendo na tela, o usuário tem total controle para

ocultar e abrir. Toda a estrutura de design e analogias foi pensada para que os usuários possam se

57

sentir confortáveis e engajados na tarefa de depuração, dando todas as sinalizações e caminhos

necessários para que eles tenham o controle da tarefa e se sintam confiantes durante a interação

com o JAD para a depuração de código.

O JAD foi projetado para que atenda SDA e não SDA, com o objetivo de tornar o

acesso e a forma de aprendizado igualitários sem barreiras para ambos os grupos. Durante sua

construção, foi pensada em uma série de recursos de acessibilidade para que a interação e o

acesso fossem universais. Esses recursos são apresentados na seção 5.3.

5.3 OS RECURSOS DE ACESSIBILIDADE DO JAD

Durante o processo de interação com sistemas, os usuários utilizam-se de seus

sentidos (visão, audição e tato). Para pessoas com algum tipo de deficiência, a interação pode

ser prejudicada, caso o sistema não possua algum recurso de acessibilidade que possibilite

a interação. Barbosa e Silva (2010) definem como critério de acessibilidade, interfaces que

possibilitem o usuário a interagir com o sistema sem que imponha obstáculos.

O JAD possui mecanismos de lançamento de erros e exceções do Java em Libras

para auxiliar programadores surdos na compreensão dos erros, como é mostrado na Figura 26.

Figura 26 – Erro de sintaxe em Libras.


O World Wide Web Consortium (W3C) é um consórcio de empresas e instituições

que definem os padrões para a Web (W3C, 2008). Algumas diretrizes para acessibilidade na web

foram propostas e disponibilizadas pela W3C por meio do Web Content Accessibility Guidelines

58

(WCAG). Ela segue alguns níveis de abordagem que incluem princípios, recomendações gerais

e critérios de sucesso. Todos esses níveis de abordagem funcionam em conjunto para fornecer

orientações sobre como tornar o conteúdo mais acessível. Os utilizadores são encorajados a

observar e a aplicar todos os níveis que conseguirem, incluindo as técnicas aconselhadas, para

satisfazer as necessidades do maior número possível de usuários. São 3 os níveis de conformidade:

A, AA e AAA, que são mapeados conforme os critérios de sucesso convencionados pela WCAG,

sendo A (o mais baixo) e o AAA (o mais elevado) (W3C, 2008).

O JAD possui alguns dos recursos de acessibilidade propostos pela WCAG 2.0,

sendo alguns deles herdados do JLOAD (IDE à qual ele está integrado) que visa atender não

somente a SDA, mas outros tipos de deficiência, buscando o uso amplo e eficaz por diversos

tipos de usuário com ou sem deficiência. Na Tabela 2, são classificamos os recursos conforme os

níveis de conformidade da WCAG.

Tabela 2 – Recursos de acessiblidade e conformidade com a WCAG 2.0

Recurso Conformidade WCAGLançamento de Exceções do Java em Libras AAutocontraste AARedimensionamento de fonte ATeclas de atalho AColocar em Pausa, Parar, Ocultar AEtiquetas ou Instruções AAdaptável (apresentação padrão e visual) A


A WCAG utiliza alguns validadores de código para verificação de conformidade

geral de páginas web. Utilizou-se o validador TAW (TECNOLóGICO, 2017) para fazer a

validação do JAD, obtendo nível AA. A WCAG não recomenda fixar o Nível AAA como

requisito normativo para todas as páginas, pois em alguns casos, não é possível satisfazer todos

os critérios de Sucesso de Nível AAA (W3C, 2008).

As tabelas

Tabela 3 – Recursos de Acessibilidade - ComparativoRecursos de Acessiblidade JAD JGrasp JIVE CodemapAtalhos x xAutocontraste xRedimencionamento de fonte x xVídeos pré-gravados de Libras xSuporte para leitores de tela x x

59

Tabela 4 – Funcionalidades - ComparativoFuncionalidades JAD JGrasp JIVE CodemapPortabilidade xVoltar linha de código x xTécnicas Infovis para construir e manipular objetos x x x xCHAT com opção de gravação de vídeo em Libras xSolicitação de tradução em Libras para Exceções Java xPerfil Administrador para solicitações de tradução xVersões de código xMarcação de código para revisão x

As funcionalidades e recursos presentes no JAD foram implementados para atender

não somente a SDA, mas também a pessoas que possuam outras ou nenhuma deficência. Espera-

se que o uso do JAD para tarefas de depuração de código auxilie no aprendizado e na evolução

de códigos, tornando o processo de depuração mais fácil e inutitivo.

60

6 EXPERIMENTOS APLICADOS AO JAD

Os estudos realizados e apresentados neste trabalho no Capítulo 4 permitiram identi-

ficar as seguintes situações:

1. Na Seção 4.1, os resultados da análise comparativa de performance entre SDA e não SDA,

utilizando o Eclipse para evolução de um código, mostraram que os participantes não SDA

obtiveram melhor desempenho sobre os SDA.

2. Na Seção 4.2, o estudo situado utilizando método Between Subjects (onde grupos de

uma população são submetidos a tratamentos diferentes) identificou que o grupo de SDA

que utilizou o depurador visual JGrasp obteve-se melhor desempenho sobre o grupo que

utilizou o Eclipse. Um teste de usabilidade também foi aplicado e verificou-se que o JGrasp

foi melhor avaliado em relação ao Eclipse. Com isso, verificou-se que um depurador visual

pode ter impacto positivo na performance de alunos SDA.

Verificou-se nos experimentos que participantes SDA obtiveram bons resultados com

uso do JGrasp. Tais resultados motivaram a formulação das seguintes hipóteses:

1. Não existe nenhuma diferença significativa de desempenho entre SDA e não SDA durante

a tarefa de evolução de um código utilizando o JAD;

2. SDA e não SDA possuem um desempenho melhor utilizando o JAD comparado ao JGrasp;

3. O JAD obteve melhores resultados para avaliação de usabilidade quando comparado com

JGrasp.

Para verificar as hipóteses e analisar a eficácia do JAD em relação ao JGrasp, realizou-

se um experimento aplicando as mesmas técnicas e métricas dos experimentos anteriores,

mostrados no Capítulo 4. Todas as técnicas, métricas e ferramentas utilizadas são apresentadas

na Seção 2.6.

6.1 TÉCNICAS E FERRAMENTAS UTILIZADAS

Para aplicação do experimento, buscou-se na literatura, algumas técnicas para análise

e avaliação da interação de usuários com sistemas computacionais. A aplicação delas nos

possibilita o levantamento de dados para análises quantitativas e qualitativas da experiência de

uso do JAD.

Para obtenção de resultados mais rigorosos e válidos, utilizou-se a técnica de tri-

angulação, que permite a análise dos dados de diferentes perspectivas com objetivo de afirmar

descobertas (BARBOSA; SILVA, 2010). Para aplicá-la, utilizou-se as técnicas de análise de

61

desempenho, teste de usabilidade e análise competitiva, dessa forma, tem-se uma visão dos

resultados dos usuários, do sistema e do desempenho do sistema proposto em relação ao existente

no mercado.

• Análise de Desempenho: A análise de desempenho consiste na coleta dos seguintes

dados: tarefas realizadas, tempo necessário para concluir a tarefa e o número de auxílios

solicitados. Os dados foram catalogados pelo observador enquanto o usuário realizava a

tarefa de evolução e depuração de um código Java. Ela foi aplicada ao uso das ferramentas

JAD e JGrasp, possibilitando comparar o desempenho de SDA e não SDA em ambas as

ferramentas.

• Teste de Usabilidade: Para avaliação de usabilidade, utilizou-se o System Usability Scale.

Algumas questões foram acrescentadas ao questionário de forma complementar, não

fazendo parte da contagem para os escores gerados pelo SUS. Elas foram elaboradas com

base nas heurísticas de Nielsen (1994) para avaliar algumas questões de usabilidade não

abordadas diretamente pelo SUS, sendo assim, totaliza-se 15 questões a serem respondidas

pelos participantes. As respostas às questões seguem o mesmo modelo utilizado pelo

SUS, onde o avaliador seleciona em uma escala Likert de 1 (Discordo fortemente) a 5

(Concordo fortemente) seu grau de concordância. Foram acrescentadas 5 (cinco) questões

apresentadas na Figura 27. O teste de usabilidade foi aplicado logo após a conclusão da

tarefa, e os usuário SDA contaram com o auxílio de intérpretes de Libras para compreensão

dos textos.

• Análise Competitiva: Com os resultados da análise de performance e do teste de usabili-

dade foi possível fazer uma análise competitiva entre as ferramentas e os perfis SDA e não

SDA. A análise foi realizada comparando os resultados dos testes aplicados com objetivo

de verificar diferenças significativas de uso entre as ferramentas. As variáveis a serem

comparadas foram as seguintes: tempo de conclusão das tarefas, quantidade de auxílios

referente ao código que está sendo depurado, quantidade de auxílios referente ao uso da

ferramenta escore SUS, correspondências com mundo real, controle e mapeamento das

tarefa, facilidade de identificação dos estados do sistema, reconhecimento das funções,

além de diagnosticar e recuperar-se de erros.

62

Figura 27 – Questões Adicionadas à Avaliação de Usabilidade.

Fonte: Nielsen (1994).

6.2 PERFIL DOS PARTICIPANTES

Foram convidados a participar do experimento 14 participantes SDA e 14 não SDA.

Dada a dificuldade para captação de participantes SDA, optou-se por estender os critérios de

inclusão para participação no experimento, sendo eles:

• Ter o conhecimento de lógica de programação;

• Ter participado do minicurso para nivelamento.

Os participantes responderam um questionário com perguntas referentes ao seu perfil

socioeducativo (Apêndice C). Com esse questionário, tornou-se possível fazer uma análise dos

perfis dos participantes e mapear suas competências. Disponibilizou-se o questionário online

com tradução em Libras para os participantes surdos.

Durante o processo de seleção e aplicação do experimento houve as desistências de

3 (três) ouvintes e 1 (um) surdo. Os 24 participantes tiveram um minicurso de nivelamento com

as seguintes temáticas: arrays, tipos de dados e depuração de código Java. Além dos conceitos,

63

também apresentou-se as ferramentas JAD e JGrasp. Informou-se para os participantes que tais

ferramentas seriam utilizadas posteriormente para as atividades práticas e consequentemente

para avaliação de usabilidade.

Com os dados dos perfis coletados, realizou-se uma análise quantitativa com objetivo

de verificar o perfis dos grupos de SDA e não SDA. Na Tabela 5, são apresentados os dados os

quais não se utilizou de escala Likert para medir os resultados.

Tabela 5 – Resultados para questões que não se utilizou a escala LikertQuestão SDA não SDA Análise Crítica

1. Sexo Masculino: 11Feminino: 02

Masculino: 9Feminino: 2

Os dois grupos são compostosem sua maioria por participantes

do sexo masculino.

5. Grau deSurdez

Leve: 0Moderada: 2

Severa: 2Profunda: 9

Nãose aplica

Dos 13 participantes, 11 apresentamgrau de surdez severa ou profunda,

impossibilitando a audição de sons defala em nível de conversação natural.

6. Oralizado? Sim: 5Não: 8

Nãose aplica

Sujeitos surdos oralizadosnormalmente possuem domínio da

escrita e/ou leitura labial. Apenas 5 dosparticipantes possuem essa habilidade.


Para algumas questões utilizou-se opções onde as respostas poderiam variar em uma

escala Likert de 1 a 5. Essa foi uma estratégia utilizada para medição dos resultados em forma

de Ranking Médio (RM), assim, geraram-se números RM que apontam em que faixa da escala

está a maior parte da amostra para cada grupo de participantes (OLIVEIRA, 2005). A análise

crítica de tais questões é apresentada na Tabela 6.

64

Tabela 6 – Análise crítica a partir do RM para questões com escala LikertQuestão Análise Crítica

2. Idade

Embora o grupo não SDA possua uma tendência de idadesuperior aos SDA, os dois grupos estão no intervalo entre2 (de 20 a 30 anos) e 3 (de 31 a 40 anos). Isso mostra que osdois grupos não apresentam diferenças significativas emrelação à faixa etária.

3. Grau deInstrução

Para o grau de escolaridade, apresentou-se para o grupo deSDA um nível mais elevado de escolaridade em relaçãoao não SDA. O grupo de SDA está no intervalo entre3 (superior incompleto) e 4 (superior completo), enquanto ogrupo de ouvintes está entre 2 (ensino médio completo) e3 (superior incompleto).

4. Conhecimentoem Java

Os resultados apontam que o grupo de SDA possui umconhecimento maior da linguagem Java em relação aonão SDA. O grupo de SDA indicou um intervalo entre3 (Médio) e 4 (Bom), enquanto o grupo de não SDA estáentre 2 (Pouco) e 3 (Médio).

7. Domínio deLibras Os resultados apontam que o nível de domínio da Libras

entre os SDA está entre Médio e Bom. O mesmo resultadotambém ocorre para o domínio do português.

8. Domínio dePortuguês


65

6.3 INFRAESTRUTURA E MÉTODO DE APLICAÇÃO

Foram disponibilizadas duas salas, onde os participantes tinham acesso a um compu-

tador com os programas necessários instalados como mostrado na Figura 28.

Figura 28 – Layout e logística do experimento


Como apresentado na Figura 28, foram divididos 3 (três) subgrupos em horários

66

distintos, onde os participantes foram distribuídos de forma aleatória. Para melhor identificar

a transição dos participantes entre os laboratórios destacaram-se as duplas que iniciaram o

experimento com JAD na cor verde e aquelas que iniciaram com JGrasp em azul. Os horários

foram definidos e divulgados para os participantes previamente. Solicitou-se que viessem apenas

no horário agendado para evitar a espera e fadiga durante o experimento.

Nos laboratórios estavam dispostos 1 (um) observador, 1 (um) intérprete de libras

para auxiliar participantes SDA na compreensão das tarefas e possíveis dúvidas e 1(um) entrevis-

tador responsável pelo preenchimento do questionário de avaliação da usabilidade. Definiu-se

que cada observador deveria acompanhar 2 (dois) participantes por vez. Após a conclusão da

tarefa, os participantes eram direcionados para o preenchimento do questionário de usabilidade

com auxílio de um entrevistador. No intervalo entre a transição do Lab-JAD para o Lab-JGrasp

ou o contrário, os participantes tinham um intervalo de 15 minutos, com lanche à disposição. Ao

final, por meio do voto secreto, cada participante pôde votar na ferramenta de sua preferência.

Algumas condições para o experimento foram estabelecidas e seguidas:

1. Termo de Consentimento: Todos os participantes assinaram um termo de consentimento

com objetivo de esclarecer e formalizar sua participação no experimento. Neste termo,

foram expostas as condições de uso e divulgação dos dados coletados.

2. Nivelamento: Realizou-se um nivelamento com as seguintes temáticas: Arrays, tipos

de dados e depuração de código Java. Além dos conceitos, também apresentou-se as

ferramentas JAD e JGrasp. O nivelamento aconteceu no dia 13 de Janeiro de 2017 na

Universidade do Trabalho Digital em Fortaleza-Ce. A participação neste evento foi uma

condição para a participação no experimento ocorrido na semana seguinte, nos dias 16 e

17 de Janeiro de 2017.

3. Acompanhamento: Os participantes foram acompanhados por 1 (um) observador para

tirar dúvidas e registrar o tempo de cada participante na execução da tarefa, pedidos de

auxílio e registrar se o mesmo obteve sucesso ou não;

4. Avaliação de usabilidade: Ao final de cada tarefa os participantes responderam ao

questionário de usabilidade, com auxílio de um atendente previamente treinado. Os

participantes SDA tiveram o auxílio de intérpretes para a interpretação das perguntas e

respostas ao questionário.

5. Intervalo: Foi disponibilizada uma sala com lanche para que pudessem descansar entre o

uso de uma ferramenta e outra. Durante esse intervalo foi pedido que os participantes não

conversassem sobre o uso das ferramentas para que não influenciassem os resultados.

67

6. Votação: Ao final do uso das duas ferramentas, foi pedido para que os participantes

votassem de forma secreta na ferramenta de sua preferência. Foram disponibilizados papel

e caneta para que pudessem escrever o nome da ferramenta e depositar no envelope.

7. Formulários aplicados: Questionário de Perfil Socioeducativo (Apêndice C); Termo de

Consentimento (Apêndice D); Questionário de Usabilidade (Seção 2.6.2); e Ficha de

Observação (Apêndice B).

Esse formato de aplicação corresponde ao método Whithin-subjects, onde um par-

ticipante é submetido a dois contextos (o uso do JAD e JGrasp). Foram disponibilizados dois

códigos com duas classes JAVA com 2 erros cada, um sintático e outro semântico. No Código 1,

mostrado na Figura 29, foi incluído um erro de compilação: compiler.err.cant.resolve.location,

onde o Java tenta encontrar o tipo “Int”. Como esse tipo não existe ou, se existe, não foi incluído

no import, esse tipo de erro é gerado, já que não é possível encontrar a localização do tipo.

No Código 2, mostrado na Figura 30, é gerado um erro de compilação referente à

incompatibilidade de tipos: compiler.err.prob.found.req.

O erro de execução java.lang.ArrayIndexOutOfBoundsException foi incluído em

ambos os códigos. Esse erro indica que um vetor foi acessado por um índice ilegal. O erro ocorre

pois o índice acessado é negativo, ou maior ou igual ao tamanho do vetor.

Figura 29 – Código 1 apresentado no JGRASP.


68

Figura 30 – Código 2 apresentado no JAD.


Foi pedido aos participantes que depurassem os códigos mostrados nas Figuras 29 e

30 e corrigissem os erros das classes. Foi feito o "quadrado latino"para contrabalançar e evitar os

carry on effects (aprendizada e fadiga) e a alocação dos participantes às condições experimentais

foi randomizado conforme Tabela 7.

Tabela 7 – Disponibilização do Código por Turma.Código Turma 1 Turma 2

SDA não SDA SDA não SDACódigo 1 JAD JAD JGrasp JGraspCódigo 2 JGrasp JGrasp JAD JAD


Toda interação foi gravada com captura de tela e webcam do participante, assim

foi possível analisar pontos críticos da interação. Durante a aplicação do experimento, os

participantes podiam contar com um suporte especializado e auxílio de intérprete de Libras para

os participantes SDA.

6.4 PROBLEMAS OCORRIDOS

Durante a aplicação, ocorreram alguns problemas que resultaram em alterações no

processo:

1. Mesmo preenchendo o questionário de perfil, alguns participantes não compareceram para

o treinamento de nivelamento, ficando assim o número de 13 participantes SDA e 11 não

SDA;

69

2. Durante a aplicação do experimento, aconteceram alguns problemas que nos levaram a

eliminar participantes da análise de desempenho como: o mesmo código ser utilizado no

JAD e no JGrasp por falta de atenção da equipe de suporte, a rede de internet ficar fora do

ar e não ser possível para um dos participantes fazer o teste com o JAD. Com isso, foram

eliminados da contagem quantitativa para a análise de desempenho 3 participantes SDA e

2 não SDA, ficando assim 10 SDA e 9 ouvintes para análises válidas;

3. Apenas um participante surdo, foi eliminado da contagem para avaliação de usabilidade,

pois em razão de problema de rede de internet o mesmo não pôde realizar o teste com o JAD.

Embora tenham acontecidos alguns problemas que impossibilitaram incluir o resultado

de alguns participantes para a análise de desempenho, 4 dos participantes utilizaram as

duas ferramentas. Com isso, achou-se por bem incluir a avaliação de usabilidade realizada

por eles nos resultados válidos, pois os problemas ocorridos não causam impacto direto

sobre a avaliação de usabilidade da interface. Assim, o número de participantes para esta

avaliação foram 12 SDA e 11 ouvintes.

Durante o planejamento e a aplicação do experimento, buscou-se rigorosamente evi-

tar que os dados coletados fossem corrompidos por problemas de logística. Algumas adaptações

de metodologia de testes foram necessárias, pois as restrições de infraestrutura e adaptações para

o perfil de SDA não nos permitiram seguir rigorosamente algumas boas práticas recomendadas

para os tipos de testes aplicados.

70

7 RESULTADOS

Neste capítulo, são apresentados os resultados quantitativos e qualitativos obtidos a

partir dos dados coletados durante a aplicação do experimento. Além disso, foi realizada uma

análise crítica dos resultados com intuito de verificar a veracidade das hipóteses e identificar os

impactos da intervenção (JAD) sobre a performance de alunos surdos durante a depuração de um

código Java.

7.1 ANÁLISE QUANTITATIVA

A seguir, são mostrados os resultados quantitativos obtidos a partir dos testes estatís-

ticos. Cada uma das seções a seguir está relacionada com uma das hipóteses citadas no Capítulo

6.

7.1.1 Comparativo de Desempenho SDA x não-SDA utilizando o JAD

Os participantes, divididos nos grupos SDA e não-SDA, foram analisados quanto à

utilização da ferramenta JAD por meio das métricas de tempo, número de auxílios de código

e número de auxílios de ferramenta. O objetivo é verificar se existe diferença de desempenho

entre SDA e não-SDA ao utilizar o JAD.

Na Tabela 8, pode-se observar as médias das métricas obtidas por SDA e não-SDA.

Nota-se que o primeiro grupo, em média, finalizou em menos tempo, mas também realizou mais

solicitações de auxílio.

Tabela 8 – Média das métricas dos participantes ao utilizar o JADMétrica SDA não-SDATempo 14min 54s 15min 20s

Auxílios - Código 1,30 1Auxílios - Ferramenta 1,30 1,22


Dada a quantidade da amostra, fez-se necessária a aplicação do teste de Normalidade

Shapiro Wilk (SHAPIRO; WILK, 1965) para verificar a normalidade dos dados. Esse teste

verifica se a distribuição de probabilidade em um conjunto de dados pode ser aproximada pela

distribuição normal. Essa aproximação da normalidade é pré-requisito para aplicação de um

teste paramétrico. Visto que a normalidade dos dados não pode ser assumida, os resultados

individuais dos participantes foram submetidos ao teste Mann-Whitney U (MANN; WHITNEY,

71

1947). Trata-se de um teste não-paramétrico apropriado para avaliação de dois grupos distintos

(SDA e não-SDA) ao utilizar uma certa condição de teste. A Tabela 9 resume os resultados

obtidos.

Tabela 9 – Resultados do teste Mann-Whitney UMétrica Resultado Valor Crítico

para UDiferença

SignificativaTempo U=44,5, p=1 20 Não

Auxílios - Código U=40,5, p=0,7414 20 NãoAuxílios - Ferramenta U=42,5, p=0,87288 20 Não


Nenhuma das métricas apresenta diferença significativa, visto que o valor de U

obtido em todos os casos é maior que o valor crítico.

Portanto, pode-se afirmar que a ferramenta permite que pessoas SDA e não-SDA

aprendam atividades de depuração de forma mais isonômica. Desta forma, visando oferecer

oportunidades iguais para o público SDA.

7.1.2 Comparativo de Desempenho JAD x JGrasp

Os grupos SDA e não-SDA utilizaram as ferramentas JAD e JGrasp. Foi verificado

inicialmente quantos sujeitos finalizaram com êxito as atividades em ambas as ferramentas.

Esses dados bem como os resultados do teste estatístico McNemar (MCNEMAR, 1947) são

resumidos na Tabela 10.

Tabela 10 – Sujeitos que corrigiram com sucesso os Erros 01 e 02

Erro Perfil JAD JGraspResultadoMcNemar

(valor de p)

DiferençaSignificativa

Erro 01Geral 19/19 14/19 0,0736 NãoSDA 10/10 8/10 0,4795 Não

não-SDA 9/9 6/9 0,2482 Não

Erro 02Geral 12/19 10/19 0,7893 NãoSDA 5/10 5/10 0.7237 Não

não-SDA 7/9 5/9 0,6831 Não


Como pode ser visto na Tabela 10, os resultados favorecem o JAD. Uma maior

quantidade de participantes SDA e não-SDA conseguiu corrigir os erros usando o JAD do que

usando o JGrasp. Os dados foram submetidos ao teste estatístico McNemar (MCNEMAR, 1947),

próprio para dados categóricos. Contudo, nenhuma diferença significativa foi identificada.

72

Os participantes também foram avaliados nas métricas de tempo, número de auxílios

de código e número de auxílios de ferramenta. Como pode ser visto na Tabela 11, o JAD obtém

melhores médias em todas as métricas: os participantes terminaram em menor tempo; solicitaram

menos auxílio de código, o que sugere que a ferramenta apresenta a informação de maneira

que facilita o entendimento; e, por fim, também solicitaram menos auxílios sobre a ferramenta,

mostrando que o JAD é mais intuitivo na sua utilização. Para cada métrica, um sujeito de

pesquisa possui dois valores (um para cada ferramenta). As diferenças desses valores foram

submetidas ao teste de normalidade Shapiro Wilk (SHAPIRO; WILK, 1965). Em alguns casos, a

normalidade dos dados pode ser assumida. Nesses casos, foi utilizado o teste paramétrico teste T

de Student pareado. Quando a normalidade dos dados não pode ser assumida, o teste Wilcoxon

Signed-rank (WILCOXON, 1945) é utilizado. Contudo, como pode ser visto na tabela, nenhuma

diferença significativa foi encontrada.

Tabela 11 – Média das Métricas de Tempo e AuxíliosErro Perfil JAD JGrasp Resultado

EstatísticoDiferença

Significativa

TempoGeral 15min 07s 16min 41s

W=35,5, p>,05(valor crítico = 21) Não

SDA 14min 54s 17min 36s t(9)=0,979, p=0,353 Nãonão-SDA 15min 20s 15min 40s t(8)=0,142, p=0,890 Não

Auxíliode Código

Geral 1,16 1,53 t(18)=0,741, p=0,467 NãoSDA 1,30 1,60 t(9)=0,330, p=0,748 Não

não-SDA 1 1,44 * *

Auxílio deFerramenta

Geral 1,26 2,32W=27, p>,05

(valor crítico = 21) Não

SDA 1,30 1,90 t(9)=0,874, p=0,404 Não

não-SDA 1,22 2,78W=6, p>,05

(valor crítico = 2) Não

Nota: *Amostra reduzida devido ao alto número de empates.Fonte: Elaborada pelo autor.

7.1.3 Comparativo de Avaliação de Usabilidade JAD x JGrasp

Os dados foram submetidos ao teste de normalidade Shapiro-Wilk (SHAPIRO;

WILK, 1965). Após esse passo, assumimos a normalidade dos dados e submetemos os escores

SUS ao teste T de Student pareado, este teste foi utilizado em razão do design Within Subjects,

onde o mesmo sujeito é exposto a duas situações experimentais. O objetivo consiste em verificar

se existe diferença significativa entre a usabilidade do JAD e JGrasp.

A ferramenta JAD apresenta melhor resultado com um escore médio de 65,543

contra 48,152 do JGrasp, mostrando uma melhor avaliação de usabilidade dos participantes para

73

a ferramenta. Além disso, o resultado do teste T de Student pareado para toda a amostra (SDA

e não-SDA) aponta diferença significativa em relação à usabilidade: t(24)=-3,0267, p=0,0062.

Resultados com valor de p ≤ 0,05 apresentam diferença significativa.

7.1.3.1 Análise das Questões 4 e 10 do Questionário SUS

Analisaram-se também, os resultados individuais das questões 4 e 10 do questionário

SUS. Segundo Lewis e Sauro (2009), elas apontam o nível de aprendizado. O ranking médio

(RM) foi utilizado para analisar como os participantes SDA e não-SDA respondem a cada questão

em relação às ferramentas.

A Figura 31 apresenta os resultados referente ao JAD. Eles apontam uma discordância

de SDA e não-SDA em relação à necessidade de auxílio para operar o sistema. A maioria dos

sujeitos SDA optou por concordar ou concordar fortemente, enquanto a maioria dos não-SDA

optou por discordar ou discordar fortemente. Com isso, suspeita-se que o resultado tenha

refletido problemas culturais vividos por SDA, onde o auxílio de pessoas para certas tarefas faz

parte de seu cotidiano. Os resultados para essa questão tornam evidente a necessidade de aplicar

melhorias na ferramenta com objetivo de torná-la mais intuitiva para que ambos os grupos, SDA

e não-SDA, sintam-se seguros para executar uma tarefa sem necessidade de auxílio.

Figura 31 – RM para o JAD com base nas respostas à escala likert para as questões 4 e

10.


Os resultados referentes ao JGrasp são mostrados na Figura 32. Para a questão que

trata de conhecimentos prévios para operar o sistema, o grupo de SDA optou por concordar e

concordar fortemente, enquanto o grupo de não-SDA permaneceu entre a indiferença e concordar.

Observou-se que, por se tratar de uma ferramenta que envolve conhecimento prévio de uma

74

linguagem de programação, os participantes podem ter sido motivados a concordar com essa

questão, embora tenha sido explicado que o conhecimento deles não estaria sendo avaliado e sim

a usabilidade da ferramenta.

Figura 32 – RM para o JGrasp com base nas respostas à escala Likert para as questões 4

e 10.


7.1.3.2 Análise das Questões Acrescidas ao Questionário SUS

Para as cinco questões acrescidas ao questionário de avaliação de usabilidade foram

aplicadas diferentes métricas, por se tratar de um questionário com questões extras a respeito de

usabilidade. O método de ranking médio (RM) foi utilizado. Por se tratar apenas de questões

positivas, o valor maior na escala significa uma boa avaliação.

7.1.3.2.1 Resultados para o JAD

Q1 - É possível identificar facilmente os estados do sistema, permitindo maior controle e

mapeamento das tarefas.

Para esta questão, os grupos de não SDA com RM = 4,0 e SDA com RM= 4,3

demonstram tecnicamente a mesma opinião, com diferença de 0,3 de avaliação positiva por parte

do grupo de SDA. Esses resultados demonstram que os participantes de forma geral se sentiram

satisfeitos em relação ao mapeamento de controle das tarefas.

Q2 - O sistema possui correspondências com mundo real.

Os resultados dos não SDA com RM = 4,2 e SDA com RM = 4,1, mostram tecnica-

mente o mesmo grau de concordância entre os dois grupos, avaliando o nível de correspondência

dos elementos da interface com mundo real satisfatório.

75

Q3 - É possível controlar facilmente as tarefas.

Os resultados dos não SDA com RM = 4,5 e SDA com RM=4,2, mostram tecnica-

mente o mesmo grau de concordância entre os dois grupos para uma avaliação satisfatória no

que se refere ao fácil controle das tarefas.

Q4 - É possível reconhecer as funções sem esforço para lembrar o que elas executam.

Os resultados dos não SDA com RM = 4,5 e SDA com RM = 3,6, mostram divergên-

cia entre os dois grupos. Enquanto o grupo de não SDA apresenta resultados positivos a respeito

da questão, o grupo de SDA apresenta indiferença sobre o assunto com uma certa tendência

a concordar. Tal fato pode se dar em razão de que SDA precisam de um esforço maior para

entender um conteúdo ou até mesmo para se adaptar ao funcionamento de um software(PERLIN,

2004).

Q5 - O sistema fornece ajuda para reconhecer, diagnosticar e recuperar-se de erros.

Os resultados dos não SDA com RM = 4,7 e SDA com RM=4,8, mostram tecni-

camente o mesmo grau de concordância entre os dois grupos para uma avaliação satisfatória

reconhecer, diagnosticar e recupera-se de erros.

7.1.3.2.2 Resultados para o JGrasp

Q1 - É possível identificar facilmente os estados do sistema permitindo maior controle e mapea-

mento das tarefas.

Para esta questão os grupos de não SDA com RM = 3,5 e SDA com RM= 2,7,

demonstram divergências, onde o grupo de não SDA se demonstram indiferentes com tendência

a concordar com a questão, enquanto o grupo de SDA demonstra insatisfação no que diz respeito

a controle e mapeamento.

Q2 - O sistema possui correspondências com mundo real.

Os resultados dos não SDA com RM = 2,8 e SDA com RM = 3,1, mostram tecnica-

mente o mesmo grau de concordância em relação à correspondência da ferramenta com o mundo

real, demonstrando que ambos os grupos não se sentiram confiantes para afirmar tal questão.

Entre os dois grupos existe uma pequena tendência de discordância por parte dos não SDA no

que se refere à questão.

76

Q3 - É possível controlar facilmente as tarefas.

Para esta questão, os grupos de não SDA com RM = 3,3 e SDA com RM= 3,5,

demonstram tecnicamente o mesmo grau de indiferença com leve tendência a concordar com a

questão. Isso, mostra que ambos os grupos não se sentiram confiantes para avaliar positivamente

esta questão.

Q4 - É possível reconhecer as funções sem esforço para lembrar o que o que elas executam.

Os resultados dos não SDA com RM = 2,9 e SDA com RM=3,4, apontam uma

pequena divergência entre os dois grupos, porém, pelos valores é possível perceber que ambos

os grupos tendem a ser indiferentes com a questão, com certa inclinação para discordância por

parte dos não SDA e concordância dos SDA.

Q5 - O sistema fornece ajuda para reconhecer, diagnosticar e recuperar-se de erros.

Os resultados dos não SDA com RM = 4,3 e SDA com RM=3,4, apontam divergência

entre os dois grupos, onde o grupo de não SDA inclina-se para concordância com a questão e o

grupo de SDA inclina-se para indiferença, isso mostra que o grupo não se sentiu confiante ao

concordar com a questão.

7.1.3.2.3 Comparativo JAD x JGasp

O teste T de Student pareado foi aplicado para os resultados de RM das duas

ferramentas para cada grupo (Figura 33), a fim de verificar se existem diferenças significativas

na avaliação de usabilidade referente às questões acrescidas.

Figura 33 – Valores de RM submetidos ao teste T de Student.


Inicialmente aplicamos o teste para o grupo de não-SDA. O resultado t (5) 4,2208,

p=0,0135 aponta que para o grupo de não-SDA existe uma diferença significativa para uma

77

avaliação positiva do JAD em relação ao JGrasp. Quando aplicado o mesmo teste para o grupo

de SDA, o resultado t(5) = 3,9231, p = 0,0172 aponta que para o grupo de SDA também existe

uma diferença significativa para uma avaliação positiva do JAD em relação ao JGrasp.

7.2 CAPTURA DE TELA E ANÁLISE CRÍTICA

Foram capturadas aproximadamente 5h de vídeos com 48 interações, sendo 24 delas

utilizando o JAD e 24 para o JGrasp. Com a análise de vídeo como é mostrado nas Figuras 34 e

35, foi possível perceber que para os usuários SDA alguns ícones eram confusos, tanto no JAD

como no JGrasp. Em alguns momentos eles clicaram nos ícones apenas para saber qual ação

seria executada, como se não tivessem segurança sobre qual ação seria executada. Foi possível

perceber que SDA e não-SDA utilizaram muitas vezes recurso de legenda para identificar a

funcionalidade de um botão em ambas as ferramentas, como é mostrado nas Figuras 34 e 35.

Figura 34 – Contexto de depuração com JGrasp.


A leitura da legenda foi outra barreira encontrada pelos participantes SDA e não-

78

SDA, pois o texto para os tooltip encontrados no JGrasp estava escrito em inglês. Foi possível

observar que em ambas as ferramentas esse foi um recurso bem utilizado pelos participantes

para compreender os ícones e encontrar funcionalidades. No JAD, como é mostrado na Figura

35, os ícones e botões possuem legendas em português.

Figura 35 – Participante utilizando o recurso de legenda no JAD.


Na Figura 36, é mostrado um participante surdo utilizando-se do recurso de erros

em Libras. É possível perceber a atenção do usuário para compreensão do vídeo. Na análise

de vídeo verificou-se que o participante visualizou duas vezes o vídeo em Libras e logo após

conseguiu corrigir o erro, obtendo sucesso na tarefa.

Para alguns surdos, as caixas de diálogos do JAD eram compreendidas como diálogos

de erro mesmo estando na cor azul; demorou para que alguns compreendessem que era apenas

uma caixa de diálogo com os valores das variáveis e objetos. No JGrasp a quantidade de

funcionalidades dispostas fez com que os participantes tanto surdos como ouvintes encontrassem

a função desejada, levando os usuários a passear pelos ícones e ler a legenda de cada um para

identificar a função que gostariam de realizar.

79

Figura 36 – Participante surdo se beneficiando do recurso de erros em Libras.


7.3 ANÁLISE QUALITATIVA

Durante a aplicação do questionário SUS, os participantes relataram de forma livre,

caso tivessem interesse, sobre o porquê de suas escolhas para cada questão do questionário.

Estes relatos geraram um documento disponível no Apêndice A, no qual são mostrados os

comparativos dos feedbacks dados pelos participantes SDA e não-SDA para cada ferramenta.

Foram relatados pelos dois grupos de usuários vários feedbacks positivos e negativos, em relação

ao JAD e ao JGrasp.

Alguns dos pontos fortes citados pelos participantes são a interatividade, simplicidade

, navegação intuitiva, e, para o grupo de SDA, o vídeo em libras para os erros de código foi um

diferencial, embora tenha sido indicado que ainda é preciso aplicar algumas melhorias na forma

como o vídeo é apresentado. Para alguns usuários o JAD pareceu confuso no início da interação

e, ao longo da tarefa, o participante foi se adaptando à interface.

Para o JGrasp, embora, para alguns participantes, a ferramenta tenha parecido simples

e fácil, foram relatadas muitas dificuldades para identificar as funcionalidades necessárias para

execução da tarefa. No grupo de surdos, surgiram alguns relatos sobre a falta de intérpretes de

80

Libras para o JGrasp, mostrando que este é um recurso realmente necessário e importante para

esse público. Os relatos mostram que, embora o JGrasp seja uma boa opção para a depuração e

desenvolvimento de código Java, ainda possui alguns desafios de usabilidade a ser vencidos.

Ao final de uso das duas ferramentas, os participantes eram convidados a votar

na ferramenta de sua preferência. Foi dado um papel para que eles escrevessem o nome da

ferramenta de sua preferência. Ao final, obteve-se o resultado de 16 votos para o JAD, 4 para

JGrasp, e 4 participantes não participaram da votação. Na Figura 37 são mostrados os papéis

com as opções dos participantes.

Figura 37 – Resultado da votação realizada pelos participantes.


81

8 CONCLUSÕES E TRABALHOS FUTUROS

O JAD foi concebido a partir da necessidade identificada, inicialmente pela obser-

vação de como alunos SDA se comportavam durante a codificação e depuração de um código

Java, onde estes encontram várias barreiras, entre elas a dificuldade de compreensão da lógica e

complexidade das IDEs de desenvolvimento. Foram traçados e realizados alguns experimentos

para atestar e apontar as dificuldades encontradas por SDA. Partiu-se da hipótese de que alunos

SDA egressos de um curso Java teriam desempenho inferior ao de seus homólogos ouvintes

durante a depuração de um código Java. Realizou-se um estudo experimental com objetivo de

verificar se esta seria uma hipótese válida. Aplicou-se a técnica de análise da situação para SDA

e não SDA, assim, fez-se possível analisar como os grupos realizavam as tarefas de depuração e

quais os problemas encontrados por eles. Os resultados apontaram que não SDA encontravam

menos barreiras de usabilidade e compreensão das tarefas, levando-os a um melhor desempenho

durante a depuração em relação aos SDA. Os resultados tornam válido o argumento de que SDA

de um curso Java teriam desempenho inferior ao de seus homólogos ouvintes (NASCIMENTO;

OLIVEIRA; FREITAS, 2014).

Dada a problemática identificada, buscou-se na literatura estudos e intervenções

que poderiam mitigar o problema vivido por SDA, removendo as barreiras de usabilidade e

performance encontradas para que os mesmos pudessem igualar seu desempenho ao de seus

homólogos não SDA. Encontrou-se na literatura que o uso de representações e esquemas visuais

é um forte preditivo para auxiliar SDA na compreensão de coisas abstratas. Com isso, realizou-se

um estudo experimental sobre a hipótese de que depuradores visuais poderiam atenuar a diferença

de desempenho entre SDA e não SDA durante a depuração de um código Java. Realizou-se

um estudo comparativo entre duas ferramentas de depuração (IDE Eclipse e outra o JGrasp que

possui mais recursos visuais). A comparação foi realizada sobre a perspectiva de uso dos usuários

SDA, onde um grupo de SDA realiza a tarefa de depuração no Eclipse, enquanto outro utiliza

o JGrasp. Os resultados apontaram que, embora não haja diferenças significativas em relação

ao tempo gasto na tarefa de depuração e evolução de código pelos dois grupos, os participantes

tiveram maior êxito utilizando o JGrasp, além disso em uma avaliação de usabilidade realizada, o

JGrasp obteve melhores resultados sobre o Eclipse. Esses resultados tornam evidentes o potencial

e impactos que uma ferramenta que utiliza-se de esquemas interativos e visuais pode gerar sobre

a performance de SDA durante a depuração de um código (NASCIMENTO et al., 2015).

O JAD foi projetado a partir dos estudos realizados previamente. Suas funcionali-

82

dades e design são resultados dos estudos experimentais, onde foi realizada ampla pesquisa de

interação, além de coleta e análise dos feedbacks dos usuários. Espera-se que o JAD, aliado

ao JLOAD (Objeto de aprendizado citado em 3.4 ), com seus recursos de acessibilidade, possa

atenuar ainda mais as dificuldades encontradas por SDA durante o processo de evolução de

um código. Para tais constatações, realizaram-se experimentos com o objetivo de validar as

hipóteses de que SDA e não SDA teriam desempenho similar utilizando o JAD e que o JAD

teria melhor avaliação de usabilidade em relação ao JGrasp. Identificou-se que o JAD pode ser

um boa alternativa para SDA e não SDA, tendo bons resultados para ambos os grupos. Não

houve diferença significativa de desempenho no uso das ferramentas por parte de ambos os

grupos( SDA e não SDA). Embora os participantes não tenham alcançado melhores resultados de

desempenho no JAD, a ferramenta cumpre seu papel equiparando SDA e não SDA no processo

de evolução de um código Java.

Os resultados ratificam que representações esquemáticas, interativas e acessíveis

podem quebrar barreiras de usabilidade e compreensão encontradas por SDA e não SDA, tendo

em vista os bons resultados alcançados por ambos os grupos com a utilização do JAD. Espera-se

que o JAD, como ferramenta de depuração integrada a um objeto de aprendizagem (JLOAD),

possa auxiliar nas primeiras lições de codificação, sendo um forte auxílio para o aprendizado

de Java. Busca-se em trabalhos futuros realizar a validação da ferramenta aplicando testes

experimentais com uma população maior de SDA e, assim, validar a eficácia da ferramenta e sua

importância para o ensino e aprendizado de Java, levando para SDA as mesmas oportunidades de

aprendizado que possuem os não SDA, equiparando o desempenho de ambos para que possam

concorrer em mesmo nível de competência no mercado de trabalho.

Por fim, a presente pesquisa permitiu a publicação de três artigos em conferências:

• How do deaf or hearing impaired programmers perform in debugging java code?

(NASCIMENTO; OLIVEIRA; FREITAS, 2014);

• Visual deguggers and the deaf: paving the way to workplace

(NASCIMENTO et al., 2015);

• Visual Debuggers and Deaf Programmers

(NASCIMENTO et al., 2016).

83

REFERÊNCIAS

ALEXANDRE, D. S.; TAVARES, J. Factores da percepção visual humana na visualizaçãode dados. In: CONGRESSO IBERO LATINO-AMERICANO SOBRE MÉTODOS COMPU-TACIONAIS EM ENGENHARIA, ABMEC, 28., 2007, Porto. Anais... Porto, Portugal, 2007.p. 211.

BARBOSA, H. H. Habilidades matemáticas iniciais em crianças surdas e ouvintes. RevistaCadernos Cedes, v. 33, n. 91, p. 333–347, 2013.

BARBOSA, S.; SILVA, B. Interação humano-computador. Rio de Janeiro: Elsevier Brasil,2010.

BARROS, T.; SILVA, M.; ESPÍNOLA, E. State mvc: Estendendo o padrão mvc para usono desenvolvimento de aplicações para dispositivos móveis. In: CONFERÊNCIA LATINO-AMERICANA EM LINGUAGENS DE PADRÕES PARA PROGRAMAÇÃO, SBC, 6., 2007,Rio de Janeiro. Anais... Rio de Janeiro, Brasil, 2007. p. 123.

BAVELIER, D.; DYE, M. W.; HAUSER, P. C. Do deaf individuals see better? Trends inCognitive Sciences Journal, v. 10, n. 11, p. 512–518, 2006.

BLATTO-VALLEE, G.; KELLY, R. R.; GAUSTAD, M. G.; PORTER, J.; FONZI, J. Visual-spatial representation in mathematical problem solving by deaf and hearing students. Journal ofDeaf Studies and Deaf Education, v. 12, n. 4, p. 432–448, 2007.

BRANDÃO, L. de O.; BRANDÃO, A. A. F.; RIBEIRO, R. da S. ivprog, uma ferramentade programaçao visual para o ensino de algoritmos. In: CONGRESSO BRASILEIRO DEINFORMÁTICA NA EDUCAÇÃO, SBC, 1., 2012, Uberlândia. Anais... Uberlândia, Brasil,2012. p. 19.

BROOKE, J. Sus, a quick and dirty usability scale. Usability Evaluation in Industry Journal,v. 189, n. 194, p. 4–7, 1996.

BULL, R.; BLATTO-VALLEE, G.; FABICH, M. Subitizing, magnitude representation, andmagnitude retrieval in deaf and hearing adults. Journal of Deaf Studies and Deaf Education,v. 11, n. 3, p. 289–302, 2006.

CARD, S. K.; MACKINLAY, J. D.; SHNEIDERMAN, B. Readings in information visualiza-tion: using vision to think. Burlington: Morgan Kaufmann, 1999.

CATTANEO, G.; FARUOLO, P.; PETRILLO, U. F.; ITALIANO, G. F. Jive: Java interactivesoftware visualization environment. In: CONFERENCE ON VISUAL LANGUAGES ANDHUMAN CENTRIC COMPUTING, IEEE, 8., 2004, Rome. Proceedings... Rome, 2004. p.41–43.

CONSELHO NACIONAL DE TRâNSITO. Manual Brasileiro de Sinalização de Trânsito:Sinalização vertical de regulamentação. 2007. Disponível em: <http://www.denatran.gov.br/images/Educacao/Publicacoes/MANUAL_VOL_I.pdf>. Acesso em: 20 set. 2016.

CROSS, J. H.; HENDRIX, D.; UMPHRESS, D. A. Jgrasp, an integrated development envi-ronment with visualizations for teaching java in cs1, cs2, and beyond. In: FRONTIERS INEDUCATION CONFERENCE, IEEE, 34., 2004, Savannah. Proceedings... Savannah, USA,2004. p. 1466–1467.

http://www.denatran.gov.br/images/Educacao/Publicacoes/MANUAL_VOL_I.pdf

http://www.denatran.gov.br/images/Educacao/Publicacoes/MANUAL_VOL_I.pdf

84

CROSS, J. H.; HENDRIX, T. D.; JAIN, J.; BAROWSKI, L. A. Dynamic object viewers fordata structures. Special Interest Group on Computer Science Education Bulletin, v. 39, n. 1,p. 4–8, 2007.

CRUPI, J.; MALKS, D.; ALUR, D. Core J2EE Patterns. Houston: Gulf Professional Pu-blishing, 2001.

CURY, R. F. et al. Interfaces gráficas referencialmente claras e sua utilização na criaçãode laboratórios para a aprendizagem a distância on-line. Tese (Doutorado em EngenhariaElétrica) — Universidade Federal de Uberlândia, Uberlândia, 2008.

CYPHER, A.; HALBERT, D. C. Watch what I do: programming by demonstration. Cambridge:MIT press, 1993.

DELL INC. Laboratório de Educação a Distância para Pessoas com Deficiência. 2017.Disponível em: <http://www.projetolead.com.br>. Acesso em: 16 jan. 2017.

GESUELI, Z. M.; MOURA, L. de. Letramento e surdez: a visualização das palavras. Jornal daEducação Temática Digital, v. 7, n. 2, p. 110–122, 2006.

GOMES, M.; BECKER, L.; GESTARO, L.; AMARAL, E.; TAROUCO, L. M. R. Um estudosobre erros em programação: Reconhecendo as dificuldades de programadores iniciantes. In:CONGRESSO BRASILEIRO DE INFORMÁTICA NA EDUCAÇÃO, SBC, 4., 2015, Maceió.Anais... Maceió, 2015. p. 1398.

GONÇALVES, E.; VILELA, J.; PEIXOTO, M.; OLIVEIRA, F.; CASTRO, J. Produção de vide-oaulas de programação em java acessíveis no contexto de um projeto de capacitação profissionalpara pessoas surdas. In: BRAZILIAN SYMPOSIUM ON COMPUTERS IN EDUCATION,SBC, 26., 2015, Maceió. Proceedings... Maceió, Brazil, 2015. p. 877.

GRACIANO, A. B. V. Rastreamento de objetos baseado em reconhecimento estrutural depadroes. Dissertação (Mestrado em Ciências da Computação) — Universidade de São Paulo,São Paulo, 2007.

HUTCHINS, E. L.; HOLLAN, J. D.; NORMAN, D. A. Direct manipulation interfaces. Human-Computer Interaction Journal, v. 1, n. 4, p. 311–338, 1985.

INSTITUTO BRASILEIRO DE GEOGRAFIA E ESTATíSTICA. Censo demográfico do Brasilde 2010. 2010. Disponível em: <http://www.censo2010.ibge.gov.br/>. Acesso em: 18 out. 2015.

JÚNIOR, C. G. F.; SOARES, J. M.; BARROSO, G. C.; CASTRO, L.; SOARES, M. I. da S.;JOYE, C. R.; FREITAS, A. T. de; SOARES, É. F. Um modelo para a produção de objetos deaprendizagem acessíveis: Modelagem e análise por redes de petri coloridas. In: BRAZILIANSYMPOSIUM ON COMPUTERS IN EDUCATION, SBC, 25., 2014, Dourados. Proceedings...Dourados, Brazil, 2014. p. 1143.

KUHN, A.; ERNI, D.; NIERSTRASZ, O. Towards improving the mental model of softwaredevelopers through cartographic visualization. In: INTERNATIONAL CONFERENCE ONSOFTWARE ENGINEERING, ACM/IEEE, 32., 2010, Cape Town. Proceedings... Cape Town,South Africa, 2010. p. 45–54.

LEAL, A. V. d. A. Ensino de Programação no Ensino Médio Integrado: Uma abordagemutilizando padrões e jogos com materiais concretos. Dissertação (Mestrado em Ciência daComputação) — Universidade Federal de Goiás, Goiânia, 2014.

http://www.projetolead.com.br

http://www.censo2010.ibge.gov.br/

85

LEITÃO, C. F.; SILVEIRA, M. S.; SOUZA, C. S. de. Uma introdução à engenharia semiótica:conceitos e métodos. In: BRAZILIAN SYMPOSIUM ON HUMAN FACTORS IN COMPU-TING SYSTEMS, SBC, 12., 2013, Manaus. Proceedings... Manaus, Brasil, 2013. p. 356–358.

LEITE, J. C. Modelos e formalismos para a engenharia semiótica de interfaces de usuário.Tese (Doutorado em Ciências em Informática) — Pontifícia Universidade Católica do Rio deJaneiro, Rio de Janeiro, 1998.

LEWIS, J. R.; SAURO, J. The factor structure of the system usability scale. In: INTERNATIO-NAL CONFERENCE ON HUMAN CENTERED DESIGN, SPRINGER, 1., 2009, San Diego.Proceedings... San Diego, USA, 2009. p. 94–103.

LINHARES, M. Introdução ao Hibernate 3. 2012. Disponível em: <http://www.guj.com.br/content/articles/hibernate/intruducao\_hibernate3\_guj.pdf>. Acesso em: 31 out. 2016.

MANN, H. B.; WHITNEY, D. R. On a test of whether one of two random variables is stochasti-cally larger than the other. The Annals of Mathematical Statistics Journal, v. 6, n. 3, p. 50–60,1947.

MCNEMAR, Q. Note on the sampling error of the difference between correlated proportions orpercentages. Psychometrika Journal, v. 12, n. 2, p. 153–157, 1947.

MORENO, A.; JOY, M. S. Jeliot 3 in a demanding educational setting. Electronic Notes inTheoretical Computer Science Journal, v. 178, n. 8, p. 51–59, 2007.

NASCIMENTO, H. A. D. D. Uma introdução à visualização de informações. Revista Visuali-dades, v. 9, n. 2, p. 13–43, 2012.

NASCIMENTO, M. D. do; OLIVEIRA, F. C. d. M. B.; FREITAS, A. T. de. How do deaf orhearing impaired programmers perform in debugging java code? In: BRAZILIAN SYMPOSIUMON COMPUTERS IN EDUCATION, SBC, 25., 2014, Dourados. Proceedings... Dourados,Brazil, 2014. p. 593.

NASCIMENTO, M. D. do; OLIVEIRA, F. C. d. M. B.; FREITAS, A. T. de; SILVA, L. C.Visual debuggers and deaf programmers. In: INTERNATIONAL CONFERENCE ON UNIVER-SAL ACCESS IN HUMAN-COMPUTER INTERACTION, SPRINGER, 10., 2016, Toronto.Proceedings... Athens, Greece, 2016. p. 26–37.

NASCIMENTO, M. do; OLIVEIRA, F.; FREITAS, A.; SILVA, L. C. Visual debuggers and thedeaf: paving the way to workplace. In: BRAZILIAN SYMPOSIUM ON COMPUTERS INEDUCATION, SBC, 26., 2015, Maceió. Proceedings... Maceió, Brazil, 2015. p. 792.

NIELSEN, J. Usability engineering. Amsterdam: Elsevier, 1994.

NIELSEN, J.; LANDAUER, T. K. A mathematical model of the finding of usability problems.In: CONFERENCE ON HUMAN FACTORS IN COMPUTING SYSTEMS, ACM, 1., 1993,New York. Proceedings... New York, USA, 1993. p. 206–213.

NIUZA, L. Metáforas e Interfaces Gráficas: Contribuições para uma aprendizagem significa-tiva da informática. Dissertação (Mestrado em Educação Tecnológica) — Centro Federal deEducação Tecnológica de Minas Gerais, Belo Horizonte, 2008.

NOGUEIRA, C. M. I.; ZANQUETTA, M. E. M. Surdez, bilingüismo eo ensino tradicionalde matemática: uma avaliação piagetiana. Revista de Educação Matemática Zetetiké, v. 16,n. 30, p. 219–237, 2009.

http://www.guj.com.br/content/articles/hibernate/intruducao\_hiber nate3\_guj.pdf

http://www.guj.com.br/content/articles/hibernate/intruducao\_hiber nate3\_guj.pdf

86

NUNES, T.; MORENO, C. Is hearing impairment a cause of difficulties in learning mathe-matics? In: DONLAN, C. (Ed.). The development of mathematical skills. United Kingdom:Psychology Press Hove, 1998. cap. 10, p. 227–254.

OLIVEIRA, H. R. d. Argumentação no Ensino de Ciências: O uso de analogias como recursopara a construção do conhecimento. Dissertação (Mestrado em Educação) — UniversidadeFederal de Juiz de Fora, Juiz de Fora, 2012.

OLIVEIRA, L. A. de. A escrita do surdo: relação texto e concepção. 2001. Disponível em:<http://www.afirse.com/archives/cd3/tematica1/048.pdf>. Acesso em: 03 jun. 2016.

OLIVEIRA, L. H. d. Exemplo de Cálculo de Ranking Médio para Likert. 2005. Disponívelem: <www.administradores.com.br/producao-academica/ranking-medio-para-escala-de-likert/28/download>. Acesso em: 18 nov. 2016.

PERLIN, G. O lugar da cultura surda. In: THOMA, A. da S.; LOPES, M. C. (Ed.). A invençãoda surdez: cultura, alteridade, identidade e diferença no campo da educação. Santa Cruz do Sul:Edunisc, 2004. cap. 3, p. 73–82.

PETER, D. Being deaf. 2012. Disponível em: <http://www.davidpeter.me/stories/being-deaf>.Acesso em: 31 set. 2015.

PINTO, M. A. d. S.; GOMES, A. M. d. S.; NICOT, Y. E. A experiência visual como elementofacilitador na educação em ciências para alunos surdos. Revista Amazônica de Ensino deCiências, v. 5, n. 09, p. 110–118, 2014.

REITZ, L. P.; CASTIÑEIRA, M. I.; SCHUHMACHER, V. R. Testes automatizados comferramentas de software livre: um estudo de caso. In: CONGRESSO SUL BRASILEIRO DECOMPUTAÇÃO, SBC, 7., 2015, Criciúma. Anais... Criciúma, Brasil, 2015. p. 79–83.

ROSE, A.; PLAISANT, C.; SHNEIDERMAN, B. Using ethnographic methods in user interfacere-engineering. In: SYMPOSIUM ON DESIGNING INTERACTIVE SYSTEMS, ACM, 1.,1995, Miami. Proceedings... Miami, USA, 1995. p. 115–122.

SAURO, J.; LEWIS, J. R. Quantifying the user experience: Practical statistics for user research.Amsterdam: Elsevier, 2012.

SHAPIRO, S. S.; WILK, M. B. An analysis of variance test for normality (complete samples).Biometrika Journal, v. 52, n. 3/4, p. 591–611, 1965.

SILVA, L. C.; OLIVEIRA, F. C. de M.; OLIVEIRA, A. C. de; FREITAS, A. T. de. Introducingthe jload: A java learning object to assist the deaf. In: INTERNATIONAL CONFERENCE ONADVANCED LEARNING TECHNOLOGIES, IEEE, 14., 2014, Athens. Proceedings... Athens,Greece, 2014. p. 579–583.

SKINNER, J. Sublime Text: Editor de texto sofisticado para códigos html, css e javascript. 2013.Disponível em: <https://www.sublimetext.com>. Acesso em: 29 jun. 2016.

SORVA, J.; KARAVIRTA, V.; MALMI, L. A review of generic program visualization systemsfor introductory programming education. Transactions on Computing Education Journal,v. 13, n. 4, p. 15, 2013.

TECNOLóGICO, C. TAW: Ferramenta para análise de acessiblidade conforme a w3c. 2017.Disponível em: <http://www.tawdis.net>. Acesso em: 10 jan. 2017.

http://www.afirse.com/archives/cd3/tematica1/048.pdf

www.administradores.com.br/producao-academica/ranking-medio-para-escala-de-likert/28/download

www.administradores.com.br/producao-academica/ranking-medio-para-escala-de-likert/28/download

http://www.davidpeter.me/stories/being-deaf

https://www.sublimetext.com

http://www.tawdis.net

87

TOSCANO, L. C.; DIZEU, B.; CAPORALI, S. A. A língua de sinais constituindo o surdo comosujeito. Revista Educação & Sociedade, v. 26, n. 91, p. 583–597, 2005.

W3C. Web Content Accessibility Guidelines 2.0. 2008. Disponível em: <https://www.w3.org/TR/WCAG20/>. Acesso em: 17 jun. 2016.

WILCOXON, F. Individual comparisons by ranking methods. Biometrics Bulletin, v. 1, n. 6, p.80–83, 1945.

WILSON, M.; EMMOREY, K. Comparing sign language and speech reveals a universal limit onshort-term memory capacity. Psychological Science Journal, v. 17, n. 8, p. 682–683, 2006.

ZOGBI, P. Conheça o setor que tem mais vagas que profissionais no Brasil.2016. Disponível em: <http://www.infomoney.com.br/carreira/emprego/noticia/4447259/conheca-setor-que-tem-mais-vagas-que-profissionais-brasil>. Acesso em: 25 ago. 2016.

https://www.w3.org/TR/WCAG20/

https://www.w3.org/TR/WCAG20/

http://www.infomoney.com.br/carreira/emprego/noticia/4447259/conheca-setor-que-tem-mais-vagas-que-profissionais-brasil

http://www.infomoney.com.br/carreira/emprego/noticia/4447259/conheca-setor-que-tem-mais-vagas-que-profissionais-brasil

88

APÊNDICES

89

APÊNDICE A – Depoimentos

Feedback dos participantes a respeito das ferramentas JAD e JGRASP

A.1 FEEDBACK DOS PARTICIPANTES SOBRE O JAD

A.1.1 Participantes SDA

1. Eu gostaria de usar este sistema com frequência.

• Porque na primeira vez no JAD me fez entender todo o processo, mas precisa

conhecer o sistema e as setas facilitaram

• Porque o sistema é maravilhoso

• Sim, pois o modo de visualização é agradável e gosto de java

• O sistema é um pouco confuso

• Pois é mais rápido encontrar o erro, e ajuda muito, e também dá pra identificar a

certeza.

2. O sistema é desnecessariamente complexo.

• Porque não tem muita interação

• O sistema é bem interativo.

• Porque em relação as palavras são muito detalhadas e são muitas informações, mas

com esforço é possível conseguir.

• Porque é difícil

• Um pouco, por causa da resolução, que faz ficar um pouco complexo.

3. O sistema foi fácil de usar.

• Porque é um sistema adaptável aos surdos. Mas a relação quando ele começa não

mostra que ele começou, se tiver a opção avançar ficaria melhor.

• Em relação as setas não são muito acessíveis e a sugestão seria mudar para o botão

"avançar” para identificar melhor.

• Foi difícil de utilizar.

• É fácil, mas por ser o primeiro uso não teve muito interação, entretanto com o tempo

consegue desenvolver e utilizar a ferramenta.

• Porque a dificuldade com relação ao contexto do vídeo.

• Sim, pois é adequado a forma das cores.

• Sim, pois pra mim que já tenho o conhecimento ficou mais claro.

90

4. Eu acho que eu iria precisar de ajuda técnica de alguém para ser capaz de usar este sistema.

• Porque o sistema não é muito complexo e tem pouca interação.

• Porque se por exemplo ele não consegue resolver o problema precisaria chamar

alguém para auxiliar.

• Pois o sistema possibilita um bom entendimento.

• Depende de cada pessoa com seu desenvolvimento.

• Porque preciso de mais experiência e junto com o técnico o conhecimento se abrange,

por isso cada funcionalidade se evolui.

• Sim, pois para alunos novatos são bem importantes pois eles não tem um conheci-

mento profundo, diferente dos que já tem.

5. As diversas funções deste sistema são bem integradas.

• Porque ele já conhece a área de informática e já tem contato com essa técnica e ele já

tem conhecimento nessa área.

• Elas são bem integradas, porque me ajudam a encontrar o erro.

• Pois cada função é diferente no entendimento.

6. Existem muitas coisas despadronizadas no sistema.

• Os ícones precisam mudar.

• É um pouco confuso, porque na imagem o intérprete avisa mas não consegue identi-

ficar o erro.

• O sistema possui muitas regras e ajuda a desenvolver facilmente o que se pede.

• Pois o sistema é bem visível, mas atrapalha um pouco a estrada no lado da tela.

7. Muitas pessoas aprenderiam usar rapidamente o sistema

• O JAD é mais fácil de usar se comparado com o JGRASP.

• Vai variar de pessoa para pessoa

• Depende do conhecimento do usuário, pois antes no Java não tinha essa interação

mas agora é possível obter.

• Porque as pessoas precisam ter a prática antes, pois se tiverem elas conseguem

responder.

• Depende de cada pessoa

• Pois cada função tem um certo tempo de aprendizado.

• Depende de cada pessoa, e também depende do interesse que a pessoa dá ao assunto

referente.

8. O sistema é muito complicado de usar.

91

• No começo é bem complicado

• Na hora de começar a utilizar não consegue entender bem mais com o uso adquiri

conhecimento sobre a ferramenta.

• Porque não está acostumado coma interação com o JAD.

• Porque falta o contexto e estratégia a interpretação do intérprete.

• Pois faltam algumas adequações na janela de libras

9. Eu me senti muito confiante com o sistema.

• Pode variar de usuário para usuário.

• Pois não tem afinidade com o sistema.

• Porque o sistema proporciona cada ação para o entendimento seja mais claro.

• Pois avisa cada erro e assim ajuda para resolver o código.

• Pois cada linha tem um certo tipo de visualidade, mas a estrada ao lado, não é

agradável.

10. É preciso aprender muitas coisas antes usar o sistema.

• Porque muitas pessoas usam a programação e não se sabe como vão utilizar, mas o

sistema ajuda a encontrar a linha do erro.

• Porque precisa ter um conhecimento prévio.

• Sim, pois é bom ter como base o assunto prévio.

A.1.2 Participantes não SDA


• É fácil utilizar e ele faz com simplicidade o que promete.

• Porque o sistema facilita o aprendizado em Java, principalmente para os iniciantes.

• Por conta da facilidade online e objetivo.

• Pois a interface é fácil e o idioma em português.

• Porque o JAD é simples e prático.

• Porque é bem intuitivo e fácil, em termo de usabilidade

• Porque o layout é agradável, o gráfico do processo também é bom e ele é prático de

utilizar.

• Ele auxilia na construção e validação do código.

• Na questão de cada vez mais de se capacitar.


92

• Ele não é complexo e sim intuitivo.

• Porque o sistema de visualização na estrada facilita.

• É facilmente compreensível.

• Não achou complexo.

• Acho o sistema intuitivo.

• Porque a ferramenta é bastante simples.

• Ele só seria complexo para quem não tem o conhecimento.


• Foi intuitivo, a ferramenta é bem prática.

• Faltou mais orientações sobre o real trabalho que iria executar.

• Ele atende de maneira objetiva a proposta ofertada.

• A interface e ícones são fáceis de entender.

• Poucas funcionalidades e as funcionalidades eram intuitivas.

• Não foi encontrada dificuldade na utilização da ferramenta.

• A dificuldade de utilização foi a pouca habilidade em programação.

• Por ele mostrar onde tem o erro do código


•

• Ele é simples.

• Porque se tiver comandos explícitos será mais fácil.

• Que o ponto de partida não ficou claro em primeiro momento.

• Acho fácil de usar.

• Talvez possa surgir pontos de dúvidas no decorrer do processo.

• Pelo o conhecimento ser básico.

• As dúvidas podem ser consultadas pela internet, em tutoriais e etc.


• Não utilizou todas as funções.

• Por ele ser de fácil utilização.

• A princípio as funções são bem integradas.


• inicialmente foi fácil identificar a função de cada item.

• Porque não encontrou nada que pudesse chamar atenção de forma negativa.


93


• Mas teria que ter um conhecimento da linguagem.

• Porque vai depender do comando inicial que a pessoa vai ter.

• Pois é facilmente intuitivo e o feedback da aplicação é claro e compreensivo.

• Devido a interface ser fácil de usar

• Por conta da simplicidade da ferramenta.

• Vai depender do grau de conhecimento em programação.

• Porque os usuários ao utilizar a ferramenta já podem ter experiência em outros

programas semelhantes

• Por conta da ferramenta ser fácil

• Pra quem ta iniciando não teria nenhuma dificuldade de usar a ferramenta


• A ferramenta é simples.


• A ferramenta segue o mesmo padrão das que já existem no mercado, porém tem

incrementos gráficos e técnicos mais modernos.

• Por conta da ferramenta ser fácil de usar.


• Porque nós conseguimos executar e logo ao lado visualizar a aplicação do código.

• Permite o controle de cada etapa.

• A interface permite uma fácil visualização dos itens.

• A ferramenta com o decorrer do uso deixou o confiante.

• Por conta do conhecimento e do treinamento ajudou bastante com a ferramenta.

• Por ele identificar o erro e tenha mais confiança em elaborar o código.


• A ferramenta é simples.

• Aprender a linguagem JAVA

• Como observação é necessário ter o conhecimento em introdução à programação.

• Só precisaria aprender a linguagem Java.

• A linguagem de programação.

• Ter um conhecimento básico em lógica e programação.

• Saber o básico sobre programação.

94

A.2 FEEDBACK DOS PARTICIPANTES SOBRE O JGRASP

A.2.1 Participantes SDA


• Não, eu não uso muito, minha área de trabalho é diferente.

• Sim, gostei do uso.

• A interface é difícil e não tem auxílio, ela não auxilia em nada.

• Achei ótimo.

• É muito difícil.

• Discordo, pois o nível de programação é profunda, e isso atrapalha, pois o erro só é

reconhecido na outra linha.


• Sim, no começo é bastante difícil mas depois com a prática se tornou fácil.

• Sim , no começo, mas depois ficou mais fácil.

• Sim, a aba que fica em baixo onde identifica o erro é de difícil o entendimento.

• Porque falta acessibilidade, intérprete e vídeos.

• Porque o interface é boa.

• Sim, é muito difícil entendi pouca coisa.

• É muito difícil a usabilidade dele.

• Pois o ícone é muito extenso.e também o compilador é muito difícil de entender.


• Os símbolos ajudaram a entender.

• Achei muito fácil

• Não consegui entender muita coisa.

• Muito difícil de usar, linguagem é muito pesada

• Eu tive bastante dificuldade de usar .

• Depende de cada pessoa com seu nível de aprendizagem.


• Sim , no começo para conhecer as etapas e depois começar a utilizar.

• Sim, no começo.

• Sim, se eu não tiver ajuda vou demorar mais para resolver os erros.

• É preciso porque a usabilidade do sistema é bem difícil.

95

• Precisa, pois o sistema é complexo mas a linguagem é bastante técnica e por isso é

preciso ter um técnico auxiliando.

• Sim, no caso de dúvidas o técnico poderia me ajudar.

• Precisa de muita ajuda, pois é bem difícil de localizar as funções.

• Como ainda não tenho muita experiência, precisaria de alguém para me auxiliar e

tirar minhas dúvidas.

• Sim, pois dependendo da programação precisa de ajuda para esclarecer algumas

dúvidas.


• Como eu já utilizo se tornou mais fácil para eu usar, como já tenho convívio com

com outras ferramentas para mim se tornou mais fácil

• Sim , porque as etapas são claras, minha experiência é que foi complicada

• Sim, o sistema avisa onde está o erro

• É bem integrada, porém o entendimento não é claro.

• Pois falta acessibilidade.

• Não são bem integradas

• Sim, pois dá pra entender bem, mas precisa de prática.


• Achei pouco acessível para pessoas com deficiência visual e usuários iniciantes, pois

a interface apresenta ícones pequenos.

• Sim, não é acessível.

• Falta acessibilidade no sistema.

• É ruim de utilizar

• É muito despadronizado.

• Sim existem, porque o ambiente é diferente.


• Com a prática o usuário se acostuma.

• Não, porque o sistema é bastante complexo, principalmente para pessoas que não

tem conhecimento na área.

• Depende de cada pessoa, o aprendizado de cada um é diferente.

• Vai depender de cada usuário.

• Só aprenderiam rápido as pessoas que tivessem alguma prática.

• Porque o visual é fácil de aprender.

96

• Depende de cada pessoa.

• Acho que demorariam a aprender.

• No meu caso eu não aprenderia rápido, precisaria de tempo para conhecer o sistema

melhor , pois ele é bastante difícil.

• Depende de cada pessoa, por exemplo se for um aluno novo, ele não sabe como

proceder, mas já o profissional sim.


• Na minha opinião ele não é difícil, pois a interface é familiarizada para pessoas

envolvidas com a área de informática, por conta da usabilidade e design pois já tem

ícones sugestivos que facilitam a compreensão.

• Sim, para mim foi complicado.

• Sim, é complexo.

• O sistema não aponta exatamente onde está erro, na linha do teste eu não sabia onde

estava o erro.

• Não consigo ver complicação em nada, é fácil de operar.

• Sim, achei complicado.

• Achei simples o sistema, só eu que não sabia utilizar.


• Por ser da área.

• Não, não me senti confiante.

• Por que o sistema me proporcionou uma segurança.

• É bem complicado.

• Por falta de acessibilidade e linguagem em Inglês, causa insegurança.

• Não senti segurança com sistema, pois não senti afinidade.

• Me senti pouco confiante.


• Porque precisa de instruções para saber como fazer o teste, necessita de uma versão

em português para facilitar quem não sabe o inglês e não conhece o sistema.

• Sim, precisa de muita prática para utilizar.

• Sim, se não tiver conhecimento a pessoa não vai conseguir usar o sistema.

• Se a pessoa conhecer antes o java, fica mais fácil da pessoa operar.

• Precisaria aprender para ter mais conhecimento e dominar melhor a ferramenta.

• Sim, precisa ter conhecimento antes de usar.

97

• Sim, é necessário, até mesmo eu que passei por um treinamento foi difícil resolver

os erros.

• Precisa muito, precisa de treinamento.

• Sim, pois precisa saber antes cada função, pois a programação é diferente.

A.2.2 Participantes não SDA


• Porque aparentemente ela tem muitas ferramentas mas ela não é muito intuitiva, e eu

gostaria de aprender mais.

• Não, eu já tenho outra ferramenta na própria IDE que já utilizo.

• Sim, porque tem o controle de todo o processo e fica tudo documentado.

• Sim, o sistema é um pouco complexo mas depois que entendemos sua aplicabilidade

se torna prático.

• Não fiquei muito familiarizado com o sistema.

• Sim, se eu programasse com frequência.

• Porque a ferramenta é complicada e pouco intuitiva.

• Mesmo sendo complexo ele fácil de operar.

• Porque é bom para relembrar o que estudou antes


• Quando estou usando não facilita na compreensão, existem muitos ícones que execu-

tam a mesma função e quando é identificado o erro, é mostrado com muita informação

onde deixa o usuário confuso com tanta informação, poderia ser direto.

• Não, é intuitivo

• Não, as ferramentas não ficaram claras, parecem ambíguas pois apresentam a mesma

funcionalidade, não tem como fazer a diferenciação a primeira contato, provavel-

mente testando de outra forma ela apresenta uma funcionalidade diferente, mas

dentro desse código apresentam a mesma função, mas não é claro o que cada uma

faz.

• Sim, por falta de comandos iniciais para entendermos sua usabilidade.

• Como foi meu primeiro contato não sabia das funcionalidades, precisei de ajuda.

• Porque o JGRASP é muito complexo e o idioma é em inglês.

• Como não explorei muito o sistema, não achei coisas muito complexas.

98

• Que desenvolveu essa ferramenta deu uma complexidade desnecessária, pois o

mesmo é simples.


• Mesmo com pouco tempo eu consegue fazer teste, apesar de ter identificado dificul-

dades com sistema

• Sim, é intuitivo e funcionalidades já estão bem definidas.

• Sim, é fácil mas é carente de informação do uso básico, não tem ícones intuitivos

para facilitar o desenvolvimento do código em primeiro momento, mas é confuso

quanto a sua real funcionalidade, o símbolo de soma, é usado para compilar sendo

que sua representação remete a adicionar algo

• A organização da área de trabalho é um pouco confusa.

• No primeiro contato não sabia das funcionalidade e depurar o código, não estava

intuitivo.

• Os ícones da ferramenta não ajuda muito. E também tem muita informação sendo

apresentada: ícones em excesso.

• Por eu já ter conhecimento em programação, usar e encontrar os erros se tornaram

mais fáceis.

• É pouco didático e intuitivo.

• O sistema é fácil, eu que não tenho conhecimento.


• Nos primeiros contatos eu precisaria da ajuda de uma pessoa que conhecesse, para

poder me mostrar o sistema.

• Não, já tenho experiência com esse tipo de ferramenta.

• Não, a própria prática facilita a aprendizagem sem danificar o código testado.

• Sim, pelo menos até entender sua sistemática.

• Tive dúvidas referente as mensagens de erro do que deveria ser feito.

• Mesmo explorando o sistema ainda estava confuso quanto sua sistemática.

• Por conta das inúmeras informações apresentadas que deixam a ferramenta complexa.

• Para operar de forma mais avançada precisaria de ajuda, pois meu conhecimento é

básico.

• E fácil de operar por conta da sua simplicidade.

• Quem não sabe precisaria sim.


99

• Não, pois não são intuitivas.

• Não, suas funções são difíceis compreensão devido está em outro idioma.

• Existem similaridade com outros sistemas.

• Por conta das inúmeras informações apresentada na tela confundem um pouco e o

fato de quando apertamos o ícone apresenta outra tela em cima da anterior.

• Como não explorei muito o sistema, não posso fazer julgamento sobre o mesmo.


• Sim, o excesso de ferramentas que não mostra sua finalidade.

• Não, a padronização do sistema atende a sua proposta.

• Não, acredito que seja um padrão java, mas para um iniciante é um pouco complexo.

• Consegui identificar alguns ícones padrões, que já tinha visto em outros sistemas.

• Como não utilizei as ferramentas não tenho como ter noção da padronização.


• Sim, mas com auxílio de uma pessoa para ensinar.

• Não, tem muitas funcionalidades onde um iniciante ficaria perdido.

• Sim, mas a pessoa precisa ter o conhecimento básico de programação.

• Sim, depois que você entende sua sistemática você consegue desempenhar todas suas

funções.

• Não, sem o auxílio de um pessoa qualificada iria demorar.

• Em frequente contato, sim.

• Por conta da complexidade.

• Depende do nível de conhecimento de cada um que for usar, se torna mais rápido ou

mais lento.

• Por ser simples facilita o aprendizado.

• Para quem tem conhecimento em java seria fácil de aprender, mas para quem nunca

teve contato, talvez tivesse um pouco de dificuldade.

• Se pessoa souber programar aprende sim, se tiver conhecimento, caso contrário seria

bastante lento.


• Não, a única coisa que o usuário precisa saber um pouco, é inglês para facilitar na

hora da depuração.

• Sim, é difícil sua compreensão e entender suas regras.

• Não achei tão difícil mas encontrei dificuldade na usabilidade.

100

• Não é muito complicado, só não é tão intuitivo.

• Por conta da grande quantidade de ícones e também as informações são em inglês.

• Como não explorei ele como um todo, não tenho uma opinião formada.

• Por ser simples facilita o uso.


• Apesar do excesso de informação existem alguns ícones que facilitam a compreensão

e não deixa o usuário perdido.

• Sim, não tive dificuldade, testei dois tipos de soluções para saber se era flexível.

• Não, pois aparece muitos códigos que não são aplicados na ocasião.

• Como não tive experiência anterior não tinha como ter confiança.

• Como foi o primeiro contato não foi intuitivo, fiquei inseguro.

• Por conta das inúmeras informações apresentadas na tela.

• Dentro do que foi visto me senti confiante, pro nível de conhecimento que eu tenho

em programar.


• Pelo fato de eu conhecer um pouco de programação não senti dificuldade.

• Não me senti pela falta de conhecimento.


• Não, apesar da complexibilidade eu consegui fazer o teste.

• Não, basta saber um pouco de inglês.

• Sim, é necessário conhecer os erros básico dos comandos na linguagem de progra-

mação, já que o registro não deixa claro o erro, oferecendo apenas a exceção.

• Sim, para quem não tem um aprendizado prático em Java é difícil a compreensão.

• Sim, precisa de um pré conhecimento em códigos e idioma inglês.

• Precisa ter noções básicas de lógica de programação, para entender suas funcionali-

dades.

• Primeiro é preciso analisar a ferramenta.

• Precisaria aprender muito código, java e inglês.


• Tem conhecer outras ferramentas do eclipse, ter noção de programação e um básico

de inglês

• Precisa saber programar para poder utilizar o sistema de forma eficiente.

101

APÊNDICE B – Formulário de Observação

1) Observador:

2) Participante:

3) Hora de inicio:

4) Hora de conclusão:

5) Perfil: SDA( ) não-SDA( )

6) Conseguiu corrigir o primeiro erro?

Sim ( )

Não ( )

Horário:

7) Conseguiu corrigir o segundo erro ?

Sim ( )

Não ( )

Horário:

8) Quantidade de pedidos de auxilio sobre a ferramenta:

9) Quantidade de pedidos de auxilio sobre o código

10) Feedback do observador

11) Feedback do participante

102

APÊNDICE C – Questionário de Perfil Socioeducativo

1. Gênero

a) Masculino

b) Feminino

2. Indique sua idade

a) Menos de 20 anos

b) De 20 a 30 anos

c) De 31 a 40 anos

d) De 41 a 50 anos

e) Mais de 51 anos

3. Indique seu grau de escolaridade

a) Ensino médio incompleto

b) Ensino médio completo

c) Superior incompleto

d) Superior completo

e) Pós-graduação incompleta/Completa

4. Nível de conhecimento de Java

a) Muito pouco

b) Pouco

c) intermediário

d) Bom

e) Muito bom

5. Qual seu grau de surdez?

a) Leve

b) Moderada

c) Severa

d) Profunda

6. Como você avalia seu domínio de LIBRAS?

a) Muito pouco

b) Pouco

c) intermediário

d) Bom

103

e) Muito bom

7. Como você avalia seu domínio de Português?

a) Muito pouco

b) Pouco

c) intermediário

d) Bom

e) Muito bom

8. Você é Oralizado?

a) Sim

b) Não

104

APÊNDICE D – Termo de Consentimento Livre e Esclarecido

Eu (Nome do participante) , estou participando de uma pesquisa sob supervisão do Mestrando

em Ciência da computação Marcos Devaner do Nascimento, cujo objetivo é a validação de uma

ferramenta acessível para depuração de código Java (Java Accessible Debugger - JAD). Minha

participação envolve um minicurso de nivelamento, participar de um teste de usabilidade da

ferramenta proposta e de uma ferramenta utilizada amplamente no mercado (JGrasp).

A minha participação nesse estudo é voluntária e se você decidir não participar ou quiser desistir

de continuar em qualquer momento, tenho absoluta liberdade de fazê-lo. Na publicação dos

resultados desta pesquisa, minha identidade será mantida no mais rigoroso sigilo. Serão omitidas

todas as informações que permitam me identificar. Mesmo não tendo benefícios diretos em

participar, indiretamente estarei contribuindo para a compreensão do fenômeno estudado e para

a produção de conhecimento científico.

Consinto em participar deste estudo e declaro ter recebido uma cópia deste termo de consenti-

mento.

Atenciosamente,

Assinatura do Participante

Assinatura do Pesquisador

Local:

Data:

Documents

UNIVERSIDADE ESTADUAL DO CEARÁ PROGRAMA DE PÓS … · Java Acessible Debugger: Uma Abordagem de Interface Metafórica para Depuração de Código Java [recurso eletrônico] / Marcos