LÓGICA PROGRAMAÇÃO 2

Prévia do material em texto

Construção de Abstrações em Lógica de Programação 
 
 
Mauro M. Mattos, MSc 
FURB – Universidade Regional de Blumenau 
Departamento de Sistemas e Computação 
mattos@furb.rct-sc.br 
 
 
 
RESUMO 
 
O presente trabalho contextualiza um dos problemas comuns de aprendizado de lógica de 
programação em turmas introdutórias de cursos de Computação e, descreve uma ferramenta 
de software que utiliza conceitos de sistemas especialistas, raciocínio baseado em casos e 
análise de linguagem natural para obter propostas de soluções abstratas para os problemas 
propostos. 
 
ABSTRACT 
 
This article describes one of the problems that affects students in the first steps in 
programming logic classes in computing courses and describes a software tool that uses 
expert systems, case-based reasoning concepts and natural language processing concepts in 
order to obtain high level abstractions of exercises proposed. 
 
PALAVRAS-CHAVE : Raciocínio baseado em casos, Sistemas Especialistas, Informática 
na Educação. 
 
 
1. Introdução 
 
A aprendizagem é um processo no qual experiências fomentam modificação do 
comportamento e aquisição de hábitos. Piaget (1964) [9], ao estudar a gênese do 
desenvolvimento da inteligência, demonstrou a importância da maturação do sistema nervoso, 
da ação sobre os objetos e dos fatores sociais como variáveis influenciantes na compreensão 
do processo intelectual e, demonstrou como os processos de assimilação e acomodação de 
novos conhecimentos se incorpora à estrutura do pensamento. Os processos cognitivos dizem 
respeito aos processos psicológicos envolvidos no conhecer, compreender, perceber, aprender, 
nas formas de pensar e nos tipos de pensamento. 
 
Com o processo crescente no uso de tecnologias aplicadas à educação é importante ressaltar 
não só a contribuição dos recursos computacionais existentes, mas, também, a necessidade de 
estudar-se a forma ideal para sua aplicação. 
 
É portanto, imprescindível uma constante pesquisa na área educacional para promover 
métodos de ensino mais atuais e atuantes. O computador surge como uma ferramenta de 
transmissão de conhecimentos a qual não pode deixar de ser considerada. E o computador é 
ao mesmo tempo uma ferramenta de trabalho e uma ferramenta de aprendizagem auxiliando a 
capacidade do indivíduo de utilizá-lo em todo o seu potencial para resolver problemas. 
Diversos sistemas para implementação de animações de algoritmos e de estruturas de dados 
tem sido produzidos desde o trabalho de Brown [2], como por exemplo [1,3,7]. Vários destes 
sistemas exploram muito bem a potencialidade do uso de visualizações gráficas das operações 
realizadas nas estruturas de dados como ferramenta de ensino[6]. 
 
É justamente pela abordagem abstrata no ensino da lógica de programação que justifica-se a 
pesquisa e o desenvolvimento de ferramentas e/ou aplicações tecnológicas para o aprendizado 
ideal. Os aspectos cognitivos relacionados a captação de conteúdos comprovam a eficácia de 
processos que relacionam a ferramenta computador em beneficio da produtividade intelectual. 
 
Cabe destacar que a disciplina que desenvolve os conceitos básicos de lógica de programação 
constitui-se no primeiro de uma série de passos que pretende-se venham a formar um perfil 
profissional na área de computação. Maus hábitos adquiridos nas primeiras fases podem ser 
difíceis de corrigir. Entretanto, se algum formalismo puder ser aplicado desde o início, isto 
certamente contribuirá para a formação de um perfil profissional melhor preparado. 
 
Neste sentido, vem sendo desenvolvido um projeto na FURB – Universidade Regional de 
Blumenau, no sentido de obter-se uma ferramenta didática que auxilie alunos com 
dificuldades de aprendizado de lógica de programação, conteúdo este desenvolvido na 
disciplina denominada Algoritmos. 
 
Uma primeira proposta, já validada, foi apresentada no VII Congresso Iberoamericano de 
Educación Superior en Computación.- CIESC99. Neste trabalho[5], descreve-se uma proposta 
de ferramenta didática baseada em sistemas especialistas, a qual tem por objetivo introduzir o 
conceito de análise de requisitos já nas primeiras fases do ensino de computação, de tal forma 
que o aluno acostume-se a realizar uma análise mais detalhada dos problemas que, apesar de 
serem simples, já requerem algum grau de formalização. 
 
2. Motivação 
 
