INSTITUTO SUPERIOR DE TECNOLOGIA DE INFORMAÇÃO E

COMUNICAÇÃO

SISTEMA DE GESTÃO DE MATRÍCULA E PAGAMENTO DO

COLÉGIO BETÂNIA

TRABALHO DE FIM DE CURSO DE LICENCIATURA EM

ENGENHARIA INFORMÁTICA

AUTOR: JOSÉ FELICIANO CUSSOIA

LUANDA, 2018
INSTITUTO SUPERIOR DE TECNOLOGIA DE INFORMAÇÃO E
COMUNICAÇÃO

SISTEMA DE GESTÃO DE MATRÍCULA E PAGAMENTO DO

COLÉGIO BETÂNIA

TRABALHO DE FIM DE CURSO DE LICENCIATURA EM

ENGENHARIA INFORMÁTICA

AUTOR: JOSÉ FELICIANO CUSSOIA

ORIENTADORA: MSC. GEIDIS SÁNCHEZ MICHEL

LUANDA, 2018
 AGRADECIMENTO
Agradeço primeiramente á Deus, por ter me concedido o fôlego de vida e as faculdades
preceptivas do assunto investigado a fim de que tornasse possível a realização deste
projecto. Aos meus pais pelo apoio moral e financeiro prestado durante os anos aqui
vividos, aos meus professores que foram incansáveis na transmissão dos conhecimentos,
principalmente a minha tutora MSc. Geidis Sánchez Michel e a todos aqueles que directa
ou indirectamente contribuíram para que este projecto se realizasse.

II
 RESUMO

A utilização dos recursos tecnológicos, pelo simples facto de agregá-los à educação,

permite a análise e a articulação entre informações no interior das unidades escolares e
sistemas de ensino possibilitando expectativas quanto ao aumento de produtividade e
qualidade de suas equipes administrativa e pedagógica.
Ter os dados académicos dos alunos armazenados de forma segura é algo muito
importante e relevante, além de ser um passo a frente para as instituições escolares. Isto
torna-se difícil quando este processo é de forma manual, mas não quando se tem um
sistema automatizado para tal. Com este intuito, no objectivo de solucionar esta situação,
desenvolveu-se um sistema académico denominado Sistema de Matrícula – SGMCB, que
tem como principal função o gerenciamento de alunos. O software desenvolvido, além de
fornecer o gerenciamento de alunos, professores, também apresenta os dados
(informações) em tabelas e gera relatório de alunos.
Palavras-chave: gestão académica, programação.

ABSTRACT
The use of the technological resources, for the simple fact of joining them to the education,
allows the analysis and the articulation among information inside the school units and
education systems making possible expectations as for the productivity increase and
quality of their administrative and pedagogic teams.
To have the stored students' in a safe way data academics is something very important
and relevant, besides being a step the front for the school institutions. This becomes difficult
when this process is in a manual way, but no when an automated system is had for such.
With this intention, in the objective of solving this situation, grew a system academic
denominated System of Registers-SGMCB, that has as main function the students'
administration. The developed software, besides supplying the students' administration,
advisor, also presents the data (information) in tables and it generates students' report.

Key-words: academic management, programming.

III
Índice Geral

INTRODUÇÃO ............................................................................................................................................... 1
CAPíTULO I- FUNDAMENTAÇÃO TEÓRICA......................................................................................... 5
1.1. Introdução ....................................................................................................................................... 5

1.2. Principais conceitos associados á sistema de gestão de matrícula e pagamento do

colégio Betânia .......................................................................................................................................... 5

Sistema de gestão escolar ................................................................................................................... 6

Sistema de gestão de matrícula .......................................................................................................... 6
1.3. Análise de soluções existentes e tendências actuais. ............................................................. 7

1.3.1. Campo internacional ............................................................................................................. 7

1.3.2. Campo nacional ................................................................................................................... 11
1.4. Metodologia utilizada, tendência e metodologias actuais ..................................................... 13

1.4.1. Metodologias robustas ou pesadas .................................................................................. 13

1.4.2. Metodologias Ágeis ............................................................................................................. 13
1.4.2.1. Open Up ............................................................................................................................ 14
1.4.2.2. Scrum ................................................................................................................................ 14
1.4.2.3. Xp (Extreme Programming) ........................................................................................... 14
1.5. Ferramentas que se apoia para a solução .................................................................................. 15

1.5.1. Visual Paradigm V13.1 ............................................................................................................ 15

1.5.2. NetBeans V8.2 .......................................................................................................................... 16
1.5.3. PostgreSQL V9.4.1 ................................................................................................................. 17
1.5.4. IReports V5.6 ............................................................................................................................ 17
1.5.5. Java V1.8.0............................................................................................................................... 18
1.5.6. Hibernate V5.2.10 ................................................................................................................... 19
1.6. Conclusões Parciais ........................................................................................................................ 19

CAPíTULO II- CARACTERÍSTICAS DO SISTEMA.............................................................................. 20

1.1. Introdução ..................................................................................................................................... 20

1.2. Modelagem do Negócio.............................................................................................................. 20

1.2.1. Modelo de domínio .............................................................................................................. 21

VI
 1.3. Modelagem do Sistema .............................................................................................................. 23

1.3.1. Especificação de Requerimentos do Sistema ................................................................ 23

1.3.2. Diagrama de Caso de Uso do Sistema ............................................................................ 26
1.3.3. Descrição de Caso de Uso do Sistema ........................................................................... 26
1.4. Conclusões Parciais.................................................................................................................... 32

CAPíTULO III- DESENHO, IMPLEMENTAÇÃO E PROVAS .............................................................. 33

3.1. Introdução ..................................................................................................................................... 33

3.2. Arquitectura do Sistema e Padrão de Desenho Utilizado ..................................................... 33

3.2.1. Arquitectura do Sistema ..................................................................................................... 33

3.2.2. Padrão de Desenho ............................................................................................................ 34
3.2.3. Padrão de Codificação ....................................................................................................... 37
3.3. Diagrama de Classe.................................................................................................................... 39

3.4. Análise e Desenho do Banco de Dados .................................................................................. 40

3.4.1. Modelo Físico do Banco de Dados ................................................................................... 40

3.4.2. Descrição das Entidades .................................................................................................... 41
3.5. Modelo de despliegue (implantação)........................................................................................ 42

3.5.1. Diagrama de Implantação .................................................................................................. 43

3.5.2. Descrição do modelo de implantação do sistema .......................................................... 43
3.6. Principais Interfaces do Sistema ............................................................................................... 44

3.7. Provas de Software ..................................................................................................................... 46

3.7.1. Estratégia de teste............................................................................................................... 46

3.7.2. Tipos de testes.......................................................................................................................... 47
3.8. Métodos de testes ....................................................................................................................... 48

3.8.1. Método de Teste Caixa Preta ............................................................................................ 48

3.8.2. Método de Teste Caixa Branca ......................................................................................... 50
3.9. Resultado das Provas ................................................................................................................. 52

3.9.1. Mecanismo de eficiência (Teste de aceitação) ............................................................... 52

3.10. Conclusões Parciais.................................................................................................................... 53

CONCLUSÕES ........................................................................................................................................ 54

RECOMENDAÇÕES .............................................................................................................................. 55

BIBLIOGRAFIA ........................................................................................................................................... 56
VII
Índice de Figuras
Figura 1-SCHOOL MANAGEMENT SYSTEM................................................................... 8
Figura 2-SISTEMA DE CONTROLE ACADÉMICO – ACADSISTEM................................ 9
Figura 3-SISTEMA DE CONTROLE ACADÊMICO ......................................................... 10
Figura 4-G-SCHOOL PRO .............................................................................................. 11
Figura 5-Sistema de Gestão de Cursos de curta duração .............................................. 12
Figura 6-Diagrama de Modelo de Domínio de Classe ..................................................... 21
Figura 7-Diagrama de Caso de Uso do Sistema ............................................................. 26
Figura 8-Arquitectura mvc da classe curso ..................................................................... 34
Figura 9-Fragmento do código getConnection ................................................................ 36
Figura 10-Subsistema da interface VistaAluno................................................................ 37
Figura 11-Fragmento do Código getListTurma................................................................ 38
Figura 12-Diagrama de classe ........................................................................................ 39
Figura 13-Módulo Matrícula............................................................................................. 40
Figura 14-Módulo Pedagógico ........................................................................................ 41
Figura 15-Módulo Pagamento ......................................................................................... 41
Figura 16-Diagrama de implantação ............................................................................... 43
Figura 17-Tela do Login .................................................................................................. 44
Figura 18-Tela Gerir Estudante ....................................................................................... 45
Figura 19-Tela Gerir Professor ........................................................................................ 45
Figura 20-Tela Gerir Turma ............................................................................................. 46
Figura 21-Código fonte salvar Curso ............................................................................... 50
Figura 22-Gráfico de fluxo ............................................................................................... 51
Figura 23-Gráfico do Resultado das Provas.................................................................... 52

Índice de Tabela
Tabela 1-Requisitos Funcionais ...................................................................................... 24
Tabela 2-RNF Usabilidade .............................................................................................. 25
Tabela 3-RNF Disponibilidade......................................................................................... 25
Tabela 4-RNF Confidencialidade .................................................................................... 25
Tabela 5-RNF Segurança................................................................................................ 25
VIII
Tabela 6-Aparência ou interface externa ........................................................................ 25
Tabela 7-RNF Apoio........................................................................................................ 25
Tabela 8-RNF Hardware ................................................................................................. 26
Tabela 9-Actores do Sistema .......................................................................................... 26
Tabela 10-DCUS. Autenticar. Usuário ............................................................................. 26
Tabela 11-DCUS. Gerir Usuário ...................................................................................... 27
Tabela 12-DCUS. Gerir Matrícula ................................................................................... 29
Tabela 13-DCUS. Gerir Pagamento ................................................................................ 31
Tabela 14-Descrição das Entidades da Base de Dados ................................................. 41
Tabela 15-Descrição do Modelo de Implantação ............................................................ 43
Tabela 16-Cenário de Prova (Cadastrar Professor) ........................................................ 49
Tabela 17- Mecanismo de Eficiência ............................................................................... 53

IX
 INTRODUÇÃO
Ao longo do tempo tem-se notado o crescente desenvolvimento das Tecnologias de
Informação e Comunicação (TIC), a um ritmo acentuado, visto que o homem é um ser
inovador com capacidades de actualização. Desde então o homem como ser pensante
sempre teve a ideia de simplificar as suas tarefas, isto é, a transformação da dificuldade em
simplicidade.

O cotidiano de actividades desenvolvidas pelo ser humano em sua jornada de trabalho tem
tornando-se cada vez mais complexo e no mercado competitivo que se enfrentam nos dias
actuais, exige-se um maior e mais eficaz controle de todo o funcionamento da gerência do
negócio de uma simples empresa a uma grande indústria, nos diversos ramos existentes,
necessitando para isso de um apoio computacional que seja capaz de facilitar todo esse
mecanismo, tornando a tomada de decisões e a produção humana mais optimizada, segura
e organizada.

Se observa que o aparecimento da informática é uma necessidade, pois ela surgiu para
superar a dificuldade do ser humano de registar e manipular dados em grandes quantidades
com precisão. Um exemplo de uso das tecnologias pode-se observar em algumas escolas,
geralmente na área da secretaria para agilizar, organizar e fazer melhor seu trabalho. É muito
importante fazer o trabalho desta maneira porque as pessoas resolvem dúvidas e realizam
gestões de forma rápida. Também o bom trato, a eficácia nas gestões e a claridade da
informação que facilitam e permitem multiplicar o efeito positivo.

O Colégio Betânia, é uma instituição de formação situado no distrito do Rangel, dedicado na

formação de estudantes nos cursos que conformam um vasto conhecimento nas áreas de
PUNIV (Pré-Universitário) e INFORMÁTICA.
O armazenamento de informação cresce a cada ano nesta instituição. Levando assim um
aumento de volume de informação acumulada durante o funcionamento das actividades da
instituição. Este crescimento dificulta a manutenção das informações.
A manipulação dos arquivos demanda espaço físico, na medida que registos vão
aumentando, além de papel ser material facilmente degradável, o que pode ocasionar perda
de registos, além disso, o seu manuseio é delicado.
O colégio Betânia apresenta dificuldades no processo de matrícula de alunos, tal como a sua
distribuição em turmas. Os dados dos candidatos a inscrição para a matrícula são registrados

