Maizer Aly de Oliveira Gomes

Concepção e Implementação do módulo de Inscrição Online para Estudantes – estudo

da Direcção de Registo Académico da Universidade Pedagógica

Licenciatura em Ensino de Informática

Universidade Pedagógica

Maputo

2016
 Maizer Aly de Oliveira Gomes

Concepção e Implementação do módulo de Inscrição Online para Estudantes - estudo

da Direcção de Registo Académico da Universidade Pedagógica

Monografia Científica apresentada ao

Departamento de Informática, Escola Superior
Técnica, para obtenção do grau académico de
Licenciatura em Ensino de Informática.

Supervisor:

M. Sc. Eugénio Macumbe

Universidade Pedagógica

Maputo

2016
 i

Índice

Lista de Tabelas ....................................................................................................................... iv

Lista de Figuras ........................................................................................................................ v

Lista de Abreviaturas .............................................................................................................. vi

Declaração de Honra ..............................................................................................................vii

Dedicatória .............................................................................................................................viii

Agradecimentos ....................................................................................................................... ix

Resumo ...................................................................................................................................... x

Abstract .................................................................................................................................... xi

Capítulo I: Introdução ............................................................................................................. 1

Enquadramento ............................................................................................................ 1

Contextualização .......................................................................................................... 1

Justificativa .................................................................................................................. 2

Formulação do problema ............................................................................................. 2

Questões de Pesquisa ................................................................................................... 4

Hipóteses ...................................................................................................................... 4

Objectivos .................................................................................................................... 5

1.7.1. Objectivo geral ..................................................................................................... 5

1.7.2. Objectivos específicos .......................................................................................... 5

Metodologia ................................................................................................................. 5

1.8.1. Metodologia de pesquisa ...................................................................................... 6

1.8.2. Metodologia de desenvolvimento do sistema proposto ........................................ 6

Estrutura do trabalho .................................................................................................... 7

Capítulo II: Revisão Bibliográfica .......................................................................................... 9

Dados ........................................................................................................................... 9

Informação ................................................................................................................... 9

Tecnologias de Informação ........................................................................................ 10

 ii

Software ..................................................................................................................... 10

2.4.1. Software Livre (Open Source) ............................................................................ 10

2.4.2. Licença de Software............................................................................................ 11

Internet ....................................................................................................................... 12

2.5.1. Web..................................................................................................................... 13

Sistema de Informação ............................................................................................... 15

2.6.1. Tipos de Sistemas de Informação ....................................................................... 15

2.6.2. Planeamento de Recursos Empresariais (ERP) .................................................. 16

2.6.3. Sistema Integrado vs. Descentralizado ............................................................... 17

Linguagem de Programação ...................................................................................... 18

2.7.1. PHP ..................................................................................................................... 19

2.7.2. Javascript ............................................................................................................ 19

2.7.3. HTML ................................................................................................................. 20

Base de dados ............................................................................................................. 20

2.8.1. Sistema de Gestão de Base de dados (SGBD) .................................................... 20

2.8.2. Base de dados relacional..................................................................................... 21

Controle de versão ..................................................................................................... 22

2.9.1. GIT ..................................................................................................................... 23

Homestead .............................................................................................................. 23

Padrão de desenho (Design Pattern) ...................................................................... 23

2.11.1. Padrão Model-View-Controller (MVC) ......................................................... 24

Metodologia de Desenvolvimento de Software ..................................................... 25

2.12.1. Relational Unified Process (RUP) .................................................................. 26

2.12.2. Unified Modeling Language (UML) .............................................................. 30

Requisitos de um Sistema ...................................................................................... 32

Capítulo III: Estudo do caso proposto.................................................................................. 33

Breve Historial ........................................................................................................... 33

 iii

Missão da UP ............................................................................................................. 34

A Direcção de Registo Académico ............................................................................ 34

3.3.1. Actividades do sector.......................................................................................... 34

3.3.2. Organização ........................................................................................................ 35

Descrição do Sistema actual ...................................................................................... 36

3.4.1. Sistema de Gestão da Universidade Pedagógica (SIGEUP) .............................. 36

3.4.2. Inscrição dos Estudantes ..................................................................................... 39

Capítulo IV: Concepção e Implementação do Módulo de Inscrição Online ..................... 42

Concepção do módulo de inscrição online ................................................................ 42

4.1.1. Requisitos funcionais.......................................................................................... 42

4.1.2. Requisitos não funcionais ................................................................................... 43

4.1.3. Casos de Uso ...................................................................................................... 43

4.1.4. Diagramas de Sequência ..................................................................................... 46

4.1.5. Modelo de Entidade-Relacionamento ................................................................ 47

4.1.6. Dicionário de Dados ........................................................................................... 48

4.1.7. Diagrama de instalação ....................................................................................... 49

4.1.8. Ambiente de desenvolvimento ........................................................................... 49

Testes do Sistema....................................................................................................... 49

Implementação do Módulo de inscrição online ......................................................... 50

Capítulo V: Conclusão ........................................................................................................... 52

Considerações Finais ................................................................................................. 52

Limitações .................................................................................................................. 52

Recomendações ......................................................................................................... 53

Referências Bibliográficas ..................................................................................................... 54

Glossário .................................................................................................................................. 56

Anexos ...................................................................................................................................... 58
 iv

Lista de Tabelas

Tabela 1: Detalhes dos workflows do RUP ............................................................................. 29

Tabela 2: Número de estudantes inscritos na UP por delegação em 2015. ............................. 33
Tabela 3: Diagrama de MER ................................................................................................... 47
Tabela 4: Dicionário das tabelas ............................................................................................. 48
Tabela 6: Dicionários dos campos das tabelas ........................................................................ 59
Tabela 7: Diagrama de casos de uso ....................................................................................... 62
 v

Lista de Figuras

Figura 1: Dados vs. Informação ................................................................................................ 9

Figura 2: Requisição de uma página WEB ............................................................................. 13
Figura 3: Principais ERPs ....................................................................................................... 16
Figura 4: Sistema Descentralizado .......................................................................................... 17
Figura 5: Sistema Centralizado (ERP) .................................................................................... 18
Figura 6: Fluxo de requisições no padrão MVC ..................................................................... 25
Figura 7: Ciclo do desenvolvimento Utilizando RUP ............................................................. 29
Figura 8: Resumo dos elementos de estrutura ......................................................................... 30
Figura 9: Resumo dos elementos de comportamento, agrupamento e anotação ..................... 31
Figura 10: Resumo dos tipos de relações standard ................................................................. 31
Figura 11: Organigrama da DRA ............................................................................................ 35
Figura 12: Diagrama de sequência - Inscrição ........................................................................ 46
Figura 13: Diagrama de sequência - Cancelar Inscrição ......................................................... 46
Figura 14: Diagrama de sequência: Importar Pagamentos...................................................... 47
Figura 15: Diagrama de Instalação .......................................................................................... 49
Figura 16: Esquema de deployment da aplicação .................................................................... 50
Figura 17: Interface de Login .................................................................................................. 65
Figura 18: Menu para Inscrição .............................................................................................. 65
Figura 19: Activação da conta ................................................................................................. 66
Figura 20: Confirmação do envio de email ............................................................................. 66
Figura 21: Email de confirmação ............................................................................................ 67
Figura 22: Mensagem de confirmação .................................................................................... 67
Figura 23: Escolha das disciplinas normais ............................................................................ 68
Figura 24: Escolha das cadeiras em atraso .............................................................................. 68
Figura 25: Obter factura .......................................................................................................... 68
Figura 26: Relatório para pagamento ...................................................................................... 69
Figura 27: Importação do ficheiro do banco ........................................................................... 69
Figura 28: Confirmação da importação ................................................................................... 69
Figura 29: Email de confirmação da inscrição ........................................................................ 70
 vi

Lista de Abreviaturas

CIUP – Centro de Informática da Universidade Pedagógica

CSS – Cascade Style Sheet

DEV - Development

DRA – Direcção do Registo Académico

EAD – Ensino à distância

ERP – Enterprise Resource Planning

GPL - General Public License

HTTP – Hyper Text Transfer Protocol

HTML – Hyper Text Markup Language

JSON – Javascript Object Notation

MVC – Model View Controller

PHP – Hyper Text Preprocessor

POO – Programação Orientada à Objectos

PgSQL - PostgreSQL

PDF - Portable Document File

PC – Personal Computer

RUP - Rational Unified Process

SGBD – Sistema de Gestão de Base de Dados

SIGEUP – Sistema de Gestão da Universidade Pedagógica

UML - Unified Modelling Language

UP – Universidade Pedagógica

URL - Uniform Resource Locators

WWW – World Wide Web

 vii

Declaração de Honra

Declaro que esta Monografia é resultado da minha investigação pessoal e das orientações do
meu supervisor, o seu conteúdo é original e todas as fontes consultadas estão devidamente
mencionadas no texto, nas notas e na bibliografia final.

Declaro ainda que este trabalho não foi apresentado em nenhuma outra instituição para
obtenção de qualquer grau académico.

Maputo, _____ de ______________________ de _______

Maizer Aly de Oliveira Gomes

______________________________________
 viii

Dedicatória

Em memória à minha querida mãe Sureia Ibrahimo Aly.

 ix

Agradecimentos

Em primeiro lugar, agradeço a Deus pelo dom da vida e pela oportunidade de chegar a este
estágio académico.

Especial agradecimento ao meu supervisor Mestre Eugénio Macumbe, Engenheira Elena

Magumane e Mestre Sheila Rangel pela dedicação na realização deste trabalho, que sem a
importante ajuda não teria sido concretizado.

Endereço, igualmente, um agradecimento especial ao meu pai, Horácio Pavia de Oliveira

Gomes, como reconhecimento pelos seus esforços para a minha formação desde o ensino
primário até ao ensino superior.

Agradeço, particularmente, a minha noiva e companheira de todos os momentos, Natércia da

Conceição Cumbe, pelas horas que me ouvia falar sobre assuntos de informática, por se embalar
nas minhas análises e partilhar ideias.

Agradeço também a todos que directa ou indirectamente contribuíram para que pudesse
alcançar este patamar na vida, entre eles meus familiares, colegas da turma de 2009 e colegas
de trabalho.
 x

Resumo
Esta monografia científica é o resultado do requisito para o término do curso de Licenciatura
em Ensino de Informática e tem como tema “Concepção e Implementação do módulo de
Inscrição Online para Estudantes” e como caso de estudo a “Direcção de Registo
Académico da UP1”.
A temática em estudo centraliza-se na concepção de um módulo, usando as Tecnologias de
Informação e Comunicação, para a inscrição de estudantes na Universidade Pedagógica em
uma base de dados central e ao mesmo tempo permitir que o próprio estudante faça a sua
inscrição sem que, para isso, tenha que se deslocar até a instituição, evitando assim, longas filas
de espera para a inscrição e dando maior comodidade aos estudantes.
No presente trabalho, será feita uma descrição dos métodos usados para estender o sistema de
gestão usado nesta universidade através deste módulo, com intuito de melhorar os serviços
prestados pela instituição.
O sistema foi desenvolvido usando a linguagem PHP como back-end, Javascript no lado do
cliente e HTML para gerar os formulários de interação, em conexão à uma base de dados
PostgresSQL. Outras ferramentas auxiliares usadas: Git, PL/SQL, Composer, Twitter
Bootstrap.

Palavras-chave: ERP, Open Source, Programação Web, Sistema de Informação.

1
UP – Universidade Pedagógica
 xi

Abstract
This scientific work entitled “Design and Implementation of the Student’s Online
Enrollment module” is a requisite for the obtaining of the Degree in Computer Science
Teaching and has as a study case the “Academic Registry Department of UP”.
The study focuses on the design of a module for student’s enrollment at the Pedagogical
University using a central database and in the same time allow the student itself to do its own
enrollment without the need of going to the institution, thus avoiding long queues for
registration and giving greater convenience to students.
The system was developed using the PHP language as back-end, Javascript in the client side
and HTML to generate the user forms, in connection to a PostgreSQL database. Other auxiliary
tools used: Git, PL/SQL, Composer, Twitter Bootstrap.

Keywords: ERP, Open Source, Web Programming, Information System.

 1

Capítulo I: Introdução

Enquadramento

Nas últimas duas décadas, computadores e tecnologia tem revolucionado os processos,

salvando tempo e dinheiro das indústrias em formas nunca antes possíveis. Com a crise
económica actual, instituições de ensino procuram formas de usar computadores e a internet
para simplificar os seus processos enquanto diminuem, substancialmente, os seus gastos (In
School Business Affairs, 2011). O processo de inscrições pode tornar-se um dos processos que
mais consome recursos durante o ano, quer em termos de pessoal, infraestruturas, tempo e de
materiais, mostrando-se, assim, como um dos aspectos que mais carece soluções informáticas
de forma a tornar este processo (ainda) mais eficiente.