O presente trabalho portanto constitui-se em um avanço em relação ao trabalho descrito em 
[5] no sentido de aprimorar a proposta de forma que, além de conduzir um processo de análise 
de requisitos, também auxilie o aluno a construir abstrações sobre a solução dos problemas 
propostos. 
 
Como apresentado em [5], os estudantes que iniciam um curso de Graduação em Informática, 
normalmente encontram uma primeira dificuldade relacionada com a disciplina de Algoritmos 
(ou com nome similar), cujo principal objetivo é o de introduzir os conceitos básicos de lógica 
de programação. Esta dificuldade é na maioria das vezes, decorrente da falta de experiência 
com os aspectos relacionados a ambientes industriais e/ou comerciais, pois é a partir destes 
ambientes que são caracterizados os exercícios propostos. 
 
Analisando-se o perfil destes alunos, verifica-se que em sua maioria, são oriundos do 2o 
Grau, e portanto, possuem conhecimentos abstratos sobre áreas científicas (matemática, 
física, biologia, etc.). Porém , quando deparam-se com a descrição textual dos enunciados dos 
problemas apresentados nesta disciplina introdutória, geralmente encontram dificuldades em 
identificar como extrair as informações necessárias para iniciar a solução destes problemas. 
 
Cabe salientar que, muitos alunos não possuem experiência prática em áreas comerciais e/ou 
industriais, a partir das quais vários exercícios são elaborados. Outros, apesar de entenderem 
os problemas propostos, nem sempre conseguem facilmente descreve-los em pequenos passos 
para os demais colegas. 
 
Um acompanhamento realizado sobre as turmas de Algoritmos durante o período 
compreendido entre os semestres: 96/1 e 98/2, permitiu a constatação de que os alunos 
poderiam ser separados claramente em 2 grupos: 
 
� aqueles que haviam entendido o “como fazer” e superado as dificuldades iniciais, e 
� aqueles que não conseguiam superá-las, ou seja, não haviam apropriado-se do 
conhecimento. 
 
Observou-se também que, quando induzidos a pensar sobre o problema através de perguntas 
direcionadas, em sua grande maioria, os alunos do segundo grupo conseguiam descrever a 
solução “intuitivamente”, ou seja, sem o formalismo necessário à área de computação. 
 
A partir destas constatações iniciou-se um trabalho no sentido de formalizar-se através de uma 
metodologia, este processo de indução, com o objetivo de conduzir o aluno no processo de 
busca da solução dos problemas propostos. Este processo foi sendo refinado ao longo dos 
referidos semestres. Ao final de cada período a metodologia era avaliada e os ajustes 
incorporados e submetidos as turmas seguintes. 
 
A partir de um nível de refinamento da proposta julgado adequado, iniciou-se o 
desenvolvimento de um sistema especialista que a partir do conhecimento sobre o processo de 
indução, permitisse a construção de uma ferramenta de software que levasse o aluno, na 
ausência do professor, a desenvolver o processo de aprendizado dos conceitos básicos da 
disciplina. Uma descrição do protótipo desenvolvido pode ser encontrada em [5]. 
 
Observou-se contudo que, o processo de indução desenvolvido não contemplava um problema 
de suma importância na área de computação: a questão das abstrações. Neste sentido, 
apresenta-se a seguir a proposta de uso de técnicas de raciocínio baseado em casos que 
procura recuperar (e construir novas) soluções genéricas (abstratas) a partir de informações 
coletadas no enunciado do problema, de forma a levar o aluno não só a gerar uma descrição 
mais completa dos requisitos do problema, mas também aprender a realizar especializações de 
soluçõesgerais para cada caso apresentado. 
 
 
3. Aspectos de engenharia de software relacionados ao contexto 
 
A cada momento verifica-se o esforço da comunidade de software e pesquisadores da área no 
sentido de desenvolver produtos de software de melhor qualidade. Já é consenso que, uma 
especificação de requisitos de baixa qualidade conduz a erros de projeto que somente muito 
tarde no ciclo de desenvolvimento serão descobertos. 
 
A importância em produzir documentos de especificação mais corretos tem levado a indústria 
de software a produzir um número significativo de ferramentas para apoio a criação e 
gerenciamento de documentos de especificação de requisitos. Poucas entretanto, atuam na 
área de avaliação de qualidade do documento em si. 
 Em função desta constatação, o Software Assurance Technology Center (SATC) do Goddard 
Space Flight Center (GSFC-NASA) iniciou o desenvolvimento de uma ferramenta que deve 
ser utilizada para análise de especificação de requisitos em linguagem natural.[9] Basicamente 
a ferramenta analisa o documento buscando expressões em linguagem natural que foram 
previamente classificadas como indicadores de qualidade. O relatório produzido pela 
ferramenta é utilizado para identificar indicativos de uma descrição que poderá causar 
problemas. 
 
As principais características de um documento de especificação de requisitos são: ser 
completo, consistente, correto, modificável, classificável, verificável e não ambíguo. Apesar 
dos atributos de qualidade serem subjetivos, existem alguns aspectos da documentação que 
podem ser mensurados. Por exemplo, o tamanho que é uma primitiva utilizada em um grande 
número de métricas, pode ser diretamente aplicado: o tamanho de um documento pode ser 
totalizado para número de páginas, número de linhas, número de parágrafos, etc. 
 
Estes contadores fornecem um indicativo de como o documento de especificação está 
organizado. Também é possível contar a ocorrência de palavras e expressões específicas, as 
quais sinalizam pontos fracos ou fortes na descrição[10]. 
 
Nove categorias de indicadores de qualidade foram estabelecidas no estudo de [9], a partir de 
uma série de documentos de especificação de sistemas desenvolvidos pela NASA e obtidos na 
biblioteca da SATC. 
 
Estas categorias estão divididas em 2 grupos: aquelas relacionadas a análise de comandos 
específicos, tais como : imperativas, continuações, diretivas, opções e frases “fracas”; e 
aquelas relacionadas a totalização do documento, tais como: tamanho, estrutura do texto, 
profundidade da especificação (em termos de itemização) e legibilidade. 
 
Um aspecto importante enfatizado no trabalho de [8], refere-se ao fato de que, a ferramenta 
produzida pelo SATC, não verifica a correção da especificação em termos de produto final, 
mas permite a produção de documentos de especificação que utilizam uma linguagem mais 
apropriada a especificação de requisitos. 
 
As questões acima relatadas relacionam-se ao contexto do presente trabalho a partir de uma 
das conclusões apresentadas por Wilson [8]: “ quem escreve documentos de especificação de 
requisitos deveria ser ensinado a como escrever estruturas de linguagem simples e diretas e 
como fielmente seguir um enfoque disciplinado na criação destes documentos. O documento 
não tem que ser interessante, mas passível de entendimento”. 
 
Dentro do contexto anteriormente caracterizado, e segundo a afirmação acima, a metodologia 
desenvolvida permite que este tipo de funcionalidade venha a ser aplicada durante o processo 
de desenvolvimento do aprendizado do aluno, de tal forma que, ao mesmo tempo em que o 
aluno está adquirindo experiência na solução de problemas relacionados aos tópicos 
introdutórios da disciplina, ele passa a fazê-lo empregando intuitivamente conceitos 
relacionados a produção de especificações de melhor qualidade – conceitos estes que 
oficialmente só serão desenvolvidos em semestres posteriores (de acordo com cada grade 
curricular). 
 
 
4. A solução através de Sistemas Especialistas 
 
Segundo Giarratano[4], o conhecimento pode ser classificado em : 
 
� Procedural: saber como fazer – ex: como esquentar água; 
� Declarativo: saber que algo é verdadeiro/falso – ex: não tocar em chaleira quente e 
� Tácito ou ‘inconsciente’: sabe o que ocorre, mas não sabe como faz – ex: mover a mão. 
 
No caso específico do problema proposto, observa-se com freqüência que a partir da solução 
de um determinado número de exercícios alguns alunos "descobrem" o mecanismo de como 
construir as soluções de lógica de programação. Entretanto, outros enquanto não se apropriam 
desta nova forma de pensar, permanecem estagnados, e assumem uma postura de tentativa-e-
erro. Naturalmente isto conduz ao insucesso e ao desânimo levando muitas vezes a 
reprovação na disciplina. 
 
Este ato de descobrir, se analisado do ponto de vista do aluno, poderia ser considerado como 
um conhecimento tácito, uma vez que, mesmo aqueles que aprenderam como fazer, tem 
dificuldades de explicar aos colegas como organizaram o raciocínio que conduziu a solução 
do problema. Por outro lado, se analisado do ponto de vista dos professores, o conhecimento é 
procedural, ou seja, sabe-se que há uma seqüência de passos a serem executados no sentido de 
construir-se uma solução lógica. Naturalmente, há ainda um outro tipo de conhecimento 
envolvido no caso em questão, o qual pode ser classificado como declarativo – ou seja, 
analisar-se a solução e verificar-se que a mesma funciona ou não, baseando-se em experiência 
prévia, sabe-se que determinada seqüência de passos, para determinados problemas, 
provavelmente conduzirá a uma solução que não é correta para determinadas situações. 
 