1
em fichas de matrícula imprensa. As informações de cadastro dos alunos são arquivadas em
formulários.
Com o andar do tempo, a quantidade de dados vai aumentando o que implica que a
quantidade de papeis também vai crescendo, vai se tornando mais difícil fazer a manutenção,
como também muitas consultas desejadas.
Por razões anteriormente expostas fica proposto o seguinte problema da investigação:
como garantir o processo de gestão de matrículas, e pagamentos do colégio Betânia?

Fica definido como objecto de estudo da presente investigação: processo de gestão de

matrículas e pagamentos.
Como seu campo de Acção: sistema de gestão de matrícula e pagamentos para o colégio
Betânia.
Para dar-lhe solução ao problema antes descrito se tem como objectivo geral: desenvolver
um sistema de gestão de matrícula e pagamento para o colégio Betânia.
Para dar-lhe solução ao objectivo geral se definem os seguintes objetivos específicos:

1. Elaborar o marco teórico da investigação mediante a partir do estado da arte sobre o

desenvolvimento dos sistemas de gestão de matrícula e pagamento do colégio
Betânia.
2. Identificar os requisitos funcionais e não funcionais sistemas de gestão de matrícula
e pagamento do colégio Betânia.
3. Desenhar o sistema de gestão de matrícula e pagamento do colégio Betânia.
4. Implementar sistemas de gestão de matrícula e pagamento do colégio Betânia.
5. Avaliar a proposta de solução mediante provas de software.

As tarefas da investigação para dar cumprimento aos objectivos propostos são:

1. Estudo do estado da arte sobre o sistema de gestão de matrícula e pagamento

para a construção do marco teórico da investigação.
2. Caracterização dos metodologias, ferramentas e tecnologias para o
desenvolvimento do sistema de gestão de matrícula e pagamento do colégio
Betânia.
3. Obtenção dos requisitos funcionais e não funcionais do sistema.
4. Definição da arquitectura de software para o sistema de gestão de matrícula e
pagamento do colégio Betânia.
5. Desenho do sistema de gestão de matrícula e pagamento do colégio Betânia.
6. Implementação do sistema de gestão de matrícula e pagamento do colégio Betânia.
2
 7. Realização das provas de software para validar o correcto funcionamento do
sistema de gestão de matrícula e pagamento do colégio Betânia.
Fica definido como ideia a defender da presente investigação: com a implementação do
sistema de gestão de matrícula e pagamento, garante-se aumentar a eficiência do
processo de gestão de matrícula e pagamento.

Durante a investigação, foram utilizados os seguintes métodos científicos:

Os métodos teóricos são utilizados na adoção de teoria científica e na abordagem geral
para abordar problemas científicos, possibilitando a interpretação conceitual de dados
empíricos e a explicação dos factos. Eles estão presentes nos vários momentos do
processo de pesquisa e durante a análise e compreensão das informações utilizadas para
o processo de desenvolvimento (Coello González & Hernández León, 2011).

Métodos Teóricos
• História Lógica: Um estudo do estado da arte é realizado nos projectos, soluções e
resultados das escolas que contribuem para definir e orientar a realização deste trabalho.
• Analítica Sintética: Análise da documentação e em diversas fontes das escolas sobre a
implementação de Sistemas de Gestão e o uso de ferramentas e tecnologias em função
deles.
• Modelagem: abstrações são criadas com o propósito de explicar a realidade. O modelo
é o substituto do objecto de pesquisa. Os diagramas correspondentes aos modelos de
análise, desenho e implementação do Módulo de Controle para o sistema de
gerenciamento em questão são feitos.

Métodos empíricos
• Entrevistas: Várias entrevistas estruturadas são realizadas com os funcionários do
colégio, a fim de identificar os processos existentes no negócio e capturar os requisitos
que são fundamentais na implementação.
A estrutura do trabalho investigativo foi constituída em três capítulos, conclusões,
referências bibliográficas e anexos.
Este trabalho encontra-se composto por três capítulos, um resumo, uma introdução,
conclusão, recomendações, referências bibliográficas e anexos. Os aspectos principais
de cada capítulo são abordados em seguida:

3
Capítulo 1: Fundamentação teórica. Neste capítulo se especificam os principais conceitos
relacionados com o tema, realiza-se o estudo do estado da arte a nível nacional e
internacional sobre os Sistemas de Gestão Académico. Também se definem as
ferramentas, metodológicas e tecnológicas a utilizar durante o desenvolvimento do
sistema.

Capítulo 2: Características do sistema. Este capítulo apresenta os artefactos gerados nas

actividades de análise e modelagem do sistema, estes que são uma descrição geral da
solução proposta e do seu funcionamento. Se apresenta uma análise de negócio,
descrição do Actor e especificação dos requisitos funcionais e não funcionais do sistema,
diagrama de caso de uso do sistema, bem como as suas descrições e protótipo de
interface do sistema.

Capítulo 3: Desenho, Desenvolvimento e Provas do Sistema Informático. Neste capitulo

se abordam aspectos relacionados com o desenho, desenvolvimento e provas do sistema,
desta forma se realiza a modelação detalhada e a construção da estrutura do sistema
informático obtendo como artefacto diagrama de classes, modelo físico do banco de
dados, diagrama de implantação, e finalmente documentam-se as provas realizada sobre
o sistema informático, feita para verificar se o sistema corresponde ao que foi especificado
e detectar falhas no sistema informático.

4
CAPíTULO I- FUNDAMENTAÇÃO TEÓRICA

1.1. Introdução

No capítulo se apresentam os conceitos fundamentais que constituem a base teórica dos

processos de gestão de matrículas, e pagamentos. Se realizará um estudo homologo
sobre as diferentes alternativas aplicadas durante o processo de gestão de matrículas
existentes a nível nacional e internacional. Se analisaram as metodologias de
desenvolvimento de software, tecnologias e ferramentas actuais que guiarão o processo
de desenvolvimento de software e se selecionarão aquelas a utilizar durante o
desenvolvimento da solução que se propõe.

1.2. Principais conceitos associados á sistema de gestão de matrícula

e pagamento do colégio Betânia

Os conceitos que se definem a continuação neste capítulo estão relacionados com o

objecto de estudo desta investigação para o melhor entendimento dos aspectos que se
abordarão posteriormente.

Colégio pode ser definida como uma instituição que tem o encargo de educar, segundo
programas e planos sistemáticos, os indivíduos nas diferentes idades da sua formação.
Conjunto formados por alunos, professores e outros funcionários de um estabelecimento
de ensino. [PORTO EDITORA, 2015]

A matrícula é o ato formal de ingresso e de vinculação do aluno à Instituição de Ensino

realizada no período determinado pelo Calendário Académico. [VALENTIM, ET AL.,
2014]

A matrícula é o ato pelo qual o aluno aprovado em processo seletivo é admitido

regularmente em um dos cursos de Pós-Graduação da Universidade. [UNICAMP, 2016]

Pagamento é a forma de liberação do devedor, mediante a prestação do obrigado, ou

seja, modalidade extintiva voluntária ou normal da obrigação. O desfecho natural da
obrigação é o seu cumprimento.

Gestão significa gerenciamento, administração, onde existe uma instituição, uma

empresa, uma entidade social de pessoas, a ser gerida ou administrada. O objetivo é de
crescimento, estabelecido pela empresa através do esforço humano organizado, pelo

5
grupo, com um objetivo específico. As instituições podem ser privadas, sociedades de
economia mista, com ou sem fins lucrativos (Kruthiventi, 2012).

Sistema de gestão escolar

Sistema de gestão escolar é um programa de computador que torna automáticos os

procedimentos burocráticos de uma instituição de ensino. Desse modo, o dia-a-dia das
escolas ou colégio ou curso torna-se mais fácil, já que o sistema permite registrar dados
e emitir documentos automaticamente, sem a necessidade de se procurar informações
em meio à papelada.

Um bom sistema de gestão escolar consegue integrar os sectores acadêmico, pedagógico

e financeiro de uma escola ou curso. Ou seja: O programa é capaz de realizar diversas
tarefas, desde calcular as notas dos alunos até emitir boletos de cobrança.

Um sistema de gestão escolar é um investimento importante para qualquer escola ou

curso. Porém, para escolher bem um sistema para sua instituição, você precisa levar em
consideração alguns factores. É preciso levar em conta quais são as reais necessidades
do seu estabelecimento, pois assim você não corre o risco de adquirir algo que não vá
utilizar. Além disso, você precisa conhecer características do sistema que vai comprar,
para saber se será fácil e prático usá-lo. [WPENSAR, 2017]

Sistema de gestão de matrícula

São sistemas preparados para auxiliar no processo de matrícula, avaliações, pagamentos

dos estudantes nas instituições de ensino. Estas funcionalidades vêm incluídas em um
único sistema e agregam também outras funcionalidades. Estes sistemas permitem a
realização de matrícula, confirmação matrícula, cancelamento matrícula, inscrição em
disciplinas, Lançamento de notas de avaliações contínua e resultado de provas bem como
geração relatórios, pautas, declarações, gestão de turma, etc.

Depois de ter analisado os conceitos definidos por outros autores, o autor do presente
trabalho define como conceito o seguinte:

Matrícula escolar é um contrato firmado entre uma instituição de ensino e os pais ou

responsáveis por uma criança, adolescente ou por alguém adulto. O processo de inscrição
é a garantia a uma vaga na instituição na qual pretende formar-se.

6
Pagamento é o cumprimento de um acordo abordado pelo devedor e a organização
prestadora de serviços, em outras palavras define-se pagamento como aquilo que é dado
em troca de serviço.

1.3. Análise de soluções existentes e tendências actuais.

No mundo existem numerosos sistemas de gestão de matrículas, avaliações e
pagamentos que têm sido desenvolvidos com o propósito de satisfazer as necessidades
existentes em diferentes organizações. Neste epigrafe se descreverá as características
de alguns sistemas existente a nível nacional e internacionais no qual permitem gerir o
processo de matrículas, avaliações e pagamentos dos formandos ou alunos.

1.3.1. Campo internacional

SCHOOL MANAGEMENT SYSTEM

Sistema americano, criado pelo Sr. Kean Tak, MSc, conferencista e Gerente de Projetos
de TI do Departamento de Ciência da Computação @ RUPP. O sistema é para
automatizar o gerenciamento de estudantes, turmas e professores em qualquer escola de
médio porte. Criada especialmente para cumprir os requisitos de escolas pequenas e
médias que cobrem todos os aspectos da escola gerenciamento de informações como
segue: [TAK, 2008]
Recursos disponíveis:
1. Gestão da informação do aluno
2. Gerenciamento de informações de classe
3. Gestão de sessões de ensino
4. Gestão de atendimento a estudantes
5. Relatório de resultados iniciais dos alunos
6. Relatório de resultados de exames de estudantes
7. Relatório de tutores temporários
8. Relatório de sessões canceladas
9. Gerenciamento de usuários
10. Trabalho multiusuário em LAN

Para termos mais ideia sobre o sistema descrito acima, a figura 1 abaixo apresenta a sua
interface que permite a interação com o usuário.

7
 Figura 1-SCHOOL MANAGEMENT SYSTEM

SISTEMA DE CONTROLE ACADÉMICO – ACADSISTEM

O sistema de controle académico – ACADSISTEM é um sistema de origem brasileira, feito

para ser utilizado via web.

O Sistema de Controle Académico – ACADSISTEM é um sistema que tem como principal

função o gerenciamento de alunos, orientadores e publicações. O software desenvolvido,
além de fornecer o gerenciamento de alunos, orientadores e publicações, também
apresenta os dados (informações) em tabelas e gera relatório de aluno.

O sistema desenvolvido - ACADSISTEM - proporcionou a universidade o cadastro e

gerenciamento de alunos, usuários, orientadores e publicações.

Nesta versão do software, foi implementado visualização em tabelas os dados destes

alunos, usuários, orientadores e publicações. Foi implementado também, a possibilidade
de usuários tanto administradores quanto comuns fazer upload de publicações de alunos
da universidade.

Para próximas versões será implementado o gerenciamento de matérias, para um melhor

relacionamento entre matérias e alunos. E o software será aplicado no sistema de
graduação da universidade, pois nesta primeira versão, o software foi implementado para
o sistema de pós-graduação da universidade.

