INSTITUTO FEDERAL DO PARANÁ PATRICIA DANNER SISTEMA DE GERENCIAMENTO DE CURSOS DE EXTENSÃO - PDF
INSTITUTO FEDERAL DO PARANÁ PATRICIA DANNER SISTEMA DE GERENCIAMENTO DE CURSOS DE EXTENSÃO
Download "INSTITUTO FEDERAL DO PARANÁ PATRICIA DANNER SISTEMA DE GERENCIAMENTO DE CURSOS DE EXTENSÃO"
Sandra Lopes Câmara
1 INSTITUTO FEDERAL DO PARANÁ PATRICIA DANNER SISTEMA DE GERENCIAMENTO DE CURSOS DE EXTENSÃO PARANAGUÁ 2012
2 PATRICIA DANNER SISTEMA DE GERENCIAMENTO DE CURSOS DE EXTENSÃO Trabalho de Conclusão de Curso apresentado ao curso de Informática - Ensino Médio Integrado do Instituto Federal do Paraná, como requisito parcial de avaliação Orientador: Wagner Rodrigo Weinert PARANAGUÁ 2012
3 A todos que acreditaram no meu potencial e participaram da minha formação.
4 AGRADECIMENTOS À minha família, pelo apoio e incentivo dados não apenas durante minha formação técnica, mas na vida. Ao Orientador, Professor Doutor Wagner Rodrigo Weinert, pela sugestão ao tema de TCC, pelo conhecimento que me passou e pelo comprometimento demonstrado. Aos meus amigos, pela companhia e pelos momentos de diversão dentro e fora da sala de aula. Ao Câmpus do IFPR Paranaguá em geral, onde evoluí muito durante os três últimos anos, graças a todos os professores que me deram, além de aulas, exemplos a serem seguidos, e às pessoas que conheci e passei a dividir novas experiências no decorrer do Ensino Médio, que com certeza carão marcadas em minha memória.
5 Resumo O Sistema de Gerenciamento de Cursos de Extensão é um sistema voltado ao controle dos cursos de extensão ministrados no Instituto Federal do Paraná - Câmpus Paranaguá. Como o sistema já foi previamente iniciado por alunos do câmpus, o objetivo desse trabalho é continuar e concluir a ideia inicial do projeto, que é a de auxiliar no controle dos cursos de extensão e das horas de Atividades Formativas Integradoras (horas AFINS) dos alunos. O sistema começou a ser desenvolvido para a plataforma web, para que tanto professores quanto técnicos administrativos utilizem. O sistema utiliza basicamente das linguagens PHP, HTML, CSS, JavaScript e MySQL, e em parte do paradigma orientado a objetos e da técnica AJAX. Inicialmente contava com o cadastro e gerência de matrículas, pessoas, cursos, salas, turmas, calendário, relatórios e usuários, que são subdivididos em dois níveis, professor e administrador. Neste trabalho primeiramente foi pensado em maneiras de melhorar o que já foi desenvolvido até então, para depois propor novos objetivos e enm instalá-lo no câmpus do Instituto. Palavras-chave: Programação Web. Sistema Gerenciador. PHP. Manutenção de Sites. Orientação a Objetos.
6 Abstract The Sistema de Gerenciamento de Cursos de Extensão is a system turned to the control of the extension courses given at Instituto Federal do Paraná - campus Paranaguá. As the system had already been iniciated by other campus students, the objective of this work is to continue and conclude the initial ideia of the project, which is to assist in the control of extension courses and at the students Formative Integrated Activities hours. The system started being developed for the web plataform, so either teachers and administrative technicals use it. The system uses basically the PHP, HTML, CSS, JavaScript and MySQL languages, the object-oriented paradigm and the AJAX technique. Initially, it had people, courses, rooms, classes, calendars, reports and users (who are subdivided in teacher and administrator users) registration and management. This work was rst thought in ways to improve what was already developed so far, so it would be possible to propose new goals and nally install it on the Institute campus. Key words: Web programming. Management System. PHP. Site Maintence. Objectorientation.
7 Sumário Lista de Figuras 1 INTRODUÇÃO E JUSTIFICATIVA p OBJETIVOS p Objetivos Gerais p Objetivos Especícos p FUNDAMENTAÇÃO TEÓRICA p ESTRATÉGIA DE TESTES p MANUTENÇÃO p Possíveis Problemas p ORIENTAÇÃO A OBJETOS p UML - UNIFIED MODELLING LANGUAGE p Diagrama de Casos de Uso p Diagrama de Classes p BANCO DE DADOS p Modelos de Banco de Dados p HTML HYPERTEXT MARKUP LANGUAGE p JAVASCRIPT p CSS CASCADING STYLE SHEETS p AJAX ASYNCHRONOUS JAVASCRIPT AND XML p PHP PERSONAL HOME PAGE p MYSQL p. 25
8 2.12 APACHE p METODOLOGIA p Preparação do Ambiente para a Implementação do Sistema p WampServer p NetBeans IDE (Integrated Development Environment)..... p O Estudo do Sistema Atual p Diagramas do Sistema p Diagramas Registrados da Documentação Anterior p Ajustes Realizados nos Diagramas p Itens Aprimorados p Demonstração da Nova Versão do Sistema p CONSIDERAÇÕES FINAIS p REFERÊNCIAS BIBLIOGRÁFICAS p ANEXOS p. 41 Anexo A -- Diagrama de Caso de Uso Anterior p. 42 Anexo B -- Diagrama de Classes Anterior p. 43 Anexo C -- Modelo Entidade-Relacionamento Anterior p. 44 Anexo D -- Modelo Relacional Anterior p. 45 Anexo E -- Diagrama de Caso de Uso Atual p. 46 Anexo F -- Diagrama de Classes Atual p. 47 Anexo G -- Modelo Entidade-Relacionamento Atual p. 48
9 Anexo H -- Modelo Relacional Atual p. 49 Anexo I -- Diagrama de Sequência p. 50 Anexo J -- Diagrama de Sequência p. 51
10 Lista de Figuras 1 Exemplo de Ator p Exemplo de caso de uso p Exemplo de associação p Exemplo de inclusão p Exemplo de extensão p Exemplo de classe p Exemplo de associação binária p Exemplo de agregação p Exemplo de composição p Exemplo de modelo entidade-relacionamento p Exemplo de modelo entidade-relacionamento (a) derivado para o modelo relacional (b) p Exemplo de documento HTML (a) interpretado pelo navegador (b).. p Exemplo de documento HTML com CSS (a) interpretado pelo navegador (b) p Demonstração sobre o que acontece ao acessar uma URL direcionada a uma página em PHP (retirado de Davis (2008)) p Interface antiga da página principal do sistema (a) comparada a interface nova (b) p Interface antiga do formulário de cadastro de turmas do sistema (a) comparada a interface nova (b) p Nova interface de controle de usuários (anteriormente inexistente)... p Modelo de certicado gerado ao fechar uma turma p Diagrama de Caso de Uso registrado na documentação anterior..... p. 42
11 20 Diagrama de Classes registrado na documentação anterior p Modelo Entidade-Relacionamento registrado na documentação anterior p Modelo Relacional registrado na documentação anterior p Diagrama de Caso de Uso atual p Diagrama de Classes atual p Modelo Entidade-Relacionamento atuall p Modelo Relacional Atual p Diagrama de sequência - matrícula de aluno p Diagrama de sequência - listagem de matrículas p. 51
12 11 1 INTRODUÇÃO E JUSTIFICATIVA Este trabalho propõe a manutenção e a conclusão de um sistema já criado em O sistema em questão é o SisGCE, ou Sistema de Gerenciamento de Cursos de Extensão, desenvolvido na disciplina de TCC do ano passado, pelos alunos Alan Willians de Oliveira e Allison Cristiano Lindner. O objetivo do sistema é organizar e agilizar o gerenciamento dos cursos de extensão que ocorrem durante o ano no Instituto Federal do Paraná - Câmpus Paranaguá. Atualmente não existe nenhum sistema informatizado para este m. O sistema é voltado para o ambiente acadêmico, ou seja, professores, alunos e técnicos administrativos. Os cursos de extensão acontecem como aulas extracurriculares, fazendo parte de um processo que envolve educação, cultura e ciência, articulando o ensino e pesquisa a comunidade escolar e do entorno da instituição. Como se trata do primeiro sistema voltado para essa área, e como não há outras bases de dados implantadas no Instituto, o SisGCE ainda não tem dependência com outros sistemas do Câmpus. Como atualmente não existe nenhum sistema utilizado para o controle dos cursos de extensão no câmpus, a organização, tanto dos docentes como dos discentes, se torna trabalhosa. Muitos alunos acabam perdendo seus certicados, que são requisitados no nal do curso, o que pode se tornar complicado de recuperar. Nem sempre os professores tem fácil acesso aos controles mantidos na época em que ministravam as atividades. A implantação de um sistema como esse no Câmpus deixaria o controle e a vericacão de informações muito mais fácil e eciente. 1.1 OBJETIVOS Objetivos Gerais Dar continuidade ao projeto, estudando e revisando o sistema a m de reestruturá-lo e deixá-lo o mais próximo possível do desejado, implantá-lo e disponibilizá-lo para uso no Instituto Federal do Paraná - Câmpus Paranaguá.
13 Objetivos Especícos Consertar problemas de lógica nas funções de: Cadastro de usuários: Não permitir que uma pessoa seja cadastrada mais de uma vez como Professor ou Administrador. Cadastro de turmas: Não permitir que uma turma seja cadastrada em um horário que interceda o horário de alguma outra turma já cadastrada; Fazer com que a programação da turma (calendário) seja feita junto com o cadastro; Permitir que uma turma possa iniciar e terminar no mesmo dia que outra turma. Fechar turma: Permitir que o administrador feche turmas somente após elas serem previamente fechadas pelo professor. Gerar relatório: Aprimorar a exportação de informações em arquivos PDF. Reestruturar a base de dados: Remover tabela "turmas fechadas" Adicionar um atributo na tabela Turmas que indique se ela está ativa ou não. Propor ajustes na interface do sistema: Substituir o menu "Matrículas"por "Cadastros", e nele criar submenus "Professores"e "Alunos". Remover o menu "Pessoas". Remover o botão "Salvar"da interface de listagem de salas. Implantar o sistema no Instituto, para uma fase de testes: Testar todas as funcionalidades do sistema para encontrar e corrigir possíveis novas falhas. Preparar o ambiente para realizar a instalação. Instalar o sistema para ser usado pelos usuários.
14 13 2 FUNDAMENTAÇÃO TEÓRICA 2.1 ESTRATÉGIA DE TESTES Pressman (2005, p. 786) arma que "a atividade de teste de software é um elemento crítico da garantia de qualidade de software e representa a última revisão de especicação, projeto e codicação". Com base nisso, pode-se entender que a fase de testes de um software é de extrema importância. É na fase de testes que são listados todos os problemas encontrados em um software. Essa fase consiste em executar um programa com a intenção de descobrir erros ainda não descobertos, podendo ser mais desaador quanto o projeto inicial do software. Existem duas abordagens de teste muito efetivas, e que serão seguidas nesse trabalho: a teste de caixa branca (white box) e a teste de caixa preta (black box). O teste de caixa branca ocorre quando o funcionamento interno do programa já for conhecido. O teste verica se todas as funções disponíveis estão sendo utilizadas e funcionando, testando os caminhos lógicos do software. Ele verica se todos os caminhos independentes tenham sido exercitados, assim como as decisões lógicas para valores falsos e verdadeiros, laçõs de repetição e estruturas de dados internas. O teste de caixa preta, diferentemente do teste de caixa branca, acontece quando a função especíca do software é conhecida, e deseja-se testar todas as funcionalidades do programa, de maneira a visar apenas a interface. Nesse teste é vericado se a integridade das informações são mantidas, assim como se os valores de entrada e saída são devidamente aceitos. O teste de caixa preta não se preocupa muito com a estrutura lógica interna do software: ele verica se as funções estão corretas, se há erros de interface, erros nas estruturas de dados, erros de desempenho e erros na inicialização ou término. Ambos testes são de grande proveito quando trabalhados juntos. O teste de caixa preta é um complemento para o teste de caixa branca, e vice-versa, já que os dois visam coisas diferentes que no nal atendem ao mesmo objetivo. Após a realização desses testes, é possível partir para a etapa de manutenção, onde todos os defeitos encontrados durante os testes podem ser resolvidos.
15 MANUTENÇÃO Para Pressman (2005, p. 876): "A manutenção de software foi caracterizada como um "iceberg". Ansiosamente, esperamos que aquilo que é imediatamente visível esteja lá de verdade. Realisticamente, sabemos que uma massa enorme de problemas e custos potenciais esconde-se sob a superfície(...)." Para alcançar os objetivos, eventualmente será preciso corrigir algumas funções do sistema. Isso pode ser visto como um tipo manutenção. De acordo com Júlio Xavier (2009), há três tipos de manutenção: preventiva, corretiva e preditiva. A Manutenção preventiva é o tipo de manutenção que previne futuros problemas no sistema. Nela são vistas as possíveis falhas que podem aparecer e gerar problemas futuramente. Na detecção de uma dessas falhas, o sistema é arrumado antes de ser implantado. Na manutenção corretiva, a manutenção ocorre quando a manutenção preventiva não conseguiu prever tudo o que poderia acontecer. Se algum problema aparecer, é realizada a manutenção que irá corrigir esse problema, como o nome já diz. Por m, na manutenção preditiva, a manutenção ocorre dentro de um determinado intervalo de tempo predenido, para fazer checagens sobre o funcionamento do sistema. A partir de uma manutenção preditiva pode-se determinar se há necessidade de ocorrer uma manutenção Possíveis Problemas Segundo Pressman (2005, p. 883), existem muitos problemas que podem aparecer durante a realização de uma manutenção de software. Entre esses problemas, os que mais se destacam são: Diculdade em entender o programa desenvolvido por outra pessoa. Não ter contato pessoal com o desenvolvedor anterior para esclarecimento de dúvidas, uma vez que existe muita rotatividade entre o pessoal da área de informática. Não existir nenhum tipo de documentação sobre o programa, ou se existir, ser ruim ou incompreensível. O programa desenvolvido não ser projetado para sofrer mudanças, dicultando o trabalho da manutenção.
16 15 Como o trabalho trata de um sistema que ainda não está em uso, o tipo de manutenção que se encaixa e será seguida nele será a preventiva. Para poder realizar essa manutenção, é necessário ter conhecimento sobre os conteúdos denidos nas próximas seções. 2.3 ORIENTAÇÃO A OBJETOS Segundo Pablo Dall'Oglio (2007, p. 86): "A orientação a objetos é um paradigma que representa toda uma loso- a para construção de sistemas. Em vez de construir um sistema formado por um conjunto de procedimentos e variáveis nem sempre agrupadas de acordo com o contexto, como se fazia em linguagens estruturadas, na orientação a objetos utilizamos uma ótica mais próxima do mundo real. Lidamos com objetos, estruturas que já conhecemos do nosso dia-a-dia e sobre as quais possuímos maior compreensão." Com base ainda em Dall'Oglio, para trabalhar com a programação orientada a objetos, deve-se entender o que são classes e objetos. Uma classe é uma estrutura de dados que contém métodos (funções) e atributos (variáveis). Um objeto é uma instância de uma classe, ou seja, a classe pode se transformar num objeto dinâmico que possibilita a manipulação de seus valores. Vários objetos podem ser originados de uma classe. Exemplicando: se fosse preciso criar um objeto pessoa, esse objeto poderia se referir a uma classe chamada Pessoa, e nessa classe poderiam existir atributos como nome, data de nascimento, CPF, e métodos como caminhar, falar, e dormir, por exemplo. Existem outros conceitos dentro da orientação a objetos, como herança e polimorsmo. Dall'Oglio (2007, p.99) também diz que na herança, "devemos levar em consideração (...) o compartilhamento de atributos e comportamentos entre classes de uma mesma hierarquia (árvore). As classes inferiores da hierarquia automaticamente herdam todas as propriedades e os métodos das classes superiores, chamadas superclasses." O polimorsmo usa o conceito de herança. Uma classe que deriva de uma superclasse pode ter seus mesmos métodos, mas que podem executar tarefas diferentes. Pode-se dar um exemplo disso no seguinte caso: duas classes,professor e Administrador, provêm da classe Pessoa ou seja, as classes Professor e Administrador possuem todos os métodos que a classe Pessoa tem. Mas apesar disso, as classes Professor e Administrador podem ter alguma alteração em uma dessas funções, que as tornem próprias de um professor e de um administrador. Para solucionar isso, é possível então sobrescrever os métodos da sua superclasse Pessoa, facilitando o desenvolvimento do algoritmo.
17 16 Após essa breve denição sobre Orientações a Objetos, no próximo tópico pode ser visto como funciona a UML, uma linguagem de modelagem de sistemas que está totalmente inserida nesse paradigma. 2.4 UML - UNIFIED MODELLING LANGUAGE Antes de colocar um projeto em prática, faz-se sua modelagem, que envolve vários tipos de estudos e planos. Quando modelamos um software, criamos diagramas que podem representar diversas funções. Essa diagramação é chamada de UML, ou Unied Modelling Language (Linguagem Unicada de Modelagem). A UML consiste numa padronização de notações que representam o funcionamento de um sistema Diagrama de Casos de Uso Sobre diagramas de casos de uso, Guedes (2006) arma que "apresenta uma linguagem simples e de fácil compreensão para que os usuários possam ter uma ideia geral de como o sistema irá se comportar." O Diagrama de Casos de Uso é um diagrama muito conhecido e utilizado, feito no início do projeto, onde apresenta uma ideia geral do comportamento do sistema. É formado principalmente de atores e casos de uso. Os atores representam elementos externos que irão interagir com o sistema. Podem ser, além de pessoas, outros hardwares e serviços. São representados por um boneco seguido de uma breve identicador, como mostrado na gura 1. Figura 1: Exemplo de Ator Os casos de uso representam serviços e funções do sistema que irão interagir com o usuário. São representados por uma elipse, com um texto descritivo dentro. A gura 2 mostra um exemplo de caso de uso. Para mostrar os tipos de relações entre os elementos de um diagrama de Casos de
18 17 Figura 2: Exemplo de caso de uso Uso, usa-se diferentes tipos de retas entre os elementos, podendo representar associações, inclusões, extensões e generalizações, como demonstrado a seguir: A associação, basicamente, demonstra relações entre atores e casos de uso. Quando essa relação é utilizada, demonstra que o ator faz algum uso da função representada no caso de uso. A gura 3 demonstra um exemplo de relação entre um ator e um caso de uso. Figura 3: Exemplo de associação A inclusão acontece entre dois casos de uso. Quando existe uma relação de inclusão entre esses casos de uso, signica que na execução de um, o outro também será, obrigatoriamente, executado. A gura 4 demonstra um exemplo de inclusão. Mostra que o diário de classe, ao ser acessado pelo professor, fará com que as opções consultar cursantes e consultar curso também sejam, automaticamente, executadas.
19 18 Figura 4: Exemplo de inclusão Na extensão as relações são muito parecidas com as relações de inclusão. As relações de extensão também acontecem entre dois casos de uso, mas representa que o caso de uso apontado não será necessariamente executado, será apenas uma opção para o usuário. A gura 5 exemplica casos de uso ligados através de uma relação de extensão: ao acessar a opção "consultar cursantes", o usuário poderá, se quiser, acessar as opções "alterar cursantes"e "excluir cursantes". Figura 5: Exemplo de extensão Diagrama de Classes O Diagrama de Classes serve para mostrar todas as classes que farão parte do sistema, contando com seus atributos, métodos, e relacionamentos. Ele serve de base para a construção da maioria dos diagramas da UML. As classes, como explicado anteriormente na seção sobre Orientação a Objetos, repre-
20 19 sentam uma estrutura de dados, um objeto. Um atributo representa uma característica desse objeto, e um método representa uma função, um conjunto de instruções que esse objeto pode executar. O diagrama de classes apresenta todas as classes que farão parte do sistema, contando com seus atributos, métodos, e relacionamentos. Segundo Gilleanes Guedes (2006), ele serve de base para a construção da maioria dos outros diagramas da UML. A gura 6 mostra como é uma classe representada na UML. É representada por um retângulo dividido em três partes, que indicam, respectivamente, o nome da classe, seus atributos e seus métodos. Figura 6: Exemplo de classe Como no diagrama de caso de uso, o diagrama de classes também tem relacionamentos, determinando que, de alguma maneira, existe algum tipo de compartilhamento de informações entre duas classes. As denições a seguir também seguem como base Gilleanes Guedes (2006, p ). A associação binária é o tipo de associação mais simples. Ocorre quando é identicado um relacionamento entre duas classes. A gura 7 mostra que um objeto da classe Turma se relaciona com apenas um objeto da classe Sala, e que um objeto da classe Sala pode se relacionar com um ou mais objetos da classe Turma. Figura 7: Exemplo de associação binária. Na agregação, a função principal é representar a obrigatoriedade de uma complemen-
21 20 tação de um "objeto-todo"por seu "objeto-parte". Na gura 8 podemos ver que a classe Infraestrutura armazena os objetos-todo e a classe Sala armazena os objetos-parte. Nesse caso é utilizada a agregação, pois "Sala"depende de Infraestrutura, mas não de maneira muito forte, porque Infraestrutura ainda não passa de um complemento. Figura 8: Exemplo de agregação. A relação de composição é parecida com a relação de agregação. A relação de composição é usada para mostrar que uma classe depende, com mais intensidade, de outra para existir. Usando a gura 9 como exemplo: Nessa composição, o objeto-parte (Curso) não pode se associar a mais de uma objeto-todo. Não faz sentido existir Curso se não existir Turma. Então se Turma deixar de existir, Curso"também irá deixar de existir. Figura 9: Exemplo de composição. O SisGCE possui integração com uma base de dados que, assim como o sistema em si, também passa pela etapa de modelagem antes de ser implementado. A próxima seção trata sobre os modelos utilizados para a representação do banco de dados. 2.5 BANCO DE DADOS Com o passar do tempo, achou-se necessário começar a subdividir as funções de um software, e com isso "camadas"começaram a aparecer. Nisso, surgiram os Sistemas de
22 21 Gerenciamento de Banco de Dados. Dentro de um sistema que trabalha com informações sobre usuários, como é o caso do SisGCE, é de bom proveito utilizar uma base de dados para o armazenamento e consulta de dados. Essa base precisa ser independente, ou seja, que ela não se restrinja a apenas um sistema: se, futuramente, outros sistemas surgirem, eles também poderão utilizar da mesma base de dados já existente no local Modelos de Banco de Dados Antes de criar um Banco de Dados, assim como criar algum outro software, é necessário fazer sua modelagem, para que se tenha noção do que é preciso implementar e de como deverá funcionar o sistema por m. Para isso, dois modelos foram utilizados na modelagem do Banco de Dados do SisGCE: o Modelo Conceitual e o Modelo Relacional. Segundo Carlos Alberto Heuser (1998, p. 6), o Modelo Conceitual apenas descreve o banco de dados, sem registrar como os dados estão armazenados a nível de SGBD. O modelo conceitual é o primeiro nível da modelagem. Ela se deriva da observação do mundo real, baseando-se na análise de requerimentos e especicações do sistema. O modelo conceitual geralmente é rotulado com o modelo entidade-relacionamento (MER). Nesse modelo exemplicado na Figura 10, constam duas entidades, com seus atributos e suas relações. Figura 10: Exemplo de modelo entidade-relacionamento. Entidades descrevem "coisas", objetos que têm suas próprias características, distinguível de outros elementos. Podem ser, por exemplo, pessoas ou locais. Atributos são informações sobre entidades. Podem ser determinante, quando o atributo representará um elemento da entidade (deve ter valor exclusivo); composto, quando necessário subdividi-lo, e multivalorado, quando pode assumir mais que um valor para cada instância. Para Heuser (1998), o modelo relacional, segundo nível na modelagem, deriva do
23 22 modelo conceitual. É a transformação do MER para um modelo mais próximo do SGBD real. É representado por tabelas, e seu detalhamento é maior. A Figura 11 demonstra um exemplo de uma entidade, no modelo entidade-relacionamento se transformando em uma tabela no modelo relacional. (a) (b) Figura 11: Exemplo de modelo entidade-relacionamento (a) derivado para o modelo relacional (b) 2.6 HTML HYPERTEXT MARKUP LANGUAGE Muitas pessoas confundem HTML com uma linguagem de programação. Isso não é verdade, pois HTML, como o próprio nome diz, é uma linguagem de marcação de hipertextos. Essa linguagem não possui comandos para tomadas de decisões, variáveis, estruturas de repetição, etc. As pessoas que trabalham com HTML são chamadas autores, não programadores. HTML é muito fácil de ser compreendido, mesmo para as pessoas que nunca tiveram contato com programação antes. Além de ser uma linguagem fácil de usar, também é uma linguagem fácil de ter acesso. É necessário apenas um editor de texto simples para editar o documento, e um navegador para fazer sua interpretação. De acordo com Leandro Campos (2004, p. 19), "Um documento HTML contém apenas informações sobre a forma como devem ser exibidos imagens na tela". O HTML tem como uso principal as chamadas tags, marcadores usados para a formatação do layout de uma página: são comandos especícos que delimitam o tipo de formatação nos elementos apresentados na página. Essas tags podem formatar fontes, cores, tamanho de imagens, títulos da página, entre várias outras coisas. A gura 12 mostra um exemplo da utilização do HTML. A gura 12(a) representa o documento no editor de texto, e a gura 12(b) representa o documento interpretado por um navegador.
24 23 (a) (b) Figura 12: Exemplo de documento HTML (a) interpretado pelo navegador (b) Como o HTML é uma linguagem um tanto limitada, existem recursos como a linguagem de programação JavaScript, que unida ao HTML, torna as páginas web bem mais funcionais. 2.7 JAVASCRIPT Segundo Adriano Lima (2006, p. 9), A linguagem JavaScript foi criada pela NetScape para trabalhar com aplicações junto a páginas HTML. JavaScript é uma linguagem de script de programação baseada na linguagem Java, mas que não suporta tantos tipos de dados como a linguagem Java. Ela é conhecida como uma extensão do HTML exatamente por ser embutida ao documento HTML para ampliar a usabilidade e a interação das páginas Web com o usuário. O JavaScript, ao contrário do HTML, é uma linguagem onde existe compilação. O programador pode inserir várias funcionalidades em sua página com a ajuda do JavaScript, como validações para formulário e comandos a serem executados dependendo da necessidade do usuário. 2.8 CSS CASCADING STYLE SHEETS CSS é um recurso muito útil ao HTML. O HTML, apesar de suas várias funções de formatação, ainda deixa a desejar quando o assunto é facilidade de padronização do estilo de layout. Em uma sistema como o SisGCE, existem várias interfaces de interação com o usuário. Isso faz com que toda vez que for necessário criar uma interface, será necessário documentar, de novo, seus padrões de estilo usando o HTML. Com o CSS é possível criar um "modelo"para que todas as outras páginas em HTML possam seguir o mesmo padrão de alinhamento, cores, e outras formatações. Esse modelo é chamado de estilo, que é
25 24 predenido de maneira que o autor quiser. A gura 13 mostra um exemplo de uso do CSS em um documento HTML. (a) (b) Figura 13: Exemplo de documento HTML com CSS (a) interpretado pelo navegador (b) 2.9 AJAX ASYNCHRONOUS JAVASCRIPT AND XML De acordo com o site de aprendizagem W3Schools, AJAX é uma técnica usada para criar páginas web rápidas e dinâmicas. AJAX não se trata de uma linguagem de programação, mas sim de um novo jeito de utilizar padrões já existentes. Entre esses padrões, estão o JavaScript (para mostrar e interagir com a informação), o CSS (para o estilizar os dados) e o XML (formato para a transferência de dados). Uma das utilidades do AJAX que torna páginas web mais interativas, é a atualização de conteúdos de uma página sem ter que recarregá-la por completo, coisa que acontece com páginas clássicas que não utilizam desse recurso. O AJAX se tornou muito popular com o passar do tempo, tanto que aplicações como Google Maps, Gmail, Youtube, e Facebook utilizam de seus recursos PHP PERSONAL HOME PAGE PHP é uma linguagem de programação voltada ao ambiente web. Segundo Pablo Dall'Oglio (2007, p. 20) Dentre as principais características do PHP estão a extensibili-
26 25 dade, possibilidade de conexão com vários bancos de dados, novos protocolos, uma sintaxe mais consistente e suporte a orientação a objetos. Com base nisso, Michele Davis e Jon Phillips (2008, p.2) armam: "PHP facilita o desenvolvimento da web porque todo o código necessário está contido na estrutura PHP. Isso signica que não há razão para que você reinvente a roda cada vez que se sentar para desenvolver um programa PHP; ele vem com funções web embutidas." PHP surgiu da necessidade das pessoas em criar e manter suas páginas na web que tivessem interatividade com seu servidor. O PHP não é uma linguagem de marcação como o HTML; ele soma e modica as saídas básicas do HTML após buscar no servidor a resposta da requisição pedida pelo usuário. O PHP tem facilidade em acesso a banco de dados, como por exemplo o MySQL, um sistema de gerenciamento de banco de dados open source muito popular MYSQL MySQL é um sistema de gerenciamento banco de dados desenvolvido desde os anos 80, e que se tornou mundialmente conhecido em Segundo seu site ocial, ele se tornou tão popular assim porque além de ser gratuito, tem alta performance e é fácil de usar. Para ter uma ideia de seu ecácia, grandes empresas como Google, Facebook, Adobe, Wikipedia e Nokia utilizam o MySQL, poupando tempo e dinheiro para fazer com que seus Web sites gigantes funcionem. MySQL também tem grande compatibilidade: ele funciona em em mais de 20 plataformas, incluindo Windows, Linux e Mac OS. MySQL é um banco de dados relacional. Segundo Davis e Phillips (2008, p. 4), "Um banco de dados relacional é uma coleção de tabelas, porém outros itens são frequentemente considerados parte do banco de dados, já que ajudam a organizar e estruturar os dados além de forçar o banco de dados a conformar-se com uma série de requisições" Para que haja "conversa"entre o banco de dados e o PHP, é necessário também prover de um servidor, como o Apache, explicado na próxima seção APACHE O servidor HTTP da Fundação de Software Apache, o Apache, é um servidor gratuito e o mais popular da Internet desde Segundo o site ocial da Apache, o objetivo do projeto desse servidor é prover segurança, eciência e fornecer extensos serviços HTTP.
27 26 Um servidor web serve para transformar requisições dos navegadores em resultados em páginas web, processados, por exemplo, a partir de um código PHP. Sem um servidor web como o Apache, seria impossível, para os usuários web, alcançar as páginas solicitadas via navegador. A gura 14 exemplica como ocorre uma série de eventos durante uma requisição de dados de uma página web. Figura 14: Demonstração sobre o que acontece ao acessar uma URL direcionada a uma página em PHP (retirado de Davis (2008)) Abaixo é listado cada passo demonstrado na gura 14: 1. Inserção de um endereço no navegador. 2. O navegador divide o endereço e envia a página requisitada para o host. Nessa demonstração: requisita a página exemplo.php do endereço 3. O servidor web processa as respostas do host para exemplo.php. 4. O servidor web lê o arquivo exemplo.php no HD do host. 5. O servidor web detecta que o arquivo php não é apenas um arquivo HTML, e chama o intérprete PHP para processar o arquivo. 6. O intérprete de PHP executa o código PHP que ele recebeu, e percebe que existem chamadas ao banco de dados MySQL 7. O PHP solicita que o MySQL execute essas chamadas. 8. O banco de dados MySQL processa as respostas adquiridas do banco e as manda para o intérprete PHP.
28 27 9. O intérprete PHP completa a execução do código e retorna os resultados para o processo do servidor web. 10. O servidor web retorna os resultados em forma de HTML de volta para o navegador. 11. O navegador web do usuário constrói a página web a partir dos resultados. Após ter estudado todos os itens descritos na fundamentação teórica, a continuidade do trabalho é dada através da metodologia explicada no próximo capítulo.
29 28 3 METODOLOGIA Neste capítulo serão mostrados e explicados os diagramas que compõem o sistema, os novos ajustes propostos para conseguir cumprir os objetivos especícos, os métodos utilizados para realização de tal m e a representação dos novos modelos propostos. 3.1 Preparação do Ambiente para a Implementação do Sistema Antes de começar os estudos e enm começar a por em prática todos os objetivos especícos voltados à funcionalidade do sistema, é necessário preparar um ambiente de desenvolvimento que suporte o sistema. Tratando-se de um sistema que utiliza a plataforma Web, uma base de dados e um servidor, é necessário obter suporte de softwares que atendam a especicidade dos serviços WampServer O WampServer se encaixa perfeitamente para suprir as necessidades de desenvolvimento. O WampServer é um ambiente de desenvolvimento para Windows, que permite criar aplicações em PHP que utilizem o Apache e uma base de dados MySQL. A partir deste software é possível gerenciar todos os serviços Apache e MySQL, pois este programa instala e prepara o Windows para dar suporte aos serviços necessários citados anteriormente. O WampServer serve como um "painel de controle"de todos estes serviços, concentrando as funções de congurações em um ícone na bandeja do Windows. Seu download pode ser feito em sua homepage: NetBeans IDE (Integrated Development Environment) O NetBeans IDE, ou Ambiente de Desenvolvimento Integrado, é um software para desenvolvedores que torna a implementação do código mais fácil, pois conta com uma grande variedade de ferramentas aliadas ao desenvolvimento, tais como auto complementação de código, revisão de bugs e erros de digitação, scripts de códigos vazios (modelos),
30 29 entre várias outras coisas. A versão utilizada do NetBeans neste trabalho é a versão 7.1, que possui suporte para o PHP 5.3 também utilizado neste trabalho, já instalado pelo WampServer. O NetBeans é um projeto de software livre e pertence a comunidade NetBeans, criada pela Sun Microsystems, hoje pertencente a Oracle O Estudo do Sistema Atual Após as devidas integrações do SisGCE com o Windows através dos softwares anteriormente citados, a etapa de estudo do sistema já pode ser realizada. Este estudo faz uso de vários materiais de apoio, como os diagramas UML, livros e tutoriais que abordam o tema e o modelo do SisGCE. A primeira diculdade enfrentada está logo nesta etapa de estudo, que é a parte de ler e entender o código fonte atual do sistema. Por se tratar de um novo conteúdo, uma linguagem de programação até então nova, uma adaptação a este novo conteúdo deve se formar com o passar do tempo. Os diagramas do sistema documentados anteriormente ajudaram apenas parcialmente, visto que nem todos os diagramas foram feitos, principalmente o de sequência. O sistema inteiro foi projetado de acordo com um design pattern ensinado em um livro sobre PHP orientado a objetos, de Pablo Dall'Oglio, o PHP - Programando com Orientação a Objetos, lançado em 2007 pela editora Novatec. Sabendo disso, grande parte das dúvidas em relação aos códigos do sistema são sanadas com a leitura deste livro, que explica todo o processo de implementação. 3.2 Diagramas do Sistema Na documentação do SisGCE feita anteriormente, foram registrados os diagramas de Caso de Uso, de Classe, os modelos Entidade-Relacionamento e Relacional, conforme mostrado a seguir. Os diagramas foram corrigidos conforme o atual funcionamento do sistema Diagramas Registrados da Documentação Anterior O diagrama de Caso de Uso registrado na documentação anterior, mostrado no anexo A, está exemplicado a interação entre professor e administrador com o sistema da seguinte maneira: o professor acessa o diário de classe, e automaticamente consulta os cursos e seus cursantes. Ele tem como opções alterar e excluir cursos e cursantes. O
31 30 administrador pode gerar certicados, o que inclui poder consultar e alterar dados dos cursantes e dos cursos. Ele também pode apenas consultar os cursantes e alterar seus dados diretamente. Ao cadastrar um aluno, ele vai automaticamente consultar os cursos poder fazer alterações novamente. Para cadastrar um ministrante, o administrador também consultará a mesma opção de cursos. Ao fazer apenas a consulta a ministrantes, ele poderá fazer alterações em seus dados. O diagrama de Classes registrado na documentação anterior, mostrado no anexo B, demonstra a parte das principais relações orientadas a objeto no sistema. A partir dele pode-se ver que: a classe matrícula é composta por uma pessoa e uma turma; A classe matrícula é agregada a uma ou várias avaliações; Frequência é associada a uma matrícula; A classe turma é composta por um curso; Calendário é agregado a uma turma; Sala possui associação com uma turma e é agregada a infraestrutura. O modelo Entidade-Relacionamento registrado na documentação anterior, mostrado no anexo C, demonstra como se dá os relacionamentos entre entidades do banco de dados do sistema. A linguagem nesse modelo é bem acessível e pode ser compreendida apenas observando a gura. O modelo Relacional registrado na documentação anterior, anexo D, demonstra como se dá a modelagem do banco de dados do sistema, em um nível mais próximo à realidade. Pode-se observar que esse modelo deriva do modelo Entidade-Relacionamento visto no parágrafo anterior Ajustes Realizados nos Diagramas No diagrama de Caso de Uso, foram corrigidas algumas associações e inseridos os casos de usos que estavam ausentes. Como pode-se observar no anexo E, professor pode ver informações de turma, gerenciar o diário de classe, as frequências e as aulas ministradas. O administrador pode consultar ministrantes, cursos, turmas, cursantes, e modicá-los. No diagrama de classes, anexo F, foram adicionadas as classes de controle das classes modelo, e a classe de FrontController. No modelo Entidade-Relacionamento, anexo G, foram corrigidos os nomes dos atributos (alguns não estavam exatamente iguais aos do banco), e a cardinalidade da relação entre as entidades aula e turma. No modelo Relacional, anexo H, foi criado um atributdo status na tabela turma, para referenciar se ela está ativa ou não.
32 31 O diagrama de sequência não foi registrado na documentação anterior. Foi feito dois desses diagramas para exemplicar o funcionamento de cadastro (anexo I) e de listagem (anexo J) do sistema Itens Aprimorados Na manutenção do sistema, os seguintes itens foram aprimorados: Menu "Turmas"(administrador): Este menu foi inserido como submenu em um novo menu chamado "Cadastros", onde separa todos os menus de gerência de cadastros dos demais. Anteriormente, apenas as informações sobre a turma selecionada eram mostradas. Foi aprimorado este item para que além das informações de turma, fossem também mostrados os alunos que estão matriculados na turma selecionada. Neste menu foi ajustada a função de fechamento de turmas, colocando uma condição que zesse com que o administrador só pudesse fechar turmas previamente fechadas pelo professor da turma. Uma veriacação foi adicionada no formulário de criação de turma, para que não houvesse interseção de horários entre turmas que são ministradas numa mesma sala. Não era possível criar turmas que iniciassem ou terminassem na mesma data. Esta função foi ajustada para que essa ação fosse possível. Foi adicionado, junto do formulário de cadastro de turmas, o formulário de cadastro de calendários, que é referente aos dias da semana e horário em que haverá aula com a nova turma. Foi adicionada uma vericação no formulário de inclusão de turmas, para que fosse possível apenas escolher salas que suportassem a capacidade de vagas requerida pela nova turma. Menu "Pessoas" Este menu foi inserido como submenu em um novo menu chamado "Cadastros", onde separa todos os menus de gerência de cadastros dos demais. Também foram feitos dois novos submenus relacionados ao cadastro de Pessoas am de realizar ltragens: o submenu "Professores", que ltra a listagem para que
33 32 apenas professores de turmas sejam mostrados, e o submenu "Alunos", que ltra a listagem para que apenas alunos de turmas sejam mostrados. Menu Calendários: Este menu serve como uma agenda, onde mostra quais aulas são ministradas em quais dias e horários. A função deste menu era completamente separada de sua da turma referenciada: era possível adicionar novas datas e alterar/excluir datas de turmas ainda em andamento. Esta função foi aprimorada mesclandoa com a função de cadastro de turmas, fazendo com que a programação da turma fosse registrada no ato do cadastro da mesma. Foi feito um ltro para que apenas turmas ainda não fechadas pelo administrador fossem mostradas, am de não dar informações sobre turmas que não serão mais utilizadas. Menu "Matrículas": Foram retirados campos inutilizáveis existentes no formulário de matrícula (campos desempenho, falta e status). Foi adicionada uma vericação no formulário de matrículas, para que fosse possível apenas matricular um novo aluno numa turma que ainda tivesse vagas. Este tipo de vericação não existia anteriormente. Menu "Usuários": No cadastro de usuários, foi feita a vericação que não deixasse a mesma pessoa se cadastrar em mais de um nível de usuário, permitindo apenas que ele fosse ou administrador ou professor. Não existia o controle de usuários; era possível apenas inserir novos usuários. Esta função foi remodelada para que o administrador pudesse editar e excluir usuários, como nos outros menus que continham cadastro, edição e exclusão. Formulários de busca em geral: A busca no banco de dados com palavras que tinham acentuação não era possível. Esta função foi otimizada para atender às buscas com termos que usavam acentos. A busca de calendários, turmas e matrículas só era possível através do ID de cada um. Atualmente a busca é realizada através do nome de cada um.
34 33 Menu "Turmas"(professor): Neste menu, as turmas foram separadas em "Ativas"e "Inativas", para que o professor, ao consultar suas turmas, tivesse o retorno apenas das turmas que lhe fossem convenientes. O diário de classe das turmas foi refeito, fazendo com que fosse gerado um arquivo PDF contendo todas as informações de um diário de classe, como nome do curso, nome da turma, nome do professor, data de início, data de término, alunos matriculados e suas respectivas frequências, e total de faltas. Tabela "Turma"(banco de dados) Foram criadas três novas colunas: nome, fechada e excluída. A coluna nome faz referência ao nome da turma, que até então só tinha o nome do curso. A coluna fechada faz referência à ação de fechar turma feita pelo professor. A coluna excluída faz referência à existência da tabela, ou seja, se a turma foi excluída pelo administrador ou não. Observação sobre o último item (coluna excluída): ao excluir uma turma, muitas vezes era impossível, porque outras tabelas dependiam de sua chave primária. O sistema informava um erro ao tentar fazer a exclusão, porém não especicava o porquê. Tabela "Pessoa"(banco de dados) Foi criada uma nova coluna nesta tabela, chamada excluída, pelo mesmo motivo explicado no item anterior: a tabela pessoa fazia referência a outras tabelas, como a tabela matrícula e a tabela usuários; então, ao realizar a exclusão de um dos valores da tabela pessoa, a ação era negada por causa da dependência de chave estrangeira que esta tabela tinha com as outras.agora, com a correção realizada, ao excluir uma pessoa, ela cará apenas "invisível"para ações que usem dados provenientes da tabela pessoa. Visualmente, o sistema não sofreu grandes alterações. Sua interface foi conservada, podendo ser observada na próxima seção. 3.3 Demonstração da Nova Versão do Sistema A guras a seguir são screenshots que demonstram algumas telas do sistema atual, após a manutenção, comparando-o com o sistema antigo.
35 34 (a) (b) Figura 15: Interface antiga da página principal do sistema (a) comparada a interface nova (b)
36 35 (a) (b) Figura 16: Interface antiga do formulário de cadastro de turmas do sistema (a) comparada a interface nova (b)
37 Figura 17: Nova interface de controle de usuários (anteriormente inexistente) 36
38 Figura 18: Modelo de certicado gerado ao fechar uma turma 37
39 38 4 CONSIDERAÇÕES FINAIS O desenvolvimento de um TCC, desde seu início, na exploração de variedades de temas a serem abordados, até a sua execução, mostra que para chegar a um resultado satisfatório é necessário dedicação e força de vontade. Problemas durante o desenvolvimento aparecem às vezes, nem tudo acaba saindo como o planejado porém isso é algo normal, pois, com o tempo, conseguimos experiência para melhorar os nossos métodos. Como o trabalho consistiu em realizar testes e propor ajustes para um funcionamento mais correto de um sistema desenvolvido até então, por outra pessoa, foi de muita importância investir as primeiras semanas do trabalho em estudar o código fonte e a funções até então denidas. Apesar de várias coisas terem sido corrigidas durante o trabalho, novas ferramentas e funções podem vir a serem incluídas no sistema para o deixar ainda mais usual, como a integração a outros sistemas do Câmpus, etc. Após essa experiência no desenvolvimento do sistema, cou clara a importância da documentação feita pelo desenvolvedor, e como se deparar com novas técnicas e linguagens de programação é algo normal e constante, exigindo dinâmica e interesse da parte do programadores. Quanto ao sistema e seu objetivo principal, que é o de facilitar o controle de horas extracurriculares para os alunos, foi de grande ajuda a maneira da qual a impressão de certicados veio a se tornar. Os objetivos iniciais foram alcançados podendo concluir esta etapa do projeto, fazendo com que o sistema possa ser utilizado a partir do ano de 2013 no Instituto Federal do Paraná - Câmpus Paranaguá.
40 39 5 REFERÊNCIAS BIBLIOGRÁFICAS APACHE HTTP Server Project Disponível em: <http://httpd.apache.org>. Acesso em 07 abr CAMPOS, L. HTML Rápido e Prático. Goiânia: Terra DALL'OGLIO, P. PHP Programando com Orientação a Objetos. São Paulo: Novatec DAVIS M. E.; PHILLIPS, J. A.Aprendendo PHP & MySQL. Rio de Janeiro: A. Books DAVIS M. E.; PHILLIPS, J. A.Aprendendo PHP & MySQL. Rio de Janeiro: A. Books li. GUEDES, G. UML - Uma Abordagem Prática. 2ª Edição. São Paulo: Novatec HEUSER, C. A. Projeto de Banco de Dados. Disponível em: < Acesso em: 02 abr LIMA A. G. JavaScript - Aplicações Interativas para a Web. Belo Horizonte MYSQL - About MySQL Disponível em: <http://www.mysql.com/about/>. Acesso em 07 abr
41 40 NASCIF, X. J. Manutenção - Tipos e Tendências Disponível em: <http://www.manageengenharia.com.br/>. Acesso em: 10 abr PRESSMAN R. S. Engenharia de Software. São Paulo: Pearson Education do Brasil SILBERSCHATZ, A.; KORTH H. Sistema de Banco de Dados. 3ª Edição. São Paulo: Peason The Apache Software Foundation Disponível em: <http://www.apache.org/>. Acesso em 07 abr W3SCHOOLS - AJAX Introduction Disponível em: <http://www.w3schools.com/ajax/ajax_intro.asp>. Acesso em 07 abr
42 6 ANEXOS 41
43 42 ANEXO A -- Diagrama de Caso de Uso Anterior Figura 19: Diagrama de Caso de Uso registrado na documentação anterior
44 43 ANEXO B -- Diagrama de Classes Anterior Figura 20: Diagrama de Classes registrado na documentação anterior
45 44 ANEXO C -- Modelo Entidade-Relacionamento Anterior Figura 21: Modelo Entidade-Relacionamento registrado na documentação anterior
46 45 ANEXO D -- Modelo Relacional Anterior Figura 22: Modelo Relacional registrado na documentação anterior
Professor: Paulo Macos Trentin paulo@paulotrentin.com.br http://www.paulotrentin.com.br Escola CDI de Videira
Professor: Paulo Macos Trentin paulo@paulotrentin.com.br http://www.paulotrentin.com.br Escola CDI de Videira Objetivo e desafio do curso Como objetivo o curso irá tornar o aluno capaz de desenvolver um
ESCOLA ESTADUAL DE EDUCAÇÃO PROFISSIONAL ESTRELA TÉCNICO EM INFORMÁTICA SISTEMA DE LOCADORA. Rodrigo Luiz da Rosa
ESCOLA ESTADUAL DE EDUCAÇÃO PROFISSIONAL ESTRELA TÉCNICO EM INFORMÁTICA SISTEMA DE LOCADORA Rodrigo Luiz da Rosa Estrela 2012 EIXO TECNOLÓGICO: Informação e Comunicação TÍTULO: SISTEMA DE LOCADORA AUTOR: