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
Ambiente de suporte à aprendizagem de conceitos básicos de programação
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.
Ambiente de suporte à aprendizagem de conceitos básicos de programação
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
Ambiente de suporte à aprendizagem de conceitos básicos de programação
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.
Ambiente de suporte à aprendizagem de conceitos básicos de programação
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
Ambiente de suporte à aprendizagem de conceitos básicos de programação
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
Ambiente de suporte à aprendizagem de conceitos básicos de programação
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
Ambiente de suporte à aprendizagem de conceitos básicos de programação
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.14 Écran ilustrativo de uma situação de resolução.......................................................................... 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.17 Écran ilustrativo de uma situação de resolução.......................................................................... 88
Figura 4.18 Diálogo de especificação de uma atribuição .............................................................................. 88
Figura 4.19 Écran ilustrativo de uma situação de resolução.......................................................................... 89
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.22 Écran ilustrativo de uma situação durante uma simulação......................................................... 90
Figura 4.23 Écran ilustrativo de uma situação durante uma simulação......................................................... 91
Figura 4.24 Écran ilustrativo de uma situação durante uma simulação......................................................... 91
Figura 4.25 Diálogo de especificação de uma repetição while...................................................................... 92
Figura 4.26 Écran ilustrativo de uma situação de resolução.......................................................................... 92
Figura 4.27 Écran ilustrativo de uma situação de resolução.......................................................................... 93
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.38 Écran ilustrativo de uma situação durante uma simulação......................................................... 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.
Cap. 1 - Introduçã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
Cap. 1 - Introdução
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
Cap. 1 - Introduçã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
Cap. 1 - Introdução
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.
Cap. 1 - Introduçã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.
Cap. 1 - Introdução
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.
Cap. 1 - Introdução
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
Cap. 1 - Introdução
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
Cap. 2 - Algoritmos e resolução de problemas
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
Cap. 2 - Algoritmos e resolução de problemas
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
Cap. 2 - Algoritmos e resolução de problemas
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:
Cap. 2 - Algoritmos e resolução de problemas
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
Cap. 2 - Algoritmos e resolução de problemas
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.
Cap. 2 - Algoritmos e resolução de problemas
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
Cap. 2 - Algoritmos e resolução de problemas
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
Cap. 2 - Algoritmos e resolução de problemas
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.
Cap. 2 - Algoritmos e resolução de problemas
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 é
Cap. 2 - Algoritmos e resolução de problemas
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
Cap. 2 - Algoritmos e resolução de problemas
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).
Cap. 2 - Algoritmos e resolução de problemas
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)
Cap. 2 - Algoritmos e resolução de problemas
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:
Cap. 2 - Algoritmos e resolução de problemas
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
Cap. 2 - Algoritmos e resolução de problemas
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
Cap. 2 - Algoritmos e resolução de problemas
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,
Cap. 2 - Algoritmos e resolução de problemas
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.
Cap. 2 - Algoritmos e resolução de problemas
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.
Operador Exemplo Descrição
= = 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
Operador Exemplo Descrição
&& 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.
Tipo de parâmetros:
a – numérico
Tipo de retorno:
numérico
atan(a)
Retorna o arco tangente de um valor.
Tipo de parâmetros:
a – numérico
Tipo de retorno:
numérico
bitand(a,b)
Retorna o resultado da operação binária “Conjunção”, entre dois valores.
Tipo de parâmetros:
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 parâmetros:
a – numérico, inteiro
b – numérico, inteiro
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 parâmetros:
a – numérico, inteiro
b – numérico, inteiro
Tipo de retorno:
numérico
cos(a)
Retorna o coseno trigonométrico de um valor.
Tipo de parâmetros:
a – numérico, expresso em radianos
Tipo de retorno:
numérico
int(a)
Retorna a parte inteira de um valor.
Tipo de parâmetros:
a – numérico
Tipo de retorno:
Numérico
log(a)
Retorna o logaritmo natural (base e) de um valor.
Tipo de parâmetros:
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.
Tipo de parâmetros:
a – numérico
b – numérico
Tipo de retorno:
numérico
min(a,b)
Retorna o menor de dois valores.
Tipo de parâmetros:
a – numérico
b – numérico
Tipo de retorno:
numérico
pow(a,b)
Retorna o valor a elevado ao expoente b.
Tipo de parâmetros:
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 parâmetros:
a – numérico, inteiro
Tipo de retorno:
numérico
Cap. 3 - O SICAS
53
round(a)
Retorna o valor inteiro mais próximo de a.
Tipo de parâmetros:
a – numérico
Tipo de retorno:
numérico
roundn(a,b)
Retorna o valor, com b casas decimais, mais próximo de a.
Tipo de parâmetros:
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 parâmetros:
a – numérico, expresso em radianos
Tipo de retorno:
numérico
sqrt(a)
Retorna a raiz quadrada de um valor.
Tipo de parâmetros:
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 parâmetros:
a – numérico, expresso em radianos
Tipo de retorno:
numérico
toDegrees(a)
Converte um ângulo medido em radianos no ângulo equivalente medido
em graus.
Tipo de parâmetros:
a – numérico, expresso em radianos
Tipo de retorno:
numérico
toRadians(a)
Converte um ângulo medido em graus no ângulo equivalente medido em
radianos.
Tipo de parâmetros:
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.
Tipo de parâmetros:
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).
Tipo de parâmetros:
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.
Tipo de parâmetros:
a – cadeia de caracteres
b – numérico, inteiro não negativo, inferior ao tamanho da cadeia
de caracteres a
Tipo de retorno:
cadeia de caracteres
left(a,b)
Retorna os primeiros b caracteres da cadeia de caracteres a.
Tipo de parâmetros:
a – cadeia de caracteres
b – numérico, inteiro não negativo, inferior ao tamanho da cadeia
de caracteres a
Tipo de retorno:
cadeia de caracteres
length(a)
Retorna o tamanho de uma cadeia de caracteres.
Tipo de parâmetros:
a – 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.
Tipo de parâmetros:
a – cadeia de caracteres
b – numérico, inteiro não negativo, inferior ao tamanho da cadeia
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:
cadeia de caracteres
rigth(a,b)
Retorna os últimos caracteres da cadeia de caracteres a, a partir do índice b.
Tipo de parâmetros:
a – cadeia de caracteres
b – numérico, inteiro não negativo, inferior ao tamanho da cadeia
de caracteres a
Tipo de retorno:
cadeia de caracteres
toLowerCase(a)
Converte a cadeia de caracteres a para minúsculas.
Tipo de parâmetros:
a – cadeia de caracteres
Tipo de retorno :
cadeia de caracteres
toUpperCase(a)
Converte a cadeia de caracteres a para maiúsculas.
Tipo de parâmetros:
a – cadeia de caracteres
Tipo de retorno:
cadeia de caracteres
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
Cap. 4 - Utilização do SICAS
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. É
Cap. 4 - Utilização do SICAS
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
Cap. 4 - Utilização do SICAS
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”.
Cap. 4 - Utilização do SICAS
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
Cap. 4 - Utilização do SICAS
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
Cap. 4 - Utilização do SICAS
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.
Cap. 4 - Utilização do SICAS
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.
Cap. 4 - Utilização do SICAS
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.
Figura 4.11 Diálogo de especificação de uma leitura
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
Cap. 4 - Utilização do SICAS
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.
Figura 4.14 Écran ilustrativo de uma situação de resolução
Cap. 4 - Utilização do SICAS
87
Há então que proceder à leitura de cada um dos elementos da tabela, da forma
representada na Figura 4.15.
Figura 4.15 Diálogo de especificação de uma leitura
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
Cap. 4 - Utilização do SICAS
88
Figura 4.17 Écran ilustrativo de uma situação de resolução
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.
Cap. 4 - Utilização do SICAS
89
Figura 4.19 Écran ilustrativo de uma situação de resolução
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
Cap. 4 - Utilização do SICAS
90
Figura 4.21 Ilustração de um pedido de introdução de dados durante uma simulação
Figura 4.22 Écran ilustrativo de uma situação durante uma simulação
Cap. 4 - Utilização do SICAS
91
Figura 4.23 Écran ilustrativo de uma situação durante uma simulação
Figura 4.24 Écran ilustrativo de uma situação durante uma simulação
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
Cap. 4 - Utilização do SICAS
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
Figura 4.26 Écran ilustrativo de uma situação de resolução
Cap. 4 - Utilização do SICAS
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.
Figura 4.27 Écran ilustrativo de uma situação de resolução
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.
Cap. 4 - Utilização do SICAS
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.
Cap. 4 - Utilização do 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.
Cap. 4 - Utilização do SICAS
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.
Cap. 4 - Utilização do SICAS
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
Cap. 4 - Utilização do SICAS
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.
Cap. 4 - Utilização do SICAS
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.
Figura 4.38 Écran ilustrativo de uma situação durante uma simulação
Cap. 4 - Utilização do SICAS
100
Figura 4.39 Écran ilustrativo de uma situação durante uma simulação
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
Cap. 5 - Conclusões e Trabalho Futuro
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.
Cap. 5 - Conclusões e Trabalho Futuro
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
Cap. 5 - Conclusões e Trabalho Futuro
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.
Cap. 5 - Conclusões e Trabalho Futuro
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.