Uma dificuldade encontrada neste trabalho foi a elaboração das interfaces de integração
com o usuário. Pois as interfaces do sistema exigiram diversos protótipos de tela até que
se chegasse ao resultado final aprovado pelo cliente. Definir as necessidades do usuário

8
ao elaborar uma interface incomum é um trabalho muito complexo. Este trabalho
contribuiu para o aprimoramento dos processos da Universidade Federal de Pelotas –
UFPel [PARAISO, 2011].

Para saber mais a respeito deste sistema observe a figura 2.

Figura 2-SISTEMA DE CONTROLE ACADÉMICO – ACADSISTEM

SGA

O SGA é um sistema de gestão académica desenvolvido pela Expoente Soluções

Comerciais e Educacionais de origem brasileira, feito para ser utilizado via web (por
intermédio de um browser), o mesmo permite gerir os recursos físicos, humanos,
financeiros e materiais. Segundo a empresa, o SGA foi concebido para os diversos níveis
de ensino. Por ser um sistema web, oferece facilidade no facto de que não é necessário
instala-lo para usar.

Como outros sistemas de gestão, o SGA é composto por módulos e citados alguns:

Módulo de turma: É neste módulo em que os alunos são distribuídos nas turmas de
acordo com as regras de negócio da escola. Outras funções:

1. Turma;
2. Disciplina da turma;
3. Matrícula da turma;
4. Horário;
5. Relatório das actividades extracurriculares, etc.

9
Módulo de avaliação: Este módulo permite configurar um sistema de avaliação da escola.
Tem um funcionamento como a plataforma de ensino a distância Moodle.
[EDUCACIONAIS, 2016]

SISTEMA DE CONTROLE ACADÊMICO

O sistema brasileiro, dividido em três módulos referentes aos perfis dos usuários que
utilizarão o sistema, sendo um módulo para a secretaria, um módulo para os professores
e um módulo para os alunos, e cada módulo foi dividido em sub-módulos específicos para
cada perfil. Assim, a área da secretaria conta com funções que auxiliarão a secretária a
cadastrar alunos, professores, novas turmas e fazer a emissão dos boletins acadêmicos.
A área dos professores conta com todos os recursos necessários para gerenciar
trabalhos, provas, notas e fazer a frequência diária dos alunos. A área dos alunos
apresenta os sub-módulos necessários para que eles possam ter melhor
acompanhamento de suas notas e faltas e maior simplicidade na entrega dos trabalhos.
[SILVA, 2015]
Depois da descrição acima referida, numas simples imagens resume-se com a figura 3
abaixo referenciada.

Figura 3-SISTEMA DE CONTROLE ACADÊMICO

10
1.3.2. Campo nacional

G-SCHOOL PRO

O G-SCHOOL PRO é um sistema nacional que resolve problemas de vasta dimensão,

considera-se sistema de gestão integrada conforme já identificado constitui de vários
módulos.

O sistema foi desenvolvido com a linguagem de programação (JAVA), tem o suporte de

uma base de dados MYSQL com possibilidades de migração para outros sistemas de
gestão de base de dados se o cliente assim o preferir, garantindo assim armazenamento
de dados infinitos e para toda vida. O sistema funciona com um único computador ou em
N computadores em simultâneo, desde que haja uma estrutura de rede montada para o
efeito. É um sistema integrado de gestão escolar, surgiu para dar suporte às instituições
escolares públicas e privadas. É um software fiável, rápido, eficiente e muito fácil de se
usar.

Este software fornece-nos a gestão dos seguintes módulos: Gestão de encarregados de

educação, gestão de inscrições, gestão de matrículas, gestão de confirmações de
matrículas, anulação de matrículas, gestão de pagamentos de propinas, gestão de
pagamentos diversos, gestão de utilizadores, gestão de relatórios, gestão de notas,
gestão de horários, gestão de docentes, gestão de pautas e mini pautas, boletins de notas.
[RAMOSSOFT, 2015]

Em síntese a figura 4 abaixo referida mostra como esta organizado o sistema G-SCHOOL
PRO

Figura 4-G-SCHOOL PRO

11
Sistema de Gestão de Cursos de curta duração

O sistema de gestão de cursos de curta duração é um sistema que faz a gestão de

matrículas de alunos, cursos, professores e também organiza os alunos em listas nominais
e gera certificado. É o sistema desenvolvido para satisfazer ou atender as necessidades
do centro do Instituto Superior de Tecnologia de Informação e Comunicação (ISUTIC).
[Sapalo, 2015]

A figura 5 apresenta a interface de utilizador de como se gere o processo de cadastro do

aluno.

Figura 5-Sistema de Gestão de Cursos de curta duração

Depois de fazer uma descrição das principais características dos sistemas nacionais e
internacionais existentes no mercado que faz gestão dos processos de matrícula e
pagamento, descritas acima, o autor da presente investigação chegou a conclusão de que
seriam óptimas soluções para a resolução do problema, se não fossem os seguintes
factores:
• Os sistemas foram desenvolvidos para uma instituição.

• Os sistemas estão adaptados à legislação de outros países.

• Geração de relatórios diferentes do que o que se necessita.

• As funcionalidades existentes nos sistemas não cumprem com as que

foram solicitados pelo colégio Betânia.
Em síntese se necessita fazer um novo aplicativo que contem as características
inexistentes nas soluções citadas a cima.

12
1.4. Metodologia utilizada, tendência e metodologias actuais

Quando se elabora um projecto de software é importante percorrer uma série de passos

previsíveis, isto é, um roteiro que ajuda a criar a tempo um resultado de alta qualidade. O
roteiro que se segue é chamado de Metodologia ou processo de Software. As
metodologias de desenvolvimento de software são muito importantes porque, fornecem
estabilidade, controle e organização para uma atividade que pode, se deixada sem
controlo, bastante caótica. Existem diversos mecanismos de avaliação de metodologia de
desenvolvimento de software que permite as organizações ou desenvolvedores
determinar a maturidade da sua metodologia. Toda via a qualidade, pontualidade e
viabilidade a longo prazo do produto que se constrói são os melhores indicadores da
eficácia da metodologia usada. Em nível de detalhe, o processo adotado depende do
software que se está construindo. Por exemplo uma metodologia poderia ser apropriada
para criação de softwares para sistemas aviônica de uma aeronave enquanto um
processo inteiramente diferente seria indicado para criação de um site. (S.Pressman,
2010)

As metodologias de desenvolvimento de software encontram-se divididas em dois grandes

grupos: as robustas ou pesadas e ágeis.

1.4.1. Metodologias robustas ou pesadas

As metodologias pesadas têm maior ênfase na planificação e controlo do projecto, assim

como na especificação precisa de requisitos. Centram-se especialmente no controlo do
processo mediante uma rigorosa definição de roles, actividades, artefactos, ferramentas
e notações. Tipos de metodologias pesadas incluem: RUP (RATIONAL UNIFIED
PROCESS), ICONIX, MSF (MICROSOFT SOLUTION FRAMEWORK).

1.4.2. Metodologias Ágeis

Métodos de desenvolvimento de software que aplicam o desenvolvimento iterativo

empregam o planeamento adaptativo, promovem a entrega incremental, incluem outros
valores e práticas que encorajam a agilidade - resposta rápida e flexível às mudanças.
Tipos de metodologias ágeis: XP (EXTREME PROGRAMMING), OPENUP E SCRUM
(Carvalho & Mello, 2009).

13
1.4.2.1. Open Up

Um modelo de desenvolvimento de software, desenvolvido pela fundação Eclipse. Esta

preserva as melhores práticas de RUP (segundo suas siglas em inglês Rational Unified
Process, Processo Racional Unificado), entre suas principais características se mantém
um desenvolvimento iterativo e incremental, dirigido por casos de uso e centrado na
arquitectura para reduzir ao mínimo os riscos e organizar o desenvolvimento
(PRESSMAN, 2009).

Esta metodologia está desenhada para equipas pequenas já que se espera obter
resultados num curto período de tempo e utilizar os processos, produtos, papéis, e tarefas
que sejam indispensáveis para o mesmo. Por ser uma metodologia ágil tem um enfoque
centrado ao cliente e com iterações curtas. O ciclo de vida do Open Up consiste em quatro
fases: concepção, elaboração, construção e transição.

1.4.2.2. Scrum

Desenvolvido por Ken Schwaber, Jeff Sutherland e Mike Beedle. Define um marco para a
gestão de projetos, que se utilizou com sucesso durante os últimos 10 anos. Está
especialmente indicada para projetos com uma rápida mudança de requisitos. Suas
principais características se podem resumir em duas.

O desenvolvimento de software se realiza mediante iterações, denominados SPRINTS,

com uma duração de 30 dias. O resultado de cada Sprint é um incremento executável que
se mostra ao cliente. A segunda característica importante são as reuniões ao longo
projeto, entre elas se destaca a reunião diária de 15 minutos da equipe de
desenvolvimento para coordenação e integração (Informáticas, 2013).

1.4.2.3. Xp (Extreme Programming)

O XP é uma metodologia ágil para equipes pequenas e médias que desenvolvem software
baseado em requisitos vagos e que se modificam rapidamente. Entre as principais
diferenças da XP em relação às metodologias clássicas estão o feedback constante, a
abordagem incremental e o encorajamento da comunicação entre as pessoas (CASTRO,
2007).

14
O principal objectivo da XP é dar agilidade ao desenvolvimento do projeto e busca garantir
a satisfação do cliente. As práticas, regras, e os valores da XP garantem um agradável
ambiente de desenvolvimento de software para os seus seguidores, que são conduzidos
por quatro princípios básicos:

1. Princípio da Comunicação;
2. Princípio da Simplicidade;
3. Princípio do Feedback e
4. Princípio da Coragem.

Metodologia a utilizar
O software será desenvolvido por meio da metodologia Open UP. Open Up é uma
metodologia de software baseada em RUP que contém um conjunto mínimo de práticas e
regras que ajudam no desenvolvimento de um software a realizar um produto de alta
qualidade de uma forma eficiente.
Algumas razões para escolha da metodologia:
1. Processo iterativo e incremental que é o Mínimo, Completo e Extensível;
2. Evita a Permite detectar erros adiantados a través de um ciclo iterativo.
3. Por ser uma metodologia ágil e ter um enfoque centrado ao cliente e com iterações
curtas;

1.5. Ferramentas que se apoia para a solução

Na atualidade existe uma grande revolução dos meios informáticos, onde os avanços das
novas tecnologias têm o propósito de oferecer soluções adaptáveis as exigências do
usuário final. A integração das tecnologias de desenvolvimento com as ferramentas, vão
surgindo como alternativa que permite elaborar aplicação desktop e outras para a gestão
da informação, facilitando assim a interação dos usuários com os sectores envolvidos na
problemática.

1.5.1. Visual Paradigm V13.1

Visual Paradigm é um poderoso, multiplataforma e, mas fácil de usar ferramenta de

modelagem UML e CASE visual. Visual Paradigm fornece aos desenvolvedores de
software da plataforma de desenvolvimento de ponta para construir aplicações de
qualidade mais rápida, melhor e mais barato! Ele facilita a excelente interoperabilidade

15
com outras ferramentas CASE e na maioria das IDEs líderes que supera todo o seu
processo de desenvolvimento Model-Code-Deploy nesta solução one-stop-shopping.
[VISUAL-PARADIGM CORPORATION, 2015]
É uma ferramenta que utiliza a linguagem de modelado estândar UML, permite a geração
de códigos e engenharia inversa. Esta ferramenta multiplataforma que se pode utilizar
tanto em Linux como em Windows. A mesma fornece um conjunto de ajudas para o
desenvolvimento de programas informáticos, desde a planificação, passando por análises
e o desenho, até a geração do código para entorno integrado de desenvolvimento tais
como: NetBeans, Eclipse, Oracle JDeveloper e JBuilder.

Vantagens que proporciona:

1. Têm uma interface muito intuitiva e é fácil de aprender para os desenvolvedores.

2. Permite a geração automática de diagramas a partir de descrições de casos de usos.
3. Permite fazer descrição dos casos de uso dando ma grande variedade de janelas
predeterminadas permitindo personaliza-las.
4. Combina as funcionalidades de todas as edições numa ampla plataforma de
modelagem visual.

1.5.2. NetBeans V8.2

