FACULDADE DE TECNOLOGIA DE SÃO JOSÉ DOS CAMPOS
FATEC PROFESSOR JESSEN VIDAL
CHRISTIANNE DE MELO SILVA PARAÍSO
DESENVOLVIMENTO DE UM SISTEMA DE CONTROLE
ACADÊMICO - ACADSISTEM
São José dos Campos
2011
CHRISTIANNE DE MELO SILVA PARAÍSO
DESENVOLVIMENTO DE UM SISTEMA DE CONTROLE
ACADÊMICO - ACADSISTEM
Trabalho de Graduação apresentado à
Faculdade de Tecnologia São José dos
Campos, como parte dos requisitos
necessários para a obtenção do título de
Tecnólogo em Informática com Ênfase em
Banco de Dados.
Orientador: Me. Juliana Forin Pasquini Martinez
São José dos Campos
2011
Dados Internacionais de Catalogação-na-Publicação (CIP)
Divisão de Informação e Documentação
PARAÍSO, Christianne M. S.
Desenvolvimento de um Sistema de Controle Acadêmico - ACADSISTEM.
São José dos Campos, 2011.
154f.
Trabalho de Graduação – Curso de Tecnologia em Informática com Ênfase em Banco de dados,
FATEC de São José dos Campos: Professor Jessen Vidal, 2011.
Orientador: Me. Juliana ForinPasquini Martinez.
1. Banco de Dados. I. Faculdade de Tecnologia. FATEC de São José dos Campos: Professor
Jessen Vidal. Divisão de Informação e Documentação. II. Desenvolvimento de um Sistema de
Controle Acadêmico – ACADSISTEM.
2.
REFERÊNCIA BIBLIOGRÁFICA –
PARAÍSO, Christianne M. S. Desenvolvimento de um Sistema de Controle Acadêmico ACADSISTEM. 2011. 154f. Trabalho de Graduação - FATEC de São José dos Campos:
Professor Jessen Vidal
CESSÃO DE DIREITOS –
NOME DO AUTOR: Christianne de Melo Silva Paraíso
TÍTULO DO TRABALHO: Desenvolvimento de um Sistema de Controle Acadêmico ACADSISTEM
TIPO DO TRABALHO/ANO: Trabalho de Graduação / 2011.
É concedida à FATEC de São José dos Campos: Professor Jessen Vidal permissão para
reproduzir cópias deste Trabalho e para emprestar ou vender cópias somente para propósitos
acadêmicos e científicos. O autor reserva outros direitos de publicação e nenhuma parte deste
Trabalho pode ser reproduzida sem a autorização do autor.
____________________________________
Christianne de Melo Silva Paraíso
Av. Marechal Castelo Branco nº1400 Apto 543-B
CEP 12286-580 – Caçapava – São Paulo
iii
Christianne de Melo Silva Paraíso
DESENVOLVIMENTO DE UM SISTEMA DE CONTROLE
ACADÊMICO - ACADSISTEM
Trabalho de Graduação apresentado à
Faculdade de Tecnologia São José dos
Campos, como parte dos requisitos
necessários para a obtenção do título de
Tecnólogo em Informática com Ênfase em
Banco de dados.
___________________________________________________________________
Murilo da Silva Dantas, Mestre em Computação Aplicada, Instituto Nacional de
Pesquisas Espaciais - INPE
__________________________________________________________________
Carlos Augusto Lombardi Garcia, Mestre em Engenharia Eletrônica e Computação,
Instituto Tecnológico de Aeronáutica - ITA
__________________________________________________________________
Juliana Forin Pasquini Martinez, Mestre em Ciências, Instituto Tecnológico de
Aeronáutica – ITA.
_____/_____/_____
DATA DA APROVAÇÃO
iv
Dedico este trabalho a minha família que
sempre esteve ao meu lado em todos os
momentos.
v
AGRADECIMENTOS
Agradeço primeiramente a Deus por me proporcionar a realização deste trabalho e
conclusão do mesmo com êxito, a minha família pela compreensão e atenção, aos professores
da Faculdade de Tecnologia Jessen Vidal pelo que me foi ensinado, ao apoio da Faculdade
Federal de Pelotas e a professora Juliana Forin Pasquini Martinez pela orientação deste
trabalho.
vi
RESUMO
Ter o acompanhamento acadêmico dos alunos e orientadores é algo muito importante
e relevante, além de ser um passo a frente para as Universidades. 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 objetivo de solucionar esta situação, desenvolveu-se um sistema
acadêmico denominado Sistema de Controle Acadêmico - ACADSISTEM, 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 alunos. Neste projeto
foi utilizado o conceito de Engenharia de Software, Banco de Dados, Padrões de Projetos e
Processo Unificado da Rational®.
Palavra Chave: Controle acadêmico; universidade; pós-graduação; aluno; orientador;
publicação; engenharia de software; banco de dados.
vii
ABSTRACT
Have the academic monitoring of students and supervisors is very important and
relevant, and is a step forward for universities. This becomes difficult when this process is
done manually, but not when you have an automated system to do so. For this purpose, in
order to resolve this situation, we developed a system called academic Control System
Academic - ACADSISTEM, whose main function is the management of students, advisors
and publications. The software developed, and provides management of students, advisors
and publications, it also presents the data (information) and generates tables of students
report. In this project we used the concept of Software Engineering, Database, Design
Patterns and Rational Unified Process®.
Keywords: Control academic; university; graduate; student; counselor; publishing; software
engineering, database.
.
viii
LISTA DE FIGURAS
Figura 1 – Modelo Cascata
Figura 2 - Ciclo de vida de desenvolvimento
Figura 3 – As duas dimensões do RUP
Figura 4 – As quatro fases do RUP
Figura 5 – Exemplo de diagrama de caso de uso
Figura 6 - Exemplo de diagrama de sequência
Figura 7 – Exemplo de diagrama de atividade
Figura 8 – Exemplo de diagrama de Classe
Figura 9 – Exemplo de diagrama de Estado
Figura 10 – Exemplo de diagrama de Componente
Figura 11 – Exemplo de diagrama de Utilização
Figura 12 – Exemplo do Modelo Conceitual
Figura 13 – Exemplo do Modelo Lógico
Figura 14 – Exemplo de uma Classe
Figura 15 – Representação de Herança e Polimorfismo
Figura 16 - Linguagem Orientada a Objetos, objetos trocando mensagem
Figura 17 - Visão geral da ferramenta AstahCommunity
Figura 18 - Visão geral da ferramenta BrModelo
Figura 19 - Driver para o servidor de banco de dados MySQL
Figura 20 – Diagrama de Caso de Uso do Sistema
Figura 21 – Diagrama de Classes do Sistema – MVC
Figura 22 – Diagrama – View
Figura 23 – Diagrama – Controllers
Figura 24 – Diagrama – Model
Figura 25 – Diagrama de Sequência - Autenticação
Figura 26 – Diagrama de Sequência - Cadastro de Aluno
Figura 27 – Diagrama de Atividade de Exclusão de Orientador
Figura 28 – Diagrama de Atividade de Pesquisa de Aluno
Figura 29 – Diagrama de Estado de Cadastro de Usuário
Figura 30 – Diagrama de Componente Geral
Figura 31 - Tela de Autenticação
Figura 32 – Modelo Conceitual do Sistema
Figura 33 - Modelo Lógico do Sistema
Figura 34 – Interface Sujeito
Figura 35 – Classe Modelo
Figura 36 – Classe Usuário
Figura 37 – Interface Observador
Figura 38 – Classe GerenciamentoView
Figura 39 - Interface Cadastro
Figura 40 – Classe CadastroUsuário
Figura 41 – Tela de Autenticação
Figura 42 – Tela de Principal do Administrador
Figura 43 – Tela de Principal do Usuário Comum
Figura 44 – Tela De Gerenciamento de Aluno
Figura 45 – Tela De Gerenciamento de Usuário
Figura 46 – Tela De Gerenciamento de Orientador
Figura 47 – Tela De Gerenciamento de Publicação
19
21
22
23
27
28
28
29
29
30
30
31
32
33
34
35
36
37
37
42
45
46
47
48
49
50
51
52
53
53
54
55
56
57
58
59
59
60
60
61
102
103
103
104
105
105
106
ix
Figura 48 – Tela de Pesquisa de Aluno
Figura 49 – Tela de Pesquisa de Usuário
Figura 50 – Tela de Pesquisa de Orientador
Figura 51 – Tela de Pesquisa e Upload de Publicação
Figura 52 – Tela de Solicitação de Relatório de Aluno
Figura 53 – Detalhes da Tela de Autenticação
Figura 54 – Detalhes da Tela Principal do Administrador
Figura 55 – Detalhes da Barra de Menu: Navegar
Figura 56 – Detalhes da Barra de Menu: Ajuda
Figura 57 – Detalhes da Tela Principal do Usuário Comum
Figura 58 – Detalhes da Tela de Gerenciamento de Usuário
Figura 59 – Detalhes da Tela de Gerenciamento de Aluno
Figura 60 – Detalhes da Tela de Gerenciamento de Orientador
Figura 61 – Detalhes da Tela de Gerenciamento de Publicação
Figura 62 – Detalhes da Tela de Pesquisa de Aluno
Figura 63 – Detalhes da Tela de Pesquisa de Orientador
Figura 64 – Detalhes da Tela de Pesquisa de Publicação
Figura 65 – Detalhes da Tela de Pesquisa de Usuário
Figura 66 – Detalhes da Tela de Visualização da Publicação
Figura 67 – Detalhes da Tela de Solicitação de Relatório de Aluno
Figura 68 – Detalhes da Tela de Relatório de Aluno
107
107
108
108
109
117
118
118
118
120
121
123
125
127
129
130
131
132
133
134
135
x
LISTA DE TABELAS
Tabela 1 – Requisitos Funcionais
Tabela 2 – Requisitos Não Funcionais
Tabela 3 – Autenticar
Tabela 4 – Pesquisar Usuário
Tabela 5 – Pesquisar Aluno
Tabela 6 – Pesquisar Orientador
Tabela 7 – Pesquisar Publicação
Tabela 8 – Gerenciar Aluno
Tabela 9 – Gerenciar Orientador
Tabela 10 – Gerenciar Publicação
Tabela 11 – Gerenciar Usuário
Tabela 12 – Gerar Relatório
Tabela 13 – Upload
Tabela 14 – Definição do Problema
Tabela 15 – Requisitos Funcionais
Tabela 16 – Requisitos Não Funcionais
Tabela 17 – Definições do Sistema
Tabela 18 – Requisitos de Design e Qualidade
Tabela 19 – Requisitos de Confiabilidade
Tabela 20 – Caso de Uso Autenticar
Tabela 21 – Caso de Uso Pesquisar Usuário
Tabela 22 – Caso de Uso Pesquisar Aluno
Tabela 23 – Caso de Uso Pesquisar Orientador
Tabela 24 – Caso de Uso Pesquisar Publicação
Tabela 25 – Caso de Uso Pesquisar Usuário
Tabela 26 – Caso de Uso Gerenciar Aluno
Tabela 27 – Caso de Uso Gerenciar Orientador
Tabela 28 – Caso de Uso Gerenciar Publicação
Tabela 29 – Caso de Uso Gerar Relatório de Aluno
Tabela 30 – Caso de Uso Upload de Publicação
Tabela 31 – Tabela Aluno
Tabela 32 – Tabela Orientador
Tabela 33 – Tabela Publicação
Tabela 34 – Tabela Usuário
Tabela 35 – Descrição da Tela de Autenticação
Tabela 36 – Descrição da Tela Principal do administrador
Tabela 37 – Descrição da Tela Principal do Usuário Comum
Tabela 38 – Descrição da Tela de Gerenciamento de Usuário
Tabela 39 – Descrição da Tela de Gerenciamento de Aluno
Tabela 40 – Descrição da Tela de Gerenciamento de Orientador
Tabela 41 – Descrição da Tela de Gerenciamento de Publicação
Tabela 42 – Descrição da Tela de Pesquisa de Aluno
Tabela 43 – Descrição da Tela de Pesquisa de Orientador
Tabela 44 – Descrição da Tela de Pesquisa de Publicação
Tabela 45 – Descrição da Tela de Pesquisa de Usuário
Tabela 46 – Descrição da Tela de Visualização da Publicação
Tabela 47 – Descrição da Tela de Solicitação de Relatório de Aluno
40
41
42
43
43
43
43
43
43
43
44
44
44
86
87
88
91
92
93
96
96
96
97
97
97
98
98
98
98
99
112
112
112
113
117
119
120
121
123
125
127
129
130
131
132
133
134
xi
Tabela 48 – Descrição da Tela de Relatório de Aluno
Tabela 49 – Itens de Teste
Tabela 50 - Teste de Integridade de Dados e de Banco de Dados
Tabela 51 – Teste de Interface
Tabela 52 – Teste de Função
Tabela 53 – Perfil de desempenho
Tabela 54 – Teste de Segurança e Controle de Acesso
Tabela 55 – Resultado do Teste de Integridade de Dados e de Banco de Dados
Tabela 56 – Resultado do Teste de Função
Tabela 57 – Resultado do Teste de Interface
Tabela 58 – Resultado do Teste de Desempenho
Tabela 59 – Resultado do Teste de Segurança e Controle de Acesso
135
145
147
147
148
149
149
152
152
153
153
154
xii
LISTA DE ABREVITATURAS E SIGLAS
UFPel
Universidade Federal de Pelotas
IES
Instituições de Ensino Superior.
RUP
Rational Unified Process.
IDE
Integrated Development Environment.
UML
Unified Modeling Language.
OMG
Object Management Group.
DER
Diagrama de Entidade Relacionamento.
SGBD
Sistema Gerenciador De Banco De Dados
SQL
Structured Query Language.
DDL
Data Definition Language.
DML
Data ManipulationLanguage.
DCL
Data ControlLanguage.
JAVA
Linguagem de Programação.
JVM
Java Virtual Machine.
MVC
Model View Controller.
Univag
Universidade de Várzea Grande.
C
Linguagem de Programação.
C++
Extensão da Linguagem de Programação C.
xiii
SUMÁRIO
1- INTRODUÇÃO
16
1.1- Motivação
16
1.2- Objetivos
16
1.3- Objetivo Geral
17
1.4- Objetivos Específicos
17
1.5- Metodologia
17
1.6- Conteúdo do Trabalho
18
2- LEVANTAMENTO TEÓRICO PARA DESENVOLVIMENTO DO SISTEMA DE
CONTROLE ACADÊMICO
19
2.1- Engenharia de Software
19
2.1.1- Definição
19
2.1.2- Ciclo de Vida de Desenvolvimento
19
2.1.3- Processo Unificado da Rational®
21
2.1.3.1- Arquitetura do RUP
21
2.1.3.1.1- Dimensões
21
2.1.3.1.2- Dimensão Dinâmica
22
2.1.3.1.3- Dimensão Estática
24
2.1.3.2- Melhores Práticas
25
2.1.3.2.1- Desenvolver Software Iterativamente
25
2.1.3.2.2- Gerenciamento de Requisitos
25
2.1.3.2.3- Uso de Arquitetura Baseada em Componentes
25
2.1.3.2.4- Modelagem Visual de Software
26
2.1.3.2.5- Verificar Qualidade de Software
26
2.1.3.2.6- Controle de Alterações no Software
26
2.2- A Linguagem UML
26
2.2.1- Principais Diagramas UML
27
2.2.1.1- Diagrama de Caso de Uso
27
2.2.1.2- Diagrama de Sequência
27
2.2.1.3- Diagrama de Atividade
28
2.2.1.4- Diagrama de Classe
29
2.2.1.5- Diagrama de Estado
29
2.2.1.6- Diagrama de Componente
30
2.2.1.7- Diagrama de Utilização
30
2.3- Banco de Dados
31
2.3.1- Projeto de Banco de Dados
31
2.4- A Linguagem Sql
32
2.5- Orientação a Objetos
33
2.5.1- Classes
33
2.5.2- Objetos
33
2.5.3- Polimorfismo
33
2.5.4- Herança
33
2.5.5- A Linguagem Java
34
2.6- Padrões de Projetos
35
2.6.1- Padrão Mvc
35
3- FERRAMENTAS
36
3.1- Astah Community
36
3.2- Brmodelo
36
3.3- Netbeans
37
xiv
3.4- Mysql
4- O SISTEMA PROPOSTO
4.1- Concepção
4.1.1- Levantamento de Dados e Análise de Requisitos
4.1.1.1- Necessidade do Negócio
4.1.1.2- Descrição dos Envolvidos
4.1.2- Visão Geral do Sistema Proposto
4.1.2.1- Objetivos do Sistema
4.1.2.2- Descrição do Escopo do Projeto
4.1.2.3- Impactos Gerados pelo Projeto
4.1.3- Requisitos do Sistema
4.1.3.1- Requisitos Funcionais
4.1.3.2- Requisitos Não Funcionais
4.1.4- Relatório de Caso de Uso
4.1.4.1- Descrição dos Casos de Uso
4.2- Elaboração
4.2.1- Diagrama de Classes
4.2.2- Diagrama de Sequência
4.2.3- Diagrama de Atividades
4.2.4- Diagrama de Estado
4.2.5- Diagrama de Componente
4.3- Construção
4.3.1- Protótipo de Tela
4.3.2- Projeto de Banco de Dados – Diagramas
4.3.3- Dicionário de Dados
4.3.4- Desenvolvimento do Sistema
4.3.4.1- Mvc
4.3.4.1.1- Model – Modelo
4.3.4.1.1.1- Interface Sujeito
4.3.4.1.1.2- Classe Modelo
4.3.4.1.1.3- Classe Usuário
4.3.4.1.2- View – Visão
4.3.4.1.2.1-Interface Observador
4.3.4.1.2.2-Visãogerenciamentoview
4.3.4.1.3- Controller – Controlador
4.3.4.1.3.1- Interface Cadastro – Controlador
4.3.4.1.3.2-Classe Cadastrousuario
4.4- Transição
4.4.1- Testes
4.4.1.1- Plano de Teste
4.4.1.2- Procedimento de Teste
4.4.1.3- Resultado de Teste
5- CONSIDERAÇÕES FINAIS
5.1- Contribuições E Conclusão
5.1.1- Contribuições
5.1.2- Conclusão
APÊNDICES
37
39
39
39
39
39
40
40
40
40
40
40
41
42
42
44
44
49
50
52
53
54
54
54
56
56
56
57
57
57
58
59
59
60
60
60
61
61
61
61
62
62
63
63
63
63
68
xv
LISTA DE APÊNDICE
Apêndice A – Questionário para Levantamento de Requisitos
Apêndice B – Documento de Visão
Apêndice C – Documento de Requisitos
Apêndice D – Especificação Suplementar
Apêndice E – Descrição do Caso de Uso
Apêndice F – Protótipo de Tela
Apêndice G – Dicionário de Dados
Apêndice H – Manual de Instruções do AcadSistem
Apêndice I – Plano de Teste
Apêndice J – Procedimento de Teste
Apêndice L – Resultado dos Testes
68
73
83
89
94
100
110
114
137
143
150
16
1- INTRODUÇÃO
1.1- Motivação
Atualmente Instituições de Ensino Superior - IESs tem avançado bastante. Com
isso as IESs precisam se estruturar para orientar seus alunos e professores
(TACHIZAWA, 1999).
Uma Instituição de ensino é um conjunto de pessoas se interagindo, que ao se
relacionar com alunos através do poder do ensino, consegue passar a ideia em mente e
tentar garantir que os alunos saiam dali com um pensamento feito (TACHIZAWA,
1999).
Segundo a entrevista realizada com o pesquisador e professor Adjunto I da
Universidade Federal de Pelotas - UFPel, no Rio Grande do Sul, Dr. Hueder Paulo
Moisés de Oliveira (Oliveira, 2011):
“O Programa de Pós-Graduação da Universidade Federal de Pelotas – UFPel
oferece cursos de mestrado e doutorado em Química. A Universidade tem a
grande necessidade de organizar relatórios com perfis de alunos para ter um
bom acompanhamento de desempenhos acadêmicos e controle desses alunos
de pós-graduação. Porém a Universidade não tem um aplicativo
automatizado que proporcione, à administração, emitir um relatório com o
perfil de cada aluno e orientador, onde possam ser contidos todos os dados
cadastrais e institucionais de cada um deles”.
O Dr. Oliveira ainda concluiu que:
“Sem um aplicativo automatizado para armazenar esses dados, a única
solução encontrada até hoje pela administração foi recorrer à planilha do
Microsoft Office Excel para informações relacionadas aos alunos e
orientadores, porém não há certa segurança, porque esses dados armazenados
nas planilhas podem ser perdidos em caso de perda de arquivo”.
Portanto, torna se necessário automatizar esta atividade, a fim de assegurar estes
dados, a eficiência e a agilidade às tarefas desempenhadas pela administração da UFPel.
A solução proposta nesse projeto é desenvolver um software de banco de dados
relacional para o sistema de controle acadêmico, que possibilite a universidade
acompanhar o desempenho de alunos de Pós-Graduação.
1.2- Objetivos
Nesta seção serão apresentados os objetivos deste trabalho.
17
1.3- Objetivo Geral
Este trabalho tem como objetivo desenvolver um sistema de software para o
sistema de controle acadêmico do curso de Pós-Graduação da Universidade Federal de
Pelotas, denominado SISTEMA DE CONTROLE ACADÊMICO - ACADSISTEM.
1.4- Objetivos Específicos
Os objetivos específicos deste Trabalho são:
a. Pesquisar o referencial teórico para o desenvolvimento do ACADSISTEM;
b. Recolher os requisitos funcionais e não funcionais do ACADSISTEM com o
cliente UFPel;
c. Realizar o projeto de Banco de Dados Relacional;
d. Implementar o ACADSISTEM;
e. Realizar testes no ACADSISTEM e;
f. Analisar os resultados.
1.5- Metodologia
O software será desenvolvido por meio do processo de engenharia de software
Rational Unified Process® - RUP, utilizado de forma customizada, utilizando assim,
parte do processo RUP, pois ele é um processo muito complexo.
O RUP apresenta seis das melhores práticas para um bom desenvolvimento de
como desenvolver o software iterativamente, gerar requisitos, usar arquiteturas baseadas
em componentes, modelar software visualmente, verificar a qualidade do software,
controlar as mudanças do software (IBMb, 1998).
A modelagem do software será realizada com a utilização das ferramentas
StarUml(versão 5.0.2, 2005) e BrModelo (versão 2.0, 2007) para que possam
proporcionar um padrão para a arquitetura do sistema de software. A linguagem que
será usada para a implementação será Java (versão 1.6, 2006) e a NetBeansIDE (versão
6.8, 2009) e foi selecionado um Sistema Gerenciador de Banco de Dados livre, o
MySQL (versão 5.1, 2008).
18
1.6- Conteúdo do Trabalho
O presente trabalho está estruturado em cinco Capítulos, cujo conteúdo é
sucintamente apresentado a seguir:
No Capítulo 2 é feito o Levantamento Teórico para Desenvolvimento do
Sistema de Controle Acadêmico ACADSISTEM: – Apresenta os conceitos envolvidos
no desenvolvimento de software.
O Capítulo 3 - Ferramentas envolvidas no desenvolvimento: – Apresenta quais
as ferramentas selecionadas para auxiliar no desenvolvimento do software.
No Capítulo 4 - O Sistema Proposto: – Demonstrar o processo de
desenvolvimento de software composto pelas seguintes fases: concepção, elaboração,
construção e transição.
Finalmente, o Capítulo 5 apresenta as conclusões deste trabalho a partir da
análise dos resultados obtidos e trabalhos futuros.
19
2- LEVANTAMENTO TEÓRICO PARA DESENVOLVIMENTO DO
SISTEMA DE CONTROLE ACADÊMICO
Este capítulo tem como objetivo apresentar os conceitos básicos para o
desenvolvimento do sistema de controle acadêmico - ACADSISTEM.
2.1- Engenharia de Software
Nesta seção apresenta-se a definição sobre Engenharia de Software, Ciclo de
Vida de um software e Processo Unificado da Rational.
2.1.1- Definição
Engenharia de Software é uma das grandes áreas da computação, onde envolve
criação, construção, análise, desenvolvimento e manutenção do software. Este tipo de
tratamento pode proporcionar ao desenvolvedor a produção de um software com
qualidade e resultado desejado.(SOMMERVILLE, 2007).
2.1.2- Ciclo de Vida de Desenvolvimento
Para alguns sistemas o ciclo de vida não é longo, portanto é necessário entender
que um software nunca estará totalmente acabado; ele poderá estar pronto para uso, mas
sempre sofrerá implementações e melhorias (REZENDE, 2005).
Este ciclo abrange algumas etapas: análise, projeto, implementação, testes e
manutenção. O modelo cascata, mais conhecido como modelo de ciclo de vida, tem
essas cinco fases denominada de uma forma diferente, como mostra a Figura 1
(SOMMERVILLE, 2007).
Figura 1 – Modelo Cascata
Fonte: Adaptada de Sommerville (2007)
20
Para melhor especificação do sistema, é necessário recolher todos os requisitos e
finalidades do sistema na primeira fase: Definição de Requisitos. Na segunda, é definida
a arquitetura, tanto no aspecto software, com os requisitos funcionais, quanto no aspecto
hardware, os requisitos não funcionais.
Na terceira fase, Implementação e Teste de Unidade, o software começa a ser
implementado e testado, de maneira a verificar se está atendendo a sua finalidade. Para
verificar se todos os requisitos atendem as expectativas, na fase de Integração e Teste de
Sistema, o software é testado como um todo. E por último, na fase de Operação e
Manutenção, após a entrega do software, ele é requerido a novas alterações,
relacionadas a erros não detectados nos testes (SOMMERVILLE, 2007).
O ciclo de vida de um software também está representado na Figura 2. Como já
dito, um software sempre estará em desenvolvimento, pois no decorrer de seu uso
haverá sempre a necessidade de modificações (BROOKSHEAR, 2003).
A fase de Manutenção concentra-se nas:
 Correções: Mudanças que estão associadas à correção de defeitos
