Ricardo Concilio            RA 974608

Resumo
        Este trabalho tem como tema a padronização no que se refere ao ferramental, a terminologia e aos serviços que talvez devessem ser disponibilizados em um ambiente educacional. Comenta de maneira sucinta os grupos do IEEE - P1484 Learning Technology Standards Committee (LTSC)  que tratam desse assunto e apresenta com maiores detalhes o estudo de caso baseado no grupo P1484.1 Architecture and Reference Model Working Group. Tomando como base o Modelo de Referência colocado por esse grupo, este trabalho apresenta um exemplo de modelagem.

1. Introdução
2. Grupos de Trabalho
3. Estudo de caso: Arquitetura
4. Exemplo de Modelagem
5. Conclusão
6. Referências Bibliográficas

1.) Introdução
        O desenvolvimento da padronização no ambiente educacional é prática recomendável, tendo como objetivo desenvolver, capacitar e habilitar a existência de ferramentas e serviços de informação para serem desenvolvidos com a finalidade de utilização no ensino.

        Pode-se colocar que tal padronização especificará um modelo de referência e arquitetura para sistemas baseados em Computer Aided Instruction (CAI), utilizando a aplicação de softwares como Intelligent Learning Environment (ILE) e Intelligent Tutoring System (ITS).

        Não se pode esquecer a necessidade de padronização da terminologia utilizada, de modo que:

• desenvolvedores de padrões de uma determinada área sejam capazes de se comunicar com outros de áreas diferentes, porém com a mesma finalidade;
• pesquisadores possam ser capazes de entender e usar como referência trabalhos de outros pesquisadores;
• educadores deveriam ter essa terminologia conhecida, tornando, portanto, o seu trabalho mais eficiente e eficaz;
• estudantes deveriam utilizar com facilidade essa terminologia beneficiando, assim, o próprio aprendizado.
 

• capacitar o estudante ou qualquer pessoa que deseja estudar (independente da idade, local de origem e conhecimento anterior) para criar e construir o seu próprio modelo de aprendizado;
• capacitar os desenvolvedores dos cursos que utilizam a tecnologia no aprendizado, a criarem um material mais personalizado e portanto de instrução mais efetiva dependendo do perfil do aluno em questão;
• possibilitar aos pesquisadores para que possam aumentar a base de dados do sistema, mas sempre seguindo os requisitos especificados na padronização.

        Estes grupos têm por objetivo o desenvolvimento de padrões, de linhas mestras e recomendar práticas comuns para a área do aprendizado baseado em computador, com a finalidade de capacitar ferramentas, desenvolver courseware, informações e serviços que seriam utilizados como base para os projetos implementados nesta área.

        O quadro abaixo especifica quais são os grupos de estudo:
 

P1484.1 Architecture and Reference Model Working Group
        Especifica um modelo de referência/arquitetura para sistemas de instrução baseado em computador, especificamente incluindo a necessidade de um ambiente inteligente de aprendizado e um sistema tutorial inteligente.

P1484.2 Learner Model Working Group
        Especifica a sintaxe e a semântica de um Learner Model, o que caracterizará o estudante, contendo seus conhecimentos e habilidades. Deveria permitir diferentes visões do modelo (alunos, professores, pais, empregadores, etc) e, ainda, discutir tarefas de privacidade e segurança.

P1484.3 Glossary Study Group
        Desenvolver definições padrão para todos os termos na área do aprendizado baseado em computador.

P1484.4 Task Model Working Group
        Este padrão especifica a sintaxe e a semântica de um Task Model, que caracterizará todos os aspectos estáticos de um projeto, incluindo a descrição das tarefas, os pré-requisitos necessários, funções dos membros, cronograma, recursos, objetivo do aprendizado, transmissão e taxação.

P1484.6 Session Management Working Group
        Especificar uma linguagem e um ambiente para o gerenciamento da tecnologia do sistema de aprendizado, ou seja, instrução auxiliada por computador, ambiente de aprendizado inteligente e sistema tutorial inteligente.

