integração de ferramentas de produtividade com aplicações ... · este projeto teve como...

FACULDADE DE ENGENHARIA DA UNIVERSIDADE DO PORTO

Integração de Ferramentas deProdutividade com Aplicações

Empresariais

Tiago Miguel da Cunha Gomes

DISSERTAÇÃO

Mestrado Integrado em Engenharia Informática e Computação

Orientador: Prof. Dr. José António Faria

19 de Julho de 2013

c© Tiago Gomes, 2013

Integração de Ferramentas de Produtividade comAplicaçõ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 PaivaArguente: Professor Doutor João Paulo Jorge Pereira

Vogal: Professor Doutor José António Rodrigues Pereira de Faria

19 de Julho de 2013

Resumo

O buildONE é uma aplicação de software que se destina à gestão de sistema de trabalhocontendo 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 funcionalidadese ferramentas de suporte à gestão da documentação e à gestão da comunicação. Todos os recursosde 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 plataformabuildONE que permitam ao utilizador aceder aos recursos disponíveis a partir de ferramentas deprodutividade, como o caso do Microsoft Outlook ou de uma aplicação Desktop com integraçãocom 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 armazenadosem 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, Ferramentasde Produtividade, Sistemas Empresariais

i

Abstract

buildONE is a software platform designed to manage work systems that contain activitieswith 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 application are stored in centralrepositories.

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, likeMicrosoft 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 tothe resources managed by buildONE platform. This application is developed using the SharePointplatform 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 mobiledevices or in other operating systems.

In order to validate the obtained results, a new module to the buildONE application wasimplemented: the Work orders management module. In this module, the integration mechanismsdeveloped during this project are extensively used.

Key words: SharePoint, Web Services, API, REST, Maintenance management, Productivitytools, Enterprise systems

iii

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ónioFaria, 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 edisponibilidade ao longo do projeto.Um especial agradecimento a todos os meus amigos, que direta ou indiretamente me deram apoioe 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, aolongo destes anos, terem apoiado as minhas decisões e dado força para lutar mesmo nas pioresalturas.

Tiago Gomes

v

”You can’t have great software without a great team,and most software teams behave like dysfunctional families.”

Jim McCarthy

vii

Conteúdo

1 Introdução 11.1 Enquadramento e motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Sistemas de trabalho baseados em conhecimento intensivo . . . . . . . . . . . . 21.3 Aplicação piloto de demonstração e validação de conceitos . . . . . . . . . . . . 21.4 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.5 Estrutura do documento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Estado da Arte 72.1 Trababalho relacionado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1.1 Ferramentas de gestão de projetos . . . . . . . . . . . . . . . . . . . . . 82.1.2 Ferramentas de produtividade pessoal . . . . . . . . . . . . . . . . . . . 11

2.2 Síntese das ferramentas relacionadas . . . . . . . . . . . . . . . . . . . . . . . . 152.3 Tecnologias utilizadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.3.1 SharePoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.3.2 OData . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.3.3 REST Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3 Mecanismos de integração desenvolvidos 293.1 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.2 MS Outlook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.2.1 Sincronização nativa entre o MS Outlook e uma aplicação SharePoint . . 313.2.2 Desenvolvimento de um Add-in . . . . . . . . . . . . . . . . . . . . . . 313.2.3 Comparativo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.3 MS Explorer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363.3.1 Network Drive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363.3.2 Desenvolvimento de uma aplicação para Windows . . . . . . . . . . . . 373.3.3 Comparativo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4 Gestão de ordens de trabalho 414.1 Requisitos da aplicação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414.2 Análise dos processos de trabalho . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.2.1 Gestão dos incidentes e das Ordens de trabalho . . . . . . . . . . . . . . 434.3 Modelo do domínio e o modelo de dados relacional . . . . . . . . . . . . . . . . 444.4 Especificação das interfaces com o utilizador . . . . . . . . . . . . . . . . . . . 47

4.4.1 Aplicação web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484.4.2 Aplicação Desktop e Add-in para MS Outlook . . . . . . . . . . . . . . . 504.4.3 Aplicação móvel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

ix

CONTEÚDO

5 Arquitetura da aplicação piloto 555.1 Arquitetura dos REST Web Services para acesso a dados e documentos . . . . . . 565.2 Arquitetura da aplicação Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

6 Conclusões e trabalho futuro 616.1 Resultados obtidos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 616.2 Trabalho futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

A Anexo 1 63

Referências 71

x

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 . . . . 92.2 Interface web da aplicação Pivotal Tracker . . . . . . . . . . . . . . . . . . . . . 102.3 Diagrama de Gantt na aplicação Wrike . . . . . . . . . . . . . . . . . . . . . . . 102.4 Envio de uma tarefa como anexo de um email no Microsoft Outlook 2010 . . . . 112.5 Interface de calendário na aplicação Microsoft Outlook 2010 . . . . . . . . . . . 122.6 Interface web da aplicação Asana . . . . . . . . . . . . . . . . . . . . . . . . . . 132.7 Interface Android da aplicação Pocket Informant . . . . . . . . . . . . . . . . . 132.8 Versão tablet da aplicação Astrid no sistema operativo móvel Android . . . . . . 142.9 Estrutura de uma aplicação SharePoint . . . . . . . . . . . . . . . . . . . . . . . 172.10 Bibliotecas cliente e servidor [Pro10] . . . . . . . . . . . . . . . . . . . . . . . . 192.11 Web Service REST sem estado . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.12 Arquitectura de um WFC Data Service [Mic10b] . . . . . . . . . . . . . . . . . 222.13 Inteface REST SharePoint[Mic10a] . . . . . . . . . . . . . . . . . . . . . . . . 232.14 Arquitetura REST do SharePoint[Mic12c] . . . . . . . . . . . . . . . . . . . . . 24

3.1 Arquitetura da aplicação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.2 Sincronização entre um calendário SharePoint e um calendário Outlook . . . . . 313.3 Adição de um novo separador à Ribbon do Microsoft Outlook . . . . . . . . . . . 323.4 Adição de um menu de contexto a um item do calendário . . . . . . . . . . . . . 333.5 Criação de um novo formulário no Outlook para edição e criação de compromissos 343.6 Utlização de uma Network Drive para mapeamento de uma biblioteca SharePoint 36

4.1 Workflow de uma ordem de trabalho preventiva . . . . . . . . . . . . . . . . . . 434.2 Especificação do modelo de dados relacional . . . . . . . . . . . . . . . . . . . 454.3 Ligação entre uma tabela de um SGBD a uma biblioteca SharePoint . . . . . . . 464.4 Instanciação de um Template . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474.5 Formulário de consulta e configuração de um equipamento . . . . . . . . . . . . 504.6 Navegação entre pastas e documentos no Windows Explorer . . . . . . . . . . . 51

5.1 Arquitetura geral do sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . 555.2 Excerto da arquitetura da aplicação para acesso a dados e documentos . . . . . . 565.3 Excerto da arquitetura da aplicação web . . . . . . . . . . . . . . . . . . . . . . 58

A.1 Modelo de dados UML completo . . . . . . . . . . . . . . . . . . . . . . . . . . 64A.2 Listagens de Ordens de trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . 65A.3 Formulário de criação e edição de Ordens de trabalho . . . . . . . . . . . . . . . 66A.4 Listagens de Equipamentos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

xi

LISTA DE FIGURAS

A.5 Formulário de criação e edição de Equipamento . . . . . . . . . . . . . . . . . . 67A.6 Formulário de criação e edição de um equipamento . . . . . . . . . . . . . . . . 68A.7 Formulário de criação e edição de uma ordem de trabalho . . . . . . . . . . . . . 69A.8 Formulário de pesquisa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

xii

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 . . . . . 353.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

xiii

LISTA DE TABELAS

xiv

Abreviaturas e Símbolos

API Application Programming InterfaceC# C SharpCRUD Create, Read, Update, DeleteEDM Entity Data ModelERM Entity Relationship ModelEUA Estado Unidos da AméricaIDE Integrated Development EnvironmentiOS iPhone OSLINQ Language Integrated QueryMS MicrosoftoData Open Data ProtocolOT Ordem de trabalhoPC Personal ComputerREST Representational State TransferSGBD Sistema de Gestão de Base de DadosSOAP Simple Object Access ProtocolSO Sistema OperativoSP SharePointURI Uniform Resource IdentifierXML Extensible Markup LanguageWCF Windows Communication FoundationWSDL Web Services Description Language

xv

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 calendá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 explorador de ficheiros documentos disponíveis

1

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.

2

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

3

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ítulo 2 apresenta o estado da arte sobre ferramentas de produtividade pessoal e sobre as

tecnologias de base utilizadas nas ferramentas de integração.

No capítulo 3 sã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.

4

Introdução

O capítulo 4 apresenta 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ítulo 5 apresenta 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.

5

Introdução

6

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.

7

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

8

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

9

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.

Figura 2.3: Diagrama de Gantt na aplicação Wrike

10

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.

11

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.

12

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.

Nesta aplicação é possível criar várias listas de tarefas e também atribuir cores às várias tarefas.

13

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.

14

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

15

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.

16

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;

17

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 conjunto 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 tabela 2.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 dedados 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 maispropriedades 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 osclientes exceto osprimeiros 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 comuma determinada pesquisa.

Devolve todosos clientes quevivem 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

18

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.10 pode 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.

Figura 2.10: Bibliotecas cliente e servidor [Pro10]

