ambiente de suporte à aprendizagem de conceitos básicos de...

Universidade de Coimbra Faculdade de Ciências e Tecnologia

Departamento de Engenharia Informática

Ambiente de suporte à aprendizagem de conceitos

básicos de programação

Anabela de Jesus Gomes

Coimbra 2000

Universidade de Coimbra Faculdade de Ciências e Tecnologia

Departamento de Engenharia Informática

Ambiente de suporte à aprendizagem de conceitos

básicos de programação

Anabela de Jesus Gomes

Dissertação submetida à Universidade de Coimbra para a obtenção do grau de

“Mestre em Engenharia Informática”, área de especialização em Sistemas

Multimédia na Educação e Formação Profissional, elaborada sob a orientação

do Professor Doutor António José Mendes

Coimbra

2000

Ambiente de suporte à aprendizagem de conceitos básicos de programação

i

Ao Álvaro


ii

Agradecimentos

Ao Professor Doutor António José Mendes pela dedicação, disponibilidade, apoio

constante e profissionalismo com que orientou todo o trabalho, desde a sua fase inicial, às

valiosas críticas, ensinamentos e sugestões durante a implementação até à revisão do

texto.

Ao Instituto Superior de Engenharia de Coimbra por todas as facilidades concedidas.

Aos colegas do Instituto Superior de Engenharia de Coimbra pela compreensão e apoio

que sempre me ofereceram.

Aos Engº Álvaro Santos, Engº João Durães, Engª Leonor Melo e Engº Rui Pedro Paiva,

pelos testes realizados e pelas valiosas sugestões.

A toda a minha família não apenas pelo incentivo mas essencialmente por todo o tempo

que lhes era devido.

Finalmente, os meus agradecimentos a todos aqueles que das mais variadas formas

ofereceram contribuições para que o desenvolvimento deste trabalho fosse possível.


iii

Resumo

As dificuldades sentidas por muitos alunos na aprendizagem da programação

sugere a existência de deficiências a vários níveis, às quais os métodos de ensino e

aprendizagem clássicos parecem não dar uma resposta suficientemente eficaz. Tendo em

conta que a programação envolve essencialmente conceitos dinâmicos, parece-nos que a

abordagem normalmente utilizada para o ensino de programação, recorrendo

principalmente a materiais de índole estática, não será a mais adequada. Nesta dissertação

é feita uma reflexão sobre as origens deste problema e possíveis formas de colmatá-lo.

Os professores tentam habitualmente utilizar diversas estratégias no sentido de

facilitar a aprendizagem dos seus alunos. No que respeita ao ensino da programação têm

sido realizados diversos esforços, como por exemplo, o desenvolvimento de várias

ferramentas computacionais com o objectivo de facilitar a aprendizagem. Porém, apesar

da existência de estudos que constatam a contribuição positiva por parte de algumas delas,

não existem indicações de que alguma tenha tido uma vasta utilização no

ensino/aprendizagem.

Neste trabalho apresentamos o SICAS (Sistema Interactivo para Construção de

Algoritmos e sua Simulação), um ambiente de aprendizagem, concebido como auxiliar do

ensino/aprendizagem de programação, suportando actividades de concepção, simulação e

teste de algoritmos. Isto porque, pensamos que o principal problema que os alunos

enfrentam na aprendizagem de programação reside numa enorme dificuldade de resolução

de problemas que, em disciplinas de programação, se traduz na incapacidade de

concepção de algoritmos. A aproximação utilizada passa por uma postura muito activa

por parte do aluno, na convicção que a melhor forma de um aluno aprender programação

é construindo, corrigindo e refinando os seus próprios programas.

Assim, em nossa opinião, a principal vantagem da utilização do SICAS centra-se

na possibilidade de construção e simulação de algoritmos pelos alunos, de forma

autónoma, mas supervisionada. O SICAS pode ser utilizado em vários contextos,

nomeadamente extra aulas, permitindo aos alunos estudar, compreender e utilizar os

diversos aspectos que constituem normalmente uma disciplina de programação. Este

trabalho poderá ser feito ao ritmo que mais se adeqúe ao seu processo de aprendizagem e

de acordo com o seu raciocínio e teorias.

O SICAS, apesar de ter sido concebido principalmente para uma utilização

independente pelo aluno, pode também ser utilizado num contexto de sala de aula


iv

auxiliando o professor nas suas tarefas de explicação e exposição da matéria. Neste

contexto, permite uma variedade de actividades de que se destacam a possibilidade de

fornecer exercícios para os alunos completarem, alterarem, corrigirem ou conceberem de

raiz, mostrar diversas versões de determinado problema de forma rápida ou modificar

programas por forma a responder a dúvidas dos alunos. O SICAS pode ainda ser utilizado

numa perspectiva de avaliação na medida em que o professor pode indicar enunciados que

pretende que os alunos resolvam e posteriormente consultar/avaliar as resoluções dos seus

alunos.

A grande disponibilidade do SICAS para ser utilizado de acordo com os horários

estabelecidos pelos próprios alunos, a não existência de embaraço por parte deles,

conferindo-lhes um à-vontade para experimentar as suas próprias hipóteses e a

consciência de estar a resolver problemas sob orientação e acompanhamento do sistema,

com possibilidade de testar e simular as resoluções, são outro conjunto de benefícios que

o aluno poderá retirar da sua utilização.

O facto do SICAS apresentar um elevado grau de flexibilidade, permitindo a

adição, remoção e alteração dos exemplos, exercícios propostos e soluções apresentadas,

sem que tal implique quaisquer alterações no seu código faz dele um ambiente poderoso e

fácil de utilizar.

As facilidades concedidas pelo SICAS aliadas à sua apresentação/interface

constitui, no nosso entender, um forte apelativo para a sua utilização. Também o seu

carácter predominantemente prático pode criar um estímulo para a sua utilização, pois a

grande maioria dos alunos apresenta maior motivação para o estudo de assuntos práticos

em detrimento dos teóricos. Este aspecto é consideravelmente importante, não apenas

para os alunos da área mas também, para os alunos sem qualquer conhecimento prévio

sobre o assunto.


v

Índice 1 INTRODUÇÃO ..................................................................................................................................... 1

1.1 MOTIVAÇÃO ..................................................................................................................................... 1

1.2 OBJECTIVOS ..................................................................................................................................... 4

1.3 ALGUMAS TÉCNICAS COMPLEMENTARES.......................................................................................... 5

1.4 ESTRUTURA DA DISSERTAÇÃO.......................................................................................................... 8

2 ALGORITMOS E RESOLUÇÃO DE PROBLEMAS..................................................................... 10

2.1 REFLEXÃO ...................................................................................................................................... 10

2.2 FORMAS DE REPRESENTAÇÃO DE ALGORITMOS .............................................................................. 16

2.3 FERRAMENTAS DE SUPORTE À APRENDIZAGEM DE PROGRAMAÇÃO ................................................ 20

2.3.1 Sistemas ................................................................................................................................. 20

2.3.2 Estudos .................................................................................................................................. 23

3 O SICAS ............................................................................................................................................... 29

3.1 INTRODUÇÃO.................................................................................................................................. 29

3.2 DESCRIÇÃO .................................................................................................................................... 30

3.2.1 Modo Professor ..................................................................................................................... 30

3.2.2 Modo Aluno ........................................................................................................................... 31

3.2.2.1 Actividades de Construção/Edição da Resolução do Problema......................................... 33

3.2.2.1.1 Área de construção/edição da resolução do problema ................................................ 33

3.2.2.1.1.1 Estruturas básicas................................................................................................. 36

3.2.2.1.1.1.1 Atribuição ..................................................................................................... 36

3.2.2.1.1.1.2 Entrada/Saída ................................................................................................ 36

3.2.2.1.1.2 Estruturas de controlo .......................................................................................... 37

3.2.2.1.1.2.1 Repetição....................................................................................................... 37

3.2.2.1.1.2.2 Selecção ........................................................................................................ 39

3.2.2.1.1.3 Estruturas Compostas........................................................................................... 40

3.2.2.1.1.3.1 ChamaFunção ............................................................................................... 40

3.2.2.1.1.4 Outras estruturas .................................................................................................. 42

3.2.2.1.1.5 Variáveis .............................................................................................................. 44

3.2.2.1.1.6 Identificadores...................................................................................................... 46

3.2.2.1.1.7 Expressões ........................................................................................................... 46

3.2.2.1.1.8 Funções pré-definidas .......................................................................................... 49

3.2.2.1.1.9 Funções definidas pelo utilizador......................................................................... 57

3.2.2.1.2 Área de geração de resultados e descrição do problema ............................................. 62

3.2.2.1.2.1 Enunciado ............................................................................................................ 62

3.2.2.1.2.2 Saída..................................................................................................................... 63

3.2.2.1.2.3 Entradas ............................................................................................................... 64


vi

3.2.2.1.2.4 Solução................................................................................................................. 64

3.2.2.1.2.5 Exemplo de Saída ................................................................................................ 65

3.2.2.1.3 Área de dados auxiliares ............................................................................................. 65

3.2.2.1.3.1 Factos ................................................................................................................... 66

3.2.2.1.3.2 Variáveis .............................................................................................................. 66

3.2.2.1.3.3 Funções ................................................................................................................ 66

3.2.2.2 Actividades de Animação/Simulação da Resolução do Problema..................................... 67

3.2.2.3 Elementos Auxiliares......................................................................................................... 69

3.3 AVALIAÇÃO E MELHORAMENTOS ................................................................................................... 71

3.4 ALGUNS ASPECTOS DE IMPLEMENTAÇÃO ....................................................................................... 73

4 UTILIZAÇÃO DO SICAS.................................................................................................................. 77

4.1 FORMAS DE UTILIZAÇÃO ................................................................................................................ 77

4.2 EXEMPLO 1..................................................................................................................................... 79

4.3 EXEMPLO 2..................................................................................................................................... 93

5 CONCLUSÕES E TRABALHO FUTURO .................................................................................... 101

5.1 CONCLUSÕES................................................................................................................................ 101

5.2 TRABALHO FUTURO ..................................................................................................................... 104

BIBLIOGRAFIA ....................................................................................................................................... 106


vii

Lista de figuras

Figura 3.1 Áreas principais do SICAS .......................................................................................................... 34

Figura 3.2 Diálogo de especificação de uma atribuição ................................................................................ 36

Figura 3.3 Diálogo de especificação de uma leitura ...................................................................................... 37

Figura 3.4 Diálogo de especificação de uma escrita...................................................................................... 37

Figura 3.5 Diálogo de especificação de uma repetição while........................................................................ 38

Figura 3.6 Diálogo de especificação de uma repetição for ............................................................................ 39

Figura 3.7 Diálogo de especificação de uma selecção................................................................................... 40

Figura 3.8 Diálogo de uma chamada de uma função com passagem de parâmetros por valor...................... 41

Figura 3.9 Diálogo de uma chamada de uma função com passagem de parâmetros por referência .............. 42

Figura 3.10 Extracto da representação de uma estrutura de selecção ............................................................ 43

Figura 3.11 Extracto da representação de uma estrutura de repetição........................................................... 43

Figura 3.12 Diálogo para gestão das variáveis .............................................................................................. 46

Figura 3.13 Écran ilustrativo dos elementos delimitadores de uma função................................................... 57

Figura 3.14 Mensagem ilustrativa de uma situação de erro........................................................................... 58

Figura 3.15 Diálogo de definição dos parâmetros formais de uma função.................................................... 59

Figura 3.16 Diálogo de especificação do valor de retorno de uma função .................................................... 59

Figura 3.17 Selecção da opção para eliminação de uma função.................................................................... 60

Figura 3.18 Diálogo para eventual eliminação de uma função...................................................................... 60

Figura 3.19 Diálogo para eventual substituição de uma função por outra..................................................... 61

Figura 3.20 Diálogo para eventual eliminação das chamadas de uma função............................................... 61

Figura 3.21 Diálogo para escolha da função a substituir ............................................................................... 62

Figura 3.22 Selecção da opção para geração de pseudocódigo ..................................................................... 63

Figura 3.23 Écran ilustrativo do preenchimento de valores na subsecção Solução....................................... 65

Figura 3.24 Configuração do ritmo da execução ........................................................................................... 68

Figura 3.25 Écran ilustrativo de uma situação durante uma simulação......................................................... 68

Figura 3.26 Diálogo para introdução de dados durante uma simulação ........................................................ 69

Figura 3.27 Selecção da opção para consulta de informação sobre o SICAS................................................ 69

Figura 3.28 Janela de apresentação das funcionalidades do SICAS.............................................................. 70

Figura 3.29 Janela de apresentação das utilidades do SICAS ....................................................................... 70

Figura 4.1 Écran inicial do modo professor................................................................................................... 79

Figura 4.2 Écran ilustrativo das modificações provocadas pela criação do enunciado ................................. 80

Figura 4.3 Écran ilustrativo dos valores introduzidos para a solução............................................................ 81

Figura 4.4 Diálogo para introdução de dados na subsecção Entradas ........................................................... 81

Figura 4.5 Diálogo para introdução do nome do utilizador ........................................................................... 82

Figura 4.6 Écran inicial do modo aluno......................................................................................................... 82

Figura 4.7 Écran ilustrativo das modificações provocadas pela abertura de um enunciado .......................... 83

Figura 4.8 Diálogo para atribuição de um nome a uma resolução................................................................. 83


viii

Figura 4.9 Écran inicial de uma resolução..................................................................................................... 84

Figura 4.10 Diálogo para gestão das variáveis .............................................................................................. 84

Figura 4.11 Diálogo de especificação de uma leitura .................................................................................... 85

Figura 4.12 Écran ilustrativo de uma situação de resolução.......................................................................... 85

Figura 4.13 Diálogo de especificação de uma repetição for .......................................................................... 86


Figura 4.15 Diálogo de especificação de uma leitura .................................................................................... 87

Figura 4.16 Diálogo de especificação de uma escrita.................................................................................... 87


Figura 4.18 Diálogo de especificação de uma atribuição .............................................................................. 88


Figura 4.20 Selecção das opções de configuração para o decorrer de uma simulação .................................. 89

Figura 4.21 Ilustração de um pedido de introdução de dados durante uma simulação.................................. 90




Figura 4.25 Diálogo de especificação de uma repetição while...................................................................... 92



Figura 4.28 Selecção da opção para adição de uma função........................................................................... 94

Figura 4.29 Diálogo para introdução do nome de uma função...................................................................... 94

Figura 4.30 Écran ilustrativo de uma situação de resolução numa função .................................................... 95

Figura 4.31 Diálogo de definição dos parâmetros formais ............................................................................ 95

Figura 4.32 Diálogo de especificação do valor de retorno de uma função .................................................... 96

Figura 4.33 Écran ilustrativo de uma situação de resolução numa função .................................................... 96

Figura 4.34 Selecção da opção para transição entre funções......................................................................... 97

Figura 4.35 Diálogo para estabelecimento de correspondência entre parâmetros formais e reais................. 97

Figura 4.36 Écran ilustrativo de uma situação de resolução com evocação de uma função.......................... 98

Figura 4.37 Activação de um menu contextual para edição de uma estrutura............................................... 99


Figura 4.39 Écran ilustrativo de uma situação durante uma simulação....................................................... 100

Cap. 1 - Introdução

1

11 IINNTTRROODDUUÇÇÃÃOO

11..11 MMoottiivvaaççããoo O ensino da programação tem como propósito conseguir que os alunos

desenvolvam as suas capacidades, adquirindo os conhecimentos necessários para

conceber programas e sistemas computacionais capazes de resolver problemas reais.

Porém, a experiência tem demonstrado que existe, em termos gerais, uma grande

dificuldade em compreender e aplicar certos conceitos abstractos de programação, por

parte de uma percentagem significativa dos alunos que frequentam cadeiras introdutórias

nesta área. Uma das grandes dificuldades reside precisamente na compreensão e, em

particular, na aplicação de noções básicas, como as estruturas de controlo, à criação de

algoritmos que resolvam problemas concretos.

Face a taxas de insucesso geralmente elevadas nas disciplinas de programação, há

um conjunto de questões sobre as quais convém reflectir nomeadamente os métodos de

ensino e de estudo utilizados. Será que são os mais adequados? Na realidade, parece

existir um certo desajustamento entre os modelos de ensino tradicionais e as necessidades

que os alunos apresentam para o entendimento e aprendizagem deste tipo de matérias.

Pensamos que os problemas sentidos na aprendizagem da programação se devem a um

conjunto diferenciado de factores, que passamos a apresentar.

As linguagens de programação apresentam normalmente características muito

próprias com sintaxes demasiado extensas, não facilmente apreensíveis num estágio

inicial de aprendizagem da programação, para além de possuírem determinados aspectos

que exigem um elevado grau de abstracção. A não existência de representações visuais

dos algoritmos construídos e implementados, na maioria das linguagens de programação

tradicionais, agrava estas dificuldades traduzindo-se, em geral, num reduzido nível de

compreensão.


2

O tipo de materiais tradicionalmente utilizados não parecem os mais apropriados

para o ensino da programação, pois utilizam principalmente materiais de índole estática

para a explicação de conceitos dinâmicos. Este aspecto deve-se essencialmente ao facto

de o tempo dentro do currículo escolar ser demasiado apertado o que leva, muitas vezes,

os professores a reagirem tipo “máquinas de despejar matéria”. Este factor associado à

existência de turmas demasiado grandes impossibilitando um acompanhamento

individualizado ao aluno também contribui para o agravamento do problema apresentado.

A aprendizagem da programação necessita de um tipo de estudo muito baseado na

prática e, por isso, bastante diferente do requerido pela maioria das disciplinas (mais

baseado em noções teóricas, implicando muita leitura e alguma memorização). É

necessário haver uma consciencialização por parte dos alunos que a programação se

aprende fazendo e não vendo como se faz, exigindo muito treino, persistência e um bom

nível de conhecimentos e prática de técnicas de resolução de problemas.

A programação exige múltiplas aptidões, ou seja, consiste numa hierarquia de

qualificações, muitas das quais têm de estar activas simultaneamente. A aprendizagem da

programação não implica apenas um conhecimento profundo da sintaxe de uma

linguagem, é necessária uma grande capacidade para resolver problemas, um bom

conhecimento de técnicas eficazes para atacar os problemas mais comuns e uma grande

capacidade de abstracção.

Aliado a todos estes problemas existe um outro que acentua as dificuldades

referidas. Actualmente, no ensino superior português, é permitido que alunos de áreas

algo diversificadas, e como tal com backgrounds muito diferentes, frequentem um curso

superior, onde são leccionadas disciplinas de programação. Assim, é possível encontrar

turmas muito heterogéneas onde existem alunos provenientes de cursos tecnológicos, já

com algum conhecimento de programação, e outros dos mais variados cursos, que muitas

vezes apenas se defrontaram com um computador na óptica do utilizador, traduzindo-se

em diferentes ritmos de aprendizagem e de interesses. Os assuntos leccionados em

programação são, na generalidade, ministrados por anos de escolaridade e não por níveis

de conhecimentos, o que faz com que todos os alunos sejam forçados a moverem-se ao

mesmo ritmo, gastando o mesmo tempo no processo de aprendizagem independentemente

do progresso de uns relativamente aos outros, das suas diferenças individuais e níveis de

dificuldade desigual.

Todos os aspectos mencionados contribuem para que haja um factor psicológico

negativo associado à área em questão. Este factor faz com que os alunos por vezes não se


3

esforcem o suficiente ou não tenham a motivação necessária uma vez que essas

disciplinas estão “etiquetadas” como sendo demasiado difíceis, agravando assim o

problema focado.

A nossa opinião é a de que este conjunto de questões deveria de ser repensado e

analisado, e uma das primeiras intervenções a efectuar antes de se começar a leccionar

uma cadeira de programação seria uma selecção dos alunos por níveis de conhecimentos e

aptidões. Assim, os alunos com menos discernimento e engenho para estas questões

deveriam ser direccionados para uma cadeira preparatória que incidisse numa dedicação

intensiva com muitas horas de treino a resolver problemas. Esses problemas deveriam

promover o desenvolvimento do seu raciocínio lógico orientado à programação, com

actividades que envolvessem o planeamento, subdivisão e construção de soluções.

Kagan (1988) estabeleceu um paralelo entre uma linguagem natural, como por

exemplo o Inglês, e uma linguagem de programação, afirmando que ambas são utilizadas

para comunicar e ambas contêm os mesmos dois tipos fundamentais de estruturas:

semântica e sintáctica. Um programa consiste em pequenas componentes linguísticas

(declarações), que são ordenadas e agrupadas de uma forma coerente numa composição

(programa), tal como as frases e declarações são ordenadas e agrupadas num discurso. O

problema, segundo ele, talvez não resida na diferença significativa do tipo existente entre

as duas linguagens, mas antes do facto de termos anos de treino numa, e provavelmente

falta dele na outra.

Também nós achamos que a experiência é um factor determinante para o sucesso

da aprendizagem da programação, porém, pensamos que o problema não é assim tão

linear. Pois, tal como um bom conhecimento de uma língua, como por exemplo o

português, não é o suficiente para que uma pessoa seja um bom escritor nessa língua,

também o conhecimento profundo de uma linguagem de programação incluindo todos os

seus aspectos sintácticos e semânticos não chega para fazer um bom programador. Esse é

apenas um dos aspectos a ter em consideração, mas que por si só não é suficiente. É

necessária uma grande capacidade para resolver problemas (algoritmos), um bom

conhecimento de técnicas eficazes para atacar um determinado problema numa dada

linguagem, alguma criatividade, uma boa dose de raciocínio lógico, persistência e

perseverança.

Todo o conjunto de problemas focados origina alguma desorientação e

desinteresse por parte dos alunos, exigindo um acompanhamento e orientação que o


4

professor nem sempre pode disponibilizar e a que os métodos de ensino tradicionais nem

sempre dão resposta. Antes, porém, de avançarmos para as possíveis formas de atacar o

problema convém analisar as suas origens. Entre os diversos motivos que levam os alunos

a ter dificuldades e a solicitar ajuda, há que destacar os seguintes:

♦ incapacidade de estruturação dos passos de resolução de um problema;

♦ incapacidade de concepção de algoritmos;

♦ incapacidade de detectar erros de lógica de programação;

♦ falta de pré-requisitos sobre as matérias em questão e de técnicas de

programação eficazes;

♦ conceitos errados sobre os recursos e técnicas utilizadas;

♦ problemas devido a efeitos colaterais não previstos;

♦ erros de sintaxe e advertências na compilação.

11..22 OObbjjeeccttiivvooss Face a todo o conjunto de problemas mencionado, surgiu a ideia de conceber um

sistema educativo capaz de auxiliar o ensino e aprendizagem de mecanismos básicos de

programação, em que o “centro de gravidade” seja o próprio aluno.

O sistema educativo em causa tem como principal objectivo permitir que o aluno

aprenda a construir resoluções (algoritmos) para determinados problemas de

programação, as quais podem ser por ele simuladas.

Esse auxiliar de ensino/aprendizagem foi pensado com o objectivo sempre

presente de uma participação e intervenção activa do aluno para que ele não receba a

informação passivamente, como quando está a ler um livro ou a ver televisão, mas dando-

lhe a possibilidade de controlá-la. É também objectivo desse sistema dar ao aluno a

possibilidade de realizar uma análise da informação ao seu próprio ritmo, com o pormenor

desejado, com o tempo necessário para absorver determinadas ideias ou conceitos,

permitindo-lhe ultrapassar as suas inibições que tantas vezes impedem a exposição das

suas dúvidas, ajudando-o a vencer muitas das suas dificuldades.

A ferramenta criada deve também ser capaz de assistir o aluno, apoiando as

actividades de supervisão habitualmente conferidas ao professor e de detectar os erros

cometidos pelo aluno dando-lhe algumas indicações no sentido de os corrigir. Para além


5

disso, deve minimizar a possibilidade de o aluno cometer determinados erros sintácticos e

semânticos, a fim de interiorizar sem grande esforço determinadas estruturas e conceitos.

11..33 AAllgguummaass ttééccnniiccaass ccoommpplleemmeennttaarreess Tendo em conta o que já foi referido, e antes de apresentar a ferramenta criada e as

suas características, é feita de seguida uma breve exposição sobre técnicas e sistemas

complementares aos métodos de ensino tradicionais, que eventualmente possam apoiar o

aluno no seu processo de aprendizagem da programação.

♦ Existência de vastas bibliotecas com manuais de problemas com resoluções.

Apesar de poderem constituir um auxiliar precioso no sentido de uma verdadeira

disponibilização da informação, como opção e não como elemento obrigatório do sistema

de aprendizagem, colmatando alguns prejuízos provocados pela impossibilidade de

acompanhamento pelo professor fora do horário lectivo, apresentam a desvantagem de

constituírem meios passivos e estáticos. Principalmente, pensamos que ver problemas

resolvidos raramente se traduz num aumento da capacidade de solucionar outros

problemas. Por vezes, basta pedir aos alunos para resolverem um problema ligeiramente

diferente ou fazer alterações ao existente para constatar que este método é pouco eficaz.

♦ Aplicação de práticas de programação em equipa. Traduz-se numa nova

filosofia de trabalho, baseada na colaboração, permitindo que os membros do grupo

