UNIVERSIDADE FEDERAL DO PARÁ CURSO DE SISTEMAS DE ... · MySQL Query Browser..... 36 CAPÍTULO 4 – Modelagem do Sistema ... Figura 4.1 – Diagrama de caso de Uso da Visão Geral

UNIVERSIDADE FEDERAL DO PARÁ CURSO DE SISTEMAS DE INFORMAÇÃO

Campus Marabá

DESENVOLVIMENTO DE UM SISTEMA WEB PARA COLEGIADO ACADÊMICO.

Rafael Henrique Nogueira Corrêa Ralfh Alan Gomes Machado

Euler Almeida Fonseca

MARABÁ

2008


Campus Marabá

DESENVOLVIMENTO DE UM SISTEMA WEB PARA COLEGIADO ACADÊMICO.



Trabalho de Conclusão de Curso, apresentado à Universidade Federal do Pará, como parte dos requisitos necessários para obtenção do Título de Bacharel em Sistemas de Informação.

Orientador: Profª. Geilma Ferreira Brito

MARABÁ

2008


Campus Marabá

DESENVOLVIMENTO DE UM SISTEMA WEB PARA

COLEGIADO ACADÊMICO.



Trabalho de Conclusão de Curso apresentado como parte dos requisitos necessários para obtenção do Título de Bacharel em Sistemas de Informação.

Marabá-PA, 15 de Dezembro de 2008.

_________________________________

Orientador(a): Profª. Geilma Ferreira Brito

UFPA

_________________________________

Profº. Narciso das Neves Soares, Msc.

UFPA

__________________________________

Charles Pitter da Silva Sarges

Membro

MARABÁ

2008

iv

DEDICATÓRIA

“A minha família pelo apoio e financiamento de importantes

anos de estudo. A minha esposa Gabriella, pela paciência e

apoio durante essa árdua jornada”.

Rafael

“A minha mãe, Rosângela, ao meu irmão David, minha

gratidão pelo apoio recebido. Aos meus filhos e a minha

esposa Joicy pelo amor que sempre me doaram”.

Ralfh

“A minha mãe (minha heroína e exemplo de vida), pelo amor

incondicional e sem limites que fez de mim o que sou hoje e

que me dá forças para querer ser melhor amanha. A meus

irmãos e irmãs os quais muito amo, fundamentais como

família e base de tudo, meu padastro Adão José pelo apoio ao

longo destes anos, e a minha esposa Laicy pela dedicação e

amor, e por ter dividido comigo bons e maus momentos”.

Euler

v

AGRADECIMENTOS

Agradecemos primeiramente a Deus, por nos fazer dotados de

inteligência e capacidade.

A nossa orientadora pelo auxílio, aos membros da banca

examinadora pelo emprego de tempo e atenção e aos

colaboradores diretos e indiretos.

vi

RESUMO

Este trabalho tem como objetivo principal desenvolver um sistema web que irá atender funcionários, docentes e discentes do curso de matemática do campus de Marabá da UFPA, além do público externo que acesse a página. Utilizando para tal fim estudo e aplicação de alguns dos conceitos, tecnologias e ferramentas usadas na concepção desse tipo de aplicação. Por fim demonstrando as vantagens das aplicações voltadas para o ambiente web em relação às aplicações tradicionais em vários aspectos como mobilidade de acesso às informações, independência de sistema operacional, alcance mundial por utilizar a Internet como meio de difusão, entre outros. Palavras-chave: Sistema web, mobilidade, Internet.

vii

ABSTRACT

This paper aims to develop a system main web that will meet officials, teachers and students of mathematics from the campus of UFPA Maraba, in addition to the external public who visit the page. Using this order to study and application of some concepts, technologies and tools used to design this type of application. Finally showing the benefits of applications geared to the Web environment for traditional applications in various aspects such as mobility to access information, independent of the operating system, global reach by using the Internet as a means of dissemination, among others. Key words: System web, mobile, Internet.

viii

SUMÁRIO

Dedicatória............................................................................................................................................ iv

Agradecimentos ......................................................................................................................................v

Resumo .................................................................................................................................................. vi

Abstract ................................................................................................................................................. vii

Lista de Ilustrações ............................................................................................................................... x

Lista de Tabelas.................................................................................................................................... xi

Lista de Abreviaturas ......................................................................................................................... xii

CAPÍTULO 1 – Introdução................................................................................................................ 13

1.1. Considerações Iniciais................................................................................................................. 13

1.2. Objetivos ..................................................................................................................................... 13

1.3. Justificativa ................................................................................................................................. 14

1.4. Estrutura do Trabalho.................................................................................................................. 15

CAPÍTULO 2 – Revisão de Literatura ............................................................................................. 16

2.1. Engenharia de Software.............................................................................................................. 16

2.1.1. Modelo em Cascata ............................................................................................................. 17

2.1.2. Desenvolvimento Evolucionário ......................................................................................... 19

2.1.3. Desenvolvimento Formal de Sistemas ................................................................................ 20

2.1.4. Desenvolvimento Orientado a Reuso .................................................................................. 21

2.1.5. Iteração de Processo ............................................................................................................ 22

2.1.6. Desenvolvimento Incremental............................................................................................. 23

2.1.7. Desenvolvimento em Espiral .............................................................................................. 24

2.2. UML (Linguagem de Modelagem Unificada)............................................................................ 26

2.2.1. Histórico.............................................................................................................................. 26

2.2.2. Diagramas............................................................................................................................ 27

2.3. PHP (Hypertext Preprocessor)................................................................................................... 29

2.4. MySQL....................................................................................................................................... 31

CAPÍTULO 3 – Metodologia ............................................................................................................. 33

3.1. Visual Paradigm Community Edition para UML...................................................................... 33

3.2. Zend Studio................................................................................................................................ 35

3.3. MySQL Query Browser ............................................................................................................ 36

CAPÍTULO 4 – Modelagem do Sistema ........................................................................................... 38

4.1. Análise de Requisitos ................................................................................................................ 38

4.2. Diagramas de Caso de Uso........................................................................................................ 38

4.2.1. Diagrama de Caso de Uso – Visão Geral ............................................................................ 38

ix

4.2.2. Diagrama de Caso de Uso – Acesso Público ...................................................................... 40

4.2.2.1. Documentação do Caso de Uso – Acesso Público ..................................................... 42

4.2.3. Diagrama de Caso de Uso – Acesso Irrestrito – Visão do Funcionário .............................. 45

4.2.3.1. Documentação do Caso de Uso – Acesso Irrestrito – Visão do Funcionário............. 46

4.2.4. Diagrama de Caso de Uso – Acesso Irrestrito – Visão do Aluno ....................................... 50

4.2.4.1. Documentação do Caso de Uso – Acesso Irrestrito – Visão do Aluno ...................... 52

4.3. Diagrama de Classes ................................................................................................................. 54

4.4. Diagrama de Objetos................................................................................................................. 56

4.5. Diagrama de Sequência............................................................................................................. 57

4.6. DER (Diagrama Entidade-Relacionamento) ............................................................................. 61

CAPÍTULO 5 – Considerações Finais .............................................................................................. 63 REFERÊNCIAS BIBLIOGRÁFICAS ............................................................................................. 64 ANEXO A ............................................................................................................................................ 65 ANEXO B............................................................................................................................................. 73

x

LISTA DE ILUSTRAÇÕES

Figura 2.1 – Modelo em Cascata.......................................................................................................... 18

Figura 2.2 – Esquema do Desenvolvimento Evolucionário................................................................. 20

Figura 2.3 – Esquema do Desenvolvimento Formal de Sistemas ........................................................ 21

Figura 2.4 – Esquema do Desenvolvimento Orientado a Reuso.......................................................... 22

Figura 2.5 – Esquema de Desenvolvimento Incremental..................................................................... 24

Figura 2.6 – Esquema do Desenvolvimento em Espiral ...................................................................... 25

Figura 3.1 – Visão do Visual Paradigm............................................................................................... 34

Figura 3.2 – Visão do Editor de Código do Zend Studio ..................................................................... 35

Figura 3.3 – Tela do MySQL Query Browser...................................................................................... 37

Figura 4.1 – Diagrama de caso de Uso da Visão Geral........................................................................ 40

Figura 4.2 – Diagrama de Caso de Uso do Acesso Público................................................................. 41

Figura 4.3 – Diagrama de Caso de Uso do Acesso Irrestrito (Visão Funcionário) .............................. 46

Figura 4.4 – Diagrama de Caso de Uso do Acesso Irrestrito (Visão Aluno) ....................................... 51

Figura 4.5 – Diagrama de Classes do Sistema ..................................................................................... 55

Figura 4.6 – Diagrama de Objetos do Sistema..................................................................................... 56

Figura 4.7 – Diagrama de Seqüência Realizar Login (Visão Funcionário).......................................... 57

Figura 4.8 – Diagrama de Seqüência Realizar Login (Visão Aluno)................................................... 58

Figura 4.9 – Diagrama de Seqüência Incluir Nota ............................................................................... 59

Figura 4.10 – Diagrama de Seqüência Alterar Dados (Visão Aluno) .................................................. 60

Figura 4.11 – DER do Banco de Dados do Sistema............................................................................. 62