Este trabalho científico intitulado “Concepção e Implementação de um módulo de Inscrição

Online para Estudantes” é elaborado no âmbito da obtenção do grau de Licenciatura em Ensino
de Informática. Nele, serão tratados aspectos relevantes sobre o sistema já existente na Direcção
de Registo Académico (SIGEUP) e para a concepção de um módulo de inscrição, onde o
estudante poderá fazer a sua própria inscrição de disciplinas e o respectivo pagamento através
de um sistema de interface intuitiva, segura e de alta disponibilidade, sem para isso ter que se
deslocar à instituição, proporcionando uma maior comodidade ao estudante, principalmente aos
que possuem pouca disponibilidade de deslocação aos locais de inscrição, como por exemplo
os que frequentam no regime à distância.

Contextualização

A Universidade Pedagógica, inicialmente Instituto Superior Pedagógico (ISP), é uma

instituição pública de ensino superior que conta com um universo de mais de quarenta e cinco
mil estudantes activos do regime diurno, pós-laboral, semi-presencial e a distância (Fonte:
Direcção de Registo Académico, 2015) e possui infraestruturas em todas as províncias do país.
Neste momento, está num processo de expansão no número infraestruturas e,
consequentemente, no número de estudantes, cursos, docentes, etc. Esta expansão, reflectida
directamente no número de estudantes, acaba incidindo sobre os sectores administrativos
directamente ligados à gestão destes, conduzindo à dificuldades em termos de gestão,
atendimento, infraestruturas e custos.
 2

Para Guimarães (2000), os administradores utilizam, cada vez mais, as tecnologias de

informação como ferramentas de suporte às suas actividades. Os estudos sobre o uso de
sistemas de informação gerenciais por parte dos administradores se concentram em
organizações do sector privado. A pesquisa realizada por Guimarães em uma Pró-Reitoria de
uma Universidade constata exactamente a necessidade do uso de sistemas de informações por
parte dos gerentes universitários como ferramenta de trabalho e de apoio a decisões nos serviços
públicos, principalmente em Universidade.

Face a este cenário, há a necessidade da melhoria dos serviços prestados e racionalização dos
seus recursos, fazendo assim a optimização da sua gestão.

Ao optar pelo atendimento público através de um sistema informático, a UP estará a dar campo
à uma gestão eficaz, em busca de maior produtividade, melhoria dos serviços prestados e
racionalização de recursos para atender cada vez melhor os estudantes. Por esta razão, a
implementação de um sistema de inscrição online acaba tornando-se uma possível solução para
a atender comodamente o crescente número de estudantes que procura os serviços prestados
pela instituição.

Justificativa

A escolha deste tema tem origem no facto do autor do mesmo ser funcionário da Universidade
Pedagógica afecto na Direcção do Registo Académico em Maputo, direcção responsável pela
gestão dos estudantes da UP a nível nacional, e observar, na primeira pessoa, as dificuldades
enfrentadas durante o processo de inscrição de disciplinas devido ao reduzido número de
funcionários em contraste ao número de estudantes, além de já ter feito parte do corpo estudantil
desta instituição de ensino que semestralmente procurava a DRA a fim de regularizar a sua
situação académica.

Formulação do problema

No início de cada semestre lectivo, os estudantes da UP dirigem-se ao registo académico,

durante o seu horário de funcionamento, da sua respectiva delegação para que possam efectuar
a sua inscrição nas disciplinas que vão frequentar. No caso da DRA (UP-Sede), esta encerra as
suas demais actividades durante este período e desloca-se, temporariamente, para outro espaço
maior (Campus de Lhanguene) de forma a poder atender os estudantes (um pouco mais de dez
 3

mil estudantes, fonte: DRA, 2015) pois as suas instalações na UP-sede não são capazes de
albergar este número de estudantes no período estabelecido para as inscrições.

A inscrição em disciplinas dos estudantes da UP, a nível nacional, é feita dentro do Sistema de
Gestão Universitária da Universidade Pedagógica (SIGEUP), sistema este que entrou em
funcionamento no ano de 2013 com o nome eDondzo adotando mais tarde em 2014 o nome
actual. O SIGEUP é um Sistema Integrado de Gestão Universitária que engloba diversos
módulos destinados à gestão de sectores pertinentes da UP, conectados através de uma base de
dados única. Esta aplicação é baseada em Open Source, possui uma estrutura modular com o
acesso dentro de um ambiente Web através de um navegador. A inscrição é feita pelos
funcionários do registo académico selecionados para esta função. Essa selecção é feita através
de um módulo de permissões gerido pelos administradores do sistema.

O processo de inscrição consiste, basicamente, em o estudante primeiramente consultar o valor

que deve depositar pela inscrição, que vai de acordo com o número de disciplinas a frequentar,
seguido pelo depósito desse valor dentro do banco, na respectiva conta do registo académico e
por fim a apresentação do recibo de depósito e do cartão de estudante (ou outro documento de
identificação) ao funcionário do registo académico. Após isto, o funcionário faz o registo do
recibo no SIGEUP seguido pela inscrição nas disciplinas pretendidas e por fim a impressão do
recibo da inscrição onde são impressas duas cópias ficando uma com o estudante e a outra no
registo académico, onde se anexa o recibo do depósito.

O que tem-se observado durante este processo são enchentes devida a demora no atendimento
que tem várias causas como origem: falta de acesso à internet, lentidão da rede, equipamentos
danificados (PC’s, impressoras, switches, etc.). Apesar das tentativas de organização dos
estudantes por faculdade em que cada faculdade teria um período específico para inscrição e
optar-se por espaços maiores para instalação da DRA, as enchentes prevalecem. Outro ponto
que tem sido observado é em relação aos estudantes do EAD que não se encontram a residir
dentro da cidade de Maputo ou então trabalham fora da cidade sendo este, muitas das vezes, o
motivo por optarem por este regime de frequência. Muitos acabam perdendo o período de
inscrições pela falta de disponibilidade para se deslocar aos locais onde estas decorrem. Além
disso, o SIGEUP não possui uma ferramenta para o controle de precedências, ficando essa
função a cargo do funcionário que normalmente não possui acesso a estas informações ou que,
por um ou outro motivo, acaba cometendo erros. Outro ponto concerne o arquivo desses recibos
de depósito que chegam a ser um constrangimento pois ocupam largos espaços chegando a
ameaçar a saúde dos próprios funcionários, pois, acabam sendo armazenados nos próprios
 4

locais de trabalho por falta de espaços para o seu arquivo, para além dos custos em termos de
aquisição dos recursos materiais necessários para a concretização das inscrições (papel,
impressoras, tinteiros, etc.) e humanos.

Partindo destas dificuldades surge a necessidade da concepção de uma solução para estes
problemas enfrentados pela DRA, em particular, e o registo académico da UP no geral, sendo
proposto um sistema electrónico de fácil acesso e interface amigável em que os dados são
validados automaticamente e armazenados em uma base de dados, podendo reduzir, desta
forma, possíveis erros humanos, custo em recursos materiais e frustrações por parte dos
estudantes.

Questões de Pesquisa

 Qual seria a melhor solução para criar um sistema de atendimento público de alta
disponibilidade e grande abrangência?
 Que soluções se demonstram mais viáveis para a concepção de um sistema de
inscrições?
 Em que aspectos iria a implementação de um sistema de inscrição online beneficiar a
DRA?

Hipóteses

 Através de um aplicação web, os estudantes poderão fazer a sua própria inscrição através
de qualquer ponto com ligação à internet à qualquer hora do dia e em qualquer dia da
semana.
 O uso de tecnologias Open Source no desenvolvimento de sistemas tornará económico
o processo de concepção do sistema, pois, não acarretará custos adicionais.
 O uso de um sistema de inscrição online irá ter os seguintes benefícios:
 Diminuição da carga de actividades sobre a DRA, permitindo mais tempo para
realização de outras actividades;
 Informatização do arquivo da DRA constituído por recibos de depósitos de
pagamento;
 Permitirá uma melhor implementação do regulamento académico em vigor na UP,
minimizando erros humanos;
 5

 Redução de custos em recursos materiais e humanos;

Objectivos

1.7.1. Objectivo geral

 Conceber e Implementar um módulo de inscrição de disciplinas Online para os

estudantes da Universidade Pedagógica baseado em tecnologias Open Source, tendo
como foco o aumento da comodidade e garantia da integridade deste processo.

1.7.2. Objectivos específicos

 Fazer um estudo sobre tecnologias e ferramentas Open Source que poderiam ser
utilizados na concepção e implementação do módulo de inscrição proposto;
 Analisar o processo actual de inscrição dos estudantes na UP;
 Propor métodos de segurança, validação e integridade do processo de inscrição online,
seguindo as normas do regulamento académico da UP;
 Conceber e apresentar uma proposta de implementação do sistema de inscrição online.

Metodologia

Segundo Prodanov & Freitas (2013), a investigação científica depende de um conjunto de

procedimentos intelectuais e técnicos para que seus objetivos sejam atingidos: os métodos
científicos. A Metodologia, em um nível aplicado, examina, descreve e avalia métodos e
técnicas de pesquisa que possibilitam a colecta e o processamento de informações, visando ao
encaminhamento e à resolução de problemas e/ou questões de investigação.

Método científico é o conjunto de processos ou operações mentais que devemos empregar na

investigação. É a linha de raciocínio adotada no processo de pesquisa.

De forma a poder-se alcançar os objectivos do trabalho, será usada uma metodologia de

pesquisa assim como uma metodologia de desenvolvimento do sistema que serão descritas ao
longo deste ponto.
 6

1.8.1. Metodologia de pesquisa

i. Do ponto de vista da sua natureza

O presente trabalho quanto à sua natureza é classificado como sendo uma Pesquisa
Aplicada pois objetiva gerar conhecimentos para aplicação prática dirigidos à solução de
problemas específicos. Envolve verdades e interesses locais (PRODANOV & FREITAS,
2013).

ii. Do ponto de vista dos procedimentos técnicos

Quanto aos procedimentos técnicos, ou seja, a maneira pela qual obtivemos os dados
necessários para a elaboração da pesquisa, foram usados os seguintes métodos:
 Pesquisa bibliográfica;
 Levantamento;
 Pesquisa participante.

iii. Do ponto de vista da forma de abordagem do problema

Partindo da natureza do trabalho em que o ambiente de trabalho é a fonte directa dos dados
e que o autor mantém contacto directo com o ambiente e o objecto de estudo em questão, a
pesquisa terá uma abordagem qualitativa, porém, dados quantitativos também foram
levados em consideração. O desafio da pesquisa qualitativa é apreender, sob a óptica
daqueles que participam do universo pesquisado, o sentido da experiência vivenciada.

1.8.2. Metodologia de desenvolvimento do sistema proposto

i. Metodologia de desenvolvimento

Para concepção do sistema será utilizada a metodologia Rational Unified Process (RUP),
criada para apoiar o desenvolvimento orientado a objetos, fornecendo uma forma
sistemática para se obter vantagens no uso da UML.
 7

ii. Técnica de modelação

A técnica de modelação é a UML, uma linguagem de modelação visual que é usada para
especificar, visualizar, construir e documentar artefactos de um software de sistema
(Almeida, 2005).

iii. Linguagens de programação

O objectivo deste trabalho é propor a concepção de um sistema para trabalhar com custo
zero de licença de software. No servidor seria utilizado o sistema operativo Linux e a base
de dados PostgreSQL. A linguagem de programação seria o PHP. Todos sob licença GPL,
ou seja, de livre distribuição e cópia. O acesso ao sistema poderá ser feito através de
qualquer sistema operativo, desde que possua um navegador de internet, tornando-se, assim,
num sistema multiplataforma.

Estrutura do trabalho

Este trabalho encontra-se disposto em cinco (5) capítulos:

 Capítulo I: Introdução - Neste capítulo é apresentada a introdução do trabalho dando

uma pequena explanação da presente situação de funcionamento do departamento em
estudo, a justificativa, a formulação do problema, as questões de pesquisa, os objectivos
do trabalho, as hipóteses e as metodologias.

 Capítulo II: Revisão Bibliográfica – Neste capítulo são apresentados, a fundo, os

conceitos relacionados com o desenvolvimento do sistema proposto: as metodologias
de desenvolvimento e as tecnologias usadas.

 Capítulo III: Estudo do caso proposto – Neste capítulo é feita uma apresentação mais
detalhada da direcção em estudo, os sistemas informáticos usados actualmente, o
processo de inscrição dos estudantes tendo em conta aspectos económicos, de
comodidade, tempo, segurança e infraestruturas.
 8

 Capítulo IV: Concepção e Implementação do Módulo de Inscrição Online – Neste

capítulo são apresentados os resultados do desenvolvimento do projecto em causa e os
testes executados no sistema.

 Capítulo V: Conclusão – Neste capítulo final são apresentadas as conclusões e