Uma característica fundamental do protótipo atual é que o conhecimento do especialista é 
armazenado através de regras. Regras, neste contexto, são construções simples na forma: Se 
alguma condição é verdadeira, Então faça alguma coisa. O uso de regras é interessante em 
algumas situações tendo em vista que permite a construção da definição de um determinado 
comportamento de maneira compacta. Se analisado em sua forma mais simples, um 
determinado comportamento caracteriza-se por um conjunto de ações e um conjunto de 
condições sob as quais as ações devem acontecer. 
 
O sistema especialista continuamente analisa um conjunto de elementos condicionais (regras) 
em relação a uma base de fatos (base de conhecimento) para verificar se alguma regra pode 
ser aplicada para aquele conjunto de fatos. Se a premissa é verdadeira, então o sistema 
especialista executa as ações associadas gerando novos fatos na base de conhecimento. Este 
processo de analisar a base e disparar regras é realizado por um componente denominado: 
máquina de inferência. 
 
Como citado anteriormente, a medida em que verificou-se que o processo de indução 
apresentava resultados, procurou-se identificar quais perguntas e em que seqüência elas eram 
apresentadas aos alunos, no sentido de conduzir a turma em direção a uma possível solução 
aos problemas propostos. 
 
A partir daí confeccionou-se o que foi caracterizado pelos alunos como : a metodologia dos 8 
passos. 
 
Esta primeira proposta procurava fazer com que o aluno respondesse às seguintes questões: 
a) Quais as “variáveis” conhecidas ? – ou seja, quais as informações que podem ser obtidas 
a partir do enunciado do problema; 
b) O que precisa ser calculado (ou executado)? – identificação do escopo da aplicação; 
c) Quais as “variáveis” desconhecidas? -- ou seja, variáveis para as quais não há informação 
no enunciado do problema; 
d) O que precisa ser informado (digitado) – ou seja, o que o usuário da aplicação precisa 
informar para que o mesmo realize suas funções; 
e) O que precisa ser apresentado (impresso) – ou seja, o que a aplicação deve apresentar 
como resultado; 
f) Realizar um esboço da solução – ou seja, identificar em termos de macro passos, qual a 
estratégia a ser adotada para solução do problema; 
g) Construir um fluxograma– efetivamente elaborar um fluxograma, utilizando a notação 
gráfica para representar a lógica da solução; 
h) Construir o teste-de-mesa – excitar as variáveis a partir da execução dos comandos na 
seqüência em que aparecem no gráfico 
 
Consequentemente, após a realização do teste-de-mesa e, verificada sua correção, a solução 
está pronta para ser codificada em alguma linguagem alvo. Embora facilitasse mais o 
encaminhamento da solução, a metodologia acima descrita ainda carecia de um detalhamento 
melhor, porque haviam obviamente muitos passos "escondidos" entre a passagem das fases de 
(a) a (e) para a fase (f) – esboço da solução. Cabe salientar que, com esta estratégia, um 
número maior de alunos passou a entender o escopo da aplicação – isto porque, o primeiro 
passo para a solução de um problema é entendê-lo. 
 
O passo seguinte foi o de detalhar o aspecto "obscuro" anteriormente citado. Através de 
entrevistas com o especialista e, utilizando-se as listas de exercícios que os alunos recebiam 
como exercícios, refinou-se o conhecimento a ponto de obter-se uma planilha a qual possui 28 
colunas. Nesta planilha, além de identificadas a seqüência de perguntas, identificou-se 
também grupos de perguntas relacionadas, de tal forma que, dependendo das respostas 
obtidas, somente um subconjunto das mesmas faz-se necessário serem respondidas para 
atingirem-se os objetivos desejados. 
 
O ponto de partida da análise foi: de um lado o enunciado do problema, de outro, o esboço da 
solução para cada um dos problemas. Uma vez estabelecidos os limites, passou-se a responder 
as questões e analisar-se o relacionamento entre as respostas e a proposta de esboço de 
solução no sentido de identificar-se algum padrão de comportamento. 
 
Este procedimento foi realizado para um conjunto de aproximadamente 30 exemplos, os 
quais englobavam desde a solução de problemas simples (entrada-equação-saída) , problemas 
de complexidade média baixa (entrada-várias equações-saída), problemas de média 
complexidade (entrada-decisões-equações-saída) e problemas de complexidade média-alta 
(repetições-entrada-decisões-equações-saída). Cabe salientar que neste estágio do projeto não 
foram contemplados exercícios envolvendo estruturas de dados multi-dimensionais. 
 
Com base nestas informações, o passo seguinte foi a construção uma estrutura de 
representação do conhecimento identificado através da análise dos problemas resolvidos, o 
que será descrito a seguir. 
 
4.1. A representação do c onhecimento 
 
