ferramentas de auxílio a ead: módulo de controle de eventos para o e-duc@re

Antonio Vitor Elias Swaid Junior

Ferramentas de auxílio a EaD:Módulo de Controle de Eventos para o E-duc@re

Monografia apresentada ao Departamento deCiência da Computação da Universidade Federalde Lavras como parte das exigências do curso dePós-Graduação “Lato Sensu” em Administração deRedes Linux, para obtenção do título de especialista

OrientadorProf. Msc. Joaquim Quinteiro Uchôa

Co-OrientadorProf. Samuel Pereira Dias

LavrasMinas Gerais - Brasil

2004

Antonio Vitor Elias Swaid Junior

Ferramentas de auxílio a EaD:Módulo de Controle de Eventos para o E-duc@re

Monografia apresentada ao Departamento deCiência da Computação da Universidade Federalde Lavras como parte das exigências do curso dePós-Graduação “Lato Sensu” em Administração deRedes Linux, para obtenção do título de especialista

Aprovada em15 de Dezembro de 2004

Profa. Msc. Kátia Cilene Amaral Uchôa

Prof. Msc. Joaquim Quinteiro Uchôa(Orientador)

Prof. Samuel Pereira Dias(Co-Orientador)

LavrasMinas Gerais - Brasil

Agradecimentos

A Deus pela vida e pela força para lutar.A meus pais pelo incentivo que sempre deram, mesmo tendo agoraminha própria família para cuidar.A minha família pelo apoio nas horas mais difíceis.Aos professores do ARL que mesmos distantes sempre estavam porperto.Ao Prof. Joaquim pela oportunidade do trabalho.Ao Samuel por todo apoio técnico e críticas.A Profa. Kátia por aceitar fazer parte da banca e por sua indispensávelcolaboração.A minha irmã Alessandra pela sua ajuda e força.A meu pai pela sua fundamental presença para que eu pudesse apre-sentar este trabalho.A todos que de uma forma ou de outra colaboraram para que eu pu-desse escrever este trabalho e que tenho certeza não haveriaespaçosuficiente para escrever tantos nomes nesta página.

v

Resumo

O objetivo deste trabalho é demonstrar um módulo de controlee ge-renciamento de eventos como ferramenta auxiliar para EaD contex-tualizado na necessidade atual do curso de pós graduaçãoLato Sensuem Administração de Redes Linux da Universidade Federal de Lavrasem adição ao sistemaE-duc@re

vii

Dedico este trabalho a minha esposa e filha pela paciência, compreensão ecolaboração para sua conclusão.

ix

Sumário

1 Introdução 1

2 Revisão de Literatura 52.1 Educação a Distância . . . . . . . . . . . . . . . . . . . . . . . . 52.2 Educação a Distância na UFLA . . . . . . . . . . . . . . . . . . . 82.3 O Curso ARL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.4 Proposta do novo módulo de Eventos . . . . . . . . . . . . . . . . 12

3 Metodologia 153.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.2 Casos de Uso (Use Cases) . . . . . . . . . . . . . . . . . . . . . 183.3 Diagramas Entidade Relacionamento (E-R) e Modelo Relacional . 193.4 Programação Orientada a Objetos . . . . . . . . . . . . . . . . . 213.5 PHP Orientado a Objetos . . . . . . . . . . . . . . . . . . . . . . 223.6 Comentários . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4 Modelagem 254.1 Banco de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.1.1 Normalização . . . . . . . . . . . . . . . . . . . . . . . . 274.1.2 Descrição detalhada das Entidades . . . . . . . . . . . . . 28

4.2 Descrição do módulo em UML . . . . . . . . . . . . . . . . . . . 354.2.1 Fluxo de Eventos dos casos de uso . . . . . . . . . . . . . 36

5 Implementação 575.1 Ferramentas de ’Tipo de Evento’ . . . . . . . . . . . . . . . . . . 59

5.1.1 Criar um Novo Tipo de Evento . . . . . . . . . . . . . . . 595.1.2 Exibir os Tipos de Evento . . . . . . . . . . . . . . . . . 615.1.3 Modificar um Tipo de Evento . . . . . . . . . . . . . . . 615.1.4 Apagar um Tipo de Evento . . . . . . . . . . . . . . . . . 61

xi

5.2 Ferramentas de ’Evento’ . . . . . . . . . . . . . . . . . . . . . . 625.2.1 Criar um Novo Evento . . . . . . . . . . . . . . . . . . . 625.2.2 Exibir Eventos . . . . . . . . . . . . . . . . . . . . . . . 635.2.3 Modificar Evento . . . . . . . . . . . . . . . . . . . . . . 635.2.4 Apagar Evento . . . . . . . . . . . . . . . . . . . . . . . 66

5.3 Ferramentas de ’Sub-Evento’ . . . . . . . . . . . . . . . . . . . . 665.3.1 Criar um Novo Sub-Evento para ’Evento’ . . . . . . . . . 665.3.2 Exibir os Sub-Eventos . . . . . . . . . . . . . . . . . . . 685.3.3 Modificar ’Sub-Evento’ . . . . . . . . . . . . . . . . . . 695.3.4 Apagar um Sub-Evento . . . . . . . . . . . . . . . . . . . 69

5.4 Ferramentas Administrativas . . . . . . . . . . . . . . . . . . . . 725.4.1 Inserir Turma no Público Alvo . . . . . . . . . . . . . . . 725.4.2 Analisar Inscrição . . . . . . . . . . . . . . . . . . . . . 725.4.3 Inscrever Aluno no Evento . . . . . . . . . . . . . . . . . 755.4.4 Exibir Inscrito em Evento . . . . . . . . . . . . . . . . . 765.4.5 Imprimir Lista de Presença . . . . . . . . . . . . . . . . . 765.4.6 Inscrever Sub-Evento Alternativo . . . . . . . . . . . . . 775.4.7 Preencher Lista de Presença Eletrônica . . . . . . . . . . 785.4.8 Avaliar Presença no Evento . . . . . . . . . . . . . . . . 785.4.9 Convocar Aluno . . . . . . . . . . . . . . . . . . . . . . 79

6 Conclusão 85

A Apêndices 89A.1 GuidelinesPara o Desenvolvimento Padronizado . . . . . . . . . 89A.2 Estatísticas de Utilização de Apache e PHP . . . . . . . . . . . .89

xii

Lista de Figuras

2.1 Tela Inicial doEduc@re . . . . . . . . . . . . . . . . . . . . . . 11

3.1 Exemplo de Nomes de Casos de Uso . . . . . . . . . . . . . . . . 193.2 Exemplo de Atores . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.1 Diagrama Entidade Relacionamento . . . . . . . . . . . . . . . . 264.2 Modelo Relacional - Tabelas . . . . . . . . . . . . . . . . . . . . 294.3 Diagrama Entidade Relacionamento . . . . . . . . . . . . . . . . 35

5.1 Adicionar ’Tipo de Evento’ - Tela Inicial . . . . . . . . . . . . .. 595.2 Adicionar ’Tipo de Evento’ - Exemplo . . . . . . . . . . . . . . . 605.3 Adicionar ’Tipo de Evento’ - Operação Realizada com Sucesso . . 605.4 Exibir ’Tipo de Evento’ . . . . . . . . . . . . . . . . . . . . . . . 615.5 Modificar ’Tipo de Evento’ . . . . . . . . . . . . . . . . . . . . . 625.6 Apagar ’Tipo de Evento’ . . . . . . . . . . . . . . . . . . . . . . 635.7 Adicionar Eventos - Tela Inicial . . . . . . . . . . . . . . . . . . 645.8 Adicionar Eventos - Exemplo . . . . . . . . . . . . . . . . . . . . 655.9 Adicionar Eventos - Operação Realizada com Sucesso . . . .. . 665.10 Exibir Eventos . . . . . . . . . . . . . . . . . . . . . . . . . . . 665.11 Modificar Eventos . . . . . . . . . . . . . . . . . . . . . . . . . . 675.12 Apagar Eventos . . . . . . . . . . . . . . . . . . . . . . . . . . . 685.13 Adicionar Sub-Eventos - Tela Inicial . . . . . . . . . . . . . . .. 695.14 Adicionar Sub-Eventos - Exemplo . . . . . . . . . . . . . . . . . 705.15 Adicionar Sub-Eventos - Operação Realizada com Sucesso . . . . 705.16 Exibir Sub-Eventos . . . . . . . . . . . . . . . . . . . . . . . . . 715.17 Modificar Sub-Eventos . . . . . . . . . . . . . . . . . . . . . . . 715.18 Apagar Sub-Eventos . . . . . . . . . . . . . . . . . . . . . . . . 725.19 Adicionar Turma no Publico Alvo de um Evento - Tela Inicial . . 735.20 Adicionar Turma no Publico Alvo de um Evento - Exemplo . .. . 735.21 Adicionar Turma no Publico Alvo de um Evento - Lista de Alunos 74

xiii

5.22 Analisar Inscrições . . . . . . . . . . . . . . . . . . . . . . . . . 745.23 Analisar Inscrições - Lista de Alunos Inscritos . . . . . .. . . . . 755.24 Inscrever Aluno em Evento . . . . . . . . . . . . . . . . . . . . . 765.25 Exibir Inscrito em Evento . . . . . . . . . . . . . . . . . . . . . . 765.26 Imprimir Lista de Presença - Selecionando um Evento . . .. . . . 775.27 Imprimir Lista de Presença - Selecionando um Sub-Evento . . . . 775.28 Imprimir Lista de Presença - Lista Final (em Tela) . . . . .. . . . 785.29 Inscrever Sub-Evento Alternativo . . . . . . . . . . . . . . . . .. 795.30 Preencher Lista de Presença Eletrônica . . . . . . . . . . . . .. . 805.31 Avaliar Presença - Aluno está com Pendências . . . . . . . . .. . 815.32 Avaliar Presença - Aluno sem Pendências . . . . . . . . . . . . .825.33 Convocar Aluno - Listagem Inicial . . . . . . . . . . . . . . . . . 825.34 Convocar Aluno - Listagem Intermediária . . . . . . . . . . . .. 835.35 Convocar Aluno - Rodapé da Listagem . . . . . . . . . . . . . . . 83

A.1 Guidelinesde desenvolvimento para o E-duc@re 1/4 . . . . . . . 90A.2 Guidelinesde desenvolvimento para o E-duc@re 2/4 . . . . . . . 91A.3 Guidelinesde desenvolvimento para o E-duc@re 4/4 . . . . . . . 92A.4 Guidelinesde desenvolvimento para o E-duc@re 4/4 . . . . . . . 93A.5 Utilização do Apache como servidorweb1/4 . . . . . . . . . . . 94A.6 Utilização do Apache como servidorweb2/4 . . . . . . . . . . . 95A.7 Utilização do Apache como servidorweb3/4 . . . . . . . . . . . 96A.8 Utilização do Apache como servidorweb4/4 . . . . . . . . . . . 97A.9 Utilização do PHP como linguagem de script para páginasweb . . 98

xiv

Capítulo 1

Introdução

Em tempos contemporâneos, a educação à distância (EaD) vem sendo praticadapor diversos setores da sociedade em âmbito mundial. Os meios utilizados paraatingir o educando estão diretamente relacionados com as tecnologias presentesem cada época da história onde a EaD está sendo praticada.Com o avanço da tecnologia nas últimas décadas, o advento daInternet, e seusvários serviços, vem cada dia mais ser importante meio de comunicação a serviçoda Educação a Distância. Mediante esse fato, houve o surgimento na grande teiade diversos ambientes virtuais de apoio ao ensino à distância tais comoTelEduc1,Serf2, WebLearn3, Manhattan4, entre outros5.Por ambientes virtuais entendem-se sistemas de informática, utilizados atravésde redes de computadores, que buscam unir professores e alunos localizados emquaisquer partes do planeta possibilitando a troca de informações, o direciona-mento e a organização do aprendizado. Essa tentativa de estreitamento de distân-cias pode ser melhor percebida na modalidade de Educação a Distância mediadapelaInternet, também conhecida por educaçãoonline.Em grande parte esses ambientes não estão completamente preparados ou não sãoapropriados para atender as necessidades de instituições ofertadoras dessa modali-dade de educação de acordo com as disposições previstas na legislação e diretrizeseducacionais. Os ítens que precisam ser mais trabalhados estão ligados à ferra-mentas que facilitem as atividades de coordenadoria e administração dos cursos.

1TelEduc- http://teleduc.nied.unicamp.br/teleduc/2SERF- http://serfsoft.com/3WebLearn- http://www.webconsult.com.br/solucoes/weblearn/4Manhattan- http://manhattan.sourceforge.net/5Ver Anexo B

1

Nesse sentido, várias ferramentas como controles de horários, notas, etc. estãosendo desenvolvidas para serem incorporadas nesses ambientes virtuais. Seu obje-tivo é suprir, não somente as necessidades de recursos para suportar aprendizagem,mas também permitir vários controles administrativos e acadêmicos do aluno du-rante a realização de cursos ofertados pela modalidadeonlinede Educação a Dis-tância.O curso de pós graduaçãolato sensuAdministração de Redes Linux (ARL)6 éum curso oferecido na modalidade de EaDonline. Tem como metodologia a dis-ponibilização dos recursos de aprendizagem, administração e coordenação, tantoonline (através de conexão do computador via Internet) quantooffline. Esses re-cursos são tanto para alunos quanto para professores e coordenadores.Em (UCHÔA; UCHÔA, 2004) pode-se obter uma descrição mais detalhada da me-todologia do curso ARL, onde o destaque para a comunicaçãooffline a distânciaestá na utilização de material impresso (apostilas), atividades a distância (avalia-ções), materiais tecnológicos e informáticos (CD-ROM). Para a comunicaçãoon-line destacam-se osite do curso, o ambiente virtual, as ferramentas de apoio e oservidorIRC. Ainda em (UCHÔA; UCHÔA, 2004), pode-se observar que:

“Além dessas formas de comunicação, o curso possuirá atividadespresenciais, como: seminários, preleções, avaliações, defesas de mo-nografia eworkshopssobre diversos assuntos ligados a temática docurso. Essas atividades serão divididas em dois encontros no decorrerdessa especialização com quatro dias cada encontro.”

Conforme o exposto na citação, também faz parte do curso a existência de en-contros presenciais com atividades variadas. Para auxiliar na realização de taisatividades é necessária a existência de ferramentas que facilitem sua administra-ção, coordenação e execução.Para atender as necessidades específicas dos cursos oferecidos na metodologia doARL, a equipe técnica do curso projetou e construiu um conjunto de ferramen-tas de apoio às atividades administrativas descrito em (DIAS, 2003), denominadoE-duc@re7. Em uma primeira instância, o objetivo principal doE-duc@reé ofe-recer recursos para gerenciamento e controle de atividadesadministrativas, de or-ganização e controle de inscrições de eventos presenciais,atuando integrado aoambiente virtual de ensinoTelEduc, que é o ambiente virtual adotado. Em mo-mentos posteriores oTelEducdeverá ser substituído por módulos próprios doE-duc@re, à medida que esse incorporar novos recursos que auxiliem o processoensino-aprendizagemonline.

6ARL - http://ginux.comp.ufla.br/arl/7E-duc@re- http://ginux.comp.ufla.br/arl/educare/

2

Diante desse contexto, este trabalho tem por objetivo propor o desenvolvimentode um novo módulo de gerenciamento de eventos para adequar asnecessidadesda coordenação do curso frente ao mesmo módulo atual doE-duc@re. Esse novomódulo foi criado com o objetivo de criar e gerenciar eventose sub-eventos (comoworkshops, encontros presenciais, etc), criar listas de inscrição de alunos, listasde presença, realizar convocações de alunos para encontrospresenciais e outros.O novo módulo pretende suprir e completar as necessidades degerenciamento deeventos do módulo atual. O desenvolvimento desse novo módulo leva em consi-deraçãoguidelinesapresentados em (DIAS, 2003) e trará a modelagem realizadautilizandoUnified Modeling Language - (UML)8.

8UML - http://www.uml.org/

3

Capítulo 2

Revisão de Literatura

2.1 Educação a Distância

A educação, em sua essência, faz uso dos recursos disponíveis ao educador paratransmitir o conhecimento ao aluno. Esse, por sua vez, retorna informações parao educador, realizando a comunicação que é fundamental no processo ensino-aprendizagem. Na educação a distância, o processo de troca de informações comentendimento entre as partes é o mesmo. Entretanto, os meiosde comunicação uti-lizados no momento em que ocorre o ensino, dependem das tecnologias de trans-missão de informações disponíveis nessa época.Uma das definições de EaD está em (UCHÔA; UCHÔA, 2004) como:

“Diferentes teóricos classificam a educação a distância como mo-dalidade, forma, estratégia educativa diferenciada, ou mesmo comosistema didático, metodologia ou processo educativo. Na maioria dasvezes, a educação a distância é definida como atividade de ensino eaprendizagem que ocorre sem que haja proximidade física entre o tu-tor (o professor no novo ambiente) e os aprendizes. Nessa forma edu-cativa a comunicação entre os vários sujeitos se dá por meio de algumrecurso tecnológico intermediário, tal como: cartas, textos impressos,rádio e teledifusão ou ambientes computacionais.”

Pode-se notar, em relação ao modelo tradicional de ensino presencial, a mudançano papel do aluno nessa modalidade e o conseqüente aumento desua responsabi-lidade frente ao desafio de receber do tutor as orientações necessárias. Nessa novamodalidade de ensino, o aprendiz é o responsável por administrar a quantidade deinformação que ele absorve dos diversos facilitadores (tutores, administradores,

5

outros alunos, etc). No modelo tradicional de ensino, o aluno espera do profes-sor o qual, de certa forma, mais do que apenas orientação define a quantidade deinformação ministrada em cada aula. Também é possível notarque por essa defini-ção de EaD a comunicação com os tutores, o uso dos ambientes virtuais e demaisrecursos tecnológicos disponíveis devem ser o foco do aprendiz no processo daauto-aprendizagem.Ainda, pela legislação brasileira do sistema de ensino, através de (DECRETO2494) que regulamenta o artigo 80 da Lei de Diretrizes e Bases(LEI 9394/96)há outra definição:

“Art. 1o Educação a distância é uma forma de ensino que possibi-lita a auto-aprendizagem, com a mediação de recursos didáticos sis-tematicamente organizados, apresentados em diferentes suportes deinformação, utilizados isoladamente ou combinados, e veiculados pe-los diversos meios de comunicação.”

EaD não é uma modalidade de ensino recente. Sua história remonta as primeirasexperimentações registradas através de cartas e certamente apareceu após o ad-vento da escrita, que possibilitou a primeira maneira de transmitir informação sema necessidade da presença de um locutor. Diversos autores citados em (NUNES,1993) comentam a prática e experimentação da EaD associada aos recursos tecno-lógicos disponíveis durante o período no qual houve a necessidade de se utilizaresta modalidade de educação. O surgimento da imprensa, e comela os meios dedivulgação da informação, colaborou para a difusão dessa modalidade de ensino.Segundo (UCHÔA; UCHÔA, 2004) :

“O século XX é um período histórico de grandes transformaçõesnos contextos políticos, sociais, econômicos e mesmo culturais. Grandeparte dessas modificações devem-se ao impacto das Novas Tecnolo-gias da Informação e Comunicação (NTICs) na sociedade como umtodo. As NTICs possuem como características principais: o uso dastécnicas da telemática e dos meios audio-visuais e a aparição de di-versos dispositivos para o armazenamento, tratamento e difusão deinformação.”

Na prática recente da EaD o uso das NTICs, entre elas aInternete seus serviços,está possibilitando um patamar de interação e de disponibilização de conteúdosnão alcançado em outras épocas da história.Os avanços das telecomunicações e de seu uso pela informática formam um con-junto poderoso em termos de meio de comunicação usado pelaInternet. A uniãodos termos "telecomunicações"e "informática"é denominado por alguns autores

6