recomendações.
 9

Capítulo II: Revisão Bibliográfica

A revisão de literatura é imprescindível para a elaboração de um trabalho científico. Para

Trentini e Paim (1999) o estímulo ao pensamento e a definição de um problema de investigação
de caráter científico têm como ponto de partida e de chegada a revisão de literatura sobre o
tema. Os mesmos autores defendem que a revisão da literatura ocupa a posição introdutória do
projecto e, portanto, decide as bases intelectuais em que alógica da pesquisa está sendo
estruturada

Neste capítulo serão apresentados os conceitos relacionados com o tema escolhido como, por
exemplo, sistemas de informação e a sua classificação, sistemas de gestão de base de dados e
seus tipos, linguagens de programação e metodologias para desenvolvimento de softwares.

Dados

Segundo Stair (2008), dados são fatos básicos, como o nome e a quantidade de horas
trabalhadas em uma semana de um funcionário, números de peças em estoque ou pedidos.

Informação

É o conjunto de fatos organizados de modo a terem valor adicional, além do valor dos fatos
propriamente ditos, segundo Stair (2008).

Figura 1: Dados vs. Informação

Fonte: (MELO, I. S, 2006)

 10

Tecnologias de Informação

Segundo Rezende & Abreu (2000, p.76), pode-se conceituar a Tecnologia de Informação como
recursos tecnológicos e computacionais para geração e uso da informação. Esse conceito
enquadra-se na visão de gestão da Tecnologia da Informação.

Software

Segundo Pressman (1995), softwares são instruções que, quando executadas, produzem a
função e o desempenho desejados.

Segundo Laudon e Jane (2004), existem dois tipos de software:

 Softwares de Sistema: conjunto de programas generalizados que gerenciam os recursos

do computador como o processador central, conexões de comunicação e dispositivos
como: impressoras, mouses etc. Exemplos: o sistema operacional Ubuntu, Windows 7,
etc.;
 Softwares Aplicativos: ou simplesmente aplicação, são programas que são construídos
para ou pelos usuários para designar uma tarefa específica ao computador. Exemplos:
um programa de gerenciamento de pedidos, gerenciamento de folha de pagamento.

2.4.1. Software Livre (Open Source)

De acordo com Yumi (2008) o software Open Source é também conhecido como “free
software” ou software livre em que a palavra “free” não indica gratuidade, mas sim, liberdade.
Afirmando que a liberdade é um dos valores defendidos pelo movimento Open Source, além
da colaboração e partilha do conhecimento. Devido à ambiguidade do significado do termo
“free software”, foi criada a expressão “Open Source”. De acordo com (Raymond, 2001),
existem quatro liberdades de softwares livres sob a licença GPL (General Public License):

 Liberdade de executar o programa para qualquer propósito;

 Liberdade de estudar como o programa funciona, e adaptá-lo às suas necessidades;
 Liberdade de redistribuir cópias de modo que você possa ajudar ao seu próximo;
 Liberdade de aperfeiçoar o programa e liberar os seus aperfeiçoamentos, de modo que
toda a comunidade possa beneficiar.
 11

Vantagens dos Softwares Livres

 Baixo custo, fundamentalmente concentrado em serviços e suporte;

 Maior segurança;
 Algumas das alternativas de aplicativos Open Source apresentam interfaces para o
utilizador final já muito próximas aos seus equivalentes proprietários, facilitando a sua
aceitação;
 Maior portabilidade frente às diversas arquitecturas de Hardware;
 Maior possibilidade de personalização já incorporada ao aplicativo, com mais
alternativas de configurações, possibilitando maior capacidade do aplicativo para
atender às necessidades do utilizador;
 Maior desempenho do sistema, relacionando com uma melhor integração
Hardware/Software, o que proporciona maior estabilidade dos serviços oferecidos ao
utilizador;

Desvantagens dos Softwares Livres

 Instalação e configuração dos aplicativos ainda tecnicamente complicados pela falta de

sistematização e disseminação dos conhecimentos pertinentes;
 Mão-de-obra escassa para suporte e/ou desenvolvimento;
 Resistência cultural do utilizador na migração do aplicativo;
 Interface com o utilizador de alguns aplicativos ainda não totalmente amadurecidos em
comparação com os homólogos proprietários;
 Alguma desconfiança por parte dos utilizadores em relação a continuidade e evolução
do aplicativo Open Source, relacionada com falsa ideia de ausência de
comprometimento da equipa envolvida no desenvolvimento do aplicativo;

2.4.2. Licença de Software

Ao desenvolver um software é necessário atribuir algum tipo de licença a ele para garantir seus
direitos sobre a obra. Existem algumas opções quando se tratam de licenças para projectos open
 12

source, cada uma com suas respectivas características. Abaixo será realizado uma abordagem
sobre as mais utilizadas no mundo do código livre.

 GNU - General Public License: As licenças de software são normalmente desenvolvidas

para restringir a liberdade de compartilhá-lo e modificá-lo. Pelo contrário, a GNU General
Public License ou Licença Pública Geral GNU pretende garantir a liberdade de compartilhar
e modificar o software livre, garantindo que o software será livre para os seus utilizadores.
(GNU, 2007). É a licença mais utilizada em softwares livres;
 BSD - Berkeley Software Distribution: criada pela Universidade de Berkeley que
desenvolveu o seu próprio sistema operacional baseado no Unix. Esta licença impõe poucas
limitações, tendo como objetivo disponibilizar o desenvolvimento do software para a
sociedade e ao mesmo tempo permitir que um financiador privado faça uso da pesquisa para
fins proprietários. Qualquer pessoa pode alterar o programa e comercializá-lo como se fosse
de sua autoria (BACIC, 2003);
 MIT - Massachusetts Institute of Technology: criada pelo Instituto de Tecnologia de
Massachusetts. É uma das licenças mais liberais que existe podendo ser modificada
livremente pelo autor do software. Permite que o código seja utilizado em softwares
licenciados e em programas livres ou proprietários.

Internet

A Internet é uma rede onde há a capacidade de interligar e interagir milhões de computadores

em qualquer lugar do mundo através do protocolo de comunicação TCP/IP de forma unificada
viabilizando a conectividade independente do tipo de computador que seja utilizado, permitindo
o acesso e transferência de dados e informações entre eles, podendo assim os usuários
conectados desfrutar de serviços de informação de abrangência mundial.

Patrocinada pelo Departamento de Defesa Norte Americano (DARP), a Internet nasceu em

1969, e foi chamada Arpa net. Foi criada com o objectivo de permitir que engenheiros e
cientistas que trabalhavam em projectos militares em toda a América pudessem compartilhar
computadores caros e outros recursos. (TEIXEIRA, 1997).
 13

Desde então as tecnologias que fazem parte da Internet evoluíram bastante, e seu propósito
tomou outro rumo. “A Internet alterou a forma como guardamos e procuramos informações,
conduzimos negócios e respondemos a questões em nossa sociedade”. (JONASSEN, 1996).

Segundo Barbalho (2004), o desenvolvimento de tecnologias, como a Internet, tem acelerado a

renovação científica através da circulação de saberes antes pouco disseminados.

2.5.1. Web

Conallen (2003), diz que a Web foi criada no início da década de 1990 por Tim Bernes-Lee,
para aperfeiçoar a comunicação no CERN – Centre European pour la Recherche Nucleaire.

Considera ainda que Bernes-Lee criou o HTML2, uma linguagem de marcação para formatar
os documentos que seriam distribuídos em rede e também desenvolveu protocolos de
comunicação para tornar viável o seu novo sistema de informações em hipertexto.

Sabe-se que a Web consiste em milhões de clientes e servidores, conectados em redes de

estruturas e tipologias diversas. Quando um determinado utilizador acede a uma determinada
URL pelo navegador, uma solicitação é enviada para o servidor Web que normalmente
responde para o cliente enviando a página Web solicitada (Deitel e Deitel, 2004). A figura
abaixo ajuda a entender essa distribuição:

Figura 2: Requisição de uma página WEB

Fonte: (Basham, Sierra, Bates, 2008)

2
HTML - Linguagem de marcação de hipertexto
 14

Aplicação Web

Uma aplicação web refere-se a qualquer programa que é acessado via uma conexão de rede
através de algum protocolo de comunicação em rede, em vez de existir na memória do
dispositivo. Estas aplicações correm, normalmente, dentro de um navegador web podendo
também ser baseadas no cliente, onde uma parte da aplicação é baixada para o dispositivo do
usuário, mas o processamento é feito via internet em um servidor externo.

Conallen (2003) acredita que os seguintes pontos trazem vantagens no uso de aplicações web:

 Sistemas na Web podem ser executados a partir de qualquer navegador da internet;

 Interface HTML reconhecida por uma grande gama de utilizadores já acostumados com
o funcionamento dos navegadores;
 Atualização dos dados e informações em tempo real para todos os utilizadores do
sistema;
 Desenvolvimento, manutenção e atualização centralizada da aplicação.
 Redução dos custos de comunicação, sendo que se existem escritórios dispersos e o SI
se baseia na internet, o custo em comunicação pode ser substancialmente reduzido;
 Exportações de dados entre utilizadores remotos utilizando o protocolo HTTP são mais
simples e mais fácil do que utilizar outro protocolo;
 Não é exigida muita memória e nem poderosos processadores para a execução do
sistema nos terminais, pois o sistema é todo executado no servidor;
 Escalabilidade no processamento.

Porém, o autor aponta ainda algumas desvantagens na utilização de sistemas web:

 Não há uma padronização entre os diversos navegadores;

 A entrada de uma grande massa de dados é prejudicada na interface HTML, pois não
existe uma forma padrão de criar máscaras de entrada de dados;
 Tempo de processamento da execução das tarefas depende da velocidade da conexão,
entre cliente e servidor;
 Os sistemas baseados na Web dependem dos recursos do navegador utilizado para
visualizar a aplicação;
 Difícil controlo do estado do cliente no servidor;
 15

Sistema de Informação

Sistema de Informação é qualquer sistema usado para prover informações (incluindo seu
processamento), qualquer que seja sua utilização. Os SI3s se desenvolvem em uma empresa
segundo duas dimensões: os componentes da empresa e seu nível de decisão. Os componentes
da empresa correspondem aos diversos setores que executam as diferentes funções necessárias
ao funcionamento da empresa. Os níveis de decisão obedecem à hierarquia existente na empresa
e são conhecidos como nível estratégico, táctico e operacional (POLLONI, 2000, p.30).

2.6.1. Tipos de Sistemas de Informação

Segundo Laudon e Jane (2004), os principais tipos de sistemas de informação são os Sistemas
de Processamento de Transações (SPTs), os Sistemas de Informações Gerenciais (SIGs) e os
Sistemas de Apoio à Decisão (SADs).

 Sistemas de Processamento de Transações (SPTs) - Conforme a abordagem de Stair

(2008), SPTs são um conjunto organizado de pessoas, procedimentos, software, base de
dados e dispositivos usados para registrar transações completas de procedimentos no
dia-a-dia das organizações. São os sistemas administrativos considerados básicos e que
atendem a todos os níveis operacionais das organizações;
 Sistemas de Informações Gerenciais (SIGs) - Os SIGs atendem ao nível gerencial da
organização, munindo os gerentes de relatórios ou de acesso on-line aos registros de
desempenho corrente e ao histórico da organização; apoiam as funções de planeamento,
controle e decisão no nível gerencial; e, geralmente, dependem dos SPTs subjacentes
para a aquisição de dados. Os SIGs, usualmente, atendem aos gerentes interessados em
resultados semanais, mensais e anuais e não em atividades diárias.
 Sistemas de Apoio à Decisão (SADs) - são desenvolvidos com o intuito de atender às
necessidades do nível estratégico da organização, no qual auxilia a direção a tomar
decisões nos cenários onde ocorreram mudanças rápidas. Os SAD usam as informações
geradas pelos SIT, pelos SE ou pelos SIG, e ainda utiliza-se das fontes externas, como
os níveis de preço dos competidores e oferta existente do produto.

3
Sistema de informação
 16

2.6.2. Planeamento de Recursos Empresariais (ERP)

O planeamento de recursos empresariais ou ERP é um sistema integrado que possibilita um

fluxo de informações contínuo e consistente por todos os departamentos de uma organização,
em uma mesma base de dados.

A tecnologia Enterprise Resource Planning (ERP) ou Planeamento de Recursos Empresariais

são pacotes (software) de gestão empresarial ou de sistemas integrados, com recursos de
automação e informatização, visando contribuir com o gerenciamento dos negócios
empresariais (REZENDE e ABREU, 2000, p.206).

Figura 3: Principais ERPs

Fonte: (MELO, I. S, 2006)