Durante o processo de análise do conhecimento representado na planilha, verificou-se que 
haviam questões que exigiam respostas do tipo sim/não; questões que exigiam respostas 
textuais; situações em que era necessário uma orientação ao aluno no sentido de guiá-lo para 
o passo seguinte e, finalmente situações onde se fazia necessário uma realimentação sobre as 
decisões tomadas anteriormente tendo em vista posicioná-lo no contexto da solução em 
andamento. 
 
A partir destas informações, construiu-se em CLIPS uma árvore de decisões, a qual possui 4 
tipos de nodos, a seguir relacionados: 
 
� Nodos de decisão – ex: Há alguma operação lógica ou aritmética? 
� Nodos de ação – ex: Descreva a operação. 
� Nodos de status – ex: Até o momento você identificou os seguintes passos: 
� Nodos de ajuda – ex: Uma vez analisadas as pré-condições, podemos identificar a 
operação a ser realizada! 
 
Esta estrutura representa o conhecimento do especialista em termos de conhecimento 
procedural (conforme comentado anteriormente). 
 
A estratégia adotada para orientar o aluno, foi a filosofia de desenvolvimento top-down, onde 
o desenvolvimento da aplicação dá-se por refinamentos sucessivos. Sempre que houver 
necessidade, um novo passo de refinamento vai sendo realizado até a obtenção do nível 
desejado de especificação que efetivamente solucione o problema. Para tanto, foram 
construídas regras, que permitem a navegação através dos nodos da árvore de decisões. Assim 
sendo, medida em que os nodos vão sendo repetidamente visitados, novos fatos vão sendo 
gerados na memória de trabalho. 
 
Estes novos fatos disparam regras que uma vez executadas geram uma nova árvore auxiliar 
(denominada árvore de log) , a qual registra as respostas do usuário, e estabelece a seqüência 
em termos temporais em que as respostas vão sendo cadastradas. 
 
Em momentos estratégicos, apresenta-se ao aluno um feedback do contexto delineado pelo 
mesmo até o momento, e dependendo do nível de refinamento necessário, automaticamente o 
sistema inicia um novo passo de refinamento de alguma estrutura que ainda requeira 
informações complementares. 
 
A figura 1 apresenta uma tela onde é perguntado ao aluno que descreva sinteticamente o 
problema a ser resolvido. Neste momento já se procura induzi-lo a pensar em termos do 
contexto do problema. E a figura 2, continua apresentando questões ao aluno para que o 
mesmo vá aos poucos delimitando o escopo do problema, e aprofundando-se em direção a 
uma solução para o mesmo. 
 
Após cada rodada na árvore de decisões, apresenta-se ao aluno um feedback do contexto 
delineado pelo mesmo até o momento, e dependendo do nível de refinamento necessário, 
automaticamente o sistema inicia um novo passo de refinamento de alguma estrutura que 
ainda requeira informações complementares (figura 3). 
 
Figura 1 – Tela de contextualização do problema 
Figura 3 – Tela de feedback de andamento 
Figura 2 –Tela de contextualização do problema 
 
 
A adoção desta estratégia permitiu 
que fosse adquirido o 
conhecimento tácito do aluno, a 
partir do conhecimento 
declarativo, ou seja, o aluno sabe 
responder sim e não as perguntas 
que vão sendo realizadas. A 
ordem das perguntas está 
estabelecida na árvore de 
decisões. O que ele não sabe fazer 
que é explicar como resolver o 
problema vai sendo armazenado 
na árvore auxiliar (log), de tal 
forma que, ao final do processo, é 
possível inferir a solução macro 
do problema através da 
conjugação dos vários tipos de 
conhecimento envolvidos no 
processo. 
 
Como citado anteriormente, esta 
solução apesar de conduzir a um 
melhor entendimento do contexto 
do problema a ser solucionado, 
não contribui significativamente 
para o processo de generalização 
da solução desenvolvida (processo 
de abstração). Nesta situação, 
alunos com dificuldades em 
abstrair novos conceitos continuam 
excluídos do processo de 
aprendizagem. 
 
A solução adotada envolveu a 
utilização de técnicas de 
processamento de linguagem 
natural e raciocínio baseado em 
casos (associada a atual solução a 
base de sistemas especialistas), a 
qual será delineada a seguir. 
 
A proposta de solução através de 
raciocínio baseado em casos. 
 
A área de raciocínio baseado em 
casos é uma área relativamente 
recente, contudo, os 
pesquisadores em RBC não 
divergem muito sobre sua definição. 
 