(Manutenção Corretiva);
 Adaptações: são exigidas à medida que o ambiente do sistema evolui e
(Manutenção Adaptativa);
 Melhoramento Funcional produzidas por exigências variáveis do cliente
(Manutenção perfectiva).
 Prevenção:
 O software de computador se deteriora devido a modificações, e;
 Surge a manutenção preventiva, frequentemente chamada de
reengenharia de software;
 Em essência, a manutenção preventiva faz modificações nos
programas de computador, de modo que eles possam ser mais
facilmente corrigidos, adaptados e melhorados;
21
Figura 2 - Ciclo de vida de desenvolvimento
Fonte: Adaptada de Brookshear (2003)
2.1.3- Processo Unificado da Rational®
O Rational Unified Process® - RUP que traduzido para o português significa
Processo Unificado da Rational, é um processo de engenharia de software. Com o
objetivo de garantir um software de alta qualidade que, dentro de um cronograma e um
orçamento previsíveis, atendam às necessidades dos seus usuários finais, o RUP fornece
uma abordagem disciplinada para a atribuição de tarefas e responsabilidades na
organização do desenvolvimento. Utiliza a linguagem UML no desenvolvimento dos
casos de uso e a orientação a objetos (KRUCHTEN, 2003).
2.1.3.1- Arquitetura do RUP
Nesta seção será apresentada a arquitetura do RUP composta por dimensões e
fases.
2.1.3.1.1- Dimensões
O RUP apresenta duas dimensões, a dinâmica e a estática, como mostra a figura
a seguir:
22
Figura 3 – As duas dimensões do RUP
Fonte: Adaptada de Kruchten (2003)
A dimensão horizontal representa o aspecto dinâmico do processo, o ciclo de vida.
Essa dimensão faz com que o projeto do software seja elaborado com uma sequência de
iterações incrementais. A dimensão vertical representa o aspecto estático, descrito em
termos de componentes do processo: atividades, disciplinas, artefatos e papéis do
processo (KRUCHTEN, 2003).
2.1.3.1.2- Dimensão Dinâmica
A arquitetura do RUP apresenta quatro fases no aspecto dinâmico: concepção,
elaboração, construção e transição, como apresenta a figura 4. Essas fases podem conter
várias iterações (KRUCHTEN, 2003).
23
Figura 4 – As quatro fases do RUP
Fonte: Adaptada de Kruchten (2003)
A Concepção é a fase da criação do escopo do projeto; nela é realizada a
avaliação de risco, uma estimativa dos recursos necessários e o cronograma dos marcos
temporais mais importantes. Todos os atores envolvidos na iteração do sistema também
são identificados nesta fase. Nesta fase são desenvolvidos, também, os seguintes
artefatos:
 Caso de negócio inicial;
 Formulação do documento de visão geral dos requisitos do projeto;
 Relatório inicial de avaliação de risco;
 Estimativa de recursos;
 Cronograma inicial e;
 Protótipos iniciais.
A elaboração é a especificação e eliminação dos pontos de maior risco. Nesta
fase são desenvolvidos os seguintes requerimentos:
 Modelo de casos de uso
 Análise e projeto do sistema;
 Relatórios de Riscos;
 Plano de gerenciamento;
 Alocação da equipe;
 Planejamento das fases, mostrando suas iterações e conteúdos.
 Realiza-se a analise do domínio do problema e projeta uma arquitetura para
o sistema.
A construção é o início do desenvolvimento do sistema, ao final de cada ciclo,
pode surgir uma versão utilizável do processo. Nesta fase são desenvolvidos os
seguintes requerimentos:
24
 Sistema de software funcionando e documentação associada pronta para ser
liberada aos usuários;
 Casos de teste baseados em cenários, e resultados de testes;
Por ultimo a transição: implantação do software e transferência do software para o
usuário do sistema (KRUCHTEN, 2003).
2.1.3.1.3- Dimensão Estática
A dimensão estática possui quatro conceitos chaves que definem quem faz o
quê, como e quando?
 Workers (trabalhadores) – quem;
 Atividades – como;
 Artefatos – o quê;
 Fluxos de trabalho (workflows) – quando.