O ERP tem como objetivo melhorar processos de negócios como produção, avaliação ou
distribuição, tanto para verificação de informações on-line assim como em tempo real. O ERP
utiliza a tecnologia cliente/servidor, na qual o usuário acessa as informações diretamente em
uma base de dados única (servidor), que interage com todos os aplicativos do sistema.
 17

2.6.3. Sistema Integrado vs. Descentralizado

O Sistema apresentado na Figura 3, a seguir, é um sistema de informação totalmente

descentralizado, fazendo, então, com que os procedimentos internos da organização tornem-se
muito mais lentos. Todos os departamentos, com relação ao sistema de informação, estão
totalmente separados e para cada departamento existe a necessidade de se manter um banco de
dados, tornando a administração muito complexa.

Características indesejadas:

 Falta de integridade das informações;

 Atrasos na obtenção de resultados;
 Falta de padronização de procedimentos;
 Morosidade;
 Comprometimento dos dados.

Figura 4: Sistema Descentralizado

Fonte: Adaptado

Na figura 6, a seguir, temos a esquematização de um sistema integrado onde a informação torna-

se centralizada e os dados, que antes eram mantidos em bancos separados, passam a ter um
único banco para acomodação das informações, gerando então:
 18

 Integridade das informações;

 Agilidade na obtenção de resultados;
 Padronização de procedimentos.

Figura 5: Sistema Centralizado (ERP)

Fonte: Adaptado

Linguagem de Programação

Uma linguagem de programação é um método padronizado para expressar um conjunto de

instruções para um computador executar para uma determinado fim. Uma linguagem permite
que um programador especifique precisamente sobre quais dados uns computador vai atuar,
como estes serão armazenados ou transmitidos e quais ações devem ser tomadas sob várias
circunstâncias.

O conjunto de palavras, composto de acordo com essas regras, constitui o código fonte de um
software, que depois é traduzido para código de máquina, que é, por sua vez, executado pelo
processador.

Segundo a definição de Pressman (1995), “As linguagens de programação são veículos de

comunicação entre os seres humanos e os computadores”.
 19

2.7.1. PHP

O PHP, segundo Primo (2007, apud SILVEIRA, 2009, p. 43), surgiu em 1994 como um
projecto pessoal de Rasmus Lerdorf com o intuito de controlar acessos a sua página Web e
permitir aos desenvolvedores escrever páginas que serão desenvolvidas ou geradas
dinamicamente.

Silveira ainda complementa dizendo que a tecnologia PHP é gratuita e incorpora ainda a
linguagem PHP que é baseada nas linguagens C, Java e Perl e ainda pode ser vista como uma
combinação de linguagem de programação e servidores de aplicações.

Existem ainda outras tecnologias não tão conhecidas, mas que fazem parte desta categoria de
linguagens de servidor e que estão se popularizando cada vez mais, como é o caso do Python
e Ruby criados no final da década de 90. (SILVEIRA, 2009, p. 43)

Para Oliveira (2007), PHP é uma linguagem de scripting do tipo server-side, mas com
característica de ser open source. O PHP pode ser utilizado na maioria dos sistemas operativos,
incluindo Linux, diversas variantes UNIX, Microsoft Windows, Mac OS X e RISC OS. A
linguagem PHP proporciona o desenvolvimento de aplicações para base de dados utilizando
uma interface web.

2.7.2. Javascript

Silveira (2009), diz que Javascript é uma linguagem de scripts que é processada diretamente no
navegador, dispensando a ajuda de um servidor, onde através dela é possível fazer validações
de campos, abertura de janelas, controle da utilização de botões, mensagens de alertas,
confirmações e principalmente criar uma interatividade maior do usuário com a página
utilizada. (SILVEIRA, 2009, p.40)

Com Javascript é possível alterar o estilo de uma página de forma dinâmica, pois não é uma
linguagem compilada, mas sim interpretada e é inserida junto com o código fonte HTML das
páginas (SILVEIRA, 2009 apud DZENDZIK, 2005). Nesse contexto, podemos destacar que
com a linguagem Javascript será possível corrigir possíveis problemas que podem vir a surgir
no sistema proposto, tendo em vista que somente as linguagens HTML e CSS não oferecem
suporte para tanto, além possibilitar a construção de páginas mais dinâmicas e interativas.
 20

Para Pereira e Poupa (2005) o Javascript é uma linguagem de programação, da família da

linguagem C, que foi criada especificamente para a Internet pela Netscape no ano 1995, com o
propósito de permitir uma interactividade à que se consegue apenas com HTML.

2.7.3. HTML

Na óptica de Coelho (2001), o HTML consiste na linguagem utilizada nas páginas WWW.
Ainda o autor afirma que se trata de uma linguagem construída segundo as regras especificadas
por outras mais antigas (SGML) e que descreve páginas de Hipertexto com recursos a um
conjunto de identificadores denominados de “marcas”.

De acordo com Pereira e Poupa (2005) o HTML é uma linguagem básica da WWW e ainda
afirmam que a maioria dos documentos na Internet encontram-se escritas em HTML, e daí a
sua incontornável importância.

Base de dados

Date (2003) define base de dados como sendo um repositório para uma coleção de ficheiros de
dados computarizados. Date (2003) considera ainda que uma base de dados é uma “coleção de
preposições, assumidas por convenção como verdadeiras”.

2.8.1. Sistema de Gestão de Base de dados (SGBD)

Segundo Silberschatz, Korth e Sudarshan (1999), um Sistema de Gestão de Base de Dados é

um sistema constituído por um conjunto de dados associados a um conjunto de programas que
possibilitam acesso a esses dados.

Estes sistemas são criados para gerenciar um grande volume de informação de forma segura,
conveniente e eficiente, atendendo à necessidades dos aplicativos. São usados para o
armazenamento e manipulação de dados e devem garantir segurança das informações
armazenadas, tanto contra eventuais problemas com o sistema quanto a tentativas de acessos
não autorizados.
 21

2.8.2. Base de dados relacional

O relacional é um modelo de dados adequado a ser o subjacente de um sistema gestão de base

de dados (SGDB), que se baseia no princípio de que todos os dados estão guardados em tabelas
ou, matematicamente falando, relações. Toda sua definição é teórica e baseada na lógica de
predicados e na teoria dos conjuntos.

O conceito foi criado por Edgar Frank Codd em 1970, sendo descrito no artigo "Relational
Model of Data for Large Shared Data Banks". Na verdade, o modelo relacional foi o primeiro
modelo de dados descrito teoricamente.

Base de dados PostgreSQL

O PostgreSQL é um SGBD objeto-relacional de código aberto que implementa, além das

características de um SGBD relacional, algumas características de orientação a objetos, como
herança e tipos personalizados. O PostgreSQL possui uma grande compatibilidade com os
padrões SQL92/SQL99. É extremamente robusto e confiável, além de ser extremamente
flexível e rico em recursos.

Segundo o website4 do PostgreSQL, pela riqueza de recursos e conformidade com os padrões,

o PostgreSQL é um SGBD muito adequado para o estudo universitário do modelo relacional,
além de ser uma óptima opção para empresas implementarem soluções de alta confiabilidade
sem altos custos de licenciamento. É um programa distribuído sob a licença BSD5, o que torna
o seu código fonte disponível e o seu uso livre para aplicações.

Entre suas características, tem-se:

 Compatibilidade multiplataforma, ou seja, executa em vários sistemas operacionais,

como Windows, Mac OS X, Linux e outras variantes de Unix;
 Compatibilidade com várias linguagens, entre elas, Java, PHP, Python, Ruby, e C/C++;
 Base de dados de tamanho ilimitado;
 Tabelas com tamanho de até 32 TB;
 Quantidade de linhas de até 1.6 TB;
 Campos de até 1 GB;

4
http://www.postgresql.org – acessado no dia 01 de Junho de 2016 as 22:45h
5
Berkeley Software Distribution
 22

 Suporte a recursos como gatilhos, vistas, procedimentos armazenados, SSL6, MVCC7,

schemas, transacções, savepoints, integridade referencial e expressões regulares;
 Instruções em SQL;

Base de dados MySQL

Aloise et Al (2008), afirma que o MySQL é um sistema de gestão de base de dados relacional
multe encadeado, que tem código fonte aberto e nível corporativo. O MySQL não é apenas um
base de dados, mas também um gestor de base de dados. Com este SGBD (Sistema Gestão de
Base de Dados), também pode ser utilizado para aplicações corporativas, em que, necessitam
de várias conexões simultâneas, e que possibilita 101 conexões em simultâneas e que uma
conexão é o tempo que leva para um determinado utilizador receber o dado solicitado.

O MySQL é um software livre sob licença GPL, o que significa que qualquer um pode estudá-
lo, alterá-lo e distribuí-lo conforme a necessidade, desde que o software que o acessa seja livre.

Entre as características técnicas do MySQL, estão:

 Compatibilidade multiplataforma, ou seja, executa em vários sistemas operacionais,

como Windows, Mac OS X, Linux e outras variantes de Unix;
 Alta compatibilidade com linguagens como PHP, Java, Python, C#, Ruby e C/C++;
 Vários sistemas de armazenamento de dados (batabase engine), como MyISAM,
MySQL, Cluster, CSV, Merge, InnoDB, entre outros;
 Suporte a recursos como gatilhos, vistas, procedimentos armazenados, SSL,
transacções, savepoints, integridade referencial e expressões regulares;
 Instruções em SQL;

Controle de versão

Controle de versão é um repositório de ficheiros, normalmente ficheiros do código fonte de

programas de computador, com acesso monitorado. Cada alteração feita é monitorada e os

6
Secure Socket Layer – Protocolo de encriptação de dados
7
Controle de concorrência multiversionado
 23

dados de quem alterou, porquê alterou, as referencias dos problemas resolvidos ou melhorias
adicionadas incluídas com a alteração.

Permite que arquivos sejam revertidos à um estado anterior, todo o projecto de volta a um
estado anterior e comparar as alterações ao longo do tempo.

2.9.1. GIT

O GIT é um sistema de controlo de versão, iniciado por Linus Torvalds em 2005 e projectado
com enfâse em velocidade8.

O GIT está primariamente desenvolvido para Linux, mas pode ser usados em outros sistemas
operacionais baseados no Unix e Windows.

Actualmente dispõe de diversos serviços de hospedagem de repositórios compatíveis, estando

entre os mais populares o gitub.com e bitbucket.org que são grátis para uso pessoal.

Homestead

Segundo o website do framework Laravel9, do criador Taylor Otwell, homestead é uma “caixa”
Vagrant10 pré-construída que oferece um ambiente de desenvolvimento sem precisar instalar
PHP, servidor web ou qualquer outro software na máquina local.

É possível instalar em qualquer máquina Windows, Linux ou Mac e inclui o servidor web
Nginx, PHP 5.6, MySQL, PostgreSQL, GIT e outras ferramentas necessárias para desenvolver
aplicações web.

Padrão de desenho (Design Pattern)

É uma solução geral reutilizável para um problema que ocorre com frequência dentro de um
determinado contexto no projecto de software. Um padrão de projecto não é um projecto
finalizado que pode ser diretamente transformado em código fonte ou de máquina, ele é uma
descrição ou modelo (template) de como resolver um problema que pode ser usado em muitas

8
https://pt.wikipedia.org/wiki/Git - consultado no dia 1 de junho de 2016 as 23:01h
9
https://laravel.com/docs/master/homestead - consultado no dia 6 de junho de 2016 as 2:25h
10
Software para gestão de máquinas virtuais – https://www.vagrantup.com
 24

situações diferentes. Padrões são melhores práticas formalizadas que o programador pode usar
para resolver problemas comuns quando projetar uma aplicação ou sistema.

2.11.1. Padrão Model-View-Controller (MVC)

O padrão MVC foi formulado em 1970 por Trygve Reenskaug como parte de um sistema de
Smalltalk sendo desenvolvido na Xerox PARC. O sistema desenvolvido foi o princípio do
projecto em que muitos frameworks modernos da web se basearam. Foi projetado para actuar
em aplicativos em que os desenvolvedores descobriram que a separação de interesse resultava
em muito menos acoplamento, tornando o código mais fácil de escrever e de manter
(THOMAS; HANSSON, 2008). Sendo um padrão é implementado em várias linguagens de
programação e é altamente difundido, permitindo que equipes distintas trabalharem sem
interferência pejorativa, deixando o código mais legível, possibilitando cada equipe focar
exclusivamente nas suas atribuições.

É um padrão de arquitetura usado em engenharia de software, que divide a aplicação em três

camadas, cada uma com uma responsabilidade específica. Essas camadas são à base de toda a
aplicação e onde é focado a maior parte do código e do esforço em um projecto.

 Model (Modelo de Negócio): os objectos desta camada contêm os dados do negócio e

