Sistema de Gestão de Informação do IPFNGestão de Recursos Humanos e Suporte Informático

Jorge Simão Madeira Cordeiro de Aragão Goulart

Dissertação para obtenção do Grau de Mestre em

Engenharia Informática e de Computadores

Orientadores: Prof. Helena Isabel de Jesus GalhardasDr. Alberto Manuel Martinho Vale

Prof. João Carlos Serrenho Dias Pereira

Júri

Presidente: Prof. Luís Manuel Antunes VeigaOrientador: Prof. Helena Isabel de Jesus GalhardasVogal: Prof. Luís Jorge Brás Monteiro Guerra e Silva

Abril 2018

ii

Em memoria da Bijou, cujo amor incondicional e compreensao mutua mas sem palavras me

acompanharao ate ao fim.

2006 - 2018

iii

iv

Agradecimentos

Deixo aqui algumas palavras de agradecimento a todas as pessoas cujos contributos tornaram possıvel

a realizacao desta tese e, assim, me ajudaram a atingir mais um marco importante na minha vida

academica, profissional e pessoal.

Aos meus orientadores - a Prof. Helena Galhardas, o Dr. Alberto Vale e o Prof. Joao Pereira - nao

so por me oferecerem a oportunidade de contribuir para este projeto, como tambem pela ajuda, atencao

e acompanhamento oferecidos durante o desenvolvimento desta tese e do documento de levantamento

de requisitos que a precedeu.

Ao meu colega e amigo Pedro Silva, com quem trabalhei em conjunto para tornar este novo Sistema

de Gestao de Informacao do IPFN uma realidade, cujo trabalho e cooperacao tornaram possıvel a

realizacao desta tese.

A equipa da DSI do Tecnico - mencionando em particular o Prof. Luıs Guerra e Silva, o Eng. Luıs

Cruz e o Eng. Sergio Silva - cujo apoio tecnico e acompanhamento foram indispensaveis durante a

implementacao deste sistema.

Aos membros do IPFN que participaram nos testes com utilizadores, a equipa de informatica do

IPFN cuja colaboracao tornou possıvel a realizacao dos testes de desempenho, por prescindirem do

seu tempo para ajudar a assegurar a qualidade deste sistema.

Ao IST e os seus docentes, por garantirem que os seus estudantes recebem uma educacao superior

de elevada qualidade e, portanto, contribuıram para a minha propria evolucao como pessoa e como

estudante.

A equipa da MicroEuropa, por, previamente a realizacao desta tese e do documento de levantamento

de requisitos, me acolherem de bracos abertos e me oferecerem a oportunidade de contribuir para os

seus projetos e assim aprender e ganhar experiencia no desenvolvimento de sistemas web, que provou

ser essencial durante o desenho e implementacao deste sistema.

A Escola de Musica Crescendo e aos coros Vox Laci - em especial, o Coro Hirmandade e o Maestro

Myguel Santos e Castro - que, pela sua exigencia, me inspiraram a sempre dar o meu melhor em todas

as areas da minha vida.

Aos meus amigos - em especial ao Ismael e a Carolina - cuja companhia, carinho e amizade me

ajudaram a superar os maiores obstaculos e a apreciar os melhores momentos.

A minha famılia - em especial os meus pais, avos e o meu irmao Tiago - que sempre me acompa-

nharam e me suportaram, trabalhando arduamente todos os anos da minha vida para garantir a minha

felicidade e o meu sucesso. O vosso amor foi, acima de tudo, aquilo que me moldou como pessoa, e

estarao sempre presentes em tudo aquilo que faco.

v

vi

Resumo

Um Sistema de Gestao de Informacao (SGI) e uma plataforma de software que suporta a gestao

de informacao sobre os produtos, clientes, fornecedores e financas de uma organizacao. As unida-

des de investigacao tambem beneficiam da utilizacao de um SGI devido a necessidade de gestao de

informacao sobre os seus membros, projetos e ativos. O Instituto de Plasmas e Fusao Nuclear (IPFN)

e uma unidade de investigacao do IST e necessita de um SGI que cumpra os requisitos emergentes de

projetos nacionais e internacionais de investigacao cientıfica.

Anteriormente a realizacao desta tese foi produzido um documento detalhando os requisitos para

um novo SGI. Varios SGI atualmente disponıveis foram analisados, comparando as suas caracterısticas

e funcionalidades com os requisitos. Concluiu-se que nenhum dos sistemas analisados cumpre todas

as necessidades do IPFN e a melhor solucao foi desenvolver um novo SGI.

O SGI desenvolvido no ambito desta tese e modular, permitindo que seja facilmente expandido. Adi-

cionalmente, o sistema foi projetado para se integrar com sistemas externos pertencentes ao IPFN e

ao IST. Apos o desenvolvimento, foram realizados testes de desempenho e usabilidade para verificar o

seu comportamento em situacoes de carga e a qualidade da interface com o utilizador, respetivamente.

Os testes mostraram que o sistema responde as necessidades de desempenho e tem uma boa usabi-

lidade. O novo sistema foi colocado em producao em marco de 2017, para ser usado pelos membros

do IPFN. Existiu um perıodo de 6 meses onde foram reportados erros do sistema, e este foi atualizado

com correcoes.

Palavras-chave: Sistema de Gestao de Informacao, Recursos Humanos, Suporte Informa-

tico, Unidades de Investigacao, Engenharia de Software.

vii

viii

Abstract

An Information Management System (IMS) is a software platform that enables the management of in-

formation about products, customers, suppliers and finances of an organization. Research units also

benefit from the use of an IMS due to the need to manage information about their members, projects

and assets. Instituto de Plasmas e Fusao Nuclear (IPFN) is a research unit belonging to IST and needs

an IMS that meets the emerging requirements of national and international scientific research projects.

Before the development of this thesis, a document detailing the requirements for a new IMS was pro-

duced. Several IMS currently available were analyzed, comparing their characteristics and functionality

with the requirements. None of the analyzed systems fully meet IPFN’s requirements, and thus the best

solution was to develop a new IMS.

The IMS developed under this thesis is modular, which enables it to be easily extended. Additionally,

the system was designed to be integrated with external software systems, belonging to IPFN and to

IST. After development, a set of performance and usability tests were performed in order to verify the

behavior of the system under load and the quality of the user interface, respectively. Tests have shown

that the system meets IPFN’s performance needs and users felt that the system had good usability. The

new system was put into production in March 2017, to be used by IPFN’s members. There was a period

of 6 months where system errors were reported, and the system has been updated with fixes.

Keywords: Information Management System, Human Resources, IT Support, Research Units,

Software Engineering.

ix

x

Conteudo

Agradecimentos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v

Resumo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii

Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix

Lista de Tabelas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv

Lista de Figuras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii

1 Introducao 1

1.1 Sistemas de Gestao de Informacao existentes . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.3 Estrutura do Documento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Requisitos 5

2.1 Gestao de Membros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2 Gestao de Perfil de Membro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.3 Gestao de Assiduidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.4 Gestao de Missoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.5 Gestao de Tickets de Suporte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.6 Gestao de Rede Informatica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3 Trabalho Relacionado 21

3.1 Selecao dos Sistemas de Gestao de Informacao . . . . . . . . . . . . . . . . . . . . . . . 21

3.2 Caracterısticas Analisadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.3 Sistemas de Gestao Academica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.3.1 FenixEdu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.4 Sistemas de Gestao de Workflows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.4.1 Dot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.5 Sistemas Integrados de Gestao Empresarial . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.5.1 1ERP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.5.2 Apache OFBiz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.5.3 ERPNext . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.5.4 GrowERP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.5.5 JFire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

xi

3.5.6 Microsoft Dynamics AX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.5.7 Odoo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.5.8 Primavera . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.5.9 SAP ERP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.6 Sistemas de Gestao de Recursos Humanos . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.6.1 OrangeHRM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.7 Sistemas de Gestao de Tickets de Suporte . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.7.1 osTicket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.8 Discussao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.8.1 Escolha de framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4 Implementacao 39

4.1 Arquitetura Geral do Sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.2 Arquitetura da Solucao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.3 Funcionalidades Comuns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.4 Arquitetura de um Modulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.5 Modulo de Gestao de Membros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.5.1 Classes Member e User . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4.5.2 Sincronizacao com o Fenix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

4.5.3 Permissoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

4.6 Modulo de Gestao de Perfil de Membro . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

4.6.1 Criacao de Perfil de Membro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

4.6.2 API para Perfil de Membro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

4.7 Modulo de Gestao de Assiduidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

4.7.1 Iniciar e Parar Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

4.7.2 Pedidos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

4.7.3 Estatıstica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

4.8 Modulo de Gestao de Missoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

4.8.1 Implementacao da API no Dot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

4.8.2 Listar Missoes do Dot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

4.8.3 Gerar Relatorios de Missoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

4.9 Modulo de Gestao de Tickets de Suporte . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

4.9.1 Comentarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

4.10 Modulo de Gestao de Rede Informatica . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

4.10.1 Workflow para um Pedido IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

5 Validacao 65

5.1 Interface Grafica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

5.1.1 Avaliacao Quantitativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

5.1.2 Avaliacao Qualitativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

xii

5.1.3 Planeamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

5.1.4 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

5.2 Desempenho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

5.2.1 Preparacao do Sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

5.2.2 Testes de Desempenho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

5.2.3 Metricas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

5.2.4 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

5.3 Funcionalidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

6 Conclusoes 83

6.1 Resumo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

6.2 Trabalho Futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

Bibliografia 87

A Acrescentar um novo modulo ao Sistema 89

A.1 Preparar um novo modulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

A.2 Implementar o novo modulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

A.2.1 Domınio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

A.2.2 Servicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

A.2.3 Beans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

A.2.4 Pesquisa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

A.2.5 Implementar Servicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

A.2.6 Controladores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

A.2.7 Vistas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

A.3 Instalar o novo modulo no sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

B Guia de Instalacao e Atualizacao do Sistema de Gestao de Informacao do IPFN 115

B.1 Instalar o Sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

B.1.1 Instalar e Configurar as Dependencias . . . . . . . . . . . . . . . . . . . . . . . . . 115

B.1.2 Compilar e Empacotar o Sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

B.1.3 Configurar o Sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

B.2 Atualizar o Sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

B.3 Backups ao Sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

B.4 Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

C Envio de Emails 137

C.1 Configuracao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

C.2 Eventos com Envio de Email . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

D Questionario 141

xiii

xiv

Lista de Tabelas

3.1 Informacao Geral do Sistema para os sistemas Dot, FenixEdu, Microsoft Dynamics AX e

SAP ERP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.2 Funcionalidades presentes nos sistemas Dot, FenixEdu, Microsoft Dynacs AX e SAP ERP 32

3.3 Informacao Geral do Sistema para os sistemas 1ERP, ERPNext, OrangeHRM e osTicket 33

3.4 Funcionalidades presentes nos sistemas 1ERP, ERPNext, OrangeHRM e osTicket . . . . 33

xv

xvi

Lista de Figuras

2.1 Diagrama de Casos de Uso para a Gestao de Membros. . . . . . . . . . . . . . . . . . . . 8

2.2 Diagrama de Casos de Uso para a Gestao de Perfil de Membro. . . . . . . . . . . . . . . 9

2.3 Diagrama de Casos de Uso para a Gestao de Assiduidade. . . . . . . . . . . . . . . . . . 12

2.4 Diagrama de Casos de Uso para a Gestao de Missoes. . . . . . . . . . . . . . . . . . . . 15

2.5 Diagrama de Casos de Uso para a Gestao de Tickets de Suporte. . . . . . . . . . . . . . 16

2.6 Diagrama de Casos de Uso para a Gestao de Rede Informatica. . . . . . . . . . . . . . . 18

4.1 Visao Geral do novo SGI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.2 Visao de Decomposicao em Modulos do novo SGI. . . . . . . . . . . . . . . . . . . . . . . 41

4.3 Visao de Camadas do novo SGI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.4 Diagrama de Classes para Acceptable. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4.5 Diagrama de Sequencia para a geracao do Acceptable para os criterios de pesquisa

?title=Test&published=false . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4.6 Acceptable para os criterios de pesquisa ?title=Test&published=false . . . . . . . . 45

4.7 Visao de Camadas de um Modulo do novo SGI. . . . . . . . . . . . . . . . . . . . . . . . 46

4.8 Diagrama de Classes para o Modulo de Gestao de Membros. . . . . . . . . . . . . . . . . 48

4.9 Implementacao da Classe RegisterUserAsMemberListener. . . . . . . . . . . . . . . . . 49

4.10 Protocolo para obter e renovar OAuth2 Tokens. . . . . . . . . . . . . . . . . . . . . . . . . 51

4.11 Interface final para a gestao das permissoes de um membro. . . . . . . . . . . . . . . . . 53

4.12 Diagrama de Classes para o Modulo de Gestao de Perfil de Membro. . . . . . . . . . . . 54

4.13 Implementacao do JsonViewer para a classe MemberProfile. . . . . . . . . . . . . . . . 56

4.14 Diagrama de Classes para o Modulo de Gestao de Assiduidade. . . . . . . . . . . . . . . 57

4.15 Exemplo do calculo das estatısticas para um membro do IPFN para o ano de 2016. . . . 59

4.16 Diagrama de Classes para o Modulo de Gestao de Missoes. . . . . . . . . . . . . . . . . 59

4.17 Diagrama de Classes para a interface MissionGatherer e as classes que a implementam. 61

4.18 Diagrama de Classes para o Modulo de Gestao de Tickets de Suporte. . . . . . . . . . . 61

4.19 Diagrama de Classes para o Modulo de Gestao de Rede Informatica. . . . . . . . . . . . 62

4.20 Diagrama de Maquina de Estados de um Pedido IP. . . . . . . . . . . . . . . . . . . . . . 63

5.1 Total de utilizadores que terminaram cada tarefa. . . . . . . . . . . . . . . . . . . . . . . . 70

5.2 Media e Desvio Padrao do tempo demorado por tarefa. . . . . . . . . . . . . . . . . . . . 70

xvii

5.3 Media e Desvio Padrao do numero de cliques efetuados por tarefa. . . . . . . . . . . . . . 71

5.4 Total de erros cometidos por utilizadores para cada tarefa. . . . . . . . . . . . . . . . . . . 71

5.5 Distribuicao das idades dos utilizadores. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

5.6 Previsao dos dispositivos que irao ser usados com maior frequencia por parte dos utili-

zadores. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

5.7 Previsao dos modulos que irao ser usados com maior frequencia por parte dos utilizadores. 74

5.8 Distribuicao das pontuacoes SUS obtidas. . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

5.9 Frequencia de erros com o aumento de numero de utilizadores. . . . . . . . . . . . . . . 78

5.10 Frequencia de erros com o aumento de numero de acoes. . . . . . . . . . . . . . . . . . . 78

5.11 Throughput com o aumento de numero de utilizadores. . . . . . . . . . . . . . . . . . . . 79

5.12 Throughput com o aumento de numero de acoes. . . . . . . . . . . . . . . . . . . . . . . 79

5.13 Tempo medio de resposta com o aumento de numero de utilizadores. . . . . . . . . . . . 80

5.14 Tempo medio de resposta com o aumento de numero de acoes. . . . . . . . . . . . . . . 80

xviii

Capıtulo 1

Introducao

Um Sistema de Gestao de Informacao (SGI) e uma plataforma de software que suporta a gestao de um

conjunto vasto de informacao sobre os seus produtos, clientes, empregados, fornecedores, projetos,

producao, ativos e financas. Estes sistemas sao geralmente utilizados por todos os departamentos de

uma organizacao e pela maioria dos seus elementos.

Atualmente existem varios SGI disponıveis no mercado, com diferentes focos e diferentes publicos-

alvo1. Os SGI existentes vao desde sistemas open source desenhados para serem expandidos e

alterados de maneira a servirem as necessidades das instituicoes ate sistemas comerciais desenvolvi-

dos para serem usados out-of-the-box por organizacoes de grande dimensao. No entanto, verifica-se

que, na grande maioria das solucoes disponıveis, os sistemas foram desenvolvidos com foco na sua

utilizacao por instituicoes empresariais ou organizacoes com fins lucrativos, dando portanto uma ele-

vada importancia a gestao financeira, de relacionamento com clientes, de marketing e de vendas. Os

centros de investigacao cientıfica e de educacao tambem beneficiam da utilizacao de um SGI, devido

a necessidade de gestao de informacao sobre os seus empregados, projetos e ativos. No entanto,

existem necessidades especıficas a estes centros que os SGI tradicionais nao satisfazem, tal como a

gestao da sua producao cientıfica (como publicacoes, projetos cientıficos, e outros documentos de cariz

cientıfico).

O Instituto de Plasmas e Fusao Nuclear (IPFN)2 e uma unidade de investigacao do Instituto Su-

perior Tecnico (IST)3 e, a semelhanca de outras unidades de investigacao, necessita de um SGI que

cumpra os requisitos emergentes de projetos nacionais e internacionais de investigacao cientıfica. O

actual SGI do IPFN, vulgarmente conhecido por “Intranet”4, comecou a ser desenvolvido em 2005 e foi

sofrendo alteracoes ao longo dos anos, conforme as necessidades que foram surgindo como resultado

do crescimento do IPFN. Devido a escassa documentacao da arquitetura implementada, a utilizacao

de tecnologias ja ultrapassadas e ao aparecimento de novas necessidades nao satisfeitas pelo sistema

atual, o IPFN necessita de um novo SGI, de maneira a substituir o “Intranet”.

1http://www.softwareadvice.com2http://www.ipfn.tecnico.ulisboa.pt3http://tecnico.ulisboa.pt4https://informatica.ipfn.ist.utl.pt/private

1

1.1 Sistemas de Gestao de Informacao existentes

Anteriormente a realizacao desta tese, para entender as necessidades do IPFN, foi produzido um do-

cumento detalhando os requisitos para o novo SGI [1].

Durante o desenvolvimento desta tese, foram analisados varios SGI existentes no mercado, em

particular: (i) Sistemas de Gestao Academica, (ii) Sistemas de Gestao de Workflows, normalmente

conhecidos como Workflow Management System (WMS) [2], (iii) Sistemas Integrados de Gestao Em-

presarial, normalmente conhecidos como sistemas Enterprise Resource Planning (ERP) [3], (iv) Sis-

temas de Gestao de Recursos Humanos, normalmente conhecidos como sistemas Human Resource

Management (HRM) [4], (v) Sistemas de Gestao de Tickets de Suporte, normalmente conhecidos como

Issue Tracking System (ITS) [5].

Comparamos as caracterısticas e funcionalidades de cada SGI com os requisitos levantados e

concluiu-se que nenhum dos sistemas analisados cumpre na totalidade as necessidades do IPFN e,

portanto, a melhor solucao foi desenvolver um novo SGI.

1.2 Objetivos

O objetivo desta tese consiste no desenho, implementacao e validacao dos modulos relativos a Gestao

de Informacao de Recursos Humanos e Suporte Informatico de um novo SGI para o IPFN. Os modulos

de Gestao de Producao e de Ativos sao desenvolvidos numa tese em separado [6].

Os modulos relativos a Gestao de Informacao de Recursos Humanos e Suporte Informatico sao os

seguintes:

1. Gestao de Recursos Humanos

(a) Gestao de Membros: Responsavel pela gestao das contas de membro dos utilizadores do

IPFN.

(b) Gestao de Perfil de Membro: Responsavel pela gestao dos perfis de membro, que estao

disponıveis para qualquer visitante do site do IPFN visualizar.

(c) Gestao de Assiduidade: Responsavel pela gestao da assiduidade dos membros do IPFN.

(d) Gestao de Missoes: Responsavel por listar as missoes que um membro tem no Dot e gerar

relatorios das missoes.

2. Suporte Informatico:

(a) Gestao de Tickets de Suporte: Responsavel pela gestao de Tickets que podem ser criados

por membros em caso de existencia de problema com o sistema informatico do IPFN.

(b) Gestao de Rede Informatica: Responsavel pela gestao de Pedidos de Enderecos IP que

podem ser criados por membros.

2

1.3 Estrutura do Documento

Este documento encontra-se dividido em seis capıtulos. O Capıtulo 2 descreve os requisitos do novo

SGI. O Capıtulo 3 reporta o estudo efetuado sobre os SGI existentes no mercado considerados mais

relevantes, analisando as caracterısticas de cada um deles, e comparando as funcionalidades ofereci-

das com os requisitos dos modulos descritos no Capıtulo 2. O Capıtulo 4 detalha a solucao desenhada

e implementada para o novo SGI. O Capıtulo 5 detalha a validacao experimental realizada e os re-

sultados obtidos. Para terminar, o Capıtulo 6 conclui resumindo o trabalho realizado e apresentando

trabalho futuro a desenvolver.

3

4

Capıtulo 2

Requisitos

De forma a compreender as necessidades do IPFN, previamente a realizacao desta tese, foi efetuado

um levantamento de requisitos documentado em [1]. Este documento descreve os requisitos que o

novo SGI do IPFN deve satisfazer, usando a Unified Modeling Language (UML) [7]. Os requisitos sao

descritos com base em Diagramas de Caso de Uso, Diagramas de Classes e Diagramas de Sequencia.

No documento de levantamento de requisitos, os requisitos encontram-se organizados em grupos

distintos, sendo que cada um possui um conjunto de responsabilidades.

Os grupos do novo SGI sao os seguintes:

1. Gestao de Recursos Humanos

(a) Gestao de Membros: Responsavel pela gestao das contas de membro dos utilizadores do

IPFN.

(b) Gestao de Perfil de Membro: Responsavel pela gestao dos perfis de membro, que estao

disponıveis para qualquer visitante do site do IPFN visualizar.

(c) Gestao de Assiduidade: Responsavel pela gestao da assiduidade dos membros do IPFN.

(d) Gestao de Missoes: Responsavel por listar as missoes que um membro tem no Dot e gerar

relatorios das missoes.

2. Gestao de Producao

(a) Gestao de Projetos: Responsavel pela gestao de todos os projetos do IPFN.

(b) Gestao de Producao Cientıfica: Responsavel pela gestao da producao cientıfica, isto e,

todos os documentos cientıficos produzidos pelo IPFN, tais como teses, patentes e artigos,

de modo a estarem disponıveis para consulta por qualquer visitante do site do IPFN.

(c) Gestao de Grupos de Investigacao: Responsavel pela gestao de informacao sobre os

Grupos de Investigacao do IPFN, disponıvel a qualquer visitante do site do IPFN.

(d) Gestao de Notıcias: Responsavel pela gestao de notıcias no site do IPFN.

3. Gestao de Ativos:

5

(a) Gestao de Aquisicoes: Responsavel pela gestao de toda a informacao o que esteja relaci-

onado com as aquisicoes do IPFN, como por exemplo pedidos de aquisicao e reembolsos.

(b) Gestao de Inventario: Responsavel pela gestao de todo o Inventario do IPFN, isto e, de

todos os recursos disponıveis no IPFN, tais como Licencas de Software, Equipamento e

Salas.

4. Suporte Informatico:

(a) Gestao de Tickets de Suporte: Responsavel pela gestao de Tickets que podem ser criados

por membros em caso de existencia de problema com o sistema informatico do IPFN.

(b) Gestao de Rede Informatica: Responsavel pela gestao de Pedidos de Enderecos IP que

podem ser criados por membros.

Esta tese foca-se nos grupos de Gestao de Recursos Humanos e Suporte Informatico. Os grupos

de Gestao de Producao e de Ativos sao desenvolvidos numa tese em separado [6]. Este capıtulo

esta organizado do seguinte modo: Na Seccao 2.1 sao detalhados o grupo de Gestao de Membros,

as caracterısticas associadas a membros, e os casos de uso para este grupo. Na Seccao 2.2 sao

detalhados o grupo de Gestao de Perfil de Membro, as caracterısticas associadas a cada perfil, e os

casos de uso para este grupo. Na Seccao 2.3 sao detalhados o grupo de Gestao de Assiduidade, as

caracterısticas associadas a presencas, ausencias, e pedidos de marcacao e alteracao, e os casos de

uso para este grupo. Na Seccao 2.4 sao detalhados o grupo de Gestao de Missoes, o uso do Sistema

Dot, e os casos de uso para este grupo. Na Seccao 2.5 sao detalhados o grupo de Gestao de Tickets

de Suporte, as caracterısticas associadas a tickets, e os casos de uso para este grupo. A Seccao 2.6

sao detalhados o grupo de Gestao de Rede Informatica, as caracterısticas associadas a pedidos de

endereco IP, e os casos de uso para este grupo.

Para cada grupo, existem diferentes nıveis de privilegios que diferentes membros podem ter. O

nıvel de privilegio de Membro indica que o membro tem acesso a funcionalidade basica do grupo,

enquanto que o nıvel de privilegio de Administrador indica que o membro tem acesso a funcionalidade

de administracao do grupo alem de ter acesso a funcionalidade basica.

2.1 Gestao de Membros

Todas as pessoas pertencentes ao IPFN devem estar registadas no SGI. Este registo levara a criacao

de um Membro no Sistema.

Um Membro tem as seguintes caracterısticas associadas:

1. Nome: O nome completo do Membro

2. Sexo: O genero do Membro.

3. Data de Nascimento: A data de nascimento do Membro.

6

4. Grau Academico: O grau academico do Membro. Pode ser “Primario”, “Secundario”, “Licencia-

tura”, “Mestrado” ou “Doutoramento”

5. Email: O endereco de email do Membro.

6. Telefone: O numero de telefone do Membro.

7. Extensao: O numero da extensao telefonica do Membro.

8. Morada: A morada completa do Membro.

9. ORCID ID: O identificador do Membro no ORCID1.

10. Chave Publica: A chave publica do Membro na FCT2.

11. Colaborador: Indica se o Membro e um colaborador ou nao.

12. Linha Tematica: A linha tematica a que o Membro pertence dentro do IPFN.

13. Funcoes: As funcoes do Membro dentro do IPFN.

14. Categoria: A categoria do Membro dentro do IPFN.

15. Tipo de Contrato: O tipo do contrato que o Membro tem com o IPFN.

16. Contratos: Uma lista dos contratos entre o Membro e o IPFN. Cada contrato tem uma Data de

Inıcio, uma Data de Fim e uma Descricao.

17. Codigo de Bolsa: O codigo da bolsa a que o Membro esta associado (se for um bolseiro).

18. Permissoes: A lista de permissoes do Membro, que indica os nıveis de privilegio que o Membro

tem para cada um dos grupos no sistema.

19. Observacoes: Observacoes adicionais relativas ao Membro.

20. Fotografia: Uma fotografia do Membro.

A Gestao de Membros e responsavel pela gestao dos registos de Membro, e deve incluir os casos

de uso representados no diagrama da Figura 2.1 e detalhados abaixo. Os atores intervenientes sao: o

Membro, o Administrador e o Sistema Fenix.

1. Listar Membros: O sistema deve listar todos os registos de Membro que foram criados. Deve

ser tambem possıvel filtrar os resultados por Nome, Email ou Extensao, e ordenar os resultados

segundo os mesmos criterios.

2. Adicionar Membro: O administrador deve poder adicionar registos de Membro, para isso indi-

cando todos as caracterısticas para o novo registo.

1http://orcid.org/2http://www.fct.pt/

7

Figura 2.1: Diagrama de Casos de Uso para a Gestao de Membros.

3. Editar Membro: Selecionando um registo de Membro, o administrador deve poder editar as infor-

macoes do registo, para isso indicando as alteracoes a efetuar.

4. Adicionar Contrato a Membro: O administrador deve poder adicionar contratos a um registo de

Membro, para isso indicando uma Data de Inıcio, uma Data de Fim e uma Descricao para o novo

contrato.

5. Remover Contrato a Membro: Selecionando um contrato a remover, o administrador deve poder

apagar este contrato.

6. Alterar Permissoes de Membro: O administrador deve poder alterar as permissoes de um re-

gisto de Membro, para isso indicando as permissoes que o Membro passa a ter.

7. Sincronizar Informacao Pessoal de Membro: O sistema deve automaticamente e periodica-

mente sincronizar a informacao pessoal dos membros com a plataforma Fenix do IST. Os mem-

bros do IPFN, sendo esta uma unidade de investigacao do IST, sao tambem membros do IPFN

e, portanto, estao registados como membros na plataforma Fenix, e e importante que o sistema

mantenha a informacao sincronizada.

8

2.2 Gestao de Perfil de Membro

Cada membro do IPFN deve ter um Perfil de Membro, que guarda informacao sobre ele. Esta informacao

e publica, portanto pode ser visualizada por pessoas exteriores ao IPFN.

Cada registo de Membro tem, associado a este, um Perfil de Membro, que tem como caracterıstica

uma Descricao do Membro.

A Gestao de Perfil de Membro e responsavel por disponibilizar a informacao de Perfil dos Membros

do IPFN, assim como permitir a sua edicao, e deve incluir os casos de uso representados no diagrama

da Figura 2.2 e detalhados abaixo. Os atores intervenientes sao: o Membro, e o Utilizador Anonimo.

Figura 2.2: Diagrama de Casos de Uso para a Gestao de Perfil de Membro.

1. Listar Perfis de Membro: O sistema deve devolver uma lista de membros presentes no sistema,

e, para cada membro, deve indicar o seu Nome, o seu ORCID ID e um URL para visualizar a

sua fotografia. Esta acao deve estar disponıvel para pessoas exteriores ao IPFN atraves de uma

Application Programming Interface (API).

2. Consultar Perfil de Membro: Selecionando um Membro, o sistema deve devolver o seu Nome,

o seu Sexo, o seu ORCID ID, a sua Data de Nascimento, o seu Email, o seu Telefone, a sua

Extensao, o seu Grau Academico, a sua Entidade, se e Colaborador, a sua Linha Tematica, o seu

ORCID ID, a Descricao do seu Perfil de Membro, o ano da data de inicio do seu primeiro Contrato,

o ano da data de fim do seu ultimo Contrato e um URL para visualizar a sua fotografia. Esta acao

deve estar disponıvel para pessoas exteriores ao IPFN atraves de uma API.

3. Editar Dados Pessoais: O membro deve poder editar os valores de Telefone, Email e Descricao

do seu Perfil de Membro.

9

2.3 Gestao de Assiduidade

Os membros do IPFN devem registar as suas presencas, indicando as horas em que comecam e

terminam de trabalhar para cada dia. Para tal, podem indicar quando iniciam e terminam trabalho, ou

podem fazer um Pedido de Marcacao para adicionar registos de Presenca. Os registos de Presenca

podem tambem ser corrigidos com Pedidos de Alteracao. No caso em que o membro se ausenta do

trabalho, este deve fazer um Pedido de Ausencia para adicionar registos de Ausencia.

Todos os pedidos devem ser analisados por um administrador, e este pode aprovar ou rejeitar o

pedido. Se aprovar o pedido, os novos registos (ou as alteracoes aos registos no caso dos Pedidos de

Alteracao) indicados no pedido dever ser automaticamente guardadas.

Uma Presenca tem as seguintes caracterısticas associadas:

1. Membro: O registo de Membro do membro que esteve a trabalhar.

2. Inıcio: A data e hora em que o membro iniciou o seu trabalho.

3. Fim: A data e hora em que o membro terminou o seu trabalho.

4. Projeto: O Projeto para o qual o membro esteve a trabalhar. A gestao de Projetos e da res-

ponsabilidade do grupo de Gestao de Projetos, que foi desenvolvido fora do ambito desta tese

[6].

5. Local de Trabalho: O Local de Trabalho onde o membro realizou o seu trabalho.

6. Descricao: Uma curta descricao do que o membro esteve a trabalhar.

Os Pedidos de Marcacao e Pedidos de Alteracao tem tambem os mesmos atributos que Presencas,

mas adicionalmente tem: uma justificacao para realizar o pedido, um estado (que pode ser “Pendente”,

“Aprovado” ou “Rejeitado”) e, exclusivamente para Pedidos de Marcacao, um motivo para realizar o

pedido.

Uma Ausencia tem as seguintes caracterısticas associadas:

1. Membro: O registo de Membro do membro que esteve ausente.

2. Inıcio: A data e hora do inıcio da ausencia do membro ao trabalho.

3. Fim: A data e hora do fim da ausencia do membro ao trabalho.

4. Motivo de Ausencia: O motivo para a ausencia do membro.

Os Pedidos de Ausencia tem tambem as mesmas caracterısticas que Ausencias, mas adicional-

mente um estado (que pode ser “Pendente”, “Aprovado” ou “Rejeitado”).

Para alem de Presencas e Ausencias, a Gestao de Assiduidade deve ainda permitir registar os

seguintes dados:

1. Locais de Trabalho: Os diferentes locais de trabalho que um membro pode escolher quando

regista uma Presenca. Cada local de trabalho tem um fuso horario associado.

10

2. Motivos de Pedido de Marcacao: Os diferentes motivos que um membro pode escolher quando

adiciona um Pedido de Marcacao.

3. Motivos de Ausencia: Os diferentes motivos de ausencia que um membro pode escolher quando

adiciona um Pedido de Ausencia.

4. Feriados: Uma lista de datas que correspondem a feriados.

5. Perıodos de Horas de Trabalho Diarias: O numero de horas a realizar por dia pelos membros

do IPFN para cada perıodo de tempo.

A Gestao de Assiduidade e responsavel pela gestao da assiduidade dos varios membros do IPFN, e

deve incluir os casos de uso representados no diagrama da Figura 2.3 e detalhados abaixo. Os atores

intervenientes sao: o Membro, e o Administrador.

1. Listar Presencas: O sistema deve listar todas as Presencas que foram criadas pelo membro.

Deve ser tambem possıvel filtrar os resultados por Local de Trabalho, Projeto, Data de Inıcio ou

Data de Fim, e ordenar os resultados pelos mesmos criterios.

2. Listar Pedidos de Marcacao: O sistema deve listar todos os Pedidos de Marcacao que foram cri-

ados pelo membro. Deve ser tambem possıvel filtrar os resultados por Estado, Local de Trabalho,

Projeto, Motivo, Data de Inıcio ou Data de Fim, e ordenar os resultados pelos mesmos criterios.

3. Listar Pedidos de Alteracao: O sistema deve listar todos os Pedidos de Alteracao que foram cri-

ados pelo membro. Deve ser tambem possıvel filtrar os resultados por Estado, Local de Trabalho,

Projeto, Data de Inıcio ou Data de Fim, e ordenar os resultados pelos mesmos criterios.