O RUP possui também, nove disciplinas, as quais estão detalhadas a seguir:
Modelagem do negócio - Esta disciplina visa o entendimento da estrutura e a
dinâmica da organização; o entendimento dos problemas e; a identificação das
melhorias.
Requisitos - Nesta disciplina é possível estabelecer uma concordância entre os
envolvidos no projeto sobre os requisitos do sistema, bem como os limites do sistema,
estimar o tempo e custo de desenvolvimento.
Análise e Projeto - Esta disciplina visa transformar os requisitos em projeto;
construir uma arquitetura para oi sistema e; adaptar o projeto ao ambiente.
Implementação - Visa estruturar o código, bem como implementar classes e
objetos; testar e integrar as unidades.
Testes - Nesta disciplina é testado o sistema para a identificação de erros, esses
erros são identificados e documentados; é possível validar o sistema de acordo com o
que foi especificado e validar se o sistema foi desenvolvido de acordo com o projetado.
Implantação - Esta disciplina visa a certificação da entrega do sistema ao
usuário final.
Gerência de Configuração e Mudança - Nesta disciplina é controlado os
artefatos produzidos no desenvolvimento do projeto.
25
Gerenciamento e Planejamento - Esta disciplina controla o gerenciamento de
riscos. Além de disponibilizar guias para planejar, executar, acompanhar e monitorar o
projeto.
Ambiente - Visa focar nas atividades relacionadas à adaptação do processo
organizacional (do projeto) (KRUCHTEN, 2003).
2.1.3.2- Melhores Práticas
As melhores práticas apresentadas no RUP descreve como implantar um bom
desenvolvimento de software para equipes desenvolvedoras. São elas:
2.1.3.2.1- Desenvolver Software Iterativamente
O RUP sugere que o desenvolvedor adote uma abordagem iterativa, pois nela é
necessário uma maior compreensão do problema através de melhoras sucessivas, para
gerar gradativamente uma solução eficaz a cada iteração. A abordagem iterativa no
desenvolvimento verifica os itens de maior risco em cada etapa do ciclo de vida,
reduzindo significativamente o perfil de um projeto de risco(IBMb, 1998).
Pois cada iteração termina com uma versão executável, o desenvolvedor
permanece focado em produzir resultados e a checagem de status frequentes ajudam a
garantir que o projeto permaneça dentro do cronograma. Uma abordagem iterativa
também torna mais fáceis as mudanças táticas nos requisitos, nas funcionalidades e/ou
no cronograma (IBMb, 1998).
2.1.3.2.2- Gerenciamento de Requisitos
O RUP sugere ao desenvolvedor uma excelente maneira de capturar os
requisitos funcionais. Essa prática apresenta como obter, organizar o documento de
funcionalidade e restrições; como acompanhar e documentar compromissos e decisões;
e facilmente como capturar os requisitos de negócio (IBMb, 1998).
2.1.3.2.3- Uso de Arquitetura Baseada em Componentes
O processo concentra-se no desenvolvimento inicial de uma arquitetura robusta
executável. Ele descreve como projetar uma arquitetura flexível, acomoda as mudança,
é intuitivamente compreensível e promove a reutilização de software mais eficiente. O
RUP apóia o desenvolvimento de software baseado em componentes (IBMb, 1998).
26
2.1.3.2.4- Modelagem Visual de Software
As abstrações visuais ajudam o desenvolvedor a se comunicar com os diferentes
aspectos software; a ver comoos elementos do sistema se encaixam; manter a coerência
entre um projeto e sua execução; e promover a comunicação inequívoca (IBMb, 1998).
2.1.3.2.5- Verificar Qualidade de Software
Atualmente o fraco desempenho de aplicativos e a pouca confiabilidade são
fatores comuns que impedem drasticamente a aceitação dos pedidos de software. Assim,
a qualidade deve ser focada no que diz respeito aos requisitos baseados em
confiabilidade, funcionalidade, desempenho da aplicação e desempenho do sistema.
Esta prática auxilia no planejamento do projeto, na implementação, na execução e na
avaliação dos teste(IBMb, 1998).
2.1.3.2.5- Controle de Alterações no Software
Em todo software há mudanças, em alguns casos, estas mudanças são
inevitáveis, por isso a capacidade de gerir a mudança e de ser capaz de acompanhar as
mudanças é essencial. Esta prática descreve como controlar, acompanhar e monitorar as
mudanças para permitir o desenvolvimento iterativo sucesso (IBMb, 1998).
2.2- A Linguagem UML
A Unified Modeling Language ™ - UML® é uma especificação da Object
Management Group - OMG® (OMG, 1997 - 2011). É uma linguagem gráfica de
modelagem para visualizar, especificar, construir e documentar os artefatos de sistemas
de objetos distribuídos (UML, 2011).
A UML possui treze modelos gráficos que estão divididos em duas categorias,
os diagramas de aplicações estáticas que representam a estrutura e os diagramas de
comportamentos, no entanto dentro desta última categoria, existe uma subcategoria que
compõe os diagramas de interação (SILVA, 2007).
A categoria de diagramas de Estrutura inclui diagrama de classe, diagrama de
objeto, diagrama de componentes, diagrama de estrutura composta, diagrama de pacote
e diagrama de utilização (SILVA, 2007).
Os diagramas de Comportamento são: diagrama de caso de uso, diagrama de
máquina de estados e diagrama de atividades. Em sua subcategoria Interação estão
27
inclusos os diagramas de sequência, comunicação, visão geral de interação e por ultimo,
porém não menos importante o de temporização (SILVA, 2007).
2.2.1- Principais Diagramas UML
Os diagramas UML abordados neste projeto são os de: Caso de Uso, Sequência,
Atividade, Classe, Estado e Utilização.
2.2.1.1- Diagrama de Caso de Uso
O diagrama de caso de uso está relacionado à modelagem dinâmica do sistema.
Ele é composto por elementos sintáticos denominados “atores” e relações que envolvem
esses elementos (SILVA, 2007). A figura 5 apresenta um exemplo de um diagrama de
caso de uso.
Figura 5 – Exemplo de diagrama de caso de uso
Fonte: Adaptada de Silva (2007)
2.2.1.2- Diagrama de Sequência
O diagrama de sequência também está relacionado à modelagem dinâmica do
sistema. E representa a interação entre os objetos na troca de mensagens na ordem
temporal em que elas acontecem. A leitura das mensagens que são enviadas de objetos
para outros objetos é feita de cima para baixo (SILVA, 2007). A figura 6 apresenta um
exemplo de um diagrama de sequência.
28
Figura 6 - Exemplo de diagrama de sequência
Fonte: Adaptada de Silva (2007)
2.2.1.3- Diagrama de Atividade
O diagrama de atividades é composto por atividades, vista como um conjunto de
atividades ou de ações. Este diagrama representa uma atividade correspondente ao
sistema. Conforme mostrado na figura 7.
Figura 7 – Exemplo de diagrama de atividade
Fonte: Adaptada de Silva (2007)
29
2.2.1.4- Diagrama de Classe
O diagrama de classes representa a estrutura e os relacionamentos das classes.
No entanto, as classes e os relacionamentos cedidos a elas, são os elementos sintáticos
básicos do diagrama de classes (SILVA, 2007). A figura 8 apresenta um exemplo de um
diagrama de classe.
Figura 8 – Exemplo de diagrama de Classe
Fonte: Adaptada de Silva (2007)
2.2.1.5- Diagrama de Estado
O diagrama de estado representa o estado em que um objeto se encontra no
sistema. Com isso, os elementos principais desse diagrama são os estados e as
transições. Um objeto muda de estado com o auxilio de uma transição (SILVA, 2007).
A figura 9 apresenta um exemplo de um diagrama de estado.
Figura 9 – Exemplo de diagrama de Estado
Fonte: Adaptada de Silva (2007)
30
2.2.1.6- Diagrama de Componente
Este diagrama demonstra os componentes do sistema e a relação entre esses
componentes. Assim o diagrama representa a classe organizada, especificando a qual
classe pertence cada um dos componentes. Conforme a figura 10.
Figura 10 – Exemplo de diagrama de Componente
Fonte: Adaptada de Silva (2007)
2.2.1.7- Diagrama de Utilização
O diagrama de utilização, mais conhecido como diagrama de implantação
representa os elementos do sistema necessários para a execução. Representando assim, a
modelagem estrutural do sistema, através de nodos ou instâncias de nodos. Conforme a
figura 11.
Figura 11 – Exemplo de diagrama de Utilização
Fonte: Adaptada de Silva (2007)
31
2.3- Banco de Dados
Banco de dados é um conjunto de dados persistentes, com o intuito de armazenar
informações de uma determinada organização. Esses dados são mantidos por um
software chamado de Sistema Gerenciador de Banco de Dados (SGBD), onde os
usuários desse sistema podem realizar busca, exclusão, inserção e alteração nesses
arquivos de banco de dados (DATE, 2003).
Alguns autores definem que dados e informações tem o mesmo significado, por
outro lado, outros definem dados como os valores fisicamente armazenados no banco de
dados e informações como o significado gerado a partir de um determinado dado
(DATE, 2003).
2.3.1- Projeto de Banco de Dados
Na maioria dos projetos de banco de dados são utilizados dois modelos de banco
de dados em duas fases: o modelo conceitual e o modelo lógico, porém existe mais um
modelo: o físico.
Na primeira fase é abstraído o modelo conceitual. Este modelo descreve o banco
de dados de forma independente, sem necessitar do SGBD. O projeto de banco de dados
é representado em um DER – Diagrama de Entidade Relacionamento, como mostra a
figura a seguir (HEUSER, 1998).
Figura 12 – Exemplo do Modelo Conceitual
Fonte: Adaptada de Heuser (1998)
E na segunda fase é abstraído o modelo lógico. Modelo que representa o banco
de dados na maneira como é visto pelo usuário do SGBD. Ao contrário do conceitual,
depende do SGBD utilizado no projeto. E é gerado a partir do modelo conceitual
desenvolvido na primeira fase do projeto de banco de dados (HEUSER, 1998).
32
Figura 13 – Exemplo do Modelo Lógico
Fonte: Adaptada de Heuser (1998)
2.4- A Linguagem SQL
A Structured Query Language- SQL que traduzido para o português significa
Linguagem de Consulta Estruturada, é a linguagem padrão para definição e
manipulação no banco de dados relacional (IBMc, 2011). É uma linguagem simples e
de fácil uso (DAMAS, 2007).
A linguagem SQL se divide em três principais grupos: DDL, DML e DCL. A
DDL (Data Definition Language– Linguagem de Definição de Dados) trabalha com os
objetos e tem os seguintes comandos: ALTER – altera um objeto do banco de dados
(uma tabela, por exemplo), CREATE – cria um objeto na base de dados e DROP – apaga
um objeto da base de dados; Os comandos ALTER e CREATE, podem ser usados para
index (indices) e view (visões).
Outro grupo é a DML (Data Manipulation Language– Linguagem de
Manipulação de Dados), ela
trabalha com as tuplas (linhas), seus comandos são
SELECT – consuta os dados armazenados em uma tabela, INSERT – insere uma linha na
tabela, DELETE– deleta e UPDATE – permite alterar quantas linhas de dados for
preciso em uma tabela.
E por último, porém não menos importante, a DCL (Data Control Language–
Linguagem de Controle de Dados) trabalha com os utilizadores, controla o acesso aos
dados, seus principais comandos são: GRANT – seta os privilégios, permite o acesso aos
dados ao usuário e REVOKE – remove os privilégios dado ao usuário.
A linguagem SQL faz parte de uma das cinco gerações de linguagens, a quarta
geração. Ela atende a quase todas as necessidades para o desenvolvimento de um banco
de dados, porém para completar as necessidades que a SQL não atende, em algumas
ocasiões o desenvolvedor concilia a linguagem SQL com alguma outra linguagem de
programação (DAMAS, 2007).
33
2.5- Orientação a Objetos
A programação orientada a objetos é implementada pelo envio de mensagens a
objetos. Ela reúne alguns conceitos que precisam ser entendidos antes iniciar uma
programação orientada a objetos, como classe, objetos, herança e polimorfismo.
2.5.1- Classes
Uma classe é um modelo ou protótipo onde os objetos serão criados e definidos.
Assim, a classe define o estado e o comportamento de um objeto físico do mundo real,
como está representado na figura 14 (RICARTE, 2001).
Figura 14 – Exemplo de uma Classe
Fonte: Adaptada de Ricarte (2001)
2.5.2- Objetos
Objeto é uma instância de uma classe, sendo assim ele é um objeto físico do
mundo real. São justamente os objetos que caracterizam a programação orientada a
objetos. O objeto tem seus devidos atributos e métodos que o manipulam (RICARTE,
2001).
2.5.3- Polimorfismo
Polimorfismo consiste em implementar um código considerando classes
abstratas ou interfaces, ao invés de classes concretas (SIERRA, 2007).
2.5.4- Herança
A herança organiza e estruturar o software. As classes herdam o estado e o
comportamento de suas superclasses. Com a herança, classes podem herdar
características da classe pai, como por exemplo, atributos e métodos. Podendo assim a
subclasse, especificar ou estender a superclasse (RICARTE, 2001).
A figura 15 apresenta um exemplo de herança e polimorfismo. Foram criadas
três classes de tipos diferentes de canetas, porem todas são derivadas de outra classe. As
34
classes CanetaFlor, CanetaPalhaço e CanetaRelógio herdam os atributos e métodos
(mesma assinatura) da classe Caneta. Porém as ações dos métodos são diferentes para
cada uma das classes que estão herdando (MARIANI, 2010).
Figura 15 – Representação de Herança e Polimorfismo
Fonte: Adaptada de Mariani (2010)
2.5.5- A Linguagem Java
Java foi desenvolvido em 1991 por um grupo secreto da Sun Microsystems
denominado por “The Green Project”, que traduzido para o português significa “o
Projeto Verde”, com o intuito de desenvolver uma linguagem de grande importância na
área de informática (SERSON, 2008).
Java é uma linguagem de programação utilizada no desenvolvimento de
software que tem portabilidade entre as plataformas, através da máquina virtual ou
JAVA VIRTUAL MACHINE (JVM). Além disso, ela é orientada a objetos, o que
possibilita a reutilização de códigos desenvolvidos em outros projetos e trabalha com a
troca de mensagens entre os objetos, como mostra a figura 16 (SOMERA, 2006).
Linguagem de programação orientada a objetos é mais fácil de programar,
principalmente para iniciantes que tem certa dificuldade no inicio, pois a orientação a
objetos consegue fazer com que o programador se sinta mais a vontade no
desenvolvimento (SERSON, 2008).
35
Figura 16 - Linguagem Orientada a Objetos, objetos trocando mensagem
Fonte: Adaptada de Serson (2008)
2.6- Padrões de Projetos
Em uma definição mais recente, padrões de projeto não são projetos, como listas
encadeadas e tabelas de acesso aleatório, que podem ser codificadas em classes e ser
reutilizadas tais como então. Tampouco são projetos complexos, de domínio especifico,
para uma aplicação inteira ou subsistemas [...] Padrões de Projeto são descrições de
objetos e classes comunicantes que precisam ser personalizadas para resolver um
problema geral de projeto num contexto particular. (GAMMA, 2005).
Apesar de existirem diversos padrões de projeto, padrões têm sido descritos em
diferentes formatos.
2.6.1- Padrão MVC
O Padrão MVC – Model View Controller é um dos mais usados atualmente. Ele
é dividido em três camadas:
a. Model (Modelo): Representa os dados da organização e as regras de negócios
que governam o acesso e atualizações de dados.
b. View (Visão): Acessa os dados da organização através do modelo e especifica
como os dados devem ser apresentados. Quando o modelo é alterado, é a visão
é quem fica responsável por manter a consistência na sua apresentação.
c. Controller (Controlador) - Traduz as interações com a visão em ações a serem
realizadas pelo modelo. Com base na interação do usuário e os resultados das
ações do modelo, o controlador responde ao selecionar uma visão apropriada
(SUN, 2000 – 2002).
36
3- FERRAMENTAS
Foram selecionadas algumas ferramentas de desenvolvimento que serão usadas
neste projeto com o intuito de melhor desempenho do software.
3.1- ASTAH COMMUNITY
A ferramenta Astah Community é open source e é utilizada para o
desenvolvimento da modelagem de software. É flexível e extensível e contém vários
recursos. Nela é possível desenvolver vários diagramas: diagrama de casos de uso,
diagrama de classe, diagrama de sequência, diagrama de estados, diagrama de
atividades, diagrama de componentes, diagrama de implantação, diagrama de estrutura
composta, diagrama de comunicação e diagrama de pacote, como mostra a figura 17
(ASTAH_COMMUNITY, 2011).
Figura 17 - Visão geral da ferramenta Astah Community.
Fonte: Adaptada de Paraíso (2011)
3.2- BRMODELO
A ferramenta BrModelo é um aplicativo totalmente livre para modelagem de
software. É um resultado de um trabalho de graduação do curso de pós-graduação de
banco de dados de um aluno da Universidade de Várzea Grande – Univag. O BrModelo
37
tem como base a metodologia defendida pelo professor Heuser, em seu livro. Ele possui
as seguintes funcionalidades: construção do modelo de entidade e relacionamento, como
apresenta a figura 18, e mapeamento para o modelo relacional de banco de dados (SIS,
2007).
Figura 18 - Visão geral da ferramenta BrModelo.
3.3- NETBEANS
A ferramenta NetBeans foi fundada no ano de 2000 pela Sun Microsystems,
totalmente open-source. É um ambiente de desenvolvimento integrado para
desenvolvedores de software.Escrito em totalmente em Java, porém compila qualquer
tipo de linguagem (NETBEANSa, 2011). O IDE vem com drivers para os servidores de
banco de dados MySQL e PostgreSQL como mostra a figura 19 (NETBEANSb, 2011).
Figura 19 - Driver para o servidor de banco de dados MySQL
Fonte: Adaptada de NetBeansb (2011)
3.4- MYSQL
O MySql é o sistema gerenciador de banco de dados (SGBD) de código aberto
mais conhecido no mundo que trabalha com a linguagem SQL. Pois tem excelente
38
desempenho, confiabilidade e facilidade de uso. Tem uma grande portabilidade,
funciona em mais de 20 plataformas, sendo elas as principais, Linux, Windows, Mac e
Solaris e foi escrito em C e C++ (MYSQL, 2010).
39
4- O SISTEMA PROPOSTO
Para o processo de desenvolvimento do ACADSISTEM utilizou-se o RUP de
forma customizada. O RUP é descrito no capítulo 2 seção 2.1.3. Este capítulo descreve
as fases do processo de desenvolvimento do sistema, são elas: Concepção, Elaboração,
Construção e Transição.
4.1- Concepção
Nesta fase realizou-se o levantamento de dados e análise dos requisitos. Gerouse alguns artefatos importantes para o andamento do projeto como ata da entrevista e
documento de visão. As seções a seguir detalham esta fase.
4.1.1- Levantamento de Dados e Análise de Requisitos
Realizaram-se reuniões e entrevistas com o cliente da Universidade Federal de
Pelotas
–
UFPel
para levantamento
e
entendimento das
necessidades
do
ACADESISTEM, vide apêndice A. Em Seguida gerou-se um documento de visão com
o objetivo de apresentar uma visão geral do sistema, listando as necessidades e
funcionalidades gerais, bem como os envolvidos, vide apêndice B.
4.1.1.1- Necessidade do Negócio
A Universidade Federal de Pelotas de pós-graduação tem a grande necessidade
de organizar relatórios com perfis de alunos, para ter um bom acompanhamento do
desempenho acadêmico e controle desses alunos, como por exemplo, quantidade e
acompanhamento das matérias cursadas pelos alunos. Com isso, a Universidade sente
falta de um sistema automatizado que proporcione, à administração, emitir um relatório
com o perfil de cada aluno, onde possam ser contidos todos os dados cadastrais e
institucionais de cada um deles.
4.1.1.2- Descrição dos Envolvidos
a. Christianne Melo Silva Paraíso: Desenvolvedora do Software.
b. UFPel: mentora da idéia do aplicativo;
c. Hueder Paulo Moisés de Oliveira: Professor Adjunto I da UFPel; orientador pela
UFPel e cliente do projeto;
d. Administração da UFPel: interessada em acompanhar o perfil acadêmico dos
alunos e orientadores;
e. Juliana Forin Pasquini Matinez: orientadora pela Fatec.
40
4.1.2- Visão Geral do Sistema Proposto
Nesta subseção serão apresentadas algumas informações relacionadas ao
sistema.
4.1.2.1- Objetivos do Sistema
Desenvolver um sistema que seja capaz de:
a. Acesso através de autenticação com usuário e senha;
b. Armazenar dados cadastrais e institucionais de alunos e orientadores;
c. Arquivar publicações, como por exemplo, artigos e teses;
d. Fazer upload dessas publicações;
e. Pesquisar por aluno ou orientador.
4.1.2.2- Descrição do Escopo do Projeto
Um software personalizado para o sistema de pós-graduação precisa ser
desenvolvido para que a Universidade Federal de Pelotas (UFPel) possa controlar dados
cadastrais de alunos e orientadores, bem como as publicações feitas por eles, emitir
relatório com o perfil de cada aluno e com isso ter um melhor controle no sistema de
pós-graduação.
4.1.2.3- Impactos Esperados pelo Projeto
a.
Melhor acompanhamento dos alunos, com relação ao desempenho de cada um;
b.
Controle de orientadores;
c.
Acompanhamento das publicações feitas por alunos.
4.1.3- Requisitos do Sistema
Nesta seção apresentam-se os requisitos funcionais e não funcionais do sistema,
vide apêndice C.
4.1.3.1- Requisitos Funcionais
A tabela apresenta os requisitos funcionais do sistema ACADSISTEM.
41
Tabela 1 – Requisitos Funcionais
Código
Requisito
RF01
Possuir dois tipos de usuários: Administrador e Usuário Comum.
RF02
Permitir a liberação do sistema após autenticação do usuário.
RF03
Permitir as seguintes consultas aos usuários sobre alunos:
 RF0301 - Condição perante o programa de pós-graduação;
 RF0302 - Disciplinas cursadas;
 RF0303 - Disciplinas dependentes;
 RF0304 - Status de proficiência em língua estrangeira;
 RF0305 - Matricula em mestrado ou doutorado e;
 RF0306 - Em qual curso está matriculado;
 RF0307 - Publicações realizadas.
