MHNSS: Um Middleware para o Desenvolvimento de
Aplicac¸ ˜
oes M ´
oveis com Interac¸ ˜
oes Baseadas na Fala
Arikleyton de O. Ferreira
Universidade Federal do
Maranh˜ao (UFMA)
S˜ao Lu´ıs - Maranh˜ao
arikleyton@gmail.com
Ariel Soares Teles
Universidade Federal do
Maranh˜ao (UFMA)
S˜ao Lu´ıs - Maranh˜ao
ariel.teles@ifma.edu.br
Francisco Jos´e da S. e Silva
Universidade Federal do
Maranh˜ao (UFMA)
S˜ao Lu´ıs - Maranh˜ao
fssilva@deinf.ufma.br
RESUMO
Aplicac¸˜oes m´oveis apresentam diversas limitac¸˜oes de aces-sibilidade devido `a dependˆencia da interac¸˜ao com o usu´ario atrav´es da tela dos dispositivos, mas interfaces baseadas na fala podem super´a-las. Este artigo apresenta um middleware para o desenvolvimento de aplicac¸˜oes m´oveis com interac¸˜ao baseada na fala que foi desenvolvido utilizando requisitos da ´area da sa´ude. Uma aplicac¸˜ao dedicada aos cuidados da sa´ude foi usada como estudo de caso para avaliac¸˜ao com 10 sujei-tos, em que os resultados mostram um grande desempenho do middleware e uma facilidade de utilizac¸˜ao da aplicac¸˜ao por perfis de usu´arios diversificados.
Palavras-chave
Acessibilidade; Aplicac¸˜oes M´oveis; Interac¸˜oes Baseadas na Fala;
ABSTRACT
Mobile applications present several access limitations due to dependency on the interaction with the user through the devices display, but speech-based interfaces can overcome them. This paper presents a middleware for developing speech-based interaction mobile applications that was deve-loped using requirements of the healthcare field. A health-care application was used as case study for evaluation with 10 subjects, which results showed a great performance of the middleware and the application was easily used by a diversi-fied user profiles.
Author Keywords
Accessibility; Mobile Applications; Speech-Based Interaction;
ACM Classification Keywords
H.5.2. Information Interfaces and Presentation (e.g. HCI): User Interfaces
INTRODUC¸ ˜AO
Muitas tecnologias s˜ao destinadas a encurtar a distˆancia entre as pessoas, otimizar a realizac¸˜ao de tarefas ou at´e mesmo au-tomatizar processos repetitivos. Contudo, poucas s˜ao aquelas empenhadas em tornar as atividades mais acess´ıveis, conside-rando as diferentes necessidades e dificuldades dos usu´arios. Os dispositivos m´oveis s˜ao um exemplo de tecnologia popu-lar que, apesar das v´arias inovac¸˜oes do setor, ainda apresen-tam diversas limitac¸˜oes de acessibilidade. Por exemplo, como citado no relat´orio dos grandes desafios em IHC [4] “no caso dos dispositivos touchscreen, prevalece o enfoque visual das aplicac¸˜oes, o que torna a interac¸˜ao mais complexa por parte dos deficientes visuais”. Portanto, outras formas de interac¸˜ao com aplicac¸˜oes m´oveis s˜ao necess´arias.
Os assistentes pessoais virtuais para dispositivos m´oveis, como o Siri1da Apple e o Google Now2, surgiram como uma proposta das respectivas empresas para fornecer um certo n´ıvel de acessibilidade a seus usu´arios. Apesar de concor-rentes, esses assistentes s˜ao iguais no objetivo de auxiliar seus donos a efetuar atividades b´asicas atrav´es de comandos de voz, como redigir mensagens de texto, iniciar um aplica-tivo ou fazer buscas na Internet. Para fazer uma chamada te-lefˆonica, por exemplo, basta que o usu´ario inicie o assistente e fale o comando juntamente com o nome da pessoa que deseja ligar (por exemplo, “Ligar para Maria”), assim o assistente se encarregar´a de buscar o n´umero do telefone dessa pessoa na agenda e efetuar´a a chamada. Este foi um grande passo para a acessibilidade nos dispositivos m´oveis, pois permitiu a realizac¸˜ao de algumas tarefas de forma r´apida, al´em de via-bilizar o uso dos dispositivos m´oveis por pessoas com certos tipos de limitac¸˜oes f´ısicas. Entretanto, s˜ao poucas as ativida-des que os assistentes virtuais m´oveis conseguem realizar e, entre os mais populares, apenas o Google Now possui suporte ao idioma portuguˆes brasileiro.
As aplicac¸˜oes encontradas nos dispositivos m´oveis modernos, que atualmente s˜ao mais utilizadas que as func¸˜oes b´asicas de telefonia, quase nunca s˜ao beneficiadas pelos servic¸os dos assistentes pessoais virtuais. Isso ocorre devido os assisten-tes serem tratados como aplicac¸˜oes independenassisten-tes, n˜ao pos-suindo relac¸˜ao com as demais aplicac¸˜oes, portanto, n˜ao per-mitindo seu uso em paralelo com as aplicac¸˜oes. No sistema Android ´e poss´ıvel que o usu´ario ative servic¸os que o auxi-liam a ler e escrever textos atrav´es da fala, mas ´e uma opc¸˜ao
1
http://www.apple.com/ios/siri/
2http://www.google.com/landing/now/
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. IHC'14, Brazilian Symposium on Human Factors in Computing Systems. October 27-31, 2014, Foz do Iguaçu, PR, Brazil. Copyright 2014 SBC. ISSN 2316-5138 (pendrive). ISBN 978-85-7669-291-1 (online).
do usu´ario recorrer a esses servic¸os, pois as aplicac¸˜oes n˜ao s˜ao desenvolvidas considerando esse recurso ou qualquer ou-tro tipo de acessibilidade como requisito. Desta forma, as limitac¸˜oes de acessibilidade ainda est˜ao fortemente presentes nos dispositivos m´oveis, pois s˜ao poucas as aplicac¸˜oes que tentam amenizar esse problema.
Nesse contexto, em que aplicac¸˜oes m´oveis necessitam prover acessibilidade aos usu´arios, propomos o MHNSS (Mobile-HealthNet Speech Service), um middleware que fornece su-porte ao desenvolvimento de aplicac¸˜oes m´oveis com recursos de acessibilidade atrav´es da fala. Este middleware conta com um sistema de di´alogo falado que proporciona `as aplicac¸˜oes interagirem com o usu´ario utilizando a fala em diversas situac¸˜oes, como para coletar informac¸˜oes atrav´es de pergun-tas, ler textos ou receber comandos para executar atividades espec´ıficas. Diferente dos assistentes virtuais, o sistema de di´alogo falado executa em segundo plano como um servic¸o, permitindo o seu uso em conjunto com as aplicac¸˜oes. O MHNSS est´a inserido no contexto do projeto Mobile-HealthNet, o qual viabiliza a criac¸˜ao de aplicac¸˜oes sociais m´oveis colaborativas dedicadas `a atenc¸˜ao a sa´ude. Este ´e um projeto destinado a rede p´ublica de sa´ude e, por isso, neces-sita que suas aplicac¸˜oes levem em considerac¸˜ao restric¸˜oes de acessibilidade. Assim, o MHNSS ´e fundamental para garantir a usabilidade de diversos recursos das aplicac¸˜oes do projeto. Para tal, o sistema de di´alogo proposto possui caracter´ısticas que visam superar limitac¸˜oes computacionais e de conectivi-dade do ambiente m´ovel, permitindo que seja executado em dispositivos considerados de baixo custo. Al´em disso, a lin-guagem de comunicac¸˜ao adotada ´e o portuguˆes brasileiro. O artigo est´a organizado como segue. Na primeira sec¸˜ao fa-zemos uma fundamentac¸˜ao sobre sistemas de di´alogo falado e sua aplicac¸˜ao na ´area da sa´ude. Em seguida descrevemos o projeto MobileHealthNet e como suas aplicac¸˜oes se benefi-ciam com o sistema de di´alogo, juntamente com os desafios enfrentados no uso do mesmo. Na terceira sec¸˜ao apresenta-mos o MHNSS. Posteriormente na quarta sec¸˜ao descreveapresenta-mos o estudo de caso e a metodologia utilizados para avaliar a proposta. Na sec¸˜ao seguinte mostramos os resultados e dis-cuss˜oes da avaliac¸˜ao, seguida pela sec¸˜ao de trabalhos relaci-onados. Por fim, as conclus˜oes do artigo s˜ao apresentadas. SISTEMAS DE DI ´ALOGO FALADO
Os Sistemas de Di´alogo Falado (em inglˆes, Spoken Dialogue System- SDS) aceitam linguagem natural como entrada, ge-ram linguagem natural na sa´ıda e, como o pr´oprio nome su-gere, mant´em uma conversa com o usu´ario [7]. Esse tipo de sistema proporciona um alto n´ıvel de acessibilidade, pois as pessoas podem utilizar algo que elas tˆem usado a vida toda - a habilidade de falar e entender conversas. Para tal, um SDS pode guiar, perguntar, responder, ler e escrever para o usu´ario, proporcionando uma interface que n˜ao requer pr´evio aprendizado e permitindo sua utilizac¸˜ao por uma variedade de p´ublico, desde que a linguagem de comunicac¸˜ao seja a mesma.
De modo geral, um componente captura o sinal ac´ustico da fala do usu´ario e o converte em um comando ou sinal
eletrˆonico para executar func¸˜oes espec´ıficas ou executar ta-refas. Sua aplicac¸˜ao costuma estar relacionada a atividades que exijam um alto n´umero de interac¸˜oes entre usu´ario e sis-tema, como os sistemas coletores de informac¸˜oes (por exem-plo, obtenc¸˜ao de dados de vˆoo em sistemas de viagem), con-troladores de dispositivos (por exemplo, ajuste de uma cama em um hospital, mesmo que o paciente esteja impossibili-tado fisicamente) e assistentes virtuais pessoais (por exemplo, marcar uma reuni˜ao na agenda eletrˆonica).
V´arios componentes precisam trabalhar em conjunto para que o SDS funcione corretamente, o que normalmente in-clui: (i) Reconhecimento de Voz - reconhece as palavras que o usu´ario falou; (ii) Compreens˜ao da Linguagem - atribuir um significado `as palavras reconhecidas; (iii) Gerenciador do Di´alogo - processa o di´alogo e decide o que fazer a seguir; (iv) Fontes Externas - fornece dados para auxiliar no proces-samento do di´alogo; (v) Gerador de Linguagem - transforma a instruc¸˜ao do gerenciador em uma frase estruturada; e (vi) S´ıntese Texto-para-Fala - reproduz a frase para o usu´ario. Por ser um fluxo normalmente sequencial, como ilustrado na Figura 1 baseada em [7], a performance de cada compo-nente ´e dependente dos antecessores. Por exemplo, caso o Reconhecimento de Voz falhe, o Gerenciar do Di´alogo pode trabalhar com informac¸˜oes erradas e comprometer todo o di´alogo. Ressalta-se que nem todos os sistemas de di´alogo seguem essa arquitetura completamente. As aplicac¸˜oes de-senvolvidas comercialmente, por exemplo, buscam simplifi-car cada componente da arquitetura pra reduzir custos e fa-cilitar a produc¸˜ao. Alguns m´odulos podem ainda ser mes-clados ou desconsiderados, dependendo do desenvolvedor e da finalidade da aplicac¸˜ao. Por outro lado, sistemas mais avanc¸ados podem envolver uma arquitetura mais elaborada, com interac¸˜oes direta de componente a componente, com a adic¸˜ao de novos componentes e sem necessariamente seguir um fluxo sequencial [14]. Normalmente SDSs exigem recur-sos computacionais elevados para que o di´alogo parec¸a natu-ral, completo e sem atrasos. Por isso, s˜ao comumente desen-volvidos para estac¸˜oes de trabalho fixas (n˜ao-m´ovel).
Figura 1. Arquitetura b´asica de um sistema de di´alogo
O Health Dialog System ´e um termo utilizado para caracte-rizar sistemas de di´alogo que estabelecem uma comunicac¸˜ao com pacientes sobre assuntos relacionados a sa´ude [1]. Sua aplicac¸˜ao pode ser destinada ao auxilio de auto-medic¸˜ao, acompanhamento remoto e prevenc¸˜ao de doenc¸as, educac¸˜ao
de pacientes, entre outras finalidades. Mesmo que n˜ao se-jam t˜ao eficientes quanto os encontros com os profissionais da sa´ude, os Health Dialog Systems podem atender as ne-cessidades do paciente em diferentes formas. Umas dessas formas ´e o fator tempo, pois muitos dos encontros com os m´edicos e especialistas s˜ao em curto tempo para que possam atender o maior n´umero de pessoas, o que pode intimidar o paciente a fazer perguntas ou pedir para que uma informac¸˜ao seja repetida [3]. Neste caso, um sistema de di´alogo pode-ria tirar d´uvidas e fornecer informac¸˜oes para o usu´ario sem-pre que necess´ario, sem que haja a necessidade de um pro-fissional durante esse processo. Outro ponto favor´avel des-ses sistemas ´e o alcance, pois grande parte dos pacientes n˜ao possuem acesso a todos os profissionais que eles precisam, seja por quest˜oes financeiras ou pela demora em conseguir marcar uma consulta. Assim, os sistemas de di´alogo podem fornecer atendimento especializado a um maior n´umero de pessoas [18]. Al´em disso, sistemas de di´alogo podem for-necer assistˆencia a pacientes em idiomas diferentes, aumen-tando ainda mais o alcance dos atendimentos.
O PROJETO MOBILEHEALTHNET
O projeto MobileHealthNet [16] tem por objetivo desenvol-ver um middleware que permita a construc¸˜ao de aplicac¸˜oes sociais m´oveis e facilite o desenvolvimento de servic¸os cola-borativos para o setor da sa´ude, a troca de experiˆencias e a comunicac¸˜ao entre pacientes e profissionais da sa´ude, al´em de uma melhor gest˜ao dos recursos da sa´ude por ´org˜aos go-vernamentais.
Este projeto foi concebido para ser aplicado em especial a comunidades carentes e distantes, em que o custo do deslo-camento de pacientes para os postos de atendimento ´e alto devido as suas condic¸˜oes de acesso. Dessa forma, pode-se explorar o uso de redes sociais m´oveis para prover o in-tercˆambio de informac¸˜oes, colaborac¸˜ao e integrac¸˜ao social para ac¸˜oes dedicadas a sa´ude [15]. Entre essas ac¸˜oes inclui-se o pr´oprio provimento de inclui-servic¸os de sa´ude, a educac¸˜ao em sa´ude envolvendo profissionais e pacientes, uma plataforma para o suporte e discuss˜ao sobre quest˜oes e problemas rela-cionadas a tratamentos, compartilhamento de documentos e consultorias com especialistas. Al´em disso, a manutenc¸˜ao do contato e relacionamento entre as pessoas envolvidas no processo de atendimento `a sa´ude pode se prolongar al´em dos encontros presenciais. Entre os agentes que possam estar en-volvidos nesse processo cita-se os profissionais da sa´ude (por exemplo, m´edicos, enfermeiros, fisioterapeutas e terapeutas ocupacionais), pesquisadores da sa´ude (professores e alunos de graduac¸˜ao e p´os-graduac¸˜ao), pacientes e seus familiares, bem como membros da comunidade em geral.
Por ser destinado a rede p´ublica de sa´ude, uma das preocupac¸˜oes do projeto para que seus objetivos sejam atin-gidos ´e garantir a utilizac¸˜ao dos servic¸os oferecidos por perfis diversificados de usu´arios, de forma apropriada e sem grandes dificuldades. Entre esses usu´arios, atenta-se aos que possuem baixa escolaridade e pouco conhecimento tecnol´ogico, al´em dos que utilizam dispositivos m´oveis de baixo custo devido a sua condic¸˜ao financeira limitada. Por isso, algumas premis-sas foram estabelecidas para que as aplicac¸˜oes desenvolvidas
levem em considerac¸˜ao restric¸˜oes de uso, das quais pode-se citar:
• Componentes de software para dispositivos m´oveis devem apresentar baixo consumo de recursos, de maneira que pos-sam ser executados em uma grande variedade de equipa-mentos, incluindo aqueles considerados de baixo custo, j´a que os resultados do projeto devem ser aplic´aveis a comu-nidades carentes;
• Deve-se prover suporte a diversos tipos de comunicac¸˜ao sem fio (em especial sistemas celulares e redes locais sem fio), de forma a se atingir uma ampla ´area de cober-tura, minimizando-se custos de comunicac¸˜ao sempre que poss´ıvel para n˜ao gerar gastos ao usu´ario;
• A plataforma m´ovel visada ´e o Android, pois est´a presente em maior quantidade nos dispositivos m´oveis populares atuais, tornando os servic¸os acess´ıveis ao maior n´umero de pessoas;
• As aplicac¸˜oes devem respeitar crit´erios de privacidade e seguranc¸a, para n˜ao expor informac¸˜oes dos pacientes e de seus tratamentos;
• Fornecer opc¸˜oes de acessibilidade que permitam ao usu´ario utilizar os servic¸os oferecidos sem dificuldades.
Esta ´ultima ´e a principal premissa que atacaremos no decorrer deste artigo, mas sem ignorar as demais citadas. Para isso, o sistema de di´alogo encontrado no middleware proposto aten-der´a a interac¸˜oes baseadas na fala para proporcionar acessibi-lidade aos usu´arios. Contudo, h´a desafios para o uso de sis-temas de di´alogo no ambiente do projeto MobileHealthNet, conforme detalhado a seguir.
Desafios para o uso de um SDS no MobileHealthNet Apesar de bastante favor´avel para suprir as necessidade de acessibilidade do projeto MobileHealthNet, o uso de SDSs no ambiente do projeto ´e bastante desafiador. No ambi-ente m´ovel, ainda que os dispositivos tenham evolu´ıdo em hardware e software nos ´ultimos anos, as interfaces basea-das em voz ainda enfrentam problemas com limitac¸˜oes de recursos. Func¸˜oes como reconhecimento de voz e compre-ens˜ao da linguagem, por exemplo, demandam muito proces-samento e s˜ao sens´ıveis a diversos fatores que podem com-prometer seu bom funcionamento. Devido a sua capacidade de utilizac¸˜ao em qualquer lugar, os dispositivos m´oveis est˜ao naturalmente mais expostos a interferˆencias e ru´ıdos externos (por exemplo, barulho no ambiente e pessoas conversando ao redor) e em consequˆencia disso, os componentes do sistema de di´alogo empenhariam esforc¸os maiores para tentar solu-cionar erros de reconhecimento e compreens˜ao. Assim, o uso do sistema de di´alogo no ambiente m´ovel n˜ao ´e trivial, pois esses esforc¸os extras e a demanda por poder de proces-samento s˜ao ainda mais custosos devido aos recursos compu-tacionais e de energia limitados.
A maioria das interfaces de voz atuais utiliza servidores ro-bustos que s˜ao consultados atrav´es da Internet para processar a maior parte do di´alogo, superando assim o fraco poder de
processamento dos dispositivos m´oveis [8]. Contudo, a co-nex˜ao de Internet m´ovel no Brasil ´e inst´avel e de baixa velo-cidade, e o uso desmedido de servic¸os remotos poderia deixar o SDS sujeito a atrasos, devido ao atraso da rede, e trazer pro-blemas no di´alogo ocasionados por perdas de conex˜ao, o que reduziria a aceitac¸˜ao do usu´ario pelo uso do sistema. Por isso, o uso moderado da comunicac¸˜ao foi outro fator considerado no desenvolver da proposta.
O perfil dos usu´arios do MobileHealthNet ´e bastante diver-sificado e, por isso, foi outra caracter´ıstica trabalhada no MHNSS. O sistema de di´alogo precisa utilizar uma lingua-gem de f´acil compreens˜ao e ser capaz de atender usu´arios de diferentes sexos, idades e n´ıveis de escolaridade. Al´em disso, deve compreender ao idioma portuguˆes brasileiro, o que j´a ´e um grande desafio, pois a maior parte das ferramentas de desenvolvimento e das t´ecnicas de processamento para esses sistemas s˜ao destinadas ao inglˆes.
Aplicac¸ ˜oes do Sistema de Di ´alogo no MobileHealthNet Considerando que parte dos usu´arios do MobileHealthNet possuem dificuldades para ler, escrever (digitar) e utilizar as aplicac¸˜oes de forma geral, o uso de SDSs pelas aplicac¸˜oes do MobileHealthNet possibilita uma quebra de limitac¸˜oes de acessibilidade, tornando facilitada suas experiˆencias com os servic¸os.
Atualmente, trˆes aplicac¸˜oes est˜ao em desenvolvimento para o projeto MobileHealthNet. Para cada aplicac¸˜ao, o Sistema de Di´alogo proposto deve fornecer um tipo de suporte espec´ıfico, baseado nas necessidades de cada uma delas, que s˜ao: • Health Education - possui ferramentas para o
compartilha-mento de arquivos multim´ıdia e seu objetivo ´e aprimorar a educac¸˜ao de pacientes e profissionais da sa´ude atrav´es de m´ıdias com conte´udo educacional. Para esta aplicac¸˜ao o SDS auxiliar´a na busca por arquivos, leitura de documen-tos e na orientac¸˜ao ao usu´ario para utilizar algum medica-mento, equipamento m´edico ou como atuar em determina-das situac¸˜oes, de forma educativa e dinˆamica;
• Professional Collaboration - visa diminuir a distˆancia en-tre os profissionais da sa´ude, atrav´es de recursos como chat multiusu´ario, f´orum de discuss˜ao e servic¸o de notificac¸˜ao que permita informar sobre a urgˆencia de se obter o re-sultado de um exame, discutir a respeito do tratamento e acompanhamento de um determinado paciente. Neste caso, o SDS ser´a aplicado para ler e escrever mensagens no bate-papo e f´orum, possibilitando que o profissional da sa´ude utilize a aplicac¸˜ao mesmo que esteja com as m˜aos ocupadas;
• HUPD Care - tem por objetivo explorar os conceitos das redes sociais m´oveis para promover a assistˆencia remota de especialistas respons´aveis pelo atendimento de alta com-plexidade a profissionais da atenc¸˜ao b´asica a sa´ude no atendimento a casos espec´ıficos. Para tanto, o sistema de di´alogo poder´a auxiliar esses profissionais no uso da rede social em geral.
Uma quarta aplicac¸˜ao j´a foi finalizada, a PBB (Patient-Buddy-Build) [9], que possibilita o acompanhamento remoto
de pacientes com doenc¸as crˆonicas, alertando a m´edicos e familiares sobre mudanc¸as no seu estado de sa´ude. Para tal, a aplicac¸˜ao utiliza dados de sensores, hist´orico do pa-ciente e um question´ario customizado para identificar essas mudanc¸as. O question´ario ´e parte fundamental no processo de acompanhamento remoto dos pacientes e, por isso, o SDS os auxiliar´a no preenchimento correto atrav´es do di´alogo, co-letando todas as informac¸˜oes necess´arias para o acompanha-mento remoto. O uso do sistema de di´alogo pela PBB ´e o nosso estudo de caso e ser´a apresentado na sec¸˜ao de avaliac¸˜ao desse artigo.
MHNSS
Como forma de superar as limitac¸˜oes de hardware e mini-mizar o consumo de recursos do dispositivo m´ovel, a ar-quitetura do MHNSS adota uma abordagem descentralizada para executar o m´ınimo poss´ıvel de processamento no cli-ente, deixando as atividades computacionais mais intensas para o servidor. Nessa abordagem, conforme ilustrado na Figura 2, a aplicac¸˜ao cliente (MHNSS-Mobile) ´e um servic¸o Android instalado no dispositivo m´ovel do usu´ario e ´e res-pons´avel por processar o di´alogo localmente. O processa-mento local ´e capaz de atender a atividades simples, como fazer uma pergunta ao usu´ario, ler um texto para ele, cap-turar sua voz para inserir como texto em um chat, entre outras. Para tal, o MHNSS-Mobile possui trˆes componen-tes b´asicos: o (i) Reconhecimento da Voz que ´e res-pons´avel por capturar o ´audio de entrada atrav´es do micro-fone do dispositivo m´ovel e convertˆe-lo em texto para ser processado pelo gerenciador de di´alogo; o (ii) S´ıntese Texto-para-Falaque faz o processo inverso, recebendo um texto do gerenciador, transformando-o em sinal de ´audio e reproduzindo-o pelos auto-falantes do dispositivo m´ovel; e (iii) o Gerenciador de Di´alogo-Mobileque faz o processamento do di´alogo no dispositivo m´ovel, define qual a pr´oxima ac¸˜ao a ser tomada pelo sistema e, caso precise, comunica-se com o servidor e servic¸os de terceiros que auxi-liam no di´alogo.
Figura 2. Arquitetura do MHNSS-Mobile
Quando necess´ario, a aplicac¸˜ao que deseja utilizar os recursos de di´alogo se comunica com o MHNSS-Mobile e solicita uma determinada atividade. Por exemplo, caso ela queira ajuda para que o usu´ario insira uma mensagem em um chat, ela solicita a captura da fala do usu´ario. Ent˜ao, com o auxilio do componente Reconhecimento da Voz, o MHNSS-Mobile captura o ´audio da mensagem do usu´ario, converte
em formato de texto e envia como resposta para a aplicac¸˜ao. Em posse do texto, a aplicac¸˜ao complementa o chat com a mensagem do usu´ario e continua suas atividades, assim como seria caso o usu´ario estivesse digitado sua pr´opria resposta. Para transformar o texto em ´audio e o ´audio em texto, os componentes Reconhecimento da Voz e S´ıntese Texto-para-Falautilizam o Servic¸o de Convers˜ao de ´Audio oriundo, na vers˜ao atual do middleware, do Dragon Mobile SDK3, uma ferramenta de servic¸os de voz para aplicac¸˜oes m´oveis atrav´es da Internet, a qual ´e propriet´aria. Por´em, o Servic¸o de Convers˜ao de ´Audio´e fracamente acoplado ao middleware, podendo assim ser substitu´ıdo por qualquer outro servic¸o de con-vers˜ao a desejo do desenvolvedor. O Dragon Mobile SDK diferencia-se por ser espec´ıfico para o ambiente m´ovel, ofe-recendo suporte a maioria das plataformas m´oveis e a diver-sos idiomas. Para reduzir o tr´afego de dados na rede m´ovel em uma convers˜ao de um ´audio, a ferramenta possui meca-nismos de compress˜ao de dados, possibilitando que o servic¸o seja utilizado tamb´em em redes de baixa velocidade como a 3G. A escolha desta ferramenta como servic¸o de convers˜ao deu-se pelo fato de requerer vers˜ao do Android 2.3 ou supe-rior, sendo assim compat´ıvel com os requisitos m´ınimos das aplicac¸˜oes do MobileHealthNet e n˜ao limitando o servic¸o `as vers˜oes do Android encontradas apenas nos dispositivos de alto custo. Al´em disso, os dados trafegados s˜ao criptogra-fados, o ´audio gerado ´e de f´acil compreens˜ao e a precis˜ao de reconhecimento ´e satisfat´oria, atendendo aos requisitos do projeto.
Uma vez que determinado ´audio de entrada ´e convertido em texto pelo componente Reconhecimento da Voz, o gerenciador de di´alogo receber´a esse texto e tentar´a pro-cess´a-lo. Esse processamento pode ser realizado tanto no dispositivo m´ovel, quanto no servidor. Por exemplo, caso a aplicac¸˜ao queira questionar o usu´ario sobre “Vocˆe est´a com febre?” e ele responda “Sim”, o Gerenciador de Di´alogo-Mobileser´a capaz de identificar essa resposta como satisfat´oria por ela ser direta. Mas se a resposta for mais estruturada, como “Tive febre ontem a noite”, uma co-nex˜ao com o servidor ser´a necess´aria para obter uma melhor compreens˜ao da resposta. Esta conex˜ao com o servidor ser´a evitada sempre que poss´ıvel pelo MHNSS-Mobile, a fim de n˜ao gerar gastos com tr´afego de dados na comunicac¸˜ao en-tre dispositivo m´ovel e servidor, caso o Gerenciador de Di´alogo-Mobileseja capaz de lidar com a atividade. O servidor de di´alogo (MHNSS-Server) ´e respons´avel por fazer o processamento das etapas do di´alogo que deman-dam maior poder computacional. Conforme ilustrado na Figura 3, ele ´e composto por um gerenciador de di´alogo mais robusto e um m´odulo de compreens˜ao da lingua-gem. O Gerenciador de Di´alogo-Serverauxilia o Gerenciador de Di´alogo-Mobilena tomada de de-cis˜oes, no tratamento de erros, no processamento de textos e na consulta a fontes de informac¸˜oes externas. Para tanto, ele utiliza o componente Compreens˜ao da Linguagem para analisar um texto, seja uma resposta do usu´ario ou
3http://www.nuance.com/for-developers/dragon-mobile-sdk/
uma mensagem de erro, e decide a pr´oxima ac¸˜ao a ser to-mada pelo sistema. A compreens˜ao de determinado texto ´e feita atrav´es de t´ecnicas de Processamento de Lingua-gem Natural (PLN) e do uso do componente Fontes de Informac¸˜oes Externas. Este ´ultimo representa toda informac¸˜ao externa ao servic¸o que pode auxiliar no proces-samento do di´alogo, como por exemplo, bancos de dados, di-cion´arios e servic¸os de terceiros. Na vers˜ao atual do MHNSS um dicion´ario de sinˆonimos ´e utilizado para ajudar no PLN, o qual ´e descrito a seguir.
Figura 3. Arquitetura do MHNSS-Servidor
Processamento de Linguagem Natural no MHNSS Processamento de Linguagem Natural ´e um conjunto de t´ecnicas computacionais para analisar e representar textos, em um ou mais n´ıveis de an´alise lingu´ıstica, com o objetivo de atingir a maneira humana de processar a linguagem para uso em diversas tarefas ou aplicac¸˜oes [2]. Existem v´arios objetivos pr´aticos para o uso do PLN, principalmente em aplicac¸˜oes que dependem de informac¸˜oes expressas em lin-guagem natural. Os SDSs s˜ao umas desses aplicac¸˜oes, pois utilizam an´alises lingu´ısticas no processamento do di´alogo como forma de aumentar a precis˜ao da compreens˜ao da lin-guagem.
Atualmente quatro t´ecnicas de PLN s˜ao utilizadas no middle-ware proposto. A End of Sentence Detection ´e utilizada para identificar se o texto analisado ´e uma sentenc¸a com-posta, ou seja, se ´e formado por mais de uma frase. A separac¸˜ao das sentenc¸as ´e necess´aria por que o Tokenization (pr´oxima t´ecnica) geralmente opera em sentenc¸as individu-ais. A t´ecnica Tokenization ´e utilizada para dividir o texto em tokens(unidades mais simples) como n´umeros, pontuac¸˜oes e palavras. Na maioria dos casos os espac¸os em branco e sinais de pontuac¸˜ao s˜ao usados como delimitadores na di-vis˜ao dos tokens. A partir dos tokens ´e poss´ıvel fazer uma an´alise individual em cada palavra e conseguir uma melhor compreens˜ao do texto. A t´ecnica Stemming consiste em re-duzir uma palavra (token) a seu radical, ou seja, s˜ao retira-dos seus afixos (prefixos e sufixos). A partir dessa t´ecnica ´e poss´ıvel identificar variac¸˜oes lingu´ısticas da mesma palavra (por exemplo, muit-o, muit-a, muit-´ıssimo) e, assim, trat´a-las como um ´unico termo em vez de termos diferentes. A Stem-mingauxilia ainda a identificar palavras sinˆonimas mais facil-mente, uma vez que os dicion´arios geralmente n˜ao possuem variac¸˜oes lingu´ısticas. Por fim, a Part-of-Speech Tagging ´e respons´avel por fixar em cada token uma marcac¸˜ao (tag) de
sua respectiva categoria gramatical como substantivo, adje-tivo ou verbo. A partir dessas tags ´e poss´ıvel diferenciar pa-lavras amb´ıguas, ou seja, que possuem diversos sentidos ou m´ultiplos significados. Por exemplo, “paciente” pode ser um substantivo, e significar uma pessoa que esta doente, ou um adjetivo, e significar uma pessoa que tem paciˆencia.
Para processar determinado texto, nem sempre o MHNSS utiliza todas essas t´ecnicas de PLN. Na maioria dos casos ´e poss´ıvel compreender o texto com apenas algumas delas. Como exemplo, a Figura 4 ilustra uma sequˆencia comum para processamento de um texto no MHNSS. Neste caso, o usu´ario foi questionado sobre “Vocˆe vomitou hoje?”. Como resposta, o usu´ario disse “Nenhuma vez hoje” e esse texto foi proces-sado usando as t´ecnicas de PLN.
Figura 4. Processamento de linguagem natural no MHNSS
A princ´ıpio, o texto de entrada passa por trˆes t´ecnicas de processamento de linguagem natural: End of Sentence De-tection, Tokenization e Stemming. Em vermelho, o exemplo mostra como fica o texto ap´os a aplicac¸˜ao de cada t´ecnica. Ap´os a Stemming, o sistema faz uma verificac¸˜ao se alguma das palavras representa uma resposta satisfat´oria para a per-gunta. Neste caso, o sistema busca por palavras afirmativas ou negativas. Caso essa verificac¸˜ao seja satisfeita, a resposta ´e dada como v´alida. Caso contr´ario, o processamento do texto continua atrav´es do uso da Part-of-Speech Tagging e da busca por palavras sinˆonimas em um dicion´ario. A Part-of-Speech Tagging auxilia a identificar sinˆonimos das pala-vras de acordo com a classificac¸˜ao gramatical delas naquela sentenc¸a. Atrav´es das palavras sinˆonimas, o sistema tenta identificar novamente palavras afirmativas ou negativas na resposta do usu´ario. Contudo, caso encontre, a resposta n˜ao ´e dada como totalmente v´alida e, por isso, ´e necess´ario con-firmar se o usu´ario realmente quis dizer aquilo. Esta ´e uma forma do MHNSS prevenir-se de tomar conclus˜oes precipita-das, pois nem sempre a an´alise individual das palavras repre-senta o sentido da frase. Por exemplo, as palavras da sentenc¸a “muito pouco” (uma poss´ıvel resposta dada pelo usu´ario) se analisadas individualmente possuem sentidos opostos, o que pode confundir o sistema de di´alogo e, por isso, ´e necess´ario confirmar com o usu´ario a sua real resposta. Por fim, caso ne-nhuma das t´ecnicas tenha ajudado a compreender a resposta do usu´ario, a pergunta ´e refeita para coletar uma nova res-posta.
Para o uso dessas t´ecnicas, utilizamos a ferramenta Natural Language Toolkit(NLTK)4que ´e uma biblioteca Python open sourcepara processamento de linguagem natural. Esta ferra-menta fornece suporte a PLN em v´arios idiomas, incluindo o portuguˆes brasileiro. Contudo, para o uso adequado do POS Taggingem portuguˆes, foi necess´ario treinar um corpus com textos analisados morfo-sintaticamente. Para tal, utilizamos um acervo disponibilizado pelo Projeto Floresta5, que pos-sui mais de nove mil sentenc¸as classificadas e revisadas por linguistas a partir de textos extra´ıdos do jornal Folha de S˜ao Paulo. Com isso, foi poss´ıvel treinar o corpus para fazer a classificac¸˜ao gramatical de diversas palavras e, assim, tornar o NLTK ideal para os prop´ositos do MHNSS.
AVALIAC¸ ˜AO DO MHNSS
Para avaliarmos o MHNSS, conduzimos um estudo de caso que demostra a utilizac¸˜ao dos recursos do middleware pela aplicac¸˜ao PBB. Atrav´es desse estudo ´e poss´ıvel perceber como uma aplicac¸˜ao m´ovel dentro do dom´ınio da sa´ude pode usufruir do sistema de di´alogo proposto de forma a proporci-onar uma maior acessibilidade a seus usu´arios.
Estudo de Caso
Como citado anteriormente, a PBB utiliza dados coletados de sensores, o hist´orico do paciente e a situac¸˜ao atual dele (ob-tida atrav´es de um question´ario) para identificar mudanc¸as no seu estado de sa´ude. Este question´ario ´e composto de nove perguntas do tipo “Est´a com falta de ar?” ou “Sentiu palpitac¸˜ao na regi˜ao do corac¸˜ao?”, sendo que as perguntas s˜ao selecionadas de acordo com a doenc¸a e a situac¸˜ao do pa-ciente, ou seja, o question´ario ´e personalizado. Para maioria dessas perguntas, espera-se respostas simples como “Sim” ou “N˜ao”, mas para algumas outras ´e necess´ario informar a in-tensidade das dores como, por exemplo, “Muito intenso” ou “Mediano” para a pergunta sobre palpitac¸˜ao no corac¸˜ao. Por ser destinado ao acompanhamento de portadores de doenc¸as crˆonicas, a intensidade das dores ´e importante para alertar os profissionais da sa´ude sobre a criticidade da situac¸˜ao. Como o acompanhamento desses pacientes ´e geralmente longo, a coleta dessas informac¸˜oes precisa ser realizada regularmente, a fim de manter os profissionais da sa´ude sempre atualizados sobre o tratamento dos pacientes.
Tradicionalmente o usu´ario responde o question´ario da PBB atrav´es de uma aplicac¸˜ao no dispositivo m´ovel. Contudo, as perguntas e respostas s˜ao apresentas ao usu´ario em modo texto. Ent˜ao o MHNSS pode ser acionado para fornecer ao usu´ario uma opc¸˜ao facilitada de acessibilidade para respon-der `as perguntas.
Para utilizar o MHNSS, a aplicac¸˜ao PBB disponibiliza atrav´es da interface de programac¸˜ao do middleware as quest˜oes selecionadas e algumas respostas de referˆencia para cada pergunta. Essas respostas de referˆencia auxiliam o ge-renciador de di´alogo a identificar respostas v´alidas para cada pergunta, principalmente quando for necess´ario realizar o PLN. Em posse dessas informac¸˜oes, o sistema de di´alogo interage com o usu´ario atrav´es da fala at´e obter respostas
4
http://www.nltk.org/
v´alidas para todas as perguntas, ou seja, ele conversa com o usu´ario de v´arias formas e quantas vezes forem necess´ario at´e conseguir as respostas. Ao final do question´ario, o servic¸o informa `a aplicac¸˜ao PBB as respostas coletadas. Na Fi-gura 5 tem-se o exemplo de um di´alogo gerenciado pelo MHNSS para o preenchimento de um question´ario enviado pela aplicac¸˜ao PBB.
Figura 5. Question´ario preenchido com o MHNSS
Neste exemplo o sistema de di´alogo busca fazer trˆes per-guntas ao usu´ario (linhas 3, 7 e 11). Para cada uma de-las ´e demonstrado um comportamento diferente do sistema. Na primeira pergunta (linha 3), o MHNSS se recuperou de erro interno provavelmente ocorrido na captura da resposta do usu´ario (por exemplo, erro de comunicac¸˜ao com o servic¸o de convers˜ao do ´audio) e, por isso, foi necess´ario refazer a pergunta (linha 5). Na segunda pergunta (linha 7) o sistema obteve como resposta uma express˜ao mais elaborada (linha 8), mas com a ajuda do PLN, como demonstrado no exemplo da Figura 4, ele conseguiu compreender a resposta e confir-mou isso com o usu´ario (linhas 9 e 10). J´a na terceira pergunta (linha 11) o sistema n˜ao foi capaz de compreender a resposta de imediato e, por isso, precisou interagir mais vezes com o usu´ario at´e obter uma resposta satisfat´oria para a pergunta (linhas 13 a 16). As linhas 1, 2 e 17 s˜ao express˜oes defini-das pela aplicac¸˜ao que requisitou o servic¸o, que no caso foi a PBB, e s˜ao utilizadas para introduzir, comentar e concluir o di´alogo da forma que a aplicac¸˜ao achar melhor para a ex-periˆencia do usu´ario. Ap´os conclus˜ao do di´alogo, o MHNSS envia as respostas obtidas para a aplicac¸˜ao PBB, que conti-nuar´a com o processo de acompanhamento de sa´ude do paci-ente.
Metodologia de Avaliac¸ ˜ao
A avaliac¸˜ao do MHNSS foi realizada com sujeitos que, vo-luntariamente, utilizaram a aplicac¸˜ao PBB e responderam ao question´ario atrav´es do di´alogo gerado com os recursos do
middlewareproposto. Os sujeitos foram recrutados na uni-versidade (nos arredores do laborat´orio de pesquisa) e du-rante os testes foram encaminhados a uma sala com baixa circulac¸˜ao de pessoas e com acesso `a Internet via rede local sem fio. Os sujeitos utilizaram a aplicac¸˜ao individualmente, para que cada um tivesse seu primeiro contato com o sis-tema de di´alogo apenas no momento do teste. A avaliac¸˜ao do MHNSS foi realizada de duas formas: mensurando aspectos de performance de um SDS [11] (quantitativa) e analisando a aceitac¸˜ao da aplicac¸˜ao m´ovel com interac¸˜oes baseada na fala pelo usu´ario [6] (qualitativa).
Na avaliac¸˜ao de performance do MHNSS, o servic¸o ´e anali-sado quantitativamente com relac¸˜ao a seus componentes de forma individual e tamb´em o sistema completo. A avaliac¸˜ao individual dos componentes aborda aspectos de precis˜ao do sistema com relac¸˜ao `as respostas dos usu´arios. As m´etricas utilizadas nessa avaliac¸˜ao s˜ao: Exatid˜ao da Palavra (Word Accuracy), que conta a precis˜ao do sistema em reconhecer as palavras ditas pelo usu´ario. Essa m´etrica est´a diretamente relacionada com o componente de Reconhecimento da Voze ´e mensurada em porcentagem atrav´es da relac¸˜ao en-tre o n´umero de palavras ditas e o n´umero de palavras reconhecidas corretamente; a Exatid˜ao da Sentenc¸a (Sen-tense Accuracy) mede a porcentagem de sentenc¸as (frases completas) que o sistema reconheceu corretamente. Nessa m´etrica avaliamos se o sistema foi capaz de iniciar e fina-lizar o reconhecimento no momento certo, capturando ape-nas o que o usu´ario quis dizer e desconsiderando ru´ıdos do ambiente. Ela tamb´em est´a relacionada diretamente com o componente de Reconhecimento da Voz e ´e men-surada pela diferenc¸a entre o n´umero de sentenc¸as ditas e sentenc¸as reconhecidas erroneamente; e a Compreens˜ao da Sentenc¸a (Sentence Understanding) mede quantas vezes o componente Compreens˜ao da Linguagem, atrav´es das t´ecnicas de PLN, foi capaz de entender uma sentenc¸a e identi-ficar a resposta do usu´ario. Essa medic¸˜ao ´e dada pelo n´umero de sentenc¸as consultadas em relac¸˜ao ao n´umero de sentenc¸as compreendidas.
Quanto a avaliac¸˜ao de performance do sistema completo, uti-lizamos as seguintes m´etricas. O N´umero de Turnos (Num-ber of Turns) mede quantas interac¸˜oes foram necess´arias para completar todo o di´alogo. Cada interac¸˜ao, seja por parte do usu´ario ou do sistema, ´e considerada como um turno do di´alogo e ´e mensurado pela soma do n´umero de turnos de ambos. A Taxa de Correc¸˜ao (Correction Rate) mede quantos turnos do di´alogo foram dedicados a corrigir alguma falha do sistema, seja falha de reconhecimento, de compreens˜ao ou fa-lha interna do servic¸o. O Tempo de Transac¸˜ao (Transaction Time) mede quanto tempo demorou todo o di´alogo. A Taxa de Sucesso (Transaction Sucess) mensura quantas informac¸˜oes foram poss´ıveis coletar do usu´ario com sucesso. Essa m´etrica avalia se para cada pergunta realizada do question´ario uma resposta v´alida foi obtida. No entanto, as falhas nas coletas de respostas n˜ao indicam que houve falha no sistema, pois h´a casos em que o sistema de di´alogo n˜ao consegue compreen-der as respostas do usu´ario sucessivas vezes e precisa pular a pergunta para n˜ao ficar preso a ela.
Os resultados para a avaliac¸˜ao de performance do MHNSS s˜ao obtidos de trˆes formas. Primeiramente atrav´es de um log que cont´em cada interac¸˜ao ocorrida no di´alogo, simi-lar ao mostrado na Figura 5. Este log ´e gerado apenas du-rante o processo de avaliac¸˜ao e ´e enviado ao servidor ap´os a utilizac¸˜ao por cada sujeito. Atrav´es dele ´e poss´ıvel mensurar v´arias m´etricas, como N´umero de Turnos, Taxa de Correc¸˜ao, Tempo de Transac¸˜ao e Compreens˜ao da Sentenc¸a. Para auxi-liar a medir essas m´etricas e outras como Exatid˜ao da Palavra e Exatid˜ao da Sentenc¸a, utilizamos o ´audio do di´alogo que ´e gravado durante a avaliac¸˜ao individual com cada sujeito. Esse ´audio ´e gravado, com o consentimento dos avaliados, atrav´es do gravador de som de um notebook e ´e utilizado, por exem-plo, para identificar se o usu´ario falou algo diferente do que o sistema reconheceu e registrou no log. Assim, ´e poss´ıvel identificar tamb´em se houve fatores que interferiram no re-conhecimento da voz, como um barulho no ambiente ou se o usu´ario comec¸ou a falar antes do sistema finalizar a pergunta. Outra forma de obtenc¸˜ao da avaliac¸˜ao ´e atrav´es do relat´orio gerado pelo middleware com as perguntas realizadas e as res-postas coletas durante o question´ario. Este relat´orio ´e enviado para a aplicac¸˜ao PBB como retorno `a solicitac¸˜ao do servic¸o e tamb´em auxilia na avaliac¸˜ao da m´etrica Taxa de Sucesso. Ap´os os testes com o uso da aplicac¸˜ao, cada usu´ario responde um question´ario qualitativo6 para avaliarmos a opini˜ao dele com relac¸˜ao ao servic¸o. Neste question´ario o sujeito informa seu gˆenero, idade, escolaridade, profiss˜ao e se ele j´a havia utilizado smartphone antes. Atrav´es desses dados podemos fazer uma classificac¸˜ao dos perfis dos usu´arios e observar as necessidades e dificuldades de cada perfil. Juntamente com essas informac¸˜oes, o question´ario pede que o sujeito avalie o sistema qualitativamente baseado em oito afirmac¸˜oes em que ele especifica o seu n´ıvel de concordˆancia com as afirmac¸˜oes, atrav´es de respostas baseadas na escala Likert [6]. Atrav´es dessa medic¸˜ao ´e poss´ıvel identificar o qu˜ao positiva foi a ex-periˆencia dos sujeitos com o servic¸o, a fim de medir o seu n´ıvel de aceitac¸˜ao com o uso do sistema de di´alogo. A Fi-gura 6 exibe as afirmac¸˜oes e poss´ıveis respostas contidas no question´ario qualitativo.
Ainda no question´ario qualitativo, h´a um espac¸o dedicado a cr´ıticas e sugest˜oes, em que o sujeito pode expressar livre-mente sua opini˜ao sobre o sistema de di´alogo e que ser˜ao consideradas para futuras vers˜oes do middleware.
RESULTADOS E DISCUSS ˜AO
O perfil dos sujeitos que utilizaram o MHNSS atrav´es do uso da aplicac¸˜ao PBB para avaliac¸˜ao foi bastante diversificado. Ao todo foram 10 sujeitos, com perfis apresentados na Ta-bela 1 e identificados de P1 a P10. Dentre eles, P3 e P6 ale-garam nunca terem utilizado smartphone antes. Esse perfil re-presenta o p´ublico diversificado que pode utilizar os recursos do middleware junto `as aplicac¸˜oes do projeto MobileHealth-Net, inclusive a PBB, desde pacientes com baixa escolaridade at´e profissionais da sa´uda com formac¸˜ao superior.
6
Este question´ario n˜ao refere-se ao mesmo solicitado pela aplicac¸˜ao PBB, mas sim a um preenchido a punho ap´os o seu uso.
Figura 6. Question´ario qualitativo
Sujeito Gˆenero Idade Escolaridade Profiss˜ao
P1 F 30 M´edio Vendedora
P2 F 37 M´edio Dona de Casa
P3 F 35 M´edio Vendedora
P4 M 26 Mestrado Programador
P5 M 28 Superior Estudante
P6 M 50 M´edio Servic¸os Gerais
P7 F 26 Superior Estudante
P8 M 26 Superior Estudante
P9 M 33 Superior Professor
P10 F 54 M´edio Dona de Casa
Tabela 1. Perfil dos sujeitos participantes da avaliac¸˜ao
Os resultados obtidos na avaliac¸˜ao quantitativa foram bas-tante positivos. De acordo com os dados coletados atrav´es dos logs e dos ´audios gravados durante a avaliac¸˜ao, a m´edia de Exatid˜ao das Palavras reconhecidas dentre todos os sujei-tos foi de 96,09% (DP7=0,05). Este resultado aponta o com-ponente Reconhecimento da Voz como favor´avel para fazer a coleta da voz do usu´ario em portuguˆes com alta taxa de precis˜ao. Mesmo quando a palavra era reconhecida erronea-mente, percebeu-se que geralmente havia uma similaridade fon´etica com a palavra correta, como por exemplo quando o usu´ario falava “sim”, mas era reconhecido como “se”. Esses erros geravam turnos adicionais no di´alogo para corrigi-los, mas n˜ao comprometiam a performance geral do sistema. Quanto a m´edia de Exatid˜ao da Sentenc¸a, 96,17% (DP=0,04) das express˜oes ditas pelos sujeitos foram reconhecidas com-pletas e corretas. As falhas foram ocasionadas devido o su-jeito em algumas casos comec¸ar a responder antes do sistema estar pronto para capturar o ´audio, o que resultava em pala-vras reconhecidas a mais ou a menos. Essas falhas tamb´em resultavam em n´umeros adicionais de turnos para correc¸˜ao, mas eram mais f´aceis para o componente Compreens˜ao da Linguagem identificar a resposta correta atrav´es do PLN. A taxa de Compreens˜ao da Sentenc¸a, que est´a dire-tamente relacionada com o sucesso no reconhecimento da
resposta por parte do PLN, obteve uma m´edia de 88,33% (DP=0,15).
Em condic¸˜oes ideais, o MHNSS necessita de, no m´ınimo, 21 turnos de di´alogo para coletar as nove respostas solicitadas pela PBB. Nessa contagem considera-se interac¸˜oes por parte do sistema e por parte do usu´ario. Durante as avaliac¸˜oes, o N´umero de Turnos m´edio foi 23 (DP=1,63), o que n˜ao est´a muito longe do ideal. A Taxa de Correc¸˜ao foi de 2 turnos em m´edia, o que demonstra exatamente a diferenc¸a entre o n´umero de turnos ideal do n´umero de turnos obtido.
O Tempo de Transac¸˜ao m´edio para que cada sujeito comple-tasse o question´ario foi de 123 segundos (DP=14,47), o que n˜ao ´e um tempo ruim, pois estima-se que, em condic¸˜oes ide-ais, o sistema necessite cerca de 110 segundos para esse pro-cesso. A Taxa de Sucesso obtida foi de 100%, ou seja, todos os sujeitos conseguiram responder `as 9 perguntas do ques-tion´ario completamente e as respostas coletadas foram con-firmadas como as fornecidas por eles.
Quanto a avaliac¸˜ao qualitativa, tamb´em obtivemos resultados bastante positivos. No question´ario cada sujeito deveria espe-cificar o seu n´ıvel de concordˆancia com as afirmac¸˜oes sobre o sistema que acabara de utilizar. A Figura 7 exibe quantos sujeitos elegeram aquele n´ıvel de concordˆancia para as res-pectivas afirmac¸˜oes.
Figura 7. Resultado da avaliac¸˜ao qualitativa
Analisando esses resultados qualitativos, verifica-se que to-dos os sujeitos alegaram que foi f´acil ou muito f´acil res-ponder o question´ario (Afirmac¸˜ao 1) e utilizar a aplicac¸˜ao (Afirmac¸˜ao 2) atrav´es da fala. A avaliac¸˜ao dos sujeitos quanto ao sistema entender o que eles diziam (Afirmac¸˜ao 3) foi for-temente positiva em mais da metade dos casos. J´a quanto a voz do sistema (Afirmac¸˜ao 4), ela foi unanimemente avali-ada de f´acil compreens˜ao. O desempenho do sistema foi dito como sempre r´apido (Afirmac¸˜ao 5) por 8 sujeitos e que em 100% do casos ele coletou todas as respostas corretamente (Afirmac¸˜ao 6). Por fim, de acordo com os sujeitos, o sistema foi capaz de lidar bem com os erros (Afirmac¸˜ao 7) e que ´e
sempre prefer´ıvel utilizar o sistema de di´alogo para respon-der ao question´ario (Afirmac¸˜ao 8) em 90% das avaliac¸˜oes. Os resultados demonstram que para os perfis de usu´arios que fizeram parte da avaliac¸˜ao, o MHNSS apresentou ´otimo de-sempenho no reconhecimento e na compreens˜ao das pala-vras, al´em de um tempo m´edio e n´umero de turnos pr´oximos ao ideal. O middleware foi ainda eficaz em coletar as informac¸˜oes requisitadas pela aplicac¸˜ao e os sujeitos n˜ao tive-ram dificuldades em utiliza-la atrav´es da fala. Os resultados mostram, principalmente, que a proposta foi bem aceita pe-los sujeitos, pois eles alegaram preferir utilizar o sistema de di´alogo em vez de preencher o question´ario digitando as res-postas.
TRABALHOS RELACIONADOS
Alguns SDSs com abordagem voltada para atenc¸˜ao `a sa´ude s˜ao encontrados na literatura, como o apresentado em [5], em que pessoas que cuidam de crianc¸as com HIV podem interagir com o sistema para obter informac¸˜oes sobre a doenc¸a. Esse trabalho tamb´em ´e dedicado a usu´ario com baixa alfabetizac¸˜ao e, por isso, utiliza o di´alogo como forma de acessibilidade, mas possui uma estrutura simples com o conte´udo agrupado em menus l´ogicos e ´audios pr´e-gravados, enquanto nossa proposta apresenta uma estrutura capaz de atender requisic¸˜oes mais livremente e com reproduc¸˜ao de ´audio sob demanda. J´a em [12] um sistema com di´alogo mais flex´ıvel ´e disponibilizado na Web, ele ´e utilizado para prover acesso e incentivar militares a buscar tratamentos de sa´ude, aconselhando-os e iniciando o contato com um profissional real. Contudo, diferente da nossa proposta, esse ´e um sis-tema totalmente voltado para a Web e n˜ao fornece nenhum tipo de processamento do di´alogo. Outro sistema dedicado a atenc¸˜ao `a sa´ude ´e o apresentado em [13], em que ele utiliza ´audios pr´e-gravados para fornecer informac¸˜oes para suporte a profissionais da sa´ude no Paquist˜ao, diferenciando-se prin-cipalmente por promover um intercˆambio do idioma urdu e o inglˆes, mas ainda sem qualquer tipo de processamento de di´alogo ou aplicac¸˜ao no ambiente m´ovel.
Em [10] um assistente virtual ´e apresentado para auxiliar o usu´ario em v´arios assuntos do cotidiano atrav´es de um di´alogo aberto e levando em considerac¸˜ao aspectos afetivos. Nesse trabalho h´a um cuidado maior com o processamento do di´alogo, possuindo inclusive componentes para compre-ens˜ao de linguagem natural, assim como em [17], em que um assistente virtual chamado de Companion auxilia seus donos a manterem um estilo de vida saud´avel atrav´es de exerc´ıcios f´ısicos e alimentac¸˜ao controlada. Contudo, cada um adota uma estrat´egia de processamento diferente. Al´em disso, nesse ´ultimo, a interac¸˜ao com o assistente virtual tamb´em pode ser realizada atrav´es de dispositivos m´oveis, mas diferente do MHNSS, n˜ao houve qualquer preocupac¸˜ao dos desenvolve-dores quanto as limitac¸˜oes impostas pelos ambiente m´ovel. Assim, comparado a esses trabalhos, nossa proposta ´e mais audaciosa em v´arios sentidos. Primeiramente, ela ´e um middlewaree fornecer recursos para a criac¸˜ao de aplicac¸˜oes m´oveis de diversos tipos com suporte a sistema de di´alogo. Portanto, nossa soluc¸˜ao n˜ao foca em um tipo espec´ıfico de aplicabilidade, apesar do nosso cen´ario ser dedicado `a
atenc¸˜ao a sa´ude e termos levado em considerac¸˜ao requisitos deste dom´ınio para a construc¸˜ao do middleware. Segundo, ela foca na utilizac¸˜ao em dispositivos m´oveis com pouco recurso computacional, atentando para as suas limitac¸˜oes e necessida-des. Terceiro, ela atende a perfis diversificados de usu´arios, incluindo pessoas de diferentes gˆeneros, idades, escolarida-des e profiss˜oes. Ela ainda diferencia-se por utilizar o idioma portuguˆes brasileiro.
CONCLUS ˜OES
Neste artigo apresentamos o MHNSS, um middleware que oferece recursos facilitadores para utilizac¸˜ao de aplicac¸˜oes m´oveis atrav´es da fala. Para isso, o middleware supera al-guns desafios na utilizac¸˜ao de um sistema de di´alogo no am-biente m´ovel, como adotar uma abordagem descentralizada de arquitetura para contornar limitac¸˜oes de recursos dos dis-positivos e reduzir o tr´afego de dados na rede m´ovel para mi-nimizar custos com a comunicac¸˜ao. Al´em disso, ele executa em segundo plano como um servic¸o Android, o que permite seu uso em conjunto com as aplicac¸˜oes, fornecendo acessibi-lidade para qualquer tipo de aplicac¸˜ao m´ovel. Para avaliac¸˜ao do MHNSS realizamos um estudo de caso com uma aplicac¸˜ao dedicada a atenc¸˜ao `a sa´ude, cujos resultados demonstraram que os recursos do MHNSS tiveram um ´otimo desempenho, e a aplicac¸˜ao foi f´acil de utilizar e teve grande aceitac¸˜ao por diversos perfis de usu´arios.
Como trabalhos futuros, pretendemos realizar avaliac¸˜oes com usu´arios analfabetos, com limitac¸˜oes motoras e deficientes vi-suais, os quais s˜ao tamb´em p´ublico alvo do projeto Mobile-HealthNet. Outra avaliac¸˜ao que pretendemos fazer ´e verificar a performance do MHNSS em cen´ario que o dispositivo tenha acesso atrav´es de uma conex˜ao de Internet 3G. Em vers˜oes futuras, pretendemos analisar as sugest˜oes dos usu´arios para realizar poss´ıveis aperfeic¸oamentos no middleware. Al´em disso, tamb´em testaremos servic¸os de convers˜ao de ´audio que sejam gratuitos, utilizem o portuguˆes brasileiro e que tenham desempenho equivalente ou pr´oximo ao Dragon Mobile SDK. AGRADECIMENTOS
Os autores gostariam de agradecer a Fundac¸˜ao de Amparo `a Pesquisa e ao Desenvolvimento Cient´ıfico e Tecnol´ogico do Maranh˜ao (FAPEMA) e Conselho Nacional de Desenvolvi-mento Cient´ıfico e Tecnol´ogico (CNPq) pelo apoio dado ao projeto.
REFER ˆENCIAS
1. Bickmore, T., and Giorgino, T. Health dialog systems for patients and consumers. Journal of Biomedical Informatics 39, 5 (2006), 556 – 571.
2. Drake, M. A., Ed. Encyclopedia of library and information sciences. CRC Press, 2003.
3. Dugdale, D. C., Epstein, R., and Pantilat, S. Z. Time and the patient–physician relationship. Journal of General Internal Medicine 14, S1 (1999), 34–40.
4. Furtado, E. S., Chagas, D., Bittencourt, I. I., and Fac¸anha, A. Acessibilidade e inclus˜ao digital — grandes desafios de pesquisa em interac¸˜ao humano-computador no brasil. Tech. rep., CEIHC-SBC, 2014.
5. Grover, A., Plauche, M., Barnard, E., and Kuun, C. Hiv health information access using spoken dialogue systems: Touchtone vs. speech. In ICTD (2009), 95–107.
6. Love, S. Understanding mobile human-computer interaction. Elsevier, Amsterdam, 2005.
7. McTear, M. F. Spoken Dialogue Technology: Toward the Conversational User Interface. Springer London, 2004. 8. Neustein, A., and Markowitz, J. Mobile Speech and
Advanced Natural Language Solutions. Springer London, 2013.
9. Pinheiro, V., Endler, M., and Hermann, E.
Patient-buddy-build: Customized mobile monitoring for patients with chronic diseases. In Proc. of eTELEMED (2013).
10. Pulman, S. G., Boye, J., Cavazza, M., Smith, C., and de la C´amara, R. S. ’how was your day?’. In Proc. of Workshop on Companionable Dialogue Systems, Association for Computational Linguistics (Stroudsburg, PA, USA, 2010), 37–42.
11. Rajput, N., and Nanavati, A. A. Speech in Mobile and Pervasive Environments, 1st ed. Wiley Publishing, 2012. 12. Rizzo, A., Sagae, K., Forbell, E., Kim, J., Lange, B.,
Buckwalter, J., Williams, J., Parsons, T., Kenny, P., Traum, D., Difede, J., and Rothbaum, B. ’simcoach: An intelligent virtual human system for providing
healthcare information and support’. In I/ITSEC (2011). 13. Sherwani, J., Ali, N., Mirza, S., Fatma, A., Memon, Y.,
Karim, M., Tongia, R., and Rosenfeld, R. Healthline: Speech-based access to health information by low-literate users. In ICTD (2007), 1–9.
14. Suendermann, D. Advances in Commercial Deployment of Spoken Dialog Systems. Springer New York, 2011. 15. Teles, A., Gonc¸alves, J., Pinheiro, V., da Silva e Silva,
F. J., and Endler, M. Infraestrutura e aplicac¸˜oes de redes sociais m´oveis para colaborac¸˜ao em sa´ude. In CBIS (2012).
16. Teles, A. S., Pinheiro, D. N., Gonc¸alvez, J. F., Batista, R. C., Silva, F. J. S., Pinheiro, V., Haeusler, E., and Endler, M. Mobilehealthnet: A middleware for mobile social networks in m-health. In Proc. of MobiHealth 2012, Springer (2012).
17. Turunen, M., Hakulinen, J., St˚ahl, O., Gamb¨ack, B., Hansen, P., Gancedo, M. C. R., de la C´amara, R. S., Smith, C., Charlton, D., and Cavazza, M. Multimodal and mobile conversational health and fitness
companions. Computer Speech & Language 25, 2 (2011), 192 – 209.
18. Velicer, W., Prochaska, J., Fava, J., Laforge, R., and Rossi, J. Interactive versus noninteractive interventions and dose-response relationships for stage-matched smoking cessation programs in a managed care setting. Health Psychol 18, 1 (1999), 21–8.