4. Listar Pedidos de Ausencia: O sistema deve listar todos os Pedidos de Ausencia que foram

criados pelo membro. Deve ser tambem possıvel filtrar os resultados por Estado, Data de Inıcio

ou Data de Fim, e ordenar os resultados pelos mesmos criterios.

5. Listar Pedidos de Marcacao de todos os Membros: O sistema deve listar todos os Pedidos de

Marcacao que foram criados. Deve ser tambem possıvel filtrar os resultados por Membro, Local de

Trabalho, Projeto, Motivo, Data de Inıcio ou Data de Fim, e ordenar os resultados pelos mesmos

criterios. Apenas administradores podem realizar esta acao.

6. Listar Pedidos de Alteracao de todos os Membros: O sistema deve listar todos os Pedidos de

Alteracao que foram criados. Deve ser tambem possıvel filtrar os resultados por Membro, Local de

Trabalho, Projeto, Data de Inıcio ou Data de Fim, e ordenar os resultados pelos mesmos criterios.

Apenas administradores podem realizar esta acao.

7. Listar Pedidos de Ausencia de todos os Membros: O sistema deve listar todos os Pedidos

de Ausencia que foram criados. Deve ser tambem possıvel filtrar os resultados por Membro,

Motivo, Data de Inıcio ou Data de Fim, e ordenar os resultados pelos mesmos criterios. Apenas

administradores podem realizar esta acao.

11

Figura 2.3: Diagrama de Casos de Uso para a Gestao de Assiduidade.

8. Listar Locais de Trabalho: O sistema deve listar todos os Locais de Trabalho que foram criados.

Apenas administradores podem realizar esta acao.

9. Listar Motivos de Pedido de Marcacao: O sistema deve listar todos os Motivos de Pedido de

Marcacao que foram criados. Apenas administradores podem realizar esta acao.

10. Listar Motivos de Ausencia: O sistema deve listar todos os Motivos de Ausencia que foram

criados. Apenas administradores podem realizar esta acao.

11. Listar Feriados: O sistema deve listar todos os Feriados que foram criados. Apenas administra-

dores podem realizar esta acao.

12

12. Listar Perıodos de Horas de Trabalho Diarias: O sistema deve listar todos os Perıodos de

Horas de Trabalho Diarias que foram criados. Apenas administradores podem realizar esta acao.

13. Consultar Estatıstica: O sistema deve calcular e mostrar o numero de dias, horas e minutos

totais para cada projeto no perıodo de tempo indicado pelo membro.

14. Gerar Relatorio de Estatıstica: O sistema deve calcular e gerar um relatorio (em formato PDF)

com o numero de dias, horas e minutos totais para cada projeto no perıodo de tempo indicado

pelo membro, assim como a lista de todos os registos de Presenca e de Ausencia do membro

para o mesmo perıodo.

15. Iniciar Trabalho: O membro deve poder registar que iniciou trabalho, indicando qual o Projeto

para o qual vai trabalhar e qual o Local de Trabalho. O sistema regista a nova Presenca com

os dados indicados, guardando tambem, na caracterıstica Inıcio, a data e hora no momento do

registo e, no atributo Membro, o registo de Membro do membro que iniciou o trabalho.

16. Terminar Trabalho: O membro deve poder indicar que terminou o trabalho. O sistema regista, na

ultima Presenca registada pelo membro, na caracterıstica Fim, a data e hora em que o membro

indicou que terminou o trabalho.

17. Adicionar Pedido de Marcacao: O membro deve poder adicionar Pedidos de Marcacao, in-

dicando o Projeto, Local de Trabalho, Descricao, Inıcio, Fim, Motivo e Justificacao. O sistema

regista um novo pedido com os valores indicados, guardando tambem, na caracterıstica Membro,

o registo de Membro do autor do pedido.

18. Adicionar Pedido de Alteracao: O membro deve poder adicionar Pedidos de Alteracao, indi-

cando o registo de Presenca a alterar, o Projeto, Local de Trabalho, Descricao, Inıcio, Fim e

Justificacao. O sistema regista um novo pedido com os valores indicados, guardando tambem, no

atributo Membro, o registo de Membro do autor do pedido.

19. Adicionar Pedido de Ausencia: O membro deve poder adicionar Pedidos de Ausencia, indicando

o Inıcio, Fim e Motivo. O sistema regista um novo pedido com os valores indicados, guardando

tambem, no atributo Membro, o registo de Membro do autor do pedido.

20. Responder a Pedido de Marcacao: O administrador deve poder responder a Pedidos de Marcacao,

indicando se o pedido e aprovado ou rejeitado. Caso seja aprovado, o sistema deve criar registos

de Presenca conforme indicado no pedido.

21. Responder a Pedido de Alteracao: O administrador deve poder responder a Pedidos de Alteracao,

indicando se o pedido e aprovado ou rejeitado. Caso seja aprovado, o sistema deve alterar o re-

gisto de Presenca conforme indicado no pedido.

22. Responder a Pedido de Ausencia: O administrador deve poder responder a Pedidos de Ausencia,

indicando se o pedido e aprovado ou rejeitado. Caso seja aprovado, o sistema deve criar registos

de Ausencia conforme indicado no pedido.

13

23. Adicionar Local de Trabalho: O administrador deve poder adicionar um Local de Trabalho, indi-

cando o nome do local.

24. Editar Local de Trabalho: O administrador deve poder editar um Local de Trabalho, mudando o

nome do local.

25. Tornar Local de Trabalho Predefinido: O administrador deve poder marcar um Local de Trabalho

como predefinicao, sendo este o local selecionado por defeito. Apenas pode existir um local

marcado como predefinicao. Caso se tente mudar o local predefinido, o anterior passa a nao

estar marcado como predefinido.

26. Adicionar Motivo de Pedido de Marcacao: O administrador deve poder adicionar um Motivo de

Pedido de Marcacao, indicando o nome do motivo.

27. Editar Motivo de Pedido de Marcacao: O administrador deve poder editar um Motivo de Pedido

de Marcacao, mudando o nome do motivo.

28. Adicionar Motivo de Ausencia: O administrador deve poder adicionar um Motivo de Ausencia,

indicando o nome do motivo.

29. Editar Motivo de Ausencia: O administrador deve poder editar um Motivo de Ausencia, mudando

o nome do motivo.

30. Adicionar Feriado: O administrador deve poder adicionar um Feriado, indicando a data e o nome

do Feriado.

31. Editar Feriado: O administrador deve poder editar um Feriado, indicando uma nova a data e um

novo nome para o Feriado.

32. Adicionar Perıodo de Horas de Trabalho Diarias: O administrador deve poder adicionar Perıodos

de Horas de Trabalho Diarias, indicando a data de inıcio e a data de fim do perıodo, e quantas

horas de trabalho diarias sao aplicadas durante esse perıodo.

33. Editar Perıodo de Horas de Trabalho Diarias: O administrador deve poder editar Perıodos de

Horas de Trabalho Diarias, indicando novos valores para a data de inıcio, a data de fim e horas de

trabalho diarias.

34. Eliminar Perıodo de Horas de Trabalho Diarias: O administrador deve poder eliminar Perıodos

de Horas de Trabalho Diarias.

2.4 Gestao de Missoes

Os membros do IPFN tem a possibilidade de realizar Missoes (por exemplo, viagens a conferencias),

tendo que criar um Processo de Missao que, depois de avaliado, podera ser aceite. Para a gestao

destes Processos de Missao, o IPFN utiliza o sistema Dot3, uma ferramenta pertencente ao IST, que ja3https://dot.tecnico.ulisboa.pt

14

oferece funcionalidade para criar, pesquisar, listar e rever processos de missao, assim como o workflow

de um processo de missao. O IPFN pretende continuar a utilizar o Dot para a gestao de Missoes.

No entanto, os membros do IPFN necessitam tambem de funcionalidade no novo SGI que o Dot nao

oferece, como por exemplo a geracao de relatorios em PDF do pedido de missao.

A Gestao de Missoes e responsavel por disponibilizar funcionalidade adicional a gestao de missoes

do Dot, e deve incluir os casos de uso representados no diagrama da Figura 2.4 e detalhados abaixo.

Os atores intervenientes sao: o Membro, e o Sistema Dot.

Figura 2.4: Diagrama de Casos de Uso para a Gestao de Missoes.

1. Listar Missoes. Embora o Dot permita listar processos de missao, e importante para os membros

do IPFN obter essa listagem, juntamente com a informacao do estado do processo e o numero

de comentarios, diretamente no novo SGI.

2. Gerar Relatorio de Missao. O novo SGI deve solicitar ao Dot todas as informacoes de um

processo de missao e, com estas informacoes, gerar um relatorio (em formato PDF) que obedeca

as regras impostas ao IPFN para relatorios de processo de missao.

2.5 Gestao de Tickets de Suporte

Em caso de problema, um membro tem a possibilidade de criar um Ticket de Suporte, com a descricao

do problema. Este Ticket de Suporte sera depois analisado e, quando o problema estiver resolvido, o

Ticket de Suporte passara ao estado concluıdo.

Um Ticket de Suporte tem as seguintes caracterısticas associadas:

1. Tıtulo: Indica sucintamente o problema a que o Ticket de Suporte se refere.

2. Descricao: Uma descricao mais detalhada do problema a que o Ticket de Suporte se refere.

3. Criado por: O registo de Membro do membro que criou o Ticket de Suporte.

4. Data de Criacao: A data e hora a que foi criado o Ticket de Suporte.

15

5. Estado: O estado do Ticket de Suporte, que pode ser “Pendente” (caso a resolucao do pro-

blema ainda nao tenha sido iniciada), “Em Progresso” (caso o problema esteja a ser resolvido) ou

“Concluıdo” (apos a resolucao do problema).

Adicionalmente, um membro pode adicionar comentarios publicos aos tickets que criou. Adminis-

tradores podem adicionar comentarios publicos ou internos em qualquer ticket. Comentarios internos

apenas podem ser vistos por outros administradores, enquanto que comentarios publicos sao visıveis

tambem pelo membro que criou o ticket onde foi feito o comentario.

A Gestao de Tickets de Suporte e responsavel pela gestao dos Tickets de Suporte e os seus co-

mentarios, e deve incluir os casos de uso representados no diagrama da Figura 2.5 e detalhados abaixo.

Os atores intervenientes sao: o Membro, e o Administrador.

Figura 2.5: Diagrama de Casos de Uso para a Gestao de Tickets de Suporte.

1. Listar Tickets de Suporte: O sistema deve listar todos os Tickets de Suporte que foram cria-

dos pelo membro. Deve ser tambem possıvel filtrar os resultados por Tıtulo, Descricao, Data de

Criacao ou Estado do Ticket de Suporte, e ordenar os resultados pelos mesmos criterios. Apenas

administradores podem listar tickets criados por outro membro.

2. Consultar Ticket de Suporte: Selecionando um Ticket de Suporte, o sistema deve devolver

informacao detalhada do mesmo, listando os valores de todos os atributos do Ticket de Suporte,

assim como todos os comentarios publicos adicionados ao ticket. Apenas administradores podem

consultar tickets criados por outros membros, e tem acesso aos comentarios internos.

16

3. Adicionar Ticket de Suporte: O membro deve poder adicionar Tickets de Suporte, para isso

indicando um Tıtulo e uma Descricao para o Ticket de Suporte. O sistema regista um novo Ticket

de Suporte com os valores indicados, guardando tambem, no atributo Data de Criacao, a data

e hora no momento do registo, no atributo Membro, o registo de Membro do autor do Ticket de

Suporte e, no atributo Estado, “Pendente”.

4. Marcar Ticket de Suporte como Em Progresso: Durante a resolucao do problema, o Ticket de

Suporte pode ser marcado como estando em processo de ser resolvido, mudando o seu estado

para “Em Progresso”. Apenas administradores podem realizar esta acao.

5. Marcar Ticket de Suporte como Concluıdo: Apos a resolucao do problema, o Ticket de Suporte

pode ser marcado como concluıdo, mudando o seu estado para “Concluıdo”. Apenas administra-

dores podem realizar esta acao.

6. Marcar Ticket de Suporte como Pendente: Caso seja necessario reabrir um Ticket de Suporte,

pode-se marca-lo como pendente, mudando o seu estado para “Pendente”. Apenas administra-

dores podem realizar esta acao.

7. Adicionar Comentario a Ticket de Suporte: Os membros devem poder adicionar comentarios

a Tickets de Suporte, para isso indicando o texto do novo comentario. O sistema regista um

novo comentario de Suporte com o texto indicado. Apenas administradores podem adicionar

comentarios a tickets criados por outros membros, e adicionar comentarios internos.

2.6 Gestao de Rede Informatica

Os membros tem a possibilidade de fazer Pedidos de Endereco IP, caso seja necessario reservar um

endereco IP para um dispositivo pertencente ao IPFN.

Um Pedido de Endereco IP tem as seguintes caracterısticas associadas:

1. Endereco IP: O endereco IP a ser pedido.

2. Endereco MAC: O endereco MAC da maquina que ira utilizar o endereco IP pedido.

3. Host: O nome da maquina que ira utilizar o endereco IP pedido.

4. Localizacao da Maquina: Descricao sucinta da localizacao fısica onde se encontra a maquina

que ira utilizar o endereco IP pedido.

5. IP Publico: Indica se o endereco IP pedido e publico ou privado.

6. Data de Inıcio: A data a partir da qual o endereco IP pedido devera estar reservado para a

maquina indicada.

7. Data de Fim: A data a partir da qual o endereco IP pedido podera ser libertado.

8. Criado por: O registo de Membro do membro que criou o Pedido de Endereco IP.

17

9. Data de Criacao: A data e hora a que foi criado o Pedido de Endereco IP.

10. Justificacao: A razao para pedir o endereco IP.

11. Estado: O estado do Pedido IP, que pode ser “Pendente”, “Aprovado”, “Rejeitado”, “Terminado”,

“Abandonado” ou “Expirado”.

A Gestao de Rede Informatica e responsavel pela gestao dos pedidos de endereco IP, e deve incluir

os casos de uso representados no diagrama da Figura 2.6 e detalhados abaixo. Os atores intervenien-

tes sao: o Membro, e o Administrador.

Figura 2.6: Diagrama de Casos de Uso para a Gestao de Rede Informatica.

1. Listar Pedidos de Endereco IP: O sistema deve listar todos os Pedidos de Endereco IP que

foram criados pelo membro. Deve ser tambem possıvel filtrar os resultados por Endereco IP ou

Data de Criacao, e ordenar os resultados por Endereco IP, Endereco MAC, Host, Localizacao da

Maquina, Data de Inıcio, Data de Fim ou Data de Criacao. Apenas administradores podem listar

pedidos criados por outro membro.

2. Consultar Pedido de Endereco IP: Selecionando um Pedido de Endereco IP, o sistema deve

devolver informacao detalhada do mesmo, listando os valores de todos os atributos do Pedido de

Endereco IP. Apenas administradores podem consultar pedidos criados por outro membro.

18

3. Adicionar Pedido de Endereco IP: O membro deve poder adicionar Pedidos de Endereco IP,

para isso indicando o Endereco MAC, o Host, a Localizacao da Maquina, se e um endereco

IP publico ou privado, a Data de Inıcio, a Data de Fim e a Justificacao para o pedido. O sistema

regista um novo Pedido de Endereco IP com os valores indicados, guardando tambem, no atributo

Data de Criacao, a data e hora no momento do registo, no atributo Membro, o registo de Membro

do autor do Pedido de Endereco IP, e colocando o estado como “Pendente”.

4. Aprovar Pedido de Endereco IP: Depois de realizado um Pedido de Endereco IP, este pode ser

aprovado, sendo necessario indicar um Endereco IP. Ao faze-lo, o estado o pedido muda para

“Aprovado”. Apenas administradores podem realizar esta acao.

5. Rejeitar Pedido de Endereco IP: Depois de realizado um Pedido de Endereco IP, este pode ser

rejeitado. Ao faze-lo, o estado o pedido muda para “Rejeitado”. Apenas administradores podem

realizar esta acao.

6. Terminar Pedido de Endereco IP: Depois de aprovado, um Pedido de Endereco IP pode ser

terminado, caso o endereco IP ja nao seja necessario. Ao faze-lo, o estado o pedido muda para

“Terminado”. Apenas administradores podem realizar esta acao.

7. Abandonar Pedido de Endereco IP: Depois de realizado um Pedido de Endereco IP, este pode

ser abandonado, caso o endereco IP ja nao seja necessario. Ao faze-lo, o estado o pedido muda

para “Abandonado”. Apenas o membro que criou o pedido pode abandona-lo.

8. Renovar Pedido de Endereco IP: Depois de realizado um Pedido de Endereco IP, este pode ser

renovado, sendo necessario indicar uma nova Data de Fim. O sistema deve criar um novo Pedido

de Endereco com os mesmos valores que o pedido anterior, mas com a nova Data de Fim e no

estado “Pendente”. Apenas o membro que criou o pedido pode renova-lo.

19

20

Capıtulo 3

Trabalho Relacionado

De forma a aprofundar o conhecimento sobre os SGI existentes, foi recolhida informacao sobre diferen-

tes tipos, em particular: (i) Sistemas de Gestao Academica, (ii) Sistemas de Gestao de Workflows, nor-

malmente conhecidos como WMS [2], (iii) Sistemas Integrados de Gestao Empresarial, normalmente

conhecidos como sistemas ERP [3], (iv) Sistemas de Gestao de Recursos Humanos, normalmente

conhecidos como sistemas HRM [4], (v) Sistemas de Gestao de Tickets de Suporte, normalmente co-

nhecidos como ITS [5].

A Seccao 3.1 lista os sistemas que foram estudados e descreve o processo de selecao utilizado na

escolha destes sistemas. A Seccao 3.2 detalha as caracterısticas utilizadas para analisar cada sistema.

As Seccoes 3.4.1 a 3.7.1 descrevem cada um dos sistemas estudados, segundo as caracterısticas

listadas na Seccao 3.2. Para finalizar, a Seccao 3.8 analisa as hipoteses para a implementacao do

novo SGI do IPFN, e concluı indicando qual das hipoteses melhor se adequa para esse fim.

3.1 Selecao dos Sistemas de Gestao de Informacao

Hoje em dia, encontra-se no mercado um grande numero de solucoes para SGI com funcionalidades

compatıveis com as necessidades do novo SGI do IPFN. Destes, foram selecionados 13 SGI diferentes

para serem analisados. Para selecionar quais os SGI a analisar, primeiro, selecionamos os sistemas

que possuem funcionalidades que satisfazem os requisitos listados no Capıtulo 2. Segundo, foi dada

preferencia a sistemas open source e/ou que disponibilizem uma API. Estes permitem a integracao com

outros sistemas, e podem ser estendidos de maneira a satisfazer mais requisitos que possam aparecer

no futuro. Finalmente, foi tambem dada preferencia a sistemas que estejam a ser usados por instituicoes

de ensino superior e/ou centros de investigacao cientıfica, ou que tenham sido desenvolvidos com foco

para o uso por parte deste tipo de instituicoes, pois apresentam uma maior possibilidade de ir ao

encontro das necessidades do IPFN.

Os Sistemas que foram analisados sao os seguintes:

1. Sistemas de Gestao Academica

21

(a) FenixEdu1

2. Sistemas de Gestao de Workflows

(a) Dot2

3. Sistemas Integrados de Gestao Empresarial

(a) 1ERP3

(b) Apache OFBiz4

(c) ERPNext5

(d) GrowERP6

(e) JFire7

(f) Microsoft Dynamics AX8

(g) Odoo9

(h) Primavera10

(i) SAP ERP11

4. Sistemas de Gestao de Recursos Humanos

(a) OrangeHRM12

5. Sistemas de Gestao de Tickets de Suporte

(a) osTicket13

Estes sistemas foram agrupados segundo o seu tipo. Dentro de cada grupo, foram ordenados por

ordem alfabetica do seu nome.

3.2 Caracterısticas Analisadas

Para garantir uma analise justa dos varios SGI, foram analisadas as mesmas caracterısticas para todos.

As caracterısticas analisadas estao divididas em dois grupos diferentes:

1. Informacao Geral do Sistema

1http://fenixedu.org2https://dot.tecnico.ulisboa.pt3http://www.quidgest.pt/e_qerpPT.asp4http://ofbiz.apache.org/index.html5https://erpnext.com6http://www.growerp.com/cms/cms7http://www.jfire.net8https://www.microsoft.com/en-us/dynamics/default.aspx9https://www.odoo.com

10hhttp://pt.primaverabss.com/pt11http://go.sap.com12http://www.orangehrm.com13http://osticket.com

22

2. Funcionalidades Presentes no Sistema

Para o primeiro grupo de caracterısticas, isto e, Informacao Geral do Sistema, as caracterısticas sao

as seguintes:

• Equipa de Desenvolvimento: O nome da entidade responsavel pelo desenvolvimento do sis-

tema.

• Open Source?: Indica se o sistema e open source. Se for, indica tambem qual a licenca utilizada.

• Custo de Licenca: O custo da licenca para a utilizacao do sistema.

• SaaS?: Indica se e possıvel a utilizacao do sistema numa modalidade de Software as a Ser-

vice (SaaS). SaaS (Software como Servico) consiste numa forma de comercializacao de soft-

ware, a base de uma subscricao, em que o fornecedor se responsabiliza por toda a infraestrutura

necessaria para a disponibilizacao do sistema, tal como servidores, bases de dados e cuidados

com seguranca da informacao.

• Ultima Versao: A data da ultima versao estavel do sistema. Utilizado para verificar se o sis-

tema ainda esta a ser suportado, ou foi abandonado (datas mais recentes indicam uma maior

probabilidade de que o sistema ainda e suportado)

• Suporte: Indica se o sistema disponibiliza suporte em caso de duvida ou problema. Caso so seja

disponibilizado se o sistema for utilizado como servico, tambem sera indicado aqui.

• Multi-Lıngua: Indica se o sistema pode ser usado em Portugues, Ingles, ou ambos.

• Focado na Investigacao Cientıfica?: Indica se o sistema foi desenvolvido com um foco nos

Sectores de Investigacao Cientıfica e/ou de Ensino Superior.

• Bases de Dados Compatıveis: Lista de bases de dados compatıveis com o sistema.

• Dependencias: Lista de outras tecnologias necessarias para o sistema funcionar.

• Servidor: Indica se e possıvel instalar o servidor do sistema numa maquina local, na nuvem, ou

ambos.

• Aplicacao Cliente Web based: Indica se o sistema disponibiliza um cliente que pode ser acedido

por um browser e, se tal for o caso, se a interface e adaptavel a dispositivos moveis.

• Sistemas Operativos Compatıveis: Indica a compatibilidade da aplicacao cliente nos varios

sistemas operativos mais usados (Windows, OS X, Linux, iOS, Android e Windows Phone).

• Extensıvel: Indica se e possıvel estender a funcionalidade do sistema. Se apenas for possıvel

atraves de add-ons pagos, tambem sera indicado aqui.

• API: Indica se o sistema disponibiliza uma API que permite a outro software interagir com o

sistema.

23

Para o segundo grupo de caracterısticas, isto e, Funcionalidades Presentes no Sistema, as carac-

terısticas sao as seguintes:

• Gestao de Membros: Indica se o sistema permite a gestao de utilizadores do sistema, permitindo

listar os utilizadores do sistema, adicionar novos utilizadores e/ou editar as suas informacoes

pessoais.

• Gestao de Perfil de Membro: Indica se o sistema permite a cada utilizador ter um perfil publico,

disponibilizado num portal web, com as suas informacoes pessoais.

• Gestao de Assiduidade: Indica se o sistema permite um controlo da assiduidade de cada uti-

lizador, registando presencas e faltas de cada utilizador, horas de inıcio e fim de trabalho, e

justificacoes para as faltas.

• Gestao de Missoes: Indica se o sistema permite um controlo das viagens de trabalho dos utili-

zadores, permitindo realizar pedidos de viagem e aceitar ou recusar pedidos.

• Suporte Informatico: Indica se o sistema permite aos seus utilizadores criat tickets de suporte

que podem a posteriori serem consultados e resolvidos.

Caso o sistema apenas tenha a funcionalidade de um modulo atraves de add-on, estara indicado dessa

maneira.

3.3 Sistemas de Gestao Academica

3.3.1 FenixEdu

O FenixEdu e um Sistema de Gestao Academica open source desenvolvido pela Direcao de Servicos

Informaticos (DSI) do IST e focado no sector de ensino superior. Este sistema esta ao abrigo da licenca

GNU Lesser General Public License (LGPL) v3, que permite a liberdade de utilizar, modificar, e distribuir

o Sistema sem qualquer custo. Com este sistema e disponibilizada documentacao do sistema, mas nao

e disponibilizado qualquer suporte em caso de duvida ou problema.

O FenixEdu foi desenvolvido em Java, utilizando a BennuFramework14, e e compatıvel com base de

dados MySQL.

O IST nao oferece uma solucao de cloud-hosting, logo o servidor tem de ser um servidor local, gerido

e mantido pela entidade que adquirir o sistema. Para o correto funcionamento do servidor, e necessario

instalar JDK versao 1.8 e Maven. A aplicacao cliente e acessıvel atraves de um web browser, o que

implica que nao e necessaria a sua instalacao nos computadores dos utilizadores, e que e compatıvel

com Sistemas Operativos Windows, OS X e Linux. A aplicacao cliente possui uma interface adaptavel

a dispositivos moveis, o que permite a sua utilizacao em Sistemas Operativos iOS, Android e Windows

Phone, e esta disponıvel em Portugues e em Ingles.

14https://github.com/FenixEdu/bennu

24

O sistema oferece funcionalidade que permite a gestao de Membros e a gestao de Perfil de Membro.

O site indica ainda que e possıvel expandir a funcionalidade do sistema dado que e um sistema open

source.

O IPFN, visto ser um centro de investigacao pertencente ao IST, utiliza o FenixEdu para a gestao

dos seus membros. Cada membro do IPFN e obrigado a ter uma conta no FenixEdu do IST, cujas

credenciais sao utilizadas para entrar no atual Intranet.

3.4 Sistemas de Gestao de Workflows

3.4.1 Dot

O Dot e um WMS, desenvolvido pela DSI do IST e utilizado internamente no IST, focado no sector de

ensino superior.

O FenixEdu foi desenvolvido em Java, utilizando a BennuFramework, e e compatıvel com base de

dados MySQL.

O IST nao oferece uma solucao de cloud-hosting, logo o servidor tem de ser um servidor local,

gerido e mantido pela entidade que adquirir o sistema. Para o correto funcionamento do servidor,

e necessario instalar JDK versao 1.8 e Maven. A aplicacao cliente e acessıvel atraves de um web

browser, o que implica que nao e necessaria a sua instalacao nos computadores dos utilizadores, e

que e compatıvel com Sistemas Operativos Windows, OS X e Linux. A aplicacao cliente nao possui

uma interface adaptavel a dispositivos moveis, o que limita a sua utilizacao em Sistemas Operativos

iOS, Android e Windows Phone, e esta disponıvel em Portugues e em Ingles.

O Sistema oferece funcionalidade que permite a gestao de Missoes.

O IPFN, visto ser um centro de investigacao pertencente ao IST, utiliza o Dot para a sua gestao de

missoes. Como indicado na Seccao 2.4, embora o sistema permita ao IPFN realizar todo o processo

de autorizacao de um pedido de missao atraves do Dot, ainda e necessario funcionalidade adicional,

nomeadamente a listagem dos pedidos de missao no SGI do IPFN e a geracao de relatorios em formato

PDF.

3.5 Sistemas Integrados de Gestao Empresarial

3.5.1 1ERP

O 1ERP e um Sistema ERP closed source desenvolvido pela Quidgest15 e focado no sector empresarial.

A utilizacao deste Sistema esta sujeita a um plano de pagamento, dependente de negociacao direta

com a empresa. Com este sistema e disponibilizado documentacao do sistema e suporte em caso de

duvida ou problema.

15http://www.quidgest.pt

25

O 1ERP foi construıdo de forma modular, com base em tecnologias Microsoft, IBM e Oracle. Foi

desenvolvido em Visual C++, C# e Java, e e compatıvel com base de dados Microsoft SQL Server e

Oracle.

A empresa nao oferece uma solucao de cloud-hosting, logo o servidor tem de ser local, gerido e

mantido pela entidade que adquirir o sistema. A aplicacao cliente nao e acessıvel atraves de um web

browser, o que implica a sua instalacao nos computadores dos utilizadores. Existe apenas aplicacao

cliente para Sistemas Operativos Windows, e apenas esta disponıvel em Portugues.

Segundo a informacao disponıvel no site oficial do 1ERP, este sistema oferece funcionalidade que

se enquadra em todos os itens apontados na Seccao 3.2 para o segundo grupo de caracterısticas, isto

e, Funcionalidades Presentes no Sistema. O site indica ainda que e possıvel expandir a funcionalidade

do Sistema entrando em contacto com a empresa.

3.5.2 Apache OFBiz

O Apache OFBiz e um Sistema ERP open source desenvolvido pela Apache16 e focado no sector

empresarial. Este sistema esta ao abrigo da licenca Apache License 2.0, que permite a liberdade

de utilizar, modificar, e distribuir o sistema sem qualquer custo. Com este sistema e disponibilizada

documentacao, mas nao e disponibilizado qualquer suporte em caso de duvida ou problema.

O Apache OFBiz foi desenvolvido em Java, e e compatıvel com base de dados MySQL, PostgreSQL,

Derby, Oracle, Microsoft SQL Server, entre outras.

A empresa que desenvolveu o sistema nao oferece uma solucao de cloud-hosting, logo o servidor

tem de ser um servidor local, gerido e mantido pela entidade que adquirir o sistema. Para o correto

funcionamento do servidor, e necessario instalar JDK versao 1.7, Ant17 e Apache HTTP Server. A

aplicacao cliente e acessıvel atraves de um web browser, o que implica que nao e necessaria a sua

instalacao nos computadores dos utilizadores, e que e compatıvel com Sistemas Operativos Windows,

OS X e Linux. A aplicacao cliente nao possui uma interface adaptavel a dispositivos moveis, o que limita

a sua utilizacao em Sistemas Operativos iOS, Android e Windows Phone, e apenas esta disponıvel em

Ingles.

Segundo a informacao disponıvel no site oficial do Apache OFBiz, este sistema oferece funcionali-

dade que permite a gestao de Membros, de Perfil de Membro e de Assiduidade. O site indica ainda que

e possıvel expandir a funcionalidade do Sistema dado que e um Sistema open source.

3.5.3 ERPNext

O ERPNext e um Sistema ERP open source desenvolvido pela Frappe Technologies18 e focado no

sector empresarial. Este sistema esta ao abrigo da licenca GNU General Public License (GNU GPL)

v3, que permite a liberdade de utilizar, modificar, e distribuir o sistema sem qualquer custo. Com

este sistema e disponibilizada documentacao, mas nao e disponibilizado qualquer suporte em caso de

16http://www.apache.org17http://ant.apache.org18https://about.frappe.io

26

duvida ou problema. A empresa que desenvolveu o sistema tambem oferece uma solucao de cloud-

hosting, com diferentes planos de pagamento disponibilizados. Estes planos tem um custo entre $300

por ano e $5000 por ano. Com esta solucao e disponibilizado suporte em caso de duvida ou problema.

O ERPNext foi desenvolvido em Python e Javascript, e e compatıvel com base de dados MariaDB19.

A empresa que desenvolveu o sistema oferece uma solucao de cloud-hosting, mas existe a possibili-

dade de utilizar um servidor local, gerido e mantido pela entidade que adquirir o sistema. Para o correto

funcionamento do servidor, e necessario instalar Python 2.7, Redis20 e wkhtmltopdf21. A aplicacao cli-

ente e acessıvel atraves de um web browser, o que implica que nao e necessaria a sua instalacao nos

computadores dos utilizadores, e que e compatıvel com Sistemas Operativos Windows, OS X e Linux.

A aplicacao cliente possui uma interface adaptavel a dispositivos moveis, o que permite a sua utilizacao

em Sistemas Operativos iOS, Android e Windows Phone, e apenas esta disponıvel em Ingles.

Segundo a informacao disponıvel no site oficial do ERPNext, este sistema oferece funcionalidade

que permite a gestao de Membros, de Perfil de Membro, de Assiduidade e Suporte Informatico. O site

indica ainda que e possıvel expandir a funcionalidade do sistema dado que e um sistema open source.

3.5.4 GrowERP

O GrowERP e um Sistema ERP open source desenvolvido pela AntWebsystems22 e focado no sector

empresarial. Este sistema esta ao abrigo da licenca Apache License 2.0, que permite a liberdade

de utilizar, modificar, e distribuir o sistema sem qualquer custo. Com este sistema e disponibilizada

documentacao, mas nao e disponibilizado qualquer suporte em caso de duvida ou problema. A empresa

que desenvolveu o sistema tambem oferece uma solucao de cloud-hosting, com diferentes planos de

pagamento disponibilizados. Estes planos tem um custo entre $29 e $99 por utilizador e por mes. Com

esta solucao e disponibilizado suporte em caso de duvida ou problema.

O GrowERP foi construıdo com base no Apache OFBiz (ver Seccao 3.5.2). Foi desenvolvido em

Java, e e compatıvel com base de dados MySQL, PostgreSQL, Derby, Oracle, Microsoft SQL Server,

entre outras.

A empresa que desenvolveu o sistema oferece uma solucao de cloud-hosting, mas existe a possibili-

dade de utilizar um servidor local, gerido e mantido pela entidade que adquirir o sistema. Para o correto

funcionamento do servidor, e necessario instalar Apache OFBiz (e todas as suas dependencias). A

aplicacao cliente e acessıvel atraves de um web browser, o que implica que nao e necessaria a sua

instalacao nos computadores dos utilizadores, e que e compatıvel com Sistemas Operativos Windows,

OS X e Linux. A aplicacao cliente possui uma interface adaptavel a dispositivos moveis, o que permite a

sua utilizacao em Sistemas Operativos iOS, Android e Windows Phone, e esta disponıvel em Portugues

e em Ingles.

Segundo a informacao disponıvel no site oficial do GrowERP, este sistema oferece funcionalidade

que permite a gestao de Membros, de Perfil de Membro e de Assiduidade. O site indica ainda que e

19https://mariadb.org20http://redis.io21http://wkhtmltopdf.org22http://www.antwebsystems.com/control/main

