ENQUADRAMENTO CONCEPTUAL DE
ENSINO/APRENDIZAGEM PARA O
DESENVOLVIMENTO DE PROGRAMAS EDUCATIVOS

João Carlos Lopes Batista
Instituto Superior de Contabilidade e Administração de Aveiro
A. Dias Figueiredo
Laboratório de Informática e Sistemas Universidade de Coimbra
Portugal



Resumo

A identificação de alguns problemas na transição entre as fases de concepção e de desenvolvimento de programas educativos conduziu-nos ao desenvolvimento de um enquadramento conceptual de ensino/aprendizagem para aplicação nessa transição. Nesse enquadramento, que designamos por modelo das três entidades, são explicitamente caracterizadas as três entidades envolvidas na utilização de um programa educativo o aluno, o educador e o programa educativo , bem como a forma como as três entidades comunicam entre si. Este modelo é explorado para a aplicação prática através de uma outra proposta, a tabela de responsabilidades estendida, que permite especificar a interacção entre as três entidades. Esta tabela é construída na transição da fase de concepção para a fase de desenvolvimento de programas educativos e conduz à utilização de métodos orientados a objectos durante o desenvolvimento.

1. Introdução

As metodologias de produção de programas educativos [1, 2, 3] incluem duas fases: a fase de concepção e a fase de desenvolvimento. Na fase de concepção elabora-se um documento, designado por documento de concepção pedagógica, em que se estabelece uma definição do programa pretendido. Na segunda fase, a de desenvolvimento, é realizado o desenvolvimento do programa. O produto final das duas fases é o programa educativo. Alguns problemas impedem, em geral, que um programa assim produzido coincida com o programa pretendido.

Dois desses problemas constituem a motivação para este estudo. Por um lado, a atenção e o esforço na produção de um programa educativo direccionam-se apenas para um dos três intervenien-tes no contexto de utilização do programa, que é o próprio programa educativo, não se especificando os intervenientes restantes, o aluno e o educador, nem as interacções entre os três intervenientes.

Por outro lado, as dificuldades na transição entre as fases de concepção e de desenvolvimento são elevadas, o que se deve a dois factores: as técnicas utilizadas para a elaboração dos modelos das duas fases são substancialmente distintas; e a complexidade das concepções é crescente, implicando programas mais elaborados e a utilização, para o seu desenvolvimento, de métodos e técnicas mais sofisticadas.

Na secção dois deste artigo propomos um enquadramento conceptual, o modelo das três entidades, em que são explicitamente caracterizadas todas as entidades envolvidas no processo de aprendizagem realizado com recurso a programas educativos, bem como a forma como as entidades comunicam entre si. Este enquadramento visa suportar a transição entre as duas fases, facilitando as actividades de desenvolvimento. A aplicação prática do modelo das três entidades é descrita ao longo da secção três, em que propomos a tabela de responsabilidades estendida e os seus elementos de notação. A modelização do enquadramento conceptual e a transição entre as duas fases são realizados com recurso ao paradigma dos objectos [4, 5]. Por fim, na secção quatro, apresentamos as conclusões e as perspectivas deste estudo.

2. Modelo das três entidades


Figura 1 Diagrama de classes de um contexto restrito de ensino/aprendizagem

 Estas fronteiras permitem o estabelecimento de um princípio: todas as entidades envolvidas são caracterizadas, e o contexto de caracterização é comum a todas elas. Como a sua existência é explícita, não existe argumento para que a caracterização de cada uma das entidades não seja realizada2. Este princípio é importante porque a concepção e o desenvolvimento de programas educativos deixam de poder ser tratados isoladamente, passando a ser encarados como dizendo respeito a uma de três entidades, todas elas importantes, que devem interagir e colaborar no processo de aprendizagem dos alunos.
 