como "telemática". Os avanços tecnológicos da telemática favorecem a transmis-são de informações complexas e de grande volume em intervalos de tempo cadavez menores. Devido ao fato da diminuição do tempo de resposta proporcionadoao usar esses meios de comunicação, pode ser notado o relacionamento estrito en-tre a disponibilidade das NTICs e a maneira como se pratica EaD em termos demeio de comunicação.Com base nas definições citadas anteriormente pode-se dizerque qualquer situaçãoformal de ensino-aprendizagem que envolve troca de informação entre interlocu-tores, seja falada ou escrita, sem existir o contato visual direto entre as partes podeser considerado EaD. Os meios de comunicação utilizados, são fatores relevantesna prática da EaD e dependem da disponibilidade das tecnologias dos veículos deinformação para alunos e tutores. As tecnologias de redes decomputadores e asderivadas daInternetestão dia após dia mais presentes na utilização da EaD.No Brasil EaD está tomando espaço cada vez mais significativoentre as institui-ções de ensino. Essa modalidade propicia aos profissionais já inseridos no mercadoe pessoas a procura de aperfeiçoamento profissional uma aprendizagem continu-ada e de fácil acesso. Através dessa alternativa é possível atender as exigênciasque o mercado de trabalho vem impondo nos últimos tempos.Para fomentar e auxiliar nas atividades regulatórias relacionadas a EaD no Brasilfoi criada a Secretaria de Educação a Distância (SEED)(MEC, 2001)1:

“... em 27 de maio de 1996, o Decreto no 1.917 criou a Secretariade Educação a Distância (SEED) como um órgão integrante da Es-trutura Regimental do Ministério da Educação (MEC). O regimentoda Secretaria está estabelecido no Decreto 3.501, de 12 de junho de2000.(...)A SEED é a responsável pela definição e implantação da política deeducação a distância do MEC, em articulação com as áreas afins.”

Com a publicação do (DECRETO 2494/01), que regulamenta o artigo 80 da Leide Diretrizes e Bases do ensino (LEI 9394/96), torna-se obrigatória a realizaçãode atividades presenciais para cursos ministrados na modalidade de EaD. Nessedecreto, em seu artigo 7o, isso é caracterizado para as instituições de ensino auto-rizadas pelo MEC da seguinte maneira:

“Art. 7o A avaliação do rendimento do aluno para fins de promo-ção, certificação ou diplomação, realizar-se-á no processopor meio deexames presenciais, de responsabilidade da Instituição credenciada

1SEED - http://www.mec.gov.br/seed/

7

para ministrar o curso, segundo procedimentos e critérios definidosno projeto autorizado.”[grifo nosso]

Mais recentemente o Conselho Nacional de Educação (CNE)2 e sua Câmara deEducação Superior (CES) publicaram a Resolução CNE/CES no 1 de abril de 2001,que estabelece as normas para os cursos de pós-graduação reforçou a obrigatori-edade de uma parcela presencial de atividades em cursos de EaD conforme seuartigo 11o :

“Art. 11 Os cursos de pós-graduaçãolato sensua distância sópoderão ser oferecidos por instituições credenciadas pelaUnião, con-forme o disposto no § 1o do art. 80 da Lei 9.394, de 1996.Parágrafo único. Os cursos de pós-graduação lato sensu oferecidosa distânciadeverão incluir, necessariamente, provas presenciaise defesa presencial de monografia ou trabalho de conclusão decurso.”[grifo nosso]

Desse modo ficam as instituições educacionais brasileiras comprometidas a provi-denciar para seus cursos oferecidos na modalidade de EaD, uma logística envol-vendo organização de encontros presenciais. Essa atividade pode compreender aconvocação de alunos para os encontros ou mesmo a realizaçãode exames. O obje-tivo é cumprir os requisitos formais deatividades presenciaisexigidas pelo MEC.

2.2 Educação a Distância na UFLA

A antiga Escola Superior de Agricultura de Lavras (ESAL), fundada em 1908, foifederalizada em 1994 para dar origem a Universidade Federalde Lavras (UFLA)3.Com quase um século de existência, a Universidade Federal deLavras consolidou-se pelo seu pioneirismo ao longo de sua história.Em 1976 foi fundada a Fundação de Apoio, Ensino, Pesquisa e Extensão (FA-EPE)4 pela Associação dos Professores da UFLA. A FAEPE, que é uma instituiçãosem fins lucrativos, tem como missão o apoio institucional à UFLA e, para tanto,desempenha atividades efetivas de ensino, pesquisa, cultura e extensão. Comofundação integrada à estrutura organizacional da UFLA proporciona meios para acaptação, viabilização dos programas de ensino, pesquisa,extensão e desenvolvi-mento da instituição.

2CNE - http://www.mec.gov.br/cne/3UFLA - http://www.ufla.br/4FAEPE - http://www.faepe.org.br/

8

A parceria entre a UFLA e a FAEPE oferece e viabiliza cursos depós-graduaçãoLato Sensu(especialização) na modalidade de Educação a Distância há 17 anos.Vale mencionar que a UFLA é credenciada pelo MEC para ministrar tais cursos.Ela é considerada a maior universidade do país no oferecimento de cursos de pós-graduação na modalidade de EaD, comprovando mais uma vez o pioneirismo dainstituição.Dentre os inúmeros cursosLato Sensuoferecidos por essa instituição encontra-seo curso de Pós-Graduação a Distância, viaInternet, em Administração em RedesLinux (ARL). O curso foi aprovado na Universidade Federal de Lavras com a Por-taria n◦. 367 de 10 de Dezembro de 2001, emitida pela Reitoria. Para obter maisinformações sobre os cursos oferecidos pode-se consultar osite da Open UFLA5

onde estão descritas as áreas, modalidades, disciplinas, etc sobre os cursos minis-trados.

2.3 O Curso ARL

Com a rápida disseminação doLinux nas indústrias, escritórios e ambientes aca-dêmicos, surgiu um espaço para ser preenchido por profissionais habilitados equalificados a lidar com esta nova tecnologia emergente. Como comentado em(UCHÔA; UCHÔA, 2002):

“Diante dessa situação, atualmente presencia-se a necessidade cres-cente de pessoal técnico habilitado em administrar servidoresLinux.Dessa forma, este curso pretende oferecer instrumentos quepermi-tam obter conhecimento aprofundado em Administração em RedesLinux. Pretende-se, assim, aumentar a oportunidade dos alunos atua-rem nesse mercado com maior qualificação.”

Esse curso é oferecido na modalidade de EaD. Isso possibilita que alunos dasmais variadas localizações possam realizá-lo. Sua metodologia prevê a utilizaçãode recursos tantoonline quantooffline. Seu diferencial está no uso dos recursosde telemática como principal meioonline de interação entre tutores e alunos. Autilização das tecnologias daInternetpossibilita para os alunos e tutores a trocafreqüente e rápida de informações. Segundo (UCHÔA; UCHÔA, 2002) os recursosutilizados são:

“Para a comunicaçãoonlinea distância será utilizado o recurso detutoria a distância, o qual se dará principalmente medianteo uso de

5OpenUFLA - http://www.openufla.com.br/

9

e-mails e fóruns de discussão, com o objetivo de dirimir dúvidas comos professores/tutores. As aulas virtuais ocorrerão via chat.(...)Como forma de integrar e facilitar a comunicaçãoonline, será utili-zado o ambiente de ensino Manhattan.(...)Além dessas formas de comunicação, o curso possuiráatividadespresenciais, como: seminários, preleções, avaliações, defesa de mo-nografia e workshops sobre assuntos ligados ao curso. Essas ativida-des serão divididas em doisencontros no decorrer do curso.”[grifonosso]

Para dar suporte as necessidades acadêmicas foi elaborado pela equipe técnica docurso juntamente com a coordenação a configuração e disponibilização de um am-biente virtual. Esse ambiente tem o objetivo de apoiar a disseminação do conhe-cimento para os alunos, a organização das informações e facilitar a comunicaçãoentre os alunos e os tutores. Tudo isso através do uso dos recursos daInternet. Oambiente virtual fica nositedo curso já mencionado na introdução.O primeiro ambiente virtual usado foi o Manhattan. Este ambiente mostrou-sebastante amigável porém de difícil manutenção das salas de aula virtuais, difí-cil administração de alunos entre salas, difícil gerenciamento de várias salas poraluno. Esses fatos levaram a equipe técnica e a coordenação aprocurar novas al-ternativas de ambientes virtuais no decorrer do curso. Nessa busca foi encontradoum projeto nacional conhecido comoTelEducque é oferecido comoSoftwareLi-vre6. Este ambiente virtual é o que está em uso atualmente para o ARL, porémnão atende completamente as necessidades administrativasde um curso de pós-graduação oferecido por uma instituição formal de ensino. As ferramentas dis-poníveis no TelEduc estão ligadas diretamente a recursos deensino como fórunsde discussão, salas de aula virtuais, áreas para disponibilização de literatura emformato eletrônico, inscrições de alunos em turmas, gerenciamento de senhas, etc.Entretanto existe uma lacuna a respeito de ferramentas de ordem administrativapara auxiliar a coordenação em suas atividades.Esse cenário levou a equipe técnica do ARL a realizar uma série de pesquisas queculminaram no início do desenvolvimento de várias ferramentas de apoio admi-nistrativo com o objetivo de dar melhor suporte ao curso. Essas ferramentas foramprojetadas de modo a utilizar informações doTelEduce em alguns casos interagircom o mesmo. O projeto desse conjunto de ferramentas de apoioadministrativo foi

6SofwareLivre são programas de computador desenvolvidos seguindo afilosofia teste de mantida

pelaFree Software Foundation- http://www.fsf.org/philosophy/

10

batizado deE-duc@reconforme pode ser observado em (DIAS, 2003). Na páginado menu de ferramentas doE-duc@reexiste uma descrição de seu objetivo:

“O objetivo dessas ferramentas é oferecer suporte a atividades deEaD não cobertas por ambientes virtuais e necessárias ao gerencia-mento de cursos a distância, em especial, cursos de graduação ou pós-graduação que ministrem disciplinas via internet.”

Figura 2.1: Tela Inicial doEduc@re

A Figura 2.1 ilustra a página principal doEduc@re. Entre as ferramentas de apoiodisponíveis estão:

• Minhas Salas - nessa ferramenta o aluno pode ter acesso as salas de aulavirtuais, doTelEduce doManhattan, nas quais está matriculado;

• Trabalhos de Conclusão - é possível, nessa ferramenta, administrar o anda-mento das propostas de Trabalhos de Conclusão (monografias), aprovaçãodos mesmos por alunos e professores. A lista de ferramentas eseus no-mes nessa categoria são: Projetos Novos; Projetos Avaliados; Projetos emOrientação; Projetos não Disponíveis; Propor Projeto; Confirmar Orienta-ção; Professores (para acesso apenas aos professores); Áreas de Orientação;Imprimir; Editar Áreas de orientação;

• Controle Acadêmico - nessa categoria estão disponíveis as ferramentas Ofe-recer Disciplina; Listar Disciplinas Oferecidas e Documentação Recebida;Minhas Notas (consulta das notas cadastradas);

11

• Eventos - essa ferramenta tem por objetivo disponibilizar os eventos cadas-trados para os alunos. Se fizerem parte do público alvo cadastrado para umevento, os alunos podem realizar a sua inscrição nele. O aluno ainda podeverificar em quais eventos está inscrito e quem está inscritoem um deter-minado evento. O administrador e a coordenação têm as ferramentas decriação de eventos e público alvo. É possível informar o período em que épossível ser feita inscrição e os demais detalhes sobre os eventos. O focodessa categoria de ferramentas é nos encontros presenciais. Listar Eventos;Adicionar Eventos; Inscrito em eventos; Listar Usuários Inscritos;

• Enquetes - ferramenta para exibir enquetes realizadas. Criar enquete; ExibirEnquete; Resultados das Enquete;

• Dados pessoais - é o conjunto de ferramentas para o aluno ou tutor adicionare atualizar seus dados pessoais. Sua composição é feita por ferramentas quelidam com: Dados Restritos; Endereço; Meu Perfil (perfil do aluno); EditarFormação (informações curriculares); Alterar Senha; Exportar Dados paraTelEduc (para comunalizar as bases de dados de alunos das diversas salasdo TelEduc). Visualizar Pendências; Listar Usuários; Listar Alterações

2.4 Proposta do novo módulo de Eventos

Uma das missões da coordenação do ARL é garantir que o aluno seja devidamenteconvocado para estar presente nos dois encontros técnicos nacionais (presenci-ais), de acordo com o estabelecido no projeto político pedagógico do curso e noregimento da PRPG. Desse modo é preciso informar à FAEPE, queé o órgão fa-cilitador para a UFLA nesse sentido, a lista com o nome dos alunos que devemser convocados para tais eventos. Para a geração dessa listaé preciso conhecer asituação de cada aluno, no que diz respeito a já ter participado (e quando) dos en-contros, o que gera uma quantidade significativa de trabalhopara a coordenação.Cada evento é formado por diversas atividades como: avaliações, mini-cursos,palestras e etc que daqui em diante serão chamados de sub-eventos. São neces-sárias também gerações de listas de presença para cada sub-evento de modo quefiquem registradas as participações dos alunos em atividades presenciais. Estessão exemplos de atividades da coordenação para as quais não há ferramentas deapoio apropriadas dentre as existentes para auxiliar o gerenciamento de eventos.Este novo Módulo de Controle de Eventos, como ferramenta de apoio a EaD, devefornecer os seguintes recursos administrativos:

• Ferramentas para a Coordenação:

12

– Interfaces para permitir o gerenciamento (criação, deleção, modifica-ção, consulta) de tipos de evento;

– Interfaces para criação de eventos e sua manipulação bem como o ge-renciamento de seu público alvo;

– Mecanismos para gerenciar sub-eventos dentro de um evento com aopção de sub-eventos alternativos;

– Mecanismos para análise de inscrições pela coordenação;

– Meios para os alunos matriculados num determinado curso serem con-vocados pela coordenação, para os casos onde isto for aplicado;

• Ferramentas para Alunos:

