TCC

FACULDADE CARLOS DRUMMOND DE ANDRADE
ABRAÃO ALMEIDA
ALESSANDRO BISPO DOS SANTOS
FELIPE SZMYHIEL
MAYCON DOS SANTOS NUNES
PAULO EDUARDO DEININGER MESSIAS ALVES
SILVIO RODRIGUES JESUS JUNIOR
DESENVOLVIMENTO DE UMA FERRAMENTA ACADÊMICA PARA

ADMINISTRAR EXERCÍCIOS E AVALIAÇÕES, QUE APÓIA O CORPO
DOCENTE E DISCENTE.
São Paulo
2009
ABRAÃO ALMEIDA
FELIPE SZMYHIEL

DOCENTE E DISCENTE.
Trabalho de Conclusão de Curso apre-

sentado à Faculdade Carlos Drummond
de Andrade como parte dos requisitos
para a obtenção de grau de Bacharel em
Ciência da Computação, sob orientação
da Profa . Lúcia Contente Mós.
São Paulo
2009
ABRAÃO ALMEIDA
FELIPE SZMYHIEL

DOCENTE E DISCENTE.
Trabalho de Conclusão de Curso apresentado à Faculdade Carlos Drummond de Andrade,

aprovada pela Banca Examinadora constituı́da pelos seguintes professores:
Profa . Lúcia Contente Mós

Faculdade Carlos Drummond de Andrade
Orientadora
Prof. Dr.
Prof. Dr.
São Paulo, junho de 2009.

Este trabalho está licenciado sob uma Licença Creative Commons Atribuição-Uso
Não Comercial e Vedada a Criação de Obras Derivadas 2.5. Para ver essa licença, visite
http://creativecommons.org/licenses/by-nc-nd/2.5/br/
Agradecimentos
Ao Sr. André Medeiros que contribuiu com livros e explicações sobre ferramentas
web. Ao prof. Dr. Marcelo Facio Palin por todo seu empenho e dedicação durante o
desenvolvimento do trabalho.
”Disse-lhe Deus: Pede-me o que queres que
eu te darei. Respondeu Salomão: Dá, pois,
ao teu servo, coração compreensivo, com
sabedoria e justiça, para discenir entre o bem
e o mal.”
Bı́blia (Reis Cap. 3, Versı́culos 3 ao 13)
Dedico este trabalho a Deus, pela saúde, fé
e perseverança que tem nos dado. As nossas
companheiras, nossas fiéis companheiras na
hora da tribulação. A nossos pais, a quem
honramos pelo esforço com o qual nos man-
tiveram no caminho do bem. A nossos ami-
gos pelo incentivo a busca de novos conhec-
imentos, a todos os professores e professo-
ras que muito contribuı́ram para a nossa for-
mação, dos quais temos boas lembranças e à
professora mestra, Sra. Lúcia Contente Mós,
pela sabedoria e dedicação com a qual super-
visionou o estágio, levando em consideração
os problemas que fazem parte do contexto de
seus alunos, sendo sensı́vel às diversas situ-
ações apresentadas.
Resumo
Este trabalho apresenta um software gerador de questões, a fim de auxiliar professores
na elaboração de avaliações e métodos avaliativos de desempenho geral ou individual
de alunos. Foram adaptados recursos em conjunto a plataforma de Ensino a Distância,
Moodle. A agregação, essencial, dos padrões SCORM, para auxilio educacional na Web.
Com essa metodologia foi possı́vel gerar as questões para integrarem-se é plataforma
Moodle.
No desenvolvimento do software é utilizado um framework genérico de um processo de
desenvolvimento, RUP.
Palavras-chave: Moodle, SCORM, RUP, desenvolvimento.
Abstract
This paper presents a generator of software issues, to assist teachers in developing
methods of assessment and evaluation of overall performance or individual students. Were
adapted to all resources in distance learning platform, Moodle. Aggregation is essential,
the SCORM standard to support educational web. With this methodology could lead to
integrate the issues to the Moodle platform.
In developing the software used is a generic framework of a development process, RUP.
Keywords: Moodle, SCORM, RUP, development.
Sumário
1 Introdução 15
1.1 Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.2 Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.3 Justificativas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.4 Estrutura do trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2 Educação a distância 18
2.1 Tipos de Educação a distância . . . . . . . . . . . . . . . . . . . . . . . . . 18
3 E-Learning 19
3.1 Vantagens e desvantagens do E-Learning . . . . . . . . . . . . . . . . . . . 19
3.2 E-Learning Sı́ncrono X Assı́ncrono . . . . . . . . . . . . . . . . . . . . . . 20
4 Learning Management Systems (LMS) 21
5 Sharable Content Object Reference Model (SCORM) 23
6 Modular Object-Oriented Dynamic Learning Environment 24

6.1 Caracterı́sticas do Moodle . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
6.1.1 Linhas gerais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
6.2 Recursos Adicionados ao Moodle . . . . . . . . . . . . . . . . . . . . . . . 24
6.2.1 DragMath . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
6.2.2 JsMath . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
7 Gerenciamento de Projetos 26
8 Engenharia de Software 28
8.1 Modelagem de Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
8.2 Programação Orientada a Objetos . . . . . . . . . . . . . . . . . . . . . . . 29
8.3 Unified Modeling Language (UML) . . . . . . . . . . . . . . . . . . . . . . 29
8.4 Diagramas da UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
8.4.1 Diagrama de Casos de Uso (Use Cases Diagram) . . . . . . . . . . . 30
8.4.2 Diagrama de Classes (Class Diagram) . . . . . . . . . . . . . . . . . 30
8.4.3 Diagramas de Interação (Interaction Diagrams) . . . . . . . . . . . 30
8.4.4 Diagrama de Estados (State Diagram) . . . . . . . . . . . . . . . . 30
8.4.5 Diagrama de Atividades (Activity Diagram) . . . . . . . . . . . . . 30
8.4.6 Diagrama de Implementação (Deployment Diagram) . . . . . . . . 30
8.4.7 Diagrama de Pacotes (Package Diagram) . . . . . . . . . . . . . . . 31
9 Rational Unified Process (RUP) 32

9.1 Dimensão Dinâmica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
9.1.1 Iniciação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
9.1.2 Elaboração . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
9.1.3 Construção . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
9.1.4 Transição . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
9.2 Dimensão Estática . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
9.2.1 Fluxo de Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
9.2.2 Papéis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
9.2.3 Atividades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
9.2.4 Artefatos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
9.2.5 Disciplinas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
10 Ferramentas e tecnologias utilizadas 39

10.1 NetBeans uma Ferramenta Open Source . . . . . . . . . . . . . . . . . . . 39
10.2 W3C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
10.3 XHTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
10.4 CSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
10.5 JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
10.6 JQuery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
10.7 Ajax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
10.8 Apache Tomcat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
10.8.1 História . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
10.9 JSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
10.10MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
10.11XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
10.12LaTeX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Referências Bibliográficas 46
11
Lista de Figuras
1 Gerenciamento de projetos no RUP . . . . . . . . . . . . . . . . . . . . . . 26
2 Exemplo de processo em Engenharia de Software . . . . . . . . . . . . . . 28
3 Arquitetura geral do RUP . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4 Fluxo de trabalho do RUP . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5 Iteração do RUP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
6 Representação de papel do RUP . . . . . . . . . . . . . . . . . . . . . . . . 37
12
Lista de Tabelas
13
Lista de Abreviaturas e Siglas
ANS (Padrão Nacional Americano)
ANSI (Instituto de Padrões Nacional Americano)
CSS Cascading Style Sheet
HTML Hypertext MarKup Language
LMS Learning Menager System
Moodle Modular Object-Oriented Dynamic Learning Environment
PMBoK Project Management Body of Knowledge
PMI Project Management Institute
RUP Rational Unified Process
SCORM Sharable Content Object Reference Model
UML Unified Modeling Language
VWP Visual Web Pack
W3C Word Wide Web Consortium
XML Extensible Markup Language
14
1 Introdução
A finalidade deste capı́tulo é apresentar uma introdução sobre o trabalho desenvolvido, um
sistema de gerenciamento de questões que permite à professores compartilharem questões
entre outros professores e alunos e maior interatividade com ferramentas atuais de ensino
a distância, o Moodle. Para os alunos, trazer também o recurso da mobilidade com o
uso de um sistema que pode ser utilizado em dispositivos móveis, como celulares, e que
permite a realização de simulados das questões compartilhadas a fim de contribuir com
as técnicas utilizadas para ensino a distância.
Este capı́tulo é organizado da seguinte forma: nas motivações são apresentados os
problemas que motivaram o desenvolvimento; o objetivo descreve o propósito deste tra-
balho; nas justificativas são identificadas as razões para a elaboração, apresentando os
principais resultados esperados e suas contribuições; e a estrutura do trabalho apresenta
os capı́tulos do trabalho comentados.
1.1 Motivação
As provas são um meio de avaliação de alunos, independente de seu nı́vel de escolaridade,
para realização de concursos públicos e vestibulares. A preparação de uma prova pode
demandar muito tempo pois coletar, corrigir e revisar questões é um trabalho cansativo e
maçante(DOUGIAMAS, ). Caso o avaliador resolva utilizar certos critérios, tais como:
• Questões de tipos diferentes;