A maioria dos desenvolvedores reconhecem o NetBeans IDE como o IDE Java livre
originais. É isso, e muito mais! O NetBeans IDE oferece suporte para várias linguagens
(PHP, JavaFX, C / C ++, Javascript, etc.) e Framework.

NetBeans é um projecto open-source dedicada ao fornecimento de produtos de

desenvolvimento de software rocha sólida (o NetBeans IDE e a plataforma NetBeans) que
abordam as necessidades dos desenvolvedores, usuários e as empresas que contam com
NetBeans como base para os seus produtos; particularmente, para que possam
desenvolver esses produtos de forma rápida, eficiente e fácil, aproveitando os pontos
fortes da plataforma Java e outros padrões relevantes da indústria. [ORACLE
CORPORATION, 2015]

Versão 8.2 é um IDE de baixa licença e de código aberto. Esta ferramenta tem a finalidade
de permitir aos desenvolvedores criar diferentes sistemas e projectos orientados sobre
toda criação de soluções em linguagem java. O Netbeans tem muitas Vantagens que são:

1. Software multiplataforma.

16
2. Disponibiliza várias ferramentas
3. Fácil de usar e seu ambiente visual facilita a interação com o desenvolvedor.
4. Auxilia o programador na criação do código e é gratuito.

1.5.3. PostgreSQL V9.4.1

O postgresql 9.4.1 é um dos motores de base de dados relacionais mais potentes que
existe atualmente. Pois, permite executar consultas SQL, as quais possibilitam actualizar,
insertar, eliminar e realizar reportes sobre os dados armazenados em ficheiros ou base
de dados.

O PostgreSQL possui características sofisticadas tais como Multi-Versão Controle de

Concorrência (MVCC), ponto no tempo de recuperação, espaços de tabela, a replicação
assíncrona, transações aninhadas (savepoints), on-line / backups quentes, um sofisticado
planejador de consultas / optimizador, e escrever frente log para tolerância a falhas. Ele
suporta conjuntos de caracteres internacionais, codificações de caracteres de vários
bytes, Unicode, e é local-aware para a classificação, maiúsculas e minúsculas, e
formatação. É altamente escalável tanto na enorme quantidade de dados que podem
gerenciar e no número de usuários simultâneos que podem acomodar. Existem sistemas
PostgreSQL ativos em ambientes de produção que gerem em excesso de 4 terabytes de
dados. [POSTGRESQL GLOBAL DEVELOPMENT GROUP, 2015]

Este gestor oferece muitas vantagens com respeito aos sistemas de base de dados que
são:
1. Multiplataforma: Postgresql está disponível em várias plataformas como Linux,
Windows e Mac OS.
2. O código fonte está disponível para todos de maneira gratuita.

1.5.4. IReports V5.6

O iReport é uma ferramenta desenvolvida pela mesma empresa do JasperReports,

a JasperForge, e por isso é muito comum ver os dois sendo usados em conjunto. Uma
das dificuldades ao trabalhar com os relatórios, está na definição do layout. É complicado
escrever o layout totalmente em XML, sem ter que se aprofundar em todas as tags e

17
atributos possíveis, e além disso posicionar todos os elementos corretamente. Na prática,
é muito raro alguém editar o JRXML manualmente, e sim apenas para fazer alguns
pequenos ajustes quando necessários. O processo normal é utilizar alguma ferramenta
para gerar o JRXML automaticamente, e o iReport é utilizado com esse propósito.

O iReport é um aplicativo gráfico, que permite que você “desenhe” um relatório, utilizando
uma palheta, e arrastando e soltando componentes, de forma bem-parecida com a criação
de interfaces e janelas para programa. Ao salvar, automaticamente será gerado um
JRXML que você poderá utilizar na aplicação que estiver desenvolvendo. A vantagem é
que não é necessário que você conheça a fundo o XML. [MARTINS, 2010]

Vantagens que proporciona:

1. Aplicativo gráfico de desenho de relatório livre, multiplataforma, integração fácil com

java, fácil uso e aprendizagem.
2. É capaz de exportar relatórios para diversos formatos diferentes, tais como PDF,
HTML, XML, XLS, etc.
3. Aceita diversas formas de entrada de dados, tais como um arquivo XML ou CSV,
conexão com o banco de dados, uma colecção de objetos em memória, etc.

1.5.5. Java V1.8.0

Java é uma excelente linguagem de programação orientada a objetos. Ela tem

proporcionado muitos benefícios para os desenvolvedores de software, incluindo uma boa
abordagem orientada a objeto, gerenciamento de memória implícita e vinculação
dinâmica, entre outros. Estas características linguísticas são uma das principais razões
para a popularidade de Java e uma ampla aceitação. Mas Java é muito mais do que uma
linguagem de programação. É uma plataforma de desenvolvimento conjunto. Isso significa
que ela vem com um ambiente de tempo de execução (JRE), que fornece a máquina
virtual, e as interfaces de programação de aplicativos (APIs padronizadas) que ajudam os
desenvolvedores realizar a maioria de suas tarefas desejadas. As principais vantagens
deste ambiente integrado de tempo de execução são a sua independência de plataforma
verdadeira e simplificação do desenvolvimento de software. [BOSANAC, 2007]

O Java é hoje a linguagem mais utilizada em todo o mundo, isso acontece porque ela não
é somente uma linguagem, mas também uma plataforma de desenvolvimento. Onde uma

18
 das suas principais vantagens é que ele além de ser uma linguagem é uma plataforma de
desenvolvimento. Com ele é possível desenvolver aplicações para desktop, celular,
cartão, web, televisão digital. [GUILHERME, 2009]

1.5.6. Hibernate V5.2.10

O Hibernate é um Java FrameWork responsável por realizar a persistência dos dados no

Banco de Dados utilizando o Mapeamento Objeto-Relacional. Ele funciona como um
MiddleWare, uma camada que está entre a aplicação e o Banco de Dados, servindo
como um intermediário e diminuindo a complexidade da programação, reduzindo
substancialmente o tempo de desenvolvimento.
Ele facilita o mapeamento dos atributos entre uma base tradicional de dados relacionais
e o modelo objeto de uma aplicação, mediante o uso de arquivos XML para estabelecer
esta relação.

Sua principal característica é a transformação das classes (POJO) e tipos de dados do

Java para tabelas e tipos de dados SQL. O Hibernate gera as chamadas SQL (Select,
Insert, Join, Triggers...) e libera o desenvolvedor do trabalho manual da conversão dos
dados resultantes, mantendo o programa portável para qualquer banco de dados SQL,
porém causando um pequeno aumento no tempo de execução. [Reis, 2017]

Vantagens que proporciona:

1. Reduz a necessidade de conhecer SQL, conhecer pelo menos o básico de SQL

é fundamental para qualquer programador. Todavia você consegue trabalhar com
a JPA sem esse conhecimento.
2. Otimização automática, nem sempre temos o trabalho de otimizar uma consulta.

1.6. Conclusões Parciais

Em suma é neste capítulo onde se transmitiu a ideia introdutória do tema em questão, pois
definiu-se os conceitos fundamentais para perceção do trabalho em questão. A análise
feita das características e funcionamento dos sistemas de gestão de formação académica
no âmbito internacional e nacional permitiu comprovar que os sistemas Académicos têm
sido grande suporte para a gestão eficiente de informações e a otimização do tempo.
Portanto acima encontra-se alguns sistemas a nível internacional e nacional que servem
de suporte para algumas instituições, mas quanto aos sistemas estrangeiros ou

19
 internacionais não se enquadrará a realidade do colégio Betânia, e o outro motivo é o facto
de não cumprirem os requisitos funcionais que o colégio Betânia pretende, alguns estão
em falta e outros com excesso. Selecionou-se a metodologia ágil Open up, pois permite o
desenvolvimento do projecto em menos tempo e quantidade de integrantes é reduzida,
visto que enquadra o trabalho desenvolvido, porque desenvolveu-se em menos tempo.
Quanto a seleção das ferramentas e tecnologias foram avaliadas as vantagens das
mesmas.

CAPíTULO II- CARACTERÍSTICAS DO SISTEMA

1.1. Introdução
Neste capítulo dá-se início as actividades de análise e modelagem do sistema na qual
será apresentado os artefactos gerados nestas e que foram feitos com a ferramenta
CASE, Visual Paradigm. Inicialmente apresentar-se-á o modelo conceitual e a descrição
do negócio, a seguir descrevem os actores do sistema, os requisitos funcionais e não
funcionas do sistema e finalmente se representam os diagramas de casos de uso do
sistema bem como sua descrição.

1.2. Modelagem do Negócio

Antes de se levar acabo o desenvolvimento de um sistema informático, precisa-se
conhecer e entender o domínio do negócio na qual o sistema será implantado e isso
consegue-se pela análise e modelagem do negócio (Rodrigues, et al., 2015).

Segundo (Silva, et al., 2001) a Modelagem “é a arte e ciência de criar modelos de uma
determinada realidade”. Desta forma pode-se entender a modelagem de negócio como a
criação de modelos do negócio, resultante das análises e reflexões sobre a natureza do
negócio e a forma como ele é executado, ou seja, sobre as características do negócio e
as rotinas organizacionais

O resultado da modelagem de negócio são os modelos de negócio, esses modelos

reflectem a representação de um conjunto de actividades, processos, quem os realiza e
os serviços que a organização oferece a seus clientes.

20
1.2.1. Modelo de domínio

Modelo de domínio é um conjunto de suposições baseadas no mundo real que indicarão

as regras de negócio de um sistema. Esta etapa independentemente da escolha de
tecnologias e protótipos ajuda no entendimento dos processos. Portanto, modelo
conceitual é a descrição do sistema proposto na forma de um conjunto de ideias e
conceitos integrados. [REBELO, 2012]. Na figura a seguir será ilustrada o diagrama de
classes de domínio.

Diagrama de classe de domínio

Figura 6-Diagrama de Modelo de Domínio de Classe

Descrição do negócio

A secretaria Docente é responsável pela execução de processos de controlo e registo académico

no colégio Betânia, esta realiza os processos de forma manual e armazena os dados e
informações em folhas do MS Excel e pastas arquivos. Ao ser analisada, pôde-se perceber a
existência de vários processos, mas aqui serão destacados apenas aqueles que são de suma
importância para este projecto.

21
Processo de Matrícula

O processo de matrícula começa quando o estudante se dirige a secretaria Docente na data

marcada pelo calendário académico para as matrículas e solicita a realização da matrícula à
secretária. A secretaria solicita os documentos necessários ao estudante e verifica se está
conforme os requisitos estabelecidos. Após a verificação é fornecido a ficha de matrícula ao
estudante. Este preenche a ficha e entrega à secretária, ela verifica se a ficha está bem preenchida
e assina a ficha de matrícula e adiciona o estudante na lista de matrícula e entrega o comprovativo
de matrícula ao estudante e este se retira da secretaria docente.

Processo de Inserção de Estudante na Turma

O processo de inserção de estudante na turma ocorre após os processos de matrícula e

confirmação de matrícula. Neste processo a secretária selecciona a turma (criada em documento
MS EXCEL) que deseja inserir estudantes, na lista de matrícula (obtida nos processos de matrícula
e confirmação de matrícula) selecciona os estudantes que deseja inserir na turma. Inserir os
estudantes seleccionados na turma e posteriormente realiza a publicação da pauta da turma.

Processo de Anulação de Matrícula

Este processo começa quando o estudante dentro do prazo estipulado para anulação da matrícula,
chega a secretaria docente e solícita anulação de matrícula por meio de um requerimento dirigido
ao Direito académico, onde o estudante expressa sua pretensão, a secretaria faz a recessão e
remete a direcção docente que avalia os motivos da pretensão. A direcção defere o requerimento
e a secretaria efetua anulação de matrícula do estudante.

Processo de Confirmação de Matrícula

Este processo começa quando o estudante transita de classe e dentro do prazo estipulado para a
confirmação da matrícula, chega a secretaria docente e solícita a confirmação. A secretaria verifica
se o aluno se encontra no estado apto e se for solicita os documentos necessários ao estudante
e verifica se está conforme os requisitos estabelecidos. Após a verificação é fornecido a ficha de
confirmação ao estudante. Este preenche a ficha e entrega à secretária, ela verifica se a ficha está
bem preenchida e assina a ficha de confirmação e adiciona o estudante na lista de confirmação e
entrega o comprovativo de confirmação ao estudante e este se retira da secretaria docente.

22
Processo de Pagamento de Propinas

Este processo começa quando o estudante vai fazer o pagamento na secretaria., chega a
secretaria e solícita o pagamento da mensalidade. A secretaria pede o cartão do
estudante e verifica os meses a serem pagos, o estudante informa os meses a serem
pagos, a secretaria Preenche o caderno de anotações com o nome, horário, mês ou
meses e o curso, Carimba o cartão do aluno e solicita o berderon, o aluno realiza o
pagamento do mês e a secretaria entrega o cartão ao estudante, apos isto o estudante
retira-se da secretaria.

1.3. Modelagem do Sistema

Modelagem de sistema é o processo de desenvolvimento de modelos abstratos de um

sistema, em que cada modelo apresenta uma visão ou perspectiva, diferente do sistema.
Os modelos são usados durante o processo de engenharia de requisitos para ajudar a
extrair os requisitos do sistema durante o processo de projeto, são usados para descrever
o sistema para os engenheiros que o implementam; e após isso, são usados para
documentar a estrutura e a operação do sistema. Pode-se desenvolver modelos do
sistema existente e do sistema a ser desenvolvido (BOOCH et. Al., 2005).

1.3.1. Especificação de Requerimentos do Sistema

Requerimento também chamado de requisitos do sistema entende-se pelas propriedades

que os sistemas em construção devem manifestar quando estiverem prontos. Os
requisitos de sistema expressam as necessidades dos usuários e as restrições que são
apresentadas a um sistema que devem ser consideradas durante o desenvolvimento
(Fernandes, et al., 2017).
A colecta de informações necessárias para a construção do sistema foi realizada através
de entrevistas e documentos disponibilizados pelos funcionários da secretaria docente do
colégio Betânia. A seguir é apresentado os requisitos funcionais especificados para o
sistema.

23
Requisitos Funcionais

Tabela 1-Requisitos Funcionais

RF1. Habilitar usuário

RF2. Adicionar usuário
RF3. Alterar usuário
RF4. Eliminar usuário
RF5. Visualizar usuários
RF6. Matricular estudante
RF7. Alterar estudante
RF8. Eliminar estudante
RF9. Visualizar estudante
RF10. Adicionar professor
RF11. Alterar professor
RF12. Eliminar professor
RF13. Visualizar professor
RF14. Adicionar Curso
RF15. Alterar Curso
RF16. Visualizar Cursos
RF17. Adicionar Turma
RF18. Alterar Turma
RF19. Visualizar Turmas
RF20. Registrar pagamentos
RF21. Editar pagamentos
RF22. Visualizar pagamentos
RF23. Imprimir relatórios.
RF24. Adicionar Disciplina
RF25. Alterar Disciplina
RF26. Visualizar Disciplina
RF27. Adicionar Preço
RF28. Alterar Preço
RF29. Visualizar Preço
RF30. Adicionar professor-turma
RF31. Alterar professor-turma
RF32. Eliminar professor-turma
RF33. Visualizar professor-turma
RF34. Adicionar Ano Lectivo
RF35. Alterar Ano Lectivo
RF36. Visualizar Ano Lectivo

24
Requisitos Não Funcionais

Tabela 2-RNF Usabilidade

Usabilidade

RNF1. O sistema deve permitir aos usuários com pouco conhecimento de informática poder interagir
com o sistema.
RNF2. O sistema deve possuir uma interface intuitiva e fácil de usar.

Tabela 3-RNF Disponibilidade

Disponibilidade

RNF3. O sistema deve estar disponível as 8 horas do dia e os 5 dias da semana.

Tabela 4-RNF Confidencialidade

Confiabilidade

RNF4. O sistema deve validar a colecta de dados para evitar entradas inapropriadas,
concretamente fazer validações dos campos.

Tabela 5-RNF Segurança

Segurança

RNF5. Integridade e confidencialidade das informações são asseguradas através de mecanismos

de controlo de acesso uso não autorizado.
RNF6. O sistema deve garantir que a exclusão de informações pode ser uma opção de aviso antes
de executar a acção.
Tabela 6-Aparência ou interface externa

Aparência ou interface externa.

RNF7. A boa organização das informações é garantida para permitir a interpretação correcta.

Tabela 7-RNF Apoio

Apoio.

RNF8. O sistema deve ser instalado e testado em que o cliente precisa.

25
 Tabela 8-RNF Hardware

R Hardware.

RNF9. Os requisitos mínimos para o computador que vai funcionar com o software devem ter as
seguintes características Pentium 4 com 1 GB de RAM, 80 GB de disco rígido.

1.3.2. Diagrama de Caso de Uso do Sistema

Tabela 9-Actores do Sistema

Actor do sistema Descrição
Secretario É a entidade responsável de realizar matrícula e pagamento.
Dr. Pedagógico É a entidade responsável pela administração do sistema e pela
realização de todas operações do sistema.

Figura 7-Diagrama de Caso de Uso do Sistema

1.3.3. Descrição de Caso de Uso do Sistema

Tabela 10-DCUS. Autenticar. Usuário

Caso de Uso Autenticar. Usuário

Actores Secretário, Dr. Pedagógico.

Resumo O caso de uso permite ao Dr. Pedagógico e o secretário introduzirem suas

credenciais, nome de usuário e a senha para que o sistema as verifique. Uma vez

26
 verificada podem aceder o sistema para executar as funcionalidades segundo sua
actividade.

Precondições Deve ser um usuário que se encontre registrado no sistema.

Pós-condições O sistema concede permissão correspondente a cada usuário.

Referências RF1

Prioridade Alta

Fluxo normal de eventos

Acção do Actor Resposta do sistema

1. Usuário clica no ícone do programa. 2. O sistema mostra a interface para a

autenticação.

3. O usuário introduz o seu nome de usuário e 4. Valida que os dados introduzidos pelo
a senha para acessar o sistema. usuário são correctos.

5. Se são correctos. Permite o acesso ao

sistema.

Fluxo alterno de eventos

Nome do fluxo alterno (dados incorrectos)

Acção do actor Resposta do sistema

5.1. Se não estão correctos, mostra uma

mensagem de erro:’’ Verifique os dados
introduzidos’’.

Tabela 11-DCUS. Gerir Usuário

Caso de Uso: Gerir Usuários.

Actores:
Dr. Pedagógico.
Propósito: Possibilitar o Dr. Pedagógico registrar usuários ao sistema.

Resumo: O caso de uso permite ao Dr. Pedagógico gerenciar os dados dos usuários no
sistema.

Precondição: Deve ser um usuário que não se encontre registrado no sistema.

Poscondição: O Dr. Pedagógico deve insertar pelo menos um usuário.

Referencia: RF2

27
Prioridade: Alta

Secção “Adicionar Usuário”

Fluxo normal de eventos

Acção Actor Resposta do Sistema

1. O Dr. Pedagógico acede a interface gerir usuário. 2. O sistema mostra a interface.

3. Aparece tela com informações da secção

“usuários”.
1. O Dr. Pedagógico clica em usuários. 2. Aparece um formulário com os seguintes
campos: nome do funcionário, nome
completo do usuário, nome de usuário, o
perfil, senha e confirmar senha. Também
aparece no mesmo formulário os botões
salvar e eliminar.

1. O Dr. Pedagógico preenche e selecione os

campos.

2. O Dr. Pedagógico clica em salvar. 3. Se todos os campos estão de preenchidos.

4. Aparecerá uma mensagem:” usuário salvo com

sucesso”

Fluxo Alternativo “Adicionar Usuário”

3.1. Se tiver campo vazio o sistema. Envia uma

mensagem: “preencha ou selecione o
campo”

Secção “Salvar Perfil”

1. O Dr. Pedagógico clica no botão perfil. 2. Aparece dois campos: novo perfil e
descrição do perfil.

3. Preenche os campos 4. Se todos os campos estão de preenchidos.

5. Aparecerá uma mensagem:” perfil salvo com

sucesso”

Fluxo Alternativo “Salvar Perfil”

4.1. Se tiver campo vazio o sistema. Envia uma

mensagem: “preencha o campo”

Secção “Ver Usuários”

28
 1. O Dr. Pedagógico clica no botão ver. 2. Aparece uma tabela com os dados do
usuário. E também o botão alterar.

Secção “Alterar usuário”

1. O Dr. Pedagógico seleciona o registro na

tabela.

2. O Dr. Pedagógico clica no botão alterar. 3. O formulário de cadastro de usuários aparece

com os campos preenchidos.

4. Altera os campos.

5. O Dr. Pedagógico clica no botão salvar. 6. Aparece a mensagem:” Dados do usuário

alterado com sucesso”

Secção “Fluxo Alternativo”

1.1. Se não selecionou o registro.

1.2. Clicar no botão alterar. 1.3. Aparece a mensagem:” selecione o

registro a ser alterado”

Tabela 12-DCUS. Gerir Matrícula

Caso de Uso Gerir Matrícula

Actores Secretario, Dr. Pedagógico.

Resumo O caso de uso permite ao secretário ou Dr. Pedagógico matricular os estudantes,

num curso.

Precondições Caso o estudante não esteja registrado no sistema, deve ser registrado. Caso
contrário deve se fazer atualização, do curso, classe, período e turma.

Pós-condições Deve constar o estudante cadastrado ou actualizado no sistema.

Referências RF6

Prioridade Alta

Secção “Matricular Estudante”

Fluxo normal de eventos

Acção do actor Resposta do sistema

1. Tem acesso o sistema para efectuar 2. O sistema mostra a interface para efectuar a
matrícula. matrícula.

3. Introduz os dados pessoais (nome do 4. Valida que os dados introduzidos pelo usuário
formando, do pai, da mãe, estado civil, género, são correctos.
número do BI ou cédula, morada, telefone e

29
email), a turma (curso, sala, horário e fase) e o
ano académico.

5. Se introduziu-se dados correctos, mostra a

mensagem: ‘’O formando matriculado com
sucesso’’

Fluxo alterno de eventos (matricular estudante)

Nome do fluxo alterno (dados incorrectos)

Acção do Actor Resposta do sistema

5.1. Se não foram preenchidos alguns campos

5.2. Mostra a seguinte mensagem: ‘Preencha

o campo com o nome do campo’’.

5.3. Se o formando já foi matriculado num

curso, mostra a mensagem: ‘’O Formando
já foi matriculado no sistema’’.

30
 Secção “Listar Estudante”

1. Clica no botão Listas 2. Mostra uma tabela com os dados do

formando, abaixo o botão alterar, nova
matrícula e imprimir ficha de inscrição.

Secção “Alterar Estudante”

1. Selecione o dado a ser alterado.

2. Clica no botão alterar. 3. Carrega os campos do formulário da

matrícula.

4. Altera os dados 5. Clica no botão Salvar.

6. Mostra a mensagem: ‘’O Formando

Atualizado com sucesso!’’.

Nome do fluxo alterno (alterar estudante)

Acção do actor Resposta do sistema

1.1. Se não foi selecionado o registro.

1.2. Clica no botão alterar. 1.3. Mostra a mensagem: ‘’Seleccione o

registro’’.

Secção “Eliminar Estudante”

1. Seleciona na tabela o formando a ser

eliminado.

2. Clica sobre botão alterar. 3. Carrega os campos do formulário da

matrícula.

4. Clica no botão eliminar. 5. Aparecerá a seguinte mensagem:

“Estudante eliminado com sucesso”.

Fluxo alterno de eventos (eliminar estudante)

Acção do Actor Resposta do sistema

1.1. Se não foi selecionado o registro.

1.2. Clica sobre botão alterar abaixo da 1.3. Mostra a mensagem: ‘’Seleccione o registro’’.
tabela.

Tabela 13-DCUS. Gerir Pagamento

Caso de Uso Gerir Pagamentos

Actores Secretario.

Resumo O caso de uso permite ao secretário registrar os pagamentos feitos pelos estudantes.

31
Precondições O estudante deve constar no sistema.

Pós-condições O registro de pagamento deve aparecer no sistema.

Referências RF20

Prioridade Alta

Fluxo normal de eventos “Pagamento de Mensalidade”

Acção do Actor Resposta do sistema

1. Clica no menu em pagamento. 2. O sistema mostra a interface inicial do

pagamento. Com botão mensalidade.

3. Caso o usuário clique no botão 4. Aparecerá um formulário com os campos

mensalidade. (número de processo, ano académico,
classe, valor, meses, forma de pagamento).

5. O secretário introduz o número de processo,