comuniquem e troquem as suas ideias, colaborando na resolução do problema. A

colaboração é um factor crítico para o sucesso da aprendizagem, em especial neste tipo de

matérias em que predominam conceitos abstractos, os quais quando discutidos

colectivamente poder-se-ão tornar mais evidentes. Porém, esta solução pode apresentar a

desvantagem de, por um lado, carecer de um acompanhamento especializado que dirija a

equipa, sem o qual poderá haver dedução de conclusões a partir de pressupostos errados.

Por outro lado, se o grupo formado não for devidamente escolhido, poderá existir um

aluno com conhecimentos muito superiores aos restantes que monopolize as actividades

ficando os outros com a sua participação reduzida à simples observação.


6

♦ Apoio por correio electrónico. Apesar da troca de mensagens interpessoais

apresentar enormes vantagens no que respeita à poupança de tempo, na medida em que o

remetente e o destinatário não precisam de estar simultaneamente disponíveis para

comunicar e da possibilidade de enviar problemas concretos e outros suplementos de

informação, conduzindo a uma maior eficiência na comunicação, este método apresenta

uma certa passividade. Também, por vezes, os agentes envolvidos na comunicação

recebem informação insuficiente para uma boa colocação do problema e/ou

esclarecimento da dúvida, na medida em que há questões complexas de colocar através da

utilização deste meio de uma forma rápida e clara. No entanto, esta alternativa constitui

uma forma para que o professor possa estar disponível de um modo assíncrono e

distribuído.

♦ Apoio através de serviços de discussão em grupo. Possibilitam a criação de

novos canais de comunicação que, com o advento da Internet, permitem que as

mensagens possam ser trocadas em amplitude planetária. Ou seja, promovem a discussão

e colaboração entre as pessoas envolvidas, através da troca de dados, informação e

experiências e, acima de tudo, permitem construir o saber num processo cumulativo de

ajuda e percepção partilhada de problemas e necessidades. Contudo, apresentam como

inconveniente principal o possível volume de dados transaccionados, para além dos

problemas focados no ponto anterior.

♦ Utilização de tutoriais multimédia. Pensamos que apesar de componentes deste

tipo poderem ser úteis, esta abordagem por si só não é a mais adequada, pois a

programação aprende-se essencialmente fazendo e não vendo como se faz. Também, o

desenvolvimento de um bom tutorial é muito caro e difícil, exigindo a participação de

uma equipa multidisciplinar. Além disso, a maioria dos tutoriais existentes requer poucas

acções por parte do aprendiz, perpetuando um método de ensino que é pouco eficiente,

mas agora em versão computacional.

♦ Ajuda on-line. Esta alternativa é normalmente implementada recorrendo a

hipertexto, hipermedia e/ou aprendizagem através da WEB. Incorpora um aspecto

completamente diferente da apresentação da informação, integrando normalmente

múltiplos meios apelativos que são combinados de uma forma não linear e interactiva

fazendo com que o aprendiz possa atravessar o ambiente, explorando várias ideias.


7

Baseado na crença de que a memória é associativa e não linear, o hipermedia reforça a

promessa de melhorar o pensamento e compreensão do aprendiz. Porém, apresenta as

desvantagens de o aluno se poder perder com o excesso de dados, sentindo-se “carente de

saber e inundado de informação”. Além disso, este tipo de sistemas são algo limitados

quanto ao tipo de feedback gerado e de actividades possibilitadas, indicando normalmente

apenas um resultado como resposta ao conjunto de acções permitidas ao utilizador.

Pensamos que esta alternativa pode ajudar a resolver muitos dos problemas focados se

funcionar como um sistema complementar e não como um sistema principal.

♦ Sistemas de Tutores Inteligentes. Estes sistemas quando bem concebidos

poderiam ser altamente eficazes como ajuda na aprendizagem, permitindo simular ou

substituir as funções de auxiliares humanos. Apesar da existência de alguns tutores

inteligentes desenvolvidos no passado com aplicação na programação, de que se destacam

Lisp Tutor (Anderson e Reiser, 1985), SCENT (McCalla et al., 1988), Loop Tutor

(Tyerman et al., 1996), C-Tutor (Song et al., 1997), entre outros, existem pouquíssimos

sistemas deste tipo para avaliação, na medida em que são muito difíceis e dispendiosos de

construir.

♦ Jogos educacionais. A pedagogia subjacente nesta abordagem é a da articulação

do lazer com a aprendizagem, em que predomina o conceito de metáfora. Assim, o aluno

ao reconhecer relações e estabelecer correspondências entre ambientes estimulantes e

objectos que lhe são familiares com outros mais complexos e abstractos está, muitas

vezes, inconscientemente, a usar conceitos de grande significado lógico sem se aperceber.

A filosofia presente neste meio de aprendizagem é a da exploração auto-dirigida em vez

do ensino explícito e directo. Os proponentes desta forma de ensino defendem a ideia de

que o aluno aprende melhor quando é livre para descobrir as relações entre os objectos

por si próprio do que quando explicitamente ensinado, em especial se se encontrar num

ambiente atraente que estimule a sua curiosidade. Porém, esta solução só é eficaz se tiver

sempre presente um compromisso entre dois objectivos, o entretenimento e a

aprendizagem das matérias em questão. Além disso, pensamos que este tipo de solução é

mais adequado para grupos etários mais novos do que aqueles que apresentam os

problemas focados.


8

♦ Sistemas de animação e visualização de algoritmos. Tem havido algumas

propostas de sistemas deste tipo, de que se destacam as referidas mais à frente no capítulo

dois desta dissertação. Pensamos que a existência de componentes deste tipo é

importantíssima, na medida em que possibilitam a representação visual e animada dos

algoritmos codificados com a apresentação das alterações das diversas entidades

envolvidas em cada uma das suas etapas. Porém, consideramos que estes sistemas

apresentam uma falha a nosso ver importantíssima, na medida em que não permitem a

construção de algoritmos sem estarem implementados numa determinada linguagem de

programação específica. Assim, entendemos que esta aproximação será bastante benéfica

para a explicação e entendimento de algoritmos já realizados e codificados, mas não

promove a capacidade do que consideramos realmente importante (a construção de

algoritmos).

Após a análise e reflexão deste conjunto de possíveis aproximações, concluímos

que a quase totalidade delas pode auxiliar o aluno como algo complementar, mas não

como sistema principal do seu processo de aprendizagem de programação, pois

“programar aprende-se a programar”.

Assim, propomos uma ferramenta híbrida, reunindo alguns dos aspectos presentes

nas alternativas referidas. O ambiente criado apresenta um formato que não é rígido e

sempre igual de aluno para aluno, mas que é por ele definido, podendo moldar-se às suas

pretensões, permitindo a construção e resolução dos problemas de acordo com o seu

raciocínio. Essa ferramenta possibilitará que os alunos por iniciativa própria desenvolvam

as suas capacidades como se fosse um “ginásio da mente”, permitindo a experimentação,

construção, exploração, teste e validação das suas próprias teorias acerca de certos

conceitos abstractos. O sistema por nós desenvolvido, SICAS, descrito no capítulo três

desta dissertação, integra ainda um conjunto de métodos dinâmicos, como a animação e

simulação dos problemas resolvidos pelo aluno.

11..44 EEssttrruuttuurraa ddaa ddiisssseerrttaaççããoo No capítulo seguinte desta dissertação focar-se-á a importância da resolução de

problemas para a aprendizagem da programação. Relativamente a este assunto são

abordados os dois principais métodos de representação de algoritmos – fluxograma e


9

pseudocódigo, acompanhados de uma análise sobre as suas diferenças básicas, vantagens

e desvantagens e apresentação de alguns estudos a reforçar a nossa opção pela escolha de

fluxogramas para essa representação. São ainda focados alguns sistemas propostos na

literatura com a finalidade de apoiar o ensino/aprendizagem da programação. São também

apresentados alguns estudos empíricos que revelam a valiosa contribuição que a utilização

de técnicas de visualização e animação pode dar para o entendimento deste tipo de

matérias, justificando assim muitas das opções por nós tomadas. No final deste capítulo é

apresentado um conjunto de características a nosso ver fundamentais numa ferramenta

com o propósito do SICAS.

No capítulo três, é feita uma descrição da estrutura geral do SICAS, incluindo os

seus modos e possibilidades de utilização, consoante o perfil do utilizador identificado,

aluno ou professor. São também apresentadas e explicadas as estruturas, elementos e

funcionalidades definidas consoante o ambiente em que o utilizador se encontra –

edição/construção ou animação/simulação da resolução de um problema. Neste capítulo

são ainda referidas algumas das alterações e melhoramentos realizados no SICAS em

consequência das sugestões derivadas de uma primeira avaliação. Finalmente são

apresentados e justificados os factores que estiveram na base da opção pela utilização da

linguagem escolhida para o desenvolvimento do SICAS, bem como as principais opções

de desenvolvimento relacionadas com essa decisão.

No capítulo quatro, são apresentados vários contextos em que o SICAS pode ser

utilizado. Com a pretensão de concretizar alguns aspectos da sua utilização e

aplicabilidade é demonstrada a construção de dois exemplos típicos de problemas de

programação, com a definição dos elementos necessários para a elaboração dessa tarefa.

No capítulo cinco tecem-se algumas conclusões do trabalho realizado, sendo

também apresentados alguns tópicos a desenvolver e a implementar em futuras versões do

SICAS. É também feita referência a alguns estudos que pretendemos levar a cabo para

avaliar mais profundamente o seu impacto na aprendizagem dos seus utilizadores.

Cap. 2 - Algoritmos e resolução de problemas

10

22 AALLGGOORRIITTMMOOSS EE RREESSOOLLUUÇÇÃÃOO DDEE

PPRROOBBLLEEMMAASS

22..11 RReefflleexxããoo Porque razão é que aprender a programar é tão difícil? Podemos observar que a

maioria das pessoas consegue seguir uma receita, dar direcções, construir histórias,

imaginar situações, planear viagens, no fundo actividades mentais similares às envolvidas

na tarefa de programação. Por outro lado, podemos verificar que os seres humanos

apresentam a capacidade de construir e compreender conceitos como sequências (1º

adicionar o açúcar, de seguida os ovos,…), condicionais (se chover então tenho de levar

guarda-chuva,...) e variáveis (duplicar a quantidade do açúcar,…). Será que é possível

transformar a programação numa actividade tão simples como a de elaborar orientações?

Provavelmente não. Aprender a programar é um processo difícil e tornar-se um bom

programador exige vários tipos de aptidões.

O trabalho de programação pode ser facilitado se for abordado como sendo

constituído por duas fases distintas, a resolução do problema através da elaboração de um

algoritmo adequado e a sua implementação ou codificação numa linguagem de

programação. É, no entanto, na resolução de problemas, muitas vezes secundarizada na

actividade de programação, que surgem as grandes dificuldades. Muitos dos alunos

revelam-se incapazes de conceber e determinar um modelo (algoritmo) de solução para o

problema proposto.

Desde os tempos mais remotos que o homem tenta encontrar meios formais e

definir meios automáticos de resolução dos problemas que lhe são propostos. Um dos

meios de formalização passa por observar e registar a forma de resolução que ele ou um


11

seu semelhante efectua. Esses registos podem servir de base para a construção de

algoritmos que podem ser executados com sucesso por um outro ser inteligente (ou

sistema automático). Um dos primeiros registos bibliográficos deste tipo de procedimento

(formalização/idealização de um algoritmo), data do século V A.C., sobre um pedido de

Sócrates a Euthyphro para encontrar as características de “bondade” que tornam as acções

boas de modo que, a partir delas, se possa formar um juízo sobre as acções de qualquer

pessoa (Russel e Norvig, 1995).

A formalização de algoritmos é de tal importância que deve ser incutida aos alunos

para estes efectuarem uma boa resolução de problemas. A capacidade de resolver

problemas não apenas em cadeiras de programação, mas também numa vasta panóplia de

disciplinas, bem como a necessidade de os alunos lidarem com problemas diários tem

conduzido muitos educadores a concluir que ensinar a pensar e a resolver problemas tem

de passar a constituir uma prioridade nas escolas (Bitter 1985; de Bono, 1983;

Frederickson, 1984; Gagne, 1977; Pea e Kurland, 1984). Programas para desenvolver as

capacidades de pensamento e resolução de problemas são evidentes em muitas escolas (de

Bono, 1983; Mackey, 1977). Tentenbaum e Mulkeen (1984) sugeriram que uma possível

explicação para o fluxo massivo de computadores nas escolas consistia na expectativa de

que eles facilitassem a aprendizagem e resolução de problemas.

Mas, será que as capacidades de pensamento e a arte de resolução de problemas

em geral podem ser transmitidas e explicadas? A opinião consensual entre muitos

psicólogos e investigadores educacionais é a de que estas podem ser explicitamente

ensinadas (de Bono, 1983; Frederickson, 1984; Hayes, 1980). Porém, na nossa opinião, o

que é importante é que se dêem aos alunos oportunidades frequentes para praticar a

resolução de problemas numa variedade de contextos para que eles realmente se tornem

proficientes nessa tarefa. Apesar de haver determinadas estratégias e orientações que se

podem ministrar aos alunos para que eles aprendam a resolver problemas, eles só

aprenderão a resolvê-los resolvendo-os, especialmente resolvendo os problemas reais, que

os confrontam nas suas vidas diárias dentro e fora da escola (Glen e Ellis, 1982). Quanto

mais oportunidades se dão aos alunos para lidar com problemas, mais eficientes eles se

tornam como resolvedores de problemas (Schuncke e Hoffman, 1980).

Dado o relevo apresentado por vários autores para a capacidade de resolver

problemas em diversas áreas e a importância que esta habilidade apresenta, na nossa

opinião, para um bom desempenho em disciplinas de programação, coloca-se a seguinte


12

questão: será que deveria existir uma cadeira específica onde se ensinasse a resolver

problemas genéricos? Pensamos que deveria existir uma disciplina dedicada

exclusivamente à resolução de problemas. Essa disciplina teria uma forte componente

lúdica, mas abordaria aspectos elementares relacionados com questões práticas do curso

em questão. Porém, enquanto não for possível a implementação desta medida, pensamos

que o que deve acontecer é, em cada matéria específica, cada professor estimular e ensinar

a resolução de problemas dentro dos contextos específicos das matérias que leccionam.

Também Greeno (1980) recomendou que a educação fosse dirigida para o ensino da

“resolução de problemas em domínios específicos” em vez de “resolução de problemas

em geral”.

Porém, na nossa opinião, as estratégias de resolução de problemas só funcionam se

os alunos tiverem algum conhecimento sobre os conteúdos em questão. Assim, a sugestão

apontada para a criação da disciplina dedicada à resolução de problemas teria também

como função ensinar conceitos básicos muitas vezes esquecidos ou nunca percebidos

pelos alunos. Essa disciplina funcionaria como um ensino de cultura geral específica do

curso em causa. O professor teria como função, para além de lançar os problemas,

encaminhar os alunos no sentido da sua resolução, detectando as partes não entendidas

por eles, orientando-os assim para o estudo de determinados tópicos e assuntos. Também

Greeno (1980) afirma que todas as actividades de resolução de problemas envolvem

algum conhecimento, mesmo se esse conhecimento estiver na forma de estratégias gerais

para analisar situações e soluções. Salienta ainda que, na maioria das situações, é

impossível aplicar as capacidades de resolução de problemas sem ter um conhecimento

extensivo e específico do domínio em causa. Este é também um dos grandes problemas

que afectam as cadeiras de programação, os alunos não sabem resolver os problemas na

maioria das vezes porque desconhecem os conceitos e matéria subjacente. Existe, na

generalidade, uma enorme carência de hábitos de trabalho por parte dos alunos que em

cadeiras mais exigentes como estas poderão ser fatais.

Outra questão que se coloca é a de quando e em que situações é que as

capacidades de resolução de problemas são transferíveis entre domínios. Por exemplo,

será que as capacidades de resolução de problemas aprendidas em matemática e lógica se

podem aplicar à programação? Apesar de haver muitos teóricos que acreditam que esta

transferência é possível (de Bono, 1983; Feuerstein, 1980; Simon, 1980) é raro encontrar

evidência empírica de transferência espontânea das capacidades de resolução de


13

problemas entre domínios (Brown e Ferraro, 1985; Frederickson, 1984; Gagne, 1977;

Krasnor e Mitterer, 1984). Mesmo muitos daqueles que prometem o ensino de

capacidades gerais de resolução de problemas reconhecem que a transferência entre

domínios é difícil e talvez mesmo improvável (Frederickson, 1984; Newell, 1980; Simon,

1980). Muitas das dificuldades da transferência entre domínios e mesmo dentro do mesmo

domínio entre problemas diferentes parecem envolver o processo de reconhecimento de

que a nova situação é similar a situações previamente encontradas (Brown et al., 1983).

Se as pessoas são incapazes de detectar um relacionamento entre uma nova situação e

outras previamente encontradas é difícil de verificar como é que a transferência pode

ocorrer (Brown et al., 1983).

Uma vez que, na nossa opinião, a capacidade de resolução de problemas está

relacionada com a capacidade de raciocínio lógico do processo de pensamento, qual a

relação existente entre aprender a programar e aprender a pensar?

Papert (1980) argumenta que, quando as crianças têm a possibilidade de

desenvolver programas em LOGO, “são desenvolvidas poderosas capacidades intelectuais

nesse processo”. De forma análoga, Bork (1981) vê “…o processo de programação como

um veículo para treinar…o pensamento analítico aplicável a grandes classes de

problemas”. Nickerson (1982) argumenta que devemos ver “a programação como um

veículo para ensinar as capacidades do pensamento”. Em Mayer et al. (1986) é

apresentado um estudo sobre a relação entre aprender a programar e aprender a pensar,

baseado numa análise cognitiva da programação. Primeiramente os autores definem os

seus conceitos sobre “aprender a programar” e “aprender a pensar”. No contexto desse seu

artigo aprender a programar refere-se à aprendizagem inicial de uma primeira linguagem

de programação por parte de um aluno. Aprender a pensar refere-se aos aperfeiçoamentos

da capacidade de resolução de problemas em domínios para além da linguagem de

programação que é ensinada. Os autores chegaram então às seguintes conclusões

relativamente à relação entre “aprender a programar” e “aprender a pensar”:

1º Aprender a programar melhora as capacidades de pensamento das pessoas.

2º Certas capacidades de pensamento melhoram a aprendizagem da programação.

3º A preparação e treino prévio em certas capacidades de pensamento melhora a

aprendizagem de programação.

Também Linn (1985) sugeriu as seguintes três “realizações cognitivas” possíveis,

tendo como base o aprender a programar numa linguagem como o BASIC:


14

1º Aprender as características da linguagem como por exemplo as declarações

LET, PRINT e INPUT.

2º Aprender a resolver problemas de programação, tais como conceber programas

em BASIC.

3º Aprender as capacidades de resolução de problemas aplicáveis a outros

sistemas, como por exemplo resolução de problemas noutras linguagens de programação.

O uso da programação para ensinar as capacidades de resolução de problemas foi

popularizado pela introdução da linguagem LOGO. Algumas das capacidades de

resolução de problemas associadas com o LOGO incluem: capacidade de particionar os

problemas em subproblemas mais facilmente manipuláveis; planeamento sistemático das

acções para alcançar objectivos e desenvolvimento de uma atitude mais positiva

relativamente aos erros (Krasnor e Mitterer, 1984). A programação é um tipo de resolução

de problemas, assim é possível que as capacidades aprendidas em programação possam

ser transferidas para outros tipos de resolução de problemas (Krasnor e Mitterer, 1984). E

será que o contrário também não se verifica? Na nossa opinião, a capacidade de resolução

de problemas que em programação se traduz na capacidade de elaboração de algoritmos

constitui o aspecto mais importante para a aprendizagem e desenvolvimento da

capacidade de programar.

Uma vez que não existem regras rígidas a seguir para a elaboração eficaz de

algoritmos de programação, segue-se um conjunto de directrizes que, na nossa opinião,

poderão auxiliar o aluno na tentativa de resolução de problemas nesta área.

Em primeiro lugar, o aluno deverá meditar sobre um conjunto de questões que o

ajude a definir a natureza do problema. Ou seja, para a elaboração de um programa

computacional, os alunos deveriam apostar em primeiro lugar no entendimento geral do

problema em questão, assegurando-se sobre a compreensão dos dados e incógnitas do

problema, bem como das condições a satisfazer. Porém, muitas vezes as condições são

complexas pelo que os alunos devem tentar várias estratégias para as simplificar. Os

estratagemas podem ser variados, entre eles, dividir o problema sistematicamente noutros

mais simples, tentando resolver o problema com menos elementos mantendo apenas parte

das condições, deixando as outras de lado e verificar até que ponto fica determinada a

incógnita. Se esta estratégia não resultar porque não simplificar determinados aspectos do

enunciado, aproximando-se sucessivamente da solução, ou então, porque não imaginar o


15

problema resolvido? Ao tentar construir, de forma aproximada, uma figura mental, de

como deve funcionar, o aprendiz terá a oportunidade de explorar as relações entre os

elementos dados e os que procura. Uma ajuda muitas vezes útil consiste na elaboração de

esquemas, com notações adequadas. De seguida deve tentar elaborar estratégias para

“atacar” o problema, por exemplo, estabelecendo analogias com outros problemas

conhecidos e com ele relacionados, formando um juízo sobre quais delas têm mais

probabilidades de êxito.

Um outro problema muito frequente consiste na incapacidade de o aluno, após a

determinação de um modelo de solução, a seu ver correcto, detectar erros lógicos da sua

resolução. Assim, convém examinar e reflectir sobre a solução obtida e sobre todo o

processo, verificando se o argumento funcionou, porquê e se não existem formas

alternativas de resolver o mesmo problema. Ou seja, o aprendiz deve ponderar se a sua

proposta de solução atinge as especificações pretendidas, decidindo que dados ou outras

condições pode/deve alterar para que a solução construída funcione na sua plenitude, ou

seja, quais os refinamentos a fazer. Qualquer erro descoberto deve ser corrigido de tal

forma que o algoritmo modificado realize correctamente as exigências do problema. Desta

forma, mesmo que a solução proposta não satisfaça completamente os requisitos exigidos,

provavelmente o aluno aprenderá muito ao verificar e corrigir o erro lógico do seu

raciocínio. Muitas vezes aprende-se muito mais, e mais profundamente, com os problemas

que se tentaram resolver sem sucesso mas com interesse e persistência, do que com os que

se resolvem quase à primeira tentativa, pois o erro pode ser instrutivo, e os alunos podem

aprender tanto com os sucessos quanto com os insucessos.

Outra atitude fundamental que o aluno não deve esquecer é, após ter resolvido o

problema com sucesso, analisar profundamente a sua solução e verificar se não é possível

conseguir uma outra mais simples, pois a resolução de problemas envolve simplificação.

É ainda necessário que o aluno reflicta sobre todo o processo realizado, sobre as

dificuldades que encontrou e como as superou para que futuramente possa resolver

melhor outros problemas. Repetindo experiências como esta, talvez o aluno consiga fazer

um diagnóstico do seu próprio estilo de conhecimento e pensamento que o auxilie na

obtenção de soluções e na descoberta de certos conceitos errados que possui sobre as

técnicas utilizadas.


16

22..22 FFoorrmmaass ddee rreepprreesseennttaaççããoo ddee aallggoorriittmmooss Uma questão que mereceu profunda reflexão para a realização deste trabalho diz

respeito à forma de construção da própria resolução do problema, ou seja, ao formato a

utilizar pelo aluno para representar algoritmos. Assim, e antes de justificar a escolha por

nós realizada, é feita uma breve referência a estudos de vários investigadores que se

debruçaram sobre esta temática, nomeadamente comparando a utilização de fluxogramas

e pseudocódigo.

David Scanlan, professor na California State University em Sacramento, começou-

se a envolver com a pesquisa sobre fluxogramas estruturados em 1981 enquanto

ministrava um curso de Estruturas de Dados. Durante esse curso descobriu,

acidentalmente, que a grande maioria dos seus alunos preferiam fluxogramas estruturados

em detrimento de pseudocódigo para a compreensão dos algoritmos apresentados. Mas

porquê esta preferência? Os defensores dos fluxogramas e a maioria dos alunos

argumentam que é pelo facto de melhorarem a compreensão. Porém, os críticos desta

forma de representação dos algoritmos afirmam que os alunos simplesmente gostam de

olhar para as figuras, são por elas atraídos, mas que isso não melhora a compreensão.

A sua observação foi posteriormente confirmada em estudos por ele realizados em

4 escolas, envolvendo 42 turmas da cadeira de Estruturas de Dados num total de 554

alunos (Scanlan, 1989). Na sua experiência Scanlan comprovou as seguintes hipóteses

sobre a utilização dos fluxogramas estruturados relativamente ao pseudocódigo para o

entendimento de algoritmos:

♦ levam significativamente menos tempo a compreender;

♦ produzem significativamente menos erros na compreensão;

♦ dão aos alunos mais confiança na compreensão de um algoritmo;

♦ reduzem o tempo gasto ao responder a questões sobre um algoritmo;

♦ reduzem o número de vezes que os alunos necessitam de analisar/rever um

algoritmo.

