PT106436A - Método automático de mediação de comunicação assíncrona e não verbal por fluxos iconográficos interactivos - Google Patents

Abstract

A PRESENTE INVENÇÃO CONSISTE NUM MÉTODO DE DESENVOLVIMENTO RÁPIDO DE APLICAÇÕES MÓVEIS NATIVAS SEMPRE DISPONÍVEIS, ATRAVÉS DE PROTOTIPAGEM RÁPIDA PARA MULTIPLATAFORMA, DEFININDO UM MODELO UNIFICADO DE ACESSO A SERVIÇOS PRESTADOS POR ENTIDADES EXTERNAS, ATRAVÉS DE UMA INTERFACE MÓVEL, REGIDA POR FLUXOS ICONOGRÁFICOS COM INTERACÇÕES NÃO-VERBAIS. O MODELO OPERA EM AMBIENTE DISTRIBUÍDO, USANDO UMA APLICAÇÃO CLIENTE ALOJADA NUM DISPOSITIVO MÓVEL E UM SERVIÇO DE MEDIAÇÃO, ONDE SÃO EXECUTADOS MÓDULOS DE INTERMEDIAÇÃO DA COMUNICAÇÃO E DE INTEGRAÇÃO COM OS SERVIÇOS DAS ENTIDADES EXTERNAS. A ALOCAÇÃO CONTEXTUAL DINÂMICA DOS SERVIÇOS DE COMUNICAÇÃO UTILIZADOS, ASSEGURA O ACESSO AOS SERVIÇOS EXTERNOS ATRAVÉS DAS APLICAÇÕES MÓVEIS EM QUALQUER ALTURA E EM QUALQUER LUGAR, COM RECURSO À MEDIAÇÃO DA COMUNICAÇÃO.

Description

BBsesxçlo Método Automático de Mediação de Comunicação Assíncrona e Não-verbal por Fluxos Iconogrâficos Interativos

1.CAMPO TÉCNICO BA XMVEEÇÃQ A presente invenção consiste num método dê ^e^envoivittfôntQ rápido de aplicações moveis nativas sempre disponíveis, através de prototipagem rápida para multiplataforma, bastando para isso apenas definir o fluxo aplicacional, com integração de serviços sempre disponíveis, através do serviço de mediação e dos serviços de comunicação dinâmicos. Esta solução foca-se na prestação de um serviço genérico que garante soluções interativas com base em fluxos iconogrãfíoos para a comunicação não-verbal, como um serviço integrado de mediação e comunicação com serviços externos <

3,. ANTECEDENTES DA INVENÇÃO

Este Método Automático de Mediação de Comunicação Assíncrona e Não Verbal foi inspirado por trabalhos anteriores, dos inventores, no sentido de facilitar as atividades diárias dos surdos, através de aplicações móveis. A primeira aplicação baseada neste método de comunicação não-verbal foi o SOSPhone e permite que as pessoas surdas comuniquem com os serviços de emergência. O seu potencial e a eficácia demonstrada motivou-nos a aplicar o mesmo conceito em outros dois cenários: contacto com serviços de assistência, em viagem. (My Car Mofei .1 e} e marcação, de consultas e outros atos médicos ÍM3App) As subsecções que se seguem descrevem brevemente estas três aplicações moveis, e representam a base da proposta que estamos a demonstrar.