A maioria dos autores concordam que o RBC é um método de raciocínio baseado na proposta 
de utilizar experiências passadas encapsuladas em estruturas de dados como a base para lidar 
com novas situações similares. A abordagem parece ser intuitiva: quando uma nova situação 
acontece, deve-se tentar alguma coisa que já foi utilizada com sucesso. Usualmente, as 
soluções utilizadas em situações similares devem ajudar na solução do novo problema. É 
importante notar que o raciocínio pode funcionar também por contra-exemplos. Neste caso, 
dada uma nova situação, deve-se procurar descartar aquelas soluções utilizadas em situações 
similares que resultaram em insucessos. Os sistemas RBC utilizam um processo interativo 
constituído genericamente por: identificação da situação atual, busca da experiência mais 
semelhante na memória e aplicação do conhecimento desta experiência na situação atual. 
Entretanto, a literatura usualmente não considera a identificação da situação atual como parte 
do processo RBC, adotando um modelo genérico baseado em quatro etapas: recuperar, 
reutilizar, revisar e reter. 
 
A principalparte do conhecimento nos sistemas RBC está representada através de seus casos. 
Um caso pode ser entendido como a abstração de uma experiência descrita em termos de seu 
conteúdo e contexto, podendo assumir diferentes formas de representação. A representação 
dos casos é uma tarefa complexa e importante para o sucesso do sistema RBC. O 
conhecimento neste contexto pode ser interpretado como sendo um conjunto de métodos que 
modelam um conhecimento especializado para disponibilizá-lo em um sistema inteligente. 
Apesar de um sistema RBC ser extremamente dependente da estrutura e do conteúdo de sua 
base de casos, seu conhecimento não está presente apenas nos seus casos (memória), mas 
também nas suas etapas de desenvolvimento. Estas etapas são: Representação dos casos, 
Indexação, Recuperação dos casos, Adaptação e Aprendizagem. A seguir cada uma das fases 
é descrita nos termos da especificação do projeto ora em andamento. 
 
 
4.2. Representação dos casos. 
 
Um caso neste contexto é definido através de um perfil de solução, o qual é formado pelos 
seguintes componentes: Palavras-Chave, Generalização, Número-de-passos, Número-de-
variáveis, Número-de-constantes e Solução. 
 
As palavras-chave são obtidas tomando-se por base o texto do enunciado, e a aplicação de 
um conjunto de heurísticas importadas da solução anterior (usando-se Sistemas Especialistas). 
A generalização constitui-se no resultado do processo de abstração da solução do caso em 
questão. Número-de-passos, Número-de-variáveis e Número-de-constantes são métricas 
utilizadas para melhor definir o perfil deste caso, e usadas na fase de seleção dos melhores 
casos para um determinado contexto. A Solução contém a seqüência detalhada dos passos 
necessários para a solução do problema. Esta solução é desenvolvida utilizando-se a 
metodologia apresentada em [5]. 
 
 
4.3. Indexação. 
 
A indexação é um problema central em raciocínio baseado em casos, envolvendo a 
determinação dos tipos de índices que serão utilizados pela etapa de recuperação. Da mesma 
forma que índices podem acelerar a busca em bases de dados, eles são utilizados em RBC 
para acelerar a recuperação de casos. Na solução proposta há basicamente 2 índices que são 
utilizados para nortear o processo de recuperação: um índice montado a partir das 
generalizações e um índice montado a partir das palavras-chave. Cada entrada no índice de 
generalização aponta para o conjunto de casos que descrevem os perfis de soluções 
associadas. Cada entrada no índice de palavras-chave aponta para o conjunto de 
generalizações em cujas soluções estão a referida chave. Como o projeto encontra-se em fase 
de projeto, e a base de casos não é muito grande, não há a necessidade de uma estrutura de 
armazenamento mais complexa. No entanto, a medida em que a base de casos começa a 
aumentar, certamente far-se-á necessário uma estrutura de gerenciamento auxiliar, 
possivelmente baseada em gerenciadores de bases de dados. 
 
 
4.4. Recuperação dos casos. 
 
Dado um enunciado de um problema a ser resolvido, esta etapa realiza a busca na base de 
casos e seleciona quais casos podem ser aproveitados. O processo é feito por algoritmos que 
selecionam casos da base que apresentam um determinado grau de similaridade com o caso 
proposto. No contexto do protótipo, este processo ocorre em duas fases: uma fase de pré-
seleção (dirigido por palavras-chave) e uma fase de seleção propriamente dita (dirigida por 
abstrações). Na fase de pré-seleção, o processo de montagem do caso proposto envolve uma 
fase de análise do texto do enunciado, onde busca-se identificar através de uma série de 
heurísticas um conjunto de palavras-chave que nortearão o processo de busca dos possíveis 
casos que enquadram-se neste perfil. O índice de similaridade é calculado a partir do número 
de palavras-chave encontradas. Quanto maior o número delas, melhor a qualidade da seleção. 
 
