Aplicação de Raciocínio Baseado em Casos na Fase de Análise de Requisitos para Construção de Abstrações em Lógica de Programação

Aplicação de Raciocínio Baseado em Casos na Fase de Análise de Requisitos para 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 [email protected]

Christiane Gresse von Wangenheim UFSC – Universidade Federal de Santa Catarina Departamento de Engenharia de Produção e Sistemas [email protected]

Roberto C. Pacheco, PhD UFSC – Universidade Federal de Santa Catarina Departamento de Engenharia de Produção e Sistemas [email protected]

RESUMO Os educadores estão constantemente buscando novas maneiras de prender a atenção e melhorar e facilitar os níveis de aprendizado. Este artigo 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 Educators constantly are seeking new ways to improve instruction to facilitate learning and to hold the student’s attention. 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. É 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 recentemente 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. o

Analisando-se o perfil destes alunos, verifica-se que em sua maioria, são oriundos do 2

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ções gerais 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-eerro. 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 conhecimento

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 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.

5. 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 principal parte 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. 5.1. 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-devariá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]. 5.2. 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.

5.3. 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 5.4. 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üencias if’s podem ser escritas através de uma estrutura case” poderia-se enquadrar-se neste caso. 5.5. 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.

6. 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. 7. 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 [11] Wilke,W. Bergmann,R. Adaptation with the INRECA System.ECAI’96 Workshop: Adaptation in CBR. 1996.