P1484.7 Tool/Agent Communication Working Group
        Consiste na aplicação de uma (ou mais) ferramentas do usuário de um (ou mais) agentes de instrução. Ferramentas do usuário são softwares aplicativos padronizados que o estudante utilizará no contexto do aprendizado (editores de texto e gráfico, planilhas, etc). Agentes de instrução são programas capazes de fornecer orientação para os estudantes ao usarem as ferramentas acima citadas.

P1484.10 CBT Interchange Language Working Group
        Tem por objetivo:

• definir a mídia envolvida no CBT (Computer Based Training), como áudio, vídeo, animações ou gráficos;
• recomendar e incorporar (na medida do possível) padrões de formatos de dados existentes
• definir (ou recomendar) uma linguagem que descreva a composição, os recursos e o comportamento lógico dos módulos do CBT, de maneira que eles possam trabalhar com diversas ferramentas de autoria.

• descrição do que está no curso;
• organização e seqüência das lições (sessões ou unidades);
• comunicação entre o software de gerenciamento das lições e as próprias lições;
• descrever os objetivos do curso relacionando-os com as lições;
• informar a performance do aluno.

P1484.13 Student Identifier Study Group
        O escopo deste grupo não se encontra disponível até a presente data. A seguinte mensagem é apresentada: "The scope of this proposed standard will be posted here soon".

        O P1484.1 Architecture and Reference Model Working Group propõe um Modelo de Referência em termos de hierarquia de níveis abstratos de arquitetura, assim a utilização deste modelo é possível no desenvolvimento e na organização da arquitetura de softwares aplicativos na área educacional.

        O tratamento dos níveis como categorias distintas mostra que conceitos dentro de cada um dos níveis são separados de outros pertencentes a outras camadas. Portanto, fica claro a necessidade do tratamento das tarefas de cada nível de maneira independente dos outros. Em resumo, um padrão construído com um conjunto de camadas faz com que cada uma delas seja bem conhecida, recebendo, dessa maneira um tratamento que dever ser particularizado.

        Cada nível tem um conjunto de conceitos e funcionalidades que devem estar presentes no projeto e no processo de padronização. Ao usar a abstração hierárquica como linha mestra para esse desenvolvimento, as tarefas devem ser tratadas distintamente, sendo separadas mais claramente (onde começam e onde terminam), incrementando a sinergia com outros padrões organizados hierarquicamente e aumentando o reuso. o que resulta em um padrão mais claro e modular.

        O Modelo de Referência e os seus níveis são apresentados no esquema a seguir:
 

Modelo de Aplicação: descreve o domínio (a área) da aplicação.
        Áreas de aplicação ou domínio incorporam a maneira de como fazer as tarefas e a maneira pela qual os conceitos devem ser compreendidos. Os conceitos, habilidades, o caminho do aprendizado e do pensamento, que são conhecidos pelos profissionais da área de educação, deveriam ser também do conhecimento dos desenvolvedores destes sistemas, de modo que estes conceitos pudessem ser utilizados no desenvolvimento dos sistemas  envolvidos com o aprendizado através do computador. Não se pode esquecer que o objetivo educacional em questão deverá estar bem definido e entendido por todas as partes envolvidas no processo.

        A padronização nesse nível deve possuir definições do material de ensino, do estilo de ensino, do professor e da interação dos padrões utilizados. Esta  camada deve guiar e fornecer material para padrões das outras áreas, isto é, as idéias podem fornecer a base para as técnicas de automação do material.

Modelo de Sistema Abstrato: descreve a percepção do usuário e o modelo conceitual do sistema.
        Tem dois aspectos: Modelo de Interação (descreve a aparência e as características de interação do sistema) e o Modelo Conceitual (incorpora as funcionalidades do sistema).
 
        O ser humano interage diretamente com o mundo através da sua percepção (os seus sentidos) e indiretamente pelo modelo conceitual que cria. O Modelo de Sistema Abstrato descreve a conceitução e a percepção do usuário em relação aos sistemas, definindo suas funções, suas características e tudo que afeta quem o estiver utilizando.

        Conforme já foi colocado acima, este modelo é dividido em duas partes distintas:

• Modelo de Interação: uma grande parte do sucesso de um sistema vem, efetivamente, da experiência do usuário ao interagir com o sistema. Esse tópico trata de como o ser humano pode e deve interagir com o sistema, incluindo o projeto da interface e a criação de metáforas de fácil percepção. Sendo bem projetado deve traduzir de maneira fiel o Modelo de Aplicação e possuir uma interface bastante fidedigna aos objetos utilizados e com as funcionalidades definidas no domínio, sendo que este modelo e sua interface podem ser reusados por aplicações com o mesmo domínio;
• Modelo Conceitual: a integridade de um sistema deriva da coerência das suas funcionalidades e das suas características. Este modelo pode definir classes de objetos e operações que trabalhem adequadamente com o domínio do sistema. Em geral, ele organiza a automação dos conceitos do domínio e fornece um guia para a implementação da arquitetura, também fornecendo uma maneira consistente para o usuário entender o sistema e como ele opera.

Modelo de Implementação Abstrata: descreve a estrutura da implementação, a arquitetura dos elementos e a comunicação entre eles.

        O Modelo Conceitual fornece o conteúdo das interações (funcionalidades) entre os usuários e os elementos do Modelo de Implementação Abstrata, já o Modelo de Interação fornece o significado destas interações.

        Nesse nível a comunicação é a mola mestra do reuso e da interoperabilidade, especificamente o uso de protocolos padronizados facilitam a troca, a adição e o reuso de componentes.
 

Modelo de Recursos: descreve os recursos empregados no sistema de acordo com o item anterior.

        Nesse nível são levadas em consideração a implementação e a performance (arquitetura e projeto) em um nível abstrato. O sistema é descrito em termos dos recursos usados e suas características, incluindo a performance de hardware e de software implementados, como também as limitações encontradas. Dessa maneira, são descritos os mecanismos necessários para implementar o sistema tendo a estrutura apresentada no Modelo de Implementação Abstrata (cabe o comentário que essa associação é geralmente complexa).

4.) Exemplo de Modelagem
        Modelo da disciplina de Computação oferecida com o auxílio do computador para alunos do ciclo básico e que não necessitam de conhecimento anterior para acompanhá-la. Além das aulas será também disponibilizado via rede exercícios, trabalhos e avaliações, sendo necessária, dessa maneira, senha individual para cada um dos alunos. É importante para a solidificação do aprendizado que a disciplina apresente exemplos relacionados com o mundo real e tenha ligação interdisciplinar com as outras do curso. O software implementado para atender essas especificações será utilizado em uma aula presencial, mas permitindo que dentro do período da aula, o aluno possa desenvolver conforme a sua velocidade de aprendizado. Também deve possuir a possibilidade de comunicação, via rede, entre professor-aluno e aluno-aluno. O ambiente desenvolvido deve permitir a utilização do recurso de link para endereços que tratem sobre o mesmo assunto e que possam ser usados como referência para estudo complementar.

Modelo de Aplicação: descreve o domínio (área) da aplicação.
        Os itens a seguir são necessários para a descrição deste modelo:

• definir os objetivos do curso: aprendizado de estrutura de programação utilizando linguagem visual;
• para atingir o objetivo colocado acima será apresentada a utilização de fluxograma para a solução dos problemas propostos;
• é necessário para o aprendizado o relacionamento de exemplos com o mundo real e com outras disciplinas do curso;
• disponibilizar via rede:
• aulas (envolve parte teórica, problemas resolvidos e exercícios propostos);
• avaliações (múltipla escolha, associação de itens e dissertativas);
• trabalhos mais elaborados.
• permitir correção automática das avaliações (quando possível);
• público alvo sem conhecimento anterior;
• possibilidade de comunicação entre os usuários;
• permitir link com endereços relacionados com o assunto em estudo.

• Modelo de Interação:
• possibilitar chat com o professor e com os colegas da sala;
• possibilitar link com outros endereços relacionados com o assunto em estudo;
• implementar as atividades definidas no Modelo de Aplicação.
• Modelo Conceitual:
• software trabalhará em aula presencial, sendo por vezes o trabalho do aluno em caráter colaborativo no sentido de ser possível a comunicação entre eles (mais provável durante os exercícios de aplicação) e por vezes sem a necessidade de comunicação (mais provável durante a exposição teórica).