19

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 explicitamenteCom 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 estadoUm 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 figura 2.11).

3. Expõem o URI com uma estrutura do tipo diretórioUm web service REST deve utilizar URI’s simples e intuitivos, cujo objetivo seja de fácil

20

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 ambosAs 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 caracterí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).

21

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

Figura 2.12: Arquitectura de um WFC Data Service [Mic10b]

22

Estado da Arte

Como pode ser visto na figura 2.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 ponto 2.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 tabela 2.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.

Figura 2.13: Inteface REST SharePoint[Mic10a]

23

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 figura 2.14 mostra 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

tabela 2.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

Sendo que:

24

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-

data e 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.

25

Estado da Arte

http://ws2k8r2x64/sites/GesMan/_vti_bin/ListData.svc/WorkOrders

No exemplo de código 2.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ódigo 2.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.

26

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].

27

Estado da Arte

28

Capítulo 3

Mecanismos de integraçãodesenvolvidos

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 integraçã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ítulo 1, 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ítulo 4 e no capítulo 5.

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ítulo 2 faz 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 Services REST.

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.

29

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 figura 3.1 pode 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 atualizada 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.

Figura 3.1: Arquitetura da aplicação

30


3.2 MS Outlook

Nesta secção será vista a integração desenvolvida entre a ferramentas de produtividade pessoal

MS Outlook com 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 figura 3.2), disponí-

vel nos calendários criados numa aplicação SharePoint, um novo calendário é criado na aplicação

Outlook com 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.

Assim, pretende-se que, a partir do Outlook, seja possível:

31


• Ter uma sincronização completa de itens com o calendário da plataforma;

• Criar, editar e apagar compromissos diretamente na interface do Outlook;

• Organizar os vários emails numa biblioteca da aplicação buildONE.

Para o desenvolvimento deste Add-in foi utilizada a linguagem de programação C# e o IDE

Visual Studio. O Visual Studio é também uma ferramenta desenvolvida pela Microsoft e oferece

uma maior simplicidade e integração de vários componentes no processo de criação do Add-in.

Foi realizado um estudo a esta ferramenta, Microsoft Outlook, de forma a conhecer os recursos

e possibilidades que estão disponíveis na criação de um Add-in e de que forma estas se podem

integrar com os requisitos necessários para a criação de uma Add-in para a plataforma buildONE.

Pretendia-se que a comunicação entre o Outlook e a plataforma buildONE fosse bidirecional e

assim fosse possível gerir as várias tarefas, compromissos ou emails em ambas as interfaces.

Com este Add-in pretendeu-se acrescentar à interface do Outlook novos elementos visuais, tais

como novos menus, adicionar novas entradas ao menu de contexto dos itens existentes ou criar

novos formulários para a inserção dos dados no sistema. Estes elementos visuais são integrados

nos vários elementos já existentes do Outlook. Desta forma, o utilizador consegue fazer as suas

tarefas numa interface que já é familiar.

3.2.2.1 Adição de menus

Com a criação de um Add-in para o Outlook é possível adicionar novos menus aos já exis-

tentes, sendo que estes novos menus são adicionados à Ribbon do Outlook (ver figura 3.3). A

Ribbon é um elemento gráfico presente nas várias ferramentas de produtividade do Microsoft Of-

fice onde se encontram um conjunto de opções agrupadas por separadores. A estes separadores é

possível adicionar grupos com novos botões, novos menus, entre outros elementos visuais. Nes-

tes elementos podem ser adicionados várias eventos, a partir de código em C#, que pode incluir

por exemplo a ligação à plataforma buildONE. A partir destes eventos também podem ser abertos

novos formulários ou ter acesso a dados presentes no Outlook (contactos, emails, tarefas, entre

outros).

Figura 3.3: Adição de um novo separador à Ribbon do Microsoft Outlook

No desenvolvimento deste Add-in para a aplicação buildONE este conjunto de menus foi es-

pecialmente útil para a adição de atalhos rápidos para a criação de novos formulários (criação de

32


novas tarefas ou reuniões), bem como uma opção de sincronização entre os elementos do calendá-

rio do Outlook e da plataforma buildONE.

3.2.2.2 Adição de novas entradas ao menu de contexto

Outra opção que se encontra disponível é a possibilidade de adicionar novas entradas ao menu

de contexto dos itens presentes no Outlook. Desta forma é possível manipular e ter maior con-

trolo sobre um item individualmente. Neste menu de contexto também é possível agrupar várias

entradas em sub-menus, como pode ser visto na figura 3.4.

Figura 3.4: Adição de um menu de contexto a um item do calendário

A utilização de menus de contexto para os itens permitiu adicionar funcionalidades e atalhos

extra aos vários elementos que eram sincronizados com a aplicação. Por exemplo, a partir de

um item do calendário do Outlook, caso este estivesse sincronizado com a plataforma buildONE,

aparecia uma menu de contexto que possibilitava a sua edição a partir de um formulário idêntico

ao existente na plataforma web.

Outra opção disponível era a de arquivar emails recebidos no Outlook para uma pasta (biblio-

teca de SharePoint) utilizando o menu de contexto disponível sobre um item do tipo "Email".

3.2.2.3 Criação de novos formulários

De forma a estender a integração com a aplicação é possível criar novos formulários dentro

da aplicação Outlook. Estes formulários e os eventos associados, tal como as restantes funciona-

lidades do Add-in criado, são desenvolvidos utilizando a linguagem de programação C#. Neste

sentido o IDE Visual Studio também oferece algumas facilidades, oferecendo um editor visual

para a criação de formulários.

33


Figura 3.5: Criação de um novo formulário no Outlook para edição e criação de compromissos

Existe um total controlo nos recursos que se encontram disponíveis no Outlook assim como

nos recursos que se encontram em servidor na aplicação buildONE. Estes formulários foram espe-

cialmente úteis de forma a inserir e atualizar informações na plataforma buildONE.

Como pode ser visto na figura 3.5, a partir de um formulário foi possível inserir e editar novos

compromissos na base de dados da aplicação buildONE. Após a criação de um compromisso, este

passa a estar disponível no calendário do Outlook bem como no calendário do buildONE.

3.2.2.4 Criação de novas pastas

A partir do Outlook foi possível adicionar uma nova pasta a uma conta de email. Pretendeu-

se dar a possibilidade de um utilizador gerir os seus emails de aplicação buildONE através de

interface do Outlook sem que para isso tenha de abrir a aplicação web.

Para esta pasta, podem ser arrastados emails presentes na conta de email do utilizador, sendo

que posteriormente são sincronizados para uma pasta de um biblioteca SharePoint de forma au-

tomática. Um email é um objeto com a extensão ".msg"que além dos vários campos de texto

associados também contém os anexos presentes nesse email. Desta forma, todo o conteúdo sin-

cronizado é preservado.

Após um email ter sido enviado para o servidor, o objeto de ".msg" é apagado do Outlook e

apenas é mostrado um atalho para esse email em servidor, que pode ser aberto normalmente caso o

34


utilizador assim o pretenda. De forma semelhante, quando o Outlook carrega a pasta de email que

se encontra mapeada para um pasta em servidor, por exemplo quando o Outlook é iniciado, apenas

são criados atalhos para esses mesmo emails. Desta forma são evitados problemas de duplicação

de dados e não é necessário utilizar armazenamento extra.

Uma limitação presente na implementação desenvolvida é o facto de ainda não existir nenhum

mecanismo que detete quando um email é apagado no servidor e não no Outlook. O conteúdo

dentro da pasta apenas é atualizado quando o Oulook é iniciado ou quando o utilizador pressiona

o botão de "Sincronizar"presente na Ribbon de menus adicionados com a criação deste Add-in.

Uma possível solução para este problema seria a atualização de forma automática num intervalo

de tempo pré-definido, por exemplo a cada dois minutos era atualizado o conteúdo da pasta de

emails.

3.2.3 Comparativo

Apesar da sincronização nativa com o Outlook ser uma mais-valia, esta apresenta algumas

limitações relativamente às funcionalidades que se pretendiam implementar. A sincronização entre

itens dos vários calendários funciona como pretendido. No entanto, a edição destes mesmos itens

fica limitada pelos formulários oferecidos pelo Oulook, que são mais básicos e não permitem a

adição de vários campos como pode ser feito com a utilização de um Add-in.

De forma nativa também não existe nenhuma forma de sincronizar e organizar os emails dis-

poníveis no Outlook para uma biblioteca em servidor.

Em relação ao Add-in criado pode existir uma dependência relativamente à versão do Outlook

utilizada. Esta versão desenvolvida foi testada utilizando as versões 2007 e 2010 do Outlook. Se

existirem alterações em futuras versões do Outlook este Add-in pode deixar de ser compatível. Por

exemplo, a Ribbon que permite adicionar novos menus à interface (ver ponto 3.2.2.1) apenas foi

introduzida a partir da versão Outlook 2007. A sincronização nativa apresenta a vantagem de não

requerer nenhum tipo de instalação nem estar dependente de futuras atualizações.

Descrição Nativamente Utilização de um Add-inSincronização de tarefas para o calendário V VEdição completa de itens a partir do Outlook X VOrganização de emails no SharePoint X VCompatibilidade das funcionalidades V Dependente da versãoNão requer instalação V X

Tabela 3.1: Comparativo entre os mecanismos nativos e o Add-in para o MS Outlook