Existe um conjunto de soluções que seguem alguns aspetos da nossa abordagem. Estas soluções incluem ferramentas de acesso à prestação do serviço de emergência médica para os surdos W02 0 0 7 0.9 0 9 0.9, que é semelhante ao trabalho real içado no SOS Phone. A invenção W02 00? 090.909 remove as barreiras de comunicação e impede o envolvimento de terceiros num ambiente de total mobilidade, onde a aplicação de recolha de informação médica é integrado com um dispositivo móvel e o referido dispositivo móvel ê integrado com o funcionamento do serviço de emergência. Esta invenção permite estabelecer um pré-diagnóstico pelo serviço de emergência de uma forma co.nr iâvel, devido à simplicidade e facilidade de uso da aplicação de recolha de informações médicas instalada no dispositivo móvel do paciente, 0 trabalho realizado no SOSPhone é uma aplicação móvel que. permite facer chamadas de emergência sem a necessidade de recursos de áudio. Esta aplicação oferece ao utilizador urna interface de toque iconográfico que lhe permite contactar com o serviço de emergência escolhendo os ícones que representam o problema que está a ser relatado, bem como clicar em algumas caixas para responder a perguntas simples, tais como o número de vitimas na ocorrência. O fluxo da aplicação segue o protocolo definido pelos serviços de emergência para a recolha de dados da emergência ocorrida, A comunicação entre o utilizador e o ponto de atendimento de segurança pública (PSAP) é efetuado através de uma mensagem de 5MS, que è codificada contendo toda a descrição da ocorrência é inclui ainda informações de localização fornecidas pelo dispositivo. Assim., o SOSPhone difere de W0200709090S* uma vez que o SOSPhone efetua comunicações nâo-verbais & não recorre a um serviço de mediação de mensagens para comunicar com os serviços externos. W02010043247 apresenta um método para a definição de uma descrição dos fluxos de dados de uma rede. Este método utiliza uma gestão de fluxos para direcionar um fluxo de dados (pacotes} a partir da fonte até ao destino através de um determinado percurso. No entanto, esta abordagem é útil se só ium nó tiver acesso à rede, por isso difere da solução que aprese.nta.mos porque não usamos apenas â ligação à Internet, mas todos os serviços de comunicação disponíveis nos dispositivos móveis, A solução apresentada, em WQ2011133908 utiliza um serviço para estender os serviços IMS - Subsistema Multimedia IP -· para alcançar as redes e dispositivos de comunicação locais existentes, e refere-se ao fornecimento de IMS em conteúdo multiméaia para dispositivos que sào ou não compatíveis com o IMS, mas não tão bem adaptados para o conteúdo fornecido. O conteúdo multimedia podem ser dados, como vídeo HD ou outros conteúdos, e comunica com o serviço através da rede local,. rede T\!i--Fi, e rede corporativa. Além disso, esta solução é bastante diferente da nossa abordagem, uma vez que as comunicações em WO20111339G8 são apenas baseadas no serviço, e foca-se apenas em estender os serviços IMS para alcançar as redes e dispositivos de comunicação. Contrariamente à nossa abordagem, que apresenta foco não só na gestão da informação proveniente dos dispositivos móveis, mas também na gestão de serviços externos, 0 documento W02009044214 descreve um sistema de comunicações e um método para criação visual, envio e receção de mensagens entre dois dispositivos (telemõveis) através de um servidor, customízado para pessoas com incapacidades físicas ou problemas de saúde. O referido método contêm os passos de apresentação de um menu com símbolos pictóricos divididos em categorias, para seleção de uma delas pelo utilizador, consequente seleção de uma imagem, preparação da imagem para transmissão, seleção do destinatário, transmissão da mensagem e consequente receção no dispositivo móvel de um destinatário. A mensagem transmitida poderá ser encaminhada para o servidor que reencaminha para o dispositivo destinatário. Embora WQ20G9044214 possa aparentemente apresentar algumas semelhanças com o método iconogrâfíco do SOSPhone e com o reeneaminhamento de mensagens entre o dispositivo móvel e o servidor, este difere da solução proposes, uma vez que e referente ao fluxo das aplicações móveis e à troca, de mensagens entre o dispositivo móvel e um serviço de mediação que comunica com serviços externos. G documento US2007224972 descreve um sistema e um método para criação de mensagens de texto num dispositivo eletrónico, que contem uma pluralidade de teclas, às quais estão associadas informações apresentadas visualmente ao utilizador. De acordo com a seleção de teclas realizada pelo utilizador, ê gerada uma mensagem no dispositivo electrõnico, através de uma funcionalidade de envio de mensagens, sendo posteriormente enviada para um destinatário na formai de SMS. É ainda revelado em US2007224S72 que o método de envio de mensagens contém os passos de criação de uma mensagem com seleção de pelo menos uma tecla â© dispositivo, â qual está associada uma informação visual e consequente envio da mensagem. Contudo, US2G07224972 difere da nossa abordagem, que compreende a transformação dos pacotes de reencaminhamento, através da aplicação de regras de transformação, era regras de encaminhamento, que são instaladas no serviço de mediação, para. serem aplicadas âs mensagens das aplicações para os serviços externos, 0 documento vi02GGM44214 revela um sistema e método associado para a comunicação entre dois dispositivos móveis, sendo a interface de introdução de dados apresentada aos utilizadores através de imagens, O documento WO2G09044214 apresenta uma arquitetura composta por dispositivos moveis, servidores de mediação, canais de comunicação entre dispositivos móveis, serviços externos e interfaces, interfaces de aplicações e de comunicação entre os servidores de mediação e os serviços externos. Contudo, o documento WO2Q09044.214 difere da nossa solução por este se tratar de um método de desenvolvimento rápido de aplicações moveis nativas com integração de serviços sempre disponíveis, Complementarmente, o método da nossa solução está associado â comunicação exclusiva entra serviços presentes nas aplicações móveis e os respectivos serviços externos através de comunicação assíncrona e não-verbal, contrarlamente ao documento W02 0 0 9014 2 i 4 que é exclusivo a comunicação entre dispositivos móveis, O documento WO2G06075334 consiste no envio de mensagens em formato de imagens entre dispositivos móveis que contenham baixo nível de resolução. Contudo, o documento $$02006075334 difere da nossa proposta, uma vez que se trata, de um método de desenvolvimento rápido de aplicações móveis nativas com integração de serviços sempre disponíveis em que a comunicação é feita entre as aplicações móveis e os serviços externos, O documento US2003060240 revela uma invenção relacionada com as comunicações de dispositivos moveis, maia especifícamente no envio e recepção de mensagens de imagem entre utilizadores de dispositivos móveis, O documento US2003060240 difere da presente invenção porque a solução aqui apresentada não é relacionada com o envio de mensagens de imagem mas sim com õ desenvolvimento e comunicação entre os serviços instalados nas aplicações móveis {desenvolvidas pelo método proposto} e os seus raspectivos serviços externos. O documento CABO,. M, , et al. . "Exploring iconographic interface in emergency for deaf'' é da autoria dos proponentes deste pedido de patente e die respeito a uma interface de aplicação móvel que permite a comunicação de cidadãos surdos com os serviços de emergência. Este documento é descrito neste pedido de patente (secção 2.1} e ê uma interface móvel que se enquadra no processo de implementação de aplicações móveis seguindo o método aqui apresentado.

2,1 . BOSBHÔME A proliferação dos dispositivos moveis nas duas últimas décadas ampliou a possibilidade de desenvolver aplicações moveis que suportam de forma eficiente os utilizadores no decorrer das suas atividades diárias. Uma situação que beneficiou a população em geral foi a maior disponibilidade de chamadas de emergência, uma vez que se tornou disponível em qualquer telefone móvel. No entanto, ainda ê muito complicado e extremamente difícil para algumas pessoas fazerem uma chamada, por motivo de alguma deficiência ou mesmo em situações de emergência de trauma. Um caso óbvio é o de pessoas surdas, que sãc incapazes de comunicar através de uma chamada de voz. Outros exemplos em que pode ser dific.il articular palavras são os de idosos que tenham alguma doença ou que estejam numa situação crítica repentina, ou até mesmo situações violentas que originem estados de choque ou pânico.