e selecione o ano académico e a classe.

6. Clica em ok. 7. Mostra todos os meses a serem pagos.

8. Selecciona os meses a serem pagos e

preenche os campos do formulário.

9. Clica em salvar. 10. Se os dados estão correctos: Aparecerá a

seguinte mensagem: ‘’Pagamento da
mensalidade efetuado com sucesso!’’

11. Secretário clica no botão ver. 12. Aparece uma tabela vazia.

13. Seleciona o curso, a classe e o ano 14. Carrega todos os estudantes que pagaram
académico. e os que não pagaram.
Fluxo alterno de eventos “Pagamento de Mensalidade”
Acção do Actor Resposta do sistema
7.2. Aparecerá a seguinte mensagem:
7.1. Se não selecionou os meses.
“selecione os meses a serem pagos”

1.4. Conclusões Parciais

Com todos estes diagramas e tabelas feitos permitiu ou simplificou a compreensão de

quem procura entender o que o sistema neste caso faz, foi identificado os actores do
sistema, também foi registado modelo de negócio, a interacção entre os mesmos os
actores e caso de uso. Para o leitor ficou mais fácil ou já consegue ter a ideia de negócio
proveniente do colégio Betânia e como funciona o sistema na qual se implementa. Neste
capítulo relaciona a forma como o negócio está relacionado ao sistema, pois descreveu-

32
 se as actividades elaboradas na mesma, permitiu então ter uma ideia daquilo que o
sistema faz.

CAPíTULO III- DESENHO, IMPLEMENTAÇÃO E PROVAS

3.1. Introdução

Neste capítulo se documentam os aspectos fundamentais de desenhos, implementação e

provas do sistema. E tem como objectivo descrever os diagramas de classes e base de
dados do sistema e os testes realizados na aplicação desenvolvida, tendo utilizado a
técnica estrutural (caixa branca) que avalia o comportamento interno do software e técnica
funcional (caixa negra) onde não se considera o comportamento interno do mesmo.

3.2. Arquitectura do Sistema e Padrão de Desenho Utilizado

Um padrão de arquitectura de software é um esquema genérico testado para resolver um

problema em particular, que é recorrente dentro de um determinado contexto. Este
esquema é especificado descrevendo os componentes, com suas responsabilidades e
relacionamentos (Rivera, et al., 2010).

3.2.1. Arquitectura do Sistema

Arquitectura do Sistema é a descrição de como os componentes que compõem o sistema

estarão organizados e de como eles se relacionam (Sommerville, 2011). Para o
desenvolvimento do Sistema decidiu-se a utilização o padrão de arquitectura MVC
(Modelo Vista Controladora).
Modelo Vista Controladora (MVC)
O Padrão oferece grandes vantagens, como organização, reutilização e flexibilidade de
código. A programação é organizada à medida que separa os dados da aplicação, a
interface do usuário e a lógica dos dados em três componentes diferentes, nos quais cada
camada é especializada em uma função específica.
Modelo: representação específica da informação com a qual o sistema opera. A lógica de
dados garante a integridade desses dados e permite que novos dados sejam derivados.
Vista: mostra o modelo em um formato adequado para interagir. Lida com a apresentação
visual dos dados representados pelo modelo.

33
Controlador: responde a eventos e invoca alterações no modelo e provavelmente na
exibição.
Vantagem do MVC

• Suporte para múltiplas visualizações, pois não há dependência direta entre a visão
e o modelo.
• Maior suporte a mudanças, pois os requisitos de interface tendem a mudar mais
rapidamente que as regras de negócios. Como o modelo não depende das
visualizações, a adição de novos tipos de visualizações ao sistema geralmente não
afeta o modelo (Salazar, 2012).
Na presente solução por exemplo: a camada de apresentação CursoVista faz requisições
por dados ou acções sobre os dados do modelo CursoModelo. O control CursoControl
recebe as requisições e repassa para o objecto apropriado da camada de modelo
CursoModelo para atendê-la. O modelo faz as operações sobre os dados e retorna algum
tipo de informação ao control CursoControl, que por sua vez devolve informações para
exibição na camada de apresentação CursoVista. Vista faz acesso indireto à modelo
CursoModelo para apresentação das informações.
Na figura a seguir será ilustrada a arquitectura mvc da classe curso.

Figura 8-Arquitectura mvc da classe curso

3.2.2. Padrão de Desenho

Padrão de desenho é uma solução geral para um problema que ocorre com frequência
dentro de um determinado contexto no projecto de software. Uma solução bem provada
para um problema comum que captura a experiência e as boas práticas de forma que
possa ser reutilizada. É uma representação abstracta que pode ser instanciada de várias
maneiras (Sommerville, 2011). Entre os padrões que se utilizaram neste contexto

34
encontram-se os Padrões gerais de software para a atribuição de responsabilidades
(GRASP do inglês General Responsibility Asignment Software Patterns) e os Padrões
GoF (do inglês Gang Of Four).

GRASP

Os Padrões GRASP são formados por princípios fundamentais que servem de base para
a atribuição de responsabilidades a classes e objectos em um projecto orientado a
objectos (DEVMEDIA, 2018). Os utilizados no desenho do sistema são os seguintes:
Controlador (Controller): quando aplicado atribui a responsabilidade por lidar com
eventos do sistema a uma classe que não esteja relacionada a interface com o usuário
(Silva, 2016). Aplicação deste padrão fica evidente nas classes TurmaControl,
ProfessorControll, só para citar alguns. Onde esta recebe e trata eventos da camada de
interface com o usuário, delegando as acções para as camadas inferiores, de modo que
funcione como intermediário.
Criador (Creator): este princípio determina qual classe deve ser responsável pela criação
certos objectos (Silva, 2016). Uso desse padrão pode ser observado entre a classe Aluno
e Matricula onde a classe Matrícula possui informação necessária para inicialização ou
criação de objecto Aluno.
Especialista (Information Expert): quando aplicado este princípio determina quando se
deve delegar a responsabilidade para um outro objecto que seja especialista naquele
domínio (Silva, 2016). Este padrão se evidencia na classe MatriculaControl, como
especialista no domínio de informação de quantos estudantes estão matriculados.
Alta Coesão: caracteriza as classes com responsabilidades estremamente relacionadas
que não realizam um trabalho enorme. Significa que as classes do sistema têm
assignadas somente as responsabilidades que lhes corresponde e mantem uma estreita
relação com o resto das classes. Na presente solução se utiliza o padrão mencionado na
classe Login e LoginControl pois as mesmas mostram responsabilidades relacionadas
coerentemente, que se complementam entre si.
Baixo Acoplamento: determina o nível de dependência de uma classe com respeito a
outras. Na presente solução se utiliza o padrão mencionado se põe de exemplo a
existência de uma baixa interdependência entre a classe controlador, o modelo ou a
vista.Esta característica evidencia a possibilidade de serem efectuada mudanças em
estas classes sem que as outras sofram grandes alterações.

35
Padrão de Desenho GOF

Outro conjunto de padrões de projeto bem conhecidos são conhecidos padrões de como
um grupo de quatro GOF (Gang of Four) são uma série de padrões que se expandem a
linguagem, aprender novos estilos de design e introduzir a notação UML. Esses padrões
de GoF são agrupados em três categorias: criação, estrutura e comportamento (Scielo,
2013).
Dos diferentes padrões oferecidos pelo GOF, os seguintes foram levados em conta:

Padrões de Criação
Tem como intenção principal abstrair o processo de criação de objectos, ou seja, a sua
instanciação. Desta maneira o sistema não precisa se preocupar com questões sobre,
como o objecto é criado, como é composto, qual a sua representação real

Objecto unitário (Singleton): esse padrão garante que apenas uma instância da classe
seja criada e forneça um ponto de acesso global a ela. Ele é projectado para restringir a
criação de objectos pertencentes a uma classe ou o valor de um tipo a um único objecto.
Esse padrão é evidenciado na classe HibernateUtil que estabelece comunicação com a
base de dados formando um canal de comunicação aberto, garantindo que outras classes
fazem uso uma única conexão valida. Toda vez que uma chamada for feita para essa
classe, essa instância única que foi criada anteriormente será usada.
A figura a seguir mostra um exemplo de um fragmento de código do método
getConnection() da classe HibernateUtil usando esse padrão:

_
o

Figura 9-Fragmento do código getConnection

Padrões de Estrutura
Se preocupam em como as classes e objectos são compostos, ou seja, como é a sua
estrutura. O objectivo destes padrões e facilitar o design do sistema identificando maneiras

36
de realizar o relacionamento entre as entidades, deixando o desenvolvedor livre desta
preocupação.

Fachada (Facade): é um padrão que define um único ponto de conexão de um

subsistema, esse objecto de fachada apresenta uma única interface unificada e é
responsável por colaborar com os usuário (Mühlrad, 2008). Um exemplo desse padrão é
evidenciado na interface do módulo VistaAluno, VistaProfessor e VistaPagamento, que,
apesar de ser dividido em várias subclasses, cada uma com suas respectivas
responsabilidades, todas são agrupadas e usadas na mesma interface.
A figura a seguir mostra o exemplo da interface VistaAluno usando esse padrão:

Figura 10-Subsistema da interface VistaAluno

3.2.3. Padrão de Codificação

Para começar com a implementação do software, os programadores devem estabelecer
um padrão de codificação para que o trabalho relacionado à geração de código seja feito
de maneira coordenada. Um código fonte completo deve refletir um estilo armonioso,
como se um único programador teria escrito todo o código de uma só vez (Microsoft,
2016).
O Padrão de codificação usado para a implementação do sistema de gestão de matrícula
e pagamentos do colégio Betânia é baseado em Padrão CamelCase e em Code
Conventions for the Java Programming Language ou a tradução livre para português
"Convenções de Código para a Linguagem de Programação Java":

37
O CamelCase é um padrão muito utilizado em várias linguagens de programação, como
o Java, PHP e Ruby. Apesar de ser um padrão muito adotado na programação, é normal
encontrarmos algumas diferenças de uma linguagem para a outra.
UpperCamelCase: As palavras que formam o nome são escritas juntas e a primeira letra
de cada uma delas é colocada em maiúscula.
LowerCamelCase: É a prática de escrever frases ou palavras compostas eliminando
espaços e capitalizando a primeira letra de cada palavra, exceto a primeira letra que é
minúscula. É usado para nomear funções, variáveis e constantes.
A figura a seguir mostra um exemplo de um fragmento de codigo de um método Listar
Turma de consulta usando esse padrão:

Figura 11-Fragmento do Código getListTurma

Classes: Os nomes das classes, assim como seus atributos ou métodos, devem estar no
UpperCamelCase, como explicado acima.
Funções: Os nomes das funções ou métodos devem usar LowerCamelCase e, além
disso, os métodos devem existir como um modificador de acesso para cada atributo da
classe, embora para atributos públicos não seja necessário.
Variáveis: Variáveis devem usar LowerCamelCase e também ter nomes coerentes e
identificá-los, ou seja, eles não devem receber nomes como "a" ou "b", somente se a
variável for muito genérico para não ter um nome específico, como o índice de um loop
(um loop for ou while) será declarado com o nome "i", "j", "k" e assim por diante no caso
de vários loops aninhados .

38
3.3. Diagrama de Classe

Diagramas que são usados para descrever a estrutura estática de um sistema, modelando
em particular as entidades existentes, as suas estruturas internas (atributos e operações),
e as relações entre si (Videira, 2001). De seguida é apresentado diagrama de classe
modelado para o sistema de gestão de matrícula e pagamento do colégio Betânia:

Figura 12-Diagrama de classe

39
3.4. Análise e Desenho do Banco de Dados

O desenho de bases de dados e a criação de modelos de dados é uma parte importante

do ciclo de vida do desenvolvimento de aplicações. No entanto, nem sempre lhe é dada a
devida importância. Um modelo de dados fidedigno e actualizado pode servir como uma
ferramenta importante de referência para analistas de bases de dados, programadores e
outros membros das equipas de desenvolvimento.

3.4.1. Modelo Físico do Banco de Dados

Modelo físico de banco de dados é uma descrição de um banco de dados no nível de