Legenda:

V - É possivel / Verdadeiro

X - Não é possivel / Falso

35


3.3 MS Explorer

O Windows Explorer,também conhecido por File Explorer, é uma aplicação de gestão de fi-

cheiros e também de navegação incluída no sistema operativo Windows a partir da versão Windows

95. O Windows Explorer contem uma interface gráfica que permite aos utilizadores uma gestão

dos ficheiros do sistema. É também o Windows Explorer que apresenta vários componentes do

sistema operativo como é o caso do Ambiente de trabalho (Desktop)[Sin11].

O ambiente de trabalho serve como uma plataforma de trabalho, onde é possível colocar itens

tais como pastas ou ficheiros e organizá-los da forma desejada[Mic13].

Nesta secção serão descritos os mecanismos de sincronização nativos que permitem a sincro-

nização de uma biblioteca de documentos de uma aplicação desenvolvida em SharePoint, assim

como o desenvolvimento de uma aplicação para Windows que também permite a manipulação de

ficheiros em servidor, assim como outras funções adicionais.

3.3.1 Network Drive

A partir do Microsoft Windows existe um mecanismo nativo que permite a manipulação de

ficheiros num servidor remoto. Esta funcionalidade, com o nome de Network Drive apresenta-se

como uma forma simples e rápida mapear e controlar o conteúdo de uma biblioteca para uma pasta

localizada no computador pessoal.

Para criar uma ligação remota a um servidor, apenas é necessário clicar em Map Network Drive

a partir do Windows Explorer, como poder ser visto na figura 3.6a, e adicionar alguma informação

sobre o servidor ao qual se pretende criar a ligação. É necessário adicionar o URI da biblioteca

que se pretende mapear assim como as credenciais de autenticação do utilizador. Estas credenciais

asseguram que esse utilizador apenas tem acesso a documentos para aos quais tem permissão.

Após introduzir as informações necessárias é criada uma nova pasta no Windows Explorer

a partir da qual o utilizador pode consultar e editar documentos alojados em servidor. Dentro

dessa pasta podem ser efetuadas as funções habituais tais como colar ou arrastar ficheiros, apagar

ficheiros ou criar sub-pastas. Todo este conteúdo é sincronizado com a biblioteca SharePoint para

a qual a pasta se encontra mapeada.

(a) Criação de uma Network Drive(b) Mapeamento de uma biblioteca SharePoint

Figura 3.6: Utlização de uma Network Drive para mapeamento de uma biblioteca SharePoint

36


3.3.2 Desenvolvimento de uma aplicação para Windows

Apesar dos mecanismos nativos oferecidos pelo sistema operativo Windows permitirem a sin-

cronização e manipulação de ficheiros numa biblioteca SharePoint pretendia-se ter controlo total

sobre esses mesmos itens e sobre a informação adicionada para a aplicação buildONE no momen-

tos em que estes são sincronizados. Desta forma foi desenvolvida uma aplicação para Windows,

na linguagem de programação C# que permitia um total controlo sobre os itens sincronizados com

uma biblioteca SharePoint. A escolha desta linguagem de programação recaiu no facto de existi-

rem bibliotecas adicionais que geram eventos a partir de ações que são efetuadas sobre ficheiros

ou pastas presentes no Windows Explorer.

Desta forma pretendia-se que a aplicação permitisse:

• Sincronização de ficheiros e pastas a partir de uma biblioteca SharePoint;

• Ter controlo sobre os itens dentro da pasta e sub-pastas;

• Adicionar informações adicionais para a aplicação web sobre o ficheiro adicionado.

Desta forma foi criado um programa que adicionava uma pasta a um determinado diretório e

de seguida procedia à sua monitorização. Para a monitorização dos ficheiros e pastas foi utilizada

a classe .NET FileSystemWatcher.

3.3.2.1 FileSystemWatcher

FileSystemWatcher é uma classe da Framework .NET que permite a monitorização de ficheiros

e pastas num determinado diretório do sistema (Windows Explorer)[Hes09]. Com esta classe são

gerados eventos relativos a ações efetuadas sobre esses mesmos ficheiros e pastas. Os eventos

gerados são[Sin08]:

• Changed: Ocorre quando o conteúdo de um ficheiro ou diretório é alterado;

• Created: Ocorre quando um ficheiro ou diretório é criado;

• Deleted: Ocorre quando um ficheiro ou diretório é apagado;

• Renamed: Ocorre quando um ficheiro ou diretório muda de nome.

Após a criação de um objeto desta classe em C# é necessário definir qual o diretório que se

pretende monitorizar. Também é possível adicionar mais parâmetros que definem a forma como

a pasta é monitorizada. Um desses parâmetros permite definir se a monitorização é feita apenas

na pasta definida ou para todas as sub-pastas. É ainda possível aplicar filtros de forma a limitar os

ficheiros ou pastas que são monitorizadas. Isto é especialmente útil para aplicar filtros ao tipo de

ficheiro através do seu formato.

37


1 FileSystemWatcher Watcher = new FileSystemWatcher();

2 Watcher.Path = "C:\Projetos\Documentos";

3 Watcher.IncludeSubdirectories = true;

4 Watcher.Created += new FileSystemEventHandler(Wathcer_Changed);

5 Watcher.Deleted += new FileSystemEventHandler(Wathcer_Changed);

Code 3.1: Monitorização de uma pasta no Windows Explorer

A partir dos eventos gerados foi possível controlar os ficheiros de forma a criar uma aplicação

de sincronização de documentos com a aplicação buildONE.

No caso da aplicação para a plataforma buildONE, quando um ficheiro é criado numa pasta

ou sub-pasta que está a ser monitorizada, são utilizados os Web Services REST do SharePoint e é

efetuado o upload desse ficheiro para o servidor. De forma semelhante ao que se passava com o

upload de emails no Outlook, a partir do momento em que o upload é efetuado com sucesso esse

ficheiro é removido do sistema e apenas é mantido um atalho para esse ficheiro que se encontra no

servidor.

Quando um ficheiro ou diretório é removido do sistema, essa informação é propagada para o

sistema e esses mesmos ficheiros também são removidos. Numa aplicação SharePoint os fichei-

ros removidos são colocados numa nova biblioteca "Recycle Bin", de forma semelhante ao que

acontece com a "Reciclagem"existente no sistema operativo Windows.

Estes mecanismos permitiram construir uma ferramenta com as funcionalidades oferecidas

pelo mecanismo nativo Network Drive. No entanto, permitem ter um controlo total sobre os itens

que estão a ser monitorizados.

3.3.2.2 Adição de uma nova entrada ao menu de contexto do Windows Explorer

De forma a adicionar maior controlo sobre os itens presentes no Windows Explorer pretendeu-

se adicionar uma nova entrada ao menu de contexto desses mesmos itens. A adição de um menu

de contexto permite a execução de várias ações, como a execução de outros programas, com

informação relativa aos ficheiros a partir da qual a ação foi gerada.

A adição de um novo menu de contexto ao Windows Explorer implica a adição de uma nova

chave ao registo do Windows. Essa chave inclui informação sobre o nome a adicionar à entrada do

menu de contexto, o tipo de ficheiros à qual é adicionada esta nova entrada, assim como qual é o

programa executado quando esta chave é invocada[Mic12a].

reg add "HKEY_CLASSES_ROOT\docx\shell\Arquivar no Servidor\command" /t

REG_SZ /d "C:\buildONE\run.bat \"%%1"" /f

No exemplo acima, é adicionada uma entrada ao menu de contexto para todos os ficheiros com

a extensão *.docx. Para adicionar um menu de contexto a todos os ficheiros e não limitar o seu

formato é utilizado o símbolo ’*’ em substituição do formato anteriormente definido. De seguida,

é adicionado o nome que aparece no menu de contexto, neste caso ”Arquivar no servidor”. Por

38


fim, a última variável que pode ser definida é o programa a ser executado quando o utilizador clica

nessa entrada do menu. Como parâmetro para o programa executado é passado o diretório do

ficheiro selecionado.

Para remover esse menu de contexto, caso seja necessário, basta apagar a entrada criada no

registo manualmente ou utilizando um simples programa que foi desenvolvido com essa funcio-

nalidade.

De forma semelhante ao que foi descrito no desenvolvimento do Add-in para Outlook, pretendia-

se adicionar nova informação aos itens que estamos a manipular. Par tal, através do menu de

contexto é possível abrir um novo formulário onde é possível inserir esses dados e posteriormente

submeter. Esta informação é atualizada usando os Web Services REST como tem vindo a ser

descrito.

Esta solução desenvolvida apresenta grandes semelhanças com outras aplicações de sincroni-

zação de documentos, como é o caso da aplicação Dropbox. No entanto, para o armazenamento

dos ficheiros foi adotada uma abordagem diferente. Os ficheiros sincronizados não ficam alojados

no computador pessoal do utilizador e apenas é criado um atalho para esses mesmos ficheiros em

servidor. Desta forma a sincronização é feita mais rapidamente e o utilizador apenas descarrega

os ficheiros quando é necessário, poupando também espaço em armazenamento.

3.3.3 Comparativo

Após o desenvolvimento desta aplicação foi possível concluir que a sincronização nativa ofe-

recida pelo sistema operativo se apresentava uma mais-valia, sendo este um método simples e de

fácil configuração para conseguir aceder e gerir documentos armazenados numa biblioteca de uma

