CARACTERÍSTICAS

usuário, seja via mouse, teclado ou comando de voz e atribuem as classes BrailleSpeechRecognitionEngine. A classe teria os artefatos sugeridos na Figura 20:

Figura 20 – Controle de classe.

4.8.4 FileSerializer

Realiza o encapsulamento dos diretórios nos Isolated Storages, responsável pela administração e integridade do Repositório de Arquivos do usuário do sistema. É permitido, salvar, excluir ou ler arquivos assincronamente utilizando esta entidade do sistema.

do projeto bem como uma pré-análise da agilidade na viabilização do trabalho e garantia da obtenção dos resultados desejados. O produto foi desenvolvido usando a linguagem proprietária C#.NET 4.0 da Microsoft, tendo como principais bibliotecas de uso a mscorlib e Microsoft.Speech.

Com o avanço das tecnologias de software, a inclusão de deficientes visuais vem ocorrendo, mas com sérios problemas relativos a acessibilidade a esses softwares. No que tange a palavra acessibilidade, refere-se a importância não apenas de permitir que pessoas com deficiências participem de atividades que incluem o uso de produtos, serviços, informação e tecnologias, mas a inclusão e extensão do uso destes por todas as parcelas presentes.

Grande parte dos softwares existentes hoje no mercado para auxílio ao deficiente utiliza sistemas de leitura de arquivos ou lente amplificadoras. Como citado nos capítulos anteriores, o Braille é fundamental na formação e captura de conhecimento do deficiente e não deve ser ignorado. Os softwares hoje implementam o acesso a informação quase que exclusivamente via áudio.

Por isso, o principal requisito funcional do software desenvolvido é garantir que o deficiente visual leia em Braille, através do envio de caracteres de texto ao hardware responsável pela sua tradução e impressão. Para facilitar o uso do software, diversos atalhos no teclado ativam suas funcionalidades, bem como a possibilidade de receber comandos de voz, fazer o reconhecimento do áudio e executar as ações. O uso do áudio é apenas um complemento para conseguir maior independência do cego ao usar o software e não a solução para o problema.

O software atenderá a Norma ISO/IEC 9126 na definição das seis características de qualidade de software, avaliadas em funcionalidade, usabilidade, confiabilidade, eficiência, manutenabilidade e portabilidade.

Como funcionalidade ou finalidade principal do produto, temos o envio de caracteres ao hardware anexo utilizando a porta serial. No que se trata a usabilidade ou esforço para utilizar e aprender o produto, o software faz uso de comandos de voz, atalhos via teclado,

documentação e confirmação audiovisual das operações, ainda utilizando geração dinâmica dos componentes gráficos a evitar navegação em várias janelas do sistema.

Nos requisitos funcionais que tangem os temas confiabilidade, recuperabilidade e frequência de falhas, o sistema, esporadicamente, apresenta alguns problemas no reconhecimento de voz de alguns comandos, através do uso da API Microsoft.Speech, distribuída com as versões Windows XP, Vista e Seven e gerenciados pelo Microsoft Speech Server. Estas API's são próprias para o reconhecimento e análise da língua inglesa, o que necessita a importação de um pacote de línguas para dar suporte ao português brasileiro, o qual necessita de alguns ajustes. É importante ressaltar que esta falha no reconhecimento do comando de voz é de pequena importância, visto que o usuário pode utilizar o sistema através dos atalhos ou repetindo o comando de voz.

No que se refere ao tratamento de exceções provindos da comunicação com o hardware, o driver acusa erro caso aja ausência do conector serial ou indisponibilidade do hardware em receber as informações. A respeito da eficiência e características relacionadas ao desempenho, o software utiliza o conceito de multi-thread e objetos Kernel, mais especificamente com o encapsulando de Mutex's, para sincronização dos comandos de voz e envio de dados a porta serial. No modo de leitura, o driver faz uso da criação de uma árvore de threads e envia um sinal, monitorado via pooling, quando o sistema terminou a bufferização dos dados. Isso garante que ao estabelecer um comando de leitura a um arquivo presente no repositório de arquivos, o mesmo será submetido a um processo específico e separado de leitura, deixando a interface gráfica livre de processamento sequencial.

Quando o processo de bufferização termina, o campo de texto criado pela thread pai é acessado e preenchido com o conteúdo do arquivo. É importante citar que o sistema operacional faz uso do cache ao acessar arquivos subsequentemente, o que garante que o usuário final pode trocar livremente o arquivo solicitado pelo modo de treinamento sem sofrer uma grande sobrecarga de leitura.