27

possıvel expandir a funcionalidade do sistema dado que e um sistema open source.

3.5.5 JFire

O JFire e um Sistema ERP open source desenvolvido pela NightLabs23 e focado no sector empresarial.

Este sistema esta ao abrigo da licenca LGPL, que permite a liberdade de utilizar, modificar, e distribuir

o sistema sem qualquer custo. Com este sistema e disponibilizado documentacao e suporte em caso

de duvida ou problema.

O JFire foi desenvolvido em Java, e e compatıvel com base de dados MySQL e Derby.

A empresa que desenvolveu o sistema nao oferece uma solucao de cloud-hosting, logo o servidor

tem de ser um servidor local, gerido e mantido pela entidade que adquirir o sistema. Para o correto

funcionamento do servidor, e necessario instalar Java versao 1.6 (JRE ou JDK). A aplicacao cliente

e acessıvel atraves de um web browser, o que implica que nao e necessaria a sua instalacao nos

computadores dos utilizadores, e que e compatıvel com Sistemas Operativos Windows, OS X e Linux. A

aplicacao cliente nao possui uma interface adaptavel a dispositivos moveis, o que limita a sua utilizacao

em Sistemas Operativos iOS, Android e Windows Phone, e apenas esta disponıvel em Ingles.

Segundo a informacao disponıvel no site oficial do JFire, este sistema oferece funcionalidade para o

Suporte Informatico. O site indica ainda que e possıvel expandir a funcionalidade do sistema dado que

e um sistema open source.

3.5.6 Microsoft Dynamics AX

O Microsoft Dynamics AX e um Sistema ERP closed source desenvolvido pela Microsoft24. A utilizacao

deste sistema esta sujeita a um plano de pagamento, dependente de negociacao com parceiros da

empresa. Com este sistema e disponibilizado documentacao e suporte em caso de duvida ou problema.

O Microsoft Dynamics AX foi construıdo com base em tecnologias Microsoft, utilizando Microsft

Azure25 e .NET C# e X++26. E compatıvel com base de dados Microsoft SQL Server.

A empresa que desenvolveu o sistema oferece uma solucao de cloud-hosting, mas existe a possibi-

lidade de utilizar um servidor local, gerido e mantido pela entidade que adquirir o sistema. A aplicacao

cliente nao e acessıvel atraves de um web browser, o que implica a sua instalacao nos computadores

dos utilizadores. Existe apenas aplicacao cliente para Sistemas Operativos Windows, e esta disponıvel

em Portugues e em Ingles.

Segundo a informacao disponıvel no site oficial do Microsoft Dynamics AX, este sistema oferece

funcionalidade que permite a gestao de Membros, de Perfil de Membro e de Assiduidade. Nao e, no

entanto, possıvel expandir a funcionalidade do Sistema.

23http://www.nightlabs.de/en24https://www.microsoft.com25https://azure.microsoft.com/pt-pt/26https://msdn.microsoft.com/en-us/library/aa867122.aspx

28

3.5.7 Odoo

O Odoo e um Sistema ERP open source desenvolvido pela Odoo S.A.27 e focado no sector empresa-

rial. Este sistema esta ao abrigo da licenca LGPL v3, que permite a liberdade de utilizar, modificar, e

distribuir o sistema sem qualquer custo. Com este sistema e disponibilizada documentacao, mas nao

e disponibilizado qualquer suporte em caso de duvida ou problema. A empresa tambem oferece uma

solucao de cloud-hosting, com um custo de $15 a $35 por mes por App (cada App engloba um conjunto

de funcionalidades, o preco varia conforme a App), somado de $25 por mes por utilizador, e ainda um

custo de implementacao que varia entre os $3400 e os $5500. Com esta solucao e disponibilizado

suporte em caso de duvida ou problema.

O Odoo foi desenvolvido em Python e JavaScript, e e compatıvel com base de dados PostgreSQL.

A empresa que desenvolveu o sistema oferece uma solucao de cloud-hosting, mas existe a possi-

bilidade de utilizar um servidor local, gerido e mantido pela entidade que adquirir o sistema. Para o

correto funcionamento do servidor, e necessario instalar Python 2.7. A aplicacao cliente e acessıvel

atraves de um web browser, o que implica que nao e necessaria a sua instalacao nos computadores

dos utilizadores, e que e compatıvel com Sistemas Operativos Windows, OS X e Linux. A aplicacao cli-

ente possui uma interface adaptavel a dispositivos moveis, o que permite a sua utilizacao em Sistemas

Operativos iOS, Android e Windows Phone, e esta disponıvel em Portugues e em Ingles.

Segundo a informacao disponıvel no site oficial do Odoo, este sistema oferece funcionalidade que

permite a gestao de Membros e de Assiduidade. O site indica ainda que e possıvel expandir a funcio-

nalidade do sistema dado que e um sistema open source.

3.5.8 Primavera

O Primavera e um Sistema ERP closed source desenvolvido pela PRIMAVERA Consulting28, e inclui

uma solucao focada no sector de de administracao publica. A utilizacao deste Sistema esta sujeita a um

plano de pagamento, dependente de negociacao directa com a empresa que desenvolveu o sistema.

Com este sistema e disponibilizado documentacao e suporte em caso de duvida ou problema.

A aplicacao cliente e acessıvel atraves de um web browser, o que implica que nao e necessaria

a sua instalacao nos computadores dos utilizadores, e que e compatıvel com Sistemas Operativos

Windows, OS X e Linux. A aplicacao cliente possui uma interface adaptavel a dispositivos moveis, o

que permite a sua utilizacao em Sistemas Operativos iOS, Android e Windows Phone, e esta disponıvel

em Portugues e em Ingles.

Segundo a informacao disponıvel no site oficial do Primavera, este sistema oferece funcionalidade

que permite a gestao de Membros e de Assiduidade. Nao e, no entanto, possıvel expandir a funcionali-

dade do Sistema.

27https://www.odoo.com/page/about-us28http://pt.primaverabss.com/en/primavera

29

3.5.9 SAP ERP

O SAP ERP e um Sistema ERP closed source desenvolvido pela SAP SE29, e inclui uma solucao

focada no sector de ensino superior. A utilizacao deste sistema esta sujeita a um plano de pagamento,

dependente de negociacao com parceiros da empresa que desenvolveu o sistema. Com este sistema

e disponibilizado documentacao e suporte em caso de duvida ou problema.

O SAP ERP foi desenvolvido em C, C++ e ABAP/4. E compatıvel com base de dados Oracle e SQL

Hana.

A empresa que desenvolveu o sistema nao oferece uma solucao de cloud-hosting, logo o servidor

tem de ser um servidor local, gerido e mantido pela entidade que adquirir o sistema. A aplicacao cliente

e acessıvel atraves de um web browser, o que implica que nao e necessaria a sua instalacao nos

computadores dos utilizadores, e que e compatıvel com Sistemas Operativos Windows, OS X e Linux.

Esta disponıvel em Portugues (do Brasil) e em Ingles.

Segundo a informacao disponıvel no site oficial do SAP ERP, este sistema oferece funcionalidade

que permite a gestao de Membros, de Assiduidade e de Missoes.

3.6 Sistemas de Gestao de Recursos Humanos

3.6.1 OrangeHRM

O OrangeHRM e um Sistema HRM open source desenvolvido pela OrangeHRM Inc.30 e focado no

sector empresarial. Este sistema esta ao abrigo da licenca GNU GPL v2, que permite a liberdade

de utilizar, modificar, e distribuir o sistema sem qualquer custo. Com este sistema e disponibilizada

documentacao, mas nao e disponibilizado qualquer suporte em caso de duvida ou problema. A empresa

que desenvolveu o sistema tambem oferece uma solucao de cloud-hosting, com diferentes planos de

pagamento disponibilizados, dependente de negociacao direta com a empresa. Com esta solucao e

disponibilizado suporte em caso de duvida ou problema.

O OrangeHRM foi desenvolvido em PHP, e e compatıvel com base de dados MySQL.

A empresa que desenvolveu o sistema oferece uma solucao de cloud-hosting, mas existe a possibili-

dade de utilizar um servidor local, gerido e mantido pela entidade que adquirir o sistema. Para o correto

funcionamento do servidor, e necessario instalar Apache HTTP Server 2.2.22 e PHP 5.4. A aplicacao

cliente e acessıvel atraves de um web browser, o que implica que nao e necessaria a sua instalacao

nos computadores dos utilizadores, e que e compatıvel com Sistemas Operativos Windows, OS X e

Linux. A aplicacao cliente nao possui uma interface adaptavel a dispositivos moveis, o que limita a sua

utilizacao em Sistemas Operativos iOS, Android e Windows Phone. Para retificar isto, encontram-se

disponıveis aplicacoes cliente iOS e Android nativas. Estas teriam de ser instaladas nos dispositivos

moveis dos utilizadores, mas permitiriam a utilizacao do Sistema nestes dispositivos. A aplicacao cliente

esta disponıvel em Portugues e em Ingles.

29http://go.sap.com/portugal/about.html30http://www.orangehrm.com/OrangeHRM_Excutive_Profile

30

Segundo a informacao disponıvel no site oficial do OrangeHRM, este sistema oferece funcionalidade

que permite a gestao de Membros e de Assiduidade. O site indica ainda que e possıvel expandir

a funcionalidade do sistema dado que e um sistema open source. Adicionalmente, encontram-se a

venda add-ons ao sistema que adicionam mais funcionalidade ao sistema. Em particular, existe um

add-on que permite a gestao de Missoes.

3.7 Sistemas de Gestao de Tickets de Suporte

3.7.1 osTicket

O osTicket e um ITS open source desenvolvido pela Enhancesoft31 e focado no sector empresarial.

Este sistema esta ao abrigo da licenca GNU GPL v2, que permite a liberdade de utilizar, modificar, e

distribuir o Sistema sem qualquer custo. Com este sistema e disponibilizada documentacao do Sis-

tema, mas nao e disponibilizado qualquer suporte em caso de duvida ou problema. A empresa que

desenvolveu o sistema tambem oferece uma solucao de cloud-hosting, com diferentes planos de paga-

mento disponibilizados. Estes planos tem um custo entre $9 por agente por mes e $16 por agente por

mes. Um agente e um utilizador do sistema que pode responder e resolver tickets de ajuda. Com esta

solucao e disponibilizado suporte em caso de duvida ou problema.

O osTicket foi desenvolvido em PHP, e e compatıvel com base de dados MySQL.

A empresa que desenvolveu o sistema oferece uma solucao de cloud-hosting, mas existe a pos-

sibilidade de utilizar um servidor local, gerido e mantido pela entidade que adquirir o sistema. Para

o correto funcionamento do servidor, e necessario instalar Apache HTTP Server e PHP. A aplicacao

cliente e acessıvel atraves de um web browser, o que implica que nao e necessaria a sua instalacao

nos computadores dos utilizadores, e que e compatıvel com Sistemas Operativos Windows, OS X e

Linux. A aplicacao cliente nao possui uma interface adaptavel a dispositivos moveis, o que limita a sua

utilizacao em Sistemas Operativos iOS, Android e Windows Phone, e esta disponıvel em Portugues e

em Ingles.

Segundo a informacao disponıvel no site oficial do osTicket, este sistema oferece funcionalidade

para o Suporte Informatico. O site indica ainda que e possıvel expandir a funcionalidade do sistema

dado que e um sistema open source.

3.8 Discussao

A analise efectuada aos diferentes sistemas descritos nesta seccao encontra-se resumida nas Tabelas

3.1, 3.2 (para os sistemas Dot, FenixEdu, Microsoft Dynamics AX e SAP ERP), 3.3 e 3.4 (para os

sistemas 1ERP, ERPNext, OrangeHRM, osTicket).

Com base nesta analise, conclui-se que existem tres possıveis solucoes para a implementacao do

novo SGI do IPFN: i) a utilizacao de um sistema ja existente no mercado, ii) a utilizacao de dois ou mais

31http://www.enhancesoft.com

31

Tabela 3.1: Informacao Geral do Sistema para os sistemas Dot, FenixEdu, Microsoft Dynamics AX eSAP ERP

Sistemas/Caracterısticas Dot FenixEdu Microsoft

Dynamics AX SAP ERP

Equipa deDesenvolvimento DSI IST DSI IST Microsoft SAP SE

Open Source? Nao Sim(LGPL v3) Nao Nao

Custo daLicenca Gratuito Gratuito Valor a ser

negociadoValor a sernegociado

SaaS? Nao Nao Sim SimUltima Versao Jun/2015 Nov/2015 Jun/2015 Jul/2015Suporte Sim Nao Sim SimMulti-Lıngua PT e EN PT e EN PT e EN PT-BR e ENFocado naInvestigacaoCientıfica?

Sim Sim Nao Nao

Bases de DadosCompatıveis MySQL MySQL Microsoft

SQL ServerOracle,

SQL Hana

Dependencias Java Java Microsoft Azure.NET (C# e X++)

C, C++,ABAP/4

Servidor Apenas local Apenas local Local oucloud-hosted Apenas local

Aplicacao ClienteWeb Based

Sim(Responsive)

Sim(Responsive) Nao Sim

SistemasOperativosCompatıveis

Windows,OS X, Linux,iOS, Android,

Windows Phone

Windows,OS X, Linux,iOS, Android,

Windows Phone

Windows Windows,OS X, Linux

Extensıvel? Nao Sim Nao NaoAPI? Nao Sim Nao Nao

Tabela 3.2: Funcionalidades presentes nos sistemas Dot, FenixEdu, Microsoft Dynacs AX e SAP ERPSistemas/Modulos Dot FenixEdu Microsoft

Dynamics AX SAP ERP

Gestao de Membros - X X XGestao de Perfilde Membros - X X -

Gestao deAssiduidade - - X X

Gestao de Missoes X - - XSuporteInformatico - - - -

32

Tabela 3.3: Informacao Geral do Sistema para os sistemas 1ERP, ERPNext, OrangeHRM e osTicketSistemas/Caracterısticas 1ERP ERPNext OrangeHRM osTicket

Equipa deDesenvolvimento Quidgest Frappe

Technologies OrangeHRM Inc. Enhancesoft

Open Source? Nao Sim(GNU GPL v3)

Sim(GNU GPL v2)

Sim(GNU GPL v2)

Custo daLicenca

Valor anegociar Gratuito Gratuito Gratuito

SaaS? Nao Sim Sim SimUltima Versao - Abr/2015 Abr/2015 Ago/2015

Suporte Sim Apenas usandocomo servico

Apenas usandocomo servico

Apenas usandocomo servico

Multi-Lıngua EN e PT EN EN PT e ENFocado naInvestigacaoCientıfica?

Nao Nao Nao Nao

Bases de DadosCompatıveis

MicrosoftSQL Server,

OracleMariaDB MySQL MySQL

Dependencias Visual C++,C#, Java

Python, Redis,wkhtmltopdf

PHP, ApacheHTTP Server

PHP, ApacheHTTP Server

Servidor Apenas Local Local oucloud-hosted

Local oucloud-hosted

Local oucloud-hosted

Aplicacao ClienteWeb Based Nao Sim

(Responsive) Sim Sim

SistemasOperativosCompatıveis

Windows

Windows,OS X, Linux,iOS, Android,

Windows Phone

Windows,OS X, Linux,iOS, Android

Windows,OS X, Linux

Extensıvel? Sim Sim Sim SimAPI? Nao Nao Sim Sim

Tabela 3.4: Funcionalidades presentes nos sistemas 1ERP, ERPNext, OrangeHRM e osTicketSistemas/Modulos 1ERP ERPNext OrangeHRM osTicket

Gestao de Membros X X X -Gestao de Perfilde Membros X X - -

Gestao deAssiduidade X X X -

Gestao de Missoes X - X(Add-on) -

SuporteInformatico X X - X

33

sistemas em conjunto, e iii) o desenvolvimento de um sistema de raiz.

A primeira hipotese e a utilizacao de um sistema ja existente no mercado. Analisando as tabelas 3.2

e 3.4, concluı-se que apenas o 1ERP apresenta funcionalidades para todos os modulos. No entanto, a

utilizacao do 1ERP pelo IPFN apresenta as seguintes desvantagens:

• Sendo um sistema closed source, isto implica que e impossıvel para o IPFN implementar funci-

onalidade adicional. No caso de surgir a necessidade de expandir a funcionalidade do sistema,

seria necessario entrar em contacto com a Quidgest para esta incluir a funcionalidade adicional

numa versao futura do sistema, trazendo custos adicionais ao IPFN.

• Embora o 1ERP tenha funcionalidade para a gestao de Missoes, o IPFN de momento ja se encon-

tra a utilizar o Dot para a sua gestao de Missoes. Isto implica que seria necessario para o IPFN

passar a utilizar a solucao presente no 1ERP, ou adicionar funcionalidade ao 1ERP para integrar

com o Dot.

• O facto que o 1ERP e so compatıvel com Sistema Operativo Windows, e inexistencia de aplicacao

cliente Web Based, obriga os utilizadores a utilizar um computador com Sistema Operativo Win-

dows, limitando severamente o numero de dispositivos que podem aceder ao sistema. Os mem-

bros do IPFN sentem a necessidade de aceder ao sistema de gestao de informacao a partir de

uma variedade de dispositivos, como portateis, tablets e smartphones. Por exemplo, durante uma

missao ao estrangeiro, um membro pode necessitar de aceder ao sistema, mas o unico disposi-

tivo disponıvel para o fazer e o seu smartphone. Portanto, e necessario existir a possibilidade de

aceder ao sistema a partir de uma grande variedade de dispositivos.

A segunda hipotese e a utilizacao de dois ou mais sistemas em conjunto. Esta hipotese consiste em

aproveitar as APIs que alguns sistemas apresentam, de forma a combinar a funcionalidade dos siste-

mas, e assim cobrir todos os modulos do sistema de gestao de informacao a ser desenvolvido. Tendo

em conta os sistemas que disponibilizam uma API (FenixEdu, na Tabela 3.1, e OrangeHRM e osTicket,

na Tabela 3.3), e comparando as suas funcionalidades (nas Tabelas 3.2 e 3.4), seria possıvel usar o

OrangeHRM, o osTicket e o FenixEdu em conjunto de maneira a combinar as suas funcionalidades, e

assim cobrir todos os modulos para a Gestao de Recursos Humanos e Suporte Informatico.

Esta solucao permite a criacao de um sistema de gestao de informacao que suporta as funcionali-

dades dos modulos de Gestao de Recursos Humanos e Suporte Informatico, mas tambem apresenta

varios problemas:

• Os sistemas apresentam diferentes dependencias (o OrangeHRM e o osTicket tem como de-

pendencia o servidor Apache HTTP Server, mas o FenixEdu utiliza a maquina virtual Java), o que

leva a um maior numero de processos em execucao no servidor, consumindo mais recursos e

afetando negativamente o desempenho do sistema.

• A necessidade de comunicacao entre os tres sistemas leva tambem a um maior consumo de

recursos e, portanto, um pior desempenho.

34

• No caso de um dos sistemas necessitar de ser atualizado para uma versao mais recente, a

atualizacao pode introduzir erros no sistema completo, ou ate mesmo impossibilita-lo de ser exe-

cutado. Por serem sistemas diferentes, as atualizacoes muito provavelmente sao lancadas de

maneira dessincronizada, levantando dificuldades e custos na manutencao.

• De maneira a cobrir toda a funcionalidade de todos os modulos, seria necessario usar sistemas

que contem funcionalidade repetida entre eles. Isto resulta na duplicacao de informacao nos

diferentes sistemas, trazendo problemas de sincronizacao entre eles.

• A utilizacao de varios sistemas tambem traz problemas de implementacao e manutencao, pois

requer conhecimento sobre a interface e o funcionamento dos tres sistemas, aumentando consi-

deravelmente a complexidade do sistema de gestao de informacao.

A terceira hipotese e o desenvolvimento de um sistema de raiz. Esta solucao tem as seguintes

vantagens:

• Ser possıvel incluir no sistema toda a funcionalidade necessaria para o IPFN. Ou seja, ao

contrario dos restantes sistemas analisados, este sistema incluira funcionalidade de modo a sa-

tisfazer todos os requisitos identificados.

• Ser possıvel adaptar a arquitetura do sistema as necessidades do IPFN e aos requisitos de todos

os modulos do novo sistema, evitando situacoes em que a arquitetura nao e indicada para uma

ou mais funcionalidades.

• Ser possıvel ao IPFN comercializar o sistema (utilizando uma licenca closed source), ou disponi-

biliza-lo a outros centros de investigacao (utilizando uma licenca open source).

A implementacao de um sistema de raiz tem, no entanto, a desvantagem de ser impossıvel utilizar

funcionalidade ja implementada noutros sistemas. Todos os modulos terao de ser implementados de

raiz. Para mitigar esta desvantagem, e possıvel a utilizacao de bibliotecas ou frameworks de software

que facilitem o desenvolvimento do sistema (caso a sua utilizacao seja benefica para a implementacao

e o correto funcionamento do sistema).

Tendo em conta as vantagens e desvantagens de cada hipotese, concluı-se que a melhor solucao

e desenvolver o sistema de gestao de informacao de raiz.

Embora o novo sistema seja desenvolvido de raiz, durante a analise efetuada aos sistemas existen-

tes no mercado, notou-se que alguns dos sistemas apresentam certos aspetos que, se implementados

no novo sistema, seriam beneficos para o IPFN. Em particular:

• Na grande maioria dos sistemas analisados, o sistema esta divido em varios modulos com funcio-

nalidade reduzida, sendo que cada um esta focado num conjunto bem definido de funcionalidade.

Interacoes ou dependencias entre estes modulos sao tambem limitadas. Tomando como exemplo

o sistema Odoo: cada modulo, ou App, pode ser introduzido ou excluıdo do sistema conforme a

necessidade dos utilizadores (com certas restricoes conforme as dependencias entre Apps). Isto

demonstra a elevada modularidade do sistema, e os benefıcios que esta decisao traz.

35

• Em sistemas cuja aplicacao cliente e acedida atraves de um browser, a compatibilidade com

sistemas operativos Windows, OS X e Linux e imediatamente oferecida.

• No caso em que a aplicacao cliente do sistema, em acrescimo a ser acedida atraves de um

browser, tambem tem um visual adaptativo, a sua utilizacao em dispositivos moveis e garantida,

sem a necessidade de desenvolver uma aplicacao nativa.

Utilizando estes aspetos como inspiracao, a arquitetura do novo sistema sera desenvolvida de modo

a:

• Garantir a modularidade e minimizar as dependencias entre modulos. Cada modulo sera uma

unidade de implementacao, minimizando o numero de ligacoes com outros modulos.

• Utilizar tecnologias Web, que permitem a criacao de aplicacoes que se executam num browser,

para desenvolver um sistema cuja aplicacao cliente pode ser imediatamente utilizada em qualquer

sistema operativo.

• Ser possıvel utilizar um design adaptativo a dispositivos moveis na aplicacao cliente, permitindo

assim a utilizacao do sistema tambem em dispositivos moveis.

3.8.1 Escolha de framework

De forma a aproveitar alguma da funcionalidade ja existente no sistema FenixEdu, escolhemos utilizar

a BennuFramework, a framework base do sistema FenixEdu, tambem como base do novo sistema.

A BennuFramework e uma framework Java, desenvolvida pela DSI do IST, que permite o desenvolvi-

mento de aplicacoes web modulares. Sendo construıda usando a Fenix Framework, a BennuFramework

oferece persistencia e operacoes transacionais sobre objetos do domınio. As classes de domınio sao

geradas automaticamente pela Fenix Framework, e o seu uso garante a persistencia dos objetos de

domınio. Para a geracao das classes de domınio, o domınio tem de ser modelado usando a Domain

Modelling Language (DML).

Adicionalmente, sendo construıda com aplicacoes web em mente, a BennuFramework implementa

conceitos fundamentais para este genero de aplicacoes, nomeadamente:

• Autenticacao e gestao de utilizadores, usando um login local, ou atraves de um servico Central

Authentication Service (CAS)

• O menu da aplicacao, presente na interface com o utilizador e permite ao utilizador aceder as

varias funcionalidades do sistema, e configuravel em tempo de execucao

• Grupos de acesso que permitem controlar as permissoes dos utilizadores as varias funcionali-

dades da aplicacao

• Agendamento de tarefas usando uma sintaxe baseada no agendamento de tarefas Cron32

• Abstracao sobre o armazenamento de ficheiros32http://www.unixgeeks.org/security/newbie/unix/cron-1.html

36

• Navegador de domınio, permitindo graficamente inspecionar os objetos de domınio em tempo

de execucao

A BennuFramework tem tambem como base a Spring Framework33, uma framework open source

de desenvolvimento de aplicacoes web Java, permitindo utilizar muita da funcionalidade presente nesta

ultima framework.

Finalmente, sendo modular, e possıvel adicionar outros modulos a BennuFramework que implemen-

tem outras funcionalidades. Em particular, o novo SGI utiliza o modulo de Messanging, um modulo

tambem desenvolvido pela DSI do IST, que permite ao sistema enviar emails aos seus utilizadores.

Embora existam outras frameworks focadas no desenvolvimento de aplicacoes web em varias lin-

guagens (por exemplo, Django34 para Python, Ruby on Rails35 para Ruby e Zend Framework 236 ou

Laravel37 para PHP), a BennuFramework foi escolhida devido a selecao de funcionalidades que imple-

menta, que permite uma maior e mais simples integracao com o Fenix e o Dot do IST, e o suporte

oferecido pela DSI durante o desenvolvimento do sistema.

33https://spring.io34https://www.djangoproject.com35http://rubyonrails.org36http://framework.zend.com37https://laravel.com/

37

38

Capıtulo 4

Implementacao

Tendo em conta os requisitos do SGI do IPFN detalhados no Capıtulo 2, e as conclusoes sobre o

trabalho relacionado descritas na Seccao 3.8, este capıtulo apresenta um sistema que satisfaz as ne-

cessidades do IPFN. Na Seccao 4.1 e apresentada a arquitetura geral do sistema. Na Seccao 4.2 e

detalhada a implementacao da arquitetura. A Seccao 4.3 detalha a implementacao de funcionalidades

comuns a todos os modulos do sistema desenvolvido, nomeadamente a implementacao usada para per-

mitir pesquisa e ordenacao de objetos. Na Seccao 4.4 e apresentada a arquitetura geral de um modulo

do sistema. A Seccao 4.5 detalha a implementacao do modulo de Gestao de Membros, em particular

referindo a implementacao das contas de membros, sincronizacao de dados com o Fenix e controlo de

permissoes dos membros. A Seccao 4.6 detalha a implementacao do modulo de Gestao de Perfil de

Membros, em particular referindo a implementacao dos perfis e da API JSON do modulo. A Seccao

4.7 detalha a implementacao do modulo de Gestao de Assiduidade, nomeadamente a implementacao

do registo de presencas e pedidos, e do calculo da estatıstica de um membro. A Seccao 4.8 deta-

lha a implementacao do modulo de Gestao de Missoes, nomeadamente a implementacao da consulta

de processos de missao no Dot e da geracao de relatorios em formato PDF. A Seccao 4.9 detalha a

implementacao do modulo de Gestao de Tickets de Suporte, nomeadamente a implementacao usada

para permitir a membros adicionar comentarios aos tickets de suporte. Finalmente, a Seccao 4.10 de-

talha a implementacao do modulo de Gestao de Rede Informatica, nomeadamente a implementacao

do workflow de um Pedido IP.

4.1 Arquitetura Geral do Sistema

O novo SGI foi desenvolvido de forma a integrar-se com outros sistemas externos ja existentes no IST.

A Figura 4.1 representa uma visao geral do novo SGI, e como este comunica com sistemas externos.

Atualmente, existem quatro sistemas externos que comunicam com o novo SGI:

CAS Tecnico O CAS Tecnico e um CAS que permite a qualquer utilizador autenticar-se nos varios

servicos do IST (por exemplo, o Fenix e o Dot), desde que tenha um TecnicoID1. Os membros do

1 O TecnicoID e um identificador unico atribuıdo a estudantes, docentes, e funcionarios do IST, que os permite ter acesso aos

39

Figura 4.1: Visao Geral do novo SGI.

IPFN tambem tem um TecnicoID, e portanto o CAS Tecnico pode ser utilizado para autenticacao

no novo SGI.

Fenix Usando a API do Fenix, e possıvel obter informacoes pessoais sobre o membro autenticado2.

Esta informacao e usada para sincronizar os dados no novo SGI com os dados no Fenix.

Dot Usando a API do Dot, e possıvel obter uma listagem das missoes do membro autenticado, assim

como informacao detalhada de cada uma destas missoes. Esta informacao e usada para listar e

gerar relatorios de missao no novo SGI.

Portal IPFN O novo SGI tambem disponibiliza uma API para que sistemas externos, como o Portal

IPFN, possam obter informacao publica sobre os dados geridos pelo novo SGI, nomeadamente

as notıcias, os grupos de investigacao e os perfis de membros. Outros sistemas podem tambem

fazer uso desta API, sendo o Portal IPFN apenas um exemplo de um sistema que a usa.

Focando-nos no novo SGI, este pode ser decomposto em diferentes modulos. Como detalhado no

Capıtulo 2, os requisitos encontram-se organizados em modulos distintos, sendo que cada um possui

um conjunto de responsabilidades, independentes entre si. Esta organizacao sugere que a arquitetura

do novo SGI seja modular e constituıda por diversos sub-sistemas mais simples, sendo cada modulo

um equivalente aos modulos descritos no Capıtulo 2. Assim, consegue-se minimizar a complexidade e

permite-se que, posteriormente, seja possıvel a adicao de outros modulos ou a alteracao de modulos

ja existentes sem que os restantes modulos sejam afetados. Aplicando esta decomposicao, e obtida a

estrutura representada na Figura 4.2. Os modulos foram agrupados logicamente por funcionalidade.

Dado que esta tese se foca na implementacao dos modulos de Gestao de Recursos Humanos

e Suporte Informatico, os modulos relativos a Gestao de Producao e Ativos nao serao incluıdos nas

figuras e seccoes seguintes. Os modulos de Gestao de Producao e de Ativos sao desenvolvidos numa

tese em separado [6].

varios servicos disponibilizados pelo IST.2https://fenix.tecnico.ulisboa.pt/api/fenix/v1/person

40

Figura 4.2: Visao de Decomposicao em Modulos do novo SGI.

4.2 Arquitetura da Solucao

Foi decidido, para a implementacao do sistema, que seria utilizada a BennuFramework3, devido aos

varios benefıcios que esta traz (que sao detalhados na Seccao 3.8.1). O sistema a desenvolver tem

uma arquitetura em camadas, tendo a BennuFramework como uma das camadas base. A Figura 4.3

apresenta as varias camadas do sistema desenvolvido, onde cada modulo desenvolvido e representado

por uma camada distinta.

Figura 4.3: Visao de Camadas do novo SGI.

3https://github.com/FenixEdu/bennu

41

Cada camada na Figura 4.3 depende das camadas inferiores a si mesma, podendo apenas usar

classes definidas na propria camada ou em camadas inferiores, e nao tem acesso as camadas superi-

ores ou laterais. As camadas da aplicacao desenvolvida sao as que se seguem (comecando de baixo

para cima):

Fenix Framework Requisito da BennuFramework, esta camada permite o desenvolvimento de aplica-

coes Java que necessitam de um modelo de domınio persistente e transacional. Mais detalhes

sobre esta framework na Seccao 3.8.1.

BennuFramework Uma framework de desenvolvimento de aplicacoes web Java. Mais detalhes sobre

esta framework na Seccao 3.8.1.

Messaging Modulo da BennuFramework que permite as aplicacoes desenvolvidas usando esta fra-

mework enviar emails.

Funcionalidades Comuns Modulo extra do novo SGI, que implementa varias classes utilitarias uti-

lizadas pelos modulos de Gestao de Recursos Humanos e Suporte Informatico, assim como a

estrutura para permitir a pesquisa de objetos do domınio nesses mesmos modulos. Mais detalhes

sobre este modulo na Seccao 4.3.

Gestao de Recursos Humanos e Suporte Informatico Estas camadas sao compostas pelos modu-

los representados na Figura 4.2. Os Modulos de Gestao de Perfil de Membro, Assiduidade,

Missoes, Tickets de Suporte e Rede Informatica dependem do modulo de Gestao de Membros.

Adicionalmente, o modulo de Gestao de Assiduidade depende tambem do modulo de Gestao de

Projetos, que e detalhado noutra tese. Mais detalhes sobre a arquitetura de um modulo na Seccao

4.4, e sobre a implementacao de cada um dos modulos nas Seccoes 4.5 a 4.10.

WebApp Modulo extra do novo SGI, cujo objetivo e juntar todos os outros modulos numa so aplicacao.

4.3 Funcionalidades Comuns

O modulo de Funcionalidades Comuns, alem de implementar varias classes utilitarias para minimizar

codigo repetido pelos restantes modulos, implementa a base para a procura e ordenacao de objetos.

Uma procura e ordenacao flexıvel dos objetos de domınio e uma funcionalidade importante para o

IPFN. No entanto, a BennuFramework nao implementa qualquer funcionalidade para permitir a pesquisa

pelos objetos de domınio (com a unica excecao de permitir encontrar um objeto de domınio dado o seu

identificador). Portanto, foi necessario desenvolver uma solucao capaz de filtrar apenas os objetos que

satisfazem os criterios indicados pelo utilizador durante uma procura, e de seguida ordena-los conforme

as indicacoes dadas.

O Algoritmo 1 descreve a solucao generica usada para implementar a pesquisa e ordenacao de

objetos de domınio.

42

input : conjunto de criterios de pesquisa c1, conjunto de criterios de ordenacao c2output: lista r filtrada e ordenada segundo os criterios

r ← [];foreach domain object o ∈ GetDomainObjectSet() do

if Accept(o, c1) thenr ← r ∪ {o};

endendSort (r,c2);

Algoritmo 1: Algoritmo usado para filtrar e ordenar objetos de domınio segundo criterios indicadospelo utilizador.

Embora este algoritmo tenha uma complexidade temporal O(nlog(n)) (onde n e o numero de objetos

de domınio do modulo em questao)4, a sua simplicidade permite a pesquisa por qualquer criterio (ou

conjunto de criterios) de pesquisa, dependendo da implementacao da funcao Accept(o,c1) (sendo o

um objeto de domınio que pode, ou nao, satisfazer os criterios de procura c1), e permite a ordenacao