Em resumo, Scanlan, colocou a hipótese de que os fluxogramas estruturados

apresentam melhor desempenho do que o pseudocódigo sob todas as condições

experimentais. Estas hipóteses foram por ele testadas e confirmadas em 3 algoritmos de

complexidade variável, constatando ainda que, quanto mais complexo o algoritmo mais

benéfico os fluxogramas se revelaram. Segundo ele, os resultados mais surpreendentes


17

foram para a grande diferença a favor dos fluxogramas quando aplicados a algoritmos

simples, pois nestes casos esperava apenas uma pequena diferença.

Scanlan argumenta ainda que é possível que a maioria dos investigadores que não

encontraram diferenças significativas entre os fluxogramas e o pseudocódigo, no que

respeita à compreensão dos algoritmos, tenham usado fluxogramas não estruturados ou

então a sua metodologia experimental falhou. Argumenta ainda que, para os

investigadores que não encontraram diferenças na compreensão entre a utilização de

fluxogramas e pseudocódigo concluírem que não há diferenças, só porque eles não as

encontraram, constitui um sério erro de estatística e investigação. Scanlan acrescenta

ainda que, quando não são encontradas diferenças significativas, a única afirmação que se

pode fazer é que “os resultados são inconclusivos”.

Wright e Reid (1973), também acharam que os fluxogramas representavam

vantagens sobre as representações verbais/textuais. Estudos por eles realizados

verificaram que assim que a complexidade do algoritmo aumenta, aumenta também a

necessidade de representações gráficas. Estes autores demonstraram que quando os

algoritmos eram complexos, os alunos cometiam menos erros ao usarem fluxogramas.

Porém, quando os algoritmos eram extremamente simples não encontraram diferenças na

utilização de uma ou outra forma de representação de algoritmos.

Porém, pensamos que toda a gente concorda que também se podem obter

benefícios usando outros métodos que contribuem para um melhor entendimento de um

programa/algoritmo, entre eles a indentação, a atribuição de nomes adequados às

variáveis, a utilização racional de comentários, a existência de linhas em branco a separar

determinadas estruturas, entre outros. Também Miara et al. (1983) constataram que a

compreensão do código era melhorada quando o código era indentado, e como tal mais

espacial, verificando que a informação espacial em geral parece contribuir para a

compreensão dos algoritmos.

Shneiderman et al. (1977) conduziram uma série de experiências que tentavam

avaliar a efectividade dos fluxogramas na construção, debugging, compreensão e

modificação de programas. Três das 5 experiências tentaram medir como é que os

fluxogramas afectam a compreensão. Nessas experiências, constataram que os

fluxogramas não contribuíam significativamente para a compreensão dos programas

quando comparados com outras técnicas de representação como o uso do Fortran.

Subsequentemente, concluíram que “fluxogramas detalhados constituem meramente uma

apresentação redundante da informação contida nas declarações do programa”. E, uma


18

vez que os fluxogramas detalhados podem ser simplesmente uma representação

alternativa da sintaxe de um programa, não deverá ser útil para programadores familiares

com uma linguagem de programação. Os autores estabelecem ainda a seguinte analogia

“ter uma receita em Francês para além de uma versão em Inglês da mesma receita não

será vantajoso para um cozinheiro entendido em ambas as línguas”. Ou seja, para estes

autores os fluxogramas não transportam nem mais nem menos informação do que o

código de um programa. Porém, o público alvo do SICAS não são pessoas entendidas

nem familiares com linguagens de programação, além disso o SICAS dá especial ênfase à

construção de algoritmos e não apenas à sua simulação e compreensão.

A escolha para a construção de resoluções de problemas no SICAS foi tomada no

sentido de privilegiar o uso de representações gráficas (fluxogramas), em detrimento de

especificações verbais (pseudocódigo), não apenas pelos estudos analisados mas por uma

forte convicção de que esse modelo de descrição dos algoritmos apresenta enormes

vantagens. Os benefícios a nosso ver essenciais assentam nos pressupostos de que essa

forma de representação é mais apelativa prendendo mais a atenção do aluno, tira mais

partido do potencial do sistema visual humano para facilitar a compreensão, é mais clara e

está menos sujeita a erros. De seguida são apresentadas algumas opiniões por parte de

vários estudiosos que reforçam estes argumentos.

Muitas são as publicações que argumentam que os sistemas que permitem a

representação visual dos programas são naturalmente superiores a outras formas

tradicionais/textuais, na medida em que são mais amigáveis do utilizador (Chang, 1990),

apelativas (Karsai, 1995), atractivas (Lodding, 1983), agradáveis (Costagliola et al.,

1995), intuitivas (Tanimoto e Glinert, 1986), legíveis (Edel, 1986), familiares (Repenning

e Sumner, 1995), imediatas e óbvias (Tanimoto e Glinert, 1986), fáceis de aprender

(Kimura et al., 1995), fáceis de compreender (Tanimoto e Glinert, 1986), fáceis de usar

(Burnett et al., 1995), fáceis de escrever (Myers, 1986), e modificar (Goldberg et al.,

1995), úteis (Glinert, 1990) satisfatórias (Glinert e Gonczarowski, 1987), acessíveis e

fiáveis (Burnett et al., 1995). Também muitos são os autores que argumentam que as

representações visuais ajudam a expressar a natureza do problema, afirmando que as

relações entre as coisas são mais explicitamente representadas e facilmente reconhecidas

em figuras do que em texto (Schiffer e Fröhlich, 1995), principalmente no domínio da

programação, ajudam a exprimir a estrutura do problema.


19

Também, como meio de comunicação entre o programador e o computador, as

linguagens de programação são muitas vezes comparadas com a linguagem humana.

Muitos autores sugeriram que as pessoas sempre, ao longo dos tempos, acharam natural

comunicarem com imagens (Lodding, 1983), que as figuras constituem uma forma de

comunicação universal (Tanimoto e Glinert, 1986). Mas será que as figuras contêm mais

informação do que um texto descritivo da mesma situação? Esta crença metacognitiva

pode ser derivada do ditado “uma imagem vale mais do que mil palavras”. O conteúdo de

informação superior das figuras em relação ao texto é muitas vezes explicado em termos

de teorias cognitivistas. Também em termos de senso comum temos a percepção que uma

figura é mais fácil de memorizar e recordar do que uma descrição textual do seu conteúdo.

Um outro argumento a favor da representação visual ou gráfica é a de que esta

forma de representação da informação se encontra mais próxima do mundo físico do que

as representações textuais (Lodding, 1983). Como resultado, a manipulação de entidades

visuais emprega as mesmas aptidões que usamos no mundo real quando manipulamos

objectos (Cox, 1986). O argumento de que as representações visuais são mais parecidas

com o mundo físico do que as puramente textuais é suportado pela observação de que

“nós vivemos num mundo visual onde as imagens abundam” (Lodding, 1983).

A utilidade das representações gráficas pode também ser constatada se atendermos

à capacidade impressionante do cérebro humano para processar imagens. Assim, alguns

autores argumentam que a memória humana está optimizada para a visão (Myers, 1986;

Duisberg, 1988), fazendo com que as formas sejam mais fáceis de processar do que as

palavras (Huang, 1990; Ford e Tallis, 1994).

Também, segundo alguns autores, a informação gráfica é mais intuitiva do que a

textual, possibilitando o uso da “inteligência inata” (Glinert e Tanimoto, 1987) e

fornecendo “interacção intuitiva” (Costagliola et al., 1995). O facto de que as coisas

intuitivas são mais fáceis de entender, faz com que as representações gráficas também o

sejam (Yeung, 1990). Esta evidência pode ser constatada sempre que os especialistas nos

mais variados domínios escolhem a representação através de diagramas quando

pretendem entender situações complexas (Dillon et al., 1994). Porém, a capacidade de

interpretar um diagrama envolve, por vezes, a existência de qualificações mais complexas

e convenções sobre os elementos em causa.

Pensamos que é genericamente aceite que a programação visual é importante e

necessária para comunicar ideias aos outros. Teóricos como Arnheim (1969) têm

promovido o conceito de pensamento visual desde há vários anos. O pensamento visual é


20

não apenas uma habilidade para interpretar a informação visual mas também uma

capacidade para criar imagens nas nossas próprias mentes, para nos ajudar a armazenar

informação, tomar decisões e resolver problemas. É uma forma de criar e armazenar

informação mentalmente e não apenas de processamento visual da informação.

As representações visuais apresentam também a vantagem de permitir que os seus

utilizadores visualizem as operações do programa (Chang et al., 1995), possibilitando-

lhes formar uma melhor imagem/modelo mental do que as textuais (Lord, 1994). Também

Paivio (1969), argumentou que as figuras são mais fáceis de lembrar do que as palavras,

devido à “superioridade mnemónica” da imagem sobre o código verbal. Constatou

também que o uso de figuras ajuda os alunos a desenvolverem uma atitude positiva da

aprendizagem/instrução e consequentemente, torna a aprendizagem numa tarefa mais

agradável.

Para concluir refira-se ainda algumas razões que Clarke (1992) considera

elementares para usar figuras/ilustrações e que estiveram na base da opção da construção

de algoritmos através de fluxogramas, em detrimento de pseudocódigo, no SICAS:

♦ amplificar, informar, persuadir, sumariar, exemplificar, simplificar ou explicar

material incluído no texto;

♦ apresentar informação de um modo diferente para ajudar a aprendizagem;

♦ focar a atenção do aluno;

♦ estimular o aluno.

22..33 FFeerrrraammeennttaass ddee ssuuppoorrttee àà aapprreennddiizzaaggeemm ddee pprrooggrraammaaççããoo

22..33..11 SSiisstteemmaass O ensino da programação usando sistemas assistidos por computador tem sido

tentado desde os finais dos anos 70. Vários sistemas têm sido construídos usando diversas

técnicas pedagógicas e recorrendo a diversas áreas como Multimédia, Engenharia de

Software, Inteligência Artificial, entre outras. Existem diversos tipos de aplicações, como

os sistemas de tutores inteligentes, os ambientes de aprendizagem ou as sub-linguagens

dedicadas aos mais variados domínios. Com aplicação no ensino da programação

destacam-se os seguintes meios automatizados: Incense (Myers, 1983), Provide (Moher,

1988), CLAP (Meisalo et al., 1996), Programação Assistida por Computador (Santos et


21

al., 1996), MRUDS (Hanciles et al., 1997), Automatic Array Algorithm Animation in

C++ (Rasala, 1999), Flint (Ziegler e Crews, 1999), Testers and Visualizers for Teaching

Data Structures (Baker et al., 1999).

Outros exemplos de aplicações nesta área são os micro-mundos, seriamente

influenciados pelos gráficos da tartaruga do LOGO (Papert, 1980). O LOGO não foi

concebido especificamente com o propósito de ensinar programação, mas o “subconjunto

da tartaruga” surge como sendo um bom instrumento para introduzir conceitos de

programação a alunos sem qualquer experiência neste domínio. Como exemplos típicos

de micro-linguagens com aplicações na área de programação destacam-se, entre outros:

Karel the robot (Pattis, 1981), Josef the robot, (Tomek, 1982), Martino, (Olimpo et al.,

1985), PMS (Tomek et al., 1985), Robot Brothers (Olimpo, 1988), Marta (Calabrese,

1989), Pascal Genie (Miller e Chandhok, 1989), Turingal (Brusilovsky, 1991), Karel-3D

(Hvorecky, 1992), Darel (Kay e Tyler, 1993), Tortoise (Brusilovsky, 1993) e Turtle-

Graph (Jehng et al., 1994).

Também os sistemas de animação/visualização de software têm sido muito usados

com o propósito de facilitar a compreensão da programação apelando ao potencial do

sistema visual humano. Assim, uma vez que os programas computacionais podem ser

pouco claros quando apresentados num formato textual, é esperado que o formato gráfico

animado contribua para uma melhor compreensão. Os sistemas de visualização de

programas variam desde programas de baixo nível de detalhe, que mostram manipulações

de estruturas de dados, até programas com um nível mais global de profundidade, como

os que mostram o seu propósito e metodologias. Os sistemas que apresentam uma

visualização abstracta global de mais alto nível são designados de sistemas de

visualização de algoritmos. Muitas vezes, estes sistemas apresentam uma visualização

contínua/progressiva do programa durante a sua execução, adquirindo o nome de

animação de algoritmos. Deste tipo de sistemas há que destacar os seguintes: ANTICS

(Dionne e Mackworth, 1978), BALSA (Brown e Sedgewick, 1985), SEE (Baecker e

Marcus, 1986), ANIMUS (Duisberg, 1988), BALSAII (Brown, 1988), VIP (Mendes e

Mendes, 1988), ALLADIN (Helttula et al., 1989), GAIGS (Naps, 1990), TANGO

(Stasko, 1990), ANIM (Bently e Kerninghan, 1991a), ZEUS (Brown, 1991), Pavane

(Roman et al., 1992), VCC (Baeza-Yates et al., 1992), XTANGO (Stasko, 1992), POLKA

(Stasko e Kraemer, 1993), DRUIDS (Whale, 1994), FLAIR (Ingargiola et al., 1994),

POLKA-RC (Stasko e McCrickard, 1995), JAWAA (Pierson and Rodger, 1998), ALMA

(Varanda e Henriques, 1999).


22

Baseados na crença de que existem vantagens cognitivas em utilizar metodologias

gráficas em vez de textuais, outras propostas, para ensinar programação, foram para a

criação de linguagens de programação baseadas em ícones, de que se destacam o BACII

(Calloni e Bagert, 1993) e o BACII++ (Calloni et al., 1996) e de design languages de que

é exemplo o G2 (Ellis e Lund, 1994).

Para apoiar o ensino da programação foram também desenvolvidos diversos

sistemas recorrendo a variadas técnicas existentes em inteligência artificial, de que são

exemplo o Lisp Tutor (Anderson e Reiser, 1985), Proust (Johnson e Soloway, 1985), TPM

(Eisenstadt e Brayshow, 1988), Ceilidh (Benford e Burke, 1993), COACH (Selker, 1994),

ADAPT (Fix e Wiedenbeck, 1996), Loop Tutor (Tyerman et al., 1996) e C-Tutor (Song et

al., 1997).

Também na World Wide Web, é possível encontrar alguma diversidade de

projectos/cursos para apoiar diversos assuntos abordados no ensino da programação,

aplicados às mais variadas linguagens, destacando-se os seguintes locais:

♦ CTC (Center for Teaching Computing) – CTC Online Courses