aplicação corporativa desenvolvida em SharePoint. Como é um método nativo do sistema opera-

tivo Windows apresenta, também a vantagem de não ser necessário efetuar a instalação software

adicional.

No entanto, se o objetivo for ter um maior controlo sobre os itens que estão a ser manipulados,

a criação de uma aplicação para a monitorização e sincronização apresenta várias vantagens. Uma

delas é o facto de poderem ser adicionados formulários extra de forma a inserir mais informação

sobre os itens pretendidos. Ao contrário do que acontece com o mecanismo nativo, Network Drive,

é possível implementar mecanismos de forma a que seja possível adicionar documentos sem uma

ligação à internet - modo offline - e proceder à sincronização assim que a ligação seja retomada.

No caso de outros sistemas operativos onde estes mecanismos nativos não estejam disponíveis,

poderia ser estudada a possibilidade de criar uma aplicação de forma semelhante, de forma a

suplantar estas falhas.

Utilizando os mecanismos de monitorização de pastas e ficheiros com a classe FileSystemWat-

cher também se tentou monitorizar a Network Drive criada e assim utilizar os mecanismos de

sincronização nativos. No entanto, esta solução não funcionou, visto não ser possível fazer a

monitorização de pastas e ficheiros armazenados remotamente.

39


Descrição Nativamente Utilização uma aplicaçãoSincronização de documentos em servidor V VMaior controlo sobre os itens X VAdição de formulários adicionais X VFunciona em modo offline X VArmazenar apenas atalho dos ficheiros em servidor offline X VFunciona em vários sistemas operativos X VNão requer instalação V X

Tabela 3.2: Mecanismos nativos de sincronização e o desenvolvimento de uma aplicação cliente

Legenda:

V - É possível / Verdadeiro

X - Não é possível / Falso

40

Capítulo 4

Gestão de ordens de trabalho

Neste capítulo será apresentada a análise funcional e a especificação do módulo de gestão de

manutenção desenvolvido para a aplicação buildONE, em função dos requisitos definidos para

este módulo. Será feita a análise dos processos de trabalho relativos à gestão dos incidentes e

das ordens de trabalho preventiva e curativa. De seguida, será descrito o modelo do domínio e o

modelo de dados relacional utilizado no desenvolvimento deste módulo. Por fim, será feita uma

especificação das interfaces com o utilizador da aplicação web, das aplicações PC-Desktop e das

aplicações móveis.

4.1 Requisitos da aplicação

O módulo de gestão de manutenção desenvolvido tem dois atores principais, sendo eles o

Gestor e o Técnico interno.

Nas condições anteriormente apresentadas, uma mais-valia fundamental do sistema de gestão

será a possibilidade do Gestor gerir as ordens de trabalho a partir das suas ferramentas de produti-

vidade pessoal, executadas tanto no computador pessoal, como no dispositivo móvel. Desta forma,

o Gestor poderá gerir as suas várias tarefas, quer as que tem origem na aplicação de manutenção,

como as tarefas relativas às outras atividades externas à gestão de manutenção, a partir da mesma

interface.

As funções mais complexas de parametrização e configuração do sistema serão executadas

na aplicação web, mas as tarefas quotidianas podem ser geridas diretamente nas ferramentas de

produtividade pessoal sem necessidade de aceder explicitamente à aplicação web.

Na aplicação web estão disponíveis as funcionalidades completas da aplicação de gestão de

manutenção, entre as quais:

• Manutenção da documentação técnica associada aos equipamentos;

• Configuração e parametrização da aplicação (tipos de equipamentos e de ordens de trabalho,

localizações e centros de custos, relatórios e indicadores de desempenho, entre outros);

41


• Gestão da documentação técnica (manuais, procedimentos e instruções de trabalho e esque-

mática);

• Gestão das equipas técnicas;

• Gestão dos prestadores de serviços e dos contratos de manutenção;

• Gestão das instalações e do parque de equipamentos;

• Planeamento das ordens de trabalho.

Já nas ferramentas de produtividade no computador pessoal e em dispositivo móvel apenas

estão disponíveis as funcionalidades necessárias para a gestão diária das ordens de trabalho de

manutenção que, fundamentalmente, são as seguintes:

• Notificação dos incidentes;

• Consulta dos trabalhos em curso;

• Atribuição de ordens de trabalho aos técnicos;

• Consulta dos contratos de manutenção;

• Consulta dos histórico das intervenções.

Além da interface para o Gestor, a aplicação deverá também disponibilizar interfaces aos técni-

cos que executam as ordens de trabalho. Neste caso, as principais funcionalidades a disponibilizar

consistem em:

• Consulta das ordens de trabalho que lhe estão atribuídas;

• Registo da execução das ordens;

• Consulta da documentação técnica dos equipamentos;

• Consulta dos procedimentos de manutenção;

• Consulta do histórico das intervenções.

4.2 Análise dos processos de trabalho

A implementação de um módulo de gestão de manutenção para o software buildONE foi divi-

dida em várias partes devido à sua complexidade que, por sua vez, deram origem a outras disser-

tações. Toda a análise e modelação do processos, assim como a configuração e parametrização,

não foram definidas no âmbito desta dissertação, sendo que essa análise e especificação foi depois

utilizada na implementação da aplicação desenvolvida.

42


4.2.1 Gestão dos incidentes e das Ordens de trabalho

A manutenção divide-se em duas categorias distintas: a manutenção planeada e manutenção

não-planeada. A manutenção planeada é aquela que é efetuada antes de ocorrer qualquer avaria,

por exemplo num equipamento. Por outro lado, a manutenção não-planeada diz respeito às ações

efetuadas à posteriori, isto é, depois de detetadas as avarias.

Manutenção preventiva: é um tipo de manutenção planeada. A manutenção preventiva "é a

manutenção efetuada a intervalos de tempo predeterminados ou de acordo com critérios prescritos

com a finalidade de reduzir a probabilidade de avaria ou de degradação do funcionamento de um

bem"[Cab06].

No caso da aplicação implementada, a execução de uma ordem de trabalho do tipo preventiva

segue um workflow, tal como pode ser visto na figura 4.1. Inicialmente, existe uma ordem de

trabalho que é criada pelo gestor ou pelo sistema de forma automática e periódica. Essa ordem

de trabalho é validada pelo Gestor que decide se passa a execução ou não. Caso essa ordem de

trabalho não passe a execução o processo termina. No caso dessa ordem de trabalho ser aprovada,

o gestor atribuiu-a a um Técnico responsável pela sua execução. Assim, o técnico executa essa

ordem de trabalho e regista a execução da tarefas. Posteriormente é feita uma avaliação pelo gestor

avalia o estado e decide se essa ordem de trabalho pode ser concluída, ou se é necessário atribuí-la

a um novo técnico caso tenha ocorrido alguma falha durante o processo ou não haja conformidade

na execução do processo. Na situação em que a execução da ordem de trabalho tenha sido bem

sucedida, o gestor dá essa ordem por concluída.

Figura 4.1: Workflow de uma ordem de trabalho preventiva

Manutenção curativa: A manutenção curativa é um tipo de manutenção corretiva (manu-

tenção não-planeada), sendo que "é a manutenção efetuada depois da deteção de uma avaria e

destinada a repor o bem num estado em que possa realizar uma função requerida". As avarias

podem ser intrínsecas ou extrínsecas. Ou seja, uma avaria intrínseca é a perda de funções do equi-

pamento devido a fatores internos (tubo rompido, rolamento gripado, etc. . . ), enquanto que uma

avaria extrínseca é a perda de funções do equipamento devido a causas externas como: acidentes,

má operação, entre outros[Cab06].

43


Para fazer a manutenção curativa ou preventiva de equipamentos, estão normalmente associa-

das ordens de trabalho para o efeito. No caso das ordens de trabalho de manutenção curativa

existe uma orientação exclusiva à resolução de um incidente emergente, já no caso de ordens de

trabalho de manutenção preventiva, estas podem ter orientações distintas ao nível da forma de

lançamento/programação das mesmas.

4.3 Modelo do domínio e o modelo de dados relacional

A partir dos requisitos especificados foi desenhada uma solução que apresenta duas componen-

tes distintas, mas que se encontram relacionadas de forma consistente. Como tem sido referido ao

longo desta dissertação, existe um conjunto de dados relativos à gestão de manutenção que são ar-

mazenados num SGBD relacional, assim como um conjunto de documentos relativos a essa gestão

que se encontram armazenados num sistema de armazenamento virtual oferecido pela plataforma

SharePoint.

Esta solução surgiu pelo facto de se pretender desenvolver uma solução flexível e evitar erros

cometidos por outras empresas ao criar bases de dados "rígidas"e onde existe pouca flexibilidade

nos dados introduzidos. Sendo assim, esta solução apresenta duas vertentes distintas que devem

ser escolhidas de acordo com as necessidades inerentes à situação atual. No entanto, esta deve ser

pensada de modo a garantir os melhores resultados para a situação presente mas também de modo

a garantir alterações e maior flexibilidade em situações futuras:

• Guardar só alguns dados em base de dados: nesta solução é apresentado um misto em

que a informação mais importante é guardada em base de dados e a restante informação,

como é o caso dos relatórios ou manuais de equipamentos, são armazenados num sistema

de ficheiros. Esta situação garante maior flexibilidade, uma vez que garante a possibilidade

de preencher os vários documentos de forma relativamente livre sem impor procedimentos