RF04
Para o usuário Administrador permitir o gerenciamento de:
 RF0401 - Usuários comuns;
 RF0402 - Alunos;
 RF0403 - Orientadores e;
 RF0404 - Publicações.
RF05
Gerar relatório a partir dos resultados obtidos na pesquisa.
RF06
Fazer upload das publicações.
4.1.3.2- Requisitos Não Funcionais
A tabela apresenta os requisitos não funcionais do sistema ACADSISTEM. Vide
apêndice C.
Tabela 2 – Requisitos Não Funcionais
Código
RNF01
RNF02
RNF03
RNF04
RNF05
Requisito
Acessível apenas em modo desktop.
Desenvolvido em JAVA.
Compatível com Windows XP e Seven.
MySQL – SGBD utilizado.
Hardware: Servidor superior a:
 RNF0501 - 2GB de RAM;
 RNF0502 - 100GB disponível em HD.
RNF06
Níveis de acesso.
42
4.1.4- Relatório de Caso de Uso
A figura 20 apresenta o diagrama de caso de uso do sistema, contendo todos os
casos de uso do sistema e os usuários. A descrição desse caso de uso encontra-se no
apêndice E.
Figura 20– Diagrama de Caso de Uso do Sistema
4.1.4.1- Descrição dos Casos de Uso
A seguir será apresentada uma simples descrição sobre o caso de uso, mas esta
descrição está detalhada com o passo a passo no apêndice D.
Tabela 3 – Autenticar
Nome:
Descrição:
Autenticar
A tela de autenticação aparecerá para o usuário e ele deverá informar
nos campos indicados, o seu nome e senha.
43
Tabela 4 – Pesquisar Usuário
Nome:
Descrição:
Pesquisar usuário
Após passar pela autenticação, o usuário poderá realizar pesquisas
sobre outros usuários. Como por exemplo, pesquisar para efetuar
algumas alterações.
Tabela 5 – Pesquisar Aluno
Nome:
Descrição:
Pesquisar aluno
Após passar pela autenticação, o usuário poderá realizar pesquisas
sobre alunos. Como por exemplo, saber o nome, o RA, em qual curso
está matriculado, etc.
Tabela 6 – Pesquisar Orientador
Nome:
Descrição:
Pesquisar orientador
Após passar pela autenticação, o usuário poderá realizar pesquisas
sobre orientadores. Como por exemplo, saber o nome, curso, efetuar
alterações e exclusões.
Tabela 7 – Pesquisar Publicação
Nome:
Descrição:
Pesquisar publicação
Após passar pela autenticação, o usuário poderá realizar pesquisas
sobre publicações. Como por exemplo, saber o autor(aluno) e ler o
conteúdo.
Tabela 8 – Gerenciar Aluno
Nome:
Descrição:
Gerenciar Aluno
O administrador do sistema devidamente autenticado poderá
cadastrar, alterar e excluir alunos do banco de dados.
Tabela 9 – Gerenciar Orientador
Nome:
Descrição:
Gerenciar Orientador
O administrador do sistema devidamente autenticado poderá
cadastrar, alterar e excluir orientadores do banco de dados.
Tabela 10 – Gerenciar Publicação
Nome:
Descrição:
Gerenciar Publicação
O administrador do sistema devidamente autenticado poderá cadastrar
e excluir publicações de alunos.
44
Tabela 11 – Gerenciar Usuário
Nome:
Descrição:
Gerenciar Usuário
O administrador do sistema devidamente autenticado poderá cadastrar
e excluir usuários.
Tabela 12 – Gerar Relatório
Nome:
Descrição:
Gerar Relatório de Aluno
O usuário poderá gerar um relatório simples sobre o aluno com as
informações selecionadas ou gerar um relatório completo, composto
de todas as informações sobre o aluno.
Tabela 13 – Upload
Nome:
Descrição:
Upload de Publicação
Usuário poderá pesquisar por uma publicação e realizar o upload de
tal arquivo.
4.2- Elaboração
Esta seção descreve a segunda fase do processo de desenvolvimento do
ACADSISTEM. Nesta fase foram realizados os diagramas de classe, de sequência, de
atividade, de estado, de componente e de utilização.
4.2.1- Diagrama de Classes
A figura 21 apresenta o diagrama de classes do sistema. Neste diagrama utilizouse o padrão de projeto: o Padrão MVC – Model View Controller. A parte amarela
representa a View, a parte azul representa o Controller e a parte rosa representa o
Model.
45
Figura 21 – Diagrama de Classes do Sistema – MVC.
46
Para melhor visualização do diagrama, ele foi dividido em três partes como mostra as
figuras 22 – representando a view, 23 – representando os controllers e 24 –
representando o model.
Figura 22 – Diagrama – View.
47
Figura 23 – Diagrama – Controllers.
48
Figura 24 – Diagrama – Model.
49
4.2.2- Diagrama de Sequência
A figura 25 representa a autenticação de um usuário no sistema. O usuário
informa o devido nome e senha na tela de autenticação e em seguida os dados serão
conferidos, se os dados estiverem incorretos, aparecerá uma mensagem informando o
erro, caso contrário, o usuário terá acesso ao sistema, pois ele estará logado.
Figura 25 – Diagrama de Sequência - Autenticação.
A figura 26 representa o cadastro de um aluno feito pelo usuário administrador.
O usuário informa os dados do aluno na tela de cadastro, esses dados serão enviados e
conferidos na classe Aluno, se estes dados estiverem incorretos, será informado a
mensagem informando o erro, caso contrário, será chamado o método da classe
AlunoDao que irá adicionar o aluno no banco de dados do sistema.
50
Figura 26 – Diagrama de Sequência - Cadastro de Aluno.
4.2.3- Diagrama de Atividades
A figura 27 descreve a atividade realizada pelo usuário administrador ao efetuar
uma exclusão relacionada ao orientador. O usuário informa os dados do orientador, em
seguida o sistema consulta esse orientador. Se o registro for encontrado o usuário
visualiza os dados que o sistema irá recuperar e o usuário confirma a exclusão, caso o
registro não exista, o sistema informará uma mensagem.
51
Figura 27 – Diagrama de Atividade de Exclusão de Orientador.
A figura 28 descreve a atividade realizada pelo usuário ao efetuar uma pesquisa
relacionada a aluno. O usuário informa o nome do aluno a ser consultado na tela de
pesquisa e em seguida o sistema busca este aluno no banco de dados. Se retornar mais
de um registro, o sistema informará uma lista contendo estes registros ao usuário, caso
contrário, se não for encontrado nenhum registro, o sistema informará ao usuário uma
mensagem dizendo que o aluno que estar sendo pesquisado é invalido no sistema, ou
seja, nenhum aluno cadastrado no banco de dados com o nome informado.
52
Figura 28 – Diagrama de Atividade de Pesquisa de Aluno.
4.2.4- Diagrama de Estado
A figura 29 representa o diagrama de estado do cadastro de usuário. O cadastro
será iniciado a partir da informação dos dados do usuario a ser cadastro, o objeto
passará para o estado de Processando Requisição e em seguida estes dados serão
enviados ao banco de dados, se os dados estiverem corretos, o objeto passa para o
estado de Finalizado, caso contrário, ele passa para estado de Não Cadastrado, assim ele
pode voltar ao estado Enviado, enviando os dados novamente, ou passar para o estado
Cancelado.
53
Figura 29 – Diagrama de Estado de Cadastro de Usuário.
4.2.5- Diagrama de Componente
O diagrama de componentes deste projeto é composto pelas três partes do MVC
– Modelo, Visão e Controladores; e o DAO, conforme mostrado na figura 30.
Figura 30 – Diagrama de Componente Geral.
54
4.3- Construção
Nesta seção apresenta-se a fase de construção. Nesta fase foram desenvolvidos
os protótipos de telas e o projeto de banco de dados.
4.3.1- Protótipo de Tela
A figura a seguir representa uma das principais interfaces do software com o
usuário. As demais encontram-se anexadas no apêndice F.
Figura 31 - Tela de Autenticação.
4.3.2- Projeto de Banco de Dados - Diagramas
Serão apresentadas as fases de modelagem do banco de dados, conforme as
figuras 33 e 34. A figura 33 demonstra o modelo conceitual do banco de dados, a sua
estrutura; e a figura 34 apresenta o modelo lógico, onde são demonstrados os detalhes
de implementação de cada campo das tabelas a partir do modelo conceitual.
55
Figura 32 – Modelo Conceitual do Sistema.
56
Figura 33 - Modelo Lógico do Sistema.
4.3.3- Dicionário de Dados
As tabelas com o dicionário de dados encontram-se em anexo no apêndice G.
4.3.4- Desenvolvimento do Sistema
Nesta fase foi realizado a implementação do ACADSISTEM. Com detalhes da
estrutura do Padrão utilizado, o MVC – Model View Controller.
4.3.4.1- Mvc
As subseções a seguir mostrarão o que cada padrão representa no Padrão MVC.
57
4.3.4.1.1- Model – Modelo
A parte do Modelo está composta neste projeto, pela interface Sujeito, as classes
Modelo, Aluno, Usuario, Publicacao e Orientador. E também as classes do padrão
DAO: AlunoDAO, UsuarioDAO, PublicacaoDAO e OrientadorDAO. Porém apenas as
classes e interfaces relacionadas a classe Usuario será representada nesta primeira parte
de apresentação da implementação.
4.3.4.1.1.1- Interface Sujeito
A figura 34 ilustra a interface Sujeito.
Figura 34 – Interface Sujeito
4.3.4.1.1.2- Classe Modelo
A figura 35 ilustra a classe Modelo.
58
Figura 35 – Classe Modelo
4.3.4.1.1.3- Classe Usuario
A classe usuário contém seus devidos atributos e os métodos getters e setters. A
Figura 36 representa a classe Usuário.
59
Figura 36 – Classe Usuário
4.3.4.1.2- View – Visão
A parte view está composta pela interface Observador e pelas visões
AutenticacaoView,
GerenciamentView
e
PesquisaView,
GerenciamentoView e a interface Observador serão representadas.
4.3.4.1.2.1-Interface Observador
A Figura 37 ilustra a interface Observador.
Figura 37 – Interface Observador
apenas
a
visão
60
4.3.4.1.2.2-Visão GerenciamentoView
A figura 38 ilustra a classe GerenciamentoView que implementa a interface
Observador.
Figura 38 – Classe GerenciamentoView
4.3.4.1.3- Controller - Controlador
A parte Controller, está composta por cinco famílias de controladores:
Autenticacao, Cadastro, Alteracao, Exclusao e Pesquisa. Serão representadas aqui a
interface Cadastro e uma classe da família de Cadastro, a CadastroUsuario.
4.3.4.1.3.1- Interface Cadastro – Controlador
A Figura 39 representa a interface Cadastro.
Figura 39 - Interface Cadastro
61
4.3.4.1.3.2-Classe CadastroUsuario
A classe CadastroUsuario implementa a interface Cadastro, assim ela
implementa também os métodos abstratos. A Figura 40 representa a classe
CadastroUsuario que implementa a interface Cadastro.
Figura 40 – Classe CadastroUsuário
4.4- Transição
Nessa seção apresenta-se a última fase do RUP, a fase de Transição. Nessa fase
foram realizados os testes e entregue o ACADSISTEM com todas as funcionalidades
desenvolvidas para serem validadas pelo cliente.
4.4.1- Testes
Esta fase de teste foi dividida em três fases: a primeira é o plano de teste, em
seguida o procedimento de teste e por ultimo o resultado de teste.
4.4.1.1- Plano de teste
O Plano de Teste encontra-se em anexo no apêndice I. Nele foram identificados
os casos e requisitos de teste necessários para testar o sistema ACADSISTEM.
62
4.4.1.2- Procedimento de Teste
O Procedimento de Teste encontra-se em anexo no apêndice J. Foi elaborado
para servir de auxilio na execução dos testes do sistema ACADSISTEM antes da
entrega final ao cliente UFPel. Nele encontram-se todos os passos de execução de testes
com os resultados requeridos para um resultado esperado.
4.4.1.3- Resultado de Teste
Os testes foram aplicados conforme o que foi especificado no procedimento de
teste. Foi aplicado e testado na máquina do cliente UFPel, foi também, avaliado todos
os aspectos descritos no plano de teste.
Todos os testes, sendo eles, de integridade de dados, função, interface,
desempenho e de segurança, obtiveram resultados satisfatórios. Para resultados
detalhados vide apêndice L.
63
5- CONSIDERAÇÕES FINAIS
Um sistema de controle acadêmico é muito importante para instituições de
ensino, devido à facilidade de gerenciamento de dados acadêmicos com segurança.
5.1- Contribuições e Conclusão
5.1.1- Contribuições
Neste trabalho foi possível desenvolver um software para o sistema de controle
acadêmico do curso de pós-graduação da Universidade Federal de Pelotas.
a.
Foi estudado o referencial teórico para o desenvolvimento de um software;
b.
Recolhido os requisitos funcionais e não funcionais da UFPel;
c.
Foi realizado o projeto de Banco de Dados Relacional;
d.
Implementado um sistema de software denominado AcadSistem;
e.
Foi também, realizado os testes em cima do software desenvolvido e;
f.
Os resultados foram analisados de acordo com o que foi pedido.
5.1.2- Conclusão
Antes, sem um aplicativo automatizado para armazenar os dados dos alunos e
orientadores, a única solução encontrada pela administração era recorrer à planilha do
Microsoft Office Excel para informações, o que não garantia segurança pela facilidade
de perda de dados, agora, com um sistema personalizado, é possível uma administração
mais segura e confiável a universidade, onde o administrador do sistema pode gerenciar
todos os alunos, orientadores, publicações e usuários da Universidade.
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.
64
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 ao elaborar uma interface incomum é um trabalho muito complexo.
Este trabalho contribuiu para o aprimoramento dos processos da Universidade
Federal de Pelotas - UFPel.
65
REFERÊNCIAS
ASTAH_COMMUNITY, 2011. Site Oficial Astah Comumunity. Disponível em
<http://astah.change-vision.com/en/product/astah-community.html
>
Acesso
em
09/06/2011.
BROOKSHEAR, J. G. Ciência da Computação - Uma Visão Abrangente. Porto
alegre: Bookman, 2003.
DAMAS, L. SQL Structured Query Language. Rio de Janeiro: LCT, 2005.
DATE, C. J. Introdução a Sistemas de Bancos de Dados. Rio de Janeiro: Elsevier:
2003.
GAMMA, E. H., R. J., R. Padrões de Projeto. Porto Alegre: Bookman, 2000.
HEUSER, C. A. Projeto de Banco de Dados. Porto Alegre: Sagra, 2000.
IBMa,
1998.
Rational
Unified
Process.
Disponível
em:
<
http://www.ibm.com/developerworks/rational/library/content/03July/1000/1251/1251_b
estpractices_TP026B.pdf > Acessado em: 27/03/2011.
IBMb,
2011.
Site
Oficial
IBM.
Disponível
em
<http://publib.boulder.ibm.com/infocenter/db2luw/v9/index.jsp?topic=/com.ibm.db2.ud
b.admin.doc/doc/c0004100.htm > Acessado em 10 de Abril de 2011.
KRUCHTEN, P. The Rational Unified Process - An Introduction. São Paulo:
ADDISON WESLEY, 2003.
66
MARIANI, A. C. O Mundo dos Atores: uma perspectiva de introdução à
programação
orientada
a
objetos.
Disponível
<http://www.inf.ufsc.br/poo/atores/sbie98/sbie98-atores.html>
em
Acessado
em
06/04/2011.
MYSQL, 2010. Site Oficial MySQL. Disponível em < http://www.mysql.com/whymysql/ >Acessado em 09/04/2011.
NETBEANSa,
2011.
Site
Oficial
NetBeans.
Disponível
em
<
em
<
http://netbeans.org/index_pt_PT.html> Acessado em 09/04/2011.
NETBEANSb,
2011.
Site
Oficial
NetBeans.
Disponível
http://netbeans.org/features/ide/database.html> Acessado em 09/04/2011.
OLIVEIRA, H. P. M. - 2011 - Professor Adjunto I da Universidade Federal de
Pelotas - UFPel.
OMG, 1997 - 2011. Site Oficial OMG. Disponível em < http://www.omg.org/spec/ >
Acessado em 10/04/2011.
REZENDE, D. A. Engenharia de software e sistemas de informação. Rio de Janeiro:
Brasport, 2005.
RICARTE, I. L. M., 2001. Programação Orientada a Objetos: Uma Abordagem
com Java. Disponível em <
http://www.dca.fee.unicamp.br/cursos/PooJava/Aulas/poojava.pdf > Acessado em
29/03/2011.
SERSON, R. R. Programação Orientada a Objetos com Java 6. Rio de Janeiro:
Brasport, 2008.
SIERRA, K.; BATES, B. Use a cabeça! Java. Rio de Janeiro: Alta Books, 2007.
SILVA, R. P. Uml2 Em Modelagem Orientada a Objetos. Florianópolis: Visual
Books, 2007.
67
SIS, 2007. Site Oficial BrModelo. Disponível em <http://www.sis4.com/brModelo/ >
Acesso em 07/04/2011.
SOMERA, G. Tratamento Profissional em Java. São Paulo: Digerati, 2006.
SOMMERVILLE, I. Engenharia de software. São Paulo: Pearson, 2007.
SUN,
2000
-
2002.
Model
-
View
-
Controller.
Disponível
em
<
http://java.sun.com/blueprints/patterns/MVC-detailed.html > Acesso em 09/06/2011.
UML, 2011. Site Oficial UML. Disponível em < http://www.uml.org/#UML2.0 >
Acessado em 10/04/2011.
TACHIZAWA, E. T.; ANDRADE, R. O. B. Gestão De Instituições De Ensino e
Organizações Escolares. Rio de Janeiro: FGV, 1999.
68
APÊNDICES
Apêndice A – Questionário
Questionário - AcadSistem
Cliente: Universidade Federal de Pelotas
Aplicação: AcadSistem
DESENVOLVIMENTO DE UM SISTEMA DE CONTROLE
ACADÊMICO – ACADSISTEM
Questionário para Levantamento de Requisitos
69
SUMÁRIO
1- QUESTIONÁRIO
70
70
1- QUESTIONÁRIO
Nove de Março de 2011, pesquisador e professor Adjunto I da Universidade
Federal de Pelotas – UFPel, no Rio Grande do Sul, Hueder Paulo Moisés de Oliveira
responde ao questionário sobre o projeto.
Questões referentes ao Projeto ACADSISTEM:
1. Qual é o objetivo do sistema?
Desenvolver um software de banco de dados para o sistema de pós-graduação
onde possam ser armazenados todos os dados cadastrais dos alunos e dos orientadores.
Além disso, o software deve permitir que as publicações sejam arquivadas e possa ser
feito upload desses arquivos. Esse aplicativo (software) é o Trabalho de Conclusão de
Curso da interessada. O aplicativo será desenvolvido em parceria entre a FATEC (que
terá um orientador para a aluna) e a UFPel (mentora da idéia do aplicativo) (que
também terá um orientador para a aluna).
2. Que área vai atender?
Ele atenderá a área Educativa.
3. Que tipo de usuários e quantos usuários estarão interagindo com o sistema?
Pessoal administrativo.
4. Quais são as principais funcionalidades que o sistema deverá possuir?
O sistema deverá realizar cadastro alunos e orientadores, gerar ficha completa
(relatório) ou somente com os dados solicitados dos alunos, arquivar publicações (entre
elas, artigos, dissertações e teses) junto à ficha do aluno.
5. Quais funcionalidades os usuários poderão acessar?
Gerar ficha completa ou somente com os dados solicitados dos alunos (por
exemplo, nome, data nascimento, RG, CPF, sexo, etc), arquivar e fazer upload das
publicações. Entretanto modificações que afetem tanto o sistema quanto a ficha
cadastral somente poderão ser feitas por pessoal autorizado.
71
Questões referentes à Infra Estrutura
6. É necessário utilizar perfil de usuário para definir acesso aos usuários?
Sim. O administrador terá acesso a todas as funcionalidades do software. E os
usuários comuns terão acesso apenas à pesquisa de alunos e publicações.
7. Qual plataforma o sistema irá utilizar?
Plataforma Windows. Futuramente se for de interesse, colocar para outras
plataformas.
8. Qual banco de dados que irá utilizar?
Será utilizado um SGBD livre, no caso, o MYSQL.
9. O sistema estará alocado dentro da Universidade ou em servidor de terceiros?
Dentro da Universidade.
10. Qual é o prazo de entrega?
10/12/2011. Preferencialmente.
11. Necessita de uma equipe para o treinamento do Projeto?
Não. Somente a desenvolvedora do sistema.
12. Há disponibilidade de alguém para acompanhar o desenvolvimento?
Sim. Pessoal administrativo.
13. Necessita treinamento no processo a ser sistematizado?
Sim, da desenvolvedora.
14. Necessidade de alguma linguagem especifica?
O software será desktop, no entanto a linguagem para esse projeto será JAVA.
72
15. Já há informações em arquivos ou banco de outros sistemas?
Sim, várias informações estão em planilhas (Excel) feitas pelo pessoal
administrativo.
16. Sistema terá integração com outros sistemas atuais?
Não.
17. Qual é a configuração padrão das máquinas da empresa (Windows 95, 98, 2000, XP
ou Linux)?
A maioria com Windows XP.
18. O sistema atenderá mais franquias da própria empresa?
Não
73
Apêndice B – Documento de Visão
Documento de Visão - AcadSistem
Cliente: Universidade Federal de Pelotas
Aplicação: AcadSistem
DESENVOLVIMENTO DE UM SISTEMA DE CONTROLE
ACADÊMICO – ACADSISTEM
Documento de Visão
74
SUMÁRIO
1- SOBRE O DOCUMENTO
1.1- Objetivos do Documento
1.2- Escopo
1.3- Referências
2- NECESSIDADE DO NEGOCIO
3- OBJETIVO DO PROJETO
4- DECLARAÇÃO PRELIMINAR DO ESCOPO
4.1- Descrição
4.2- Produtos a Serem Entregues
4.3- Requisitos
4.3.1- Requisitos Funcionais
4.3.2- Requisitos Não Funcionais
5- RESTRINÇOES
5.1- Restrição de Tempo
6- PREMISSAS
7- DESCRIÇÃO DO USUÁRIO
8- INFLUÊNCIA DAS PARTES INTERESSADAS
75
75
75
75
76
77
78
78
78
78
78
78
79
79
80
81
82
75
1- SOBRE O DOCUMENTO
1.1- Objetivos do Documento
Este documento trata principalmente do registro das necessidades de negócios,
da justificativa do Sistema de Controle Acadêmico, do entendimento atual das
necessidades do cliente e descreve resumidamente o novo produto, serviço ou resultado
que deve satisfazer esses requisitos. Tem o objetivo de alinhar as expectativas dos
interessados para formalizar o início do projeto. Nenhum detalhamento de
funcionalidades será feito neste documento. Outros documentos de definições de
requisitos serão gerados ao longo do projeto.
1.2- Escopo
O escopo deste documento trata do desenvolvimento de um Sistema de Controle
Acadêmico.
1.3- Referências
Para a construção deste documento foram utilizadas as seguintes referências:

Reuniões com um dos professores da UFPel, vide o anexo com
apêndice A;

Análise do sistema de banco de dados atual na universidade.
Este documento influencia o seguinte documento:

Documento de Requisitos
76
2- NECESSIDADES DO NEGÓCIO
Um software de banco de dados para o sistema de pós-graduação precisa ser
desenvolvido para que a Universidade Federal de Pelotas (UFPel) possa controlar dados
cadastrais de alunos e orientadores, bem como as publicações feitas por eles, emitir
relatório com o perfil de cada aluno e com isso ter um melhor controle no sistema de
pós-graduação.
77
3- OBJETIVO DO PROJETO
Desenvolver um sistema que seja capaz de:
a. Acesso através de autenticação com usuário e senha;
b. Armazenar dados cadastrais e institucionais de alunos e orientadores;
c. Arquivar publicações, como por exemplo, artigos e teses;
d. Fazer upload dessas publicações;
e. Pesquisar por aluno ou orientador.
78
4- DECLARAÇÃO PRELIMINAR DO ESCOPO
4.1- Descrição
A Universidade Federal de Pelotas de pós-graduação tem a grande necessidade
de organizar relatórios com perfis de alunos, para ter um bom acompanhamento
desempenho acadêmico e controle desses alunos.
Com isso, a Universidade sente falta de um sistema automatizado que proporcione, à
administração, emitir um relatório com o perfil de cada aluno, onde possam ser contidos
todos os dados cadastrais e institucionais de cada um deles.
4.2- Produtos a Serem Entregues
Os seguintes itens são considerados produtos do projeto.
Os itens a seguir serão entregues em etapas distintas do projeto:

1ª etapa: Motivação e Referencial Teórico;

2ª etapa: Modelagem do sistema e da base de dados;

3ª etapa: Implementação do sistema e da base de dados;

4ª etapa: Testes e Análise de Resultados.

5ª etapa: Sistema de Banco de Dados Acadêmico – Final.
4.3 - Requisitos
4.3.1- Requisitos Funcionais
O sistema deverá ter apenas um usuário administrador, o qual será responsável
por manter todos os outros usuários, gerenciar todos os dados cadastrais, assim
cadastrar alunos e orientadores. Os demais usuários poderão efetuar pesquisar, gerar os
relatórios com perfis de alunos e fazer upload das publicações. Para mais detalhes vide
documento de requisitos, encontra-se em anexo no apêndice C.
4.1.2- Requisitos Não Funcionais
O sistema utilizará a metodologia RUP, deverá ser escrito em linguagem JAVA,
ser um software desktop e ser compatível principalmente com a plataforma Windows
XP. A base de dados do Sistema ACADSISTEM deverá ser instalada em máquina
separada do ambiente de produção. Para mais detalhes vide documento de requisitos,
encontra-se em anexo no apêndice C.
79
5- RESTRIÇÕES
5.1- Restrição de Tempo
Este projeto tem uma data prevista para entrega, dia dez de dezembro de 2011.
No entanto, até essa data, o software precisa estar funcionando com os devidos
requisitos.
80
6- PREMISSAS

O projeto contará com o apoio de um orientador da Universidade;

O projeto contará com o apoio de uma orientadora da Faculdade Fatec.
81
7- DESCRIÇÃO DO USUÁRIO
O software será utilizado pelo pessoal administrativo da UFPel. Uma pessoa será
responsável pela administração do software. Esta mesma terá acesso a todas as
funcionalidades do software. Sendo assim, ela será responsável pelo cadastro de outros
usuários que terão acesso apenas a algumas funcionalidades
82
8- INFLUÊNCIA DAS PARTES INTERESSADAS
a. Christianne Melo Silva Paraíso: Desenvolvedora do Software.
b. Universidade Federal de Pelotas: mentora da idéia do aplicativo;
c. Hueder Paulo Moisés de Oliveira: Professor Adjunto I da Universidade Federal de
Pelotas; orientador pela UFPel e cliente do projeto;
d. Administração da UFPel: interessada em acompanhar o perfil acadêmico dos
alunos e orientadores;
e. Juliana Pasquini: orientadora pela Fatec;
83
Apêndice C – Documento de Requisitos
Documento de Requisitos - AcadSistem
Cliente: Universidade Federal de Pelotas
Aplicação: AcadSistem
DESENVOLVIMENTO DE UM SISTEMA DE CONTROLE
ACADÊMICO – ACADSISTEM
Documento de Requisitos
84
SUMÁRIO
1- INTRODUÇÃO
2- DEFINIÇÃO DO PROBLEMA
3- REQUISITOS FUNCIONAIS
4- REQUISITOS NÃO-FUNCIONAIS
85
86
87
88
85
1- INTRODUÇÃO
Este documento faz uma especificação dos requisitos do sistema para o cliente,
usuários finais e desenvolvedores de software, especificando o que foi requisitado pelo
cliente.
86
2- DEFINIÇÃO DO PROBLEMA
A tabela 14 apresenta a definição do problema.
TABELA 14 – DEFINIÇÃO DO PROBLEMA
O Problema
A Universidade tem a grande necessidade de organizar
relatórios com perfis de alunos para ter um bom
acompanhamento de desempenhos acadêmicos e
controle desses alunos de pós-graduação. Porém a
Universidade não tem um aplicativo automatizado que
proporcione, à administração, emitir um relatório com
o perfil de cada aluno e orientador, onde possam ser
contidos todos os dados cadastrais e institucionais de
cada um deles
Quem é afetado
Administradores da Universidade Federal de Pelotas.
Uma Boa Solução poderia
Desenvolver um sistema de software para o sistema de
controle acadêmico do curso de pós-graduação da
Universidade Federal de Pelotas.
ser
87
3- REQUISITOS FUNCIONAIS
A tabela 15 apresenta os requisitos funcionais.
Tabela 15 – Requisitos Funcionais
Código
Requisito
RF01
Possuir dois tipos de usuários: Administrador e Usuário Comum.
RF02
Permitir a liberação do sistema após autenticação do usuário.
RF03
Permitir as seguintes consultas aos usuários sobre alunos:
 RF0301 - Condição perante o programa de pós-graduação;
 RF0302 - Disciplinas cursadas;
 RF0303 - Disciplinas dependentes;
 RF0304 - Contagem de crédito;
 RF0305 - Status de proficiência em língua estrangeira;
 RF0306 - Matricula em mestrado ou doutorado e;
 RF0307 - Em qual curso está matriculado;
 RF0308 - Publicações realizadas.
RF04
Para o usuário Administrador permitir o gerenciamento de:
 RF0401 - Usuários comuns;
 RF0402 - Alunos;
 RF0403 - Orientadores e;
 RF0404 - Publicações.
RF05
Gerar relatório a partir dos resultados obtidos na pesquisa.
RF06
Fazer upload das publicações.
88
4- REQUISITOS NÃO FUNCIONAIS
A tabela 16 apresenta os requisitos não funcionais.
Tabela 16 – Requisitos Não Funcionais
Código
RNF01
RNF02
RNF03
RNF04
RNF05
Requisito
Acessível apenas em modo desktop.
Desenvolvido em JAVA.
Compatível com Windows XP e Seven.
MySQL – SGBD utilizado.
Hardware: Servidor superior a:
 RNF0501 - 2GB de RAM;
 RNF0502 - 100GB disponível em HD.