(http://www.ctc.dcu.ie/ctcweb/courses.html)

♦ CTI (Computers in Teaching Initiative) – Computer Science Courses on WWW

(http://www.ulst.ac.uk/cticomp/ukcourse.html)

♦ Coronado Enterprises Tutorials

(http://www.swcp.com/~dodrill)

♦ Heriot-Watt University of Edinburg – Department of Computing & Electrical

Engineering

(http://www.cee.hw.ac.uk/~pjbk/pathways)

♦ Montana State University – Dynalab Project

(http://www.cs.montana.edu/~dynalab)

♦ University of Cardiff – Department of Computer Science

(http://www.cm.cf.ac.uk/Dave/JAVA)

♦ University of Nottingham – Computer Science Department

(http://www.cs.nott.ac.uk/~ceilidh)

♦ University of Washington – Department of Computer Science

(http://cs.washington.edu/homes/amir/Opsis)


23

22..33..22 EEssttuuddooss O facto de os programas computacionais serem inerentemente dinâmicos sugere

que as operações e interacções dos algoritmos sejam, em geral, melhor descritas por meio

de representações visuais dinâmicas. Isto faz-nos acreditar que a capacidade de animação

de um algoritmo seja uma das principais características a ter em conta na construção de

uma ferramenta com o propósito pretendido. Antes porém de apontar as características

que, a nosso ver, são importantes existir numa ferramenta deste tipo, são apresentados

alguns estudos empíricos com o intuito de verificar a importância da utilização de

animações/visualizações, na compreensão e resolução de problemas computacionais. A

maioria deles constatou a valiosa contribuição do apelo visual dinâmico para a formação

de conceitos, em detrimento da apresentação de imagens estáticas. Revelou também uma

vantagem significativa da animação com elevados níveis de interactividade e a eficácia da

utilização de animações e representações visuais em contraposição às linguagens textuais,

para a compreensão de algoritmos e programas computacionais.

No Georgia Institute of Technology foi conduzido um estudo que tinha como

finalidade medir a eficácia da utilização de algoritmos animados, em várias estratégias de

ensino (Lawrence et al., 1994). Essas estratégias variaram no nível de controlo e

envolvimento activo dos alunos. A experiência foi conduzida num ambiente de sala de

aula e os objectos do estudo foram alunos de ciências da computação que frequentavam o

primeiro curso de programação. As animações algorítmicas utilizadas foram criadas com

os sistemas XTANGO (Stasko, 1992) e POLKA (Stasko e Kraemer, 1993). Foram

estudadas diversas variáveis, incluindo o estilo de apresentação do algoritmo animado

(animação ou transparências), o uso de uma sessão laboratorial para clarificar conceitos

algorítmicos e a interacção dos alunos com a animação durante a sessão laboratorial (onde

um grupo recebeu conjuntos de dados preparados e outro grupo criou os seus próprios

conjuntos de dados). O algoritmo estudado foi o “Kruskal's Minimum Spanning Tree”.

Após as sessões a que foram sujeitos, incluindo várias estratégias de ensino, os diversos

grupos realizaram um teste on-line de questões tipo verdadeiro/falso e de escolha múltipla

cuja finalidade era a de testar a compreensão acerca do algoritmo e sua aplicação. Para

além disso, os alunos também efectuaram um teste de respostas livres no papel, cuja

finalidade era a de verificar a sua capacidade em articular conceitos relacionados com a

compreensão do algoritmo. As conclusões obtidas pelos autores do estudo foram as

seguintes:


24

♦ Nos testes de resposta livre os grupos sujeitos a condições laboratoriais activas

(onde os alunos participaram na construção das animações) obtiveram

pontuações significativamente mais elevadas do que todos os outros grupos,

incluindo os sujeitos a condições laboratoriais passivas (onde os alunos se

limitavam a observar as animações, com reduzida participação e intervenção).

Isto foi mais visível nas questões que exigiam conhecimentos a nível mais

profundo (testes de resposta livre). As questões neste tipo de teste exigiam a

chegada a conclusões a partir das questões colocadas, bem como a

demonstração de uma outra versão do algoritmo.

♦ Os alunos que receberam a sessão laboratorial (activa ou passiva) obtiveram

melhores resultados nos testes on-line com questões do tipo verdadeiro/falso e

de escolha múltipla, mas sem que tal diferença se revelasse significativa. Isto

indica, segundo os autores, que a participação laboratorial dos alunos é mais

relevante em questões que requerem mais conhecimento conceptual do que em

questões mais básicas, como as que apenas requerem o reconhecimento dos

passos individuais do algoritmo.

♦ A utilização de exemplos quer através de animações ou transparências não faz

muita diferença no processo de ensino do algoritmo. Isto poderá ser explicado,

pelo facto de ambos estes métodos usarem técnicas visuais passivas, uma vez

que em qualquer dos casos não há interacção ou intervenção do aluno com a

representação do algoritmo.

Outros estudos corroboram estes resultados, por exemplo Shih e Alessi (1994)

mostraram que os benefícios e contributos da animação, para uma melhoria da capacidade

dos alunos resolverem problemas procedimentais e conceptuais acerca de algoritmos são,

na sua maioria, significativos, constatando que existe alguma evidência indirecta de que a

animação faz com que o conhecimento seja adquirido mais rapidamente.

Outros estudos analisados indicam também que as animações, para serem eficazes,

têm de permitir interacção e vários níveis de controlo pelo aluno. É o facto de os alunos

intervirem activamente numa animação, participando na sua construção e reconstrução,

explorando várias estratégias de resolução de problemas que provavelmente os ajudará a

resolver novos problemas. Os estudos publicados por Stasko et al. (1993), Ramani e Rao

(1994) e Kann et al. (1997) também demonstraram a influência da dimensão activa versus

passiva na aprendizagem. Estes autores reafirmaram a ideia de que as animações para


25

serem eficazes têm de ser usadas como parte de um conjunto educacional mais vasto, em

que os alunos podem beneficiar da construção do algoritmo que é uma aprendizagem

activa em oposição à sua simples visualização que é uma aprendizagem passiva.

Com base nos estudos analisados, pode-se afirmar que, para o tipo de matérias

referidas é vantajoso utilizar meios animados em detrimento de materiais não animados,

essencialmente devido aos seguintes aspectos:

♦ possibilidade de inclusão, numa animação, de elementos que podem fornecer

informação mais detalhada ao aluno, não facilmente discernível de outra forma;

♦ possibilidade de os alunos verificarem como é que determinados conjuntos de

dados afectam o funcionamento do algoritmo;

♦ possibilidade de execução e simulação das resoluções do problema em tempo

real, traduzindo-se num melhor estudo e compreensão do comportamento do

algoritmo;

♦ os alunos são normalmente seduzidos por projectos que envolvam animações

em detrimento de materiais estáticos.

Porém, para que a animação seja mais efectiva, ela não deverá ser usada

isoladamente mas como uma parte integrante da experiência de aprendizagem. Na

realidade, também pensamos que o verdadeiro valor de uma animação reside não na sua

simples visualização, que permite um reduzido nível de interactividade, mas na

capacidade de permitir que o aluno intervenha, construa, explore, modifique, experimente

e teste as suas teorias, ou seja, permita vários níveis de interacção. A consideração da

animação aliada à interactividade foi uma das principais preocupações a que se deu

particular destaque no SICAS.

Pensamos, contudo, que o sucesso de um programa educativo depende não apenas

da sua funcionalidade mas também da sua interface com o utilizador. Porém, a concepção

de uma boa interface com fins educativos é uma tarefa exigente e não pode esquecer o seu

objectivo principal – conduzir o aprendiz a uma determinada acção. Para tal, deve possuir

um conjunto de características que consideramos fundamentais e que tentámos seguir

aquando da concepção do SICAS, nomeadamente os que apresentamos de seguida.

♦ Ser visualmente organizado. O aspecto visual da informação constitui um factor

importante da concepção de um programa. Diversos estudos sobre a memória humana


26

mostram unanimemente que o material bem organizado é percebido, retido, compreendido

e melhor apreendido do que material idêntico não organizado (Haber e Wilkinson, 1982).

Assim, pensamos que a organização visual da informação a apresentar nos ecrãs é crucial

para a sua utilização plena. Também Mullet e Sano (1995) são da opinião de que uma

organização visual clara é essencial para uma efectiva comunicação.

♦ Ser simples, óbvio, intuitivo e fácil de navegar. O material apresentado deve ser

simples de utilizar, óbvio e intuitivo, de fácil apreensão, exigindo pouco tempo de

aprendizagem, para que o aluno não fique desencorajado à partida. Porém, isto não

significa que o ambiente criado não deva ser rico e poderoso, pois os iniciados em

determinada matéria necessitam de sistemas persuasivos e sofisticados e não de sistemas

simplistas como a maioria das vezes se pensa (muitas vezes a simplicidade apenas é

apreciada nos primeiros momentos de contacto com uma nova aplicação). Além disso,

deve permitir que tudo o que seja relevante para as tarefas do aluno surja visível no ecrã.

Sem esta visibilidade torna-se quase impossível alcançar uma interface fácil de usar.

Também Tullis (1988) afirma que, se a informação visualizada for confusa ou não

fornecer aos utilizadores o que eles precisam, o seu desempenho diminuirá. É também

importante que o utilizador seja capaz de encontrar facilmente a informação que precisa,

pelo que a interface deverá estar estruturada de modo a ser fácil navegar através dela

(Preece et al., 1994).

♦ Conter apenas a informação essencial. Pensamos que se deve evitar a

sobrecarga de informação, ou seja, o ambiente criado deve conter apenas a informação

relevante e essencial, para evitar o aborrecimento ou desinteresse por parte do utilizador e

para que haja uma melhor orientação do utilizador para que em etapa alguma se sinta

perdido com o excesso de informação. Por outro lado, é importante não esquecer que o

aprendiz é limitado no que respeita à quantidade de informação que pode armazenar num

dado momento, ou seja, apresenta uma capacidade limitada da memória de curto prazo ou

memória de trabalho. Smith e Mosier (1986) consideram que toda a informação que o

utilizador necessite, e apenas essa, deve estar disponível.

♦ Ser familiar. Pensamos que todo o sistema, que aborda assuntos sobre os quais

o utilizador eventualmente possui alguns conhecimentos, deve utilizar os termos e

convenções que ele habitualmente utiliza para esses mesmos conceitos. Isto por um lado,


27

para minimizar a distância conceptual entre as representações mentais que o utilizador

possui acerca de determinados conceitos e as representações que o programa em causa

apresenta. Por outro lado, porque há a tendência de, sempre que se deparam com uma

nova situação, as pessoas tendem a aplicar os conhecimentos que possuem e com os quais

são mais familiares.

♦ Ser consistente. Outro aspecto a nosso ver importante é que, seja qual for o tipo

de dados, se deve manter um formato consistente de ecrã para ecrã (Smith e Mosier,

1986). Shneiderman (1986) salienta que o princípio da consistência é o mais

frequentemente violado, sendo normalmente o mais fácil de reparar e evitar. Brown e

Cunningham (1989) distinguem duas componentes da consistência:

- Consistência no modelo mental do utilizador.

- Consistência com outros programas que realizam funções semelhantes, e que já

tenham comprovado a sua eficiência.

Assim, pensamos que deve existir consistência no formato apresentado, nas

convenções e terminologia.

♦ Ser flexível e configurável. Pensamos que é importante, num programa com as

características do SICAS, dar ao utilizador a possibilidade de adicionar, remover e alterar

os exemplos e exercícios propostos, sem que isso implique quaisquer alterações no seu

código. Atender ao princípio da flexibilidade significa considerar a diversidade de

preferências dos potenciais utilizadores e disponibilizar opções de trabalho de acordo com

essa diversidade. Cada grupo de utilizadores ou, idealmente, cada utilizador deve poder

trabalhar com o programa de acordo com as suas preferências e estilo cognitivo, mas não

de forma a que seja necessária a alteração da estrutura e formato do programa

apresentado. É desejável dar vários graus de liberdade ao utilizador, mas não

exageradamente, pois, por vezes, a existência de demasiadas alternativas e possibilidades

de escolha ao utilizador pode desvalorizar a importância do acto de escolher e acabar por

causar frustração em vez de satisfação (Miller, 1956). Esta consideração aplica-se

essencialmente a certo tipo de escolhas como por exemplo menus, e não à liberdade de

escolha de resolução de um problema.


28

♦ Ser poderoso. Para que dê ao aprendiz uma sensação de domínio e controlo

apropriado dos projectos que desenvolve e que, de outra forma, não desenvolveria,

permitindo uma melhor aprendizagem. Dar ao utilizador a sensação que está a controlar

como deseja o decurso de uma actividade frente ao computador pode ter um efeito muito

positivo, porém não será desejável que o aluno controle um determinado ambiente na sua

totalidade. Relativamente a este assunto, Gentner (1992) afirma que uma actividade de

ensino/aprendizagem com controlo misto concilia os benefícios de:

- Permitir ao aluno sentir que controla o que está a fazer, constituindo um aspecto

positivo que favorece a aprendizagem.

- Manter a actividade estruturada de forma a favorecer a aprendizagem, o que não

seria assegurado caso o utilizador possuísse controlo absoluto do ambiente de

aprendizagem.

No fundo pensamos que alguns dos critérios do conjunto que Daru (1985) definiu

genericamente como linhas orientadoras para a construção de gráficos, nomeadamente, a

clareza, a visibilidade, a simplicidade e a consistência são aplicáveis para a concepção

global de interfaces com o utilizador.

Porém, aquando da construção do SICAS, verificámos que nem sempre foi

possível seguir e articular um conjunto de regras rígidas sendo, muitas vezes, tomadas

decisões eventualmente não acertadas, mas que estavam relacionadas com experiências

anteriores. Assim, aconteceu frequentemente que as decisões foram tomadas com base em

compromissos entre alternativas estando sempre presente o objectivo de facilidade de

compreensão e interacção.

Cap. 3 - O SICAS

29

33 OO SSIICCAASS

33..11 IInnttrroodduuççããoo O programa educativo SICAS tem como finalidade apoiar a aprendizagem de

estratégias e mecanismos básicos de construção de algoritmos para resolver problemas de

programação, dando especial ênfase à utilização de estruturas de controlo como a selecção

e repetição. Pretende-se que o SICAS seja essencialmente uma ferramenta orientada para

a resolução de problemas, apresentando não uma abordagem expositiva dos assuntos a

ensinar/aprender mas antes, constituindo um ambiente que permita que o aluno

desenvolva as suas capacidades com base na experimentação e na prática. Neste contexto

é permitido ao aluno descobrir, construir, e perceber visualmente a forma como um dado

algoritmo funciona ou se comporta mediante certas circunstâncias, possibilitando-lhe

detectar eventuais erros, corrigi-los e através disso aprender. Estamos de acordo com

Figueiredo e Mendes (1985), quando afirmam que em vez de meramente obrigar o aluno a

absorver e a reter conhecimentos, a educação deve ser orientada para o desenvolvimento

do pensamento inventivo e da capacidade de aplicar de forma criativa a informação

disponível. Pretendemos que o SICAS seja um ambiente que permita uma aprendizagem

baseada na exploração e descoberta que, segundo Romiszowski (1981), consiste em:

♦ dar aos alunos oportunidades para agir e observar as consequências das suas

acções;

♦ testar a compreensão dos princípios, regras, ou conceitos envolvidos;

♦ testar as interpretações desenvolvidas sobre o princípio geral subjacente aos

casos estudados;

♦ dar aos alunos oportunidades para aplicação da informação recentemente

aprendida a situações ou problemas reais.

Cap. 3 - O SICAS

30

33..22 DDeessccrriiççããoo O SICAS prevê dois tipos diferentes de utilizadores: professores e alunos. Como

tal, de forma a permitir a existência de módulos com diferentes características consoante o

perfil apresentado, o utilizador terá que realizar em primeiro lugar a sua identificação.

33..22..11 MMooddoo PPrrooffeessssoorr Este módulo tem como objectivo principal permitir ao professor orientar e

verificar a actividade do aluno. Esta característica é especialmente importante na medida

em que o SICAS é passível de ser utilizado não apenas em ambiente de sala de aula, mas

também em sessões de estudo isoladas em que o aluno se encontra desprovido de um

acompanhamento especializado como aquele que é fornecido pelo professor. Assim, este

módulo permite ao professor indicar enunciados de problemas que pretende ver resolvidos

pelos alunos, fornecer soluções que os alunos podem consultar, testar e/ou editar. Estas

soluções poderão ser correctas ou incorrectas, completas ou incompletas, dependendo das

actividades pedagógicas que o professor pretenda que os alunos levem a cabo.

Utilizando este modo, o professor pode também aceder às resoluções produzidas

por cada aluno para os diversos problemas propostos. Desta forma poder-se-á aperceber

facilmente das dificuldades apresentadas por cada um deles e tentar as medidas que

entender adequadas em cada caso (por exemplo problemas com um nível de dificuldade

mais adequado).

Outro aspecto importante deste módulo reside na possibilidade de o professor

fornecer, para um dado enunciado, um conjunto de dados de entrada e respectivos

resultados esperados, por forma a permitir aos alunos uma maior credibilidade nos testes à

resolução desse problema.

O professor pode também fornecer enunciados vazios para que os alunos possam

livremente realizar um conjunto de exercícios extra, para além daqueles que lhe são

impostos, não limitando desta forma a sua criatividade e desejo de ir mais além.

De seguida passamos a apresentar e descrever o SICAS do ponto de vista do

aluno. Apesar da maioria das funcionalidades não serem exclusivas desse modo,

encontrando–se também disponíveis no modo professor, são aí descritas, pois o SICAS

destina-se essencialmente à utilização por alunos.

Cap. 3 - O SICAS

31

33..22..22 MMooddoo AAlluunnoo Como já foi referido, a actividade fundamental de um aluno com o SICAS consiste

na resolução de problemas que lhe são propostos. No entanto, poderá também visualizar

uma simulação animada da sua resolução ou, caso hajam dados de teste facultados pelo

professor, verificar se o seu algoritmo se comporta correctamente em qualquer caso. A

cada uma das actividades de construção ou simulação da resolução do problema,

corresponderá um ambiente que suporta diferentes tarefas mas com um conjunto de

generalidades similares respeitantes à interface e interacção com o utilizador. Antes

porém, de descrever as funcionalidades de suporte às actividades do aluno nestes dois

tipos de cenário, passamos a referir as analogias existentes entre eles que contribuem para

um ambiente uniforme e coerente.

No SICAS, a selecção das operações a realizar poderá ser efectuada por meio da

escolha de elementos de menus ou através de ícones que representam as principais

actividades do aluno. Pensamos que a existência de menus ajuda a estruturar o acesso à

informação, contribui para uma melhor organização do ambiente de aprendizagem e

orienta eficazmente o aluno sempre que as suas tarefas envolvem a escolha de elementos,

especialmente se os elementos relacionados fizerem parte do mesmo menu e possuírem

um arranjo adequado. Também para Brown e Cunningham (1989) os menus adequam-se

bem a utilizadores inexperientes na medida em que se baseiam na memória de

reconhecimento e estruturam o programa para o utilizador.

No SICAS, tentou-se utilizar ícones apenas para as operações mais frequentes,

pois pensamos que a existência de demasiadas funções, expressa numa grande diversidade

de ícones no ecrã, poderá ser prejudicial. Além disso, tentou-se que os ícones utilizados

fossem familiares ao aluno, representativos e por isso fáceis de associar com a função que

desempenham. Apesar de ser pouco provável que os ícones sejam mais “intuitivamente

significativos” do que as palavras para muitas estruturas de programação, o efeito da sua

localização pode facilitar a sua utilização (Chang et al., 1995). Os ícones são ainda

colocados em localizações que não interfiram com as tarefas que o utilizador está a

realizar.

Cap. 3 - O SICAS

32

O SICAS utiliza janelas de diálogo para comunicação com o aluno, para

introdução de dados e configuração de componentes. Esta é uma forma de interacção com

o utilizador que está tão vulgarizada que é globalmente considerada como uma forma

natural de comunicar e interactuar com programas computacionais. Para Reichman (1986)

a necessidade da existência de janelas prende-se com o facto da possibilidade, frequente,

da coexistência, em programas educativos, de múltiplos processos simultaneamente

activos e visíveis pelo utilizador, não tendo o utilizador de interromper o seu fluxo de

raciocínio sempre que pretende transitar entre actividades. Porém, pensamos que, por

vezes, a utilização de várias janelas em simultâneo pode criar um ambiente distractivo.

Assim, procurou-se no SICAS minimizar a sua utilização simultânea optando, em vez

disso, pela possibilidade de escolha alternativa entre janelas, de forma a maximizar a

concentração do aluno.

Relativamente à forma de introdução de dados, no SICAS, tentámos seguir

algumas das regras estabelecidas por Rowe (1981) para esse efeito, nomeadamente:

♦ referenciar bem as alturas onde é necessária a sua introdução;

♦ realizar sempre a sua validação. Quando há erro na introdução dos dados (por

exemplo, o valor introduzido sai fora da gama de variação) a frase de pedido de

um dado volta a ser feita e a execução do programa só continua quando o valor

do dado estiver correcto.

Relativamente ao tipo de feedback gerado com o aluno apresentamos de seguida

um conjunto de opções tomadas no SICAS para a sua geração.

♦ Uma vez que o SICAS prevê a realização de sessões de estudo isoladas, houve

o cuidado de cada acção iniciada pelo aluno ter sempre ou uma mensagem de

feedback ou alguma resposta, não necessariamente textual, mas que contemple

mudanças no ecrã significando uma forma indirecta de feedback e como tal

comunicação com o aluno. Por exemplo, no SICAS, o ecrã em situação alguma

ficará em branco como resultado intermédio de um comando ou enquanto o

aluno executa determinada acção.

♦ No SICAS tentámos que o feedback fosse imediato. Pensamos que o momento

mais adequado para que a geração do feedback resulte numa eficácia máxima

seja imediatamente após a realização de acções incorrectas, apresentando as

vantagens computacionais e pedagógicas de impedir erros em cascata. Na nossa

Cap. 3 - O SICAS

33

opinião o feedback retardado, após uma demora prolongada, poderá perder o

seu efeito.

♦ Como pensamos que o efeito do feedback é maior quando se segue a respostas

erradas, pois a sua principal função é a de informar a existência de erros ou

acções incorrectas, no SICAS, as mensagens de feedback são geradas apenas

para notificar o aluno de possíveis erros. Especialmente para o público alvo do

SICAS achamos que não faz sentido a existência de feedback após acções

correctas, situação que se pode tornar enfadonha para o utilizador em causa.

♦ Pensamos que os diversos tipos de feedback para com o aluno devem evitar dar

as respostas correctas quando erra mas antes levá-lo a corrigir os seus erros,

guiando-o na construção e obtenção de respostas adequadas, através de dicas ou

sugestões. Porém, apesar de o SICAS não fornecer a resposta correcta quando o

aluno falha, achamos que o feedback gerado deve ser relativamente específico e

não com mensagens demasiado genéricas. Assim, no SICAS, optámos pela

geração de mensagens que relatam as possíveis causas de erro.

33..22..22..11 AACCTTIIVVIIDDAADDEESS DDEE CCOONNSSTTRRUUÇÇÃÃOO//EEDDIIÇÇÃÃOO DDAA RREESSOOLLUUÇÇÃÃOO DDOO

PPRROOBBLLEEMMAA

Após a sua identificação, o aluno é direccionado para um ambiente constituído

essencialmente por três áreas: “Área de construção/edição da resolução do problema”,

“Área de geração de resultados e descrição do problema” e “Área de dados auxiliares”

(Figura 3.1).

33..22..22..11..11 ÁÁRREEAA DDEE CCOONNSSTTRRUUÇÇÃÃOO//EEDDIIÇÇÃÃOO DDAA RREESSOOLLUUÇÇÃÃOO DDOO PPRROOBBLLEEMMAA

Esta é considerada a área crucial para a resolução de um problema, na medida em

que não apenas permite que o aluno conceba resoluções, mas também funciona como o

motor gerador de dados para qualquer uma das outras áreas.

No SICAS um problema é composto por um enunciado, uma ou mais resoluções

(algoritmos) que lhe ficam associadas e, eventualmente, uma solução (definida pelo

professor) acompanhada dos respectivos dados de teste. A ideia da existência de várias

resoluções para o mesmo problema é a de permitir diferentes estilos de raciocínio e

Cap. 3 - O SICAS

34

suportar diversas formas de entendimento, podendo o aluno constatar qual a mais

eficiente para cada situação e em que situações é que uma resolução ou estratégia

apresenta um desempenho superior à outra.

Por forma a organizar as tarefas do aluno, o SICAS pressupõe que este apenas

possa realizar as suas actividades depois da abertura de um enunciado de um problema,

podendo em seguida optar entre a construção/edição de uma resolução (algoritmo) e a sua

simulação ou teste (caso tenha uma resolução activa). O SICAS possibilita, desta forma, a

existência de dois tipos de cenários: resolução de problemas e execução/simulação de

resoluções previamente construídas. Debruçar-nos-emos em primeiro lugar sobre o

ambiente de resolução de problemas.

Área de construção/edição da resolução do problema

Área de geração de resultados e descrição do problema

Área de dados auxiliares

Figura 3.1 Áreas principais do SICAS

Neste ambiente o aluno não terá forçosamente de construir uma resolução de raiz,

podendo optar por editar/alterar uma previamente construída por si ou uma das resoluções

que o professor tenha disponibilizado para esse problema.

Para a criação/edição de uma resolução o aluno é direccionado para um ambiente

icónico, que lhe dá a possibilidade de construir, sob a forma de fluxograma, uma

sequência de operações (acções) que, quando executadas, produzirão a solução do

problema. A construção de um fluxograma é realizada recorrendo a simbologia gráfica

padrão que representa as principais estruturas necessárias à construção de um algoritmo.

Cap. 3 - O SICAS

35

Esta decisão está relacionada com a tentativa de aproximar os conceitos apresentados no

programa aos conceitos que o aluno possui, de forma a haver uma maior familiarização

com o ambiente. Além disso, houve um esforço no sentido de haver unicidade de

representações, ou seja, cada símbolo tem apenas um significado, e vice versa.

A criação de uma estrutura envolve a escolha do seu tipo através da selecção do

elemento adequado, a sua introdução no local desejado no fluxograma e o preenchimento

completo dos campos necessários à sua total definição. Para a tarefa de introdução dos

componentes existem pontos de inserção bem definidos, no centro de linhas que

interligam as diversas estruturas, de forma a evitar diagramas inconsistentes.

Em qualquer um dos componentes a inserir, os campos a preencher são concebidos

de forma a minimizar os erros do aluno. Além disso, só é possível inserir um componente,

quando houver em todos os campos indispensáveis à sua definição informação mínima

para o descrever completamente.

Para além dos elementos específicos de cada uma das estruturas, que passaremos a

descrever, existe um campo que é parte integrante de qualquer uma, o “Comentário”. Este

tem por finalidade permitir aos alunos associar a cada componente uma nota, quer para

registar uma dúvida que lhe ocorra, uma opção de desenvolvimento a seu ver importante,

ou qualquer outro tipo de análise que ache pertinente para a resolução em causa e que

posteriormente também surgirá no código, correspondente à resolução, que pode ser

gerado automaticamente para as linguagens C e Java. Os comentários, se escritos

correctamente, podem proporcionar uma visão muito útil sobre a lógica geral do

programa. Podem também delinear segmentos principais de um programa, identificar

certos aspectos-chave e proporcionar outra informação útil sobre o mesmo. Os

comentários podem-se revelar muito úteis não apenas ao aluno que concebe uma

resolução e que muitas vezes passado algum tempo se esquece dos pormenores dos seus

próprios programas, especialmente em programas longos e complicados, mas também ao

professor que ao analisá-lo poderá melhor compreender a estratégia de resolução do

aluno.

De seguida, são apresentadas as estruturas existentes/definidas para a construção

de fluxogramas no SICAS, acompanhadas do símbolo que as representa.

Cap. 3 - O SICAS

36

33..22..22..11..11..11 EESSTTRRUUTTUURRAASS BBÁÁSSIICCAASS

33..22..22..11..11..11..11 AATTRRIIBBUUIIÇÇÃÃOO

É a instrução mais simples presente no SICAS e, como o próprio nome

indica, possibilita a atribuição de um valor de uma determinada expressão a uma variável.

Esta acção é realizada numa janela análoga à apresentada na Figura 3.2, na qual as

actividades do aluno se resumem a seleccionar, a partir da lista de variáveis já por ele

declaradas, a variável à qual se pretende conferir um valor ou expressão seguido da escrita

da expressão desejada. Notar que, caso os tipos das variáveis ou variável e expressão não

sejam iguais ou compatíveis o aluno é notificado, podendo no entanto prosseguir a sua

actividade de resolução. Caso seja detectada qualquer incompatibilidade durante a

simulação, haverá a sua interrupção.

Figura 3.2 Diálogo de especificação de uma atribuição

33..22..22..11..11..11..22 EENNTTRRAADDAA//SSAAÍÍDDAA

É a estrutura que permite escrever expressões na área de saída e ler valores

para variáveis. Quando o aluno decide introduzir este componente, na sua sequência de

instruções, são-lhe apresentados dois possíveis tipos de visualização e estruturas distintas,

consoante o tipo de operação escolhida: entrada (ler) ou saída (escrever). A opção de

incluir estas duas estruturas numa única janela prende-se com o facto de elas

apresentarem propósitos análogos, na medida em que dizem respeito aos métodos de

interacção directa com o aluno durante a execução da resolução.

Se a operação consistir numa leitura apenas há que seleccionar a variável a ler, de

entre as que estão declaradas até ao momento.

Cap. 3 - O SICAS

37

Figura 3.3 Diálogo de especificação de uma leitura

Caso a operação consista numa escrita, o parâmetro a indicar corresponde a uma

expressão representativa dos caracteres a escrever.

Figura 3.4 Diálogo de especificação de uma escrita

33..22..22..11..11..22 EESSTTRRUUTTUURRAASS DDEE CCOONNTTRROOLLOO

33..22..22..11..11..22..11 RREEPPEETTIIÇÇÃÃOO

O SICAS suporta as duas estruturas que consideramos fundamentais, num

estágio inicial de aprendizagem de programação, para a execução repetida de um conjunto

de instruções. Estas estruturas são conhecidas em muitas linguagens de programação

como for e while. Dependendo da acção pretendida o aluno terá de escolher o tipo de

estrutura de controlo de repetição mais adequada e, posteriormente, preencher o número

mínimo de campos que permitam defini-la sem qualquer ambiguidade. De salientar no

entanto que qualquer uma dessas estruturas pode ser implementada à custa da outra,

podendo qualquer ciclo repetitivo ser obtido a partir de qualquer uma delas, daí que se

tenha decidido pela sua inclusão na mesma janela de diálogo.

Cap. 3 - O SICAS

38

A estrutura while é uma estrutura de controlo de repetição normalmente usada para

a realização de ciclos condicionais. Apresenta o seguinte comportamento: as instruções

existentes no seu interior são executadas repetidamente enquanto se verificar a condição

definida, terminando essa execução quando essa expressão representativa da condição

tiver um resultado falso. Assim, enquanto o resultado da expressão lógica tiver um valor

diferente de “0”, representativo do valor lógico verdadeiro, a instrução ou conjunto de

instruções no seu interior, será executada. Quando a expressão tomar um valor igual a “0”

correspondente ao valor lógico falso, o ciclo termina e a execução do programa continua

na instrução que lhe sucede. Normalmente esse conjunto de instruções possui uma ou

mais características que podem alterar o valor da expressão lógica.

Para a realização de uma acção while, há apenas a necessidade de preencher o

campo “Condição de teste” à qual corresponde uma expressão condicional cujo resultado

corresponderá a um valor lógico.

Figura 3.5 Diálogo de especificação de uma repetição while

A estrutura for é normalmente usada para efectuar “ciclos incondicionais”1. Isto é,

esta estrutura é habitualmente utilizada para repetir uma acção um determinado número de

1 Usa-se o termo “ciclo incondicional” uma vez que é usado na bibliografia clássica. Logicamente tem que

existir uma condição de paragem, caso contrário, estar-se-ia na presença de um ciclo infinito.

Cap. 3 - O SICAS

39

vezes, sendo por isso adequada e frequentemente utilizada para as situações em que se

sabe à partida o número de vezes que deve ser realizada uma repetição. Há então que

definir o valor inicial para a variável de controlo “Atribuição inicial”, os valores

sucessivos que são atribuídos à variável de controlo, por exemplo

incrementos/decrementos, que lhe permitem representar a sua evolução e a condição que

força à paragem do ciclo “Condição de teste”.

Figura 3.6 Diálogo de especificação de uma repetição for

33..22..22..11..11..22..22 SSEELLEECCÇÇÃÃOO

Esta estrutura de controlo condicional tem como função seleccionar o

conjunto de instruções a executar entre duas possíveis alternativas. Esta escolha é feita em

função do resultado de uma expressão lógica. A instrução de selecção definida apresenta o

seguinte comportamento, se a expressão que exprime a condição possuir o valor

verdadeiro (um valor diferente de “0”) então realiza a acção ou acções expressas pela

instrução ou conjunto de instruções definidas no lado esquerdo deste componente, caso

contrário, realiza a acção ou acções expressas pela instrução ou conjunto de instruções

definidas no seu lado direito. Notar, no entanto, que não é obrigatória a existência de

Cap. 3 - O SICAS

40

instruções em ambos os lados da estrutura, na situação limite até poderão não conter

qualquer instrução, apesar de não vermos vantagem nesse tipo de utilização.

Figura 3.7 Diálogo de especificação de uma selecção

33..22..22..11..11..33 EESSTTRRUUTTUURRAASS CCOOMMPPOOSSTTAASS

33..22..22..11..11..33..11 CCHHAAMMAAFFUUNNÇÇÃÃOO

Esta estrutura tem como finalidade evocar uma função definida pelo aluno e

a eventual atribuição a uma variável do possível valor por ela retornado. A inserção desta

estrutura, apesar de realizada segundo o procedimento habitualmente seguido para a

introdução de qualquer outro componente/estrutura, implica a construção (conforme

explicado mais à frente neste capítulo) prévia da função a evocar. Para a completa

definição desta estrutura há que indicar os parâmetros reais a passar à função chamada e a

variável onde deve ser armazenado o valor por ela retornado, caso este exista e se

pretenda empregar em determinada utilização. As definições/configurações a realizar são

efectuadas numa caixa de diálogo análoga à apresentada na Figura 3.8.

Cap. 3 - O SICAS

41

Figura 3.8 Diálogo de uma chamada de uma função com passagem de parâmetros por valor

Em primeiro lugar deve-se escolher a função que se pretende evocar, de entre as

que estão definidas, para que surja a lista de parâmetros formais e respectivos tipos,

definidos na função. Esta funcionalidade foi introduzida para minimizar os erros do aluno

e incutir-lhes as regras que devem ser respeitadas para o estabelecimento da

correspondência entre parâmetros reais e formais, nomeadamente:

♦ o número de parâmetros reais ser necessariamente igual ao número de

parâmetros formais;

♦ cada parâmetro real dever ser do mesmo tipo do parâmetro formal

correspondente (aquele que ocupa a mesma posição na lista de parâmetros);

♦ cada parâmetro real dever ser expresso de maneira consistente com o parâmetro

formal correspondente, conforme determinado pela classe do parâmetro formal.

Para estabelecer a correspondência entre os parâmetros formais e reais basta que o

aluno active a linha correspondente ao parâmetro em causa e escolha a variável (se a

passagem de parâmetros for por referência) ou digite uma expressão (se a passagem de

parâmetros for por valor) seguida da acção “Actualizar”. De salientar que esta perda

lógica de generalidade no caso de parâmetros passados por referência (só poderem ser

variáveis e não constantes ou expressões) reflecte-se, na caixa de diálogo apresentada na

Figura 3.9, traduzindo-se numa acção de escolha entre uma lista de variáveis em vez de

introdução manual de dados.

Cap. 3 - O SICAS

42

Figura 3.9 Diálogo de uma chamada de uma função com passagem de parâmetros por referência

Conforme já referido, o aluno deve também escolher qual a variável da função

chamante que recebe o valor de retorno, caso este exista. Para isso há que escolhê-la de

entre as variáveis do mesmo tipo definidas na função chamante. Notar que também esta

opção foi implementada no sentido de reduzir os erros do aluno, contribuindo

simultaneamente para a interiorização gradual de certos conceitos.

33..22..22..11..11..44 OOUUTTRRAASS EESSTTRRUUTTUURRAASS Para a construção de uma resolução há sempre dois componentes especiais que

surgem automaticamente e que indicam o início e o fim da resolução e são impossíveis de

alterar, copiar ou remover, são eles “Principal” e “Retornar”. Estes elementos têm como

propósito delimitar as instruções que determinam as acções a executar ao longo do

programa. Porém, no SICAS, como o objectivo é a concentração máxima do aluno na

actividade de resolução do problema, ou seja, na realização do corpo propriamente dito do

algoritmo, optámos pela sua introdução de forma automática pois consideramos um

detalhe acessório, não determinante para uma resolução eficiente de um algoritmo, com o

qual o aluno não se deve preocupar, porém deve estar consciente da sua necessidade.

Outra estrutura que não é explicitamente definida mas está subjacente em qualquer

resolução existente no SICAS é a sequência, a qual provoca a execução de um conjunto

de acções, uma após a outra, pela ordem em que estão definidas. A sequência é

representada por uma linha interligando, dois a dois, os componentes básicos constituintes

Cap. 3 - O SICAS

43

do programa. No entanto, as estruturas de controlo “Repetição” e “Selecção”, possuem

não uma mas sim duas “sequências de saída” possíveis, também elas representadas por

linhas condutoras. No caso da “Selecção”, uma dessas linhas representa a situação em que

a “Condição” a ser testada é verdadeira e a outra traduz a sequência de execução de

instruções quando a “Condição” é falsa.

Figura 3.10 Extracto da representação de uma estrutura de selecção

Também na estrutura “Repetição” ambas as linhas têm significados diferentes,

uma equivale à sequência de componentes a executar em cada iteração do ciclo, a outra

descreve a sequência de instruções a realizar após o seu términos.

Figura 3.11 Extracto da representação de uma estrutura de repetição

Cap. 3 - O SICAS

44

33..22..22..11..11..55 VVAARRIIÁÁVVEEIISS A definição de qualquer estrutura/componente implica, normalmente, a utilização

de expressões que envolvem variáveis. Antes de utilizar qualquer variável deve-se

proceder à sua declaração, a qual consiste na definição de um nome e indicação do seu

tipo. Para destacar a importância deste acto, o SICAS perante a tentativa do aluno utilizar

uma variável sem a declarar notifica-o com uma mensagem elucidativa desse facto, não o

impedindo no entanto de progredir com a sua actividade. Porém, caso o aluno pretenda

simular a execução da sua resolução, esta será interrompida sempre que houver uma

situação anómala deste tipo.

O SICAS possibilita apenas a existência de quatro tipos de informação e,

consequentemente, quatro tipos de variáveis: “Numéricos”, “Cadeia de caracteres”,

“Tabela de numéricos” e “Tabela de cadeia de caracteres”. O reduzido número de tipos de

dados permitidos não tem como objectivo a desvalorização deste assunto, mas antes está

relacionado com o facto de não se pretender preocupar o aluno com a sua diversidade.

Prende-se apenas com a tentativa de maximizar a sua concentração com o que achamos

crucial - as estratégias para a concepção de um algoritmo que resolva um problema. Isto

não significa, porém, que não achemos importante que, aquando da implementação de um

algoritmo numa determinada linguagem de programação, o aluno não tenha de perceber a

diferença entre os diversos tipos de dados e a sua utilização racional com as implicações

que daí advêm para uma boa resolução e gestão dos recursos do sistema. Além disso,

também não se pretende que o SICAS seja utilizado para o desenvolvimento de

programas mais complexos onde a definição de estruturas também mais complexas é

essencial.

No SICAS estabeleceram-se as seguintes regras para a construção de tipos de

dados numéricos:

♦ vírgulas e espaços não podem estar incluídas num numérico;

♦ um valor numérico pode ser precedido por um sinal mais (+) ou menos (-). Se

não existir sinal o número é considerado positivo;

♦ um valor numérico representativo de uma quantidade não inteira deve conter

um ponto decimal. Este, caso exista, deve aparecer entre dois dígitos, não

podendo o número começar ou acabar com um ponto decimal.

Cap. 3 - O SICAS

45

Entende-se por “Cadeia de caracteres” ou “String” qualquer sequência de

caracteres entre “”. O SICAS possibilita também a existência de cadeias de caracteres

com um único caracter para simulação do tipo de dados caracter. No SICAS a definição

do tipo de dados “Cadeia de caracteres” foi pensada não apenas para possibilitar a

resolução de grande número de problemas de programação que envolvem este tipo de

dados, mas também para utilização em instruções de escrita. Nesse contexto, e de forma a

permitir uma formatação de saída mais legível, foi pré-definida uma função – nl, que

apresenta um comportamento constante em qualquer resolução. Pode ser utilizada

isoladamente numa estrutura de escrita ou em conjunto com uma cadeia de caracteres

ligada pelo operador (+). Em qualquer dos casos a sua execução resulta numa mudança de

linha.

Como referido o SICAS possibilita também o tipo de dados tabelas (nesta versão

apenas são aceites tabelas unidimensionais). Este tipo de dados tem a característica de um

único identificador poder representar múltiplos elementos. Estabeleceram-se um conjunto

de regras relativamente à utilização deste tipo de dados:

♦ a totalidade dos elementos individuais de uma tabela têm de ser do mesmo tipo;

♦ os elementos individuais da tabela podem ser usados em expressões, instruções

de atribuição, selecção ou repetição, como se fossem variáveis do tipo simples,

“Numérico” ou “Cadeia de caracteres”. Assim, a utilização de elementos de

uma tabela deve seguir as mesmas regras que as variáveis correspondentes do

tipo simples;

♦ para indexar elementos de tabelas, podem ser utilizados não apenas valores

numéricos inteiros fixos, mas também expressões que conduzam a esses

valores.

Em qualquer momento o aluno pode adicionar, alterar o tipo, nome ou número de

elementos das variáveis, bem como removê-las, bastando para isso realizar as acções

pretendidas através de uma janela análoga à apresentada na Figura 3.12.

Cap. 3 - O SICAS

46

Figura 3.12 Diálogo para gestão das variáveis

33..22..22..11..11..66 IIDDEENNTTIIFFIICCAADDOORREESS Um identificador é um nome atribuído a um elemento do programa, tal como uma

variável ou função. Relativamente ao conjunto de caracteres permitido para a definição de

identificadores o SICAS autoriza as letras maiúsculas e minúsculas (A-Z e a-z), os dígitos

de 0 a 9 e o caracter de sublinhado. Como regra para uma boa prática de programação, um

identificador deve conter um número de caracteres suficientes para indicar claramente o

seu significado, desde que não excessivo. O SICAS impõe, por isso, a restrição de o

caracter inicial, para o nome das variáveis, não poder começar por dígitos bem como um

limite de 15 caracteres para o tamanho do nome atribuído a cada identificador. Como

acontece com a maioria das linguagens de programação, o SICAS também não permite a

existência de identificadores repetidos, na mesma resolução, advertindo e impedindo o

aluno na tentativa de o fazer.

33..22..22..11..11..77 EEXXPPRREESSSSÕÕEESS Relativamente à construção de expressões, o SICAS não segue uma sintaxe rígida

de uma determinada linguagem de programação, mas está mais orientado para o C e para

o JAVA, na medida em que o público alvo previsível para utilização do SICAS irá, numa

fase posterior, programar numa dessas linguagens. No entanto, há um esforço constante

para minimizar os detalhes sintácticos, de forma a que o aluno se possa concentrar

plenamente na sua tarefa principal, a criação de um algoritmo que resolva um problema.

Entende-se por expressão um conjunto de operandos agrupados por certos

operadores constituindo formas algébricas que representam um valor. No SICAS o

Cap. 3 - O SICAS

47

resultado de uma expressão é um valor numérico se todos os operandos forem do tipo

numérico ou caso inclua cadeias de caracteres estas estarem inseridas no contexto de

funções que devolvem valores numéricos. O resultado de uma expressão representa uma

“Cadeia de caracteres” sempre que na expressão surja pelo menos um operando deste tipo

(à excepção do caso anteriormente referido). Todas as expressões devem satisfazer as

seguintes condições gerais:

♦ os identificadores não declarados não podem aparecer numa expressão;

♦ preceder um identificador com um sinal (-) é equivalente à multiplicação por -1;

♦ as operações aritméticas não podem estar implícitas. Assim, a expressão 2y está

incorrecta, mas a expressão 2*y é válida;

♦ as operações aritméticas não podem ser efectuadas directamente sobre cadeias

de caracteres;

♦ não pode existir um desequilibro de parêntesis;

♦ não são permitidos dois operadores sucessivos. Podem, contudo, ser usados

parêntesis para separar operadores sucessivos;

♦ uma expressão pode consistir num único identificador correspondente a uma

variável;

♦ o nome de uma função definida pelo aluno (a referência à função) não pode ser

usado, directamente, no lugar de um identificador dentro de uma expressão.

Contudo, é possível utilizar dentro de uma expressão uma variável contendo o

valor devolvido por uma função desde que realizada a devida atribuição prévia.

Expressões Aritméticas

Na formação de expressões aritméticas, são permitidos apenas operandos que

representam quantidades numéricas e operadores aritméticos. No SICAS foram definidos

os operadores aritméticos constantes na Tabela 3.1.

Operador Exemplo Descrição

- - a Negação + a + b Adição - a – b Subtracção * a * b Multiplicação / a / b Divisão % a % b Módulo (resto da divisão inteira)

Tabela 3.1 Operadores aritméticos

Cap. 3 - O SICAS

48

Expressões lógicas

Na constituição de expressões lógicas são usados diferentes tipos de operandos

(numéricos e cadeias de caracteres) e operadores (lógicos e relacionais). Quando uma

expressão lógica é construída os dois operandos têm obrigatoriamente de ser do mesmo

tipo. No SICAS, uma expressão recorrendo a operadores lógicos pode não ser

completamente calculada, o cálculo interrompe-se assim que o valor resultante possa ser

inferido. Os operadores relacionais e lógicos definidos no SICAS são os descritos nas

tabelas 3.2 e 3.3.


= = a = = b Igual != a != b Diferente < a < b Menor <= a <= b Menor ou Igual > a > b Maior >= a >= b Maior ou Igual

Tabela 3.2 Operadores relacionais


&& a && b Conjunção || a || b Disjunção inclusiva

Tabela 3.3 Operadores lógicos

Precedência dos operadores

Uma expressão pode por vezes tornar-se bastante complexa, devido à presença de

múltiplos operadores. Nestes casos torna-se necessário entender a ordem pela qual as

operações são efectuadas. Esta ordem pode ser determinada pela precedência dos

operadores incluída no SICAS. Os diversos grupos de precedência a que pertencem os

operadores envolvidos numa expressão, no SICAS, indicam-se na Tabela 3.4.

Operadores

*, /, % +, - <, <=, >, >=, !=, = = && ||

Tabela 3.4 Ordem de precedência dos operadores

Cap. 3 - O SICAS

49

Os operadores na mesma linha, pertencem ao mesmo grupo e como tal apresentam

a mesma precedência. As linhas estão apresentadas por ordem de precedência

decrescente. Para operadores pertencentes ao mesmo grupo, a ordem de avaliação na

expressão é da esquerda para a direita. No entanto, esta ordem pode ser alterada pela

introdução de parêntesis curvos, permitindo assim que determinadas expressões, sejam

calculadas em primeiro lugar e actuem como operandos dentro da expressão em que se

incluem.

33..22..22..11..11..88 FFUUNNÇÇÕÕEESS PPRRÉÉ--DDEEFFIINNIIDDAASS O SICAS possui também um conjunto de funções intrínsecas pré-definidas, que

podem ser utilizadas na construção de expressões sem que haja a preocupação da sua

declaração. No entanto, podem ser usadas unicamente para o fim a que são destinadas,

não podendo ser redefinidas pelo programador. As funções pré-definidas existentes no

SICAS são as mais frequentemente utilizadas na generalidade das linguagens de

programação e que proporcionam a resolução de grande número de problemas numa fase

inicial de aprendizagem deste tipo de matéria. Foram definidas funções para manipulação

de dados numéricos e de cadeias de caracteres. Os nomes atribuídos às funções tiveram

em conta uma maior aproximação aos usados nas linguagens de programação com as

quais o público alvo do SICAS se irá defrontar, como tal, consistem em abreviaturas em

Inglês da funcionalidade oferecida por cada uma delas. Por uma questão de organização e

orientação do aluno, aquando de uma possível consulta, estabelecemos a distinção de

funções para manipulação de dados numéricos e de cadeias de caracteres, como se ilustra

de seguida.

Funções para manipulação de valores numéricos

acos(a)

Retorna o arco coseno de um valor.

Tipo de parâmetros:

a – numérico

Tipo de retorno:

numérico

Cap. 3 - O SICAS

50

asin(a)

Retorna o arco seno de um valor.


a – numérico

Tipo de retorno:

numérico

atan(a)

Retorna o arco tangente de um valor.


a – numérico

Tipo de retorno:

numérico

bitand(a,b)

Retorna o resultado da operação binária “Conjunção”, entre dois valores.


a – numérico, inteiro

b – numérico, inteiro

Tipo de retorno:

Numérico

bitor(a,b)

Retorna o resultado da operação binária “Disjunção inclusiva”, entre dois

valores.




Tipo de retorno:

numérico

Cap. 3 - O SICAS

51

bitxor(a,b)

Retorna o resultado da operação binária “Disjunção exclusiva”, entre dois

valores.




Tipo de retorno:

numérico

cos(a)

Retorna o coseno trigonométrico de um valor.


a – numérico, expresso em radianos

Tipo de retorno:

numérico

int(a)

Retorna a parte inteira de um valor.


a – numérico

Tipo de retorno:

Numérico

log(a)

Retorna o logaritmo natural (base e) de um valor.


a – numérico, maior que zero

Tipo de retorno:

numérico

Cap. 3 - O SICAS

52

max(a,b)

Retorna o maior de dois valores.


a – numérico

b – numérico

Tipo de retorno:

numérico

min(a,b)

Retorna o menor de dois valores.


a – numérico

b – numérico

Tipo de retorno:

numérico

pow(a,b)

Retorna o valor a elevado ao expoente b.


a – numérico

b – numérico

Se a for igual a zero, então b tem de ser maior que zero.

Se a for menor que zero, então b tem de ser um inteiro.

Tipo de retorno:

numérico

not(a)

Retorna o complemento lógico de um valor.



Tipo de retorno:

numérico

Cap. 3 - O SICAS

53

round(a)

Retorna o valor inteiro mais próximo de a.


a – numérico

Tipo de retorno:

numérico

roundn(a,b)

Retorna o valor, com b casas decimais, mais próximo de a.


a – numérico

b – numérico, não negativo

Tipo de retorno:

numérico

sin(a)

Retorna o seno trigonométrico de um valor.



Tipo de retorno:

numérico

sqrt(a)

Retorna a raiz quadrada de um valor.


a – numérico, maior ou igual a zero

Tipo de retorno:

numérico

Cap. 3 - O SICAS

54

tan(a)

Retorna a tangente trigonométrica de um valor.



Tipo de retorno:

numérico

toDegrees(a)

Converte um ângulo medido em radianos no ângulo equivalente medido

em graus.



Tipo de retorno:

numérico

toRadians(a)

Converte um ângulo medido em graus no ângulo equivalente medido em

radianos.


a – numérico, expresso em graus

Tipo de retorno:

numérico

Funções para manipulação de cadeias de caracteres

ascii(a)

Retorna um valor inteiro correspondente ao código ASCII do primeiro

caracter da cadeia de caracteres a.


a – cadeia de caracteres, não nula

Tipo de retorno:

numérico

Cap. 3 - O SICAS

55

char(a)

Retorna o caracter correspondente a um valor inteiro (código ASCII).


a – numérico, pertencente ao intervalo [0, 255]

Tipo de retorno:

cadeia de caracteres

charAt(a,b)

Retorna o caracter, de uma cadeia de caracteres a, correspondente ao

índice especificado por b. O índice varia de zero ao tamanho da cadeia de

caracteres menos uma unidade.


a – cadeia de caracteres

b – numérico, inteiro não negativo, inferior ao tamanho da cadeia

de caracteres a

Tipo de retorno:


left(a,b)

Retorna os primeiros b caracteres da cadeia de caracteres a.




de caracteres a

Tipo de retorno:


length(a)

Retorna o tamanho de uma cadeia de caracteres.



Tipo de retorno:

numérico

Cap. 3 - O SICAS

56

mid(a,b,c)

Retorna o conjunto de caracteres da cadeia de caracteres a, compreendidos entre

os índices b e c.




de caracteres a e ao índice c

c – numérico, inteiro não negativo, inferior ao tamanho da cadeia

de caracteres a

Tipo de retorno:


rigth(a,b)

Retorna os últimos caracteres da cadeia de caracteres a, a partir do índice b.




de caracteres a

Tipo de retorno:


toLowerCase(a)

Converte a cadeia de caracteres a para minúsculas.



Tipo de retorno :


toUpperCase(a)

Converte a cadeia de caracteres a para maiúsculas.



Tipo de retorno:


Cap. 3 - O SICAS

57

33..22..22..11..11..99 FFUUNNÇÇÕÕEESS DDEEFFIINNIIDDAASS PPEELLOO UUTTIILLIIZZAADDOORR O SICAS permite que o aluno defina as suas próprias funções. Esta é uma

possibilidade importante, pois pensamos que é fundamental incutir desde cedo aos alunos

o conceito de modularização, demonstrando as vantagens da sua utilização na resolução

de problemas de programação, bem como a sua importância para uma programação

eficaz, permitindo nomeadamente:

♦ aumentar a clareza lógica da resolução construída, tornando-a mais fácil de

conceber, entender e corrigir através da decomposição de um problema

complexo numa sequência de subproblemas individuais mais simples e

concisos;

♦ facilitar a resolução de problemas mais complexos e de maiores dimensões,

com considerável redução do comprimento da sua resolução;

♦ evitar a redundância possibilitando a redução do número de componentes;

♦ alterar um módulo/função independentemente dos outros.

A construção de uma função é realizada segundo as regras e opções definidas

anteriormente para qualquer resolução. A principal diferença reflecte-se nos elementos

delimitadores da sequência de instruções. O componente inicial apresenta agora um

cabeçalho que inclui o nome atribuído à função e os seus parâmetros, caso existam. O

elemento final indicará um eventual valor a devolver como resultado da execução da

função.

Figura 3.13 Écran ilustrativo dos elementos delimitadores de uma função

Cap. 3 - O SICAS

58

A edição do cabeçalho da função permite definir os parâmetros formais através da

indicação das variáveis locais que passam a ter um comportamento especial – parâmetro.

A tentativa de definição de parâmetros sem a declaração prévia de variáveis traduz-se no

aparecimento de uma mensagem a notificar o aluno dessa impossibilidade, como se

demonstra na Figura 3.14.

Figura 3.14 Mensagem ilustrativa de uma situação de erro

Conforme já mencionado, a definição dos parâmetros formais, para posterior

passagem entre funções, pode ser de dois tipos: valor ou referência.

Os parâmetros passados por valor podem considerar-se como parâmetros de

entrada nas suas funções respectivas. O uso destes parâmetros envolve uma transferência

ou atribuição de valor e não apenas uma substituição de um parâmetro real. Assim,

aquando da chamada a uma função, a variável parâmetro correspondente assume um valor

que é uma réplica do valor original (o valor indicado na chamada da função). Valores que

são representados por parâmetros passados por valor não podem, contudo, ser transferidos

na direcção contrária, isto é, da função chamada para a função chamante, daí serem

entendidos como parâmetros de entrada.

Os parâmetros passados por referência são normalmente usados em situações em

que se pretende que a informação seja transferida em ambas as direcções entre as funções

chamante e chamada. Assim, a variável indicada como parâmetro na função chamada é

mapeada na variável indicada na função chamante. Como consequência, o valor da

variável da função chamada é iniciado com o valor da variável da função chamante e,

aquando do retorno da função, o valor da variável da função chamante assume o valor

final da variável da função chamada. De realçar que, em consequência do processo de

mapeamento das variáveis, qualquer mudança do valor do parâmetro passado por

referência dentro de uma função muda também o valor do correspondente parâmetro real

fora da função chamada. Assim, os parâmetros passados por referência podem afectar o

Cap. 3 - O SICAS

59

programa globalmente, mesmo que o seu âmbito seja local à função em que são

declaradas.

A Figura 3.15 exemplifica a caixa de diálogo que surge aquando da edição do

cabeçalho de uma função para a definição dos seus parâmetros formais.

Figura 3.15 Diálogo de definição dos parâmetros formais de uma função

Notar que a definição dos parâmetros formais não apresenta um caracter vitalício,

podendo o aluno alterar a sua ordem, bastando para tal seleccionar o parâmetro desejado e

posteriormente accionar os botões “Para cima” e “Para baixo”. Também o tipo de

passagem de parâmetros pode ser alterado através da selecção do parâmetro pretendido,

posterior eliminação e nova introdução, após a selecção do tipo de parâmetro desejado.

Se o aluno pretender retornar um valor, calculado numa função, há que escolher

qual a variável cujo valor se deseja devolver. Para isso há que activar o bloco delimitador

final do conjunto de instruções da função e escolher a opção que permite a sua edição.

Esta acção traduz-se no aparecimento da janela de diálogo mostrada na Figura 3.16, na

qual poderá ser realizada a escolha pretendida.

Figura 3.16 Diálogo de especificação do valor de retorno de uma função

Cap. 3 - O SICAS

60

O SICAS também possibilita a eliminação de funções, à excepção da função

principal, bastando para tal que o aluno se encontre na função a eliminar e escolha a

opção adequada, como se representa na Figura 3.17. A única excepção reside na situação

em que o aluno tem aberta uma resolução do professor, a qual não poderá ser alterada

pelo aluno. No entanto, o aluno tem forma de contornar este impedimento, bastando para

isso atribuir outro nome à resolução, ficando a nova resolução a pertencer-lhe.

Figura 3.17 Selecção da opção para eliminação de uma função

Quando o aluno manifesta interesse em apagar uma função, é-lhe ainda dada a

possibilidade de repensar a sua acção, através da janela de diálogo mostrada na Figura

3.18.

Figura 3.18 Diálogo para eventual eliminação de uma função

Cap. 3 - O SICAS

61

Caso o aluno decida que realmente pretende apagar a função são-lhe oferecidas um

conjunto de possibilidades, entre elas a de substituir as chamadas existentes a essa função

por uma outra função.

Figura 3.19 Diálogo para eventual substituição de uma função por outra

Se o aluno responder negativamente à pergunta mostrada na caixa de diálogo

presente na Figura 3.19, é-lhe dada ainda a possibilidade de eliminar as chamadas à

função, conforme mostrado na Figura 3.20.

Figura 3.20 Diálogo para eventual eliminação das chamadas de uma função

Se o aluno aceitar esta opção todos os locais em todas as funções onde é evocada a

função (estrutura ChamaFunção) em causa são eliminados. Caso contrário eles

permanecerão e é da responsabilidade do aluno a sua alteração de forma a que façam

sentido.

Se o aluno decidir que pretende substituir as chamadas à função que foi eliminada

por uma outra função também o poderá fazer, seleccionando apenas a função para a qual

pretende efectuar a substituição, como se ilustra na Figura 3.21, e fazendo os respectivos

ajustamentos necessários. Se, de qualquer opção de apagamento de uma função

resultarem incongruências e o aluno não realizar as modificações necessárias, caso

pretenda simular a sua execução esta será interrompida no local onde é evocada a função

desajustada.

Cap. 3 - O SICAS

62

Figura 3.21 Diálogo para escolha da função a substituir

Obviamente, com este tipo de possibilidades é provável que o aluno cometa erros,

no entanto, pensamos que é importante responsabilizá-lo para este tipo de atitudes para

que reflicta sobre a importância destas acções. Os alunos também precisam de errar e ter a

oportunidade de corrigir os seus próprios erros, analisando e investigando a origem das

faltas e enganos cometidos. Segundo Piaget (1970), os alunos precisam de experimentar a

inconsistência e a contradição para tornar as alterações significativas para a forma como

eles interpretam o mundo. Não é suficiente experimentar simplesmente este tipo de

conflito cognitivo, o aluno tem de ser capaz de reconhecer o conflito e o motivo para o

resolver. Este tipo de responsabilização das atitudes do aluno também se aplica aquando

da alteração dos parâmetros das funções.

33..22..22..11..22 ÁÁRREEAA DDEE GGEERRAAÇÇÃÃOO DDEE RREESSUULLTTAADDOOSS EE DDEESSCCRRIIÇÇÃÃOO DDOO PPRROOBBLLEEMMAA

Esta área apesar de não ser determinante para uma boa concepção do algoritmo,

pode ser considerada como um complemento importante de informação de apoio ao

aluno. É constituída pelas subsecções apresentadas de seguida.

33..22..22..11..22..11 EENNUUNNCCIIAADDOO Esta secção destina-se à descrição do problema a resolver. Apesar de presente em

ambos os modos, aluno e professor, apenas é editável no modo professor. Esta decisão

tem como finalidade principal permitir ao professor orientar a actividade do aluno através

da disponibilização dos enunciados de problemas que pretende ver resolvidos pelo aluno.

Pensamos que esta opção é fundamental para uma melhor orientação e estruturação das

actividades do aluno, em especial quando exerce as suas práticas de programação sem

acompanhamento. Assim, achamos aconselhável que o aluno apenas possa resolver os

problemas que o professor ache adequados aos seus níveis actuais de conhecimentos, para

Cap. 3 - O SICAS

63

que não fique desmotivado com um problema possuidor de um grau de dificuldade muito

superior. Além disso, consideramos importante a possibilidade de o aluno, durante a

resolução de um problema, ter exposto a sua descrição de modo a permitir-lhe a presença

constante dos dados, incógnitas e condições a satisfazer, para que em situação alguma

perca de vista os objectivos a atingir.

33..22..22..11..22..22 SSAAÍÍDDAA Esta secção contém a saída gerada pela execução do programa e também o

eventual código produzido, para a resolução construída, sob a forma de Pseudocódigo,

Linguagem C ou Linguagem JAVA, se alguma destas opções for escolhida. A diversidade

destas alternativas para apresentação da resolução do problema não está relacionada com

a sua importância, mas antes tem como propósito demonstrar que a acção fundamental na

resolução dos problemas de programação é a construção do algoritmo e não a linguagem

em que é implementada. Assim, a partir do momento em que existe um algoritmo

concebido a sua tradução é relativamente fácil de realizar, para a generalidade das

linguagens de programação. Por outro lado, a ideia da existência de várias representações

alternativas para a mesma resolução é a de facilitar ao aluno diferentes tipos de raciocínio,

permitindo-lhe viajar entre diferentes representações para o mesmo problema. A Figura

3.22 ilustra a saída gerada caso a preferência do aluno tenha recaído sobre a opção

“Pseudocódigo”.

Figura 3.22 Selecção da opção para geração de pseudocódigo

Cap. 3 - O SICAS

64

33..22..22..11..22..33 EENNTTRRAADDAASS Esta secção apesar de não ser visível no modo aluno, está implícita pois, quando

devidamente definida pelo professor, proporciona ao aluno o teste da resolução construída

para um determinado problema, caso este tenha necessidade de fornecimento de dados.

Para tal, o professor terá que indicar um conjunto de dados nessa secção, um por linha. A

ordem pela qual se encontram estabelece uma correspondência unívoca com as operações

de leitura executadas durante a simulação do algoritmo.

33..22..22..11..22..44 SSOOLLUUÇÇÃÃOO Esta secção apenas se encontra presente no modo professor e destina-se à

indicação de um conjunto de caracteres representativos da saída esperada para o problema

definido, assumindo os valores de entrada estabelecidos, na secção “Entradas”. Com as

secções “Entradas” e “Solução” preenchidas pelo professor o aluno poderá testar a sua

resolução. O SICAS para averiguar a correcção da resolução verifica se, para o conjunto

de dados fornecidos em “Entradas”, se obtém como saída o conjunto de valores fornecido

em “Solução”. Para testar uma solução, é dada ao aluno a possibilidade de fazer um teste

mais superficial não tendo em consideração os espaços em branco excessivos ou em falta,

caso não sejam considerados determinantes para uma solução bem sucedida (Ignorar

espaços), ou ainda, fazer um teste exaustivo valorizando a totalidade dos espaços em

branco constituintes de uma resolução. De realçar que é da responsabilidade do professor

a colocação de valores correctos nas secções “Entradas” e “Solução” para a realização de

um teste bem sucedido.

Assim as secções “Solução” e “Entradas” isoladamente não apresentam qualquer

utilidade mas antes actuam em conjunto. Esta, apesar de não ser uma funcionalidade

essencial, consideramos que apresenta alguma importância e é desejável na medida em

que possibilita ao aluno, depois de estudar a matéria, utilizar o programa para, liberto das

preocupações classificativas, auto-avaliar a sua aprendizagem antes de se submeter a

testes formais. Apesar de o aluno poder simular a execução da sua resolução passo-a-

passo e como tal analisar a sua evolução, pensamos que a possibilidade anteriormente

referida apresenta uma medida de credibilidade superior, conferindo ao aluno um grau de

confiança mais elevado no sistema e como tal levando-o a utilizá-lo um maior número de

vezes.

Cap. 3 - O SICAS

65

Figura 3.23 Écran ilustrativo do preenchimento de valores na subsecção Solução

33..22..22..11..22..55 EEXXEEMMPPLLOO DDEE SSAAÍÍDDAA Esta secção é uma réplica da secção “Solução” presente no modo professor. Desta

forma, contém os dados fornecidos pelo professor correspondentes a uma saída típica de

uma resolução. Pensamos ser fundamental que o aluno conheça os moldes em que deverá

construir a sua resolução, para a realização de uma resolução plena de acordo com as

pretensões do professor. Isto porque, o aluno muitas vezes é penalizado nas suas

respostas, não porque não saiba resolver os problemas mas, porque desconhece o formato

pretendido ou porque se esquece de determinados detalhes. Além disso, o SICAS para

testar a resolução de um aluno espera que ela esteja num determinado formato, definido

pelo professor.

33..22..22..11..33 ÁÁRREEAA DDEE DDAADDOOSS AAUUXXIILLIIAARREESS

Esta área destina-se ao fornecimento de dados suplementares à actividade do

aluno. Por um lado, tem o papel de simplificar o acesso a determinado tipo de informação

útil durante a resolução do problema. Por outro lado, revela-se imprescindível para a

compreensão da actividade de simulação da resolução construída. Dela fazem parte as

subsecções que se passam a apresentar.

Cap. 3 - O SICAS

66

33..22..22..11..33..11 FFAACCTTOOSS Esta secção apenas se revela útil durante o momento em que o aluno simula a

execução da resolução construída daí que apenas se encontre activa por defeito nesse

ambiente. Os factos permitem conhecer, em cada momento, os dados da experiência,

estabelecendo para isso a correspondência entre cada variável e o valor que lhe está

associado. Este par variável/valor é constantemente actualizado durante a execução da

resolução e é de crucial importância para a detecção de eventuais erros lógicos de

concepção.

33..22..22..11..33..22 VVAARRIIÁÁVVEEIISS Esta secção é especialmente conveniente quando o aluno se encontra no modo de

edição/resolução do problema e pretende obter informação sobre as variáveis declaradas e

dos respectivos tipos. No entanto também consta no ambiente de simulação da execução

de uma determinada resolução, pois pensamos que pode ser útil a possibilidade de uma

eventual consulta rápida deste tipo de informação durante uma simulação, sem que se

tenha de proceder à sua interrupção.

33..22..22..11..33..33 FFUUNNÇÇÕÕEESS Esta secção não acrescenta qualquer funcionalidade, no entanto foi introduzida

dada a necessidade de existência de um local de fácil acesso para transição entre as

diversas funções integrantes de uma resolução. Pensamos que este aspecto é

especialmente útil durante a construção da resolução de um problema, na medida em que,

ao facilitar as tarefas do aluno, contribui para maximizar a sua concentração na resolução

do problema.

Cap. 3 - O SICAS

67

33..22..22..22 AACCTTIIVVIIDDAADDEESS DDEE AANNIIMMAAÇÇÃÃOO//SSIIMMUULLAAÇÇÃÃOO DDAA RREESSOOLLUUÇÇÃÃOO DDOO

PPRROOBBLLEEMMAA

Uma vez concluída a tarefa de construção da resolução do problema, esta poderá

ser simulada pelo sistema. Para isso, o aluno terá que transitar para outro ambiente –

ambiente de execução.

A diferença essencial em termos de aparência entre ambos os ambientes reside nos

diferentes botões integrantes da barra de tarefas e correspondentes menus e opções, para

além das secções que surgem activas por defeito. Assim, enquanto que no modo de edição

da resolução do problema são as secções “Variáveis” e “Enunciado” que são

automaticamente activadas nas correspondentes áreas, no ambiente de simulação são as

secções “Factos” e “Saída”.

Para determinar se a sua resolução satisfaz o pretendido o aluno terá a

possibilidade de simular a resolução construída, de forma animada, para uma melhor

compreensão sobre as várias fases e entidades envolvidas no problema em causa. Assim,

para que a visualização melhor expresse as ideias e transmita a informação presente na

resolução do problema, a animação do sistema permite um elevado grau de interacção e

controlo por parte do aluno, configurada segundo os seus interesses.

As opções que o aluno pode configurar, relativamente ao progresso de uma

execução, são:

♦ escolha da direcção de execução: realização da execução processando-se da

primeira instrução para a última (Para a frente) ou recuar na execução,

permitindo ao aluno voltar a observar uma situação anterior que, eventualmente

não tenha compreendido (Para trás);

♦ escolha do tipo de movimento realizado: permite estipular o ritmo de execução,

só avançando de uma instrução para a que lhe sucede quando o aluno o

autorizar (Passo-a-Passo) ou com uma execução contínua mas lenta (Lento) ou

ainda uma execução ininterrupta mas mais acelerada (Rápido).

Cap. 3 - O SICAS

68

Figura 3.24 Configuração do ritmo da execução

Independentemente da direcção e movimento estipulados para o decorrer da

execução, o aluno poderá, em qualquer momento, pará-la pelo período de tempo desejado

e posteriormente retomá-la ou ainda reiniciá-la.

No decurso de qualquer simulação o próximo componente a ser executado é

devidamente destacado e a sua visibilidade reforçada no ecrã, de forma a melhor localizar

e enquadrar o aluno na acção que está a decorrer.

Figura 3.25 Écran ilustrativo de uma situação durante uma simulação

Cap. 3 - O SICAS

69

Como ilustrado na Figura 3.25, em determinada etapa de uma resolução poderá

haver necessidade de ler um valor, para tal o aluno terá que proceder à introdução dos

dados solicitados pelo sistema, como se demonstra na Figura 3.26.

Figura 3.26 Diálogo para introdução de dados durante uma simulação

33..22..22..33 EELLEEMMEENNTTOOSS AAUUXXIILLIIAARREESS

Independentemente do ambiente em que o aluno se encontra, o SICAS, apresenta

ainda a possibilidade de o informar sobre as suas funcionalidades e utilidades, para além

de possibilitar o registo de algumas notas. Assim, o utilizador do SICAS poderá, em

qualquer momento e independentemente do modo e ambiente em que se encontra, obter

informação sobre os operadores e operações passíveis de serem utilizados, o formato da

sua utilização, a sua descrição/funcionalidade e exemplos de aplicação, bastando para isso

seleccionar a opção adequada conforme se demonstra na janela presente na Figura 3.27.

Figura 3.27 Selecção da opção para consulta de informação sobre o SICAS

Cap. 3 - O SICAS

70

Defrontando-se posteriormente com a informação solicitada numa janela

semelhante à apresentada na Figura 3.28.

Figura 3.28 Janela de apresentação das funcionalidades do SICAS

O aluno poderá também, sempre que o desejar, ser informado sobre a

utilidade/aplicabilidade de cada um dos menus, respectivas opções e ícones, surgindo-lhe

o esclarecimento respectivo na janela apresentada na Figura 3.29.

Figura 3.29 Janela de apresentação das utilidades do SICAS

É ainda permitido ao aluno registar algumas dúvidas e ideias que lhe vão surgindo

como estratégias para a resolução de um problema ou determinados apontamentos que lhe

vão ocorrendo no decorrer das suas tarefas, na secção “Bloco de Notas”.

Cap. 3 - O SICAS

71

33..33 AAvvaalliiaaççããoo ee mmeellhhoorraammeennttooss O SICAS já sofreu uma primeira avaliação por parte de alguns professores que

leccionam habitualmente disciplinas de programação. Do conjunto de opiniões fornecidas,

pela generalidade dos avaliadores, destacam-se as seguintes:

♦ O SICAS apresenta um elevado grau de interesse revelando-se muito útil,

especialmente para utilização em cadeiras introdutórias de programação, por forçar a uma

formalização e estruturação do raciocínio.

♦ Os pontos mais fortes do trabalho residem na possibilidade de poder simular a

execução do algoritmo e na incorporação de funções.

♦ Houve também um conjunto de funcionalidades e facilidades muito apreciadas

de que se destacam a possibilidade de poder salvaguardar o trabalho (enunciado e

resoluções) e a possibilidade de gerar “código”, correspondente ao fluxograma construído,

em diferentes linguagens.

♦ O facto de sensibilizar os alunos para os tipos essenciais de dados, permitindo

resolver grande número de problemas, sem contudo sobrecarregar o aluno com a sua

diversidade, foi do agrado da generalidade.

♦ A validação da resolução construída foi também considerada de grande

importância para a detecção de erros lógicos, nem sempre percebidos durante a simulação.

♦ O SICAS é bastante atractivo, sob o ponto de vista visual.

♦ Os menus e ícones escolhidos são suficientemente representativos mas não

óbvios, especialmente para pessoas não familiarizadas com a simbologia padrão utilizada

nos fluxogramas.

♦ A interface com o utilizador é bastante amigável, agradável e com interacção

suficiente. Em especial foi do agrado geral a não sobrecarga de informação textual para

notificação de situações anómalas.

♦ A interface é, em geral, bastante intuitiva, simples de utilizar e de perceber mas

com um grau de detalhe adequado. A única excepção apontada reside na definição dos

parâmetros formais e reais e do valor de retorno de uma função, algo complicada de

descobrir sem a consulta do manual de utilizador distribuído.

Cap. 3 - O SICAS

72

Dos aspectos que menos gostaram destacam-se:

♦ A sintaxe utilizada, em especial para a escrita de expressões, realçando que

deveria ser usada uma sintaxe genérica para o caso de utilização do SICAS por alunos que

usem outras linguagens de programação que não o JAVA ou o C.

♦ Enquanto uns eram da opinião de que as estruturas deveriam poder mover-se

manualmente, não gostando da estrutura rígida imposta, outros acharam um aspecto de

extrema importância o facto de haver uma estrutura fixa evitando a geração de

fluxogramas inconsistentes.

Em relação aos objectivos do programa, os avaliadores não sentiram qualquer

omissão importante. Porém mencionaram um conjunto de sugestões mais relacionadas

com a interface com o utilizador, que passamos a apresentar:

♦ A possibilidade da coexistência de várias resoluções abertas em simultâneo ou

uma forma mais rápida para transitar entre resoluções.

♦ Aquando da abertura de um enunciado, realizar uma filtragem dos ficheiros,

que surgem na janela de diálogo, de forma a aparecerem apenas os respeitantes aos

enunciados.

♦ A possibilidade de mostrar o comentário relativamente à estrutura em causa

sempre que se deslocar o rato sobre a estrutura.

♦ O apagamento das estruturas de uma forma mais intuitiva, através da definição

de uma tecla para esse fim.

♦ A possibilidade de desfazer um ou vários níveis de operações anteriores.

♦ A possibilidade de geração de código noutras linguagens só deveria estar

disponível mediante ordem do professor. Isto porque, segundo os avaliadores, muitas

vezes há a tentação e curiosidade de começar a programar sem pensar profundamente na

resolução.

♦ A dificuldade apontada relativamente à navegação entre funções numa mesma

resolução, por algumas pessoas, resultou na adição da subsecção “Funções”, na “Área de

dados auxiliar”, já apresentada anteriormente neste capítulo.

Cap. 3 - O SICAS

73

33..44 AAllgguunnss aassppeeccttooss ddee iimmpplleemmeennttaaççããoo Com a pretensão de conceber um ambiente com predomínio absoluto de interfaces

com utilização intensiva de representações gráficas (incluindo animação), recheado de

ícones, janelas e grande interactividade com o utilizador não houve dúvida que teria de ser

utilizada uma linguagem de programação de alto nível com capacidades/bibliotecas

gráficas. O objectivo consistia em conceber um produto bastante aceitável não apenas

funcionalmente, mas essencialmente que fosse capaz de conquistar o utilizador

visualmente, pois, hoje em dia, impressionar a visão tornou-se um imperativo. No entanto,

a variedade de alternativas trouxe um problema acrescido, entre as linguagens

disponíveis, qual deveria ser a escolhida?

Relativamente à adequação da linguagem ao projecto a realizar, houve que

caracterizar bem a aplicação a desenvolver. Desta forma, identificou-se de primordial

importância, além das capacidades gráficas já mencionadas, a necessidade de utilizar uma

linguagem que permitisse a implementação das estruturas constituintes de um algoritmo

tendo em conta algumas bases comuns existentes entre elas, o que nos levou a optar por

uma linguagem orientada a objectos.

Entre as diversas linguagens orientadas a objectos era necessário optar por uma.

Um dos critérios a que normalmente se recorre é o da utilização de uma linguagem

apropriada às tarefas a realizar mas que o programador domine. Porém, a curiosidade em

aprender uma linguagem tão divulgada como o JAVA foi precisamente um dos apelativos

para o seu estudo.

Após um estudo das características do JAVA e alguma prática na sua utilização,

verificámos que essa linguagem se adequava plenamente para o desenvolvimento do

SICAS. A facilidade na definição e utilização de objectos, gráficos e os necessários para a

definição de algoritmos, foi uma das características de maior peso na escolha realizada,

permitindo nomeadamente:

♦ Simplicidade. A utilização de objectos permite esconder a complexidade do

código. É possível a criação de uma complexa aplicação gráfica usando botões, janelas,

barras de scroll, entre outros, sem conhecer a complexidade do código subjacente.

♦ Reutilização de código. Um objecto, depois de definido, pode ser reutilizado

por outras aplicações, ter as suas funções estendidas e ser usado noutros sistemas.

♦ Inclusão Dinâmica. Os objectos podem ser incluídos dinamicamente no

programa, durante a execução.

Cap. 3 - O SICAS

74

As vantagens da programação orientada a objectos devem-se principalmente às

seguintes características:

♦ Abstracção. É o processo de extrair as características essenciais de um objecto

real/concreto, retendo apenas a informação básica e excluindo-se todas as especificidades,

aspectos irrelevantes ou secundários. O conjunto das características resultante da

abstracção forma um tipo de dados abstracto com informações sobre o seu estado e

comportamento. Através deste mecanismo foi possível entender formas complexas, ao

dividi-las em partes e analisar cada uma delas separadamente.

♦ Encapsulamento. É o processo de combinar tipos de dados, dados e funções

relacionadas num único bloco de organização. Assim, por um lado, permite proteger os

dados, através de acessos a métodos determinados/adequados evitando que os seus dados

sejam corrompidos por aplicações externas, protegendo uma classe de acessos exteriores.

Por outro lado, permite que a visibilidade atribuída aos campos de dados e métodos oculte

determinados detalhes da classe dos seus utilizadores escondendo a complexidade do

código. Assim, o utilizador de uma classe necessita apenas de conhecer a sua

funcionalidade e a forma como obter a informação de que necessita da classe, não se

preocupando com as particularidades de codificação dos seus métodos.

♦ Herança. É um mecanismo potente, inexistente em linguagens procedimentais,

que consiste em partilhar dados e métodos entre classes, subclasses e objectos, permitindo

estender ou aprimorar abstracções para abranger um conhecimento mais detalhado ou

refinado. Quando utilizada correctamente permite a reutilização do código e facilita a

concepção de software.

♦ Polimorfismo. É uma característica que permite à mesma mensagem (definida

na classe base de um conjunto de outras classes) originar diferentes resultados consoante

o tipo de objecto a que é enviada. Este aspecto confere uma certa flexibilidade na

nomeação de entidades e em expressar abstracções, através da possibilidade da existência

de mais do que uma forma para as mesmas classes e métodos.

A fim de concretizar estas características passa-se a referir brevemente a sua

aplicação no SICAS.

Cap. 3 - O SICAS

75

Os algoritmos são escritos através da reunião de um conjunto de estruturas. Da

análise realizada para cada uma das estruturas necessárias identificou-se um conjunto de

características comuns partilhadas entre elas. Assim criou-se uma classe base abstracta –

Bloco, na qual estão representadas todas as abstracções comuns das estruturas referidas,

nomeadamente a existência de coordenadas de desenho, as estruturas que as sucedem e

antecedem, um campo destinado a comentários, e a declaração de métodos que

possibilitam o seu desenho, execução, modificação, escrita em ficheiros, entre outros.

Cada uma das estruturas foi implementada através de uma classe que a representa,

descendente da classe base abstracta Bloco (a classe mais especializada herda todos os

métodos e atributos da classe mais geral), onde foram implementadas as suas

especificidades. Definimos cinco tipos de classes: “Atribuição”, “Repetição”, “Selecção”,

“EntradaSaída” e “ChamaFunção” que representam as estruturas com o mesmo nome.

Assim, através de mecanismos de herança podemos aceder a uma subclasse

abstraindo-nos ao nível da classe base. Ao se executarem métodos da classe base,

redefinidos pelas subclasses, são os métodos dessas subclasses que são executados. Desta

forma o SICAS utiliza polimorfismo traduzindo-se na existência dos métodos que

apresentam o mesmo nome para cada uma das subclasses (“Atribuição”, “EntradaSaída”,

“Selecção”, “Repetição” e “ChamaFunção”) e da classe base (Bloco), porém, podem ser

definidos de forma diferente e como tal produzirem efeitos variados de acordo com a

especificidade de cada subclasse.

Tendo também em mente o objectivo de uma vasta distribuição, na concepção do

SICAS houve a preocupação de escolher uma linguagem que não colocasse entraves para

alcançar o seu público alvo, nomeadamente no que respeita à sua instalação e recursos

necessários. A portabilidade existente no JAVA deve-se ao facto de apresentar uma

arquitectura neutral, com liberdade e uniformidade multiplataforma. Assim, um programa

em JAVA pode ser executado em qualquer arquitectura, isto porque se baseia num

conceito que consiste em criar código para um computador virtual, o qual, por sua vez, é

simulado por intérpretes específicos para cada computador real.

Outra razão para a escolha do JAVA como linguagem de implementação foi o

facto da robustez apresentada. Uma das tarefas importantes das linguagens de

programação reside no tratamento de excepções para lidar com condições anormais de

funcionamento de um programa. O JAVA tem classes que tornam por um lado, o

Cap. 3 - O SICAS

76

tratamento de excepções totalmente previsível e transparente para o programador e, por

outro, tornam o software mais robusto, seguro e bem estruturado.

Houve também um conjunto de facilidades que o JAVA proporcionou para o

desenvolvimento do SICAS, nomeadamente a possibilidade de execução concorrente de

processos devido à facilidade da programação de threads.

Outra característica bastante importante do JAVA, se bem que não aproveitada no

SICAS, reside na possibilidade de divulgação de produtos através da Internet, permitindo

elevados graus de interactividade, através da integração fácil nos browsers existentes, de

applets, os quais podem reagir dinamicamente às interacções do utilizador.

Cap. 4 - Utilização do SICAS

77

44 UUTTIILLIIZZAAÇÇÃÃOO DDOO SSIICCAASS

44..11 FFoorrmmaass ddee uuttiilliizzaaççããoo O SICAS apresenta um conjunto de possibilidades de utilização educativa que nos

parecem relevantes. Destacamos a possibilidade de os alunos construírem e simularem os

seus próprios algoritmos, analisando os respectivos resultados e corrigindo aspectos

eventualmente menos conseguidos. Esta é uma actividade de grande importância para a

aprendizagem dos fundamentos da programação, objectivo primeiro do desenvolvimento

deste ambiente.

Apesar de ter sido concebido para uma utilização independente, este ambiente

pode também suportar actividades em contexto de sala de aula, mesmo que o professor

pretenda levar a cabo um conjunto de actividades mais dirigidas. Uma das possíveis

utilizações do SICAS em ambiente de sala de aula refere-se à possibilidade de o professor

poder fazer simulações para a explicação de determinados problemas, exemplificando e

concretizando determinados assuntos a abordar, de forma mais realística e entusiástica.

Além disso, muitas das questões e dúvidas lançadas pelos alunos poderão ser explicadas,

recorrendo a este meio, de uma forma mais clara e economizadora de tempo. Também

como elemento de apoio à matéria a leccionar poderá ser importante a possibilidade de o

professor, durante a aula, fornecer resoluções completas, incompletas ou erradas, para os

alunos testarem, compreenderem e fazerem alterações.

O SICAS pode evidentemente ser utilizado em qualquer outro local, fora do

horário curricular, no âmbito do estudo autónomo, fundamental na aprendizagem da

programação. Assim, outro aspecto importante da utilização do SICAS reside na

possibilidade de, em utilização autónoma, o aluno auto-avaliar os seus conhecimentos

através da simulação e teste das suas resoluções. Em particular, a possibilidade de

verificar que o seu algoritmo se comporta correctamente, mesmo com os testes


78

especificados pelo professor (dados de entrada e resultados esperados), pode conferir ao

sistema uma grau de credibilidade superior perante o aluno contribuindo para que este o

utilize mais frequentemente.

Outro aspecto importante reside na possibilidade de permitir ao professor criar

conjuntos de exercícios resolvidos, constituindo assim mais um auxiliar para o estudo dos

seus alunos. Claro que neste ponto podem ser utilizadas diversas abordagens pedagógicas,

como seja fornecer resoluções correctas, incorrectas ou ainda incompletas. Apesar de

acharmos que analisar problemas resolvidos não se traduz normalmente num aumento da

capacidade de solucionar novos problemas, pensamos que o verdadeiro valor desta

característica reside em permitir aos alunos fazer alterações às resoluções existentes e

testar essas novas resoluções. Também a possibilidade de dar aos alunos algoritmos

errados, em especial com o tipo de erros lógicos que o aluno em causa habitualmente

apresenta, e pedir-lhe que procure e corrija esses erros, pode apresentar um alto valor

educativo nesta área. A possibilidade de o professor fornecer resoluções incompletas é

visivelmente vantajosa para problemas em que há repetição de código base e que para a

determinação completa da resolução há apenas que definir certos módulos. Este aspecto

possibilita ao aluno a sua concentração máxima em determinadas partes que o professor

ache conveniente para o seu nível de conhecimentos e dificuldades.

Outra característica importante do SICAS encontra-se na faculdade de os alunos

compararem algoritmos diferentes para um mesmo problema e verificar em que situações

é que uns apresentam um desempenho superior aos outros, interiorizando assim

gradualmente técnicas eficazes de programação.

Finalmente destacamos a possibilidade de o professor colocar problemas aos

alunos e verificar o seu grau de proficiência através da análise das resoluções por eles

realizadas. De acordo com esta perspectiva, é possível afirmar que o SICAS permite

avaliar e individualizar as actividades desenvolvidas pelos alunos. Com este

conhecimento, o professor pode propor actividades de acordo com os níveis actuais de

conhecimentos de cada aluno, evitando propor problemas demasiado fáceis ou difíceis, o

que geralmente se traduz em desmotivação dos alunos. Este aspecto acrescenta um

conjunto de valores importantíssimo ao sistema educativo tradicional, na medida em que

possibilita uma actividade de ensino/aprendizagem mais personalizada, contribuindo para

que os alunos possam aprender ao seu próprio ritmo, aumentando a sua motivação. Muitas

vezes os factores que mais contribuem para o desinteresse dos alunos nas salas de aula é a

sua total incapacidade de acompanhamento dos exercícios que estão a ser abordados. É


79

claro que este objectivo poderia ser atingido por outros meios, mas pensamos que o

SICAS pode proporcionar algum suporte a esta abordagem, eventualmente mais

trabalhosa para o professor.

De forma a melhor concretizar alguns aspectos de utilização do SICAS vamos de

seguida demonstrar a construção de dois exemplos.

No primeiro, pretende-se realizar um programa que, a partir de um conjunto de

valores, pedidos ao aluno, que representam as notas laboratoriais na escala de 0-20

obtidas por um conjunto de n alunos numa determinada cadeira, calcule e imprima a

média desse conjunto de valores.

O segundo exemplo tem como finalidade testar se uma determinada cadeia de

caracteres é uma capicua.

44..22 EExxeemmpplloo 11 Suponha-se que o utilizador se identifica como professor, a fim de preparar um

enunciado de um exercício para o aluno resolver. Após a sua identificação, surgem

activos os únicos menus e ícones que correspondem a acções que o professor, nesta fase

inicial, pode fazer, nomeadamente a abertura ou criação de um enunciado. Estas

possibilidades podem ser visualizadas na Figura 4.1.

Figura 4.1 Écran inicial do modo professor


80

Neste exemplo, o objectivo consiste na criação de um enunciado, para que o aluno

possa construir uma resolução. A Figura 4.2 traduz a situação resultante da realização

dessa tarefa. Notar que, a partir do momento em que se cria um enunciado, a secção

respectiva fica editável e a opção “Gravar Enunciado” activa, indicando a possibilidade de

salvaguarda do mesmo.

Figura 4.2 Écran ilustrativo das modificações provocadas pela criação do enunciado

Como o professor pretende dar ao aluno a possibilidade de averiguar a correcção

da resolução construída, vai-lhe preparar os dados necessários à realização dessa

actividade. Assim, escreve o conjunto de dados correspondentes ao formato da saída

esperada, na secção “Solução”, face ao conjunto de dados também por ele fornecidos na

secção “Entradas”.


81

Figura 4.3 Écran ilustrativo dos valores introduzidos para a solução

A ordem pela qual o professor fornece estes dados (“Solução” e “Entradas”) é

irrelevante. Supondo que, forneceu em primeiro lugar os dados esperados para a saída do

programa, resta-lhe indicar quais os valores que, a fornecer durante a execução,

conduzirão a esses resultados. Para tal, o professor terá de indicar na secção “Entradas”, o

conjunto de valores, um por linha. Tendo a secção “Entradas” activada, para adicionar um

valor basta dar um duplo clique nessa área e seleccionar a operação adequada. As

operações possíveis para preenchimento de dados nessa área podem ser visualizadas na

janela de diálogo ilustrada na Figura 4.4.

Figura 4.4 Diálogo para introdução de dados na subsecção Entradas


82

Como facilmente se depreende, dado o conjunto de opções sugestivas presentes na

janela de diálogo ilustrada na Figura 4.4, o SICAS também possibilita a alteração dos

dados fornecidos em caso de engano.

Tendo o professor preparado o conjunto de dados necessários à actividade que

pretende que o aluno realize, pode abandonar o ambiente. Para que um determinado aluno

possa resolver o problema proposto terá de realizar o procedimento habitual, invocando o

SICAS, e identificando-se.

Figura 4.5 Diálogo para introdução do nome do utilizador

Reparar agora que, no modo aluno, nesta fase inicial, a única possibilidade refere-

se à abertura de um determinado enunciado disponibilizado pelo professor, o que se

reflecte na janela presente na Figura 4.6 através de um único ícone activo que traduz

precisamente essa situação.

Figura 4.6 Écran inicial do modo aluno


83

A escolha da opção “Abrir Enunciado” seguida da selecção/escrita do nome

pretendido para o enunciado, conduz à realização da tarefa desejada. Mais uma vez, ficam

activas as opções decorrentes do acto realizado, nomeadamente Gravar Enunciado,

Fechar Enunciado, Criar Resolução, Abrir Resolução e Abrir Resolução do Professor

(caso o professor tenha alguma construída).

Figura 4.7 Écran ilustrativo das modificações provocadas pela abertura de um enunciado

Na situação presente, como o que o aluno pretende fazer é a construção de uma

resolução, escolhe a opção a isso destinada, resultando daí o aparecimento de uma janela

(Figura 4.8) na qual tem de indicar o nome a atribuir à resolução. De salientar que é o

ambiente que se encarrega de atribuir uma extensão adequada, .res, ao ficheiro.

Figura 4.8 Diálogo para atribuição de um nome a uma resolução

Após a etapa anteriormente referida surgem automaticamente os dois componentes

delimitadores da resolução “Principal” e “Retornar”, já explicados no capítulo anterior.


84

Figura 4.9 Écran inicial de uma resolução

Há então que dar início à construção da resolução propriamente dita. Nesta

situação, como o problema é de pequenas dimensões e supondo que o aluno sabe

exactamente o número e tipo de variáveis pretendidas, começa pela sua declaração. Para

tal, recorre à selecção do ícone ou elemento de menu adequado o qual evoca uma janela

de diálogo análoga à representada na Figura 4.10.

Figura 4.10 Diálogo para gestão das variáveis

Tendo as variáveis declaradas há que proceder à definição e inserção das estruturas

de controlo necessárias. Assim, uma vez escolhido o tipo de estrutura a introduzir há que

activar o rectângulo de inserção a isso destinado, existente no centro de cada linha de

interligação entre estruturas. À medida que novos elementos vão sendo introduzidos o

diagrama representativo da resolução vai sendo recalculado e redesenhado de forma a

contemplar uma visualização proporcional de todos os seus componentes.


85

Neste exemplo, o aluno começa por definir uma estrutura de Entrada/Saída que

tem como finalidade conhecer o número de elementos, pedidos durante a execução. Nesta

situação a actividade do aluno resume-se a escolher a variável a ler de entre as que definiu

previamente.


A introdução da estrutura referida traduz-se na janela da Figura 4.12. De salientar

também a visualização da totalidade das variáveis declaradas na área a isso dedicada, com

a respectiva actualização à medida que vão sendo acrescentadas, eliminadas ou alteradas.

Figura 4.12 Écran ilustrativo de uma situação de resolução

Suponhamos que o aluno decide armazenar os valores, com cada uma das

classificações, em posições consecutivas de uma tabela em memória. Para tal, tem a


86

necessidade de definir uma estrutura que permita realizar um ciclo, de forma a permitir a

leitura de todos os elementos que irão integrar a tabela referida.

Face às possibilidades oferecidas pelo SICAS perante este cenário a escolha recai

sobre a estrutura for. A definição dos campos necessários à sua definição é ilustrada na

Figura 4.13.

Figura 4.13 Diálogo de especificação de uma repetição for

O preenchimento referido conduz à actualização da resolução na forma mostrada

na Figura 4.14.



87

Há então que proceder à leitura de cada um dos elementos da tabela, da forma

representada na Figura 4.15.


Convém que o aluno tenha presente que a produção dos dados resultantes da sua

resolução tem de obedecer ao formato especificado pelo professor, para uma eventual

avaliação correcta da sua resolução. Assim, preenche de seguida as estruturas que

contribuem para essa concretização, introduzidas nos pontos de inserção adequados.

Como exemplo, mostramos o preenchimento da estrutura de escrita na Figura 4.16,

resultando na actualização visualizada na Figura 4.17.

Figura 4.16 Diálogo de especificação de uma escrita


88


A fim de completar a sua resolução, o aluno tem ainda que definir as estruturas

que permitem realizar o cálculo da média dos valores constantes na tabela. A Figura 4.18

ilustra a definição de uma dessas estruturas, a iniciação com o valor “0” da variável que

irá acumular a soma de todos os elementos da tabela.

Figura 4.18 Diálogo de especificação de uma atribuição

A definição das estruturas restantes, segundo os formatos já apresentados, conduz

à conclusão da resolução, da qual parte é apresentada na Figura 4.19.


89


Tendo concluído a sua resolução o aluno pode simulá-la, para isso há que mudar

de ambiente, bastando para tal clicar no primeiro ícone da barra de tarefas. Uma vez nesse

ambiente terá de configurar os parâmetros pretendidos para o decorrer da simulação, já

explicados no capítulo três desta dissertação. De seguida são ilustradas algumas janelas

representativas da evolução da simulação da resolução construída.

Figura 4.20 Selecção das opções de configuração para o decorrer de uma simulação


90

Figura 4.21 Ilustração de um pedido de introdução de dados durante uma simulação



91



Porém, o programa apesar de aparentemente correcto, na medida em que a “Saída”

da resolução coincide com o “Exemplo de Saída”, não realiza a validação de dados no que

respeita ao tipo de valores possíveis para o problema em questão. De seguida mostra-se a

elaboração de uma estrutura repetitiva condicional com a finalidade de testar os valores


92

entrados pelo aluno durante a execução. Este procedimento é introduzido para demonstrar

que é uma boa prática de programação evitar a introdução de dados indesejáveis.

Figura 4.25 Diálogo de especificação de uma repetição while



93

44..33 EExxeemmpplloo 22 A Figura 4.27 traduz a situação de início de resolução do segundo problema

proposto em que é realizado o pedido de introdução da cadeia de caracteres com a

respectiva leitura.


A forma habitualmente utilizada para a resolução deste tipo de problemas consiste

na comparação do primeiro elemento da string com o último, o segundo com o

antepenúltimo, repetindo o processo até que todos os pares estejam comparados ou se

encontrem pares com caracteres diferentes. Porém, vamos supor que, por opção do aluno

ou imposição do professor, o aluno realiza uma actividade pedagógica de comparação de

resoluções. Assim, após ter uma resolução para o problema proposto, de acordo com o

método acima indicado, o aluno vai realizar um outro tipo de resolução para o mesmo

problema. Para a realização de tal tarefa evoca uma função por ele definida que permite

inverter a cadeia de caracteres fornecida e, posteriormente, testa se a cadeia de caracteres

resultante da inversão é igual à original.

A Figura 4.28 retracta a situação em que se selecciona a opção de definição/adição

de uma nova função.


94

Figura 4.28 Selecção da opção para adição de uma função

A acção anterior conduz ao aparecimento de uma janela de introdução de dados

análoga à apresentada na Figura 4.29 destinada à atribuição de um nome à função.

Figura 4.29 Diálogo para introdução do nome de uma função

Após isto, o processo de construção da função processa-se de forma análoga à

construção da função “Principal”. Na janela representada na Figura 4.30 pode-se analisar

a construção referida salientando o recurso a certas funções pré-definidas no SICAS.


95

Figura 4.30 Écran ilustrativo de uma situação de resolução numa função

A diferença relativamente à função “Principal” reflecte-se nos elementos

delimitadores destinados à passagem de parâmetros. Assim, há que editar o cabeçalho da

função a fim de definir os seus parâmetros formais. Esta operação é realizada numa

janela similar à ilustrada na Figura 4.31.

Figura 4.31 Diálogo de definição dos parâmetros formais

Há também a necessidade de editar o elemento terminal da função, a fim de

indicar qual a variável que contém o valor a devolver à função chamante, resultando no

aparecimento da janela de diálogo constante na Figura 4.32.


96

Figura 4.32 Diálogo de especificação do valor de retorno de uma função

A definição destes valores reflecte-se na janela representada na Figura 4.33. De

salientar que, a partir do momento em que há o estabelecimento dos parâmetros formais

estes são listados separadamente na secção “Variáveis” a fim de traduzir o seu

comportamento especial.

Figura 4.33 Écran ilustrativo de uma situação de resolução numa função

O SICAS permite também a livre transição entre as diversas funções existentes

numa resolução. Essa tarefa pode ser conseguida através da selecção da opção de menu

adequada, e consequente indicação da função que se pretende editar, ou por selecção da

função pretendida na subsecção “Funções” da “Área de dados auxiliar”. A Figura 4.34

ilustra a primeira dessas possibilidades.


97

Figura 4.34 Selecção da opção para transição entre funções

Porém, definida uma função ela só é realmente evocada após a inserção do

elemento ChamaFunção no local desejado, segundo o procedimento habitualmente usado

para a inserção de qualquer componente. A escolha da opção referida conduz a uma janela

de diálogo análoga à apresentada na Figura 4.35.

Figura 4.35 Diálogo para estabelecimento de correspondência entre parâmetros formais e reais

Em primeiro lugar deve-se escolher a função que se pretende chamar, de entre as

que estão definidas. Uma vez seleccionada a função surgem o número de parâmetros, o

tipo e a ordem pela qual há que estabelecer a correspondência, bastando para isso que o


98

aluno active a linha correspondente ao parâmetro em causa e digite a variável ou

expressão que lhe corresponde seguida de “Actualizar”. O aluno deve também escolher

qual a variável da função chamante que recebe o valor de retorno, caso este exista, para

isso há que escolhê-la de entre as variáveis possíveis.

A Figura 4.36 traduz a parte referente à chamada da função definida, seguida dos

elementos que permitem concluir a resolução que visa dar resposta ao problema

pretendido.

Figura 4.36 Écran ilustrativo de uma situação de resolução com evocação de uma função

De salientar ainda que qualquer acção do aluno jamais terá um caracter definitivo,

assim, em qualquer momento, poderá apagar, modificar ou copiar um dos componentes,

bastando para isso seleccioná-lo e escolher as acções respectivas. Estas podem ser

realizadas através de menus, dos ícones existentes na barra de tarefas ou activando um

menu contextual através do botão direito do rato. De forma a orientar o aluno sobre qual o

componente seleccionado/activado, há uma mudança de cor nesse componente para

salientar esse facto. Estes aspectos podem ser visualizados na Figura 4.37.


99

Figura 4.37 Activação de um menu contextual para edição de uma estrutura

Suponhamos agora que, no processo de construção da função “Inverte”, o aluno

comete um erro lógico. Por exemplo, assumamos que a “Condição de teste”, para

finalização do ciclo, foi preenchida com i > 0 em vez de i >= 0. Nessa situação, quando

finaliza a simulação da execução da função “Inverte”, constata que esta não vai retornar

uma string correspondente à inversão da original (faltando-lhe um caracter), como se

ilustra na Figura 4.38. A incorrecta inversão da string reflecte-se posteriormente na

conclusão obtida, como se demonstra na janela apresentada na Figura 4.39.



100


Cap. 5 - Conclusões e Trabalho Futuro

101

55 CCOONNCCLLUUSSÕÕEESS EE TTRRAABBAALLHHOO FFUUTTUURROO

55..11 CCoonncclluussõõeess O trabalho desenvolvido, constitui uma proposta que visa dar resposta a alguns dos

problemas sentidos pelos alunos numa fase inicial de aprendizagem de uma cadeira de

programação.

Pensamos que o SICAS apresenta um conjunto de características para ser bem

sucedido e não constituir apenas mais um trabalho desenvolvido no âmbito de um

projecto académico com vista à obtenção de um grau.

Relativamente à sua divulgação e distribuição será realizada primeiramente nas

instituições a que pertencemos, ao corpo docente responsável pela leccionação de cadeiras

de programação, para apreciação e realização de testes. No que diz respeito a este aspecto,

o SICAS possui um conjunto de especificidades que contribuem para que não haja

qualquer entrave à sua experimentação, nomeadamente:

♦ Custo. De forma a atingir um elevado número de utilizadores, o SICAS vai ser

distribuído gratuitamente a alunos, professores e eventuais interessados. Além disso, não

envolve custos elevados ao nível de hardware e software, para além dos recursos

utilizados e necessários para as aplicações habitualmente utilizadas pelos utilizadores

típicos desta área.

♦ Disponibilidade. O SICAS estará acessível para o aluno utilizar fora da parte

lectiva, durante o período de tempo desejado, sem as limitações que um professor

normalmente apresenta. Para isso será disponibilizado numa máquina central acessível

sem quaisquer restrições.

♦ Portabilidade. A plataforma de desenvolvimento do SICAS foi escolhida para

que ele seja facilmente transportável, apresentando uma arquitectura neutral, de tal forma


102

que o aluno o possa utilizar em qualquer lugar onde esteja a desempenhar a sua prática de

programação.

♦ Facilidade de instalação. O SICAS é distribuído com uma versão executável

bastando para isso que o utilizador execute um comando, em resposta ao qual entrará

imediatamente no ambiente.

O SICAS apresenta também um conjunto de características que, na nossa opinião,

levam a que não haja uma rejeição inicial, muito comum em variados programas, entre

elas:

♦ Simplicidade. É simples de utilizar, exigindo pouco tempo de aprendizagem,

para não afastar o aluno no primeiro contacto. Possui também a maioria das opções não

permitidas desactivadas para limitar as acções do aluno, evitando a sua dispersão e

distracção com detalhes supérfluos numa primeira relação com o ambiente. Além disso, é

fornecido conjuntamente com um manual de utilização explicativo das suas

funcionalidades, utilidades e demonstração de construção de alguns exemplos.

♦ Atractividade. A aparência visual e estética da forma como o aluno constrói as

suas actividades é, na nossa opinião, apelativa, não o sobrecarregando com informação

textual enfadonha, sendo antes apresentada de uma forma gráfica mais estimulante.

♦ Organização. A informação é apresentada de forma clara, organizada e

estruturada, com áreas diferenciadas para os diversos tipos de assuntos e actividades,

sendo igualmente bem referenciado os momentos e locais onde o aluno deve proceder à

introdução de dados.

♦ Controlo. Apesar de poder ser utilizado em equipa, com acompanhamento ou

não de um elemento especializado, o SICAS, como prevê a sua utilização por alunos

isoladamente, tenta de alguma forma dar-lhes alguma orientação no que respeita ao tipo

de possibilidades de escolha. A ideia aqui patente é a de manter a actividade do aluno o

mais consistente possível sem no entanto lhe retirar a liberdade da realização do tipo de

actividade desejada.

♦ Interactividade. Permitindo ao aluno interactuar, controlar e desempenhar um

papel activo na construção e animação dos algoritmos. Apresentando sempre uma

resposta visível em resultado de uma acção do aluno e em especial uma capacidade de

resposta imediata, sempre que o aluno erra, para evitar a edificação de novos conceitos

sobre bases incorrectas.


103

Porém, os aspectos referidos que conferem ao SICAS alguma simplicidade não

impedem que o ambiente criado não seja rico e poderoso, pois os iniciados em

determinada matéria necessitam de sistemas persuasivos e sofisticados e não de sistemas

simplistas como a maioria das vezes se pensa. Assim, o SICAS possui um conjunto de

características que lhe conferem esta supremacia relativamente a variados sistemas com

propósito análogo, entre elas:

♦ Flexibilidade e funcionalidade. Atribui ao utilizador um certo grau de controlo

no que respeita às actividades que o aluno pode realizar. Desta forma, permite a

configuração de certos elementos fundamentais ao esclarecimento das dúvidas de cada

aluno particular, sem que isso implique qualquer alteração no código do sistema.

♦ Animação. Para que a visualização do algoritmo expresse as ideias e transmita a

informação nele presente com mais vivacidade e entusiasmo, facilitando a apreensão dos

conceitos, o SICAS possibilita a simulação animada da forma como um algoritmo

funciona, dando ao aprendiz uma panorâmica sobre as várias fases e entidades envolvidas

no algoritmo em causa.

♦ Representações alternativas. Cada problema proposto ao aluno pode conter

várias resoluções, de forma a possibilitar-lhe diferentes perspectivas e soluções para os

mesmos conceitos ou ideias.

Pensamos que o SICAS reúne as condições mais importantes para a aceitação de

uma ferramenta com o seu propósito. Como já referido, o primeiro protótipo foi objecto

de avaliação por parte de um conjunto de professores com experiência no ensino da

programação.

Contudo, como desconhecemos métodos automáticos fiáveis para testar e avaliar

ambientes destinados à aprendizagem de programação, pensamos que há toda a

conveniência em efectuar estudos empíricos adequados. Isto porque, para além de darem

algumas indicações no sentido de medir a eficácia do sistema, podem também servir para

orientar os melhoramentos a efectuar e ajudar a definir novas áreas de pesquisa. Assim,

existe um conjunto de estudos que pretendemos fazer brevemente para averiguar a

efectividade e impacto do SICAS na aprendizagem destas matérias, com o público alvo a

que se destina.

A razão pela qual os estudos ainda não foram realizados com os seus destinatários

principais em ambiente real, prende-se com o facto de, para uma avaliação efectiva do

ambiente criado, este ter de ser testado de forma faseada, em determinados momentos


104

lectivos, com os alunos munidos de um certo estado de conhecimento, não coincidentes

com os prazos de realização do presente trabalho.

55..22 TTrraabbaallhhoo FFuuttuurroo Embora já se possa aceitar o SICAS como um produto verdadeiramente utilizável,

completar esta implementação inclui aumentar a quantidade de conhecimento

implementado, nomeadamente ao nível das estruturas de controlo, das estruturas de dados

e da diversificação de outros conteúdos de programação.

Passa-se de seguida a especificar alguns dos possíveis melhoramentos e extensões

futuras do SICAS:

♦ Cada exercício proposto ao aluno ter associado um ou mais campos

identificativos dos assuntos a abordar e consoante esses tipos existir a possibilidade do

aluno executar um tutorial informativo e explicativo dos conceitos subjacentes no

exercício em questão.

♦ Os exercícios adaptarem-se aos alunos de forma controlada pelo programa, o

que pode acontecer por exemplo, com base em modelos e perfis de alunos que revelem os

seus níveis de conhecimentos. Assim, seria imposto ao aluno uma ordem de exercícios a

resolver. Associada a esta característica automática do sistema, o professor também

poderia realizar algumas alterações a essa ordem para um determinado aluno específico.

♦ O professor, num mesmo computador verificar as resoluções dos seus alunos,

para um mesmo problema, para isso era fundamental que os dados dos alunos fossem

concentrados num único computador central e não residissem apenas no computador local

onde o aluno usa o ambiente.

♦ Adicionar a capacidade de geração de relatórios sobre as actividades dos

alunos, nos quais constaria informação que o professor pretendesse, dentro da

estabelecida. Nesse relatório constaria, para cada aluno e relativamente a cada exercício,

um conjunto de informação que permitisse de alguma forma avaliar o seu desempenho e

evolução.

♦ Acrescentar a possibilidade de executar apenas partes do algoritmo, definidas

pelo utilizador, através da introdução de breakpoints. Seria interessante a possibilidade de

definir o bloco ou condição em que se quer começar e/ou parar a execução, a

possibilidade de não entrar nos fluxogramas das funções chamadas, e outras coisas típicas

de debugging em compiladores.


105

♦ A alteração dos valores das variáveis durante a sua execução, a fim de

possibilitar a realização de determinados testes.

♦ O alargamento dos tipos de dados estabelecidos permitindo a existência de

tabelas multi-dimensionais bem como a definição das estruturas de dados habitualmente

leccionadas em cadeiras mais avançadas de linguagens de programação nomeadamente,

listas ligadas, pilhas, filas, árvores, ficheiros, entre outras.

♦ A partir do código gerado, haver a ligação do programa ao compilador. Apesar

de não ser uma possibilidade muito importante para os objectivos propostos, significaria

uma opção mais cómoda para o utilizador evitando o esforço de transição entre o SICAS

para gerar o código e posteriormente abri-lo e executá-lo no local adequado.

♦ Fornecer a possibilidade de desfazer vários níveis de operações, vulgo undo.

Embora não consideremos esta característica de primordial importância pensamos que

muitas vezes seria útil para o utilizador o facto de poder voltar atrás nas suas acções, sem

que para isso tivesse que despender muito esforço e tempo na reconstituição das

operações.

♦ Implementar a possibilidade de partilhar funções entre problemas diferentes de

uma forma sugestiva e confortável para o utilizador. Apesar de actualmente esta opção ser

possível através de alguns malabarismos, nomeadamente por meio da edição dos ficheiros

onde constam as resoluções dos problemas.

♦ A possibilidade de existência de vários conjuntos de teste, para a mesma

resolução.

♦ A orientação da construção da resolução do aluno, por exemplo através de

avisos em situações de desvio na construção do algoritmo, por meio de simulações

efectuadas em background, tendo em conta um conjunto de valores definidos para

entradas e saídas.

♦ Para além da animação do fluxograma, existir uma outra animação sincronizada

com a anterior que representasse um mundo mais familiar e atractivo para o aluno. Esta

opção teria um caracter multimédia em que para a execução dessa animação o utilizador

escolheria uma personagem (de entre as existentes) e um dos diferentes cenários onde a

sua personagem desempenharia diferentes tarefas e percorreria diferentes itinerários

representativos das acções executadas, consoante o problema em questão. Esta simulação

envolveria a criação de um modelo cuidadoso para que não houvesse uma visão distorcida

da realidade, havendo a preocupação de criar condições para o aprendiz fazer a transição

entre a simulação e o fenómeno no mundo real.

Bibliografia

106

BBIIBBLLIIOOGGRRAAFFIIAA

Anderson, J. e Reiser, B. (1985). The LISP Tutor. Byte, Vol. 10, Nº 4, pp. 159-

175.

Arnheim, R. (1969). Visual Thinking. Berkley and Los Angeles: University of

California Press.

Baecker, R. e Marcus, A. (1986). Design Principles for enhanced presentation of

computer program. In Proceedings of the Human Factors in Computing Systems. New

York. Pp. 51-58.

Baeza-Yates, R., Jara, L., e Quezada, G. (1992). VCC: Automatic Animation of C

Programs. In Proceedings of COMPUGRAPHICS'92. Lisboa, Portugal. Pp. 389-397.

Baker, R., Boilen, M., Goodrich, M., Tamassia, R. e Stibel, B. (1999). Testers and

Visualizers for Teaching Data Structures. In Proceedings of SIGCSE’99. New Orleans,

LA, USA. Pp. 261-265.

Benford, S. e Burke, E. (1993). Ceilidh: a course administration and marking

system. In Proceedings of the International Conference on Computer-Based Learning in

Science. Vienna. Pp. 364-372.

Bently, J. e Kerninghan, B. (1991a). A system for algorithm animation. Computing

Systems, Vol. 4, Nº 1, pp. 5-30.

Bibliografia

107

Bitter, G. (1985). Trends in Hardware/Software. Computers in the Schools, Nº 2,

pp. 15-27.

Bork, A. (1981). Learning with Computers. Digital Press, Bedford, Mass.

Brown, A. e Ferraro, R. (1985). Diagnosing Zones of Proximal Development. In J.

V. Wertsch (Ed.), Culture, Communication, and Cognition: Vygotskian Perspectives.

New York: Cambridge University Press. Pp. 273-305.

Brown, A., Bransford, J., Ferraro, R., e Campione, J. (1983). Learning,

Remembering and Understanding. In J. Flavell and E. Markham (Eds.), Carmichael’s

Manual of Child Psychology. New York: John Wiley & Sons, Nº 3, pp. 77-166.

Brown, J. e Cunningham, S. (1989). Programming the user interface. Principles

and Examples. John Wiley & Sons.

Brown, M. (1988). Exploring algorithms using BALSA-II. IEEE Computer, Vol.

21, Nº 5, pp.14-36.

Brown, M. (1991). ZEUS: A System for algorithm animation and multi-view

editing. In Proceedings of the 1991 IEEE Workshop on Visual Languages. Japan. Pp. 4-9.

Brown, M. e Sedgewick, R. (1985).Techniques for algorithm animation. IEEE

Software, Vol. 2, Nº 1, pp. 28-39.

Brusilovsky, P. (1991). Turingal - the language for teaching the principles of

programming. In Proceedings of Third European Logo Conference. E. Calabrese (Ed.).

Parma. Pp. 423-432.

Brusilovsky, P. (1993). Program visualization as a debugging tool for novices. In

Proceedings of INTERCHI’93. Amsterdam. Pp. 29-30.

Bibliografia

108

Burnett, M., Baker, M., Bohus, C., Carlson, P., Yang, S. e Zee, P. (1995). Scaling

up visual programming languages. IEEE Computer, Vol. 28, Nº 3, 45-54.

Calabrese, E. (1989). Marta – The ”intelligent turtle”. In Proceedings of the

Second European Logo Conference. G. Schuyten and M. Valcke (Eds.). Ghent, Belgium.

Pp. 111-127.

Calloni, B. e Bagert, D. (1993). BACCII: An iconic syntax-directed system for

teaching procedural programming. In Proceedings of the 31st ACM Southeast

Conference. Birmingham. Pp. 177-183.

Calloni, B., Bagert, D. e Haiduk, H. (1996). Iconic vs. text-based programming in

the introductory programming sequence. In Proceedings of the ASEE Annual Conference.

Washington DC. CD-ROM 6pp.

Chang, B.–W., Ungar, D. e Smith, R. (1995). Getting Close to Objects. In Visual

Object-Oriented Programming Concepts and Environments, Edd. M. Burnett, A.

Goldberg & T. Lewis, Manning. Pp. 186.

Chang, S.-K. (1990). Principles of Visual Languages. In Principles of Visual

Programming Systems, Ed. S-K. Chang, Prentice-Hall. Pp. 2.

Chang, S.-K., Costagliola, G., Pacini, G., Tucci, M., Tortora, G., Yu, B. e Yu, J.

(1995). Visual-Language System for User Interfaces. IEEE Software, Vol. 12, Nº 2, pp.

33-44.

Clarke, A. (1992). The principles of screen design for computer based learning

materials. 2nd Edition. Learning Methods Project Report. Employment Department

Group.

Bibliografia

109

Costagliola, G., De Lucia, A., Orefice, S. and Tortora, G. (1995). Automatic

generation of visual programming environments. IEEE Computer, Vol. 28, Nº 3, 56-66.

Cox, B. (1986). Object Oriented Programming: An Evolutionary Approach.

Addison Wesley. Pp. 158.

Daru, R. (1985). Evaluation by graphics. In Faludi, A. e Voogd, H. (Eds.),

Evaluation of complex policy problems. Delftsche Uitgevers Maatschappij Delft.

de Bono, E. (1983). The Direct Teaching of Thinking as a Skill. Phi Delta

Kappan, Nº 64, pp. 703-708.

Dillon, L., Kutty, G., Melliar, P., Moser, L. e Ramakrishna, Y. (1994). Visual

specifications for temporal reasoning. Journal of Visual Languages and Computing, Vol.

5, Nº 1, pp. 61-82.

Dionne, M. e Mackworth, A. (1978). ANTICS – A System for Animating LISP

Programs. Computer Graphics and Image Processing, Vol. 7, pp. 105-119.

Duisberg, R. (1988). Animation using temporal constraints: an overview of the

animus system. Human Computer Interaction, Vol. 3, Nº 3, pp. 275-307.

Edel, M. (1986). The Tinkertoy graphical programming environment. In

Proceedings of COMPSAC’86 IEEE. Chicago, Illinois.

Bibliografia

110

Eisenstadt, M. e Brayshow, M. (1988). The Transparent Prolog Machine: an

execution model and graphical debugger for logic programming. Journal of Logic

programming, Vol. 5, Nº 4, pp.1-66.

Ellis, G. e Lund, G. (1994). G2 - A design language to help novice C

programmers. Disponível em http://www2.ulst.ac.uk/misc/cticomp/gpellis.html.

Feuerstein, R. (1980). Instrumental Enrichment. Baltimore: University Park Press.

Figueiredo, A. e Mendes, T. (1985). As tecnologias da informação no ensino e na

formação profissional. Caderno nº1. Grupo de Informática, Departamento de Engenharia

Electrotécnica, Universidade de Coimbra.

Fix, V. e Wiedenbeck, S. (1996). An intelligent tool to aid students in learning

second and subsequent programming languages. Computers & Education, Vol. 27, Nº 2,

pp. 71-83.

Ford, L. e Tallis, D. (1994). Interacting Visual Abstractions of Programs.

University of Exeter Department of Computer Science Report, RN 273.

Frederickson, N. (1984). Implications of Cognitive Theory for Instruction in

Problem Solving. Review of Educational Research, Nº 54, pp. 363-407.

Gagne, R. M. (1977). The Conditions of Learning. (3rd edition). New York: Holt,

Rinehart and Winston.

Gentner, D. (1992). Interfaces for Learning: motivation and the locus of control.

In F. Engel, D. Bouwhuis, T. Bösser, G. d‘Ydewalle (Eds.), “Cognitive Modeling and

Environments in Language Learning”, Spring-Verlag.

Glen, A. e Ellis, A. (1982). Direct and Indirect Methods of Teaching Problem

Solving to Elementary School Children. Social Education, Nº 46, pp. 134-136.

Bibliografia

111

Glinert, E. (1990). Nontextual Programming Environments. In Principles of Visual

Programming Systems, Ed. S-K. Chang, Prentice-Hall, pp. 145,148,170.

Glinert, E. e Gonczarowski, J. (1987). A (Formal) Model for (Iconic)

Programming Environments. In Proceedings of Interact’87. Stuttgart, W. Germany.

Glinert, E. e Tanimoto, L. (1984). Pict: an interactive graphical programming

environment. IEEE Computer, Vol. 17, Nº 11, pp. 7-25.

Goldberg, A., Burnett, M. e Lewis, T. (1995). What Is Visual Object-Oriented

Programming?. In Visual Object-Oriented Programming Concepts and Environments,

Edd. M. Burnett, A. Goldberg & T. Lewis, Manning. Pp. 11.

Greeno, J. G. (1980). Trends in the Theory of Knowledge for Problem Solving. In

D. T. Tuma and R. Reif (Eds.), Problem Solving and Education: Issues in Teaching and

Research. Hillsdale, NJ: Erlbaum.

Haber, R. e Wilkinson, L. (1982). Perceptual Components of Computer Displays.

IEEE Computer Graphics and Applications, Nº 2, pp. 23-35.

Hanciles, B., Shankararaman, V. e Munoz, J. (1997). Multiple representation for

understanding data structures. Computers & Education, Vol. 29, Nº 1, pp. 1-11.

Hayes, J. R. (1980). Teaching Problem-Solving Mechanisms. In D. T. Tuma and

R. Reif (Eds.), Problem Solving and Education: Issues in Teaching and Research.

Hillsdale, NJ: Erlbaum.

Heltulla, E., Hyskykari, A., e Raiha, K.-J. (1989). Graphical Specifications of

Algorithm Animations with ALLADIN. In Proceedings of The Twenty-Second Annual

Bibliografia

112

Hawaii International Conference on System Sciences. New York: IEEE Computer

Society, pp. 892-901.

Huang, K.-T. (1990). Visual Interface Design Systems. In Principles of Visual

Programming Systems, Ed. S-K. Chang, Prentice-Hall, pp. 68.

Hvorecky, J. (1992). Karel the Robot for PC. In Proceedings of the East-West

Conference on Emerging Computer Technologies in Education. P. Brusilovsky and V.

Stefanuk (Eds.). Moscow. Pp. 157-160.

Ingargiola, G, Hoskin, N., Aiken, R., Duby, R., Wilson, J., Papalaskari, M,

Christensen, M., e Webster, R. (1994). A repository that supports teaching and

cooperation in the introductory AI course. In Proceedings of the 1994 ACM SIGCSE

Technical Symposium. Phoenix, AZ.

Jehng, J., Shih, Y., Liang, S. e Chan, T. (1994). Turtle-Graph: A computer

Supported Cooperative learning environment. In Proceedings of the ED-MEDIA’94.

Vancouver, BC, Canada. Pp. 293-298.

Johnson, W. e Soloway, E. (1985). PROUST: An automatic debugger for Pascal

programs. BYTE, Vol. 10, Nº 4, pp. 179-190.

Kagan, D. (1988). Learning how to program or use computers: a review of six

applied studies. Educational Technology, March 1988, pp. 49-51.

Kann, C., Lindeman, R. e Heller, R. (1997). Integrating Algorithm Animation into

a Learning Environment. Computers & Education, Vol. 28, No. 4, pp. 223-228.

Karsai, G. (1995). A configurable visual programming environment: a tool for

domain-specific programming. IEEE Computer, Vol. 28, Nº 3, pp. 36-44.

Bibliografia

113

Kay, J. e Tyler, P. (1993). A microworld for developing learning design strategies.

Computer Science Education, Vol. 3, No. 1, pp. 111-122.

Kimura, T., Apte, A., Sengupta, S. e Chan, J. (1995). "Form/Formula: A visual

programming paradigm for user-definable user interfaces". IEEE Computer, Vol. 28, Nº

3, pp. 27-35.

Krasnor, L. e Mitterer, J. (1984). LOGO and the Development of General

Problem-Solving Skills. The Alberta Journal of Educational Research, Nº 30, pp. 133-

144.

Lawrence, A., Badre, A. e Stasko, J. (1994). Empirically Evaluating the Use of

Animations to Teach Algorithms. In Proceedings of the 1994 IEEE Symposium on Visual

Languages. St. Louis. Pp. 48-54.

Linn, M. (1985). The cognitive consequences of programming instruction in

classrooms. Educational Research, Vol. 14, Nº 5, pp. 14-16, 25-29.

Lodding, L. (1983). Iconic Interfacing. IEEE Computer Graphics and

Applications, Vol. 3, Nº 2.

Lord, H. (1994). Visual programming for visual applications: a new look for

computing. Object Magazine, Vol. 4, Nº 4.

Mackey, J. (1977). Three Problem-Solving Models for the Elementary Classroom.

Social Education, Nº 41, pp. 408-410.

Mayer, R., Dyck, J. e Vilberg, W. (1986). Learning to Program and learning to

think: What’s the connection? Communications of the ACM, Nº 29, pp. 605-610.

Bibliografia

114

McCalla, G., Greer, J. e SCENT Research Team. (1988). Intelligent Advising in

Problem Solving Domains: The SCENT-3 Architecture. Proceedings of the First

International Conference on Intelligent Tutoring Systems. Montreal, Canada. Pp. 124-131.

Meisalo, V., Sutien, E. e Tarhio, J. (1997). CLAP: teaching data structures in a

creative way. In Proceedings of ITiCSE’97. Uppsala, Sweden. Pp. 117-119.

Mendes, A. J. e Mendes, T. (1988). VIP – A Tool to VIsualize programming

examples. In Proceedings of Education and Application of Computer Technology. Malta.

Pp. 131-140.

Miara, R., Musselman, J., Navarro, J., e Shneiderman, B. (1983). Program

Indentation and Comprehensibility. Communications of the ACM, Vol. 26, Nº 11, pp. 861-

867.

Miller, G. (1956). The magical number seven, plus or minus two: some limits on

our capacity for processing information. Psychological Review, Nº 63, pp. 81-97.

Miller, P. e Chandhok, R. (1989). The design and implementation of the Pascal

Genie. In Proceedings of the ACM Computer Science Conference. Louisville, KY.

Moher, T. (1988). Provide: A process visualization and debugging environment.

IEEE Transactions on Software Engineering, Vol. 14, Nº 6, pp. 849-857.

Mullet, K., e Sano, D. (1995). Designing Visual Interfaces: Communication

Oriented Techniques. Englewood Cliffs: SunSoft Press & Prentice Hall.

Myers, B. A. (1983). Incense: A System for Displaying Data Structures. Computer

Graphics, Vol. 17, Nº 3, pp. 115-125.

Naps, T. L. (1990). Algorithm visualization in computer science laboratories. In

Proceedings of the ACM SIGCSE Technical Symposium. Pp. 105-110.

Bibliografia

115

Newell, A. (1980). One Final Word. In D. T. Tuma and R. Reif (Eds.), Problem

Solving and Education: Issues in Teaching and Research. Hillsdale, NJ: Erlbaum.

Nickerson, R. S. (1982). Computer programming as a vehicle for teaching of

thinking skills. Thinking, Nº 4 , pp. 42-48.

Olimpo, G. (1988). The Robot Brothers: An environment for learning parallel

programming oriented to computer education. Computers & Education, Vol. 12, No 1, pp.

113-118.

Olimpo, G., Persico, D., Sarti, L. e Tavella, M. (1985). An experiment in

introducing the basic concepts of informatics. In Proceedings of the Fourth World

Conference on Computers in Education. K. Dunkan and D. Harris (Eds.). Amsterdam. Pp.

31-38.

Paivio, A. (1969). A Mental Imagery in Associative Learning and Memory.

Psychological Review, Vol. 76, Nº 3, pp. 241-263.

Papert, S. (1980). Mindstorms, Children, Computers and Powerful Ideas. New

York. Basic Books.

Pattis, R. (1981). Karel the Robot: A gentle introduction to the art of

programming.(2nd Edition), John Wiley & Sons.

Pea, R. e Kurland, D. (1984). On the Cognitive Effects of Learning Computer

Programming. New Ideas in Psychology, Nº 2, pp. 137-168.

Piaget, J. (1970). The Science of Education and the Psychology of the Child. NY:

Grossman.

Pierson, W. e Rodger, S. (1998). Web-based animation of data structures using

JAWAA. SIGCSE Bulletin, Vol. 30, Nº 1, pp. 267-271.

Bibliografia

116

Preece, J., Rogers, Y., Sharp, H., Benyon, D., Holland, S. e Carey, T. (1994).

Human-Computer Interaction. Wokingham: Addison-Wesley Publishing Company.

Ramani, K. e Rao, T. (1994). A graphics based computer-aided learning package

for integer programming: the branch and bound algorithm. Computers & Education, Nº

23, pp. 1-10.

Rasala, R. (1999). Automatic Array Algorithm Animation in C++. In Proceedings

of SIGCSE’99. New Orleans, LA, USA. Pp. 257-260.

Reichman, R. (1986). Communication paradigms for a window system. In

Norman, D. A. e Draper, S. W. (Eds.), User Centered System Design, Hillsdale, New

Jersey, London: Lawrence Erlbaum Ass. Pub.

Repenning, A. e Sumner, T. (1995). Agentsheets: a medium for creating domain-

oriented visual languages. IEEE Computer, Vol. 28, Nº 3, pp. 17-25.

Roman, G.-C., Cox, K., Wilcox, D. e Plun, J. (1992). Pavane: a system for

declarative visualization of concurrent computations. Journal of Visual Languages and

Computing. Vol. 3, No. 2, pp. 161-193.

Romiszowski, A. (1981). Designing Instructional Systems. Kogan Page.

Rowe, N. (1981). Some rules for good simulation. Education Computer Magazine,

Novembro/Dezembro, pp. 37-40.

Russel, S. e Norvig, P. (1995). Artificial Intelligence – A Modern Approach.

Prentice Hall in AI.

Santos, C., Borges, A., Ferrari, A. e Ramos, F. (1996). Programação Assistida por

computador: a experiência na Universidade de Aveiro. 1º Simpósio Investigação e

Desenvolvimento de Software Educativo. Costa da Caparica, Portugal.

Bibliografia

117

Scanlan, D. (1989). Structured Flowcharts Outperform Pseudocode: An

Experimental Comparison. IEEE Software, Vol. 6, Nº 5, pp. 28-36.

Schiffer, S. e Fröhlich, J. (1995). Visual Programming and Software Engineering

with Vista. In Visual Object-Oriented Programming Concepts and Environments, Edd. M.

Burnett, A. Goldberg & T. Lewis, Manning, pp. 201.

Schuncke, G. e Hoffman, J. (1980). Develop Problem-Solving Readiness in

Elementary School Children. Social Studies, Nº 71, pp. 23-27.

Selker, T. (1994). COACH: A teaching Agent that learns. Communications of the

ACM, Vol. 37, Nº 7, pp. 92-99.

Shih, Y. e Alessi, S. (1994). Mental Models and transfer of learning in computer

programming. Journal of Research on Computing in Education, Nº 26, pp. 155-175.

Shneiderman, B., Mayer, R., McKay, D. e Heller, P. (1977). “Experimental

investigations of the utility of detailed flowcharts in programming”. Communications of

the ACM, Vol. 20, Nº6, pp. 373-381.

Shneiderman, B. (1986). Designing the User Interface: Strategies for Effective

Human-Computer Interaction. Addison-Wesley Publishing Company.

Shu, N. (1986). Visual Programming Languages: A perspective and a dimensional

analysis. In Visual Languages Edd. S. K. Chang, T. Ichikawa & P. A. Ligomenides.

Simon H. (1980). Problem Solving and Education. In D. T. Tuma and R. Reif

(Eds.), Problem Solving and Education: Issues in Teaching and Research. Hillsdale, NJ:

Erlbaum.

Bibliografia

118

Smith, S., e Mosier, J. (1986). Guidelines for Designing User Interface Software.

Report ESD-TR-86-278. Bedford. MA: MITRE Corporation.

Song, J., Hahn, S., Tak, K. e Kim, J. (1997). An intelligent tutoring system for

introductory C language course. Computers & Education, Vol. 28, Nº 2, pp. 93-102.

Stasko, J, e Kraemer, E. (1993). A methodology for building application-specific

visualizations of parallel programs. Journal of Parallel and Distributed Computing, Vol.

18, Nº 2 pp. 258-264.

Stasko, J. (1990). TANGO: A framework and system for algorithm animation.

IEEE Computer, Vol. 23, No. 9, pp. 27-39.

Stasko, J. (1992). Animating algorithms with XTANGO. SIGACT News, Vol. 23

Nº 2, pp. 67-71.

Stasko, J. e McCrickard, D. (1995). Real clock time animation support for

developing software visualizations. Australian Computer Journal, Vol. 27, Nº 3, pp. 118-

128.

Stasko, J., Badre, A. e Lewis, C. (1993). Do algorithm animations assist learning?

An empirical study and analysis. In Proceedings of the INTERCHI’93 Conference on

Human Factors in Computing Systems. Amsterdam, Netherlands. Pp. 61-66.

Tanimoto, S. e Glinert, E. (1986). Designing iconic programming systems:

representation and learnability. In Proceedings of IEEE Workshop on Visual Languages.

Dallas, Texas. Pp. 54.

Tentenbaum, T. e Mulkeen, T. (1984). LOGO and teaching of problem-solving: a

call for a moratorium. Educational Technology, Vol. 24, Nº 11, pp. 16-19.

Tomek, I. (1982). Josef the Robot. Computers & Education, Vol. 6, Nº 3, pp. 287-

293.

Bibliografia

119

Tomek, I., Muldner, T. e Khan, S. (1985). PMS – A program to make learning

Pascal easier. Computers & Education, Vol. 9, Nº 4, pp. 205-211.

Tullis, T. (1988). Screen Design. In Helander, M. (Ed.). Handbook of Human-

Computer Interaction. North Holland: Elsevier Science Publishers B. V.

Tyerman, S., Woods, P. e Warren, J. (1996). Loop Tutor and HyperTutor:

experiences with Adaptative Tutoring Systems. In Proceedings of the 4th Australian and

New Zealand Intelligent Information Systems Conference. V.L. Narasimhan & L.C. Jain,

Piscataway, New Jersey: IEEE. (Eds.). Pp. 60-63.

Varanda, M. J. e Henriques, P. R. (1999). “Animação de Algoritmos tornada

Sistemática”. 1º Workshop de Computação Gráfica, Multimédia e Ensino. Leiria,

Portugal.

Whale, G. (1994). DRUIDS: tools for understanding data structures and

algorithms. In Proceedings of the 1994 IEEE First International Conference on Multi-

media Engineering Education. New York. Pp. 403-407.

Wright, P. e Reid, F. (1973). “Written Information: Some alternatives to prose for

expressing the outcomes of complex contingencies”. Journal of Applied Psychology, Vol.

57, Nº2, pp. 160-166.

Yeung, R. (1990). The design and implementation of MPL: a matrix-oriented

programming environment based on logic and constraints. In Visual Languages and

Visual Programming Ed. S-K Chang. Pp. 214.

Ziegler, U. e Crews, T. (1999). An Integrated Program Development Tool for

Teaching and Learning How to Program. In Proceedings of SIGCSE’99. New Orleans,

LA, USA, pp. 276-280.

ambiente de suporte à aprendizagem de conceitos básicos de...

Documents