SisEdu – Sistema Educacional - Módulo Financeiro
81
FACULDADE ALVORADA CURSO DE BACHARELADO EM SISTEMAS DE INFORMAÇÃO Emerson Alex Teixeira de Morais Michael James Rodrigues Romeiro SISEDU – SISTEMA EDUCACIONAL MÓDULO FINANCEIRO Brasília-DF 2011
description
Buscamos através deste projeto, expor a formulação de um trabalho descentralizado, modular e ágil de uma IES (Instituição de Ensino Superior), com objetivo de trabalhar com esta IES de maneira homogênea onde todos os módulos serão integrados.Especificamente este trabalho consiste em demonstrar a realização do projeto de construção do sistema web para realizar pagamento por boleto bancário, demonstrando a elaboração do sistema, desde as escolhas das ferramentas para o ambiente de desenvolvimento utilizando o estudo de viabilidade do projeto, indicando problemas subsequentes, expondo as necessidades e sugerindo novas rotinas informatizadas que serão totalmente otimizadas para a formulação de pagamentos via boleto bancário.
Transcript of SisEdu – Sistema Educacional - Módulo Financeiro
FACULDADE ALVORADA
CURSO DE BACHARELADO EM SISTEMAS DE INFORMAÇÃO
Emerson Alex Teixeira de Morais
Michael James Rodrigues Romeiro
SISEDU – SISTEMA EDUCACIONAL
MÓDULO FINANCEIRO
Brasília-DF
2011
ii
Emerson Alex Teixeira de Morais
Michael James Rodrigues Romeiro
SISEDU – SISTEMA EDUCACIONAL
MÓDULO FINANCEIRO
Orientadores: Prof. Mestre Osmar Ribeiro Torres
Profa. Mestre Elizabeth d´Arrochella Teixeira
Brasília-DF
2011
Monografia apresentada a
Faculdade Alvorada para a
obtenção do título de Bacharel
em Sistemas de Informação.
iii
AGRADECIMENTOS
Emerson Alex Teixeira de Morais – Primeiramente agradeço a Deus por
ter colocado dificuldades e me dado forças para vencer, pois sem as dificuldades
não haveria motivos para superação,
Agradeço também aos meus familiares em especial meus pais Luiz Carlos
de Morais e Rita Teixeira de Morais pela educação que me deram e pelo apoio
prestado. Agradeço ainda a todos da turma de Bacharelado em Sistemas de
Informação, turma de 2008-2011. Deixo créditos também a todos os professores
pelo suporte e orientação que nos deram ao longo desta jornada, em especial a
professora d’Arrochella que com punhos de ferro no conduziu e ao professor Osmar,
orientador desta monografia.
Michael James Rodrigues Romeiro – Agradeço á DEUS por me
proporcionar fôlegos de vida para contemplar toda essa história de vida. Dedico este
trabalho a meus pais por todo o seu amor e dedicação para comigo a minha família
por todo carinho e compreensão a minha namorada Juliana Maciel por sempre esta
ao meu lado nos momentos difíceis, aos meus professores por toda ajuda durante
meus estudos, a todos meus amigos da turma Bacharelado Sistemas de Informação
2008 a 2011, que juntos estamos trilhando no mesmo caminho para o sucesso.
iv
RESUMO
Buscamos através deste projeto, expor a formulação de um trabalho
descentralizado, modular e ágil de uma IES (Instituição de Ensino Superior), com
objetivo de trabalhar com esta IES de maneira homogênea onde todos os módulos
serão integrados.
Especificamente este trabalho consiste em demonstrar a realização do
projeto de construção do sistema web para realizar pagamento por boleto bancário,
demonstrando a elaboração do sistema, desde as escolhas das ferramentas para o
ambiente de desenvolvimento utilizando o estudo de viabilidade do projeto,
indicando problemas subsequentes, expondo as necessidades e sugerindo novas
rotinas informatizadas que serão totalmente otimizadas para a formulação de
pagamentos via boleto bancário.
Palavras-chave: Sistemas de Informação. Sistema Financeiro. Processo
Unificado. Modelagem Única de Sistemas. Engenharia de Software.
v
ABSTRACT
We seek through this project, exposing the formulation of a decentralized
work, modular and agile an HEI (Higher Education Institution), in order to work with
this IES evenly where all modules will be.
Specifically this work is to demonstrate the achievement of the project to
build the web system to make payment by bank, showing the development of the
system, since the choices of tools for the development environment using the
feasibility study for the project, indicating subsequent problems, exposing the needs
and suggesting new computerized routines that are fully optimized for the formulation
of payments via bank transfer.
Keywords: Information Systems. Financial System. Processo Unificado da
Rational Modeling Language. Software Engineering.
vi
LISTA DE FIGURAS
Figura 1 - Organograma da Faculdade ABC ................................................................................. 16
Figura 2 - O cilco de vida clássico (modelo cascata) ................................................................... 21
Figura 3 - O modelo de Prototipagem ............................................................................................. 23
Figura 4 - O modelo Espiral .............................................................................................................. 24
Figura 5 - Ciclo de vida do Scrum .................................................................................................... 26
Figura 6 - Ciclo de vida do Extreme Programming ....................................................................... 28
Figura 7 - Arquitetura Geral do RUP (Gráfico de Baleia) ............................................................. 35
Figura 8 - Requisição básica de um MVC ...................................................................................... 39
Figura 9 - Diagrama de caso de uso ............................................................................................... 41
Figura 10 - Diagrama de Classes .................................................................................................... 42
Figura 11 - Diagrama de Interação .................................................................................................. 43
Figura 12 - Diagrama de Estados .................................................................................................... 44
Figura 13 - Diagrama de Atividades ................................................................................................ 45
Figura 14 - Diagrama de caso de uso (SISEDU-Financeiro) ...................................................... 51
Figura 15 - Diagrama de classe (SISEDU-Financeiro) ................................................................. 54
Figura 16 - Modelo de Entidade e Relacionamento (SISEDU) ................................................... 55
Figura 17 - Árvore do sistema (SISEDU-Financeiro) .................................................................... 65
Figura 18 - Tela de Cadastro de Novo Boleto ............................................................................... 66
Figura 19 - Tela de Boleto Cadastrado com Sucesso .................................................................. 66
Figura 20 - Tela de Busca de Boleto ............................................................................................... 67
Figura 21 - Tela de Resultado de busca, caso não encontrado. ................................................ 67
Figura 22 - Tela de Edição de Boleto .............................................................................................. 67
Figura 23 - Confirmação para deleção ............................................................................................ 68
Figura 24 - Tela de Boleto Deletado com sucesso. ...................................................................... 68
Figura 25 - Visualização do Boleto. ................................................................................................. 69
Figura 26 - Menu de Navegação do Sistema ................................................................................ 70
vii
LISTA DE TABELAS
Tabela 1 - Planejamento do projeto de desenvolvimento .......................................... 18
Tabela 2 - Comparativo entre tecnologias ................................................................. 47
Tabela 3 - Lista de diagramas de caso de uso .......................................................... 51
Tabela 4 - Manter Boleto ........................................................................................... 52
Tabela 5 - Gerar Boleto ............................................................................................. 53
Tabela 6 - PERIODOS .............................................................................................. 56
Tabela 7 - MATRICULA ............................................................................................ 56
Tabela 8 - TURMAS .................................................................................................. 56
Tabela 9 - ENTURMACAO ........................................................................................ 57
Tabela 10 - DISCIPLINA_MATRICULA ..................................................................... 57
Tabela 11 - BANCO .................................................................................................. 57
Tabela 12 - BOLETO ................................................................................................. 57
Tabela 13 - CURSO .................................................................................................. 58
Tabela 14 - DISCIPLINA ........................................................................................... 58
Tabela 15 - DOCUMENTOS ..................................................................................... 59
Tabela 16 - GRADE_CURRICULAR ......................................................................... 59
Tabela 17 - HST_PESSOA ....................................................................................... 59
Tabela 18 - HST_USUARIO ...................................................................................... 60
Tabela 19 - INSCRICAO_VESTIBULAR ................................................................... 60
Tabela 20 - INSCRICAO_VESTIBULAR_ALUNO ..................................................... 60
Tabela 21 - OBSERVACAO ...................................................................................... 61
Tabela 22 - PAGAMENTOS ...................................................................................... 61
Tabela 23 - PARAMETROS ...................................................................................... 61
Tabela 24 - PERFIL ................................................................................................... 62
Tabela 25 - PERIODOS ............................................................................................ 62
Tabela 26 - PESSOA ................................................................................................ 63
Tabela 27 - PLANO_ENSINO ................................................................................... 63
Tabela 28 - TIPO_BOLETO ...................................................................................... 64
Tabela 29 - TIPO_DOC ............................................................................................. 64
Tabela 30 - TIPO_END ............................................................................................. 64
Tabela 31 - UF .......................................................................................................... 64
Tabela 32 - USUARIO ............................................................................................... 64
Tabela 33 - VESTIBULAR ......................................................................................... 65
viii
LISTA DE ABREVIATURAS E SIGLAS
Sigla Descrição
Página ANSI American National Institute
API Application Programming Interface (Interface de
Programação de Aplicações)
E-COMMERCE Comércio Eletrônico
FEBRABAN Federação Brasileira de Bancos
HTML Hypertext Markup Language (Linguagem de Marcação
Hipertexto) IES Instituição de Ensino Superior
IR Imposto de Renda
MVC Model-View-Controller (Modelo-Visão-Controlador)
ODBC Open Data Base Connectivity
OOSE Object-oriented software engineering
PHP PHP Hypertext Processor (Processador de Hipertexto PHP)
RUP Rational Unified Process (Processo Unificado da Rational)
SGBDOR Sistema de Gerenciamento de Banco de Dados Objeto
Relacional SGBG Sistema de Gerenciamento de Banco de Dados
SISEDU Sistema Educacional
SQL Structured Query Language (Linguagem de Consulta
Estruturada) UML Unified Modeling Language (Linguagem Única de
Modelagem) XP Extreme Programming (Programação Extrema)
9
SUMÁRIO
1. Introdução ........................................................................................................... 11
1.1. Tema ............................................................................................................ 11
1.2. Justificativa ................................................................................................... 12
1.3. Formulação do Problema ............................................................................. 12
1.4. Objetivos ...................................................................................................... 13
1.4.1. Objetivo Geral ........................................................................................ 13
1.4.2. Objetivo Específico ................................................................................ 13
1.5. Organização do Trabalho ............................................................................. 14
2. Análise Institucional ............................................................................................ 15
2.1. A empresa e seu Negócio ............................................................................ 15
2.1.1. Organograma da Empresa .................................................................... 15
2.2. Descrição das Necessidades ....................................................................... 16
2.3. Sistema de Informação Existente na Empresa ............................................ 16
2.4. Normas de Funcionamento .......................................................................... 17
2.5. Ambiente tecnológico existente .................................................................... 17
3. Cronograma ........................................................................................................ 18
4. Referencial Teórico ............................................................................................. 19
4.1. Engenharia de Software ............................................................................... 19
4.1.1. Modelos Prescritivos .............................................................................. 20
4.1.2. Desenvolvimento Ágil ............................................................................ 24
4.1.3. Arquitetura de Software ......................................................................... 28
4.2. Linguagem de Programação ........................................................................ 29
4.2.1. JavaScript .............................................................................................. 29
4.2.2. PHP (Personal Home Page Tools) ........................................................ 30
4.2.3. Delphi .................................................................................................... 30
4.3. Banco de Dados ........................................................................................... 31
4.3.1. Oracle .................................................................................................... 31
4.3.2. PostegreSQL ......................................................................................... 32
4.3.3. MySQL ................................................................................................... 33
4.4. RUP (Rational Unified Process) ................................................................... 34
4.5. MVC (Model View Controller) ....................................................................... 38
4.6. UML (Unified Model Language) ................................................................... 39
4.6.1. Diagrama de Caso de Uso .................................................................... 40
4.6.2. Diagrama de Classes ............................................................................ 41
4.6.3. Diagrama de Interação .......................................................................... 42
4.6.4. Diagrama de Colaboração ..................................................................... 43
4.6.5. Diagrama de Estados e Atividades ........................................................ 43
5. Proposta do Novo Sistema ................................................................................. 45
5.1. Descrição do Sistema Proposto ................................................................... 47
5.2. Resultados Esperados ................................................................................. 47
5.3. Restrições do Sistema Proposto .................................................................. 48
10
5.4. Áreas Afetadas Pelo Novo Sistema ............................................................. 48
5.5. Banco de Dados ........................................................................................... 48
6. Documentação de Análise .................................................................................. 49
6.1. Visão Macro dos Atores ............................................................................... 50
6.2. Identificação dos Atores ............................................................................... 50
6.3. Listas de Casos de Uso ............................................................................... 50
6.4. Diagrama de Caso de Uso ........................................................................... 51
6.5. Descrição Detalhada dos Casos de Uso ...................................................... 51
6.6. Diagrama de Classes ................................................................................... 54
6.7. Modelo de Entidade e Relacionamento........................................................ 55
6.8. Especificação das Tabelas ........................................................................... 56
6.9. Árvore do Sistema ........................................................................................ 65
6.10. Especificações Técnicas ........................................................................... 66
6.10.1. Layout das Principais Telas da Aplicação ............................................. 66
6.10.2 Navegação ............................................................................................ 69
6.11 Segurança Física e Lógica ........................................................................ 70
6.12 Segurança Física ...................................................................................... 70
6.13 Segurança Lógica ..................................................................................... 71
7 Plano de Implantação ......................................................................................... 72
7.1 Atividades Futuras........................................................................................ 72
8 Conclusão ........................................................................................................... 74
9 Bibliografia .......................................................................................................... 75
Anexo A – Dicionário de dados SISEDU ................................................................... 78
11
1. Introdução
Segundo CAMPANO (2009), a Internet não é um canal de comunicação para
ser subestimado e cada dia mais as empresas utilizam-na como parte integrante da
sua estratégia de marketing e publicidade. A diminuição de custos, a audiência mais
elevada e um grau superior de interatividade com o cliente/visitante são apenas
alguns dos aspectos que elevam a Internet nos dias de hoje ao mesmo nível que
outras formas de comunicação e marketing regularmente utilizados. Mas a verdade
é que a forma de fazer negócios mudou, evoluiu. Caso a empresa não mude de
igual forma o seu método de fazer negócios, não só ficará pra traz como estará
cometendo um erro que pode ditar o fim do seu negócio.
Segurança é um dos aspectos primordiais. Web sites de e-commerce vivem
das transações financeiras, é de supra importância que as mesmas sejam realizadas
num ambiente devidamente seguro e de confiança. De igual modo, é importante que
o sistema de pagamento seja rápido e simples.
Idealmente em termos operacionais a página de pagamento deverá estar
incluída no site da empresa tendo em atenção à inclusão de diversas formas de
pagamento.
1.1. Tema
Encontra-se em elaboração uma proposta de um sistema unificado na
Faculdade ABC (empresa fictícia), que lide com as solicitações de serviços,
monitoramento de informações financeiras e acadêmicas por gestores e discentes
matriculados, dentre outras atribuições dentro da Instituição, este projeto foi
nomeado de SISEDU (Sistema Educacional). O presente estudo visa o
desenvolvimento de um dos módulos integrantes deste sistema, responsável pela
parte financeira.
O módulo Financeiro do sistema SISEDU (Sistema Educacional) será um
sistema capaz de gerar boletos referentes a mensalidades e serviços e disponibilizá-
12
los on-line, através de Login/senha, facilitando a emissão e recebimento dos boletos
pelos alunos.
Esta é uma forma de centralizar o fluxo financeiro da Faculdade ABC em um
só lugar tornando possível o controle dos boletos gerados e a situação dos mesmos
(pago/pendente).
1.2. Justificativa
A organização do trabalho adotada atualmente pela Faculdade ABC pode
ser considerada defasada, pois é baseada em tarefas manuais com circulação de
documentos físicos (papéis) e geração de planilhas eletrônicas, ambas sem um tipo
de controle adequado.
O sistema Cathedra utilizado atualmente auxilia em algumas atividades
financeiras como a geração de boletos (em papel), porém este recurso somente os
emite, não permitindo o controle dos mesmos.
Notadamente a Faculdade ABC necessita de uma forma automatizada para
gerar e dispor os boletos de cobrança on-line provendo meios de controle.
1.3. Formulação do Problema
A Faculdade ABC é uma instituição de ensino superior do tipo fictícia situada
na cidade de Brasília, que usa sistemas informatizados que compreendem todas as
atividades desenvolvidas pela mesma, estando diretamente ligado à sua matriz em
Curitiba; utiliza o sistema denominado Cathedra que faz toda a gerência dos
recursos disponíveis, desde o nível operacional até o gerencial e o sistema
WebClass que gerencia basicamente os dados acadêmicos como notas e diários de
classe.
É notória a necessidade de uma integração eficiente entre o corpo docente,
os alunos e a Faculdade ABC, afim de otimizar os fluxos da instituição como um
todo.
13
Sendo mais específico, o grande problema encontrado no departamento
financeiro da Faculdade ABC é que o controle é feito através de planilhas eletrônicas
e documentos físicos (em papel) e planilhas eletrônicas.
1.4. Objetivos
O nosso objetivo é projetar e implementar um sistema, de forma que possa
abranger todas as necessidades e erradicar todo tipo de rotina manual, otimizando
ao máximo a credibilidade das rotinas de pagamento da instituição através de
boletos.
1.4.1. Objetivo Geral
Informatizar e automatizar a criação e gerenciamento de boletos da
Faculdade ABC em um ambiente WEB, visando facilitar o uso e a otimização do
processo de criação de boletos, eliminando as filas na central de atendimento para
os alunos retirarem a segunda via de boleto.
1.4.2. Objetivo Específico
Minimizar o tráfego na central de atendimento, tornando a rotina do aluno
mais cômoda e ágil, os boletos serão gerados automaticamente e disponibilizados
em ambiente WEB. Estarão disponíveis no portal da Faculdade ABC mediante
autenticação do aluno, onde será possível visualizar e imprimir seus boletos e ter
acesso a recursos adicionais como demonstrativo para imposto de renda (IR).
14
1.5. Organização do Trabalho
O primeiro capítulo refere-se ao contexto do trabalho, o tema, os objetivos
da monografia em apresentação.
O segundo capítulo realiza a apresentação da empresa, qual é o seu ramo
de negócio e como ela está organizada.
O terceiro capítulo apresenta o cronograma das atividades de
desenvolvimento dessa monografia, sinalizando os prazos para a finalização do
trabalho.
O quarto capítulo descreve o referencial teórico, todas as fontes de pesquisa
de ferramentas, tecnologias e metodologias que serão utilizadas para o
desenvolvimento do sistema e escrita da monografia.
No quinto capítulo, é apresentada a proposta, a descrição, os resultados, as
restrições e as áreas afetadas pelo sistema que será desenvolvido.
No sexto capítulo é apresentada a descrição e identificação dos atores e
casos de uso do sistema. Como também, a apresentação das principais telas do
sistema e suas funcionalidades.
O sétimo capítulo descreve as atividades desempenhadas para a
implantação sistema na empresa.
Para o oitavo capítulo esta registrada a conclusão do trabalho.
No nono e último capitulo estão descritas todas as referências bibliografias
que deram sustentação e base ao desenvolvimento deste trabalho.
15
2. Análise Institucional
Neste capítulo trataremos da análise institucional da Faculdade ABC, sua
história e seus objetivos bem como seu ramo de negócio, com o objetivo de abstrair
os conhecimentos necessários para entender suas necessidades perante a
construção de um novo sistema.
2.1. A empresa e seu Negócio
A Faculdade ABC é uma instituição de ensino superior fictícia, com filial
estabelecida em Brasília – Asa Norte, podendo ser classificada como de médio
porte. A Faculdade ABC faz parte de uma rede com matriz no Paraná e com várias
filiais em diferentes estados da federação. O quadro de funcionários é da própria
Faculdade ABC, dispensando assim o uso de serviços terceirizados.
2.1.1. Organograma da Empresa
Segundo FARIA (2008) o organograma é uma espécie de diagrama usado
para representar as relações hierárquicas dentro de uma empresa, ou simplesmente
a distribuição dos setores, unidades funcionais e cargos e a comunicação entre eles.
Credita-se a criação do organograma ao norte americano Daniel C. MacCallum
(EUA) por volta de 1856, quando este administrava ferrovias nos EUA. Desde então
o organograma se tornou uma ferramenta fundamental para as organizações, pois
além de facilitar a todos conhecer como funcionam as relações da empresa e sua
estrutura, permite inclusive, identificar alguns problemas ou, oportunidades de
melhorias, através de sua análise. Na criação de um organograma deve-se levar em
consideração que ele é uma representação da organização em determinado
momento e, portanto pode mudar. Para isto ele deve ser flexível e de fácil
interpretação. Quando o organograma é bem estruturado ele permite aos
componentes da organização saber exatamente quais suas responsabilidades, suas
funções e a quem devem se reportar.
16
A imagem abaixo representa o organograma da empresa que se trata da
representação gráfica da hierarquia da instituição.
A presidência, as diretorias e os departamentos da empresa, estão dispostos
da seguinte forma:
Figura 1 - Organograma da Faculdade ABC
2.2. Descrição das Necessidades
Notadamente há a necessidade de melhorar o processo de geração de
boletos e a forma com que serão disponíveis ao aluno.
Partindo desta necessidade, torna-se necessário a criação de um sistema
web capaz de gerar os boletos automaticamente e disponibilizá-los aos alunos.
2.3. Sistema de Informação Existente na Empresa
O atual software utilizado pela Faculdade ABC (Cathedra) é um sistema
concebido por terceiros e tem arquitetura cliente-servidor com sede dos dados no
Paraná o que torna por muitas vezes o acesso aos dados lentos bem como
dependência total aos sistemas legados em sua sede.
17
Com foco no departamento financeiro não há qualquer tipo de integração on-
line para uso de alguns serviços pelos alunos e todos os boletos são gerados e
impressos para serem entregues aos alunos em sala ou conforme solicitação na
central de atendimento.
O Webclass é um sistema proprietário web que por sua vez utiliza um banco
de dados próprio nos remetendo ao mesmo problema do Cathedra. É utilizado para
manter as funcionalidades acadêmicas da instituição, ou seja, é através dele que os
professores lançam notas de freqüência dos alunos, que são feitas as consultas
para saber os aprovados do semestre, sendo também responsável pelo controle de
turma e disciplinas.
2.4. Normas de Funcionamento
Após análise, constata-se que, para o devido funcionamento de qualquer
dos dois sistemas, o usuário deve ter acesso a eles via login. No caso do Cathedra,
é necessário que a aplicação esteja presente na máquina. Para o WebClass, o
funcionário deve ter acesso à rede interna da Faculdade, além de ser um professor
ou gestor de informações acadêmicas.
2.5. Ambiente tecnológico existente
O ambiente tecnológico é composto por: 100 computadores AMD Sempron,
1GB, HD 160GB, Gravador de DVD - Space BR, monitor 15.6 polegadas, sistema
operacional Windows XP, todo o pacote Microsoft Office 2003; 5 impressoras
Lexmark T632 e, 5 scanner HP 5590.
18
3. Cronograma
Desenvolver o cronograma significa determinar as datas de início e fim para
as atividades do projeto. Se as datas de início e fim não forem reais, é improvável
que o projeto termine como planejado.
Tabela 1 - Planejamento do projeto de desenvolvimento
MÊS ETAPAS
AN
O 2
01
1
Qu
inzen
a
Definiç
ão
do
Pro
ble
ma
Delim
ita
çã
o d
o T
em
a
Pe
sq
uis
a B
iblio
grá
fica
Le
van
tam
en
to T
eó
rico
Definiç
ão
da
meto
do
log
ia
Pla
ne
jam
en
to d
e A
ções
Le
van
tam
en
to d
e R
equ
isito
s
An
ális
e (
de
f. c
aso
s d
e u
so
)
Escre
ve
r a
mon
og
rafia
Ap
resen
tação
TC
C I
Ace
rtos a
pó
s A
pre
se
nta
çã
o
TC
C I
Pro
jeto
Cod
ific
açã
o
Teste
s
Ap
resen
tação
da
mono
gra
fia
Ace
rtos a
pó
s a
pre
se
nta
çã
o
En
trega
fin
al
Inte
gra
çã
o d
os M
ód
ulo
s
Fevereiro 1a.
2a.
Março 1a.
2a.
Abril 1a.
2a.
Maio 1a.
2a.
Junho 1a.
2a.
Julho 1a.
2a.
Agosto 1a.
2a.
Setembro 1a.
2a.
Outubro 1a.
2a.
Novembro 1a.
2a.
Dezembro 1a.
2a.
19
4. Referencial Teórico
Para o desenvolvimento deste trabalho foram estudados os principais
conceitos do RUP (Rational Unified Process) para o uso das melhores práticas de
desenvolvimento de software moderno e a UML (Unified Modeling Language) para a
modelagem do sistema.
Foram colocadas em confronto diferentes linguagens de programação bem
como diferentes bancos de dados para a verificação das vantagens e desvantagens
da cada uma delas e futura escolha para utilização na construção do sistema.
4.1. Engenharia de Software
Na concepção de SOMMERVILLE (2003) a engenharia de software é uma
disciplina da engenharia que se ocupa de todos os aspectos da produção de
software, desde os estágios iniciais de especificação do sistema até a manutenção
desse sistema, depois que ele entrou em operação.
Segundo PRESSMAN (1995) a engenharia de software compreende um
conjunto de etapas que envolvem métodos, ferramentas e os procedimentos. Essas
etapas muitas vezes são citadas como paradigmas de engenharia de software. Um
paradigma de engenharia de software é escolhido tendo-se como base a natureza
do projeto e da aplicação, os métodos e as ferramentas a serem usados, os
controles e os produtos que precisam ser entregues.
Segundo FILHO (2001) as máquinas de tratamento de informação são
organizadas em estruturas úteis, formando os sistemas de informática.
Ainda segundo PRESSMAN (1995) a engenharia de software é um rebento
da engenharia de sistemas e de hardware. Ela abrange um conjunto de três
elementos fundamentais que possibilitam ao gerente o controle do processo de
desenvolvimento do software e oferece ao profissional uma base para a construção
de software de alta qualidade produtivamente, são eles:
Métodos: proporcionam os detalhes de “como fazer” para construir o
software.
Ferramentas: proporcionam apoio automatizado ou semi-automatizado aos
métodos.
20
Procedimentos: constituem o elo que mantém entre os métodos e as
ferramentas e possibilita o desenvolvimento racional e oportuno do software de
computador.
Ainda segundo FILHO (2001) o software é a parte programável de um
sistema de informática. Ele é um elemento central que realiza estruturas complexas
e flexíveis que trazem funções, utilidade e valor ao sistema. Mas outros
componentes são indispensáveis: as plataformas de hardware, os recursos de
comunicação e informação, os documentos de diversas naturezas, as bases de
dados e até os procedimentos manuais que se integram aos automatizados.
4.1.1. Modelos Prescritivos
Conforme PRESSMAN (1995) os modelos prescritivos de processo definem
um conjunto distinto de atividades, ações, tarefas, marcos e produtos de trabalho
que são necessários para fazer engenharia de software com alta qualidade. Esses
modelos de processos não são perfeitos, mas efetivamente fornecem um roteiro útil
para o trabalho de engenharia de software.
4.1.1.1. Modelo Cascata
Segundo SOMMERVILLE (2003) o modelo cascata considera as atividades
de especificação, desenvolvimento, validação e evolução, que são fundamentais ao
processo, e as representa como fases separadas do processo, como a
especificação de requisitos, o projeto de software, a implementação, os testes e
assim por diante.
À medida que para PRESSMAN (1995) o modelo cascata é o modelo de
ciclo de vida clássico e requer uma abordagem sistemática, sequencial ao
desenvolvimento do software, que se inicia no nível do sistema e avança ao longo
da análise, projeto, codificação, teste e manutenção. Modelado em função do ciclo
de engenharia convencional, o paradigma do ciclo de vida abrange as seguintes
atividades:
21
A figura 2 demonstra o ciclo de vida do modelo cascata:
Figura 2 - O cilco de vida clássico (modelo cascata) Fonte: PRESSMAN (1995)
Ainda segundo PRESSMAN (1995), a análise e engenharia de sistemas
levam em conta que uma vez que o software sempre faz parte de um sistema mais
amplo, o trabalho inicia-se com o estabelecimento dos requisitos para todos os
elementos do sistema e prossegue com a atribuição de certo subconjunto desses
requisitos de software.
A análise de requisitos de software é o processo de coleta dos requisitos é
intensificado e concentrado especificamente no software.
O Projeto é um processo de múltiplos passos que se concentra em quatro
atributos distintos do programa: estrutura de dados, arquitetura de software, detalhes
procedimentais e caracterização da interface.
A codificação compreende a tradução numa forma legível para a máquina.
Os testes são iniciados assim que o código é gerado. O processo de
realização dos testes concentra-se nos aspectos lógicos internos do software,
garantindo que todas as instruções tenham sido testadas.
Na manutenção serão realizadas as mudanças depois que o projeto for
entregue ao cliente. Ocorrerão mudanças porque erros foram encontrados, porque o
software deve ser adaptado a fim de acomodar mudanças em seu ambiente externo
ou porque o cliente exige acréscimos funcionais ou de desempenho.
22
4.1.1.2. Prototipação
Segundo CUNHA (2007) Protótipo é a primeira versão desenvolvida do
software, a qual tem a finalidade de abordar a questão de interface com o usuário,
validar requisitos e apresentar a viabilidade do sistema. Durante a criação do
protótipo, clientes e desenvolvedores ficam em constante interação, facilitando
assim o levantamento de requisitos e funcionalidades do sistema. Alguns
desenvolvedores utilizam prototipações que são descartadas, ou seja, o
desenvolvimento do sistema somente será iniciado após o término do
desenvolvimento do protótipo. Esses métodos de prototipações geralmente elevam o
custo do sistema, pois são feitos dois projetos separados, um do protótipo e outro do
sistema final.
Conforme PRESSMAN (1995) como todas as abordagens ao
desenvolvimento de software, a prototipação inicia-se com a coleta dos requisitos.
Ocorre então a elaboração de um “projeto rápido” que consiste na representação
daqueles aspectos do software que serão visíveis ao usuário. O projeto rápido leva a
construção do protótipo que é avaliado pelo cliente/usuário e é usado para refinar os
requisitos para o software a ser desenvolvido. Idealmente, o protótipo serve como
um mecanismo para identificar os requisitos do software.
Ainda conforme CUNHA (2007) essa separação entre o desenvolvimento do
protótipo e do sistema final vem diminuindo a cada dia, com o uso da prototipação
evolutiva, a qual será o objeto de estudo deste artigo que terá como objetivo mostrar
as vantagens e desvantagens da utilização deste método no desenvolvimento de
sistemas de informação.
Ainda segundo PRESSMAN (1995), a prototipação é um processo que
capacita o desenvolvedor a criar um modelo de software que será implementado. O
modelo pode assumir uma das três formas:
(1) um protótipo em papel ou modelo baseado em PC que retrata a interação
homem-máquina de uma forma que capacita o usuário a entender quanta interação
ocorrerá;
(2) um protótipo de trabalho que implementa algum subconjunto da do
software desejado; ou
23
(3) um programa existente que executa parte ou toda a função, mas que tem
outras características que serão melhoradas em um novo esforço de
desenvolvimento.
A figura 3 mostra o paradigma de prototipação.
Figura 3 - O modelo de Prototipagem Fonte: PRESSMAN (1995)
4.1.1.3. Modelo Espiral
Segundo SOMMERVILLE (2003) o modelo espiral em vez de representar o
processo de software como uma sequência de atividades com algum retorno de
atividade para outra, o processo é representado como uma espiral. Cada loop na
espiral representa uma fase do processo de software. Assim, o loop mais interno
pode estar relacionado à viabilidade do sistema; o loop seguinte, à definição dos
requisitos do sistema; o próximo loop, ao projeto do sistema e assim por diante.
Para PRESSMAN (1995) o modelo espiral para a engenharia de software foi
desenvolvido para abranger as melhores características tanto do ciclo de vida
clássico como da prototipação, acrescentando, ao mesmo tempo, um novo elemento
– a análise de riscos – que falta a este esses paradigmas. O modelo que representa
a espiral define quatro importantes atividades representadas pelos quatros
quadrantes (figura 4):
Planejamento: determinação dos objetivos, alternativas e restrições.
Análise dos riscos: análise de alternativas e identificação/resolução dos
riscos.
Engenharia: desenvolvimento do produto no “nível seguinte”.
24
Avaliação feita pelo cliente: avaliação dos resultados da engenharia.
Um aspecto particular se torna claro quando consideramos a dimensão
radial descrita. A cada iteração ao redor da espiral (iniciando-se do centro), versões
progressivamente mais completas do software são construídas.
A figura 4 representa o ciclo de vida do modelo espiral.
Figura 4 - O modelo Espiral Fonte: PRESSMAN (1995)
4.1.2. Desenvolvimento Ágil
Consoante LARMAN (2007) métodos de desenvolvimento ágil usualmente
aplicam desenvolvimento iterativo e evolutivo num tempo limitado, empregam
planejamento adaptativo, promovem entrega incremental e incluem outros valores e
práticas que encorajam a agilidade – resposta rápida e flexível à modificação.
Segundo PRESSMAN (1995) a engenharia de software ágil combina uma
filosofia e um conjunto de diretrizes de desenvolvimento. A filosofia encoraja a
satisfação do cliente e a entrega incremental do software logo de início; equipes de
projeto pequenas, altamente motivadas, métodos informais; produtos de trabalho de
25
engenharia de software mínimos e simplicidade global do desenvolvimento. As
diretrizes de desenvolvimento enfatizam a entrega em contraposição à análise e ao
projeto (apesar dessas atividades não serem encorajadas) e a comunicação ativa e
contínua entre desenvolvedores e clientes.
4.1.2.1. SCRUM
Segundo CISNEIROS (2009) o SCRUM é um modelo de desenvolvimento
ágil de software que fornece métodos para se definir o planejamento, os principais
papéis de pessoas e a forma de trabalho do time. O nome SCRUM é derivado de
uma jogada de rúgbi, onde todo o mesmo time avança como apenas uma unidade,
trabalhando com os mesmos jogadores e em conjunto, passando sempre a bola pra
um e para outro.
Ao detalhar, o SCRUM tem três partes principais em seu modelo: Papéis
(Roles), Cerimônias (Cerimonies) e Artefatos (Artifacts). Cada um destes três pilares
contém outros sub-itens. Todas estas três partes principais são utilizadas no que
chamamos de ciclo de desenvolvimento, ou seja, o Sprint. Cada Sprint possui suas
fases e utiliza destes papéis, cerimônias e artefatos para alcançar seu objetivo final.
Conforme PRESSMAN (1995) o SCRUM é um modelo ágil de processo que
foi desenvolvido por Jeff Sutherland e por sua equipe no início da década de 90. Os
princípios do SCRUM são usados para guiar atividades de desenvolvimento dentro
de um processo que incorpora as seguintes atividades de arcabouço: requisitos,
análise, projeto, evolução e entrega, Em cada atividade de arcabouço, as tarefas de
trabalho ocorrem dentro de um padrão de processo chamado sprint. O trabalho
conduzido dentro de um sprint é adaptado ao problema em mãos e é definido, e
freqüentemente, modificado em tempo real pela equipe SCRUM.
Ainda conforme CISNEIROS (2009) a idéia do SCRUM é justamente definir
papéis bem específicos para as pessoas envolvidas no projeto e como cada pessoa
vai jogar, ou seja, o que cada uma vai ter que fazer para o time seguir em frente no
jogo: que no nosso caso é o próprio desenvolvimento do software.
Em geral e de forma reduzida, esta metodologia funciona da seguinte forma:
26
1. O produto é definido: quais são os seus requisitos? O que realmente o
cliente quer? O responsável por esta tarefa é o que chamamos de Proprietário do
Produto (Product Owner, em inglês).
2. O Proprietário do Produto define quais são as funcionalidades do
programa que mais importam, criando assim o que chamamos de Product Backlog.
3. Com as prioridades definidas, uma pessoa é definida para ser o
ScrumMaster, uma espécie de coordenador do projeto. O ScrumMaster, junto com o
Proprietário do Produto e o Time de desenvolvimento definem o que chamamos de
Sprints.
4. Cada Sprint possui uma parte de todo o Product Backlog, e devem ser
trabalhados de acordo com as prioridades definidas no Product Backlog. Os Sprints
devem ser preparados de uma forma de que durem de 2 a 4 semanas, e que no final
de cada período tenham um produto apresentável para o cliente.
5. Os Sprints vão sendo feitos até o Product Backlog acabar e o
Proprietário do Produto definir que o projeto está pronto. Mas isso não quer dizer
que novas funcionalidades não podem ser incluídas: basta ir adicionando no Product
Backlog e realizando outros Sprints.
Durante os passos reais de desenvolvimento, os Sprints, a principal
ferramenta de medição de desempenho é o Burndown Chart, que é uma das
características mais especiais do SCRUM e que o torna um grande diferencial, no
sentido positivo.
O fluxo global do processo é ilustrado na Figura 5.
Figura 5 - Ciclo de vida do Scrum Fonte: PRESSMAN (1995)
27
4.1.2.2. XP (Extreme Programming)
Para os autores KUHN e PAMPLONA (2009), XP é uma metodologia para
desenvolvimento de software ágil, com qualidade e que atenda as necessidades do
cliente. Alguns praticantes definem a XP como a prática e a perseguição da mais
clara simplicidade, aplicado ao desenvolvimento de software, voltada para projetos
cujos requisitos mudem com frequência, utilizem desenvolvimento orientado a
objetos, equipes de até 12 desenvolvedores e desenvolvimento incremental. A XP
Busca o máximo de valor a cada dia de trabalho da equipe para o seu cliente. Em
um curto espaço de tempo o cliente terá um produto utilizável, podendo aprender
com o mesmo e reavaliar se o que foi desenvolvido é realmente o desejado.
Ainda conforme KUHN e PAMPLONA (2009) Por ser uma metodologia
recente, a XP sofre mudanças em suas concepções e, portanto, é comum encontrar
variações. A adaptação ao ambiente de desenvolvimento deve ser levada em conta,
se um valor trouxer mais prejuízos do que benefícios é necessário reavaliar a
utilização desta metodologia.
A XP é organizada em torno de um conjunto de práticas e valores que atuam
perfeitamente para assegurar um alto retorno do investimento efetuado pelo cliente.
Os valores são: feedback, comunicação, simplicidade e coragem. As práticas são:
cliente sempre disponível, jogo de planejamento, stand up meeting (reunião rápida
pela manhã), programação em par, refactoring (melhorar o código), desenvolvimento
coletivo e guiado por testes, código coletivo, padrões para desenvolvimento, design
simples, metáfora, ritmo sustentável, integração contínua e releases curtos
(liberação de novas versões).
Segundo PRESSMAN (1995) o XP usa uma abordagem orientada a objetos
com seu paradigma de desenvolvimento padrão. O XP inclui um conjunto de regras
e práticas que ocorrem no contexto de quatro atividades de arcabouço:
planejamento, projeto, codificação e teste. A Figura 6 ilustra o processo XP e mostra
algumas das idéias chave e tarefas que estão associadas a cada atividade de
arcabouço.
28
Figura 6 - Ciclo de vida do Extreme Programming Fonte: PRESSMAN (1995)
4.1.3. Arquitetura de Software
Na visão de PRESSMAN (1995) em um nível mais simplista,
consideraremos a forma geral da estrutura física, mas na realidade, arquitetura é
muito mais. É a maneira pela qual os vários componentes do edifício são integrados
para formar um todo coeso. É o modo pelo qual o edifício se ajusta ao seu ambiente
e se mistura com os outros edifícios vizinhos. É o grau como que o edifício alcança
sua finalidade declarada e satisfaz às necessidades do seu proprietário.
Se tratando de Arquitetura de Software podemos dizer que a arquitetura não
é o software operacional. Ao contrário, é a representação que permite ao engenheiro
de software analisar a efetividade do projeto em satisfazer a seus requisitos
declarados, considerar alternativas arquiteturais em um estágio em que fazer
modificações do projeto é ainda relativamente fácil, e reduzir os riscos associados à
construção do software.
29
4.2. Linguagem de Programação
Segundo SEBESTA (2002) os computadores são usados em uma infinidade
de diferentes áreas, desde o controle de usinas elétricas à armazenagem de
registros de talões de cheques pessoais. Por causa dessa grande diversidade no
seu espaço, linguagens de programação com metas muito diferentes têm sido
desenvolvidas.
Para os autores VILLAS e VILLABOAS (1987) o computador é uma máquina
capaz de efetuar cálculos. Foi inventado porque era necessário realizar muitos
cálculos em pouco tempo, do contrário os resultados não seriam úteis.
4.2.1. JavaScript
Segundo PACIEVITCH (2011) Java é uma linguagem de programação
orientada a objetos que começou a ser criada em 1991, na Sun Microsystems. Teve
inicio com o Green Project, no qual os mentores foram Patrick Naughton, Mike
Sheridan, e James Gosling. Este projeto não tinha intenção de criar uma linguagem
de programação, mais sim de antecipar a “próxima onda” que aconteceria na área
da informática e programação.
Conforme SMITH e NEGRINO (2001) com a popularização do HTML no
âmbito de sites na internet foi também crescendo a necessidade de novas interfaces
nas aparências de sites na internet, com isso foi forçando o HTML a evoluir para ter
um melhor controle do design em sites, com toda essa evolução no ambiente web.
Foi percebendo que com as limitações do HTML que quase não tinha interação com
o usuário, com base nesse e outras necessidades que foi necessário criar uma
ferramenta que pode interagir com usuário, o Javascript. Os projetistas da empresa
Netscape criaram o Javascript com o objetivo de controlar o navegado e acrescentar
interesses e interatividade ás paginas da Web. O Javascript que pode ser usado
como já foi dito para aumentar a interatividade de paginas Web, mesmo tento o
mesmo nome de outra linguagem JAVA não tem nada de igual, o Javascript teve
propósito de diversificar os conteúdos de uma paginar da Web, diferente da
Linguagem Java que inicialmente foi desenvolvida para maquinas eletrônicas e com
outros objetivos.
30
Segundo HORSTMANN (2005) o Java além da sua própria linguagem
também possui uma rica biblioteca, que torna possível escrever programas portáteis
que podem ser executados em diversos sistemas operacionais mesmo que
proprietários. Sua biblioteca inclui pacotes para gráficos, projeto de interfaces com o
usuário, criptografia, redes, som, armazenamento de bancos de dados e muitos
outros propósitos.
4.2.2. PHP (Personal Home Page Tools)
Segundo JUNIOR (2001) o PHP foi elaborado por Rasmus Lerdorf no ano
de 1994 , o PHP na época chamado de Personal Home Page Tools (Ferramentas
para Home Pages Pessoais) utilizados na primeira versão para consultar o currículo
online. A linguagem fazia interpretação bem simples, que entendia alguns macros
especiais de alguns utilitários de uso comum nas homepages.
Em meados de 1995, o interpretado foi reescrito e batizado de PHP/FI
Version 2.0 O sufixo FI foi elabora por Ramus, que fazia interpretação dos dados de
formulários HTML, ele combinou os scripts das ferramentas para homepages e como
interpretador de formulários e adicionou o suporte ao MySQL, então estava criado O
PHP/FI. Já em 1996 já avia mais de 15.000 paginas Web utilizando a linguagem
PHP/FI, em 1997 já era mais de 50.000 paginas usando o PHP/IF. Nesta mesma
época o desenvolvimento PHP sofre outra mudança, com a avaliação do Rasmus e
com uma pequena ajuda de uma equipe mais organizada. O interpretador foi
reescrito do zero por Zeey Suraski e Andi Gutemns, esse novo interpretador foi a
base para o PHP Versão 3, e muitos outros códigos PHP e MySQL.
4.2.3. Delphi
Segundo o autor SWAN (1997), Delphi é uma linguagem de programação
modular e o módulo básico é denominado unidade. Para compilar um programa em
Delphi, é preciso um arquivo-fonte de programa e quaisquer unidades adicionais na
forma de fonte ou objeto.
31
O Delphi é utilizado para aplicativos rápidos, adequado para criação de
protótipos do Windows e aplicativos profissionais que competem em velocidade e
eficiência. Delphi inclui poderosos recursos orientados a objeto, sem tornar a
linguagem muito complicada, permite a criação de aplicações para sistemas
operacionais.
Conforme LISCHNER (2000), Delphi possui três variedades de diretivas de
compilador: chaves, parâmetro e compilação condicional. Uma chave é um flag
Booleano: Um recurso pode estar ativado ou desativado. Um parâmetro oferece
informações, como um nome de arquivo ou o tamanho da pilha. A compilação
condicional lhe permite definir condições e compilar seletivamente partes de um
arquivo-fonte dependendo das condições definidas. Um programa em Delphi é
semelhante a um programa do Pascal tradicional, no entanto, os programas em
Delphi são curtos, pois o trabalho real ocorre em uma ou mais unidades separadas.
4.3. Banco de Dados
Para os autores SILBERSCHATZ, KORTH e SUDARSHAN (2006) um
sistema de banco de dados é uma coleção de dados inter-relacionados e um
conjunto de programas que permitem o usuário acessar e modificar esses dados.
Uma importante finalidade de um sistema de banco de dados é fornecer aos
usuários uma visão abstrata dos dados, ou seja, o sistema oculta certos detalhes de
como os dados são armazenados e mantidos.
4.3.1. Oracle
Conforme visão de ABBEY, COREY e ABRAMSON (2000), Oracle é uma
ferramenta potente que além de fazer gerenciamento de informações também
possibilita integrações com outras ferramentas das empresas da mesma área.
Também existem aplicações de desenvolvimento para web e ferramentas para
desenvolver várias etapas na construção de sistemas. No Oracle há aplicativos
flexíveis de alto desempenho de fácil manutenção com quase nenhum trabalho.
32
Entre outros aplicativos destaca-se também um aplicativo usado na modelagem de
componentes de sistema, entre aplicativos de desenvolvimento de alta escala.
Conforme RAMALHO (1999) Oracle Server é um sistema de gerenciamento
de banco de dados relacional de um objeto constituído, além desse banco de dados,
de uma instância de servidor Oracle que possui uma estrutura física e lógica. Como
essas estruturas no servidor são separadas, o armazenamento dos dados pode ser
gerenciado sem afetar o acesso às estruturas lógicas de armazenamento.
Ainda segundo ABBEY, COREY e ABRAMSON (2000) o Oracle também
não deixa a desejar na questão de segurança e acessibilidade, o sofisticado
mecanismo de segurança da Oracle controla o acesso aos dados sigilosos através
do uso de uma variedade de privilégios e através de perfiz entre usuários e
administradores separando os dados proibidos dos sigilosos e dando autorização
somente aos usuários específicos. A Oracle também dispõe de muitas
funcionalidades relativas a acessibilidade o que ajuda a armazenar e manter os
dados, com o utilitário de backup e restauração, e como todos SGBD a Oracle
controla a integridade de dados.
Segundo PACIEVITCH (2000), Oracle é um sistema de banco de dados que
surgiu no final dos anos 70, criado por Larry Ellison. Visava desde o início ser um
banco de dados relacional, o que, na época ainda não havia sido feito por nenhuma
outra empresa de Bancos de Dados.
4.3.2. PostegreSQL
Mediante a documentação do PostgreSQL 8.0, traduzido por PACHECO
(2005), PostgreSQL é um sistema gerenciador de banco de dados objeto-relacional
(SGBDOR), baseado no POSTGRES Versão 4.2 desenvolvido pelo Departamento
de Ciência da Computação da Universidade da Califórnia em Berkeley. O
POSTGRES foi pioneiro em vários conceitos que somente se tornaram disponível
muito mais tarde em alguns sistemas de banco de dados comerciais.
O PostgreSQL é um descendente de código fonte aberto deste código
original de Berkeley. É suportada grande parte do padrão SQL:2003, além de serem
oferecidas muitas funcionalidades modernas, como:
33
• comandos complexos;
• chaves estrangeiras;
• gatilhos;
• visões;
• integridade transacional;
• controle de simultaneidade multiversão;
Além disso, o PostgreSQL pode ser estendido pelo usuário de muitas
maneiras como, por exemplo, adicionando novos;
• tipos de dado;
• funções;
• operadores;
• funções de agregação;
• métodos de índice;
• linguagens procedurais.
Devido à sua licença liberal, o PostgreSQL pode ser utilizado, modificado e
distribuído por qualquer pessoa para qualquer finalidade, seja privada, comercial ou
acadêmica, livre de encargos.
Segundo EISENTRAUT (2011), PostgreSQL é um sistema de bancos de
dados relacional poderoso e de código aberto. Ele possui mais de 15 anos de
desenvolvimento ativo e uma arquitetura que ganhou uma forte reputação e
confiabilidade e integridade dos dados.
4.3.3. MySQL
Segundo JUNIOR (2001) o MySQL é um servidor de banco de dados
multiusuário e multitarefa, que trabalha com uma das linguagens de manipulação de
dados mais populares do mundo, o SQL (Structured Query Language).
SQL (Structury Querry Language) é uma linguagem simples, em que você
facilmente pode gravar, alterar e recuperar informações num ambiente web com
segurança e rapidez. Ela foi desenvolvida pelo Departamento de Pesquisas da IBM
com forma de interface para o Sistema de Banco de Dados Relacionadis SYSTEM
34
R, no início dos anos 70; em 1996, a American National Institute (ANSI) publicou um
padrão SQL. A SQL estabeleceu-se como linguagem padrão de Banco de Dados
Relacional. A linguagem SQL tem como grande virtude a capacidade de gerenciar
índices sem a necessidade de controle individualizado no índice corrente, ago
bastante comum nos Sistemas Gerenciadores de Arquivos, como Dbase por
exemplo.
O MySQL foi originalmente desenvolvido pela empresa sueca TCX, que
necessitava de um servidor de banco de dados que operasse com grandes escalas
de dados rapidamente sem exibir caríssimas plataformas de hardware. A TCX opera
desde 1996 com 40 bancos de dados, contendo 10.000 tabelas, sendo 500 delas
com mais de 10 milhões de linhas.
Dentre as características que se destacam no MyQSL estão:
• Suporte a diferentes plataformas: Win32, Linux, FressBSB, Unix e etc;
• Suporte às API’s das de PHP, Perl, C, C++, Java, Pynthon e etc;
• Suporte a múltiplos processadores;
• Sofisticado sistema de criptografia flexível e seguro;
• Suporte a ODBC;
• Suporte de até 16 índices por tabela;
• Código fonte escrito em C e C++ e testado com uma variedade de
diferentes compiladores;
• O cliente conecta no MySQL através de conexão TCP/IP.
Para PACIEVITCH (2010), esse SGBD possui interface simples, e também a
capacidade de rodar em vários sistemas operacionais, o que são alguns dos motivos
para este programa ser tão usado atualmente.
4.4. RUP (Rational Unified Process)
Segundo KRUCHTEN (2003), o Rational Unified Process é um processo de
engenharia de software que fornece uma abordagem para assumir
responsabilidades dentro da organização. O RUP na sua concepção, tem objetivo de
assegura dentro da construção do software a entrega do projeto nas conformidades
35
que o cliente estabeleceu, na medida em que o software seja entregue na alta
qualidade satisfazendo dentro dos requisitos as necessidades do cliente.
O processo RUP é um processo é um produtor de processo. É desenvolvido
e mantido pela Rational Software e integrado com seus conjuntos de ferramentas de
desenvolvedores de software.
O Rational Unified Process é um método que pode adaptar a estruturas da
organização que esteja usando. O Rational Unified Unified Process captura muitas
da melhores práticas no desenvolvimento de software de forma satisfatória para uma
grande faixa de projeto e organizações.
Conforme Hermano (2003), o RUP é um conjunto de métodos e práticas de
desenvolvimento, ele define o que fazer e quando fazer. Ainda segundo ele as
atividades do RUP são bem definidas, possuindo ordem de execução com descrição
de como essas ordens devem ser realizadas. Diz ainda que o RUP é uma
abordagem da orientação a objeto e utiliza a notação UML (Unified Modeling
Language).
A figura 7 mostra as fases e os processos do RUP, mostra também que suas
etapas estão divididas em quatro fases: concepção, elaboração, construção e
transição.
Figura 7 - Arquitetura Geral do RUP (Gráfico de Baleia) Fonte: RUP (2009)
36
4.4.1.1. A Fase de Iniciação (ou Concepção)
Segundo Martins (2004), os envolvidos devem chegar a um acordo em
relação à visão do sistema e estimativas das fases do projeto.
Conforme KRUCHTEN (2003) a principal meta da fase de concepção é
alcançar o consentimento de todos os interessados nos objetivos do ciclo de vida
para o projeto. Os objetivos primários da fase de iniciação incluem: estabelecer a
extensão de software do projeto e limitar condições; discriminar os dados de uso
críticos do sistema; exibir, e talvez demonstrar, pelo menos uma arquitetura
candidata contra alguns dos cenários primários; estimar o custo global e programar
o programar o projeto inteiro; e estimar os riscos.
Segundo PRESSMAN (1995) esta fase abrange atividades de comunicação
com o cliente e de planejamento. Em colaboração com o cliente e os usuários finais,
os requisitos de negócio para o software são identificados, um rascunho da
arquitetura do sistema é proposto e um plano para a natureza iterativa e incremental
do projeto que vai ser seguido é desenvolvido.
4.4.1.2. A Fase de Elaboração
Para SANT’ANA (2010), esta fase tem por objetivo analisar de forma mais
detalhada os planos do projeto, revisar e resolver todos os riscos do projeto e assim
assegurar que a arquitetura escolhida suportará todos os requisitos estabelecidos.
Todas as indagações deverão ser esclarecidas e também deverá ser desenvolvida e
avaliada a estabilidade da arquitetura do projeto, isso através de um ou mais
protótipo de arquitetura.
Segundo KRUCHTEN (2003) o propósito da fase de elaboração é analisar o
domínio de problema, estabelecer uma fundação arquitetônica sadia, desenvolver o
plano de projeto e eliminar os elementos de alto risco do projeto. Nesta fase um
protótipo executável de arquitetura é construído em uma ou mais iterações,
dependendo da extensão, tamanho, risco e novidade do projeto. No mínimo, este
esforço deveria endereçar os casos de uso críticos identificados na fase de
concepção, que tipicamente expõe os riscos técnicos principais do projeto. Os
principais objetivos desta fase compreendem: definir, validar e delinear a arquitetura
37
tão rápido quanto possível de ser realizada; delinear a visão; delinear um plano de
alta-fidelidade para a fase de construção; e demonstrar que a arquitetura de linha de
base suportará esta visão, a um custo razoável e num tempo razoável.
4.4.1.3. Construção
Segundo KRUCHTEN (2003) durante a fase de construção, todos os
componentes restantes e características de aplicação são desenvolvidos e
integrados ao produto, e todas as características são completamente testadas. A
fase de construção é, de certo modo, um processo industrial no qual é colocada
ênfase em gerenciar recursos e controlar operações para aperfeiçoar custos, prazos
e qualidade. De certo modo, o quebra-cabeça do gerenciamento sofre uma transição
do desenvolvimento de propriedade intelectual durante a concepção e a elaboração
para o desenvolvimento de produtos para distribuição durante a construção e
transição. Os principais objetivos desta fase consistem em: minimizar custos de
desenvolvimento, aperfeiçoando recursos e evitando fragmentar e refazer
desnecessário; alcançar a qualidade adequada tão rápida quanto possível de ser
realizada; e alcançar versões úteis tão rápido quanto possível de ser realizada.
Conforme SANT’ANA (2010), esta fase é a de conclusão do
desenvolvimento, onde a meta é analisar todos os requisitos que ainda restam. Dá
uma ênfase maior no gerenciamento de componentes e no controle de operações
para que se obtenha qualidade, otimização dos lucros e programações, é também
nesta fase que ocorre a construção do código-fonte.
4.4.1.4. A Fase de Transição
Segundo KRUCHTEN (2003) o propósito desta fase é levar o produto de
software à comunidade de usuários. Depois do produto ser entregue ao usuário final,
normalmente surgem questões que exigem que se desenvolva novos lançamentos,
corrija alguns problemas e as características finais que foram adiadas.
38
Entra-se nesta fase quando uma linha base é madura suficiente para ser
distribuída no domínio de usuários finais. Isso significa que algum subconjunto
utilizável do sistema foi completado a um nível aceitável de qualidade e aquela
documentação de usuário está disponível, de forma que a transição para o usuário
fornecerá resultados positivos para todas as partes.
Esta fase inclui: teste beta para validar o sistema novo contra expectativas
do usuário; operação paralela com o sistema de legado que o projeto está
substituindo; conversão de banco de dados operacionais; treinamento de usuários e
mantenedores; e saída do produto para o marketing, distribuição e equipes de
vendas.
Os objetivos primários desta fase incluem: alcançar auto-suporte do usuário;
alcançar consentimento do interessado nas linhas de base do desenvolvimento que
estão completas e consistentes com os critérios de avaliação da visão; e alcançar a
linha de base do produto final tão rapidamente e como custo efeito.
Para SANT’ANA (2010), esta é a fase onde se deve tornar disponível o
sistema para o usuário final, nesta fase também inclui atividades de treinamentos
para os usuários para que eles possam compreender o sistema, realizações de teste
das versões disponíveis , visando sempre garantir qualidade adequada ao software.
4.5. MVC (Model View Controller)
Segundo VALENTE (2011), o MVC (Model View Controller) surgiu em 1979
com o Smalltalk, se popularizou apenas na década de 90, quando surgiram os
padrões de camada. O foco principal do MVC é fazer a separação nas camadas de
desenvolvimento, fazendo assim com que os problemas e ajustes sejam resolvidos
com uma facilidade maior. Seria o mesmo que dividir as responsabilidades na
aplicação e a característica do MVC é que ele aumenta a flexibilidade e reutiliza o
código-fonte.
Segundo MARTINS (2009), o MVC (Model View Controller) foi desenvolvido
utilizando o Smalltalk, nele os componentes são regidos por três objetos: modelo,
visão e controle. O modelo gerencia o comportamento, fornece informações sobre o
seu estado. A visão gerencia a saída gráfica, ela especifica como os dados do
39
modelo são mostrados aos usuários. O controle interpreta as entradas do usuário,
ele comanda o modelo e a visão para que sejam alterados adequadamente, isso
ocorre de acordo com as ações do usuário.
Conforme LACKEY a programação em MVC separa sua aplicação em três
partes principais:
1. O model representa os dados;
2. A view representa a visualização dos dados;
3. O controller manipula e roteia as requisições dos usuários.
Usar o modelo MVC torna fácil a manutenção da sua aplicação, com pacotes
modulares de rápido desenvolvimento. Elaborar tarefas divididas entre models,
views e controllers faz com que sua aplicação fique leve e independente. Novas
funcionalidades são facilmente adicionadas e pode-se dar nova cara nas
características antigas num piscar de olhos. O design modular e separado também
permite aos desenvolvedores e designers trabalharem simultaneamente, incluindo a
habilidade de se construir um rápido protótipo. A separação também permite que os
desenvolvedores alterem uma parte da aplicação sem afetar outras.
Figura 8 - Requisição básica de um MVC Fonte: Manual do CakePHP (2011)
4.6. UML (Unified Model Language)
Segundo MELO (2004) não se pode falar de UML sem falar de orientação a
objetos. Desde os primeiros conceitos da orientação a objetos, diversos métodos
40
foram apresentados à comunidade (cerca de 50 no período de 1989 e 1994), onde
grande parte tendia aos métodos estruturados. Com o passar do tempo cada
método ganhava uma fatia do mercado, tentativas de padronização foram propostas,
mas não obtiveram resultado. Por volta de 1993, os métodos que mais cresciam no
mercado eram: Booch’93, OMT-2 e OOSE (Object-oriented software engineering).
Todavia, apesar das semelhanças, existiam pontos significativos e fortes em cada
método.
Conforme GUEDES (2005), a UML é uma linguagem visual utilizada para
modelar softwares baseados no paradigma da orientação a objetos. É uma
linguagem de modelagem de propósito geral que pode ser aplicada a todos os
domínios de aplicação. A UML não é uma linguagem de programação, e sim uma
linguagem de modelagem, uma notação, cujo objetivo é auxiliar os engenheiros de
software a definirem as características do sistema.
Ainda segundo MELO (2004) resumidamente, o OOSE possuía seu foco em
casos de uso (use cases), provendo excelente suporte à engenharia de negócios e
análise de requisitos. OMT-2 era expressivo na fase de análise dos sistemas de
informação. Booch’93 já se destacava na fase de projeto. Ao invés de seguir a linha
dos primeiros autores (que procuravam redefinir ou entender os métodos já
existente), Booch, Rumbaugh e Jacobson decidiram unir forças e criar um método
único. Estes esforços deram início em 1994 quando James Rumbaugh deixou a
General Eletric e se juntou à Grady Booch na Rational Software, no intuito de unir
seus métodos (Booch e OMT). Em 1995 eles lançaram publicamente o rascunho de
seu Método Unificado na versão 0.8. Nesta época, Jacobson se juntou à equipe e o
projeto inicial passou a incorporar métodos OOSE. Em 1996, os três autores,
lançaram uma nova versão, o Método Unificado passou a se chamar UML – Unified
Modeling Language.
4.6.1. Diagrama de Caso de Uso
Conforme MATOS (2002), casos de uso (do inglês Use Case) são utilizados
para identificar as regras do negócio e são uma excelente forma de entender o ponto
de vista do usuário simplesmente pelo fato de que modela o que ele precisa
41
executar. Internamente, um caso de uso é uma sequência de ações que permeiam a
execução completa de um comportamento esperado para o sistema.
Um caso de uso é apenas uma representação de uma função, manipulada
por uma entidade do sistema, conhecida como ator.
Consoante LARMAN (2004) um diagrama de caso de uso é uma excelente
imagem do contexto do sistema; ele é um bom diagrama de contexto, ou seja,
mostra a fronteira de um sistema, o que está fora dele e como o sistema é usado.
Serve como uma ferramenta de comunicação que resume o comportamento do
sistema e seus atores.
A figura 9 representa um diagrama de caso de uso, conforme os padrões da
UML.
Figura 9 - Diagrama de caso de uso Fonte: MATOS (2002)
4.6.2. Diagrama de Classes
Segundo BOOCH, RUMBAUNGH e JACOBSON (2005) um diagrama de
classes é um diagrama que mostra um conjunto de classes, interfaces e
colaborações e seus relacionamentos. Graficamente, um diagrama de classes é
uma coleção de vértices e arcos. Um diagrama de classes é apenas um tipo
especial de diagrama e compartilha as mesmas propriedades de todos os outros
diagramas. Conforme MATOS (2002) uma classe é uma abstração de um conjunto
de coisas que possuem características e operações em comum. Ou seja, classe é
um conjunto de objetos.
Na figura 10 uma representação de um diagrama de classe.
42
Figura 10 - Diagrama de Classes Fonte: MATOS (2002)
4.6.3. Diagrama de Interação
Segundo BOOCH, RUMBAUNGH e JACOBSON (2005), o diagrama de
interação é utilizado para fazer a modelagem dos aspectos dinâmicos do sistema.
Na maior parte, isso envolve a modelagem de instâncias concretas ou prototípicas
de classes, interfaces, componentes e nós, juntamente com as mensagens que são
trocadas entre eles, tudo isso no contexto de um cenário que ilustra um
comportamento.
Diagramas de interações podem aparecer sozinhos para visualizar,
especificar, construir e documentar a dinâmica de uma determinada sociedade de
objetos ou podem ser utilizados para refazer a modelagem de um determinado fluxo
de controle de um caso de uso.
Conforme MATOS (2002), objetos são entidades dinâmicas, ou seja, não é
possível imaginá-las como depósito de dados, mas como um ponto de referência no
processo de execução das tarefas.
Neste sentido, é necessária uma forma de modelar como esse
comportamento dinâmico é conduzido.
Programas orientados a objetos são, na verdade, constantes trocas de
mensagens. Em conjunto, essas mensagens colaboram na consecução de um
determinado propósito. Os diagramas de interação são, portanto, a representação
do comportamento dinâmico que uma sociedade de objetos necessita ter para que a
execução de alguma tarefa seja executada.
Na figura 11 um exemplo de um diagrama de interação.
43
Figura 11 - Diagrama de Interação Fonte: MATOS (2002)
4.6.4. Diagrama de Colaboração
Segundo MATOS (2002) o diagrama de colaboração fixa a atenção em
como os objetos estão se organizando para efetuar uma tarefa.
Consoante BOOCH, RUMBAUNGH e JACOBSON (2005) no contexto da
arquitetura de um sistema, uma colaboração permite nomear um agrupamento
conceitual que abrange aspectos estáticos e dinâmicos. Uma colaboração nomeia
uma sociedade de classes, interfaces e outros elementos que trabalham em
conjunto para fornecer algum comportamento cooperativo maior do que a soma de
todas as partes.
4.6.5. Diagrama de Estados e Atividades
Segundo MATOS (2002), estados e atividades se complementam e, do
ponto de vista semântico, às vezes, podem confundir. No entanto, ambos têm um
ponto de partida bem definido: ambas são máquina de estado.
Máquinas de estado são amplamente utilizadas na computação teórica,
desde a inteligência artificial até sistemas digitais.
44
Qualquer máquina de estados pretende avaliar os aspectos dinâmicos de
uma construção e sempre são identificados os seguintes elementos: estados,
entradas, saídas, transições, um estado inicial e um final.
O importante é saber que o diagrama de estados possui um enfoque distinto
do diagrama de atividades.
Diagramas de estado preocupam-se em avaliar o comportamento das
instâncias, ou seja, são avaliadas as possíveis sequências de ações por meio das
quais as instâncias procedem em reação aos eventos que lhe são apresentados
durante a vida. Por outro lado, diagramas de atividades são uma extensão à idéia
original das máquinas de estado, avaliando melhor as condições pelas quais as
instâncias chegam a determinadas decisões.
4.6.5.1. Desenho de um Diagrama de Estados
Segundo BOOCH, RUMBAUNGH e JACOBSON (2005), um diagrama de
estados mostra uma máquina de estados, dando ênfase ao fluxo de controle de um
estado para outro.
Conforme a visão de MATOS (2002) o ponto de partida para desenhar um
diagrama de estado é avaliar os atributos da instância em questão. Muitos atributos
possuem um domínio de valores que permite o acompanhamento de possíveis
transições que um objeto da classe poderia ter.
Na figura 12 é apresentando um diagrama de estados.
Figura 12 - Diagrama de Estados Fonte: MATOS (2002)
45
4.6.5.2. Desenho de um Diagrama de Atividades
Conforme MATOS (2002), do ponto de vista de representação de aspectos
dinâmicos do sistema, dois diagramas possuem características muito comuns: o
diagrama de atividades e o diagrama de estados, porém o diagrama de atividades
trata-se de algo que está em execução, portanto não finalizado Quando uma
atividade termina, alguma ação ocorre.
Na figura 13 é ilustrado uma representação de um diagrama de atividades.
Figura 13 - Diagrama de Atividades Fonte: MATOS (2002)
5. Proposta do Novo Sistema
46
Criar um sistema informatizado de ambiente WEB que trabalhará com os
conceitos de internet, intranet e extranet para dividir os níveis de acesso destinados
a cada tipo de ator do sistema.
A intranet terá a maior parte do sistema e todos os processos deverão ser
feitos a partir da identificação do usuário, ou seja, mediante login e senha. O acesso
será local e terá como limite o espaço físico da instituição.
Na extranet serão disponibilizadas funcionalidades onde os usuários não
precisem estar na instituição, o que não retira a necessidade de estar logado no
sistema. Um exemplo para a finalidade do uso na extranet seria a necessidade de se
compor diário de classe (presença/nota) por parte do docente
Na internet de maneira geral será disponibilizado apenas funcionalidades de
consulta e solicitações, na maior parte realizadas pelo Aluno.
Após análise e levantamento de requisitos se propõe os módulos descritos a
seguir com suas respectivas funcionalidades:
O módulo financeiro será responsável pelo controle de pagamentos
efetuados pelos alunos e pela a gestão de boletos gerados/liquidados.
O módulo Aluno/Professor terá a incumbência de manter todo o cadastro de
alunos e professores, controlar todo o cadastramento de documentos utilizados pela
instituição além de observações referente aos alunos, cabe ainda, dispor alguns
serviços como o de carteirinha estudantil, tudo isso, mantendo um histórico de
alterações executadas, visando maior controle e segurança para a instituição.
O módulo Ano Letivo propõe manter todo o cadastro do Ano Letivo
(semestral) além da matrícula do aluno e seu histórico escolar, será responsável por
receber a pauta, manter o diário de classe e controlar a criação de novas turmas na
instituição.
Para manter os cursos da IES, criou-se o módulo Curso/Disciplina, que além
desta funcionalidade terá de manter os Planos de ensino proposto para as
Disciplinas, de manter a grade do curso e de fazer o relacionamento entre os
Professores e as Disciplinas.
Com o objetivo atender as necessidades dos usuários do sistema, foi criado
o módulo Usuário, responsável por manter os Usuários e determinar seus perfis
dentro do sistema, com o delegar a atividade dos mesmos dentro do sistema através
de histórico de utilização e alteração do sistema.
47
A biblioteca também será receberá um módulo, capaz de gerar boletos
referentes a multas por atrasos além de fazer todo o controle do acervo e
empréstimos.
Vários outros módulos também foram levantados num primeiro momento,
porém suas funcionalidades ainda não foram exprimidas, sendo eles:
Módulo Locação de Material;
Módulo Ouvidoria;
Módulo Vestibular;
Módulo Patrimônio;
Módulo Demandas;
Módulo Recursos Humanos.
5.1. Descrição do Sistema Proposto
Criar um sistema disponível através da WEB, que trabalhará em três frentes
distintas: internet, intranet e extranet com o objetivo de separar o acesso entre os
atores do sistema.
A tabela 2 reflete as principais diferenças entre as tecnologias que serão
utilizadas.
Tabela 2 - Comparativo entre tecnologias
INTERNET INTRANET EXTRANET
Acesso Restrito
Comunicação Instantânea
Comunicação Externa
Compartilhamento de Impressoras
Compartilhamento de Dados
Rede Local (LAN)
5.2. Resultados Esperados
48
O sistema inicialmente terá um foco no cliente/aluno e com a utilização do
sistema proposto se espera dar maior comodidade aos clientes/alunos bem como
reduzir o fluxo de trabalho na central de atendimento da faculdade ABC.
5.3. Restrições do Sistema Proposto
O sistema estará disponível na internet para os alunos e na intranet para o
gerente financeiro bem como funcionários do departamento financeiro, os quais
deverão estar devidamente autenticados com senhas de acesso para fazer qualquer
tipo de transação utilizando o sistema.
5.4. Áreas Afetadas Pelo Novo Sistema
O novo sistema impactará em toda a empresa, em alguns setores de forma
mais direta.
Os alunos serão largamente beneficiados pela facilidade de uso e pela
possibilidade do acesso aos dados financeiros através da internet.
O departamento financeiro terá toda a rotina e fluxo de trabalho revisto para
a implantação do novo sistema.
A biblioteca será indiretamente afetada e fará uso da nova ferramenta do
módulo financeiro para gerar boletos de cobrança no caso de atraso na devolução
de livros, e por isso será beneficiada, onde até o momento não há controle
automatizado para as cobranças, sendo tudo feito de forma manual.
5.5. Banco de Dados
O banco escolhido foi o MySQL pois apresenta um bom desempenho para
aplicações de pequeno e médio porte, suporte a variadas linguagens de
programação como o PHP, Perl, C, C++, Java e Pynthom, suporte a diferentes
plataformas como Win32, Linux e Unix..
49
Por ser uma ferramenta gratuita o MySQL, se tornou largamente usado no
cenário atual possibilitando a formação de grandes referências sobre este banco de
dados, além da formação de incontáveis profissionais capacitados a desenvolver
sistemas utilizando este banco de dados.
6. Documentação de Análise
50
Nesta seção serão descritos os atores do sistema, mostrando o papel de
cada um dentro do mesmo. Também será exibida uma lista dos casos de uso que
serão implementados no sistema, assim como um diagrama contendo esses casos
de uso, e por fim as suas especificações, sendo todos estes artefatos integrantes do
módulo financeiro do SISEDU.
6.1. Visão Macro dos Atores
Ator 01: Aluno – Manter Aluno; Gerar declaração de IR (Imposto de Renda)
Ator 02: Funcionário – Manter Boleto; Gerar Boleto
Ator 03: Administrador – Manter Funcionário; Gerar Relatório
6.2. Identificação dos Atores
De acordo com o levantamento para o novo sistema, em específico o
módulo financeiro, dois tipos de atores são identificados.
São eles: Aluno, Funcionário e Administrador.
O Aluno tem acesso a dados financeiros em sua página pessoal, tendo
controle dos boletos de mensalidades/serviços e também gerar declaração de
Imposto de Renda.
O Funcionário gerencia os boletos de alunos que são gerados a partir do
contrato de matrícula gerados no módulo Ano Letivo, bem como os débitos gerados
a partir de outros módulos como a Biblioteca. O funcionário terá a opção de gerar,
visualizar e de excluir boletos gerados, as funções de editar boleto bancário não
estará disponível.
O administrador mantém os funcionários e gera relatórios de controle de
boleto.
6.3. Listas de Casos de Uso
51
Na tabela 3 estão listados os casos de uso do módulo financeiro do sistema
SISEDU.
Tabela 3 - Lista de diagramas de caso de uso
UC01 Manter Boleto
UC 02 Gerar Boleto
UC03 Calcular Débitos
UC04 Negociar Dívida
UC05 Solicitar Informe de Despesas (IR)
UC06 Gerar Relatório
6.4. Diagrama de Caso de Uso
A figura 14 é a representação do diagrama de caso de uso do módulo
Financeiro do sistema SISEDU.
Figura 14 - Diagrama de caso de uso (SISEDU-Financeiro)
6.5. Descrição Detalhada dos Casos de Uso
A tabela 4 refere-se à descrição detalhada do caso de uso Manter Boleto.
52
Tabela 4 - Manter Boleto
Nome UC01 – Manter Boleto
Objetivo Cadastra dados do boleto bancário
Atores Funcionário
Dados Consumidos Dados do Boleto
Dados Produzidos Regras do Boleto
Prioridade Alta
Pré-condições N/A
Pós-condições N/A
Fluxo Principal
Cadastrar Regras do Boleto
Ator Sistema
Acessar o botão cadastro de boleto Abrir formulário de cadastro de boleto
Inserir os dados Agência e Conta Receber os dados inseridos e validá-los.
Solicita confirmação de inclusão.
Confirma e clica no botão enviar Armazena-os na tabela Boleto
Exibe mensagem de operação realizada com
sucesso
Receber mensagem
Fluxo Alternativo 1
Alterar Boleto
Ator Sistema
Acessar o botão listar no menu Boleto Exibir lista de boletos cadastrados
Clicar no botão alterar ao lado do boleto que
deseja realizar a alteração
Exibir dados do boleto escolhido
Realizar a alteração desejada Receber novos dados.
Solicita confirmação de alteração.
Confirma e clica no botão enviar Gera um novo boleto.
Exibir mensagem de operação realizada com
sucesso.
Receber mensagem
Fluxo Alternativo 2
Excluir Boleto
53
Ator Sistema
Acessar o botão listar no menu Boleto Exibir lista de Boletos cadastrados.
Clicar no botão excluir ao lado do boleto que
deseja realizar a exclusão
Exibir dados do boleto escolhido
Solicita confirmação de exclusão.
Confirma e clica no botão enviar Excluir os dados do funcionário selecionado.
funcionário
Receber mensagem
A tabela 5 refere-se à descrição detalhada do caso de uso Gerar Boleto.
Tabela 5 - Gerar Boleto
Nome UC02 – Gerar Boleto
Objetivo Gerar boleto bancário
Atores Funcionário
Dados Consumidos Dados do Boleto
Dados Produzidos Regras do Boleto
Prioridade Alta
Pré-condições N/A
Pós-condições N/A
Fluxo Principal
Gerar do Boleto
Ator Sistema
Acessar o botão gerar boleto Abrir Box com turmas para gerar os boletos
Confirmar geração de boletos Receber os dados inseridos e valida-os.
Gera os boletos
Fluxo Alternativo 1
Excluir Boleto
Ator Sistema
Acessar o botão excluir Boleto Exibir busca de alunos
Selecionar boleto desejado Marcar boleto como selecionado dados do boleto
escolhido
Acessar botão excluir boleto Pergunta se deseja realmente excluir
Confirma exclusão Inabilita a visibilidade deste boleto, mas o mantém.
na base de dados para futuras consultas.
54
6.6. Diagrama de Classes
A Figura 15 refere-se ao diagrama de classes do SISEDU-Financeiro, são
apresentadas todas as classes que compõem o sistema e seus relacionamentos.
Figura 15 - Diagrama de classe (SISEDU-Financeiro)
55
6.7. Modelo de Entidade e Relacionamento
Figura 16 - Modelo de Entidade e Relacionamento (SISEDU)
56
6.8. Especificação das Tabelas
As tabelas apresentadas abaixo descrevem os campos do MER do Modulo
Ano Letivo do Sistema SISEDU desenvolvido para Faculdade ABC.
A tabela 6 é utilizada para armazenar os dados cadastrais de um novo
cadastro de período letivos
Tabela 6 - PERIODOS
Campo Tipo Nulo PK FK
CD_ANO_LTV year(4) Não sim
CD_SEM char(1) Não
NR_CUR int(11) Sim
TX_OBS char(100) Não
NR_SEM char(2) Sim
A tabela 7 é utilizada para armazenar as matrículas dos alunos
Tabela 7 - MATRICULA
Campo Tipo de Dados Nulo PK FK
CD_MTR int(11) Não SIM
PESSOAS_NR_CPF_PESSOA char(11) Não SIM
CURSO_NR_CUR int(11) Não SIM
CD_TIP_MTR char(1) Sim
DT_MTR Date Sim
DT_INI_MTR Date Sim
NR_SEM char(2) Sim
DT_FIN_MTR Date Sim
CD_STT_MTR char(1) Sim
A tabela 8 é utilizada para armazenar as turmas em que os alunos serão
matriculados.
Tabela 8 - TURMAS
Campo Tipo Nulo PK FK
CURSO_NR_CUR int(11) Não sim
PERIODOS_CD_ANO_LTV year(4) Não sim
CD_TURMA int(11) Não sim
TX_DESC char(80) Sim
PERIODOS_CD_ANO_LTV1 year(4) Não
57
A tabela é 9 utilizada para armazenar a relação entre os alunos e as turmas.
Tabela 9 - ENTURMACAO
Campo Tipo Nulo PK FK
CD_ENT int(11) Não SIM
CD_DSC int(11) Não SIM
TURMAS_CURSO_NR_CUR int(11) Não SIM
TURMAS_PERIODOS_CD_ANO_LTV year(4) Não SIM
TURMAS_CD_TURMA int(11) Não SIM
TX_NOM_DSC varchar(45) Sim
CD_STT char(1) Não
DT_ENT date Não
DT_ULT_ALT date Sim
CD_MTR_ALN_01 int(11) Sim
Mais 59 campos iguais ...
A tabela 10 é utilizada para armazenar o relacionamento entre disciplina e
matrícula.
Tabela 10 - DISCIPLINA_MATRICULA
Campo Tipo Nulo PK FK
MATRICULA_CD_MTR int(11) Não SIM
MATRICULA_PESSOAS_NR_CPF_PESSOA char(11) Não SIM
CD_DSC_01 int(11) Sim
QT_CRG_HOR_01 int(11) Sim
NR_SEM_01 char(2) Sim
CD_DSC em mais 10 campos...
QT_CRG_HOR em mais 10 campos...
NR_SEM em mais 10 campos...
A tabela 11 é utilizada para armazenar os dados do banco (instituição
financeira).
Tabela 11 - BANCO
Campo Tipo Nulo PK FK
CD_BB char(3) Não SIM
TX_BB varchar(45) Sim
A tabela 12 é utilizada para armazenar os dados do boleto.
Tabela 12 - BOLETO
Campo Tipo Nulo PK FK
NR_SEQ_BOL int(11) Não SIM
58
TIPO_BOLETOS_CD_TIP_BOL int(11) Não SIM
Campo Tipo Nulo PK FK
MATRICULA_CD_MTR int(11) Não SIM
MATRICULA_PESSOAS_NR_CPF_PESSOA char(11) Não SIM
MATRICULA_CURSO_NR_CUR int(11) Não SIM
DT_VCT date Sim
NSS_NR int(11) Sim
NR_DOC varchar(50) Sim
CD_SIT_PG tinyint(1) Sim
DT_PG date Sim
DT_GRC_BOL date Sim
VL_MNS float Sim
VL_DSC float Sim
VL_PG float Sim
A tabela 13 é utilizada para armazenar os dados do curso.
Tabela 13 - CURSO
Campo Tipo Nulo PK FK
NR_CUR int(11) Não SIM
TX_NOM varchar(45) Não
CD_COO_CUR int(11) Não
TX_SGL char(3) Sim
CD_CUR char(1) Sim
CD_TRN char(1) Sim
QT_HOR_EST int(11) Sim
QT_CRG_HOR int(11) Sim
VL_MNS float Sim
CD_STT char(1) Sim
DT_REG_MEC date Sim
NR_REG_MEC char(20) Sim
QT_SEM char(2) Sim
A tabela 14 é utilizada para armazenar os dados da disciplina.
Tabela 14 - DISCIPLINA
Campo Tipo Nulo PK FK
CURSO_NR_CUR int(11) Não SIM
CD_DSC int(11) Não SIM
TX_NOM varchar(45) Não
TX_SGL char(3) Sim
TX_DESC char(150) Sim
QT_CRG_HOR int(11) Sim
59
VL_DSC float Sim
Campo Tipo Nulo PK FK
TX_END_ARQ char(60) Sim
DT_ULT_ALT date Sim
A tabela 15 é utilizada para armazenar dados de documentos que poderão
ser solicitados na central de atendimento.
Tabela 15 - DOCUMENTOS
Campo Tipo Nulo PK FK
TIP_DOC_CD_TIP_DOC char(2) Não SIM
PESSOA_NR_CPF_PESSOA char(11) Não SIM
TX_OBS char(200) Sim
TX_END_DOC char(150) Sim
TP_EXT_DOC char(5) Sim
A tabela 16 é utilizada para armazenar a grade curricular do curso.
Tabela 16 - GRADE_CURRICULAR
Campo Tipo Nulo PK FK
CURSO_NR_CUR int(11) Não SIM
NM_GRA_HOR char(5) Não SIM
NR_SEM char(2) Não
CD_TRN char(1) Não
CD_STT char(1) Não
DT_INI_GRA date Não
DT_FIN_GRA date Sim
A tabela 17 é utilizada para armazenar os dados de pessoa (aluno,
professor, funcionário).
Tabela 17 - HST_PESSOA
Campo Tipo Nulo PK
NR_CPF_PESSOA char(11) Não SIM
DT_ULT_ATL timestamp Não SIM
TP_PESSOA char(2) Sim
TX_NOM char(60) Não
TX_NOM_PAI char(60) Sim
TX_NOM_MAE char(60) Não
DT_NSC date Não
CD_SEX char(1) Não
TX_EML char(60) Sim
NR_DDD_TEL_RES decimal(3,0) Sim
NR_TEL_RES decimal(9,0) Sim
60
NR_DDD_TEL_CEL decimal(3,0) Sim
Campo Tipo Nulo PK
NR_TEL_CEL decimal(9,0) Sim
NR_DDD_TEL_SRV decimal(3,0) Sim
NR_TEL_SRV decimal(9,0) Sim
TX_END_TIP decimal(2,0) Sim
TX_END_NOME char(40) Sim
TX_END_CPL char(15) Sim
TX_END_BRO char(30) Sim
TX_END_CDD char(45) Sim
TX_END_UF char(2) Sim
TX_END_CEP decimal(8,0) Sim
CD_STT char(1) Sim
TX_GRD_ESC char(2) Sim
NR_CPF_USU_ALT decimal(11,0) Não
A tabela 18 é utilizada para armazenar os dados de usuário, associado a
tabela pessoa.
Tabela 18 - HST_USUARIO
Campo Tipo Nulo PK FK
NR_CPF_PESSOA char(11) Não SIM
DT_ULT_ALT timestamp Não SIM
CD_PER int(11) Sim
TX_SNH char(8) Não
DT_INI date Não
DT_ATL_USU date Não
A tabela 19 é utilizada para armazenar os dados de alunos que queiram faze
a inscrição no vestibular
Tabela 19 - INSCRICAO_VESTIBULAR
Campo Tipo Nulo PK FK
CURSO_NR_CUR int(11) Não SIM
VESTIBULAR_PERIODOS_CD_ANO_LTV year(4) Não SIM
VESTIBULAR_NR_VST int(11) Não SIM
QT_INS_VST int(11) Sim
QT_APV_VST int(11) Sim
QT_RPV_VST int(11) Sim
A tabela 20 é utilizada para armazenar os dados de aluno no vestibular.
Tabela 20 - INSCRICAO_VESTIBULAR_ALUNO
Campo Tipo Nulo Padrão Extra
COD_INS_VST_AL int(11) Não SIM
61
PESSOAS_NR_CPF_PESSOA char(11) Não SIM
Campo Tipo Nulo Padrão Extra
INSCRICAO_VESTIBULAR_CURSO_NR_CUR int(11) Não SIM
INSCRICAO_VESTIBULAR_VESTIBULAR_
PERIODOS_CD_ANO_LTV year(4) Não SIM
INSCRICAO_VESTIBULAR_VESTIBULAR_NR_VST int(11) Não SIM
DT_VST date Sim
VL_NOT_DSC_01 int(11) Sim
VL_NOT_DSC_02 int(11) Sim
VL_NOT_DSC_03 int(11) Sim
VL_NOT_DSC_04 int(11) Sim
VL_NOT_DSC_05 int(11) Sim
VL_MED_NOT_VST int(11) Sim
A tabela 21 é utilizada para armazenar observações diversas.
Tabela 21 - OBSERVACAO
Campo Tipo Nulo PK FK
PESSOAS_NR_CPF_PESSOA decimal(11,0) Não SIM
DT_OBS timestamp Não SIM
TX_OBS varchar(300) Sim
A tabela 22 é utilizada para armazenar dados dos pagamentos efetuados.
Tabela 22 - PAGAMENTOS
Campo Tipo Nulo PK FK
MATRICULA_CD_MTR int(11) Não SIM
MATRICULA_PESSOAS_NR_CPF_PESSOA char(11) Não SIM
MATRICULA_CURSO_NR_CUR int(11) Não SIM
DT_PG date Não SIM
VL_MNS float Sim
VL_DSC float Sim
VL_PG float Sim
CD_BB char(3) Sim
A tabela 23 é utilizada para armazenar parâmetros do sistema.
Tabela 23 - PARAMETROS
Campo Tipo Nulo PK FK
TX_END_URL char(200) Não SIM
62
A tabela 24 é utilizada para armazenar o perfil do usuário.
Tabela 24 - PERFIL
Campo Tipo Nulo PK FK
CD_PER int(11) Não SIM
NM_PER char(20) Não
CD_UTZ_MOD_ALN_C char(1) Sim
CD_UTZ_MOD_ALN_R char(1) Sim
CD_UTZ_MOD_ALN_U char(1) Sim
CD_UTZ_MOD_ALN_D char(1) Sim
CD_UTZ_MOD_ANL_C char(1) Sim
CD_UTZ_MOD_ANL_R char(1) Sim
CD_UTZ_MOD_ANL_U char(1) Sim
CD_UTZ_MOD_ANL_D char(1) Sim
CD_UTZ_MOD_CUR_C char(1) Sim
CD_UTZ_MOD_CUR_R char(1) Sim
CD_UTZ_MOD_CUR_U char(1) Sim
CD_UTZ_MOD_CUR_D char(1) Sim
CD_UTZ_MOD_DSC_C char(1) Sim
CD_UTZ_MOD_DSC_R char(1) Sim
CD_UTZ_MOD_DSC_U char(1) Sim
CD_UTZ_MOD_DSC_D char(1) Sim
CD_UTZ_MOD_FNC_C char(1) Sim
CD_UTZ_MOD_FNC_R char(1) Sim
CD_UTZ_MOD_FNC_U char(1) Sim
CD_UTZ_MOD_FNC_D char(1) Sim
CD_UTZ_MOD_PRF_C char(1) Sim
CD_UTZ_MOD_PRF_R char(1) Sim
CD_UTZ_MOD_PRF_U char(1) Sim
CD_UTZ_MOD_PRF_D char(1) Sim
CD_UTZ_MOD_USU_C char(1) Sim
CD_UTZ_MOD_USU_R char(1) Sim
CD_UTZ_MOD_USU_U char(1) Sim
CD_UTZ_MOD_USU_D char(1) Sim
CD_UTZ_MOD_VST_C char(1) Sim
CD_UTZ_MOD_VST_R char(1) Sim
CD_UTZ_MOD_VST_U char(1) Sim
CD_UTZ_MOD_VST_D char(1) Sim
A tabela 25 é utilizada para armazenar os dados dos períodos letivos.
Tabela 25 - PERIODOS
Campo Tipo Nulo PK FK
CD_ANO_LTV year(4) Não SIM
CD_SEM char(1) Não
63
Campo Tipo Nulo PK FK
NR_CUR int(11) Sim
TX_OBS char(100) Não
NR_SEM char(2) Sim
A tabela 26 é utilizada para armazenar os dados da pessoa/cliente.
Tabela 26 - PESSOA
Campo Tipo Nuloa PK FK
NR_CPF_PESSOA char(11) Não SIM
TP_PESSOA char(2) Sim
TX_NOM char(60) Não
TX_NOM_PAI char(60) Sim
TX_NOM_MAE char(60) Não
DT_NSC date Não
CD_SEX char(1) Não
TX_EML char(60) Não
NR_DDD_TEL_RES decimal(3,0) Sim
NR_TEL_RES decimal(9,0) Sim
NR_DDD_TEL_CEL decimal(3,0) Sim
NR_TEL_CEL decimal(9,0) Sim
NR_DDD_TEL_SRV decimal(3,0) Sim
NR_TEL_SRV decimal(9,0) Sim
CD_TIP_END decimal(2,0) Sim
TX_NOM_END char(40) Sim
TX_CPL_END char(15) Sim
TX_BRO_END char(30) Sim
TX_CDD_END char(45) Sim
CD_UF_END char(2) Sim
TX_CEP_END decimal(8,0) Sim
CD_STT char(1) Sim
TX_GRD_ESC char(2) Sim
DT_ULT_ATL date Sim
A tabela 27 é utilizada para armazenar os dados referentes ao plano de
ensino da disciplina.
Tabela 27 - PLANO_ENSINO
Campo Tipo Nulo PK FK
PERIODOS_CD_ANO_LTV year(4) Não SIM
DISCIPLINA_CURSO_NR_CUR int(11) Não
64
Campo Tipo Nulo PK FK
DISCIPLINA_CD_DSC int(11) Não
NR_PLN_ESN int(11) Não
TX_NOM_PRF char(60) Não
TX_END_ARQ char(60) Sim
DT_ULT_ALT date Sim
A tabela 28 é utilizada para armazenar os dados de tipo de boleto.
Tabela 28 - TIPO_BOLETO
Campo Tipo Nulo PK FK
CD_TIP_BOL int(11) Não SIM
NM_TIP_BOL varchar(45) Sim
TX_RGR text Sim
A tabela 29 é utilizada para armazenar dados de tipo de documento.
Tabela 29 - TIPO_DOC
Campo Tipo Nulo PK FK
CD_TIP_DOC char(2) Não SIM
TX_TIP_DOC char(30) Sim
A tabela 30 é utilizada para armazenar o tipo de endereço.
Tabela 30 - TIPO_END
Campo Tipo Nulo PK FK
CD_TIP_END decimal(2,0) Não SIM
TX_TIP_END char(10) Sim
A tabela 31 é utilizada para armazenar a unidade da federação.
Tabela 31 - UF
Campo Tipo Nulo PK FK
CD_UF char(2) Não SIM
TX_UF char(30) Sim
A tabela 32 é utilizada para armazenar o usuário e seu perfil.
Tabela 32 - USUARIO
Campo Tipo Nulo PK FK
PESSOA_NR_CPF_PESSOA char(11) Não SIM
PERFIL_CD_PER int(11) Não SIM
TX_SNH char(8) Não
DT_INI date Não
65
Campo Tipo Nulo PK FK
DT_ULT_ATL date Não
A tabela 33 é utilizada para armazenar os dados do vestibular (prova).
Tabela 33 - VESTIBULAR
Campo Tipo Nulo PK FK
NR_VST int(11) Não SIM
PERIODOS_CD_ANO_LTV year(4) Não SIM
DT_INI_INS date Sim
DT_FIN_INS date Sim
CD_STT char(1) Sim
No Anexo A foi inserido o dicionário de dados do sistema SISEDU, utilizado
na construção de todo o modelo das tabelas do banco de dados.
6.9. Árvore do Sistema
Na figura 17 a estrutura do sistema é demonstrada em forma de árvore
Figura 17 - Árvore do sistema (SISEDU-Financeiro)
66
6.10. Especificações Técnicas
As especificações técnicas abrangem tudo que se torna necessário em
termos físicos e lógicos para o bom funcionamento do sistema, isto se aplica deste
as instalações físicas do ambiente onde residirá o sistema até a parte lógica
(softwares) que farão a monitoração do sistema.
6.10.1. Layout das Principais Telas da Aplicação
A figura 18 ilustra a tela de cadastro de boleto, responsável pela geração
dos dados do boleto propriamente dito.
Figura 18 - Tela de Cadastro de Novo Boleto
Na figura 19, é demonstrado a tela de boleto cadastrado com sucesso.
Figura 19 - Tela de Boleto Cadastrado com Sucesso
67
Na figura 20, é demonstrada a tela de busca de boleto, onde é possível fazer
uma busca por CPF ou nome do Aluno.
Figura 20 - Tela de Busca de Boleto
Caso a busca não retorne nenhum registro a figura 21 é mostrada.
Figura 21 - Tela de Resultado de busca, caso não encontrado.
A edição de boleto é mostrada conforme figura 22, quando há o acesso ao
botão editar, o programa traz os dados previamente inseridos.
Figura 22 - Tela de Edição de Boleto
68
A figura 23 é mostrada quando se deseja realizar uma deleção de boleto
Figura 23 - Confirmação para deleção
A figura 24 é mostrada quando se confirma o pedido de deleção, a deleção é
apenas lógica e os dados não serão excluídos definitivamente da base de dados.
Figura 24 - Tela de Boleto Deletado com sucesso.
A figura 25 é a visualização do boleto, onde todos os dados anteriormente
cadastrados são organizados para formar o boleto de cobrança.
69
Figura 25 - Visualização do Boleto.
6.10.2 Navegação
Na figura 26 é ilustrado o menu de navegação do sistema, onde são exibidos
todos os módulos do sistema SISEDU em forma de botões, por onde os usuários
irão navegar para acessar os diferentes módulos do sistema.
70
Figura 26 - Menu de Navegação do Sistema
6.11 Segurança Física e Lógica
O avanço da tecnologia da informação tem proporcionado as empresas
maior eficiência e rapidez na troca de informações. Esse novo tipo de ambiente
computacional tornou-se completamente complexo na questão da segurança. As
ameaças aos ambientes computacionais estão em constantes evoluções para
auxiliar a organização e a melhoria na segurança das informações onde foram
criadas normas e diretrizes que auxiliam a segurança da empresa.
Atualmente existe a norma padrão ISO/IEC Internacional 17799 que é a
proteção contra grande quantidade de ameaças às informações, de forma a
assegurar a continuidade do negócio, minimizando danos comerciais e maximizando
o retorno de possibilidades e investimentos. A segurança da informação tem que
esta relacionada com o faturamento de uma empresa, sua imagem e sua reputação
perante as consequências de incidentes de segurança que muitas vezes podem ser
desastrosas, porém que podem ser evitadas.
6.12 Segurança Física
Proteção física pode ser obtida criando várias barreiras de proteção em
torno das estações minimizando os riscos de perdas das informações e
processamento de informações da organização. Cada barreira estabelece um
perímetro de segurança, cada um aumentando a proteção total fornecida. As
organizações devem usar perímetros de segurança para proteger áreas que
71
contenham facilidades de processamento de informações. Um perímetro de
segurança é alguma coisa que constitui uma barreira, tal como uma parede, um
portão de entrada controlado por cartão ou um balcão de recepção com atendentes.
A localização e a resistência de cada barreira dependem dos resultados de uma
avaliação de riscos (RUP 2009).
6.13 Segurança Lógica
Proteger a integridade de software e suas informações, e necessário para
impedir a detectar a introdução de softwares maliciosos. Os softwares normalmente
são vulnerários a introdução de software malicioso, tais como vírus de computador,
Cavalos de Tróia, Worms e bombas lógicas. Os usuários deve se precaver contra o
perigo software malicioso, e os gerentes devem apropriar implantando controles
especiais para detectar ou impedir software malicioso.
Instalação e atualização de software para detectar vírus e reparos.
Backup dos softwares e das informações e essências para o negócio devem
ser executados regulamente. Adequando o backup para ser fornecidas para
assegurar que todas as informações que são essências para o negócio possam ser
recuperadas após um desastre ou falha em alguma mídia.
72
7 Plano de Implantação
O plano de implantação descreve as atividades que garantem que o produto
de software será disponibilizado aos usuários finais. No plano de implantação
podemos descrever em três modos de implantação do produto:
• A instalação personalizada;
• O produto em uma forma “compacta”;
• Acesso ao software por meio da internet .
Em cada instância, a ênfase é a teste do produto no local do
desenvolvimento, seguidos desde os testes aos testes beta, onde finalmente pode
se oferecido ao cliente.
A implantação de software é disponibilizar o software final para o usuário, e
o esforço final do desenvolvimento de software.
O planejamento da implantação de software se inicia no ciclo de vida do
projeto e envolve não só produto do software, mas também o desenvolvimento de
material de treinamento e suporte para garantir que o usuário final possa usar
corretamente o produto.
Material de suporte inclui todo tipo de material para que o usuário final
instale, opere e mantenha o sistema finalizado. Incluindo também material de
treinamento para diversas posições necessárias para utilização correta do novo
sistema.
7.1 Atividades Futuras
Num primeiro momento buscou-se suprir as necessidades básicas e
essenciais para manter o sistema em funcionamento levando em conta o usuário
Aluno com prioridade, para um segundo plano ficam listadas várias atividades a
serem desenvolvidas futuramente a fim de suprir os usuários Funcionário e
Professor, são elas:
Geração de relatórios de controle;
Financeiro para usuários;
Financeiro para professores.
73
Implementação de ferramentas financeiras a fim de atingir processos que
envolva o funcionário e o professor;
74
8 Conclusão
O estudo realizado para compor todo este trabalho objetivou levantar todo o
conhecimento necessário para se construir um software para a Faculdade ABC.
Após estudo detalhado da instituição, foi possível entender as necessidades e
propor a solução para o novo sistema.
Utilizando conceitos e práticas de engenharia de software, programação,
banco de dados, padrões de modelagem bem como unificação de processos temos
por concluir a viabilidade de se construir o sistema em questão.
Com a construção dos módulos e posterior integração e implementação do
sistema, se espera melhorar qualidade na execução dos processos e rotinas da
Faculdade ABC, além de oferecer ao aluno maior comodidade e agilidade em alguns
tipos de solicitações que poderão ser requeridas online. Ressalta-se que este projeto
é apenas um módulo (módulo financeiro) de um sistema composto por outros
módulos e para pleno funcionamento do sistema é necessário o desenvolvimento
dos demais módulos citados no item 5. A implementação do módulo financeiro se
refere às funcionalidades básicas levantadas, cabendo o posterior desenvolvimento
e implementação das funcionalidades descritas no item 7.1.
Quanto ao módulo financeiro específico deste trabalho, podemos concluir
que foi construído seguindo o levantamento de requisitos e está funcionando, pronto
para ser integrado aos demais módulos do Sistema SIEDU.
75
9 Bibliografia
ABBEY, M., COREY, M. J., & ABRAMSON, I. (2000). Oracle 8i - Guia Introdutório.
Rio de Janeiro: Campus.
BOOCH, G., RUMBAUGH, J., & JACOBSON, I. (2005). UML - Guia do Usuário. Rio
de Janeiro: Campus.
CAMPANO, J. (2009). Introdução ao E-Commerce e Questões de Usabilidade.
JM Digital.
CISNEIROS, H. (07 de 05 de 2009). Modelo de Desenvolvimento Ágil SCRUM.
Acesso em 2009 de 05 de 25, disponível em Devin - a antiga página do Eitch :
http://www.devin.com.br/modelo-scrum/
CONECOB. (2006). Manual técnico operacional. Acesso em 10 de 05 de 2011,
disponível em bradesco:
http://www.bradesco.com.br/br/pj/conteudo/sol_rec/pdf/manualtecnico.pdf
CUNHA, F. A. (27 de 06 de 2007). PROTOTIPAÇÃO DE SOFTWARE:
Prototipação Evolutiva. Acesso em 08 de 06 de 2011, disponível em
WebArtigos.com: http://www.webartigos.com/articles/1896/1/Prototipacao-De-
Software/pagina1.html
EISENTRAUT, P. (s.d.). PostegreSQL. Acesso em 30 de 05 de 2011, disponível em
PostegreSQL: http://www.postgresql.org/community/contributors/
FARIA, C. (30 de 05 de 2008). Organograma. Acesso em 08 de 06 de 2011,
disponível em Info Escola - Navegando e Aprendendo:
http://www.infoescola.com/administracao_/organograma/
FILHO, W. d. (2001). Engenharia de Software. Rio de Janeiro: LTC.
GUEDES, G. T. (2005). Guia de Consulta Rápida UML 2. São Paulo: Novatec.
HERMANO, M. (12 de 12 de 2001). Visão Geral do RUP. Acesso em 02 de 06 de
2011, disponível em http://www.cin.ufpe.br/~if716/slides/pdfs/visao-geral-RUP.pdf
HORSMANN, C. (2005). Conceitos de Computação com o Essencial de Java.
Porto Alegre: Bookman.
JUNIOR, F. C. (2001). Programando para a Web com PHP/MySQL.
76
KRUCHTEN, P. (2003). Introdução ao RUP - Rational Unified Process. Rio de
Janeiro: Ciência Moderna LTDA.
KUHN, G. R., & PAMPLONA, V. F. (17 de 08 de 2009). Apresentando XP. Encante
seus clientes com Extreme Programming. Acesso em 19 de 05 de 2011,
disponível em JavaFree.org: http://javafree.uol.com.br/artigo/871447/Apresentando-
XP-Encante-seus-clientes-com-Extreme-Programming.html
LACKEY, E. (04 de 10 de 2008). Começando com o CakePHP. Acesso em 06 de
06 de 2011, disponível em CakePHP:
http://book.cakephp.org/pt/view/890/Entendendo-o-Model-View-Controller-MVC
LARMAN, C. (2007). Utilizando UML e Padrões: uma introdução à análise e ao
projto orientado a objetos e ao desenvolvimento iterativo. Porto Alegre:
Bookman.
LISCHNER, R. (2000). Delphi. O Guia Essencial. Rio de Janeiro: Campus.
MARTINS, D. F. (17 de 08 de 2009). Apresentando Model-View-Presenter, o MVC
focado na visualização. Acesso em 02 de 06 de 2011, disponível em Javafree.org:
http://javafree.uol.com.br/artigo/871446/Apresentando-ModelViewPresenter-o-MVC-
focado-na-visualizacao.html
MARTINS, J. C. (2004). Gerenciando Projetos de Desenvolvimento de Software
com PMI, RUP e UML (1 edição ed.). Rio de Janeiro: Brasport.
MATOS, A. V. (2002). Unified Modeling Language - UML Prático e
Descomplicado. São Paulo: Erica.
MELO, C. (2004). Desenvolvendo Aplicações com UML 2.0: Conceitual e
Implementação (2ª Edição ed.). Rio de Janeiro: Brasport.
PACHECO, H. O. (2005). Documentação do PostgreSQL 8.0: Projeto de
Tradução para o Português do Brasil. Fonte: http://www.postgresql.org.br/docs
PACIEVITCH, Y. (20 de 03 de 2011). História do Java. Acesso em 30 de 06 de
2011, disponível em Info Escola: http://www.infoescola.com/informatica/historia-do-
java/
PRESSMAN, R. S. (1995). Engenharia de Software. São Paulo: Person Education
do Brasil.
RAMALHO, J. A. (1999). Oracle8i. São Paulo: Berkeley Brasil.
77
SALASAR, W., VALENTIM, S., & VIVAN, D. (11 de 06 de 2008). DOS BLOQUETOS
AO DDA. Acesso em 04 de 07 de 2011, disponível em FEBRABAN:
http://www.febraban.org.br/Noticias1.asp?id_texto=119&id_pagina=61&palavra=bloq
uetos
SANT'ANA, A. d. (28 de 11 de 2010). Os Processos RUP. Acesso em 02 de 06 de
2011, disponível em WebArtigos.com: http://www.webartigos.com/articles/53262/1/O-
Processo-RUP/pagina1.html
SEBESTA, R. S. (2002). Conceitos de Linguagens de Programação. Porto Alegre:
Artmed Editora S.A.
SILBERSCHATZ, A., KORTH, H. F., & SUDARSHAN, S. (2006). Sistema de Banco
de Dados. Rio de Janeiro: Elsevier Editora LTDA.
SMITH, D., & NEGRINO, T. (2001). JavaScript para World Wid Web. Campos
Elsevier.
SOMMERVILLE, I. (2003). Engenharia de Software. São Paulo: Addison Wesley.
SWAN, T. (1997). Delphi, Bíblia do Programador (3 Edição ed.). São Paulo: IDG
Books.
VALENTE, F. (11 de 01 de 2011). O que é MVC. Acesso em 02 de 06 de 2011,
disponível em FernandoValente:
http://www.fernandovalente.com.br/wordpress/2011/01/11/mvc-model-view-
controller/
VILLAS, M. V., & VILLASBOAS, L. F. (1987). Programação: conceitos, técnicas e
linguagens. Rio de Janeiro: Campus.
78
Anexo A – Dicionário de dados SISEDU
O Anexo A se trata do dicionário de dados utilizado na construção das
tabelas do banco de dados do sistema SISEDU.
COD DESCRIÇÃO
CD CODIGO
DT DATA
HR HORA
IN INDICE
NM NOME
NR NUMERO
QT QUANTIDADE
TS TIMESTEMP
TX TEXTO
VL VALOR
2EP 2a. Época
AG Agência
ALN Aluno
ANO Ano
ANT Anterior
APR Apresentação
APV Aprovado
ARQ Arquivo
ATL Atual-Atualização
AUTZ Autorizado
B1 Bimestre 1
B2 Bimestre 2
BB Código do Banco
BOL Boleto
BRO Bairro
CAD Cadastro
CC Conta Corrente
CDD Cidade
CEL Celular
CEP Código Postal
79
COD DESCRIÇÃO
COO Coordenador
CPL Complemento
CRG Carga
CTR Controle
CUR Curso
DCP Disciplina
DD Dias
DESC Descrição
DOC Documentação
DSC Disciplina
EML e_mail
EMM Ementa
END Endereço
ENT Enturmação
ENS Ensino
ESC Escolaridade
EST Estágio
FILI Filiação
FIN Final
FLT Faltas
FRM Formatura
FUC Funcionário
GRA Grade
GRC Geração
GRD Grau
HOR Horário/Hora
INCL Inclusão
INI Inicial
INS Inscrição
LIM Limite
LTV Letivo
MTR Matricula
MEC Min. Educação
MED Média
MNS Mensalidade
80
COD DESCRIÇÃO
MOD Módulo
MSG Mensagem
MVT Movimento
NOM Nome
NOT Nota
NSC Nascimento
OBS Observação
PFN Prova Final
PAG Pago
PER Perfil
PLN Plano
PRD Período
PRF Professor
REG Regularização
RES Residencial
RGR Regra
RLZ Realização
RPV Reprovado
RSP Responsável
SAL Sala
SDO Saldo
SEM Semestre
SEQ Sequencial
SEX Sexo
SGL Sigla
SIT Situação
SMN Semana
SNH Senha
SRV Serviço
STT Status
TEL Telefone
TIP Tipo
TOT Totais
TRM Turma
TRN Turno
81
COD DESCRIÇÃO
UF Unid.Federativa
ULT Última
USU Usuário
UTZ Utilização
VCT Vencimento
VST Vestibular