abstracção visto pelo usuário do Sistema de Gestão do Banco de Dados (SGBD). Neste
modelo são detalhados os componentes da estrutura física do banco de dados, como
tabelas, campos, tipos de valores, tamanho, índices, etc. Assim, esse modelo depende do
SGBD que está sendo usado. É Modelo está pronto para criar o banco de dados
propriamente dito, usando o SGBD seleccionados. Com isso a seguir tem-se o modelo
físico de banco de dados para o sistema de gestão de Matrícula e Pagamento do colégio
Betânia.

Figura 13-Módulo Matrícula

40
 Figura 14-Módulo Pedagógico

Figura 15-Módulo Pagamento

3.4.2. Descrição das Entidades

Tabela 14-Descrição das Entidades da Base de Dados

Entidade Descrição

ano_lectivo Esta tabela armazena as informações do ano lectivo.

curso Aqui nesta tabela é armazenada informações dos cursos
existentes.
disciplina Esta tabela armazena as disciplinas do curso.
curso _disciplina Esta tabela armazena os dados da combinação da disciplinas e
curso.
aluno Armazena os dados associados aos alunos.

41
 Instituição Esta tabela armazena os dados relacionados a instituição.
matrícula Esta tabela armazena as matrículas dos alunos.
município Esta tabela armazena os municípios onde residem os alunos.
professor Esta tabela armazena os dados dos professores.
professor_turma Esta tabela armazena os dados do professor associados á turmas.
província Esta tabela armazena os dados das províncias.
role Esta tabela armazena os perfis que podem ser atribuídos aos
usuários do sistema.
sala Esta tabela armazena os dados concernentes os salas de aulas
existentes na instituição.
turma Esta tabela armazena os dados das turmas de aulas.
usuário Esta tabela armazena os dados dos usuários que acedem o
sistema.
usuario_role Esta tabela armazena os dados da combinação de usuários e roles
dos usuários.
pagamento Esta tabela armazena os dados dos pagamentos dos alunos
referente á um tipo de serviço
servico Esta tabela armazena os dados do serviço quanto aos tipos de
pagamentos.
preco_config Esta tabela armazena os dados referente a configuração dos
preços dos serviços realizados ao pagamento
mes Esta tabela armazena os dados dos meses
Pagamento_mes Esta tabela armazena os dados da combinação de pagamento e
mês.

3.5. Modelo de despliegue (implantação)

Como parte da metodologia OpenUp, uma vez que os requisitos foram concluídos, a
implementação da aplicação é realizada, assim o Modelo de Implementação é preparado.
Este modelo é composto pelos diagramas dos componentes, descrevendo como os
elementos do modelo de design são implementados em termos de componentes, arquivos
de código-fonte e executáveis. O modelo de implementação também descreve como os
componentes são organizados de acordo com os mecanismos de estruturação e
modularização, disponíveis no ambiente de implementação e na linguagem de
programação utilizada e como os componentes dependem uns dos outros (Presman,
2001).

42
3.5.1. Diagrama de Implantação

Os diagramas de instalação ou também de implantação mostram a disposição e descrevem a

configuração de elementos de suporte de processamento, e de componentes de software,
processos e objectos existentes nesses elementos (Videira, 2001).

Figura 16-Diagrama de implantação

3.5.2. Descrição do modelo de implantação do sistema

Tabela 15-Descrição do Modelo de Implantação

Nós/Dispositivos Descrição

Impressora HP office jet pro 8720

Computador Dr. Pedagógico Processador: intel(R) core(TM) i5-4590

Cpu 3.30 GHZ RAM: 8.00 GB
Gabinete: Pro Desk (HP)

Switch Modelo: D_Link

Quantidade porta: 8

Computador Secretaria Processador: intel core (TM) 2 duo cpu E4400

2.00GHZ
RAM: 1.00 GB
Gabinete: Compaq (HP)

43
 Conectores Descrição

Cabo UTP Cabo de cobre, par trançado não blindado com o

conector RJ-45

Cabo USB (barramento serial universal)

3.6. Principais Interfaces do Sistema

A seguir são apresentadas algumas interfaces do SGMCB que permite que os usuários realizem
de maneira simples e amigável suas actividades.

Figura 17-Tela do Login

44
Figura 18-Tela Gerir Estudante

Figura 19-Tela Gerir Professor

45
 Figura 20-Tela Gerir Turma

3.7. Provas de Software

Seguindo a metodologia OpenUp, uma série de testes foi realizada no produto, uma vez
que a implementação foi concluída. Uma vez que é necessário verificar a operação, a
qualidade da mesma e garantir que ela atenda aos requisitos estabelecidos pelos clientes
e todos os possíveis erros sejam detectados e corrigidos (Pressman, 2012).

3.7.1. Estratégia de teste

Para iniciar os testes de um software, a primeira coisa é definir uma estratégia de teste
onde os níveis de teste a serem tratados são capturados, assim como os tipos de teste, o
método de teste e a técnica aplicada neste método.
Uma estratégia de teste de software integra métodos de projecto de caso de teste de
software em uma série bem planejada de etapas que levará à sua construção. Deve
incorporar o planejamento de testes, o desenho de casos de teste, a execução de testes
e a coleta e avaliação dos dados resultantes. Isso tem que ser flexível o suficiente para
promover uma abordagem personalizada. Ao mesmo tempo, deve ser suficientemente
rígido para promover o planejamento razoável e o monitoramento administrativo do
progresso do projecto (Pressman, 2011).
A seguir, descrevemos os níveis de testes que serão aplicados para verificar e validar um
produto de software.

46
Nível de Unidade
O teste unitário é onde as unidades de programa ou classes de objectos individuais são
testadas. Estes devem se concentrar em verificar a funcionalidade de objectos ou métodos
(Sommerville, 2011). Com os testes no nível da unidade, as funcionalidades e os métodos
foram verificados individualmente, verificando o correcto funcionamento dos mesmos. Isso
é evidenciado em alguns métodos da classe Curso, como selectCurso (), getCurso () e
bem como no método salvarCurso () da classe controladora, que produziu resultados
satisfatórios em períodos de tempo curtos.

Nível de Integração
O teste de integração é uma técnica sistêmica para construir a arquitectura de software,
enquanto, ao mesmo tempo, testes são aplicados para descobrir erros associados à
interface. O objetivo é levar componentes para os quais um teste de unidade foi aplicado
e construir uma estrutura de programa que determine o design (Pressman, 2011). Para
aplicar este tipo de teste, uma abordagem incremental será aplicada aplicando a
estratégia incremental crescente.
Integração incremental: É a antítese da abordagem "big bang". O programa é construído
e testado em pequenos incrementos, nos quais é mais fácil isolar e corrigir erros
(Pressman, 2011).

Nível de aceitação
Este é o estágio final do processo de teste, antes que o sistema seja aceito para uso
operacional. O sistema é testado com dados fornecidos pelo cliente do sistema, em vez
de dados de teste simulados. Os testes de aceitação revelam erros e omissões na
definição dos requisitos do sistema, uma vez que os dados reais exercitam o sistema de
diferentes maneiras a partir dos dados de teste. Os testes de aceitação revelam problemas
de requisitos, em que as instalações do sistema não atendem às necessidades do usuário
ou quando o desempenho do sistema é inaceitável (Sommerville, 2011).

3.7.2. Tipos de testes

Os testes são projectados para encontrar o maior número de erros. Cada tipo de teste
tem um objectivo específico e uma técnica que o suporta (Cabrera, et al., 2008). Existem

47
diferentes tipos de testes que podem ser aplicados para verificar se o SGMCB atende a
todos os requisitos identificados e se o seu funcionamento correto é atingido. Aqui estão
os tipos de testes usados:

Teste de aceitação do tipo alfa: esses testes são executados pelo cliente (SGMCB) para
certificar que o sistema é válido para ele. Eles são basicamente testes funcionais no
sistema, uma vez terminados, e buscam verificar se os requisitos estabelecidos são
atendidos. Eles são feitos na presença do desenvolvedor, caso haja erros, eles serão
registrados e, posteriormente, serão resolvidos. Esse teste é executado novamente,
repetindo o processo até que o produto esteja livre de erros e o cliente obtenha o produto
solicitado por ele (Valdez et al., 2013).

Teste Funcional: São aqueles que visam demonstrar que os sistemas desenvolvidos
cumprem com as funções específicas para as quais foram criados. É comum a ser
desenvolvido por analistas de evidências suportadas por alguns usuários finais e são
baseados na implementação, revisão e feedback funcionalidade anteriormente projectado
para (Sanchez et al, 2013) software. Use o método da caixa preta.

3.8. Métodos de testes

Os métodos de teste de software têm os objectivos de projectar testes que descubram
diferentes tipos de erros com menos tempo e esforço (González, 2016). Existem dois
fundamentos: white box (caixa branca) para verificar a estrutura e black box (caixa preta)
para a funcionalidade do software. No processo de teste em questão, o método de teste
black box é usado.

3.8.1. Método de Teste Caixa Preta

Os testes de caixa preta, também chamados de testes comportamentais, concentram-se
nos requisitos funcionais do software. Esse teste permite que o engenheiro de software
obtenha conjuntos de condições de entrada que exercitam totalmente todos os requisitos
funcionais de um programa. O teste de caixa preta tenta encontrar erros das seguintes
categorias: funções incorrectas ou ausentes, erros de interface, erros nas estruturas de
dados ou acesso a bancos de dados externos, erros de desempenho e erros de
inicialização e finalização.

48
A técnica aplicada neste método é a partição equivalente que divide o campo de entrada
de um programa em classes de dados das quais você pode derivar casos de teste. A
partição equivalente é direcionada para a definição de casos de teste que descobre
classes de erros, reduzindo assim o número total de casos de teste que devem ser
desenvolvidos (Pressman, 2012).

Descrição do processo de provas de funcionamento

O sistema foi provado com método de provas de caixa preta usando técnica de partição
equivalente e com ajuda de cenários de provas que é um conjunto de entradas, condições
de execuções e resultados esperados desenvolvido para um objectivo particular. De
seguida será apresentado um cenário de prova realizado sobre o caso de uso cadastrar
professor.

Cenário de prova: cadastrar professor

O cadastro de professor apresenta quartos (6) campos (nome do professor, área de
formação, género, telefone, morada e foto) que uns devem estar preenchidos
obrigatoriamente e outros não. Uma vez cumprido este requisito espera-se como resultado
que o novo professor esteja cadastrado no sistema informático. Caso não se cumprida
este requisito o sistema informará o preenchimento daqueles campos obrigatório que se
encontram vázio.

Tabela 16-Cenário de Prova (Cadastrar Professor)

Condições de entrada Classes de equivalência Classes de equivalência não

válida válidas

O campo nome do professor Nome do Professor = “José

não pode estar vazio, e Cussoia” Nome do Professor = “”
também só aceita letras.

O campo área de formação Área de Formação: Engenharia

Área de Formação: “”
deve estar preenchido e Informática
também só com letras

Campos obrigatórios a serem Género=”M” Género=””

selecionados Morada=” Viana”
Morada=””

Campos não obrigatórios Telefone=””

Foto=””

49
Resultados da prova válida:

Resultados da prova não válida:

O cadastro de professor apresenta dois (2) campos (nome do professor, área de

formação) que devem estar preenchidos correctamente. Uma vez cumprido este requisito
espera-se como resultado que o novo professor esteja cadastrado no sistema informático.
Caso não se cumprida este requisito, o sistema informará o preenchimento correcto dos
campos.

3.8.2. Método de Teste Caixa Branca

Técnica de teste que avalia o comportamento interno do componente de software. Essa
técnica trabalha directamente sobre o código fonte do componente de software para
avaliar aspectos tais como: teste de condição, teste de fluxo de dados, testes de ciclo e
testes de caminhos lógicos (Pressman, 2005).

Figura 21-Código fonte salvar Curso

50
Gráfico de fluxo

Figura 22-Gráfico de fluxo

A complexidade ciclomática tem fundamento na teoria dos grafos e fornece uma métrica de
software extremamente útil. A complexidade é calculada da seguinte forma:

1. O número de regiões do grafo de fluxo correspondente à complexidade ciclomática.

2. A complexidade ciclomática V (G) para um grafo de fluxo G é definido: V (G) = A –

N+2, Onde A é o número de aresta e o N número de nodos.

Logo temos:

V(G) =4–4+ 2

V(G) = 2

O gráfico possui duas (2) regiões.

Descrição dos caminhos encontrados:

Caminho:1-2-3
1. Caso de Prova: Salvar Curso.
2. Entrada: Se o curso não estiver registrado no sistema.
3. Resultado: Salva o curso.