Figura A1 – Primeira Página do Curso de Matemática........................................................................ 65

Figura A2 – Nova Página do Curso de Matemática............................................................................. 66

Figura A3 – Página de Login do Aluno ............................................................................................... 67

Figura A4 – Página de Controle das Funções do Aluno ...................................................................... 68

Figura A5 – Página de Login do Funcionário ...................................................................................... 69

Figura A6 – Página de Controle das Funções do Funcionário............................................................. 70

Figura A7 – Histórico Acadêmico Disponível na Seção do Aluno...................................................... 71

Figura A8 – Seção de Material de Apoio............................................................................................. 72

xi

LISTA DE TABELAS

Tabela 4.1: Documentação do Caso de Uso Visualizar Conteúdo....................................................... 42

Tabela 4.2: Documentação do Caso de Uso Visualizar Projeto de TCC ............................................. 43

Tabela 4.3: Documentação do Caso de Uso Baixar TCC .................................................................... 43

Tabela 4.4: Documentação do Caso de Uso Visualizar Material de Apoio ......................................... 44

Tabela 4.5: Documentação do Caso de Uso Baixar Material de Apoio............................................... 44

Tabela 4.6: Documentação do Caso de Uso Realizar Login ................................................................ 47

Tabela 4.7: Documentação do Caso de Uso Manter Aluno ................................................................. 48

Tabela 4.8: Documentação do Caso de Uso Manter Turma ................................................................ 49

Tabela 4.9: Documentação do Caso de Uso Manter Histórico ............................................................ 50

Tabela 4.10: Documentação do Caso de Uso Realizar Login .............................................................. 52

Tabela 4.11: Documentação do Caso de Uso Manter Alunos.............................................................. 53

Tabela 4.12: Documentação do Caso de Uso Visualizar Histórico ..................................................... 53

Tabela 4.13: Documentação do Caso de Uso Imprimir Histórico ....................................................... 54

xii

LISTA DE ABREVIATURAS

BPMN Business Process Modeling Notation

CASE Computer-Aided Software Engineering

CGI Common Gateway Interface

DFD Data Flow Diagram

ERD Entity-relationship Diagram

HTML Hypertext Markup Language

ODBC Open Database Connection

OMG Object Management Group

OMT Object Modeling Technique

OOSE Object-Oriented Software Engineering

PHP HyperText Preprocessor

SQL Structured Query Language

XHTML eXtensible Hypertext Markup Language

XML eXtensible Markup Language

Capítulo 1 – Introdução

13

CAPÍTULO 1 – Introdução

1.1 Considerações Iniciais

O incrível crescimento a que a Internet se submeteu e continua sofrendo, foi

com o tempo levando ao aparecimento de uma nova classe de aplicações, assim surgiram os

sistemas web, que se utilizam da Internet como meio de trabalho e disseminação.

Trabalham da mesma forma que uma aplicação tradicional, mas em um

ambiente que propicia vantagens como: manutenções em tempo real, independência de

sistemas operacionais, alcance mundial, entre outros. São sistemas que funcionam no

computador servidor da rede, o qual é responsável pelo processamento das informações do

sistema, o trabalho das máquinas clientes é simplesmente o de esperar pela chegada das

informações, fator que representa um importante ganho adicional de velocidade nas

transações.

A mobilidade de acesso as informações que se deseja consultar a partir de

qualquer lugar e a qualquer momento (sendo necessário apenas uma conexão com Internet

ou Intranet, dependendo do tipo de aplicação) e a possibilidade de desenvolvimento de um

sistema que atenda os requisitos do cliente tornam cada vez mais atraente o uso dessas

aplicações.

1.2 Objetivos

Este projeto tem como objetivo desenvolver um sistema web que irá atender o

colegiado do curso de Matemática da UFPA campus de Marabá, sendo composto de

funcionalidades que atenderão o público em geral que acesse a página, e também uma área

com aplicações específicas voltadas aos discentes do curso, funcionando de forma integrada

ao sistema.


14

1.3 Justificativa

Os sistemas de plataforma web consistem em sistemas que funcionam através

de browser. Nesse formato, os softwares funcionam pela Internet, permitindo a integração

de várias outras aplicações, formando uma grande plataforma.

Essa plataforma pode ser acessada através de qualquer navegador e tem como

benefícios a mobilidade de ter seus aplicativos disponíveis de qualquer lugar, investimento

reduzido pelo baixo custo de instalação e manutenção das versões, gerenciamento

centralizado, por que a aplicação se encontra em único ponto, o servidor e a liberdade de

ser flexível, segura e ter alto desempenho. O fato de ter uma aplicação instalada em várias

máquinas gera uma carga de trabalho grande e aumenta a possibilidade de erros e

problemas indesejáveis quando o usuário tem acesso físico às máquinas e pode fazer

alterações que comprometem a qualidade do sistema. Esses problemas são contornados,

quando o acesso aos aplicativos do sistema ocorre via browser, ou seja, de qualquer

computador com ligação a Internet ou ao servidor onde o sistema encontra-se instalado.

Tomando como referencial o alvo do projeto, o colegiado do curso de

matemática da UFPA campus de Marabá, houve a partir de determinado momento a

necessidade da implantação de uma aplicação que privilegiasse rotinas que ocorrem no

ambiente do curso, de forma que os atores presentes no cotidiano do curso (funcionários e

alunos) e o público em geral que busca informações, fossem incluídos. Como melhor saída

para atender esses requisitos, o desenvolvimento de uma aplicação voltada para o ambiente

web foi escolhida. Assim, a partir do término da aplicação, o público que acessar a página

do curso de matemática contará com informações que antes não eram divulgadas pelo

colegiado do curso, pelo simples fato de não contarem com um veículo de difusão

apropriado. No que tange aos alunos existirá a independência em relação aos serviços

disponibilizados pelo portal da UFPA, por estarem sempre sendo atualizadas à medida que

os professores divulguem no colegiado as informações referentes ao seu aproveitamento

acadêmico e também os materiais de apoio que não possam ser disponibilizados pelo meio

comum (de forma presencial), tudo isso sendo feito através da Internet, com todas as

vantagens já citadas anteriormente.


15

1.4 Estrutura do Trabalho

O trabalho está disposto da seguinte forma, no capítulo dois é feita uma

apresentação sobre o conceito de engenharia de software, com ênfase nos processos de

software, e abordagem das linguagens UML e PHP e aspectos básicos do sistema

gerenciador de banco de dados MySQL.

O capítulo três destina-se a abordagem das metodologias empregadas na

realização do projeto, analisando os processos de software usados no sistema, as

ferramentas usadas na modelagem, implementação de código e do banco de dados, Visual

Paradigm, Zend Studio e MySQL Query Browser respectivamente.

O capítulo quatro aborda o processo de modelagem do sistema mostrando os

diagramas utilizados. Em seguida o quinto capítulo com as considerações finais sobre o

projeto.

Capítulo 2 – Revisão de Literatura

16

CAPÍTULO 2 – Revisão de Literatura

A difusão da Internet chegou a tal ponto, que os sistemas e aplicações web,

adquiriram complexidade e importância semelhantes às aplicações tradicionais, alcançando

os mais diversos tipos de organizações e finalidades de aplicação e uso. Com isso

evidenciou-se a preocupação na utilização de métodos que auxiliem e dinamizem o

processo de desenvolvimento dessas aplicações.

Serão descritas a seguir as tecnologias que foram utilizadas na realização desse

trabalho de conclusão de curso.

2.1 Engenharia de Software

Segundo SOMMERVILLE, (2003) a engenharia de software é uma ramificação

da engenharia que tem por objetivo se dedicar aos aspectos necessários ao desenvolvimento

de um software, constituindo bases teóricas que permitem que o mesmo seja construído,

utilizando para isso os conceitos de processo de software e seus variados modelos, os

modelos de processo de software.

Um processo de software é um conjunto de atividades e resultados associados

que culminam na produção de um software (SOMMERVILLE, 2003). Apesar da existência

de vários modelos de processos de software, existem atividades fundamentais comuns a

todos. Atividades como:

• Especificação de software;

• Projeto e implementação de software;

• Validação de software;

• Evolução de software;

Um modelo de processo de software é uma forma simples de um processo de

software, apresentado a partir de uma visão específica. Serão exibidos a seguir alguns

modelos genéricos, o modelo em cascata, desenvolvimento evolucionário, desenvolvimento

formal de sistemas e desenvolvimento orientado a reuso e finalizando abordagens híbridas

de processo, desenvolvimento incremental e desenvolvimento em espiral.


17

2.1.1 Modelo em Cascata

O modelo de processo em cascata recebe esse nome devido à seqüência linear

em que suas fases se sucedem (SOMMERVILLE, 2003). Esse modelo divide-se em

estágios fundamentais: (ver figura 2.1).

Análise e definição de requisitos: as funções, restrições e objetivos do

sistema são estabelecidos a partir da consulta dos usuários do sistema.

Projeto de sistemas e de software: o processo de projeto de sistemas reúne os

requisitos em sistemas de hardware ou software.

Implementação e teste de unidades: nessa fase o projeto de software é

compreendido como um conjunto de programas ou unidades de programa. O teste das