Questionário;
Dissertativas;
Múltipla escolha;
Associativa.
• Questões diferentes para cada uma;
• Utilização de imagens;
• Questões em ordens diferentes;
• Questões diferentes para diferentes provas, entre outros.
Há também a questão do aluno, que precisa se preparar para exames. As atividades
são, um dos principais recursos que ajudam a fixar os conceitos aprendidos em sala de
aula. Garimpar questões em livros, apostilas e sites demandaria um tempo que poderia ser
gasto fazendo exercı́cios. Além disso, nos tempos de hoje, onde a questão da mobilidade
se torna tão importante para nossa integração com a tecnologia, os alunos precisam de
ferramentas que possibilitem estudar também onde quer que estejam, como na condução
enquanto vão para o trabalho por exemplo.
1.2 Objetivo
O desenvolvimento de um sistema que além de gerenciar uma base de dados de questões,
gerasse simulados e gabaritos, resolveria principalmente a questão do tempo gasto pelos
professores e alunos. Com a possibilidade de compartilhar informação entre os usuários,
1 INTRODUÇÃO 16
questões de vários lugares poderiam ser incorporadas a base de dados atual, enriquecendo-
a.
Auxiliar o ensino a distância trazendo recursos de mobilidade aos alunos para estu-
darem e maior interatividade entre os professores e alunos, facilitando o uso de tecnologias
como o Moodle.
1.3 Justificativas
Com o avanço tecnológico e uso de novas práticas de ensino, como o ensino a distância,
torna-se necessário o desenvolvimento de melhores ferramentas que auxiliem a integração
entre os diversos ambientes existentes hoje. O Moodle, importante ferramenta de ensino a
distância, com o auxı́lio deste sistema, será capaz de gerenciar melhor seus questionários,
importar e exportar questões entre si, compartilhar questões entre professores e alunos,
afim de melhorar todo o processo de aprendizagem.
Ferramentas de ensino a distância proporcionam ao aluno a capacidade de administrar
seu horário. O desenvolvimento de um sistema para dispositivos móveis contribuirá com
os alunos para que possam estudar por meio de simulados em qualquer local.
Atualmente, há poucos sistemas de geração de provas e exames que sejam populares
entre alunos e professores e que sejam fáceis de utilizar.
1.4 Estrutura do trabalho

1 Introdução
Determina o objetivo deste trabalho, assim como as motivações e as justificativas
para a sua elaboração. Por fim, apresenta a estrutura comentada do trabalho.
2 Educação a distância
Introdução sobre o processo de educação a distância e definição com base na legis-
lação brasileira.
3 E-Learning
Principais conceitos sobre e-learning.
4 Learning Management Systems (LMS)
Definição de LMS e suas caracterı́sticas.
5 Sharable Content Object Reference Model (SCORM)
Conceito SCORM utilizado como base no desenvolvimento deste projeto.
6 Modular Object-Oriented Dynamic Learning Environment
Apresentação da plataforma Moodle e recursos (plugins) utilizados.
7 Gerenciamento de Projetos
O Gerenciamento de Projeto de Software, conceitos de modelagem de software,
orientação à objetos e diagramas UML.
8 Engenharia de Software
O que é Engenharia do Software, sua origem e princı́pio com base na metologia
RUP.
1 INTRODUÇÃO 17
9 Rational Unified Process (RUP)

Este capı́tulo apresenta um resumo dos principais conceitos do RUP relacionados
ao gerenciamento de projetos e utilizados no desenvolvimento deste projeto.
10 Ferramentas e tecnologias utilizadas

Dedicado à apresentar as ferramentas e tecnologias utilizadas no desenvolvimento
deste projeto.
Referências
Esta seção apresenta uma lista de fontes de pesquisas utilizadas como referências
para este trabalho.
2 EDUCAÇÃO A DISTÂNCIA 18
2 Educação a distância
A legislação brasileira educacional define educação a distância como:
Uma forma de ensino que possibilita a auto-aprendizagem com a mediação de re-
cursos didáticos sistematicamente organizados, apresentados em diferentes suportes de
informação, utilizados isoladamente ou combinados e veiculado pelos diversos meios de
comunicação.(BRASIL,2005).
Para (MORAN, 2002) a Educação a distância é o processo de ensino-aprendizagem,
mediado por tecnologias, onde professores e alunos estão separados espacial e/ou tem-
poralmente. (MORAN, 2002) diz que é ensino/aprendizagem onde professores e alunos
não estão fisicamente juntos, mas podem estar conectados, interligados por algum meio
tecnológico, como a Internet.
2.1 Tipos de Educação a distância

(MORAN, 2002) descreve os tipos de educação à distância, como educação presencial,
semipresencial (parte presencial/parte virtual ou à distância) e educação a distância(ou
virtual). A educação presencial é a dos cursos regulares, em qualquer nı́vel, onde profes-
sores e alunos se encontram sempre num local fı́sico, chamado sala de aula. É o ensino
convencional. A semipresencial acontece em parte na sala de aula e outra parte a distân-
cia, através de tecnologias. A educação a distância pode ter ou não momentos presenciais,
mas acontece fundamentalmente com professores e alunos separados fisicamente no espaço
e ou no tempo, mas podendo estar juntos através de tecnologias de comunicação.
Para (PADALINO, 2006) a educação a distância pode construir uma solução aberta e
flexı́vel na capacitação profissional capaz de superar novas necessidades de aprendizagem
de forma individualizada, permitindo que se obtenham resultados mais eficientes e eficazes.
3 E-LEARNING 19
3 E-Learning
Para (RODRIGUES, 2003) E-learning é uma modalidade de ensino a distância que pos-
sibilita a auto-aprendizagem, com a mediação de recursos didáticos sistematicamente
organizados, apresentados em diferentes suportes tecnológicos de informação, utilizados
isoladamente ou combinados, e veiculado através da internet. Alguns termos, apesar de
apresentarem certa diferença conceitual, na prática são utilizados como sinônimos de E-
learning. São eles: web training, web education, educação à distância via internet, ensino
controlado por tecnologia, ensino dirigido por computador etc. Em uma segunda instân-
cia, visa-se permitir que as Empresas e Instituições ligadas à Formação e Ensino, passem
a oferecer um leque de soluções de Formação mais abrangente e completo, por forma a
enriquecer e melhorar o nı́vel de qualidade. Em uma terceira instância, deve-se permitir a
conciliação entre os métodos de Formação tradicionais (Formação presencial) e os métodos
de Formação a distância, criando-se uma fusão entre os dois métodos, atingindo-se como
resultado os sistemas de Formação mistos.
3.1 Vantagens e desvantagens do E-Learning

(RODRIGUES, 2003) diz que a implementação de uma solução de e-Learning permite obter
redução de custos associados com a formação, nomeadamente através de:
• Redução dos custos de deslocações e estadias: ao acederem à informação em qualquer

local, os formandos não estão limitados à sua área geográfica de atuação, da mesma
maneira que são reduzidos os custos com deslocações necessárias para os locais
de formação. A redução nas deslocações traduz-se também em um aumento de
produtividade associado à menor necessidade de se ausentar do local de trabalho;
• Redução dos custos associados à logı́stica de formação: os formandos poderão aceder
à informação sempre que dela necessitarem, não estando obrigados à presença su-
jeita a marcação de hora e local. Também a disponibilização da informação online
permite aos formando a consulta para esclarecimento de dúvidas ou para processos
de reciclagem;
• Acessibilidade, redução de tempo e rápida distribuição: A informação está disponı́vel
para todos os colaboradores (ou para os destinatários selecionados) em tempo real,
com uma redução do tempo de produção de alterações aos conteúdos o que permite
uma rápida distribuição da informação.
Ainda (RODRIGUES, 2003) descreve as desvantagens do sistema e-learning:
• Necessidade de maior esforço para motivação dos alunos.

• Exigência de maior disciplina e auto-organização por parte do aluno.
• A criação e a preparação do curso-line é, geralmente, mais demorada do que a
preparação de uma aula presencial.
• Não gera a possibilidade da existência de cumplicidade e vı́nculos relacionais, que
somente o processo de interação presencial permite.
• O custo de implementação da estrutura para o desenvolvimento para o programa
e-learning é alto.
3 E-LEARNING 20
• Dificuldades técnicas relativas a Internet e a velocidade de transmissão de imagens

e vı́deos.
• Limitações no desenvolvimento da socialização do aluno.
• Limitações em alcançar objetivos na área afetiva e de atitudes, pelo empobrecimento

da troca direta de experiência entre professor e aluno.
3.2 E-Learning Sı́ncrono X Assı́ncrono

