Successfully reported this slideshow.
FACULDADE ALVORADACURSO DE BACHARELADO EM SISTEMAS DE INFORMAÇÃO          Emerson Alex Teixeira de Morais         Michael ...
ii         Emerson Alex Teixeira de Morais        Michael James Rodrigues Romeiro       SISEDU – SISTEMA EDUCACIONAL      ...
iii                                 AGRADECIMENTOS       Emerson Alex Teixeira de Morais – Primeiramente agradeço a Deus p...
iv                                      RESUMO       Buscamos através deste projeto, expor a formulação de um trabalhodesc...
v                                        ABSTRACT        We seek through this project, exposing the formulation of a decen...
vi                                                        LISTA DE FIGURASFigura 1 - Organograma da Faculdade ABC ...........
vii                                           LISTA DE TABELASTabela 1 - Planejamento do projeto de desenvolvimento .........
viii             LISTA DE ABREVIATURAS E SIGLASSigla         DescriçãoANSI          Página National Institute             ...
9                                                          SUMÁRIO1. Introdução .............................................
10  5.4. Áreas Afetadas Pelo Novo Sistema ............................................................. 48  5.5. Banco de ...
11   1. Introdução        Segundo CAMPANO (2009), a Internet não é um canal de comunicação paraser subestimado e cada dia ...
12los on-line, através de Login/senha, facilitando a emissão e recebimento dos boletospelos alunos.          Esta é uma fo...
13           Sendo mais específico, o grande problema encontrado no departamentofinanceiro da Faculdade ABC é que o contro...
14   1.5. Organização do Trabalho        O primeiro capítulo refere-se ao contexto do trabalho, o tema, os objetivosda mon...
152. Análise Institucional       Neste capítulo trataremos da análise institucional da Faculdade ABC, suahistória e seus o...
16        A imagem abaixo representa o organograma da empresa que se trata darepresentação gráfica da hierarquia da instit...
17        Com foco no departamento financeiro não há qualquer tipo de integração on-line para uso de alguns serviços pelos...
183. Cronograma       Desenvolver o cronograma significa determinar as datas de início e fim paraas atividades do projeto....
194. Referencial Teórico       Para o desenvolvimento deste trabalho foram estudados os principaisconceitos do RUP (Ration...
20        Procedimentos: constituem o elo que mantém entre os métodos e asferramentas e possibilita o desenvolvimento raci...
21        A figura 2 demonstra o ciclo de vida do modelo cascata:                     Figura 2 - O cilco de vida clássico ...
22            4.1.1.2.   Prototipação        Segundo CUNHA (2007) Protótipo é a primeira versão desenvolvida dosoftware, a...
23          (3) um programa existente que executa parte ou toda a função, mas que temoutras    características   que   ser...
24        Avaliação feita pelo cliente: avaliação dos resultados da engenharia.        Um aspecto particular se torna clar...
25engenharia de software mínimos e simplicidade global do desenvolvimento. Asdiretrizes de desenvolvimento enfatizam a ent...
26           1.   O produto é definido: quais são os seus requisitos? O que realmente ocliente quer? O responsável por est...
27          4.1.2.2.   XP (Extreme Programming)       Para os autores KUHN e PAMPLONA (2009), XP é uma metodologia parades...
28                     Figura 6 - Ciclo de vida do Extreme Programming                                 Fonte: PRESSMAN (19...
29   4.2. Linguagem de Programação        Segundo SEBESTA (2002) os computadores são usados em uma infinidadede diferentes...
30        Segundo HORSTMANN (2005) o Java além da sua própria linguagemtambém possui uma rica biblioteca, que torna possív...
31       O Delphi é utilizado para aplicativos rápidos, adequado para criação deprotótipos do Windows e aplicativos profis...
32Entre outros aplicativos destaca-se também um aplicativo usado na modelagem decomponentes de sistema, entre aplicativos ...
33       • comandos complexos;       • chaves estrangeiras;       • gatilhos;       • visões;       • integridade transaci...
34R, no início dos anos 70; em 1996, a American National Institute (ANSI) publicou umpadrão SQL. A SQL estabeleceu-se como...
35que o cliente estabeleceu, na medida em que o software seja entregue na altaqualidade satisfazendo dentro dos requisitos...
36          4.4.1.1.   A Fase de Iniciação (ou Concepção)        Segundo Martins (2004), os envolvidos devem chegar a um a...
37tão rápido quanto possível de ser realizada; delinear a visão; delinear um plano dealta-fidelidade para a fase de constr...
38          Entra-se nesta fase quando uma linha base é madura suficiente para serdistribuída no domínio de usuários finai...
39modelo são mostrados aos usuários. O controle interpreta as entradas do usuário,ele comanda o modelo e a visão para que ...
40foram apresentados à comunidade (cerca de 50 no período de 1989 e 1994), ondegrande parte tendia aos métodos estruturado...
41executar. Internamente, um caso de uso é uma sequência de ações que permeiam aexecução completa de um comportamento espe...
42                            Figura 10 - Diagrama de Classes                                 Fonte: MATOS (2002)      4.6...
43                              Figura 11 - Diagrama de Interação                                    Fonte: MATOS (2002)  ...
44        Qualquer máquina de estados pretende avaliar os aspectos dinâmicos deuma construção e sempre são identificados o...
45         4.6.5.2.   Desenho de um Diagrama de Atividades       Conforme MATOS (2002), do ponto de vista de representação...
46         Criar um sistema informatizado de ambiente WEB que trabalhará com osconceitos de internet, intranet e extranet ...
47        A biblioteca também será receberá um módulo, capaz de gerar boletosreferentes a multas por atrasos além de fazer...
48        O sistema inicialmente terá um foco no cliente/aluno e com a utilização dosistema proposto se espera dar maior c...
49       Por ser uma ferramenta gratuita o MySQL, se tornou largamente usado nocenário atual possibilitando a formação de ...
50          Nesta seção serão descritos os atores do sistema, mostrando o papel decada um dentro do mesmo. Também será exi...
51        Na tabela 3 estão listados os casos de uso do módulo financeiro do sistemaSISEDU.                       Tabela 3...
52                                  Tabela 4 - Manter BoletoNome                   UC01 – Manter BoletoObjetivo           ...
SisEdu – Sistema Educacional - Módulo Financeiro
SisEdu – Sistema Educacional - Módulo Financeiro
SisEdu – Sistema Educacional - Módulo Financeiro
SisEdu – Sistema Educacional - Módulo Financeiro
SisEdu – Sistema Educacional - Módulo Financeiro
SisEdu – Sistema Educacional - Módulo Financeiro
SisEdu – Sistema Educacional - Módulo Financeiro
SisEdu – Sistema Educacional - Módulo Financeiro
SisEdu – Sistema Educacional - Módulo Financeiro
SisEdu – Sistema Educacional - Módulo Financeiro
SisEdu – Sistema Educacional - Módulo Financeiro
SisEdu – Sistema Educacional - Módulo Financeiro
SisEdu – Sistema Educacional - Módulo Financeiro
SisEdu – Sistema Educacional - Módulo Financeiro
SisEdu – Sistema Educacional - Módulo Financeiro
SisEdu – Sistema Educacional - Módulo Financeiro
SisEdu – Sistema Educacional - Módulo Financeiro
SisEdu – Sistema Educacional - Módulo Financeiro
SisEdu – Sistema Educacional - Módulo Financeiro
SisEdu – Sistema Educacional - Módulo Financeiro
SisEdu – Sistema Educacional - Módulo Financeiro
SisEdu – Sistema Educacional - Módulo Financeiro
SisEdu – Sistema Educacional - Módulo Financeiro
SisEdu – Sistema Educacional - Módulo Financeiro
SisEdu – Sistema Educacional - Módulo Financeiro
SisEdu – Sistema Educacional - Módulo Financeiro
SisEdu – Sistema Educacional - Módulo Financeiro
SisEdu – Sistema Educacional - Módulo Financeiro
SisEdu – Sistema Educacional - Módulo Financeiro
Upcoming SlideShare
Loading in …5
×

SisEdu – Sistema Educacional - Módulo Financeiro

4,565 views

Published on

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.

SisEdu – Sistema Educacional - Módulo Financeiro

  1. 1. FACULDADE ALVORADACURSO 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
  2. 2. 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
  3. 3. iii AGRADECIMENTOS Emerson Alex Teixeira de Morais – Primeiramente agradeço a Deus porter colocado dificuldades e me dado forças para vencer, pois sem as dificuldadesnão haveria motivos para superação, Agradeço também aos meus familiares em especial meus pais Luiz Carlosde Morais e Rita Teixeira de Morais pela educação que me deram e pelo apoioprestado. Agradeço ainda a todos da turma de Bacharelado em Sistemas deInformação, turma de 2008-2011. Deixo créditos também a todos os professorespelo suporte e orientação que nos deram ao longo desta jornada, em especial aprofessora d’Arrochella que com punhos de ferro no conduziu e ao professor Osmar,orientador desta monografia. Michael James Rodrigues Romeiro – Agradeço á DEUS por meproporcionar fôlegos de vida para contemplar toda essa história de vida. Dedico estetrabalho a meus pais por todo o seu amor e dedicação para comigo a minha famíliapor todo carinho e compreensão a minha namorada Juliana Maciel por sempre estaao meu lado nos momentos difíceis, aos meus professores por toda ajuda durantemeus estudos, a todos meus amigos da turma Bacharelado Sistemas de Informação2008 a 2011, que juntos estamos trilhando no mesmo caminho para o sucesso.
  4. 4. iv RESUMO Buscamos através deste projeto, expor a formulação de um trabalhodescentralizado, modular e ágil de uma IES (Instituição de Ensino Superior), comobjetivo de trabalhar com esta IES de maneira homogênea onde todos os módulosserão integrados. Especificamente este trabalho consiste em demonstrar a realização doprojeto 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 oambiente de desenvolvimento utilizando o estudo de viabilidade do projeto,indicando problemas subsequentes, expondo as necessidades e sugerindo novasrotinas informatizadas que serão totalmente otimizadas para a formulação depagamentos via boleto bancário. Palavras-chave: Sistemas de Informação. Sistema Financeiro. ProcessoUnificado. Modelagem Única de Sistemas. Engenharia de Software.
  5. 5. v ABSTRACT We seek through this project, exposing the formulation of a decentralizedwork, modular and agile an HEI (Higher Education Institution), in order to work withthis IES evenly where all modules will be. Specifically this work is to demonstrate the achievement of the project tobuild the web system to make payment by bank, showing the development of thesystem, since the choices of tools for the development environment using thefeasibility study for the project, indicating subsequent problems, exposing the needsand suggesting new computerized routines that are fully optimized for the formulationof payments via bank transfer. Keywords: Information Systems. Financial System. Processo Unificado daRational Modeling Language. Software Engineering.
  6. 6. vi LISTA DE FIGURASFigura 1 - Organograma da Faculdade ABC ................................................................................. 16Figura 2 - O cilco de vida clássico (modelo cascata) ................................................................... 21Figura 3 - O modelo de Prototipagem ............................................................................................. 23Figura 4 - O modelo Espiral .............................................................................................................. 24Figura 5 - Ciclo de vida do Scrum.................................................................................................... 26Figura 6 - Ciclo de vida do Extreme Programming ....................................................................... 28Figura 7 - Arquitetura Geral do RUP (Gráfico de Baleia) ............................................................. 35Figura 8 - Requisição básica de um MVC ...................................................................................... 39Figura 9 - Diagrama de caso de uso ............................................................................................... 41Figura 10 - Diagrama de Classes .................................................................................................... 42Figura 11 - Diagrama de Interação .................................................................................................. 43Figura 12 - Diagrama de Estados .................................................................................................... 44Figura 13 - Diagrama de Atividades ................................................................................................ 45Figura 14 - Diagrama de caso de uso (SISEDU-Financeiro) ...................................................... 51Figura 15 - Diagrama de classe (SISEDU-Financeiro)................................................................. 54Figura 16 - Modelo de Entidade e Relacionamento (SISEDU) ................................................... 55Figura 17 - Árvore do sistema (SISEDU-Financeiro).................................................................... 65Figura 18 - Tela de Cadastro de Novo Boleto ............................................................................... 66Figura 19 - Tela de Boleto Cadastrado com Sucesso .................................................................. 66Figura 20 - Tela de Busca de Boleto ............................................................................................... 67Figura 21 - Tela de Resultado de busca, caso não encontrado. ................................................ 67Figura 22 - Tela de Edição de Boleto .............................................................................................. 67Figura 23 - Confirmação para deleção............................................................................................ 68Figura 24 - Tela de Boleto Deletado com sucesso. ...................................................................... 68Figura 25 - Visualização do Boleto. ................................................................................................. 69Figura 26 - Menu de Navegação do Sistema ................................................................................ 70
  7. 7. vii LISTA DE TABELASTabela 1 - Planejamento do projeto de desenvolvimento .......................................... 18Tabela 2 - Comparativo entre tecnologias ................................................................. 47Tabela 3 - Lista de diagramas de caso de uso .......................................................... 51Tabela 4 - Manter Boleto ........................................................................................... 52Tabela 5 - Gerar Boleto ............................................................................................. 53Tabela 6 - PERIODOS .............................................................................................. 56Tabela 7 - MATRICULA ............................................................................................ 56Tabela 8 - TURMAS .................................................................................................. 56Tabela 9 - ENTURMACAO ........................................................................................ 57Tabela 10 - DISCIPLINA_MATRICULA ..................................................................... 57Tabela 11 - BANCO .................................................................................................. 57Tabela 12 - BOLETO ................................................................................................. 57Tabela 13 - CURSO .................................................................................................. 58Tabela 14 - DISCIPLINA ........................................................................................... 58Tabela 15 - DOCUMENTOS ..................................................................................... 59Tabela 16 - GRADE_CURRICULAR ......................................................................... 59Tabela 17 - HST_PESSOA ....................................................................................... 59Tabela 18 - HST_USUARIO ...................................................................................... 60Tabela 19 - INSCRICAO_VESTIBULAR ................................................................... 60Tabela 20 - INSCRICAO_VESTIBULAR_ALUNO ..................................................... 60Tabela 21 - OBSERVACAO ...................................................................................... 61Tabela 22 - PAGAMENTOS ...................................................................................... 61Tabela 23 - PARAMETROS ...................................................................................... 61Tabela 24 - PERFIL................................................................................................... 62Tabela 25 - PERIODOS ............................................................................................ 62Tabela 26 - PESSOA ................................................................................................ 63Tabela 27 - PLANO_ENSINO ................................................................................... 63Tabela 28 - TIPO_BOLETO ...................................................................................... 64Tabela 29 - TIPO_DOC ............................................................................................. 64Tabela 30 - TIPO_END ............................................................................................. 64Tabela 31 - UF .......................................................................................................... 64Tabela 32 - USUARIO ............................................................................................... 64Tabela 33 - VESTIBULAR ......................................................................................... 65
  8. 8. viii LISTA DE ABREVIATURAS E SIGLASSigla DescriçãoANSI Página National Institute American Application Programming Interface (Interface deAPI Programação de Aplicações)E-COMMERCE Comércio EletrônicoFEBRABAN Federação Brasileira de BancosHTML Hypertext Markup Language (Linguagem de MarcaçãoIES Hipertexto)de Ensino Superior InstituiçãoIR Imposto de RendaMVC Model-View-Controller (Modelo-Visão-Controlador)ODBC Open Data Base ConnectivityOOSE Object-oriented software engineeringPHP PHP Hypertext Processor (Processador de Hipertexto PHP)RUP Rational Unified Process (Processo Unificado da Rational)SGBDOR Sistema de Gerenciamento de Banco de Dados ObjetoSGBG Relacional Gerenciamento de Banco de Dados Sistema deSISEDU Sistema EducacionalSQL Structured Query Language (Linguagem de ConsultaUML Estruturada) Unified Modeling Language (Linguagem Única deXP Modelagem) Extreme Programming (Programação Extrema)
  9. 9. 9 SUMÁRIO1. 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 ............................................................................. 142. 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 .................................................................... 173. Cronograma ........................................................................................................ 184. 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 ........................................................ 435. 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. 10. 10 5.4. Áreas Afetadas Pelo Novo Sistema ............................................................. 48 5.5. Banco de Dados ........................................................................................... 486. 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 ..................................................................................... 717 Plano de Implantação ......................................................................................... 72 7.1 Atividades Futuras........................................................................................ 728 Conclusão ........................................................................................................... 749 Bibliografia .......................................................................................................... 75Anexo A – Dicionário de dados SISEDU ................................................................... 78
  11. 11. 11 1. Introdução Segundo CAMPANO (2009), a Internet não é um canal de comunicação paraser subestimado e cada dia mais as empresas utilizam-na como parte integrante dasua estratégia de marketing e publicidade. A diminuição de custos, a audiência maiselevada e um grau superior de interatividade com o cliente/visitante são apenasalguns dos aspectos que elevam a Internet nos dias de hoje ao mesmo nível queoutras 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 deigual 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 vivemdas transações financeiras, é de supra importância que as mesmas sejam realizadasnum ambiente devidamente seguro e de confiança. De igual modo, é importante queo sistema de pagamento seja rápido e simples. Idealmente em termos operacionais a página de pagamento deverá estarincluída no site da empresa tendo em atenção à inclusão de diversas formas depagamento. 1.1. Tema Encontra-se em elaboração uma proposta de um sistema unificado naFaculdade ABC (empresa fictícia), que lide com as solicitações de serviços,monitoramento de informações financeiras e acadêmicas por gestores e discentesmatriculados, dentre outras atribuições dentro da Instituição, este projeto foinomeado de SISEDU (Sistema Educacional). O presente estudo visa odesenvolvimento de um dos módulos integrantes deste sistema, responsável pelaparte financeira. O módulo Financeiro do sistema SISEDU (Sistema Educacional) será umsistema capaz de gerar boletos referentes a mensalidades e serviços e disponibilizá-
  12. 12. 12los on-line, através de Login/senha, facilitando a emissão e recebimento dos boletospelos alunos. Esta é uma forma de centralizar o fluxo financeiro da Faculdade ABC em umsó 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 podeser considerada defasada, pois é baseada em tarefas manuais com circulação dedocumentos físicos (papéis) e geração de planilhas eletrônicas, ambas sem um tipode controle adequado. O sistema Cathedra utilizado atualmente auxilia em algumas atividadesfinanceiras como a geração de boletos (em papel), porém este recurso somente osemite, não permitindo o controle dos mesmos. Notadamente a Faculdade ABC necessita de uma forma automatizada paragerar 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 situadana cidade de Brasília, que usa sistemas informatizados que compreendem todas asatividades desenvolvidas pela mesma, estando diretamente ligado à sua matriz emCuritiba; utiliza o sistema denominado Cathedra que faz toda a gerência dosrecursos disponíveis, desde o nível operacional até o gerencial e o sistemaWebClass que gerencia basicamente os dados acadêmicos como notas e diários declasse. É 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 umtodo.
  13. 13. 13 Sendo mais específico, o grande problema encontrado no departamentofinanceiro da Faculdade ABC é que o controle é feito através de planilhas eletrônicase documentos físicos (em papel) e planilhas eletrônicas. 1.4. Objetivos O nosso objetivo é projetar e implementar um sistema, de forma que possaabranger todas as necessidades e erradicar todo tipo de rotina manual, otimizandoao máximo a credibilidade das rotinas de pagamento da instituição através deboletos. 1.4.1. Objetivo Geral Informatizar e automatizar a criação e gerenciamento de boletos daFaculdade ABC em um ambiente WEB, visando facilitar o uso e a otimização doprocesso de criação de boletos, eliminando as filas na central de atendimento paraos 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 alunomais cômoda e ágil, os boletos serão gerados automaticamente e disponibilizadosem ambiente WEB. Estarão disponíveis no portal da Faculdade ABC medianteautenticação do aluno, onde será possível visualizar e imprimir seus boletos e teracesso a recursos adicionais como demonstrativo para imposto de renda (IR).
  14. 14. 14 1.5. Organização do Trabalho O primeiro capítulo refere-se ao contexto do trabalho, o tema, os objetivosda monografia em apresentação. O segundo capítulo realiza a apresentação da empresa, qual é o seu ramode negócio e como ela está organizada. O terceiro capítulo apresenta o cronograma das atividades dedesenvolvimento dessa monografia, sinalizando os prazos para a finalização dotrabalho. O quarto capítulo descreve o referencial teórico, todas as fontes de pesquisade ferramentas, tecnologias e metodologias que serão utilizadas para odesenvolvimento do sistema e escrita da monografia. No quinto capítulo, é apresentada a proposta, a descrição, os resultados, asrestrições e as áreas afetadas pelo sistema que será desenvolvido. No sexto capítulo é apresentada a descrição e identificação dos atores ecasos de uso do sistema. Como também, a apresentação das principais telas dosistema e suas funcionalidades. O sétimo capítulo descreve as atividades desempenhadas para aimplantaçã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 bibliografiasque deram sustentação e base ao desenvolvimento deste trabalho.
  15. 15. 152. Análise Institucional Neste capítulo trataremos da análise institucional da Faculdade ABC, suahistória e seus objetivos bem como seu ramo de negócio, com o objetivo de abstrairos conhecimentos necessários para entender suas necessidades perante aconstruçã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 filialestabelecida em Brasília – Asa Norte, podendo ser classificada como de médioporte. A Faculdade ABC faz parte de uma rede com matriz no Paraná e com váriasfiliais em diferentes estados da federação. O quadro de funcionários é da própriaFaculdade 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 usadopara representar as relações hierárquicas dentro de uma empresa, ou simplesmentea 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ãoo organograma se tornou uma ferramenta fundamental para as organizações, poisalém de facilitar a todos conhecer como funcionam as relações da empresa e suaestrutura, permite inclusive, identificar alguns problemas ou, oportunidades demelhorias, através de sua análise. Na criação de um organograma deve-se levar emconsideração que ele é uma representação da organização em determinadomomento e, portanto pode mudar. Para isto ele deve ser flexível e de fácilinterpretação. Quando o organograma é bem estruturado ele permite aoscomponentes da organização saber exatamente quais suas responsabilidades, suasfunções e a quem devem se reportar.
  16. 16. 16 A imagem abaixo representa o organograma da empresa que se trata darepresentação gráfica da hierarquia da instituição. A presidência, as diretorias e os departamentos da empresa, estão dispostosda 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 deboletos e a forma com que serão disponíveis ao aluno. Partindo desta necessidade, torna-se necessário a criação de um sistemaweb 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 sistemaconcebido por terceiros e tem arquitetura cliente-servidor com sede dos dados noParaná o que torna por muitas vezes o acesso aos dados lentos bem comodependência total aos sistemas legados em sua sede.
  17. 17. 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 eimpressos para serem entregues aos alunos em sala ou conforme solicitação nacentral de atendimento. O Webclass é um sistema proprietário web que por sua vez utiliza um bancode dados próprio nos remetendo ao mesmo problema do Cathedra. É utilizado paramanter as funcionalidades acadêmicas da instituição, ou seja, é através dele que osprofessores lançam notas de freqüência dos alunos, que são feitas as consultaspara saber os aprovados do semestre, sendo também responsável pelo controle deturma e disciplinas. 2.4. Normas de Funcionamento Após análise, constata-se que, para o devido funcionamento de qualquerdos 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, ofuncionário deve ter acesso à rede interna da Faculdade, além de ser um professorou 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, sistemaoperacional Windows XP, todo o pacote Microsoft Office 2003; 5 impressorasLexmark T632 e, 5 scanner HP 5590.
  18. 18. 183. Cronograma Desenvolver o cronograma significa determinar as datas de início e fim paraas atividades do projeto. Se as datas de início e fim não forem reais, é improvávelque 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 IFevereiro 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. 19. 194. Referencial Teórico Para o desenvolvimento deste trabalho foram estudados os principaisconceitos do RUP (Rational Unified Process) para o uso das melhores práticas dedesenvolvimento de software moderno e a UML (Unified Modeling Language) para amodelagem do sistema. Foram colocadas em confronto diferentes linguagens de programação bemcomo diferentes bancos de dados para a verificação das vantagens e desvantagensda 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 é umadisciplina da engenharia que se ocupa de todos os aspectos da produção desoftware, desde os estágios iniciais de especificação do sistema até a manutençãodesse sistema, depois que ele entrou em operação. Segundo PRESSMAN (1995) a engenharia de software compreende umconjunto de etapas que envolvem métodos, ferramentas e os procedimentos. Essasetapas muitas vezes são citadas como paradigmas de engenharia de software. Umparadigma de engenharia de software é escolhido tendo-se como base a naturezado projeto e da aplicação, os métodos e as ferramentas a serem usados, oscontroles e os produtos que precisam ser entregues. Segundo FILHO (2001) as máquinas de tratamento de informação sãoorganizadas em estruturas úteis, formando os sistemas de informática. Ainda segundo PRESSMAN (1995) a engenharia de software é um rebentoda engenharia de sistemas e de hardware. Ela abrange um conjunto de trêselementos fundamentais que possibilitam ao gerente o controle do processo dedesenvolvimento do software e oferece ao profissional uma base para a construçãode software de alta qualidade produtivamente, são eles: Métodos: proporcionam os detalhes de “como fazer” para construir osoftware. Ferramentas: proporcionam apoio automatizado ou semi-automatizado aosmétodos.
  20. 20. 20 Procedimentos: constituem o elo que mantém entre os métodos e asferramentas e possibilita o desenvolvimento racional e oportuno do software decomputador. Ainda segundo FILHO (2001) o software é a parte programável de umsistema de informática. Ele é um elemento central que realiza estruturas complexase flexíveis que trazem funções, utilidade e valor ao sistema. Mas outroscomponentes são indispensáveis: as plataformas de hardware, os recursos decomunicação e informação, os documentos de diversas naturezas, as bases dedados e até os procedimentos manuais que se integram aos automatizados. 4.1.1. Modelos Prescritivos Conforme PRESSMAN (1995) os modelos prescritivos de processo definemum conjunto distinto de atividades, ações, tarefas, marcos e produtos de trabalhoque são necessários para fazer engenharia de software com alta qualidade. Essesmodelos de processos não são perfeitos, mas efetivamente fornecem um roteiro útilpara o trabalho de engenharia de software. 4.1.1.1. Modelo Cascata Segundo SOMMERVILLE (2003) o modelo cascata considera as atividadesde especificação, desenvolvimento, validação e evolução, que são fundamentais aoprocesso, e as representa como fases separadas do processo, como aespecificação de requisitos, o projeto de software, a implementação, os testes eassim por diante. À medida que para PRESSMAN (1995) o modelo cascata é o modelo deciclo de vida clássico e requer uma abordagem sistemática, sequencial aodesenvolvimento do software, que se inicia no nível do sistema e avança ao longoda análise, projeto, codificação, teste e manutenção. Modelado em função do ciclode engenharia convencional, o paradigma do ciclo de vida abrange as seguintesatividades:
  21. 21. 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 sistemaslevam em conta que uma vez que o software sempre faz parte de um sistema maisamplo, o trabalho inicia-se com o estabelecimento dos requisitos para todos oselementos do sistema e prossegue com a atribuição de certo subconjunto dessesrequisitos 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 quatroatributos distintos do programa: estrutura de dados, arquitetura de software, detalhesprocedimentais 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 derealizaçã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 forentregue ao cliente. Ocorrerão mudanças porque erros foram encontrados, porque osoftware deve ser adaptado a fim de acomodar mudanças em seu ambiente externoou porque o cliente exige acréscimos funcionais ou de desempenho.
  22. 22. 22 4.1.1.2. Prototipação Segundo CUNHA (2007) Protótipo é a primeira versão desenvolvida dosoftware, 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 doprotótipo, clientes e desenvolvedores ficam em constante interação, facilitandoassim o levantamento de requisitos e funcionalidades do sistema. Algunsdesenvolvedores utilizam prototipações que são descartadas, ou seja, odesenvolvimento do sistema somente será iniciado após o término dodesenvolvimento do protótipo. Esses métodos de prototipações geralmente elevam ocusto do sistema, pois são feitos dois projetos separados, um do protótipo e outro dosistema final. Conforme PRESSMAN (1995) como todas as abordagens aodesenvolvimento 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çãodaqueles aspectos do software que serão visíveis ao usuário. O projeto rápido leva aconstrução do protótipo que é avaliado pelo cliente/usuário e é usado para refinar osrequisitos para o software a ser desenvolvido. Idealmente, o protótipo serve comoum mecanismo para identificar os requisitos do software. Ainda conforme CUNHA (2007) essa separação entre o desenvolvimento doprotótipo e do sistema final vem diminuindo a cada dia, com o uso da prototipaçãoevolutiva, a qual será o objeto de estudo deste artigo que terá como objetivo mostraras vantagens e desvantagens da utilização deste método no desenvolvimento desistemas de informação. Ainda segundo PRESSMAN (1995), a prototipação é um processo quecapacita o desenvolvedor a criar um modelo de software que será implementado. Omodelo pode assumir uma das três formas: (1) um protótipo em papel ou modelo baseado em PC que retrata a interaçãohomem-máquina de uma forma que capacita o usuário a entender quanta interaçãoocorrerá; (2) um protótipo de trabalho que implementa algum subconjunto da dosoftware desejado; ou
  23. 23. 23 (3) um programa existente que executa parte ou toda a função, mas que temoutras características que serão melhoradas em um novo esforço dedesenvolvimento. 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 oprocesso de software como uma sequência de atividades com algum retorno deatividade para outra, o processo é representado como uma espiral. Cada loop naespiral representa uma fase do processo de software. Assim, o loop mais internopode estar relacionado à viabilidade do sistema; o loop seguinte, à definição dosrequisitos 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 foidesenvolvido para abranger as melhores características tanto do ciclo de vidaclá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 representaa espiral define quatro importantes atividades representadas pelos quatrosquadrantes (figura 4): Planejamento: determinação dos objetivos, alternativas e restrições. Análise dos riscos: análise de alternativas e identificação/resolução dosriscos. Engenharia: desenvolvimento do produto no “nível seguinte”.
  24. 24. 24 Avaliação feita pelo cliente: avaliação dos resultados da engenharia. Um aspecto particular se torna claro quando consideramos a dimensãoradial descrita. A cada iteração ao redor da espiral (iniciando-se do centro), versõesprogressivamente 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 usualmenteaplicam desenvolvimento iterativo e evolutivo num tempo limitado, empregamplanejamento adaptativo, promovem entrega incremental e incluem outros valores epráticas que encorajam a agilidade – resposta rápida e flexível à modificação. Segundo PRESSMAN (1995) a engenharia de software ágil combina umafilosofia e um conjunto de diretrizes de desenvolvimento. A filosofia encoraja asatisfação do cliente e a entrega incremental do software logo de início; equipes deprojeto pequenas, altamente motivadas, métodos informais; produtos de trabalho de
  25. 25. 25engenharia de software mínimos e simplicidade global do desenvolvimento. Asdiretrizes de desenvolvimento enfatizam a entrega em contraposição à análise e aoprojeto (apesar dessas atividades não serem encorajadas) e a comunicação ativa econtí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 principaispapéis de pessoas e a forma de trabalho do time. O nome SCRUM é derivado deuma 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 praum 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 pilarescontém outros sub-itens. Todas estas três partes principais são utilizadas no quechamamos de ciclo de desenvolvimento, ou seja, o Sprint. Cada Sprint possui suasfases 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 quefoi desenvolvido por Jeff Sutherland e por sua equipe no início da década de 90. Osprincípios do SCRUM são usados para guiar atividades de desenvolvimento dentrode 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 detrabalho ocorrem dentro de um padrão de processo chamado sprint. O trabalhoconduzido dentro de um sprint é adaptado ao problema em mãos e é definido, efreqüentemente, modificado em tempo real pela equipe SCRUM. Ainda conforme CISNEIROS (2009) a idéia do SCRUM é justamente definirpapéis bem específicos para as pessoas envolvidas no projeto e como cada pessoavai jogar, ou seja, o que cada uma vai ter que fazer para o time seguir em frente nojogo: que no nosso caso é o próprio desenvolvimento do software. Em geral e de forma reduzida, esta metodologia funciona da seguinte forma:
  26. 26. 26 1. O produto é definido: quais são os seus requisitos? O que realmente ocliente quer? O responsável por esta tarefa é o que chamamos de Proprietário doProduto (Product Owner, em inglês). 2. O Proprietário do Produto define quais são as funcionalidades doprograma que mais importam, criando assim o que chamamos de Product Backlog. 3. Com as prioridades definidas, uma pessoa é definida para ser oScrumMaster, uma espécie de coordenador do projeto. O ScrumMaster, junto com oProprietário do Produto e o Time de desenvolvimento definem o que chamamos deSprints. 4. Cada Sprint possui uma parte de todo o Product Backlog, e devem sertrabalhados de acordo com as prioridades definidas no Product Backlog. Os Sprintsdevem ser preparados de uma forma de que durem de 2 a 4 semanas, e que no finalde cada período tenham um produto apresentável para o cliente. 5. Os Sprints vão sendo feitos até o Product Backlog acabar e oProprietário do Produto definir que o projeto está pronto. Mas isso não quer dizerque novas funcionalidades não podem ser incluídas: basta ir adicionando no ProductBacklog e realizando outros Sprints. Durante os passos reais de desenvolvimento, os Sprints, a principalferramenta de medição de desempenho é o Burndown Chart, que é uma dascaracterísticas mais especiais do SCRUM e que o torna um grande diferencial, nosentido positivo. O fluxo global do processo é ilustrado na Figura 5. Figura 5 - Ciclo de vida do Scrum Fonte: PRESSMAN (1995)
  27. 27. 27 4.1.2.2. XP (Extreme Programming) Para os autores KUHN e PAMPLONA (2009), XP é uma metodologia paradesenvolvimento de software ágil, com qualidade e que atenda as necessidades docliente. Alguns praticantes definem a XP como a prática e a perseguição da maisclara simplicidade, aplicado ao desenvolvimento de software, voltada para projetoscujos requisitos mudem com frequência, utilizem desenvolvimento orientado aobjetos, equipes de até 12 desenvolvedores e desenvolvimento incremental. A XPBusca o máximo de valor a cada dia de trabalho da equipe para o seu cliente. Emum curto espaço de tempo o cliente terá um produto utilizável, podendo aprendercom o mesmo e reavaliar se o que foi desenvolvido é realmente o desejado. Ainda conforme KUHN e PAMPLONA (2009) Por ser uma metodologiarecente, a XP sofre mudanças em suas concepções e, portanto, é comum encontrarvariaçõ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 autilização desta metodologia. A XP é organizada em torno de um conjunto de práticas e valores que atuamperfeitamente 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ápidapela manhã), programação em par, refactoring (melhorar o código), desenvolvimentocoletivo e guiado por testes, código coletivo, padrões para desenvolvimento, designsimples, 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 objetoscom seu paradigma de desenvolvimento padrão. O XP inclui um conjunto de regrase 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 mostraalgumas das idéias chave e tarefas que estão associadas a cada atividade dearcabouço.
  28. 28. 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 integradospara formar um todo coeso. É o modo pelo qual o edifício se ajusta ao seu ambientee se mistura com os outros edifícios vizinhos. É o grau como que o edifício alcançasua 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 engenheirode software analisar a efetividade do projeto em satisfazer a seus requisitosdeclarados, considerar alternativas arquiteturais em um estágio em que fazermodificações do projeto é ainda relativamente fácil, e reduzir os riscos associados àconstrução do software.
  29. 29. 29 4.2. Linguagem de Programação Segundo SEBESTA (2002) os computadores são usados em uma infinidadede diferentes áreas, desde o controle de usinas elétricas à armazenagem deregistros de talões de cheques pessoais. Por causa dessa grande diversidade noseu espaço, linguagens de programação com metas muito diferentes têm sidodesenvolvidas. Para os autores VILLAS e VILLABOAS (1987) o computador é uma máquinacapaz de efetuar cálculos. Foi inventado porque era necessário realizar muitoscá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çãoorientada a objetos que começou a ser criada em 1991, na Sun Microsystems. Teveinicio com o Green Project, no qual os mentores foram Patrick Naughton, MikeSheridan, e James Gosling. Este projeto não tinha intenção de criar uma linguagemde programação, mais sim de antecipar a “próxima onda” que aconteceria na áreada 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 interfacesnas aparências de sites na internet, com isso foi forçando o HTML a evoluir para terum 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 como usuário, com base nesse e outras necessidades que foi necessário criar umaferramenta que pode interagir com usuário, o Javascript. Os projetistas da empresaNetscape criaram o Javascript com o objetivo de controlar o navegado e acrescentarinteresses e interatividade ás paginas da Web. O Javascript que pode ser usadocomo já foi dito para aumentar a interatividade de paginas Web, mesmo tento omesmo nome de outra linguagem JAVA não tem nada de igual, o Javascript tevepropósito de diversificar os conteúdos de uma paginar da Web, diferente daLinguagem Java que inicialmente foi desenvolvida para maquinas eletrônicas e comoutros objetivos.
  30. 30. 30 Segundo HORSTMANN (2005) o Java além da sua própria linguagemtambém possui uma rica biblioteca, que torna possível escrever programas portáteisque podem ser executados em diversos sistemas operacionais mesmo queproprietários. Sua biblioteca inclui pacotes para gráficos, projeto de interfaces com ousuário, criptografia, redes, som, armazenamento de bancos de dados e muitosoutros propósitos. 4.2.2. PHP (Personal Home Page Tools) Segundo JUNIOR (2001) o PHP foi elaborado por Rasmus Lerdorf no anode 1994 , o PHP na época chamado de Personal Home Page Tools (Ferramentaspara Home Pages Pessoais) utilizados na primeira versão para consultar o currículoonline. A linguagem fazia interpretação bem simples, que entendia alguns macrosespeciais de alguns utilitários de uso comum nas homepages. Em meados de 1995, o interpretado foi reescrito e batizado de PHP/FIVersion 2.0 O sufixo FI foi elabora por Ramus, que fazia interpretação dos dados deformulários HTML, ele combinou os scripts das ferramentas para homepages e comointerpretador de formulários e adicionou o suporte ao MySQL, então estava criado OPHP/FI. Já em 1996 já avia mais de 15.000 paginas Web utilizando a linguagemPHP/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 ecom uma pequena ajuda de uma equipe mais organizada. O interpretador foireescrito do zero por Zeey Suraski e Andi Gutemns, esse novo interpretador foi abase 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çãomodular e o módulo básico é denominado unidade. Para compilar um programa emDelphi, é preciso um arquivo-fonte de programa e quaisquer unidades adicionais naforma de fonte ou objeto.
  31. 31. 31 O Delphi é utilizado para aplicativos rápidos, adequado para criação deprotótipos do Windows e aplicativos profissionais que competem em velocidade eeficiência. Delphi inclui poderosos recursos orientados a objeto, sem tornar alinguagem muito complicada, permite a criação de aplicações para sistemasoperacionais. Conforme LISCHNER (2000), Delphi possui três variedades de diretivas decompilador: chaves, parâmetro e compilação condicional. Uma chave é um flagBooleano: Um recurso pode estar ativado ou desativado. Um parâmetro ofereceinformações, como um nome de arquivo ou o tamanho da pilha. A compilaçãocondicional lhe permite definir condições e compilar seletivamente partes de umarquivo-fonte dependendo das condições definidas. Um programa em Delphi ésemelhante a um programa do Pascal tradicional, no entanto, os programas emDelphi 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) umsistema de banco de dados é uma coleção de dados inter-relacionados e umconjunto de programas que permitem o usuário acessar e modificar esses dados. Uma importante finalidade de um sistema de banco de dados é fornecer aosusuários uma visão abstrata dos dados, ou seja, o sistema oculta certos detalhes decomo os dados são armazenados e mantidos. 4.3.1. Oracle Conforme visão de ABBEY, COREY e ABRAMSON (2000), Oracle é umaferramenta potente que além de fazer gerenciamento de informações tambémpossibilita integrações com outras ferramentas das empresas da mesma área.Também existem aplicações de desenvolvimento para web e ferramentas paradesenvolver várias etapas na construção de sistemas. No Oracle há aplicativosflexíveis de alto desempenho de fácil manutenção com quase nenhum trabalho.
  32. 32. 32Entre outros aplicativos destaca-se também um aplicativo usado na modelagem decomponentes de sistema, entre aplicativos de desenvolvimento de alta escala. Conforme RAMALHO (1999) Oracle Server é um sistema de gerenciamentode 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. Comoessas estruturas no servidor são separadas, o armazenamento dos dados pode sergerenciado sem afetar o acesso às estruturas lógicas de armazenamento. Ainda segundo ABBEY, COREY e ABRAMSON (2000) o Oracle tambémnão deixa a desejar na questão de segurança e acessibilidade, o sofisticadomecanismo de segurança da Oracle controla o acesso aos dados sigilosos atravésdo uso de uma variedade de privilégios e através de perfiz entre usuários eadministradores separando os dados proibidos dos sigilosos e dando autorizaçãosomente aos usuários específicos. A Oracle também dispõe de muitasfuncionalidades relativas a acessibilidade o que ajuda a armazenar e manter osdados, com o utilitário de backup e restauração, e como todos SGBD a Oraclecontrola a integridade de dados. Segundo PACIEVITCH (2000), Oracle é um sistema de banco de dados quesurgiu no final dos anos 70, criado por Larry Ellison. Visava desde o início ser umbanco de dados relacional, o que, na época ainda não havia sido feito por nenhumaoutra 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 Departamentode Ciência da Computação da Universidade da Califórnia em Berkeley. OPOSTGRES foi pioneiro em vários conceitos que somente se tornaram disponívelmuito mais tarde em alguns sistemas de banco de dados comerciais. O PostgreSQL é um descendente de código fonte aberto deste códigooriginal de Berkeley. É suportada grande parte do padrão SQL:2003, além de seremoferecidas muitas funcionalidades modernas, como:
  33. 33. 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 muitasmaneiras 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 edistribuído por qualquer pessoa para qualquer finalidade, seja privada, comercial ouacadêmica, livre de encargos. Segundo EISENTRAUT (2011), PostgreSQL é um sistema de bancos dedados relacional poderoso e de código aberto. Ele possui mais de 15 anos dedesenvolvimento ativo e uma arquitetura que ganhou uma forte reputação econfiabilidade e integridade dos dados. 4.3.3. MySQL Segundo JUNIOR (2001) o MySQL é um servidor de banco de dadosmultiusuário e multitarefa, que trabalha com uma das linguagens de manipulação dedados 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 comsegurança e rapidez. Ela foi desenvolvida pelo Departamento de Pesquisas da IBMcom forma de interface para o Sistema de Banco de Dados Relacionadis SYSTEM
  34. 34. 34R, no início dos anos 70; em 1996, a American National Institute (ANSI) publicou umpadrão SQL. A SQL estabeleceu-se como linguagem padrão de Banco de DadosRelacional. A linguagem SQL tem como grande virtude a capacidade de gerenciaríndices sem a necessidade de controle individualizado no índice corrente, agobastante comum nos Sistemas Gerenciadores de Arquivos, como Dbase porexemplo. O MySQL foi originalmente desenvolvido pela empresa sueca TCX, quenecessitava de um servidor de banco de dados que operasse com grandes escalasde dados rapidamente sem exibir caríssimas plataformas de hardware. A TCX operadesde 1996 com 40 bancos de dados, contendo 10.000 tabelas, sendo 500 delascom 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 dediferentes compiladores; • O cliente conecta no MySQL através de conexão TCP/IP. Para PACIEVITCH (2010), esse SGBD possui interface simples, e também acapacidade de rodar em vários sistemas operacionais, o que são alguns dos motivospara este programa ser tão usado atualmente. 4.4. RUP (Rational Unified Process) Segundo KRUCHTEN (2003), o Rational Unified Process é um processo deengenharia de software que fornece uma abordagem para assumirresponsabilidades dentro da organização. O RUP na sua concepção, tem objetivo deassegura dentro da construção do software a entrega do projeto nas conformidades
  35. 35. 35que o cliente estabeleceu, na medida em que o software seja entregue na altaqualidade satisfazendo dentro dos requisitos as necessidades do cliente. O processo RUP é um processo é um produtor de processo. É desenvolvidoe mantido pela Rational Software e integrado com seus conjuntos de ferramentas dedesenvolvedores de software. O Rational Unified Process é um método que pode adaptar a estruturas daorganização que esteja usando. O Rational Unified Unified Process captura muitasda melhores práticas no desenvolvimento de software de forma satisfatória para umagrande faixa de projeto e organizações. Conforme Hermano (2003), o RUP é um conjunto de métodos e práticas dedesenvolvimento, ele define o que fazer e quando fazer. Ainda segundo ele asatividades do RUP são bem definidas, possuindo ordem de execução com descriçãode como essas ordens devem ser realizadas. Diz ainda que o RUP é umaabordagem da orientação a objeto e utiliza a notação UML (Unified ModelingLanguage). A figura 7 mostra as fases e os processos do RUP, mostra também que suasetapas estão divididas em quatro fases: concepção, elaboração, construção etransição. Figura 7 - Arquitetura Geral do RUP (Gráfico de Baleia) Fonte: RUP (2009)
  36. 36. 36 4.4.1.1. A Fase de Iniciação (ou Concepção) Segundo Martins (2004), os envolvidos devem chegar a um acordo emrelaçã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 vidapara o projeto. Os objetivos primários da fase de iniciação incluem: estabelecer aextensão de software do projeto e limitar condições; discriminar os dados de usocríticos do sistema; exibir, e talvez demonstrar, pelo menos uma arquiteturacandidata contra alguns dos cenários primários; estimar o custo global e programaro programar o projeto inteiro; e estimar os riscos. Segundo PRESSMAN (1995) esta fase abrange atividades de comunicaçãocom 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 daarquitetura do sistema é proposto e um plano para a natureza iterativa e incrementaldo 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 maisdetalhada os planos do projeto, revisar e resolver todos os riscos do projeto e assimassegurar que a arquitetura escolhida suportará todos os requisitos estabelecidos.Todas as indagações deverão ser esclarecidas e também deverá ser desenvolvida eavaliada a estabilidade da arquitetura do projeto, isso através de um ou maisprotótipo de arquitetura. Segundo KRUCHTEN (2003) o propósito da fase de elaboração é analisar odomínio de problema, estabelecer uma fundação arquitetônica sadia, desenvolver oplano de projeto e eliminar os elementos de alto risco do projeto. Nesta fase umprotó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, esteesforço deveria endereçar os casos de uso críticos identificados na fase deconcepção, que tipicamente expõe os riscos técnicos principais do projeto. Osprincipais objetivos desta fase compreendem: definir, validar e delinear a arquitetura
  37. 37. 37tão rápido quanto possível de ser realizada; delinear a visão; delinear um plano dealta-fidelidade para a fase de construção; e demonstrar que a arquitetura de linha debase 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 oscomponentes restantes e características de aplicação são desenvolvidos eintegrados ao produto, e todas as características são completamente testadas. Afase de construção é, de certo modo, um processo industrial no qual é colocadaênfase em gerenciar recursos e controlar operações para aperfeiçoar custos, prazose qualidade. De certo modo, o quebra-cabeça do gerenciamento sofre uma transiçãodo desenvolvimento de propriedade intelectual durante a concepção e a elaboraçãopara o desenvolvimento de produtos para distribuição durante a construção etransição. Os principais objetivos desta fase consistem em: minimizar custos dedesenvolvimento, aperfeiçoando recursos e evitando fragmentar e refazerdesnecessário; alcançar a qualidade adequada tão rápida quanto possível de serrealizada; 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 dodesenvolvimento, onde a meta é analisar todos os requisitos que ainda restam. Dáuma ênfase maior no gerenciamento de componentes e no controle de operaçõespara que se obtenha qualidade, otimização dos lucros e programações, é tambémnesta 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 desoftware à 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. 38. 38 Entra-se nesta fase quando uma linha base é madura suficiente para serdistribuída no domínio de usuários finais. Isso significa que algum subconjuntoutilizável do sistema foi completado a um nível aceitável de qualidade e aqueladocumentação de usuário está disponível, de forma que a transição para o usuáriofornecerá resultados positivos para todas as partes. Esta fase inclui: teste beta para validar o sistema novo contra expectativasdo 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 emantenedores; e saída do produto para o marketing, distribuição e equipes devendas. 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 queestão completas e consistentes com os critérios de avaliação da visão; e alcançar alinha 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 osistema para o usuário final, nesta fase também inclui atividades de treinamentospara os usuários para que eles possam compreender o sistema, realizações de testedas 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 1979com o Smalltalk, se popularizou apenas na década de 90, quando surgiram ospadrões de camada. O foco principal do MVC é fazer a separação nas camadas dedesenvolvimento, fazendo assim com que os problemas e ajustes sejam resolvidoscom uma facilidade maior. Seria o mesmo que dividir as responsabilidades naaplicação e a característica do MVC é que ele aumenta a flexibilidade e reutiliza ocódigo-fonte. Segundo MARTINS (2009), o MVC (Model View Controller) foi desenvolvidoutilizando 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 oseu estado. A visão gerencia a saída gráfica, ela especifica como os dados do
  39. 39. 39modelo 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, issoocorre de acordo com as ações do usuário. Conforme LACKEY a programação em MVC separa sua aplicação em trêspartes 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 pacotesmodulares de rápido desenvolvimento. Elaborar tarefas divididas entre models,views e controllers faz com que sua aplicação fique leve e independente. Novasfuncionalidades são facilmente adicionadas e pode-se dar nova cara nascaracterísticas antigas num piscar de olhos. O design modular e separado tambémpermite aos desenvolvedores e designers trabalharem simultaneamente, incluindo ahabilidade de se construir um rápido protótipo. A separação também permite que osdesenvolvedores 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 aobjetos. Desde os primeiros conceitos da orientação a objetos, diversos métodos
  40. 40. 40foram apresentados à comunidade (cerca de 50 no período de 1989 e 1994), ondegrande parte tendia aos métodos estruturados. Com o passar do tempo cadamé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 nomercado eram: Booch’93, OMT-2 e OOSE (Object-oriented software engineering).Todavia, apesar das semelhanças, existiam pontos significativos e fortes em cadamétodo. Conforme GUEDES (2005), a UML é uma linguagem visual utilizada paramodelar softwares baseados no paradigma da orientação a objetos. É umalinguagem de modelagem de propósito geral que pode ser aplicada a todos osdomínios de aplicação. A UML não é uma linguagem de programação, e sim umalinguagem de modelagem, uma notação, cujo objetivo é auxiliar os engenheiros desoftware a definirem as características do sistema. Ainda segundo MELO (2004) resumidamente, o OOSE possuía seu foco emcasos de uso (use cases), provendo excelente suporte à engenharia de negócios eanálise de requisitos. OMT-2 era expressivo na fase de análise dos sistemas deinformação. Booch’93 já se destacava na fase de projeto. Ao invés de seguir a linhados 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 aGeneral Eletric e se juntou à Grady Booch na Rational Software, no intuito de unirseus métodos (Booch e OMT). Em 1995 eles lançaram publicamente o rascunho deseu Método Unificado na versão 0.8. Nesta época, Jacobson se juntou à equipe e oprojeto 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 – UnifiedModeling Language. 4.6.1. Diagrama de Caso de Uso Conforme MATOS (2002), casos de uso (do inglês Use Case) são utilizadospara identificar as regras do negócio e são uma excelente forma de entender o pontode vista do usuário simplesmente pelo fato de que modela o que ele precisa
  41. 41. 41executar. Internamente, um caso de uso é uma sequência de ações que permeiam aexecução completa de um comportamento esperado para o sistema. Um caso de uso é apenas uma representação de uma função, manipuladapor uma entidade do sistema, conhecida como ator. Consoante LARMAN (2004) um diagrama de caso de uso é uma excelenteimagem 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 dosistema e seus atores. A figura 9 representa um diagrama de caso de uso, conforme os padrões daUML. Figura 9 - Diagrama de caso de uso Fonte: MATOS (2002) 4.6.2. Diagrama de Classes Segundo BOOCH, RUMBAUNGH e JACOBSON (2005) um diagrama declasses é um diagrama que mostra um conjunto de classes, interfaces ecolaborações e seus relacionamentos. Graficamente, um diagrama de classes éuma coleção de vértices e arcos. Um diagrama de classes é apenas um tipoespecial de diagrama e compartilha as mesmas propriedades de todos os outrosdiagramas. Conforme MATOS (2002) uma classe é uma abstração de um conjuntode 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. 42. 42 Figura 10 - Diagrama de Classes Fonte: MATOS (2002) 4.6.3. Diagrama de Interação Segundo BOOCH, RUMBAUNGH e JACOBSON (2005), o diagrama deinteraçã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ípicasde classes, interfaces, componentes e nós, juntamente com as mensagens que sãotrocadas entre eles, tudo isso no contexto de um cenário que ilustra umcomportamento. Diagramas de interações podem aparecer sozinhos para visualizar,especificar, construir e documentar a dinâmica de uma determinada sociedade deobjetos ou podem ser utilizados para refazer a modelagem de um determinado fluxode 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 noprocesso de execução das tarefas. Neste sentido, é necessária uma forma de modelar como essecomportamento dinâmico é conduzido. Programas orientados a objetos são, na verdade, constantes trocas demensagens. Em conjunto, essas mensagens colaboram na consecução de umdeterminado propósito. Os diagramas de interação são, portanto, a representaçãodo comportamento dinâmico que uma sociedade de objetos necessita ter para que aexecução de alguma tarefa seja executada. Na figura 11 um exemplo de um diagrama de interação.
  43. 43. 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 emcomo os objetos estão se organizando para efetuar uma tarefa. Consoante BOOCH, RUMBAUNGH e JACOBSON (2005) no contexto daarquitetura de um sistema, uma colaboração permite nomear um agrupamentoconceitual que abrange aspectos estáticos e dinâmicos. Uma colaboração nomeiauma sociedade de classes, interfaces e outros elementos que trabalham emconjunto para fornecer algum comportamento cooperativo maior do que a soma detodas as partes. 4.6.5. Diagrama de Estados e Atividades Segundo MATOS (2002), estados e atividades se complementam e, doponto de vista semântico, às vezes, podem confundir. No entanto, ambos têm umponto 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. 44. 44 Qualquer máquina de estados pretende avaliar os aspectos dinâmicos deuma 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 distintodo diagrama de atividades. Diagramas de estado preocupam-se em avaliar o comportamento dasinstâncias, ou seja, são avaliadas as possíveis sequências de ações por meio dasquais as instâncias procedem em reação aos eventos que lhe são apresentadosdurante a vida. Por outro lado, diagramas de atividades são uma extensão à idéiaoriginal das máquinas de estado, avaliando melhor as condições pelas quais asinstâncias chegam a determinadas decisões. 4.6.5.1. Desenho de um Diagrama de Estados Segundo BOOCH, RUMBAUNGH e JACOBSON (2005), um diagrama deestados mostra uma máquina de estados, dando ênfase ao fluxo de controle de umestado para outro. Conforme a visão de MATOS (2002) o ponto de partida para desenhar umdiagrama de estado é avaliar os atributos da instância em questão. Muitos atributospossuem um domínio de valores que permite o acompanhamento de possíveistransiçõ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. 45. 45 4.6.5.2. Desenho de um Diagrama de Atividades Conforme MATOS (2002), do ponto de vista de representação de aspectosdinâmicos do sistema, dois diagramas possuem características muito comuns: odiagrama de atividades e o diagrama de estados, porém o diagrama de atividadestrata-se de algo que está em execução, portanto não finalizado Quando umaatividade 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. 46. 46 Criar um sistema informatizado de ambiente WEB que trabalhará com osconceitos de internet, intranet e extranet para dividir os níveis de acesso destinadosa cada tipo de ator do sistema. A intranet terá a maior parte do sistema e todos os processos deverão serfeitos a partir da identificação do usuário, ou seja, mediante login e senha. O acessoserá local e terá como limite o espaço físico da instituição. Na extranet serão disponibilizadas funcionalidades onde os usuários nãoprecisem estar na instituição, o que não retira a necessidade de estar logado nosistema. Um exemplo para a finalidade do uso na extranet seria a necessidade de secompor diário de classe (presença/nota) por parte do docente Na internet de maneira geral será disponibilizado apenas funcionalidades deconsulta e solicitações, na maior parte realizadas pelo Aluno. Após análise e levantamento de requisitos se propõe os módulos descritos aseguir com suas respectivas funcionalidades: O módulo financeiro será responsável pelo controle de pagamentosefetuados 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 dealunos e professores, controlar todo o cadastramento de documentos utilizados pelainstituição além de observações referente aos alunos, cabe ainda, dispor algunsserviços como o de carteirinha estudantil, tudo isso, mantendo um histórico dealteraçõ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 porreceber a pauta, manter o diário de classe e controlar a criação de novas turmas nainstituição. Para manter os cursos da IES, criou-se o módulo Curso/Disciplina, que alémdesta funcionalidade terá de manter os Planos de ensino proposto para asDisciplinas, de manter a grade do curso e de fazer o relacionamento entre osProfessores e as Disciplinas. Com o objetivo atender as necessidades dos usuários do sistema, foi criadoo módulo Usuário, responsável por manter os Usuários e determinar seus perfisdentro do sistema, com o delegar a atividade dos mesmos dentro do sistema atravésde histórico de utilização e alteração do sistema.
  47. 47. 47 A biblioteca também será receberá um módulo, capaz de gerar boletosreferentes a multas por atrasos além de fazer todo o controle do acervo eempré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 frentesdistintas: internet, intranet e extranet com o objetivo de separar o acesso entre osatores do sistema. A tabela 2 reflete as principais diferenças entre as tecnologias que serãoutilizadas. Tabela 2 - Comparativo entre tecnologias INTERNET INTRANET EXTRANETAcesso RestritoComunicação InstantâneaComunicação ExternaCompartilhamento de ImpressorasCompartilhamento de DadosRede Local (LAN) 5.2. Resultados Esperados
  48. 48. 48 O sistema inicialmente terá um foco no cliente/aluno e com a utilização dosistema proposto se espera dar maior comodidade aos clientes/alunos bem comoreduzir 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 ogerente financeiro bem como funcionários do departamento financeiro, os quaisdeverão estar devidamente autenticados com senhas de acesso para fazer qualquertipo 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 formamais direta. Os alunos serão largamente beneficiados pela facilidade de uso e pelapossibilidade do acesso aos dados financeiros através da internet. O departamento financeiro terá toda a rotina e fluxo de trabalho revisto paraa implantação do novo sistema. A biblioteca será indiretamente afetada e fará uso da nova ferramenta domódulo financeiro para gerar boletos de cobrança no caso de atraso na devoluçãode livros, e por isso será beneficiada, onde até o momento não há controleautomatizado 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 paraaplicações de pequeno e médio porte, suporte a variadas linguagens deprogramação como o PHP, Perl, C, C++, Java e Pynthom, suporte a diferentesplataformas como Win32, Linux e Unix..
  49. 49. 49 Por ser uma ferramenta gratuita o MySQL, se tornou largamente usado nocenário atual possibilitando a formação de grandes referências sobre este banco dedados, além da formação de incontáveis profissionais capacitados a desenvolversistemas utilizando este banco de dados.6. Documentação de Análise
  50. 50. 50 Nesta seção serão descritos os atores do sistema, mostrando o papel decada um dentro do mesmo. Também será exibida uma lista dos casos de uso queserão implementados no sistema, assim como um diagrama contendo esses casosde uso, e por fim as suas especificações, sendo todos estes artefatos integrantes domó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 omó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, tendocontrole dos boletos de mensalidades/serviços e também gerar declaração deImposto de Renda. O Funcionário gerencia os boletos de alunos que são gerados a partir docontrato de matrícula gerados no módulo Ano Letivo, bem como os débitos geradosa 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ãoestará disponível. O administrador mantém os funcionários e gera relatórios de controle deboleto. 6.3. Listas de Casos de Uso
  51. 51. 51 Na tabela 3 estão listados os casos de uso do módulo financeiro do sistemaSISEDU. Tabela 3 - Lista de diagramas de caso de usoUC01 Manter BoletoUC 02 Gerar BoletoUC03 Calcular DébitosUC04 Negociar DívidaUC05 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. 52. 52 Tabela 4 - Manter BoletoNome UC01 – Manter BoletoObjetivo Cadastra dados do boleto bancárioAtores FuncionárioDados Consumidos Dados do BoletoDados Produzidos Regras do BoletoPrioridade AltaPré-condições N/APós-condições N/AFluxo PrincipalCadastrar Regras do BoletoAtor SistemaAcessar o botão cadastro de boleto Abrir formulário de cadastro de boletoInserir 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 sucessoReceber mensagemFluxo Alternativo 1Alterar BoletoAtor SistemaAcessar o botão listar no menu Boleto Exibir lista de boletos cadastradosClicar no botão alterar ao lado do boleto que Exibir dados do boleto escolhidodeseja realizar a alteraçãoRealizar 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 mensagemFluxo Alternativo 2Excluir Boleto

×