De acordo com o Relatório Mundial sobre a Deficiência de 2011. o número de pessoas com deficiência no mundo é atualmente estimada em um bilião, o que corresponde aproxi.madame.nte a 15% da população do mundo atual. 0 prefácio do relatório diz que "[.--3 as pessoas com deficiência experienciam barreiras no acesso aos serviços que muitos de nós há muito temos tomadas por concedidas O mesmo relatório indica que 124,2 milhões de pessoas no mundo têm perda de audição, o que corresponde a cerca de 2% da população mundial, cerca de metade deles com idade acima de 60 anos. Ετη Portugal,, de acordo corn os censos de 2001 , havia maia de 636 mil pessoas com deficiência, e mats de 84 mil com deficiências na audição. Além disso, tanto em Portugal como no resto mundo, há um maior grau de analfabetismo entre as pessoas com deficiência, auditiva.

Atualmente as soluções existentes para efetuar chamadas de emergência são baseadas em comunicação por texto, ambas síncronas e assíncronas, comunicação por vídeo, e/ou aplicações móveis. O uso de uma solução de comunicação baseada em texto tem como principal desvantagem o facto de a língua nativa de muitos eidadã.os surdos ser a linguagem gestual e alguns serem mesmo analfabetos. Contudo, a maior parte da comunicação assíncrona baseada em texto através de mensagens SMS origina uma lentidão no uso do sistemas de emergência, uma vez que são realizadas várias trocas de mensagens para explicar a situação a um centro de atendimento (PS.AP) . As soluções tecnológicas de comunicação síncrona baseadas em texto sáo geralmente baseadas em TTY ou mensagens instantâneas, representando assim uma alternativa mais benéficas que as mensagens de SMS. No entanto, ainda precisam de trocar um grande volume ele mensagens para descrever a situação de emergência e podem ainda necessitar de acesso à rede de dados. A desvantagem de utilizar a linguagem gestual para efetuar chamadas de emergência em soluções de comunicação de vídeo é que estas requerem um intérprete de linguagem gestual permanente no PSAP ou a utilização de serviços intermédios. Para além disso, é ainda necessário ter largura de banda disponível para a transmissão do video. Alguns estudos também apontam que os utilizadores que comunicam somente através de mensagens de texto ou através de vídeos montados a partir de segmentos modulares., tratam com desprezo o uso da linguagem gestual em vídeos contínuos. A maioria, das soluções existentes emprega o desenvolvimento específico de aplicações móveis paru comunicar com os serviços de emergência. Em alguns casos, incluem um mecanismo de triagem pré-definida para aumentar a resposta ao pedido de emergência. Contudo, a maioria deles têm interfaces de texto, que, pelas razões acima explanadas, restringem o uso da aplicação. Aliás, as aplicações atuais falham na descrição da situação de emergência e no estabelecimento de um canal de çomuníeaçá© bidirecional de pós -pedido,