(RODRIGUES, 2003) fala sobre os dois meios distintos de ensinar através do e-Learning:
Sı́ncrono e Assı́ncrono. Sı́ncrono é quando professor e aluno estão em aula ao mesmo
tempo. Exemplos de recursos sı́ncronos: Telefone, Chat, Vı́deo Conferência, Web confer-
ência. Através da Web conferência o professor ministrará a aula e os alunos, via WEB,
irão ouvir sua palestra e ver suas transparências. Podendo realizar perguntas e discussões.
Este modelo é o que mais se assemelha ao ensino presencial. Principalmente na estru-
tura de custos, desenvolvimento e atualização de conteúdo. Com a grande ampliação
dos recursos de comunicação por voz (VOIP) na WEB, exemplo o sistema Skype, e os
mensageiros como um todo. Este meios tem ganho muita importância. No e-Learning
Assı́ncrono, professor e alunos não estão em aula ao mesmo tempo. Exemplos de recursos
assı́ncronos: e-mail e fórum. No e-Learning corporativo, muitos projetos não tem profes-
sor, são o auto-treinamento na sua essência. O aluno inscreve-se quando quiser, participa
quando quiser e termina quando quiser. O que representa um curso com pouco custo
variável, ou seja, custo baixo para grande número de alunos. No e-learing assı́ncrono com
professor, este irá responder dúvidas, participar de discussões em momentos diferentes
do tempo. Exemplo: o aluno publica uma pergunta as 9h00 e o professor responde as
17h00. A grande diferença no assı́ncrono é que o tempo é ”elástico- o oposto de rı́gido, no
sı́ncrono – e cada aluno pode fazer o curso em seu tempo, hora, velocidade. Pode pensar,
estudar e pesquisar antes de escrever sua atividade. Cada aluno poderá ter seu tempo
de aprendizagem. Antes do advento da informática, o EaD era possı́vel somente de duas
formas: ”um para muitos”(tv,rádio) e ”um para um”(ensino por correspondência). Após a
chegada da internet mais uma possibilidade foi acrescentada, ”muitos para um”, por esse
motivo fica difı́cil falarmos em ensino à distância, sem a internet.
4 LEARNING MANAGEMENT SYSTEMS (LMS) 21
4 Learning Management Systems (LMS)

Para (ALMEIDA, 2003) são softwares desenvolvidos sobre uma metodologia pedagógica
para auxiliar a promoção de ensino e aprendizagem virtual ou semi-presencial. Conhecidos
como LMS, ou Sistema de Gerenciamento de Cursos.
(ALMEIDA, 2003) relata que com o avanço da educação à distância – os realizados pela
Internet - e as preocupações fortificadas como o novo modelo de EaD, como o papel do
aluno e do professor em ambiente virtual, outras questões passaram a ser discutidas para
a otimização deste modelo educacional. A geração de Comunidades Virtuais é um dos
princı́pios que orientam o crescimento inicial do ciberespaço, ao lado da Interconexão e
da Inteligência Coletiva . Isto justificaria a criação de Comunidades Virtuais como sendo
essencial para o estabelecimento de uma cultura de EaD. Porém, percebe-se que a simples
criação de comunidades virtuais não significa a criação de grupos de estudo pela Internet.
Isto porque surgem ambientes da Internet comunidades com os mais diversos interesses,
que vão deste o entretenimento até a distribuiçãode notı́cias.
Para atingir seus objetivos educacionais (ALMEIDA, 2003), diz que as Comunidades
Virtuais necessitam de princı́pios de comportamento que visem a aprendizagem, sendo isto
realizado dentro das ideias de construção coletiva e de interesse mútuo dos participantes.
Assim, as simples agregações eletrônicas de pessoas tornar-se-iam Comunidades Virtuais
de Aprendizagem.
Com a criação destas comunidades, surge na Internet diversos softwares de agregação
e pessoas. Dentre os muitos, alguns são voltados ao entretenimento, outro à distribuição
de notı́cias até que chegamos aos focado no sistema de ensino e aprendizagem pela In-
ternet. Estes softwares trazem consigo discussões pedagógicas para o desenvolvimento
de metodologias educacionais utilizando canais de interação web. Assim, softwares como
Moodle, dentre outros, ganham espaço no cotidiano aos educadores virtuais pelo fato de
possibilitarem fácil manuseio e controle de aulas, discussões, apresentações, enfim, ativi-
dades educacionais de forma virtual.
(ALMEIDA, 2003) descreve os chamados Ambientes Digitais de Aprendizagem, a EaD
ganhou a possibilidade de organizar de maneira mais controlada cursos, mescla de aulas
presenciais e a distância, possibilidade de aulas apenas virtuais, integração com novas
possibilidades de interação pela Internet, além da aproximação entre professores e alunos
dentro do processo educativo. O número de ferramentas disponı́veis para utilização tam-
bém cresce a cada dia. São emails, fóruns, conferências, bate-papos, arquivos de textos,
wikis, blogs, dentre outros. Ressaltase que, em todos estes ambientes, textos, imagens e
vı́deos podem circular de maneira a integrar mı́dias e potencializar o poder de educação
através da comunicação. Além disso, a possibilidade de hiperlinks traz o aumento do raio
de conhecimento possı́vel de ser desenvolvido pelos alunos. Estes hiperlinks podem ser
realizados tanto dentro do próprio ambiente digital de aprendizagem (entre textos indica-
dos ou entre discussões em fóruns diferentes, por exemplo), como também de dentro para
fora e de fora para dentro (em casos de pesquisas alargadas de discussões internas, nos
quais se pode trazer ou levar conteúdo desenvolvido para a discussão). Assim, pode-se
diferenciar inclusive as nomenclaturas que são dadas à educação promovido a distância.
De acordo com (ALMEIDA, 2003), as três nomenclaturas para o modelo a distância de
educação (Educação On-line, Educação a Distância e E-Learning) são conhecidos da área
de educação, porém se diferenciam entre si. Conforme (ALMEIDA, 2003), a divisão ocorre
da seguinte forma:
• Educação a distância: realiza-se por diferentes meios (correspondência postal ou

4 LEARNING MANAGEMENT SYSTEMS (LMS) 22
eletrônica, rádio, televisão, telefone, fax, computador, internet, dentre outros), sendo
um termo abrangente, mantém a relação de discussão de tempo e espaço (distanci-
amento fı́sico) dentro o processo educacional, porém não é obrigatoriamente dentro
do ambiente Internet;
• realizada obrigatoriamente com Internet em papel principal como meio, pode ser
utilizada de forma sı́ncrona ou assı́ncrona. Tem como caracterı́sticas mais enfáticas
a velocidade na troca de informações, o feedback entre alunos e professores e o grau
de interatividade alcançado.
• formato de educação a distância com suporte na internet. É muito utilizado por

empresas, em processos de treinamentos de funcionários e seleção de pessoal. Seu
foco consiste em organizar e disponibilizar materiais didáticos e, como afirma a
Professora Maria Elizabeth, recursos hipermediáticos.
Com isso, percebe-se que o modelo de Educação a Distância dentro do conceito de

Educação On-Line, se apresenta como o mais interativo, requerendo das ferramentas uti-
lizadas o uso visando o ideal de autonomia e construção coletiva do conhecimento.
5 SHARABLE CONTENT OBJECT REFERENCE MODEL (SCORM) 23
5 Sharable Content Object Reference Model (SCORM)

Para (DUTRA R. L.;TAROUCO, ) Sharable Content Object Reference Model (SCORM) é
um conjunto unificado de especificações para disponibilização de conteúdos e serviços de
e-learning. Definem um modelo de agregação de conteúdo, um ambiente de execução para
objetos de aprendizagem baseados.
Para (DUTRA R. L.;TAROUCO, ) a utilização do SCORM no desenvolvimento de con-
teúdo para Educação à Distância é seu foco na reusabilidade, acessibilidade, interoperabili-
dade e durabilidade. O SCORM tem como um de seus objetivos propiciar a independência
de plataforma na qual os objetos serão utilizados, assim como facilitar a migração de cur-
sos entre diferentes LMS que sejam compatı́veis com esse modelo. A migração de um
curso através de um processo de empacotamento conforme as especificações do SCORM
demanda um esforço reduzido. O conteúdo desenvolvido com o padrão SCORM é inde-
pendente de contexto (ADL, ), ou seja, funcionará em situações variadas, seja inserido
em um ambiente de gerenciamento de aprendizagem ou como parte de um curso on-line
publicado diretamente na Web.
6 MODULAR OBJECT-ORIENTED DYNAMIC LEARNING ENVIRONMENT 24
6 Modular Object-Oriented Dynamic Learning En-

vironment
A palavra MOODLE é um acrônimo de Modular Object-Oriented Dynamic Learning
Environment, ou Ambiente de Aprendizado Dinâmico e Modular Orientado a Objeto,
uma definição feita para programadores e técnicos da educação. Segundo (FERRAZ, 2007)
foi concebido na Austrália por Martin Dougiamas, para apoiar uma teoria de aprendizado
interativo chamado Pedagogia Construcionista Social, onde as pessoas aprendem melhor
quando interagem com o material de ensino.
6.1 Caracterı́sticas do Moodle

Para (??) o Moodle é um produto ativo e em evolução. Esta seção lista algumas das
caracterı́sticas que ele tem:
6.1.1 Linhas gerais

• Promove uma pedagogia social construcionista colaboração, atividades, reflexão e
crı́tica.
• Adequado para aulas 100
• Simples, eficiente, compatı́vel, interface baseada em navegadores de tecnologia sim-

ples
• Fácil instalação em qualquer plataforma que suporte o PHP. Exige apenas uma base
de dados
• Independência total da base de dados, suporta todas as principais marcas de base

de dados
• A lista de cursos mostra as descrições de cada curso existente no servidor, incluindo

acessibilidade para convidados.
• Cursos podem ser categorizados e pesquisados é um site Moodle pode suportar

milhares de cursos
• Ênfase em total segurança o tempo todo. Os formulários são todos checados, os

dados validados , os cookies codificados.
• A maioria das áreas de entrada de texto (recursos, postagens nos fóruns, etc.) podem
ser editadas usando um editor HTML WYSIWYG incorporado.
6.2 Recursos Adicionados ao Moodle