conforme qualquer indicacao, dependendo da implementacao da funcao Sort(r,c2) (sendo r uma lista

de objetos de domınio, e c2 o conjunto de criterios de ordenacao).

Para a implementacao da funcao Accept(o,c1) sao utilizados dois conceitos:

Acceptable Classes que, dado um objeto de domınio, indicam se este verifica um (ou mais) criterios

de pesquisa.

AcceptableFactory Classes que, dado os termos de pesquisa do utilizador, geram um Acceptable

que verifica todos os criterios.

Para permitir a classes AcceptableFactory gerar uma instancia de Acceptable para varios termos

de pesquisa, existem tres classes de Acceptable especiais. Estas classes representam um Acceptable

que pode estar associado a uma ou mais instancias de Acceptable (dependendo do caso) e permitem

realizar uma dada operacao logica sobre os Acceptable a que estao associados:

CompositeAcceptableAnd Aceita duas instancias de Acceptables e, dado um objeto de domınio,

indica se este corresponde a ambos os Acceptables.

CompositeAcceptableOr Aceita duas instancias de Acceptables e, dado um objeto de domınio, indica

se este corresponde a pelo menos um dos Acceptables.

CompositeAcceptableNot Aceita uma instancia de Acceptable e, dado um objeto de domınio, indica

se este nao corresponde ao Acceptable.

A Figura 4.4 representa o diagrama de classes para Acceptable e estas tres especializacoes de

Acceptable, assim como as classes FilterByTitle e FilterPublished, dois exemplos de Acceptable

simples utilizados no modulo de Gestao de Notıcias, que permitem filtrar notıcias segundo o seu tıtulo

e se estao publicadas, respetivamente.

4 O algoritmo apenas tem uma complexidade O(nlog(n)) no pior caso, quando a pesquisa devolve todos os objetos na lista deresultados, devido a complexidade temporal de ordenar a lista no ultimo passo. O melhor caso, quando a pesquisa nao devolvenenhum objeto a lista de resultados, o algoritmo tem uma complexidade temporal O(n).

43

Figura 4.4: Diagrama de Classes para Acceptable.

Com estas classes Acceptable, e possıvel para um AcceptableFactory gerar um Acceptable para

quaisquer criterios de pesquisa, seguindo o Algoritmo 2.

input : conjunto de criterios de pesquisa c1output: Acceptable a capaz de verificar todos os criterios de pesquisa

a← null;if IsEmpty(c1) then

a← new AcceptAll();endforeach criterion i ∈ c1 do

if a = null thena← CreateAcceptableForCriterion(i);

elset← CreateAcceptableForCriterion(i);a← new CompositeAcceptableAnd(t, a);

endend

Algoritmo 2: Algoritmo usado para gerar uma instancia de Acceptable que verifica todos os criteriosde pesquisa.

Neste algoritmo, a funcao CreateAcceptableForCriterion(i) e responsavel por devolver uma

instancia de Acceptable que consiga verificar o criterio i (por exemplo, se o utilizador estiver a rea-

lizar uma pesquisa sobre notıcias e o criterio de procura e sobre o tıtulo, deve entao devolver uma

instancia de FilterByTitle), e devera ser implementada pelo AcceptableFactory.

Para exemplificar o Algoritmo 2, na Figura 4.5 esta representado o diagrama de sequencia para

a geracao do Acceptable para os criterios de pesquisa ?title=Test&published=false (ou seja, a

pesquisa dos objetos cujo atributo title contem ”Test”e o atributo published e falso). A Figura 4.6

44

representa o Acceptable gerado neste exemplo.

Figura 4.5: Diagrama de Sequencia para a geracao do Acceptable para os criterios de pesquisa?title=Test&published=false

Figura 4.6: Acceptable para os criterios de pesquisa ?title=Test&published=false

45

Para a implementacao da funcao Sort(r,c2), e possıvel utilizar o metodo List.sort(Comparator)5.

Este metodo ordena uma lista dada uma instancia da interface Comparator6, que determina a ordem

entre dois objetos. No entanto, e necessario gerar um Comparator que consiga corretamente ordenar

objetos de domınio segundo as indicacoes do utilizador. Foi decidido que, para cada pesquisa, o

utilizador pode indicar apenas dois criterios de ordenacao do resultado da pesquisa:

sort Indica qual o campo do objeto que deve ser usado para ordenar os resultados.

order Indica se a ordem dos objetos deve ser ascendente (caso o valor seja asc) ou descendente (caso

o valor seja desc).

Para exemplificar, consideremos o caso em que o utilizador deseja ordenar os objetos por data, do

mais recente ao mais antigo. Os termos a usar para esta ordenacao serao ?sort=date&order=desc.

Tal como para gerar um Acceptable correspondente aos criterios de pesquisa e utilizada uma classe

AcceptableFactory, para gerar um Comparator correspondente aos criterios de ordenacao e utilizada

uma classe ComparatorFactory. As classes ComparatorFactory, sendo dado estes dois termos, de-

volvem uma instancia da interface Comparator que se adequa as indicacoes do utilizador. Deve existir,

para cada valor valido de sort, uma classe que concretize Comparator e que corresponde ao criterio

(por exemplo, para uma ordenacao por data, deve haver uma classe DateComparator). Estas clas-

ses Comparator devem ser capazes de comparar objetos usando a ordem ascendente ou a ordem

descendente, conforme o indicado no termo order. Caso o utilizador nao indique estes criterios, in-

dique criterios invalidos, ou nao exista uma classe que concretize a interface Comparator adequada

aos criterios de ordenacao, e usado uma instancia de Comparator por predefinicao, definido na classe

ComparatorFactory.

4.4 Arquitetura de um Modulo

Cada modulo do novo SGI esta dividido em classes de domınio, servicos, e apresentacao, que se

podem organizar em camadas, obtendo a estrutura representada na Figura 4.7.

Figura 4.7: Visao de Camadas de um Modulo do novo SGI.

Listando as camadas presentes na Figura 4.7, comecando de baixo para cima, temos:

5https://docs.oracle.com/javase/8/docs/api/java/util/List.html#sort-java.util.Comparator-6https://docs.oracle.com/javase/8/docs/api/java/util/Comparator.html

46

Domınio Camada composta pelas classes geradas pela Fenix Framework, que representam as enti-

dades do domınio do modulo. A Fenix Framework e responsavel por manter a persistencia dos

dados. A logica de negocio deve tambem estar concretizada nesta camada.

Servicos Camada que implementa as varias acoes possıveis de se realizar sobre os objetos de domınio.

Metodos que envolvem a escrita de dados (como, por exemplo, para adicionar ou editar dados)

devem ser atomicos.

Apresentacao Camada composta por Controladores, que respondem a pedidos dos utilizadores do

sistema, utilizando a camada de Servicos.

Adicionalmente, para permitir a representacao de objetos da camada de domınio nas camadas

de servicos e apresentacao, sao utilizados objetos simples e temporarios designados como beans.

Estes objetos permitem a camada de apresentacao representar objetos de domınio sem os aceder

diretamente, mantendo assim o nıvel de abstracao.

Para exemplificar a interacao entre estas camadas, consideremos o caso em que um utilizador

deseja criar um novo objeto de domınio. Ao realizar o pedido para criar o novo objeto, o modulo

responsavel por responder ao pedido realiza os seguintes passos:

1. O controlador responsavel por responder ao pedido verifica se o pedido e correto e se o utilizador

tem permissoes para realizar a acao pretendida (neste exemplo, criar o objeto).

2. O controlador cria um objeto bean que representa o objeto de domınio que deve ser criado.

3. O controlador chama o servico responsavel por criar o objeto de domınio, passando-lhe o bean

criado no passo anterior.

4. O servico cria o novo objeto de domınio conforme a informacao no bean.

5. O objeto de domınio, ao ser criado, verifica se sao respeitadas as regras de negocio.

6. Uma vez criado o objeto de domınio, o servico termina.

7. Uma vez o servico terminado, o controlador responde ao utilizador.

4.5 Modulo de Gestao de Membros

O modulo de Gestao de Membros e o modulo responsavel pela gestao das contas de membro dos

utilizadores do IPFN. Os utilizadores podem listar todos os membros existentes e sincronizar os seus

dados pessoais com o Fenix. Adicionalmente, caso tenham permissoes de administracao, podem criar,

editar, adicionar e apagar contratos e mudar as permissoes dos membros.

A Figura 4.8 representa o diagrama de classes usado para a implementacao deste modulo. As

classes Bennu, User e DynamicGroup fazem parte da Bennu Framework.

47

Figura 4.8: Diagrama de Classes para o Modulo de Gestao de Membros.

4.5.1 Classes Member e User

A Bennu Framework ja disponibiliza uma classe que representa um utilizador do sistema, a classe User.

No entanto, existem duas limitacoes a esta classe:

• Muitos dos campos que e necessario atribuir aos membros do IPFN nao estao presentes em User.

• Ao ser usado um sistema CAS, a BennuFramework apenas cria instancias da classe User no mo-

mento que o utilizador se autentica pela primeira vez no sistema, impossibilitando o administrador

de criar novas instancias manualmente (necessario, por exemplo, para os membros que nao se

48

encontram no ativo, mas que devem estar registados no sistema, para serem todos listados).

Devido a estas limitacoes, foi decidido entao criar uma classe Member, que representa um membro

do IPFN. A classe Member ja inclui todos os campos necessarios, e e possıvel criar novas instancias de

Member sem que a pessoa se autentique no sistema.

Para associar a informacao de membro com a conta de utilizador correspondente, existe uma

relacao entre as classes Member e User. Ao ser atribuıdo um username a um membro, o sistema tenta

imediatamente associar a instancia de Member a instancia de User com o mesmo username. No entanto,

existe a possibilidade de ser atribuıdo um username ao membro antes de existir uma instancia de User

com esse username. Nesse caso, o sistema deve associar a informacao de membro com a conta de

utilizador no momento que o utilizador se autentica no sistema. Para implementar este comportamento,

foi implementado um UserAuthenticationListener7. A Figura 4.9 representa a implementacao deste

listener. Sempre que um utilizador se autentica usando uma conta de utilizador que nao tem associada

um membro, o sistema verifica se existe algum membro que deve estar associado a este utilizador.

Caso existir, e nao estiver inativo, entao os dois sao associados.

Figura 4.9: Implementacao da Classe RegisterUserAsMemberListener.

Isto garante que a instancia de Member e a instancia de User correspondente se encontrem associ-

ados assim que possıvel (imediatamente caso ja exista a instancia de User, ou assim que o utilizador

se autentica pela primeira vez, criando a instancia de User necessaria).

7https://confluence.fenixedu.org/display/BENNU/Users+and+Security#UsersandSecurity-AuthenticationListeners

49

4.5.2 Sincronizacao com o Fenix

Como o IPFN e uma unidade de investigacao do IST, os membros do IPFN estao tambem registados no

Fenix, onde sao tambem guardadas algumas informacoes pessoais do membro. Para garantir que nao

existe discrepancia entre os dados do novo SGI e os do Fenix, e necessario permitir a sincronizacao

entre os dois sistemas.

O Fenix disponibiliza uma API publica8 que permite a sistemas externos ao Fenix obter informacoes

sobre os cursos, cadeiras, e pessoas registados, entre outros. Em particular, esta API inclui um endpoint

GET /person, que devolve a informacao pessoal da pessoa atualmente autenticada no Fenix. Este

endpoint, no entanto, e privado, e portanto requer que a pessoa se autentique no sistema para poder

ser acedido.

Para permitir que sistemas externos ao Fenix possam ter acesso a estes endpoints e possıvel utilizar

OAuth29, um protocolo de autorizacao que permite a utilizadores de um sistema autorizar este a aceder

a informacao privada presente num outro sistema. Esta autorizacao pode ser revogada a qualquer

altura.

Durante o processo de autorizacao por OAuth2, existem as seguintes entidades:

Resource Owner O utilizador que pode autorizar o sistema a ter acesso a sua informacao privada.

Client O sistema que requer ter acesso a informacao privada do utilizador.

Resource Server O sistema que possui a informacao privada do utilizador.

Authorization Server O sistema que gere as autorizacoes ao acesso a informacao privada do utiliza-

dor.

Um Resource Owner, para poder dar permissao, devera ser redirecionado para um endpoint no

Authorization Server onde, apos ser autenticado, devera aceitar que o Client tenha acesso a sua

informacao privada. Apos aceitar, o Authorization Server deve indicar ao Client um Authorization Code

que e usado para obter dois tokens: o access token e o refresh token. O access token deve entao ser

usado pelo Client como comprovativo de que o utilizador o autorizou a aceder a informacao privada do

Resource Server. O access token e temporario, mas o Client Server pode usar o refresh token para

renovar os tokens, sendo-lhe dado um novo access token que pode usar para continuar a ter acesso a

informacao privada. A Figura 4.10 representa o Diagrama de Sequencia para este processo.

Usando OAuth2 e possıvel aos membros do IPFN autorizarem o novo SGI a aceder a sua informacao

pessoal no Fenix. O membro pode, em qualquer momento, autorizar o sistema a utilizar as suas

informacoes pessoais do Fenix. Apos autorizar, o novo SGI obtem os OAuth2 Tokens e cria uma nova

instancia de OAuth2Token, onde sao guardados estes tokens, e associa-a ao membro em questao

(caso ja existam tokens para o membro, o sistema apaga os tokens anteriores e mantem apenas os

mais recentes). De seguida, o sistema imediatamente tenta obter as informacoes pessoais do utilizador

presente no Fenix usando estes tokens. Apos obter resposta, o sistema guarda no membro o nome

8http://fenixedu.org/dev/api/9https://oauth.net/2/

50

Figura 4.10: Protocolo para obter e renovar OAuth2 Tokens.

completo, data de nascimento e genero. Tambem guarda a fotografia do membro e atualiza o valor de

lastSync para a data e hora no momento de sincronizacao.

Para garantir que a informacao se mantem sincronizada, foi desenvolvido uma tarefa que sincroniza

a informacao de todos os membros que tem OAuth Tokens associados. Esta tarefa e executada uma

vez por dia, usando para isto o agendamento de tarefas proporcionado pela BennuFramework. Se,

durante a sincronizacao de informacao, algum dos membros tiver associado um access token expirado,

e lancada uma excecao AccessTokenExpiredException. Ao ser apanhada esta excecao, o sistema

automaticamente utiliza o refresh token para gerar novos tokens, e tenta sincronizar outra vez para o

mesmo membro. Caso seja lancada outra excecao, o sistema assume que o membro revogou a sua

autorizacao, apaga os tokens associados a este, e cancela a sincronizacao de informacao para este

membro. Sera necessario voltar a obter uma autorizacao do membro para criar novos OAuth2 Tokens

51

e voltar a permitir a sincronizacao de informacao.

4.5.3 Permissoes

Como indicado na Seccao 3.8.1, a Bennu Framework ja oferece suporte para grupos de acesso10,

portanto ja oferece suporte para controlo de permissoes. Estes grupos de acesso sao implementados

usando DynamicGroup, uma classe que permite associar a um grupo de utilizadores um nome. No

entanto, estes grupos de acesso demonstram algumas limitacoes:

• Nao e possıvel obter uma lista de instancias de DynamicGroup existentes no sistema, apenas

se pode obter um grupo sabendo o seu nome. Tentar obter um grupo nao existente cria um

grupo novo. Adicionalmente, sendo independente dos restantes modulos, o modulo de Gestao de

Membros nao tem acesso aos nomes dos grupos de acesso dos restantes modulos.

• A interface existente para gestao de grupos de acesso e de difıcil utilizacao e nao satisfaz os

requisitos do IPFN.

• Para um utilizador obter acesso a esta interface, e necessario dar-lhe tambem privilegios de

administracao de sistema para a funcionalidade de gestao de utilizadores.

Para superar estas limitacoes, foi decidido criar a classe AccessGroup. Esta classe, tendo uma

referencia para um DynamicGroup correspondente, ja permite a cada modulo registar os seus grupos

de acesso (bastando criar, para este efeito, instancias de AccessGroup), e assim e possıvel ao modulo

de Gestao de Membros obter uma lista de todos os grupos de acesso do sistema, independentemente

do numero de modulos ativos e quais os seus grupos de acesso.

Com acesso a lista de grupos de acesso, ja e possıvel criar uma interface com o utilizador propria

para a gestao das permissoes de um membro. Esta interface, no entanto, teria de ser gerada com base

nos grupos de acesso do sistema, e portanto varia conforme as instancias de AccessGroup existentes.

Para gerar esta interface, foi decidido que cada instancia de AccessGroup seria agrupada com base no

valor do atributo moduleNameCode (que indica a que modulo pertence o grupo de acesso), e ordenado

com base no valor do atributo roleNameCode (que indica qual o papel que o grupo representa). Cada

grupo seria um checkbox, e os grupos dos diferentes modulos estariam separados pelo nome do modulo

a que pertencem. A Figura 4.11 representa a interface usada para a gestao das permissoes de um

membro na versao final do sistema, gerada com base nos grupos de acesso dos diferentes modulos do

sistema.

Face a geracao do formulario, o pedido POST resultante de o submeter sera, tambem ele, variavel,

com base nas instancias de AccessGroup existentes no sistema. Sendo o conteudo do pedido POST

esperado impossıvel de se determinar em compile time, a utilizacao de um bean como explicado na

Seccao 4.4 nao e possıvel. A solucao desenvolvida optou por utilizar o formato JSON para enviar

as novas permissoes ao servidor. Aquando da submissao do formulario por parte do membro, esta

submissao e interrompida pelo browser, e e gerado um JSON com os valores do formulario, que e

10https://confluence.fenixedu.org/display/BENNU/Access+Groups

52

Figura 4.11: Interface final para a gestao das permissoes de um membro.

53

enviado no pedido POST. No servidor, em vez de se usar um bean, e criado uma instancia de JsonArray

que representa o JSON no pedido POST. Sendo uma instancia de JsonArray, e entao possıvel iterar

sobre esta e adicionar ou remover o membro dos grupos de acesso conforme o pedido.

4.6 Modulo de Gestao de Perfil de Membro

O modulo de Gestao de Perfil de Membro e o modulo responsavel pela gestao dos perfis de mem-

bro dos utilizadores do IPFN. Deve permitir a membros editar as suas informacoes pessoais, e deve

disponibilizar os dados publicos sobre cada membro na sua API.

A Figura 4.12 representa o diagrama de classes usado para a implementacao deste modulo. A

classe Bennu faz parte da Bennu Framework, e a classe Member faz parte do modulo de Gestao de

Membros.

Figura 4.12: Diagrama de Classes para o Modulo de Gestao de Gestao de Membro.

4.6.1 Criacao de Perfil de Membro

Para cada instancia de Member existente no sistema deve tambem existir, associado a esta, uma

instancia de MemberProfile assim que a primeira e criada. No entanto, sendo as classes Member

e MemberProfile parte do domınio de dois modulos diferentes, nao e possıvel criar a instancia de

MemberProfile no construtor de Member. Para ser possıvel implementar esta funcionalidade, foi de-

cidido usar uma classe RelationListener. Classes RelationListener sao classes que permitem

adicionar comportamento extra quando dois objetos de domınio sao associados ou desassociados.

Neste caso, foi implementada a classe MemberProfileCreationListener que, quando uma instancia

de Member e associada a Bennu (este passo e realizado durante a sua criacao), cria uma nova instancia

de MemberProfile e associa-a a instancia de Member correspondente.

54

4.6.2 API para Perfil de Membro

Para sistemas externos terem acesso aos perfis dos membros do IPFN, e necessario ao novo SGI dis-

ponibilizar uma API que disponibilize essa informacao. Foi decidido usar JSON como formato de dados

da API. Portanto, e necessario converter os objetos de domınio para o formato JSON, e disponibili-

zar endpoits que devolvam a informacao pedida neste formato. A BennuFramework disponibiliza duas

ferramentas para a criacao de APIs JSON: JsonViewer e BennuRestResource.

As classes JsonViewer sao classes que permitem a conversao de qualquer instancia de uma

classe numa instancia de JsonElement. Para cada classe podem ser implementadas uma ou mais

classes JsonViewer. O processo de conversao para JSON consiste em criar uma nova instancia de

JsonElement vazia, adicionar as propriedades a esta instancia conforme desejado no JSON final, e

devolver a instancia. A Figura 4.13 representa a implementacao de um JsonViewer para a classe

MemberProfile.

Para definir os endpoints de uma API JSON, a BennuFramework disponibiliza a classe abstrata

BennuRestResource. As classes que implementam BennuRestResource tem acesso ao metodo view

que, dada uma instancia de uma classe, e um JsonViewer para a mesma classe, devolve o JsonElement

correspondente a instancia. Os metodos das classes BennuRestResource que sejam anotados com

@RequestMapping e devolvam um JsonElement correspondem aos endpoints da API.

4.7 Modulo de Gestao de Assiduidade

O modulo de Gestao de Assiduidade e o modulo responsavel pela gestao das presencas e ausencias

dos membros do IPFN. Deve permitir a membros iniciar e parar trabalho, fazer pedidos para adicionar

ou editar presencas e ausencias, listar presencas e pedidos realizados e gerar relatorios da estatıstica

de assiduidade, e a administradores consultar a assiduidade de todos os membros, aprovar ou rejeitar

pedidos e registar motivos, locais de trabalho, feriados e o numero de horas de trabalho por dia.

A Figura 4.14 representa o diagrama de classes usado para a implementacao deste modulo. A

classe Bennu faz parte da Bennu Framework, a classe Member faz parte do modulo de Gestao de Mem-

bros e a classe Project faz parte do modulo de Gestao de Projetos.

4.7.1 Iniciar e Parar Trabalho

Um membro do IPFN, para iniciar trabalho, deve indicar o projeto, local de trabalho e descricao para a

nova presenca. Ao iniciar, e criada uma nova instancia de Attendance, com os dados indicados, e a

data e hora no momento do pedido como hora de inıcio. A hora de fim permanece a NULL, e enquanto

a presenca nao tiver uma hora de fim, e considerada como sendo incompleta. A nova presenca e

tambem guardada na relacao Last Attendance. Ao terminar o trabalho, o sistema utiliza esta relacao

para encontrar a presenca que esta incompleta, e atualiza-a com a hora de fim (a data e hora no

momento que o pedido de terminar trabalho foi realizado).

55

Figura 4.13: Implementacao do JsonViewer para a classe MemberProfile.

No entanto, e possıvel que o membro se esqueca de terminar trabalho. Para este caso, foi desenvol-

vida uma tarefa que automaticamente termina presencas a meia-noite do fuso horario em vigor no local

de trabalho associado a Attendance. Esta tarefa e executada no inıcio de cada hora, usando para isto

56

Figura 4.14: Diagrama de Classes para o Modulo de Gestao de Assiduidade.

57

o agendamento de tarefas proporcionado pela BennuFramework. Dado que as presencas tem de ser

terminadas a meia noite do fuso horario em vigor no local de trabalho associado (e nao o fuso horario

configurado no servidor), executar esta tarefa a cada hora garante que o sistema mais rapidamente

deteta quais presencas e preciso terminar, independentemente do fuso horario em questao.

A relacao Last Attendance tambem e usada para automaticamente preencher os campos do for-

mulario de iniciar trabalho com os valores da presenca anterior.

4.7.2 Pedidos

Os membros do IPFN podem tambem fazer pedidos para adicionar ou editar presencas, ou para

adicionar ausencias. Os pedidos para adicionar presencas (RequestToAddAttendance) ou ausencias

(RequestToAddAbsence) devem conter toda a informacao necessaria para criar instancias de Attendance

e Absence, respetivamente.

Ao ser criado um novo pedido, este encontra-se no estado Pendente, e pode ser aprovado ou

rejeitado por um Administrador. Ao ser aprovado, o sistema altera o estado do pedido para Aprovado e

cria uma instancia de Attendance ou Absence com os mesmos valores dos atributos no pedido. Caso

o intervalo de tempo do pedido inclua varios dias, sao criadas varias instancias de Attendance ou

Absence, e cada instancia corresponde a cada dia incluıdo no pedido.

4.7.3 Estatıstica

O sistema consegue, com base nas presencas de cada membro, calcular o numero de dias, horas e

minutos trabalhados para cada projeto. Para tal, o sistema soma a duracao (em milissegundos) de cada

instancia de Attendance associada ao membro, separado por projeto, e no final divide em numero de

dias, horas e minutos.

O numero de dias e calculado com base no DailyWorkHoursPeriod que e aplicavel ao intervalo de

tempo das presencas. Os Administradores podem definir, para diferentes perıodos de tempo, quantas

horas de trabalho diarias devem ser usadas. Por exemplo, se ate dia 1 de Junho de 2016 eram 8 horas

diarias (exclusive), mas a partir dessa data passam a ser 7 horas diarias, entao o sistema utiliza o valor

de 8 horas diarias para calcular a estatıstica de todas as presencas cuja data vai ate a data limite do

DailyWorkHoursPeriod, e utiliza 7 horas diarias para calcular a estatıstica das restantes presencas.

O sistema discrimina em relacao ao numero de horas diarias, portanto a estatıstica da assiduidade

do membro fica dividida por projeto e horas de trabalho diarias. A Figura 4.15 representa o calculo das

estatısticas efetuado a um membro do IPFN para o ano de 2016, onde se pode verificar esta divisao.

4.8 Modulo de Gestao de Missoes

O modulo de Gestao de Missoes e o modulo responsavel pela gestao das missoes dos membros do

IPFN. As missoes sao registadas no Dot, e portanto este modulo deve utilizar a API do Dot para listar

as missoes do membro e gerar relatorios destas missoes.

58

Figura 4.15: Exemplo do calculo das estatısticas para um membro do IPFN para o ano de 2016.

A Figura 4.16 representa o diagrama de classes usado para a implementacao deste modulo. A

classe User faz parte da Bennu Framework.

Figura 4.16: Diagrama de Classes para o Modulo de Gestao de Missoes.

4.8.1 Implementacao da API no Dot

Antes do desenvolvimento desta tese, o Dot nao possuıa nenhuma API que permitisse a sistemas

externos consultar informacao sobre os processos de missao de um utilizador.

No ambito desta tese desenvolvemos, para o Dot, dois endpoints:

Listar e Procurar Missoes Este endpoint permite listar as missoes de um utilizador, assim como filtrar

os resultados segundos criterios de pesquisa. Devolve uma lista de objetos JSON com informacao

59

resumida sobre cada processo de missao que verifique os criterios de pesquisa. Apenas sao

listados os processos que o utilizador tenha permissao para consultar no DOT.

Consultar Processo de Missao Este endpoint permite, dado o numero de um processo de missao,

consultar informacao detalhada sobre esse processo. Devolve um objeto JSON com informacao

detalhada sobre o processo de missao indicado. Caso nao encontre um processo com o numero

indicado, ou o utilizador nao tenha permissoes para o consultar no DOT, e devolvido um erro.

De forma analoga ao Fenix, sistemas externos ao Dot (como e o caso do novo SGI) podem usar

OAuth2 para obterem autorizacao para fazerem uso destes endpoints. Este processo encontra-se

descrito na Seccao 4.5.2.

4.8.2 Listar Missoes do Dot

Como referido na Seccao 4.8.1, foi desenvolvida uma API para o Dot com um endpoint que permite a

listagem e pesquisa de missoes. Devido ao uso de OAuth2 por parte do Dot, e necessario autorizacao

por parte do membro para o sistema poder fazer uso desta API. Apos obter autorizacao, o sistema utiliza

o access token do membro para obter a lista de processos de missao presentes no Dot, conforme a

pesquisa efetuada.

E possıvel, no entanto, expandir a funcionalidade deste modulo para obter processos de missao de

outros servicos externos, sendo necessario, para isso, desenvolver uma classe que implemente a inter-

face MissionGatherer. Classes que implementam MissionGatherer tem como responsabilidade obter

os processos de missao do seu sistema de origem. Atualmente, as unicas classes que implementam

MissionGatherer sao DotMissionGatherer (que obtem os processos de missao presentes no Dot) e

MockMissionGatherer (que gera um lista de processos de missao, usada apenas para testar o modulo

sem ser necessario um sistema externo), como representado na Figura 4.17.

4.8.3 Gerar Relatorios de Missoes

Em adicao a listar todos os processos de missoes de um utilizador presentes no Dot, o sistema permite

gerar relatorios em formato PDF com informacao detalhada de um processo de missao. Para tal, foi

decidido usar iText11 2.1.7, uma biblioteca Java usada para a geracao de ficheiros em formato PDF.

Embora existam versoes mais recentes desta biblioteca, foi escolhida a versao 2.1.7 devido a sua

licenca GPL. Versoes mais recentes utilizam uma licenca AGPL, que e menos adequada para este

sistema.

4.9 Modulo de Gestao de Tickets de Suporte

O modulo de Gestao de Tickets de Suporte e o modulo responsavel pela gestao dos tickets criados

pelos membros do IPFN. Deve permitir a membros consultar e criar tickets, e adicionar comentarios

11http://itextpdf.com/

60

Figura 4.17: Diagrama de Classes para a interface MissionGatherer e as classes que a implementam.

aos seus tickets, e a administradores alterar o estado dos tickets.

A Figura 4.18 representa o diagrama de classes usado para a implementacao deste modulo. A

classe Bennu faz parte da Bennu Framework, e a classe Member faz parte do modulo de Gestao de

Membros.

Figura 4.18: Diagrama de Classes para o Modulo de Gestao de Tickets de Suporte.

4.9.1 Comentarios

Membros e Administradores tem a possibilidade de adicionar comentarios a Tickets de Suporte. Estes

comentarios sao listados juntamente com as restantes informacoes do ticket na pagina de visualizacao

de um ticket, ordenados por data e hora de criacao do comentario.

61

No entanto, existem dois tipos de comentarios: comentarios publicos, que sao visıveis a todos os

administradores e ao membro que criou o ticket, e comentarios internos, que sao visıveis apenas a

administradores. Para garantir que os comentarios internos nao sejam visıveis ao membro, sao usadas

duas implementacoes de AcceptableFactory diferentes:

SupportTicketCommentAdminAcceptableFactory gera um Acceptable cuja implementacao da fun-

cao Accept(o,c1) devolve sempre true.

SupportTicketCommentMemberAcceptableFactory gera um Acceptable cuja implementacao da fun-

cao Accept(o,c1) devolve true apenas se o comentario nao for interno.

O sistema decide qual das implementacoes usar com base nas permissoes do utilizador a requisitar

a pagina de visualizacao do ticket.

4.10 Modulo de Gestao de Rede Informatica

O modulo de Gestao de Rede Informatica e o modulo responsavel pela gestao dos Pedidos IP realiza-

dos por membros do IPFN. Deve permitir a membros listar, adicionar, renovar e abandonar Pedidos IP,

e a administradores aprovar, rejeitar e terminar Pedidos IP.

A Figura 4.19 representa o diagrama de classes usado para a implementacao deste modulo. A

classe Bennu faz parte da Bennu Framework, e a classe Member faz parte do modulo de Gestao de

Membros.

Figura 4.19: Diagrama de Classes para o Modulo de Gestao de Rede Informatica.

62

4.10.1 Workflow para um Pedido IP

Apos a criacao de um Pedido IP por um Membro, o pedido deve seguir um workflow ate a data final

indicada no pedido, ou ate ser abandonado, rejeitado ou terminado manualmente antes da data final. A

Figura 4.20 representa o Diagrama de Maquina de Estados para um Pedido IP.

Figura 4.20: Diagrama de Maquina de Estados de um Pedido IP.

Ao ser criado, o Pedido IP encontra-se no estado Pendente. Sendo um novo Pedido IP, nao lhe foi

ainda atribuıdo um endereco IP. Neste estado, um Administrador do modulo pode rejeitar ou aprovar

o pedido. Ao aprovar, e necessario ao Administrador atribuir um endereco IP. Caso a data de fim do

pedido passe sem o administrador aceitar ou recusar o pedido, este transaciona para o estado Expirado.

Apos ser aprovado, o pedido pode ser terminado ou rejeitado por um administrador, ou pode ser

abandonado pelo membro que o criou. O membro pode tambem renovar o pedido. Ao renovar um

pedido, e criado um novo Pedido IP com todos os mesmos atributos (incluindo o endereco IP), exceto

com uma nova data de fim determinada pelo membro. Este novo Pedido IP inicia no estado Pendente.

Caso a data final passe sem qualquer acao ser tomada, o pedido automaticamente transaciona para o

estado Expirado, e nenhuma outra acao pode ser tomada.

63

64

Capıtulo 5

Validacao

Este capıtulo detalha a metodologia de validacao que foi aplicada ao novo SGI do IPFN. A validacao do

sistema encontra-se dividida em 3 grupos: interface grafica, desempenho e funcionalidade.

5.1 Interface Grafica

Para a validacao da interface grafica, foram realizados testes com futuros utilizadores do sistema, ou

seja, membros do IPFN. Estes testes tiveram como objetivo testar a usabilidade da interface da nova

Intranet, e averiguar a satisfacao dos utilizadores relativamente a mesma. Esta validacao foi realizada

de forma quantitativa e qualitativa. A avaliacao quantitativa consistiu na realizacao de testes com uti-

lizadores, e esta detalhada na Seccao 5.1.1. A avaliacao qualitativa consistiu na realizacao de um

questionario, e esta detalhada na Seccao 5.1.2.

5.1.1 Avaliacao Quantitativa

A avaliacao quantitativa consistiu na realizacao de testes com utilizadores. Estes testes sao divididos

em duas fases distintas: uma primeira fase de introducao ao sistema, e uma segunda fase de realizacao

de tarefas.

Durante a fase de introducao ao sistema, era permitido ao utilizador explorar o sistema e a sua

interface. O utilizador podia (e era incentivado a) fazer perguntas sobre o sistema e como utiliza-lo.

Apos o termino da fase de introducao, dava-se inıcio a fase de realizacao de tarefas. Durante esta

fase, era pedido aos utilizadores que realizassem um conjunto de tarefas utilizando o sistema. Em

cada tarefa, o utilizador devia indicar quando se encontrava pronto para comecar a sua realizacao,

como tambem quando considerava que a tarefa tinha sido terminada. Durante a realizacao de cada

tarefa nao podia haver dialogos com o utilizador. Caso o utilizador tivesse alguma questao ou algum