Tendo em consideração o que foi apresentado anteríormente, utna possível solução que garanta o acesso universal aos serviços de emergência requer uma aplicação para dispositivos móveis,. que pode ser adaptada a outros dispositivos com capacidade de comunicação,, orientada para os requisitos descritos, h aplicação deve combinar algumas das soluções apresentadas de forma a atingir as necessidades e preferências dos utilizadores, bem como a. realidade operacional das PSAP. Uma vez que as soluções atuais não produzem os efeitos desejados a esses níveis e na necessidade de um sistema de resposta de curto prazo para os requisitos de acessibilidade dos serviços de emergência,. o principal objetivo do SOS Phone é © desenvolvimento de uma aplicação móvel que permita uma comunicação eficaz com os PSAP, 0 SOSPhone ê uma aplicação móvel que permite fazer chamadas de emergência sem a necessidade de recursos de áudio, K.sta aplicação move .1 oferece ao utilizador uma interface de toque íeonográfico que lhe permite contactar com o centro de emergência escolhendo os ícones que representam o problema que está a ser relatado, bem como clicar em alguns botões para responder a perguntas simples, tais como o número de vitimas na ocorrência- O resultado deste processo de seleção é uma mensagem SMS que ê enviada contendo os códigos que correspondem a informação selecionada, juntamente com as coordenadas de quem envia a mensagem. Para além das principais ca.racterí éticas apresentadas do SOS Phone, foram ainda 1 n c 1 u 1 da s as s e gu 1 n.t e s : * Protocolo de fluxo de emergência incorporado ~ de modo a facilitar a integração com os sistemas existentes a aplicação permite ao utilizador descrever a situação corn o maior detalhe possível, seguindo os protocolos de emergência, utilizados pelos centros de controlo de emergência. ·« Largura de banda reduzida para comunicar com o centro de controlo de emergência -- o uso da largura de banda deve ser reduzida para permitir «ma comunicação mais rápida, da situação de emergência. * Localização automática do incidente (implícita ou explicita). * Identificação de quem faz a chamada. * Necessidade de registo do utilizador - p&rá ajudar a evitar chamadas falsas. « Comunicação bidirecional entre o utilizador e o PSAF após o relatório da. situação de emergência. A avaliação deste protótipo incluiu a realização de entrevistas com os utilizadores surdos e com as pessoas responsáveis pelos serviços de emergência em Portugal., ou seja, MPC, Polícia, GHR. 112. pt e INEM. Esta fase de avaliação produziu os seguintes requisitos: 2.1.1. Protótí po A solução implementada procura explorar uma interface que se baseia em ícones paxa descrever uma. situação de emergência. Para. se proceder à recolha dos dados da situação de emergência (ocorrência), o fluxo da aplicação é gerido pelo protocolo definido pelos serviços de emergência. A comunicação entre quem faz a chamada e o PSAP e executada utilizando uma mensagem de SMS, que é codificada ao longo da descrição da ocorrência e inclui informações de localização fornecidas pelo dispositivo móvel. A Figura 1 mostra algumas imagens da aplicação. A interface de toque iconográfico foi implementada recorrendo a ícones de símbolos de referência, tendo em consideração as melhores práticas das aplicações móveis (hfctp: / / wv* w, »v3 . org/TF</rtiwabp/) , e os elementos de invalidez necessários para os dispositivos moveis (http: //trace . wise . edu/docs/201 Q - phoneessentials/index.php). Os ícones foram agrupados por gxavidade conforme as diversas situações de emergência, de modo a que o visor não esteja sobrecarregado com o excesso de informação, permitindo utu melhor uso por parte de pessoas com baixa mobi11dade,

Com o intuito de garantir uma comunicação de baixa largura de banda com o centro de controlo de emergência, a aplicação envia apenas uma mensagem SMS, A construção da mensagem SMS é feita através do processo, com base nas letras e números, representado em cada. uma das opções selecionadas,, tendo em. conta a limitação de 160 carateres. As informações do registo do utilizador são concatenadas a esta informação, incluindo o nome, a idade e o número de segurança social. A informação da localização é também incluída na mensagem de SMS, recorrendo ao GPS e/ou àe coordenadas fornecidas pelo operador móvel, 0 registo do utilizador é obrigatório e é executado quando a aplicação móvel é iniciada pela. primeira ves., X4ormalmen.ts, um telefone é pessoal, de modo que os dados registados só serão recolhidos uma ves« No entanto, os dados do registo poderá ser alterados na última etapa da chamada de emergência, antes de enviar a mensagem SMS,

Em relação à instalação do protocolo do fluxo de •emergência, esta solução inclui mecanismos que permitem a definição de fluxos dinâmicos, sem alterar o código fonte da aplicação, permitindo a adaptação dos fluxos recorrendo a atualizações dinâmicas na aplicação móvel através das redes de dados (3G/WÍ--FÍ) ,

2.2. MYCAR MOBILE

Um dos problemas de comunicação que os surdos enfrentam no seva dia-a-dia, especialmente aqueles que têm carta de condução, ocorre quando estes ficam parados na estrada devido a uma avaria na viatura ou mesmo em caso de acidente, e necessitam de comunicar com a. assistência em viagem, Uma pesquisa efetuada com. a comunidade surda Portuguesa revelou que 80% têm carta de condução e que cerca, de 56% precisaram pelo menos uma vez de ligar .para a assistência em viagem.

Esta pesquisa também revelou que cerca de 64% das empresas de assistência em viagem tem suporte de comunicação para surdos, no entanto, em 56% das ocasiões os surdos enfrentaram problemas de comunicação (36% dos inquiridos não responderam a esta questão, pelo que este número pode ser ainda maior), levando a que cerca de metade dos casos f o s sem r et i rados,

Os resultados apresentados indicam que as atuais soluções de comunicação entre surdos e a assistência em viagem não são eficientes e estão dependentes da ajuda de terceiros. Neste contexto, a disponi. foxlidade de uma aplicação móvel que utilize a comunicação iconogrâfica pode ajudar a resolver esta lacuna no quotidiano dos surdos.

Esta aplicação móvel é intitulada de ''MyCarMobile'' e são consideradas três categorias de ocorrência.: falha da viatura, acidente e outros problemas, 0 fluxo desta aplicação móvel esfã descrito na Figura 2.

2,3. MSAFP " MY MÓBILE MEDICAL APPOINTMENT

De um modo geral, os surdos enfrentam vários problemas de comunicação quando lidam com os serviços públicos, no entanto surgem dificuldades ainda ma is criticas quando se trata de questões de saúde e de segurança. O í!My Mobile Medicai. Appointment” (M3ft.pp) é uma aplicação para dispositivos moveis que permite aos utilizadores efetuarem marcações de consultas médicas, selecionando ícones iconogrâficos, seguindo a mesma interação e princípios arquitetônicos do SOS Phone. Mais uma vez, apesar da sua inspiração nas necessidades especificas dos surdos, também é adequado para qualquer outro utilizador, devido ã sua conveniência e ao facto de a sua utilização ser intuitiva. Esta aplicação móvel evita telefonemas demorados e exclui a necessidade de uma pessoa ter que se deslocar a um centro de saúde específico para marcar urna consulta. A M3App tem caracteristicas semelhantes as do SOSPhone e ãs do MyCarMobile, possuindo algumas caracteristicas mala especificas: « Possibilidade de utilização de serviços do localização para ajudar o utilizador a encontrar" os serviços de saúde que estão mais perto. * Possibilidade de escolher critérios para filtrar o local pretendido - uso da localização atual, com base no endereço da pessoa e corn as preferências das unidades de saúde, médicos, regiões, cidades, etc, ·· Serviço de mediação - A M3App é a interface do utilizador para uma infinidade de serviços de saúde, que são geridos por um serviço de mediação central pa^a orientar o processo de determinação das organ! zações aderentes (hospitais, clínicas., centros de saúde) - ver a Figura 3,

Ativação na primeira utilização os utilizadores devem preencher um perfil cie utilizador que inclui os dados ma.is relevantes de identificação, tais como o nome, o número de identificação, a morada, o sistema de saúde ou o numero do seguro, ou mesmo ainda alguma informação clínica, m.ais relevante {conta doenças ou incapacidades permanentes). 0 fluxo da aplicação é demonstrado na Figura 4. A opção "Minhas Consultas" dá acesso à lista de futuras consultas e a todo o histórico de consultas antigas, o que pode ser útil para aj udar na marcação de novas consultas, juntamente com. a lista de favoritos. O 'utilizador, ao fazer uma nova consulta, pode optar por usar o seu próprio perfil para marcar uma consulta para ele próprio, ou pode fasê-lo para. outra pessoa, sendo necessário para isso fornecer manualmente todos os detalhes. Quando o utilizador finaliza o preenchimento de todas as: inf-ormações necessárias para marcar uma consulta, esta informação é enviada para o serviço de mediação através do serviço de comunicação de rede mais conveniente. 0 serviço de mediação processa esta informação e envia-a à unidade de. cuidados de saúde adequada., que terá posteríormente de confirmar ou negociar alternativas ao pedido efetuado. Ã comunicação entre o serviço de mediação e a unidade de saúde pode ser feito através de serviços web, SMS ou e-mail. A Figura 5 mostra uma imagem do protótipo M3Αρρ.

3.DESCRIÇÃO GFR&L DA INVENÇÃO h presente invenção define um método unificado de acesso a serviços externos, através de uma interface móvel, regida por fluxos iconogrâficos com interações não-verbais, O método opera em ambiente distribuído e incorpora uma aplicação cliente alojada num. dispositivo movei e um serviço de mediação, onde .são executados módulos de mediação da. comunicação e integração com os serviços externos. A generalização da solução perm.·.te a criação de aplicações específicas para cada serviço a ser prestado num ambiente comum, assegurando a partilha de recursos, a escala e o alcance da solução, optimizando a viabilidade dos serviços prestados.

Este método apresenta mais-valias na dísponifcílisação de aplicações moveis, recorrendo a prototipagem rápida para muifciplafcaferma baseada na especificação do seu fluxo aplicacional. A. transparência da comunicação associada â independência e alcoação contextuai dinâmica dos serviços de comunicação utilizados, assegura o acesso aos serviços dispombi .1 i nados pelos serviços externos através das aplicações moveis em qualquer altura e em qualquer lugar, com recurso à mediação da comunicação.

4,DESCRIÇÃO DOS BISBOTOS

Figura 1: Protótipo da aplicação SOSPhone, dividida em 4 fases.

Figura 2; Apresenta todo o fluxo da aplicação mõvel PlycarMobile <

Figura 3: Exemplificação de como é feito a comunicação da aplicação móvel M3App com o serviço de mediação e todos os seus intervenientes.

Figura 4: Apresenta todo o fluxo da aplicação móvel 143App. B'igura 5: Protótipo da aplicação MBApp.

Figura 6: Visão geral do sistema proposto, onde são apresentados todos os intervenientes e a forma como estes comunicam entre si: aplicações móveis, serviços e interfaces de comunicação, serviço de mediação e serviços externos,

Figura f* Fluxo do pacote aplicacional no serviço de mediação.

Figura 8: Diagrama d.e blocos das £ une iona 1 idades da solução em tempo real.

Figura 9: Desenvolvimento da aplicação movei através da integração de fluxos aplicacionais e de ambiente de execução.

Figura 10; Componentes de execução da aplicação móvel,

5 * DESCRIÇÃO DETALHADA DA XMVEHÇ&O

As entidades que pretendam prestar um serviço destinado a pequenos grupos na sociedade enfrentam dificuldades ao nível da sustentabílidade financeira do negócio, associado ao fator de escala das soluções existentes. A solução proposta visa resolver este problema, uma vez que é uma solução genérica que pode ser utilizada para uma grande variedade de serviços, comparcilhando uma. infraestrutura aplicacional de suporte e de manutenção, deste sentido, a partir da perspetiva do gestor da entidade prestadora do serviço, o método proposto visa garantir a disponibilidade do serviço num curto período de tempo e garantir a minimisapão dos custos associados ao seu desenvolvimento è manutenção, maximizando a sua viabilidade financeira. Tendo em conta as exigências em matéria de acesso universal, a maioria dos produtos não são desenvolvidos, devido ao seu alto custo de desenvolvimento e ao pequeno mercado-alvo. A mudança de paradigma introduzida pelo método de mediação automática de comunicação assíncrona, não-verbal para os fluxos ieonográfíoos interativos através da agregação e rápido desenvolvimento de serviços, visa minimizar estes problemas.

Do ponto de vista dos utilizadores o objetivo é garantir o acesso aos serviços a que estão limitados a usar devido a restrições temporárias ou permanentes e às necessidades especiais/limitações. Estas restrições estão tipicamente relacionadas com a disponibilidade dos serviços quando é utilizada comunicação verbal (telefone) que restringe a sua utilização por parte de pessoas com necessidades especiais estimuladas pelo contexto ou pela falta, de audição/def iciêncías na. fala. A disponibilidade de uma interface gráfica intuitiva e de fácil aprendizagem, que atenda às necessidades do utilizador, e âs rotinas do dispositivo móvel no qual a. aplicação está a ser executada, é outro objetivo do método. Por conseguinte, a interface deve seguir os padrões de interface do dispositivo onde a aplicação se executa, a fim de assegurar una utilização consistente corn outras aplicações. A transparência re 1 a t ivaraente aos serviços de comunicação é outro grande objective e também uma exigência da aplicação movei, proporcionando o serviço de comunicação ma is eficiente em carda, momento, sem a intervenção do utilizador para contactar o serviço de mediação ar enviar ar mensargem do utilizador. Desta forma, por exemplo, se uma rede de dados está disponível, então esse serviço será. usado em vez do serviço de SMS. Por f im, as atualizações para o fluxo da aplicação são, de acordo com as opções padrão, realizadas automaticamente sem a necessidade de intervenção do utilizador e sempre que as condições de comunicação necessárias estejam reunidas. Estas atualizações incluem a redefinição do fluxo da aplicação que será fornecido pelas empresas que prestam o serviço,

CICLO DE VIÉS A solução é constituída por três componentes aplicacionais que interagem entre sí {.Figura 6) : uma aplicação móvel (601, um serviço de mediação da comunicação (603) e serviços externos (6 05) , Através da interface de acesso universal da aplicação móvel, o utilizador acede aos serviços externos, selecionando ícones apresentados segundo um fluxo pré-definido. A comunicação com os serviços externos é mediada pelo serviço de mediação. A mediação da comunicação assegura normalização da informação entre serviços externos e. as aplicações moveis, generalizando a solução e assegurando uma plataforma comum partilhada por diversas aplicações. Este processo envolve a. transformação dos formatos de dados, adaptação dos serviços de comunicação e encaminhamento das mensagens·. Ά transformação dos formatos de dados consiste na adaptação dos dados a transmitir ao serviço de comunicação mais adequado que esteja disponível no momento, por SMS ou dados moveis. No caso do SMS, requer a. codificação dos dados na aplicação móvel num formato alfanumérico que permita a sua. transmissão através de uma mensagem limitada a um máximo de 160 caracteres (ou a seus múltiplos) . Contudo, a transmissão de dados pode recorrer a outros serviços de comunicação baseados em redes de dados, usando protocolos de comunicação comuns da Internet, como sejam o email ou os serviços web. Mestos casos, ê preciso igualmente proceder â adequação dos dados a.o protocolo de comunicação usado. Caso não esteja disponível nenhum serviço de comunicação, a aplicação guarda os dados originais e procede á sua transmissão apenas quando estiver disponível um serviço de comunicação adequado, aplicando as necessárias transformações. Esta operação e transparente para o utilizador, que não se apercebe do não envio imediato da mensagem ~ conceito de serviços .sempre disponíveis. Mo serviço de mediação, os dados sã© transformados de novo, para o formato do serviço fornecido pela entidade externa, a. que se destina. Esta transformação pode ser realizada de novo para um formato SMS ou de transmissão de dados moveis, A recepção dos dados na interface de comunicação do serviço externo resultará numa nova transformação, podendo os dados ser visualizados numa interface gráfica, armazenados .numa base de dados, ou até ser usados para construir automaticamente invocações de outros serviços externos, entre outras opções.

Segundo este método, cada solução terá um ciclo ãe vida com quatro fases (Figura 7 e 8); * Planeamento e desenho (702}. * Instalação e testes (708). * Execução (802}, 9 Manutenção- e evolução.

Planeamento ® desenho (702) A primeira fase envolve o arquiteto (701), o gestor e os utilizadores (801) , assemelhando-se à fase de. conceção do projeto. Nesta etapa é realizada a análise de requisitos da solução a ser implementada, com base nas opiniões dos potenciais utilizadores e gestores dos serviços. O arquiteto utiliza as informações recolhidas a partir da análise de requisitos e desenvolve o fluxo de interação da aplicação (705), selecionando as plataformas moveis (703} em que a aplicação será. executada, e identifica ainda os serviços externos (704) que são necessários. Juntamente com estas ações é definido o encaminhamento de mensagens (713} no serviço de mediação, isto é, o fluxo de mensagens recebidas pela aplicação móvel para os serviços externos e vice-versa. Além disso, são selecionados os serviços de comunicação (713) a serem utilizados pela aplicação de entre os que são suportados pelo modelo. A definição do pr~ooes sarnento de mensagens ao níwl do serviço de mediação e o seu encaminharaenfco para oç serviços externos ê suportado por uma .ferramenta disponível para. o arquiteto. Baseada nos serviços externos existentes/'registados no serviço de mediação, nos adaptadores de comunicação e nos adaptadores dos serviços externos, a ferramenta informática de de & e πνο .1 v i me nt o das aplicações moveis permite a definição gráfica do seu fluxo de informação. Associada a esta ferramenta para a gestão de serviços externos, a definição do processo de encaminhamento pode ser manual ou semiautomática. No modo manual, o arquiteto define todo o processo, Ho modo semiautomático, a ferramenta de desenvolvimento deteta as earacterístícas de cada um dos serviços externos e sugere ao arquiteto os fluxos mais apropriados cora base na análise efetuada e no conhecimento do modelo. Para garantir a definição de um fluxo de informação, a. ferramenta permite a definição de; estados (interação e ação de estados); estruturas condicionais (if, case); estruturas cíclicas (por enquanto, repetir) e variáveis (tipos de dados simples e estruturas complexas). A base de um conjunto de ações para definir estados, em particular, enviar mensagens, receber mensagens, obter informações sobre a localização do serviço, registar continuaments as informações e ler informações persistentes, estão também disponíveis para o arquiteto. Para além disso, esta ferramenta fornece um conjunto de padrões de interação - Ícones, definição de localização, escolha múltipla, escolha da data - adequada ãs especificidades das interfaces moveis, a fim de garantir que os utilizadores tenham uma aprendizagem rápida e uma fácil adaptação ao utilizar a aplicação. A fase de planeamento e criação (702) completa--se com a criação de utn pacote aplicacional (706} contendo o fluxo de interação, rotas, e a seleção das plataformas moveis e serviços de comunicação a serem utilizados peia aplicação. Este pacote aplicacional é enviado para o administrador (707) para iniciar á fase de instalação e testes- dá aplicação (708) .

Instalação e testas (70S) A fase de instalação e testes (70S) está a cargo do administrador do sistema (707). As ferramentas fornecidas para o administrador incluem ferramentas de gestão de monitorização. Fazem parte das suas funções assegurar a gestão da. instalação e a manutenção da infraestrutura centralizada no serviço de mediação, È a este nível, que o serviço de mediação e todos os serviços periféricos são controlados. Com base no pacote aplicacional {706} fornecido, o administrador faz a ligação entre o fluxo {709} e o núcleo funcional (710) da aplicação móvel através da criação de uma aplicação para o cliente que é submetida aos mercados das aplicações de cada. uma das plataformas móveis selecionadas (711), O funcionamento do núcleo funcional da. aplicação móvel será ainda ma is detalhado. Para além disso, nesta fase., o pacote é compilado no serviço de mediação {Figura .9} , com base nas rotas e nos serviços de comunicação definidos pelo pacote aplicacional {706} criado na fase anterior, Kste pacote aplicacional (706) é inserido no serviço de mediação e são realizados um conjunto de testes funcionais © de integração. Depois desta fase {702), a di epon ibi X ização das aplicações nos mercados (711) , o serviço está pronto para ser usado e é iniciada a fase de execução do serviço (802), O administrador também gere o registo dos serviços externos para os quais as mensagens são encaminhadas. A este nível, torna-se um requisito o administrador" definir as políticas de integração mais adequadas a cada situação, utilizando para isso padrões ./modelos para. a integração cora as aplicações móveis, juntamente com os serviços externos. Deve notar-se que, devido à generalização da solução poderá coexistir vários níveis de integração e diferentes níveis de serviços, os quais afetam o tempo de resposta para o utilizador.

Execução (802) A fase de execução (802) é caracterizada pela disponibiiisação da aplicação aos utilizadores e é iniciada após a aplicação ser instalada nos dispositivos móveis (803), Nesta fase, todos os componentes operam em conjunto; a aplicação móvel, o serviço de mediação e os serviços externos. Uma vez que o funcionamento dos serviços externos é da responsabilidade do prestador do serviço, é efetuada, na fase de execução, uma análise do funcionamento da aplicação móvel e do serviço de mediação, A utilização dos serviços começa com a interação do utilizador com a aplicação móvel, seguindo o fluxo de interação definido pela aplicação (804) e a mensagem (80S) é criada, para o serviço/serviços de destino. A aplicação móvel é executada por um núcleo funcional (806) dividido em quatro blocos funcionais, como é demonstrado na Figura 10. A simplicidade estrutural do núcleo de execução tem a intenção de minimizar os intermediários e, assim, garantir níveis mínimos de desempenho na sua execução tendo em conta as limitações do equipamento no qual a aplicação ê executada (príncipalmente nos dispositivos móveis com menores capacidades).

Na parte inferior ao núcleo de execução é feita uma ligação de dados através de uma função de toloccs de análise de XML (1004). Os dados da aplicação usam a língua franca para troca de informações, XML, e portanto, a sua disponíbilízaçâo aos serviços está a cargo do bioco que interpreta e se adapta aos dados em execução, S também de salientar que os protocolos do fluxo da. aplicação são definidos em XML, de acordo com um esquema de XML específico. Com base rias informações carregadas peio bloco de acesso aos dados, os blocos funcionais UILoader (1003) e UI Pender (1002) cuidam das adaptações necessárias paira que esses dados sejam utilizados em tempo real (1001). 0 UILoader é responsável pelas estruturas de suporte e de envio de eventos com base no protocolo definido pelo fluxo da aplicação. Por outro lado, o UIRender realiza a verificação das interfaces do utilizador, validando a declaração de um único distribuidor do evento. A necessidade da existência d.e um único registo de expedição para. o evento esta relacionada com o funcionamento do ambiente de execução, tal como será posteríormente apresentado. Este bloco funcional também carrega as interfaces do utilizador com base nos ficheiros descritos, Fínalmente, o bloco funcionai de execução tem um componente, que executa o envio de eventos entre as interfaces e o utilizador, e é especificada no protocolo de fluxo da aplicação. A base de funcionamento deste bloco ê um GenericDispacher que despacha os eventos desencadeados na interface do utilizador para os estados definidos pelas transições do protocolo de fluxo da aplicação, Ho caso de ocorrerem açoes de invocação dinâmica de métodos, estes são garantidos por meio de mecanismos de reflexão,

Ho final da interação do cliente é enviada uma mensagem para o serviço de mediação (Figura 5 5 utilizando ura dos serviços de comunicação disponíveis. O serviço é selecionado tendo em consideração o contexto {di sponibi1idade dos serviços de comunicação), as interações e o tipo de mensagem. Ao detetar a receção da mensagem (807), o serviço de mediação processa a mensagem, a fim de obter o identificador de serviço associado a mensagem recebida. Com base no serviço externo a que se destina e no serviço de comunicação em que foi recebida a mensagem são aplicados filtros (808) de conteúdos por forma a reconstruir a mensagem para um formato intermédio (por exemplo, transformação da mensagem de vos em texto dada a disponibilidade exclusiva do canal de vos aquando do envio da mensagem). Seguidamente, os módulos associados ao serviço são ativados/executados para proceder ao tratamento e encaminhamento da mensagem., mediante o definido pelo pacote aplicacional. O serviço de mediação acompanha a transformação (808) e a fase do envio da mensagem para a porta de destino, de acordo cora as regras do serviço - definidas durante o desenvolvimento da aplicação, durante a instalação no serviço de mediação e de acordo com os requisitos das característícas de que cada serviço. A mensagem é recodificada com o formato descrito na política de integração definida entre © serviço de mediação e o serviço externo. Assim que ê confirmado que a mensagem foi enviada com sucesso é contabilizada no sistema essa. ação, e se necessário, os mecanismos de retorno são ativados para receber a. resposta. Neste caso, ao enviar a mensagem (807) de resposta, o mecanismo que é processado é inverso ao da receção, a fim de enviar a resposta para o utilizador.

Manutenção e evolução

Paralelamente à fase de execução segue a fase de manutenção e evolução da solução. Para garantir a alta disponibilidade da solução, estas fases podem ser executados em paralelo, necessitando o sistema de garantir um sistema de controlo de versões que determina não só © tipo de pedido, mas também a. sua versão, garantindo sempre a disponibilidade da versão atual e anterior até que haja registos de a. aplicação ter sido atualizada em todos os clientes, A manutenção de uma aplicação pode ser feita ao nível da aplicação do lado do cliente ou no pacote da aplicação, que está alojado e que é executado pelo serviço de mediação. A evolução do modelo é assegurada pelo programador, para o qual o modelo jã é considerado de baixo nível, sob os auspícios de cada. um. dos blocos funcionais. A partir desta perspetiva, o modelo é visto por Interfaces de Programação de Aplicações (API) dos vários componentes, a fim de evoluir a solução para as necessidades do mercado, de acordo com as novas exigências dos serviços externos. Para atingir este objetivo, é uma exigência que o modelo tenha um conjunto de referências de API para garantir o seu desenvolvimento, nomeadamente: * API ce referência para a instalação da módulos de tradução/integraçâo com os serviços externos. « API de referência para a criação dos adaptadores de comunicação, * API para a criação de ações ao nível da interface do dispo si t ivo move1, * API para a interação de modelos/padrões.

As atualizações que modificam o fluxo de interação da aplicação são efetuadas no âmbito da aplicação do cliente. Ao nível do núcleo aplicativo as atualizações são consideradas na evolução da solução. Portanto, o nível de atualização da aplicação do cliente é composto por: * Criação de um novo fluxo da aplicação, * Compilação do pacote da atualização. * Instalação do pacote aplicacional da atualização nó serviço de atualização no serviço de mediação. » Bonificação da disponibilidade de atualização das aplicações instaladas. * Cada pedido, quando deteta as condições necessárias de comunicação para realizar a atualização, efetua o download e instala. o pacote aplicacional da atualização loca1mente. * Carregamento dinâmico do novo fluxo aplíCACional-

No que diz respeito às atualizações no serviço de mediação, este também incluí alterações nos fluxos de envio da aplicação. Além disso, a evolução do serviço de mediação inclui o desenvolvimento e fornecimento de novos recursos. Atualizando a lógica de envio de um serviço, este inclui- « Criação de uma nova lógica de envio. * Compilação da atualização do pacote dé envio. .· Compilação da atualização do pacote da aplicação para o serviço de mediação, com. base no pacote aplicacional de atualizações submetidas, • Instalação das atualizações da aplicação no serviço cifô mediação. « Testar a instalação atualizada. ã evolução da solução compreende a atualização do núcleo de execução da aplicação móvel, fornecendo novas característíeas associadas com a aplicação, bem como a correção de erros. Este processo envolve o programador,, que desenvolve as novas funcionalidades ou as correções de erros existentes. Envolve ainda o administrador, que apôs a disponibilizaçâo do novo núcleo de execução regenera todas as aplicações alojadas na plataforma, baseadas no novo núcleo e torna as atualizações disponíveis nas aplicações móveis comercializadas. Este processo termina quando os utilizadores executarem .manualmente a atualização da aplicação móvel.

Da mesma forma, o desenvolvimento é realizado para o serviço de mediação, de ix.a ndo o programador implementar novas funcionalidades ou correções de erros, e ao administrador a instalação de novos módulos e testés aplicacionais antes de passar â produção.

Claims (5)

1. REIVINDICAÇÕES 1- Método automático de mediação de comunicação assíncrona e não·· verbal de fluxos iconográficos interativos, caraterizado por compreender um método de desenvolvimento rápido de aplicações moveis nativas {601}, através da definição doe fluxos aplicacionais usando uma ferramenta gráfica, assim como a integração de serviços sempre disponíveis, através da interação conjunta de vários componentes: serviço de mediação {603}; serviços de comunicação (602) entre as aplicações móveis (601) e o serviço de mediação (603); os serviços externos (605) ; as interfaces apiiea.cion.ais {€04} e de comunicação entre o serviço de mediação (603) e os serviços externos (606} .
2. 2~ Método automático de mediação de comunicação assíncrona e não-verbal de fluxos iconográficos interativos, de acordo com a reivindicação anterior, caraterizado por compreender a transformação dos fluxos aplicacionais {901}, definidos através de uma ferramenta gráfica de prototipagem rápida, que contêm o fluxo de acesso ao serviço e que associados a ura componente de execução {902} permitem a. criação de uma aplicação {903}, que é dispon.ibii izada aos utilizadores nos mercados aplicacionais e Ibes proporciona o acesso a serviços externos.
3. 3— Método automático de mediação de comunicação assíncrona e não-verbal de fluxos iconográficos interativos, de acordo com a reivindicação 1 caraterizado por permitir a transformação de formatos de dados produzidos pela aplicação em dados compatíveis com o formato de transmissão de dados do serviço de comunicação ma í s adequado disponível no momento (5MS, dados móveis ou adiamento até que esteja disponível um serviço dé comunicação, sendo selecionado apenas nesse momento) ,· de forma transparente para o utilizador, criando a. sensação de serviços sempre disponíveis e sem pereepçáo do serviço de comunicação usado.
4. 4- Método automático de mediação de comunicação assíncrona e não-verbal de fluxos i conogrâí í cos interativos, de acordo com a reivindicação anterior., caraterizado por a mensagem ser recebida no serviço de mediação, ser detetado o serviço de comunicação pelo qual a mensagem foi recebida, verificada a aplicabilidade de regras de transformação de formatos de dados {de acordo cora a.s regras de reencaminhamento definidas pelo programador durante a instalação dos serviços no serviço de mediação, em função das necessidades de comunicação com ou serviços externos requeridos- pela aplicação) e reencaminhada para os serviços externos requeridos pela aplicação através de serviços de comunicação próprios (606) e mediante as regras de encaminhamento.
5. 5 - Método automático de mediação de comunicação assíncrona e não-verbal de fluxos iconográficos interativos, de acordo com as reivindicações anteriores, caraterizado por em caso de resposta do serviço externo para o cliente, o processamento da mensagem segue o próces-sd inverso. Vila Real, S de Dezembro de 2Q14