unidades visa verificar se elas atendem suas especificações.

Integração e teste de sistemas: as unidades de programas são unidas e testadas

em conjunto como um sistema complemento para garantir que os requisitos de software

foram alcançados.

Operação de manutenção: o sistema é instalado e colocado em

funcionamento, a manutenção visa corrigir erros não detectados durante as fases anteriores

do processo.


18

Figura 2.1 – Modelo em cascata.

Fonte: SOMMERVILLE, 2003.

Cada um desses estágios gera documentos que são aprovados, o que implica

que uma fase não começa até que sua antecessora seja devidamente concluída e aprovada,

mas na prática esses estágios sobrepõem-se interagindo entre si, o que resulta na detecção

de problemas durante as fases, fato que o torna um processo linear, porém não simples que

requer trabalhos adicionais entre as fases tornando todo esse processo caro e oneroso

levando a suspensão de algumas partes do projeto, fato que leva o sistema final à não

atender uma série de requisitos que foram levantados no início do projeto.

A inflexibilidade causada pela divisão do projeto em fases distintas, leva a

confecção dos acordos de todos os estágios logo no início do projeto, fase em que os

requisitos do usuário ainda não estão bem definidos e são altamente mutáveis. Logo, o

modelo em cascata é mais indicado nas situações onde os requisitos de usuário são bem

compreendidos e em sistemas de grande porte.


19

2.1.2 Desenvolvimento Evolucionário

O modelo de desenvolvimento evolucionário (ver figura 2.2) se baseia na idéia

de apresentar uma versão inicial ao cliente, e levando em conta os comentários da sua

avaliação fazer aprimoramentos até que o sistema ideal seja alcançado (SOMMERVILLE,

2003). Ao invés da formalidade (no sentido de realizar as fases em separado) encontrada no

desenvolvimento em cascata, no modo evolucionário essas fases são realizadas em paralelo

e existe rápido feedback de informação entre as mesmas. Existem dois tipos de

desenvolvimento evolucionário:

Desenvolvimento exploratório: onde o trabalho é feito em conjunto com o

cliente através da exploração dos seus requisitos até que o sistema final seja concluído.

Desenvolvimento de protótipos descartáveis: onde através da compreensão

dos requisitos expostos pelo cliente, tem-se uma melhor definição de requisitos para o

sistema e os protótipos concentram-se em testar os requisitos mal entendidos.

Esse tipo de modelo de desenvolvimento de software tem maior eficácia em

relação ao modelo em cascata no que diz respeito ao atendimento das necessidades

imediatas dos clientes. As especificações podem ser desenvolvidas de forma gradativa,

porém a partir da visão da engenharia e gerenciamento de software surgem alguns

problemas, como a falta de visibilidade do processo, onde os responsáveis pela gerência

precisam de dados para medir a progressão do desenvolvimento e devido à rapidez dessa

abordagem se torna inviável fazer relatórios das diferentes fases já que elas acontecem de

forma simultânea, e a freqüente mal-estruturação do sistema já que a constante mudança de

requisitos durante a implementação pode trazer instabilidades, além da dificuldade de se

mudar constantemente um software.


20

Figura 2.2 – Esquema do desenvolvimento evolucionário.


2.1.3 Desenvolvimento Formal de Sistemas

Esse tipo de abordagem de desenvolvimento tem aspectos em comum com o

desenvolvimento em cascata, mas tem como base o processo de transformação matemática

formal de uma especificação de sistema em um programa executável (SOMMERVILLE,

2003). As principais diferenças entre o modelo de desenvolvimento formal e o modelo em

cascata, são:

• A especificação de requisitos é redefinida em uma especificação formal

detalhada, que é expressa em uma notação matemática.

• Os processos de desenvolvimento de projeto, implementação e teste de

unidade são trocados por um processo de desenvolvimento transformacional, em que a

especificação formal é refinada por meio de uma série de transformações, em um programa.

No processo de transformação, a representação matemática formal do sistema é

sistematicamente convertida em uma representação de sistema mais detalhada, mas ainda

matematicamente correta. Cada etapa acrescenta mais detalhes, até que a especificação

formal seja convertida em um programa equivalente.


21

Figura 2.3 – Esquema do desenvolvimento formal de sistemas.


2.1.4 Desenvolvimento Orientado a Reuso

Na maioria dos projetos de software, ocorre algum reuso de software. Isso em

geral, ocorre informalmente, quando as pessoas envolvidas no projeto conhecem projetos

ou códigos similares aquele exigido. As modificações necessárias são realizadas e esses

produtos são incorporados no sistema (SOMMERVILLE, 2003).

Esse tipo de reuso informal acontece independente do processo genérico usado,

porém nos últimos anos, surgiu uma abordagem de desenvolvimento que adota o reuso e

que tem se tornado cada vez mais amplamente usada.

Essa abordagem dispõe de ampla base de componentes de software

reutilizáveis, que podem ser acessados, e com infra-estrutura de integração para esses

componentes. O estágio inicial de especificação de requisitos e o estágio de validação são

comparáveis aos de outros processos, porem os estágios intermediários são diferentes na

abordagem orientada a reuso, os estágios são:

Análise de componentes: levando em conta a especificação dos requisitos, é

feita uma busca de componentes para implementar essa especificação.

Modificação de requisitos: os requisitos são analisados, utilizando-se das

informações sobre os componentes que foram encontrados, eles então são modificados para

refletir os componentes disponíveis.

Projeto de sistema com reuso: a infra-estrutura do sistema é projetada ou uma

infra-estrutura existente é reutilizada.


22

Desenvolvimento e integração: o software que não puder ser comprado será

desenvolvido, e os componentes e sistemas serão integrados com a finalidade de criar um

sistema.

Esse modelo tem a vantagem de reduzir a quantidade de software a ser

desenvolvido, com conseqüente economia de tempo na entrega do mesmo e redução de

custos e riscos. Contudo as adequações inevitáveis nos requisitos podem resultar em um

sistema que não atenda as reais necessidades do usuário.

Figura 2.4 – Esquema do desenvolvimento orientado a reuso.


2.1.5 Iteração de Processo

Os processos mostrados anteriormente têm vantagens e desvantagens, e como

alternativa para resolver esse problema, na maioria dos sistemas de grande porte usa-se um

conceito de processo híbrido, que visa usar nas diversas partes do desenvolvimento, o

processo que melhor lhe couber, com o intuito de tirar mais proveito de cada esquema.

Além disso, começa a ser usada a estratégia da iteração que consiste na repetição em

diversas vezes das partes do processo, na medida em que novos requisitos se configuram

(SOMMERVILLE, 2003).


23

2.1.6 Desenvolvimento Incremental

Como visto antes o modelo em cascata se aplica em situações onde antes do

desenvolvimento os requisitos já estão todos bem definidos, no desenvolvimento

evolucionário as decisões, no que diz respeito a requisitos, podem ser tomadas enquanto o

desenvolvimento acontece. O desenvolvimento incremental reúne a vantagem de não haver

perda de tempo refazendo definições que já foram acertadas anteriormente, mas por outro

lado permite a possibilidade de dar ao cliente a chance de adiar decisões sobre o sistema,

para que elas ocorram após um entendimento melhor por parte do cliente, mas tudo isso

sem interromper o desenvolvimento (SOMMERVILLE, 2003).

Nesse processo, os clientes definem quais funções tem maior e menor

importância e prioridade, e também definem prazos de entrega, são implementados

incrementos com as funcionalidades principais e estes já podem ser usados pelo cliente,

diferentes processos de desenvolvimento podem ser usados para os diferentes incrementos

criados. Como o cliente já pode fazer uso do sistema a partir dos primeiros incrementos que

contem as funções principais, com isso tem-se a visão necessária de quais pontos precisam

ser adicionados nos incrementos restantes, até que se chegue a uma versão final do sistema.


24

Figura 2.5 – Esquema de desenvolvimento incremental.


2.1.7 Desenvolvimento em Espiral

Esse modelo de processo foge do padrão em que existe uma seqüência de

atividades que geram retorno de informação umas para as outras, o processo é representado

por uma espiral. Cada loop da espiral representa uma fase do processo, onde o loop mais

interno representa a fase inicial de avaliação de viabilidade do sistema e os outros loops

seguintes representam as fases subseqüentes (SOMMERVILLE, 2003). Cada loop é

dividido em quatro setores:

Definição de Objetivos: definem-se os objetivos específicos do projeto, são

identificadas as possíveis restrições para o projeto e o produto e então é preparado um

plano de gerenciamento detalhado.

Avaliação e Redução de Riscos: para cada um dos riscos analisados, é

realizada, detalhada análise e tomada a providência para a redução dos mesmos.

Desenvolvimento e Validação: depois da avaliação dos riscos é escolhido o

modelo de desenvolvimento para o sistema.


25

Planejamento: há uma revisão do projeto, e se parte para o ponto de tomar a

decisão de ir ou não para o próximo loop da espiral, caso o projeto prossiga, serão traçados

os planos do próximo estágio.

A diferença explicita do modelo em espiral em relação aos outros é a

importância dada na análise dos possíveis riscos. Não existem fases fixas, e o modelo em

cascata abrange outros modelos de processo que são usados para resolver problemas

