U
NIVERSIDADE DET
RÁS-
OS-M
ONTES E ALTO DOUROSOSPhone: Aplicação móvel de acesso
universal para efetuar chamadas de
emergência
Dissertação de Mestrado em Engenharia Informática
Filipe Gonçalves Fernandes
U
NIVERSIDADE DET
RÁS-
OS-M
ONTES E ALTO DOUROSOSPhone
Aplicação móvel de acesso universal para
efetuar chamadas de emergência
Dissertação de Mestrado em Engenharia Informática apresentada
por
Filipe Gonçalves Fernandes
Vila Real, 2014
Dissertação apresentada por Filipe Gonçalves Fernandes à Universidade de Trás-os-Montes e Alto Douro para o cumprimento dos requisitos necessários à obtenção do grau de Mestre em Engenharia Informática, sob a orientação do Professor Doutor José Benjamim Ribeiro da Fonseca e Professor Doutor Hugo Alexandre Paredes Guedes da Silva.
"You can't connect the dots looking forward, you can only connect them looking backwards. So you have to trust that the dots will somehow connect in your future. You have to trust in something: your gut, destiny, life, karma, whatever. Because believing that the dots will connect down the road will give you the confidence to follow your heart, even when it leads you off the well worn path." (Steve Jobs - Stanford Commencement Speech, 2005)
R
ESUMO
Nas últimas duas décadas, a proliferação do uso dos dispositivos móveis permitiu o aumento do desenvolvimento de aplicações móveis que suportam eficientemente muitas das atividades diárias dos utilizadores.A adoção geral dos dispositivos móveis e a grande cobertura de rede tornou possível efetuar chamadas de emergência em qualquer lugar, contudo é recorrente o uso de voz.
Esta restrição é um problema não só para pessoas surdas, mas também para pessoas idosas sem necessidades especiais que enfrentam situações em que é difícil articular o discurso.
Neste contexto, foi criado o SOSPhone, um protótipo de uma aplicação móvel que possibilita aos utilizadores efetuar chamadas de emergência usando uma interface iconográfica num dispositivo móvel tátil.
Durante o desenvolvimento deste protótipo foram surgindo requisitos técnicos de integração com as soluções existentes dos serviços de emergência. Neste sentido houve a necessidade de estudar as possíveis soluções que permitissem resolver estes problemas.
O objetivo principal deste trabalho é estudar as possíveis soluções para os problemas de integração do SOSPhone com os serviços de emergência, sendo os seus contributos ao nível da Engenharia de Software. Deste modo, será desenvolvida uma nova arquitetura que suporte os principais requisitos do SOSPhone, nomeadamente, um modelo de integração e adaptação dinâmica do conteúdo, por dados propagados por um sistema central, baseado em fluxos de informação, que representam a lógica de funcionamento da aplicação.
A
BSTRACT
In the last two decades, the proliferation of the use of mobile devices has enabled increased development of mobile applications that support efficiently many of the daily activities of users.The widespread adoption of mobile devices and the wide network coverage became possible to make emergency calls in any place, but is recurrently using voice. This restriction is a problem not only for deaf people but also for older people without special needs who face situations where it is difficult to articulate speech.
In this context, the SOSPhone, a prototype of a mobile application that enables users to make emergency calls using an iconographic touch interface on a mobile device was created.
During the development of this prototype technical integration requirements have arisen with existing solutions for emergency services in this sense was necessary to study possible solutions allowing to solve these problems.
The main objective of this work is to study possible solutions to the problems of integration of SOSPhone with the emergency services, and their contributions to the level of Software Engineering. Thus, it will be developed a new architecture that supports the main requirements of SOSPhone in particular a model of integration and dynamic adaptation of content, data propagated by a central system, based on information flows, which represent the logical application operation .
Dedico esta obra aos meus pais que
sem o seu apoio nada disto teria sido
possível.
A
GRADECIMENTOS
Esta dissertação representa uma etapa muito importante na minha vida cuja realização só foi possível devido ao auxilio e ao apoio de algumas pessoas, a elas um muito obrigado.Quero dedicar esta dissertação aos meus pais e irmã, sem eles nada disto seria possível. Obrigado pela paciência, pelo esforço e pelo apoio.
Quero agradecer aos meus orientadores, Professor Hugo Paredes e Professor Benjamim Fonseca, por toda a ajuda e orientação neste trabalho, pela disponibilidade, pela exigência, pela motivação e por todos os conselhos que me auxiliaram no decorrer deste processo.
À Universidade Trás-os-Montes e Alto Douro, pela formação académica e por me proporcionar esta oportunidade.
A minha colega Miriam Cabo pela ajuda, pela simpatia demonstrada, pela motivação que sempre me deu e sem dúvida um exemplo a seguir.
Ao André Pinheiro por estar sempre presente nos momentos mais importantes da minha formação académica, pela motivação, pela exigência, pela força e coragem.
Aos meus colegas Tiago Pinto, Luís Filipe Gonçalves, César Meira, Jorge Freitas, André Sousa, Hugo Fernandes, Ricardo Nunes e Tânia Pereira por estarem sempre prontos a ajudar, pela simplicidade, pela amizade, pelos bons momentos de descontração a eles um muito obrigado.
A todos que, direta ou indiretamente me ajudaram a desenvolver este trabalho, a eles, um muito obrigado.
Filipe Fernandes
Í
NDICE
Resumo ... vi
Abstract ...viii
Agradecimentos ... xii
Lista de Figuras ... xvi
Lista de Tabelas ... xviii
Siglas e Acrónimos ... xx Capítulo 1... 1 1. Introdução ... 3 1.1. Enquadramento ... 3 1.2. Motivação e contribuições ... 5 1.3. Objetivos do Trabalho ... 6 1.4. Estrutura ... 7 Capítulo 2... 9
2. Tecnologias para a Criação Adaptáveis de Interfaces de Dispositivos Móveis . 11 2.1. Enquadramento ... 11
2.2. Dispositivos Móveis ... 11
2.3. Interfaces Adaptáveis ... 13
2.4. Modelos de Interfaces Adaptáveis ... 14
Capítulo 3... 17
3. Análise do Problema ... 19
3.1. SOSPhone ... 19
3.2. O número europeu de emergência 112 ... 19
3.3. Integração Serviços de Emergência ... 27
3.4. Tipificação e Caracterização ... 28
Capítulo 4... 29
4. Avaliação de Técnicas para a Criação de Interfaces ... 31
4.1. Enquadramento ... 31
4.2. Ambiente de Testes ... 31
4.3. Caracterização da amostra ... 34
4.3.1. Questionário de avaliação de técnicas de criação de interfaces móveis .... 34
4.4. Análise de Resultados ... 38
Capítulo 5... 43
5. Implementação do Serviço SOSPhone ... 45
5.1. Enquadramento ... 45
5.2. Especificação do modelo de dados ... 45
5.3. Desenvolvimento do protótipo ... 48
5.3.1. Especificação dos Requisitos... 48
5.3.2. Arquitetura ... 49
5.4. Avaliação do Protótipo ... 53
5.4.2. Dispositivos utilizados para teste ... 54 5.4.3. Layouts testados ... 55 5.4.4. Procedimentos ... 56 5.4.5. Resultados obtidos ... 59 5.4.6. Discussão ... 66 Capítulo 6... 69
6. Conclusão e trabalho futuro ... 71
6.1. Conclusão ... 71
Referências bibliográficas ... 73
L
ISTA DE
F
IGURAS
FIGURA 1-DEFINIÇÃO DE DISPOSITIVO MÓVEL (SEPPÄLÄ E ALAMÄKI 2003) ... 12
FIGURA 2-MODELO 1-EROHANDLING EMERGENCY CALLS ... 22
FIGURA 3-MODELO 2-FILTERING STAGE 1PSAP AND RESOURCE DISPATCHING STAGE 2PSAP ... 23
FIGURA 4-MODELO 3-DATA GATHERING BY STAGE 1,RESOURCE DISPATCHING BY STAGE 2 ... 23
FIGURA 5-MODELO 4-DATA GATHERING BY STAGE 1PSAP,RESOURCE DISPATCHING BY STAGE 2 IN AN INTEGRATED CONTROL ROOM ... 24
FIGURA 6-MODELO 5-EROINDEPENDENT PSAP ... 24
FIGURA 7-MODELO 6-INTERCONNECTED PSAP ... 25
FIGURA 8-MODELO 7-PSAP USADO EM PORTUGAL ... 26
FIGURA 9-FUNCIONAMENTO DA APLICAÇÃO DE TESTE ... 32
FIGURA 10-APLICAÇÃO DE TESTE DE UTILIZAÇÃO DE INTERFACE ... 33
FIGURA 11-CLASSIFICAÇÃO DOS UTILIZADORES QUANTO À IDADE ... 34
FIGURA 12-CLASSIFICAÇÃO DOS UTILIZADORES QUANTO AO TIPO DE SMARTPHONE QUE POSSUEM ... 36
FIGURA 13-CLASSIFICAÇÃO DOS UTILIZADORES QUANTO AO TEMPO QUE TÊM SMARTPHONE ... 37
FIGURA 14-GRÁFICO DA PERCEÇÃO DOS UTILIZADORES NA COMPONENTE BUTTON ... 38
FIGURA 15-GRÁFICO DA PERCEÇÃO DOS UTILIZADORES NA COMPONENTE CHECKBOX ... 39
FIGURA 16-CLASSIFICAÇÃO DA PERCEÇÃO DOS UTILIZADORES NA COMPONENTE RADIOBUTTON ... 40
FIGURA 17-GRÁFICO DA PERCEÇÃO DOS UTILIZADORES NA COMPONENTE TEXTFIELD ... 40
FIGURA 18-GRÁFICO DA PERCEÇÃO DOS UTILIZADORES NA COMPONENTE IMAGEBUTTON ... 41
FIGURA 19-ESTRUTURA DE FUNCIONAMENTO E CRIAÇÃO FICHEIRO DE CONFIGURAÇÃO ... 47
FIGURA 20-ESTRUTURA DE FUNCIONAMENTO E CRIAÇÃO FICHEIRO DE CONFIGURAÇÃO E DESIGN ... 48
FIGURA 21-ARQUITETURA GLOBAL DO SERVIÇO SOSPHONE ... 50
FIGURA 22-DIAGRAMA DE CLASSES DO SERVIÇO SOSPHONE ... 52
FIGURA 23-ARQUITETURA DO LAYOUT DE TESTES TABLELAYOUT ... 55
FIGURA 24-ARQUITETURA DO LAYOUT DE TESTES LINEARLAYOUT ... 56
FIGURA 25-INTERFACES LINEARLAYOUT ... 57
FIGURA 26-INTERFACES TABLELAYOUT ... 57
FIGURA 27-FUNCIONAMENTO DO TESTE ... 58
FIGURA 28-GRÁFICO DOS RESULTADOS OBTIDOS DO TEMPO DE CARREGAMENTO DO FICHEIRO XML DESIGN ... 60
FIGURA 29-GRÁFICO DOS RESULTADOS OBTIDOS DO TEMPO DE CARREGAMENTO DO FICHEIRO XML ... 60
FIGURA 30-GRÁFICO DOS RESULTADOS OBTIDOS DO TEMPO DE CARREGAMENTO DA INTERFACE 1 COM 1 BUTTON ... 61
FIGURA 31-GRÁFICO DOS RESULTADOS OBTIDOS DO TEMPO DE CARREGAMENTO DA INTERFACE 1 COM 4 BUTTONS ... 62
FIGURA 32-GRÁFICO DOS RESULTADOS OBTIDOS DO TEMPO DE CARREGAMENTO DA INTERFACE 1 COM 8 BUTTONS ... 63
FIGURA 33-GRÁFICO DOS RESULTADOS OBTIDOS DO TEMPO DE CARREGAMENTO DO INTERFACE 1 COM 16 BUTTONS ... 63
FIGURA 34-GRÁFICO DOS RESULTADOS OBTIDOS DO TEMPO DE CARREGAMENTO DA INTERFACE 2 COM 1 BUTTON ... 64
FIGURA 35-GRÁFICO DOS RESULTADOS OBTIDOS DO TEMPO DE CARREGAMENTO DA INTERFACE 2 COM 4 BUTTONS ... 65
FIGURA 36-GRÁFICO DOS RESULTADOS OBTIDOS DO TEMPO DE CARREGAMENTO DA INTERFACE 2 COM 8 BUTTONS ... 66
FIGURA 37-GRÁFICO DOS RESULTADOS OBTIDOS DO TEMPO DE CARREGAMENTO DA INTERFACE 2 COM 16 BUTTONS ... 66
L
ISTA DE
T
ABELAS
TABELA 1-COMPARAÇÃO ENTRE OS DIVERSOS MODELOS QUE DEFINEM UM PSAP ... 26
TABELA 2-CLASSIFICAÇÃO DOS UTILIZADORES QUE TÊM SMARTPHONE ... 35
TABELA 3-CLASSIFICAÇÃO DOS UTILIZADORES QUE TÊM SMARTPHONE COMO TELEFONE PRINCIPAL ... 35
TABELA 4–CLASSIFICAÇÃO DOS UTILIZADORES QUE JÁ USOU UMA LOJA DE APLICAÇÕES ... 37
TABELA 5 - COMPARAÇÃO DAS ESPECIFICAÇÕES DOS DISPOSITIVOS MÓVEIS USADOS NA AVALIAÇÃO DO PROTÓTIPO ... 54
S
IGLAS E
A
CRÓNIMOS
ADT
Android Development Tools
ERO
Emergency Response Organisations
EU
Europe Union
GNR
Guarda Nacional Republicana
GSM
Global System for Mobile Communications
HCI
Human Computer Interaction
HTML
HyperText Markup Language
MAI
Ministério da Administração Interna
PDA
Personal Digital Assitant
PSAP
Public Safety Answering Point
SDK
Software Development Kit
SMS
Short Message Service
XML
eXtensible Markup Language
C
APÍTULO
1
Introdução
“For people without disabilities, technology makes things easier. For people with disabilities, technology makes things possible.” Mary Pat Radabaugh
Neste capítulo é feito o enquadramento do trabalho desenvolvido no âmbito desta dissertação, apresentada a motivação e objetivos para a sua realização e identificadas as suas principais contribuições. O capítulo termina com a apresentação da estrutura da dissertação, incluindo uma descrição sumária dos capítulos que se seguem.
3
1. Introdução
1.1. Enquadramento
A adoção geral de dispositivos móveis e sua vasta cobertura de rede tornaram possível fazer chamadas de emergência praticamente em todos os lugares. No entanto, a necessidade de recorrer a áudio/voz para pedir ajuda de emergência, representa um problema para alguns grupos da população limitados das suas capacidades auditivas, em particular, para os surdos, pessoas idosas e pessoas que enfrentam situações, temporárias ou permanentes, em que a fala é difícil de articular (Paredes, et al. September 2013).
Segundo o Relatório Mundial sobre Deficiência 2011 (Organization e Bank WHO Press), o número de pessoas com deficiência no mundo é atualmente estimado em mil milhões, correspondente aproximadamente a 15% da população mundial atual. O prefácio do relatório diz que “estas pessoas têm barreiras no acesso a serviços que para muitos de nós, há muito tempo, que estão dado como garantido”. O mesmo relatório indica que 124,2 milhões de pessoas no mundo têm problemas de audição, correspondendo a cerca de 2% da população mundial, aproximadamente metade delas com idade acima de 60 anos de idade.
O serviço mais frequentemente usado por pessoas com problemas auditivos é o serviço de mensagens curtas, SMS (Short Message Service), sendo que 96% usam este serviço para comunicação interpessoal (Chien-Hsiou, et al. 2010).
Numa situação emergência é essencial rapidez e uma correta comunicação, que inclui a troca de informações como sintomas e historial clínico para um tratamento adequado. No entanto, essa comunicação pode tornar-se difícil se houverem barreiras, como por exemplo, a surdez (Buttussi, et al. 2010).
4
Em Portugal, está disponível um número para o qual as pessoas surdas podem enviar um SMS para pedir ajuda, em caso de emergência, este sistema é gerido pelo Comando Central da GNR (Guarda Nacional Republicana) (Interna 2008).
No caso Europeu, também estão disponíveis alguns sistemas que se baseiam não só serviço SMS, mas também em chamadas de vídeo ou fax.
O SMS tradicional, usado nestes sistemas, implica a escrita de texto que por vezes é uma barreia no momento de pedir ajuda, a incapacidade dos surdos chamarem o 112 através de um SMS demostra a inadequação deste tipo de tecnologia (Chien-Hsiou, et al. 2010).
Neste contexto, foi criado o SOSPhone, como um protótipo de uma aplicação móvel que permite realizar chamadas de emergência através de telemóveis com ecrã táctil, recorrendo a uma interface iconográfica. O protótipo foi demonstrado e avaliado por surdos, profissionais de serviços de emergência e população em geral (Pereira, et al. 2011). O conceito SOSPhone constituiu um primeiro passo no desenvolvimento de uma solução para os problemas associados à comunicação não-verbal de situações de emergência. O trabalho anteriormente desenvolvido visa a avaliação da usabilidade de interfaces iconográficas geridas por fluxos para a caracterização de situações de emergência (Fonseca 2011). A avaliação do conceito enquanto solução para a resolução do problema enunciado requer a sua disponibilização em situações reais, havendo para tal a necessidade de implementação de um piloto em conjunto com as forças de segurança, responsáveis pela coordenação do número europeu de emergência em Portugal (112.pt).
O principal objetivo deste trabalho de dissertação de mestrado é a implementação da base tecnológica para o desenvolvimento de um piloto do SOSPhone que permita avaliar a adequação do conceito a si associado em ambiente real. Para tal será necessário redesenhar a arquitetura da aplicação com vista à sua integração com os sistemas de informação dos serviços de suporte ao número europeu de emergência. A atual implementação será dotada de capacidades de integração, dinamismo e flexibilidade de maneira a que possa constituir uma solução
5
viável ao utilizador final e assegurando a comunicação com os serviços de emergência.
1.2. Motivação e contribuições
A motivação para a realização deste trabalho de mestrado é inerente à resolução de problemas estruturantes no acesso a serviços básicos por parte de cidadãos com necessidades especiais. Neste contexto, o contributo espectável deste trabalho é estudar as possíveis soluções para os problemas de integração do SOSPhone com os serviços de emergência. Este trabalho não está confinado à Engenharia de Software, tendo já sido alvo de trabalhos anteriores nas áreas da Acessibilidade e de Interação Pessoa Computador – HCI (Human-Computer Interaction).
Na área da acessibilidade, os contributos aferidos do trabalho anteriormente desenvolvido estão associados ao conceito SOSPhone, cujo principal objetivo é o criar uma tecnologia capaz de tornar pessoas com necessidades especiais, particularmente pessoas com problemas auditivos, independentes na hora de chamar os serviços de emergência. Este trabalho foi desenvolvido previamente no âmbito de projetos de Licenciatura em Engenharia de Reabilitação e Acessibilidades Humanas, Engenharia Biomédica e de Mestrado em Engenharia Informática. No decurso destes projetos, foram também avaliadas questões de interação pessoa-computador visando aferir a viabilidade da solução SOSPhone no suporte e auxilio a situações de emergência. Foram analisadas com particular detalhe questões associadas à interação do utilizador com a aplicação através da interface iconográfica proporcionada pelo protótipo, bem como a não necessidade de escrever texto, o que por vezes é uma barreira no momento de pedir ajuda.
6
O trabalho aqui proposto surge na sequência do anteriormente realizado, sendo os seus contributos ao nível da Engenharia de Software. Deste modo, será desenvolvida uma nova arquitetura que suporte os principais requisitos do SOSPhone, nomeadamente, um modelo de integração e adaptação dinâmica do conteúdo, por dados propagados por um sistema central, baseado em fluxos de informação, que representam a lógica de funcionamento da aplicação.
Nesta implementação, pretende-se criar uma aplicação de acesso universal de pedido de emergência através de uma interface iconográfica. A estrutura da aplicação será definida através de fluxos de informação que serão definidos por um sistema central. Estes fluxos podem variar dependendo da instituição/países que os emitir. A criação de uma arquitetura de software dinâmica traz vantagens ao nível da expansão e manutenção da aplicação, pois independentemente de quais forem os fluxos de funcionamento, esta irá funcionar em diferentes serviços de emergência/países.
1.3. Objetivos do Trabalho
A concretização dos objetivos globais passam pelo estabelecimento de objetivos parcelares que se concretizarão em várias etapas do seu desenvolvimento, utilizando a metodologia (Hevner, March, et al. 2004) (Hevner, A Three Cycle View of Design Science Research 2007). Apresenta-se assim, em seguida, a lista de objetivos parcelares que visam a concretização do objetivo primário:
Avaliar o estado da arte, através da análise de aplicações/arquiteturas de integração, destinando-se a documentar o que está a ser feito atualmente no campo em estudo, através da análise de soluções existentes e identificar referências bibliográficas que envolvam a leitura e análise das principais abordagens, metodologias, métodos e autores do tema em estudo.
7
Analisar os requisitos que será feita em conjunto com a empresa que vai executar integração do SOSPhone com os serviços de emergência, e nesta fase que vamos identificar, organizar e documentar os requisitos do sistema, e estabelecer e manter acordo entre a aplicação e o sistema central que vai gerir todo o processo.
Especificar um modelo de integração no qual vão ser enumerados todos os detalhes, acerca da comunicação entre os sistemas, resultante da análise de requisitos executados anteriormente. Para além disto, a aplicação terá de ser capaz de através de fluxos gerados pelo sistema central, ser capaz de automaticamente gerar o seu conteúdo. A estrutura vai definir o funcionamento da aplicação independentemente do fluxo que for emitido, isto significa que a aplicação deve funcionar com qualquer fluxo de emergência e em qualquer serviço de emergência independentemente do país.
1.4. Estrutura
A estrutura da presente dissertação encontra-se dividida em 6 capítulos, serão apresentados de uma forma detalhada e justificando todas as decisões tomadas, deste modo, a par da presente secção introdutória, a dissertação encontra-se organizada da seguinte forma:
Capítulo 2 - Tecnologias para a Criação Dinâmica de Interfaces para Dispositivos Móveis - Este capítulo apresenta uma revisão do estado da arte sobre criação interfaces para dispositivos móveis. Isto permitirá ter uma visão geral acerca do modo como outros sistemas abordam esta problemática e que tipos de soluções implementam. Este trabalho de levantamento bibliográfico será realizado com base na consulta de publicações científicas e pesquisa de eventuais soluções comerciais existentes nesta área.
8
Capítulo 3 – Análise do Problema – É efetuada o enquadramento do Serviço SOSPhone com os sistemas de atendimento de chamadas de emergência, descrevendo as principais características, nomeadamente tipificação e caracterização de ocorrência.
Capítulo 4 – Avaliação de Técnicas para a Criação de Interfaces – É descrita neste capítulo uma avaliação efetuada a utilizadores sobre a criação dinâmica de interfaces para dispositivos móveis. São também apresentados os resultados desta avaliação bem como a devida análise de resultados do estudo.
Capítulo 5 - Implementação do Serviço SOSPhone - Neste capítulo é apresentada a definição conceptual do projeto. É descrita implementação do serviço bem como a arquitetura e metodologia utilizada.
Capítulo 6 – Conclusão e Trabalho Futuro - Neste último capítulo são apresentadas as conclusões retiradas da elaboração deste trabalho bem como é descrito o trabalho futuro.
9
C
APÍTULO
2
Tecnologias para a Criação Dinâmica de
Interfaces Móveis
“The beauty is that through disappointment you can gain clarity, and with clarity comes conviction and true originality.” Conan O'Brien
Neste capítulo será apresentado um enquadramento sobre o estado da arte das tecnologias para a criação dinâmica de interfaces móveis. Pretende-se neste capítulo identificar os conceitos associados, identificação e distinção das principais tecnologias e interfaces móveis. Serão apresentadas os modelos e tecnologias de criação dinâmica de interfaces móveis.
11
2. Tecnologias para a Criação Adaptáveis de
Interfaces de Dispositivos Móveis
2.1. Enquadramento
Para desenvolver o presente trabalho foi necessário o estudo e compreensão de diferentes conceitos. No presente capítulo será efetuado o estado da arte ligado ao tema do trabalho. Serão alvo de análise os principais conceitos associados aos dispositivos móveis, pretendendo realçar as principais especificidades que interessam ao presente trabalho, nomeadamente, análise de tecnologias, interfaces adaptáveis, modelos de criação adaptáveis de interfaces.
2.2. Dispositivos Móveis
A tecnologia móvel provocou diferenças radicais na maneira como a sociedade trabalha, aprende e se diverte.
Segundo (Halpert 2005), dispositivos móveis são PDA (Personal Digital Assistant), telemóveis, computadores portáteis e smartphones.
A Figura 1 define o que são dispositivos móveis, apresentados anteriormente,
em três categorias: tecnologia sem fios, tecnologia móvel e tecnologia portátil (manual/dimensão reduzida).
12
FIGURA 1-DEFINIÇÃO DE DISPOSITIVO MÓVEL (SEPPÄLÄ E ALAMÄKI 2003)
O dispositivo que é transversal a todas as tecnologias apresentadas é o smartphone.
Segundo (Gandhewar e Sheikh 2011), o uso do smartphone tem vindo a aumentar dramaticamente ao longo dos últimos anos, atualmente não é apenas uma ferramenta para fazer chamadas e escrever SMS, mas sim um item pessoal, que oferece entretenimento e informação.
O smartphone é um telemóvel que oferece capacidades avançadas, com funcionalidades de um computador pessoal (Santhipriya e Sastry 2011).
O smartphone está a alterar as possibilidades e os aspetos práticos de muitos componentes da vida quotidiana. Está a mudar a natureza da comunicação, a afetar as identidades e as relações. Tem afetado também o desenvolvimento das estruturas sociais e as atividades económicas e está a ter uma influência considerável na perceção que os utilizadores têm sobre si próprios e do mundo (Moura 2009).
A sua introdução permitiu o surgimento de um novo elemento: a tecnologia tátil. Antes ligada apenas a recursos de acessibilidade para deficientes visuais, torna-se elemento estorna-sencial para interação em aplicações instaladas nestorna-ses dispositivos móveis. Outros elementos também passaram a permitir a interação com dados, tais
13
como acelerômetro, giroscópio, sensores de luz e proximidade, possibilitando a criação de novas interfaces em aplicações (Palacios e Cunha 2012).
No campo das aplicações, tem existido alguma discussão associada às dispositivos móveis e a mecanismos que lhes permitam adaptarem-se às alterações do ambiente.
2.3. Interfaces Adaptáveis
As interfaces adaptáveis apresentam-se promissoras na tentativa de superar os problemas atuais de complexidade na HCI (Human-Computer Interaction) (Ito, Ferreira e Sant’anna 2006). O aumento da complexidade das aplicações, leva o utilizador a tratar uma grande quantidade de informações simultaneamente. Para melhorar esta interação é necessário interfaces que sejam capazes de se adaptar as suas necessidades (Pacheco Júnior e Castro 2010).
Um programa é dito adaptável se for capaz de alterar automaticamente seu comportamento de acordo com seu contexto. A adaptação, neste caso, é a capacidade de um algoritmo fornecer diferentes saídas válidas dependendo das características do ambiente onde o dispositivo móvel se encontra (Ito, et al. 2005).
Existem dois fatores fundamentais para o aumento do desenvolvimento destas interfaces adaptáveis. O primeiro é o paradigma da computação móvel que deve ter a capacidade de se adaptar a diversos ambientes e tipos de dispositivos móveis. O segundo é o crescimento da computação autônoma, a qual tem como objetivo o desenvolvimento de sistemas que têm a capacidade de se gerar automaticamente, configurar e proteger retirando das infraestruturas tecnológicas todas as suas potencialidades, com a necessidade de menos administração humana do que a que é atualmente requerida (McKinley, et al. 2004).
14
2.4. Modelos de Interfaces Adaptáveis
Na área de interfaces adaptativas, há diversas discussões que exploram as várias maneiras e mecanismos que permitam a sua adaptação (Martins 1995). Porém, cada uma delas leva em consideração um tipo de abordagem diferente. Abaixo segue alguns exemplos que serviram de base para este estudo.
Um modelo proposto por (Pereira e Escobar 2011), uma framework para a construção de aplicações a partir da linguagem de marcação XML, interpretação e disponibilização do conteúdo em dispositivos móveis, tais como smartphones e tablets, que utiliza a linguagem de marcação para a descrição de aplicações independentes de plataforma.
Outro exemplo da criação de interfaces adaptativas, é o proposto por (Ableson 2010), que descreve uma arquitetura para forms dinâmicos para a recolha de informação do utilizador, a aplicação tem a capacidade gerar todo o seu conteúdo baseando-se em ficheiros XML, propagados por um sistema central.
Muito semelhante ao modelo anterior, (G. C. Ito, et al. 2005), propõem um modelo de criação de interfaces de utilizadores que se adaptem às características de dispositivos móveis e paralelamente retornam dinamicamente elementos da interface de acordo com as características distintas de cada dispositivo.Através deste processo a interface do utilizador poderá adaptar-se em tempo de execução, ao aparelho que solicitar o serviço, considerando a classe de dispositivos, o tipo de plataforma, aspetos de contexto do utilizador entre outros fatores.
Este sistema é baseado na arquitetura Model View Controller e esta dividida em 2 níveis: cliente e servidor. No lado do cliente os utilizadores pode solicitar serviços dos dispositivos móveis, do lado do servidor estão localizados os meta-dados (contem o perfil do utilizador, a descrição da interface e a descrição dos componentes
15
da interface), proxy da interface (contém o controle que recupera os metadados, o perfil do dispositivo e o gerador da interface que é) e a interface.
Este trabalho está limitado no âmbito da plataforma Android. O principal ponto é desenvolver mecanismos de interface adaptativa específicas, onde se consiga atingir qualquer aparelho que a use independente das características do dispositivos.
17
C
APÍTULO
3
Análise do Problema
“Believe you can and you’re halfway there” Theodore Roosevelt
Neste capítulo será apresentada análise de requisitos para a futura integração da aplicação SOSPhone com os Sistemas de Informação dos Serviços de Emergência.
19
3. Análise do Problema
3.1. SOSPhone
Tal como determinado na diretiva europeia 2009/136/EC, todos os serviços de emergência nacionais dos estados membros da EU (European Union) devem ter provisões para atendimento aos cidadãos com deficiências auditivas (Union 2009).
Deste modo, foi criado o primeiro protótipo do serviço SOSPhone, com o objetivo de testar a sua viabilidade junto dos utilizadores, a interação e obter o seu feedback.
Este estudo de viabilidade permitiu-nos concluir que o serviço SOSPhone representa uma boa solução para resolver os problemas de acessibilidade na hora de pedir emergência (Paredes, et al. September 2013).
Esta é pois a oportunidade de alguns países europeus que ainda não apresentam nenhuma solução, entrarem em conformidade com a diretiva, anteriormente referida, e a sua modalidade será um interface SMS, GSM (Global System for Mobile Communications) associado a um protocolo que poderá ser implementado por múltiplas entidades.
3.2. O número europeu de emergência 112
Emergência caracteriza-se por uma situação de grande vulnerabilidade e desproteção, resultante de não estarem asseguradas, as condições mínimas de sobrevivência e que constituam um perigo real, atual ou iminente, para a integridade
20
física, psíquica e emocional do individuo/família, necessitando de intervenção imediata (Instituto da Segurança Social 2012).
Os cidadãos da União Europeia (EU) em situações de emergência têm ao seu dispor o Número Europeu de Emergência, 112, através do qual poderão ser atendidos pelos serviços de socorro.
Durante décadas este número foi usado por iniciativa nacional em alguns países europeus como forma de permitir aos seus cidadãos o contacto com alguns dos seus serviços de emergência. Desde então a União Europeia e países de outras partes do mundo estabeleceram acordos que instituíram o 112 como número único dos serviços de emergência. Na União Europeia esta decisão foi tomada oficialmente em 1991 (Europeia 1991).
A cada chamada de emergência, o tempo é crucial. Estar no lugar certo com os recursos necessários, o mais rápido possível, reduz o sofrimento e permite minimizar perdas.
Dependendo do país, o operador pode tratar diretamente o pedido ou encaminhá-lo para o serviço de emergência competente. É cada vez mais frequente os operadores serem capazes de atender as chamadas feitas para o 112 em mais de uma língua, o que é particularmente útil quando se está no estrangeiro.
Em qualquer caso de emergência o número 112 pode ser ligado através dos telefones das redes fixa e móvel. A chamada é gratuita e está acessível de qualquer ponto do país a qualquer hora do dia.
O Serviço de Emergência é um Serviço Público, gratuito, com funcionamento contínuo e ininterrupto (24 h por dia, 365 dias por ano), para proteção e salvaguarda da segurança dos cidadãos em situação de Emergência.
Os principais tipos de serviços de emergência são:
Polícia;
21
Emergência Médica.
A chamada será atendida por um operador (com uma formação específica) da Central de Emergência ou Public Safety Answering Point (PSAP), que acionam os sistemas médico, polícia e de incêndio, consoante a situação verificada é que enviará os meios de socorro apropriados.
O PSAP tem o objetivo de aprimorar a capacidade e funcionalidade do número 112, opera 24h por dia 7 dias por semana, tem como objetivo principal receber chamadas efetuadas para o 112 e, conforme a emergência, despoletar os serviços de emergência ou, transferir as chamadas para as entidades de emergência públicas ou privadas (Bureau 2012).
O PSAP determina qual é a melhor ação para resolver a situação de emergência. Por exemplo, se uma determinada pessoa está a ter um ataque cardíaco, e é efetuada uma chamada para o 112, a sua chamada vai ser encaminhada, diretamente para o PSAP, onde um operador vai receber a chamada e vai determinar que tipo de serviço vai ter de enviar para socorrer aquela emergência.
A nível europeu existem vários modelos de funcionamento de PSAP, cada país decide que modelo aplicar desde que respeitem as condições impostas como por exemplo localizar a chamada.
Existem vários modelos que representam o funcionamento do PSAP na Europa:
Modelo 1 - “EROs handling emergency calls”;
Modelo 2 - “Filtering stage 1 PSAP and resource dispatching stage 2
PSAPs”;
Modelo 3 - “Data gathering by stage1, resource dispatching by stage 2”;
Modelo 4 - “Data gathering by stage 1 PSAP, resource dispatching by
stage 2 in an integrated control room”;
22
Modelo 6 - “Interconnected PSAPs”.
Algumas das características destes modelos sobrepõem-se, contudo existem diferenças no que toca ao funcionamento interno dos PSAP (Machado e O’Brien 2013). É de realçar que estes modelos serão descritos de modo global destacando as suas características principais.
Neste primeiro modelo as chamadas nacionais de emergência são redirecionadas para o ERO (Emergency Response Organizations). É iniciado uma primeira triagem e consoante a natureza da emergência as chamadas ou informações são encaminhadas para um ERO específico quando assim se justificar sendo depois acionados os meios necessários, como podemos verificar na Figura 2.
FIGURA 2-MODELO 1-EROHANDLING EMERGENCY CALLS
O segundo modelo “Filtering stage 1 PSAP and resource dispatching stage 2 PSAP”, como mostra a Figura 3, divide-se em duas fases, a primeira fase representa uma processo de filtragem de emergência, existe um operador inicial que faz um processo de triagem identificando qual o ERO que deve contactar, posteriormente o
23
processo de ocorrência passa para um ERO especifico e são então despoletados os meios necessários.
FIGURA 3-MODELO 2-FILTERING STAGE 1PSAP AND RESOURCE DISPATCHING STAGE 2PSAP
O modelo “Data gathering by stage1resource dispatching by stage 2”, como referido na Figura 4, também está dividido em dois níveis, a grande diferença passa pelo papel desempenhado pelas organizações independentes. Existe um operador civil que classifica a chamada e passa a mesma para os ERO. Em alguns casos este processo é auxiliado pelo ERO da polícia. O despoletar de meios é feito pelos ERO.
FIGURA 4-MODELO 3-DATA GATHERING BY STAGE 1,RESOURCE DISPATCHING BY STAGE 2
O modelo “Data gathering by stage 1 PSAP, resource dispatching by stage 2 in an integrated control room” também dividido em 2 níveis, contudo a grande diferença
24
para o modelo anterior é que tanto o operador como todos os ERO se encontram na mesma localização, como demonstrado na Figura 5.
FIGURA 5-MODELO 4-DATA GATHERING BY STAGE 1PSAP,RESOURCE DISPATCHING BY STAGE 2 IN AN INTEGRATED CONTROL ROOM
No modelo “ERO independent PSAP”, Figura 5, o operador classifica a emergência e determina, ou não se deve enviar meios. É muitas vezes apoiado pelos especialistas dos ERO.
25
“Interconnected PSAP”, neste modelo existem vários PSAP que podem comunicar entre si. Se um PSAP não estiver disponível, a chamada é encaminhada para outro, exemplificado na Figura 7.
FIGURA 7-MODELO 6-INTERCONNECTED PSAP
Em Portugal o PSAP adotado enquadra-se no modelo europeu, é gerido pelo MAI (Ministério da Administração Interna).
As chamadas para o 112 são recebidas por um operador especializado. Este depois de recolher as informações necessárias segue os protocolos adotados e envia os dados para as autoridades especializadas, de realçar que os serviços de emergência médica recebem não só os dados como também a chamada de voz. No PSAP existe também agentes ERO especializados para auxiliar o operador em situações mais complicadas. O envio de meios para a ocorrência é levado a cabo pelos ERO usando os seus sistemas internos.
26
FIGURA 8-MODELO 7-PSAP USADO EM PORTUGAL
Na Tabela 1 é efetuada uma comparação resumida dos diversos PSAP, existentes na Europa: 1ª Linha de Atendimento 2ª Linha de Atendimento Envio de recursos
Modelo 1 ERO - ERO
Chamadas direcionadas para o ERO especifico
Modelo 2 Chamadas são filtradas por um Operador e depois direcionadas para Operador Civil ERO ERO
o ERO
Modelo 3 Chamadas filtradas e é recolhida informação por um Operador, e Operador Civil ERO ERO depois direcionadas para o ERO especifico
Modelo 4 Funciona como o anterior, contudo o operador e os ERO estão na Operador Civil ERO ERO mesma localização
Modelo 5 Operador Civil - Operador Civil
O Operador Civil envia os meios necessários
Modelo 6 Operador Civil - Operador Civil
Vários PSAP comunicam entre si
27
3.3. Integração Serviços de Emergência
Requisito 1 (R1) - O serviço SOSPhone deve poder ser disponibilizada
gratuitamente e, através de um interface tátil, a aplicação deve solicitar ao utente informação necessária e suficiente para a Tipificação e Caracterização da ocorrência como apresentado na secção 3.4. Para o fazer deve conseguir implementar o protocolo operacional do 112.pt.
O protocolo operacional do 112.pt tem por finalidade estabelecer o enquadramento operacional do pedido de emergência, bem como definir os princípios gerais que orientam a sua utilização e enumerar os procedimentos que concorrem para uma execução operacional eficaz. Nele está contido todo o fluxo de funcionamento de um pedido de emergência e este pode ser definido como o funcionamento lógico de um pedido desta natureza.
O protocolo operacional do 112.pt não será apresentado nem incluído no presente trabalho visto não ser do domínio público. Contudo os exemplos apresentados neste trabalho são baseados no protocolo real.
R2 - A aplicação deve recolher as coordenadas geográficas da localização do contatante devem ser codificadas e enviadas dentro da mensagem SMS de forma a tentar dotar este canal de contacto da mesma qualidade de atendimento e processamento de ocorrência que tem o canal de voz.
R3 - A aplicação precisará de ser ativada antes de disponibilizar as suas
funções ao seu utilizador. Esta ativação deverá servir como primeiro nível de validação dos utilizadores pré-registados e portanto autorizados a usar este canal de comunicação com o 112.pt (Parliament 2011). Segundo (Carlos Martins, 2013), 80% das chamadas efetuadas para o Centro Operacional 112.pt Sul não são de emergência. O objetivo destes requisitos é que situações como estas possam ser
28
evitadas, com a localização e a identificação da chamada, o número de chamadas falsas pode ser reduzida substancialmente.
3.4. Tipificação e Caracterização
O sistema de emergência possibilita a configuração de uma lista de tipificação caracterizada por tipo e subtipo. Esta lista é parametrizável na aplicação de gestão do sistema. Durante o atendimento do contacto, será necessário criar um registo de ocorrência que a caracterize. Deste modo, a par da recolha de informação sobre o contacto, o Sistema 112 deverá permitir a recolha dos dados relevantes sobre a ocorrência.
Os atributos deste registo de ocorrência deverão permitir a sua caracterização, entre outros, identificador único, a sua localização, tipificação, consequências, contactos associados, estado, entidades envolvidas no seu socorro, data e hora de abertura e de fecho, data e hora do envio para cada uma das entidades envolvidas, estado da atuação individual de cada uma das entidades envolvidas e descrição. Estes atributos deverão ser preenchidos automaticamente pelo Sistema 112 tanto quanto seja tecnicamente possível. Os restantes atributos deverão poder ser preenchidos pelos operadores ou pelos operadores especializados.
Os atributos da ocorrência e os respetivos valores deverão estar em conformidade com os protocolos acordados, ou seja, dependem da tipificação e consequências, requerendo-se uma grande flexibilidade por parte do Sistema 112 para permitir a alteração dos protocolos e o conjunto de atributos das ocorrências.
29
C
APÍTULO
4
Avaliação de Técnicas para a Criação de
Interfaces
“Dream as if you’ll live forever. Live as if you’ll die today.” James Dean
Neste capítulo será feita avaliação de técnicas para a criação de interfaces de dispositivos móveis analisar-se-á os desafios associados a sua criação e apresentadas as soluções escolhidas para os resolver no nosso projeto.
31
4. Avaliação de Técnicas para a Criação de
Interfaces
4.1. Enquadramento
No presente capítulo pretende-se apresentar a avaliação de técnicas para a criação de interfaces, nomeadamente a sua implementação através de layouts.
Um layout (Android Developers 2011) define a estrutura visual para a interface do utilizador, existem duas maneiras de declarar um interface:
Declarar elementos da UI (User Interface) em XML.
Instanciar elementos de layout em tempo de execução.
De maneira avaliar a perceção do utilizador a cerca das diversas formas de criação de interfaces para dispositivos móveis foi desenvolvido um conjunto de testes a ser realizados a diversos utilizadores. Deste modo, neste capítulo vai ser descrito o método de avaliação dos utilizadores acerca da utilização de técnicas para a criação de interfaces em dispositivos móveis, resultados dos testes e respetiva análise.
4.2. Ambiente de Testes
Para testar os diversos tipos de tecnologia de criação de interfaces foi criado um questionário apresentado no Anexo 1.
Foi implementada uma aplicação móvel que contém três tipos diferentes de interface num dispositivo móvel:
Interface Dinâmica – os componentes são instanciados em tempo de execução;
32
Interface Normal – os componentes são declarados no XML;
Interface Web – os componentes estão definidos em HTML e são carregados em tempo de execução, através de um webview (layout Web);
A aplicação móvel está dividida em cinco tipos diferentes de input controls de uma interface nomeadamente: Button, Checkbox, Radiobutton, Textfield e Imagebutton. Input controls são componentes interativos na interface do utilizador, disponibilizados pelo Android SDK.
Para cada componente vai ser testada o tempo de perceção do utilizador e, simultaneamente o tempo de resposta do dispositivo e posteriormente foram comparados e retiradas conclusões.
Para testar esta aplicação foi usado em todos os testes, o mesmo dispositivo móvel: Samsung Galaxy Nexus (maguro) com Android 4.3 Jelly Bean.
Em primeiro lugar foi feita uma breve explicação ao utilizador de como utilizar a aplicação, tendo sido descrito para que servia e como se interagia com ela Figura 9.
33
O teste contém uma fase inicial onde o utilizador responde a algumas perguntas de caracterização como mostra o Anexo 2.
Ao iniciar a aplicação de testes são apresentados ao utilizador cinco botões cada um representando uma componente diferente (Selecionar componente), como mostra a Figura 10.
FIGURA 10-APLICAÇÃO DE TESTE DE UTILIZAÇÃO DE INTERFACE
Após a escolha de um componente, por exemplo Button, foram apresentados ao utilizador três exemplos diferentes de interfaces. Cada exemplo representa um tipo diferente de interface: dinâmico, normal e web. A ordem destes exemplos é sempre variável, isto significa que as interfaces têm ordem aleatória entre componentes, isto evita que os testes sejam sistemáticos e que a decisão seja influenciável.
O utilizador teve que avaliar cada exemplo cuja sequência de questões é apresentado no Anexo 2, repetindo esta ação para os restantes componentes.
34
4.3. Caracterização da amostra
4.3.1.
Questionário de avaliação de técnicas de criação de
interfaces móveis
Para testar a perceção do utilizador, foi preparado um questionário, com um conjunto de perguntas, em que o utilizador tinha que analisar uma aplicação, no dispositivo móvel, com diferentes tipos de interface e posteriormente registar a sua perceção. Foram efetuados testes a uma população de 66 indivíduos, com idades compreendidas entre 18 e 45 anos.
Das pessoas que fizeram a avaliação, 46 tinham idades compreendidas entre 18 e 25 anos, o que equivale a 70% do total de pessoas que fizeram avaliação. Por sua vez, 14 pessoas tinham idades entre 26 e 39 o que equivale a 21% e 9% dos indivíduos tinham 40 a 45 anos de idades, como mostra a Figura 11.
FIGURA 11-CLASSIFICAÇÃO DOS UTILIZADORES QUANTO À IDADE
Para avaliar a experiência do utilizador com dispositivos móveis foi perguntado a todos os indivíduos que efetuaram o teste se tinham smartphone e qual o sistema operativo que usavam.
35
Como se pode verificar na Tabela 2, 49 indivíduos usam smartphone o que equivale a 74% do total da amostra, enquanto os indivíduos que responderam não têm smartphone, correspondem a 19, equivalendo a 26% do total da amostra.
Tem smartphone:
Não 17
Sim 49
TABELA 2-CLASSIFICAÇÃO DOS UTILIZADORES QUE TÊM SMARTPHONE
Para além da pergunta “Tem smartphone”, também foi perguntado aos utilizadores se o smartphone era o seu telefone principal. De todos os indivíduos, 43 responderam que sim e 23 responderam que não, correspondendo a 65% e 35% da amostra respetivamente.
É o seu telefone principal:
Não 23
Sim 43
TABELA 3-CLASSIFICAÇÃO DOS UTILIZADORES QUE TÊM SMARTPHONE COMO TELEFONE PRINCIPAL
Com base nas escolhas dos indivíduos que têm smartphone, foi-lhes perguntado que tipo de sistema operativo utilizam, foi então gerado o Gráfico da Figura 12 com os resultados obtidos.
36
FIGURA 12-CLASSIFICAÇÃO DOS UTILIZADORES QUANTO AO TIPO DE SMARTPHONE QUE POSSUEM
Dos 49 indivíduos que possuem smartphone, 34 usam o sistema operativo Android o que equivale aproximadamente a 70% da amostra, no caso dos que escolheram Windows Phone, o número de indivíduos é de 11, correspondendo a 22%. No smartphone IPhone, que utiliza o sistema operativo IOS, apenas 3 indivíduos escolheram esta opção, o que equivale a uma percentagem de 6%. Apenas 1 indivíduo, representado 2% da amostra, possui um smartphone diferente dos anteriores.
A Figura 13 estão representados as respostas da pergunta “Há quanto tempo tem smartphone”. 34 11 3 1 0 5 10 15 20 25 30 35 Android Windows Phone IPhone Outros
37
FIGURA 13-CLASSIFICAÇÃO DOS UTILIZADORES QUANTO AO TEMPO QUE TÊM SMARTPHONE
Dezanove dos indivíduos responderam que têm smartphone há 1 ou 2 anos, representando aproximadamente 39% do total da amostra. Em relação aos indivíduos que responderam que têm smartphone há mais de 2 anos, o número é de 16, simbolizando 33% da amostra. No caso dos indivíduos que escolheram entre 2 meses e 1 ano e menos de 2 meses, os valores são de 10 e 4, representando 20% e 8% respetivamente.
Na pergunta “Já usou uma loja de aplicações”, 57 dos indivíduos responderam que sim e 9 responderam que não, representando 86% e 4 %, como mostra a
Tabela 4.
Já usou uma loja de aplicações:
Não 9
Sim 57
TABELA 4–CLASSIFICAÇÃO DOS UTILIZADORES QUE JÁ USOU UMA LOJA DE APLICAÇÕES 19 16 10 4 0 5 10 15 20
Entre 1 ano a 2 anos
Há mais de 2 anos
Entre 2 meses a 1 ano Há menos de 2 meses
38
4.4. Análise de Resultados
Dos testes realizados pelos utilizadores, resultou uma análise à informação obtida, com o objetivo de poder concluir qual das técnicas de criação de interfaces se aplica melhor ao desenvolvimento do protótipo do SOSPhone. A síntese desses resultados é apresentada de seguida.
FIGURA 14-GRÁFICO DA PERCEÇÃO DOS UTILIZADORES NA COMPONENTE BUTTON
O gráfico da Figura 14 representa a perceção do utilizador em relação ao tempo de carregamento de um button. Como podemos verificar a quantidade de utilizadores que respondeu que o tempo de carregamento foi rápido para a interface dinâmica é de 33, enquanto 5 acham que foi lento e 28 que foi normal (estática). Em relação as restantes interfaces os valores não alteram substancialmente verificando-se que não houve alterações significativas. Para a componente button, podemos então concluir que os utilizadores, no que toca a perceção não notaram grandes diferenças entre as três técnicas.
33 34 39 5 9 8 28 22 19 0 5 10 15 20 25 30 35 40 45 dynamic html normal UT IL IZA DO R ES
Button
39
Para a componente checkbox, na interface dinâmica 40 utilizadores acharam que a interface é rápida, 7 acharam que foi lenta e 19 acharam que foi normal. Nas restantes as tendências mantêm-se, considerando que tanto na interface html e normal (estática) consideram que o tempo de carregamento foi rápido, como representado no gráfico da Figura 15. Nota-se que os valores se aproximam da componente button.
FIGURA 15-GRÁFICO DA PERCEÇÃO DOS UTILIZADORES NA COMPONENTE CHECKBOX
No caso da componente Radiobutton, como representado no gráfico da Figura 16, 43 utilizadores acharam que a interface dinâmica foi rápida, enquanto 6 acharam que foi lenta e 17 normal. A tendência mantêm-se para as restantes interfaces.
40 37 36 7 10 9 19 19 21 0 5 10 15 20 25 30 35 40 45 dynamic html normal UT IL IZA DO R ES
Checkbox
40
FIGURA 16-CLASSIFICAÇÃO DA PERCEÇÃO DOS UTILIZADORES NA COMPONENTE RADIOBUTTON
É importante realçar que nesta componente os utilizadores acharam que as interfaces são mais rápidas que as duas antecessoras, embora os valores não sejam muito diferentes, nota-se que esta componente foi considerada mais rápida.
O gráfico da Figura 17 representa a perceção do utilizador em relação ao tempo de carregamento da componente Textfield aproxima-se bastante da tendência das componentes anteriores. Para a interface dinâmica 38 dos utilizadores acharam que foi rápida, 6 lenta e 22 normal (estática).
FIGURA 17-GRÁFICO DA PERCEÇÃO DOS UTILIZADORES NA COMPONENTE TEXTFIELD 43 40 41 6 8 6 17 18 19 0 5 10 15 20 25 30 35 40 45 50 dynamic html normal UT IL IZA DO R ES
Radiobutton
Rápida Lenta Normal
38 35 41 6 7 6 22 24 19 0 5 10 15 20 25 30 35 40 45 dynamic html normal UT IL IZA DO R ES
Textfield
41
Na última componente Imagebutton, os utilizadores também consideraram as interfaces rápidas, nomeadamente no caso da interface dinâmica, 42 utilizadores acharam que a interface era rápida, 11 acharam lenta e 13 normal (estática), representado na Figura 18.
FIGURA 18-GRÁFICO DA PERCEÇÃO DOS UTILIZADORES NA COMPONENTE IMAGEBUTTON
Embora a maioria dos utilizadores acharem que as interfaces desta componente em geral é rápida existem uma pequena diferença em relação as componentes anteriores, especificamente a distribuição da perceção lenta e normal nas diversas interfaces. Enquanto nas componentes anteriores existe uma clara diferença entre a lenta e o normal no caso da componente Imagebutton esta diferença diminui substancialmente.
De um modo global podemos concluir que a perceção dos utilizadores no que toca ao tempo de carregamento dos diversos componentes, nomeadamente button, checkbox, radiobutton, Textfield e Imagebutton é rápida, isto significa que a maioria dos utilizadores que efetuaram o teste não nota diferenças entre as diversas técnicas de criação interfaces dinâmica, html ou normal (estática). Após análise e reflexão sobre todos os dados e respetivos resultados, podemos concluir que as diversas técnicas de criação de interface não interferem na perceção do utilizador.
42 43 45 11 9 5 13 14 16 0 5 10 15 20 25 30 35 40 45 50 dynamic html normal UT IL IZA DO R ES
Imagebutton
43
C
APÍTULO
5
Implementação do Serviço SOSPhone
“Hope is a waking dream.” Aristotle
Neste capítulo será apresentada a arquitetura do serviço, sendo especificado todos os requisitos, modelos de dados, modelos conceptuais de arquitetura deste sistema.
45
5. Implementação do Serviço SOSPhone
5.1. Enquadramento
No presente capítulo pretende-se apresentar com detalhe todo o processo de implementação do serviço SOSPhone. Iremos iniciar esta secção por apresentar a arquitetura de implementação.
Será apresentada a metodologia utilizada, seguindo-se a descrição da sua aplicação, a discussão dos resultados obtidos, e concluindo, a definição de uma estrutura de dados de suporte à definição do fluxo da aplicação móvel de acesso universal do serviço.
Por fim iremos apresentar algumas conclusões sobre o processo de implementação.
5.2. Especificação do modelo de dados
A matriz de protocolos do 112.pt define um conjunto de regras que permitem caracterizar rapidamente as ocorrências, assegurando que as entidades correspondentes sejam ativadas em períodos temporais adequados à normal qualidade do serviço prestado pelo PSAP. Esta matriz de protocolos rege o software do operador de 1ª linha no atendimento inicial do contacto do cidadão, solicitando um conjunto de informação que permite ao sistema caracterizar e encaminhar a ocorrência. Complementarmente, a matriz de protocolos associa a cada ocorrência as entidades que deverão ser envolvidas de acordo com parâmetros pré-acordados pelas entidades e pré-estabelecidos.
O modelo da matriz de protocolos segue uma estrutura em árvore, com raiz na natureza da ocorrência.
46
A matriz de protocolos do 112.pt permite a compreensão do processo associado ao atendimento de 1ª linha do PSAP, e a criação de uma estrutura que possa comportar o fluxo do processo em ambiente móvel de acesso universal.
A estrutura de dada desenvolvida tem como base a representação da informação em XML (eXtensible Markup Language).
Seguindo o princípio da matriz de protocolos, para cada situação existe uma tipificação e caracterização.
Ao nível da tipificação existem vários níveis, correspondendo a um determinado tipo um conjunto de subtipos e assim consequentemente, segundo a árvore de tipificação. Esta árvore, atualmente com 3 níveis, deverá ser dinâmica, suportando qualquer profundidade. Desta forma, são definidos genericamente conjuntos de tipos correspondendo, e transições entre um tipo e um conjunto de tipos, permitindo deste modo representar a informação constante na matriz de protocolos.
A caracterização de uma ocorrência segue um fluxo de conjuntos de informação dependentes do tipo da ocorrência. Neste sentido, associadas à caracterização da situação, são definidas características, segundo o especificado para a informação a recolher (informação a registar, prioridade, obrigatoriedade, macro tipo e microtipo). As características são agrupadas em conjuntos de características que por sua vez se interrelacionam entre si e com a tipificação da ocorrência através de transições.
A especificação do documento XML em formado XML Schema é apresentada no Anexo 3 e 4.
Este documento XML serve portanto de ficheiro de configuração para o funcionamento da aplicação móvel. Este protocolo operacional é despoletado pelo BackOffice do Sistema de Gestão Operacional do 112 e é disponibilizado no formato adequado para atualização da aplicação cliente, como mostra a Figura 19.
47
FIGURA 19-ESTRUTURA DE FUNCIONAMENTO E CRIAÇÃO FICHEIRO DE CONFIGURAÇÃO
Como referido anteriormente o serviço SOSPhone necessita de um ficheiro de configuração que representa o fluxo de funcionamento da aplicação. A aplicação tem a capacidade de, em tempo real, gerar toda a sua estrutura e funcionamento.
Este ficheiro de configuração pode variar de pais para pais, contudo o serviço cria uma camada de abstração devido a capacidade de criar o seu conteúdo em tempo de funcionamento.
As vantagens desta abordagem são ao nível das atualizações constante da aplicação, o simples fato de alterar o ficheiro permite uma atualização da aplicação.
Contudo o serviço necessita de outro ficheiro XML, para gerar a sua interface, nomeadamente todo o design da aplicação. A principal diferença entre os dois é que o ficheiro XML de configuração apenas contêm o fluxo de funcionamento, não tem associado nenhum tipo de design.
48
Como mostra a Figura 20, o serviço SOSPhone necessita de 2 ficheiros, um de configuração e outro de design para gerar a interface.
FIGURA 20-ESTRUTURA DE FUNCIONAMENTO E CRIAÇÃO FICHEIRO DE CONFIGURAÇÃO E DESIGN
5.3. Desenvolvimento do protótipo
5.3.1.
Especificação dos Requisitos
Tendo em consideração o conhecimento adquirido com a análise ao funcionamento do 112.pt, apresentado ao longo da secção 5.1, bem como a concretização dos objetivos primordiais definidos e já referenciados previamente e a análise realizada no capítulo 4 obtiveram-se então os seguintes requisitos:
Esta aplicação deve poder ser disponibilizada gratuitamente e deve poder ser executada numa plataforma Android.
49
Através de um interface tátil, a aplicação deve solicitar ao utilizador informação necessária e suficiente para a Tipificação e Caracterização da ocorrência. Para o fazer deve implementar o protocolo operacional que é despoletado pelos Centros Operacionais 112.pt.
Se a informação estiver disponível no smartphone do utilizador, as coordenadas geográficas da localização do contatante devem ser codificadas e enviadas dentro da mensagem SMS de forma a tentar dotar este canal de contacto da mesma qualidade de atendimento e processamento de ocorrência que tem o canal de voz.
A aplicação tem de ser atualizável de forma gratuita e fácil pelo utente. Tomando como exemplo a plataforma Android, a aplicação deve ser disponibilizada no Android Market.
A aplicação precisará de ser ativada antes de disponibilizar as suas funções ao seu utilizador. Esta ativação deverá servir como primeiro nível de validação dos utilizadores pré-registados e portanto autorizados a usar este canal de comunicação com o 112.pt;
O workflow de funcionamento da aplicação deverá ser baseado num ficheiros de configuração que representa o fluxo de funcionamento e design;
5.3.2.
Arquitetura
A arquitetura global do serviço, ilustrada na Figura 21, divide-se em duas camadas principais, XML Parser e um motor que gera a interface (Dynamic UI).
50
FIGURA 21-ARQUITETURA GLOBAL DO SERVIÇO SOSPHONE
A camada XML Parser tem como principal função ler os ficheiros de configuração que são despoletados pelos diversos Sistemas de Gestão. Esta camada tem a capacidade de abrir ficheiros, ler e selecionar a informação pertinente para a criação da interface. Divide-se em duas classes principais, um para o ficheiro de configuração e outra para o ficheiro de design.
A camada Dynamic UI é a camada principal da aplicação. Esta camada recebe toda a informação lida e selecionada na camada anterior e de um modo global permite criar a interface em função da informação recebida.
51
5.3.2.1. Implementação
A aplicação foi desenvolvida na plataforma móvel Android, usando como plataforma de desenvolvimento o Eclipse IDE (Integrated Development Environment), recorrendo ao ADT (Android Development Tools) plugin, que serve de suporte e integração do Android SDK (Software Development Kit) no Eclipse IDE. A aplicação foi desenvolvida recorrendo a versão 4.2.2 (API (Application Programming Interface) 17) do sistema operativo Android. No que toca à linguagem de programação foi usado o Java.
5.3.2.2. Diagrama de Classes
Nesta secção será apresentada uma descrição sobre a estrutura e relação entre classes integrantes da aplicação. Na Figura 22 é apresentado o diagrama de classes da aplicação SOSPhone.
52
FIGURA 22-DIAGRAMA DE CLASSES DO SERVIÇO SOSPHONE
Como podemos verificar são necessárias 6 classes para que a aplicação possa funcionar.
Classes XMLParser
XMLParserEntryConf é a classe responsável pela leitura e seleção do ficheiro de configuração principal da aplicação. Esta classe contem método de leitura de todas as entradas de tipificação, caracterização e transições do ficheiro de configuração.
53
A classe XMLParserEntryDesign tem o mesmo objetivo da classe anterior, contudo o ficheiro de leitura é diferente. Esta é a classe responsável de ler os dados do ficheiro de design.
Classes Model
A classe tipoSet tem como objetivo armazenar os dados referentes a tipificação da ocorrência.
A classe caracterizacaoSet serve para guardar os dados referentes a característica da ocorrência.
A classe transicaoSet esta classe guarda todas as transições entre Views da aplicação.
A classe entryDesign tem a função de guardar dados relativos ao design da aplicação.
Classe Principal
A classe DynamicUI é a classe mais importante da aplicação pois é ela que cria toda sua interface. Recebe os dados vindos das classes model e em tempo de funcionamento cria a interface ao utilizador.
Esta classe tem a capacidade de interpretar os dados recolhidos nas classes de dados e criar toda a lógica de funcionamento do serviço SOSPhone, aplicando o design respetivo.
5.4. Avaliação do Protótipo
De forma avaliar o protótipo final do SOSPhone, foi desenvolvido um conjunto de testes que visam registar o tempo de resposta do carregamento de duas interfaces distintas. Assim, neste subcapítulo será descrito o método de avaliação utilizado e os