as regras do negócio que ditam como acessar e modificar os dados de maneira
consistente. Encapsula os dados e os comportamentos do negócio e persistem os
mesmos sem se preocupar em como serão mostrados. Alguns autores preferem o termo
modelo do domínio, pois nem todos os sistemas são comerciais.
 View (Visão): é responsável pela interação com o usuário e por apresentar as diversas
visões dos dados do negócio. Não se preocupa em como os dados foram obtidos, apenas
em apresentá-los.
 Controller (Controle): comanda o fluxo de apresentação das informações fazendo a
intermediação entre as camadas de visão e de modelo.
 25

Figura 6: Fluxo de requisições no padrão MVC

Fonte: http://rubysource.com/getting-started-withmvc

A descrição da imagem anterior pode ser feita da seguinte forma:

1) O usuário faz a requisição através do navegador;

2) O roteador recebe a requisição e selecciona a parte da aplicação para onde a requisição
deve ser encaminhada;
3) A requisição é enviada ao controlador que analiza a requisição feita e executa os
métodos necessários;
4) O controlador contacta o modelo para execução de algum repositório de dados;
5) O modelo executa a busca de dados em algum repositório de dados;
6) Os dados são retornados ao controlador em forma de um objecto;
7) O controlador envia estes dados a vista que retorna a representação visual desses dados;
8) Por fim a resposta é enviada ao cliente para visualização através do navegador;

Metodologia de Desenvolvimento de Software

Segundo Booch, (2000), para além da sequência de etapas e procedimentos recomendados para
serem aplicados durante o processo de desenvolvimento de sistemas de informação (ou seja,
 26

uma metodologia pressupõe a existência de um processo), acrescenta a esta definição a

utilização de um conjunto de ferramentas, técnicas e notações.

2.12.1. Relational Unified Process (RUP)

Segundo Castro & Moreira (2007) uma das grandes representantes das metodologias rigorosas
é o RUP, um recurso de Engenharia de Software, criado pela empresa Rational Software
Corporation que descreve a maneira de desenvolver um software utilizando técnicas comerciais
e objectivando o aumento da qualidade do produto criado. É classificado também como um
processo de Engenharia de Software, que tem como principal objectivo garantir o
desenvolvimento de sistemas com qualidade, respeitando os requisitos solicitados pelo cliente,
em prazos e custos determinados.

O Processo Unificado proposto pela RUP foi criado para apoiar o desenvolvimento orientado a
objectos, fornecendo uma forma sistemática para se obter vantagens na utilização da
Linguagem de Modelagem Unificada (Unified Modelling Language).

Segundo Silva (2001), a arquitectura do RUP encontra-se estruturada segundo duas dimensões,
que reflectem as duas visões através das quais um sistema pode ser descrito:

 Componente dinâmica: que reflecte a evolução temporal de um projecto, expressa em

ciclos, fases, iterações e objectivos a atingir.
 Componente estática: que reflecte quais as tarefas (workflows11) e actividades
realizadas, os outputs produzidos (artefactos), e os intervenientes.

Ciclos, Fases e Iterações - A Componente Dinâmica

O processo de desenvolvimento é dividido em ciclos, sendo que o ciclo de desenvolvimento é

subdividido em 4 fases consecutivas. Estas fases são concluídas tão logo uma milestone é
alcançada. Uma milestone define uma etapa, na fase, na qual decisões críticas são feitas ou
objetivos são alcançados.

11
Fluxo de actividades
 27

i. Concepção

Concepção inicial do sistema, aonde é feita uma discussão sobre o problema, definição do
escopo do projeto, estimativa de recursos necessários para a execução do projeto, etc. É nesta
fase que é apresentado o plano de projeto, caso de uso inicial e o glossário do projeto, entre
outros.

ii. Elaboração

O propósito desta fase é analisar o domínio do problema, desenvolver o plano de projeto,

estabelecer a fundação arquitetural e eliminar os elementos de alto risco. Os elementos de risco
a serem analisados, nesta fase, são os riscos de requerimentos, tecnológicos (referentes a
capacidade das ferramentas disponíveis), de habilidades (dos integrantes do projeto) e políticos.
Esta é a fase mais crítica de todas, pois ao final desta fase a engenharia é considerada completa
e os custos para modificação do sistema aumentam a medida que o projeto avança. Do ponto
de vista administrativo, é ao final desta fase que um projeto deixa de ser uma operação de baixo
risco e baixo custo para se tornar uma operação de alto risco e alto custo.

iii. Construção

É objectivo principal da fase de construção efectuar o desenvolvimento e integração de

componentes no produto final, bem como testes exaustivos a todas as funcionalidades. É
prestada particular atenção ao controle de custos, prazos e qualidade do produto. No final desta
fase existe um produto que pode ser disponibilizado aos utilizadores, que inclui os diversos
componentes de software integrados e instalados nas plataformas identificadas.

iv. Transição

A partir desta fase, o sistema já está pronto, começa a implantação do sistema para o usuário
(ou a comunidade de usuários do mesmo). Nesta fase é deve ser utilizado o lançamento de
versões beta12, operação paralela com o sistema legado, treinamento dos usuários e
mantenedores do sistema, etc.

12
Software/Produto que ainda se encontra em fase de desenvolvimento e testes
 28

Workflows, Actividades e Artefactos – A Componente Estática

A especificação da estrutura estática do RUP envolve a descrição de quem (Interveniente -

Worker) faz o quê (Artefactos), como (Actividades) e quando (Workflows). O modelo do RUP
prevê a existência de seis workflows principais, que agrupam as actividades directamente
relacionadas com a produção do produto final:

 Modelação do negócio
 Requisitos
 Análise e Desenho
 Implementação
 Testes
 Instalação.

Prevê ainda a existência de três workflows de suporte, que incluem actividades de apoio
executadas ao longo de todo o processo, que são essenciais para garantir o sucesso do mesmo:

 Gestão de projectos
 Configuração e gestão de alterações
 Definição do Ambiente.

Ao contrário das abordagens tradicionais, estes workflows não só não são sequenciais, como
são repetidos diversas vezes ao longo das várias fases do processo, em várias iterações,
possivelmente realizando actividades diferentes ou com um grau variável de intensidade e
detalhe.
 29

Tabela 1: Detalhes dos workflows do RUP

Fluxos Descrição

Modelagem do Documento que compreende o entendimento dos processos e negócio da

Negócio organização. Esse documento serve como uma espécie de acordo de concepção
entre o cliente e os desenvolvedores.

Planeamento e Planejar e monitorar todo o processo de desenvolvimento, gerenciar riscos,

Acompanhamento prover a infraestrutura e definir artefactos e atividades que serão contempladas
do Projeto no desenvolvimento do projeto

Requisitos Levantar os requisitos e definir o escopo do sistema

Análise e Projeto Transformar os requisitos num projeto para implementação do sistema

Implementação Implementar as classes em termos de componentes e testar as unidades.

Teste Verificar a integração de todos os componentes do software

Implantação Produzir a versão final do produto de software

Figura 7: Ciclo do desenvolvimento Utilizando RUP

Fonte: Kruchten (2003)

 30

2.12.2. Unified Modeling Language (UML)

A Unified Modeling Language (UML), Linguagem de Modelagem Unificada, é uma linguagem

gráfica para visualização, especificação, construção e documentação de artefactos de sistemas
complexos de software (BOOCH, 2000).

O UML apresenta, entre outras, as seguintes características principais: (1) é independente do

domínio de aplicação (i.e., pode ser usado em projectos de diferentes características, tais como
sistemas cliente/ servidor tradicionais; sistemas baseados na Web; sistemas de informação
geográficos; sistemas de tempo real); (2) é independente do processo ou metodologia de
desenvolvimento; (3) é independente das ferramentas de modelação; (4) apresenta mecanismos
potentes de extensão; (5) agrega um conjunto muito significativo de diferentes
diagramas/técnicas dispersos por diferentes linguagens (e.g., diagramas de casos de utilização,
de classes, de objectos, de colaboração, de actividades, de estados, de componentes, e de
instalação).

Elementos básicos

Segundo Silva (2001), a estrutura de conceitos do UML pode ser vista através das seguintes
noções: (1) “coisas” ou elementos básicos, com base nos quais se definem os modelos; (2)
relações, que relacionam elementos; e (3) diagramas, que agrupam elementos.

Os elementos encontram-se organizados consoante a sua funcionalidade ou responsabilidade.

Assim há elementos de estrutura, comportamento, agrupamento e de anotação.

Figura 8: Resumo dos elementos de estrutura

Fonte: SILVA, 2001

 31

Figura 9: Resumo dos elementos de comportamento, agrupamento e anotação

Fonte: SILVA, 2001

Tipos de relações

As relações são conceitos gerais que apresentam uma sintaxe (neste caso, uma notação) e uma
semântica bem definida, e que permite o estabelecimento de interdependências entre os
elementos básicos acima introduzidos.

Figura 10: Resumo dos tipos de relações standard

Fonte: SILVA, 2001

Diagramas da UML

Segundo Booch (2000), um diagrama é a representação gráfica de um conjunto de elementos

do sistema. Esses diagramas são desenhados para permitir a visualização de um sistema sob
diferentes perspectivas, sendo assim um diagrama constitui uma projeção de um determinado
sistema.
 32

O UML define diferentes tipos de diagramas, cuja utilização e aplicação permitem dar visões
complementares:

 Diagramas de casos de utilização, que representam a visão do sistema na perspectiva do

seu utilizador;
 Diagramas de classes que permitem especificar a estrutura estática de um sistema
segundo a abordagem orientada por objectos;
 Diagramas de interacção entre objectos (diagramas de sequência e diagramas de
colaboração) e diagramas de transição de estados e diagramas de actividades, que
permitem especificar a dinâmica ou o comportamento de um sistema segundo a
abordagem orientada por objectos;
 Diagramas de componentes e diagramas de instalação, que dão uma visão da disposição
dos componentes físicos (software e hardware) de um sistema.

Requisitos de um Sistema

Os requisitos de software nada mais são do que um conjunto de atividades que o software deve
desempenhar, com suas limitações e restrições, além de características não ligadas diretamente
às funções desempenhadas pelo software (SOMMERVILLE, 2003).

Quanto mais compreensível, precisa e rigorosa for a descrição de um requisito de sistema, maior
será a proporção quanto ao grau de qualidade do produto resultante (PETERS, 2001).

i. Requisitos Funcionais

Os requisitos funcionais abordam as funções que o sistema deve apresentar o comportamento

do sistema perante as entradas e a determinadas ocasiões. (PRESSMAN,2002).

ii. Requisitos Não Funcionais

Requisitos não funcionais são restrições que especificam os critérios que podem ser utilizados
para avaliar o funcionamento de um sistema, através de comportamentos específicos.
(LARMAN, 2000).
 33

Capítulo III: Estudo do caso proposto

Breve Historial

A Universidade Pedagógica é uma instituição pública de ensino superior fundada em 1985 sob
o nome de Instituto Superior Pedagógico (ISP) até que em 1995, dez anos depois da sua
abertura, passa a categoria de Universidade adoptando, então, o seu nome actual. Na época da
sua abertura, funcionou nas instalações da Escola Preparatória General Joaquim José Machado,
em Maputo.

Foi a primeira instituição de ensino superior a ter um campus fora da capital do país,
demostrando desde então a sua vontade de expandir a educação para todos os cantos de
Moçambique.

Aquando da elaboração deste projecto, a UP completava 30 anos da sua existência e contava

com nove faculdades englobando mais de quarenta e cinco cursos de áreas que vão desde o
ensino de inglês até a medicina geral. Ela está presente em todas províncias do país e conta com
um universo de mais de quarenta e cinco mil estudantes distribuídos nos regimes regular, pós-
laboral, semi-presencial e à distância.

Tabela 2: Número de estudantes inscritos na UP por delegação em 2015.

Delegação Regimes Total de

estudantes por
Pós-laboral Regular Distância Semi-presencial
delegação

Sede 4.674 4.327 1.024 0 10.025

Gaza 1.147 846 775 0 2.768

Massinga 389 516 566 0 1.471

Beira 1.962 2.855 1.035 0 5.852

Quelimane 1.721 2.041 1.142 0 4.904

Nampula 2795 3550 1029 34 7.408

Niassa 861 1.482 538 0 2.881

 34

Montepuez 386 1.118 565 0 2.069

Manica 754 1.227 673 0 2.654

Maxixe 777 1.097 1.278 0 3.152

Tete 846 787 799 0 2.432

Total de estudantes inscritos 45.616

Fonte: Direcção de Registo Académico da UP, 2015.

Missão da UP

Aquando da sua fundação, a UP era tida somente como uma instituição vocacionada para a
formação de professores para todos os níveis do Sistema Nacional de Educação (SNE) e de
quadros da educação. Hoje, com o aumento significativo do leque de cursos ministrados por
ela, forma desde professores a técnicos profissionais capacitados para lidar com o mercado de
trabalho, algo que vem fomentando a procura pelos serviços por ela prestados.