específicos durante a especificação e fase de implementação.

Figura 2.6 – Esquema de desenvolvimento em espiral. Fonte: SOMMERVILLE, 2003.


26

2.2 UML (Linguagem de Modelagem Unificada)

A UML (Unified Modeling Language – Linguagem de Modelagem Unificada)

é uma linguagem visual utilizada para modelar sistemas computacionais por meio do

paradigma de Orientação a Objetos (GUEDES, 2006). Esta linguagem tornou-se, nos

últimos anos, a linguagem-padrão de modelagem de software adotada internacionalmente

pela indústria de engenharia de software.

De acordo com GUEDES, (2006) a UML não é uma linguagem de

programação, e sim uma linguagem de modelagem, cujo objetivo é auxiliar os engenheiros

de software a definirem as características do software, tais como seus requisitos, seu

comportamento, sua estrutura lógica, a dinâmica de seus processos e inclusive suas

necessidades físicas em relação ao equipamento sobre o qual o sistema deverá ser

implantado. Tais características são definidas por meio da UML antes do software começar

a ser realmente desenvolvido.

2.2.1 Histórico

A UML surgiu da união de três métodos de modelagem: o método de Booch, o

método OMT (Object Modeling Technique), de Jacobson, e o método OOSE (Object-

Oriented Software Engineering) de Rumbaugh. Estas eram, até meados da década de 1990,

os métodos de modelagem orientada a objetos mais populares entre os profissionais da área

de desenvolvimento de software. A união desses métodos contou com o amplo apoio da

Rational Software, que a incentivou e financiou.

O esforço inicial do projeto começou com a união do método de Booch ao

OMT de Jacobson, o que resultou no lançamento do Método Unificado, no final de 1995.

Logo em seguida, Rumbaugh juntou-se a Booch e Jacobson na Rational Software, e seu

método OOSE começou também a ser incorporado à nova metodologia.

O trabalho de Booch, Jacobson e Rumbaugh, conhecidos popularmente como

“Os Três Amigos”, resultou no lançamento, em 1996, da primeira versão da UML

propriamente dita. Tão logo a primeira versão foi lançada, muitas empresas atuantes na área

de modelagem e desenvolvimento de software passaram a contribuir com o projeto,

fornecendo sugestões para melhorar e ampliar a linguagem. Finalmente, a UML foi


27

adotada, em 1997, pela OMG (Object Management Group ou Grupo de Gerenciamento de

Objetos), como uma linguagem padrão de modelagem (GUEDES, 2006).

2.2.2 Diagramas

A UML é composta por diversos diagramas, o objetivo é fornecer múltiplas

visões do sistema a ser modelado, analisando-o e modelando-o sob diversos aspectos,

procurando-se, assim, atingir a totalidade da modelagem, permitindo que cada diagrama

complemente os outros.

Cada diagrama da UML analisa o sistema, ou parte dele, sob uma determinada

visão. É como se o sistema fosse modelado em camadas, sendo que alguns diagramas

enfocam o sistema de forma mais geral, apresentando uma visão externa do sistema, como

é o objetivo do Diagrama de Casos de Uso, enquanto outros oferecem uma visão de uma

camada mais profunda do software, apresentando um enfoque mais técnico ou ainda

visualizando apenas uma característica específica do sistema ou um determinado processo.

A utilização de diversos diagramas permite que falhas sejam descobertas, diminuindo a

possibilidade da ocorrência de erros futuros (GUEDES, 2006). A seguir breve descrição

dos diagramas.

Diagrama de Casos de Uso: é o diagrama mais geral e informal da UML,

procura identificar os atores (usuários, outros sistemas ou até mesmo algum hardware

especial), que utilizarão de alguma forma o software, bem como os serviços, ou seja, as

opções que o sistema disponibilizará aos atores, conhecidas neste diagrama como Casos de

Uso.

Diagrama de Classes: o Diagrama de Classes é o mais utilizado e o mais

importante da UML. Serve de apoio para a maioria dos demais diagramas. Como o próprio

nome diz, define a estrutura das classes utilizadas pelo sistema, determinando os atributos e

métodos que cada classe possui, além de estabelecer como as classes se relacionam e

trocam informações entre si.

Diagrama de Objetos: o Diagrama de Objetos está amplamente associado ao

Diagrama de Classes. Na verdade, o Diagrama de Objetos é praticamente um complemento

do Diagrama de Classes e bastante dependente deste. O diagrama fornece uma visão dos


28

valores armazenados pelos objetos de um Diagrama de Classes em um determinado

momento da execução de um processo do software.

Diagrama de Estrutura Composta: o Diagrama de Estrutura Composta

descreve a estrutura interna de um classificador, como uma classe ou componente,

detalhando as partes internas que o compõem, como estas se comunicam e colaboram entre

si. Também é utilizado para descrever uma Colaboração em que um conjunto de instâncias

cooperam entre si para realizar uma tarefa.

Diagrama de Seqüência: um Diagrama de Seqüência costuma identificar o

evento gerador do processo modelado, bem como o ator responsável por esse evento, e

determina como o processo deve se desenrolar e ser concluído por meio da chamada de

métodos disparados por mensagens enviadas entre os objetos.

Diagrama de Comunicação: está amplamente associado ao Diagrama de

Seqüência, na verdade um complementa o outro. As informações mostradas no Diagrama

de Comunicação com freqüência são, praticamente, as mesmas apresentadas naquele de

Seqüência, porém com um enfoque distinto, visto que este diagrama não se preocupa com a

temporalidade do processo, concentrando-se em como os objetos estão vinculados e quais

mensagens trocam entre si durante o processo.

Diagrama de Máquina de Estados: o Diagrama de Máquina de Estados é

utilizado normalmente para acompanhar os estados por que passa uma instância de uma

classe, mas pode ser utilizado para representar os estados de um caso de uso ou mesmo os

estados gerais de um subsistema ou de um sistema completo.

Diagrama de Atividade: o Diagrama de Atividade preocupa-se em descrever

os passos a serem percorridos para a conclusão de uma atividade específica, muitas vezes

representada por um método com certo grau de complexidade. O Diagrama de Atividade

concentra-se na representação do fluxo de controle de uma atividade.

Diagrama de Componentes: o Diagrama de Componentes está amplamente

associado à linguagem de programação que será utilizada para desenvolver o sistema

modelado. Esse diagrama representa os componentes do sistema quando o mesmo for ser

implementado em termos de módulos de código-fonte, bibliotecas, formulários, arquivos de

ajuda, módulos executáveis etc. e determina como tais componentes estarão estruturados e

irão interagir para que o sistema funcione de maneira adequada.


29

Diagrama de Implantação: o Diagrama de Implantação determina as

necessidades de hardware do sistema, as características físicas como servidores, estações,

topologias e protocolos de comunicação, ou seja, todo o aparato físico sobre o qual o

sistema deverá ser executado. O Diagrama de Componentes e de Implantação são bastante

associados, podendo ser representados separadamente ou em conjunto.

Diagrama de Pacotes: seu objetivo é representar os subsistemas englobados

por um sistema de forma a determinar as partes que o compõem. Pode ser utilizado de

maneira independente ou associado com outros diagramas.

Diagrama de Integração Geral: o Diagrama de Interação Geral é uma

variação do Diagrama de Atividade que fornece uma visão geral dentro de um sistema ou

processo de negócio.

Diagrama de Tempo: o Diagrama de Tempo descreve a mudança no estado ou

condição de uma instância de uma classe ou seu papel durante um tempo. Tipicamente

utilizado para demonstrar a mudança no estado de um objeto no tempo em resposta a

eventos externos.

2.3 PHP1 (Hypertext Preprocessor)

PHP (Hypertext Preprocessor) é uma linguagem de programação de ampla

utilização, interpretada, que é especialmente interessante para desenvolvimento web e pode

ser mesclada dentro do código HTML (PHP, 2008). A sintaxe da linguagem lembra C, Java

e Perl e é fácil de aprender. O objetivo principal da linguagem é permitir a desenvolvedores

escreverem páginas que serão geradas rapidamente e de forma dinâmica, mas muitas outras

funcionalidades podem ser feitas com PHP.

O PHP é focado para ser uma linguagem de script do lado do servidor,

portanto, pode-se fazer qualquer coisa que outro programa CGI (Common Gateway

Interface) pode fazer, como: coletar dados de formulários, gerar páginas com conteúdo

dinâmico ou enviar e receber cookies2.

1 Para este projeto foi utilizado o PHP versão 5.0, deve-se a isso os comentários comparativos a outras versões do mesmo software ao longo do texto. 2 Cookies são pequenos arquivos de texto que podem ser salvos no computador, que armazenam informações de sites da internet.


30

O PHP pode ser utilizado na maioria dos sistemas operacionais, incluindo

Linux, várias variantes do Unix (incluindo HP-UX, Solaris e OpenBSD), o Microsoft

Windows, Mac OS X, RISC OS, e provavelmente outros. O PHP também é suportado pela

maioria dos servidores web atuais, incluindo Apache, Microsoft Internet Information

Server, Personal Web Server, Netscape e Servidores iPlanet, Oreilly Website Pro Server,

Caudium, Xitami, OmniHTTPd, e muitos outros. O PHP pode ser configurado como