Nesta seção relata-se conceitos introdutórios sobre o DragMath (SANGWIN C.;BILLINGSLEY,
) e JsMath (CERVONE, ).
6 MODULAR OBJECT-ORIENTED DYNAMIC LEARNING ENVIRONMENT 25
6.2.1 DragMath
O DragMath foi criado por (SANGWIN C.;BILLINGSLEY, ) da Universidade de Birmingham,
no Reino Unido. O DragMath permite que os alunos construam expressões matemáticas,
utilizando uma interface gráfica.
O DragMath é integrado com o Moodle através de um novo botão na barra de editor.
Com isso esse recurso esta disponı́vel em todos os lugares em que os alunos e professores
estiverem atuando.
Na Figura mostra-se a tela inicial do DragMath.
No APÊNDICE É mostrado a instalação e configuração desse recurso no Moodle.
6.2.2 JsMath
Segundo (CERVONE, ) JsMath é uma coleção de programas JavaScript, que torna possı́vel
a visualização matemática dentro de páginas da web. Ele funciona em vários browsers e
plataformas de hardware, sem a necessidade de downloads ou plugins adicionais por parte
do usuário. (no entanto, se o usuário instala um conjunto de fontes matemática, mas
que não é necessário.) Ao contrário de métodos que utilizam imagens para representação
matemática, as equações geradas por jsMath serão corretamente dimensionados em relação
ao texto, independentemente do tamanho da fonte definidos pelo usuário e podem até
mesmo redimensionar corretamente se o usuário alterar o tamanho das letras.
JsMath não utiliza MathML. O MathML não foi concebido para ser escritos dire-
tamente, e a partir disso deu-se a necessidade de um modelo que poderia-se facilmente
escrever e incluir, embora não tendo a exigir aos estudantes que utilizam um determinado
navegador ou baixar um software extra para poder vê-lo. Na época do desenvolvimento
do jsMath, apenas Mozilla já continha o MathML implementado diretamente, e no IE
poderia fazê-lo com um plugin.
No APÊNDICE É mostrado a instalação e configuração desse recurso no Moodle.
7 GERENCIAMENTO DE PROJETOS 26
7 Gerenciamento de Projetos
O Gerenciamento de Projeto de Software é a arte de confrontar os objetivos da concorrên-
cia, gerenciar riscos e superar obstáculos para liberar com êxito um produto que atenda
às necessidades dos clientes e dos usuários. O fato de que tão poucos projetos sejam
indiscutivelmente bem-sucedidos é o comentário suficiente sobre a dificuldade da tarefa
(RATIONAL, 2001).
Figura 1: Gerenciamento de projetos no RUP (RATIONAL, 2001)
A finalidade do Gerenciamento de Projeto é:
• Fornecer um framework para gerenciar projetos intensivos de software;
• fornecer diretrizes práticas para planejar, montar a equipe, executar e monitorar os

projetos;
• fornecer um framework de gerenciamento de risco.

7 GERENCIAMENTO DE PROJETOS 27
Entretanto, essa disciplina do RUP não tenta cobrir todos os aspectos do gerencia-
mento de projeto. Por exemplo, ela não cobre problemas como:
• Gerenciamento de pessoal: contratação, treinamento, ensino;
• gerenciamento de orçamento: definição, alocação etc;
• gerenciamento de contratos, com fornecedores e clientes.
Essa disciplina enfatiza principalmente os aspectos importantes de um processo de

desenvolvimento iterativo:
• Gerenciamento de risco;
• planejamento de um projeto iterativo, por meio do ciclo de vida e de uma iteração

particular;
• monitoramento do progresso de um projeto iterativo, métricas para mensuramento.

8 ENGENHARIA DE SOFTWARE 28
8 Engenharia de Software
A Engenharia de Software emergiu na década de 70 e vem evoluindo significativamente nas
últimas décadas procurando estabelecer técnicas, critérios, métodos e ferramentas para a
produção de software, em consequência da crescente utilização de sistemas baseados em
computação em praticamente todas as áreas da atividade humana, o que provoca uma
crescente demanda por qualidade e produtividade, tanto do ponto de vista do processo de
produção como do ponto de vista dos produtos gerados(DóRIA, 2001).
O processo de engenharia de software2 é o processo de desenvolvimento de um sistema
a partir dos requisitos, sejam eles novos (ciclo de desenvolvimento inicial) ou alterados
(ciclo de evolução)(??).
Figura 2: Exemplo de processo em Engenharia de Software (??)
Um processo é um conjunto de passos parcialmente ordenados com a intenção de

atingir uma meta. A meta é criar um software ou aperfeiçoar um existente. No RUP, eles
são organizados em um conjunto de disciplinas para posteriormente definirem os fluxos de
trabalho e outros elementos do processo. Organizados em um conjunto de disciplinas para
posteriormente definirem os fluxos de trabalho e outros elementos do processo (RATIONAL,
2001).
8.1 Modelagem de Software

Um dos maiores tormentos envolvidos na construção de software é o reconhecimento dos
problemas e suas causas aliado à geração de soluções que ofereçam assistência prática e
padronizadas de acordo com cada problema. Para se atingir o resultado esperado a engen-
haria de software utiliza-se de três elementos fundamentais: os métodos, as ferramentas e
alguns procedimentos. Os métodos proporcionam os detalhes de como fazer para produzir
o software e estão divididos em tarefas que incluem planejamento e estimativa de projeto,
análise de requisitos de software e de sistemas, projeto da estrutura de dados, arquitetura
de programa, algoritmo de processamento, codificação teste e manutenção.
Existem limites para a capacidade humana de compreender complexidades, mais es-
pecificamente, reter todos os detalhes que envolvem uma realidade complexa, os relaciona-
mentos existentes, as possı́veis situações que possam ocorrer dependendo da combinação
de cada aspecto envolvido. Com a ajuda da modelagem, é delimitado o problema, re-
stringindo o foco num único aspecto por vez. Quanto mais complexo for o sistema, maior
será a probabilidade de ocorrência de erros ou de construção de itens errados. Caso não
se utilize nenhuma modelagem, pode-se esquecer de detalhes que irão comprometer o
produto quando estiver sendo utilizado (TONSIG, 2003).
Os procedimentos da engenharia de software mantém juntos os métodos e as ferramen-
tas e possibilita o desenvolvimento racional e oportuno do software. O conjunto destas
etapas para o desenvolvimento de software denomina-se paradigmas de engenharia de soft-
ware cuja escolha é efetuada no inı́cio do projeto tendo como base a natureza do projeto
e da aplicação, os métodos e as ferramentas a serem usados, os controles e produtos que
precisam ser entregues.
8.2 Programação Orientada a Objetos

Segundo (SANTOS, 2003), programação orientada a objetos é um paradigma de progra-
mação de computadores onde se usam classes e objetos criados à partir de modelos para
representar e processar dados usando programas de computadores. A modelagem dos
dados e operações em um programa de computador permite o processamento dos dados
de forma coesa, rápida e menos suscetı́vel a erros.
8.3 Unified Modeling Language (UML)

Para que a utilização de representações simplificadas de modelos com dados e processos
relevantes ao contexto de desenvolvimento de software atingisse uma maturidade e ex-
celência diante do público em questão, a padronização de uma linguagem foi necessária,
desta necessidade surge a UML.
De acordo com (GRADY; RUMBAUGH; JACOBSON, 2000), a UML (Unified Modeling
Language) é uma linguagem de modelagem padronizada para engenharia de sistemas
orientados a objeto. Ela foi concebida a partir de várias técnicas de projeto e análise
orientados a objeto (OOA& D – Object Oriented Analysis & Design) existentes, de vários
autores, como Coad & Yourdon, Shlaer & Mellor, Odell & Martin e principalmente, a
partir do ”método unificado”OOSE (Object Oriented Software Engineering), de Booch,
Rumbaugh e Jacobson.
Pode-se dizer que o objetivo principal da UML é definir uma linguagem de modelagem
visual e expressiva, no sentido de prover facilidades na visualização, ou seja, o pleno en-
tendimento das funções de um sistema a partir de diagramas que o representem, no geren-
ciamento de complexidade, permitindo uma representação simplificada das atividades do
sistema, ou seja, que cada aspecto funcional dele seja representado em modelos especı́ficos
e, por fim, na comunicação, unificando a comunicação da equipe de desenvolvimento na
forma de diagramas.
Além disso, a UML tem por objetivo prover uma base formal para o entendimento
da linguagem de modelagem, visual e textualmente; ser independente de linguagem de
programação e também de processos de desenvolvimento de sistema (embora exista um
padrão sugerido na UML); ser extensı́vel e suportar outros conceitos de desenvolvimento
de sistemas, como colaborações, patterns, distribuição e componentes; integrar as carac-
terı́sticas de várias práticas de modelagem OOA& D, no sentido de uniformizar a mod-
elagem de sistemas orientados a objeto em um só padrão de fato e, por fim, fomentar o
crescimento da utilização de ferramentas de desenvolvimento de sistemas.
(MARTINS, 2007) diz que, Diagramas UML são o cerne da linguagem de modelagem
pois através deles se pretende demonstrar os elementos que compõem um sistema, como
eles interagem para atingir a resposta esperada e, a partir dessa combinação, se possa
partir diretamente para a geração de código.
Segundo (TONSIG, 2003), a UML tem como objetivo prover as necessidades de de-
senvolvedores de software com uma linguagem de modelagem visual completa, buscando
atingir os seguintes aspectos:
1. Disponibilização de mecanismos de especificações que possam expressar os nı́veis

conceituais;
2. independência de processos de desenvolvimento e linguagens de programação;

3. incentivo do crescimento das aplicações desenvolvidas no conceito da orientação a