Para manter a eficiência e disponibilidade dos caracteres, o sistema faz uso de técnicas de paralelismo e afinidade de processamento, garantindo que o sistema tenha uma performance considerada, necessária para interoperar com o Microsoft Speech Server e contínua comunicação com porta serial e recursos gráficos GDI+ e DirectX gerenciado. Com

o uso do padrão Singleton, o software garante que os objetos de infraestrutura do sistema sejam instanciados e alocados na memória apenas uma vez, sendo assim, um “novo” objeto do sistema ocupa apenas 4 bytes, correspondente ao ponteiro de memória.

No requisito manutenabilidade, o software faz esforço necessário mínimo para modificação, visto que utiliza os conceitos de orientação a objetos e programação via interfaces, gerenciados pelo .NET Framework. O sistema também faz uso de um padrão de desenvolvimento conhecido como Injeção de Dependência, a qual garante o baixo nível de acoplamento entre os diferentes módulos de um sistema.

4.9.1 Acessibilidade e Integração com Sistemas Auxiliares

O sistema utiliza a tecnologia GDI+ (Graphic Design Interface), utilizada nas versões do Windows, junto com DirectX. Logo, são controles renderizados pelo sistema operacional, incluindo botões, caixas de textos, cursores e caixas de diálogo. Muitos leitores de tela e software de Tecnologia Assistiva, foram projetados para reconhecer estes componentes por padrão. Caso fossem criados componentes personalizados diferentes do padrão, um leitor de tela pode não ser capaz de tornar esse objeto no discurso, tornando esse elemento, e, possivelmente, toda a aplicação, inutilizável. A criação de uma interface de usuário flexível também é levada em conta, visto que oferece aos usuários a capacidade de personalizar a interface para atender suas necessidades, utilizando parâmetros do sistema operacional que interferem nas configurações que terão impacto de acessibilidade, como cor, contraste e configurações de tamanho de fonte; estilos de cursor e os sons do sistema.

O sistema, também deve permitir a navegação completa do sistema pelo teclado, permitindo o acesso a todas as características do programa através deste dispositivo. Porém, é mais vantajoso o uso do reconhecimento de voz perante teclado, pois permite que o usuário mantenha a mão em cima do hardware, concentrando-se na leitura do Braille. Caso esteja em um ambiente onde o recurso de voz não possa ser executado ou o usuário possua deficiência auditiva, o teclado pode ser utilizado. Por fim, verifica-se a necessidade de o sistema ser utilizado com o mouse, com regras de tabelamento, onde cada movimento nele, situa o cursor em algum elemento gráfico configurável.

4.9.2 Planejamento da Validação do Dispositivo

O processo de validação pretendeu identificar se o sistema atendeu os requisitos mínimos e as necessidades do usuário através de dois estudos de caso. Também foi realizada a validação do sistema na Fundação Catarinense de Educação Especial (FCEE). Acredita-se que com o uso do sistema com regularidade, o cego certamente atingirá maior grau de independência, podendo agir sem a ajuda de outra pessoa. O auxílio só se fará necessário para adicionar os arquivos no repositório, pois tal ação não pode ser efetuada pelo simples uso do atalho no teclado ou via comando de voz.

O primeiro passo consistiu em identificar o público alvo inicial, se os usuários são deficientes visuais parciais ou não, qual o nível de conhecimento prévio do Braille e o nível de acessibilidade e experiência que o mesmo tinha no uso de computadores. Tais informações poderiam, por exemplo, permitir a configuração do sistema com valores padrões. O Modo Treinamento, descrito anteriormente, é um bom modelo de análise de aprovação inicial, pois trás os resultados que o usuário já espera. No entanto, pretende-se verificar a necessidade da criação de novos comandos, como por exemplo, “repetir frase”, “repetir palavra”, “voltar frase”, “próxima linha” e, através de questionário, descobrir o nível de aprovação e a definição dos parâmetros padrões do sistema. Por fim, o seguinte questionário foi usado para avaliar estas propostas:

a) É necessário o feedback sonoro após envio dos caracteres?

b) Quais comandos você adicionaria para aprimorar a interação com o display Braille?

c) Qual a maior dificuldade constatada em utilizar o sistema?

d) Há necessidade de criação de novos módulos na interface do software? Que novos recursos seriam interessantes?

e) Quais as vantagens e desvantagens do sistema se comparados à leitura Braille tradicional?

Todo o processo de validação foi acompanhado e observado, registrando-se em forma de relatório eventuais anomalias do sistema e os benefícios detectados.