comentario a fazer em relacao a interface, apenas poderia faze-lo apos a conclusao da tarefa que se

encontrava a realizar.

Quatro tipos de dados foram recolhidos durante a realizacao das tarefas:

65

1. Conclusao da tarefa: Indica se o utilizador conseguiu realizar a tarefa ate ao fim. Caso o utili-

zador decida desistir da tarefa antes de a terminar, ou haja algum obstaculo por parte do sistema

que impeca a tarefa de ser realizada ou terminada, nao e considerado que a tarefa tenha sido

concluıda. Nenhum outro dado e recolhido caso a tarefa nao tenha sido concluıda.

2. Tempo demorado na tarefa: O tempo, em segundos, que o utilizador demorou durante a reali-

zacao da tarefa. O tempo comeca a contar a partir do momento em que o utilizador indica que se

encontra pronto para comecar a tarefa, e termina assim que o utilizador indique que a tarefa foi

concluıda.

3. Numero de cliques efetuados: O numero de cliques total que o utilizador realizou para terminar

a tarefa. E considerado um clique sempre que:

• O utilizador muda de pagina.

• O utilizador muda de separador (em paginas que possuem diferentes separadores).

• O utilizador provoca o aparecimento ou desaparecimento de um modal.

• O utilizador seleciona um campo de introducao de dados ou de pesquisa.

• O utilizador seleciona uma opcao num campo de escolha multipla (select).

De notar que a introducao de texto e selecao de datas e horas usando selecionadores de data e

hora (DateTimePickers) nao sao considerados na contagem de cliques.

4. Numero de erros cometidos: O numero de erros que o utilizador cometeu durante a realizacao

da tarefa. E considerado um erro sempre que o utilizador se desvia do caminho (ou um dos

caminhos) necessario para a realizacao da tarefa, e/ou utiliza indevidamente um elemento da

interface. Exemplos de erros incluem:

• O utilizador nao chegou ao final correto da tarefa.

• O utilizador insere texto em dois idiomas diferentes em campos multilingue sem selecionar

os idiomas corretos.

• O utilizador insere texto em apenas um dos idiomas pedidos em campos multilingue.

• O utilizador utiliza campos de pesquisa numa tentativa de os utilizar como campos de intro-

ducao de dados.

• O utilizador nao insere corretamente uma data e hora ao usar DateTimePickers.

Cada tipo de erro apenas conta uma vez por tarefa. Ao ser realizado um erro, era informado o

utilizador do facto e pedido para tentar realizar a tarefa usando um metodo diferente.

5.1.2 Avaliacao Qualitativa

A avaliacao qualitativa consistiu na realizacao de um questionario que utilizadores responderam apos

a interacao com o sistema. Este questionario esta dividido em tres seccoes:

66

1. Dados pessoais e previsao de utilizacao: Nesta seccao e pedida a idade do utilizador, e e

lhe perguntado quais os dispositivos que ele preve usar com maior frequencia para aceder ao

sistema, assim como quais os modulos do sistema que ele preve usar com maior frequencia.

2. System Usability Scale (SUS): Esta seccao e baseada no questionario SUS [8], onde sao reali-

zadas 10 perguntas, nas quais e apresentada uma frase e o utilizador deve marcar, numa escala

de 1 a 5, o grau de concordancia com a frase.

Com as respostas, e possıvel calcular um numero, entre 0 e 100, que representa uma medida

composta da usabilidade global do sistema. A este numero da-se o nome de pontuacao SUS.

Para calcular a pontuacao SUS, primeiro soma-se as contribuicoes de cada item, que varia entre

0 a 4. Para os itens 1, 3, 5, 7 e 9, a contribuicao e igual a posicao da escala menos 1. Para os

itens 2, 4, 6, 8 e 10, a contribuicao e igual a 5 menos a posicao da escala. No final, multiplica-se

o resultado da soma por 2,5 para obter a pontuacao SUS.

3. Comentarios adicionais: Nesta seccao e oferecido um espaco para os utilizadores deixarem

quaisquer comentarios adicionais sobre o sistema que desejam transmitir.

Este questionario esta apresentado no Apendice D.

5.1.3 Planeamento

Antes da realizacao de qualquer sessao de avaliacao da interface grafica, foram realizados tres testes-

piloto, com tres membros do IPFN, com o objetivo de testar e validar os testes com utilizadores e o

questionario. Estes tres testes-piloto foram realizados em Outubro de 2016.

Apos a validacao dos metodos de avaliacao usados, avancou-se para a realizacao da avaliacao da

interface grafica. Foram escolhidos 13 outros membros do IPFN. Para garantir que os resultados nao

seriam distorcidos, foram escolhidos membros que nao participaram na realizacao dos testes-piloto.

A avaliacao da interface grafica realizou-se durante o mes de Novembro de 2016, com sessoes

marcadas pelos utilizadores. Cada sessao teve a duracao estimada de 1 hora, sendo que os primeiros

10 minutos foram usados para introduzir o utilizador ao sistema, os 40 minutos seguintes eram alocados

para a realizacao das tarefas, e os ultimos 10 minutos para a realizacao dos questionarios.

Os utilizadores realizaram os testes individualmente, numa sala pertencente ao IPFN com pouco

ruıdo e poucas interferencias externas (foi tambem pedido a todos os utilizadores a testar a interface

que desligassem os telemoveis e outros equipamentos que pudessem perturbar a realizacao dos tes-

tes). Nesta sala, no inıcio de cada sessao, encontrava-se um portatil ligado e com um browser aberto

na pagina de autenticacao do sistema. Este portatil encontrava-se ligado a um projetor que permitia

visualizar as acoes do utilizador, utilizado para registar os dados necessarios durante a realizacao dos

testes com utilizadores.

Os utilizadores realizaram 22 tarefas, agrupadas por modulos. As tarefas foram as seguintes:

1. Membros

(a) Qual e o e-mail do membro Pedro Manuel Galvao da Silva?

67

2. Perfil de Membro

(a) Qual e a Chave Publica associada ao seu Perfil de Membro?

(b) Adicionar uma descricao ao seu Perfil de Membro. Em Portugues adicionar o texto “Isto e

um teste.” e em Ingles adicionar o texto “This is a test.”

3. Assiduidade

(a) Presencas

i. Iniciar trabalho no projecto com o nome “Projecto Teste”, no local de trabalho “IST”.

ii. Parar trabalho.

(b) Pedidos

i. Fazer um Pedido de Marcacao, com os seguintes dados:

Projeto: “Projeto Teste”

Local de Trabalho: “IPFN – Lisboa”

Duracao: 1 de Setembro de 2016 09:00 as 17:00

Motivo: “Esquecimento”

Justificacao: “Isto e um teste.”

ii. Fazer um Pedido de Alteracao, para editar a primeira presenca criada, para o local de

trabalho passar a ser “IPFN - Lisboa”, com a justificacao “Isto e um teste.”

iii. Fazer um Pedido de Falta, com os seguintes dados:

Projeto: “Projeto Teste”

Local de Trabalho: “IPFN – Lisboa”

Duracao: 1 de Setembro de 2016 as 00:00 ate 1 de Outubro de 2016 as 00:00

Motivo: “Ferias”

Justificacao: “Isto e um teste.”

(c) Estatıstica

i. Exportar dados estatısticos do mes atual para PDF.

4. Missoes

(a) Autorizar a aplicacao a aceder aos dados sobre Missoes no Dot.

(b) Qual e o estado da Missao mais recente?

(c) Exportar para PDF o relatorio relativo a Missao mais antiga.

5. Tickets de Suporte

(a) Adicionar um Ticket com o tıtulo “Preciso de ajuda para terminar o teste.” e com a descricao

“Alguem me ajude”.

6. Rede Informatica

68

(a) Adicionar um Pedido IP com os seguintes dados:

Endereco MAC: “11:22:33:44:55:66”

Hospedeiro: “teste.com”

Localizacao da Maquina: “IPFN”

IP Publico: Sim

Duracao: 1 de Dezembro de 2016 ate 30 de Dezembro de 2016

Justificacao: “Isto e um teste.”

7. Projetos

(a) Qual e o seu papel no Projeto “Projeto Teste”?

8. Grupos de Investigacao

(a) Qual e o seu papel no Grupo de Investigacao “Grupo Teste”?

9. Notıcias

(a) A notıcia com o tıtulo “Notıcia Teste” foi criada por que Membro?

10. Inventario

(a) Qual e o tipo do Item com o nome “Item Teste”?

(b) Que reservas existem no Item com o nome “Item Teste” para o dia 30 de Novembro de 2016?

(c) Adicionar uma Reserva para o Item com o nome “Item Teste”, para o dia 29 de Novembro de

2016, entre as 15:00 e as 16:00 horas, com a justificacao “Isto e um teste.”

(d) Cancelar a Reserva criada na tarefa anterior, com a justificacao “Isto e um teste.”

(e) Fazer um Pedido de Cancelamento de Reserva a Reserva para o Item com o nome “Item

Teste”, do dia 28 de Novembro de 2016, entre as 10:00 e as 11:00 horas, com a justificacao

“Isto e um teste.”

5.1.4 Resultados

Esta seccao foi dividida em duas subseccoes, uma para a analise de resultados da avaliacao qualitativa,

e outra para a analise de resultados da avaliacao quantitativa. Para a avaliacao qualitativa, encontram-

se os resultados obtidos para cada um dos tipos de dados recolhidos durante a realizacao das tarefas

relativas aos modulos de gestao de Recursos Humanos e Suporte Informatico, cujo desenho e desen-

volvimento foram objeto desta tese. A analise dos resultados para os restantes modulos esta disponıvel

noutra tese.

69

Avaliacao Quantitativa

Nos graficos das Figuras 5.1, 5.2, 5.3 e 5.4 encontram-se os resultados obtidos para cada um dos

tipos de dados recolhidos durante a realizacao das tarefas. A analise dos resultados para os restantes

modulos esta disponıvel noutra tese.

Pela analise da Figura 5.1, podemos verificar que todos os utilizadores conseguiram terminar a

maioria das tarefas. Na tarefa 2.b houve um utilizador que desistiu da tarefa sem a terminar (nao

conseguiu realizar corretamente a tarefa e nao conseguiu perceber qual foi o erro cometido), e nas

tarefas 4.b e 4.c houve um utilizador que nao tinha quaisquer missoes no Dot, o que impossibilitou a

realizacao destas tarefas.

Figura 5.1: Total de utilizadores que terminaram cada tarefa.

Figura 5.2: Media e Desvio Padrao do tempo demorado por tarefa.

A Figura 5.2 representa o tempo despendido pelo utilizador para realizar cada tarefa. Podemos

verificar que as tarefas com um maior desvio padrao sao as tarefas 2.b, 3.b.i, 3.b.ii, 3.b.iii, 3.c.i, 5.a e 6.a.

Na tarefa 2.b notou-se que havia dificuldade por parte dos utilizadores em perceber o funcionamento

do campo multilingue. Nas tarefas 3.b.i, 3.b.ii e 3.b.iii, alguns dos utilizadores tiveram dificuldade em

70

Figura 5.3: Media e Desvio Padrao do numero de cliques efetuados por tarefa.

Figura 5.4: Total de erros cometidos por utilizadores para cada tarefa.

perceber o funcionamento de DateTimePickers. Na tarefa 3.c.i, uma leitura incompleta do enunciado

induziu os utilizadores em erro. Finalmente, nas tarefas 5.a e 6.a, os utilizadores tinham tendencia a

usar a pesquisa como meio de insercao de dados.

A Figura 5.3 representa o numero de cliques efetuados pelo utilizador para realizar cada tarefa.

Nesta figura, as tarefas 3.a.i, 3.b.i, 3.c.i e 6.a apresentam um desvio padrao mais significativo do que

as restantes tarefas. Na tarefa 3.a.i, devido ao uso de campos de escolha multipla (select), alguns utili-

zadores quiseram verificar quais as opcoes disponıveis para cada um dos campos levando a efetuarem

mais cliques que outros que aproveitavam que o valor por omissao de alguns dos campos era o pedido

e nao efetuavam cliques para selecionar o valor para estes campos. Relativamente as restantes tare-

fas, podemos concluir que as dificuldades com DateTimePickers tambem contribuıram para um elevado

desvio padrao no numero de cliques.

A Figura 5.4 representa o numero de erros efetuados pelo utilizador ao realizar cada tarefa. Nesta

figura, as tarefas 2.a, 2.b, 3.b.i, 3.c.i, 5.a e 6.a sao as que apresentam um maior numero de erros

cometidos. Na realizacao tarefa 2.a, sendo a primeira tarefa que requer que o utilizador mude de

71

modulo, notou-se que alguns dos utilizadores permaneciam no modulo de Membros antes de perceber

que o valor pedido se encontrava no modulo de Perfil de Membro. Nas restantes tarefas, podemos

concluir que que as dificuldades com DateTimePickers e o uso de campos de pesquisa como meio de

insercao de dados tambem contribuıram para um elevado numero de erros.

Tendo em conta estes resultados, pode-se concluir que as tarefas 2.b, 3.b.i, 3.c.i, 5.a e 6.a sao as

tarefas que os utilizadores mais tiveram dificuldades em realizar.

• Para a tarefa 2.b, verificou-se que o campo multilingue confundiu os utilizadores, que muitas vezes

nao notavam que o campo permitia selecionar idiomas diferentes.

• Para a tarefa 3.b.i, verificou-se que o funcionamento do DateTimePicker nao era claro para os

utilizadores. O DateTimePicker requer que o utilizador selecione uma data, um valor para as

horas e um valor para os minutos, nesta ordem. No entanto, os utilizadores muitas vezes nao

notavam que o DateTimePicker pedia os minutos, levando-os a cancelar a introducao da data e

hora inadvertidamente.

• Para a tarefa 3.c.i, verificou-se que os utilizadores tinham tendencia a nao ler o enunciado da

pergunta ate ao fim, levando-os a exportar dados para o ano inteiro e nao para o mes. Apos uma

leitura mais cuidadosa do enunciado, conseguiam terminar corretamente a tarefa.

• Para as tarefas 5.a e 6.a, os utilizadores tentaram utilizar os campos de pesquisa como campos de

introducao de dados. Estes campos nao foram identificados como campos de pesquisa porque,

como nao havia Tickets de Suporte nem Pedidos IP, os utilizadores nao identificaram corretamente

as paginas que os listavam e permitiam efetuar pesquisas, e pensavam que eram paginas para

inserir dados.

Para cada um destes problemas, as sugestoes para a sua resolucao sao:

• Para campos multilingue, indicar abaixo destes quantos idiomas o campo requer, e quantos ja se

encontram preenchidos, pode ajudar o utilizador a perceber melhor o funcionamento do campo e,

portanto, levar a uma reducao dos erros cometidos.

• Devido ao funcionamento pouco claro do DateTimePicker uma solucao seria evitar o seu uso, e

substituir pela combinacao de dois campos diferentes (um para a data, o outro para as horas).

• Como os campos de pesquisa apenas tem utilidade quando existem itens para listar, e a sua

presenca quando nao existem itens na listagem gera confusao, uma possıvel solucao seria ape-

nas mostrar estes campos de pesquisa quando existem itens para listar.

Avaliacao Qualitativa

Foram realizados um total de 13 questionarios. Nos graficos das Figuras 5.5, 5.6, 5.7 e 5.8 encontram-

se os resultados obtidos para os questionarios realizados.

Dos membros que responderam ao questionario, foi calculada uma idade media de 40.9 com um

desvio padrao de 10.7. A Figura 5.5 representa a distribuicao das idades dos utilizadores. Pode-se

72

Figura 5.5: Distribuicao das idades dos utilizadores.

concluir que houve uma grande variedade nas idades dos membros que realizaram os testes e os

questionarios.

Figura 5.6: Previsao dos dispositivos que irao ser usados com maior frequencia por parte dos utilizado-res.

A Figura 5.6 representa a previsao dos utilizadores em relacao aos dispositivos que irao ser usados

com maior frequencia para aceder ao sistema. Pode-se concluir que, embora os computadores de

secretaria e portateis sejam os dispositivos que serao mais usados para aceder ao sistema, dispositivos

portateis como tablets e smartphones tambem serao bastante utilizados, o que reforca a importancia

do uso de uma interface adaptativa.

73

Figura 5.7: Previsao dos modulos que irao ser usados com maior frequencia por parte dos utilizadores.

A Figura 5.7 representa a previsao dos utilizadores em relacao aos modulos que irao ser usados

com maior frequencia. Os modulos que serao mais utilizados sao: Assiduidade, Tickets de Suporte,

Missoes, Rede e Projetos. Devido a elevada pontuacao destes modulos, e importante garantir que o seu

acesso seja o mais imediato possıvel, dando acesso as funcionalidades mais usadas destes modulos

diretamente na pagina de entrada do sistema.

Figura 5.8: Distribuicao das pontuacoes SUS obtidas.

Dos membros que responderam ao questionario, foi calculada uma pontuacao SUS media de 85.4

com um desvio padrao de 9.1. A Figura 5.5 representa a distribuicao das pontuacoes SUS. Em geral,

as pontuacoes SUS foram bastante elevadas, o que indica que os utilizadores sentiram que o sistema

tinha uma boa usabilidade, e tiveram uma experiencia de utilizacao bastante positiva.

74

5.2 Desempenho

De forma a verificar a capacidade do sistema sob as condicoes normais de uso a que estara sujeito

num ambiente de producao, foram realizados varios testes de desempenho, indicados na Seccao 5.2.2.

Para a realizacao dos testes de desempenho foi utilizada a ferramenta JMeter1. O JMeter e uma

aplicacao open source desenvolvida em Java capaz de avaliar o desempenho de uma aplicacao Web,

simulando varios utilizadores a utilizar diversas funcionalidades do sistema a ser avaliado.

Os testes foram realizados numa maquina com as seguintes especificacoes

• Processador Intel Core2 Quad a 2.40GHz.

• 6GB de memoria RAM DDR2 .

• 64KB de cache nıvel 1 e 4MB de cache nıvel 2.

• Dois discos rıgidos configurados num Redundant Array of Independent Disks (RAID), com uma

velocidade de leitura de 3.8 GB/s e uma velocidade escrita de 216 MB/s.

5.2.1 Preparacao do Sistema

De forma a realizar estes testes, foi necessario introduzir um conjunto de dados no sistema. Para este

fim, foram criados 800 membros, 10 grupos de investigacao e 25 projetos. Cada membro tem um

username e password unicos, ou seja, nenhum utilizador simulado no JMeter devera partilhar a sua

conta de membro. Todos os membros encontram-se associados a um grupo de investigacao e a um

projeto.

5.2.2 Testes de Desempenho

Os testes de desempenho foram divididos em nove cenarios - cinco com variacao no numero de uti-

lizadores, e restantes com variacao no numero de acoes tomadas. Em cada cenario, um numero de

utilizadores (simulados usando JMeter) realizou um conjunto de acoes segundo uma determinada or-

dem. Cada cenario foi repetido duas vezes, em que na primeira vez nao existiu nenhum tempo de

espera entre cada acoes e na segunda vez existiu um tempo de espera de 1 segundo entre acoes.

O numero de utilizadores e acoes realizadas para cada cenario sao:

1. 50 utilizadores que irao realizar 50 acoes cada (total de 2500 acoes realizadas).

2. 100 utilizadores que irao realizar 50 acoes cada (total de 5000 acoes realizadas).

3. 200 utilizadores que irao realizar 50 acoes cada (total de 10000 acoes realizadas).

4. 400 utilizadores que irao realizar 50 acoes cada (total de 20000 acoes realizadas).

5. 800 utilizadores que irao realizar 50 acoes cada (total de 40000 acoes realizadas).

1https://jmeter.apache.org/

75

6. 50 utilizadores que irao realizar 100 acoes cada (total de 5000 acoes realizadas).

7. 50 utilizadores que irao realizar 200 acoes cada (total de 10000 acoes realizadas).

8. 50 utilizadores que irao realizar 400 acoes cada (total de 20000 acoes realizadas).

9. 50 utilizadores que irao realizar 800 acoes cada (total de 40000 acoes realizadas).

Os primeiros cinco cenarios permitiram estudar o comportamento do sistema com o crescimento do

numero de utilizadores (50 acoes foram realizadas por 50, 100, 200, 400 e finalmente 800 utilizado-

res). Os ultimos quatro cenarios, juntamente com o primeiro, permitiram estudar o comportamento do

sistema com o crescimento de acoes realizadas (50 utilizadores fizeram 50, 100, 200, 400 e finalmente

800 acoes).

As acoes que os utilizadores realizaram foram as seguintes:

• Fazer Login: Cada utilizador, no inıcio de cada fase, autenticou-se usando um login local.

• Fazer Logout: No final de cada fase, cada utilizador fez logout do sistema.

• Iniciar Trabalho: O utilizador inicia trabalho no projeto indicado na Seccao 5.2.1 e num local de

trabalho qualquer.

• Parar Trabalho: O utilizador para o trabalho atual.

• Trocar Trabalho: O utilizador para o trabalho atual e inicia um novo trabalho.

• Listar Membros: O utilizador consulta a primeira pagina da lista de membros, ordenada pela

ordem por defeito.

• Pesquisar Membros. O utilizador pesquisa pelos membros cujo email contem a sequencia de

carateres “ipfn.tecnico.ulisboa.pt” (excluindo aspas).

• Listar Reservas: O utilizador consulta as reservas existentes para um item de inventario qualquer

no mes de Janeiro.

• Adicionar Reserva: O utilizador realiza uma reserva a um item de inventario qualquer. A reserva

e realizada para um dia aleatorio de Janeiro de 2017, tem inıcio a uma hora aleatoria do dia, e

tem uma duracao aleatoria (ate um maximo de uma hora).

Em cada um dos cenarios, os utilizadores realizaram as acoes na seguinte ordem:

1. Fazer Login

2. Iniciar Trabalho

3. Escolher, aleatoriamente, uma acao a realizar (de entre Trocar Trabalho, Listar Membros, Pesqui-

sar Membros, Listar Reservas, Adicionar Reserva). Repetir este passo ate atingir o numero de

acoes a realizar.

4. Parar Trabalho

76

5. Fazer Logout

Esta ordem representa um cenario pessimista para o comportamento tıpico de um membro do IPFN.

5.2.3 Metricas

Durante a realizacao dos testes foram medidos:

• Frequencia de erros: A frequencia de erros mede quantos pedidos deram erro, em relacao ao

numero total de pedidos efectuados. E considerado que tenha ocorrido um erro quando, para um

certo pedido, o servidor respondeu com o codigo 500 Internal Server Error.

• Taxa de transferencia (Throughput): O throughput mede a quantidade de tarefas em simultaneo

e que o servidor e capaz de realizar. Esta metrica foi medida em numero de pedidos respondidos

por segundo.

• Tempo medio de resposta: O tempo medio de resposta mede quanto tempo, em media, e que

o cliente teve que esperar para obter uma resposta, desde que fez o seu pedido. Esta metrica foi

medida em milissegundos.

5.2.4 Resultados

Esta seccao foi dividida em tres subseccoes, uma para cada metrica. Para cada metrica sao apresen-

tados dois graficos dos resultados obtidos, sendo o primeiro a relacionar com a variacao do numero de

utilizadores e o segundo a relacionar com a variacao do numero de acoes por utilizador, seguidos de

uma analise dos resultados e de uma conclusao.

Frequencia de erros

Nos graficos das Figuras 5.9 e 5.10 encontram-se os resultados obtidos referentes a frequencia de

erros.

Na Figura 5.9 pode-se verificar que a frequencia de erros cresce exponencialmente com o numero

de utilizadores. No entanto, na figura 5.10, a frequencia de erros mantem-se constante a 0% com o

aumento no numero de acoes. Estes resultados verificam-se independentemente de existir, ou nao

existir, 1 segundo de espera entre acoes realizadas por cada utilizador.

Sabendo que o numero total de acoes sao iguais, pode-se concluir que o crescimento na frequencia

de erros deve-se ao maior numero de sessoes que estao a ser geridas pela Bennu Framework, e nao

devido ao processamento de cada acao.

Throughput

Nos graficos das Figuras 5.11 e 5.12 encontram-se os resultados obtidos referentes ao throughput do

sistema.

77

Figura 5.9: Frequencia de erros com o aumento de numero de utilizadores.

Figura 5.10: Frequencia de erros com o aumento de numero de acoes.

Na Figura 5.11 pode-se verificar que, sem tempo de espera entre acoes, o throughput decresce ate

chegar aos 400 utilizadores, onde comeca a crescer novamente. Verifica-se uma situacao semelhante

quando existe 1 segundo de espera entre acoes, com uma excecao para 50 utilizadores. Este baixo

valor deve-se ao facto que, com poucos utilizadores e tempo de espera entre acoes, existe um baixo

numero de pedidos a serem efetuados por segundo, levando a um baixo throughput.

Na figura 5.12 pode-se notar que, sem tempo de espera entre acoes, existe um decrescimo de

throughput ate as 200 acoes por utilizador, que volta a crescer apos as 200 acoes. No entanto, quando

existe 1 segundo de tempo de espera entre acoes, o throughput ja cresce logaritmicamente com o

78

Figura 5.11: Throughput com o aumento de numero de utilizadores.

Figura 5.12: Throughput com o aumento de numero de acoes.

numero de acoes.

Com o aumento no numero de pedidos realizados por segundo, o decrescimo no throughput indica

que o tempo de processamento para cada pedido cresce, levando a menos pedidos respondidos por

segundo. No entanto, este crescimento no tempo de processamento para cada pedido nao e suficiente

para diminuir o throughput com o crescimento no numero total de acoes, quer devido a um crescimento

no numero de utilizadores ou no numero de acoes por utilizador, dado um valor suficientemente grande

de total de acoes.

79

Tempo Medio de Resposta

Nos graficos das Figuras 5.13 e 5.14 encontram-se os resultados obtidos referentes ao tempo medio

de resposta do sistema.

Figura 5.13: Tempo medio de resposta com o aumento de numero de utilizadores.

Figura 5.14: Tempo medio de resposta com o aumento de numero de acoes.

Na Figura 5.13 pode-se verificar que o tempo de resposta cresce linearmente com o numero de

utilizadores, independentemente de existir, ou nao existir, 1 segundo de espera entre acoes realizadas

por cada utilizador.

Na figura 5.14 pode-se notar que, sem tempo de espera entre acoes, existe um crescimento no

80

tempo medio de resposta ate as 200 acoes por utilizador, e volta a decrescer apos as 200 acoes.

No entanto, quando existe 1 segundo de tempo de espera entre acoes, o tempo medio de resposta e

constante.

Sabendo que o numero de acoes totais sao iguais, pode-se concluir que o crescimento no tempo

medio de resposta deve-se ao maior numero de sessoes que estao a ser geridas pela Bennu Fra-

mework, e nao devido ao processamento de cada acao.

5.3 Funcionalidade

O sistema entrou em producao no dia 13 de Marco de 2017, passando a ser utilizado por todos os

membros do IPFN num contexto real de utilizacao. Desde entao que foram reportados os seguintes

erros no sistema:

• Os campos Projeto e Justificacao nos Pedidos de Ausencia nao deviam existir.

• Ao calcular a duracao de uma Presenca (durante o calculo da estatıstica), nao esta a ser descon-

tado uma hora de almoco caso a duracao da Presenca seja superior ou igual a 7 horas.

• Ao calcular a duracao total num projeto (durante o calculo da estatıstica), nao estao a ser consi-

deradas as diferentes horas de trabalho diarias, e em vez estao a ser assumidas sempre 7 horas

diarias.

• O sistema nao devia permitir adicionar registos de Presenca ou pedidos que se sobreponham a

outros registos ja existentes pertencentes ao mesmo membro.

• Adicionar um comentario vazio a um Ticket de Suporte resulta num erro inesperado.

• Apos alterar o estado de um ticket, o utilizador esta a ser redirecionado para a listagem de tickets

em vez de ser redirecionado para a pagina do ticket.

• Aparece ocasionalmente a mensagem de erro “A hora de fim deve vir apos a hora de inıcio” ao

tentar efetuar uma reserva, mesmo que os dados inseridos estejam corretos.

• Apos expirar um access token, o sistema nao utiliza o refresh token corretamente para o renovar,

levando o sistema a assumir erroneamente que o membro revogou a autorizacao no Fenix.

Todos os problemas listados foram corrigidos, e o sistema de producao ja foi atualizado com estas

correcoes.

81

82

Capıtulo 6

Conclusoes

Este documento apresenta o desenho e implementacao do novo SGI para o IPFN, em particular no que

diz respeito aos modulos relativos a Gestao de Recursos Humanos e Suporte Informatico.

6.1 Resumo

O Capıtulo 2 apresenta os requisitos do IPFN relativamente a funcionalidade de Gestao de Recursos

Humanos e Suporte Informatico. O Capıtulo 3 analisa varios SGI, existentes no mercado, em particular

as suas caracterısticas e as funcionalidades oferecidas com respeito a Gestao de Recursos Humanos

e Suporte Informatico. Com base no resultado desta comparacao, foram apresentadas diferentes al-

ternativas para a implementacao do novo SGI do IPFN, e concluiu-se que o desenvolvimento de um

sistema de raiz era a melhor solucao.

O Capıtulo 4 descreve o desenho e a implementacao do novo SGI do IPFN, em particular os modulos

relativos a Gestao de Recursos Humanos e Suporte Informatico. Este novo sistema integra-se no ecos-

sistema do IST, utilizando varios recursos dos sistemas CAS Tecnico, Fenix e Dot, e disponibilizando

informacao adicional a sistemas externos como o Portal IPFN, atraves de uma API JSON. O novo sis-

tema foi desenvolvido de forma modular, permitindo a facil adicao e modificacao de modulos. Utiliza

a Bennu Framework, tirando partido da sua arquitetura modular e varias funcionalidades oferecidas.

Para satisfazer os requisitos de pesquisa e ordenacao do IPFN, e atendendo que a Bennu Framework

nao oferece suporte para estas funcionalidades, foi tambem desenvolvido uma solucao que procura ser

flexıvel e extensıvel para qualquer modulo do sistema.

O Capıtulo 5 detalha a validacao experimental do novo SGI do IPFN. A validacao do sistema foi

dividida em tres partes: interface grafica, desempenho e funcionalidade. Para a validacao da interface

grafica, foram realizados testes com futuros utilizadores do sistema, ou seja, membros do IPFN. Um

total de 13 utilizadores participaram nos testes, onde lhes foi pedido para realizar um conjunto de

tarefas usando o novo SGI e, de seguida, responderem a um questionario de satisfacao. Com base nos

resultados destes testes e questionarios, podemos concluir que os utilizadores sentiram que o sistema

tinha uma boa usabilidade, e tiveram uma experiencia de utilizacao bastante positiva. Para a avaliacao

83

do desempenho, foram realizados testes com a ferramenta JMeter. Os testes de desempenho foram

divididos em nove cenarios diferentes: cinco cenarios com variacao no numero de utilizadores e um

numero constante de acoes por utilizador, e quatro cenarios com um numero constante de utilizadores

e variacao no numero de acoes por utilizador. Para cada cenario foram medidos: a frequencia de

erros, a taxa de transferencia, e o tempo medio de resposta. Com base nos resultados destes testes,

concluımos que o sistema responde as necessidades de desempenho do IPFN. O sistema mostrou

conseguir manter um bom desempenho em situacoes com um elevado numero de utilizadores e acoes,

mantendo um crescimento controlado das tres metricas.

Os resultados do trabalho realizado nesta tese sao:

• Realizacao de um sistema que cumpre todos os requisitos apresentados no Capıtulo 2. O sistema

entrou em producao no dia 13 de Marco de 2017, passando a ser utilizado por todos os membros

do IPFN num contexto real de utilizacao. Desde entao foram reportados um total de oito erros

no sistema: quatro erros na interface com o utilizador, dois erros no calculo das estatısticas de

assiduidade, um erro no controlo do registo de presencas, e um erro na sincronizacao de dados

pessoais com o sistema Fenix. Estes erros foram corrigidos, e o sistema de producao ja foi

atualizado com estas correcoes.

• Um documento que descreve de forma exaustiva o trabalho a realizar para acrescentar um novo

modulo ao sistema. Este documento esta apresentado no Apendice A.

• Um documento que apresenta todos os passos a realizar para instalar e atualizar o sistema. O

Apendice B apresenta este documento.

• Um documento que lista, para cada modulo desenvolvido, a lista de acoes que resulta no envio

automatico de um email. Este documento esta apresentado no Apendice C.

6.2 Trabalho Futuro

Com o sistema em producao e a ser utilizado por membros reais, e necessario suportar e manter o

sistema com correcao de problemas encontrados e continuar o desenvolvimento de funcionalidades e

novos modulos que sejam entretanto concebidos. Em particular, e necessario o desenvolvimento dos

modulos de Gestao de Producao Cientıfica e Gestao de Aquisicoes. O modulo de Gestao de Producao

Cientıfica integra-se com outros sistemas como o ORCID1, e permite a membros e administradores gerir

todos os documentos cientıficos produzidos pelo IPFN, tais como teses, patentes e artigos, para serem

disponibilizados atraves da API e assim estarem presentes no Portal do IPFN. O modulo de Gestao

de Aquisicoes integra-se com o Dot, e, a semelhanca do modulo de Gestao de Missoes, permite a

membros obter a lista de processos de aquisicao presentes no Dot e gerar relatorios de aquisicoes. O

desenvolvimento deste modulo implicaria, tambem, o desenvolvimento de novos endpoints na API do

Dot.1https://orcid.org/

84

Tambem sera importante estender o uso deste sistema a outros centros de investigacao cientıfica,

disponibilizando-o para permitir o desenvolvimento de novos modulos, ou alteracoes a modulos exis-

tentes, conforme as necessidades especıficas de cada centro.

85

86

Bibliografia

[1] J. Goulart, P. Silva, A. Vale, and H. Galhardas. Levantamento de Requisitos do Sistema de Gestao

de Informacao do Instituto de Plasmas e Fusao Nuclear. INESC-ID, 2015.

[2] W. van der Aalst and K. van Hee. Workflow Management: Models, Methods, and Systems (Coope-

rative Information Systems). The MIT Press, 1st edition, 2002.

[3] H. Bidgoli. The Internet Encyclopedia, volume 1. John Wiley & Sons, 2004.

[4] M. Kavanagh, M. Thite, and R. Johnson. Human Resource Information Systems: Basics, Applicati-