A fase de seleção propriamente dita, onde será selecionado o caso que melhor se enquadra a 
solução ocorre da seguinte forma: uma vez recuperados aqueles casos julgados pertinentes, 
dispara-se o processo de análise de requisitos descrita em [5]. A medida em que o aluno vai 
desenvolvendo a lógica da solução, o conjunto de casos selecionado vai sendo depurado, e um 
perfil genérico vai sendo montado, de tal forma que, a partir de um determinado momento, o 
melhor caso passa a ser usado como referência para nortear as questões que devem ser 
apresentadas ao aluno. 
 
4.5. Adaptação 
 
Quando problemas são resolvidos usando-se RBC, o tipo principal de conhecimento usado 
durante a solução de um problema é aquele fornecido pelo conhecimento específico contido 
nos casos. Contudo, em muitas situações este conhecimento não é suficiente ou apropriado 
para atender a todos os requisitos da aplicação. Freqüentemente são utilizados conhecimentos 
de domínio, os quais podem contribuir para a identificação de dependências entre certas 
características de um caso e auxiliar na inferência de características adicionais. No projeto 
INRECA [11], este tipo de conhecimento é denominado conhecimento de base (background), 
e é representado através de regras em uma estrutura de representação de casos orientada à 
objetos. Estas regras podem ser classificadas em 2 grupos: regras de preenchimento 
(completion) e regras de adaptação. 
 
No projeto INRECA, as regras de preenchimento servem para explicitar interdependência 
entre atributos bem como para inferir valores de atributos que são dependentes de alguns 
outros na descrição do caso. No caso do protótipo em questão, a seguinte regra: “variáveis 
utilizadas do lado direito de uma expressão devem ter sido previamente inicializadas” poderia 
ser enquadrada neste grupo. 
 
No projeto INRECA, as regras de adaptação servem para ajustar valores de atributos entre 
aqueles especificados no caso de entrada e aqueles recuperados da base tendo em vista 
produzir-se um novo caso. No caso do protótipo, as regras de adaptação executam um papel 
ligeiramente diferente daquele apresentado acima na medida em que elas são usadas para 
modificar a estrutura de uma solução apresentada pelo aluno. Por exemplo: a regra 
“seqüências if’s podem ser escritas através de uma estrutura case” poderia-se enquadrar-se 
neste caso. 
 
 
4.6. Aprendizagem. 
 
Uma característica muito interessante que os sistemas de RBC podem apresentar é a 
capacidade de aprendizagem. Este processo pode ser aplicado a um caso específico ou a base 
toda. No protótipo, este processo é disparado em três situações. 
 
� toda vez que, após um enunciado ter sido digitado, o processo de seleção não consegue 
identificar nenhuma palavra-chave, ou o conjunto de palavras-chave recuperado é muito 
pequeno, ou ainda produz ambigüidades. Neste momento, dispara-se um processo onde o 
usuário (provavelmente o professor) deverá identificar quais são as palavras-chave 
importantes que vão nortear o processo da solução. 
� Num segundo momento, o processo de aprendizagem é disparado, quando o processo de 
recuperação encontra palavras-chave e não consegue recuperar um conjunto de casos. 
Nesta situação, o processo de aprendizagem consiste em generalizar a solução apresentada 
e cadastrá-la na base de casos. 
� Num terceiro momento, dito off-line, quando solicita-se explicitamente a execução do 
processo de análise e generalização dos casos da base. 
 
 
5. O protótipo da Aplicação em RBC 
 
O protótipo da aplicação acima descrita está sendo implementado em Java, e possui as 
seguintes características: 
 
� implementa a fase de análise de enunciados, permitindo a identificação de: heurísticas 
(como explicado anteriormente), constantes, variáveis (se necessário ou não a sua 
inicialização), repetições, decisões, entradas e saídas. 
� Implementa a fase de generalização do enunciado, a partir das informações coletadas na 
fase anterior. 
 
Atualmente, encontra-se em fase de implementação/testes o módulo de recuperação dos casos 
da base a partir da chavede generalização do perfil do caso como da chave de generalização 
do perfil da solução. 
 
O funcionamento do protótipo é muito simples. Uma vez instalado, deve-se armazenar no 
diretório “Enunciados” as descrições dos problemas que pretende-se, venham a ser 
Figura 4 – Tela inicial do protótipo 
solucionados pelos alunos. Executando-se a aplicação, após uma tela de identificação do 
usuário, apresenta-se a tela apresentada na figura 1. 
 
