Diversos trabalhos direcionaram esforços em torno do conceito de “Cidade Ubíqua”, ou U- City3 (JANG; SUH, 2010). Esse conceito, de forma simplificada, está relacionado ao provi- mento de diversos serviços ubíquos, com o propósito de tornar melhor a convivência urbana, sob aspectos como trânsito, serviços de saúde, serviços de atendimento aos cidadãos, dentre outros. Dentre os serviços disponíveis em uma cidade ubíqua, destaca-se neste capítulo o
U-Parking (KNHC, 2007) apud (JANG; SUH, 2010), um serviço ubíquo para o controle de estacionamento. Esse tipo de serviço influenciou na escolha do domínio específico de aplicação a ser explorado por envolver uma série de situações as quais podem ser utilizadas para demonstrar os benefícios do tratamento de exceções sensível ao contexto e da utilização do MDBT.
5.2.1 Aplicação Motivadora
Primeiramente, a escolha de sistemas de estacionamento ubíquo como domínio específico para o desenvolvimento de uma prova de conceito deve-se pela utilização das ideias e problemas desses domínio, no decorrer desta pesquisa, como cenário motivador para discussões técnicas e reuniões realizadas entre alunos e pesquisadores do GREat4. Diversas situações, apresentadas como exemplos nesta dissertação, foram idealizadas a partir de reflexões iniciadas nessas discussões e reuniões.
Além disso, a escolha desse domínio específico deve-se pelo estudo realizado sobre um sistema real chamado SFPark (SFMTA, 2012), que serviu como aplicação motivadora. Esse sistema foi implantado pela Agência Municipal de Transportes de São Francisco, nos Estados Unidos, para controlar a ocupação de vagas de estacionamento em vias públicas em algumas áreas da cidade. As informações coletadas e analisadas sobre o SFPark proporcionaram um melhor entendimento sobre alguns requisitos específicos desse tipo de sistema.
O acesso as informações sobre esses tipo de sistema elucidam alguns benefícios do seu uso, que podem ser citados:
• A otimização na ocupação de vagas;
• A facilidade no acesso a informações de vagas disponíveis;
• A viabilidade de uso de outras formas de pagamento (e.g., através do celular, ao invés do uso de tickets);
• A possibilidade de utilização de políticas de cobrança auto-adaptáveis, com base na disponibilidade de vagas (e.g., tornando mais barato estacionar em períodos onde a ocupação de vagas é baixa, ou mais caro caso contrário);
• Vários outros benefícios indiretos (e.g., melhoria no comércio local em consequência da maior rotatividade nos estacionamentos, por sua vez, promovido pela melhoria na gestão de ocupação de vagas).
No SFPark, as informações de vagas disponíveis são acessíveis através de um portal, por aplicações móveis, ou, até mesmo, através da utilização da API5disponibilizada ao público (por exemplo, utilizada em sistemas embarcados nos veículos). Na figura 5.1, são apresentadas duas imagens do SFPark. Na imagem 5.1(a), é apresentada uma montagem com uma tela real
4Grupo de pesquisa o qual os autores deste trabalho fazem parte. Website: www.great.ufc.br . 5Sigla do inglês para Application Programming Interface.
da aplicação móvel do SFPark, exibindo um mapa com marcações indicando a disponibilidade de vagas controladas por esse sistema, e os principais elementos do sistema do ponto do vista do usuário. Na imagem 5.1(b), é apresentada uma fotografia de um dos sensores utilizados nesse sistema.
(a) Montagem com ilustração de um usuário estacionando seu veículo e uma tela real da aplicação móvel do SFPark exibindo a disponibilidade de vagas.
(b) Foto com sensores de estaciona- mento do SFPark.
Figura 5.1: Imagens do sistema SFPark (SFMTA, 2012).
5.2.2 Delimitação do Cenário
O desenvolvimento de um sistema de estacionamento oferece um cenário fértil para observação de características onde a utilização da computação ubíqua pode trazer benefícios. Em um estacionamento tradicional qualquer, seja ele limitado a uma área privada ou a um conjunto de vias públicas, podem ser observadas pelo menos duas características comuns: a mobilidade dos usuário/veículos e a possibilidade de bilhetagem. Essa primeira característica de mobili- dade dos usuários é observável nos estacionamentos, uma vez que os usuários/veículos estão normalmente em movimento, seja buscando uma vaga para estacionar ou uma rota para algum outro lugar (e.g., saída do estacionamento). A característica de bilhetagem está relacionada a possibilidade de cobrança pelo tempo em que uma vaga de estacionamento ficou ocupada.
Ao se considerar a utilização da computação ubíqua como fundação para o desen- volvimento de um sistema de estacionamento, torna-se possível atender aos requisitos chaves já identificados anteriormente de forma mais apropriada, por exemplo levando em consideração informações de contexto dos usuários e do ambiente. Além disso, o desenvolvimento desse tipo de sistema sob uma perspectiva de computação ubíqua permite contemplar uma série de funcionalidades ou serviços adicionais, antes não concebíveis, como, por exemplo, a adoção de uma política de cobrança auto-adaptável (já presente no SFPark).
Considerando os possíveis benefícios da utilização da computação ubíqua nesse domínio específico, de sistemas de estacionamentos, é possível especificar de forma mais direta três funcionalidades. Tais funcionalidades foram analisadas e desenvolvidas para compor o UbiParking, e são enumeradas a seguir:
1. Pesquisar vagas disponíveis, o sistema deve ser capaz de localizar vagas livres e indicá-las para os usuários;
2. Reservar uma vaga, o sistema deve ser capaz de receber confirmações dos usuários sobre a aceitação de vagas, podendo reservá-las por um período determinado;
3. Registrar o estacionamento, o sistema deve estar apto a registrar estacionamentos efetiva- dos (percebidos através de sensoriamento).
Contudo, conforme já explicado nos Capítulos 1 e 2, a utilização da computação ubíqua não trás apenas oportunidades de benefícios para os sistemas desenvolvidos. Ao de- senvolver um sistema ubíquo, diversos problemas complexos devem ser enfrentados, como, por exemplo, a especificação do comportamento do sistema para condições de contexto indesejadas. As três funcionalidades enumeradas estabelecem o escopo de desenvolvimento da PoC. Todavia, mesmo parecendo simples, essas funcionalidades podem envolver uma série de situações excepcionais, as quais podem ser contornadas através do uso adequado do mecanismo de tratamento de exceções contextuais proposto nesta dissertação.
Antes de detalhar algumas situações excepcionais das funcionalidades enumeradas, é necessário destacar que as três podem ser organizadas para compor, de forma simplificada, a tarefaP❛r❦✐♥❣❚❛s❦, já apresentada em exemplos anteriormente. Essa tarefa estaria relacionada com a meta dos usuários desse sistema, que é simplesmente a meta de “estacionar”. Caso essas funcionalidades sejam executadas por um mesmo usuário, seguindo uma sequência adequada, ao final da execução, a meta deve ter sido atingida. Logo, percebe-se que a construção desse sistema é passível de ser realizada através do MDBT. Nesse caso, cada uma das três funcionalidades devem ser mapeadas para passos da tarefaP❛r❦✐♥❣❚❛s❦, cada um cumprindo parcialmente a meta dos usuários, através da utilização de um ou mais serviços disponíveis no ambiente.
Durante o primeiro passo, ou execução da funcionalidade “Pesquisar vagas dispo- níveis”, o sistema deve localizar uma vaga disponível e informá-la para o usuário. A busca pela vaga, por sua vez, pode levar em consideração a localização do usuário ou suas preferências durante a escolha.
Já no segundo passo, o de reserva de uma vaga, o sistema deve aguardar uma confirmação de aceite do usuário em relação a vaga que lhe foi informada. Após recebimento dessa confirmação, o sistema deverá reservar esta vaga para o usuário, passando, no passo seguinte, a monitorá-la até o motorista efetivamente parar seu veículo no local previsto.
Apesar de existirem possíveis situações excepcionais durante a execução desses dois passos, foram, em um primeiro momento, desconsideradas.
Já o terceiro passo, o de registro do estacionamento, inicia logo após a aceitação de uma vaga. Este é o passo onde o sistema permanece monitorando uma vaga. Além disso, ele só é finalizado após o usuário conseguir efetivamente ocupar a vaga que lhe foi recomendada. Porém, para este passo da tarefaP❛r❦✐♥❣❚❛s❦, foi definido uma situação excepcional.
Nesse terceiro passo, após a confirmação de aceitação de uma vaga, o usuário irá dispor de um intervalo de tempo para se dirigir até a vaga reservada. No entanto, por motivos alheios ao funcionamento do sistema, a vaga reservada está sujeita a vários problemas que podem alterar inesperadamente sua disponibilidade. Um exemplo disso pode ser a ocupação da vaga reservada por um outro usuário, de forma concorrente, ignorando as recomendações do sistema, ou, até mesmo, um problema físico na vaga ocasionando a sua interdição. Essa mudança contextual, na disponibilidade da vaga, afeta o funcionamento normal da tarefa P❛r❦✐♥❣❚❛s❦, impedindo a sua finalização de forma adequada.
Neste caso, o sistema deve ser capaz de lidar com essa situação excepcional, evitando problemas para o usuário que havia “reservado” a vaga. Logo, identifica-se que esse fluxo pode ser investigado na PoC através da utilização do conceito de exceções contextuais locais, do mecanismo proposto nesta dissertação.
Além disso, como já foi mencionado, um sistema de estacionamento ubíquo pode possuir integrações com outros sistemas, como, por exemplo, com um sistema de prevenção de incêndio. Por conseguinte, outras situações excepcionais podem ser detectadas, podendo influenciar na execução de uma determinada tarefa do sistema. Como exemplo, pode ser considerado uma situação onde ocorra a detecção de incêndio simultaneamente a execução de instâncias da tarefaP❛r❦✐♥❣❚❛s❦. Essa situação de incêndio é considerada na PoC como um cenário a ser tratado através do uso de exceções contextuais globais.
5.2.3 Organização da Prova de Conceito
Inspirado na organização dos dispositivos e serviços do SFPark, foram concebidos três tipos de elementos para a PoC, são eles:
• os serviços ubíquos,
• as interfaces com usuários (nesse caso, representadas pelos dispositivos móveis),
• e os dispositivos de sensoriamento.
Na figura 5.2, é mostrado uma visão geral da organização desses elementos. A partir dessa visão global, é possível ter um melhor entendimento sobre a forma de interação entre todos esses agentes. Nesse caso, é utilizado o SysSU como base para essas interações.
O Ubiparking Service, ilustrado na figura 5.2, representa os serviços ubíquos desenvolvidos para o protótipo do UbiParking. Para o desenvolvimento e implantação desses serviços, foi utilizado um computador com sistema operacional Windows 7 e a plataforma Java v.6 . Nesse mesmo dispositivo foi também implantada uma instância do❯❜✐❈❡♥tr❡ para possibilitar a comunicação dos elementos do sistema.
O UbiParking Client, também mostrado na figura 5.2, representa a interface com os usuários do sistema através de uma aplicação móvel. Esta aplicação foi desenvolvida sob a Plataforma Android, compatível com versões iguais ou superiores a versão 2.1 . Ademais, essa aplicação foi desenvolvida com a instanciação do framework FRonTES.
Figura 5.2: Organização dos agentes no protótipo desenvolvido como prova de conceito. Já o papel dos sensores, responsáveis pela detecção de informações de contexto, foi simplificado através do mapeamento do seu comportamento para uma aplicação que simula a detecção e notificação de mudanças no estado do contexto. Tal aplicação permite alterar arbitrariamente a percepção do sistema quanto as informações de contexto. Essa característica é conveniente para investigação do comportamento do mecanismo de tratamento de exceções proposto nesta dissertação, uma vez que permite alterar o contexto e forçar a adaptação no fluxo de execução do sistema para cenários críticos.