RNF06
Níveis de acesso.
89
Apêndice D – Especificação Suplementar
Especificação Suplementar - AcadSistem
Cliente: Universidade Federal de Pelotas
Aplicação: AcadSistem
DESENVOLVIMENTO DE UM SISTEMA DE CONTROLE
ACADÊMICO – ACADSISTEM
Especificação Suplementar
90
SUMÁRIO
1- DEFINIÇÕES LEGAIS E REGULARES
2- ATRIBUTOS DE QUALIDADE AO SISTEMA
3- ATRIBUTOS DE CONFIABILIDADE
91
92
93
91
1- DEFINIÇÕES LEGAIS E REGULARES
A tabela a seguir apresenta a todos os envolvidos do projeto a definição do título
do sistema, da propriedade e distribuição.
Tabela 17 – Definições do Sistema
Definições Gerais do Sistema
Título do Sistema
Propriedade do Sistema
Distribuição do Sistema
AcadSistem – Sistema de Controle Acadêmico.
O sistema AcadSistem é de propriedade de seus
idealizadores.
A distribuição do sistema é de responsabilidade de seus
idealizadores. Não é garantida nenhuma exclusividade no
uso do sistema.
92
2- ATRIBUTOS DE QUALIDADE AO SISTEMA
Na tabela a seguir são apresentados os requisitos de design do sistema
AcadSistem que será desenvolvido para uso da Universidade Federal de Pelotas.
Tabela 18 – Requisitos de Design e Qualidade
Requisitos de Design e Qualidade
Cores da Interface com o Usuário
Logotipo na Interface
Intuitividade e Usabilidade na
Interface
Compatibilidade de Browsers
Restrições de Design
As cores utilizadas na interface de interação
com o usuário serão as cores laranja, azul e
preto.
O logotipo do sistema deverá ser inserido em
todas interfaces de interação com o usuário.
As interfaces do sistema deverão ser intuitivas,
de forma que se gaste o menor tempo possível
com treinamento do pessoal que utilizará o
sistema.
O sistema deverá ser compativel com o
Sistema Operacional Windows.
Cores destoantes.
Logotipo com tamanho incompativel.
93
3- ATRIBUTOS DE CONFIABILIDADE
A tabela abaixo registra os requisitos de confiabilidade do sistema, são
abordados tempo de disponibilidade, tempo médio entre falhas e reparos taxa aceitavel
de erros ou defeitos.
Tabela 19 – Requisitos de Confiabilidade
Requisitos de Confiabilidade
Disponibilidade do Sistema O sistema deverá estar disponível aos usuários 24h por dia.
Tempo Médio Entre Falhas Após a fase de implantação do sistema o tempo médio entre
falhas será de 30 dias.
O tempo de reparo deverá respeitar o limite maximo de 48h
Tempo Médio de Reparo
para finais de semana e 24h para dias de semana, sendo que,
durante a semana o trabalho de reparo será efetuado após o
horário de expediente da Universidade. Para caso de extrema
necessidade será tolerado o limite máximo de 2h para
reparos durante o expediente da Universidade.
Erros importantes serão aceitos desde que se respeite o
Taxa de Erros
tempo de reparo estipulado.
Categorizados
Erros críticos não serão aceitos.
Entende-se por erro importante: incapacidade de utilizar
determinada parte do sistema.
Entende-se por erro crítico: perda total de dados.
94
Apêndice E – Descrição do Caso de Uso
Descrição do Caso de Uso - AcadSistem
Cliente: Universidade Federal de Pelotas
Aplicação: AcadSistem
DESENVOLVIMENTO DE UM SISTEMA DE CONTROLE
ACADÊMICO – ACADSISTEM
Descrição do Caso de Uso
95
SUMÁRIO
1- CASO DE USO DO SISTEMA
96
96
1- CASO DE USO DO SISTEMA
As tabelas a seguir detalham os casos de uso do sistema.
Tabela 20 – Caso de Uso Autenticar
Nome:
Autenticar
Atores:
Todos os tipos de usuários
Precondições: Nenhuma.
1. Usuário abre o sistema AcadSistem.
2. O usuário deve informar no local indicado o login e a senha e
Fluxo
clicar no botão “logar”.
3. Caso seja usuário do tipo Administrador, irá abrir a tela
Principal:
principal do administrador; caso contrário, abrirá a tela
principal comum.
Fluxo de
Exceção [3]:
3.1.Caso o login ou senha esteja incorreto ou login não exista no
banco de dados, o sistema enviará uma mensagem informando
o erro;
3.2.Usuário confirma a informação e tenta o login novamente.
Tabela 21 – Caso de Uso Pesquisar Usuário
Nome:
Pesquisar usuário.
Atores:
Usuários Administradores.
Precondições: Usuário ser administrador e estar logado no sistema.
Fluxo
1. Usuário seleciona “Por Usuário” no menu de pesquisas;
Principal:
2. Usuário deve informar nome ou parte do nome do usuário na
tela de pesquisa de usuário e clicar no botão “Pesquisar”;
3. Em seguida o sistema retornará uma lista de usuários que tem
o nome ou parte do nome informado;
4. Usuário seleciona o usuário desejado.
Fluxo
de
Exceção [3]:
1.1.Caso não exista nenhum usuário com o nome ou parte do nome
informado, o sistema retornará uma mensagem informando que
não existe nenhum usuário cadastrado com aquele nome.
1.2.Em seguida o usuário confirma a informação.
Tabela 22 – Caso de Uso Pesquisar Aluno
Nome:
Pesquisar aluno.
Atores:
Usuários Administradores.
Precondições: Usuário ser administrador e estar logado no sistema.
Fluxo
1. Usuário seleciona “Por Aluno” no menu de pesquisas;
Principal:
2. Usuário deve informar nome ou parte do nome do aluno na tela
de pesquisa de aluno e clicar no botão “Pesquisar”;
3. Em seguida o sistema retornará uma lista de aluno que tem o
nome ou parte do nome informado;
4. Usuário seleciona o aluno desejado.
97
Fluxo
de
Exceção [3]:
3.1.Caso não exista nenhum aluno com o nome ou parte do nome
informado, o sistema retornará uma mensagem informando
que não existe nenhum aluno cadastrado com aquele nome.
3.2.Em seguida o usuário confirma a informação.
Tabela 23 – Caso de Uso Pesquisar Orientador
Nome:
Pesquisar orientador.
Atores:
Usuários Administradores.
Precondições: Usuário ser administrador e estar logado no sistema.
Fluxo
1. Usuário seleciona “Por Orientador” no menu de pesquisas;
Principal:
2. Usuário deve informar nome ou parte do nome do orientador
na tela de pesquisa de aluno e clicar no botão “Pesquisar”;
3. Em seguida o sistema retornará uma lista de orientadores que
tem o nome ou parte do nome informado;
4. Usuário seleciona o orientador desejado.
Fluxo
de
Exceção [3]:
3.1.Caso não exista nenhum orientador com o nome ou parte do
nome informado, o sistema retornará uma mensagem
informando que não existe nenhum orientador cadastrado com
aquele nome.
3.2.Em seguida o usuário confirma a informação.
Tabela 24 – Caso de Uso Pesquisar Publicação
Nome:
Pesquisar publicação.
Atores:
Usuários Administradores.
Precondições: Usuário ser administrador e estar logado no sistema.
Fluxo
1. Usuário seleciona “Por Publicação” no menu de pesquisas;
Principal:
2. Usuário deve informar nome ou parte do nome da publicação
na tela de pesquisa de publicação e clicar no botão
“Pesquisar”;
3. Em seguida o sistema retornará uma lista de publicações que
tem o nome ou parte do nome informado;
4. Usuário seleciona a publicação desejada.
Fluxo
de
Exceção [3]:
3.1.Caso não exista nenhuma publicação com o nome ou parte do
nome informado, o sistema retornará uma mensagem
informando que não existe nenhuma publicação cadastrada com
aquele nome.
3.2.Em seguida o usuário confirma a informação.
Tabela 25 – Caso de Uso Pesquisar Usuário
Nome:
Gerenciar Usuário.
Atores:
Usuários Administradores.
Precondições: Usuário ser administrador e estar logado no sistema.
Fluxo
1. Usuário seleciona “Usuário” no menu de gerenciamento;
98
Principal:
Fluxo
Exceção:
2. Em seguida o sistema retornará a página de cadastro de
usuário. Caso o usuário deseje realizar alterações ou exclusões
de usuários, deverá pesquisar por tal primeiro.
de
N/A
Tabela 26 – Caso de Uso Gerenciar Aluno
Nome:
Gerenciar Aluno
Atores:
Usuários Administradores.
Precondições: Usuário ser administrador e estar logado no sistema.
Fluxo
1. Usuário seleciona “Aluno” no menu de gerenciamento;
Principal:
2. Em seguida o sistema retornará a página de cadastro de aluno.
Caso o usuário deseje realizar alterações ou exclusões de
alunos, deverá pesquisar por tal primeiro.
Fluxo
Exceção:
de
N/A
Tabela 27 – Caso de Uso Gerenciar Orientador
Nome:
Gerenciar Orientador.
Atores:
Usuários Administradores.
Precondições: Usuário ser administrador e estar logado no sistema.
Fluxo
1. Usuário seleciona “Orientador” no menu de gerenciamento;
Principal:
2. Em seguida o sistema retornará a página de cadastro de
orientador. Caso o usuário deseje realizar alterações ou
exclusões de orientadores, deverá pesquisar por tal primeiro.
Fluxo
Exceção:
de
N/A
Tabela 28 – Caso de Uso Gerenciar Publicação
Nome:
Gerenciar Publicação.
Atores:
Usuários Administradores.
Precondições: Usuário ser administrador e estar logado no sistema.
Fluxo
1. Usuário seleciona “Publicação” no menu de gerenciamento;
Principal:
2. Em seguida o sistema retornará a página de cadastro de
publicação. Caso o usuário deseje realizar alterações ou
exclusões de publicações, deverá pesquisar por tal primeiro.
Fluxo
Exceção:
de
N/A
Tabela 29 – Caso de Uso Gerar Relatório de Aluno
Nome:
Atores:
Gerar Relatório de Aluno
Todos os tipos de usuários.
99
Precondições: Estar logado no sistema.
Fluxo
1. Usuário seleciona “Aluno” no menu de relatório;
Principal:
2. O sistema retornará a página solicitando o nome do aluno.
3. O usuário deve informar o nome ou parte do nome do aluno no
campo solicitado.
4. Em seguida o sistema retornará uma lista de alunos que tem o
nome ou parte do nome informado;
5. Usuário seleciona o aluno desejado.
6. Sistema retorna o relatório completo do aluno.
Fluxo
Exceção:
de
N/A
Tabela 30 – Caso de Uso Upload de Publicação
Nome:
Upload de Publicação
Atores:
Todos os tipos de usuários.
Precondições: Estar logado no sistema.
Fluxo
1. Usuário seleciona “Publicação” no menu de upload;
Principal:
2. O sistema retornará a página solicitando o nome do arquivo.
3. O usuário deve informar o nome ou parte do nome do arquivo
no campo solicitado.
4. Em seguida o sistema retornará uma lista de arquivos que tem
o nome ou parte do nome informado;
5. Usuário seleciona o arquivo desejado.
6. Sistema retorna o arquivo.
Fluxo
Exceção:
de
N/A
100
Apêndice F – Protótipo de Tela
Protótipo de Tela - AcadSistem
Cliente: Universidade Federal de Pelotas
Aplicação: AcadSistem
DESENVOLVIMENTO DE UM SISTEMA DE CONTROLE
ACADÊMICO – ACADSISTEM
Protótipo de Tela
101
SUMÁRIO
1- PROTÓTIPO DE TELA
1.1- Autenticar
1.2- Principal Administrador
1.3- Principal Comum
1.4- Gerenciar Aluno
1.5- Gerenciar Usuário
1.6- Gerenciar Orientador
1.7- Gerenciar Publicação
1.8- Pesquisar Aluno
1.9- Pesquisar Usuário
1.10- Pesquisar Orientador
1.11- Pesquisar e Upload de Publicação
1.12- Relatório de Aluno
102
102
102
103
104
104
105
106
106
107
108
108
109
102
1- PROTÓTIPO DE TELA
As figuras a seguir apresentam os protótipos de tela do sistema ACADSISTEM.
1.1- Autenticar
A figura 41 demonstra a tela de autenticação.
Figura 41 – Tela de Autenticação
A tela de autenticação tem dois campos no qual solicita o login e a senha do
usuário respectivamente e um botão que verificar o valor digitado no campo e o
redireciona a página principal do sistema.
1.2- Principal Administrador
A figura 42 demonstra a tela principal do usuário administrador.
103
Figura 42 – Tela de Principal do Administrador
Nesta tela é possível ao usuário administrador gerenciar e pesquisar outros
usuários, alunos, orientadores e publicações, além de gerar relatórios dos alunos.
1.3- Principal Comum
A figura 43 demonstra a tela principal do usuário comum.
Figura 43 – Tela de Principal do Usuário Comum
104
Nesta tela é possível ao usuário comum, pesquisar e realizar upload de por
publicações, além de gerar relatórios de alunos.
1.4- Gerenciar Aluno
A figura 44 demonstra a tela de gerenciamento de aluno.
Figura 44 – Tela De Gerenciamento de Aluno
Esta tela é composta por vários campos de texto, que solicitam os dados dos
alunos a serem cadastrados.
1.5- Gerenciar Usuário
A figura 45 demonstra a tela de gerenciamento de usuário.
105
Figura 45 – Tela De Gerenciamento de Usuário
Esta tela é composta por vários campos de texto, que solicitam os dados dos
usuários a serem cadastrados.
1.6- Gerenciar Orientador
A figura 46 demonstra a tela de gerenciamento de orientador.
Figura 46 – Tela De Gerenciamento de Orientador
106
Esta tela é composta por vários campos de texto, que solicitam os dados dos
orientadores a serem cadastrados.
1.7- Gerenciar Publicação
A figura 47 demonstra a tela de gerenciamento de publicação.
Figura 47 – Tela De Gerenciamento de Publicação
Esta tela é composta por vários campos de texto, que solicitam os dados das
publicações a serem cadastrados.
1.8- Pesquisar Aluno
A figura 48 demonstra a tela de pesquisa de aluno.
107
Figura 48 – Tela de Pesquisa de Aluno
Esta tela é composta por um campo de texto que recebe o nome do aluno a ser
pesquisado e uma tabela que retornará uma lista de alunos.
1.9- Pesquisar Usuário
A figura 49 demonstra a tela de pesquisa de usuário.
Figura 49 – Tela de Pesquisa de Usuário
Esta tela é composta por um campo de texto que recebe o nome do usuário a ser
pesquisado e uma tabela que retornará uma lista de usuários.
108
1.10- Pesquisar Orientador
A figura 50 demonstra a tela de pesquisa de orientador.
Figura 50 – Tela de Pesquisa de Orientador
Esta tela é composta por um campo de texto que recebe o nome do orientador a
ser pesquisado e uma tabela que retornará uma lista de orientadores.
1.11- Pesquisar e Upload de Publicação
A figura 51 demonstra a tela de pesquisa e upload de publicação.
Figura 51 – Tela de Pesquisa e Upload de Publicação
109
Esta tela é composta por um campo de texto que recebe o nome da publicação a
ser pesquisada e uma tabela que retornará uma lista de publicações.
1.12- Relatório De Aluno
A figura 52 demonstra a tela de solicitação de relatório de aluno.
Figura 52 – Tela de Solicitação de Relatório de Aluno
Esta tela receberá o RA do aluno, pesquisará o mesmo e retornará todos os dados
do aluno requerido pelo usuário do sistema.
110
Apêndice G – Dicionário de Dados
Dicionário de Dados - AcadSistem
Cliente: Universidade Federal de Pelotas
Aplicação: AcadSistem
DESENVOLVIMENTO DE UM SISTEMA DE CONTROLE
ACADÊMICO – ACADSISTEM
Dicionário de Dados
111
SUMÁRIO
1- DICIONÁRIO DE DADOS
112
112
1- DICIONÁRIO DE DADOS
A seguir serão descritas as tabelas que formarão o software.
Tabela 31 – Tabela Aluno
Nome da tabela:
Descrição:
Campo
ALU_RA
ALU_NOME
ALU_SEXO
ALU_DATANASC
ALU_CPF
ALU_FILIACAO
ALU_ENDEREÇO
ALU_TELEFONE
ALU_DATAMATR
ALU_DISCCONC
ALU_DISCPEND
ALU_PROFIC
ALU_SISTEMA
ALU_CURSO
ORIENT_ID
Aluno
Tabela que armazenará os dados do aluno.
Constraint
Tipo numérico
Descrição
PRIMARY KEY INT(2)
Código de identificação
NOT NULL
VARCHAR(50)
Nome
NOT NULL
VARCHAR(1)
Sexo
NOT NULL
DATE
Data de nascimento
UNIQUE
VARCHAR(20)
CPF
NOT NULL
VARCHAR(50)
Nome da mãe
NOT NULL
VARCHAR(50)
Endereço
NOT NULL
VARCHAR(20)
Telefone
NOT NULL
DATE
Data da matricula
VARCHAR(250) Disciplinas cursadas
VARCHAR(250) Disciplinas pendentes
VARCHAR (1)
Proficiência em língua
estrangeira
NOT NULL
VARCHAR(20)
Mestrado ou doutorado
NOT NULL
VARCHAR(20)
Curso
FOREING KEY
INT(2)
Código do orientador
Tabela 32 – Tabela Orientador
Nome da tabela:
Descrição:
Campo
ORIENT_ID
Orientador
Tabela que armazenará os dados do orientador.
Constraint
Tipo numérico
Descrição
PRIMARY
INT(2)
Código de identificação
KEY
ORIENT_NOME
NOT NULL
VARCHAR(50) Nome
ORIENT_DATANASC
NOT NULL
DATE
Data de nascimento
ORIENT_CPF
UNIQUE
VARCHAR(20) CPF
ORIENT_INSTITUICAO NOT NULL
VARCHAR(50) Nome da mãe
ORIENT_TITULACAO
NOT NULL
VARCHAR(50) Endereço
Tabela 33 – Tabela Publicação
Nome da tabela:
Descrição:
Campo
PUBL_ID
PUBL_TITULO
PUBL_DATAPUBL
PUBL_TIPO
PUBL_DIRETORIO
Publicação
Tabela que armazenará os dados das publicações.
Constraint
Tipo numérico
Descrição
PRIMARY
INT(2)
Código de identificação
KEY
NOT NULL
VARCHAR(50) Nome
NOT NULL
DATE
Data de publicação
VARCHAR(15) Tipo. Ex: tese ou artigo
NOT NULL
VARCHAR(200) Diretório do arquivo
113
ALU_RA
ORIENT_ID
FOREIGN
KEY
FOREIGN
KEY
INT(2)
Código do aluno que fez
INT(2)
Código do orientador
Tabela 34 – Tabela Usuário
Nome da tabela:
Descrição:
Campo
USU_ID
USU_NOME
USU_LOGIN
USU_TEL
USU_SENHA
USU_TIPO
Usuário
Tabela que armazenará os dados do usuário.
Constraint
Tipo numérico
Descrição
PRIMARY
INT(2)
Código de identificação
KEY
NOT NULL
VARCHAR2(50) Nome
NOT NULL
VARCHAR2(50) Login
NOT NULL
VARCHAR2(30) Telefone
NOT NULL
VARCHAR2(10) Senha
NOT NULL
CHAR(1)
Tipo. Ex: administrador ou
usuário comum
114
Apêndice H – Manual de Instruções do AcadSistem
Manual de Instruções do AcadSistem
Cliente: Universidade Federal de Pelotas
Aplicação: AcadSistem
DESENVOLVIMENTO DE UM SISTEMA DE CONTROLE
ACADÊMICO – ACADSISTEM
Manual de Instruções do AcadSistem
115
SUMÁRIO
1- INTRODUÇÃO
2- ACESSO AO SISTEMA ACADSISTEM
3- ACESSO PRINCIPAL DO USUÁRIO ADMINISTRADOR
4- ACESSO PRINCIPAL DO USUÁRIO COMUM
5- GERENCIAMENTO DE USUÁRIO
6- GERENCIAMENTO DE ALUNO
7- GERENCIAMENTO DE ORIENTADOR
8- GERENCIAMENTO DE PUBLICAÇÃO
9- PESQUISAR POR ALUNO
10- PESQUISAR POR ORIENTADOR
11- PESQUISAR POR PUBLICAÇÃO
12- PESQUISAR POR USUÁRIO
13- VISUALIZAÇÃO DA PUBLICAÇÃO
14- SOLICITAÇÃO DE RELATORIO DE ALUNO
15- RELATÓRIO COMPLETO DE ALUNO
116
117
118
120
121
123
125
127
129
130
131
132
133
134
135
116
1- INTRODUÇÃO
Este documento tem o objetivo de orientar o usuário final na utilização do
sistema para que possa aproveitar os recursos oferecidos.
117
2- ACESSO AO SISTEMA ACADSISTEM
A figura 53 mostra os detalhes da tela de autenticação.
Figura 53 – Detalhes da Tela de Autenticação
Tabela 35 – Descrição da Tela de Autenticação
Campo
1
Descrição
Login: campo destinado a identificação do usuário.
2
Senha: campo destinado a senha do usuário.
3
Logar: Botão de acesso ao sistema
4
Sair: Botão de saída do sistema.
Tanto o usuário comum quanto o usuário administrador acessam o sistema
através desta página. Os campos 01 e 02 são obrigatórios para o acesso ao sistema.
118
3- ACESSO PRINCIPAL DO USUÁRIO ADMINISTRADOR
A figura 54 mostra os detalhes da tela principal do usuário administrador.
Figura 54 – Detalhes da Tela Principal do Administrador
As figura 56 e 57 mostram os detalhes da barra de menu.
Figura 55 – Detalhes da Barra de Menu: Navegar
Figura 56 – Detalhes da Barra de Menu: Ajuda
119
Tabela 36 – Descrição da Tela Principal do Administrador
Campo
1
2
Descrição
Navegar: campo destinado ao acesso ao campo Logoff.
Ajuda: campo destinado ao acesso aos campos Conteúdo da
Ajuda e Sobre.
3
Ir: Botão de acesso ao cadastro de usuário.
4
Ir: Botão de acesso ao cadastro de aluno.
5
Ir: Botão de acesso ao cadastro de orientador.
6
Ir: Botão de acesso ao cadastro de publicação.
7
Pesquisar: Botão de acesso à pesquisa de aluno.
8
Pesquisar: Botão de acesso à pesquisa de orientador.
9
Pesquisar: Botão de acesso à pesquisa de publicação.
10
Pesquisar: Botão de acesso à pesquisa de usuário.
11
Gerar: Gerar relatório completo de aluno.
12
Sair: Botão de saída do sistema.
13
Logoff: Botão de saída do sistema.
14
Conteúdo da ajuda: Redirecionamento à ajuda.
15
Sobre: Título do Sistema.
Esta tela é de acesso restrito a usuários administradores. Os campos 13, 14 e 15
estarão na maioria das telas a seguir, por isso não serão descritos novamente.
120
4- ACESSO PRINCIPAL AO USUÁRIO COMUM
A figura 57 mostra os detalhes da tela principal do usuário comum.
Figura 57 – Detalhes da Tela Principal do Usuário Comum
Tabela 37 – Descrição da Tela Principal do Usuário Comum
Campo
1
2
Descrição
Navegar: campo destinado ao acesso ao campo Logoff.
Ajuda: campo destinado ao acesso aos campos Conteúdo da
Ajuda e Sobre.
3
Pesquisar: Botão de acesso à pesquisa de publicação.
4
Gerar: Gerar relatório completo de aluno.
5
Sair: Botão de saída do sistema.
Esta tela é de acesso restrito a usuários comuns. Nela o usuário pode pesquisar
por publicações e solicitar relatório completo de alunos.
121
5- GERENCIAMENTO DE USUÁRIO
A figura 58 mostra os detalhes da tela de gerenciamento de usuário.
Figura 58 – Detalhes da Tela de Gerenciamento de Usuário
Tabela 38 – Descrição da Tela de Gerenciamento de Usuário
Campo
1
2
Descrição
Navegar: campo destinado ao acesso ao campo Logoff.
Ajuda: campo destinado ao acesso aos campos Conteúdo da
Ajuda e Sobre.
3
Id: Campo destinado ao id do usuário.
4
Telefone: Campo destinado ao telefone do usuário.
5
Nome: Campo destinado ao nome do usuário.
6
Senha: Campo destinado à senha do usuário.
7
Login: Campo destinado ao login do usuário.
8
Tipo: Campo destinado ao tipo do usuário.
9
Novo: Botão para um novo cadastro.
10
Editar: Botão de edição de cadastro.
11
Alterar: Botão de alteração de cadastro.
12
Salvar: Botão de conclusão de cadastro.
13
Excluir: Botão de exclusão de cadastro.
14
Voltar: Redirecionamento à página inicial.
122
15
Sair do Sistema: Botão de saída do sistema.
Este tipo de gerenciamento é feito apenas pelo usuário administrador. Todos os
campos com * deverão ser preenchidos no ato do cadastro ou da alteração.
123
6- GERENCIAMENTO DE ALUNO
A figura 59 mostra os detalhes da tela de gerenciamento de aluno.
Figura 59 – Detalhes da Tela de Gerenciamento de Aluno
Tabela 39 – Descrição da Tela de Gerenciamento de Aluno
Campo
1
2
Descrição
Navegar: campo destinado ao acesso ao campo Logoff.
Ajuda: campo destinado ao acesso aos campos Conteúdo da
Ajuda e Sobre.
3
RA: Campo destinado ao ra do aluno.
4
Nome: Campo destinado ao nome do aluno.
5
Sexo: Campo destinado ao sexo do aluno.
6
Data de Nasc: Campo destinado à data de nascimento do aluno.
7
Filiação: Campo destinado à filiação do aluno.
8
CPF: Campo destinado ao cpf do aluno.
9
Endereço: Campo destinado ao endereço do aluno.
10
Telefone: Campo destinado ao telefone do aluno.
11
Data de Matr.:Campo destinado à data da matricula do aluno.
12
13
Curso: Campo destinado ao curso em que o aluno está
matriculado.
Teste: Campo destinado ao teste de proficiência em inglês.
124
14
15
16
Sistema: Campo destinado ao sistema em que o aluno está
matriculado.
Orientador: Campo destinado ao id do orientador do aluno.
Disc. Concl.:Campo destinado as matérias concluídas pelo
aluno.
17
Disc. Pend.:Campo destinado as matérias pendentes do aluno.
18
Novo: Botão para um novo cadastro.
19
Editar: Botão de edição de cadastro.
20
Alterar: Botão de alteração de cadastro.
21
Salvar: Botão de conclusão de cadastro.
22
Excluir: Botão de exclusão de cadastro.
23
Voltar: Redirecionamento à página inicial.
24
Sair do Sistema: Botão de saída do sistema.
Este tipo de gerenciamento é feito apenas pelo usuário administrador. Todos os
campos com * deverão ser preenchidos no ato do cadastro ou da alteração.
125
7- GERENCIAMENTO DE ORIENTADOR
A figura 60 mostra os detalhes da tela de gerenciamento de orientador.
Figura 60 – Detalhes da Tela de Gerenciamento de Orientador
Tabela 40 – Descrição da Tela de Gerenciamento de Orientador
Campo
1
2
Descrição
Navegar: campo destinado ao acesso ao campo Logoff.
Ajuda: campo destinado ao acesso aos campos Conteúdo da
Ajuda e Sobre.
3
Id: Campo destinado ao id do orientador.
4
Nome: Campo destinado ao telefone do orientador.
5
Data de Nasc.:Campo destinado à data de nascimento do
orientador.
6
CPF: Campo destinado ao CPF do orientador.
7
Titulação: Campo destinado à titulação do orientador.
8
Instituição: Campo destinado à instituição do orientador.
9
Novo: Botão para um novo cadastro.
10
Editar: Botão de edição de cadastro.
11
Alterar: Botão de alteração de cadastro.
12
Salvar: Botão de conclusão de cadastro.
13
Excluir: Botão deexclusão de cadastro.
126
14
Voltar: Redirecionamento à página inicial.
15
Sair do Sistema: Botão de saída do sistema.
Este tipo de gerenciamento é feito apenas pelo usuário administrador. Todos os
campos com * deverão ser preenchidos no ato do cadastro ou da alteração.
127
8- GERENCIAMENTO DE PUBLICAÇÃO
A figura 61 mostra os detalhes da tela de gerenciamento de publicação.
Figura 61 – Detalhes da Tela de Gerenciamento de Publicação
Tabela 41 – Descrição da Tela de Gerenciamento de Publicação
Campo
1
2
Descrição
Navegar: campo destinado ao acesso ao campo Logoff.
Ajuda: campo destinado ao acesso aos campos Conteúdo da
Ajuda e Sobre.
3
Upload: Botão para realizar upload do arquivo.
4
Id: Campo destinado ao id do orientador.
5
Data de Publ.:Campo destinado à data publicada da publicação.
6
Titulo: Campo destinado ao título da publicação.
7
Tipo: Campo destinado ao tipo da publicação.
8
Orientador: Campo destinado ao orientador da publicação.
9
Aluno: Campo destinado ao aluno que escreveu a publicação.
10
Diretório: Campo destinado ao diretório da publicação
11
Procurar: Botão para procurar diretório.
12
Novo: Botão para um novo cadastro.
13
Editar: Botão de edição de cadastro.
14
Alterar: Botão de alteração de cadastro.
128
15
Salvar: Botão de conclusão de cadastro.
16
Excluir: Botão de exclusão de cadastro.
17
Voltar: Redirecionamento à página inicial.
18
Sair do Sistema: Botão de saída do sistema.
Este tipo de gerenciamento é feito apenas pelo usuário administrador. Todos os
campos com * deverão ser preenchidos no ato do cadastro ou da alteração.
129
9- PESQUISAR POR ALUNO
A figura 62 mostra os detalhes da tela de pesquisa de aluno.
Figura 62 – Detalhes da Tela de Pesquisa de Aluno
Tabela 42 – Descrição da Tela de Pesquisa de Aluno
Campo
1
2
3
Descrição
Navegar: campo destinado ao acesso ao campo Logoff.
Ajuda: campo destinado ao acesso aos campos Conteúdo da
Ajuda e Sobre.
Nome: Campo destinado ao nome ou parte do nome do aluno a
ser pesquisado.
4
Pesquisar: Botão para realizar a pesquisa.
5
Tabela: Tabela destinada aos resultados encontrados.
6
Voltar: Redirecionamento à página inicial.
7
Sair do Sistema: Botão de saída do sistema.
Pesquisa destinada somente aos usuários administradores.
É preciso preencher o campo com o nome ou parte do nome do aluno para que o
sistema possa fazer a pesquisa através de filtro, caso contrário, o sistema trás todos os
resultados (alunos) existentes no banco de dados.
130
10- PESQUISAR POR ORIENTADOR
A figura 63 mostra os detalhes da tela de pesquisa de orientador.
Figura 63 – Detalhes da Tela de Pesquisa de Orientador
Tabela 43 – Descrição da Tela de Pesquisa de Orientador
Campo
1
2
3
Descrição
Navegar: campo destinado ao acesso ao campo Logoff.
Ajuda: campo destinado ao acesso aos campos Conteúdo da
Ajuda e Sobre.
Nome: Campo destinado ao nome ou parte do nome do
orientador a ser pesquisado.
4
Pesquisar: Botão para realizar a pesquisa.
5
Tabela: Tabela destinada aos resultados encontrados.
6
Voltar: Redirecionamento à página inicial.
7
Sair do Sistema: Botão de saída do sistema.
Pesquisa destinada somente aos usuários administradores.
É preciso preencher o campo com o nome ou parte do nome do orientador para
que o sistema possa fazer a pesquisa através de filtro, caso contrário, o sistema trás
todos os resultados (orientadores) existentes no banco de dados.
131
11- PESQUISAR POR PUBLICAÇÃO
A figura 64 mostra os detalhes da tela de pesquisa de publicação.
Figura 64 – Detalhes da Tela de Pesquisa de Publicação
Tabela 44 – Descrição da Tela de Pesquisa de Publicação
Campo
1
2
Descrição
Navegar: campo destinado ao acesso ao campo Logoff.
Ajuda: campo destinado ao acesso aos campos Conteúdo da
Ajuda e Sobre.
4
Nome: Campo destinado ao título ou parte do título da
publicação a ser pesquisada.
Pesquisar: Botão para realizar a pesquisa.
5
Tabela: Tabela destinada aos resultados encontrados.
6
Voltar: Redirecionamento à página inicial.
7
Sair do Sistema: Botão de saída do sistema.
3
Pesquisa destinada tanto para os usuários administradores quanto para usuários comuns.
É preciso preencher o campo com o título ou parte do título da publicação para que o
sistema possa fazer a pesquisa através de filtro, caso contrário, o sistema trás todos os
resultados (publicações) existentes no banco de dados.
132
12- PESQUISAR POR USUÁRIO
A figura 65 mostra os detalhes da tela de pesquisa de usuário.
Figura 65 – Detalhes da Tela de Pesquisa de Usuário
Tabela 45 – Descrição da Tela de Pesquisa de Usuário
Campo
1
2
Descrição
Navegar: campo destinado ao acesso ao campo Logoff.
Ajuda: campo destinado ao acesso aos campos Conteúdo da
Ajuda e Sobre.
4
Nome: Campo destinado ao nome ou parte do nome do usuário a
ser pesquisado.
Pesquisar: Botão para realizar a pesquisa.
5
Tabela: Tabela destinada aos resultados encontrados.
6
Voltar: Redirecionamento à página inicial.
7
Sair do Sistema: Botão de saída do sistema.
3
Pesquisa destinada somente aos usuários administradores.
É preciso preencher o campo com o nome ou parte do nome do usuário para que
o sistema possa fazer a pesquisa através de filtro, caso contrário, o sistema trás todos os
resultados (usuários) existentes no banco de dados.
133
13- VISUALIZACAO DA PUBLICACAO
A figura 66 mostra os detalhes da tela de visualização da publicação.
Figura 66 – Detalhes da Tela de Visualização da Publicação
Tabela 46 – Descrição da Tela de Visualização da Publicação
Campo
1
2
Descrição
Navegar: campo destinado ao acesso ao campo Logoff.
Ajuda: campo destinado ao acesso aos campos Conteúdo da
Ajuda e Sobre.
3
Upload: Botão para realizar upload do arquivo.
4
Id: Campo destinado ao id do orientador.
5
Data de Publ.:Campo destinado à data publicada da publicação.
6
Titulo: Campo destinado ao título da publicação.
7
Tipo: Campo destinado ao tipo da publicação.
8
Orientador: Campo destinado ao orientador da publicação.
9
Aluno: Campo destinado ao aluno que escreveu a publicação.
10
Diretório: Campo destinado ao diretório da publicação
11
Voltar: Redirecionamento à página inicial.
12
Sair do Sistema: Botão de saída do sistema.
Visualização de publicação destinada para usuários comuns. Nesta tela é
possível o usuário realizar o upload do arquivo.
134
14- SOLICITAÇÃO DE RELATORIO DE ALUNO
A figura 67 mostra os detalhes da tela de solicitação de relatório de aluno.
Figura 67 – Detalhes da Tela de Solicitação de Relatório de Aluno
Tabela 47 – Descrição da Tela de Solicitação de Relatório de Aluno
Campo
1
2
3
Descrição
Navegar:Campo destinado ao acesso ao campo Logoff.
Ajuda: Campo destinado ao acesso aos campos Conteúdo da
Ajuda e Sobre.
4
RA: Campo destinado ao RA do aluno solicitado.
Pesquisar: Botão para realizar a pesquisa.
5
Voltar: Redirecionamento à página inicial.
6
Sair do Sistema: Botão de saída do sistema.
Pesquisa destinada tanto a usuários administradores quanto a usuários comuns.
É preciso preencher o campo com o RA do aluno solicitado, senão não será
possível a solicitação de relatório.
135
15- RELATÓRIO COMPLETO DE ALUNO
A figura 68 mostra os detalhes da tela de relatório de aluno.
Figura 68 – Detalhes da Tela de Relatório de Aluno
Tabela 48 – Descrição da Tela de Relatório de Aluno
Campo
1
Descrição
Arquivo:Acesso ao campo Voltar e Logoff.
2
Nome: Campo de retorno do nome do aluno.
3
4
Data de Nasc.:Campo de retorno da data de nascimento do
aluno.
Endereço: Campo de retorno do endereço do aluno.
5
Filiação: Campo de retorno da filiação do aluno.
6
Sexo: Campo de retorno do sexo do aluno.
7
CPF: Campo de retorno do cpf do aluno.
8
Telefone: Campo de retorno do telefone do aluno.
9
RA: Campo de retorno do RA do aluno.
10
Sistema: Campo de retorno do sistema em que o aluno está
matriculado.
Data de Matr.: Campo de retorno da data de matricula do aluno.
11
12
13
14
15
Curso: Campo de retorno do curso em que o aluno está
matriculado.
Proficiência: Campo de retorno do teste de proficiência feito ou
não pelo aluno.
Orientador: Campo de retorno do orientador do aluno.
Disc. Concluídas: Campo de retorno das matérias concluídas
pelo aluno
136
16
Disc. Pendentes: Campo de retorno das matérias pendentes, não
feitas ainda pelo aluno.
Pesquisa destinada tanto a usuários administradores quanto a usuários comuns.
Esta tela tem como retorno, dados de apenas um aluno.
137
Apêndice I – Plano de Teste
Plano de Teste - AcadSistem
Cliente: Universidade Federal de Pelotas
Aplicação: AcadSistem
DESENVOLVIMENTO DE UM SISTEMA DE CONTROLE
ACADÊMICO – ACADSISTEM
Plano de Teste
138
SUMÁRIO
1- INTRODUÇÃO
1.1- Objetivo
2- ESCOPO
3- REQUISITOS DE TESTE
3.1- Teste de Banco de Dados
3.2- Teste Funcional
3.3- Teste de Interface
3.4- Perfil de Desempenho
3.5- Teste de Carga
3.6- Teste de Stress
3.7- Teste de Segurança e de Controle de Acesso
3.8- Teste de Configuração
3.9- Teste de Instalação
139
139
140
141
141
141
141
141
141
142
142
142
142
139
1- INTRODUÇÃO
1.1- Objetivo
Este documento de Plano de Teste do Sistema de Controle Acadêmico atende
aos seguintes objetivos:
1. Identificar informações de projeto existentes e os componentes de software
que devem ser testados;
2. Listar os Requisitos de Teste recomendados (nível alto);
3. Recomendar e descrever as estratégias de teste a serem utilizadas;
4. Identificar os recursos necessários e fornecer uma estimativa dos esforços
de teste;
5. Listar os elementos do produto liberados do projeto de teste.
140
2- ESCOPO
Será testado o sistema do Sistema de Controle Acadêmico. Os testes unitários
abordarão a qualidade funcional, enquanto que os testes de sistema abordarão questões
de escalabilidade e desempenho.
As seguintes interfaces de sistema serão testadas:
1. Interface Inicial do Sistema;
2. Interface de Gerenciamento de Usuário;
3. Interface de Gerenciamento de Aluno;
4. Interface de Gerenciamento de Orientador;
5. Interface de Gerenciamento de Publicação;
6. Interface de Pesquisa.
141
3- REQUISITOS DE TESTE
A seguir serão identificados os itens que serão objetivos de teste, como por
exemplo, casos de uso, requisitos funcionais e requisitos não funcionais.
3.1- Teste de Banco de Dados
Verificar se as informações do usuário podem ser fornecidas.
Verificar se os dados e o tipo de usuários podem ser inseridos e exibidos.
Verificar se os perfis do administrador e as informações de conta podem ser
fornecidos e exibidos.
Verificar se os dados dos alunos podem ser inseridos e exibidos.
Verificar se os dados dos orientadores podem ser inseridos e exibidos.
Verificar se os dados das publicações podem ser inseridos e exibidos.
3.2- Teste Funcional
Verificar se os usuários conseguem visualizar as informações sobre as quais
solicitaram pesquisa.
Verificar se a inserção de conteúdo automático está funcionando – (Id ou RA).
Verificar se a exibição de tabelas está ocorrendo corretamente.
Verificar se o acesso de usuários cadastrados está ocorrendo corretamente.
Verificar se os usuários que tiveram suas contas canceladas não estão tendo
acesso ao sistema.
Verificar se os relatórios gerados podem ser impressos.
3.3- Teste de Interface
Navegar por todos os casos de uso, verificando se cada painel da interface com
usuário pode ser facilmente compreendida.
Verificar todas as funções do Conteúdo da Ajuda.
Verificar se todas as telas estão de acordo com as especificações.
3.4- Perfil de Desempenho
Verificar o tempo de resposta da interface.
3.5- Teste de Carga
Nenhum.
142
3.6- Teste de Stress
Nenhum
3.7- Teste de Segurança e de Controle de Acesso
Verificar se os usuários sem privilégios de administrador realmente não
conseguem acessar as informações destinadas somente a usuário administrador.
3.8- Teste de Configuração
Nenhum.
3.9- Teste de Instalação
Verificar se a instalação do gerenciador de banco de dados está de acordo com
as instruções.
143
Apêndice J – Procedimento de Teste
Procedimento de Teste - AcadSistem
Cliente: Universidade Federal de Pelotas
Aplicação: AcadSistem
DESENVOLVIMENTO DE UM SISTEMA DE CONTROLE
ACADÊMICO – ACADSISTEM
Procedimento de Teste
144
SUMÁRIO
1- OBJETIVO DOS TESTES
1.1- Matriz de Requisitos de Projetos/ Atividades X Teste
1.2- Equipamentos Necessários
2- PROCEDIMENTO PREPARATÓRIO
2.1- Preparação do Ambiente de Teste
3- PROCEDIMENTO DE TESTE
3.1- Teste de Integridade de Dados e de Banco de Dados
3.2- Teste de Interface
3.3- Teste de Função
3.4- Perfil de Desempenho
3.5- Teste de Segurança e Controle de Acesso
145
145
145
146
146
147
147
147
148
148
149
145
1- OBJETIVO DOS TESTES
Verificar a correta funcionalidade do sistema antes da entrega final ao cliente.
Tomar conhecimento e registrar erros, falhas do sistema.
1.1- Matriz de Requisitos de Projetos/ Atividades x Teste
A tabela 49 relata os itens de teste e sua respectiva descrição.
Tabela 49 – Itens de Teste
Item de Teste Descrição
3.1
Integridade de Cadastro
3.1
Consulta ao Banco de Dados
3.1
Gerenciar Usuário
3.1
Gerenciar Aluno
3.1
Gerenciar Orientador
3.1
Gerenciar Publicação
3.2
Imprimir Relatório Completo de Aluno
3.2
Fazer Upload de Publicação
3.2
Gerenciar Usuário
3.2
Gerenciar Aluno
3.2
Gerenciar Orientador
3.2
Gerenciar Publicação
3.3
Teste de Interface
3.4
Desempenho do Sistema
3.5
Autenticação no Sistema
1.2- Equipamentos Necessários
01(um) computador com o sistema ACADSISTEM instalado.
146
2- PROCEDIMENTO PREPARATÓRIO
2.1- Preparação do Ambiente de Teste
Certificar-se que a versão de software ACADSISTEM é a última fornecida pela
desenvolvedora;
Certificar-se que o computador tem comunicação com o banco de dados
MYSQL.
147
3- PROCEDIMENTO DE TESTE
3.1- Teste de Integridade de Dados e de Banco de Dados
Tabela 50 - Teste de Integridade de Dados e de Banco de Dados
Resultado
Satisfatório
1
Acessar o sistema com privilégio de administrador;