módulo para a maioria dos servidores, e para os outros como um CGI comum.

Com o PHP, portanto, existe a liberdade para escolher o sistema operacional e o

servidor web. Do mesmo modo, a escolha entre utilizar programação estrutural ou

programação orientada a objeto, ou ainda uma mistura deles.

A mais forte e mais significativa característica do PHP é seu suporte a uma

ampla variedade de banco de dados. Escrever uma página que consulte um banco de dados

é incrivelmente simples. Os seguintes bancos de dados são atualmente suportados:

• Adabas D • dBase • Empress • FilePro (somente leitura) • Hyperwave • IBM DB2 • Informix • Ingres • InterBase • FrontBase • mSQL • Direct MS-SQL • MySQL • ODBC (Open Data Base Connectivity) • Oracle (OCI7 and OCI8) • Ovrimos • PostgreSQL • SQLite • Solid • Sybase • Velocis • Unix dbm

Também foi providenciada uma abstração de banco de dados (chamada PDO)

que permite utilizar qualquer banco de dados transparentemente com sua extensão.


31

Adicionalmente, o PHP suporta ODBC (Open Database Connection – Padrão Aberto de

Conexão com Banco de Dados), permitindo a utilização de qualquer outro banco de dados

que suporte esse padrão mundial.

2.2 MySQL

O MySQL é um sistema de gerenciamento de bancos de dados que utiliza a

linguagem SQL (Structured Query Language – Linguagem de Consulta Estruturada) como

interface. Foi criado na Suécia por dois suecos e um finlandês: David Axmark, Allan

Larsson e Michael "Monty" Widenius, que têm trabalhado juntos desde a década de 1980.

Hoje seu desenvolvimento e manutenção empregam aproximadamente 70 profissionais no

mundo inteiro, e mais de mil contribuem testando o software, integrando-o a outros

produtos, e escrevendo a respeito dele (MySQL, 2008).

É um software opensource3 passível de uso e modificação por qualquer pessoa,

permitindo que através do estudo de seu código fonte, sejam feitas modificações que

melhor atendam as necessidades de cada usuário. O sistema de banco de dados MySQL é

extremamente rápido, confiável, e fácil de usar. O MySQL tem um conjunto de recursos

muito práticos desenvolvidos com a cooperação de seus usuários. MySQL tem como

características principais:

• Portabilidade (suporta praticamente qualquer plataforma atual); • Compatibilidade (existem drivers ODBC, JDBC e .NET e módulos de

interface para diversas linguagens de programação, como Delphi, Java, C/C++, Python, Perl, PHP, ASP e Ruby);

• Excelente desempenho e estabilidade; • Pouco exigente quanto a recursos de hardware; • Facilidade de uso; • É um software livre; • Suporte a vários tipos de tabelas (como MyISAM, InnoDB e Maria), cada

um específico para um fim; • Faltam alguns recursos quando comparados com outros bancos de dados,

como o PostgreSQL que aos poucos estão sendo implementados; • Aceita controle transacional; • Aceita Triggers; • Aceita Stored Procedures e Functions;

3 Software gratuito e com código fonte aberto para modificação pelos usuários.


32

• Replicação facilmente configurável;

MySQL foi desenvolvido originalmente para lidar com bancos de dados muito

grandes de maneira muito mais rápida que as soluções existentes e tem sido usado em

ambientes de produção de alta demanda por diversos anos de maneira bem sucedida.

Apesar de estar em constante desenvolvimento, MySQL oferece hoje um rico e proveitoso

conjunto de funções. A conectividade, velocidade, e segurança fazem com que o MySQL

seja altamente adaptável para acessar bancos de dados na Internet.

Capítulo 3 – Metodologia

33

CAPÍTULO 3 – Metodologia

Neste capítulo o enfoque será dado às ferramentas usadas para a realização do

projeto, todas baseadas nas tecnologias mostradas no capítulo anterior. A metodologia a ser

seguida para o desenvolvimento do projeto consiste em pesquisa bibliográfica sobre

Engenharia de Software, UML, a linguagem de programação PHP e o Sistema Gerenciador

de Banco de Dados MySQL.

O primeiro ponto diz respeito às abordagens de processo de software escolhidas

para o projeto. Associando as informações anteriores do item Engenharia de Software ao

caso no qual está inserido o projeto da implementação do sistema para o colegiado do curso

de Matemática, a opção de modelo de processo de software que melhor se adequa a

situação é a da iteração de processo com desenvolvimento incremental, devido a fatores

como o pouco tempo disponível para a conclusão do projeto, fato que inviabiliza o uso do

modelo em cascata em todas as partes do processo, a não ser no que diz respeito ao

levantamento das funcionalidades principais da aplicação que já estão definidas, assim

abrindo espaço ao uso da estratégia evolucionária adicionando às funções principais já

estabelecidas, os incrementos baseados nos requisitos adicionais que eventualmente possam

aparecer. Dessa forma o uso das melhores funcionalidades de cada estratégia se adequa

melhor a aplicação.

Nos próximos itens serão descritas as ferramentas escolhidas para trabalhar

cada tecnologia adotada, seguindo a seqüência do capítulo anterior, Visual Paradigm para

UML, Zend Studio para PHP e MySQL Query Browser para MySQL.

3.1 Visual Paradigm Community Edition para UML

Visual Paradigm é uma poderosa ferramenta CASE (Computer-Aided Software

Engineering ou Engenharia de software com auxílio de computador), que não trabalha

apenas como ferramenta de modelagem como também fornece uma poderosa ferramenta de

geração de código e engenharia reversa. O gerador instantâneo pode transformar um gráfico

em código fonte sem o mínimo esforço, pode gerar código fonte de 15 linguagens

diferentes (VISUAL PARADIGM, 2008).


34

Além de cuidar da parte de modelagem visual, contem ferramentas que cobrem

todos os aspectos da modelagem e da documentação. Suporta mais de 20 tipos de diagrama,

incluindo todos os tipos de diagrama UML, BPMN, SysML, ERD, DFD entre outros. Tem

ótima diagramação de ambiente, com o intuito de aumentar a eficácia da modelagem.

As funcionalidades acima descritas além do fato do Visual Paradigm possuir a

versão Community Edition de distribuição livre para o espaço acadêmico, contribuíram de

forma decisiva para sua escolha no projeto.

Figura 3.1 – Visão do Visual Paradigm.

Fonte: Elaboração Própria, 2008.


35

3.2 Zend Studio

Editor web orientado à programação de páginas PHP, com auxílio na gestão de

projetos e depuração de código. Zend Studio consta de duas partes nas quais se dividem as

funcionalidades da parte do cliente e as do servidor. A parte do programa que permite

escrever os scripts é bastante útil para a programação em PHP (ALVAREZ, 2008). A

interface está composta por várias partes, nas quais são encontrados um explorador de

arquivos, uma janela de depuração, os menus e outra para mostrar o código das páginas

(ver figura).

Figura 3.2 – Visão do editor de código do Zend Studio.

Fonte: ALVAREZ, 2008.

Os projetos permitem salvar muito mais informação ao programa sobre os

arquivos, discos, servidores, etc. que são providenciados em aplicações PHP.

Zend Studio dispõe de uma ferramenta muito interessante de debug ou

depuração. Com ela pode-se executar páginas e conhecer em todo momento o conteúdo das

variáveis da aplicação e as variáveis do meio como os cookies, as recebidas por formulário


36

ou na sessão. Pode-se colocar pontos de parada dos scripts e realizar as ações típicas de

depuração.

Em comparação com os outros editores da linguagem PHP testados, Zend

Studio se mostrou como a melhor opção, devido ao conjunto de funcionalidades que

proporcionaram escrever o código fonte da aplicação de forma bastante ágil, e a total

compatibilidade com a linguagem usada.

3.3 MySQL Query Browser

MySQL Query Browser é uma ferramenta visual fornecida pela MySQL AB

para criar, executar e otimizar solicitações SQL em um ambiente visual (MySQL, 2008).

Assim como o MySQL Administrator foi criado para administrar um servidor MySQL, o

MySQL Query Browser foi criado para auxiliar a seleção e analise de dados armazenados

dentro de um Banco de Dados MySQL.

Enquanto todas as solicitações executadas no MySQL Query Browser também

podem ser executadas pela linha de comando utilizando-se o utilitário MySQL, o MySQL

Query Browser permite a execução e edição dos dados de maneira visual, que é mais

intuitiva para o usuário. MySQL Query Browser foi projetado para trabalhar com versões

4.0 ou superiores do gerenciador MySQL.

Além de o fator custo pesar na escolha desse aplicativo, (MySQL Query

Browser tem licença freeware) ele apresenta total compatibilidade com o gerenciador

MySQL por serem produzidos pelo mesmo fabricante.


37

Figura 3.3 – Tela do MySQL Query Browser.

Fonte: MySQL, 2008.

Capítulo 4 – Modelagem do Sistema

38

CAPÍTULO 4 – Modelagem do Sistema

Neste capítulo será abordada a modelagem da aplicação web desenvolvida para

o colegiado do curso de matemática. O processo de modelagem tem como finalidade, tornar

