geração (semi)automática de metadados - Universidad Autónoma ...

ISBN: 978–972–8924–45-4 © 2007 IADIS
2. SISTEMA DE GESTÃO DE PROJECTOS DESENVOLVIDO
No âmbito do projecto exposto apresentado neste artigo, foi seguida uma lista de objectivos a atingir. Se por
um lado estes objectivos não eram vinculativos por outro serviam de base e de ponto de partida em direcção
ao que se pretendia alcançar. Os objectivos inicialmente estipulados foram, em traços gerais, a criação de um
Portal WEB que permitisse a gestão e divulgação dos Projectos dos alunos das áreas tecnológicas da UTAD
garantindo para isso um mecanismo de autenticação, interfaces gráficas simples e intuitivas, construção da
respectiva base de dados relacional que serviria de suporte à aplicação, definição de perfis de utilizadores,
desenvolvimento do processo automático de candidaturas assim como a atribuição automática dos mesmos.
Para cumprir esta lista de objectivos foram planeadas e desenvolvidas três fases do projecto. A primeira foi a
fase de análise de requisitos, a segunda a criação e validação de uma base de dados e a terceira a criação e
implementação das interfaces gráficas para os diferentes tipos de utilizadores. Foi ainda ponderada uma
quarta fase para o projecto estando esta direccionada para testes e correcção de erros da aplicação
desenvolvida podendo ainda proceder-se à integração da aplicação no SIDE, Sistema de Informação de
Apoio ao Ensino, sistema este largamente implementado e utilizado por toda a comunidade académica da
UTAD. Para o desenvolvimento da fase de análise de requisitos decidiu-se que a melhor solução de
modulação seria o desenvolvimento de Diagramas de Casos de Uso e a sua respectiva especificação. Desta
forma foi possível identificar com grande grau de certeza todos os possíveis utilizadores do sistema assim
como o tipo de acções que estes poderiam eventualmente vir a efectuar sobre o mesmo. O sistema a
desenvolvido foi então dividido em duas partes diferenciadas de acordo com o nível de privilégios de cada
utilizador. Assim os diagramas de casos de usos criados foram distinguidos em BackOffice e FrontOffice.
Foi ainda definido um quarto tipo de actor ligado ao BackOffice que seria o actor tempo. Este actor seria
despoletado automaticamente e seria associado a processos mais automáticos do sistema como fechar ou
abrir as épocas de inscrição ou candidaturas para os projectos ou ainda a emissão automática de avisos para
os outros actores sobre datas e prazos. Relativamente ao FrontOffice estipulou-se que este apenas
apresentaria um único actor, sendo este o utilizador que faltava para completar o quadro, o utilizador aluno.
O utilizador aluno é um tipo de utilizador com privilégios mais limitados e sem grande possibilidade de
introdução e edição de conteúdos no sistema a não ser sobre pontos que lhe estivessem directamente ligados
como os seus dados pessoais. Foram ainda tidas em conta questões de segurança. Nesse sentido foi decidido
que o utilizador não teria a possibilidade de alterar a sua password, esta era-lhe atribuída pelo administrador
do sistema e apenas entidade possui a capacidade de recuperar e alterar as respectivas passwords. Na
realidade em sistemas de informação deste género, leia-se um sistema mais fechado e altamente direccionado
para um tipo de utilizadores muito específicos, não é muito comum a permissão da alteração da palavrachave.
Tal facto também acontece no sistema a desenvolver. Na prática a funcionalidade foi desenvolvida
mas não se encontra acessível ao utilizador aluno, apenas ao administrador geral do sistema. Assim sempre
que a acção alteração de palavra-chave for invocada é devolvido um aviso que alerta o utilizador sobre a
indisponibilidade deste serviço pedindo que contacte o administrador do sistema. Estando o sistema
modelado e todos os casos de usos especificados passou-se à fase de desenvolvimento da Base de Dados de
suporte. Neste âmbito começou-se por desenvolver um modelo de ER, Entidade-Relacionamentos. Este
modelo permitiu adquirir uma visão geral sobre o sistema assim como uma percepção mais real da Base de
Dados a criar. Após se ter normalizado todo o ER procedeu-se à implementação da BD. Neste processo há a
realçar a possibilidade de um mesmo utilizador poder assumir vários perfis, a título de exemplo pode
apresentar-se o caso de um aluno de doutoramento poder ser um docente de uma cadeira. Por conseguinte e
para evitar duplicação de dados criou-se um conjunto de triggers que permitem validar a introdução de novos
perfis de utilizadores no sistema. Terminada esta fase seguiu-se para a fase de desenvolvimento das
Interfaces Gráficas. Neste âmbito e visto existir a possibilidade de uma futura integração da aplicação num
sistema já completamente desenvolvido foi estipulado que as interfaces deveriam ser o mais idênticas
possíveis às do SIDE. Assim desenvolveu-se um conjunto de interfaces simples e acessíveis onde o tema
predominante foi sempre constante ao longo de toda a navegação privilegiando o estilo e aparência do SIDE.
O sistema desenvolvido culminou num Portal WEB cujos principais benefícios para a comunidade académica
passam por tornar todo o processo de candidaturas, por parte dos alunos, ao projectos de cursos muito mais
simples e rápidos. A aplicação é responsável por toda a gestão dos conteúdos relacionados com os projectos
de cursos desde a recepção das propostas para projectos por parte dos docentes, publicação das mesmas,
recepção das candidaturas a projectos pelos alunos, atribuição automática dos projectos a alunos ou grupos de
438