Uma Arquitetura de Linha de Produto de Software para Ambientes Virtuais de Aprendizagem
Discente: Arthur Silva Paes Barreto dos Anjos / Orientador: Arturo Hernández Domínguez
TCC - Arthur Silva - CC.pdf
Documento PDF (9.2MB)
Documento PDF (9.2MB)
Trabalho de Conclusão de Curso
Uma Arquitetura de Linha de Produto de Software
para Ambientes Virtuais de Aprendizagem
Arthur Silva Paes Barreto dos Anjos
arthuranjos@gmail.com
Orientador:
Arturo Hernández Domínguez
Maceió, Agosto de 2011
Arthur Silva Paes Barreto dos Anjos
Uma Arquitetura de Linha de Produto de Software
para Ambientes Virtuais de Aprendizagem
Monografia apresentada como requisito parcial para
obtenção do grau de Bacharel em Ciência da Computação do Instituto de Computação da Universidade
Federal de Alagoas.
Orientador:
Arturo Hernández Domínguez
Maceió, Agosto de 2011
Monografia apresentada como requisito parcial para obtenção do grau de Bacharel em Ciência da Computação do Instituto de Computação da Universidade Federal de Alagoas, aprovada
pela comissão examinadora que abaixo assina.
Arturo Hernández Domínguez - Orientador
Instituto de Computação
Universidade Federal de Alagoas
Ig Ibert Bittencourt - Examinador
Instituto de Computação
Universidade Federal de Alagoas
Patrick Henrique Brito - Examinador
Instituto de Computação
Universidade Federal de Alagoas
Maceió, Agosto de 2011
Resumo
O trabalho consiste na criação de uma Linha de Produto de Software para Ambientes Virtuais de Aprendizagem. Seu principal objetivo é de criar um sistema que construa AVAs através
de uma infraestrutura comum e com características específicas. Os produtos criados pela linha
podem ser rapidamente desenvolvidos.
No contexto da Linha de Produto desenvolvida foi necessário realizar uma Engenharia de
Domínio para definir os artefatos comuns e as variabilidades, posteriormente foram usados técnicas de Engenharia da Aplicação para que as aplicações da linha de produto de software sejam
construídas através do reuso de artefatos e para que suas variabilidades específicas fossem implementadas.
Para a validação da LPS, foi criado um AVA que foi usado em um minicurso. Através desse
minicurso, foram obtidos resultados e conclusões sobre a LPS criada. A Linha de Produto de
Software desenvolvida possibilita o rápido desenvolvimento de AVAs com caracteríscas específicas. É possível através do AVA desenvolvido que os usuários participem de um curso de EAD
online.
Palavras-Chave: Linha de Produto de Software, Ambientes Virtuais de Aprendizagem,
Engenharia de Software Baseada em Componentes.
i
Abstract
This academic work consists in creating a Software Product Line for Virtual Learning Environments. Its main objective is to create a system that builds VLEs through a common architecture and with some specific features. The products created by the line can be quickly developed.
In the context of SPL (Software Product Line) was necessary to use a Domain Engineering to define common and variable artifacts of the product line, techniques from Application
Engineering like reuse of artifacts and specific variability developement were used to build the
applications of the software product line.
To validate the SPL, an VLE was created and it was used in a short course. Through this
short course, were obtained results and conclusions about the created SPL. The developed Software Product Line allowed the rapid development of VLEs with specific distinguishing feature.
It is possible that the users participate in a course of distance education through the VLE developed.
Keywords: Software Product Line, Virtual Learning Environments, Component Based
Software Engineering
ii
Agradecimentos
Agradeço a meus pais que sempre estiveram do meu lado para TUDO e sempre se esforçaram (as vezes mais do que deviam) pra que eu tivesse educação e uma boa formação, a meus
amigos de curso que me ajudaram em momentos que ficarão sempre guardados em minha memória.
Não posso esquecer de lembrar de Deus, que me deu essa vida e nunca deixou-me faltar
nada. E por último agradeço ao meu orientador e a todos os professores, companheiros de
trabalho e todos que me ajudaram nesse minha caminhada de curso.
iii
Conteúdo
Lista de Figuras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
vii
1
Introdução
1.1 Definição do Problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3 Estrutura do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
2
2
2
2
Fundamentação Teórica
2.1 Linha de Produto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.1 Plataformas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.2 Engenharia de Produtos Customizáveis . . . . . . . . . . . . . . . . .
2.1.3 Motivações do uso de Linhas de Produto . . . . . . . . . . . . . . . .
2.1.4 Definição . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.5 Processos de Desenvolvimento de uma Linha de Produto de Software .
2.1.6 Engenharia de Domínio . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.7 Artefatos de Domínio . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.8 Engenharia da Aplicação . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.9 Artefatos da Aplicação . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.10 Variabilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.11 Ponto de Variação . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.12 Variante . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.13 Definir Pontos de Variação e Variantes . . . . . . . . . . . . . . . . . .
2.1.14 Modelagem de Features . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.15 Variabilidade interna e externa . . . . . . . . . . . . . . . . . . . . . .
2.1.16 Classificação da Variabilidades . . . . . . . . . . . . . . . . . . . . . .
2.1.17 Diagrama de Variabilidade . . . . . . . . . . . . . . . . . . . . . . . .
2.1.18 Modelagem UML de Variabilidade . . . . . . . . . . . . . . . . . . .
2.2 Ambientes Virtuais de Aprendizagem . . . . . . . . . . . . . . . . . . . . . .
2.2.1 Princípios dos Ambientes Virtuais de Aprendizagem . . . . . . . . . .
2.2.2 Principais Ferramentas de um AVA . . . . . . . . . . . . . . . . . . .
2.2.3 Material Didático e interfaces do ambiente virtual . . . . . . . . . . . .
2.2.4 Exemplos de Frameworks de Ambientes Virtuais de Aprendizagem . .
2.2.5 Diferenças entre as abordagens de desenvolvimento . . . . . . . . . . .
4
4
4
4
5
6
6
7
9
9
11
11
12
12
12
12
13
13
14
15
15
16
17
18
19
20
3
Modelagem da Arquitetura de Linha de Produto de Software para AVAs
3.1 Diagrama de Casos de Uso . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 Diagrama de Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3 Definição dos componentes criados para a arquitetura . . . . . . . . . . . . . .
3.4 Arquitetura da Linha de Produto de Software . . . . . . . . . . . . . . . . . .
21
21
22
23
24
iv
CONTEÚDO
v
3.5
3.6
3.7
3.8
Gerenciador de Transações . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Gerenciador de Usuário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Gerenciador de Disciplina . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Gerenciador de Comunicações . . . . . . . . . . . . . . . . . . . . . . . . . .
24
26
29
34
Implementação da Arquitetura e Estudo de Caso
4.1 Informações técnicas sobre a implementação da Linha de Produto de Software .
4.1.1 Linguagem utilizada no lado do servidor . . . . . . . . . . . . . . . . .
4.1.2 Ferramenta para gerenciamento e automação de projetos . . . . . . . .
4.1.3 Framework MVC utilizado . . . . . . . . . . . . . . . . . . . . . . . .
4.1.4 Sistema Gerenciador de Banco de dados utilizado . . . . . . . . . . . .
4.1.5 Framework para controlar injeção de dependência, criação de beans e
conexão com o banco de dados . . . . . . . . . . . . . . . . . . . . . .
4.1.6 IDE utilizada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2 Criação de um AVA através da Linha de Produto de Software . . . . . . . . . .
4.3 Estudo de Caso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3.1 Telas de execução do AVA durante o estudo de caso . . . . . . . . . . .
39
39
39
40
40
40
5
Resultados obtidos e Discussão
5.1 Dificuldades encontradas . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2 Gráficos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
58
58
59
6
Conclusão
6.1 Considerações finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
62
62
62
4
Referências bibliográficas
41
41
42
45
45
64
Lista de Figuras
2.1
2.2
2.3
2.4
2.5
2.6
3.1
Diagrama com os subprocessos da Engenharia de Domínio. . . . . . . . . . . .
Diagrama com os subprocessos da Engenharia da Aplicação. . . . . . . . . . .
Variabilidade de componentes de uma LPS. . . . . . . . . . . . . . . . . . . .
Diagrama de Variabilidade de uma LPS. . . . . . . . . . . . . . . . . . . . . .
Diagrama UML de Variabilidade. . . . . . . . . . . . . . . . . . . . . . . . . .
Interação entre professor e aluno em um AVA. . . . . . . . . . . . . . . . . . .
Diagrama de Casos de Uso da Linha de Produto de Software para Ambientes
Virtuais de Aprendizagem. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 Diagrama de Features da Linha de Produto de Software para Ambientes Virtuais
de Aprendizagem. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3 Diagrama de Componentes da Linha de Produto de Software para Ambientes
Virtuais de Aprendizagem. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4 Diagrama de classes do componente Gerenciador de Transações. . . . . . . . .
3.5 Diagrama das classes de domínio do componente Gerenciador de Usuário. . . .
3.6 Diagrama de classes da interface do componente Gerenciador de Usuário. . . .
3.7 Diagrama de Variabilidade do componente Gerenciador de Usuário. . . . . . .
3.8 Diagrama das classes de domínio do componente Gerenciador de Disciplina. .
3.9 Diagrama de classes da interface do componente Gerenciador de Disciplina. . .
3.10 Diagrama de Variabilidade do tipo da disciplina. . . . . . . . . . . . . . . . . .
3.11 Diagrama de Variabilidade do tamanho da turma. . . . . . . . . . . . . . . . .
3.12 Diagrama de Variabilidade do upload ou não de arquivos. . . . . . . . . . . . .
3.13 Diagrama de Variabilidade da possibilidade ter ou não atividades. . . . . . . .
3.14 Diagrama de Variabilidade do status da atividade. . . . . . . . . . . . . . . . .
3.15 Diagrama das classes de domínio do componente Gerenciador de Comunicacao.
3.16 Diagrama das classes da interface do componente Gerenciador de Comunicacao.
3.17 Diagrama de Variabilidade da forma de comunicação. . . . . . . . . . . . . . .
3.18 Diagrama de Variabilidade do status da discussão. . . . . . . . . . . . . . . . .
3.19 Diagrama de Variabilidade do tipo da discussão. . . . . . . . . . . . . . . . . .
4.1 Alteração das permissões para permitir acesso dos usuários. . . . . . . . . . . .
4.2 Remoção do código para acesso do menu sobre o componente no AVA. . . . .
4.3 Execuçao do projeto para gerar o AVA. . . . . . . . . . . . . . . . . . . . . . .
4.4 Primeira parte do cadastro de um usuário no AVA. . . . . . . . . . . . . . . . .
4.5 Segunda parte do cadastro de um usuário no AVA. . . . . . . . . . . . . . . . .
4.6 Terceira parte do cadastro de um usuário no AVA. . . . . . . . . . . . . . . . .
4.7 Primeira parte do cadastro de uma disciplina no AVA. . . . . . . . . . . . . . .
4.8 Segunda parte do cadastro de uma disciplina no AVA. . . . . . . . . . . . . . .
4.9 Primeira parte da inscrição de um aluno em uma disciplina do AVA. . . . . . .
4.10 Segunda parte da inscrição de um aluno em uma disciplina do AVA. . . . . . .
vi
7
10
14
14
15
18
22
23
24
25
27
28
29
30
31
32
32
33
33
34
35
36
37
37
38
42
43
44
45
46
46
47
47
48
48
LISTA DE FIGURAS
4.11 Tereira parte da inscrição de um aluno em uma disciplina do AVA. . . . . . . .
4.12 Página Principal da disciplina do AVA. . . . . . . . . . . . . . . . . . . . . . .
4.13 Página de membros de uma disciplina do AVA. . . . . . . . . . . . . . . . . .
4.14 Página da atividades da disciplina do AVA. . . . . . . . . . . . . . . . . . . . .
4.15 Página de discussões de uma disciplina do AVA. . . . . . . . . . . . . . . . . .
4.16 Página de criação de uma discussão do AVA. . . . . . . . . . . . . . . . . . . .
4.17 Página Principal de um blog do AVA. . . . . . . . . . . . . . . . . . . . . . .
4.18 Página Principal da chat do AVA. . . . . . . . . . . . . . . . . . . . . . . . . .
4.19 Primeira parte da página de um tópico de discussão com comentários sobre o
minicurso de gestão finaceira. . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.20 Segunda parte da página de um tópico de discussão com comentários sobre o
minicurso de gestão finaceira. . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.21 Primeira parte de um tutor enviando uma mensagem para um usuário através de
uma discussão no minicurso de gestão finaceira. . . . . . . . . . . . . . . . . .
4.22 Segunda parte de um tutor enviando uma mensagem para um usuário através de
uma discussão no minicurso de gestão finaceira. . . . . . . . . . . . . . . . . .
4.23 Primeira parte da discussão estrurada sobre um arquivo postado no AVA sobre
o minicurso de gestão finaceira. . . . . . . . . . . . . . . . . . . . . . . . . . .
4.24 Segunda parte da discussão estrurada sobre um arquivo postado no AVA sobre
o minicurso de gestão finaceira. . . . . . . . . . . . . . . . . . . . . . . . . . .
4.25 Terceira parte da discussão estrurada sobre um arquivo postado no AVA sobre
o minicurso de gestão finaceira. . . . . . . . . . . . . . . . . . . . . . . . . . .
4.26 Primeira parte da discussão final sobre o minicurso de gestão finaceira. . . . . .
4.27 Segunda parte da discussão final sobre o minicurso de gestão finaceira. . . . . .
4.28 Terceira parte discussão final sobre o minicurso de gestão finaceira. . . . . . .
5.1 Gráfico que mostra a aceitação dos usuários sobre as ferramentas do AVA. . . .
5.2 Gráfico que mostra qual foi o componente de comunicação que os usuários mais
gostaram. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3 Nesse gráfico é mostrado a porcentagem de compreensão dos assunto ministrado no minicurso segundo dados fornecidos pelos usuários. . . . . . . . . . .
5.4 Expectativa dos usuários em relação ao assunto lecionado durante o minicurso.
5.5 Gráfico que informa o número de alunos que estariam dispostos a realizar outro
minicurso utilizando o AVA. . . . . . . . . . . . . . . . . . . . . . . . . . . .
vii
49
49
50
50
51
51
52
52
53
53
54
54
55
55
56
56
57
57
59
60
60
61
61
1
Introdução
A
I ndústria de produção de software está cada vez mais acirrada. A velocidade com que
novos softwares chegam ao mercado está bem maior que a 10 ou 20 anos atrás. É de
se destacar que os softwares no passado eram criados para consumidores individuais,
uma característica que eleva bastante o valor do produto final para o consumidor. Hoje o número de usuários que podem comprar produtos com maiores customizações aumentou bastante.
São esses fatores que levaram ao paradigma de Linha de Produto de Software ser introduzido
[1].
Através do uso das LPS (Linha de Produto de Software) é possível criar softwares de boa
qualidade com baixo custo de venda, softwares com complexidade de desenvolvimento menor,
oferecer uma maior flexibilidade na criação dos produtos e componentes, além do baixo custo
de manutenção, rapidez no desenvolvimento e na entrega de um software derivado da LPS [1].
A internet trouxe a grande parte da população novas formas de comunicar-se e informarse sobre as notícias de qualquer lugar do mundo. Hoje atráves do uso de um computador é
possível que uma pessoa de uma parte do mundo saiba o que aconteceu em outra localidade totalmente diferente em poucos minutos, ou em até presenciar o acontecimento em tempo real [2].
A EaD surgiu da necessidade do preparo profissional e cultural das pessoas que, por vários
motivos, não podiam frequentar um estabelecimento de ensino presencial, e evoluiu com as tecnologias disponíveis em cada momento histórico, as quais influenciam o ambiente educativo e
a sociedade [2].
Devido ao avanço das TICs (Tecnologias da Informação e Comunicação) no contexto da
EaD, foram criados os Ambientes Virtuais de Aprendizagem (AVA). AVAs são ambientes utili1
1.1. DEFINIÇÃO DO PROBLEMA
2
zados para facilitar ou promover a aprendizagem online [3]. Eles são acessíveis pela internet.
No contexto desse trabalho, é apresentada uma arquitetura de uma LPS para criação de
AVAs.
Com o uso da Linha de Produto de Software de Ambientes Virtuais de Aprendizagem,
espera-se reduzir o tempo para construir diferentes AVAs, com qualidade e baixo custo para o
cliente.
1.1
Definição do Problema
No contexto da EaD, é necessário construir uma solução de software que possibilite diminuir
o tempo de desenvolvimento de AVAs.
1.2
Objetivos
O objetivo deste trabalho é desenvolver uma Linha de Produto de Software para Ambientes
Virtuais de Aprendizagem. Os objetivos dessa LPS são:
• Rapidez - Diminuir o tempo de desenvolvimento de um AVA.
• Baixo custo - Reduzir o custo das aplicações derivadas da arquitetura da linha de produto
de software.
• Flexibilidade - As aplicações construídas pela LPS precisarão ser flexiveis dar suporte as
mudanças, isto será realizado via integração de componentes.
1.3
Estrutura do Trabalho
Este trabalho é composto de seis capítulos. O capítulo 2 é voltado para a fundamentação
teórica. Nele é mostrada a introdução a linhas de produto de software, suas principais caracteríscas, sua definição, conceito de plataforma, variabilidade, informações sobre Engenharia de
Domínio e Engenharia da Aplicação, uma introdução sobre Ambientes Virtuais de Aprendizagem e exemplos de alguns frameworks que criam AVAs.
Já o capítulo 3 é voltado para a modelagem da plataforma de software usada como base
para a LPS. Nesse capítulo são vistos as características da arquitetura desenvolvida usando o
paradigma de LPS e mostrado os componentes criados que formam a plataforma. O capítulo 4
é voltado para implementação e descrição do estudo de caso usado para validar a LPS.
1.3. ESTRUTURA DO TRABALHO
3
No capítulo 5, os resultados obtidos e a discussão são aprensentados com base no estudo de
caso realizado.
Por último, o capítulo 6 representa a conclusão onde abordará o fechamento com relação ao
trabalho desenvolvido nessa monografia.
2
Fundamentação Teórica
N
2.1
E ste capítulo será apresentada a fundamentação teórica desta monografia, isto é, Li-
nhas de Produto de Software(LPS) e Ambientes Virtuais de Aprendizagens(AVAs).
Linha de Produto
A maneira que novos produtos são criados e lançados tem mudado bastante com o passar
do tempo. Antigamente as mercadorias eram criadas para consumidores individuais. Porém a
quantidade de pessoas que podiam comprar produtos com as mais diversas variações aumentou
consideravelmente. Um bom exemplo de produção em massa está nos automóveis, que guiados
pela Ford seguiram o conceito de linha de produto. Com a criação das linhas de produto foi
possível baratear o custo de desenvolvimento dos produtos, aumentar a velocidade de criação e
oferecer uma maior flexibilidade na criação dos produtos e componentes [1].
2.1.1
Plataformas
A criação de produtos individuais e específicicos trazem a necessidade de maior investimento tecnológico e menores margens de lucro para a empresa. Devido a isso as companhias
criaram as plataformas genéricas. Essas plataformas possuem todo um conjunto de componentes predefinidos que servem como base para uma futura customização [1].
2.1.2
Engenharia de Produtos Customizáveis
Para a criação de produtos customizáveis é necessário agregar três processos que serão usados no desenvolvimento do produto. Abaixo cada processo está sendo brevemente descrito
[1].
4
2.1. LINHA DE PRODUTO
5
• Criação da Plataforma - Para a criação da plataforma é necessário primeiro focar no
que é comum a todos os produtos que serão criados. Depois focar nos diferentes artefatos
que poderão ser reusados por todos os produtos.
• Flexibilidade - Todos os artefatos devem suportar uma flexibilidade suficiente para que
sejam adaptados a diferentes produtos que sejam criados pela linha de produto. É necessário prover flexibilidade para termos uma alta customização. A flexibilidade usada em
linhas de produto de software é chamada de variabilidade.
• Reorganização de uma organização - A mudança de produção de produtos individuais
para produtos criados a partir de uma plataforma pode refletir em adições de novas unidades organizacionais. Em que uma unidade terá de se focar na construção da plataforma
e outra unidade se focará na construção dos artefatos que trarão variabilidade a linha. Essas unidades precisam ter constante interação para que tanto a plataforma criada como os
artefatos sejam compatíveis.
2.1.3
Motivações do uso de Linhas de Produto
O uso de Linhas de Produto tem vários benefícios que contribuem no desenvolvimento de
um produto. Abaixo são mostrados alguns desses benefícios:
• Redução do esforço de Manuntenção - Sempre que algum artefato é criado, atualizado,
ou corrigido ele é testado e propagado a todos os produtos criados pela linha de produto.
Devido aos inevitáveis testes, o trabalho com manuntenção é altamente reduzido pois o
artefato se encaixará perfeitamente ao produto.
• Evolução - Quando um novo artefato é introduzido na plataforma (ou é alterado) existe a
oportunidade de evoluir todos os produtos que foram criados a partir daquela plataforma.
• Menor complexidade - Devido a crescente necessidade dos consumidores, a complexidade dos produtos aumentam. Isso acontece principalmente em softwares, onde algumas
vezes o código e a complexidade crescem juntos. O uso de plataformas provém uma
estrutura em que artefatos reusáveis reduzem a complexidade e reduz a taxa de erro no
tempo de desenvolvimento.
• Facilidades para o cliente - Os produtos criados por uma linha de produto tem muito em
comum devido aos mesmos artefatos serem usados pela plataforma. Interfaces similares
ou iguais facilitam a curva de aprendizado do cliente, tornando assim a troca de um produto para outro mais fácil. O consumidor não precisa aprender novas maneiras de lidar
com outro produto derivado da mesma plaforma.
2.1. LINHA DE PRODUTO
2.1.4
6
Definição
Segundo o livro Software Product Line Foundations, Principles, and Techniques, de
Klaus Pohl, Günter Böckle e Frank van der Linden uma linha de produtos de software é definido como:
Definição - Linha de Produto de Software é um paradigma de desenvolvimento de aplicações usando plataformas e customização em massa.
A engenharia de um linha de produto de software lida com o gerenciamento de variações de
um produto.
2.1.5
Processos de Desenvolvimento de uma Linha de Produto de Software
O paradigma de desenvolvimento de software usando a abordagem de LPS consiste em dois
processos:
• Engenharia de domínio - Este processo é responsável por criar unma plataforma reusável e então definir os artefatos comuns aos pordutos da LPS. A plataforma engloba todos
os artefatos do software (requisitos, projeto, testes).
• Engenharia da aplicação - Este processo é responsável por derivar as aplicações da
plataforma criada a partir da engenharia de domínio.
A separação em dois processos favorece a variabilidade. A Engenharia de domínio é responsável por garantir que a variabilidade disponível é apropriada para produzir as aplicações. Isto
envolve mecanismos comuns para derivar uma aplicação específica. A plataforma é definida
com o máximo de flexibilidade para beneficiar o reuso em várias aplicações. Uma grande parte
da engenharia de aplicação consiste em reusar a plaforma e associar os artefatos necessários
para os diferentes produtos criados [1].
Definição - Engenharia de Domínio- Engenharia de Domínio é o processo de linhas de
produto de software em que os artefatos comuns e variáveis da linha de produto são definidos
e criados [1].
Definição - Engenharia da Aplicação- Engenharia da Aplicação é o processo de linhas de
produto de software em que as aplicações da linha de produto de software são construídos
através do reuso de artefatos e a suas variabilidades específicas são desenvolvidas [1].
2.1. LINHA DE PRODUTO
2.1.6
7
Engenharia de Domínio
Os principais processos da engenharia de domínio são:
• Especificar os aspectos em comum e os variáveis da LPS.
• Especificar o conjunto de aplicações para as quais a LPS foi planejada. O escopo da LPS
precisa ser definido aqui.
• Especificar e construir os artefatos que serão usados pela LPS para concretizar a variabilidade.
Existem também 5 subprocessos (ver figura 2.1) que contribuem para a engenharia de domínio.
Figura 2.1: Diagrama com os subprocessos da Engenharia de Domínio.
2.1. LINHA DE PRODUTO
8
Gerenciamento do Produto
Aqui é definido o escopo do produto, o que o produto abrangerá ou não [1].
Nesse subprocesso tem-se como entrada os objetivos da organização, o que ela pretende
obter. Como saída desse subprocesso a equipe de desenvolvimento terá um roteiro que dirá as
caracteríscas comuns e variáveis do produto, assim como as possíveis datas de desenvolvimento
e entrega do mesmo. É de se lembrar que com o gerenciamento do produto é possível obter uma
relação de de produtos ou artefatos que podem ser reusados na construção da plataforma [1].
Requisitos da Engenharia de Domínio
O subprocesso da engenharia de requisitos domímio engloba todas as atividades para produzir e documentar os requisitos comuns e variáveis da LPS [1].
Design do Domínio
O design do domínio engloba todas as atividades para definição da arquitetura da LPS.
Essa arquiteura comum definida nesse subprocesso proverá uma estrutura de alto nível para
todos os produtos criados pela LPS. A entrada desse subprocesso é formada pelos requisitos do
domínio e o modelo de variabilidade criado no subprocesso anterior. A saída será a arquiteura da
LPS e um modelo de variabilidade mais refinado (Nesse modelo serão incluídos especificações
técnicas das variabilidades) [1].
Implementação do Domínio
Com o desing do domínio já criado, é feito toda a implementação dos artefatos reusáveis
para a montagem da plataforma. Esse subprocesso é chamado de implementação do domímio. O resultado dessa fase consiste na criação de componentes fracamente acoplados. Cada
componente é planejado e implementado para o reuso em diferentes contextos [1].
Teste do domínio
Os testes do domínio são responsáveis por testarem e validarem cada componente criado
na etapa anterior. Os componentes são testados para ver se sua especificação coincide com
a função do componente implementado. Também nesse subprocesso são criados artefatos de
testes reusáveis que servem para diminuir o trabalho de testes. Há de se lembrar que não existe
nenhuma aplicação sendo testada nesse subprocesso, apenas componentes. A aplicação será
testada nos testes de aplicação [1].
2.1. LINHA DE PRODUTO
2.1.7
9
Artefatos de Domínio
Os artefatos de domínio são criados pelos subprocessos de engenharia de domínio. Eles
formarão a plataforma que será usada na linha de produto de software. Os artefatos criados são:
roteiro (criado no gerenciamento do produto), requisitos de variabilidade e suas modelagens
(criados na engenharia de requisitos do domínio), arquitetura da LPS e um modelo de variabilidade mais refinado (criados no design do domínio), componentes implementados (criados na
implementação do domínio) e os artefatos de testes (criados nos teste de domínio) [1].
2.1.8
Engenharia da Aplicação
Os principais objetivos do processo de engenharia da aplicação são:
• Obter o máximo de reuso das características do domínio quando definir e desenvolver
uma aplicação de uma LPS.
• Explorar os elementos comuns e variáveis da LPS durante o desenvolvimento de uma
aplicação.
• Documentar os artefatos da aplicação (requisitos da aplicação, arquitetura, componentes,
testes).
• Associar a variabilidade de acordo com as necessidades da aplicação.
• Estimar os impactos e diferenças entre requisitos da arquitetura, componentes e testes de
domímio e aplicação.
Os subprocessos que formam a engenharia da aplicação serão descritos na figura 2.2.
2.1. LINHA DE PRODUTO
10
Figura 2.2: Diagrama com os subprocessos da Engenharia da Aplicação.
Requisitos da Engenharia da Aplicação
Esse subprocesso engloba todas as atividades necessárias para a o desenvolvimento da especificação dos requisitos da aplicação. O reuso dos artefatos de domínio dependerão bastante
desse processo de coleta de requisitos. Portanto, através desse subprocesso será avaliado a capacidade da plataforma de prover o reuso ou não para a construção da aplicação. Tem-se como
entrada os requisitos de domínio e o roteiro do produto com os componentes da aplicação a ser
criada. Também serão considerados os requisitos que não foram incluídos na coleta de requisitos do domínio. A saída desse subprocesso corresponde aos requisitos para uma determinada
aplicação [1].
Projeto da Aplicação
O projeto da aplicação compõe todas as atividades para a criação da arquitetura da aplicação. Esse subprocesso utiliza a arquitetura base para instanciar uma arquitetura da aplicação.
O subprocesso seleciona e configura as partes necessárias para a adaptação da arquitetura da
aplicação. A entrada aqui consiste na arquiteura base criada no design do domínio e nos requisitos da aplicação a ser produzida. A saída será a arquitetura da aplicação para uma aplicação
específica [1].
2.1. LINHA DE PRODUTO
11
Implementação da Aplicação
No subprocesso de implementação da aplicação é criado a aplicação. As principais preocupações são a seleção e configuração dos componentes reusáveis e a implementação dos
componentes específicos da aplicação. Esse subprocesso tem como entrada a arquitetura da
aplicação e os artefatos reusáveis da plataforma. A saída consiste em uma aplicação criada a
partir dos artefatos da plataforma e dos artefatos específicos [1].
Teste da Aplicação
O teste da aplicação engloba as atividades necessárias para validar e verificar uma aplicação
de acordo com sua especificação. A entrada são todos os artefatos que a aplicação necessita
para rodar. A saída é um relatório com os resultados dos testes que foram executados [1].
2.1.9
Artefatos da Aplicação
Esses artefatos são compostos por todos os artefatos criados nos subprocessos da engenharia
da aplicação. Eles serão responsáveis por trazerem a variabilidade que aplicações distintas
necessitam. Os artefatos da aplicação são: requisitos para uma determinada aplicação (criados
engenharia de requisitos da aplicação), arquitetura da aplicação para uma aplicação específica
(criados no projeto da aplicação), aplicação criada a partir dos artefatos da plataforma e dos
artefatos específicos (criados na implementação da aplicação) e o relatório com os resultados
dos testes que foram executados (criados nos testes da aplicação) [1].
2.1.10
Variabilidade
Em linhas de produto de software variabilidade é uma propriedade fundamental dos artefatos
de domínio, pois através dela é possível dar um maior apoio ao desenvolvimento e ao reuso de
artefatos. Ela é introduzida no subprocesso de gerenciamento do produto quando os recursos
comuns e variáveis da LPS são identificados. Ela também é transitada nos subprocessos de
coleta de requisitos, design, implementação e teste de domínio. A seguir será mostrado os
principais conceitos de variabilidade em LPS. Existem dois tipos de variabilidade [1]:
• Variabilidade de um assunto - É um item variável do mundo real ou uma propriedade
variável de um item. Ex: A cor de um carro [1].
• Variabilidade de um objeto - É um instância particular de um sujeito variável. Ex: Como
a cor de um carro é um assunto variável, a cor vermelha será um objeto variável [1].
2.1. LINHA DE PRODUTO
2.1.11
12
Ponto de Variação
Os pontos de variação representam um subconjunto de todas as possíveis variabilidades de
um assunto de um mundo real, que são necessárias para implementar um determinado software
[1].
Definição - Ponto de Variação - Ponto de variabilidade é uma representação da variabilidade de um assunto de variabilidade dentro de artefatos de domínio enriquecido com suas
informações contextuais [1].
2.1.12
Variante
Variante é um termo em LPS que define uma representação de um objeto variável. Uma
variante idenfica uma única opção de um ponto de variação e pode ser associado com outros
artefatos para indicar que aqueles artefatos correspondem a uma opção particular [1].
Definição - Variante - Variante é uma representação de um objeto de variabilidade dentro
de artefatos de domínio [1].
2.1.13
Definir Pontos de Variação e Variantes
Os passos para definir os pontos de variação e suas variantes são brevemente descritos
abaixo:
• Indentificar um item do mundo real que possa variar.
• Definir um ponto de variação dentro do contexto de LPS.
• Com o ponto de variação definido, é necessário agora definir as variantes. A adição de
variantes provê a aplicação com instâncias específicas.
2.1.14
Modelagem de Features
A atividade de modelagem de features tem como finalidade descrever os requisitos da LPS
da perspectiva do usuário final, por meio de um modelo de features. Features podem ser descritas como conceitos, ou requisitos e características reutilizáveis de uma LPS (ver figura 2.3).
O conceito de feature é utilizado para fazer distinção entre os possíveis produtos de uma LPS,
definindo as funcionalidades comuns e variáveis de uma linha. Uma feature também pode se
referir a requisitos não-funcionais. Os artefatos de uma LPS podem ser chamados de features
[1].
2.1. LINHA DE PRODUTO
2.1.15
13
Variabilidade interna e externa
A variabilidade de um produto pode ser classificada também dessa forma, entre interna ou
externa. Os stakeholders somente enxergam a variabilidade externa. A interna somente é vista
pelos desenvolvedores. Um bom exemplo de variabilidade externa é as possíveis escolhas da
cor de um carro. Já um exemplo de variabilidade interna está na escolha de um algoritmo de
ordenação para listar as distâncias entre cidades num sistema de GPS [1].
2.1.16
Classificação da Variabilidades
As variabilidades podem ser classficadas como [GRISS et al, 1998; VAN GURP; BOSCH,
2001]:
• Obrigatórias - são características que estão sempre presentes e identificam um produto.
Por exemplo: uma característica efetuar pagamento em um sistema de e-commerce.
• Opcionais - são características que podem ou não estar presentes em um produto. Quando
presentes, adicionam algum valor relacionado às características obrigatórias de um produto. Por exemplo: a possibilidade de adicionar um cartão de aniversário na compra.
• Variáveis - são um conjunto de características semelhantes em que zero ou mais dessas
características podem ser selecionadas para estarem presentes em um produto. Por exemplo: a forma de pagamento, podendo ser on-line, cartão, boleto, entre outros.
• Externas - são as características oferecidas pela plataforma-alvo do sistema. Por exemplo:
o tipo de conexão do cliente, ou serviços fornecidos pelo provedor.
Dependendo do autor outros tipos de características são também incluídas, como:
• Mutuamente inclusivas - para que uma característica seja incluída, outras características
específicas devem ser também incluídas e vice-versa [4].
• Mutuamente exclusivas - para que uma característica seja incluída, outras características
específicas não devem ser incluídas e vice-versa [4].
2.1. LINHA DE PRODUTO
14
Figura 2.3: Variabilidade de componentes de uma LPS.
2.1.17
Diagrama de Variabilidade
Para reprensentar visualmente onde há variabilidade, e o que está variando é usado um diagrama de variabilidade (ver figura 2.4). Na qual é demostrado o ponto de variação e suas
possíveis variantes. Em uma pirâmide (pirâmide de variabilidade) é mostrado o ponto de variação (PV) e em retângulos é mostrado suas possíveis variantes (V) [5].
Figura 2.4: Diagrama de Variabilidade de uma LPS.
2.2. AMBIENTES VIRTUAIS DE APRENDIZAGEM
2.1.18
15
Modelagem UML de Variabilidade
Para modelar variabilidade é usado a notação de UML 2 (ver figura 2.5). A classe que representa um ponto de variação é uma classe abstrata que pode ser generalizada em variabilidade
interna e externa[6]. Uma dependência de variabilidade é uma classe formada da associação
entre uma variante e um ponto de variação. Essa associação informa que um ponto de variação
possui certos variantes. As regras de associação são as seguintes: Cada ponto de variação deve
ser associado a no mínimo uma variante, cada variante deve ser associado a no mínimo um
ponto de variação, um ponto de variação pode ter mais de uma variante e uma variante pode ser
associado a diferentes pontos de variação [1].
Figura 2.5: Diagrama UML de Variabilidade.
2.2
Ambientes Virtuais de Aprendizagem
A maneira de ensinar e aprender foi mudada no século XX devido ao avanço e os desenvolvimentos tecnológicos. Além disso, o intenso ritmo do mundo globalizado e a complexidade
crescente de tarefas que envolvem informação e tecnologia fazem com que o processo educativo
não possa ser considerado uma atividade trivial. Neste contexto, a demanda educativa deixou
de ser exclusividade de uma faixa etária que freqüenta escolas e universidades. A esse público
juntam-se todos os indivíduos que necessitam estar continuamente atualizados no competitivo
mercado de trabalho e/ou ativos na sociedade [7].
Nos últimos anos, os Ambientes Virtuais de Aprendizagem (AVAs) estão sendo cada vez
mais utilizados no âmbito acadêmico e corporativo como uma opção tecnológica para atender
esta demanda educacional [8]. Conceitualmente, um AVA pode ser definido como um meio que
utiliza o ciberespaço para veicular conteúdos com o objetivo de permitir a interação entre os
atores do processo educativo. Nessa proposta, a qualidade da educação não dependerá somente
2.2. AMBIENTES VIRTUAIS DE APRENDIZAGEM
16
dos professores e alunos, mas sim de um conjunto de ferramentas que permitirão o aprendizado
a distância. Também influenciam a qualidade de aprendizagem fatores como:
• Proposta pedagógica.
• Materiais veiculados.
• Estrutura e qualidade de professores, tutores, monitores e equipe técnica.
• Ferramentas e recursos tecnológicos utilizados no ambiente.
2.2.1
Princípios dos Ambientes Virtuais de Aprendizagem
Ambiente Virtual de Aprendizagem (AVA) consiste em uma opção de mídia que está sendo
utilizada para mediar o processo ensino-aprendizagem a distância. A Educação a distância
(EaD), conhecida também como Ensino a Distância, teve seu início sem data muito precisa,
porém pode-se assegurar que no século XVIII houve o oferecimento de cursos por correspondência. Impulsionado pelos avanços científicos e tecnológicos e pela demanda e necessidade
social, a oferta de cursos a distância aumentou e, novas mídias, à medida que apareceram, foram
utilizadas como suporte [8].
Segundo Crespo, Lucena e Schlemmer [CRE 1998], [LUC 2000] e [SCH 2002], três considerações fundamentais devem ser observadas em uma estratégia de avaliação de ambientes
virtuais de aprendizagem:
• Eles devem oportunizar a melhoria da qualidade da aprendizagem que não são passíveis
de realizar usando métodos convencionais.
• Devem suportar processos comunicacionais que propiciem alto grau de interatividade,
favorecendo o trabalho em equipe.
• Devem reduzir a sobrecarga administativa dos professores, permitindo a eles gerenciar
sua carga de trabalho mais eficientemente, possibilitando dessa forma a atenção para os
aspectos de cooperação e colaboração entre os participantes do ambiente.
Conforme Bastos [2003], as principais características da EaD estão relacionadas ao fato de
seus atores estarem separados geograficamente, ser vinculada a uma instituição educacional e
mediada pelas Tecnologias de Informação e Comunicação [7].
Na literatura nacional, entre os termos mais freqüentes relacionados a AVA pode-se citar:
Aprendizagem baseada na Internet, educação ou aprendizagem on-line, ensino ou educação a
distância via Internet e e-learning. Enquanto que, na literatura internacional, esta modalidade
2.2. AMBIENTES VIRTUAIS DE APRENDIZAGEM
17
de aprendizagem pode estar referenciada aos termos: Web-based learning, online learning,
Learning management Systems, Virtual Learning Environments, e-learning, entre outros
[7].
2.2.2
Principais Ferramentas de um AVA
Um AVA deve apresentar algumas ferramentas que contribuirão para a gestão do aprendizado e disponibilização de materiais [7]. Segundo Milligan [1999], essas ferramentas são:
• Controle de acesso - Geralmente realizado através de senha.
• Administração - Refere-se ao acompanhamento dos passos do estudante dentro do ambiente, registrando seu progresso por meio das atividades e das páginas consultadas.
• Controle de tempo - Feito através de algum meio explícito de disponibilizar materiais e
atividades em determinados momentos do curso, por exemplo, o recurso calendário.
• Avaliação - Usualmente formativa (como por exemplo, a auto-avaliação).
• Comunicação - Promovida de forma síncrona e assíncrona.
• Espaço privativo - Disponibilizado para os participantes trocarem e armazenarem arquivos.
• Gerenciamento de uma base de recursos - Como forma de administrar recursos menos
formais que os materiais didáticos, tais como FAQ e sistema de busca.
• Apoio - Como por exemplo, a ajuda on-line sobre o ambiente.
• Manutenção - Relativo à criação e atualização de matérias de aprendizagem.
Todas as ferramentas do eixo de comunicação visam apoiar discussões em atividades de
resolução de exercícios e problemas em um ambiente virtual. O uso maior ou menor dessas
ferramentas de comunicação depende da proposta pedagógica do curso. Contudo, em um ambiente virtual colaborativo, algumas dessas ferramentas comunicacionais, necessitam ser adaptadas para o uso coletivo por grupos individualizados.
Tais recursos e ferramentas, se disponibilizados e utilizados corretamente, permitem que
os participantes os utilizem para a interação, a colaboração e o suporte do processo ensinoaprendizagem. Contudo, a seleção de ferramentas e serviços oferecidos pela internet deve ser
realizada em função das necessidades do público-alvo e da proposta pedagógica do curso [7].
2.2. AMBIENTES VIRTUAIS DE APRENDIZAGEM
2.2.3
18
Material Didático e interfaces do ambiente virtual
Em um curso a distância, o processo de elaboração de material didático é diferente de um
curso com educação presencial com relação ao processo de elaboração de material didático,
pois demanda maiores esforços de concepção e produção. De acordo com Santos [1999], na
educação presencial o material didático "é um recurso de apoio à ação do professor, podendo,
inclusive, ser suprimido quando necessário"enquanto que na educação a distância assume o
papel de maior envergadura e de maior flexibilidade, à medida que, distanciados da presença
física do emissor de mensagens pedagógicas, os alunos têm nos recursos mediadores o principal,
senão o único, elemento instigador de interações com os conteúdos veiculados (ver figura 2.6).
Figura 2.6: Interação entre professor e aluno em um AVA.
Os AVAs provêem recursos para dispor grande parte dos materiais didáticos nos mais diferentes formatos, podendo ser elaborados na forma escrita, hipertextual, oral ou áudio-visual.
Esses podem ser trabalhados paralelamente por uma grande equipe e por grupos menores, no
qual todos os envolvidos devem acompanhar a preparação do material para que se possa fazer
maior uso das potencialidades e características de cada recurso tecnológico [7].
O uso de várias mídias, como vídeo, áudio, gráficos e textos, segundo Fahy [2004], apresenta diversas vantagens:
• Promove o desenvolvimento de habilidades e a formação de conceitos.
• Possibilita múltiplas modalidades de aprendizagem.
• Aumenta a interatividade.
• Faculta a individualidade, o estudante pode administrar seu tempo.
• Permite aos estudantes compreenderem melhor o conteúdo, pois utiliza gráficos, quadros
e esquemas e não apenas textos.
• Facilita a aprendizagem por meio das palavras utilizadas, simultaneamente, com os gráficos, as tabelas ou os quadros.
• Ajuda no aprendizado, pois utiliza animação e narração audível que é mais consistente
do que animação e texto na tela.
2.2. AMBIENTES VIRTUAIS DE APRENDIZAGEM
2.2.4
19
Exemplos de Frameworks de Ambientes Virtuais de Aprendizagem
Nessa seção serão brevemente descritos a nível de arquitetura três exemplos de frameworks
que possibilitam a criação de AVAs. O primeiro a ser mostrado será o FAmCorA, o segundo
será o FAVECI e o terceiro será o ArCo.
FAmCorA
O FAmCorA é um framework para o desenvolvimento de aplicações do tipo CSCL
(Computer-Supported Collaborative Learning), seja através do reuso dos provedores de serviços
(web services) implementados pelo framework, seja pelo compartilhamento de aplicações entre
vários sistemas. O framework está baseado na composição de um conjunto de tecnologias: cgi,
web services e agentes [9].
O FAmCorA busca contemplar as necessidades da construção de ambientes cooperativos
de aprendizagem através de um conjunto de aplicações provedoras de serviços (Web Services)
e de uma arquitetura que possibilita a comunicação inter-aplicações. Um provedor de serviço
está implementado com a tecnologia de Web Services; nesse sentido, no FAmCorA, o reuso
dá-se no nível do consumo de serviços (API/Application Program Interface), que podem residir
em qualquer parte da web, diferentemente do modelo de objetos ou componentes, nos quais
o reuso dá-se através do reaproveitamento de código. Porém o FAmCorA vai mais longe e
propõe o reuso de aplicações inteiras a partir de um protocolo de notificação que possibilita o
monitoramento e a troca de informações entre aplicações [10].
FAVECI
A abordagem de construção de software mais adequada no FAVECI é a da Inteligência Artificial Distribuída, ou seja, sistemas multiagentes. Esse framework possibilita que diversos
estudantes interajam de forma própria e assíncrona através do uso de agentes. Esses agentes
podem facilitar a comunicação e contribuir com a cooperação entre os estudantes, além de facilitar o acesso a informação relevante para o curso [11].
O FAVECI é desenvolvido seguindo os conceitos de Inteligência Artificial Distribuída (IAD)
mais recentes, baseia-se em uma arquitetura multiagente, onde cada agente tem seu comportamento definido em função dos seus objetivos específicos, e interage com outros agentes desta
sociedade diretamente (através de linguagens de comunicação inter-agentes), ou inderetamente
(através de mudanças do ambiente) [11].
2.2. AMBIENTES VIRTUAIS DE APRENDIZAGEM
20
ArCo
ArCo é um arcabouço extensível e de código aberto para a construção de ambientes de comunidades virtuais. A construção de ambientes utilizando o arcabouço é baseada no conceito de
montagem de componentes de prateleira (COTS) [Souza 1999], os quais encapsulam serviços
de comunidades virtuais conhecidos, tais como bate-papo, fórum, e-mail, busca e indexação de
conteúdo, dentre outros [12].
O arcabouço dispõe de ferramentas para a interação e colaboração de atores, componentes
de infra-estrutura e interface gráfica, além de suportar integração com outros sistemas através de
OpenLDAP [OpenLDAP 2004] e Web Services [Cerami 2002]. Utilizando o padrão arquitetural
de camadas funcionais, os componentes do arcabouço foram agrupados nas camadas de infraestrutura, camada de núcleo, ferramentas e interface gráfica unificada [12].
2.2.5
Diferenças entre as abordagens de desenvolvimento
Como foi visto nas abordagens de desenvolvimento descritas acima, todas elas usam o conceito de frameworks para desenvolvimento de AVAs. Este trabalho propõe que se crie uma LPS
para desenvolver AVAs. As diferenças que uma LPS possui em relação ao desenvolvimento
usando frameworks e ao orientado a componentes são mostradas a seguir:
• Define um processo para reúso. Esse processo é sistematizado e abrange tanto a construção de artefatos de software para reutilização como um processo de construção de
produtos com reúso desses artefatos [13].
• LPS contém uma arquitetura que é compartilhada por todos os produtos da linha. Frameworks também provêem uma arquitetura, porém essa arquitetura não é necessariamente central, pode ser responsável por um aspecto da aplicação como persistência [13].
• Admite outros artefatos além de código-fonte como artefatos de análise ou projeto [13].
3
Modelagem da Arquitetura de Linha de
Produto de Software para AVAs
A
A rquitetura de uma linha de produto de software é um dos grandes pontos-chave para
a construção de outras aplicações. Através da engenharia de domímio é projetada
uma plataforma comum que será usada na engenharia de aplicação para o desenvolvimento de diferentes aplicações em um domínio.
3.1
Diagrama de Casos de Uso
Os requisitos funcionais que a arquitetura [14] visa atender são mostrados através do diagrama de casos de uso (ver figura 3.1).
21
3.2. DIAGRAMA DE FEATURES
22
Figura 3.1: Diagrama de Casos de Uso da Linha de Produto de Software para Ambientes Virtuais de Aprendizagem.
3.2
Diagrama de Features
O diagrama de features da linha de produto modelada é mostrado na figura 3.2:
3.3. DEFINIÇÃO DOS COMPONENTES CRIADOS PARA A ARQUITETURA
23
Figura 3.2: Diagrama de Features da Linha de Produto de Software para Ambientes Virtuais de
Aprendizagem.
3.3
Definição dos componentes criados para a arquitetura
Para a criação da plataforma comum foram projetados 4 componentes que juntos formam o
esqueleto da plataforma. Esses componentes são: Gerenciador de Transações, Gerenciador de
Comunicações, Gerenciador de Usuário e o Gerenciador de Disciplina.
• Gerenciador de Transações - Esse componente é usado para controlar e estabelecer
todas as conexões com o banco de dados.
• Gerenciador de Usuário - O componente Gerenciador de Usuário foi criado com o intuito de controlar a criação e monitoração de usuários a serem usados no AVA. Através
desse componente, são definidas regras para os diferentes tipos de usuários.
• Gerenciador de Disciplina - Componente que controla a criação, e gerenciamento de
disciplinas e atividades ofertadas pelo AVA.
• Gerenciador de Comunicações - Esse componente provem os meios de comunicação
que os usuários do AVA (Ambiente Virtual de Apredizagem) usarão para interagirem.
Todos os 4 componentes criados para a linha de produto de software são obrigatórios. As
variabilidades opcionais ou variáveis estão em como os componentes serão usados na montagem
da aplicação.
3.4. ARQUITETURA DA LINHA DE PRODUTO DE SOFTWARE
3.4
24
Arquitetura da Linha de Produto de Software
Com os componentes projetados, a arquitetura da linha de produto de software tem os seguintes diagramas de componentes (ver figura 3.3):
Figura 3.3: Diagrama de Componentes da Linha de Produto de Software para Ambientes Virtuais de Aprendizagem.
3.5
Gerenciador de Transações
O componente Gerenciador de Trasações foi criado para controlar e estabelecer as conexões
entre o banco de dados e a aplicação criada pela linha de produto. Nesse componente foram
definidos e implementados diversos métodos genéricos que realizam transações com o banco de
dados. Entre os métodos criados estão métodos como: listar (esse método lista as entidades de
um determinado tipo de dados), consultar (método que busca no banco uma entidade através de
uma chave primária), inserir (persiste um objeto na base de dados) e excluir (apaga um objeto
da base de dados).
O componente Gerenciador de Transações é usado através da interface genérica GenericDao
[15] (ver figura 3.4). Nessa interface os métodos que fazem interações com o banco de dados
são definidos, e a classe abstrata HibernateGenericDao implementa a interface GenericDao. A
classe HibernateGenericDao extende da classe HibernateDaoSupport.1
1 Essa classe faz parte do framework Spring Object Relational Mapping, que usa os recursos do Hibernate para
mapear as classes com as tabelas do banco de dados.
3.5. GERENCIADOR DE TRANSAÇÕES
25
Figura 3.4: Diagrama de classes do componente Gerenciador de Transações.
Assim como a interface GenericDao, a classe HibernateGenericDao faz uso de Generics
(estrutura que possibilita a programação genérica). Os parâmetros passados como identificador
do Generics são: o tipo do objeto e uma chave primária (é usado como chave primária um objeto do tipo Long).
Na arquitetura da linha de produto, esse componente é considerado obrigatório, ou seja, ele
será um componente sempre presente na plataforma comum. Todos as aplicações que venham
a ser criadas a partir dessa linha possuirão esse componente.
3.6. GERENCIADOR DE USUÁRIO
3.6
26
Gerenciador de Usuário
O componente Gerenciador de Usuário tem a proposta de controlar a criação e monitoração
de usuários no AVA. Com esse componente, são definidas regras para os diferentes tipos de
usuários. Os tipos de usuário que podem ser criados através desse componente são: aluno, professor, tutor e administrador. Dentro do contexto do AVA cada tipo de usuário tem determinadas
regras de navegação e ações diferenciadas.
Um usuário do tipo aluno pode se inscrever em uma disciplina, interagir com um professor
ou com qualquer outro membro do AVA. Esse usuário também pode criar tópicos de discussão
relativos a uma disciplina, criar um blog e conversar com outros membros em um chat global.
Um usuário do tipo professor pode realizar ações semelhantes a de um aluno, sua única diferença é que ele não pode se inscrever em uma disciplina, mas criá-las e as ministrar. O tipo do
usuário tutor pode realizar as mesmas ações de um aluno, sua diferença está no propósito da sua
criação, que é ajudar outros alunos. Já um usuário do tipo administrador pode realizar qualquer
tarefa que os outros tipos de usuários podem. Esse usuário está apto a excluir outros usuários,
modificar tópicos, encerrar discussões e excluir disciplinas dentre outras funções.
3.6. GERENCIADOR DE USUÁRIO
27
Figura 3.5: Diagrama das classes de domínio do componente Gerenciador de Usuário.
O componente Gerenciador de Usuário possui as classes Usuario, TipoUsuario, Endereco,
Regra e Pessoa (ver figura 3.5).Esse componente faz uso do componente Gerenciador de Transações. Para acessar os recursos desse componente foi criado uma interface chamada de GerenciamentoUsuario (ver figura 3.6). Nessa interface foram definidos métodos de acesso, inserção
e controle as entidades que esse componente provém. A classe GerencimentoUsuarioImpl implementa a interface GerenciamentoUsuario.
3.6. GERENCIADOR DE USUÁRIO
28
Figura 3.6: Diagrama de classes da interface do componente Gerenciador de Usuário.
Como esse componente faz uso do componente de transacões, foi criado uma interface GenericDao para cada classe do domínio desse componente. Essas interfaces extedem a interface
GenericDao do Gerenciador de Transações. A classe GerencimentoUsuarioImpl faz uso dessas
interfaces para realizar as transações com o banco de dados.
Esse componente faz uso do framework Spring Security para gerenciar acessos e regras
de sistema para cada tipo de usuário [16]. Na arquitetura da linha de produto projetada ele é
considerado obrigatório, uma vez que o mesmo participa do domínio da linha.
3.7. GERENCIADOR DE DISCIPLINA
29
• Ponto de Variação - Usuário (ver figura 3.7).
• Variantes - Administrador, Aluno, Professor e Tutor.
• Classificação da Variabilidade - Alternativa.
Figura 3.7: Diagrama de Variabilidade do componente Gerenciador de Usuário.
3.7
Gerenciador de Disciplina
Componente que controla a criação, e gerenciamento de disciplinas e atividades ofertadas
pelo AVA. Com o auxílio desse componente podem ser criados disciplinas nas quais os membros
do AVA poderão se associar. As propriedades das disciplinas criadas através do Gerenciador de
Disciplina podem variar de acordo com a sua criação.
Em relação ao tamanho da turma, a disciplina pode variar de 10, 20 e 30 vagas, ou pode
também ter um número de vagas sem tamanho máximo. Quanto a possibilidade de qualquer
aluno ou tutor se associar a ela, a disciplina pode ser pública ou privada. No caso dela ser privada, será necessário uma senha para inscrição na mesma. Todas as disciplinas criadas poderão
possuir um conjunto de arquivos que serão enviados ou pelos alunos, ou pelo professor. Assim
como um professor poderá criar atividades para a disciplina.
As classes que formam o domínio desse da linha de produto são: Disciplina, Relacionamento, StatusAtividade, TamanhoTurma, TipoDisciplina, Atividade e Arquivo. (ver figura 3.8)
Assim como o Gerenciador de Usuário, esse componente faz uso do componente Gerenciador
de Transações para realizar as conexões com o banco de dados.
3.7. GERENCIADOR DE DISCIPLINA
30
Figura 3.8: Diagrama das classes de domínio do componente Gerenciador de Disciplina.
A interface que provém os métodos de acesso e controle das entidades relacionadas a disciplina é definida por GerenciamentoDisciplina (ver figura 3.9). Essa interface é implementada
pela classe GerenciamentoDisciplinaImpl. Também foram criadas as interfaces GenericDao
para cada classe do domínio desse componente. Essas interfaces também extedem a interface
GenericDao do Gerenciador de Transações.
3.7. GERENCIADOR DE DISCIPLINA
31
Figura 3.9: Diagrama de classes da interface do componente Gerenciador de Disciplina.
Esse componente utiliza o componente Gerenciador de Usuário para criar relacionamentos
entre as disciplinas e os membros do AVA.
3.7. GERENCIADOR DE DISCIPLINA
32
Os pontos de variação que esse componente fornece a linha de produto são os seguintes:
• Ponto de Variação - Disciplina ser aberta ao público (ver figura 3.10).
• Variantes - Aberta ou Fechada (necessidade de senha para matrícula).
• Classificação da Variabilidade - Alternativa.
Figura 3.10: Diagrama de Variabilidade do tipo da disciplina.
• Ponto de Variação - Tamanho da Turma (ver figura 3.11).
• Variantes - Pequeno (10 vagas), Médio (20 vagas). Grande (30 vagas) ou sem número
máximo de vagas.
• Classificação da Variabilidade - Alternativa.
Figura 3.11: Diagrama de Variabilidade do tamanho da turma.
3.7. GERENCIADOR DE DISCIPLINA
• Ponto de Variação - Upload e download de Arquivos (ver figura 3.12).
• Variantes - Possui ou Não possui.
• Classificação da Variabilidade - Opcional.
Figura 3.12: Diagrama de Variabilidade do upload ou não de arquivos.
• Ponto de Variação - Atividades referentes a Disciplina (ver figura 3.13).
• Variantes - Possui ou não possui.
• Classificação da Variabilidade - Opcional.
Figura 3.13: Diagrama de Variabilidade da possibilidade ter ou não atividades.
33
3.8. GERENCIADOR DE COMUNICAÇÕES
34
• Ponto de Variação - Status da Atividade (ver figura 3.14).
• Variantes - Aberta, Encerrada.
• Classificação da Variabilidade - Alternativa.
Figura 3.14: Diagrama de Variabilidade do status da atividade.
3.8
Gerenciador de Comunicações
Esse componente provem os meios de comunicação que os usuários do AVA (Ambiemte
Virtual de Apredizagem) usarão para interagirem. O uso desse componente na linha de produto
possibilita a inclusão de diferentes maneiras de estabelecer uma comunicação entre os membros
do AVA.
As formas de comunicação que o Gerenciador de Comunicações (ver figura 3.15) trazem
à linha são: comunicação via fórum através de tópicos de discussão, criação de um blog para
postar textos e novas idéias, envio de mensagens entre os participantes do AVA e comunicação
entre os participantes do AVA através de um chat.
As discussões criados por esse componente podem variar das seguintes maneiras: discussão
estruturada ou discussão normal. Uma discussão pode ter seu status de aberta, encerrada ou
aguardando a confirmação para a publicação. Nas mensagens das discussões estruturadas, será
possível fazer um comentário sobre a mensagem postada, enviar uma mensagem particular para
o usuário que postou a mensagem e também marcar a mensagem dizendo se concorda ou não
com o que foi escrito por outro usuário.
3.8. GERENCIADOR DE COMUNICAÇÕES
35
Figura 3.15: Diagrama das classes de domínio do componente Gerenciador de Comunicacao.
3.8. GERENCIADOR DE COMUNICAÇÕES
36
O acesso do Gerenciador de Comunicações se dá através da interface GerenciamentoComunicacao (ver figura 3.16). Essa interface é implementada pela classe GerenciamentoComunicacaoImpl. Esse componente faz uso do Gerenciador de Transações, Gerenciador de Usuário e
Gerenciador de Disciplina.
Figura 3.16: Diagrama das classes da interface do componente Gerenciador de Comunicacao.
3.8. GERENCIADOR DE COMUNICAÇÕES
Os pontos de variação que esse componente fornece a linha de produto são os seguintes:
• Ponto de Variação - Forma de Comunicação (ver figura 3.17).
• Variantes - Fórum, Blog, Chat e Mensagem.
• Classificação da Variabilidade - Alternativa.
Figura 3.17: Diagrama de Variabilidade da forma de comunicação.
• Ponto de Variação - Status da Discussão (ver figura 3.18).
• Variantes - Aberta, Encerrada ou Aguardando confirmação.
• Classificação da Variabilidade - Alternativa.
Figura 3.18: Diagrama de Variabilidade do status da discussão.
37
3.8. GERENCIADOR DE COMUNICAÇÕES
• Ponto de Variação - Tipo da Discussão (ver figura 3.19).
• Variantes - Normal ou Estruturada.
• Classificação da Variabilidade - Alternativa.
Figura 3.19: Diagrama de Variabilidade do tipo da discussão.
38
4
Implementação da Arquitetura e Estudo
de Caso
E
S te capítulo apresenta a descrição do estudo de caso, seu objetivo, como criar um AVA
através da linha de produto, informações técnicas da implementação da linha de produto desenvolvida.
Através de uma LPS, um cliente poderá ter produtos de alta qualidade, baixo custo e também
terá uma customização segundo sua preferência. Com a criação de uma LPS para AVAs será
possível construir AVAs com mais rapidez e qualidade. Os AVAs construídos pela LPS terão
toda uma base já criada anteriormente e alguns recursos exclusivos de acordo com a vontade do
cliente.
4.1
Informações técnicas sobre a implementação da Linha de
Produto de Software
Para a implementação da LPS, foram usadas diversas tecnologias. Nessa seção serão brevemente descritas as tecnologias usadas para construção da LPS.
4.1.1
Linguagem utilizada no lado do servidor
A linguagem escolhida foi Java. A versão usada do JAVA é a versão 6, é uma linguagem de
programação orientada a objetos criada pela Sun Microsystems. Diferentemente das linguagens
convencionais, que são compiladas para código nativo, a linguagem Java é compilada para um
bytecode que é executado por uma máquina virtual [17].
39
4.1. INFORMAÇÕES TÉCNICAS SOBRE A IMPLEMENTAÇÃO DA LINHA DE
PRODUTO DE SOFTWARE
40
Algumas características da linguagem: orientada a objetos, possui portabilidade, segurança,
sintaxe similar a C/C++ e é distribuída com um vasto conjunto de bibliotecas (ou APIs) [17].
4.1.2
Ferramenta para gerenciamento e automação de projetos
O Apache Maven é uma ferramenta para gerenciamento e automação de projetos em Java.
Ela é similar à ferramenta Ant, mas possui um modelo de configuração mais simples, baseado
no formato XML. Maven é um projeto da Apache Software Foundation.
Maven utiliza uma construção conhecida como Project Object Model (POM). Ela descreve
todo o processo de construção de um projeto de software, suas dependências em outros módulos
e componentes e a sua sequência de construção. O Maven contém tarefas pré-definidas que
realizam funções bem conhecidas como compilação e empacotamento de código [18].
4.1.3
Framework MVC utilizado
JavaServer Faces é um framework MVC para o desenvolvimento de aplicações Web, que
permite o desenvolvimento de aplicações para a internet de forma visual, ou seja, arrastando e
soltando os componentes na tela (JSP), definindo propriedades dos mesmos. A versão do JSF
usada é a 1.2 [19].
Algumas caracteríscas do framework: Permite que o desenvolvedor crie UIs através de um
conjunto de componentes UIs pré-definidos, fornece um conjunto de tags JSP para acessar os
componentes, reutiliza componentes da página e utiliza Ajax em alguns de seus componentes
tornando alguns processos mais rapidos e eficientes [20].
4.1.4
Sistema Gerenciador de Banco de dados utilizado
O SGBD usado foi o MySQL que utiliza a linguagem SQL (Linguagem de Consulta Estruturada, do inglês Structured Query Language) como interface. É atualmente um dos bancos de
dados mais populares, com mais de 10 milhões de instalações pelo mundo [21].
Características do MySQL: Portabilidade, compatibilidade (existem drivers ODBC, JDBC
e .NET e módulos de interface para diversas linguagens de programação, como Delphi, Java,
C/C++, C#, Visual Basic, Python, Perl, PHP, ASP e Ruby), excelente desempenho e estabilidade, pouco exigente quanto a recursos de hardware e é um Software Livre com base na GPL
[21].
4.1. INFORMAÇÕES TÉCNICAS SOBRE A IMPLEMENTAÇÃO DA LINHA DE
PRODUTO DE SOFTWARE
4.1.5
41
Framework para controlar injeção de dependência, criação de beans e conexão com o banco de dados
O Spring é um framework open source para a plataforma Java. Trata-se de um framework
não intrusivo, baseado na inversão de controle (IoC) e injeção de dependência. No Spring o
container se encarrega de instancia classes de uma aplicação Java e definir as dependências
entre elas através de um arquivo de configuração em formato XML, métodos e propriedades.
Dessa forma o Spring permite o baixo acoplamento entre classes de uma aplicação orientada a
objetos [22].
O Spring possui uma arquitetura baseada em interfaces e POJOs (Plain Old Java Objects),
oferecendo aos POJOs características como mecanismos de segurança e controle de transações.
Também facilita testes unitários e surge como uma alternativa à complexidade existente no uso
de EJBs. Esse framework oferece diversos módulos que podem ser utilizados de acordo com
as necessidades do projeto, como módulos voltados para desenvolvimento Web, persistência,
acesso remoto e programação orientada a aspectos [23].
Os módulos do Spring utilizados foram:
• Spring Transaction - Realiza uma integração com o hibernate para mapear as classes
com as tabelas do banco de dados [23].
• Spring Security - Controla as regras de acesso as páginas do AVA. Faz o gerenciamento
de login de um usário no sistema [24].
• Spring Beans e Spring WEB - Cria os beans para realizar a interação entre as páginas
da interface com os métodos escritos na linguagem JAVA e provém recursos ao projeto
de se tornar um sistema web [25].
4.1.6
IDE utilizada
Para implementação do projeto, foi usado a IDE Eclipse 3.6 Helios. Eclipse é uma IDE desenvolvida em Java, com código aberto para a construção de programas de computador. Possui
como características marcantes o uso da SWT e não do Swing como biblioteca gráfica, a forte
orientação ao desenvolvimento baseado em plug-ins e o amplo suporte ao desenvolvedor com
centenas de plug-ins que procuram atender as diferentes necessidades de diferentes programadores [26].
4.2. CRIAÇÃO DE UM AVA ATRAVÉS DA LINHA DE PRODUTO DE SOFTWARE
4.2
42
Criação de um AVA através da Linha de Produto de Software
Para a criação de um AVA usando a plataforma da linha de produto de software desenvolvida
são necessários os seguintes passos:
1. Todas as alterações para se gerar um novo produto através da linha serão aplicadas no
projeto lpsAva.
2. Definir com o cliente quais serão os meios de comunicação que serão usados pelo AVA.
3. O desenvolvedor precisa abrir o arquivo applicationContext-security.xml [16] e ir na tag
xml http (ver figura 4.1).
4. Nessa tag estão definidos as regras de navegação por tipo de usuário nas páginas do AVA.
Existem várias tags xml com o nome de intercept-url. Cada tag dessa está dando acesso
a um certo tipo de página para o tipo de usuário definido nela.
5. No campo acess da tag será posto somente ROLE_BLOQUEADO. Assim as páginas
que o AVA a ser criado não estiverem disponíveis serão bloqueadas para acesso. Ou
colocar ROLE_tipoDoUsuario para que o determinado tipo do usuário tenha acesso as
páginas. As possíveis roles são: ROLE_ADMIN, ROLE_TUTOR, ROLE_ALUNO e
ROLE_PROF.
Figura 4.1: Alteração das permissões para permitir acesso dos usuários.
4.2. CRIAÇÃO DE UM AVA ATRAVÉS DA LINHA DE PRODUTO DE SOFTWARE
43
6. Abra o arquivo menu.xhtml (ver figura 4.2). Dentro da tag rich:toolbar existem outras tags
rich:dropDownMenu, então remova (guarde as informações da tag em outro arquivo, caso
queira ativar o componente futuramente) a tag que se refere ao componente que não será
usado. Assim, não aparecerá links na aplicação do AVA para recursos não disponíveis.
Figura 4.2: Remoção do código para acesso do menu sobre o componente no AVA.
4.2. CRIAÇÃO DE UM AVA ATRAVÉS DA LINHA DE PRODUTO DE SOFTWARE
44
7. Depois de realizar esses passos, o AVA já pode ser criado. Então usando o eclipse (ou
outra IDE), execute o projeto em um servidor web (ver figura 4.3). Depois é só exportar
o novo AVA e usá-lo.
Figura 4.3: Execuçao do projeto para gerar o AVA.
4.3. ESTUDO DE CASO
4.3
45
Estudo de Caso
Para validação dessa linha de produto de software, foi criado um AVA com todos os componentes e recursos que a linha pode oferecer. O sistema contém como forma de comunicação
entre os usuários as features de blog, fórum, chat e mensagens. As disciplinas criadas podem
ser públicas ou privadas, as discussões são estruturadas e normais. As disciplinas criadas por
esse AVA terão a variabilidade de criar atividades.
Com a aplicação construída através da linha de produto, foi proposto um minicurso sobre
gestão financeira. Esse minicurso teve duração de 13/05/2011 até 19/05/2011 e sua metodologia
foi dividida em três partes, como é mostrado abaixo:
• Primeira parte - Momento presencial para explicação do assunto e de como se usar o
AVA. Essa aula teve duração de 1 hora.
• Segunda parte - Os alunos durante uma semana usaram o AVA para interagir com o
professor e outros alunos. Sendo através do AVA as dúvidas sanadas e o assunto compreendido. Também nessa segunda parte do minicurso, novos materiais foram postados no
AVA, para que os alunos pudessem lê-los e postar suas opiniões sobre o assunto.
• Terceira parte - Essa última parte foi novamente um momento presencial, na qual os
alunos relataram suas experiências sobre o AVA. Foi citado novas sugestões, críticas e
elogios sobre a aplicação.
4.3.1
Telas de execução do AVA durante o estudo de caso
Abaixo são mostrados as telas do AVA em funcionamento. Essas telas foram tirados durante
o minucurso de gestão financeira.
Figura 4.4: Primeira parte do cadastro de um usuário no AVA.
4.3. ESTUDO DE CASO
46
Figura 4.5: Segunda parte do cadastro de um usuário no AVA.
Nas figuras 4.4 e 4.5 são mostrados passos iniciais para um usuário se cadastrar no AVA.
Nesses passos o usuário fornece dados como CPF, endereço residencial, email, nome entre outros.
Figura 4.6: Terceira parte do cadastro de um usuário no AVA.
A figura 4.6 mostra o último passo do cadastro de um usuário no AVA. Nessa figura é mostrado o usuário escolhendo seu nome de usuário, senha e principalmente o tipo do usuário que
ele será no AVA: Aluno, Tutor, ou Professor.
4.3. ESTUDO DE CASO
47
Figura 4.7: Primeira parte do cadastro de uma disciplina no AVA.
A figura 4.7 mostra a um usuário do tipo Professor como proceder para cadastrar uma disciplina no AVA.
Figura 4.8: Segunda parte do cadastro de uma disciplina no AVA.
Já na figura 4.8 é mostrado o usuário fornecendo os dados sobre a disciplina a ser criada.
Dados como o tamanho da turma, se a disciplina será ou não aberta ao público são decididos
nessa parte de criação da mesma.
4.3. ESTUDO DE CASO
48
Figura 4.9: Primeira parte da inscrição de um aluno em uma disciplina do AVA.
Nas figuras 4.9, 4.10 são mostrados passos de como um Aluno deve fazer para se inscrever
em uma disciplina ofertada pelo AVA.
Figura 4.10: Segunda parte da inscrição de um aluno em uma disciplina do AVA.
4.3. ESTUDO DE CASO
49
A figura 4.11 mostra um aluno digitando a senha para inscrição em uma disciplina privada.
No minicurso de Gestão Financeira, a disciplina criada foi privada.
Figura 4.11: Tereira parte da inscrição de um aluno em uma disciplina do AVA.
O aluno ao inscrever-se em uma disciplina é rederecionado para página principal da disciplina criada (ver figura 4.12). Nessa página o usuário pode enviar ou baixar arquivos, ver quem
são os outros membros inscritos, enviar pergunta ao professor, ver as atividades criadas pelo
professor e as discussões criadas.
Figura 4.12: Página Principal da disciplina do AVA.
4.3. ESTUDO DE CASO
50
Figura 4.13: Página de membros de uma disciplina do AVA.
Nas figuras 4.13 e 4.14 é visualizado os membros da disciplina e sua atividades disponíveis.
Figura 4.14: Página da atividades da disciplina do AVA.
4.3. ESTUDO DE CASO
51
Figura 4.15: Página de discussões de uma disciplina do AVA.
A figura 4.15 mostra as discussões que foram criadas durante o minicurso de Gestão Financeira.
Figura 4.16: Página de criação de uma discussão do AVA.
A criação de uma discussão é mostrado na figura 4.16. É necessário fornecer dados como
título, disciplina associada, conteúdo da discussão e seu tipo: normal ou estruturada (caso a
variabilidade de tipo de discussão esteja presente no AVA).
4.3. ESTUDO DE CASO
52
A página principal de um blog criado para postar assuntos durante o minicurso é mostrada
na figura 4.17.
Figura 4.17: Página Principal de um blog do AVA.
A figura 4.18 mostra a página principal do chat durante o minicurso de Gestão Financeira.
Para login no chat é preciso escolher um apelido que não esteja sendo usado no chat.
Figura 4.18: Página Principal da chat do AVA.
4.3. ESTUDO DE CASO
53
Figura 4.19: Primeira parte da página de um tópico de discussão com comentários sobre o
minicurso de gestão finaceira.
Acima (ver figura 4.19) é visto uma tela de uma discussão relativa a uma atividade realizada
no período do minicurso. A figura 4.20 mostra os comentários dos alunos em relação ao tema
proposto na discussão.
Figura 4.20: Segunda parte da página de um tópico de discussão com comentários sobre o
minicurso de gestão finaceira.
4.3. ESTUDO DE CASO
54
Figura 4.21: Primeira parte de um tutor enviando uma mensagem para um usuário através de
uma discussão no minicurso de gestão finaceira.
Na figura 4.21 é visto um usuário enviando uma mensagem para outro usuário através de
uma discussão. É clicado no ícone que representa uma mensagem e então a página é redirecionada para a página de enviar mensagem.
Figura 4.22: Segunda parte de um tutor enviando uma mensagem para um usuário através de
uma discussão no minicurso de gestão finaceira.
O usuário escreve a mensagem e a envia ao usuário escolhido anteriormente (ver figura
4.22).
4.3. ESTUDO DE CASO
55
Figura 4.23: Primeira parte da discussão estrurada sobre um arquivo postado no AVA sobre o
minicurso de gestão finaceira.
Dentre os tipos de discussão criados, a discussão estruturada (ver figura 4.23) esteve presente no minicurso. Através dela, recursos como concordar ou discordar de uma mensagem
postada ficam disponíveis. Para concordar ou discordar de uma mensagem basta apenas clicar
no ícone que mostra uma mão com o sinal de afirmativo (concordar) ou negativo (discordar).
Figura 4.24: Segunda parte da discussão estrurada sobre um arquivo postado no AVA sobre o
minicurso de gestão finaceira.
Com a discussão estruturada é possível comentar uma mensagem postada anteriormente
por outro usuário, desde que ela não tenha recebido nenhum comentário (ver figura 4.24). A
figura abaixo (figura 4.25) mostra as outras mensagens postadas pelos alunos referentes a uma
discussão do minicurso.
4.3. ESTUDO DE CASO
56
Figura 4.25: Terceira parte da discussão estrurada sobre um arquivo postado no AVA sobre o
minicurso de gestão finaceira.
Essa última discussão (ver figuras 4.26, 4.27 e 4.28) tratou de coletar informações e opiniões
dos usuários sobre a compreensão dos assuntos abordados através do AVA.
Figura 4.26: Primeira parte da discussão final sobre o minicurso de gestão finaceira.
4.3. ESTUDO DE CASO
57
Figura 4.27: Segunda parte da discussão final sobre o minicurso de gestão finaceira.
Última parte das mensagens sobre os assuntos ministrados no minicurso de Gestão Financeira (ver figura 4.28).
Figura 4.28: Terceira parte discussão final sobre o minicurso de gestão finaceira.
5
Resultados obtidos e Discussão
C
O m o minicurso sobre Gestão Financeira Empresarial finalizado, foi possível obter
conclusões e alguns resultados sobre o uso do AVA criado através da Linha de Produto de Software. Essas considerações e resultados foram adquiridos com base em
um questionário que os 7 usuários (6 alunos e 1 tutor) do minicurso responderam após o término
do mesmo.
Através do questionário foi possível criar alguns gráficos sobre: se os usuários realizariam
outro minicurso a distância usando o AVA criado através da LPS, se houve compreensão total
do assunto abordado, se o minicurso atingiu as expectativas dos usuários inscritos, se gostaram
das ferramentas do AVA, entre outros.
5.1
Dificuldades encontradas
Alguns usuários tiveram dificuldade no início no uso do AVA, devido a maioria não ter
nunca realizado um curso a distância. Então eles tiveram um pouco de dificuldade para compreender o que seria e como funcionaria um AVA. A dificuldade de compreensão foi sanada no
momento presencial, na qual foi explicado o uso do AVA, suas funcionalidades e foi realizada
uma introdução sobre o minicurso que seria realizado.
A nível de desenvolvimento, a maior dificuldade encontrada foi na etapa de Engenharia
de Domínio. Aqui foi preciso definir cuidadosamente as variabilidades e as características em
comum do domínio da LPS. Essa etapa foi a mais trabalhosa pois através dela foi projetada a
arquitetura comum para as aplicações derivadas.
58
5.2. GRÁFICOS
5.2
59
Gráficos
Na figura 5.1 é mostrado a aceitação dos usuários com relação as ferramentas do AVA. Dos 7
usuários, 4 acharam boas, 2 acharam as ferramentas regulares e 1 usuário achou as ferramentas
do AVA ruim.
Figura 5.1: Gráfico que mostra a aceitação dos usuários sobre as ferramentas do AVA.
5.2. GRÁFICOS
60
Figura 5.2: Gráfico que mostra qual foi o componente de comunicação que os usuários mais
gostaram.
As figuras 5.2 e 5.3 trazem como resultados quais componentes de comunicação os usuários
mais gostaram e a porcentagem de compreensão do assunto lecionado. O componente que os
usuários mais gostaram foi o do fórum.
Figura 5.3: Nesse gráfico é mostrado a porcentagem de compreensão dos assunto ministrado no
minicurso segundo dados fornecidos pelos usuários.
5.2. GRÁFICOS
61
Figura 5.4: Expectativa dos usuários em relação ao assunto lecionado durante o minicurso.
A expectativa dos usuários com relação ao assunto lecionado durante o minicurso é mensurada de acordo com a figura 5.4.
Figura 5.5: Gráfico que informa o número de alunos que estariam dispostos a realizar outro
minicurso utilizando o AVA.
O gráfico (ver figura 5.5) mostram se os alunos que participaram do minicurso estariam
dispostos a realizar outro minicurso utilizando o AVA criado pela LPS.
6
Conclusão
E
6.1
S te capítulo tem como objetivo apresentar as considerações finais e trabalhos futuros
que surgirão após a criação da linha de produto de software para ambientes virtuais de
aprendizagem.
Considerações finais
Empresas e equipes de desenvolvimento de software podem perder muito tempo para decidir
qual paradigma ou modelo adequado de construção de software usar. E normalmente o tempo
é um aspecto fundamental no desenvolvimento de um software. Devido a alta competitividade
do mercado e necessidade de rapidez e qualidade, este trabalho mostrou que o uso de linhas de
produto de software pode ser uma das alternativas para enfrentar a demanda do mercado.
Com esse trabalho é possível que sejam criados diferentes AVAs de acordo com a necessidade do cliente. Com o uso dos AVAs, é possível que pessoas de qualquer parte do Brasil e do
mundo através de um computador conectado na internet possam participar de cursos de EAD
online.
Da maneira que o projeto foi criado, é possível desenvolver rapidamente um AVA devido
ao reuso. Esses AVAs possuem interfaces semelhantes que facilitam a adaptação do usuário e
possibilitam ao desenvolvedor um baixo esforço de manutenção.
6.2
Trabalhos Futuros
Como foi mostrado neste trabalho, a LPS desenvolvida pode ser uma alternativa rápida e de
qualidade para criação de AVAs. Como trabalho futuro, é possível que seja implementado novos
62
6.2. TRABALHOS FUTUROS
63
artefatos para a linha, como um componente de notificação e um componente de geração de log.
O componente de notificação informará os usuários sobre atualizações no AVA ou poderá
ser usado para informar ao usuário sobre novos tópicos, novas disciplinas. A notificação para o
usuário poderá ser feita tanto via uso do AVA ou via email. Já o componente de geração de log
registrará toda as atividades do usuário no AVA e gerará relatórios sobre a sua participação no
ambiente.
Referências bibliográficas
[1] K. Pohl, G. Böckle, and F. Van Der Linden. Software Product Line Engineering Foundations, Principles, and Techniques, 2005.
[2] Sistema educacional brasileiro - educação a distância.
http://www.di.ufpe.br/ fab/publications/semish99.ppt, Janeiro 2010. Acesso feito em 27
de Junho de 2011.
[3] C. Haguenauer, M. V. Mussi, and F. Cordeiro Filho. Ambientes virtuais de
aprendizagem: Definições e singularidades. Revista EDUCAÇÃONLINE, 3, 2009.
[4] L. A. Burgareli. Gerenciamento de Variabilidade de Linha de Produtos de Software com
Utilização de Objetos Adaptáveis e Reflexão. PhD thesis, Escola Politécnica da
Universidade de São Paulo, 2009.
[5] T. Ribeiro, W. Ataíde, and W. Soares. Linha de produto de software para sistemas de
portfólio-tutor. Trabalho de Engenharia de Software II do curso de Ciência da
Computação da Universidade Federal de Alagoas, 2009.
[6] D. Dermeval, J. Melo, J. Melo, and O. Holanda. Relatório de especificação de uma linha
de produto para sistemas tutores inteligentes. Trabalho de Engenharia de Software II do
curso de Ciência da Computação da Universidade Federal de Alagoas, 2009.
[7] A. T. C. Pereira, V. Schmitt, and M. R. A. C Dias. Ambientes Virtuais de Aprendizagem,
2005.
[8] S. C. C. S. Pinto, E. Schlemmer, C. T. Santos, C. C. Pérez, and L. R. Rheinheimer. Ava:
Um ambiente virtual baseado em comunidade. XIII Simpósio Brasileiro de Informática
na Educação - SBIE - UNISINOS, 2002.
[9] J. M. Pessoa and C. S. Menezes. Um framework para construção cooperativa de
ambientes virtuais de aprendizagem na web. XIV Simpósio Brasileiro de Informática na
Educação - NCE - IM/UFRJ, 2003.
64
REFERÊNCIAS BIBLIOGRÁFICAS
65
[10] J. M. Pessoa, H. V. Netto, and C. S. Menezes. Famcora: um framework para a construção
de ambientes cooperativos inteligentes de apoio a aprendizagem na internet baseado em
web services e agentes. XIII Simpósio Brasileiro de Informática na Educação – SBIE –
UNISINOS, 2002.
[11] A. Neves, F. Barros, and G Ramalho. Um framework para desenvolvimento de ambientes
virtuais de estudo cooperativo na internet.
http://www.di.ufpe.br/ fab/publications/semish99.ppt, 1999. Acesso feito em 27 de Junho
de 2011.
[12] H. O. Almeida, L. E. F. Tenório, N. M. Costa, E. B. Barbosa, and A. A. Bublitz, F.
M. Barbosa. Um arcabouço de software livre baseado em componentes para a construção
de ambientes de comunidades virtuais de aprendizagem na web. XV Simpósio Brasileiro
de Informática na Educação, 2004.
[13] Lince. Avaliação de técnicas voltadas para o reúso de software. PROJETO REÚSO DE
SOFTWARE - FAPESP, Junho 2010.
[14] A. Oliveira, D. Santos, L. Miranda, M. A. Pereira, and T.W. Tolêdo. Ava - ambiente
virtual de aprendizagem. Trabalho de Engenharia de Software II do curso de Ciência da
Computação da Universidade Federal de Alagoas, 2009.
[15] Generic data access objects. http://community.jboss.org/wiki/GenericDataAccessObjects,
2011. Acesso feito em 27 de Junho de 2011.
[16] L. Groner. Tutorial: Começando com spring security.
http://www.loiane.com/2010/01/tutorial-comecando-com-spring-security/, 2010. Acesso
feito em 27 de Junho de 2011.
[17] Oracle technology network for java developers.
http://www.oracle.com/technetwork/java/index.html, 2011. Acesso feito em 27 de Junho
de 2011.
[18] M. L. Aragão Junior. Automatizando seus projetos com o Maven 2, 2006.
[19] M. Katz. An introduction to jboss richfaces.
http://java.dzone.com/articles/an-introduction-to-jboss-richf?page=0,2, Agosto 2008.
Acesso feito em 27 de Junho de 2011.
[20] M. Katz. Jboss richfaces with spring.
http://java.dzone.com/articles/jboss-richfaces-spring?page=0,2, Fevereiro 2009. Acesso
feito em 27 de Junho de 2011.
REFERÊNCIAS BIBLIOGRÁFICAS
66
[21] Mysql:: The world’s most popular open source database. http://www.mysql.com/, 2011.
Acesso feito em 27 de Junho de 2011.
[22] L. Baxter III. Acegi/spring security integration – jsf login page.
http://ocpsoft.com/java/acegi-spring-security-jsf-login-page/, Outubro 2008. Acesso feito
em 27 de Junho de 2011.
[23] L. Lindermann. Integrando o Hibernate com o Spring, 2009.
[24] Spring security - discussão do fórum guj.
http://www.guj.com.br/java/131765-spring-security, 2011. Acesso feito em 27 de Junho
de 2011.
[25] Spring security - tutorial: Adding security to spring petclinic.
http://static.springsource.org/spring-security/site/petclinic-tutorial.html, 2011. Acesso
feito em 27 de Junho de 2011.
[26] Eclipse - the eclipse foundation open source community website.
http://www.eclipse.org/, 2011. Acesso feito em 27 de Junho de 2011.