– Possibilidade do aluno se inscrever para um determinado evento queestá sendo oferecido (desde que ele esteja numa lista de ’candidatos’ acomparecer no evento ou sub-evento (público alvo);

– Um mecanismo de lista de espera caso o número de inscritos em umdeterminado evento tenha atingido o seu limite;

• Ferramentas para Professores:

– Ter um sistema para imprimir listas de presença por sub-evento minis-trado pelo professor;

• Ferramentas para Secretaria:

– Interface para preenchimento de listas de presença no formato eletrô-nico;

– Possuir ferramentas para avaliação de presença nos eventos.

O objetivo deste trabalho é implementar as ferramentas acima propostas. Atra-vés delas, pretende-se fornecer o apoio necessário para queas tarefas administra-tivas, relativas a atividades presenciais, sejam feitas demaneira mais simplificada,organizada e ágil. Assim, espera-se possibilitar o fornecimento de informaçõespara coordenação, alunos e secretaria com maior prontidão econsistência, ser-vindo como ferramenta de auxílio à tomada de decisões. Também pretende-seautomatizar algumas tarefas como geração de listas de presença e emissão de con-vocações melhor identificadas no Capítulo 3.Para esta implementação foram utilizadas algumas metodologias de modelageme desenvolvimento de sistemas, as quais serão abordadas nosCapítulos 3 e 4. OCapítulo 3 é composto pela descrição dessas metodologias e oCapítulo 4 contéma descrição da sua utilização neste trabalho. A implementação das ferramentas éapresentada no Capítulo 5.

13

Capítulo 3

Metodologia

3.1 Introdução

No desenvolvimento de um sistema de informações é necessário o emprego de umametodologia que seja adequada ao domínio da solução proposta. Essa metodologiadeve ser composta de elementos que facilitem o desenvolvimento, principalmentequando isso ocorre em equipe. Ela deve contemplar uma linguagem de descriçãodos processos, interfaces, bases de dados, padronização decódigos-fonte e demaiselementos componentes de um sistema.Desde o surgimento de métodos formais de desenvolvimento o que se procura éotimizar os tempos e recursos em função dos requisitos. Outro ponto de vistamuito importante é o da abordagem utilizada na solução procurada. Existem di-versas metodologias e cada uma tem suas características específicas.Uma delas é a Análise Estruturada Moderna de (YOURDON, 1992) que descrevemétodos lineares de desenvolvimento de sistemas (software). Esse método é base-ado na importância que deve ser dada as estruturas de dados e uma programaçãobaseada em procedimentos bem estruturados nos programas dosistema. Existemoutros autores que seguem a mesma linha.Outra metodologia que pode ser citada é aObject Modeling Techniquede JamesRumbaughet al. que define a informação em forma de objetos responsáveis pelasestruturas de dados e procedimentos para sua manipulação, hierarquia e descen-dência. Com outros autores são encontradas metodologias com o mesmo princípio.Neste trabalho será adotado um método orientado a objetos para a modelagem dosdados e a implementação do sistema. Isso se deve ao fato das ferramentas doE-duc@re(ver Introdução) já estarem desenvolvidas usando esta abordagem

15

Devido as diferenças encontradas entre os métodos e nas representações propostaspor eles, houve, por parte de alguns autores, um consenso de que deveria existiruma linguagem única de representação do conhecimento e das necessidades queum sistema deveria suprir. Foi então que os autores Graddy Booch e James Rum-baugh se reuniram e criaram a Unified Modeling Language (UML). Inicialmenteela foi definida, testada e publicada na empresa Rational Software, de propriedadede um dos criadores. Hoje, dada a sua versatilidade e visão com foco em objetos aUML é uma linguagem amplamente difundida e utilizada nas comunidades e em-presas de software do mundo todo.Este trabalho fez o uso de UML em sua fase de modelagem por possuir os elemen-tos necessários para representar, de maneira simples e clara, as diversas situaçõesencontradas no escopo do problema. UML não é apenas uma linguagem para mo-delagem de sistemas, é também uma linguagem de definição de processos.Para o desenvolvimento doE-duc@re(ver Introdução) foi estabelecido um con-junto deguidelines(Anexo A) que contempla as regras básicas a serem utilizadasdurante o processo de codificação de um sistema. Esta proposta fará uso de taldocumento para prezar pela padronização, legibilidade e manutenabilidade dosprogramas desenvolvidos.A Unified Modeling Language(UML) é, como visto em seu nome, uma lingua-gem de modelagem. Ela surgiu da unificação de várias metodologias de desen-volvimento de sistemas. Entre eles estão:Object Modeling Technique(OMT) deRumbaughet al. e Objectory Process (OOSE) de Booch. Seus autores trabalha-vam na empresa Rational Software na época em que unificaram a notação de suasmetodologias e publicaram a UML. Hoje a UML é mantida peloObject Manage-ment Group(OMG). Conforme o (BOOCH; RUMBAUGH; JACOBSON, 2000):

“(...) ela é uma linguagem gráfica para visualização, especifica-ção, construção e documentação de sistemas complexos desoftware.”

Isso demonstra que a UML não é apenas para a modelagem do sistema em si.Ela é uma linguagem que contém elementos capazes de descrever os processos,interfaces e o conhecimento no domínio do problema.O elementos da UML estão organizados da seguinte maneira:

• Ítens - São os blocos de construção elementares de um modelo feito emUML. Eles se subdividem em:

– Estruturais - Representam em geral um conceito. São a parte maisestática do modelo. Esses elementos estão divididos em:

∗ Classes - Descrições de objetos

∗ Interfaces - Serviços de um objeto

16

∗ Colaborações - Representa padrões que implementados formamum sistema

∗ Casos de Uso - é uma descrição de um conjunto de ações realiza-das pelo sistema. Sua missão é proporcionar uma visão do pontode vista do ator. Na seção 3.3 há mais detalhes sobre este itemestrutural da UML.

∗ Classes Ativas - Classes com objetos de mais de um processo

∗ Componentes - define partes substituíveis do sistema.

∗ Nós - elementos físicos existentes em tempo de execução.

– Comportamentais - São as partes dinâmicas dos modelos. Elessubdividem-se em Mensagens e Estados.

– De Agrupamentos - São ítens com finalidade de organização e seu prin-cipal mecanismo é o de pacotes.

– Anotacionais - este item é voltado a documentação e explicação daspartes do sistema e se concretiza através de notas.

• Relacionamentos - São elementos usados para demonstrar graficamente amaneira como os objetos estão interligados. Eles são em 4 tipos:

• Dependência - usada para indicar dois ítens que são semanticamente de-pendentes. Eles podem interferir um no outro dependendo do sentido dadependência.

– Associação - representa as conexões entre objetos.

– Generalização - usado para representar quando um objeto herda carac-terísticas de outro objeto.

– Realização - é um indicador de qual elemento irá executar umaaçãode um objeto.

• Diagramas da UML - Os Diagramas são as apresentações gráficasde umconjunto de elementos. Eles existem em diversos níveis de detalhamentos ecombinações de objetos. São eles diagramas de: Classes, Objetos, Casos deUso, Seqüências, Colaborações, Transição de Estados, Atividades, Compo-nentes, Implantação. Cada um deles tem foco no elemento da UML que dáorigem a seu nome.

Fazendo parte da UML estão as definições de símbolos permitidos bem como seussignificados quando da utilizados na especificação dos elementos acima descritos.Há também uma semântica própria na UML, lembrando que acima foram descritos

17

apenas os elementos da linguagem. UML permite que sejam elaborados modelosiniciais não completos ou mal-formados que ao longo da modelagem e do desen-volvimento vão tomando sua forma final.A utilização de UML para este projeto foi adotada na modelagem para atender aopadrão proposto no conjunto deguidelinesadotado (ver Anexo ) e por seus re-cursos proporcionarem uma visão muito clara do problema e como ele pode serresolvido.

3.2 Casos de Uso (Use Cases)

Casos de Uso é um item estrutural definido na semântica da UML.Sua função éespecificar o comportamento de uma parte de um sistema. Sua utilização na fasede levantamento e especificação de requisitos favorece a compreensão sobreo quedeve ser feito. É possível verificar com casos de uso os diversos pontos de vistasobre o sistema que os diferentes usuários possuem e como eles esperam que osistema se comporte. É possível também, observar de que maneira é esperada ainteração com outros sistemas, dispositivos, etc.A definição formal de caso de uso pode ser vista em (BOOCH; RUMBAUGH; JACOBSON,2000):

“Um caso de uso é uma descrição de um conjunto de seqüênciasde ações, que um sistema executa para produzir um resultado de valorobservável por um ator.”

Para representar um caso de uso utiliza-se uma elipse com seunome no centro. Otermos e conceitos definidos para casos de uso são:

• Nomes - deve-se escolher nomes para os casos de uso que sejam únicos.Um nome simples é usado para representar um conceito ou ação.Pode servisto um exemplo na Figura 3.1. Um nome de caminho representaa mesmacoisa porém localiza e organiza o caso de uso em um elemento daUMLdenominadopackage.

• Atores - Este elemento da UML representa um conjunto de papéis desempe-nhados por usuários ou outros sistemas em um dado caso de uso.Os atores,apesar de estarem representados nos casos de uso, em geral não são parte in-tegrante do sistema, mas apenas interagem com ele. Eles são representadosgraficamente por um boneco estilizado identificado pelo nomede seu papelno sistema. A Figura 3.2 mostra um exemplo.

18

Figura 3.1: Exemplo de Nomes de Casos de Uso

• Fluxo de eventos - Esse elemento é a descrição em forma textual do caso deuso. Ele deve ser escrito de maneira tal que alguém não envolvido no pro-cesso possa compreender facilmente o que deve ser feito. Eledeve descreverquando e como o caso de uso começa e termina, como é a interaçãocom osatores e os fluxos de comportamento normal e de exceções do sistema.

• Cenários - Quando os fluxos tendem a ter muitas variações dependendo decomo deve o comportamento do sistema para cada situação, devem ser uti-lizados os cenários. Eles descrevem seqüências diferentesde execução emum mesmo fluxo.

• Colaborações - Após a definição do que fazer é preciso efetivamente definircomo fazer. As colaborações são o conjunto de elementos da UML traba-lhando interligados para a implementação de um caso de uso.

3.3 Diagramas Entidade Relacionamento (E-R) e Modelo

Relacional

Muito antes da UML, havia outra maneira de modelar sistemas.Era através douso de diagramas E-R (Entidade-Relacionamento). Eles foram definidos por PeterChen em 1976. Essa descrição foi baseada na álgebra relacional, teoria de E. F.Cood criada em 1970.A proposta dos Diagramas E-R é representar o modelo de dados de uma determi-

19

Figura 3.2: Exemplo de Atores

nada situação elegendo elementos chamados entidades e descrevendo a maneiracomo essas entidades interagem entre si. Em (MACHADO; ABREU, 1997) pode-seobservar uma definição de entidade da seguinte forma:

“Define-se entidade como aquele objeto que existe no mundo realcom uma identificação distinta e com um significado próprio.”

Nesse ponto de vista qualquer coisa ou situação que possa serclaramente identi-ficado e que possua características próprias e um significadopode ser eleita comouma entidade.Em termos de relacionamentos todas as ações ou fatos que descrevem a iteraçãoentre as entidades podem ser definidas como um relacionamento. Em (MACHADO; ABREU,1997) há uma definição que diz:

“(...) definimos relacionamento como o fato, o acontecimento queliga dois objetos, duas ’coisas’ existentes no mundo real.”

Essa representação foi concebida por Chen para descrever sistemas de banco dedados, porém pode ser estendida para representar outros tipos de situações. Nestetrabalho sua utilização segue a definição original (para banco de dados). No Capí-tulo 4 há mais detalhes sobre esta modelagem.O banco de dados pode ser representado em forma de diagrama através do ModeloRelacional. Esse modelo é ligeiramente diferente do diagrama E-R e ao invés derepresentar a informação de maneira conceitual, ele a representa do modo que deveser fisicamente no banco de dados. A simbologia é diferente também. Cada au-tor sugere uma simbologia diferente. A legenda dos diagramas apresentados nestetrabalho trarão o significado de cada símbolo quando for usado.

20

3.4 Programação Orientada a Objetos

A programação orientada a objetos (POO) teve seu grande momento na década de90. Entretanto seus conceitos haviam sido usados, de forma restrita, uma ou duasdécadas antes. Os conceitos introduzidos por esse tipo de abordagem no desen-volvimento de sistemas, trouxeram para a comunidade de computação em geraluma nova visão para a solução dos problemas emergentes nessadécada. O rápidoavanço das tecnologias de computadores na época fez com que novas maneirasde se pensar em software surgissem. Diferentemente da programação estruturadacitada anteriormente a programação orientada a objetos nãoé focada em proce-dimentos dos programas. Seu foco está no objeto e em seus comportamentos ouações no sistema como um todo.Um objeto é qualquer "coisa"que exista e que tenha características bem definidase ações que possam ser executadas por ele ou com ele. Um objetopropriamentedito passa existir num sistema quando uma classe é instanciada, ou seja, quandosão atribuídos valores a ela. Por exemplo podemos dizer que carro é um objeto deum grupo de objetos ou classe chamada veículo. O nosso objetocarro passaria aexistir assim que lhe fosse atribuído o modelo por exemplo. Do mesmo modo, oobjeto carro tem características de qualquer outro veículoex. número de passagei-ros.Os conceitos de classe e objeto juntamente com herança, polimorfismo, abstraçãoe encapsulamento são os conceitos mínimos que qualquer linguagem orientada aobjeto deve fornecer ao programador.A abstração permite que sejam modelados os objetos do mundo real sem a necessi-dade de criação de estruturas de dados através de matrizes e vetores propriamenteditos. O encapsulamento permite que todos os comportamentos, ações e reaçõesdo objeto estejam contidos no mesmo, definidos em sua classe,e evita que alte-rações em outras partes do sistema modifique o comportamentodireto do objeto.A herança permite que uma classe use características e funções (em orientaçãoa objetos chamados métodos) de outra classe. No exemplo a classe carro herdaa característica de número de passageiros da classe veículos. E o polimorfismopermite que a mesma ação tenha resultados diferentes em objetos diferentes. Porexemplo, dar a partida para o objeto carro é diferente de dar apartida para o objetomotocicleta.Essa maneira "nova"de programar também exige que se mude a maneira de pensarem projeto desoftware. Formalmente foram definidas algumas metodologias dedesenvolvimento de sistemas orientados a objetos como OMT,Objectory, Analisee projeto orientados a objetos, cada uma com suas características e simbologiaspróprias. Mais recentemente foi criada UML na tentativa de padronizar a simbolo-

21

gia e metodologia de desenvolvimento de projetos usando o conceito de orientaçãoa objetos. UML foi a fusão de OMT e OOSE quando seus autores passaram a tra-balhar juntos naRational Software Ltd.

3.5 PHP Orientado a Objetos

Os ambientes virtuais descritos anteriormente, inclusiveo que está em uso peloARL, são na sua maioria voltados para utilização através de um serviço daInter-netconhecido comoHiperText Transfer Protocol- (HTTP)1. Esse serviço é forne-cido por computadores conectados àInternetque possuem um software conhecidocomo WebServer(Webde teia eserverde servidor). O mais famoso deles é oApache2. No princípio do uso desse serviço apenas era possível observar páginasestáticas através de um aplicativo de computador chamado navegador (em inglêsbrowser). Em 1995 Rasmus Lerdorf resolveu colocar conteúdos gerados de acordocom a requisição do serviço em algumas de suas páginas e criouum programa bati-zado dePersonal Home Page / Forms Interpreter(PHP/FI). Esse programa evoluiue teve milhares de contribuidores ao redor do mundo. Hoje está na versão 5 e suasigla ficou apenas PHP.PHP é uma linguagem para criação descripts(programas procedurais) que ao se-rem interpretados funcionam como programas de computador.Dado seu estadode evolução pode-se contar com conexão e manipulação de banco de dados, cria-ção de gráficos, manipulação de vetores e inúmeras funções. Como é um projetode Software Livre (ver Introdução), seus colaboradores ao redor do mundo es-tão continuamente adicionando novas características na linguagem e desse modoestendendo cada vez mais as características da linguagem. Uma das recentes capa-cidades adicionadas foi o suporte a objetos. Dessa forma é possível implementarprogramas de projetos orientados a objetos, onde o foco é numa estrutura de dadose procedimentos relacionados trabalhando integrados e independentes.O ambienteTelEducbem como as ferramentas doE-duc@reforam desenvolvidosusando essa linguagem. Nas versões mais recentes é possívelcriar scripts baseadona tecnologia de objetos. Seguindo a recomendação dos guidelines doE-duc@redeve-se utilizar orientação a objetos. Como o PHP possibilita o acesso a essa tec-nologia, torna-se a linguagem mais indicada para ser usada neste projeto, além deproporcionar a compatibilidade natural com os sistemas citados e ser a linguagem

1HTTP - http://www.w3c.org/Protocols/2Apache - http://www/apache.org/ — Ver no anexo A.5 a estatística sobre utilização desse tipo

softwareservidor

22

mais utilizada mundialmente3 para servidores de páginasweb.

3.6 Comentários

O Capítulo 3 trouxe uma pequena noção de cada metodologia, linguagem ou con-ceito de programação que será usado nos Capítulos 4 e 5 para implementar a pro-posta feita no Capítulo 2. Essa noção foi usada para contextualizar os Capítulos 4e 5.Em função da diversidade de linguagens de programação e metodologias de de-senvolvimento existentes, é possível notar que não é tarefafácil optar por umaou outra. Porém o universo de opções se reduz, ao passo que já existe uma baseinstalada, e este trabalho implementa mais um módulo para agregar valor aos ou-tros módulos já existentes. Embora tal fator não tenha sido usado na escolha demetodologia e linguagem de programação a ser utilizados, reforça ainda mais ajustificativa do uso deles no desenvolvimento de módulos futuros. Passo a imple-mentação.

3Ver estatística no anexo A.9

23

Capítulo 4

Modelagem

A modelagem de dados, interfaces com usuário e processos do sistema foi ela-borada levando em consideração as premissas descritas no ítem 3. Por tratar-sede uma aplicação com armazenamento de informações, foi utilizado um diagramaE-R para representar as entidades de banco de dados (Figura 4.1). O DiagramaE-R está seguido da explanação detalhada de cada entidade e seus atributos. Paraa modelagem das interfaces e processos foi utilizada UML. O principal diagramaem UML está ilustrado na Figura 4.3 e é seguido da explicação de cada um doscasos de uso previstos para cobrir os requisitos mencionados no ítem 2.4.

4.1 Banco de Dados

O Diagrama E-R da Figura 4.1 ilustra a representação conceitual da base de dadosque foi vislumbrada e normalizada para atender as necessidades das ferramentaspropostas neste trabalho. Ele contempla as entidades para armazenar:

Tipo de eventosEsta entidade representa os tipos de eventos que o modulo de eventos de-verá tratar. Como exemplos de tipo de eventos podem ser citados "Prova","Encontro Técnico","Mini Curso", etc.

EventosOs eventos propriamente ditos são representados por essa entidade. Entre ascaracterísticas ou atributos de um evento está o tipo do evento. Exemplos deevento podem ser: "Primeiro Encontro Técnico para a Primeira Turma do

25

ALUNO

EVENTO

TIPO DE EVENTO

PUBLICO ALVO INSCRIÇÃO EM

EVENTOSSUB-EVENTO

INSCRIÇÃO EM SUB-EVENTOS

ESTÁ EM

POSSUI

É DE UM

PARTICIPA

POSSUI

1

N

N

N

N N

N

N

N

N

N

N

1

1

Figura 4.1: Diagrama Entidade Relacionamento

26

Curso ARL de 2003", "Segundo Encontro Técnico para a Primeira Turmado Curso ARL de 2002", etc.

Sub-eventosEsta entidade tem por finalidade representar as atividades realizadas duranteum evento. Essas atividades podem ser exemplificadas como: "Prova deC++","Apresentação de Monografia","Mini-curso de LATEX", etc.

Inscrição em eventos com publico alvoPara participar de um evento é necessário que um aluno estejaincluído nopúblico alvo desse evento. Isso será melhor abordado mais adiante. A tarefadessa entidade é dupla. Ela registra se o aluno faz parte do publico alvo deum evento e ao mesmo tempo se ele aceitou ou não comparecer ao evento.

Inscrição em Sub-eventos com lista de presençaAo aceitar participar de um evento o aluno é inscrito em todasas atividadesdaquele evento, porém pode haver atividades simultâneas e oaluno deveoptar por uma ou outra. Esta entidade representa o armazenamento dessainformação.

No ítem 4.1.2 está a descrição detalhada das entidades.O conceito de "chaves"em banco de dados será citado mais adiante, portanto valeuma pequena introdução. Chaves em banco de dados são informações capazesde identificar de uma forma especial cada registro de uma tabela. Se o registroé identificado unicamente através de uma chave ou em outras palavras só existeum registro identificado por aquela chave então tal chave é dita primária. Quandouma parte do registro ou da chave do registro depende da chaveou parte de ou-tro registro, esta chave é dita estrangeira. Quando uma parte do registro é usadapara ordenação ou outra finalidade é chamada de chave auxiliar ou índice. Essanomenclatura pode variar entre os bancos de dado existentesno mercado porém oconceito é o mesmo.

4.1.1 Normalização

Para refinar modelos de base de dados com o objetivo de eliminar duplicidade deinformação armazenada e de uma certa forma colocar cada informação em seudevido lugar, (CODD, 1970) introduziu um conceito que foi chamado de normali-zação. Esse conceito está fundamentado na teoria matemática de conjuntos. Trata-se de substituir gradativamente os atributos das entidadese entre as entidades demodo a evitar atributos repetidos desnecessariamente, informações perdidas (nãocorretamente localizadas), etc.. O conceito de normalização pode ser aplicado em

27

alguns passos para auxiliar no desenvolvimento de uma modelagem consistente.Em (MACHADO; ABREU, 1997) esses passos estão descritos como Primeira FormaNormal (1FN), 2FN, 3FN, Forma Normal de Boyce/Codd (FNBC), 4FN e 5FN.Ele defende a idéia de que ao término dessa seqüência de normalizações, o mo-delo encontrado seja o ideal para o desenvolvimento e implementação do bancode dados — "O processo de normalização leva ao refinamento dasentidades, reti-rando delas grande parte das redundâncias e inconsistências". É possível tambémpercorrer o caminho reverso, ou seja, a "desnormalização".É um conceito maisrecente e apesar de se opor a normalização pode se fazer necessário por questõesde ordem prática relacionadas a performance das bases de dados.O processo de normalização tem início com a nomeação de entidades e seus atri-butos observáveis a primeira vista. Então identificam-se todos os atributos quetem características repetitivas para aquela entidade e criam-se entidades própriaspara eles. O modelo resultante está na Primeira Forma Normal. Em seguida podeser usada a segunda forma normal (2FN) para remover a dependência de atribu-tos que se relacionam com os atributos das chaves primárias.Os outros proces-sos não descrevo em detalhe porém se executados obrigatoriamente em seqüência(3FN,FNBC,4FN e 5FN) levam no final a um modelo mais consistente e e menosredundante. O Diagrama E-R resultante, após o processo de normalização, podeser facilmente passado para um diagrama Modelo Relacional.O processo de normalização é bastante longo. Sendo assim apresento apenas oresultado final desse processo na Figura 4.2 para implementar o Módulo de Even-tos. Duas entidades passaram pelo processo de desnormalização ("Inscrição emSub-eventos com lista de presença"e "Inscrição em eventos com publico alvo")por questões de performance e economia de espaço no banco de dados. s

4.1.2 Descrição detalhada das Entidades

Entidade ’tipo_eventos’Um tipo de evento descreve a modalidade, a configuração e a espécie de umevento. Seu objetivo é armazenar e padronizar os tipos de eventos e sub-eventos que são oferecidos ou que precisam ser gerenciados pelo sistema.Ele será usado pelas entidades de eventos e sub-eventos parainformar qualo tipo de evento que está sendo criado. Pode-se cadastrar tipos de even-tos inter-dependentes, obrigatórios, principais e auxiliares e a combinaçãodeles. Para esta entidade estão implementadas interfaces de:

1. Cadastro de tipo, não permitindo tipos idênticos, com facilitadores dedigitação para campos com valores pré-definidos;

28

Figura 4.2: Modelo Relacional - Tabelas

29

2. Deleção de tipo, não permitindo isto para tipos já utilizados em even-tos, sub-eventos ou outro registro de tipo de evento;

3. Modificação, observando as mesmas condições para deleção;

4. Consulta simples de tipo de eventos.

Atributo ’cod_tipo’Este atributo é o identificador único do tipo de evento. Esse código é achave primária para identificação de cada tipo de evento.

Atributo ’nome’É o nome do tipo de evento propriamente ditos.

Atributo ’descricao’São informações complementares para detalhar o tipo do evento ecomo deve ser utilizado sendo de critério da coordenação seuconteúdoou norma para preenchimento.

Atributo ’pre_requisito’É o código de outro tipo de evento dessa mesma entidade que indicaque o tipo de evento necessita que outro tipo já tenha tido o participantecomo inscrito e presente.

Atributo ’obrigatorio’Indica se um tipo de evento ou sub-evento é obrigatório ou nãocom osvalores armazenados de S (de Sim) para obrigatório e N (de Não) paranão obrigatório.

Atributo ’classificacao’Esse atributo tem o objetivo de classificar o evento em [P]rimário ou[S]ecundário sendo mais ou menos indicador de evento (primário) esub-evento (secundário).

Entidade ’eventos’Esta entidade é a responsável pelo registro da criação de eventos no sistema.Para esta entidade pretende-se criar interfaces para:

1. Cadastro de evento, não permitindo eventos idênticos, com facilitado-res de digitação para campos com valores pré-definidos, assim comoos tipos de evento;

2. Deleção de evento, não permitindo isto para eventos já utilizados emsub-eventos;

3. Modificação, observando as regras acima;

30

4. Consulta simples com alguns tipos de ’visões’ a serem definidas, como:por evento, por nome, por interdependências, etc.

Atributo ’cod_evento’Este atributo é do tipo numérico e contém o código de identificaçãoúnico do evento no sistema. Seu valor será iniciado em 1 e incre-mentado automaticamente pelo sistema (auto-incremental)quando oregistro for criado.

Atributo ’cod_tipo’O código do tipo será um valor advindo da tabela de tipo de eventos.Para exibição e para prezar pela facilidade de uso serão exibidos osdados do tipo de evento e apenas armazenado o código para minimizara base de dados.

Atributo ’descrição’É a descrição do evento em si que podem ser comentários diversossobre o que a coordenação do curso julgar necessário.

Atributo ’local’Deve definir o local do evento de maneira clara e objetiva.

Atributo ’data_inicio’Data do início previsto para o evento.

Atributo ’turno_inicio’Turno em que o evento será iniciado (Matutino/Vespertino/Noturno).

Atributo ’data_termino’Data de término previsto para o evento.

Atributo ’turno_termino’Turno em que o evento terminará (Matutino/Vespertino/Noturno).

Atributo ’min_participantes’Número mínimo de participantes que um determinado evento podecomportar. O número de inscrições aceitas deve ser maior ou iguala este valor, que é predefinido pela coordenação no momento dacria-ção do evento no sistema, podendo um evento ser até mesmo canceladopor falta dequorum.

Atributo ’max_participantes’Número máximo de participantes que um determinado evento podecomportar. O número de inscrições aceitas deve ser menor ou iguala este valor, predefinido pela coordenação no momento da criação doevento no sistema.

31

Atributo ’data_inicio_inscricao’Data até a qual é possível o aluno se inscrever no referido evento. Apósesta data o sistema não deve permitir mais inscrições para este evento,fornecendo as informações necessárias sobre este fato aos pretenden-tes.

Atributo ’data_limite_inscricao_sem_conv’Data até a qual é possível o aluno se inscrever no referido evento, semnecessidade de convocação. Após esta data o sistema não deveidenti-ficar a necessidade de gerar uma convocação automática para oaluno.

Atributo ’data_limite_inscricao_com_conv’Data até a qual é possível o aluno se inscrever no referido evento, apóster recebido uma convocação por carta oue-mail para participar domesmo. Após esta data o sistema não deve permitir mais a inscriçãodo aluno e deve gerar um alerta para a coordenação.

Entidade ’publico_alvo_inscricao_eventos’O aluno pode, após a criação de um evento pela coordenação, seinscre-ver neste e aguardar a avaliação de sua solicitação. Isso é possível no casodo aluno ter sido cadastrado como participante do público alvo para esseevento.Essa tabela deve ser preenchida de maneira semi-automática. O programaadministrativo de verificação de obrigatoriedade de presença em eventosserá o responsável por essa atividade. Essa ação mostrará à coordenaçãoquem deve ou não estar obrigatoriamente presente no evento em questão.Pretende-se fornecer as ferramentas de aceitação e rejeição de inscrição peloaluno e coordenação. Outra ferramenta que atuará nesta entidade será paramanutenção dosstatusde concluído ou não.

Atributo ’cod_evento’Código usado como chave estrangeira para a tabela de eventos.

Atributo ’cod_usuário’Código usado como chave estrangeira para a tabela de usuários.

Atributo ’status’Esse atributo será o responsável por armazenar a situação doalunonaquele evento. Os seguintes valores com seus significados serão pos-síveis para este atributo:

P - pendente, preenchido automaticamenteS - solicitada pelo alunoC - cancelada pelo aluno

32

R - rejeitada pela coordenação

A - aceita pela coordenação

X - cancelada não comparecimento

T - concluído - compareceu em todos os sub eventos

O - convocação obrigatória, gerada pelo sistema

Esses valores serão alterados através de interfaces durante a operaçãonormal do sistema.

Entidade ’sub_eventos’Esta entidade tem por objetivo registrar todos os sub-eventos (atividades)

que são oferecidos em um evento. Como exemplo pode ser dito que essaentidade registra as provas, mini-cursos ou outra atividade qualquer duranteum encontro técnico. Ela também é utilizada para fornecer asinformaçõesnecessárias para gerar lista de presença para as atividadese registrar a pre-sença dos alunos nessas atividades.A visão gerada dos dados dessa entidade em forma tabular, organizado pordata e com todas as atividades de um evento é equivalente à agenda desseevento.Pretende-se prover as ferramentas necessárias para administrar o cadastro desub-eventos em eventos. Sendo elas estão a inclusão, deleção, modificaçãoe listagem de sub-eventos para um determinado evento.

Atributo ’cod_sub_evento’Atributo para identificar unicamente um sub-evento.

Atributo ’cod_evento’Código do evento ao qual esse sub_evento pertence.

Atributo ’cod_tipo’Código do tipo de sub-evento. Esse código vem da entidade ’tipo_eventos’.

Atributo ’data_hora_inicio’Data e hora previsto de início do sub-evento.

Atributo ’data_hora_fim’Data e hora previsto de término do sub-evento.

Atributo ’possui_alternativo’Este atributo permite dois valores – [S]im ou [N]ão. Se tivervalor’S’ admite que outro sub-evento do mesmo evento seja concorrente.Assim o aluno ao fazer a inscrição deverá optar por um dos sub-eventossimultâneos.

33

Atributo ’status’Indica ostatusdo sub-evento em termos de:

N - sub-evento criado

C - sub-evento cancelado

F - sub-evento concluído

O - sub-evento com lista de presença preenchida

Entidade ’inscricao_sub_eventos’Esta entidade é uma entidade a principio de preenchimento sendo feito auto-maticamente por rotinas a serem implementadas no sistema demodo que ousuário que se inscreveu apenas deve, caso existam para o evento em ques-tão, escolher um entre os sub-eventos que por ventura possamestar sendooferecidos no mesmo horário.

Atributo ’cod_sub_evento’Atributo para identificar unicamente um sub-evento.

Atributo ’cod_evento’Código do evento primário deste sub-evento.

Atributo ’cod_usuário’Código usado como chave estrangeira para a tabela de usuários.

Atributo ’status’Este campo reflete ostatusda inscrição do aluno em cada sub-eventode um evento que possa participar. Esse atributo pode assumir os se-guintes valores:

I - para inscrito automaticamente. Esse valor é inserido automatica-mente pelo sistema quando o sub-evento não tem outro sub-eventoalternativo, ou seja, concorrente.

N - pendente para inscrever em um dos alternativos. Esse valoré in-serido automaticamente pelo sistema quando o sub-evento possuioutro sub-evento concorrente.

A - inscrito em um dos alternativos. Quando o aluno já fez a opçãopor uma das atividades concorrentes e informou isso atravésdasinterfaces do sistema.

C - cancelado. O sub-evento alternativo que não foi escolhidopeloaluno, fica com esse valor.

P - registro de presença através deste status. O atributo status recebeesse valor para indicar que o aluno esteve presente nessa atividade.

34

4.2 Descrição do módulo em UML

Um dos diagramas propostos na UML é o Diagrama de casos de uso.Nesse dia-grama são usadas as representações de atores, casos de uso e os relacionamentosentre eles. Esse tipo de diagrama consegue reunir elementossuficientes para ex-pressar de forma gráfica o contexto de um sistema. Também é possível realizar amodelagem dos requisitos de um sistema reunindo os objetivos e comportamentosdesejados para o sistema em questão.Este trabalho faz uso de um diagrama de casos de uso para completar a modela-

Figura 4.3: Diagrama Entidade Relacionamento

gem. Nesse diagrama estão representadas as funcionalidades esperadas do sistema(comportamentos e ações) através de casos de uso e os atores para desempenharos papéis desejados. O Diagrama de casos de uso pode ser vistona (Figura 4.3).Para esse diagrama foram definidos 4 atores:

• Coordenador, que terá o papel de administrador dos eventos eas informa-ções necessárias para gerar e gerenciar eventos através do sistema;

35

• Aluno, que terá o papel de se inscrever em eventos e seus sub-eventos alter-nativos;

• Professor, que poderá imprimir as listas de presença de seuscursos, provas,mini cursos, etc;

• Secretaria, que poderia gerenciar as obrigações legais de lista de presença econclusão de eventos no sistema.

Para facilitar a compreensão dos fluxos de eventos que descrevem os casos de usoapresentados no Diagrama de casos de uso, serão utilizados sub-fluxos. Nos pontosonde se fizer necessário será utilizada a letra ’E’ seguida deum número indicandoa execução de uma exceção ou tratamento de erro (sub-fluxo de exceção). Um ’A’seguido de um número identifica uma ação ou sub-fluxo alternativo para o caso deuso.

4.2.1 Fluxo de Eventos dos casos de uso

Caso de uso ’Gerenciar Tipo de Evento’Este caso de uso fornece os meios para o coordenador criar, apagar, modi-ficar e consultar os tipos de eventos que podem acontecer no sistema bemcomo sua interdependência.

Fluxo PrincipalSeu início dá-se quando o coordenador acessa o menu de Eventos edepois o menu Gerenciar Tipo de Evento. O sistema então verifica seeste coordenador tem permissão para trabalhar com Tipo de Eventos(E1) e apresenta as opções para selecionar a atividade desejada: Inserir,Modificar, Apagar, Consultar ou Sair.Se a atividade selecionada é:

Inserir , o sub-fluxo A1 (Criar um Novo Tipo de Evento) é executado;

Modificar , o sub-fluxo A2 (Modificar um Tipo de Evento) é execu-tado;

Apagar, o sub-fluxo A3 (Apagar um Tipo de Evento) é executado;

Consultar, o sub-fluxo A4 (Consultar Tipos de Eventos) é executado;

Sair, o sistema vai para o menu do módulo ou menu principal.

Descrição dos Sub-fluxos do caso de uso

A1 - Criar um Novo Tipo de EventoO Sistema apresenta uma tela com um formulário de criação de

36

’Tipo de Evento’ em branco. O coordenador preenche os camposNome, Descrição, escolhe um tipo de evento de Pré-Requisito,indica se ele é obrigatório e sua classificação usando facilitadoresde digitação como botões ou caixas com valores pré-definidos.Em seguida o coordenador submete o formulário preenchido aosistema. O sistema irá verificar se não existe um tipo de eventocom aquele nome (E1). O sistema verifica se o nome e a descriçãoforam digitados (E2). Caso tenha sido fornecido um código depré-requisito o mesmo deve existir previamente na base de dados(E3) e o campo ’Obrigatório’ deve ter valor valido de ’S’ ou ’N’(E4) e o campo ’Classificação’ deve ter valor valido de ’P’ ou’S’ (E5). Com todos os dados válidos o sistema cria o ’Tipo deEvento’. O sistema exibe opção para poder reiniciar o processoou ir para o menu do módulo ou menu principal.

A2 - Modificar um Tipo de EventoO sistema recupera (E6) e exibe numa tela inicial todos os tipos deeventos previamente cadastrados ordenados por nome. Ao seleci-onar um dos tipos de evento o sistema recupera todas as informa-ções deste tipo de evento (E7) e exibe num formulário semelhanteao de criação.Ao confirmar o sistema deve verificar os ítens do processo A1 etambém se o pré-requisito é diferente do tipo de evento que estásendo modificado e então efetiva a modificação (E8). O sistemaexibe opção para poder reiniciar o processo ou ir para o menu domódulo ou menu principal.

A3 - Apagar um Tipo de EventoO sistema recupera (E6) e exibe numa tela inicial todos os tipos deeventos previamente cadastrados ordenados por nome. Ao seleci-onar um dos tipos de evento o sistema recupera todas as informa-ções deste tipo de evento (E7) e exibe num formulário semelhanteao de criação porém com as informações apenas para leitura ecom uma opção para confirmação da operação. Ao confirmar osistema deve verificar se este tipo de evento não é pré-requisito denenhum outro (E8) e se não foi utilizado em nenhum Evento (E9)ou Sub-evento (E10) e efetivar a operação. O sistema exibe opçãopara poder reiniciar o processo ou ir para o menu do módulo oumenu principal.

A4 - Consultar Tipos de EventosO sistema recupera (E6) e exibe numa tela inicial todos os tipos de

37

eventos previamente cadastrados ordenados por nome. Ao seleci-onar um dos tipos de evento o sistema recupera todas as informa-ções deste tipo de evento (E7) e exibe num formulário semelhanteao de criação porém com as informações apenas para leitura. Osistema exibe opção para poder reiniciar o processo ou ir para omenu do módulo ou menu principal.

Descrição dos Sub-fluxos de Exceção do caso de uso

E1 - Nome do tipo de evento previamente existenteO coordenador pode redigitar o nome do tipo de evento ou cance-lar a operação.

E2 - Nome do tipo de evento e/ou descrição em brancoO coordenador pode redigitar o nome e/ou descrição do tipo deevento ou cancelar a operação.

E3 - Código do tipo de evento selecionado no pré-requisito inexis-tente no banco de dadosO coordenador pode selecionar outro código, informar que aqueletipo de evento não possui pré-requisito ou cancelar a operação.

E4 - Indicação de obrigatório do tipo de evento com valor invá-lidoO coordenador pode selecionar um valor válido ou cancelar a ope-ração.

E5 - Indicação de classificação do tipo de evento com valor invá-lidoO coordenador pode selecionar um valor válido ou cancelar a ope-ração.

E6 - Não foi possível selecionar listagemSe a lista estiver vazia exibir informações a respeito. Se não foipossível executar a consulta exibir instruções de contataradminis-trador do sistema. Voltar ao menu do módulo.

E7 - Não foi possível selecionar todos os valores para um deter-minado tipo de eventoInformar o coordenador que não é possível exibir as informaçõespara o tipo do evento e o porque e permitir que seja selecionadooutro tipo de evento.

E8 - Tipo de evento é pré-requisito de outro tipo de eventoNesta situação o coordenador deve ser informado de quais tiposde eventos tem este como pré-requisito e o sistema deve cancelara operação.

38

E9 - Tipo de evento foi usado em EventosNesta situação o coordenador deve ser informado de quais eventosusaram este como tipo e o sistema deve cancelar a operação.

E10 - Tipo de evento foi usado em Sub-EventosNesta situação o coordenador deve ser informado de quais sub-eventos usaram este como tipo e o sistema deve cancelar a opera-ção.

Caso de uso ’Criar Evento’Este caso de uso fornece os meios para o coordenador criar, apagar, modifi-car e consultar os eventos que podem acontecer no sistema.

Fluxo PrincipalSeu início dá-se quando o coordenador acessa o menu de Eventos edepois o menu Gerenciar Evento. O sistema então verifica se este co-ordenador tem permissão para trabalhar com Eventos (E1) e apresentaas opções para selecionar a atividade desejada: Inserir, Modificar, Apa-gar, Consultar ou Sair.Se a atividade selecionada é:

Inserir , o sub-fluxo A1 (Criar um Novo Evento) é executado;

Modificar , o sub-fluxo A2 (Modificar um Evento) é executado;

Apagar, o sub-fluxo A3 (Apagar um Evento) é executado;

Consultar, o sub-fluxo A4 (Consultar Eventos) é executado;



A1 - Criar um Novo EventoO Sistema apresenta uma tela com um formulário de criação deEvento em branco. O coordenador seleciona o tipo de evento epreenche descrição, local, data de inicio, data de término ede-mais atributos descritos para a entidade de eventos no ítem 4.1.2.Em seguida ele submete o formulário preenchido ao sistema. Osistema irá verificar se não existe um evento com aquela descriçãoe tipo (E1), validar as datas e demais campos (E2) e então inseriro evento no sistema. O sistema exibe opção para poder reiniciar oprocesso ou ir para o menu do módulo ou menu principal.

A2 - Modificar um EventoO sistema recupera (E6) e exibe numa tela inicial todos os eventospreviamente cadastrados ordenados por descrição. Ao selecionar

39

um dos eventos o sistema recupera todas as informações desseevento (E7) e exibe num formulário semelhante ao de criação.Ao confirmar as mudanças o sistema deve verificar os ítens doprocesso A1 e então efetiva a modificação (E8). O sistema exibeopção para poder reiniciar o processo ou ir para o menu do móduloou menu principal.

A3 - Apagar um EventoO sistema recupera (E6) e exibe numa tela inicial todos os eventospreviamente cadastrados ordenados por descrição. Ao selecionarum dos eventos o sistema exibe num formulário semelhante aode criação porém com as informações apenas para leitura e comuma opção para confirmação da operação. Ao confirmar o sistemadeve verificar se esse evento não está sendo usado em nenhumsub-evento, ou inscrição (E7) e efetivar a operação. O sistemaexibe opção para poder reiniciar o processo ou ir para o menu domódulo ou menu principal.

A4 - Consultar EventosO sistema recupera (E6) e exibe numa tela inicial todos os eventospreviamente cadastrados ordenados por descrição. Ao selecionarum dos eventos o sistema recupera todas as informações desseevento (E7) e exibe num formato de listagem apenas para leitura.O sistema exibe opção para poder reiniciar o processo ou ir parao menu do módulo ou menu principal.


E1 - Descrição do evento previamente existenteO coordenador pode redigitar o nome do tipo de evento ou cance-lar a operação.

E2 - Descrição em brancoO coordenador pode redigitar o nome e /ou descrição do tipo deevento ou cancelar a operação.

E6 - Não foi possível selecionar listagemSe a lista estiver vazia exibir informações a respeito. Se não foipossível executar a consulta exibir instruções de contataradminis-trador do sistema. Voltar ao menu do módulo.

E7 - Não foi possível selecionar todos os valores para um deter-minado tipo de eventoInformar o coordenador que não é possível exibir as informaçõespara o tipo do evento e o porque e permitir que seja selecionadooutro tipo de evento.

40

E10 - Evento foi usado em Sub-EventosNesta situação o coordenador deve ser informado de quais sub-eventos usaram este como tipo e o sistema deve cancelar a opera-ção.

Caso de uso Criar Sub-EventoEste caso de uso fornece os meios para o coordenador definir osSub-Eventospara cada evento criado no sistema.

Fluxo PrincipalEsse fluxo inicia-se quando o coordenador acessa o menu de Eventose depois o menu Gerenciar Sub-Eventos. O sistema então verifica seeste coordenador tem permissão para trabalhar com Sub-Eventos (E1)e apresenta as opções para selecionar a atividade desejada:Inserir,Modificar, Apagar, Consultar ou Sair.Se a atividade selecionada é:

Inserir , o sub-fluxo A1 (Criar um Novo Sub-Evento) é executado;

Modificar , o sub-fluxo A2 (Modificar um Sub-Evento) é executado;

Apagar, o sub-fluxo A3 (Apagar um Sub-Evento) é executado;

Consultar, o sub-fluxo A4 (Consultar Sub-Eventos) é executado;



A1 - Criar um Novo Sub-EventoO Sistema apresenta uma tela com um formulário de criação deSub-Evento em branco. O coordenador seleciona o tipo de eventoe o evento e preenche descrição, local, data de inicio, data de tér-mino e demais atributos descritos para a entidade sub-eventos noítem 4.1.2. Em seguida ele submete o formulário preenchido aosistema. O sistema irá verificar se não existe um sub-evento comaquela descrição e tipo (E1), validar as datas e demais campos(E2) e então inserir o sub-evento no sistema. O sistema exibeop-ção para poder reiniciar o processo ou ir para o menu do móduloou menu principal.

A2 - Modificar um Sub-EventoO sistema recupera (E6) e exibe numa tela inicial todos os sub-eventos de um determinado evento ordenados por descrição. Aoselecionar um dos sub-eventos o sistema recupera todas as infor-mações desse sub-evento (E7) e exibe num formulário semelhante

41

ao de criação.Ao confirmar as mudanças o sistema deve verificar os ítens doprocesso A1 e então efetiva a modificação (E8). O sistema exibeopção para poder reiniciar o processo ou ir para o menu do mó-dulo ou menu principal.

A3 - Apagar um Sub-EventoO sistema recupera (E6) e exibe numa tela inicial todos os sub-eventos de um determinado evento ordenados por descrição. Aoselecionar um dos sub-eventos o sistema exibe num formuláriosemelhante ao de criação porém com as informações apenas paraleitura e com uma opção para confirmação da operação. Ao con-firmar o sistema deve verificar se esse sub-evento não está sendousado em nenhuma inscrição (E7) e efetivar a operação. O sistemaexibe opção para poder reiniciar o processo ou ir para o menu domódulo ou menu principal.

A4 - Consultar Sub-EventosO sistema recupera (E6) e exibe numa tela inicial todos os sub-eventos previamente cadastrados ordenados por descrição.Ao se-lecionar um dos sub-eventos o sistema recupera todas as infor-mações desse sub-evento (E7) e exibe num formato de listagemapenas para leitura. O sistema exibe opção para poder reiniciar oprocesso ou ir para o menu do módulo ou menu principal.


E1 - Descrição do sub-evento previamente existenteO coordenador pode redigitar o nome do sub-evento ou cancelara operação.

E2 - Descrição em brancoO coordenador pode redigitar o nome e /ou descrição do sub-evento. ou cancelar a operação.

E6 - Não foi possível selecionar listagemSe a lista estiver vazia exibir informações a respeito. Se não foipossível executar a consulta exibir instruções de contataradminis-trador do sistema. Voltar ao menu do módulo

E7 - Não foi possível selecionar todos os valores de sub-eventospara um determinado evento.Informar o coordenador que não é possível exibir as informaçõespara o evento e o porque e permitir que seja selecionado outroevento.

42

E10 - Sub-Evento foi usado em InscriçãoNessa situação o coordenador deve ser informado de quais inscri-ções se enquadram. O sistema deve cancelar a operação.

Caso de uso ’Definir Publico Alvo’Este caso de uso fornece os meios para o coordenador definir para cadaevento criado no sistema quais alunos podem se inscrever nosmesmos.

Fluxo PrincipalSeu início dá-se quando o coordenador acessa o menu de Eventos edepois o menu Definir Publico Alvo do Evento. O sistema então ve-rifica se este coordenador tem permissão para trabalhar com PublicoAlvo e apresenta as opções para selecionar a atividade desejada: Inse-rir Turma, Inserir Aluno, Apagar Turma, Apagar Aluno, Consultar ouSair.Se a atividade selecionada é:

Inserir Turma , o sub-fluxo A1 (Inserir Turma no Publico Alvo) éexecutado;

Inserir Aluno , o sub-fluxo A2 (Inserir Aluno no Publico Alvo) éexecutado;

Apagar Turma , o sub-fluxo A3 (Apagar Turma do Publico Alvo) éexecutado;

Apagar Aluno, o sub-fluxo A4 (Apagar Aluno do Publico Alvo) éexecutado;

Consultar, o sub-fluxo A5 (Consultar Publico Alvo de Eventos) éexecutado;



A1 - Inserir Turma no Publico AlvoO sistema recupera os eventos (E1) do sistema e fornece um for-mulário contendo as opções para serem selecionadas. O coor-denador então seleciona um evento (E2) e o sistema recupera asturmas do sistema (E3) e exibe um formulário contendo o eventoselecionado e as opções de turma (E4) para o coordenador sele-cionar. Ao confirmar, o sistema recupera todos os alunos daquelaturma (E5) e exibe uma tela solicitando a confirmação dos dados.O sistema insere os alunos no publico alvo daquele evento (E6) e

43

exibe opção para poder reiniciar o processo ou ir para o menu domódulo ou menu principal.

A2 - Inserir Aluno no Publico AlvoO sistema recupera os eventos (E1) e fornece um formulário con-tendo as opções para serem selecionados. O coordenador entãoseleciona um evento (E2), o sistema recupera as turmas cadastra-das (E3) e exibe um formulário contendo o evento selecionadoeas opções de turma (E4) para o coordenador selecionar uma coma intenção de filtrar o numero de alunos a serem exibidos. Aoconfirmar, o sistema recupera todos os alunos daquela turma (E5)e exibe uma tela solicitando a seleção de um determinado aluno.Ao confirmar os dados, o sistema insere o aluno no publico alvodaquele evento (E6) e exibe opção para poder reiniciar o processoou ir para o menu do módulo ou menu principal.

A3 - Apagar Turma do Publico AlvoO sistema recupera os eventos (E1) do sistema e fornece um for-mulário contendo as opções para serem selecionadas. O coordena-dor então seleciona um evento (E2) e o sistema recupera as turmasdo sistema (E3) e exibe um formulário contendo o evento seleci-onado e as opções de turma (E4) para o coordenador selecionar.Ao confirmar, o sistema recupera todos os alunos daquela turma(E5) e exibe uma tela solicitando a confirmação dos dados. O sis-tema então exibe uma tela solicitando a confirmação da exclusãodos alunos daquele evento. O sistema remove todos os alunos da-quela turma do publico alvo daquele evento (E7) e exibe opçãopara poder reiniciar o processo ou ir para o menu do módulo oumenu principal.

A4 - Apagar Aluno do Publico AlvoO sistema recupera os eventos (E1) e fornece um formulário con-tendo as opções para serem selecionados. O coordenador entãoseleciona um evento (E2) e o sistema recupera as turmas do sis-tema (E3) e exibe um formulário contendo o evento selecionado eas opções de turma (E4) para o coordenador selecionar uma coma intenção de filtrar o numero de alunos a serem exibidos. Aoconfirmar, o sistema recupera todos os alunos daquela turma (E5)e exibe uma tela solicitando a seleção de um determinado aluno.Ao selecionar e confirmar o sistema exibe uma tela solicitando aconfirmação da exclusão do aluno daquele evento. O sistema re-move o aluno do publico alvo daquele evento (E7) e exibe opção

44

para poder reiniciar o processo ou ir para o menu do módulo oumenu principal.

A5 - Consultar Publico Alvo de EventosO sistema recupera os eventos (E1) do sistema e fornece um for-mulário com as opções para serem selecionadas. O coordenadorentão seleciona um evento (E2) e ao confirmar o sistema recuperatodos os alunos do publico alvo daquele evento (E8) e exibe natela. O sistema exibe opção para poder reiniciar o processo ou irpara o menu do módulo ou menu principal.


E1 - Não existem eventos cadastradosInformar o coordenador que não é possível exibir as informaçõesde evento e o porque.

E2 - Evento selecionado é inválidoO coordenador pode selecionar um valor válido ou cancelar a ope-ração.

E3 - Não existem turmas cadastradasInformar o coordenador que não é possível exibir as informaçõesde turmas e o porque.

E4 - Turma selecionada é inválidaO coordenador pode selecionar um valor válido ou cancelar a ope-ração.

E5 - Turma não tem alunosInformar o coordenador que não é possível exibir as informaçõesde alunos e o porque.

E6 - Não foi possível inserir aluno no publico alvo do eventoInformar o coordenador que não é possível inserir o aluno no pu-blico alvo do evento e o porque.

E7 - Não foi possível excluir aluno do publico alvo do eventoInformar o coordenador que não é possível excluir o aluno do pu-blico alvo do evento e o porque.

E8 - Não existe público alvo cadastrado para o eventoInformar o coordenador que não é possível exibir os dados dopublico alvo do evento e o porque.

Caso de uso ’Inscrever no Evento’Este caso de uso fornece os meios para o aluno poder se cadastrar em umdeterminado evento que esteja sendo oferecido no sistema.

45

Fluxo PrincipalEste caso de uso tem início quando um aluno acessa o menu de Even-tos. O sistema então verifica se este aluno tem permissão parase ins-crever em evento (E1) e apresenta as opções para selecionar aatividadedesejada: Inscrever-se, Cancelar Inscrição, Consultar Inscrições, Mo-dificar Inscrições ou Sair.Se a atividade selecionada é:

Inscrever-se, o sub-fluxo A1 (Inscrever Aluno em Eventos) é execu-tado;

Cancelar Inscrição, o sub-fluxo A2 (Cancelar Inscrição em Eventos)é executado;

Consultar Inscrições, o sub-fluxo A3 (Consultar Inscrições em Even-tos) é executado;


Descrição dos Sub-fluxos do caso de usoA1 - Inscrever Aluno em Eventos

O sistema recupera os eventos ainda não encerrados, não inicia-dos, liberados para iniciar inscrições, que o aluno faça parte dopúblico alvo e que não há inscrição cancelada para o aluno (E2)e exibe a lista de eventos possíveis para o aluno escolher. Apósinformar se deseja receber convocação e confirmar a escolha osis-tema inscreve o aluno no evento (E3) mantendo a inscrição comstatus inicial ’S’ (Solicitada pelo aluno). O sistema exibeopçãopara poder reiniciar o processo ou ir para o menu do módulo oumenu principal.

A2 - Cancelar Inscrição em EventosNessa opção o sistema recupera a lista de eventos em que o alunoestá inscrito que não estejam encerrados ou com prazos limites deinscrição vencidos e com status = ’S’ (E4). Após o aluno confir-mar, o sistema efetiva a desinscrição mudando o status da inscri-ção para ’C’ (Cancelada pelo aluno) (E5). O sistema exibe opçãopara poder reiniciar o processo ou ir para o menu do módulo oumenu principal.

A3 - Consultar Inscrições em EventosNesta opção o sistema recupera a lista de eventos em que o alunoestá inscrito sem distinção de status (E6), exibe os detalhes doevento e da inscrição. Exibe opção para poder reiniciar o processoou ir para o menu do módulo ou menu principal.

46


E1 - Aluno não tem permissão para acessar a ferramenta de ins-criçãoExibir mensagem de erro e instruções de como obter acesso.

E2 - Não existem eventos onde o aluno pode se inscreverO aluno deve ser informado se não existem eventos cadastradose se existem que não há eventos onde ele possa se inscrever nomomento. Deve ser informado para entrar em contato com a co-ordenação para maiores esclarecimentos.

E3 - Aluno não está inscrito em nenhum eventoInformar o aluno que não é possível exibir as informações de ins-crição e o porque.

E4 - Não há inscrições para cancelarInformar o aluno que não épossível exibir as informações de inscrição e o porque.

E5 - Ocorreu erro ao tentar atualiza a inscriçãoO aluno pode selecionar um valor válido ou cancelar a operação.O sistema deve informar o aluno que não é possível modificar asinformações de inscrição e o porque.

Caso de uso ’Analisar Inscrição’Este caso de uso fornece os meios para o coordenador aceitar ou não ins-crições feitas pelos alunos contanto com relatórios por alunos na mesmainterface para auxilio na tomada de decisão.

Fluxo PrincipalEste caso de uso tem início quando o coordenador acessa o menudeEventos e o sub-menu Analisar Inscrição. O sistema então verifica seo coordenador tem acesso a esta ferramenta (E1) e apresenta Tela comos eventos válidos (E2) para selecionar e analisar (A1) ou opção desair onde, o sistema vai para o menu do módulo ou menu principal.


A1 - Selecionar Evento e Analisar inscriçõesO sistema recupera os eventos ainda não encerrados e exibe a listade eventos possíveis para o Coordenador escolher. Após informaro evento, todos os inscritos (E3) e suas informações (E4), bemcomo as do evento (E5), são exibidas na tela. Nesta mesma telaacada aluno inscrito será possível definir o estado atual através deuma lista com os valores: ’R’ para rejeitar e ’A’ para aceitar. Aoconfirmar os dados da tela o sistema efetiva a alteração do status

47

e a análise (E6). O sistema exibe opção para poder reiniciar oprocesso ou ir para o menu do módulo ou menu principal.


E1 - Coordenador não tem permissão para acessar a ferramentade análise de inscriçõesExibir mensagem de erro e instruções de como obter acesso.

E2 - Não há eventos válidos para analisarUm evento válido para analisar é aquele que ainda não está emandamento, que tem alunos inscritos com status diferente de’C’e que exista no sistema. Caso uma das três condições anterioresnão seja satisfeita em todos os eventos existentes no sistema ocoordenador deve ser informado do fato e sugestionado a criar umevento e abri-lo para inscrições.

E3 - Não existem alunos inscritos neste eventoO coordenador deve ser informado disto e o sistema pode voltar asolicitar a escolha de um novo evento para analisar inscrições.

E4 - Não foi possível recuperar informações adicionais dos even-tos O coordenador deve ser informado sobre o fato e instruído acontatar o administrador do sistema.

E5 - Código do evento inválidoO coordenador pode voltar e selecionar um código válido ou can-celar a operação.

E6 - nem todos os registros puderam ser alterados de uma só vezO sistema deve desfazer as modificações feitas e informar o co-ordenar o que ocorreu e porque. O coordenador pode cancelar aoperação ou tentar novamente.

Caso de uso ’Convocar Aluno’Esse caso de uso fornece os meios para o coordenador identificar e emitirconvocações automáticas e obrigatórias em eventos.

Fluxo PrincipalEsse caso de uso tem início quando o coordenador seleciona nomenude eventos a opção de Convocar Alunos. O sistema então verifica seo coordenador tem acesso a esta ferramenta (E1) e apresenta tela paraselecionar um dentre os eventos primários cadastrados (E2)e entãoo sistema irá analisar a situação de cada aluno (A1) ’que estiver fa-zendo parte do publico alvo deste evento (E3)’ ou ’que estiver com amatrícula em dia no ARL e ainda não tiver concluído o curso’. Oco-ordenador pode daí avaliar o resultado da análise e selecionar o aluno

48

para ser convocado automaticamente pelo sistema (E4) ou cancelar aoperação. O sistema vai para o menu do módulo ou menu principal.


A1 - Analisar situação do alunoO sistema deve recuperar as informações de tipo de evento e suadependência (E5). Se o evento for do tipo primário e sem depen-dência, o sistema deve avaliar se o aluno esteve em outro eventosemelhante (E6). Para isto o sistema deve recuperar todos oseven-tos diferentes do atual cujos classificação seja primário, otipo sejao mesmo do evento atual, e que já foram encerrados e o aluno es-teja inscrito com status diferente de ’P’. Se o resultado da buscafor vazio, o aluno deve ser excluído da lista de candidatos a con-vocação. Se o evento for do tipo primário e com dependência,o sistema deve verificar além do exposto acima, primeiramente oexposto acima para o evento do qual este é dependente (E7). Seoresultado da busca for vazio o coordenador deve ser avisado queeste aluno não está habilitado a freqüentar este evento e deve serconvocado para uma próxima ocorrência do evento primário doqual este evento depende e o aluno não compareceu. Após o co-ordenador selecionar os alunos para as convocações baseadonasinformações apresentadas em tela como, aluno, data da matrícula,vencimento legal do prazo para conclusão, tempo restante para oaluno concluir o curso, se falta ainda vir no evento dependente, euma caixa para marcar o aluno, e aprovar, o sistema então irá efe-tuar a inscrição automática do aluno no evento atual com statusigual ’O’ (E8) e emitiráe-mailcom texto padrão cadastrado pelocoordenador no evento (E9) convocando o aluno obrigatoriamentee solicitando para o aluno que ele confirme pore-mailque recebeua convocação (verificar se precisa disto). O coordenador quecriouo evento recebe então pore-mail do sistema a lista com o nomede todos os alunos que foram convocados automaticamente paraeste evento (E10). O sistema apresenta então opção para reiniciaro processo ou voltar ao menu principal do sistema.


E1 - Coordenador não tem acesso a ferramentaExibir mensagem de erro e instruções de como obter acesso.

E2 - Não existem eventos primários e não finalizados cadastradosno sistema

49

Um evento válido para analisar é aquele que ainda não está fi-nalizado e que em seu tipo tenha o valor ’P’ de primário. Casoem todos os eventos existentes no sistema não exista um com estaclassificação o coordenador deve ser informado do fato e o sis-tema exibe opção de reiniciar o processo ou de ir para o menu domódulo ou principal.

E3 - Não existe publico alvo para o evento ou não foi possível de-terminar os alunos ainda matriculados e que não concluíramo cursoO sistema deve informar que não houve condições de determinaralunos para serem selecionados e terem sua situação analisada eexibir o porque. O sistema exibe opção de reiniciar o processo oude ir para o menu do módulo ou principal.

E4 - Não há alunos que necessitam ser convocados para o eventoselecionadoNão existem alunos que se enquadram na classifica-ção de urgência de execução de um determinado curso. Exibirinformação para o coordenador. O sistema exibe opção de reini-ciar o processo ou de ir para o menu do módulo ou principal.

E5 - Não foi possível determinar o tipo do evento ou sua depen-dênciaO coordenador deve ser informado do erro ao tentar determinaras informações agregadas do evento e sua possível causa. O sis-tema exibe opção de reiniciar o processo ou de ir para o menu domódulo ou principal.

E6 - Não foi possível determinar se houve outro evento seme-lhanteO coordenador deve ser informado do erro ao tentar determinaras informações de eventos semelhantes e sua possível causa.Osistema exibe opção de reiniciar o processo ou de ir para o menudo módulo ou principal.

E7 - Não foi possível determinar as informações do evento do qualeste é dependenteO coordenador deve ser informado do erro ao tentar determinar asinformações do evento do qual este depende e sua possível causa.O sistema exibe opção de reiniciar o processo ou de ir para o menudo módulo ou principal.

E8 - Não foi possível inscrever aluno no eventoO coordenador não possui permissão para executar esta atividadeou o sistema não foi informado corretamente com os dados neces-

50

sários para executar tal operação. Mensagem com o erro deve serexibida. O sistema exibe opção de reiniciar o processo ou de irpara o menu do módulo ou principal.

E9 - Não foi possível emitire-mail para aluno com a convocaçãoO coordenador não possui permissão para executar esta atividadeou o sistema não foi informado corretamente com os dados neces-sários para executar tal operação. Mensagem com o erro deve serexibida. O sistema exibe opção de reiniciar o processo ou de irpara o menu do módulo ou principal.

E10 - não foi possível emitire-mail para o coordenadorO coordenador não possui permissão para executar esta atividadeou o sistema não foi informado corretamente com os dados neces-sários para executar tal operação. Mensagem com o erro deve serexibida. O sistema exibe opção de reiniciar o processo ou de irpara o menu do módulo ou principal.

Caso de uso ’Inscrever no sub-evento opcional’Este caso de uso fornece os meios para o aluno poder optar por um sub-evento alternativo caso venha a existir durante um determinado evento.

Fluxo PrincipalEste caso de uso tem início quando um aluno acessa no menu de even-tos a ferramenta de Inscrever em Sub-evento Opcional. O sistema en-tão verifica se o aluno tem permissão para usar esta ferramenta (E1) eapresenta as opções para escolher um evento conforme sub-fluxo A1.


A1 - GeralO sistema exibe para o aluno uma lista de eventos para os quaisele está inscrito (E2). Após selecionar um evento o sistema exibepara o aluno os sub-eventos opcionais, caso existam (E3), daqueleevento e permite que seja escolhido um dos opcionais de cadagrupo de sub-eventos concorrentes. O aluno pode então cancelara operação ou confirmá-la para efetivar as alterações feitaspor ele(E4). O sistema exibe opção para poder reiniciar o processo ou irpara o menu principal.


E1 - Aluno não tem permissão para acessar a ferramenta de ins-criçãoExibir mensagem de erro e instruções de como obter acesso.

51

E2 - Não existem eventos onde o aluno está inscritoO aluno deve ser informado se não existem eventos para os quaisele está inscrito. Deve ser informado para entrar em contatocoma coordenação para maiores esclarecimentos.

E3 - O evento selecionado não possui sub-eventos alternativosO aluno deve ser informado do fato e instruído a entrar em contatocom a coordenação para maiores esclarecimentos.

E4 - Ocorreu um erro na base de dados e os dados não puderamser atualizadosO aluno deve ser informado do fato e instruído aentrar em contato com a coordenação para maiores esclarecimen-tos.

Caso de uso ’Imprimir lista de presença’Este caso de uso fornece os meios para o professor imprimir para cada sub-evento que ele ministrar e estiver criado no sistema uma lista de presençacom o nome de todos os alunos inscritos.

Fluxo PrincipalEste caso de uso tem início quando um professor acessa no menudeeventos a ferramenta de Imprimir Lista de Presença. O sistema entãoverifica se o professor tem permissão para usar esta ferramenta (E1) eapresenta as opções para escolher um evento conforme sub-fluxo A1.


A1 - GeralO sistema exibe para o professor uma lista de eventos (E2). Apósselecionar um evento o sistema exibe para o professor os sub-eventos daquele evento (E3) e permite que seja escolhido um de-les. O professor então verifica a lista exibida na tela com todosos alunos inscritos naquele sub-evento (status conforme descriçãoem referência para atributo da entidade) (E4) e pode então impri-mir a lista. O sistema exibe opção para poder reiniciar o processoou ir para o menu principal.


E1 - Professor não tem permissão para acessar a ferramenta delista de presençaExibir mensagem de erro e instruções de como obter acesso.

E2 - Não existem eventos cadastrados no sistema.O professor deve ser informado que não existem eventos cadastra-

52

dos no sistema. Deve ser informado para entrar em contato comacoordenação para maiores esclarecimentos.

E3 - O evento selecionado não possui sub-eventos cadastradosO professor deve ser informado do fato e instruído a entrar emcontato com a coordenação para maiores esclarecimentos.

E4 - Ocorreu um erro na base de dados e os dados não puderamser exibidos.O professor deve ser informado do fato e instruído a entrar emcontato com a coordenação para maiores esclarecimentos.

Caso de uso ’Preencher lista de presença eletrônica’Este caso de uso fornece os meios para a secretaria definir para cada sub-evento criado no sistema quais alunos participaram ou não.

Fluxo PrincipalEste caso de uso tem início quando a secretaria acessa no menudeeventos a ferramenta de Preencher Lista de Presença Eletrônica. Osistema então verifica se a secretaria tem permissão para usar esta fer-ramenta (E1) e apresenta as opções para escolher um evento conformesub-fluxo A1.


A1 - GeralO sistema exibe para a secretaria uma lista de eventos (E2) e emseguida a lista de sub-eventos (E3). Após selecionar um eventoe sub-evento, o sistema exibe para a secretaria a lista de presença(E4), semelhante a impressão de listas de presença. Nessa lista asecretaria pode marcar os alunos presentes de acordo com a listaimpressa pelo professor e assinada pelos alunos. A secretaria veri-fica a lista exibida e os dados marcados e atualiza a base de dadoscom os dados de presença no sub-evento alterando o status dosregistros (E5). O sistema exibe opção para poder reiniciar opro-cesso ou ir para o menu principal.


E1 - Secretaria não tem permissão para acessar a ferramenta delista de presençaExibir mensagem de erro e instruções de como obter acesso.

E2 - Não existem eventos cadastrados no sistemaA Secretaria deve ser informado que não existem eventos cadas-

53

trados no sistema. Deve ser informado para entrar em contatocoma coordenação para maiores esclarecimentos.

E3 - O evento selecionado não possui sub-eventos cadastradosA Secretaria deve ser informado do fato e instruído a entrar emcontato com a coordenação para maiores esclarecimentos.

E5 - Ocorreu um erro na base de dados e os dados não puderamser exibidosA Secretaria deve ser informado do fato e instruído a entrar emcontato com a coordenação para maiores esclarecimentos.

Caso de uso ’Avaliar presença no Evento’Este caso de uso fornece os meios para a secretaria definir para cada eventocriado no sistema quais alunos participaram plenamente nosmesmos.

Fluxo PrincipalEste caso de uso tem início quando a secretaria acessa no menudeeventos a ferramenta de Avaliar de Presença No Evento. O sistemaentão verifica se a secretaria tem permissão para usar esta ferramenta(E1) e apresenta as opções para escolher um evento conforme sub-fluxo A1.


A1 - GeralO sistema exibe para a secretaria uma lista de eventos (E2). Apósselecionar um evento, o sistema deve pesquisar na base de da-dos para todos os alunos inscritos nesse evento (E3), quais são ossub-eventos (E4) e qual o status do aluno para cada sub-evento.Se em todos os sub-eventos do evento o aluno está presente (sta-tus em inscricao_sub_evento) (E5)então o sistema muda o statusda participação no evento para "Presente". Ao fazer a pesquisa osistema deve considerar o fato de poder haver sub-eventos alter-nativos concorrentes em um evento e a presença em apenas umdeles já é válida (E6). O sistema exibe opção para poder reiniciaro processo ou ir para o menu principal.


E1 - Secretaria não tem permissão para acessar a ferramenta delista de presençaExibir mensagem de erro e instruções de como obter acesso.

E2 - Não existem eventos cadastrados no sistema.A Secretaria deve ser informado que não existem eventos cadas-

54

trados no sistema. Deve ser informado para entrar em contatocoma coordenação para maiores esclarecimentos.

E3 - O evento selecionado não possui sub-eventos cadastradosA Secretaria deve ser informado do fato e instruído a entrar emcontato com a coordenação para maiores esclarecimentos.

E4 - O sub-evento selecionado não possui alunos inscritosA Secretaria deve ser informado do fato e instruído a entrar emcontato com a coordenação para maiores esclarecimentos.

E5 - O Aluno não pode ser considerado presenteOs casos onde o aluno não puder ser passado para ’presente’ de-vem ser exibidos para a Secretaria analisar e completar as infor-mações se necessário.

E6 - Ocorreu um erro na base de dados e os dados não puderamser exibidosA Secretaria deve ser informado do fato e instruído a entrar emcontato com a coordenação para maiores esclarecimentos.

55

Capítulo 5

Implementação

A implementação do módulo de eventos teve seu início no estudo da base de da-dos já existente doE-duc@re. Foi fornecido pelo Prof. Samuel, em meados dejaneiro de 2004, uma versão da base de dados doE-duc@repois as ferramentasdo módulo de eventos devem se integrar aos módulos já existentes. Além da estru-tura das tabelas, foi fornecido também umdumpda base de dados conforme ela seencontrava naquele período. No jargão da informáticadumppode ser um arquivocontendo as tabelas de uma base de dados e alguns registros para poder ser usadoou recuperado em outra base de dados ou de outra maneira conveniente. O estudoda base de dados e dos seus registros juntamente com a análisedas necessidadesdo gerenciamento de eventos, gerou a modelagem da base de dados e das ferra-mentas apresentadas no Capítulo 4.O banco de dados usado foiMySQL1 pois tanto oTelEducquanto oE-duc@rejáusavam esse gerenciador de base de dados.Para a implementação das interfaces do projeto, bem como osscripts de bancode dados, foram usados editores de texto comuns comoJEdit2, KWrite, Nedit3.Os editores exemplificados oferecem o recurso de colorir o texto de acordo com otipo do arquivo (sintax highlight). Essa característica ajuda muito o programadora encontrar problemas de sintaxe nos programas de acordo coma linguagem deprogramação ou script que está sendo escrito o programa. Esses editores de textonão inserem marcas especiais no texto com propósito de formatação, o que podeconfundir os interpretadores de programas e causar comportamentos indesejadosquando os programas estão sendo executados. Todos osscriptsna linguagem PHP

1MySQL- http://www.mysql.com2JEdit - http://www.jedit.org3NEdit - http://www.nedit.org/

57

e osscriptspara o banco de dados foram escritos usando os editores de texto men-cionados.Devido a complexidade do desenvolvimento do módulo de eventos não ser muitoalta, não foi necessário o uso de um programa do tipoComputer Aided SoftwareEngineeringespecífico. Tais programas são mais comumente conhecidos por suasiglaCASEou ferramentasCASE. São programas que auxiliam o desenvolvimentodesde a modelagem até a geração automatizada de partes dos programas.Os diagramas resultantes das análises foram obtidos através do uso das ferramen-tas simples do pacoteOpen Office4.Com o objetivo de manter um ambiente estável e menos sujeito ao uso diário docomputador foi configurado umnotebookcom sistema operacionalLinux RedHat9. Nessenotebookforam instalados e configurados alguns programas e serviçospara ficar equivalente ao computador servidor real. Entre eles estão:

• Apache- Serviço para gerar as páginas WEB das interfaces do módulo deeventos

• MySQL- Gerenciador e serviço do banco de dados

• PHP - como módulo doApachepara permitir que os programas ouscriptsescritos nessa linguagem quando requisitados produzam as páginas WEBdesejadas bem como as interfaces dos módulos doE-duc@re

Para que fosse possível aos orientadores acompanhar o desenvolvimento das fer-ramentas e ao mesmo tempo não colocar em risco o ambiente de produção doE-duc@refoi configurado um site com os mesmos serviços donotebook. Esse sitepossui uma interface de administração própria porém permite a execução de scriptsde manipulação e criação de base de dados e também de carga de arquivos novos.Essa configuração de uma forma geral possibilita e facilita odesenvolvimento desistemas à distância.Ao término da instalação e da configuração de todos os sistemas, incluindo oE-duc@ree oTelEduc, foi iniciado o processo de implementação das interfaces domódulo de eventos. A sua implementação e o exemplo de suas telas estão descritasnas próximas seções.Conforme a modelagem do Capítulo 4 e a descrição dos casos de uso foram desen-volvidas as ferramentas que constituem o módulo de eventos.Na seqüência estáa descrição de cada uma delas com uma breve explanação de seu uso. De certaforma o Capítulo 5 poderia ser considerado um manual do usuário bem resumido.

4Open Office- http://www.openoffice.org

58

5.1 Ferramentas de ’Tipo de Evento’

5.1.1 Criar um Novo Tipo de Evento

Através dessa ferramenta é possível criar os tipos de eventos que serão controladospelo sistema. Exemplos de tipo de evento são encontros presenciais, provas, pales-tras,chats, etc. Sua implementação segue a descrição do caso de uso "GerenciarTipo de Evento"sub-fluxo A1.Na interface vista na Figura 5.1 deve-se informar o nome do tipo de evento, suadescrição, se o evento é obrigatório ou não, se existe um pré-requisito para parti-cipar dele, e se é primário ou secundário.O campo ’Nome do Tipo de Evento’ é obrigatório e o valor digitado nele será

Figura 5.1: Adicionar ’Tipo de Evento’ - Tela Inicial

exibido nas outras interfaces do sistema. O campo ’Descrição’ deve ser preen-chido com o significado daquele ’Tipo de Evento’. O campo ’Pré-Requisito’ aoser preenchido indica para o sistema que, para o ’Tipo de Evento’ que está sendocadastrado, existe um outro ’Tipo de Evento’ dependente. Esse outro ’Tipo deEvento’ deve ser realizado pelo aluno antes de realizar um evento com o ’Tipo de

59

Evento’ que está sendo criado nesse momento. Como exemplo podem ser citadosos encontros técnicos nacionais. Quando o ’Tipo de Evento’ com o nome ’Se-gundo Encontro Técnico Nacional’ for cadastrado, deve ser informado que existeum pré requisito do ’Tipo de Evento’ com o nome ’Primeiro Encontro TécnicoNacional’. Isso significa que se um aluno não participou de umevento do tipo’Primeiro Encontro Técnico Nacional’, ele não poderia participar de um evento dotipo ’Segundo Encontro Técnico Nacional’. Essa informaçãoserá usada na inter-face de convocação de alunos do item 5.4.9 descrita mais a frente. A Figura 5.2mostra uma tela com um exemplo preenchido.Após preencher e clicar em ’Adicionar Tipo de Evento’ o sistema faz as verifica-

Figura 5.2: Adicionar ’Tipo de Evento’ - Exemplo

ções de consistência definidas na especificação e se estiver correto insere o registrona base de dados conforme a Figura 5.3.

Figura 5.3: Adicionar ’Tipo de Evento’ - Operação Realizada com Sucesso

60

5.1.2 Exibir os Tipos de Evento

Com a ferramenta ’Exibir Tipos de Evento’ é possível verificar quais ’Tipos deEvento’ foram criados no sistema. Esta interface também possui as chamadas paraas ferramentas de modificação e deleção de tipos de eventos. Sua implementaçãosegue a descrição do caso de uso "Gerenciar Tipo de Evento"sub-fluxo A4 e suautilização pode ser vista na Figura 5.4.

Na coluna ’Código do Tipo de Evento’ também são exibidos doislinks. Um

Figura 5.4: Exibir ’Tipo de Evento’

é lança a interface de modificação de ’Tipo de Evento’ e outro lança a interfacepara apagar um ’Tipo de Evento’. Eles estão identificados por’[mod]’ e ’[del]’respectivamente, dentro da coluna ’Código do Tipo de Evento’.

5.1.3 Modificar um Tipo de Evento

Esta interface é disparada a partir da interface de exibiçãodos dados de ’Tipos deEvento’. Seu uso é muito semelhante a interface de Inclusão,porém os dados quejá estão cadastrados aparecem já preenchidos na tela. A Figura 5.5 ilustra essasituação.A implementação da interface ’Modificar um Tipo de Evento’ segue a descrição

do caso de uso "Gerenciar Tipo de Evento"sub-fluxo A2.

5.1.4 Apagar um Tipo de Evento

Esta interface possui duas opções de inicialização. Uma é pela interface de exi-bição conforme mencionado anteriormente. A outra é pela própria interface dedeleção de ’Tipo de Evento’. Na Figura 5.6 é possível verificar o aspecto dessainterface.

61

Figura 5.5: Modificar ’Tipo de Evento’

Ao clicar no link identificado por ’[del]’ o ’Tipo de Evento’ aser apagado é sele-cionado e é exibido um botão para ser confirmada a ação sobre o item escolhido.Após pressionar o botão o ’Tipo de Evento’ é excluído da base observando-se asrestrições impostas no caso de uso "Gerenciar Tipo de Evento"sub-fluxo A3.

5.2 Ferramentas de ’Evento’

5.2.1 Criar um Novo Evento

Através dessa ferramenta é possível criar os eventos para serem controlados pelosistema. Exemplos de evento são o "1o Encontro Presencial da Turma ARL2001","Mini Curso de Pacotes em Jan/2004", "Defesa de Monografia emDezembro de2004", etc. A interface pode ser vista na Figura 5.7. Nela devem ser informados otipo de evento, a descrição do evento, as datas, número de participantes mínimo emáximo. Sua implementação segue a descrição do caso de uso "Criar Evento"sub-fluxo A1.O controle de eventos começa com o preenchimento do formulário de cadastro.

Campos como data de início e término e turno de início e término são de pre-enchimento obrigatório. A Figura 5.8 ilustra um exemplo de preenchimento deformulário.

62

Figura 5.6: Apagar ’Tipo de Evento’

Após preencher o formulário e clicar em ’Adicionar Evento’ osistema faz asverificações de consistência definidas na especificação e se estiver correto insere oregistro na base de dados. A Figura 5.9 ilustra a mensagem de sucesso.

5.2.2 Exibir Eventos

Com a ferramenta ’Exibir Eventos’ é possível verificar quaiseventos foram criadosno sistema. Essa interface também possui as chamadas para asferramentas demodificação e deleção de eventos. Sua implementação segue a descrição do casode uso "Gerenciar Evento"sub-fluxo A4. A Figura 5.10 ilustrasua utilização.Na coluna ’Código do Evento’ são exibidos doislinks. Um é para a interface de

modificação de evento e outro para a interface de deleção de evento. Eles estãoidentificados por ’[mod]’ e ’[del]’ respectivamente, dentro dessa coluna.

5.2.3 Modificar Evento

Esta interface é disparada a partir da interface de exibiçãodos dados de Evento.Seu uso é muito semelhante a interface de Inclusão de Evento,porém os dadosque já estão cadastrados aparecem preenchidos na tela. A Figura 5.11 ilustra essasituação.

Sua implementação segue a descrição do caso de uso "Gerenciar Evento"sub-fluxo A2.

63

Figura 5.7: Adicionar Eventos - Tela Inicial

64

Figura 5.8: Adicionar Eventos - Exemplo

65

Figura 5.9: Adicionar Eventos - Operação Realizada com Sucesso

Figura 5.10: Exibir Eventos

5.2.4 Apagar Evento

Essa interface possui duas opções de inicialização. Uma é pela interface de exi-bição de ’Evento’ conforme mencionado anteriormente. A outra é pela própriainterface de deleção de ’Evento’. Na Figura 5.12 é possível verificar o aspectodessa interface.Ao clicar no link identificado por ’[del]’ o tipo de evento a ser apagado é selecio-

nado e é exibido um botão para ser confirmada a ação sobre o itemescolhido. Apóspressionar o botão de confirmação o Evento é excluído da base observando-se asrestrições impostas no caso de uso "Gerenciar Evento"sub-fluxo A3.

5.3 Ferramentas de ’Sub-Evento’

5.3.1 Criar um Novo Sub-Evento para ’Evento’

Através dessa ferramenta é possível criar os sub-eventos deum evento que serãocontrolados pelo sistema. Exemplos de sub-eventos são mini-cursos, palestras,provas, etc. Sua implementação segue a descrição do caso de uso "Criar Sub-Evento"sub-fluxo A1. Na interface mostrada na Figura 5.13 deve-se informar oevento principal, o tipo do sub-evento, sua descrição, datae hora de início e tér-mino e se esse sub-evento possui um outro sub-evento que sejaalternativo.

66

Figura 5.11: Modificar Eventos

67

Figura 5.12: Apagar Eventos

O campo sub-evento alternativo indica que no mesmo horário edata será ofere-cido outro sub-evento. Essa informação será usada pela rotina Avaliar Presença noEvento disponibilizada para a coordenação. Segue uma tela com um exemplo naFigura 5.14.Após preencher e clicar em ’Adicionar Sub Evento’ o sistema faz as verificações

de consistência definidas na especificação e se estiver correto insere o registro nabase de dados. A mensagem da Figura 5.15 é exibido se foi possível inserir o re-gistro.

5.3.2 Exibir os Sub-Eventos

Usando essa ferramenta é possível para os coordenadores verificar quais sub-eventos foram criados no sistema. Esta interface também possui as chamadas paraas ferramentas de modificação e deleção de sub-eventos. Sua implementação se-gue a descrição do caso de uso "Criar Sub-Evento"sub-fluxo A4. Seu uso pode servisto na Figura 5.16.Na coluna do código do sub-evento também são exibidos doislinks. Um é para

a interface de modificação de sub-evento e outro para a interface de deleção desub-evento. Eles estão identificados por ’[mod]’ e ’[del]’ respectivamente, dentroda coluna código do sub-evento.

68

Figura 5.13: Adicionar Sub-Eventos - Tela Inicial

5.3.3 Modificar ’Sub-Evento’

Essa interface é disparada a partir da interface de exibiçãodos dados de Sub-Eventos. Seu uso é muito semelhante a interface de Inclusão,porém os dadosque já estão cadastrados aparecem já preenchidos na tela. A Figura 5.17 ilustraessa situação.

Sua implementação segue a descrição do caso de uso "Criar Sub-Evento"sub-fluxo A2.

5.3.4 Apagar um Sub-Evento

Essa interface possui duas opções de inicialização. Uma é pela interface de exi-bição conforme mencionado anteriormente. A outra é pela própria interface dedeleção de Sub-Evento. Na Figura 5.18 é possível verificar o aspecto dessa inter-face.Ao clicar nolink identificado por ’[del]’ o tipo de evento a ser apagado é selecio-

nado e é exibido um botão para ser confirmada a ação sobre o itemescolhido. Apóspressionar o botão de confirmação, o Sub-Evento é excluído dabase observando-seas restrições impostas no caso de uso "Criar Sub-Evento"sub-fluxo A3.

69

Figura 5.14: Adicionar Sub-Eventos - Exemplo

Figura 5.15: Adicionar Sub-Eventos - Operação Realizada com Sucesso

70

Figura 5.16: Exibir Sub-Eventos

Figura 5.17: Modificar Sub-Eventos

71

Figura 5.18: Apagar Sub-Eventos

5.4 Ferramentas Administrativas

5.4.1 Inserir Turma no Público Alvo

Para que os alunos possam se inscrever em um dado evento é necessário que ocoordenador tenha definido o público alvo para esse evento.

Usando a ferramenta de Inserção de Público Alvo mostrada na Figura 5.19, ocoordenador seleciona qual evento deve ser gerenciado e em seguida a turma dosalunos para ser cadastrada. A Figura 5.20 exibe um exemplo deseleção.Quando o botão ’Selecionar Turma’ é pressionado, o sistema exibe uma tela com

a lista dos alunos ainda ’Ativos’ para conferência (Figura 5.21). Essa ferramentaimplementa o caso de uso ’Definir Publico Alvo’.

5.4.2 Analisar Inscrição

Após criar os eventos e suas configurações é necessário que o coordenador valideas intenções de participação registradas pelos alunos vista na Figura 5.22.Após acessar essa ferramenta e selecionar o evento desejado, é exibida uma lis-

tagem com todos os alunos que se inscreveram no evento, conforme exemplo da

72

Figura 5.19: Adicionar Turma no Publico Alvo de um Evento - Tela Inicial

Figura 5.20: Adicionar Turma no Publico Alvo de um Evento - Exemplo

73

Figura 5.21: Adicionar Turma no Publico Alvo de um Evento - Lista de Alunos

Figura 5.22: Analisar Inscrições

74

Figura 5.23. Na coluna ’Aceitar ou Rejeitar’ existe um botãopara aceitar e outropara rejeitar a intenção do aluno em participar do evento. A ação de clicar nessesbotões para cada aluno listado, registra no banco de dados que o coordenador estáaceitando ou rejeitando a inscrição do aluno. Essa ferramenta é descrita no casode uso Analisar Inscrição.

Figura 5.23: Analisar Inscrições - Lista de Alunos Inscritos

5.4.3 Inscrever Aluno no Evento

Um aluno pode participar de um evento desde que ele faça o registro da sua in-tenção de participar. Para que seja possível ele realizar essa atividade, existe umaferramenta para inscrição. Sua interface pode ser visualizada na Figura 5.24.Após Clicar no botão ’Inscrever no Evento’ é feito o registrona base de dados. O

caso de uso ’Inscrever no Evento’ sub-fluxo A1 está implementado nessa interface.

75

Figura 5.24: Inscrever Aluno em Evento

5.4.4 Exibir Inscrito em Evento

Figura 5.25: Exibir Inscrito em Evento

Após realizar a sua inscrição em um ou mais eventos, o aluno pode verificar asinformações de sua inscrição usando a ferramenta ’Exibir Inscrito em Eventos’. AFigura 5.25 mostra a tela com um exemplo da consulta mencionada anteriormente.A partir do link no rodapé da tela é possível executar diretamente a ferramenta de’Inscrever em Evento’ sem a necessidade de acessar o menu de ferramentas dapágina.

5.4.5 Imprimir Lista de Presença

Uma das tarefas durante a execução de um evento é obter uma lista de presençaorganizada e assinada por todos. A ferramenta de imprimir lista de presença é a

76

implementação do caso de uso ’Imprimir Lista de Presença’. Para iniciar seu usoo professor deve selecionar o evento para o qual ele deverá gerar as listas (Figura5.26).Em seguida, o professor deve selecionar um dos sub-eventos do evento principal

Figura 5.26: Imprimir Lista de Presença - Selecionando um Evento

e clicar no botão de imprimir lista (Figura 5.27).Por final a lista de presença é apresentada levando-se em consideração o disposto

Figura 5.27: Imprimir Lista de Presença - Selecionando um Sub-Evento

no caso de uso que descreve essa ferramenta (Figura 5.28).

5.4.6 Inscrever Sub-Evento Alternativo

Em um evento é possível que haja sub-eventos simultâneos. Quando houver sub-eventos desse tipo em um mesmo evento o aluno deverá optar porum dos sub-eventos simultâneos daquele evento. Isso é feito através dainterface ’InscreverSub-Evento Alternativo’. A Figura 5.29 mostra a tela da interface após ter sidoselecionado um evento. O aluno deve fazer sua opção por um doseventos exibidosem linha.

77

Figura 5.28: Imprimir Lista de Presença - Lista Final (em Tela)

Caso exista mais de um conjunto de sub-eventos simultâneos,cada conjuntoé exibido numa linha e o aluno deve escolher um sub-evento de cada conjuntoclicando no botão correspondente da tela.

5.4.7 Preencher Lista de Presença Eletrônica

Com a ferramenta ’Preencher Lista de Presença Eletrônica’ épossível registrar nosistema para cada sub-evento de um determinado evento os alunos que comparece-ram. Em outras palavras, esta o uso dessa ferramenta pode serconsiderado comoa transcrição da lista de presença para o sistema. Essa informação é usada na veri-ficação da presença de um aluno num evento.Para preencher a lista de presença eletrônica basta acessa omenu correspondente,

selecionar o evento e o sub-evento desejados. O sistema então exibe uma lista comtodos os alunos inscritos naquele sub-evento e também uma caixa para marcar aspresenças. Essa ferramenta pode ser usada mais de uma vez para o mesmo sub-evento. Caso isso ocorra, para os alunos que foram marcados como ’Presente’ alistagem apresenta a caixa de marcação preenchida.

5.4.8 Avaliar Presença no Evento

Para iniciar o processo de avaliar a presença dos alunos no evento basta abrir a in-terface ’Avaliar Presença no Evento’. Quando essa interface é executada, o sistema

78

Figura 5.29: Inscrever Sub-Evento Alternativo

realiza as verificações necessárias sobre o estado do eventoe seus sub-eventos paracada aluno. Caso haja sub-eventos para os quais as informações de presença nosub-evento estejam pendentes, o sistema exibe uma listagemcom eles. Na Figura5.31 pode ser vista uma listagem onde há sub-eventos com pendência de informa-ções. Essas pendências devem ser verificadas pelas ferramentas de Preenchimentode Lista de Presença Eletrônica. Apesar de ter pendências nosistema, é permitidoque a informação para o aluno sobre o evento selecionado sejaatualizada. Bastamarcar a opção correspondente ao aluno e pressionar o botão ’Atualizar’.Caso não haja pendências de informações para o aluno a tela daFigura 5.32 é

exibida. O sistema identifica os alunos com todas as informações preenchidas eautomaticamente marca seus respectivos campos para facilitar o trabalho de atu-alização de informações. Entretanto somente após clicar nobotão ’Atualizar’ osdados selecionados manual e automaticamente serão gravados.

5.4.9 Convocar Aluno

A ferramenta de convocação de alunos permite que a coordenação realize a tarefade verificar quem já compareceu em eventos. A ferramenta realiza diversas pes-quisas no sistema, analisa os resultados e sugere para a coordenação os alunos que

79

Figura 5.30: Preencher Lista de Presença Eletrônica

80

Figura 5.31: Avaliar Presença - Aluno está com Pendências

81

Figura 5.32: Avaliar Presença - Aluno sem Pendências

Figura 5.33: Convocar Aluno - Listagem Inicial

82

devem ser convocados ou não para um determinado evento.Inicialmente é necessário escolher um evento para ser analisado. Primeiramente

Figura 5.34: Convocar Aluno - Listagem Intermediária

é feita uma análise sobre o público alvo desse evento. Em seguida é feita umaanálise para todos os outros alunos do curso. As análises sãosemelhantes, porémdiferem em relação ao conjunto de alunos que estão sendo analisados.Para enviar a convocação para um aluno basta marcar a caixa apropriada e em

Figura 5.35: Convocar Aluno - Rodapé da Listagem

seguida pressionar o botão enviar convocação. O sistema tenta então enviar ose-mailsde convocação conforme cadastrados e se não for possível exibe o textocompleto doe-mailna tela para poder ser copiado.

83

Capítulo 6

Conclusão

No desenvolvimento deste novo módulo de controle eventos para oE-duc@refo-ram colocadas em prática as matérias estudadas no curso ARL.Juntamente às no-vas técnicas formalmente aprendidas, foram utilizadas algumas experiências pré-vias do autor no que diz respeito à engenharia desoftwaree desenvolvimento desistemas. As necessidades de ferramentas de apoio à tomada de decisão e de usoadministrativo descritas na Seção 2.4 trouxeram o tema deste trabalho ’à tona’.Participar do curso ARL foi uma experiência muito boa. A modalidade de educa-ção a distância (EaD) mediada pela Internet não fazia parte da ’carteira’ de cursosrealizados pelo autor anteriormente. Poder colaborar com amelhoria de um ambi-ente virtual, em particular o usado pelo ARL, trouxe muita satisfação para o autor.Não só a participação no curso foi à distância mas também o desenvolvimento dasferramentas propostas. A experiência do desenvolvimento àdistância também foinova para o autor e muito proveitosa. Nesse processo, a comunicação, através dosserviços oferecidos na Internet, teve um papel fundamentalde prover o contatoentre os envolvidos. Através do uso dechats, e-mails, WEB sitese o próprio am-biente virtual do curso descrito no Capítulo 1 foi possível trocar informações, tirardúvidas, enviar exemplos e receber comentários.Durante os encontros presenciais também foi possível obterinformações e co-laborações dos orientadores deste trabalho. No primeiro encontro presencial foidefinido o tema deste trabalho e também as principais ferramentas que deveriamcompor o novo módulo de eventos. Vale mencionar que oE-duc@rejá possuium módulo de eventos. O módulo existente precisava de funcionalidades adicio-nais para facilitar o trabalho da coordenação do curso em relação a eventos. Paraimplementar essas novas funcionalidades foi decidido criar um novo módulo deeventos ao invés de evoluir o módulo atual. A idéia de desenvolver um módulo

85

novo mostrou-se bastante adequada e facilitou o desenvolvimento das novas in-terfaces e das novas funcionalidades. Mesmo sendo novo, o desenvolvimento domódulo seguiu osguidelines(Anexo A.1) de desenvolvimento com o objetivo defacilitar sua manutenção, padronização em relação aos outros módulos e sua futuraexpansão.O novo módulo de controle de eventos para oE-duc@refoi implementado para su-prir as necessidades ainda existentes com o módulo atual. Entre elas estão a listade presença (papel e eletrônica), convocação de alunos e verificação de alunos quejá compareceram ou não nos encontros obrigatórios. As ferramentas descritas noCapítulo 5 preenchem esse espaço e fornecem meios para a coordenação do cursoadministrar essas informações de maneira mais automatizada e simplificada.O conceito de gerenciamento de eventos apresentado no Capítulo 4 foi implemen-tado para ser integrado aoE-duc@reque nesta época encontra-se integrado aoTelEduc. Futuramente, o mesmo conceito pode ser implementado observando-sea integração com outros ambientes virtuais e outras linguagens de programação.A camada de modelagem de dados apresentada não é completamente dependentedas linguagens de programação utilizadas e nem do ambiente virtual. Entretantosão necessários pequenos ajustes na modelagem para integrar o conceito do novomódulo de controle de eventos em outros ambientes virtuais elinguagens de pro-gramação.Especificamente sobre este novo módulo de eventos poderiam ser implementadasnovas funcionalidades como:

• Controle de materiais e equipamentos para os eventos como: datashow,retro-projetor, computadores, etc;

• Controle de salas como: auditórios, anfiteatros, laboratórios, etc;

• Evoluir a interface de gerenciamento de público alvo;

• Interface para confirmar presença eletronicamente;

• Aviso das ações dos alunos no sistema para a coordenação;

Ao término do desenvolvimento deste novo módulo, mesmo não implementandoas futuras funcionalidades acima propostas, o autor esperater contribuído parafacilitar e simplificar as atividades do gerenciamento e controle da participação dealunos nos eventos presenciais oferecidos pela coordenação do curso ARL.

86

Referências Bibliográficas

BOOCH, G.; RUMBAUGH, J.; JACOBSON, I.UML - Guia do Usuário(Tradução de: The Unified Modeling Language User Guide). 1. ed. Rio DeJaneiro - RJ: Editora Campus, 2000.

CODD, E. F. A relational model of data for large shared data banks.Commun.ACM, v. 13, n. 6, p. 377–387, 1970.

DIAS, S. P.E-duc@re: Proposta de Ambiente de Aprendizagem Suportadopela Web para Cursos de Nível Superior Oferecidos a Distância. Dissertação(Mestrado) — Universidade Federal de Lavras, 2003.

MACHADO, F. N. R.; ABREU, M.Projeto de Banco de Dados - Uma VisãoPrática. 2. ed. São Paulo - SP: Editora érica, 1997.

MEC. Secretaria de Educação a Distância - site. 2001.Http://www.mec.gov.br/seed/.

NUNES, I. B. Noções de educação a distância.Revista Educação a Distância -INED, v. 1, n. 4, Dec/93-Abr/94 1993.

UCHÔA, J. Q.; UCHÔA, K. C. do A.Guia Didático. 1. ed. Lavras - MG:UFLA/FAEPE, 2002.

UCHÔA, J. Q.; UCHÔA, K. C. do A.Introdução a Cibercultura. 4. ed. Lavras -MG: UFLA/FAEPE, 2004.

YOURDON, E.Análise Estruturada Moderna. 3. ed. Rio de Janeiro: EditoraCampus, 1992.

87

Apêndice A

Apêndices

A.1 Guidelines Para o Desenvolvimento Padronizado

A.2 Estatísticas de Utilização de Apache e PHP

89

� �� "!�#%$'&)('*'+,#.-0/%1�23#.4657#.8:90+)#;46$:#�83#;4<9=2>9?2'#;2>1;4�2>9A@;9B4C9AD�EF90&G5H#�(I1.DJ!K9A&)1K2>9=1.8>LM9A5C1;4N *'9=&O$:P�+)*3#%!Q!SRA5C1>2>1T4J(3#%DH#�9AU>90P�*'57#%DV#;4J1.(I9ADH#.-AWT9X4Y8:Z.4C&)P0#.4#%8:#%&OU[1:\

] 4C9A+)90PA&O1;$3#%D=^=_'$'&,PA#S57*'('+,#K2'#K83#.4C9?#`57D7#a@;R04�2'#KPHb3#[email protected](3#.4747#.2'#S#%1�P�1;$34<5CD7*>5C1;D0c] #.+G579ADH#%DJ1;4P0#%!K(I1;4?de#%5CD7&O83*>5C1T42'#KP�+,#.474<9afgc] 47#%+)@`#%D#.4#.+G579ADH#.-AWT9X4�1.*h&O$3PA+O*3&ODV*3!K#S$'1`@`#�5C*3('+)#3c] 9AU'P�+)*'&OD1KD79Ai;&)4<5CD71�D79A+,#.PA&O1;$3#.2'1�#%1K1;8>LM9�5713j k4�P�+,#.474C904 96#`57DC&)8'*>571;4l2>9A@;9A!m(I1;474<*3&OD�4<90*�$'1;!K96P�1;$34<5C&O5C*'n,2>1B(:1;D &)$'&,P�&,#%&,4o!K&)$T_:4MpP�*3+)#;4qdF9AU>PA9�571V1;4�PA1.!K(I1;4<5C1;4r(I1.Dl4<&)i.+,#.4HfI9q90!s&)$'i.+)t040uaP�1.!K1(I1.D�9AU>9A!K('+)1vrw%x;yruAz'{[{>|3u9�5HP%j } 4J!KR�5C1>2>1T4?dF1;(:90D7#;-�W[904Hfgu'2>[email protected]!~4<90i.*'&)DV#K4<90i.*'&)$T5C9=$'1;DC!�#`57&O�X#.-0/%13\] #S+)9�57D7#S&)$'&)PA&)#.+o2>[email protected]?4<90D!K&O$[_347P�*'+,#'c] EF*3$3-�W[904 N *39J#.+G579ADH#%!m1=@`#%+)1.D�2>9J*'!�#`5CD7&)8'*>5C1=2>[email protected]<90DqP�1;!S(I1;4<57#�(I9A+)1B(3DC9A�'U>1w.x;z�4C9Ai;*'&)2'1�(I9A+)1�$'1.!K9?2>1�#`57DC&)8'*>5713u'PA1.!K1K(:1;D9�U>9A!K('+)1hw%x;z[�'�a�Ix��0�[c] EF*3$3-�W[904 N *'9�PA1.$34C*'+O57#%!�1�@`#%+)1.DK2>9�*'!�#%5CD7&O8'*'5C1�4<90i.*'90!�#�D790PA1.!K9A$:2'#.-0/%1#.$T5C9AD7&)1.DXu[4C*'834<5C&O5C*3&O$32'1�1S(3DC9A�'U>1S(I1.D�'x;z�dF�'x;z[�'�X�rx��0�%fgc] EF*3$3-�W[904 N *'9=#%(I9A$:#.4�9�U>90PA*>57#.!�*'!�#K#.-A/.13u[P�1;!S1S(I1.DJ9�U>9A!K('+)13u>47#%+)@`#%DJ1SPA1.$>p579A_32'1S2>1�1.8>LM9A5C1�$'1�83#.$3P�1S2>9=2'#.2>1T4Au[2>[email protected]!�579ADJ4<90*�$'1;!S9B2>9��:$'&)2'1SPA1.!�*'!@;9AD78:1:u'P�1;!S1hw.�;�'xl�0�=1.*��>x>|;x;z'x��0�Tc] 2'[email protected]<90D�&O$:P�+)*'n)23#*'!�#Y�C#.474<&)$3#`57*'DH#a��#.$T5C904o2'#&)!S(3+O90!S90$T57#.-0/%1V2>96PA#.23#�EF*'$3-A/.13u9X4<(I90PA&G�IPA#%$:2>1�1�DC9A5C1;DC$'1h904C(I9ADH#.2>1:uo(3#.D7�.!S9A5CD71;4BD790P�908'&,2>1;4=9�*'!�#�8'D79A@;9�2>9�p47P�D7&,-A/%1K2>1SEF*'$3PA&O1;$3#%!K90$;571�2'#SEF*'$3-0/%13u'PA1.!K1S!S1T4M57D7#;2>1S$3#��l&Oi;*'D7#�^.c] (I1.$T571;4BP�D7nG57&)PA1;4B2'#�EF*'$:-A/%1:u N *39�$3/.1�(I1;474C#.!�4<90DkEe#;P�&)+O!K9A$T579�9A$T579A$32>&,2>1T4�(I1.D*3!K#KDHZ%(3&)2'#S#%$:Z%+)&)4C9?2>1�P��>2>&)i.13u'2'[email protected]!~4C9ADVP�1;!K9A$T57#;2>1;40j� 1>2>1T4B1;4B$'1.!K9X4�dF@`#%D7&)Za@;9A&,4Au�PA+)#;4C4C9040uIEF*'$3-�W[9X4Au�9A57P.j f 2>9A@;9A!¡4C9Ai.*3&OD?#�PHb3#%!�#;2'#�<$'1%5H#.-A/.1�PA#.!S90+O1%�HuT1.*�4<9<L<#'u>PA#;4<1�1�$'1.!K9B4<9<L<#�P�1;!K(:1T4M571�(I1.DJ2>*3#.46(3#.+)#a@[DH#.40u.#.46&O$3&GpP�&,#%&,4q2>[email protected]!¢904<57#.Dq9A!�!�#%&)_347P�*'+,#�dF$3/.1�2>[email protected]!�4<90Dq*347#.2>1T4qPA#.D7#;Pg579AD7904�2>9k4C*'8'+)&)$'b3#.2'1(3#.D7#S4<90(3#%DH#%DJ#.4J(:#%+,#a@TDH#.4Hfgu[9;j i:jl�'x;z[�'�X�rx:u[£:¤.|Tx;¥'�%¦'�'|Tx;yIu3jAjAj} 2'&)4C(:1T4M571K$'1K(3#%DHZ%i;D7#%EF1�#%$T579AD7&O1;D�$:/%1KR�#%('+)&,[email protected]+r$'1�PA#.4C1�2>9�P�1;$34<57#%$T579040u N *'92>[email protected]!§4C9ADli.DH#`Ee#;2'#.4 P�1;!¨5C1>2'#.4�#;4 +)9�57D7#;4o90!m!�#%&)_34CPA*'+,#.4l9�4C9A(:#%DH#.2'#;4�(I1.D�©)ª?«)u%P�1;!K1