Caminho:1-4-3
1. Caso de Prova: Salvar Curso.
2. Entrada: Se o Curso já existe no sistema.
3. Resultado: Actualiza as informações do campo.

Caminho:1-2-3
1. Caso de Prova: Salvar Curso.

51
 2. Entrada: Se o sistema não estiver validado.
3. Resultado: Recebe mensagem de validação.

3.9. Resultado das Provas

Ao aplicar as provas de caixa preta, foram elaborados 78 cenários de provas. Depois de
uma primeira execução se obtiveram 30 não conformidades e foram resolvidas 27 não
conformidades. Uma vez corrigidos os erros detectados, se executaram novamente todas
as provas uma segunda vez se obtiveram 18 não conformidades e se resolveram as 18
não conformidades na sua totalidade e numa terceira vez após se ter corrigido os erros
detectados não se detectaram não conformidades. Os tipos de erros encontrados foram
erros de sintaxe, erros de semântica e erros de lógica.

Resultado das Provas

Cenários de Provas Defeitos Encontrados Defeitos Resolvidos

78 78 78

30 27
18 18

0 0

1º Iteração 2º Iteração Revisão

Figura 23-Gráfico do Resultado das Provas

3.9.1. Mecanismo de eficiência (Teste de aceitação)

Com o objectivo de comparar a eficiência do processo de gestão de matrícula, e

pagamentos antes e depois da implementação do sistema informático de gestão para o
colégio Betânia (SGMCB).

52
 Tabela 17- Mecanismo de Eficiência

Acção Tempo

Manual Sistema

Matricular Aluno 15 minutos no mínimo 2 minutos no mínimo

Pagamento de mensalidade 10 minutos no mínimo 1 minuto no mínimo

Processo geral Total

Processo de Matrícula e 25 minutos 3 minutos

Pagamento.

A tabela acima permite concluir que com a implementação do aplicativo informático houve uma
melhoria no que tange ao tempo de atendimento dos serviços prestado na instituição.

3.10. Conclusões Parciais

Durante o desenvolvimento do capítulo 3 ficou definido o modelo de implementação do

sistema mediante o diagrama de implementação que permitiu representar as principais
dependências que conformam a estrutura do sistema. Também foram descritos os
estândares de codificação usados durante o desenvolvimento da solução, mediante o
desenvolvimento de processos de provas foi possível identificar e resolver os erros na
implementação aumentando assim a qualidade do produto final. Depois das provas
confirmou-se que a solução satisfaz as funcionalidades e cumpre com os requisitos não
funcionais.

53
 CONCLUSÕES

Neste trabalho de conclusão de curso foram destacados vários aspectos que dizem
respeito as novas tecnologias bem como o desenvolvimento do sistema de gestão de
matrícula e pagamento para o colégio Betânia.
Utilizou-se para isto as metodologias e modelo de engenharia de software, aplicando
conceitos que abrangem do primeiro ao último semestre do curso. Através das técnicas
de levantamento de requisitos, absorveu-se uma boa percepção do problema e, a partir
daí, desenvolver todos os artefactos que levaram a codificação do sistema.
A solução apresentada foi validade junto aos professores, e confirmou-se, portanto, que
esta, atende o problema proposto. sendo que o SGMCB é um sistema que poderá atender
as mais básicas necessidades de gerenciamento de matrícula e pagamento.
Como um todo, o projecto adicionou grande experiência ao membro da equipe, sendo que
a razão principal para isto é que, do princípio ao fim, estava focados e envolvidos em todas
as actividades desenvolvidas. Com o levantamento dos requisitos do sistema, colocamos
em prática todos os conceitos aprendido sobre análise de sistema. Aplicaram-se as
metodologias de gerência de projecto para controle de pagamento das actividades,
desenvolvimento dos diagramas e codificação do sistema baseados nas habilidades
adquiridas durante a formação académica.
Visto que esta oportunidade de poder se colocar todo o conhecimento aprendido durante
os anos como académico, embora foram trabalhosos e exaustivos até certo ponto, devo
aqui dizer que foi desafiador e entusiasmante ate certo ponto. Não esquecendo ainda que
o foco deste projecto foi: gestão de matrícula e pagamento do colégio Betânia.

54
 RECOMENDAÇÕES
Todos os objectivos definidos na etapa inicial foram cumpridos, mas tem como
recomendações:

➢ Implementar uma versão posterior web, que possibilite o acesso externo as

informações relacionadas aos cursos e seus preços sem a necessidade de sair
de casa, isto por meio do site do colégio Betânia.
➢ Implementar um requerimento para verificar a autenticidade do recibo de pago
das mensalidades pela instituição bancaria.

55
BIBLIOGRAFIA
Afonso, Normandes Junior e Alexandre. 2017. Produtividade no Desenvolvimento de
Aplicações Web Com Spring Boot. Brasil : AlgaWorks Sftwares, 2017.
Araújo, Marco Antônio. 2015. Visual Paradigm. devmedia. [Online] 4 de 7 de 2015.
http://www.devmedia.com.br/artigo-sql-magazine-42-modelagem-de-dados-com-a-visual-
paradigm-do-modelo-de-classes-a-criacao-do-banco-de-dados/7019#ixzz3pfxBCvTr.
Bauer, Christian;King, Gavin. 2007. Java persistence with hibernate. 2007.
Bonaparte, Ubaldo Jose. 2012. Proyectos UML. Argentina : Editorial de la Universidad
Tecnológica Nacional - edUTecNe, 2012.
Burgués, Esteban Gracia. 2016. Aprende a Modelar Aplicaciones con UML: 2ª Edición.
Espanha : ITCampos Academy, 2016. 978-1523498536.
Company-PostgreSQL. 2014. PostgreSQL. 2014.
COMUNITY, ASTHA. 2011. Site Official Astha Comunity. Site Official Astha Comunity.
[Online] Astha Comunity, 2011. http://astah.change-vision.com/en/product/astah-
community.html.
Córdova, Dorta, Erick. 2011. ´´Procedimiento para la ejecución de las pruebas de unidad
a los componentes de la Capa de presentación del sistema CEDRUX´´. La Habana :
Universidad de las Ciencias Informáticas : s.n., 2011.
Costa, Pedro. 2013. Partição de equivalência em testes de software. Base2. [Online] 12
de Setembro de 2013. [Citação: 13 de Março de 2018.]
http://www.base2.com.br/2013/09/12/particao-equivalencia-teste-software/#.
Debastiani, Alberto, Carlos. 2015. Definindo Escopo em Projetos de Software. São
Paulo : s.n., 2015.
DEVMEDIA. 2018. Desenvolvimento com qualidade com GRASP. DEVMEDIA. [Online]
DEVMEDIA, 2018. [Citação: 20 de Janeiro de 2018.]
https://www.devmedia.com.br/desenvolvimento-com-qualidade-com-grasp/28704.
Dias, Rudinei Pereira. 2013. Modelagem de dados e Banco de dados. Modelagem de
dados e Banco de dados. 2013.
Editora, Porto. 2015. Dicionário Língua Portuguesa. infopedia. [Online] 10 de Setembro
de 2015. http://www.infopedia.pt/dicionarios/lingua-portuguesa/escola.
Fernandes, João M. e Machado, Ricardo J. 2017. Requisitos em projetos de software e
de sistemas de informação. São Paulo-Brasil : Novatec Editora Ltd, 2017. 978-85-7524-
566-0.

56
PostgreSQL. 2017. PostgreSQL. [Online] The PostgreSQL Global Development Group, 5
de 10 de 2017. [Citação: 5 de 11 de 2017.] www.postgrsql.org.
Howard, Y. 2012. Systems Design - Use case Modeling Lab using Visual Paradigm. 2012.
—. 2012. Use Case Modelling Lab using Visual Paradigm. 2012.
Instituto Federal do Paraná. 2014. MANUAL DE PROCEDIMENTOS DA SECRETARIA
ACADÊMICA. Paranavaí : Instituto Federal do Paraná, 2014.
http://paranavai.ifpr.edu.br/wp-content/uploads/2014/09/Manual-da-Secretaria-
Acadêmica-2014.pdf.
International Institute of Business Analysis. 2011. Um guia para o Corpo de
Conhecimento de Análise de Negócios. Canada : IIBA, 2011. 978-0-9811292-4-2.
JasperReports Community. JasperReports Community. community.jaspersoft.com.
[Online] [Citação: 10 de Dezembro de 2015.]
community.jaspersoft.com/project/jasperreports-library.
JasperReportsCommunity. JasperReportsCommunity. [Online] [Citação: 11 de
Dezembro de 2015.] community.jaspersoft.com/project/jasperreports-library.
JÚNIOR, CLAUDEMIR PÚBLIO . 2006. SISTEMA WEB DE GESTÃO ESCOLAR.
Guaratinguetá-SP : s.n., 2006.
Junior, Thiago Faria e Normandes. 2015. JPA e Hibernate. Brasil : AlgaWorks
Softwares, 2015.
La Torre, Novella. 2012. ´´Sistema de gestión de base de datos PostgreSQL´´. 2012.
Lucas, Ana, et al. 2008. Conceitos Fundamentais de Software. 2008.
Lyceum, Equipe. 2017. Blog Lyceum. Confira as principais tendências para a gestão
acadêmica. [Online] 22 de Maio de 2017. [Citação: 2018 de Janeiro de 2018.]
https://blog.lyceum.com.br/confira-as-principais-tendencias-para-a-gestao-academica/.
Marinho, Fabiana Gomes, Souza, Gabriela Telles de e Andrade, Rossana Maria de
Castro. 2003. UMA METODOLOGIA PARA APLICAÇÃO DE PADRÕES DE SOFTWARE.
2003.
Martínez, Luis Joyanes Agular e Ignacio Zahonero. 2011. Programación En Java 6.
México : McGraw-Hill/Interamericana, 2011. 978-607-15-0618-4.
Martins, Gilson Rodrigues. 2015. Diagrama de Classes. [Online] 28 de Outubro de 2015.
[Citação: 13 de Novembro de 2015.] http://www.wiki/Diagrame_de_classes.
Martins, Marcelo. 2010. Relatórios em Java – JasperReports e iReport. k19. [Online] 20
de Novembro de 2010. http://www.k19.com.br/artigos/relatorios-em-java-jasperreports-e-
irepor/.

57
—. 2010. Relatórios em Java – JasperReports e iReport. k19. [Online] 20 de Novembro
de 2010. [Citação: 13 de Setembro de 2015.] http://www.k19.com.br/artigos/relatorios-em-
java-jasperreports-e-irepor/.
Martins, Vistor Manuel Moreira. 2006. Integração de Sistema de Informação:
Perspectivas, normas e Abordagens. Lisboa : Edições Sílabo, 2006. 972-618-426-6.
Meira, Fábio Lúcio. 2010. Open UP - Processo Unificado Aberto. Open UP . [Online] 1
de Abril de 2010. [Citação: 12 de Julho de 2017.] http://www.open2up.blogspot.com.
Meira, Regilan. Banco de Dados. Banco de Dados. http://www.regilan.com.br : s.n.
Visual Paradigm. 2017. Visual Paradigm. Visual Paradigm. [Online] Visual Paradigm,
2017. [Citação: 6 de 11 de 2017.] www.visualparadigm.com.
NetBeans. 2016. NetBeans. NetBeans. [Online] Oracle Corporation, 3 de 10 de 2016.
[Citação: 15 de 07 de 2017.] www.netbeans.org.
Neto, Pedro Alcântara dos Santos. Requisitos de Software.
Orihuela, J.L. 2009. Redes Sociales y eduación. 2009.
PARAÍSO, CHRISTIANNE DE MELO SILVA. 2011. DESENVOLVIMENTO DE UM
SISTEMA DE CONTROLE ACADÊMICO. São José dos Campos : s.n., 2011.
Pina, Emanuel Vieira de. 2014. SISTEMA INTEGRADO DE GESTÃO ACADÉMICA –
SIGA. [Trabalho de Conclusão de Curso] Mindelo : s.n., 2014.
RAMOS SOFT TECNOLOGIAS. 2017. Softwares De Gestão Escolar. RAMOS SOFT.
[Online] RAMOS SOFT ANGOLA, 2017. [Citação: 2 de julho de 2017.]
http://www.ramossoft.com/ramossoft-1-softwares-de-gestao-escolar.

58
59