objetos;
4. permissão de suporte a conceitos de desenvolvimento de alto nı́vel, tais como frame-

works, padrões e componentes.
8.4 Diagramas da UML

Um diagrama provê uma parcial representação do sistema. Ele ajuda a compreender a
arquitetura do sistema em desenvolvimento, os diagramas da UML são:
8.4.1 Diagrama de Casos de Uso (Use Cases Diagram)

É o diagrama que representa o cenário de execução do sistema, ou seja, a sequência de
passos que descrevem as interações entre o usuário (que pode ser humano, outros objetos
do mesmo sistema, ou ainda outros sistemas) e o sistema.
8.4.2 Diagrama de Classes (Class Diagram)

É considerado como a visão estática da estrutura do sistema e escreve os tipos de objetos
do sistema e os relacionamentos entre eles. Neste diagrama são definidas as classes, através
de seus métodos e atributos.
8.4.3 Diagramas de Interação (Interaction Diagrams)

Descrevem o funcionamento do sistema, através da representação dos objetos e suas in-
terações no tempo de execução, em geral partindo de um caso de uso (evento de entrada).
São divididos em dois tipos: o Diagrama de Sequência, que mostra as interações entre os
objetos a partir de um evento disparado pelo usuário em forma de linha de tempo e o
Diagrama de Colaboração, que mostra as ligações estáticas entre os objetos e como elas
são ativadas a partir de um evento e as mensagens entre os objetos, ordenadas em tempo
de execução por timestamps.
8.4.4 Diagrama de Estados (State Diagram)

É a descrição comportamental dos componentes do sistema, demonstrando todos os pos-
sı́veis estados de um objeto, como esses estados mudam (transições) e como os objetos
respondem aos eventos.
8.4.5 Diagrama de Atividades (Activity Diagram)

Considerado uma variação do diagrama de estados, age como complemento deste, mostrando
os fluxos de execução internos do sistema, em geral também a partir de casos de uso.
Permitem a representação de concorrência na execução de fluxos, através da técnica de
desenho em swimlanes.
8.4.6 Diagrama de Implementação (Deployment Diagram)

Utilizado, juntamente com o Diagrama de Componentes, para representar os relaciona-
mentos fı́sicos e lógicos entre os componentes de hardware e software do sistema, sendo
bastante aplicado onde é necessária uma representação da distribuição de componentes

de um sistema.
8.4.7 Diagrama de Pacotes (Package Diagram)

Geralmente utilizados em sistemas de maior porte, representa os pacotes (conjuntos de
classes agrupadas para formar uma unidade de execução concisa), classes e suas dependên-
cias na execução de tarefas do sistema.
9 RATIONAL UNIFIED PROCESS (RUP) 32
9 Rational Unified Process (RUP)

Este capı́tulo apresenta um resumo dos principais conceitos do RUP relacionados ao geren-
ciamento de projetos e utilizados no desenvolvimento deste projeto.
O RUP é um processo de engenharia de software. Ele oferece uma abordagem baseada
em disciplinas para atribuir tarefas e responsabilidades dentro de uma organização de
desenvolvimento. Sua meta é garantir a produção de software de alta qualidade que atenda
às necessidades dos usuários dentro de um cronograma e de um orçamento previsı́veis
(RATIONAL, 2001).
Figura 3: Arquitetura geral do RUP (RATIONAL, 2001)
• O eixo horizontal representa o tempo e mostra os aspectos do ciclo de vida do

processo à medida que se desenvolve;
• o eixo vertical representa as disciplinas, que agrupam as atividades de maneira

lógica, por natureza.
O RUP tem duas dimensões: dinâmica e estática.
9.1 Dimensão Dinâmica

Na dimensão dinâmica, o projeto de software é dividido ao longo do tempo em quatro
fases. Cada uma das fases é dividida em uma ou mais iterações. Uma iteração é um ciclo
de desenvolvimento completo, resultando em uma versão, um subconjunto do produto
final, que cresce incrementalmente de iteração a iteração para se transformar no produto
final (TAMAKI, 2007).
As quatro fases do RUP são descritas a seguir.
9.1.1 Iniciação
Os objetivos principais da fase de iniciação incluem:
• Estabelecer o escopo do software do projeto e as condições limite, incluindo uma

visão operacional, critérios de aceitação e o que deve ou não estar no produto;
• discriminar os casos de uso crı́ticos do sistema, os principais cenários de operação e

o que direcionará as principais trocas de design;
• exibir, e talvez demonstrar, pelo menos uma opção de arquitetura para alguns
cenários básicos;
• estimar o custo geral e a programação para o projeto inteiro, e estimativas detalhadas

para a fase de elaboração imediatamente a seguir;
• estimar riscos em potencial e as origens de imprevistos;
• preparar o ambiente de suporte para o projeto.
No fim na fase de iniciação está o primeiro marco mais importante do projeto ou Marco
dos Objetivos do Ciclo de Vida. Nesse momento, são analisados os objetivos do ciclo de
vida do projeto e decide-se prosseguir ou cancelar o mesmo.
9.1.2 Elaboração
A meta da fase de elaboração é criar a baseline1 do sistema. A arquitetura se desenvolve
a partir de um exame dos requisitos mais significativos e de uma avaliação de risco.
Os objetivos primários da fase de elaboração incluem:
• Assegurar que a arquitetura, os requisitos e os planos sejam estáveis o suficiente e

que os riscos sejam suficientemente diminuı́dos a fim de determinar com segurança
o custo e a programação para a conclusão do desenvolvimento. Para a maioria dos
projetos, ultrapassar essa marca também corresponde à transição de uma operação
rápida e de baixo risco para uma operação de alto custo e alto risco com uma inércia
organizacional frequente;
• tratar todos os riscos significativos do ponto de vista da arquitetura do projeto;
• estabelecer uma arquitetura da baseline derivada do tratamento dos cenários sig-

nificativos do ponto de vista da arquitetura, que normalmente expõem os maiores
riscos técnicos do projeto;
• produzir um protótipo evolutivo dos componentes de qualidade de produção, assim

como um ou mais protótipos descartados para diminuir riscos especı́ficos como:
Trocas de design/requisitos;
reutilização de componentes;
possibilidade de produção do produto ou demonstrações para investidores, clientes
e usuários finais.
1
baseline é uma ”imagem”de uma versão de cada artefato no repositório do projeto. Ela funciona como
um padrão oficial básico para os trabalhos subsequentes.
• demonstrar que a arquitetura de baseline suportará os requisitos do sistema a um

custo justo e em tempo justo;
• estabelecer um ambiente de suporte.
No fim na fase de elaboração está o segundo marco mais importante do projeto, o

Marco da Arquitetura do Ciclo de Vida. Nesse momento, você examina os objetivos e o
escopo detalhados do sistema, a opção de arquitetura e a resolução dos principais riscos.
9.1.3 Construção
A meta da fase de construção é esclarecer os requisitos restantes e concluir o desenvolvi-
mento do sistema com base na arquitetura da baseline.
Os objetivos principais da fase de construção incluem:
• Minimizar os custos de desenvolvimento, otimizando recursos e evitando retalhamento

e retrabalho desnecessários;
• atingir a qualidade adequada com rapidez e eficiência;
• atingir as versões úteis (alfa2 , beta3 e outros releases4 de teste) com rapidez e
eficiência;
• concluir a análise, o design, o desenvolvimento e o teste de todas as funcionalidades

necessárias;
• desenvolver de modo iterativo e incremental um produto completo que esteja pronto

para a transição para a sua comunidade de usuários. Isso implica descrever os casos
de uso restantes e outros requisitos, incrementar o design, concluir a implementação
e testar o software;
• decidir se o software, os locais e os usuários estão prontos para que o aplicativo seja
implantado;
• atingir um certo paralelismo entre o trabalho das equipes de desenvolvimento.
O marco Capacidade Operacional Inicial determina se o produto está pronto para ser
implantado em um ambiente de teste beta.
9.1.4 Transição
O foco da Fase de Transição é assegurar que o software esteja disponı́vel para seus usuários
finais.
Os objetivos principais da Fase de Transição são:
• Teste beta para validar o novo sistema em confronto com as expectativas do usuário;
2
alfa é uma versão de software ainda em teste. O software pode sofrer alterações radicais.
3
beta é uma versão gerada à um grupo de teste. Possui a maioria das caracterı́sticas da versão final
mas pode possuir bugs(defeitos) que o tornam impróprio para utilização profissional.
4
release é uma notificação formal da versão de software que tenha se tornada pública.
• teste beta e operação paralela relativa a um sistema legado5 que está sendo substi-
tuı́do;
• conversão de bancos de dados operacionais;
• treinamento de usuários e equipe de manutenção;
• introdução a marketing, distribuição e equipe de vendas;
• engenharia voltada para implantação, como preparação, empacotamento e produção

comercial, introdução a vendas, treinamento de pessoal em campo;
• atividades de ajuste, como correção de erros, melhoria no desempenho e na usabili-

dade;
• avaliação das baselines de implantação tendo como base a visão completa e os

critérios de aceitação para o produto;
• obtenção de auto-suportabilidade do usuário;
• obtenção do consentimento dos envolvidos de que as baselines de implantação estão

completas;
• obtenção do consentimento dos envolvidos de que as baselines de implantação são

consistentes com os critérios de avaliação da visão.
No fim na fase de transição está o quarto marco mais importante do projeto, o Marco
do Release do Produto. Nesse momento, você decide se os objetivos foram atendidos, e
se outro ciclo de desenvolvimento deve ser iniciado.
9.2 Dimensão Estática