rígidos. Por exemplo, um técnico pode imprimir um template para o registo de uma ordem

de trabalho, onde manualmente o pode preencher e mais tarde digitalizar, inserindo-o no

sistema de forma a que este documento fique associado à ordem de trabalho em questão.

• Guardar tudo em base de dados: esta solução é mais adequada numa situação em que

se pretende que a parametrização e a pesquisa de muitos dados tenha maior importância do

que a flexibilidade oferecida pela solução anterior.

Da especificação referida surgiram algumas entidades principais como é o caso das ordens

de trabalho, tipos de ordens de trabalho, equipamentos e tipo de equipamentos. A partir destas

entidades surgiram outras, sendo que uma das preocupações foi sempre manter o sistema muito

flexível.

Nesta versão optou-se por utilizar o modelo em que os dados mais importantes e de maior

relevância seriam armazenados em base de dados, enquanto que os documentos associados às

várias entidades são armazenados num repositório virtual.

44


Na figura 4.2 pode ser vista uma representação simplificada das principais entidades criadas

para este modelo de dados. Várias entidades, como "Marca", "Modelo", entre outras, não se

encontram representadas neste modelo simplificativo. A versão completa deste modelo pode ser

encontrada no anexo A.

Figura 4.2: Especificação do modelo de dados relacional

Para fazer a correspondência entre a informação armazenada em base de dados e o os docu-

mentos associados armazenados no repositório de ficheiros, é guardada uma referência que cor-

responde ao identificador da pasta onde os documentos estão armazenados e que posteriormente

permite aceder a essa localização.

Na figura 4.3 pode ser vista a ligação existente entre uma ordem de trabalho e a sua pasta

de documentos no repositório principal. Esta pasta pode conter vários documentos e incluir sub-

pastas de forma a organizar a informação pretendida da melhor forma.

45


Figura 4.3: Ligação entre uma tabela de um SGBD a uma biblioteca SharePoint

Esta associação é feita de forma semelhante para para as restantes entidades nas quais se

pretendem armazenar documentos, como é o caso dos equipamentos.

Sempre que uma nova ordem de trabalho é criada, é instanciada uma cópia de um documento

template para a pasta de documentos dessa ordem de trabalho. Esse template é instanciado de

acordo com o tipo de ordem de trabalho escolhido. Um template é um documento genérico relativo

a uma ordem de trabalho desse tipo e vai ser preenchido aquando da execução dessa ordem de

trabalho pelo técnico responsável.

De forma a aumentar a flexibilidade do sistema é possível, por exemplo, o técnico imprimir

este template, preenchê-lo durante a execução da ordem de trabalho que lhe foi atribuída e poste-

riormente digitalizar e submeter esse documento para a página da ordem de trabalho.

A partir dos dados introduzidos na página de formulário relativa a uma ordem de trabalho,

pretende-se ainda preencher um cabeçalho existente no template com esses mesmos dados. Isto é

possível devido ao facto de existir controlo sobre o conteúdo armazenado num documento da suite

de produtividade Microsoft Office como é o caso dos documentos Word (*.docx) e Excel (.*xlsx).

Desta forma existe um aproveitamento das informações introduzidas e um maior controlo sobre

os dados de forma a evitar dados incorretos no preenchimento do documento relativo à ordem de

trabalho. Também é possível poupar tempo ao técnico uma vez que apenas tem de introduzir os

dados uma única vez.

Na figura 4.4 pode ser vista uma representação da instanciação de uma template para uma

ordem de trabalho.

46


Figura 4.4: Instanciação de um Template

4.4 Especificação das interfaces com o utilizador

Neste pronto será analisada a construção das principais interfaces para as diferentes aplicações

cliente desenvolvidas, entre elas a interface do módulo de gestão de manutenção da aplicação web,

a interface do utilizador recorrendo à utilização do MS Outlook e da aplicação Desktop assim como

a aplicação móvel para o sistema operativo Android.

Os vários módulos construídos para a aplicação buildONE seguem três princípios essenciais no

desenho das várias interfaces. Estes princípios pretendem garantir um rápido acesso à informação,

a sua fácil manipulação, assim como a gestão facilitada de conteúdos relacionados. Desta forma,

pretendia-se que estes princípios fossem também utilizados, mesmo que de forma adaptada, na

construção das interfaces para as diferentes aplicações construídas. Esses três princípios utilizados

são:

One Page Shows All:

Com este princípio pretende-se que a informação principal esteja facilmente visível para o

utilizador. Por exemplo, quando um utilizador da plataforma (Gestor ou Técnico) se encontra na

página de gestão de uma ordem de trabalho, este pode encontrar facilmente na mesma página todas

47


as informações relativas a essa OT, incluindo mas não limitando, o técnico associado, os vários do-

cumentos associados a essa OT, emails relativos à OT, entre outro tipo de conteúdos e informação.

Desta forma pretende-se que na mesma página ou na mesma interface sejam apresentados:

• Vários tipos de conteúdos;

• Conteúdos locais e remotos;

• Conteúdos partilhados e privados.

One Click Management:Com este princípio pretende-se ter um controlo rápido sobre o conteúdo disponível nas interfa-

ces desenvolvidas. Através de um simples clique pretende-se ter acesso às várias funcionalidades

existentes sobre esse item. Por exemplo, na interface web, através de um clique com o botão

do lado direito do rato é apresentado um menu de contexto com várias opções disponíveis para

esse item. Utilizando este princípio no desenvolvimento das interfaces é possível uma integração

perfeita entre dados e documentos, sejam eles locais ou remotos, públicos ou privados.

One Day Setup:Nas aplicações desenvolvidas pretende-se oferecer ao utilizador a possibilidade de configurar

as suas preferências pessoais e ainda oferecer várias vistas alternativas à visualização da informa-

ção disponível. Este tipo de configurações é especialmente útil numa ferramenta de produtividade

pessoal. Por exemplo, a partir do calendário do Outlook o utilizador pode definir se pretende ver

as suas tarefas diárias, semanais ou mensais, sendo que o calendário se ajusta nesse sentido.

Partindo destes princípios iniciais foi necessário analisar para cada plataforma quais os recursos

disponíveis e a partir dos requisitos desenvolver as interfaces pretendidas.

4.4.1 Aplicação web

A aplicação web apresenta-se como a principal interface na qual é feita a gestão da manuten-

ção. É nesta interface que são realizadas as tarefas de maior complexidade, como a parametrização

e configuração do sistema.

Foi nesta interface que mais se apostou em aplicar os três princípios anteriormente enunciados,

de forma a aumentar a usabilidade e facilidade de manipulação dos itens apresentados.

Desta forma, são apresentados alguns conceitos que foram aplicados na construção da interface

web da aplicação:

• Drag and Drop: Utilizando a funcionalidade de "arrastar e largar", muito utilizada no Win-

dows Explorer, é possível mover itens, sejam eles documentos ou dados, de uma posição

inicial para uma posição final, alterando o estado desse mesmo item. Por exemplo, é possí-

vel arrastar uma ”Ordem de trabalho” de uma listagem para cima de uma listagem contendo

48


”Técnicos” e assim atribuir essa ordem de trabalho a um técnico responsável de forma faci-

litada. Noutra situação, é possível mover documentos entre pastas na interface web, fazendo

assim uma gestão simples, rápida e intuitiva dos conteúdos.

• Menu de contexto: à semelhança do que acontece no Windows Explorer, foi possível adi-

cionar menus de contexto a itens disponíveis na interface web. Desta forma consegue-se ter

acesso a várias opções relativas a esse item com apenas um clique. É também possível fazer

a ligação entre dados e documentos recorrendo ao menu de contexto. Por exemplo, pode ser

adicionada uma entrada no menu de contexto de um item do tipo ” Ordem de trabalho” que

apresente todos os documentos relativos a essa ordem.

• Navegação em árvore: A navegação em árvore é frequentemente utilizada para mostrar

conteúdo de forma organizada, apresentando uma estrutura de menus e sub-menus à medida

que se navega entre eles. Isto é, são apresentados sub-menus relativos a um menu (nó) à

medida que se expande esse nó. Esta navegação também é encontrada no Windows Explorer.

Este tipo de navegação é útil na navegação utilizada no menu lateral da aplicação web ou,

por exemplo, na navegação entre pastas e documentos guardados.

• Vistas alternadas: Os utilizadores devem ter a possibilidade de personalizar e poder ver os

dados em diversas vistas que melhor se adaptem às suas necessidades. Por exemplo, num

calendário o utilizador pode alterar entre a vista para o ”Dia”, ”Semana” ou ”Mês” e assim

ver os seus compromissos dentro de intervalos de tempo configuráveis.

Também foram utilizados vários conceitos provenientes de aplicações analisadas no estado da

arte de forma a aproveitar o que de melhor existe noutras aplicações. Uma das caraterísticas que

foi apontada como ponto positivo nas ferramentas de produtividade pessoal foi o sistema de cores

utilizado para identificar a prioridade associada a cada tarefa/compromisso. Este sistema de cores

foi adotado no desenvolvimento desta aplicação assim como na aplicação móvel, permitindo assim

aos utilizadores identificar facilmente a prioridade das tarefas a realizar.

A integração das tarefas no calendário integrado na aplicação foi outra das funcionalidades

existentes nalgumas ferramentas analisadas e que foi integrada nesta aplicação. Desta forma é fácil

apresentar ao utilizador quais as próximas tarefas que têm de realizar, assim como a possibilidade