visíveis as funcionalidades do sistema, e as ações de cada ator envolvido, através do uso

dos diagramas da linguagem UML e da ferramenta de criação de diagramas Visual

Paradigm Community Edition para UML.

4.1 Análise de Requisitos

Após os estudos de viabilidade do sistema, os requisitos foram levantados

através de entrevistas realizadas com o coordenador do curso de matemática e os bolsistas

do colegiado do curso.

A proposta foi desenvolver uma aplicação web com o propósito de facilitar a

visualização do histórico acadêmico e informações extras por parte dos alunos, como

materiais de apoio, TCC’s e outros, além da inserção de rotinas de controle sobre as

informações dos discentes por parte dos funcionários e conteúdo aberto sobre o curso

voltado ao público externo.

4.2 Diagramas de Caso de Uso

Como mencionado anteriormente, é o diagrama mais geral e informal da UML,

procura identificar os atores (usuários, outros sistemas ou até mesmo algum hardware

especial), que utilizarão de alguma forma o software, bem como os serviços, ou seja, as

opções que o sistema disponibilizará aos atores (GUEDES, 2006).

4.2.1 Diagrama de Caso de Uso – Visão Geral

Para que se pudesse entender de forma mais fácil o sistema do colegiado de

matemática, tornou-se necessário a elaboração de um diagrama que desse uma visão geral

da aplicação, sem abordar de forma mais específica os papeis e funções de cada ator

envolvido.


39

No diagrama estão presentes três atores que desempenham funções distintas

dependendo das informações que acessam. Convencionou-se chamar de conteúdo geral a

junção de todos os conteúdos disponibilizados na aplicação e suas respectivas funções. As

ações da cada ator ao interagir com os conteúdos serão mostradas a seguir:

Visualizar Conteúdo Aberto: um usuário qualquer que navegue pela página

do curso de matemática, tem a disposição diversos tipos de conteúdos, alguns para

visualização e outros disponíveis para download caso julgue necessário.

Visualizar Conteúdo Irrestrito: nessa área do sistema só dois atores têm

acesso, o aluno e o funcionário do colegiado, desde que, devidamente cadastrados e

mediante a inserção de login e senha corretos para que se iniciem uma sessão na área

restrita.

Na seção do funcionário existem opções administrativas ao seu alcance, como

editar informações pertinentes ao cadastro de turmas matriculadas, alunos e históricos

acadêmicos. Já na seção do aluno, o mesmo tem as opções de atualizar seus dados

cadastrais e fazer visualização momentânea do seu histórico, podendo proceder na

impressão do mesmo caso julgue necessário.


40

Figura 4.1 – Diagrama de caso de uso da visão geral.


4.2.2 Diagrama de Caso de Uso – Acesso Público

Esse caso de uso tem por finalidade mostrar com mais detalhes a idéia de

acesso público mencionada no caso de uso geral através do termo Visualizar Conteúdo

Aberto.

Visualizar Conteúdo: o usuário navega pelas seções constantes da página

principal.

Visualizar Projeto de TCC: o usuário que navega nessa seção e visualiza num

banco de dados os TCC’s dos alunos do curso de matemática.


41

Baixar TCC: após ler o resumo descritivo de cada TCC, o usuário tem a opção

de realizar o download do arquivo que lhe interessar.

Visualizar Material de Apoio: nessa seção o usuário navega pela lista de

arquivos disponíveis, arquivos disponibilizados pelos professores do curso.

Baixar Material de Apoio: a partir das descrições dos arquivos, o usuário pode

realizar o download do arquivo que desejar.

Figura 4.2 – Diagrama de caso de uso do acesso público.



42

4.2.2.1 Documentação do Caso de Uso – Acesso Público

As tabelas abaixo contem a documentação dos casos de uso do diagrama acesso

público, descrvendo as etapas realizadas pelo ator usuário.

Tabela 4.1: Documentação do caso de uso visualizar conteúdo.

Nome do Caso de Uso Visualizar Conteúdo Caso de Uso Geral Ator principal Usuário Atores secundários Resumo Este caso de uso descreve as etapas realizadas

pelo usuário para visualização do conteúdo de acesso público.

Pré-Condições Pós-Condições Ações do Ator Ações do Sistema 1. Escolher o conteúdo a ser visualizado ou baixado em determinada seção.

2. Exibir os conteúdos disponíveis na seção escolhida.

Restrições / Validações



43

Tabela 4.2: Documentação do caso de uso visualizar projeto de TCC.

Nome do Caso de Uso Visualizar Projeto de TCC Caso de Uso Geral Visualizar Conteúdo Ator principal Usuário Atores secundários Resumo

Este caso de uso descreve as etapas realizadas pelo usuário para visualização do conteúdo da seção de Projeto de TCC’s.

Pré-Condições Pós-Condições Ações do Ator Ações do Sistema 1. Escolher o conteúdo a ser visualizado.



Tabela 4.3: Documentação do caso de uso baixar TCC.

Nome do Caso de Uso

Baixar TCC

Caso de Uso Geral Visualizar Projeto de TCC Ator principal Usuário Atores secundários Resumo

Este caso de uso descreve as etapas realizadas pelo usuário para fazer o download dos TCC’s.

Pré-Condições Pós-Condições Ações do Ator Ações do Sistema 1. Escolher o arquivo do TCC a ser baixado.

2. Mostrar o arquivo escolhido. 3. Salvar o arquivo. Restrições / Validações



44

Tabela 4.4: Documentação do caso de uso visualizar material de apoio.

Nome do Caso de Uso Visualizar Material de Apoio Caso de Uso Geral Visualizar Conteúdo Ator principal Usuário Atores secundários Resumo

Este caso de uso descreve as etapas realizadas pelo usuário para visualização dos conteúdos da seção de Materiais de Apoio.

Pré-Condições Pós-Condições Ações do Ator Ações do Sistema 1. Escolher o conteúdo a ser visualizado.



Tabela 4.5: Documentação do caso de uso baixar material de apoio.

Nome do Caso de Uso Baixar Material de Apoio Caso de Uso Geral Visualizar Material de Apoio Ator principal Usuário Atores secundários Resumo

Este caso de uso descreve as etapas realizadas pelo usuário para fazer o download dos materiais de apoio.

Pré-Condições Pós-Condições Ações do Ator Ações do Sistema 1. Escolher o arquivo do material de apoio a ser baixado.

2. Mostrar o arquivo escolhido. 3. Salvar o arquivo. Restrições / Validações



45

4.2.3 Diagrama de Caso de Uso – Acesso Irrestrito – Visão do Funcionário

Esse caso de uso mostra as tarefas do funcionário no sistema.

Realizar Login: o funcionário para ter acesso a parte restrita do sistema

correspondente as suas tarefas, precisa fazer o login informando seu nome de usuário e

senha corretos e previamente cadastrados.

Manter Aluno: nesta área o funcionário pode fazer as alterações necessárias

nas informações referentes aos alunos.

Manter Turma: nesse setor o funcionário pode alterar as informações das

turmas constantes no sistema.

Manter Histórico: o funcionário altera as informações nos históricos

acadêmicos dos alunos e disponibiliza para que os alunos possam fazer consulta.


46

Figura 4.3 – Diagrama de caso de uso do acesso irrestrito (Visão Funcionário).


4.2.3.1 Documentação do Caso de Uso – Acesso Irrestrito – Visão do Funcionário

As tabelas abaixo contém a documentação dos casos de uso do diagrama acesso

irrestrito segundo a visão do funcionário, descrvendo as etapas realizadas pelo ator

funcionário.


47

Tabela 4.6: Documentação do caso de uso realizar login.

Nome do Caso de Uso Realizar Login Caso de Uso Geral Ator principal Funcionário Atores secundários Resumo

Este caso de uso descreve as etapas realizadas pelo funcionário para realizar o login no sistema.

Pré-Condições O login e a senha precisam ser validados. Pós-Condições Realizar logout para deixar o sistema com

segurança. Ações do Ator Ações do Sistema 1. Inserir nome de login e a senha.

2. Consultar se os dados de login e senha estão corretos.

3. Mostrar opções de manutenção de dados cadastrais dos alunos, turmas e históricos acadêmicos.


1. Para realizar login é preciso ser funcionário do curso de matemática e estar incluso no banco de dados do sistema.



48

Tabela 4.7: Documentação do caso de uso manter aluno.

Nome do Caso de Uso Manter Aluno Caso de Uso Geral Realizar Login Ator principal Funcionário Atores secundários Resumo

Este caso de uso descreve as etapas realizadas pelo funcionário para realizar a manutenção do ator aluno.

Pré-Condições O login e a senha precisam ser validados.

Pós-Condições Realizar logout para deixar o sistema com segurança.

Ações do Ator Ações do Sistema 1. Visualiza e seleciona a turma desejada.

2. Consulta e depois exibe os alunos cadastrados na turma escolhida.

3. Escolher o aluno para realizar a manutenção dos dados.

4. Exibe os dados do aluno selecionado permitindo sua atualização.

5. Realiza a atualização nos dados do aluno escolhido.

6. Salva as alterações realizadas. 7. O sistema atualiza as alterações em seu

banco de dados. Restrições / Validações 1. Os dados referentes ao login e senha dos