A dimensão estática do RUP descreve basicamente quem deve fazer o que, como e quando.
Para representar estas caracterı́sticas, o RUP utiliza as estruturas descritas a seguir.
9.2.1 Fluxo de Trabalho

O fluxo de trabalho é uma sequência de atividades que produz um resultado de valor
observável. Para representar esta sequencia de atividades, ele se utiliza do diagrama de
atividades proposto na UML.
Cada uma das macro-atividades apresentadas na Figura 4 são apenas o primeiro nı́vel
de detalhamento. Cada uma delas possui um segundo nı́vel de detalhamento, que apre-
senta um conjunto de atividades, papéis e artefatos que as compõem.
Cada fluxo de trabalho é repetido a cada iteração como na Figura 5. Apesar do fluxo
ser repetido em todas as iterações, o volume de trabalho de cada uma das atividades pode
variar.
5
Sistemas legados são sistemas antigos, geralmente de difı́cil manutenção, que fornecem serviços essen-
ciais a empresa mas que pelo grau de criticidade e custo para modernização, continuam ativas.
Figura 4: Fluxo de trabalho do RUP (RATIONAL, 2001)
9.2.2 Papéis
Um papel define um conjunto de comportamentos ou responsabilidades que um indivı́-
duo ou uma equipe pode adquirir ao longo do processo de desenvolvimento estabelecido
pelo RUP, conforme exemplo da Figura 6. Um mesmo indivı́duo pode assumir diversos
papeis ao longo do ciclo de vida de desenvolvimento. Os principais papéis do RUP são os
analistas, os testadores, os gerentes e os desenvolvedores.
• Analistas organizam os papéis envolvidos principalmente na identificação e na in-

vestigação de requisitos.
• Testadores organizam os papéis que lidam com habilidades especı́ficas exclusivas

para teste.
• Gerentes organizam os papéis envolvidos principalmente no gerenciamento e na

configuração do processo de engenharia de software.
Figura 5: Iteração do RUP (RATIONAL, 2001)
Figura 6: Representação de papel do RUP (RATIONAL, 2001)
• Desenvolvedores organizam os papéis envolvidos principalmente no design e de-

senvolvimento de software.
9.2.3 Atividades
Cada papel possui um conjunto de atividades que definem o trabalho realizado por ele
(Figura 6). Cada atividade produz um resultado significativo para o contexto do projeto
e tem uma finalidade clara, normalmente expressa através da criação ou atualização de
um artefato.
9.2.4 Artefatos
Um artefato é um produto de trabalho do processo. Os papéis utilizam artefatos para
realizar atividades e produzem ou alteram artefatos ao executarem as atividades (conforme
ilustrado na Figura 6).
9.2.5 Disciplinas
Uma disciplina é um conjunto de atividades relacionadas a uma mesma área de interesse.
O objetivo do agrupamento das atividades em disciplinas é facilitar a compreensão do
processo, tornando-o similar a uma perspectiva tradicional (modelo em cascata) em cada
disciplina.
O RUP apresenta as seguintes disciplinas:
• Modelagem de Negócios: Disciplina responsável pelo entendimento do domı́nio

do problema, pela detecção dos problemas no processo de negócio atual, e pela
identificação das possibilidades de melhoria;
• Requisitos: Disciplina responsável por levantar e manter o acordo entre cliente e

desenvolvedores sobre os objetivos e o escopo do sistema;
• Análise e Projeto: Disciplina responsável pelo projeto da arquitetura do sistema,

seguindo os requisitos estabelecidos para o mesmo;
• Implementação: Disciplina responsável pela implementação e testes dos compo-

nentes do sistema;
• Teste: Disciplina responsável pelo planejamento, implementação e execução dos

testes de integração e de sistema. O objetivo de tais testes é encontrar defeitos no
sistema e apresentar resultados concretos que o sistema atende as especificações;
• Implantação: Disciplina responsável por garantir que o sistema será disponibi-

lizado aos seus usuários finais;
• Gerenciamento de Configuração e Mudança: Disciplina responsável por con-

trolar as mudanças feitas nos artefatos de um projeto e manter a integridade entre
eles;
• Gerenciamento de Projeto: Disciplina responsável pela elaboração dos planos e

controle da execução do projeto de software;
• Ambiente: Disciplina responsável por estabelecer o processo e as ferramentas

necessárias para o ambiente de desenvolvimento do sistema.
10 FERRAMENTAS E TECNOLOGIAS UTILIZADAS 39
10 Ferramentas e tecnologias utilizadas

Este capı́tulo é dedicado à apresentar as ferramentas e tecnologias utilizadas no desen-
volvimento deste projeto.
10.1 NetBeans uma Ferramenta Open Source

NetBeans é um projeto Open Source de sucesso com uma ampla base de usuários, uma
comunidade crescente, perto dos 100 parceiros pelo mundo. A Sun Microsystem fun-
dou o projeto Open Source NetBeans em junho de 2000 e continua sendo seu principal
patrocinador (NADA, 2009a).
Hoje existem dois produtos: O NetBeans IDE e o NetBeans Platform.
O NetBeans IDE é um ambiente de desenvolvimento, uma ferramenta para progra-
madores escreverem, compilarem, depurarem e implantarem programas. É escrito em
Java, mas pode suportar qualquer linguagem de programação. Existem também um
enorme número de módulos para aprimorá-lo. O NetBeans IDE é um produto gratuito
sem restrições de como ser utilizado.
A facilidade de utilização prova também o seu fascı́nio pois não é preciso ir além do
portal netbeans.org em busca de caracterı́sticas adicionais e plug-ins em pacotes de car-
acterı́sticas com uma variedade de requisitos, desde C/C++ até mobilidade para a Web.
Uma vez transferido, o NetBeans é fácil de utilizar, graças ao sua interface de utilizador
e caracterı́sticas tais como o recentemente anunciado Visual Web Pack (VWP). Com o
VWP, os componentes JavaServer Faces, utilizados no desenvolvimento deste projeto, po-
dem ser arrastados e largados de modo a definir propriedades e criar código para processos
de eventos ao nı́vel do servidor.
O NetBeans verifica também o seu ciclo de desenvolvimento, e este processo ajuda
a expandir o alcance das aplicações criadas com o IDE. Esta capacidade de extensão
pode ser encontrada, por exemplo, nas aplicações de Intranet, que podem ser facilmente
migradas para dispositivos móveis com o NetBeans Mobility Pack. Tal como os outros
módulos em NetBeans, o Mobility Pack oferece ferramentas de programação de arrastar
e largar e isto resulta na criação de aplicações móveis baseadas em ecrã (tela) concebidas
com pouca lógica adicional (NADA, 2009b).
10.2 W3C
O Word Wide Web Consortium(W3C) é um consórcio de empresas de tecnologia, fun-
dado por Tim Berners Lee em 1994. Possui diversos comitês que estudam as tecnologias
existentes para a apresentação de conteúdo na Internet e criam padrões de recomendação
para a utilização dessas tecnologias. Com a padronização, os programas conseguem aces-
sar facilmente os códigos e entender onde deve ser aplicado cada conhecimento expresso
no documento. Alguns exemplos de padrões são CSS, HTML e XML.
Com a utilização do padrão W3C o conteúdo produzido trará compatibilidade entre
Navegadores, tirando um bom fardo das mãos do desenvolvedores uma vez que apenas
navegadores que seguem este padrao executaram suas aplicações com perfeição.
A importância dos padrões W3C são notáveis pelas ferramentas de buscas de conteúdo
na internet onde desfrutarão desta padronização dando relevância a conteúdos publicados
validados pela W3C.
10.3 XHTML
A XTML é uma reformulação da linguagem HTML(Hypertext MarKup Language) baseada
na XML(Extensible Markup Language). Em termos de sintaxe, a XHTML não é tolerante
como a HTML. Isso ocorre porque a XHTML utiliza as rı́gidas regras XML para realizar
as marcações em um documento.
As limitações da HTML levaram o W3C( desenvolvedor dos padrões e diretrizes para
a web) a partir para uma próxima etapa no desenvolvimento de linguagens de marcação,
criando a XHTML.
Essa nova Linguagem consiste em uma reformulação do HTML 4.01 baseada na XML
1.0, que hoje é bastante utilizada por permitir criação de marcação padronizada, além
de fazer a separação entra marcação e exibição. Com isso são resolvidos os problemas
existentes na HTML, como os listados a seguir.
• Código desnecessário: geralmente quem desenvolve um documento HTML, em vez

de utilizar folhas de estilos para orientar a exibição, faz isso por meio de tags de
formatação(como, por exemplo, a tag << f ont >> ), o que muitas vezes torna o
código repetitivo. Isso causa um aumento desnecessário no tamanho do documento
e, consequentemente, ele demorará mais para ser carregado.
• Dificuldade na descrição dos dados: a HTML não se preocupa em descrever os tipos

de dados contidos nos documento, o que torna difı́cil a recuperação e a troca desses
dados.
• Elementos incluı́dos por fabricantes de browsers: os desenvolvedores de paginas

HTML se deparam com elementos criados pelas próprias empresas que fabricam os
programas navegadores, como Internet Explorer e o Netscape.
Visando à conquista de um maior numero de usuários, essas empresas acabaram in-