de alternar entre vistas do calendário ("Dia", "Semana", "Mês").

Como foi visto nalgumas ferramentas de produtividade pessoal analisadas, principalmente nas

ferramentas de gestão de projetos, era possível visualizar e acompanhar facilmente o estado em

que cada tarefa se encontrava agrupando-as por diferentes secções de acordo com o seu estado.

Esta facilidade foi também reutilizada na construção destas novas interfaces.

Devido a limitações de tempo para a realização desta dissertação, algumas das interfaces aqui

apresentadas são protótipos e não representações reais do produto desenvolvido, uma vez que

ainda existem funcionalidades em desenvolvimento.

Na figura 4.5 pode ser vista uma representação da página de configuração de um equipamento.

Tal como pode ser visto, na mesma página são apresentadas várias informações relativas a esse

49


equipamento, incluindo os seus manuais associados armazenados em pastas de documentos. Este

é um dos princípios anteriormente referidos (One Page Shows All) sendo que é utilizado no desen-

volvimento das várias páginas da aplicação buildONE.

Figura 4.5: Formulário de consulta e configuração de um equipamento

4.4.2 Aplicação Desktop e Add-in para MS Outlook

Tanto a aplicação desenvolvida para Desktop como o desenvolvimento do Add-in para Ou-

tlook assentaram sobre aplicações já existentes e desta forma as várias interfaces com o utilizador

integram-se perfeitamente com os sistemas já existentes.

50


No caso do desenvolvimento da aplicação Desktop, esta oferece total integração com o Win-

dows Explorer como foi referido no capítulo 3.

O Windows Explorer permitiu utilizar vários recursos oferecidos nativamente de forma a gerir

os vários conteúdos armazenados em servidor na aplicação buildONE. Neste caso foram utilizados

elementos nativos como é o caso da navegação entre pastas e sub-pastas a que os utilizadores já

se encontram habituados. Esta navegação pode ser efetuada de várias formas, como por exemplo

navegar em árvores e expandir as várias pastas até encontrar os documentos necessários.

A criação de uma aplicação para Desktop também permitiu introduzir novos elementos ao

menu de contexto dos itens e assim adicionar novas funcionalidades aos mecanismos já existentes.

No desenvolvimento desta aplicação foram tomadas algumas decisões e retiradas algumas

ideias a partir de aplicações já existentes, como é o caso da Dropbox, analisada no capítulo 2 -

Estado da Arte.

Figura 4.6: Navegação entre pastas e documentos no Windows Explorer

Como pode ser visto na figura 4.6, no Windows Explorer encontra-se presente um menu de na-

vegação na lateral esquerda, que permite a navegação entre pastas e ficheiros presentes no sistema.

Após o desenvolvimento desta aplicação, a integração com o sistema de documentos armazenados

na aplicação buildONE permitiu uma igual navegação entre ficheiros armazenados em servidor, de

forma completamente transparente para o utilizador. O mesmo acontece com todos os documentos

que são geridos através da pasta que se encontra monitorizada, como foi descrito no capítulo 3,

ponto 3.3.2.

O desenvolvimento do Add-in para a ferramenta de produtividade Outlook permitiu utilizar

vários dos elementos visuais existentes, como é o caso da utilização do menu de contexto sobre os

51


itens existentes ou a adição de menus à Ribbon do Outlook.

Os elementos adicionados, assim como o seu objetivo, foram analisados e detalhados no capí-

tulo 3, ponto 3.2.

Além desses elementos, foram adicionados novos formulários para a criação de nova infor-

mação à aplicação buildONE. Na construção dos formulários procurou-se que estes tivessem uma

aparência semelhante aos formulários existentes na versão web de forma a manter a consistência

e desta forma o utilizador tivesse uma maior integração entre as ferramentas.

4.4.3 Aplicação móvel

Como foi referido anteriormente, o desenvolvimento deste projeto deu origem a mais que

uma dissertação com temas diferentes e realizadas em simultâneo, embora vários elementos se

interliguem entre elas. No caso da aplicação móvel, esta não foi desenvolvida no âmbito desta

dissertação. No entanto, várias decisões tomadas no desenvolvimento desta interface foram anali-

sadas em conjunto. Além das decisões tomadas para o desenvolvimento desta aplicação, também

foram utilizados os vários Web Services analisados e desenvolvidos nesta dissertação.

A primeira decisão a ser tomada para o desenvolvimento desta aplicação foi:

”Desenvolver uma aplicação nativa ou em HTLM5?”Atualmente existem questões que têm de ser analisadas quando se pretende optar pela criação

de uma aplicação nativa ou pelo desenvolvimento de uma aplicação HTML5. Em ambos os casos

existem vantagens e esta decisão deve ser tomada de acordo com as necessidades de cada caso.

Relativamente às vantagens apresentadas pelas aplicações desenvolvidas em HTML5 destaca-

se o suporte existente para várias plataformas, uma vez que correm sobre um browser e a sua fácil

manutenção.

No caso das aplicações nativas, estas apresentam uma melhor performance comparativamente

às aplicações desenvolvidas em HTML5 e conseguem aceder a todos os recursos disponíveis no

smartphone, tais como sensores, câmara, contactos, armazenamento interno, entre outros. Neste

momento, HTML5 ainda apresenta um suporte limitado no acesso a recursos locais [KO11].

Muitas empresas, como é o caso do Facebook e LinkedIn abandonaram o desenvolvimento de

aplicações HTML5 e optaram pelo desenvolvimento de aplicações nativas para as várias platafor-

mas [BL13].

”I think the biggest mistake that we made, as a company, is betting too much on HTML5 as

opposed to native... because it just wasn’t there...” Mark Zuckerberg, September 2012 [BL13]

52


Na tabela 4.1 pode ser visto um comparativo entre os dois tipos de desenvolvimento.

Funcionalidade Aplicação nativa HTML5Performance Rápida LentaAspeto da aplicação Nativo EmuladoDistribuição Loja de aplicações WebAcesso aos dispositivo Total LimitadoArmazenamento offline Secure file storage Shared SQLGestos (exemplo: Swipe) Sim SimGeo-localização Sim SimConectividade Online e Offline Maioritariamente Online

Tabela 4.1: Comparativo entre aplicações nativas e HTML5

Dadas as vantagens apresentadas e os requisitos pretendidos, optou-se pelo desenvolvimento

de uma aplicação nativa para o sistema operativo móvel Android. Este sistema é líder de vendas a

nível mundial [Koe13], com cerca de 70% de cota de mercado no final de 2012. Esta escolha tam-

bém foi ajudada pelo facto de haver uma grande quantidade de documentação1 com boa qualidade,

além de muitas bibliotecas existentes que facilitam o desenvolvimento de algumas funcionalida-

des.

De seguida, foi necessário analisar quais as funcionalidades e elementos nativos disponíveis

no desenvolvimento de uma aplicação para Android e de que forma esses elementos poderiam ser

adaptados aos princípios utilizados no desenvolvimento da interface web.

A maior questão prendeu-se no facto de como conseguir organizar as várias informação dispo-

níveis numa página web e conseguir de forma semelhante adaptar esse mesmo conteúdo para um

ecrã de menores dimensões como é o caso dos smartphones. Esta questão diz respeito ao princípio

anteriormente mencionado "One Page Shows All".

A solução encontrada para este problema foi a utilização de ”tabs”, onde cada uma das jane-

las apresenta conteúdo diferente relativo a Web-parts (da aplicação web) distintas. A navegação

efetuada entre tabs é feita recorrendo a gestos de swipe entre as janelas, uma funcionalidade muito

comum nas aplicações desenvolvidas para esta plataforma.

O menu existente ao longo de toda a aplicação web, na aplicação móvel passou a estar dis-

ponível através da Navigation Drawer2. A Navigation Drawer é um painel lateral, que faz parte

dos princípios de desenho das aplicações Android, que permite a navegação entre várias janelas de

uma aplicação. Este painel está sempre disponível, mas apenas é apresentado quando o utilizador

assim o pretender deslizando o dedo a partir do lado esquerdo do ecrã. Desta forma consegue-se

poupar espaço para apresentar outra informação e ao mesmo tempo garantir que a navegação entre

toda a aplicação está sempre assegurada e de forma simples.

1Documentação para Android: http://developer.android.com/guide/components/index.html2Android Navigation Drawer: http://developer.android.com/design/patterns/navigation-drawer.html

53


Com a utilização dos Web Services desenvolvidos no âmbito desta dissertação foi possível

apresentar todo o conteúdo, incluindo documentos, disponíveis na aplicação web numa interface

móvel garantindo sempre uma boa usabilidade.

Como foi referido anteriormente, o desenvolvimento da aplicação encontra-se inserido no âm-

bito de outra dissertação, pelo que, não são apresentadas imagens da aplicação móvel desenvol-

vida.

54

Capítulo 5

Arquitetura da aplicação piloto

Neste capítulo será apresentada a arquitetura da aplicação desenvolvida para esta dissertação.

Nesse sentido, de forma a facilitar a compreensão das diferentes camadas, esta análise é dividida

em duas partes distintas, como pode ser observado na figura 5.1:

• Arquitetura dos REST Web Services

• Arquitetura da aplicação Web

A figura 5.1 resume a arquitetura da aplicação que permite acesso às funcionalidades do sis-

tema.

Figura 5.1: Arquitetura geral do sistema

55


