Upload
others
View
0
Download
0
Embed Size (px)
Citation preview
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 [email protected].
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!