ons, and Future Directions. Sage Publications, Inc., 3rd edition, 2014.

[5] J. Spolsky. Painless bug tracking. Joel on Software, 2000.

[6] P. Silva. Sistema de Gestao de Informacao do IPFN - Gestao de Producao e de Activos. Tese

Mestrado em Engenharia Informatica e de Computadores, Instituto Superior Tecnico, 2016.

[7] G. Booch, J. Rumbaugh, and I. Jacobson. The Unified Modeling Language User Guide. Addison-

Wesley Professional, 2nd edition, 2005.

[8] J. Brooke. SUS - A “quick and dirty” usability scale. In Usability Evaluation in Industry. Taylor and

Francis, 1996.

87

88

Apendice A

Acrescentar um novo modulo ao

Sistema

Sendo o novo Sistema de Gestao de Informacao do IPFN modular, e possıvel adicionar e remover

modulos conforme as necessidades dos utilizadores.

De forma a facilitar a criacao de novos modulos que possam vir a ser desenvolvidos no futuro,

disponibilizamos um modulo de nome Skeletons, que contem um esqueleto generico de um modulo do

sistema.

Todos os modulos sao constituıdos por:

1. src/main/ Contem todo o codigo do modulo, dividido em:

(a) dml Especificacao do domınio para a FenixFramework

(b) java Codigo fonte Java

(c) resources Ficheiros de traducoes e configuracoes

(d) webapp Ficheiros JSP

2. pom.xml Usado para gerar dependencias (utilizando Maven)

Este documento ira especificar, a tıtulo de exemplo, como implementar um novo modulo capaz de

gerir uma lista de afazeres, que vamos denominar de Feng ToDo Module. Neste modulo, cada membro

tem uma lista de instances de ToDoItems, que contem uma descricao e uma flag a indicar se o item

ja foi completo. O membro pode adicionar, editar e apagar ToDoItems, assim como marca-los como

completo. Cada membro apenas tem acesso aos ToDoItems criados por ele.

A.1 Preparar um novo modulo

Para preparar a implementacao do novo modulo, e necessario:

1. Duplicar a pasta feng-skeletons-module e mudar o nome da pasta duplicada para o nome do

novo modulo (neste exemplo, feng-todo-module).

89

2. Alterar o ficheiro feng/pom.xml, adicionando <module>feng-todo-module</module> dentro da

etiqueta (tag) <modules>.

3. Alterar o ficheiro feng/feng-todo-module/pom.xml, de maneira a que:

(a) A etiqueta <artifactId> contenha o nome da pasta (neste exemplo, feng-todo-module).

(b) A etiqueta <name> contenha o nome do modulo (neste exemplo, Feng ToDo Module).

(c) Quaisquer dependencias adicionais estejam listadas dentro da etiqueta <dependencies>

(neste exemplo, nao sao necessarias quaisquer dependencias adicionais).

4. Alterar o ficheiro feng/feng-webapp/pom.xml, adicionando dentro da etiqueta <dependencies> a

seguinte dependencia:

<dependency><groupId>pt.ulisboa.tecnico.ipfn</groupId><artifactId>feng−todo−module</artifactId><version>${project.version}</version>

</dependency>

5. Alterar o nome da package Java pt.ulisboa.tecnico.ipfn.feng.skeletons para o nome do

novo modulo (neste exemplo pt.ulisboa.tecnico.ipfn.feng.todo). Esta alteracao deve incidir

sobre as sub-packages tambem. E aconselhavel utilizar um IDE (como, por exemplo, Eclipse)

para alterar o nome da package automaticamente em todos os ficheiros Java.

O modulo encontra-se entao configurado para ser utilizado no sistema.

A.2 Implementar o novo modulo

De forma a adicionar funcionalidade ao novo modulo, sera necessario seguir os seguintes passos:

1. Especificar o domınio do modulo no ficheiro DML.

2. Executar o comando mvn ff:ff-generate-domain para gerar os ficheiros Java do domınio.

3. Implementar as funcionalidades de domınio.

4. Implementar os servicos do modulo.

5. Implementar o controlador do modulo.

6. Implementar as vistas do modulo.

A.2.1 Domınio

O primeiro passo para a implementacao de um novo modulo e implementar o domınio. A implementacao

do domınio e dividida em duas partes: (i) definir o domınio e (ii) implementar a logica de negocio.

90

Definir o Domınio

Todos os dados que precisam de ser armazenados no sistema de forma persistente encontram-se

especificados num ficheiro DML localizado dentro da pasta feng/feng-todo-module/src/main/dml.

Ja se deve encontrar la o ficheiro skeletons.dml, que deve ser renomeado para o nome do modulo

(todo.dml).

A primeira linha do ficheiro todo.dml indica a package a utilizar pelas classes de domınio. Neste

caso, deve ser pt.ulisboa.tecnico.ipfn.feng.todo.domain.

O ficheiro todo.dml ja contem um exemplo de uma classe cujas instancias se pretende armazenar

de forma persistente, denominada Skeleton, que contem o atributo data do tipo String. Esta classe

deve ser alterada, e outras classes devem ser adicionadas, conforme os requisitos do novo modulo.

Neste caso, apenas e preciso uma classe ToDoItem, definida do seguinte modo:

class ToDoItem {String description;boolean complete;

}

Tambem e possıvel especificar relacoes entre diferentes classes. Este ficheiro contem um exemplo

de uma relacao entre classes, denominada BennuSkeletons, entre um Bennu1 e varios Skeletons (ex-

plicitado usando a keyword multiplicity). O Bennu e a raiz de todo o sistema, e, regra geral, todas as

instances devem estar relacionadas com Bennu para ser possıvel acede-las. Outras relacoes tambem

podem ser definidas de modo analogo.

Neste exemplo, sao necessarias duas relacoes: uma relacao entre ToDoItem e Bennu, para ser

possıvel aceder aos ToDoItems, e outra relacao entre ToDoItem e Member (disponıvel na package pt.

ulisboa.tecnico.ipfn.feng.members.domain), a indicar qual foi o membro que criou o ToDoItem.

Estas relacoes sao definidas do seguinte modo:

relation BennuToDoItems {ToDoItem playsRole toDoItem {

multiplicity ∗;}

.org.fenixedu.bennu.core.domain.Bennu playsRole bennu {multiplicity 1..1;

}}

relation MemberToDoItems {ToDoItem playsRole toDoItems {

multiplicity ∗;}

.pt.ulisboa.tecnico.ipfn.feng.members.domain.Member playsRole creator {multiplicity 1..1;

}}

1A classe Bennu e uma classe singleton. E garantida a existencia da unica instance de Bennu em qualquer momento. Devidoa esta propriedade, o Bennu e usado como raiz do sistema, pois permite aceder a todas as instances relacionadas com Bennu dequalquer parte do codigo, sem ser necessario usar um identificador de alguma das instances.

91

Finalizado o ficheiro DML, deve-se executar o comando mvn ff:ff-generate-domain. Este co-

mando vai gerar, com base no ficheiro todo.dml, as classes necessarias para a Fenix Framework gerir

a sua persistencia. Tambem vai gerar, para cada classe definida no ficheiro, um ficheiro Java na pac-

kage indicada no ficheiro todo.dml (neste caso pt.ulisboa.tecnico.ipfn.feng.todo.domain). De-

vera ter sido gerado o ficheiro feng/feng-todo-module/src/main/java/pt/ulisboa/tecnico/ipfn/

feng/todo/domain/ToDoItem.java, com o seguinte conteudo:

package pt.ulisboa.tecnico.ipfn.feng.todo.domain;

public class ToDoItem extends ToDoItem_Base {

public ToDoItem() {super();

}

}

Este vai ser o ficheiro onde vai ser implementada a logica de negocio.

Logica de Negocio

Usando as classes geradas anteriormente e possıvel definir as varias regras de negocio associadas a

cada objeto de domınio.

Neste exemplo, vamos implementar as seguintes regras de negocio:

1. Para ser criado, um ToDoItem precisa de uma descricao e de um Membro, que ficarao associados

ao ToDoItem.

2. Ao ser criado, o ToDoItem nao esta completo.

3. Ao ser criado, o ToDoItem e associado ao Bennu.

4. Depois de marcado como completo, o ToDoItem nao permite alterar mais o valor do atributo

complete.

5. Deve ser possıvel eliminar ToDoItems.

6. Ao ser eliminado, o ToDoItem e desassociado do Bennu e do Membro.

As regras de negocio associadas a criacao do ToDoItem sao implementadas em construtores. Neste

caso, e apenas necessario um construtor, implementado do seguinte modo:

public ToDoItem(String description, Member creator) {super();

super.setDescription(description);super.setComplete(false); // não está completosuper.setCreator(creator); // associar membro criadorsuper.setBennu(Bennu.getInstance()); // associar a Bennu

}

92

As regras de negocio associados a alteracao de atributos sao implementadas redefinindo os metodos

set. Neste caso, e preciso redefinir o metodo setComplete(boolean) para impedir alteracoes caso o

atributo complete esteja a true:

@Overridepublic void setComplete(boolean complete) {

if(!this.getComplete()) {super.setComplete(complete);

}}

Por omissao, nao e possıvel eliminar objetos de domınio. Caso deva ser possıvel, e necessario

implementar um novo metodo delete(). As regras de negocio associados a eliminacao de objetos de

domınio sao implementadas tambem neste metodo, do seguinte modo:

public void delete() {this.setCreator(null); // apagar associação com membrothis.setBennu(null); // apagar associação com Bennusuper.deleteDomainObject(); // eliminar objeto

}

E importante, sempre que se elimina um objeto, que todas as relacoes com outros objetos sejam

apagadas.

Caso seja necessario lancar uma excecao, existe uma classe SkeletonException dentro de pt.

ulisboa.tecnico.ipfn.feng.todo.domain.exception. Esta classe deve ser renomeada conforme

o nome do novo modulo (neste caso, ToDoException), e deve ser estendida por todas as excecoes

lancadas na camada de domınio.

A.2.2 Servicos

Apos o domınio implementado, avanca-se para a camada de servicos. Esta camada ira conter classes

que oferecem metodos para realizar as acoes possıveis (no caso do ToDo, listar, adicionar, editar,

eliminar e marcar como completo). E importante notar que camadas superiores nao devem alterar os

valores dos atributos diretamente nos objetos de domınio, pois essa e a responsabilidade da camada

de servicos. Em vez disso, as camadas superiores tem acesso a objetos bean, que sao objetos simples

Java que representam objetos de domınio.

Primeiro, e preciso criar estes objetos Bean, depois implementar as classes necessarias para per-

mitir pesquisa e, no fim, implementar as classes de servicos.

A.2.3 Beans

Na package pt.ulisboa.tecnico.ipfn.feng.todo.bean encontram-se duas classes: SkeletonBean e

SkeletonSearchParametersBean. Deve existir sempre uma classe bean por cada classe de domınio, e

uma classe search parameters bean por cada tipo de objeto sobre o qual seja possıvel, ao utilizador,

efetuar pesquisas. Neste exemplo, temos uma classe de domınio ToDoItem, e deve ser possıvel realizar

93

pesquisas na listagem de ToDoItem, logo sera necessario renomear as classes bean ja presentes para

ToDoItemBean e ToDoItemSearchParametersBean.

A classe ToDoItemBean deve conter os mesmos atributos que a classe ToDoItem. Por conveniencia,

deve haver um construtor que recebe um ToDoItem e copia todos os seus valores para o ToDoItemBean.

Deve tambem existir um construtor vazio. Um metodo isNew() deve tambem existir para distinguir um

bean que foi criado com base num objeto de domınio existente de um criado de raiz que servira para

gerar um novo objeto de domınio.

private String id;private String description;private boolean complete;private Member creator;

public ToDoItemBean() {}

public ToDoItemBean(ToDoItem toDoItem) {this.id = toDoItem.getExternalId();this.setDescription(toDoItem.getDescription());this.setComplete(toDoItem.getComplete());this.setCreator(toDoItem.getCreator());

}

public boolean isNew() {return (this.id == null || this.id.isEmpty());

}

A classe ToDoTemBean deve tambem ter getters e setters para cada um dos atributos:

public String getId() { return id; }public void setId(String id) {

this.id = Sanitizer.toSafeHtml(id);}

public String getDescription() { return data; }public void setDescription(String description) {

this.description = Sanitizer.toSafeHtml(description);}

public String isComplete() { return complete; }public void setComplete(boolean complete) { this.complete = complete; }

public String getCreator() { return creator; }public void setCreator(Member creator) { this.creator = creator; }

E preciso, para os setters de atributos do tipo String, chamar o metodo Sanitizer.toSafeHtml(String),

pois os atributos de beans irao conter dados introduzidos pelo utilizador. Por questoes de seguranca, e

para garantir que estes dados nao provocam efeitos indesejados devido ao uso de etiquetas HTML, os

dados introduzidos pelo utilizador devem ser filtrados por esse metodo.

A classe ToDoItemSearchParametersBean deve ter, como atributos, todos os campos que o utili-

zador possa usar para realizar uma pesquisa sobre ToDoItems (neste caso, id e description). Deve

tambem herdar de SearchParametersBean, que ja contem outros atributos necessarios para a pesquisa:

sort (qual o tipo de ordenacao a usar), order (se a ordenacao deve ser ascendente ou descendente)

94

e page (qual a pagina a mostrar numa listagem paginada). E necessario atribuir um valor por omissao

a todos os atributos desta classe.

private String id;private String description;

public ToDoItemSearchParametersBean() {super();this.setId("");this.setDescription("");this.setSort(ToDoItemConstants.SORT_ID);this.setOrder(ToDoItemConstants.ORDER_ASC);

}

Tal como em ToDoItemBean, e necessario criar getters e setters. Nos setters, ao ser dado um

valor null ou invalido, deve ser substituıdo pelo valor por defeito. Tambem se deve chamar o metodo

Sanitizer.toSafeHtml(String) pelas mesmas razoes que em ToDoItemBean.

public String getId() { return id; }public void setId(String id) {

this.id = (id == null ? "" : Sanitizer.toSafeHtml(id));}

public String getDescription() { return description; }public void setDescription(String description) {

this.description =(description == null ? "" : Sanitizer.toSafeHtml(description));

}

@Overridepublic void setSort(String sort) {

if (!ToDoConstants.SORT_ID.equalsIgnoreCase(sort) &&!ToDoConstants.SORT_DESCRIPTION.equalsIgnoreCase(sort)) {sort = ToDoConstants.SORT_ID;

}

super.setSort(Sanitizer.toSafeHtml(sort).toLowerCase());}

Tambem e preciso um metodo que indique quando e que existe alguma pesquisa a ser realizada,

denominado hasSearch(), e um metodo toString() usado para fazer log das pesquisas realizadas

pelos membros:

@Overridepublic boolean hasSearch() {

return !(id.isEmpty() && description.isEmpty());}@Overridepublic String toString() {

return "?id=" + id + "&description=" + description + "&sort="+ getSort() + "&order=" + getOrder() + "&page=" + getPage();

}

Neste bean tem sido utilizado uma classe ToDoConstants. Esta classe devera existir em pt.

ulisboa.tecnico.ipfn.feng.todo.util, a substituir a classe SkeletonsConstants ja existente. Nesta

classe sao definidos todas as constantes usadas pelo modulo, como por exemplo os valores possıveis

para o atributo sort nas pesquisas.

95

A.2.4 Pesquisa

Para permitir pesquisar sobre objetos de domınio, o sistema deve ser capaz de filtrar e ordenar os obje-

tos. Filtrar os objetos e conseguido atraves do uso de classes Filter e AcceptableFactory, enquanto

que ordenacao e conseguida atraves do uso de Comparators e ComparatorFactories.

As classes Filter sao classes que, dado um objeto de domınio, o aceitam ou recusam conforme

os seus parametros. Para este exemplo, os membros devem poder pesquisar pelo identificador ou

pela descricao do ToDoItem, logo devem ser criadas as classes FilterById e FilterByDescription.

Adicionalmente, cada membro apenas deve ter acesso aos ToDoItems criados por ele, logo e tambem

necessaria a classe FilterByCreator. Estes tres filtros devem estar na package pt.ulisboa.tecnico.

ipfn.feng.todo.search.filter.

As classes FilterById e FilterByDescription sao ambos filtros que filtram com base em atributos

String, logo devem herdar da classe FilterByStringAttribute<ToDoItem>. Esta classe ja implementa

o metodo accept(ToDoItem), faltando apenas implementar o metodo getAttribute(ToDoItem), onde

deve ser devolvido o valor do atributo que queremos usar para realizar a pesquisa.

public class FilterById extends FilterByStringAttribute<ToDoItem> {

public FilterById(String token) { super(token); }

@Overrideprotected String getAttribute(ToDoItem obj) {

return obj.getExternalId();}

}

A classe FilterByDescription e implementada de modo analogo.

Existem as seguintes classes abstratas Filter que podem ser usadas para definir filtros:

• FilterByAtribute<T, E> que, dado um objeto de domınio T, verifica se o atributo do tipo E e

igual a outro objeto do tipo E passado como token, chamando o metodo equals(E)

• FilterByStringAttribute<T> que, dado um objeto de domınio T, verifica se o atributo do tipo

String contem o valor do token passado.

• FilterByLocalizedStringAttribute<T> que e parecida a classe FilterByStringAttribute<T>,

mas usa LocalizedStrings em vez de Strings.

• FilterBySetAttributeContainingElement<T, E> que, dado um objeto de domınio T, verifica se

o atributo do tipo Set<E> contem outro objeto do tipo E passado como token, chamando o metodo

contains(E)

• FilterNone<T> que aceita todos os objetos de domınio T

• FilterAll<T> que recusa todos os objetos de domınio T

Todas estas classes implementam a interface Acceptable<T>. Novos filtros podem ser desenvolvi-

dos implementando a interface Acceptable<T> (possıvelmente estendendo das classes listadas acima).

96

Para a classe FilterByCreator<ToDoItem>, herdar de FilterByAttribute<ToDoItem, Member> e

o mais indicado.

public class FilterByCreator extends FilterByAttribute<ToDoItem, Member> {

public FilterByCreator(Member token) { super(token); }@Overrideprotected Member getAttribute(ToDoItem obj) {

return obj.getCreator();}

}

Com as classes Fiter e a classe SearchParametersBean, e possıvel implementar as classes AcceptableFactory.

Estas classes tem como objetivo criar, com base nos valores no SearchParametersBean, um Filter

capaz de filtrar os objetos pedidos pelo membro. Devem herdar de AbstractAcceptableFactory<P

extends SearchParametersBean, T>, que oferece os seguintes metodos para facilitar na criacao de

Filters complexos:

• and(Acceptabe<T>, Acceptabe<T>) que devolve um Filter resultante de realizar um AND logico

ao resultado dos dois Filters passados como argumentos

• or(Acceptabe<T>, Acceptabe<T>) que devolve um Filter resultante de realizar um OR logico

ao resultado dos dois Filters passados como argumentos

• not(Acceptabe<T>) que devolve um Filter resultante de realizar um NOT logico ao resultado ao

Filter passado como argumento

No nosso exemplo, e preciso um AcceptableFactory que cria um Filter que indica os ToDoItems

que se adequam a pesquisa do utilizador, excluindo todos os ToDoItems criados por outros membros.

@Componentpublic class ToDoItemAcceptableFactory

extends AbstractAcceptableFactory<ToDoItemSearchParametersBean, ToDoItem> {

@Overridepublic Acceptable<ToDoItem>

buildAcceptable(ToDoItemSearchParametersBean parameters)throws BadSearchParametersException {

// este é o membro que está autenticadoMember member = Authenticate.getUser().getMember();if (!parameters.hasSearch()) {

return new FilterByCreator(member);}

Acceptable<ToDoItem> completeAcceptable = new FilterByCreator(member);

if (!parameters.getId().isEmpty()) {final FilterById filterById = new FilterById(parameters.getId());completeAcceptable = and(filterById, completeAcceptable);

}

if (!parameters.getDescription().isEmpty()) {final FilterByDescription filterByDesc =

new FilterByDescription(parameters.getDescription());completeAcceptable = and(filterByDesc, completeAcceptable);

97

}

return completeAcceptable;}

}

A anotacao @Component e necessaria para, mais adiante, ser possıvel usar a anotacao @Autowired2.

Como indicado anteriormente, para a ordenacao sao usados Comparators e ComparatorFactories.

Neste exemplo, os membros devem ter a hipotese de ordenar pelo identificador ou pela descricao, logo e

necessario implementar dois Comparators: ToDoItemIdComparator e ToDoItemDescriptionComparator.

Os Comparators sao implementados como habitualmente em Java:

public static class ToDoItemIdComparator implements Comparator<ToDoItem> {int order;

public ToDoItemIdComparator(boolean desc) {this.order = desc ? −1 : 1;

}

@Overridepublic int compare(ToDoItem o1, ToDoItem o2) {

final int comparation = o1.getExternalId().compareTo(o2.getExternalId());return order ∗ comparation;

}}

O atributo order permite ao Comparator inverter a ordem caso seja necessaria a ordem descendente.

A classe ToDoItemDescriptionComparator e implementada de modo analogo.

Semelhante ao AcceptableFactory, ComparatorFactories devem devolver um Comparator com

base nos valores do SearchParametersBean. Devem herdar de AbstractComparatorFactory<P extends

SearchParametersBean, T> e implementar o metodo abstrato Comparator<T> buildComparator(P)

throws BadSearchParametersException.

@Componentpublic class ToDoItemComparatorFactory

extends AbstractComparatorFactory<ToDoItemSearchParametersBean, ToDoItem> {

@Overridepublic Comparator<ToDoItem>

buildComparator(ToDoItemSearchParametersBean parameters) {

Comparator<ToDoItem> comparator = null;final boolean desc = parameters.getOrder().equals(ToDoConstants.ORDER_DESC);switch (parameters.getSort()) {

case ToDoConstants.SORT_ID:comparator = new ToDoItemIdComparator(desc);break;

case ToDoConstants.SORT_DESCRIPTION:comparator = new ToDoItemDescriptionComparator(desc);break;

default:parameters.setSort(ToDoConstants.SORT_ID);parameters.setOrder(ToDoConstants.ORDER_ASC);comparator = new ToDoItemIdComparator(false);

2http://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/beans/factory/

annotation/Autowired.html

98

}return comparator;

}}

Com os elementos necessarios para a pesquisa, o ultimo passo e implementar uma classe que

utilizara o algoritmo de pesquisa para devolver uma lista ordenada de objetos de domınio.

public class SearchToDoItems {private final static SearchDomainObjects<ToDoItem> instance =

new SearchDomainObjects<ToDoItem>();

public static List<ToDoItem>search(Acceptable<ToDoItem> filter, Comparator<ToDoItem> comparator) {

final Set<ToDoItem> items = Bennu.getInstance().getToDoItemSet();return instance.search(items, filter, comparator);

}}

A.2.5 Implementar Servicos

Terminadas a implementacao dos beans e da pesquisa, pode-se avancar para a implementacao dos

servicos. Neste exemplo, irao ser implementadas duas classes de servicos: SearchToDoItemsService

e ToDoItemService. Ambas estarao na package pt.ulisboa.tecnico.ipfn.feng.todo.service. A

primeira oferecera tres metodos: (i) um para listar todos os ToDoItems, (ii) um para devolver um

ToDoItem com base no seu identificador, e (iii) um para realizar uma pesquisa. Sera baseada na classe

SearchSkeletonsService, que devera ser renomeada para SearchToDoItemsService.

@Servicepublic class SearchToDoItemsService {

private final static Logger LOGGER =LoggerFactory.getLogger(SearchToDoItemsService.class);

A anotacao @Service e semelhante a anotacao @Component, no sentido em que tambem permite, mais

adiante, a utilizacao da anotacao @Autowired. Todas as classes de servico devem ser anotadas com

esta anotacao. A constante LOGGER permite fazer logs das acoes tomadas. Todos os metodos das

classes de servicos devem registar no log qual o membro que realizou o pedido e uma mensagem

descritiva do sucedido.

public List<ToDoItem> getAllToDoItems(Comparator<ToDoItem> comparator)throws ToDoItemServiceException {

final Acceptable<ToDoItem> searchAll = new FilterNone<ToDoItem>();

if (Authenticate.isLogged()) {final User whoDidThis = Authenticate.getUser();LOGGER.info("[TODO] User " + whoDidThis.getDisplayName()

+ " (" + whoDidThis.getUsername()+ ") searched for all ToDoItems");

}return SearchToDoItems.search(searchAll, comparator);

}

99

public ToDoItem getToDoItem(String id) throws ToDoItemServiceException {final ToDoItem toDoItem = FenixFramework.getDomainObject(id);

if (ToDoItem == null) {throw new ToDoItemNotFoundException(id);

}

if (Authenticate.isLogged()) {final User whoDidThis = Authenticate.getUser();

LOGGER.info("[TODO] User " + whoDidThis.getDisplayName()+ " (" + whoDidThis.getUsername()+ ") searched for ToDoItem with id ’" + id + "’");

}

return toDoItem;}

public List<ToDoItem> searchToDoItems(ToDoItemSearchParametersBean parameters,AbstractAcceptableFactory<ToDoItemSearchParametersBean, ToDoItem> acceptableFactory,AbstractComparatorFactory<ToDoItemSearchParametersBean, ToDoItem> comparatorFactory)throws BadSearchParametersException {

final Acceptable<ToDoItem> acceptable =acceptableFactory.buildAcceptable(parameters);

final Comparator<ToDoItem> comparator =comparatorFactory.buildComparator(parameters);

if (Authenticate.isLogged()) {final User whoDidThis = Authenticate.getUser();LOGGER.info("[TODO] User " + whoDidThis.getDisplayName()

+ " (" + whoDidThis.getUsername()+ ") searched for ToDoItems with the following parameters: ’"+ parameters.toString() + "’");

}return SearchToDoItems.search(acceptable, comparator);

}

A segunda classe de servicos vai ser baseada na classe SkeletonService, que deve ser reno-

meada para ToDoItemService. Nesta classe, vao ser implementados cinco metodos, corresponden-

tes as acoes que membros podem realizar em relacao a ToDoItems: addToDoItem, editToDoItem,

deleteToDoItem e setToDoItemAsComplete. Estes metodos, visto que alteram valores em objetos do

domınio, tem de estar obrigatoriamente anotados com @Atomic. Esta anotacao garante que o metodo

e executado dentro de uma transacao. No caso em que e realizada alguma alteracao a um objeto de

domınio fora de uma transacao, e lancada uma excecao e a alteracao nao e efetuada.

@Atomicpublic ToDoItem addToDoItem(ToDoItemBean toDoItemBean)

throws ToDoItemServiceException {

final String data = toDoItemBean.getData();

final ToDoItem toDoItem = new ToDoItem(data);

final User whoDidThis = Authenticate.getUser();LOGGER.info("[TODO] User " + whoDidThis.getDisplayName()

+ " (" + whoDidThis.getUsername()+ ") added a ToDoItem with id + ’"

100

+ toDoItem.getExternalId() + "’");return toDoItem;

}

@Atomicpublic ToDoItem editToDoItem(ToDoItemBean toDoItemBean)

throws ToDoItemServiceException {

final ToDoItem toDoItem = FenixFramework.getDomainObject(toDoItemBean.getId());

if (toDoItem == null) {throw new ToDoItemNotFoundException(toDoItemBean.getId());

}

try {toDoItem.setDescription(toDoItemBean.getData());

} catch (final ToDoException e) {throw new IllegalOperationException("edit");

}

final User whoDidThis = Authenticate.getUser();LOGGER.info("[TODO] User " + whoDidThis.getDisplayName()

+ " (" + whoDidThis.getUsername()+ ") set the ToDoItem with id ’" + toDoItem.getExternalId()+ "’ data with ’" + toDoItemBean.getData() + "’");

return toDoItem;}

@Atomicpublic ToDoItem deleteToDoItem(ToDoItemBean toDoItemBean)

throws ToDoItemServiceException {

final ToDoItem toDoItem = FenixFramework.getDomainObject(toDoItemBean.getId());

if (toDoItem == null) {throw new ToDoItemNotFoundException(toDoItemBean.getId());

}

try {toDoItem.delete();

} catch (final ToDoException e) {throw new IllegalOperationException("delete");

}

final User whoDidThis = Authenticate.getUser();LOGGER.info("[TODO] User " + whoDidThis.getDisplayName()

+ " (" + whoDidThis.getUsername()+ ") deleted the ToDoItem with id ’"+ toDoItem.getExternalId() + "’");

return toDoItem;}

@Atomicpublic ToDoItem setToDoItemAsComplete(ToDoItemBean toDoItemBean)

throws ToDoItemServiceException {

final ToDoItem toDoItem = FenixFramework.getDomainObject(toDoItemBean.getId());

if (toDoItem == null) {throw new ToDoItemNotFoundException(toDoItemBean.getId());

}

try {

101

toDoItem.setComplete(true);} catch (final ToDoException e) {

throw new IllegalOperationException("setAsComplete");}

final User whoDidThis = Authenticate.getUser();LOGGER.info("[TODO] User " + whoDidThis.getDisplayName()

+ " (" + whoDidThis.getUsername()+ ") set as complete the ToDoItem with id ’"+ toDoItem.getExternalId() + "’");

return toDoItem;}

De notar que na package pt.ulisboa.tecnico.ipfn.feng.todo.service.exception se encon-

tram varias classes que implementam excecoes de servico. Todas as excecoes de domınio devem ser

apanhadas nos servicos, devendo de seguida ser lancadas excecoes de servico. Em particular, as clas-

ses SkeletonServiceException e SkeletonNotFoundException devem ser renomeadas consoante o

modulo (neste caso, para ToDoServiceException e ToDoItemNotFoundException, respetivamente). To-

das as excecoes de servico devem herdar de ToDoServiceException (ou equivalente para o modulo).

A.2.6 Controladores

Antes da implementacao de controladores, e necessario implementar as classes Validators. Estas

classes sao classes que, dado um bean, validam se os valores sao corretos antes de estes serem

usados nos servicos. As classes Validator encontram-se na package pt.ulisboa.tecnico.ipfn.

feng.todo.util. Para este exemplo, ira ser implementada a classe ToDoItemValidator, baseada na

classe SkeletonValidator. Este Validator deve validar o valor do id para garantir que se refere a um

ToDoItem existente, e deve garantir que o valor de description nao esta vazio.

@Componentpublic class ToDoItemValidator implements Validator {

private final DomainObjectExistsValidator domainObjectExistsValidator =new DomainObjectExistsValidator(ToDoItem.class);

private final StringValidator stringValidator =new StringValidator();

@Overridepublic boolean supports(Class<?> clazz) {

return ToDoItemBean.class.isAssignableFrom(clazz);}

@Overridepublic void validate(Object target, Errors errors) {

final ToDoItemBean bean = (ToDoItemBean) target;

// validar se o id é válidoif (!bean.isNew()) {

ValidationUtils.invokeValidator(domainObjectExistsValidator,bean.getId(), errors);

}// validar se a description não é null ou string vaziaValidationUtils.invokeValidator(stringValidator,

bean.getDescription(), errors);}

102

}

Para a implementacao de Validators, as seguintes classes podem ser usadas:

• CollectionIsNotEmptyValidator que, dado uma Collection, verifica se esta a null ou vazia.

Apenas permite Collections com pelo menos um elemento.

• DateValidator que, dado uma String, verifica se representa uma data no formato dd/mm/yyyy.

Apenas permite Strings com esse formato.

• DomainObjectExistsValidator que, dado uma String, verifica se existe um objeto de domınio

com essa String como identificador. Adicionalmente, verifica se o objeto de domınio e instancia

da classe usada como argumento no construtor.

• ImageValidator que, dado um MultipartFile, este e uma imagem valida. Usado principalmente

no upload de imagens.

• LocalizedStringValidator que, dado uma LocalizedString, verifica se tem traducoes para

todos os idiomas. Apenas permite LocalizedStrings que tenham uma traducao para todos os

idiomas do sistema.

• StringValidator que, dado uma String, verifica se e null ou vazia. Apenas permite Strings que

nao sejam vazias.

Os controladores devem ser especificados na pasta feng/feng-todo-module/src/main/java/pt/

ulisboa/tecnico/ipfn/feng/todo/ui. Esta pasta ja contem um controlador SkeletonsController.

Continuando com o desenvolvimento do modulo ToDo, o nome deste controlador deve ser alterado para

ToDoController.

Esta classe contem 3 anotacoes, cujo conteudo deve ser alterado para representar o modulo ToDo:

@RequestMapping("/todo")@SpringApplication(group = "#" + ToDoConstants.MEMBER_GROUP_NAME,

path = "todo", title = "todo.title")@SpringFunctionality(app = TodoController.class, title = "todo.title")public class TodoController {

Dentro da classe existem varios atributos anotados com @Autowired que tambem terao que sofrer

alteracoes:

@Autowiredprivate ToDoService service;@Autowiredprivate SearchToDosService searchService;

@Autowiredprivate ToDoAcceptableFactory acceptableFactory;@Autowiredprivate ToDoComparatorFactory comparatorFactory;

@Autowiredprivate ToDoItemValidator toDoValidator;

103

Sendo @Autowired, estes atributos sao automaticamente atribuıdos com instancias de classes ano-

tadas com @Component e @Service.

De seguida encontram-se os metodos responsaveis por receber os pedidos HTTP dos clientes. O

primeiro metodo, denominado list, sera responsavel por mostrar uma lista paginada de ToDoItems,

com os criterios de pesquisa definidos anteriormente:

@RequestMapping(method = RequestMethod.GET)public String list(@Valid ToDoSearchParametersBean searchParametersBean,

BindingResult result,Model model,HttpServletRequest request) {

if (result.hasErrors()) {for (final ObjectError error : result.getAllErrors()) {

System.out.println("error: " + error);}Alert.danger(request, formatAlert("todo.search.failure"));return "redirect:/todo";

}

final List<ToDoItem> toDos;

try {todos = searchService.searchToDoItems(searchParametersBean,

acceptableFactory, comparatorFactory);} catch (final BadSearchParametersException e) {

Alert.danger(request, formatAlert("todo.search.failure"));return "redirect:/todo";

}

PagedListHolder<ToDoItem> toDosPages =new PagedListHolder<ToDoItem>(toDos);

toDosPages.setPage(searchParametersBean.getPage());toDosPages.setPageSize(ToDoConstants.DEFAULT_ITEMS_PER_PAGE);

model.addAttribute("todos", toDosPages);model.addAttribute("searchParameters", searchParametersBean);

return "todo/list";}

O metodo seguinte, denominado add, sera responsavel por mostrar um formulario ao utilizador que

lhe permitira fazer um pedido de adicao de ToDoItems ao sistema:

@RequestMapping(value = "add", method = RequestMethod.GET)public String add(Model model) {

final ToDoItemBean toDoBean = new ToDoItemBean();

model.addAttribute("toDoBean", toDoBean);return "todo/add";

}

O terceiro metodo, denominado edit, sera responsavel por mostrar um formulario ao utilizador que

lhe permitira fazer um pedido de edicao de ToDoItems ao sistema:

@RequestMapping(value = "edit/{id}", method = RequestMethod.GET)public String edit(@PathVariable String id,

Model model, HttpServletRequest request) {

104

ToDoItem toDo;try {

toDo = searchService.getToDoItem(id);} catch (final ToDoServiceException e) {

throw new WebApplicationException(404);}

final ToDoItemBean toDoBean = new ToDoItemBean(toDo);

model.addAttribute("toDoBean", toDoBean);return "todo/edit";

}

O quarto metodo, denominado save, sera responsavel por receber os pedidos de adicao/edicao de

ToDoItems e efetuar as devidas alteracoes no sistema. Este metodo invoca um outro metodo tambem

denominado save, que sera especificado mais a frente:

@RequestMapping(value = "save", method = RequestMethod.POST)public String save(@Valid ToDoItemBean toDoBean,

BindingResult result, Model model, HttpServletRequest request) {

try {final ToDoItem toDo = save(toDoBean, request, result);

} catch (final ToDoServiceException e) {throw new WebApplicationException(404);

}

return "redirect:/todo";}

O quinto metodo publico, denominado delete, sera responsavel por receber os pedidos de remocao

de ToDoItems e efetuar as devidas alteracoes no sistema:

@RequestMapping(value = "delete", method = RequestMethod.POST)public String delete(@Valid ToDoItemBean toDoBean,

Model model, HttpServletRequest request) {

try {service.deleteToDo(toDoBean);Alert.success(request, formatAlert("todo.delete.success"));

} catch (final ToDoServiceException e) {throw new WebApplicationException(404);

}

return "redirect:/todo";}

O sexto e ultimo metodo publico, denominado setAsComplete, sera responsavel por receber os

pedidos para marcar um ToDoItem como completo e efetuar as devidas alteracoes no sistema:

@RequestMapping(value = "delete", method = RequestMethod.POST)public String setAsComplete(@Valid ToDoItemBean toDoBean,

Model model, HttpServletRequest request) {

try {service.deleteToDo(toDoBean);Alert.success(request, formatAlert("todo.delete.success"));

} catch (final ToDoServiceException e) {

105

throw new WebApplicationException(404);}

return "redirect:/todo";}

O metodo privado denominado save, sera responsavel por definir toda a logica necessaria para a

adicao/edicao, de ToDoItems do sistema:

private ToDo save(ToDoItemBean toDoBean,HttpServletRequest request, BindingResult result) throws SkeletonServiceException {

ValidationUtils.invokeValidator(toDoValidator, toDoBean, result);

if (result.hasErrors()) {if (toDoBean.isNew()) {

Alert.danger(request, formatAlert("todo.add.failure"));} else {

Alert.danger(request, formatAlert("todo.edit.failure"));}return null;

}

if (toDoBean.isNew()) {final ToDoItem toDo = service.addToDo(toDoBean);toDoBean.setId(toDo.getExternalId());Alert.success(request, formatAlert("todo.add.success"));return toDo;

} else {final ToDo toDo = service.editToDo(toDoBean);Alert.success(request, formatAlert("todo.edit.success"));

}

return null;}

O ultimo metodo da classe, denominado formatAlert, serve de acucar sintatico para a criacao de

alertas. Estes alertas sao mostrados na pagina na forma de um popup no canto superior direito.

private String formatAlert(String alertKey) {return " " + BundleUtil.getString("resources.ToDoAlertsResources", alertKey);

}

Estes alertas devem ser traduzidos para ingles e portugues. Os ficheiros de traducao dos aler-

tas encontra-se em feng/feng-todo-module/src/main/resources/resources. Dois ficheiros ja exis-

tem, SkeletonsAlertsResources en.properties e SkeletonsAlertsResources pt.properties, para

as traducoes em ingles e em portugues, respetivamente. Estes ficheiros devem ser renomeados para

ToDoAlertsResources en.properties e ToDoAlertsResources pt.properties, respetivamente.

O ficheiro ToDoAlertsResources en.properties deve conter:

todo.add.success = The item was created successfully!todo.add.failure = An error occurred while trying to create the item.

todo.edit.success = The item was edited successfully!todo.edit.failure = An error occurred while trying to edit the item.

todo.delete.success = The item was deleted successfully!

106

todo.delete.failure = An error occurred while trying to delete the item.

todo.set_as_complete.success = The item was set as complete successfully!todo.set_as_complete.failure = An error occurred while trying to set the item.

todo.search.failure = An error occurred while processing the search parameters.

O ficheiro ToDoAlertsResources pt.properties deve conter:

todo.add.success = O item foi criado com sucesso!todo.add.failure = Ocorreu um erro ao tentar criar o item.

todo.edit.success = O item foi editado com sucesso!todo.edit.failure = Ocorreu um erro ao tentar editar o item.

todo.delete.success = O item foi eliminado com sucesso!todo.delete.failure = Ocorreu um erro ao tentar eliminar o item.

todo.set_as_complete.success = O item foi marcado como completo com sucesso!todo.set_as_complete.failure = Ocorreu um erro ao tentar marcar o item.

todo.search.failure = Ocorreu um erro ao processar os parametros de procura.

A.2.7 Vistas

Na pasta feng/feng-todo-module/src/main/webapp/WEB-INF encontram-se os ficheiros necessarios

para a criacao das vistas que serao enviadas como resposta aos pedidos feitos a este novo modulo.

A pasta resources contem as traducoes para as diferentes lınguas que o sistema se encontra con-

figurado. Dentro desta pasta podemos entao encontrar dois ficheiros:

1. SkeletonsResources en.properties, cujo nome devera ser alterado para ToDoResources en.properties.

Este ficheiro contem todas as traducoes de texto presentes nas vistas para ingles.

2. SkeletonsResources pt.properties, cujo nome devera ser alterado para ToDoResources pt.properties.

Este ficheiro contem todas as traducoes de texto presentes nas vistas para portugues.

O conteudo do ficheiro ToDoResources en.properties devera ser alterado para o seguinte:

todo.title = To Do

todo.set_as_complete = Set as Complete

todo.add.description = Add Item to To Do listtodo.edit.description = Edit To Do list itemtodo.delete.description = Delete To Do list itemtodo.set_as_complete.description = Set To Do list item as Complete

todo.delete.are_you_sure = You are about to delete an item. Are you sure?

label.id = IDlabel.description = Description

label.description.prompt = Enter the description

O conteudo do ficheiro ToDoResources pt.properties devera ser alterado para o seguinte:

107

todo.title = To Do

todo.set_as_complete = Marcar como Completo

todo.add.description = Adicionar item à lista de To Dotodo.edit.description = Editar item da lista de To Dotodo.delete.description = Eliminar item da lista de To Dotodo.set_as_complete.description = Marcar item da lista de To Do como Completo

todo.delete.are_you_sure = Está prestes a eliminar um item. Tem a certeza?

label.id = IDlabel.description = Descrição

label.description.prompt = Introduza a descrição

Com isto as traducoes deverao estar terminadas. Voltando a pasta feng/feng-todo-module/src/

main/webapp/WEB-INF, podemos verificar que existe tambem uma pasta denominada Skeletons. Esta

pasta devera ser renomeada para ToDo. Dentro desta pasta agora denominada ToDo, existem tres

ficheiros:

1. add.jsp, que contem o formulario de adicao de um ToDo para ser apresentado ao utilizador.

2. edit.jsp, que contem o formulario de edicao de um ToDo para ser apresentado ao utilizador.

3. list.jsp, que contem a listagem de ToDos para ser apresentado ao utilizador.

Em todos estes ficheiros sera necessario converter todas as spring:message para corresponder

aos ficheiros de traducao que definimos anterior.

A tıttulo de exemplo, a spring:message:

<spring:message code="skeletons.title"></spring:message>

passara para:

<spring:message code="todo.title"></spring:message>

No ficheiro add.jsp sera necessario alterar os url’s que se encontram especificados no inıcio do

ficheiro:

<spring:url var="listUrl" value="/todo"></spring:url><spring:url var="saveUrl" value="/todo/save"></spring:url>

Assim como alterar o formulario:

<!−− BEGIN FORM−−><form id="todo−form" method="POST" action="${saveUrl}" class="form−horizontal"><input name="id" type="hidden" id="todo−id" />${csrf.field()}<div class="form−body"><div class="form−group"><label class="control−label col−md−3" for="description"><strong><spring:message code="label.description"/>

</strong>

108

</label><div class="col−md−6 place−error">

<inputtype="text"id="description"name="description"class="form−control"placeholder="<spring:message code=’label.description.prompt’/>"

></div>

</div></div><div class="form−actions right"><button type="submit" class="btn btn−success"><i class="fa fa−save"></i> <spring:message code="save"></spring:message>

</button></div>

</form><!−− END FORM−−>

Na parte final do ficheiro add.jsp encontra-se um script responsavel por efectuar uma validacao do

formulario antes que este seja enviado ao servidor. Esta validacao utiliza o plugin jquery-validation3.

No ficheiro edit.jsp sera necessario alterar os url’s que se encontram especificados no inıcio do

ficheiro:

<spring:url var="listUrl" value="/todo"></spring:url><spring:url var="saveUrl" value="/todo/save"></spring:url>

Assim como alterar o formulario:

<!−− BEGIN FORM−−><form id="todo−form" method="POST" action="${saveUrl}" class="form−horizontal"><input name="id" type="hidden" id="todo−id" value="${toDoBean.id}" />${csrf.field()}<div class="form−body"><div class="form−group"><label class="control−label col−md−3" for="description"><strong><spring:message code="label.description"/>

</strong></label><div class="col−md−6 place−error"><inputtype="text"id="description"name="description"class="form−control"placeholder="<spring:message code=’label.description.prompt’/>"value="${skeletonBean.description}"

></div>

</div></div><div class="form−actions right"><button type="submit" class="btn btn−success"><i class="fa fa−save"></i> <spring:message code="save"/>

</button></div>

</form>

3https://jqueryvalidation.org/

109

<!−− END FORM−−>

No ficheiro list.jsp sera necessario alterar os url’s que se encontram especificados no inıcio do

ficheiro:

<spring:url var="listUrl" value="/todo"></spring:url><spring:url var="addUrl" value="/todo/add"></spring:url><spring:url var="editUrl" value="/todo/edit"></spring:url><spring:url var="deleteUrl" value="/todo/delete"></spring:url><spring:url var="setAsCompleteUrl" value="/todo/setAsComplete"></spring:url>

Assim como alterar o formulario de pesquisa. Para isso, sera necessario alterar o if que se encontra

antes do inıcio do formulario para:

<c:if test="${toDos.nrOfElements != 0 || searchParameters.hasSearch()}">

De seguida sera necessario alterar o choose que se encontra dentro do button com o id search-type-button:

<c:choose><c:when test="${!searchParameters.id.isEmpty()}">

<spring:message code="label.id"></spring:message></c:when><c:when test="${!searchParameters.description.isEmpty()}">

<spring:message code="label.description"></spring:message></c:when><c:otherwise>

<spring:message code="label.id"></spring:message></c:otherwise>

</c:choose>

Sera tambem necessario alterar o ul que se encontra a seguir ao button com o id search-type-button:

<ul class="dropdown−menu"><li>

<a class="search−type" data−type="id"><spring:message code="label.id"/>

</a></li><li>

<a class="search−type" data−type="description"><spring:message code="label.description"/>

</a></li>

</ul>

E alterar o input com o id search-data para:

<inputid="search−description"name="description"type="text"class="search−field form−control${searchParameters.description.isEmpty() ? ’hidden’ : ’’}"

placeholder="<spring:message code=’search.term.prompt’/>"value=’${searchParameters.description}’

></input>

110

Com estas alteracoes, o componente de pesquisa desta vista devera estar terminado. Para corrigir

a tabela que mostrara a listagem de ToDoItems e necessario alterar o primeiro when do choose que se

encontra dentro da div com a classe table-responsive:

<c:when test="${toDos.nrOfElements == 0}"><div class="alert alert−danger">

<spring:message code="search.no_results"></spring:message></div>

</c:when>

Dentro da table , sera necessario corrigir o segundo th para:

<thclass="col−xs−8 sortable${searchParameters.sort == ’description’ ? searchParameters.order : ’’}"

data−sort="description">

<spring:message code="label.description"></spring:message></th>

O forEach que se encontra dentro do tbody tera que ser alterado para:

<c:forEach items="${toDos.pageList}" var="toDo"><tr>

<td> ${toDo.externalId} </td><td> ${toDo.description} </td><td class="text−right"><ahref="${editUrl}/${toDo.externalId}"class="btn btn−icon−only blue−steel tooltips"data−container="body"data−placement="top"data−original−title="<spring:message code=’edit’/>"

><i class="fa fa−fw fa−edit"></i>

</a><buttontype="button"data−id="${toDo.externalId}"class="btn btn−icon−only red btn−set−as−complete tooltips"data−container="body"data−placement="top"data−original−title="<spring:message code=’todo.set_as_complete’/>"

><i class="fa fa−fw fa−trash"></i>

</button><buttontype="button"data−id="${toDo.externalId}"class="btn btn−icon−only red btn−delete tooltips"data−container="body"data−placement="top"data−original−title="<spring:message code=’delete’/>"

><i class="fa fa−fw fa−trash"></i>

</button></td>

</tr></c:forEach>

O paging tera que ser alterada para:

111

<!−− BEGIN PAGINATION −−><tg:paging pagedListHolder="${toDos}" pagedLink="${listUrl}"/><!−−END PAGINATION −−>

O modal tera que ser alterado para:

<divclass="modal fade"id="deleteToDoModal"tabindex="−1"role="deleteToDoModal"aria−hidden="true"

><div class="modal−dialog">

<div class="modal−content"><div class="modal−header"><button type="button" class="close" data−dismiss="modal" aria−hidden="true"></button><h4 class="modal−title"><spring:message code=’todo.delete.description’/>

</h4></div><div class="modal−body">

<spring:message code=’todo.delete.are_you_sure’/></div><div class="modal−footer"><form method="POST" action="${deleteUrl}" id="delete−form">${csrf.field()}<input name="id" value="${toDo.externalId}" type="hidden" id="todo−id">

<button type="button" class="btn default" data−dismiss="modal"><i class="fa fa−chevron−circle−left"></i><spring:message code="back"/>

</button>

<button type="submit" class="btn btn−danger"><i class="fa fa−trash"></i><spring:message code="delete"/>

</button></form>

</div></div>

</div></div>

Tera que ser adicionado um novo Modal, para tratar do pedido de setAsComplete:

<divclass="modal fade"id="setAsCompleteModal"tabindex="−1"role="setAsCompleteModal"aria−hidden="true"

><div class="modal−dialog">

<div class="modal−content"><div class="modal−header"><button type="button" class="close" data−dismiss="modal" aria−hidden="true"></button><h4 class="modal−title"><spring:message code=’todo.set_as_complete.description’/>

</h4>

112

</div><div class="modal−body">

<spring:message code=’todo.set_as_complete.are_you_sure’/></div><div class="modal−footer"><form method="POST" action="${setAsCompleteUrl}" id="set−as−complete−form">${csrf.field()}<input name="id" value="${toDo.externalId}" type="hidden" id="todo−id">

<button type="button" class="btn default" data−dismiss="modal"><i class="fa fa−chevron−circle−left"></i><spring:message code="back"/>

</button>

<button type="submit" class="btn btn−danger"><i class="fa fa−trash"></i><spring:message code="todo.set_as_complete"/>

</button></form>

</div></div>

</div></div>

Para finalizar, e necessario alterar o script responsavel por mostrar o Modal de delete:

$(".btn−delete").click(function(){$("#todo−id").val($(this).data("id"))$("#deleteToDoModal").modal();

});

E acrescentar o novo script responsavel por mostrar o Modal de setAsComplete:

$(".btn−set−as−complete").click(function(){$("#todo−id").val($(this).data("id"))$("#setAsCompleteModal").modal();

});

A.3 Instalar o novo modulo no sistema

Uma vez implementado o novo modulo, e necessario instalar o modulo no sistema antes de poder ser

utilizado. Para tal, e necessario seguir os seguintes passos:

1. Compilar o novo modulo usando o comando mvn install.

2. Compilar e correr o modulo feng-webapp.

3. Entrar no sistema usando uma conta de administracao.

4. Selecionar Portal Configuration no menu lateral.

5. Selecionar Manage Menu.

6. Selecionar, no lado esquerdo, a localizacao onde se deseja instalar o modulo.

7. Selecionar Install.

113

8. Selecionar em Application o novo modulo.

9. Selecionar em Functionality o novo modulo.

10. Selecionar Install Functionality.

Com estes passos, o novo modulo esta pronto para ser utilizado. Depois de instalado, e ainda

possıvel alterar o nome apresentado (para todos os idiomas suportados pelo sistema), dar-lhe um icon

para ser apresentado no menu lateral, e alterar os grupos que tem acesso as novas funcionalidades.

114

Apendice B

Guia de Instalacao e Atualizacao do

Sistema de Gestao de Informacao do

IPFN

Este documento contem as instrucoes e comandos a utilizar para corretamente instalar o novo Sistema

de Gestao de Informacao do IPFN numa maquina a correr o Sistema Operativo Ubuntu (ou um derivado

de Ubuntu, como Kubuntu ou Xubuntu). Seguindo estas instrucoes, o servico estara a correr numa so

maquina com hostname intranet.ipfn.tecnico.ulisboa.pt, no porto 8080, e a base de dados es-

tara a correr na mesma maquina, no porto 3306. Na Seccao B.2 tambem esta documentado o processo

de atualizacao do Sistema de Gestao de Informacao do IPFN, a correr nas mesmas condicoes.

B.1 Instalar o Sistema

Antes de iniciar o processo de instalacao, e necessario notar que o codigo-fonte do sistema, necessario

durante o processo de instalacao, podera ter mudado de repositorio de controlo de versoes, ou ate

mesmo de sistema de controlo de versoes, desde a escrita deste documento. Por esta razao, sera

assumido que a versao mais recente do codigo-fonte ja foi descarregada do repositorio para a pasta

~/feng.

B.1.1 Instalar e Configurar as Dependencias

Para instalar o novo Sistema de Gestao de Informacao do IPFN numa maquina limpa, sao necessarias

as seguintes dependencias: JDK 8, Maven 3, MySQL 5.5 e Tomcat 7. Estas dependencias podem ser

instaladas usando os seguintes comandos:

$ apt−get install mysql−server−5.5 mysql−server mysql−client−5.5$ apt−get install tomcat7$ apt−get install maven

115

$ apt−get install software−properties−common$ add−apt−repository ppa:webupd8team/java$ apt−get update$ apt−get install oracle−java8−installer

Para preparar a base de dados para o sistema, e necessario criar um novo schema. Tambem e

aconselhado utilizar uma conta especifica para o sistema. Esta conta deve ter permissoes totais sobre

o schema criado anteriormente. Estes passos podem ser realizados utilizando os comandos:

$ mysql −uroot −pmysql> CREATE SCHEMA feng;mysql> CREATE USER ’feng’@’localhost’ IDENTIFIED BY ’some\_password’;mysql> GRANT ALL ON feng.∗ TO feng@’localhost’;

Como o sistema utiliza BennuFramework (que, por sua vez, utiliza a Fenix Framework), nao e ne-

cessario criar quaisquer tabelas, pois estas sao criadas automaticamente.

De seguida, e necessario configurar o Tomcat7 para utilizar o JDK 8 (a BennuFramework e in-

compatıvel com JDK 7 ou anterior) e utilizar pelo menos 1GB de RAM (requisito, tambem, da Ben-

nuFramework). O ficheiro de configuracao do Tomcat7 encontra-se em /etc/default/tomcat7. Para

configurar estes dois aspetos, e preciso que

1. JAVA HOME aponte para o diretorio onde foi instalado o JDK 8.

2. JAVA OPTS indique para utilizar 1GB de RAM.

As seguintes configuracoes devem indicar os dois aspetos corretamente:

# The home directory of the Java development kit (JDK). You need at least# JDK version 1.5. If JAVA_HOME is not set, some common directories for# OpenJDK, the Sun JDK, and various J2SE 1.5 versions are tried.JAVA_HOME=/usr/lib/jvm/java−8−oracle

# You may pass JVM startup parameters to Java here. If unset, the default# options will be: −Djava.awt.headless=true −Xmx128m −XX:+UseConcMarkSweepGC## Use "−XX:+UseConcMarkSweepGC" to enable the CMS garbage collector (improved# response time). If you use that option and you run Tomcat on a machine with# exactly one CPU chip that contains one or two cores, you should also add# the "−XX:+CMSIncrementalMode" option.JAVA_OPTS="−Djava.awt.headless=true −Xmx1g −XX:+UseConcMarkSweepGC"

Estas duas variaveis ja existem, por definicao, no ficheiro /etc/default/tomcat7 com outros valores

(linhas 12 e 21 para JAVA HOME e JAVA OPTS, respetivamente), e portanto devem ser substituıdas com

os valores indicados acima.

Para alem destas dependencias, a Intranet necessita tambem que os seguintes projetos estejam

instalados no sistema: Fenix Java SDK, Dot Java SDK e Messaging. O codigo fonte destes modulos

pode ser encontrado em:

https://github.com/JSMCAG/fenixedu-java-sdk

https://github.com/JSMCAG/dot-java-sdk

https://github.com/FenixEdu/messaging

116

Para instalar cada um destes projetos, e necessario transferir o codigo fonte (p.ex.: usando git

clone) e, apos a transferencia, correr o seguinte comando dentro da diretoria do projeto:

$ mvn install

Uma vez preparada a base de dados, e configurado o Tomcat, podemos agora compilar, configurar

e instalar o sistema.

B.1.2 Compilar e Empacotar o Sistema

O novo Sistema de Gestao de Informacao do IPFN esta dividido em diferentes modulos, agrupados

em dois projetos Maven separados. O principal, simplesmente chamado de “feng”, inclui como sub-

modulos todos os outros modulos do sistema, com a excecao do modulo “feng-webapp”. O modulo

“feng-webbapp” e um projeto Maven separado do principal, mas que tem como dependencias todos os

modulos do “feng”. Portanto, para instalar o sistema, e necessario seguir os seguintes passos:

1. Compilar o projeto “feng” inteiro.

2. Criar os ficheiros de configuracao para o “feng-webapp”

3. Empacotar o projeto “feng-webapp” num WAR e instala-lo no Tomcat 7

4. Reiniciar o servico Tomcat 7

Para compilar o projeto “feng” inteiro, basta correr os seguintes comandos:

$ cd ~/feng$ mvn install

Os ficheiros de configuracao para o “feng-webapp” encontram-se em ~/feng/feng-webapp/src/

main/resources. Podera ser necessario criar esta diretoria. Existem cinco ficheiros de configuracao

para o “feng-webapp”: fenix-framework.properties, configuration.properties, fenixedu.properties,

dot.properties e logback.xml. O primeiro, fenix-framework.properties, contem as configuracoes

da base de dados para a Fenix Framework. Este ficheiro deve conter:

1. dbAlias, com a localizacao do servidor MySQL

2. dbUsername, com o nome de utilizador que o sistema vai utilizar

3. dbPassword, com a password para o utilizador que o sistema vai utilizar

4. updateRepositoryStructureIfNeeded, que indica se a Fenix Framework deve automaticamente

modificar a estrutura da base de dados caso haja alguma atualizacao ao sistema. Caso esteja a

true, a Fenix Framework encarrega-se de modificar a estrutura e migrar os dados para a nova

estrutura. Caso esteja a false, sera necessario realizar a migracao manualmente.

5. canCreateDomainMetaObjects, que indica se a Fenix Framework pode criar meta-objetos de

domınio.

117

Tendo em conta a configuracao da base de dados indicada na Seccao B.1.1, o ficheiro fenix-framework.

properties deve entao ficar assim:

dbAlias=//localhost:3306/feng

dbUsername=fengdbPassword=some_password

updateRepositoryStructureIfNeeded = truecanCreateDomainMetaObjects=false

O segundo, configuration.properties, contem as configuracoes da WebApp para a BennuFra-

mework. Para gerar este ficheiro, basta correr os seguintes comandos:

$ cd feng−webapp$ mvn bennu:generate−configuration

Este comando gera automaticamente um ficheiro de configuracao base, com alguns valores pre-definidos,

e outros para serem preenchidos.

Para o sistema, as seguintes variaveis devem ser alteradas:

1. application.url, que deve apontar o URL completo para a aplicacao.

2. development.mode, que indica se a aplicacao deve estar em modo de desenvolvimento ou nao.

3. locale.default, que deve dizer qual o idioma predefinido da aplicacao. O sistema esta desen-

volvido para suportar Ingles (en-GB) e Portugues (pt-PT).

4. locales.supported, que deve ter uma lista (separada por virgulas), de todos os idiomas para a

aplicacao. O sistema esta desenvolvido para suportar Ingles (en-GB) e Portugues (pt-PT).

5. logout.url, que deve apontar o URL para o qual a aplicacao deve redirecionar apos um utilizador

sair da aplicacao.

6. cas.enabled, que deve indicar se a aplicacao deve permitir aos utilizadores autenticarem-se

usando um servico CAS externo.

7. cas.serverUrl, que deve indicar o URL onde se encontra o CAS a utilizar para autenticacao

8. cas.serviceUrl, que deve indicar um URL predefinido para redirecionar apos autenticacao no

CAS

9. local.login, que deve indicar se a aplicacao deve permitir aos utilizadores autenticarem-se sem

usar o CAS

10. mail.smtp.host, que deve apontar o host do servidor de SMTP a utilizar para enviar emails.

11. mail.smtp.name, que deve indicar o nome do host.

12. mail.smtp.port, que deve indicar o porto do servico SMTP.

118

Os seguintes valores sao indicados para o sistema correr numa maquina com hostname intranet.

ipfn.tecnico.ulisboa.pt em modo de producao:

• application.url = http://intranet.ipfn.tecnico.ulisboa.pt:8080/feng

• development.mode = false

• locale.default = pt-PT

• locales.supported = pt-PT,en-GB

• logout.url = https://id.tecnico.ulisboa.pt/cas/logout

• cas.enabled = true

• cas.serverUrl = https://id.tecnico.ulisboa.pt/cas

• cas.serviceUrl = http://intranet.ipfn.tecnico.ulisboa.pt:8080/feng/index.jsp

• local.login = true

• mail.smtp.host = smtp.ipfn.ist.utl.pt

• mail.smtp.name = smtp

• mail.smtp.port = 25

O terceiro, fenixedu.properties, contem as configuracoes para aceder a API do Fenix, e assim

permitir a sincronizacao de alguma informacao pessoal. Este ficheiro deve conter:

1. oauth.customer.key, que contem o Client ID gerado ao registar a aplicacao no Fenix

2. oauth.customer.secret, que contem o Client Secret gerado ao registar a aplicacao no Fenix

3. callback.url, que contem o URL do endpoint para receber as chaves de acesso de cada utiliza-

dor

4. base.url, que contem o URL a utilizar para chamar os endpoints da API

Os seguintes valores sao indicados para o sistema correr numa maquina com hostname intranet.

ipfn.tecnico.ulisboa.pt em modo de producao:

• oauth.consumer.key = FENG CONSUMER KEY

• oauth.consumer.secret = FENG SECRET KEY

• callback.url = http://intranet.ipfn.tecnico.ulisboa.pt:8080/feng/members/authorization

• base.url = https://fenix.tecnico.ulisboa.pt

O quarto, dot.properties, contem as configuracoes para aceder a API do Dot, e assim permitir a

consulta de missoes do Dot. Este ficheiro deve conter:

119

1. oauth.customer.key, que contem o Client ID gerado ao registar a aplicacao no Fenix

2. oauth.customer.secret, que contem o Client Secret gerado ao registar a aplicacao no Fenix

3. callback.url, que contem o URL do endpoint para receber as chaves de acesso de cada utiliza-

dor

4. base.url, que contem o URL a utilizar para chamar os endpoints da API

Os seguintes valores sao indicados para o sistema correr numa maquina com hostname intranet.

ipfn.tecnico.ulisboa.pt em modo de producao:

• oauth.consumer.key = FENG CONSUMER KEY

• oauth.consumer.secret = FENG SECRET KEY

• callback.url = http://intranet.ipfn.tecnico.ulisboa.pt:8080/feng/missions/authorization

• base.url = https://dot.tecnico.ulisboa.pt

O quinto, logback.xml, contem as configuracoes para os logs criados pelo sistema, como esta

explicado em http://logback.qos.ch/manual/configuration.html. Encontram-se mais instrucoes

sobre este ficheiro na Seccao B.4.

Uma vez criados os ficheiros de configuracao, pode-se entao empacotar o projeto “feng-webapp”

num WAR e instala-lo no Tomcat 7. Para tal, basta correr os seguintes comandos na diretoria ~/feng/

feng-webapp:

$ mvn clean package$ cp target/feng−webapp−1.0.0−SNAPSHOT.war /var/lib/tomcat7/webapps/feng.war

Finalmente, basta reiniciar o servico Tomcat 7

$ service tomcat7 stop$ service tomcat7 start

Com isto, o sistema esta pronto para ser utilizado pela primeira vez.

B.1.3 Configurar o Sistema

Ao aceder a http://intranet.ipfn.tecnico.ulisboa.pt:8080/feng, inicia-se o processo de boots-

trap da aplicacao. Para continuar, basta seguir as instrucoes indicadas. Durante o processo de boots-

trap da aplicacao, vao ser configuradas outras definicoes da aplicacao (tais como o nome da aplicacao

e da instituicao), e vai ser criada uma conta de administrador (por definicao, com username “admin” e

password “admin”).

Uma vez terminado o processo de bootstrap, e necessario ainda configurar mais definicoes:

1. O tema da aplicacao deve ser alterado para “metronic”.

2. O logotipo da aplicacao, assim como o favicon, devem ser escolhidos.

120

3. Deve ser escolhido um diretorio de armazenamento, onde sao guardados os ficheiros que se faz

upload (por exemplo, as imagens das notıcias).

4. Devem ser instaladas e configuradas as opcoes de envio de email.

5. Devem ser disponibilizados os modulos do “feng”.

Vai ser assumido que, para os passos seguintes, o utilizador fez login no sistema usando a conta de

administracao criada durante o processo de bootstrap, e tem o sistema em Ingles. Apos fazer login, o

sistema apresentara um erro. Isto e normal, pois o sistema, apos autenticacao, redireciona o utilizador

para o dashboard, que ainda nao foi disponibilizado. Este sera disponibilizado mais adiante.

Para alterar o tema da aplicacao, basta seguir os seguintes passos:

1. Ir a http://intranet.ipfn.tecnico.ulisboa.pt:8080/feng/bennu-admin/#/portal-configuration.

2. Em Theme, selecionar metronic.

3. Carregar em “Save”.

Para alterar o logotipo e o favicon, basta seguir os seguintes passos:

1. Ir a http://intranet.ipfn.tecnico.ulisboa.pt:8080/feng/bennu-admin/#/portal-configuration.

2. Em Logo, carregar em Choose File, e escolher uma imagem de logotipoo. Esta imagem deve ser

um PNG e ter uma resolucao de 85 x 38 pixeiss.

3. Em Favicon, carregar em Choose File, e escolher uma imagem de favicon. Esta imagem deve ser

um ICO e ter uma resolucao de pelo menos 16 x 16 pixeiss.

4. Carregar em “Save”.

Para configurar o diretorio de armazenamento, basta seguir os seguintes passos:

1. Ir a http://intranet.ipfn.tecnico.ulisboa.pt:8080/feng/bennu-admin/#/io.

2. Carregar em + New.

3. Carregar no separador File System Store.

4. Em Name, dar um nome ao diretorio (por exemplo: fengStorage).

5. Em Path, indicar o caminho completo para o diretorio. O diretorio deve ja existir, e o Tomcat7 deve

ter permissoes para ler e escrever neste diretorio.

6. Carregar em Create.

7. Carregar no separador Configurations.

8. Para o File Type org.fenixedu.bennu.io.domain.GroupBasedFile, selecionar o repositorio cri-

ado nos passos 2 a 6.

121

Para configurar as definicoes de envio de emails, basta seguir os seguintes passos:

1. Ir a http://intranet.ipfn.tecnico.ulisboa.pt:8080/feng/bennu-admin/#/portal-configuration.

2. Carregar em Manage Menu.

3. Do lado esquerdo vai-se encontrar uma representacao do menu lateral. E preciso encontrar e

selecionar a primeira pasta de todas.

4. Carregar em Install.

5. Em Application, selecionar Messaging System.

6. Carregar em Install Application.

7. Do lado esquerdo, encontrar e selecionar a pasta Messaging System.

8. Em Access Expression, escrever #managers.

9. Carregar em Save.

10. Ir a http://intranet.ipfn.tecnico.ulisboa.pt:8080/feng/messaging/config/senders.

11. Carregar em Configure.

12. Em Name, escrever “Intranet IPFN”.

13. Em Address, escrever intranet@ipfn.tecnico.ulisboa.pt.

14. Em Member Group Expression, escrever #managers.

15. Carregar em Configure.

16. Ir a http://intranet.ipfn.tecnico.ulisboa.pt:8080/feng/bennu-admin/#/scheduler/tasks.

17. Em Tasks, carregar em Schedule relativo a tarefa org.fenixedu.messaging.core.task.MessageTask.

18. Carregar em Schedule. Isto garante que esta tarefa sera corrida a todos os minutos.

19. Ir a http://intranet.ipfn.tecnico.ulisboa.pt:8080/feng/bennu-admin/#/scheduler/tasks.

20. Em Tasks, carregar em Schedule relativo a tarefa taskorg.fenixedu.messaging.emaildispatch.

task.EmailTask.

21. Carregar em Schedule. Isto garante que esta tarefa sera corrida a todos os minutos.

Devido a elevada frequencia com que as tarefas org.fenixedu.messaging.core.task.MessageTask

e taskorg.fenixedu.messaging.emaildispatch.task.EmailTask serao executadas, o sistema ira ge-

rar uma elevada quantidade de diretorias e ficheiros na pasta /tmp/tomcat7-tomcat7-tmp/. E aconse-

lhado que sejam eliminados com alguma frequencia os ficheiros e diretorias mais antigos.

122

Modulo de Membros

Para disponibilizar o Modulo de Membros, basta seguir os seguintes passos:

1. Ir a http://intranet.ipfn.tecnico.ulisboa.pt:8080/feng/bennu-admin/#/portal-configuration.

2. Carregar em Manage Menu.

3. Do lado esquerdo vai-se encontrar uma representacao do menu lateral. E preciso encontrar e

selecionar a pasta Human Resources.

(a) Se esta nao existir, entao e preciso selecionar a primeira pasta (com o nome do sistema).

(b) Carregar em Create Child.

(c) Em Title, escrever “Human Resources” para Ingles, e “Recursos Humanos” para Portugues.

(d) Em Description, fazer o mesmo que no passo anterior.

(e) Em Path, escrever “human-resources”.

(f) Carregar em Save.

4. Carregar em Install.

5. Em Application, selecionar Members.

6. Em Functionality, selecionar Members.

7. Carregar em Install Functionality.

8. Abrir a pasta Human Resources, selecionar Members.

9. Em Icon, escrever icon-user.

10. Carregar em Save.

11. Ir a http://intranet.ipfn.tecnico.ulisboa.pt:8080/feng/bennu-admin/#/scheduler/custom/

add.

12. Copiar o conteudo do ficheiro feng/feng-webapp/src/main/java/pt/ulisboa/tecnico/ipfn/

feng/webapp/task/CreateMembersModuleGroupsTask.java e colar em New Custom Task.

13. Carregar em Compile. A mensagem “The compilation was successful!” deve aparecer.

14. Carregar em Run.

15. Ir a http://intranet.ipfn.tecnico.ulisboa.pt:8080/feng/bennu-admin/#/scheduler/tasks.

16. Em Tasks, carregar em Schedule relativo a task pt.ulisboa.tecnico.ipfn.feng.webapp.task.

SyncMembersDetailsTask.

17. Em Schedule, escrever “0 0 * * *”. Isto garante que esta task sera corrida todos os dias as 00h00.

18. Carregar em Schedule.

123

Depois de estar o Modulo de Membros disponibilizado, e necessario que a pessoa responsavel pela

gestao de Membros faca login usando o CAS. Ao ser autenticado pela primeira vez, o sistema ira criar

um utilizador para essa pessoa, com o username igual ao seu TecnicoID. De seguida, e necessario

utilizar a conta de administracao do sistema para realizar os seguintes passos:

1. Ir a http://intranet.ipfn.tecnico.ulisboa.pt:8080/feng/bennu-admin/#/user-management/

groups.

2. Carregar em “members admin”.

3. Em Add User, escrever o TecnicoID da pessoa responsavel pela gestao dos Membros.

4. Selecionar a pessoa e carregar em Add User.

5. Carregar em “members member”.

6. Repetir os passos 3 e 4.

Finalmente, usando a conta de utilizador da pessoa responsavel pela gestao dos Membros, e ne-

cessario seguir os seguintes passos:

1. Ir a http://intranet.ipfn.tecnico.ulisboa.pt:8080/feng/members/add.

2. Em Username, escrever o TecnicoID da pessoa responsavel pela gestao dos Membros.

3. Em Full Name, escrever o nome completo da pessoa responsavel pela gestao dos Membros.

4. Selecionar Active.

5. Opcionalmente, preencher os restantes campos com a informacao da pessoa responsavel pela

gestao dos Membros.

6. Carregar em Submit.

Com isto, ja e possıvel a esta pessoa gerir as permissoes dos restantes utilizadores que se au-

tenticarem perante o CAS. Pode ser criado um registo de membro antes do utilizador correspondente

autenticar-se pela primeira vez, que o sistema automaticamente associara os dois, bastando para isso

que o registo de membro tenha indicado, no campo Username, o TecnicoID da pessoa correspondente.

Modulo de Perfil de Membro

Para disponibilizar o Modulo de Perfil de Membro, basta seguir os seguintes passos:

1. Ir a http://intranet.ipfn.tecnico.ulisboa.pt:8080/feng/bennu-admin/#/portal-configuration.

2. Carregar em Manage Menu.

3. Do lado esquerdo vai-se encontrar uma representacao do menu lateral. E preciso encontrar e

selecionar a pasta Human Resources.

124

(a) Se esta nao existir, entao e preciso selecionar a primeira pasta (com o nome do sistema).

(b) Carregar em Create Child.

(c) Em Title, escrever “Human Resources” para Ingles, e “Recursos Humanos” para Portugues.

(d) Em Description, fazer o mesmo que no passo anterior.

(e) Em Path, escrever “human-resources”.

(f) Carregar em Save.

4. Carregar em Install.

5. Em Application, selecionar Member Profile.

6. Em Functionality, selecionar Member Profile.

7. Carregar em Install Functionality.

8. Abrir a pasta Human Resources, selecionar Member Profile.

9. Em Icon, escrever icon-badge.

10. Carregar em Save.

11. Ir a http://intranet.ipfn.tecnico.ulisboa.pt:8080/feng/bennu-admin/#/scheduler/custom/

add.

12. Copiar o conteudo do ficheiro feng/feng-webapp/src/main/java/pt/ulisboa/tecnico/ipfn/

feng/webapp/task/CreateMemberProfilesModuleGroupsTask.java e colar em New Custom Task.

13. Carregar em Compile. A mensagem “The compilation was successful!” deve aparecer.

14. Carregar em Run.

Modulo de Missoes

Para disponibilizar o Modulo de Missoes, basta seguir os seguintes passos:

1. Ir a http://intranet.ipfn.tecnico.ulisboa.pt:8080/feng/bennu-admin/#/portal-configuration.

2. Carregar em Manage Menu.

3. Do lado esquerdo vai-se encontrar uma representacao do menu lateral. E preciso encontrar e

selecionar a pasta Human Resources.

(a) Se esta nao existir, entao e preciso selecionar a primeira pasta (com o nome do sistema).

(b) Carregar em Create Child.

(c) Em Title, escrever “Human Resources” para Ingles, e “Recursos Humanos” para Portugues.

(d) Em Description, fazer o mesmo que no passo anterior.

125

(e) Em Path, escrever “human-resources”.

(f) Carregar em Save.

4. Carregar em Install.

5. Em Application, selecionar Missions.

6. Em Functionality, selecionar Missions.

7. Carregar em Install Functionality.

8. Abrir a pasta Human Resources, selecionar Missions.

9. Em Icon, escrever icon-plane.

10. Carregar em Save.

11. Ir a http://intranet.ipfn.tecnico.ulisboa.pt:8080/feng/bennu-admin/#/scheduler/custom/

add.

12. Copiar o conteudo do ficheiro feng/feng-webapp/src/main/java/pt/ulisboa/tecnico/ipfn/

feng/webapp/task/CreateMissionsModuleGroupsTask.java e colar em New Custom Task.

13. Carregar em Compile. A mensagem “The compilation was successful!” deve aparecer.

14. Carregar em Run.

Modulo de Projetos

Para disponibilizar o Modulo de Projetos, basta seguir os seguintes passos:

1. Ir a http://intranet.ipfn.tecnico.ulisboa.pt:8080/feng/bennu-admin/#/portal-configuration.

2. Carregar em Manage Menu.

3. Do lado esquerdo vai-se encontrar uma representacao do menu lateral. E preciso encontrar e

selecionar a pasta Production.

(a) Se esta nao existir, entao e preciso selecionar a primeira pasta (com o nome do sistema).

(b) Carregar em Create Child.

(c) Em Title, escrever “Production” para Ingles, e “Producao” para Portugues.

(d) Em Description, fazer o mesmo que no passo anterior.

(e) Em Path, escrever “production”.

(f) Carregar em Save.

4. Carregar em Install.

5. Em Application, selecionar Projects.

126

6. Em Functionality, selecionar Projects.

7. Carregar em Install Functionality.

8. Abrir a pasta Production, selecionar Projects.

9. Em Icon, escrever icon-folder-alt.

10. Carregar em Save.

11. Ir a http://intranet.ipfn.tecnico.ulisboa.pt:8080/feng/bennu-admin/#/scheduler/custom/

add.

12. Copiar o conteudo do ficheiro feng/feng-webapp/src/main/java/pt/ulisboa/tecnico/ipfn/

feng/webapp/task/CreateProjectsModuleGroupsTask.java e colar em New Custom Task.

13. Carregar em Compile. A mensagem “The compilation was successful!” deve aparecer.

14. Carregar em Run.

Modulo de Notıcias

Para disponibilizar o Modulo de Notıcias, basta seguir os seguintes passos:

1. Ir a http://intranet.ipfn.tecnico.ulisboa.pt:8080/feng/bennu-admin/#/portal-configuration.

2. Carregar em Manage Menu.

3. Do lado esquerdo vai-se encontrar uma representacao do menu lateral. E preciso encontrar e

selecionar a pasta Production.

(a) Se esta nao existir, entao e preciso selecionar a primeira pasta (com o nome do sistema).

(b) Carregar em Create Child.

(c) Em Title, escrever “Production” para Ingles, e “Producao” para Portugues.

(d) Em Description, fazer o mesmo que no passo anterior.

(e) Em Path, escrever “production”.

(f) Carregar em Save.

4. Carregar em Install.

5. Em Application, selecionar News.

6. Em Functionality, selecionar News.

7. Carregar em Install Functionality.

8. Abrir a pasta Production, selecionar News.

9. Em Icon, escrever icon-book-open.

127

10. Carregar em Save.

11. Ir a http://intranet.ipfn.tecnico.ulisboa.pt:8080/feng/bennu-admin/#/scheduler/custom/

add.

12. Copiar o conteudo do ficheiro feng/feng-webapp/src/main/java/pt/ulisboa/tecnico/ipfn/

feng/webapp/task/CreateNewsCategoriesTask.java e colar em New Custom Task.

13. Carregar em Compile. A mensagem “The compilation was successful!” deve aparecer.

14. Carregar em Run.

15. Ir a http://intranet.ipfn.tecnico.ulisboa.pt:8080/feng/bennu-admin/#/scheduler/custom/

add.

16. Copiar o conteudo do ficheiro feng/feng-webapp/src/main/java/pt/ulisboa/tecnico/ipfn/

feng/webapp/task/CreateNewsModuleGroupsTask.java e colar em New Custom Task.

17. Carregar em Compile. A mensagem “The compilation was successful!” deve aparecer.

18. Carregar em Run.

Modulo de Grupos de Investigacao

Para disponibilizar o Modulo de Grupos de Investigacao, basta seguir os seguintes passos:

1. Ir a http://intranet.ipfn.tecnico.ulisboa.pt:8080/feng/bennu-admin/#/portal-configuration.

2. Carregar em Manage Menu.

3. Do lado esquerdo vai-se encontrar uma representacao do menu lateral. E preciso encontrar e

selecionar a pasta Production.

(a) Se esta nao existir, entao e preciso selecionar a primeira pasta (com o nome do sistema).

(b) Carregar em Create Child.

(c) Em Title, escrever “Production” para Ingles, e “Producao” para Portugues.

(d) Em Description, fazer o mesmo que no passo anterior.

(e) Em Path, escrever “production”.

(f) Carregar em Save.

4. Carregar em Install.

5. Em Application, selecionar Investigation Groups.

6. Em Functionality, selecionar Investigation Groups.

7. Carregar em Install Functionality.

8. Abrir a pasta Production, selecionar Investigation Groups.

128

9. Em Icon, escrever icon-users.

10. Carregar em Save.

11. Ir a http://intranet.ipfn.tecnico.ulisboa.pt:8080/feng/bennu-admin/#/scheduler/custom/

add.

12. Copiar o conteudo do ficheiro ~/feng/feng-webapp/src/main/java/pt/ulisboa/tecnico/ipfn/

feng/webapp/task/CreateInvestigationGroupsModuleGroupsTask.java e colar em New Cus-

tom Task.

13. Carregar em Compile. A mensagem “The compilation was successful!” deve aparecer.

14. Carregar em Run.

Modulo de Tickets de Suporte

Para disponibilizar o Modulo de Suporte Informatico, basta seguir os seguintes passos:

1. Ir a http://intranet.ipfn.tecnico.ulisboa.pt:8080/feng/bennu-admin/#/portal-configuration.

2. Carregar em Manage Menu.

3. Do lado esquerdo vai-se encontrar uma representacao do menu lateral. E preciso encontrar e

selecionar a pasta Support.

(a) Se esta nao existir, entao e preciso selecionar a primeira pasta (com o nome do sistema).

(b) Carregar em Create Child.

(c) Em Title, escrever “IT Support” para Ingles, e “Suporte Informatico” para Portugues.

(d) Em Description, fazer o mesmo que no passo anterior.

(e) Em Path, escrever “it-support”.

(f) Carregar em Save.

4. Carregar em Install.

5. Em Application, selecionar Support Tickets.

6. Em Functionality, selecionar Support Tickets.

7. Carregar em Install Functionality.

8. Abrir a pasta IT Support, selecionar Support Tickets.

9. Em Icon, escrever icon-question.

10. Carregar em Save.

11. Ir a http://intranet.ipfn.tecnico.ulisboa.pt:8080/feng/bennu-admin/#/scheduler/custom/

add.

129

12. Copiar o conteudo do ficheiro ~/feng/feng-webapp/src/main/java/pt/ulisboa/tecnico/ipfn/

feng/webapp/task/CreateSupportModuleGroupsTask.java e colar em New Custom Task.

13. Carregar em Compile. A mensagem “The compilation was successful!” deve aparecer.

14. Carregar em Run.

Modulo de Rede Informatica

Para disponibilizar o Modulo de Rede Informatica, basta seguir os seguintes passos:

1. Ir a http://intranet.ipfn.tecnico.ulisboa.pt:8080/feng/bennu-admin/#/portal-configuration.

2. Carregar em Manage Menu.

3. Do lado esquerdo vai-se encontrar uma representacao do menu lateral. E preciso encontrar e

selecionar a pasta Support.

(a) Se esta nao existir, entao e preciso selecionar a primeira pasta (com o nome do sistema).

(b) Carregar em Create Child.

(c) Em Title, escrever “IT Support” para Ingles, e “Suporte Informatico” para Portugues.

(d) Em Description, fazer o mesmo que no passo anterior.

(e) Em Path, escrever “it-support”.

(f) Carregar em Save.

4. Carregar em Install.

5. Em Application, selecionar Network.

6. Em Functionality, selecionar Network.

7. Carregar em Install Functionality.

8. Abrir a pasta IT Support, selecionar Network.

9. Em Icon, escrever icon-feed.

10. Carregar em Save.

11. Ir a http://intranet.ipfn.tecnico.ulisboa.pt:8080/feng/bennu-admin/#/scheduler/custom/

add.

12. Copiar o conteudo do ficheiro ~/feng/feng-webapp/src/main/java/pt/ulisboa/tecnico/ipfn/

feng/webapp/task/CreateNetworkModuleGroupsTask.java e colar em New Custom Task.

13. Carregar em Compile. A mensagem “The compilation was successful!” deve aparecer.

14. Carregar em Run.

130

Modulo de Inventario

Para disponibilizar o Modulo de Inventario, basta seguir os seguintes passos:

1. Ir a http://intranet.ipfn.tecnico.ulisboa.pt:8080/feng/bennu-admin/#/portal-configuration.

2. Carregar em Manage Menu.

3. Do lado esquerdo vai-se encontrar uma representacao do menu lateral. E preciso encontrar e

selecionar a pasta Ativos.

(a) Se esta nao existir, entao e preciso selecionar a primeira pasta (com o nome do sistema).

(b) Carregar em Create Child.

(c) Em Title, escrever “Actives” para Ingles, e “Ativos” para Portugues.

(d) Em Description, fazer o mesmo que no passo anterior.

(e) Em Path, escrever “actives”.

(f) Carregar em Save.

4. Carregar em Install.

5. Em Application, selecionar Resources.

6. Em Functionality, selecionar Resources.

7. Carregar em Install Functionality.

8. Abrir a pasta Actives, selecionar Resources.

9. Em Icon, escrever icon-bag.

10. Carregar em Save.

11. Ir a http://intranet.ipfn.tecnico.ulisboa.pt:8080/feng/bennu-admin/#/scheduler/custom/

add.

12. Copiar o conteudo do ficheiro ~/feng/feng-webapp/src/main/java/pt/ulisboa/tecnico/ipfn/

feng/webapp/task/CreateInventoryModuleGroupsTask.java e colar em New Custom Task.

13. Carregar em Compile. A mensagem “The compilation was successful!” deve aparecer.

14. Carregar em Run.

Modulo de Assiduidade

Para disponibilizar o Modulo de Assiduidade, basta seguir os seguintes passos:

1. Ir a http://intranet.ipfn.tecnico.ulisboa.pt:8080/feng/bennu-admin/#/portal-configuration.

2. Carregar em Manage Menu.

131

3. Do lado esquerdo vai-se encontrar uma representacao do menu lateral. E preciso encontrar e

selecionar a pasta Human Resources.

(a) Se esta nao existir, entao e preciso selecionar a primeira pasta (com o nome do sistema).

(b) Carregar em Create Child.

(c) Em Title, escrever “Human Resources” para Ingles, e “Recursos Humanos” para Portugues.

(d) Em Description, fazer o mesmo que no passo anterior.

(e) Em Path, escrever “human-resources”.

(f) Carregar em Save.

4. Carregar em Install.

5. Em Application, selecionar Assiduity.

6. Em Functionality, selecionar Assiduity.

7. Carregar em Install Functionality.

8. Abrir a pasta Human Resources, selecionar Assiduity.

9. Em Icon, escrever icon-clock.

10. Carregar em Save.

11. Ir a http://intranet.ipfn.tecnico.ulisboa.pt:8080/feng/bennu-admin/#/scheduler/custom/

add.

12. Copiar o conteudo do ficheiro feng/feng-webapp/src/main/java/pt/ulisboa/tecnico/ipfn/

feng/webapp/task/CreateTimezonesTask.java e colar em New Custom Task.

13. Carregar em Compile. A mensagem “The compilation was successful!” deve aparecer.

14. Carregar em Run.

15. Ir a http://intranet.ipfn.tecnico.ulisboa.pt:8080/feng/bennu-admin/#/scheduler/custom/

add.

16. Copiar o conteudo do ficheiro feng/feng-webapp/src/main/java/pt/ulisboa/tecnico/ipfn/

feng/webapp/task/CreateAssiduityModuleGroupsTask.java e colar em New Custom Task.

17. Carregar em Compile. A mensagem “The compilation was successful!” deve aparecer.

18. Carregar em Run.

19. Ir a http://intranet.ipfn.tecnico.ulisboa.pt:8080/feng/bennu-admin/#/scheduler/tasks.

20. Em Tasks, carregar em Schedule relativo a task pt.ulisboa.tecnico.ipfn.feng.webapp.task.

FinishMidnightCurrentAttendancesTask.

21. Em Schedule, escrever “0 * * * *”. Isto garante que esta task sera corrida todos as horas.

22. Carregar em Schedule.

132

Modulo de Dashboard

Para disponibilizar o Modulo de Dashboard, basta seguir os seguintes passos:

1. Ir a http://intranet.ipfn.tecnico.ulisboa.pt:8080/feng/bennu-admin/#/portal-configuration.

2. Carregar em Manage Menu.

3. Do lado esquerdo vai-se encontrar uma representacao do menu lateral. E preciso encontrar e

selecionar a pasta Dashboard.

(a) Se esta nao existir, entao e preciso selecionar a primeira pasta (com o nome do sistema).

(b) Carregar em Create Child.

(c) Em Title, escrever “Dashboard” para Ingles, e “Dashboard” para Portugues.

(d) Em Description, fazer o mesmo que no passo anterior.

(e) Em Path, escrever “dashboard”.

(f) Carregar em Save.

4. Carregar em Install.

5. Em Application, selecionar Dashboard.

6. Em Functionality, selecionar Dashboard.

7. Carregar em Install Functionality.

8. Abrir a pasta Dashboard, selecionar Dashboard.

9. Em Icon, escrever icon-home.

10. Carregar em Save.

Com isto, o sistema deve ficar todo preparado para ser utilizado. Se for necessario, e possıvel

alterar a ordem dos modulos no menu lateral indo a http://intranet.ipfn.tecnico.ulisboa.pt:

8080/feng/bennu-admin/#/portal-configuration e arrastando os modulos para a ordem desejada.

Conforme configurado na Seccao B.1.2, o sistema oferece duas formas diferentes para um utilizador

autenticar-se. A primeira, o login local, requer que seja criada uma conta de utilizador manualmente (em

http://intranet.ipfn.tecnico.ulisboa.pt:8080/feng/bennu-admin/#/user-management/create)

e que esta conta de utilizador seja associada a um registo de membro (no Modulo de Membros). Esta

forma de autenticacao pode ser acedida atraves do URL http://intranet.ipfn.tecnico.ulisboa.

pt:8080/feng/login, e e a forma de autenticacao utilizada para autenticar usando a conta de administracao

criada durante a primeira configuracao do sistema. A segunda, o login pelo CAS do Tecnico, requer

que o utilizador tenha um TecnicoID, e que esse mesmo TecnicoID esteja associado a um registo de

membro (no Modulo de Membros). Esta forma de autenticacao pode ser acedida fazendo um pedido

POST para o URL http://intranet.ipfn.tecnico.ulisboa.pt:8080/feng/login/cas.

133

B.2 Atualizar o Sistema

Tal como na Seccao B.1, e assumido que a versao mais recente do codigo-fonte ja foi descarregada do

repositorio para a pasta /feng.

Para atualizar o sistema, basta executar os seguintes comandos:

$ cd ~/feng$ mvn clean install$ cd feng−webapp$ mvn clean package$ cp target/feng−webapp−1.0.0−SNAPSHOT.war /var/lib/tomcat7/webapps/feng.war$ service tomcat7 stop$ rm −r /var/lib/tomcat7/webapps/feng$ service tomcat7 start

B.3 Backups ao Sistema

Para garantir que nao haja perda de dados, e necessario realizar backups frequentes ao sistema. E

necessario incluir nos backups:

• Todas as entradas presentes na base de dados usada pelo sistema (configurada na Seccao B.1.1)

• Os logs gerados pelo sistema (presentes na(s) pasta(s) indicadas no ficheiro logback.xml, criado

na Seccao B.1.2)

• O diretorio de armazenamento (configurado na Seccao B.1.3)

Para recuperar os dados de backup, basta executar os seguintes passos:

1. Parar o sistema executando o seguinte comando:

$ service tomcat7 stop

2. Recuperar os dados de base de dados

3. Recuperar os logs gerados pelo sistema

4. Recuperar o diretorio de armazenamento

5. Voltar a iniciar o sistema executando o seguinte comando:

$ service tomcat7 start

B.4 Logs

O sistema utiliza SLF4J1 para registar todas as acoes tomadas pelos utilizadores. Esta biblioteca

permite a configuracao dos ficheiros de log, permitindo especificar a localizacao dos ficheiros, o formato1http://www.slf4j.org/

134

do nome dos ficheiros, as regras de rollover, e o formato das mensagens de log. Para isso, deve ser

criado um ficheiro logback.xml na pasta feng/feng-webapp/src/main/resources, cujo conteudo deve

seguir as instrucoes presentes em http://logback.qos.ch/manual/configuration.html.

Segue-se um exemplo do conteudo do ficheiro para uma correta configuracao dos logs:

1 <configuration>2 <appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">3 <file>/var/log/feng/logFile.log</file>4 <rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy">5 <!−− daily rollover −−>6 <fileNamePattern>7 /var/log/feng/archive/logFile.%d{yyyy−MM−dd}.%i.log8 </fileNamePattern>9 <maxFileSize>50MB</maxFileSize>

10 </rollingPolicy>1112 <encoder>13 <pattern>%d{HH:mm:ss.SSS} [%thread] %−5level %logger{36} − %msg%n</pattern>14 </encoder>15 </appender>1617 <root level="INFO">18 <appender−ref ref="FILE" />19 </root>20 </configuration>

Neste exemplo, sera criado o ficheiro de logs /var/log/feng/logFile.log, definido na linha 3. Tambem

sao definidas as regras de rollover entre as linhas 4 e 10. Os ficheiros de log sao arquivados em

/var/log/feng/archive diariamente (definido na linha 7), e, adicionalmente, sao arquivados sempre

que o ficheiro excede os 50MB (definido na linha 9). Outras regras de rollover podem ser definidas se-

guindo as instrucoes em http://logback.qos.ch/manual/appenders.html. De notar que estas regras

sao especıficas a classe especificada ao appender da linha 2.

Os ficheiros de log encontram-se em formato de texto, e portanto podem ser consultados abrindo-os

diretamente com qualquer editor de texto.

Todas as mensagens serao escritas com o formato indicado na linha 13. Segue-se um exemplo de

uma linha de log resultante do padrao indicado:

14:08:59.151 [http−bio−8080−exec−5] INFO p.u.t.i.f.m.s.SearchMemberService −[MEMBERS] User Ruben Marques (ist167944) searched for member with id’281767034486908’

Todas as diretorias indicadas no ficheiro logback.xml devem existir, e o Tomcat7 deve ter per-

missoes de leitura e escrita sobre essas pastas.

Alteracoes realizadas ao ficheiro de configuracao apenas terao efeito apos recompilar e reinstalar o

sistema, e reiniciar o Tomcat7.

135

136

Apendice C

Envio de Emails

De forma a informar os utilizadores de eventos importantes que tenham sucedido no sistema, este tem

a capacidade de enviar mensagens de email. Esta funcionalidade e proporcionada pelo modulo de

Messanging1 da Bennu Framework. Este modulo permite o envio de emails a utilizadores do sistema,

ou grupos de utilizadores. De notar que nao e permitido o envio de emails a um membro que nao tenha

associado uma conta de utilizador.

As mensagens de email sao enviados em ingles ou em portugues, dependendo da preferencia do

utilizador.

C.1 Configuracao

Para possıvel ao sistema enviar emails, e necessario configurar as definicoes de SMTP a serem usadas.

Estas definicoes, juntamente com outras configuracoes (detalhadas no Anexo B), encontram-se no

ficheiro feng/feng-webapp/src/main/resources/configuration.properties.

As definicoes de SMTP sao as seguintes:

1. mail.smtp.host, que deve apontar o host do servidor de SMTP a utilizar para enviar emails.

2. mail.smtp.name, que deve indicar o nome do host.

3. mail.smtp.port, que deve indicar o porto do servico SMTP.

Os seguintes valores sao indicados para o sistema utilizar o servidor de SMTP do IPFN:

• mail.smtp.host = smtp.ipfn.ist.utl.pt

• mail.smtp.name = smtp

• mail.smtp.port = 25

Para fazer alteracoes ao texto das mensagens de email, sera necessario fazer as alteracoes a classe

MailService presente na package service do respetivo modulo (por exemplo, para o modulo de assi-

duidade, sera a classe pt.ulisboa.tecnico.ipfn.feng.assiduity.service.MailAssiduityService).1https://confluence.fenixedu.org/display/BENNU/Messaging

137

Alteracoes realizadas ao ficheiro de configuracao ou as classes MailService apenas terao efeito

apos recompilar e reinstalar o sistema, e reiniciar o Tomcat7.

C.2 Eventos com Envio de Email

Nesta seccao serao listados, para cada modulo, que eventos resultam no envio de emails, e quais

os seus destinatarios. Em todos os casos, um membro e um utilizador que nao tem privilegios de

administracao sobre o modulo em questao, enquanto que um administrador e um utilizador que tem

privilegios de administracao sobre o modulo em questao.

Modulo de Membros

• Quando um administrador adiciona um novo membro, e enviado um email a todos os adminis-

tradores.

Modulo de Perfil de Membro

No modulo de Perfil de Membro nao existem eventos que resultem no envio de emails.

Modulo de Assiduidade

• Quando o sistema termina automaticamente uma presenca, e enviado um email ao membro

que deu inıcio a presenca.

• Quando um membro adiciona um pedido de marcacao, de alteracao, ou de ausencia, e envi-

ado um email a todos os administradores.

• Quando um administrador aprova um pedido de marcacao, de alteracao, ou de ausencia, e

enviado um email ao membro que adicionou o pedido.

• Quando um administrador rejeita um pedido de marcacao, de alteracao, ou de ausencia, e

enviado um email ao membro que adicionou o pedido.

Modulo de Missoes

No modulo de Missoes nao existem eventos que resultem no envio de emails.

Modulo de Tickets de Suporte

• Quando um membro adiciona um ticket de suporte, e enviado um email a todos os administra-

dores.

• Quando um administrador marca um ticket de suporte como em progresso, e enviado um

email ao membro que adicionou o ticket.

138

• Quando um administrador marca um ticket de suporte como completo, e enviado um email ao

membro que adicionou o ticket.

• Quando um administrador marca um ticket de suporte como pendente, e enviado um email ao

membro que adicionou o ticket.

• Quando um membro ou um administrador adiciona um comentario a um ticket de suporte, e

enviado um email ao membro que adicionou o ticket e a todos os administradores.

• Quando um administrador adiciona um comentario interno a um ticket de suporte, e enviado

um email a todos os administradores.

Modulo de Rede Informatica

• Quando um membro adiciona um pedido de endereco IP, e enviado um email a todos os admi-

nistradores.

• Quando um administrador aprova um pedido de endereco IP, e enviado um email ao membro

que adicionou o pedido.

• Quando um administrador rejeita um pedido de endereco IP, e enviado um email ao membro

que adicionou o pedido.

• Quando um membro renova um pedido de endereco IP, e enviado um email a todos os admi-

nistradores.

• Quando um membro abandona um pedido de endereco IP, e enviado um email a todos os

administradores.

• Quando um administrador termina um pedido de endereco IP, e enviado um email ao membro

que adicionou o pedido.

Modulo de Projetos

• Quando um administrador associa um membro a um projeto, e enviado um email ao membro

que foi associado.

• Quando um administrador desassocia um membro de um projeto, e enviado um email ao mem-

bro que foi desassociado.

• Quando um administrador promove um membro para lıder de um projeto, e enviado um email

ao membro que foi promovido.

• Quando um administrador despromove um membro lıder de um projeto, e enviado um email

ao membro que foi despromovido.

• Quando um administrador fecha um projeto, e enviado um email a todos os membros associados

a esse projeto.

139

• Quando um administrador abre um projeto fechado, e enviado um email a todos os membros

associados a esse projeto.

Modulo de Grupos de Investigacao

• Quando um administrador associa um membro a um grupo de investigacao, e enviado um

email ao membro que foi associado.

• Quando um administrador desassocia um membro de um grupo de investigacao, e enviado

um email ao membro que foi desassociado.

• Quando um administrador promove um membro para responsavel de um grupo de investigacao,

e enviado um email ao membro que foi promovido.

• Quando um administrador despromove um membro responsavel de um grupo de investigacao,

e enviado um email ao membro que foi despromovido.

• Quando um administrador elimina um grupo de investigacao, e enviado um email a todos os

membros associados a esse projeto.

Modulo de Notıcias

• Quando um editor submete uma notıcia para aprovacao, e enviado um email a todos os admi-

nistradores.

• Quando um administrador aprova uma notıcia, e enviado um email ao editor que adicionou a

notıcia.

• Quando um administrador rejeita uma notıcia, e enviado um email ao editor que adicionou a

notıcia.

Modulo de Inventario

• Quando um administrador cancela uma reserva, e enviado um email ao membro que adicionou

a reserva.

• Quando um membro adiciona um pedido de cancelamento de reserva, e enviado um email a

todos os administradores.

• Quando um administrador responde a um pedido de cancelamento de reserva, e enviado um

email ao membro que adicionou o pedido.

140

Apendice D

Questionario

A avaliacao qualitativa consistiu na realizacao de um questionario que utilizadores responderam apos

a interacao com o sistema. O questionario usado e apresentado abaixo.

141

Questionnaire on the usability of the new IntranetThank you for taking part in testing the new Intranet!Before concluding this session, we still need you to answer the following questions.

* Required

Personal Data

1. What is your age? *

2. What kind of device(s) will you use frequently to access the Intranet? *Check all that apply.

 Desktop

 Laptop

 Tablet

 Smartphone

 Other: 

3. Which modules of the new Intranet will you use more often? *Check all that apply.

 Assiduity

 Inventory

 Investigation Groups

 Member Profile

 Members

 Missions

 Network

 News

 Projects

 Support Tickets

A series of 10 sentences will be provided below. For each one,please indicate your level of agreement.Please record their immediate response to each item, rather than thinking about items for a long time.All items should be checked. If you feel that they cannot respond to a particular item, please mark the centre point of the scale.

4. I think I would like to use this system frequently. *Mark only one oval.

1 2 3 4 5

Strongly disagree Strongly agree

5. I found the system unnecessarily complex. *Mark only one oval.

1 2 3 4 5

Strongly disagree Strongly agree

6. I thought the system was easy to use. *Mark only one oval.

1 2 3 4 5

Strongly disagree Strongly agree

7. I think that I would need the support of a technical person to be able to use this system. *Mark only one oval.

1 2 3 4 5

Strongly disagree Strongly agree

8. I found the various functions in this system were well integrated. *Mark only one oval.

1 2 3 4 5

Strongly disagree Strongly agree

9. I thought there was too much inconsistency in this system. *Mark only one oval.

1 2 3 4 5

Strongly disagree Strongly agree

10. I would imagine that most people would learn to use this system very quickly. *Mark only one oval.

1 2 3 4 5

Strongly disagree Strongly agree

11. I found the system very cumbersome to use. *Mark only one oval.

1 2 3 4 5

Strongly disagree Strongly agree

Powered by

12. I felt very confident using the system. *Mark only one oval.

1 2 3 4 5

Strongly disagree Strongly agree

13. I needed to learn a lot of things before I could get going with this system. *Mark only one oval.

1 2 3 4 5

Strongly disagree Strongly agree

Additional commentsIf you have any additional comments you'd like to share, please use the following text box.

14.  

 

 

 

 

Thank you for your time!