alunos não podem ser alterados.



49

Tabela 4.8: Documentação do caso de uso manter turma.

Nome do Caso de Uso Manter Turma Caso de Uso Geral Realizar Login Ator principal Funcionário Atores secundários Resumo

Este caso de uso descreve as etapas realizadas pelo funcionário para realizar a manutenção das turmas.



Ações do Ator Ações do Sistema 1. Visualiza e seleciona a turma desejada.

2. Consulta e depois exibe as turmas cadastradas.

3. Escolher a turma para realizar a manutenção dos dados.

4. Exibe os dados da turma selecionada permitindo sua atualização.

5. Realiza a atualização na turma escolhida.

6. Salva as alterações realizadas.

7. O sistema atualiza as alterações em seu banco de dados.




50

Tabela 4.9: Documentação do caso de uso manter histórico.

Nome do Caso de Uso Manter Histórico Caso de Uso Geral Realizar Login Ator principal Funcionário Atores secundários Resumo

Este caso de uso descreve as etapas realizadas pelo funcionário para realizar a manutenção nos históricos acadêmicos dos alunos.


segurança. Ações do Ator Ações do Sistema 1. Visualiza e seleciona a turma desejada.

2. Consulta e depois exibe os alunos cadastrados na turma escolhida.

3. Escolher o aluno para realizar a manutenção dos dados do histórico acadêmico.

4. Exibe os dados do histórico do aluno selecionado permitindo sua atualização.

5. Realiza a atualização nos dados do histórico do aluno escolhido.

6. Salva as alterações realizadas.

7. O sistema atualiza as alterações em seu banco de dados.



4.2.4 Diagrama de Caso de Uso – Acesso Irrestrito – Visão do Aluno

Esse caso de uso mostra detalhadamente as ações do aluno no sistema.

Realizar Login: o aluno previamente cadastrado insere o nome de usuário e

senhas corretos, para ter seu acesso ao sistema validado.


51

Manter Alunos: o aluno após validar sua entrada no sistema, pode alterar suas

informações cadastrais de cunho pessoal e de contato. As informações de cadastro

acadêmico como número de matrícula por exemplo, não podem ser editadas pelo aluno.

Visualizar Histórico: o aluno pode visualizar as informações referentes ao seu

histórico acadêmico.

Imprimir Histórico: após a visualização o aluno tem a opção de imprimir seu

histórico para posterior consulta.

Figura 4.4 – Diagrama de caso de uso do acesso irrestrito (Visão Aluno).



52

4.2.4.1 Documentação do Caso de Uso – Acesso Irrestrito – Visão do Aluno

As tabelas a seguir contem a documentação dos casos de uso do diagrama

acesso irrestrito segundo a visão do aluno, descrvendo as etapas realizadas pelo ator aluno.

Tabela 4.10: Documentação do caso de uso realizar login.

Nome do Caso de Uso Realizar Login Caso de Uso Geral Ator principal Aluno Atores secundários Funcionário Resumo

Este caso de uso descreve as etapas realizadas pelo aluno para realizar o login no sistema.


segurança. Ações do Ator Ações do Sistema 1. Inserir nome de login e a senha.

2. Consultar se os dados de login e senha estão corretos.

3. Mostrar opções de alteração de dados cadastrais e visualização de histórico.


1. Para realizar login é preciso ser aluno do curso de matemática e estar incluso no banco de dados do sistema.



53

Tabela 4.11: Documentação do caso de uso manter alunos.

Nome do Caso de Uso Manter Alunos Caso de Uso Geral Realizar Login Ator principal Aluno Atores secundários Funcionário Resumo Este caso de uso permite realizar a atualização de

seus dados cadastrais. Pré-Condições O login e a senha precisam ser validados. Pós-Condições Realizar logout para deixar o sistema com

segurança. Ações do Ator Ações do Sistema

1. O sistema consulta e depois exibe os dados cadastrais ao usuário.

2. Visualizar dados cadastrais. 3. Proceder a alteração dos dados cadastrais (se necessário).

4. Salvar as alterações realizadas. Restrições / Validações 1. O usuário não poderá alterar os dados

referentes ao login e senha.


Tabela 4.12: Documentação do caso de uso visualizar histórico.

Nome do Caso de Uso Visualizar Histórico Caso de Uso Geral Realizar Login Ator principal Aluno Atores secundários Funcionário Resumo

Este caso de uso permite realizar a visualização do histórico acadêmico do usuário.


segurança. Ações do Ator Ações do Sistema

1. O sistema consulta e depois exibe o histórico acadêmico ao usuário.

2. Visualizar o histórico. Restrições / Validações



54

Tabela 4.13: Documentação do caso de uso imprimir histórico.

Nome do Caso de Uso Imprimir Histórico Caso de Uso Geral Visualizar Histórico Ator principal Aluno Atores secundários Funcionário Resumo

Este caso de uso permite realizar a impressão do histórico acadêmico atualizado do usuário.



Ações do Ator Ações do Sistema

1. O sistema consulta e depois exibe o histórico acadêmico ao usuário.

2. Visualizar o histórico. 3. O usuário realiza a impressão do histórico.



4.3 Diagrama de Classes

O diagrama de classes é o mais utilizado e o mais importante da UML. Serve de

apoio para a maioria dos demais diagramas. Como o próprio nome diz, define a estrutura

das classes utilizadas pelo sistema (GUEDES, 2006).

No diagrama de classes do sistema foram identificadas as seguinte classes:

Classe Funcionário: possui os atributos, Nome e Senha. Possui as operações,

incluirTurma, incluirAluno, manterNota e alterarSenha.

Classe Alunos: possui os seguintes atributos, matrícula, nome, senha,

endereço, telefone e e-mail. Possui as operações, visualizarHistórico e alterarDados. Possui

também associação com a classe Funcionário que é responsavel por gerenciar todas as

informações referentes aos alunos e possui mais duas classes, a classe Disciplinas e a classe

AlunosDisciplinas que resulta do relacionamento das duas classes anteriores.


55

Classe Disciplinas: possui os atributos coddisciplina, nome, creditos,

cargahoraria e tipo. É uma extensão da classe Alunos.

Classe AlunosDisciplinas: possui os atributos matricula, coddisciplina, ano,

período, Frequencia, Conceito, Situação, CR. É a classe derivada da relação entre as classes

Alunos e Disciplinas.

Classe Turmas: possui o atributo, ano. Deriva da classe AlunosDisciplinas.

Classe Períodos: possui o atributo, período. Deriva da classe Disciplinas.

Figura 4.5 – Diagrama de classes do sistema.



56

4.4 Diagrama de Objetos

O Diagrama de Objetos está amplamente associado ao Diagrama de Classes. Na

verdade, o Diagrama de Objetos é praticamente um complemento do Diagrama de Classes e

bastante dependente deste, ele fornece uma visão dos valores armazenados pelos objetos de

um Diagrama de Classes (GUEDES, 2006). A seguir o diagrama de objetos do sistema.

Figura 4.6 – Diagrama de objetos do sistema.



57

4.5 Diagrama de Seqüência

O Diagrama de Seqüência costuma identificar o evento gerador do processo

modelado, bem como o ator responsável por esse evento, e determina como o processo

deve se desenrolar e ser concluído (GUEDES, 2006).

A seguir serão exibidos os diagramas de seqüência realizar login segundo a

visão do funcionário e aluno, incluir notas e alterar dados na visão do aluno.

Realizar Login (Visão Funcionário): o funcionário insere no sistema as

informações requeridas no login (nome e senha), o sistema faz uma chamada ao banco de

dados, que consulta as informações inseridas pelo funcionário, em caso de consulta positiva

(informações existentes no banco de dados) o sistema exibe a página do funcionário com o

menu de suas atividades.

Figura 4.7 – Diagrama de seqüência realizar login (Visão Funcionário).



58

Realizar Login (Visão Aluno): o aluno insere no sistema as informações

requeridas no login (matrícula e senha), o sistema faz uma chamada ao banco de dados, que

consulta as informações inseridas pelo aluno, em caso de consulta positiva (informações

existentes no banco de dados) o sistema exibe a página do aluno com o menu de suas

atividades.

Figura 4.8 – Diagrama de seqüência realizar login (Visão Aluno).


Incluir Nota: o funcionário insere no sistema as informações requeridas no

login (nome e senha), o sistema faz uma chamada ao banco de dados, que consulta as

informações inseridas pelo funcionário, em caso de consulta positiva (informações

existentes no banco de dados) o sistema exibe a página do funcionário com o menu de suas

atividades. Após selecionar no menu a opção Incluir Nota, o sistema solicitará a inclusão do

número de matrícula do aluno em que se deseja incluir a nota, após essa confirmação o

sistema exibirá uma listagem com todas as disciplinas, ao selecionar uma disciplina será

mostrado um formulário com opção de inclusão de informações do período, freqüência,


59

conceito e situação, caso insira os dados corretamente, o sistema atualiza os novos dados e

exibe uma mensagem de sucesso.

Figura 4.9 – Diagrama de seqüência incluir nota.



60

Alterar Dados (Visão Aluno): o aluno insere no sistema as informações

requeridas no login (matrícula e senha), o sistema faz uma chamada ao banco de dados, que

