Os resultados da última pergunta de pesquisa (subsecção 5.1.3), estão apresentados na Tabela5.3.
Tabela 5.3: Resultados da terceira questão
Bibliotecas Digitais Obtidos Seleccionados Descritos
ACM Digital Library 10 0 0
SpringerLink 110 1 1
IEEE Xplore 1 1 1
Science Direct 16 1 0
5. TRABALHOSRELACIONADOS 5.3. Resultados
Os escassos trabalhos encontrados nesta pesquisa apenas fazem referência a aborda- gens com recurso a UML (e.g., diagrama de classes, diagrama de estados, diagrama de sequências). Houve muitos resultados provenientes da biblioteca SpringerLink porque a pesquisa estava centrada na interacção pessoa-máquina, mas na prática só houve um resultado enquadrado na área de modelação de requisitos/UML. O artigo seleccionado na biblioteca Science Direct é o mesmo que vai ser descrito proveniente do IEEE Xplore.
Abordagem proveniente do IEEE Xplore e Science Direct
No IEEE Xplore foi obtido um trabalho muito semelhante à abordagem usada nesta dissertação. A proposta consistiu em desenvolver uma ferramenta chamada VoCoTo [LP03], implementando uma abordagem de reconhecimento de voz através de uma gra- mática para os seguintes diagramas UML: diagrama de classes, diagrama de estados, diagrama de sequências. A aplicação tem três interfaces disponíveis: teclado, rato e co- mandos via voz. A Graphical User Interface (GUI) da ferramenta foi concebida para ser o mais discreta possível, mas sempre visível, de modo a disponibilizar a informação im- portante para usar o mecanismo de voz de forma eficaz. A ferramenta usa a aplicação Microsoft SAPI como ferramenta de mecanismo de voz e as gramáticas em formato XML. Apesar de a ferramenta oferecer um mecanismo de acessibilidade para três diagramas UML, que podem ser usados numa fase de desenho no processo de Engenharia de Soft- ware, a fase inicial do processo de Engenharia de Requisitos continua esquecida no que diz respeito a aspectos de acessibilidade.
Abordagem proveniente da Springer Link
Outro artigo relevante encontrado, proveniente da Springer Link, é o Technical Diagram
Understanding for the Blind (TeDUB) [Kin+04]. Permite extrair o XMI (XML Metadata
Interchange) de um modelo e convertê-lo para uma representação que possibilite ao uti-
lizador com deficiências visuais a interpretação do diagrama. O projecto disponibiliza uma interface acessível com componentes de interface semelhantes a outras aplicações do Windows, permitindo aos utilizadores manipular a interface através de monitores de leitura, joystick ou teclado. A aplicação mostra o nome e nó actual oferecendo ao utiliza- dor a possibilidade de aceder aos outros nós que estão conectados ao nó actual através de um joystick. No entanto os criadores do TeDUB mencionam uma grande falha caso exis- tam vários nós conectados na mesma direcção no diagrama, pois é apresentado apenas o nó mais próximo. Para além desta limitação, o projecto apenas disponibiliza acessibi- lidade para os diagramas de casos de uso, classe, sequência e estados para a leitura de diagramas que já tenham sido previamente criados.
A aplicação TeDUB não usa mecanismos de reconhecimento de voz, apenas periféri- cos tais como monitores de leitura, joystick ou teclado. Os diagramas UML usados são o diagrama de classes e estados, sendo que não abordam modelos que se comportam como um grafo (e.g., modelo KAOS e features).
5. TRABALHOSRELACIONADOS 5.4. Análise comparativa
Abordagem proveniente de outras fontes
Por fim, foi encontrado o projecto D4ALL [Pan+12] com recurso a pesquisas no sis- tema Google. É um projecto que se centra em abordagens e técnicas alternativas para aceder e manipular diagramas por pessoas invisuais. Este trabalho recorre à mesma téc- nica para para capturar a informação do diagrama usado pelo TeDUB, ou seja, utiliza o padrão XMI para ter acesso aos conteúdos dos elementos do diagrama. A ferramenta tem duas interfaces: representação dos elementos UML numa tabela e representação do dia- grama de forma visual, mas com a possibilidade de percorrer todos os elementos através do teclado. Esta abordagem não oferece opções para que sejam criados modelos.
A forma de acessibilidade é apenas por teclado, para percorrer as tabelas ou os mo- delos, usando diagramas em UML. Não existe qualquer uso de mecanismos de reconhe- cimento de voz, nem da geração de modelos de análise de requisitos como o KAOS ou de features.
5.4
Análise comparativa
Após de ter sido feito uma descrição de cada abordagem que cada trabalho usa para melhorar a acessibilidade em ferramentas CASE, a Tabela5.4mostra que tipo de aborda- gens é que as aplicações usam, enquadradas da primeira e terceira questão de pesquisa.
Tabela 5.4: Tipo de abordagens usadas pelas aplicações.
Tipo JavaSpeak AudioGraf PLUMB Scribble Kevin VoCoTo TeDUB D4ALL
Reconheci- mento de voz ✗ ✗ ✗ ✗ ✗ ✓ ✗ ✗ Sintetização de voz ✓ ✓ ✓ ✗ ✓ ✓ ✓ ✓ Monitor táctil ✗ ✓ ✗ ✗ ✗ ✗ ✓ ✗ Caneta electró- nica ✗ ✓ ✓ ✗ ✗ ✗ ✗ ✗ Teclado ✓ ✗ ✓ ✓ ✗ ✗ ✓ ✗ Rato ✗ ✗ ✗ ✓ ✗ ✗ ✗ ✗ Dispositivo táctil ✗ ✗ ✗ ✗ ✓ ✗ ✗ ✗ Joystick ✗ ✗ ✗ ✗ ✗ ✗ ✓ ✗ Tabelas ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✓
As abordagens Reconhecimento de voz e Sintetização de voz são os mecanismos mais importantes no contexto da dissertação. No que diz respeito às aplicações que usam este tipo de abordagens, apenas o VoCoTo usa mecanismos de reconhecimento de voz e o Scribble é a única aplicação que não usa sintetização de voz para melhorar a acessibili- dade da ferramenta.
5. TRABALHOSRELACIONADOS 5.5. Sumário
Estas duas abordagens vão ser integradas na ferramenta da dissertação, para que seja possível gerar modelos de requisitos, nomeadamente modelos KAOS, conceptuais e de features. A Tabela5.5 mostra, com base nas aplicações que usam mecanismos de reco- nhecimento e sintetização de voz, especificadas na Tabela 5.4, se usam modelos KAOS, conceptual ou features nas suas ferramentas.
Tabela 5.5: Tipo de modelos usados pelas aplicações.
Tipo JavaSpeak AudioGraf PLUMB Scribble Kevin VoCoTo TeDUB D4ALL
Modelo KAOS ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ Modelo Concep- tual ✗ ✗ ✗ ✗ ✗ ✓ ✓ ✓ Modelo de Featu- res ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗
Nenhuma aplicação usa abordagens para derivar modelos KAOS e de features. Ape- nas as aplicações VocoTo, TeDUB e D4ALL usam os seus mecanismos para derivar dia- gramas de classes usando a linguagem de modelação UML. No entanto, as ferramentas TeDUB e D4ALL não usam mecanismos de reconhecimentos de voz para gerar os diagra- mas de classes, tal como foi apresentado na Tabela5.4.
Após a análise comparativa, através das Tabelas5.4e5.5, pode-se concluir que a apli- cação VoCoTo é a abordagem mais próxima do contexto da dissertação, visto que usa mecanismos de reconhecimento e sintetização de voz, embora não se foque em modelos de análise de requisitos.
5.5
Sumário
O estudo dos trabalhos relacionados permitiu analisar alguns trabalhos que oferece- rem acessibilidade em ferramentas CASE para utilizadores com deficiências. Os dispo- sitivos principais neste tipo de abordagens englobam leitores de monitor, dispositivos tácteis/braile e mecanismos de reconhecimento e sintetização de voz. Foram encontra- dos apenas trabalhos sobre acessibilidade para modelos UML. No próximo capítulo é descrita a abordagem VoiceToModel.
6
Abordagem VoiceToModel
6.1
Descrição
De forma a proceder à implementação da ferramenta, foram analisadas as técnicas e frameworks apresentadas nos capítulos2, 3e 4. A framework Eclipse, juntamente com os plugins EMF/GMF (subsecção 4.5.1 e 4.5.3), definem a sintaxe abstracta e concreta dos modelos de requisitos KAOS, modelos conceptuais e modelos de features, respecti- vamente apresentados nas subsecções2.3.1,2.3.2e2.3.3. A linguagem EVL especifica as restrições de cada modelo de requisitos (subsecção4.5.2). As ferramentas Sphinx-4 (sub- secção3.5.2) e Google Speech API (citado na secção3.5) interpretam comandos através da voz e, por fim, o FreeTTS (subsecção3.5.3) fornece feedback ao utilizador.
Nas próximas secções vão ser descritos todos os passos e decisões tecnológicas que foram tomadas durante todo o ciclo de implementação da ferramenta VoiceToModel.