PAULO VICTOR C. DO N. SANTANA
EXECUTANDO APLICAÇÕES WEB DE FORMA OFFLINE COM O
GOOGLE GEARS
FEIRA DE SANTANA 2010
EXECUTANDO APLICAÇÕES WEB DE FORMA OFFLINE COM O
GOOGLE GEARS
Trabalho de Conclusão de Curso apresentado ao curso de Graduação em Engenharia de Computação da Universidade Estadual de Feira de Santana para a obtenção do título de Bacharel em Engenharia de Computação.
Orientador: Prof. Hugo Saba
Co-Orientador: Prof. Kellyton dos Santos Brito
FEIRA DE SANTANA 2010
Resumo
Este trabalho propõe uma solução para adoção de softwares web de gerenciamento em locais em que a conexão com a internet se apresenta intermitente ou ausente por um dado período de tempo. Essa solução visa transformar essas aplicações web em programas que possam ser executados de forma offline. Dessa forma, algumas funcionalidades do software estarão disponíveis mesmo que a conexão com a internet não esteja. Nessa realidade, as informações acessadas através de tais funcionalidades ficam armazenadas localmente e são atualizadas sempre que o usuário da aplicação solicitar, sincronizando a base de dados local com a base de dados web. Para a validação da proposta citada, este trabalho realizou uma parceria com uma empresa que disponibilizou uma de suas aplicações. Essa aplicação trata-se de um sistema para gestão médica e o módulo de agendamento desse sistema teve acrescentado ao seu código-fonte o modo offline. Para a concepção da solução, conceitos relativos aos sistemas web e à sua utilização através da abordagem de Software como Serviço (SaaS - Software as a Service), aos sistemas web offline, bem como o uso da tecnologia Google
Gears tiveram que ser levados em consideração e pesquisados. Como resultado do
trabalho a aplicação disponibilizada pela empresa parceira foi testada e funcionou como esperado, assim como o seu modo offline adicionado ao software.
Abstract
This paper proposes a solution to adoption of management software web in places where internet connection is slow, intermittent or missing for a given period of time. This solution aims to transform these applications into web programs that can run offline. Thus, some features of the software will be available even if the internet connection is not. In this reality, the information accessed through such features are stored locally and are updated whenever the user requests, synchronizing the local database with the web database. To validate the mentioned proposal, as this research has made a partnership with a company that disponibilized one of its applications. This application it is a system for medical management and the scheduling module of this system has added to source code the offline mode. For the design of the solution, concepts of the web systems and their use by the approach of Software as a Service (SaaS), web systems offline as well as the use of Google Gears technology had to be taken into consideration and researched. As a result of job, application available from partner company was tested and functioned as expected, as well as its offline mode added to the software.
Lista de Figuras
Figura 1: Camadas de dados Gears (GEARS ARCHITECTURE, 2010). ... 23
Figura 2: Pesquisa por Especialidade ... 29
Figura 3: Pesquisa por Médico ... 30
Figura 4: Pesquisa por Unidade ... 30
Figura 5: Pesquisa por Especialidade e Unidade ... 31
Figura 6: Arquitetura do Sistema ... 35
Figura 7: Formulário para captura dos dados offline ... 38
Figura 8: Diagrama de entidade e relacionamento do banco de dados local ... 39
Figura 9: Formulário para mudança de Estado ... 41
Figura 10: Formulário de autenticação offline ... 41
Figura 11: Tela inicial... 44
Figura 12: Tela inicial com formulário offline ... 45
Figura 13: Tela inicial com formulário offline com campos preenchidos ... 45
Figura 14: Mensagem de dados capturados com sucesso ... 46
Figura 15: Tela inicial com formulário offline ("Change to Off" habilitado) ... 47
Figura 16: Tela inicial modo offline ... 47
Figura 17: Pesquisa por Unidade (Offline) ... 48
Figura 18: Pesquisa por Unidade e Especialidade (Offline) ... 49
Figura 19: Pesquisa por Especialidade "ANGIOLOGIA" (Offline) ... 49
Figura 20: Pesquisa por Especialidade "ORTOPEDIA" (Offline) ... 50
Figura 21: Pesquisa por Médico (Offline) ... 50
Figura 22: Pesquisa por Especialidade "ANGIOLOGIA" (Online) ... 51
Lista de Tabelas
Sumário
Introdução ... 8
1 Sistemas web ... 13
1.1 Software como Serviço – SaaS ... 14
1.2 Sistemas web offline ... 16
2 Google Gears e Microsoft Sync Framework ... 18
2.1 Google Gears ... 18
2.1.1 LocalServer ... 19
2.1.2 DataBase... 20
2.1.3 WorkerPool ... 20
2.1.4 Factory ... 21
2.1.4 Outros módulos do Gears ... 21
2.1.6 Arquitetura do Google Gears ... 22
2.2 Microsoft Sync Framework ... 24
2.2.1 Microsoft Sync Services for ADO.NET ... 25
2.3 Comparativo Google Gears e Microsoft Sync Framework ... 26
3 Medicware Sistemas de Informática... 27
3.1 SmartDoctor (Agendamento) ... 27
4 SmartDoctor Offline ... 32
4.1 Projeto ... 33
4.1.1 Arquitetura ... 35
4.1.2 Funcionamento e implementação ... 37
4.1.2.1 Processo de inicialização dos componentes ... 37
4.1.2.2 Sincronização ... 40
4.1.2.4 Visualização e manipulação do SmartDoctor Offline ... 42
4.2 SmartDoctor Offline em Ação ... 44
Considerações Finais ... 53
Introdução
Empresas, de um modo geral, buscam sempre gerenciar de maneira mais eficaz e eficiente suas atividades e recursos. Realizar uma gestão da informação de maneira eficiente transformando dados precisos, capazes de prover um melhor controle das atividades desempenhadas, padronizando e organizando suas tarefas e produtos é um passo para alcançar uma melhor gestão desses recursos e atividades. Nesse contexto, softwares voltados à gestão da informação servem como um importante auxílio na busca para conseguir esse objetivo (REZENDE, 2002).
Instituições como hospitais e clínicas médicas costumam utilizar softwares de auxilio ao controle das suas consultas, ao gerenciamento das informações necessárias aos cuidados do paciente e até mesmo para realizar a gerência de seus próprios serviços e processos. Um exemplo desse tipo de aplicação é um software para gestão de informação que auxilie um setor profissional, como o setor de enfermagem ocupacional, de uma clínica ou hospital em questão. Na enfermagem ocupacional a praticidade na atualização e resgate de registros de acidentes de trabalho com materiais biológicos, bem como a avaliação estatística desses registros é uma vantagem obtida com uso de uma ferramenta ocupacional adequada (PARRO; ÉVORA, 2008). Dificuldades na organização dos trabalhos e ações mal planejadas ou sem planejamento prévio fazem com que haja pouca exploração da informação, portanto esse tipo de aplicação figura uma necessidade do ramo (PARRO; ÉVORA, 2008).
Por outro lado, outros tipos de organizações, normalmente, utilizam soluções diferenciadas. Empresas como indústrias, por exemplo, utilizam softwares Enterprise
Resource Planning (ERP) para gerenciar seus processos. O software ERP consiste numa
solução integrada de gerenciamento, fazendo uso de recursos de automação e informatização, com uma base de dados comum para os componentes do sistema. Com o uso desse tipo de software é possível realizar uma otimização das atividades de gerência, das operações, e avaliação dos investimentos de uma empresa. Como o sistema ERP integra o fluxo e os processos de negócio da empresa por meio de seus componentes integrados, e ainda com capacidade de efetuar o gerenciamento das atividades dos usuários do sistema, torna-se uma poderosa ferramenta para a melhoria dos processos de uma empresa. (SACCOL et al., 2002).
Apesar de softwares como os supracitados possibilitarem melhorias nos processos das organizações, a manutenção de uma estrutura própria para seu uso podem envolver investimentos tanto de hardware, quanto de software e pessoal, investimentos esses que resultem em custos para as empresas que podem ser vistos como não vantajosos. Os custos com hardware incluem gastos com aquisição de servidores, infra-estrutura de rede e infra-infra-estrutura de segurança; os gastos com software incluem sistemas para os servidores, políticas de backup, softwares das estações e antivírus; e gastos com pessoal são referentes à contratação de profissionais competentes para gerenciamento de banco de dados, para segurança do software, manutenção da rede e suporte ao usuário, dentre outros.
Estes custos são uma barreira para a adoção desses tipos de softwares por parte de algumas empresas. O impacto desses custos em pequenas e médias empresas, que possuem um faturamento menor em relação a empresas de grande porte, pode fazer com que seus administradores recuem na decisão de adquirir tais sistemas.
Uma solução para esse problema é a implantação desses softwares como serviços web usando a abordagem Software como Serviço (SaaS - Software as a
Service). Nessa abordagem o cliente não se preocupa com os custos de aquisição e
manutenção do software e os custos com hardware e pessoal são reduzidos, uma vez que não é preciso manter um servidor para a aplicação e uma equipe para dar manutenção do sistema. Através de um modelo de subscrição o software é disponibilizado remotamente para o cliente por um provedor de serviço (PRESTE, 2008). Dessa forma o usuário irá pagar uma taxa mensal à empresa provedora do serviço e ter acesso ao software e suas funcionalidades através de um browser com acesso à internet. Fazendo uso desse recurso, os custos ficam sob responsabilidade da empresa que disponibiliza o software.
Apesar das empresas terem à sua disposição a possibilidade do uso de softwares no modelo SaaS, a falta de uma conexão de internet confiável gera incertezas que atrapalham a adoção em larga escala de softwares no modelo SaaS por parte das empresas.
Basicamente, os modelos mais comuns de conexão com a internet no Brasil são através de:
• Modem digital via linha telefônica “Digital Subscriber Lines (DSL)” • Modem via cabo
• Conexão via rádio • Conexão via celular • Acesso discado • Conexão via satélite
A observação dos dados de uma pesquisa sobre o uso da internet no Brasil realizada pelo Núcleo de Informação e Coordenação do Ponto BR (NIC.br) entre Outubro e Novembro de 2009 e disponível no site do Centro de Estudo sobre as Tecnologias da Informação e Comunicação(CETIC), mostram a situação apresentada na Tabela 1 (CETIC.BR, 2009):
Tabela 1: Uso da internet por empresas por tipo de conexão
Percentual (%)
Modem digital via linha telefônica "DSL"
Conexão via rádio
Acesso discado "conexão dial-up via telefone"
TOTAL 60 16 3
Norte 43 20 2
Nordeste 54 21 4
Fonte: Centro de Estudo sobre as Tecnologias da Informação e Comunicação – CETIC.
A tabela mostra que no Brasil nas empresas com dez ou mais funcionários 60% utilizam internet através de modem digital via linha telefônica “DSL”, 16% conexão via rádio e 3% acesso discado. Em relação às regiões Norte e Nordeste esses valores se alteram para 43% modem digital via linha telefônica “DSL”, 20% conexão via rádio e 2% acesso discado e 54% digital via linha telefônica “DSL”, 21% conexão via rádio e 4% acesso discado, respectivamente.
Uma análise desses dados revela os fatores que podem fazer com que softwares baseados em web, como os do modelo SaaS, não executem sempre como esperado nas empresas. Como dito anteriormente, 16% das empresas utilizam conexão com a internet via rádio. Esse tipo de conexão é fornecido através de equipamentos capazes de proverem taxas de transferências entre 64 Kilobits por segundo (Kbps) e 2 Megabits por segundo (Mbps), tanto para realização de download como de upload, a distâncias de 5 km usando antenas unidirecionais, ou seja sem obstáculos entre as antenas (CYCLADES BRASIL, 2008). O problema desse tipo de conexão se encontra nas
condições do tempo. Condições climáticas extremas, como vento forte, céu nublado e tempo chuvoso podem eventualmente forçar os provedores de serviço a pararem de funcionar, fazendo com que nem sempre o serviço esteja disponível. (ILYAS, 2010; COTANIS; JABBARI, 2010). Sempre que essa indisponibilidade acontecer, o funcionamento de sistemas web utilizados por empresas através de uma conexão via rádio será afetado. O percentual de empresas afetadas aumenta quando se observa as regiões Norte e Nordeste (Tabela 1). Dessa forma, observa-se que nem sempre os softwares utilizados pelas empresas como serviços web terão as suas funcionalidades disponíveis.
Nesse contexto, este trabalho propõe uma solução para a adoção de softwares de gerenciamento adicionando aos softwares no modelo SaaS um modo offline. Dessa maneira, algumas funcionalidades do software estarão disponíveis mesmo que a internet esteja indisponível num dado momento. Isso é possível porque tanto elementos visuais da aplicação, como botões e imagens, quanto informações a respeito da base de dados
web da aplicação são armazenadas localmente no computador do usuário. Essas
informações da base de dados web (lado do servidor), são copiadas e salvas localmente, criando uma base de dados local semelhante à do servidor. As informações dessa base local são atualizadas sempre que o usuário do sistema solicitar, clicando em um botão, por exemplo, sincronizando base de dados local e base de dados do servidor, onde essa base local fica disponível no computador do usuário para ser utilizada no modo offline. Não será possível na aplicação realizar ações que modifiquem a base de dados local, pois essas modificações precisariam ser atualizadas na base de dados do servidor. Essa atualização levantaria questões importantes como o conflito entre duas atualizações feitas em versões offline distintas da mesma aplicação e que utilizasse a mesma base de dados e qual seria o tipo de transação realizada para não expor o banco de dados na rede.
Para a concepção da solução deste trabalho, que passa a ser tratada nessa seção como SmartDoctor Offline, alguns passos foram seguidos. Primeiramente foi feito um levantamento bibliográfico dos meios de informação confiáveis e relevantes ao tema desta monografia. Dentre os meios procurados e encontrados pode-se destacar artigos científicos e livros nas áreas de SaaS, web offline, informática na saúde e administração da informação. Foram encontradas e utilizadas como meios também home pages de algumas tecnologias envolvidas direta ou indiretamente com a implementação da
proposta. Depois de levantadas as bibliografias iniciais, uma seleção daquelas que possuíam o conjunto de informações mais relevante ao escopo do trabalho foram selecionadas.
Este trabalho está organizado da seguinte maneira: o capítulo 1 apresenta uma visão geral a respeito dos sistemas web dando um enfoque ao modelo SaaS de entrega de software, explicando seus principais conceitos, e aos sistemas web offline apresentando as principais questões envolvidas neste tipo de desenvolvimento. O capítulo 2 apresenta uma descrição das principais tecnologias para o desenvolvimento de aplicações web offline: Google Gears e Microsoft Sync Framework, bem como um comparativo entre as duas tecnologias apresentando as principais características de cada uma e posteriormente a tecnologia escolhida para este trabalho. O capítulo 3 discorre a respeito da empresa Medicware Sistemas de Informática, empresa parceira deste trabalho, e apresenta o módulo de agendamento da aplicação disponibiliza pela Medicware, que terá o modo offline adicionado. O capítulo 4 apresenta a aplicação desenvolvida neste trabalho, o SmartDoctor Offline, descrevendo o projeto do sistema, arquitetura, descrição da implementação e do funcionamento do software, bem como os testes realizados. Por fim são feitas considerações finais a respeito do trabalho desenvolvido.
1 Sistemas web
Este capítulo apresenta, a princípio, uma visão geral a respeito dos sistemas web discutindo posteriormente o modelo de entrega de software SaaS, descrevendo como ele funciona e quais suas principais características e por fim discorrendo sobre os sistemas
web offline apresentando as principais questões envolvidas no desenvolvimento desse
tipo de aplicação.
No século 21, as pessoas fazem uso do acesso à internet para verificar emails, utilizar ferramentas online, conversar com amigos ou até mesmo participar de reuniões online de negócios. Através da internet é possível fazer o uso de aplicativos web, sem que o usuário possua um computador, através de uma lan house, por exemplo. Tais aplicações podem ser acessadas também por dispositivos móveis como smartphones e
Personal Digitant Assistant's (PDAs) e ainda são bastante úteis para o usuário que
possui ou tem acesso a internet por vários computadores, onde é possível acessar a mesma aplicação, com os mesmos dados desejados, de locais diferentes. (SAIKAEW, 2009).
No início da década de 80, a web se constituía, basicamente, de conteúdos estáticos descritos através da linguagem Hypertext Markup Language (HTML) (CYCLADES BRASIL, 2008). Esses conteúdos não requeriam uma programação extensiva com realização de cálculos e inserção de estruturas lógicas e de repetição complexas. Com o surgimento de novas tecnologias foi possível realizar a criação de páginas web com conteúdo dinâmico. O desenvolvimento de sistema web, com lógicas complexas, conexão com banco de dados e processamento de dados foi possível, primeiro, graças ao surgimento da tecnologia Commom Gateway Interface (CGI) que permitia ao servidor passar solicitações Hypertext Transfer Protocol (HTTP) a um programa externo e depois receber o resultado e enviá-lo ao browser. E posteriormente graças à criação de tecnologias que se tornaram bem difundidas como PHP, Java Server
Pages (JSP) e Servlets, Active Server Pages (ASP) e Active Server Pages .NET (ASP
.NET) (RIBEIRO et al., 2006).
Atualmente, no século 21, os sistemas web são aplicações difundidas, úteis, e que podem atender às mais variadas vertentes, seja para prover soluções para grandes
empresas, aplicações que visem o entretenimento ou até mesmo conectar pessoas ao redor do mundo através de redes sociais.
1.1 Software como Serviço – SaaS
Com o surgimento e posterior evolução das tecnologias que permitiram o desenvolvimento de sistemas web robustos e com a maturidade adquirida no desenvolvimento e engenharia de software ao longo dos anos, foi possível para empresas que comercializam software entregar aplicações aos clientes como um serviço provido através da internet sob um modelo de entrega de software denominado Software como Serviço (SaaS - Software as a Service). Esse tipo de aplicação possui um preço vinculado a ela que é cobrado ao usuário mediante o nível de uso do sistema. O preço pode ser alterado caso o usuário queira alterar seu pacote de serviços como, por exemplo, aumentar o espaço de armazenamento para a sua aplicação (CHEN; SORENSON, 2009).
Um provedor de softwares no modelo SaaS oferece sistemas especificamente desenvolvidos para serem hospedados e entregues pela internet para uma grande quantidade de clientes. Através desse modelo, os clientes têm a possibilidade de acesso a um conjunto de diferentes funcionalidades de um software via web e poderá escolher quais funcionalidades se encaixam melhor às necessidades de sua empresa. Em aplicações SaaS a administração do software é completamente feita pelo vendedor da aplicação não sendo necessário para a empresa cliente que hajam profissionais especialistas no ambiente da corporação (NITU, 2009).
As aplicações que seguem essa forma de funcionamento possuem por trás um contrato prévio entre cliente e fornecedor do serviço seguindo um modelo de subscrição. Dessa maneira o contrato prevê o pagamento mensal de um valor referente às funcionalidades utilizadas pelo cliente. Caso o usuário deseje aumentar o número de funcionalidades que ele tem acesso ou até mesmo possuir uma capacidade de armazenamento de informações maior, um novo acordo deve ser estabelecido entre as partes envolvidas. Essa maneira de fornecer sistemas é vantajosa para os clientes no que diz respeito aos custos de manutenção, suporte, hardware e pessoal especializado, pois os mesmos ficam sob responsabilidade do fornecedor do serviço. O cliente arca apenas
com os custos referentes à utilização das funcionalidades do sistema (NITU, 2009). Como a hospedagem da aplicação fica sob a responsabilidade do provedor do serviço, questões inerentemente voltadas a Tecnologia da Informação como, por exemplo,
backup, segurança, confiabilidade, integridade das informações e manutenção de uma
equipe responsável por essas questões, são resolvidas pelo provedor.
Nesse contexto, o mercado para soluções no modelo SaaS amadureceu entre 2005 e 2006, e teve como chave para sua ascensão novas tecnologias (NITU, 2009):
• Web 2.0: provocou uma nova onda de inovações no que diz respeito a negócios web. A capacidade de ler e escrever dados dinâmicos e em tempo real e a criação de uma nova classe de aplicações web a partir dessa capacidade habilitou a emergência do modelo SaaS.
• Rich Internet applications (RIAs): aplicações web com funcionalidades típicas de sistemas desktop. Essa tecnologia age enviando o processamento adequado para o cliente web, porém mantém informações como o estado do programa no lado do servidor.
• Service-oriented architecture (SOA): arquitetura usada em sistemas para empresas. Lógica desenvolvida pelo provedor do serviço.
• Computação nas nuvens: Tem como tecnologia por trás a virtualização. A disponibilidade dos dados e serviços em qualquer lugar e todo o tempo trouxe novas oportunidades para o modelo SaaS.
• Virtualização: Abstração de recursos como hardware e sistemas operacionais. Não é necessária a existência física de certos recursos no lugar onde a aplicação está sendo executada.
Pode-se destacar no modelo SaaS alguns níveis de maturidade relativos à camada de aplicação (HUDLI; SHIVARADHYA; HUDLI, 2009; KWOK; NGUYEN; LAM, 2008):
• Nível 1: Cada solução computacional gera uma aplicação, onde cada instância dessa aplicação é personalizada para um cliente e, específico e cada um deles possui uma cópia do sistema.
• Nível 2: Nesse nível o software não é personalizado, mas sim configurável e cada cliente possui um conjunto de opções de configuração.
• Nível 3: Nível onde a mesma aplicação suporta um grande número de inquilinos.
• Nível 4: Resolvida a falta de escalabilidade trazendo o sistema a uma situação de maior estabilidade, segurança, desempenho e confiabilidade. Através da definição do contrato entre cliente e provedor do serviço é possível ter acesso à aplicação no modelo SaaS e usufruir do sistema nos diferentes níveis e também das vantagens que o modelo traz. SaaS surge nos últimos anos como uma solução interessante, rentável e que emergiu no mercado de software.
1.2 Sistemas web offline
As aplicações web são úteis para algumas tarefas executadas pelo homem. Entretanto esse tipo de aplicação não será útil em todos os cenários possíveis. Uma situação que pode ser comum é a de um executivo desejando acessar informações da aplicação online da organização em que trabalha ou então tentando atualizar informações importantes no software, porém, ele está em uma viagem e não tem acesso a internet todo o tempo. Estando offline não será possível nem acessar os dados da aplicação web, nem atualizar informações na mesma. Em outras situações, há a probabilidade do usuário não ter acesso à aplicação, seja por uma sobrecarga de servidor ou até mesmo por serviços não confiáveis de internet, fatores esses que sinalizam a importância de ter acesso à aplicação estando sem conexão com a internet (SAIKAEW, 2009).
A capacidade de prover o funcionamento das aplicações web no campo offline é uma vertente nova e atualmente existem poucos sistemas e tecnologias disponíveis. Para que as ferramentas offline sejam aptas a proverem esse tipo de execução às aplicações
web, elas precisam ter algumas das funcionalidades que são inerentes com este tipo de
desenvolvimento. Tais funcionalidades formam a base da arquitetura dessas tecnologias e são elas:
• A capacidade do acesso local ao sistema web e às suas respectivas funcionalidades: o usuário deve ser capaz de ter acesso às páginas da aplicação através do endereço eletrônico delas, mesmo sem conexão com
a web. Essas páginas podem ser compostas por recursos como imagens e folhas de estilo que também devem estar disponíveis. Devem estar disponíveis também os meios para executar as ações da aplicação como os scripts responsáveis por isso.
• A manipulação de uma base de dados local que permita o armazenamento dos dados da aplicação e alterações feitas pelo usuário, enquanto a conexão com a internet não existir: os dados que alimentam a aplicação, seja ela de qual natureza for, precisam estar disponíveis e armazenados localmente. Dessa forma, a aplicação quando estiver sendo executada offline será alimentada por esta base de dados local que é baseada nos dados que residem no banco de dados original no servidor do sistema.
• A atualização da base de dados local: Caso haja alguma modificação da base de dados do servidor, a base de dados local precisa ser atualizada em algum momento, seja automaticamente pela aplicação, seja por uma solicitação do usuário clicando em algum botão do sistema que inicia essa ação.
Através do uso de ferramentas que provem o acesso offline às aplicações web, da implementação correta das funcionalidades supracitadas, seja no desenvolvimento de um novo sistema, seja na inserção dessas funcionalidades em um sistema já existente, é possível para os usuários desfrutar da capacidade de utilizar uma aplicação acessada via internet sem que a conexão com a grande rede esteja estabelecida.
O próximo capítulo apresenta uma descrição das principais tecnologias para o desenvolvimento de aplicações web offline seguida de um comparativo entre essas tecnologias sendo apresentada posteriormente a tecnologia escolhida para a utilização neste trabalho.
2 Google Gears e Microsoft Sync Framework
No contexto das ferramentas offline pode-se destacar duas tecnologias inerentemente capazes de proverem a possibilidade do desenvolvimento de aplicações
web offline. São elas a Interface de Programação de Aplicativos (API - Application Programming Interface) Gears desenvolvida pela empresa Google, e a plataforma
Microsoft Sync Framework da empresa Microsoft.
2.1 Google Gears
A API Gears do Google é um projeto de software que permite o desenvolvimento de aplicações offline através da inclusão de recursos aos browsers de internet. O projeto consiste em um conjunto de classes escritas em JavaScript que formam a API Gears. Realizando as chamadas às funções dessas classes do Google
Gears é possível tornar uma aplicação web em uma aplicação offline através de recursos
que vão desde a captura e armazenamento local dos arquivos pertinentes, à manipulação de um banco local de dados.
O Google Gears possui três classes principais para prover a capacidade de executar sem a conexão com a web. São elas o LocalServer, o DataBase e WorkerPool.
O Google Gears é dividido em módulos, onde cada módulo desempenha uma funcionalidade diferente. Esses módulos são representados por uma ou mais classes. Para o desenvolvimento deste trabalho, os módulos principais a serem considerados são:
Factory, LocalServer, DataBase, WorkerPool e HttpRequest. Além dessas classes o Google Gears possui módulos que não são usados no desenvolvimento deste trabalho,
pois não são necessários para a validação desta proposta, porém possui importância para o melhor entendimento do Gears como um todo. Esses módulos são: Blob, BlobBuilder,
2.1.1 LocalServer
O LocalServer é um módulo que funciona como uma memória cache para o armazenamento de recursos web como páginas html, imagens e folha de estilo em locais chamados de stores, e é controlado pela aplicação que o utiliza. Ele intercepta as solicitações HTTP e Hypertext Transfer Protocol secure (HTTPS) do navegador e serve os recursos aos quais essas solicitações dizem respeito localmente no disco rígido do usuário. Existem duas classes do LocalServer para que as aplicações possam gerenciar o armazenamento dos arquivos, sendo elas: ResourceStore e ManagedResourceStore. (GEARS API, 2010; KILANI, 2007).
O ResourceStore é como um recipiente de Uniform Resource Locator (URL) armazenadas localmente. Ele permite a captura de arquivos que somente são acessados através de uma URL, como uma imagem ou uma página HTML. Este recipiente pode ser povoado com estas URLs através das chamadas explícitas às funções JavaScript da classe e requer que o desenvolvedor faça uma aplicação que busque os elementos que se deseja colocar offline.
Já o ManagedResourceStore foi desenvolvido para armazenamento de um dado conjunto de recursos que são inter-dependentes. Por exemplo, os recursos responsáveis por inicializar uma dada aplicação podem ser armazenados no ManagedResourceStore. Os arquivos que serão armazenados através do ManagedResourceStore são listados em um arquivo denominado manifest file. Esse arquivo possui a listagem das URLs aonde podem ser encontrados os arquivos correspondentes na internet. De forma periódica o
LocalServer checa se houve alguma atualização no manifest file. Se houve alguma
alteração no arquivo, o LocalServer realiza automaticamente o download do novo conjunto de recursos listado no manifest file. (GEARS API, 2010).
Através do LocalServer o desenvolvedor que esteja usando a API Gears, pode fazer com que os arquivos da aplicação sejam acessados localmente e que dessa forma o usuário tenha acesso às páginas e recursos do sistema em questão não havendo a conexão com a internet.
2.1.2 DataBase
O DataBase é um módulo que possibilita que dados do usuário da aplicação sejam salvos na máquina em que a aplicação está executando. O banco utilizado é no formato SQLite 3, que permite execuções de instruções SQL para armazenamento e dá suporte a chaves primárias, view e transações (GEARS API, 2010; KILANI, 2007; SQLITE HOME PAGE, 2009). Os dados são salvos através do uso de requisições SQL ao banco de dados. Este módulo é formado por duas classes, sendo elas: classe
DataBase e a classe ResultSet.
A classe DataBase é responsável pelos métodos que manipulam o banco de dados, como executar uma requisição Structured Query Language (SQL) ou remover um banco de dados existente. Já a classe ResultSet contém o conjunto dos resultados de uma requisição SQL ao banco de dados do DataBase.
2.1.3 WorkerPool
O módulo WorkerPool do Gears é composto apenas por uma classe de mesmo nome, a classe WorkerPool, e permite que aplicações web executem os códigos
JavaScript em background, não bloqueando dessa maneira a execução do script
principal de execução. (GEARS API, 2010). Com o WorkerPool executando as operações em background, elas não vão interferir na interface do usuário porque os
scripts não acionarão a caixa de diálogo “unresponsive script” (script sem resposta) do
navegador de internet.
O WorkerPool funciona como um conjunto de processos e não como um conjunto de threads. (GEARS API, 2010). É possível criar mais de uma instância da classe WorkerPool, sendo que essas instâncias são totalmente independentes e só se comunicam com outros objetos da classe através do envio de mensagens.
2.1.4 Factory
Este módulo é formado pela classe Factory que é responsável por instanciar todas as outras classes da API Gears. Nas aplicações usando a API um objeto dessa classe deve ser criado primeiramente e através de uma instância desta classe é possível criar instâncias de todas as outras classes do Google Gears e então ter acesso às suas funcionalidades (GEARS API, 2010).
2.1.5 Outros módulos do Gears
Além dos módulos apresentados anteriormente, outros módulos responsáveis por realizarem tarefas mais simples ou até mesmo discretas compõem a API Gears. São eles o Factory, Blob, BlobBuilder, Canvas, Desktop, Geolocation e Timer.
O módulo HttpRequest implementa um subconjunto da especificação W3C
XmlHttpRequest e é responsável por realizar requisições HTTP de algum recurso web.
(GEARS API, 2010). Já o módulo Blob é um módulo composto pela classe de mesmo nome e é responsável por prover uma maneira de referenciar dados binários em aplicações web. A linguagem JavaScript possui um tipo de dados utilizado para construir strings de texto, porém não existe algo similar para dados binários. Esta classe atende a essa ausência. Os objetos dessa classe podem ser passados como parâmetro em vários métodos das classes do Gears e retornados também. Além dessa característica, os
Blobs são imutáveis, ou seja, os dados binários referenciados por um Blob não podem
ter seu conteúdo modificado diretamente (GEARS API, 2010).
O módulo BlobBuilder é composto pela classe com mesmo nome e é responsável por gerar objetos da classe Blob com um novo conteúdo. Fazendo uma analogia a uma classe específica da linguagem Java, os objetos dessa classe podem ser comparados aos objetos da classe StringBuilder (GEARS API, 2010).
O módulo Canvas é um módulo gráfico, representado pela classe Canvas, que fornece métodos capazes de manipular imagens. Inspirado no Canvas do HTML5 com métodos de codificar e decodificar arquivos de imagens, transformando-os ou montando-os a partir de dados binários representados por um Blob (GEARS API, 2010).
O Canvas do Gears não segue por completo a especificação do HTML5 Canvas, e por essa razão possui algumas pequenas diferenças.
O módulo Desktop é responsável por prover uma interface para acessar funcionalidades que tem a ver com a área de trabalho da máquina em que a aplicação está sendo utilizada. Um exemplo disso é a criação de um atalho (GEARS API, 2010).
O módulo Geolocation permite que uma aplicação web obtenha a posição geográfica da máquina do usuário mostrando os valores de latitude e longitude. Além da obtenção da posição geográfica estática da máquina é possível visualizar também a mudança de posição do usuário ao longo do tempo e ainda obter a última posição conhecida do usuário (GEARS API, 2010). Já o módulo Timer é baseado na especificação WhatWG Timer (WHATWG, 2010; GEARS API, 2010)
2.1.6 Arquitetura do Google Gears
No desenvolvimento da API Gears diversos estilos de arquitetura foram testados. Como resultado desses testes, em todas as aplicações com a capacidade de acesso offline desenvolvidas, os criadores da API tiveram que atentar às questões seguintes: isolamento da camada de dados, decisão de quais funcionalidades serão implementadas offline, decisão sobre a modalidade do aplicativo e sincronização de dados.
Em geral, aplicações web não costumam possuir uma camada de dados real. Porém quando um banco de dados local é criado para ser utilizado na sua aplicação, existirá um espaço reservado, por menor que seja, por onde os dados para armazenamento e os retornos para as requisições ao banco irão passar (GEARS API, 2010). Esse espaço pode ser denominado de camada de dados (Data Layer). Ainda nesse contexto pode-se levar em conta a existência de uma nova camada: a camada de troca de dados (Data Switch). Essa camada implementa a mesma interface que a camada de dados e é ela quem recebe de fato as solicitações da aplicação e decide quando escrever os dados localmente ou quando mandar os dados para o servidor. Seguindo essa linha de pensamento, pode-se pensar em duas camadas de dados distintas: a camada de dados do servidor (Server Data Layer) que irá se comunicar com o servidor
e camada de dados local (Local Data Layer) que irá realizar as operações com o banco de dados local. A Figura 1 mostra uma visão geral dessas camadas e seus possíveis relacionamentos:
Ainda que a aplicação não esteja estruturada a ponto de permitir a existência de uma camada de dados é possível isolar essa camada interceptando todas as chamadas enviadas ao servidor antes delas serem enviadas. Para a implementação deste tipo de funcionalidade todos os métodos e funções devem ser capturados e roteados para o local correto (GEARS API, 2010).
Outra questão importante a ser levada em consideração é modalidade da aplicação. Existem dois tipos de modalidade (GEARS API, 2010):
• Aplicação do tipo modal: Esse tipo de aplicação possui versões online e
offline distintas. São normalmente diferenciadas através de uma mudança
de interface. Nesse tipo de aplicação quando a aplicação está online as comunicações dela acontecem diretamente com o servidor e quando ela está offline acontecem com a base local.
• Aplicação do tipo modeless: A transição entre o modo online e o modo
offline acontecem através da mudança de estados e sem mudanças
significativas na interface do usuário. O usuário não precisa mudar de um estado para o outro, pois isso acontece automaticamente. Existe uma sincronização de dados em background quando o servidor está disponível e quando faz a transição do estado offline para o estado online.
Ambos os tipos possuem desvantagens. A principal desvantagem do tipo modal é que o usuário precisa lembrar-se de mudar do modo online para o modo offline. Se a internet estiver intermitente, o usuário deve escolher um modo para trabalhar ou então mudar de modo várias vezes durante esse tempo. Dentre as desvantagens do tipo
modeless estão o fato de que é uma maneira mais difícil de implementar e de que é
preciso ter cuidado com o consumo de recurso feito pela sincronização entre base de dados local e base de dados do servidor para não atrapalhar a execução normal da aplicação (GEARS API, 2010).
Uma terceira questão relevante é a sincronização dos dados. Para que a base local esteja de acordo com os dados e modificações feitas na base de dados do servidor, e vice-versa, é preciso que haja uma sincronização entre as duas. Existem duas estratégias de sincronização: a sincronização manual e a sincronização em background (GEARS API, 2010). Na sincronização manual, o usuário é quem decide em qual momento sincronizar os dados, acionando essa ação através do clique em um botão, por exemplo. Já na sincronização em background a aplicação realiza sincronização entre os dados locais e do servidor continuamente de tempos em tempos de maneira transparente ao usuário. Vale ressaltar que o Gears não possui classes específicas para tratar da sincronização dos dados e também não sugere o tipo de estratégia para realizar essa sincronização.
Dentre as várias questões envolvidas e maneiras de desenvolvimento de aplicações com a capacidade de executar offline discutidas nessa seção, é preciso analisar as necessidades de um determinado sistema e aplicar a as técnicas corretas para cada situação problema.
2.2 Microsoft Sync Framework
O Microsoft Sync Framework é uma plataforma de desenvolvimento que permite o acesso offline para aplicativos e a sincronização dos dados. Através do Sync
Framework é possível criar ambientes que utilizam a sincronização, integrando
qualquer aplicativo a dados de qualquer armazenamento e fazendo uso de qualquer protocolo de rede. (MSDN MICROSOFT, 2009). O Sync Framework foca na
sincronização dos dados, sendo os cenários offline uma das funcionalidades providas por esta plataforma. Para trabalhar com o conjunto de dados a serem sincronizados o
Sync possui um banco de dados SQL Server em uma versão compacta, capaz de guardar
esses dados e manipulá-los.
A documentação do Framework traz a seguinte definição ao apresentar uma visão geral da plataforma:
Ao usar a Estrutura de sincronização, os desenvolvedores podem criar ecossistemas de sincronização que integram qualquer aplicativo com dados de qualquer armazenamento usando qualquer protocolo em qualquer rede. Por exemplo, o software de PIM (gerenciamento de informações pessoais) pode usar a Estrutura de sincronização para propagar atualizações de dados de PIM para todos os participantes. Os aplicativos de negócios que compartilham dados, como documentos, podem usar a Estrutura de sincronização para garantir que todos os membros da equipe recebam atualizações de documentos e que todos os conflitos em atualizações simultâneas sejam tratados corretamente... (MSDN MICROSOFT, 2009).
Em se tratando da arquitetura do Microsoft Sync Framework pode-se dizer que a plataforma é composta de tecnologias, onde as principais são: Componentes principais do Sync Framework; Metadata Storage Service; Microsoft Sync Services for ADO.NET;
Sync Services for File Systems e Sync Services for FeedSync. Dentre essas tecnologias,
a específica para o desenvolvimento de aplicações offline é a Microsoft Sync Services
for ADO.NET que será descrita a seguir.
2.2.1 Microsoft Sync Services for ADO.NET
O Microsoft Sync Services for ADO.NET é um provedor de sincronização feito para o uso em aplicações web offline, onde os recursos da aplicação são armazenados localmente. O desenvolvimento em cima desta plataforma é realizado através das linguagens suportadas pela plataforma .NET da Microsoft. Através do uso da tecnologia é possível a sincronização dos dados conectando dois clientes do banco de dados SQL
Server 3.5 SP1, nativo da tecnologia, ou então conectando um cliente do SQL Server
Sync Framework, um banco de dados que use o Services terá a capacidade de trocar
informações com as outras bases de dados que sejam suportadas pelo Sync Framework. Esses serviços suportados podem ser desde serviços web a sistemas de arquivos. (MSDN MICROSOFT, 2009).
2.3 Comparativo Google Gears e Microsoft Sync Framework
Em linhas gerais, a plataforma Microsoft Sync framework trata de maneira mais detalhada a sincronização dos dados em si, focando na capacidade de atualizar uma base de dados a partir de outra. Já a API Gears do Google foca mais na capacidade de armazenar os arquivos da aplicação localmente e habilitar suas funções de forma offline. Neste contexto, a API Gears do Google melhor se adéqua à utilização neste trabalho, cuja proposta é voltada para a capacidade offline de execução das aplicações web, sendo dessa forma a tecnologia escolhida para ser utilizada.
O capítulo a seguir discorre a respeito da empresa parceira deste trabalho, bem como a respeito do módulo da aplicação, disponibilizada pela empresa parceira, que teve o modo offline adicionado.
3 Medicware Sistemas de Informática
Este trabalho foi desenvolvido através de uma parceria realizada com a empresa Medicware Sistemas de Informática. A Medicware é uma empresa baiana, localizada na cidade de Salvador, e atua no mercado de informática provendo soluções médicas para as mais variadas classes de instituições do ramo. Essas soluções contemplam desde pequenos consultórios médicos até grandes hospitais.
É válido ressaltar que a Medicware possui um hall de produtos que já são comercializados em território nacional e que se encontram em funcionamento nos seus diferentes clientes da área de saúde. Dentre esse produtos pode-se destacar o
SmartHealth, produto voltado para hospitais; o SmartClin, voltado para clínicas; o SmartLab, que possui como público alvo os laboratórios e o SmartDoctor
(MEDICWARE, 2010), aplicação web que funciona como um serviço web e que é acessado pelo cliente através de um navegador de internet.
A solução apresentada neste trabalho foi desenvolvida tendo a aplicação
SmartDoctor como alvo. Esta aplicação possui um menu de funcionalidades que
contemplam várias tarefas, dentre as quais pode-se destacar: o cadastro, remoção, busca e atualização de pacientes, prestadores de serviços e convênios médicos; o preenchimento e atualização do prontuário eletrônico de cada paciente; o gerenciamento completo do agendamento de consultas; o controle da unidade na qual o serviço está sendo realizado, funcionalidade essa que é útil para os clientes que possuem matriz e filiais. Dentre essas funcionalidades, o módulo de marcação de consultas do sistema de agendamento da aplicação foi escolhido para que tivesse parte de suas funcionalidades disponibilizadas ao usuário de maneira offline. Essa nova funcionalidade no sistema agrega valor a ele, trazendo uma realidade prática de visualização de informações numa aplicação web, ainda que a máquina do usuário esteja sem conexão com a internet.
3.1 SmartDoctor (Agendamento)
Num sistema de agendamento de consultas médicas, uma funcionalidade como realizar a marcação de uma consulta para um determinado paciente, em um determinado
horário e para um médico específico é intrínseca ao seu funcionamento. É essencial também a capacidade de visualizar os agendamentos realizados para cada médico, junto com as informações relevantes de cada consulta. Estas informações podem ser o paciente de cada horário, seu convênio médico, a data da consulta e, no caso da existência de mais de uma unidade da instituição usuária do sistema, a unidade para qual o agendamento foi marcado.
Como dito anteriormente, a aplicação escolhida da empresa parceira foi o
SmartDoctor e a funcionalidade que teve o acréscimo da capacidade de execução offline
foi o sistema de marcação de consultas do software.
O sistema de marcação de consultas funciona da seguinte maneira: na página inicial você tem acesso à utilização de três filtros: especialidade, médico e unidade. Esses filtros são parâmetros para uma pesquisa no banco de dados do sistema e o resultado dessa pesquisa é estruturado da seguinte maneira:
• Especialidade: retorna em uma tabela todos os médicos que possuem a especialidade solicitada na pesquisa, com o destaque para os turnos em que realizam atendimento e com os horários possíveis de atendimento, sejam eles livres ou ocupados por uma consulta.
• Médico: retorna um resultado semelhante ao anterior, porém não retorna os médicos de uma dada especialidade, mas apenas o médico solicitado na pesquisa.
• Unidade: retorna todos os médicos, com seus horários livres e ocupados, bem como os turnos de atendimento, que atendem na unidade médica especificada na pesquisa.
A Figura 2, a seguir, mostra um exemplo de uma pesquisa realizada através do filtro de especialidade.
Note que a pesquisa retorna os médicos “Glória Menezes”, “José Maia” e “Patrícia Pilar” que possuem a especialidade “ANGIOLOGIA”. É possível observar também os turnos livres que cada médico possui em cada dia. Por exemplo, no dia 28/12 “José Maia” tem horário livre pela manhã, enquanto “Glória Menezes” não tem horário livre nem pela manhã e nem pela tarde.
A Figura 3 já mostra uma pesquisa feita tendo como filtro o médico. Nesse resultado de pesquisa foi passado como parâmetro o nome da médica “Eva Wilma” e foram retornados os dias da semana com os respectivos turnos livres. Visualizando as células com preenchimento verde e com o nome “LIVRE” que ficam na coluna dos dias da semana e na linha que especifica a médica, é possível notar que a médica “Eva Wilma” possui as manhãs das segundas, terças, quartas e quintas livres. Essas células servem como link que abrem a tabela logo abaixo com os horários disponíveis de cada dia. Na Figura 3 estão sendo visualizados os horários disponíveis do dia 28 de dezembro de 2009.
Já na Figura 4, pode-se observar uma pesquisa com o filtro de unidade. Nessa pesquisa são listados os médicos “Ivete Sangalo” e “Patrícia Pilar” que atendem na “UNIDADE GARIBALDI”. Os horários disponíveis do dia 28 de dezembro também estão sendo mostrados. É possível observar também um agendamento feito para o horário das 15 horas para o paciente “ANDRE GOMES”, agendamento esse que pode
Figura 3: Pesquisa por Médico
ser realizado através do clique em uma célula com o nome “HORÁRIO DISPONÍVEL”.
Uma pesquisa pode ser feita também a partir de mais de um filtro. A Figura 5 mostra o resultado de uma pesquisa feita a partir da especialidade “ORTOPEDIA” e da “UNIDADE CANELA” como parâmetros de pesquisa:
A pesquisa a partir de mais de um filtro pode ser realizada não só a partir dos filtros de especialidade e de unidade e sim com qualquer combinação entre os três filtros existentes. É possível, por exemplo, realizar buscas fazendo uso dos filtros de médico e unidade ao mesmo tempo, médico e especialidade ou até mesmo por médico, especialidade e unidade.
O próximo capítulo apresenta a aplicação desenvolvido neste trabalho, mostrando como foi feito o projeto e arquitetura do sistema, bem como a descrição da sua implementação e funcionamento, além dos testes feitos na aplicação.
4 SmartDoctor Offline
Para estruturar a solução que valida o tema deste trabalho, primeiramente, uma empresa de sistemas de informática consolidada no mercado foi escolhida para atuar como parceria deste trabalho. Uma vez escolhida a empresa, ela foi contatada e a proposta foi feita e aceita. Essa empresa é a MedicWare Sistemas de Informática e entrou no trabalho fornecendo um de seus produtos de mercado como alvo do desenvolvimento da proposta.
O produto da empresa escolhido, o SmartDoctor, foi selecionado de acordo com o que se propõe este trabalho, sendo ele, portanto, uma aplicação inteiramente web e rodando sob o modelo de serviço SaaS. Escolhido o produto, ele foi analisado e uma funcionalidade específica dele foi eleita como alvo da solução. Essa funcionalidade no software é um sistema de agendamento de consultas médicas. Levando em consideração o fato de esse software ser um sistema web, numa realidade onde não haja conexão com a internet, a capacidade de visualizar os detalhes de uma consulta marcada como o horário do atendimento, paciente que será atendido, médico que irá consultar o paciente e o convênio do paciente, figura uma vantagem dessa aplicação em relação a outras e que se encaixa com os objetivos do trabalho.
Para disponibilizar sua aplicação, a empresa criou uma máquina virtual com o sistema operacional Microsoft Windows Server 2003, onde nesse sistema estava configurado o SmartDoctor com respectivo banco de dados, bem como seus arquivos de código-fonte. O desenvolvimento do SmartDoctor Offline foi feito através da implementação de arquivos JavaScript, bem como alterações no código-fonte do arquivo principal do módulo de agendamento.
Uma vez finalizado o desenvolvimento da aplicação, testes foram realizados a fim de verificar e ratificar o seu bom funcionamento. Cenários de teste foram pensados e postos em prática como a marcação de consultas prévias enquanto online, a mudança para a realidade offline e a posterior verificação da capacidade de visualizar esta mesma consulta. O sistema foi testado também em casos de busca de agendamentos com filtros como critérios de pesquisa, sendo essas consultas buscadas enquanto o software executava sem conexão com a web. A seção a seguir explica o projeto do SmartDoctor
4.1 Projeto
A proposta deste trabalho foi feita com o uso da tecnologia Google Gears que é uma API escrita em linguagem JavaScript. A aplicação SmartDoctor é uma aplicação construída com o uso de ASP e de PowerBuilder. A linguagem de script na qual a aplicação faz uso dentro dos códigos ASP é a linguagem VBScript e por isso essa linguagem também foi utilizada pela proposta dessa monografia. Outra linguagem utilizada foi a HTML para design de alguns elementos de layout. Além dessas linguagens, foram utilizados também elementos em Cascade Style Sheets (CSS) que definem alguns atributos gráficos dos elementos de layout.
Uma vez de posse de todas as informações e ferramentas necessárias para o desenvolvimento da aplicação, algumas questões foram analisadas a fim de fazer com que o desenvolvimento da aplicação estivesse de acordo com a arquitetura do Gears e contemplasse os requisitos básicos de uma aplicação web com capacidade offline. A primeira questão analisada foi decidir sobre a modalidade do SmartDoctor Offline. A aplicação possui características dos dois tipos de modalidade. Dentre as características, as seguintes são inerentes ao tipo modal:
• A versão online e a versão offline da aplicação são distintas; • O usuário pode mudar manualmente para o SmartDoctor Offline;
• O SmartDoctor Offline possui diferenças na interface de usuário que indicam a mudança da versão;
• Quando a aplicação está online ela se comunica com o servidor e quando está offline ela se comunica com a base de dados local;
• A atualização da base de dados local é acionada pelo usuário através do clique de um botão na interface gráfica da aplicação.
Já as características inerentes ao tipo modeless são:
• A aplicação detecta quando a conexão com a internet é perdida e faz a troca para o SmartDoctor Offline automaticamente;
• A aplicação detecta quando a conexão com a internet é restabelecida e faz a troca para o SmartDoctor também automaticamente.
Outra questão levantada foi o isolamento da camada de dados local da aplicação. Como o SmartDoctor realiza comunicação somente com a base de dados do servidor e o
dados local da aplicação é garantida. Dessa forma a comunicação com as duas bases de dados se processa de forma distinta sendo uma gerenciada pelo SmartDoctor e outra pelo SmartDoctor Offline.
Feitas as considerações a respeito dessas questões, foram levantadas quais funcionalidades iriam ser acrescentadas na aplicação e iriam constar no SmartDoctor
Offline. Essas funcionalidades são:
• Capturar as informações do banco de dados do servidor necessárias para a visualização das marcações realizadas e salvá-las localmente: para realizar essa operação é necessário que um nome de usuário e uma senha sejam fornecidos para o acesso posterior a essas informações. • Mudar a visualização da agenda do modo online para o modo offline,
mesmo que a conexão com a internet não seja interrompida: para essa operação é preciso que o fornecer o mesmo nome de usuário e a mesma senha informados na ação anterior.
• Trocar do modo online para o modo offline de forma automática caso a conexão com a internet seja interrompida: assim que a conexão com a web não estiver mais disponível, a aplicação solicitará o nome de usuário e a senha fornecida na captura dos dados do banco do servidor. • Atualizar as informações da base de dados local concernentes aos
agendamentos realizados: caso novos agendamentos tenham sido realizados desde a última vez em que as informações do banco do servidor foram capturadas elas serão atualizadas na base local.
• Realizar buscas dos agendamentos com base nos filtros de especialidade, médico e unidade: as informações capturadas até então no banco de dados local podem ser acessadas através de pesquisas com base nos filtros citados.
Feito o levantamento das funcionalidades do SmartDoctor Offline, a arquitetura da aplicação foi desenvolvida a fim de contemplar tais requisitos. Essa arquitetura será descrita na subseção a seguir.
4.1.1 Arquitetura
A arquitetura do SmartDoctor Offline foi criada com o intuito de o código da aplicação prover ao sistema as funcionalidades previstas da maneira mais organizada possível. Essa arquitetura pode ser visualizada em três camadas:
• Offline Manager Layer • Local Data Layer • View Layer
A Figura 6 mostra um esquemático da arquitetura do sistema:
Cada camada dessas é representada por arquivo(s) JavaScript contendo métodos pertinentes à camada e/ou por métodos isolados ou operações específicas localizados em um ou mais arquivos JavaScript e compostas por um ou mais módulos.
A Offline Manager Layer é a camada mais complexa do software e é composta pelos seguintes módulos:
• Gears Initialization • Connection Verify
• Mode Change
O módulo Gears Initialization é responsável pela inicialização da API Gears e de seus componentes que são utilizados na aplicação. Dentre esses componentes há a inicialização do objeto da classe Factory, que é responsável pela criação de todos os outros tipos de objetos; a inicialização do LocalServer e do store utilizado no sistema; do manifest file e do banco de dados local a partir da classe DataBase. Já o módulo
Connection Verify realiza a verificação da conexão com a internet periodicamente e
inicializa o processo de mudança do modo online para offline sempre que essa conexão é interrompida e do offline para o online quando é restabelecida. Essa mudança de modo é feita pelo módulo Mode Change, que muda a visualização do SmartDoctor para o
SmartDoctor Offline e vice-versa quando solicitado pelo módulo Connection Verify.
Outra camada menos complexa, mas não menos importante, é a Local Data
Layer. Essa camada faz a manipulação do banco de dados local realizando as operações
SQL necessárias nessa base de dados. Os módulos dessa camada são: • Local DataBase Manipulation
• Gears DataBase
O módulo Local DataBase Manipulation fica responsável por realizar a manipulação da base de dados local executando operações que selecionam informações específicas do banco de dados com base em filtros de pesquisa. Já o módulo Gears
DataBase representa de maneira abstrata o banco de dados local SQLite armazenado na
máquina do usuário do SmartDoctor Offline e, nesse caso específico, não possui linhas de código, métodos ou arquivos JavaScript que o representem e sim a própria base de dados em si.
A terceira camada da aplicação é a View Layer e é responsável pela interface gráfica do SmartDoctor Offline. Essa camada é composta apenas pelo módulo Offline
View Mount que engloba os métodos que montam a visualização do modo offline do SmartDoctor. Parte dessa visualização é montada após uma consulta no banco de dados
e por essa razão esse módulo se comunica com o módulo Local DataBase
Manipulation.
Uma vez explicada como a arquitetura do sistema foi concebida, será explicado na próxima subseção como a aplicação funciona e como ela foi implementada.
4.1.2 Funcionamento e implementação
Como explicado na seção 4.1.1 a arquitetura do SmartDoctor Offline é dividida em camadas e módulos. As seções que vêm a seguir, explicam como a aplicação funciona e como o seu código-fonte está estruturado de acordo com a arquitetura idealizada.
4.1.2.1 Processo de inicialização dos componentes
No início da execução do sistema de agendamento do SmartDoctor, o
SmartDoctor Offline verifica, de forma transparente ao usuário, se o Gears está
instalado no browser que ele está utilizando. Em caso negativo uma mensagem é mostrada na tela ao usuário orientando-o a instalar o Gears antes de executar essa aplicação. Em caso positivo a API é inicializada. Essa inicialização faz parte do módulo
Gears Initialization da camada Offline Manager Layer e é feita através do código do
arquivo gears_init.js, escrito em linguagem JavaScript e disponível aos desenvolvedores pela Google no site da API (GEARS API, 2010). Esse arquivo verifica primeiramente qual navegador de internet em que o software está sendo executado. Uma vez feito isso ele define o objeto que vai representar o Gears, que é nomeado
google.gears, e um objeto da classe Factory do Gears que é nomeado pelo rótulo google.gears.factory.
Através do google.gears.factory é possível instanciar todas as outras classes da API. Sempre que é necessário criar algum outro objeto dessas classes, basta realizar uma chamada à função google.gears.factory.create(), da classe Factory, e passar como parâmetro a string com o texto que identifica qual a classe da nova instância criada. Por exemplo, para criar uma nova instância da classe LocalServer é preciso chamar essa função da seguinte maneira: google.gears.factory.create(“beta.localserver”).
Na primeira vez que a aplicação é executada, a base de dados local ainda não existe. Essa base de dados só irá existir quando o usuário acionar a ação de captura dos dados informando um usuário e senha. Uma vez usuário e senha informados, o usuário pode clicar em um botão com o rótulo “OK”, como mostra a Figura 7:
Esse formulário pertence à camada View Layer no módulo Offline View Mount. Quando o usuário preenche o formulário com os campos necessários e clica no botão “Atualizar dados locais”, mais uma operação do módulo Gears Initialization é realizada. Essa operação recarrega a página principal da aplicação que verifica se a captura dos dados do servidor está sendo realizada pela primeira vez. Caso seja a primeira vez, toda a estrutura para manipulação, e a própria criação do banco de dados local, é realizada. Essa manipulação faz parte da camada Local Data Layer e do módulo
Local DataBase Manipulation, e o banco de dados em si do módulo Gears DataBase.
Essa estrutura começa a ser concebida com a criação da classe LocalServer, que é feita através de uma chamada à função offline(), localizada no arquivo start_offline.js. Essa função além de criar uma instância dessa classe cria o store utilizado na aplicação. O store criado foi do tipo ManagedResourceStore, pois ele permite o uso do manifest
file que descreve os recursos online que serão utilizados na sistema offline.
Após a chamada da função offline(), começa o processo de criação do banco de dados local. Primeiramente o banco propriamente dito é criado fazendo uma chamada à função google.gears.factory.create(“beta.database”). Depois são criadas as tabelas que vão existir no banco local. Essas tabelas são:
• Login: contém as informações de usuário e senha da aplicação;
• AGM: contém os dados do agendamento, como nome do paciente, médico que irá realizar o atendimento, horário do atendimento, convênio do paciente, a unidade de atendimento e a data da última sincronização; • ESP: possui informações a respeito de uma especialidade de médico,
como o nome da especialidade e seu código;
• ESM: faz a conexão entre um médico e a sua especialidade;
• PSV: possui informações a respeito de um prestador de serviço, como seu nome e código. No caso do SmartDoctor esse prestador de serviço poder ser um médico, um enfermeiro ou outro profissional que preste serviços à instituição médica. Já no SmartDoctor Offline esse prestador de serviços são apenas médicos.
• STR: guarda as informações de uma unidade de atendimento da instituição médica, como nome e código.
A tabela Login é criada localmente e não possui suas informações baseadas no banco de dados do servidor. Ela guarda as informações de usuário e senha relativas ao usuário da máquina que está executando a aplicação offline e é preenchida com os parâmetros digitados pelo usuário inseridos nos campos mostrados na Figura 7.
Uma vez criadas as tabelas e com a tabela Login já preenchida, o banco de dados do servidor é acessado a fim de extrair as informações necessárias das tabelas AGM, ESP, ESM, PSV e STR. O diagrama de entidade e relacionamento do banco de dados local que define suas tabelas e as relações entre elas pode ser visualizado na Figura 8.
