ANÁLISE E PROJETO

desenvolvimento do sistema. Por fim são apresentadas as limitações da ferramenta e as considerações acerca do capítulo.

4.7.1 Tecnologia

A solução proposta foi desenvolvida em C# 4.0, linguagem gerenciada pelo .NET Framework, caracterizada por compilador JustInTime, forte tipagem e orientação a objeto. A plataforma de desenvolvimento utilizada foi o Visual Studio 2010. Como forma de persistência, o projeto faz uso de um recurso conhecido como Isolated Storage. Isolated Storage é um mecanismo de persistência de arquivos padronizado. Entre as principais vantagens, temos o uso de uri's (Uniform Resource Identifier) gerenciadas e seguras através da criação implícita de diretórios e subdiretórios específicos do sistema. Isso garante que utilizando esta API do Windows, os arquivos serializados tornam-se protegidos a eventuais exclusões ou corrompimento de dados involuntários.

4.7.2 Arquitetura

Em termos arquiteturais foi proposta uma divisão das partes estruturais do sistema de acordo com o padrão de projeto Model-View-ViewModel (MVVM). Segundo (MICROSOFT CORPORATION, 2012), este padrão auxilia na separação limpa entre regra de negócio e lógica de apresentação. Isto garantirá que o sistema seja mais fácil de testar, manter e evoluir.

Também garante que os desenvolvedores percam menos tempo, fazendo vasto uso da reutilização de componentes.

A arquitetura foi baseada na criação de três classes, a View, que encapsula recursos gráficos e lógica de interface, a ViewModel, que encapsula a lógica de interação do objeto com a interface mantendo estados e a Model, que encapsula o acesso a informações serializadas e regras de negócio. As regra de encapsulamento das informações estão em uma dll anexa, criada para auxiliar o sistema na reprodução das regras de usabilidade. A Figura 16 simboliza esta arquitetura.

Figura 16 – Arquitetura MVVM

A arquitetura faz uso do padrão de projetos comportacional Command, capaz de encapsular uma solicitação através de um objeto que parametriza clientes com diferentes solicitações, fila ou pedidos de registro. A finalidade é separar a semântica do objeto que invoca o comando, da lógica de aplicação. Isto permite que múltiplos e diferentes recursos invoquem o mesmo comando, atribuindo a lógica a si próprio. No contexto do sistema, todas as ações de entrada de dados, como teclado, mouse ou recurso de voz, são encapsuladas no objeto Container e vinculadas a objetos responsáveis pelo tratamento do recurso. Sendo assim o Container atua como um proxy entre as camadas View e ViewModel, intermediando e atendendo requisições, repassando os dados do cliente à frente.

Para gerencias as instâncias de objetos pesados, como de reconhecimento de voz e serializador de arquivos, foi utilizado o padrão Singleton, garantindo uso de instância única do objeto no sistema. Acessos futuros apenas requisitam alocação de um ponteiro de memória, desalocado ao sair do escopo de sua criação.

4.7.3 View

A View representa o elemento visual, como um formulário ou uma web page. Ela faz uso de controles para definir o layout, utilizando qualquer tecnologia adjacente, como folhas de estilo, DirectX ou GDI+. Ela é responsável pela vinculação dos dados provindos da Model e por definir o comportamento visual dos elementos gráficos bem como a interação entre eles mediante ações do usuário. No caso deste sistema, optou-e por GDI+, por ser uma biblioteca mais interoperável com outras versões do Windows.

4.7.4 Model

A Model são classes não visuais que encapsulam as funções de serialização da informação, bem como a regra de negócio. A model é responsável pela validação final e regras adicionais, como log e cache. Esta por sua vez, não referencia a View nem a ViewModel e é totalmente independente em como é implementada. É comumente utilizada em conjunto com serviços ou classes auxiliares de acesso a informação. Neste trabalho, as Models estão encapsuladas em outra dll.

4.7.5 ViewModel

A ViewModel é um modelo não visual de classe que encapsula lógica de interação da inteface, o que garante que seu objeto mantenha estado, tornando-o idenpendente para uso de testes automatizados. Esta camada não faz referência direta a View, apenas implementa comandos aos quais disparam eventos e estes, por sua vez, inscrevem-se no objeto ViewModel para atualização de algum componente gráfico. É importante ressaltar que ela faz a interação entre os outros dois modelos, resolvendo problemas referentes a conversão e manipulação dos dados, isto é, a entidade trafegar da View para a Model com integridade. No contexto deste trabalho, as ViewModel não são puras como descritas acima. São misturadas com o padrão Proxy. Um proxy, em sua forma mais geral, é um funcionamento de classe como uma interface para outra coisa. O proxy pode servir como interface para qualquer coisa: uma conexão de rede, um grande objeto na memória, um arquivo, ou algum outro recurso que é caro ou impossível de duplicar. As classes AppContext, AppDomain, RecognitionSetup e BrailleSpeechTranslator, realizam este trabalho.

4.7.6 Acessibility API

Com a forte necessidade de seguir os padrões descritos nos capítulos anteriores, foi desenvolvido com esta base uma API isolada da camada de apresentação. Sua utilização é vinculada as boas práticas de recursos de acessibilidade, vinculadas ao I/O do display Braille com o sistema. É extensível no que se refere ao paradigma de programação, contendo uso de padrões de projeto como Singleton, Proxy, Command e Factory. A API foca seus esforços na utilização da composição sobre herança. As composições tem acoplamento forte, controlando