Seleciona-se o caso clicando-se sobre o nome do arquivo que contém o enunciado e 
pressionando-se o botão “Enunciado”. Neste momento, aparece na janela abaixo, a descrição 
do enunciado do caso. 
 
Clicando-se no botão ‘Generaliza”, o processo de análise do texto do enunciado é disparado, 
e o resultado apresentado na janela “Perfil do Caso” como apresentado na figura 5. 
 
6. Trabalhos Futuros 
 
A partir dos testes realizados com os 2 protótipos – o primeiro de sistemas especialistas em 
CLIPS e o segundo utilizando RBC em Java, atualmente encontra-se em fase de 
desenvolvimento a 3a versão da ferramenta, a qual deve incorporar uma versão do sistema 
especialista convertida para Java através da biblioteca Jess, e o aprimoramento da aplicação 
utilizando RBC. 
 
Pretende-se que a partir de um enunciado textual seja possível construir-se um meta-modelo 
da solução utilizando-se o conhecimento adquirido pelo sistema de RBC, de tal forma que 
este modelo, possa ser de certa forma passado como parâmetro para o sistema especialista. O 
sistema especialista, a partir deste meta-modelo deverá ajustar-se de forma a eliminar 
perguntas redundantes e perguntas ineficazes e concentrar as perguntas no contexto da meta-
solução. 
Dessa forma, minimiza-se a possibilidade de distração, e potencializa-se o aspecto 
educacional permitindo inclusive que sejam, posteriormente, desenvolvidas questões que 
permitam reconduzir o aluno ao caminho quando este derivar “muito” da meta-solução 
proposta. 
 
7. Conclusão 
 
Como apresentado anteriormente, uma das vantagens na aplicação de técnicas de raciocínio 
baseado em casos está em trabalhar com conhecimento de domínio parcialmente incompleto. 
Não há necessidade que um modelo explícito de domínio esteja presente. Esta característica 
permite que o crescimento seja incremental, a medida em que novos casos vão sendo 
agregados a base de casos. 
 
A aplicação desta característica com fins educacionais é válida na medida em que os casos 
podem ser explorados como situações a serem apresentadas aos estudantes para que estes 
tentem produzir soluções adotadas anteriormente em problemas semelhantes, sintetizá-las, 
aplicá-las na nova solução e ainda fornecer explicações que motivaram a escolha. 
 
Embora o protótipo esteja em fase inicial de implementação, algumas características já podem 
ser avaliadas, o que permite dizer que a aplicabilidade desta proposta com fins didáticos é 
perfeitamente viável, e deve conduzir a melhores resultados quando comparados com àqueles 
obtidos na versão anterior que utilizava somente a técnica de sistemas especialistas e 
centrava-se somente na fase de análise de requisitos. 
 
8. Bibliografia 
 
[1] Amorim,R.V,Rezende,P.J. Compreensão de algoritmos através de ambientes 
dedicados a animação. In XX Semish, 1993. 
[2] Brown,M. Exploring algorithms using Balsa-II . Computer,21(5): 14-36,1988. 
[3] Brown,M. Zeus: a system for algorithm animation and multi-view editing . In 
Proc.1991 IEEE Workshop on Visual Languages. IEEE, October 1991. 
[4] Giarratano,J.C. & Riley,G. Expert Systems: principles and programming. PWS 
Publishing Co, Boston, 1994. 
[5] Mattos,M.M.Fernandes,A. López,O.C. Sistema especialista para apoio ao 
aprendizado de lógica de programação . VII Congresso Iberoamericano de 
Educación Superior en Computación.- CIESC99, Asunción, Paraguay. Set.1999. 
[6] Rezende,P, J. de Garcia,I. C. Ensino de estruturas de dados e seus algoritmos 
através de implementação com animações. IC Technical Report, IC-96-14, 
Nov 1996. 
[7] Stasko,J. Tango: a framework and system for algorithm animation .Computer, 
23(9): 39-44, 1990. 
[8] Wilson, W.M., Rosenberg,L.H and Hyatt,L.E. Automated Analysis of Requirement 
Specifications . International Conference on Software Engineering (IASTED), 
Boston, MA - May 1997. 
[9] Wilson, W.M Rosenberg,L.H. Hyatt,L.E. Automated Analysis of Requirement 
Specifications. International Conference on Software Engineering (IASTED). 
Boston, MA - May 1997 
[10] Wilson, W.M .Writing Effective Requirements Specifications . Software Technology 
Conference. Utah, April 1997. 
[11] Wilke,W. Bergmann,R. Adaptation with the INRECA System .ECAI’96 Workshop: 
Adaptation in CBR. 1996.