2

4
No menu “Gerenciar” clicar no botão relacionado ao
“Cadastrar Usuário”;
Na interface de cadastro de usuário cadastrar um novo
usuário;
Acessar a interface pesquisa usuário;
5
Localizar o registro do usuário cadastrado.

6
Repetir o processo 1 ao 5 para aluno, orientador e

publicação.
O registro existente na base de dados, referente ao usuário cadastrado, deve
corresponder com as informações inseridas pelo sistema.
Testar todos os campos de inserção de dados;

3
Resultado
Esperado
7
8
Resultado
Esperado
Negativo


Verificar se o sistema permite inserir caracteres diferentes

do especificado;
Para inserção de caracteres diferentes do permitido em determinado campo o
sistema não aceita a inserção do mesmo.
3.2- Teste de Interface
Tabela 51 – Teste de Interface
Resultado
Satisfatório
1
Acessar a pagina de autenticação do sistema;

2
Acessar o sistema com privilégios de administrador;

3
Verificar a disposição do conteúdo da interface inicial do

Negativo
administrador;
4
Acessar as funcionalidades de pesquisa;

5
Verificar a disposição do conteúdo na interface;

6
Acessar as funcionalidades de gerenciar o sistema;

7
Verificar a disposição do conteúdo na interface;

Resultado
Esperado
As disposições do conteúdo das interfaces devem estar de acordo com o
especificado nos protótipos de tela.
Repetir o procedimento com privilégios de usuário comum.
148
3.3- Teste de Função
Tabela 52 – Teste de Função
Resultado
Satisfatório
1
Resultado
Esperado
2
Resultado
Esperado
3
4
5
6
Resultado
Esperado
7
8
Resultado
Esperado
9
10
Resultado
Esperado
11
12
13
Resultado
Esperado
Negativo
Acessar o sistema ACADSISTEM com privilegio de