o ciclo de vida do objeto que a compõe. A herança apesar de bastante útil, provoca um engessamento por parte dos objetos filhos.

4.7.7 Diagrama de Classes

A figura 17, representa o diagrama de classes adotado pela API.

Figura 17 - Diagrama de classes I

Este diagrama representa a estrutura e relações das classes que servem de modelo para os objetos do sistema, sendo de utilidade direta para a visualização da sequência de eventos, estados e comunicação das entidades descritas na próxima sessão.

4.7.8 DictionaryWord

DictionaryWord permite que um aplicativo, em tempo de execução, especifique uma combinação específica de palavras ou até frases significativas. O objeto é construído usando o

padrão W3C Speech Recognition Grammar Specification (SRGS) e especificações da gramática livre de contexto (CFG).

As classes de Setup vistas a seguir, podem criar e carregar um ou mais objetos Dictionary Words, assim como habilitar ou desabilitar gramáticas particulares, e definir propriedades de gramática como prioridades. Dessa forma algumas palavras ou frases terão seu evento disparado com antecedência.

4.7.9 Braille Grammar Constructor

Define acesso a funcionalidade de síntese e reconhecimento de fala. A criação do objeto, implica em uma instância configurada com a fala padrão do sistema. O sistema por enquanto, fala e reconhece apenas o português, mas há suporte a outras línguas através da função SetLanguage, basta o computador do usuário ter os pacotes instalados, isso garante o aplicativo como proprietário de requisito básico de internacionalização. A função AppendDictionaryWords parametriza o objeto descrito acima, a qual dinamicamente vincula o vocabulário com a instância do motor de reconhecimento e/ou sintetizamento de voz. Esta classe implementa o padrão de projetos Proxy.

4.7.10 Braille Speech Recognition Engine

Define acesso a funcionalidade propriamente dita de reconhecimento de fala. Esta classe desempenha um papel parecido com a classe acima, porém aplica uma camada de filtragem de ruídos. É importante ressaltar que o processo compartilha um único reconhecedor de voz, ou seja, se outro aplicativo estiver em uso, em ambos, os comandos serão sintetizados.

O objeto faz uso da função InitializeInputToDefaultDevice para permitir que a escuta do motor de reconhecimento seja direcionada a entrada de áudio padrão. Esta classe se comunica diretamente com RecognitionSetup, a qual trata os eventos disparados, comparando o espectrograma interno com a instância de DictionaryWord. A função LoadBrailleSpeechGramar é invocada pelo objeto BrailleGrammarConstructor utilizando padrão proxy, como informado no objeto acima. Por fim, ChainRecognizeEvent disparada o evento principal da API de reconhecimento de voz, dentro dos padrões W3C Speech Recognition Grammar Specification (SRGS), a qual delega a classe chamadora o que fazer com a fala capturada.

4.7.11 BrailleSpeechGrammar

Tem a função de ordenar os eventos de síntese de fala, ativar, desativar e preencher o objeto DictionaryWord com as palavras e sentenças a serem faladas. Atua como Proxy para o objeto BrailleSpeechTranslator.

4.7.12 BrailleSpeechTranslator

Faz uso da voz padrão do sistema de comunicação com objetos de som. É configurado através dos pacotes de voz instalados (text-to-speech), podendo alterar o dialeto com a função SelectVoice (a função não foi mostrada no diagrama de classes por motivos de organização).

Essa classe também fornece controle sobre a configuração de saída de voz para o objeto SpeechSynthesizer da dll MicrosoftSpeech, utilizando as funções SetSoundToStreamOutput.

Esta função conversa diretamente com um objeto MemoryStream, que nada mais é do que um buffer criado em runtime a qual é passada ao objeto MediaPlayerInterop, descrito mais a frente. O objeto gera eventos quando encontra algumas características em prompts:

(BookmarkReached, PhonemeReached, VisemeReached, SpeakProgress). Ele também gera eventos que relatam sobre o início (SpeakStarted) e fim (SpeakCompleted) de operações e falam sobre a mudança de voz (VoiceChange), criada apenas para futuras necessidades da API, como por exemplo, internacionalização.

4.7.13 Speaker e MediaPlayerInterop

Classes responsáveis por carregar o objeto BrailleSpeechTranslator no buffer de voz e proteger as chamadas a ele. Devido ao uso de técnicas de composição sob o objeto BrailleSpeechTranslator e SpeechSynthetizer da Microsoft, seria simples o uso errôneo da classe de voz. Por isso a relação entre Speaker e BrailleSpeechTranslator. Ja MediaPlayerInterop é apenas um wrap a classe MediaPlayer, com fins de herança ao objeto System.ComponentModel.Component da Microsoft.

4.7.14 Classes de Interface

Esta seção pretende mostrar as classes utilizadas na lógica do aplicativo e sua ligação com a arquitetura apresentada anteriormente. A Figura 18 representa o diagrama de classes.

Figura 18 - Diagrama de classes II

Para melhor visualização das classes do sistema e suas ligações, foi desenvolvido um diagrama de classe apenas com as principais funções e atributos de cada objeto. Observa-se que todo o modelo gira em torno do objeto AppContext. Este é responsável pela delegação de funções da interface gráfica e sua comunicação via eventos com os objetos de modelo. Outro fator importante é o uso das classe FormFactory, responsável pela comunicação com a dll de usabilidade e FormMain responsável como classe base aos outros formulário do sistema.