troduzindo seus próprios elementos à HTML, o que dificultou ainda mais a criação de
um documento que seja exibido corretamente em diferentes browsers. Um documento
desenvolvido em XHTML deve ser muito bem escrito devido a suas rı́gidas regras para
marcação.
Em um documento XHTML podem ser utilizados diversas tecnologias que foram de-
senvolvidas para trabalhar em conjunto com a XML, como por exemplo, folhas de estilo
que convertem documento XML e consultas a ducumentos XML. Documentos XHTML
suportam aplicações(como script ou applets) que funcionam com o HTML Document
Model e com o XML Document Model.
A padronização no desenvolvimento ajuda a programação e visualização do código.
10.4 CSS
A Cascading Style Sheet (CSS) é uma ferramenta utilizada para a construção da aparência
de paginas para web. permite o uso de uma técnica diferente da convencional (HTML
puro), possibilitando uma considerável redução no tempo de trabalho.
O recurso, que traduzido significa Folha de Estilo em Cascata, se tornou uma necessi-
dade para quem deseja ser um bom webdeveloper (desenvolvedor de paginas para internet)
e para quem quer criar qualquer projeto Web. Com isso é possı́vel o controle do layout
de vários documentos a partir de um simples arquivo CSS, onde a aplicação de diferentes
layouts podem servir para diferentes mı́dias(telas, impressoras).
Devido a alguns navegadores não seguirem padrões W3C, foram desenvolvidos recursos
chamados CSS Hacks, onde regras são criadas para que os navegadores executarem e
manterem a padronização de exibição de conteúdos.
Com a utilização da CSS podemos obter a formatação separadas da HTML, trazendo
conforto para manutenções onde os arquivos de estrutura e formatação ficão distintos.
A codificação fica mais limpa e sem redundâncias, a facilidade de criação de classes
que herdam modelos de formatação ajuda a otimização de códigos HTML.
10.5 JavaScript
JavaScript é a linguagem de script criada pela Netscape em 1995, tendo sido lançada
com o navegador Netscape Navigator 2.0. Com seu lançamento, as paginas na Internet
começaram a ganhar vida, implementando um minimo de dinamicidade devido ao modo
como a linguagem acessa e manipula os componentes do seu ambiente hospedeiro(nesse
caso, o Natscape Navigator).
A linguagem Java Script é interpretada dando a liberdade ao programador de não
declarar uma variável antes de utiliza-la ou de adicionar novas propriedades e novos méto-
dos a um objeto a qualquer momento.
Em uma aplicação Web muitos processos que são executados pelo servidor de internet,
para retirar esta sobrecarga pode ser utilizado a linguagem JavaScript por exemplo na
validação de campos, este processo é feito pelo navegador do cliente onde os dados já
disparam tratados para o servidor. Além disso exibindo o código fonte da pagina todo
o código criado pode ser copiado por outras pessoas, isso pode facilitar a maneira de
descobrir falhas no código e aproveita-las para algum acesso restrito.
Exemplo: CPF sendo validado apenas no Cliente(navegador), existindo falha no código
o sistema armazenará um CPF inválido.
O JavaScript permite uma interação com o HTML, tornando possı́vel a manipulação
de vários elementos e a criação de recursos diversos em uma página que o HTML, por si
só, é incapaz de realizar.
Além disso a disponibilidade de editores, bibliotecas e depuradores de alta qualidade.
10.6 JQuery
JQuery é uma biblioteca em JavaScript que ajuda desenvolvedores web e designers adi-
cionar dinâmicos e interativos elementos para os seus projetos que podem reduzir grande-
mente o tempo de desenvolvimento, sabendo que um vasto conteúdo de código fonte é
disponı́vel para uso, e aplicações sofisticadas com recursos dinâmicos é possı́vel obter.
Além disso a atualização geral de uma pagina não ocorre mais, apenas o conteúdo
necessário é carregado havendo menor tráfego de banda.
JQuery utiliza AJAX para manipulação de seus elementos, e trás compatibilidade
entre navegadores. Em uma aplicação Web os Códigos fonte desenvolvidos com esta
biblioteca ficam acessı́veis para o cliente, porem esta aplicação não executa caso os arquivos
JavaScript estiverem desabilitados pelo Navegador.
A velocidade no desenvolvimento, compatibilidade entre navegadores e a reusabilidade
de códigos fontes disponı́veis são pontos que destacam esta Biblioteca.
10.7 Ajax
Ajax não é apenas uma tecnologia, são várias tecnologias: XHTML, CSS, Document
Object Modal(DOM), XML, XMLHttpRequest(XHR), JavaScript.
Segundo Jesse James Garrett, 2005 AJAX significa Asynchronous JavaScript And
Xml. Com a utilização do conjunto destas tecnologias os navegadores passam a fornecer
aplicações não mais apenas conteúdo.
A atualização geral de uma pagina não ocorre mais, apenas o conteúdo necessário é
carregado havendo menor tráfego de banda.
Assim como a Biblioteca JQuery o código fonte fica desprotegido, a aplicação não
executa caso os arquivos JavaScript estiverem desabilitados pelo Navegador.
Devido sua resposta rápida ser um diferencial, o tráfego da banda é menor e as apli-
cações podem ser mais flexı́veis e agradáveis para visualizar e manipular em um Naveg-
ador.
10.8 Apache Tomcat

O Apache Tomcat é um Servlet Container distribuı́do livremente, que implementa as
especificações da tecnologia JSP (Java Server Pages), da Sun Microsystems.
Servlets são classes Java que, de forma semelhante a linguagens como PHP, Perl e
Python, extendem as capacidades de um servidor web. Servlets usam o modelo Re-
quest/Response (Requisição/Resposta), em que o cliente faz uma requisião ao servidor
web, o servidor processa os dados da requisição, e envia uma resposta HTTP para o
browser (cliente).
O Apache Tomcat é 100% compatı́vel com as especificações Servlet e JSP publicadas
pela Sun, sendo considerada, assim, a implementação de referência.(CHOPRA; LI; GENEN-
DER, 2007)
A última versão do Apache Tomcat (6) implementa as especificações Servlet 2.5 e JSP
2.1
10.8.1 História
As origens do Tomcat remontam a metade da década de 1990, com o projeto Apache.
Originalmente desenvolvido por Rob McDool, na época no National Center for Super-
computer Applications (NCSA), ficou inicialmente conhecido como NCSA Project Web
Server.
O nome Apache surgiu após a saı́da de MCDool. Um grupo de desenvolvedores da
NCSA se reuniu e aplicou diversos melhoramentos e correções (patches) no código. Em
abril de 1995, uma nova versão foi lançada, agora com o nome de Apache, que é um
acrônimo para ‘A PAtCHy Web Server‘
A Sun Microsystems criou o primeiro Servlet Container, chamado Java Web Server,
que demonstrava como a tecnologia funcionava. Por sua vez, a ASF (Apache Software
Foundation) desenvolvia o JServ, outro Servlet Container, que se integrava ao Apache.
Em 1999, a Sun Microsystems doou o código fonte de seu projeto para a ASF. Os
dois projetos foram fundidos e assim nasceu o Apache Tomcat.(CHOPRA; LI; GENENDER,
2007)
10.9 JSP
JSP (Java Server Pages) é uma tecnologia criada para desenvolver páginas da internet
com conteúdo dinâmico, semelhantemente a linguagens como PHP e Perl.
Diferentemente de HTML, onde as página possuem um conteúdo dinâmico, as páginas
JSP podem mudar seu conteúdo com base nas reuisições do cliente, nas variáveis do
servidor, informações vindas de bancos de dados, entre outros fatores.
Uma página JSP contém marcações especiais, como a HTML. A diferença está no fato
de essas tags possibilitarem o servidor inserir dados na página dinamicamente. (BERG-
STEN, 2002)
10.10 MySQL
MySQL é um SGBDR (Sistema Gerenciador de Banco de Dados Relacional) rápido,
multi-tarefa, multi-usuário e robusto. Desenhado tanto para trabalhar com sistemas com
grandes quantidades de dados, como para pequenas aplicações.(MYSQL. . . , 2009)
10.11 XML
XML é um acrônimo para eXtensible Markup Language (Linguagem de marcação exten-
sı́vel). XML é derivada da SGML (Standard Generalized Markup Language). A entidade
responsável por definir os padrões da linguagem é a W3C (World Wide Web Consor-
tium).(HUNTER et al., 2007, pag. 7)
Apesar do nome, SGML nem XML são linguagens em si. São melhor entendidas como
metalinguagens usadas para construir outras linguagens ou vocabulários.(JACOBS, 2006,
pag. 2)
10.12 LaTeX
Este tópico visa apresentar sobre a utilização do LaTeX para o desenvolvimento não só
deste trabalho, mas também o motivo pelo qual foi utilizado para formatar as fórmulas
matemáticas para os questionários do sistema.
LaTeX é uma linguagem de macros para TeX, um programa de formatação de doc-
umentos para impressão baseado em uma linguagem de marcação criado por Donald E.
Knuth, um professor de matemática dos Estados Unidos que estava insatisfeito com a
qualidade gráfica das edições de seus livros.(TEX-BR, 2009)
O TeX é o mais antigo (desde 1983) sistema de processamento de textos ainda em uso
e também o único que está disponı́vel para todos os sistemas operacionais e o único capaz
de imprimir o mesmo documento em qualquer sistema sem perdas de formatação.
Estas vantagens, aliadas a facilidade para trabalhar com fórmulas matemáticas, gráfi-
cos e sı́mbolos esdrúxulos tornam os sistemas TeX e LaTeX muito apreciados por pessoas
que escrevem teses e livros técnicos nas áreas de ciências exatas porque somente através
de um sistema TeX ou LaTeX é possı́vel, a baixo custo, produzir documentos matemáticos
de qualidade tipográfica profissional.
LaTeX (pronúncia correta lay tech) é uma linguagem de macro que facilita o uso do
TeX por leigos (aliás a primeira sı́laba do nome se pronuncia exatamente igual à palavra
inglesa lay, que significa ”leigo”). Cada comando LaTeX é um atalho para um conjunto
de comandos TeX.
• Formatação de qualidade por padrão;
• liberta o autor para concentrar-se no conteúdo em vez da forma;
• facilidade para trabalhar com fórmulas matemáticas;
• facilidade para trabalhar com bibliografias e citações;
• facilidade para trabalhar com referências cruzadas;
• geração automática e sempre correta de sumários, listas de tabelas, listas de figuras,