A Direcção de Registo Académico

A direcção de registo académico é o órgão da Universidade Pedagógica responsável pelo

acompanhamento dos estudantes na vertente administrativa. Foi criada em 1985 com o nome
de Serviço de Assuntos Estudantis e só em 1997 passa a chamar-se Direção de Registo
Académico com objectivo de dar melhor resposta contínua aos serviços académicos, motivado
pelo número crescente dos estudantes da Universidade Pedagógica a nível nacional.

A direção central funciona no edifício da UP-Sede, na rua João Carlos Raposo Beirão, n°135,
em Maputo.

3.3.1. Actividades do sector

Dentre as demais actividades pelas quais a DRA é responsável, destacam-se:

 Registo dos estudantes e abertura de processos individuais dos mesmos e administração

do respectivo arquivo;
 35

 Emissão e autenticação de documentos (certificados, diplomas, cartões de estudante e

declarações) solicitados pelos estudantes e instituições diversas;
 Organização das cerimónias de graduação;
 Atendimento ao público em geral e em especial aos estudantes da UP;
 Administração da base de dados do registo académico;
 Fornecer relatórios estatísticos sobre a população estudantil da instituição;
 Apoio à Direcção Pedagógica na implementação de planos curriculares na instituição e
codificação das disciplinas dos mesmos;

3.3.2. Organização

Esta direcção é administrada por um director nacional que trabalha em colaboração com os
chefes de departamento espalhados pelas delegações da UP.

A nível central, ela conta com uma equipa formada por nove funcionários, um chefe de
departamento, uma chefe de secretaria e a directora da direção, fazendo o total de doze
trabalhadores.

Figura 11: Organigrama da DRA

Fonte: www.up.ac.mz/dra, 2015.

 36

Descrição do Sistema actual

3.4.1. Sistema de Gestão da Universidade Pedagógica (SIGEUP)

O SIGEUP é um sistema de informação que foi concebido para auxiliar a gestão das áreas
académica, administrativa e financeira da Universidade Pedagógica a nível nacional provendo
segurança, facilidade, compartilha de informação e rapidez nos processos desta instituição.

Historial do SIGEUP

Até ao ano de 2012, a DRA já usava um sistema de informação para o registo das inscrições
dos estudantes. Era uma aplicação desktop13 desenvolvida usando os pacotes proprietários
Microsoft Office Access-200314 e Visual Basic15 da Microsoft16. Este sistema, devido a sua
arquitectura, mostrava várias limitações em termos de flexibilidade e integridade dos dados,
visto ser um sistema que só podia ser acedido localmente (o que punha em risco a segurança e
integridade da própria base de dados pois era necessário transporta-la de um computador para
outro), necessitava de instalação de softwares pagos em cada máquina que precisasse aceder ao
sistema e um técnico formado para configurar cada máquina, para além da morosidade do
sistema. Até então, somente algumas delegações faziam o uso deste sistema sendo que cada
uma possuía os seus dados localmente sem que houvesse partilha de informação. Outro aspecto
era o isolamento dos demais sectores pois cada um dos sectores possuía, também, um sistema
isolado que proporcionava os mesmos problemas de duplicidade e inconsistência de dados e
dificuldade no levantamento de informações.

Na tentativa de ao menos melhorar tal cenário, surge a necessidade de implementação de um

sistema de gestão que pudesse responder as dificuldades da DRA, em particular, e da instituição
no geral. Para que isso pudesse acontecer, a instituição teve que assumir um grau mais elevado
de maturidade, direcionando seus esforços para o desenvolvimento de módulos integrados que
fizessem uso de uma única base de dados e estivessem apoiadas por uma infraestrutura sólida
de Tecnologia da Informação, dando origem a um novo sistema denominado eDondzo17.

13
Sistemas executados na máquina dos usuários, podendo ter comunicação com outros sistemas.
14
Sistema de gestão de base de dados com uma interface gráfica do utilizador.
15
Linguagem de programação produzida pela empresa Microsoft.
16
Empresa americana que vende softwares de computador, produtos eletrônicos, computadores e serviços
pessoais.
17
Denominação inicial do SIGEUP.
 37

O eDondzo foi criado por um desenvolvedor contratado pela instituição que havia iniciado o
seu desenvolvimento no ano de 2010 e passou a ser implementado em todas delegações da UP
a partir do ano de 2013. Esta implementação foi possível graças ao uso de uma base de dados
única e à sua arquitectura voltada à web que permite o acesso remoto a partir de qualquer parte
do mundo, desde que possua uma conexão à internet e um navegador web.

Gradualmente, foi feita a integração dos estudantes no sistema (registo académico), planos
curriculares, dos pagamentos (finanças), funcionários e docentes (recursos humanos) e notas
dos estudantes.

Em 2014 ele passa por uma reestruturação que engloba um novo domínio, nova equipa de
desenvolvimento, políticas de administração, servidores e nome, passando a ser denominado
por SIGEUP, um acrónimo para Sistema de Gestão da Universidade Pedagógica, nome este que
prevalece até hoje.

A equipa responsável pelo sistema é composta, actualmente, por três funcionários da instituição
alocados na DRA e CIUP18 nomeados pelo Reitor com a função de prover a manutenção,
aprimoramento, extensão e documentação do sistema.

Características do Sistema

O SIGEUP é um sistema integrado que funciona através de uma interface web, intuitiva e de
fácil acesso. O seu acesso pode ser feito a partir de qualquer dispositivo com acesso à internet
e uma aplicação que permita navegar na web, independentemente das especificações de
hardware e software do dispositivo, tornando-se, assim, um sistema multiplataforma. O seu
acesso é disponibilizado através do endereço www.sigeup.up.ac.mz.

O acesso ao sistema e controlado por um serviço de autenticação em que o usuário deve

providenciar um nome de usuário e senha válidos para ter acesso ao SIGEUP. O acesso aos
módulos é gerido por um serviço de perfis dos utilizadores que permite, de forma dinâmica, a
limitação do acesso a determinadas funções de acordo com as necessidades e políticas da
instituição.

Este sistema foi desenvolvido usando as linguagens de programação PHP e Javascript e, para a
interface do usuário, recorreu-se ao uso do Bootstrap da Twitter, um framework CSS e

18
Departamento responsável pelo ramo de informática na UP.
 38

Javascript que permite o desenvolvimento de páginas web responsivas19 em relativamente

pouco tempo.

O sistema é disponibilizado a partir de um servidor que funciona com o sistema operativo

Ubuntu Server e um SGBD PostgreSQL. Os dados da ligação entre o dispositivo do usuário e
o servidor são encriptados usando os protocolos TLS e SSL, permitindo uma maior segurança
na transmissão de dados.

O código do SIGEUP é proprietário, isto é, o uso, redistribuição ou modificação sem

autorização é proibido.

Módulos existentes

O Sistema de Gestão da Universidade Pedagógica está, actualmente, agrupado nos seguintes

módulos:

 Portal do Estudante: é o módulo disponível para que os estudantes possam

acompanhar o seu progresso académico e situação financeira. Nele podem consultar as
sua notas, o seu saldo, lista de pagamentos feitos e por fazer e, também, a lista das suas
referências bancárias;

 Portal do Docente: este módulo está voltado para o docente e é onde ele pode ter acesso
à lista dos seus estudantes por cadeira, lançar avaliações e imprimir as suas pautas;

 Gestão do Currículo: este módulo está virado à gestão dos cursos, disciplinas,
faculdades, departamentos e planos curriculares no sistema;

 Registo Académico: neste módulo temos acesso à diversos recursos para administração
académica do estudante como o registo, gestão, inscrição, registo de actas de conclusão,
emissão de declarações do estudante;

19
Página web que muda a sua aparência e disposição com base no tamanho da tela em que é exibida.
 39

 Finanças: aqui temos a administração financeira da instituição, onde faz-se o registo

dos pagamentos, gestão das mensalidades dos estudantes e multas;

 Recursos humanos: neste módulo temos as funções relacionadas com a administração

das carreiras, categorias e funções dos funcionários da instituição, alocação dos
directores de curso e docentes para as turmas;

 Serviços Sociais: aqui temos as funcionalidades de alocação de bolsas de estudo aos

estudantes privilegiados e cadastramento de instituições bolseiras no sistema;

 Administração do Sistema: aqui temos as funções básicas do sistema como o registo

de anos lectivos, delegações, campis universitários, gestão de perfis e usuários e o painel
de importação de notas dos estudantes;

 Relatórios: neste módulo temos os relatórios do sistema onde podemos ter a estatística
do número de estudantes inscritos em disciplinas, os inscritos para a graduação, para os
exames especiais, as actas emitidas, estatística do corpo docente e as pautas das
disciplinas leccionadas.

3.4.2. Inscrição dos Estudantes

A inscrição dos estudantes na UP é feita no SIGEUP pela direção do registo académico na sede
e pelos departamentos de registo académico nas delegações.

Período das Inscrições

As inscrições dos estudantes decorrem duas vezes ao ano no início de cada semestre. Este
processo, com um tempo estipulado de 7 a 15 dias, chega a durar no mínimo 45 dias. Durante
este período, o Registo Académico estende o seu horário de funcionamento, passando a
funcionar no horário das 7h e 30 mins até as 17h, contra o horário normal que termina às 15h e
30 minutos.
 40

Processo de Inscrição

O processo de inscrições dos estudantes na UP decorre no início de cada semestre, época esta
em que os estudantes desta instituição dirigem-se em massa aos locais de atendimento do registo
académico a fim de regularizar a sua inscrição, requisito de carácter obrigatório para que o
estudante possa frequentar as disciplinas leccionadas no semestre em vigor.

Na UP sede, devido à limitações em termos de infraestruturas suficientes para albergar o

numeroso universo de estudantes que aflui a este departamento (um pouco mais de dez mil
estudantes, fonte: DRA, 2015), os seus funcionários se deslocam à um espaço maior, neste caso
Campus de Lhanguene, de forma a suprir esta dificuldade. Durante este período, a DRA encerra
as suas demais actividades e foca os seus funcionários na actividade de atender aos estudantes
nas inscrições.

A inscrição dos estudantes na UP, a nível nacional, é feita em cadeiras dentro do SIGEUP onde
os administradores definem as políticas de acesso aos módulos através dos recursos fornecidos
pelo sistema.

O processo de inscrição consiste, basicamente, em o estudante primeiramente consultar o valor

que deve depositar pela inscrição, que vai de acordo com o número de disciplinas a frequentar,
seguido pelo depósito desse valor dentro do banco, na respectiva conta do registo académico e
por fim a apresentação do recibo de depósito e do cartão de estudante (ou outro documento de
identificação) ao funcionário do registo académico. Após isto, o funcionário faz o registo do
recibo manualmente no SIGEUP, introduzindo os dados do recibo (código da conta bancária,
número do talão, data do depósito e o valor do depósito) e de seguida a inscrição nas disciplinas
pretendidas. Por fim faz a impressão do recibo da inscrição onde são impressas duas cópias
ficando uma com o estudante e a outra no registo académico, onde se anexa o recibo do
depósito.

Constrangimentos

Durante o período das inscrições, tem-se observado enchentes devida a demora no atendimento
que tem várias causas como origem: falta de acesso à internet, lentidão da rede, equipamentos
danificados (PC’s, impressoras, switches, etc.). Apesar das tentativas de organização dos
estudantes por faculdade em que cada faculdade teria um período específico para inscrição e
optar-se por espaços maiores para instalação da DRA, as enchentes prevalecem.
 41

Outro ponto que tem sido observado é em relação aos estudantes do EAD que não se encontram
a residir dentro da cidade de Maputo ou então trabalham fora da cidade sendo este, muitas das
vezes, o motivo por optarem por este regime de frequência. Muitos acabam perdendo o período
de inscrições pela falta de disponibilidade para se deslocar aos locais onde estas decorrem.
Além disso, o SIGEUP não possui uma ferramenta para o controle de precedências, ficando
essa função a cargo do funcionário que normalmente não possui acesso a estas informações ou
que, por um ou outro motivo, acaba cometendo erros.

Outro ponto concerne o arquivo desses recibos de depósito que chegam a ser um
constrangimento pois ocupam largos espaços chegando a ameaçar a saúde dos próprios
funcionários, pois, acabam sendo armazenados nos próprios locais de trabalho por falta de
espaços para a sua arquivação

Durante este período, os custos em termos de consumíveis de escritório (papel, tinteiros,

impressoras, etc) e humanos chegam a aumentar significamente. Tendo em conta que o horário
de funcionamento do Registo Académico é estendido, a instituição é obrigada a pagar horas
extras aos envolvidos neste processo.

Outro constrangimento está relacionado com o lançamento dos dados dos talões de depósito
pois não existe algum mecanismo que possa autenticar os dados inseridos no sistema, isto é, o
sistema está vulnerável ao forjamento de dados de pagamentos.
 42

