-
Estrada Segura - AAF Aplicação Android e Alertas no Facebook
Luis Manuel Pinto da Costa
Licenciado em Engenharia Informática
Orientadores
Professor Doutor Nuno Filipe Alves Gaiola Castela
Dissertação apresentado à Escola Superior de Tecnologia do
Instituto Politécnico de Castelo Branco
para cumprimento dos requisitos necessários à obtenção do grau
de Mestre em Desenvolvimento de
Software e Sistemas Interativos, realizada sob a orientação
científica do Professor Doutor Nuno Filipe
Alves Gaiola Castela, do Instituto Politécnico de Castelo
Branco.
Abril 2015
-
II
-
III
-
IV
-
V
Composição do júri
Presidente do júri
Doutor Alexandre José Pereira Duro da Fonte,
Professor Adjunto da UTC de Informática da Escola Superior de
Tecnologia do
Instituto Politécnico de Castelo Branco.
Vogais
Doutor Nuno Manuel Garcia dos Santos,
Professor Auxiliar da Universidade da Beira Interior.
Doutora Mónica Isabel Teixeira da Costa,
Professor Adjunto da UTC de Informática da Escola Superior de
Tecnologia de
Castelo Branco, do Instituto Politécnico de Castelo Branco.
Doutor Nuno Filipe Alves Gaiola Castela,
Professor Adjunto da UTC de Informática da Escola Superior de
Tecnologia de
Castelo Branco, do Instituto Politécnico de Castelo Branco
(Orientador).
-
VI
-
VII
Dedicatória
Filipa Peleja, família e amigos.
-
VIII
-
IX
Agradecimentos
Agradeço ao meu orientador, Nuno Castela, pela disponibilidade,
orientação,
ajuda, crítica e principalmente pelo encorajamento quando o
tempo restante era
escasso para concluir esta etapa.
Agradeço a todos os meus colegas que, de alguma forma,
colaboraram e me
ajudaram no desenvolvimento deste trabalho, em especial ao Bruno
Ramos, Marco
Ferreira e Bruno Madaleno.
Agradeço aos meus amigos por todo o apoio, ajuda, sugestões e
testes à
aplicação. Um agradecimento especial ao Élio Cariano pela ajuda
na gestão dos
grupos do Facebook.
Um agradecimento especial para os meus pais e irmã por todo o
carinho, ânimo,
incentivo e por estarem sempre presentes.
O agradecimento mais importante é para a minha namorada, Filipa
Peleja, que
sempre me apoiou e ajudou ao longo desta caminhada. É graças a
ela que hoje estou
a atravessar a meta e a concluir com sucesso esta etapa.
A todos um Muito Obrigado!
Luis Costa
-
X
-
XI
Resumo
A popularidade dos dispositivos móveis tem vindo a crescer a um
ritmo muito
elevado. Em particular a possibilidade de localizar o
dispositivo móvel trouxe uma
mais-valia para uma variedade muito grande de diferentes
aplicações. O valor de
poder obter a localização marcou o futuro da nova geração de
telemóveis. Serviços
de localização podem ser utilizados para melhorar a informação
de tráfego, onde
poderá superar a informação obtida por sistemas tradicionais. O
objetivo desta
dissertação é disponibilizar um trabalho de investigação que
examina uma solução
em como detetar perigos na via pública.
O primeiro problema que é investigado é a identificação da
posição do
dispositivo móvel. É feito um estudo sobre como calcular a
posição dispositivo em
relação aos perigos próximos. O segundo problema abordado é o da
apresentação
da interface ao utilizador. A experiência do utilizador com a
aplicação é deveras
importante e poderá determinar o sucesso, ou insucesso, de uma
aplicação. Além de
ser uma aplicação que precisa de informar o utilizador de um
perigo na proximidade
sem causar distração. Finalmente, foi feito um estudo sobre a
integração de uma
rede social com a aplicação de forma a atingir um maior impacto
sobre a população.
Os resultados da utilização da aplicação mostraram um maior pico
quando foi
realizada a integração com a rede social Facebook.
Palavras chave
Android, smartphone, padrões de sincronização, segurança.
-
XII
-
XIII
Abstract
Mobile phones popularity has been increasing at a very fast
rate. In particular,
the possibility of tracking a mobile device has surged as a
valuable asset for a large
number of applications. The diversity of advantages from using
tracking
information as set a milestone on the future generation of
mobile phones. Tracking
services can be used to improve traffic information in which
they may overpower
traditional systems. The objective of the present thesis is to
research a solution on
how to detect dangers on public areas, more specifically
roads.
The first problem investigated is how to use the information of
the position of
the mobile phone. The investigation starts with a comprehensive
study in how to
measure the most correct distance between the mobile device and
the nearby
dangers. A second problem is how to present the interface to the
user. The user
experience with the application is highly important and may be
determinant for the
success, or failure, of the application. Besides it is important
to keep in mind that it
is an application that must inform about nearby danger without
distracting the
driver. Moreover, it was performed a study on the impact of
integrating a social
network module in the application. It has been observed a higher
usage as a result
of adding this module.
Keywords
Android, smartphone, synchronization patterns, safety.
-
XIV
-
XV
Índice geral
Introdução
........................................................................................................................................
1
1.1. Contexto e motivação
...............................................................................................
1
1.2. Objetivo
..........................................................................................................................
2
1.3. Formalização do problema
.....................................................................................
3
1.4. Organização do
documento....................................................................................
5
2. Estado de Arte
......................................................................................................................
7
2.1. Padrões para sincronização de dados
................................................................
8
2.2. Armazenamento de dados e padrões disponíveis.
..................................... 11
2.3. Tráfego em dispositivos móveis
........................................................................
14
3. Metodologia da Investigação
.......................................................................................
17
3.1. Questões éticas
.........................................................................................................
18
4. Arquitetura
.........................................................................................................................
21
4.1. Arquitetura Cliente-Servidor
..............................................................................
21
4.2. Arquitetura de 3-Tier
............................................................................................
22
4.3. Esquema geral
..........................................................................................................
23
4.4. Tecnologias usados na aplicação
......................................................................
25
5. Modelação da Aplicação
................................................................................................
29
5.1. Processo de modelação
.........................................................................................
29
5.2. Análise de requisitos
..............................................................................................
32
5.2.1. Requisitos funcionais
....................................................................................
32
5.2.2. Funcionalidade de um Sistema Estrada Segura em Portugal
........ 32
5.2.3. Recolha de informação
.................................................................................
32
5.2.4. Integração com redes sociais – Facebook
............................................. 33
5.3. Casos de uso
..............................................................................................................
34
5.4. Diagrama entidade relacionamentos
..............................................................
40
5.5. Descrição de tabelas
..............................................................................................
43
6. Estrada Segura
..................................................................................................................
49
6.1. Distância entre marcos
.........................................................................................
49
-
XVI
6.2. Cálculo do distrito
...................................................................................................
52
6.3. Estrada Segura na loja play (Google)
...............................................................
56
7. Usabilidade da Interface
................................................................................................
59
8. Conclusão
............................................................................................................................
67
8.1. Trabalho Futuro
.......................................................................................................
68
Referências Bibliográficas
.......................................................................................................
69
-
XVII
Índice de figuras
Figura 1 – Sincronização de dados assíncrona.
................................................................
9
Figura 2 - Sincronização de dados síncrona.
..................................................................
11
Figura 3 - Armazenamento parcial.
....................................................................................
12
Figura 4 - Armazenamento total.
........................................................................................
14
Figura 5 - Aplicação móvel para informação de tráfego.
........................................... 15
Figura 6 - Processo de Investigação - Método Cientifico
(hipótese-dedução) .. 18
Figura 7 - Arquitetura Cliente-Servidor.
..........................................................................
21
Figura 8 - Arquitetura de 3-Tier.
.........................................................................................
23
Figura 9 - Arquitetura do sistema em 3 camadas.
........................................................ 23
Figura 10 - Arquitetura do sistema com representação das camadas
e
subcamadas.
........................................................................................................................................
24
Figura 11 - Arquitetura da Aplicação Móvel.
..................................................................
24
Figura 12 - Modelo Castata (Waterfall model)
...............................................................
30
Figura 13 - Modelo Incremental.
.........................................................................................
31
Figura 14 - Casos de uso da aplicação “Estrada
Segura”............................................ 35
Figura 15 - Modelo ER
servidor...........................................................................................
41
Figura 16 - Modelo ER integração com o
Facebook.....................................................
42
Figura 17 - Modelo ER completo após integração com o Facebook.
..................... 42
Figura 18 - Modelo ER dispositivos móveis.
...................................................................
43
Figura 19 - Raio de sincronização de dados
...................................................................
50
Figura 20 - Aplicação móvel com um acidente dentro do raio de
alertas ........... 51
Figura 21 - Carta Administrativa Oficial de Portugal - CAOP
................................... 53
Figura 22 - Botão para o grupo do Facebook correspondente ao
distrito da
minha localização.
.............................................................................................................................
54
Figura 23 - Evolução da aplicação desde Outubro 2013 a 1 Janeiro
de 2014. .. 57
Figura 24 - Integração da rede social Facebook na aplicação (3
Dezembro 2014).
..................................................................................................................................................................
57
Figura 25 - Descarregamentos da aplicação Estrada Segura na loja
play desde
Outubro de 2013 a Fevereiro 2015.
...........................................................................................
57
-
XVIII
Figura 26 - Interface da aplicação no estudo de usabilidade.
.................................. 66
Figura 27 - Interface da aplicação após estudo de usabilidade
............................... 66
-
XIX
Lista de tabelas
Tabela I - Caso de Uso – Adicionar Marco.
......................................................................
36
Tabela II - Caso de Uso – Confirmar Marco.
....................................................................
37
Tabela III - Caso de Uso – Remover
Marco......................................................................
37
Tabela IV - Caso de Uso – Sincronizar Aplicação.
......................................................... 38
Tabela V - Caso de Uso – Editar Preferências.
................................................................
38
Tabela VI - Caso de Uso – Consultar Publicações Facebook.
.................................... 39
Tabela VII - Caso de Uso – Publica no Facebook.
.......................................................... 39
Tabela VIII - Dispositivo Móvel.
..........................................................................................
44
Tabela IX - MARKER_TYPE.
...................................................................................................
45
Tabela X - MARKER_CONFIRMATION.
..............................................................................
45
Tabela XI - MARKER (Server).
.............................................................................................
46
Tabela XII - DISTRICT (Server).
..........................................................................................
46
Tabela XIII - CITY (Server).
...................................................................................................
47
Tabela XIV - MARKER (Dispositivo móvel).
..................................................................
47
Tabela XIV - Número de utilizadores por distrito no Facebook.
............................ 52
Tabela XV - Descrição dos participantes.
.........................................................................
61
Tabela XVI - Questionário sobre a aplicação Estradas Segura. As
respostas são
avaliadas numa escala de Likert de 1 a 5, onde 1 – Não Concordo
e 5 – Concordo. A
média corresponde à média aritmética e desvio padrão é uma
medida estatística que
identifica a variação em relação à média.
................................................................................
64
Tabela XVII - Interface da aplicação – novas funcionalidades.
............................... 65
-
XX
-
Estrada Segura - AAF
Aplicação Android e Alertas no Facebook
1
Introdução 1.1. Contexto e motivação
O problema de congestionamento de tráfego automóvel na via
pública é um
problema universal que apresenta um impacto muito elevado a
nível pessoal,
trabalho e segurança. Os atrasos e a inconveniência causada
devido ao
congestionamento das vias reduz a qualidade de vida das pessoas
que têm de
esperar, provocando perda de dinheiro para várias empresas e
dificultando a
rapidez de resposta dos pedidos de emergência. Portanto, se
fosse possível
atempadamente alertar a população que existe um problema na via
e, e
consequentemente, avisar que deverão utilizar caminhos
alternativos terá um
resultado muito positivo na vida de muitas pessoas. Uma forma de
resolver este
problema seria fornecer aos automobilistas informação em tempo
real de forma a
permitir uma resposta rápida e informada. Por vezes recebemos
este tipo de
informação através da rádio.
Recentemente a empresa Garmin1 apresentou um produto com o
seguinte slogan
“Don’t Hate Traffic – Avoid it”. O produto utiliza tecnologias
como DAB Radio,
Smartphone Link e FM radio2 para informar o automobilista da
proximidade com
uma via congestionada. Portanto resolver o problema de
congestionamento de
tráfego é um problema que chamou a atenção tanto da academia
como da indústria.
Relativamente a este produto da Garmin, foram identificadas duas
limitações: para
usufruir da tecnologia o utilizador terá de adquirir um
dispositivo. Logo exige que
seja feito um investimento monetário sobre algo que o utilizador
ainda não tem
conhecimento da sua mais-valia, e além disso, esta abordagem
prossupõe que a via
se encontre bastante congestionada para avisar o automobilista,
pelo que não pode
ser considerada uma abordagem preventiva. Quando existe um
problema na via
pública o automobilista poderá evitar a via ou ficar mais atento
– o que não significa
necessariamente que o trânsito já se encontre congestionado.
No entanto, nos dias de hoje observa-se um aumento de interação
com interfaces
tangíveis (Preece, Rogers, & Sharp, 2002), em particular,
com dispositivos móveis.
O número de pessoas que adquiriram um dispositivo móvel em
comparação com o
número de automobilistas que adquiram um dispositivo como o da
Garmin é muito
mais elevado. E, por isso, apesar dos dispositivos da Garmin
apresentarem esta
funcionalidade, ainda não previnem um número de pessoas muito
elevado. O
potencial dos dispositivos móveis tem vindo a crescer ao longo
dos anos,
principalmente com o aparecimento dos smartphones. Este
possibilitaram a
1 http://garmin.com/.
2 http://www.garmin.com/en-GB/traffic/.
http://garmin.com/http://www.garmin.com/en-GB/traffic/
-
Luis Manuel Pinto da Costa
2
implementação de uma variedade de diferentes aplicações e,
consequentemente, a
sua popularidade possibilitou o aparecimento de lojas que vendem
aplicações
apenas para este tipo de dispositivos (e.g. itunes da Apple)
(Sherman, 2014). Por a
presença dos dispositivos móveis ser constante existem muitos
investigadores a
estudar a ubiquidade 3 dos dispositivos móveis (Polatidis &
Georgiadis, 2014;
Zaharakis & Komninos, 2012).
1.2. Objetivo
No contexto da presente dissertação propõe-se desenvolver uma
aplicação
móvel que visa alertar o automobilista de possíveis perigos na
via e,
consequentemente aumentar o seu nível de alerta para que
adotem
comportamentos mais adequados no contexto da circulação
rodoviária.
O trabalho proposto consiste no desenvolvimento de uma aplicação
que tem
como objetivo facilitar uma tarefa humana, mais especificamente,
a condução de
veículos motorizados, melhorando o seu conhecimento acerca do
contexto
rodoviário. A aplicação possui um modelo específico de interação
que minimizará a
aprendizagem da sua utilização. O desafio será conseguir
promover a interação
pessoa-máquina de forma natural e no futuro espera-se que esta
interação se torne
transparente – uma interação que seja baseada no conhecimento do
seu contexto, e
por isso, tem a capacidade alterar comportamentos. E, assim
conseguirá capturar a
atenção de muitos mais utilizadores (Abowd, 1999). Assim, será
possível utilizar
este sistema para influenciar os membros da sociedade a alterar
comportamentos,
com vista a tornar a circulação rodoviária mais segura.
Pretende-se promover um sistema onde se inserem localizações GPS
onde
existem: acidentes, veículos imobilizados, obstáculos na
estrada, estradas
bloqueadas, e outras situações de perigo. A inserção desta
informação irá promover
um comportamento mais atento ao meio envolvente e,
consequentemente, um
maior cuidado na circulação na estrada. Os automobilistas
recebem um alerta se
estiverem dentro de um raio de distância em relação à
localização onde foi
previamente inserido um alerta.
A aplicação não irá impor nenhuma autenticação. Esta decisão
advém da
observação da reação de vários utilizadores nas redes sociais.
Pretende-se satisfazer
dois grupos de pessoas que apresentam uma postura de utilização
muito distinta:
(1) um grupo que promove a sua privacidade, e (2) outro grupo
que gosta de manter
3 Refere-se a ser algo que está muito presente. Ou seja aparece
em quase todo o lado.
-
Estrada Segura - AAF
Aplicação Android e Alertas no Facebook
3
uma reputação na comunidade e, por isso, é possível definir um
nickname para a sua
identificação. A importância da autenticação está implicitamente
associada à
interação da aplicação com a rede social Facebook4. O objetivo
de integrar uma rede
social com a aplicação proposta depreende-se pela necessidade de
promover a
aplicação, ou seja, agilizar a interação entre os utilizadores e
aumentar o número de
pontos de referência, ou alerta, inseridos na aplicação Estrada
Segura. O
desenvolvimento do trabalho proposto prossupõe o uso das
seguintes tecnologias:
Android Google Maps API v25, Spring Framework6, Spring Social7,
PostgreeSQL v9,
SQLite e ORMLite.
1.3. Formalização do problema
A motivação por detrás do trabalho proposto é clara, pois
trata-se de uma
necessidade que tem vindo a ser pensada desde há muito tempo.
Contudo existe um
conjunto de problemas que será necessário abordar antes de
utilizar uma aplicação
como Estrada Segura:
Problemas técnicos: a cobertura da rede é determinante para o
bom funcionamento
da aplicação.
Devido à comunicação com o servidor a aplicação apenas será
elegível para
utilizadores que tenham um pacote de dados ativo.
A questão da privacidade e segurança: utilizadores que não
queiram uma aplicação
a analisar os seus percursos diários.
Inclusão de informação de outras fontes (e.g. Estradas de
Portugal) poderá implicar
custos adicionais.
Também, no desenvolvimento desta dissertação foram abordados
várias
questões:
Desenho da aplicação: Usabilidade e rapidez de comunicação.
O cálculo da proximidade a um marco. E cálculo do distrito a que
o marco pertence.
Garantir a fluidez de comunicação de dados: evitar colisões.
4 Facebook. Disponível em: http://www.facebook.com/.
5 Google Maps Android API v2. Disponível em:
https://developers.google.com/maps/documentation/android/.
6 Spring Framework. Disponível em:
http://projects.spring.io/spring-framework/.
7 Spring Social. Disponível em:
http://projects.spring.io/spring-social/.
-
Luis Manuel Pinto da Costa
4
Evitar envios de pacotes muito grandes devido ao consumo de
dados do pacote do
utilizador.
Evitar realizar um número de comunicações muito elevado com o
dispositivo. Para
reduzir o impacto negativo no tempo de vida da bateria do
telemóvel.
Integração com redes sociais.
O problema que será abordado nesta dissertação pode ser descrito
em três
questões: a primeira questão tem como maior preocupação garantir
a comunicação
de dados (dispositivos móveisservidor) e, em tempo-real,
calcular a proximidade
do automobilista ao marco; a segunda questão tem maior foco no
desenho da
aplicação; e na terceira questão foi feita uma análise do
impacto da inclusão de uma
rede social na aplicação.
Questão 1: “maior preocupação para garantir a comunicação de
dados (dispositivos
móveisservidor) e calcular em tempo real a proximidade de
automobilista”
Objetivo: estudar técnicas que calculam proximidade entre pontos
e encontrar uma
solução.
Objetivo: implementar algoritmos que tenham em atenção que
poderá existir várias
comunicações para o mesmo marco; receber várias comunicações em
simultâneo;
Objetivo: não sobrecarregar o servidor com pedidos se houver a
possibilidade de
utilizar a capacidade de processamento do dispositivo móvel. E
tem a vantagem do
utilizador utilizar menos pacotes de dados.
Questão 2: “maior foco no desenho da aplicação e o impacto que
tem seu sucesso”
Objetivo: minimizar a complexidade da aplicação para evitar
distrair o
automobilista.
Objetivo: determinar qual será a melhor posição e dimensão dos
botões para serem
facilmente utilizados. Portanto exigirem pouca atenção para
analisar a aplicação.
Objetivo: apresentar os marcos e informação associada de forma
clara.
Questão 3: “impacto da inclusão de uma rede social na
aplicação”
Objetivo: garantir a privacidade do utilizador ao integrar uma
rede social na
aplicação.
Objetivo: divulgar os marcos e garantir uma maior adesão por
parte da população.
-
Estrada Segura - AAF
Aplicação Android e Alertas no Facebook
5
1.4. Organização do documento
Para além do presente capitulo, a dissertação de mestrado
encontra-se dividida
da seguinte forma:
No Capítulo 2 faz-se um enquadramento tecnológico, apresentam-se
alguns
dos problemas existentes no desenvolvimento de aplicações
móveis. São
ainda descritos alguns dos patterns existentes para a resolução
destes
problemas.
No Capítulo 3 são apresentadas as metodologias utilizadas
durante todo o
processo. Neste capítulo abordam-se ainda questões éticas que
foram tidas
em conta.
No Capítulo 4 é abordada a arquitetura da aplicação e as
tecnologias utilizadas
para no desenvolvimento da solução.
No Capítulo 5 analisa-se o problema e apresenta-se a modelação
da solução.
É neste capítulo que são descritos os casos de uso e o modelo
relacional da
solução.
No Capítulo 6 é descrita a aplicação, Estrada Segura, bem como
algumas das
características que a diferenciam.
No Capítulo 7 são apresentados os testes feitos à usabilidade da
aplicação e as
melhorias feitas de forma a aumentar a usabilidade da mesma.
No Capítulo 8 apresentam-se as conclusões, tiradas ao logo de
todo o processo
de desenvolvimento, bem como o trabalho futuro.
-
Luis Manuel Pinto da Costa
6
-
Estrada Segura - AAF
Aplicação Android e Alertas no Facebook
7
2. Estado de Arte
Na última década observamos um aumento do uso de dispositivos
que acedem à
Internet (Meeker, Pitz, Fitzgerald, & Ji, 2005). Os
dispositivos podem ser
smartphones ou tablets, e por isso, a necessidade de aplicações
móveis tem vindo a
ganhar relevância (Wang & Ma, 2014). Tecnologias como iOS
(Apple), Android
(Google), Windows Phone (Microsoft) surgiram neste mercado
emergente e
continuam a desenvolver plataformas que visam ser flexíveis com
arquiteturas e
plataformas open-ended (Ribeiro & da Silva, 2012). Com este
objetivo, Apple8 e
Google9 disponibilizaram tutoriais com informação sobre as
melhores práticas para
produzir aplicações para estes dispositivos contudo ainda não
existe consenso
numa coleção de design-patterns ou pattern language para
desenvolvimento de
aplicações móveis (Ohrt & Turau, 2012). Devido a isto surgem
dificuldades em
produzir soluções neste domínio. Nesta secção irei discutir
alguns destes aspetos, a
solução desenvolvida será descrita em maior detalhe no capítulo
5.
Muitas aplicações móveis têm como objetivo transformar-se de
forma portátil
em mapas, dicionários, bibliografias digitais, etc. Por se
tratar de uma tecnologia
muito recente, as alterações são constantes por surgirem
tecnologias que
previamente não estarem disponíveis para este tipo de
dispositivos. Uma questão
muito importante está relacionada com os padrões para
sincronização dos dados. É
uma questão que exige muita atenção pois tem-se de garantir a
consistência dos
dados desde o dispositivo móvel ao servidor que armazena a
informação (e o
inverso também) (Franzago, Muccini, & Malavolta, 2014).
Google Maps é um exemplo de uma aplicação onde é impossível
armazenar todos
os dados no dispositivo (Li & Zhijian, 2010). Por isso é
essencial que sejam
implementadas mecanismos de sincronização para se obter os dados
necessários.
Existem outras aplicações que permitem que os utilizadores
atualizem o seu perfil,
ou que definam estratégias – aplicações relacionadas com a bolsa
de valores – e por
isso é deveras importante que as mesma se encontrem atualizadas
com os dados
mais recentes. Estes exemplos apontam para a necessidade de
haver uma
sincronização de dados como uma coleção de padrões, agrupados de
acordo com os
problemas que têm como objetivo resolver.
8
http://developer.apple.com/library/ios/#documentation/iPhone/Conceptual/
iPhoneOSProgrammingGuide/Introduction/Introduction.html.
9 http://developer.android.com/design/index.html.
-
Luis Manuel Pinto da Costa
8
2.1. Padrões para sincronização de dados
Padrões para sincronização de dados tem como objetivo ajudar na
tarefa de
decidir o momento adequado para sincronizar os dados entre um
dispositivo móvel
e o servidor (sistema remoto). Esta questão representa um
problema comum que
por vezes não é dada a devida importância aquando do desenho da
aplicação móvel.
Portanto, programadores de aplicações móveis devem ter em
consideração um
conjunto de limitações: disponibilidade da rede móvel,
requisitos de atualização de
dados, e a interface da aplicação (UI – user interface) (Alencar
& Cowan, 2011).
Existem dois mecanismos para a sincronização de dados: uploading
e
downloading. Uploading refere-se à transferência de dados da
aplicação móvel para
um servidor; e, downloading à transferência de dados da
aplicação móvel para o
servidor. Em ambos os casos, se a comunicação falhar o
utilizador deverá ter essa
informação diretamente, ou indiretamente. Ou seja, através de
uma notificação ou
um registo que seja processado em separado pela aplicação. Os
mecanismos de
sincronização de dados são frequentemente padrões de
arquiteturas. Um padrão de
uma arquitetura indica uma forma fundamental de desenhar um
diagrama da
estrutura de uma organização para um sistema de software. Para
tal, utiliza um
conjunto de sistemas predefinidos onde é especificado
responsabilidades, regras e
indicações para organizar as relações entre os mesmos
(Buschmann, Meunier,
Rohnert, Sommerlad, & Stal, 1996).
O desafio é conseguir utilizar aplicações móveis e ter um acesso
rápido aos dados
(Giguère, 2001; Hyun & Kim, 1995). A capacidade de resposta
e tempo de espera é
essencial para determinar o quão rápido os dados podem ser
acedidos num
ambiente móvel. Uma aplicação que não seja responsiva ou muito
lenta a dar
feedback é indicativo de uma user experience (UX) de pouca
qualidade. No caso de a
aplicação ter um bom tempo de resposta na obtenção dos dados mas
apresentar um
tempo de espera longo a processar essa informação, o utilizador
irá apresentar
bastante desagrado ao utilizar a aplicação. E por isso, a
importância de assegurar
que a aplicação não fica bloqueada quando a sincronização dos
dados ocorre – este
passo deverá ser transparente ao utilizador.
Tendo em consideração a necessidade de assegurar uma aplicação
com uma boa
usabilidade e capacidade de resposta (Nilsson, 2009). É
necessário obter uma
sincronização de dados assíncrona numa perspetiva de (1)
uploading e (2)
downloading: (1) no workflow da aplicação o próximo estado da
interface ou
funcionalidade da aplicação não pode depender do resultado dos
dados uploaded.
Por exemplo, no caso the uma aplicação que gere dados de
serviços de redes sociais,
a atualização do status pode ser iniciado para um conjunto de
diferentes serviços.
Estas operações de uploading, que ocorrem simultaneamente, devem
permitir que
o utilizador possa continuar a interagir com a aplicação, ou até
mesmo outras
-
Estrada Segura - AAF
Aplicação Android e Alertas no Facebook
9
aplicações, se o dispositivo móvel suportar multi-tasking,
enquanto transfere a
informação para atualizar o status. Logo a aplicação não depende
do resultado das
transferências a decorrer; (2) apesar de ser preferível utilizar
dados que foram
atualizados recentemente, uma aplicação pode utilizar um fração
de dados estáveis
para funcionar. Esta questão depende da natureza dos dados. Por
exemplo, uma
aplicação que gere a informação de uma conferência, e por isso,
sendo transparente
ao utilizador terá de atualizar a informação das horas e
localização com um servidor
e sendo esta informação mais recente. No entanto, dados como
sumários das
apresentações a realizar na conferência e informação mais
estática não necessita de
ser atualizada com a mesma frequência. E, se considerarmos uma
aplicação que
indica menus de restaurantes, que variam com muita pouca
frequência, não fará
sentido piorar a usabilidade do utilizador ao bloquear a
interface com uma
sincronização síncrona (ao contrário de assíncrona, que neste
trabalho defendo ser
a melhor opção) cada vez que a aplicação é aberta. Portanto, o
ideal será realizar
uma atualização (download) assíncrono paralelo à interface do
utilizador.
Para alguns casos onde não existe muita memória disponível a
sincronização
assíncrona poderá não ser a melhor solução. Contudo esta era uma
limitação mas
evidente para versões de telemóveis mais antigas (e.g. primeiras
versões do
Symbian (Aapo, 2008)).
Estado:não-sincronizado
Iniciarsincronização
Evento:Iniciar sincronização
Evento:Iniciar sincronização
assíncrona
Retornarestado usable
Sincronizar
Figura 1 – Sincronização de dados assíncrona.
A sincronização de dados assíncrona é um mecanismo que quando a
aplicação se
encontra no estado usable (Figura 1) o utilizador pode interagir
com a aplicação e o
evento de sincronização pode iniciar. No entanto, invés de
iniciar o evento de
-
Luis Manuel Pinto da Costa
10
sincronização sequencialmente o evento é iniciado
assincronamente, logo retorna
de imitado ao estado usable. Esta ação é possível via trigger,
no sistema Android é
usado o “intent”10 ou no sistema iOS push notification. Para o
mecanismo de
notificação o Android e iOS utilizam “toasts”11 e
“UIAlertViews”12 respectivamente.
Finalmente, para informar que o sistema já acabou a
transferência de dados Android
e iOS utilizam o “intent” ou uma função de retorno (Murphy,
2010; Wenderlich et
al., 2013). O trabalho proposto nesta dissertação utilizou um
sistema assíncrono
para Android. No entanto devido à importância e impacto do
Android e iOS tenho
como objetivo implementar a aplicação para iOS (Goadrich &
Rogers, 2011).
A opção pela comunicação assíncrona deveu-se a dois motivos
principais: A
aplicação continuar disponível aquando da sincronização.
Intuitivamente, a data
mais recente não estará disponível, mas para muitas das
situações o utilizador
poderá interagir com a aplicação enquanto os dados sincronizam.
E no caso dos
dados já se encontrarem atualizados a UX do utilizador não será
degradada devido
de se encontrar à espera da atualização. E, sincronização de
dados de forma
transparente (background). Se o sistema triggers um evento de
sincronização (via
Android “intent" ou iOS “push notification”) enquanto a
aplicação não está em
primeiro plano, a aplicação pode sincronizar e atualizar os
dados. Assim quando o
utilizador retornar à aplicação esta estará atualizada. Contudo
existem questões
importantes a ter e atenção ao utilizar sincronização
assíncrona:
1. Inconsistência de dados por acessos concorrentes à base de
dados.
2. Muitos dados a serem carregados poderão implicar custos
elevados ao utilizador.
3. Quantidade de dados a comunicar na rede poderão congestionar
a rede da
operadora móvel.
A sincronização de dados síncrona faz a gestão dos dados
sincronizados, ou seja,
cada vez que sincroniza os dados a interface do utilizador fica
bloqueada. A
sincronização síncrona é adequada quando existem aplicações que
são dependentes
de base de dados que têm de estar atualizados (real time) e
precisos. Algumas
aplicações móveis podem depender na resposta de uma ação antes
de determinar
qual será a ação seguinte. Portanto, para evitar que a aplicação
avance para um
estado que não é o correto, ao desenvolver a aplicação terá de
se garantir que a
aplicação ficará bloqueada até a sincronização de dados ter
terminado.
10
http://developer.android.com/reference/android/content/Intent.html.
11
http://developer.android.com/guide/topics/ui/notifiers/toasts.html.
12
http://developer.apple.com/library/ios/#DOCUMENTATION/UIKit/Reference/
UIAlertView_Class/UIAlertView/UIAlertView.html.
-
Estrada Segura - AAF
Aplicação Android e Alertas no Facebook
11
Estado:usable
Iniciarsincronização
Evento:Iniciar sincronização
Evento:sincronização
síncrona
Retornarestado usable
Esperar pelo fimdo evento
sincronização
Figura 2 - Sincronização de dados síncrona.
O padrão de sincronização de dados síncrona, como a assíncrona,
é um
mecanismo de sincronização de dados. Quando uma aplicação está
no estado usable
o evento de sincronização pode iniciar (Figura 2). O evento é
iniciado e executado
sequencialmente, ficando a aplicação em espera que a
sincronização do evento
termine. A aplicação apenas retoma ao estado usable quando o
evento sincronização
termina.
A vantagem de utilizar a sincronização síncrona é que a
aplicação poderá ser
gerida muito mais facilmente do que com a comunicação
assíncrona. Uma das
vantagens, em comparação com a sincronização assíncrona, é que
reduz o número
de estados que a aplicação poderá a estar num dado momento. A
desvantagem, como
descrita anteriormente, é que o tempo de espera poderá reduzir
substancialmente
a qualidade da experiência do utilizador (UX) aquando da
utilização da aplicação. No
entanto, existem aplicações como Spotify que é bastante popular
que utiliza este tipo
de sincronização. Neste caso, a aplicação apenas atualiza os
dados do utilizador de
acordo com o pagamento da respetiva conta. Em comunicação
síncrona valida se o
utilizador tem a conta paga e, apenas após confirmar esta
informação faz atualiza os
dados ou alerta que o utilizador expirou o tempo de validade do
pagamento
efetuado.
2.2. Armazenamento de dados e padrões disponíveis.
O armazenamento de dados e os respetivos padrões têm como
objetivo ajudar a
resolver os problemas de determinar qual serão os dados que
devem ser guardados
e os que deverão ficar armazenados sem haver fluxo de
transferência de dados.
Estas questões são importantes quando se desenha a aplicação
móvel e os
servidores que irá interagir. Usualmente as aplicações móveis
têm limitações na
-
Luis Manuel Pinto da Costa
12
velocidade de internet, largura de banda disponível e capacidade
de
armazenamento (Kim, Ryu, & Ramachandran, 2012).
Uma solução é armazenamento parcial (McCormick & Schmidt,
2012). Para tal,
os dados são sincronizados e armazenados apenas com os dados
necessários para
otimizar a largura de banda e o armazenamento de dados
utilizado. A largura de
banda e armazenamento são vitais para o desenho da aplicação
sendo que muitas
aplicações necessitam de ser adaptadas pois originalmente foram
desenhadas para
dispositivos que não são móveis (computadores, servidores, etc.)
e onde os recursos
são muito maiores. Nestas aplicações a otimização da solução era
muitas vezes
obtida por aumentar o uso da largura de banda e aumento da
capacidade de
armazenamento em disco, esta abordagem é impraticável para
aplicações móveis.
Um exemplo de uma aplicação é lojas de venda de livros, onde
seria impraticável a
aplicação ter memória todo o inventário de livros disponíveis.
Portanto é necessário
sincronizar a base de dados com os dados à medida que forem
sendo precisos. Assim
para a aplicação funcionar não é necessário ter armazenado a
base de dados com
toda a informação – uma informação parcial dos dados pode ser
transferida apenas
quando é necessária.
ComponenteAplicacional
Proxy Virtual Acesso ao objeto
Dados que não estãoguardados localmente
método: chamada
método: query
método: pedido ao servidor
método:resposta do servidor
método:devolver o pedido da query
método: retornar
ComponenteAplicacional
Proxy Virtual Acesso ao objeto
Dadosguardados localmente
método: chamada
método: query
método:devolver o pedido da query
método: retornar
Figura 3 - Armazenamento parcial.
-
Estrada Segura - AAF
Aplicação Android e Alertas no Facebook
13
Na Figura 3 é apresentado o diagrama da sincronização para
armazenamento
parcial. Existem duas sequências que mostram como é processado
para ambos os
casos (dados guardados localmente e no servidor) os pedidos de
mais informação.
A primeira sequência refere-se ao caso de os dados não estarem
guardados
localmente e a segunda aos dados guardados localmente. Os dados
são
sincronizados dinâmicamente on-demand por triggers da aplicação
móvel,
tipicamente utilizando o padrão de Virtual Proxy (proxy virtual)
(Gamma, Helm,
Johnson, & Vlissides, 1995). Um proxy virtual é um objecto
com a mesma interface
que o objecto usado pelo sistema que recebe as chamadas aos
métodos, assim
pertmite a inicialização dos campos apenas quando estes são
necessários.
Armazenamento parcial pode ser realizado utilizando o padrões do
proxy virtual e
o acesso ao objecto (Alur, Malks, & Crupi, 2001) que trata
da sincronização a-pedido
dos dados e não é apenas armazenamento local. O proxy virtual
disponibiliza uma
interface onde o objecto pode ser consultado pelas componentes e
queries do acesso
ao objecto (o dados irão preencher os campos do objecto). O
acesso ao objecto é
determina onde os dados estão disponiveis e apenas irá fazer
pedidos ao servidor
quando não estão disponiveis localmente. Este padrão permite
minimizar os dados
armazenados localmente mas também não necessita de utilizar a
largura de banda
para sincronizar com os dados todos. Assim, armazenamento
parcial tem a
vantagem de não utilizar demasiado espaço do dispositivo móvel e
os dados podem
ser sincronizados com diferentes niveis de granularidade:
sincronizar apenas
quando é necessário, é definido que dados e quantidade se
pretende sincronizar. A
desvantagem desta abordagem é que o utilizado para utilizar a
aplicação terá de ter
uma ligação à rede e estará dependente da largura de banda
(velocidade) disponível.
Existem vários exemplos de aplicações que utilizam este tipo de
abordagem. Há
pouco foi mencionado uma aplicação de venda de livros mas também
aplicações
como Google Maps aplicam este tipo de padrões. O Google Maps
apenas faz pedidos
ao servidor para os mapas que são relevantes ao utilizador, e à
medida que se faz
zoom vão sendo feitos pedidos com um maior nível de
granularidade. No caso da
aplicação proposta também foi necessário aplicar este tipo de
padrões e os motivos
foi evitar: (1) sobrecarregar o dispositivo móvel com mapas que
não são do
interesse do utilizador; (2) procurar por alertas que não estão
no raio de distância
do utilizador; (3) gastar largura de banda e bateria do
dispositivo móvel com
atualizações que não estão no raio de distância do
utilizador.
Em seguida será descrito o padrão armazenamento total. A análise
deste padrão
é indicativo do motivo porque não foi seleccionado para o
trabalho proposto.
O armazenamento total sincroniza e guarda todos os dados
necessários à
aplicação – permite um tempo de resposta mais rápido a obter os
dados e a carregar
os dados na aplicação. Este padrão permite resolver problemas de
quando a rede
-
Luis Manuel Pinto da Costa
14
não se encontra disponível ou não é desejável (e.g. roaming). Os
dados (completos)
são sincronizados com o disposito e o servidor num único evento.
É uma abordagem
ideal para aplicações que visam ter informação guardada no
dispositivo no caso de
não haver nenhuma rede disponível.
ComponenteAplicacional
Acesso ao objeto
método: chamada
método: get (obter)
método: pedido ao servidor
método:resposta do servidor
método:devolver o pedido da query
método: retornar
Figura 4 - Armazenamento total.
Na Figura 4 é apresentado o diagrama para o armazenamento total
(McCormick
& Schmidt, 2012). É feita uma distinta separação entre
sincronização (método
chamada) e o método que obtém os dados (get). A sincronização
faz um pedido à
rede e sincroniza com os dados (completos) que são
posteriormente guardados no
dispositivo. Todos os métodos get são feitos localmente no
dispositivo móvel, ou
seja, nunca é feita uma chamada ao servidor.
A vantagem do armazenamento total é o facto de se poder utilizar
a aplicação
mesmo quando não existe rede disponível. As desvantagens são:
utilizar o
armazenamento do dispositivo móvel, que pela natureza do
dispositivo é limitado,
e para aplicações que precisam de dados que são dependentes de
novas atualizações
é impraticável utilizar este tipo de armazenamento (e.g.
aplicação Facebook).
2.3. Tráfego em dispositivos móveis
Na Figura 5 é apresentada uma proposta de uma aplicação para
tráfego urbano.
Este sistema utiliza a posição dos dispositivos móveis para
colecionar dados em
tempo-real, e obter uma estimativa do tráfego existente.
Aplicações como MobiTraS
(Manolopoulos, Tao, Rodriguez, Ismail, & Rusu, 2010)
utilizaram este tipo de
abordagem, em tempo-real: uma aplicação existente no dispositivo
móvel processa
os dados e envia a informação para um sistema central onde são
executados os
algoritmos (i.e. dados de localização, estimar o trafego, etc.).
A localização do
-
Estrada Segura - AAF
Aplicação Android e Alertas no Facebook
15
telemóvel pode ser calculado através das antenas GPS ou com a
informação das
antenas que fornecem sinal ao dispositivo. Naturalmente, este
género de aplicações
exigem que se tenha precaução em relação à privacidade do
utilizador e, por isso,
Manolopoulos et al. utilizaram a arquitetura GBA13 por
autenticação anónima
(Manolopoulos, Papadimitratos, Tao, & Rusu, 2011). Como é
possível verificar nesta
abordagem toda o processamento de dados depende unicamente da
posição do
dispositivo. E por isso não contempla informação adicionar
fornecida pelo
utilizador.
Satelites
Sistema Central
de Trafego
Dispositivos móveis
Com GPS
Figura 5 - Aplicação móvel para informação de tráfego.
13 Do inglês, Generic Bootstrapping Architecture.
-
Luis Manuel Pinto da Costa
16
-
Estrada Segura - AAF
Aplicação Android e Alertas no Facebook
17
3. Metodologia da Investigação
O trabalho de investigação pode ser dividido em duas
metodologias: qualitativa
e quantitativa (Franklin, 2012; Venkatesh, Brown, & Bala,
2013). Se o objetivo for
colecionar (i.e. crawl dados da Web) dados em larga escala será
necessário elaborar
teorias e hipóteses para se validar os mesmos. Usualmente os
resultados da análise
sobre os dados colecionados serão utilizados para criar novas
hipóteses. Portanto
existem estudos que o objetivo principal visa uma análise numa
larga escala. No
outro prisma, existe a metodologia qualitativa onde não existe
uma quantidade de
dados tão elevada mas existe uma maior preocupação a efetuar uma
validação
estatística sobre os dados que se está a trabalhar. É de ter em
mente que estatística
não responde a todas os problemas mas ajuda na compreensão dos
dados. Os dados
obtidos quantitativamente são usualmente obtidos de acordo com
determinadas
regras mas devido à sua quantidade a sua análise é menos
subjetiva que os dados
qualitativos, que muitas vezes são manualmente anotados.
No desenvolvimento do trabalho proposto foi realizada uma tarefa
para avaliar
a usabilidade da aplicação. Esta tarefa enquadra-se no método
qualitativo – foram
selecionadas 10 pessoas e avaliaram diferentes aspetos
(eficácia, eficiência e
satisfação) da aplicação. Porém, o trabalho apresenta uma maior
proximidade ao
método quantitativo. Isto porque o trabalho proposto pode ser
observado com uma
sequência de tarefas: (1) ideia a implementar; (2) elaboração
das várias hipóteses
em como desenvolver a ideia; (3) desenvolvimento e
experimentação com alguns
utilizadores; (4) e, de acordo com a observações do ponto (3)
retoma-se ao ponto
(2) até atingir um ponto onde se identifica que a aplicação
estará pronta para
validação. Portanto, para se realizar uma análise qualitativa do
sistema Estrada
segura, no ponto (4) o sistema teria de ser avaliado por pessoas
que usufruíram de
uma formação para saberem as boas práticas de como utilizar a
aplicação. Ou seja
para esta aplicação, um especialista será alguém que se encontra
confortável com a
tecnologia e que previamente a utilizar a aplicação teve uma
formação – por
exemplo, introdução sobre o que se pretende da aplicação e as
melhores práticas de
como a utilizar. Contudo a aplicação foi testada em larga escala
por pessoas de
diferentes idades, estratos sociais, formação, etc. E, por isso,
não houve qualquer
controlo sobre os indivíduos que descarregaram a aplicação. De
acordo com (Flick,
2005) na investigação quantitativa: “As situações em que os
fenómenos e as relações
estudadas ocorrem são controladas até ao limite do possível, a
fim de determinar com
máximo de clareza as relações casuais e a sua validade. Os
estudos são desenhados de
forma a excluir, na medida do possível, a influência do
investigador” e, o mesmo autor
para a investigação qualitativa afirma que “Ao contrário da
investigação
quantitativa, os métodos qualitativos encaram a interação do
investigador como o
campo e os seus membros como parte explícita da produção do
saber, em lugar de a
excluírem a todo o custo, como variável interveniente. A
subjetividade do investigador
-
Luis Manuel Pinto da Costa
18
e dos sujeitos estudados faz parte do processo de investigação”
No entanto ao
contrário de Flick existem autores (Kelle, 2005) que fundamentam
que não deveria
haver uma separação entre estas duas abordagens. (Cupchik, 2001)
resume esta
questão por considerar que as duas abordagens estão
inter-relacionadas e, por isso,
a abordagem quantitativa contribuí para a identificação de
processos relevantes e,
consequentemente disponibiliza uma investigação pela abordagem
qualitativa.
Teoria
Hipóteses
Operacionalização
Validação
Interpretaçãodos Dados
Recolha de Dados
Amostragem
Observações
Figura 6 - Processo de Investigação - Método Cientifico
(hipótese-dedução)
A organização do processo de investigação pode ser esquematizado
de acordo
com Figura 6. O investigador elege uma teoria e para tal gera
uma, ou mais, hipóteses
que são elaboradas (operacionalização) e testadas (amostragem).
Com base na
interpretação dos dados obtidos o investigador tem duas opções:
observa
consistência nos resultados obtidos e avança para a validação;
ou modifica as
hipóteses e, como tal, retoma à etapa das hipóteses
(Dodig-Crnkovic, 2002).
Na Figura 6 a etapa de validação corresponde ao processo onde
uma medida de
teste é usada para medir os resultados. Existem medidas
quantitativas como:
temporais, avaliações em exames, etc. Para o caso de uma
aplicação com o Sistema
Estrada Segura: número de utilizadores da aplicação ao longo do
tempo; número de
marcos diários; número de likes nos marcos; número de
publicações por dia nos
grupos do Sistema Estrada Segura na rede social Facebook (total
e por distrito) e
finalmente, número de pessoas nos grupos do Facebook.
3.1. Questões éticas
No processo de investigação surgiu a questão de ocultar, ou não,
a informação do
utilizador que inseriu o marco, logo uma questão de privacidade.
Como os
utilizadores se sentem em relação a isso?
Para um bom funcionamento da aplicação não é estritamente
necessário que a
inserção de um marco indique explicitamente aos outros
automobilistas quem
inseriu o marco. E, talvez alguns automobilistas prefiram o
anonimato. No outro
prisma existe a questão da reputação dos utilizadores da
aplicação. Há
-
Estrada Segura - AAF
Aplicação Android e Alertas no Facebook
19
automobilistas que poderão contribuir mais porque gostam de ser
gratificados com
pontos validação dos seus marcos. E, ficando reconhecidos como
automobilistas de
confiança, respetivamente à inserção dos marcos. Neste caso são
utilizadores que
gostariam de ter um nome associado a si.
Devido a ser uma questão ambígua em que seria difícil de chegar
a um consenso,
optou-se por não ser feita uma validação exaustiva. O
automobilista será associado
a um nickname escolhido por si. Esse nome é escolhido pelo
utilizador da aplicação.
Sendo assim não se tem acesso a nenhuma informação sobre a
pessoa inseriu o(s)
marco(s).
Quando surge um novo marco – coordenada GPS no mapa – é inserido
uma
publicação automática no Facebook. A publicação apresenta um
mapa com a
indicação de onde ocorre o alerta e está associada ao comentário
inserido pelo
automobilista que criou o marco. No entanto, esta publicação não
se encontra
associada à conta da rede pessoal do Facebook do automobilista.
As publicações
automáticas são feitas pela aplicação Estrada Segura e, no
respetivo Distrito que o
marco se encontra associado.
-
Luis Manuel Pinto da Costa
20
-
Estrada Segura - AAF
Aplicação Android e Alertas no Facebook
21
4. Arquitetura
Arquitetura de computadores descreve a funcionalidade e a
organização de
como o sistema de computação está organizado. Portanto, de forma
abstrata, define
a capacidade de um computador e a sua organização “interna”.
Arquitetura de
computadores envolve vários aspetos, entre estes, desenhar a
arquitetura, a lógica
do desenho e a sua implementação. E, existem várias formas de
desenhar uma
arquitetura de rede de computadores. Refere-se a arquitetura de
rede de
computadores à forma como os computadores estão organizados num
sistema e
como as diferentes tarefas são alocadas aos mesmos. Duas
arquiteturas mais
populares são a arquitetura ponto-a-ponto (peer-to-peer) e
cliente-servidor (client-
server). A arquitetura cliente-servidor é também denominada por
tiered porque
utiliza várias camadas (Pyke & Blanc, 1973).
4.1. Arquitetura Cliente-Servidor
Nos primórdios da Web a arquitetura cliente-servidor foi a mais
popular (Figura
7). O cliente – página web (browser) – efetua pedidos que são
enviados e tratados
pelo servidor (HTTP). O cliente tem de apenas receber as
respostas e a apresentá-
las ao utilizador. Portanto neste tipo de aplicações o servidor
tem a
responsabilidade do processamento de dados e, por isso, esta
arquitetura é bastante
simples. Atualmente é utilizada por muitos dos conteúdos
existentes.
Server
Client
ClientClient
Client
Figura 7 - Arquitetura Cliente-Servidor.
A vantagem da arquitetura cliente-servidor em relação a
aplicações únicas
(stand-alone) é a de se encontrar centralizada numa única
máquina e, por isso, ser
fácil de gerir. E, em simultâneo estar disponível por um número
vasto de
utilizadores – capacidade de comunicação pelo acesso à Web.
O problema do modelo cliente-servidor reside no facto de não
existir uma
distinção clara entre a lógica de processamento dos pedidos
(conhecida como lógica
de negócio) e o próprio sistema de gestão da informação. Em um
cenário
empresarial onde os sistemas de informação servem vários tipos
de aplicações,
-
Luis Manuel Pinto da Costa
22
inclusivamente aplicações não-Web, a utilização de um sistema
destes força a que
cada aplicação tenha de redundantemente reimplementar a lógica
de negócio. E
assim, a gestão global do sistema poderá tornar-se numa tarefa
extremamente
complexa e, consequentemente, mais sensível à ocorrência de
erros. Portanto, a
arquitetura cliente-servidor constitui uma boa arquitetura para
aplicações baseadas
em páginas estáticas ou mesmo para aquelas que produzem
informação dinâmica
(no servidor) mas que não incorporam demasiado processamento
para a sua
execução.
4.2. Arquitetura de 3-Tier
A arquitetura de 3-Tier surge como forma de ultrapassar as
limitações da
arquitetura cliente-servidor. Nesta arquitetura, existem três
zonas funcionais ou
camadas distintas: a camada de apresentação suportada pelo
cliente, a camada de
lógica de negócio que reside no servidor e a camada de dados que
pode encontrar-
se ou não no mesmo servidor. A camada de apresentação tem
exatamente as
mesmas funções da arquitetura cliente-servidor, isto é, enviar
pedidos e apresentar
as respostas ao utilizador. No entanto, agora no lado do
servidor existe uma divisão
clara entre a lógica de negócio e a base de dados dados (Figura
8).
A função da camada intermédia (lógica de negócio) é a de
proporcionar a
construção dinâmica de informação que será enviada ao cliente.
Esta análise é
realizada sem preocupações de manutenção de integridade dos
dados que agora são
geridos independentemente. Esta separação permite que os mesmos
dados possam
ser facilmente acedidos por outras aplicações – que beneficiam
das restrições de
integridade que possam estar implementadas pela camada de dados.
As aplicações
terão de apresentar uma interface conveniente para esta
comunicação. O mesmo se
aplica à segunda camada, ou seja, agora é possível reaproveitar
a lógica de negócio
implementada desde que esta satisfaça os requisitos de outras
aplicações que não
precisam necessariamente de um interface Web.
Base de Dados
Camada de Acesso a Dados
Camada de Apresentação
Camada de Lógica de Dados
-
Estrada Segura - AAF
Aplicação Android e Alertas no Facebook
23
Figura 8 - Arquitetura de 3-Tier.
A arquitetura de 3-Tier indicia uma clara separação entre
apresentação e
conteúdo porém, na realidade, esta separação não é sempre assim
tão clara. O facto
de o HTML14 ser o resultado do processamento intermédio efetuado
pela camada
intermédia implica que a camada lógica tenha de ter conhecimento
de conceitos
relativos à camada de apresentação – HTML é uma linguagem que
também define a
apresentação. Portanto, a solução passa por basear as respostas
não na sua
apresentação mas sim no seu conteúdo por utilização de uma
linguagem como o
XML. Desta forma, utilizando utilização de folhas de estilo
diferentes, o mesmo tipo
de informação poderia ser visualizado de forma mais apropriada
ao cliente gráfico
utilizado.
4.3. Esquema geral
A arquitetura proposta para o sistema da aplicação Estrada
Segura está dividida
em 3 camadas: camada de apresentação, a camada aplicacional e a
camada de dados
(Figura 9). Na Figura 10 é possível ver que a camada
aplicacional se encontra
subdividida em duas camadas, a camada de lógica de negócio e a
camada de acesso
a dados respetivamente.
O sistema esta dividido em dois módulos, aplicações, sendo eles
a aplicação
móvel e a aplicação servidor. A aplicação móvel esta dividida em
3 camadas, sendo
elas a camada de apresentação, a camada de negócio e acesso a
dados e a camada de
dados (Figura 11).
Camada de ApresentaçãoCamada Aplicacional(Lógica de Negócio)
Camada de Dados(PostgreSQL)
SQLite
SQLite
SQLite
Figura 9 - Arquitetura do sistema em 3 camadas.
14 HTML é o acrónimo para HyperText Markup Language.
-
Luis Manuel Pinto da Costa
24
Lógica de Negócio
Camada de Acesso a Dados
Internet
Camada de Apresentação Webservice
Camada de Base de DadosPostgreSQL
PostgreSQLPostgreSQL
PostgreSQL
Camada Aplicacional
Figura 10 - Arquitetura do sistema com representação das camadas
e subcamadas.
AplicaçãoMóvel
Camadade Acesso a Dados
(ORMLite)
SQLite
Lógica de Negócio
Figura 11 - Arquitetura da Aplicação Móvel.
-
Estrada Segura - AAF
Aplicação Android e Alertas no Facebook
25
4.4. Tecnologias usados na aplicação
A aplicação móvel foi desenvolvida para ser utilizada na
plataforma Android. A
vertente do servidor foi desenvolvida para ser multiplataforma,
isto é, poder ser
instalada tanto em servidores com sistema operativo Windows ou
Unix. No
desenvolvimento de ambas as aplicações foi tido em consideração
se as tecnologias
eram ou não open source. De seguida são apresentadas as
tecnologias utilizadas.
Androidé um sistema operativo (SO) móvel baseado em linux,
desenvolvido pela
empresa de tecnologia Google. Com uma interface com o utilizador
baseada
na manipulação direta, o Android é projetado principalmente para
dispositivos
móveis com ecrãs sensíveis ao toque como smartphones e
tablets.
Android tem como objetivo ser utilizado num ecrã sensível ao
toque, onde o
utilizador pode manipular objetos virtuais (e.g. teclado
virtual). Apesar de ser
principalmente utilizado em dispositivos com tela sensível ao
toque, também é
utilizado em consolas de jogos, camaras, computadores e outros
dispositivos
eletrônicos.
SQLite é uma biblioteca escrita na linguagem C que implementa
uma base de
dados SQL embebida. Programas que utilizam a biblioteca SQLite
têm acesso a uma
base de dados SQL sem executar um processo SGBD15. A biblioteca
SQLite lê e
escreve diretamente para a base de dados em disco.
ORMLite é uma arquitetura open source que fornece um leve
mapeamento objeto-
relacional (ORM) entre as classes Java e uma base de dados SQL.
Suporta base de
dados JDBC16, bem como a plataforma móvel Android. ORMLite
fornece uma camada
que abstrai eficientemente as funções JDBC, evitando a
complexidade de outras
estruturas (e.g. Hibernate ou iBATIS). Esta arquitetura suporta
ligações JDBC para
MySQL, PostgreSQL, Microsoft SQL Server, H2, Derby, HSQLDB e
SQLite. E também
chamadas a bases de dados nativas do sistema operativo
Android.
Google Maps Android API v2 – a Google disponibiliza na sua loja
Google play a
aplicação de mapas do Google (Google Maps) e também uma
biblioteca (API) para
programadores poderem utilizar a mesma. Google Maps
disponibiliza imagens de
satélite; percursos entre localizações: de carro, a pé e
recorrendo a transportes
15 Em português SGBD é o acrónimo de “Sistema de Gestão de Base
de Dados”. O acrónimo em inglês é RDBMS “Relational DataBase
Management System”.
16 JDBC é o acrónimo para “Java DataBase Connectivity”.
http://pt.wikipedia.org/wiki/Linux_(n%C3%BAcleo)http://pt.wikipedia.org/wiki/Googlehttp://pt.wikipedia.org/wiki/Manipula%C3%A7%C3%A3o_diretahttp://pt.wikipedia.org/wiki/Smartphonehttp://pt.wikipedia.org/wiki/Tablethttp://pt.wikipedia.org/wiki/Teclado_virtualhttp://pt.wikipedia.org/wiki/Consoles_de_videogameshttp://pt.wikipedia.org/wiki/Banco_de_dadoshttp://pt.wikipedia.org/wiki/Banco_de_dadoshttp://pt.wikipedia.org/wiki/SQLhttp://pt.wikipedia.org/wiki/SGBDhttp://pt.wikipedia.org/wiki/Disco_r%C3%ADgido
-
Luis Manuel Pinto da Costa
26
públicos; perspetivas das ruas; etc. Uma das vantagens desta
aplicação é a facilidade
de poder ser integrada em outras aplicações ou páginas web.
Neste momento é uma
das aplicações mais populares para aplicações em smartphones.
Num estudo
realizado durante o mês de Agosto de 201317 54% de todos os
utilizadores de
smartphones utilizaram pelo menos uma vez a aplicação de Google
Maps.
JSON é um formato leve para comunicação de dados. Este formato
foi originalmente
criado por Douglas Crockford e é descrito no RFC 462718. O
media-type oficial do
JSON é “application/json” e a sua extensão é .json. Devido à sua
simplicidade JSON é
um muito formato utilizado tanto na academia como na indústria,
apresentando-se
como uma boa alternativa ao XML. Em comparação com o formato XML
JSON
apresenta-se como um formato mais leve, fácil de analisar e
gerar.
Spring Data JPA é uma implementação de uma camada de acesso a
dados em uma
aplicação. Usualmente o acesso a dados é moroso e complicado
exigindo muito
código para executar consultas simples (e.g. paginação e
auditoria). Spring Data JPA
melhora significativamente a camadas de acesso a dados e,
consequentemente,
reduz o esforço na fase de implementação.
As principais características da API Spring Data JPA são:
o Suporte para construir repositórios baseados em Spring e
JPA.
o Auditoria transparente das classes de domínio
o Suporte para paginação, execução de consulta dinâmica,
capacidade de
integrar código personalizado para aceder a dados.
o Mapeamento de entidades através de XML ou anotações.
Hibernate é uma arquitetura ORM19 escrita na linguagem Java.
Também se
encontra disponível para .Net com o nome NHibernate. Esta
arquitetura facilita o
mapeamento dos objetos de domínios (Java Entitiy) com as tabelas
de uma base de
dados. O mapeamento pode ser feito recorrendo a ficheiros (XML)
ou anotações
Java.
17 GlobalWebIndex.
http://www.businessinsider.com/google-smartphone-app-popularity-2013-9#infographic.
18 https://www.ietf.org/rfc/rfc4627.txt.
19 ORM é o acrónimo para “Object-relational mapping”.
http://pt.wikipedia.org/wiki/Douglas_Crockfordhttp://tools.ietf.org/html/rfc4627http://pt.wikipedia.org/wiki/Frameworkhttp://pt.wikipedia.org/wiki/Javahttp://pt.wikipedia.org/wiki/.Nethttp://pt.wikipedia.org/wiki/NHibernatehttp://pt.wikipedia.org/wiki/XMLhttp://www.businessinsider.com/google-smartphone-app-popularity-2013-9#infographichttps://www.ietf.org/rfc/rfc4627.txt
-
Estrada Segura - AAF
Aplicação Android e Alertas no Facebook
27
Spring é uma arquitetura open source para a plataforma Java,
criada por Rod
Johnson (Johnson, 2004). Spring é uma arquitetura baseada nos
padrões de
projeto de inversion of control (IoC) e injeção de dependência.
O container de
Spring é responsável por "instanciar" as classes de uma
aplicação Java e definir as
dependências entre elas.
Spring MVC é uma arquitetura HTTP20 baseada em servlet´s.
Fornece um vasto
numero de extensões para implementar aplicações web e/ou
serviços web RESTful.
REST é um acrónimo para Representational State Transfer.
Trata-se de um estilo de
arquitetura de software onde se aplicam as melhores práticas
para gerar serviços
web escaláveis. REST ganhou popularidade como sendo uma
alternativa mais
simples a SOAP21 e WSDL22-based Web Services.
Tomcat é um servidor web, mais especificamente um servlet
container. Este
servidor foi desenvolvido pela Apache Software Foundation23 e
distribuído como
uma tecnologia open source. Tomcat implementa as tecnologias
Java
Servlet e JavaServer Pages (JSP) no entanto não se trata de um
container EJB24
(servidor aplicacional).
PostgreSQL é um sistema que faz a gestão de base de dados
relacionais.
Originalmente desenhado para plataformas UNIX, contudo suporta
ser utilizado em
Mac os x, Solaris e Windows. É uma tecnologia open source e, por
ser estável,
necessita de pouco esforço de manutenção. Uma das vantagens é
que PostgreSQL foi
um dos primeiros programas que gerem base de dados, a
implementar MVCC
(Multi-Version Concurrency Control). Também permite a adição de
funções feitas à
medida em diferentes linguagens de programação: C/C++, Java,
entre outras.
20 Acrónimo para “Hypertext Transfer Protocol”.
21 Acrónimo para “Simple Object Access protocol”.
22 Acrónimo para “Web Services Description Language”.
23https://www.apache.org/ .
24 Acrónimo para “Enterprise JavaBeans”.
http://pt.wikipedia.org/wiki/Open_sourcehttp://pt.wikipedia.org/wiki/Linguagem_Javahttp://pt.wikipedia.org/w/index.php?title=Rod_Johnson&action=edit&redlink=1http://pt.wikipedia.org/w/index.php?title=Rod_Johnson&action=edit&redlink=1http://pt.wikipedia.org/wiki/Inje%C3%A7%C3%A3o_de_depend%C3%AAnciahttp://pt.wikipedia.org/wiki/Classe_(programa%C3%A7%C3%A3o)http://pt.wikipedia.org/wiki/Java_(linguagem_de_programa%C3%A7%C3%A3o)http://pt.wikipedia.org/wiki/Servidor_webhttp://pt.wikipedia.org/wiki/Container_(programa%C3%A7%C3%A3o)http://pt.wikipedia.org/wiki/Apache_Software_Foundationhttp://pt.wikipedia.org/wiki/Java_Servlethttp://pt.wikipedia.org/wiki/Java_Servlethttp://pt.wikipedia.org/wiki/JavaServer_Pageshttps://www.apache.org/
-
Luis Manuel Pinto da Costa
28
-
Estrada Segura - AAF
Aplicação Android e Alertas no Facebook
29
5. Modelação da Aplicação
Os requisitos necessários são definidos durante a fase inicial
da modelação
do sistema. Estes requisitos descrevem como o sistema deverá
funcionar, o seu
domínio, limitações do sistema e especificações de atributos e
patentes associadas
ao sistema. De acordo com (Böckle, van der Linden, & Pohl,
2005) o processo de
desenvolvimento de um sistema pode ser dividido em quatro
atividades
fundamentais: (1) especificar as funcionalidades e limitações
(ou restrições) do
sistema; (2) desenvolvimento do sistema tendo em atenção as
funcionalidades e
limitações identificadas em (1); (3) testar o sistema a fim de
garantir que garante
todos os pedidos inicialmente formulados; e (4) ter em atenção a
evolução do
sistema, ou seja, que o sistema seja adaptável às necessidades
adicionais que
poderão surgir. Neste capítulo será dado uma maior atenção a (1)
– análise funcional
do sistema.
O objetivo deste capítulo é identificar os requisitos
necessários para
implementar a aplicação Estrada Segura. Estes têm como objetivo
identificar de
forma clara como o dispositivo móvel comunica com o servidor e a
rede social
Facebook. É importante realçar a importância desta fase: é um
dos esforços mais
importantes no desenvolvimento de um sistema. Estes requisitos
são desenvolvidos
para garantirem que todo o esforço do desenvolvimento do sistema
contempla o
modelo conceptual que foi desenhado cuidadosamente para que
todas as hipóteses
de interação com o sistema decorressem sem haver falhas. Ou
necessidades de
refazer desenvolvimento por falta de análise.
5.1. Processo de modelação
No desenvolvimento de software não existe um processo de
desenvolvimento de
software mais ou menos correto. No processo de seleção do
processo de
desenvolvimento é tido em atenção o quão é adequado à
complexidade do sistema,
a equipa disponível para desenvolver e como será feita a
utilização do sistema.
Aquando da escolha do modelo de processo deve ser tido em
consideração (Boehm
& Belz, 1990):
Desenvolvimento incremental – ao longo do desenvolvimento será
feito um
conjunto de incrementos de funcionalidades. Usualmente os
incrementos surgem
devido a necessidades que surjam posteriormente; restrições de
orçamento sendo
os incrementos desenvolvidos gradualmente; requisitos que tenham
sido mal
especificados e aplicações com um elevado número de módulos.
Desenvolvimento orientado ao custo ou por tempos – é gerado uma
lista de
prioridades dos requisitos do sistema até atingir o limite de
custo ou tempo
disponível.
-
Luis Manuel Pinto da Costa
30
O modelo clássico é o modelo cascata (do inglês, Waterfall
model) onde o
desenvolvimento é linear e sequencial. O desenvolvimento em
cascata segue as
seguintes etapas: levantamento dos requisitos; desenho do
sistema; testes
(validação); instalação e integração do sistema; e, por fim,
operação e manutenção
(Figura 12).
AnáliseDe
Requisitos
Desenhodo
Sistema
Implementação
Teste
Integraçãodo
Sistema
Manutenção
Figura 12 - Modelo Castata (Waterfall model)
A vantagem deste modelo é que existe uma separação clara entre
cada fase de
desenvolvimento; simples de compreender e utilizar; fácil de
gerir (devido à rigidez
do modelo); funciona bem para pequenos projetos com poucos
requisitos; fases
claramente definidas; e, os processos e resultados podem ser
facilmente bem
documentados. A desvantagem deste modelo é o de não permitir
flexibilidade, por a
sua natureza ser sequencial torna-se muito rígido quando é
necessário retornar
para uma das fases anteriores. Existem situações onde são
detetados erros na
modelação dos requisitos ou o cliente tem dificuldades em
definir as tuas
necessidades explicitamente. Portanto, no desenvolvimento de
software existe uma
elevada quantidade de risco e incerteza; o modelo poderá ficar
pobre para projetos
que necessitem de incrementos; e muito complicado para realizar
alterações nos
requisitos.
Uma alternativa ao modelo sequencial é o modelo incremental,
onde o modelo é
desenhado, implementado e testado de forma incremental. Nestes
modelos são
adicionadas funcionalidades recursivamente até o sistema estar
completo. Ao
contrário do modelo sequencial onde a documentação se encontra
muito bem
-
Estrada Segura - AAF
Aplicação Android e Alertas no Facebook
31
definida, no modelo incremental poderá ser complicado garantir
esta
funcionalidade. A vantagem de usar o modelo incremental é por
este modelo
permitir que seja dividido em vários “mini” projetos de
desenvolvimento que
poderão ser continuamente evoluídos ao logo do desenvolvimento
do sistema e, por
isso, permite que requisitos de maior prioridade sejam
rapidamente processados.
Em comparação ao modelo sequencial, o modelo incremental é mais
flexível e reduz
o risco de satisfazer os requisitos da aplicação.
AnáliseDe
Requisitos
Desenhodo
Sistema
Implementação
Teste
Integraçãodo
Sistema
AnáliseDe
Requisitos
Desenhodo
Sistema
Implementação
Teste
Integraçãodo
Sistema
AnáliseDe
Requisitos
Desenhodo
Sistema
Implementação
Teste
Integraçãodo
Sistema
Funcionalidades
Tempo
Figura 13 - Modelo Incremental.
No desenvolvimento do Sistema Estrada Segura foi utilizado o
modelo
incremental. O modelo em cascata seria uma boa opção pelas suas
vantagens
mencionadas anteriormente, no entanto, o Sistema Estrada Segura
é uma aplicação
de pequena dimensão e por isso facilita na gestação da
documentação. E também
não existem várias equipas a desenvolver tarefas que precisem de
estar linearmente
separadas. Contudo o motivo principal por optar pelo modelo
incremental foi
devido à necessidade de continuamente alterar os requisitos do
sistema. As
funcionalidades da aplicação foram sendo alteradas de acordo
necessidades que
foram posteriormente identificadas. Como por exemplo, integração
com a rede
social Facebook, gosto/não gosto de um marco e adicionar as
camaras de trafego.
-
Luis Manuel Pinto da Costa
32
5.2. Análise de requisitos 5.2.1. Requisitos funcionais
Em engenharia de software requisitos funcionais referem-se a uma
função de um
sistema e os seus componentes. Onde a função é descrita pelos
seus componentes
de entrada, saída e o seu comportamento. A descrição tem de
obedecer a um balanço
entre uma especificação demasiado abstrata e demasiado
detalhada. Logo,
descrições que possam ser demasiado vagas e pouco descritivas e
não ajudaria
tecnicamente ou descrições demasiado detalhadas que dificultaria
na adaptação dos
componentes em situações pontuais no decurso de um processo
(Humphrey, 1989).
5.2.2. Funcionalidade de um Sistema Estrada Segura em
Portugal
O Sistema Estrada Segura pretende melhorar a segurança dos
automobilistas ao
avisar em tempo real da proximidade de alguma situação que possa
ter ocorrido, ou
estar a decorrer, na via. A questão que surgiu foi: Como
conseguir obter estas
informações?
O desenvolvimento da aplicação Sistema Estrada Segura envolveu a
consulta de
um leque de informação que irei descrever de seguida.
Quem o avisa25 (PSP) – Mensalmente a PSP disponibiliza os locais
dos radares.
Radares fixos26 – Lista obtida em Outubro de 2013. Neste momento
só se encontra
disponível para utilizadores registados.
Mapas da Google – Mapas que possibilitam a utilização da
aplicação em diferentes
países.
Lusoponte27 - integrar em tempo real o vídeo das camaras da
Ponte 25 de Abril e
Ponte Vasco da Gama.
Entrevista com Diretor das Estradas de Portugal sobre a
viabilização de integrar as
camaras na aplicação Estrada Segura28.
Entrevistas para perceber o que os utilizadores procuram quando
utilizam redes
sociais para obter alertas sobre operações stop e problemas de
tráfego.
5.2.3. Recolha de informação
Os utilizadores da aplicação inserem marcos a alertar de eventos
na via. Também
validam marcos que já se encontravam previamente inseridos: um
utilizador recebe
um alerta de acidente, imediatamente o seu nível de atenção
altera, e
25 http://www.psp.pt/
26
http://radaresdeportugal.pt/site/bases-de-dados-pdi/viewcategory/4-radares-atualizados
27 https://www.lusoponte.pt/livecam.asp
28 http://www.estradas.pt/index
-
Estrada Segura - AAF
Aplicação Android e Alertas no Facebook
33
posteriormente pode validar o marco como um alerta correto. No
caso contrário
também poderá indicar na aplicação que aquele marco poderá ser
removido. O que
é importante?
A interface da aplicação é tangível a qualquer automobilista? O
desenho da aplicação
é intuitivo?
Em tempo real, é possível receber (no servidor) o alerta de
novos marcos sem
longos períodos de espera? Que informação será mais adequada
para enviar?
Como gerir marcos muito próximos? Elevada probabilidade de ser o
mesmo alerta
fornecido por automobilistas diferentes.
É possível garantir a sincronização dos marcos nos vários
dispositivos móveis?
Como calcular eficientemente, em tempo real, a distância dos
automobilistas aos
marcos existentes?
De que forma se deve utilizar a informação fornecida pelos
automobilistas?
Deveremos restringir esta informação apenas à aplicação?
Sendo os pontos acima questões importantes para o
desenvolvimento da
aplicação, seguidamente serão descritas as formas de recolha de
informação
utilizadas:
Marcos inseridos pelos automobilistas.
Validação (positiva e negativa) dos marcos.
Utilizadores ativos (loja da Google play store).
Número de instalações da aplicação (ao longo do tempo).
Utilizadores ativos nos grupos do Facebook.
Atividade nos grupos do Facebook: da aplicação ou apenas na rede
social.
5.2.4. Integração com redes sociais – Facebook
A relevância e impacto das redes sociais foi uma questão
importante que surgiu
no processo de investigação. As redes sociais são um meio de
grande sucesso e que
ajudam no processo de divulgação de informação e, por isso,
importante para o caso
em estudo.
Na rede social Facebook existe uma comunidade que partilha
ativamente alertas
de congestionamento de vias causado por diferentes motivos
(fluxo elevado de
veículos, acidente, obras, etc) e, também alertam em relação a
radares e operações
stop. Estes alertas são inseridos manualmente, onde
habitualmente apenas se
encontra associado a uma breve descrição preenchida pelo
utilizador. Em
comparação com a aplicação proposta, Facebook tem a vantagem de
se aproximar
de um número mais elevado de pessoas e, tem a desvantagem de se
encontrar
afastado do automobilista. Também tem a desvantagem de não
apresentar um mapa
mais preciso de onde decorre a obstrução na via.
-
Luis Manuel Pinto da Costa
34
Com base neste cenário e, com o objetivo de complementar a
aplicação proposta
com as redes sociais, foi implementado um módulo que integra a
aplicação Estrada
Segura com a rede social Facebook. Neste módulo o objetivo será
comunicar ao
servidor aplicacional um novo marco e também no Facebook no
grupo do Distrito
associado ao marco.
5.3. Casos de uso
Um requisito funcional poderá ser um cálculo, detalhes técnicos,
manipulação de
dados etc. Os requisitos comportamentais, que contemplam todos
os casos do
sistema, são extraídos dos casos de uso. Portanto um caso de uso
corresponde a uma
unidade funcional onde é descrita uma sequência de mensagens
entre o sistema e
outros componentes (e.g. dispositivo móvel ou facebook).
Os casos de uso são uma sequência de ações que um ou mais ator
realizam de
modo a obter um determinado resultado. Os diagramas de caso de
uso permitem
representar as interações entre os utilizadores e os sistemas e
também as
funcionalidades a implementar no sistema. É importante notar que
os diagramas de
casos de uso não descrevem o modo como se deve construir uma
aplicação, mas sim,
o modo como se deve comportar. De seguida é apresentado o
diagrama de caso de
uso (Figura 14) do sistema. No diagrama “Utilizador” representa
um ator da
aplicação. O “Utilizador” será o principal componente pois toda
a interação do
sistema através da interface móvel é feita por este ator.
-
Estrada Segura - AAF
Aplicação Android e Alertas no Facebook
35
Figura 14 - Caso