5.1 Arquitetura dos REST Web Services para acesso a dados e docu-mentos

Neste ponto será descrita e analisada a arquitetura utilizada na construção de um WCF Data

Service para acesso a dados e documentos disponíveis na aplicação buildONE. Este extrato encontra-

se assinalado na figura 5.1 com o número (1).

Pretendia-se fazer acesso aos recursos de uma aplicação desenvolvida utilizando a plataforma

SharePoint através de várias aplicações cliente. Esses recursos podem ser dados armazenados

numa base de dados relacional, assim como em listas da plataforma SharePoint. Os documentos

são ficheiros dos mais variados tipos, como documentos .*docx, *.xlsx, .*pdf, *.msg, entre muitos

outros formatos, sendo que se encontram alojados num repositório virtual do SharePoint.

Figura 5.2: Excerto da arquitetura da aplicação para acesso a dados e documentos

Como foi referido no capítulo 2, o acesso a estes recursos foi feito através da criação de

um WCF Data Service, uma plataforma que permite a criação e leitura de dados através da web

utilizando o protocolo OData. 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.

56


Apesar dos dados serem baseados no Modelo Entidade Relação (ERM), um WCF Data Servi-

ces expõe 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.

Desta forma foi criado um WCF Data Service para fazer o acesso a uma base de dados re-

lacional e desta forma disponibilizar os dados através de uma API baseada em REST. No caso

dos documentos, a plataforma SharePoint fornece um conjunto de Web Services que permitem a

aplicações cliente trabalharem remotamente sobre as suas bibliotecas e listas. A interface REST

do SharePoint é um WCF Data Service que permite assim a consulta e manipulação desses re-

cursos através de pedidos HTTP. São também suportadas as opções de filtragem e de consulta

apresentadas na tabela 2.1, uma vez que este web service também utiliza o protocolo OData.

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.

Como pode ser visto na figura 5.2, existem várias bibliotecas que podem ser utilizadas por apli-

cações cliente para facilitar a manipulação da informação recebida utilizando o protocolo OData.

Tal como foi referido no ponto 2.3.2.2, estão contempladas bibliotecas para várias linguagens de

programação, incluindo C#, JAVA, PHP, entre muitas outras. No caso desta dissertação, e como

pode ser visto na figura 5.1, estes Web Services foram especialmente úteis na construção do Add-in

para o MS Outlook, na aplicação de sincronização desenvolvida para Windows com integração com

o Windows Explorer, assim com na construção de uma aplicação móvel desenvolvida no âmbito

de outra dissertação.

A comunicação é efetuada através de pedidos HTTP, sendo que a resposta desses pedidos

encontra-se no formato Atom(XML) ou JSON (protocolo OData).

57


5.2 Arquitetura da aplicação Web

Neste ponto será descrita e analisada a arquitetura utilizada na construção do módulo de Gestão

de manutenção da aplicação web. Na figura 5.1 este extrato corresponde ao número (2).

Na figura seguinte (5.3) esse extrato pode ser visto de forma mais detalhada.

Figura 5.3: Excerto da arquitetura da aplicação web

Como pode ser visto nessa figura, no desenvolvimento dessa aplicação são utilizadas três ca-

madas distintas, sendo elas:

• Camada de acesso a dados;

• Camada lógica;

• Camada de apresentação.

Assim, na camada de acesso a dados é feita toda a gestão da informação armazenada numa

base de dados relacional SQL Server, sendo que esta informação é utilizadas nas restantes cama-

das. Na camada lógica são implementadas todas as ”regras de negócio” relativas à aplicação. É

58


nesta camada que os dados provenientes da camada de dados são manipulados de acordo com as

necessidades e regras inerentes à aplicação. Por fim, a camada de apresentação é responsável pela

apresentação destes dados ao utilizador.

Uma aplicação SharePoint é construída utilizando a Framework ASP.Net [Kum05]. A sepa-

ração das várias funcionalidades em diferentes camadas apresenta várias vantagens relativamente

a modelos mais simples onde não existe esta separação [Inc13]. Por exemplo, a separação das

”regras de negócio” na camada lógica da camada de apresentação facilita a sua manutenção e a

sua reutilização [Mac05].

59


60

Capítulo 6

Conclusões e trabalho futuro

Neste capítulo serão apresentadas os principais resultados obtidos no desenvolvimento no final

desta dissertação assim como as perspetivas de trabalho futuro.

6.1 Resultados obtidos

O desenvolvimento de mecanismos de integração desenvolvidos entre ferramentas corporati-

vas empresariais e os sistemas de produtividade pessoal permitiram quebrar uma barreira existente

entre este tipo de ferramentas e, desta forma, abrir um conjunto alargado de novas possibilidades

que permite uma maior simplicidade e rapidez na sua utilização.

Estas vantagens traduzem-se assim num aumento da produtividade e uma redução do tempo

despendido na realização de tarefas que exigiam a utilização de uma ferramenta web, que nem

sempre se encontrava disponível ou de fácil acesso.

Procurou-se que este sistema de integração fosse suficientemente genérico e desta forma a sua

reutilização noutras aplicações pudesse ser feita de forma simples e rápida. O desenvolvimento

de Web Services para uma aplicação desenvolvida na plataforma SharePoint permite o desenvol-

vimento de várias aplicações cliente para diversos sistemas operativos, assim como várias plata-

formas de desenvolvimento. Estes Web Services permitem o acesso e manipulação de dados e

documentos de uma aplicação SharePoint na aplicação cliente desenvolvida.

No desenvolvimento desta aplicação procurou-se oferecer um sistema bastante flexível, onde

a decisão humana tem um papel importante nas decisões tomadas. Foi desenvolvido um sistema

onde toda a informação pode ser armazenada em dados e documentos sem que a sua integridade

seja perdida.

Comparando os objetivos inicialmente estabelecidos para esta dissertação e os resultados finais

obtidos, todos os objetivos foram atingidos com sucesso e foram feitos grandes progressos que

podem ser utilizados em futuras aplicações desenvolvidas nesta área.

61

Conclusões e trabalho futuro

6.2 Trabalho futuro

O desenvolvimento das várias ferramentas desenvolvidas poderia evoluir e estas apresentarem

novas funcionalidades que permitissem um maior controlo nos dados e documentos manipulados.

Pretendia-se, por exemplo, na aplicação desenvolvida Desktop, integrada com o Windows Explo-

rer, implementar um sistema de sincronização que permitisse o controlo de itens quando adiciona-

dos em modo offline de forma a proceder à sua sincronização assim que a ligação à Internet fosse

retomada.

Pretende-se implementar, num futuro próximo, um sistema de controlo e comparação do

tempo despendido na realização de várias tarefas com a utilização de um sistema tradicional e

com o novo sistema de integração desenvolvido, como é o caso da aplicação Desktop. Este sis-

tema irá gerar estatísticas que permitam calcular e determinar valores aproximados de ganhos de

tempo/produtividade com a utilização deste tipo de ferramentas. Este sistema pode ser imple-

mentado, por exemplo, recorrendo ao sistema de monitorização de pastas e ficheiros apresentado

anteriormente.

O desenvolvimento da aplicação web piloto apresenta ainda uma grande margem de progressão

e várias funcionalidades que necessitam de ser melhoradas, assim como novas funcionalidades que

necessitem ser implementadas.

62

Anexo A

Anexo 1

Na figura A.1 é apresentado o modelo conceptual completo.

63

Anexo 1

Figura A.1: Modelo de dados UML completo

Nas figuras seguintes são apresentadas imagens do módulo de Gestão de Ordens de trabalho

implementado

64

Anexo 1

Figura A.2: Listagens de Ordens de trabalho

65

Anexo 1

Figura A.3: Formulário de criação e edição de Ordens de trabalho

66

Anexo 1

Figura A.4: Listagens de Equipamentos

Figura A.5: Formulário de criação e edição de Equipamento

67

Anexo 1

Nas figuras seguintes são apresentados os protótipos do módulo de Gestão de Ordens de

trabalho

Figura A.6: Formulário de criação e edição de um equipamento

68

Anexo 1

Figura A.7: Formulário de criação e edição de uma ordem de trabalho

69

Anexo 1

Figura A.8: Formulário de pesquisa

70

Referências

[AC06] Barton A. Smith Clemens Drews James Lin Bob Stachel Stephen Farrell Thomas P. Mo-ran Alex Cozzi, Tessa Lau. Activity management as a web service. 2006.

[B86] Boehm B. A spiral model of software development and enhancement. ACM SIGSOFTSoftware Engineering Notes, 11(4), August 1986.

[BL13] Marcelo Ballve e Tammy Lee. The future of mobile development: Html5vs. native apps, Apr 2013. URL: http://www.businessinsider.com/html5-vs-native-apps-for-mobile-2013-4?op=1.

[Bla09] News Blaze. Pivotal tracker best project management tool, Março 2009. URL:http://mw.newsblaze.com/story/2009031708593100007.mwir/topstory.html.

[Cab06] José Paulo Saraiva Cabral. Organização e Gestão da Manutenção - Dos Conceitos àPrática. 2006.

[CH06] Carol Jones Sandra L. Kogan Charles Hill, Robert Yates. Beyond predictable work-flows: Enhancing productivity in artful business processes. 2006.

[Dam10] Reghunath Damodaran. Limitations of sharepoint web services, March2010. URL: http://www.codeproject.com/Articles/63861/Limitations-of-SharePoint-Web-Services.