administrador
A interface deve possuir o menu “Gerenciar”, “Pesquisar” e “Relatório”;
No menu “Pesquisar” realizar uma pesquisa por aluno,

uma pesquisa por orientador, uma por publicação.
O resultado da pesquisa deve ser apresentado em tabela. Apague o que
digitado no campo de pesquisa e escreva novamente para repetir a operação;
Clicar no link “Voltar ao Início” na barra de ferramentas

ou no botão na parte inferior da interface.
Ir no menu “Gerenciar”, em seguida clicar no botão

relacionado ao “Cadastrar Usuário”.
Na interface de cadastro entrar com informações de um

novo usuário;
Clicar no botão “Salvar”;

Uma caixa de diálogo deve ser exibida informando o sucesso da operação.
foi
Repetir a operação para as funções “Alterar” e “Excluir”

usuário.
Fazer o mesmo para Aluno, Orientador e Publicação.

Uma caixa de diálogo deve ser exibida informando o sucesso da operação.
No menu “Relatório” clicar no botão relacionado a “Gerar

Relatório”.
Entrar com o código RA do aluno;

Se o código estiver correto, irá abrir uma tela com o relatório completo do aluno,
caso contrário, uma caixa de diálogo deve ser exibida informando que o aluno não
existe.
Voltar ao Início e pesquisar uma publicação.


Na tabela de publicações selecionar e clicar na linha da
tabela correspondente à publicação desejada.

Na tela com o retorno da publicação, clicar no botão
“Fazer Upload”.
Se o diretório da publicação estiver correto, a publicação será aberta.
149
3.4- Perfil de Desempenho
Tabela 53 – Perfil de desempenho
Resultado
Satisfatório
1
Acessar o sistema com privilégios de administrador;

2
Verificar o tempo de resposta para acesso ao sistema;

3
Cadastrar usuário, aluno, orientador e publicação no
sistema;
Verificar o tempo de reposta para o cadastro;

4
5
Resultado
Esperado
Negativo

Repetir a operação de acesso com privilégios de usuário

comum;
O tempo para autenticação do sistema não pode ser maior que 4 segundos.
Interfaces comuns não devem exceder o tempo de 2 segundo para serem
carregadas.
3.5- Teste de Segurança e Controle de Acesso
Tabela 54 – Teste de Segurança e Controle de Acesso
Resultado
Satisfatório
Negativo

1
Acessar o sistema com privilégios de usuário comum;
2
Verificar se os menus exclusivos do usuário administrador

aparecem;
Devem estar disponível somente os menus de pesquisa de publicação e gerar
relatório.
Alternar na mesma maquina o acesso entre usuário

administrador e usuário comum;
Os menus do administrador não devem aparecer na interface com o usuário
comum.
Tentar acessar o sistema alternando entre usuário e senha

invalida;
O sistema deve exibir uma caixa de diálogo informando o erro de usuário ou
senha.
Resultado
Esperado
3
Resultado
Esperado
4
Resultado
Esperado
150
Apêndice L – Resultado dos Testes
Resultado dos Testes - AcadSistem
Cliente: Universidade Federal de Pelotas
Aplicação: AcadSistem
DESENVOLVIMENTO DE UM SISTEMA DE CONTROLE
ACADÊMICO – ACADSISTEM
Resultado dos Testes
151
SUMÁRIO
1- RESULTADO DOS TESTES
1.1- Teste de Integridade de Dados
1.2- Teste de Função
1.3- Teste de Interface
1.4- Teste de Desempenho
1.5- Teste de Segurança E Controle De Acesso
152
152
152
152
153
153
152
1- RESULTADO DOS TESTES
As tabelas a seguir apresentam os resultados de testes.
1.1- Teste de Integridade de Dados
A Tabela a seguir representa o resultado obtido com relação ao teste de
integridade de dados e de banco de dados.
Tabela 55 – Resultado do Teste de Integridade de Dados e de Banco de Dados
Por: Hueder Paulo M. de Oliveira
Resultado Final
(X) Aprovado
( ) Reprovado
Por: Hueder Paulo M. de Oliveira
Data: 26/10/2011
Em: 26/10/2011
Execução
Comentários (se houver):
Os registros existentes na base de dados correspondem com as informações inseridas no
sistema.
Fonte: Adaptada de Oliveira (2011)
1.2- Teste de Função
A Tabela a seguir representa o resultado obtido com relação ao teste de função.
Tabela 56 – Resultado do Teste de Função
Por: Hueder Paulo M. de Oliveira
Resultado Final
(X) Aprovado
( ) Reprovado
Por: Hueder Paulo M. de Oliveira
Data: 26/10/2011
Em: 26/10/2011
Execução
Comentários (se houver):
Cadastros e pesquisas realizados com sucesso.
Fonte: Adaptada de Oliveira (2011)
1.3- Teste de Interface
A Tabela a seguir representa o resultado obtido com relação ao teste de
interface.
153
Tabela 57 – Resultado do Teste de Interface
Por: Hueder Paulo M. de Oliveira
Resultado Final
(X) Aprovado
( ) Reprovado
Por: Hueder Paulo M. de Oliveira
Data: 26/10/2011
Em: 26/10/2011
Execução
Comentários (se houver):
As disposições do conteúdo das interfaces estão de acordo com o especificado nos
protótipos de tela.
Fonte: Adaptada de Oliveira (2011)
4.4.1.3.4- Teste de Desempenho
A Tabela a seguir representa o resultado obtido com relação ao teste de
desempenho.
Tabela 58 – Resultado do Teste de Desempenho
Por: Hueder Paulo M. de Oliveira
Resultado Final
(X) Aprovado
( ) Reprovado
Por: Hueder Paulo M. de Oliveira
Data: 26/10/2011
Em: 26/10/2011
Execução
Comentários (se houver):
O tempo para autenticação do sistema não excede a 4 segundos. E as telas comuns levam
menos de 2 segundos para executar.
Fonte: Adaptada de Oliveira (2011)
4.4.1.3.5- Teste de Segurança e Controle de Acesso
A Tabela a seguir representa o resultado obtido com relação ao teste de
Segurança e Controle de Acesso.
154
Tabela 59 – Resultado do Teste de Segurança e Controle de Acesso
Por: Hueder Paulo M. de Oliveira
Resultado Final
(X) Aprovado
( ) Reprovado
Por: Hueder Paulo M. de Oliveira
Data: 26/10/2011
Em: 26/10/2011
Execução
Comentários (se houver):
Os menus do administrador não aparecem na interface com o usuário comum.
Fonte: Adaptada de Oliveira (2011)