View - IFBa

Moodle
Uma Análise da Arquitetura de Software
ALMEIDA, K. N.
MOURA, I. C. M.
[email protected]
[email protected]
GSORT – Grupo de Sistemas Distribuídos, Otimização Redes e Tempo-Real
IFBa – Instituto Federal de Educação, Ciência e Tecnologia
Salvador - Bahia, Brasil.
Abstract— This article presents an architectural analysis of
the Moodle educational under the components-connectors view
and deployment view.
Keywords — component; connector; view; architecture;
deployment;
I.
INTRODUÇÃO
O Moodle (Modular Object-Oriented Dynamic Learning
Environment) [1] é uma aplicação destinada ao Ensino e
Aprendizado a Distância (EaD) utilizando a Internet como
forma de comunicação de múltiplas vias. Foi criado pelo
educador e cientista computacional australiano Martin
Dougiamas em 2001 motivado pelas limitações de sistemas
de gerenciamento de aprendizado existentes na época que
eram de código fechado e não atendiam requisitos
identificados por educadores e como parte de sua tese de
doutorado institulada "The use of Open Source software to
support a social constructionist epistemology of teaching
and learning within Internet-based communities of reflective
inquiry".
O nome vem do verbo da linguagem inglesa “to moodle”
que descreve o processo de navegar despretensiosamente por
algo enquanto outras coisas são feitas ao mesmo tempo.
Este artigo tem como objetivo analizar as decisões
arquiteturais buscando encontrar implementações de padrões
e estilos arquiteturais verificando como eles atendem os
requisitos funcionais e não-funcionais do sistema. Esta
análise apresentada duas visões arquiteturais do sistema, a
estrutural (componente-conector) e a visão de implantação e
discute os padrões e estilos encontrados nas duas visões.
Com o intuito de executar o trabalho proposto foi
necessário baixar o código fonte do projeto, a utilização de
ferramentas de software para leitura do código fonte, realizar
análises das estruturas de pacotes e classes e de documentos
encontrados na comunidade de contribuição ao projeto.
Apresentamos inicialmente um breve histórico do sistema
mostrando a motivação para a sua criação, pequenos detalhes
de sua instalação e algumas de suas características mais
importantes, focando nos requisitos funcionais e nãofuncionais.
Em seguida é apresentado o projeto arquitetural do
sistema com foco em dois view points, o estrutural, do qual
há um detalhamento dos componentes e conectores
identificados e o de implatantação. Essa análise arquitetural
pretende expor estilos e padrões arquiteturais presentes no
projeto do sistema e o rationale para cada um dos itens
identificados.
Logo depois serão detalhes de como foram realizados os
mapeamentos dos artefatos, além de detalhamento das
tecnologias encontradas e detalhes importantes da sua
implantação, assim como características e justificativas para
o modelo mapeado na análise realizada.
Por fim, o trabalho apresenta uma discussão dos aspectos
encontrados na análise comparando seus pontos e negativos e
mostrando ponto de melhoria.
II.
O MOODLE
Sistemas para Ensino a Distancia (EaD) são também
conhecidos como CMS (Course Management System), LMS
(Learning Management System) ou VLE (Virtual Learning
Environment). Como qualquer sistema web para ensino e
aprendizado a distancia deve possuir funcionalidades que
permitam colaboração entre seus usuários através da
Internet. Deve estar adequado tanto para aulas 100% on-line
quanto para aulas presenciais com demanda de suporte
continuado fora de sala. É necessário ênfase em segurança
através de mecanismos de autenticação e autorização, bem
como funcionalidades de postagem de conteúdo didático,
fórum de discussão entre outras.
É baseado na metodologia pedagógica sócioconstrutivista que é uma das correntes teóricas empenhadas
em explicar como a inteligência humana se desenvolve
partindo da ideia de que o homem não nasce inteligente, mas
também não é passivo sob a influência do meio e responde
aos estímulos externos agindo sobre eles para construir e
organizar o seu próprio conhecimento, de forma cada vez
mais elaborada.
O Moodle tornou-se muito popular entre os educadores
de todo o mundo como uma ferramenta para criação de sites
dinâmicos on-line para seus alunos. É gratuito e open source
(GPLv3+), construído para ser uma alternativa às soluções
comerciais. A plataforma Moodle [3] pode ser definida como
uma caixa de ferramentas modular para o desenvolvimento
de atividades e tarefas on-line e para a criação de
comunidades de aprendizagem.
A Figura 1 mostra um diagrama em blocos da estrutura
do Moodle do ponto da estrutura do sistema. Esse ponto de
vista será discutido melhor na próxima seção do artigo.
De operação simples possui como requisito técnico a
necessidade de um servidor web com suporte a linguágem
PHP (“PHP: Hypertext Preprocessor") e também um banco
de dados que será acessado via ODBC. O sistema Moodle
pode ser instalado em um servidor local, mas também
permite a instalação distribuída utilizando vários servidores
web, servidores de banco de dados e de arquivos com o
objetivo de atender demandas de alta escala [5].
CLIENTE
HTTP
MOODLE
SERVIDOR
LINGUAGEM DE SCRIPT (PHP/PYTON/PERL)
BANCO DE DADOS
SERVIDOR WEB
SISTEMA OPERACIONAL
L/W/M
A
M
P
Figura 1 – Arquitetura do Sistema Moodle
A. Requisitos não-funcionais
Esses são requisitos em termos gerais identificados por
restrições impostas de alguma forma ao sistema para atender
alguma necessidade do mesmo [7].
Foram identificados no Moodle e em sua documentação
alguns destes requisitos.
Usabilidade: o Moodle precisa suportar serviços
personalizados e automatizados e estes serviços
precisam estar disponíveis de maneira transparente a
usuários sem conhecimento profundo de informática.
Precisa ser fácil e intuitivo.
Disponibilidade: o sistema precisa estar disponível
para garantir que os usuários possam acessar o
material de estudos a qualquer momento. Deve ser
robusto para atender os diversos tipos de usuários ao
mesmo tempo [8].
Escalabilidade: deve ser possível expandir o sistema
para acomodar o crescimento futuro, não só no
volume de instruções, mas também na quantide de
usuários. [8]
Interoperabilidade: para suportar conteúdos de
diferentes formatos e fornecedores o sistema deve
trocar informações usando padrões abertos de
apresentação na web [8].
Segurança: Como qualquer solução colaborativa, o
Moodle deve limitar e controlar seletivamente o
acesso ao seu conteúdo e para isso define papéis, cada
um com seu conjunto específico de privilégios [8].
B. Requisitos funcionais
Pode ser integrado a outros sistemas tais como sistemas
de matrícula presencial das instituições de ensino que o
adotam, sistemas de pagamento e sistemas de
armazenamento de notas dos alunos do curso presencial.
Segundo [7], esses requisitos devem ser declarações de
funções fornecidas pelo sistema, como o sistema deve reagir
a entradas específicas e como deve se comportar em
determinadas situações.
O sistema Moodle [4] possui um núcleo com 42 pacotes
principais (na versão 2.5) que possuem papéis distintos na
arquitetura do sistema. Além destes pacotes básicos muitos
plug-ins podem ser instalados adicionando novas features ou
modificando o comportamento de outras já existente.
Configuração automática da lista de alunos
matriculados: O sistema deve ser capaz de obter a
lista de alunos da instituição através de alguma
conexão com o sistema de matrículas da instituição.
A maioria dos plug-ins ao ser instalados gravam seus
parâmetros em uma ou mais tabelas de configurações gerais
do banco de dados, com o intuito de que o núcleo do
software tenha controle sobre os pacotes adicionados.
Foram tomadas decisões arquiteturais na concepção do
Moodle para que o sistema pudesse ser construído de forma a
atender necessidades levantadas por pedagogos que
entendiam que os sistemas existentes, na época, não eram
flexíveis o bastante para atender demandas específicas e tais
demandas não podiam ser adicionadas por conta dos sistemas
serem fechados.
Então a arquitetura tentou atender entre outros requisitos,
os que são citados a seguir.
Possuir estruturas semelhantes a salas de aula: O
sistema deve ser capaz de ter um comportamento
semelhante a uma escola com disciplinas e tarefas.
Configuração de idioma de acordo com local onde for
instalado: o sistema deve ser configurável para
possuir o idioma do local onde ele for instalado.
Ser possível gravar cópia de segurança dos itens nele
gerados: o sistema deve ser possuir um subsistema de
backup que guarde toda a estrutura criada após sua
instalação.
Controlar a autenticação: o sistema deve ser capaz de
ativar plugin de autenticação e enviar mensagens de
confirmação de cadastro.
Controlar autorização: deve ser capaz de atribuir ou
excluir perfis de acesso, suspender contas de usuário,
acrescentar novos usuários nos papéis existentes e
permitir que usuários anônimos acessem áreas
públicas do portal.
Gerenciar cursos: deve ser capaz de manter os cursos
e as categorias destes, exibir e manter a relação dos
participantes, exibir cursos por usuários.
Gerenciar grade de notas: deve ser capaz de manter as
notas dos inscritos em cursos.
Disponibilizar fórum: deve ser possível manter fóruns
dentro do ambiente.
Prover mecanismos de pesquisa textual: deve ser
possível pesquisar por termos detro do conteúdo do
portal.
Manter menus: deve ser possível ativar e desativar
menus e configurar os menus de acesso geral e
restrito.
Manter conteúdo do portal: deve haver gestão de
conteúdo.
Configuração de conteúdo dinâmico: deve ser
possível gerenciar o conteúdo dinâmico em formato
HTML (HyperText Markup Language), gerenciável
pela interface de administração.
Publicação de contatos: permitir publicação de
contatos
com
possibilidade
de
escolher
individualmente para cada um se o mesmo será
público ou visível apenas a usuários registrados.
Permitir ainda o envio de mails para cada contato,
pelo internauta, diretamente através do sistema.
III.
ASPECTOS ARQUITETURAIS
Com objetivo de apresentar e detalhar a análise
arquitetural do sistema Moodle, mostrar padrões e estilos de
arquitetura encontrados e detalhar os principais componentes
e conectores presentes no sistema, foram escolhidas duas
views: a estrutural e a de implantação. Estas serão analisadas
detalhadamente explicando para cada um de seus aspectos o
seu rationale.
O Moodle é um sistema construído em camadas e com
módulos bem definidos específicos para cada tarefa a ser
realizada. Estes módulos podem ser estendidos ou
adicionados através de plug-ins.
A. Visão Estrutural
A Figura 2 mostra o view point estrutural de uma parte
significativa do sistema no qual podemos observar alguns
estilos e padrões arquiteturais, seus componentes e
conectores. Não estão exibidos todos os componentes,
apenas um grupo significativo.
A view estrutural está representando alguns dos 42
pacotes principais do sistema como componentes, banco de
dados, repositório de arquivos e os seus conectores
principais, e ainda demonstra algumas possibilidades de
conexão com sistemas externos e a adição de plug-ins, neste
caso como estensão do tema.
O funcionamento do sistema se inicia através de uma
requisição HTTP que é recebida pelo core e na grande
maioria é repassada para o componente admin para que ele
solicite do componente correto o serviço que precisa ser
executado para aquele processo.
No modelo que representa a visão estrutural do sistema,
conforme Figura 2, foram mapeados os seguintes
componentes:
Core: Representa um pacote de classes e subpacotes.
Este componente representa o pacote mais externo de
componentes, nele estão contidos quase todos os
outros componentes do sistema. Ele recebe do
servidor web a requisição HTTP via remote procedure
call e delega ao admin via conector procedure call
que ele resolva a requisição.
Admin: representa um pacote de classes que também
possui subpacotes. Recebe via procedure call uma
comunicação do core para que resolva uma
determinada requisição e retransmite para o pacote
especializado naquela tarefa solicitada na requisição.
Pode ser uma solicitação de exibição de um curso ou
uma solicitação de autenticação de usuário, por
exemplo.
Enrol: representa o componente que é responsável
pela matricula dos alunos nas turmas virtuais. Ele
recebe as informações a respeito dos alunos através
de um conector event que o notifica quando há
alguma modificação na relação de alunos
matriculados.
Este conector verifica essas
informações em um sistema externo de matrícula via
event. É possível notar a presença do estilo
arquitetural publish-subscribe nesse componente do
sistema.
Auth: representa o componente responsável pelas
regras de autenticação e autorização do sistema. No
momento em que o administrador do sistema adiciona
um novo usuário e aplica um papel ao mesmo,
quando este usuário tenta acessar o sistema se o
módulo exigir autorização a requisição do usuário e
seu papel são submetidos à análise do auth e só então
liberados. Os acessos a este módulo são via conector
procedure call.
Lang: também se trata de um componente que
gerencia os idiomas nos quais a interface com o
usuário do Moodle já possui tradução. O pacote de
idiomas é acessado pelo módulo admin através das
suas configurações de preferência e utiliza conectores
procedure call.
Grade: representa o componente que gerencia notas,
cálculos de média e modos quantitativos de avaliação
dos alunos, usualmente, médias de notas numéricas
das atividades realizadas, como subpackage do core
também tem acesso via procedure call.
Course: esse componente gerencia os cursos que
podem ser criados é acessado via procedure call e
internamente são criadas atividades, fóruns, enquetes,
entre outras e são adicionadas ao curso, todas as
chamadas são procedure call.
Event: o conector pode ser encontrado em diversos
componentes do sistema Moodle, na análise descrita
neste documento foram relatadas duas ocorrências,
nas quais o mesmo tipo de conector possui interações
diferentes com os componentes os quais ele liga.
Tema: este bloco representa um componente que
estende a funcionalidade theme do Moodle com
alguma feature que não existe no pacote default. É
um exemplo de plugin que provê novas features ao
sistema ou modificam o comportamento de features já
existentes. O plugin normalmente implementa o
padrão GOF (Gang of Four) Observer que é o
pradrão implementado quando não se deseja que os
objetos possuam forte acoplamento [2]. Sendo assim,
há uma aderência ao estilo arquitetural publishsubscribe, pelo comportamento do componente de
auto registrar-se no sistema. Além disso, um plugin
pode ser implementado pela própria comunidade ou
pode ser um componente COTS (Commercial Offthe-Shelf) disponibilizado por alguma plataforma a
fim de viabilizar a comunicação entre os dois
sistemas.
Na primeira situação o componente enrol precisa ser
sinalizado sobre mudanças nas matrículas no sistema de
cadastro de alunos então o publicador busca a informação no
sistema externo e notifica o enrol. Essa situação caracteriza
o serviço de comunicação e coordenação.
Repositório de Arquivos: é um componente que
gerencia os arquivos enviados ao sistema pelos
usuários obedecendo aos níveis de autorização de
cada usuário em particular o gerenciador desse
repositório pode ser o componente nativo do sistema
ou também pode ser usando um sistema COTS
através de plugins. A manipulação dos documentos
dentro da estrutura de repositório é realizada através
de conectores RPC (remote procedure call).
Backup: um componente que realiza as tarefas de
backup e restore da aplicação. Quando uma ação de
backup é disparada o componente verifica através de
componentes procedure call com o core quais os
módulos que integrarão o backup e via RPC obtém
todos dados necessários para a cópia de segurança.
Banco de dados: são componentes COTS,
responsáveis pelo armazenamento dos dados do
sistema, tanto dados de configuração quanto dados
disponibilizados para os usuários e pelos usuários.
Tem o acesso através de um conector data access +
RPC, provido por um conector híbrido arbitrator +
distributor que coordenam e facilitam o acesso a base
de dados distribuída.
Após detalhar os componentes representados no modelo,
serão detalhados os conectores mais encontrados.
Na segunda situação um novo tema precisa registrar-se e
mudar o comportamento da interface de usuário, então ele
utiliza uma composição de event para se registrar no sistema
e as chamadas para seu comportamente são procedure call.
Procedure call: estes conectores na view estrutural
exposta nesse artigo possuem o mesmo tipo de
comportamento e construção, tendo os valores das
suas dimensões iguais. Em relação aos parâmetros o
valor do data transfer é value, semântica é inline
parameters, invocation record é push from L to R,
quanto ao entry point é single, quanto a invocação
explicita é method call, quanto a sincronicidade é
synchronous e quanto a assecibilidade são públicos.
Remote procedure call: é um composite de distributor
com procedure call.
Data access: provê o serviço de comunicação e
possui os seguintes valores em suas dimensões:
Availability persistent database access, Acessibility
private. O conector data access possui outras
dimensões, mas a análise realizada nesse trabalho não
foi capaz de inferir sobre estas dimensões.
Distributor: está presente em composites com
procedure call e arbitrator. Possui os seguintes
valores em suas dimensões: quanto a dimensão
delivery, semantics at least once, mechanism unicast,
e quanto a dimensão routing o path é static.
Arbitrator: executa o serviço de coordenação no
balanceamento de carga das bases distribuídas.
Foram encontrados na análise desta view estrutural os
padrões arquiteturais em camadas e baseado em plug-ins.
Deduz-se que foi pensado durante a concepção do sistema o
padrão baseado em plugins para suprir a deficiência que
outros sistemas semelhantes traziam de não poderem criar
nem estender funcionalidades.
Os estilos de arquitetura encontrados foram os de
invocação explícita, publish-subscribe, object-oriented e
baseado em interpretadores, mobile code.
Figura 2 – Visão Estrutural do Sistema Moodle
B. Visão de Implantação
A Figura 3 mostra o view point de implantação do
sistema Moodle. Nesta view temos a implantação do sistema
com base de dados e componentes distribuídos.
A visão de implantação, ou deployment view, ajuda a
dispor os elementos físicos da instalação do sistema onde é
possível prever procedimentos operacionais para instalação e
ajuda a analisar possíveis problemas de disponibilidade,
performance, segurança entre outros aspectos.
Os components mostrados no diagrama de implantação
são os seguintes:
Document Repository: Esse componente é um plugin
COTS que provê o serviço de gerenciamento de documentos
que os usuários submetem, controlado pelas regras de
autorização do sistema Moodle. Está fisicamente instalado
em outro servidor por conta das operações de I/O que
poderiam sobrecarregar o processamento do servidor web.
Reporting Tool: ferramenta de criação de relatórios,
COTS, instalada num servidor web diferente e sendo
acessada via RPC + Adaptor que provê a interoperabilidade
entre os dois sistemas.
Database: Bases de dados replicadas instaladas em
servidores de dados distribuídos e acessadas via DataAccess.
+ distributor + arbitrator.
Billing System: sistema externo de gerenciamento de
pagamento que modifica as informações de alunos
requeridas pelo sistema Moodle.
Student Information Server: sistema que mantém os dados
dos alunos da instituição. O Moodle requisita as informações
mais atualizadas dos alunos através de um conector event.
Moodle Core: os módulos principais do sistema Moodle
integram o core que gerencia todos os módulos com apoio do
módulo admin e do Autentication Provider quando é
requerida alguma regra de autenticação ou autorização para
acesso a algum módulo.
Figura 3 – Visão Estrutural do Sistema Moodle (Servidores Distribuídos)
IV.
IMPLEMENTAÇÃO
A implantação fácil e a versatilidade do sistema devem-se
ao seu projeto arquitetural estar dividido entre o núcleo e os
plugins que funcionam de maneira integrada para oferecer os
serviços necessários ao funcionamento do ambiente.
Para implantação é necessário basicamente um servidor
web compatível com PHP e um banco de dados compatível
com ODBC. O acesso a este poderá ser realizado através de
script PHP através de código C/C++ ou mesmo de qualquer
outra linguagem que seja suportada pelo sistema.
A utilização do Request Dispatcher é um fator de
implementação conduzidos pelo projeto arquitetural e é o
que confere ao Moodle um controle fácil de requisicões. O
Moodle [7] utiliza abordagem “Cool URL don’t change” a
qual prega que a manutenção dos dados na URL, sem que ela
seja alterada por posteriores intervenções nas páginas ou
novas requisições é o que torna o funcionamento interno da
aplicação rastreável. Outra forma de manter os dados das
requisições por todo o ciclo de operações de um cliente sobre
o Moodle é a aplicação do Design Pattern Singleton. Este
padrão garante a existência de apenas uma instância de
uma classe, mantendo um ponto global de acesso ao
seu objeto e assim proporcionar um caminho padrão para a
troca de mensagens entre os componentes do projeto.
Também segundo [6], é recomendável que a base de
dados que se comunica com o core Moodle esteja à parte
do diretório raiz. Essa é uma proposta que visa
proporcionar maior controle sobre os dados trafegados no
ambiente virtual o que implementa um serviço de
segurança pela preservaçào de integridade desses dados,
característica esta proveniente da técnica de
descentralização de sistemas.
V.
CONCLUSÃO
O Moodle vem tendo sua base instalada amplida
significamente no mundo e despertando cada vez mais
interesse quanto a sistemas de ensino e aprendizado a
distancia, seja em instituições públicas ou privada.
Flexível e adptável pela decisão de adoção de novas
features através de plug-ins. Possuindo facilidade de
interface e integração com outros produtos e sistemas.
Utilizando a linguagem PHP que suporta um grande conjunto
de sistemas de banco de dados bem como suporte a HTTP e
a protocolos de sistemas de e-mails.
A Arquitetura Cliente-Servidor é outro ponto destacado na
avaliação. Permite que os papéis e responsabilidades de um
sistema de computação possam ser distribuídos entre vários
computadores independentes criando uma vantagem
adicional de manutenção e divisão de tarefas. Servidores
podem controlar melhor o acesso e recursos para garantir que
apenas os clientes com as permissões adequadas possam
acessar e alterar dados. Desde que o armazenamento de
informações é centralizada, as atualizações dos dados são
muito mais fáceis de administrar. A utilização desta
arquitetura também favorece a utilização do sistema por
vários e diferentes clientes com capacidade igualmente
diferente.
Estas características foram definidas em grande parte pela
decisão sobre a arquitetura de software e do sistema e
identificadas neste trabalho.
Há que mencionar o fato de que sistemas cliente-servidor
podem ter seus serviços indisponíveis seja por excesso de
requisições, por limitações do servidor ou por
indisponibilidade de banda de tráfego. Nesta arquitetura se
um servidor crítico falha, os pedidos dos clientes não
poderão ser atendidos. Desta forma questões relacionados ao
Sistema Operacional, hardware e manutenção do sistema
ganham grande importância dentro do processo de
implantação quanto a quesitos de disponibilidade.
Neste aspecto vem também o entendimento do ponto de
melhoria necessário com a consideração de implantação ou
migração do sistema para Nuvem (Cloud Computing). Nesta
Arquitetura os aspectos mencionados (sistema operacional,
hardware e manutenção) passam a ser geridos como
commodities contratado de provedores especializados na
prestação do serviço de hosting. De grande importância
também as questões relacionadas à infraestrutura (consumo
de energia, resfriamento e espaço físico) são melhores
gerenciados permitindo o uso mais racional dos recursos
naturais.
VI.
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
REFERENCIAS
RICE IV, William H., “Moodle E-Learning Course Development”, 2ª
ed, Packt Publishing, Birmingham, UK, maio 2006.
GAMMA, Erich, et al. Sneddon, “Padrões de Projeto, Soluções
Reutilizáveis de Software Orientado a Objetos” Porto Alegre,
BookMan, 2000.
Moodle. Disponível em http://pt.wikipedia.org/wiki/Moodle. Último
acesso em 02/06/2013.
COLE, J and FOSTER, H., “Using Moodle, Teaching with the
Popular Open Source Course Management System”, 2ª ed,
Sebastopol, CA, novembro 2007.
Moodle.
Disponível
em
http://moodle.progdan.com/mod/page/view.php?id=745.
Último
acesso 08/06/2013.
Horstmann, Cay, “The Architecture of Open Source Applications:
Elegnce, Evolution, and a Few Fearless Hacks”, vol. II.
SOMERVILLE, I., Engenharia de Software, 6ª ed, Addison-Wesley,
São Paulo, SP, 2004.
MoodleDocs.
Disponível
em
http://docs.moodle.org/all/pt_br?O_caso_Moodle. Úmtimo acesso em
08/06/2013.