Entre as classes Aluno e Educador pode existir um relacionamento de hereditariedade. A existência ou não desse relacionamento resulta, em particular, de cada contexto restrito de ensino/aprendizagem. Por exemplo, na concepção Dice Calculation3, as propriedades e o comportamento da classe Educador também se encontram presentes na classe Aluno. O diagrama de classes representado na figura 1 evolui então para o representado na figura 2, em que se observa que a classe Aluno é descendente, ou herdeira, da classe Educador.


Figura 2 Diagrama de classes de um contexto restrito de ensino/aprendizagem
em que a classe Aluno é descendente da classe Educador, como indicado pela seta

Este relacionamento de hereditariedade permite evidenciar a caracterização da classe Educador, por um lado, e o facto de esta não possuir, no âmbito do contexto restrito de ensino/aprendizagem, características internas ou externas que o aluno também não possua. Permite evidenciar também que, além das características do educador, o aluno possui outras.

  • 2.3. Diagrama de objectos

  • Cada instância de uma classe é um objecto. No contexto restrito de ensino/aprendizagem consideram-se objectos para cada uma das três classes, representando-se esses objectos através de um diagrama de objectos. Neste, além dos objectos, representa-se também a forma como comunicam, através de mensagens, como se pode observar na figura 3.

    Figura 3 Diagrama de objectos de um contexto restrito de ensino/aprendizagem em que são representados os objectos do contexto e as trocas de mensagens entre eles4


    Num contexto restrito de ensino/aprendizagem existem normalmente um objecto da classe Programa_Educativo, um outro da classe Educador e um ou mais da classe Aluno. No diagrama de objectos da figura 3 são representados dois objectos da classe Aluno. Entre todos estes objectos, a comunicação é realizada através de trocas de mensagens. No âmbito deste estudo, não se caracterizam as mensagens que se processam entre os seres humanos, ou seja, entre objectos das classes Aluno e Educador.

    O diagrama de objectos da figura 4 ilustra o contexto restrito de ensino/aprendizagem do Dice Calculation. Neste programa são consideradas uma instância da classe Programa_Educativo, uma da classe Educador e uma ou duas da classe Aluno. No caso concreto da figura apresentada, são considerados dois jogadores.



    Figura 4 Diagrama de objectos de um contexto restrito de ensino/aprendizagem em que é utilizado o Dice Calculation por dois alunos orientados por um educador. A comunicação entre os quatro objectos processa-se através de trocas de mensagens

  • 2.4. Simetria na comunicação

  • O modelo básico de comunicação que tem sido utilizado na concepção de programas educativos baseia-se num ciclo em que a uma acção do aluno corresponde uma reacção do programa, e assim sucessivamente [2]. Este modelo restringe a interacção entre os objectos presentes num contexto restrito de ensino/aprendizagem, dado que o fluxo de controlo se dirige apenas num sentido.

    Através das figuras 3 e 4 pode observar-se que na proposta aqui defendida as mensagens são sempre representadas nos dois sentidos, o que significa que a comunicação deve ser dialogante. Este modelo de comunicação subjacente ao modelo das três entidades é representado na figura 5. Pela sua observação verifica-se que a uma acção de um objecto, que é identificada pelo envio de uma mensagem, se segue uma reacção de outro objecto que determina a sua próxima acção, que é também identificada pelo envio de uma mensagem, e assim sucessivamente.

    Este modelo de comunicação é extensível a um número superior de objectos. Nessas condições, o envio de uma mensagem por parte de um objecto não tem, obrigatoriamente, de ser dirigido ao objecto do qual recebeu a última mensagem.

    O que permite esta evolução do modelo é o facto de a comunicação se verificar através de mensagens, e não apenas através de comandos. Com o conceito de mensagem, o diálogo torna-se explícito. Neste diálogo, o aluno deve possuir controlo, nomeadamente no que respeita à escolha do percurso de aprendizagem. No entanto, o programa educativo também possui o seu próprio controlo. A comunicação entre objectos é, assim, baseada em diálogo, e não na utilização arbitrária de algo, o programa educativo, que responde impassivelmente às ordens e aos comandos que recebe.


     
     


    Figura 5 Modelo de comunicação entre objectos, em que todos os objectos envolvidos são, fundamentalmente, agentes5, dado que todos enviam e recebem mensagens

    A defesa que aqui se faz de que o programa educativo assuma a sua quota parte de responsabilidade no controlo do diálogo não deverá ser entendida como correspondendo a uma diminuição da capacidade de controlo do aluno. Pelo contrário, corresponde à previsão, no modelo, de uma interacção mais simétrica6 do programa educativo no controlo do diálogo, tendo em vista permitir ao aluno o exercício de formas superiores de controlo.
    3. Tabela de responsabilidades estendida

    O modelo das três entidades estabelece um enquadramento conceptual para um contexto restrito de ensino/aprendizagem em que são usados programas educativos. Não é claro, até agora, como se aplica este modelo na prática. Para isso, propomos a tabela de responsabilidades estendida, em que se caracterizam cada classe e as mensagens entre os objectos dessas classes. Propomos ainda uma notação a utilizar na construção dessa tabela.

  • 3.1. Responsabilidades

  • A tabela de responsabilidades estendida que aqui propomos é uma extensão da tabela de responsabilidades de Crossley e Green [2]. Nesta consideram-se três colunas, uma para cada classe: o aluno, o educador e o programa educativo. Em cada coluna, exprime-se quem faz o quê [2], ou seja, o conteúdo dessa tabela é relativo às acções que cada entidade toma.

    Crossley e Green apresentam dois outros documentos importantes: a tabela de comandos/condições, em que se exprimem as condições em que cada comando pode ser utilizado; e a tabela de comandos/reacções, em que se apresentam as reacções do programa a cada um dos seus comandos. Estas tabelas são substituídas, em [3], por um diagrama de estados.

    Se forem considerados todos estes documentos, verifica-se que estão expressas as funções externas de cada entidade, bem como os estados do programa educativo. A tabela de responsabilidades estendida baseia-se nessas informações e completa-as com os atributos das três classes. Obtém-se, assim, uma caracterização mais completa das três classes. Além disso, e dado que o modelo das três entidades se baseia no paradigma dos objectos, estabelece-se uma especificação da comunicação entre os objectos do contexto restrito de ensino/aprendizagem, através de mensagens explícitas e implícitas.

    A tabela de responsabilidades estendida apresenta-se em três colunas, uma por cada classe. Para cada uma, indica-se a sua cardinalidade, ou seja, o número de objectos de cada classe. Por exemplo, para o Dice Calculation, a cardinalidade das classes Educador e Programa_Educativo é unitária e a da classe Aluno é de um a dois.
     

  • 3.2. Cenários

  • Ao longo das linhas representa-se aquilo que aqui se convencionou chamar cenários, que se procuram na concepção. A divisão em cenários é uma forma de decompor o contexto em partes menores, com que se pode lidar mais facilmente. Por exemplo, no Dice Calculation, identificam-se alguns cenários como Dados, Jogador ou Operação. A figura 6 ilustra a primeira fase da elaboração da tabela de responsabilidades estendida para o contexto restrito de utilização do Dice Calculation, indicando-se todos os cenários que foram identificados através do documento de concepção.

    Figura 6 Primeira fase da elaboração da tabela de responsabilidades estendida, em que se apresentam as classes e as respectivas cardinalidades, bem como os cenários identificados através do documento de concepção.

    A decomposição em cenários é uma forma de gerir a complexidade. No entanto, é uma actividade subjectiva: se cada cenário for muito complexo, o ganho da decomposição é nulo; e se cada cenário for muito pequeno, perde-se a noção do todo. A nossa sugestão é de realizar um processo iterativo de decomposição com vista a encontrar um conjunto coerente e consistente de cenários, cada um dos quais relativamente simples. Para orientação de aplicação prática, sugerimos que a especificação completa de cada cenário não ultrapasse uma página.

  • 3.3. Atributos, métodos e pedidos

  • A fase seguinte corresponde à especificação de cada cenário. Essa especificação consiste em identificar, para cada classe, os seus atributos (A), os seus métodos (M) e os pedidos (P) que os seus objectos efectuam aos objectos das outras classes, ou seja, as mensagens que lhes enviam. Ao especificar as mensagens enviadas por cada objecto especificam-se também, implicitamente, as mensagens recebidas. No entanto, constatou-se que uma especificação cruzada, em que se procuram as mensagens enviadas e as recebidas, contribui para evitar omissões e serve para realizar verificações de consistência.
     
  • 3.4. Diálogos

  • Para cada cenário especificam-se também os diálogos (D) entre os objectos. Aplicam-se em situações em que as mensagens enviadas e recebidas não são perfeitamente identificáveis. Por exemplo, uma caixa de diálogo utilizada na alteração dos dígitos dos dados envolve uma situação de diálogo intenso, em que o utilizador altera sucessivamente os diversos dígitos, provocando sistematicamente reacções do programa, que se traduzem por mensagens implícitas. Verificou-se que a especificação destes diálogos é particularmente útil para situações em que existem mensagens implícitas, pelo menos por parte de um dos objectos envolvidos no diálogo.

    Figura 7 Representação de um diálogo entre dois objectos, em que existe um fluxo intenso de trocas de mensagens



    Cada diálogo entre dois objectos é especificado na tabela de responsabilidades estendida através do símbolo representado na figura 7. Em geral, os identificadores dos diálogos dos dois objectos coincidem, o que serve para verificar a consistência da interacção entre ambos os objectos. No entanto, o significado do diálogo, para cada um dos objectos, é distinto. No exemplo da figura 7, o papel do objecto da classe Aluno é diverso do papel do objecto da classe Programa_Educativo. O Aluno toma decisões de alteração dos dígitos, enquanto que o Programa_Educativo reage, em conformidade, a essas decisões.

  • 3.5. Exemplo

  • Na figura 8 representa-se a especificação completa do cenário Relógio, identificado na concepção Dice Calculation. Nesta figura,

    «183 \f "Symbol" \s 12» as linhas a tracejado, com setas a apontar para ambos os lados, estabelecem uma correspondência de atributos de duas classes diferentes. Por exemplo, o atributo Tempo por volta é semelhante nas três classes envolvidas;

    «183 \f "Symbol" \s 12» as linhas cheias com seta apenas de um dos lados representam o envio de mensagens, ou seja, representam pedidos de um objecto de uma classe a um objecto de outra classe. Por exemplo, tanto o objecto da classe Aluno como o da classe Educador pedem ao objecto da classe Programa_Educativo para alterar o tempo por volta do relógio.



    Figura 8 Especificação do cenário Relógio identificado na concepção Dice Calculation


    Pela observação da figura 8 constata-se ainda que:

    «183 \f "Symbol" \s 12» as classes Aluno e Educador não são caracterizadas, necessariamente, da mesma forma. Por exemplo, verifica-se que a classe Aluno possui o atributo Posição do ponteiro do relógio, que não é comum à classe Educador porque esta não necessita, no âmbito da concepção, de o conhecer;

    «183 \f "Symbol" \s 12» as classes podem possuir atributos e/ou métodos privados, ou seja, desconhecidos das outras classes. Por exemplo, a classe Programa_Educativo possui um método nessas condições, o método Avança (1/60) x tempo por volta.

    Deve ainda referir-se que, apesar de no exemplo da figura 8 não existirem pedidos por parte dos objectos da classe Programa_Educativo, não significa que não possam ocorrer. Ocorrem, de forma implícita, durante os diálogos. Ocorrem também, explicitamente, como ilustrado na figura 9, em que se representa um pedido do objecto da classe Programa_Educativo a um objecto da classe Aluno, no âmbito do cenário Jogada.


    Figura 9 Ilustração de um caso em que se verifica um pedido explícito por parte do objecto da classe Programa_Educativo.


    4. Conclusões e perspectivas

    Com o modelo das três entidades, um programa educativo deixa de ser considerado como uma entidade isolada, passando a ser uma de três entidades que devem interagir e colaborar no processo de aprendizagem dos alunos. Desta forma é necessário especificar não apenas o programa educativo, mas também as outras entidades, o aluno e o educador, que existem no contexto da sua utilização.

    Cada uma das três entidades é uma classe de objectos e a comunicação entre eles realiza-se através de trocas de mensagens, implícitas e explícitas, o que permite o estabelecimento de um modelo de comunicação que torne possível a existência de formas de interacção mais simétricas, em termos de controlo, entre os utilizadores e o programa educativo.

    O modelo das três entidades constitui apenas um enquadramento conceptual, pelo que foi orientado para a aplicação prática através de uma nova entidade, a tabela de responsabilidades estendida, em que se caracterizam as classes e as trocas de mensagens entre os objectos dessas classes.

    Os testes realizados com o Dice Calculation permitiram verificar que a tabela de responsabilidades estendida suporta a modelização de uma interacção mais simétrica entre o programa educativo e as outras duas entidades. Torna-se necessário realizar outros testes baseados em concepções em que essa simetria seja mais evidente, e não baseados num modelo de comunicação do tipo acção do aluno reacção do programa. Para isso é necessário explorar técnicas de concepção em que possam ser expressos níveis mais elevados de simetria.

    Esses testes permitiram concluir também que o modelo das três entidades e a tabela de responsabilidades estendida conduzem a uma abordagem de desenvolvimento baseada em métodos orientados a objectos. Em particular, verificou-se que os cenários identificados e caracterizados na tabela de responsabilidades estendida constituem pistas válidas para a identificação das classes e dos objectos durante as actividades de análise orientada a objectos. Desta forma, o modelo das três entidades e a tabela de responsabilidades estendida facilitam a transição da fase de concepção para a fase de desenvolvimento.

    Para o desenvolvimento do Dice Calculation utilizámos, como metodologia de desenvolvimento, a prototipificação continuadamente evolutiva [8] e socorremo-nos de métodos orientados a objectos [6]. Reconhecemos, no entanto, que apesar de os testes realizados sugerirem as conclusões que acabamos de apresentar, é necessário maior experimentação com vista a desenvolver o modelo proposto, por um lado, e a reforçar estas conclusões, por outro.
     

    Agradecimentos
    Os autores agradecem ao Instituto Superior de Contabilidade e Administração de Aveiro e ao Centro de Informática e Sistemas da Universidade de Coimbra pelas facilidades concedidas na elaboração deste estudo.

    Referências

    [1] Alessi, S., e Trollip, S. Computer-Based Instruction: Methods and Development. Prentice-Hall, Inc., Englewood Cliffs, New Jersey, U.S.A., 1985.

    [2] Crossley, K., e Green, L. Le Design des Didacticiels: Guide Pratique pour la Conception de Scénarios Pédagogiques Interactifs. ACL-Editions, Paris, France, 1990.

    [3] Minken, I., Stenseth, B., e Vavik, L. Educational Software. ULTIMA-Gruppen A/S, Halden, Norway, 1988.

    [4] Snyder, A. The Essence of Objects: Concepts and Terms. IEEE Software 10, 1 (Janeiro, 1993), 31.

    [5] Batista, J., e Figueiredo, A. Object-Orientation: In Search of the Paradigm. Relatório Interno DEE-FCTUC-011-93, ISSN:0871-7850, Universidade de Coimbra, Coimbra, Portugal, 1993.

    [6] Booch, G. Object-Oriented Analysis and Design: With Applications (second edition). The Benjamin/Cummings Publishing Company, Inc., Redwood City, California, U.S.A., 1994.

    [7] Laurel, B. Computers as Theatre. Addison-Wesley Publishing Company, Inc., Reading, Massachusetts, U.S.A., 1991.

    [8] Batista, J., e Figueiredo, A. A Prototipificação Estruturada Aplicada ao Desenvolvimento de Programas Educativos. Dissertação de Mestrado, Faculdade de Ciências e Tecnologia, Universidade de Coimbra, Coimbra, Portugal, 1992.