• descrição de como implementar a estrutura apresentada nos itens anteriores e como fazer o gerenciamento entre os diversos aplicativos utilizados.

• recursos necessários sob o ponto de vista de software:
• ambiente de programação que atenda o domínio da aplicação: linguagem de programação visual;
• editor gráfico utilizado para a produção dos algoritmos que atendam aos exercícios e aos trabalhos  propostos;
• editor de texto para a elaboração de relatórios referentes aos trabalhos propostos;
• sistema operacional que suporte a utilização de ambiente de rede;
• mecanismo de segurança para o gerenciamento da senha dos alunos.
• recursos necessários sob o ponto de vista do hardware:
• ambiente de rede (servidor, usuários e impressora);
• canhão de projeção para projetar a tela do computador do professor para algum tipo de explicação coletiva.

        Nota-se que há diversas vantagens na adoção de um padrão para o modelamento da arquitetura:

• organização: mostra uma separação explícita nos diferentes projetos relativos às necessidades do sistema, arquitetura e padrões;
• comunicação: devido à natureza hierárquica do modelo, existe um entendimento melhor da arquitetura por todos os grupos de trabalho envolvidos no projeto;
• análise: seria fácil comparar as arquiteturas descritas. Se a hierarquia é bem utilizada, diferenças superficiais em um nível não esconderiam as semelhanças em outros níveis;
• reuso: quando a arquitetura é modelada em múltiplos níveis de abstração, pode-se optar pelo reuso do projeto em um ou mais níveis;
• adaptação: não é uma arquitetura padrão, mas sim um padrão que trata de arquiteturas. Dessa maneira não existe uma única correta e sim aquela que melhor se adapta às necessidades do projeto dentro de modelo estabelecido.

        Analisando o que foi colocado acima, nota-se a importância e a necessidade da construção de sistemas padronizados, uma vez que é desejável que todos estes sistemas possam se comunicar entre si. Dessa maneira, fica claro que características como reuso, operação independente de plataforma, performance, tempo gasto em projeto, custo, aquisição e retenção do conhecimento pelo alunado,  melhoria da qualidade de treinamentos e educação continuada seriam alguns dos pontos que poderiam ser melhor implementados e gerenciados.

        Todavia, estudos que tratam desse campo de ação são bastante recentes, o que demonstra ser esta uma área de pesquisa onde muito ainda está por ser produzido para alcançar todas as vantagens expostas acima.

6.) Referências Bibliográficas

• P1484 Learning Technology Standards Committee (LTSC)           URL:http://www.manta.ieee.org/p1484

• IEEE P1484.1 Architecture and Reference Model Working Group URL:http://www.manta.ieee.org/p1484/sg~rm.htm

• P1484.2 Learner Model Working Group                           URL:http://www.manta.ieee.org/p1484/sg~lm.htm

• P1484.3 Glossary Study Group                                             URL:http://www.manta.ieee.org/p1484/sg~dict.htm

• P1484.4 Task Model Working Group                                 URL:http://www.manta.ieee.org/p1484/sg~tm.htm

• P1484.6 Session Management Working Group                        URL:http://www.manta.ieee.org/p1484/sg~sm.htm

• P1484.7 Tool/Agent Communication Working Group  URL:http://www.manta.ieee.org/p1484/sg~tp.htm

• P1484.10 CBT Interchange Language Working Group  URL:http://www.manta.ieee.org/p1484/sg~cbtil.htm

• P1484.11 Computer Managed Instruction Working Group  URL:http://www.manta.ieee.org/p1484/sg~cmi.htm

• P1484.12 Learning Objects and Metadata Working Group  URL:http://www.manta.ieee.org/p1484/sg~lo.htm

• P1484.13 Student Identifier Study Group                     URL:http://www.manta.ieee.org/p1484/sg~si.htm

• Belz, F.; Suthers, D.; Wheeler, T.; Architecture Abstraction Hierarchy Reference Model September 18, 1997; URL:http://advlearn.lrdc.pitt.edu/its~arch/p1484/ARM.html

• Suthers, D.; Jones, D.; An Architecture for Intelligent Colaborative Educational Systems URL:http://advlearn.lrdc.pitt.edu/advlearn/papers/AIED97S.html