F
ACULDADE DEE
NGENHARIA DAU
NIVERSIDADE DOP
ORTOIntegração de Ferramentas de
Produtividade com Aplicações
Empresariais
Tiago Miguel da Cunha Gomes
D
ISSERTAÇÃOMestrado Integrado em Engenharia Informática e Computação Orientador: Prof. Dr. José António Faria
c
Integração de Ferramentas de Produtividade com
Aplicações Empresariais
Tiago Miguel da Cunha Gomes
Mestrado Integrado em Engenharia Informática e Computação
Aprovado em provas públicas pelo Júri:
Presidente: Professor Doutor Ana Cristina Ramada Paiva Arguente: Professor Doutor João Paulo Jorge Pereira
Vogal: Professor Doutor José António Rodrigues Pereira de Faria
Resumo
O buildONE é uma aplicação de software que se destina à gestão de sistema de trabalho contendo atividades com diferentes níveis de estruturação, desde projetos, até processo de work-flow, passando por processos emergentes semi-estruturados e com uma forte componente humana. Além do suporte à gestão do trabalho, a plataforma também inclui um conjunto de funcionalidades e ferramentas de suporte à gestão da documentação e à gestão da comunicação. Todos os recursos de informação geridos pela aplicação são arquivados em repositórios de informação centrais.
Este projeto teve como objetivo desenvolver um conjunto de novas interfaces para a plataforma buildONEque permitam ao utilizador aceder aos recursos disponíveis a partir de ferramentas de produtividade, como o caso do Microsoft Outlook ou de uma aplicação Desktop com integração com o Windows Explorer.
Para isso pretende-se especificar e implementar uma API que, através de Web Services, per-mitam aceder aos recursos geridos pela plataforma buildONE. Esta aplicação é desenvolvida uti-lizando a plataforma SharePoint. Esses recursos podem ser dados ou documentos armazenados em servidor. Desta forma, existe a possibilidade de estender estes recursos a outras plataformas, como é o caso dos dispositivos móveis, ou a outros sistemas operativos.
Por fim, de forma a validar os resultados obtidos, foi implementado um módulo para a aplica-ção buildONE, mais especificamente o módulo de Gestão de ordens de trabalho, onde os mecanis-mos de integração desenvolvidos são extensivamente utilizados.
Palavras-chave: SharePoint, Web Services, API, REST, Gestão de Manutenção, Ferramentas de Produtividade, Sistemas Empresariais
Abstract
buildONE is a software platform designed to manage work systems that contain activities with a different structural organization, like projects, workflow processes, or even emerging semi-structured processes with a strong human component. In addiction to supporting work manage-ment, this platform also includes a set of features and tools to support document and communi-cation management. All information resources managed by the applicommuni-cation are stored in central repositories.
The main goal of this dissertation is to develop a new set of interfaces to the buildONE plat-form. This way, users can access available resources from buildONE using productivity tools, like Microsoft Outlook or a Desktop application integrated with Windows Explorer.
For this it is intended to specify and implement an API using Web Services that gives acess to the resources managed by buildONE platform. This application is developed using the SharePoint platform and the resouces can be documents or information stored in central repositories. Thus, it will be possible to use these resources in other platforms, such as those available on mobile devices or in other operating systems.
In order to validate the obtained results, a new module to the buildONE application was implemented: the Work orders management module. In this module, the integration mechanisms developed during this project are extensively used.
Key words: SharePoint, Web Services, API, REST, Maintenance management, Productivity tools, Enterprise systems
Agradecimentos
Foram várias as pessoas que direta ou indiretamente contribuíram tanto ao longo deste ano, como em toda a minha vida para que este momento fosse possível. Gostaria desta forma de agra-decer a todos eles por este apoio.
Gostaria de dar um especial agradecimento ao meu orientador, Professor Doutor José António Faria, por todo o apoio, motivação e ajuda dada ao longo deste período da preparação e da disser-tação.
Gostaria também de agradecer aos engenheiros Hélder Marques e João Silva por toda a ajuda e disponibilidade ao longo do projeto.
Um especial agradecimento a todos os meus amigos, que direta ou indiretamente me deram apoio e motivação para que tudo isto fosse possível.
Por último, mas não menos importante, um agradecimento aos meus pais e à minha irmã por, ao longo destes anos, terem apoiado as minhas decisões e dado força para lutar mesmo nas piores alturas.
”You can’t have great software without a great team, and most software teams behave like dysfunctional families.”
Conteúdo
1 Introdução 1
1.1 Enquadramento e motivação . . . 1
1.2 Sistemas de trabalho baseados em conhecimento intensivo . . . 2
1.3 Aplicação piloto de demonstração e validação de conceitos . . . 2
1.4 Metodologia . . . 4
1.5 Estrutura do documento . . . 4
2 Estado da Arte 7 2.1 Trababalho relacionado . . . 7
2.1.1 Ferramentas de gestão de projetos . . . 8
2.1.2 Ferramentas de produtividade pessoal . . . 11
2.2 Síntese das ferramentas relacionadas . . . 15
2.3 Tecnologias utilizadas . . . 16
2.3.1 SharePoint . . . 16
2.3.2 OData . . . 17
2.3.3 REST Web Services . . . 20
3 Mecanismos de integração desenvolvidos 29 3.1 Objetivos . . . 29
3.2 MS Outlook . . . 31
3.2.1 Sincronização nativa entre o MS Outlook e uma aplicação SharePoint . . 31
3.2.2 Desenvolvimento de um Add-in . . . 31
3.2.3 Comparativo . . . 35
3.3 MS Explorer . . . 36
3.3.1 Network Drive . . . 36
3.3.2 Desenvolvimento de uma aplicação para Windows . . . 37
3.3.3 Comparativo . . . 39
4 Gestão de ordens de trabalho 41 4.1 Requisitos da aplicação . . . 41
4.2 Análise dos processos de trabalho . . . 42
4.2.1 Gestão dos incidentes e das Ordens de trabalho . . . 43
4.3 Modelo do domínio e o modelo de dados relacional . . . 44
4.4 Especificação das interfaces com o utilizador . . . 47
4.4.1 Aplicação web . . . 48
4.4.2 Aplicação Desktop e Add-in para MS Outlook . . . 50
CONTEÚDO
5 Arquitetura da aplicação piloto 55
5.1 Arquitetura dos REST Web Services para acesso a dados e documentos . . . 56 5.2 Arquitetura da aplicação Web . . . 58
6 Conclusões e trabalho futuro 61
6.1 Resultados obtidos . . . 61 6.2 Trabalho futuro . . . 62
A Anexo 1 63
Lista de Figuras
1.1 Processo de desenvolvimento em espiral . . . 4
2.1 Interface de gestão do workflow de um projeto na aplicação KanbanFlow . . . . 9
2.2 Interface web da aplicação Pivotal Tracker . . . 10
2.3 Diagrama de Gantt na aplicação Wrike . . . 10
2.4 Envio de uma tarefa como anexo de um email no Microsoft Outlook 2010 . . . . 11
2.5 Interface de calendário na aplicação Microsoft Outlook 2010 . . . 12
2.6 Interface web da aplicação Asana . . . 13
2.7 Interface Android da aplicação Pocket Informant . . . 13
2.8 Versão tablet da aplicação Astrid no sistema operativo móvel Android . . . 14
2.9 Estrutura de uma aplicação SharePoint . . . 17
2.10 Bibliotecas cliente e servidor [Pro10] . . . 19
2.11 Web Service REST sem estado . . . 21
2.12 Arquitectura de um WFC Data Service [Mic10b] . . . 22
2.13 Inteface REST SharePoint[Mic10a] . . . 23
2.14 Arquitetura REST do SharePoint[Mic12c] . . . 24
3.1 Arquitetura da aplicação . . . 30
3.2 Sincronização entre um calendário SharePoint e um calendário Outlook . . . 31
3.3 Adição de um novo separador à Ribbon do Microsoft Outlook . . . 32
3.4 Adição de um menu de contexto a um item do calendário . . . 33
3.5 Criação de um novo formulário no Outlook para edição e criação de compromissos 34 3.6 Utlização de uma Network Drive para mapeamento de uma biblioteca SharePoint 36 4.1 Workflowde uma ordem de trabalho preventiva . . . 43
4.2 Especificação do modelo de dados relacional . . . 45
4.3 Ligação entre uma tabela de um SGBD a uma biblioteca SharePoint . . . 46
4.4 Instanciação de um Template . . . 47
4.5 Formulário de consulta e configuração de um equipamento . . . 50
4.6 Navegação entre pastas e documentos no Windows Explorer . . . 51
5.1 Arquitetura geral do sistema . . . 55
5.2 Excerto da arquitetura da aplicação para acesso a dados e documentos . . . 56
5.3 Excerto da arquitetura da aplicação web . . . 58
A.1 Modelo de dados UML completo . . . 64
A.2 Listagens de Ordens de trabalho . . . 65
A.3 Formulário de criação e edição de Ordens de trabalho . . . 66
LISTA DE FIGURAS
A.5 Formulário de criação e edição de Equipamento . . . 67
A.6 Formulário de criação e edição de um equipamento . . . 68
A.7 Formulário de criação e edição de uma ordem de trabalho . . . 69
Lista de Tabelas
2.1 Operações para costumizar o resultado de uma consulta OData . . . 18 3.1 Comparativo entre os mecanismos nativos e o Add-in para o MS Outlook . . . 35 3.2 Mecanismos nativos de sincronização e o desenvolvimento de uma aplicação cliente 40 4.1 Comparativo entre aplicações nativas e HTML5 . . . 53
Abreviaturas e Símbolos
API Application Programming Interface C# C Sharp
CRUD Create, Read, Update, Delete EDM Entity Data Model
ERM Entity Relationship Model EUA Estado Unidos da América
IDE Integrated Development Environment iOS iPhone OS
LINQ Language Integrated Query MS Microsoft
oData Open Data Protocol OT Ordem de trabalho PC Personal Computer
REST Representational State Transfer SGBD Sistema de Gestão de Base de Dados SOAP Simple Object Access Protocol SO Sistema Operativo
SP SharePoint
URI Uniform Resource Identifier XML Extensible Markup Language
WCF Windows Communication Foundation WSDL Web Services Description Language
Capítulo 1
Introdução
Neste capítulo é feita uma introdução ao tema desenvolvido nesta dissertação. Será apresen-tado o enquadramento em que o projeto se encontra inserido, a motivação e os objetivos para esta dissertação, assim como a metodologia utilizada. Por fim, será descrita a organização deste documento.
1.1
Enquadramento e motivação
Esta dissertação teve por objetivo desenvolver um conjunto de mecanismos de integração que permitam a aplicações cliente executadas em diferentes plataformas aceder a recursos de informa-ção disponíveis em aplicações servidor corporativas.
Esses recursos podem ser de natureza diferente, como dados armazenados em sistemas de gestão de bases de dados, documentos arquivados em sistema de ficheiros ou em base de dados, ou mensagens de email com os respetivos documentos em anexo. Por seu lado, as aplicações cliente podem consistir em aplicações web, em extensões de aplicações já existentes, por exemplo, ferramentas de produtividade pessoal MS Office, ou em aplicações dedicadas, podendo o utilizador aceder à aplicação num computador pessoal ou num dispositivo móvel.
Em qualquer dos casos, trata-se de oferecer ao utilizador a possibilidade de consultar e atuali-zar os vários recursos de informação relativos a um dado assunto (por exemplo a um cliente, um projeto, um pedido de assistência técnica ou um processo de tratamento de reclamação) através da mesma interface, independentemente da natureza do recurso (dados, documentos e mensagens) e da aplicação cliente (web, integrada noutras ferramentas ou dedicada). Por exemplo, um utilizador que utilize o Outlook como o seu organizador pessoal poderá fazer a sincronização do seu calen-dário pessoal com o calencalen-dário disponível na plataforma web, assim como criar e editar novos compromissos que serão sincronizados entre ambos os calendários. É ainda possível organizar os seus emails pessoais e profissionais em pastas que serão também sincronizadas com os repositó-rios de dados oferecidos pela plataforma. Passa assim ser possível executar estas tarefas através do Outlook sem a necessidade de abrir a plataforma web. De forma semelhante, o mesmo utiliza-dor poderá mapear para pastas disponíveis no seu explorautiliza-dor de ficheiros documentos disponíveis
Introdução
em base de dados no servidor e sujeitos a mecanismos de controlo de acessos mais robustos do que os oferecidos nas pastas partilhadas, sendo ainda possível oferecer funcionalidades acresci-das de pesquisa, indexação ou a adição de informação aos itens sincronizados através de novos formulários.
1.2
Sistemas de trabalho baseados em conhecimento intensivo
Este tipo de funcionalidades é particularmente importante no contexto dos sistemas de trabalho baseados em conhecimento intensivo normalmente associados às atividades e serviços de alto valor acrescentado.
Por sistema de trabalho entende-se um conjunto de pessoas e recursos que tem a seu cargo a execução de um conjunto de processos e atividades afins. Por sistema de trabalho baseado em conhecimento intensivo entende-se um sistema de trabalho onde a boa execução das atividades e dos processos depende, em grande medida, do conhecimento tácito dos vários intervenientes na sua execução, normalmente técnicos especializados no domínio de aplicação[Ire06]. O modelo de gestão das atividades baseadas em conhecimento intensivo é diferente do modelo de gestão dos processos operacionais de rotina. Os procedimentos de execução destes processos podem ser padronizados e sistematizados e, portanto, a sua gestão pode ser automatizada através de siste-mas e aplicações do tipo gestão de workflow[AC06]. O mesmo não acontece com as atividades baseadas em conhecimento intensivo pois, pela sua própria natureza, estas atividades não obede-cem a procedimentos de execução rígidos e, muitas vezes, têm um caráter emergente, isto é, as ações a executar vão sendo decididas à medida que o processo avança e mais informação vai sendo conhecida sobre o processo.
Outras caraterísticas fundamentais do trabalho baseado em conhecimento intensivo residem no facto de normalmente envolverem a manipulação de informação com diferentes níveis de estrutu-ração, por exemplo, dados em base de dados e documentos, e de terem um caráter colaborativo uma vez que, durante a execução do processo, ocorrem múltiplas interações entre os vários inter-venientes, umas com caráter formal e outras informais.
Os maiores ganhos de produtividade nos processos de negócio foram atingidos por formali-zação dos processos para a gestão dos fluxos de trabalho que passaram a ser feitos através do computador[CH06][SWS04].
1.3
Aplicação piloto de demonstração e validação de conceitos
Uma vez desenvolvidos os mecanismos de integração, na segunda parte da dissertação foi analisado e implementado um módulo de uma aplicação de suporte a um sistema de trabalho baseado em conhecimento intensivo, nos moldes enunciados acima, e onde os mecanismos de integração são extensivamente utilizados.
Tratou-se, concretamente, do módulo de Gestão de Ordens de Trabalho da aplicação buil-dONE.
Introdução
O buildONE é uma aplicação de software que inclui um conjunto de módulos que suportam o conjunto de atividades relativos à gestão técnica de instalações complexas, nomeadamente:
• Gestão da manutenção; • Gestão da subcontratação; • Gestão da energia; • Gestão de empreitadas.
Por seu lado, o módulo de gestão de manutenção oferece como principais funcionalidades: • Planeamento da manutenção;
• Controlo da execução das ordens de trabalho preventivas e curativas; • Avaliação do desempenho e reporting.
As aplicações de gestão da manutenção tradicionais são essencialmente aplicações onde a informação se encontra armazenada em base de dados com capacidade de associar documentos aos equipamentos, como por exemplo manuais ou instruções de trabalho.
No caso das aplicações industriais, em que existe uma equipa interna dedicada à gestão da manutenção, esta abordagem é a mais adequada. Já no caso da gestão da manutenção de edifícios, a situação é significativamente diferente porque a grande maioria dos trabalhos são subcontratados e, como tal, a maioria da comunicação entre os vários intervenientes nos processos de manuten-ção processa-se através de mensagens de correio eletrónico, uma vez que os vários atores dos processos não partilham o mesmo sistema de informação. Por outro lado, nestas instalações, não existe normalmente uma pessoa exclusivamente dedicada à gestão da manutenção. O responsável pela manutenção desdobra-se normalmente por várias outras funções e responsabilidades como a gestão de energia, a gestão de empreitadas e obras de beneficiação, a supervisão das operações correntes (de limpeza e segurança por exemplo) e a gestão da ocupação dos espaços.
Devido à multiplicidade de responsabilidades e de tarefas que tem de executar, é difícil a este responsável manter um sistema de gestão da manutenção formal. Como consequência, os processos são menos estruturados do que em ambiente industrial e são geridos mais com base na experiência e sensibilidade do gestor do que em rotinas sistematizadas.
Além disso, pode mesmo ser difícil à entidade detentora das instalações impor procedimentos normalizados aos seus prestadores de serviços. Em vez disso, e pelo contrário, é a organização que subcontrata a ter de se adaptar aos procedimentos dos seus vários fornecedores que, normalmente, têm já os seus próprios sistemas de gestão de qualidade internos consolidados com os respetivos procedimentos de controlo e templates. Nestas condições, é fundamental que o sistema de apoio ao Gestor da Manutenção seja muito flexível por forma a permitir-lhe manter o controlo dos tra-balhos mas sem impor procedimentos rígidos. Em particular, o sistema deverá permitir lidar de uma forma integrada com os dados, documentos e mensagens envolvidos na execução dos vários
Introdução
trabalhos de manutenção. Além disso, a gestão desses processos no sistema não deverá implicar uma sobrecarga de trabalho significativa para o Gestor.
1.4
Metodologia
A metodologia utilizada no desenvolvimento das várias aplicações ao longo desta dissertação foi o modelo em espiral[B86].
Figura 1.1: Processo de desenvolvimento em espiral
Este processo de desenvolvimento de software é iterativo e incremental, sendo que consiste no desenvolvimento de novas versões onde são adicionadas mais funcionalidades e correção de erros sobre versões anteriormente desenvolvidas.
Para isso, este modelo apresenta um conjunto de etapas que são repetidas até à finalização do produto. Tal como pode ser observado na figura 1.1, inicialmente são definidos os requisitos necessários para a versão a desenvolver. De seguida passa-se à especificação e desenho do sistema de forma a incluir as novas funcionalidades adicionadas nessa versão, seguindo-se a etapa de codificação. Por fim, é lançada uma versão piloto dessa aplicação para testes. O ciclo de vida do desenvolvimento de uma versão é repetido até à versão final do produto.
1.5
Estrutura do documento
A dissertação está organizada em 5 capítulos, para além da introdução.
O capítulo2apresenta o estado da arte sobre ferramentas de produtividade pessoal e sobre as tecnologias de base utilizadas nas ferramentas de integração.
No capítulo3são apresentadas as tecnologias e ferramentas de integração desenvolvidas, com destaque para o Add-in desenvolvido para o MS Outlook e a aplicação de sincronização para MS Explorer.
Introdução
O capítulo4apresenta a análise funcional e especificação do módulo de gestão de ordens de manutenção, concretamente:
• O modelo do domínio e o modelo de dados relacional;
• A análise dos processos de trabalho relativos à gestão dos incidentes e das ordens de trabalho preventiva e curativas;
• A especificação das interfaces com o utilizador da aplicação web, das aplicações desktop e das aplicações móveis.
O capítulo5apresenta a arquitetura da aplicação piloto que foi implementada.
Por fim, o capítulo 6 resume os principais resultados alcançados ao longo da dissertação e apresenta as perspetivas de desenvolvimento.
Capítulo 2
Estado da Arte
Neste capítulo é feita uma revisão do estado da arte. Serão apresentadas algumas ferramentas de gestão de projetos e ferramentas de produtividade pessoal assim como será feita uma análise mais geral dessas ferramentas de modo a verificar quais os pontos fortes e os pontos a evitar na construção ou na integração com ferramentas deste tipo. Por fim, serão analisadas as tecnologias base utilizadas no desenvolvimento das ferramentas de integração, como é o caso do protocolo OData e dos Restful Webservices.
No caso desta dissertação, o desenvolvimento de um webservice tem como objetivo aceder à informação proveniente de um website desenvolvido com a plataforma SharePoint utilizando uma API baseada em REST. No caso de uma aplicação desenvolvida em SharePoint, mais espe-cificamente no âmbito desta dissertação a aplicação buildONE, existe a necessidade de aceder a dados e documentos provenientes dessa aplicação. Os dados são objetos que se encontram arma-zenados numa base de dados relacional, enquanto que os documentos são ficheiros (por exemplo ficheiros MS Word, MS Excel, entre outros) provenientes de uma biblioteca SharePoint, onde são armazenados no SharePoint File System.
Em ambos os casos é utilizado o protocolo OData em conjunto com uma API baseada em REST de forma a fornecer os dados disponíveis no formato XML ou JSON. O formato em que os dados são apresentados é escolhido pela aplicação cliente, de acordo com a sua necessidade ou preferência.
A especificação desta API tem como objetivo poder criar um conjunto de aplicações, ou inte-grar com aplicações já existentes, para que possam aceder a dados e documentos de uma aplicação SharePoint independentemente da plataforma utilizada (Desktop, Smartphone, Web) e do sistema operativo (Windows, Linux, Android, Windows Phone).
2.1
Trababalho relacionado
Com tem vindo a ser referido, um dos objetivos desta dissertação é oferecer ao utilizador a possibilidade de aceder e manipular dados e documentos existentes numa ferramenta empresarial corporativa nas ferramentas de produtividade pessoal utilizadas no seu dia-a-dia do utilizador.
Estado da Arte
Estas ferramentas de produtividade podem ser de diversos tipos e encontrarem-se disponíveis em várias plataformas e vários sistemas operativos.
Desta forma foi necessário analisar várias ferramentas de produtividade, sendo que esta análise foi dividida em dois tipos de ferramentas:
• Ferramentas de Gestão de Projetos; • Ferramentas de Produtividade Pessoal.
Por vezes é difícil fazer um diferenciação entre este tipo de ferramentas e existem conceitos e funcionalidades que são comuns. Para ambos os casos, estas ferramentas podem estar disponíveis em variadas plataformas de forma a responder a diferentes necessidades. É possível aceder a estas ferramentas através de uma página web num navegador, utilizando aplicações nativas para dispositivos móveis e aplicações web adaptadas para dispositivos móveis, ou ainda através de aplicações desktop para ser utilizadas num computador pessoal.
2.1.1 Ferramentas de gestão de projetos
As ferramentas de gestão de projetos ajudam a planear, organizar, gerir e estimar recursos para o desenvolvimento de um projeto. Dependendo da complexidade da ferramenta, estas também podem ser ferramentas colaborativas, de gestão de documentação e servir de meio de comunicação entre os vários elementos da equipa. As ferramentas de gestão de projetos são utilizadas desde projetos de pequenas dimensões a grandes projetos.
2.1.1.1 KanbanFlow
KanbanFlowé uma ferramenta de gestão de projetos embora também possa ser utilizada como uma ferramenta de produtividade pessoal. Esta ferramenta caracteriza-se pela sua simplicidade. Isto faz com que o processo de adicionar e gerir as várias tarefas se torne bastante simples e efici-ente. A interface principal do KanbanFlow encontra-se dividida em quatro secções que permitem gerir o workflow do processo ao longo do tempo e saber facilmente qual a sua situação atual[Kan]. Essas quatro secções são:
• To-do: Todas as tarefas que estão por fazer são colocadas nesta secção;
• Do today: Nesta secção são colocadas as tarefas que têm de ser efetuadas no próprio dia, mas que ainda não foram começadas;
• In progress: Todas as tarefas que estão a ser realizadas são colocadas nesta fase no momento em que são iniciadas;
• Done: Quando uma tarefa é concluída, será colocada nesta secção.
Para alterar o estado em que uma tarefa se encontra, basta utilizar a funcionalidade de "arrastar e largar", tornando este processo bastante simples e intuitivo. Uma tarefa pode ser dividida em sub-tarefas. No entanto, todas as sub-tarefas têm de estar na mesma secção que a tarefa da qual são
Estado da Arte
descendentes. No KanbanFlow é possível atribuir uma cor a uma tarefa. Encontram-se disponíveis sete cores (vermelho, amarelo, verde, azul, laranja, roxo ou branco). Este sistema pode ser útil para definir a prioridade das tarefas. No entanto a cor a atribuir fica ao critério do utilizador ou pode ser definida entre os elementos da equipa.
Os projetos criados no KanbanFlow podem ser individuais ou colaborativos. É possível adici-onar mais utilizadores a um projeto através do seu email e desta forma torná-lo colaborativo. Num projeto colaborativo, todos os membros da equipa podem alterar o estado das tarefas em tempo-real e todas as alterações ficam visíveis para os restantes elementos. Para cada tarefa é atribuído um utilizador responsável.
Figura 2.1: Interface de gestão do workflow de um projeto na aplicação KanbanFlow
2.1.1.2 Pivotal Tracker
Pivotal Tracker é uma ferramenta web usada por programadores e gestores de projeto para planear e acompanhar os seus projetos [Bla09]. À semelhança de outras aplicações de gestão de projetos, as tarefas passam por vários estados desde o momento em que são introduzidas até que são terminadas. No caso do Pivotal Tracker, temos presentes os estados Current, Backlog e IceBox.
Para cada tarefa é possível definir o responsável, adicionar uma descrição, palavras-chave, o tipo de tarefa, a sua prioridade e ainda o número de pontos. Este número de pontos é a estimativa de tempo, numa escala definida pela equipa, que a tarefa vai demorar a ser concluída. No Pivotal Trackeré introduzido o conceito de "Velocidade". Esta velocidade é definida pela equipa e ajuda a perceber se a atribuição de tarefas para uma iteração, em função do número de pontos das tarefas, se encontram dentro da velocidade de desenvolvimento da equipa. Desta forma é possível fazer melhores estimativas com base nas iterações anteriores.
Esta ferramenta é colaborativa e transparente. Todos os elementos da equipa sabem no que os outros estão a trabalhar, quais as sus prioridades e compromissos. Todas as alterações são vistas instantaneamente sem a necessidade de atualizar a página [Niv08]. Existe ainda um sistema de notificações por email. Sempre que uma tarefa é atribuída é enviado um email para o seu
Estado da Arte
responsável, da mesma forma que, sempre que uma tarefa é terminada é enviado um email para o responsável pelo projeto (project manager).
Esta ferramenta encontra-se disponível numa versão web e também numa aplicação nativa para dispositivos móveis com o sistema operativo móvel iOS.
Figura 2.2: Interface web da aplicação Pivotal Tracker
2.1.1.3 Wrike
Também inserida na categoria de aplicação de gestão de projetos, Wrike é uma aplicação que se encontra disponível numa versão web e também para dispositivos móveis Android e iOS[Wri]. Na sua versão web esta ferramenta permite a uma equipa partilhar os seus projetos de forma a que todos os elementos tenham acesso às suas tarefas. À semelhança de outras aplicações, é possível definir um estado para as tarefas (ativo, cancelado, deferido ou anulado) bem como a sua prioridade (baixa, média ou elevada). As tarefas podem ser atribuídas a um responsável.
Os projetos podem ser divididos por pastas e também podem ser criados sub-projetos. A utilização de pastas para organizar os projetos faz com que o utilizador possa utilizar conceitos já conhecidos da sua utilização num computador e transpondo estes conceitos para a aplicação a sua utilização torna-se mais simples e intuitiva.
De forma a dar uma visão geral do projeto, esta aplicação permite alternar entre várias vistas distintas, incluindo a visualização num diagrama de Gantt.
Estado da Arte
2.1.2 Ferramentas de produtividade pessoal
A maior parte das pessoas tem mais tarefas para fazer do que aquelas que realmente são ca-pazes de gerir. Para tal, uma ferramenta de produtividade pessoal ajuda as pessoas a priorizar as suas tarefas, e desta forma, aumentar a sua qualidade de vida. Este tipo de ferramentas ajudou a substituir a agenda pessoal e como tal é possível fazer uma gestão simples das tarefas, reuniões ou compromissos pessoais. Dependendo da complexidade da ferramenta, pode também ser possível fazer uma gestão completa das contas de email ou dos vários contactos associados.
2.1.2.1 Microsoft Outlook
O Microsoft Outlook, ou apenas Outlook, é uma ferramenta de gestão de informação pes-soal desenvolvida pela Microsoft e faz parte integrante da suite de produtividade Microsoft Of-fice[Micb].
Nesta ferramenta encontramos presente o Email, Calendário, Tarefas e Contactos. Nestes grupos podemos realizar operações específicas, mas que oferecem integração com as restantes.
Figura 2.4: Envio de uma tarefa como anexo de um email no Microsoft Outlook 2010
• Email: No Outlook está presente um cliente de email. Aqui, é possível adicionar várias contas de email de vários serviços de email, como por exemplo @hotmail.com, e desta forma fazer uma gestão completa das várias contas de forma simples. Dentro da aplicação do Outlook é possível adicionar tarefas, contactos, eventos (entre outros), a um email e desta forma o destinatário pode fazer a importação para a sua conta.
• Calendário: O calendário permite organizar e ver os vários compromissos e reuniões que estão agendadas. Estão disponíveis várias vistas que permitem ter uma perspetiva diferente da agenda pessoal. Desta forma é possível ver os compromissos que estão agendados para o próprio dia, para a semana ou para o mês.
No calendário não é possível ver as tarefas criadas; apenas os compromissos são considera-dos.
• Tarefas: É possível criar uma lista de tarefas e também atribuí-las a outras pessoas (res-ponsáveis). As tarefas têm definida uma prioridade (baixa, média ou elevada). Para cada tarefa é possível definir uma notificação que é mostrada assim que a data de realização se aproxima. As tarefas podem ser agrupadas de forma temporal e assim saber quais as que se vão realizar mais brevemente.
Estado da Arte
• Contactos: Aqui é possível gerir todos os contactos das contas associadas. Os contactos são utilizados no Outlook para enviar emails, atribuir tarefas ou mesmo partilhar compro-missos. É ainda possível criar grupos de contactos e desta forma partilhar a informação mais facilmente com as pessoas desse grupo.
O MS Outlook permite ainda a adição de Add-ins. Os Add-ins para Outlook são programas desenvolvidos na linguagem de programação C# que permitem a adição de novas funcionalidades, automatizar rotinas do utilizador ou substituir algumas funcionalidades já existentes no Outlook. Os Add-ins oferecem uma integração total com a ferramenta e desta forma os utilizadores traba-lham no sistema a que já estão habituados.
Figura 2.5: Interface de calendário na aplicação Microsoft Outlook 2010
2.1.2.2 Asana
Criada pelo co-fundador do facebook Dustin Moskovitz e por Justin Rosenstein [G11], Asana é uma ferramenta web que permite a criação de uma lista de tarefas. Essa lista de tarefas pode ser utilizada de forma pessoal ou partilhada com uma equipa. Nesta aplicação estão presentes os conceitos de workspace, projetos e tarefas. Uma equipa partilha um workspace, que por sua vez contêm projetos. Os projetos contêm as várias tarefas. A criação de uma tarefa é feita de forma simples, sendo também possível adicionar comentários, notas, ficheiros e tags associados à mesma. Quando uma tarefa é alterada, os vários elementos que estão envolvidos são notificados através de email.
Esta aplicação oferece uma interface simples e intuitiva, no entanto a gestão das tarefas pode tornar-se também limitada pois não é possível definir prioridades para as tarefas além da ordem com que aparecem na lista.
Estado da Arte
Figura 2.6: Interface web da aplicação Asana
2.1.2.3 Pocket Informant
Pocket Informanté uma aplicação web que permite a criação de tarefas e eventos. Encontram-se também disponíveis aplicações nativas para os sistemas operativos móveis Android e iOS. Este serviço permite a sincronização dos vários elementos criados entre as várias plataformas. É pos-sível importar tarefas de outros serviços externos, como o calendário da Google.
As tarefas e os eventos têm uma data associada, sendo possível visualizá-los no calendário inte-grado na ferramenta. As tarefas também podem ser divididas por pastas e desta forma manter os conteúdos organizados.
Nas aplicações móveis [Web13][Sol13] é possível receber notificações de sistema relativas aos próximos eventos e tarefas que estiverem agendados.
(a) Interface Smartphone (b) Inteface Tablet
Figura 2.7: Interface Android da aplicação Pocket Informant
2.1.2.4 Astrid
Astrid é outra aplicação que pode ser utilizada para fazer a gestão de listas de tarefas. Esta aplicação encontra-se disponível na forma de aplicações móveis para Android e iOS, com versões adaptadas a tablet em ambos os sistemas, e também numa aplicação web que pode ser acedida através de qualquer browser.
Estado da Arte
Essas cores representam a sua importância, sendo que a cor vermelha representa uma tarefa de alta prioridade (ou mais importante) e a cor azul as tarefas de menor importância.
Todas as listas são sincronizadas para um servidor central de modo a ter todas as tarefas atualiza-das nas várias plataformas em que o serviço se encontra disponível. Também é possível partilhar lista de tarefas com outras pessoas através do seu email.
São também gerados grupos de forma automática que organizam as tarefas de acordo com o seu estado e com a data em que se vão realizar. São criados grupos para as tarefas ativas, para as tarefas que tem data marcada para o próprio dia, as recentemente modificada, entre outros. Sempre que uma tarefa se aproxima da data em que tem de ser realizada, é enviado um email para as pessoas que a podem visualizar.
Esta aplicação apresenta uma interface bastante robusta e intuitiva. São utilizados vários elementos nativos das próprias plataformas móveis de modo a respeitar os seus padrões de desenho[Dev13][Inc13].
Figura 2.8: Versão tablet da aplicação Astrid no sistema operativo móvel Android
2.1.2.5 Dropbox
Dropbox é um serviço de alojamento de ficheiros na "cloud"[Dro]. Este serviço permite a criação de ficheiros e pastas, sendo que também é possível recuperar ficheiros graças ao seu con-trolo de versões. A Dropbox oferece um conjunto de aplicações cliente que permitem o acesso a todos os ficheiros. Estes encontram-se sincronizados entre as várias aplicações, uma vez que se encontram alojados num servidor central - cloud.
No caso da aplicação para PC-Desktop, esta oferece um integração total com o sistema ope-rativo Windows. Assim que o utilizador copia um ficheiro para a pasta relativa ao programa, este é armazenado automaticamente em servidor. De forma semelhante funcionam todas as tarefas comuns sobre os ficheiros e pastas, tal como "mover", "apagar", "copiar". Todas estas tarefas são efetuadas numa pasta no computador pessoal mas que se encontra sincronizada com os repositó-rios centrais.
Estado da Arte
Além da interface Web e da aplicação Desktop para Windows, existem também aplicações para outros sistemas operativos (Mac OS, Linux), bem como aplicações para sistemas operativos móveis como é o caso do Android, iOS, Symbian, BlackBerry OS e MeeGo Harmattan.
Este serviço foi fundado em 2007 e atualmente é um dos mais populares na área de arma-zenamento de dados online. À semalhança da Dropbox, existem vários serviços, todos eles com características de sincronização idênticas como é o caso do Google Drive, SkyDrive ou CouldPT.
2.2
Síntese das ferramentas relacionadas
Das várias ferramentas analisadas é possível retirar algumas características importantes na construção de uma ferramenta de produtividade e também alguns pontos que devem ser evitados. Desta forma como principais pontos positivos temos:
• Sincronização entre várias plataformas: A sincronização entre as várias plataformas em que a ferramenta está disponível torna-se de extrema importância. Desta forma é possível aceder aos mesmos dados, editá-los ou apagá-los e esta informação encontra-se sempre sincronizada no serviço.
• Sistema de cores para as prioridades: Um aspecto importante na definição de tarefas numa ferramenta deste tipo é o facto de poderem ser definidos vários tipos de prioridades. Em algumas ferramentas estas prioridades são identificadas por cores e este sistema ajuda a fazer uma visualização mais rápida e simples do estado atual da agenda ou do projeto. • Visualização de tarefas no calendário: Em algumas ferramentas é possível visualizar as
várias tarefas que estão atribuídas num calendário. É ainda possível aplicar filtros de forma a escolher as datas das tarefas a mostrar (próprio dia, semana, mês). É importante dar alternativas ao utilizador de forma a que os dados possam ser visualizados em diferentes vistas de acordo com as suas preferências.
• Ver em que estado a tarefa se encontra: Em algumas ferramentas de gestão de projetos, é possível gerir facilmente o workflow do processo e visualizar facilmente o estado em as várias tarefas se encontram. Nas ferramentas de produtividade pessoal, também é possível criar grupos de tarefas de acordo com o estado em que estas se encontram.
• Adição de novas funcionalidades à ferramenta: No caso do Outlook é possível adicionar novas funcionalidades através da utilização de Add-ins. Desta forma é possível aproveitar o que de melhor já existe nesta ferramenta sem a necessidade de criar uma nova aplicação de raiz.
A apontar como principais pontos negativos estão:
• Problemas de usabilidade: Um dos problemas mais recorrentes em algumas aplicações deste tipo são os problemas de usabilidade. Os problemas de usabilidade podem ser de
Estado da Arte
vários tipos e ter diferentes consequências. No caso das aplicações móveis um problema encontrado é a falta de feedback para o utilizador no momento de tomar determinadas ações. Isto faz com que seja necessário clicar em determinados objetos sem saber qual a sua função. Também são encontrados problemas de falta de consistência entre algumas ações realizadas. • Limitação na sincronização com outros serviços: Muitas destas aplicações apresentam algumas limitações no momento em que se pretende sincronizar o conteúdo ou importar dados de outros serviços. Algumas delas não apresentam qualquer forma de sincronizar o conteúdo entre as várias ferramentas. No momento em que se pretende importar conteúdo de outros serviços externos, geralmente apenas está disponível a opção de importar a partir do calendário da Google.
• Limitação na adição de novas funcionalidades: Ao contrário do que se verifica com o Outlook, as aplicações analisadas ficam limitadas ao contexto para o qual foram criadas e não é possível criar módulos extra que permitam uma integração com a aplicação builONE.
2.3
Tecnologias utilizadas
Neste ponto serão analisadas algumas tecnologias utilizadas no desenvolvimento de vários mecanismos utilizados nesta dissertação, como é o caso do protocolo OData e o caso dos REST Web Services.
2.3.1 SharePoint
SharePointé uma plataforma de desenvolvimento web criada pela Microsoft. Esta plataforma tem uma suite de serviços que permite aos trabalhadores de uma equipa trabalhar de forma colabo-rativa, pois facilita o desenvolvimento, a partilha e gestão de informação bem como acompanhar o processo de desenvolvimento[MM10].
Esta plataforma oferece vários benefícios, entre os quais se pode destacar a facilidade de res-ponder a mudanças, a melhor gestão de conteúdo e gestão de documentos, controlo de tarefas e capacidades de automatizar o workflow de um processo. Em relação à gestão documental, o Sharepointé compatível com diversos tipos de ficheiros, incluindo documentos da suite de produ-tividade Microsoft Office.
Uma aplicação desenvolvida em SharePoint é designada de "Site". Um site é um conjunto de páginas, listas e bibliotecas no quais são adicionados dados e documentos. Um site pode ainda conter sub-sites. Por sua vez, uma página de um site pode conter uma ou mais Web-parts. Uma web-part é uma secção inserida numa página que podem mostrar o conteúdo de uma lista ou biblioteca SharePoint. Por exemplo, uma web-part pode apresentar calendário com as tarefas do utilizador ou mesmo o conteúdo de uma pasta de documentos.
Estado da Arte
Figura 2.9: Estrutura de uma aplicação SharePoint
2.3.2 OData
Open Data Protocol, também conhecido simplesmente por OData, é um protocolo web pa-dronizado criado pela Microsoft que permite estruturar, manipular dados e consultar informação através de operações CRUD (create, read, update, delete). Fornecer e manipular dados através de API’s não é algo novo, sendo que já existiam alguns protocolos criados que permitiam operações do tipo CRUD, tal como é o caso do ODBC (Open DataBase Connectivity), entre outros.
Este protocolo é usado para o acesso a informação de uma grande variedade de fontes, in-cluindo mas não limitando, bases de dados relacionais, sistemas de informação, sistemas de gestão de conteúdo e websites tradicionais [Mica]. Existe uma lista crescente de produtos que utiliza o protocolo OData. A Microsoft utiliza este protocolo em vários dos seus produtos, como é o caso do SharePoint Server 2010 (e posteriores), Excel 2010, Windows Azures Storage, Visual Studio 2008, entre outros.
O protocolo OData foi criado com o objetivo de criar um protocolo padronizado e multi-plataforma, sendo assim possível acabar com as barreiras existentes entre os diversos formatos em que os dados se encontravam estruturados. Este protocolo suporta e disponibiliza os dados que estamos a manipular nos formatos ATOM (XML) ou JSON [Sel10].
2.3.2.1 Funcionalidades
Como foi referido anteriormente, este protocolo permite estruturar, manipular dados e con-sultar informação através de operações CRUD (create, read, update, delete). Estas operações são realizadas através de pedidos HTTP do tipo GET, PUT, POST ou DELETE.
• GET: tipicamente é utilizado como a operação CRUD de leitura (Read);
• DELETE: é utilizado como a operação CRUD DELETE, o que permite apagar os objetos ou conteúdo desejado;
• PUT: é utilizado como a operação de CRUD UPDATE, permite atualizar os objetos preten-didos, no entanto um pedido HTTP do tipo PUT necessita de substituir os objetos originais, sendo que desta forma também é possível criar novos objetos - Create;
Estado da Arte
• POST: Esta operação é utilizada como o operação CRUD CREATE, o que permite criar novos objetos. Também pode ser utilizada para atualizar objetos já existentes.
O protocolo OData permite às aplicações cliente construir URI’s para um determinado con-junto de dados e aplicar filtros às entidades que esse concon-junto de dados contêm. As relações existentes entre as várias entidades presentes são preservadas. OData permite ainda costumizar o resultado de uma consulta. No exemplo seguinte, utilizando $orderby podemos ordenar o re-sultado de uma consulta de acordo com uma ou mais propriedades, por ordem ascendente ou descendente.
http://localhost:8080/exemplo.svc/Categories?$orderby=CategoryName desc
Na tabela2.1, podem ser vistas algumas operações que podem ser utilizadas.
Operação Descrição Exemplo
expand Permite adicionar ao resultado um ou mais conjuntos de dados de entidades relacionadas. Por exemplo, se estiver-mos a apresentar o resultado de uma entidade ’Cliente’, podemos incluir no resultados as suas ’Encomendas’
/Customers(’Pedro’)? $expand=Orders
orderby Permite ordenar o resultado de acordo com uma ou mais propriedades por ordem ascendente ou descendente
/Customers? $or-derby=City desc skip Não apresenta um determinado número de resultados. É
util em conjunto com a função ’top’ para implementar pa-ginação.
Retorna todos os clientes exceto os primeiros 10 /Cus-tomers? $skip=10 top Limita o número de resultados a ser retornado. /Customers?
$top=5 filter Restringe os resultados a serem devolvidos de acordo com
uma determinada pesquisa.
Devolve todos os clientes que vivem em Lon-dres /Customers? $filter=City eq ‘London’
Tabela 2.1: Operações para costumizar o resultado de uma consulta OData
No mesmo pedido é possível utilizar mais que uma operação.
Com este protocolo, utilizando a tag $metadata também é possível ver a metadata do conjunto de dados. Isto é, podemos ver a estrutura completa e consultar informação detalhada acerca das entidades que constituem esse conjunto de dados para um determinado serviço que utilizar OData. 2.3.2.2 Arquitectura e bibilotecas
O acesso e manipulação de dados utilizando OData é feito através de pedidos utilizando o protocolo HTTP. Assim qualquer aplicação que seja capaz de comunicar através de HTTP pode
Estado da Arte
usar o protocolo OData. No entanto, foi desenvolvido um conjunto alargado de bibliotecas que facilita o desenvolvimento de aplicações através do processamento dos dados recebidos em ATOM (XML) ou JSON, criando objetos de forma a facilitar a interação e manipulação dos dados. Estas bibliotecas permitem utilizar este protocolo independentemente da plataforma e da linguagem de programação utilizada. Desta forma, é possível usar este protocolo utilizando:
• Um browser; • Microsoft .NET 4;
• Microsoft .NET 3.51 (disponível para download); • JAVA, incluindo Android;
• JavaScript; • PHP; • AJAX; • Silverlight; • entre outros...
Na figura 2.10pode ser vista uma representação esquemática da comunicação efetuada en-tre aplicações cliente e o servidor. De notar que, como este protocolo é baseado em HTTP, as aplicações cliente e servidor podem usar bibliotecas completamente diferentes. Quando o servi-dor expõe a informação utilizando o protocolo OData, as aplicações cliente podem usar qualquer biblioteca para consumir esta informação.
Estado da Arte
2.3.3 REST Web Services
Representational State Transfer(REST) define um conjunto de princípios de arquitetura para sistemas distribuídos, com os quais podemos desenhar serviços web com foco nos recursos de um sistema, incluindo a forma com os recursos são organizados e transferidos através de HTTP para vários clientes em diferentes linguagens. [Rod08]
REST foi apresentado pela primeira vez no ano 2000, por Roy Fielding na Universidade de Califórnia na sua dissertação com o titulo "Architectural Styles and the Design of Network-based Software Architectures"[Rod08], na qual eram analisados vários princípios de arquitetura de soft-ware para plataformas web utilizando sistemas distribuídos. Passados alguns anos após a sua introdução, várias frameworks para REST começaram a aparecer e ainda continuam a evoluir.
O número de web services que usam REST aumentou ao longo dos anos e neste momento é o modelo predominante. REST teve um enorme impacto na web por ser consideravelmente mais fácil de utilizar comparativamente a outras arquiteturas como SOAP ou WSDL (ambas baseadas em XML).
”REST’s client–server separation of concerns simplifies component implementation, reduces the complexity of connector semantics, improves the effectiveness of performance tuning, and incre-ases the scalability of pure server components.” - Fielding 2000 [Fie00]
Uma implementação REST segue quatro princípios principais: 1. Usa métodos HTTP explicitamente
Com REST são usados métodos HTTP do tipo GET, POST, PUT e DELETE. • GET para operações de leitura;
• POST para operações de escrita. Permite criar novos objetos no sistema; • PUT permite atualizar ou criar um novo objeto ou recurso;
• DELETE permite apagar um objeto do sistema. 2. Não tem estado
Um web service REST precisa de escalar para conseguir suportar um número elevado de pedidos sem comprometer a performance. Imaginando um cenário em que o utilizador (cliente) faz um pedido HTTP GET para consultar os 25 primeiros itens de uma lista de contactos, num próximo pedido pode pretender consultar os 25 próximos contactos dessa lista. Num web service "sem estado"não são guardadas variáveis que permitam ao servidor saber qual a informação a enviar no próximo pedido. Neste caso, é necessário o servidor criar links para os próximos recursos para o qual o cliente vai aceder e a aplicação cliente utiliza essa informação no próximo pedido que pretenda efetuar (ver figura2.11).
3. Expõem o URI com uma estrutura do tipo diretório
Estado da Arte
Figura 2.11: Web Service REST sem estado
interpretação. Para conseguir esta simplicidade é utilizada uma estrutura do tipo diretório, onde é mapeado para o URI a estrutura em que as várias entidades se encontram organiza-das. Por exemplo, num fórum de discussão podemos utilizar um endereço com a seguinte estrutura:
http://www.webservice.com/discussion/topics/{topic}
4. Transfere XML, JSON ou ambos
As aplicações clientes têm a possibilidade de especificar o formato de output que melhor se adequa às suas necessidades. Para tal, apenas é necessário que no cabeçalho do pe-dido HTTP a aplicação indique o formato desejado. Estão disponíveis os formato XML (XML/XHTML) ou JSON. Os objetos no modelo de dados geralmente encontram-se re-lacionados e essas relações também devem ser preservadas no momento em que é criada uma representação desses mesmos objetos (recursos) para um dos formatos de output. Uma representação dos objetos apresenta o seu estado atual e os seus atributos no momento em que o pedido é enviado pela aplicação cliente.
2.3.3.1 WCF Data Service
WCF Data Service é uma plataforma que permite a criação e leitura de dados através da web utilizando o protocolo OData. Como foi referido, este protocolo permite expor os vários recursos de dados recorrendo a um URI. O acesso e alteração (criar, atualizar e apagar) da informação é efetuado através de pedidos HTTP, onde são usados os métodos GET, PUT, POST e DELETE. Uma vez que os WCF Data Service utilizam o protocolo OData, todas as funcionalidades e carac-terísticas presentes neste protocolo são preservadas. Uma das caraccarac-terísticas é a possibilidade de acesso e manipulação dos dados independentemente da plataforma e da linguagem de programa-ção utilizada.
Um WCF Data Service conta também com outras facilidades para operações como autentica-ção e caching. Para isso, os WCF Data Services integram-se com outros serviços e aplicações já existentes como ASP.NET, Windows Communication Foundation (WCF), e Internet Information Services(IIS).
Estado da Arte
Apesar dos dados serem baseados no Modelo Entidade Relação (ERM), um WCF Data Ser-vices expõem o resultado independentemente da fonte de dados subjacente. Depois de um WCF Data Service receber um pedido HTTP, esse pedido é processado e passada uma representação para o WCF Data Service provider. Esse provider traduz o pedido no formato específico da fonte de dados e executa esse mesmo pedido[Mic10b]. Os WFC Data Services conseguem assim garan-tir uma independência da fonte de dados, separando o modelo conceptual dos recursos pedidos, usando OData, do modelo da fonte de dados subjacente.
Os WCF Data Services têm integração com várias tecnologias já existentes, como a ADO.NET Entity Framework, que permite criar um serviço de dados que expõem dados relacionais, tal como acontece com dados armazenados numa base de dados relacional. Desta forma, podemos usar as ferramentas do modelo Entity Data Model (EDM) para criar um modelo que contêm as referências entre este modelo e as tabelas da base de dados. Existem ainda bibliotecas para aplicações base-adas na Framework .NET assim como em Silverlight. Estas bibliotecas permitem interagir com os serviços de dados usando objetos da Framework .NET, assim como também é possível fazer consultas utilizando LINQ.
Arquitetura de um WCF Data Service
Estado da Arte
Como pode ser visto na figura2.12, existem várias bibliotecas que podem ser utilizadas por aplicações cliente para facilitar a manipulação da informação recebida utilizando o protocolo OData. Tal como foi referido no ponto2.3.2.2, estão contempladas bibliotecas para várias lin-guagens de programação, incluindo C#, JAVA, PHP, entre muitas outras.
A comunicação é efetuada através de pedidos HTTP, sendo que a resposta desses pedidos encontra-se no formato Atom(XML) ou JSON (potocolo OData). Tal como pode ser visto na mesma figura, a informação pode estar armazenada numa base de dados relacional ou noutra fonte de dados.
2.3.3.2 SharePoint Web Services
SharePoint fornece um conjunto de Web Services que permitem a aplicações cliente traba-lharem remotamente sobre uma aplicação desenvolvida sobre o mesmo. A interface REST do SharePoint é um WCF Data Service que permite a consulta de informação armazenada em listas e bibliotecas de SharePoint através de pedidos HTTP. Tal como todas os RESTful Web services, a interface REST do SharePoint permite operações HTTP do tipo GET, PUT, POST e DELETE. São também suportadas as opções de filtragem e de consulta apresentadas na tabela2.1, uma vez que este web service também utiliza o protocolo OData. Como os WCF Data Services são inde-pendentes da fonte de dados subjacente, pode ser utilizada uma base de dados relacional assim como outras fontes de dados.
Estado da Arte
Como pode ser visto na figura 2.13, a aplicação cliente começa por enviar uma expressão LINQ para o proxy do serviço WCF. Esse mesmo proxy converte a expressão LINQ para um URL que será enviado para a interface REST no servidor. A aplicação cliente também pode enviar o URI diretamente para a interface REST do SharePoint.
De seguida, a interface REST converte o pedido REST recebido para uma expressão LINQ do SharePoint, sendo que o processo de conversão efetuado é transparente para os programado-res. Posteriormente, essas expressões são executadas numa lista de SharePoint onde os dados se encontram armazenados. É importante notar que as expressões LINQ submetidas pela aplicação cliente para o proxy são independentes das expressões LINQ que o SharePoint executa sobre uma lista. Após a execução do pedido, a interface REST retorna os resultados para o proxy no formato Atom(XML) ou JSON, usando o protocolo OData. A figura2.14mostra a representação de alto nível da arquitetura da interface REST do SharePoint.
Figura 2.14: Arquitetura REST do SharePoint[Mic12c]
• Acesso a Documentos
Tal como tem vindo a ser referido ao longo desta dissertação, é possível efetuar operações do tipo CRUD (create, read, update e delete) através da interface REST fornecido pelo SharePoint. Uma vantagem de utilizar a interface REST do SharePoint é que desta forma não é necessário adicionar referências para a aplicação SharePoint às aplicações cliente para conseguir aceder às suas entidades e listas[Mic12b]. Para aceder às entidades e listas de uma aplicação SharePoint é necessário construir um pedido HTTP, utilizando o padrões do protocolo OData. É possível efetuar os pedidos HTTP em qualquer linguagem de programação, incluindo mas não limitando JAVA e C#.
Para ler informação de uma biblioteca SharePoint, devemos conhecer o URI para essa biblio-teca e a representação OData de forma a a aplicar os filtros necessários às nossas necessidades (ver tabela2.1). Por exemplo, para ler todos os documentos presentes na pasta WorkOrders devemos fazer o seguinte pedido:
http://ws2k8r2x64/GesMan/_vti_bin/ListData.svc/WorkOrders
Estado da Arte
http://ws2k8r2x64/sites/GesMan: Corresponde ao endereço da aplicação SharePoint _vti_bin/ListData.svc/ : Devolve o conjunto de dados relativos ao site
/WorkOrders: Nome da biblioteca que se pretende aceder, neste caso, "WorkOrders"
A representação OData pode ser obtida no formato XML e JSON, sendo que a pré-definida é a linguagem de anotação XML. Para obtermos essa representação em JSON, devemos enviar no cabeçalho do pedido HTTP o par "Accept", "application/json;odata=verbose". De seguida podemos ver um excerto de um pedido efetuado na linguagem de programação JAVA, assim como um pequeno excerto da resposta recebida.
1 URL urlRequest = new URL(urlStr);
2 HttpURLConnection conn = (HttpURLConnection) urlRequest.openConnection();
3 conn.setRequestMethod("GET");
4 conn.setRequestProperty("Accept", "application/json;odata=verbose");
5 conn.setRequestProperty("charset", "utf-8");
Code 2.1: Envio de um pedido HTTP GET
A resposta recebida inclui todas as informações relativas ao documento, tal como a sua meta-datae as várias informações relativas ao ficheiro (nome, diretório onde está armazenado, o tipo de ficheiro, data de modificação, entre muitos outros). A partir desta informação é possível fazer o download do ficheiro pretendido.
1 { 2 "__metadata":{ 3 "uri":"http://ws2k8r2x64/GesMan/_vti_bin/ListData.svc/WorkOrders (88)", 4 "media_src":"http://ws2k8r2x64/GesMan/WorkOrders/Emails/teste. docx" 5 }, 6 "Id":88, 7 "ContentType":"Document", 8 "Path":"/GesMan/WorkOrdes/Emails", 9 "Name":"teste.docx",
10 "Title":"Documento de teste" 11 }
Code 2.2: Resposta em JSON a um pedido HTTP GET
Para fazer o upload de um novo documento para o servidor, é necessário também conhecer o nome da biblioteca SharePoint e o URI onde o documento vai ser armazenado.
Estado da Arte
http://ws2k8r2x64/sites/GesMan/_vti_bin/ListData.svc/WorkOrders
No exemplo de código2.3é possível ver um excerto de um pedido HTTP do tipo POST, que permite a criação de um documento no servidor. Ao cabeçalho do pedido efetuado é necessário adicionar a informação relativa ao diretório para onde o ficheiro vai ser armazenado, assim como o seu nome. Essa informação é adicionada no cabeçalho "Slug". A resposta deste pedido será a informação relativa ao ficheiro criado ou, em caso de falha, o erro devolvido pelo servidor.
1 HttpURLConnection conn = (HttpURLConnection)
2 ((new URL(urlStr).openConnection()));
3 conn.setRequestProperty("Content-Type", "application/json");
4 conn.setRequestProperty("Accept", "application/json");
5 conn.setRequestProperty("Slug", "http://ws2k8r2x64/GesMan/WorkOrders/" + "documento .docx");
6 conn.setRequestMethod("POST");
Code 2.3: Upload de um documento para o servidor
Para enviar o ficheiro para o servidor através de um pedido HTTP POST, primeiro é necessário ler a informação binária do ficheiro para um array de bytes utilizando um FileInputStream. De seguida, esse array de bytes é escrito para o OutputStream, tal como pode ser visto no excerto de código2.4.
1 File file = new File("C:\\documento.docx");
2 byte[] fileData = new byte[(int) file.length()];
3 FileInputStream inn = new FileInputStream(file);
4 inn.read(fileData); 5 6 OutputStream os = conn.getOutputStream(); 7 os.write(fileData); 8 os.close(); 9 inn.close();
Code 2.4: Escrita de um documento através de um pedido HTTP POST
• Acesso a Dados
O acesso a dados a partir de uma aplicação SharePoint pode ser efetuado de duas formas dis-tintas, dependendo da localização onde os dados se encontram armazenados. Desta forma, podem existir dados armazenados numa lista SharePoint, assim como numa base de dados relacional. Dados são recursos de informação que podem ser ou não relacionados entre si.
Na primeira situação, o acesso e manipulação de dados que se encontram armazenados numa lista SharePoint é em tudo semelhante ao acesso e manipulação de documentos, como foi visto no ponto anterior.
Estado da Arte
No caso de pretendermos fazer o acesso a dados armazenados numa base de dados relacional, é necessário criar um novo WCF Data Service. De seguida é necessário criar as chamadas necessá-rias, sendo que estas podem ser do tipo GET, PUT, POST e DELETE. Tal como já foi referido, um WCF Data Service utiliza o protocolo OData e todas as suas caraterísticas encontram-se presentes. Podemos ainda utilizar as capacidades da linguagem de consulta LINQ, utilizando a linguagem de programação C# ou Visual Basic. Conseguimos assim efetuar as operações necessárias com os dados armazenados armazenados nas tabelas presentes em base de dados.
2.3.3.3 Limitações dos SharePoint Web Services
Um web service geralmente é mais lento a efetuar determinadas operações, comparativamente aos mecanismos de comunicação binários (nativos). Da mesma forma, no caso SharePoint também é mais lenta a manipulação de dados através de web services comparativamente aos mecanismos geralmente utilizados, como é o caso de .NET [Dam10].
Este atraso nas respostas recebidas pode ser explicado, no caso da resposta recebida utilizar a linguagem de anotação XML, pelo facto desta linguagem ser muito ”verbosa”. São enviados vários dados repetidos, como é o caso das várias tags existentes de forma a respeitar a boa formatação da linguagem. De forma a melhorar esta situação, podemos usar JSON que é significativamente mais rápido devido à sua simplicidade em comparação com a XML.
Outra situação que atrasa as respostas de um SharePoint Web Service é o facto de não existir o conceito de sessão e todos os pedidos efetuados terem de ser autenticados através de um username e password.
Outra das limitações está relacionada com o upload de ficheiros para o servidor. Esta limitação prende-se com o facto de apenas ser utilizado um único buffer para receber todo o conteúdo do ficheiro. No SharePoint, o tamanho máximo pré-definido para o tamanho do ficheiro que queremos enviar é de 50MB, embora possa ser configurado e o limite máximo para a ser de 2GB[Dam10].
Capítulo 3
Mecanismos de integração
desenvolvidos
Neste capítulo será apresentado e descrito o sistema de integração desenvolvido para a aplica-ção buildONE. Serão apresentadas as tecnologias e ferramentas de integraaplica-ção desenvolvidas, com especial destaque para o Add-in desenvolvido para o MS Outlook e a aplicação de sincronização desenvolvida para MS Explorer.
3.1
Objetivos
Tal como foi referido no capítulo1, o objetivo desta dissertação passou pelo desenvolvimento de mecanismos de integração que permitissem a aplicações cliente executadas em diferentes pla-taformas o acesso a recursos de informação disponíveis em aplicações servidor corporativas. No caso das aplicações cliente, são salientadas as ferramentas de produtividade pessoal como é o caso do MS Outlook e o MS Explorer. Pretendeu-se integrar estas ferramentas com um módulo da apli-cação buildONE, mais concretamente o módulo de Gestão de Ordens de Trabalho. Este módulo desenvolvido será analisado com mais detalhe no capítulo4e no capítulo5.
Quando se fala em recursos, estes podem ser de natureza diferente. Podem ser dados ar-mazenados em sistemas de gestão de bases de dados, documentos ou mensagens de email com os respetivos documentos em anexo, que em ambos os casos são arquivados em sistemas de ficheiros, entre outros tipos de ficheiros. O capítulo2faz referência à analise e desenvolvimento de vários mecanismos de integração que permitem o acesso e a manipulação destes recursos recorrendo a Web ServicesREST.
De forma a integrar os recursos da plataforma buildONE com a ferramenta de produtividade pessoal MS Outlook, foi desenvolvido um Add-in que permite a integração desses mesmos recur-sos com esta ferramenta. Com esta extensão é possível executar várias tarefas, como a criação de compromissos ou o arquivo de emails de um projeto para o servidor, diretamente a partir da aplicação Outlook sem a necessidade de recorrer à aplicação web como geralmente acontece com outro tipo de soluções.
Mecanismos de integração desenvolvidos
Para estender estas funcionalidades para o Windows Explorer do utilizador, foi criada uma aplicação que permite de forma simples a organização de documentos alojados no computador pessoal para pastas de documentos armazenadas em servidor. Esta aplicação mapeia numa pasta do computador do utilizador, a estrutura de pastas e documentos de uma biblioteca de documentos de uma aplicação SharePoint, neste caso do módulo de Gestão de ordens de trabalho da aplicação buildONE.
Em ambos os casos foram utilizados os Web Services REST analisados e desenvolvidos de forma a utilizar os recursos da aplicação buildONE nestas ferramentas de produtividade. Estes recursos podem ser dados relacionais ou documentos provenientes de uma biblioteca de ficheiros SharePoint.
Com estas aplicações o utilizador consegue a criação e manipulação de conteúdos armazena-dos em aplicações corporativas através de aplicações e ambientes que já lhe são familiares no seu quotidiano, aumentando desta forma a facilidade com que esta interação é feita.
Na figura3.1pode ser vista a arquitetura simplificada da aplicação, onde pode ser observada uma aplicação onde todos os recursos são armazenados de forma a manter a informação centra-lizada e atuacentra-lizada entre as várias plataformas. Esses recursos (dados e documentos) podem ser acedidos e manipulados diretamente através da aplicação web bem como através do Outlook, de uma aplicação smartphone ou mesmo através de uma aplicação PC-Desktop.
Mecanismos de integração desenvolvidos
3.2
MS Outlook
Nesta secção será vista a integração desenvolvida entre a ferramentas de produtividade pessoal MS Outlookcom a aplicação buildONE, uma ferramenta empresarial corporativa. Serão analisa-dos os vários mecanismos nativos que já permitiam integração de alguns componentes entre ambas as ferramentas assim como a criação de uma Add-in para o Outlook. Por fim, será feito um com-parativo entre estes dois tipos de integração de forma a saber quais as vantagens e desvantagens que apresentam.
3.2.1 Sincronização nativa entre o MS Outlook e uma aplicação SharePoint
Uma aplicação desenvolvida em SharePoint apresenta algumas opções que permitem a sincro-nização de dados entre essa aplicação e o Outlook. Entre os elementos que é possível sincronizar o destaque vai para o calendário. Utilizando a opção "Connect to Outlook" (ver figura3.2), disponí-vel nos calendários criados numa aplicação SharePoint, um novo calendário é criado na aplicação Outlookcom todos os compromissos existentes na aplicação.
A partir desse momento a sincronização é bidirecional, sendo que tanto é possível criar com-promissos na aplicação web ou no calendário criado no Outlook. Quando um compromisso é apagado são afetados ambos os calendários.
Figura 3.2: Sincronização entre um calendário SharePoint e um calendário Outlook
3.2.2 Desenvolvimento de um Add-in
Tal como foi visto no capítulo 2, o Outlook é uma ferramenta de produtividade pessoal de-senvolvida pela Microsoft que permite de forma simples a gestão de informação pessoal. Esta ferramenta é bastante completa. No entanto é ainda possível acrescentar novas funcionalidades através da adição de Add-ins. Um Add-in é um programa que pode ser desenvolvido para diver-sas ferramentas do pacote de produtividade Microsoft Office. Os Add-ins criados, neste caso para o Outlook, oferecem uma integração total com a ferramenta para a qual é desenvolvido e, desta forma, os utilizadores trabalham num sistema que já é familiar. A construção deste Add-in tem como objetivo facilitar os utilizadores a gerir as suas tarefas que são agendadas no sistema, assim como os emails relativos a projetos ou ordens de trabalho.