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

Monografia apresentada a
Faculdade Alvorada para a
obtenção do título de Bacharel
em Sistemas de Informação.

Orientadores: Prof. Mestre Osmar Ribeiro Torres
Profa. Mestre Elizabeth d´Arrochella Teixeira

Brasília-DF
2011

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
ANSI Página National Institute
American
Application Programming Interface (Interface de
API
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
IES Hipertexto)de Ensino Superior
Instituição
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
SGBG Relacional Gerenciamento de Banco de Dados
Sistema de
SISEDU Sistema Educacional
SQL Structured Query Language (Linguagem de Consulta
UML Estruturada)
Unified Modeling Language (Linguagem Única de
XP Modelagem)
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

Apresentação da monografia
Levantamento de Requisitos

Acertos após Apresentação

Acertos após apresentação
Análise (def. casos de uso)
Definição da metodologia

Integração dos Módulos
Planejamento de Ações
Definição do Problema

Escrever a monografia
Levantamento Teórico
Pesquisa Bibliográfica
Delimitação do Tema
ANO 2011

Apresentação TCC I

Entrega final
Codificação
Quinzena

Projeto

Testes
TCC I
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

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

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

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

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 Exibir dados do boleto escolhido

deseja realizar a alteração

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 Exibir dados do boleto escolhido

deseja realizar a exclusão 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)

SisEdu – Sistema Educacional - Módulo Financeiro

SisEdu – Sistema Educacional - Módulo Financeiro

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (11)

Ähnlich wie SisEdu – Sistema Educacional - Módulo Financeiro

Ähnlich wie SisEdu – Sistema Educacional - Módulo Financeiro (20)

Mehr von UNIEURO

Mehr von UNIEURO (11)

SisEdu – Sistema Educacional - Módulo Financeiro