[Dev13] Android Developers. User interface guidelines, Janeiro 2013. URL:http://developer.android.com/guide/practices/ui_guidelines/index.html.

[Dro] Dropbox. What’s dropbox? "one place for all your stuff, wherever you are.". Últimoacesso - Abril 2013. URL: https://www.dropbox.com/tour/1.

[Fie00] Roy Fielding. Architectural styles and the design of network-based software architec-tures. page Chapter 5, 2000.

[G11] Jessica G. Facebook co-founder dustin moskovitz un-veils new company, asana, Novembro 2011. URL: http://latimesblogs.latimes.com/technology/2011/11/facebook-co-founder-dustin-moskovitz-unveils-new-company-.html.

[Hes09] Amir Hesami. Creating a windows service for watching system directory’s fi-les, Jan 2009. URL: http://www.codeproject.com/Articles/32591/Creating-a-Windows-Service-for-Watching-System-Dir.

71

http://www.businessinsider.com/html5-vs-native-apps-for-mobile-2013-4?op=1

http://www.businessinsider.com/html5-vs-native-apps-for-mobile-2013-4?op=1

http://mw.newsblaze.com/story/2009031708593100007.mwir/topstory.html

http://mw.newsblaze.com/story/2009031708593100007.mwir/topstory.html

http://www.codeproject.com/Articles/63861/Limitations-of-SharePoint-Web-Services

http://www.codeproject.com/Articles/63861/Limitations-of-SharePoint-Web-Services

http://developer.android.com/guide/practices/ui_guidelines/index.html

http://developer.android.com/guide/practices/ui_guidelines/index.html

https://www.dropbox.com/tour/1

http://latimesblogs.latimes.com/technology/2011/11/facebook-co-founder-dustin-moskovitz-unveils-new-company-.html




http://www.codeproject.com/Articles/32591/Creating-a-Windows-Service-for-Watching-System-Dir

http://www.codeproject.com/Articles/32591/Creating-a-Windows-Service-for-Watching-System-Dir

REFERÊNCIAS

[Inc13] Apple Inc. ios human interface guidelines, Janeiro 2013. URL: http://developer.apple.com/library/ios/#documentation/userexperience/conceptual/mobilehig/Introduction/Introduction.html.

[Ire06] Lewis R. Ireland. Project management. mcgraw-hill professional. 2006.

[Kan] KanbanFlow. Lean project management, simplified. Último acesso - Maio 2013. URL:https://kanbanflow.com/features.

[KO11] Mario Korf e Eugene Oksman. Editing native, html5, or hybrid: Unders-tanding your mobile application development options, 2011. URL: http://wiki.developerforce.com/page/Native,_HTML5,_or_Hybrid:_Understanding_Your_Mobile_Application_Development_Options.

[Koe13] John Koetsier. Android captured almost 70apple just un-der 20 URL: http://venturebeat.com/2013/01/28/android-captured-almost-70-global-smartphone-market-share-in-2012-apple-just-under-20/.

[Kum05] Dhananjay Kumar. Architecture of sharepoint for asp.net developers, Feb 2005.URL: http://www.c-sharpcorner.com/uploadfile/dhananjaycoder/architecture-of-sharepoint-for-Asp-Net-developers/.

[Mac05] José Carlos Macoratti. .net - considerações sobre arquitetura e desenho de aplicações,2005. URL: http://www.macoratti.net/net_arc1.htm.

[Mica] Microsoft. Open data protocol q&a. URL: http://msdn.microsoft.com/en-us/data/ee844254.aspx.

[Micb] Microsoft. Outlook - connect. Último acesso - Junho 2013. URL: http://office.microsoft.com/en-us/outlook/.

[Mic10a] Microsoft. Using the rest interface, 2010. URL: UsingtheRESTInterface.

[Mic10b] Microsoft. Wcf data services overview, 2010. URL: http://msdn.microsoft.com/en-us/library/cc668794.aspx.

[Mic12a] Microsoft. Creating shortcut menu handlers, Nov 2012. URL: http://msdn.microsoft.com/en-us/library/cc144171(VS.85).aspx.

[Mic12b] Microsoft.SharePoint. How to: Complete basic operations using sharepoint 2013 restendpoints, July 2012. URL: http://msdn.microsoft.com/en-us/library/jj164022.aspx.

[Mic12c] Microsoft.SharePoint. Programming using the sharepoint 2013 rest service, July 2012.URL: http://msdn.microsoft.com/en-us/library/fp142385.aspx.

[Mic13] Microsoft. The desktop (overview), 2013. URL: http://windows.microsoft.com/en-us/windows-vista/The-desktop-overview.

[MM10] Nancy Buchanan Marty Matthews. Microsoft Sharepoint 2010 QuickSteps. MatthewsTechnology, 2010.

[Niv08] Nivi. Pivotal tracker: The ipod of project management software, Novembro 2008. URL:http://venturehacks.com/articles/pivotal-tracker.

72

http://developer.apple.com/library/ios/#documentation/userexperience/conceptual/mobilehig/Introduction/Introduction.html



https://kanbanflow.com/features

http://wiki.developerforce.com/page/Native,_HTML5,_or_Hybrid:_Understanding_Your_Mobile_Application_Development_Options



http://venturebeat.com/2013/01/28/android-captured-almost-70-global-smartphone-market-share-in-2012-apple-just-under-20/

http://venturebeat.com/2013/01/28/android-captured-almost-70-global-smartphone-market-share-in-2012-apple-just-under-20/

http://www.c-sharpcorner.com/uploadfile/dhananjaycoder/architecture-of-sharepoint-for-Asp-Net-developers/

http://www.c-sharpcorner.com/uploadfile/dhananjaycoder/architecture-of-sharepoint-for-Asp-Net-developers/

http://www.macoratti.net/net_arc1.htm

http://msdn.microsoft.com/en-us/data/ee844254.aspx

http://msdn.microsoft.com/en-us/data/ee844254.aspx

http://office.microsoft.com/en-us/outlook/

http://office.microsoft.com/en-us/outlook/

Using the REST Interface

http://msdn.microsoft.com/en-us/library/cc668794.aspx

http://msdn.microsoft.com/en-us/library/cc668794.aspx

http://msdn.microsoft.com/en-us/library/cc144171(VS.85).aspx

http://msdn.microsoft.com/en-us/library/cc144171(VS.85).aspx

http://msdn.microsoft.com/en-us/library/jj164022.aspx

http://msdn.microsoft.com/en-us/library/jj164022.aspx

http://msdn.microsoft.com/en-us/library/fp142385.aspx

http://windows.microsoft.com/en-us/windows-vista/The-desktop-overview

http://windows.microsoft.com/en-us/windows-vista/The-desktop-overview

http://venturehacks.com/articles/pivotal-tracker

REFERÊNCIAS

[Pro10] Open Data Protocol. What is the open data protocol?, 2010. URL: http://www.odata.org/introduction/.

[Rod08] Alex Rodriguez. Restful web services: The basics. November 2008.

[Sel10] Chris Sells. Open data protocol by example, March 2010. URL: http://msdn.microsoft.com/en-us/library/ff478141.aspx.

[Sin08] Prashant K Singh. C#: Application to watch a file or directory using filesystemwatcher, May 2008. URL: http://www.codeproject.com/Articles/26528/C-Application-to-Watch-a-File-or-Directory-using-Fs.

[Sin11] Steven Sinofsky. Building windows 8 - improvements in windows explorer,Aug 2011. URL: http://blogs.msdn.com/b/b8/archive/2011/08/29/improvements-in-windows-explorer.aspx.

[Sol13] Web Information Solutions. Pocket informant, Janeiro 2013. URL: https://itunes.apple.com/us/app/pocket-informant/id302503702?mt=8.

[SWS04] Wasim Sadiqb Shazia W. Sadiqa, Maria E. Orlowskaa. Specification and validation ofprocess constraints for flexible workflows. 2004.

[Web13] Inc. WebIS. Pocket informant-events,tasks, Janeiro 2013. URL: https://play.google.com/store/apps/details?id=net.webis.pocketinformant.

[Wri] Wrike. Manage multiple projects. Último acsso - Maio 2013. URL: http://www.wrike.com/tour/#manage-multiple-projects.

73

http://www.odata.org/introduction/

http://www.odata.org/introduction/

http://msdn.microsoft.com/en-us/library/ff478141.aspx

http://msdn.microsoft.com/en-us/library/ff478141.aspx

http://www.codeproject.com/Articles/26528/C-Application-to-Watch-a-File-or-Directory-using-Fs

http://www.codeproject.com/Articles/26528/C-Application-to-Watch-a-File-or-Directory-using-Fs

http://blogs.msdn.com/b/b8/archive/2011/08/29/improvements-in-windows-explorer.aspx

http://blogs.msdn.com/b/b8/archive/2011/08/29/improvements-in-windows-explorer.aspx

https://itunes.apple.com/us/app/pocket-informant/id302503702?mt=8

https://itunes.apple.com/us/app/pocket-informant/id302503702?mt=8

https://play.google.com/store/apps/details?id=net.webis.pocketinformant

https://play.google.com/store/apps/details?id=net.webis.pocketinformant

http://www.wrike.com/tour/#manage-multiple-projects

http://www.wrike.com/tour/#manage-multiple-projects

integração de ferramentas de produtividade com aplicações ... · este projeto teve como...

Documents