¬3[%®3¯.°r±a¬ j� #.&)4�P�1;$34M5H#%$T5C9X4�2>[email protected]!�4C9AD�*:4C#;2'#.4?(:#%DH#�&O!K(I902>&)DS#�&O$3PA+O*:4C/.1�9A!�2>*'('+)&,P�&,2'#.2>92>9�*3!K#�P�+,#.474<9;u:PA1.!K1²@[&)4<5C1�$3#²�l&Oi;*'DH#²³>jk ¢('DC1;(:�T4<&O5C1²23#K�3i.*3D7#²PA&G5H#.2'#3u31;834<90DC@`#.D1K*34C1²2'#h´¶µ0·�2>9�#.8:90D<57*'D7#K2>1K¸Y¹k¸�u N *'9�2>[email protected]=('D7&O@[&)+O90i.&,#%D4C*3#SEF1.D7!�#�&)$T5C90DC!K902'&)Z.DC&,#d»º[¼%½[¾[½'fl90!�2'9�5CD7&)!S90$T5C1�23#.4J¿CÀ'Á%Âg´q´ÃµA·%¿Jd¶ºT¼ ÄTÄ[ÄÅ¼[ÆTf�9V1�*:4<1�2'9k*'!�P�1;!K9A$T57Z.DC&)1&,2>9A$T5C&O�:P0#%$32>11 N *39q904<57ZV4C9A$:2>1EF90PHb:#.2>1�dÇ2>9��3$3&)-0/%1k2'#kP�+,#.474<9;uAEF*'$:-A/%1.p»!K90!�8'D713uA5C904<5C9¤`£IÈ`x>|'w.x:u3jAj0j7f�j^

Figura A.1: Guidelinesde desenvolvimento para o E-duc@re 1/4

90

�� '{:¤`�¨w��3�%½Y�0¤X¦>z �� ¤0¦>z��w��3�.½ zT¾'x �'�[|%v3x3w �3ÄTÄ[Äg��£;v[¦ �̀ zr¤%{.¦"w��3�.½Y��T��r��

�.z`�3½��T��T��.z%�3½��

�� w��3�.½Y�0�

�l&Oi;*'DH#�^;\� �U>9A!K('+)1K23#S2'1[PA*'!K9A$T57#;-A/.1K2'9B*3!K#SEF*3$3-A/.1º[¼%½[¾T½ ¤`£Q�"!M�>x;£I¤X¦3xT��#�$�%'&)(�( ¯3± ��$*#%�[�+��>xT£:¤X¦3x��#,$�%'&�(�( ¯3± �)$-#-�/.;�0�

�;|T�'w[w �'$'|T�'w[w1�� 3Ä[Ä[ÄH�

� � �� ;|T�3wTw��'� ¤a£2!M�[xT£I¤X¦3x;�¼[Æ

�l&)i.*'DH#K³>\43�9��3$'&,-A/.1�2>9?*'!�#KP�+,#.474<95 6-7h��l��6�� &,2>90$;5H#.-0/%1k2>1BP��>2>&)i.1B2>9A@;9Y4<90DoEF90&G5H#V*347#%$:2>1k9AU[(:#%$347/%1V2>9657#.8'*'+,#.-0/%1V(3#.D7#V904C(3#.-A1;40uP�1;!98�9X4<(:#.-�1T4=2>9�5H#%!�#%$3b'13j: Y4C4C9SRS1h@`#%+)1.D=(3#;2>D7/.1�(3#.D7#�#%+)i.*'$:4�9X2>&O5C1.D79040u�P�1;!K11� V$%LM*>57#�(I1.D�9�U>9A!K('+)13j<;M4M571�4<&)i.$'&O�:P0# N *39�1�*34<1�2'9�57#.8'*'+,#.-A/.1�$3/%1�R�(I9AD7!K&G57&)2>12>90@T&,2>1>==(I1;474<&)8'&)+O&,2'#.2'9V2>9V#%+)i.*'!¢*34<*:Z%D7&O1=!K&)4<5C*3D7#.D�57#%83*'+)#;-A/.1=PA1.! 904C(3#.-A1;4JdF9X2>&G5H#%D1�PA�[2'&Oi;1�9A! *'! ('D71.i;D7#.!�# N *39�P�1;$[@.9ADC57#S5H#%8'*3+)#;-A/%1�(3#%DH#K904C(3#.-A1;40u:(I1.D�9�U>9A!K('+)1Tf9B5C1;DC$3#.$32>1K1�P��>2>&)i.1S&O+)9Ai;nO@;9A+»j;Ã$34<5CD7*3-�W[904 N *'9?*'5C&)+O&)�A90! PHb3#a@;904�(3#.D7#K2>90+O&)!K&G5H#%D8'+)1>P�1;4�d?�[¾�¤%|Tx:ur¤`£:u'£;v[¦-�̀ zI¤%{.¦�u

�;|T�'w[w>u;w��¤az �a¾ru09�5HP%j f�2>[email protected]!"579AD�4<*3#�#%8I9ADC5C*'DH#$3#k!K904C!K#k+O&)$'b3#�2'#V&)$34<5CD7*3-A/.13u`P�1;!K1!K1;4<5CDH#.2>1J$3#�l&)i.*'DH#A@'j V('D71`@.90&G5H#%$32>1#J!K904C!�#��3i.*3D7#3uAD790474C#.+G5H#`pÃ4<9�1*34C1V2>9q9X4<(3#;-�1T44C9A(3#.D7#.$32>1�1;(:90D7#;2>1.D7904�9=1.(I9ADH#%$:2>1;4�9A!Q9�U>('D790474<W[9X468I1[1.+)90#.$3#.4�1.*�#%D7&O5C!KR�57&)P0#.40jB C¢�D7h�FE�G6��6��H7h�I6I�� J��J̀ �KG�� &)$;579ADCEe#.PA9�PA1.! 1 *34<*:Z%D7&O1:uY1.8[@[&,#%!K9A$T5C9hEF90&G5H# #`5CDH#[email protected]>9�(3Z%i;&O$:#.4K¹ �ALNM 2>9A@;94C9Ai.*3&ODJD7&Oi;&)2'#.!K9A$T5C9=1�2>&,4<(I1;4<5C1K$'9X4M5H#�9X4<(I90PA&G�IPA#.-0/%1:uT@[&,4C#.$32>1Ki;#.D7#.$T5C&)D0\

] (I1.DC57#.8'&)+O&,2'#.2'9.c

³


91

º[¼%½T¾[½�� ¤`£ � ��T� � Æ � ��r� � �� x"�a¾3{ � #,& � �I�3¤%{%y �� v'x �� #*�� y'x;zTv>y;¦ � z[y;v'x�� x>|>w.x � �� x"�a¾3{ � #,& � �Ix%¦3{%y �� v'x �� #*�� y'x;zTv>y;¦ � £>�[|>w.x��

�� 3¤ � � �� . � �

�� >{ � �� 3¤ � � � �3¤�� 3È[È �� [¾r¤.|Tx � ��3¤ � º � ��'�0�¼[Æ

� &)i.*3D7# @'\� �U>90!S(3+O1²2>9>;M2'9A$T57#;-A/%1S9��k4C1�2>9� 6b3#[email protected]

] &)$T5C90DC$3#;P�&)1.$3#.+O&)�0#;-A/.13c] #;P�9X4C4C&O83&O+)&)23#.2>9;c] EF1;DC!�#%57#.-0/%1KP�1;$>�3i.*3D7Za@;9A+»j} 4�2'1.&,4V('D7&O!K90&OD71;4k&G579A$34�(:1>2>90!�4<90DkEe#;P�&)+O!K9A$T579�#%+,PA#.$3-A#;2>1;4V9A@[&G5H#%$32'1²1�*34C1�2>9¸Y¹ �ALNM�� de�l&Oi;*'DH#�8Tfgu�('D7&)@T&)+)9Ai.&,#%$:2>1�*'!�P��>2>&)i.1�¸Y¹k¸§('*'D71 de�l&)i.*'DH#��.f�u�1.* 4<9<L<#'u5C*:2>1V1 N *'9�EF1;Doi.90D7#;2>1J$3#(3Z.i.&)$3#2>[email protected](3DC1`@;9A$'&)9A$T5C9�2>9Y*'!�#JEF*'$3-0/%1k2>9Y&O!K('D790474C/.12'#S+)&O$'i;*3#%i;9A!�u'P�1;!K1�½>yr¤X¦[zru'x"�a¾'{:u[9�5HP%j� Y4747#SPA1>2>&G�IPA#.-0/%1�Ee#.PA&O+)&G5H#�#S&O$T5C90DC$:#.P�&)1.$:#%+Op&)�0#.-0/%1=#`57D7#a@;R04l2>1?*34C1=2'1��T�� >x;z[z'x��Tzrua#%+)i.1 N *'9V4<90DC&,#�9�U[5CD79A!�#%!K90$;579P�1.!K('+)&,PA#.2'1*347#%$32'1�*'!�#�P�1>2>&O�:P0#.-A/.1�¸Y¹ �ALNM j� &)$T5C9AD7$3#;P�&)1.$3#.+O&)�0#;-A/%1�*347#%$:2>1��T�� 'x;z[z>x��[z$3/.1�R=#%8I1.DH2'#.2'#�$'904<57#;4�·�� "!#��¿6(I1.&,4Y5CDH#`57#%p¶4C9�#.(:90$3#.4�2>9B*'!�#�PHb:#%!�#.2'#�2>9�*3!K#EF*'$3-0/%1 N *'9=DC9XP�908:9?*'!�#�¿g´ÇÂ$�"![·=P�1;!S1K(3#.D7�.!K9�5CD71&%('�)�*�+-,/.�,10�2323+54»j¸�1.D�#.PA90474<&)8'&)+O&,2'#;2>9K9A$T5C90$32>9�pÃ4C9K#�Ee#;P�&)+O&,2'#.2'9�de1.*�1�!K9A$'1;D?$'nO@;9A+q2>9²2'&G�:PA*'+,2'#.2>91%EF90DC9XP�&,2>1Tf�(3#%DH# # @[&)4C*3#%+)&)�0#.-0/%1 2'9�(3Z.i.&)$3#.4�9A!�$:#[email protected]#.2>1;DC9X4?9A!�!K1>2>1 5C9�U[571�1;*2>9X4M57&O$3#;2>1;4�#�(I1.DC57#;2>1.D7904k2>9�$390P�9X4C4C&,2'#.2>9X4V9X4<(I90PA&)#.&)4SdF$3#a@;9AiT#.2>1;DC9X4VP�1;! 4Cn)$;57904C9�2>[email protected];�.uYPA1.$[@.90D74C1.D7904�(3#%DH#76AÂCµ/�"�"�8��uJ9�5HP%j fgj } !K9A$'1;DKi.DH#%* 2>9�2>&O�:PA*'+)23#.2>9�Rh1%EF9AD790PA&)2'1*347#%$32'1�#�!�#%DHPA#;-A/%1�¹ �ALNM PA1.D7DC9A57#%!K90$;579�dF(I1.DS9�U>9A!K('+)13ul5CnO5C*3+O1T4Sº.¥ .aÆ3u�jAj0jHº.¥:9[Æ$3/.1�2>9A@;9A!�4C9AD�*34C#;2>1;4Y(3#%DH#?9AEF9A&O5C1;4�@[&,4<*3#.&)4Y9A!�EF1;$;579040u;!�#;4Y(3#.D7#�&O$34C9AD7&)D6*'!�#�$'1`@`#4C90-A/.1�;%4<*'8:4<9X-A/%1J$'1=2>1>P�*3!S90$T5C1Tf�j3�9A@;9�pÃ4<96*347#%D�#%(I9A$3#;4o1T4 90+O90!K9A$T5C1T4o9X4M57DC*>57*'DH#%&,4 2>9!�#%DHPA#;-A/%1B$3#�PADC&,#.-0/%1?2'#;4q(3Z.i.&)$3#.40u.90@T&O57#.$32>1?90+O90!S90$T5C1;4kdM´ÃµA·%¿Mfq9�#%5CD7&O8'*'5C1;4Y2>9A('D790PA&Gp#.2'1;40uTPA1.!K1�£>{.¦[zru��[� �.{>|T{.yru)�.{>|T{;yIu[�>|'¤a�T¦�u.9A57P%j�3�9A@;9�pÃ4<9V*:4C#.D0uT('D79�EF9AD79A$:P�&,#%+)!S90$T5C9.u1=<?>A@CBEDGFIHKJMLONP,0RQSN?TU>AT u�2'&)4C(:1;$'n)@.9A+�90!�d�VW'�XY'�,/Z�[�Q�0R.]\�.7^_2P`a'�Q�0cbdQ�.-e�f:+

gih#j5kGl�m#n3j5kGl�mporq$storuPv3wyx$qzh#j�h1vwy{�|~}�wy��yv3q��q��yq$�x$q�v��/��x$wy�/�3�/�rs7��q$��|Rq${�wy{~q$� ��v3q${��

@


92

º%¾>z`��|[Æº��3{;��3Æ�'{a�Ix hº[¼ x"�a¾3{��%¦3�X�rx��¼[Æ[º �>y3Æ� ¦'�[x;y'x��.{4�º[¼ x"�a¾3{��T�;�[�Ty'x3wTw ��¼[Æ[º �>y3Æº � �'{T��3Æº � ¾[z%��|[Æ

� &)i.*3D7# 83\a 61>2>&O�:PA#;-A/.1�83#;4<9X#.2'#�9A!Q¸Y¹ �AL Mx"�a¾'{ #aº%¾>z%��|TÆ��%¦0#*�x"�a¾'{ #aº��3{T��'Æ��%¦0#*�x"�a¾'{ # �>{a�rx �%¦'�a�rx>º��[y3Æ��%¦0#-�x"�a¾'{ # � ¦'�>x;y'x��.{ �;�T�[�Ty'x'w[w;º��>y'Æ��%¦0#*�x"�a¾'{ # º � �3{T��'Æ��%¦0#*�x"�a¾'{ # º � ¾>z%��|TÆ��%¦0#*�

�l&Oi;*'DH# �'\ 61[2'&G�:P0#.-0/%1S*34C#.$32>1K¸Y¹k¸ ('*'D71\�+ <?>p@CB��2� ��2PNP0�N��0c,%fgj L #.&O1;DC9X46&)$>EF1;DC!�#.-AW[904J4<1;8'D79B#;P�90474C&O8'&)+)&)2'#;2>9B9=5CR0PA$'&,PA#.4(3#.D7#S#%*'!K90$;5HZ`p¶+)#�904<57/.1K9A! dRVW'�XY'�,/Z�[�Q�0�. \�+��W4 f�j V&)$32'#�$31 N *3904C&G571 #.PA90474<&)8'&)+O&,2'#.2'9.uo!�#;4?&O$:P�+)*'&O$:2>1�#%&)$32'#�#hEF1;DC!�#%57#.-0/%1�P�1;$>�3i%p*'[email protected]+Çu90$3P�1;$;57D7#%p¶4C9�1 *34<1 2>9M ��'³sd�Q�+#)�+GQ�.�, ,/'�XY'�,Z�[�Q�0R.K4 f (3#%DH#�EF1.D7!�#`5H#.-A/.12>9K5H#%!�#%$'b313uoPA1.D7904=9K5C&)(I1;4�2>9KEF1;$T5C9040u �Oµ��.Á/�>´Bd 57#.8:90+)#;4�2>[email protected]! 4<90D?*34C#;2'#.4?#.(:90$3#.4(3#.D7#�2>&)4C(I1.$'&)8'&)+O&)�0#.D�23#.2>1T4oD790#.+O!K9A$T579Y5H#%8'*'+,#%D79040ua$3/%1B(3#.D7#VEF1.D7!K#%57#.Dl#B#%(3#.DCt0$3P�&,#V2'#(3Z.i.&)$3#'u%9AU'P�9�571 N *3#%$32'1�4<*3#�+O&)$'90#.DC&)�0#;-A/.1k�3�09ADY4C9A$T57&)2>1 �"! ;¶p#!�@� Jf�u.9�5HP%j� �U>&,4M579A!EF1.+)b3#;4�2>9²9X4M57&O+)1�('D7R�pÃ2>9��:$'&)23#.4?9 N *'9�(:1>2>90!�4C9AD�9AU[5C9A$:2>&)23#.4�90!�P0#.4C1�2>9²$'9XP�9X4C4C&Gp2'#;2>9.j�¸�#%DH#=EF1.D7!�#`5H#.-A/.13uT2>9A@;9A!�4<90D6*:4C#;2>1;46('D79�EF9AD79A$:P�&,#%+)!S90$T5C9k1T4Y90+O90!K9A$T5C1T4 °r±%$ 9('&�&T�S*>57&O+)&O�X#%$32'1�1S#`5CD7&)8'*>5C1<�;|T�'w[w=DC9AEF9AD79A$3PA&)#.$32>1�*3!K#SP�+,#.474C9k('D7904C9A$T5C9�$3#?EF1;+Ob:#�2>9904<5C&)+)1;40j

8


93

English | Deutsch | Español UserID: Login

Passwd: new user

Free Reports | Paid Reports | Order Survey Archive | FAQ | Glossary

Market Share Change (Total servers: 15,389,236)

1Servers are ordered according to their global market share.

Free Research Reportsweb srvrs by domain

market share server details

ssl srvrs by domain market share server details certs & CAs protocols & ciphers

apache modules tech penetration web authoring tools theft & upgrades cookie usage isp market share dns load balancing web bugs firewalled IIS web failure/growth p3p compact policy telephone area code DNS site operator

Web Server Survey August 1st, 2005

For analysis of other domains:Please Select

Across All Domains

Server 1 July Count

July %

June Count

June % Change

Apache 11,095,845 72.10% 10,938,890 71.94% +0.16%

Microsoft 3,425,678 22.26% 3,402,407 22.38% -0.12%

Zeus 121,930 0.79% 124,574 0.82% -0.03%

Netscape 95,598 0.62% 86,221 0.57% +0.05%

WebSTAR 52,069 0.34% 45,145 0.30% +0.04%

WebSite 15,937 0.10% 16,453 0.11% -0.01%

Other 582,179 3.78% 592,115 3.89% -0.11%

Web Server Survey - SecuritySpace

1 of 2http://www.securityspace.com/s_survey/data/200507/index.html

Figura A.5: Utilização do Apache como servidorweb1/4

94

English | Deutsch | Español UserID: Login

Passwd: new user

Free Reports | Paid Reports | Order Survey Archive | FAQ | Glossary

Apache Module Report August 1st, 2005

The Apache Module report is a breakdown of the popular add-on modules to the Apache web servers. All percentages shown are based on web servers running Apache in this month's survey.

Click any module to see detailed graphs and histories.

Module July 2005 Count

July 2005 %

June 2005 Count

June 2005 %

Growth %

PHP 5,087,300 45.85 5,082,557 46.46 -1.32

mod_ssl 3,419,639 30.82 3,384,074 30.94 -0.38

OpenSSL 3,418,592 30.81 3,383,005 30.93 -0.38

FrontPage 2,431,093 21.91 2,427,878 22.19 -1.28

perl 1,342,647 12.10 1,335,652 12.21 -0.90

mod_log_bytes 892,176 8.04 878,641 8.03 0.10

mod_bwlimited 834,740 7.52 824,012 7.53 -0.13

DAV 493,266 4.45 497,083 4.54 -2.17

mod_throttle 380,458 3.43 385,151 3.52 -2.62

mod_jk 374,667 3.38 379,033 3.47 -2.55

mod_fastcgi 290,290 2.62 287,533 2.63 -0.47

mod_python 195,077 1.76 191,951 1.75 0.19

mod_auth_pam 164,618 1.48 172,891 1.58 -6.13

ApacheJServ 113,771 1.03 119,693 1.09 -6.29

AuthMySQL 113,224 1.02 112,886 1.03 -1.12

rus 109,122 0.98 111,177 1.02 -3.24

mod_layout 82,315 0.74 81,031 0.74 0.15

Rewrit 77,099 0.69 77,670 0.71 -2.14

Ben-SSL 65,165 0.59 67,841 0.62 -5.30

Resin 36,254 0.33 36,147 0.33 -1.12

mod_watch 32,586 0.29 30,836 0.28 4.18

mod_fs 19,730 0.18 12,388 0.11 57.01

mod_become 17,908 0.16 17,607 0.16 0.27

SVN 13,545 0.12 12,808 0.12 4.26

Embperl 5,949 0.05 6,305 0.06 -6.98

mod_macro 5,595 0.05 5,639 0.05 -2.18

Tomcat 5,035 0.05 5,578 0.05 -11.01

mod_backhand 4,940 0.04 4,825 0.04 0.94

Apache Survey: Apache Module Report

1 of 2http://www.securityspace.com/s_survey/data/man.200507/apachemods.html


96

Note: Readers are cautioned that the Growth percentages are based on a module's market share penetration rather than the absolute number of modules we detected. Thus, it is possible for the number of modules to increase, while the growth is actually a negative value.

Looking for a specific module? Check the module registry at http://modules.apache.org/

Note: OpenSSL, BSafe, and SSLeay aren't true modules in their own right; rather they are required for a number of SSL enabling modules, and will often have their signature string imbedded into the server string, thus allowing us to determine which of them is being used. Rather than separate this out into a separate report, we've included them here. Copyright© 1998-2005 E-Soft Inc. Excerpts of this report may be reproduced providing that E-Soft and the URL http://www.securityspace.com/ are attributed.

Home | About Us | Contact Us | Partner Programs | Privacy | Mailing Lists | Abuse Security Audits | Managed DNS | Network Monitoring | Site Analyzer | Internet Research Reports

Web Probe | Whois

© 1998-2005 E-Soft Inc. All rights reserved.

CSacek 4,144 0.04 4,253 0.04 -3.94

mod_virtual 4,050 0.04 3,375 0.03 18.30

Raven 2,582 0.02 2,697 0.02 -5.62

Midgard 2,429 0.02 2,588 0.02 -7.47

AxKit 1,996 0.02 2,338 0.02 -15.84

mod_front 1,912 0.02 1,949 0.02 -3.29

iae_chroot 1,327 0.01 1,311 0.01 -0.21

mod_czech 1,258 0.01 1,253 0.01 -1.02

mod_oas 812 0.01 842 0.01 -4.93

SSLeay 811 0.01 808 0.01 -1.05

AuthPostgreSQL 804 0.01 796 0.01 -0.42

ihtml 613 0.01 617 0.01 -2.05

WebTen 300 0.00 333 0.00 -11.18

gd 114 0.00 115 0.00 -2.27

PyApache 66 0.00 65 0.00 0.10

mod_script 1 0.00 1 0.00 -1.41

NIRL 1 0.00 0 0.00 N/A

Apache Survey: Apache Module Report

2 of 2http://www.securityspace.com/s_survey/data/man.200507/apachemods.html


97

search for in the

Usage Stats for August 2005

PHP: 22,267,442 Domains, 1,291,738 IP Addresses Source: Netcraft

You can also see how popular PHP is relative to other Apache modules at SecuritySpace's Web Survey. Spoiler: PHP is the most popular. There is also a Programming Community Index provided by TIOBE.

show source | credits | sitemap | contact | advertising | mirror sites

function list

downloads | documentation | faq | getting help | mailing lists | reporting bugs | php.net sites | links | my php.net

This mirror generously provided by: Web Hosting Talk Last updated: Mon Aug 8 19:23:17 2005 EDT

Copyright © 2001-2005 The PHP Group All rights reserved.

PHP: PHP Usage Stats

1 of 1http://www.php.net/usage.php

Figura

A.9:

Utilização

doP

HP

como

linguagemde

scriptparapáginas

web

98

ferramentas de auxílio a ead: módulo de controle de eventos para o e-duc@re

Documents