consulta as informações inseridas pelo aluno, em caso de consulta positiva (informações

existentes no banco de dados) o sistema exibe a página do aluno com o menu de suas

atividades. Após selecionar no menu a opção Alterar Dados, o sistema exibirá um

formulário com as opções de alteração dos dados de senha de acesso, endereço, telefone e

e-mail, caso insira os dados corretamente, o sistema atualiza os novos dados e exibe uma

mensagem de sucesso.

Figura 4.10 – Diagrama de seqüência alterar dados (Visão Aluno).



61

4.6 DER (Diagrama Entidade-Relacionamento)

Um modelo de banco de dados é uma descrição dos tipos de informações que

estão armazenadas em um banco de dados A técnica de modelagem de dados mais

difundida e utilizada é a abordagem entidade-relacionamento (HEUSER, 1998). Nesta

técnica, o modelo de dados é representado através de um modelo entidade-relacionamento

(modelo ER). Usualmente, um modelo ER é representado graficamente, através de um

diagrama entidade-relacionamento (DER).

O DER da aplicação é formado pelas seguintes tabelas:

Tabela Funcionário: a entidade Funcionário possui os atributos nome e senha,

cardinalidade 1 : N (um para muitos) e está associado com todas as outras entidades do

DER.

Tabela Alunos: a entidade Alunos possui os atributos matrícula, nome, senha,

endereço, telefone e email. Possui cardinalidade 1 : N, associa-se com as entidades

Funcionário e Disciplinas. Tem como chave primária o atributo matrícula.

Tabela Disciplinas: a entidade disciplinas possui os atributos código, nome,

créditos, cargahoraria, tipo. Possui cardinalidade 1 : N, associa-se com a entidade Alunos.

Tem como chave primária o atributo código que também é uma das chaves primárias da

tabela AlunosDisciplinas.

Tabela AlunosDisciplinas: a entidade AlunosDisciplinas é resultado da

associação entre as entidades Alunos e Disciplinas, possui os atributos alunosmatricula,

disciplinascodigo, períodosperiodo, freqüência, conceito, situação, CR e ano. Possui

cardinalidade 1 : N. Suas chaves primárias são alunosmatricula e disciplinascodigo,

herdadas das tabelas Alunos e Disciplinas respectivamente.

Tabela Turmas: a entidade Turmas possui o atributo ano. Possui cardinalidade

1 : 1 (um para um) e associa-se a tabela AlunosDisciplinas. Tem como chave primária o

atributo ano.


62

Tabela Períodos: a entidade Período possui o atributo periodo. Possui

cardinalidade 1 : 1 e associa-se a tabela AlunosDisciplinas. Sua chave primária é o atributo

periodo.

Figura 4.11 – DER do banco de dados do sistema.


Capítulo 5 – Considerações Finais

63

CAPÍTULO 5 – Considerações Finais

A partir de contatos feitos com o coordenador do curso de matemática do

campus de Marabá da UFPA, ficaram evidenciadas deficiências nas rotinas que fazem parte

do cotidiano do colegiado do curso de matemática, e como forma de solucionar os

problemas enumerados pelo coordenador e tornar mais dinâmica as rotinas do colegiado de

forma a contemplar também os alunos do curso e o público em geral interessado em

conhecer detalhes sobre o curso, foi elaborado um sistema web com conteúdo voltado para

o público externo ao ambiente do curso e uma área interna com funcionalidades para os

discentes.

Para alcançar o objetivo do projeto, foi necessário realizar pesquisa nas áreas de

engenharia de software, que compreenderam todos os aspectos de análise de viabilidade e

requisitos do sistema, a escolha do processo de software mais adequado a situação onde o

sistema estava inserido, além de estudo dos aspectos relativos as modelagens necessárias

que serviram de base de apoio para a posterior implementação do código, que teve como

paradigma escolhido a linguagem de modelagem unificada, UML e como ferramenta de

edição da linguagem o software Visual Paradigm para UML na versão Community Edition

e estudo da linguagem de programção PHP voltada basicamente para aplicações em

ambientes web e o servidor de banco de dados MySQL.

A partir das vantagens envolvidas com o ambiente para qual o sistema foi

criado, foi possível desenvolver uma aplicação que atendeu de forma satisfatória aos

requisitos propostos pelos usuários finais diretamente envolvidos no sistema, os

funcionários e alunos do curso de matemática. Durante a realização desse projeto foram

adquiridos conhecimentos importantes, que serão levados para além da vida acadêmica e

possibilitarão e realização de projetos semelhantes no âmbito profissional.

64

REFERÊNCIAS BIBLIOGRÁFICAS

ALVAREZ, M. A. Zend Studio, Dez 2004. Disponível em: http://www.criarweb.com/artigos/265.php Acesso em: 10 out. 2008.

GUEDES, G.T.A., UML, Uma Abordagem Prática. 2 ed. São Paulo, Novatec Editora, 2006.

HEUSER, C.A., Projeto de Banco de Dados. 4 ed. Porto Alegre, Editora Sagra, 1998.

MySQL. Manual MySQL, versão traduzida, Out 2008. Disponível em: http://dev.mysql.com/doc/mysql/pt Acesso em: 11 out. 2008. MySQL. Manual MySQL Query Browser, versão traduzida, Out 2008. Disponível em: http://dev.mysql.com/doc/query-browser/pt/mysql-query-browser-introduction.html Acesso em: 10 out. 2008. PHP. Manual PHP, versão traduzida, Out 2008. Disponível em: http://www.php.net/manual/pt_BR/ Acesso em: 10 out. 2008. SOMMERVILLE, I., Engenharia de Software. 6 ed. São Paulo, Pearson Addsion Wesley,

2003. VISUAL, P. Manual Visual Paradigm, versão traduzida, Out 2008. Disponível em: http://www.visual-paradigm.com/documentation/#vpuml Acesso em: 11 out. 2008.

ANEXO A

Após a etapa de modelagem e desenvolvimento do sistema algumas imagens

das telas da página do colegiado de matemática foram capturadas, para uma visão do

resultado final. A seguir serão exibidas imagens da primeira página do curso de matemática

(que ainda pode ser acessada) e da página criada após o desenvolvimento do sistema, para

efeito de comparação.

Figura A1 – Primeira página do curso de matemática.


Figura A2 – Nova página do curso de matemática.


Na primeira comparação entre as telas se percebe a grande diferença na

disponibilidade de conteúdo entre as páginas, na página antiga os itens disponíveis no menu

não estão todos voltados ao curso de matemática, na nova página todos os conteúdos são

voltados com exclusividade para o curso de matemática.

Seguem mais imagens de telas do sistema, agora com funcionalidades internas

das quais dispõem os atores do sistema, alunos e funcionários. A página desenvolvida nesse

trabalho de conclusão de curso está disponível no endereço eletrônico:

http://www.ufpa.br/marabamat.

Figura A3 – Página de login do aluno.


Figura A4 – Página de controle das funções do aluno.


Figura A5 – Página de login do funcionário.


Figura A6 – Página de controle das funções do funcionário.


Figura A7 – Histórico acadêmico disponível na seção do aluno.


Figura A8 – Seção de material de apoio.


ANEXO B Segue em SQL o código das tabelas do banco de dados do sistema:

create database st_marabamat ; use st_marabamat; (Tabela Alunos) create table alunos ( matricula varchar(11) not null , nome varchar(50) not null, senha varchar(10) not null, endereco varchar(80) not null, telefone int(15) not null, email char(80) not null, primary key (matricula) )type=InnoDB; (Tabela Periodo) create table periodos ( periodo int(1) not null, primary key ( periodo) )type=InnoDB; (Tabela Disciplinas) create table disciplinas ( coddisciplina varchar(15) not null , nome varchar(100) not null, creditos int(1) not null , cargahoraria int(5) not null , tipo char(3) not null, primary key (coddisciplina) ) type=InnoDB; (Tabela Turmas) create table turmas ( ano int(4) not null, primary key (ano) )type=InnoDB;

(Tabela AlunosDisciplinas) create table alunosdisciplinas ( matricula varchar(11) not null , coddisciplina varchar(15) not null, ano int(4) not null , periodo int(1) not null , frequencia float(2,2) not null, conceito char(3) not null, situacao char(3) not null, cr float(2,2) , INDEX (periodo), FOREIGN KEY (periodo) REFERENCES periodos(periodo) ON UPDATE CASCADE, INDEX (matricula), FOREIGN KEY (matricula) REFERENCES alunos(matricula) ON UPDATE CASCADE ON DELETE CASCADE, INDEX (coddisciplina), FOREIGN KEY (coddisciplina) REFERENCES disciplinas(coddisciplina) ON UPDATE CASCADE , INDEX (ano), FOREIGN KEY (ano) REFERENCES turmas(ano) ON UPDATE CASCADE )type=InnoDB; (Tabela Funcionario) create table funcionario ( nome char(40) not null , senha char(40) not null )type=InnoDB;

Documents

UNIVERSIDADE FEDERAL DO PARÁ CURSO DE SISTEMAS DE ... · MySQL Query Browser..... 36 CAPÍTULO 4 – Modelagem do Sistema ... Figura 4.1 – Diagrama de caso de Uso da Visão Geral