Capítulo IV: Concepção e Implementação do Módulo de Inscrição Online

Para Finger (1997) os processos de Gestão Universitária deveriam ser inovadores e melhorar a
interacção entre alunos, docentes, técnicos e, em geral, a comunidade universitária. Reforçando
a ideia, (Bernardes & Abreu, 2009) afirma que os colaboradores das Universidades precisam
se consciencializar da importância das tecnologias como componente de integração dos
diversos departamentos, unidades académicas e administrativas.

A vasta disponibilidade de tecnologia da computação a custo acessível mudou drasticamente a

maneira como as pessoas/organizações adquirem, armazenam, recuperam, transmitem,
comunicam e usam as informações.

Após termos feito a apresentação da instituição em estudo e o cenário encontrado, vamos, neste
capítulo, percorrer o processo de concepção do módulo e a sua implementação.

Concepção do módulo de inscrição online

4.1.1. Requisitos funcionais

R1 Autenticação dos usuários

R2 Registo do endereço electrónico do estudante
R3 Confirmação do endereço electrónico do estudante
R4 Selecção de disciplinas por frequentar
R5 Selecção de disciplinas dos níveis anteriores por frequentar
R6 Gerar referência e valor para pagamento da inscrição
R7 Gerar relatório com referência, entidade, valor total da inscrição e instrucções de
pagamento
R8 Anulação de inscrição Online não confirmada
R9 Validação automática de inscrições dos estudantes isentos de pagamentos
R10 Importação de ficheiros dos pagamentos enviados pelo banco
R11 Validação das inscrições dos estudantes com pagamentos feitos
R12 Enviar notificações de confirmação das inscrições
R13 Gerar relatório do recibo da inscrição
 43

4.1.2. Requisitos não funcionais

 O sistema deve estar capaz de processar várias requisições por um curto espaço de
tempo;
 A interface deve ser compatível com os navegadores de dispositivos móveis (Smart
Phones, Tablets, Netbooks);
 O sistema deverá rodar em multiplataformas;
 O sistema deve trabalhar em rede (fornecer terminais aos seus clientes, de forma que
eles possam interagir directamente com o sistema);
 O sistema deve permitir uma autenticação dos utilizadores;
 A comunicação entre sistemas deve utilizar uma plataforma segura;

4.1.3. Casos de Uso

Descrição dos casos de uso

 Caso de Uso (R1): Autenticação dos usuários

o Actores: Estudante/Funcionário;
o Pré-Condição: O usuário deve estar registado no sistema;
o Descrição: Para acesso às funcionalidades do sistema, o usuário deve
providenciar o seu usuário e senha que serão validados via base de dados. Caso
haja erro, uma mensagem deve ser exibida;
 Caso de Uso (R2): Registo do endereço electrónico do estudante
o Actores: Estudante;
o Pré-Condição: O estudante deve estar logado no sistema;
o Descrição: O sistema deve permitir a inserção do endereço electrónico do
estudante;
 Caso de Uso (R3): Confirmação do endereço electrónico do estudante
o Actores: Estudante
o Pré-Condição: O estudante deve estar logado no sistema;
o Descrição: Após o registo do endereço electrónico no sistema, o estudante deve
realizar a confirmação do através de um link de confirmação enviado via email
pelo sistema. Após acessar o link, deverá ser redireccionado para o sistema. Uma
mensagem de sucesso deve ser exibida;
 44

 Caso de Uso (R4): Selecção de disciplinas por frequentar

o Actores: Estudante;
o Pré-Condição: O estudante deve ter o email confirmado;
o Descrição: O sistema deve exibir a permissão para fazer a inscrição online e
selecionar as disciplinas que o estudante quer frequentar;
 Caso de Uso (R5): Selecção de disciplinas dos níveis anteriores por frequentar
o Actores: Estudante;
o Pré-Condição: O estudante deve ter a situação financeira regularizada;
o Descrição: O sistema deve permitir a selecção de disciplinas dos níveis
anteriores ao actual do estudante;
 Caso de Uso (R6): Gerar referência e valor para pagamento da inscrição
o Actores: Estudante;
o Descrição: Após a confirmação da submissão dos dados para da inscrição, o
sistema deve gerar uma referência para pagamento baseada na delegação do
estudante, o valor total da inscrição por cadeiras e multa sobre o valor da
inscrição, sendo que este último caso é somente aplicado em caso de inscrição
fora do prazo estabelecido;
 Caso de Uso (R7): Gerar relatório com referência, entidade, valor total da inscrição e
instrucções de pagamento
o Actores: Estudante;
o Descrição: O sistema deve permitir a visualização dos detalhes para pagamento
da inscrição, assim como instrucções de como fazer o pagamento;
 Caso de Uso (R8): Anulação de inscrição Online não confirmada
o Actores: Funcionário;
o Pré-Condição: O funcionário deve estar logado no sistema e ter permissões para
eliminar inscrições;
o Descrição: O sistema deve permitir a anulação de inscrições online desde que
ainda não tenham sido validadas;
 Caso de Uso (R9): Validação automática de inscrições dos estudantes isentos de
pagamentos
o Actores:
o Descrição: O sistema deve validar automaticamente todas a inscrições dos
estudantes bolseiros que não tenham nenhuma cadeira em atraso;
 45

 Caso de Uso (R10): Importação de ficheiros dos pagamentos enviados pelo banco
o Actores: Funcionário;
o Pré-Condição: O funcionário deve estar logado no sistema e ter permissões para
importar pagamentos;
o Descrição: O sistema deve permitir a importação dos ficheiros enviados pelo
banco;
 Caso de Uso (R11): Validação das inscrições dos estudantes com pagamentos feitos
o Actores: Funcionário;
o Pré-Condição: O funcionário deve estar logado no sistema e ter permissões para
eliminar inscrições;
o Descrição: Durante a importação dos pagamentos do banco, o sistema deve
validar todas as inscrições cujo pagamento esteja conforme;
 Caso de Uso (R12): Enviar notificações de confirmação das inscrições
o Actores:
o Descrição: O sistema deve enviar automaticamente emails para os endereços
dos estudantes cujas inscrições tenham sido confirmadas;
 Caso de Uso (R13): Gerar relatório do recibo da inscrição
o Actores: Estudante;
o Pré-Condição: O estudante deve estar logado no sistema;
o Descrição: O sistema deve permitir obter o recibo da inscrição para as que já
tenham sido confirmadas e validadas;

Para os diagramas de casos de uso, veja o Anexo 2.

 46

4.1.4. Diagramas de Sequência

Efectuar inscrição

Figura 12: Diagrama de sequência - Inscrição

Cancelar Inscrição

Figura 13: Diagrama de sequência - Cancelar Inscrição

 47

Importar Pagamentos

Figura 14: Diagrama de sequência: Importar Pagamentos

4.1.5. Modelo de Entidade-Relacionamento

Tabela 3: Diagrama de MER

 48

4.1.6. Dicionário de Dados

Tabela 4: Dicionário das tabelas

Tabelas
Usuario Tabela com informações dos usuários
Perfil Tabela com informações das permissões dos usuários
Estudante Tabela com os dados dos estudantes
Curso Tabela com informações dos cursos
Regime Tabela com informações dos regimes
Delegacao Tabela com informações das delegações do sistema
Bolsa Tabela com dados das bolsas dos estudantes
Pagamento Tabela com dados dos pagamentos feitos pelos estudantes
Recibo Tabela com as informações dos recibos dos pagamentos do sistema
Recebo_descritivo Tabela com descritivos dos pagamentos feitos no sistema
Disciplina Tabela com informações das disciplinas
Curso_disciplina Tabela com informações das disciplinas que pertence a cada curso
Turma Tabela com informações das turmas
Inscricao Tabela com informações das inscrições feitas no sistema
Inscricao_disciplina Tabela com informações das disciplinas inscritas pelos estudantes
Banco Tabela com informações dos bancos do sistema
Conta_bancaria Tabela com dados das contas bancárias
Referencia_bancaria Tabela com informações das referências geradas pelo sistema
Referencia_import Tabela com informações das referencias recebidas via importação de ficheiros do
banco
Audit.Inscricao Tabela com informações de backup das inscrições eliminadas do sistema
Audit.Log Tabela de Log das actividades no sistema

Para consultar o dicionário de campos das tabelas acima, veja o Anexo 1.

 49

4.1.7. Diagrama de instalação

Figura 15: Diagrama de Instalação

4.1.8. Ambiente de desenvolvimento

Para o desenvolvimento deste módulo, foram usadas as seguintes ferramentas:

 PhpStorm para edição dos códigos;

 Composer para gestão de dependências;
 Git para o controlo de versão e deployment do código fonte;
 Homestead como ambiente virtual;
 PgAdmin para interacção com o SGBD PostgreSQL;
 Mandrill para envio de emails do sistema;

Para consulta das ilustrações das ferramentas acima, vide Anexo 5.

Testes do Sistema

Para a concepção deste projecto não foi utilizado nenhum método específico para realização
dos testes. Durante o processo de concepção, foram realizados testes de integridade dos dados
com registos reais em máquinas virtuais.

Quanto à apresentação do sistema, tendo em vista o ponto importante de compatibilidade dos

navegadores, foram usadas as ferramentas disponibilizadas pela Google através do seu
navegador chrome – Chrome DevTools. Estas ferramentas permitem simular a visualização do
website em diversos dispositivos com diferentes resoluções do ecrã. Foram também feitos testes
com outros navegadores sendo eles: FireFox, Opera e Microsoft Edge.
 50

Relativamente à apresentação, foram testados basicamente a usabilidade do sistema perante

diversos utilizadores. Estes tipos de testes permitem verificar quais as funcionalidades onde os
utilizadores mostraram mais dificuldade na sua utilização, revelando os diversos aspectos para
possíveis melhorias.

A nível de segurança foram definidos e testados os privilégios para cada tipo de utilizadores na
utilização do sistema. Os utilizadores somente terão disponíveis a interface necessária para a
execução das suas tarefas.

O piloto foi lançado com suporte para importação de ficheiros de pagamento do BIM, banco
com o qual a instituição já trabalhava, mas foram testados com sucesso ficheiros do BCI.

Implementação do Módulo de inscrição online

Na fase de implementação do sistema, foi usado o serviço de hospedagem de repositórios GIT

BitBucket.org. O esquema apresentado de seguida, ilustra o processo de deployment da
aplicação no servidor de produção com o auxílio do GIT.

Figura 16: Esquema de deployment da aplicação

1: Ambiente local de desenvolvimento; 6: Busca as actualizações no repositório remoto e

2: Repositório GIT remoto; inclui no repositório local (pull);
3: Servidor de Produção; 7: Rota protegida com sistema de autenticação segura;
4: Envio (push) do repositório de desenvolvimento
local para o remoto;
5: Envio do sinal para o servidor de produção caso
exista alguma alteração através de webhooks;
 51

De forma a garantir encriptação dos dados entre o cliente e o servidor durante a conexão, de
forma a impedir o extravio e adulteração desses dados, recorreu-se ao uso de um certificado
SSL no servidor web.

Foi criado um manual para os estudantes sobre o procedimento de inscrição que pode ser
consultado no Anexo 4 e na página web do DRA (https://www.up.ac.mz/dra/8-
departamentos/12-passos-para-inscricao-no-sigeup.html).

Foi feita uma pequena formação dos funcionários nos aspectos de anulação de inscrições,
importação de pagamentos e suporte para questões em que houvesse dúvidas por parte dos
estudantes sobre o processo de inscrição.

Foi disponibilizado um endereço de email (apoio.sigeup@up.ac.mz) que consta em todos

emails enviados pelo o sistema, para uma comunicação directa com a equipa de
desenvolvimento assim como um formulário de contacto que permite enviar mensagens via
email directamente do SIGEUP.

Para mais detalhes sobre os formulários do sistema, vide Anexo 4.

 52

Capítulo V: Conclusão

Considerações Finais

O uso de tecnologias de informação ajudam a minimizar diversos aspectos de administração de

uma instituição entre eles económicos, humanos e infraestruturas sendo que a Universidade
Pedagógica não está alheia a este movimento.

Neste trabalho apresentou-se a concepção e implementação de um serviço web que estende as

funcionalidades do sistema de gestão existente na Universidade Pedagógica através do uso de
tecnologias Open Source através do uso de metodologias orientadas à objectos.

O uso da metodologia RUP permitiu obter qualidade de software, produtividade no

desenvolvimento, operação e manutenção de software, controle sobre o desenvolvimento
dentro de custos, prazos e níveis de qualidade desejados, sem deixar de levar em conta a
estimativa de prazos e custo com maior precisão.

Com a implementação do módulo, foi possível adicionar fiabilidade aos dados de pagamentos
no sistema, diminuição significativa dos custos acarretados pelo processo de inscrição e
aumento de comodidade tanto para os estudantes assim como para a instituição.

Em suma, atingimos os nossos objectivos com o trabalho, validamos nossas hipóteses e

efectivamente contornamos as dificuldades apresentadas na formulação do problema.

Limitações

 O ficheiro com os dados de pagamentos é enviado pelo banco somente nos dias
úteis, uma vez por dia;
 A arquitectura monolítica20, que é a actual usada no sistema, trás algumas
dificuldades que vão se agravando de acordo com o crescimento da aplicação
como:
o Ponto único de falha: se houver um erro em algum componente que
deixe o sistema fora do ar, isso vai levar junto todo o sistema, incluindo
funcionalidades que não possuem nenhuma relação com essa
funcionalidade;

20
Uma aplicação feita em uma só unidade.
 53

o Integração de equipas: o código fonte, que se torna muito extenso,

podendo deixar novos membros do projeto menos produtivos por algum
tempo, visto a sua complexidade ser um pouco maior;
o Implantação da aplicação: alterações em alguma parte da aplicação
obriga o deployment de toda aplicação;

Recomendações

Após o término do processo de implementação do sistema, pode-se fazer uma pequena análise
de alguns pontos que vamos aqui recomendar:

 Integração de mais bancos de forma a estender os pontos de pagamento de

serviços;
 Encontrar-se formas de minimizar o tempo de espera pela consolidação dos
pagamentos feitos via referências;
 Uso de um balanceador de conexões de forma a permitir a integração de uma
arquitectura em microserviços;
 54

Referências Bibliográficas

 GIL, A. C. Como elaborar projectos de pesquisa. 5. ed. São Paulo, Atlas, 2010.
 SEVERINO, Antônio Joaquim. Metodologia do trabalho científico. São Paulo: Cortez,
2000.
 PRESSMAN, R. S. Engenharia de software. São Paulo: Makron Books, 1995.
 STAIR, R. M. Princípios de sistemas de informação: uma abordagem gerencial. São
Paulo: Cengage Learning, 2008.
 LAUDON, K. C. S.; LAUDON, J. P. Management of information systems: a
contemporary perspective. [S.l.]: MacMillan, 1996.
 Comissão de Revisão Curricular. Normas para Produção e Publicação de Trabalhos
Científicos na Universidade Pedagógica, Maputo, 2012;
 BERNARDES, J. F.; ABREU, A. F. A contribuição dos sistemas de informações na
gestão universitária. Florianópolis: INPEAU, 2004.
 GASPEROTTO, Neiva Aparecida. A secretaria de uma universidade virtual.
Florianópolis, 2000.
 DÁVALOS, R. V.; MÜLBERT, A. L. Implantação de um Sistema Integrado de
Gestão.2002. Obtido em 10 de Maio de 2014, de
http://www.abepro.org.br/biblioteca/ENEGEP2002_TR90_0239.pdf.
 YUMI, E. I. Movimento Open Source. 2008. Obtido em 10 de Maio de 2014, de
http://www.dicasl.com.br/download/movimento_open_source.pdf.
 ANDERSON, John: Paper-Based Enrollment: Problems and Solutions. In: School
Business Affairs. New York. Outubro. 2011 pp. 30-32.
 KRUCHTEN, P. (2003). Introdução a RUP. Obtido em 17 de Novembro de 2015, de
http://www.personati.com/artigos/Pu_RUP.doc
 PRODANOV, C. C.; FREITAS, E. C. Metodologia do Trabalho Científico: Métodos e
Técnicas da Pesquisa e do Trabalho Acadêmico. 2. ed. Novo Hamburgo, Feevale, 2013.
 MANÃS, A. V. Administração de sistemas de informação. 2. ed. São Paulo: Érica,
1999.
 MELO, I. S. Administração de sistemas de informação. 1. ed. São Paulo: Pioneira, 2006
 Dicionário escolar da língua portuguesa/Academia Brasileira de Letras. 2ª edição. São
Paulo. Companhia Editora Nacional. 2008. p. 922.
 COLOMBO, Sônia Simões: Gestão educacional: uma nova visão. Porto Alegre:
Artmed, 2004. 262 p.
 55

 DATE, C. J. An Introduction to Database Systems, 8thEdition, Ed. Addison Wesley,

2003.
 BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar. UML – Guia do Usuário.
Rio de Janeiro: Campus, 2000.
 SANTOS, R.E.S.; MAGALHÃES, C.V.C; CORREIA NETO, J.S. 2009. Scrum –
Principais Vantagens do Método no Processo de Desenvolvimento de Software. In: Iº
Encontro Regional de Tecnologia e Negócios, UFRPE/UAST
 56

Glossário

Bootstrap: Framework fron-end baseado em css e Javascript para criação de páginas

web responsivas.

Composer: gestor de pacotes para a linguagem PHP que providencia dependências para
projectos.

Framework: é uma abstração que une códigos comuns entre vários projetos de software
provendo uma funcionalidade genérica.

Máquina Virtual: instância de um hardware virtualizado e um SO também

virtualizado normalmente sob a forma de simulação, ou seja, uma interface com o
ambiente, diferentemente da emulação que reflectiria todos os estados internos do
ambiente ao mesmo tempo.

Online - termo com origem inglesa e que se popularizou com o advento da Internet.
Significa estar disponível para acesso imediato a uma página de Internet, em tempo
real.

SQL: sigla para Structured Query Language, que é uma linguagem utilizada em
bancos de dados relacional.

Stored procedures: esse recurso consiste em comandos SQL "guardados" no servidor

para, por exemplo, executar tarefas repetitivas, evitando que um cliente tenha que
executá-las constantemente;

Schemas: recurso que permite cruzar informações em um mesmo banco de dados, mas
em estruturas diferentes;
 57

SSL: sigla para Secure Sockets Layer, que consiste em um protocolo para a troca
segura de informações.

Transactions: também conhecidas como transações, são instruções executadas em um

bloco designado por parâmetros que indicam seu início e seu fim;

Triggers: também chamados de gatilhos, são recursos que permitem o acionamento de

uma sequência de comandos logo em seguida ou logo após um evento;

Virtualização: técnica que permite que uma única máquina física execute dois ou
mais sistemas operativos simulando as mesmas características de uma máquina real.

Web Browser: aplicação que é utilizada para efectuar consultas e pesquisas à

informação que existe nas várias páginas Web, localizados em servidores remotos para
acesso via Internet
 58

Anexos
 59

1. Dicionário de dados

Tabela 5: Dicionários dos campos das tabelas

Usuario
Coluna Tipo Constraint Nulo Defeito
ID Character varying(15) PK N
Nome Character Varying(100) N
Email Character varying(30) S
Senha Character varying(60) N
Perfil_id Character(3) FK(Perfil) N
Confirmado boolean N false
Perfil
Coluna Tipo Constraint Nulo Defeito
ID Character(3) PK N
Nome Character varying(30) N
Permissoes json S
Estudante
ID Character varying(15) PK N
Nome Character varying(100) N
Curso_id Character(5) FK(Curso) N
Regime_id Character(3) FK(Regime) N
Delegacao_id Character(2) FK(Delegacao) N
Usuario_id Chaacter Varying(15) FK(Usuario) S
Curso
ID Character(5) PK N
Nome Character varying(30) N
Regime
ID Character(2) PK N
Nome Character varying(30) N
Delegacao
ID Character(2) PK N
Nome Character varying(30) N
Bolsa
ID Integer PK N Auto_inc
Estudante_id Character varying(30) FK(Estudante) S
Isenção Integer N
Pagamento
ID Integer PK N Auto_inc
Descritivo Character varying(30) N
 60

Operacao Character Varying(20) N

Data Timestamp N
Estudante_id Character(3) FK(Estudante) N
Recibo_id Integer FK(Recibo) S
Entidade Integer S
Referencia Integer S
Inscricao_id Intger FK(Inscricao) S
Recibo
ID Integer PK N Auto_inc
Estudante_id Character varying(15) FK(Estudante) N
Conta_bancaria_id Integer FK(Banco) N
Cod_comprovativo Integer N
Valor Numeric(15,2) N
Forma_pagamento Character varying(10) N
Recibo_descritivo
ID Integer PK N Auto_inc
Recibo_id Integer FK(Recibo) S
Descricao Character varying(100) N
Valor Numeric(15,2) N
Activo Boolean N False
Disciplina
ID Character varying(30) PK N
Nome Character varying(30) N
Curso_disciplina
ID Integer PK N Auto_inc
Disciplina_id Character varying(30) N
Curso_id Character(5) N
Nivel smallint N
Semestre smallint N
Tipo Character Varying(10) N Normal
Opcional smallint N 0
Precedencia Integer ID S
Turma
ID Character varying(36) PK N Auto_inc
Delegacao_id Character(2) FK(Delegacao) N
Curso_id Character(5) FK(Curos) N
Regime_id Character(3) FK(Regime) N
Nivel Integer N false
Semestre Integer N
 61

Ano_lectivo Integer N
Inscricao
ID Integer PK N Auto_inc
Estudante_id Character varying(30) FK(Estudante) N
Ano_lectivo Integer N
Semestre Integer N
Data Timestamp N Now()
Activo boolean N false
Inscrição_disciplina
ID Integer PK N Auto_inc
Disciplina_id Character varying(30) FK(Disciplina) N
Nivel Integer N
Activo boolean N false
Turma_id Character Varying(36) FK(Turma) N
Inscrição_id Integer FK(Inscricao) N
Banco
ID Integer PK N Auto_inc
Nome Character varying(30) N
Conta_bancaria
ID Character varying(15) PK N Auto_inc
Banco_id Integer FK(Banco) N
Entidade Integer N
Referencia_bancaria
ID Character varying(11) PK N Auto_inc
Estudante_id Character varying(15) FK(Estudante) N
Ano_lectivo Integer N
Referencia_import
ID Character varying(15) PK N Auto_inc
Referencia Character varying(11) FK(Referencia_ba N
ncaria)
Entidade Integer N
Valor Numeric(15,2) N
Data Date N
Usada Boolean N false
Adit.inscricao
ID Integer PK N Auto_inc
Estudante_id Character varying(30) FK(Estudante) N
Ano_lectivo Integer N
Semestre Integer N
 62

Data Timestamp N Now()

Activo boolean N false
Data_apagada Timestamp N Now()
Usuario_apagada Character varying(15) FK(Usuario) N
Adit.Log
ID Integer PK N Auto_inc
ficheiro Character varying(30) S
accao Character varying(60) N
sucesso Boolean N false
ip boolean N
data_reg timestamp N Now()
usuario_id Character varying(15) N
obs text S
new Json S
old Json S
metodo text S
linha integer S

2. Diagrama de Casos de Uso

Tabela 6: Diagrama de casos de uso
 63

3. Ferramentas de desenvolvimento
a. PhpStorm21: Interface do IDE

b. Homestead: Processo de início da máquina virtual

21
Disponível em https://jetbrains.com/phpstorm
 64

c. Composer: Estrutura do ficheiro de dependências do sistema

d. PgAdmin: Interface do administrador SGBD

 65

4. Interfaces do sistema22
a. O usuário deve providenciar as suas credenciais para aceder ao sistema.

Figura 17: Interface de Login

b. Dentro do menu Porta do Estudante, estará disponível o sub-menu de inscrição online,

o qual deverá fazer o clique com o rato ou dedo;

Figura 18: Menu para Inscrição

22
Disponível também em https://www.up.ac.mz/dra/8-departamentos/12-passos-para-inscricao-no-sigeup.html
 66

c. Caso não tenha confirmado o email ainda, será pedido que insira o endereço de email
para envio do email de confirmação.

Figura 19: Activação da conta

d. O sistema exibirá a mensagem de sucesso, caso tenha conseguido enviar o email e o

estudante já o tenha informado

Figura 20: Confirmação do envio de email

NB: Para o envio de emails, o sistema faz uso de um serviço de terceiro chamado mandril. O serviço é
grátis para os primeiros 12000 emails do mês.

A comunicação entre o serviço e o SIGEUP é feita através da biblioteca PHPMailer que é carregada
como dependência do sistema via Composer.
 67

e. Na figura seguinte, podemos ver o layout do email enviado pelo sistema, devendo o
estudante fazer clique sobre o link realçado na imagem.

Figura 21: Email de confirmação

Figura 22: Mensagem de confirmação

 68

Figura 23: Escolha das disciplinas normais

Figura 24: Escolha das cadeiras em atraso

Figura 25: Obter factura

 69

Figura 26: Relatório para pagamento

Figura 27: Importação do ficheiro do banco

Figura 28: Confirmação da importação

 70

Figura 29: Email de confirmação da inscrição

 71

5. Código Fonte do sistema

a) Método para fazer inscrição online
 72

b) Método para cancelar inscrição

 73

c) Métodos para confirmação da inscrição

 74

d) Método para gerar referência da inscrição

1