etc.;
• facilidade para criação de ı́ndices remissivos6 ;
• facilidade para criação de glossários a partir de entradas no texto do livro;
• gerenciamento inteligente de notas de rodapé;
• facilidade para acrescentar notas à margem;
• produção de PDFs sem custo;
• exportação para HTML através de programas como latex2html e tex4ht e para RTF
(latex2rtf);
• inserção automática de numeração sequencial de seções;
• gerenciamento fácil (por padrão) de diferentes estilos de página para capa, folha de
rosto, ı́ndices, parte pré-textual, parte textual, páginas iniciais de capı́tulo, apêndice,
etc.;
• gerenciamente fácil de documentos a ser impressos em ambos os lados do papel.
Desvantagens
• Requer aprendizado, sendo necessário pelo menos um mês de treinamento até que o
usuário se sinta à vontade;
• a conversão para formatos populares, como Word ou OpenOffice, ou não existe ou

é de baixa qualidade, gerando perda de parte do texto ou de formatação.
• quanto mais complexo o documento, mais complexos se tornam os comandos em-

pregados.
6
Índice Remissivo é uma lista em ordem alfabética dos diversos nomes e assuntos mencionados numa
obra, com a indicação de página, capı́tulo, contexto etc.
Referências
2009. Disponı́vel em: <http://www.netbeans.org/index pt BR.html>.
2009. Disponı́vel em:

<http://www.sun.com/emrkt/innercircle/newsletter/portugal/0207portugal
feature.html>.
ADL.
ALMEIDA, M. E. B. de. Educação a distância na internet: abordagens e contribuições

dos ambientes digitais de aprendizagem. 2003. Disponı́vel em: <www.scielo.br/pdf/ep-
/v29n2/a10v29n2.pdf>.
BERGSTEN, H. Java Server Pages. [S.l.]: O’Reilly Media, 2002.
CERVONE, D. P.
CHOPRA, V.; LI, S.; GENENDER, J. Professional Apache Tomcat 6. [S.l.]: Wiley
Publishing, 2007.
DOUGIAMAS, M.
DóRIA, E. S. Replicação de estudos empı́ricos em engenharia de software. 2001.

Disponı́vel em: <http://www.teses.usp.br/>.
DUTRA R. L.;TAROUCO, L. M. R.
FERRAZ, G. de M. Análise da interface com o aluno de um Sistema de Gerenciamento

de Curso aplicando conceitos de cognição. 2007. Disponı́vel em: <http://www.teses.usp-
.br/teses/disponiveis/3/3141/tde-18012008-115913/>.
GRADY, B.; RUMBAUGH, J.; JACOBSON, I. UML Guia do Usuário. [S.l.]: Elsevier,
2000.
HUNTER, D. et al. Beginning XML. [S.l.]: Wiley Publishing, 2007.
JACOBS, S. Beginning XML with DOM and Ajax: From Novice to Professional. [S.l.]:
Apress, 2006.
MARTINS, J. C. C. Gerenciando Projetos de Desenvolvimento de software com PMI,

RUP e UML. [S.l.]: Editora Atual, 2007.
MORAN, J. M. O que e educacao a distancia. 2002. Disponı́vel em: <http://www.eca-

.usp.br/prof/moran/dist% -.htm>.
MYSQL 5.1 Reference Manual. 6 2009. Disponı́vel em: <http://dev.mysql.com/doc-

/refman/5.1/en/introduction.html>.
PADALINO, Y. E-LEARNING: ESTUDO COMPARTIVO DA APREENSÃO DO

CONHECIMENTO ENTRE ENFERMEIROS. 2006. Disponı́vel em: <http://www-
.teses.usp.br/teses/disponiveis/7/7131/tde-18102006-085645/>.
RATIONAL, S. C. Rational unified process. 2001. Disponı́vel em: <http://www-

.wthreex.com/rup/portugues/index.htm>.
REFERÊNCIAS 46
RODRIGUES, A. C. A escola e sociedade da informação, que pedagogias no século xxi?

2003. Disponı́vel em: <http://www.prof2000.pt/users/acr/materiais/ead/elearn1.htm>.
SANGWIN C.;BILLINGSLEY, A.
SANTOS, R. Introdução a programação orientada a objetos usando Java. [S.l.]: Elsevier,

2003.
TAMAKI, P. A. O. Uma extensão do rup com ênfase no gerenciamento de projetos do

pmbok baseada em process patternes. 2007. Disponı́vel em: <http://www.teses.usp.br/>.
TEX-BR. 2009. Disponı́vel em: <http://www.tex-br.org>.
TONSIG, S. L. Engenharia de Software: Análise e projeto de sistemas. [S.l.]: Editora

Futura, 2003.

TCC

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

TCC

Enviado por

Direitos autorais:

Formatos disponíveis

FACULDADE CARLOS DRUMMOND DE ANDRADE

DESENVOLVIMENTO DE UMA FERRAMENTA ACADÊMICA PARA

DESENVOLVIMENTO DE UMA FERRAMENTA ACADÊMICA PARA

Trabalho de Conclusão de Curso apre-

DESENVOLVIMENTO DE UMA FERRAMENTA ACADÊMICA PARA

Trabalho de Conclusão de Curso apresentado à Faculdade Carlos Drummond de Andrade,

Profa . Lúcia Contente Mós

São Paulo, junho de 2009.

4 Learning Management Systems (LMS) 21

5 Sharable Content Object Reference Model (SCORM) 23

6 Modular Object-Oriented Dynamic Learning Environment 24

9 Rational Unified Process (RUP) 32

10 Ferramentas e tecnologias utilizadas 39

• Questões de tipos diferentes;

• Questões diferentes para cada uma;

• Questões em ordens diferentes;

• Questões diferentes para diferentes provas, entre outros.

1.4 Estrutura do trabalho

9 Rational Unified Process (RUP)

10 Ferramentas e tecnologias utilizadas

2.1 Tipos de Educação a distância

3.1 Vantagens e desvantagens do E-Learning

• Redução dos custos de deslocações e estadias: ao acederem à informação em qualquer

Ainda (RODRIGUES, 2003) descreve as desvantagens do sistema e-learning:

• Necessidade de maior esforço para motivação dos alunos.

• Dificuldades técnicas relativas a Internet e a velocidade de transmissão de imagens

• Limitações no desenvolvimento da socialização do aluno.

• Limitações em alcançar objetivos na área afetiva e de atitudes, pelo empobrecimento

3.2 E-Learning Sı́ncrono X Assı́ncrono

4 Learning Management Systems (LMS)

• Educação a distância: realiza-se por diferentes meios (correspondência postal ou

• formato de educação a distância com suporte na internet. É muito utilizado por

Com isso, percebe-se que o modelo de Educação a Distância dentro do conceito de

5 Sharable Content Object Reference Model (SCORM)

6 Modular Object-Oriented Dynamic Learning En-

6.1 Caracterı́sticas do Moodle

6.1.1 Linhas gerais

• Adequado para aulas 100

• Simples, eficiente, compatı́vel, interface baseada em navegadores de tecnologia sim-

• Independência total da base de dados, suporta todas as principais marcas de base

• A lista de cursos mostra as descrições de cada curso existente no servidor, incluindo

• Cursos podem ser categorizados e pesquisados é um site Moodle pode suportar

• Ênfase em total segurança o tempo todo. Os formulários são todos checados, os

6.2 Recursos Adicionados ao Moodle

Figura 1: Gerenciamento de projetos no RUP (RATIONAL, 2001)

A finalidade do Gerenciamento de Projeto é:

• Fornecer um framework para gerenciar projetos intensivos de software;

• fornecer diretrizes práticas para planejar, montar a equipe, executar e monitorar os

• fornecer um framework de gerenciamento de risco.

• Gerenciamento de pessoal: contratação, treinamento, ensino;

• gerenciamento de orçamento: definição, alocação etc;

• gerenciamento de contratos, com fornecedores e clientes.

Essa disciplina enfatiza principalmente os aspectos importantes de um processo de

• planejamento de um projeto iterativo, por meio do ciclo de vida e de uma iteração

• monitoramento do progresso de um projeto iterativo, métricas para mensuramento.

Figura 2: Exemplo de processo em Engenharia de Software (??)

Um processo é um conjunto de passos parcialmente ordenados com a intenção de

8.1 Modelagem de Software

8.2 Programação Orientada a Objetos

8.3 Unified Modeling Language (UML)

1. Disponibilização de mecanismos de especificações que possam expressar os nı́veis

2. independência de processos de desenvolvimento e linguagens de programação;

3. incentivo do crescimento das aplicações desenvolvidas no conceito da orientação a